| |||||||||||||
Debian looks at OpenRCDebian looks at OpenRCPosted Aug 23, 2012 16:11 UTC (Thu) by kaol (subscriber, #2346)Parent article: Debian looks at OpenRC Yet another option would be to automatically generate init scripts for various init systems from a single source. This year's GSoC had one such project, though it yet remains to be seen if and how it will be used in Debian. Akhil's project used systemd init files as the source, which seems like a good choice to me, given how declarative they are. LSB init scripts are full of boilerplate.
(Log in to post comments)
Debian looks at OpenRC Posted Aug 23, 2012 16:22 UTC (Thu) by drag (subscriber, #31333) [Link]
That sounds terrible.
What Debian really needs to do is just make a choice. They only need one init system.
Debian looks at OpenRC Posted Aug 23, 2012 16:56 UTC (Thu) by josh (subscriber, #17465) [Link]
I agree entirely, but at least with a compatibility translator like this, the systemd .service files could become the canonical description of how to run a service, and packagers would not need to write sysvinit scripts by hand anymore. Seems like the easiest way to "support" sysvinit without forcing every service to deal with sysvinit scripts, which seems like a net improvement over the current state.
Debian looks at OpenRC Posted Aug 23, 2012 18:57 UTC (Thu) by viro (subscriber, #7872) [Link]
... because all this fragmentation makes it so much harder to play dependency games, doesn't it?
Here's how it works:
With systemd on every box the whole thing would become so much easier - just cut (3) out, avoiding the need to convince a lot of developers and (oh, horror) to deal with their objections.
Debian looks at OpenRC Posted Aug 23, 2012 21:50 UTC (Thu) by rleigh (subscriber, #14622) [Link] This is one of my primary objections to systemd, which was mentioned here: http://lists.debian.org/debian-devel/2012/04/msg00751.html.The tight-coupling between components which systemd is encouraging and requiring is something which, for those who remember back then, we used to criticise Microsoft for, due to their inability to dig themselves out of the rut such philosophy had led to, being unable to fix even trivial bugs due to fixing them breaking old code. It leads to inflexible systems which can't change, whereas loosely-coupled systems, which Linux has had until now, allow components to be easily swapped out and changed providing that the interfaces between the components are relatively well specified. The loose coupling does have the disadvantage that components aren't necessarily as well integrated, but this hasn't really been a problem in practice--the benefits far outweigh these downsides, and this seems to have been forgotten in some camps. An example is the requirement for stuff like cgroups, autofs, D-Bus etc. Having these as a requirement, rather than merely being optional and used if available, imposes constraints on other projects. cgroups can never be removed from the kernel, and distribution kernels must include it. So it indirectly forces other parties not to allow certain components to evolve or be removed. Likewise in userspace with D-Bus. I can't say I'm particularly happy to have such a nasty bit of code required to be running on my system, let alone being used by init. If systemd was a bit less aggressive in its strict requirements, it would be rather more portable (including to Linux, for kernels which don't have all the extra bits built in). The other issue is the reliability of the system. sysvinit is tiny (~30KiB on i386), because it does relatively little. This makes it very reliable. PID 1 must never die! There's no need for PID1 to do anything but the bare minimum--it's quite fine for more advanced stuff to be done by other processes forked from init. The ideas behind other less well known alternatives such as s6 are also well worth looking into. The nice thing about OpenRC is that it's run from init, so it can do some more advanced stuff like dependency-based boot, but the extra complexity is not going into PID 1. Now, it's clearly not as advanced as systemd. But it's most certainly more advanced than sysv-rc. It gives us some of the features that systemd offers, but without the massive downsides. Lastly, while there's a lot of momentum in the adoption of systemd across several other distributions, I always feel somewhat bothered by the arguments that we must adopt it or get left behind. Blindly jumping on the latest bandwagon is rarely a sensible choice, particuarly when it might not be taking us where we want to go. And while having a single init across distributions is touted as a generally good idea, having different implementations does prevent gross stupidities from taking place, nor give any single party the ability to force unwanted changes upon eveyone. Systemd certainly has a lot of good ideas, but the package as a whole is does not allow one to pick and choose the good from the bad due to its lack of modularity. That might require them to be reimplemented. As has happened with cgroups in OpenRC.
Debian looks at OpenRC Posted Aug 23, 2012 22:26 UTC (Thu) by daniels (subscriber, #16193) [Link]
> It leads to inflexible systems which can't change, whereas loosely-coupled systems, which Linux has had until now, allow components to be easily swapped out and changed providing that the interfaces between the components are relatively well specified.
Wait, what? If you have a single large and totally integrated system, you can change what you want: everything is an implementation detail. If you have an infinitely modular system, you can't change anything, because every line of code is an interface.
I don't see your argument at all.
Debian looks at OpenRC Posted Aug 24, 2012 7:06 UTC (Fri) by dgm (subscriber, #49227) [Link]
A highly coupled system is one where any part of it can interact with any other part of it, like a program written in assembly language, where every line of code is a potential jump destination. This makes changing parts rather difficult, as stated.
A loosely coupled one is just the opposite. In those all interactions happen through interfaces, so as long as the interfaces are respected, you can confidently change the parts behind them.
Debian looks at OpenRC Posted Aug 26, 2012 0:17 UTC (Sun) by HelloWorld (guest, #56129) [Link]
> The tight-coupling between components which systemd is encouraging and requiring is something which, for those who remember back then, we used to criticise Microsoft for, due to their inability to dig themselves out of the rut such philosophy had led to, being unable to fix even trivial bugs due to fixing them breaking old code. It leads to inflexible systems which can't change, whereas loosely-coupled systems, which Linux has had until now, allow components to be easily swapped out and changed providing that the interfaces between the components are relatively well specified.
Systemd's interfaces are perfectly well-specified. http://www.freedesktop.org/wiki/Software/systemd/Interfac... They're also relatively simple and portable, so that other init-like software can use the same interfaces for e. g. socket activation. I'm sorry, but I don't see your point at all.
> The loose coupling does have the disadvantage that components aren't necessarily as well integrated, but this hasn't really been a problem in practice--the benefits far outweigh these downsides,
> An example is the requirement for stuff like cgroups, autofs, D-Bus etc. Having these as a requirement, rather than merely being optional and used if available, imposes constraints on other projects. cgroups can never be removed from the kernel, and distribution kernels must include it.
> So it indirectly forces other parties not to allow certain components to evolve or be removed.
> If systemd was a bit less aggressive in its strict requirements, it would be rather more portable
> Systemd certainly has a lot of good ideas, but the package as a whole is does not allow one to pick and choose the good from the bad due to its lack of modularity.
Debian looks at OpenRC Posted Aug 30, 2012 18:04 UTC (Thu) by gvy (guest, #11981) [Link]
> I can't help noticing though that the successful desktop operating
> systems do apply a well-integrated approach. In marketing (and sometimes in plain deception), that is.
> cgroups are needed, but why would you disable them?
> There's also nothing wrong with systemd's use of D-Bus.
> And besides, systemd is by no means the only program that uses cgroups.
> thus making systemd portable would be a waste of time.
>> modularity.
What is irritating in the crowd touting systemd is that viral "who would need this or that?". You never know in advance. Just ask Linus if you haven't read the story already: did he anticipate an Alpha port, or Beowulf clusters, or even thousands of users at the outset? And yet this egocentric upstream -- which is churning out a lot of code indeed -- damaged their heads enough so as to think that they can decide for the rest of us.
They can't.
Heck, I've suggested this article in the distro's devel mailing list just in case OpenRC might get considered and found useful -- we thoroughly dislike an idea of running systemd at servers.
Debian looks at OpenRC Posted Aug 30, 2012 18:24 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
> e.g. I see no reason for them (and the system in question isn't the one where stray processes are welcome in the first place).
So you prefer to blindly trust all daemon developers that they correctly process all the shutdown requests and won't hang your box during restart?
For example, BIND had a bug where it hangs indefinitely on exit if DNSSEC is used. Doubly nice on a remote server, especially if init kills sshd first. And yes, that caused me a real-life 4am trip to our datacenter to press the "reset" switch.
>> There's also nothing wrong with systemd's use of D-Bus.
>> thus making systemd portable would be a waste of time.
>Heck, I've suggested this article in the distro's devel mailing list just in case OpenRC might get considered and found useful -- we thoroughly dislike an idea of running systemd at servers.
Debian looks at OpenRC Posted Aug 31, 2012 20:16 UTC (Fri) by HelloWorld (guest, #56129) [Link]
> e.g. I see no reason for them
So what? They won't interfere with your work if you don't need them, the overhead is negligible, so please, just name *one* sensible reason for disabling cgroups. Btw, file permissions are also totally useless on my wireless router, so why doesn't anybody complain because you can't disable those? Because they don't harm anything either.
OTOH, there is a reason for enabling cgroups they're needed to reliably terminate a service, including all its children. Perhaps you don't need that, but many others (like Cyberax) like that ability.
> ...but http://secunia.com/advisories/search/?search=dbus
> Do you know the difference between PID 1 and a bunch of other processes, Mr. Downright Downplayer?
> What about accepting patches?
> What is irritating in the crowd touting systemd is that viral "who would need this or that?".
> we thoroughly dislike an idea of running systemd at servers.
Debian looks at OpenRC Posted Sep 2, 2012 11:20 UTC (Sun) by oldtomas (guest, #72579) [Link]
Thanks, rleigh, for putting things so clearly. I couldn't have.
To illustrate: I'd managed to set up a Debian system without dbus (libdbus had to go in -- even Emacs depends on it these days). One upgrade and *whoosh* this thing wants to go in[1] (i just could avert it this time by ditching recommends).
I'm on the verge of giving up on binary distros. The (binary) interdependencies are reaching an all-or-nothing level, and for some folks it's by design. I grudgingly half-accepted /bin/ls dependincy on libselinux (why? -- and no, "it's just a teeny-weeny lib", wielded down-thread doesn't convince me. It doesn't seem to scale).
Time for a "reduced" Debian derivative, perhaps: "Curmudgeon's Cut"?
--
Debian looks at OpenRC Posted Sep 2, 2012 15:39 UTC (Sun) by jackb (subscriber, #41909) [Link] I'm on the verge of giving up on binary distros. The (binary) interdependencies are reaching an all-or-nothing level, and for some folks it's by design. I grudgingly half-accepted /bin/ls dependincy on libselinux (why? -- and no, "it's just a teeny-weeny lib", wielded down-thread doesn't convince me. It doesn't seem to scale).You should take a look at Gentoo. USE="-selinux" solves that problem.
Debian looks at OpenRC Posted Sep 3, 2012 11:35 UTC (Mon) by mpr22 (subscriber, #60784) [Link] The (binary) interdependencies are reaching an all-or-nothing level, and for some folks it's by design. I grudgingly half-accepted /bin/ls dependincy on libselinux (why? Presumably to get getfilecon() so that it can support the --context command-line option. (The alternative would be to have /bin/ls invoke the dynamic linker, which doesn't seem a terribly pleasant alternative.)
Debian looks at OpenRC Posted Aug 23, 2012 22:23 UTC (Thu) by daniels (subscriber, #16193) [Link]
> 1) take a turd-of-the-week (dbus, etc.)
'Of the week'? It's ten years old!
Debian looks at OpenRC Posted Aug 23, 2012 22:41 UTC (Thu) by viro (subscriber, #7872) [Link]
OK, OK - "coprolite of the week". Pedants... (Unless I've misparsed you and you mean that no piece of software remains shitty ten years after it had been started, in which case I have a really nice bridge for you...)
Debian looks at OpenRC Posted Aug 24, 2012 11:22 UTC (Fri) by mpr22 (subscriber, #60784) [Link] The construction "X of the week" tends to bring to mind plot devices popular in episodic TV e.g. the "monster of the week" in an action show (shows up at start of episode, wreaks havoc, gets beaten by the heroes by the time the end credits roll) or the local Casanova's "girlfriend of the week" (shows up at start of episode, instantiates some allegedly-amusing personality stereotype, dumps him by the time the end credits roll) in a sitcom. Calling something that has been around in wide use for ten years "X of the week" seems a suboptimal use of the term.
Debian looks at OpenRC Posted Aug 24, 2012 1:57 UTC (Fri) by walters (subscriber, #7396) [Link]
systemd only depends on libdbus, not the message bus daemon. There's quite a bit of difference between the two.
Debian looks at OpenRC Posted Aug 23, 2012 20:42 UTC (Thu) by hummassa (subscriber, #307) [Link]
> That sounds terrible.
Why?
> What Debian really needs to do is just make a choice. They only need one init system.
Says who? Different applications and workloads may need different init systems. A person may need a "give me a text shell as fast as you can" or "restart the database really fast" or "show me my graphical desktop, even before the network is up" use cases. Some workloads are better served by upstart's logging and start-daemon-on-demand. There is no init system whose size fits all.
Debian looks at OpenRC Posted Aug 24, 2012 14:16 UTC (Fri) by HelloWorld (guest, #56129) [Link]
> Why?
Because every moving part in the system increases the amount of testing that needs to be done in order to ensure that things actually work together well. Of couse, that kind of testing never happens, so what we get isn't choice between several different, but working implementations, but choice between several different kinds of crap, the least bad of which one has to put up with.
> Says who? Different applications and workloads may need different init systems. A person may need a "give me a text shell as fast as you can" or "restart the database really fast" or "show me my graphical desktop, even before the network is up" use cases. Some workloads are better served by upstart's logging and start-daemon-on-demand. There is no init system whose size fits all.
|
|||||||||||||