Shared publicly  - 
I have skimmed through the debian-devel threads regarding systemd a bit. I didn't read all of it, it's just too much and highly repetitive. But here are a few points I'd like to make, for those who care:

Whether Debian chooses systemd or Upstart has major implications on the future too, so you shouldn't only look at what is now, but also keep in mind what will come next. And there are at least two areas where opting for Upstart will mean you shut out Debian of major changes.

One is the cgroup situation. The kernel folks want userspace to have a single arbitrator component for cgroups, and on systemd systems that is now systemd, and you cannot isolate this bit out of systemd. The Upstart world has exactly nothing in this area, not even concreter plans. There are dreams of having some secondary daemon taking the cgroup arbitration role, but that's a complex task and is nothing you can just do at the side. I am pretty sure the Ubuntu guys don't even remotely understand the complexities of this. Control groups of course are at the center of what a modern server needs to do. Resource management of services is one of the major parts (if not the biggest) of service management, and if you want to stay relevant on the server you must have something in this area. The control group stuff exposes an API. The API systemd exposes is very systemd-specific, it is unlikely that whatever solution Upstart one day might come up with will be compatible to that. Of course, at that time a major part of the Linux ecosystem will already use the systemd APIs...

The other thing is kdbus. The userspace of kdbus pretty much lives inside of systemd. Bus activation work will be using the same mechanisms as socket activation in systemd, and again you cannot isolate this bit out of systemd. Basically the D-Bus daemon has been subsumed by systemd itself (and the kernel), and the logic cannot be reproduced without it. In fact, the logic even spills into the various daemons as they will start shipping systemd .busname and .service unit files rather than the old bus activation files if they want to be bus activatable. Then, one of the most complex bits of the whole thing, which is the remarshalling service that translates old dbus1 messages to kdbus GVariant marshalling and back is a systemd socket service, so no chance to rip this out of systemd.

