4 ms·
Your story is factually off, I'm afraid. Canonical comes up with a replacement for sysvinit called Upstart. Actually a replacement for both sysvinit and sysv-
by vezzy-fnord 11y ago
Your story is factually off, I'm afraid.
Canonical comes up with a replacement for sysvinit called Upstart.
Actually a replacement for both sysvinit and sysv-rc, along with some overlap for hotplug and other demand-based/lazy operations.
Everyone agrees sysvinit is a dumpster fire on wheels careening around at high speed, so a new init system is welcomed as a Good Thing.
Hah. I wish.
In fact, the painful truth of the matter is few people really cared. There was lots of prior art (and indeed, Canonical themselves chose to write Upstart instead of adopting the emerging initng at the time for largely handwaving/wish-wash reasons [1]), but not a lot of interest in seriously tackling the problem domain beyond introducing a host of band-aids on top of sysv-rc like LSB dependency headers and startpar.
Some people from Red Hat wanted to contribute improvements to Upstart, but Canonical insisted on a Contributor Licensing Agreement that would allow Canonical to relicense the work however they wanted, including commercially. Shockingly, Red Hat employees couldn't get clearance to do uncompensated labor for a Canonical project like that, so rather than contribute to Upstart, we got systemd.
In fact, "some people from Red Hat" already had deeper architectural failings with Upstart (which I agree with, but absolutely not with how they decided to "solve" them) and its event model. The beginnings of systemd (prototyped under the name of Babykit) were lying around for several years on Lennart Poettering's machine.
And at that point... game over for Upstart. Ubuntu uses systemd now. Because they don't have the resources to package everything for Upstart if Debian is moving to systemd.
Which, ironically, is a form of cooperation. And look what cooperation gets you: homogenization towards a Red Hat solution.
The thing is, Canonical isn't that well resourced. Look at who contributes to the Linux kernel.
I'm well aware of the massive corporate contribution, and Canonical's low activity there.
But they're not succeeding at it and they're not GOING to succeed without some way of becoming profitable that has yet eluded them. And developers don't want the burden of having to support Canonicals quixiotic insistence that they are the Apple of the Linux world.
Again, Canonical are at a loss, true. This is their loss, not developers'. There is no "burden" placed on them unless they decide to ship their software in binary form only, in which case the problems already exist for any distro with its own packaging infrastructure.
[1] https://wiki.ubuntu.com/ReplacementInit https://wiki.ubuntu.com/ReplacementInit
- cwyers 11y agoMost of your corrections to my story aren't really germane to the point, and mostly involve your constant flogging of a bunch of sysvinit replacements that never caught on, but there's one where I think you move from mere pedantry to being wrong: > In fact, "some people from Red Hat" already had deeper architectural failings with Upstart (which I agree with, but absolutely not with how they decided to "solve" them) and its event model. The beginnings of systemd (prototyped under the name of Babykit) were lying around for several years on Lennart Poettering's machine. Here's Kay Sievers, one of the originators of systemd[1]: > True statement. And yeah, without the CLA, we would very likely have worked on upstart, instead of starting the systemd project. Four years ago we talked to lawyers and tried pretty hard to convince them to give it up, but there was no way to negotiate. In the comments, from Scott James Remnant, who wrote Upstart for Canonical: > I don't think we ever disagreed enough for me to refuse patches from them - it was very much a case of they had different ideas to me, and couldn't contribute them because of the CLA > If the CLA wasn't there, we'd've just tugged and pulled and fought about patches like normal projects, and Upstart would have turned out much like systemd - I'd've been okay with that :) And another comment from SJR: > you'd be surprised how little of Upstart's code is the "event system". It could have quite easily evolved into what systemd looks like today, with an active community working on it. > Indeed, systemd today doesn't look much like systemd back then either, it's evolved over time - the dependency system has taken a greater forefront than the socket system it was designed around, etc. > systemd had the benefit of an active developer community, because it didn't put barriers up to contribution. People who wrote for systemd and Upstart at the time both claim that if it weren't for the CLA, Upstart would've been contributed to by the people who eventually wrote systemd instead of systemd being its own project. I see no reason to disbelieve them. [1] https://plus.google.com/+KaySievers/posts/C3chC26khpq https://plus.google.com/+KaySievers/posts/C3chC26khpq
- vezzy-fnord 11y agoKay Sievers was actually a SUSE employee at the time, IIRC. Now, there's a case to be made that the public statements of intent did not necessarily correspond to the actual function, or strategy that made systemd emerge. Quoting from Lennart Poettering's Linux Voice interview [1]: > We, at that time, thought: OK, Upstart is the future! Scott understood how init systems work – it needs to be dynamic, it needs to react to events, and it’s not the static thing that Sysvinit was. So we thought that was the way of the future, but as it progressed, we realised it probably wasn’t the future, because we realised that conceptually, it was the wrong design. Now, furthermore, the goal of systemd became "universal GNU/Linux middleware," a massively increased scope relative to what Upstart was intended to be. Though it may have been the case that Upstart could have evolved into something similar to systemd-the-PID1, it appears to me that systemd's emergence would nevertheless have been determined by the desire for a homogeneous catch-all userland suite. The Upstart architecture, relying on so-called "bridges" at the time to marshall external events to and from the internal format, would likely not have been as desirable. LP's testimony starkly contrasts with Kay and SJR. [1] http://www.linuxvoice.com/interview-lennart-poettering/ http://www.linuxvoice.com/interview-lennart-poettering/