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

[Warner Losh <imp@bsdimp.com>]

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

On Mon, Jun 17, 2024, 5:30 PM Greg A. Woods <woods@robohack.ca> wrote:

> 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

--
>                                         Greg A. Woods <gwoods@acm.org>
>
> Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
> Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>
>

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