If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
I have to agree that a lot of systemd's functions aren't related at all to an init system (eg DNS resolution as noted before) but that isn't the root of the problem. The issue that I and probably at least a few other people have with systemd is that it's a fait-accompli.
If all these extensions were modular packages then it'd be fine. I could run openRC, but borrow systemd's "super awesome amazing" DNS resolver. Most things really shouldn't conceptually need anything more. Others only really need a way to communicate. What's the simplest stand-alone D-BUS implementation theoretically possible?
But I can't just pick up one cool tool or program. It's an all-or-nothing deal. I can't use A without pulling in not just B and C basically all the rest of systemd too. The only thing I can ditch are some relatively high-level functions that haven't become dependencies of other shit yet.
And god help a program that thinks it can do a better job than a mandatory part of systemd. It'd better learn to stay the fuck off systemd's turf if it wants to be adopted. Default is easy and default always wins.
The way that systemd is developed it's more like a playground for the developers to go "wouldn't this be a totally radical cool thing for an OS to do too?" (I'm looking at you, systemd-homed) and then they build it, good idea or no. Except they also happen to be the developers of systemd so A) it relies upon the rest of this infrastructure they've been building for 10+ years and B) it's going to get automatic adoption because it'll ship shrinkwrapped to the next copy of systemd.
If they were actually charging money for this it'd put the "windows bundles IE with XP" anticompetitive arguments to shame. Systemd pics lynx as the next viewer for config pages? You bet your ass lynx is getting installed into every linux distro from here on out.
You ever notice how distros have pretty much completely given up breaking up systemd into packages? They go to extreme lengths to break out every last bundled library and dependency for all other software, but systemd for all it's functionality gets split into maybe five parts.
So firstly thank you for a civil and unemotional argument. As far as your points go, the fact that you can't pick and choose has been raised before, but in reality, tight integration is part of the systemd design brief. The idea of having multiple totally independent programs (none of which really does ONE thing and they never do it particularly well, by the way - heck, even /bin/false must contain a parser and has a CVE history!) has been used for decades and it hasn't really worked out - the *nix landscape (and Linux, who inherited it) has always been an inconsistent mess where application developers can't ever assume anything and must expect everything. So yes, you lose the possibility to replace your DNS resolver with yet-another DNS resolver. It comes down to what is more important: being able to do that, or being able to develop application software knowing exactly what the underlying platform is, what it does and how it does it? Personally I vote for the latter.
PS: regarding DBUS, I could be wrong but I believe systemd has its own basic DBUS implementation so if you want to write additional systemd modules or rewrite some existing one, you should be able to use just that.
IMHO systemd should be a kernel optimized, super-robust pubsub engine, and everything else in the systemd package should be applications that utilize this pubsub engine. Plus a way to get legacy apps to talk to this engine through a wrapper. Alas, the proper time and effort to make it a standalone engine was never invested, so now we have a tightly coupled system that collects all other subsystems like a huge katamari damacy.
However, I do not have the time nor motivation to recode systemd, and it works reasonably well as it stands right now. While the design is suboptimal, the software itself provides excellent features. One day systemd will get rewritten to a more efficient and modular design; until then I will use what is available.
What gets to me is that systemd replaced some common things with its own implementation,but changed the defaults which is causing problems. For example fstab.
Could you provide some more details on that? I've seen some very long shutdown times with systemd failing to unmount some stuff from fstab that never used to be a problem in the past with init.d or upstart.
What gets to me is that systemd replaced some common things with its own implementation,but changed the defaults which is causing problems. For example fstab.
Anyway, in parallel with Devuian we have Alpine and Gentoo that also works well without systemd.
This has been debated, to death, by others. Suffice to say, just because something is split in different binaries does not mean it is not monolithic, the Linux kernel has modules ergo it is not monolithic too... Except it is, even Linus Torvalds says so.
Neither does it mean the opposite. You're correct this has been debated to death, but there is no agreement as to who won the debate.
And to my eyes, if something is split into well-defined parts with well-defined and mostly stable interfaces, most of which do not form strongly connected components, then it pretty much fits the definition of "modular". If you personally don't like the interfaces, it doesn't automatically mean they are not worthy of being called modules.
Ah yes, the endlessly-rehashed but mostly invalid "points" thrown around ad infinitum. Suffice it to say, just because something has a catchy title and a lot of text doesn't mean it is true.
Last edited by intelfx; 15 October 2021, 06:15 AM.
Comment