Re: Linux stifles innovation...
On Fri, 23 Feb 2001, David Weinehall wrote:
> On Fri, Feb 23, 2001 at 07:14:48AM -0500, Wakko Warner wrote:
> > > - Some architectures' ports of the Linux kernel, at least in their current
> > > state (has anyone actually tried to *compile* the PPC kernel since
> > > 2.4. besides me?)
> >
> > Have you tried comiling 2.2.x where x > 13 on an m68k mac or 2.4.x on an
> > m68k mac? doesn't happen. The patches I found for 2.2 didn't work, kernel
> > oopsed on loading the network driver.
>
> Have you submitted patches to Alan (for v2.2.x) or Linus (for v2.4.x)
> to fix this?!
Linux/m68k 2.4.x runs on some platforms. Also note that Linux/m68k is not 100%
merged with Linus/Alan yet. The mac-specific patches in the m68k tree that
weren't merged are on hold until all issues are sorted out[*], cfr. the
linux-m68k list.
Note to Wakko: feel free to join the project! As usual, we can use the
manpower!!
Gr{oetje,eeting}s,
Geert
[*] This includes, but is not limited to:
- reports that they work
- reports that they work after applying patch foo
- drivers shared with the PPC folks must be sorted out with them first
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Fri, 23 Feb 2001, David Weinehall wrote:
On Fri, Feb 23, 2001 at 07:14:48AM -0500, Wakko Warner wrote:
- Some architectures' ports of the Linux kernel, at least in their current
state (has anyone actually tried to *compile* the PPC kernel since
2.4.whatever besides me?)
Have you tried comiling 2.2.x where x 13 on an m68k mac or 2.4.x on an
m68k mac? doesn't happen. The patches I found for 2.2 didn't work, kernel
oopsed on loading the network driver.
Have you submitted patches to Alan (for v2.2.x) or Linus (for v2.4.x)
to fix this?!
Linux/m68k 2.4.x runs on some platforms. Also note that Linux/m68k is not 100%
merged with Linus/Alan yet. The mac-specific patches in the m68k tree that
weren't merged are on hold until all issues are sorted out[*], cfr. the
linux-m68k list.
Note to Wakko: feel free to join the project! As usual, we can use the
manpower!!
Gr{oetje,eeting}s,
Geert
[*] This includes, but is not limited to:
- reports that they work
- reports that they work after applying patch foo
- drivers shared with the PPC folks must be sorted out with them first
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
> Why would anyone want to "discuss" paying intel when the license allows you > to distribute it for nothing? Its clearly designed as an alternative to GPL > for commercial vendors. Because if you bother to talk to Intel about your problems Im sure they will give you a quote to work on it - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
At 03:47 PM 02/17/2001, Alan Cox wrote: > > both lock up under load. You dont run a busy ISP i guess. The fact that > > they come out with a new release every few minutes is clear evidence that > > it is problematic. > >I've been technical director of an ISP. I help manage sites that have not >insignificant loads and no eepro100 driver problems. For that matter there >are porn sites using eepro100 drivers. > > > Intel doesnt sell the e100.o driver, so they couldnt give a rats ass if it > >Your information is wrong. But then it usually is. If you are large >corporation >and would care to talk to Intel they will be happy to discuss it further. I can lock both of them up in 10 seconds with a simple test. Why would anyone want to "discuss" paying intel when the license allows you to distribute it for nothing? Its clearly designed as an alternative to GPL for commercial vendors. There have been ongoing complaints and discussions over eepro100 problems on many of the lists that I know you monitor, so why are you in denial about it? >Of course the single biggest problem with the eepro100 is closedness, and >people >in Intel with attitudes like yours who refuse to release full documentation. LINUX has no formal documentation, so are you guilty of "closedness" also? (ie "where is the 2.4 device driver spec?"), You have source to the e100 driver (which handles initialization properly, unlike the eepro driver), so what more documentation do you need? it seems that intel is being as "open" as the LInux camp, actually more so. At least with the eepro you can get the docs under non-disclosure. Under LInux you have no chance unless someone feels like helping you. DB - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
At 03:47 PM 02/17/2001, Alan Cox wrote: both lock up under load. You dont run a busy ISP i guess. The fact that they come out with a new release every few minutes is clear evidence that it is problematic. I've been technical director of an ISP. I help manage sites that have not insignificant loads and no eepro100 driver problems. For that matter there are porn sites using eepro100 drivers. Intel doesnt sell the e100.o driver, so they couldnt give a rats ass if it Your information is wrong. But then it usually is. If you are large corporation and would care to talk to Intel they will be happy to discuss it further. I can lock both of them up in 10 seconds with a simple test. Why would anyone want to "discuss" paying intel when the license allows you to distribute it for nothing? Its clearly designed as an alternative to GPL for commercial vendors. There have been ongoing complaints and discussions over eepro100 problems on many of the lists that I know you monitor, so why are you in denial about it? Of course the single biggest problem with the eepro100 is closedness, and people in Intel with attitudes like yours who refuse to release full documentation. LINUX has no formal documentation, so are you guilty of "closedness" also? (ie "where is the 2.4 device driver spec?"), You have source to the e100 driver (which handles initialization properly, unlike the eepro driver), so what more documentation do you need? it seems that intel is being as "open" as the LInux camp, actually more so. At least with the eepro you can get the docs under non-disclosure. Under LInux you have no chance unless someone feels like helping you. DB - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
Why would anyone want to "discuss" paying intel when the license allows you to distribute it for nothing? Its clearly designed as an alternative to GPL for commercial vendors. Because if you bother to talk to Intel about your problems Im sure they will give you a quote to work on it - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Fri, Feb 23, 2001 at 07:14:48AM -0500, Wakko Warner wrote: > > - Some architectures' ports of the Linux kernel, at least in their current > > state (has anyone actually tried to *compile* the PPC kernel since > > 2.4. besides me?) > > Have you tried comiling 2.2.x where x > 13 on an m68k mac or 2.4.x on an > m68k mac? doesn't happen. The patches I found for 2.2 didn't work, kernel > oopsed on loading the network driver. Have you submitted patches to Alan (for v2.2.x) or Linus (for v2.4.x) to fix this?! /David _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
> - Some architectures' ports of the Linux kernel, at least in their current > state (has anyone actually tried to *compile* the PPC kernel since > 2.4. besides me?) Have you tried comiling 2.2.x where x > 13 on an m68k mac or 2.4.x on an m68k mac? doesn't happen. The patches I found for 2.2 didn't work, kernel oopsed on loading the network driver. -- Lab tests show that use of micro$oft causes cancer in lab animals - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
- Some architectures' ports of the Linux kernel, at least in their current state (has anyone actually tried to *compile* the PPC kernel since 2.4.whatever besides me?) Have you tried comiling 2.2.x where x 13 on an m68k mac or 2.4.x on an m68k mac? doesn't happen. The patches I found for 2.2 didn't work, kernel oopsed on loading the network driver. -- Lab tests show that use of micro$oft causes cancer in lab animals - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Fri, Feb 23, 2001 at 07:14:48AM -0500, Wakko Warner wrote: - Some architectures' ports of the Linux kernel, at least in their current state (has anyone actually tried to *compile* the PPC kernel since 2.4.whatever besides me?) Have you tried comiling 2.2.x where x 13 on an m68k mac or 2.4.x on an m68k mac? doesn't happen. The patches I found for 2.2 didn't work, kernel oopsed on loading the network driver. Have you submitted patches to Alan (for v2.2.x) or Linus (for v2.4.x) to fix this?! /David _ _ // David Weinehall [EMAIL PROTECTED] / Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \ http://www.acc.umu.se/~tao// Full colour fire / - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Linux stifles innovation...
On Wed, 21 Feb 2001, Leif Sawyer wrote: > > From: Dr. Kelsey Hudson [mailto:[EMAIL PROTECTED]] > > > > 'good' in this case was meant to mean working properly, well-coded, > > does-what-it's-suppossed-to-do, eg not broken in one way or > > another. English should have a better word that 'good...' > > > > Functional, perfect, clean, documented, readable, understandable, > tight, tuned, grok-able. exactly what i meant, with the exception possibly of 'grok-able' as i'm not familiar with that term. > Don't use one word to mean multiple things if you're trying to make > a clear case. Otherwise you sound like a Micro$oft lawyer. :-) How dare you compare me to that scum-of-the-earth! :) I do agree, though... I should have been more clear. > Really, this thread should just DIE already. It should! > We now return you to your regularly scheduled kernel bashing. Let the flames begin. :) Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
> - Some architectures' ports of the Linux kernel, at least in their current > state (has anyone actually tried to *compile* the PPC kernel since > 2.4. besides me?) Yes it compiles beautifully. Just remember to get it from the ppc tree because its not merged yet - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Thu, 22 Feb 2001, Augustin Vidovic wrote: > On Wed, Feb 21, 2001 at 03:00:26PM -0800, Dr. Kelsey Hudson wrote: > > By saying this, you are implying that all pieces of code released under > > the GPL are 'good' pieces of code. > > If you want to rephrase it like that, ok, but then you must not forget > why these pieces of code are 'good' : because everybody have access to the > source code and may debug or improve it as needed. 'good' in this case was meant to mean working properly, well-coded, does-what-it's-suppossed-to-do, eg not broken in one way or another. English should have a better word that 'good...' Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
At 11:00 pm + 21/2/2001, Dr. Kelsey Hudson wrote: >On Sat, 17 Feb 2001, Augustin Vidovic wrote: > >> 1- GPL code is the opposite of crap > >By saying this, you are implying that all pieces of code released under >the GPL are 'good' pieces of code. I can give you several examples of code >where this is not the case; several I have written for my own use, as a >matter of fact. > >Software is only as 'good' as the effort the programmer who wrote it put >into it. Spend an hour writing a device driver while watching TV, eating >food, and after a couple dozen beers, and release it under the GPL. Is it >good code? probably not. :p > >This isn't, however, to say that I think commercial code is better than >GPL code... They both have their merits and deficiencies, so I value both >equally based upon this (although all software *should* be free...) I was going to stay out of this after a few days back, but I'll put in one last point in favour of this: I have seen good commercial software and extremely bad GPL software. Here are some examples: Good commercialware: - CorelXARA, by Computer Concepts, which totally blew CorelDRAW out of the water on release (but then Corel failed to market it and instead nabbed all the good ideas, tsk tsk) - the assembler/programmer/emulator for my Motorola 68HC08 microcontroller Both of these were developed by relatively small companies which don't have to kowtow to shareholders every 5 minutes. Terrible GPLware: - VNC Server for Macintosh, AT version 3.3.2 (I tried to debug this and eventually gave up and rewrote it from scratch) - Some architectures' ports of the Linux kernel, at least in their current state (has anyone actually tried to *compile* the PPC kernel since 2.4. besides me?) In the former case, I was able to take the few useful pieces of code and re-use them in the replacement - which I was *paid* to write, but is still GPL'ed in the spirit of the VNC project. In the latter case, people can see and experience the problem, and get on with fixing it as and when they need to and/or get time to. This is somewhat different in nature to, say, WinNT which dumped the Alpha platform overnight... I'll shut up now, especially as this isn't exactly the right place for this discussion... -- from: Jonathan "Chromatix" Morton mail: [EMAIL PROTECTED] (not for attachments) big-mail: [EMAIL PROTECTED] uni-mail: [EMAIL PROTECTED] The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -BEGIN GEEK CODE BLOCK- Version 3.12 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+ -END GEEK CODE BLOCK- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Linux stifles innovation...
On Sat, 17 Feb 2001, Torrey Hoffman wrote: > On the other hand, they make excellent mice. The mouse wheel and > the new optical mice are truly innovative and Microsoft should be > commended for them. The idea of an optical mouse is nothing new: I've got an optical mouse sitting to the side of my keyboard as we speak, dated ::turns mouse over:: 1987. Produced for Sun Microsystems by Mouse Systems. Microsoft being innovative? Hell no... They stole that idea from someone else, as they have for decades (and will undoubtedly continue to do). It also wouldn't surprise me if MS is mimicing someone else's idea with the wheel... I can remember purchasing a Logitech mouse with that wheel long before I had seen a Micros~1 equivalent. Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Linux stifles innovation...
> From: Dr. Kelsey Hudson [mailto:[EMAIL PROTECTED]] > > 'good' in this case was meant to mean working properly, well-coded, > does-what-it's-suppossed-to-do, eg not broken in one way or > another. English should have a better word that 'good...' > Functional, perfect, clean, documented, readable, understandable, tight, tuned, grok-able. Don't use one word to mean multiple things if you're trying to make a clear case. Otherwise you sound like a Micro$oft lawyer. :-) Really, this thread should just DIE already. We now return you to your regularly scheduled kernel bashing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Sat, 17 Feb 2001, Alan Olsen wrote: > "You keep using that word. i don't think it means what you think it > means." ...To quote Indigo Montoya, speaking to Vuzinni, from "The Princess Bride" :) One hell of a story :) Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Sat, 17 Feb 2001, Augustin Vidovic wrote: > 1- GPL code is the opposite of crap By saying this, you are implying that all pieces of code released under the GPL are 'good' pieces of code. I can give you several examples of code where this is not the case; several I have written for my own use, as a matter of fact. Software is only as 'good' as the effort the programmer who wrote it put into it. Spend an hour writing a device driver while watching TV, eating food, and after a couple dozen beers, and release it under the GPL. Is it good code? probably not. :p This isn't, however, to say that I think commercial code is better than GPL code... They both have their merits and deficiencies, so I value both equally based upon this (although all software *should* be free...) Just my .02. Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Wed, Feb 21, 2001 at 03:00:26PM -0800, Dr. Kelsey Hudson wrote: > On Sat, 17 Feb 2001, Augustin Vidovic wrote: > > > 1- GPL code is the opposite of crap > > By saying this, you are implying that all pieces of code released under > the GPL are 'good' pieces of code. If you want to rephrase it like that, ok, but then you must not forget why these pieces of code are 'good' : because everybody have access to the source code and may debug or improve it as needed. To the contrary, the commercially distributed closed software may be nicely coded (sometimes), but how can you know ? You don't have acess to the source code. All you can do if you want to modify it is to disassemble it. In some countries this solution is even illegal. That's why a GPLed piece of code, whatever ugly it may look, is far better, because you have the _liberty_ to modify it. That's the exact contrary of crap, because there is no reason to throw it into the trashcan. A GPLed code has the potential of living as long asd there exists a need to ru it. A closed code can live only on one architecture, and thus is doomed to the dumpster. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Wed, Feb 21, 2001 at 03:00:26PM -0800, Dr. Kelsey Hudson wrote: On Sat, 17 Feb 2001, Augustin Vidovic wrote: 1- GPL code is the opposite of crap By saying this, you are implying that all pieces of code released under the GPL are 'good' pieces of code. If you want to rephrase it like that, ok, but then you must not forget why these pieces of code are 'good' : because everybody have access to the source code and may debug or improve it as needed. To the contrary, the commercially distributed closed software may be nicely coded (sometimes), but how can you know ? You don't have acess to the source code. All you can do if you want to modify it is to disassemble it. In some countries this solution is even illegal. That's why a GPLed piece of code, whatever ugly it may look, is far better, because you have the _liberty_ to modify it. That's the exact contrary of crap, because there is no reason to throw it into the trashcan. A GPLed code has the potential of living as long asd there exists a need to ru it. A closed code can live only on one architecture, and thus is doomed to the dumpster. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Sat, 17 Feb 2001, Augustin Vidovic wrote: 1- GPL code is the opposite of crap By saying this, you are implying that all pieces of code released under the GPL are 'good' pieces of code. I can give you several examples of code where this is not the case; several I have written for my own use, as a matter of fact. Software is only as 'good' as the effort the programmer who wrote it put into it. Spend an hour writing a device driver while watching TV, eating food, and after a couple dozen beers, and release it under the GPL. Is it good code? probably not. :p This isn't, however, to say that I think commercial code is better than GPL code... They both have their merits and deficiencies, so I value both equally based upon this (although all software *should* be free...) Just my .02. Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Sat, 17 Feb 2001, Alan Olsen wrote: "You keep using that word. i don't think it means what you think it means." ...To quote Indigo Montoya, speaking to Vuzinni, from "The Princess Bride" :) One hell of a story :) Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Linux stifles innovation...
From: Dr. Kelsey Hudson [mailto:[EMAIL PROTECTED]] 'good' in this case was meant to mean working properly, well-coded, does-what-it's-suppossed-to-do, eg not broken in one way or another. English should have a better word that 'good...' Functional, perfect, clean, documented, readable, understandable, tight, tuned, grok-able. Don't use one word to mean multiple things if you're trying to make a clear case. Otherwise you sound like a Micro$oft lawyer. :-) Really, this thread should just DIE already. We now return you to your regularly scheduled kernel bashing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Linux stifles innovation...
On Sat, 17 Feb 2001, Torrey Hoffman wrote: On the other hand, they make excellent mice. The mouse wheel and the new optical mice are truly innovative and Microsoft should be commended for them. The idea of an optical mouse is nothing new: I've got an optical mouse sitting to the side of my keyboard as we speak, dated ::turns mouse over:: 1987. Produced for Sun Microsystems by Mouse Systems. Microsoft being innovative? Hell no... They stole that idea from someone else, as they have for decades (and will undoubtedly continue to do). It also wouldn't surprise me if MS is mimicing someone else's idea with the wheel... I can remember purchasing a Logitech mouse with that wheel long before I had seen a Micros~1 equivalent. Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Thu, 22 Feb 2001, Augustin Vidovic wrote: On Wed, Feb 21, 2001 at 03:00:26PM -0800, Dr. Kelsey Hudson wrote: By saying this, you are implying that all pieces of code released under the GPL are 'good' pieces of code. If you want to rephrase it like that, ok, but then you must not forget why these pieces of code are 'good' : because everybody have access to the source code and may debug or improve it as needed. 'good' in this case was meant to mean working properly, well-coded, does-what-it's-suppossed-to-do, eg not broken in one way or another. English should have a better word that 'good...' Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
At 11:00 pm + 21/2/2001, Dr. Kelsey Hudson wrote: On Sat, 17 Feb 2001, Augustin Vidovic wrote: 1- GPL code is the opposite of crap By saying this, you are implying that all pieces of code released under the GPL are 'good' pieces of code. I can give you several examples of code where this is not the case; several I have written for my own use, as a matter of fact. Software is only as 'good' as the effort the programmer who wrote it put into it. Spend an hour writing a device driver while watching TV, eating food, and after a couple dozen beers, and release it under the GPL. Is it good code? probably not. :p This isn't, however, to say that I think commercial code is better than GPL code... They both have their merits and deficiencies, so I value both equally based upon this (although all software *should* be free...) I was going to stay out of this after a few days back, but I'll put in one last point in favour of this: I have seen good commercial software and extremely bad GPL software. Here are some examples: Good commercialware: - CorelXARA, by Computer Concepts, which totally blew CorelDRAW out of the water on release (but then Corel failed to market it and instead nabbed all the good ideas, tsk tsk) - the assembler/programmer/emulator for my Motorola 68HC08 microcontroller Both of these were developed by relatively small companies which don't have to kowtow to shareholders every 5 minutes. Terrible GPLware: - VNC Server for Macintosh, ATT version 3.3.2 (I tried to debug this and eventually gave up and rewrote it from scratch) - Some architectures' ports of the Linux kernel, at least in their current state (has anyone actually tried to *compile* the PPC kernel since 2.4.whatever besides me?) In the former case, I was able to take the few useful pieces of code and re-use them in the replacement - which I was *paid* to write, but is still GPL'ed in the spirit of the VNC project. In the latter case, people can see and experience the problem, and get on with fixing it as and when they need to and/or get time to. This is somewhat different in nature to, say, WinNT which dumped the Alpha platform overnight... I'll shut up now, especially as this isn't exactly the right place for this discussion... -- from: Jonathan "Chromatix" Morton mail: [EMAIL PROTECTED] (not for attachments) big-mail: [EMAIL PROTECTED] uni-mail: [EMAIL PROTECTED] The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -BEGIN GEEK CODE BLOCK- Version 3.12 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+ -END GEEK CODE BLOCK- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
- Some architectures' ports of the Linux kernel, at least in their current state (has anyone actually tried to *compile* the PPC kernel since 2.4.whatever besides me?) Yes it compiles beautifully. Just remember to get it from the ppc tree because its not merged yet - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Linux stifles innovation...
On Wed, 21 Feb 2001, Leif Sawyer wrote: From: Dr. Kelsey Hudson [mailto:[EMAIL PROTECTED]] 'good' in this case was meant to mean working properly, well-coded, does-what-it's-suppossed-to-do, eg not broken in one way or another. English should have a better word that 'good...' Functional, perfect, clean, documented, readable, understandable, tight, tuned, grok-able. exactly what i meant, with the exception possibly of 'grok-able' as i'm not familiar with that term. Don't use one word to mean multiple things if you're trying to make a clear case. Otherwise you sound like a Micro$oft lawyer. :-) How dare you compare me to that scum-of-the-earth! :) I do agree, though... I should have been more clear. Really, this thread should just DIE already. It should! We now return you to your regularly scheduled kernel bashing. Let the flames begin. :) Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
> "Jeff" == Jeff Garzik <[EMAIL PROTECTED]> writes: Jeff> FWIW, -every single- Windows driver source code I've seen Jeff> has been bloody awful. Asking them to release that code Jeff> would probably result in embarrassment. Same reasoning why Jeff> many companies won't release hardware specifications... The Jeff> internal docs are bad. Really bad. Speaking as a user, I would much prefer to use an open source driver that is "bloody awful" rather then a closed source driver that still might be "bloody awful", unless I am confident that the vendor will support me if I encounter a bug. (IMHO "bloody awful" means "awfully buggy"). In the past, I have had a case where my AGFA scanner stopped working, as the software kept coming up with illegal operation errors. Technical support were not the least bit interested in helping (no one else has reported having the same problem), but instead blamed the problem on my computer (try reinstalling it again, maybe this time it will work?) Or: bring the scanner in, and if the same problem occurs on our computer, we will fix it, otherwise we will have to charge you for testing it. At one stage I tricked the consultant into copying down the CPU register information, but I got the strong impression that they weren't interested in diagnosing the bug (they probably didn't have the programmers anymore). I ended up having to reinstall the entire MS-operating system on the computer so it would work again. However, my feeling is that if I knew what the problem was, it would have been easy to work around, eg. by editing the appropriate entry in the system registry. I couldn't do determine this myself though, without access to the source code. (the scanner in question died about 1 month after warranty expired, with very little use, so I went and purchased a HP scanner instead.) -- Brian May <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
"Jeff" == Jeff Garzik [EMAIL PROTECTED] writes: Jeff FWIW, -every single- Windows driver source code I've seen Jeff has been bloody awful. Asking them to release that code Jeff would probably result in embarrassment. Same reasoning why Jeff many companies won't release hardware specifications... The Jeff internal docs are bad. Really bad. Speaking as a user, I would much prefer to use an open source driver that is "bloody awful" rather then a closed source driver that still might be "bloody awful", unless I am confident that the vendor will support me if I encounter a bug. (IMHO "bloody awful" means "awfully buggy"). In the past, I have had a case where my AGFA scanner stopped working, as the software kept coming up with illegal operation errors. Technical support were not the least bit interested in helping (no one else has reported having the same problem), but instead blamed the problem on my computer (try reinstalling it again, maybe this time it will work?) Or: bring the scanner in, and if the same problem occurs on our computer, we will fix it, otherwise we will have to charge you for testing it. At one stage I tricked the consultant into copying down the CPU register information, but I got the strong impression that they weren't interested in diagnosing the bug (they probably didn't have the programmers anymore). I ended up having to reinstall the entire MS-operating system on the computer so it would work again. However, my feeling is that if I knew what the problem was, it would have been easy to work around, eg. by editing the appropriate entry in the system registry. I couldn't do determine this myself though, without access to the source code. (the scanner in question died about 1 month after warranty expired, with very little use, so I went and purchased a HP scanner instead.) -- Brian May [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The lack of specification (was Re: [LONG RANT] Re: Linux stifles innovation... )
Mikulas Patocka <[EMAIL PROTECTED]> writes: > Imagine that there is specification of mark_buffer_dirty. That > specification says that > 1. it may not block > 2. it may block > > In case 1. implementators wouldn't change it to block in stable kernel > relese because they don't want to violate the specification. > > In case 2. implementators of ext2 wouldn't assume that it doesn't block > even if it doesn't in current implementation. Whenever the question has been asked the answer is always assume anything in the kernel outside of the current function blocks. > In both cases, the bug wouldn't be created. Nope. It looks like someone made a mistake in ext2... > > Anytime you change implementation of syscalls, you gotta check all > applications that use them ;-) Luckily not - because there is > specification and you can check that syscalls conform to the > specification, not apps. Not normally. The rule is that syscall don't change period. The internal kernel interface is different. It is allowed to change. As for syscall changing auditing most apps did happen when the LFS spec was put together. So you would have an implementation that would keep most apps from failing on large files. > > > Saying "code is the specification" is not good. > > > > I'm not arguing against documentation. That is dumb. But the code is > > ALWAYS canonical. Not docs. > > Let's see: > Who is right? If there is no specification Hmm. The developers should get together and pow wow when the problem is noticed. When it is finally talked out about how it should happen then the code should get fixed accordingly. It isn't about right and wrong it is about working code. Not that documenting things doesn't help. And 2.4 is going in that direction... Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
On Mon, 19 Feb 2001 10:58:36 -0500 (EST), "Richard B. Johnson" <[EMAIL PROTECTED]> wrote: >I was unable to use the new kernel because the drivers I need for >`initrd` all had undefined symbols relating to some high memory stuff. >This, in spite of the fact that I did: > >cp .config .. >make clean >make distclean >cp ../.config >make oldconfig >make dep >make bzImage >make modules >make modules_install FAQ: http://www.tux.org/lkml/#s8-8 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The lack of specification (was Re: [LONG RANT] Re: Linux stifles innovation... )
> One of these things must happen: > > a. follow the specification, even if that makes code slow and contorted > b. change the specification > c. ignore the specification > d. get rid of the specification > > Option "a" will not be accepted around here. Sorry. It should be followed in stable releases. (and usually is - except for few cases - and except that there is no specification, just unwritten rules). > The best you can > hope for is option "b". Since that is hard work (want to help?) we > often end up not using a specification... hopefully by just not > having one, instead of by ignoring one. > > Now implementators of TCP will say: that driver is buggy. Everybody should > > set state=TASK_RUNNING before calling schedule to yield the process. > > > > Implementators of driver will say: TCP is buggy - no one should call my > > driver in TASK_[UN]INTERRUPTIBLE state. > > > > Who is right? If there is no specification > > The driver is buggy, unless the TCP maintainer can be convinced > that TCP is buggy. TCP is a big chunk of code that most people use, > while the driver is not so huge or critical. > > The TCP maintainers do not seem to be sadistic bastards hell-bent on > breaking your drivers. API changes usually have a good reason. Why should block device developers read TCP/IP code? And only after reading significant amount of it they realize that they can be called in TASK_INTERRUPTIBLE state. They will most likely read other block drivers, find using schedule without setting state and use it also that way. The only way to tell developers to always set state before using schedule is to write it to specification. Mikulas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The lack of specification (was Re: [LONG RANT] Re: Linux stifles innovation... )
Mikulas Patocka writes: > Imagine that there is specification of mark_buffer_dirty. That > specification says that > 1. it may not block > 2. it may block > > In case 1. implementators wouldn't change it to block in stable kernel > relese because they don't want to violate the specification. One of these things must happen: a. follow the specification, even if that makes code slow and contorted b. change the specification c. ignore the specification d. get rid of the specification Option "a" will not be accepted around here. Sorry. The best you can hope for is option "b". Since that is hard work (want to help?) we often end up not using a specification... hopefully by just not having one, instead of by ignoring one. Not saying it doesn't suck to have things undocumented, but at least you don't have to reverse-engineer a multi-megabyte binary kernel to find out what is going on. >> Anytime you change implementation, you gotta check all drivers that use >> them. I know, I'm one of the grunts that does such reviews and changes. > > Anytime you change implementation of syscalls, you gotta check all > applications that use them ;-) Luckily not - because there is > specification and you can check that syscalls conform to the > specification, not apps. Syscalls are more stable, but they may be changed after many years of a transition period. The C library hides some of this from users. > Now implementators of TCP will say: that driver is buggy. Everybody should > set state=TASK_RUNNING before calling schedule to yield the process. > > Implementators of driver will say: TCP is buggy - no one should call my > driver in TASK_[UN]INTERRUPTIBLE state. > > Who is right? If there is no specification The driver is buggy, unless the TCP maintainer can be convinced that TCP is buggy. TCP is a big chunk of code that most people use, while the driver is not so huge or critical. The TCP maintainers do not seem to be sadistic bastards hell-bent on breaking your drivers. API changes usually have a good reason. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
On Mon, 19 Feb 2001, Henning P . Schmiedehausen wrote:
> And yes, there _is_ IMHO a difference in telling someone on LKM,
> especially someone without deeper knowledge that is lookin for help:
>
> "You're using a non-open source driver, so we can't help you. Please
> ask your vendor for support."
Henning,
Lets be realistic here. If I take my BMW (M series) into the shop because
it has problem yet I tell the German Mechanic that he may not look under
the hood because there is a secret "wonder blunder" inside. Where do you
think that mechanic is going to tell you to go??
This is the motor(kernel-space) not the paint(user-space).
You have admitted that you are an "End-User"(of the kernel) and that you
generally write user-space packages. I have yet to understand why you are
going out of bounds. It is clear that you have read to many of my person
best flame-wars here on LKML where I know I must have earned :
"Arse of the Year, 2000 :: LKML"
> "Fuck off, Luser".
And you slammed me for being rude and ugly?? In my defense of code and
work that I publish, but heavily enforce the license and terms of use.
Since I am aware that about 96% of all linux boxes today use some form of
ATA/ATAPI, it is important that I recover all know fixes public/private
to help everyone.
> ("Der Ton macht die Musik". Sorry don't know the equal english
> expression).
I now see the joy in watching someone go nuts here on LKML.
Respectfully,
Andre Hedrick
Linux ATA Development
ps. Please keep up the entertainment, I am getting a good belly-laugh
of what I must have looked like in the past.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
The lack of specification (was Re: [LONG RANT] Re: Linux stifles innovation... )
> > > > I suspect part of the problem with commercial driver support on Linux is that > > > > the Linux driver API (such as it is) is relatively poorly documented > > > > > > In-kernel documentation, agreed. > > > > > > _Linux Device Drivers_ is a good reference for 2.2 and below. > > > > And do implementators of generic kernel functions and developers of device > > drivers respect it? And how can they respect it if it's a commercial book? > > _Linux Device Drivers_ documents the 2.2 (and previous) API, and > thus refutes the argument that the kernel API is poorly documented. > Since the publication of the book -succeeds- the publication of the > APIs, your questions are not applicable. What does it say about mark_buffer_dirty blocking or schedule and TASK_[UN]INTERRUPTIBLE issues? If it says nothing, it is bad documentation. If it says something, kernel developers do not respect it and it is useless documentation... > > > > and seems > > > > to change almost on a week-by-week basis anyway. I've done my share of chasing > > > > the current kernel revision with drivers that aren't part of the kernel tree: > > > > by the time you update the driver to work with the current kernel revision, > > > > there's a new one out, and the driver doesn't compile with it. > > > > > > This is entirely in your imagination. Driver APIs are stable across the > > > stable series of kernels: 2.0.0 through 2.0.38, 2.2.0 through 2.2.18, > > > 2.4.0 through whatever. > > > > No true. Do you remember for example the mark_buffer_dirty change in some > > 2.2.x that triggered ext2 directory corruption? (mark_buffer_dirty was > > changed so that it could block). > > > > Another example of bug that comes from the lack of specification is > > calling of get_free_pages by non-running processes that caused lockups on > > all kernels < 2.2.15. And it is still not cleaned up - see tcp_recvmsg(). > > > > Having documentation could prevent this kind of bugs. > > Hardly. Imagine that there is specification of mark_buffer_dirty. That specification says that 1. it may not block 2. it may block In case 1. implementators wouldn't change it to block in stable kernel relese because they don't want to violate the specification. In case 2. implementators of ext2 wouldn't assume that it doesn't block even if it doesn't in current implementation. In both cases, the bug wouldn't be created. > No documentation is often -better- than bad documentation. Of course. But good documentation is better than no documentation :-) > > You don't need too > > long texts, just a brief description: "this function may be called from > > process/bh/interrupt context, it may/may not block, it may/may not be > > called in TASK_[UN]INTERURPTIBLE state, it may take these locks." > > > > With documentation developers would be able to change implementation of > > kernel functions without the need to recheck all drivers that use them. > > Anytime you change implementation, you gotta check all drivers that use > them. I know, I'm one of the grunts that does such reviews and changes. Anytime you change implementation of syscalls, you gotta check all applications that use them ;-) Luckily not - because there is specification and you can check that syscalls conform to the specification, not apps. > > Saying "code is the specification" is not good. > > I'm not arguing against documentation. That is dumb. But the code is > ALWAYS canonical. Not docs. Let's see: There are parts of code (1) that set state to TASK_[UN]INTERRUPTIBLE and then call some other complex functions, like page fault handlers. (for example tcp in 2.2) There are parts of code (2) that call schedule to yield the process assuming that the state is TASK_RUNNING. (including some drivers) Sooner or later will happen, that subroutine called from part (1) get somehow to part (2) and the process locks up. Now implementators of TCP will say: that driver is buggy. Everybody should set state=TASK_RUNNING before calling schedule to yield the process. Implementators of driver will say: TCP is buggy - no one should call my driver in TASK_[UN]INTERRUPTIBLE state. Who is right? If there is no specification Mikulas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
> One of the latest module killers was the opaque type, "THIS_MODULE", > put at the beginning of struct file_operations. This happened between > 2.4.0 and 2.4.x. So it's not "imagination". No it happened before 2.4.0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
On Mon, 19 Feb 2001, Mikulas Patocka wrote: > > > I suspect part of the problem with commercial driver support on Linux is that > > > the Linux driver API (such as it is) is relatively poorly documented > > > > In-kernel documentation, agreed. > > > > _Linux Device Drivers_ is a good reference for 2.2 and below. > > And do implementators of generic kernel functions and developers of device > drivers respect it? And how can they respect it if it's a commercial book? _Linux Device Drivers_ documents the 2.2 (and previous) API, and thus refutes the argument that the kernel API is poorly documented. Since the publication of the book -succeeds- the publication of the APIs, your questions are not applicable. > > > and seems > > > to change almost on a week-by-week basis anyway. I've done my share of chasing > > > the current kernel revision with drivers that aren't part of the kernel tree: > > > by the time you update the driver to work with the current kernel revision, > > > there's a new one out, and the driver doesn't compile with it. > > > > This is entirely in your imagination. Driver APIs are stable across the > > stable series of kernels: 2.0.0 through 2.0.38, 2.2.0 through 2.2.18, > > 2.4.0 through whatever. > > No true. Do you remember for example the mark_buffer_dirty change in some > 2.2.x that triggered ext2 directory corruption? (mark_buffer_dirty was > changed so that it could block). > > Another example of bug that comes from the lack of specification is > calling of get_free_pages by non-running processes that caused lockups on > all kernels < 2.2.15. And it is still not cleaned up - see tcp_recvmsg(). > > Having documentation could prevent this kind of bugs. Hardly. No documentation is often -better- than bad documentation. > You don't need too > long texts, just a brief description: "this function may be called from > process/bh/interrupt context, it may/may not block, it may/may not be > called in TASK_[UN]INTERURPTIBLE state, it may take these locks." > > With documentation developers would be able to change implementation of > kernel functions without the need to recheck all drivers that use them. Anytime you change implementation, you gotta check all drivers that use them. I know, I'm one of the grunts that does such reviews and changes. > Saying "code is the specification" is not good. I'm not arguing against documentation. That is dumb. But the code is ALWAYS canonical. Not docs. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
On Mon, 19 Feb 2001, Richard B. Johnson wrote: > One of the latest module killers was the opaque type, "THIS_MODULE", > put at the beginning of struct file_operations. This happened between > 2.4.0 and 2.4.x. So it's not "imagination". Richard, Time to join the rest of us on planet Earth. That was added in 2.4.0-test2, and was most definitely in 2.4.0 release. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
> So, is it legal to put changes to a twin licensed driver in the Linux > kernel tree back into the same driver in the BSD tree? Just make it plain that patches and contributions to that driver must be dual licensed. We have several shared drivers with BSD and most people seem happy that small fixes to a dual or BSD licensed drivers should go back under the original license. In fact I'd say I'm not the only one who would find it impolite otherwise. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
On Mon, 19 Feb 2001, Henning P . Schmiedehausen wrote: > So, is it legal to put changes to a twin licensed driver in the Linux > kernel tree back into the same driver in the BSD tree? IANAL, but AIUI: if the changes are made the copyright holder then they may do whatever they want. (release the changes only under one licence, both, none, etc..) if small changes are made by a 3rd party (eg a patch) and submitted back to the copyright holder, then it is almost safe to presume that the copyright holder may incorporate those changes without ceding copyright in any way. (then see first point) if major changes are made by a 3rd party then (i think) 3rd party has copyright over their changes, and so, either: -copyright holder of the original work would need to comply with the licence of the derived work. (eg if GPL, then changes can't go back into the BSD version) or: - copyright holder of the original work would need express permission from the copyright holder of the derived work to use it under a different licence. but IANAL most obviously... :) > > Regards > Henning --paulj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
On Mon, 19 Feb 2001, Jeff Garzik wrote: > On Mon, 19 Feb 2001, David Howells wrote: > > I suspect part of the problem with commercial driver support on Linux is that > > the Linux driver API (such as it is) is relatively poorly documented > > In-kernel documentation, agreed. > > _Linux Device Drivers_ is a good reference for 2.2 and below. > > > and seems > > to change almost on a week-by-week basis anyway. I've done my share of chasing > > the current kernel revision with drivers that aren't part of the kernel tree: > > by the time you update the driver to work with the current kernel revision, > > there's a new one out, and the driver doesn't compile with it. > > This is entirely in your imagination. Driver APIs are stable across the > stable series of kernels: 2.0.0 through 2.0.38, 2.2.0 through 2.2.18, > 2.4.0 through whatever. > > Jeff > One of the latest module killers was the opaque type, "THIS_MODULE", put at the beginning of struct file_operations. This happened between 2.4.0 and 2.4.x. So it's not "imagination". It is well understood that there will be changes to the driver APIs, but some could be better thought out to accomplish what must be accomplished, but at the same time, minimize the code changes to existing drivers. While on the subject of compatibility, I just put 1 gb of memory in one of my machines at home this weekend, with 256 mb sticks now costing under $US 80, I figured it was about time. The machine would not boot with Linux 2.4.1 just Uncompressing then nothing. I had to remove one memory stick. I recompiled with "high memory" enabled, CONFIG_HIGHMEM4G. I was unable to use the new kernel because the drivers I need for `initrd` all had undefined symbols relating to some high memory stuff. This, in spite of the fact that I did: cp .config .. make clean make distclean cp ../.config make oldconfig make dep make bzImage make modules make modules_install I can't understand how changes in memory management could possibly affect drivers! They should not care where memory comes from! If a driver, calling kmalloc() or whatever, needs to know anything about where the pages made available were stashed, then something's broken, plain and simple. Also, with 4 gb of address space in ix86 machines, we should not have any problems accessing memory until the sum of all the RAM, plus the sum of all the address-space needed for PCI resources, plus anything below 1 megabyte, plus the physical memory required for PTEs and kernel resources, starts to get near 4 gb. Presently, the address limit without "highmem hacks" is less than 1 gb. This needs some work. It looks as though somebody guessed that 'PAGE_OFFSET' imposed some kind of limit. It doesn't as long as it's summed, not ORed (some early code I looked at ORed in PAGE_OFFSET in several places, destroying the linearity of address arithmetic). Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
> > I suspect part of the problem with commercial driver support on Linux is that > > the Linux driver API (such as it is) is relatively poorly documented > > In-kernel documentation, agreed. > > _Linux Device Drivers_ is a good reference for 2.2 and below. And do implementators of generic kernel functions and developers of device drivers respect it? And how can they respect it if it's a commercial book? > > and seems > > to change almost on a week-by-week basis anyway. I've done my share of chasing > > the current kernel revision with drivers that aren't part of the kernel tree: > > by the time you update the driver to work with the current kernel revision, > > there's a new one out, and the driver doesn't compile with it. > > This is entirely in your imagination. Driver APIs are stable across the > stable series of kernels: 2.0.0 through 2.0.38, 2.2.0 through 2.2.18, > 2.4.0 through whatever. No true. Do you remember for example the mark_buffer_dirty change in some 2.2.x that triggered ext2 directory corruption? (mark_buffer_dirty was changed so that it could block). Another example of bug that comes from the lack of specification is calling of get_free_pages by non-running processes that caused lockups on all kernels < 2.2.15. And it is still not cleaned up - see tcp_recvmsg(). Having documentation could prevent this kind of bugs. You don't need too long texts, just a brief description: "this function may be called from process/bh/interrupt context, it may/may not block, it may/may not be called in TASK_[UN]INTERURPTIBLE state, it may take these locks." With documentation developers would be able to change implementation of kernel functions without the need to recheck all drivers that use them. Saying "code is the specification" is not good. Mikulas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
On Mon, 19 Feb 2001, David Howells wrote: > I suspect part of the problem with commercial driver support on Linux is that > the Linux driver API (such as it is) is relatively poorly documented In-kernel documentation, agreed. _Linux Device Drivers_ is a good reference for 2.2 and below. > and seems > to change almost on a week-by-week basis anyway. I've done my share of chasing > the current kernel revision with drivers that aren't part of the kernel tree: > by the time you update the driver to work with the current kernel revision, > there's a new one out, and the driver doesn't compile with it. This is entirely in your imagination. Driver APIs are stable across the stable series of kernels: 2.0.0 through 2.0.38, 2.2.0 through 2.2.18, 2.4.0 through whatever. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
> "Jeff" == Jeff Garzik <[EMAIL PROTECTED]> writes: Jeff> On Mon, 19 Feb 2001, Werner Almesberger wrote: >> Now what's at stake ? Look at the Windows world. Also there, >> companies could release their drivers as Open Source. Quick, how >> many do this ? Almost none. So, given the choice, most companies >> have defaulted to closed source. Consistently complaining when a >> company tries to release only closed source drivers for Linux seems >> to generally have the desired effect of making them change their >> policy. Jeff> FWIW, -every single- Windows driver source code I've seen has Jeff> been bloody awful. Asking them to release that code would Jeff> probably result in embarrassment. Same reasoning why many Jeff> companies won't release hardware specifications... The internal Jeff> docs are bad. Really bad. Trust me, commercial UNIX drivers aren't any better. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
I suspect part of the problem with commercial driver support on Linux is that the Linux driver API (such as it is) is relatively poorly documented and seems to change almost on a week-by-week basis anyway. I've done my share of chasing the current kernel revision with drivers that aren't part of the kernel tree: by the time you update the driver to work with the current kernel revision, there's a new one out, and the driver doesn't compile with it. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
Henning P . Schmiedehausen wrote: > No, I don't. I don't at all. But I prefer a more pragmatic approach to > the developers and companies who don't. I actually think it's good if we appear to be a little more "hard-liners" than we really are. If companies assume that only open source will get them anywhere, they'll err on the safe side. In the end, this is likely to be to their own benefit: they won't waste time designing not-quite open models that fail in the end (and may generate a lot of bad blood), and can focus directly on options that make everybody happy. > And yes, there _is_ IMHO a difference in telling someone on LKM, > especially someone without deeper knowledge that is lookin for help: Yes, also rejection can be delivered in a civilized way. - Werner -- _ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
- Original Message - From: "David Lang" <[EMAIL PROTECTED]> To: "Nicholas Knight" <[EMAIL PROTECTED]> Cc: "Jeff Garzik" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, February 19, 2001 3:36 AM Subject: Re: [LONG RANT] Re: Linux stifles innovation... > before you go to far in condemming companies, note that even transmeta is > in this situation with their docs. when Linus was asked about > documentation for the longrun config stuff he stated that whil trasmeta > was planning to release both docs and source, they were not willing to > release them in the state that they are in currently. > Yes I did read what Linus said, and I did consider that when I wrote this, I still don't feel that it should stop them if they plan to release it and it might be quite some time before they have it in what they consider a releasable state (if a company wants to clean things up before releasing them, great, but if it's going to be a while, I'm saying that they should *consider* simply releasing them in a given state) > and to be perfectly honest, they do have a point, if the internal > documentation is so poor, releaseing it will cause a flood of calls for > clarification of the docs. it's better to spend the time before release to > fix it then to spend the time (a much larger chunk of time) after the > release explaining it multiple times AND fixing the docs. > > sometimes companies are not willing to spend that much time on what they > see as a minor market. that's just the fact of life. > > the real fix isn't to yell at the companies, it's to show them that it is > a significant market and worth them spending their money there. Please understand that I'm not really condemming anyone or anything, I saying that I did not see the point in keeping it all closed simply because the source/docs are a mess. I do understand that they may have reason for not wanting to release things in that state, but I'm not sure it should stop them if at all possible, as even messy, undocumented code, and bad spec sheets, is better than nothing at all. There's something else I was going to add in my original note but failed to. (warning, painfully obvious paragraph ahead) I belive that if companies would write drivers and specs from the beginning with the intention of releasing at least the specs if not the specs and source, then we'd probably wind up with better products as well as cleaner code and spec sheets. Prehaps it's time someone gave the companies a little nudging (possibly with a penguin beak? :). > > David Lang > -NK > > On Mon, 19 Feb > 2001, Nicholas Knight wrote: > > > Date: Mon, 19 Feb 2001 03:28:56 -0800 > > From: Nicholas Knight <[EMAIL PROTECTED]> > > To: Jeff Garzik <[EMAIL PROTECTED]> > > Cc: [EMAIL PROTECTED] > > Subject: Re: [LONG RANT] Re: Linux stifles innovation... > > > > - Original Message - > > From: "Jeff Garzik" <[EMAIL PROTECTED]> > > To: "Werner Almesberger" <[EMAIL PROTECTED]> > > Cc: "Henning P. Schmiedehausen" <[EMAIL PROTECTED]>; > > <[EMAIL PROTECTED]> > > Sent: Monday, February 19, 2001 3:07 AM > > Subject: Re: [LONG RANT] Re: Linux stifles innovation... > > > > > > While I understand that internal docs and source are often simply a mess, I > > fail to see why this should prevent a company from releasing specs or > > source. > > Sure somebody will come along and say "What on earth were you people > > THINKING?!", and then they'll get over it and do something useful with the > > specs and/or source to the drivers (or if they don't, somebody else will) > > I seriously doubt it'd lead to a company seeing a drop in sales because of > > it... and even if they did, I'd say it's a calculated risk, as they could > > well pick up a higher number of new customers than the number of old > > customers they lost due to wider ranging support. > > And even if their specs and code were the worst peices of trash on the > > planet, I'd still thank them for opening them up to the public. > > > > -NK - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
- Original Message - From: "Jeff Garzik" <[EMAIL PROTECTED]> To: "Nicholas Knight" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, February 19, 2001 3:47 AM Subject: Re: [LONG RANT] Re: Linux stifles innovation... > On Mon, 19 Feb 2001, Nicholas Knight wrote: > > From: "Jeff Garzik" <[EMAIL PROTECTED]> > > > While I understand that internal docs and source are often simply a mess, I > > fail to see why this should prevent a company from releasing specs or > > source. > > Sure somebody will come along and say "What on earth were you people > > THINKING?!", and then they'll get over it and do something useful with the > > specs and/or source to the drivers (or if they don't, somebody else will) > > I seriously doubt it'd lead to a company seeing a drop in sales because of > > it... and even if they did, I'd say it's a calculated risk, as they could > > well pick up a higher number of new customers than the number of old > > customers they lost due to wider ranging support. > > And even if their specs and code were the worst peices of trash on the > > planet, I'd still thank them for opening them up to the public. > > You might thank them. The other opinion is... people look at the > newly-released garbage source code, and say "wow, the driver I'm running > is shit. I'm switching to another type of hardware." etc. > > Maybe harmless, maybe PR disaster. As I said, calculated risk. I suppose if it was in a truely horrible state and the company wasn't a large company such as IBM or HP that could probably afford to take the risk, I could understand them being unwilling to release the source and spec sheets. Double edged swords run rampant in the computer industry... *sigh* My dream is probably quite similar to that of every geek on earth... open, standard protocols and API's for *everything* that allows for quick and easy driver and software development, another layer if you will, but getting hundreds of companies that tend to be addicted to closed everything to agree on the standards would probably be next to impossible... prehaps it's time some thought went into how to make this a reality, or are large scale efforts for this already going on that I haven't noticed? > > Jeff -NK - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
On Mon, Feb 19, 2001 at 05:07:02AM -0600, Jeff Garzik wrote:
> On Mon, 19 Feb 2001, Werner Almesberger wrote:
> > Now what's at stake ? Look at the Windows world. Also there, companies
> > could release their drivers as Open Source. Quick, how many do this ?
> > Almost none. So, given the choice, most companies have defaulted to
> > closed source. Consistently complaining when a company tries to release
> > only closed source drivers for Linux seems to generally have the desired
> > effect of making them change their policy.
>
> FWIW, -every single- Windows driver source code I've seen has been
> bloody awful. Asking them to release that code would probably result in
> embarrassment. Same reasoning why many companies won't release hardware
> specifications... The internal docs are bad. Really bad.
Because they start off bloody awful examples. From the DDK. And they
have noone to ask but M$. And they hire a student or a contract
company to write a driver after ambigous specs from the DDK. Or they
just reiterate on a chip-vendor-supported driver again and again
(Quick, can anyone say "NVidia"?). And who certificates (hah!) a
driver written after the DDK to run on an OS? Right, the vendor of
both. =:-)
And the public documentation must be cleared by a lawyer to not
accidentially release IP of another company. And they must be reworked
by a tech writer to be readable for people that "can't go to office
#307 and ask Fred about the wiring details".
All boils down to money, IMHO, not always to bad will. Sometimes,
yes. Most of the time, the CFO will just as the project manager:
"Costs how much? Earns how much?".
I would even like think, that some HW companies would release drivers
as open source if they would be able to find individuals or contract
companies, that are willing to sign NDAs to use the inhouse
information for writing a driver without leaking the information
itself out.
I know of some companies that do that kind of contract work.
Unfortunately most of the time for more exotic HW.
BTW: Lawyer question:
"I release a driver as open source under, BSD license. May I put it
into the kernel source tree or must I compile it as a separate
loadable module for not being in GPL violation."
According to my understanding of the loadable module issue and the GPL
of the kernel, I must distribute the source separated from the kernel
source and may only compile as loadable module.
Would twin licensing solve this? But then I must not pull changes from
the GPL tree back into my BSD tree and distribute this BSD tree under
BSD license, because this license allows a vendor binary only
distribution which is forbidden by the GPL'ed changes. And I must not
pose the "changes to the GPL'ed sources can be pulled back into the
BSD sources" restriction on the tree because then I am already in
violation of the GPL ("must not put additional restrictions on").
So, is it legal to put changes to a twin licensed driver in the Linux
kernel tree back into the same driver in the BSD tree?
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED]
D-91054 Buckenhof Fax.: 09131 / 50654-20
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
Jeff Garzik wrote: > FWIW, -every single- Windows driver source code I've seen has been > bloody awful. Asking them to release that code would probably result in > embarrassment. Maybe a good analogy is that drivers are to hardware companies like excrements are to living creatures: in order to stay alive, they have to produce them, but you don't put much love into their production, and their internals (like their development) may be a little disgusting. > Same reasoning why many companies won't release hardware > specifications... The internal docs are bad. Really bad. A fair number of hardware documents I have came with "here's all the material you'll need, but please don't show this to anyone" (but no NDA), which is fine with me: it doesn't complicate development in any way, and in those few cases where I really needed to share a document, they were flexible enough to allow this. Of course, it's better if documentation is entirely in the public too, but considering the typical overhead of clearing a document for public release, I can understand why companies frequently don't do it. - Werner -- _ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
On Mon, Feb 19, 2001 at 11:53:14AM +0100, Werner Almesberger wrote:
> Henning P. Schmiedehausen wrote:
> Fine. So you've reinvented AIX, HP-UX, SCO, etc. The question is what
> you expect from Linux. After all, you strongly disagree with the main
> common denominator of Linux developers, that it be Open Source.
No, I don't. I don't at all. But I prefer a more pragmatic approach to
the developers and companies who don't.
And yes, there _is_ IMHO a difference in telling someone on LKM,
especially someone without deeper knowledge that is lookin for help:
"You're using a non-open source driver, so we can't help you. Please
ask your vendor for support."
and
"Fuck off, Luser".
("Der Ton macht die Musik". Sorry don't know the equal english
expression).
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED]
D-91054 Buckenhof Fax.: 09131 / 50654-20
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
On Mon, 19 Feb 2001, Nicholas Knight wrote: > From: "Jeff Garzik" <[EMAIL PROTECTED]> > > FWIW, -every single- Windows driver source code I've seen has been > > bloody awful. Asking them to release that code would probably result in > > embarrassment. Same reasoning why many companies won't release hardware > > specifications... The internal docs are bad. Really bad. > > While I understand that internal docs and source are often simply a mess, I > fail to see why this should prevent a company from releasing specs or > source. > Sure somebody will come along and say "What on earth were you people > THINKING?!", and then they'll get over it and do something useful with the > specs and/or source to the drivers (or if they don't, somebody else will) > I seriously doubt it'd lead to a company seeing a drop in sales because of > it... and even if they did, I'd say it's a calculated risk, as they could > well pick up a higher number of new customers than the number of old > customers they lost due to wider ranging support. > And even if their specs and code were the worst peices of trash on the > planet, I'd still thank them for opening them up to the public. You might thank them. The other opinion is... people look at the newly-released garbage source code, and say "wow, the driver I'm running is shit. I'm switching to another type of hardware." etc. Maybe harmless, maybe PR disaster. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
before you go to far in condemming companies, note that even transmeta is in this situation with their docs. when Linus was asked about documentation for the longrun config stuff he stated that whil trasmeta was planning to release both docs and source, they were not willing to release them in the state that they are in currently. and to be perfectly honest, they do have a point, if the internal documentation is so poor, releaseing it will cause a flood of calls for clarification of the docs. it's better to spend the time before release to fix it then to spend the time (a much larger chunk of time) after the release explaining it multiple times AND fixing the docs. sometimes companies are not willing to spend that much time on what they see as a minor market. that's just the fact of life. the real fix isn't to yell at the companies, it's to show them that it is a significant market and worth them spending their money there. David Lang On Mon, 19 Feb 2001, Nicholas Knight wrote: > Date: Mon, 19 Feb 2001 03:28:56 -0800 > From: Nicholas Knight <[EMAIL PROTECTED]> > To: Jeff Garzik <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: [LONG RANT] Re: Linux stifles innovation... > > - Original Message - > From: "Jeff Garzik" <[EMAIL PROTECTED]> > To: "Werner Almesberger" <[EMAIL PROTECTED]> > Cc: "Henning P. Schmiedehausen" <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]> > Sent: Monday, February 19, 2001 3:07 AM > Subject: Re: [LONG RANT] Re: Linux stifles innovation... > > > > On Mon, 19 Feb 2001, Werner Almesberger wrote: > > > Now what's at stake ? Look at the Windows world. Also there, companies > > > could release their drivers as Open Source. Quick, how many do this ? > > > Almost none. So, given the choice, most companies have defaulted to > > > closed source. Consistently complaining when a company tries to release > > > only closed source drivers for Linux seems to generally have the desired > > > effect of making them change their policy. > > > > FWIW, -every single- Windows driver source code I've seen has been > > bloody awful. Asking them to release that code would probably result in > > embarrassment. Same reasoning why many companies won't release hardware > > specifications... The internal docs are bad. Really bad. > > While I understand that internal docs and source are often simply a mess, I > fail to see why this should prevent a company from releasing specs or > source. > Sure somebody will come along and say "What on earth were you people > THINKING?!", and then they'll get over it and do something useful with the > specs and/or source to the drivers (or if they don't, somebody else will) > I seriously doubt it'd lead to a company seeing a drop in sales because of > it... and even if they did, I'd say it's a calculated risk, as they could > well pick up a higher number of new customers than the number of old > customers they lost due to wider ranging support. > And even if their specs and code were the worst peices of trash on the > planet, I'd still thank them for opening them up to the public. > > -NK > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
- Original Message - From: "Jeff Garzik" <[EMAIL PROTECTED]> To: "Werner Almesberger" <[EMAIL PROTECTED]> Cc: "Henning P. Schmiedehausen" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, February 19, 2001 3:07 AM Subject: Re: [LONG RANT] Re: Linux stifles innovation... > On Mon, 19 Feb 2001, Werner Almesberger wrote: > > Now what's at stake ? Look at the Windows world. Also there, companies > > could release their drivers as Open Source. Quick, how many do this ? > > Almost none. So, given the choice, most companies have defaulted to > > closed source. Consistently complaining when a company tries to release > > only closed source drivers for Linux seems to generally have the desired > > effect of making them change their policy. > > FWIW, -every single- Windows driver source code I've seen has been > bloody awful. Asking them to release that code would probably result in > embarrassment. Same reasoning why many companies won't release hardware > specifications... The internal docs are bad. Really bad. While I understand that internal docs and source are often simply a mess, I fail to see why this should prevent a company from releasing specs or source. Sure somebody will come along and say "What on earth were you people THINKING?!", and then they'll get over it and do something useful with the specs and/or source to the drivers (or if they don't, somebody else will) I seriously doubt it'd lead to a company seeing a drop in sales because of it... and even if they did, I'd say it's a calculated risk, as they could well pick up a higher number of new customers than the number of old customers they lost due to wider ranging support. And even if their specs and code were the worst peices of trash on the planet, I'd still thank them for opening them up to the public. -NK - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
On Mon, 19 Feb 2001, Werner Almesberger wrote: > Now what's at stake ? Look at the Windows world. Also there, companies > could release their drivers as Open Source. Quick, how many do this ? > Almost none. So, given the choice, most companies have defaulted to > closed source. Consistently complaining when a company tries to release > only closed source drivers for Linux seems to generally have the desired > effect of making them change their policy. FWIW, -every single- Windows driver source code I've seen has been bloody awful. Asking them to release that code would probably result in embarrassment. Same reasoning why many companies won't release hardware specifications... The internal docs are bad. Really bad. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
Henning P. Schmiedehausen wrote: > Company wants to make at least some bucks with their > products and the driver is part of the product. So they may want to > release a driver which is "closed source". Usually, the driver doesn't play a large role in product differentiation, at least not in a positive way. Also, we must balance the value closed-sourcing the driver may have for a company, against the damage this does to Linux development. Now what's at stake ? Look at the Windows world. Also there, companies could release their drivers as Open Source. Quick, how many do this ? Almost none. So, given the choice, most companies have defaulted to closed source. Consistently complaining when a company tries to release only closed source drivers for Linux seems to generally have the desired effect of making them change their policy. So if we'd follow your line of reasoning, we'd end up with almost all drivers being closed-source. Since drivers are an essential part of any Linux kernel, this would essentially mean that all of the Linux kernel would be subjected to the constraints of closed-source development. Fine. So you've reinvented AIX, HP-UX, SCO, etc. The question is what you expect from Linux. After all, you strongly disagree with the main common denominator of Linux developers, that it be Open Source. - Werner -- _ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
"Henning P. Schmiedehausen" wrote: > > _BUT_ all these people that want to use Linux ask sometimes for help > outside their vendor contracts, they get told exactly this: "Go away > where. You're not using the "one true source from kernel.org". They're > more locked it with their "open software" than people that use > windows. Because if they ask for help in a M$ support forum, they get > help. Sometimes (most of the times) they have to pay for it but > they're willing to pay. That's the point. They're willing to pay for > help and they don't want to hear "fuck off and get xxx Linux instead > of yyy Linux". Or "fuck off and use zmailer, only idiots still use > sendmail". Microsoft is no better. MS don't provide all the software that runs on windows. Get some product (say, a word processor) that competes with with MS office. Then go try getting help when that word processor have trouble with your new printer. MS: "Get word instead, only idiots use that word processor. Or try a different printer. Maybe the vendor has a newer driver." Printer vendor: "must be a sw problem, it works fine with office" Word processor vendor: "It works fine with hundreds of printers, use something other than that screwball printer of yours." Been there, done that. > Or "Recompile your kernel. Check out kernel v2.3.99pre7-ac8 with the > latest patch from Andrea Arcangeli" (And most of the times they as > themselves, who is this Andrea-gal anyway? ;-) (SCNR))" Nothing wrong with this advice. Of course the company that prefer paying for support will simply not see it, the guy they pay for support will be the one who collect such advice and implement it. > Look at the ECN discussion. Look at the NFS discussion. Look at the IP > fragmentation discussion. Most non-technical people don't want to hear > "you can't connect from your company proxy to hotmail because they're > braindead with their firewalls and don't wanna listen". They hear this But you can connect. Your support guy simply have to turn off ECN. Distributors don't ship ECN kernels anyway, they aren't stupid. It is a default only for those who compile their own kernel. > The state of driver for printing or font rendering on the desktop is > terrible. You may rant about M$ all the time, but if I buy a new > printer, I get a driver which produces printouts like on my screen and > like my last printer. I get all the nifty features supported that this > printer has. Linux surely don't support all the printers out there. This fact is no more problem than the fact that "windows don't run on ARM, 68040, S/390, and a lot of other platforms linux runs on" A company buy intel compatible machines for running windows. And they buy one of the well-supported printers if they want a linux print server. Go for a postscript printer, or one of those with good ghostscript support. Not a problem at all. Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
"Henning P. Schmiedehausen" wrote: _BUT_ all these people that want to use Linux ask sometimes for help outside their vendor contracts, they get told exactly this: "Go away where. You're not using the "one true source from kernel.org". They're more locked it with their "open software" than people that use windows. Because if they ask for help in a M$ support forum, they get help. Sometimes (most of the times) they have to pay for it but they're willing to pay. That's the point. They're willing to pay for help and they don't want to hear "fuck off and get xxx Linux instead of yyy Linux". Or "fuck off and use zmailer, only idiots still use sendmail". Microsoft is no better. MS don't provide all the software that runs on windows. Get some product (say, a word processor) that competes with with MS office. Then go try getting help when that word processor have trouble with your new printer. MS: "Get word instead, only idiots use that word processor. Or try a different printer. Maybe the vendor has a newer driver." Printer vendor: "must be a sw problem, it works fine with office" Word processor vendor: "It works fine with hundreds of printers, use something other than that screwball printer of yours." Been there, done that. Or "Recompile your kernel. Check out kernel v2.3.99pre7-ac8 with the latest patch from Andrea Arcangeli" (And most of the times they as themselves, who is this Andrea-gal anyway? ;-) (SCNR))" Nothing wrong with this advice. Of course the company that prefer paying for support will simply not see it, the guy they pay for support will be the one who collect such advice and implement it. Look at the ECN discussion. Look at the NFS discussion. Look at the IP fragmentation discussion. Most non-technical people don't want to hear "you can't connect from your company proxy to hotmail because they're braindead with their firewalls and don't wanna listen". They hear this But you can connect. Your support guy simply have to turn off ECN. Distributors don't ship ECN kernels anyway, they aren't stupid. It is a default only for those who compile their own kernel. The state of driver for printing or font rendering on the desktop is terrible. You may rant about M$ all the time, but if I buy a new printer, I get a driver which produces printouts like on my screen and like my last printer. I get all the nifty features supported that this printer has. Linux surely don't support all the printers out there. This fact is no more problem than the fact that "windows don't run on ARM, 68040, S/390, and a lot of other platforms linux runs on" A company buy intel compatible machines for running windows. And they buy one of the well-supported printers if they want a linux print server. Go for a postscript printer, or one of those with good ghostscript support. Not a problem at all. Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
Henning P. Schmiedehausen wrote: Company wants to make at least some bucks with their products and the driver is part of the product. So they may want to release a driver which is "closed source". Usually, the driver doesn't play a large role in product differentiation, at least not in a positive way. Also, we must balance the value closed-sourcing the driver may have for a company, against the damage this does to Linux development. Now what's at stake ? Look at the Windows world. Also there, companies could release their drivers as Open Source. Quick, how many do this ? Almost none. So, given the choice, most companies have defaulted to closed source. Consistently complaining when a company tries to release only closed source drivers for Linux seems to generally have the desired effect of making them change their policy. So if we'd follow your line of reasoning, we'd end up with almost all drivers being closed-source. Since drivers are an essential part of any Linux kernel, this would essentially mean that all of the Linux kernel would be subjected to the constraints of closed-source development. Fine. So you've reinvented AIX, HP-UX, SCO, etc. The question is what you expect from Linux. After all, you strongly disagree with the main common denominator of Linux developers, that it be Open Source. - Werner -- _ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
On Mon, 19 Feb 2001, Werner Almesberger wrote: Now what's at stake ? Look at the Windows world. Also there, companies could release their drivers as Open Source. Quick, how many do this ? Almost none. So, given the choice, most companies have defaulted to closed source. Consistently complaining when a company tries to release only closed source drivers for Linux seems to generally have the desired effect of making them change their policy. FWIW, -every single- Windows driver source code I've seen has been bloody awful. Asking them to release that code would probably result in embarrassment. Same reasoning why many companies won't release hardware specifications... The internal docs are bad. Really bad. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
- Original Message - From: "Jeff Garzik" [EMAIL PROTECTED] To: "Werner Almesberger" [EMAIL PROTECTED] Cc: "Henning P. Schmiedehausen" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, February 19, 2001 3:07 AM Subject: Re: [LONG RANT] Re: Linux stifles innovation... On Mon, 19 Feb 2001, Werner Almesberger wrote: Now what's at stake ? Look at the Windows world. Also there, companies could release their drivers as Open Source. Quick, how many do this ? Almost none. So, given the choice, most companies have defaulted to closed source. Consistently complaining when a company tries to release only closed source drivers for Linux seems to generally have the desired effect of making them change their policy. FWIW, -every single- Windows driver source code I've seen has been bloody awful. Asking them to release that code would probably result in embarrassment. Same reasoning why many companies won't release hardware specifications... The internal docs are bad. Really bad. While I understand that internal docs and source are often simply a mess, I fail to see why this should prevent a company from releasing specs or source. Sure somebody will come along and say "What on earth were you people THINKING?!", and then they'll get over it and do something useful with the specs and/or source to the drivers (or if they don't, somebody else will) I seriously doubt it'd lead to a company seeing a drop in sales because of it... and even if they did, I'd say it's a calculated risk, as they could well pick up a higher number of new customers than the number of old customers they lost due to wider ranging support. And even if their specs and code were the worst peices of trash on the planet, I'd still thank them for opening them up to the public. -NK - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
before you go to far in condemming companies, note that even transmeta is in this situation with their docs. when Linus was asked about documentation for the longrun config stuff he stated that whil trasmeta was planning to release both docs and source, they were not willing to release them in the state that they are in currently. and to be perfectly honest, they do have a point, if the internal documentation is so poor, releaseing it will cause a flood of calls for clarification of the docs. it's better to spend the time before release to fix it then to spend the time (a much larger chunk of time) after the release explaining it multiple times AND fixing the docs. sometimes companies are not willing to spend that much time on what they see as a minor market. that's just the fact of life. the real fix isn't to yell at the companies, it's to show them that it is a significant market and worth them spending their money there. David Lang On Mon, 19 Feb 2001, Nicholas Knight wrote: Date: Mon, 19 Feb 2001 03:28:56 -0800 From: Nicholas Knight [EMAIL PROTECTED] To: Jeff Garzik [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [LONG RANT] Re: Linux stifles innovation... - Original Message - From: "Jeff Garzik" [EMAIL PROTECTED] To: "Werner Almesberger" [EMAIL PROTECTED] Cc: "Henning P. Schmiedehausen" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, February 19, 2001 3:07 AM Subject: Re: [LONG RANT] Re: Linux stifles innovation... On Mon, 19 Feb 2001, Werner Almesberger wrote: Now what's at stake ? Look at the Windows world. Also there, companies could release their drivers as Open Source. Quick, how many do this ? Almost none. So, given the choice, most companies have defaulted to closed source. Consistently complaining when a company tries to release only closed source drivers for Linux seems to generally have the desired effect of making them change their policy. FWIW, -every single- Windows driver source code I've seen has been bloody awful. Asking them to release that code would probably result in embarrassment. Same reasoning why many companies won't release hardware specifications... The internal docs are bad. Really bad. While I understand that internal docs and source are often simply a mess, I fail to see why this should prevent a company from releasing specs or source. Sure somebody will come along and say "What on earth were you people THINKING?!", and then they'll get over it and do something useful with the specs and/or source to the drivers (or if they don't, somebody else will) I seriously doubt it'd lead to a company seeing a drop in sales because of it... and even if they did, I'd say it's a calculated risk, as they could well pick up a higher number of new customers than the number of old customers they lost due to wider ranging support. And even if their specs and code were the worst peices of trash on the planet, I'd still thank them for opening them up to the public. -NK - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
On Mon, 19 Feb 2001, Nicholas Knight wrote: From: "Jeff Garzik" [EMAIL PROTECTED] FWIW, -every single- Windows driver source code I've seen has been bloody awful. Asking them to release that code would probably result in embarrassment. Same reasoning why many companies won't release hardware specifications... The internal docs are bad. Really bad. While I understand that internal docs and source are often simply a mess, I fail to see why this should prevent a company from releasing specs or source. Sure somebody will come along and say "What on earth were you people THINKING?!", and then they'll get over it and do something useful with the specs and/or source to the drivers (or if they don't, somebody else will) I seriously doubt it'd lead to a company seeing a drop in sales because of it... and even if they did, I'd say it's a calculated risk, as they could well pick up a higher number of new customers than the number of old customers they lost due to wider ranging support. And even if their specs and code were the worst peices of trash on the planet, I'd still thank them for opening them up to the public. You might thank them. The other opinion is... people look at the newly-released garbage source code, and say "wow, the driver I'm running is shit. I'm switching to another type of hardware." etc. Maybe harmless, maybe PR disaster. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
On Mon, Feb 19, 2001 at 11:53:14AM +0100, Werner Almesberger wrote:
Henning P. Schmiedehausen wrote:
Fine. So you've reinvented AIX, HP-UX, SCO, etc. The question is what
you expect from Linux. After all, you strongly disagree with the main
common denominator of Linux developers, that it be Open Source.
No, I don't. I don't at all. But I prefer a more pragmatic approach to
the developers and companies who don't.
And yes, there _is_ IMHO a difference in telling someone on LKM,
especially someone without deeper knowledge that is lookin for help:
"You're using a non-open source driver, so we can't help you. Please
ask your vendor for support."
and
"Fuck off, insert binary vendor, software or distribution Luser".
("Der Ton macht die Musik". Sorry don't know the equal english
expression).
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED]
D-91054 Buckenhof Fax.: 09131 / 50654-20
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
Jeff Garzik wrote: FWIW, -every single- Windows driver source code I've seen has been bloody awful. Asking them to release that code would probably result in embarrassment. Maybe a good analogy is that drivers are to hardware companies like excrements are to living creatures: in order to stay alive, they have to produce them, but you don't put much love into their production, and their internals (like their development) may be a little disgusting. Same reasoning why many companies won't release hardware specifications... The internal docs are bad. Really bad. A fair number of hardware documents I have came with "here's all the material you'll need, but please don't show this to anyone" (but no NDA), which is fine with me: it doesn't complicate development in any way, and in those few cases where I really needed to share a document, they were flexible enough to allow this. Of course, it's better if documentation is entirely in the public too, but considering the typical overhead of clearing a document for public release, I can understand why companies frequently don't do it. - Werner -- _ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
On Mon, Feb 19, 2001 at 05:07:02AM -0600, Jeff Garzik wrote:
On Mon, 19 Feb 2001, Werner Almesberger wrote:
Now what's at stake ? Look at the Windows world. Also there, companies
could release their drivers as Open Source. Quick, how many do this ?
Almost none. So, given the choice, most companies have defaulted to
closed source. Consistently complaining when a company tries to release
only closed source drivers for Linux seems to generally have the desired
effect of making them change their policy.
FWIW, -every single- Windows driver source code I've seen has been
bloody awful. Asking them to release that code would probably result in
embarrassment. Same reasoning why many companies won't release hardware
specifications... The internal docs are bad. Really bad.
Because they start off bloody awful examples. From the DDK. And they
have noone to ask but M$. And they hire a student or a contract
company to write a driver after ambigous specs from the DDK. Or they
just reiterate on a chip-vendor-supported driver again and again
(Quick, can anyone say "NVidia"?). And who certificates (hah!) a
driver written after the DDK to run on an OS? Right, the vendor of
both. =:-)
And the public documentation must be cleared by a lawyer to not
accidentially release IP of another company. And they must be reworked
by a tech writer to be readable for people that "can't go to office
#307 and ask Fred about the wiring details".
All boils down to money, IMHO, not always to bad will. Sometimes,
yes. Most of the time, the CFO will just as the project manager:
"Costs how much? Earns how much?".
I would even like think, that some HW companies would release drivers
as open source if they would be able to find individuals or contract
companies, that are willing to sign NDAs to use the inhouse
information for writing a driver without leaking the information
itself out.
I know of some companies that do that kind of contract work.
Unfortunately most of the time for more exotic HW.
BTW: Lawyer question:
"I release a driver as open source under, BSD license. May I put it
into the kernel source tree or must I compile it as a separate
loadable module for not being in GPL violation."
According to my understanding of the loadable module issue and the GPL
of the kernel, I must distribute the source separated from the kernel
source and may only compile as loadable module.
Would twin licensing solve this? But then I must not pull changes from
the GPL tree back into my BSD tree and distribute this BSD tree under
BSD license, because this license allows a vendor binary only
distribution which is forbidden by the GPL'ed changes. And I must not
pose the "changes to the GPL'ed sources can be pulled back into the
BSD sources" restriction on the tree because then I am already in
violation of the GPL ("must not put additional restrictions on").
So, is it legal to put changes to a twin licensed driver in the Linux
kernel tree back into the same driver in the BSD tree?
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED]
D-91054 Buckenhof Fax.: 09131 / 50654-20
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
- Original Message - From: "Jeff Garzik" [EMAIL PROTECTED] To: "Nicholas Knight" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, February 19, 2001 3:47 AM Subject: Re: [LONG RANT] Re: Linux stifles innovation... On Mon, 19 Feb 2001, Nicholas Knight wrote: From: "Jeff Garzik" [EMAIL PROTECTED] snip While I understand that internal docs and source are often simply a mess, I fail to see why this should prevent a company from releasing specs or source. Sure somebody will come along and say "What on earth were you people THINKING?!", and then they'll get over it and do something useful with the specs and/or source to the drivers (or if they don't, somebody else will) I seriously doubt it'd lead to a company seeing a drop in sales because of it... and even if they did, I'd say it's a calculated risk, as they could well pick up a higher number of new customers than the number of old customers they lost due to wider ranging support. And even if their specs and code were the worst peices of trash on the planet, I'd still thank them for opening them up to the public. You might thank them. The other opinion is... people look at the newly-released garbage source code, and say "wow, the driver I'm running is shit. I'm switching to another type of hardware." etc. Maybe harmless, maybe PR disaster. As I said, calculated risk. I suppose if it was in a truely horrible state and the company wasn't a large company such as IBM or HP that could probably afford to take the risk, I could understand them being unwilling to release the source and spec sheets. Double edged swords run rampant in the computer industry... *sigh* My dream is probably quite similar to that of every geek on earth... open, standard protocols and API's for *everything* that allows for quick and easy driver and software development, another layer if you will, but getting hundreds of companies that tend to be addicted to closed everything to agree on the standards would probably be next to impossible... prehaps it's time some thought went into how to make this a reality, or are large scale efforts for this already going on that I haven't noticed? Jeff -NK - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
Henning P . Schmiedehausen wrote: No, I don't. I don't at all. But I prefer a more pragmatic approach to the developers and companies who don't. I actually think it's good if we appear to be a little more "hard-liners" than we really are. If companies assume that only open source will get them anywhere, they'll err on the safe side. In the end, this is likely to be to their own benefit: they won't waste time designing not-quite open models that fail in the end (and may generate a lot of bad blood), and can focus directly on options that make everybody happy. And yes, there _is_ IMHO a difference in telling someone on LKM, especially someone without deeper knowledge that is lookin for help: Yes, also rejection can be delivered in a civilized way. - Werner -- _ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
I suspect part of the problem with commercial driver support on Linux is that the Linux driver API (such as it is) is relatively poorly documented and seems to change almost on a week-by-week basis anyway. I've done my share of chasing the current kernel revision with drivers that aren't part of the kernel tree: by the time you update the driver to work with the current kernel revision, there's a new one out, and the driver doesn't compile with it. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
"Jeff" == Jeff Garzik [EMAIL PROTECTED] writes: Jeff On Mon, 19 Feb 2001, Werner Almesberger wrote: Now what's at stake ? Look at the Windows world. Also there, companies could release their drivers as Open Source. Quick, how many do this ? Almost none. So, given the choice, most companies have defaulted to closed source. Consistently complaining when a company tries to release only closed source drivers for Linux seems to generally have the desired effect of making them change their policy. Jeff FWIW, -every single- Windows driver source code I've seen has Jeff been bloody awful. Asking them to release that code would Jeff probably result in embarrassment. Same reasoning why many Jeff companies won't release hardware specifications... The internal Jeff docs are bad. Really bad. Trust me, commercial UNIX drivers aren't any better. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
On Mon, 19 Feb 2001, David Howells wrote: I suspect part of the problem with commercial driver support on Linux is that the Linux driver API (such as it is) is relatively poorly documented In-kernel documentation, agreed. _Linux Device Drivers_ is a good reference for 2.2 and below. and seems to change almost on a week-by-week basis anyway. I've done my share of chasing the current kernel revision with drivers that aren't part of the kernel tree: by the time you update the driver to work with the current kernel revision, there's a new one out, and the driver doesn't compile with it. This is entirely in your imagination. Driver APIs are stable across the stable series of kernels: 2.0.0 through 2.0.38, 2.2.0 through 2.2.18, 2.4.0 through whatever. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
I suspect part of the problem with commercial driver support on Linux is that the Linux driver API (such as it is) is relatively poorly documented In-kernel documentation, agreed. _Linux Device Drivers_ is a good reference for 2.2 and below. And do implementators of generic kernel functions and developers of device drivers respect it? And how can they respect it if it's a commercial book? and seems to change almost on a week-by-week basis anyway. I've done my share of chasing the current kernel revision with drivers that aren't part of the kernel tree: by the time you update the driver to work with the current kernel revision, there's a new one out, and the driver doesn't compile with it. This is entirely in your imagination. Driver APIs are stable across the stable series of kernels: 2.0.0 through 2.0.38, 2.2.0 through 2.2.18, 2.4.0 through whatever. No true. Do you remember for example the mark_buffer_dirty change in some 2.2.x that triggered ext2 directory corruption? (mark_buffer_dirty was changed so that it could block). Another example of bug that comes from the lack of specification is calling of get_free_pages by non-running processes that caused lockups on all kernels 2.2.15. And it is still not cleaned up - see tcp_recvmsg(). Having documentation could prevent this kind of bugs. You don't need too long texts, just a brief description: "this function may be called from process/bh/interrupt context, it may/may not block, it may/may not be called in TASK_[UN]INTERURPTIBLE state, it may take these locks." With documentation developers would be able to change implementation of kernel functions without the need to recheck all drivers that use them. Saying "code is the specification" is not good. Mikulas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
On Mon, 19 Feb 2001, Jeff Garzik wrote: On Mon, 19 Feb 2001, David Howells wrote: I suspect part of the problem with commercial driver support on Linux is that the Linux driver API (such as it is) is relatively poorly documented In-kernel documentation, agreed. _Linux Device Drivers_ is a good reference for 2.2 and below. and seems to change almost on a week-by-week basis anyway. I've done my share of chasing the current kernel revision with drivers that aren't part of the kernel tree: by the time you update the driver to work with the current kernel revision, there's a new one out, and the driver doesn't compile with it. This is entirely in your imagination. Driver APIs are stable across the stable series of kernels: 2.0.0 through 2.0.38, 2.2.0 through 2.2.18, 2.4.0 through whatever. Jeff One of the latest module killers was the opaque type, "THIS_MODULE", put at the beginning of struct file_operations. This happened between 2.4.0 and 2.4.x. So it's not "imagination". It is well understood that there will be changes to the driver APIs, but some could be better thought out to accomplish what must be accomplished, but at the same time, minimize the code changes to existing drivers. While on the subject of compatibility, I just put 1 gb of memory in one of my machines at home this weekend, with 256 mb sticks now costing under $US 80, I figured it was about time. The machine would not boot with Linux 2.4.1 just Uncompressing then nothing. I had to remove one memory stick. I recompiled with "high memory" enabled, CONFIG_HIGHMEM4G. I was unable to use the new kernel because the drivers I need for `initrd` all had undefined symbols relating to some high memory stuff. This, in spite of the fact that I did: cp .config .. make clean make distclean cp ../.config make oldconfig make dep make bzImage make modules make modules_install I can't understand how changes in memory management could possibly affect drivers! They should not care where memory comes from! If a driver, calling kmalloc() or whatever, needs to know anything about where the pages made available were stashed, then something's broken, plain and simple. Also, with 4 gb of address space in ix86 machines, we should not have any problems accessing memory until the sum of all the RAM, plus the sum of all the address-space needed for PCI resources, plus anything below 1 megabyte, plus the physical memory required for PTEs and kernel resources, starts to get near 4 gb. Presently, the address limit without "highmem hacks" is less than 1 gb. This needs some work. It looks as though somebody guessed that 'PAGE_OFFSET' imposed some kind of limit. It doesn't as long as it's summed, not ORed (some early code I looked at ORed in PAGE_OFFSET in several places, destroying the linearity of address arithmetic). Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
On Mon, 19 Feb 2001, Henning P . Schmiedehausen wrote: So, is it legal to put changes to a twin licensed driver in the Linux kernel tree back into the same driver in the BSD tree? IANAL, but AIUI: if the changes are made the copyright holder then they may do whatever they want. (release the changes only under one licence, both, none, etc..) if small changes are made by a 3rd party (eg a patch) and submitted back to the copyright holder, then it is almost safe to presume that the copyright holder may incorporate those changes without ceding copyright in any way. (then see first point) if major changes are made by a 3rd party then (i think) 3rd party has copyright over their changes, and so, either: -copyright holder of the original work would need to comply with the licence of the derived work. (eg if GPL, then changes can't go back into the BSD version) or: - copyright holder of the original work would need express permission from the copyright holder of the derived work to use it under a different licence. but IANAL most obviously... :) Regards Henning --paulj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
So, is it legal to put changes to a twin licensed driver in the Linux kernel tree back into the same driver in the BSD tree? Just make it plain that patches and contributions to that driver must be dual licensed. We have several shared drivers with BSD and most people seem happy that small fixes to a dual or BSD licensed drivers should go back under the original license. In fact I'd say I'm not the only one who would find it impolite otherwise. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
On Mon, 19 Feb 2001, Richard B. Johnson wrote: One of the latest module killers was the opaque type, "THIS_MODULE", put at the beginning of struct file_operations. This happened between 2.4.0 and 2.4.x. So it's not "imagination". Richard, Time to join the rest of us on planet Earth. That was added in 2.4.0-test2, and was most definitely in 2.4.0 release. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
On Mon, 19 Feb 2001, Mikulas Patocka wrote: I suspect part of the problem with commercial driver support on Linux is that the Linux driver API (such as it is) is relatively poorly documented In-kernel documentation, agreed. _Linux Device Drivers_ is a good reference for 2.2 and below. And do implementators of generic kernel functions and developers of device drivers respect it? And how can they respect it if it's a commercial book? _Linux Device Drivers_ documents the 2.2 (and previous) API, and thus refutes the argument that the kernel API is poorly documented. Since the publication of the book -succeeds- the publication of the APIs, your questions are not applicable. and seems to change almost on a week-by-week basis anyway. I've done my share of chasing the current kernel revision with drivers that aren't part of the kernel tree: by the time you update the driver to work with the current kernel revision, there's a new one out, and the driver doesn't compile with it. This is entirely in your imagination. Driver APIs are stable across the stable series of kernels: 2.0.0 through 2.0.38, 2.2.0 through 2.2.18, 2.4.0 through whatever. No true. Do you remember for example the mark_buffer_dirty change in some 2.2.x that triggered ext2 directory corruption? (mark_buffer_dirty was changed so that it could block). Another example of bug that comes from the lack of specification is calling of get_free_pages by non-running processes that caused lockups on all kernels 2.2.15. And it is still not cleaned up - see tcp_recvmsg(). Having documentation could prevent this kind of bugs. Hardly. No documentation is often -better- than bad documentation. You don't need too long texts, just a brief description: "this function may be called from process/bh/interrupt context, it may/may not block, it may/may not be called in TASK_[UN]INTERURPTIBLE state, it may take these locks." With documentation developers would be able to change implementation of kernel functions without the need to recheck all drivers that use them. Anytime you change implementation, you gotta check all drivers that use them. I know, I'm one of the grunts that does such reviews and changes. Saying "code is the specification" is not good. I'm not arguing against documentation. That is dumb. But the code is ALWAYS canonical. Not docs. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
One of the latest module killers was the opaque type, "THIS_MODULE", put at the beginning of struct file_operations. This happened between 2.4.0 and 2.4.x. So it's not "imagination". No it happened before 2.4.0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
The lack of specification (was Re: [LONG RANT] Re: Linux stifles innovation... )
I suspect part of the problem with commercial driver support on Linux is that the Linux driver API (such as it is) is relatively poorly documented In-kernel documentation, agreed. _Linux Device Drivers_ is a good reference for 2.2 and below. And do implementators of generic kernel functions and developers of device drivers respect it? And how can they respect it if it's a commercial book? _Linux Device Drivers_ documents the 2.2 (and previous) API, and thus refutes the argument that the kernel API is poorly documented. Since the publication of the book -succeeds- the publication of the APIs, your questions are not applicable. What does it say about mark_buffer_dirty blocking or schedule and TASK_[UN]INTERRUPTIBLE issues? If it says nothing, it is bad documentation. If it says something, kernel developers do not respect it and it is useless documentation... and seems to change almost on a week-by-week basis anyway. I've done my share of chasing the current kernel revision with drivers that aren't part of the kernel tree: by the time you update the driver to work with the current kernel revision, there's a new one out, and the driver doesn't compile with it. This is entirely in your imagination. Driver APIs are stable across the stable series of kernels: 2.0.0 through 2.0.38, 2.2.0 through 2.2.18, 2.4.0 through whatever. No true. Do you remember for example the mark_buffer_dirty change in some 2.2.x that triggered ext2 directory corruption? (mark_buffer_dirty was changed so that it could block). Another example of bug that comes from the lack of specification is calling of get_free_pages by non-running processes that caused lockups on all kernels 2.2.15. And it is still not cleaned up - see tcp_recvmsg(). Having documentation could prevent this kind of bugs. Hardly. Imagine that there is specification of mark_buffer_dirty. That specification says that 1. it may not block 2. it may block In case 1. implementators wouldn't change it to block in stable kernel relese because they don't want to violate the specification. In case 2. implementators of ext2 wouldn't assume that it doesn't block even if it doesn't in current implementation. In both cases, the bug wouldn't be created. No documentation is often -better- than bad documentation. Of course. But good documentation is better than no documentation :-) You don't need too long texts, just a brief description: "this function may be called from process/bh/interrupt context, it may/may not block, it may/may not be called in TASK_[UN]INTERURPTIBLE state, it may take these locks." With documentation developers would be able to change implementation of kernel functions without the need to recheck all drivers that use them. Anytime you change implementation, you gotta check all drivers that use them. I know, I'm one of the grunts that does such reviews and changes. Anytime you change implementation of syscalls, you gotta check all applications that use them ;-) Luckily not - because there is specification and you can check that syscalls conform to the specification, not apps. Saying "code is the specification" is not good. I'm not arguing against documentation. That is dumb. But the code is ALWAYS canonical. Not docs. Let's see: There are parts of code (1) that set state to TASK_[UN]INTERRUPTIBLE and then call some other complex functions, like page fault handlers. (for example tcp in 2.2) There are parts of code (2) that call schedule to yield the process assuming that the state is TASK_RUNNING. (including some drivers) Sooner or later will happen, that subroutine called from part (1) get somehow to part (2) and the process locks up. Now implementators of TCP will say: that driver is buggy. Everybody should set state=TASK_RUNNING before calling schedule to yield the process. Implementators of driver will say: TCP is buggy - no one should call my driver in TASK_[UN]INTERRUPTIBLE state. Who is right? If there is no specification Mikulas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
On Mon, 19 Feb 2001, Henning P . Schmiedehausen wrote:
And yes, there _is_ IMHO a difference in telling someone on LKM,
especially someone without deeper knowledge that is lookin for help:
"You're using a non-open source driver, so we can't help you. Please
ask your vendor for support."
Henning,
Lets be realistic here. If I take my BMW (M series) into the shop because
it has problem yet I tell the German Mechanic that he may not look under
the hood because there is a secret "wonder blunder" inside. Where do you
think that mechanic is going to tell you to go??
This is the motor(kernel-space) not the paint(user-space).
You have admitted that you are an "End-User"(of the kernel) and that you
generally write user-space packages. I have yet to understand why you are
going out of bounds. It is clear that you have read to many of my person
best flame-wars here on LKML where I know I must have earned :
"Arse of the Year, 2000 :: LKML"
"Fuck off, insert binary vendor, software or distribution Luser".
And you slammed me for being rude and ugly?? In my defense of code and
work that I publish, but heavily enforce the license and terms of use.
Since I am aware that about 96% of all linux boxes today use some form of
ATA/ATAPI, it is important that I recover all know fixes public/private
to help everyone.
("Der Ton macht die Musik". Sorry don't know the equal english
expression).
I now see the joy in watching someone go nuts here on LKML.
Respectfully,
Andre Hedrick
Linux ATA Development
ps. Please keep up the entertainment, I am getting a good belly-laugh
of what I must have looked like in the past.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: The lack of specification (was Re: [LONG RANT] Re: Linux stifles innovation... )
Mikulas Patocka writes: Imagine that there is specification of mark_buffer_dirty. That specification says that 1. it may not block 2. it may block In case 1. implementators wouldn't change it to block in stable kernel relese because they don't want to violate the specification. One of these things must happen: a. follow the specification, even if that makes code slow and contorted b. change the specification c. ignore the specification d. get rid of the specification Option "a" will not be accepted around here. Sorry. The best you can hope for is option "b". Since that is hard work (want to help?) we often end up not using a specification... hopefully by just not having one, instead of by ignoring one. Not saying it doesn't suck to have things undocumented, but at least you don't have to reverse-engineer a multi-megabyte binary kernel to find out what is going on. Anytime you change implementation, you gotta check all drivers that use them. I know, I'm one of the grunts that does such reviews and changes. Anytime you change implementation of syscalls, you gotta check all applications that use them ;-) Luckily not - because there is specification and you can check that syscalls conform to the specification, not apps. Syscalls are more stable, but they may be changed after many years of a transition period. The C library hides some of this from users. Now implementators of TCP will say: that driver is buggy. Everybody should set state=TASK_RUNNING before calling schedule to yield the process. Implementators of driver will say: TCP is buggy - no one should call my driver in TASK_[UN]INTERRUPTIBLE state. Who is right? If there is no specification The driver is buggy, unless the TCP maintainer can be convinced that TCP is buggy. TCP is a big chunk of code that most people use, while the driver is not so huge or critical. The TCP maintainers do not seem to be sadistic bastards hell-bent on breaking your drivers. API changes usually have a good reason. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The lack of specification (was Re: [LONG RANT] Re: Linux stifles innovation... )
One of these things must happen: a. follow the specification, even if that makes code slow and contorted b. change the specification c. ignore the specification d. get rid of the specification Option "a" will not be accepted around here. Sorry. It should be followed in stable releases. (and usually is - except for few cases - and except that there is no specification, just unwritten rules). The best you can hope for is option "b". Since that is hard work (want to help?) we often end up not using a specification... hopefully by just not having one, instead of by ignoring one. Now implementators of TCP will say: that driver is buggy. Everybody should set state=TASK_RUNNING before calling schedule to yield the process. Implementators of driver will say: TCP is buggy - no one should call my driver in TASK_[UN]INTERRUPTIBLE state. Who is right? If there is no specification The driver is buggy, unless the TCP maintainer can be convinced that TCP is buggy. TCP is a big chunk of code that most people use, while the driver is not so huge or critical. The TCP maintainers do not seem to be sadistic bastards hell-bent on breaking your drivers. API changes usually have a good reason. Why should block device developers read TCP/IP code? And only after reading significant amount of it they realize that they can be called in TASK_INTERRUPTIBLE state. They will most likely read other block drivers, find using schedule without setting state and use it also that way. The only way to tell developers to always set state before using schedule is to write it to specification. Mikulas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
On Mon, 19 Feb 2001 10:58:36 -0500 (EST), "Richard B. Johnson" [EMAIL PROTECTED] wrote: I was unable to use the new kernel because the drivers I need for `initrd` all had undefined symbols relating to some high memory stuff. This, in spite of the fact that I did: cp .config .. make clean make distclean cp ../.config make oldconfig make dep make bzImage make modules make modules_install FAQ: http://www.tux.org/lkml/#s8-8 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The lack of specification (was Re: [LONG RANT] Re: Linux stifles innovation... )
Mikulas Patocka [EMAIL PROTECTED] writes: Imagine that there is specification of mark_buffer_dirty. That specification says that 1. it may not block 2. it may block In case 1. implementators wouldn't change it to block in stable kernel relese because they don't want to violate the specification. In case 2. implementators of ext2 wouldn't assume that it doesn't block even if it doesn't in current implementation. Whenever the question has been asked the answer is always assume anything in the kernel outside of the current function blocks. In both cases, the bug wouldn't be created. Nope. It looks like someone made a mistake in ext2... Anytime you change implementation of syscalls, you gotta check all applications that use them ;-) Luckily not - because there is specification and you can check that syscalls conform to the specification, not apps. Not normally. The rule is that syscall don't change period. The internal kernel interface is different. It is allowed to change. As for syscall changing auditing most apps did happen when the LFS spec was put together. So you would have an implementation that would keep most apps from failing on large files. Saying "code is the specification" is not good. I'm not arguing against documentation. That is dumb. But the code is ALWAYS canonical. Not docs. Let's see: Who is right? If there is no specification Hmm. The developers should get together and pow wow when the problem is noticed. When it is finally talked out about how it should happen then the code should get fixed accordingly. It isn't about right and wrong it is about working code. Not that documenting things doesn't help. And 2.4 is going in that direction... Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Sun, 18 Feb 2001, Michael H. Warfield wrote: > On Sun, Feb 18, 2001 at 12:00:03PM -0600, Gregory S. Youngblood wrote: > > > I remember being at a computer show in Minneapolis where a small company > > was showing off this mouse that worked on a variety of surfaces without a > > ball. I'm trying to remember if the mouse was optical or used yet another > > method of functioning -- I think it was optical, though I could be > > mistaken. This was in 1992/1993. > > I think you are correct here. I seem to recall mention of some > of those earlier devices at the time of the Microsoft announcement. I > seem to also recall some of the reliability problem they had. I believe > they were extremely fussy about the surface they were on. In the demo I saw, they had about 6 sample surfaces ranging from a mirror to blue jeans. I also got to play with the mouse on the demo system and it worked very well. At the time, mice were about $25 to $35 dollars, and theirs were like $79 or $99. I remember thinking it was a cool toy, but the price difference was going to keep it from mass market potential. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
>> > On the other hand, they make excellent mice. The mouse wheel and >> > the new optical mice are truly innovative and Microsoft should be >> > commended for them. >> > >> The wheel was a nifty idea, but I've seen workstations 15 years old with >> optical mice. It wasn't MS's idea. > > I think their "innovation" was not requiring the optical cross >grid mouse pad common on Sun workstations over the years. The Microsoft >optical mouse uses variations in the surface characteristics of whatever >it's on to perform it's function. The old optical mice just used two >different colors of LED's (red and IR) and a special pad. This would >actually have to scan and track the surface below it. Don't know that >I've seen anyone do that before. I doubt Micro$oft actually did the innovation there. After all, Apple now sell an optical mouse with similar capabilities, but with an innovative overall design (almost the entire upper surface forms the button!). Optical mouse technology has been developed continuously (with a fairly low profile) since the early models found on those Sun workstations, and both Micro$oft and Apple simply put said technology into their latest products. Maybe I'm biased, but I think Apple did a better job of it. -- from: Jonathan "Chromatix" Morton mail: [EMAIL PROTECTED] (not for attachments) big-mail: [EMAIL PROTECTED] uni-mail: [EMAIL PROTECTED] The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -BEGIN GEEK CODE BLOCK- Version 3.12 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+ -END GEEK CODE BLOCK- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Sun, 18 Feb 2001, Steve VanDevender wrote: > Andre Hedrick writes: > > Those are not threats they are terms to enforce the License you agreed > > upon the very act of editing the source code that you are using in the > > kernel. > > Get it right, Andre. The mere act of editing a file that is part of a > GPL-licensed source distribution doesn't bind anyone to anything. > Anyone can download GPLed source and edit it all they want without > restriction, and they can also produce binaries for private use from > those edited sources without restriction. However, if they want to > distribute binaries derived from that source, edited or not, then the > GPL requires that they also distribute the source. > Steve, You are correct in the expanded definition and stand corrected; however, I assumed that we were already beyond the personal use issue. Because we were describing the situation of commerial issues. If this is all about personal use of the source and not redistribition for commerial purpose then why has it even used this much time of mailing list? Regards, Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
Andre Hedrick writes: > Those are not threats they are terms to enforce the License you agreed > upon the very act of editing the source code that you are using in the > kernel. Get it right, Andre. The mere act of editing a file that is part of a GPL-licensed source distribution doesn't bind anyone to anything. Anyone can download GPLed source and edit it all they want without restriction, and they can also produce binaries for private use from those edited sources without restriction. However, if they want to distribute binaries derived from that source, edited or not, then the GPL requires that they also distribute the source. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Sun, 18 Feb 2001, Henning P . Schmiedehausen wrote: > Bla, bla, bla. The usual Andre Hedrick rant about how superior you're > to all other, threats and the cited hostility of "open source advocats" > about everyone not their opinion. > > You may be a really talented software developer with a deep under- > standing of the ATA subsystem. That does not give you the right to > insult all other people that are not your opinion. Mr. Schmiedehausen, I have not insulted you, just stated the facts. Those are not threats they are terms to enforce the License you agreed upon the very act of editing the source code that you are using in the kernel. It is you that would be violating the rules, and that makes me "hostile"? What about the issue you doing the initial terms and actions to harm me by willfully disregarding the the terms and usage? Please note that "you" refers to a generalixed individual. It is not intended to imply, state, charge, or any other means of accusing. > > When you begin to learn that OpenSource is the way and that some of us > > will work with companies on an as needed bases. At this point if you came > > Andre, I do this since quite a few years. I can live quote good from > it in my small vertical market and I love using free software for the > flexibility that I get. But this does not mean, that I will never ever > touch again a program where I have no source. I do this all the time > without and ideological prejudice. We agree that user-space programs that are value add are binaries. I also use programs that I have not source code for; however, you are now parsing the difference between user-space and kernel-space. I do not have a strong point of view on user-space open-source, however, if I got the source, hey no big deal. > > Once Linux decides to adopt and support AV Streams, it will be in the best > > interrest of TiVO to work with me so that they do not have to work against > > me. > > I see the fine point of you using the word "me". Not "the Linux community". Well, I would find very few that would not define "me" as part of "the Linux community". In fact these that have been charge with the task or have voluteered to the task of maintaining a supporting a subsystem are generally viewed as the contact point for that sub-system. ./drivers/net/ Don Becker ./drivers/scsi/ Justin Gibbs ./drivers/char(serial) Ted Ts'o ./drivers/usb/ The USB gang of Matt, Johannas, etc.. ./arch/arm/ Russel King ./arch/ia64/Walt Drummond ./arch/sparc(64)David Miller ./arch/ppc Paul Mac. ./arc/m68k Geert U. The point being, there are people designated as point or leaders. If you have an issue with me, you are free to submit it to Linus, Alan, or the List. Regards, Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
In message <96o9uf$j4h$[EMAIL PROTECTED]>, "Henning P. Schmiedehausen" write s: > [EMAIL PROTECTED] (Gregory Maxwell) writes: > > >when you said commercial above) drivers for Linux, including the steaming > >pile of garbage your company ships. > > "hostile behaviour of the open source community towards people that > don't agree to their ideas". As I am a member of this community and have not exhibited such behavior to you, please include me *out* of such general condemnation. BTW, your conclusion is *false* -- +---+ | Bob Taylor Email: [EMAIL PROTECTED]| |---| | Like the ad says, at 300 dpi you can tell she's wearing a | | swimsuit. At 600 dpi you can tell it's wet. At 1200 dpi you | | can tell it's painted on. I suppose at 2400 dpi you can tell | | if the paint is giving her a rash. (So says Joshua R. Poulson)| +---+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Sun, Feb 18, 2001 at 12:00:03PM -0600, Gregory S. Youngblood wrote: > On Sun, 18 Feb 2001, Michael H. Warfield wrote: > > On Sat, Feb 17, 2001 at 09:15:08PM -0800, Ben Ford wrote: > > > > > > > > On the other hand, they make excellent mice. The mouse wheel and > > > > the new optical mice are truly innovative and Microsoft should be > > > > commended for them. > > > > > > > The wheel was a nifty idea, but I've seen workstations 15 years old with > > > optical mice. It wasn't MS's idea. > > I think their "innovation" was not requiring the optical cross > > grid mouse pad common on Sun workstations over the years. The Microsoft > > optical mouse uses variations in the surface characteristics of whatever > > it's on to perform it's function. The old optical mice just used two > > different colors of LED's (red and IR) and a special pad. This would > > actually have to scan and track the surface below it. Don't know that > > I've seen anyone do that before. > I remember being at a computer show in Minneapolis where a small company > was showing off this mouse that worked on a variety of surfaces without a > ball. I'm trying to remember if the mouse was optical or used yet another > method of functioning -- I think it was optical, though I could be > mistaken. This was in 1992/1993. I think you are correct here. I seem to recall mention of some of those earlier devices at the time of the Microsoft announcement. I seem to also recall some of the reliability problem they had. I believe they were extremely fussy about the surface they were on. > The point is, I really do not believe Microsoft made the "leap" to provide > opitcal mice without the need of the mousepad grid. Their "innovation" was > in marketing it on a wide scale though. I would agree there. They did something to improve the reliability on a wider variety of surface textures, though. Is that innovation or merely getting a good idea, that's been around, to finally work? Don't know. I didn't find the idea itself particularly innovative. The fact that they did get it to work reliable is something to be said. The marketing is a given, of course. Particularly in the face of the preception in some camps that this style of optical mouse was unreliable. > I could be mistaken - if so then let's give them their credit - but I have > a hard time believing it was their idea without some serious proof. Agreed. Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Sun, 18 Feb 2001, Gregory S. Youngblood wrote: > I remember being at a computer show in Minneapolis where a small company > was showing off this mouse that worked on a variety of surfaces without a > ball. I'm trying to remember if the mouse was optical or used yet another > method of functioning -- I think it was optical, though I could be > mistaken. This was in 1992/1993. > > The point is, I really do not believe Microsoft made the "leap" to provide > opitcal mice without the need of the mousepad grid. Their "innovation" was > in marketing it on a wide scale though. I believe I read about an optical mouse that worked on any surface by tracking surface constrast movement in an old issue of Byte. I think it was an Xerox invention, but my memory may be off. Peter -- Peter Svensson ! Pgp key available by finger, fingerprint: <[EMAIL PROTECTED]>! 8A E9 20 98 C1 FF 43 E3 07 FD B9 0A 80 72 70 AF <[EMAIL PROTECTED]> ! Remember, Luke, your source will be with you... always... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Sun, Feb 18, 2001 at 09:50:17AM -0800, Andre Hedrick wrote: [...] > If you do not like that rule, LEAVE! [...] > if I catch you abusing the privildge of use of my work, I will > pursue you in terms defined as actionable. [...] > And you do not have the knowledge or authority to comment on this subject > where "I do". [...] Bla, bla, bla. The usual Andre Hedrick rant about how superior you're to all other, threats and the cited hostility of "open source advocats" about everyone not their opinion. You may be a really talented software developer with a deep under- standing of the ATA subsystem. That does not give you the right to insult all other people that are not your opinion. > When you begin to learn that OpenSource is the way and that some of us > will work with companies on an as needed bases. At this point if you came Andre, I do this since quite a few years. I can live quote good from it in my small vertical market and I love using free software for the flexibility that I get. But this does not mean, that I will never ever touch again a program where I have no source. I do this all the time without and ideological prejudice. > Once Linux decides to adopt and support AV Streams, it will be in the best > interrest of TiVO to work with me so that they do not have to work against > me. I see the fine point of you using the word "me". Not "the Linux community". Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] D-91054 Buckenhof Fax.: 09131 / 50654-20 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Sun, 18 Feb 2001, Michael H. Warfield wrote: > On Sat, Feb 17, 2001 at 09:15:08PM -0800, Ben Ford wrote: > > > > > > On the other hand, they make excellent mice. The mouse wheel and > > > the new optical mice are truly innovative and Microsoft should be > > > commended for them. > > > > > The wheel was a nifty idea, but I've seen workstations 15 years old with > > optical mice. It wasn't MS's idea. > > I think their "innovation" was not requiring the optical cross > grid mouse pad common on Sun workstations over the years. The Microsoft > optical mouse uses variations in the surface characteristics of whatever > it's on to perform it's function. The old optical mice just used two > different colors of LED's (red and IR) and a special pad. This would > actually have to scan and track the surface below it. Don't know that > I've seen anyone do that before. I remember being at a computer show in Minneapolis where a small company was showing off this mouse that worked on a variety of surfaces without a ball. I'm trying to remember if the mouse was optical or used yet another method of functioning -- I think it was optical, though I could be mistaken. This was in 1992/1993. The point is, I really do not believe Microsoft made the "leap" to provide opitcal mice without the need of the mousepad grid. Their "innovation" was in marketing it on a wide scale though. I could be mistaken - if so then let's give them their credit - but I have a hard time believing it was their idea without some serious proof. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Sun, 18 Feb 2001, Henning P. Schmiedehausen wrote: > >- Innovative new hardware devices are more likely to be based on > >Linux than any Microsoft OS. For example, the TiVO, the coolest > >improvement to television since the VCR. Henning, When you begin to learn that OpenSource is the way and that some of us will work with companies on an as needed bases. At this point if you came to me I would put you through the same grinder that I do every other use of the ATA/ATAPI subsystem for commerial purpose. I have the duty and right to protect that which was entrusted to me and that which I create. If you do not like that rule, LEAVE! Henning, if I catch you abusing the privildge of use of my work, I will pursue you in terms defined as actionable. It is not a game. > Because it is cheaper to use. Linux has no license fee. That's what > the TiVO vendor cares about. Henning, And you do not have the knowledge or authority to comment on this subject where "I do". Maybe it you would bother the take you shoe out of your mouth one more time than you put it in you could not sound more like a fool, today. TiVO came to Linux and Linux went back to TiVO in a working relationship. ** Date: Mon, 22 May 2000 14:10:42 -0700 From: Mike Klar <[EMAIL PROTECTED]> To: Andre Hedrick <[EMAIL PROTECTED]> Cc: Alan Cox <[EMAIL PROTECTED]> Subject: Re: non-PCI IDE DMA in Linux IDE driver The 2.3-based tree is not in a releaseable state at his point, and doesn't have the AV stuff in it yet, anyway. The 2.1-based code (which is what our shipping units currently use) is available, I can inquire into the release mechanism for that if you're interested. Mike Klar TiVo Inc. Andre Hedrick wrote: > > Greetings Mike, > > Can I see the source tree under the rules of GPL? > I know that you are doing AV streams and that is the hot topic at t13. > > Cheers, > > Andre Hedrick > The Linux ATA/IDE guy ** Once Linux decides to adopt and support AV Streams, it will be in the best interrest of TiVO to work with me so that they do not have to work against me. This is how you work with industry. You load share the work. Regards, Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Sat, Feb 17, 2001 at 09:15:08PM -0800, Ben Ford wrote: > > > > On the other hand, they make excellent mice. The mouse wheel and > > the new optical mice are truly innovative and Microsoft should be > > commended for them. > > > The wheel was a nifty idea, but I've seen workstations 15 years old with > optical mice. It wasn't MS's idea. I think their "innovation" was not requiring the optical cross grid mouse pad common on Sun workstations over the years. The Microsoft optical mouse uses variations in the surface characteristics of whatever it's on to perform it's function. The old optical mice just used two different colors of LED's (red and IR) and a special pad. This would actually have to scan and track the surface below it. Don't know that I've seen anyone do that before. > -b Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation... [way O.T.]
"Henning P. Schmiedehausen" wrote: > > [EMAIL PROTECTED] (Michael H. Warfield) writes: > > > Excuse me? A 1 billion dolar investment in Linux is not > >supporting it? > > On their own hardware. Which is really the point and they won't be the only ones. If IBM wants to attract and keep customers on their hardware, they will ensure that the software and Linux drivers for it run very well, if Linux is going to be their main play to sell hardware. The same will hold true for other hardware manufacturers, including those the make video cards, modems, etc, as Linux grows in the marketplace. Linux will not displace the software industry, it will eventually displace the commodity portions of it. This is what has Microsoft afraid, since commodity software is their real play, games and specialty software isn't. The fact is, the majority of software is written in-house and through contracted professional services work, not off the shelf. Linux will make that side of the industry even more valuable, it will empower the developers and the businesses that hire them to do even more than they can today. It will empower them to do it right. As for games and similar specialties, they aren't going anywhere. It costs far too much money to produce a high-end game and the open source world either can't afford it or can't produce it fast enough to support the market. So Allchin's flag waving is simple posturing. Microsoft may become irrelevant, but the software industry won't. John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
Hi. Thought I'd toss my 0.02sek into the discussion. > > > objective, arent we? > >Nope. Are you claiming to be? > > > > > For example, if there were six different companies that marketed ethernet > > > drivers for the eepro100, you'd have a choice of which one to buy..perhaps > >... Rant deleted > > > >I had a problem with eepro100. > >It was fixed same night cause I had the source. > >Don't even try to compare with MickyS**t. > > good commercial drivers dont need fixing. another point. You are arguing > that having source is required to fix crappy code, which i agree with. Ok, tell that to my SBLive that absolutely loves jumping and jittering on my SMP box under Win2k. Creative have been notified. Ever since they released their first driver for it... So if they would've had their driver out in the open I'm sure SOMEONE, if not me, would've squashed the bug already. So you're right, good commercial drivers don't need fixing. Also, good open-source drivers don't need fixing. Good drivers don't need fixing! Of course they don't! But crap coding is crap coding no matter what license/distribution form you put it under, be it open source, closed source or whatnot. // Stefan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
Henning P. Schmiedehausen writes: > The matter with me is: "Vendors AAA ships its hardware product with a > driver for i386/Linux". The driver may be closed source, but at least > there _is_ a driver. Russell now says: "This is bad, because I can't use > the driver for my ARM box. So the vendor should ship no driver at > all. This is better than a i386-only driver". I thank you again to NOT put words in my mouth that I didn't say. > If the hardware is "NOT SUPPORTED BESIDES LINUX/i386" and you have an > ARM, the solution is simple: DON'T BUY IT. VOTE WITH YOUR MONEY. If > Linux/ARM starts becoming a sigificant part of the market share, > vendor AAA will either lose to vendor BBB or release a driver for ARM. When there is no vendor BBB to supply such a driver? This is my point. > And Russell can buy a vendor supported driver for Linux/ARM. Not possible. There are none at the present time, and have been none over the past 8 years for ARM Linux. Only recently, because of the hard work put into ARM Linux by the ARM community as a whole have the ARM vendors started to take Linux seriously. There are now around 50 or so different ARM machines that can run Linux, but most of them are not of a PC form factor. All of them are committed to open source. None of them write printer drivers. In fact, for a vast majority of them a printer driver would not make sense. > And I actively _DON'T_ want _YOU_ to decide what _I_ want. I don't want to tell you want you want either. Neither do I want you putting words into my mouth that I did not say. IMHO if you carry on in this light, and you have been shouted down for doing so, I am in full support of those who shouted you down, whether they be in the open source, closed source or whatever arena you care to think of. As a mark of good nature, I will dismiss all of your mistakes thus far. However, if you carry on mis-representing and mis-quoting me in this way, then I shall have to demand a full public appology, and demand that you decist in doing so. > I WANT THE CHOICE. If I have no choice, I buy the product on another > platform. That is your right. No one is taking that away from you. However, I want the choice to develop what I want, how I want, and allow other people to contribute to this development. If you would like to carry this discussion on in private, then I'm quite willing to accept. However, it is off-topic for the Linux-Kernel mailing list. If you wish to keep this public, then as before, please don't reply directly to me or CC: me. Thanks. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
