On Thursday 13 July 2006 08:52, luc wrote: > Le jeudi 13 juillet 2006 à 07:16 +0200, Lourens Veen a écrit : > > > > Here's another. We have a number of computers running GNU/Linux in > > our dorm, most of them (K)Ubuntu. There were some security updates > > yesterday, and I mentioned that I'd updated my machine as well as > > the one in our livingroom. My neighbour, who had an important > > presentation to give that day, said he hadn't yet updated his > > machine, preferring to do that when he didn't need it for something > > important. The following conversation followed: > > > > Me: "Well, the only thing they change is a few lines of code to fix > > the bug, so the chances of breaking something are incredibly low. > > I've never had any problems." > > > > Him: "Well, last time I upgraded the kernel, the proprietary nVidia > > driver stopped working and I was left with an unusable system." > > > > Me: "Aha, right. I told you you shouldn't be using evil and > > proprietary drivers..." > > In this case, it´s not the problem between proprietary and openess. > What's happend each time Apple provides a set of patches ? Most of > the times everything runs well after the upgrade. > Hence, in this related case, simply nVidia don´t want or cannot > follow the kernel Linux, but apparently he´s more keen to follow > Apple. (Not sure that, the fact that Darwin is a micro-kernel make > all the difference)
Also, there's only one Apple, and only one MacOSX kernel. It's much easier for them to synchronise. Making your binary-only driver work with a gazillion Linux-based distributions, all of which have different kernel configurations, is a lot harder. When a programme becomes free software, everyone can build (on) it, and it can explode into a huge amount of (slightly) different versions/build. Open Source solves that problem: you simply add more maintainers, who each maintain their own version and make sure it works. The problem occurs when you attempt to interface between a proprietary programme and a free programme. Unless there is a well-defined ABI, the makers of the proprietary programme have to keep track of everything on their own. Another way of looking at this is by analogy: rendering pixels, like maintaining builds, is a parallelisable problem. Attempting to maintain proprietary driver builds for all of the various kernel builds out there is akin to rendering graphics on the CPU: it's never fast enough. So, OGA is to driver build maintainability what OGC is to rendering graphics. Ehhm... ;-) Lourens
pgpLk9f18aIpl.pgp
Description: PGP signature
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
