Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.ecn.uoknor.edu!paladin.american.edu!news.jhu.edu!aplcenmp!netnews.jhuapl.edu!uunet!in1.uu.net!news.artisoft.com!usenet
From: Terry Lambert <terry@lambert.org>
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
Subject: Re: Why to not buy Matrox Millennium
Date: Sat, 13 Apr 1996 16:11:09 -0700
Organization: Me
Lines: 150
Message-ID: <3170348D.4496D9F1@lambert.org>
References: <4jv7c9$m5t@park.uvsc.edu> <stephenkDpCsvp.LBu@netcom.com> <4kfkb2$dgs@coyote.Artisoft.COM> <stephenkDpoDrJ.177@netcom.com>
NNTP-Posting-Host: hecate.artisoft.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.01 (X11; I; Linux 1.1.76 i486)
Xref: euryale.cc.adfa.oz.au comp.os.linux.development.apps:14417 comp.os.linux.development.system:21248 comp.os.linux.x:29240 comp.os.linux.hardware:36231 comp.os.linux.setup:50320 comp.unix.bsd.386bsd.misc:559 comp.unix.bsd.bsdi.misc:3152 comp.unix.bsd.netbsd.misc:2954 comp.unix.bsd.freebsd.misc:17210
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.
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).
] BTW SCO does NOT run IBCS2 programs, but SCO programs which
] HAPPEN to be IBCS2. There are MANY IBCS2 programs that
] aren't SCO compatible!
This is not true. SCO is certified to provide an IBCS2
environment for programs. You must be referring to "IBCS2
plus extensions", which is *not* IBCS2 compliant. To be
IBCS2 compliant, a program must use only those interfaces
documented by IBCS2 (or a subset thereof).
Like POSIX, this makes for a tricky bit of programming to get
around standards defficiencies. Oh well. That is (supposedly)
why programmers are paid more than MCDonalds employees.
] >] >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.
] >XFree86 is primarily for the benefit of the free Intel UNIX
] >clones. Commercial Intel UNIX comes with an X Server, usually
] >OEM, and XFree86 is limited to Intel.
] >
] >This is all about nothing but Millenium support for Linux and BSD.
]
]
] 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.
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?).
] 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.
] It ISN'T about linux, or bsd, but ANY non real mode program.
For instance?
I remind you that "ANY non real mode programmer" can get
documentation as long as he does not disclose it by publishing
source code.
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.
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.