They did a good job [LWN.net]

They did a good job

Posted Sep 18, 2015 19:08 UTC (Fri) by davidstrauss (subscriber, #85867)
In reply to: They did a good job by dlang
Parent article: How Debian managed the systemd transition

> 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.

to post comments

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.