LWN: Comments on "Debian decides on systemd—for now"

Debian decides on systemd—for now

mattrose — Tue, 25 Feb 2014 15:59:31 +0000

> Theo is committed to standards, compatibility and portability. Lennart is committed to the opposite -- Linux and nothing else.

Last I checked, OpenSSH only works on OpenBSD, anything else is in a "portable" directory, and it's portable, but only because of the efforts of a lot of people, I don't think Theo cares whether it works anywhere but OpenBSD.

So, you're wrong about that...

OpenSSH and portability

Kluge — Fri, 21 Feb 2014 16:12:23 +0000

>Theo is committed to standards, compatibility and portability.

I don't know how committed Theo is to standards and compatibility in general, but see my comment above about his feelings in regard to portability (for OpenSSH, at least).

Debian decides on systemd—for now

Kluge — Fri, 21 Feb 2014 15:49:33 +0000

> I mean, can you seriously imagine Apache or Sendmail or OpenSSH telling people "you must use
> one of the major Linux platforms to run our system"? :)

As I understand it, this is precisely the POV of the OpenSSH project: core development is done solely for OpenBSD. Portability is handled by a separate group.

From http://www.openssh.com/history.html:
"From the start of our own efforts, we have felt that even the original ssh code was too complicated, it simply had too many operating system dependencies to deal with. Our approach to writing completely secure and rock solid code avoids dealing with excessive differences like that. Thus, to make the entire development process easier on us all, we decided to split our core development efforts from portability developments."

Debian decides on systemd—for now

sfeam — Mon, 17 Feb 2014 07:13:18 +0000

The good stuff is here . I'm suffering from this on my Mageia 4 laptop as well.

Debian decides on systemd—for now

cyperpunks — Mon, 17 Feb 2014 06:44:30 +0000

Maybe Debian can bring in some developers to get systemd into working state too: https://bugzilla.redhat.com/show_bug.cgi?id=1057883

Debian decides on systemd—for now

lab — Sun, 16 Feb 2014 11:10:41 +0000

:-) Good one, that made me giggle (and I love the Highlander).

Debian decides on systemd—for now

bdale — Fri, 14 Feb 2014 19:22:49 +0000

Thank you.

Debian decides on systemd—for now

oconnorcjo — Fri, 14 Feb 2014 15:38:41 +0000

sysVinit was the standard for many years because it did the job. In the future, new PID 1's will come and go and eventually one will become the "new" standard. I think today's new standard is systemd because it is better. I have already heard that the BSD's are looking at systemd as well (though I don't know to what extent). One failing of UNIX when I was in college (20 years ago) was the zombie process. You would kill the parent process but the siblings would go on living (and wasting resources). I always thought that that was crazy & stupid. systemd supposedly fixes this issue and if that is true, then just for that one feature, I think it is a HUGE advance for linux to adopt it.

Debian decides on systemd—for now

pizza — Fri, 14 Feb 2014 13:39:08 +0000

"standards and compatibility" are red herrings, because OpenBSD necessarily has to interoperate with *pre-existing* specifications for network services (eg SSH, CVS, and SMTP, NTP) or find themselves completely unable to talk to anyone else, rendering the whole exercise moot. In other words, *everyone* [re-]writing a network service defined by third-party specification (eg a pile of RFCs) has to care about standards and compability.

In areas where they are not forced work with the outside world (eg kernel+libc, syscall interface, system configuration, and even the userspace ABI) they are completely non-portable (even when only compared to other BSDs) and non-standards compliant (unless you consider themselves to be compliant with themself).

