Rajko,

On Sep 08, 06 19:44:10 -0500, Rajko M wrote:
> > And prevent many users from actually using Linux at all, because there
> > is *no* really fast 3D hardware with OS drivers.
> > 
> > It's not so simple.
> 
> It Matthias.
> If we start to run to get more users as the only goal that we going to
> loose even existing base. Linux picks up computer users that know for
> sure that they don't want what is offered in other environments.

I know. I'm not saying I'm all for binary modules, not at all. I'm just
saying the world isn't black and white.

> > There are no specs, so they cannot be published.
> > 
> > Release cycles are too fast, there is no documentation even within ATI
> > or NVIDIA.
> 
> That is the same as there is airplane without plans. Do you need this in
> Linux?

It is *definitvely* not the same.

- If a plane crashes people die. This is typically not the case if a
  graphics driver crashes.

- Planes don't get obsolete after 2 years.

- Planes cost a bit more than 200-500 bucks.

- The airplane market is a little bit bigger than the graphics hardware
  market.

- It is also a little bit more regulated than the graphics hardware
  market.

Do I need high-performance graphics in Linux?  *YES*
Wouldn't have my job, wouldn't have my PhD without.

> Open source has problems with documentation too, but at least, the
> ultimate specification, source code is open, so you can compare to the
> real world.

Then what? Why is the r200 driver in such a bad shape? It's open source,
and many people are working on it.

For complex hardware w/o docs with erratas you need direct access to the
hardware engineers. Which, of course, is only possible in-house.

Other than that you're right, we DO want open source drivers. But not if
that means the producers just kick out the code and abandom it. Because
without input from the original developers they start falling to a
silent, miserable death. We want something like the intel drivers, which
are still mostly being worked on by intel (not directly, but who cares).

> Once upon a time computer did exactly what is specified. If not vendor
> was laughed out like an incompetent bunch of amateurs. No one wanted
> such reputation because it meant no customers.

Once upon a time a computer had 640KB of memory, because that was more
than was ever needed.

Don't, just don't compare the complex beasts we have nowadays with a PC
of 1980 or even a ZX-1 or an old SuperMicro.

> You can imagine how sounds "it is normal that first released version is
> buggy". If first is buggy, and release cycles are so fast, what version
> will have no bugs? The one that is not released?

Software has bugs. Period.
This is a lema in computer science, like it or not:
All even modestly complex software has bugs.
Read: helloworld.c has (hopefully) no bugs, all others have.

It's just the number and severence of bugs we are finding in some
products at release time that may really get on one's nerve. On mine,
too, of course.

> While for multimedia computers some bugs are not important, for computer
>  as machine that is meant to compute exact values, almost any bug is
> important. It indicates that program is not properly tested, and user
> can't trust that it will perform as designed in important functions.

No, typically >90% of all bugs will never ever be encountered, or they
will have no side effects (which is close enough to not being a bug, I
admit).

Yes, the space shuttle and ariane software has bugs as well. Only those
that showed up bad (read: destroying the aircraft) are noticed by the
public.

Matthias

-- 
Matthias Hopf <[EMAIL PROTECTED]>       __        __   __
Maxfeldstr. 5 / 90409 Nuernberg    (_   | |  (_   |__         [EMAIL PROTECTED]
Phone +49-911-74053-715            __)  |_|  __)  |__  labs   www.mshopf.de
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to