Choose Your Side On the Linux Divide
snydeq writes The battle over systemd exposes a fundamental gap between the old Unix guard and a new guard of Linux developers and admins, writes Deep End's Paul Venezia. "Last week I posted about the schism brewing over systemd and the curiously fast adoption of this massive change to many Linux distributions. If there's one thing that systemd does extremely well, it is to spark heated discussions that devolve into wild, teeth-gnashing rants from both sides. Clearly, systemd is a polarizing subject. If nothing else, that very fact should give one pause. Fundamental changes in the structure of most Linux distributions should not be met with such fervent opposition. It indicates that no matter how reasonable a change may seem, if enough established and learned folks disagree with the change, then perhaps it bears further inspection before going to production. Clearly, that hasn't happened with systemd."
Yes, the old SysV init of hordes of scripts running in series was broken - especially for large-scale systems that have to do a lot of things during startup.
But systemd is just plain FUCKED UP. Read the dependencies.
Why the fuck does the startup process have to depend on the IPv6 kernel module? The other dependencies are no better.
It amuses me greatly that both replies to this post responded as if Bill was talking about "X" the windowing system rather than a placeholder variable.
Should've used $X. ;)
You got a bunch of "upstarts" who don't know, or don't care, about Linux's roots and want to turn it into something it just never was meant to be
When I was a junior network engineer, I sometimes had to work on (what we now consider ancient) technology such as ATM, Frame Relay and ISDN. I even had my share of IPX/SPX. Back in those days, the experienced network engineers with 20+ years of experience despised Ethernet while complaining about those junior folks who knew nothing about the established technologies. As it turned out, all of them are out of a job now.
Bottom line is, when it comes to technology progress, roots are pretty much irrelevant. I don't care if something has been done like this for 1000 years. If we can find a better way to do it, let's do it.
The question should be whether or not systemd is progress, or an unnecessary burden. History is irrelevant in this case.
I'm not a complete idiot... Some parts are missing.
Not just the Registry, but it's also rapidly becoming the equivalent of "svchost.exe". I probably wouldn't have a problem with SystemD if it were designed to be *much* more modular, but the design goals for the package seem to be to embrace, extend and extinguish a significant number of other processes essential to the Linux boot process and to bring most of it straight into PID1. That's just asking for major problems if/when anything goes wrong, and makes troubleshooting a nightmare because you have one huge black box instead of a bunch of daemons. If the SystemD team want to manage network startup, system logging, firewalls and whatever else takes their fancy, then fine, go right ahead; just do it in a way that makes it easier for system admins to disable it and plug in a more fully featured and/or stable alternative, and do it as a child of PID1 so if/when it does crash it doesn't bring the whole system down with it.
If you want an eye opener take a look at the dependency list for SystemD and those packages that depend on SystemD some time, note how entries appear in both lists, then consider the following questions: Bearing in mind that SystemD is the first thing that is loaded after the Kernel; does that look like a good design to you? Does it explain why so many distros have adopted it, given that many of those dependencies either won't work without SystemD underneath or require a considerable amount of customisation to use any alternative?
Still, there's always BSD.
UNIX? They're not even circumcised! Savages!