Path: ...!news.mixmin.net!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Rainer Weikusat <rweikusat@talktalk.net>
Newsgroups: comp.unix.programmer
Subject: Re: Faking a TTY on a pipe/socketpair
Date: Fri, 06 Dec 2024 17:01:49 +0000
Lines: 50
Message-ID: <87zfl8924i.fsf@doppelsaurus.mobileactivedefense.com>
References: <vh9vgr$5bb$1@dont-email.me> <jHw3P.41603$vLg2.41154@fx17.iad>
	<vimf13$3uoji$1@dont-email.me> <vinp86$avd9$1@dont-email.me>
	<vip46l$omqu$1@dont-email.me> <vir23n$17csf$5@dont-email.me>
	<virnn2$1g9ja$1@dont-email.me> <vit3dg$1quau$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Trace: individual.net FIWrRSXTSsyC0F8PB/LjvwPV+orKyjcMMMjocFtrxSM7zjvnQ=
Cancel-Lock: sha1:sBEnW2ONUvdFwzWi2ujcYrr/3n4= sha1:OjYjXHQPrfHvsHyjLZvQrzX1uvQ= sha256:ujpdk2vbuSrP6e0TCJyve9jYdZ5gHBpgsHq4w6WQpKY=
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
Bytes: 3270

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.