Recent Features
| |||||||||||||
Remarks about the benchmarkRemarks about the benchmarkPosted Dec 3, 2012 16:44 UTC (Mon) by JanC_ (guest, #34940)In reply to: Remarks about the benchmark by HelloWorld Parent article: Langasek: Upstart in Debian
Debian should pick a single init system, and it's obviously systemd given its technical superiority over all its contenders. kFreeBSD must obviously use sysvinit, as neither systemd nor upstart run on the FreeBSD kernel, but it should be used only on kFreeBSD. That way, eventual sysvinit breakage will be confined to users of that OS. Considering that kFreeBSD is a first class member of the Debian family, and they use the same source packages as linux, it should be obvious that there is only one way to do that: support (at least) two init systems in Debian. And if they would have to choose one and only one init system, then systemd would not be an option at all. Another good reason to support multiple init systems might be that it allows competition, which in turn fosters innovation (why would you keep innovating something if you can sit on your lazy ass or do something else instead?).
(Log in to post comments)
Remarks about the benchmark Posted Dec 3, 2012 16:49 UTC (Mon) by HelloWorld (guest, #56129) [Link] Considering that kFreeBSD is a first class member of the Debian family, and they use the same source packages as linux, it should be obvious that there is only one way to do that: support (at least) two init systems in Debian.No. There's no reason to support sysvinit on Debian GNU/Linux just because it's required on Debian GNU/kFreeBSD. There are already many packages that are supported on only one of the two.
Remarks about the benchmark Posted Dec 3, 2012 18:36 UTC (Mon) by JanC_ (guest, #34940) [Link]
AFAIK those packages are kernel-specific tools or other applications that (for some reason) don't work on one or the other kernel (yet), but there is no reason why sysvinit would not work on linux (as long as somebody keeps maintaining it on linux).
The point is: once you add support for sysvinit to a package that runs on both kernels (which you have to do anyway, as Debian kFreeBSD requires it), you have already done the work to support two init systems, and there is no point in *removing* it again. (Maybe you could say that one init system is the default, and that others are supported on a best-efforts basis, but doing *extra work* to remove something that already works and doesn't break anything else is silly.)
Also, you didn't address my other point: if it were forbidden to add alternative init systems to Debian (and/or other distros), then right now systemd or upstart would likely not be in Debian at all.
Remarks about the benchmark Posted Dec 3, 2012 19:14 UTC (Mon) by HelloWorld (guest, #56129) [Link] The point is: once you add support for sysvinit to a package that runs on both kernels (which you have to do anyway, as Debian kFreeBSD requires it), you have already done the work to support two init systems, and there is no point in *removing* it again. Good point, but I think you're missing something :) If sysvinit is only supported on kFreeBSD, that allows you to use all kinds of FreeBSD craziness in your init scripts, such as jails or whatever else the FreeBSD kernel has to offer. It's like systemd's use of cgroups and whatnot, just the other way around. Of course it's possible to check inside the init scripts what kernel you're running on, but this again increases complexity and need for testing, so the question is, why bother, when there's a better Linux alternative available anyway? Also, you didn't address my other point: if it were forbidden to add alternative init systems to Debian (and/or other distros), then right now systemd or upstart would likely not be in Debian at all. Why do you think that? Choices like these aren't set in stone. They can be revised when a better alternative comes along, just like Fedora dropped upstart when systemd showed up.
|
|||||||||||||