On 2022-02-02, William Ahern <william@25thandClement.com> wrote:
>
> I do indeed use OpenBSD for the stuff that matters most =) But I figured the
> context here was mainline Linux distributions using systemd (e.g. Debian,
> Fedora), not alternative Linux distributions (e.g. Alpine) or different Unix
> operating systems altogether.

Debian, and I would guess most GNU/Linux distributions, also distribute
good-old SysV init and can be configured to use that. So it's really on
you, if you decide to stick with systemd. Removing systemd is the first
thing I do on any new GNU/Linux installation.

--
John Tsiombikas
http://nuclear.mutantstargoat.com/

On 26 May 2022 21:36:35 GMT
John Tsiombikas <nuclear@member.fsf.org> wrote:
>On 2022-02-02, William Ahern <william@25thandClement.com> wrote:
>>
>> I do indeed use OpenBSD for the stuff that matters most =) But I figured the
>> context here was mainline Linux distributions using systemd (e.g. Debian,
>> Fedora), not alternative Linux distributions (e.g. Alpine) or different Unix
>> operating systems altogether.
>
>Debian, and I would guess most GNU/Linux distributions, also distribute
>good-old SysV init and can be configured to use that. So it's really on
>you, if you decide to stick with systemd. Removing systemd is the first
>thing I do on any new GNU/Linux installation.

Just install Slackware, it uses SysV by default.

On 2022-05-27, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
> On 26 May 2022 21:36:35 GMT
> John Tsiombikas <nuclear@member.fsf.org> wrote:
>>On 2022-02-02, William Ahern <william@25thandClement.com> wrote:
>>>
>>> I do indeed use OpenBSD for the stuff that matters most =) But I figured the
>>> context here was mainline Linux distributions using systemd (e.g. Debian,
>>> Fedora), not alternative Linux distributions (e.g. Alpine) or different Unix
>>> operating systems altogether.
>>
>>Debian, and I would guess most GNU/Linux distributions, also distribute
>>good-old SysV init and can be configured to use that. So it's really on
>>you, if you decide to stick with systemd. Removing systemd is the first
>>thing I do on any new GNU/Linux installation.
>
> Just install Slackware, it uses SysV by default.

Speaking of which, I recently installed Slackware 15 into a VM.

Very refreshing experience.

But, I must say, Slackware is quite harmed by the insane piece of
vandalism that some dastardly knaves perpetrated against the kernel
source sometime in the past couple of years. I'm talking about the
vicious removal of the Shift-PgUp scrollback history available in the
console.

When you are doing a text-only install using only the console,
in a distro such as Slackware, it's very annoying not to be able to
scroll back. I needed to see something that scrolled off the screen
while doing partitioning with fdisk. This was so vexing, I did the
unthinkable and finished the job with cfdisk.

Burn in hell, scrollback-removing cretins!

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

In article <20220527223044.307@kylheku.com>,
Kaz Kylheku <480-992-1380@kylheku.com> wrote:
....
>Speaking of which, I recently installed Slackware 15 into a VM.
>
>Very refreshing experience.
>
>But, I must say, Slackware is quite harmed by the insane piece of
>vandalism that some dastardly knaves perpetrated against the kernel
>source sometime in the past couple of years. I'm talking about the
>vicious removal of the Shift-PgUp scrollback history available in the
>console.
>
>When you are doing a text-only install using only the console,
>in a distro such as Slackware, it's very annoying not to be able to
>scroll back. I needed to see something that scrolled off the screen
>while doing partitioning with fdisk. This was so vexing, I did the
>unthinkable and finished the job with cfdisk.
>
>Burn in hell, scrollback-removing cretins!

+1 (!)

Two comments:

1) I heard about this on some Raspberry Pi forum. Apparently, what
happened was that somebody discovered a bug (presumably, a non-trivial one)
in the code for this, but there was no one around (i.e., no one left) who
could fix it. So, they made the executive decision to just remove it - on
the assumption that (almost) nobody would miss it. Essentially, the code
had become unmaintainable.

2) I don't run any recent enough kernels to be affected by this, so I have
no way to test it. But I'm wondering something. Do you know if they
removed the underlying buffer (i.e., the fact that there is more stored
than actually fits [i.e., is visible] on the screen) or just the ability to
access it via certain keystrokes? I ask, because I have some scripts that
access the console buffer via /dev/vcsN - and these scripts are able to get
the part of the buffer that is no longer visible onscreen. I'm wondering
if that still works...

--
The motto of the GOP "base": You can't *be* a billionaire, but at least you
can vote like one.

On 2022-05-28, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <20220527223044.307@kylheku.com>,
> Kaz Kylheku <480-992-1380@kylheku.com> wrote:
> ...
>>Speaking of which, I recently installed Slackware 15 into a VM.
>>
>>Very refreshing experience.
>>
>>But, I must say, Slackware is quite harmed by the insane piece of
>>vandalism that some dastardly knaves perpetrated against the kernel
>>source sometime in the past couple of years. I'm talking about the
>>vicious removal of the Shift-PgUp scrollback history available in the
>>console.
>>
>>When you are doing a text-only install using only the console,
>>in a distro such as Slackware, it's very annoying not to be able to
>>scroll back. I needed to see something that scrolled off the screen
>>while doing partitioning with fdisk. This was so vexing, I did the
>>unthinkable and finished the job with cfdisk.
>>
>>Burn in hell, scrollback-removing cretins!
>
> +1 (!)
>
> Two comments:
>
> 1) I heard about this on some Raspberry Pi forum. Apparently, what
> happened was that somebody discovered a bug (presumably, a non-trivial one)
> in the code for this, but there was no one around (i.e., no one left) who
> could fix it.

This is the part that is idiotic, because unless those bugs are so
severe that they make possible a *remote* exploit, they should
just stay.

I enjoyed "years of trouble-free operation" with the console, and now
some fuckfaces who can't deal with a few corner cases think it's fine to
deal a blow to the user-friendliness of Linux?

Make it a command line option, you know?

linux root=whatever ... console_scroll=1 ,,,

Then those who are paranoid about the bug can just leave out the option.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

Kaz Kylheku <480-992-1380@kylheku.com> writes:
>On 2022-05-28, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> In article <20220527223044.307@kylheku.com>,
>> Kaz Kylheku <480-992-1380@kylheku.com> wrote:
>> ...
>>>Speaking of which, I recently installed Slackware 15 into a VM.
>>>
>>>Very refreshing experience.
>>>
>>>But, I must say, Slackware is quite harmed by the insane piece of
>>>vandalism that some dastardly knaves perpetrated against the kernel
>>>source sometime in the past couple of years. I'm talking about the
>>>vicious removal of the Shift-PgUp scrollback history available in the
>>>console.
>>>
>>>When you are doing a text-only install using only the console,
>>>in a distro such as Slackware, it's very annoying not to be able to
>>>scroll back. I needed to see something that scrolled off the screen
>>>while doing partitioning with fdisk. This was so vexing, I did the
>>>unthinkable and finished the job with cfdisk.
>>>
>>>Burn in hell, scrollback-removing cretins!
>>
>> +1 (!)
>>
>> Two comments:
>>
>> 1) I heard about this on some Raspberry Pi forum. Apparently, what
>> happened was that somebody discovered a bug (presumably, a non-trivial one)
>> in the code for this, but there was no one around (i.e., no one left) who
>> could fix it.
>
>This is the part that is idiotic, because unless those bugs are so
>severe that they make possible a *remote* exploit, they should
>just stay.
>
>I enjoyed "years of trouble-free operation" with the console, and now
>some fuckfaces who can't deal with a few corner cases think it's fine to
>deal a blow to the user-friendliness of Linux?
>
>Make it a command line option, you know?
>
>linux root=whatever ... console_scroll=1 ,,,

The source is available for download. Feel free to fix it and
submit the patch to the kernel mailing list.

scott@slp53.sl.home (Scott Lurndal) writes:
> The source is available for download. Feel free to fix it and
> submit the patch to the kernel mailing list.

The vulnerability was already fixed. The requirement for restoring
functionality seems to be for someone to volunteer to maintain the code
in the long term.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=973c096f6a85e5b5f2a295126ba6928d9a6afd45
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ebfdfeeae8c01fcb2b3b74ffaf03876e20835d2d

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

On Sat, 28 May 2022 16:51:43 -0000 (UTC)
Kaz Kylheku <480-992-1380@kylheku.com> wrote:
>On 2022-05-28, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> In article <20220527223044.307@kylheku.com>,
>> Kaz Kylheku <480-992-1380@kylheku.com> wrote:
>> ...
>>>Speaking of which, I recently installed Slackware 15 into a VM.
>>>
>>>Very refreshing experience.
>>>
>>>But, I must say, Slackware is quite harmed by the insane piece of
>>>vandalism that some dastardly knaves perpetrated against the kernel
>>>source sometime in the past couple of years. I'm talking about the
>>>vicious removal of the Shift-PgUp scrollback history available in the
>>>console.
>>>
>>>When you are doing a text-only install using only the console,
>>>in a distro such as Slackware, it's very annoying not to be able to
>>>scroll back. I needed to see something that scrolled off the screen
>>>while doing partitioning with fdisk. This was so vexing, I did the
>>>unthinkable and finished the job with cfdisk.
>>>
>>>Burn in hell, scrollback-removing cretins!
>>
>> +1 (!)
>>
>> Two comments:
>>
>> 1) I heard about this on some Raspberry Pi forum. Apparently, what
>> happened was that somebody discovered a bug (presumably, a non-trivial one)
>> in the code for this, but there was no one around (i.e., no one left) who
>> could fix it.
>
>This is the part that is idiotic, because unless those bugs are so
>severe that they make possible a *remote* exploit, they should
>just stay.
>
>I enjoyed "years of trouble-free operation" with the console, and now
>some fuckfaces who can't deal with a few corner cases think it's fine to
>deal a blow to the user-friendliness of Linux?
>
>Make it a command line option, you know?
>
>linux root=whatever ... console_scroll=1 ,,,
>
>Then those who are paranoid about the bug can just leave out the option.

Don't worry , Poettering will probably come along soon and add the functionality
to systemd. It'll require an incomprehensible setup in some undocumented
file and won't work properly but its the thought that counts.

On 2022-05-29, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
> Don't worry , Poettering will probably come along soon and add the functionality
> to systemd. It'll require an incomprehensible setup in some undocumented
> file and won't work properly but its the thought that counts.

True systemd story here.

Almost something like a decade ago, while working at Broadcom, I
developed a nice kernel feature in the TTY subsystem.

1. Firstly, I ensured that when you unplug a a USB Serial adapter from
a port and then re-insert it, it would get the same /dev/ttyUSB<N>
device entry.

2. Secondly, I hacked the USB Serial and TTY code such that not only
would you get the same device, but your TTY session would be intact.
As a test case, you could log in to the board over the USB Serial
console, start editing a file in vi, and then unplug the USB Serial
dongle. Plug it back in, hit Ctrl-L to refresh the screen and, voila,
keep editing. You're not logged out, your edit session didn't die,
nothing.

3. I also hacked it so that you could boot the board with the USB-Serial
in an unplugged state, and get a console upon plugging it in.

4. The hot-plugging-with-session intact worked even if you swapped
brands. E.g, unplug a serial adapter based on a FTDI chip, and plug
in one based on a PL2302: no problem. Though a different driver is
now handling the I/O at the low level, your session is intact.

Now when I was debugging this into working, I kept getting a mysterious
issue: for some unknown reason, the session was dying when I unplugged
the USB-Serial adapter. I was sure the code was correct. There was
no reason that should be happening. I spent a day trying to root cause
this problem. Through some kernel printk's, I traced the behavior to
some system calls issued by ... that fucking systemd!

systemd implemented a behavior whereby if it detects that the USB Serial
device is removed, it turfs the surrounding TTY session. I found this
behavior in the source code; it was not documented anywhere. I grepped
all available docs backward and forward, to no avail.

