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?
I'm sure many of us Slashdotters who can't be bothered to read the article, much less do research, would love to know:
Who is this Wieers fellow?
What exactly did Shuttleworth propose?
What's the point of syncing Enterprise Linux releases?
What is and why is Wieers making this big stink?
The government can't save you.
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.
Yes. Shuttleworth would benefit from synchronized releases. If there wasn't some advantage for his project, he wouldn't have suggested it. What he's suggesting is that everyone else would benefit too.
Sure, Red Hat puts a lot of effort into hardware support backports. But if Ubuntu, Debian, Novel and Red Hat all standardized on the same kernel releases for their six-month release cycles then hardware vendors would have one platform to target instead of four. That might very well increase vendor cooperation - even to a sufficient extent that Red Hat would get better hardware support than they have now with less investment.
-- The act of censorship is always worse than whatever is being censored. Always.
Synchronizing the major distro releases helps to distribute testing and integration load among the enterprise supported distros while helping upstream developers by giving them fixed integration deadlines. All of that is good for Linux, and helps to keep distros and upstream vendors doing what they're good at, which enterprise loves. Which begs the question: is Red Hat thinking that growing the enterprise Linux space is harmful to its interests?
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
Linux will be doomed if people start benefitting from others work!
Maybe I should also write an article so that I can be quoted as "...Bogaboga supports Coordinated Linux release proposal..."
"If he can use that same kernel, with the same backports, fixes and regressions tests, Ubuntu LTS does not need to do anything to support the same vendor hardware. Easy, but at the expense of both Novell and Red Hat."
I feel a borg joke coming on....something about a collective maybe?
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.
Das Wiener! Sorry it's late.
then what Shuttleworth is suggesting is the idea of seasons. If everyone can get on the same page a couple times a year, the rest of the time they can go do their migration, vacationing, rewrites, refactoring, day-jobs, etc. If it makes sense for mother nature, it might just make sense for our software ecosystem.
Emergent cooperation FTW!
Big glob-o-stuff goes out the door on a known schedule.
What could be simpler?
Here is Mark Shuttleworth's insightful response when I asked him, "Why would Red Hat cooperate with Ubuntu, especially now that Ubuntu also has its sights set on the server market. Don't they consider Ubuntu a threat?"
Some operating systems provide a well defined (documented) set of interfaces/APIs/libraries to develop with. Version info included.
Some don't.
The market shows which philosophy is more successful.
It would be a very reasonable effort to develop a standardized "driver API" for drivers and whatnot. Linus could easily issue an API that is standard, year by year. EG: 2007 API, 2008 API, 2009 API, etc. It doesn't have to be by calendar year, but it does have to be CONSISTENT.
And makers of hardware could easily write drivers to this API, binary or source, and release these in yum/apt repos, so that any distro could do a quick check for the hardware, and instantly know what repo to go to with a simple lookup.
Once this is done, WHO FREAKIN' CARES what date something is released? The only thing that matters is the driver API. If that's honored, the game is over. I imagine yum/apt repos for drivers published by driver manufacturers that are discovered "automagically" by distros. It not only wouldn't be that hard, it would be trivial if the right effort was put into the right place.
(Sigh). I can dream, can't I?
I have no problem with your religion until you decide it's reason to deprive others of the truth.
From my point of view only Ubuntu would benefit from such a synchronized release schedule. Well, I guess then it's best that they change their release cycle to Red Hat's. That's not too difficult to achieve as RH announced its schedules quite early.
So if you want free beer - go and get it yourself!
A co-ordinated Linux would help the Linux user, so it is a good thing to stop all this Linux nightmare. Just make it easier for desktop users to use Linux, that is what we want. Co-ordinated kernel is a good thing.
But will the monopolistic behaviour of RH allow this. Interestingly RH is killing Linux in the long term by smoothering others. Because of this behaviour more are looking at Ubuntu and OpenSolaris.
Novells SLES and SLED are released every 18 months. openSUSE is released every 8 months.
Also SLES and SLED are maintained 7 years.
Does this mean manpower? Yes, especialy for the parts of the distribution where no updates are provided anymore. e.g. where the production has completely halted. This has to be maintained by Novell themselves. Just download the source if you so desire and you can copy and paste it into your own code.
How do they do it, except for editing the code? https://build.opensuse.org/. Hey Mark, if you like, you can download it and put your distributions on it, letting the community handle the security updates. It is able to build complete distributions, so you can then build them as often as you desire. Yes, it handles Ubuntu as well.
Don't fight for your country, if your country does not fight for you.
Mark Shuttleworth's proposal is one of the most important and well-thought out ideas in a long time, and essential in the effort to make Linux compete successfully against Windows. And, solving bug #1 on Ubuntu's bugtracker.
Currently, the release of any distribution, no matter when it happens, will be a snapshot of all the included software packages. Some will be mature, some will just miss a major update, some may be unstable, some may be bleeding edge experimental.
Ubuntu is currently synchronized with Gnome, but the more projects that are able synchronize on a fixed schedule, the more complete, bug-free and up-to-date the distributions will be, because their set of software contains newly released, stable and debugged versions.
This all boils down to the fact that users will get a much better experience, and Linux will shine at its finest. All distributions will benefit from it.event-driven release, "When It's Done."
.. ah, dude, Hitler's dead ... we nailed him years-ago?"
is like migrating When It's Time.
Clock-driven release, is like
"Hurry Up! Hitler said we have to move, because he's going to come through here soon!
Artificial deadlines create artificial stress, artificial requirements, artificial breakage.
When It's Done, with a disciplined crew, produces much less breakage, and therefore, even for all the whining done by those who wanted you to produce "yesterday" ( who will whine when anything is flawed, due to *their* artificial-hurry/rush! ), is a better-in-the-end solution.
Having a *divided* release-schedule, rather-than a chaotic one ( SuSE spring/fall, RH summer/winter ), however, would
a) be general-enough to allow flexibility, and
b) suppress the risk of pervasive vulnerability/exploit, *across* distros, since they'd be staggered, rather-than lockstep, and
c) would allow quicker learning
( oh, SuSE released driver N 2 months ago, and we now know it doesn't work, lets leave it out of our release next-month... )
I hope they DON'T do the Artificial Lockstep BS dance, and stick to code-quality, instead!
Cheers
I used to work at Morgan Stanley. Their unix and linux environments are incredible. I've worked at several large financial companies, and Morgan Stanley was probably the best (read: most mature, robust) technical environment I've ever seen.
I didn't know they'd released Aurora publicly, but I'll definitely need to check it out now.
I have Fedora on one system because it handles one scenario more easily than Ubuntu, x86_64 having to install third-party 32-bit software. Other than that, the system is frustrating:
-Their 'releases' seem to mean little. They don't stick to the major revisions of software (Fedroa 8 box updated kernel to 2.6.24 and pidgin to 2.4 for example). As a result, third party drivers can exhibit different glitches or not work at all even during a routine update. Pidgin changed its UI and initially started crashing for me a lot when they went to 2.4. No matter what Fedora path you take, you are submitted to the bleeding edge across the board, not just the areas you are intrinsically interested in.
-They have no interest in helping users have a convenient time with binary software. I.e. annoying to install flash, nvidia, or ati binary drivers. It's one thing of the OSS alternatives are remotely comparable, but they simply are not at this point. ath5k when first adopted was no where near good enough for common usage. The nv driver is a waste of paying the nVidia premium. Ditto for the open source ATI driver until those efforts see fruition. And the open-source implementation of flash is getting closer, but is still far removed from a viable alternative.
All in all, Fedora feels to an extent like crippleware and a rolling beta. Knowing explicitly that as a user you are little more than a free tester for RedHat's for-profit endeavor is annoying. If I were interested in a specific major increase of a package such that I didn't want to wait a few months for the next distro rev, I'd download it myself.
Ubuntu's releases are not perfect (the hardy scheduler annoyance a good example), but the complaints are far less severe and I know when an update might require work. I'm too lazy to have to deal with a major change at a random time. It's the reason why I stopped using Gentoo after a couple of years.
Sorry to rant, but the implication that Fedora is 'geeky' and Ubuntu is not rubbed me the wrong way.
XML is like violence. If it doesn't solve the problem, use more.
Don't lose track of the fact that Red Hat turned its back on the community and went all commercial. Then realizing that they had both alienated the community and lost a lot of software help they crawled back and put their Fedora on the table. Fedora is a diode - all the benefits flow in one direction. Mark Shuttleworth is still sold out on community and helping advance the state of the art where Novell has sold out on profit and uses the community the same way Microsoft does.
This has been obvious to me for a long time. And it's obvious that, even with the tremendous amount of development that they do, RedHat has been going in the wrong direction. They do a fine job with hardware support and security updates and building distros that are well-integrated and up-to-date, if somewhat of a pain to administer. But RedHat is still missing the one final step, the market that Canonical has done so well in of late: putting Linux in front of the average user and MAKING IT WORK FOR THEM. And you can bet your ass that RedHat considers Canonical a threat.
The potential of Linux doesn't lie in selling a $500 OS that's better than Windows for a few enterprise users. It lies in selling a $50 OS that's better than Windows for the vast majority of users, and for the users that don't even own computers yet.
On the other hand, it's good that Shuttleworth has finally learned the folly of a six-month release cycle. It's unfortunate he had to fork Debian to learn that lesson. And ironic, of course, that Debian is one of the distros he's now asking to coordinate efforts with. For all the jokes about Debian Stable being old, it's one of the few versions of Linux that doesn't consistently come with some glaringly obvious broken component in the form of a pre-release or Beta from upstream.
"I assumed blithely that there were no elves out there in the darkness"
What license is the code under that prohibits that from happening? Modular binary blobs are already OK with the espoused license of the kernel it works with.
What MAY be an issue is that, for example, the license ***NVidia*** have their code under requires that only THEY or paid up members can distribute the driver. NOT the GPL. NVidia.
The Linux distributions got all of you by the balls with the precompiling of packages and products that are dependant on the OS release.
It also seems many of the Linux world savor this without realizing how you got cold-cocked. Ask the really important question of "WHY does Gnome 3.xx.x REQUIRE FC/RHEL/LinuxN 4.xx, and also WHY can't the same Gnome 3.xx.xx run on FC/RHEL/LinuxN 7.xx?" Did some API change between OS releases that broke everything? Why are you using an OS where every release is an 'API' breakage??
Ask yourself, does every release of World of Warcraft/Microsoft Office/Dawn of War require you to have a SPECIFIC Windows XP/2000/Vista version release (beyond security patches) with a complicated web of dependencies? Why can't I install multiple versions of gcc/OpenOffice/Python/etc in the way the original vendor didn't limit me?
Your middle-man got you dependent on them for their drug 'releases' in order to fulfill your basic needs.
The base OS and the package system SHOULD NOT have any dependencies on each other and ideally should not even care which version of what you have installed beyond simple ABI limitations. It should allow side-by-side execution of multiple versions of programs/libs, because software is long-lived and everybody has different needs.
This is another reason Linux will never overshadow Windows simply because the community and the commercialization has chained the users to this never ending, single-pipeline upgrade treadmill in a single-release turn-key/embedded-like/PalmOS-like system fashion. Funny enough, raw Linux itself doesn't limit the users either.
So, if you can get away from the endless, locked-in, upgrade whipping, you can then focus directly on the app itself and which version serves your needs best instead of which OS has the version of the application you need. The decision between PHP4 or PHP5 requiring hours of paid, 'managed' care support contracts because the vendor doesn't "support" it.
Myself, I live on Ports which suffers no such middle-man, straw-sucking limitations beyond keeping the port framework up-to-date.