So yeah, these things are already part of systemd, and I believe that both are highly relevant on what people want from a Linux-based operating system. If you go for Upstart then you opt out of this. I have serious doubts that Canonical will play catch-up with this so quickly. The last time they tried that they took logind out of the systemd tree and ported it to Upstart. logind of course is one of the components of systemd where we explicitly documented that it is not a component you can rip out of systemd. And of course, just a few months after Canonical did this, things are broken again, and this was to be expected: logind now uses the new cgroups userspace APIs (as mentioned above), and hence it will not run without systemd around. So Ubuntu is stuck with an old and unsupported version of logind. If they advocate this as a solution, then they are in ignorance onthat what they have is already out-of-date. (And yeah, this matters, for example all the nifty stuff that allows Wayland to run nicely without privs is implemented in the newer logind versions, and not in Canonical's forked version).

I believe ultimately this really boils down to this: the Linux userspace plumbing layer is nowadays developed to a big part in the systemd source tree. Ignoring this means you constantly have to work with half-baked systems, where you combine outdated components which do not belong to together into something that in many facets might work but is hardly integrated or consistent. Or to put this another way: you are at a road fork: either you take the path where you use the stuff that the folks doing most of the Linux  core OS development work on (regardless if they work at Red Hat, Intel, Suse, Samsung or wherever else) or you use the stuff Canonical is working on (which in case it isn't obvious is well... "limited").

People on the email thread have claimed we had an agenda. That's actually certainly true, everybody has one. Ours is to create a good, somewhat unified, integrated operating system. And that's pretty much all that is to our agenda. What is not on our agenda though is "destroying UNIX", "land grabbing", or "lock-in". Note that logind, kdbus or the cgroup stuff is new technology, we didn't break anything by simply writing it. Hence we are not regressing, we are just adding new components that we believe are highly interesting to people (and they apparently are, because people are making use of it now). For us having a simple design and a simple code base is a lot more important than trying to accommodate for distros that want to combine everything with everything else.  I understand that that is what matters to many Debian people, but it's admittedly not a priority for us.

Canonical over the years has been working hard on building its own stack that is different to what others do to a major degree. Whether it is Upstart, Mir or Unity, there's a line through the whole stack where they make other choices. Every one of them is pretty much a Canonical exclusivity right now. It's up to Debian to decide whether to follow that, or whether the other communities aren't the happier places to be in.

I used to be a Debian contributor a long time ago (I maintained one package but never became a real DD), I care enough about Debian to attend DebConf this year. However, it is of course Debian's decision which path to go. I just hope you guys do it knowing what's at stake here. The least I'd like to ask the technical committee is to thoroughly do your research, and decide on the technology, and the future prospect, not philosophy and not which company you belong to. And yeah, we, upstream, are of course open to answer any questions you might have. And make sure to actually try the two candidates out. Play around with systemctl, with journalctl, and suchlike. To make an informed decision you must have played around with the actual code, it is not sufficient to just comment from the sidelines.

I understand that at least two votes on the technical committee are by people who play a major role in the development of Ubuntu. Both of them are to a large degree responsible for the strategy that Canonical has on on the development of their core OS. It is highly unlikely that they will vote against Upstart when it comes to it (I mean, how would they explain this to their space boss?). So yeah, I figure that Upstart's cards in this game are much better (maybe marked?) than systemd's, but hey, I'd at least like to to be able to say one day that I tried ;-).

Debian, please make sure you know what you do. Be aware that above anything else you make a decision for the future (not the present, not the past), and figure out what that future should be like for you.

And that's all I have to say. Happy decision making!
Ivan Baldo's profile photoSvein Engelsgjerd's profile photoMarenz Zenram's profile photoArne Babenhauserheide's profile photo
Well that is pretty much what all the haters where saying all along, isn't it? That systemd accumulates APIs and functionality, until it is basically impossible to not use systemd anymore. I don't really mind, because I actually am in favor of systemd, but your statement here will play directly into the hands of all the people in debian opposing systemd, I'm afraid.
Will kdbus be part of PID 1, or will it be a separate process?
(please tell me it's the latter)
+Axel Wagner well, we are building the basic building blocks for an operating system. If people start using them, they start using them, that's hardly my fault, is it? I mean, it's a question of honesty: do I personally care whether people can easily run Upstart or whatever with the tools we ship in systemd? Only to a very small degree -- which means we support that only where this is easy, and we document this here:

For the more complex parts the simplicity of code and clean design is way more important to us than anything else, so those bits are not portable. Sorry for that, but I will not lie about that.
+Alberto Mardegan The text above is pretty explicit about this, no? kdbus is a kernel component that is set up and managed by systemd. The system bus is set up by system systemd instance (i.e. PID 1), the user bus is set up by the user systemd instance. There is no dbus daemon anymore in this scheme.
It was not obvious whether you wew talking of systemd as a project (source tree) or the actual process.
I like most of the ideas behind systemd, but I think that the direction it's going (with stuffing everything into PID 1) is quite scary.
+Alberto Mardegan the "stuffing everything into PID 1" statement is a myth that has grown legs. Most of the systemd components are separate but often use the interfaces provided by PID 1. This is very different to actually doing everything in PID 1. Obviously some bits are in PID 1 by it's nature, but these are actually quite limited if you care to look into it.

In this case, most of the work of the kdbus stuff is in the kernel for example, but the userspace interface to this is tightly bound to systemd's mechanisms for launching and maintaining services. This means that there is precisely one component handling launching of binaries as needed for bus activation (which is also the case currently when the current dbus is built with systemd support) which means people can track, maintain and govern their processes properly and consistently. None of this really relates much to work done in PID 1 - just a relatively small amount of interfacing with the kernel.
+Alberto Mardegan well, "stuffing everything into PID1" is hardly what we do. We have 80+ separate binaries around. The bits of kdbus that will be in PID 1 are mostly how we set up things (a few ioctls) and the handling of the activation events (which are currently already there but awkwardly complex since dbus-daemon and systemd need to stay in close touch to handle this, asynchronously). The more complex bits, like the remarshalling to dbus1 (i.e. the compat for old libdbus1 clients) is outside of PID 1 in a socket activated service. This too, is written in the text above. Ultimately this all makes things a lot simpler. In fact, the D-Bus code in PID 1 after the transition will be substantially shorter than before. So if you are afraid that we "stuff everything into PID1" then you should actually be happy.

(Also, what a stupid argument anyway: have you seen how huge the kernel is these days and what they all stuff in there? drivers! staging drivers! binary drivers! yikes!)
+Lennart Poettering it's probably also worth mentioning the actual practical efforts you often go to to keep relevant people involved and informed. I know you have talked with the current Upstart maintainers to attempt to explain the repercussions of the latest kdbus and cgroups changes. This is often what detractors accuse you of explicitly not doing when the opposite is true. You should be more open about the efforts you continually make to keep people aware of what's happening - it's very valid and worthwhile work by itself!
Was "I am pretty sure the Ubuntu guys don't even remotely understand the complexities of this." really needed? I'm quite sure that will not help to have any constructive discussion...
+Lennart Poettering (disclaimer) I'm not an expert in this field. I believe a problem with systemd and upstart is that they both require Linux while Debian support several kernels. What can be done about this?
I wonder why Debian/Ubuntu don't simply provide more than 1 initsystem, so it's up to the user to decide whether he want to stick with the 20th century solution or move on to the 21st… (which includes either sticking with a certain set of software which doesn't have systemd dependencies or getting to enjoy the whole thing).
Gentoo does the same… keeps providing OpenRC, but also supports systemd.
+Elias Probst This is exactly what is happening. The question is, what is to be the default init-system. And keep in mind, that supporting multiple init-systems in a distribution essentially boils down to having multiple init-configs in every package of the distribution, so it is not as simple as saying, a distribution should "simply provide more then one initsystem". What does "provide" even mean? Providing a package? certainly, that is not very dificult and debian does it (as does ubuntu). But I hope you agree that this is not enough to provide appropriate support for the init-system, as long as there are no packages shipped using that system.
+Axel Wagner Well, looking at Gentoo and knowing the packaging process and efforts of Linux software very well, I don't see so much of work to be done to provide init-scripts/systemd units.

  * systemd units are provided in most cases by upstream (or just need to be modified slightly to downstream needs)
  * upstart/SysV init-scripts are already maintained, so this just needs to be continued

The only thing which IMHO adds considerably more effort is properly tracking the dependencies for packages which don't support systemd and are restricted to SysV/upstart.
Tim JP
Reason for Debian to use systemd: journalctl. Enough said. 
+Zlatan Todoric Nah, I am not really involved in the Debian project, and I don't care enough to get involved. I am already annoyed enough by Fedora, so I really don't want another project to be annoyed about. ;-)

I like my position on the sidelines, where I can just comment, but don't need to get involved... ;-)
Is there any chance of having a reduced functionality systemd on Debian/kFreeBSD? How about Upstart?
Debian has to support far more than just Linux. I thought that was why Debian was always going to keep SysV around, with optional systemd and Upstart.
+Antony Williams Are there statistics how many people are actually using the FreeBSD port of Debian? I mean what are we talking about? 1% or 10%? Is the support really worth it?
How about Debian GNU/kFreeBSD and Debian GNU/Hurd? This systems does not have systemd support.
I'm a debian user and I use systemd as it's something new and exciting. And it also "just works" for me :)

But when I read Lennart saying loud words like "we, upstream" or "make a decision for the future" I just feel that I'm being brainwashed. I think in the open source world the quality and features should talk for themselves. If Debian makes a wrong decision now and realizes it later, they can always switch to systemd or whatever is the new-and-fancy init by that time! It's free software after all, let them make their own decisions.
+Christoph Anton Mitterer I am not involved in Debian, I really don't need another ML to subscribe to, especially if I am not really involved in that project. I'd certainly welcome Debian in the systemd world, but then again, I don't really care enough to do more than just comment from the sidelines, sorry. If people care enough about my opinion then I am sure somebody will forward this to debian-devel, anyway...
+Vadim Pyadin Well, the Debian Hurd and Debian BSD folks can certainly use a differen init system on their ports. That's not too hard... And besides that Upstart supports neither either. (Though in contrast to use systemd guys they would be willing to merge such portability patches...)
The recent thread is riddled with false assumptions on how Open Source projects work and interact: Quote "It is not up to GNOME to assume that systemd is the only init system it can choose to support." -- I'm sorry, but that's just incorrect, the GNOME community can certainly make this choice. There's also a lot of confusion between "debian package maintainer maintaining the systemd debs" and "the upstream systemd maintainers" causing all sorts of message translation errors.
+Евгений Деревянкин: I've taken part in the debian-devel discussion. A lot is noise. Aside from pure noise, there is a lot of incorrect information and assumptions and loads and loads of "GNOME is evil" posts. The amount of incorrect information is really high. I tried  to show that the issue is more complicated than just making some quick judgement call on whatever you think on the top of your head.

I've had to repeat the same statements many times. Many times I've responded to emails which basically boil down to the same incorrect statements over and over again by various different people. Most of them don't use GNOME or systemd. Also some names I do recall and recall correcting their statements before. E.g. "everything in PID1" stuff.

The Google+ post is a lot of advocacy, probably puts various people off. But then read the various debian-devel threads and see how things are being framed.
+Olav Vitters Please keep in mind that anyone can post on d-d, so not everyone in that discussion is a Debian Developer ;-)
I have trust in the tech-ctte to make the right decision, and I think it is independent enough (there are more people in it than just Canonical employees). And there even was an offer from one of the tech-ctte members to refrain from voting if there is pressure from Canonical to direct the decision.
Both of your reasons point to places where Systemd alone is integrating with changes in Linux. I'm a Debian user and I'd prefer to use SystemD, but your arguments suggest to me that Debian should pick Upstart, so Free software can continue to offer free choices: Debian would have to live or die by Upstart, and would have to innovate and create solutions for moving Upstart into the future.
One important thing Systemd have over Upstart is the licence. That is a very important point to be made. Which I think the Debian camp can't ignore.

I do agree that there is a point of concern in that upstream does not take particular patches. As I see fragmentation can also be innovative. The negative is that fragmentation is not as effective. The solution would be if +Lennart Poettering changed his mind about this. Systemd could be both innovative and effective. I am not saying systemd isn't innovative... it's clearly the best init for Linux at the moment. I just wish we could be a bit more open minded about this.
+Morgaine Fowle Until your "free choice" became equal to an "slow to improve, not optimized" result. Sorry but if I use Linux I want the best from the kernel and the system, not the best only from the sharable code/functionality between linux and everything else.

To me, Debian should use systemd.
+Morgaine Fowle That's the fallacy of choice, a pervasive, die-hard idea on this ecosystem.. the usual result is, dozens of half-baked, half working, incompatible solutions for the same problem.
+Daniel Sandman hmm, we are happy to take any patch that makes sense. The only thing we won't take is patches that make systemd portable to the BSDs or Hurd. But the thing is that this doesn't even matter. Such a port is not really sensible, support for cgroups and suchlike (for which no counterpart exists on neither alternative kernel) is too deeply at the core of what systemd does.  So, complaining about upstream not taking these patches is like complaining that there are no commercial trips available to the edges of the earth's surface ignoring that the earth is actually a sphere and not flat... You won't even get as far as having patches that port systemd to other kernels, so it doesn't matter whether we accept them or not.
+Lennart Poettering Yes, I know.. and part of me support that decision. It's just the "makes sense" part that scares me a little. I mean it is fully the right any project can take. It's about reassuring the quality of the project. That is a good thing. The kernel works much in the same manner. Everyone knows the Android story...

But would those patches really hurt the systemd project? Would they add such amount of bloat?

I guess the kernel argument you made is very valid in that aspect. It might not be viable to do so. I know however BSD has a similar feature to cgroups in their jails but have too little knowledge in how adding support for this would affect the maintainability of systemd. Except the obvious that the code base would grow. And a bigger code base can make a project more unstable.

Anyway, thanks for your answer. I appreciated it.
+Daniel Sandman No, jails is not at all like cgroups. Please go and do your homework, please. You cannot abstract things away that don't exist in the first place.

Anyway, this discussion is pointless. It's not feasible. If you think otherwise, then go ahead, start working on it, good luck!
+Valerio De Angelis I have no idea what you are indicating. I only contend that progress happens best when there is competition, that we'll only understand how features are used if multiple parties are out there trying to best understand how to harness features. A monolithic unity between features and their users is certain to find local maxima, and never escape that end: it is death.
Markus S.
Let Debian switch to Upstart. I can't wait to see Canonical tell them that if they want a certain feature in Upstart, they have to write it themselves and then get handed Canonical's CLA to sign first.
Oh, the fun I'll have...! 
I don't think the Canonical bashing in the original post was necessary or helpful. It's enough to explain what's good and right about systemd and then call it a day.
+Morgaine Fowle Yeah, I like the competition too. But there is a big difference between competition and a false-competition. Firefox vs Chrome browser is a competition that push Firefox to be better. In that case, however, both the contenders are strong and full of manpower.
The Hurd kernel, the FreeBSD kernel and the others if any, have they the manpower to implement the same features that linux have? 
Because otherwise they are only a dead weight (from the features implementation pov) and not a competitors, they only prevent you to take all the vantages of the linux kernel for the sake of compatibility with others kernel. 
That is not competition, that is stupid. The competition doesn't start at all because they are not able to achieve the same result. 
From what I have read, it is an even score. On one hand upstart has CLA but could be ported, on the other hand systemd is LGPL but won't accept BSD patches. Debian will have to deside if they want BSD or not.
+stavros daliakopoulos as Lennart said above, it's not that systemd won't accept BSD patches, it's that it's not feasible for anyone to write them. The needed kernel infrastructure just doesn't exist there. If in the future the kernel interfaces were added to BSD, and if the user space interface was clean and isolated, then I'm sure patches would be considered. This isn't about hostility - it's about practicality. 
+Lennart Poettering I hope I'm not being too much of a PITA, but I continue not to understand. You say that systemd functionality is split into different binaries, but what's still not clear to me is if this binaries are loaded by PID 1 or not.
I wonder if it makes sense for you to write a blog post about this (or point people at it, in case you have something out already), so to clarify whether "everything into PID 1" is a myth, or to what extent it can be true.

I'd suggest answering to this question: how much of the work that systemd is doing in PID 1 could be done outside of it?
In particular, does the cgroups and kdbus setup (will) happen in PID 1 and, if so, is this mandated by the Linux kernel?

And if there is some room to the "everything into PID 1" criticism, would you be willing to work (or accept patches) to move those bits out of PID 1?
+Alberto Mardegan as long as you're asking sensible questions to gain a better understanding I think you're OK ;)

