Martin Gräßlin
2 years agoPublic
I do hope Debian decides for systemd. It's important for running KWin on top of Wayland and if Debian as a base would not provide this i would be forced to switch distros. Arch seems to be very popular among kde devs nowadays...
Lennart Poettering originally shared:
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!
Nick Paulin2 years ago
Chakra might also be a good fit.... Especially with their focus on a KDE centric experience. $.02+2
+Martin Gräßlin I'm sure you'll find yourself at home on Arch. Have you ever tried it?

+Andrea Scarpino maybe you can put some good words for Arch here ;)
Markus Be2 years ago
tl,dr but i also think, that Debian should chose systemd. The old init-System is outdatet and upstart is more and more a canonical piece of software. Systemd establish oneself.+6
Thomas Pfeiffer2 years ago
+Martin Gräßlin Lennart doesn't say that Wayland won't work at all on a Upstart-based system, does he? He only says "all the nifty stuff that allows Wayland to run nicely without privs", so I assume the experience is less good on Upstart, but it's still possible, right?
Martin Gräßlin2 years ago
Right, but that's nothing I want to worry about. I want to have an easy to use system for my development needs.+4
Ivan Čukić2 years ago
This is a question about the default system, not the only system. Systemd is almost usable on debian already.
Martin Gräßlin2 years ago
As I read it, it is about being the only system
Colin Guthrie2 years ago
+Thomas Pfeiffer this basically a security thing. Linux doesn't have any kind of revoke system so when the user is no longer allowed to access things, we have no defined way to get them to stop.

This is a lesser known security problem on Linux. For example, if you open audio devices and then switch user, it's technically possible for the original user to eavesdrop on any VoIP calls etc made by the second user who things only they are now allowed to access things. Now +PulseAudio "solves" this by hooking into logind notifications and voluntarily giving up (i.e. closing) the audio devices, but this cannot be considered "security" by any metric (it's also a little bit racy, but the practical window of exploitation here is pretty small so it's a non-issue)

logind actually solves the problem properly for wayland by effectively proxying the opening of the fds needed to communicate with the graphics hardware. When it knows a user is no longer active it can make sure that the process no longer allowed to access the fds cannot access them. It's effectively a revoke implementation in userspace.

