On Thu, 5 Dec 2024 02:11:04 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>On Wed, 4 Dec 2024 08:34:30 -0000 (UTC), Muttley wrote:
>
>> Linux is far closer to the unix philosphy (ignoring systemd) ...
>
>Which “unix philosophy” would that be?

The one where init does a single task instead of spreading itself throughout
the system after massive scope creep and hence isn't a huge attack vector for
hackers and a single point of failure, plus doesn't use obtuse binary files for
logging which require tools to read. init needed an upgrade for sure, but
systemd isn't it.

In article <viri3s$1ac00$1@news.xmission.com>,
Kenny McCormack <gazelle@shell.xmission.com> wrote:
>In article <vir23n$17csf$5@dont-email.me>,
>Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>On Wed, 4 Dec 2024 08:34:30 -0000 (UTC), Muttley wrote:
>>
>>> Linux is far closer to the unix philosphy (ignoring systemd) ...
>>
>>Which "unix philosophy" would that be?
>
>Wouldn't it be easier to just use Google (or whatever search engine you
>favor) to find out what the Unix philosphy is?

Why do people continue to try and engage with Lawrence in good
faith? He's a rather obvious troll.

- Dan C.

In article <vis90n$5d5$1@reader2.panix.com>,
Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>In article <viri3s$1ac00$1@news.xmission.com>,
>Kenny McCormack <gazelle@shell.xmission.com> wrote:
>>In article <vir23n$17csf$5@dont-email.me>,
>>Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>On Wed, 4 Dec 2024 08:34:30 -0000 (UTC), Muttley wrote:
>>>
>>>> Linux is far closer to the unix philosphy (ignoring systemd) ...
>>>
>>>Which "unix philosophy" would that be?
>>
>>Wouldn't it be easier to just use Google (or whatever search engine you
>>favor) to find out what the Unix philosphy is?
>
>Why do people continue to try and engage with Lawrence in good
>faith? He's a rather obvious troll.

Yes, well, you make a good point. But it passes the time.

One could argue that I wasn't exactly engaging in good faith.
I was making the point that he wasn't arguing in good faith; his question
is obvious trollery, not a legitimate question. If it *were* a legitimate
question, then Googling would give him his answer. But it isn't, so it
won't.,.

--
You are a dreadful man, Kenny, for all your ways are the ways of death.
- Rick C Hodgin -

(P.S. -> https://www.youtube.com/watch?v=sMmTkKz60W8)

On Thu, 5 Dec 2024 13:57:20 -0000 (UTC)
gazelle@shell.xmission.com (Kenny McCormack) wibbled:
>In article <vis90n$5d5$1@reader2.panix.com>,
>Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>is obvious trollery, not a legitimate question. If it *were* a legitimate
>question, then Googling would give him his answer. But it isn't, so it
>won't.,.

To be fair, if google had the answer to everything no one would ever post on
here again.

On Thu, 5 Dec 2024 08:19:46 -0000 (UTC), Muttley wrote:

> On Thu, 5 Dec 2024 02:11:04 -0000 (UTC)
> Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>>
>>On Wed, 4 Dec 2024 08:34:30 -0000 (UTC), Muttley wrote:
>>
>>> Linux is far closer to the unix philosphy (ignoring systemd) ...
>>
>>Which “unix philosophy” would that be?
>
> The one where init does a single task instead of spreading itself
> throughout the system ...

What “single task” did init do?

* Mount filesystems
* Spawn syslog, cron
* Spawn terminal login processes (getty)
* Respawn terminated getty processes
* Monitor other special stuff in inittab
* Spawn random other services, without monitoring their state
* Act as a general catch-all for orphaned processes when they terminate

This was all before systemd came on the scene.

On Thu, 5 Dec 2024 08:19:46 -0000 (UTC), Muttley wrote:

> On Thu, 5 Dec 2024 02:11:04 -0000 (UTC)
> Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>>
>>On Wed, 4 Dec 2024 08:34:30 -0000 (UTC), Muttley wrote:
>>
>>> Linux is far closer to the unix philosphy (ignoring systemd) ...
>>
>>Which “unix philosophy” would that be?
>
> The one where init does a single task instead of spreading itself
> throughout the system ...

What “single task” did init do?

* Mount filesystems
* Spawn syslog, cron
* Spawn terminal login processes (getty)
* Respawn terminated getty processes
* Monitor other special stuff in inittab
* Spawn random other services, without monitoring their state
* Act as a general catch-all for orphaned processes when they terminate

This was all before systemd came on the scene.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Thu, 5 Dec 2024 08:19:46 -0000 (UTC), Muttley wrote:
>
>> On Thu, 5 Dec 2024 02:11:04 -0000 (UTC)
>> Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>>>
>>>On Wed, 4 Dec 2024 08:34:30 -0000 (UTC), Muttley wrote:
>>>
>>>> Linux is far closer to the unix philosphy (ignoring systemd) ...
>>>
>>>Which “unix philosophy” would that be?
>>
>> The one where init does a single task instead of spreading itself
>> throughout the system ...
>
>What “single task” did init do?

Read a bunch of files and call the shell to execute them
whenever the run-level changed and monitored the resulting
processes for failure.

And reaped zombies.

On Thu, 5 Dec 2024 20:45:36 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>On Thu, 5 Dec 2024 08:19:46 -0000 (UTC), Muttley wrote:
>
>> On Thu, 5 Dec 2024 02:11:04 -0000 (UTC)
>> Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>>>
>>>On Wed, 4 Dec 2024 08:34:30 -0000 (UTC), Muttley wrote:
>>>
>>>> Linux is far closer to the unix philosphy (ignoring systemd) ...
>>>
>>>Which “unix philosophy” would that be?
>>
>> The one where init does a single task instead of spreading itself
>> throughout the system ...
>
>What “single task” did init do?

Boot the system to usable state. You can't have that without filesystems,
terminals or other important system daemons running.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Thu, 5 Dec 2024 08:19:46 -0000 (UTC), Muttley wrote:
>
>> On Thu, 5 Dec 2024 02:11:04 -0000 (UTC)
>> Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>>>
>>>On Wed, 4 Dec 2024 08:34:30 -0000 (UTC), Muttley wrote:
>>>
>>>> Linux is far closer to the unix philosphy (ignoring systemd) ...
>>>
>>>Which “unix philosophy” would that be?
>>
>> The one where init does a single task instead of spreading itself
>> throughout the system ...
>
> What “single task” did init do?
>
> * Mount filesystems
> * Spawn syslog, cron
> * Spawn terminal login processes (getty)
> * Respawn terminated getty processes
> * Monitor other special stuff in inittab
> * Spawn random other services, without monitoring their state
> * Act as a general catch-all for orphaned processes when they terminate
>
> This was all before systemd came on the scene.

Originally, mainly two things: Execute a script to kick off userspace
boot. Call wait in a loop in order to reap zombies.

System V init is somewhat more complicated than that. It has a concept
of numbered run levels and will run a configurable command in response
to runlevel change request. On linux, that's usually the script
/etc/init.d/rc. It also has some process monitoring capabilities: It can
start programs depending on the current runlevel and restart them when
they terminate. This is typically used to run getty processes for real
or virtual terminals and serial lines connected to modems.

Minus some handling of special situations (power failure, ctrl-alt-del
on PCs), that's it. Anything beyond that is done by the rc script.

One could argue that this is already a case of creature feep as process
monitoring and restarting of terminated processes and many other
process invocation management tasks can as well be provided
by dedicated programs. There's no reason to hack all of this (or rather,
some random subset of what could be provided here) into a single
codebase save developer inertia: It's less work to add code to a file
that's already compiled by some build system or to add a new file to a
code base which already has a build system than to create lots of
different, specialized tools.

On Fri, 6 Dec 2024 10:28:15 -0000 (UTC), Muttley wrote:

> On Thu, 5 Dec 2024 20:45:36 -0000 (UTC)
> Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>
>> What “single task” did init do?
>
> Boot the system to usable state.

What would you say systemd does that is not related to that?

On Fri, 6 Dec 2024 20:00:54 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

> What would you say systemd does that is not related to that?

QR codes?

John Ames <commodorejohn@gmail.com> writes:
>On Fri, 6 Dec 2024 20:00:54 -0000 (UTC)
>Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> What would you say systemd does that is not related to that?
>
>QR codes?
>

DNS. Drives me nuts, the crappy resolver in SystemCrap doesn't
work at all on a LAN which has a DNS server serving the local
domain and forwarding to external DNS resolvers.

On Fri, 6 Dec 2024 20:00:54 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> gabbled:
>On Fri, 6 Dec 2024 10:28:15 -0000 (UTC), Muttley wrote:
>
>> On Thu, 5 Dec 2024 20:45:36 -0000 (UTC)
>> Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>>
>>> What “single task” did init do?
>>
>> Boot the system to usable state.
>
>What would you say systemd does that is not related to that?

Networking, including DNS
Graphics
Logging
systemd-boot

Basically init should start the system, maintain some the running of
some essential daemons and then leave well alone.

In article <vj16j0$30r12$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote:
....
>>What would you say systemd does that is not related to that?
>
>Networking, including DNS
>Graphics
>Logging
>systemd-boot
>
>Basically init should start the system, maintain some the running of
>some essential daemons and then leave well alone.

I agree with you. But it underscores a major difference between two very
different ways of thinking about computing, which can be described as
"Unix-think" vs. "Windows-think".

systemd represents nothing so much as the bringing of "Windows-think" to Unix.

If one embraces "Windows-think", then systemd makes complete sense.

