Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!hobyah.cc.uq.oz.au!bunyip.cc.uq.oz.au!munnari.OZ.AU!news.ecn.uoknor.edu!paladin.american.edu!gatech!newsfeed.internetmci.com!info.ucla.edu!library.ucla.edu!agate!reason.cdrom.com!usenet
From: jkh@time.cdrom.com (Jordan K. Hubbard)
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)
Date: 14 Apr 1996 04:11:20 -0700
Organization: The FreeBSD Project
Lines: 355
Sender: jkh@time.cdrom.com
Message-ID: <yfg3f67giw7.fsf@time.cdrom.com>
References: <4ki055$60l@Radon.Stanford.EDU> <jdd.829261293@cdf.toronto.edu>
<yfglok14n5r.fsf@time.cdrom.com> <31702487.420C2193@lambert.org>
NNTP-Posting-Host: time.cdrom.com
In-reply-to: Terry Lambert's message of Sat, 13 Apr 1996 15:02:47 -0700
X-Newsreader: Gnus v5.1
Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:21267 comp.unix.bsd.386bsd.misc:566 comp.unix.bsd.bsdi.misc:3159 comp.unix.bsd.netbsd.misc:2966 comp.unix.bsd.freebsd.misc:17228 comp.os.linux.advocacy:45197
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.
Yes, Motif can be had at a relatively low cost but it's still not
something we can standardise on for the free operating systems when
we've got the OSF sticking their hands out at the toll-booth saying
"$60 royalty please!" every time someone downloads a copy of one of
these OSs from their friendly neighborhood FTP server. I'm sure that
the distinction between a freely available windowing system and a
non-freely available GUI standard isn't lost on you, and you yourself
later say:
standard that requires a buy-in to OSF to let you play. Motif
is proprietary technology, and as such, should never have been
ratified by a standards body. Either bench-packing or buyoffs
Getting Motif ratified by the free operating systems camps is
currently sort of like getting a snake through a narrow hole after
it's swallowed a very large gopher. You can get people to accept only
as much snake as makes it through until you run into the, erm,
obstruction.
And don't tell me that this doesn't effect the solution providers
since we can ship our binaries static - one of the nicest things about
the Free OS world right now is that today's customer can become
tomorrow's solution provider due to the low cost of entry for
volunteers. Finding programming volunteers willing to help provide
high-level UNIX solutions is hard enough as it is without having to
say "oh, and guys, you'll have to pony up $100 for one of the Motif
distributions before you can jump on the GUI hacking bandwagon with
us." No thank you!
I know that Motif has the lowest training cost, but I've talked to the
OSF about their rock-bottom-minimum royalty arrangements and there's
just no relief in sight for the *monetary* costs and, as you say, it
should therefore have never been ratified as any kind of standard.
This one is easier; it is completely technical, and I have
tried to push it in a large number of commercial organizations,
including Novell USG (the former USL) without success:
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.
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.
Do bear in mind that my postings were attempting to describe the
situation as it stands today, leavened with a healthy dose of realism
about what we might hope to accomplish in the next 12 months or so.
No offense, but your postings always have a large element of the
surreal to them (were you Franz Kafka in a previous life?) where you
gesture wildly in all directions about highly theoretical solutions
and many "if we just virtualize the frammis and re-implement the
frotch code as a multi-layered, stackable protocol breemitch, it'll be
trivial to..." sorts of suggestions. Left unanswered for me at the
end of each reading is the rather bemused question of "Yeah, but WHO
is going to do all that work? Who?!"
I also fully realize the value of theoretical contributions and the
fact that it took a number of guys sitting around chalk boards in dusty
classrooms before the first atomic bomb could ever be detonated in New
Mexico, but $12 billion dollars and one General Groves requisitioning
every resource in sight had quite a bit to do with their success(?) as
well. One type of applied resource without the other is quite useless
if it's your intention to actually produce a working prototype.
Perhaps I shouldn't have used the atomic bomb as my analogy since I'll
now get flamed (pun intended) for it, but I hope you get the point.
I've heard much of this before but still don't have anyone signed up
to do it in any kind of time-frame that would be useful to us, so
it'll have to go into the "interesting theoretical suggestion" pile.
Now let's talk about "magic install images". Such an image is
a non-memory-overcommit (fd's are not strictly recoverable for
executables) APM save image of a sytem "just about to be
installed".
I'd need to see a prototype of this before I could even begin to
believe there weren't 500 different "gotchas" still waiting to spring
on the unwary implementor. You yourself well know that with the
implementation of every new idea you have 10% of the development time
spent in a frenzied blitz on the proof-of-concept ("Yay! It's
possible! It sort of works!") and 90% trying to actually make it work
in enough cases to become a truly general solution. I'm left with
many questions about how the initial machine state would be
initialized by such a load-it-whole kernel, for example, and I'm sure
that an entire host of other uncovered problems remain to be exhumed
and wrestled with. Like the concept of a matter teleportation device
being used to transport live human beings, this one is too theoretical
to comment on - we need a working prototype to examine before we can
even begin to develop an idea as to how truly practical an idea it is.
Another easy problem; sample answers might be, in order:
1) It's the "control panel" option on your "Start" button
menu.
Yeah, but you need to write this, first. There *is* no easy to use
control panel application for X, hence it's an education problem and
will STAY an education problem until someone implements it.
Terry, again, you can't just explain every problem away with a glib
"well, that's simple - just write a control panel and a nice paint
program and a word processor and a device configuration utility and
maybe one of those nifty event log display programs like NT has and
and.. Geeze, what's your problem, Jordan? The problems you raise are
_trivial_ to solve!" :-)
X is a windows system, not a user interface. Just like Unicode
Bingo! Thank you, Terry. Now that we've both agreed on that, we can
try to find some nice non-proprietary solutions to the problem and
hope that everyone is willing to sit patiently for the 2-5 man-years
it will take to implement them? You say my estimate is too long?
Fine - prove me wrong, please! :-)
] 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.
I won't even try to refute your contention that OLE has anything
which merits a direct comparison to standard IPC or even a language
like REXX (which is hardly a UNIX standard to the degree that OLE
is for Windows - only AREXX for the Amiga ever even came close to
this degree of wide acceptance). I can only conclude that the straw
you were reaching for broke as you attempted to grasp it and you
decided to go ahead with the comparison anyway in hope that no one
would notice.. :-)
UNIX has two types of standards: good ones (defacto) and bad ones
(industry mandated for the purposes of competitive advantage).
Maybe we just have a highly different definition of the word
"standard" here. I define a standard as something that's widely
embraced by vendor, user and application provider alike - not merely
something published as a white paper and widely agreed to be a good
idea by all the programmers and perhaps a couple of the ISVs who read
it.
Motif is only a "standard" because the users were so tired of the
bitter infighting ("the GUI wars") that they would have sold their
souls to the devil if he'd only come along with a contract promising
to lead them out of the combat zone and give them ONE set of UI
guidelines to follow. As history shows, that's also exactly what they
did.
I don't really see any other standards worth talking about in the UNIX
world today (Unix95? Oh great, *another* standard that you have to
pay a lot of money for the privilege of adopting!) so this will be a
very short argument.
] The fact is that it's already too late for UNIX on the desktop.
You sound like Kanwahl Rheki in a meeting I attended at Novell
right before he (ahem) "left Novell to pursue other opportunities".
Hah, he's not the only one! Lotus' director of UNIX development
started his keynote address at the Irish Unix User's Group with those
very same words. I'm sure Kanwahl left because he didn't much like
the role of Cassandra - right and despised for it nonetheless.
I remember him making a similar statement about UNIX on the
desktop, after which I raised my hand and asked "What *NOVELL*
operating system will people be running on their desktop, then,
if not UnixWare?". To which he replied Novell USG would be
concentrating on application servers.
I don't understand that statement at all. Novell didn't *have* a
desktop operating system, so what? You raising your hand and saying
"I see an orange, a drugged hamster and a pound of Earl Grey tea here
on the table - which are we going to use in our fight against crime?"
would have made just about as much surrealistic sense. Novell didn't
have a desktop strategy, never had a desktop strategy (that they ever
showed the world in any significant way, anyway, and their brief,
aborted affair with UNIX hardly counts) and probably never WILL have a
desktop strategy. They made their money selling network servers and
that's really the only market they understand. Duh. You groom a
whole legion of executives to go out and try to dominate the network
connectivity market, it's hardly a surprise that their vision becomes
narrowed.
Hmmmmmmm... Ray Noorda left after that statement, and less than
a month later the group that later broke away to become Caldera
came into existance... hmmmmmmmm.
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! :-)
With due respect, anyone who portrays a technical market as
"impenetrable" or "already won by the competition" is a jackass
who is going to drive your product into the toilet.
And anyone who tries to make a silk purse out of a sow's ear will find
themselves holding a bloody scrap of flesh with little resale value.
Can we stop spouting the meaningless aphorisms now? :-)
Porting cost is a function of developmental architecture and
approach to implementation.
Most modern GUI builders are causing this gap to widen, but it
boils down to programmers who don't understand portability
issues, and attempts to salvage sales from legacy markets.
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.
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.
] I worked for Lotus's UNIX porting group (where I worked on the ports
] of AmiPro [now Lotus Word] to the Sun and SCO platforms) and I can
You mean "making Intel/DOS/Windows-centric code run"? 8-).
Of course. You think a company that makes $2 billion dollars a year
off the Windows market and $300K off the UNIX market (real figures
from when I worked there) is going to pervert their code base at the
request of a few UNIX weenies? Get real! The windows weenies will be
the star programmers with their gold plated keyboards and $10K
development bonuses and the UNIX development weenies will be happy to
have jobs at all and take whatever they can get. No amount of
up-front pleading for "porting awareness" will help, either, as market
forces will simply take over and feature after feature will creep into
the Windows product, making it a harder and harder target for
portability. Even if the Windows programmers are best friends with
the UNIX programmers and utterly sympathetic, this will happen with
any substantial code base. Market and deadline pressures will out
every time!
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.
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:
Oh, I know. I've even heard that Win95 suffers from a considerable
defection rate in the OS group from programmers who desperately want
to escape a 10 year old ball of mutant fur and get into the NT group
where at least things were more-or-less designed. My heart bleeds for
them, really! :-)
"Microsoft's problems" is another way of saying "competitor's
opportunities".
Aw, they've got enough money that they merely need skim the cream off
the top of another 2 or 3 year's worth of CS graduate classes to get
through this temporary setback ("Come work for Microsoft, little boy!
It'll look great on your resume' and we'll give you nice this sack of
money, too! C'mon, hop in the car! It's just a short ride from
here!")
You can't generalize about the possibility to create a successful
UNIX desktop simply because UnixWare failed to do so (and not for
technical reasons, at that).
I wasn't generalizing ONLY because UnixWare failed to do so, but you
have to admit that there aren't very many existing examples *to* point
to! I thought I was being rather fair in not even mentioning SCO's
Open DeathTrap! :-)
I think this was the argument to congress about Apollo after
the fatal fire, and again about the shuttle after the fatal
administrative decision to launch under conditions where success
was impossible.
Please *don't* make the same argument to the UNIX industry at
large after the "fatal" UnixWare launch (which wasn't all that
fatal, if you want to compare sales numbers with them).
Oh, I'm not. The UNIX industry's problem was never one of
discouragement from lack of success, and I was only citing some
examples of how other attempts had gone south. No, the UNIX
industry's problem was that they never even could agree on which
direction to point the rocket, much less how to build one, and a
jury-rigged and unfinished prototype sat on the launching pad for a
decade while groups of white coated engineers rolled around on the
grass, pulling one another's hair and screaming "The Moon?! NO, NO,
Mars you idiot! The rocket's going to Mars or I'm outta here! Mars?!
Venus, you utter moron! That's where the women are!"
Predictably, they all eventually wandered away, rubbing their bruises
and brushing mud out of their hair. Some went off to work for the
ESA, launching much smaller rockets into low orbits, while others
elected to sit on their front porches drinking Jim Beam from the
bottle and launching bottle rockets from the empties.
Jordan
--
- Jordan Hubbard
President, FreeBSD Project