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