> De : Lourens Veen <[EMAIL PROTECTED]>
>>> 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. You're right, but here you point the crude reality that Linux on desktop and the whole paradigm of a Linux distribution cannot be a "platform". In fact, it could be, but that implies a committement from the developers and the distros (who seems unwilling to drop their buisness model) > > 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. The real problem starts with this offspring of versions (forks or patches, call that as you want) *without* a core of cross-compatibility. Or if you prefer, the open-source developement afford a great liberty of expression, but it doesn't bring by itself any coordination Concerning a well-defined and *stable* ABI about drivers, this has always raised a lot of concern and a lot of messy ideological purpose. In fact a communitary developement doesn't let very much choice for any actor : either he joins the community or opens the source; either he stays aside and as you explain, he can't satisfy all that diversity. The proprietary developement set the thing differently : everybody is a third-party for everybody and that implies by itself a platform which is mainly raised through social domination. Conclusion : beside the lack of coordination in the OS developement, everyone enjoys a real liberty of expression, nonetheless that can't provide a platform by itself. On the contrary, in a closed developement, all the game is to impose a platform by any means, that drives the expression to follow the leader accordingly to his rules. Meanwhile a hardware is like a platform since once produced it won't change. Hence, an open hardware would solve the recurrent issues with closed-drivers and could bring a bridge between the OS community and any third-party though, on the principle) > > 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. If the analogy is correct, it matches with my conclusion : an OH could bring a kind of stability in the relationship > > Ehhm... ;-) > > Lourens > _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
