|
|
Subscribe / Log in / New account

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

And on the other hand _your_ arguments are so much better than the "anti-systemd template", right?

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.


to post comments

The Debian init system general resolution returns

Posted Oct 17, 2014 23:00 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

Not really. There are tons of rational technical arguments for systemd.

For me this script was the deal-breaker: http://anonscm.debian.org/cgit/users/lamont/bind9.git/tre...

The Debian init system general resolution returns

Posted Oct 17, 2014 23:15 UTC (Fri) by mgb (guest, #3226) [Link] (2 responses)

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, 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.

The Debian init system general resolution returns

Posted Oct 17, 2014 23:17 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

And I could never get right all the rc.local, /etc/inittab, /etc/rc<wtf> and the correct way to juggle all the start-stop-daemon incantations.

So for me systemd's public interfaces seems crystal clear.

The Debian init system general resolution returns

Posted Oct 18, 2014 0:15 UTC (Sat) by anselm (subscriber, #2796) [Link]

One can certainly consider improving upon sysvinit, but a rat's nest of processes and D-Bus interfaces is not an improvement.

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.

A good modular design would have been technically acceptable to everybody

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.

Systemd is about seizing control of Linux.

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.

And the extraordinarily serious downside of systemd's awful design is that the lack of modularity makes it hard to improve Linux in future.

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.

possible motivation for not supporting forced-support of multiple init options

Posted Oct 18, 2014 7:01 UTC (Sat) by wt (subscriber, #11793) [Link] (2 responses)

If we assume that the human resources going into Debian don't change rapidly, those who need to keep systems working, like me, may not be as well served by having options for init due to sacrifices needed in areas of time or quality for supporting multiple options. It seems a product decision must be made to prioritize portability (user choice), time needed to deliver, and quality of the product.

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

[1]http://popcon.debian.org/

possible motivation for not supporting forced-support of multiple init options

Posted Oct 18, 2014 8:10 UTC (Sat) by zwenna (guest, #64777) [Link] (1 responses)

> 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.

Small correction: the number is 1.6 ‰, not 1.6 %.

possible motivation for not supporting forced-support of multiple init options

Posted Oct 20, 2014 6:32 UTC (Mon) by wt (subscriber, #11793) [Link]

You're totally right. It's actually 0.16% who use alternative-kernel archs and 99.84% that use Linux-kernel archs.

I guess I was trying to be fair and erred on the side of to much share for the alternative kernels.

wt


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds