Canonical depends on their community for everything from the very OS (Debian) to marketing to support.
Yet, they're crippling their community at the same time with their IP policy and their general refusal to integrate with software projects they depend on for survival.
This is, simply, unsustainable. Canonical cannot fork everything and do their own thing (not without quickly going bankrupt – unlike Apple, which has no problem with say, developing their own SMB stack if needed); and they cannot continue alienating potential (and current) users and upstream sources.
Why are you treating this as zero-sum?
It then becomes the problem of its users, and rapidly the problem of userland developers, because users expect their software to just work in Ubuntu.
Developers can now go and waste effort just to comply to Canonical's de facto walled garden, or lose all Ubuntu users (furthering the "Linux is too complicated and fragmented!" narrative).
Everybody loses, nobody wins.
Assuming source distribution, I do not see any special effort required.
This is a protectionist, anti-choice argument.
No special effort to support Mir/Unity/upstart? Other Ubuntu-only APIs, standards, UX, Kernel/Library versions not employed by other distributions, …?
(Upstart was killed when even Canonical realized it was impossible to demand of everyone else to support their special snowflake init system.)
It's also funny how people routinely bitch about Upstart when it predated systemd.
Would you be able to elaborate on this a little bit? It seems like a contradiction to me but it's more likely that I'm not understanding properly.
I certainly get why it would be in their interest to not have much collaboration. But if that's a problem for them, they should not have based their business around GPLd products. All these problems could very easily go away if Ubuntu were a FreeBSD distribution, not a Linux one.
This "stay in their corner, don't bother, don't intervene" does bother developers who increasingly have to code for Windows, OS X, Linux and, separately, Ubuntu. It's very unpleasant, and they're getting a lot of hate because users are suffering just because Canonical's business plan was shit.
There is no obsession over "community" or "integration" as you stated. It is a valid concern that if others can not contribute freely, we are killing the essential of what made Ubuntu possible.
It is insulting from you to call the demand for inclusion and giving back as "myopic" and "abhorrent".
Like with social interaction, we don't need everybody to be the same, but we very much demand some core principles to be followed. Would you call that myopic and abhorrent?
Most complaints about Canonical's exclusivity underpin a utopian fantasy that everyone in the Linux community must converge towards one holy solution. Any deviation is considered "fragmentation" and brutally discouraged.
One way is that, by having a "one holy solution", you avoid fragmentation and get more stuff working on end-user's systems with minimal hassle. This is why, for example, Steam targets Ubuntu. They're the 800lb gorilla of the Linux world, and if someone is a desktop Linux user, odds are high they're using Ubuntu rather than anything else. They target the most users with the least hassle.
The end user doesn't want to mess with dependencies, compilation, desktop environments, and so forth. They want their shit to work. Fragmentation is an impediment to this from a usability standpoint, and that's before we even talk about security (e.g. Android).
The other way is that by these tightly integrated, non-interoperable stacks like Unity and Systemd make life miserable for every other Linux user in the world who values the ability that they can sample this init system, that window manager, etc, and build a system that fits their needs much more closely than any of the tightly integrated one-size-fits-all solutions.
This isn't a false dichotomy either - there are no companies out there nowadays that make good software that works really well for end users with minimal hassle, while allowing the degree of customization and interchangeability that power users demand.
So pick your poison, I guess.
That is why I watch its progress with a certain degree of suspicion (disclaimer: I am a user of Apple and Canonical products.)
Canonical comes up with a replacement for sysvinit called Upstart. 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. 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.
Eventually, systemd became so [PICK ONE OF SUCCESSFUL OR BELIGERENT] that Debian adopted it. 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.
The thing is, Canonical isn't that well resourced. Look at who contributes to the Linux kernel.[1] Looking at the top 10 sponsors of contributors, we see some of the usual suspects -- Intel, Red Hat, Linaro, Samsung, IBM, SuSE. We see "Vision Engraving Systems," weirdly. Going out of the top 10, a lot of hardware vendors, spits Oracle, FOSS Outreach Program for Women, Pengutronix... I mean, look at the homepage for Pengutronix. [2] It's some 90s era HTML 4.01 they've got going on there. But they're able to make significant contributions to the Linux kernel. Canonical isn't on the list. Canonical has NEVER been on the list, so far as I can tell. You can look all up and down the stack, there's a handful of Canonical-only projects they contribute to, but they're a rounding error in overall Linux development.
Which is their right, of course -- the GPL doesn't insist upon contributing back. And I would agree that shaming Canonical about community isn't productive. At the same time, Apple isn't what they are, it's what they want to be but are failing at being. Apple can get away with incorporating BSD code into their OS but still writing vast swaths of it themselves because Apple doesn't need any of the BSDs to adopt launchd to make it feasible for them to keep running it. Apple has money and can pay people to write code. And on the desktop, OS X has twice the market share of every Linux distro combined, so they can get developers to write applications for their OS even though it doesn't follow the lead of the rest of the BSD-derived OSes. (And yes, I know that OS X resembles a BSD distro far, far less than Ubuntu resembles Debian.) You're right that Canonical wants to be the Apple of the Linux world. 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.
[1] http://www.linuxfoundation.org/publications/linux-foundation... (Also, why do I have to tell the Linux Foundation who I work for in order to read this report?)
> [1] http://www.linuxfoundation.org/publications/linux-
> foundation... (Also, why do I have to tell the Linux
> Foundation who I work for in order to read this report?)
https://lwn.net/Articles/507651/
> A newcomer to the top 20 companies is Vision Engraving Systems, thanks to the Comedi development work from H. Hartley Sweeten. With his work, hopefully this subsystem can move out of the staging area of the kernel in a future release.
> The Comedi project develops open-source drivers, tools, and libraries for data acquisition.
> Comedi is a collection of drivers for a variety of common data acquisition plug-in boards. The drivers are implemented as a core Linux kernel module providing common functionality and individual low-level driver modules.
> Comedilib is a user-space library that provides a developer-friendly interface to Comedi devices. Included in the Comedilib distribution is documentation, configuration and calibration utilities, and demonstration programs.
> Kcomedilib is a Linux kernel module (distributed with Comedi) that provides the same interface as Comedilib in kernel space, suitable for real-time tasks. It is effectively a "kernel library" for using Comedi from real-time tasks.
Frankly i see a bunch of beats fighting each other for old school territory, with the Linux ecosystem caught in the middle. None of the corporations involved with Linux are white knights, none.
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.
> 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.
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.
No it doesn't. There is no reason that "conceptually, it was the wrong design" has to contradict with "they had different ideas to me, and couldn't contribute them because of the CLA" and "it could have quite easily evolved into what systemd looks like today, with an active community working on it." It is quite easy to read those statements as being in agreement -- Lennart decided that Upstart wasn't conceptually correct, SJR is amenable to discussing merging changes that would bring Upstart in line with Lennart's ideas, but the CLA is a roadblock so Lennart goes off to form his own project. Why not adopt the principle of charity and take everyone at their word?
Discussing historical counterfactuals like this based on limited public testimony is a difficult matter, but my input here is that the ultimate breadth of changes envisioned by the systemd developers would have triggered a split anyway.
SJR's comments concern systemd-the-PID1.
Is there any reason, any at all, that you've provided to think that Lennart wouldn't have abandoned that project to contribute to Upstart, if the CLA issue had been able to be overcome? Because the testimony of people who would actually know this indicates that he would have. I mean, I'm happy to drop this argument if you find it a "difficult matter," but it seemed to matter to you enough to bring it up in the first place, and you seem to be focusing on trivialities that you think support your point rather than some pretty unambiguous statements from people who would know (and it seems hard to accuse SJR of some sort of pro-Red Hat bias ehre).
Something that can make a guy wonder if the root of the issue is Suse, as apparently that distro has always been "weird". Something that may well be a outcome of a corporate culture that former employees are now bringing with them to others.
As for LP's story not lining up with others. Not surprised. Best i can find the guy has never told a consistent account of things. The goal posts are forever moving.
I'm not sure why would anyone think this is a good thing
The FOSS obsession with "community" and "integration" is myopic and abhorrent. As if everyone must converge on one approach, one vanguard. There are scantly any problem domains where only one solution applies.
Now, Canonical keeping to themselves has a very crucial advantage: they leave everyone else alone. They stay in their corner, they don't bother, they don't intervene. They don't start a massive integration effort to drag everyone else in every time they devise something new.
We should be commending Canonical for this.