(Nevermind you're trying to draw a comparison between a by-definition interoperable network service and something that *launches* network services. Apples and oranges...)

So, two of three of your items are irrelevant, you just now added a fourth ("interoparability") which is equivalent to the first two (and still irrelevant), and the third has been demonstrated to be completely false using the very documentation you accused me of not reading.

Even if one accepts your attempt to move the goalpoasts, you still haven't supported your original assertion that Theo de Raat (and the other core OpenBSD developers) are more dedicated to "standards, compatibility, and interoperability" than the systemd developers.

Debian decides on systemd—for now

Thue — Fri, 14 Feb 2014 08:47:41 +0000

According to https://lwn.net/Articles/584175/ , each Linux distro often had their own initscripts per package. When sysv init scripts are not even portable across Linux distributions, that can't be called anything but unportable.

Debian decides on systemd—for now

ebirdie — Fri, 14 Feb 2014 08:37:22 +0000

+1 expressing my support to the parent commentor and madscientist, you are both right on spot I can't bring anything to but just backup up with my experience from systems maintenance. Just a familiar term to describe my fears - and very deep irritation - with the vision in systemd: dependency hell.

I'm ready for systemd and I support that Debian makes a decision here and now to systemd than prolong the process. I fully trust both the decision-makers and the process they came to conclusions. The future will tell whether the old dogs fall in love with systemd and be quiet or feel the pain and rejoice at reinvented bone, init.

Just my cents to the discussion.

Debian decides on systemd—for now

khim — Fri, 14 Feb 2014 08:11:48 +0000

Google is plenty clear in it's position: upstart tested and works, it's fast [enough] and thus there are no need to change it. It's not as if they looked at systemd and rejected it, no, they have never looked and since they have patches which tie the rest of ChromeOS to upstart switch to systemd is not trivial.

As you can see they are very, very, very pragmatic and not wedded to upstart at all.

Debian decides on systemd—for now

dgm — Fri, 14 Feb 2014 07:41:18 +0000

Which kind of portability are you talking about?

Debian decides on systemd—for now

rodgerd — Fri, 14 Feb 2014 02:16:20 +0000

> Actually, until fairly recently, most OSes (with MS being the notable exception of course) used BSD init or SysV init, or something compatible.

(MS are hardly the only notable exception, unless your world of "most OSes" is sufficiently small to exclude VMS, AS/400, and so on and so forth. And given that SMF has been around 9 years, upstart is almost 8, and launchd is also 9 years old, "recently" is torturing the language a bit. People have been revamping the Unix init/process management space for a decade now.)

No one implementation of which is compatible with another platform. That's even more true when considering the assumption a particular shell will be /bin/sh and the many and varied possible permutations of the system layout. It's not like you can take a script from Fedora and assume it'll work on Debian, never mind BSD. So that would be "not very portable at all."

systemd is actually pretty late to the game, which is IMO a good thing. It means it hasn't been tempted to e.g. have XML based config files like SMT, because that's not fashionable any more. There's been time to learn the lessons of previous attemps to do this. One may or may not like all the decisions (I really don't like binary logs, for example), but it's not like this hasn't been a common idea.

> I'm dismayed at the recent proliferation of incompatible init systems.

I'm dismayed that so many people seem to think "it sort of worked in 1982" is a good reason to never ever change anything.

> I can't help wonder what the Apache folks think about all this. Or the various mail server projects. Or all the other folks working on assorted cross-platform daemons.

Given they already have to either (a) tailor scripts to every single distribution or (b) leave it up to the distro I fail to see how things are in any way worse.

Debian decides on systemd—for now

vonbrand — Fri, 14 Feb 2014 02:03:05 +0000

OK, so the fundamental difference is ... <drumroll> systemd and Linux are developed with exactly the same strategy: each crowd develops what they consider is right, if others don't agree, it's up to them to come up with their own solutions</drumroll>. Many thanks for that earthshattering insight!

Debian decides on systemd—for now

rsidd — Fri, 14 Feb 2014 01:43:02 +0000

I think you guys do not understand what "interoperability" means. And I did not just say "portability". I said "standards, compatibility and portability". OpenSSH satisfied the first two from day 1, and the last very soon after. Other OpenBSD projects -- OpenCVS, OpenSMTPD, etc -- are compatible and portable too, if less successful in the wider world than OpenSSH.

Debian decides on systemd—for now

vonbrand — Fri, 14 Feb 2014 00:28:42 +0000

Oh, come on. The mess of SysV init scripts is almost as far from portable as humanly possible.

Debian decides on systemd—for now

xtifr — Thu, 13 Feb 2014 23:49:20 +0000

And since Ubuntu is now alone in its use of Upstart, upstream projects are free to say "we don't support single-distro solutions", and depend directly on systemd features without fallback.

That's true only for Linux-specific projects! I mean, can you seriously imagine Apache or Sendmail or OpenSSH telling people "you must use one of the major Linux platforms to run our system"? :)

