On Monday, June 17th, 2024 at 6:51 PM, Steve Nickolas <usotsuki(a)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(a)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.