The Debian init system general resolution returns
The Debian init system general resolution returns
Posted Oct 17, 2014 20:21 UTC (Fri) by ctpm (guest, #35884)In reply to: The Debian init system general resolution returns by Cyberax
Parent article: The Debian init system general resolution returns
The only argument I've read from you in this thread is you saying that you don't care and you don't want to care.
And that's fine! You can keep eating your mystery sausage with eyes closed for as long as you want. That's your prerogative.
But the people who want or need to keep real life systems working *will* need to care and know what's happening on their systems, and fix them when they break.
Bury your head (and your sausage) in the sand as much as you want, but don't come whining in 2 years when most distros are so FUBAR that the solution is to throw half of that trash away.
Posted Oct 17, 2014 23:00 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
For me this script was the deal-breaker: http://anonscm.debian.org/cgit/users/lamont/bind9.git/tre...
Posted Oct 17, 2014 23:15 UTC (Fri)
by mgb (guest, #3226)
[Link] (2 responses)
A good modular design would have been technically acceptable to everybody, but systemd was never about technology.
Systemd is about seizing control of Linux. And the extraordinarily serious downside of systemd's awful design is that the lack of modularity makes it hard to improve Linux in future.
Posted Oct 17, 2014 23:17 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
So for me systemd's public interfaces seems crystal clear.
Posted Oct 18, 2014 0:15 UTC (Sat)
by anselm (subscriber, #2796)
[Link]
Great. Feel free to design, implement, debug, and document something that is better than systemd. If systemd is really so terrible, people will be celebrating you for the next few decades.
In reality, though, actually coming up with a software system that does what systemd does but better is probably not all that easy. Talk is cheap, but actually doing the work is hard – which is why out of all the people who are moaning and griping about how systemd is so bad, nobody so far has actually got their gear together enough to come up with anything at all to compete with it. They tell us, for example, that sysvinit would be perfectly equal to systemd if only someone added component X, feature Y, or approach Z that is superior to what systemd does, but nobody develops the code or writes the documentation. Many of the missing bits and pieces purportedly exist and are working great, but nobody even comes up with a proof-of-concept derivative of a popular Linux distribution that integrates them by default. My personal guess is that most of these people simply lack the vision, technical competence, and will of someone like Lennart Poettering, but they still think they're entitled to tell everyone what they should or should not be using. I don't think these people are really worth listening to.
Have you actually looked at systemd? The design is pretty modular as these things go. And the interfaces between the modules are way better documented than anything in the sysvinit universe.
Exactly who is supposed to be “seizing control of Linux” through systemd? The systemd developer community includes people from all major Linux distributions. If getting rid of every distribution's /etc/hostname, /etc/HOSTNAME, and /etc/sysconfig/whatever_the_file_is_called_this_week in favour of one standardised configuration file is “seizing control of Linux“ then I say bring it on.
Systemd consists of a bunch of modules with documented interfaces and a stability promise. It would certainly be possible to replace individual modules with different implementations that adhere to the same interfaces. It may be often be an easier route, however, to simply improve systemd's components instead. These could be forked if required, and/or improvements could be fed back into the systemd development process.
Posted Oct 18, 2014 7:01 UTC (Sat)
by wt (subscriber, #11793)
[Link] (2 responses)
The Debian TC already found systemd to be the technically superior choice. It makes sense to want to use the best technical solution as broadly as possible, meaning systemd support should be a priority for Debian. However, systemd only supports Linux-based systems, which accounts for ~98.4% of Debian's user base according to popcon data[1].
With regard to other Debian archs, it's straightforward to look at the ecosystem and conclude that it's dominated by the Linux kernel over the alternative kernel options. In fact, according to popcon data, only ~1.6% of users run hurd, kfreebsd, or have an unknown arch.
Given those stats, forcing support for the other kernels basically means holding back ~98.4% of Debian users to support those other choices. In order to have those choices available a sacrifice must be made in terms of time needed to deliver a release or quality of a release or both.
I don't think the resistance to supporting multiple init options has so much to do with not caring about the other viewpoint as much as not wanting to sacrifice the benefits of what they see as the best way forward for 98.4% of the user base.
wt
Posted Oct 18, 2014 8:10 UTC (Sat)
by zwenna (guest, #64777)
[Link] (1 responses)
Small correction: the number is 1.6 ‰, not 1.6 %.
Posted Oct 20, 2014 6:32 UTC (Mon)
by wt (subscriber, #11793)
[Link]
I guess I was trying to be fair and erred on the side of to much share for the alternative kernels.
wt
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
The Debian init system general resolution returns
One can certainly consider improving upon sysvinit, but a rat's nest of processes and D-Bus interfaces is not an improvement.
A good modular design would have been technically acceptable to everybody
Systemd is about seizing control of Linux.
And the extraordinarily serious downside of systemd's awful design is that the lack of modularity makes it hard to improve Linux in future.
possible motivation for not supporting forced-support of multiple init options
possible motivation for not supporting forced-support of multiple init options
possible motivation for not supporting forced-support of multiple init options