Re: Open letter to the UDI folks?: Killing two birds with one stone

Terry L Ridder (terrylr@tbcnet.com)
Wed, 14 Oct 1998 03:56:28 -0500

Jon Maddog Hall wrote:
>
Terry L. Ridder wrote:
Jon Maddog Hall wrote:
> >> Here are some of my thoughts:
> >>
> >> Adam is right. While LI embraces the OSD concepts, it is not
> >> exclusive. We encourage people to be Open Source,
> >> but LI's main goal is to have them use
> >> the Linux(R) operating system as an alternative to Microsoft.
> >
> >This places Linux in a rather fragile position.
> >Please refer to
> >
> >http://www.internetworld.com/print/current/webdev/19981012-underdev.html
> >
> >I quote a brief section:
> >
> ><Begin Quote>
> >
> >But Linux will fail if it is forced to serve the wrong goal. If,
> >instead of being a better tool to solve developers' needs, Linux
> >becomes the latest proxy for Microsoft's competitors, it will
> >fade into obscurity. This is where Apple, Borland, Novell,
> >Netscape, et al. went wrong. By becoming obsessed with
> >Microsoft instead of serving their customers, these companies
> >forgot that the point of making products is developing solutions
> >to real problems, not dinging the largest competitor.
> >
> ><End Quote>
>
> I am really tired of having to explain to people that I was basically
> quoting
> what Linus Torvalds has said many, many times in speeches: "Alternative
> to Microsoft", an "alternative operating system". I did not say why it
> was an alternative, or why people would agree it was an alternative
> (superiority of code?), because the letter was NOT ABOUT THAT.
>
> Normally I answer that LI's goal is simply to "promote Linux". And quite
> frankly Nate Zelnick, the author of the article that you are quoting is
> dead wrong about Linus. ANYONE who has ever heard him speak knows that.
>
> >>
> >> Third, while UDI does have the capability of allowing binary-only
> >> drivers
> >> to be generated and distributed, its larger capability is to allow the
> >> same
> >> APIs to go across operating systems. Therefore people who write
> >> device drivers
> >> for *BSD or SPARC or Digital Unix will also be writing them for Linux.
> >> This is a win-win situation.
> >
> >It is not a win-win situation when you consider I2O in the picture.
> >Currently there is no way for Linux to incorporate I2O support.
>
> I have not only read them, but I have had long talks with Michael LoBue,
> who is the head of the SIG, and the SIG representative from Intel.
> Both of them have told me that the issue of the specification being
> closed is a temporary thing. Maybe they were lying, but I just called
> Micheal's office and asked for an appointment tomorrow
> (I am flying out to San Fransico), and I will see what he says now.

It is not Michael LoBue or the SIG representative from Intel
that can release the I2O specification. The Steering Committee
must first approve such a release and than 51 out of the 67 Contributing
members of I2O Sig must approve it. That is straight from the
I2O Sig "charter". They can say whatever they want but if the
Contributing Members vote down such a release there is nothing the
Steering Committee can do about it. There is also the option that
the Steering Committee would never approve such a release and
the Contributing members do not have to vote.

>
> >It is that very nature of products which have a "six month or less
> >lifetime"
> >that would lead the hardware vendor to slap a driver together which
> >offers
> >poor performance, or just plain does not work. This would be no
> >different than
> >what we currently have today. Anyone who has installed Windows lately
> >understands
> >this. After the market lifetime of a product has passed what incentive
> >is there for
> >the hardware vendor to keep updating the device driver?
>
> You made an assumption that people start working on the follow-on
> product's driver either from scratch (bad assumption) or that they
> actually wait until the current product is shipping before they
> work on the next product. These days most large companies are working
> on two generations of products, banking on the fact that the products
> which will let them build the next generation of products are now
> being created themselves.

I did not make that assumption. I have clients who are doing basically
what you have described, working two generations of product at the same
time. Even in this environment the device drivers are an afterthought,
just slap something together. They take the previous products device
driver, which barely worked, change it for the product they are working
on, barely test it, and ship it. Do customers complain, yes they surely
do.
Does it make a difference? Meetings are scheduled, held, and lectures
given about development needs to "get their act together". Development
argues that marketing better start allowing for longer lead times so
development is able to correct the device drivers and test them longer.
The cycle repeats itself over and over again. :-(

> >The end-user is not going to blame the hardware vendor about the driver
> >he will blame Linux/*BSD/Solaris/HP-UX/IRIX/etc.
>
> >From where do you draw this assumption?
>
> It is late, and I have a plane to catch early tomorrow. Bottom line
> (from what I can see) is this:
>
> The Linux community can be paranoid, not trusting anyone, and
> doing things their own way (no I2O, no UDI), whack and hack
> everything from scratch.
> That is o.k., if that is what they want.
>
> Or they can be openly trusting, try to work with I2O, UDI and take the
> chance of getting screwed.
>
> Or they can go a middle route, of trying to work with these groups, but
> keep an eye out. Take the best of what is offered.

There is a fourth alternative:

The Project UDI people and the I2O people get together and I2O
becomes open and public now.

Just as IBM opened up giving source code to the Apache developer
in exchange for supporting Apache for IBM.

There must be a currency of trust, and that currency is that I2O
becomes open and public. Not available publicly under "reasonable
terms",
but public, licensing fees, no royality fees, no NDA's.

>
> I prefer the third alternative, since I think that there are some gains
> that could be made. And to this goal I will try to see Michael LoBue
> tomorrow. I may not succeed in seeing him, since it is short notice for
> an appointment, but I will try.
>
> md

I wish you the best if and when you get to meet with him.

-- 
Terry L. Ridder
Blue Danube Software (Blaue Donau Software)
"We do not write software, we compose it."


 entertaining angels
 by the light of my computer screen
 24-7 you wait for me
 entertaining angels
 while the night becomes history
 host of heaven, sing over me
 ==Entertaining Angels==Newsboys


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/