You ask if those separate binaries are loaded by PID 1. Technically all binaries are loaded by PID 1 by design. It is responsible for loading everything else on the system, so "yes, they are loaded by PID 1". But it's important to consider that in many cases those binaries will be spawned just like any other on the system, e.g. tmpfiles, hostnamed, datetimed and all the other low level interfaces are spawned just like any other "normal" system service installed from an external package. Some things do have to start early and care is taken to handle them at the appropriate time.

Regarding a blog post about this, Lennart did write one a while back:

Regarding cgroups and kdbus setup, this is done inside PID 1 AFAIK. I don't think it's too practical to do it outside, but Lennart can maybe clarify that bit.
+Alberto Mardegan Nope, sorry, I am not blogging again about something where you cannot be bothered to just read what is already there...

Yes, of course, all processes have PID1 ultimately as parent, and thus have been started from it, transitively. That's the purpose of it. We do outside of PID 1 what makes sense to do outside of PID 1, thus the 80+ executable binaries in our tree. (I mean, in case this isn't clear: having 80+ executable binaries means you split up things into 80+ different processes). And no, cgroups and kdbus are not features that make sense to be split out. kdbus is how clients communicate with PID 1, so we need to set it up in PID1. That's a logic that is quite forcing, no? And then, cgroup support is used to spawn services, so how could you put that into another process if to start that process you need cgroups?

