User: Password:
Subscribe / Log in / New account

Canonical Goes It Alone with Unity

Canonical Goes It Alone with Unity

Posted May 22, 2010 6:58 UTC (Sat) by riteshsarraf (subscriber, #11138)
In reply to: Canonical Goes It Alone with Unity by paulj
Parent article: Canonical Goes It Alone with Unity

Once upon a time there was a solo Linux vendor named Red Hat. Then, it did not have much competition. SuSE was small. Ubuntu was non-existent. Then came Novell and Canonical.
Novell changed the definition of "Linux Enterprise Product" and Canonical slapped all who said "Linux is not yet ready for Desktop".

In the early days, there was no problem because Red Hat served upstream and could not live without this "Community Users". These users were invaluable testers and bug triagers.

But things have changed now. Now, it is a TTM game. Every vendor, that finds a bug or a fix, preferably wants to keep it a secret until its release. All vendors effectively maintain forks and carry them for the entire lifecycle.

There does not seem to be a "Community".

There's also the war of "I be the upstream for everything I ship in my product". So, if you are not the upstream of something you ship, drop it, fork it, re-label it, re-invent it and then re-ship it.

It will be interesting to see how well and how long can the GNU/Lnux Community Model sustain going forward.

(Log in to post comments)

Canonical Goes It Alone with Unity

Posted May 22, 2010 21:49 UTC (Sat) by dlang (subscriber, #313) [Link]

to many of us, redhat is not the 'early days' and while it grew huge, when it did so we remember problems of it not working with the community. the increased compeition of the last several years has improved redhat's behavior. the forks they carry for the kernel are significantly smaller than in the past for example.

Canonical Goes It Alone with Unity

Posted May 22, 2010 21:56 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]

There wasn't any 'forks' as such. Red Hat's model involves upstreaming code and backporting it for the most part and during the 2.5 days, it was larger and now it smaller. A major reason is the new 2.6 development model. Attributing it to competition when they seem to do significantly worse at upstreaming code seems odd.

Canonical Goes It Alone with Unity

Posted May 22, 2010 22:02 UTC (Sat) by dlang (subscriber, #313) [Link]

during the 2.4/2.5 days there was real work being done at redhat that was not being upstreamed to the main kernel. There were very real fears that redhat was forking linux and going their own way. in the 2.6 development model they have moved away from that and are much better at getting their patches upstream and not doing things that make their kernel incompatible with the vanilla kernel.

I remember trying to run some commercial closed source apps and finding that they would only run on the redhat kernel, not on _any_ vanilla kernel because redhat had added features that were not upstream and never did go upstream

Canonical Goes It Alone with Unity

Posted May 23, 2010 1:46 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]

Interesting claims but would be more credible with some references to specific features. Even more useful if you could show that the cause was not the development model.

Canonical Goes It Alone with Unity

Posted May 23, 2010 2:05 UTC (Sun) by dlang (subscriber, #313) [Link]

anyone who tried to use Oracle in the early days of their 'linux' support will remember how it only would run on RedHat. I didn't pursue it far enough to figure out exactly which feature they depended on, but it was known at the time that it was a kernel issue, you couldn't replace the stock RedHat kernel with a vanilla kernel without applying redhat patches to it and have it work.

the new 2.6 development model was created specifically to address these sorts of problems.

I'm not saying that when RedHat implemented a feature they did so to deliberately lock users in to their flavor of Linux, but when the upstream developers went a different direction and didn't accept what they had already shipped to customers (and had companies like Oracle depend on) that's the effect that it had.

Canonical Goes It Alone with Unity

Posted May 23, 2010 3:12 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]

What you are saying now doesn't require a non-upstreamed kernel feature and since you didn't point out any specific feature, I don't think that was the cause. Red Hat upstreamed and backported several features from 2.5 series and maybe Oracle was depending on one of them. Since you aren't claiming that Red Hat was deliberating hoarding patches, it throws out the idea of competition having any effect. If you could show any case where upstream went in a different direction and that causing ISV's to depend on Red Hat specific features, I would be very interested to hear about that. In my understanding, there is no such case. If there was a pattern of such behavior, it should be trivial to point out a few of them.


Posted May 23, 2010 15:26 UTC (Sun) by corbet (editor, #1) [Link]

TUX is a clear example of a kernel feature shipped by Red Hat which was never upstreamed - or even attempted to upstream. I also had fun in the first revision of the driver book because there were RH-specific API features in their kernel.

Whether competition has anything to do with any perceived changes is not clear to me, though. I suspect it has more to do with both the company and the communities it works in growing up.


Posted May 24, 2010 18:30 UTC (Mon) by foom (subscriber, #14868) [Link]

A personal anecdote:

RH's non-upstreamed tux patches caused me pain recently(ish). Turns out TUX added a flag to the open syscall named O_ATOMICOPEN. It used the next available O_ flag value after those used in upstream kernels. That flag was not upstreamed. Upstream then added a flag to open called O_CLOEXEC. They (of course) also used hte next available flag value.

So, new binaries which attempted to use O_CLOEXEC (even when they attempted to test for its existence before using it) would fail badly when it returned some completely unexpected random error value...

Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds