Comment by smartmic
2 days ago
It's a pity. It's also a step back from valuing the Unix philosophy, which has its merits, especially for those with a "learning the system from scratch" mindset. Sorry, but I have no sympathy for systemd.
2 days ago
It's a pity. It's also a step back from valuing the Unix philosophy, which has its merits, especially for those with a "learning the system from scratch" mindset. Sorry, but I have no sympathy for systemd.
SysVinit has been seen by some people in the post-systemd world as some sort of mystifying mashup concocted by sadists, yet I've found that when it is explained well, it is clear and human-friendly, with easy uptake by newcomers. I echo that this decision is a pity.
It’s not just explaining but whether you have to support it on more than one distribution/version or handle edge cases. For a simple learning exercise, it can be easier to start with but even in the 90s it was notably behind, say, Windows NT 3 in a lot of ways which matter.
"When it's explained well" is the keyword
I'm not a systemD fan but SysV is not without its quirks and weirdness and foot guns
sysv is garbage tho. If unix philosophy is "make it do one thing and do it well", it doesn't do the one thing it is supposed to do well.
I dislike overloading systemd with tools that are not related to running services but systemd does the "run services" (and auxiliary stuff like "make sure mount service uses is up before it is started" or "restart it if it dies" and hundred other things that are very service or use-case specific) very, very well and I used maybe 4 different alternatives across last 20 years
I don't see how this relates to removing SysVinit support from LFS. Choice is good.
Are you entitled to the LFS developers time? They build the system they get to make into what they want.
That "choice" still has to be maintained. And why spend effort when you can do the same things + more with systemd?
2 replies →
I don't have a dog in this fight but I find it funny that the anti-systemd crowd hates it because it doesn't "follow the Unix philosophy", but they tend to also hate Wayland which does and moves away from a clunky monolith (Xorg)
While Xorg itself (which isn't a monolith, BTW) provides more than the bare minimum, so does the Linux kernel - or even the Unix/BSD kernels of old - yet programs that did follow to the Unix philosophy were built on top of them.
In X11/Xorg's case, a common example would be environments built off different window managers, panels, launchers, etc. In theory nothing prevents Wayland to have something similar but in practice 17 years after its initial release, there isn't anything like that (or at least nothing that people do use).
At least in my mind, the Unix philosophy isn't some sort of dogma, just something to try and strive for and a base (like X11) that enables others to do that doesn't go against it from the perspective of the system as a whole.
This one bothers me too.
Systemd and Xorg are very similar in many ways. I do not know how you hate Systemd and love Xorg unless your real problem is just change.
And, while I like Wayland, I think that liking the Wayland architecture should have you disliking Systemd. But that is just me.
I'm in the same boat. Systemd is an unpricipled mess and ships some quite shoddy replacements for pre-existing components. Wayland is super clean, it just takes for-everrr to add the features that users (and developers) expect. It could seriously have been done over 10 years ago not by heroic development effort, but by not being pathologically obstructive about features.
The two projects are complete opposites except in one way, they replace older stuff.
> but they tend to also hate Wayland which does and moves away from a clunky monolith (Xorg)
It's been 17 years and Wayland has yet to reach feature parity with X11/Xorg. There is doubt that it ever will.
Regardless of what you think the Unix "philosophy" is, actual features matter.
But Wayland is a protocol suite, you're comparing it against Xorg, an implementation that shipped 16 years after X was created.
If you want to learn the system from scratch, the best way will be writing your own little init system from scratch, so you can understand how the boot sequence works. And as you make use of more and more of the advanced features of Linux, your init system will get more and more complex, and will start to resemble systemd.
If you only learn about sysvinit and stop there, you are missing large parts of how a modern Linux distro boots and manages services.
> and will start to resemble systemd
That's the point on which people differ. Even if we take as given that rc/svinit/runit/etc is not good enough (and I don't think that's been established), there are lots of directions you can go from there, with systemd just one of them.
And on the other hand, I have no sympathy for the Unix philosophy. I value results, not dogma, and managing servers with systemd is far more pleasant than managing servers with sysvinit was. When a tool improves my sysadmin life as much as systemd has, I couldn't care less if it violates some purity rule to do so.