In fact, systemd is a lot of like the original goal of MS's "dot net",
which was to put a solid wall between the applications programmer and the
actual operating system.

--
If Jeb is Charlie Brown kicking a football-pulled-away, Mitt is a '50s
housewife with a black eye who insists to her friends the roast wasn't
dry.

On Sat, 7 Dec 2024 15:00:50 -0000 (UTC)
gazelle@shell.xmission.com (Kenny McCormack) gabbled:
>In article <vj16j0$30r12$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote:
>....
>>>What would you say systemd does that is not related to that?
>>
>>Networking, including DNS
>>Graphics
>>Logging
>>systemd-boot
>>
>>Basically init should start the system, maintain some the running of
>>some essential daemons and then leave well alone.
>
>I agree with you. But it underscores a major difference between two very
>different ways of thinking about computing, which can be described as
>"Unix-think" vs. "Windows-think".
>
>systemd represents nothing so much as the bringing of "Windows-think" to Unix.
>
>If one embraces "Windows-think", then systemd makes complete sense.

Yes, I've heard that said before and it does ring true. I guess we should be
thankful that systemd still uses text based config but I wouldn't be surprised
if some Windows like binary registry isn't somewhere on the horizon. Of course
Poettering has worked for MS for a long time so one can see where all his bad
ideas come from.

On 2024-12-07, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> If one embraces "Windows-think", then systemd makes complete sense.

Complete Windows-think would be if systemd ran all services in the same
process, so that all services die if you have to kill it.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Muttley@dastardlyhq.com writes:
> On Fri, 6 Dec 2024 20:00:54 -0000 (UTC)
> Lawrence D'Oliveiro <ldo@nz.invalid> gabbled:
>>On Fri, 6 Dec 2024 10:28:15 -0000 (UTC), Muttley wrote:
>>
>>> On Thu, 5 Dec 2024 20:45:36 -0000 (UTC)
>>> Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>>>
>>>> What “single task” did init do?
>>>
>>> Boot the system to usable state.
>>
>>What would you say systemd does that is not related to that?
>
> Networking, including DNS
> Graphics
> Logging
> systemd-boot
>
> Basically init should start the system, maintain some the running of
> some essential daemons and then leave well alone.

There's no particular reason why init should implement process
management. That init is the one program which cannot easily be replaced on
a running system, is actually a good reason why it shouldn't.

At least on Linux, arbitrary processes can become so-called subreapers
for their descendant processes (prctl(2), PR_SET_CHILD_SUBREAPER). This
means not only the already specious reason¹ that only init can wait for
processes trying to "break out of process management" by double-forking
isn't really valid anymore.

¹ Well-behaved server programs shouldn't background themselves as whether or not a
particular instance should run in the background depends on the reason
why it was started. Ie, that's a system- and situation-specific policy
decision. Backgrounding can easily be provided by a special tool for
that.

On 2024-12-05, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Thu, 5 Dec 2024 08:19:46 -0000 (UTC), Muttley wrote:
>
>> On Thu, 5 Dec 2024 02:11:04 -0000 (UTC)
>> Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>>>
>>>On Wed, 4 Dec 2024 08:34:30 -0000 (UTC), Muttley wrote:
>>>
>>>> Linux is far closer to the unix philosphy (ignoring systemd) ...
>>>
>>>Which ???unix philosophy??? would that be?
>>
>> The one where init does a single task instead of spreading itself
>> throughout the system ...
>
> What ???single task??? did init do?
>
> * Mount filesystems
> * Spawn syslog, cron
> * Spawn terminal login processes (getty)
> * Respawn terminated getty processes
> * Monitor other special stuff in inittab
> * Spawn random other services, without monitoring their state
> * Act as a general catch-all for orphaned processes when they terminate
>
> This was all before systemd came on the scene.

Actually traditional Unix "init" didn't do ALL those things. Most tended
to have the inittab config file. Even busybox's init has.

I can't think of a pre-systemd init that mounted filesystems, or spawned
things like syslog/cron. It ran other programs/systems that did most of
system-bring-up and the process control stuff one of which was SysV
initialise setup. Which, surprize though this might sound to some
people, was, at the time, an improvement on the startup setups that had
been common previously.

On 2024-12-07, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <vj16j0$30r12$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote:
> ...
>>>What would you say systemd does that is not related to that?
>>
>>Networking, including DNS
>>Graphics
>>Logging
>>systemd-boot
>>
>>Basically init should start the system, maintain some the running of
>>some essential daemons and then leave well alone.
>
> I agree with you. But it underscores a major difference between two very
> different ways of thinking about computing, which can be described as
> "Unix-think" vs. "Windows-think".
>
> systemd represents nothing so much as the bringing of "Windows-think" to Unix.
>
> If one embraces "Windows-think", then systemd makes complete sense.
>
> In fact, systemd is a lot of like the original goal of MS's "dot net",
> which was to put a solid wall between the applications programmer and the
> actual operating system.
>

Having just had a wee look at the Android init process, it looks as if
it attempts to do the same.

On Mon, 9 Dec 2024 20:28:31 -0000 (UTC), Jim Jackson wrote:

> Actually traditional Unix "init" didn't do ALL those things.

sysvinit certainly did. That is the usual standard of comparison, is it
not?

Jim Jackson <jj@franjam.org.uk> writes:
> On 2024-12-05, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> What ???single task??? did init do?
>>
>> * Mount filesystems
>> * Spawn syslog, cron
>> * Spawn terminal login processes (getty)
>> * Respawn terminated getty processes
>> * Monitor other special stuff in inittab
>> * Spawn random other services, without monitoring their state
>> * Act as a general catch-all for orphaned processes when they terminate
>>
>> This was all before systemd came on the scene.
>
> Actually traditional Unix "init" didn't do ALL those things. Most
> tended to have the inittab config file. Even busybox's init has.

Depends if you mean init=/sbin/init or init=the entire sysvinit system.
If you(plural) are going talk about init systems then you need to agree
terms.

--
https://www.greenend.org.uk/rjk/

On Tue, 10 Dec 2024 08:50:20 +0000
Richard Kettlewell <invalid@invalid.invalid> wibbled:
>Jim Jackson <jj@franjam.org.uk> writes:
>> On 2024-12-05, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>> What ???single task??? did init do?
>>>
>>> * Mount filesystems
>>> * Spawn syslog, cron
>>> * Spawn terminal login processes (getty)
>>> * Respawn terminated getty processes
>>> * Monitor other special stuff in inittab
>>> * Spawn random other services, without monitoring their state
>>> * Act as a general catch-all for orphaned processes when they terminate
>>>
>>> This was all before systemd came on the scene.
>>
>> Actually traditional Unix "init" didn't do ALL those things. Most
>> tended to have the inittab config file. Even busybox's init has.
>
>Depends if you mean init=/sbin/init or init=the entire sysvinit system.
>If you(plural) are going talk about init systems then you need to agree
>terms.

Its probably fair to say that because the traditional init system uses
shell scripts and hence can do anything you like they often did. But the
core part should really just be limited to starting the machine and getting
enough things running for a user to log on (or if its a black box to do its
task).

On 2024-12-10, Muttley@DastardlyHQ.org <Muttley@DastardlyHQ.org> wrote:
> On Tue, 10 Dec 2024 08:50:20 +0000
> Richard Kettlewell <invalid@invalid.invalid> wibbled:
>>Jim Jackson <jj@franjam.org.uk> writes:
>>> On 2024-12-05, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>> What ???single task??? did init do?
>>>>
>>>> * Mount filesystems
>>>> * Spawn syslog, cron
>>>> * Spawn terminal login processes (getty)
>>>> * Respawn terminated getty processes
>>>> * Monitor other special stuff in inittab
>>>> * Spawn random other services, without monitoring their state
>>>> * Act as a general catch-all for orphaned processes when they terminate
>>>>
>>>> This was all before systemd came on the scene.
>>>
>>> Actually traditional Unix "init" didn't do ALL those things. Most
>>> tended to have the inittab config file. Even busybox's init has.
>>
>>Depends if you mean init=/sbin/init or init=the entire sysvinit system.
>>If you(plural) are going talk about init systems then you need to agree
>>terms.

Yes of course. But he did mention "init" which I take to mean pid 1.

> Its probably fair to say that because the traditional init system uses
> shell scripts and hence can do anything you like they often did. But the
> core part should really just be limited to starting the machine and getting
> enough things running for a user to log on (or if its a black box to do its
> task).

Doesn't have to be shell scripts - init just launched programs, e.g.
getty on serial lines, etc.

I think Android init does quite a bit more.

On Tue, 10 Dec 2024 09:23:13 -0000 (UTC), Muttley wrote:

> But the core part should really just be limited to starting the
> machine and getting enough things running for a user to log on (or
> if its a black box to do its task).

One thing lacking from sysvinit is, while it can start a service, it
cannot ensure the service was started properly, and it cannot perform
reliable service shutdown. So the job of service management was really
only half-done.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Mon, 9 Dec 2024 20:28:31 -0000 (UTC), Jim Jackson wrote:
>
>> Actually traditional Unix "init" didn't do ALL those things.
>
> sysvinit certainly did. That is the usual standard of comparison, is it
> not?

It certainly didn't. sysvinit is a program. There source code is, for example, online
here

https://github.com/slicer69/sysvinit/blob/main/src/init.c

and all this does is execute configurable other programs in a couple of
different ways (mostly respawn, exec once and exec once and wait for it)
in response to runlevel changes.