3 ms·
I really don't think that often hated "Not my problem" kind of answers Pottering gives are that unprofessional, because in 99% of cases, he points to exact part
by adontz 8y ago
I really don't think that often hated "Not my problem" kind of answers Pottering gives are that unprofessional, because in 99% of cases, he points to exact party who's problem it is and mostly they are distribution maintainers, which makes sense.
- Karunamon 8y agoExcept, defaults matter. If you ship something that violates decades of well-known behavior, it is at least very unfair (and probably a lot of other unpleasant adjectives) to expect downstream to enable the —suck-less flag to restore the expected behavior. The friendly and not bull-headed thing to have done was to ship the new behavior, but enable the compatibility flag by default, rather than expect other people to clean up after systemd's messes. This mentality is the main reason bag on systemd all the time. If systemd does something to annoy you, it is automatically your fault for doing something Wrong or not enabling some obscure config file option. It's never systemd's fault when systemd unilaterally violates the principle of least surprise.
- adontz 8y ago>> Except, defaults matter. Do they? Debian maintains hella lot of patches for almost every package because of reasons I can hardly justify. Overriding a few systemd config files is nothing. But let's say systemd sets some sane defaults and everyone happy. Or are they? Like, for instance default NTP is "centos.pool.ntp.org". Oh, crap, Debian still can't use it.