2 ms·

This is most likely the issue in question: https://github.com/systemd/systemd/issues/11436 https://github.com/systemd/systemd/issues/11436 Poettering seems to

This is most likely the issue in question: https://github.com/systemd/systemd/issues/11436 https://github.com/systemd/systemd/issues/11436 Poettering seems to have offered a solution that doesn't break existing installs, but only after the maintainer had already thrown up his hands in frustration.

olliej 8y ago
Huh, so someone broke behavior and decided users were wrong rather than fixing it? :-/ I get maintaining API can be hard[1], but system service devs need to recognize that it’s much more important to maintain shipped API than ideological purity, certainly you can improve the API, but unless an API is actually broken in some way that can’t be automatically worked around it needs to be maintained [2]. Aside from anything else, making installation of updates break user’s systems discouraged installing updates. Including critical security ones. (An example of the terrible security impact of functionally user hostile updates can be found in windows 10) [1] I’ve worked on frameworks with strict ABI compatibility requirements which easily dwarfs the problems of maintains API, and have had to do exciting things to make sure such things continue to work. Another example was back in the early days of .net MS added support for a not quite standardized decimal format. It was used and stored in many projects and applications, but the final spec changed slightly. MS knew it couldn’t break existing data (which is what the effect of adopting the final standard would do), and they were trying to standardize .net so I assume that prevented any kind of defacto standard behaviour. In the end someone at IBM (I think) worked out a way to distinguish the two formats just from the structure of the data. So when people say Maintaining api compat is too hard it annoys me a lot. [2] Linux kernel devs recognize this as well.
Spivak 8y ago
I mean it seems like the solution was accepted after someone suggested it. Can't fault someone for not offering a perfect solution when they didn't think of it. "Revert the code to preserve the previous behavior" is bad because the design is wrong and will be surprising to someone else in two months. "Fix the behavior" is bad because it breaks existing configuration that relied on the broken design. The systemd devs seem to, as a matter of philosophy, prefer breaking things in order to do things right so I think anyone who pays attention to the mailing lists would have called the initial decision from the beginning.

olliej 8y ago

Huh, so someone broke behavior and decided users were wrong rather than fixing it? :-/ I get maintaining API can be hard[1], but system service devs need to recognize that it’s much more important to maintain shipped API than ideological purity, certainly you can improve the API, but unless an API is actually broken in some way that can’t be automatically worked around it needs to be maintained [2]. Aside from anything else, making installation of updates break user’s systems discouraged installing updates. Including critical security ones. (An example of the terrible security impact of functionally user hostile updates can be found in windows 10) [1] I’ve worked on frameworks with strict ABI compatibility requirements which easily dwarfs the problems of maintains API, and have had to do exciting things to make sure such things continue to work. Another example was back in the early days of .net MS added support for a not quite standardized decimal format. It was used and stored in many projects and applications, but the final spec changed slightly. MS knew it couldn’t break existing data (which is what the effect of adopting the final standard would do), and they were trying to standardize .net so I assume that prevented any kind of defacto standard behaviour. In the end someone at IBM (I think) worked out a way to distinguish the two formats just from the structure of the data. So when people say Maintaining api compat is too hard it annoys me a lot. [2] Linux kernel devs recognize this as well.

Spivak 8y ago

I mean it seems like the solution was accepted after someone suggested it. Can't fault someone for not offering a perfect solution when they didn't think of it. "Revert the code to preserve the previous behavior" is bad because the design is wrong and will be surprising to someone else in two months. "Fix the behavior" is bad because it breaks existing configuration that relied on the broken design. The systemd devs seem to, as a matter of philosophy, prefer breaking things in order to do things right so I think anyone who pays attention to the mailing lists would have called the initial decision from the beginning.