Since I try to avoid using platform-specific software wherever possible (I may not have any immediate plans to switch to BSD, but I'd really like to retain the option, and I always try to support BSD at least in whatever I might write), such a statement would probably result in that software being purged from my system, even though I run Debian.

Debian decides on systemd—for now

xtifr — Thu, 13 Feb 2014 23:29:57 +0000

It seems that historically pretty much every OS has written their own init system implementation.

Actually, until fairly recently, most OSes (with MS being the notable exception of course) used BSD init or SysV init, or something compatible.

As someone whose interest in providing portable, cross-platform daemons is much higher than his interest in nursing every possible second out of the startup time for one particular platform (even though it happens to be the platform I use for my desktop), I'm dismayed at the recent proliferation of incompatible init systems.

Yes, I'd like to have Linux work better and be more powerful. But I still hate people who make portability their lowest priority. Open, cross-platform standards are one of the main things that helped Linux get where it is today, and I really hate to see them abandoned by the very people who benefited from them in the first place.

I can't help wonder what the Apache folks think about all this. Or the various mail server projects. Or all the other folks working on assorted cross-platform daemons.

Still, as long as systemd maintains backwards compatibility with Sysv init, I'm not going to sweat it too much.

Debian decides on systemd—for now

jspaleta — Thu, 13 Feb 2014 23:11:02 +0000

The lack of evidence anywhere that Google is patching/fixing even a forked upstart for any of the deep problems in upstart I think screams loudly in its silence. And upstart as deep problems in its design. Even if they were just patching it and publishing their own fork of the codebase to avoid the CLA issue..that would be some indication that Google is invested into upstart long term. But I'm not aware of that going on.

That being said, Chrome isn't a dynamic or complex an init target right? It's not really a general purpose desktop or server is it where you can install lots of addon services? As a typical Chromebook user, how much control do you have over what services are starting up or not?

It's most likely that Chrome represent a very well defined init target with a well defined, nearly uniform, set of services that will be running on all installs and that upstart's service management suffices without running afoul of the problems in the event model that other service configurations will hit.

Debian decides on systemd—for now

Thue — Thu, 13 Feb 2014 23:00:32 +0000

> systemd is significantly different from other common components of the system such as glibc, bash, and coreutils and that the posited (but unproven) ubiquity of those components isn't a justification for systemd.

glibc is replacable, if you write a new library with the same interface. logind is replacable, if you write a new implementation with the same interface. I fail to see the significant difference.

Debian decides on systemd—for now

jspaleta — Thu, 13 Feb 2014 22:50:37 +0000

Yes. I think its important to really understand the logind situation.

The most important thing to note is that noone has yet gone through the trouble of building an independent implementation of a daemon to service the documented and stable D-BUS protocal. Nobody.

What Ubuntu has done is forked logind as a quick fix to avoid needing to run systemd as init. Logind prior to v205 was written with the PAXControlGroups multiple hierachy cgroups API in mind. logind prior to v205 did not depend on a single cgrourp manager entity and was free to write into the cgroup heirarchy itself..and it did so. But as of v205, systemd's provided logind daemon talks to the cgroup manager on the system as per the roadmap and guidance provided by kernel maintainers.

So it a lot of ways what we are seeing in v205 is a direct result of the kernel cgroup maintainer's decision (discussed widely in 2012!) to require a single writer model as part of cleaning up the cgroups API. systemd's implementation of the logind service provider as of v205 conforms to kernel's side expectations with regard to that.

The difficulty presented by logind change as of v205 has more to do with the fact that Ubuntu chose to fork logind as implemented by systemd instead of rolling an independent implementation to provide logind dbus API. Ubuntu could have chosen to spend the resources to re-implemented logind protocol using an independent daemon codebase that did not rely on cgroups at all. Using kernel cgroups is a design choice internal to the service talking the protocol...its not exposed in the protocol.

The Ubuntu devs are working hard to spin up cgmanager to be the single provider so they can patch logind v205 and beyond to work with cgmanager as a provider because they are still relying on a logind implementation that uses cgroups internally. And let me remind you cgmanager doesn't have a documented stable API yet for cgroup manipualtion. So the only cgroup manager API available for logind to support at present is systemd's.

All of this is entirely implementation details inside the scope of how a single logind daemon implementation can choose to work. The applications talking to it via D-BUS don't care about whether the logind daemon uses cgroups or not... or uses slices or not and systemd devs are not disrupting the stable protocol or creating new expectations on consumers at all. And given that systemd's implementation of logind service provider has always used cgroups heavily as part of its design, then it makes perfect logical sense for newest logind to require a central writer now that its been decided by the kernel cgroups maintainer that its the path forward for the cgroup rewrite.

I can't stress this enough, nobody as far as I know, is working on a independent implementation of the logind daemon to provide the stable documented logind protocol. I think that was a mistake on Ubuntu's part to fork this daemon instead of writing an independent implementation. If they had their own independent implementation, none of the changes in logind v205 would have impacted their ability to provide a working logind service and Debian would have a drop-in replacement to provide logind right now without the threat of holding up systemd or GNOME.

-jef

Debian decides on systemd—for now

rahvin — Thu, 13 Feb 2014 22:45:59 +0000

I wouldn't call it irrelevant to Google. Google put Upstart into Chrome before systemD existed. Momentum has carried them on upstart but with Google's efforts to mainline their linux stacks, to reduce their maintenance load, it may come to pass that future versions of Chrome move to systemD. Only time will tell.

Debian decides on systemd—for now

pizza — Thu, 13 Feb 2014 21:54:02 +0000

> Second, as I understand it, logind is actually a primary example _supporting_ the people concerned about systemd. Prior to systemd 205 logind was indeed separable from systemd, and Ubuntu uses logind version 204 (because GNOME requires logind). But starting with systemd 205, now logind is no longer usable without systemd, which means that any system must either switch to systemd, stay with version logind 204 and maintain it themselves, replace logind with something equivalent on at least an API level (and maintain THAT), or give up the features in GNOME that require it.

Or, let me rephrase what you're saying. (And just FYI, I'm not referring to "you" specifically)

