Various people have asked me for a few words on Canonical's decision not to adopt systemd. I am not going to say much. But a few things:
From what I am hearing behind the scenes this appears to be very much about control. They control Upstart (both by being maintainer and even enforcing copyright assignment), and they think they don't control systemd. Of course, free software has never been about control, and whenever something deviates too much from where you would like it to go you have the freedom to fork. [In addition in times of git it is dead-easy to maintain your own patch set.] Similar to companies like Sun (who was too afraid to give up control about Java) it's all about control for them, and that is sad, and never good for the health of a project.
I think this decision is not good for the Linux ecosystem. Ubuntu has now become an island that is growing more or more apart from any other bigger commercial Linux. Because they have not adopted systemd they will have to continue to develop and support infrastructure (such as ConsoleKit, independent udev) that is officially orphaned by its developers and maintainers. They are stuck with a half-obsolete stack that receives no new development. Of course, Canonical could step up and invest major work in the development of their platform, but that would definitely be a first for them, and I seriously doubt they have enough knowledgeable engineers for that. Canonical contributes barely anything to the Linux plumbing layer, much the same way they stay away from the kernel. There are now two options for them: a) stay stuck forever with a half-obsolete stack or b) invest a lot of work to develop their stack entirely on their own in order to stay competitive with us.
Anyway, summary is: I wish them good luck, they are now going their own way, stuck in a legacy stack with little new engineering, becoming an island of their own. In the short time frame they might save money with this decision, in the long run this is going to be quite expensive for them, since as our stacks start to diverge more and more adopting systemd later on will get more and more expensive.
That all said: I am sure that "cloud" and "focus" (Mark's favourite buzz words) are totally going to make Upstart a piece of software of the future... ;-)
It's a sad day for the Linux ecosystem. But it makes things a lot easier for us, since we can give up on any considerations of making it easy to them and keeping their way into the systemd world open.
From what I am hearing behind the scenes this appears to be very much about control. They control Upstart (both by being maintainer and even enforcing copyright assignment), and they think they don't control systemd. Of course, free software has never been about control, and whenever something deviates too much from where you would like it to go you have the freedom to fork. [In addition in times of git it is dead-easy to maintain your own patch set.] Similar to companies like Sun (who was too afraid to give up control about Java) it's all about control for them, and that is sad, and never good for the health of a project.
I think this decision is not good for the Linux ecosystem. Ubuntu has now become an island that is growing more or more apart from any other bigger commercial Linux. Because they have not adopted systemd they will have to continue to develop and support infrastructure (such as ConsoleKit, independent udev) that is officially orphaned by its developers and maintainers. They are stuck with a half-obsolete stack that receives no new development. Of course, Canonical could step up and invest major work in the development of their platform, but that would definitely be a first for them, and I seriously doubt they have enough knowledgeable engineers for that. Canonical contributes barely anything to the Linux plumbing layer, much the same way they stay away from the kernel. There are now two options for them: a) stay stuck forever with a half-obsolete stack or b) invest a lot of work to develop their stack entirely on their own in order to stay competitive with us.
Anyway, summary is: I wish them good luck, they are now going their own way, stuck in a legacy stack with little new engineering, becoming an island of their own. In the short time frame they might save money with this decision, in the long run this is going to be quite expensive for them, since as our stacks start to diverge more and more adopting systemd later on will get more and more expensive.
That all said: I am sure that "cloud" and "focus" (Mark's favourite buzz words) are totally going to make Upstart a piece of software of the future... ;-)
It's a sad day for the Linux ecosystem. But it makes things a lot easier for us, since we can give up on any considerations of making it easy to them and keeping their way into the systemd world open.
View 62 previous comments
+Colin Guthrie I'm afraid I'm missing why it makes so much sense for everybody. Having / as just mount point works if you have an early boot system taking care of what the current / does, so you are back to square one for most purposes...
So basically shoveling "/usr contains everything" down everybody that do not care is just spite.Apr 27, 2012
+Scott James Remnant :-D Meanwhile, do you feel that ChromeOS can forego the initrd because it's shipped on known hardware, or is a whole stack of hardware compat stuff built into the kernel image itself?Apr 27, 2012
+Luca Barbato OK, so I'm afraid I don't really buy the "spite" argument. I mean spite is a strong driving force but I'm pretty certain it's not the driver here :p
Let's backup for a second and think about this logically. You, as a user, sysadmin, whatever, decide that you need a separate /usr. Why is this in the first place? I can think of two reasonably good arguments for doing this: 1) Because I'm building a datacentre and I want all my machines to share the same /usr saving me sysadmin overheader, or 2) I'm a user who cares about security and I want my /usr mounted readonly unless I am doing my upgrades (maybe with a few hash checks on top for good measure). There may be other reasons too of course, but in most cases on a typical laptop or single server a separate /usr is not needed.
Now let's consider the case of not using an initrd. You might have an ext4 /usr. That's fairly easy, all you need is mount and maybe a handful of other binaries (fsck) and libs in / for that. OK, so we move those that should, by rights, be in /usr into / to deal with that and you're happy. But now another user has an LVM /usr, so we have to move all the LVM stuff into / too, (lvm2, vg*, lv* binaries) but because these tools link against ncurses, we also have to move libncurses and libncursesw into / too. OK, that's now done. But wait! Someone has RAID /usr, so let's move mdadm, let's move cryptsetup, let's move all the other stuff that's needed for the plethora of filesystem setups there too!
OK, so now everyone can get their boot, but what about the two previous scenarios that were outlined for having a separate /usr in the first place? 1) Server install sharing /usr. OK, so now this is basically completely broken. It just doens't work any more, I have no mount, no libncurses, etc. so I have to share the root FS too. This is certainly not the neat an manageable system I'd hoped for. 2) The security concious user now has a much harder job as he cannot simply mount his encrypted /usr readonly and avoid certain problems, he has to now implement systems to verify the mount and cryptsetup binaries and all the libs in / too if he wants to audit his security.
So, fine, believe it is spite if you like. I'd rather make such decisions based on technical considerations.
So, if a distro says "we'll only support a separate /usr when the initramfs deals with the job of mounting it before init" I think, "that's great" because it actually allows me to do even more crazy things with my setup because I can tweak the initramfs a lot more easily than I can the running system to move binaries and libraries around as I need them for my zany ways.
That same distro might quite happily support a initramfs free boot if /usr is not split off. The two are not mutually exclusive.
And, just to bring this back to a topic of systemd, you can still do a separate /usr with systemd without and initramfs is that floats your boat. In ChromeOS, the example du jour, this would be fine. They manage their split of binaries between / and /usr and they control it as they see fit. That, in itself, is not an argument against systemd.
So, no, it's not spite.Apr 27, 2012
Where's the -1 button when one needs it?
Lennart, you make it sound like systemd is the de-facto standard in the Linux world, while in fact it's been adopted only by Fedora, followed by an unbelievable amount of criticism from unhappy users.Apr 28, 2012
Suse is in the process of adopting it, but it's not a user-driven change at all. Just a few developers/maintainers are pushing the change, and a very few fan-boy users who just cheer whatever the devs do without really having an opinion of their own that's based on any technical arguments, and most users who say anything on the topic at all, hate it. For now systemd works ok on suse for the utterly typical desktop most of the time, and server admins know how to manually revert to sysv since both packages are still packaged and supported for this release, and regular users that have problems are generally told by other users how to switch back to sysv and that always fixes the problem. The real problems will only come when they actually remove the sysv-init package from the install sources. In any event, what suse does should not be a supporting argument for systemd's viability since suse has gone down the crapper getting worse and worse the last few releases. It's no longer a distro to hold up as a shining example of excellence. systemd should not exactly be proud that suse is adopting systemd.
Also minor addition to the list of os's that use upstart, webOS uses upstart.Apr 30, 2012
Not true anymore, happily!Feb 25, 2014
Add a comment...