Moreover, no such behavior should be implemented. If a TTY session is
going to be turfed due to removed hardware, it should be the operating
system doing it. Systemd thinks it's the operating system. That's
what its name means.

So all my code was fine; the biggest issue in debugging the feature was
what undocumented blurb to stick into some systemd file, after wasting
time uncovering that cause.

Send that Le Nerd Puttering bastard to hell, and throw his third-rate C
coding skills after him.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On Sun, 29 May 2022 08:06:50 -0000 (UTC)
Kaz Kylheku <480-992-1380@kylheku.com> wrote:
>On 2022-05-29, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>Moreover, no such behavior should be implemented. If a TTY session is
>going to be turfed due to removed hardware, it should be the operating
>system doing it. Systemd thinks it's the operating system. That's
>what its name means.
>
>So all my code was fine; the biggest issue in debugging the feature was
>what undocumented blurb to stick into some systemd file, after wasting
>time uncovering that cause.
>
>Send that Le Nerd Puttering bastard to hell, and throw his third-rate C
>coding skills after him.

Indeed. I've read numerous stories about systemd fucking things up. The
mystery isn't why it does it - Poetterings lack of decent coding ability is
only matched by his arrogance - the true mystery is why any distro never mind
almost all of them is using this 2nd rate POS. The only reason I've ever seen
that made sense was it booted faster than SysV. Which it does for a given
amount of functionality. So fucking what? Who cares about getting a prompt
30 secs faster if every other admin task is a bloody nightmare especially in
a server system which might only be rebooted once a year anyway!

After the abortion that is pulseaudio why did anyone let this guy near a
keyboard again never mind allow his pet init project to take over linux?
Its just the insanity of the herd mentality squared IMO.

Muttley@dastardlyhq.com writes:
> Indeed. I've read numerous stories about systemd fucking things
> up.

People write angry posts about things breaking, they don’t write them
about things that work. If you only look at the negatives then you don’t
have any basis for thinking that that the positives don’t outweigh them.

> The mystery isn't why it does it - Poetterings lack of decent
> coding ability is only matched by his arrogance - the true mystery is
> why any distro never mind almost all of them is using this 2nd rate
> POS.

In general if a large group of people are making technical decisions
that you don’t understand then they are probably working from different
information to you; either they know or believe something you don’t, or
the other way around.

In this case, the extra information Linux distributions have that you
don’t is the collection of practical issues that they and their users
have run into with sysvinit: things that didn’t work reliably or things
that were impractical to achieve with it.

Because of those issues something had to change (and in many other Unix
platforms, it already had). systemd wasn’t the only horse in the race;
it just happens to be the one that won.

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

On Sat, 28 May 2022 05:38:39 -0000 (UTC)
Kaz Kylheku <480-992-1380@kylheku.com> wrote:
> Speaking of which, I recently installed Slackware 15 into a VM.
>
> Very refreshing experience.
>
> But, I must say, Slackware is quite harmed by the insane piece of
> vandalism that some dastardly knaves perpetrated against the kernel
> source sometime in the past couple of years. I'm talking about the
> vicious removal of the Shift-PgUp scrollback history available in the
> console.
>
> When you are doing a text-only install using only the console,
> in a distro such as Slackware, it's very annoying not to be able to
> scroll back. I needed to see something that scrolled off the screen
> while doing partitioning with fdisk. This was so vexing, I did the
> unthinkable and finished the job with cfdisk.
>
> Burn in hell, scrollback-removing cretins!

I wasn't familiar with this functionality. Does it offer any advantages over
using GNU screen or script ? The latter is not interactive but will record
the information you want. With the kernel thing , is it per user configurable
how much scrollback to store ? If not , it seems to me it's best to use
something which is per user.

--
vlaho.ninja/prog

On Sun, 29 May 2022 10:06:27 +0100
Richard Kettlewell <invalid@invalid.invalid> wrote:
>Muttley@dastardlyhq.com writes:
>> Indeed. I've read numerous stories about systemd fucking things
>> up.
>
>People write angry posts about things breaking, they don’t write them
>about things that work. If you only look at the negatives then you don’t
>have any basis for thinking that that the positives don’t outweigh them.

