man, 22.11.2004 kl. 22.42 skrev Denis Leroy: > > Denis Leroy wrote: > > > On a more general note, is there any sort of communications between > Red > > > Hat people (who have phones on their desk) and the very few > companies > > > that do groundbreaking linux support (Nvidia, VMWare, ...) as far > as > > > release schedules and support for new kernel features ? Just > asking... > > > > To which Arjan van de Ven responded: > > what you call groundbreaking linux support... I personally consider a > > major problem... they are > > 1) Binary only, and not helping the open source goal at large forward > > 2) Borderline legal, if at all (my personal opinion is that they are > not > > legal, and abusing code I wrote) > > 3) Lagging behind and even keeping the kernel from going forward at > times. > > but.. if you buy a RHEL subscription the support guys you call will > be > > happy to work with such vendors on joint problems. > > I know this is a touchy subject :-) and the binary drivers thread > almost turned into a flame war. Arjan, in your response below you seem > to be talking about the linux kernel while i was talking about the > Fedora Core distro, and those are two different things. > > Seems to me, on one side we have the linux kernel developers whose > interests lie on improving the kernel and adding cool features to it, > and hereby rely on the strength of the open-source concept in which > API or ABI changes can be propagated very quickly. This allows the > kernel to move very fast (unlike other Unices that have been around > longer) and to maintain a very high level of quality in its > drivers. They see closed source drivers as an annoyance and hindrance, > and companies that support them as being capitalistic greedy evil > entities whose sole purpose is the demise of the Open-Source > movement. :-) > > On the other hand, we have companies that try to get some leverage out > of the Linux movement, sometimes in a clumsy fashion, or try to > respond to their customers demands for Linux support. They are usually > afraid of the GPL since it's human nature to be afraid of things one > doesn't fully understand. They usually mean well, but are uneducated > and completely unprepared for a world in which code is free, having no > processes in place for it since it hasn't been done before. They see > kernel developers as pony-tailed hippies who hate their guts and are > hard to interact with, much less rely on. :-) > > So my question was: shouldn't Fedora stand in the middle ? Shouldn't > it be the job of putting together a desktop-oriented distribution > precisely to coordinate the efforts of the various "forces" out there > (a hard and thankless job IMO), and reach compromises in order to > provide the best possible desktop experience. This has nothing to do > with kernel development, but rather in picking the right features to > use in that kernel without breaking the most popular components, > coordinating schedules and releases with said components, to make sure > a Fedora Core release doesn't break the Nvidia drivers (one of those > most popular components, whether you like it or not) or doesn't happen > one week before Firefox 1.0 is released. Isn't there somebody in the > Fedora community (whether he/she's a RedHat employee or not) that > should be working on this ? His/her job would include calling Nvidia > and saying something like this "Hi, i work on the Fedora distro. Even > though our kernel developers hate you, half of our users use your > drivers and we'd rather not break it for our next release. Is there > anything we can do?". To which there is or isn't of course, but at > least somebody's gotta try... > > Anyways, sorry for the long rant :-) What about having a "plugin" interface for drivers - ie. some hooks in the kernel where drivers could run as userspace programs, and connect to the kernel the same ways ex. mp3-plugin hooks up with xmms? The hook might even be a kernel-module... Is something like that possible? It would keep a more or less stable API for external driver devs., maybe not as fast or good as a "real" kernel driver would be - but still a driver. The processes should maybe run in some sort of space between userspace and kernelspace... Uid -1? :P - so it would gain direct access to that HW it *needs* direct access to, an no more. It might even mean that the need to recompile a module each and every time you upgrade the kernel is no longer needed. I don't have the expertice if this is technically possible at all, or even wanted. Anyone? Kyrre Ness Sjøbæk, who feels like sticking his head into a snake's nest of properitary/free and microkernel/monolithic
