Re: [LONG RANT] Re: Linux stifles innovation...

[Brian May]

> "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...

[Brian May]

 "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... )

[Eric W. Biederman]

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...

[Keith Owens]

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]

> 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... )

[Albert D. Cahalan]

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...

[Andre Hedrick]

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... )

[Mikulas Patocka]

> > > > 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...

[Alan Cox]

> 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...

[Jeff Garzik]

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...

[Jeff Garzik]

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...

[Alan Cox]

> 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...

[Paul Jakma]

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...

[Richard B. Johnson]

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...

[Mikulas Patocka]

> > 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...

[Jeff Garzik]

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...

[Jes Sorensen]

> "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...

[David Howells]

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...

[Werner Almesberger]

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...

[Nicholas Knight]

- 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...

[Nicholas Knight]

- 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...

[Henning P . Schmiedehausen]

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...

[Werner Almesberger]

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...

[Henning P . Schmiedehausen]

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...

[Jeff Garzik]

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...

[David Lang]

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...

[Nicholas Knight]

- 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...

[Jeff Garzik]

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...

[Werner Almesberger]

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...

[Helge Hafting]

"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...

[Helge Hafting]

"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...

[Werner Almesberger]

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...

[Jeff Garzik]

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...

[Nicholas Knight]

- 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...

[David Lang]

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...

[Jeff Garzik]

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...

[Henning P . Schmiedehausen]

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...

[Werner Almesberger]

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...

[Henning P . Schmiedehausen]

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...

[Nicholas Knight]

- 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...

[Werner Almesberger]

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...

[David Howells]

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...

[Jes Sorensen]

 "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...

[Jeff Garzik]

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...

[Mikulas Patocka]

  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...

[Richard B. Johnson]

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...

[Paul Jakma]

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...

[Alan Cox]

 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...

[Jeff Garzik]

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...

[Jeff Garzik]

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...

[Alan Cox]

 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... )

[Mikulas Patocka]

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...

[Andre Hedrick]

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... )

[Albert D. Cahalan]

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... )

[Mikulas Patocka]

 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...

[Keith Owens]

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... )

[Eric W. Biederman]

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...

[Russell King]

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/

Re: [LONG RANT] Re: Linux stifles innovation...

[Henning P. Schmiedehausen]

I wrote:

>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". 

Russell told me, that this is not what he said. I seem to have
over-interpreted his statements. I apologize for that.

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...

[Henning P. Schmiedehausen]

[EMAIL PROTECTED] (Felix von Leitner) writes:

>Thus spake Henning P . Schmiedehausen ([EMAIL PROTECTED]):
>> "If a company does not write a driver which works on all hardware
>>  platforms in all cases and gives us the source, then it is better,
>>  that the company writes no drivers at all."

>> "If I can't force a company to write a driver for everyone, then I
>>  don't want to write them any driver at all."

>> IMHO you're like a spoiled kid: "If I can't have it, noone should have it".

>Henning, what is the matter with you?

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 say "I'm happy that there is _ANY_ driver at all. Because the vendor
has recognized the importance of Linux at least on i386. And if they
did this and they see, that they _can_ get market share, maybe they
will start thinking about releasing for other architectures, too. Or
even release the source to their driver".

And if someone wants a driver for the hardware of vendor AAA on ARM
and vendor AAA does decide _not_ to release the product for ARM, it is
their right to do so. 

And Russell may still approach AAA to release an ARM driver, too. Or
buy a product from BBB, which does support ARM with either a
vendor-supported close source driver or an open source driver.

Someone approached Legato to release a MIPS/Linux version of their
backup client. Maybe they even paid for the port. And now, everyone
can get this client from the Legato website. It is still closed
source, but still, everyone that has a MIPS/Linux box benefited from
this. 

>I bought the hardware.  Why should I pay for the driver?

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.

>Please state your intentions.  Why would you want to split the Linux
>user base into people who pay companies to screw them (I get a driver
>for hardware I already paid for, but the driver will work with exactly
>one kernel version on one hardware) and people who think they deserve
>support when they buy hardware?

If you buy a hardware and on the box is stated "Supported on Windows,
MacOS and Linux/i386" and you have none of these platforms, why buy
it? If you buy it and then start complaining "it is not vendor-
supported on Linux/ARM", it is your fault and not the fault of the
vendor. If the vendor puts a second box next to the hardware box on
the shelves, which just contains a CD-ROM with a binary only driver
for Linux/ARM and sells this box for $99, it's their right to do
so. And Russell can buy a vendor supported driver for Linux/ARM.

>Why do we even have to discuss drivers?
>A company that actively hinders developing a good driver with patents,
>NDAs or other legal crap does not deserve my money.  If you throw your
>money at such people, you deserve everything you get.

That's exactly my point. Nice to see, that we agree. ;-) See
above. Vote with your money. But IMHO it's better to get
vendor-supported drivers for Linux/i386, than no driver at
all. Because if these drivers do not work, I _can_ call the company
and complain.

And I actively _DON'T_ want _YOU_ to decide what _I_ want. If I can
get a driver for the hardware XXX that I need for a project and vendor
AAA sells me a driver for this product on Linux only for a certain
platform, kernel version and distribution, it is _MY_ _PERSONAL_
_DECISION_ to still buy this driver or not. I don't want anyone to
tell me "you must not do this, because it's bad". If it's bad or not,
please let me decide. I'm old enough to decide for myself.

I WANT THE CHOICE. If I have no choice, I buy the product on another
platform.