I've seen enough negatives to know that systemd design is fundamentally
broken.

>In this case, the extra information Linux distributions have that you
>don’t is the collection of practical issues that they and their users
>have run into with sysvinit: things that didn’t work reliably or things
>that were impractical to achieve with it.

Feel free to list them. I haven't noticed the BSDs pounding at Poetterings
door to do a port for them.

In article <t7034i$1eb0$1@gioia.aioe.org>, <muttley@dastardlyhq.com> wrote:
....
>I've seen enough negatives to know that systemd design is fundamentally
>broken.
....
>Feel free to list them. I haven't noticed the BSDs pounding at Poetterings
>door to do a port for them.

I'm no fan of systemd, so don't assume that I am. I'd just as soon it had
not happened, but it has, and I have to live with it. It's the nature of
computers that when you run out of things that are broken, you start fixing
things that are not broken. MS (e.g.) does this frequently.

That said, I say to you: Give it time.

As time goes by, two things will happen with systemd:

1) The bugs will, slowly, be filtered out.

2) It will become a community project, rather than a one-man-band, as
it currently is.

The point is that, in, say, 30 years, it will be as accepted and normalized
as the old init system is/was. And people will be clamoring for something
new to replace it.

P.S. I do agree, though, that if it is an init system, it would stay an
init system. The grand design of its being an extension (and by
"extension to", I mean "an integral part of") to the kernel/OS is
fundamentally wrong. That it should be doing what Kaz describes above is
fundamentally wrong. I expect these parts also to be filtered out as time
goes by.

--
People who say they'll vote for someone else because Obama couldn't fix
*all* of Bush's messes are like people complaining that he couldn't cure
cancer, so they'll go and vote for (more) cancer.

On Mon, 30 May 2022 11:38:03 -0000 (UTC)
gazelle@shell.xmission.com (Kenny McCormack) wrote:
>In article <t7034i$1eb0$1@gioia.aioe.org>, <muttley@dastardlyhq.com> wrote:
>....
>>I've seen enough negatives to know that systemd design is fundamentally
>>broken.
>....
>>Feel free to list them. I haven't noticed the BSDs pounding at Poetterings
>>door to do a port for them.
>
>I'm no fan of systemd, so don't assume that I am. I'd just as soon it had
>not happened, but it has, and I have to live with it. It's the nature of
>computers that when you run out of things that are broken, you start fixing
>things that are not broken. MS (e.g.) does this frequently.

True.

>That said, I say to you: Give it time.
>
>As time goes by, two things will happen with systemd:
>
> 1) The bugs will, slowly, be filtered out.

No one is complaining about bugs, thats the nature of software. Its the
designed in fuckups that are the issue.

> 2) It will become a community project, rather than a one-man-band, as
> it currently is.

Out of his cold dead hands IMO.

>fundamentally wrong. That it should be doing what Kaz describes above is
>fundamentally wrong. I expect these parts also to be filtered out as time
>goes by.

Pffft. When did a codebase ever get smaller with less functionality?

On 2022-05-30, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <t7034i$1eb0$1@gioia.aioe.org>, <muttley@dastardlyhq.com> wrote:
> ...
>>I've seen enough negatives to know that systemd design is fundamentally
>>broken.
> ...
>>Feel free to list them. I haven't noticed the BSDs pounding at Poetterings
>>door to do a port for them.
>
> I'm no fan of systemd, so don't assume that I am. I'd just as soon it had
> not happened,

Let's make it clear; systemd (or something like it) is necessary and
that is why distros bundle it and use it.

The problem is, systemd is just yet another instance in the continuing
Unix history of settling on the first, maybe second thing that comes
along that solves a problem, just because some random goofball hit upon
the idea and hacked something up and promoted it in the right place at
the right time. And then you're stuck with it for decades to come.

The main problem with systemd is that it creates a big impetus against
replacing it. And that would be fine if systemd were something other
than it is.

(The answer isn't necessarily going back to some scattered shell
scripts to duct-tape everything together; that's the strawman
characterization of the systemd nay-sayers as a group, even though
a few do advocate exactly that.)

