Date: Sat, 7 Jan 1995 15:49:33 -0500 (EST) From: Wankle Rotary Engine <wpaul@skynet.ctr.columbia.edu> To: freebsd-hackers@freebsd.org Subject: Graphical installations and such... Message-ID: <199501072049.PAA05164@skynet.ctr.columbia.edu>
next in thread | raw e-mail | index | archive | help
I know that what I'm about to say probably won't be well received, but
this is how I really feel, so I have to say say it:
All this talk of trying to come up with an X/Tcl/Tk/whatever-based
installation system touches a raw nerve in me. I happen to feel that
this is exactly the sort of thing that needs to be avoided. There's
been a lot of discussion over how to maximize the chances of getting
X11R6 up and running on a user's system on the first shot, what sort of
workarounds to use if X can't or won't come up, and, in general,
how to make things easy for (possibly inexperienced) users.
Well I think this is the wrong thing to do. It sounds almost like people
want to turn FreeBSD into Windoze. Well forget it: that's a horrible idea.
FreeBSD (and UNIX in general) is *NOT* Windoze, pure and simple. Don't
bow to the pressure of clueless users who whine about the lack of a nice,
glitzy graphical installation program: you'll spend so much time trying
to cater to their whims that you'll lose sight of the more important
goal, which is producing a stable and robust operating system. I'd rather
have a killer OS with an ugly (though reliable) installation program
than a clunker with a pretty face (like Windoze). And it's just plain
dumb for people to be concentrating on making the install look pretty
when there are device drivers that need tweaking.
I don't think a graphical install should be an option at all. (Sorry
Jordan: I know the thought of a pretty Tcl/Tk installation script makes
you all warm and squishy inside, but you can't paint with broad stokes
when all you have are small brushes.) You need to take into account the
lowest common denominator, and right now that's a text display. Supposing
someone wants to set up a dedicated server and they decide to use a junky
CGA display board and CGA monitor that they happen to have lying around.
Or, better still, supposing they decide not to use a display at all: what
if they want to hang a dumb terminal off a serial port? (As an aside, it
would be neat if there were some way to tell FreeBSD to use a serial port
as a console at boot time, instead of having to hardwire it with 'options
COMCONSOLE.' Anybody working on this?)
Sure, you could come up with both a graphical and non-graphical install
to make everybody happy, but there's still the matter of cramming the
extra software onto the install floppies. Everybody, whether they want
a greaphical install or not, will have to carry a bunch of excess bagage
around. And don't hand me that line about installing from the CD-ROM:
there are still plenty of people out there who download FreeBSD from the
Internet and who depend on the floppy install method to get it running.
There are also plenty of people who own CD-ROM drives that FreeBSD does
not yet support. Face it: the floppy install will be around for a while,
so it's in everybody's best interests to keep things small and simple.
(Also, you'd be surprised at the stupid things people will do when they
have 600 Mbytes of space to play with: Sun's Solaris 2.3 install goes
through all the trouble of loading OpenWindows 3.3 off the installation
CD just so it can run a text-based installation program inside a
shelltool window. I'm not making this up.)
Look: the X server alone is big. The X libraries are big. Statically
linked X binaries are very big. Tck/Tk is big. Just how were you planning
on fitting those big things onto the boot disk, hmmm? Sure, if you mount
a CD-ROM as your root filesystem you can get around this problem, but
that won't be an option until FreeBSD supports more CD-ROM drives. The
initial boot disk is needed to partition the user's hard drive so that
the second stage of the install can be loaded. Once that's done, you
could load all kinds of software from any number of 'cpio floppies,' but
using a graphical installation just for the second part of the install is
stupid: I refuse to believe that a memory-sucking X11-based monstrosity
is really needed just to unpack a lousy bunch of tar files.
That's what this boils down to, folks: burying a couple of otherwise
simple operations under tons and tons of graphical manure, just to make
some simpletons happy. It's been established that UNIX, in general,
works, and works well. It's also been established that it isn't as
maddeningly inscrutable as people alledge it to be. Hell, I learned
to deal with it, and I'm an idiot. There's a reason for that (that I
learned to deal with UNIX that is, not that I'm an idiot): I took
C programming and UNIX internals courses in college. These didn't
exactly elevate me to the same level of expertise as Ken or Dennis,
but without them I'd probably still be fumbling around in the dark.
(I'd also probably still think that VMS was cool, but that's another
matter entirely. :) The point is that fancy shmancy graphics front-ends
are no substitute for a couple of semesters of computer science courses.
(Or reading a book.) There's only one cure for inexperienced UNIX users:
experience. And they aren't going to get any if we hide all the neat
stuff under some pretty pictures.
Okay, so now you know that I personally don't want a graphical install.
You want to know what I want instead? Okay, I'll tell you:
I recently contributed some fixes that make swapgeneric.c work again.
One of the things this does is allow you to choose what you want
to mount as your root device, if you boot with the -a flag. (You need
'options GENERIC' and 'config kernel swap generic' for this to work.
Check it out: it's cool.) This sort of brings us back to the days of the
kernel-copy floppy, but not really. You don't actually need to copy the
kernel from the boot disk onto the hard disk: you can just have it mount
the hard disk and a kernel will be installed when the bindist is unpacked.
This buys you a couple of things:
- If you take the kernel off the existing boot floppy, you gain a bunch
of extra room. (I always thought that doing away with the kernel-copy
floppy was a bad idea). Ideally this extra space should be used for:
o Splitting up the gigantic/do-everything/mega-huge install program
into a couple of smaller pieces so that people with only 4 megs of
RAM don't go insane.
o Expanding/improving the existing install scripts so that
they provide some new functionality and sanity checking. Make
that a *lot* of sanity checking.
o Possibly adding some extra utilities to make the scripts less
arcane and more reliable.
o Adding a *SHELL* for cryin' out loud!
- The kernel could be moved to a seperate boot disk (making the existing
boot disk a 'root' disk instead). You could use this boot disk to mount
either the install floppy or a hard disk, or possibly a CD-ROM drive,
without having to copy the kernel anywhere. This improves upon the
functionality that the boot blocks provide: it's not perfect, but
technically it could allow you to do strange things like mount non-SCSI
CD-ROMs as root filesystems. You could then give the user the option
of either mounting his CD-ROM, which could have a much nicer and
more expansive install package on it, or mounting a second floppy (yes,
you can take the boot floppy out and put in another one) which would
have an *EQUALLY FUNCTIONAL* but possibly more conservative install
package on it.
- Installing the kernel would be done in the process of unpacking the
bindist instead of copying it from the floppy. This means that the
kernel on the boot floppy and the kernel finally installed on the user's
hard disk need not be the same. The install kernel could be specially
configured, if needed.
- This boot disk can be used, in cases of dire emergency, to recover a
system with a damaged/improperly compiled kernel image. Maybe you
could make the boot disk into that fixit floppy that everyone's been
asking for?
That said, the picture I have in my head of the ideal install consists
of the following elements:
- A boot disk with nothing but the kernel and the boot blocks on it.
(Or, at most, a shell and some utilities so that it can be used as
a fixit floppy.)
- A root disk that's basically similar to the boot disk we have now,
only more bulletproof, less memory-hungry, better debugged and *FULLY
TESTED*. (I don't care if this delays the 2.1 release: I'd rather
we didn't imitate Sun and wait until 2.4 before we get it right. :)
- Any number of cpio-floppies containing an equally bulletproofed and
less memory-hungry second stage install package with numerous user-
configureable options and more sanity checks than humans should be
allowed to have. Note that I do not consider it bad form to increase
the number of required install floppies: 3 or 4 would not be unreasonable.
- The ability to use any CD-ROM drive that FreeBSD supports as a root
disk instead of the floppy. This is a nice perk for people who
can take advantage of it. (Be mindful of the fact that people who
use this install method won't have any VM available, since you can't
swap/page to a CD.)
- The ability to do an install from a dumb terminal on a machine with
no graphics hardware at all. You can do this with SunOS 4.1.x; why
not let people do it with FreeBSD?
- Slightly improved network configuration section. This is really a
matter of completeness: if someone has several network interfaces,
he/she should be allowed to configure them all from the install.
- Copious documentation!!
This brings me to my final point: documentation is far more valuable than
graphical 'idiot-proofing.' Micro$oft assumes that users knows nothing,
and they program their user interfaces accordingly. We should not do
that. Rather than throwing our hands up in the face of dumb users and
handholding them, we should instead try our best to turn them into something
other than dumb users. To be blunt, UNIX is not for dumb users. That said,
there should be ample documentation available for dumb users to educate
themselves. There should be an install document that outlines the steps
needed to install the software, explains briefly but completely (within
context, of course) some of the concepts involved, and refers the reader
to other more detailed documents for extra information.
Be warned: the first person who says 'HTML' will be shot. Oh wait: I
think somebody already said it. Make that the second person.
There's a chicken-and-the-egg problem at work here: the user can't read
an HTML document unless he/she gets an HTML reader installed, but they
probably won't be able to get an HTML reader installed until they read the
HTML document. Furthermore, there are a great many people (myself included)
who feel *much* more comfortable with paper documentation. There are only
a few kinds of formats I find acceptable for installation tutorials:
- PostScript (which can usually be printed out easily and can include
pictures and diagrams)
- Plain ASCII text (for people who don't have PostScript printers or
who wouldn't know what to do if they did have them)
- Any source format that can ultimately be used to generate PostScript
(for power users who can deal with oscenities like TeX)
The installation tutorial should quickly explain: what FreeBSD is; why
it is not the same as DOS and/or Windows (and why that's a good thing);
what's involved in installing it (memory/disk space requirements,
supported hardware, time required, disk partitioning techniques, etc...);
and all the possible different installation methods. It should
provide references to useful UNIX usage and administration books or
documents, a truly useful troubleshooting guide (largely for helping
people dig themselves out of disk partitioning problems), possibly a
few pictures, and, most importantly, an index.
This is not a simple 'README' file. This is a tutorial. It won't be
easy to write, but many people will love you for it.
All this talk of implementing another 'framework' is silly. The existing
'framework' is just fine: it just needs to be fixed up and debugged a
little. Copying OS/half Warp isn't the answer either: IBM shipped
OS/half with that Internet-access package to draw attention away from
the fact OS/half itself sucks so badly. FreeBSD has the potential to be
a high quality, professional OS that can more than stand on its own
merits, without the need for glitz and hype. But for that to happen,
people need to concentrate more on programming and less on marketing.
Don't blow the budget on advertising before the product is ready to ship,
okay?
Well, I think I've gotten myself in enough trouble for one day. You can
all quit cowering in the corner and uncover your ears: I'll shut up now.
-Bill
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Bill Paul System Manager
wpaul@ctr.columbia.edu Center for Telecommunications Research
(212) 854-6020 Columbia University, New York City
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Møøse Illuminati: ignore it and be confused, or join it and be confusing!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199501072049.PAA05164>