As it says in the article: "How many people does this affect? Well, to
put it in perspective, it took about four months for this to come to light…"
Anyone with the time can break out Red Hat's kernel and run diff against
the upstream. I can see why they might have considered it - Red Hat is
usually the top kernel contributor with each release, so they are
sending things upstream already. Their patches usually aren't magic,
just things that haven't been accepted by the upstream and other bits to
deal with RHEL-isms. Logistically, it's easier to keep their own kernel
in git ready for a quick tarballing than have to patch it with every RPM
rollout; anyone who's ever rolled their own RPM's know the patching
process it is a real PITA.
My guess is this has a lot to do with Canonical not making kernel
contributions, and Red Hat not wanting customers to jump to the other
side. Can't say I blame Red Hat...
-Dafydd
On 03/28/2011 09:44 AM, Mel Walters wrote:
So, anyone up to thinking about what all the Kernel Kerfluffle is about?
http://www.linux-mag.com/id/8414/
I propose that the balance between business and contributing to FOSS
requires clarity of thought, and most of all, integrity and
principles.
Big subject, and fascinating how companies contribute and others
contribute when they are not . Lost my reference to where I got these
interesting details, pointed to by this article. Sorry, can't see it for
looking.
Mel
_______________________________________________
clug-talk mailing list
clug-talk@clug.ca
http://clug.ca/mailman/listinfo/clug-talk_clug.ca
Mailing List Guidelines (http://clug.ca/ml_guidelines.php)
**Please remove these lines when replying
