15 ms·

It's pretty cool actually that this is possible and I also can't help but think that this is a solution to a problem that need not exist in the first place. Sys

It's pretty cool actually that this is possible and I also can't help but think that this is a solution to a problem that need not exist in the first place. Systemd has this problem and the solution is to use a feature in systemd, right? IMHO systemd has amassed too many features, both documented and undocumented. Having worked with GNU+Linux for over 2 decades, I still find Devuan and Void easier to manage than Fedora and Ubuntu. The latter is fine for basic desktop needs though.

jraph 4y ago
> Systemd has this problem It seems like it is a solution for anything that lives in /usr and could break your system / cannot directly be put there because it's read only when you are developing it. Not systemd-specific though obviously the part that manages the system boot and system services is going to be particularly concerned by this. > IMHO systemd has amassed too many features But systemd is not some monolith that does a lot of things. It's a set of tools that do one thing, well, quite like GNU and that happen to be called systemd-something. Often, thin wrappers around kernel features, like nspawn. I find them very cleanly designed and easy to use. To each there own but I find the possibility to create services declaratively with systemd unit files particularly useful, instead of having to write custom shell scripts and copy paste boilerplate. Upstart was a step in the right direction in this respect. It's not just "fine for basic desktop needs", it's a great fit for desktops and also particularly helpful on servers as well (not speaking about Ubuntu, just systemd).
- ldng 4y ago
  "But systemd is not some monolith" It. Does. Not. Matter. Still to much code in one place. Not enough review and unrelated subproject bitrot at different rate without visibility.
  - lazyier 4y ago
    That is like saying Apache project is subject to not enough review and unrelated subproject bitrot. https://projects.apache.org/projects.html https://projects.apache.org/projects.html or GNU https://directory.fsf.org/wiki/GNU https://directory.fsf.org/wiki/GNU Or FreeBSD or OpenBSD.... Having a single large overall project that manages a diverse number of individual software products is a common pattern and certainly something that isn't remotely unique to Systemd. There is no reason to denigrate systemd for that.
    - ldng 4y ago
      You're making an Apple to Orange comparison here. Your examples are not released to the outside world as a single product "take-it-or-leave-it" and painting it so is borderline bad faith.
      - throwaway82652 4y ago
        Painting systemd in that way is also bad faith, because it's not a single product "take-it-or-leave-it" either. If you think it doesn't have enough review for your purposes then it's time for you to step up and start reviewing, either in systemd or in another project. Part of the reason why people seem to (falsely) think systemd is monolithic is because distros have been historically bad at packaging it and haven't split up the components, but that's been improving over time.
ephaeton 4y ago
I share your opinion, but IMO it also goes one step further: systemd uses its gravity to try and shape linux distributions and dictate how things "ought" to work. Consider this quote from the linked article: > Oh, and in case you wonder, all of this only works with distributions that have completed the /usr/ merge. On legacy distributions that didn't do that and still place parts of /usr/ all over the hierarchy the above won't work, since merging /usr/ trees via overlayfs is pretty pointess if the OS is not hermetic in /usr/.) IOW, if I build a system with yocto for an embedded system, which is also a very useful candidate for a read-only system image installation, I cannot use this feature for this use-case because ... yeah because what. Because lennart says so. This got old so fast.
- jraph 4y ago
  That's fair enough though, isn't it? We can't blame the developers to not support any oddity and particularity that exists… and then blame them because the distribution makers adopt their tools because they work well (as a result?). I'm happy they focus on a standardized base, this results in less development effort focused on more useful stuff, cleaner and more robust tools, it also makes it easy to switch between distributions and to target this standardized base when developing. It also can be seen as a assumed limitation. Any tool has limitations. But the /usr merge has been conducted with reasons, and makes this kind of stuff actually possible. It's not like keeping a split /usr is very useful today anyway. Systemd is not something distributions have to bend to. It's something they willingly adopted because it solves well problems they have. And it's not just Lennart. Hate he gets gets old fast.
  - ephaeton 4y ago
    There's no need to be politic about this from the POV of systemd. "We support this feature on merged /usr" does not have to mean "we don't allow to run it on legacy systems because it doesn't make sense". Look, your users have more fantasy than you do how to use your software. Doesn't mean you have to support it. But it also doesn't mean you have to explicitly enable it only in the setup you envisioned this being used. It's not an _assumed_ limitation. It's an _enforced_ limitation based on a limited world-view that also uses the gravity of the project to enforce the world-view on any user. I'm not arguing pro or against split /usr. Reality though is that for various reasons there are legitimate use-cases for a non-unified directory tree, e.g. embedded ramdisks that contain only the barest of /bin in a crunchgen'd binary that don't want to duplicate stuff that's later used in /usr/bin. Linux is not only desktop and server. systemd is being adopted because it solves problems well the distributors have, but THEN the distributor ALSO has to bend their distribution to the single enforced world-view the systemd folks have if they want it to integrate. They, the distributors, software integrators per se, are just forced to hack out limitations that are imposed by systemd folks for no benefit of either; systemd dev or user. No unified-/usr-user will benefit from this enforced restriction. A split-/usr-user will have to patch systemd and maintain their tree to use this feature if they have a good use-case for it because .. "systemd says so" (if you prefer that over the "B"DFL lennart). Lastly, you are correct in that systemd is a pool of like-minded developers - not only lennart; and this is where I add: - who like to shape the reality out there instead of allowing distributors and users to easily take on their own responsibility easily. Sure, I can fork systemd (it's free software after all), but it's unnecessarily "opinionated" for its broad area of application. And that's where the "politic" dimension of systemd development comes into play ...
vegai_ 4y ago
>Systemd has this problem and the solution is to use a feature in systemd, right? More like systems with an immutable /usr have this problem, and systemd now has a way to circumvent those restrictions when developing. Fedora has been prototyping such systems for quite some time, not exactly with brilliant success so far, but it's good that they're trying.
mtzet 4y ago
> Systemd has this problem How does systemd have a problem? Systemd doesn't care about having a read-only rootfs at all, except that it supports it and now ships a little tool that's useful if you happen to use them. Fedora and Ubuntu doesn't ship a read-only rootfs(1). (1) Well, Fedora Silverblue is an experimental Fedora-variant that uses a read only rootfs. But that point still stands.
cookiengineer 4y ago
I am not sure whether or not you are aware that some might intepret your comment as survivor's bias. Not everybody is a sysadmin, and definitely not everybody wants to do those tedious tasks in /etc. There are so many potential pitfalls of everything around init/initd, especially if downstream integration scripts have to keep up with upstream changes. And I would argue that those should not be the burden of endusers, and also not be the burden of distro maintainers. Providing a settings file that can autolaunch your application in a failsafe manner for all distributions is where systemd shines at, like it or not. While I agree that it isn't perfect and the debugging critiques are kind of valid, I also would argue that this can be solved with better (graphical) tools for the systemd ecosystem. Also: if you assume that debugging a broken shell script (running as root) is easier than systemd, then your perspective is already biased, cause it's a skill set that requires lots of experience. I mean, most shell scripts in /etc/init.d don't even set -e, let alone -u ... and should be considered a risk for system integrity.

jraph 4y ago

> Systemd has this problem It seems like it is a solution for anything that lives in /usr and could break your system / cannot directly be put there because it's read only when you are developing it. Not systemd-specific though obviously the part that manages the system boot and system services is going to be particularly concerned by this. > IMHO systemd has amassed too many features But systemd is not some monolith that does a lot of things. It's a set of tools that do one thing, well, quite like GNU and that happen to be called systemd-something. Often, thin wrappers around kernel features, like nspawn. I find them very cleanly designed and easy to use. To each there own but I find the possibility to create services declaratively with systemd unit files particularly useful, instead of having to write custom shell scripts and copy paste boilerplate. Upstart was a step in the right direction in this respect. It's not just "fine for basic desktop needs", it's a great fit for desktops and also particularly helpful on servers as well (not speaking about Ubuntu, just systemd).

ldng 4y ago
"But systemd is not some monolith" It. Does. Not. Matter. Still to much code in one place. Not enough review and unrelated subproject bitrot at different rate without visibility.
- lazyier 4y ago
  That is like saying Apache project is subject to not enough review and unrelated subproject bitrot. https://projects.apache.org/projects.html https://projects.apache.org/projects.html or GNU https://directory.fsf.org/wiki/GNU https://directory.fsf.org/wiki/GNU Or FreeBSD or OpenBSD.... Having a single large overall project that manages a diverse number of individual software products is a common pattern and certainly something that isn't remotely unique to Systemd. There is no reason to denigrate systemd for that.
  - ldng 4y ago
    You're making an Apple to Orange comparison here. Your examples are not released to the outside world as a single product "take-it-or-leave-it" and painting it so is borderline bad faith.
    - throwaway82652 4y ago
      Painting systemd in that way is also bad faith, because it's not a single product "take-it-or-leave-it" either. If you think it doesn't have enough review for your purposes then it's time for you to step up and start reviewing, either in systemd or in another project. Part of the reason why people seem to (falsely) think systemd is monolithic is because distros have been historically bad at packaging it and haven't split up the components, but that's been improving over time.

ephaeton 4y ago

I share your opinion, but IMO it also goes one step further: systemd uses its gravity to try and shape linux distributions and dictate how things "ought" to work. Consider this quote from the linked article: > Oh, and in case you wonder, all of this only works with distributions that have completed the /usr/ merge. On legacy distributions that didn't do that and still place parts of /usr/ all over the hierarchy the above won't work, since merging /usr/ trees via overlayfs is pretty pointess if the OS is not hermetic in /usr/.) IOW, if I build a system with yocto for an embedded system, which is also a very useful candidate for a read-only system image installation, I cannot use this feature for this use-case because ... yeah because what. Because lennart says so. This got old so fast.

jraph 4y ago
That's fair enough though, isn't it? We can't blame the developers to not support any oddity and particularity that exists… and then blame them because the distribution makers adopt their tools because they work well (as a result?). I'm happy they focus on a standardized base, this results in less development effort focused on more useful stuff, cleaner and more robust tools, it also makes it easy to switch between distributions and to target this standardized base when developing. It also can be seen as a assumed limitation. Any tool has limitations. But the /usr merge has been conducted with reasons, and makes this kind of stuff actually possible. It's not like keeping a split /usr is very useful today anyway. Systemd is not something distributions have to bend to. It's something they willingly adopted because it solves well problems they have. And it's not just Lennart. Hate he gets gets old fast.
- ephaeton 4y ago
  There's no need to be politic about this from the POV of systemd. "We support this feature on merged /usr" does not have to mean "we don't allow to run it on legacy systems because it doesn't make sense". Look, your users have more fantasy than you do how to use your software. Doesn't mean you have to support it. But it also doesn't mean you have to explicitly enable it only in the setup you envisioned this being used. It's not an _assumed_ limitation. It's an _enforced_ limitation based on a limited world-view that also uses the gravity of the project to enforce the world-view on any user. I'm not arguing pro or against split /usr. Reality though is that for various reasons there are legitimate use-cases for a non-unified directory tree, e.g. embedded ramdisks that contain only the barest of /bin in a crunchgen'd binary that don't want to duplicate stuff that's later used in /usr/bin. Linux is not only desktop and server. systemd is being adopted because it solves problems well the distributors have, but THEN the distributor ALSO has to bend their distribution to the single enforced world-view the systemd folks have if they want it to integrate. They, the distributors, software integrators per se, are just forced to hack out limitations that are imposed by systemd folks for no benefit of either; systemd dev or user. No unified-/usr-user will benefit from this enforced restriction. A split-/usr-user will have to patch systemd and maintain their tree to use this feature if they have a good use-case for it because .. "systemd says so" (if you prefer that over the "B"DFL lennart). Lastly, you are correct in that systemd is a pool of like-minded developers - not only lennart; and this is where I add: - who like to shape the reality out there instead of allowing distributors and users to easily take on their own responsibility easily. Sure, I can fork systemd (it's free software after all), but it's unnecessarily "opinionated" for its broad area of application. And that's where the "politic" dimension of systemd development comes into play ...

vegai_ 4y ago

>Systemd has this problem and the solution is to use a feature in systemd, right? More like systems with an immutable /usr have this problem, and systemd now has a way to circumvent those restrictions when developing. Fedora has been prototyping such systems for quite some time, not exactly with brilliant success so far, but it's good that they're trying.

mtzet 4y ago

> Systemd has this problem How does systemd have a problem? Systemd doesn't care about having a read-only rootfs at all, except that it supports it and now ships a little tool that's useful if you happen to use them. Fedora and Ubuntu doesn't ship a read-only rootfs(1). (1) Well, Fedora Silverblue is an experimental Fedora-variant that uses a read only rootfs. But that point still stands.

cookiengineer 4y ago

I am not sure whether or not you are aware that some might intepret your comment as survivor's bias. Not everybody is a sysadmin, and definitely not everybody wants to do those tedious tasks in /etc. There are so many potential pitfalls of everything around init/initd, especially if downstream integration scripts have to keep up with upstream changes. And I would argue that those should not be the burden of endusers, and also not be the burden of distro maintainers. Providing a settings file that can autolaunch your application in a failsafe manner for all distributions is where systemd shines at, like it or not. While I agree that it isn't perfect and the debugging critiques are kind of valid, I also would argue that this can be solved with better (graphical) tools for the systemd ecosystem. Also: if you assume that debugging a broken shell script (running as root) is easier than systemd, then your perspective is already biased, cause it's a skill set that requires lots of experience. I mean, most shell scripts in /etc/init.d don't even set -e, let alone -u ... and should be considered a risk for system integrity.