LWN.net Logo

Enterprise realtime and cooperative development

Enterprise realtime and cooperative development

Posted Dec 6, 2007 11:38 UTC (Thu) by IkeTo (subscriber, #2122)
In reply to: Enterprise realtime and cooperative development by marduk
Parent article: Enterprise realtime and cooperative development

> This could potentially break Linux in the same way that it "broke" Unix.

Unfortunately for those Microsoft guys, this is not going to happen.  Vendors successfully
broken Unix because Unix is "traditionally" licensed (even though a few rather untraditional
license conflicts did occur).  Each can have a different version, each have no way knowing how
other vendors achieve the effect they were touting, each implemented their version
incompatibly, and there is no way to have the "fork" rejoin except when a vendor acquires the
assets of another, which didn't happen very often really.

Linux is protected against this scenario by its license.  Vendors can do whatever they want to
fork their own version of Linux, extend whatever, etc.  But apart from very early adopters,
most interested developers will tell them that it is unacceptable to use their solution until
all solutions of all forks have the same interface.  At that point vendors are forced to join
their interface.  And also, GPL gives a very easy way for this to be done, since everybody
know what everybody else is doing.  Somebody is going to pick the greatest features in each of
them, perhaps reimplement them, and put them in mainline.  Then the distinguished advantage of
the vendors disappears, and they will find new things to compete on.

In other words, while Unix competitions tends to hurt everybody, Linux competition tends to
benefit everybody.  As is written by RMS in 1992, that "Competition becomes combat when the
competitors begin trying to impede each other instead of advancing themselves", and GPL
stopped that.


(Log in to post comments)

Enterprise realtime and cooperative development

Posted Dec 6, 2007 12:04 UTC (Thu) by drag (subscriber, #31333) [Link]

Having the code open source has prooven this a dozen times in the past.

The major example of this in kernel-land is late in the life of the 2.4  kernel and the 2.5
development series.  In order to meet the demands of customers Redhat and other enterprise-ish
companies backported massive amounts of code from 2.5 series back to the 2.4 and added many of
their own patches. 

That was much more of a fork then any thing else in the kernel's lifespan.

So what ended up happenning is that the kernel developers modified how the development
proccess worked in order to avoid situations like that in the future.


The truth of the matter is that real-time performance is not required for the vast majority of
use cases for Linux. In fact having a strong real-time kernel can actually degrade performance
for server and desktop workloads, as well as the normal break-stuff that large patches tend to
do.

Realtime stuff has been in the works for a long long time and as patches can be applied and
changes made to the kernel they are done. Much of the work is actually  already in the vanilla
kernel and always bits and peices are incorporated into it as time and reality permits. 2.6.23
is much more realtime-ish then something like 2.6.8 in this respect, offering better
performance and desktop response if configured correctly. 



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