Originally posted by moltonel
View Post
Announcement
Collapse
No announcement yet.
SysVinit 2.90 Released With Fixes & Better Support For Newer Compilers
Collapse
X
-
Originally posted by Vistaus View PostFunny. Someone before you mentioned how straightforward sysvinit is, but it can't be straightforward is so many things are undocumented...
Comment
-
Originally posted by sjukfan View PostSo how does someone use logind without systemd?
logind relies on features provided by its dependencies, you can remove them or clone them from systemd init to logind (making it more monolithic),
Yes ladies and gents, elogind is more monolithic.Last edited by starshipeleven; 19 June 2018, 03:48 PM.
- Likes 1
Comment
-
Originally posted by moltonel View PostThere are good alternatives to sysvinit and systemd out there. OpenRC is often mentioned, runit is another, minit, daemontools... The nice thing about all of those except systemd is that they play fairly well together on a single system.
- Likes 1
Comment
-
Originally posted by starshipeleven View PostWhy you even have more than one init installed again? What's the point? Why is that "a nice thing"?
Systemd can use sysvinit scripts, but it's not bugfree. I've experienced that first-hand professionally trying to get a well-tested sysvinit script to run under systemd, the error cases were not handled well under systemd, we had to write native systemd files and patch the underlying software to get back to sysvinit-era dependability. I've had less problems mixing openrc, sysvinit, and runit scripts, probably because those don't try as hard to be the sole source of truth as systemd does.
Don't get me wrong, systemd is really nice. It offers elegant solutions to many problems. But it has a "do things my way or get lost" mentality which can get troublesome. Custom solutions for logging, managing control groups, monitoring health, etc are possible under systemd but you have to fight for it. Subsystems like udev and logind that could (or used to) be independent projects get lumped into systemd, seemingly just to strong-arm people into using systemd (thankfully, systemd-less forks are maintained for both of those). It is these reasons, not some internal architechture, that make systemd monolithic. For better and worse.
- Likes 3
Comment
-
Originally posted by starshipeleven View PostWhy you even have more than one init installed again? What's the point? Why is that "a nice thing"?
On-topic: there really aint much ground between busybox for dead-simple systems and something more maintainable than sysvinit. good luck to those still depending on it.
Comment
-
Originally posted by moltonel View Post
* Horribly written probably. Did you check ? Sysvinit is actually very small, so only its age will make it horrible. Maybe you're thinking about the individual service scripts ?
[...]
And so is inserv that is/was used in most distribution to calculate the dependency graph of the LSB compliant initscript: https://sources.debian.org/src/insse...5.4/insserv.c/Last edited by Bigon; 19 June 2018, 05:59 PM.
Comment
-
Originally posted by starshipeleven View PostWhy you even have more than one init installed again? What's the point? Why is that "a nice thing"?
Systemd can use sysvinit scripts, but it's not bugfree. I've experienced that first-hand professionally trying to get a well-tested sysvinit script to run under systemd, the error cases were not handled well under systemd, we had to write native systemd files and patch the underlying software to get back to sysvinit-era dependability. I've had less problems mixing openrc, sysvinit, and runit scripts, probably because those don't try as hard to be the sole source of truth as systemd does.
Don't get me wrong, systemd is really nice. It offers elegant solutions to many problems. But it has a "do things my way or get lost" mentality which can get troublesome. Custom solutions for logging, managing control groups, monitoring health, etc are possible under systemd but you have to fight for it. Subsystems like udev and logind that could (or used to) be independent projects get lumped into systemd, seemingly just to strong-arm people into using systemd (thankfully, systemd-less forks are maintained for both of those). It is these reasons, not some internal architechture, that make systemd monolithic.
Comment
Comment