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

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

[Charles H Sauer (he/him)]

https://www.theregister.com/2024/06/13/version_256_systemd/

I don't see the boast at 
https://github.com/systemd/systemd/releases/tag/v256, but ...

Charlie
-- 
voice: +1.512.784.7526       e-mail: sauer@technologists.com
fax: +1.512.346.5240         Web: https://technologists.com/sauer/
Facebook/Google/LinkedIn/Twitter: CharlesHSauer

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

[Dan Cross]

On Thu, Jun 13, 2024 at 10:56 AM Charles H Sauer (he/him)
<sauer@technologists.com> wrote:
> https://www.theregister.com/2024/06/13/version_256_systemd/
>
> I don't see the boast at
> https://github.com/systemd/systemd/releases/tag/v256, but ...

That "boast" seems to come from a random mastodon post?

        - Dan C.

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

[Larry McVoy]

"The new alternative does no such sleight of hand. Instead, it just gets the
systemd daemon to run the command for you, using a special form of the existing
systemd-run command."

Sounds like a new path for exploits.  We'll see if Mr Systemd has to eat
some crow in the future.  Said by a guy who _hates_ systemd.


On Thu, Jun 13, 2024 at 09:56:04AM -0500, Charles H Sauer (he/him) wrote:
> https://www.theregister.com/2024/06/13/version_256_systemd/
> 
> I don't see the boast at
> https://github.com/systemd/systemd/releases/tag/v256, but ...
> 
> Charlie
> -- 
> voice: +1.512.784.7526       e-mail: sauer@technologists.com
> fax: +1.512.346.5240         Web: https://technologists.com/sauer/
> Facebook/Google/LinkedIn/Twitter: CharlesHSauer

-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

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

[Alan D. Salewski]

On Thu, Jun 13, 2024, at 11:35, Larry McVoy wrote:
> "The new alternative does no such sleight of hand. Instead, it just gets the
> systemd daemon to run the command for you, using a special form of the existing
> systemd-run command."
>
> Sounds like a new path for exploits.  We'll see if Mr Systemd has to eat
> some crow in the future.  Said by a guy who _hates_ systemd.

Eating sudo, eating crow...I guess systemd is /still/ hungry:

    https://i.kym-cdn.com/photos/images/original/000/925/966/8d2.gif

-Al

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

[Steve Nickolas]

On Thu, 13 Jun 2024, Larry McVoy wrote:

> "The new alternative does no such sleight of hand. Instead, it just gets the
> systemd daemon to run the command for you, using a special form of the existing
> systemd-run command."
>
> Sounds like a new path for exploits.  We'll see if Mr Systemd has to eat
> some crow in the future.  Said by a guy who _hates_ systemd.

systemd is the thing that should not be.

If I had successfully gotten my project up (trying to get a standalone
kernel/libc/clang build environment up and running - either Linux/musl or 
NetBSD) it would run a rewrite of the SysV init system (not "sysvinit", 
that's GPL).

-uso.

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

[Clem Cole]

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

Thank Charlie.  But I just threw up after I read it.

Sadly, UNIX's "prime directive" was to "keep it simple."  Or, as someone
else describes it, create "small tools that did one job well." On the
PDP-11, the lack of address space somewhat enforced this. With the 32-bit
vax, we see cat -v and the like. I think "frameworks" are just a modern
term for IBM's "access methods" of the 1960s. John Lions observed that the
entire documentation set for UNIX V6 could be kept in a 3-ring binder, and,
as his book showed, given the size, anyone could understand all of the
kernel and the core systems ideas.

FWIW, Linux is not the first to fail. Years ago, I pointed out to Dennis
that the System V Release 3 bootloader for the 3B was larger than the
entire V6 kernel. I  have not looked at the size of systemd, but do you
want to bet that it fails the same test?

But I digress. Someone (Henry Spencer, maybe) once said, "Good Taste is
subjective. I have it, and you don't seem to."

IMO systemd, was >>not<< a net positive - it falls so many of these tests
WRT to good programming and good ideas.

Sigh ...
Clem
ᐧ
ᐧ

On Thu, Jun 13, 2024 at 10:56 AM Charles H Sauer (he/him) <
sauer@technologists.com> wrote:

> https://www.theregister.com/2024/06/13/version_256_systemd/
>
> I don't see the boast at
> https://github.com/systemd/systemd/releases/tag/v256, but ...
>
> Charlie
> --
> voice: +1.512.784.7526       e-mail: sauer@technologists.com
> fax: +1.512.346.5240         Web: https://technologists.com/sauer/
> Facebook/Google/LinkedIn/Twitter
> <https://technologists.com/sauer/Facebook/Google/LinkedIn/Twitter>:
> CharlesHSauer
>

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

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

[Arrigo Triulzi via TUHS]

On 13 Jun 2024, at 17:39, Clem Cole <clemc@ccc.com> wrote:
> IMO systemd, was >>not<< a net positive - it falls so many of these tests WRT to good programming and good ideas.

Binary logs, ’nuff said.

Good sysadmins live & die by grep and being able to visually detect departures from the norm by just looking at the “shape” of logs scrolling down a screen (before), terminal window now.

Yours disgusted since v1 of that abomination.

Arrigo

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

[segaloco via TUHS]

On Thursday, June 13th, 2024 at 9:47 AM, Arrigo Triulzi via TUHS <tuhs@tuhs.org> wrote:

> On 13 Jun 2024, at 17:39, Clem Cole clemc@ccc.com wrote:
> 
> > IMO systemd, was >>not<< a net positive - it falls so many of these tests WRT to good programming and good ideas.
> 
> 
> Binary logs, ’nuff said.
> 
> Good sysadmins live & die by grep and being able to visually detect departures from the norm by just looking at the “shape” of logs scrolling down a screen (before), terminal window now.
> 
> Yours disgusted since v1 of that abomination.
> 
> Arrigo

Part of what irks me is the lack of choice.  Just like many outlets will use GNU extensions to otherwise POSIX components, leaving the rest of the world out in the rain, several bits of the Linux ecosystem have backed systemd as the one true way and are hobbled if even usable at all with other init systems out there.  User software shouldn't have any attachment to a particular init system, it isn't meant to provide "services" beyond run this script at this time based on the conditions of boot, manage terminal lines, and maybe offer some runlevels to compartmentalize operating environments.  I've seen it said elsewhere that the amount of surface area being shoved into PID 1 can only lead to disaster.

Are there any known attempts in the modern age to roll Linux with something resembling research/BSD init?  That would be a nice counter to the proliferation of systemd.  Even if it doesn't make a dent in the actual uptake, at least it'd feel cathartic to have an alternative in the opposite direction.

- Matt G.

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

[Mychaela Falconia]

Matt G. wrote:

> Are there any known attempts in the modern age to roll Linux with something
> resembling research/BSD init?  That would be a nice counter to the
> proliferation of systemd.

I use Slackware and will never give it up.  It uses sysvinit, which
isn't as good as research/BSD init, but a helluvalot better than
systemd!  There is also Devuan, a sans-systemd fork of Debian, for
those who aren't hard-core enough to go full Slackware.

M~

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

[Ralph Corderoy]

Hi,

The Arch Linux wiki if often useful for non-Arch systems.  It has
details of alternative init systems to systemd, including s6 mentioned
elsewhere in the thread: https://wiki.archlinux.org/title/Init

-- 
Cheers, Ralph.

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

[Dan Cross]

On Thu, Jun 13, 2024 at 2:39 PM segaloco via TUHS <tuhs@tuhs.org> wrote:
> On Thursday, June 13th, 2024 at 9:47 AM, Arrigo Triulzi via TUHS <tuhs@tuhs.org> wrote:
> > On 13 Jun 2024, at 17:39, Clem Cole clemc@ccc.com wrote:
> > > IMO systemd, was >>not<< a net positive - it falls so many of these tests WRT to good programming and good ideas.
> >
> > Binary logs, ’nuff said.
> >
> > Good sysadmins live & die by grep and being able to visually detect departures from the norm by just looking at the “shape” of logs scrolling down a screen (before), terminal window now.
> >
> > Yours disgusted since v1 of that abomination.
>
> Part of what irks me is the lack of choice.  Just like many outlets will use GNU extensions to otherwise POSIX components, leaving the rest of the world out in the rain, several bits of the Linux ecosystem have backed systemd as the one true way and are hobbled if even usable at all with other init systems out there.  User software shouldn't have any attachment to a particular init system, it isn't meant to provide "services" beyond run this script at this time based on the conditions of boot, manage terminal lines, and maybe offer some runlevels to compartmentalize operating environments.  I've seen it said elsewhere that the amount of surface area being shoved into PID 1 can only lead to disaster.

I agree about the lack of choice, but I think the reasoning here shows
a bit of an impedance mismatch between what systemd is, and what
people think that it should be. In particular, it left merely being an
"init system" behind a long time ago, and is now the all-singing,
all-dancing service and resource management platform for the system.

That's not a terrible thing to have, if the goal of your system is to
be able to, well, run services and manage resources. But is systemd,
as an expression of that idea, a good thing? I don't really think so.
My arguments here tend to be somewhat vague, but I do believe that
there is valid criticism beyond just, "It's new! It's different! I
hate it!!" Portability is a good argument.

Where I think many of the arguments against systemd break down is by
dismissing the real problems that it solves; off the top of my head,
this may include automatically restarting dependent services when a
daemon crashes and is restarted. But again, just because a tool solves
a real problem doesn't mean that it's a good tool, or even a good tool
for solving that problem. I suspect much of the rush to systemd is
driven less by enthusiasm for how it does things, and more for it
being the only thing out there that solves some problem that the
distro maintainers consider important (ie, that they get asked about
frequently).

> Are there any known attempts in the modern age to roll Linux with something resembling research/BSD init?

Alpine Linux may come closest? And of course the BSDs still exist.

> That would be a nice counter to the proliferation of systemd.  Even if it doesn't make a dent in the actual uptake, at least it'd feel cathartic to have an alternative in the opposite direction.

There are still some Linux distributions that don't ship with systemd,
but I think they're just delaying the inevitable.

On a more meta point, there are big differences between production
server systems, user-oriented systems, and research systems. Systemd
feels very much like it comes from the first of those, to me; very
mainframe-y.

        - Dan C.

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

[Greg A. Woods]

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

At Thu, 13 Jun 2024 14:54:51 -0400, Dan Cross <crossd@gmail.com> wrote:
Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy'   The Register
> 
> I agree about the lack of choice,

Personally I don't see any lack of choice.  There are more than three
good BSD derived systems that together cover almost any imaginable set
of requirements.  The sheep will follow the herd though.....

> this may include automatically restarting dependent services when a
> daemon crashes and is restarted.

If your daemon's are crashing and in need of restarting so often that a
tool is needed to restart them then you have a myriad of other far more
pressing problems you should be dealing with first!

> being the only thing out there that solves some problem that the
> distro maintainers consider important (ie, that they get asked about
> frequently).

If it were so simple I would expect that claim to be more widely
advertised, yet we fall back on "it restarts daemons that crash".

Personally I think systemd trying to solve the rather high demands and
diverse requirements of mobile laptop systems and is trying to meet or
match MS Windows in this regard.  (personally I think macos has them
both beat by a country mile!)

It sure as heck isn't of any use in production server environments!

If it were more about servers then it would look more like SMF, or maybe
launchd, and it's code wouldn't look like it was written by a grade
school student.

-- 
					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: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Dan Cross]

On Thu, Jun 13, 2024 at 3:18 PM Greg A. Woods <woods@robohack.ca> wrote:
> [snip]
> > this may include automatically restarting dependent services when a
> > daemon crashes and is restarted.
>
> If your daemon's are crashing and in need of restarting so often that a
> tool is needed to restart them then you have a myriad of other far more
> pressing problems you should be dealing with first!

I may be in a bit of a grumpy mood, so forgive me if this is snarkier
than I intend, but statements like this bother me.

First, there are a number of reasons that programs crash in the real
world, in production environments. Often, the people in charge of
keeping them running are not the people who wrote the software;
nevermind that sometimes the reason for a crash has nothing to do with
the software itself; hardware soft-failures, for instance (that is,
where a momentary hardware blip kills a process on some machine but
isn't serious enough to drain the computer and reschedule the work
elsewhere; particularly where the OS can partition off a bad
component, such as a disk or a chunk of RAM or a CPU). When you
actually run systems at scale, you engineer them under an expectation
of failure and to be resilient. That means automatically restarting
services when they crash, among many other things.

Second, there are many reasons beyond just "lol it crashed" that you
may want to restart dependent services; for example, perhaps you are
upgrading a system and part of the upgrade process is restarting your
dependents. Having a system that does things like that for you is
useful.

> > being the only thing out there that solves some problem that the
> > distro maintainers consider important (ie, that they get asked about
> > frequently).
>
> If it were so simple I would expect that claim to be more widely
> advertised, yet we fall back on "it restarts daemons that crash".

See above.

> Personally I think systemd trying to solve the rather high demands and
> diverse requirements of mobile laptop systems and is trying to meet or
> match MS Windows in this regard.  (personally I think macos has them
> both beat by a country mile!)
>
> It sure as heck isn't of any use in production server environments!

That's not an argument, it's an assertion, and one that isn't well supported.

> If it were more about servers then it would look more like SMF, or maybe
> launchd, and it's code wouldn't look like it was written by a grade
> school student.

Sorry, but this is exactly the sort of overly dismissive attitude that
I was referring to earlier. You undermine your own argument by
mentioning SMF (which can automatically restart services when the
crash), for example.

        - Dan C.

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

[Greg A. Woods]

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

At Thu, 13 Jun 2024 16:03:30 -0400, Dan Cross <crossd@gmail.com> wrote:
Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register
> 
> On Thu, Jun 13, 2024 at 3:18 PM Greg A. Woods <woods@robohack.ca> wrote:
> > [snip]
> > If it were more about servers then it would look more like SMF, or maybe
> > launchd, and it's code wouldn't look like it was written by a grade
> > school student.
> 
> Sorry, but this is exactly the sort of overly dismissive attitude that
> I was referring to earlier. You undermine your own argument by
> mentioning SMF (which can automatically restart services when the
> crash), for example.

No, that's exactly my point!

SMF isn't the anywhere near the nearly-bootable monster systemd seems to
be, and it isn't filled with grade-school-level code, and it _is_
written much more in keeping with the Unix tool philosophy.  It manages
services, it does it in a well defined and predictable way, and it
doesn't try to take over the universe.

Launchd isn't quite so clean and Unix-like, but it's still a well
designed more-or-less single-purpose tool!  (Albeit one with a rather
wide set of specifications.)  Some of Apples other "frameworks" tend to
look a bit more like some of systemd, but that's different part of the
problem.

-- 
					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: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Grant Taylor via TUHS]

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

On 6/13/24 15:03, Dan Cross wrote:
> I may be in a bit of a grumpy mood, so forgive me if this is snarkier 
> than I intend, but statements like this bother me.

;-)

> Second, there are many reasons beyond just "lol it crashed" that 
> you may want to restart dependent services; for example, perhaps you 
> are upgrading a system and part of the upgrade process is restarting 
> your dependents. Having a system that does things like that for you 
> is useful.

It's my understanding that systemd as a service lifecycle manager is 
starting to take on some aspects of what cluster service managers used 
to do.  E.g.

  - Are all the other dependencies this service needs up and running -> 
is it okay to start this service on this system?

  - Is the service running and responding like it should be?  -> 
periodically check to make sure the system is returning expected 
results; is DNS answering queries / can I send a test email

  - Stop the service when it's operating outside acceptable parameters 
(read: failing).

  - Notify other related services that this service has been stopped.

I'm anti-systemd *cough*Master Control Program*cough* and it's 
associated suite of utilities for many reasons.  But I've come to accept 
that systemd is not just an init system.  It's role of a service life 
cycle manager is a superset of what an init system does.  It's a 
relatively new world (at least comparatively).

I also have seriouis doubts about systemd's stability as a services life 
cycle manager.  I've seen too many times when systems get into a wedged 
state that require a power fail / reset (or sys request if enabled) to 
recover.

I've seen too many times when a systemd based system won't shut down 
because of some circular configuration it's gotten itself into.  Without 
the complication of NFS servers being unreachable after taking down the 
network.



--
Grant. . . .

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4033 bytes --]

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

[Alexis]

Grant Taylor via TUHS <tuhs@tuhs.org> writes:

> I'm anti-systemd *cough*Master Control Program*cough* and it's
> associated suite of utilities for many reasons.  But I've come 
> to
> accept that systemd is not just an init system.  It's role of a
> service life cycle manager is a superset of what an init system 
> does.
> It's a relatively new world (at least comparatively).

Indeed: it doesn't just do init, but also _service supervision_ 
(making sure that a service that _should_ be up, _is_ up) and 
_service management_ (enabling, disabling, starting, stopping, 
dependencies, etc.). Hence why phrases like "the init wars" are 
such a misnomer.

As described in the potted history outlined in the "known problems 
with System 5 rc" article i linked to upthread, Sys V rc's issues 
with service supervision and service management have been known 
for decades:

> In 1999, Luke Mewburn worked on replacing the /etc/rc system in 
> NetBSD. netbsd.tech.userlevel mailing list discussions from the 
> time show several criticisms of the System 5 rc and System 5 
> init systems, and encouragement not to repeat their mistakes in 
> the BSD world. The resultant rc.d system was roughly 
> contemporary with Daniel Robbins producing OpenRC, another 
> System 5 rc replacement that replaced the (Bourne/Bourne Again) 
> shell with a different script interpreter, nowadays named 
> /sbin/openrc, that provided a whole lot of standard service 
> management functionality as pre-supplied functions. The NetBSD 
> rc.d system likewise reduced rc.d scripts to a few variable 
> assignments and function calls (in about two thirds of cases). 

The initial release of OpenRC - still Gentoo's 'native' system for 
service management - was in April 2007; the initial release of 
systemd was in March 2010. But although both OpenRC and systemd 
address various pain points of Sys V rc on Linux, systemd has 
_also_ had the backing of an 800-pound gorilla in the Linux world 
- Red Hat - which has _implicitly_ forced its adoption over 
alternatives by distros that don't have the same level of 
resources behind them.

Here's an excerpt from something i wrote on the Gentoo forum back 
in April:

> There's been so much anger and vitriol expressed about 
> systemd. Has that significantly slowed the systemd juggernaut? 
> Not really. Not least because, as in the case of D-Bus, and as 
> in the case of Wayland, it addresses very real issues for 
> significant numbers of people.
>
> For example: unlike on, say, OpenBSD, which has developed a 
> pretty clean shell-script-based service management system, with 
> a 'standard library' in the form of rc.subr(8), the situation on 
> Linux was a mess. Many of the (usually volunteers) who maintain 
> packages for Linux don't want to have to learn the complexities 
> of shell scripting and the subtle issues that can arise, or 
> develop and maintain workarounds for race conditions, and so 
> on. systemd comes along and says: "Hey, with systemd, you'll be 
> able to write service definitions declaratively; you won't need 
> to wrangle shell scripts." That's a pretty attractive 
> proposition to a number of package maintainers, and in the 
> absence of systemd alternatives explicitly providing such an 
> interface - not just saying "oh that could be done on our 
> alternative" - those maintainers are going to be inclined 
> towards systemd, regardless of what design and implementation 
> issues are involved in systemd's approach.
>
> So in wanting to try to ensure that myself and others have 
> choices and alternatives available, i feel that ranting against 
> the incoming tide, like a tech King Cnut, is typically far less 
> effective than actually putting in the work to develop and 
> support those choices and alternatives. 


Alexis.

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

[Greg A. Woods]

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

At Sun, 16 Jun 2024 15:48:15 +1000, Alexis <flexibeast@gmail.com> wrote:
Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register
>
> Here's an excerpt from something i wrote
> on the Gentoo forum back in April:
>
> > [[...]] the situation on
> > Linux was a mess. Many of the (usually
> > volunteers) who maintain packages for
> > Linux don't want to have to learn the
> > complexities of shell scripting and the
> > subtle issues that can arise

That pretty much says it all about the state of the GNU/linux world
right there.

In the "Unix world" everyone learns shell scripting, some better than
others of course, and some hate it at the same time too, but I would say
from my experience it's a given.  You either learn shell scripting or
you are "just a user" (even if you also write application code).

--
					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: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Clem Cole]

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

On Sun, Jun 16, 2024 at 2:50 PM Greg A. Woods <woods@robohack.ca> wrote:

> In the "Unix world" everyone learns shell scripting, some better than
> others of course, and some hate it at the same time too, but I would say
> from my experience it's a given.  You either learn shell scripting or
> you are "just a user" (even if you also write application code).
>
Side story - I think you can tell a lot about a person by what is on their
bookshelf at work and what books they have read.

A few years ago, I discovered this same flaw in using UNIX (Linux) well
with some of the new hires (from really good schools, too), and it was
worse because they often had never seen the true Bourne shell (nor knew
much/anything about Algol, much less A68).  Many thought "bash" was the
UNIX shell because they never knew better (chuckle).   I realized it was a
huge hole in their education, so I got my admin to order each copies of
K&R2 and UPE for their desks.   I said I expected them to do the
exercises in them as part of their "training." I could usually tell a lot
about each person by the questions they asked during that period. Many
often griped about having to learn to use ed and nroff.  I think those that
were already EMACS folks thought I was a little bonkers but my comment was
that you'll understand the other tools better/be a lot more effective with
the shell in particular. Many had seen Latex, so the >>idea<< of a document
compiler was not always completely foreign.  But they crawled through each
book.

But it was interesting when it was done. To a person, they all said they
were much better with the UNIX tool kit after UPE, and because they
actually read K&R2, they often learned a few things about C they never
realized.  Once they "graduated" also I gave them a copy of APUE, if they
were doing networking stuff, UNP too.  Most would start doing the APUE and
UNP problems also as I would get some of them coming to my office with
questions, but I never said they had to do them.

Clem
ᐧ

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

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

[Peter Yardley]

Algol has been a dead language for many years, for good reasons too.

> On 17 Jun 2024, at 5:44 AM, Clem Cole <clemc@ccc.com> wrote:
> 
> 
> 
> On Sun, Jun 16, 2024 at 2:50 PM Greg A. Woods <woods@robohack.ca> wrote:
> In the "Unix world" everyone learns shell scripting, some better than
> others of course, and some hate it at the same time too, but I would say
> from my experience it's a given.  You either learn shell scripting or
> you are "just a user" (even if you also write application code).
> Side story - I think you can tell a lot about a person by what is on their bookshelf at work and what books they have read.
> 
> A few years ago, I discovered this same flaw in using UNIX (Linux) well with some of the new hires (from really good schools, too), and it was worse because they often had never seen the true Bourne shell (nor knew much/anything about Algol, much less A68).  Many thought "bash" was the UNIX shell because they never knew better (chuckle).   I realized it was a huge hole in their education, so I got my admin to order each copies of K&R2 and UPE for their desks.   I said I expected them to do the exercises in them as part of their "training." I could usually tell a lot about each person by the questions they asked during that period. Many often griped about having to learn to use ed and nroff.  I think those that were already EMACS folks thought I was a little bonkers but my comment was that you'll understand the other tools better/be a lot more effective with the shell in particular. Many had seen Latex, so the >>idea<< of a document compiler was not always completely foreign.  But they crawled through each book.
> 
> But it was interesting when it was done. To a person, they all said they were much better with the UNIX tool kit after UPE, and because they actually read K&R2, they often learned a few things about C they never realized.  Once they "graduated" also I gave them a copy of APUE, if they were doing networking stuff, UNP too.  Most would start doing the APUE and UNP problems also as I would get some of them coming to my office with questions, but I never said they had to do them.
> 
> Clem
> ᐧ

Peter Yardley
peter.martin.yardley@gmail.com

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

[Clem Cole]

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

Except A68 is the core of Bourne Shell. Truth is original Algol’s DNA  -
much less A68 - lived on in most programming languages we use today.  Not
knowing anything about both puts you at a huge disadvantage.

Linux at its core is the Unix ideas (core IP) not the source code.  Trying
to rid it of so called “bad ideas” shows how little respect those taking
such actions have. In others word, their taste is rather disappointing if
not out right poor.

Frankly my major complaint with much of the modern world is that when we
ignore the past and we are cursed for forgetting its lessons.  As had been
said many times before, we are better served when we stand on the shoulders
of great people rather than stepping on their toes.

This discussion wrt the systemd is a prefect example.

Sent from a handheld expect more typos than usual


On Sun, Jun 16, 2024 at 8:11 PM Peter Yardley <
peter.martin.yardley@gmail.com> wrote:

> Algol has been a dead language for many years, for good reasons too.
>
> > On 17 Jun 2024, at 5:44 AM, Clem Cole <clemc@ccc.com> wrote:
> >
> >
> >
> > On Sun, Jun 16, 2024 at 2:50 PM Greg A. Woods <woods@robohack.ca> wrote:
> > In the "Unix world" everyone learns shell scripting, some better than
> > others of course, and some hate it at the same time too, but I would say
> > from my experience it's a given.  You either learn shell scripting or
> > you are "just a user" (even if you also write application code).
> > Side story - I think you can tell a lot about a person by what is on
> their bookshelf at work and what books they have read.
> >
> > A few years ago, I discovered this same flaw in using UNIX (Linux) well
> with some of the new hires (from really good schools, too), and it was
> worse because they often had never seen the true Bourne shell (nor knew
> much/anything about Algol, much less A68).  Many thought "bash" was the
> UNIX shell because they never knew better (chuckle).   I realized it was a
> huge hole in their education, so I got my admin to order each copies of
> K&R2 and UPE for their desks.   I said I expected them to do the exercises
> in them as part of their "training." I could usually tell a lot about each
> person by the questions they asked during that period. Many often griped
> about having to learn to use ed and nroff.  I think those that were already
> EMACS folks thought I was a little bonkers but my comment was that you'll
> understand the other tools better/be a lot more effective with the shell in
> particular. Many had seen Latex, so the >>idea<< of a document compiler was
> not always completely foreign.  But they crawled through each book.
> >
> > But it was interesting when it was done. To a person, they all said they
> were much better with the UNIX tool kit after UPE, and because they
> actually read K&R2, they often learned a few things about C they never
> realized.  Once they "graduated" also I gave them a copy of APUE, if they
> were doing networking stuff, UNP too.  Most would start doing the APUE and
> UNP problems also as I would get some of them coming to my office with
> questions, but I never said they had to do them.
> >
> > Clem
> > ᐧ
>
> Peter Yardley
> peter.martin.yardley@gmail.com
>
>

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

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

[Alexis]

"Greg A. Woods" <woods@robohack.ca> writes:

> At Sun, 16 Jun 2024 15:48:15 +1000, Alexis 
> <flexibeast@gmail.com>
> wrote:
> Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix
> philosophy' The Register
>>
>> Here's an excerpt from something i wrote
>> on the Gentoo forum back in April:
>>
>> > [[...]] the situation on
>> > Linux was a mess. Many of the (usually
>> > volunteers) who maintain packages for
>> > Linux don't want to have to learn the
>> > complexities of shell scripting and the
>> > subtle issues that can arise
>
> That pretty much says it all about the state of the GNU/linux 
> world
> right there.
>
> In the "Unix world" everyone learns shell scripting, some better 
> than
> others of course, and some hate it at the same time too, but I 
> would
> say
> from my experience it's a given.  You either learn shell 
> scripting or
> you are "just a user" (even if you also write application code).

i feel this comment is unfair.

The specific thing i wrote was:

> the _complexities_ of shell scripting and the _subtle issues_ 
> that can arise

[emphasis added]

The issue isn't about learning shell scripting _per se_. It's 
about the extent to which _volunteers_ have to go beyond the 
_basics_ of shell scripting to learn about the _complexities_ and 
_subtle issues_ involved in using it to provide _robust_ service 
management. Including learning, for example, that certain 
functionality one takes for granted in a given shell isn't 
actually POSIX, and can't be assumed to be present in the shell 
one is working with (not to mention that POSIX-compatibility might 
need to be actively enabled, as in the case of e.g. ksh, via 
POSIXLY_CORRECT).

Here's a FreeBSD thread from 2014, about how service(8) wasn't 
providing the same environment to scripts that boot did:

  https://lists.freebsd.org/pipermail/svn-src-head/2014-July/060519.html

i'm a BSD user as well as a Linux user - i've been maintaining 
OpenBSD servers for several years. i certainly have my own 
criticisms of Linux versus OpenBSD - for example, i'm, mm, 'not a 
fan' of the somewhat cavalier attitude towards documentation that 
can often be found in the Linux world, so i'm grateful for people 
like Alejandro Colomar and his extensive work on the Linux 
man-pages project. But i feel the above thread suggests that 
either the FreeBSD devs are clueless about shell scripting or - as 
i feel is actually the case - that service management via shell 
scripting isn't as straightforward as one might assume.


Alexis.

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

[Warner Losh]

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

On Sun, Jun 16, 2024, 7:01 PM Alexis <flexibeast@gmail.com> wrote:

> "Greg A. Woods" <woods@robohack.ca> writes:
>
> > At Sun, 16 Jun 2024 15:48:15 +1000, Alexis
> > <flexibeast@gmail.com>
> > wrote:
> > Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix
> > philosophy' The Register
> >>
> >> Here's an excerpt from something i wrote
> >> on the Gentoo forum back in April:
> >>
> >> > [[...]] the situation on
> >> > Linux was a mess. Many of the (usually
> >> > volunteers) who maintain packages for
> >> > Linux don't want to have to learn the
> >> > complexities of shell scripting and the
> >> > subtle issues that can arise
> >
> > That pretty much says it all about the state of the GNU/linux
> > world
> > right there.
> >
> > In the "Unix world" everyone learns shell scripting, some better
> > than
> > others of course, and some hate it at the same time too, but I
> > would
> > say
> > from my experience it's a given.  You either learn shell
> > scripting or
> > you are "just a user" (even if you also write application code).
>
> i feel this comment is unfair.
>
> The specific thing i wrote was:
>
> > the _complexities_ of shell scripting and the _subtle issues_
> > that can arise
>
> [emphasis added]
>
> The issue isn't about learning shell scripting _per se_. It's
> about the extent to which _volunteers_ have to go beyond the
> _basics_ of shell scripting to learn about the _complexities_ and
> _subtle issues_ involved in using it to provide _robust_ service
> management. Including learning, for example, that certain
> functionality one takes for granted in a given shell isn't
> actually POSIX, and can't be assumed to be present in the shell
> one is working with (not to mention that POSIX-compatibility might
> need to be actively enabled, as in the case of e.g. ksh, via
> POSIXLY_CORRECT).
>
> Here's a FreeBSD thread from 2014, about how service(8) wasn't
> providing the same environment to scripts that boot did:
>
>   https://lists.freebsd.org/pipermail/svn-src-head/2014-July/060519.html
>
> i'm a BSD user as well as a Linux user - i've been maintaining
> OpenBSD servers for several years. i certainly have my own
> criticisms of Linux versus OpenBSD - for example, i'm, mm, 'not a
> fan' of the somewhat cavalier attitude towards documentation that
> can often be found in the Linux world, so i'm grateful for people
> like Alejandro Colomar and his extensive work on the Linux
> man-pages project. But i feel the above thread suggests that
> either the FreeBSD devs are clueless about shell scripting or - as
> i feel is actually the case - that service management via shell
> scripting isn't as straightforward as one might assume.
>

"Exactly the same" turned out to be harder than one would naively assume.
That thread, and others like it elsewhere, hammered out what the
differences were and how to fix them. The thread you found is the internal
one used to point out issues from changes made... and was 10 years ago...

FreeBSD developers, as a whole, are quite adept at shell acripting and the
myriad of subtle issues around it. Every time I've committed something that
missed one or more of the relevant ones,  I've got email.... sometimes,
though, it takes a village to know all the subtly in play. It's been 25 or
more years since it all could be done by one brilliant person...

Warner


Alexis.
>

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

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

[Larry McVoy]

On Mon, Jun 17, 2024 at 11:01:40AM +1000, Alexis wrote:
> "Greg A. Woods" <woods@robohack.ca> writes:
> 
> >At Sun, 16 Jun 2024 15:48:15 +1000, Alexis <flexibeast@gmail.com>
> >wrote:
> >Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix
> >philosophy' The Register
> >>
> >>Here's an excerpt from something i wrote
> >>on the Gentoo forum back in April:
> >>
> >>> [[...]] the situation on
> >>> Linux was a mess. Many of the (usually
> >>> volunteers) who maintain packages for
> >>> Linux don't want to have to learn the
> >>> complexities of shell scripting and the
> >>> subtle issues that can arise
> >
> >That pretty much says it all about the state of the GNU/linux world
> >right there.
> >
> >In the "Unix world" everyone learns shell scripting, some better than
> >others of course, and some hate it at the same time too, but I would
> >say
> >from my experience it's a given.  You either learn shell scripting or
> >you are "just a user" (even if you also write application code).
> 
> i feel this comment is unfair.
> 
> The specific thing i wrote was:
> 
> >the _complexities_ of shell scripting and the _subtle issues_ that can
> >arise
> 
> [emphasis added]
> 
> The issue isn't about learning shell scripting _per se_. It's about the
> extent to which _volunteers_ have to go beyond the _basics_ of shell
> scripting to learn about the _complexities_ and _subtle issues_ involved in
> using it to provide _robust_ service management. Including learning, for
> example, that certain functionality one takes for granted in a given shell
> isn't actually POSIX, and can't be assumed to be present in the shell one is
> working with (not to mention that POSIX-compatibility might need to be
> actively enabled, as in the case of e.g. ksh, via POSIXLY_CORRECT).

This is sort of off topic but maybe relevant.

When I was running my company, my engineers joked that if it were invented
after 1980 I wouldn't let them use it.  Which wasn't true, we used mmap().

But the underlying sentiment sort of was true.  Even though they were
all used to bash, I tried very hard to not use bash specific stuff.
And it paid off, in our hey day, we supported SCO, AIX, HPUX, SunOS,
Solaris, Tru64, Linux on every architecture from tin to IBM mainframes,
Windows, Macos on PPC and x86, etc.  And probably a bunch of other
platforms I've forgotten.

*Every* time they used some bash-ism, it bit us in the ass.  I kept
telling them "our build environment is not our deployment environment".
We had a bunch of /bin/sh stuff that we shipped so we had to go for 
the common denominator.

I did relax things to allow GNU Make, there were some features that they
really wanted and that is build environment, so, shrug.

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

[Warner Losh]

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

On Sun, Jun 16, 2024, 7:25 PM Larry McVoy <lm@mcvoy.com> wrote:

> On Mon, Jun 17, 2024 at 11:01:40AM +1000, Alexis wrote:
> > "Greg A. Woods" <woods@robohack.ca> writes:
> >
> > >At Sun, 16 Jun 2024 15:48:15 +1000, Alexis <flexibeast@gmail.com>
> > >wrote:
> > >Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix
> > >philosophy' The Register
> > >>
> > >>Here's an excerpt from something i wrote
> > >>on the Gentoo forum back in April:
> > >>
> > >>> [[...]] the situation on
> > >>> Linux was a mess. Many of the (usually
> > >>> volunteers) who maintain packages for
> > >>> Linux don't want to have to learn the
> > >>> complexities of shell scripting and the
> > >>> subtle issues that can arise
> > >
> > >That pretty much says it all about the state of the GNU/linux world
> > >right there.
> > >
> > >In the "Unix world" everyone learns shell scripting, some better than
> > >others of course, and some hate it at the same time too, but I would
> > >say
> > >from my experience it's a given.  You either learn shell scripting or
> > >you are "just a user" (even if you also write application code).
> >
> > i feel this comment is unfair.
> >
> > The specific thing i wrote was:
> >
> > >the _complexities_ of shell scripting and the _subtle issues_ that can
> > >arise
> >
> > [emphasis added]
> >
> > The issue isn't about learning shell scripting _per se_. It's about the
> > extent to which _volunteers_ have to go beyond the _basics_ of shell
> > scripting to learn about the _complexities_ and _subtle issues_ involved
> in
> > using it to provide _robust_ service management. Including learning, for
> > example, that certain functionality one takes for granted in a given
> shell
> > isn't actually POSIX, and can't be assumed to be present in the shell
> one is
> > working with (not to mention that POSIX-compatibility might need to be
> > actively enabled, as in the case of e.g. ksh, via POSIXLY_CORRECT).
>
> This is sort of off topic but maybe relevant.
>
> When I was running my company, my engineers joked that if it were invented
> after 1980 I wouldn't let them use it.  Which wasn't true, we used mmap().
>
> But the underlying sentiment sort of was true.  Even though they were
> all used to bash, I tried very hard to not use bash specific stuff.
> And it paid off, in our hey day, we supported SCO, AIX, HPUX, SunOS,
> Solaris, Tru64, Linux on every architecture from tin to IBM mainframes,
> Windows, Macos on PPC and x86, etc.  And probably a bunch of other
> platforms I've forgotten.
>
> *Every* time they used some bash-ism, it bit us in the ass.  I kept
> telling them "our build environment is not our deployment environment".
> We had a bunch of /bin/sh stuff that we shipped so we had to go for
> the common denominator.
>

The fallout of the Unix Wars was that this denominator was kept too low for
too long.

Warner

I did relax things to allow GNU Make, there were some features that they
> really wanted and that is build environment, so, shrug.
>

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

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

[Stuff Received]

On 2024-06-16 21:25, Larry McVoy wrote (in part):
[...]
> *Every* time they used some bash-ism, it bit us in the ass.

This is so true for a lot of OS projects (on Github, for example).  Most 
-- sometimes all -- the scripts that start with /bin/sh but are full of 
bashisms because the authors run systems where /bin/sh is really bash.

S.

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

[Larry McVoy]

On Mon, Jun 17, 2024 at 03:21:47PM -0400, Stuff Received wrote:
> On 2024-06-16 21:25, Larry McVoy wrote (in part):
> [...]
> >*Every* time they used some bash-ism, it bit us in the ass.
> 
> This is so true for a lot of OS projects (on Github, for example).  Most --
> sometimes all -- the scripts that start with /bin/sh but are full of
> bashisms because the authors run systems where /bin/sh is really bash.

I think it is less of an issue these days, it's mostly Windows, MacOS,
Linux and bash is available there.

That said, anything I care about is v7 compat.  No need to get fancy,
if I need fancy, there is C.
-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

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

[Steve Nickolas]

On Mon, 17 Jun 2024, Stuff Received wrote:

> On 2024-06-16 21:25, Larry McVoy wrote (in part):
> [...]
>> *Every* time they used some bash-ism, it bit us in the ass.
>
> This is so true for a lot of OS projects (on Github, for example).  Most -- 
> sometimes all -- the scripts that start with /bin/sh but are full of bashisms 
> because the authors run systems where /bin/sh is really bash.

Which is why I'm glad Debian's /bin/sh is dash (fork of ash) instead.

-uso.

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

[Greg A. Woods]

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

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.

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.

--
					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: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Warner Losh]

[-- 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 --]

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

[Larry McVoy]

On Mon, Jun 17, 2024 at 05:44:40PM -0600, Warner Losh wrote:
> 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.

I've said before, and I'll say it again.  The BSD community couldn't decide
who was going to drive the big red fire truck.  Instead of doing that, they
each took their own toy fire truck and we have the vision of grown men
driving around on toy trucks.

All while the Linux community let Linus drive.

The results speak for themselves, we've got Android Linux on a zillion
cell phones, I believe all of the top 500 super computers are Linux,
Linux even has some use on the desktop.

BSD has what?  MacOS but that's a closed off fork, it's not helping
BSD in any way other than marketing.

It's sad, I started out as a BSD/Sun guy and loved it.  But when the
forks happened I could see the writing on the wall and went over to
Linux.

Shoulda, coulda, woulda (again).

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

[Greg A. Woods]

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

At Mon, 17 Jun 2024 17:44:40 -0600, Warner Losh <imp@bsdimp.com> wrote:
Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register
>
> ....  There was no upstream
> anymore. Csrg was gone, and all successor BSD projects assumed they were
> the new upstream.

Hmmm.... I never really thought of it that way before!

I guess I had hoped everyone would come to realize a new
one-size-fits-all upstream would be a "good thing", or
perhaps even a necessity, and that none would automatically
slip into thinking they were it without first reaching some
consensus with other projects -- at least between NetBSD
and FreeBSD for starters (and I suppose all hope of this had
long evaporated before any of the other off-shoots formed).

> 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...

Indeed!

--
					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: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[David Arnold]

> On 19 Jun 2024, at 08:44, Greg A. Woods <woods@robohack.ca> wrote:
> 
> At Mon, 17 Jun 2024 17:44:40 -0600, Warner Losh <imp@bsdimp.com> wrote:
> Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register
>> 
>> ....  There was no upstream
>> anymore. Csrg was gone, and all successor BSD projects assumed they were
>> the new upstream.
> 
> Hmmm.... I never really thought of it that way before!
> 
> I guess I had hoped everyone would come to realize a new
> one-size-fits-all upstream would be a "good thing", or
> perhaps even a necessity, and that none would automatically
> slip into thinking they were it without first reaching some
> consensus with other projects

A somewhat similar thing has happened with Plan9.

There are multiple “successor” projects, some basically single-person projects, others semi-official with legal structure, others larger groups of like-minded developers.

The are high levels of acrimony between the groups, and no accepted processes for evolving together.

Periodically, some naive passerby will suggest a common core repository, perhaps even using a popular technology, and they’ll get barbecued in the resulting flamefest. 

So it goes. 



d

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

[Steve Nickolas]

On Sun, 16 Jun 2024, Greg A. Woods wrote:

> At Mon, 17 Jun 2024 18:34:06 -0400 (EDT), Steve Nickolas <usotsuki@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.

[TUHS] Re: 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@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@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.

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

[Greg A. Woods]

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

At Tue, 18 Jun 2024 04:52:51 +0000, segaloco via TUHS <tuhs@tuhs.org> wrote:
Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register
>
> That's not
> to diminish the real help of things like autotools and CMake,

Oh, that strikes a nerve.

CMake is the very antithesis of a good tool.  It doesn't help.  I think
it is perhaps the worst abomination EVER in the world of software tools,
and especially amongst software construction tools.

--
					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: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Warner Losh]

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

On Tue, Jun 18, 2024, 4:50 PM Greg A. Woods <woods@robohack.ca> wrote:

> At Tue, 18 Jun 2024 04:52:51 +0000, segaloco via TUHS <tuhs@tuhs.org>
> wrote:
> Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix
> philosophy' The Register
> >
> > That's not
> > to diminish the real help of things like autotools and CMake,
>
> Oh, that strikes a nerve.
>
> CMake is the very antithesis of a good tool.  It doesn't help.  I think
> it is perhaps the worst abomination EVER in the world of software tools,
> and especially amongst software construction tools.
>

Someone clearly never used imake...

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: 1890 bytes --]

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

[ron minnich]

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

but it rhymes with mistake!

On Tue, Jun 18, 2024 at 4:12 PM Warner Losh <imp@bsdimp.com> wrote:

>
>
> On Tue, Jun 18, 2024, 4:50 PM Greg A. Woods <woods@robohack.ca> wrote:
>
>> At Tue, 18 Jun 2024 04:52:51 +0000, segaloco via TUHS <tuhs@tuhs.org>
>> wrote:
>> Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix
>> philosophy' The Register
>> >
>> > That's not
>> > to diminish the real help of things like autotools and CMake,
>>
>> Oh, that strikes a nerve.
>>
>> CMake is the very antithesis of a good tool.  It doesn't help.  I think
>> it is perhaps the worst abomination EVER in the world of software tools,
>> and especially amongst software construction tools.
>>
>
> Someone clearly never used imake...
>
> 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: 2318 bytes --]

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

[Greg 'groggy' Lehey]

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

On Tuesday, 18 June 2024 at 17:03:07 -0600, Warner Losh wrote:
> On Tue, Jun 18, 2024, 4:50 PM Greg A. Woods <woods@robohack.ca> wrote:
>>
>> CMake is the very antithesis of a good tool.  It doesn't help.  I think
>> it is perhaps the worst abomination EVER in the world of software tools,
>> and especially amongst software construction tools.
>
> Someone clearly never used imake...

I've used both.  I'm with Greg (Woods): cmake takes the cake.

Greg
--
Sent from my desktop computer.
Finger grog@lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA.php

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Warner Losh]

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

On Tue, Jun 18, 2024, 7:38 PM Greg 'groggy' Lehey <grog@lemis.com> wrote:

> On Tuesday, 18 June 2024 at 17:03:07 -0600, Warner Losh wrote:
> > On Tue, Jun 18, 2024, 4:50 PM Greg A. Woods <woods@robohack.ca> wrote:
> >>
> >> CMake is the very antithesis of a good tool.  It doesn't help.  I think
> >> it is perhaps the worst abomination EVER in the world of software tools,
> >> and especially amongst software construction tools.
> >
> > Someone clearly never used imake...
>
> I've used both.  I'm with Greg (Woods): cmake takes the cake.
>

Cmake actually works though...

Warner


Greg
> --
> Sent from my desktop computer.
> Finger grog@lemis.com for PGP public key.
> See complete headers for address and phone numbers.
> This message is digitally signed.  If your Microsoft mail program
> reports problems, please read http://lemis.com/broken-MUA.php
>

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

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

[Greg A. Woods]

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

At Tue, 18 Jun 2024 19:42:59 -0600, Warner Losh <imp@bsdimp.com> wrote:
Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register
> 
> On Tue, Jun 18, 2024, 7:38 PM Greg 'groggy' Lehey <grog@lemis.com> wrote:
> 
> > On Tuesday, 18 June 2024 at 17:03:07 -0600, Warner Losh wrote:
> > > On Tue, Jun 18, 2024, 4:50 PM Greg A. Woods <woods@robohack.ca> wrote:
> > >>
> > >> CMake is the very antithesis of a good tool.  It doesn't help.  I think
> > >> it is perhaps the worst abomination EVER in the world of software tools,
> > >> and especially amongst software construction tools.
> > >
> > > Someone clearly never used imake...
> >
> > I've used both.  I'm with Greg (Woods): cmake takes the cake.
> >
> 
> Cmake actually works though...

Well, maybe, sometimes, for some limited set of pre-tested targets.
Which was true for imake as well, but....


Last time I had to use cmake it took significantly longer to build the
monster than it did to build the entire current-at-the-time GCC release.

When it runs it usually chews through far more CPU cycles and requires
far more RAM than the equivalent Autotools configure script, even
including running autoconf et al to build the script first.

Its design and implementation ignores the entire history and legacy and
knowledge bank of existing tools and lore used to build portable
software and throws the one or two existing tools it does pay homage to
in your face to spite you.  It couldn't ignore Unix philosophy harder
and more completely than it does.

For example it can't generate a working makefile or script that can then
be used without it!  At least I couldn't convince it to do so.

At the time I was hacking on a project that claimed to require it, it
couldn't even properly parse a string and had trouble with parenthesis.
I don't remember the details, but it was very ugly and required stupidly
obtuse and self-limiting workarounds.

I used to think libtool was the worst software construction tool
imagined (well worse than the rest of Autotools), but cmake is many
orders of magnitude worse.

I will not ever allow cmake to run, or even exist, on the machines I
control.  Sometimes some tools are just too dangerous to have in the
house or workshop, no matter how handy others claim they might be.
Using cmake is like _forcing_ you to use a flame thrower to light your
portable gas barbecue at a camp site in a tinder-dry forest.  Inevitably
someone or something is going to get hurt/destroyed.

Sorry, cmake is a hot button for me, as you can see.

-- 
					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: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Scot Jenkins via TUHS]

"Greg A. Woods" <woods@robohack.ca> wrote:

> I will not ever allow cmake to run, or even exist, on the machines I
> control...

I'm not a fan of cmake either.  

How do you deal with software that only builds with cmake (or meson,
scons, ... whatever the developer decided to use as the build tool)?  
What alternatives exist short of reimplementing the build process in 
a standard makefile by hand, which is obviously very time consuming,
error prone, and will probably break the next time you want to update
a given package?

If there is some great alternative, I would like to know about it.

scot

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

[Luther Johnson]

I just avoid tools that build with CMake altogether, I look for
alternative tools. The tool has already told me, what I can expect from
a continued relationship, by its use of CMake ...

On 06/19/2024 10:01 PM, Scot Jenkins via TUHS wrote:
> "Greg A. Woods" <woods@robohack.ca> wrote:
>
>> I will not ever allow cmake to run, or even exist, on the machines I
>> control...
> I'm not a fan of cmake either.
>
> How do you deal with software that only builds with cmake (or meson,
> scons, ... whatever the developer decided to use as the build tool)?
> What alternatives exist short of reimplementing the build process in
> a standard makefile by hand, which is obviously very time consuming,
> error prone, and will probably break the next time you want to update
> a given package?
>
> If there is some great alternative, I would like to know about it.
>
> scot
>

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

[Luther Johnson]

That being said, I must confess there is a very smll number of tools I
use, which I build from source, keep up with patches and updates for,
etc. I don't have the same problems as a sysadmin for a large community
using many open source projects, those issues are real but since I'm
only supporting my opinionated self, I have the luxury of choosing
software that meets my approval.

On 06/19/2024 10:09 PM, Luther Johnson wrote:
> I just avoid tools that build with CMake altogether, I look for
> alternative tools. The tool has already told me, what I can expect from
> a continued relationship, by its use of CMake ...
>
> On 06/19/2024 10:01 PM, Scot Jenkins via TUHS wrote:
>> "Greg A. Woods" <woods@robohack.ca> wrote:
>>
>>> I will not ever allow cmake to run, or even exist, on the machines I
>>> control...
>> I'm not a fan of cmake either.
>>
>> How do you deal with software that only builds with cmake (or meson,
>> scons, ... whatever the developer decided to use as the build tool)?
>> What alternatives exist short of reimplementing the build process in
>> a standard makefile by hand, which is obviously very time consuming,
>> error prone, and will probably break the next time you want to update
>> a given package?
>>
>> If there is some great alternative, I would like to know about it.
>>
>> scot
>>
>
>

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

[Greg A. Woods]

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

At Thu, 20 Jun 2024 01:01:01 -0400, Scot Jenkins via TUHS <tuhs@tuhs.org> wrote:
Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register
>
> "Greg A. Woods" <woods@robohack.ca> wrote:
>
> > I will not ever allow cmake to run, or even exist, on the machines I
> > control...
>
> I'm not a fan of cmake either.
>
> How do you deal with software that only builds with cmake (or meson,
> scons, ... whatever the developer decided to use as the build tool)?
> What alternatives exist short of reimplementing the build process in
> a standard makefile by hand, which is obviously very time consuming,
> error prone, and will probably break the next time you want to update
> a given package?

The alternative _is_ to reimplement the build process.

For example, see:

	https://github.com/robohack/yajl/

This example is a far more comprehensive rewrite than is usually
necessary as I wanted a complete and portable example that could be used
as the basis for further projects.

An example of a much simpler reimplementation:

	http://cvsweb.NetBSD.org/bsdweb.cgi/src/external/mit/ctwm/bin/ctwm/Makefile?rev=1.12&content-type=text/x-cvsweb-markup&only_with_tag=MAIN

--
					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: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Adam Thornton]

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

Someone clearly never used imake...


There's a reason that the xmkmf command ends in the two letters it does,
and I'm never going to believe it's "make file".

Adam

On Thu, Jun 20, 2024 at 11:34 AM Greg A. Woods <woods@robohack.ca> wrote:

> At Thu, 20 Jun 2024 01:01:01 -0400, Scot Jenkins via TUHS <tuhs@tuhs.org>
> wrote:
> Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix
> philosophy' The Register
> >
> > "Greg A. Woods" <woods@robohack.ca> wrote:
> >
> > > I will not ever allow cmake to run, or even exist, on the machines I
> > > control...
> >
> > I'm not a fan of cmake either.
> >
> > How do you deal with software that only builds with cmake (or meson,
> > scons, ... whatever the developer decided to use as the build tool)?
> > What alternatives exist short of reimplementing the build process in
> > a standard makefile by hand, which is obviously very time consuming,
> > error prone, and will probably break the next time you want to update
> > a given package?
>
> The alternative _is_ to reimplement the build process.
>
> For example, see:
>
>         https://github.com/robohack/yajl/
>
> This example is a far more comprehensive rewrite than is usually
> necessary as I wanted a complete and portable example that could be used
> as the basis for further projects.
>
> An example of a much simpler reimplementation:
>
>
> http://cvsweb.NetBSD.org/bsdweb.cgi/src/external/mit/ctwm/bin/ctwm/Makefile?rev=1.12&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
>
> --
>                                         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: 3417 bytes --]

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

[Warner Losh]

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

For me, precomputing an environment is the same as a wysiwyg editor: what
you see is all you get. If it works for you, and the environment that's
inferred from predefined CPP symbols is correct, then it's an easy
solution. When it's not, and for me it often wasn't, it's nothing but pain
and suffering and saying MF all the time (also not Make File)....  I was
serious when I've said I've had more positive cmake experiences (which
haven't been all that impressive: I'm more impressed with meson in this
space, for example) than I ever had with IMakefiles, imake, xmkmf, etc...
But It's also clear that different people have lived through different
hassles, and I respect that...

I've noticed too that we're relatively homogeneous these days: Everybody is
a Linux box or Windows Box or MacOS, except for a few weird people on the
fringes (like me). It's a lot easier to get things right enough w/o
autotools, scons, meson, etc than it was in The Bad Old Days of the Unix
Wars and the Innovation Famine that followed from the late 80s to the mid
2000s.... In that environment, there's one of two reactions: Test
Everything or Least Common Denominator. And we've seen both represented in
this thread.  As well as the 'There's so few environments, can't you
precompute them all?' sentiment from newbies that never bloodied their
knuckles with some of the less like Research Unix machines out there like
AIX and HP/UX...  Or worse, Eunice...

Warner

On Thu, Jun 20, 2024 at 12:42 PM Adam Thornton <athornton@gmail.com> wrote:

>
>
> Someone clearly never used imake...
>
>
> There's a reason that the xmkmf command ends in the two letters it does,
> and I'm never going to believe it's "make file".
>
> Adam
>
> On Thu, Jun 20, 2024 at 11:34 AM Greg A. Woods <woods@robohack.ca> wrote:
>
>> At Thu, 20 Jun 2024 01:01:01 -0400, Scot Jenkins via TUHS <tuhs@tuhs.org>
>> wrote:
>> Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix
>> philosophy' The Register
>> >
>> > "Greg A. Woods" <woods@robohack.ca> wrote:
>> >
>> > > I will not ever allow cmake to run, or even exist, on the machines I
>> > > control...
>> >
>> > I'm not a fan of cmake either.
>> >
>> > How do you deal with software that only builds with cmake (or meson,
>> > scons, ... whatever the developer decided to use as the build tool)?
>> > What alternatives exist short of reimplementing the build process in
>> > a standard makefile by hand, which is obviously very time consuming,
>> > error prone, and will probably break the next time you want to update
>> > a given package?
>>
>> The alternative _is_ to reimplement the build process.
>>
>> For example, see:
>>
>>         https://github.com/robohack/yajl/
>>
>> This example is a far more comprehensive rewrite than is usually
>> necessary as I wanted a complete and portable example that could be used
>> as the basis for further projects.
>>
>> An example of a much simpler reimplementation:
>>
>>
>> http://cvsweb.NetBSD.org/bsdweb.cgi/src/external/mit/ctwm/bin/ctwm/Makefile?rev=1.12&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
>>
>> --
>>                                         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: 5383 bytes --]

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

[ron minnich]

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

The slurm configure, produced by the configure script, is 1 mbyte, 30,000
lines of impenetrable script. For each .c file in slurm, an 11960 line
libtool script is invoked. autoconfig uses m4. When I told Eric Grosse,
back in 2015, that *anything* still used m4, he would not believe it was
"the m4 from the 70s" until I showed him. He was speechless. He had assumed
m4 died in the 80s.

Personally, the autoconfig process does not fill me with confidence, and it
was recently responsible for a very serious security problem. And,
autoconfig doesn't work: I've lost track of how many times autoconf has
failed for me. In general, in my experience, autoconf makes for less
portability, not more.

For a good example of a very portable system with a very clean,
human-readable make setup, I'd recommend a look at plan9ports. It includes
2 window managers, 2 graphical editors, and all the Plan 9 tools, and
somehow manages to be at least as portable as the autoconf mechanism.

On Thu, Jun 20, 2024 at 12:59 PM Warner Losh <imp@bsdimp.com> wrote:

> For me, precomputing an environment is the same as a wysiwyg editor: what
> you see is all you get. If it works for you, and the environment that's
> inferred from predefined CPP symbols is correct, then it's an easy
> solution. When it's not, and for me it often wasn't, it's nothing but pain
> and suffering and saying MF all the time (also not Make File)....  I was
> serious when I've said I've had more positive cmake experiences (which
> haven't been all that impressive: I'm more impressed with meson in this
> space, for example) than I ever had with IMakefiles, imake, xmkmf, etc...
> But It's also clear that different people have lived through different
> hassles, and I respect that...
>
> I've noticed too that we're relatively homogeneous these days: Everybody
> is a Linux box or Windows Box or MacOS, except for a few weird people on
> the fringes (like me). It's a lot easier to get things right enough w/o
> autotools, scons, meson, etc than it was in The Bad Old Days of the Unix
> Wars and the Innovation Famine that followed from the late 80s to the mid
> 2000s.... In that environment, there's one of two reactions: Test
> Everything or Least Common Denominator. And we've seen both represented in
> this thread.  As well as the 'There's so few environments, can't you
> precompute them all?' sentiment from newbies that never bloodied their
> knuckles with some of the less like Research Unix machines out there like
> AIX and HP/UX...  Or worse, Eunice...
>
> Warner
>
> On Thu, Jun 20, 2024 at 12:42 PM Adam Thornton <athornton@gmail.com>
> wrote:
>
>>
>>
>> Someone clearly never used imake...
>>
>>
>> There's a reason that the xmkmf command ends in the two letters it does,
>> and I'm never going to believe it's "make file".
>>
>> Adam
>>
>> On Thu, Jun 20, 2024 at 11:34 AM Greg A. Woods <woods@robohack.ca> wrote:
>>
>>> At Thu, 20 Jun 2024 01:01:01 -0400, Scot Jenkins via TUHS <tuhs@tuhs.org>
>>> wrote:
>>> Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix
>>> philosophy' The Register
>>> >
>>> > "Greg A. Woods" <woods@robohack.ca> wrote:
>>> >
>>> > > I will not ever allow cmake to run, or even exist, on the machines I
>>> > > control...
>>> >
>>> > I'm not a fan of cmake either.
>>> >
>>> > How do you deal with software that only builds with cmake (or meson,
>>> > scons, ... whatever the developer decided to use as the build tool)?
>>> > What alternatives exist short of reimplementing the build process in
>>> > a standard makefile by hand, which is obviously very time consuming,
>>> > error prone, and will probably break the next time you want to update
>>> > a given package?
>>>
>>> The alternative _is_ to reimplement the build process.
>>>
>>> For example, see:
>>>
>>>         https://github.com/robohack/yajl/
>>>
>>> This example is a far more comprehensive rewrite than is usually
>>> necessary as I wanted a complete and portable example that could be used
>>> as the basis for further projects.
>>>
>>> An example of a much simpler reimplementation:
>>>
>>>
>>> http://cvsweb.NetBSD.org/bsdweb.cgi/src/external/mit/ctwm/bin/ctwm/Makefile?rev=1.12&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
>>>
>>> --
>>>                                         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: 6794 bytes --]

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

[Adam Thornton]

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

>
> In general, in my experience, autoconf makes for less portability, not
> more.


As an anecdotal data point, Jay Maynard has forked Hercules (S360/370/390/z
Emulator) and, among other things, is ripping out 25 years of
increasingly-baroque autoconf, which will probably make the build process
(notoriously finicky) a whole lot clearer and easier.

Adam

On Thu, Jun 20, 2024 at 1:12 PM ron minnich <rminnich@gmail.com> wrote:

> The slurm configure, produced by the configure script, is 1 mbyte, 30,000
> lines of impenetrable script. For each .c file in slurm, an 11960 line
> libtool script is invoked. autoconfig uses m4. When I told Eric Grosse,
> back in 2015, that *anything* still used m4, he would not believe it was
> "the m4 from the 70s" until I showed him. He was speechless. He had assumed
> m4 died in the 80s.
>
> Personally, the autoconfig process does not fill me with confidence, and
> it was recently responsible for a very serious security problem. And,
> autoconfig doesn't work: I've lost track of how many times autoconf has
> failed for me. In general, in my experience, autoconf makes for less
> portability, not more.
>
> For a good example of a very portable system with a very clean,
> human-readable make setup, I'd recommend a look at plan9ports. It includes
> 2 window managers, 2 graphical editors, and all the Plan 9 tools, and
> somehow manages to be at least as portable as the autoconf mechanism.
>
> On Thu, Jun 20, 2024 at 12:59 PM Warner Losh <imp@bsdimp.com> wrote:
>
>> For me, precomputing an environment is the same as a wysiwyg editor: what
>> you see is all you get. If it works for you, and the environment that's
>> inferred from predefined CPP symbols is correct, then it's an easy
>> solution. When it's not, and for me it often wasn't, it's nothing but pain
>> and suffering and saying MF all the time (also not Make File)....  I was
>> serious when I've said I've had more positive cmake experiences (which
>> haven't been all that impressive: I'm more impressed with meson in this
>> space, for example) than I ever had with IMakefiles, imake, xmkmf, etc...
>> But It's also clear that different people have lived through different
>> hassles, and I respect that...
>>
>> I've noticed too that we're relatively homogeneous these days: Everybody
>> is a Linux box or Windows Box or MacOS, except for a few weird people on
>> the fringes (like me). It's a lot easier to get things right enough w/o
>> autotools, scons, meson, etc than it was in The Bad Old Days of the Unix
>> Wars and the Innovation Famine that followed from the late 80s to the mid
>> 2000s.... In that environment, there's one of two reactions: Test
>> Everything or Least Common Denominator. And we've seen both represented in
>> this thread.  As well as the 'There's so few environments, can't you
>> precompute them all?' sentiment from newbies that never bloodied their
>> knuckles with some of the less like Research Unix machines out there like
>> AIX and HP/UX...  Or worse, Eunice...
>>
>> Warner
>>
>> On Thu, Jun 20, 2024 at 12:42 PM Adam Thornton <athornton@gmail.com>
>> wrote:
>>
>>>
>>>
>>> Someone clearly never used imake...
>>>
>>>
>>> There's a reason that the xmkmf command ends in the two letters it
>>> does, and I'm never going to believe it's "make file".
>>>
>>> Adam
>>>
>>> On Thu, Jun 20, 2024 at 11:34 AM Greg A. Woods <woods@robohack.ca>
>>> wrote:
>>>
>>>> At Thu, 20 Jun 2024 01:01:01 -0400, Scot Jenkins via TUHS <
>>>> tuhs@tuhs.org> wrote:
>>>> Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix
>>>> philosophy' The Register
>>>> >
>>>> > "Greg A. Woods" <woods@robohack.ca> wrote:
>>>> >
>>>> > > I will not ever allow cmake to run, or even exist, on the machines I
>>>> > > control...
>>>> >
>>>> > I'm not a fan of cmake either.
>>>> >
>>>> > How do you deal with software that only builds with cmake (or meson,
>>>> > scons, ... whatever the developer decided to use as the build tool)?
>>>> > What alternatives exist short of reimplementing the build process in
>>>> > a standard makefile by hand, which is obviously very time consuming,
>>>> > error prone, and will probably break the next time you want to update
>>>> > a given package?
>>>>
>>>> The alternative _is_ to reimplement the build process.
>>>>
>>>> For example, see:
>>>>
>>>>         https://github.com/robohack/yajl/
>>>>
>>>> This example is a far more comprehensive rewrite than is usually
>>>> necessary as I wanted a complete and portable example that could be used
>>>> as the basis for further projects.
>>>>
>>>> An example of a much simpler reimplementation:
>>>>
>>>>
>>>> http://cvsweb.NetBSD.org/bsdweb.cgi/src/external/mit/ctwm/bin/ctwm/Makefile?rev=1.12&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
>>>>
>>>> --
>>>>                                         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: 7702 bytes --]

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

[ron minnich]

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

and, this just happened in slurm:
autoreconf
at top level of slurm fails with an m4 error complete with the usual
incomprehensible error message.

This gets old. As the saying goes, autoconf tools may be slow and buggy,
but at least they're hard to use.

one of the things I am grateful to Go for is that it does not suffer from
this sort of nonsense.

On Thu, Jun 20, 2024 at 1:12 PM ron minnich <rminnich@gmail.com> wrote:

> The slurm configure, produced by the configure script, is 1 mbyte, 30,000
> lines of impenetrable script. For each .c file in slurm, an 11960 line
> libtool script is invoked. autoconfig uses m4. When I told Eric Grosse,
> back in 2015, that *anything* still used m4, he would not believe it was
> "the m4 from the 70s" until I showed him. He was speechless. He had assumed
> m4 died in the 80s.
>
> Personally, the autoconfig process does not fill me with confidence, and
> it was recently responsible for a very serious security problem. And,
> autoconfig doesn't work: I've lost track of how many times autoconf has
> failed for me. In general, in my experience, autoconf makes for less
> portability, not more.
>
> For a good example of a very portable system with a very clean,
> human-readable make setup, I'd recommend a look at plan9ports. It includes
> 2 window managers, 2 graphical editors, and all the Plan 9 tools, and
> somehow manages to be at least as portable as the autoconf mechanism.
>
> On Thu, Jun 20, 2024 at 12:59 PM Warner Losh <imp@bsdimp.com> wrote:
>
>> For me, precomputing an environment is the same as a wysiwyg editor: what
>> you see is all you get. If it works for you, and the environment that's
>> inferred from predefined CPP symbols is correct, then it's an easy
>> solution. When it's not, and for me it often wasn't, it's nothing but pain
>> and suffering and saying MF all the time (also not Make File)....  I was
>> serious when I've said I've had more positive cmake experiences (which
>> haven't been all that impressive: I'm more impressed with meson in this
>> space, for example) than I ever had with IMakefiles, imake, xmkmf, etc...
>> But It's also clear that different people have lived through different
>> hassles, and I respect that...
>>
>> I've noticed too that we're relatively homogeneous these days: Everybody
>> is a Linux box or Windows Box or MacOS, except for a few weird people on
>> the fringes (like me). It's a lot easier to get things right enough w/o
>> autotools, scons, meson, etc than it was in The Bad Old Days of the Unix
>> Wars and the Innovation Famine that followed from the late 80s to the mid
>> 2000s.... In that environment, there's one of two reactions: Test
>> Everything or Least Common Denominator. And we've seen both represented in
>> this thread.  As well as the 'There's so few environments, can't you
>> precompute them all?' sentiment from newbies that never bloodied their
>> knuckles with some of the less like Research Unix machines out there like
>> AIX and HP/UX...  Or worse, Eunice...
>>
>> Warner
>>
>> On Thu, Jun 20, 2024 at 12:42 PM Adam Thornton <athornton@gmail.com>
>> wrote:
>>
>>>
>>>
>>> Someone clearly never used imake...
>>>
>>>
>>> There's a reason that the xmkmf command ends in the two letters it
>>> does, and I'm never going to believe it's "make file".
>>>
>>> Adam
>>>
>>> On Thu, Jun 20, 2024 at 11:34 AM Greg A. Woods <woods@robohack.ca>
>>> wrote:
>>>
>>>> At Thu, 20 Jun 2024 01:01:01 -0400, Scot Jenkins via TUHS <
>>>> tuhs@tuhs.org> wrote:
>>>> Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix
>>>> philosophy' The Register
>>>> >
>>>> > "Greg A. Woods" <woods@robohack.ca> wrote:
>>>> >
>>>> > > I will not ever allow cmake to run, or even exist, on the machines I
>>>> > > control...
>>>> >
>>>> > I'm not a fan of cmake either.
>>>> >
>>>> > How do you deal with software that only builds with cmake (or meson,
>>>> > scons, ... whatever the developer decided to use as the build tool)?
>>>> > What alternatives exist short of reimplementing the build process in
>>>> > a standard makefile by hand, which is obviously very time consuming,
>>>> > error prone, and will probably break the next time you want to update
>>>> > a given package?
>>>>
>>>> The alternative _is_ to reimplement the build process.
>>>>
>>>> For example, see:
>>>>
>>>>         https://github.com/robohack/yajl/
>>>>
>>>> This example is a far more comprehensive rewrite than is usually
>>>> necessary as I wanted a complete and portable example that could be used
>>>> as the basis for further projects.
>>>>
>>>> An example of a much simpler reimplementation:
>>>>
>>>>
>>>> http://cvsweb.NetBSD.org/bsdweb.cgi/src/external/mit/ctwm/bin/ctwm/Makefile?rev=1.12&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
>>>>
>>>> --
>>>>                                         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: 7602 bytes --]

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

[Chet Ramey via TUHS]

[-- Attachment #1.1: Type: text/plain, Size: 926 bytes --]

On 6/20/24 4:12 PM, ron minnich wrote:

> Personally, the autoconfig process does not fill me with confidence, and it 
> was recently responsible for a very serious security problem. And, 
> autoconfig doesn't work: I've lost track of how many times autoconf has 
> failed for me. In general, in my experience, autoconf makes for less 
> portability, not more.

I'd be interested in some examples of this. I've had pretty decent success
with autoconf-based portability.

The one issue is cross-compiling between systems with different versions of
libc (glibc vs. musl, for instance). Tools that run natively on the build
platform have to be very portable, since they can't use config.h (which is
for the target system).

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

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

[Henry Bent]

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

On Fri, 21 Jun 2024 at 11:47, Chet Ramey via TUHS <tuhs@tuhs.org> wrote:

> On 6/20/24 4:12 PM, ron minnich wrote:
>
> > Personally, the autoconfig process does not fill me with confidence, and
> it
> > was recently responsible for a very serious security problem. And,
> > autoconfig doesn't work: I've lost track of how many times autoconf has
> > failed for me. In general, in my experience, autoconf makes for less
> > portability, not more.
>
> I'd be interested in some examples of this. I've had pretty decent success
> with autoconf-based portability.
>

I think it's important to make a distinction between autotools not working
and  the actual software distribution not being buildable.

For example, I've recently been working with Ultrix V4.5.  Most configure
scripts are able to complete successfully with ksh or sh5, so I don't
absolutely need bash (even though I do have it and use it).  The
difficulties begin when trying to compile the actual code; for example,
Ultrix doesn't have strdup().  Almost every autotools-based package I've
used doesn't bother checking if I have strdup() and/or providing a
replacement.  This isn't the fault of autotools, this is the fault of the
code author not considering whether a lack of strdup() is a possibility.
The end result, however, is the same - I don't have a buildable release
as-is.

I know that Ultrix is incredibly out of date, but I use it to illustrate
that while there are corner cases that autotools won't catch, that isn't
the fault of autotools.  It would be no different with cmake or imake or
meson or handwritten makefiles or anything else - if the software author
doesn't bother checking for and coding around the corner case that comes up
on your particular system, you're stuck unless you can fix the code.

-Henry

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

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

[Chet Ramey via TUHS]

[-- Attachment #1.1: Type: text/plain, Size: 2159 bytes --]

On 6/21/24 12:06 PM, Henry Bent wrote:
> On Fri, 21 Jun 2024 at 11:47, Chet Ramey via TUHS <tuhs@tuhs.org 
> <mailto:tuhs@tuhs.org>> wrote:
> 
>     On 6/20/24 4:12 PM, ron minnich wrote:
> 
>      > Personally, the autoconfig process does not fill me with confidence,
>     and it
>      > was recently responsible for a very serious security problem. And,
>      > autoconfig doesn't work: I've lost track of how many times autoconf has
>      > failed for me. In general, in my experience, autoconf makes for less
>      > portability, not more.
> 
>     I'd be interested in some examples of this. I've had pretty decent success
>     with autoconf-based portability.
> 
> 
> I think it's important to make a distinction between autotools not working 
> and  the actual software distribution not being buildable.
> 
> For example, I've recently been working with Ultrix V4.5.  Most configure 
> scripts are able to complete successfully with ksh or sh5, so I don't 
> absolutely need bash (even though I do have it and use it).  The 
> difficulties begin when trying to compile the actual code; for example, 
> Ultrix doesn't have strdup(). 

For most projects, OS releases that ancient are not supported. It's the
code author using some base minimum for assumptions -- OSs from the past
35 years or so should be safe (dating from the 4.4 BSD release, to use
the strdup() example). Maybe that's the "code author not considering,"
but I'd say that's the result of the author simply not being interested
in something that old.

Bash ran on 4.3 BSD for a long time (and may still, I haven't checked with
that project maintainer in a while), and I ran bash-5.0 on OPENSTEP 4.2
because I like it, but I'd say those are exceptions.

I guess what I'm saying is that it's not the author's fault for not wanting
to support OS versions released, for a significant percentage, before they
were born. They have different priorities.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

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

[Henry Bent]

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

On Fri, 21 Jun 2024 at 12:24, Chet Ramey <chet.ramey@case.edu> wrote:

>
> For most projects, OS releases that ancient are not supported. It's the
> code author using some base minimum for assumptions -- OSs from the past
> 35 years or so should be safe (dating from the 4.4 BSD release, to use
> the strdup() example). Maybe that's the "code author not considering,"
> but I'd say that's the result of the author simply not being interested
> in something that old.
>
> Bash ran on 4.3 BSD for a long time (and may still, I haven't checked with
> that project maintainer in a while), and I ran bash-5.0 on OPENSTEP 4.2
> because I like it, but I'd say those are exceptions.
>
> I guess what I'm saying is that it's not the author's fault for not wanting
> to support OS versions released, for a significant percentage, before they
> were born. They have different priorities.
>
>
Sure, and I don't disagree.  I was just using an old OS to make a point
about corner cases; it would be just as applicable if I had a modern OS
that for whatever reason lacked strdup(), or your personal favorite "but
everyone has this!" function.  You're not going to be able to cover all
bases all the time, and I'm sure that there are plenty of code authors who
aren't interested in formally supporting anything outside of the most
common operating systems.  If their autotools-based projects work on my
other OS that's great, but it isn't the fault of autotools if the project
isn't coded with my OS in mind.

-Henry

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

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

[Warner Losh]

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

On Fri, Jun 21, 2024 at 10:40 AM Henry Bent <henry.r.bent@gmail.com> wrote:

> Sure, and I don't disagree.  I was just using an old OS to make a point
> about corner cases; it would be just as applicable if I had a modern OS
> that for whatever reason lacked strdup(), or your personal favorite "but
> everyone has this!" function.  You're not going to be able to cover all
> bases all the time, and I'm sure that there are plenty of code authors who
> aren't interested in formally supporting anything outside of the most
> common operating systems.  If their autotools-based projects work on my
> other OS that's great, but it isn't the fault of autotools if the project
> isn't coded with my OS in mind.
>

Normally in modern software, "has it or not" is controlled by some
pre-processor variable you can check. The problem comes in when you have
under-conformant systems that claim conformance with POSiX 1-20xx, but that
lack that one interface mandated by it (and one that's not controlled by
some other thing... posix is super complex, for good and for ill). And you
also have the edge case of "newly defined in C11" say, and the base
compiler doesn't claim C11 conformance, but this function is none-the-less
available. It's really really hard to know if it's there or not w/o testing
for it. That even goes for "it's a linux box" since musl vs glibc has
variations that you won't know about until you check.

So it doesn't have to be something that should be as ubiquitous as strdup
to run into issues.

Warner

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

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

[Chet Ramey via TUHS]

[-- Attachment #1.1: Type: text/plain, Size: 420 bytes --]

On 6/21/24 12:40 PM, Henry Bent wrote:

> If their autotools-based projects work on my 
> other OS that's great, but it isn't the fault of autotools if the project 
> isn't coded with my OS in mind.

Yep, we agree on that.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

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

[Phil Budne]

Henry Bent wrote:
> On Fri, 21 Jun 2024 at 12:24, Chet Ramey <chet.ramey@case.edu> wrote:
> > I guess what I'm saying is that it's not the author's fault for not wanting
> > to support OS versions released, for a significant percentage, before they
> > were born. They have different priorities.
> If their autotools-based projects work on my
> other OS that's great, but it isn't the fault of autotools if the project
> isn't coded with my OS in mind.

autotools isn't a magic wand for making portable apps, it's a toolkit
for probing the environment to discover which alternatives are available.

I'm sure it's a mysterious waste of time to those who didn't live
through the Un*x wars, a time when there were multiple major things
called Un*x, multiple major vendors, and available features changed
frequently.

Code can only be kept portable by building and testing and fixing it
across all the platforms, which is time intensive, and given the
closer alignment of systems nowadays doesn't get much effort.

For a look at the effort I once invested in making/keeping a pet
project portable look at the range of platforms I had to test on at
http://ftp.regressive.org/finger/00README

For a current project:
https://www.regressive.org/snobol4/csnobol4/2.3/stats.html
(I tested builds on Red Hat (not Enterprise!) 7.1 and FreeBSD 3.2)
and https://www.regressive.org/snobol4/csnobol4/2.2/stats.html
(includes OpenIndiana, a Solaris based distribution).

I've never been an autotools fan; I've used it once, when I wanted to
be able to build shared libraries across arbitrary platforms.

I once used cpp for conditionalizing Makefiles, but that became
unreliable once ANSI C hit the streets (ISTR throwing up my hands when
I discovered "pee pee nums")

The REAL evil of autotools is that it builds on the premise that
all problems can be solved using #ifdef.

I drank a different drink mix three decades ago:
https://www.usenix.org/legacy/publications/library/proceedings/sa92/spencer.pdf

But you're still stuck with having to discover what's available.

Apache Portable Runtime or Boost are environments that try to smooth
over some plaform differences (for varying values of some, depending
on your needs), but that's a whole 'nuther belief system to buy into.

Maybe this discussion needs to move to autoconf-haters?

On the original topic, I keep imagining the systemd authors are are
trying to build a monolithic system; an operating system inside an
operating system that someday systemd will appear inside of.  Then it
will be "systemd all the way down".

Followups to systemd-haters?

P.S.  Some earlier post complained about the complexity of writing
rc.d scripts for FreeBSD; The current system only requires a script
setting some variables.

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

[Chet Ramey via TUHS]

[-- Attachment #1.1: Type: text/plain, Size: 753 bytes --]

On 6/21/24 1:31 PM, Phil Budne wrote:

> The REAL evil of autotools is that it builds on the premise that
> all problems can be solved using #ifdef.

That's certainly the most common idiom, and one that most autotools users
(including me) predominantly use, but it's not the only way. If you want
to provide a larger distribution, you can use AC_REPLACE_FUNCS for things
that a particular target doesn't provide and isolate the complexity there.
gnulib is a big help here.

Or you can provide a compatibility layer and push the complexity down to it.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

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

[Clem Cole]

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

On Thu, Jun 20, 2024 at 3:59 PM Warner Losh <imp@bsdimp.com> wrote:

> As well as the 'There's so few environments, can't you precompute them
> all?' sentiment from newbies that never bloodied their knuckles with some
> of the less like Research Unix machines out there like AIX and HP/UX...  Or
> worse, Eunice...
>

Remember Henry's 10 commandments [maybe I can LA to post them in all their
universities] the 10th beacons harsh here:

   - *Thou shalt forswear, renounce, and abjure the vile heresy which
   claimeth that All the world's a VAX, and have no commerce with the
   benighted heathens who cling to this barbarous belief, that the days of thy
   program may be long even though the days of thy current machine be short.*

ᐧ

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

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

[Luther Johnson]

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

I agree that there are certainly times when CMake's leverage has solved
problems for people. My most visceral reactions were mostly based on
cases where no tool like CMake was really required at all, but CMake had
wormed its way into the consciousness of new programmers who never
learned make, and thought CMake was doing them a great service. Bugged
the hell out of me, this dumbing-down of the general programming
population. My bad experiences were all as a consultant to teams that
needed a lot of expert help, when they had thrown CMake along with a lot
of other unnecessary complexity into their half-working solutions. So I
guess it was all tarred by the same flavor of badly conceived work. But
then as I tried to make my peace with the CMake build as it was, I got a
deeper understanding of how intrinsically irrational CMake is (and
again, behavior changing on the same builds depending on CMake release
versions.

So there certainly are times when something a little more comprehensive,
outside of make, is required. ./configure && make is not so bad, it's
not irrational, sometimes it's overkill, but it works ... but only if
the system is kind of Unix-y. If not you may wind up doing a lot of work
to pretend it's more Unix-y, so instead of porting your software, you're
porting it to a common Unix-like subset, then emulating that Unix-like
subset on your platform, both ends against the middle. That can be
ultimately counter-productive too.

I have an emotional reaction when I see the porting problem become
transformed into adherence to the "one true way", be it Unix, or one
build system or another. Because you're now just re-casting the problem
into acceptance of that other tool or OS core as the way it should be.
Instead of getting your thing to work on the other platform, by
translating from what your application wants, into how to do it on
whatever system, you're changing your application to be more like what
the "one true system" wants to see. You've given up control of your idea
of your app's core OS requirements, you've decided to "just give in and
be UNiX (or Windows, or whatever)". To me, that's backwards.

On 06/20/2024 12:59 PM, Warner Losh wrote:
> For me, precomputing an environment is the same as a wysiwyg editor:
> what you see is all you get. If it works for you, and the environment
> that's inferred from predefined CPP symbols is correct, then it's an
> easy solution. When it's not, and for me it often wasn't, it's nothing
> but pain and suffering and saying MF all the time (also not Make
> File).... I was serious when I've said I've had more positive cmake
> experiences (which haven't been all that impressive: I'm more
> impressed with meson in this space, for example) than I ever had with
> IMakefiles, imake, xmkmf, etc...  But It's also clear that different
> people have lived through different hassles, and I respect that...
>
> I've noticed too that we're relatively homogeneous these days:
> Everybody is a Linux box or Windows Box or MacOS, except for a few
> weird people on the fringes (like me). It's a lot easier to get things
> right enough w/o autotools, scons, meson, etc than it was in The Bad
> Old Days of the Unix Wars and the Innovation Famine that followed from
> the late 80s to the mid 2000s.... In that environment, there's one of
> two reactions: Test Everything or Least Common Denominator. And we've
> seen both represented in this thread.  As well as the 'There's so few
> environments, can't you precompute them all?' sentiment from newbies
> that never bloodied their knuckles with some of the less like Research
> Unix machines out there like AIX and HP/UX...  Or worse, Eunice...
>
> Warner
>
> On Thu, Jun 20, 2024 at 12:42 PM Adam Thornton <athornton@gmail.com
> <mailto:athornton@gmail.com>> wrote:
>
>
>
>         Someone clearly never used imake...
>
>
>     There's a reason that the xmkmf command ends in the two letters it
>     does, and I'm never going to believe it's "make file".
>
>     Adam
>
>     On Thu, Jun 20, 2024 at 11:34 AM Greg A. Woods <woods@robohack.ca
>     <mailto:woods@robohack.ca>> wrote:
>
>         At Thu, 20 Jun 2024 01:01:01 -0400, Scot Jenkins via TUHS
>         <tuhs@tuhs.org <mailto:tuhs@tuhs.org>> wrote:
>         Subject: [TUHS] Re: Version 256 of systemd boasts '42% less
>         Unix philosophy' The Register
>         >
>         > "Greg A. Woods" <woods@robohack.ca
>         <mailto:woods@robohack.ca>> wrote:
>         >
>         > > I will not ever allow cmake to run, or even exist, on the
>         machines I
>         > > control...
>         >
>         > I'm not a fan of cmake either.
>         >
>         > How do you deal with software that only builds with cmake
>         (or meson,
>         > scons, ... whatever the developer decided to use as the
>         build tool)?
>         > What alternatives exist short of reimplementing the build
>         process in
>         > a standard makefile by hand, which is obviously very time
>         consuming,
>         > error prone, and will probably break the next time you want
>         to update
>         > a given package?
>
>         The alternative _is_ to reimplement the build process.
>
>         For example, see:
>
>         https://github.com/robohack/yajl/
>
>         This example is a far more comprehensive rewrite than is usually
>         necessary as I wanted a complete and portable example that
>         could be used
>         as the basis for further projects.
>
>         An example of a much simpler reimplementation:
>
>         http://cvsweb.NetBSD.org/bsdweb.cgi/src/external/mit/ctwm/bin/ctwm/Makefile?rev=1.12&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
>
>         --
>                                                 Greg A. Woods
>         <gwoods@acm.org <mailto:gwoods@acm.org>>
>
>         Kelowna, BC     +1 250 762-7675           RoboHack
>         <woods@robohack.ca <mailto:woods@robohack.ca>>
>         Planix, Inc. <woods@planix.com <mailto:woods@planix.com>>
>          Avoncote Farms <woods@avoncote.ca <mailto:woods@avoncote.ca>>
>


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

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

[ron minnich]

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

here's where I'd have to disagree: "./configure && make is not so bad, it's
not irrational, sometimes it's overkill, but it works"

because it doesn't. Work, that is. At least, for me.

I'm amazed: the autoreconf step on slurm permanently broke the build, such
that I am having to do a full git reset --hard and clean and start over.

Even simple things fail with autoconf: see the sad story here, of how I
pulled down a few simple programs, and they all fail to build. I replaced
them ALL with a single Go program that was smaller, by far, than a single
one of the configure scripts.
https://docs.google.com/presentation/d/1d0yK7g-J6oITgE-B_odadSw3nlBWGbMK7clt_TmXo7c/edit?usp=sharing

On Thu, Jun 20, 2024 at 1:35 PM Luther Johnson <luther.johnson@makerlisp.com>
wrote:

> I agree that there are certainly times when CMake's leverage has solved
> problems for people. My most visceral reactions were mostly based on cases
> where no tool like CMake was really required at all, but CMake had wormed
> its way into the consciousness of new programmers who never learned make,
> and thought CMake was doing them a great service. Bugged the hell out of
> me, this dumbing-down of the general programming population. My bad
> experiences were all as a consultant to teams that needed a lot of expert
> help, when they had thrown CMake along with a lot of other unnecessary
> complexity into their half-working solutions. So I guess it was all tarred
> by the same flavor of badly conceived work. But then as I tried to make my
> peace with the CMake build as it was, I got a deeper understanding of how
> intrinsically irrational CMake is (and again, behavior changing on the same
> builds depending on CMake release versions.
> So there certainly are times when something a little more comprehensive,
> outside of make, is required. ./configure && make is not so bad, it's not
> irrational, sometimes it's overkill, but it works ... but only if the
> system is kind of Unix-y. If not you may wind up doing a lot of work to
> pretend it's more Unix-y, so instead of porting your software, you're
> porting it to a common Unix-like subset, then emulating that Unix-like
> subset on your platform, both ends against the middle. That can be
> ultimately counter-productive too.
>
> I have an emotional reaction when I see the porting problem become
> transformed into adherence to the "one true way", be it Unix, or one build
> system or another. Because you're now just re-casting the problem into
> acceptance of that other tool or OS core as the way it should be. Instead
> of getting your thing to work on the other platform, by translating from
> what your application wants, into how to do it on whatever system, you're
> changing your application to be more like what the "one true system" wants
> to see. You've given up control of your idea of your app's core OS
> requirements, you've decided to "just give in and be UNiX (or Windows, or
> whatever)". To me, that's backwards.
>
> On 06/20/2024 12:59 PM, Warner Losh wrote:
>
> For me, precomputing an environment is the same as a wysiwyg editor: what
> you see is all you get. If it works for you, and the environment that's
> inferred from predefined CPP symbols is correct, then it's an easy
> solution. When it's not, and for me it often wasn't, it's nothing but pain
> and suffering and saying MF all the time (also not Make File)....  I was
> serious when I've said I've had more positive cmake experiences (which
> haven't been all that impressive: I'm more impressed with meson in this
> space, for example) than I ever had with IMakefiles, imake, xmkmf, etc...
> But It's also clear that different people have lived through different
> hassles, and I respect that...
>
> I've noticed too that we're relatively homogeneous these days: Everybody
> is a Linux box or Windows Box or MacOS, except for a few weird people on
> the fringes (like me). It's a lot easier to get things right enough w/o
> autotools, scons, meson, etc than it was in The Bad Old Days of the Unix
> Wars and the Innovation Famine that followed from the late 80s to the mid
> 2000s.... In that environment, there's one of two reactions: Test
> Everything or Least Common Denominator. And we've seen both represented in
> this thread.  As well as the 'There's so few environments, can't you
> precompute them all?' sentiment from newbies that never bloodied their
> knuckles with some of the less like Research Unix machines out there like
> AIX and HP/UX...  Or worse, Eunice...
>
> Warner
>
> On Thu, Jun 20, 2024 at 12:42 PM Adam Thornton <athornton@gmail.com>
> wrote:
>
>>
>>
>> Someone clearly never used imake...
>>
>>
>> There's a reason that the xmkmf command ends in the two letters it does,
>> and I'm never going to believe it's "make file".
>>
>> Adam
>>
>> On Thu, Jun 20, 2024 at 11:34 AM Greg A. Woods <woods@robohack.ca> wrote:
>>
>>> At Thu, 20 Jun 2024 01:01:01 -0400, Scot Jenkins via TUHS <tuhs@tuhs.org>
>>> wrote:
>>> Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix
>>> philosophy' The Register
>>> >
>>> > "Greg A. Woods" <woods@robohack.ca> wrote:
>>> >
>>> > > I will not ever allow cmake to run, or even exist, on the machines I
>>> > > control...
>>> >
>>> > I'm not a fan of cmake either.
>>> >
>>> > How do you deal with software that only builds with cmake (or meson,
>>> > scons, ... whatever the developer decided to use as the build tool)?
>>> > What alternatives exist short of reimplementing the build process in
>>> > a standard makefile by hand, which is obviously very time consuming,
>>> > error prone, and will probably break the next time you want to update
>>> > a given package?
>>>
>>> The alternative _is_ to reimplement the build process.
>>>
>>> For example, see:
>>>
>>>         https://github.com/robohack/yajl/
>>>
>>> This example is a far more comprehensive rewrite than is usually
>>> necessary as I wanted a complete and portable example that could be used
>>> as the basis for further projects.
>>>
>>> An example of a much simpler reimplementation:
>>>
>>>
>>> http://cvsweb.NetBSD.org/bsdweb.cgi/src/external/mit/ctwm/bin/ctwm/Makefile?rev=1.12&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
>>>
>>> --
>>>                                         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: 11006 bytes --]

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

[David Arnold]

> On 21 Jun 2024, at 07:00, ron minnich <rminnich@gmail.com> wrote:
> 
> here's where I'd have to disagree: "./configure && make is not so bad, it's not irrational, sometimes it's overkill, but it works"
> 
> because it doesn't. Work, that is. At least, for me.

Never?

Any tool can be misused (perhaps there’s an issue with slurm’s implementation here?)

I think the quality of autoconf usage (by project authors) has declined, perhaps as building from source has been overtaken by the use of binary packages. 

I’d argue that autotools (incl automake and libtool) can be a decent solution in the hands of devs who care.  At one time, I think it was the best compromise, although I’m open to argument that this time has passed. 

It was certainly never useful for general portability to Windows, for instance, and more recent tools manage that better. 




d

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

[ron minnich]

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

You're right. It's not that autoconf never works, it's that it fails so
frequently that I can't trust it to work. Case in point, I just had a bunch
of trouble this morning with it, with the most trivial command, and had to
reset the repo to ground state to get it to build again.

but compared to my experience with Go, autoconf does not compare well.

On Thu, Jun 20, 2024 at 2:53 PM David Arnold <davida@pobox.com> wrote:

>
> > On 21 Jun 2024, at 07:00, ron minnich <rminnich@gmail.com> wrote:
> >
> > here's where I'd have to disagree: "./configure && make is not so bad,
> it's not irrational, sometimes it's overkill, but it works"
> >
> > because it doesn't. Work, that is. At least, for me.
>
> Never?
>
> Any tool can be misused (perhaps there’s an issue with slurm’s
> implementation here?)
>
> I think the quality of autoconf usage (by project authors) has declined,
> perhaps as building from source has been overtaken by the use of binary
> packages.
>
> I’d argue that autotools (incl automake and libtool) can be a decent
> solution in the hands of devs who care.  At one time, I think it was the
> best compromise, although I’m open to argument that this time has passed.
>
> It was certainly never useful for general portability to Windows, for
> instance, and more recent tools manage that better.
>
>
>
>
> d
>

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

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

[Larry McVoy]

On Thu, Jun 20, 2024 at 03:00:52PM -0700, ron minnich wrote:
> You're right. It's not that autoconf never works, it's that it fails so
> frequently that I can't trust it to work. Case in point, I just had a bunch
> of trouble this morning with it, with the most trivial command, and had to
> reset the repo to ground state to get it to build again.
> 
> but compared to my experience with Go, autoconf does not compare well.

This is BitKeeper's build shell.  Not a lot to it.

#!/bin/sh

orig_args="$@"

ms_env()
{
	unset JOBS
	test "$MSYSBUILDENV" || {
		echo running in wrong environment, respawning...
		rm -f conf*.mk
		bk get -S ./update_buildenv
		BK_USEMSYS=1 bk sh ./update_buildenv
		export HOME=`bk pwd`
		test -d R:/build/buildenv/bin &&
		    exec R:/build/buildenv/bin/sh --login $0 $orig_args
		exec C:/build/buildenv/bin/sh --login $0 $orig_args
	}

	gcc --version | grep -q cyg && {
		echo No Mingw GCC found, I quit.
		exit 1
	}
}

JOBS=-j4
while getopts j: opt
do
       case "$opt" in
               j) JOBS=-j$OPTARG;;
       esac
done
shift `expr $OPTIND - 1`

# ccache stuff
CCLINKS=/build/cclinks
CCACHEBIN=`which ccache 2>/dev/null`
if [ $? = 0 -a "X$BK_NO_CCACHE" = X ]
then
	test -d $CCLINKS || {
		mkdir -p $CCLINKS
		ln -s "$CCACHEBIN" $CCLINKS/cc
		ln -s "$CCACHEBIN" $CCLINKS/gcc
	}
	CCACHE_DIR=/build/.ccache
	# Seems like a good idea but if cache and
	# source are on different filesystems, setting
	# CCACHE_HARDLINK seems to have the same
	# effect as disabling the cache altogether
	#CCACHE_HARDLINK=1
	CCACHE_UMASK=002
	export CCACHE_DIR CCACHE_HARDLINK CCACHE_UMASK
	export PATH=$CCLINKS:$PATH
else
	CCACHE_DISABLE=1
	export CCACHE_DISABLE
fi

case "X`uname -s`" in
	XCYGWIN*|XMINGW*)
		ms_env;
		;;
esac

test "$MAKE" || MAKE=`which gmake 2>/dev/null`
test "$MAKE" || MAKE=make
test "x$BK_VERBOSE_BUILD" != "x" && { V="V=1"; }

"$MAKE" --no-print-directory $JOBS $V "$@"

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

[Luther Johnson]

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

I defer to your greater experience than mine. I guess I've run into
./configure && make in very vanilla situations, a few Gnu or Gnu-ish
applications. If it has times when it doesn't work, or doesn't behave
well, then I don't doubt your experience.

I first entered this thread in pointing out some similarities in the
style of opaque artificially pseudo intelligence behind systemd and
CMake, namely, don't you decide what to do, tell about these qualities
of these modules and we will decide what to do, don't worry your newbie
little head. I think autoconf and configure are kind of halfway between
user-decides-what to do (straight make) and user-decides-nothing,
is-kept-in the-dark (CMake). So in that way, it's only half as bad. If
it falls over sometimes when it shouldn't I think you know more about
that then me. I will be wary.

For my own code, I stick with straight make, and the occasional script.

On 06/20/2024 02:00 PM, ron minnich wrote:
> here's where I'd have to disagree: "./configure && make is not so bad,
> it's not irrational, sometimes it's overkill, but it works"
>
> because it doesn't. Work, that is. At least, for me.
>
> I'm amazed: the autoreconf step on slurm permanently broke the build,
> such that I am having to do a full git reset --hard and clean and
> start over.
>
> Even simple things fail with autoconf: see the sad story here, of how
> I pulled down a few simple programs, and they all fail to build. I
> replaced them ALL with a single Go program that was smaller, by far,
> than a single one of the configure scripts.
> https://docs.google.com/presentation/d/1d0yK7g-J6oITgE-B_odadSw3nlBWGbMK7clt_TmXo7c/edit?usp=sharing
>
> On Thu, Jun 20, 2024 at 1:35 PM Luther Johnson
> <luther.johnson@makerlisp.com <mailto:luther.johnson@makerlisp.com>>
> wrote:
>
>     I agree that there are certainly times when CMake's leverage has
>     solved problems for people. My most visceral reactions were mostly
>     based on cases where no tool like CMake was really required at
>     all, but CMake had wormed its way into the consciousness of new
>     programmers who never learned make, and thought CMake was doing
>     them a great service. Bugged the hell out of me, this dumbing-down
>     of the general programming population. My bad experiences were all
>     as a consultant to teams that needed a lot of expert help, when
>     they had thrown CMake along with a lot of other unnecessary
>     complexity into their half-working solutions. So I guess it was
>     all tarred by the same flavor of badly conceived work. But then as
>     I tried to make my peace with the CMake build as it was, I got a
>     deeper understanding of how intrinsically irrational CMake is (and
>     again, behavior changing on the same builds depending on CMake
>     release versions.
>
>     So there certainly are times when something a little more
>     comprehensive, outside of make, is required. ./configure && make
>     is not so bad, it's not irrational, sometimes it's overkill, but
>     it works ... but only if the system is kind of Unix-y. If not you
>     may wind up doing a lot of work to pretend it's more Unix-y, so
>     instead of porting your software, you're porting it to a common
>     Unix-like subset, then emulating that Unix-like subset on your
>     platform, both ends against the middle. That can be ultimately
>     counter-productive too.
>
>     I have an emotional reaction when I see the porting problem become
>     transformed into adherence to the "one true way", be it Unix, or
>     one build system or another. Because you're now just re-casting
>     the problem into acceptance of that other tool or OS core as the
>     way it should be. Instead of getting your thing to work on the
>     other platform, by translating from what your application wants,
>     into how to do it on whatever system, you're changing your
>     application to be more like what the "one true system" wants to
>     see. You've given up control of your idea of your app's core OS
>     requirements, you've decided to "just give in and be UNiX (or
>     Windows, or whatever)". To me, that's backwards.
>
>     On 06/20/2024 12:59 PM, Warner Losh wrote:
>>     For me, precomputing an environment is the same as a wysiwyg
>>     editor: what you see is all you get. If it works for you, and the
>>     environment that's inferred from predefined CPP symbols is
>>     correct, then it's an easy solution. When it's not, and for me it
>>     often wasn't, it's nothing but pain and suffering and saying MF
>>     all the time (also not Make File)....  I was serious when I've
>>     said I've had more positive cmake experiences (which haven't been
>>     all that impressive: I'm more impressed with meson in this space,
>>     for example) than I ever had with IMakefiles, imake, xmkmf,
>>     etc...  But It's also clear that different people have lived
>>     through different hassles, and I respect that...
>>
>>     I've noticed too that we're relatively homogeneous these days:
>>     Everybody is a Linux box or Windows Box or MacOS, except for a
>>     few weird people on the fringes (like me). It's a lot easier to
>>     get things right enough w/o autotools, scons, meson, etc than it
>>     was in The Bad Old Days of the Unix Wars and the Innovation
>>     Famine that followed from the late 80s to the mid 2000s.... In
>>     that environment, there's one of two reactions: Test Everything
>>     or Least Common Denominator. And we've seen both represented in
>>     this thread.  As well as the 'There's so few environments, can't
>>     you precompute them all?' sentiment from newbies that never
>>     bloodied their knuckles with some of the less like Research Unix
>>     machines out there like AIX and HP/UX...  Or worse, Eunice...
>>
>>     Warner
>>
>>     On Thu, Jun 20, 2024 at 12:42 PM Adam Thornton
>>     <athornton@gmail.com <mailto:athornton@gmail.com>> wrote:
>>
>>
>>
>>             Someone clearly never used imake...
>>
>>
>>         There's a reason that the xmkmf command ends in the two
>>         letters it does, and I'm never going to believe it's "make file".
>>
>>         Adam
>>
>>         On Thu, Jun 20, 2024 at 11:34 AM Greg A. Woods
>>         <woods@robohack.ca <mailto:woods@robohack.ca>> wrote:
>>
>>             At Thu, 20 Jun 2024 01:01:01 -0400, Scot Jenkins via TUHS
>>             <tuhs@tuhs.org <mailto:tuhs@tuhs.org>> wrote:
>>             Subject: [TUHS] Re: Version 256 of systemd boasts '42%
>>             less Unix philosophy' The Register
>>             >
>>             > "Greg A. Woods" <woods@robohack.ca
>>             <mailto:woods@robohack.ca>> wrote:
>>             >
>>             > > I will not ever allow cmake to run, or even exist, on
>>             the machines I
>>             > > control...
>>             >
>>             > I'm not a fan of cmake either.
>>             >
>>             > How do you deal with software that only builds with
>>             cmake (or meson,
>>             > scons, ... whatever the developer decided to use as the
>>             build tool)?
>>             > What alternatives exist short of reimplementing the
>>             build process in
>>             > a standard makefile by hand, which is obviously very
>>             time consuming,
>>             > error prone, and will probably break the next time you
>>             want to update
>>             > a given package?
>>
>>             The alternative _is_ to reimplement the build process.
>>
>>             For example, see:
>>
>>             https://github.com/robohack/yajl/
>>
>>             This example is a far more comprehensive rewrite than is
>>             usually
>>             necessary as I wanted a complete and portable example
>>             that could be used
>>             as the basis for further projects.
>>
>>             An example of a much simpler reimplementation:
>>
>>             http://cvsweb.NetBSD.org/bsdweb.cgi/src/external/mit/ctwm/bin/ctwm/Makefile?rev=1.12&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
>>
>>             --
>>                                                     Greg A. Woods
>>             <gwoods@acm.org <mailto:gwoods@acm.org>>
>>
>>             Kelowna, BC     +1 250 762-7675  RoboHack
>>             <woods@robohack.ca <mailto:woods@robohack.ca>>
>>             Planix, Inc. <woods@planix.com <mailto:woods@planix.com>>
>>                Avoncote Farms <woods@avoncote.ca
>>             <mailto:woods@avoncote.ca>>
>>
>


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

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

[Stuff Received]

On 2024-06-20 17:00, ron minnich wrote (in part):
> here's where I'd have to disagree: "./configure && make is not so bad, 
> it's not irrational, sometimes it's overkill, but it works"
> 
> because it doesn't. Work, that is. At least, for me.

And me.  (Many configure+gmake scripts fail on Solaris 11.)

S.

[TUHS] Version 256.1: Now slightly less likely to delete /home

[Jim Capp]

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


Enjoy. 

https://www.theregister.com/2024/06/20/systemd_2561_data_wipe_fix/ 


" Following closely after the release of version 256, version 256.1 fixes a handful of bugs. 
One of these is emphatically not systemd-tmpfiles recursively deleting your entire home directory. 
That's a feature." 










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

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

[Steve Nickolas]

So I have one program that relies on stuff that might vary from system to 
system.  I just make use of functionality common to gmake and bmake, and 
expect the system to be in a reasonable state that the various detection 
scripts provided by the libraries work, and have "#ifdef" take care of the 
rest, so for most systems building the program is just "make".

Works on Linux, OSX and a few other unices.

I have a separate build script I use to build the Windows version.

-uso.

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

[David Arnold]

> On 19 Jun 2024, at 09:03, Warner Losh <imp@bsdimp.com> wrote:
> 
> Someone clearly never used imake...

The authors of cmake?



d

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

[Greg A. Woods]

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

At Tue, 18 Jun 2024 17:03:07 -0600, Warner Losh <imp@bsdimp.com> wrote:
Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register
> 
> [1  <text/plain; UTF-8 (quoted-printable)>]
> On Tue, Jun 18, 2024, 4:50 PM Greg A. Woods <woods@robohack.ca> wrote:
> 
> > At Tue, 18 Jun 2024 04:52:51 +0000, segaloco via TUHS <tuhs@tuhs.org>
> > wrote:
> > Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix
> > philosophy' The Register
> > >
> > > That's not
> > > to diminish the real help of things like autotools and CMake,
> >
> > Oh, that strikes a nerve.
> >
> > CMake is the very antithesis of a good tool.  It doesn't help.  I think
> > it is perhaps the worst abomination EVER in the world of software tools,
> > and especially amongst software construction tools.
> >
> 
> Someone clearly never used imake...

Heh heh!

I've grovelled deeply in the innards of X11's use of imake, but I assert
that it's atrocities pale in comparison to those of cmake.  At least
there were real parsers and proper syntax for imake, and indeed it even
built on and used other existing well known tools!

-- 
					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: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Luther Johnson]

On 06/18/2024 03:50 PM, Greg A. Woods wrote:
> At Tue, 18 Jun 2024 04:52:51 +0000, segaloco via TUHS <tuhs@tuhs.org> wrote:
> Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register
>> That's not
>> to diminish the real help of things like autotools and CMake,
> Oh, that strikes a nerve.
>
> CMake is the very antithesis of a good tool.  It doesn't help.  I think
> it is perhaps the worst abomination EVER in the world of software tools,
> and especially amongst software construction tools.
>
> --
> 					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>
I agree with Greg here. In fact even if it was well done, it is
declaring something that wasn't really a problem, to be a problem, to
insert itself as the solution, but I think it's just extra stuff and
steps that ultimately obfuscates and creates yet more dependencies.
Self-serving complexity.

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

[Nevin Liber]

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

On Tue, Jun 18, 2024 at 7:09 PM Luther Johnson <luther.johnson@makerlisp.com>
wrote:

> I agree with Greg here. In fact even if it was well done, it is
> declaring something that wasn't really a problem, to be a problem, to
> insert itself as the solution, but I think it's just extra stuff and
> steps that ultimately obfuscates and creates yet more dependencies.
>

That's a really bold claim.  You may not like the solution (I don't tend to
comment on it because unlike some here, I recognize that build systems are
a Hard Problem and I don't know how to make a better solution), but that
doesn't mean it isn't solving real problems.

But I'll bite.  There was the claim by Larry McVoy that "Writing Makefiles
isn't that hard".

Please show these beautiful makefiles for a non-toy non-trivial product
(say, something like gcc or llvm), which make it easy to change platforms,
underlying compilers, works well with modern multicore processors, gets the
dependencies right (one should never have to type "make clean" to get a
build working correctly), etc. and doesn't require blindly running some 20K
line shell script like "configure" to set it up.
-- 
 Nevin ":-)" Liber  <mailto:nl <nevin@eviloverlord.com>iber@gmail.com>
+1-847-691-1404

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

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

[segaloco via TUHS]

On Tuesday, June 18th, 2024 at 5:46 PM, Nevin Liber <nliber@gmail.com> wrote:

> On Tue, Jun 18, 2024 at 7:09 PM Luther Johnson <luther.johnson@makerlisp.com> wrote:
> 
> > I agree with Greg here. In fact even if it was well done, it is
> > declaring something that wasn't really a problem, to be a problem, to
> > insert itself as the solution, but I think it's just extra stuff and
> > steps that ultimately obfuscates and creates yet more dependencies.
> 
> 
> That's a really bold claim. You may not like the solution (I don't tend to comment on it because unlike some here, I recognize that build systems are a Hard Problem and I don't know how to make a better solution), but that doesn't mean it isn't solving real problems.
> 
> But I'll bite. There was the claim by Larry McVoy that "Writing Makefiles isn't that hard".
> 
> Please show these beautiful makefiles for a non-toy non-trivial product (say, something like gcc or llvm), which make it easy to change platforms, underlying compilers, works well with modern multicore processors, gets the dependencies right (one should never have to type "make clean" to get a build working correctly), etc. and doesn't require blindly running some 20K line shell script like "configure" to set it up.
> --
> Nevin ":-)" Liber <mailto:nliber@gmail.com> +1-847-691-1404

Not sure if this counts but technically the Linux kernel build itself is largely interfaced with via a makefile.  The makefile itself may not necessarily be doing *all* the heavy lifting, but you don't start with a "./configure" this or "cmake ." that or "meson setup build" etc, you just run make to get at things like configuration, building, etc.

Linux and it's various configurators do point to an alternate, albeit also more-than-a-makefile, way to do things.  POSIX make's lack of conditionals for me is the main sticking point, but one solution is separate "parent" makefiles for certain conditions, with common definitions and rules being put in an include file.  Then you, say, have one makefile per combination of ASFLAGS/LDFLAGS for a specific build scenario, then you can call your script that interprets conditions and calls the right makefile.  You've still got a script involved, but one consisting of a handful of lines you wrote and understand well rather than oodles of generated code.

Like systemd though, I think it comes down to the use-case.  Most folks aren't thinking about POSIX through and through in their work probably, if they can cross-compile for various targets using one type of host machine, they only have to worry about their application, not their build system, playing by the POSIX rules.

I say none of this to defend anything, especially CMake, I'm also not a fan, but it plays to the unfortunate norm out there where the build system just has to work for the author and/or high-profile contributors to a project, focusing on ensuring something will build anywhere probably isn't in most folks' immediate interest.  Truth be told, the main thing that does have me focus on it is most of the stuff I work on these days is producing disassemblies of 80s/90s video games, something where the focus of the work *is* the quality of code representation, buildability, ease of modification, etc. so keeping such a thing from being tightly coupled to a specific platform does play heavily into my recent interactions with least common denominators.  That and I'm nomadic with operating environments, so I don't want to paint myself into a corner where a project I'm working on is suddenly out in the rain because I bumped back to FreeBSD from Linux or out into some non-UNIX environment entirely.  Sticking to POSIX make et. al. rules where possible minimizes that.

- Matt G.

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

[Luther Johnson]

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

I don't think any makefiles I've written do all of that. I guess I don't
expect all of that in one place. So i will have some makefiles that are
really portable, because they are very compute-bound or their interface
to the world is something else generic, like files. And then for more
platform-specific parts I would have different makefiles for different
platforms.

One-button, one command-build (that seems) identical for all platforms,
is not that important to me. And yes, sometimes I write scripts to do
the parts of a build in sequence. And I don't consider any of this
'hard', but I'm not trying make the builds look like they are the same,
even if they are really quite different. The GNU ./configure, make model
is one model. CMake and other makefile generators are another. But I
have used several compilers or other general purpose tools that have
more than one makefile or build script, depending on the platform, and I
just take the tool for what it is, and use it. And when I have to debug
or change something about the build, it's MUCH easier to work with
makefiles and build scripts than it is to extend configure scripts, or
extend a build-specification in a build-tool-specific language. In my
experience, so far. But some people will get into configure and/or CMake
or any of the others and learn how to be productive that way. More power
to them, but I don't enjoy doing that. When I have had to use CMake, it
seemed to require more specification on my part to generate all sorts of
crufty state, so every build was not necessarily the same, unless I used
the right commands or deleted all these extra directories full of
persistence from the last CMake or build, to write all these weird,
generated, unreadablemakefiles calling makefiles, doing no more than I
could easily do by hand in one makefile. No, my hand-written makefiles
will not be absolutely universal, or appear to be, but they will work in
a way I can predict, and that is of great value to me.

On 06/18/2024 05:46 PM, Nevin Liber wrote:
> On Tue, Jun 18, 2024 at 7:09 PM Luther Johnson
> <luther.johnson@makerlisp.com <mailto:luther.johnson@makerlisp.com>>
> wrote:
>
>     I agree with Greg here. In fact even if it was well done, it is
>     declaring something that wasn't really a problem, to be a problem, to
>     insert itself as the solution, but I think it's just extra stuff and
>     steps that ultimately obfuscates and creates yet more dependencies.
>
>
> That's a really bold claim.  You may not like the solution (I don't
> tend to comment on it because unlike some here, I recognize that build
> systems are a Hard Problem and I don't know how to make a better
> solution), but that doesn't mean it isn't solving real problems.
>
> But I'll bite.  There was the claim by Larry McVoy that "Writing
> Makefiles isn't that hard".
>
> Please show these beautiful makefiles for a non-toy non-trivial
> product (say, something like gcc or llvm), which make it easy to
> change platforms, underlying compilers, works well with modern
> multicore processors, gets the dependencies right (one should never
> have to type "make clean" to get a build working correctly), etc. and
> doesn't require blindly running some 20K line shell script like
> "configure" to set it up.
> --
>  Nevin ":-)" Liber  <mailto:nl
> <mailto:nevin@eviloverlord.com>iber@gmail.com
> <mailto:iber@gmail.com>>  +1-847-691-1404


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

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

[Luther Johnson]

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

To be fair, makefiles are specifications in a build-tool specific
language. But it is one language I already know, and it is one that
seems to be well-formed, translates to very definite actions on
conditions, and I get to choose those actions. I guess it works for me
if I do my part, and I can't really see what CMake does for me that I
can't do for myself.

On 06/18/2024 08:07 PM, Luther Johnson wrote:
>
> I don't think any makefiles I've written do all of that. I guess I
> don't expect all of that in one place. So i will have some makefiles
> that are really portable, because they are very compute-bound or their
> interface to the world is something else generic, like files. And then
> for more platform-specific parts I would have different makefiles for
> different platforms.
>
> One-button, one command-build (that seems) identical for all
> platforms, is not that important to me. And yes, sometimes I write
> scripts to do the parts of a build in sequence. And I don't consider
> any of this 'hard', but I'm not trying make the builds look like they
> are the same, even if they are really quite different. The GNU
> ./configure, make model is one model. CMake and other makefile
> generators are another. But I have used several compilers or other
> general purpose tools that have more than one makefile or build
> script, depending on the platform, and I just take the tool for what
> it is, and use it. And when I have to debug or change something about
> the build, it's MUCH easier to work with makefiles and build scripts
> than it is to extend configure scripts, or extend a
> build-specification in a build-tool-specific language. In my
> experience, so far. But some people will get into configure and/or
> CMake or any of the others and learn how to be productive that way.
> More power to them, but I don't enjoy doing that. When I have had to
> use CMake, it seemed to require more specification on my part to
> generate all sorts of crufty state, so every build was not necessarily
> the same, unless I used the right commands or deleted all these extra
> directories full of persistence from the last CMake or build, to write
> all these weird, generated, unreadablemakefiles calling makefiles,
> doing no more than I could easily do by hand in one makefile. No, my
> hand-written makefiles will not be absolutely universal, or appear to
> be, but they will work in a way I can predict, and that is of great
> value to me.
>
> On 06/18/2024 05:46 PM, Nevin Liber wrote:
>> On Tue, Jun 18, 2024 at 7:09 PM Luther Johnson
>> <luther.johnson@makerlisp.com <mailto:luther.johnson@makerlisp.com>>
>> wrote:
>>
>>     I agree with Greg here. In fact even if it was well done, it is
>>     declaring something that wasn't really a problem, to be a problem, to
>>     insert itself as the solution, but I think it's just extra stuff and
>>     steps that ultimately obfuscates and creates yet more dependencies.
>>
>>
>> That's a really bold claim.  You may not like the solution (I don't
>> tend to comment on it because unlike some here, I recognize that
>> build systems are a Hard Problem and I don't know how to make a
>> better solution), but that doesn't mean it isn't solving real problems.
>>
>> But I'll bite.  There was the claim by Larry McVoy that "Writing
>> Makefiles isn't that hard".
>>
>> Please show these beautiful makefiles for a non-toy non-trivial
>> product (say, something like gcc or llvm), which make it easy to
>> change platforms, underlying compilers, works well with modern
>> multicore processors, gets the dependencies right (one should never
>> have to type "make clean" to get a build working correctly), etc. and
>> doesn't require blindly running some 20K line shell script like
>> "configure" to set it up.
>> --
>>  Nevin ":-)" Liber  <mailto:nl
>> <mailto:nevin@eviloverlord.com>iber@gmail.com
>> <mailto:iber@gmail.com>> +1-847-691-1404
>


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

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

[Luther Johnson]

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

I think there is a parallel to the systemd discussion here, again. Both
CMake and systemd ask you to declare properties or qualities to be
ingested into the abstract model of the build or init problem, that is
their worldview, and then, the 'engine' will consume that and decide
what to do and how to do it. Whereas init scripts and makefiles say
exactly what to do when, and the abstract model of what is to be done is
in the mind of the author of the build or the init process. Makefiles
and init scripts are prescriptive, Cmake and systemd input are descriptive.

My problem with CMake has been that the abstract model that the CMake
engine has in mind was not docmented, to my satisfaction, or I couldn't
find the answers to questions I had. The 'algorithm' was not published,
so to speak, or I couldn't find it. Unless I read the CMake code and can
understand it well enough to predict what it will do. Maybe CMake
aficionados do just that, I don't know. To me, both systemd and CMake
seem much more opaque and mysterious. If I have to read the code for a
tool to use it effectively, that seems wrong to me. Maybe I just haven't
read the right books. Is there a 'nutshell' or similar book for CMake ?

These tools seem to have more complexity, and a different mission, then
/etc/rc or sysvinit scripts, or make. They are designed to solve a
problem that isn't a problem to me. I expect a little bit of human
attention to maintenance is required, for the actual problems I face,
not all possible problems, so that I could theoretically not ever know
how to solve those problems, because the tool would have done that for
me. If I could only learn the dark art of that tool.

On 06/18/2024 08:14 PM, Luther Johnson wrote:
>
> To be fair, makefiles are specifications in a build-tool specific
> language. But it is one language I already know, and it is one that
> seems to be well-formed, translates to very definite actions on
> conditions, and I get to choose those actions. I guess it works for me
> if I do my part, and I can't really see what CMake does for me that I
> can't do for myself.
>
> On 06/18/2024 08:07 PM, Luther Johnson wrote:
>>
>> I don't think any makefiles I've written do all of that. I guess I
>> don't expect all of that in one place. So i will have some makefiles
>> that are really portable, because they are very compute-bound or
>> their interface to the world is something else generic, like files.
>> And then for more platform-specific parts I would have different
>> makefiles for different platforms.
>>
>> One-button, one command-build (that seems) identical for all
>> platforms, is not that important to me. And yes, sometimes I write
>> scripts to do the parts of a build in sequence. And I don't consider
>> any of this 'hard', but I'm not trying make the builds look like they
>> are the same, even if they are really quite different. The GNU
>> ./configure, make model is one model. CMake and other makefile
>> generators are another. But I have used several compilers or other
>> general purpose tools that have more than one makefile or build
>> script, depending on the platform, and I just take the tool for what
>> it is, and use it. And when I have to debug or change something about
>> the build, it's MUCH easier to work with makefiles and build scripts
>> than it is to extend configure scripts, or extend a
>> build-specification in a build-tool-specific language. In my
>> experience, so far. But some people will get into configure and/or
>> CMake or any of the others and learn how to be productive that way.
>> More power to them, but I don't enjoy doing that. When I have had to
>> use CMake, it seemed to require more specification on my part to
>> generate all sorts of crufty state, so every build was not
>> necessarily the same, unless I used the right commands or deleted all
>> these extra directories full of persistence from the last CMake or
>> build, to write all these weird, generated, unreadablemakefiles
>> calling makefiles, doing no more than I could easily do by hand in
>> one makefile. No, my hand-written makefiles will not be absolutely
>> universal, or appear to be, but they will work in a way I can
>> predict, and that is of great value to me.
>>
>> On 06/18/2024 05:46 PM, Nevin Liber wrote:
>>> On Tue, Jun 18, 2024 at 7:09 PM Luther Johnson
>>> <luther.johnson@makerlisp.com <mailto:luther.johnson@makerlisp.com>>
>>> wrote:
>>>
>>>     I agree with Greg here. In fact even if it was well done, it is
>>>     declaring something that wasn't really a problem, to be a
>>>     problem, to
>>>     insert itself as the solution, but I think it's just extra stuff and
>>>     steps that ultimately obfuscates and creates yet more dependencies.
>>>
>>>
>>> That's a really bold claim.  You may not like the solution (I don't
>>> tend to comment on it because unlike some here, I recognize that
>>> build systems are a Hard Problem and I don't know how to make a
>>> better solution), but that doesn't mean it isn't solving real problems.
>>>
>>> But I'll bite.  There was the claim by Larry McVoy that "Writing
>>> Makefiles isn't that hard".
>>>
>>> Please show these beautiful makefiles for a non-toy non-trivial
>>> product (say, something like gcc or llvm), which make it easy to
>>> change platforms, underlying compilers, works well with modern
>>> multicore processors, gets the dependencies right (one should never
>>> have to type "make clean" to get a build working correctly), etc.
>>> and doesn't require blindly running some 20K line shell script like
>>> "configure" to set it up.
>>> --
>>>  Nevin ":-)" Liber  <mailto:nl
>>> <mailto:nevin@eviloverlord.com>iber@gmail.com
>>> <mailto:iber@gmail.com>> +1-847-691-1404
>>
>


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

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

[arnold]

Luther Johnson <luther.johnson@makerlisp.com> wrote:

> and I can't really see what CMake does for me that I
> can't do for myself.

I suspect that it's biggest advantage is that the same (set of)
CMake input files can produce Makefiles, config files for Visual
Studio, and also for Apple's IDE / build system.

I also don't like it; it mixes system configuration with build
dependencies and is ugly and hard to learn. But that's a separate
issue.

Arnold

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

[sjenkin]

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

Not responding to this email, apologies to Luther and Arnold.

I’ve posted on COFF a related note on Unix Philosophy, 
Would appreciate comments & corrections.

	<https://www.tuhs.org/mailman3/hyperkitty/list/coff@tuhs.org/thread/KHQYFL6KMD3HZ73I2R6C653XWO23F72S/>

> On 19 Jun 2024, at 16:50, arnold@skeeve.com wrote:
> 
> Luther Johnson <luther.johnson@makerlisp.com> wrote:
> 
>> and I can't really see what CMake does for me that I
>> can't do for myself.
> 
> I suspect that it's biggest advantage is that the same (set of)
> CMake input files can produce Makefiles, config files for Visual
> Studio, and also for Apple's IDE / build system.
> 
> I also don't like it; it mixes system configuration with build
> dependencies and is ugly and hard to learn. But that's a separate
> issue.
> 
> Arnold

--
Steve Jenkin, IT Systems and Design 
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA

mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin


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

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

[Ralph Corderoy]

Hi,

Luther Johnson:
> And when I have to debug or change something about the build, it's
> MUCH easier to work with makefiles and build scripts than it is to
> extend configure scripts, or extend a build-specification in
> a build-tool-specific language.  In my experience, so far.

Eric Raymond recently started autodafe which chews over autotools'
inputs and outputs to simplify its use or help move away from it to an
editable makefile.
https://gitlab.com/esr/autodafe/-/blob/master/README.adoc

-- 
Cheers, Ralph.

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

[Larry McVoy]

On Tue, Jun 18, 2024 at 07:46:15PM -0500, Nevin Liber wrote:
> But I'll bite.  There was the claim by Larry McVoy that "Writing Makefiles
> isn't that hard".
> 
> Please show these beautiful makefiles for a non-toy non-trivial product

Works on *BSD, MacOS, Windows, Linux on a bunch of different architectures,
Solaris, HPUX, AIX, IRIX, Tru64, etc.

# Copyright 1999-2016 BitMover, Inc

# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at

#     http://www.apache.org/licenses/LICENSE-2.0

# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

# Makefile for BitKeeper.

# Bitmover makefiles try to provide the following targets:
#
# all		build everything under the current directory
#
# clean		remove all objects and programs
#
# clobber	run clean plus 'bk -r. clean'
#
# srcs		bk get all sources in current directory
#
# tags		build ctags for all srcs (only needed in this (top) makefile)
#
# tags.local	build ctags for srcs under current directory relative to top
#
#---
# Special make variables commonly used this makefile:
#   $@	target
#   $^  all sources
#   $<  first source

INSTALLED_BK	?= $(shell bash -c "cd / && command -v bk")
INREPO  ?= $(shell bash -c "test -d ../.bk && echo true || echo false")
HERE    := $(shell pwd)
ROOT	:= $(shell dirname $(HERE))
REPO    := $(notdir $(ROOT))
URL     := $(shell echo bk://work/$(ROOT) | sed s,/home/bk/,,)
LOG	= $(shell echo LOG-`bk getuser`)
OSTYPE  := $(shell bash -c 'echo $$OSTYPE')

include conf.mk

## Which hosts are used for producing nightly builds
NIGHTLY_HOSTS	:= macos106 win7-vm debian40 debian40-64

ifeq "$(OSTYPE)" "msys"
	SYS=win32
	EXE=.exe
	XTRA=win32
	ifeq (,$(INSTALLED_BK))
		# BINDIR should really be :C:/Program Files/BitKeeper
		# The shell can not handle space in pathname, so
		# we use the short name here
		BINDIR := "C:/PROGRA~1/BITKEE~1"
	else
		BINDIR := $(shell bk pwd -s "`bk _registry get 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion' ProgramFilesDir`/BitKeeper")
	endif
	INSTALL=installdir
	RESOURCE=bkres.o
	UWT_C=$(patsubst %,win32/uwtlib/%.c, wapi_intf wcrt_intf)
	BKGUI=bkg$(EXE)
	BKG_O=bkg.o
else
	SYS=unix
	EXE=
	# You can set this to anywhere you like and do a 
	# build production" and you'll have an installed BitKeeper.
	ifeq (,$(INSTALLED_BK))
		BINDIR := /usr/local/bitkeeper
	else
		BINDIR := $(shell "$(INSTALLED_BK)" bin)
	endif
	INSTALL=install
	RESOURCE=
endif

# By default, we don't print verbose output. If you want to see
# the full compiler command line, use 'make V=1'
# The trick is to do "$(Q)$(CC)" instead of just "$(CC)" so that if
# Q is not set, it's just "$(CC)" and if Q is set to @ it becomes
# a quiet "@$(CC)".
# For the verbose messages, gmake provides
# $(if $(Q),<then>,<else>)
# so we just conditionalize on Q. Empty is false.
ifndef V
	Q=@
	export Q
endif

BK=./bk$(EXE)
G	=-g
TRIAL	=0
IMGDIR	=$(HERE)/tmp/bitkeeper

# Handle warning arguments in GCC
#
# -Wall enables a bunch of warnings by default
# -Wno-parentheses shuts up "suggest parentheses around assignment ...".
#  Unfortunately it also turns off dangling else warnings.
# -Wno-char-subscripts shuts up "subscript has type char", which comes
#  up all the time with broken <ctype.h> implementations.  
#  (renabled in GCC3 since it supresses warnings in system files by default)
# -Wno-format-y2k supresses complains about '%y' in strftime formats
# -Wstrict-prototypes    Don't allow non-ansi function declarations
WARNINGS=-Wall -Wno-parentheses -Wno-char-subscripts -Wno-format-y2k \
	-Wstrict-prototypes

# Warnings enabled with GCC newer than 3.0
#
# -Wredundant-decls	  Declaring same function twice
# -Wmissing-declarations  Functions without a prototype
WARNINGS_GCC3=-Wchar-subscripts -Wredundant-decls -Wmissing-declarations

# Warnings enabled with GCC newer than 4.0
#
# -Wextra  enable a bunch of random things (called -Wextra in newer gccs)
# -Wno-pointer-sign  Suppress warnings about changing the signs of pointers
# -Wno-sign-compare  Suppress warnings about comparing signed and unsigned vars
# -Wno-unsed-parameter Support warnings about function parameters that are 
#  no used
# -Wno-missing-field-initializers
# -Wdeclaration-after-statement Warn if someone does a C++ thing of declaring
#  a variable in the middle of a block
WARNINGS_GCC4=-Wextra -Wno-pointer-sign -Wno-sign-compare \
	-Wno-unused-parameter -Wno-missing-field-initializers \
	-Wdeclaration-after-statement -Wpointer-arith

# Warnings enabled with GCC newer than 5.0
#
# -Wno-unusedr-esult Do not warn if a caller ignores return value
WARNINGS_GCC5=-Wno-unused-result

WARNINGS_GCC6= -Wno-misleading-indentation

# XXX could not get -Wimplicit-fallthrough=3 to work
WARNINGS_GCC7= -Wno-implicit-fallthrough

# Other options to consider enabling in the future:
#
# -Wnested-externs Prototypes declared in a function
# -Wwrite-string warn in string constant is passed to a char *
# -Wmissing-prototypes
# -Wunused-parameter
# -Wold-style-definition Would be nice, but zlib falls all over here

GCC_MAJOR_REV=$(shell $(CC) -dumpversion | sed 's/\..*//')
GCC_MINOR_REV=$(shell $(CC) -dumpversion | sed 's/.*\.//')
ifeq ($(GCC_MAJOR_REV),3)
	WARNINGS += $(WARNINGS_GCC3)
endif
ifeq ($(GCC_MAJOR_REV),4)
	WARNINGS += $(WARNINGS_GCC3) $(WARNINGS_GCC4)
	ifeq ($(shell expr $(GCC_MINOR_REV) \> 5), 1)
		WARNINGS += -Wno-unused-result
	endif
endif
ifeq ($(GCC_MAJOR_REV),5)
	WARNINGS += $(WARNINGS_GCC3) $(WARNINGS_GCC4) $(WARNINGS_GCC5)
endif
ifeq ($(GCC_MAJOR_REV),6)
	WARNINGS += $(WARNINGS_GCC3) $(WARNINGS_GCC4) $(WARNINGS_GCC5) \
		    $(WARNINGS_GCC6)
endif
ifeq ($(GCC_MAJOR_REV),7)
	WARNINGS += $(WARNINGS_GCC3) $(WARNINGS_GCC4) $(WARNINGS_GCC5) \
		    $(WARNINGS_GCC6) $(WARNINGS_GCC7)
endif
ifeq ($(GCC_MAJOR_REV),8)
	WARNINGS += $(WARNINGS_GCC3) $(WARNINGS_GCC4) $(WARNINGS_GCC5) \
		    $(WARNINGS_GCC6) $(WARNINGS_GCC7) $(WARNINGS_GCC8)
endif

TRACE = -DUSE_TRACE

ifeq ($(shell uname -s), Darwin)
	XLIBS += -lresolv
	G	+= -DNOPROC
endif

ifeq (clang, $(findstring clang, $(shell $(CC) --version)))
	WARNINGS += -Wno-unused-value -Wno-empty-body -Wno-self-assign
endif

GCCOPTS=
CC_DEBUG=$(GCCOPTS) $G $(WARNINGS) $(TRACE)
CC_FAST_DEBUG=$(GCCOPTS) $G -O2 $(WARNINGS) $(TRACE)
CC_FAST	=$(CC_FAST_DEBUG)
CC_WALL=$(GCCOPTS) $G -DLINT $(WARNINGS) $(TRACE)
BINS	= $(BK) $(BKGUI)

# List of all objects in bk other than bk.o. Keep it sorted.
# But put bkver.o/cmd.o first, they generate headers.
OBJ =	bkver.o cmd.o \
	abort.o adler32.o alias.o admin.o annotate.o attributes.o \
	bam.o bisect.o bkd.o bkd_bam.o bkd_cd.o \
	bkd_changes.o bkd_client.o bkd_clone.o bkd_cmdtab.o \
	bkd_findkey.o bkd_http.o \
	bkd_id.o bkd_kill.o bkd_level.o bkd_misc.o bkd_nested.o \
	bkd_partition.o bkd_pull.o bkd_push.o bkd_pwd.o \
	bkd_r2c.o \
	bkd_rclone.o bkd_rootkey.o bkd_status.o bkd_synckeys.o bkd_version.o \
	bkverinfo.o \
	cat.o cfile.o changes.o config.o \
	check.o checksum.o clean.o cleanpath.o clone.o \
	cmdlog.o \
	collapse.o comment.o comments.o commit.o comps.o compress.o \
	contrib/cat.o \
	contrib/test.o \
	converge.o \
	cp.o \
	crypto.o \
	cset.o cset_inex.o csetprune.o csets.o cweave.o \
	dataheap.o dbfile.o delta.o diff.o dspec.o \
	export.o \
	fast-import.o fast-export.o features.o findmerge.o \
	find.o findcset.o fixtool.o fsl.o fslayer.o \
	g2bk.o gca.o get.o gethelp.o \
	gethost.o gettemp.o getuser.o gfiles.o glob.o \
	gnupatch.o graft.o grep.o \
	hash_nokey.o \
	heapdump.o help.o here.o here_check.o hostme.o http.o \
	idcache.o isascii.o info.o \
	key2rev.o key2path.o kill.o kv.o \
	libcommit.o libdiff.o libgraph.o librange.o \
	libsfiles.o lines.o \
	localtm.o lock.o locking.o \
	mail.o merge.o mklock.o \
	mailslot.o \
	mtime.o mv.o names.o ndiff.o nested.o newroot.o \
	opark.o \
	parent.o park.o partition.o \
	patch.o \
	pending.o preference.o proj.o \
	poly.o \
	populate.o \
	port/bkd_server.o \
	port/check_rsh.o \
	port/gethomedir.o \
	port/gethost.o port/getinput.o \
	port/getrealname.o port/getrusage.o port/globalroot.o port/gui.o \
	port/hostColonPath.o port/http_proxy.o \
	port/mail.o port/mnext.o port/networkfs.o \
	port/notifier.o port/ns_sock_host2ip.o port/platforminit.o \
	port/sccs_getuser.o port/sccs_lockfile.o \
	port/startmenu.o \
	port/svcinfo.o \
	port/uninstall.o \
	progress.o \
	prs.o pull.o push.o pwd.o \
	randombits.o randseed.o range.o rcheck.o rclone.o \
	rcs2bk.o rcsparse.o \
	receive.o redblack.o regex.o registry.o renumber.o \
	remap.o	remote.o \
	repo.o repos.o repogca.o repostats.o repotype.o \
	resolve.o resolve_binaries.o resolve_contents.o \
	resolve_create.o resolve_filetypes.o \
	resolve_flags.o resolve_generic.o resolve_modes.o \
	resolve_renames.o resolve_tags.o restore.o review.o \
	rm.o rmdel.o rmgone.o \
	root.o rset.o sane.o scat.o sccs.o sccs2bk.o \
	sccslog.o sccs_mv.o search.o sec2hms.o send.o sendbug.o \
	set.o setup.o sfio.o shrink.o sinfo.o \
	slib.o smerge.o sort.o startmenu.o \
	stat.o stattest.o status.o stripdel.o synckeys.o \
	tagmerge.o testcode.o tclsh.o takepatch.o \
	testdates.o time.o timestamp.o touch.o trigger.o \
	unbk.o undo.o undos.o unedit.o \
	unique.o uninstall.o unlink.o unlock.o unpull.o unrm.o unwrap.o upgrade.o \
	urlinfo.o \
	utils.o uu.o what.o which.o \
	xfile.o xflags.o \
	zone.o
SCRIPTS	= bk.script import \
	uuwrap unuuwrap gzip_uuwrap ungzip_uuwrap \
	b64wrap unb64wrap gzip_b64wrap ungzip_b64wrap
PSCR	= t/doit t/guitest
PROGS	= libc/mtst$(EXE)
LIBS	= libc/libc.a
DATA	= bkmsg.txt bkhelp.txt version \
	../doc/bk_refcard.ps ../doc/bk_refcard.pdf ../RELEASE-NOTES.md \
	dspec-changes dspec-changes-3.2 dspec-changes-4.0 dspec-changes-h \
	dspec-changes-hv dspec-changes-json dspec-changes-json-v \
	dspec-changes-vv dspec-log dspec-prs

CONTRIB = gui/ide/emacs/vc-bk.el contrib/git2bk.l
ALL	= PCRE $(LIBS) $(BINS) $(SCRIPTS) $(PSCR) $(XTRA) \
	$(PROGS) L-clean GUI L-doc $(DATA)

CFLAGS	= $(CC_DEBUG)
export CFLAGS
CPPFLAGS= -Ilibc $(TOMCRYPT_CPPFLAGS) $(TOMMATH_CPPFLAGS) \
	$(PCRE_CPPFLAGS) $(LZ4_CPPFLAGS) $(ZLIB_CPPFLAGS)
# Override this if you don't have it.
RANLIB	= ranlib

# list of C sources in bk
SRCS	= bk.c $(OBJ:.o=.c)
# list of headers in bk
HDRS	= bam.h bkd.h bk-features.h config.h configvars.def diff.h fsfuncs.h \
	  graph.h nested.h \
	  progress.h range.h rcs.h resolve.h sccs.h \
	  cmd.h poly.h proj.h redblack.h libc/system.h xfile.h

# list of non-C sources in bk
SCRSRCS	= bk.sh import.sh kwextract.pl uuwrap.sh unuuwrap.sh \
	  port/unix_platform.sh port/win32_platform.sh \
	  gzip_uuwrap.sh ungzip_uuwrap.sh \
	  substvars.sh b64wrap.sh gzip_b64wrap.sh \
	  unb64wrap.sh ungzip_b64wrap.sh 
MISC	= bkmsg.doc t/doit.sh

default:
	$(MAKE) p

SUBDIRS = libc $(shell ls -d tomcrypt tommath 2>/dev/null)

all: $(ALL)

prof:
	$(MAKE) CFLAGS="$G -pg -O2" LDFLAGS=-pg all
gprof:
	$(MAKE) CFLAGS="$G -DPROFILE -pg -O2" LDFLAGS=-pg all
ggprof:
	$(MAKE) CFLAGS="$G -DPROFILE -pg" LDFLAGS=-pg all
# Debugging...
d:
	$(MAKE) CFLAGS="$G -DDEBUG" all
debug:
	$(MAKE) CFLAGS="$G -DDEBUG" all
debug2:
	$(MAKE) CFLAGS="$G -DDEBUG2" all

gWall Wall:
	$(MAKE) CFLAGS="$(CC_WALL)" all

# production builds
p:  ## Build a production version of BitKeeper (no -g)
	$(MAKE) CFLAGS="$(CC_FAST) $(CF)" all

trial:
	$(MAKE) TRIAL="3*WEEK" CFLAGS="$(CC_FAST) $(CF)" all

trial3M:
	$(MAKE) TRIAL="3*MONTH" CFLAGS="$(CC_FAST) $(CF)" all

g:  ## Build a debug version of BitKeeper (-g)
	$(MAKE) CFLAGS="$(CC_DEBUG)" all
gO:
	$(MAKE) CFLAGS="$(CC_FAST_DEBUG)" all
gcov:
	$(MAKE) CFLAGS="$(CC_DEBUG) -fprofile-arcs -ftest-coverage" all

clean: L-clean FORCE  ## Remove object files and executables
	$(if $(Q),@echo Cleaning up,)
	$(Q)for sub in $(SUBDIRS) ../doc ../man gui utils win32 t t/win32; \
	do	$(MAKE) -C$$sub "CFLAGS=$(CFLAGS)" $@; \
	done
	$(Q)$(RM) $(OBJ) bk.o $(BKG_O) $(BINS) $(SCRIPTS) \
	    $(PSRC) $(PROGS)
	$(Q)$(RM) tags TAGS tags.local cscope.out substvars a.out cmd.c cmd.h \
		core *.bb *.bbg *.da *.gcov \
		bk.ico \
		bkmsg.txt bkhelp.txt bkver.c version \
		t/doit t/guitest kw2val_lookup.c bkres.o svcmgr.exe \
		conf.mk
	$(Q)$(RM) -r tmp
ifeq "$(OSTYPE)" "msys"
	$(Q)$(RM) -rf gnu/bin gnu/doc gnu/etc gnu/share
	$(Q)$(RM) -f gnu/m.ico gnu/msys.bat gnu/msys.ico
	$(Q)-rmdir gnu/tmp
	$(Q)-rmdir gnu
endif
ifeq (true,$(INREPO))
ifneq (,$(INSTALLED_BK))
	$(Q)EXTRALIST=`"$(INSTALLED_BK)" -Aax | \
		grep -v '~$$\|conf-.*\.mk$$'` ; \
	if [ "$$EXTRALIST" ]; then \
		echo "Clean left behind the following files:" ; \
		for file in $$EXTRALIST; do \
			echo "  $$file" ; \
		done ; \
	else \
		echo Clean complete ; \
	fi
endif
endif

clobber: clean FORCE ## Same as 'clean' but also bk clean files
	-@$(BK) -A clean

# XXX subdirs? (see tags)
wc: $(HDRS) $(SRCS) $(SCRSRCS) $(MISC)
	wc -l $(SRCS) $(HDRS) $(SCRSRCS) $(MISC)

get-e: FORCE
	-@$(BK) edit -qT `echo $(HDRS) $(SRCS) $(SCRSRCS) $(MISC) | fmt -1|sort -u`
	$(Q)$(MAKE) tags

srcs: $(SRCS) $(HDRS) FORCE
	$(Q)for sub in $(SUBDIRS); do $(BK) -r$$sub co -q; done

tags: $(patsubst %,%/tags.local, $(SUBDIRS)) tags.local
	@if [ -x $(BK) ]; \
	then	$(BK) get -Sq tags.skippats; \
		$(BK) _sort -u $^ | grep -v -ftags.skippats > $@; \
	else \
		bk get -Sq tags.skippats; \
		bk _sort -u $^ | grep -v -ftags.skippats > $@; \
	fi
	@echo ctags completed

tags.local: $(SRCS) $(HDRS)
	@ctags -f $@ --file-tags=yes --c-types=d+f+s+t $^

%/tags.local: FORCE
	$(Q)$(MAKE) -C $(dir $@) tags.local

ssh sshtest:
	$(MAKE) realtest

rsh rshtest:
	PREFER_RSH=YES $(MAKE) realtest

test tests:
	DO_REMOTE=NO $(MAKE) -C t

nonet nonet_test localtest:
	BK_NONET=YES PREFER_RSH=YES $(MAKE) realtest

realtest: $(ALL) t/doit
	-cd gui/tcltk && $(MAKE) clobber
	-$(BK) get -qS t/setup t/win32/win32_common
	$(BK) -rt get -qTS 't.*'
	cd t && ./doit -f 5

guitest: $(ALL) t/doit
	-$(BK) get -qS t/SCCS/s.g.* t/setup t/win32/win32_common t/guitest.tcl
	cd t && ./doit -g -i

t/doit: t/doit.sh substvars
	./substvars t/doit.sh > t/doit
	chmod +x t/doit

t/guitest: t/guitest.tcl
	cat < t/guitest.tcl > t/guitest

.PHONY: FORCE
FORCE:

win32: FORCE
	cd win32 && $(MAKE) BINDIR=$(BINDIR)
	cd t/win32 && $(MAKE)

# build libraries in sub directories
%.a: FORCE
	$(Q)$(MAKE) -C $(dir $@) $(notdir $@)

libc/mtst$(EXE): libc/libc.a FORCE
	$(Q)$(MAKE) -C libc mtst$(EXE)

bkres.o: win32/data/bk.rc bk.ico
	windres -i win32/data/bk.rc -o bkres.o

bk.ico: win32/data/bk.ico
	@cp -f win32/data/bk.ico .

ifneq ($(TOMCRYPT_SYSTEM),1)
# add dependency on building libraries first
$(BK): $(TOMCRYPT_LDFLAGS)
endif
ifneq ($(TOMMATH_SYSTEM),1)
# add dependency on building libraries first
$(BK): $(TOMMATH_LDFLAGS)
endif

$(BK): $(LIBS) bk.o $(RESOURCE) $(OBJ)
	$(if $(Q),@echo LINKING $(BK),)
	$(Q)$(LD) $(LDFLAGS) -o $@ bk.o $(OBJ) $(RESOURCE) $(LIBS) \
		$(TOMCRYPT_LDFLAGS) $(TOMMATH_LDFLAGS) \
		$(PCRE_LDFLAGS) $(LZ4_LDFLAGS) $(ZLIB_LDFLAGS) $(XLIBS)

# Windows only rule, BKGUI should be blank on other platforms
$(BKGUI): bkg.o $(RESOURCE)
	$(if $(Q),@echo LINKING $(BKGUI),)
	$(Q)$(LD) $(LDFLAGS) -o $@ bkg.o $(RESOURCE) -Llibc -lc -mwindows $(XLIBS)

bk.script: bk.sh port/$(SYS)_platform.sh
	cat port/$(SYS)_platform.sh bk.sh > bk.script
	chmod +x bk.script 

bkmsg.txt: bkmsg.doc
	cp -f $< $@

L-clean: FORCE
	@rm -f gui/share/doc/L/little.man ../man/man1/bk-little.1
	@rm -f ../man/man2help/bk-little-1.fmt

# has to run before bkhelp.txt but after GUI
L-doc L-docs: GUI FORCE
	@test -f gui/share/doc/L/little.man || { \
		echo Failed to build gui/share/doc/L/little.man; \
		exit 1; \
	}
	@if [ -s gui/share/doc/L/little.man ]; \
	then	cp gui/share/doc/L/little.man ../man/man1/bk-little.1; \
	else	cp ../man/man1/bk-little.1.pfmt ../man/man1/bk-little.1; \
	fi; \
	chmod +w ../man/man1/bk-little.1

bkhelp.txt: $(BK) version L-docs FORCE
	@rm -f ../man/man2help/bk-little.fmt
	@cd ../man/man2help && $(MAKE) BK=$(HERE)/bk$(EXE) helptxt
	@cp ../man/man2help/helptxt bkhelp.txt
	@rm -f ../man/man1/bk-little.1

html-docs: bkhelp.txt
	@cd ../man/man2html && $(MAKE)

../doc/bk_refcard.ps: $(BK) FORCE
	$(Q)echo building $@
	$(Q)-$(BK) -r../doc co -qS
	$(Q)$(MAKE) -C ../doc BK=$(HERE)/bk$(EXE) all

../doc/bk_refcard.pdf: ../doc/bk_refcard.ps

# This must be rebuilt every time because it includes the build time
bkver.c: utils/bk_version FORCE
	$(if $(Q),@echo Building $@,)
	$(Q)echo "#include \"sccs.h\"" > bk.v
	$(Q)echo "char *bk_platform = \""`./utils/bk_version`"\";" >> bk.v
	$(Q)echo "int test_release = "$(TRIAL)";" >> bk.v
	$(Q)echo "time_t bk_build_timet = "`perl -e "print time"`";" >> bk.v
	$(Q)echo "char *bk_build_dir = \""`pwd`"\";" >> bk.v
	$(Q)mv -f bk.v bkver.c

version: version.sh $(BK) utils/bk_version GUI FORCE
	bash version.sh > $@

%: %.sh
	$(if $(Q),@echo Building $@,)
	$(Q)$(RM) $@
	$(Q)cp $< $@
	$(Q)chmod +x $@

%: %.l
	$(if $(Q),@echo Not lexing $@,)

import: import.sh port/$(SYS)_platform.sh
	cat port/$(SYS)_platform.sh import.sh > import.T
	chmod +x import.T
	mv -f import.T import

# Quick and dirty target so we can make all the gui tools without the rest
.PHONY: GUI
GUI: PCRE $(BK)
	@$(MAKE) -Cgui BK=$(HERE)/bk$(EXE) gui

install: installdir
	tmp/bitkeeper/bk _install -d -f $(DESTDIR)$(BINDIR)
	@echo BitKeeper is installed in $(BINDIR)
	@echo We suggest you run:
	@echo
	@echo sudo $(BINDIR)/bk links /usr/local/bin
	@echo
	@echo to create the bk symlink.

installdir: utils/registry.tcl
	rm -rf $(IMGDIR) || exit 1
	mkdir -p $(IMGDIR)/contrib
	mkdir -p $(IMGDIR)/lscripts
	-$(BK) -rwww get -S
	-cp -f -r www $(IMGDIR)
	-$(BK) get -S $(CONTRIB)
	tar cf - $(BINS) $(SCRIPTS) lscripts gui/bin gui/lib gui/images \
		| (cd $(IMGDIR) && tar xf -)
	cp -f $(DATA) $(IMGDIR)
	cp -f $(CONTRIB) $(IMGDIR)/contrib
	(cd ../doc/nested && $(MAKE) install HTML=$(IMGDIR)/html)
	if [ $(SYS) = unix ]; \
	then	$(BK) get -S ../man/Makefile; \
		cd ../man && $(MAKE) install BINDIR=$(IMGDIR) ;\
	else \
		(cd win32 && $(MAKE) BINDIR=$(IMGDIR) install); \
		cp utils/registry.tcl $(IMGDIR)/gui/lib; \
	fi
	cd $(IMGDIR); \
	    find . -type l | \
		perl -ne 'chomp; $$a = readlink; print "$$a|$$_\n";'>symlinks; \
	    test -s symlinks || rm -f symlinks
	@true

image:  ## Build the installer (left in src/utils/bk-*)
	$(MAKE) p
	$(MAKE) _image

_image:
	$(MAKE) installdir
	${MAKE} -Cutils BINDIR=$(IMGDIR) "CC=$(CC)" "BK=$(HERE)/bk$(EXE)" "CFLAGS=$(CFLAGS)" image

crankturn: crank.sh remote.sh  ## Run a clean-build + regressions in cluster
	REPO=$(REPO) URL=$(URL) REMOTE=remote.sh LOG=$(LOG) bash crank.sh

cranksave: crank.sh remote.sh  ## Run a crankturn but save the built images
	REPO=$(REPO) URL=$(URL) REMOTE=remote.sh LOG=$(LOG) bash crank.sh save

crankstatus: crank.sh remote.sh  ## See how the crank is going
	REPO=$(REPO) URL=$(URL) REMOTE=remote.sh LOG=$(LOG) bash crank.sh status

crankrelease nightly: $(BK) crank.sh remote.sh  ## Do a BitKeeper release (or nightly build)
	@(TAG=$(shell $(BK) changes -r+ -d:TAG:) ; \
	test x$$TAG = x && { \
		echo Cannot crankrelease with a non-tagged tip ; \
		exit 1 ; \
	} ; \
	case $@ in \
	crankrelease ) \
		TYPE=release; DIR=/home/bk/images/$$TAG; \
		;; \
	nightly ) \
		TYPE=nightly; DIR=/home/bk/images/nightly; \
		HOSTS="$(NIGHTLY_HOSTS)" ; \
		;; \
	esac ; \
	test -d $$DIR || mkdir -p $$DIR ; \
	REPO=$(REPO) URL=$(URL) HOSTS=$$HOSTS REMOTE=remote.sh \
	    LOG=$(LOG) bash crank.sh $$TYPE ; \
	$(BK) -R get -qS ../RELEASE-NOTES.md ; \
	cp ../RELEASE-NOTES.md $$DIR ; \
	SAVED_WD=$(shell pwd) ; \
	cd $$DIR && chmod +rx bk-* >/dev/null 2>&1 ; \
	rm -f MD5SUMS ; \
	md5sum bk-* >> MD5SUMS ; \
	echo "Your images are in $$DIR" ; \
	case $@  in  \
	crankrelease ) \
	     	echo "Run './mkrelease $$TAG' to release this version of bk."; \
		;; \
	nightly ) \
#		cd $$SAVED_WD ; \
#		./mkupgrades --nightly $$TAG ; \
		;; \
	esac)

crankclean: crank.sh remote.sh
	REPO=$(REPO) URL=$(URL) REMOTE=remote.sh LOG=$(LOG) bash crank.sh clean

# This target assumes a bk repository
.PHONY: src-tar
src-tar: $(BK) version ## build tar.gz image for the current tree
ifeq (false,$(INREPO))
	$(error This target only works in a BK source repository)
else
	./bk here add default TCLTK
	$(Q)-mkdir -p tmp/src
	$(Q)(DIR=bk-$(shell $(BK) version -s) ; \
	     TAR="$$DIR".tar.gz ; \
	     echo "Creating $$TAR in tmp/src..." ; \
	     cd tmp/src ; \
	     rm -rf "$$DIR" ; \
	     ../../bk export -tplain -kwr+ -sdefault -sTCLTK "$$DIR" ; \
	     cat ../../version > "$$DIR/src/bkvers.txt" ; \
	     tar -czf "$$TAR" "$$DIR" ; \
	     rm -rf "$$DIR" ; \
	     echo Done ; \
	)
endif

# only depend on conf.mk.local if it exists
conf.mk: mkconf.sh $(wildcard conf.mk.local)
	sh mkconf.sh > $@ || { $(RM) $@; false; }

%.o: %.c
	$(if $(Q),@echo CC $<,)
	$(Q)$(CC) $(CFLAGS) $(CPPFLAGS) -c $< -o $@

port/startmenu.o: port/startmenu.c $(HDRS)
	$(if $(Q),@echo CC $<,)
	$(Q)$(CC) $(CFLAGS) -fno-strict-aliasing $(CPPFLAGS) -c $< -o $@

depend: $(SRCS)
	$(CC) -MM -MG -D_DEPEND $(SRCS) > depends

# for system.h we need to actually run libc's makefile because it includes
# calculated header files
libc/system.h: FORCE
	$(MAKE) -C libc system.h

libc/libc.a: libc/system.h

sccs.h: PCRE
.PHONY: PCRE
PCRE:
ifneq ($(PCRE_SYSTEM),1)
	$(MAKE) -Cgui/tcltk pcre
endif

$(OBJ) bk.o: $(HDRS)

cmd.c cmd.h: cmd.pl bk.sh $(filter bkd_%,$(SRCS))
	$(if $(Q),@echo Building $@,)
	$(Q)perl cmd.pl || (rm -f cmd.c cmd.h; exit 1)

# This parses slib.c and extracts the meta-data keywords expanded
# by kw2val() and passes them to gperf to generate hash lookup code.
slib.o:	kw2val_lookup.c
kw2val_lookup.c: slib.c kw2val.pl
	$(if $(Q),@echo Building $@,)
	$(Q)perl kw2val.pl slib.c || (rm -f kw2val_lookup.c; exit 1)

check-syntax:
	$(CC) $(CFLAGS) $(CPPFLAGS) -c -S ${CHK_SOURCES} -o /dev/null

# print a make variable  'make print-REPO'
#   http://www.cmcrossroads.com/article/printing-value-makefile-variable
print-%:
	@echo $* = \"$($*)\"

.PHONY: help

help:
	@grep -E -h '^[-a-zA-Z_\ ]+:.*?## .*$$' $(MAKEFILE_LIST) | sort | awk 'BEGIN {FS = ":.*?## "}; {printf "\033[36m%-30s\033[0m %s\n", $$1, $$2}'
	@echo Suggested: make -j12 image

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

[Warner Losh]

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

On Wed, Jun 19, 2024, 7:28 AM Larry McVoy <lm@mcvoy.com> wrote:

> On Tue, Jun 18, 2024 at 07:46:15PM -0500, Nevin Liber wrote:
> > But I'll bite.  There was the claim by Larry McVoy that "Writing
> Makefiles
> > isn't that hard".
> >
> > Please show these beautiful makefiles for a non-toy non-trivial product
>
> Works on *BSD, MacOS, Windows, Linux on a bunch of different architectures,
> Solaris, HPUX, AIX, IRIX, Tru64, etc.
>

The posted Makefile is no a strictly conforming POSIX Makefile, but uses
gmake extensions extensively... And eyes of the beholder may vary...

Warner

# Copyright 1999-2016 BitMover, Inc
>
> # Licensed under the Apache License, Version 2.0 (the "License");
> # you may not use this file except in compliance with the License.
> # You may obtain a copy of the License at
>
> #     http://www.apache.org/licenses/LICENSE-2.0
>
> # Unless required by applicable law or agreed to in writing, software
> # distributed under the License is distributed on an "AS IS" BASIS,
> # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> # See the License for the specific language governing permissions and
> # limitations under the License.
>
> # Makefile for BitKeeper.
>
> # Bitmover makefiles try to provide the following targets:
> #
> # all           build everything under the current directory
> #
> # clean         remove all objects and programs
> #
> # clobber       run clean plus 'bk -r. clean'
> #
> # srcs          bk get all sources in current directory
> #
> # tags          build ctags for all srcs (only needed in this (top)
> makefile)
> #
> # tags.local    build ctags for srcs under current directory relative to
> top
> #
> #---
> # Special make variables commonly used this makefile:
> #   $@  target
> #   $^  all sources
> #   $<  first source
>
> INSTALLED_BK    ?= $(shell bash -c "cd / && command -v bk")
> INREPO  ?= $(shell bash -c "test -d ../.bk && echo true || echo false")
> HERE    := $(shell pwd)
> ROOT    := $(shell dirname $(HERE))
> REPO    := $(notdir $(ROOT))
> URL     := $(shell echo bk://work/$(ROOT) | sed s,/home/bk/,,)
> LOG     = $(shell echo LOG-`bk getuser`)
> OSTYPE  := $(shell bash -c 'echo $$OSTYPE')
>
> include conf.mk
>
> ## Which hosts are used for producing nightly builds
> NIGHTLY_HOSTS   := macos106 win7-vm debian40 debian40-64
>
> ifeq "$(OSTYPE)" "msys"
>         SYS=win32
>         EXE=.exe
>         XTRA=win32
>         ifeq (,$(INSTALLED_BK))
>                 # BINDIR should really be :C:/Program Files/BitKeeper
>                 # The shell can not handle space in pathname, so
>                 # we use the short name here
>                 BINDIR := "C:/PROGRA~1/BITKEE~1"
>         else
>                 BINDIR := $(shell bk pwd -s "`bk _registry get
> 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion'
> ProgramFilesDir`/BitKeeper")
>         endif
>         INSTALL=installdir
>         RESOURCE=bkres.o
>         UWT_C=$(patsubst %,win32/uwtlib/%.c, wapi_intf wcrt_intf)
>         BKGUI=bkg$(EXE)
>         BKG_O=bkg.o
> else
>         SYS=unix
>         EXE=
>         # You can set this to anywhere you like and do a
>         # build production" and you'll have an installed BitKeeper.
>         ifeq (,$(INSTALLED_BK))
>                 BINDIR := /usr/local/bitkeeper
>         else
>                 BINDIR := $(shell "$(INSTALLED_BK)" bin)
>         endif
>         INSTALL=install
>         RESOURCE=
> endif
>
> # By default, we don't print verbose output. If you want to see
> # the full compiler command line, use 'make V=1'
> # The trick is to do "$(Q)$(CC)" instead of just "$(CC)" so that if
> # Q is not set, it's just "$(CC)" and if Q is set to @ it becomes
> # a quiet "@$(CC)".
> # For the verbose messages, gmake provides
> # $(if $(Q),<then>,<else>)
> # so we just conditionalize on Q. Empty is false.
> ifndef V
>         Q=@
>         export Q
> endif
>
> BK=./bk$(EXE)
> G       =-g
> TRIAL   =0
> IMGDIR  =$(HERE)/tmp/bitkeeper
>
> # Handle warning arguments in GCC
> #
> # -Wall enables a bunch of warnings by default
> # -Wno-parentheses shuts up "suggest parentheses around assignment ...".
> #  Unfortunately it also turns off dangling else warnings.
> # -Wno-char-subscripts shuts up "subscript has type char", which comes
> #  up all the time with broken <ctype.h> implementations.
> #  (renabled in GCC3 since it supresses warnings in system files by
> default)
> # -Wno-format-y2k supresses complains about '%y' in strftime formats
> # -Wstrict-prototypes    Don't allow non-ansi function declarations
> WARNINGS=-Wall -Wno-parentheses -Wno-char-subscripts -Wno-format-y2k \
>         -Wstrict-prototypes
>
> # Warnings enabled with GCC newer than 3.0
> #
> # -Wredundant-decls       Declaring same function twice
> # -Wmissing-declarations  Functions without a prototype
> WARNINGS_GCC3=-Wchar-subscripts -Wredundant-decls -Wmissing-declarations
>
> # Warnings enabled with GCC newer than 4.0
> #
> # -Wextra  enable a bunch of random things (called -Wextra in newer gccs)
> # -Wno-pointer-sign  Suppress warnings about changing the signs of pointers
> # -Wno-sign-compare  Suppress warnings about comparing signed and unsigned
> vars
> # -Wno-unsed-parameter Support warnings about function parameters that are
> #  no used
> # -Wno-missing-field-initializers
> # -Wdeclaration-after-statement Warn if someone does a C++ thing of
> declaring
> #  a variable in the middle of a block
> WARNINGS_GCC4=-Wextra -Wno-pointer-sign -Wno-sign-compare \
>         -Wno-unused-parameter -Wno-missing-field-initializers \
>         -Wdeclaration-after-statement -Wpointer-arith
>
> # Warnings enabled with GCC newer than 5.0
> #
> # -Wno-unusedr-esult Do not warn if a caller ignores return value
> WARNINGS_GCC5=-Wno-unused-result
>
> WARNINGS_GCC6= -Wno-misleading-indentation
>
> # XXX could not get -Wimplicit-fallthrough=3 to work
> WARNINGS_GCC7= -Wno-implicit-fallthrough
>
> # Other options to consider enabling in the future:
> #
> # -Wnested-externs Prototypes declared in a function
> # -Wwrite-string warn in string constant is passed to a char *
> # -Wmissing-prototypes
> # -Wunused-parameter
> # -Wold-style-definition Would be nice, but zlib falls all over here
>
> GCC_MAJOR_REV=$(shell $(CC) -dumpversion | sed 's/\..*//')
> GCC_MINOR_REV=$(shell $(CC) -dumpversion | sed 's/.*\.//')
> ifeq ($(GCC_MAJOR_REV),3)
>         WARNINGS += $(WARNINGS_GCC3)
> endif
> ifeq ($(GCC_MAJOR_REV),4)
>         WARNINGS += $(WARNINGS_GCC3) $(WARNINGS_GCC4)
>         ifeq ($(shell expr $(GCC_MINOR_REV) \> 5), 1)
>                 WARNINGS += -Wno-unused-result
>         endif
> endif
> ifeq ($(GCC_MAJOR_REV),5)
>         WARNINGS += $(WARNINGS_GCC3) $(WARNINGS_GCC4) $(WARNINGS_GCC5)
> endif
> ifeq ($(GCC_MAJOR_REV),6)
>         WARNINGS += $(WARNINGS_GCC3) $(WARNINGS_GCC4) $(WARNINGS_GCC5) \
>                     $(WARNINGS_GCC6)
> endif
> ifeq ($(GCC_MAJOR_REV),7)
>         WARNINGS += $(WARNINGS_GCC3) $(WARNINGS_GCC4) $(WARNINGS_GCC5) \
>                     $(WARNINGS_GCC6) $(WARNINGS_GCC7)
> endif
> ifeq ($(GCC_MAJOR_REV),8)
>         WARNINGS += $(WARNINGS_GCC3) $(WARNINGS_GCC4) $(WARNINGS_GCC5) \
>                     $(WARNINGS_GCC6) $(WARNINGS_GCC7) $(WARNINGS_GCC8)
> endif
>
> TRACE = -DUSE_TRACE
>
> ifeq ($(shell uname -s), Darwin)
>         XLIBS += -lresolv
>         G       += -DNOPROC
> endif
>
> ifeq (clang, $(findstring clang, $(shell $(CC) --version)))
>         WARNINGS += -Wno-unused-value -Wno-empty-body -Wno-self-assign
> endif
>
> GCCOPTS=
> CC_DEBUG=$(GCCOPTS) $G $(WARNINGS) $(TRACE)
> CC_FAST_DEBUG=$(GCCOPTS) $G -O2 $(WARNINGS) $(TRACE)
> CC_FAST =$(CC_FAST_DEBUG)
> CC_WALL=$(GCCOPTS) $G -DLINT $(WARNINGS) $(TRACE)
> BINS    = $(BK) $(BKGUI)
>
> # List of all objects in bk other than bk.o. Keep it sorted.
> # But put bkver.o/cmd.o first, they generate headers.
> OBJ =   bkver.o cmd.o \
>         abort.o adler32.o alias.o admin.o annotate.o attributes.o \
>         bam.o bisect.o bkd.o bkd_bam.o bkd_cd.o \
>         bkd_changes.o bkd_client.o bkd_clone.o bkd_cmdtab.o \
>         bkd_findkey.o bkd_http.o \
>         bkd_id.o bkd_kill.o bkd_level.o bkd_misc.o bkd_nested.o \
>         bkd_partition.o bkd_pull.o bkd_push.o bkd_pwd.o \
>         bkd_r2c.o \
>         bkd_rclone.o bkd_rootkey.o bkd_status.o bkd_synckeys.o
> bkd_version.o \
>         bkverinfo.o \
>         cat.o cfile.o changes.o config.o \
>         check.o checksum.o clean.o cleanpath.o clone.o \
>         cmdlog.o \
>         collapse.o comment.o comments.o commit.o comps.o compress.o \
>         contrib/cat.o \
>         contrib/test.o \
>         converge.o \
>         cp.o \
>         crypto.o \
>         cset.o cset_inex.o csetprune.o csets.o cweave.o \
>         dataheap.o dbfile.o delta.o diff.o dspec.o \
>         export.o \
>         fast-import.o fast-export.o features.o findmerge.o \
>         find.o findcset.o fixtool.o fsl.o fslayer.o \
>         g2bk.o gca.o get.o gethelp.o \
>         gethost.o gettemp.o getuser.o gfiles.o glob.o \
>         gnupatch.o graft.o grep.o \
>         hash_nokey.o \
>         heapdump.o help.o here.o here_check.o hostme.o http.o \
>         idcache.o isascii.o info.o \
>         key2rev.o key2path.o kill.o kv.o \
>         libcommit.o libdiff.o libgraph.o librange.o \
>         libsfiles.o lines.o \
>         localtm.o lock.o locking.o \
>         mail.o merge.o mklock.o \
>         mailslot.o \
>         mtime.o mv.o names.o ndiff.o nested.o newroot.o \
>         opark.o \
>         parent.o park.o partition.o \
>         patch.o \
>         pending.o preference.o proj.o \
>         poly.o \
>         populate.o \
>         port/bkd_server.o \
>         port/check_rsh.o \
>         port/gethomedir.o \
>         port/gethost.o port/getinput.o \
>         port/getrealname.o port/getrusage.o port/globalroot.o port/gui.o \
>         port/hostColonPath.o port/http_proxy.o \
>         port/mail.o port/mnext.o port/networkfs.o \
>         port/notifier.o port/ns_sock_host2ip.o port/platforminit.o \
>         port/sccs_getuser.o port/sccs_lockfile.o \
>         port/startmenu.o \
>         port/svcinfo.o \
>         port/uninstall.o \
>         progress.o \
>         prs.o pull.o push.o pwd.o \
>         randombits.o randseed.o range.o rcheck.o rclone.o \
>         rcs2bk.o rcsparse.o \
>         receive.o redblack.o regex.o registry.o renumber.o \
>         remap.o remote.o \
>         repo.o repos.o repogca.o repostats.o repotype.o \
>         resolve.o resolve_binaries.o resolve_contents.o \
>         resolve_create.o resolve_filetypes.o \
>         resolve_flags.o resolve_generic.o resolve_modes.o \
>         resolve_renames.o resolve_tags.o restore.o review.o \
>         rm.o rmdel.o rmgone.o \
>         root.o rset.o sane.o scat.o sccs.o sccs2bk.o \
>         sccslog.o sccs_mv.o search.o sec2hms.o send.o sendbug.o \
>         set.o setup.o sfio.o shrink.o sinfo.o \
>         slib.o smerge.o sort.o startmenu.o \
>         stat.o stattest.o status.o stripdel.o synckeys.o \
>         tagmerge.o testcode.o tclsh.o takepatch.o \
>         testdates.o time.o timestamp.o touch.o trigger.o \
>         unbk.o undo.o undos.o unedit.o \
>         unique.o uninstall.o unlink.o unlock.o unpull.o unrm.o unwrap.o
> upgrade.o \
>         urlinfo.o \
>         utils.o uu.o what.o which.o \
>         xfile.o xflags.o \
>         zone.o
> SCRIPTS = bk.script import \
>         uuwrap unuuwrap gzip_uuwrap ungzip_uuwrap \
>         b64wrap unb64wrap gzip_b64wrap ungzip_b64wrap
> PSCR    = t/doit t/guitest
> PROGS   = libc/mtst$(EXE)
> LIBS    = libc/libc.a
> DATA    = bkmsg.txt bkhelp.txt version \
>         ../doc/bk_refcard.ps ../doc/bk_refcard.pdf ../RELEASE-NOTES.md \
>         dspec-changes dspec-changes-3.2 dspec-changes-4.0 dspec-changes-h \
>         dspec-changes-hv dspec-changes-json dspec-changes-json-v \
>         dspec-changes-vv dspec-log dspec-prs
>
> CONTRIB = gui/ide/emacs/vc-bk.el contrib/git2bk.l
> ALL     = PCRE $(LIBS) $(BINS) $(SCRIPTS) $(PSCR) $(XTRA) \
>         $(PROGS) L-clean GUI L-doc $(DATA)
>
> CFLAGS  = $(CC_DEBUG)
> export CFLAGS
> CPPFLAGS= -Ilibc $(TOMCRYPT_CPPFLAGS) $(TOMMATH_CPPFLAGS) \
>         $(PCRE_CPPFLAGS) $(LZ4_CPPFLAGS) $(ZLIB_CPPFLAGS)
> # Override this if you don't have it.
> RANLIB  = ranlib
>
> # list of C sources in bk
> SRCS    = bk.c $(OBJ:.o=.c)
> # list of headers in bk
> HDRS    = bam.h bkd.h bk-features.h config.h configvars.def diff.h
> fsfuncs.h \
>           graph.h nested.h \
>           progress.h range.h rcs.h resolve.h sccs.h \
>           cmd.h poly.h proj.h redblack.h libc/system.h xfile.h
>
> # list of non-C sources in bk
> SCRSRCS = bk.sh import.sh kwextract.pl uuwrap.sh unuuwrap.sh \
>           port/unix_platform.sh port/win32_platform.sh \
>           gzip_uuwrap.sh ungzip_uuwrap.sh \
>           substvars.sh b64wrap.sh gzip_b64wrap.sh \
>           unb64wrap.sh ungzip_b64wrap.sh
> MISC    = bkmsg.doc t/doit.sh
>
> default:
>         $(MAKE) p
>
> SUBDIRS = libc $(shell ls -d tomcrypt tommath 2>/dev/null)
>
> all: $(ALL)
>
> prof:
>         $(MAKE) CFLAGS="$G -pg -O2" LDFLAGS=-pg all
> gprof:
>         $(MAKE) CFLAGS="$G -DPROFILE -pg -O2" LDFLAGS=-pg all
> ggprof:
>         $(MAKE) CFLAGS="$G -DPROFILE -pg" LDFLAGS=-pg all
> # Debugging...
> d:
>         $(MAKE) CFLAGS="$G -DDEBUG" all
> debug:
>         $(MAKE) CFLAGS="$G -DDEBUG" all
> debug2:
>         $(MAKE) CFLAGS="$G -DDEBUG2" all
>
> gWall Wall:
>         $(MAKE) CFLAGS="$(CC_WALL)" all
>
> # production builds
> p:  ## Build a production version of BitKeeper (no -g)
>         $(MAKE) CFLAGS="$(CC_FAST) $(CF)" all
>
> trial:
>         $(MAKE) TRIAL="3*WEEK" CFLAGS="$(CC_FAST) $(CF)" all
>
> trial3M:
>         $(MAKE) TRIAL="3*MONTH" CFLAGS="$(CC_FAST) $(CF)" all
>
> g:  ## Build a debug version of BitKeeper (-g)
>         $(MAKE) CFLAGS="$(CC_DEBUG)" all
> gO:
>         $(MAKE) CFLAGS="$(CC_FAST_DEBUG)" all
> gcov:
>         $(MAKE) CFLAGS="$(CC_DEBUG) -fprofile-arcs -ftest-coverage" all
>
> clean: L-clean FORCE  ## Remove object files and executables
>         $(if $(Q),@echo Cleaning up,)
>         $(Q)for sub in $(SUBDIRS) ../doc ../man gui utils win32 t t/win32;
> \
>         do      $(MAKE) -C$$sub "CFLAGS=$(CFLAGS)" $@; \
>         done
>         $(Q)$(RM) $(OBJ) bk.o $(BKG_O) $(BINS) $(SCRIPTS) \
>             $(PSRC) $(PROGS)
>         $(Q)$(RM) tags TAGS tags.local cscope.out substvars a.out cmd.c
> cmd.h \
>                 core *.bb *.bbg *.da *.gcov \
>                 bk.ico \
>                 bkmsg.txt bkhelp.txt bkver.c version \
>                 t/doit t/guitest kw2val_lookup.c bkres.o svcmgr.exe \
>                 conf.mk
>         $(Q)$(RM) -r tmp
> ifeq "$(OSTYPE)" "msys"
>         $(Q)$(RM) -rf gnu/bin gnu/doc gnu/etc gnu/share
>         $(Q)$(RM) -f gnu/m.ico gnu/msys.bat gnu/msys.ico
>         $(Q)-rmdir gnu/tmp
>         $(Q)-rmdir gnu
> endif
> ifeq (true,$(INREPO))
> ifneq (,$(INSTALLED_BK))
>         $(Q)EXTRALIST=`"$(INSTALLED_BK)" -Aax | \
>                 grep -v '~$$\|conf-.*\.mk$$'` ; \
>         if [ "$$EXTRALIST" ]; then \
>                 echo "Clean left behind the following files:" ; \
>                 for file in $$EXTRALIST; do \
>                         echo "  $$file" ; \
>                 done ; \
>         else \
>                 echo Clean complete ; \
>         fi
> endif
> endif
>
> clobber: clean FORCE ## Same as 'clean' but also bk clean files
>         -@$(BK) -A clean
>
> # XXX subdirs? (see tags)
> wc: $(HDRS) $(SRCS) $(SCRSRCS) $(MISC)
>         wc -l $(SRCS) $(HDRS) $(SCRSRCS) $(MISC)
>
> get-e: FORCE
>         -@$(BK) edit -qT `echo $(HDRS) $(SRCS) $(SCRSRCS) $(MISC) | fmt
> -1|sort -u`
>         $(Q)$(MAKE) tags
>
> srcs: $(SRCS) $(HDRS) FORCE
>         $(Q)for sub in $(SUBDIRS); do $(BK) -r$$sub co -q; done
>
> tags: $(patsubst %,%/tags.local, $(SUBDIRS)) tags.local
>         @if [ -x $(BK) ]; \
>         then    $(BK) get -Sq tags.skippats; \
>                 $(BK) _sort -u $^ | grep -v -ftags.skippats > $@; \
>         else \
>                 bk get -Sq tags.skippats; \
>                 bk _sort -u $^ | grep -v -ftags.skippats > $@; \
>         fi
>         @echo ctags completed
>
> tags.local: $(SRCS) $(HDRS)
>         @ctags -f $@ --file-tags=yes --c-types=d+f+s+t $^
>
> %/tags.local: FORCE
>         $(Q)$(MAKE) -C $(dir $@) tags.local
>
> ssh sshtest:
>         $(MAKE) realtest
>
> rsh rshtest:
>         PREFER_RSH=YES $(MAKE) realtest
>
> test tests:
>         DO_REMOTE=NO $(MAKE) -C t
>
> nonet nonet_test localtest:
>         BK_NONET=YES PREFER_RSH=YES $(MAKE) realtest
>
> realtest: $(ALL) t/doit
>         -cd gui/tcltk && $(MAKE) clobber
>         -$(BK) get -qS t/setup t/win32/win32_common
>         $(BK) -rt get -qTS 't.*'
>         cd t && ./doit -f 5
>
> guitest: $(ALL) t/doit
>         -$(BK) get -qS t/SCCS/s.g.* t/setup t/win32/win32_common
> t/guitest.tcl
>         cd t && ./doit -g -i
>
> t/doit: t/doit.sh substvars
>         ./substvars t/doit.sh > t/doit
>         chmod +x t/doit
>
> t/guitest: t/guitest.tcl
>         cat < t/guitest.tcl > t/guitest
>
> .PHONY: FORCE
> FORCE:
>
> win32: FORCE
>         cd win32 && $(MAKE) BINDIR=$(BINDIR)
>         cd t/win32 && $(MAKE)
>
> # build libraries in sub directories
> %.a: FORCE
>         $(Q)$(MAKE) -C $(dir $@) $(notdir $@)
>
> libc/mtst$(EXE): libc/libc.a FORCE
>         $(Q)$(MAKE) -C libc mtst$(EXE)
>
> bkres.o: win32/data/bk.rc bk.ico
>         windres -i win32/data/bk.rc -o bkres.o
>
> bk.ico: win32/data/bk.ico
>         @cp -f win32/data/bk.ico .
>
> ifneq ($(TOMCRYPT_SYSTEM),1)
> # add dependency on building libraries first
> $(BK): $(TOMCRYPT_LDFLAGS)
> endif
> ifneq ($(TOMMATH_SYSTEM),1)
> # add dependency on building libraries first
> $(BK): $(TOMMATH_LDFLAGS)
> endif
>
> $(BK): $(LIBS) bk.o $(RESOURCE) $(OBJ)
>         $(if $(Q),@echo LINKING $(BK),)
>         $(Q)$(LD) $(LDFLAGS) -o $@ bk.o $(OBJ) $(RESOURCE) $(LIBS) \
>                 $(TOMCRYPT_LDFLAGS) $(TOMMATH_LDFLAGS) \
>                 $(PCRE_LDFLAGS) $(LZ4_LDFLAGS) $(ZLIB_LDFLAGS) $(XLIBS)
>
> # Windows only rule, BKGUI should be blank on other platforms
> $(BKGUI): bkg.o $(RESOURCE)
>         $(if $(Q),@echo LINKING $(BKGUI),)
>         $(Q)$(LD) $(LDFLAGS) -o $@ bkg.o $(RESOURCE) -Llibc -lc -mwindows
> $(XLIBS)
>
> bk.script: bk.sh port/$(SYS)_platform.sh
>         cat port/$(SYS)_platform.sh bk.sh > bk.script
>         chmod +x bk.script
>
> bkmsg.txt: bkmsg.doc
>         cp -f $< $@
>
> L-clean: FORCE
>         @rm -f gui/share/doc/L/little.man ../man/man1/bk-little.1
>         @rm -f ../man/man2help/bk-little-1.fmt
>
> # has to run before bkhelp.txt but after GUI
> L-doc L-docs: GUI FORCE
>         @test -f gui/share/doc/L/little.man || { \
>                 echo Failed to build gui/share/doc/L/little.man; \
>                 exit 1; \
>         }
>         @if [ -s gui/share/doc/L/little.man ]; \
>         then    cp gui/share/doc/L/little.man ../man/man1/bk-little.1; \
>         else    cp ../man/man1/bk-little.1.pfmt ../man/man1/bk-little.1; \
>         fi; \
>         chmod +w ../man/man1/bk-little.1
>
> bkhelp.txt: $(BK) version L-docs FORCE
>         @rm -f ../man/man2help/bk-little.fmt
>         @cd ../man/man2help && $(MAKE) BK=$(HERE)/bk$(EXE) helptxt
>         @cp ../man/man2help/helptxt bkhelp.txt
>         @rm -f ../man/man1/bk-little.1
>
> html-docs: bkhelp.txt
>         @cd ../man/man2html && $(MAKE)
>
> ../doc/bk_refcard.ps: $(BK) FORCE
>         $(Q)echo building $@
>         $(Q)-$(BK) -r../doc co -qS
>         $(Q)$(MAKE) -C ../doc BK=$(HERE)/bk$(EXE) all
>
> ../doc/bk_refcard.pdf: ../doc/bk_refcard.ps
>
> # This must be rebuilt every time because it includes the build time
> bkver.c: utils/bk_version FORCE
>         $(if $(Q),@echo Building $@,)
>         $(Q)echo "#include \"sccs.h\"" > bk.v
>         $(Q)echo "char *bk_platform = \""`./utils/bk_version`"\";" >> bk.v
>         $(Q)echo "int test_release = "$(TRIAL)";" >> bk.v
>         $(Q)echo "time_t bk_build_timet = "`perl -e "print time"`";" >>
> bk.v
>         $(Q)echo "char *bk_build_dir = \""`pwd`"\";" >> bk.v
>         $(Q)mv -f bk.v bkver.c
>
> version: version.sh $(BK) utils/bk_version GUI FORCE
>         bash version.sh > $@
>
> %: %.sh
>         $(if $(Q),@echo Building $@,)
>         $(Q)$(RM) $@
>         $(Q)cp $< $@
>         $(Q)chmod +x $@
>
> %: %.l
>         $(if $(Q),@echo Not lexing $@,)
>
> import: import.sh port/$(SYS)_platform.sh
>         cat port/$(SYS)_platform.sh import.sh > import.T
>         chmod +x import.T
>         mv -f import.T import
>
> # Quick and dirty target so we can make all the gui tools without the rest
> .PHONY: GUI
> GUI: PCRE $(BK)
>         @$(MAKE) -Cgui BK=$(HERE)/bk$(EXE) gui
>
> install: installdir
>         tmp/bitkeeper/bk _install -d -f $(DESTDIR)$(BINDIR)
>         @echo BitKeeper is installed in $(BINDIR)
>         @echo We suggest you run:
>         @echo
>         @echo sudo $(BINDIR)/bk links /usr/local/bin
>         @echo
>         @echo to create the bk symlink.
>
> installdir: utils/registry.tcl
>         rm -rf $(IMGDIR) || exit 1
>         mkdir -p $(IMGDIR)/contrib
>         mkdir -p $(IMGDIR)/lscripts
>         -$(BK) -rwww get -S
>         -cp -f -r www $(IMGDIR)
>         -$(BK) get -S $(CONTRIB)
>         tar cf - $(BINS) $(SCRIPTS) lscripts gui/bin gui/lib gui/images \
>                 | (cd $(IMGDIR) && tar xf -)
>         cp -f $(DATA) $(IMGDIR)
>         cp -f $(CONTRIB) $(IMGDIR)/contrib
>         (cd ../doc/nested && $(MAKE) install HTML=$(IMGDIR)/html)
>         if [ $(SYS) = unix ]; \
>         then    $(BK) get -S ../man/Makefile; \
>                 cd ../man && $(MAKE) install BINDIR=$(IMGDIR) ;\
>         else \
>                 (cd win32 && $(MAKE) BINDIR=$(IMGDIR) install); \
>                 cp utils/registry.tcl $(IMGDIR)/gui/lib; \
>         fi
>         cd $(IMGDIR); \
>             find . -type l | \
>                 perl -ne 'chomp; $$a = readlink; print
> "$$a|$$_\n";'>symlinks; \
>             test -s symlinks || rm -f symlinks
>         @true
>
> image:  ## Build the installer (left in src/utils/bk-*)
>         $(MAKE) p
>         $(MAKE) _image
>
> _image:
>         $(MAKE) installdir
>         ${MAKE} -Cutils BINDIR=$(IMGDIR) "CC=$(CC)" "BK=$(HERE)/bk$(EXE)"
> "CFLAGS=$(CFLAGS)" image
>
> crankturn: crank.sh remote.sh  ## Run a clean-build + regressions in
> cluster
>         REPO=$(REPO) URL=$(URL) REMOTE=remote.sh LOG=$(LOG) bash crank.sh
>
> cranksave: crank.sh remote.sh  ## Run a crankturn but save the built images
>         REPO=$(REPO) URL=$(URL) REMOTE=remote.sh LOG=$(LOG) bash crank.sh
> save
>
> crankstatus: crank.sh remote.sh  ## See how the crank is going
>         REPO=$(REPO) URL=$(URL) REMOTE=remote.sh LOG=$(LOG) bash crank.sh
> status
>
> crankrelease nightly: $(BK) crank.sh remote.sh  ## Do a BitKeeper release
> (or nightly build)
>         @(TAG=$(shell $(BK) changes -r+ -d:TAG:) ; \
>         test x$$TAG = x && { \
>                 echo Cannot crankrelease with a non-tagged tip ; \
>                 exit 1 ; \
>         } ; \
>         case $@ in \
>         crankrelease ) \
>                 TYPE=release; DIR=/home/bk/images/$$TAG; \
>                 ;; \
>         nightly ) \
>                 TYPE=nightly; DIR=/home/bk/images/nightly; \
>                 HOSTS="$(NIGHTLY_HOSTS)" ; \
>                 ;; \
>         esac ; \
>         test -d $$DIR || mkdir -p $$DIR ; \
>         REPO=$(REPO) URL=$(URL) HOSTS=$$HOSTS REMOTE=remote.sh \
>             LOG=$(LOG) bash crank.sh $$TYPE ; \
>         $(BK) -R get -qS ../RELEASE-NOTES.md ; \
>         cp ../RELEASE-NOTES.md $$DIR ; \
>         SAVED_WD=$(shell pwd) ; \
>         cd $$DIR && chmod +rx bk-* >/dev/null 2>&1 ; \
>         rm -f MD5SUMS ; \
>         md5sum bk-* >> MD5SUMS ; \
>         echo "Your images are in $$DIR" ; \
>         case $@  in  \
>         crankrelease ) \
>                 echo "Run './mkrelease $$TAG' to release this version of
> bk."; \
>                 ;; \
>         nightly ) \
> #               cd $$SAVED_WD ; \
> #               ./mkupgrades --nightly $$TAG ; \
>                 ;; \
>         esac)
>
> crankclean: crank.sh remote.sh
>         REPO=$(REPO) URL=$(URL) REMOTE=remote.sh LOG=$(LOG) bash crank.sh
> clean
>
> # This target assumes a bk repository
> .PHONY: src-tar
> src-tar: $(BK) version ## build tar.gz image for the current tree
> ifeq (false,$(INREPO))
>         $(error This target only works in a BK source repository)
> else
>         ./bk here add default TCLTK
>         $(Q)-mkdir -p tmp/src
>         $(Q)(DIR=bk-$(shell $(BK) version -s) ; \
>              TAR="$$DIR".tar.gz ; \
>              echo "Creating $$TAR in tmp/src..." ; \
>              cd tmp/src ; \
>              rm -rf "$$DIR" ; \
>              ../../bk export -tplain -kwr+ -sdefault -sTCLTK "$$DIR" ; \
>              cat ../../version > "$$DIR/src/bkvers.txt" ; \
>              tar -czf "$$TAR" "$$DIR" ; \
>              rm -rf "$$DIR" ; \
>              echo Done ; \
>         )
> endif
>
> # only depend on conf.mk.local if it exists
> conf.mk: mkconf.sh $(wildcard conf.mk.local)
>         sh mkconf.sh > $@ || { $(RM) $@; false; }
>
> %.o: %.c
>         $(if $(Q),@echo CC $<,)
>         $(Q)$(CC) $(CFLAGS) $(CPPFLAGS) -c $< -o $@
>
> port/startmenu.o: port/startmenu.c $(HDRS)
>         $(if $(Q),@echo CC $<,)
>         $(Q)$(CC) $(CFLAGS) -fno-strict-aliasing $(CPPFLAGS) -c $< -o $@
>
> depend: $(SRCS)
>         $(CC) -MM -MG -D_DEPEND $(SRCS) > depends
>
> # for system.h we need to actually run libc's makefile because it includes
> # calculated header files
> libc/system.h: FORCE
>         $(MAKE) -C libc system.h
>
> libc/libc.a: libc/system.h
>
> sccs.h: PCRE
> .PHONY: PCRE
> PCRE:
> ifneq ($(PCRE_SYSTEM),1)
>         $(MAKE) -Cgui/tcltk pcre
> endif
>
> $(OBJ) bk.o: $(HDRS)
>
> cmd.c cmd.h: cmd.pl bk.sh $(filter bkd_%,$(SRCS))
>         $(if $(Q),@echo Building $@,)
>         $(Q)perl cmd.pl || (rm -f cmd.c cmd.h; exit 1)
>
> # This parses slib.c and extracts the meta-data keywords expanded
> # by kw2val() and passes them to gperf to generate hash lookup code.
> slib.o: kw2val_lookup.c
> kw2val_lookup.c: slib.c kw2val.pl
>         $(if $(Q),@echo Building $@,)
>         $(Q)perl kw2val.pl slib.c || (rm -f kw2val_lookup.c; exit 1)
>
> check-syntax:
>         $(CC) $(CFLAGS) $(CPPFLAGS) -c -S ${CHK_SOURCES} -o /dev/null
>
> # print a make variable  'make print-REPO'
> #   http://www.cmcrossroads.com/article/printing-value-makefile-variable
> print-%:
>         @echo $* = \"$($*)\"
>
> .PHONY: help
>
> help:
>         @grep -E -h '^[-a-zA-Z_\ ]+:.*?## .*$$' $(MAKEFILE_LIST) | sort |
> awk 'BEGIN {FS = ":.*?## "}; {printf "\033[36m%-30s\033[0m %s\n", $$1, $$2}'
>         @echo Suggested: make -j12 image
>
>

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

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

[Larry McVoy]

On Wed, Jun 19, 2024 at 08:44:14AM -0600, Warner Losh wrote:
> On Wed, Jun 19, 2024, 7:28???AM Larry McVoy <lm@mcvoy.com> wrote:
> 
> > On Tue, Jun 18, 2024 at 07:46:15PM -0500, Nevin Liber wrote:
> > > But I'll bite.  There was the claim by Larry McVoy that "Writing
> > Makefiles
> > > isn't that hard".
> > >
> > > Please show these beautiful makefiles for a non-toy non-trivial product
> >
> > Works on *BSD, MacOS, Windows, Linux on a bunch of different architectures,
> > Solaris, HPUX, AIX, IRIX, Tru64, etc.
> >
> 
> The posted Makefile is no a strictly conforming POSIX Makefile, but uses
> gmake extensions extensively... And eyes of the beholder may vary...

Yeah, I lost that battle.  I prefer, and carry around the sources to, a
make from Unix.  It's simple and does what I need.  But my guys convinced
me there was enough value in gmake that we used it.  I tried to keep
the craziness to a minimum.  And I think I succeeded, I can fix bugs in
that Makefile.

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

[Warner Losh]

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

On Wed, Jun 19, 2024, 8:54 AM Larry McVoy <lm@mcvoy.com> wrote:

> On Wed, Jun 19, 2024 at 08:44:14AM -0600, Warner Losh wrote:
> > On Wed, Jun 19, 2024, 7:28???AM Larry McVoy <lm@mcvoy.com> wrote:
> >
> > > On Tue, Jun 18, 2024 at 07:46:15PM -0500, Nevin Liber wrote:
> > > > But I'll bite.  There was the claim by Larry McVoy that "Writing
> > > Makefiles
> > > > isn't that hard".
> > > >
> > > > Please show these beautiful makefiles for a non-toy non-trivial
> product
> > >
> > > Works on *BSD, MacOS, Windows, Linux on a bunch of different
> architectures,
> > > Solaris, HPUX, AIX, IRIX, Tru64, etc.
> > >
> >
> > The posted Makefile is no a strictly conforming POSIX Makefile, but uses
> > gmake extensions extensively... And eyes of the beholder may vary...
>
> Yeah, I lost that battle.  I prefer, and carry around the sources to, a
> make from Unix.  It's simple and does what I need.  But my guys convinced
> me there was enough value in gmake that we used it.  I tried to keep
> the craziness to a minimum.  And I think I succeeded, I can fix bugs in
> that Makefile.
>

I thought the ask was for a POSIX one that did that,  hence my comment. I
agree that is a fools errand for anything non-trivial.

I can do way better using BSD's make since i can hide almost all the
ugliness behind the scenes... Though what's hidden has rightfully been
criticized already (I did diagree with some of it, but the main points
still stand with my quibbles so I let it go).

In many ways I really like cmake's declarative approach. I like bmake's
include macros that try to do similar, but more constrained, things. I like
that cmake figures things out, though I've done too much battle to control
how it does things, but I digress.

It's useful to have a tool that can do dependencies. However, you need a
higher level tool to generate input to that tool, like meson with ninjamake
or cmake. Combining them like gmake or bmake creates a nice macro assembler
that can be made to work, but the pain winds up being in all the wrong
places and the needs to constantly refactor is high to try to retain the
simplicity.

Warner

>

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

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

[G. Branden Robinson]

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

At 2024-06-19T07:53:59-0700, Larry McVoy wrote:
> On Wed, Jun 19, 2024 at 08:44:14AM -0600, Warner Losh wrote:
> > The posted Makefile is no a strictly conforming POSIX Makefile, but
> > uses gmake extensions extensively... And eyes of the beholder may
> > vary...
>
> Yeah, I lost that battle.  I prefer, and carry around the sources to,
> a make from Unix.  It's simple and does what I need.  But my guys
> convinced me there was enough value in gmake that we used it.  I tried
> to keep the craziness to a minimum.  And I think I succeeded, I can
> fix bugs in that Makefile.

As of POSIX 2024, that Makefile is less GNUish than its used to be.  I
excerpted the list of changes to POSIX make for Issue 8.  Here it is.

Changes in POSIX 2024 make

Issue 8

Austin Group Defect 251 is applied, encouraging implementations to
disallow the creation of filenames containing any bytes that have the
encoded value of a <newline> character.

Austin Group Defects 330, 1417, 1422, 1709, and 1710 are applied, adding
new forms of macro assignment using the "::=", "?=", and "+=" operators.

Austin Group Defect 333 is applied, adding support for “silent includes”
using −include.

Austin Group Defects 336 and 1711 are applied, specifying the behavior
when string1 in a macro expansion contains a macro expansion.

Austin Group Defect 337 is applied, adding a new form of macro
assignment using the "!=" operator.

Austin Group Defects 373 and 1417 are applied, changing the set of
characters that portable applications can use in macro names to the
entire portable filename character set (thus adding <hyphen-minus> to
the set that could previously be used).

Austin Group Defects 514 and 1520 are applied, adding the $+ and $^
internal macros.

Austin Group Defect 518 is applied, allowing multiple files to be
specified on an include line.

Austin Group Defects 519, 1712, and 1715 are applied, adding support for
pattern macro expansions.

Austin Group Defects 523, 1708, and 1749 are applied, adding the .PHONY
special target.

Austin Group Defect 875 is applied, clarifying the requirements for
inference rules.

Austin Group Defect 1104 is applied, changing “s2.a” to “.s2.a”.

Austin Group Defect 1122 is applied, changing the description of
NLSPATH.

Austin Group Defect 1141 is applied, changing “core files” to “a file
named core”.

Austin Group Defect 1155 is applied, clarifying the handling of the MAKE
macro.

Austin Group Defect 1325 is applied, adding requirements relating to the
creation of include files.

Austin Group Defect 1330 is applied, removing obsolescent interfaces.

Austin Group Defect 1419 is applied, updating the .SCCS_GET default
rule.

Austin Group Defect 1420 is applied, clarifying where internal macros
can be used.

Austin Group Defect 1421 is applied, changing the APPLICATION USAGE
section.

Austin Group Defects 1424, 1658, 1690, 1701, 1702, 1703, 1704, 1707,
1719, 1720, 1721, 1722, and 1750 are applied, making various minor
editorial wording changes.

Austin Group Defects 1436, 1437, 1652, 1660, 1661, and 1733 are applied,
adding the −j maxjobs option and the .NOTPARALLEL and .WAIT special
targets, and changing the −n option.

Austin Group Defects 1471 and 1513 are applied, adding a new form of
macro assignment using the ":::=" operator.

Austin Group Defect 1479 is applied, clarifying the requirements for
default rules and macro values.

Austin Group Defect 1492 is applied, changing the EXIT STATUS section.

Austin Group Defect 1505 is applied, clarifying the requirements for
expansion of macros that do not exist.

Austin Group Defect 1510 is applied, correcting a typographic error in
the RATIONALE section.

Austin Group Defect 1549 is applied, clarifying the requirements for an
escaped <newline> in a command line.

Austin Group Defect 1615 is applied, allowing target names to contain
slashes and hyphens.

Austin Group Defect 1626 is applied, adding the CURDIR macro.

Austin Group Defect 1631 is applied, adding information about use of the
−j option with the .c.a default rule to the APPLICATION USAGE and
EXAMPLES sections.

Austin Group Defect 1650 is applied, changing the few occurrences of
“dependencies” to use the more common “prerequisites”.

Austin Group Defect 1653 is applied, clarifying the difference between
how MAKEFLAGS is parsed compared to shell commands that use the make
utility.

Austin Group Defects 1654 and 1655 are applied, changing the APPLICATION
USAGE section.

Austin Group Defect 1656 is applied, changing the NAME section.

Austin Group Defect 1657 is applied, moving some requirements unrelated
to makefile syntax from the Makefile Syntax subsection to the beginning
of the EXTENDED DESCRIPTION section.

Austin Group Defect 1689 is applied, removing some redundant wording
from the DESCRIPTION section.

Austin Group Defect 1692 is applied, allowing make, when invoked with
the −q or −t option, to execute command lines (without a <plus-sign>
prefix) that expand the MAKE macro.

Austin Group Defect 1693 is applied, changing “command lines” to
“execution lines” in the description of the −s option.

Austin Group Defect 1694 is applied, changing “in the order they appear”
to “in the order specified” in the OPERANDS section.

Austin Group Defect 1696 is applied, changing the STDOUT section.

Austin Group Defect 1697 is applied, changing the RATIONALE and FUTURE
DIRECTIONS sections.

Austin Group Defect 1698 is applied, changing “of a target” to “of the
target” in the EXTENDED DESCRIPTION section.

Austin Group Defect 1699 is applied, addressing some inconsistencies in
the use of the term “rules”.

Austin Group Defect 1706 is applied, removing a line from the format
specified for target rules.

Austin Group Defect 1714 is applied, changing “beginning of the line” to
“beginning of the value”.

Austin Group Defect 1716 is applied, changing the typographic convention
used for variable elements within target names, in particular the
inference rule suffixes s1 and s2.

Austin Group Defect 1723 is applied, adding historical context to a
paragraph in the RATIONALE section.

Austin Group Defect 1772 is applied, clarifying the ASYNCHRONOUS EVENTS
section.

"Well, I'm not even sure that's a crime anymore--there've been a lot of
changes in the law." -- Irwin Fletcher

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[ron minnich]

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

somewhere in this zillion-thread discussion there was a comment about Plan
9 and its multi-headed community. While that comment was probably accurate
a few years back, the last two years of Plan 9 workshops saw a lot of us,
representing many different Plan 9 code bases, get together and converge on
where we want to go. Once you meet someone in person, and go get a
cheesesteak together, arguments seem to resolve.

I would say, don't take too many impressions from 9fans, a famously
argumentative list. The folks who write Plan 9 code are in broad agreement
about moving forward and leaving hatchets buried. Progress is never as
rapid as we all would like, but I'm optimistic.



On Wed, Jun 19, 2024 at 7:54 AM Larry McVoy <lm@mcvoy.com> wrote:

> On Wed, Jun 19, 2024 at 08:44:14AM -0600, Warner Losh wrote:
> > On Wed, Jun 19, 2024, 7:28???AM Larry McVoy <lm@mcvoy.com> wrote:
> >
> > > On Tue, Jun 18, 2024 at 07:46:15PM -0500, Nevin Liber wrote:
> > > > But I'll bite.  There was the claim by Larry McVoy that "Writing
> > > Makefiles
> > > > isn't that hard".
> > > >
> > > > Please show these beautiful makefiles for a non-toy non-trivial
> product
> > >
> > > Works on *BSD, MacOS, Windows, Linux on a bunch of different
> architectures,
> > > Solaris, HPUX, AIX, IRIX, Tru64, etc.
> > >
> >
> > The posted Makefile is no a strictly conforming POSIX Makefile, but uses
> > gmake extensions extensively... And eyes of the beholder may vary...
>
> Yeah, I lost that battle.  I prefer, and carry around the sources to, a
> make from Unix.  It's simple and does what I need.  But my guys convinced
> me there was enough value in gmake that we used it.  I tried to keep
> the craziness to a minimum.  And I think I succeeded, I can fix bugs in
> that Makefile.
>

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

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

[Theodore Ts'o]

On Wed, Jun 19, 2024 at 06:28:46AM -0700, Larry McVoy wrote:
> On Tue, Jun 18, 2024 at 07:46:15PM -0500, Nevin Liber wrote:
> > But I'll bite.  There was the claim by Larry McVoy that "Writing Makefiles
> > isn't that hard".
> > 
> > Please show these beautiful makefiles for a non-toy non-trivial product
> 
> Works on *BSD, MacOS, Windows, Linux on a bunch of different architectures,
> Solaris, HPUX, AIX, IRIX, Tru64, etc.

True, but it uses multiple GNU make features, include file inclusions,
conditionals, pattern substitutions, etc.  That probably worked for
Bitkeeper because you controlled the build envirnment for the product,
as you were primarily distributing binaries.

From portability perspective for e2fsprogs, I wanted to make sure I
could build it using the native build environment (e.g., suncc and
later clang, not just gcc, and the default make distributed by Sun,
AIX, Irix, HPUX, and later NetBSD/FreeBSD).  I also wanted to support
shared library support, and I didn't want to deal the horrific
performance attributes of libtool and the inscrutibility of automake.

Since my primary distribution channel was the source tarball (and
later, a git checkout), and other high priority requirement for me is
that I didn't want to require that people need to download some custom
build infratrture.  This rules out cmake, imake, gmake, and blaze
(especially since blaze/bazel requires installing a Java <shudder>
runtime).

And since I did want to use various advanced features (optionally, if
they exist on the system) such as Poix Threads (which back then I
couldn't take for granted as existing on all of the OS's that I
supported) and Thread Local Storage, as opposed to just restricting
myself to the BSD v4.4 feature subset, I needed to use autoconf anyway,
and from a runtime perspective, it only requires m4 / awk / sed which
is available everywhere.

So I did everything using (only) autoconf, including building and
using shared libraries, with some optional build features that require
GNU make, but the same makefiles will also work on FreeBSD's pmake.  I
do agree with your basic premise, though, which is there's realy no
need to use fancy/complicated build infrastructure such as cmake or
<shudder> imake.

						- Ted

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

[Kevin Bowling]

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

On Wed, Jun 19, 2024 at 11:59 PM Theodore Ts'o <tytso@mit.edu> wrote:

> On Wed, Jun 19, 2024 at 06:28:46AM -0700, Larry McVoy wrote:
> > On Tue, Jun 18, 2024 at 07:46:15PM -0500, Nevin Liber wrote:
> > > But I'll bite.  There was the claim by Larry McVoy that "Writing
> Makefiles
> > > isn't that hard".
> > >
> > > Please show these beautiful makefiles for a non-toy non-trivial product
> >
> > Works on *BSD, MacOS, Windows, Linux on a bunch of different
> architectures,
> > Solaris, HPUX, AIX, IRIX, Tru64, etc.
>
> True, but it uses multiple GNU make features, include file inclusions,
> conditionals, pattern substitutions, etc.  That probably worked for
> Bitkeeper because you controlled the build envirnment for the product,
> as you were primarily distributing binaries.
>
> From portability perspective for e2fsprogs, I wanted to make sure I
> could build it using the native build environment (e.g., suncc and
> later clang, not just gcc, and the default make distributed by Sun,
> AIX, Irix, HPUX, and later NetBSD/FreeBSD).  I also wanted to support
> shared library support, and I didn't want to deal the horrific
> performance attributes of libtool and the inscrutibility of automake.
>
> Since my primary distribution channel was the source tarball (and
> later, a git checkout), and other high priority requirement for me is
> that I didn't want to require that people need to download some custom
> build infratrture.  This rules out cmake, imake, gmake, and blaze
> (especially since blaze/bazel requires installing a Java <shudder>
> runtime).
>
> And since I did want to use various advanced features (optionally, if
> they exist on the system) such as Poix Threads (which back then I
> couldn't take for granted as existing on all of the OS's that I
> supported) and Thread Local Storage, as opposed to just restricting
> myself to the BSD v4.4 feature subset, I needed to use autoconf anyway,
> and from a runtime perspective, it only requires m4 / awk / sed which
> is available everywhere.
>
> So I did everything using (only) autoconf, including building and
> using shared libraries,


This is The Way if you really care about portability.  Autoconf, once you
get your head around what, why, and when it was created, makes for nice
Makefiles and projects that are easy to include in the 100 Linux
distributions with their own take on packaging the world.

>
with some optional build features that require
> GNU make, but the same makefiles will also work on FreeBSD's pmake.  I
> do agree with your basic premise, though, which is there's realy no
> need to use fancy/complicated build infrastructure such as cmake or
> <shudder> imake.
>
>                                                 - Ted
>

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

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

[David Arnold]

[-- Attachment #1: Type: text/html, Size: 2574 bytes --]

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

[George Michaelson]

we used to argue about that. I disliked autoconf because I felt 99% of
the work could be precomputed, which is what MIT X11 Makefiles did:
they had recipes for the common architectures.

-G

On Thu, Jun 20, 2024 at 3:15 PM David Arnold <davida@pobox.com> wrote:
>
>
> On 20 Jun 2024, at 08:48, Kevin Bowling <kevin.bowling@kev009.com> wrote:
>
> 
> On Wed, Jun 19, 2024 at 11:59 PM Theodore Ts'o <tytso@mit.edu> wrote:
>
>
> <…>
>
>> So I did everything using (only) autoconf, including building and
>> using shared libraries,
>
>
> This is The Way if you really care about portability.  Autoconf, once you get your head around what, why, and when it was created, makes for nice Makefiles and projects that are easy to include in the 100 Linux distributions with their own take on packaging the world.
>
>
> For those of a certain era, autoconf was both useful and relatively simple to use.
>
> In an era of many, divergent Unices, with different compilers, shared library implementations, and varying degrees of adherence to standards, it made using FOSS a matter of ‘./configure && make && make install’ which was massively easier than what had been required previously unless you happened to have exactly the same platform as the author.
>
> And to use it, you needed to understand shell, make, and m4, and learn a few dozen macros (at most).   m4 was perhaps the least likely skill, but since it was used by sendmail(.mc), twmrc, X11 app defaults and various other stuff, most people already had a basic understanding of it.
>
> In my view the modern rejection of autoconf as “incomprehensible” mostly suggests that the speaker comes from a generation that never used the original Unix toolset.
>
>
>
>
> d

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

[Alexis]

George Michaelson <ggm@algebras.org> writes:

> we used to argue about that. I disliked autoconf because I felt 
> 99% of
> the work could be precomputed, which is what MIT X11 Makefiles 
> did:
> they had recipes for the common architectures.

A point still being made:

> So, okay, fine, at some point it made sense to run programs to 
> empirically determine what was supported on a given system. What 
> I don't understand is why we kept running those stupid little 
> shell snippets and little bits of C code over and over. It's 
> like, okay, we established that this particular system does 
> <library function foobar> with two args, not three. So why the 
> hell are we constantly testing for it over and over?
>
> Why didn't we end up with a situation where it was just a 
> standard thing that had a small number of possible values, and 
> it would just be set for you somewhere? Whoever was responsible 
> for building your system (OS company, distribution packagers, 
> whatever) could leave something in /etc that says "X = flavor 1, 
> Y = flavor 2" and so on down the line.
>
> And, okay, fine, I get that there would have been all kinds of 
> "real OS companies" that wouldn't have wanted to stoop to the 
> level of the dirty free software hippies. Whatever. Those same 
> hippies could have run the tests ONCE per platform/OS combo, put 
> the results into /etc themselves, and then been done with it.
>
> Then instead of testing all of that shit every time we built 
> something from source, we'd just drag in the pre-existing 
> results and go from there. It's not like the results were going 
> to change on us. They were a reflection of the way the kernel, C 
> libraries, APIs and userspace happened to work. Short of that 
> changing, the results wouldn't change either. 

--https://rachelbythebay.com/w/2024/04/02/autoconf/


Alexis.

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

[David Arnold]

> On 20 Jun 2024, at 16:37, Alexis <flexibeast@gmail.com> wrote:
> 
> George Michaelson <ggm@algebras.org> writes:
> 
>> we used to argue about that. I disliked autoconf because I felt 99% of
>> the work could be precomputed, which is what MIT X11 Makefiles did:
>> they had recipes for the common architectures.
> 
> A point still being made:
> 
>> So, okay, fine, at some point it made sense to run programs to empirically determine what was supported on a given system. What I don't understand is why we kept running those stupid little shell snippets and little bits of C code over and over. It's like, okay, we established that this particular system does <library function foobar> with two args, not three. So why the hell are we constantly testing for it over and over?
>> 
>> Why didn't we end up with a situation where it was just a standard thing that had a small number of possible values, and it would just be set for you somewhere? Whoever was responsible for building your system (OS company, distribution packagers, whatever) could leave something in /etc that says "X = flavor 1, Y = flavor 2" and so on down the line.
>> 
>> And, okay, fine, I get that there would have been all kinds of "real OS companies" that wouldn't have wanted to stoop to the level of the dirty free software hippies. Whatever. Those same hippies could have run the tests ONCE per platform/OS combo, put the results into /etc themselves, and then been done with it.
>> 
>> Then instead of testing all of that shit every time we built something from source, we'd just drag in the pre-existing results and go from there. It's not like the results were going to change on us. They were a reflection of the way the kernel, C libraries, APIs and userspace happened to work. Short of that changing, the results wouldn't change either. 
> 
> --https://rachelbythebay.com/w/2024/04/02/autoconf/

Which brings us back to imake (at least in xmkmf form), where if the pre-prepared settings matched your system, you were good and if not, you had a heap of work to set all the magic variables to have it build correctly. 

On classic MacOS, otoh, you’d compile against an SDK, but for each ROM/library symbol you wanted to use you were expected to check at runtime if it existed, and if not, switch to some alternative behaviour.

Autoconf was somewhat of a middle path: check once for each installation.  It also made more sense when there was less uniformity in the platforms in use.

That said: autoconf never really worked outside of Unix.  You could make other platforms Unix-like (eg. Cygwin, or even BeOS), but its claim to portability was always fairly narrow. 


U

d

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

[Bakul Shah via TUHS]

>> Then instead of testing all of that shit every time we built something from source, we'd just drag in the pre-existing results and go from there. It's not like the results were going to change on us. They were a reflection of the way the kernel, C libraries, APIs and userspace happened to work. Short of that changing, the results wouldn't change either. 

To build a set of objects you need to worry about at least the following:
- build recipes for each of them (which may also depend on other things)
- configuration parameters
- dealing with differences on each platform
- third party libraries & alternatives
- toolchains (& may be cross-platform builds)
- supporting/navigating different versions of the last 3 above

You can't really precompute all this as there are far too many combinations and they keep changing.

Though you may be able to train a program porting AI model :-)

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

[Alexis]

Bakul Shah via TUHS <tuhs@tuhs.org> writes:

> To build a set of objects you need to worry about at least the
> following:
> - build recipes for each of them (which may also depend on other
> things)
> - configuration parameters
> - dealing with differences on each platform
> - third party libraries & alternatives
> - toolchains (& may be cross-platform builds)
> - supporting/navigating different versions of the last 3 above
>
> You can't really precompute all this as there are far too many
> combinations and they keep changing.

Both the blog author (who is a long-time sysadmin with many 'war 
stories') and myself understand all that.

i believe the idea is not for precomputing to be done by _builds_, 
but to be done on and for a given machine and its configuration, 
independent of any specific piece of software, which is then 
_queried_ by builds. That precomputation would only need to be 
re-run when one of the things under its purview changes.

If i compile something on one of my OpenBSD boxen in the morning, 
and then compile some other thing in the afternoon, without an OS 
upgrade in-between, autoconf isn't going to find that libc.so has 
changed in-between. If i did the same thing on my Gentoo box, it's 
theoretically possible that e.g. i've moved from glibc to musl 
in-between, but in that case, precomputation could be done in 
postinst (i.e. as part of the post-installation-of-musl process).


Alexis.

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

[Warner Losh]

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

On Thu, Jun 20, 2024, 5:35 PM Alexis <flexibeast@gmail.com> wrote:

> Bakul Shah via TUHS <tuhs@tuhs.org> writes:
>
> > To build a set of objects you need to worry about at least the
> > following:
> > - build recipes for each of them (which may also depend on other
> > things)
> > - configuration parameters
> > - dealing with differences on each platform
> > - third party libraries & alternatives
> > - toolchains (& may be cross-platform builds)
> > - supporting/navigating different versions of the last 3 above
> >
> > You can't really precompute all this as there are far too many
> > combinations and they keep changing.
>
> Both the blog author (who is a long-time sysadmin with many 'war
> stories') and myself understand all that.
>
> i believe the idea is not for precomputing to be done by _builds_,
> but to be done on and for a given machine and its configuration,
> independent of any specific piece of software, which is then
> _queried_ by builds. That precomputation would only need to be
> re-run when one of the things under its purview changes.
>
> If i compile something on one of my OpenBSD boxen in the morning,
> and then compile some other thing in the afternoon, without an OS
> upgrade in-between, autoconf isn't going to find that libc.so has
> changed in-between. If i did the same thing on my Gentoo box, it's
> theoretically possible that e.g. i've moved from glibc to musl
> in-between, but in that case, precomputation could be done in
> postinst (i.e. as part of the post-installation-of-musl process).
>

Isn't that what thecautoconf cache is for?

Warner

>

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

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

[Alexis]

Warner Losh <imp@bsdimp.com> writes:

> Isn't that what thecautoconf cache is for?

There's a cross-project cache? That is, a cache not just for the 
project for which autoconf was run, but for _all_ software built 
on that machine?

(Over the decades i've regularly observed instances where autoconf 
doesn't seem to be making use of results of its previous runs for 
a particular project; i don't know if that's because the build 
maintainer didn't configure autoconf correctly. My own dev/doc 
work hasn't required me to wrestle with autoconf.)


Alexis.

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

[Greg A. Woods]

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

At Fri, 21 Jun 2024 10:34:46 +1000, Alexis <flexibeast@gmail.com> wrote:
Subject: [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register
> 
> Warner Losh <imp@bsdimp.com> writes:
> 
> > Isn't that what thecautoconf cache is for?
> 
> There's a cross-project cache? That is, a
> cache not just for the project for which
> autoconf was run, but for _all_ software
> built on that machine?

Indeed there is.  Nothing new about it either.  It's been around for two
decades or more.

From autoconf.info (with variants going back at least as far as 2002):

    7.4.2 Cache Files
  ....
       The site initialization script can specify a site-wide cache file
    to use, instead of the usual per-program cache.  In this case, the
    cache file gradually accumulates information whenever someone runs a
    new ‘configure’ script.

There's a pkgsrc.org package, pkgtools/autoswc, that makes it all work
cleanly for NetBSD and other platforms using pkgsrc, caching just the
stuff that's known to be invariant (by pre-filling a static cache using
a big monster "fake" configure script that covers most of the generic
tests) and letting other stuff be handled at runtime.

It can be a bit fragile, especially in the "gradually accumulates" way
of using it (which is why pkgsrc avoids that), but usually the fault
lies squarely on the shoulders of developers who either don't read the
Autoconf documentation, or think that somehow they're smarter than
Autoconf and the many decades of lore it encodes.

-- 
					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: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[G. Branden Robinson]

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

At 2024-06-20T17:54:22-0700, Greg A. Woods wrote:
> At Fri, 21 Jun 2024 10:34:46 +1000, Alexis <flexibeast@gmail.com> wrote:
> > There's a cross-project [autoconf] cache? That is, a cache not just
> > for the project for which autoconf was run, but for _all_ software
> > built on that machine?
> 
> Indeed there is.  Nothing new about it either.  It's been around for two
> decades or more.
[...]
> It can be a bit fragile, especially in the "gradually accumulates" way
> of using it (which is why pkgsrc avoids that), but usually the fault
> lies squarely on the shoulders of developers who either don't read the
> Autoconf documentation, or think that somehow they're smarter than
> Autoconf and the many decades of lore it encodes.

Hard to believe such people exist!

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Alexis]

"Greg A. Woods" <woods@robohack.ca> writes:

> Indeed there is.  Nothing new about it either.  It's been around 
> for two
> decades or more.

TIL - thank you! i've never seen this mentioned before. (Perhaps 
because i only use autoconf as an end-user, rather than as a dev.)

Looking at section 15.8 of that manual, it looks like i could 
specify that `-C` / `--config-cache` be passed to configure by 
default site-wide. So i might do so on my Gentoo system - given 
most things on that system are locally compiled, it might be an 
interesting stress-test data-point regarding configuration 
caching.


Alexis.

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

[Warner Losh]

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

On Thu, Jun 20, 2024, 7:32 PM Alexis <flexibeast@gmail.com> wrote:

> "Greg A. Woods" <woods@robohack.ca> writes:
>
> > Indeed there is.  Nothing new about it either.  It's been around
> > for two
> > decades or more.
>
> TIL - thank you! i've never seen this mentioned before. (Perhaps
> because i only use autoconf as an end-user, rather than as a dev.)
>

I used it on OpenBSD in the 90s to make ports builds go much faster in the
days before pkgsrc was a going concern. It made a huge difference on my arc
machine that was about P75 speed, the speed of a pentium clocked at
75MHz.... it was an R4000PC running at 100MHz iirc.

Warner

Looking at section 15.8 of that manual, it looks like i could
> specify that `-C` / `--config-cache` be passed to configure by
> default site-wide. So i might do so on my Gentoo system - given
> most things on that system are locally compiled, it might be an
> interesting stress-test data-point regarding configuration
> caching.
>
>
> Alexis.
>

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

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

[Chet Ramey via TUHS]

[-- Attachment #1.1: Type: text/plain, Size: 1183 bytes --]

On 6/20/24 8:34 PM, Alexis wrote:
> Warner Losh <imp@bsdimp.com> writes:
> 
>> Isn't that what thecautoconf cache is for?
> 
> There's a cross-project cache? That is, a cache not just for the project 
> for which autoconf was run, but for _all_ software built on that machine?

Well, `all' is pretty broad.

You can set some site-specific defaults:

https://www.gnu.org/software/autoconf/manual/autoconf-2.63/html_node/Site-Defaults.html

and use a site-specific cache file:

https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Cache-Files.html

This cache file can be written by every `configure' run, if you like. It's
just a shell script.

> (Over the decades i've regularly observed instances where autoconf doesn't 
> seem to be making use of results of its previous runs for a particular 
> project; i don't know if that's because the build maintainer didn't 
> configure autoconf correctly.

You have to tell configure to use the cache file.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

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

[Bakul Shah via TUHS]

> On Jun 20, 2024, at 4:35 PM, Alexis <flexibeast@gmail.com> wrote:
> 
> If i compile something on one of my OpenBSD boxen in the morning, and then compile some other thing in the afternoon, without an OS upgrade in-between, autoconf isn't going to find that libc.so has changed in-between. If i did the same thing on my Gentoo box, it's theoretically possible that e.g. i've moved from glibc to musl in-between, but in that case, precomputation could be done in postinst (i.e. as part of the post-installation-of-musl process).

But the overlap between two different programs or their assumptions will be
only partial (except for some very basic things) which likely means the cache
won't quite work. For example, you may find that program A and B depend on different versions of some library C. And how does the configure or whatever
tool find out that no dependency has changed? I don't think you can factor
out a cache of such data to a global place that will work for every ported
program.

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

[Alexis]

Bakul Shah <bakul@iitbombay.org> writes:

> But the overlap between two different programs or their 
> assumptions
> will be
> only partial (except for some very basic things) which likely 
> means
> the cache
> won't quite work. For example, you may find that program A and B
> depend on different versions of some library C.

The basic things are, in fact, a significant part of what autoconf 
is being used to check for. "Does this platform provide this 
function?" And that doesn't significantly change between versions 
of the specific libc used by the system (glibc, musl, the *BSD 
libcs, etc.); due to their nature as a fundamental part of the 
system, they're relatively conservative (compared to higher-level 
libraries and applications) as to the rate at which they change, 
and what they add and remove. i've only rarely encountered libc 
version issues when compiling many pieces of software for my use 
over the years.

For higher-level libraries, there's pkg-config and its 
reimplementations, such as pkgconf:

> pkgconf is a program which helps to configure compiler and 
> linker flags for development libraries.  This allows build 
> systems to detect other dependencies and use them with the 
> system toolchain.
-- pkgconf(1), https://www.mankier.com/1/pkgconf

which can (and does) get _used_ by autoconf, but is a standalone 
project. (Which is not to say i'm endorsing the system, just that 
it exists, and is independent of the autoconf system.)

> And how does the
> configure or whatever
> tool find out that no dependency has changed? I don't think you 
> can
> factor
> out a cache of such data to a global place that will work for 
> every
> ported
> program.

You're right: not for _every_ ported program. But even if the 
cache worked for _most_, and simplified the build processes of 
_most_ programs, thus reducing the complexity needing to be 
understood by build maintainers, and reducing the complexity 
available for malfeasants to hide backdoors, that would still be a 
significant win, in my opinion. Don't let the perfect be the enemy 
of the good, etc.


Alexis.

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

[segaloco via TUHS]

On Thursday, June 20th, 2024 at 6:15 PM, Alexis <flexibeast@gmail.com> wrote:

> Bakul Shah bakul@iitbombay.org writes:
> 
> > But the overlap between two different programs or their
> > assumptions
> > will be
> > only partial (except for some very basic things) which likely
> > means
> > the cache
> > won't quite work. For example, you may find that program A and B
> > depend on different versions of some library C.
> 
> 
> The basic things are, in fact, a significant part of what autoconf
> is being used to check for. "Does this platform provide this
> function?"
>
> ...
> 
> 
> Alexis.

This aspect of things I have found a bit perplexing.  On one hand, sure, it's nice to have some scripted system spit out a:

"Dependency xyz not found"

But where it falls apart in my head is what that tells me that, for instance, cpp's error diagnostic about a missing include or ld saying a symbol or library wasn't found does.  It's in my mind a minor convenience but one that doesn't justify all the machinery between one's self and make just to provide.  Granted that's not all autotools does, so a poor example in practice, but in theory gets at one of my irks, packaging something that you are already going to discover some other way.  That and "does my target platform list support xyz" isn't necessarily a matter I'd wait until I've created a whole build package around my software to settle...

Just a small part of the puzzle but one of the parts that gives me more headaches than not.  Now I don't get to respond to a compiler or linker asking for something by putting it where it asked for it, now I also have to figure out how to do the extra work to ensure that it's put somewhere and in a way that all this machinery between myself and the compiler can also verify in its own magical way component <xyz> is present.

I'd be willing to wager that half the time autotools, cmake, etc has made me want to put my head through a wall is not that some needed thing isn't there, it's just that it's not there according to whatever extra expectations or formulas come into play just to satisfy the build machinery.  These tools can be helpful in the face of extreme complexity, but I feel silly when most of the work I put into compiling some package that's like 6 source files is making sure the environment on my system can satisfy the expectations of the build tools.

It has been said already that part of the problem too with the uptake of these tools and their growing ubiquity is new folks who don't know any better think that's just "how it is" and then wind up spinning an autotools or cmake build for a <1000 line tool written in ANSI C.  I've done the same in less experienced times, one of my first attempts at a game engine uses an autotools build.  I quickly grew frustrated with it and everything since has used a flat makefile and has been just fine.  Granted I'm not building a triple A game, but that gets at the root of one of my gripes, I think these sorts of frameworks are overused.  They have their areas that they shine, or they wouldn't have reached the critical mass they have, but as consequence folks will use them haphazardly regardless of the need.

Long story short, maybe gcc needs a configure script, but does GNU ed?  Maybe KDE Plasma needs CMake files, but does libtiff?  I make no claims regarding the complexity of these actual codebases...but one does have to wonder...

- Matt G.

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

[Alan D. Salewski]

On Thu, Jun 20, 2024, at 21:43, segaloco via TUHS wrote:
> On Thursday, June 20th, 2024 at 6:15 PM, Alexis <flexibeast@gmail.com> wrote:
>
[...]

>> The basic things are, in fact, a significant part of what autoconf
>> is being used to check for. "Does this platform provide this
>> function?"
>>
>> ...
>> 
>> 
>> Alexis.
>
> This aspect of things I have found a bit perplexing.  On one hand, 
> sure, it's nice to have some scripted system spit out a:
>
> "Dependency xyz not found"
>
> But where it falls apart in my head is what that tells me that, for 
> instance, cpp's error diagnostic about a missing include or ld saying a 
> symbol or library wasn't found does.  It's in my mind a minor 
> convenience but one that doesn't justify all the machinery between 
> one's self and make just to provide.  Granted that's not all autotools 
> does, so a poor example in practice, but in theory gets at one of my 
> irks, packaging something that you are already going to discover some 
> other way.  That and "does my target platform list support xyz" isn't 
> necessarily a matter I'd wait until I've created a whole build package 
> around my software to settle...
>
> Just a small part of the puzzle but one of the parts that gives me more 
> headaches than not.  Now I don't get to respond to a compiler or linker 
> asking for something by putting it where it asked for it, now I also 
> have to figure out how to do the extra work to ensure that it's put 
> somewhere and in a way that all this machinery between myself and the 
> compiler can also verify in its own magical way component <xyz> is 
> present.
[...]

The thing about the autotools is that there are two different
audiences for different aspects of the system: consumers of the
package (sysadmins, porters, distro packagers...) and developers. In
general, the developers need to work a little harder to make life of
the consumers easier. While some consumers might be fine with (to
use the example above) a cpp error diagnostic about a missing
include, I imagine most would prefer a "configure time" diagnostic
explaining that dependency package foo needs to be installed before
they try to build it. Those who are not C or C++ developers wouldn't
necessarily know what cpp is, or how to control it.[0]

I, for one, appreciate that pretty much any build tool can be
integrated into the autotools framework, in part because it acts as
a barrier between the consumers and the underlying language-specific
build tooling, etc. The same could be (and has been) said of portable
Makefiles, but the level of effort would be quite high to achieve
what the autotools-generated Makefiles produce out of the box. E.g.,
the 'make distcheck' target not only drives a full configure and
build in a temporary directory, but also verifies that a VPATH build
(building separately from the source tree) works.

Language-specific build mechanisms are fine as far as it goes. But
the more of them you encounter and need to interact with directly,
the more friction there is. The audience for such tools is primarily
the developer. Python's pip, JavaScript's npm (or yarn, or ...),
golang, Rust's cargo, Java's mvn (or ant, or ivy, or ...), Clojure's
lein, Perl's ExtUtils::MakeMaker (or Module::Build, or ...), Ruby's
gem, ... And tooling to produce documentation is even worse:
DocBook, AsciiDoc, reStructuredText. Even driving LaTeX has become
complicated (PDFLaTeX, XeTeX, LuaTeX, ...). The developer who
necessarily understands such things can, with some effort, integrate
them into an autotools build, making life much easier for the
consumers of the package (assuming the integration has been done
well).

When the audience or consumer of the package is sysadmins (including
end-users acting as their own sysadmin), porters, and distro
packagers, I think "the usual dance" of "./configure && make" is
nice because it is consistent across underlying languages,
compilers, and whatever auxiliary tools are needed to produce
documentation, etc.

And I happen to like m4  :-)
*ducks*

-Al


[0] Sadly, the days when C was the lingua franca amongst programmers
    seem to be behind us.

-- 
a l a n   d.   s a l e w s k i
ads@salewski.email
salewski@att.net
https://github.com/salewski

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

[Larry McVoy]

Are we into bike shed territory?

It seems like cmake and autoconf are hated but then they have their fans.
I posted a makefile that was pretty portable but that was not OK because
it was GNU make?  Huh?

I've been up since 12:22am (psyched for fishing, couldn't sleep) so maybe
I'm not on point, but what is the problem that this discussion is trying
to solve?

On Fri, Jun 21, 2024 at 09:35:18AM +1000, Alexis wrote:
> Bakul Shah via TUHS <tuhs@tuhs.org> writes:
> 
> >To build a set of objects you need to worry about at least the
> >following:
> >- build recipes for each of them (which may also depend on other
> >things)
> >- configuration parameters
> >- dealing with differences on each platform
> >- third party libraries & alternatives
> >- toolchains (& may be cross-platform builds)
> >- supporting/navigating different versions of the last 3 above
> >
> >You can't really precompute all this as there are far too many
> >combinations and they keep changing.
> 
> Both the blog author (who is a long-time sysadmin with many 'war stories')
> and myself understand all that.
> 
> i believe the idea is not for precomputing to be done by _builds_, but to be
> done on and for a given machine and its configuration, independent of any
> specific piece of software, which is then _queried_ by builds. That
> precomputation would only need to be re-run when one of the things under its
> purview changes.
> 
> If i compile something on one of my OpenBSD boxen in the morning, and then
> compile some other thing in the afternoon, without an OS upgrade in-between,
> autoconf isn't going to find that libc.so has changed in-between. If i did
> the same thing on my Gentoo box, it's theoretically possible that e.g. i've
> moved from glibc to musl in-between, but in that case, precomputation could
> be done in postinst (i.e. as part of the post-installation-of-musl process).
> 
> 
> Alexis.

-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

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

[Alexis]

Larry McVoy <lm@mcvoy.com> writes:

> I've been up since 12:22am (psyched for fishing, couldn't sleep) 
> so
> maybe I'm not on point, but what is the problem that this 
> discussion
> is trying to solve?

The complexity of the autoconf-based build process contributed to 
the xz-utils backdoor attempt. (Here's Russ Cox's writeup: 
https://research.swtch.com/xz-script) So, to what extent is the 
complexity of autoconf _needed_ nowadays? For some cases, it's not 
needed (and might never have been needed). For others, it seems 
like it might still be needed. What about the in-between cases? 
Can we do something different that gets us 90% of what autoconf 
provides in those cases, but with only 10% of the complexity (to 
use those commonly-provided figures)?


Alexis.

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

[Greg A. Woods]

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

At Fri, 21 Jun 2024 10:49:34 +1000, Alexis <flexibeast@gmail.com> wrote:
Subject: [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register
>
> So,
> to what extent is the complexity of
> autoconf _needed_ nowadays?

For xz in particular Autoconf is _probably_ not necessary, but I haven't
examined it in detail.

For a vast amount of application C code and libraries no build-time
configuration beyond what's provided by the system headers and the C
compiler is necessary.  This is especially true if the code is designed
to require a slightly "modern" version of C, such as iso9899:1999
(perhaps with GNU CC extensions).

There are however some things in more systems level programs and
libraries that are more difficult to handle even with well written code,
but compared to the number of tests offered by the likes of Autoconf,
well those things are actually very few.

One thing that Autoconf gets used for, but for which it is not really
necessary, is for choosing build-time options.  Indeed its feature set
for doing so is complex and error-prone to use!  Too much weird mixing
of shell scripts and M4 macros, with all the quoting nightmare this
brings.  Just try to read XZ's configure.ac!  A simple declarative
configuration file, such as a Makefile fragment, is sufficient.

When you wander into the realm of non-C code things might also be a bit
more complex, unless of course it's Go code, where this problem simply
doesn't exist in the first place.

--
					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: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Kevin Bowling]

On Thu, Jun 20, 2024 at 6:22 PM Greg A. Woods <woods@robohack.ca> wrote:
>
> At Fri, 21 Jun 2024 10:49:34 +1000, Alexis <flexibeast@gmail.com> wrote:
> Subject: [TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register
> >
> > So,
> > to what extent is the complexity of
> > autoconf _needed_ nowadays?
>
> For xz in particular Autoconf is _probably_ not necessary, but I haven't
> examined it in detail.
>
> For a vast amount of application C code and libraries no build-time
> configuration beyond what's provided by the system headers and the C
> compiler is necessary.  This is especially true if the code is designed
> to require a slightly "modern" version of C, such as iso9899:1999
> (perhaps with GNU CC extensions).
>
> There are however some things in more systems level programs and
> libraries that are more difficult to handle even with well written code,
> but compared to the number of tests offered by the likes of Autoconf,
> well those things are actually very few.

Warner sufficiently summed up the philosophical reason for the
probe-the-world-after-slumber approach.  It seems foolish at first; a
waste of time/cycles; but the deeper you dig into the problem space
the less foolish it becomes.  As an example, autoconf builds easily
handle cross toolchains or shimmed toolchains where a mix of native
and emulated tools are used to speed up cross builds.

I agree with the chorus that the implementation of autoconf is awful.
But the audience that assume that autoconf is also bad, and the bits
and bobs of shell and make are somehow equivalent, is living in a
state of willful ignorance.

> One thing that Autoconf gets used for, but for which it is not really
> necessary, is for choosing build-time options.  Indeed its feature set
> for doing so is complex and error-prone to use!  Too much weird mixing
> of shell scripts and M4 macros, with all the quoting nightmare this
> brings.  Just try to read XZ's configure.ac!  A simple declarative
> configuration file, such as a Makefile fragment, is sufficient.
>
> When you wander into the realm of non-C code things might also be a bit
> more complex, unless of course it's Go code, where this problem simply
> doesn't exist in the first place.

Go's approach was the same as Java, if you control the level of
abstraction sufficiently you eliminate much of the complexity.

>
> --
>                                         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>

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

[Chet Ramey via TUHS]

[-- Attachment #1.1: Type: text/plain, Size: 1289 bytes --]

On 6/20/24 7:35 PM, Alexis wrote:

> i believe the idea is not for precomputing to be done by _builds_, but to 
> be done on and for a given machine and its configuration, independent of 
> any specific piece of software, which is then _queried_ by builds. That 
> precomputation would only need to be re-run when one of the things under 
> its purview changes.

This is the rationale behind local (package-specific) and global (site-
specific) versions of config.cache and `configure -C'. I use them all the
time; they reduce configuration time considerably. (But then, I am probably
building more often than someone who just downloads a source tarball,
builds it, and installs the result.)

> If i compile something on one of my OpenBSD boxen in the morning, and then 
> compile some other thing in the afternoon, without an OS upgrade 
> in-between, autoconf isn't going to find that libc.so has changed 
> in-between. 

configure and config.cache compute the results for a given build
environment. If you change that, whose responsibility is it to update the
dependencies?

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

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

[Alexis]

Chet Ramey via TUHS <tuhs@tuhs.org> writes:

> On 6/20/24 7:35 PM, Alexis wrote:

>> If i compile something on one of my OpenBSD boxen in the 
>> morning,
>> and then compile some other thing in the afternoon, without an 
>> OS
>> upgrade in-between, autoconf isn't going to find that libc.so 
>> has
>> changed in-between. 
>
> configure and config.cache compute the results for a given build
> environment. If you change that, whose responsibility is it to 
> update
> the
> dependencies?

Sorry, i'm not sure i understand your question, particularly given 
that i was writing about the situation where a fundamental part of 
the build environment _hasn't_ changed .... Could you please 
elaborate or rephrase?


Alexis.

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

[Chet Ramey via TUHS]

[-- Attachment #1.1: Type: text/plain, Size: 1212 bytes --]

On 6/21/24 5:04 PM, Alexis wrote:
> Chet Ramey via TUHS <tuhs@tuhs.org> writes:
> 
>> On 6/20/24 7:35 PM, Alexis wrote:
> 
>>> If i compile something on one of my OpenBSD boxen in the morning,
>>> and then compile some other thing in the afternoon, without an OS
>>> upgrade in-between, autoconf isn't going to find that libc.so has
>>> changed in-between. 
>>
>> configure and config.cache compute the results for a given build
>> environment. If you change that, whose responsibility is it to update
>> the
>> dependencies?
> 
> Sorry, i'm not sure i understand your question, particularly given that i 
> was writing about the situation where a fundamental part of the build 
> environment _hasn't_ changed .... Could you please elaborate or rephrase?

I think we're kind of saying the same thing. The autotools can't update
dependencies if something in the environment changes, regardless of whether
an OS update has occurred or not. That responsibility has to fall on the
admin or other tools.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

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

[Luther Johnson]

If I could say something a little more meta, and echoing an earlier
comment - autotools, configure, etc, don't do the port for you - it's up
to the author to decide and test what OS features are required, and if
something hasn't been too implicitly assumed, if a "needs this" hasn't
been left out, then the "configure && make" process will give you the
right build for a system that is indeed, already supported. If it
doesn't build, we can interpret that as "not supported", or that the
author did not sufficiently adjust input to the build process, or test
similar-enough configurations, to get the right build for that system.
But that is not an indictment of this whole way of doing things, or the
tools themselves, necessarily. It may just mean that someone made some
fairly ordinary mistake along the way in setting up the build. Or that
the system on which we are trying to build is different in a way that
the author did not imagine.

On 06/22/2024 10:53 AM, Chet Ramey via TUHS wrote:
> On 6/21/24 5:04 PM, Alexis wrote:
>> Chet Ramey via TUHS <tuhs@tuhs.org> writes:
>>
>>> On 6/20/24 7:35 PM, Alexis wrote:
>>
>>>> If i compile something on one of my OpenBSD boxen in the morning,
>>>> and then compile some other thing in the afternoon, without an OS
>>>> upgrade in-between, autoconf isn't going to find that libc.so has
>>>> changed in-between.
>>>
>>> configure and config.cache compute the results for a given build
>>> environment. If you change that, whose responsibility is it to update
>>> the
>>> dependencies?
>>
>> Sorry, i'm not sure i understand your question, particularly given
>> that i was writing about the situation where a fundamental part of
>> the build environment _hasn't_ changed .... Could you please
>> elaborate or rephrase?
>
> I think we're kind of saying the same thing. The autotools can't update
> dependencies if something in the environment changes, regardless of
> whether
> an OS update has occurred or not. That responsibility has to fall on the
> admin or other tools.
>

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

[David Arnold]

> On 23 Jun 2024, at 04:16, Luther Johnson <luther.johnson@makerlisp.com> wrote:
> 
> If I could say something a little more meta, and echoing an earlier
> comment - autotools, configure, etc, don't do the port for you - it's up
> to the author to decide and test what OS features are required, and if
> something hasn't been too implicitly assumed, if a "needs this" hasn't
> been left out, then the "configure && make" process will give you the
> right build for a system that is indeed, already supported. If it
> doesn't build, we can interpret that as "not supported", or that the
> author did not sufficiently adjust input to the build process, or test
> similar-enough configurations, to get the right build for that system.

The author thus ends up searching for a sweet spot: test too many things, and people complain that you’re wasting time checking something that is always true; test too few, and it will break on relatively common platforms. 

As an example, mentioned up-thread, building on Ultrix in 2024: you need to test and work around a bunch of things that have been fixed on anything updated since the mid-90’s to get a clean build on Ultrix, SunOS-4.x, etc.  Your average Linux or macOS user sees this as pointless time wasting.  

There’s no right answer here: someone is always annoyed at you. 




d

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

[segaloco via TUHS]

On Saturday, June 22nd, 2024 at 2:16 PM, David Arnold <davida@pobox.com> wrote:

> > On 23 Jun 2024, at 04:16, Luther Johnson luther.johnson@makerlisp.com wrote:
> > 
> > If I could say something a little more meta, and echoing an earlier
> > comment - autotools, configure, etc, don't do the port for you - it's up
> > to the author to decide and test what OS features are required, and if
> > something hasn't been too implicitly assumed, if a "needs this" hasn't
> > been left out, then the "configure && make" process will give you the
> > right build for a system that is indeed, already supported. If it
> > doesn't build, we can interpret that as "not supported", or that the
> > author did not sufficiently adjust input to the build process, or test
> > similar-enough configurations, to get the right build for that system.
> 
> 
> The author thus ends up searching for a sweet spot: test too many things, and people complain that you’re wasting time checking something that is always true; test too few, and it will break on relatively common platforms.
> 
> As an example, mentioned up-thread, building on Ultrix in 2024: you need to test and work around a bunch of things that have been fixed on anything updated since the mid-90’s to get a clean build on Ultrix, SunOS-4.x, etc. Your average Linux or macOS user sees this as pointless time wasting.
> 
> There’s no right answer here: someone is always annoyed at you.
> 
> 
> 
> 
> d

Well and part of that is indeed being intentional about platform support, fancy toolkit or not.  If you're specifically intending to support just a particular vendor's platform, you make programming choices, not build machinery choices, towards that end.  Similarly, if you truly expect something you write to work everywhere with minimal modification, no amount of build machinery is a substitute for pulling up and adhering as closely to POSIX as possible, same with non-UNIX platforms and being intentional about ANSI C.

Now, if you're trying to use things these least common denominators don't include, like for instance ANSI C+thread support, build machinery still isn't going to be what makes your program work, you have to write or otherwise incorporate an abstraction layer over the available system services, be it pthreads, Win32 threads, etc.

That all said, one excellent point I must agree with up thread is that a build system will be used by a small handful of devs but then countless consumers who aren't experts in programming and that expect things to "just work". We as programmers may be fine with an "alias cc=<insert cross-compiler here>" to avoid some lengthy cross-compiler detection mechanism in our own development process, but tell every consumer they have to set a bunch of environment variables and/or aliases to get a makefile to work and they'll throw their hands up and look for something with a configure script *even if* the former really is an easier and more dependable way to get exactly what you want.

I say this because the former is how I've handled personal projects for a bit now, if I do need any environmental difference from the flat makefile in my project, I setup that environment just-in-time by hand, which usually just amounts to aliasing a command or too, maybe adding to LD_LIBRARY_PATH, that sort of thing, or if it's frequent enough, just do this with a teeny tiny script.  I like the control and terseness of the setup, but throw that at someone who is used to using a package manager or at most using a configure script or CMake, and yeah, they'd probably balk at the lack of "sophistication" in your distributable.

Looking at it as an accessibility matter rather than a developmental necessity certainly gives me different feelings about all this stuff.  I may not need it and indeed would likely be mildly inconvenienced in some situations, but for someone else, it's a crucial piece of their experience.  These words may ring true about the original subject of systemd as well...

- Matt G.

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

[Theodore Ts'o]

On Sun, Jun 23, 2024 at 07:16:35AM +1000, David Arnold wrote:
> 
> As an example, mentioned up-thread, building on Ultrix in 2024: you
> need to test and work around a bunch of things that have been fixed
> on anything updated since the mid-90’s to get a clean build on
> Ultrix, SunOS-4.x, etc.  Your average Linux or macOS user sees this
> as pointless time wasting.

In practice, the set of OS's which a particular software package using
autotools will change over time.  For me and e2fsprogs, just to give a
concrete example, there is the set of packages for which I personally
have access to.  Many years ago this included Ultrix, OSF/1, AIX,
Irix, and Solaris; and when I did have easy access to those machines,
it wasn't hard for me to do a test compile, and when things broke, it
was easy enough to add (or write) an autoconf test, and fix that
particular build or test breakage.  There would also be OS's for which
I did not have direct access --- for example HPUX, where (a) sometimes
the portability work that I did for AIX or Solaris would address eome
portability issue on HPUX, or (b) someone building the package on HPUX
would send me a bug report, and in general, it would be really easy to
fix up the sources so that things worked on HPUX.

So surprise, Autotools is not magic.  It will not magically make your
code portable.  However, for someone who *wants* to make portable
code, I've found autotools to be the most developer friendly way of
supporting portable code.  Certainly, it's ***way*** more
user-friendly than imake, for which I have had the misfortune of
having to have used, and because autotools is test features, and not
OS's, it's much easier to support than needing to have a manually
curated set of #define's for each OS that you want to support.  (I
can't beieve people think that's a good idea; I would find that
incredibly painful and would involve much more work.)

What does happen over time, though, is that when the maintainer, or
the development commuity at large, loses access to an hardware and/or
OS combination, support for that that platform will start to rot, and
things will gradully start breaking as new feature development will
accidentally add some dependency which can't be guaranteed everywhere.

Yes, you can have someone strictly trying to require that no advanced
feature beyond that which was available in BSD 4.3 be used, in the
name of portability, but sometimes there are real functional and
performance sacrifices that might get made if you do that.

> There’s no right answer here: someone is always annoyed at you.

Indeed, and there will always be people who want to backseat drive and
tell you that you should do things their way.  I find there's a lot of
religion wrapped up here, much like the choice of ed, vi or emacs....

	 	    	       	    	       - Ted
					       

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

[Chet Ramey via TUHS]

[-- Attachment #1.1: Type: text/plain, Size: 648 bytes --]

On 6/22/24 2:15 PM, Luther Johnson wrote:
> It may just mean that someone made some
> fairly ordinary mistake along the way in setting up the build. Or that
> the system on which we are trying to build is different in a way that
> the author did not imagine.

A third possibility is that the author or authors decided not to test for
and support a set of (in this case) older systems. Not a lack of
imagination, but a development priority decision.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

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

[Stuff Received]

On 2024-06-23 14:56, Chet Ramey via TUHS wrote:
> On 6/22/24 2:15 PM, Luther Johnson wrote:
>> It may just mean that someone made some
>> fairly ordinary mistake along the way in setting up the build. Or that
>> the system on which we are trying to build is different in a way that
>> the author did not imagine.
> 
> A third possibility is that the author or authors decided not to test for
> and support a set of (in this case) older systems. Not a lack of
> imagination, but a development priority decision.

My opinion is that the authors simply did not have access to other 
systems or were not interested.  Sometimes, one finds a disclaimer to 
that effect.  I understand that but I am irked when they claim POSIX 
compliance.

S.

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

[Theodore Ts'o]

On Sun, Jun 23, 2024 at 04:15:40PM -0400, Stuff Received wrote:
> My opinion is that the authors simply did not have access to other
> systems or were not interested.  Sometimes, one finds a disclaimer to
> that effect.  I understand that but I am irked when they claim POSIX
> compliance.

I get irked because Posix compliance applies to OS's (a specific
binary release of the kernel plus userspace runtime environment), and
not to applications.

Also, compliance implies that it has passed a specific test process,
after paying $$$$ to a Posix Test Compliance Lab, and said compliance
certificate gets revoked the moment you fix a security bug, until you
go and you pay additional $$$ to the Posix compliance lab.  Basically,
it's racket that generally only companies who need to sell into the US
or European government market were willing to play.  (e.g., at one
point there were Red Hat and SuSE distributions which were POSIX
certified, but Fedora or Debian never were.)

A project or vendor could claim that there product was a "strictly
conforming POSIX application[1], but that's hard to actually prove
(which is why there is no compliance testing for it), since not only
do you have to limit yourself to only those interface guaranted to be
present by POSIX, but you must also not depend on any behavior which
specified to be "implementation defined" (and very often many
traditional Unix behaviors are technically "implementation defined",
so that VMS and Windows could claim to be be "POSIX compliant
implementation".)  So a strictly POSIX conforming application was
likely only relevant for very simple "toy" applications that didn't
need to do anything fancy, like say, networking.

(Berkeley sockets couldn't be required because AT&T Streams.  Oh,
joy.)

[1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap02.html#tag_02_02_01

Can you tell I'm a bit jaded and cynical about the whole Posix
compliance/conformance thing?   :-)

Cheers,

						- Ted

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

[Dan Cross]

On Mon, Jun 24, 2024 at 10:12 AM Theodore Ts'o <tytso@mit.edu> wrote:
> On Sun, Jun 23, 2024 at 04:15:40PM -0400, Stuff Received wrote:
> > My opinion is that the authors simply did not have access to other
> > systems or were not interested.  Sometimes, one finds a disclaimer to
> > that effect.  I understand that but I am irked when they claim POSIX
> > compliance.
>
> I get irked because Posix compliance applies to OS's (a specific
> binary release of the kernel plus userspace runtime environment), and
> not to applications.
>
> Also, compliance implies that it has passed a specific test process,
> after paying $$$$ to a Posix Test Compliance Lab, and said compliance
> certificate gets revoked the moment you fix a security bug, until you
> go and you pay additional $$$ to the Posix compliance lab.  Basically,
> it's racket that generally only companies who need to sell into the US
> or European government market were willing to play.  (e.g., at one
> point there were Red Hat and SuSE distributions which were POSIX
> certified, but Fedora or Debian never were.)
>
> A project or vendor could claim that there product was a "strictly
> conforming POSIX application[1], but that's hard to actually prove
> (which is why there is no compliance testing for it), since not only
> do you have to limit yourself to only those interface guaranted to be
> present by POSIX, but you must also not depend on any behavior which
> specified to be "implementation defined" (and very often many
> traditional Unix behaviors are technically "implementation defined",
> so that VMS and Windows could claim to be be "POSIX compliant
> implementation".)  So a strictly POSIX conforming application was
> likely only relevant for very simple "toy" applications that didn't
> need to do anything fancy, like say, networking.

Also, what is "POSIX" changes over time: new things are added, and
occasionally something is removed. Indeed, a new version was just
released a couple of weeks ago. So what does it mean to say that some
OS conforms to POSIX? Which version? For some very old systems,
particularly those that are no longer being substantially updated but
that may have conformed to an older version of the standard, they may
have credibly claimed "POSIX compliant" at some point in the past, but
time has left them behind.

It is unreasonable to constrain program authors to ancient versions of
standards just because some tiny fraction of people want to use an old
system.

Consider 4.3BSD, for example: it shipped with a compiler that predated
the ANSI C standard, and doesn't understand the ANSI-style function
declaration syntax. Should one restrict oneself to the traditional C
dialect forever? If so, one loses out on the substantial benefits of
stronger type checking. Or consider better string handling functions
that came later (`snprintf` is an obvious example, but I would argue
`strlcpy` and `strlcat` as well). Should we restrict ourselves to
laborious and error-prone shenanigans with `strlen` and `strcpy` just
to keep code running on a Sun4c machine under SunOS 4? I really don't
think so.

        - Dan C.


> (Berkeley sockets couldn't be required because AT&T Streams.  Oh,
> joy.)
>
> [1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap02.html#tag_02_02_01
>
> Can you tell I'm a bit jaded and cynical about the whole Posix
> compliance/conformance thing?   :-)
>
> Cheers,
>
>                                                 - Ted

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

[Warner Losh]

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

On Mon, Jun 24, 2024 at 8:33 AM Dan Cross <crossd@gmail.com> wrote:

> On Mon, Jun 24, 2024 at 10:12 AM Theodore Ts'o <tytso@mit.edu> wrote:
> > On Sun, Jun 23, 2024 at 04:15:40PM -0400, Stuff Received wrote:
> > > My opinion is that the authors simply did not have access to other
> > > systems or were not interested.  Sometimes, one finds a disclaimer to
> > > that effect.  I understand that but I am irked when they claim POSIX
> > > compliance.
> >
> > I get irked because Posix compliance applies to OS's (a specific
> > binary release of the kernel plus userspace runtime environment), and
> > not to applications.
> >
> > Also, compliance implies that it has passed a specific test process,
> > after paying $$$$ to a Posix Test Compliance Lab, and said compliance
> > certificate gets revoked the moment you fix a security bug, until you
> > go and you pay additional $$$ to the Posix compliance lab.  Basically,
> > it's racket that generally only companies who need to sell into the US
> > or European government market were willing to play.  (e.g., at one
> > point there were Red Hat and SuSE distributions which were POSIX
> > certified, but Fedora or Debian never were.)
> >
> > A project or vendor could claim that there product was a "strictly
> > conforming POSIX application[1], but that's hard to actually prove
> > (which is why there is no compliance testing for it), since not only
> > do you have to limit yourself to only those interface guaranted to be
> > present by POSIX, but you must also not depend on any behavior which
> > specified to be "implementation defined" (and very often many
> > traditional Unix behaviors are technically "implementation defined",
> > so that VMS and Windows could claim to be be "POSIX compliant
> > implementation".)  So a strictly POSIX conforming application was
> > likely only relevant for very simple "toy" applications that didn't
> > need to do anything fancy, like say, networking.
>
> Also, what is "POSIX" changes over time: new things are added, and
> occasionally something is removed. Indeed, a new version was just
> released a couple of weeks ago. So what does it mean to say that some
> OS conforms to POSIX? Which version? For some very old systems,
> particularly those that are no longer being substantially updated but
> that may have conformed to an older version of the standard, they may
> have credibly claimed "POSIX compliant" at some point in the past, but
> time has left them behind.
>

Certification only lasts a certain amount of time... And the compliance
isn't
with POSIX, but POSIX.1-2008 or POSIX.1-2024.

The advantage of POSIX, though, is that it tries to keep up with the changes
in interfaces, tastes, etc. So aiming for it is a useful "fuzzy cloud" of
what's
currently most likely to be portable to most modern (read: released in the
last decade or less) systems.


> It is unreasonable to constrain program authors to ancient versions of
> standards just because some tiny fraction of people want to use an old
> system.
>

Indeed. Ancient systems in general are best dealt with by some
common sense build hacks. libposix can handle the missing functionality
for people that care about these ancient systems, and "layered" include
systems work for systems that are at least new enough to have #include_next
(and #include "/usr/include/stdio.h" for those that don't). Pushing that job
to a thousand package writers is a loser. I've done this for various older
systems that I've dabbled with and it becomes a question of how much
is enough...

I do similar things to build a few Linux applications on FreeBSD w/o
bothering the authors too much (I fix bugs that don't matter on Linux,
but make my shim layer smaller though). But that's mostly a modern ->
modern so C dialect is identical (enough), and the only troublesome
interfaces are the Linux Specific ones which I map to FreeBSD
functionality. I've never formalized this since I only have a few I care
about that are a bit resistant to accepting FreeBSD patches...


> Consider 4.3BSD, for example: it shipped with a compiler that predated
> the ANSI C standard, and doesn't understand the ANSI-style function
> declaration syntax. Should one restrict oneself to the traditional C
> dialect forever? If so, one loses out on the substantial benefits of
> stronger type checking. Or consider better string handling functions
> that came later (`snprintf` is an obvious example, but I would argue
> `strlcpy` and `strlcat` as well). Should we restrict ourselves to
> laborious and error-prone shenanigans with `strlen` and `strcpy` just
> to keep code running on a Sun4c machine under SunOS 4? I really don't
> think so.
>

Yea.


>         - Dan C.
>
>
> > (Berkeley sockets couldn't be required because AT&T Streams.  Oh,
> > joy.)
>

Sockets are standardized these days in POSIX, though. IPv6 is optional,
though if you support it, you have to support it with the interfaces
defined.
Same with Raw Sockets. But most of that's there (and been there
since 2008 or earlier)


> > [1]
> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap02.html#tag_02_02_01
> >
> > Can you tell I'm a bit jaded and cynical about the whole Posix
> > compliance/conformance thing?   :-)
>

Yea, Just because POSIX says so has been a terrible excuse for doing
something
silly. FreeBSD has long recognized it. However, in moderation, POSIX is a
very good
thing. Exact, pedantic, 100% conformance with no flexibility... isn't.

Warner

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

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

[Chet Ramey via TUHS]

[-- Attachment #1.1: Type: text/plain, Size: 793 bytes --]

On 6/23/24 4:15 PM, Stuff Received wrote:

> My opinion is that the authors simply did not have access to other systems 
> or were not interested.  Sometimes, one finds a disclaimer to that effect.  
> I understand that but I am irked when they claim POSIX compliance.

These are not at all the same. "POSIX compliance," from an application's
perspective, means that the application behaves the way POSIX says it
should for the behaviors POSIX standardizes. That doesn't have much to do
with the author's implementation choices or whether or not the
application runs on arbitrary systems.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

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

[Chet Ramey via TUHS]

[-- Attachment #1.1: Type: text/plain, Size: 622 bytes --]

On 6/17/24 9:52 PM, Steve Nickolas wrote:

> 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).

I ported it to macOS to use as a testing variant. You might contact kre
and see if he's interested in your work; he and I talked a year or two
ago about his possible future plans to release a portable version.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

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

[Chet Ramey via TUHS]

[-- Attachment #1.1: Type: text/plain, Size: 1052 bytes --]

On 6/17/24 6:34 PM, Steve Nickolas wrote:
> On Mon, 17 Jun 2024, Stuff Received wrote:
> 
>> On 2024-06-16 21:25, Larry McVoy wrote (in part):
>> [...]
>>> *Every* time they used some bash-ism, it bit us in the ass.
>>
>> This is so true for a lot of OS projects (on Github, for example).  Most 
>> -- sometimes all -- the scripts that start with /bin/sh but are full of 
>> bashisms because the authors run systems where /bin/sh is really bash.
> 
> Which is why I'm glad Debian's /bin/sh is dash (fork of ash) instead.

Like everything else, it depends on your goals. If portability across
different OSs is a goal, and you can't be guaranteed that bash will be
available, it's best to stick with POSIX features. If you want to run
places where you can be guaranteed that bash exists, use whatever
`bashisms' you like and use `#! /bin/bash'.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

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

[Alexander Schreiber]

On Sun, Jun 16, 2024 at 06:25:31PM -0700, Larry McVoy wrote:
> On Mon, Jun 17, 2024 at 11:01:40AM +1000, Alexis wrote:
> > 
> > The issue isn't about learning shell scripting _per se_. It's about the
> > extent to which _volunteers_ have to go beyond the _basics_ of shell
> > scripting to learn about the _complexities_ and _subtle issues_ involved in
> > using it to provide _robust_ service management. Including learning, for
> > example, that certain functionality one takes for granted in a given shell
> > isn't actually POSIX, and can't be assumed to be present in the shell one is
> > working with (not to mention that POSIX-compatibility might need to be
> > actively enabled, as in the case of e.g. ksh, via POSIXLY_CORRECT).
> 
> This is sort of off topic but maybe relevant.
> 
> When I was running my company, my engineers joked that if it were invented
> after 1980 I wouldn't let them use it.  Which wasn't true, we used mmap().
> 
> But the underlying sentiment sort of was true.  Even though they were
> all used to bash, I tried very hard to not use bash specific stuff.
> And it paid off, in our hey day, we supported SCO, AIX, HPUX, SunOS,
> Solaris, Tru64, Linux on every architecture from tin to IBM mainframes,
> Windows, Macos on PPC and x86, etc.  And probably a bunch of other
> platforms I've forgotten.
> 
> *Every* time they used some bash-ism, it bit us in the ass.  I kept
> telling them "our build environment is not our deployment environment".
> We had a bunch of /bin/sh stuff that we shipped so we had to go for 
> the common denominator.

My latest brush with someone using bash in the wrong place was when
I saw the configure scripts for GlusterFS break on NetBSD. Because
someone had used bash 4 syntax in the configure scripts ... presumably
on a Linux variant where /bin/sh == /bin/bash. While that was easy to
fix (and the PR accepted and patched in) I shouldn't have had to fix
that in the first place ... 

Kind regards,
            Alex.
-- 
"Opportunity is missed by most people because it is dressed in overalls and
 looks like work."                                      -- Thomas A. Edison

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

[Wesley Parish]

On 16/06/24 17:48, Alexis wrote:
> Grant Taylor via TUHS <tuhs@tuhs.org> writes:
>
>> I'm anti-systemd *cough*Master Control Program*cough* and it's
>> associated suite of utilities for many reasons.  But I've come to
>> accept that systemd is not just an init system.  It's role of a
>> service life cycle manager is a superset of what an init system does.
>> It's a relatively new world (at least comparatively).
>
> Indeed: it doesn't just do init, but also _service supervision_ 
> (making sure that a service that _should_ be up, _is_ up) and _service 
> management_ (enabling, disabling, starting, stopping, dependencies, 
> etc.). Hence why phrases like "the init wars" are such a misnomer.
>
> As described in the potted history outlined in the "known problems 
> with System 5 rc" article i linked to upthread, Sys V rc's issues with 
> service supervision and service management have been known for decades:
>
>> In 1999, Luke Mewburn worked on replacing the /etc/rc system in 
>> NetBSD. netbsd.tech.userlevel mailing list discussions from the time 
>> show several criticisms of the System 5 rc and System 5 init systems, 
>> and encouragement not to repeat their mistakes in the BSD world. The 
>> resultant rc.d system was roughly contemporary with Daniel Robbins 
>> producing OpenRC, another System 5 rc replacement that replaced the 
>> (Bourne/Bourne Again) shell with a different script interpreter, 
>> nowadays named /sbin/openrc, that provided a whole lot of standard 
>> service management functionality as pre-supplied functions. The 
>> NetBSD rc.d system likewise reduced rc.d scripts to a few variable 
>> assignments and function calls (in about two thirds of cases). 
>
> The initial release of OpenRC - still Gentoo's 'native' system for 
> service management - was in April 2007; the initial release of systemd 
> was in March 2010. But although both OpenRC and systemd address 
> various pain points of Sys V rc on Linux, systemd has _also_ had the 
> backing of an 800-pound gorilla in the Linux world - Red Hat - which 
> has _implicitly_ forced its adoption over alternatives by distros that 
> don't have the same level of resources behind them.
>
> Here's an excerpt from something i wrote on the Gentoo forum back in 
> April:
>
>> There's been so much anger and vitriol expressed about systemd. Has 
>> that significantly slowed the systemd juggernaut? Not really. Not 
>> least because, as in the case of D-Bus, and as in the case of 
>> Wayland, it addresses very real issues for significant numbers of 
>> people.
>>
>> For example: unlike on, say, OpenBSD, which has developed a pretty 
>> clean shell-script-based service management system, with a 'standard 
>> library' in the form of rc.subr(8), the situation on Linux was a 
>> mess. Many of the (usually volunteers) who maintain packages for 
>> Linux don't want to have to learn the complexities of shell scripting 
>> and the subtle issues that can arise, or develop and maintain 
>> workarounds for race conditions, and so on. systemd comes along and 
>> says: "Hey, with systemd, you'll be able to write service definitions 
>> declaratively; you won't need to wrangle shell scripts." That's a 
>> pretty attractive proposition to a number of package maintainers, and 
>> in the absence of systemd alternatives explicitly providing such an 
>> interface - not just saying "oh that could be done on our 
>> alternative" - those maintainers are going to be inclined towards 
>> systemd, regardless of what design and implementation issues are 
>> involved in systemd's approach.
>>
>> So in wanting to try to ensure that myself and others have choices 
>> and alternatives available, i feel that ranting against the incoming 
>> tide, like a tech King Cnut, is typically far less effective than 
>> actually putting in the work to develop and support those choices and 
>> alternatives. 
>
>
> Alexis.

Might also be worth pointing out that Red Hat's an IBM *nix daemon, and 
IBM's mainframe business is built in no small part on service managers 
in the OS management layer. I expect their "Phone Home" ability was 
part-and-parcel of the IBM mainframe service contracts. If systemd 
phones home without an explicit (ie, sign-on-the-dotted-line type) 
contract between me and Red Hat, I'll raise a stink about - but so far 
it hasn't. (I'm running Fedora.)

Wesley Parish

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

[David Arnold]

> On 15 Jun 2024, at 00:18, Grant Taylor via TUHS <tuhs@tuhs.org> wrote:
> 
> It's my understanding that systemd as a service lifecycle manager is starting to take on some aspects of what cluster service managers used to do.

I think it goes beyond this, and that systemd is just a convenient focus point for folks to push back against a wider set of changes.

My usual example here is PolKit and polkitd. In this latest systemd release, for example, it seems the new systemd-run0 command (replacing sudo or su), starts a privileged process by checking permissions with polkitd over DBus, and then uses systemd to actually fork and setup the “child”. 

This is a fairly distinctive departure from how Unix works: over the last decade, Linux has increasingly moved away from being Unix, and I think this is why people find systemd so confronting.  And there’s more to come, eg. varlink. 

I’m sure systemd, polkitd and their ilk address real needs. But the solution isn’t (in my view) Unix-like, and those for whom Linux is a convenient Unix are disappointed (to put it mildly).

The world is no longer a PDP-11 or a Vax or a SPARCstation.  USB in particular introduced a lot more dynamism to the Unix device model, and started us down this path of devfs, DBus, systemd, etc.  Users reasonably want things to work, and Red Hat wants to satisfy those users, and they’ve chosen this way to do it. Unfortunately, there’s been no real competition: this goes well beyond system startup, and well beyond service management, and citing s6 or launchd or whatever misses the war by focusing on the battle. 



d

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

[Luther Johnson]

I think there's a parallel from the Unix/Linux systems that we think of
as more Unix-like, to the cars and airplanes and other machines of that
and earlier eras. It used to be that part of the design of a system,
alongside its operation, was the idea of normal, regular maintenance.
The system could be pretty simple, but there was some maintenance and
wearable parts replacement required. It was expected that there was an
administrator or mechanic checking in once in a while to keep things
tuned and in "good repair". This worked well, as long as people accepted
this responsibility as part of the deal.

Now it seems like people want everything done for them automatically,
and not to have to know anything about the systems they are using. They
want the systems to be smarter so they don't have to know as much. It's
sort of like when the private airplane industry tried to engineer any
skill required on the part of the pilot, out of the airplane. The
results were not good. Planes became more complex, with more points of
failure, and pilots did not know how to react to unexpected situations.
I see this happening with our computer systems, and the people using
them now, too. Of course there's a reasonable middle ground, but I think
we've gone a little too far making things "easy", and in fact it's not
easier at all, we're just fiddling in a different way, often through
random trial and error, it all seems horribly indirect, opaque, and
irrational, to support some programmer's idea somewhere, of some perfect
abstraction.

For example: CMake vs. just learning how to write makefiles properly.
You fiddle with CMake and you never really know why it does what it
does, especially from one version to the next, "but you don't have to
write makefiles".

On 06/16/2024 02:56 PM, David Arnold wrote:
>> On 15 Jun 2024, at 00:18, Grant Taylor via TUHS <tuhs@tuhs.org> wrote:
>>
>> It's my understanding that systemd as a service lifecycle manager is starting to take on some aspects of what cluster service managers used to do.
> I think it goes beyond this, and that systemd is just a convenient focus point for folks to push back against a wider set of changes.
>
> My usual example here is PolKit and polkitd. In this latest systemd release, for example, it seems the new systemd-run0 command (replacing sudo or su), starts a privileged process by checking permissions with polkitd over DBus, and then uses systemd to actually fork and setup the “child”.
>
> This is a fairly distinctive departure from how Unix works: over the last decade, Linux has increasingly moved away from being Unix, and I think this is why people find systemd so confronting.  And there’s more to come, eg. varlink.
>
> I’m sure systemd, polkitd and their ilk address real needs. But the solution isn’t (in my view) Unix-like, and those for whom Linux is a convenient Unix are disappointed (to put it mildly).
>
> The world is no longer a PDP-11 or a Vax or a SPARCstation.  USB in particular introduced a lot more dynamism to the Unix device model, and started us down this path of devfs, DBus, systemd, etc.  Users reasonably want things to work, and Red Hat wants to satisfy those users, and they’ve chosen this way to do it. Unfortunately, there’s been no real competition: this goes well beyond system startup, and well beyond service management, and citing s6 or launchd or whatever misses the war by focusing on the battle.
>
>
>
> d
>

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

[Larry McVoy]

On Sun, Jun 16, 2024 at 04:34:34PM -0700, Luther Johnson wrote:
> I think there's a parallel from the Unix/Linux systems that we think of
> as more Unix-like, to the cars and airplanes and other machines of that
> and earlier eras. It used to be that part of the design of a system,
> alongside its operation, was the idea of normal, regular maintenance.
> The system could be pretty simple, but there was some maintenance and
> wearable parts replacement required. It was expected that there was an
> administrator or mechanic checking in once in a while to keep things
> tuned and in "good repair". This worked well, as long as people accepted
> this responsibility as part of the deal.
> 
> Now it seems like people want everything done for them automatically,
> and not to have to know anything about the systems they are using. They
> want the systems to be smarter so they don't have to know as much. It's
> sort of like when the private airplane industry tried to engineer any
> skill required on the part of the pilot, out of the airplane. The
> results were not good. Planes became more complex, with more points of
> failure, and pilots did not know how to react to unexpected situations.
> I see this happening with our computer systems, and the people using
> them now, too. Of course there's a reasonable middle ground, but I think
> we've gone a little too far making things "easy", and in fact it's not
> easier at all, we're just fiddling in a different way, often through
> random trial and error, it all seems horribly indirect, opaque, and
> irrational, to support some programmer's idea somewhere, of some perfect
> abstraction.
> 
> For example: CMake vs. just learning how to write makefiles properly.
> You fiddle with CMake and you never really know why it does what it
> does, especially from one version to the next, "but you don't have to
> write makefiles".

I could not agree more with this post, all of it, but especially the 
Cmake stuff.  Writing Makefiles isn't that hard, if you are a programmer
and can't do that, how good of a programmer are you?  And is it really
easier to learn shiny-new-make-replacement-du-jour every year?

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

[Steffen Nurpmeso]

Larry McVoy wrote in
 <20240616234654.GB12821@mcvoy.com>:
 |On Sun, Jun 16, 2024 at 04:34:34PM -0700, Luther Johnson wrote:
 |> I think there's a parallel from the Unix/Linux systems that we think of
 ...
 |> For example: CMake vs. just learning how to write makefiles properly.
 |> You fiddle with CMake and you never really know why it does what it
 |> does, especially from one version to the next, "but you don't have to
 |> write makefiles".
 |
 |I could not agree more with this post, all of it, but especially the 
 |Cmake stuff.  Writing Makefiles isn't that hard, if you are a programmer
 |and can't do that, how good of a programmer are you?  And is it really
 |easier to learn shiny-new-make-replacement-du-jour every year?

It must be said that "thrillingly fast" is a key item all those
(maybe ninja cmake ant) throw in.
And that it takes quite a bit of (non-portability and) thought to
empower "normal" makefiles to achieve full parallelism etc.

I think you watch the FreeBSD hacker community, and there is "war"
around the "meta-mode" (against cmake) to avoid recompilations etc.
Multiple people are working on BSD make and the BSD makefile
system.  (In fact on NetBSD the last years even saw a tremendous
run on overhauling BSD make, which then only got imported to
FreeBSD.)  The files are very dense after decades of engineering,
and due to "clean namespace" paradigm there are long variable
names that sometimes fill half of an eighty column screen alone;
for (stupid first-see-and-take) things like
  INSTALL_DDIR=   ${_INSTALL_DDIR:S://:/:g:C:/$::}
you need a clear head.  This is not self-descriptive.  (Not to
talk about the fact that lines (may) become expanded by the shell
after they have become expanded by make, ie, all the quoting, and
the delayed or immediate macro expansion mechanism(s).)

Original make did not have conditionals, or file inclusions, or
dedicated control of parallelism (on file, on target level) via
.NOTPARALLEL: and .WAIT:, so things like
  tangerine: config .WAIT build .WAIT test .WAIT install
are not portable.  (In fact portability and parallelism is not
possible unless you use a recursive approach, with all the
pitfalls that then brings.)
And then all the bugs everywhere, with quoting pitfalls, and this
applies to helper tools like awk too (ie xpg4/bin/awk even
documents "Notice that backslash escapes are interpreted twice").

I also remember (from the time i still gave money to journalists)
terms like "the usual triad" for "./configure && make && make
install" with that implied "grazy times, but that is how you do
it" undertone maybe even.  Now i see for example "cmake -D VAR1
.. && cmake --build build && cmake --install build" which is
possibly easier to grasp when compiling a C compiler that is 1.2
GiB when installed.

 --End of <20240616234654.GB12821@mcvoy.com>

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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

[Åke Nordin]

On 2024-06-16 23:56, David Arnold wrote:
>> On 15 Jun 2024, at 00:18, Grant Taylor via TUHS <tuhs@tuhs.org> wrote:
>>
>> It's my understanding that systemd as a service lifecycle manager is starting to take on some aspects of what cluster service managers used to do.
> I think it goes beyond this, and that systemd is just a convenient focus point for folks to push back against a wider set of changes.

As an example of where I believe evolution is headed, I'd like to
talk about the Elephant in the Room.

Android.

It has a Linux, and thus Unix, heritage. The parts of it that still
depends on libc enjoys the quality of OpenBSD code, so it is blessed
by some unixy simplicity. Yet regular users are so far removed from
anything unix-like that it might as well be Multivac or the Mima.

That it still has a file manager of sorts that knows the typical
locations of downloads or photos is one of the last concessions
to us "I know it's a computer, let me use it as one" types.
By default, its apps are sandboxed and isolated in their own hives
with their code (main(), library dependencies, media resources)
and data presumably sealed off from the rest of the file system.
Every code component is of course duplicated in every app. Each
new version of Android seems to remove yet another aspect of its
Unix roots.

It didn't start there, though. Once upon a time, chroot() was
a popular way to reduce attack surface area in Linux as well as
elsewhere. You had to carefully populate it with just the
dependencies that were needed. Containers followed, automating
dependency provisioning. Android and its app ecosystem  is just
a logical continuation of that evolution.

Ubuntu has promoted "snaps," a kind of containerized applications
that pretty much walks and quacks just like an Android app.
Maybe it'sjust me being stupid trying to make things work with
e.g. a snap-based version of synergy for keyboard and mouse
sharing, but to me it seems that they typically don't see much
of your file system, not to talk about any comprehensive view
of your /dev.

Quite a few distros seems to be headed that way. I'm probably
both deluded as well as occluded in my reasoning, but I strongly
suspect that the last generation of actively interested computer
users where a majority understood processor memory models, I/O
and interrupts is now largely promoted out of harms way.
"Add another layer of abstractions so we don't need to care
about such bullshit" seems to be the new call to arms.

That dbus, systemd and Wayland isn't worse than they are is frankly
an amazing success given the circumstances they were born under.

-- 
Åke Nordin <ake.nordin@netia.se>, resident Net/Lunix/telecom geek.
Netia Data AB, Stockholm SWEDEN *46#7O466OI99#

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

[Alexis]

David Arnold <davida@pobox.com> writes:

> Users reasonably want things to work, and Red Hat wants to 
> satisfy
> those users, and they’ve chosen this way to do 
> it. Unfortunately,
> there’s been no real competition: this goes well beyond system
> startup, and well beyond service management, and citing s6 or 
> launchd
> or whatever misses the war by focusing on the battle.

Good point.

The problem that D-Bus attempts to solve is communication between 
components and applications designed for different desktop 
environments. i wasn't paying particular attention at the time, so 
i don't know what more Unix-y alternatives were proposed, if 
any. Laurent Bercot, the developer of s6[a], has created a 
bare-bones proof-of-concept alternative:

  https://skarnet.org/software/skabus/

but this hasn't been taken further, as his priorities have been 
elsewhere.

Wayland is an attempt to solve various issues and limitations of 
X. It's not a project by people who don't understand X; as an 
example, Matthieu Herbb, an Xorg dev and a primary OpenBSD dev in 
this area, did a presentation last year in which he said "X11 is 
fading away" and "Wayland is the way to go for graphical desktop":

  https://2023.eurobsdcon.org/slides/eurobsdcon2023-matthieu_herrb-wayland-openbsd.pdf

The problem is, people who aren't facing the issues and 
limitations faced by others are unlikely to have any motivation to 
work on, or support, the development of alternatives. This leaves 
the field of proposed solutions open to those with a different 
approach and/or a desire for résumé-driven development, regardless 
of the quality of the design and/or implementation. But even when 
the people working on alternatives are people who understand the 
problem space, those for whom the existing solution is perfectly 
adequate are unlikely to provide input regarding the development 
of those alternatives - so when a particular alternative gains 
sufficient momentum that those people are forced to start dealing 
with it, they might find it unusable for their use-case(s).

In other words, the war is pretty much lost at the outset, and 
people are left fighting battles that, in the medium-to-long term, 
are likely to turn out to be quixotic.


Alexis.

[a] i would say s6 is very much in the spirit of "the Unix 
philosophy": a suite small focused programs that can be combined 
in various ways, "mechanism not policy", and utilising fundamental 
Unix features. As Laurent writes at the end of the page about the 
s6 approach to 'socket activation', to which i linked upthread:

> You don't have to use specific libraries or write complex unit 
> files, you just need to understand how a command line 
> works. This is Unix.
-- https://skarnet.org/software/s6/socket-activation.html

Nevertheless, he's also noted, back in 2020, the real-world issues 
that have been an obstacle to s6's uptake:

> The fact is that a full-featured init system *is* a complex 
> beast, and the s6 stack does nothing more than is strictly 
> needed, but it exposes all the tools, all the entrails, all the 
> workings of the system, and that is a lot for non-specialists to 
> handle. Integrated init systems, such as systemd, are 
> significantly *more* complex than the s6 stack, but they do a 
> better job of *hiding* the complexity, and presenting a 
> relatively simple interface. That is why, despite being 
> technically inferior (on numerous metrics: bugs, length of code 
> paths, resource consumption, actual modularity, flexibility, 
> portability, etc.), they are more easily accepted: they are just 
> less intimidating.
>
> As a friend told me, and it was an enlightening moment: you are 
> keeping the individual parts simple, but in doing so, you are 
> moving the complexity to the *interactions* between the parts, 
> and are burdening the user with that complexity. You are keeping 
> the code simple, which has undeniable maintainability benefits, 
> but you are making the administration more difficult, and the 
> trade-off is not good enough for a lot of users. 

-- https://skarnet.org/lists/supervision/2586.html

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

[Michael Kjörling]

On 18 Jun 2024 15:55 +1000, from flexibeast@gmail.com (Alexis):
>> As a friend told me, and it was an enlightening moment: you are keeping
>> the individual parts simple, but in doing so, you are moving the
>> complexity to the *interactions* between the parts, and are burdening
>> the user with that complexity. You are keeping the code simple, which
>> has undeniable maintainability benefits, but you are making the
>> administration more difficult, and the trade-off is not good enough for
>> a lot of users.
> 
> -- https://skarnet.org/lists/supervision/2586.html

It used to be the case, not least before the widespread advent of
microcomputers (let's say between the late 1970s and mid-1980s), that
computing time was fairly expensive, and programmer time was fairly
cheap (both grossly relatively speaking). So it made sense to shift
the burden from the computer to the programmer where reasonable,
especially where the operation being automated would be performed many
times: the computer would need to do the work every time, whereas the
programmer only needed to do the corresponding work once.

Now computing time (as in the cost of completing a given operation;
say, adding two 64-bit integers, or storing a given number of bytes,
or even determining whether a given line of text appears in the output
of a command) is for all intents and purposes dirt cheap, while
programmer time is relatively expensive.

Hence programming-level abstractions which save programmer time, even
when those come at a performance cost.

The same argument can be made for memory cost.

It probably can also be made for system administrator time versus the
computing cost of making the sysadmin's job easier. It's also pretty
undeniably the case that there are many, many more sysadmins working
on many, many, many more systems than there are programmers working on
init systems and system state management services.

(Which is not to say that it those abstractions are only a good thing.
Hiding the complexity of what is actually going on opens up _its own_
set of pitfalls, both because it hides what's going on and because the
abstractions can only go so far; and all that performance cost does
eventually add up. If we wrote software for today's computers like we
wrote it for an early-1980s computer, it could probably be blazingly
fast; but could we reasonably write software at the level of today's
software complexity that way? The jury might not have arrived yet.)

-- 
Michael Kjörling                     🔗 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

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

[Alan D. Salewski]

On Thu, Jun 13, 2024, at 14:39, segaloco via TUHS wrote:
[...]
> Are there any known attempts in the modern age to roll Linux with 
> something resembling research/BSD init?  That would be a nice counter 
> to the proliferation of systemd.  Even if it doesn't make a dent in the 
> actual uptake, at least it'd feel cathartic to have an alternative in 
> the opposite direction.
>
> - Matt G.

I'm interested in hearing about other options in this space,
too. The ones that I'm aware of include:

    1. Slackware
       http://www.slackware.com/

    2. Debian, with sysvinit-core or some other init
       https://www.debian.org/doc/manuals/debian-faq/customizing.en.html#sysvinit
       https://wiki.debian.org/Init

    3. Devuan (for a Debian derived system w/o systemd)
       https://www.devuan.org/

The most no-fuss, just-works-out-of-the-box-without-systemd approach
would probably be to use Slackware.

Debian can be easily customized to run without systemd, once you
know the formulas[0].

I did not include Alpine Linux[1] in the above list because it
includes lots of tools in a single executable (possibly "init").[2]
It does not use systemd by default, though.

I mention Devuan only because I'm aware of it -- I've never used it
in anger.

-Al


[0] Even on a systemd-infected host, it isn't much more complicated
    than:
        * install the 'sysvinit-core' package (and friends)
        * pin the 'systemd-sysv' package to '-1' (never install)
        * reboot
        * purge most (or all) packages with 'systemd' in their name

[1] https://www.alpinelinux.org/about/

[2] It's great in certain circumstances, though -- it's my go-to
    distro base for most of my small-footprint-scenarios work with
    Linux containers.

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

[Clem Cole]

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

Except ...

My primary Linux instances are on my growing family of Raspberry PIs or
equiv (I have a couple of BananaPIs and Libre boards).  It's based enough
on Raspian which like Henry's line WRT 4.2, is just like Debian only
different.  Frankly, dealing with those issues when you leave the fold is a
huge PITA.  The problem for me, I really don't have a choice as I can not
run a *BSD on them easily to do what I want to do - which is typically to
control HW (like my PiDP's or a some "homecontrol" stuff I have).

As I have said, it all about economics (well and ego in this case).  You
have to make something better to make it valuable.  Replacing how the
system init worked always struck me as throwing out the baby with the
bathwater. SysV init was not at all bad, moving from Research/BSD init to
it was not a huge life.  That said, I agree with Dan, adding a resource
system is a good idea and probably was a "hole."  Years ago, the CMU  Mach
team created their nanny system, but it ran in cooperation with init - it
did not try to replace init (remember Mach was trying to be a superset of
BSD -- they had learned the lessons with Accent of being completely
different).  When Apple picked up Mach, their engineers eventually combined
them to create launchd - which is what I think opened up the world to
"getting rid of init" and thus systemd being considered possible by some
Linux folks.

Of course, the Linux developers could not settle for using launched (NIH)
.... so, sadly, https://xkcd.com/927/ applies here - that's the ego part.
ᐧ
ᐧ
ᐧ

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

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

[Bakul Shah via TUHS]

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

On Jun 13, 2024, at 1:05 PM, Clem Cole <clemc@ccc.com> wrote:
> 
> My primary Linux instances are on my growing family of Raspberry PIs or equiv (I have a couple of BananaPIs and Libre boards).  It's based enough on Raspian which like Henry's line WRT 4.2, is just like Debian only different.  Frankly, dealing with those issues when you leave the fold is a huge PITA.  The problem for me, I really don't have a choice as I can not run a *BSD on them easily to do what I want to do - which is typically to control HW (like my PiDP's or a some "homecontrol" stuff I have).

(at least) FreeBSD works on Pis (though support will usually lag or be non-existent for various "HATs"). And plan9 has worked for much longer, not to mention it's more flexible. Both have gpio drivers. Writing drivers for plan9 should be far easier.



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

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

[A. P. Garcia]

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

On Thu, Jun 13, 2024, 3:38 PM Alan D. Salewski <ads@salewski.email> wrote:

> On Thu, Jun 13, 2024, at 14:39, segaloco via TUHS wrote:
> [...]
> > Are there any known attempts in the modern age to roll Linux with
> > something resembling research/BSD init?
>


> I'm interested in hearing about other options in this space,
> too.
>

https://nosysyemd.org

>

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

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

[Jim Capp]

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

https://nosystemd.org/ 


From: "A. P. Garcia" <a.phillip.garcia@gmail.com> 
To: "Alan D. Salewski" <ads@salewski.email> 
Cc: "TUHS (The Unix Heritage Society)" <tuhs@tuhs.org> 
Sent: Thursday, June 13, 2024 4:06:39 PM 
Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • The Register 







On Thu, Jun 13, 2024, 3:38 PM Alan D. Salewski <ads@salewski.email> wrote: 


On Thu, Jun 13, 2024, at 14:39, segaloco via TUHS wrote: 
[...] 
> Are there any known attempts in the modern age to roll Linux with 
> something resembling research/BSD init? 







I'm interested in hearing about other options in this space, 
too. 



https://nosysyemd.org 




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

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

[Larry McVoy]

On Thu, Jun 13, 2024 at 04:06:39PM -0400, A. P. Garcia wrote:
> On Thu, Jun 13, 2024, 3:38???PM Alan D. Salewski <ads@salewski.email> wrote:
> 
> > On Thu, Jun 13, 2024, at 14:39, segaloco via TUHS wrote:
> > [...]
> > > Are there any known attempts in the modern age to roll Linux with
> > > something resembling research/BSD init?
> >
> 
> 
> > I'm interested in hearing about other options in this space,
> > too.
> >
> 
> https://nosysyemd.org

Doesn't resolve for me?
-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

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

[Alexis]

"Alan D. Salewski" <ads@salewski.email> writes:

> I'm interested in hearing about other options in this space,
> too.

i'm currently running Gentoo+OpenRC as my daily driver, with 
OpenRC an 'official' Gentoo option.

  https://www.gentoo.org/

Previously i was running Void+s6/66, after having been running 
Void+runit, with runit being Void's default system (at least at 
the time).

  https://voidlinux.org/

Artix is an Arch-based non-systemd distro, with support for 
OpenRC, runit, s6 and dinit.

  https://artixlinux.org/

Obarun is an Arch-based distro using 66, which is roughly a 
'wrapper' for s6, providing declarative syntax for service 
definition.

  https://wiki.obarun.org/

Not a distro, but the s6-overlay project allows using s6 as PID 1 
in Docker containers:

  https://github.com/just-containers/s6-overlay

The developer of nosh has a page outlining the know problems with 
Sys V rc:

  https://jdebp.uk/FGA/system-5-rc-problems.html

The developer of dinit has written a nice comparison of various 
non-systemd systems providing init / service supervision / service 
management:

  https://github.com/davmac314/dinit/blob/master/doc/COMPARISON

The developer of s6 has pages:

* explaining his perspective on various non-systemd systems:

  https://skarnet.org/software/s6/why.html

* providing a general overview of s6 itself:

  https://skarnet.org/software/s6/overview.html

* discussing s6's approach to 'socket activation', which uses file 
  descriptors:

  https://skarnet.org/software/s6/socket-activation.html

(s6 is the system i'm most familiar with in this space, not least 
because i'm the porter and maintainer of mdoc(7) versions of the 
documentation for various parts of the s6/skaware ecosystem.)


Alexis.

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

[Larry McVoy]

This is all well and good but what I, and I suspect other boomers like me,
are looking for, is something like Ubuntu without systemd.  I'm a xubuntu
guy (Ubuntu with a lighter weight desktop), but whatever.  Ubuntu is fine,
everything works there.

So is there an "Everything just works" distro without systemd?  A guy can
hope but I suspect not.

I'm not trying to be a pain in the ass but I'm 62, I prefer to spend my
effort on fishing on the ocean, I'm not some young guy that wants to
put in a ton of hours on my Linux install, I like Linux because it is
Unix and it is trivial to install.  Windows?  Hours and hours of finding
drivers after you find some USB network connector that Windows knows?
No thanks.  *BSD - have you installed one of those?  It's a trip back
to the 1980s, those installers are fine for BSD developers but just suck
compared to Linux.  Mainstream Linux just works.

On Fri, Jun 14, 2024 at 10:27:29AM +1000, Alexis wrote:
> "Alan D. Salewski" <ads@salewski.email> writes:
> 
> >I'm interested in hearing about other options in this space,
> >too.
> 
> i'm currently running Gentoo+OpenRC as my daily driver, with OpenRC an
> 'official' Gentoo option.
> 
>  https://www.gentoo.org/
> 
> Previously i was running Void+s6/66, after having been running Void+runit,
> with runit being Void's default system (at least at the time).
> 
>  https://voidlinux.org/
> 
> Artix is an Arch-based non-systemd distro, with support for OpenRC, runit,
> s6 and dinit.
> 
>  https://artixlinux.org/
> 
> Obarun is an Arch-based distro using 66, which is roughly a 'wrapper' for
> s6, providing declarative syntax for service definition.
> 
>  https://wiki.obarun.org/
> 
> Not a distro, but the s6-overlay project allows using s6 as PID 1 in Docker
> containers:
> 
>  https://github.com/just-containers/s6-overlay
> 
> The developer of nosh has a page outlining the know problems with Sys V rc:
> 
>  https://jdebp.uk/FGA/system-5-rc-problems.html
> 
> The developer of dinit has written a nice comparison of various non-systemd
> systems providing init / service supervision / service management:
> 
>  https://github.com/davmac314/dinit/blob/master/doc/COMPARISON
> 
> The developer of s6 has pages:
> 
> * explaining his perspective on various non-systemd systems:
> 
>  https://skarnet.org/software/s6/why.html
> 
> * providing a general overview of s6 itself:
> 
>  https://skarnet.org/software/s6/overview.html
> 
> * discussing s6's approach to 'socket activation', which uses file
> descriptors:
> 
>  https://skarnet.org/software/s6/socket-activation.html
> 
> (s6 is the system i'm most familiar with in this space, not least because
> i'm the porter and maintainer of mdoc(7) versions of the documentation for
> various parts of the s6/skaware ecosystem.)
> 
> 
> Alexis.

-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

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

[Luther Johnson]

I believe there is a Debian package you can install after installing
Debian that reverts to sysvinit, removes systemd. There is also a
configuration that leaves systemd in place but lets you use the sysvinit
scripts and forget (well for most people, most uses) that systemd is
there. I have the latter style of installation on my server, but I was
thinking of going the full no-systemd route sometime.

On 06/13/2024 05:59 PM, Larry McVoy wrote:
> This is all well and good but what I, and I suspect other boomers like me,
> are looking for, is something like Ubuntu without systemd.  I'm a xubuntu
> guy (Ubuntu with a lighter weight desktop), but whatever.  Ubuntu is fine,
> everything works there.
>
> So is there an "Everything just works" distro without systemd?  A guy can
> hope but I suspect not.
>
> I'm not trying to be a pain in the ass but I'm 62, I prefer to spend my
> effort on fishing on the ocean, I'm not some young guy that wants to
> put in a ton of hours on my Linux install, I like Linux because it is
> Unix and it is trivial to install.  Windows?  Hours and hours of finding
> drivers after you find some USB network connector that Windows knows?
> No thanks.  *BSD - have you installed one of those?  It's a trip back
> to the 1980s, those installers are fine for BSD developers but just suck
> compared to Linux.  Mainstream Linux just works.
>
> On Fri, Jun 14, 2024 at 10:27:29AM +1000, Alexis wrote:
>> "Alan D. Salewski" <ads@salewski.email> writes:
>>
>>> I'm interested in hearing about other options in this space,
>>> too.
>> i'm currently running Gentoo+OpenRC as my daily driver, with OpenRC an
>> 'official' Gentoo option.
>>
>>   https://www.gentoo.org/
>>
>> Previously i was running Void+s6/66, after having been running Void+runit,
>> with runit being Void's default system (at least at the time).
>>
>>   https://voidlinux.org/
>>
>> Artix is an Arch-based non-systemd distro, with support for OpenRC, runit,
>> s6 and dinit.
>>
>>   https://artixlinux.org/
>>
>> Obarun is an Arch-based distro using 66, which is roughly a 'wrapper' for
>> s6, providing declarative syntax for service definition.
>>
>>   https://wiki.obarun.org/
>>
>> Not a distro, but the s6-overlay project allows using s6 as PID 1 in Docker
>> containers:
>>
>>   https://github.com/just-containers/s6-overlay
>>
>> The developer of nosh has a page outlining the know problems with Sys V rc:
>>
>>   https://jdebp.uk/FGA/system-5-rc-problems.html
>>
>> The developer of dinit has written a nice comparison of various non-systemd
>> systems providing init / service supervision / service management:
>>
>>   https://github.com/davmac314/dinit/blob/master/doc/COMPARISON
>>
>> The developer of s6 has pages:
>>
>> * explaining his perspective on various non-systemd systems:
>>
>>   https://skarnet.org/software/s6/why.html
>>
>> * providing a general overview of s6 itself:
>>
>>   https://skarnet.org/software/s6/overview.html
>>
>> * discussing s6's approach to 'socket activation', which uses file
>> descriptors:
>>
>>   https://skarnet.org/software/s6/socket-activation.html
>>
>> (s6 is the system i'm most familiar with in this space, not least because
>> i'm the porter and maintainer of mdoc(7) versions of the documentation for
>> various parts of the s6/skaware ecosystem.)
>>
>>
>> Alexis.

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

[Alexis]

Larry McVoy <lm@mcvoy.com> writes:

> This is all well and good but what I, and I suspect other 
> boomers like me,
> are looking for, is something like Ubuntu without systemd.  I'm 
> a xubuntu
> guy (Ubuntu with a lighter weight desktop), but whatever. 
> Ubuntu is fine,
> everything works there.
>
> So is there an "Everything just works" distro without systemd? 
> A guy can
> hope but I suspect not.

Mm, well, i guess that depends on what one's "everything" is. i 
used Ubuntu years ago - having moved from Mandriva - and was 
pleased by how everything "just worked". But over time i started 
experiencing various issues where things _didn't_ just work (i 
can't remember what now; i think printing might have been one 
thing), which became increasingly frustrating. So i moved to 
Debian, and had a much more "just works" experience. But then 
Debian moved to systemd, and i started getting frustrated again in 
various ways, and so i moved to Void.

Void's a binary distro, and i don't recall having any more issues 
with it than i ended up having with Ubuntu. And for experienced 
*n*x users, the installation process is trivial (even if the 
installer is text-based, rather than involving snazzy graphics).

> I'm not trying to be a pain in the ass but I'm 62, I prefer to 
> spend my
> effort on fishing on the ocean, I'm not some young guy that 
> wants to
> put in a ton of hours on my Linux install

Fwiw, i'm a 50-year-old woman. :-) My first distro was RedHat 5.2, 
around the end of '97.

To me, this is a "bubbles in wallpaper" thing. i've spent the time 
setting up Gentoo because i'm now at the point where i'm clear on 
what i do and don't need/want (in general), and i'm trying to 
minimise the extent to which i'm beholden to having to deal with 
breaking changes to subsystems / libraries / software that i don't 
need/want, or with breakages i don't know how to immediately fix 
or workaround. Because i have _many_ other life commitments 
myself, and i've never distro-hopped just for the fun of it; i've 
always been driven to do so, for various reasons. My distro is 
merely a means to an end, not the end in itself.

(i've taken on s6 documentation stuff because although there's no 
shortage of people wanting alternatives to systemd, there are far 
fewer people volunteering to do even small amounts of the work 
necessary for that.)


Alexis.

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

[ron minnich]

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

well, it depends on what you want, but tinycorelinux has worked well for
me, and it fits in about 24M

On Thu, Jun 13, 2024 at 6:42 PM Alexis <flexibeast@gmail.com> wrote:

> Larry McVoy <lm@mcvoy.com> writes:
>
> > This is all well and good but what I, and I suspect other
> > boomers like me,
> > are looking for, is something like Ubuntu without systemd.  I'm
> > a xubuntu
> > guy (Ubuntu with a lighter weight desktop), but whatever.
> > Ubuntu is fine,
> > everything works there.
> >
> > So is there an "Everything just works" distro without systemd?
> > A guy can
> > hope but I suspect not.
>
> Mm, well, i guess that depends on what one's "everything" is. i
> used Ubuntu years ago - having moved from Mandriva - and was
> pleased by how everything "just worked". But over time i started
> experiencing various issues where things _didn't_ just work (i
> can't remember what now; i think printing might have been one
> thing), which became increasingly frustrating. So i moved to
> Debian, and had a much more "just works" experience. But then
> Debian moved to systemd, and i started getting frustrated again in
> various ways, and so i moved to Void.
>
> Void's a binary distro, and i don't recall having any more issues
> with it than i ended up having with Ubuntu. And for experienced
> *n*x users, the installation process is trivial (even if the
> installer is text-based, rather than involving snazzy graphics).
>
> > I'm not trying to be a pain in the ass but I'm 62, I prefer to
> > spend my
> > effort on fishing on the ocean, I'm not some young guy that
> > wants to
> > put in a ton of hours on my Linux install
>
> Fwiw, i'm a 50-year-old woman. :-) My first distro was RedHat 5.2,
> around the end of '97.
>
> To me, this is a "bubbles in wallpaper" thing. i've spent the time
> setting up Gentoo because i'm now at the point where i'm clear on
> what i do and don't need/want (in general), and i'm trying to
> minimise the extent to which i'm beholden to having to deal with
> breaking changes to subsystems / libraries / software that i don't
> need/want, or with breakages i don't know how to immediately fix
> or workaround. Because i have _many_ other life commitments
> myself, and i've never distro-hopped just for the fun of it; i've
> always been driven to do so, for various reasons. My distro is
> merely a means to an end, not the end in itself.
>
> (i've taken on s6 documentation stuff because although there's no
> shortage of people wanting alternatives to systemd, there are far
> fewer people volunteering to do even small amounts of the work
> necessary for that.)
>
>
> Alexis.
>

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

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

[Angel M Alganza]

On 2024-06-14 03:42, Alexis wrote:

> Mm, well, i guess that depends on what one's "everything" is. i used 
> Ubuntu years ago - having moved from Mandriva - and was pleased by how 
> everything "just worked". But over time i started experiencing various 
> issues where things _didn't_ just work (i can't remember what now; i 
> think printing might have been one thing), which became increasingly 
> frustrating. So i moved to Debian, and had a much more "just works" 
> experience. But then Debian moved to systemd, and i started getting 
> frustrated again in various ways, and so i moved to Void.

I used Debian for 27 years, until ascii (the last release without the 
nasty systemd), which I upgraded to Devuan ascii.  The upgrade process 
was flawless with everything working without problems for me (I don't 
use disgusting DEs like Gnome or KDE, of course).

In several systems, I've kept upgrading release after release of Devuan, 
changing every part of the hardware in the way, and it keeps working 
great.

In the BSDs, I much prefer the more classic text installers, where I'm 
in control, but NomadBSD and GhostBSD have graphical installers which 
seem to be much simpler and easier to use than the Ubuntu one.

Cheers,
Ángel

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

[Dave Horsfall]

On Thu, 13 Jun 2024, Larry McVoy wrote:

> This is all well and good but what I, and I suspect other boomers like 
> me, are looking for, is something like Ubuntu without systemd.  I'm a 
> xubuntu guy (Ubuntu with a lighter weight desktop), but whatever.  
> Ubuntu is fine, everything works there.

I'm looking for something like Debian for its Amateur radio ("ham") stuff 
for a laptop, but without the "systemd" monstrosity; I've seen a reference 
to "Devuan" (?) which might suit me.

> So is there an "Everything just works" distro without systemd?  A guy 
> can hope but I suspect not.

Hopefully...

> I'm not trying to be a pain in the ass but I'm 62, I prefer to spend my 
> effort on fishing on the ocean, I'm not some young guy that wants to put 
> in a ton of hours on my Linux install, I like Linux because it is Unix 
> and it is trivial to install.  Windows?  Hours and hours of finding 
> drivers after you find some USB network connector that Windows knows? No 
> thanks.  *BSD - have you installed one of those?  It's a trip back to 
> the 1980s, those installers are fine for BSD developers but just suck 
> compared to Linux.  Mainstream Linux just works.

Only 62?  I turn 72 in a few months :-)  And I *don't* like Linux 
precisely because it is *not* Unix (too many irritating differences), but 
I need something for the aforesaid lapdog (with some proprietary hardware, 
but 3rd-party drivers exist).  As for *BSD, yes, many times; I started 
with SunOS, used OpenBSD/NetBSD/FreeBSD (the latter is my current server), 
and I really don't see any problem.  Heck, even my Mac runs FreeBSD 
(albeit on steroids)...

I have to say though that the SunOS graphical installer was beautiful :-)

-- Dave

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

[arnold]

I'm with Larry on this one. I'm 64, I been running Ubuntu Mate for ~8
years or so, and even though it's systemd, and yeah, systemd IS an
abomination, I don't care enough to go looking for something else. I
still have $DAYJOB, kids living at home, Free Software to maintain,
books to write, etc., etc., etc.

https://wiki.ubuntu.com/SystemdForUpstartUsers#Permanent_switch_back_to_upstart
looks like it might do the trick, but it also looks like it's a little
old, and I don't want to brick my production systems.

I may try to spin up a VM and see if the instructions work before
doing it for real.

Arnold

Larry McVoy <lm@mcvoy.com> wrote:

> This is all well and good but what I, and I suspect other boomers like me,
> are looking for, is something like Ubuntu without systemd.  I'm a xubuntu
> guy (Ubuntu with a lighter weight desktop), but whatever.  Ubuntu is fine,
> everything works there.
>
> So is there an "Everything just works" distro without systemd?  A guy can
> hope but I suspect not.
>
> I'm not trying to be a pain in the ass but I'm 62, I prefer to spend my
> effort on fishing on the ocean, I'm not some young guy that wants to
> put in a ton of hours on my Linux install, I like Linux because it is
> Unix and it is trivial to install.  Windows?  Hours and hours of finding
> drivers after you find some USB network connector that Windows knows?
> No thanks.  *BSD - have you installed one of those?  It's a trip back
> to the 1980s, those installers are fine for BSD developers but just suck
> compared to Linux.  Mainstream Linux just works.

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

[Andy Kosela]

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

On Friday, June 14, 2024, Larry McVoy <lm@mcvoy.com> wrote:

> This is all well and good but what I, and I suspect other boomers like me,
> are looking for, is something like Ubuntu without systemd.  I'm a xubuntu
> guy (Ubuntu with a lighter weight desktop), but whatever.  Ubuntu is fine,
> everything works there.
>
> So is there an "Everything just works" distro without systemd?  A guy can
> hope but I suspect not.
>
> I'm not trying to be a pain in the ass but I'm 62, I prefer to spend my
> effort on fishing on the ocean, I'm not some young guy that wants to
> put in a ton of hours on my Linux install, I like Linux because it is
> Unix and it is trivial to install.  Windows?  Hours and hours of finding
> drivers after you find some USB network connector that Windows knows?
> No thanks.  *BSD - have you installed one of those?  It's a trip back
> to the 1980s, those installers are fine for BSD developers but just suck
> compared to Linux.  Mainstream Linux just works.
>

Larry, in that case I think you will be best with sticking to Xubuntu or
Debian. These distros just work. And although I am also from anti-systemd
camp after years of using systemd in production environments -- pretty much
it has been a standard since rhel 7 -- I conclude that systemd is not the
end of the world like some purported back in the days. Mostly it just works
too.

Switching to some esoteric distro maintained by a couple of university
students that will most likely disappear in three years is probably not the
best option. Debian is stable and been there from the beginning. All the
packages are also there just one simple command away.

These days I am also not that interested in kernel development anymore or
debugging low level stuff. It was fun when Linux or FreeBSD kernels were
much smaller and less complex.

I am mostly into retro computing and retro games these days; still playing
and enjoying old classics like "The Secret of Monkey Island" from LucasArts
on period correct hardware.

For daily tasks I am using Macbook which also just works and have a
terminal, so I can run my stuff from there. I can control my k8s clusters
from the terminal. I am still mostly CLI oriented. Command line will always
remain the most elegant and beautiful interface to speak with machines.

--Andy

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

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

[Dave Horsfall]

On Fri, 14 Jun 2024, Andy Kosela wrote:

> For daily tasks I am using Macbook which also just works and have a 
> terminal, so I can run my stuff from there. I can control my k8s 
> clusters from the terminal. I am still mostly CLI oriented. Command line 
> will always remain the most elegant and beautiful interface to speak 
> with machines.

What he said...

-- Dave

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

[Vincenzo Nicosia]

On Thu, Jun 13, 2024 at 05:59:02PM -0700, Larry McVoy wrote:
> This is all well and good but what I, and I suspect other boomers like me,
> are looking for, is something like Ubuntu without systemd.  I'm a xubuntu
> guy (Ubuntu with a lighter weight desktop), but whatever.  Ubuntu is fine,
> everything works there.
> 
> So is there an "Everything just works" distro without systemd?  A guy can
> hope but I suspect not.

TL;DR:
Devuan (https://devuan.org) works more or less fine as a daily drive,
both as a desktop and on servers, and it gives choice of sysvinit,
runit, openrc, and lately also s6 I believe (but I haven't tried it). If
you need something that "kinda works" without systemd, well, Devuan is
still "kinda usable", and possibly one of the best options around. 



Personal rant follows. You are not expected to read this ;P

Linux is probably broken beyond repair now, and I am saying that with a
heavy heart, having used exlusively Linux and all the other *BSD in the
last 26 years, and having advocated its adoption strongly, in different
environments. In many ways, Linux is not unix, not any more, to any
sensible measure, and since a good while ago. 

These days Linux can only provide a somehow-lightly-unixy-flavoured
system that "kinda works", provided that you do things as the distro
decided, and do not look under the hood, ever. I personally believe
Linux was at its top around 10-12 years ago, even in terms of how well
everything worked in it and how easy it still was to do things your own
way, if you wanted to do so. It was still simple enough, yet it provided
a full-featured computing experience, from desktops to high-end servers.

Nowadays if you decide to use Linux you must accept that far too many
things "do happen" to your computer, and neither you nor anybody else
knows why they do, or why they shouldn't, or how to alter their
behavious or avoid them altogether. There is so much complexity
everywhere that there is almost no space left for KISS, anywhere. Linux
has eaten itself alive plus a whole bunch of additional bloat, many
times, recursively.


I have already moved all the servers away of Linux in the last 6-7
years, and I am currently in the last phase of moving my desktops away
from it as well. It's a sad farewell, but a necessary one. You can't be
totally fed up and keep carrying on for long, can you? :)

My2Cents

Enzo

-- 

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

[Dave Horsfall]

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

On Thu, 13 Jun 2024, Arrigo Triulzi via TUHS wrote:

> Binary logs, ’nuff said.

Ugh...

> Good sysadmins live & die by grep and being able to visually detect 
> departures from the norm by just looking at the “shape” of logs 
> scrolling down a screen (before), terminal window now.

Which is exactly what I do: one window with "tail -F /var/log/maillog" and 
another with "tail -F /var/log/httpd-access.log"; I've spotted lots of 
attacks that way (followed by a quick update to my firewall).

-- Dave

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

[Michael Kjörling]

On 14 Jun 2024 06:26 +1000, from dave@horsfall.org (Dave Horsfall):
>> Good sysadmins live & die by grep and being able to visually detect 
>> departures from the norm by just looking at the “shape” of logs 
>> scrolling down a screen (before), terminal window now.
> 
> Which is exactly what I do: one window with "tail -F /var/log/maillog" and 
> another with "tail -F /var/log/httpd-access.log"; I've spotted lots of 
> attacks that way (followed by a quick update to my firewall).

journalctl -f -u 'postfix*'

or

journalctl -f -u 'exim*'

or

journalctl -f -u 'smtpd'

or whatever else might map to the SMTP server software you're running.
(Sure, it gets slightly more complicated if you don't know what SMTP
server software is in use, but in that case I think a case can be made
for why do you even care about its logs?)

To filter, one can either add -g 'pcre-expression'; or pipe the output
through grep -P for the same effect. Or you can use something like
--output=json (or -o json) and pipe the output of that through, say, jq.

And I'm pretty sure most web servers still log to text files in
typical configurations, so that plain "tail -F" should still work there.

Is systemd perfect? Of course not. I have my gripes with it myself,
but not enough to actively fight it. And nobody is _forcing_ anyone to
use systemd; plenty of examples have already been posted in this
thread, from specially-made Linux distribution derivatives to ones
that have opted to not include systemd to *BSDs to links to
instructions for how to get rid of systemd from more mainstream Linux
distributions that have opted to use it as a default.

Also, the subjectular headline from The Register seems like something
someone has dreamed up; I certainly don't see anything like that in
the actual release announcement at
<https://github.com/systemd/systemd/releases/tag/v256>. Also using
multiple different search engines to try to find it only brought up
the _The Register_ article and a handful of places regurgitating that
quote as a real representation of a statement from the systemd
maintainers. I don't see anything resembling it anywhere on either
systemd.io or github.com. Until I see someone posting a link to
something like that quote posted by a systemd maintainer in
representation of _any_ systemd release, let alone v256, I'm going to
treat that one as hearsay at best, and actively malicious at worst.

As much as I can appreciate the architectural simplicity of early
UNIX, how about not ignoring the fact that today's systems are quite a
bit more complex both at the hardware and the software level than they
were in the late 1960s, and that to some extent, this complexity
_itself_ (unfortunately) drives complexity in other areas. Also that
much of that simplicity was also out of necessity. There's a reason
why most software these days isn't written directly in assembler or
even C. None of which negates the accomplishments of either UNIX or C.

-- 
Michael Kjörling                     🔗 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

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

[A. P. Garcia]

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

On Fri, Jun 14, 2024, 7:42 AM Michael Kjörling <e5655f30a07f@ewoof.net>
wrote

Also, the subjectular headline from The Register seems like something
> someone has dreamed up; I certainly don't see anything like that in
> the actual release announcement at
> <https://github.com/systemd/systemd/releases/tag/v256>. Also using
> multiple different search engines to try to find it only brought up
> the _The Register_ article and a handful of places regurgitating that
> quote as a real representation of a statement from the systemd
> maintainers. I don't see anything resembling it anywhere on either
> systemd.io or github.com. Until I see someone posting a link to
> something like that quote posted by a systemd maintainer in
> representation of _any_ systemd release, let alone v256, I'm going to
> treat that one as hearsay at best, and actively malicious at worst.
>

https://fosstodon.org/@bluca/112600235561688561

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

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

[Arrigo Triulzi via TUHS]

From Mastodon (https://mastodon.social/@nixCraft/112637213238431183):


>FYI, there is a bug in systemd. So, running: "systemd-tmpfiles --purge" will delete your /home/ in systemd version 256.

and Twitter (https://x.com/DevuanOrg/status/1802997574695080067).

Could be Debian-specific but…

Arrigo

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

[Dave Horsfall]

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

On Fri, 14 Jun 2024, Michael Kjörling wrote:

[...]

> journalctl -f -u 'smtpd'
> 
> or whatever else might map to the SMTP server software you're running. 
> (Sure, it gets slightly more complicated if you don't know what SMTP 
> server software is in use, but in that case I think a case can be made 
> for why do you even care about its logs?)

My server runs Sendmail, and I have no idea what "journalctl" is (it 
sounds Penguin-ish, which I definitely don't run).  And I care so that I 
can firewall the buggers on the spot...

-- Dave

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

[Alexis]

Dave Horsfall <dave@horsfall.org> writes:

> My server runs Sendmail, and I have no idea what "journalctl" is 
> (it 
> sounds Penguin-ish, which I definitely don't run).

It's systemd's program for accessing the binary logs it 
generates. So, yes, it's Penguin, in the sense that systemd is 
explicitly not supported on anything other than Linux.


Alexis.

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

[Theodore Ts'o]

On Sun, Jun 23, 2024 at 11:47:52AM +1000, Alexis wrote:
> Dave Horsfall <dave@horsfall.org> writes:
> 
> > My server runs Sendmail, and I have no idea what "journalctl" is (it
> > sounds Penguin-ish, which I definitely don't run).
> 
> It's systemd's program for accessing the binary logs it generates. So, yes,
> it's Penguin, in the sense that systemd is explicitly not supported on
> anything other than Linux.

Systemd certainly isn't a pioneer in terms of binary log files.  The
first such "innovation" that I can think of is Ultrix's (and later
OSF/1 and Tru64)'s uerf (Ultrix error report formatter).  AIX also had
binary error logs that needed to be decoded using the errpt command.
And Solaris's audit logs are also stored in a binary format.

All of these "innovations" consider it a Feature that it becomes
easier to store and filter on structured data, instead of trying to
write complex regex's to pull out events that match some particular
query.

						- Ted

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

[Alexander Schreiber]

On Sun, Jun 23, 2024 at 03:00:02PM -0400, Theodore Ts'o wrote:
> On Sun, Jun 23, 2024 at 11:47:52AM +1000, Alexis wrote:
> > Dave Horsfall <dave@horsfall.org> writes:
> > 
> > > My server runs Sendmail, and I have no idea what "journalctl" is (it
> > > sounds Penguin-ish, which I definitely don't run).
> > 
> > It's systemd's program for accessing the binary logs it generates. So, yes,
> > it's Penguin, in the sense that systemd is explicitly not supported on
> > anything other than Linux.
> 
> Systemd certainly isn't a pioneer in terms of binary log files.  The
> first such "innovation" that I can think of is Ultrix's (and later
> OSF/1 and Tru64)'s uerf (Ultrix error report formatter).  AIX also had
> binary error logs that needed to be decoded using the errpt command.
> And Solaris's audit logs are also stored in a binary format.

AIX sort of gets a pass here on account of being on the weird side
to begin with and bonus points for not using DB/2 for primary log
storage ;-)
 
> All of these "innovations" consider it a Feature that it becomes
> easier to store and filter on structured data, instead of trying to
> write complex regex's to pull out events that match some particular
> query.

Except you now have to do the additional step of extracting the
data from the binary logs and _then_ apply the regex filter you
were going to use in the first place, which makes the logs less
accessible. All of my systemd running machines still get rsyslog
plugged into it so it can deliver the logs to my central log host
(which then dumps them into PostgreSQL) - and to enable a quick
rummage in the local logs via less & grep.

Kind regards,
           Alex.
-- 
"Opportunity is missed by most people because it is dressed in overalls and
 looks like work."                                      -- Thomas A. Edison

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

[Theodore Ts'o]

On Sun, Jun 23, 2024 at 10:04:22PM +0200, Alexander Schreiber wrote:
> Except you now have to do the additional step of extracting the
> data from the binary logs and _then_ apply the regex filter you
> were going to use in the first place, which makes the logs less
> accessible. All of my systemd running machines still get rsyslog
> plugged into it so it can deliver the logs to my central log host
> (which then dumps them into PostgreSQL) - and to enable a quick
> rummage in the local logs via less & grep.

Well, no, not necessarily.  You *could* just query the structured data
directly, which avoids needing to do complex, and error-prone parsing
of the data using complex (and potentially easy to fool regex's).  If
this is being done to trigger automation to handle certain exception
conditions, this could potentially be a security vulnerability if the
attacker could use /usr/ucb/logger to insert arbitrary text into the
system logs which could then potentially fool the regex parser (in the
worst case, if there things aren't properly escaped when handling the
parsed text, there might be a Bobby Tables style attack[1]).

[1] https://xkcd.com/327/

Now, you could say that there could be two separate events
notification; one which is sent via the old-fashioned text-based
syslog system, and a different one which is structured which is better
suited for large-scale automation.

So for example, at $WORK we *used* to grovel through the system logs
looking for file system corruption reports which were sent to the
console logs.  But we've since added an fsnotify schema to the
upstream Linux kernel which sends a structured event notification
which isn't nearly as error-prone, and which doens't require parsing
to fetch the device name, etc.  We didn't remove the old-style "print
to the console log" for backwards compatibility reasons, however, so
this didn't break people who were used to parse the console log by
hand.  Linux kernel developers are a lot more about backwards
compatibility than some userspace projects (including, unfortunately,
systemd).

However, this dysfunction isn't limited to Linux userspace.
Unfortunately, in the case of (I think, but I'll Digital folks correct
me if I'm wrong) Digital's uerf and AIX's unspeakable horror ("AIX ---
it *reminds* you of Unix"), backwards compatibility wasn't considered
as important by the Product Managers who make these sorts of
decisions.

Back in the Linux-land, for a while, a number of distributions had
rsyslog installed in parallel to the systemd logging system precisely
to provide that backwards compatibility.  A stable release later,
because this meant logging data was being written twice to stable
storage, rsyslog has been made no longer the default for some
distributions, but of course, you can just install rsyslog by hand if
you still want to use it.

The bottom line is that while people seem to be ranting and raving
about systemd --- and there are a lot of things that are terrible
about systemd, don't get me wrong --- I find it interesting that
legacy Unix systems get viewed with kind of a rosy-eyed set of glasses
in the past, when in fact, the "good old days" weren't necessary all
that good --- and there *are* reasons why some engineers have
considered plain text ala the 1970's Unix philosophy to not
necessarily be the final word in systems design.

Cheers,

					- Ted

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

[Dan Cross]

On Mon, Jun 24, 2024 at 9:51 AM Theodore Ts'o <tytso@mit.edu> wrote:
>[snip]
>
> The bottom line is that while people seem to be ranting and raving
> about systemd --- and there are a lot of things that are terrible
> about systemd, don't get me wrong --- I find it interesting that
> legacy Unix systems get viewed with kind of a rosy-eyed set of glasses
> in the past, when in fact, the "good old days" weren't necessary all
> that good --- and there *are* reasons why some engineers have
> considered plain text ala the 1970's Unix philosophy to not
> necessarily be the final word in systems design.

I must concur here. To bring this back to history, I think it's useful
to consider the context in which, "use text, as it's a universal
interchange format" arose. We _are_ talking about the 1970s here,
where there was a lot more variation between computers than nowadays;
back in that era, you still had a lot of word-oriented machines with
non-power-of-2 word sizes, one's complement machines, and the world
had not yet coalesced around the 8-bit byte (much of networking is
_still_ defined in terms of "octets" because of this). In that era,
yeah, it was just easier to move text between programs: transporting a
program from a 16-bit machine to a 32-bit machine didn't mean changing
parsing routines, for example.

Contrast this to today, where things are much more homogenized, even
between different ISAs. Most ISAs are little endian, and for general
purpose machines 8 bit bytes, power-of-two integer widths, and 2's
complement are pretty much universal (I'm aware that there are some
embedded and special purpose processors --- like some types of DSPs
--- for which this is not true. But I'm not trying to run Unix on
those). Furthermore, we have robust serialization formats that allow
us to move binary data between dissimilar machines in a well-defined
manner; things like XDR -- dating back almost 40 years now -- paved
the way for Protobuf and all the rest of them. In this environment,
the argument for "text first!" isn't as strong as it was in the 70s.

Something that I think also gets lost here is that we also have
well-defined, text-based serialization formats for structured data.
Things like sexprs, JSON, have all been employed to good effect here.
You can have your textual cake and eat your structured data, too!

I think what irks people more is that the traditional, line-oriented
tools we all know and love are no longer prioritized. But to me that's
an invitation to ask "why?" The default assumption seems to be that
the people who don't are just ignorant, or worse, stupid. But could it
be that they have actual, real-world problems that are not well served
by those tools?

So it is with systemd. I don't like it, and the recent, "deletes your
homedir lol you're holding it wrong lmao" thing solidifies that
opinion, but in some ways it's actually _more_ Unix-y than some of the
alternatives. Take smf, where nothing screams "UNIX!!!" at me more
than XML-based config files consumed by giant libraries. Systemd, at
least, is broken into a bunch of little programs that each do one
thing (sorta...) well, and it uses somewhat-readable text-based
configuration files and symlinks.

Indeed, we look at what we consider "real Unix" with some very rosy
glasses. Perhaps that's why we overlook un-Unix-like functionality
like Solaris's "profile" facilities, where the kernel does an upcall
to a userspace daemon to determine what privileges a program should
have? Or how about the IP management daemon, in.ndpd, or the rest of
the libipadm.so stuff?

Unix hasn't been Unix for a very long time now.

        - Dan C.

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

[Kevin Bowling]

On Mon, Jun 24, 2024 at 7:22 AM Dan Cross <crossd@gmail.com> wrote:
>
> On Mon, Jun 24, 2024 at 9:51 AM Theodore Ts'o <tytso@mit.edu> wrote:
> >[snip]
> >
> > The bottom line is that while people seem to be ranting and raving
> > about systemd --- and there are a lot of things that are terrible
> > about systemd, don't get me wrong --- I find it interesting that
> > legacy Unix systems get viewed with kind of a rosy-eyed set of glasses
> > in the past, when in fact, the "good old days" weren't necessary all
> > that good --- and there *are* reasons why some engineers have
> > considered plain text ala the 1970's Unix philosophy to not
> > necessarily be the final word in systems design.
>
> I must concur here. To bring this back to history, I think it's useful
> to consider the context in which, "use text, as it's a universal
> interchange format" arose. We _are_ talking about the 1970s here,
> where there was a lot more variation between computers than nowadays;
> back in that era, you still had a lot of word-oriented machines with
> non-power-of-2 word sizes, one's complement machines, and the world
> had not yet coalesced around the 8-bit byte (much of networking is
> _still_ defined in terms of "octets" because of this). In that era,
> yeah, it was just easier to move text between programs: transporting a
> program from a 16-bit machine to a 32-bit machine didn't mean changing
> parsing routines, for example.
>
> Contrast this to today, where things are much more homogenized, even
> between different ISAs. Most ISAs are little endian, and for general
> purpose machines 8 bit bytes, power-of-two integer widths, and 2's
> complement are pretty much universal (I'm aware that there are some
> embedded and special purpose processors --- like some types of DSPs
> --- for which this is not true. But I'm not trying to run Unix on
> those). Furthermore, we have robust serialization formats that allow
> us to move binary data between dissimilar machines in a well-defined
> manner; things like XDR -- dating back almost 40 years now -- paved
> the way for Protobuf and all the rest of them. In this environment,
> the argument for "text first!" isn't as strong as it was in the 70s.
>
> Something that I think also gets lost here is that we also have
> well-defined, text-based serialization formats for structured data.
> Things like sexprs, JSON, have all been employed to good effect here.
> You can have your textual cake and eat your structured data, too!
>
> I think what irks people more is that the traditional, line-oriented
> tools we all know and love are no longer prioritized. But to me that's
> an invitation to ask "why?" The default assumption seems to be that
> the people who don't are just ignorant, or worse, stupid. But could it
> be that they have actual, real-world problems that are not well served
> by those tools?
>
> So it is with systemd. I don't like it, and the recent, "deletes your
> homedir lol you're holding it wrong lmao" thing solidifies that
> opinion, but in some ways it's actually _more_ Unix-y than some of the
> alternatives. Take smf, where nothing screams "UNIX!!!" at me more
> than XML-based config files consumed by giant libraries. Systemd, at
> least, is broken into a bunch of little programs that each do one
> thing (sorta...) well, and it uses somewhat-readable text-based
> configuration files and symlinks.
>
> Indeed, we look at what we consider "real Unix" with some very rosy
> glasses. Perhaps that's why we overlook un-Unix-like functionality
> like Solaris's "profile" facilities, where the kernel does an upcall
> to a userspace daemon to determine what privileges a program should
> have? Or how about the IP management daemon, in.ndpd, or the rest of
> the libipadm.so stuff?
>
> Unix hasn't been Unix for a very long time now.

Apologies if that is too much into the personal taste direction but
using Solaris as an exemplar of anything UNIX is not far removed from
the common opinions of AIX on this list.. It is an awkward culmination
of a lot of money, great multi-faceted marketing spanning several
megacorporations, and from the time of enthusiastic overuse of the
word "enterprise".

Larry and others have described the financial situation that led to
Solaris.  It was a launch salvo of SVR4.. and SVRn had a lot of
expansion(&regression?) in ideology as well as some unfortunate
technicalities that have some relevance to the success of NT
(especially) and Linux than most historians recount.  Knowing that, I
find it understandable when people fondly remember Solaris because it
was cool, had a nice complement of hardware, software, and training
but a little stretched if put on a pedestal.  The thing that put Sun
on the map was SunOS, and that exemplified UNIX.  It is always fun to
"what if" Larry's SourceWare.

>
>         - Dan C.

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

[Steffen Nurpmeso]

Theodore Ts'o wrote in
 <20240624135049.GA280025@mit.edu>:
 |On Sun, Jun 23, 2024 at 10:04:22PM +0200, Alexander Schreiber wrote:
 |> Except you now have to do the additional step of extracting the
 |> data from the binary logs and _then_ apply the regex filter you
 |> were going to use in the first place, which makes the logs less
 |> accessible. All of my systemd running machines still get rsyslog
 |> plugged into it so it can deliver the logs to my central log host
 |> (which then dumps them into PostgreSQL) - and to enable a quick
 |> rummage in the local logs via less & grep.
 |
 |Well, no, not necessarily.  You *could* just query the structured data
 |directly, which avoids needing to do complex, and error-prone parsing
 |of the data using complex (and potentially easy to fool regex's).  If
 ...
 |console logs.  But we've since added an fsnotify schema to the
 |upstream Linux kernel which sends a structured event notification
 |which isn't nearly as error-prone, and which doens't require parsing
 |to fetch the device name, etc.  We didn't remove the old-style "print
 ...
 |The bottom line is that while people seem to be ranting and raving
 |about systemd --- and there are a lot of things that are terrible
 |about systemd, don't get me wrong --- I find it interesting that
 |legacy Unix systems get viewed with kind of a rosy-eyed set of glasses
 |in the past, when in fact, the "good old days" weren't necessary all
 |that good --- and there *are* reasons why some engineers have
 |considered plain text ala the 1970's Unix philosophy to not
 |necessarily be the final word in systems design.

But that is the thing, and it has nothing to do with systemd vs
a normal syslog.  I always wondered why things like fail2ban are
used to make active system decisions, including active firewall
setup, where daemons which *know* (to their extend) a state
transform it to string data, send it to syslog (or files), which
then gets parsed again.  Christos Zoulas of NetBSD then came over
with blacklistd about a decade ago, with patches for OpenSSH and
postfix and some more, where at least authentication (failure)
events are collected at the core where they happen, and then sent
to the blacklistd, which has backends for certain firewalls.  The
newest OpenSSH has something internal built-in that does not
report the event, as far as i know.
All those do not help against nonsense connections, like premature
forced breaks, or ditto with hanging on the port until the server
(or OS even) closes the connection, TLS setup failures,
downloading the same file a thousand times, etc etc.

A pity it is.  The server knows, the firewall or a controller
needs to know.  All that deep inspection shit of the past, and all
the guessing on connection count, interpolating connectivity
bandwidth, and what not, "done in the firewall", blind flight.
Noone jumped on that train that blacklistd started, even when
asked for such possibilities.

Sorry, i do not see why a binary "journal" log is any better than
a plain text file except that possibly programs can be addressed
more easily ... by their name.

Btw i hope for that new capability-for-namespaces thing that lwn
reported, that would be cool!  (Btw with 6.1.93 i could not
"cryptsetup close" unmounted mediums that were mounted before
kvm driven virtual machines moved to inside cgroup namespaces
were started.  Off-topic, of course.)

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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

[Noel Chiappa]

    > From: Clem Cole

    > Frankly my major complaint with much of the modern world is that when we
    > ignore the past

"There are two kinds of fools. One says, 'This is old, therefore it is good';
the other says, 'This is new, therefore it is better.'"  -- Dean Inge, quoted
by John Brunner in "The Shockwave Rider".

   Noel

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

[Clem Cole]

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

Exactly

Sent from a handheld expect more typos than usual


On Sun, Jun 16, 2024 at 8:48 PM Noel Chiappa <jnc@mercury.lcs.mit.edu>
wrote:

>     > From: Clem Cole
>
>     > Frankly my major complaint with much of the modern world is that
> when we
>     > ignore the past
>
> "There are two kinds of fools. One says, 'This is old, therefore it is
> good';
> the other says, 'This is new, therefore it is better.'"  -- Dean Inge,
> quoted
> by John Brunner in "The Shockwave Rider".
>
>    Noel
>
>

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

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

[Larry McVoy]

On Sun, Jun 16, 2024 at 08:48:16PM -0400, Noel Chiappa wrote:
>     > From: Clem Cole
> 
>     > Frankly my major complaint with much of the modern world is that when we
>     > ignore the past
> 
> "There are two kinds of fools. One says, 'This is old, therefore it is good';
> the other says, 'This is new, therefore it is better.'"  -- Dean Inge, quoted
> by John Brunner in "The Shockwave Rider".

"Want to be a hero in the computer science world?  Find a good paper from
5 or 10 years ago and rewrite it.  Everyone will think you're a genius"

	-- Ron Minnich

I paraphrased, Ron, feel free to correct me.
-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

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

[ron minnich]

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

yeah, I was on a rant that day, it actually made it into the plan 9 fortunes
'You want to make your way in the CS field? Simple. Calculate rough time of
amnesia (hell, 10 years is plenty, probably 10 months is plenty), go to the
dusty archives, dig out something fun, and go for it.   It's worked for
many people, and it can work for you.  - Ron Minnich
'
I'm sorry to say, it still seems to work that way.

I just saw a talk from red hat about putting linux in flash to use as a
boot loader, for example, and the authors somehow ignored the last 25 years
and acted like they invented it. Amazing. Turns out 10 minutes is enough.

On Sun, Jun 16, 2024 at 6:05 PM Larry McVoy <lm@mcvoy.com> wrote:

> On Sun, Jun 16, 2024 at 08:48:16PM -0400, Noel Chiappa wrote:
> >     > From: Clem Cole
> >
> >     > Frankly my major complaint with much of the modern world is that
> when we
> >     > ignore the past
> >
> > "There are two kinds of fools. One says, 'This is old, therefore it is
> good';
> > the other says, 'This is new, therefore it is better.'"  -- Dean Inge,
> quoted
> > by John Brunner in "The Shockwave Rider".
>
> "Want to be a hero in the computer science world?  Find a good paper from
> 5 or 10 years ago and rewrite it.  Everyone will think you're a genius"
>
>         -- Ron Minnich
>
> I paraphrased, Ron, feel free to correct me.
> --
> ---
> Larry McVoy           Retired to fishing
> http://www.mcvoy.com/lm/boat
>

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

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

[ron minnich]

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

I'm curious, as to the original topic of this discussion: can anyone
justify systemd-homed and how it works? Does that even look like 0% of a
unix idea?

On Sun, Jun 16, 2024 at 8:56 PM ron minnich <rminnich@gmail.com> wrote:

> yeah, I was on a rant that day, it actually made it into the plan 9
> fortunes
> 'You want to make your way in the CS field? Simple. Calculate rough time
> of amnesia (hell, 10 years is plenty, probably 10 months is plenty), go to
> the dusty archives, dig out something fun, and go for it.   It's worked for
> many people, and it can work for you.  - Ron Minnich
> '
> I'm sorry to say, it still seems to work that way.
>
> I just saw a talk from red hat about putting linux in flash to use as a
> boot loader, for example, and the authors somehow ignored the last 25 years
> and acted like they invented it. Amazing. Turns out 10 minutes is enough.
>
> On Sun, Jun 16, 2024 at 6:05 PM Larry McVoy <lm@mcvoy.com> wrote:
>
>> On Sun, Jun 16, 2024 at 08:48:16PM -0400, Noel Chiappa wrote:
>> >     > From: Clem Cole
>> >
>> >     > Frankly my major complaint with much of the modern world is that
>> when we
>> >     > ignore the past
>> >
>> > "There are two kinds of fools. One says, 'This is old, therefore it is
>> good';
>> > the other says, 'This is new, therefore it is better.'"  -- Dean Inge,
>> quoted
>> > by John Brunner in "The Shockwave Rider".
>>
>> "Want to be a hero in the computer science world?  Find a good paper from
>> 5 or 10 years ago and rewrite it.  Everyone will think you're a genius"
>>
>>         -- Ron Minnich
>>
>> I paraphrased, Ron, feel free to correct me.
>> --
>> ---
>> Larry McVoy           Retired to fishing
>> http://www.mcvoy.com/lm/boat
>>
>

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

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

[Bakul Shah via TUHS]

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

On Jun 16, 2024, at 8:57 PM, ron minnich <rminnich@gmail.com> wrote:
> 
> I'm curious, as to the original topic of this discussion: can anyone justify systemd-homed and how it works? Does that even look like 0% of a unix idea?


I am not a fan of systemd (or linux) and don't follow their excesses/adventures but I am not a fan of how BSD does initialization & brings up services either. They don't quite get all the dependencies right for all the possible combinations of devices etc.  Its /etc/rc.d/* system is pretty clunky -- I tend to think any time you are repeating more or less the same boilerplate code in many files, something worth abstracting is hiding in there.

I like how launchd  treats a service as an object (more than just a program but also the auxiliary files and scripts). For me it was a lightbulb moment (like realizing how a function operates in an environment!). Though I'd probably use s-expr or a simpler config format, not xml (as in launchd plist/SMF manifest).

At the other extreme of complexity we have things like Kubernetes. Not a fan.

What I want is to be able to map all my computers and compute clusters into a single virtual machine -- where storage, IO and computing resources may be added / removed without taking the whole VM down, and where each display/input user interface is a window on the same underlying VM and all sharing is under my control. Plan9 does a bit of this but that experiment ended too early. Apple is tending in this direction though not cleanly (+ I don't want to rely on a faceless behemoth corp that may trample on my data without even meaning to).

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

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

[Bakul Shah via TUHS]

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

On Jun 16, 2024, at 10:41 PM, Bakul Shah <bakul@iitbombay.org> wrote:
> 
> On Jun 16, 2024, at 8:57 PM, ron minnich <rminnich@gmail.com> wrote:
>> 
>> I'm curious, as to the original topic of this discussion: can anyone justify systemd-homed and how it works? Does that even look like 0% of a unix idea?
> 
> 
> I am not a fan of systemd (or linux) and don't follow their excesses/adventures but I am not a fan of how BSD does initialization & brings up services either. They don't quite get all the dependencies right for all the possible combinations of devices etc.  Its /etc/rc.d/* system is pretty clunky -- I tend to think any time you are repeating more or less the same boilerplate code in many files, something worth abstracting is hiding in there.
> 
> I like how launchd  treats a service as an object (more than just a program but also the auxiliary files and scripts). For me it was a lightbulb moment (like realizing how a function operates in an environment!). Though I'd probably use s-expr or a simpler config format, not xml (as in launchd plist/SMF manifest).
> 
> At the other extreme of complexity we have things like Kubernetes. Not a fan.
> 
> What I want is to be able to map all my computers and compute clusters into a single virtual machine -- where storage, IO and computing resources may be added / removed without taking the whole VM down, and where each display/input user interface is a window on the same underlying VM and all sharing is under my control. Plan9 does a bit of this but that experiment ended too early. Apple is tending in this direction though not cleanly (+ I don't want to rely on a faceless behemoth corp that may trample on my data without even meaning to).

Forgot to mention LOCUS, which was the only distributed Unix compatible OS I am aware of. To anyone who has user/implementer experience, I would love to hear what worked well, what didn't, what was easy to implement, what was very hard and what you wished was added to it.


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

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

[Clem Cole]

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

On Mon, Jun 17, 2024 at 1:51 AM Bakul Shah via TUHS <tuhs@tuhs.org> wrote:

> Forgot to mention LOCUS, which was the only distributed Unix compatible OS
> I am aware of. To anyone who has user/implementer experience, I would love
> to hear what worked well, what didn't, what was easy to implement, what was
> very hard and what you wished was added to it.
>
Jerry and Bruce's book is the complete reference:
https://www.amazon.com/Distributed-System-Architecture-Computer-Systems/dp/0262161028

There were basically 3/4 versions...  the original version of the PDP 11
which is the SOSP paper, which morphed to include a VAX at UCLA; IBM's
AIX/370 and AIX/PS2 which included TCF (Transparent Computing Facility),
and LCC's TNC Transparent Networking Computing "product" which were the 14
core technologies used to built it.  Part of them landed in other systems
from Tru64, HPUX, the Paragon and even a later a Linux implementation
(which sadly was done on the V2  kernel so was lost when Linus did not
understand it).

What worked well was different flavors of the DFS and the later core idea
of the VPROCS layer which I sorely miss, which allowed process migration -
which w worked well and boy did I miss later in my career.  Admin of a
Locus based system was a dream because it was just one system for up to
4096 nodes in a Paragon.   It also means you could migrate processes off a
node, take the node down, reboot/change and bring it back. Very cool.
After the first system was installed, adding a node was trivial, by the
way.  You booted the node, "joined" the cluster, and were up. AIX used file
replication to then build the local disks as needed.    BTW:
"checkpointing" was a freebie -- you just migrated the file to a disk.

Mixing ISA like the 370 and PS/2  was a mixed bag -- I'll let Charlie
comment.   With TNC we redid that model a bit, I'm not sure we ever got it
100% right.  The HP-UX version was probably the best.

The biggest implementation issue is that UNIX has too many different
namespaces with all sorts of rules that are particular to each.  For all of
the concept of "everything is a file," - when you start to try to bring it
together, you discover new and werid^H^H^H^H^Hintersting name spaces from
System V IPC to signals to FIFOs and Name Pipes (similar but different).
It seemed like everything we looked, we would find another NS we needed to
handle, and when we started to try to look at non-UNIX process layers, it
got even stranger.  The original UNIX protection model is a tad weak, but
most people had started to add ACLs, and POSIX was in the throughs of
standardizing them -- so we based it on an early POSIX proposal (mostly
based on HP-UX since they had them before the others did).

To be more specific, the virtual process layer (VPROC) attempted to do what
VFS had done for the FS layer to the core kernel.   If you look at both the
original 2 Locus schemes, process control was ad hoc and thus very messy.
 LCC realized if we were going to succeed, we needed to make that cleaner.
But that still took major surgery - although, like the CFS layer, things
were a lot clearer once done.   Bruce, Roman, and I came up with VPROCs.
BTW: one of the cool parts of VPROC is like VFS. It conceptually made it
possible to have other process models. We did a prototype for OS/2 running
inside of the OSF uK and were trying to get a contract from DEC to do it to
Tru64 and adding VMS before we got sold (we had already developed CFS for
DEC as part of Tru64 - which TNC's Cluster File System). Truth is, cheap
VMs killed the need for this idea, but it worked fairly well.

After the core VPROCs layer, the hardest thing was distributed
shared memory (DSM) and the distributed lock manager (DLM).   DSM was an
example that offered pure transparency in operation, *i.e.,* test and set
worked (operationally) correctly across the DSM, but it was not "speed
transparent."  But if you rewrote to use DLM, then you could get full
transparency and speed.  The DLM is one of the TNC technology which lives
on today.  It ended up in a number of systems - Oracle wrote their own
based on the specs for the DEC DLM we built for the CFS for Tru64 (which is
from TNC). I believe a few other folks used it.  It was in OSF's DCE, and
ISTR Microsoft picked it up.

So a good question is if TNC was so cool, why did Beowulf (a real hack in
comparison) stick around and TNC die?   Well, a few things.  LCC/HP did not
open-source the code until it was too late.  So Beowulf, which was around,
was what folks (like me) used to build big scientific clusters. And while
Popek was "right," -- it takes something like Locus/TNC to make a cluster
fully transparent.  Beowulf ignored the seams and i the end, that was "good
enough."   But it makes setup and admin a PITA, and the program needs to be
careful -- the dragons are all over the place. So, when I went to Intel, I
was the Architect of Cluster Ready, which defined away many of those seams
and then provided tools to test for them and help you admin.

Tools like the Cluster Checker and the whole ClusterReady program would not
be needed if TNC had "stuck," and I think clusters, in general, a cluster
of small computers on a LAN, not just clusters on a high-speed/special
interconnect like a supercomputer, would be more available today.


Clem

ᐧ

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

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

[Clem Cole]

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

typo...  like the VFS layer (not CFS layer)
ᐧ

On Mon, Jun 17, 2024 at 11:56 AM Clem Cole <clemc@ccc.com> wrote:

>
>
> On Mon, Jun 17, 2024 at 1:51 AM Bakul Shah via TUHS <tuhs@tuhs.org> wrote:
>
>> Forgot to mention LOCUS, which was the only distributed Unix compatible
>> OS I am aware of. To anyone who has user/implementer experience, I would
>> love to hear what worked well, what didn't, what was easy to implement,
>> what was very hard and what you wished was added to it.
>>
> Jerry and Bruce's book is the complete reference:
> https://www.amazon.com/Distributed-System-Architecture-Computer-Systems/dp/0262161028
>
> There were basically 3/4 versions...  the original version of the PDP 11
> which is the SOSP paper, which morphed to include a VAX at UCLA; IBM's
> AIX/370 and AIX/PS2 which included TCF (Transparent Computing Facility),
> and LCC's TNC Transparent Networking Computing "product" which were the 14
> core technologies used to built it.  Part of them landed in other systems
> from Tru64, HPUX, the Paragon and even a later a Linux implementation
> (which sadly was done on the V2  kernel so was lost when Linus did not
> understand it).
>
> What worked well was different flavors of the DFS and the later core idea
> of the VPROCS layer which I sorely miss, which allowed process migration -
> which w worked well and boy did I miss later in my career.  Admin of a
> Locus based system was a dream because it was just one system for up to
> 4096 nodes in a Paragon.   It also means you could migrate processes off a
> node, take the node down, reboot/change and bring it back. Very cool.
> After the first system was installed, adding a node was trivial, by the
> way.  You booted the node, "joined" the cluster, and were up. AIX used file
> replication to then build the local disks as needed.    BTW:
> "checkpointing" was a freebie -- you just migrated the file to a disk.
>
> Mixing ISA like the 370 and PS/2  was a mixed bag -- I'll let Charlie
> comment.   With TNC we redid that model a bit, I'm not sure we ever got it
> 100% right.  The HP-UX version was probably the best.
>
> The biggest implementation issue is that UNIX has too many different
> namespaces with all sorts of rules that are particular to each.  For all of
> the concept of "everything is a file," - when you start to try to bring it
> together, you discover new and werid^H^H^H^H^Hintersting name spaces from
> System V IPC to signals to FIFOs and Name Pipes (similar but different).
> It seemed like everything we looked, we would find another NS we needed to
> handle, and when we started to try to look at non-UNIX process layers, it
> got even stranger.  The original UNIX protection model is a tad weak, but
> most people had started to add ACLs, and POSIX was in the throughs of
> standardizing them -- so we based it on an early POSIX proposal (mostly
> based on HP-UX since they had them before the others did).
>
> To be more specific, the virtual process layer (VPROC) attempted to do
> what VFS had done for the FS layer to the core kernel.   If you look at
> both the original 2 Locus schemes, process control was ad hoc and thus very
> messy.   LCC realized if we were going to succeed, we needed to make that
> cleaner.  But that still took major surgery - although, like the CFS layer,
> things were a lot clearer once done.   Bruce, Roman, and I came up with
> VPROCs.  BTW: one of the cool parts of VPROC is like VFS. It conceptually
> made it possible to have other process models. We did a prototype for OS/2
> running inside of the OSF uK and were trying to get a contract from DEC to
> do it to Tru64 and adding VMS before we got sold (we had already developed
> CFS for DEC as part of Tru64 - which TNC's Cluster File System). Truth is,
> cheap VMs killed the need for this idea, but it worked fairly well.
>
> After the core VPROCs layer, the hardest thing was distributed
> shared memory (DSM) and the distributed lock manager (DLM).   DSM was an
> example that offered pure transparency in operation, *i.e.,* test and set
> worked (operationally) correctly across the DSM, but it was not "speed
> transparent."  But if you rewrote to use DLM, then you could get full
> transparency and speed.  The DLM is one of the TNC technology which lives
> on today.  It ended up in a number of systems - Oracle wrote their own
> based on the specs for the DEC DLM we built for the CFS for Tru64 (which is
> from TNC). I believe a few other folks used it.  It was in OSF's DCE, and
> ISTR Microsoft picked it up.
>
> So a good question is if TNC was so cool, why did Beowulf (a real hack in
> comparison) stick around and TNC die?   Well, a few things.  LCC/HP did not
> open-source the code until it was too late.  So Beowulf, which was around,
> was what folks (like me) used to build big scientific clusters. And while
> Popek was "right," -- it takes something like Locus/TNC to make a cluster
> fully transparent.  Beowulf ignored the seams and i the end, that was "good
> enough."   But it makes setup and admin a PITA, and the program needs to be
> careful -- the dragons are all over the place. So, when I went to Intel, I
> was the Architect of Cluster Ready, which defined away many of those seams
> and then provided tools to test for them and help you admin.
>
> Tools like the Cluster Checker and the whole ClusterReady program would
> not be needed if TNC had "stuck," and I think clusters, in general, a
> cluster of small computers on a LAN, not just clusters on a
> high-speed/special interconnect like a supercomputer, would be more
> available today.
>
>
> Clem
>
> ᐧ
>

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

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

[Charles H Sauer (he/him)]

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

Clem suggests I comment on mixing ISA. I'm not sure how to respond. I 
saw Bruce and Jerry demo process migration many times, particularly 
during our dramatic Santa Monica meetings in October 1987, coincident 
with the Whittier earthquake. However, I never got a chance to work with 
this myself. (During the strongest aftershocks, Bruce and I would just 
stare and hold on to our chairs. Having us Austin IBM folks in Santa 
Monica to try to resolve the Austin/LCC disagreements seemed historic, 
but probably not the cause of the October 19 Wall Street crash.)

In general, I was always impressed by what Bruce and Jerry did, but the 
assertions that LCC could do everything exacerbated the ongoing 
political challenges within IBM. To repeat from 
https://notes.technologists.com/notes/2017/03/08/lets-start-at-the-very-beginning-801-romp-rtpc-aix-versions/: 

o "The former LCC person has mentioned that IBM then seemed like N 
competing companies. Actually, it was more like M<sub>n</sub> competing 
factions within N competing companies."
o "The traditional product organizations, e.g., those associated with 
the 370 and the System 3x, saw little need for UNIX or a new hardware 
architecture. The renegade but surprisingly successful PC organizations 
looked askance for their own reasons. Even the Yorktown partners were 
partly detrimental because of disdain for UNIX." [To amplify on this, in 
1984 CEO John Akers told a gathering of Austin IBM managers that he 
questioned the need for RISC processors and UNIX.]
o "Besides our technical concerns about distributed system issues, the 
implicit question seemed an all or nothing proposition of continuing AIX 
vs. IBM depending on LCC for UNIX."

And we could dwell on OSF, DCE, etc. On the day OSF was announced, with 
Akers on stage with Ken Olsen, Akers flew across the country to an 
awards event, where Glenn Henry, Larry Loucks and I received substantial 
checks in recognition of AIX. When Akers shook my hand, he told me how 
proud he was of what had happened that day.

When I saw the Register article, I knew that systemd folks hadn't 
boasted '42% less Unix philosophy', that it was really someone on 
mas.to, but I felt like stirring up discussion. Seems to have worked...

Charlie

On 6/17/2024 11:00 AM, Clem Cole wrote:
> typo...  like the VFS layer (not CFS layer)
> ᐧ
>
> On Mon, Jun 17, 2024 at 11:56 AM Clem Cole <clemc@ccc.com> wrote:
>
>
>
>     On Mon, Jun 17, 2024 at 1:51 AM Bakul Shah via TUHS
>     <tuhs@tuhs.org> wrote:
>
>         Forgot to mention LOCUS, which was the only distributed Unix
>         compatible OS I am aware of. To anyone who has
>         user/implementer experience, I would love to hear what worked
>         well, what didn't, what was easy to implement, what was very
>         hard and what you wished was added to it.
>
>     Jerry and Bruce's book is the complete reference:
>     https://www.amazon.com/Distributed-System-Architecture-Computer-Systems/dp/0262161028
>
>     There were basically 3/4 versions...  the original version of the
>     PDP 11 which is the SOSP paper, which morphed to include a VAX at
>     UCLA; IBM's AIX/370 and AIX/PS2 which included TCF (Transparent
>     Computing Facility), and LCC's TNC Transparent Networking
>     Computing "product" which were the 14 core technologies used to
>     built it.  Part of them landed in other systems from Tru64, HPUX,
>     the Paragon and even a later a Linux implementation (which sadly
>     was done on the V2  kernel so was lost when Linus did not
>     understand it).
>
>     What worked well was different flavors of the DFS and the later
>     core idea of the VPROCS layer which I sorely miss, which allowed
>     process migration - which w worked well and boy did I miss later
>     in my career.  Admin of a Locus based system was a dream because
>     it was just one system for up to 4096 nodes in a Paragon.   It
>     also means you could migrate processes off a node, take the node
>     down, reboot/change and bring it back. Very cool.  After the first
>     system was installed, adding a node was trivial, by the way.  You
>     booted the node, "joined" the cluster, and were up. AIX used file
>     replication to then build the local disks as needed.   BTW:
>     "checkpointing" was a freebie -- you just migrated the file to a disk.
>
>     Mixing ISA like the 370 and PS/2  was a mixed bag -- I'll let
>     Charlie comment.   With TNC we redid that model a bit, I'm not
>     sure we ever got it 100% right.  The HP-UX version was probably
>     the best.
>
>     The biggest implementation issue is that UNIX has too many
>     different namespaces with all sorts of rules that are particular
>     to each.  For all of the concept of "everything is a file," - when
>     you start to try to bring it together, you discover new and
>     werid^H^H^H^H^Hintersting name spaces from System V IPC to signals
>     to FIFOs and Name Pipes (similar but different).  It seemed like
>     everything we looked, we would find another NS we needed to
>     handle, and when we started to try to look at non-UNIX process
>     layers, it got even stranger.  The original UNIX protection model
>     is a tad weak, but most people had started to add ACLs, and POSIX
>     was in the throughs of standardizing them -- so we based it on an
>     early POSIX proposal (mostly based on HP-UX since they had them
>     before the others did).
>
>     To be more specific, the virtual process layer (VPROC) attempted
>     to do what VFS had done for the FS layer to the core kernel.   If
>     you look at both the original 2 Locus schemes, process control was
>     ad hoc and thus very messy.   LCC realized if we were going to
>     succeed, we needed to make that cleaner.  But that still took
>     major surgery - although, like the CFS layer, things were a lot
>     clearer once done.   Bruce, Roman, and I came up with VPROCs. 
>     BTW: one of the cool parts of VPROC is like VFS. It conceptually
>     made it possible to have other process models. We did a prototype
>     for OS/2 running inside of the OSF uK and were trying to get a
>     contract from DEC to do it to Tru64 and adding VMS before we got
>     sold (we had already developed CFS for DEC as part of Tru64 -
>     which TNC's Cluster File System). Truth is, cheap VMs killed the
>     need for this idea, but it worked fairly well.
>
>     After the core VPROCs layer, the hardest thing was distributed
>     shared memory (DSM) and the distributed lock manager (DLM).   DSM
>     was an example that offered pure transparency in operation,
>     /i.e.,/ test and set worked (operationally) correctly across the
>     DSM, but it was not "speed transparent."  But if you rewrote to
>     use DLM, then you could get full transparency and speed.  The DLM
>     is one of the TNC technology which lives on today.  It ended up in
>     a number of systems - Oracle wrote their own based on the specs
>     for the DEC DLM we built for the CFS for Tru64 (which is from
>     TNC). I believe a few other folks used it.  It was in OSF's DCE,
>     and ISTR Microsoft picked it up.
>
>     So a good question is if TNC was so cool, why did Beowulf (a real
>     hack in comparison) stick around and TNC die?  Well, a few
>     things.  LCC/HP did not open-source the code until it was too
>     late.  So Beowulf, which was around, was what folks (like me) used
>     to build big scientific clusters. And while Popek was "right," --
>     it takes something like Locus/TNC to make a cluster fully
>     transparent.  Beowulf ignored the seams and i the end, that was
>     "good enough."   But it makes setup and admin a PITA, and the
>     program needs to be careful -- the dragons are all over the
>     place. So, when I went to Intel, I was the Architect of Cluster
>     Ready, which defined away many of those seams and then provided
>     tools to test for them and help you admin.
>
>     Tools like the Cluster Checker and the whole ClusterReady program
>     would not be needed if TNC had "stuck," and I think clusters, in
>     general, a cluster of small computers on a LAN, not just clusters
>     on a high-speed/special interconnect like a supercomputer, would
>     be more available today.
>
>
>     Clem
>
>     ᐧ
>
-- 
voice: +1.512.784.7526       e-mail:sauer@technologists.com
fax: +1.512.346.5240         Web:https://technologists.com/sauer/
Facebook/Google/LinkedIn/Twitter: CharlesHSauer

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

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

[Larry McVoy]

On Mon, Jun 17, 2024 at 11:56:55AM -0400, Clem Cole wrote:
> What worked well was different flavors of the DFS and the later core idea
> of the VPROCS layer which I sorely miss, which allowed process migration -
> which w worked well and boy did I miss later in my career.  Admin of a
> Locus based system was a dream because it was just one system for up to
> 4096 nodes in a Paragon.   It also means you could migrate processes off a
> node, take the node down, reboot/change and bring it back. Very cool.
> After the first system was installed, adding a node was trivial, by the
> way.  You booted the node, "joined" the cluster, and were up. 

I'm so bummed this didn't make it in the market place.  I dreamed up my
own version of this, very similar, actually started BitMover to build
this but got side tracked onto BitKeeper to help Linus.

What I wanted, and sadly never got, was nodes that were small SMP
machines.  Maybe 4 way.  And a tricked up C that had simplistic 
objects built in, locks would be automatic for the most part so
when you accessed VOP_OPEN() the lock was taken automatically.

Yes, I know that won't scale but that's fine.  Scale it as far as
it can go, which is not far, and then cluster those SMP machines
to get further scaling.  

The vision was to maintain a simplistic OS, not the monstrosity that
Linux has become.  

For most people, a simplistic SMP OS would work fine.  Then introduce
the clustering to go from 4 way to 4096 way.

I gave a bunch of talks on it, I was pushing for it in the early 1990's.
I gave the talk to some VP at SGI and they promptly hired me.  Never 
got anywhere while I was there but I believe they did something like
that after I left.

Woulda, coulda, shoulda.

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

[Steffen Nurpmeso]

Bakul Shah via TUHS wrote in
 <653E15D7-DD66-414C-94F3-A74B4EE3DD10@iitbombay.org>:
 |On Jun 16, 2024, at 8:57 PM, ron minnich <rminnich@gmail.com> wrote:
 |> I'm curious, as to the original topic of this discussion: can anyone \
 |> justify systemd-homed and how it works? Does that even look like \
 |> 0% of a unix idea?
 |
 |I am not a fan of systemd (or linux) and don't follow their excesses/adv\
 |entures but I am not a fan of how BSD does initialization & brings \
 |up services either. They don't quite get all the dependencies right \
 |for all the possible combinations of devices etc.  Its /etc/rc.d/* \
 |system is pretty clunky -- I tend to think any time you are repeating \

Now even more since they started to add a "jail-this-service"
variable, ie containerization by setting a variable.

 |more or less the same boilerplate code in many files, something worth \
 |abstracting is hiding in there.
 |
 |I like how launchd  treats a service as an object (more than just a \
 |program but also the auxiliary files and scripts). For me it was a \
 |lightbulb moment (like realizing how a function operates in an environme\

To me -- it turned off my light as i tried to "do something", but
could not figure out how; i somehow managed to create the XML file
necessary.  I am happy to have forgotten what it was about.  Ah,
wait, voila:

  $ v ~/arena/misc/macosx-plist-use.txt
  
  <?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
  <plist version="1.0">
  <dict>
          <key>Label</key>
          <string>com.bell-labs.plan9.u9fs</string>
          <key>Program</key>
          <string>/usr/bin/u9fs</string>
          <key>ProgramArguments</key>
          <array>
                  <string>u9fs</string>
                  <string>-l</string>
                  <string>/var/log/u9fs.log</string>
                  <string>-a</string>
                  <string>p9any</string>
                  <string>/opt/plan9</string>
          </array>
          <key>Sockets</key>
          <dict>
                  <key>Listeners</key>
                  <dict>
                          <key>SockServiceName</key>
                          <string>9pfs</string>
                  </dict>
          </dict>
          <key>inetdCompatibility</key>
          <dict>
                  <key>Wait</key>
                  <false/>
          </dict>
  </dict>
  </plist>
  
   To cause this to be run on system start, this should be
   installed as /Library/LaunchDaemons/9pfs.plist. Installing
   instead in /Library/LaunchAgents will cause it to be run only
   when a user is logged in, while $HOME/Library/LaunchAgents will
   cause it to be run only when that particular user is logged in.
  
   In order to start the listner it must first be ``loaded''
  $ sudo launchctrl load /path/to/9pfs.plist
  
   If you are running the Mac OS X firewall you will need to add
   an entry pass the 9pfs protocol in:
  SystemPreferences->Sharing->Firewall

I give you ten points for configuration lightbulb moments!
So nice and easy, also for human consumption once written.

  ...
 |What I want is to be able to map all my computers and compute clusters \
 |into a single virtual machine -- where storage, IO and computing resources \
 |may be added / removed without taking the whole VM down, and where \
 |each display/input user interface is a window on the same underlying \
 |VM and all sharing is under my control. Plan9 does a bit of this but \
 |that experiment ended too early. Apple is tending in this direction \
 |though not cleanly (+ I don't want to rely on a faceless behemoth corp \
 |that may trample on my data without even meaning to).

I had that dream somewhen spoken out in a FreeBSD IRC channel
a few years back.  It *could* be that the new per-service-jails do
it a bit like that, via nullfs mounting, that deep i have not
looked into it yet.
But my idea was that the base system is mounted partially, and you
would specify the PKGs you want in the jail, and that only the
files of the given pkgs are actually visible in the jail.

I use something a bit similar for some boxed things here on Linux,
with overlayfs; however, after

    mount -n -t overlay -o upperdir=${rundir}/storage,lowerdir=/,workdir=${rundir}/work \
            overlayfs ${rundir}/root || exit 21

i then start rm(1) removal of some files, eg

    rm -rf \
            ${rundir}/root/boot \
            ${rundir}/root/home \
            ${rundir}/root/media \
            ${rundir}/root/opt \
            ${rundir}/root/root \
            ${rundir}/root/run \
            ${rundir}/root/var \

plus over-mounting things like dev

    # devtmpfs fully populates instead, including log socket etc!!
    #mount -n -t devtmpfs dev ${rundir}/root/dev || exit 50
    mount -n -t tmpfs -o nosuid,noexec dev ${rundir}/root/dev || exit 50

etc etc etc.  That is *not* what i meant.
That idea is old, i have not yet managed it to create a shareable
root system, which is then *per-se* overlay mounted, even by the
system itself.  (That is: the base is shared by the base system
and containers, which then add onto what they want and need.  It
could even be mounted as a base for real VMs.)

Regarding systemd my only hope is that Linux remains usable
without it.  It seems more and more require the systemd
infrastructure in order to function, i have heard.
That "super / sudo / doas / [BSD] su -c" replacement that systemd
just recently added, somehow i followed a link to the github or so
issue where this was discussed, and i still hear the lead
developer of AlpineLinux ask for a separate udev, a part that
anyone needs, i think he did not even get an answer.  Which
deterred me further.  (I think the AlpineLinux lead developer's
name is pretty well-known in that society.)  Hmm.  It *could* be
that it was in fact in another issue that turned fixed linked-in
libraries like compressors like xz (the backdoor there, you know)
into dlopen()-managed mess, via kinda marshalling.  There.
Whatever.
Btw i did not sent out another email last week

  Jim Capp wrote in
   <1403506.1536.1718310415450.JavaMail.root@zimbraanteil>:
   |https://nosystemd.org/

  It is the pride and ignorance of the billion dollars that pay lots
  of developers on the Linux front that makes me sad.

  For example, on ossec-, we repeatedly see an OpenSUSE employee,
  who seems to get paid for doing security audits, publish security
  advisories.  That is (mostly seems to be) a one man show.
  Of course, many things happen behind the scenes, in bug trackers
  etc.  But i track fulldisclosure and ossec- for way over a decade.

  And "the same is true" for the boot and daemon monitoring
  environment.

  On FreeBSD, for example, one programmer is working to integrate
  "jail"ing
    (FreeBSD jails: twenty+ years ago it was a precondition in some
    system calls, looking for "is-jailed", plus dedicated network
    stack etc; usually (i hate it) also with its dedicated file
    system aka mounts etc. etc)
  into daemon startup aka the rc system, so you (that seems to be
  the idea) just set a rc.conf variable and the service is "boxed"
  in a jail automatically.

  If you look at all the rotten data in the Linux login etc (with
  PAM or not, etc etc), just a few programs in the startup process,
  but it is too much to keep them in line

Yeah!  [.] with modern achievements like PR_SET_CHILD_SUBREAPER to
move entire process hierarchies to dedicated zombie collectors and
such that is to say, with capabilities and all that, which systemd
makes easy, via easy text config files.  Ie, namespace containment
(aka network stack etc isolation), at your fingertips.
But per se a stacked call like

        cd /
        ip netns exec ${netns} \
                /usr/bin/env -i AUTHDISPLAY=${AUTHDISPLAY} DISPLAY=${DISPLAY} TERM=${TERM} XAUTHORITY=${XAUTHORITY} \
                        /usr/bin/unshare --ipc --uts --pid --fork --mount --mount-proc ${kill_child} ${rooter} ${prog} &
        pid=${!}
        [ -d /sys/fs/cgroup/_box_web ] && printf '%s\n' ${pid} > /sys/fs/cgroup/_box_web/cgroup.procs

#       if [ ${netns} = secweb ] || [ ${netns} = priwse ]; then
                wait $pid
                cleanup_setup
#       fi
        exec 7>&-

can (add capabilities) do the very same thing.

Btw there is an init-on-steroids [1] from the guy who took
maintainership of sysklogd quite some years ago (used by my Linux
distro ever since), it can also supervise, use cgroups, etc.
I plan to try it out for years, but since i realized i have to go
second line i have written some scripts, and then just call in via
SysV or OpenRC, or what.

I mean, i have no problem with the notification stuff of systemd,
it is now even included in OpenSSH (optionally, in
openbsd-compat/port-linux.c), but i mean the PID file things are
used for decades, and with "daemons and zombies are reparented to
a configured subreaper process" (instead of PID 1), and with the
fully capable but not systemd integrated udev (all "looser" Linux
distributions "have to use" eudev).  Ah!  Talking too much!!

  [1] https://github.com/troglobit/finit

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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

[Lyndon Nerenberg (VE7TFX/VE6BBM)]

> This is The Way if you really care about portability. Autoconf,
> once you get your head around what, why, and when it was created,
> makes for nice Makefiles and projects that are easy to include in
> the 100 Linux distributions with their own take on packaging the
> world.

This is outright claptrap and nonsense.  In the latter half of the
90s I was responsible for writing installers and generating
platform-native packages for about a dozen different commercial
UNIX platforms (AIX, Solaris, Irix, HP/UX, OSF, BSD/OS, ...).  Each
of these package systems was as different as could be from the
others.  (HP/UX didn't even have one.)

That entire process was driven by not very many lines of make
recipes, with the assistance of some awk glue that read a template
file from which it generated the native packages.  And these were
not trivial software distributions.  We were shipping complex IMAP,
X.400 and X.500 servers, along with a couple of MTAs.  Our installers
didn't just dump the files onto the system and point you at a README;
we coded a lot of the site setup into the installers, so the end
user mostly just had to edit a single config file to finish up.

--lyndon

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

[Kevin Bowling]

On Thu, Jun 20, 2024 at 9:45 AM Lyndon Nerenberg (VE7TFX/VE6BBM)
<lyndon@orthanc.ca> wrote:
>
> > This is The Way if you really care about portability. Autoconf,
> > once you get your head around what, why, and when it was created,
> > makes for nice Makefiles and projects that are easy to include in
> > the 100 Linux distributions with their own take on packaging the
> > world.
>
> This is outright claptrap and nonsense.  In the latter half of the
> 90s I was responsible for writing installers and generating
> platform-native packages for about a dozen different commercial
> UNIX platforms (AIX, Solaris, Irix, HP/UX, OSF, BSD/OS, ...).  Each
> of these package systems was as different as could be from the
> others.  (HP/UX didn't even have one.)

Strong language for something that is easily measured by looking at a
contemporary package collection.  That's great for you and whatever
this was but it is a simple fact that autoconf is the most common tool
for Linux and rejecting it or something like cmake that has widespread
adoption makes life more difficult for distributions.  Go look at a
random deb or rpm spec or ebuild or apk or whatever you wish, these
all have inbox support for autoconf and have to impedance mismatch
your clever custom jobs.

> That entire process was driven by not very many lines of make
> recipes, with the assistance of some awk glue that read a template
> file from which it generated the native packages.  And these were
> not trivial software distributions.  We were shipping complex IMAP,
> X.400 and X.500 servers, along with a couple of MTAs.  Our installers
> didn't just dump the files onto the system and point you at a README;
> we coded a lot of the site setup into the installers, so the end
> user mostly just had to edit a single config file to finish up.

The set of people that interact with make is minimal in relation to
the userbase of contemporary unix.  Binary distribution is the norm
and has been for decades.

> --lyndon