You're unhappy that the logind authors are not doing the work necessary for you to use new functionality they've written (ie their work), when that new functionality depends on something you don't like, and then complaining that you'll have expend ongoing effort to work around the implications of removing that dependency yet still take advantage of the ongoing work that the logind authors continue to create.

Oh, the reasons for this complaint are because that the logind authors might possibly change something in the future, and that other third parties may independently chose to depend on those changes.

This entitled attitude really irritates me, because it both demands third parties do work on your behalf, while also insulting their integrity.

> The result looks to some, especially those old enough to remember the battles of the 90's :-), like a classic embrace, extend, extinguish play.

Except for one crucial difference -- the EEE play relied on proprietary software (and the BSD licenses that enabled them), and that isn't possible here due to systemd (et al) being released under the GPL.

Debian decides on systemd—for now

peter-b — Thu, 13 Feb 2014 21:53:25 +0000

it doesn't matter if it's running as a separate process if all the interfaces to it are private, subject to change at the whim of systemd, and unable to be replaced or run without the rest of systemd.

systemd-logind's interface is covered by systemd's Interface Stability Promise, so it's not subject to change on a whim. If someone else wants to make a competing implementation of the logind interface to replace systemd-logind, then they can do so.

systemd-logind uses the public interfaces to systemd's PID 1, which are also covered by the Interface Stability Promise. If you want to run systemd-logind without the rest of systemd, then you will need to provide an alternative implementation of those interfaces.

None of the interfaces that logind exposes or uses are "private", as far as I'm aware. Of course, you may have an example of one, and I would be delighted if you could highlight it for me.

Now, I suspect you are alluding to the changes in systemd 205. That was a case where a new (public) interface was added to the systemd PID 1, and systemd-logind was modified to utilise it. May I venture to suggest that (a) the systemd devs wouldn't have added the interface unless it did something they consider novel and useful and (b) if they think the interface is useful, it fairly obviously follows that they'd want to modify related software make use of it! It's certainly hardly evidence of unreasonable, incompetent or unfriendly behaviour.

This scaremongering about concealed interfaces that shift like quicksand beneath the feet of users and reimplementers (all subject to the malicious whim of the dark and mysterious cabal of systemd hackers) is neither accurate nor a valuable contribution to the init system discussion. Please stop it.

Debian decides on systemd—for now

pizza — Thu, 13 Feb 2014 21:30:41 +0000

The fact that "Portable OpenSSH" is developed with the tacit approval of (and shares many contributors of) the core OpenBSD OpenSSH project doesn't make it any less of a fork.

But back to my original point.

If anything, Theo is more of a poster child for "my way or the highway" and "I don't care about implications for other systems, I'm making mine the best there is" attitudes than is attributed (often deservedly) to Pottering, and that attitude has helped make OpenBSD what it is today.