We should really do the same thing for audio at a lower level (i.e. alsa) and then the logic could be removed from PulseAudio, but it's a bit more complicated there as alsa actually deals with a lot more fds than wayland (surprisingly).
+Martin Gräßlin +Fedora Project and +Arch Linux are the distros I use these days and both seems fine to me. Both have great support for systemd.+4
Colin Guthrie2 years ago
Oh and of course if you are distro hopping (which I couldn't really recommend seeing as there are definitely enough people in Debian to support systemd usage), I must of course recommend +Mageia.Org which is very KDE friendly (both user and dev) :)+2
Luke Benstead2 years ago
+Martin Gräßlin you might be interested in Tanglu which seems to be based on Debian testing with systemd and a focus on KDE +1
Josep Febrer2 years ago
I have to admit that for some time I tried to avoid systemd, but after trying and using it on Debian I can only say that I'm really impressed by it, boot time is really fast, much better than upstart on my case.+1
Thomas Pfeiffer2 years ago
+Colin Guthrie Thanks for explaining the issue! Admittedly, I did not completely understand your explanation because of a lack of technical knowledge, but I took from it that Wayland with Upstart would be less secure than Wayland on systemd, is that correct?
Joachim Kindorf2 years ago
I switched to +Arch Linux because of latest KDE :-)+2
+Martin Gräßlin
It seems, that Marc was right about Lennart. His hate to Ubuntu and Canonical is so high, that he can break even systemd because of it. I hope, Debian will choose Upstart and Fedora will go to "always-second" path. We can see a very important problem: the most stable distro (a base of hundreds others) is choosing its future. Do you remember about PulseAudio path? You are working for desktops, but admins using Debian  can tell you: "Only SysVInit or Upstart".
Elias Probst2 years ago
+Николай Семенов Have you ever tried systemd on your own. Had it running for more than just a few hours and used it thoroughly on a production system?
I feel like most people who criticize systemd never tried it on their own and don't realize at all what kind of substantial improvements it brings.
+Elias Probst
Of course. Right now, I am writing these lines using OpenSUSE. I never criticize anything I have never seen. So, I have tried both systems (and SysVInit, of course).
Leszek Lesner2 years ago
Debian might be also try a dual way. For the supported linux plattforms (I really don't know how it will perform on mips or arm so it might be wise to test it out first)  use systemd. For Hurd and kFreeBSD plattforms use either sysvinit or upstart (if that is running good enough on this plattforms). 
With systemds clear focus on linux only it will very fast be the best supported init system when it comes to linux. 

From the technical standpoint (even if my knowledge is far away from Lennarts) systemd is superior. 
Sander Lepik2 years ago
+Николай Семенов, I'm a sysadmin and I'm running most of my servers on Debian. On my desktop I'm using Mageia (that has systemd support since the 2nd version). I have to say that I curse Debian a lot because life with systemd is so easy and they don't have good enough support for it.
I have little experience with Upstart but as much I've used it, I didn't like it. You can't compare it with systemd. And if Debian would go the Upstart way I would seriously consider if I want to continue with Debian.
+Sander Lepik Everybody has its own POV, but connecting to Debian, it will be better to have a choise. As a user (I was a user of several distros) I don't want to see: one init-system (systemd) - one Graphical stack (Wayland) - one DE (Gnome3) and everything is connected to systemd. It will be the end.+7
+Николай Семенов The end of nothing. 
What is an issue for you, "everything is connected", elsewhere is called optimization and it is candidate to produce amazing results. 

Wayland uses many of the linux kernel features that were unused or duplicated before (in fact they are focused on linux).

systemd wont uses all the maximum from the linux kernel and optimizes all the processes moving some stuff to userspace and managing other stuff outside userspace for performance and security reasons.

All those efforts will result in a very powerfull, secure and fast desktop based on linux kernel.
I want that more than some diversifications that exist only for the sake of the diversifications. 
Maybe for the DEs pov can be true, but for the deeply stacks (like the kernel, the init-system and the graphical stack) I don't think the diversification will produce so cool results to justify their costs. 
Markus S.2 years ago
"Marc was right"... LOL. I've read more insightful comments by Phoronix trolls. +1
Georg Grabler2 years ago
+Martin Gräßlin for that (development) I personally think debian is quite more confusing than arch ever could be, but I've been arch user for almost 10 years ... probably moving a guy using debian for 10 years could end up thinking arch is confusing ;-).

But I'm pretty sure Debian will move to systemd (other options?), and if not - there is Tanglu evolving based on debian, already on systemd (i'm currently on tanglu, works pretty well, actually better than I expected :D). But Debian is still full of quirks for me, especially packaging in debian is way too complicated - dozens of mostly unnecessary files - really?
Markus S.2 years ago
At least two guys in Debian Technology Committee are paid by Canonical.
Alberto Mardegan2 years ago
I don't think that this decision will have any impact on your work. In any case, it's about the default init system; but most importantly, you'll be able to run wayland on both upstart and systemd.
Martin Gräßlin2 years ago
+Alberto Mardegan did you read what Lennart wrote? Of course it has impact on my work because without systemd a proper Wayland setup cannot be implemented. Also I am in favor of depending our new startup code in Plasma2 on systemd.+2
+Martin Gräßlin Just interested: why Plasma2 startup code should depend on init-stack? It seems, that it is better to be independent and depend only on graphical stack. Is it really nessesary for development or just a political decision? Something like "No systemd - no Plasma2".
Martin Gräßlin2 years ago
+Николай Семенов systemd is more than just an init-stack. There are many important features in it. Like having a sane approach to the privilege handling of Wayland. Then there is the user session support which would help us to bring up Plasma much faster and more reliable. Currently it's a sequential shell script containing the dependencies. Now with Wayland our dependencies change. KWin needs to start first, then depending software can be started in parallel. On X11 the situation is quite different. More things can be started in parallel and KWin shouldn't be first. So systemd is a really useful feature here. And heck with socket-activation one doesn't even need to guarantee that KWin starts first. Systemd would provide the Wayland socket we would use and all software can start in parallel and it doesn't matter how long KWin needs to startup the Wayland compositor. That's something which can quite influence the design of KWin. If we don't have that feature our aim would be to bring up the Wayland compositor as fast as possible - this would require significant changes to the way how the startup works. If we have systemd socket-activation we can just keep our startup and take over the socket once we are ready for that - a point where we know that everything works fine and if it didn't we could silently just transition to X11. Without socket activation we would need to bring up the socket before we know that everything is fine.

In general: you won't here "political reasons" from me. I don't care about politics, I care about technical solutions. If I say I want systemd there must be a damn good technical reason for it.
+Martin Gräßlin Thank you :)
The interesting question is what should you do if Debian will choose upstart. KDE must work under Debian. But it is another theme. So, lets just wait and go on reading holywar in maillists of Debian-devel.
By the way, they again want to be XFCE as default DE in Debian. (as I understand, because of Gnome3 is not so good for them. But I have not read it yet, so it is another theme too)
Martin Gräßlin2 years ago
+Николай Семенов well we will see about what to do if Debian decides against systemd and they are not the only ones who do not use systemd - slackware for example or the BSDs. For me personally that means that Debian is no longer providing what I want to use - as pointed in my initial comment. What it means for Plasma: we'll see. I'm personally not in favor of supporting anything except systemd and a legacy shell script for the non-systemd distros from our side. I'm not the one writing that code and maybe there are then enough devs around who care about maintaining a second startup stack.+1
Markus S.2 years ago
Sessionk by vaporletti. :-P
Alberto Mardegan2 years ago
+Martin Gräßlin From what you wrote above, KWin is not the Wayland compositor. But from the little I read about Wayland, I was under the impression that in Wayland the compositor and the window manager are living in the same process. Was I wrong?
Martin Gräßlin2 years ago
+Alberto Mardegan what? I cannot see how you come to that conclusion. KWin will be a session Wayland compositor, obviously.+3
Alberto Mardegan2 years ago
OK, then I don't see all this big difference that systemd would make to you. Sure, you might not have to worry about the dependencies, but someone else will: if KWin is socket-activated, which application will start it? Well, this application needs to be started when the session begins, and this needs to be configured somewhere.
What I mean is that indeed the KWin session startup for upstart and systemd might be different, but the amount of work to configure it won't be very different.
(and if you won't do said work yourself, chances are that the distributions using upstart will do that for you)
Martin Gräßlin2 years ago
+Alberto Mardegan I do care more about the cgroup based privilege protection of the Wayland system compositor. As Lennart explains that cannot be provided by other systems right now. I do want a secure system - even on my dev system. In fact I have so far never used Wayland without systemd support.
Khalil Choudhry2 years ago
+Martin Gräßlin There's also opensuse.
Matthias Klumpp2 years ago
+Markus S. sessionk was a proof-of-concept, which might continue to be developed for Frameworks 5 - who knows ;-)
systemd, in any case, does well as session manager, so in theory it could be used for KDE.
+Martin Gräßlin Of course you can escape to Tanglu :-) But I have trust in the TC to make a good decision, so let's see what happens.
Andreas Hartmetz2 years ago
"These things that formerly didn't require systemd now do, so you have no choice."
Cool story, bro.
Edit: kdbus and udev living in the systemd repo can very well be seen as a land grab. DBus activation is a tiny part of DBus and does not make it necessary to fully integrate it with systemd. Integrating udev was simply not necessary.
Matthias Klumpp2 years ago
+Andreas Hartmetz Nobody did it better before, and the systemd package brings major improvements. If someone would have wanted to stop this, it should have been done much earlier. Now, people start to use systemd-provided services simply because they greatly enhance available functionality of other parts of the system.
And systemd basically wants to be a collection of multiple tools to form the Linux plumbing layer and to build userspace stuff on.
Andreas Hartmetz2 years ago
Now explain to me how this is in no way a land grab.
Markus S.2 years ago
"Nice indirect insult"

LOL. After Shuttleworth's "Open Source Tea Party" insultfest the so-called "insult" is pretty tame…
+Markus S.
They both are ... ready to start "insultfest" ? :) But this is offtopic. We are interested in opinions of other developers. Patrick is a developer of OpenRC, as I know. (am I right?)
Markus S.2 years ago
Other developers:

Arch devs: 'systemd is great. We'll use that.'
Fedora devs: 'systemd is great. We'll use that.'
Gnome devs: 'systemd is great. We'll use that.'
KDE devs: 'systemd is great. We'll likely use that for Plasma2.'
Mandriva devs: 'systemd is great. We'll use that.'
openSUSE devs: 'systemd is great. We'll use that.'
Red Hat devs: 'systemd is great. We'll use that in RHEL 7.'
Tanglu devs: 'systemd is great. We'll use that.'
All others: what is this? We don't like vendor locking. And remove from the list all red hat's sputniks.
Matthias Klumpp2 years ago
systemd is not limited to a vendor, therefore there can - by definition - not be a vendor lock-in.+4
rhy o'drinnan2 years ago
Radu Andries2 years ago
+Martin Gräßlin Choose chakra, we definetely need some kde devs using it to give us feedback.
Cameron Norman2 years ago
So ConsoleKit will die? And with it BSD support? I am sorry but I do not want a WM that tells me what session manager, and ipso facto (unfortunately) what init system to use, and then further what kernel to use.
Cameron Norman2 years ago
Also, you realize systemd-logind can be used when systemd is not PID 1, or have they demolished that feature?
Ian Monroe2 years ago
+Andreas Hartmetz how can it be a land grab? Who is it grabbing from? Red Hat maintained all this stuff already afaik. The creator of udev is even one of the creators of systemd lol. And of course kdbus was created for systemd.+2
May i ask why systemd is important for adopting wayland? If wayland can speed things up i do support wayland however nvidia drivers will be a problem. Also as i understand it the opengl implementation is faster because it ignores drm? Missing KMS is a pita for me though, so hopefully nvidia will step up. And to be honest it is a bit hypocritical for blaming Ubuntu on making their software not work anymore with other(kde) software while basically what you are doing is pushing other init systems away if wayland becomes successful and requires systemd for KDE. I find Ubuntus statement correct in that systemd has become invasive in our lifes, absorbing other software that should remain seperate daemons, defying UNIX logic. But Ubuntu is a hypocrite as well. As for X, it is already moving the direction wayland is going, it is just very slowly due to it being adopted and used software.
Matthias Klumpp2 years ago
+Christ-Jan Wijtmans Why should the software remain separate? What's the (real) benefit of that, instead of having integrated tools well-working together? That's the thing people don't answer.
As for Wayland and systemd, there are various things to read and understand, I recommend taking a look at
In case of udevd dissapearing because of systemd absorbing it which means that software that depended on it is now going to depends on systemd. in my case i am on gentoo, i might be forced to use systemd even though i might not even want to use it(i dont like software made by lennart at all). This either means distros that use other init systems must either maintain udevd or do the same and absorb udev into their init system. It is adding maintainance time. Not to mention the danger of increasing entropy and thus risking the creation of spaghetti code that Xorg once was because it did the exact same thing, do too much it shouldnt do. Adding wayland to the list of software that forces me to use it is not good and it defies UNIX logic. It is exactly the malpractice Ubuntu is blamed for.
Matthias Klumpp2 years ago
Well, not liking software made by Lennart is no technical argument, so I'll ignore that. Xorg does and did exactly what it is and was designed for, only the stuff around it changed a lot, so it isn't the best example here. Udevd will be separate from systemd for a long time, also there is nothing integrated into the init-system (as of pid 0). Systemd is merely a collection of lots and lots of tools which form a huge part of the plumbing layer around the Linux kernel. And some of the tools use features exposed by systemd, which is sane to do, if it adds value.
This means that in theory, if you implement something capable of doing what systemd does, you can reuse all of the code. As of today, there is no such thing (upstart might be getting there, but right now there are huge differences between both systems)
UNIX logic is not really defined anywhere, but if you understand it as "multiple small tools working well together", then this is exactly what systemd does ;-)
'Udevd will be separate from systemd for a long time,"

In April 2012, udev's source tree was merged into systemd.[1][2]

"Systemd is merely a collection of lots and lots of tools which form a huge part of the plumbing layer around the Linux kernel."

by absorbing all the existing tools into systemd.

"UNIX logic is not really defined anywhere, but if you understand it as "multiple small tools working well together", then this is exactly what systemd does ;-)"

Not really since the tools are being coded into a direction where its systemd specific and not cross init system

"Xorg does and did exactly what it is and was designed for"
very untrue. It did many tasks its should never have done, some of it is already removed but a lot of it still there.
Ian Monroe2 years ago
Christ-Jan, you aren't entitled to ordering around the folks building the Linux userland components to your personal specifications. It's not 2001 anymore, a pretty-much-Unix-circa-1985 userland perhaps doesn't cut it anymore. If you don't like the Linux plumbing being developed, don't use Linux. Or pull an Android and maintain your own system.+1
Matthias Klumpp2 years ago
Udev is part of the systemd tree, but does not depend on it.
All the tools "in systemd" live in the same codebase, and that's it. See [1] for example.
"Not really since the tools are being coded into a direction where its systemd specific and not cross init system"
Where has it ever been UNIX-ish to be able to choose an init-system? And all tools only use systemd(features) where it really makes sense, it's not like there would be dependencies added to it just because it's possible.

""Xorg does and did exactly what it is and was designed for"
very untrue. It did many tasks its should never have done, some of it is already removed but a lot of it still there"
Xorg comes from a time where shared-libs didn't exist. So it had lots of stuff in it since it's very beginning (well, not Xorg obviously, but X11 and it's implementations). But I'm not an X11 expert, Martin is ;-)

Cameron Norman2 years ago
+Matthias Klumpp Stop wasting your time arguing about trivialties and work on Tanglu! Just kidding, do what you what you enjoy.
Matthias Klumpp2 years ago
+Cameron Norman As long as this stuff is not getting personal, unfriendly or insulting, I spend some time on it ;-) (while systemd might not be perfect, it is important that people allow new stuff to happen) In any other case, I'll just leave pointless discussions, it kills productivity and every fun and excitement in developing FLOSS stuff.
Tanglu is well-shaped for the future. Sadly also because of the stuf Ubuntu is doing at time.