Possibly offtopic : Binary only driver

Sun Nov 21 23:51:46 UTC 2004

On Sun, 2004-11-21 at 12:21, Mike Hearn wrote:
> On Sun, 21 Nov 2004 11:44:39 -0800, Stephen Pollei wrote:
> > I guess I won't buy any games that need that kind of closed-source
> > binary driver. If everyone switched to Linux and had that kind of
> > attitude then I'm sure vendors would find some way to open up some code.

> They won't. Why should they? Availability of source code is useful
> primarily to those who can read and write programs. That's not the
> majority of the worlds population.
You are right most people don't follow some kind of enlightened
self-interest. However that doesn't mean that people might not slowly
come around. It gets them indirect benefits. Even in a society were only
1% of the population bother to learn how-to maintain/repair cars, being
able to get the engine benefits all. Further I've read a lot of code,
but I don't think I've read more than 2% of all the code that goes into
a modern distribution. I know I've contributed less than 0.1% , funny it
doesn't seem to diminish the benefit I get from them in any real
fashion.

> > Not really, It just means that many of the kernel developers want to
> > only support that which they can. Thats why they added the tainted flag.
> > Binary-only modules don't benefit them and they can't help you with it. 
> 
> They could support kernels with binary only modules. Other OS vendors do
> it. Other open source projects do it. They choose not to however.
Yes sir, their choice and I completely understand why and support their
choice.

> > Ok but why exactly should the kernel developers care to support that.
> 
> Good question! I thought it was because the kernel developers wanted to
> make a kernel useful for desktop systems, but if that isn't the case then
> I guess I have no arguments left: this whole thing revolves around wanting
> the kernel to be easier to use and therefore more useful than it currently
> is.
The way for the kernel people and the various distributions to make it
super easy for the end-user *requires* them to have the source for the
various things they want to support. They can mold source-code, binaries
are take it or leave it. So from my point of view I'm wondering why you
are so user-hostile, instead of allowing the system to be more
user-friendly. Also watching how people work on places like the lkml, I
can't imagine how much slower they'd progress if they had to ask third
parties to please fix this or that small problem that got exposed from
some of the rapid changes that have happened. I think it would have been
glacial slow to make the kind of smp locking changes that have happened
if they had to wait a week or two for a third party to give a kernel
developer a binary blob that he needs just to test something out quick.
That he could have just just done himself with a one line change if he
had the source.

Speaking of support, if someone had a premium support contract with
RedHat(TM) for a thousand desktop machines. If they ask for help,
because their video card driver locks up under the heavy smp load their
video editing is doing -- They don't want to hear RedHat point to a
binary blob and say -- Opps not my problem. They want it solved RSN.
And if RedHat can't or won't they want to be able to send their opps or
deadlock report to the lkml or gasp hire someone themselves. Maybe up
the bar in what you expect a sysadmin to be able to do.

> > Yep I hear windows have similar problems with third party drivers.
> > They also have lots of bloat to support old obsolete and redundant
> > api's. BTW I remember that this debate was done better online through
> > some blogs.
> > http://blogs.sun.com/roller/page/eschrock/20040924#rebutting_a_rebuttal
> > http://www.kroah.com/log/2004/09/26/#2004_09_26_sun_rebuttal_round2
> > http://www.kroah.com/log/2004/09/23/#2004_09_23_sun_rebuttal
> 
> I saw that debate. Gregs arguments struck me as very poor, and I wasn't
> the only one:
> 
> http://primates.ximian.com/~miguel/archive/2004/Sep-28.html
> 
> He basically said things like "Well Windows has multiple USB interfaces
> and that's a bad thing" and expecting it to pass as assertion, ie there
> was no analyis of why it was a bad thing. He just took it as read that it
> was. In this case the cost of having the old interfaces (in financial
> terms) was presumably outweighed by the benefits of retaining backwards
> compatibility, otherwise MS would not have done it.
Yeah MS has lots of backwards compatible stuff, sometimes on the side of
the completely sick and disgusting -- 
http://www.joelonsoftware.com/articles/APIWar.html
http://weblogs.asp.net/oldnewthing/archive/2003/12/23/45481.aspx
http://weblogs.asp.net/oldnewthing/archive/2003/10/15/55296.aspx
[[Reaching up the stack
    A certain software company decided that it was too hard to take the
coordinates of the NM_DBLCLK notification and hit-test it against the
treeview to see what was double-clicked. So instead, they take the
address of the NMHDR structure passed to the notification, add 60 to it,
and dereference a DWORD at that address. If it's zero, they do one
thing, and if it's nonzero they do some other thing.

    It so happens that the NMHDR is allocated on the stack, so this
program is reaching up into the stack and grabbing the value of some
local variable (which happens to be two frames up the stack!) and using
it to control their logic.

    For Windows 2000, we upgraded the compiler to a version which did a
better job of reordering and re-using local variables, and now the
program couldn't find the local variable it wanted and stopped working.

    I got tagged to investigate and fix this. I had to create a special
NMHDR structure that "looked like" the stack the program wanted to see
and pass that special "fake stack".

    I think this one took me two days to figure out.]]

