Dag Wieers Scoffs at Coordinated Linux Release Proposal 240
Nic Doye writes "Dag Wieers responds to Mark Shuttleworth's recent request to ask major Enterprise Linux distributions to synchronise releases, claiming that it 'is no more than a wish to benefit from a lot of work that Novell and Red Hat are already doing in the Enterprise space.' He's confessing to playing Devil's Advocate here, but it is an interesting view from someone with a large amount of experience in the Red Hat/Fedora/CentOS space."
Re:For us lazy readers... (Score:5, Informative)
What did Shuttleworth propose? [markshuttleworth.com]
Why he would propose it is sort of the point. RTFA.
I don't think it is a big stink. In fact it seems a rather well thought out bit of analysis.
Re:For us lazy readers... (Score:5, Informative)
He's also one of the people behind rpmforge, which tries to make a unified repo of 3rd party add-on packages. Previously there were a number of incompatible (dependencies and so forth) repositories like atrpms. Dag's work benefits all of us who use RHEL on a regular basis.
I'm assuming that Shuttleworth proposed that every enterprise distro synchronize the release versions of certain core packages like glibc, mysql, gcc, etc, so that it will be easier for vendors to target linux distros with their software releases. In theory it's a good idea, but not everyone has the same idea of what's important and what the right version to release is.
Re:For us lazy readers... (Score:3, Informative)
Re:Who really benefits? (Score:2, Informative)
Re:Yea, he wants to benifit - that's the point. (Score:5, Informative)
Your only options are to try to compile new driver code against the running kernel headers, which doesn't usually work because whole subsystems have changed or are entirely missing, or you can rip out the entire kernel for a new one, which doesn't happen unless you do it yourself, by compiling mainline from source, something IT shops aren't likely to do.
Look at the example i quoted, they are saying new drivers got added to the newest kernel but because of the way the kernel works, large amounts of developer time are needed to get new drivers working on existing systems.
This is quite obviously a problem, but the kernel devs seem opposed to the idea of a stable module ABI, there is even a file in the source tree which says something like "you think you want a stable module ABI, but you really don't" its like a jedi mind trick. I understand perfectly well the implications of supporting a stable module ABI, but its necessary in some cases.
Re:Yea, he wants to benifit - that's the point. (Score:1, Informative)
Which is of course why Dell ships Ubuntu en masse, why Asus (eeePC) ships Xandros (a Debian derivative), and Shuttle is shipping Foresight. As far as consumers are concerned (which is where Linux has the most room to grow), Novell and Redhat don't exist.
Facts are fun.
Re:For us lazy readers... (Score:5, Informative)
You forgot to mention that the whole reason that there is an rpmforge is that Dag and co. refuse to operate under EPEL / Fedora's rule: Don't introduce packages that are already in the main repository. As a result, Dag's archive and rpmforge will conflict with the base distribution or EPEL on some packages. Once in a while, I'll grab a spec from Dag and rebuild packages for RHEL/CentOS, but as a matter of policy I don't allow rpmforge repositories to be added to any of my systems. His work does make my life easier. Technically. From time to time. However, suggesting that there are no longer incompatible repositories gives him too much credit, I think.
Re:Who really benefits? (Score:5, Informative)
It's quite simple really they dont want fresh OSS software to be associated with the red hat brand. Fedora will have bugs and be considered "unstable" to many who are looking for no noticeable bugs in thier OS. If fedora was called redhat desktop people would be going around saying i tried to install "red hat" and the instal failed.. they wont differentiate redhat desktop from redhat server in mindshare, it will redhat will lose its brand as a stable serious company. This way I get my fast moving OS and i know what it is, yet newbies wont start branding redhat as a P.O.S cause it didn't install on their emachine.
Comment removed (Score:4, Informative)
Re:For us lazy readers... (Score:5, Informative)
Re:For us lazy readers... (Score:5, Informative)
When Fedora started I was very interested to help out (read those lists), but nobody within Fedora cared about the millions of Fedora/CentOS/RHEL users I provide packages to and Fedora Extras did not want to support the RHEL/CentOS users at the conception.
Only in 2007 they started to care about RHEL/CentOS users, mostly because Fedora itself is using CentOS for their infrastructure. At that time the Fedora packages were already incompatible with RPMforge packages.
So tell me, what did *I* do wrong here, except caring for my userbase where Fedora didn't.
If the Fedora project wants compatibility, why are they expecting the work to be done by 2 individuals ? I certainly cannot spend that extra effort.
Re:Who really benefits? (Score:2, Informative)
You mean like this? [ubuntu.com]
Granted, RedHat's list is vastly larger, but they have been on bussiness (and on top) for much longer than Canonical/Ubuntu.
Oh, and please tell me when I can get a Dell laptop with Fedora installed on it.
Re:Who really benefits? (Score:2, Informative)
Anyway...
I don't understand Dag Wieers' problem? He's upset that Ubuntu may be benefitting from Red Hat's work on a piece of GPL software that allows for the free distribution of derivative works? It was this attitude that caused backlash toward RedHat which forced them to introduce Fedora in the first place. Am I the only person who remembers Red Hat as trying to be the Microsoft of the Linux realm?
Canonical does not have the workforce to do what Novell and Red Hat are doing and by aligning releases they can much easier just take that work instead of having to re-apply it to their own frozen releases of software. So for Canonical that would be a huge plus, while there is little or no value to Novell and Red Hat to do so.
Besides, there is nothing stopping Canonical from doing so already (follow Red Hat's release cycle) except maybe the perception they create and the fact they won't be leading engineering.
There are some other false statements (and emotions) in your comment, but they are a very good source for another opinion piece