> The point is that, in, say, 30 years, it will be as accepted and normalized
> as the old init system is/was. And people will be clamoring for something
> new to replace it.

The GNU Guix project has already replaced it; it manages services with
something called GNU Shepherd. Shepherd runs as PID 1, and manages
service units and all that stuff.

Guix isn't currently very popular though.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On Mon, 30 May 2022 20:10:43 -0000 (UTC)
Kaz Kylheku <480-992-1380@kylheku.com> wrote:
>(The answer isn't necessarily going back to some scattered shell
>scripts to duct-tape everything together; that's the strawman
>characterization of the systemd nay-sayers as a group, even though
>a few do advocate exactly that.)

The thing people forget about shell scripts is that all shells are turing
complete languages and therefor FAR more flexible than some config scripts and
a load of flags which is the systemd and other init system methods. With
systemd you're effectively limited to the functionality that systemd provides
but with rc scripts you have complete flexibility over how you control the
system. old -ne bad.

In article <t74hcm$1fiu$1@gioia.aioe.org>, <muttley@dastardlyhq.com> wrote:
>On Mon, 30 May 2022 20:10:43 -0000 (UTC)
>Kaz Kylheku <480-992-1380@kylheku.com> wrote:
>>(The answer isn't necessarily going back to some scattered shell
>>scripts to duct-tape everything together; that's the strawman
>>characterization of the systemd nay-sayers as a group, even though
>>a few do advocate exactly that.)
>
>The thing people forget about shell scripts is that all shells are turing
>complete languages and therefor FAR more flexible than some config scripts and
>a load of flags which is the systemd and other init system methods. With
>systemd you're effectively limited to the functionality that systemd provides
>but with rc scripts you have complete flexibility over how you control the
>system. old -ne bad.

I think that the gist of the systemd mentality is that "flexibility" is not
necessarily a good thing. I.e., too much "flexibility" is a bad thing.

I.e., the problem with making people write shell scripts is that it:
1) Is more work than is needed in 97.1237% of the cases.
and
2) Allows people to screw up by making things more complicated and thus
hard-to-maintain than they should be doing.

And, when all is said and done, I do agree with point 1 above. That for
most cases, being able to do it as a "config file" rather than as a
full-blown executable script, is a benefit.

Now I know, of course, that nobody ever actually writes one of these things
from scratch - you just take an existing one and modify it - but, still,
you have to be concerned with the fact that you are writing a script, not
just a "config file".

--
The motto of the GOP "base": You can't *be* a billionaire, but at least you
can vote like one.

muttley@dastardlyhq.com, dans le message <t74hcm$1fiu$1@gioia.aioe.org>,
a écrit :
> The thing people forget about shell scripts is that all shells are turing
> complete languages and therefor FAR more flexible

The things you don't understand about shell scripts is that they can do
anything and they are a very fragile language. That combination unavoidably
leads to scripts that behave wildly and are a nightmare to control as soon
as the running environment is slightly different than expected.

In article <6295e928$0$8502$426a74cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> wrote:
>muttley@dastardlyhq.com, dans le message <t74hcm$1fiu$1@gioia.aioe.org>,
> a crit:
>> The thing people forget about shell scripts is that all shells are turing
>> complete languages and therefor FAR more flexible.
>
>The things you don't understand about shell scripts is that they can do
>anything and they are a very fragile language. That combination unavoidably
>leads to scripts that behave wildly and are a nightmare to control as soon
>as the running environment is slightly different than expected.

Yes. Well put.

The same general point as I was making.

It is a lot easier to prove that a config file is correct than it is to
prove a shell script correct.

--
I've learned that people will forget what you said, people will forget
what you did, but people will never forget how you made them feel.

- Maya Angelou -

On 31 May 2022 10:08:40 GMT
Nicolas George <nicolas$george@salle-s.org> wrote:
>muttley@dastardlyhq.com, dans le message <t74hcm$1fiu$1@gioia.aioe.org>,
> a �crit�:
>> The thing people forget about shell scripts is that all shells are turing
>> complete languages and therefor FAR more flexible
>
>The things you don't understand about shell scripts is that they can do
>anything and they are a very fragile language. That combination unavoidably
>leads to scripts that behave wildly and are a nightmare to control as soon
>as the running environment is slightly different than expected.

