Return to BSD News archive
Newsgroups: comp.os.linux.development.apps,comp.os.linux.development.system,comp.os.linux.x,comp.os.linux.hardware,comp.os.linux.setup,comp.unix.bsd.386bsd.misc,comp.unix.bsd.bsdi.misc,comp.unix.bsd.netbsd.misc,comp.unix.bsd.freebsd.misc Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.cs.su.oz.au!inferno.mpx.com.au!news.mel.aone.net.au!imci4!newsfeed.internetmci.com!in1.uu.net!mail2news.alias.net!myriad!mylinuxbox!suck!netcom.com!stephenk From: stephenk@netcom.com (Stephen Knilans) Subject: Re: Why to not buy Matrox Millennium Message-ID: <stephenkDq2BCK.B40@netcom.com> Organization: Netcom Online Communications Services (408-241-9760 login: guest) References: <4kfkb2$dgs@coyote.Artisoft.COM> <stephenkDpoDrJ.177@netcom.com> <3170348D.4496D9F1@lambert.org> Date: Thu, 18 Apr 1996 14:38:44 GMT Lines: 163 Sender: stephenk@netcom8.netcom.com Xref: euryale.cc.adfa.oz.au comp.os.linux.development.apps:14660 comp.os.linux.development.system:21858 comp.os.linux.x:29814 comp.os.linux.hardware:36823 comp.os.linux.setup:51339 comp.unix.bsd.386bsd.misc:720 comp.unix.bsd.bsdi.misc:3358 comp.unix.bsd.netbsd.misc:3200 comp.unix.bsd.freebsd.misc:17762 In article <3170348D.4496D9F1@lambert.org> Terry Lambert <terry@lambert.org> writes: >Stephen Knilans wrote: >] >] In article <4kfkb2$dgs@coyote.Artisoft.COM> Terry Lambert ><terry@lambert.org> writes: >] >stephenk@netcom.com (Stephen Knilans) wrote: >] >] >Running binaries under IBCS2 emulation instead of running them >] >] >native means no support from the software vendors when the >] >] >programs fail to run under Linux. >] >] >] >] MOST are NATIVE aps! >] > >] >No. Most UNIX apps which exist are IBCS2. >] >] MOST, of the ones I mentioned, and of those for linux, are >] NATIVE to Linux! > >Prejudicial on your part... you include only samples which >support your hypothesis, even when the majority of random >samples would not. If you are going to be that way, then you would have to say most UNIX apps are NOT IBCS2, and most programs are not DOS OR UNIX! You HAVE to have a GROUP you are talking about. Can't you understand, and look at the previous messgaes, and see that what I basically said is "MOST companies that support LINUX DO provide NATIVE code!"? Heck, it doen't matter in this discussiion ANYWAY! SCO would have the SAME problem. AH, you might say, they DO support it. Key word here is "DO"! I am sure they DIDN'T in ODT 2.0! The card in my office system was "not supported", but it ran FINE, because they didn't play the stupid tricks matrox did! And THAT is my point. It always HAS been my point. I don't expect them to support Linux, and don't care if they EVER do. The FACT is that they advertise it as a VGA card, and should support THAT! >The point of trying to "present a united front" to convince >Matrox to change their irrational policies is defeated if you >do this. It will take internal effort by Matrox to effect >a policy change; you must prove to them that it is worth the >effort (AFTER you have proven that their policies are in fact >irrational and provide no intellectual property protection). > > >] >] >That's why Matorx doesn't think Linux (or BSD) is enough of a >] >] >market to care to change their policy (a policy which does not, >] >] >as they purported in David's quotation of them, protect their IP). >] >] >] >] This is NOT about Linux! >] > >] >Check your newsgroups lines. >] >] CHECK THE SUBJECT! > >People who do not run XFree86 don't care that their interfaces >aren't documented. They use the proprietary X severs that >came with their proprietary OS. > >An undocumented interface is *not* a good excuse for these people >as to "Why to not buy Matrox Millennium"... the excuse does not >bear (and should not) on these peoples purchase decisions. How would YOU like to buy a car that runs on some material that only that one company can give you, and that you can't get elsewhere? That SHOULD bear on any purchase decision. If matrox went bankrupt, their cards may NEVER work on future O/Ss! Paradise, and others, could go bankrupt, and their cards are almost ASSURED of working in ANY future O/S! >] I don't care about Linux support! NOBODY does! If it was a >] register compatible card, as it CLAIMS, it wouldn't need >] special support. Such support is needed by ANY non real >] mode application! > >Bullshit. VM86() can be used from protected mode to make INT 10 >calls. VM86 (virtual machine 8086), IS basically real mode. GRANTED, it maps new memory into the conventional mode area, etc, but that is it. This is also used by dosemu. It is NOT, however, efficient, and many are even talking about doing away with it. Do you REALLY think someone is going to buy a card that is supposedly so fast on video, and will be made happy by slowing down THEIR WHOLE SYSTEM by doing what you suggested? Please, let me know who. I'd like to sell them a bridge! >I'd like to see you document their claims to register level >compatability. The VGA standards only documents INT 10 >interfaces (unless you are mistaking the IBM implementation >documentation for a standards document?). Whether it is called a standard or not is really pretty meaningless. It IS a de-facto standard, etc.... I don't know if the original LRM for C had stdio, etc... By the time they became widely used, etc....., it was ASSUMED that C WOULD have it! The FACT is that almost all cards DO! >] Don't you know about real versus flat, and segmentation, and >] their affect on a program? PLEASE read a book on 386 >] programming. THEN, you will see the problem! > >I don't see the problem because you are assuming a specific >soloution implementation, and then going on to bitch about it. > >It seems to me that you are trying to apply a single class >of problem soloution, instead of solving the problem within >the scope of the actual problem parameters. > >In other words, you have a hammer and are bitching about the >fact that you can't pound screws into a molly-bolt. > NO, I am talking about a COMMON solution that would, and HAS, worked in EVERY case! Since it has worked in every one of millions of cases so far, what is different about this one? > >] It ISN'T about linux, or bsd, but ANY non real mode program. > >For instance? How about windows NT before there were drivers? How about BSD? How about SCO? How about DOS BASED CAD programs? >I remind you that "ANY non real mode programmer" can get >documentation as long as he does not disclose it by publishing >source code. And have routines for each of HUNDREDS of cards? NO THANKS! > >For the purposes of this discussion, this is simply an additional >problem constaint. > > >I can see why this constraint causes problems for XFree86. > >I can also say that I will personally boycott the product >because I believe the reasoning which led Matrox to imposing >the constraint involved flawed logic. > >I *can't* see whining about non-conformance to what you believe >to be implied standards because of a misunderstanding on your >part about what "VGA" does or does not mean (as has already >been explained to you by others). > > >Do you have a protected mode application in an environment >where there is not a VM86() interface for which you are >*technically* (not *politically*) required to distribute >source? > >If so, can you *not* require Matrox non-disclosure from >your customers, passing the problem along? > >If this is the case, then you are in the same boat as XFree86; >otherwise you are complaining about problem difficulty in >a field known for posing difficult problems, and you will gain >no sympathy from the rest of us in the same field. > >If you have a political soloution, perhaps, like Pat Buchanan's >recent primary election failures, you would be better advised >to preach your politics to the people you oppose. Preaching >to people of the same political bent will, like Buchanan, not >gain you supporters among those who are not already behind you. >The key to a political victory lies in increasing your support, >not in alienating your allies. >