[TUHS] Version 256 of systemd boasts '42% less Unix philosophy' The Register

[segaloco via TUHS]

On Monday, June 17th, 2024 at 6:51 PM, Steve Nickolas <usotsuki at buric.co> wrote:

> On Sun, 16 Jun 2024, Greg A. Woods wrote:
> 
> > At Mon, 17 Jun 2024 18:34:06 -0400 (EDT), Steve Nickolas usotsuki at buric.co wrote:
> > 
> > Well, to be pedantic "dash" was a direct descendant of NetBSD's /bin/sh,
> > which in turn was the shell from 4.4BSD, which was of course originally
> > Kenneth Almquist's Ash. Quite a few changes were made to the shell in
> > BSD between the time it was imported (1991), and the 4.4 release (1995).
> > 
> > Unfortunately Dash now lags very far behind NetBSD's /bin/sh code.
> > 
> > If they had just kept it as a port of the upstream code and continued to
> > update it from upstream then "they" would now have a much better shell
> > (as much development has occurred in NetBSD since 1997), but no it's a
> > full-on fork that's basically ignored its upstream parent since day one.
> > It is doomed now to need fixes for the same bugs again, often in
> > incompatible ways, and probably inevitably new features will be added to
> > it, also in incompatible ways.
> 
> 
> It's still possible to port NetBSD's /bin/sh to Debian (I've done it,
> called it "nash", but don't have any official release because I don't
> really see a point).
> 
> And it's basically the "sh" I'm currently using in my projects because I
> don't have the talent to write my own. :P
> 
> -uso.

Dash is my go-to /bin/sh on minimal Linux systems I prepare owing to its similar minimalism.  I've considered that angle and hearing of your success has me tempted to pursue something along those lines.  There are projects out there that have propped up a BSD userland over the Linux kernel too.  I've not really tinkered with such things myself but I wonder if, given enough time, such a combo could gain more traction or fill a want/need not being met otherwise?  Technically it's another way for Linux-sans-systemd.

Systemd does seem to cover a diverse spread of use-cases, some better than others.  For a personal system, it feels a bit much, but many folks have made valid points, particularly regarding systems you create and walk away from.

I think of things so often from the interactive, personal system angle, but many systems don't have one person sitting at them with a handful of xterms open.  I imagine the Linux world is steered a bit more in the server and enterprise directions as far as there is money to be made, naturally.  Upstream wants to satisfy this crowd so personal user systems dip into the same systemd pool.

My only major concern still is a sort of homogenization of the Linux userland, the same as exists in the marriage of Linux and GNU.  Much of the software out there assumes if you'd got a Linux kernel, you've a GNU C library and some supporting bits, and vice versa.  That's not to diminish the real help of things like autotools and CMake, but if someone is liable to use a non-portable thing, it's probably a GNU extension or Linux-ism.  This isn't critique of either or, rather, the weight of their combined influence.  If systemd gains comparable eminence in the overwhelming majority of Linux distros to the GNU C library itself, similarly one will find themselves with daemons that may only behave themselves under systemd's piercing gaze.

Maybe it's only natural, systemd does seem to satisfy the needs of more than it offends.  They can't take my sysvinit away from me though.  It "just works" but my needs are also narrow.

- Matt G.