Rubbish. I've never had an rc script "behave wildly" in my entire career.
You sound like an apologist for Poettering.

Richard Kettlewell <invalid@invalid.invalid> writes:
> Muttley@dastardlyhq.com writes:

[...]

>> The mystery isn't why it does it - Poetterings lack of decent
>> coding ability is only matched by his arrogance - the true mystery is
>> why any distro never mind almost all of them is using this 2nd rate
>> POS.
>
> In general if a large group of people are making technical decisions
> that you don’t understand then they are probably working from different
> information to you; either they know or believe something you don’t, or
> the other way around.
>
> In this case, the extra information Linux distributions have that you
> don’t is the collection of practical issues that they and their users
> have run into with sysvinit: things that didn’t work reliably or things
> that were impractical to achieve with it.

Since RedHat had switched to sysvinit, Linux distribution had
accumulated a real mess of horrors in seriously bloated and buggy init
scripts whose authors seem to have been wedded to doing everything in
the wrong way. These didn't work reliably and some things just couldn't
be achieved in this way. One would have needed to write dedicated C
programs for them instead of the usual sysadmin coding horror tools
which try to implement every conceivable piece of process management
$sysadmin could presently think of in a single program with some 8000
different options. This was arguably a real problem, however, it wasn't
related to the program which caused these scripts to be executed.

Claiming otherwise was one of many sleights of hand used to market
systemd.

The sysvinit program (well worth of replacement due to it being old and
crufty and having an ill-defined feature set) does almost nothing for
system/ process management itself. It just initiates runlevel changes by
invoking a configurable, other program with certain arguments.
 Obviously, the script mess has long since started to regrow in top of
systemd as the functionality of that is way to limited to handle a
wealth of real world problems.

On Tue, 31 May 2022 14:37:33 -0000 (UTC)
gazelle@shell.xmission.com (Kenny McCormack) wrote:
>In article <6295e928$0$8502$426a74cc@news.free.fr>,
>Nicolas George <nicolas$george@salle-s.org> wrote:
>>muttley@dastardlyhq.com, dans le message <t74hcm$1fiu$1@gioia.aioe.org>,
>> a crit:
>>> The thing people forget about shell scripts is that all shells are turing
>>> complete languages and therefor FAR more flexible.
>>
>>The things you don't understand about shell scripts is that they can do
>>anything and they are a very fragile language. That combination unavoidably
>>leads to scripts that behave wildly and are a nightmare to control as soon
>>as the running environment is slightly different than expected.
>
>Yes. Well put.
>
>The same general point as I was making.
>
>It is a lot easier to prove that a config file is correct than it is to
>prove a shell script correct.

Great. Now prove the system that runs the config file is correct too because
that is the thing producing the same functionality as the shell script.

On Tue, 31 May 2022 09:01:36 -0000 (UTC)
gazelle@shell.xmission.com (Kenny McCormack) wrote:
>I think that the gist of the systemd mentality is that "flexibility" is not
>necessarily a good thing. I.e., too much "flexibility" is a bad thing.

I'd better restrict myself to a subset of C++ then next time I write an
application, don't want too much flexibility!

>Now I know, of course, that nobody ever actually writes one of these things
>from scratch - you just take an existing one and modify it - but, still,
>you have to be concerned with the fact that you are writing a script, not
>just a "config file".

All unix admins can write shell, particularly if they're managing the boot
system. That may not be the case for a-n-other config file syntax.

On 2022-05-31, muttley@dastardlyhq.com <muttley@dastardlyhq.com> wrote:
> Great. Now prove the system that runs the config file is correct too
> because that is the thing producing the same functionality as the
> shell script.

Why that's a piece of cake; we just refer to the thorough documentation
and exhaustive regression test suite which accompanies the mass of shell
scripts and defines what they actually do!

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal