Indeed, "Given enough eyeballs, all bugs are shallow.".
In this specific case there are rumors that there we probably only 4 eyeballs involved, which apparently was not enough;-)
Whatever said and done, there is big responsibility with the various Enterprise distributions and various hardware/software vendors that relied on OpenSSL for their business without doing their due diligence. Whether it was because they all expected the other to have covered that space, or because the particular source code is not easy to audit is less relevant. And I am sure that many companies are looking what can be done to improve their processes in this space.
I expect in the coming months to see more fixes for new vulnerabilities because of new audits and security testing.
So if project A can handpick improvements from project B. But project A creates 10x as many new improvements on its own. And it has 10x as many contributors to its own project. And project B is not allowed to merge back improvements (license-wise).
It simply means project A is going to win out in the long-run as long as the project stays as healthy as it is, no matter how healthy project B is. What project B can do in this case is make sufficient changes to the code-base so that improvements can not be easily merged into project A. Or make so many changes that project A runs out of resources to merge everything back into project A.
In this case specifically, it seems that AOO has the mindshare of the users and LO has the mindshare of the developers. It's more likely that a contributor knows what the difference is and where to contribute to. If ohloh.net does make something clear it is the divide between developers and users.
PS The 10x as many is taken for the sake of the argument, whether it is indeed 10x or 5x is irrelevant given enough time.
How about taking into account the holiday season ? I'd be interested to compare this with the trends for June, July, August and September the previous years, as I expect that browser-usage depends on sunny weather conditions, holiday-trips and people in the office browsing more with less work on their hands ? Maybe ?
On a global level this may mean not that much, but a 1% to 2% fluctuation could be addressed by this. So maybe we should wait until September or October before making any conclusions...
Nope, the Firefox usage numbers have always been higher in Europe than elsewhere. This has been a tendency for years. And Germany also has a historical aversion for Microsoft software and was in the past a big Linux proponent (think SuSE) and StarOffice (now OpenOffice) was bigger than Microsoft Office for years IIRC. I wouldn't be surprised if also OS/2 had a larger following to elsewhere (or at least US).
All this predates any anti-trust settlement, but I am sure that change will make a difference too, but the trend was always present.
Red Hat did not exit the desktop market, it always offered an Enterprise desktop Linux product and heavily invested in desktop development (which is what this article is about as well) and Fedora.
Red Hat also never said there was no future in Linux desktops, it basically said there is no money to be made in a consumer desktop offering at that moment, regardless of the investments they do.
Canonical is the living proof that you cannot survive on a consumer desktop Linux offering, that's why they are trying to leverage Ubuntu's installation base to get into the Enterprise server market, and are looking at different possibilities to sell you services on top of Ubuntu (think cloud).
So the Gnome census report shouldn't come as a surprise, regardless of how outspoken Mark Shuttleworth and Ubuntu's userbase is. Red Hat is the biggest contributor to Open Source and Linux, and they also have the most to gain from it too.
I am confident Canonical would like to trade places with Red Hat anytime, and until that happens they prefer to pretend they are leading Linux, rather than leading Linux development.
Not true, there is a whitelist kABI for interfaces that are guaranteed to not change. If I recall correctly, even the nvidia driver worked fine going from a RHEL5.4 kernel to a RHEL5.5 kernel. So it's not guaranteed that all drivers keep on working on any 2.6.18 kernel, but the large majority simply do.
Visit the ELRepo project page (http://elrepo.org/) or read the following document to learn how it works:
You could have saved yourself the embarrassment if you would have visited the ELRepo website (http://elrepo.org/) and tested it for yourself, or you could have googled for kABI or kABI-tracking modules. (Welcome in 2010 !)
The large majority of the drivers compiled against one kernel do indeed work for *all* 2.6.18 kernels. Only a few of them (those that do not use what's inside the kABI whitelist) have to be recompiled against a new major release kernel if an interface did change.
As one of the members of the ELRepo project (http://elrepo.org/), I would like you to take a look at the collection of drivers (kernel modules) that the project has backported to the RHEL5 2.6.18 kernel. In total more than 400 drivers have been ported and a large majority of these drivers work for every 2.6.18 kernel that was released (from 2.6.18-8.el5 until 2.6.18-199.el5), thanks to the kABI whitelist. Including exotic stuff like nvidia or video4linux.
So I fail to see the worse of both worlds. But then again, I may be biased of actually using, deploying and working with those kernels.
Tell that to the Ubuntu guy that had filesystem problems and required Red Hat's assistance to get it fixed. Ubuntu was impacted, Fedora was impacted, Red Hat's kernel was not. Why ? Because they were not running the latest and greatest. But a kernel that has been selectively patched and improved, by kernel developers that know exactly what they are doing. It can't get better than that...
There are more systems running RHEL and CentOS kernels than there are systems running the latest. Not only because the total number of systems running RHEL/CentOS is much larger than any given distribution, but also because that kernel is the same kernel, while every Ubuntu or Fedora user is using their own kernel (9.10, 10.04, F11, F12) and not updating it at the same time. Whereas RHEL5 has had the same 2.6.18 kernel with the same track-record for the past 3 years.
So if you want to run what everyone else is running, you're better off with a patched and improved CentOS/RHEL 2.6.18 kernel.
Red Hat is backporting the stuff their customers are demanding _and_ what they feel confident to support in a production environment _without_ breaking existing setups. That's the goal.
You don't do that by updating your complete kernel for one or two features you like to have. That would be insane.
Red Hat never promised you that 2.6.18-192.el5 has any resemblance or compatibility with the original vanilla 2.6.18. That would make your kernel ancient and not fit for newer hardware.
The whole "backporting is ugly/dishonest" comes from people that have no clue about Enterprise computing or have hidden agendas. A bit of common sense goes a long way...
Think about it. If your paid staff has to make a custom compilation of a vendor supplied application (and consequently keep it updated) then what are you paying Red Hat for? The days of paying Red Hat out of the goodness of our hearts are over. It's time for Red Hat to act like one of the big boys and earn their money.
So you buy Red Hat support only for perl ? No you don't ! Please be honest.
Also, bugzilla is not a customer support tool. If you want Red Hat to fix a bug then first make sure you actually pay for support and secondly use the normal channels for customer support.
Red Hat seldom pushes bugfix releases until the next update release, because you do not want customers to be exposed to new bugs outside of update releases.
Besides, if this was a bug that was exposed by a lot of companies, it would have already been fixed much sooner and was available from the fastrack repository.
Also, as a paying customer, I would not want a support team to pay more attention to people that blog about bugs or Bugzilla, than tickets in the support tool. We are heading in the wrong direction if blogposts get a higher attention than paying customers.
No duh. Every distribution has an ulterior motive, especially one of self preservation.
Self preservation is not ulterior.
So? I thought one of the main attributes of Open Source software was not to have to duplicate work.
Not quite. If one of the main attributes of Open Source software was not to have duplicate work, we should tell vim, emacs, gnome, KDE, openbsd, freebsd,...
But the main point is, everything that Red Hat does is Open Source and Canonical can reuse that. The problem is that reusing that with a different version of frozen software again requires a lot of effort, hence Ubuntu's request for aligning releases.
I don't think anybody in their right mind would confuse Ubuntu with the bleeding edge of Linux engineering.
I do not agree. Ubuntu is both bleeding edge and stable. In this whole discussion you are comparing Ubuntu with RHEL, while you should be comparing Ubuntu LTS with RHEL. Like Ubuntu LTS 6.06 with RHEL 5, Ubuntu LTS sucked in comparison to RHEL 5 and the reason is the one year difference. Similar to RHEL5 compared to Ubuntu LTS 8.04.
Opinions are like assholes - everyone has one, and Slashdot has a large number of both. I think I am beginning to see the real devil behind the devil's advocate...
For one, I did not ask to be on Slashdot I just blogged my opinion. The headline is not really flattering either, I liked Nic's proposed headline:-)
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?
Did you actually read the opinion piece. I am not saying that Ubuntu cannot take Red Hat's work (in fact, they can and do). I am saying there is an ulterior motive for Canonical to synchronise their releases with other Enterprise distributions.
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:-) Thanks for that !
What you fail to mention is that RPMforge predates Fedora and EPEL by a few years. Between 2002 and 2007 (EPEL) I attracted millions of users using my RPM packages. Packages that existed *before* Fedora came into play. Repositories did not exist back then in the RHEL/Fedora world as they exist today.
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.
Did you read the article (and not just the Slashdot headline) ?
Backports and fixes are only really useful if the release cycles are aligned (and the same kernel, glibc,...), so in practice Ubuntu cannot directly benefit from a lot of work Red Hat and Novell in the Enterprise space.
So in that regard they do not benefit from it and asking for synchronising the release cycle is a wish on their part to benefit from that work.
Commenting on articles without really reading them is very very un-productive.
Slashdot Mirror
Indeed, "Given enough eyeballs, all bugs are shallow.".
In this specific case there are rumors that there we probably only 4 eyeballs involved, which apparently was not enough ;-)
Whatever said and done, there is big responsibility with the various Enterprise distributions and various hardware/software vendors that relied on OpenSSL for their business without doing their due diligence. Whether it was because they all expected the other to have covered that space, or because the particular source code is not easy to audit is less relevant. And I am sure that many companies are looking what can be done to improve their processes in this space.
I expect in the coming months to see more fixes for new vulnerabilities because of new audits and security testing.
So if project A can handpick improvements from project B.
But project A creates 10x as many new improvements on its own.
And it has 10x as many contributors to its own project.
And project B is not allowed to merge back improvements (license-wise).
It simply means project A is going to win out in the long-run as long as the project stays as healthy as it is, no matter how healthy project B is. What project B can do in this case is make sufficient changes to the code-base so that improvements can not be easily merged into project A. Or make so many changes that project A runs out of resources to merge everything back into project A.
In this case specifically, it seems that AOO has the mindshare of the users and LO has the mindshare of the developers. It's more likely that a contributor knows what the difference is and where to contribute to. If ohloh.net does make something clear it is the divide between developers and users.
PS The 10x as many is taken for the sake of the argument, whether it is indeed 10x or 5x is irrelevant given enough time.
How about taking into account the holiday season ? I'd be interested to compare this with the trends for June, July, August and September the previous years, as I expect that browser-usage depends on sunny weather conditions, holiday-trips and people in the office browsing more with less work on their hands ? Maybe ?
On a global level this may mean not that much, but a 1% to 2% fluctuation could be addressed by this. So maybe we should wait until September or October before making any conclusions...
Nope, the Firefox usage numbers have always been higher in Europe than elsewhere. This has been a tendency for years. And Germany also has a historical aversion for Microsoft software and was in the past a big Linux proponent (think SuSE) and StarOffice (now OpenOffice) was bigger than Microsoft Office for years IIRC. I wouldn't be surprised if also OS/2 had a larger following to elsewhere (or at least US).
All this predates any anti-trust settlement, but I am sure that change will make a difference too, but the trend was always present.
Red Hat did not exit the desktop market, it always offered an Enterprise desktop Linux product and heavily invested in desktop development (which is what this article is about as well) and Fedora.
Red Hat also never said there was no future in Linux desktops, it basically said there is no money to be made in a consumer desktop offering at that moment, regardless of the investments they do.
Canonical is the living proof that you cannot survive on a consumer desktop Linux offering, that's why they are trying to leverage Ubuntu's installation base to get into the Enterprise server market, and are looking at different possibilities to sell you services on top of Ubuntu (think cloud).
So the Gnome census report shouldn't come as a surprise, regardless of how outspoken Mark Shuttleworth and Ubuntu's userbase is. Red Hat is the biggest contributor to Open Source and Linux, and they also have the most to gain from it too.
I am confident Canonical would like to trade places with Red Hat anytime, and until that happens they prefer to pretend they are leading Linux, rather than leading Linux development.
Not true, there is a whitelist kABI for interfaces that are guaranteed to not change. If I recall correctly, even the nvidia driver worked fine going from a RHEL5.4 kernel to a RHEL5.5 kernel. So it's not guaranteed that all drivers keep on working on any 2.6.18 kernel, but the large majority simply do.
Visit the ELRepo project page (http://elrepo.org/) or read the following document to learn how it works:
http://dup.et.redhat.com/presentations/DriverUpdateProgramTechnical.pdf
You could have saved yourself the embarrassment if you would have visited the ELRepo website (http://elrepo.org/) and tested it for yourself, or you could have googled for kABI or kABI-tracking modules. (Welcome in 2010 !)
The large majority of the drivers compiled against one kernel do indeed work for *all* 2.6.18 kernels. Only a few of them (those that do not use what's inside the kABI whitelist) have to be recompiled against a new major release kernel if an interface did change.
http://dup.et.redhat.com/presentations/DriverUpdateProgramTechnical.pdf
The kABI whitelist is an evolving list based on feedback from vendors, customers and the community.
As one of the members of the ELRepo project (http://elrepo.org/), I would like you to take a look at the collection of drivers (kernel modules) that the project has backported to the RHEL5 2.6.18 kernel. In total more than 400 drivers have been ported and a large majority of these drivers work for every 2.6.18 kernel that was released (from 2.6.18-8.el5 until 2.6.18-199.el5), thanks to the kABI whitelist. Including exotic stuff like nvidia or video4linux.
So I fail to see the worse of both worlds. But then again, I may be biased of actually using, deploying and working with those kernels.
Tell that to the Ubuntu guy that had filesystem problems and required Red Hat's assistance to get it fixed. Ubuntu was impacted, Fedora was impacted, Red Hat's kernel was not. Why ? Because they were not running the latest and greatest. But a kernel that has been selectively patched and improved, by kernel developers that know exactly what they are doing. It can't get better than that...
There are more systems running RHEL and CentOS kernels than there are systems running the latest. Not only because the total number of systems running RHEL/CentOS is much larger than any given distribution, but also because that kernel is the same kernel, while every Ubuntu or Fedora user is using their own kernel (9.10, 10.04, F11, F12) and not updating it at the same time. Whereas RHEL5 has had the same 2.6.18 kernel with the same track-record for the past 3 years.
So if you want to run what everyone else is running, you're better off with a patched and improved CentOS/RHEL 2.6.18 kernel.
Sorry the burst your bubble there...
What does this have to do with honesty ?
Red Hat is backporting the stuff their customers are demanding _and_ what they feel confident to support in a production environment _without_ breaking existing setups. That's the goal.
You don't do that by updating your complete kernel for one or two features you like to have. That would be insane.
Red Hat never promised you that 2.6.18-192.el5 has any resemblance or compatibility with the original vanilla 2.6.18. That would make your kernel ancient and not fit for newer hardware.
The whole "backporting is ugly/dishonest" comes from people that have no clue about Enterprise computing or have hidden agendas. A bit of common sense goes a long way...
Think about it. If your paid staff has to make a custom compilation of a vendor supplied application (and consequently keep it updated) then what are you paying Red Hat for? The days of paying Red Hat out of the goodness of our hearts are over. It's time for Red Hat to act like one of the big boys and earn their money.
So you buy Red Hat support only for perl ?
No you don't ! Please be honest.
Also, bugzilla is not a customer support tool. If you want Red Hat to fix a bug then first make sure you actually pay for support and secondly use the normal channels for customer support.
Red Hat seldom pushes bugfix releases until the next update release, because you do not want customers to be exposed to new bugs outside of update releases.
Besides, if this was a bug that was exposed by a lot of companies, it would have already been fixed much sooner and was available from the fastrack repository.
Also, as a paying customer, I would not want a support team to pay more attention to people that blog about bugs or Bugzilla, than tickets in the support tool. We are heading in the wrong direction if blogposts get a higher attention than paying customers.
No duh. Every distribution has an ulterior motive, especially one of self preservation.
Self preservation is not ulterior.So? I thought one of the main attributes of Open Source software was not to have to duplicate work.
Not quite. If one of the main attributes of Open Source software was not to have duplicate work, we should tell vim, emacs, gnome, KDE, openbsd, freebsd,But the main point is, everything that Red Hat does is Open Source and Canonical can reuse that. The problem is that reusing that with a different version of frozen software again requires a lot of effort, hence Ubuntu's request for aligning releases.
I don't think anybody in their right mind would confuse Ubuntu with the bleeding edge of Linux engineering.
I do not agree. Ubuntu is both bleeding edge and stable. In this whole discussion you are comparing Ubuntu with RHEL, while you should be comparing Ubuntu LTS with RHEL. Like Ubuntu LTS 6.06 with RHEL 5, Ubuntu LTS sucked in comparison to RHEL 5 and the reason is the one year difference. Similar to RHEL5 compared to Ubuntu LTS 8.04.Opinions are like assholes - everyone has one, and Slashdot has a large number of both. I think I am beginning to see the real devil behind the devil's advocate...
For one, I did not ask to be on Slashdot I just blogged my opinion. The headline is not really flattering either, I liked Nic's proposed headlineAnyway...
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?
Did you actually read the opinion piece. I am not saying that Ubuntu cannot take Red Hat's work (in fact, they can and do). I am saying there is an ulterior motive for Canonical to synchronise their releases with other Enterprise distributions.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
So I guess the only one who can have an unbiased opinion about Linux are non-Linux users ?
:-)
That makes so much more sense
Correction: I am a sock puppet for CentOS :)
But seriously, one cannot have his own opinion anymore ?
What you fail to mention is that RPMforge predates Fedora and EPEL by a few years. Between 2002 and 2007 (EPEL) I attracted millions of users using my RPM packages. Packages that existed *before* Fedora came into play. Repositories did not exist back then in the RHEL/Fedora world as they exist today.
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.
Did you read the article (and not just the Slashdot headline) ?
...), so in practice Ubuntu cannot directly benefit from a lot of work Red Hat and Novell in the Enterprise space.
Backports and fixes are only really useful if the release cycles are aligned (and the same kernel, glibc,
So in that regard they do not benefit from it and asking for synchronising the release cycle is a wish on their part to benefit from that work.
Commenting on articles without really reading them is very very un-productive.
This one is very easy:
;)
Everything that is not from Microsoft is called UNIX these days.