Date: Sun, 26 Nov 1995 10:57:00 -0500 From: Chris Shenton <cshenton@apollo.hq.nasa.gov> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: hackers@freebsd.org Subject: Re: Thoughts on the install and on Red Hat Linux. Message-ID: <199511261557.PAA10995@wirehead.hq.nasa.gov> In-Reply-To: Your message of "Sat, 25 Nov 1995 12:18:45 PST."
next in thread | raw e-mail | index | archive | help
On Sat, 25 Nov 1995 12:18:45 -0800, "Jordan K. Hubbard" <jkh@time.cdrom.com> said: Jordan> Nonetheless, I was favorably impressed by the sheer depth of their Jordan> coverage and I was asked enough questions to bring me all the way up Jordan> into X on the first try, the installer even giving me the chance to ID Jordan> everything from my board's clock chip to the monitor specs. Yup, this Jordan> is how to do it! A Mac-friend and I just spend about 16 hours trying to install Caldera (RH Linux, plus Visix desktop, plus Novell, plus ...). What a nightmare. The usual Linux root+boot disk (plus two, for Caldera), but I can live with that (tho I certainly prefer *one* disk with FreeBSD). Main problem was that if you didn't know exactly what hardware you had, you were hosed. Only after you selected and wrote a boot disk, then got through the entire network config dialog, did it discover it didn't recognize your card (eg: maybe you selected a boot with ed* drivers rather than le*). Same for the CDROM: very late in the install, when you're about ready to slurp it all onto the hard disk does it discover that it can't see the CDROM. Major waste of time. Jordan> My primary goal Jordan> is that we get some *robust* tools, with plenty of safety netting, and Jordan> an easy-to-use interface for them that looks halfway like something Jordan> you might expect to see on a commercial product. IMHO, it ought to do a *lot* of probing up front -- looking for every kind of device which can be stuffed onto a boot disk, and identifying all configs. A "commercial" user isn't gonna know what kind of ether or CD or SVGA clock chip or... he has on his/her Gateway, Dell, or other store-bought box. And they shouldn't have too. A simple design goal: don't let the user get down the road fail because of something that could have been determined earlier. Jordan> Once in X, the root login had a reasonable set of defaults (I made a Jordan> note: give root some reasonable .dotfiles!! :-) for bringing up fvwm Jordan> and a small desktop, Good. You certainly want to reassure them by giving them something they can recognize and immediately *use*. I'm sure we all had our problems getting our very first .cshrc/.login/.Xdefaults right! Jordan> 3. We should start looking at what we need to do to get the user into Jordan> X in as fool-proof a fashion as possible, working with the folks Jordan> doing #1 for the various GUI elements required. I'd suggest aggressive probing, then confirmation with the user, with an "out" if the user doesn't know. Failing good information on HW config, default to something most likely to work (eg: VGA X11, rather than nothing; WD8003, if that's the most prevalent ether clone, etc). Jordan> Only half, however, and their continued use of libdialog has cramped Jordan> their style outside of X (where one still spends considerable amounts Jordan> of time during the RedHat install), forcing some information to be Jordan> presented in a somewhat constrained fashion. A good example of this Jordan> are their TCP/IP setup dialogs, and some of the early X stuff. Yeah, I prefer FreeBSD's here: you can see it all at once.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511261557.PAA10995>