Mod parent up! Wikipedia is a battleground between small groups of highly focused editors (and I'm being kink by not using some medical term here), and the occasional blokes with too much time on their hands. The fate and content of any article is usually decided by no more than a handful of people. Don't take my word for it, check out http://wikidashboard.parc.com/.
The contested articles have all the scars of a battleground, which seriously impacts readability. Try reading articles affected by Israel-Palestine, Korea-Japan or Creationist-Scientist wiki-wars.
The uncontested articles often read like pure puff, fancruft or obituaries. Try reading some pages about anime characters, or the biographies of obscure individuals that don't get deleted because of their close affiliation with Wikipedia administrators. Did I mention the vanity pages kept by most admins? They used to get indexed by Google until this month.
The well written and informative articles on notable topics are quite rare.
So, what? Wikipedia is not a criminal court! If something is deemed not notable for lack of evidence the worst thing that can happen is... the lack of a web page on some site on the intertubes. You make it sound like the thing gets nuked off the face of the earth. Besides, notability can always be established later. This actually happened with Deletionpedia: as the deletion of the article was being discussed, which normally last a week, more sites picked up the story, and the site *became* notable. So, I don't see what's broken here. Move along...
In due time you can probably expect a more complete picture of what happened. I think the "Fedora/RedHat keeps us in the dark" view is overly alarmist.
The main Linux distro advantages I see: 1) fully "packetized" distribution. I haven't checked *BSD in a couple of years, but you could not upgrade just about anything as a package. The arbitrary distinction between the OS and ports does not exist in linux distros. 2) better hardware support outside the pure-server world. Even in the server world, you get Intel to write Linux drivers for their hardware, but no so for *BSD. Dunno if this makes much of a difference. 3) you get a few non-FOSS apps like acrobat, flash etc. Presumably they run in binary compatibility mode on *BSD, but why bother?
Ports suck if you have to compile stuff on a low end machine. I've also seen broken port compilations that were really hard to fix. Never saw that with source rpms (as long as built them on the distro they were written for).
There's no rule that patches applied on bugzilla are to be reported upstream!... Upstream devs can register to receive any and all buzilla tickets for their products, if they chose to do so.
Wow, how generous. They distribute software that I write to their users under the same name as my version while potentially applying patches that I may never see unless I go looking for them. Can you see how a bad patch like this might give users the wrong impression about the software I wrote, or how having to check every potential distributor of my software might not be the most enjoyable use of my time?
You seem to want others to redistribute only your pristine sources. Then don't write FOSS, which, horrors, other people can patch, redistribute, and never tell you about it. Or better, sue RedHat for libel or for diminishing the value of your company's stock, that would teach them!
And, lo and behold the bug will be fixed:
A bug which was never present in a stable release of Perl -- the only reason it was present in the Red Hat version of Perl is because Red Hat took a patch from a development version of Perl and kept applying it even
Which was entirely appropriate at the time, given then minimal-patch policy. You seem to imply that they should have upgraded perl instead; that may have caused more regression failures than you think, and would have been far costlier as QA. RHEL is not even Fedora, let alone Rawhide.
I sometimes run system with patches that aren't even in Rawhide yet. Why? Because I have submitted them upstream, so I stake my reputation that they'll work.
to stable releases of Perl when it was no longer appropriate.
That's indeed a *uck-up. You seem to want to hold RedHat to a level of QA that is hardly appropriate. Like Perl never had any bugs of its own or something.
1) CentOS is *not* a RedHat product. So, Vipul, you don't lose any support... because you're entitled to none!
2) For the sake of clearing the FUD with RedHat's bugzilla's policies, here are some details on how it works: - There's no rule that patches applied on bugzilla are to be reported upstream! Some (large) packages have over 100 patches applied. How would *you* feel if RedHat spammed you every time they applied a patch to whatever software you wrote? - Upstream devs can register to receive any and all buzilla tickets for their products, if they chose to do so. Some do, some don't. Those that don't sometimes end up complaining that "RedHat/Fedora is keeping patches secret!". Duh. - When a bug is reported on bugzilla, especially a crashing bug, only a _minimal_ fix is applied that fixes the crash. The patched package goes on QA for a while.
In the Perl story above an upstream patch was applied, so it made *no* sense for RedHat to report it upstream. Turns out that the patch (alone) caused another problem (slowdown). The normal thing to do was to file another bug report on it. Which did happen! And, lo and behold the bug will be fixed:
-- Comment #14 From Marcela Maslanova 2008-08-08 02:42:52 EDT -- This bug will be solved in RHEL5U3.
So Vipul, which didn't contribute a cent to RedHat by using CentOS, is biatchin' that RedHat is simply following the cautious QA policy that RHEL is known for. Perhaps he needs to use another distro that provides more bleeding edge updates, with the obvious risk entailed by less QA. Not that RedHat would give a hoot what Vipul is using (for free)...
Slashdot Mirror
Well said. Mod parent up. You should also consider that Wikipedia is not supposed to be the sum of all local newspapers.
http://en.wikipedia.org/wiki/Wikipedia:WikiSpeak
See also
http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Ed_Kalnins
http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Thomas_Muthee
Not only that, but scientists who do not waste their time studying Wikilaws often get booted off Wikipedia for minor infractions, for instance http://allswool.blogspot.com/2008/04/tyranny-of-ignorant.html
Mod parent up! Wikipedia is a battleground between small groups of highly focused editors (and I'm being kink by not using some medical term here), and the occasional blokes with too much time on their hands. The fate and content of any article is usually decided by no more than a handful of people. Don't take my word for it, check out http://wikidashboard.parc.com/.
The contested articles have all the scars of a battleground, which seriously impacts readability. Try reading articles affected by Israel-Palestine, Korea-Japan or Creationist-Scientist wiki-wars.
The uncontested articles often read like pure puff, fancruft or obituaries. Try reading some pages about anime characters, or the biographies of obscure individuals that don't get deleted because of their close affiliation with Wikipedia administrators. Did I mention the vanity pages kept by most admins? They used to get indexed by Google until this month.
The well written and informative articles on notable topics are quite rare.
http://en.wikipedia.org/wiki/Wikipedia:DRV
So, what? Wikipedia is not a criminal court! If something is deemed not notable for lack of evidence the worst thing that can happen is... the lack of a web page on some site on the intertubes. You make it sound like the thing gets nuked off the face of the earth. Besides, notability can always be established later. This actually happened with Deletionpedia: as the deletion of the article was being discussed, which normally last a week, more sites picked up the story, and the site *became* notable. So, I don't see what's broken here. Move along...
https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00842.html
In due time you can probably expect a more complete picture of what happened. I think the "Fedora/RedHat keeps us in the dark" view is overly alarmist.
The main Linux distro advantages I see:
1) fully "packetized" distribution. I haven't checked *BSD in a couple of years, but you could not upgrade just about anything as a package. The arbitrary distinction between the OS and ports does not exist in linux distros.
2) better hardware support outside the pure-server world. Even in the server world, you get Intel to write Linux drivers for their hardware, but no so for *BSD. Dunno if this makes much of a difference.
3) you get a few non-FOSS apps like acrobat, flash etc. Presumably they run in binary compatibility mode on *BSD, but why bother?
Ports suck if you have to compile stuff on a low end machine. I've also seen broken port compilations that were really hard to fix. Never saw that with source rpms (as long as built them on the distro they were written for).
Wow, how generous. They distribute software that I write to their users under the same name as my version while potentially applying patches that I may never see unless I go looking for them. Can you see how a bad patch like this might give users the wrong impression about the software I wrote, or how having to check every potential distributor of my software might not be the most enjoyable use of my time?
You seem to want others to redistribute only your pristine sources. Then don't write FOSS, which, horrors, other people can patch, redistribute, and never tell you about it. Or better, sue RedHat for libel or for diminishing the value of your company's stock, that would teach them!
A bug which was never present in a stable release of Perl -- the only reason it was present in the Red Hat version of Perl is because Red Hat took a patch from a development version of Perl and kept applying it even
Which was entirely appropriate at the time, given then minimal-patch policy. You seem to imply that they should have upgraded perl instead; that may have caused more regression failures than you think, and would have been far costlier as QA. RHEL is not even Fedora, let alone Rawhide.
I sometimes run system with patches that aren't even in Rawhide yet. Why? Because I have submitted them upstream, so I stake my reputation that they'll work.
to stable releases of Perl when it was no longer appropriate.
That's indeed a *uck-up. You seem to want to hold RedHat to a level of QA that is hardly appropriate. Like Perl never had any bugs of its own or something.
1) CentOS is *not* a RedHat product. So, Vipul, you don't lose any support... because you're entitled to none!
2) For the sake of clearing the FUD with RedHat's bugzilla's policies, here are some details on how it works:
- There's no rule that patches applied on bugzilla are to be reported upstream! Some (large) packages have over 100 patches applied. How would *you* feel if RedHat spammed you every time they applied a patch to whatever software you wrote?
- Upstream devs can register to receive any and all buzilla tickets for their products, if they chose to do so. Some do, some don't. Those that don't sometimes end up complaining that "RedHat/Fedora is keeping patches secret!". Duh.
- When a bug is reported on bugzilla, especially a crashing bug, only a _minimal_ fix is applied that fixes the crash. The patched package goes on QA for a while.
In the Perl story above an upstream patch was applied, so it made *no* sense for RedHat to report it upstream. Turns out that the patch (alone) caused another problem (slowdown). The normal thing to do was to file another bug report on it. Which did happen! And, lo and behold the bug will be fixed:
-- Comment #14 From Marcela Maslanova 2008-08-08 02:42:52 EDT --
This bug will be solved in RHEL5U3.
So Vipul, which didn't contribute a cent to RedHat by using CentOS, is biatchin' that RedHat is simply following the cautious QA policy that RHEL is known for. Perhaps he needs to use another distro that provides more bleeding edge updates, with the obvious risk entailed by less QA. Not that RedHat would give a hoot what Vipul is using (for free)...