And you can be sure, I will not come running to LKM to complain and
demand support.

And you can even sue if you're in Germany and the driver does not work
as stated on the box("Erfüllung zugesicherter Eigenschaften, Nach-
besserung oder Wandlung").

Regards
Henning

P.S.: I consider "configuring a mailer so that it does not accept mail
from a sender" neither good style nor "das letzte Wort" in a discussion. 
It is IMHO a sign of weakness and inability to discuss on an objective
base. It is more like "I don't like your opinion, so I censor you".
Discussion, Microsoft-style.

-- 
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

Re: [LONG RANT] Re: Linux stifles innovation...

[Russell King]

*** Please don't reply directly to me, either via CC: or To:.
*** I'll pick up any replies via linux-kernel.  Thanks.

Henning P . Schmiedehausen writes:
> Maybe not. But you can use this print engine API to pay anyone to
> write a driver for you. What you just said, is exactly my point. You
> said:
> 
> "If a company does not write a driver which works on all hardware
>  platforms in all cases and gives us the source, then it is better,
>  that the company writes no drivers at all."

That is not what I said.  I said the opposite - "If I company writes a
closed source driver, it will be x86 specific and will ignore the rest
of the Linux community.  However, that company is free to write such
a driver; I won't stop them because I can't stop them."

> "If I can't force a company to write a driver for everyone, then I
>  don't want to write them any driver at all."

Please restate - this sentence does not make sense at all.  No one is
forcing anyone to write drivers.

> IMHO you're like a spoiled kid: "If I can't have it, noone should have it".

Please, don't decend into flame wars.

> If you need a printer driver for the ARM, you're able to approach the
> company XXX and either pay for an ARM specific driver (and they will
> listen to you because they already have made a driver for another
> Linux platform, learned that they can make money with Linux software
> and have experience with driver(s) for Linux. And it will be just a
> recompile most of the time).

Oh, and how many users can afford to pay $1s for a company to develop
such a driver?  Yes, the driver will cost lots of money because the
company has to put effort into it, and they believe that they won't
see a reasonable return on it.  Also, since the company has its name
to think about, it will want to test it to some degree (I'll mention
here that some drivers seem on MS Windows seem to be untested), which
again adds to the cost.  What you end up with is a price structure
such as:

1. Cost of driver for x86 platform for device x = $50
2. Cost of driver for other platforms for same device x = $1

Now, can you see an individual person finding $1 to pay some company
to get the driver?  If you try to, then you're stark raving mad, and
they'll tell you to go away.

Getting closed source software ported by companies is an extremely
expensive business which no user can afford.

There are things that I would really like to say about closed source
software at this point, which will come as no surprise to anyone, but
unfortunately I would get sued to buggery for doing so.  Note however
that they don't relate to the "open source" argument, but to personal
experience of a sector of the software industry.

> We're talking about a driver. If Company XX won't sell it to you for
> your architecture, it's their right to do so. There is software that
> I've written that you might want to have, too. If I chose not to sell
> it to you, what do you do? You can say "company XX sucks" and buy an
> equal product with an ARM driver from YY which listens to you. _THAT_
> is IMHO open. Not forcing everyone to comply with your ideology.

I'm sorry, I think you misinterpreted what I said.  First point - agreed.
Second point - if you choose not to sell it to me, and I have your
hardware product, I will attempt to find out how to make this hardware
product work on ARM, and open source the driver that I come up with.
If I do not have your hardware product, and there are alternatives that
do have usable drivers, then I'll buy theirs instead.

Once the open source driver is out there, then it is a fact of human
nature that people will go for the open source driver.  If the open
source driver is crap, then they have a few choices:

1. berate me and my driver, just like people berate companies
2. improve on the open source driver to make it better
3. buy your driver because its soo much better

Note that at no point have I forced you to write open source drivers here.

> Can you get a Legato Networker Client for Linux-ARM? Can you get one for
> Linux-MIPS? Why? Because someone payed for the port.

Not AFAIK.

> Because IMHO some companies shy away from the aggressive and sometime
> openly hostile behaviour of the Open Source community ("If you don't
> support your application on Linux/SPARC with an B/W framebuffer, you
> suck. Go away") towards commercial companies.  ("If you don't support
> Gnome 1.0 but just KDE 2.1, you suck. Go away"). And billg laughs and
> just points the confused companies towards the "stable" and "easy to
> use" M$ OS.

I'm sorry, I've never approached a company, not even Netscape and said
"you don't support ARM, you suck, go away".  About the only question
that would get asked is "Can you supply a port to ARM", and the answer
will be either "what's ARM?" or "No".  There won't even be a price tag
fixed on it.

> In your opinion, it is better, that I can't get some programs at all
> than paying money for them.

What you're saying here isn't clear. 

Re: [LONG RANT] Re: Linux stifles innovation...

[Russell King]

*** Please don't reply directly to me, either via CC: or To:.
*** I'll pick up any replies via linux-kernel.  Thanks.

Henning P . Schmiedehausen writes:
 Maybe not. But you can use this print engine API to pay anyone to
 write a driver for you. What you just said, is exactly my point. You
 said:
 
 "If a company does not write a driver which works on all hardware
  platforms in all cases and gives us the source, then it is better,
  that the company writes no drivers at all."

That is not what I said.  I said the opposite - "If I company writes a
closed source driver, it will be x86 specific and will ignore the rest
of the Linux community.  However, that company is free to write such
a driver; I won't stop them because I can't stop them."

 "If I can't force a company to write a driver for everyone, then I
  don't want to write them any driver at all."

Please restate - this sentence does not make sense at all.  No one is
forcing anyone to write drivers.

 IMHO you're like a spoiled kid: "If I can't have it, noone should have it".

Please, don't decend into flame wars.

 If you need a printer driver for the ARM, you're able to approach the
 company XXX and either pay for an ARM specific driver (and they will
 listen to you because they already have made a driver for another
 Linux platform, learned that they can make money with Linux software
 and have experience with driver(s) for Linux. And it will be just a
 recompile most of the time).

Oh, and how many users can afford to pay $1s for a company to develop
such a driver?  Yes, the driver will cost lots of money because the
company has to put effort into it, and they believe that they won't
see a reasonable return on it.  Also, since the company has its name
to think about, it will want to test it to some degree (I'll mention
here that some drivers seem on MS Windows seem to be untested), which
again adds to the cost.  What you end up with is a price structure
such as:

1. Cost of driver for x86 platform for device x = $50
2. Cost of driver for other platforms for same device x = $1

Now, can you see an individual person finding $1 to pay some company
to get the driver?  If you try to, then you're stark raving mad, and
they'll tell you to go away.

Getting closed source software ported by companies is an extremely
expensive business which no user can afford.

There are things that I would really like to say about closed source
software at this point, which will come as no surprise to anyone, but
unfortunately I would get sued to buggery for doing so.  Note however
that they don't relate to the "open source" argument, but to personal
experience of a sector of the software industry.

 We're talking about a driver. If Company XX won't sell it to you for
 your architecture, it's their right to do so. There is software that
 I've written that you might want to have, too. If I chose not to sell
 it to you, what do you do? You can say "company XX sucks" and buy an
 equal product with an ARM driver from YY which listens to you. _THAT_
 is IMHO open. Not forcing everyone to comply with your ideology.

I'm sorry, I think you misinterpreted what I said.  First point - agreed.
Second point - if you choose not to sell it to me, and I have your
hardware product, I will attempt to find out how to make this hardware
product work on ARM, and open source the driver that I come up with.
If I do not have your hardware product, and there are alternatives that
do have usable drivers, then I'll buy theirs instead.

Once the open source driver is out there, then it is a fact of human
nature that people will go for the open source driver.  If the open
source driver is crap, then they have a few choices:

1. berate me and my driver, just like people berate companies
2. improve on the open source driver to make it better
3. buy your driver because its soo much better

Note that at no point have I forced you to write open source drivers here.

 Can you get a Legato Networker Client for Linux-ARM? Can you get one for
 Linux-MIPS? Why? Because someone payed for the port.

Not AFAIK.

 Because IMHO some companies shy away from the aggressive and sometime
 openly hostile behaviour of the Open Source community ("If you don't
 support your application on Linux/SPARC with an B/W framebuffer, you
 suck. Go away") towards commercial companies.  ("If you don't support
 Gnome 1.0 but just KDE 2.1, you suck. Go away"). And billg laughs and
 just points the confused companies towards the "stable" and "easy to
 use" M$ OS.

I'm sorry, I've never approached a company, not even Netscape and said
"you don't support ARM, you suck, go away".  About the only question
that would get asked is "Can you supply a port to ARM", and the answer
will be either "what's ARM?" or "No".  There won't even be a price tag
fixed on it.

 In your opinion, it is better, that I can't get some programs at all
 than paying money for them.

What you're saying here isn't clear.  Can you please restate this 

Re: [LONG RANT] Re: Linux stifles innovation...

[Henning P. Schmiedehausen]

[EMAIL PROTECTED] (Felix von Leitner) writes:

Thus spake Henning P . Schmiedehausen ([EMAIL PROTECTED]):
 "If a company does not write a driver which works on all hardware
  platforms in all cases and gives us the source, then it is better,
  that the company writes no drivers at all."

 "If I can't force a company to write a driver for everyone, then I
  don't want to write them any driver at all."

 IMHO you're like a spoiled kid: "If I can't have it, noone should have it".

Henning, what is the matter with you?

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 say "I'm happy that there is _ANY_ driver at all. Because the vendor
has recognized the importance of Linux at least on i386. And if they
did this and they see, that they _can_ get market share, maybe they
will start thinking about releasing for other architectures, too. Or
even release the source to their driver".

And if someone wants a driver for the hardware of vendor AAA on ARM
and vendor AAA does decide _not_ to release the product for ARM, it is
their right to do so. 

And Russell may still approach AAA to release an ARM driver, too. Or
buy a product from BBB, which does support ARM with either a
vendor-supported close source driver or an open source driver.

Someone approached Legato to release a MIPS/Linux version of their
backup client. Maybe they even paid for the port. And now, everyone
can get this client from the Legato website. It is still closed
source, but still, everyone that has a MIPS/Linux box benefited from
this. 

I bought the hardware.  Why should I pay for the driver?

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.

Please state your intentions.  Why would you want to split the Linux
user base into people who pay companies to screw them (I get a driver
for hardware I already paid for, but the driver will work with exactly
one kernel version on one hardware) and people who think they deserve
support when they buy hardware?

If you buy a hardware and on the box is stated "Supported on Windows,
MacOS and Linux/i386" and you have none of these platforms, why buy
it? If you buy it and then start complaining "it is not vendor-
supported on Linux/ARM", it is your fault and not the fault of the
vendor. If the vendor puts a second box next to the hardware box on
the shelves, which just contains a CD-ROM with a binary only driver
for Linux/ARM and sells this box for $99, it's their right to do
so. And Russell can buy a vendor supported driver for Linux/ARM.

Why do we even have to discuss drivers?
A company that actively hinders developing a good driver with patents,
NDAs or other legal crap does not deserve my money.  If you throw your
money at such people, you deserve everything you get.

That's exactly my point. Nice to see, that we agree. ;-) See
above. Vote with your money. But IMHO it's better to get
vendor-supported drivers for Linux/i386, than no driver at
all. Because if these drivers do not work, I _can_ call the company
and complain.

And I actively _DON'T_ want _YOU_ to decide what _I_ want. If I can
get a driver for the hardware XXX that I need for a project and vendor
AAA sells me a driver for this product on Linux only for a certain
platform, kernel version and distribution, it is _MY_ _PERSONAL_
_DECISION_ to still buy this driver or not. I don't want anyone to
tell me "you must not do this, because it's bad". If it's bad or not,
please let me decide. I'm old enough to decide for myself.

I WANT THE CHOICE. If I have no choice, I buy the product on another
platform.

And you can be sure, I will not come running to LKM to complain and
demand support.

And you can even sue if you're in Germany and the driver does not work
as stated on the box("Erfllung zugesicherter Eigenschaften, Nach-
besserung oder Wandlung").

Regards
Henning

P.S.: I consider "configuring a mailer so that it does not accept mail
from a sender" neither good style nor "das letzte Wort" in a discussion. 
It is IMHO a sign of weakness and inability to discuss on an objective
base. It is more like "I don't like your opinion, so I censor you".
Discussion, Microsoft-style.

-- 
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 

Re: [LONG RANT] Re: Linux stifles innovation...

[Henning P. Schmiedehausen]

I wrote:

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". 

Russell told me, that this is not what he said. I seem to have
over-interpreted his statements. I apologize for that.

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...

[Russell King]

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/

Re: [LONG RANT] Re: Linux stifles innovation...

[Ben Ford]

Jacob Luna Lundberg wrote:

>> Speaking as a Linux _USER_, if this happens, can I get said print
>> engine working on my ARM machines with these closed source drivers?
>> Can Alpha users get this print system working?  Can Sparc uses
>> get it working?  What?  I can't?  They can't?  Well, its no good to
>> me nor them.  You've just made the system x86 specific.  Well done,
>> thats a step backwards, not forwards.
> 
> 
> Just out of curiosity, why can't the specification be along the lines of a
> vendor data file saying ``if you want the printer to do x then say y'' and
> ``if the printer says x then it means y''.  That ought to add a lot of
> functionality right there.  Sure there are evil winprinters that this
> wouldn't be enough for but it would be hardware independant, yes?

isn't that what windows *.INF files do?
(don't flame me  I'm not sure about it)

-b

-
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...

[Peter Samuelson]

[Jacob Luna Lundberg]
> Just out of curiosity, why can't the specification be along the lines
> of a vendor data file saying ``if you want the printer to do x then
> say y'' and ``if the printer says x then it means y''.  That ought to
> add a lot of functionality right there.

Think about it.  A spec based on what you say would be quite easy to
reverse-compile, no?  In which case, obviously the company's IP, such
as it is, is not protected.  In which case, why not just do an open
source driver and be done with it?

The concept of architecture-independent device drivers goes back to
Open Firmware.  But in that case, there is a practical consideration:
the drivers couldn't be compiled down to machine language since they
had to be accessible as-is at boot time.

Peter
-
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...

[Felix von Leitner]

Thus spake Henning P . Schmiedehausen ([EMAIL PROTECTED]):
> "If a company does not write a driver which works on all hardware
>  platforms in all cases and gives us the source, then it is better,
>  that the company writes no drivers at all."

> "If I can't force a company to write a driver for everyone, then I
>  don't want to write them any driver at all."

> IMHO you're like a spoiled kid: "If I can't have it, noone should have it".

Henning, what is the matter with you?

I bought the hardware.  Why should I pay for the driver?
Not even on Windows you pay extra for a driver!

Please state your intentions.  Why would you want to split the Linux
user base into people who pay companies to screw them (I get a driver
for hardware I already paid for, but the driver will work with exactly
one kernel version on one hardware) and people who think they deserve
support when they buy hardware?

Why do we even have to discuss drivers?
A company that actively hinders developing a good driver with patents,
NDAs or other legal crap does not deserve my money.  If you throw your
money at such people, you deserve everything you get.

Felix
-
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...

[Jacob Luna Lundberg]

> Speaking as a Linux _USER_, if this happens, can I get said print
> engine working on my ARM machines with these closed source drivers?
> Can Alpha users get this print system working?  Can Sparc uses
> get it working?  What?  I can't?  They can't?  Well, its no good to
> me nor them.  You've just made the system x86 specific.  Well done,
> thats a step backwards, not forwards.

Just out of curiosity, why can't the specification be along the lines of a
vendor data file saying ``if you want the printer to do x then say y'' and
``if the printer says x then it means y''.  That ought to add a lot of
functionality right there.  Sure there are evil winprinters that this
wouldn't be enough for but it would be hardware independant, yes?

Or alternatively what about getting vendors to release their source to a
middleman as a trade secret?  The middleman could then release binaries
for the various arches...  Distasteful, but I'd love to be able to use
*all* the features of my Lexmark OptraColor 45...  ;)

-Jacob

-
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]

On Sat, Feb 17, 2001 at 01:37:58PM +, Russell King wrote:

> Henning P. Schmiedehausen writes:
> > But at least I would be happy if there would be a printing
> > engine that is entirely open source and all the printer vendors can
> > write a small, closed source stub that drives their printer over
> > parallel port, ethernet or USB and give us all the features, that the
> > Linux _USERS_ (and these are the people that count) want.
> 
> Speaking as a Linux _USER_, if this happens, can I get said print
> engine working on my ARM machines with these closed source drivers?
>
> Can Alpha users get this print system working?  Can Sparc uses
> get it working?  What?  I can't?  They can't?  Well, its no good to
> me nor them.  

Maybe not. But you can use this print engine API to pay anyone to
write a driver for you. What you just said, is exactly my point. You
said:

"If a company does not write a driver which works on all hardware
 platforms in all cases and gives us the source, then it is better,
 that the company writes no drivers at all."

"If I can't force a company to write a driver for everyone, then I
 don't want to write them any driver at all."

IMHO you're like a spoiled kid: "If I can't have it, noone should have it".

> You've just made the system x86 specific.  Well done, thats a step
> backwards, not forwards.

No. Some Linux users got a driver that works as well as the drivers
for another OS. This is good for Linux. And all Linux users and
developers got an open, stable API, which is supported by big printer
vendors and enables everyone to write good drivers.

If you need a printer driver for the ARM, you're able to approach the
company XXX and either pay for an ARM specific driver (and they will
listen to you because they already have made a driver for another
Linux platform, learned that they can make money with Linux software
and have experience with driver(s) for Linux. And it will be just a
recompile most of the time).

> Ah, golly, I'll just have to throw my ARM machines away because
> we have some critical parts of the system which are closed source.

We're talking about a driver. If Company XX won't sell it to you for
your architecture, it's their right to do so. There is software that
I've written that you might want to have, too. If I chose not to sell
it to you, what do you do? You can say "company XX sucks" and buy an
equal product with an ARM driver from YY which listens to you. _THAT_
is IMHO open. Not forcing everyone to comply with your ideology.

> > But even if there is such an engine written for Gnome or KDE, some
> > really ingenious "free software advocate" will slap a "must not be
> > used with any kind of non-GPL driver" on it...
> 
> Good.  I build the stuff to work on my ARM machines.

Can you get a Legato Networker Client for Linux-ARM? Can you get one for
Linux-MIPS? Why? Because someone payed for the port.

> They don't work on ARM though, do they?  Gee, I guess ARM Ltd ought to
> stop my contract because what use is an ARM kernel without everything
> else to go with it?
> 
> For me, closed source is _REALLY_ bad news.  _EXTREMELY_ bad news.
> It 100% prevents me from doing stuff.

No. It means, that for some programs, in order to have them, you have
to pay. That is fine. There ain't no such thing as a free lunch. You
may, of course, chose not to pay, but then you may not be able to use
a certain program.

Look, I'm willing to pay money for the whole M$ Office Suite on
Linux. Yes.  I would give billg gladly a big chunk of my money to get
this application suite on Linux. Not a copy or a "just almost like M$
Office". But the real thing. The real "M$ Office 2k" suite for Linux.

Can I?  No. Because M$ chose not to offer its product for Linux. Bad
for me. It means, that I can not get parts of my work done on Linux.
Can I buy AutoCAD? Photoshop? Quicken? Outlook? Visio? Not look alikes
or clones or "almost as good as". But the real thing with the same
support as on Windows. I can for the Mac. Why can't I for Linux?

Because IMHO some companies shy away from the aggressive and sometime
openly hostile behaviour of the Open Source community ("If you don't
support your application on Linux/SPARC with an B/W framebuffer, you
suck. Go away") towards commercial companies.  ("If you don't support
Gnome 1.0 but just KDE 2.1, you suck. Go away"). And billg laughs and
just points the confused companies towards the "stable" and "easy to
use" M$ OS.

And the volatile APIs which are immature in some points (Font handling. 
Printer support. Color handling. Same things all the time. But displaying 
the results of your work and printing them onto paper is for many
people the most important thing. And frankly, Linux sucks here).

In your opinion, it is better, that I can't get some programs at all
than paying money for them.

In my opinion, I prefer to get it at least for i386/Linux than not to
get them at all. Because if I can't get them for i386/Linux, I must
get them for 

Re: [LONG RANT] Re: Linux stifles innovation...

[Jonathan Morton]

>Henning P. Schmiedehausen writes:
>> But at least I would be happy if there would be a printing
>> engine that is entirely open source and all the printer vendors can
>> write a small, closed source stub that drives their printer over
>> parallel port, ethernet or USB and give us all the features, that the
>> Linux _USERS_ (and these are the people that count) want.
>
>Speaking as a Linux _USER_, if this happens, can I get said print
>engine working on my ARM machines with these closed source drivers?
>Can Alpha users get this print system working?  Can Sparc uses
>get it working?  What?  I can't?  They can't?  Well, its no good to
>me nor them.  You've just made the system x86 specific.  Well done,
>thats a step backwards, not forwards.
>
>Oh please nice big corporation, can you please build said closed
>source stub for ARM?  No?  Why?  You don't see the point?
>
>Ah, golly, I'll just have to throw my ARM machines away because
>we have some critical parts of the system which are closed source.



I have similar, though less acute, problems with PowerPC.  Because it's
seen as a "smaller market", less work is done on it and less closed-source
software makes it's way onto it.  Try to download a PowerPC version of
Netscape (4.x, not 6) - all you'll find are the MacOS versions, nothing for
Linux.  Fortunately, distro makers manage to have extracted one for
themselves.

As for 680x0...  well I'd love to have been able to use my old Quadra 840av
as a router/firewall/server, but nobody knows how the *hardware* works well
enough to get either Linux or NetBSD working properly on it.  So I wind up
using it as an IRC bot and scanner station, using the old, now unsupported
MacOS 8.1, which will never have it's bugs fixed because Apple considers
ancient hardware not worth it's while.  Fortunately it works well enough
for the job, and I don't have to complain too loudly about it, which is
more than I could say about any (especially recent) Micro$oft product.

Even on x86 I have problems.  I just bought ATI's flashiest new graphics
card - the All-in-Wonder Radeon - and installed it into my "workstation"
PC, which just happens to also have a Win95 partition.  With a little
fiddling, I get the 2D and 3D output features running smoothly, if not yet
optimally, under the latest version of XFree86 and the Linux kernel.  Much
the same goes for the Windows drivers.

Then I start looking for the software to drive the "extra" features, such
as the TV/video input/capture stuff, which is what distinguishes the
All-in-Wonder from the regular Radeon (and which makes it cost 2x as much).
I'll probably eventually find the right drivers for Linux - I know they
exist, if in uncompleted form - but so far I have not found them on the ATI
CDs bundled with the card!  There's a video-editing package bundled, but it
can't do anything without the right driver.

Then I try to run the Video CDs - supposedly in DVD format - and I get
errors about "wrong region code" with no way of changing the region code or
working out which region code I even need, and then the "DVD Player"
crashes Windows solid.  So much for the RIAA and closed source...

So, I have 9 computers in my bedroom.  The Macs (mostly) run MacOS.  The
PCs (mostly) run Linux.  Strange that one of the Linux machines (the most
underpowered and overworked one) has an uptime exceeding 100 days, whereas
I've never had even 4 weeks out of any of the Macs despite the "higher
quality hardware" argument.

--
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: [LONG RANT] Re: Linux stifles innovation...

[Russell King]

*** Please drop me from the CC: and To: lists before replying to this.
*** I do read linux-kernel, so there is no need to send me two copies
*** of your replies.

Henning P. Schmiedehausen writes:
> But at least I would be happy if there would be a printing
> engine that is entirely open source and all the printer vendors can
> write a small, closed source stub that drives their printer over
> parallel port, ethernet or USB and give us all the features, that the
> Linux _USERS_ (and these are the people that count) want.

Speaking as a Linux _USER_, if this happens, can I get said print
engine working on my ARM machines with these closed source drivers?
Can Alpha users get this print system working?  Can Sparc uses
get it working?  What?  I can't?  They can't?  Well, its no good to
me nor them.  You've just made the system x86 specific.  Well done,
thats a step backwards, not forwards.

Oh please nice big corporation, can you please build said closed
source stub for ARM?  No?  Why?  You don't see the point?

Ah, golly, I'll just have to throw my ARM machines away because
we have some critical parts of the system which are closed source.

> But even if there is such an engine written for Gnome or KDE, some
> really ingenious "free software advocate" will slap a "must not be
> used with any kind of non-GPL driver" on it...

Good.  I build the stuff to work on my ARM machines.

> The whole Linux community is using closed-source/open-source all along
> for years: Netscape. Star Office.

They don't work on ARM though, do they?  Gee, I guess ARM Ltd ought to
stop my contract because what use is an ARM kernel without everything
else to go with it?

For me, closed source is _REALLY_ bad news.  _EXTREMELY_ bad news.
It 100% prevents me from doing stuff.

Its really good that the Linux community is so open.

--
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/

Re: [LONG RANT] Re: Linux stifles innovation...

[Russell King]

*** Please drop me from the CC: and To: lists before replying to this.
*** I do read linux-kernel, so there is no need to send me two copies
*** of your replies.

Henning P. Schmiedehausen writes:
 But at least I would be happy if there would be a printing
 engine that is entirely open source and all the printer vendors can
 write a small, closed source stub that drives their printer over
 parallel port, ethernet or USB and give us all the features, that the
 Linux _USERS_ (and these are the people that count) want.

Speaking as a Linux _USER_, if this happens, can I get said print
engine working on my ARM machines with these closed source drivers?
Can Alpha users get this print system working?  Can Sparc uses
get it working?  What?  I can't?  They can't?  Well, its no good to
me nor them.  You've just made the system x86 specific.  Well done,
thats a step backwards, not forwards.

Oh please nice big corporation, can you please build said closed
source stub for ARM?  No?  Why?  You don't see the point?

Ah, golly, I'll just have to throw my ARM machines away because
we have some critical parts of the system which are closed source.

 But even if there is such an engine written for Gnome or KDE, some
 really ingenious "free software advocate" will slap a "must not be
 used with any kind of non-GPL driver" on it...

Good.  I build the stuff to work on my ARM machines.

 The whole Linux community is using closed-source/open-source all along
 for years: Netscape. Star Office.

They don't work on ARM though, do they?  Gee, I guess ARM Ltd ought to
stop my contract because what use is an ARM kernel without everything
else to go with it?

For me, closed source is _REALLY_ bad news.  _EXTREMELY_ bad news.
It 100% prevents me from doing stuff.

Its really good that the Linux community is so open.

--
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/

Re: [LONG RANT] Re: Linux stifles innovation...

[Jonathan Morton]

Henning P. Schmiedehausen writes:
 But at least I would be happy if there would be a printing
 engine that is entirely open source and all the printer vendors can
 write a small, closed source stub that drives their printer over
 parallel port, ethernet or USB and give us all the features, that the
 Linux _USERS_ (and these are the people that count) want.

Speaking as a Linux _USER_, if this happens, can I get said print
engine working on my ARM machines with these closed source drivers?
Can Alpha users get this print system working?  Can Sparc uses
get it working?  What?  I can't?  They can't?  Well, its no good to
me nor them.  You've just made the system x86 specific.  Well done,
thats a step backwards, not forwards.

Oh please nice big corporation, can you please build said closed
source stub for ARM?  No?  Why?  You don't see the point?

Ah, golly, I'll just have to throw my ARM machines away because
we have some critical parts of the system which are closed source.

SNIP

I have similar, though less acute, problems with PowerPC.  Because it's
seen as a "smaller market", less work is done on it and less closed-source
software makes it's way onto it.  Try to download a PowerPC version of
Netscape (4.x, not 6) - all you'll find are the MacOS versions, nothing for
Linux.  Fortunately, distro makers manage to have extracted one for
themselves.

As for 680x0...  well I'd love to have been able to use my old Quadra 840av
as a router/firewall/server, but nobody knows how the *hardware* works well
enough to get either Linux or NetBSD working properly on it.  So I wind up
using it as an IRC bot and scanner station, using the old, now unsupported
MacOS 8.1, which will never have it's bugs fixed because Apple considers
ancient hardware not worth it's while.  Fortunately it works well enough
for the job, and I don't have to complain too loudly about it, which is
more than I could say about any (especially recent) Micro$oft product.

Even on x86 I have problems.  I just bought ATI's flashiest new graphics
card - the All-in-Wonder Radeon - and installed it into my "workstation"
PC, which just happens to also have a Win95 partition.  With a little
fiddling, I get the 2D and 3D output features running smoothly, if not yet
optimally, under the latest version of XFree86 and the Linux kernel.  Much
the same goes for the Windows drivers.

Then I start looking for the software to drive the "extra" features, such
as the TV/video input/capture stuff, which is what distinguishes the
All-in-Wonder from the regular Radeon (and which makes it cost 2x as much).
I'll probably eventually find the right drivers for Linux - I know they
exist, if in uncompleted form - but so far I have not found them on the ATI
CDs bundled with the card!  There's a video-editing package bundled, but it
can't do anything without the right driver.

Then I try to run the Video CDs - supposedly in DVD format - and I get
errors about "wrong region code" with no way of changing the region code or
working out which region code I even need, and then the "DVD Player"
crashes Windows solid.  So much for the RIAA and closed source...

So, I have 9 computers in my bedroom.  The Macs (mostly) run MacOS.  The
PCs (mostly) run Linux.  Strange that one of the Linux machines (the most
underpowered and overworked one) has an uptime exceeding 100 days, whereas
I've never had even 4 weeks out of any of the Macs despite the "higher
quality hardware" argument.

--
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: [LONG RANT] Re: Linux stifles innovation...

[Jacob Luna Lundberg]

 Speaking as a Linux _USER_, if this happens, can I get said print
 engine working on my ARM machines with these closed source drivers?
 Can Alpha users get this print system working?  Can Sparc uses
 get it working?  What?  I can't?  They can't?  Well, its no good to
 me nor them.  You've just made the system x86 specific.  Well done,
 thats a step backwards, not forwards.

Just out of curiosity, why can't the specification be along the lines of a
vendor data file saying ``if you want the printer to do x then say y'' and
``if the printer says x then it means y''.  That ought to add a lot of
functionality right there.  Sure there are evil winprinters that this
wouldn't be enough for but it would be hardware independant, yes?

Or alternatively what about getting vendors to release their source to a
middleman as a trade secret?  The middleman could then release binaries
for the various arches...  Distasteful, but I'd love to be able to use
*all* the features of my Lexmark OptraColor 45...  ;)

-Jacob

-
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]

On Sat, Feb 17, 2001 at 01:37:58PM +, Russell King wrote:

 Henning P. Schmiedehausen writes:
  But at least I would be happy if there would be a printing
  engine that is entirely open source and all the printer vendors can
  write a small, closed source stub that drives their printer over
  parallel port, ethernet or USB and give us all the features, that the
  Linux _USERS_ (and these are the people that count) want.
 
 Speaking as a Linux _USER_, if this happens, can I get said print
 engine working on my ARM machines with these closed source drivers?

 Can Alpha users get this print system working?  Can Sparc uses
 get it working?  What?  I can't?  They can't?  Well, its no good to
 me nor them.  

Maybe not. But you can use this print engine API to pay anyone to
write a driver for you. What you just said, is exactly my point. You
said:

"If a company does not write a driver which works on all hardware
 platforms in all cases and gives us the source, then it is better,
 that the company writes no drivers at all."

"If I can't force a company to write a driver for everyone, then I
 don't want to write them any driver at all."

IMHO you're like a spoiled kid: "If I can't have it, noone should have it".

 You've just made the system x86 specific.  Well done, thats a step
 backwards, not forwards.

No. Some Linux users got a driver that works as well as the drivers
for another OS. This is good for Linux. And all Linux users and
developers got an open, stable API, which is supported by big printer
vendors and enables everyone to write good drivers.

If you need a printer driver for the ARM, you're able to approach the
company XXX and either pay for an ARM specific driver (and they will
listen to you because they already have made a driver for another
Linux platform, learned that they can make money with Linux software
and have experience with driver(s) for Linux. And it will be just a
recompile most of the time).

 Ah, golly, I'll just have to throw my ARM machines away because
 we have some critical parts of the system which are closed source.

We're talking about a driver. If Company XX won't sell it to you for
your architecture, it's their right to do so. There is software that
I've written that you might want to have, too. If I chose not to sell
it to you, what do you do? You can say "company XX sucks" and buy an
equal product with an ARM driver from YY which listens to you. _THAT_
is IMHO open. Not forcing everyone to comply with your ideology.

  But even if there is such an engine written for Gnome or KDE, some
  really ingenious "free software advocate" will slap a "must not be
  used with any kind of non-GPL driver" on it...
 
 Good.  I build the stuff to work on my ARM machines.

Can you get a Legato Networker Client for Linux-ARM? Can you get one for
Linux-MIPS? Why? Because someone payed for the port.

 They don't work on ARM though, do they?  Gee, I guess ARM Ltd ought to
 stop my contract because what use is an ARM kernel without everything
 else to go with it?
 
 For me, closed source is _REALLY_ bad news.  _EXTREMELY_ bad news.
 It 100% prevents me from doing stuff.

No. It means, that for some programs, in order to have them, you have
to pay. That is fine. There ain't no such thing as a free lunch. You
may, of course, chose not to pay, but then you may not be able to use
a certain program.

Look, I'm willing to pay money for the whole M$ Office Suite on
Linux. Yes.  I would give billg gladly a big chunk of my money to get
this application suite on Linux. Not a copy or a "just almost like M$
Office". But the real thing. The real "M$ Office 2k" suite for Linux.

Can I?  No. Because M$ chose not to offer its product for Linux. Bad
for me. It means, that I can not get parts of my work done on Linux.
Can I buy AutoCAD? Photoshop? Quicken? Outlook? Visio? Not look alikes
or clones or "almost as good as". But the real thing with the same
support as on Windows. I can for the Mac. Why can't I for Linux?

Because IMHO some companies shy away from the aggressive and sometime
openly hostile behaviour of the Open Source community ("If you don't
support your application on Linux/SPARC with an B/W framebuffer, you
suck. Go away") towards commercial companies.  ("If you don't support
Gnome 1.0 but just KDE 2.1, you suck. Go away"). And billg laughs and
just points the confused companies towards the "stable" and "easy to
use" M$ OS.

And the volatile APIs which are immature in some points (Font handling. 
Printer support. Color handling. Same things all the time. But displaying 
the results of your work and printing them onto paper is for many
people the most important thing. And frankly, Linux sucks here).

In your opinion, it is better, that I can't get some programs at all
than paying money for them.

In my opinion, I prefer to get it at least for i386/Linux than not to
get them at all. Because if I can't get them for i386/Linux, I must
get them for i386/Windows. Because I need a specific 

Re: [LONG RANT] Re: Linux stifles innovation...

[Felix von Leitner]

Thus spake Henning P . Schmiedehausen ([EMAIL PROTECTED]):
 "If a company does not write a driver which works on all hardware
  platforms in all cases and gives us the source, then it is better,
  that the company writes no drivers at all."

 "If I can't force a company to write a driver for everyone, then I
  don't want to write them any driver at all."

 IMHO you're like a spoiled kid: "If I can't have it, noone should have it".

Henning, what is the matter with you?

I bought the hardware.  Why should I pay for the driver?
Not even on Windows you pay extra for a driver!

Please state your intentions.  Why would you want to split the Linux
user base into people who pay companies to screw them (I get a driver
for hardware I already paid for, but the driver will work with exactly
one kernel version on one hardware) and people who think they deserve
support when they buy hardware?

Why do we even have to discuss drivers?
A company that actively hinders developing a good driver with patents,
NDAs or other legal crap does not deserve my money.  If you throw your
money at such people, you deserve everything you get.

Felix
-
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...

[Peter Samuelson]

[Jacob Luna Lundberg]
 Just out of curiosity, why can't the specification be along the lines
 of a vendor data file saying ``if you want the printer to do x then
 say y'' and ``if the printer says x then it means y''.  That ought to
 add a lot of functionality right there.

Think about it.  A spec based on what you say would be quite easy to
reverse-compile, no?  In which case, obviously the company's IP, such
as it is, is not protected.  In which case, why not just do an open
source driver and be done with it?

The concept of architecture-independent device drivers goes back to
Open Firmware.  But in that case, there is a practical consideration:
the drivers couldn't be compiled down to machine language since they
had to be accessible as-is at boot time.

Peter
-
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...

[Ben Ford]

Jacob Luna Lundberg wrote:

 Speaking as a Linux _USER_, if this happens, can I get said print
 engine working on my ARM machines with these closed source drivers?
 Can Alpha users get this print system working?  Can Sparc uses
 get it working?  What?  I can't?  They can't?  Well, its no good to
 me nor them.  You've just made the system x86 specific.  Well done,
 thats a step backwards, not forwards.
 
 
 Just out of curiosity, why can't the specification be along the lines of a
 vendor data file saying ``if you want the printer to do x then say y'' and
 ``if the printer says x then it means y''.  That ought to add a lot of
 functionality right there.  Sure there are evil winprinters that this
 wouldn't be enough for but it would be hardware independant, yes?

isn't that what windows *.INF files do?
(don't flame me  I'm not sure about it)

-b

-
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/