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-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.
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.
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.
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.
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.
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.
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.
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,
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 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.)
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.
The thing people forget about shell scripts is that all shells are turing complete languages and therefor FAR more flexible
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.
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.
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".
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.
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.
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 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!
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!
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!
On Tue, 31 May 2022 20:36:53 -0000 (UTC)
Kaz Kylheku <480-992-1380@kylheku.com> wrote:
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!
You mean like what comes with systemd? rc shell scripts are by their
nature fairly simple and linear and can be grokked in minutes. Good luck doing that with the systemd source code.
muttley@dastardlyhq.com writes:
On Tue, 31 May 2022 20:36:53 -0000 (UTC)
Kaz Kylheku <480-992-1380@kylheku.com> wrote:
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!
You mean like what comes with systemd? rc shell scripts are by their
nature fairly simple and linear and can be grokked in minutes. Good luck
doing that with the systemd source code.
Ehh ... real-world distro init.d scripts are every-growing tumour-like >entities. Eg, the system I'm using to write this has 83 of them.
avg length 125.49 lines
median 84
Kaz Kylheku <480-992-1380@kylheku.com> wrote:
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!
I knew someone would post to that effect - that using systemd instead of shell scripts just transfers the burden of proof from your shell scripts to systemd itself. But the point is that:
1) It probably is correct, and, unless you really good (and most people
currently employed in IT aren't), it is more likely to be correct
than are your scripts.
2) If there is a bug, it's not your problem. It's that guy at Red
Hat's problem. You might even get a thrill from
finding/documenting/reporting the bug.
In article <20220531133307.535@kylheku.com>,
Kaz Kylheku <480-992-1380@kylheku.com> wrote:
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!
I knew someone would post to that effect - that using systemd instead of >shell scripts just transfers the burden of proof from your shell scripts to >systemd itself. But the point is that:
1) It probably is correct, and, unless you really good (and most people currently employed in IT aren't), it is more likely to be correct
than are your scripts.
2) If there is a bug, it's not your problem. It's that guy at Red
Hat's problem. You might even get a thrill from finding/documenting/reporting the bug.
Rainer Weikusat <rweikusat@talktalk.net> wrote:
muttley@dastardlyhq.com writes:
On Tue, 31 May 2022 20:36:53 -0000 (UTC)
Kaz Kylheku <480-992-1380@kylheku.com> wrote:
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!
You mean like what comes with systemd? rc shell scripts are by their
nature fairly simple and linear and can be grokked in minutes. Good luck >>> doing that with the systemd source code.
Ehh ... real-world distro init.d scripts are every-growing tumour-like >>entities. Eg, the system I'm using to write this has 83 of them.
Why's that a bad thing? Would you prefer one huge script that did everything? My /bin directory alone has 209 utils in it. Should I exchange them all for BusyBox?
avg length 125.49 lines
median 84
Seems perfectly reasonable to me.
gazelle@shell.xmission.com (Kenny McCormack) wrote:
In article <20220531133307.535@kylheku.com>,
Kaz Kylheku <480-992-1380@kylheku.com> wrote:
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!
I knew someone would post to that effect - that using systemd instead of >>shell scripts just transfers the burden of proof from your shell scripts to >>systemd itself. But the point is that:
1) It probably is correct, and, unless you really good (and most people >> currently employed in IT aren't), it is more likely to be correct
than are your scripts.
2) If there is a bug, it's not your problem. It's that guy at Red
Hat's problem. You might even get a thrill from
finding/documenting/reporting the bug.
It most definately is your problem if you're system is fucked because of
it. With a shell script you edit it yourself, problem solved. With systemd you'd have to wait for pottyring to get his arse into gear and even acknowledge there is a bug first. Good luck with that.
The systemd-242 that's part of Debian 10 has 444,451 lines of
code. Anybody who seriously claims that a C program of this size is
"probably correct" and "more likely to be correct" than a much smaller
shell scripts is seriously deluded, not the least because the two
statements contradict each other.
Rainer Weikusat , dans le message <87zgiwurww.fsf@doppelsaurus.mobileactivedefense.com>, a écrit :
The systemd-242 that's part of Debian 10 has 444,451 lines of
code. Anybody who seriously claims that a C program of this size is
"probably correct" and "more likely to be correct" than a much smaller
shell scripts is seriously deluded, not the least because the two
statements contradict each other.
How many lines of C code in the shell interpreter and core utilities necessary to run the shell scripts?
The need for coreutils and the shell doesn't go away with systemd, though.
So it's not either/or; it's and.
Nicolas George <nicolas$george@salle-s.org> wrote:
Rainer Weikusat , dans le message
<87zgiwurww.fsf@doppelsaurus.mobileactivedefense.com>, a écrit :
The systemd-242 that's part of Debian 10 has 444,451 lines of
code. Anybody who seriously claims that a C program of this size is
"probably correct" and "more likely to be correct" than a much smaller
shell scripts is seriously deluded, not the least because the two
statements contradict each other.
How many lines of C code in the shell interpreter and core utilities
necessary to run the shell scripts?
$ find coreutils-8.30/lib coreutils-8.30/src -name '*.[ch]' -exec cat {} + | wc -l
217752
Nicolas George <nicolas$george@salle-s.org> wrote:
Rainer Weikusat , dans le message
<87zgiwurww.fsf@doppelsaurus.mobileactivedefense.com>, a écrit :
The systemd-242 that's part of Debian 10 has 444,451 lines of
code. Anybody who seriously claims that a C program of this size is
"probably correct" and "more likely to be correct" than a much smaller
shell scripts is seriously deluded, not the least because the two
statements contradict each other.
How many lines of C code in the shell interpreter and core utilities
necessary to run the shell scripts?
$ find coreutils-8.30/lib coreutils-8.30/src -name '*.[ch]' -exec cat {} + | wc -l
217752
$ find dash-0.5.10.2/src -name '*.[ch]' -exec cat {} + | wc -l
18963
The need for coreutils and the shell doesn't go away with systemd, though.
So it's not either/or; it's and.
muttley@dastardlyhq.com writes:
Rainer Weikusat <rweikusat@talktalk.net> wrote:
muttley@dastardlyhq.com writes:
On Tue, 31 May 2022 20:36:53 -0000 (UTC)
Kaz Kylheku <480-992-1380@kylheku.com> wrote:
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!
You mean like what comes with systemd? rc shell scripts are by their
nature fairly simple and linear and can be grokked in minutes. Good luck >>>> doing that with the systemd source code.
Ehh ... real-world distro init.d scripts are every-growing tumour-like >>>entities. Eg, the system I'm using to write this has 83 of them.
Why's that a bad thing? Would you prefer one huge script that did everything?
My /bin directory alone has 209 utils in it. Should I exchange them all for >> BusyBox?
I didn't claim this (the number of scripts) was a bad thing, I just
provided it as necessary part of the other statistics.
avg length 125.49 lines
median 84
Seems perfectly reasonable to me.
That's because you've deleted everything which openly contradicts your >"simple and linear and can be grokked in minutes" claim.
Rainer Weikusat <rweikusat@talktalk.net> wrote:
Ehh ... real-world distro init.d scripts are every-growing tumour-like >>>>entities. Eg, the system I'm using to write this has 83 of them.
Why's that a bad thing? Would you prefer one huge script that did everything?
My /bin directory alone has 209 utils in it. Should I exchange them all for >>> BusyBox?
I didn't claim this (the number of scripts) was a bad thing, I just >>provided it as necessary part of the other statistics.
avg length 125.49 lines
median 84
Seems perfectly reasonable to me.
That's because you've deleted everything which openly contradicts your >>"simple and linear and can be grokked in minutes" claim.
Are you suggesting you'd have trouble understanding a 100 line shell
script?
Let's make it clear; systemd (or something like it) is necessary and
that is why distros bundle it and use it.
(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.)
On 2022-05-30, Kaz Kylheku <480-992-1380@kylheku.com> wrote:
Let's make it clear; systemd (or something like it) is necessary and
that is why distros bundle it and use it.
[citation needed]
(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.)
I'll have my scattered shell scripts thank you very much.
Look. The requirements of distributions do not necessarilly align with
the requirements of users. I'm sure random init scripts are tough for distributions to automatically manage, but I as a user, don't care about that. I care about how easy it is for me to manually understand and
manage the boot process. And for me a bunch of simple shell scripts
running in pre-determined order due to runlevel changes are
*significantly* easier to understand and maintain, and as others
mentioned, much more flexible to boot.
It's the same story with the proliferation of breaking a simple
configuration file into a .d subdirectory with a bilion random config snippets. It's all to make it easier for automated tools to manage, but
it's definitely much harder for users to manage manually (unless of
course it happens to be really humongous, which it usually isn't...).
On 2022-05-30, Kaz Kylheku <480-992-1380@kylheku.com> wrote:
Let's make it clear; systemd (or something like it) is necessary and
that is why distros bundle it and use it.
[citation needed]
(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.)
I'll have my scattered shell scripts thank you very much.
On 02 Jun 2022 20:47:17 GMT, John Tsiombikas wrote:
On 2022-05-30, Kaz Kylheku <480-992-1380@kylheku.com> wrote:
Let's make it clear; systemd (or something like it) is necessary and
that is why distros bundle it and use it.
[citation needed]
(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.)
I'll have my scattered shell scripts thank you very much.
Look. The requirements of distributions do not necessarilly align with
the requirements of users. I'm sure random init scripts are tough for
distributions to automatically manage, but I as a user, don't care about
that. I care about how easy it is for me to manually understand and
manage the boot process. And for me a bunch of simple shell scripts
running in pre-determined order due to runlevel changes are
*significantly* easier to understand and maintain, and as others
mentioned, much more flexible to boot.
It's the same story with the proliferation of breaking a simple
configuration file into a .d subdirectory with a bilion random config
snippets. It's all to make it easier for automated tools to manage, but
it's definitely much harder for users to manage manually (unless of
course it happens to be really humongous, which it usually isn't...).
First off, I am no fan of systemd. BUT it is here to stay so learn to work with it.
run the following:
systemd-analyze plot > /var/tmp/blame.svg
firefox /var/tmp/blame.svg &
Makes it dead easy to see what is dependent on who and how long it takes
for something to complete initialization. There are lots of shell init scripts.
Use "systemctl status whatever.unit_name_here" to get what is executed to
see what actually is executed to start it.
The drop-in directory is a very nice method for users/sys admins to
make their configuration changes verses an app configuration file.
Bit Twister <BitTwister@mouse-potato.com> wrote:
On 02 Jun 2022 20:47:17 GMT, John Tsiombikas wrote:
On 2022-05-30, Kaz Kylheku <480-992-1380@kylheku.com> wrote:
Let's make it clear; systemd (or something like it) is necessary and
that is why distros bundle it and use it.
[citation needed]
(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.)
I'll have my scattered shell scripts thank you very much.
Look. The requirements of distributions do not necessarilly align with
the requirements of users. I'm sure random init scripts are tough for
distributions to automatically manage, but I as a user, don't care about >>> that. I care about how easy it is for me to manually understand and
manage the boot process. And for me a bunch of simple shell scripts
running in pre-determined order due to runlevel changes are
*significantly* easier to understand and maintain, and as others
mentioned, much more flexible to boot.
It's the same story with the proliferation of breaking a simple
configuration file into a .d subdirectory with a bilion random config
snippets. It's all to make it easier for automated tools to manage, but
it's definitely much harder for users to manage manually (unless of
course it happens to be really humongous, which it usually isn't...).
First off, I am no fan of systemd. BUT it is here to stay so learn to work >> with it.
run the following:
systemd-analyze plot > /var/tmp/blame.svg
firefox /var/tmp/blame.svg &
Makes it dead easy to see what is dependent on who and how long it takes
for something to complete initialization. There are lots of shell init scripts.
Use "systemctl status whatever.unit_name_here" to get what is executed to
see what actually is executed to start it.
Dead easy may be a stretch. It's extremely useful, but there are caveats.
1) Service restarts aren't shown in those plots; only the most recent run.
(And possibly failures, if they're not persistent.) On several occassions this has hidden or obscured problems.
2) You cannot reliably detect dependency conflicts. When working on the Packer build for a baseline OS image at a previous job I tried to comprehensively write ordering assertions, Depends checks, etc, in the provisioning scripts. But they proved unreliable, and issues still often
made it through the CI/CD pipeline. systemd can sometimes detect and report on these issues, but not always, and it lacks some necessary functionality for enforcing strict correctness or comprehensively analyzing correctness.
The drop-in directory is a very nice method for users/sys admins to
make their configuration changes verses an app configuration file.
Yes, it's nice. But some directives are additive (e.g. Depends) while others override prior directives, and there's no way to change the behavior. If you want to replace dependency sets, you need to remove the original unit file(s).
Muttley@dastardlyhq.com writes:
Rainer Weikusat <rweikusat@talktalk.net> wrote:
[...]
Ehh ... real-world distro init.d scripts are every-growing tumour-like >>>>>entities. Eg, the system I'm using to write this has 83 of them.
Why's that a bad thing? Would you prefer one huge script that did >everything?
My /bin directory alone has 209 utils in it. Should I exchange them all for
BusyBox?
I didn't claim this (the number of scripts) was a bad thing, I just >>>provided it as necessary part of the other statistics.
avg length 125.49 lines
median 84
Seems perfectly reasonable to me.
That's because you've deleted everything which openly contradicts your >>>"simple and linear and can be grokked in minutes" claim.
Are you suggesting you'd have trouble understanding a 100 line shell
script?
Let me put it this way: I'm not the person who recently posted that the
only way to handle a bug in systemd would be to complain to its author.
But that's completely besides the point:
You wrote that init.d scripts would be "simple and linear and can be
grokked in minutes" and this claim is wrong. Some are. And some others
are not.
Muttley@dastardlyhq.com writes:
The vast majority are and anyone with even a passing knowledge of shell >script
can understand them. Most admins still struggle with systemd and only know >> a few sections of it well.
About 60% are. Whether or not that's a vast majority is open to anyone's >opinion. Someone who has only a passing knowledge of some programming >language will be hard pressed to understand anything but the most
trivial code written in it. In a Suse init.d script, I once encountered a >comment complaining about the need to work around a bug in another Suse >init.d script. Fixing the bug instead apparently never crossed the mind
of the author of the comment.
It's perfectly possible to keep init.d scripts simple and thus, easily >modifiable. But that's something Linux distributors were never good at.
On Thu, 02 Jun 2022 18:51:32 +0100
Rainer Weikusat <rweikusat@talktalk.net> wrote:
Let me put it this way: I'm not the person who recently posted that the >>only way to handle a bug in systemd would be to complain to its author.
Turn of phrase. Systemd bugs get fixed slowly if at all on the main
tree.
You wrote that init.d scripts would be "simple and linear and can be >>grokked in minutes" and this claim is wrong. Some are. And some others
are not.
The vast majority are and anyone with even a passing knowledge of shell script
can understand them. Most admins still struggle with systemd and only know
a few sections of it well.
John Tsiombikas <nuclear@member.fsf.org> wrote:
On 2022-05-30, Kaz Kylheku <480-992-1380@kylheku.com> wrote:
Let's make it clear; systemd (or something like it) is necessary and
that is why distros bundle it and use it.
[citation needed]
(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.)
I'll have my scattered shell scripts thank you very much.
Shell scripts cannot fix bad process management in the daemons themselves.
So either process management in the daemons needs to be comprehensively
fixed and maintained (see OpenBSD), or it needs to be removed, in which case you still need infrastructure such as daemontools or systemd to juggle processes.
If I had more time and motivation I might try to implement a different compromise: introducing more sophisticated process management primitives directly into the shell. Job management is, afterall, a core competency of the shell, and despite it's innumerable problems it still excels relative to other languages, at least for the simple stuff.
Success might still be contingent on fixing and complementing existing
kernel facilities, especially if you want to achieve correctness without centralizing everything under, e.g., PID 1 init. (For example, process descriptor semantics and interfaces might not be improved.) Even systemd still falls short of semantic correctness as it's still technically susceptible to some of the same races as traditional PID files.
On 02 Jun 2022 20:47:17 GMT, John Tsiombikas wrote:
On 2022-05-30, Kaz Kylheku <480-992-1380@kylheku.com> wrote:
Let's make it clear; systemd (or something like it) is necessary and
that is why distros bundle it and use it.
[citation needed]
(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.)
I'll have my scattered shell scripts thank you very much.
Look. The requirements of distributions do not necessarilly align with
the requirements of users. I'm sure random init scripts are tough for
distributions to automatically manage, but I as a user, don't care about
that. I care about how easy it is for me to manually understand and
manage the boot process. And for me a bunch of simple shell scripts
running in pre-determined order due to runlevel changes are
*significantly* easier to understand and maintain, and as others
mentioned, much more flexible to boot.
It's the same story with the proliferation of breaking a simple
configuration file into a .d subdirectory with a bilion random config
snippets. It's all to make it easier for automated tools to manage, but
it's definitely much harder for users to manage manually (unless of
course it happens to be really humongous, which it usually isn't...).
First off, I am no fan of systemd. BUT it is here to stay so learn to work with it.
First off, I am no fan of systemd. BUT it is here to stay so learn to work with it.
On 2022-06-02, Bit Twister <BitTwister@mouse-potato.com> wrote:
First off, I am no fan of systemd. BUT it is here to stay so learn to work >> with it.
The beauty of UNIX, and even more so of free software, is that I don't
have to. I can choose to never run systemd on my computers and that's
what I intend to do. No need to learn to work with shitty programs.
complicated programs to solve simple problems and those who strive to
create simple programs to solve complicated problems. The members of the >first group are much more admired than the members of the second.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 308 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 91:33:19 |
| Calls: | 6,923 |
| Calls today: | 1 |
| Files: | 12,382 |
| Messages: | 5,434,029 |