Re: [TUHS] [tuhs] The Unix shell: a 50-year view

[Dan Cross <crossd@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5028 bytes --]

On Sat, Jul 3, 2021 at 8:36 AM Thomas Paulsen <thomas.paulsen@firemail.de>
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.

[-- Attachment #2: Type: text/html, Size: 5657 bytes --]