Lennart: The State & Future Of Systemd

[Nille]

First they start FUD campain about upstart being bad bad bad

Upstart disqualified himself with a CLA.

[interested]

First they start FUD campain about upstart being bad bad bad, because it fails to unmount partitions on reboot and that systemd magically solves this problem, but they still have this bug open that is not supposed to happen with almighty systemd for almost a year now:

https://bugzilla.redhat.com/show_bug.cgi?id=1026119

At the same time their hobby is to introduce bugs and then refuse to fix them, blaming anyone, but themselves.

First, it is an objective fact that Upstart doesn't solve some major and fundamental problems with init systems on Linux.
Its inventor and lead developer for years, Scott James Remnant, even said so.You know, there actually is such a thing as legitimate technical criticism.

But I find it funny that you complain about FUD campaigns, and then immediately start one where you insinuate that systemd developers actually _refuse_ to fix bugs. Are you sure that you aren't lying through your teeth when making such claims?

Besides that, the bug you are linking to has been fixed for a very long time, just look into your F20 journal. Notice that the bug was quite trivial, the mount points got unmounted, it was just that systemd complained about not being able to do so in a "nice" manner since a process was keeping the mount busy.

That sort of thing was simple the order of the day with SysVinit that simply issued a "killall" at some point in the shutdown process. The difference is simply that systemd usually can avoid such brutal process genocide and is actually able to report it when a process is hogging a mount point.

[Stellarwind]

Upstart disqualified himself with a CLA.

I was talking about this: https://plus.google.com/+LennartPoet...ts/LjkLwkeDiLc
I'm not advocating for upstart actually, point is neither can deal with complex fs setups, but Lennart used it as a reason why systemd better.

[Stellarwind]

But I find it funny that you complain about FUD campaigns, and then immediately start one where you insinuate that systemd developers actually _refuse_ to fix bugs. Are you sure that you aren't lying through your teeth when making such claims?

Not that ridiculous, one certain kernel developer agrees: http://www.phoronix.com/scan.php?pag...tem&px=MTY1MzA
There was more like this, that is not something uncommon.

Besides that, the bug you are linking to has been fixed for a very long time, just look into your F20 journal. Notice that the bug was quite trivial, the mount points got unmounted, it was just that systemd complained about not being able to do so in a "nice" manner since a process was keeping the mount busy.

Did you actually looked at bug report? Comment 7 is few days old and says "I can still reproduce with latest F20 including all updates."

[interested]

Not that ridiculous, one certain kernel developer agrees: http://www.phoronix.com/scan.php?pag...tem&px=MTY1MzA
There was more like this, that is not something uncommon.

Again, that keyword issue was actually fixed, and pretty quick too. I have no idea why you take that as an example on systemd developers refusing to fix bugs. It simply wasn't the issue.

Did you actually looked at bug report? Comment 7 is few days old and says "I can still reproduce with latest F20 including all updates."

Let me explain again. This bug isn't about systemd unmounting code, it is all about daemons and processes that are hogging the mount points when systemd shuts down. The mount points still gets unmounted in a clean way (the Upstart criticism was that you risked _unclean_ unmounts). systemd is just reporting this, it doesn't cause the problems. There will continue to be reports about such "failed unmounts" until the _daemons_ and their .service files have been debugged.

On older script based init systems such behaviour usually went unnoticed. With systemd you actually have a chance of finding and fixing such minor bugs.

Again, your totally bizarre accusations that systemd developers make it "their hobby is to introduce bugs and then refuse to fix them" simply isn't supported by any facts and those random links you use.

[Stellarwind]

Again, that keyword issue was actually fixed, and pretty quick too. I have no idea why you take that as an example on systemd developers refusing to fix bugs. It simply wasn't the issue.

Not until kernel devs yelled at them and proposed a patch to hide debug from systemd completely.
There was another: http://lwn.net/Articles/518942/
lklm is down atm, so can't link to actual discussion.

The mount points still gets unmounted in a clean way (the Upstart criticism was that you risked _unclean_ unmounts). systemd is just reporting this, it doesn't cause the problems. There will continue to be reports about such "failed unmounts" until the _daemons_ and their .service files have been debugged.

That is not what the bug says: "As a result to this bug fsck runs on every boot."

[interested]

Not until kernel devs yelled at them and proposed a patch to hide debug from systemd completely.
There was another: http://lwn.net/Articles/518942/
lklm is down atm, so can't link to actual discussion.

Remember that you claimed that systemd developers introduced such bugs as a hobby and then _refused_ to fix them. Now you say that they actually fixed them. Do you retract your ridiculously claim now or what?

That is not what the bug says: "As a result to this bug fsck runs on every boot."

systemd-fsck runs on every boot. Again, the difference is that Upstart because of its design always had an inherent risk of FS corruption, systemd hasn't.

In fact systemd has the most superior init and mounting behaviour of all init-systems on Linux: better than Upstart, better than OpenRC, better than SysVinit.

[Stellarwind]

Remember that you claimed that systemd developers introduced such bugs as a hobby and then _refused_ to fix them. Now you say that they actually fixed them. Do you retract your ridiculously claim now or what?

"Hobby" was a sarcasm, since you still don't get it, too bad for you.
As for refusing - they still use kernel commandline "debug" while it doesn't make any sense, bug marked as fixed doesn't mean they changed their stupid behavoiur, just that it doesn't hang the system anymore. Again, that udev issue was fixed by Linus, Kay Sievers was too stubborn to admit a bug. This all lead to Linus asking Greg to not accept any patches from systemd devs upstream.
If this qualifies as normal for you, too bad.

systemd-fsck runs on every boot. Again, the difference is that Upstart because of its design always had an inherent risk of FS corruption, systemd hasn't.
In fact systemd has the most superior init and mounting behaviour of all init-systems on Linux: better than Upstart, better than OpenRC, better than SysVinit.

There is no point running it if everything is ok, fsck is clearly triggered by unclean unmount in that case.

Your fanboy arguments are beyond any hope.

[interested]

"Hobby" was a sarcasm, since you still don't get it, too bad for you.

If it is sarcasm, does that mean you didn't mean what you said? To phrase it otherwise, you don't actually mean what you say, so you don't mean that systemd developers actually make it their hobby to introduce bugs. But then what did you actually try to say? Please explain what your sarcasm meant, otherwise it just looks like you are using it as excuse to run away from what you said.

As for refusing - they still use kernel commandline "debug" while it doesn't make any sense, bug marked as fixed doesn't mean they changed their stupid behavoiur, just that it doesn't hang the system anymore. Again, that udev issue was fixed by Linus, Kay Sievers was too stubborn to admit a bug. This all lead to Linus asking Greg to not accept any patches from systemd devs upstream.
If this qualifies as normal for you, too bad.

Again I find no evidence whatsoever for your claim that systemd developers refuse to fix a bug. Sure there was disagreement who was to blame or whether it was a bug or not (AFAIK, the problem with the system hanging was actually because the kernel doesn't rate limit its debug messages), but that happens all the time. The end result was Linus was right (he is always right, even when wrong on final matters of the kernel), and the problem was fixed to Linus' liking.

Again, no evidence what so ever for your claim that systemd developers refuse to fix bugs. Oh, or was that statement sarcasm too, (e.g. a lie!)?

There is no point running it if everything is ok, fsck is clearly triggered by unclean unmount in that case.

Your fanboy arguments are beyond any hope.

You simply don't understand the issue with Upstart you where linking to. Did you even try try to read the article, or did you just copy-paste the examples from some random loony systemd-haters on-line rant? (you certainly don't seem to be a Fedora user despite linking to its bugzilla).

The fact is that Upstart had inherent problems with dirty FS because it couldn't handle updated libs etc. Everything is explained in Lennart's article. Even Upstart developers knew that fact. Systemd doesn't suffer from such inherent problems. That doesn't mean it can prevent a FS from being marked dirty if a process has files open when a mount point is being unmounted, but that isn't an inherent bug in systemd but in the service. So you are simply wrong in your insinuations.

In fact, systemd really have some really nifty features for dealing with services that require complex un-mounting procedures, like any FS component running in user space, because it can use eg. initrd to help shut down. No other Linux init system has such advanced features.

Again, systemd's technical superiority to anything else out there is why Linux is doing a wholesale conversion to it.

[johnc]

I was talking about this: https://plus.google.com/+LennartPoet...ts/LjkLwkeDiLc

It's amazing what a douchebag that guy is.

Kay Sievers too.