| |||||||||||||
|
| |||||||||||||
Enterprise realtime and cooperative developmentEnterprise realtime and cooperative developmentPosted Dec 5, 2007 22:39 UTC (Wed) by marduk (subscriber, #3831)Parent article: Enterprise realtime and cooperative development
This could potentially break Linux in the same way that it "broke" Unix. One of the problems with Unix venders is that they really tried too hard to distinguish themselves from the competition, claim to be the only "true" Unix, and basically segregate and, IMO, weaken Unix as a whole.
(Log in to post comments)
Enterprise realtime and cooperative development Posted Dec 5, 2007 23:52 UTC (Wed) by JoeBuck (subscriber, #2330) [Link] The analogy to the old Unix days is wrong, because in those days the extensions and forks were proprietary and incompletely documented.What we're seeing now not going to break anything. Because all of the patches are GPL, we're seeing a constant process of forking and re-merging. Tools like git make this easier to manage. Right now both Red Hat and Novell have to provide extensive patches because the fundamental stuff isn't in the kernel, but this will change. As everyone gets more experience with this code based on actual deployment, it will be easier to get the upstream kernel to accept it, and the Linus kernel will get the hard real-time capabilities now seen only in vendor kernels.
Enterprise realtime and cooperative development Posted Dec 6, 2007 11:38 UTC (Thu) by IkeTo (subscriber, #2122) [Link] > 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.
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.
|
|
||||||||||||