They did a good job [LWN.net]

They did a good job

Posted Sep 26, 2015 11:16 UTC (Sat) by zdzichu (subscriber, #17118)
In reply to: They did a good job by rleigh
Parent article: How Debian managed the systemd transition

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

to post comments

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.