On 31/05/06 10:39, Bruce Marshall wrote:

On Wednesday 31 May 2006 11:41, Kai Ponte wrote:

...

...

do they think this is going to lead?

Very interesting - and scary - developments. I had read about how Novell was planning on de-coupling the non-GPL kernel-level drivers from the system and wondered what effect this would have.

Here's an article about it.... NOTE that Novell/SuSE seems to be leading the pack on getting rid of non-gpl stuff.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Kernel developers have kept proprietary drivers at arms' length, adding a feature years ago that could be used to block proprietary modules from loading. And in February, Greg Kroah-Hartman, a kernel programmer who works for Suse Linux seller Novell, added a patch that will trigger such a blockage for the USB subsystem he maintains.

"The USB subsystem will not be allowing closed-source kernel drivers to register with it" after February 2008, according to a note with his patch, posted online. Those with proprietary functions can move them above the kernel level, he argued. But his position against proprietary modules has sparked concerns about blocking use of some ISDN networking gear. Isn't this the same attitude that is supposed to be driving so many corporations and government departments away from Microsoft? Will they be making the transition back, once they start discovering that so much of their shiny new and expensive hardware isn't/won't be/cannot be supported, because the manufacturers won't play along with the kernel developers' little mindgames?

What's next on the chopping list of proprietary modules? ATI and nVidia? Bye-bye ndiswrapper, perhaps? I know I won't be holding my breath waiting for BluRay support to show up in the Linux kernel. If we are going to be forced to use only hardware that is on some Linus-approved list, I do hope that Linus will spend a reasonable amount of time to make sure the list is a) kept current, and b) made widely available. Otherwise, we might as well pack it in, and run out to buy XP. -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com

Darryl Gregorash wrote:

<snip>

...

What's next on the chopping list of proprietary modules? ATI and nVidia? Bye-bye ndiswrapper, perhaps? I know I won't be holding my breath waiting for BluRay support to show up in the Linux kernel. If we are going to be forced to use only hardware that is on some Linus-approved list, I do hope that Linus will spend a reasonable amount of time to make sure the list is a) kept current, and b) made widely available. Otherwise, we might as well pack it in, and run out to buy XP.

Darryl,

why in the world one would like to put in the kernel foreign code. Because that is where device drivers belong? Otherwise, I would like you to tell me just what user space I should use to load the driver for this nice shiny new WiFi card that comes only with a proprietary device driver. Will every user that logs in need to load his own driver to use

On 01/06/06 00:38, Rajko M wrote: the card (I'd love to see how that would work), or will just one suffice?

That is how any modern OS deals with device drivers (including XP).

The only reason XP does it is because that is the way DOS did it. Oh, yes, I am old enough to remember the BSOD -- I am old enough to remember when the IBM 360 was shiny and new.

The only thing that happens by trowing binary drivers out of kernel is that responsibility for writing and debugging drivers is back to vendors. Scream that they have no resources for that might be real, but than it is up to them to open the code or technical data and let people help them.

It has always been the responsibility of the vendor to develop and debug his device drivers, if they are going to be distributed as proprietary binaries. Do you seriously expect me to believe that vendors routinely turn all their code and technical specs over to Microsoft, to let them do what they will? Yeah, right. I believe in the easter bunny, too. The most they will ever turn over is the device i/o map, to permit MS to write its own driver. Any vendor serious about supporting Linux will likewise make sure his distributed device drivers are properly debugged. But if no one can use his drivers anyway, then any vendor is just going to walk away from Linux support, if his only option is to make all his intellectual property rights meaningless. No, this is not a technical issue, it is a childish mind-game that can only result in Linux users have less choice, not more. -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com

Darryl Gregorash wrote:

...

Darryl Gregorash wrote:

<snip>

...

What's next on the chopping list of proprietary modules? ATI and nVidia? Bye-bye ndiswrapper, perhaps? I know I won't be holding my breath waiting for BluRay support to show up in the Linux kernel. If we are going to be forced to use only hardware that is on some Linus-approved list, I do hope that Linus will spend a reasonable amount of time to make sure the list is a) kept current, and b) made widely available. Otherwise, we might as well pack it in, and run out to buy XP.

Darryl,

why in the world one would like to put in the kernel foreign code. Because that is where device drivers belong? Otherwise, I would like you to tell me just what user space I should use to load the driver for this nice shiny new WiFi card that comes only with a proprietary device driver. Will every user that logs in need to load his own driver to use

On 01/06/06 00:38, Rajko M wrote: the card (I'd love to see how that would work), or will just one suffice?

Are you serious? By definition operating system structure is divided in few subsystems. Kernel and user space is used to describe division in functions for 2 of those subsystems, not who and when is starting program. BTW, all startup scripts and programs including init, that are running for all users, are in user space. Details: http://plg.uwaterloo.ca/~itbowman/CS746G/a1/ http://wiki.cs.uiuc.edu/cs427/Architecture+of+Linux If kernel provide would raw interface for your (any) WiFi card than user space program can be used to control the card. Graphic subsystem, X server, is most prominent user space driver. USB subsystem is another.

...

That is how any modern OS deals with device drivers (including XP). The only reason XP does it is because that is the way DOS did it.

Popular myth: "They didn't develop anything after DOS" Well, they did.

...

The only thing that happens by trowing binary drivers out of kernel is that responsibility for writing and debugging drivers is back to vendors. Scream that they have no resources for that might be real, but than it is up to them to open the code or technical data and let people help them.

It has always been the responsibility of the vendor to develop and debug his device drivers, if they are going to be distributed as proprietary binaries. Do you seriously expect me to believe that vendors routinely turn all their code and technical specs over to Microsoft, to let them do what they will?

Good morning. Do you think that MS certifies hardware device drivers only because vendor promised that driver works as expected?

Yeah, right. I believe in the easter bunny, too. The most they will ever turn over is the device i/o map, to permit MS to write its own driver.

See above.

Any vendor serious about supporting Linux will likewise make sure his distributed device drivers are properly debugged.

Yes. And all software is bug free. Now you believe in Easter bunnies.

But if no one can use his drivers anyway, then any vendor is just going to walk away from Linux support, if his only option is to make all his intellectual property rights meaningless.

Intellectual property has meaning only as source of income, direct or indirect. Protection of IP that prevents hardware sale doesn't sound reasonable. Where will come money from to cover for investment in research and development (intellectual property)?

No, this is not a technical issue, it is a childish mind-game that can only result in Linux users have less choice, not more.

You are right. It is not a technical issue, alone. It has a lot to do with legal mine field that miscellaneous software license agreements present for open source developers. They don't want to be held liable for some accidental breach of agreement, and they don't want to have law experts team as part of kernel development team. -- Regards, Rajko. -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com

Peter Nikolic wrote:

On Friday 02 June 2006 05:21, Rajko M wrote:

...

Popular myth: "They didn't develop anything after DOS" Well, they did.

they did not even develope DOS theft comes to mind ..

IIRC, they bought it from Seattle Computer Products, *AFTER* they sold it to IBM. Even back then MS was showing it's lack of business ethics. Also, Q-DOS, which eventually became MS-DOS & PC-DOS was originally inteded as a development system for SCP, while they waited for CP/M-86 to be released. Since it wasn't originally intended as a commercial OS, it had a lot of deficiencies, which carried over into MS-DOS and PC-DOS. -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com

Bruce Marshall wrote:

On Thursday 01 June 2006 02:38, Rajko M wrote:

...

If driver is bad and part of the kernel than it will crash whole system (are you old enough to remember BSOD times). To make use of such driver someone has to debug it. Do you think that any of hardware vendors will ever try to ask MS to debug device drivers without giving technical specs and source code?

Uhhh your point is valid however..... in 10.1, in trying to use the radeon driver built by the kernel developers (I would assume since it was distributed with 10.1), the driver hung my entire system everytime it switched into graphics.

So why am I better off using all non-foreign code??

Code is code.... and it works or it doesn't. Gee, maybe we need a "Linux Certified" sticker to put on any non-gpl code and then we can use it. :-)

Hi Bruce, I can't say that open source, including device drivers, is better just because it is open source. I want as anybody else working code/binaries. There are two groups of problems with proprietary device drivers: 1) Technical: Who can maintain/debug program with hundreds of variables that control complex devices without knowing a lot about hardware and having source code for device driver. 2) Legal: - Who can unscramble license agreements that come with non-open part of the code. One can easily agree to something that will prevent him from further participation in open source projects, or hire lawyer to check the contract. For kernel developers there was one way out of this maze and they used it. Insisting on GPL is not matter of some irrational purity, it is the way avoid legal problems. Vendors can write drivers that will run in user space like X server. Why is good to have drivers in user space is explained here: http://lwn.net/Articles/66829/ One possible solution for vendors showed Conexant (modems). Making agreement with Linuxant they have Linux driver that is self financing operation. -- Regards, Rajko. -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com

On 6/1/06, Rajko M wrote: <snip>

Vendors can write drivers that will run in user space like X server. Why is good to have drivers in user space is explained here: http://lwn.net/Articles/66829/

The key, I think from the article linked above, is: "Getting a user-space driver patch into the kernel could be an interesting challenge. Many kernel hackers, certainly, resist changes that look like they are pushing Linux toward something that looks like a microkernel architecture - or which might legitimize binary-only drivers. On the other hand, some drivers bring a great deal of baggage into the kernel with them which might be better kept in user space; think of some of the code required by some sound drivers or the modulation software needed by "linmodem" drivers. The ability to run these drivers in user space could be a nice thing to have." The question becomes, where is the leadership on how "linux" is going to handle this? The "community" needs to resolve the issue in such a way that the bulk of "kernel hackers" can feel comfortable AND we "users" can have easy access to a stable of stable device drivers that keep pace with developments in new hardware. A distro that wants to lead, needs to define the solution to this problem, lead an open discussion about the proposed solution, and then be able to present a compelling enough case that sufficient quantities of device makers AND kernel hackers take up the solution. Perhaps this is what Novell is attempting to do with the device driver initiative that they announced. If so ... very good. But, in the mean time, they have failed to articulate the larger strategy, such that "we" know WHY they are pulling proprietary code, and HOW they plan to make it better down the road. Additionally, if they are going to pull proprietary code for well-used devices, then they SHOULD go out of their way to publish "how to's" that make the "in the meantime" tasks as easy as possible for the largest numbers of people. It only makes sense ... and that is leadership. So, at this point, it appears to me that Novell has shown 1/3 of the effort of leadership : 1)putting out a process that could pave the road for easier development, but have failed the other 2/3: 2)making a convincing case to the "kernel hackers" and other distros and hardware makers -- basically they have not created the public aliances that are required, and 3)they have failed to communicate effectively to the broader market (us) regarding the direction and have failed to "make it easy" to suffer the transition Peter -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com

On 6/1/06, Rajko M wrote:

Hi Peter,

Novel is walking in the new land of business with open source and they are learning. For this business model, there is no school to learn first, in quiet academic environment, and then to apply the knowledge, there is no even previous project of this magnitude to analyze and avoid errors, so there will be some.

The new device driver initiative is probably the most promising recent development: http://biz.yahoo.com/prnews/060517/sfw026.html?.v=53 http://developer.novell.com/wiki/index.php/Category:Partner_Linux_Driver_Pro... So some alliances will be formed.

yes, that is the 1/3 of leadership I meant. But, the other 2 parts are important, also. Particularly since "the community" needs to adopt the new proposed process as well as do the driver manufactureres and the kernel hackers. Let us hope the effort succeeds. P -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com