So, no, the kernel forces nothing. Just logic does. And no, I am not willing to add patches to systemd that are against logic.
Ops, of course I mean "loaded into PID 1", not "by". Anyway, I got the answer I wanted, that these binaries will not run as PID 1. :-)

However, +Lennart Poettering , about kdbus I think you are limiting the meaning of "logic" a bit. Yes, it might be more convenient to have those tasks performed by PID 1, but it doesn't have to be that way.
+Markus S.: +stavros daliakopoulos didn't say that upstart works on BSD, just that they would accept patches for BSD support.
Indeed, the upstart group did not explicitly say that they would reject such patches, but I doubt that porting upstart to BSD makes any sense anyway... I was first a bit sad to see that systemd would not support non-linux systems, but the reasons given by +Lennart Poettering  make sense.
+Lennart Poettering: one thing that would make the choice much less scary for debian is a service declaration format on which the major init systems could agree. Something that would let the modern inits to perform a bit better that in compatibility mode, and that could be ported to multiple systems would probably help with the transition for conservative distribs like debian...
Such a format would not allow services to make use of all features of modern init systems, but many services don't care (or would be glad to at least have this a fallback). The old init could probably be modified to load such service files for BSD kernels, or it could be turned into shell scripts by a package installation hook.
Does that make sense to you? Do you think there is hope to build such bridges with the upstart guys?
+Colin Guthrie I think this only applies to a subset of systemd service files, thus it is a bit hard to predict how well it would work.
Having a well-defined set of features that are guaranteed to work on systemd, sysvinit (with some helper), and upstart would be a much stronger gesture. On the downside, it may also prevent some services from making full use of systemd/upstart capabilities. It may also be a false good idea: systemd and upstart work in very different ways, thus the parts on which they would agree may be very limited.
+Elias Probst
since you came from gentoo you know that packages need to be recompiled to use systemd, how do you think any binary distro could support init exchange?
Canonical rejects all patches without a signed CLA. 
+Markus S. Yes. And I think that the best way people can voice their opinion (and possibly change the course of things) is to fork those components which require a CLA (be it upstart or anything else).
At that point, also depending on the value of contributions being made, a company would be forced to reconsider.
+Francesco Riosa As long as the init support of a package just depends on providing an init-script/systemd unit, it's rather easy. Just always install the init-script AND the systemd unit and don't care about it any further, as they'll be consumed by the installed init-system.

At the point, where a package depends code wise on a specific unit-system and needs to be recompiled for supporting it, the binary package could be splitted up like it is already done in other cases, e.g.
 - foopack-common
 - foopack-systemd
 - foopack-upstart
 - foopack-sysv
This causes a bit of effort to do, but as the number of packages really depending on init features is rather low, I consider this to be still rather doable.

On Gentoo on the other hand it's quite easy:
- set the USE flag for the desired init-system (e.g USE="systemd")
- rebuild all affected packages: emerge --newuse --with-bdeps=y @world
+Elias Probst 
it's more then a simple use flag change looking at
it would be a real nightmare for any distro to keep support for both.
Sabayon tryed to have both and declared failure since then

BTW. I know that it's more than that because I've tried systemd in gentoo few months ago
Upstart offers no value. It's Canonical's crappy NIH answer to launchd.
+Markus S. While I slightly prefer systemd over upstart and I'm not fond of the CLA, I would certainly not describe upstart as crappy. But as all your comments in this thread are about bashing upstart, I guess you know better.
+Elias Probst What you propose is absolutely insane for a binary distribution, there is no hope whatsoever that it will work or even that you will convince distribution maintainers to  attempt such thing in the first place. 
it was working until systemd 204 after that the shim stopped working, 204 is also the version debian is using
Services won't stop shipping old bus activation files if they want to keep working properly on Ubuntu, BSDs etc. And by services I mean also components of GNOME and KDE (unless those don't do bus activation?)
+Aurélien Naldi Upstart was started to offer Ubuntu what launchd offers OSX. Upstart did not achieve this goal and even was unmaintained for awhile and only recently development started again.
Not only did Upstart not achieve its initial goal to be launchd for Ubuntu, it's development has a bad track record. Therefore Upstart qualifies as crappy in my book.

systemd OTOH is in constant development since its inception, achieved it's goal to offer launchd concepts on Linux, and even went beyond that.
There currently is no alternative on Linux that can match systemd's technology in real world scenarios. 
+Markus S. being in "constant development" is much more scary than reassuring for an init system for me. Being maintained is important of course. That would probably be the main drawback for systemd IMHO  (even if the core features have been stable for a while).

Again, I like systemd better than upstart (and I am well aware that my opinion on it means very little), but I have to say that from a user perspective upstart works fairly well: it allows the system to boot, it does it much faster and in a much more reliable way than sysvinit did (it fixed a bunch of race condition in the early boot, even if it took some time to get there), and it handles services better than sysvinit.
For me, upstart did what it was supposed to do (which does not mean that it is perfect and that systemd does not bring a better solution to the same problems).

Note: the boot process in ubuntu also does one thing that fedora should do as well: tell the user about running fsck. This prevents people from rebooting a system which seems to be stuck.
"The userspace of kdbus pretty much lives inside of systemd."

LWN reports that the systemd implementation of kdbus userspace is a good test that will likely develop into a good implementation. I've heard that automotive folks are obsessed with absurdly quick booting, so it seems unlikely to me that they would want to pick up all of even the minimal subset of systemd just to get kdbus. Because of this, a second implementation of kdbus userspace seems very likely.


Also, the "Why systemd?" init system comparison matrix needs to add information for OpenRC. :)
+Simon C. Ion the automotive people have been early adopters of systemd all across the board. It's a required component of GENIVI and Tizen requires it too.
+Markus S. maybe you should read what I wrote before replying. I did not say that systemd is broken, I said explicitly that I like it better than upstart. I have been using systemd on fedora without problem (beside the lack of information about fsck) for a while. I have also been using upstart for a while without problem.
All I said is that the "actively developed" argument that you used could also be seen as a drawback, compared to sysvinit which has pretty much not evolved for the last 25 years. As long as the core is solid and new features don't break existing stuff, I'm perfectly happy with having an evolving init. In fact, like most people I just don't care: init is here for the boot and handling services, as long as this works well and service management does not change every year (and is similar enough in all computers I use) I'm fine.
Because your criticism has already been debunked by Lennart many times over, in this post, in previous posts and in the systemd documentation. However, I have a feeling that nothing I, or anyone else, could say is going to actually convince you about that.

What's more, I actually doubt that you have used systemd, or maintained a package that does. Lacking any relevant experience, you harp about systemd potentially becoming obsolete in 10 or 20 years.

This is, of course, no valid argument - any system has the potential to become obsolete in 20 years, including systemd, upstart and everything else you can think of.

At this point, any further discussion is a futile waste of time.
FUD, strawmen and rock 'n' roll. :)

If you had RTFM you'd have realized that the systemd design has absolutely nothing to do with the Windows registry.

As I said, nothing I, or anyone else, can say will make you change your mind. Educate yourself - that's all.
+AG Restringere What bothers me about your anti-systemd handwringing is the lack of faith in the resiliency of the open source ecosystem. Let's say that systemd is as bad as you, or even it most vociferous detractors, say. Let's say that it becomes a "large monolithic unmaintainable mess," deeply tied to the kernel and with tendrils in every WM, DE and daemon. That would make it--HAL. And I have every confidence that if you are correct, systemd will join HAL, unmourned in a shallow grave, without even an .fdi file to mark its final resting place. In the meantime, why don't we all calm down and just enjoy the lovely toys Lennart and team are building us?
+AG Restringere  I wonder what you think of BTRFS, which does for file systems what systemd tries to do for init. Keeping a generic volume manager outside of the file system is modular, elegant, it even works fairly well, but it does not allow the much better kind of snapshot offered by integrated systems like ZFS or BTRFS. Of course you can still have a mix BTRFS and other file systems, so the situation is less extreme than with systemd, but I like the comparison nonetheless.

