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!boingo.amil.jhu.edu!europa.chnt.gtegsc.com!gatech!news.mathworks.com!news.duke.edu!news-server.ncren.net!taco.cc.ncsu.edu!crazytrain.eos.ncsu.edu!not-for-mail
From: kpneal@eos.ncsu.edu (Kevin P. Neal)
Newsgroups: comp.os.linux.development.system,comp.unix.bsd.386bsd.misc,comp.unix.bsd.bsdi.misc,comp.unix.bsd.netbsd.misc,comp.unix.bsd.freebsd.misc,comp.os.linux.advocacy
Subject: Re: Historic Opportunity facing Free Unix (was Re: The Lai/Baker paper, benchmarks, and the world of free UNIX)
Followup-To: comp.os.linux.development.system,comp.unix.bsd.386bsd.misc,comp.unix.bsd.bsdi.misc,comp.unix.bsd.netbsd.misc,comp.unix.bsd.freebsd.misc,comp.os.linux.advocacy
Date: 14 Apr 1996 21:57:24 GMT
Organization: The House of RetroComputing
Lines: 160
Message-ID: <4krsc4$m7t@taco.cc.ncsu.edu>
References: <4ki055$60l@Radon.Stanford.EDU> <jdd.829261293@cdf.toronto.edu>
NNTP-Posting-Host: crazytrain.eos.ncsu.edu
X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]
Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:21314 comp.unix.bsd.386bsd.misc:576 comp.unix.bsd.bsdi.misc:3172 comp.unix.bsd.netbsd.misc:2984 comp.unix.bsd.freebsd.misc:17272 comp.os.linux.advocacy:45336
Jordan K. Hubbard (jkh@time.cdrom.com) wrote:
: In article <31702487.420C2193@lambert.org> Terry Lambert <terry@lambert.org> writes:
:
: This is hard; this is a political question. My personal answer:
: Motif. It is the only standard GUI ratified by a UNIX standards
: body, and it meets the additional requirement of being nearly
:
: Sorry, Terry, but Motif (unlike X) is not free, and none of the clones
: are anywhere close to taking the place of the OSF distribution.
:
Ummm, Lesstif has a long way to go, but if it did get "there" one day,
things will be alot nicer. We need more people.
: This is NOT easy! Easy-er, maybe, but all the stuff you outline blow
: has a tremendous development cost associated with it! Maintaining DDX
: code for per-card drivers in the kernel? YIKES! Even assuming that
: we could find someone craz^H^H^H^Hmotivated enough to yank this
: screaming out of XFree86 and into the kernel (unless you have the
: temerity to suggest that all such development should be done from
: scratch!), it would be a never-ending responsibility as each new
: generation of cards came out, and some popular current-generation
: cards like the Matrox would probably never be supported. This just
: moves the problem onto the one group of people (the OS hackers) who
: are the least motivated to solve it, rather than leaving it more
: comfortably with the graphics hackers who already populate the various
: X groups.
:
We just had half of this discussion on the NetBSD mailing lists. The only
thing that I suggested that didn't get cut to pieces (glad I can say "student"
as an excuse, just kidding) was that perhaps having the DDX layer be
dld'd into the Xserver would be a better idea.
That way, the server stays modular, the kernel stays small, the Xfree guys
do the work, the kernel guys keep their hands in the kernel proper,
and we have a collection of .o files to distribute instead of entire
binaries. It also keeps the server source from diverging when different
people start working on different cards. Just use the common server, and
write a new ddx.
: 2) Implement "fallback drivers". Such a driver is a
: standard driver implemented on BIOS calls. For
: video, this is INT 10. This will be sufficient
:
: That's probably not such a bad idea for a wide variety of things (like
: disk drivers also), but as yet the work remains to be done and there
: isn't even anyone currently taking it up, AFAIK. It's been on the
: wish list for almost 3 years now.
:
I smell a volunteer!
: ] communications like MAPI and ODBCS and OLE?
:
: SMTP/POP, SQL/UNIX_ODBC, and ICCMP/IPC/REXX.
:
: Sorry, those are the wrong answers but you do get 300 points for
: knowing your acronyms! Thank you for playing UNIX Jeopardy(tm)! :-)
:
: Judges say:
: SMTP != MAPI. SMTP is a different level of interface, and the
: presence of SMTP alone does very little to give an application
: which "just wishes to send some mail" an *easy* way of doing it.
: If you'd read the MAPI spec there would be no way in heck you'd
: even have tried to compare them - it's like saying the Flintstones'
: cars have an ABS braking system because they can always just
: lift their feet up if the cars start skidding! :-)
:
: SQL != ODBC. SQL is a query language and ODBC is a set of standard
: API calls that an application can make directly to an underlying
: database. Creating SQL queries programmatically, or even using
: embeded SQL and a precompiler, is a whole 'nother bear and not even
: close to the ODBC API.
:
:
Uh, so what's to stop somebody (except time) from getting ahold of the
specs to MAPI, et al, and hacking a mail program or something or other
to provide the API at the C program level?
Hmmmm, where do I get these specs, anyway?
: Naw, that was the Bavarian Illuminati at work, Terry! They contacted
: Ray and threatened to show him compromising pictures of Ross Perot's
: daughter if he didn't resign - it's a conspiracy, I tell you! :-)
I knew it!
: Thanks for the engineering lesson, Terry. However, we still have to
: live in the real world and if you strongly think that you have any
: chance of re-educating the world-wide base of programmers then I can
: only suggest that you start a training company and give seminars!
: You'll make a bloody fortune. Until then, certain mistakes will
: continue to be made and we'll be faced with the limitations that come
: out of same.
:
You don't think I have a chance at re-educating my comp. sci department
then? Shucks. I was hoping for a course of study that didn't *TEACH*
void main() for crying out loud!
: The first can be dealt with using TWIN (or WINE, if it ever gets
: done) to keep the API's the same and reduce porting changes and
: therefore costs.
:
: I'm not holding my breath on this one - I've been disappointed too
: many times. Sun spent a fortune on WABI and it's still not a solution
: one could recommend. I'd be happy to be pleasantly surprised, of
: course, but this particular panacea seems to be suffering from a
: rather tarnished reputation these days.
:
What was the old joke?
A user was speaking to a Sun engineer:
User: Sir, I'm trying to use WABI to run Windows programs, but it crashes
about 3 or 4 times a day!
Engineer: Hmmm, that sounds about right for Windows.
: I'd argue that the original code base was flawed.
:
: I've worked probably 50 different contracts in my 18 year career (and
: some 10 full-time positions) and I've yet to see a code base that
: wasn't. Reality striketh.
Hail Hail! People, don't use global variables, dammit, it gives co-op students
fits when they (me) have to deal with the broken code.
:
: You can bet Microsoft is suffering the same problems on transition
: to Windows NT. The main reason that Windows programs aren't
: running on all the NT platforms instead of just the Intel ones
: is that Microsoft has their share of programmers that think:
:
Mom: "But millions and millions of people use Windows, it can't be that bad!"
Me: "Mom, millions and millions of people don't know any better."
I know lots of students that only care that it works, then, and don't
give a whit about correctness. I hate these students, they tend to
have high GPAs because they spend so much time working on their
computer science homework, and they never get a chance to learn about
computers. High GPA tends to lead to job.
You know the ones, they have 3.5 or better GPA, Senior year, and you
put them down in front of the Unix boxes they have been using for 3-4
years, and they are lost the first time something slightly different
happens.
"How come gcc can't find the sin function? I included the math.h file,
it should just work, right?"
Loser. I can't wait till I graduate.
--
XCOMM Kevin P. Neal, Sophomore, Comp. Sci. \ kpneal@interpath.com
XCOMM Frue, Secret Agent of Smerp (shh!) \ kpneal@eos.ncsu.edu
XCOMM Visit the House of RetroComputing at / Perm. Email:
XCOMM http://www4.ncsu.edu/~kpneal/www/ / kevinneal@bix.com