Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mira.net.au!vic.news.telstra.net!act.news.telstra.net!imci3!imci2!news.internetMCI.com!newsfeed.internetmci.com!info.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: 12 Apr 1996 05:55:28 -0700
Organization: The FreeBSD Project
Lines: 201
Sender: jkh@time.cdrom.com
Message-ID: <yfglok14n5r.fsf@time.cdrom.com>
References: <4ki055$60l@Radon.Stanford.EDU> <jdd.829261293@cdf.toronto.edu>
NNTP-Posting-Host: time.cdrom.com
In-reply-to: jdd@cdf.toronto.edu's message of Thu, 11 Apr 1996 22:21:33 GMT
X-Newsreader: Gnus v5.1
Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:21222 comp.unix.bsd.386bsd.misc:550 comp.unix.bsd.bsdi.misc:3139 comp.unix.bsd.netbsd.misc:2939 comp.unix.bsd.freebsd.misc:17189 comp.os.linux.advocacy:45071
In article <jdd.829261293@cdf.toronto.edu> jdd@cdf.toronto.edu (John DiMarco) writes:
What will it take? All relevant shell and file interfaces will need to be
replaced by simple, point-and-click window-based interfaces (with sensible
defaults), so that completely applications-oriented users can install,
configure, and use the operating system without even having to know what a
shell or an editor is, let alone how to use one. Tools to efficiently build
such a thing (eg. tcl/tk) are already in place. Yes, this is a concept
foreign to the typical UNIX mindset, but it's required if any UNIX-like
operating system will gain a foothold among the general computing population.
Actually, this isn't as foreign as you might think. It's more the
question of _how_ to reach this point that has many of even the most
die-hard proponents of this approach scratching their heads. The
problems facing any such prospective "let's put a new face on UNIX"
team are daunting, to say the least:
First, you have the problem of a standardised GUI and how to get the
user from point A (a CDROM in one hand and a PC on the desk) to point
B (a fancy graphical interface complete with "click here to start"
button).
X is notoriously hard to configure, and anyone wishing to get the
average Windows user aboard the UNIX bandwagon faces a considerable
job just getting them up and running reliably with the bewildering
array of graphics cards available and a UNIX environment that's
usually left the BIOS (and all the standard, however braindead,
interfaces it might have provided) far behind by the time you're
running the X component of the installation. Even getting your
average card into SVGA mode is not as easy as you'd think, and there
are people in both the XFree86 and X Inside, Inc. camps who have
devoted considerable time and energy in pondering that question. The
upshot of this is that right from the opening "Windows" screen,
Microsoft has got us somewhat outclassed and have already detected the
mouse and modem at the point that we're still loading a kernel off a
floppy.
Assuming that you do manage to somehow get Joe User up safely into X,
your problems are far from over - now you've got a massive education
problem on your hands. Where is the "setup" menu? How do I pick my
color pallete? Where's the list of available fonts? How do I swap
the mouse buttons if I'm a lefty? Where's the editor? Where's the
paint program? ARGH! Where did I put those Windows disks? Face it,
the average user's expectations have been irrevokably set by the
Macintoshes and Windows boxes, and while the X community should have
been off inventing all those good things and trying to put them into
an easily accessible framework, they were focused instead on seeing
which competing GUI group ("OpenLook!" "No, No, Motif!" "Argh,
NeXTStep you philistines!") could kick the other the most times in the
crotch.
The result is an interface that only a programmer could love, and so
it's hardly then a surprise that only the programmers generally do. X
started out as a wonderful experiment in interoperability and has now
turned into a 10 ton millstone around UNIX's neck. Sorry, I know it's
painful, but that's the truth. Unfortunately, it's also all we've
got.
And we've only dealt with the lowest-level aspects of the interface.
How about all those nice front-ends you talked about? How about
standard APIs for mail and database access and inter-application
communications like MAPI and ODBCS and OLE? Sure, all of the
standards represented by those acronyms are GROSS and generally
unworthy of even mentioning in a crowd of UNIX geeks (lest you be
pelted by rocks and garbage) but when you ask what the competing
alternatives under UNIX are, you'll get a long silence followed by a
few pathetic attempts at "Well, there's ToolTalk I suppose, though
only Sun seems to really support it in their apps and it doesn't deal
with objects very well, and well, you could also always buy a nice
CORBA compliant system for that and wait for the vendors to start
using it and I hear there's some work being _done_ on the database
front though I couldn't promise that any of the apps will work with it
yet and and and..." In other words, you'll get a mismash of
well-intentioned but strangely unadopted (at least by anything
resembling a majority of UNIX ISVs) standards, all twisty, all
different.
The painful truth is that Microsoft proved that having one vendor with
a big stick *IS* sometimes the only way to keep a classroom full of
hyperactive pre-school children in line, as much as the children might
prefer to be allowed to smear peanut butter on the dog and set fire to
the drapes. UNIX never had such an authoritatian figure so it evolved
standards faster than most people could invent acronyms for them.
For the average UNIX hacker this never mattered anyway since if he
wanted an app real bad he just wrote one from scratch or cobbled it
together using AWK and a couple of shell scripts. For word
processing, who needs more than EMACS? He'll give up his shell prompt
when you pry it from his cold, dead fingers.
The naive user? Sorry, we eat those for breakfast around here. Try
the Windows support group next door.
The fact is that it's already too late for UNIX on the desktop. It
didn't evolve in _any_ of the directions that your Word-using
secretary (who occasionally dives into Powerpoint when the boss really
requires a last minute presentation) is going to be able to benefit
from. Even if were were to suddenly reach down UNIX's throat and pull
it inside out by the small intestine, it wouldn't matter to the ISVs
who have long since abandoned any pretense of porting their software
to the UNIX market. What would be the point? 5 times the porting
cost (and that's speaking _very_ conservatively, considering that
there are quite a few more than 5 popular variants of UNIX out there)
for a market 1/500th the size?
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
tell you that we got some very strange looks indeed from the rest of
the corporate IS managers when they learned that we needed $200,000
worth of equipment and 6 different operating systems gurus to do the
same job that a Windows engineer with a $3000 PC on his desk was
doing. If it hadn't been a checklist item for a few UNIX hold-out
customers, we'd have ceased to exist in an eyeblink (and eventually
did, but that's another story). Believe me, your average desktop
software vendor finds the UNIX market unprofitable, baffling and
utterly unworth the development dollars that they could (and do) spend
much more profitably on Windows or OS/2. Sure, there are a very few
small niche players who are leveraging existing UNIX expertise and
small captive markets to make a few bucks, but that's purely on the
atomic scale in comparison to the size of the Microsoft market.
And that's just the applications arena. Let's assume that you just
wanted to tackle the automation and reduction-of-complexity issues
surrounding system administration of servers and other environments
where UNIX still has a clear advantage. Woo boy - talk about walking
into the lion's den! Your average administrator is not (or at least
should not be) an off-the-street paper shuffling secretary, and they
have very clear ideas about what sorts of tools constitute aids to
progress and which are simply a pain-in-the-butt and totally in their
way. You need only look at the reception that UnixWare got when it
attempted to "go graphical" in just about every major respect. The
old school die-hards hated it since it tried to hide things rather
unsuccessfully and, in many cases, gratuitously from the administrator
and the novices didn't like it either since it really didn't help them
anywhere near as much as they were hoping. The same is true for AIX,
though I've heard that SMIT is somewhat less passionately hated now
and there are even a few people here and there who will admit to
liking it when they don't think that anyone's listening.
In any case, these are hardly sterling successes to point to and they
took their respective developers *years* to develop. It seems a
rather strange use of one's time to embark upon the same road,
littered as it is with the bones of those who went before and ending
in a tall cliff. Putting a "nice face on UNIX" has been tried, and
those that have done so have invariably list "never again" as their #1
response to those who would dare to try the same. UNIX is *not*
Windows, and in trying to make it look like Windows you generally end
up pleasing almost no one and getting a few arrows in your back for
the trouble.
So is it all gloom and doom from yours truly? Not really.
There are still things we can do. We can try to make X a more
comfortable environment to work in, not overnight or even by next
year, but incrementally and cooperatively (e.g. no more 12 different
implementations of the same thing if anybody can help it). We can try
to make it easier to set up and configure and, once we've got users
over that hurdle, we can try to figure out how to provide canned
desktops that spare the beginning user from having to figure out which
window manager is in vogue that month and now to get something up
which is actually fairly usable on the first try, with no serious
customization needed. No rocket science required, just some solid
work on trying to make the whole process a little more more menu
oriented instead of sticking up a "% " prompt and saying "have fun,
dude!"
The same goes for enhancing the documentation on all the various weird
files in /etc, putting some work into developing tools that make it
easier to find out what needs to be changed where, even if you don't
necessarily do the edits on behalf of the user. There's no substitute
for a good set of *well organized* hypertext docs (for which HTML has
been a god-send), given that such are useful to power-user and
relative novice alike and don't invite AIX-style flames about trying
to hold the user's appendages without their permission.
Finally, we can also work on minimizing the number of competing APIs
so that those few software vendors left who see a couple of bucks to
be made in the UNIX market don't need to churn out 12 different
distributions of their software, raising their blood pressure and
lowering their profit margin. I've actually stopped asking people for
FreeBSD native binaries and have started asking for *BSDI* binaries in
the hopes that if they can simply target one of our "sister" operating
systems which is also comfortably (for the ISV) commercial in nature,
we can simply ride off the same applications base with no additional
trouble. This is hard to swallow for some, native binaries being
generally seen as "an ego thing" and lack thereof somehow leading to
the perception that your operating system won't be seen to count as
much as the native one. That's a lousy attitude, and the fact is that
we can either converge towards common ABIs or we can see the
application software vendors continue to wander away until we're
fighting like wild dogs over a few pathetic scraps. If Linux becomes
the common ABI, that's fine. We can run your a.out and ELF binaries.
If it's BSD/OS, that's fine too - we've been able to run their stuff
for years now. If we can't run a given binary, we need to figure out
how to MAKE FreeBSD run that binary. What we can't do is beat on the
table and say "FreeBSD deserves native versions from you, damnit!"
Even if we manage get away with it, it just won't fly as a long-term
strategy.
Jordan