Modularity is a good goal, but in some cases it just prevents some integration, or makes things much more fragile: you can easily change a part when using a simple system like sysvinit, but you can also easily mess it up (completely or for some corner cases). Modularity can also appear at different levels: systemd has many specialised parts which share some code, is this really less modular than a collection of heterogeneous projects which implement multiple times similar stuff, just to keep it all separate and modular?

So, do you think that systemd provide valuable features? If yes, can you do the same with another design (without ugly and fragile hacks)?
Note that if your other implementation provides the same dbus API, the software which are "forced to use systemd" will work with yours as well, isn't it cool? I would love to see more discussion about this API to make sure that it is not too specific to a single system, but you can't expect the systemd people to do more than propose what they want and be ready to adapt it to accommodate other uses after constructive discussions.
the amount of time I see the word "Canonical" with a bad meaning makes me flag your analysis as biased. I just don't see how having choices is a bad thing...
I'm uninstalling systemd from my system just now. It worked quite well in my Debian for months, but the more I read about systemd, the more I think I don't want systemd.

I hope to see OpenRC as default in Debian. It's not as complete as other solutions, but I think that it's better begin with something that fits with Debian (and GNU/Linux) policies and needs, and improve it, than something that wants to impose the unique way of doing things or CLAs.
Systemd is the GNOME 3 of init systems. Slackware is running well on all our servers and desktops without either of those.
Lennart, first of all I think you are doing the right thing going for the integrated system with systemd. This is exactly what Linux needs since this means quality.

Remember however, that this is also exactly what Canonical is doing (with hopefully Debian backing them). They are implementing their own well integrated system around Upstart since this is where their competence lies. This is very wise. With extremely high odds this yields better end result for their environment than trying to play catch up with your project. For now, Canonical has produced by far the most relevant Linux desktop out there and lets give them a full credit for it. Jumping one from one project to another without clear additional benefits would never have taken them anywhere. FOCUS is the key. There are just too many projects out there.

Besides, wasn't OSS all about choice. To me it would be massively awesome to have two lively and vibrant tightly integrated Linux userlands. Go Upstart and Systemd =))
I think desktop environments and other userland software should rely on finished, properly documented and 3+ years supported APIs; maybe I am wrong but the impression I get from reading things about systemd is volatility on the APIs, some lack of proper documentation, etc.. It should be possible for a competitor to systemd to have some chance to implement some APIs and interfaces so that desktop environments and userland software could work with it instead of systemd. And I think that such APIs and interfaces must be implementable on some other unixes to be useful and generic enough, they shouldn't be too tied to Linux. I think it is important to keep software compatible with other kernels, and I think that it is important that if someone wants to do his own kernel from scratch, they could provide some APIs and interfaces that allow a great quantity of software to work on it... If it wasn't so a couple of decades ago, we wouldn't have Linux, GNU, etc.etc.
Hi Lennart, first of all I would like to start off that I am only a simple "end user" of Debian and even if I tend to dislike the integrated-takeover style of systemd and sometimes your attitude as well I still think it is the only sensible way to go. I have been playing around with systemd a bit and it seems consistent and reliable and above all in control of the system.
I might not like your decisions, but I'll give you credit for giving good arguments for systemd and I also hope you have the best intentions for Debian. I personally think you are so full of yourself that you are about to explode any second, however that being said I put fuel on the fire and very openly admit that you are often right at least in principle. I'll give you one thing tough: I would much rather use systemd constructed by a "dude" that don't wrap the details in "silk smooth talk" than one of those "silk smooth talkers" that are more concerned by their language than a technical implementation. So in short: You are such an asshole, but I wish you best of luck with systemd and hopes Debian adopts it! PS! Merry X-mas and have a happy new year celebration as well ;)
+Tim JP journalctl was actually the thing that annoyed me the most when I was forced to switch to systemd (in ArchLinux). It was dead slow for me, always talking at least 3 seconds to output something, the usage is aboslutely not intuitive. I miss my normal logfiles. 
+Marenz Zenram do you have high IO load? I had such latencies for anything related to dbus when I still had my main box as 24/7 freenet server (lots of small file IO).
Add a comment...