OpenBSD's kernel (and libc) is a world unto itself; anything that interacts with the kernel isn't even portable to the other BSDs, much less Linux. (And why should it? I don't say this as criticism; they are doing what they want, for their own goals, and appear to be successful)

Meanwhile, OpenBSD is only relevant to the vast majority of Linux users (and distributions) due to it being the upstream of Portable OpenSSH and the occasional security problem the OpenBSD folks find in 3rd-party software.

So, please, explain how Theo is an advocate of portability, and how his attitude (and practice) is different/better than Lennart's -- Because on the face of it, Lennart seems to come out on top in such a comparison.

Debian decides on systemd—for now

dlang — Thu, 13 Feb 2014 21:07:58 +0000

> Look at it this way: what is the likelihood of "the next systemd" being developed if instead of just replacing PID 1 with something that provides a simple set of well-defined behaviors, you must also replace all the other aspects that systemd now provides before anyone can use it?

This is a key difference between kernel development and "Desktop Environement" development (including systemd)

On the kernel side, Linus expects that some day he will get tired of running the kernel or that there will be reasons for the community to want him to stop running it. He also expects that some day there will be a smaller, leaner, faster kernel developed that will replace the old, crufy, fat, and slow linux kernel of the day.

His development process and tools make it so that the only thing preventing these from happening is that people are happier with the linux kernel under current management.

On the other side, the developers don't understand the idea that anyone would ever not want to use their software, and anyone who disagrees with them is wrong, a fossle who refuses to get with the times, or incompetent.

Debian decides on systemd—for now

khim — Thu, 13 Feb 2014 20:59:40 +0000

I think you've set some kind of record. You've talken a project with a very-well documented history publicly avalaible on it's web site and you try to construct some kind of alternate reality on another public web site. Don't you think that it's… well… too much?

Please go and read about OpenSSH history! Then you'll find out that you should question not the existence of OpenSSH-portable, but the existence of OpenSSH proper!

Before OpenBSD and Theo involvement OSSH supported at least the following environments:
        386BSD 0.1; i386
        AIX 3.2.5, 4.1; RS6000, PowerPC
        BSD 4.4; several platforms
        BSD/OS 1.1, 2.0.1; i486
        BSD/386 1.1; i386
        ConvexOS 10.1; Convex
        DGUX 5.4R2.10; DGUX
        FreeBSD 1.x, 2.x; Pentium
        HPUX 9.0x, 10.0; HPPA
        IRIX 5.2, 5.3; SGI Indy
        IRIX 6.0.1; Mips-R8000
        Linux 1.2.8 Slackware 2.1.0; i486
        Mach3; Mips
        Mach3/Lites; i386
        Machten 2.2
        NetBSD 1.0A; Pentium, Sparc
        OSF/1 3.0, 3.2, 3.2a; Alpha
        Sequent Dynix/ptx 3.2.0 V2.1.0; i386
        SCO Unix; i386 (client only)
        SINIX 5.42; Mips R4000
        Solaris 2.3, 2.4; Sparc
        Sony NEWS-OS 3.3 (BSD 4.3); m68k
        SunOS 4.1.2, 4.1.3, 4.1.4; Sparc
        SysV 4.x; several platforms
        Ultrix x.x; Mips
        Unicos 8.0.3; Cray C90

OpenBSD developers initially had zero interest in supporting these other environments, they removed all the the kludges (which were needed to support that zoo) in their efforts to cleanup the code and went with “OpenBSD-only” approch. Theo himself is listed as guy who removed these non-portabilities which made the code harder to read (but which were required to support wide range of non-completely-standard-OSes).

Since these versions had many features which original version lacked various non-OpenBSD groups got very, very interested. After that Damien Miller, Philip Hands, and handful of others started porting OpenSSH to Linux and various other Unix operating systems. Note: Theo is surprisingly missing even if he was featured prominently in the first, “OpenBSD-only”, version.

This is not something I've cooked up from some random sources, it's all written right there, on the web site of OpenSSH itself!

I'm pretty sure if various non-OpenBSD will become very, very interested in systemd then people (not necessarily Lennart) will be able to create portable systemd fork. Indeed, nosh can be considered a kernel for such an effort—but I just don't see interest from various BSDs, MINIXes and QNXes in such a fork.

Debian decides on systemd—for now

dlang — Thu, 13 Feb 2014 20:57:50 +0000

it doesn't matter if it's running as a separate process if all the interfaces to it are private, subject to change at the whim of systemd, and unable to be replaced or run without the rest of systemd.

Debian decides on systemd—for now

madscientist — Thu, 13 Feb 2014 20:25:16 +0000

First, that has nothing to do with the "core of my argument" which was that, contrary to the post I'm replying to, systemd is significantly different from other common components of the system such as glibc, bash, and coreutils and that the posited (but unproven) ubiquity of those components isn't a justification for systemd.

Second, as I understand it, logind is actually a primary example _supporting_ the people concerned about systemd. Prior to systemd 205 logind was indeed separable from systemd, and Ubuntu uses logind version 204 (because GNOME requires logind). But starting with systemd 205, now logind is no longer usable without systemd, which means that any system must either switch to systemd, stay with version logind 204 and maintain it themselves, replace logind with something equivalent on at least an API level (and maintain THAT), or give up the features in GNOME that require it.

I've heard differing opinions on how feasible it is to replace logind and maintain that so I won't speak to that. I also won't speak to how reasonable it was to make this change in logind: I have no idea what the technical issues involved were.

The important point here is that regardless of the technical merits or the intentions of the people behind the decisions, the result looks to some, especially those old enough to remember the battles of the 90's :-), like a classic embrace, extend, extinguish play. The more core components are intertwined with systemd, and the more upper layers of the system are modified to require those core components, the more rigid the entire system becomes and the less experimentation and radical change is possible.

Look at it this way: what is the likelihood of "the next systemd" being developed if instead of just replacing PID 1 with something that provides a simple set of well-defined behaviors, you must also replace all the other aspects that systemd now provides before anyone can use it?

Debian decides on systemd—for now

peter-b — Thu, 13 Feb 2014 20:19:42 +0000

> But things like the logind interface can be implemented in a non-PID 1 process.

systemd's implementation of the logind interface is implemented in a non-PID 1 process...

Debian decides on systemd—for now

luya — Thu, 13 Feb 2014 19:05:03 +0000

It could be a blind obsession to anything related to Debian as good and Red Hat bad. Despite clear clarification about systemd, some people simply chose to believe their own opinions as facts like systemd being a Red Hat tool just because Poettering started that project as Red Hat employee. Now change Red Hat by Debian and see how those people will scream systemd is the best init ever made from Debian developer.

Debian decides on systemd—for now

Thue — Thu, 13 Feb 2014 18:54:14 +0000

> systemd is a completely different thing, because there can be only one PID 1

But things like the logind interface can be implemented in a non-PID 1 process. How else are Ubuntu running logind without systemd? http://www.phoronix.com/scan.php?page=news_item&px=MT...

So since what seems to be is the core of your argument is based on a false premise, then...

Debian decides on systemd—for now

bronson — Thu, 13 Feb 2014 18:41:22 +0000

Booting will be called The Quickening.

Debian decides on systemd—for now

rsidd — Thu, 13 Feb 2014 17:59:38 +0000

The whole reason for the existence of OpenSSH-portable is interoperability. If they cared only about OpenBSD, why would they bother with making a portable version, rather than let Red Hat or Debian do the hard work? Its goals are exactly the same as that of the OpenBSD version. Its features are the same -- none added, none removed. The only difference in its code repository is the portability stuff. So I don't know what you are talking about, and I doubt you do, either.

Debian decides on systemd—for now

pizza — Thu, 13 Feb 2014 17:44:55 +0000

Given that OpenSSH and Portable OpenSSH are maintained independently, have different goals, and even have separate code repositories.. It's a fork by any technical definition.

(and that information is also on the Portable OpenSSH webpage, FYI. Maybe you need to take your own advice?)

Meanwhile; A simple "you are incorrect, this is why" reply would have sufficed, without resulting to "hater" insults that accomplish nothing but make you look like an imbecile.

But I digress.

Theo De Raat has done (and continues to do) many great things for the Free Software community. He is many things, but a champion of interoperability is not one of them.

Debian decides on systemd—for now

RobSeace — Thu, 13 Feb 2014 17:34:56 +0000

> because there can be only one PID 1

This makes me want to write a new init and name it Highlander...

Debian decides on systemd—for now

rsidd — Thu, 13 Feb 2014 17:29:30 +0000

"Scott James Remnant, the originator of Ubuntu,"

Ugh, of course I meant the originator of upstart.

Debian decides on systemd—for now

rsidd — Thu, 13 Feb 2014 16:42:56 +0000

Time will tell whether it's worth it. Right now the biggest Linux vendor is neither Red Hat nor Ubuntu, but Google. The other large Unix vendor is Apple. The systemd/upstart debate is irrelevant to Apple and it may well prove to be irrelevant to Google too.

Debian decides on systemd—for now

rsidd — Thu, 13 Feb 2014 16:38:49 +0000

It's not a fork. It tracks the OpenBSD version, is updated each release and is maintained officially by the OpenSSH team. As you'd know if you did your research instead of relying on BSD-haters for your talking points. (No, not linking -- it's there on the official webpage if you'd bother to look.)