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!gatech!newsfeed.internetmci.com!in1.uu.net!news.artisoft.com!usenet
From: Terry Lambert <terry@lambert.org>
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: Sat, 13 Apr 1996 15:02:47 -0700
Organization: Me
Lines: 384
Message-ID: <31702487.420C2193@lambert.org>
References: <4ki055$60l@Radon.Stanford.EDU> <jdd.829261293@cdf.toronto.edu> <yfglok14n5r.fsf@time.cdrom.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.system:21213 comp.unix.bsd.386bsd.misc:548 comp.unix.bsd.bsdi.misc:3137 comp.unix.bsd.netbsd.misc:2935 comp.unix.bsd.freebsd.misc:17183 comp.os.linux.advocacy:45051
Jordan K. Hubbard wrote:
]
] 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
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
identical in usage to the Windows environment, so training of
Windows users is portable to Motif style-guide compliant
systems.
] 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).
This one is easier; it is completely technical, and I have
tried to push it in a large number of comercial organizations,
including Novell USG (the former USL) without success:
1) Move the DDX code for per-card drivers into the
kernel. This allows you to save the state of
otherwise write-only and therefore unrestorable
video mode registers, etc.. X must use an
interface that does not require process cooperation
to restore the screen contents.
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
to put the screen in 640x480 graphic mode for the
95% majority of PC hardware capable of running a
protected mode OS.
3) Implement a full VM86(). Because the fallback
drivers must operate from protected mode, you
will need virtual machine technology to make BIOS
calls from protected mode to implement them.
4) Either discard the concept of memory overcommit
altogether, or allow it to be selected off.
5) Enable more explicit processor detection. This
is necessary to implement APM for systems without
APM BIOS capability. APM BIOS capability should
be ignored.
6) Build your "magic install image".
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".
So all you have to do is "restore" the APM save (which should
take a little less than 10 seconds), fill in the machine name
and base IP information, if network connected, and hit return.
The hardest part is writing the standalone APM restore code
program, to be run as a boot or as a DOS executable.
] 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.
The default INT 10 video modes for the card dictate the initially
available screen resoloutions, IFF the X DDX is in the kernel
instead of in the X server software.
Some additional technologies apply at this point.
The first is kernel paging, to allow you to discard fallback
drivers when card-specific drivers become available. This
requires ELF or similar object file format technology for
segment attribution in the default kernel image. Discarding
fallback drivers prevents you from needing to rebuild a minimal
kernel, but isn't required if the build process can be automated.
The second is a card/monitor selection dialog, like the
"screen preferences" control panel in Windows95, which is
a trivial thing to provide for the selection of mode lines.
The biggest problem X faces is oddball screen resoloutions so
that sp,e weenie can get 10 more pixels out of his overscan
area than the monitor is rated for.
] 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?
Another easy problem; sample answers might be, in order:
1) It's the "control panel" option on your "Start" button
menu.
2&3) Click "Display" in the "control panel" window to pick
your color pallette, fonts, etc.
4) Click "Mouse" in the "control panel" window to change
your mouse settings (including button assignment).
5) The editor is that dumb program that acts like the
Netscape editor when you click on text files (or you
can run it by picking "create new text file" from the
"start" menu).
6) The paint program is the program that starts up when
you click on paint files (or you can run it by picking
"create new bitmap(/icon/pixmap/picture/image/etc.)"
from the "start" menu.
] 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.
X is a windows system, not a user interface. Just like Unicode
is a character set standard, not a glyph encoding standard.
Just like UNIX isn't hard to use, UNIX tools are hard to use.
] 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?
SMTP/POP, SQL/UNIX_ODBC, and ICCMP/IPC/REXX.
] 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.
This is simply not true.
UNIX has two types of standards: good ones (defacto) and bad ones
(industry mandated for the purposes of competitive advantage).
Motif is a strange bear, in that it falls into both groups: it is
the defacto GUI standard for X, and it is an industry mandated
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
were involved (for instance, the major UNIX vendors do not pay
a dime of royalties for Motif and MWM distribution -- Novell
"bought in" with the NetWare UNIX Client, and other companies
paid for their good-ol'-boys-club membership with their own
proprietary standards).
It's an issue of the companies in the UNIX market not being
able to think well enough to get the correct soloution to the
game theory problem of the prisoners dilemma (I recommend the
books "The Evolution of Cooperation" and "Bionomics"). And you
can't fix that without incresing their review periods: how do
you propose to convince the NYSE to live with annual instead
of quarterly reports?
] 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".
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.
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.
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.
] 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?
Porting cost is a function of developemental 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.
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.
The second can only be dealt with by yelling "WAKE UP, WEENIE!
THE PEOPLE WHO WANT BACKWARDS COMPATABILITY WITH YOUR 2.0
NETWARE ARE NOT THE PEOPLE SPENDING MONEY ON YOUR 4.0 NETWARE
SERVERS!" (to pick one example).
] 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.
You mean "making Intel/DOS/Windows-centric code run"? 8-).
WordPerfect had the same problem: most of their code was in
Intel assembly, and "porting" was the process of converting
that assembly to C code that still looked like assembly, and
rewriting the user interface from scratch.
Spreadsheets and word processors are examples of applications
with very little code beyond user and system interfaces. I
think the comparison is unfair.
I'd argue that the original code base was flawed.
It screwed them horribly when they had to support Windows, as
well. This is why the relative popularity of WordPerfect vs.
Microsoft Word.
] 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.
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:
#pragma pack(1)
struct foo {
char c1;
long l;
char filler[ 3];
};
#pragma pack()
Is an "aligned" structure because it has an even dword-sized
footprint. Check the header files in their SDK and DDK if you
don't believe me.
To say nothing of alignment of the stack on function entry, or
non-character auto variables that have to be referenced from there.
"Microsoft's problems" is another way of saying "competitor's
opportunities".
] 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.
Yes. The problem with UnixWare is that the interface was a rush
job, and so they were unsuccessful, as you point out. I would
say that current versions of SMIT are more than successful, that
SMIT has cheering sycophants in some places.
NeXTStep's "NetInfo" crap is another example of less-that-successful
hiding.
But you only have to look at "vipw" and the password database in
FreeBSD to see that "successful hiding" doesn't provoke the same
response.
It is the lack of success -- *technical* lack of success -- that
is objectionable to the old line, not the attempt at data-hiding.
] In any case, these are hardly sterling successes to point to
] and they took their respective developers *years* to develop.
You obviously weren't there for UnixWare... I was in the same
building where it started, and many of the people I worked with
and around went to the second floor of Novell, Sandy at the start
of UnixWare. It wasn't years, and they faced hellacious adversity,
mostly from the former USL (management, not engineering), who
mandated some home-grown, but antiquated technologies in the
face attempts to acquire shining examples of UNIX prowess -- like
Visix's "Looking Glass" interface, or a real Motif instead of
"Moolit", or ZMail.
Several of the people whose technical sensibilities were *most*
trod upon in this process are the very people who started Caldera
(after USL-now-Novell/USG management succeeded in convincing the
new CEO that the internal Linux project was endangering UnixWare
and got it scrapped).
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).
] 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.
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).
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.