I have my whole system running like a livecd using overlayfs, it's great. It's a real peace of mind knowing nothing will persist. No logs or information is stored without your knowledge, any configuration mistakes will solve themselves on reboot, it also enforces the separation between your data and the system install.
Nice. Reminds me of longtime security tactic for web servers of shipping logs and mounting the entire file system as read-only so that intruders have no means of installing their root kit.
> 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 (...)
I'm not sure I fully understand what Lennart means by "/usr merge". Is it assuming all paths under /usr belong to the same mount point, or something else?
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.
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).
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.
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.
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.
>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.
[+] [-] ad404b8a372f2b9|3 years ago|reply
[+] [-] snorkel|3 years ago|reply
[+] [-] enriquto|3 years ago|reply
Laughed hard at the audacity of this one.
[+] [-] diffeomorphism|3 years ago|reply
Ubuntu: 3 years ago
Debian: supported both merged and non-merged for a while; only merged supported since last year
Opensuse: last year (?)
Arch: btw
Fedora: 2011
...
Any big distro I am missing?
[+] [-] blueflow|3 years ago|reply
[+] [-] mariusor|3 years ago|reply
[+] [-] pdenton|3 years ago|reply
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|3 years ago|reply
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).
[+] [-] ephaeton|3 years ago|reply
> 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.
[+] [-] mtzet|3 years ago|reply
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|3 years ago|reply
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.
[+] [-] vegai_|3 years ago|reply
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.
[+] [-] mro_name|3 years ago|reply
[+] [-] ephaeton|3 years ago|reply