So yes Microsoft is paying lots of costs to keep backwards compatible,
but not all of those costs boils directly to simply the cost of the
programmers keeping redundant code around that they probably don't edit
much anymore anyway. It costs efficiency; It cost quality; It costs
aesthetics; It costs excellence. Those costs are passed on to the end
customers, so MS doesn't care if it externalizes costs.

> Remember, one mans bloat is another mans ability to upgrade ...
I think Linux has done well in upgrading from 386's to AMD-64 ...
Just how many drivers that have been open-source has had problems not
being upgradeable. I've seen Linux support old hardware better than the
windows model

> > One minor comment though, the fact that we have the source to everything
> > changes all of the old rules that operating systems had to live by.
> > Backwards compatibility is no longer necessary, enabling us to move
> > faster, and be more flexible than ever. 
> 
> Yes, because as we all know software magically rewrites itself while we
> sleep. Our IT systems are also upgraded by leprechauns.
No, but if your source code lives in the tree, then if they change that
when they update the api's.
Sounds like you are really complaining that you are too slow. So you
ask, please slow down, because I have a crippled development model.

> > As proof of that, look at the
> > huge range of machines that Linux runs very well on.

> 
> That is unrelated to backwards compatibility. The rest of your paragraph
> is based on an unsupported assumption: that Linux could not be
> fast/multi-arch etc without an unstable module API. I've never seen
> anybody seriously try and argue that (Windows NT kernel is also
> multi-arch).
I was also talking about the benefits of having source, not just
backwardness. How viable are those other archs with NT. I remember when
NT ran on the Alpha, how great was the third party driver and app
support for that?

> Anyway, this is all a pointless discussion. This is not me saying
> "binary modules are good", I never claimed that, I'm saying they're
> unavoidable and should be supported.
I avoid closed-source binary-only modules just fine, thank-you very
much. 

> Probably, the only way we're going to get a sane ISV-supportable desktop
> system is by forking the kernel at the start of major release cycles (2.4,
> 2.6 etc). So this whole discussion is pretty useless and I wish I had
> never started it, people here are far more interested in theoretical
> performance benefits being available RIGHT NOW than eg being able to buy a
> working wireless card.
The only way? Sane?

I think it's insane for people to expect the great things like the smp
support, or Ingo's realtime preempt to have been viable if the kernel
developers had to wait to get third party binary drivers to fix every
little tiny thing. It is of incredible strategic importance that they
don't get into a dependency problem with things that aren't as
responsive as they are. Just listen Mrs. Reagan and "Just say no!" .

Also if I was you I'd fork at something more recent than 2.6.0 or 2.4.0,
and I wouldn't hold my breath for 2.8.0 or 3.0.0 .

Well I still use wires for networking. I don't feel like going through
the hassle of making sure I don't use WAP, and don't broadcast the SSID
stuff, and whatever else it takes. So bad example for in my case.

Since you wish you didn't receive the feedback you got, I won't continue
in this thread. Thanks for your input though.

-- 
http://dmoz.org/profiles/pollei.html
http://sourceforge.net/users/stephen_pollei/
http://www.orkut.com/Profile.aspx?uid=2455954990164098214
http://stephen_pollei.home.comcast.net/
GPG Key fingerprint = EF6F 1486 EC27 B5E7 E6E1  3C01 910F 6BB5 4A7D 9677
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20041121/51a58c06/attachment-0002.bin 