I asked which patches have been rejected, not what those (so far not revealed) patches were supposed to be for. The claim was that the systemd team have rejected patches, but so far nobody has given any link or reference to any such patch.
Stop lying and pretending you do not exactly know what this is about. At that point we can have a civil exchange. At the moment you are simply an _enemy_
I am, of course, the enemy of all lying toads.
I have no interest in having a "civil exchange" with lying toads.
What is this "about", lying toad, tell us, stop beating around the bush.
It throttles for the same reason rsyslogd (for example) throttles -- to avoid overloading the system.
The throttling is done per service, so what did you lose when some process decided to log more than 1000 messages in a 30 second period (the default).
Personally I can see a couple of ways to fix things a bit -- it should be possible to set per service throttling parameters and throttling should take message priority into account.
(By the way -- the rsyslogd throttling might not even work -- syslog is usually used over a datagram transport, so packets may be silently dropped by the kernel if it wants to).
I've seen multiple good reproduction steps that demonstrate this problem over the past few years, and it's still broken.
I've seen them too. And in every case they are fixed by fixing the broken scripts or configuration files that cause them. I've never seen one that was caused by a bug in systemd.
Since the Debian community's leaders were pretty well split on whether they should adopt systemd,
Not really "pretty well split":
The Technical committee had 8 members.
Just taking the first preferences of the members four wanted systemd, two wanted upstart and two wanted further discussion.
Debian's voting system being somewhat more complicated than almost any other on earth it ended up as a tie between systemd and upstart (only one person didn't put sysvinit as the last or next to last choice). The chair of the committee cast his tie breaker for systemd.
How many times have you actually had a problem due to sysvinit itself failing?
What do you mean by "sysvinit itself"? If you mean init(1) and the core scripts (/etc/rc1 and so on), never. init scripts from packages, quite a few times, sometimes leading to unbootable systems, sometimes to booted but useless systems (no network, missing services).
The most recent sysvinit problem was poor dependency handling, leading to failure to mount NFS volumes on boot. That was a pain to fix.
My big problem with systemd is that it fails to do simple jobs that init did just fine, like mounting NFS shares on boot. Never had a problem with it in the past
Lucky you, I've spend days trying to debug NFS mount on boot dependency problems with sysvinit.
sysvinit needed to be deprecated. And it was, most distributions were moving away from it because it no longer worked, but none of the replacements were particularly great either.
That is a lie, and you are a liar. sysvinit still works fine,
What is a lie? That RedHat and Ubuntu had already moved away from sysvinit? That Arch Linux moved to systemd in 2012? That Debian was weighing up the possible alternatives with their usual glacial pace?
As for "sysvinit still works fine" -- sysvinit has been a piece of shit since the first time I saw it, back in 1990.
systemd has no site dependent configuration outside of/etc.
The files installed in/usr/lib/systemd by packages are not supposed to be modified by the sysadmin -- that's what/etc/systemd is for, putting things that override the distro defaults.
Second, if you think running easily-understood scripts in a well-defined, obvious order
Bwhahahahahaha!
There are 9492 lines of scripts in/etc/init.d on one very simple system I sysadmin. Those scripts source an extra 920 lines of library scripts. The "obvious order" comes from the LSB headers at the top of the scripts (Hey, boogie on like it's 2005, fixed order boot is so dead).
Even that is ignoring the fact that the scripts are full of calls to such clear and simple things as "start-stop-daemon".
Whatever form of logging there is, systemd makes debugging really hard. It doesn't seem to suck up STDOUT/STDERR when you really need it to, it doesn't seem to tell you the command it ran that it thought had failed when you want it to, it doesn't give you the response code, it doesn't tell you why it considered it failed,
Crap.
Every single one of these assertions is purest bollocks.
My init.d was about 13 scripts big which were readable and editable.
What distro was that? With what services.
My boring old Debian Squeeze has 79 scripts in init.d
Hell, my Debian Squeeze (with systemd) has 42!
Also, what's the big deal with "editable"? systemd unit files are editable. More "binary" fud?
Remove/fail a hard drive and your system will boot into single user mode, not even remote access will be available so you better be near the machine just because it was in fstab and apparently everything in fstab is a hard dependency on systemd.
"apparently everything in fstab is a hard dependency on systemd." -- no, only things marked as a hard dependency will force that.
It's pretty easy to arrange that "near" be "anywhere closer than LEO" on any recent system or anything in any decent hosting facility.
Slashdot Mirror
I asked which patches have been rejected, not what those (so far not revealed) patches were supposed to be for. The claim was that the systemd team have rejected patches, but so far nobody has given any link or reference to any such patch.
Twat.
Stop lying and pretending you do not exactly know what this is about. At that point we can have a civil exchange. At the moment you are simply an _enemy_
I am, of course, the enemy of all lying toads.
I have no interest in having a "civil exchange" with lying toads.
What is this "about", lying toad, tell us, stop beating around the bush.
It throttles for the same reason rsyslogd (for example) throttles -- to avoid overloading the system.
The throttling is done per service, so what did you lose when some process decided to log more than 1000 messages in a 30 second period (the default).
Personally I can see a couple of ways to fix things a bit -- it should be possible to set per service throttling parameters and throttling should take message priority into account.
(By the way -- the rsyslogd throttling might not even work -- syslog is usually used over a datagram transport, so packets may be silently dropped by the kernel if it wants to).
I bet writing crap like that is the only thing that gets you hard.
Especially when there are a lot of events being logged;
So what do you have your journald throttling options set at?
I've seen multiple good reproduction steps that demonstrate this problem over the past few years, and it's still broken.
I've seen them too. And in every case they are fixed by fixing the broken scripts or configuration files that cause them. I've never seen one that was caused by a bug in systemd.
Who'da thunk it -- fake gold has the same problem that make it a bad basis for a currency that real gold has.
Not to mention how to use non-unicode apostrophes. "â(TM)" indeed,
Since the Debian community's leaders were pretty well split on whether they should adopt systemd,
Not really "pretty well split":
The Technical committee had 8 members.
Just taking the first preferences of the members four wanted systemd, two wanted upstart and two wanted further discussion.
Debian's voting system being somewhat more complicated than almost any other on earth it ended up as a tie between systemd and upstart (only one person didn't put sysvinit as the last or next to last choice). The chair of the committee cast his tie breaker for systemd.
The gory details are publicly available here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#6729
why isn't the logical thing for Debian to do to simply provide both options?
I am getting fucking bored of saying this, so I will shout: Debian DOES provide both options!
An appeal to authority is only a logical fallacy if the authority is not really an authority.
How many times have you actually had a problem due to sysvinit itself failing?
What do you mean by "sysvinit itself"? If you mean init(1) and the core scripts (/etc/rc1 and so on), never. init scripts from packages, quite a few times, sometimes leading to unbootable systems, sometimes to booted but useless systems (no network, missing services).
The most recent sysvinit problem was poor dependency handling, leading to failure to mount NFS volumes on boot. That was a pain to fix.
systemd still has more bugs than sysvinit?
Uh, in my world 272 is a smaller number than 383. It isn't the same where you come from?
By the way, you may think Lennart Poettering is the Devil himself, but he isn't a Debian developer, so can't close bugs at bugs.debian.org.
No. I didn't change anything.
Oh yes you did. You said:
/use ought to not even need backups because everything there is supposed to be installed and never hand edited
I pointed out that that was exactly the case with systemd and now you've changed the claim to:
No configs, editable or otherwise, should exist outside /etc.
with exactly zero justification.
My big problem with systemd is that it fails to do simple jobs that init did just fine, like mounting NFS shares on boot. Never had a problem with it in the past
Lucky you, I've spend days trying to debug NFS mount on boot dependency problems with sysvinit.
sysvinit needed to be deprecated. And it was, most distributions were moving away from it because it no longer worked, but none of the replacements were particularly great either.
That is a lie, and you are a liar. sysvinit still works fine,
What is a lie? That RedHat and Ubuntu had already moved away from sysvinit? That Arch Linux moved to systemd in 2012? That Debian was weighing up the possible alternatives with their usual glacial pace?
As for "sysvinit still works fine" -- sysvinit has been a piece of shit since the first time I saw it, back in 1990.
Great groaning sound as the goalposts are shifted.
You're changing "Config outside /etc is a major deal" to "Config outside /etc/default is a major deal" now?
Are you unable to admit that one of your complaints about systemd, which you described as "a major deal" was simply wrong?
If "service xyzzy restart" doesn't work then "systemctl restart xyzzy" wouldn't work either -- they're literally the same thing.
(/usr/sbin/service is, on Debian, a big shell script that ends up calling systemctl if pid 1 is systemd).
If someone decided to build a house out of cardboard
...
https://www.sciencealert.com/t...
Config outside /etc is a major deal
It's also a major misunderstanding of systemd.
systemd has no site dependent configuration outside of /etc.
The files installed in /usr/lib/systemd by packages are not supposed to be modified by the sysadmin -- that's what /etc/systemd is for, putting things that override the distro defaults.
Second, if you think running easily-understood scripts in a well-defined, obvious order
Bwhahahahahaha!
There are 9492 lines of scripts in /etc/init.d on one very simple system I sysadmin. Those scripts source an extra 920 lines of library scripts. The "obvious order" comes from the LSB headers at the top of the scripts (Hey, boogie on like it's 2005, fixed order boot is so dead).
Even that is ignoring the fact that the scripts are full of calls to such clear and simple things as "start-stop-daemon".
he's an arrogant fool with an overrated sense of his own abilitiies
Says the random leet hakk3r with the handle "Viol8".
Plug a network stream into init(1)? What?
Whatever form of logging there is, systemd makes debugging really hard. It doesn't seem to suck up STDOUT/STDERR when you really need it to, it doesn't seem to tell you the command it ran that it thought had failed when you want it to, it doesn't give you the response code, it doesn't tell you why it considered it failed,
Crap.
Every single one of these assertions is purest bollocks.
My init.d was about 13 scripts big which were readable and editable.
What distro was that? With what services.
My boring old Debian Squeeze has 79 scripts in init.d
Hell, my Debian Squeeze (with systemd) has 42!
Also, what's the big deal with "editable"? systemd unit files are editable. More "binary" fud?
Remove/fail a hard drive and your system will boot into single user mode, not even remote access will be available so you better be near the machine just because it was in fstab and apparently everything in fstab is a hard dependency on systemd.
"apparently everything in fstab is a hard dependency on systemd." -- no, only things marked as a hard dependency will force that.
It's pretty easy to arrange that "near" be "anywhere closer than LEO" on any recent system or anything in any decent hosting facility.
Yes you are.