Slashdot Mirror
Dag Wieers Scoffs at Coordinated Linux Release Proposal
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."
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.'
Red Hat has not provided a consumer desktop distribution in over 5 years. It used to be that most new comers were introduced to Linux via Red Hat. I would wager that today most new comers are introduced to Linux via Ubuntu. When those people who are introduced to Ubuntu have an opportunity to influence decisions in the enterprise, I would expect that many (or most, depending on the environment) are recommending RHEL because of the tremendous brand recognition within the IT world. (I know that Red Hat is not the only game in town, but they are far more prevalent in the enterprise and any other distro.) After all "it's all Linux."
So, I would say that Red Hat has already benefited from Ubuntu's run away popularity in the space the Red Hat vacated 5 years ago. What's wrong with a little reciprocity?
odd, it was my understanding that GPL'ed software was supposed to be used, not just by a few. I do understand his concern that Canonical and others should be contributing more useful software to the code base that is available but whining every time some distro uses the code that is available, adds to it and becomes popular is very very un-productive.
Sigs are too short to say anything truly profound so read the above post instead.
Right now the landscape for various projects is really a mess. Everyone kind of has their own release schedule and it's different for every project - and for good reason: we're doing this on our own time and therefore why should we care about ship dates?
Well, realistically we do. If projects knew that every May and every November there'd be major distro releases, they'd probably do a good job of freezing their trees in January and July to prepare point releases aimed at being relatively stable.
In turn, there'd be a nice set of releases that Red Hat could pick from and decrease their QA. Otherwise, it's kind of scattershot what the condition of various projects' trees are in.
----- obSig
I don't think he needs to be playing devil's advocate. I think what he's saying makes a lot of sense.
When an enterprise buys new hardware, they want the software to "just work" on it. It would be expensive for them to do the work themselves, so they are happy to pay someone else to do it. This is the value-added service that Red Hat gives. This is what an enterprise pays for.
It would be ludicrous to give your *competitor* this service for free *before* you give it to your customer. Sure, once you do the work, others can benefit -- that's part and parcel of free software. But you are allowed (I'm going to even say *expected*) to charge for your services.
Because Canonical and Red Hat are going after the same market, it is inevitable that there will be some overlap of effort. If Canonical wishes to use the work that Red Hat does, they merely have to wait until Red Hat releases.
But what worries me more here is that Canonical seems to miss the point where *creating a working distribution* is a money making opportunity. They seem to see it as a loss leader and they will charge for "support"; where "support" means hand-holding the user. Perhaps I'm wrong. I really hope I am.
Until companies understand that providing solutions and creating capability is the service where all the money is, we're not going to see the explosive growth in Free software that I'm hoping for. I had hoped that Canonical understood this. I still hope it's true, but I'm less optimistic.
I don't think this level of laziness should be encouraged
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
Not quite sure of that. A fortune 500 company I know has ceased new orders for Microsoft and investing in a Linux desktop. It is at the tender stage where where if the CIO gets a massive pricing cut the program could be nixed an not unixed.
Microsoft is under sever pressure to get it's pricing down and quality up. They falter much more, knowing Linux will be the next fad want to have skill. And those that know Linux, getting Ubuntu, RedHat and SUSE working together is much easier than a NT to AD migration, plain and simple.
Just push Open Office and FireFox to the desktops first, nice and immediate MS-Office savings and a nice prep for the conversion. And if the MS salesperson says "Linux what?" You say the OS we are using to replace MS-Windows. Gets a pretty hefty discount if you can show you mean business. Your company wins either way.
So that's the secret to making Red Hat usable, nice.
Also kindof scary to see how many things I use on a day to day basis that are in the third party repos...
Liberte, Egalite, Fraternite (TM)
The danger is that if the kernel ABI was stable, then the hardware manufacturers would think they were able to get away with releasing drivers only as binary blobs, without Source Code. This of course is highly undesirable. It also raises the nightmare possibility that repairing a deeply-embedded, totally-overlooked yet potentially fatal bug could cause major breakage. (XP SP2, and Vista UAC, I'm looking at you.)
If you want a stable ABI and binary-only drivers, then fork one of the BSDs. Hell, you can even cage the Source Code up and release the whole kernel binary-only. Recompiling something occasionally is a price I'm quite willing to pay for software freedom.
Je fume. Tu fumes. Nous fûmes!
The same goes for independent software projects. By far the largest problem across linux distributions is integration testing. Basically quite many things only work properly if you handpick specific versions of components. Introduce a little variation (like package management systems do) and basically you are looking at a unique configuration of packages that has never been tested in that exact configuration before. Feature interaction and other package interdependencies can be really tricky to test against.
The current situation of major distributions hand picking their own versions of packages + introducing distribution specific patches to them only adds to this problem. And then of course independent software developers further add to the problem by only testing on specific configurations of specific distributions. And we all know what a typical developer's workstation looks like. Few projects have the resources to organize broader integration testing.
What Shuttleworth suggests is that merely synchronizing on package versions & release schedule would broaden the scope of integration testing and reduce the amount of mostly non differentiating and needless variation. Effectively it would unify the integration testing work already done across distributions & projects and raise the level of quality across the whole community.
It's hard to see how this can be a bad thing.
A second point that Shuttleworth makes is that independent projects have their own roadmaps for stable releases. Distributions often have to deal with the fact that a nearly ready version of some component is vastly better than the year old stable version. That creates a dilemma: ship the old stable version or let users benefit from loads of useful fixes (that ultimately make the distribution more attractive). Firefox 3 beta 5 in Ubuntu was a good example. Probably a good decision but obviously the combination of OS and browser which at the time were both moving targets cannot have possibly been tested as well as would be desirable for a browser in a major desktop OS.
Wouldn't it be great if Mozilla had known a year in advance that if they'd pushed out Firefox 3 early April 2008, it would have made it into Fedora 9, Ubuntu 8.04, Slackware and Open Solaris release that each ship the exact same version of critical components that Firefox depends on.
Jilles
Correction: I am a sock puppet for CentOS :)
But seriously, one cannot have his own opinion anymore ?