At Mon, 17 Jun 2024 18:34:06 -0400 (EDT), Steve Nickolas <usotsuki@buric.co> wrote:
Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register
>
> Which is why I'm glad Debian's /bin/sh is dash (fork of ash) instead.
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.
Then again OpenBSD and FreeBSD (and its derivatives) have also continued
forked development of the 4.4BSD shell (and most of the rest of the
system) with only very occasional sharing of code back and forth with
NetBSD.
Yea. Personality squabbles trump common sense. Some areas have reconverged, and those are bright points.
I guess this forking of code is also somewhat a part of "Unix" practice,
even if it goes against the strict tenets of Unix philosophy. I don't
think it's as egregious as the N.I.H. "doctrine" (of which systemd could
be the result of, and cmake is definitely the result of), but it is
problematic.
Yea. It's more of a people problem and for the first 15 or 20 years of 4.4BSD the tools to reconverge weren't up to the task, even if the political will had been there to bless it. Diff was just one part. The easy part. But knowing why things differed. What mattered, why it was different (often with only the log message "fix. Ok xxx" to go on). Once it morphed organically for even 5 years, going back was hard. There was no upstream anymore. Csrg was gone, and all successor BSD projects assumed they were the new upstream. It was rarely clear whichnproject has the rights to that claim as the answer was patjologically different for different parts of the system.
The NIH stuff sunk adopting jails, geom, smp, etc from FreeBSD and almost sunk make from unifying some years ago. Too much ego and wanting perfect code so all that other code is junk... It's a hard problem because continuing engineering is actually hard and boring work nobody wants to do as their fun hobby... not least because it requires a lot of time to keep up and the skills of a diplomat, which previous few people have.. plus a perception that mere merging never advances the state of the art...
Warner