User: Password:
|
|
Subscribe / Log in / New account

Debian looks at OpenRC

Please consider subscribing to LWN

Subscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this page to join up and keep LWN on the net.

By Jake Edge
August 22, 2012

While Debian has discussed systemd—and Upstart—over the past year or more, that's not the whole story: another potential init replacement has appeared on the debian-devel mailing list. OpenRC is a Gentoo Linux project that was proposed as an alternative to the venerable System V init (sysvinit) that is currently the Debian default. That proposal spawned a long thread, even by debian-devel standards, and a more recent revival of the topic is adding more to the discussion. Though OpenRC has some features that sysvinit lacks, it doesn't bring the number of new features that systemd or Upstart do, so it makes some in the Debian community wonder whether it makes sense to add yet another init replacement into the mix.

OpenRC developer Patrick Lauer suggested that Debian look at OpenRC back in April. It is, he said, a "modern, slim, userfriendly init system with minimal dependencies". It would add support for stateful services (e.g. only one instance will be running at a given time), and dependency-based init scripts, without requiring all of what something like systemd requires ("dbus? udev? on my server?! and you expect a linux 3.0+ kernel? waaah!"). It would be a step up from sysvinit, while still in keeping with the "Unix way". In addition, it supports both Linux and the BSDs, which would eliminate one of the bigger gripes against systemd.

But an incremental improvement to init is not what some are looking for. To many, sysvinit and other shell-script-based solutions have not kept up with the changing hardware and kernel environment, so an event-based init is the right way forward. As Arto Jantunen put it:

Reliability in the case of modern kernels and modern hardware means event based, not static. The hardware in a modern computer comes and goes as it pleases (usb devices being the worst example, but scanning for pci or sata busses and loading drivers isn't exactly instant in all cases either), and the kernel has little choice in the matter. It can either sleep until "everything is surely detected by now" before passing control to userspace, or pass control and the problem along (by providing event notification when the device set changes). The kernel made its choice about this years ago, and we have been living on borrowed time and kludges since then.

As might be expected, there are plenty of folks who don't quite see things that way. While there are vocal advocates of systemd—and rather less vocal Upstart advocates—there are numerous opponents as well. OpenRC might provide something of a middle ground as Roger Leigh described:

While as others have mentioned that ideally a more dynamic init system such as systemd or upstart is where I think the general consensus is (we all know that sysvinit/insserv is flawed in many ways, even if we can't agree on what should replace it), there is always the possibility of having OpenRC as a sysvinit alternative in the interim, or potentially as a systemd/upstart alternative longer term.

To that end, Leigh started looking more closely at OpenRC, with an eye toward packaging it for Debian. One problem that he noted early on was the lack of support for LSB dependencies in the init scripts. The LSB headers are comments that specify the runtime dependencies for each init script. OpenRC has its own dependency system, but Leigh believed that LSB dependency handling could be added to OpenRC.

Over the intervening months, that is exactly what happened. On August 9, Benda Xu posted an intent to package (ITP) for OpenRC, which restarted the discussion. Leigh noted that Xu had gotten OpenRC to work with the LSB-based Debian init scripts, so that it could be a replacement for the sysv-rc package (which handles changing runlevels, starting and stopping services, and so on), while still using the init and scripts provided by sysvinit underneath. In addition, the OpenRC upstream is working on ways to allow other tools to access its dependencies, which would allow systemd or others to use OpenRC scripts. He concluded:

Working on getting OpenRC to work on Debian is not without value. For me, the entire point of the exercise is to explore the [feasibility] to port it and evaluate it as an alternative/replacement for sysv-rc; this is almost completely orthogonal to work on systemd/upstart, which will for the most part be unaffected by this.

Supporting multiple init systems is not without a cost, of course. There are now (or soon will be) at least four different kinds of configuration for init "scripts" (sysvinit, OpenRC, systemd, Upstart). While systemd and Upstart can use existing init scripts, and OpenRC is getting there as well, doing so loses much of the benefit of the alternatives. To some, there is simply an impedance mismatch between static dependency-based systems and those that are event-driven—though systemd advocates might not completely agree with the "event-driven" characterization. As Russ Allbery put it:

And lest someone think this is a theoretical exercise, we *frequently* get bugs filed against packages like OpenAFS, the Kerberos KDCs, or OpenLDAP that are boot-order-dependent and network-dependent and either don't start or start in unuseful ways or at unuseful times because of lack of event notification for when interfaces are *actually* ready or when network devices are *really* available.

Allbery said that these kinds of problems were not easily solvable with the existing init scripts: "The alternative is to add [significant] additional complexity to every package like those listed above that needs the network to loop and retry if the network isn't available when it first starts." That would be a "huge waste of effort".

One of the potential blockers for systemd, though, has been its reliance on Linux-only features, which makes it problematic for Debian GNU/kFreeBSD (and Debian GNU/Hurd down the road). OpenRC might not provide all of the features that systemd (and Upstart) do, but it could be enough of an upgrade to sysvinit that it makes sense to make that switch. That might actually pave the way for an event-driven init default for Debian GNU/Linux as Philip Hands described:

As a largely disinterested observer, it seems that this might at least provide a route to being able to provide enough support of the the features that make the systemd/upstart folk dizzy with excitement, such that non-linux platforms don't end up acting as a blocker for one of those two to be adopted for linux, while OpenRC covers non-linux enough so that init-agnostic start-up scripts can work anywhere.

At least some in the Debian community are particularly annoyed by the systemd team's unwillingness to take patches for portability to kernels beyond Linux. That led Adam Borowski to jokingly dismiss OpenRC because it lacks "a hostile upstream". More seriously, Leigh pointed out that OpenRC uses some of the same features as systemd, but does so with portability in mind:

OpenRC can (on Linux) use cgroups and hence do some of the more advanced stuff that systemd does. Yet it still runs on other platforms. This is in part due to the fact that OpenRC is written to be portable, while the systemd developers have an [astoundingly] bad attitude with respect to this. It would be perfectly possible for systemd to support other platforms if they really wanted to; it probably wouldn't even be that hard.

Others see it somewhat differently (of course). Maintaining a package for multiple platforms has its costs, and for a low-level package like systemd those costs may be rather high. It's not that the systemd upstream is "hostile", according to Matthias Klumpp, but that systemd is difficult to port and its developers don't want to maintain an #ifdef-heavy code base. Instead, the systemd folks suggest forking systemd and maintaining a parallel repository for any ports. But that isn't easy, Klumpp said: "So far nobody has created a non-Linux fork of systemd, and the reason is mainly that it is too much work."

There is also the underlying question of just how much "choice" there should be in a distribution's init system. Setting aside the "Linux is about choice" disagreements that always seem to arise in these kinds of discussions, there is a real question about how many different options Debian can and should support. As Allbery noted, Debian does not support switching to a different C library, for example. But Faidon Liambotis countered that it was only because no one had ever tried to show the "viability and usefulness" of switching to something other than glibc. Furthermore, things like kFreeBSD or building Debian with LLVM did not come about by some kind of consensus, rather it was due to someone deciding to make it work.

For init systems, though, Leigh believes that if OpenRC proves to be a viable replacement, it should supplant sysv-rc, rather than providing a choice. It wouldn't resolve the question of defaulting to an event-driven init (for Linux at least), but it would allow the rest of the Debian community to "get on with life while the upstart and systemd folk take chunks out of one another for a decade or so", as Hands put it.

While Linux may not be about choice exactly, its users are certainly accustomed to being able to fairly easily switch between different technologies: distributions, kernels, desktops, mail servers, web browsers, and so on. In some respects, Debian users are even more acclimated to a wide variety of choices. Its package repository is renowned for its breadth, and the distribution as a whole seems intent on providing choices whenever it is technically feasible. It is too soon to say for sure, but the addition of OpenRC may well provide a bridge that would upgrade init for those who aren't convinced of the "event-driven future", while staying out of the way of the systemd and Upstart efforts.


(Log in to post comments)

Debian looks at OpenRC

Posted Aug 23, 2012 3:19 UTC (Thu) by dlang (subscriber, #313) [Link]

If we have a good dependency based init, it seems like it would not be that big a stretch to add a dependency on some state, and then let whatever other process is appropriate set that state.

This could be as simple as waiting for a special file to be created, or for a message to be written to a known named pipe.

Debian looks at OpenRC

Posted Aug 23, 2012 16:11 UTC (Thu) by kaol (subscriber, #2346) [Link]

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.

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:
1) take a turd-of-the-week (dbus, etc.)
2) make systemd depend on it
3) push patches adding dependencies on said turd to as many packages as you can, solidifying the damn thing to the point where it would be very hard to avoid even on the systems that are not systemd-infested.
4) pick the next turd, repeat the whole thing.

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 (guest, #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,
That's an easy claim to make given that you provide no arguments to back it up and it's thus essentially impossible to refute. I can't help noticing though that the successful desktop operating systems do apply a well-integrated approach.

> 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.
Systemd doesn't strictly require autofs. cgroups are needed, but why would you disable them? The overhead is negligible if you disable all cgroup controllers, none of which are required for systemd. There's also nothing wrong with systemd's use of D-Bus. It doesn't require running dbus-daemon, and there's nothing wrong with the protocol; in fact, it would have been brain-dead to use anything else, we don't need yet more NIH syndrome on the linux desktop.

> So it indirectly forces other parties not to allow certain components to evolve or be removed.
By that logic, every kind of code reuse is bad because it forces the code that is being reused to keep a stable interface. I'm sorry, but that's downright bullshit. If the cgroup stuff is actually so bad that the kernel folks want to remove it again, it shouldn't have gone in in the first place. They've made their bed, now they must lie in it. And besides, systemd is by no means the only program that uses cgroups.

> If systemd was a bit less aggressive in its strict requirements, it would be rather more portable
Every Unix-like OS ships its own init system: SMF, launchd, BSD init etc.. Do you actually expect any of those to give up their init system in favour of systemd? I certainly don't, thus making systemd portable would be a waste of time.

> 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.
This is yet more nonsense, systemd is quite configurable. Just look at its configure script...

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

> There's also nothing wrong with systemd's use of D-Bus.
...but http://secunia.com/advisories/search/?search=dbus

> And besides, systemd is by no means the only program that uses cgroups.
Do you know the difference between PID 1 and a bunch of other processes, Mr. Downright Downplayer?

> thus making systemd portable would be a waste of time.
What about accepting patches?

>> modularity.
> its configure script...
Next time you buy bread hope they won't suggest you a grocery shop instead; but if they accidentally do, please make a mental note that it isn't you asked for.

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.
>...but http://secunia.com/advisories/search/?search=dbus
Systemd uses dbus for communication between trusted processes as a simple form of RPC. It can run totally fine without system-level bus.

>> thus making systemd portable would be a waste of time.
>What about accepting patches?
Has anyone actually bothered to create a compat patch for systemd?

>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.
Why? Because of various phobias?

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
Yeah. So how many of those redundant are reports because dozens of different distros ship the same fix for the same problem? How many of them affect d-bus-related stuff that isn't required for systemd (dbus-daemon, dbus-qt, dbus-glib etc.)? How many are made irrelevant by the fact that you need root permissions to even connect to systemd's sockets? Can you even name *one* real problem, that was caused by systemd's use of dbus, security or otherwise?

> Do you know the difference between PID 1 and a bunch of other processes, Mr. Downright Downplayer?
rleigh's original argument was that systemd shouldn't make use of cgroups because then it's hard to remove/modify them if they turn out to be a bad idea. In that context, whether the PID is 1 or something else doesn't make any difference whatsoever.

> What about accepting patches?
What for? As I said, other operating systems already have their own init systems and it's unlikely they'll switch to systemd (the BSDs aren't exactly famous for loving the LGPL). OTOH, making systemd portable will likely compromise its maintainability. It's all pain and no gain.

> What is irritating in the crowd touting systemd is that viral "who would need this or that?".
systemd can do everything sysvinit does and more. Nobody stops you from launching a shell script from a systemd unit if that is really what it takes, but systemd units cover the vast majority of cases just fine and they're easier to write and not as ridiculously inefficient as shell scripts.

> we thoroughly dislike an idea of running systemd at servers.
And yet you completely failed to name any sensible reason for that conviction.

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"?

--
[1] among other goodies with the suffix "-kit"

Debian looks at OpenRC

Posted Sep 2, 2012 15:39 UTC (Sun) by jackb (guest, #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.
Name one inherent reason a single init system can't do all of those things well.

Debian looks at OpenRC

Posted Aug 25, 2012 17:16 UTC (Sat) by raven667 (subscriber, #5198) [Link]

> Klumpp said: "So far nobody has created a non-Linux fork of systemd, and the reason is mainly that it is too much work."

Which makes it clear why the systemd team isn't jumping up, dropping everything and sacrificing all that time on portability. They wouldn't be where they are today if portability was made a goal at the project outset. I still hope that one of the BSDs pick it up and make their own portable version because I think the systemd approach is superior to the old systems. BSD projects like OpenSSH show the way it can be done.

Debian looks at OpenRC

Posted Aug 27, 2012 10:22 UTC (Mon) by anselm (subscriber, #2796) [Link]

They wouldn't be where they are today if portability was made a goal at the project outset. I still hope that one of the BSDs pick it up and make their own portable version because I think the systemd approach is superior to the old systems.

In particular, if anyone could demonstrate a way of doing this in a »minimally invasive« manner, the systemd developers might be brought around to supporting the required changes when the code has otherwise settled down. It makes a lot of sense to produce a Linux version of systemd first and then see what, if anything, can be done about portability.

On the other hand, it would mean somebody with a stake in BSD would have to do it, and that is unlikely to happen because of NIH.

Debian looks at OpenRC

Posted Aug 28, 2012 13:21 UTC (Tue) by HelloWorld (guest, #56129) [Link]

> In particular, if anyone could demonstrate a way of doing this in a »minimally invasive« manner,
It can't be done. This email mentions an incomplete list of non-portable interfaces that systemd uses.
http://lists.debian.org/debian-devel/2011/07/msg00281.html
The only way to make systemd portable is to essentially rewrite it.

Debian looks at OpenRC

Posted Aug 31, 2012 18:30 UTC (Fri) by moltonel (subscriber, #45207) [Link]

> On the other hand, it would mean somebody with a stake in BSD would
> have to do it, and that is unlikely to happen because of NIH.

While that (may be) true of the FreeBSD/OpenBSD/etc crowd, it's obviously not the case of the Gentoo/BSD and Debian/BSD one.


Copyright © 2012, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds