Matthias Hopf wrote: > 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.
So, we agree, I just said in different words "it is not that simple" :-) >>> 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. I expected such answer. It was probably wrong example. Important is that product without exact plans takes too much time to make usable. > Do I need high-performance graphics in Linux? *YES* > Wouldn't have my job, wouldn't have my PhD without. I agree that we need. Problem is that if any drivers have to break whole concept of open source than it is the same as when Ariane breaks because of some stupid bug. >> 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. There is so many pieces of software out there, many people are working on it, but not everyone is able to organize work properly, nor to produce good code. But you know that. > For complex hardware w/o docs with erratas you need direct access to the > hardware engineers. Which, of course, is only possible in-house. That is one of reason that kernel developers want GPLed software, not proprietary accompanied with NDAs that one day can explode and run them out of business. > 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). Intel can make the difference in other companies habits. If Intel can find financial interest to play on open source market, others will rethink about own Linux strategy. >> 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. I compared beasts of today with oldtimers few times. In examples I used where 1970's mainframes specifications. I compared how many people were active in maintenance and programming, and how many today. It is funny that machines, that were smaller than your examples, used to keep up and running few engineers and more technicians, programmers, accountants. Today one man, that often has no basic knowledge about computers, is all that operates "the beast". >> 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. Depends on compiler :-) > 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. Number and severance. First we never know, second ... actually we don't know that either. We know about discovered bugs. How many is left, and how severe they are we will never know. What we can say is that major roads are without holes, side roads, we don't care. >> 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). The 90% will never be seen, but it will make program load tons of unneeded junk, crash occasionally, loose data, take more and more memory as time passes, have security holes, to mention few of the most known invisible bugs that come in mind. You probably can list much more. > 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. I played with simple programming on occasions, and I know how many versions was produced before program (again, very small) worked as I wanted, so I can imagine what is happening when in play comes project deadline, marketing department, family that has needs and wishes, and much more. I don't think that old time goals are possible anymore, but as time passes and we get used to "some bugs are not that bad", it will bring more bugs with the time. This is entropy as it applies to software. It will come time when software will be useless, but we should not speed that up. -- Regards, Rajko. Visit http://en.opensuse.org/MiniSUSE --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
