17 ms·

I'm just guessing here, but systemd makes some things more convinient by being overall more monolithic, like Windows, and especially distros that are targeting

by sulami 11y ago

I'm just guessing here, but systemd makes some things more convinient by being overall more monolithic, like Windows, and especially distros that are targeting a less technical crowd want to be able to compete with Windows in terms of features and usability. Non-technical people most likely don't see any of the beauty of a strictly modular system or proper clean code. And this is not about the init-daemon, it is about systemd as a whole integrated suite of daemons that connect easily and add fancy new features, while on the other side you might have to modify two completely independent software projects to add a new feature that uses both, and even then there most likely are alternatives to each one, and you feature will only work with this specific combination. So a more monolithic system, which systemd is despite Lennard denying this, makes development faster, but will bite you in the long run, especially when the code and documentation quality is as poor as systemd's.

mgbmtl 11y ago
I'm more tempted to say that systemd does well what previously you needed a dozen half-broken tools to implement. For example, isolating the /tmp of an application, monitoring the process and restarting if necessary, more logging options (and imho cleaner/more efficient). Then again, all this has been debated over and over again. In practice, people are adopting it. Haters are noisy. It's like reading about debates on IPv6 migration strategies.
- vezzy-fnord 11y ago
  Process supervisors with reliable logging are nearly two decades old at this point. Isolating /tmp is then a namespacing feature, which in a system where execution state is composed as an explicit external manifest via chain loading (as opposed to serializing from a unit file into a private ExecContext structure, as with systemd) should be completely orthogonal to any one service manager. Else it is inflexible if it needs complex internal scaffolding. (Actually I think supervision goes back to IBM's SRC in at least 1992, but I'm not exactly sure if the earliest versions had anything beyond process management.)
  - XorNot 11y ago
    Process supervision goes back a long away...and has pretty much never been included out of the box in any server-oriented Linux distros. It also looks a lot more like systemd in systems with good process supervision like Solaris.
    - vezzy-fnord 11y ago
      Which is a failure of people making server distros, not those writing process supervisors. Not at all. SMF supports delegated restarters, its milestones can contain far more state information (and explicitly) than targets can, it uses a configuration repository which enables runtime dynamic service state modification at a far higher rate than the relatively static systemd, its dependency system is simpler, it's integrated with the hardware fault manager (also to provide service resource identifiers beyond the COMM name), its profiles are more granular than presets, it has explicit service instance support and logging is flat file-based in /var/svc/log. SMF has plenty of its own issues, but it's quite different from systemd. I think the delegation aspect is one of its most valuable lessons, but ultimately I also believe it's too overarching for a modern init.
  - digi_owl 11y ago
    I think one thing that gave systemd adoption a big boost was a declaration from the maintainer of the cgroups sub-system of Linux. At present multiple processes can set up and manage cgroups, but the maintainer wants to change to there being a single user space manager. Thus systemd was pushed as "the" cgroups user space process. You can already seeing the systemd devs behaving as if this was a done deal. Ran into a email a while back about systemd clobbering a libvirt managed cgroup. And in it Poettering "suggested" that libvirt should hand control over to systemd as it would be THE cgroups manager going forward. You can probably find similar encounters between, say, Docker and systemd.

by sulami 11y ago

mgbmtl 11y ago

I'm more tempted to say that systemd does well what previously you needed a dozen half-broken tools to implement. For example, isolating the /tmp of an application, monitoring the process and restarting if necessary, more logging options (and imho cleaner/more efficient). Then again, all this has been debated over and over again. In practice, people are adopting it. Haters are noisy. It's like reading about debates on IPv6 migration strategies.

vezzy-fnord 11y ago
Process supervisors with reliable logging are nearly two decades old at this point. Isolating /tmp is then a namespacing feature, which in a system where execution state is composed as an explicit external manifest via chain loading (as opposed to serializing from a unit file into a private ExecContext structure, as with systemd) should be completely orthogonal to any one service manager. Else it is inflexible if it needs complex internal scaffolding. (Actually I think supervision goes back to IBM's SRC in at least 1992, but I'm not exactly sure if the earliest versions had anything beyond process management.)
- XorNot 11y ago
  Process supervision goes back a long away...and has pretty much never been included out of the box in any server-oriented Linux distros. It also looks a lot more like systemd in systems with good process supervision like Solaris.
  - vezzy-fnord 11y ago
    Which is a failure of people making server distros, not those writing process supervisors. Not at all. SMF supports delegated restarters, its milestones can contain far more state information (and explicitly) than targets can, it uses a configuration repository which enables runtime dynamic service state modification at a far higher rate than the relatively static systemd, its dependency system is simpler, it's integrated with the hardware fault manager (also to provide service resource identifiers beyond the COMM name), its profiles are more granular than presets, it has explicit service instance support and logging is flat file-based in /var/svc/log. SMF has plenty of its own issues, but it's quite different from systemd. I think the delegation aspect is one of its most valuable lessons, but ultimately I also believe it's too overarching for a modern init.
- digi_owl 11y ago
  I think one thing that gave systemd adoption a big boost was a declaration from the maintainer of the cgroups sub-system of Linux. At present multiple processes can set up and manage cgroups, but the maintainer wants to change to there being a single user space manager. Thus systemd was pushed as "the" cgroups user space process. You can already seeing the systemd devs behaving as if this was a done deal. Ran into a email a while back about systemd clobbering a libvirt managed cgroup. And in it Poettering "suggested" that libvirt should hand control over to systemd as it would be THE cgroups manager going forward. You can probably find similar encounters between, say, Docker and systemd.