Debian Developers Take To Voting Over Init System Diversity
It's been five years already since the vote to transition to systemd in Debian over Upstart while now there is the new vote that has just commenced for judging the interest in "init system diversity" and just how much Debian developers care (or not) in supporting alternatives to systemd.
Due to Debian developers having differing opinions on handling non-systemd bugs in 2019 and the interest/commitment to supporting systemd alternatives in the scope of Debian packaging and various related friction points, they've taken to a new general resolution over weighing init system diversity.
The ballot is available on-line. The choices are:
Choice 1: F: Focus on systemd
Choice 2: B: Systemd but we support exploring alternatives
Choice 3: A: Support for multiple init systems is Important
Choice 4: D: Support non-systemd systems, without blocking progress
Choice 5: H: Support portability, without blocking progress
Choice 6: E: Support for multiple init systems is Required
Choice 7: G: Support portability and multiple implementations
Choice 8: Further Discussion
[Ed. note: I'm not sure what the letters after the choice numbers indicate, nor do I know where "C" disappeared to.]
(Score: 5, Insightful) by bradley13 on Tuesday December 10 2019, @03:36PM (2 children)
Security through obscurity is, indeed, not a bad thing. It's not enough by itself, but it is a tool in the toolbox. Just running a server on an unusual port eliminated virtually all attacks. So why not take advantage of that?
Linux is the same: The mass consumer usage of Windows and Mac markets attracts most of the hacking activity. Linux may be dominant in servers, but servers are also generally pretty well secured. Hence, Linux has attracted (through its obscurity in the consumer market) comparatively little hacking attention.
As far as SystemD is concerned: I'm not any sort of Linux admin, just a technical user. That said, the classic init-systems were a dog's breakfast. The few times I had to work with them, sure, everything is a text file, that's great. But the system just wasn't reliable, or didn't seem so to me. So I absolutely like the original, stated goals of SystemD.
That said, all the different things that it does should be in different modules, that you can pick and choose. It should not be the case that choosing SystemD as your init system also dictates a zillion other aspects of your Linux installation. Separate tools for separate tasks, and user (or at least distro) choice on which combination is used.
Everyone is somebody else's weirdo.
(Score: 2) by chromas on Tuesday December 10 2019, @08:08PM (1 child)
It sort of already is. You don't have to use the timesync daemon, caching dns resolver, or the service that gives you dbus access to /etc/hostname, but they're there for you, whether you want 'em or not.
(Score: 0) by Anonymous Coward on Tuesday December 10 2019, @09:10PM
... for now.
Most of systemd started as optional, and then new parts required them, and then Gnome required those parts ...
So they might be "optional" now, but they'll be needed by some core part son enough.