They did a good job

Posted Sep 18, 2015 2:15 UTC (Fri) by dlang (guest, #313)
In reply to: They did a good job by mchapman
Parent article: How Debian managed the systemd transition

you should read Ingo's comments from the kernel qotw http://lwn.net/Articles/657428/

it's worth going and reading his full post.

This attitude of "well, if we broke it, it was wrong anyway" is part of the reason people distrust the systemd folks so much.

They did a good job

Posted Sep 18, 2015 4:17 UTC (Fri) by mchapman (subscriber, #66589) [Link]

> you should read Ingo's comments from the kernel qotw http://lwn.net/Articles/657428/

I said it was "logical", not that it was right. :-)

They did a good job

Posted Sep 18, 2015 10:41 UTC (Fri) by MarcB (subscriber, #101804) [Link]

There is a significant difference between ABI/API and the internal behaviour of system components. The first is supposed to be stable (or not, depending on the project), the second is only supposed to be documented and it must be sane (much more so than an ABI, where you can - at a cost - work around insanity).

There explicitly is no stability guarantee in the latter case (as evidenced by every major distribution's release notes). If you do a major upgrade - if your distribution supports that at all - you have to read the release notes, understand them and perform any extra steps that apply to your system. This has always been the deal.
(And not only that, you also have to read the changelog of every major library you use out of the distribution's repo, or have very good testing in place - that is the real effort.)

Of course, individual users might have gotten away without doing that in the past. They were lucky.

Just to make this clear: Had Debian made such a change within the life-cycle of a distribution, I would have been really annoyed.
But during a major upgrade I expect things like that. And for me, this particular change is more than welcome. Aborting the boot on errors is the only sane thing to do. The init system cannot know and understand the filesystems and simply ignoring the errors can lead to anything, while erroring out always leads to the same thing: A very clear and very visible error that should be caught by even the most simple monitoring.

They did a good job

Posted Sep 18, 2015 14:01 UTC (Fri) by deater (subscriber, #11746) [Link]

> you should read Ingo's comments from the kernel qotw

I thought that qotw was posted ironically due to the number of times his projects have broken various ABIs.

They did a good job

Posted Sep 18, 2015 19:08 UTC (Fri) by davidstrauss (guest, #85867) [Link] (6 responses)

> This attitude of "well, if we broke it, it was wrong anyway" is part of the reason people distrust the systemd folks so much.

systemd may have a default and an opinion, but it was Debian's prior, unusual default that created this divergence. If you're Saab -- with a long history of having the ignition in the center console -- and switch to stock parts, it is not the fault of the stock steering column manufacturer that ignition is now in a different place than you had put it before.

Also, Debian could have chosen to configure the post-upgrade system to carry over "nofail," but they didn't. It's not like systemd forces you to have mounts fail hard. Complain to the Debian maintainers if you don't like the way they're choosing to configure systemd.

They did a good job

Posted Sep 26, 2015 10:22 UTC (Sat) by rleigh (guest, #14622) [Link] (5 responses)

It wasn't an "unusual default". It had behaved this way for ~20 years and was the intended and expected behaviour for a Debian system.

They did a good job

Posted Sep 26, 2015 11:16 UTC (Sat) by zdzichu (subscriber, #17118) [Link] (4 responses)

Could you show where it was documented to behave that way?

They did a good job

Posted Oct 9, 2015 22:49 UTC (Fri) by nix (subscriber, #2304) [Link] (3 responses)

You're saying that only documented behaviour needs to be preserved? That users are expected to read *all* the documentation that applies to every little part of their system, and if they don't, it's their own damn fault for being annoyed when something that turns out not to have been documented randomly changes behaviour and breaks things?

This is a very legalistic (read, unhelpful) way to make a system. It's a way to make a system that, to be blunt, doesn't work very well.

They did a good job

Posted Oct 10, 2015 9:24 UTC (Sat) by zdzichu (subscriber, #17118) [Link] (2 responses)

If it's not documented, how can it be "intended"? How can you judge if the behavior is correct and it is not a bug? See also encrypted swap support in article – it was another bug exposed by systemd.

They did a good job

Posted Oct 10, 2015 9:49 UTC (Sat) by cebewee (guest, #94775) [Link] (1 responses)

A behavior does not need to be "intended" to be relied upon. It suffices if this behavior is consistently exposed. Then a change has a high chance of breaking user expectations. Quoting dlang's comment:

> you should read Ingo's comments from the kernel qotw http://lwn.net/Articles/657428/

Now, there are of course cases where breaking changes are justified (and I won't judge whether this was the case here), but you cannot blame people for being upset when said changes break their system.

They did a good job

Posted Oct 11, 2015 0:15 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

One of systemd's goals is to make a layer for Linux that can be depended upon. Minor differences like this are the "death by 1000 papercuts" that makes cross-distro deployment a pain. Breaking every other distro in the same way Debian has for years is certainly not the better solution here. More docs would have been better. Even better would be some check in the updater about possible semantic changes in /etc/fstab entries.