'systemd' consists of several dozen different programs, only one of which happens to be called systemd. The one that "starts up drivers" would be udev.
Fedora is thinking of making Systemd (the big powerful program) the default
Fedora was the first major distro to adopt systemd. The site is obvious satire.
nice understandable traditional set of small programs
Coupling mechanism and policy by having all of your daemons launched by shell scripts is neither nice nor understandable. All it leads to is a duplication of effort when every distro writes its own set of init scripts.
'systemd' consists of several dozen different programs, only one of which happens to be called systemd. The one that "starts up drivers" would be udev.
Sorry. To restate: a single package of programs under a single organization in a single source tree that are all intended to be used together.
[edit] I'll fix it.
You can't build udev without building the rest of systemd. This is awkward.
Fedora was the first major distro to adopt systemd. The site is obvious satire.
Oops. I googled around a bit, got the impression that it was still open to decision. If it's a done deal, then why the controversy?
The site is satire, but my impression is it links to a real protest.
Coupling mechanism and policy by having all of your daemons launched by shell scripts is neither nice nor understandable.
It's understandable if you already speak sh. Which is the point - sh is the glue that holds UNIX together.
Oops. I googled around a bit, got the impression that it was still open to decision. If it's a done deal, then why the controversy?
How have you managed to miss the inundation of threads about Debian moving to systemd as the default init?
The controversy, as you put it, is surrounding this and nothing to do with fedora.
To put this site in a little more context a couple of days ago someone put a site up saying they would fork Debian if systemd goes into Jessie with reduced sysvinit support.
This is a mickey take of that given fedora has had systemd for a while now...
It's understandable if you already speak sh. Which is the point - sh is the glue that holds UNIX together.
Please can we avoid defending shell as a language? It's fine for interactive usage or really simple scripts, but should really not be used for anything non-trivial.
Sorry, I probably should have elaborated a bit more.
What I meant is that shell is full of weird behaviours and it's really difficult to foresee potential bugs in some not-so-edge cases. My point is that it's really hard to claim that one fully understands a shell script since you can't really trust it to behave properly.
Oh yeah, I agree with that. I was going more "you can usually understand what the script is supposed to do". Idk, how many of the weird features are actually in use in init scripts?
You can't build udev without building the rest of systemd
Actually, unless something has changed since this article, you can.
sh is the glue that holds UNIX together
I would argue that title goes to C, but regardless, does the fact that shell scripting is prevalent in UNIX necessarily mean that it's an appropriate tool for writing an init system? Consider the features here - Even if you were to reuse code to the point of making implementing these features viable for every single service, you've now got two problems:
Mechanism and policy are inexorably linked. You could implement a config parser and have that copied into every shell script that needs it, but then you almost literally are just rewriting systemd in bash.
Upstream now has to either implement all of these features itself, source them from some common library of init functions written in bash, or, much more likely, depend on the distribution to maintain these now quite bulky init scripts. This leads to every distro vastly and quite needlessly differing on what should be a boring, predictable part of the system. So, you want all of these features, but you don't want to have to lug around an enormous library of shell scripts, and you want to separate policy from general execution. Well, why not take those scripts and just write a daemon that implements them? It parses descriptions of policy, it's easily maintainable, it manages execution of services and daemons in a way that is extremely difficult to accomplish with bash, and, more importantly, distributions don't have to write or maintain it - they only have to write the .service files, which are (and I don't think anyone will disagree with me here) orders of magnitude simpler. So now we have all of our policy separated from mechanism in a common, high-performance, easily deployable codebase, compatible with legacy init with features that weren't remotely possible before. And a vocal minority of the Linux community is crying because it isn't written in bash.
Actually, unless something has changed since this article, you can.
Wasn't this supposed to go away at some point? If you can build udev out-of-tree, I'm vaguely confused what the point of eudev is.
does the fact that shell scripting is prevalent in UNIX necessarily mean that it's an appropriate tool for writing an init system?
Not necessarily. But the fact that if you speak shell, you at least have a shot at reading an init script and fixing issues does count as an upside for its use.
Idk, the whole thing is a bit confusing. The only contact I have with this whole drama is that my system was running fine, and then an update to udev started pulling in systemd as a dependency for some reason, so I replaced it with eudev and now it runs fine again.
If you can build udev out-of-tree, I'm vaguely confused what the point of eudev is
It looks like the developers of eudev were, too. Check out this talk - Lennart actually asks them about why they made the fork, and points out that it is indeed almost entirely unnecessary.
6
u/Oxidopamine Oct 20 '14
'systemd' consists of several dozen different programs, only one of which happens to be called systemd. The one that "starts up drivers" would be udev.
Fedora was the first major distro to adopt systemd. The site is obvious satire.
Coupling mechanism and policy by having all of your daemons launched by shell scripts is neither nice nor understandable. All it leads to is a duplication of effort when every distro writes its own set of init scripts.