From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 3926 invoked from network); 3 Jul 2021 13:22:31 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 3 Jul 2021 13:22:31 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 192C99C8A8; Sat, 3 Jul 2021 23:22:30 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 881619C86C; Sat, 3 Jul 2021 23:21:38 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="MiNGjLBY"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id C2CD09C86C; Sat, 3 Jul 2021 23:21:35 +1000 (AEST) Received: from mail-oi1-f173.google.com (mail-oi1-f173.google.com [209.85.167.173]) by minnie.tuhs.org (Postfix) with ESMTPS id A2B4B9C864 for ; Sat, 3 Jul 2021 23:21:34 +1000 (AEST) Received: by mail-oi1-f173.google.com with SMTP id r20so10379305oic.2 for ; Sat, 03 Jul 2021 06:21:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=A7uVzWWBkara9CrAHGd/LXy12B6M6bWkHTR3exMHdiI=; b=MiNGjLBY/diFtpKaM4ey2bj4mBy4dhNM3jnJ79blDaWNRyjMV5to5KDtDfRPruhmi/ R40l/AY2MN6tnW33+1oPwPQAiwSjvq4Mzuo4yebtrBqDlKMdP3yfh0MXkapI2He5/9Rx gYP8iDpyO9lr+nBJ+aLVU/ngrpOb3bXmwRNoRrYoHw4pnxJdhjpwt3CJZE8tSUyZze/E Y+nXsvYpWl+SzPDLYGhrVZtDP/i2ZKbFpN/3uO2Ihj6NnbUB698wPmYpK1n45wh+Ebtm YsxBPl8A7vhhu1uum8Sbt8gAWPdINeUq6o4rv79R7lTH1B/sEyVsZk0RMSkyQNma5dJ1 8O5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=A7uVzWWBkara9CrAHGd/LXy12B6M6bWkHTR3exMHdiI=; b=rVY+/hLQ97ooZUyR0gsa4hbD+WYlPI6hV2tDqcA8A5m0Gnd27bcTHXl0gprOZH8jZu /tbPqtY3nZDWQYlsI3uoI44WFCQz2Xd6a2KJeBNbhVDc0bger1R9opqH0hfkKy/bIpFG pousHc+OVmvXkdUTe2TYjRAgzMTmwypqOnDnl1EQsKF8/xjPBvm6ADMIx2ylq8kNKJrM 2QZerXAq6fw7erBuvUoK/6URn3ye7YqiqDfoXJeh4aiAFRjC7CV+fVaVUWwDSruJHQDv hmCsZIpBQWieoFcTHTDJxsdTbCeLzFJ1VSjWDdNgyvHWaekNlqDAIvngf5MDkUR972J4 9IsA== X-Gm-Message-State: AOAM532clCcKFWBq0FnPS1fK3N0cZc8aGsy09A2NO/j7UW6fhfWtEfyn tmqpoQeJNmlRKsd80mjtA2pom0bLtFaiFC5rJHg= X-Google-Smtp-Source: ABdhPJzFRX5PEO8dyfWJaATJjJhByGfTa701snksnVSjL8jTzv6sx8SEtYl4GgO6mNEqujM0F0pJK3ljnFs6KAcrGA8= X-Received: by 2002:a05:6808:200d:: with SMTP id q13mr3695903oiw.24.1625318493809; Sat, 03 Jul 2021 06:21:33 -0700 (PDT) MIME-Version: 1.0 References: <20210702213648.GW817@mcvoy.com> <396911b232bae5938068a14fe0f7181e@firemail.de> In-Reply-To: <396911b232bae5938068a14fe0f7181e@firemail.de> From: Dan Cross Date: Sat, 3 Jul 2021 09:20:57 -0400 Message-ID: To: Thomas Paulsen Content-Type: multipart/alternative; boundary="00000000000078715005c637f3b5" Subject: Re: [TUHS] [tuhs] The Unix shell: a 50-year view X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: tuhs@minnie.tuhs.org Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --00000000000078715005c637f3b5 Content-Type: text/plain; charset="UTF-8" On Sat, Jul 3, 2021 at 8:36 AM Thomas Paulsen wrote: > >The Linux distro I use does use systemd but I can ignore it and go on > with my life as if it were still running sysvinit. So it's not that big a > deal to me. > I'm running red hat fedora which switched 100% to systemd a couple of > years ago. It's fine, a good piece of software. > Systemd is both good and bad. The good part is that it allows for parallel service startup, which means that your system gets up and running (and serving useful work) faster. It understands the service dependency graph and thus the service start order and what can be done simultaneously. It also, in theory anyway, makes life a little easier for the authors of what I'll call "service software" (read: daemons and servers): need a privileged resource? Describe it to systemd, that will then acquire it for you and hand it to your unprivileged service software. That's nifty, aids privilege separation, namespace sandboxing a la containers, etc. But systemd is also terrible. In an extremely un-Unix-like manner, it consolidates an enormous number of disparate functions into a single monolithic piece of software. It uses ersatz data formats that are abjectly horrible. It uses binary logging, which means that one cannot use the full complement of Unix text filters to inspect logs. It does all sorts of stuff behind the scenes (manipulating filesystems, for example) in ways that are obscured and opaque to system administrators, let alone programmers; this can have surprising results (ask Ron Minnich about systemd-related data loss). It has complete disregard, and indeed, contempt for the Unix philosophy. What's interesting (to me, anyway), is how few people care about the deficiencies. This suggests a pretty fundamental shift in how people use Unix-like systems, and Linux in particular: for _most_ users, it has become a commoditized vessel for running other interesting software, but not what we historically think of as "Unix". Sure, a lot of people still live at the command line, but that's no longer the primary focus of interaction. Our machines are now either all-singing, all-dancing multimedia workstations where the sole user is in a web browser most of the time, in which case the underlying system is just a detail, they're server-class machines that are running some workload, but not something that's interactive, or embedded devices that are black boxes. Much of Unix's early evolution and thus architecture and philosophy, came from addressing a set of problems that people had in a historical context that, one could argue, aren't that relevant anymore. A hierarchical filesystem in a global namespace, pipelines facilitating chaining of filters for interactive use, a simple but weak permissions model, unstructured text as a universal interchange format, terminal-oriented text editors.... All of these were fine on shared multiuser interactive machines, but do they matter as much now? If the nexus of interaction is a web browser, who cares whether I can grep a log file? If I just want my bluetooth headphones and USB camera to work for an online meeting, how that stuff is put together under the hood isn't that interesting to me. In short, the Unix philosophy is becoming less and less relevant as a new generation of users and programmers put different demands on systems. Linux is _probably_ the most prevalent kernel in the world, but most places its used it's hidden from view. In that context, something like systemd actually makes some amount of sense. Perhaps I've mentioned this story before: a former colleague at Google was writing a shell script to figure something out. It wasn't working. Really, what he wanted was basically a `grep -q` and an `if` statement, but he'd written a complicated mess with shell functions that tried to "return" the exit status of the processes they ran: his shell script was written more like a Python program. I rewrote it for him in half-a-dozen or so lines (down from 30 or 40) and talked about Unix for a minute, the philosophy, etc. At the end of my monologue extolling the virtues of our style of computing, he looked at me blankly and said something along the lines of, "yeah. I think that time has passed and people just don't conceptualize problems that way anymore." I was sad, but is it any wonder that the kids reach for Python before a shell script these days? We aren't teaching, yes, but moreover they don't want to learn because the problems they're trying to solve are different. We need to accept and internalize that and think hard about how the tools we use can be brought to bear on the problems that are relevant _now_, not 30 years ago. It does beg the question: is a Unix-style kernel still the appropriate foundation for this style of computing? Why are we still using this system: is it because of its intrinsic power and versatility, or because of inertia? Systemd, containers, etc, all suggest that our models are inadequate. - Dan C. --00000000000078715005c637f3b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jul 3, 2021 at 8:36 AM Thomas Pau= lsen <thomas.paulsen@firem= ail.de> wrote:
>The Linux distro I use does use system= d but I can ignore it and go on with my life as if it were still running sy= svinit.=C2=A0 So it's not that big a deal to me.
I'm running red hat fedora which switched 100% to systemd a couple of y= ears ago. It's fine, a good piece of software.
Systemd is both good and bad.

The good= part is that it allows for parallel service startup, which means that your= system gets up and running (and serving useful work) faster. It understand= s the service dependency graph and thus the service start order and what ca= n be done simultaneously. It also, in theory anyway, makes life a little ea= sier for the authors of what I'll call "service software" (re= ad: daemons and servers): need a privileged resource? Describe it to system= d, that will then acquire it for you and hand it to your unprivileged servi= ce software. That's nifty, aids privilege separation, namespace sandbox= ing a la containers, etc.

But systemd is also terr= ible. In an extremely un-Unix-like manner, it consolidates an enormous numb= er of disparate functions into a single monolithic piece of software. It us= es ersatz data formats that are abjectly horrible. It uses binary logging, = which means that one cannot use the full complement of Unix text filters to= inspect logs. It does all sorts of stuff behind the scenes (manipulating f= ilesystems, for example) in ways that are obscured and opaque to system adm= inistrators, let alone programmers; this can have surprising results (ask R= on Minnich about systemd-related data loss). It has complete disregard, and= indeed, contempt for the Unix philosophy.

What= 9;s interesting (to me, anyway), is how few people care about the deficienc= ies. This suggests a pretty fundamental shift in how people use Unix-like s= ystems, and Linux in particular: for _most_ users, it has become a commodit= ized vessel for running other interesting software,=C2=A0but not what we hi= storically think of as "Unix". Sure, a lot of people still live a= t the command line, but that's no longer the primary focus of interacti= on. Our machines are now either all-singing, all-dancing multimedia worksta= tions where the sole user is in a web browser most of the time, in which ca= se the underlying system is just a detail, they're server-class machine= s that are running some workload, but not something that's interactive,= or embedded devices that are black boxes.

