|
|
|
|
|
by jraph
1515 days ago
|
|
> There's no need to be politic about this from the POV of systemd I don't think anybody is. It's their technical approach to develop stuff. But sure, their approach has a huge impact on the ecosystem. > we don't allow to run it on legacy systems because it doesn't make sense If I'm to design some piece of software that requires something, that this something is still relatively commonly not there and that I know it won't work without, yes, I'll go ahead, make a check and prevent the program to run in this configuration. Think ./configure which will not write the Makefile if some critical dependency is missing. It's the same thing for me. Anyway, the author did say "it won't work", he didn't say "We went out of our way to prevent the users from trying to do this if we detect an unmerged /usr". I think you read too much into the whole thing. |
|
And this is the political dimension of systemd. One they keep using to shape the ecosystem to their preference.
> If I'm to design some piece of software that requires something,
See that's the point. It doesn't _require_ a merged /usr to work. The benefit of the merged /usr here is that this guarantees to potentially overwrite/extend "all" binaries, not "only" those in a split-/usr. The latter doesn't mean it doesn't work. It just means that they only overwrite one place, not all potential places something exists.