It's interesting to see that Canonical intends to push Upstart into the User Session now. Doing something similar with +systemd has been a long term item on our TODO list for a while. Since a long time systemd can be run this way, but we never spent the time on actually going all the way with it and port GNOME or KDE fully onto it, so far. There are a number of reasons why we didn't do that, but one of the biggest issues certainly was that we didn't want to open another can of worms where the systemd world would start to differ greatly from the Ubuntu world, API-wise. It's one thing after all, to have incompatible system management APIs, but it's a very different thing having incompatible application environment APIs, because suddenly all the apps for your platform have to deal with the incompatibility.
Ultimately, this move of Canonical will be one more step towards splitting up the ecosystem. I am not blaming them for that though. I mean, while we certainly intended to push for unification of OS APIs with systemd, and we achieved some success (You can use the same unit files, many low-level configuration files, command line tools to manage Fedora, Suse, Mandriva, ArchLinux systems now), we certainly did fail ultimately with this goal, as we never managed to convince Ubuntu to adopt systemd. While the reasons why we didn't manage to convince them are not known in full to me, there seems to be a lot of personal antipathy part of it, and we hence certainly have to take a big part of the blame ourselves.
Whichever way you turn this, with this move Ubuntu will have their own platform on most levels now. They share the kernel, but not the system manager, session manager or UI (Unity...) with Fedora, Suse, Mandriva, ArchLinux (and other systemd using systems) anymore, i.e. the cut goes through the entire userspace. The separation of the userspace bits of the OS is not complete, we do share components (such as D-Bus, ...), but this is precisely where the focus appears to be now: sharing components of the platform, rather than the platform itself.
In a way Canonical is just doing something that Android has pioneered. Take the kernel, share some userspace components, but turn it all into your own private platform. That's certainly a valid strategy. And they might even pull it off (in contrast to Google, they create the platform gradually instead of abrutply) But I'll leave it to you to figure out what this all means for the Linux platform and ecosystem in general...
Ultimately, this move of Canonical will be one more step towards splitting up the ecosystem. I am not blaming them for that though. I mean, while we certainly intended to push for unification of OS APIs with systemd, and we achieved some success (You can use the same unit files, many low-level configuration files, command line tools to manage Fedora, Suse, Mandriva, ArchLinux systems now), we certainly did fail ultimately with this goal, as we never managed to convince Ubuntu to adopt systemd. While the reasons why we didn't manage to convince them are not known in full to me, there seems to be a lot of personal antipathy part of it, and we hence certainly have to take a big part of the blame ourselves.
Whichever way you turn this, with this move Ubuntu will have their own platform on most levels now. They share the kernel, but not the system manager, session manager or UI (Unity...) with Fedora, Suse, Mandriva, ArchLinux (and other systemd using systems) anymore, i.e. the cut goes through the entire userspace. The separation of the userspace bits of the OS is not complete, we do share components (such as D-Bus, ...), but this is precisely where the focus appears to be now: sharing components of the platform, rather than the platform itself.
In a way Canonical is just doing something that Android has pioneered. Take the kernel, share some userspace components, but turn it all into your own private platform. That's certainly a valid strategy. And they might even pull it off (in contrast to Google, they create the platform gradually instead of abrutply) But I'll leave it to you to figure out what this all means for the Linux platform and ecosystem in general...
View 65 previous comments
+Łukasz Mierzwa, did you actually read what I wrote above? I am not really blaming Ubuntu for anything here. I did write that we had similar plans too with systemd, and took the blame for not achieving unification, and said their approach is valid. I left the question open whether the whole thing was a good thing for Free Software or not. I really didn't suggest that Upstart was bad in this regard, and we were good. I tried to paint a much less black/white picture of the whole story...Nov 26, 2012- +Clint Byrum regarding cgroup usage in PID1: cgroups are just an interface among many. They allow you to assign resources to groups of processes. That is all. They hence are merely a means to achieve a goal, never a goal in itself. That's why we have high-level controls for cgroup-based resource management in systemd: because people want to control resources to achieve their goals, and cgroup is fine for that. And this is not too much different for Upstart, except that Upstart limits itself to exposing only the nice value and resource limits and little else, even though these are really not that useful for anything but the most trivial resource management of single-process services.
I do believe that projects such as libcg had the wrong goal: they tried to sell cgroups as a primary feature, something that was more than just an implementation detail of resource management.
Or to say this with other words: if you think about service management you really should think in usecases. And one of the primary usecases for that is -- on servers as much as on embedded -- resource management. And in our eyes the only reasonable resource management you can do for any non-trivial service is via cgroups, and hence we expose this.
I mean, I am happy if Upstart doesn't do cgroup stuff... It gives us one more feature where systemd is better and simply more useful than Upstart ;-)Nov 26, 2012 
+Lennart Poettering I didn't say upstart won't do it, just that I personally am not convinced that upstart needs to implement cgroups. There are others who are far more influential in the upstart world than I am, who think it should be done. I for one am not rooting against systemd or even for upstart. I only hope for modular separation of concerns that do not interfere with reliability. Perhaps systemd will achieve this. Perhaps not. IMO, upstart already has achieved it, at a cost of features and locking in some fairly pesky bugs.Nov 27, 2012
+Björn Bidar LightDM (or any other DM) has no need to add any special code to handle a session using upstart. A session is simply a process that is first set up with PAM and the execs whatever binary is specified in /usr/share/xsessions. So in this case it's just a matter of replacing gnome-session with upstart (which then calls gnome-session).Nov 27, 2012
+Lennart Poettering The one thing I've seen the Upstart guys say is that they can handle things like new hardware without having to do polling. As I understand it, they have some system that subscribes to hardware changes from the kernel and emits upstart events. They seem to think systemd couldn't do this. Is that true? Couldn't there just be a systemd "events bridge" that requests systemd to reach a target when a signal from the kernel is sent?
The other thing I'm curious about is how does systemd "prune" running services when nothing depends on them anymore? If it does have this, is it automatic? (I could see how that could be confusing for people adding services for upstart to manage, when they don't add it as a depdency to a target, and then they wonder why it doesn't start. But I could also see how things like phones and laptops could get better battery life.)Nov 11, 2013- +Erik Andersen Wut? Information about devices coming and going on Linux is handled by udev on Linux. udev is part of systemd. On Ubuntu/Upstart systems they run udev as well, they isolated it out of the systemd source tree for that.
+Kay Sievers is the guy who wrote udev, and he's one of the main guys behind +systemd.
The Upstart "events" bridge, which they use to forward udev events is actually an awful thing. udev is designed to suppress events (and hence wakeups) to clients as much as possible, to optimize power consumption. The Upstart events bridge subscribes to all events however, which makes the entire thing moot. The Upstart events logic is one of the worst design mistakes in Upstart actually, because it means that Upstart bombards the system bus with device messages all the time.
systemd has a garbage collection logic that frees all loaded unit data as soon as no other unit references it anymore, if it is not active anymore, and if it doesn't contain important runtime data that should not be lost (like for example failure codes). That's fully automatic.Nov 11, 2013
Add a comment...