Much of= Unix's early evolution and thus architecture and philosophy, came from= addressing a set of problems that people had in a historical context that,= one could argue, aren't that relevant anymore. A hierarchical filesyst= em=C2=A0in a global namespace, pipelines facilitating chaining of filters f= or interactive use, a simple but weak permissions model, unstructured text = as a universal interchange format, terminal-oriented text editors.... All o= f these were fine on shared multiuser=C2=A0interactive machines, but do the= y matter as much now? If the nexus of interaction is a web browser, who car= es whether I can grep a log file? If I just want my bluetooth headphones an= d USB camera to work for an online meeting, how that stuff is put together = under the hood isn't that interesting to me. In short, the Unix philoso= phy is becoming less and less relevant as a new generation of users and pro= grammers put different demands on systems. Linux is _probably_ the most pre= valent kernel in the world, but most places its used it's hidden from v= iew. In that context, something like systemd actually makes some amount of = sense.

Perhaps I've mentioned this story befor= e: a former colleague at Google was writing a shell script to figure someth= ing out. It wasn't working. Really, what he wanted was basically a `gre= p -q` and an `if` statement, but he'd written a complicated mess with s= hell functions that tried to "return" the exit status of the proc= esses they ran: his shell script was written more like a Python program. I = rewrote it for him in half-a-dozen or so lines (down from 30 or 40) and tal= ked about Unix for a minute, the philosophy, etc. At the end of my monologu= e extolling the virtues of our style of computing, he looked at me blankly = and said something along the lines of, "yeah. I think that time has pa= ssed and people just don't conceptualize problems that way anymore.&quo= t; I was sad, but is it any wonder that the kids reach for Python before a = shell script these days? We aren't teaching, yes, but moreover they don= 't want to learn because the problems they're trying to solve are d= ifferent. We need to accept and internalize that and think hard about how t= he tools we use can be brought to bear on the problems that are relevant _n= ow_, not 30 years ago.

It does beg the questio= n: is a Unix-style kernel still the appropriate foundation for this style o= f computing? Why are we still using this system: is it because of its intri= nsic power and versatility, or because of inertia? Systemd, containers, etc= , all suggest that our models are inadequate.

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 - Dan C.


<= /div>
--00000000000078715005c637f3b5--