Date: Sun, 8 Jan 1995 00:51:57 +0000 (MST) From: Jeremy Chatfield <jdc@crab.xinside.com> To: freebsd-hackers@freebsd.org Subject: Re: Graphical installations and such Message-ID: <199501080751.AAA07382@crab.xinside.com> In-Reply-To: <199501080359.TAA21255@estienne.cs.berkeley.edu> from "Justin T. Gibbs" at Jan 7, 95 07:59:20 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Think of me as a disinterested outsider... And take some notice of my
history. The most relevant part of my history for this discussion is
that I was development manager (and because of the lack of other people,
often the marketing and product manager) for Dell UNIX. It was, in
its' day, considered probably the best implementation of UNIX System V
Release 4.0 available.
Even if you skip the stuff in the middle, you might want to note the
last paragraph.
XII supports most versions of UNIX on Intel, so I have no particular
interest in what you decide to do, other than that X Inside would
like to see all UNIX variants develop a larger share of the market
and merge some of the execution format types... This advice is
offered with the motive of helping you to increase the number of
users that you have. That may not be your goal, and I would not
presume to tell you that it should be; FreeBSD is under your mutual
control, not mine. I hope you make it into what you want!
At Dell, we discovered that the rate of customer support calls and
product returns was strongly dependant on the installation process.
Dell UNIX 1.x was based on ISC's 1.0.6 (a fairly early System V
Release 3). Devices were statically configured to specified values
before you started the install, or you could forget about completing
an installation. Dell UNIX Release 2.x was based on SVR4.0 and used
some Dell-created dynamically configuring device drivers for the most
common devices that Dell sold. Support call rate dropped by 90% in
the first 30 days of customer use.
We discovered a side effect. When an installation succeeded first
time, that customer was:
a) Less likely to think that problems occuring later were caused
by the OS and was more likely to assume that they themselves
were confused or in error.
b) *MUCH* more likely to buy additional copies and to recommend
the product to their friends.
The development staff, support staff and (intermittent) marketing
staff agreed about one thing: installation process accounted for
approximately 80% of the customer perception of quality for the first
90 days of product use and was a strong determinant in further sales
and positive customer support experience.
There are differences between a commercial product and a freely
available product. However, if you want FreeBSD to achieve wide
spread use, you would do well to look at what commercial
organisations do, why they do it, and whether it helped... I do not
want to presume to tell you what your goals are, but if you want to
get widespread acceptance and endorsement of FreeBSD, and to get
"customer" willingness to overlook problems and have them actively
help you to fix them, a well designed, slick and reliable
installation process is essential and in some ways overcomes
weaknesses in range of hardware and applications supported.
You should also note that Dell UNIX had an annual advertising budget
of $0. This is less than the budget of FreeBSD (implied by Walnut
Creek advertising and that Walnut Creek probably have some kind of
Press Office that is willing to make Press Releases - Dell PR refused
to announce new releases of Dell UNIX on the grounds that no-one was
interested in software!). Our annual run rate at the time we were
axed, was about 2,000 units/year, sold entirely by word of mouth and
in the face of opposition from the Sales force, who would deny that
Dell sold UNIX so they get on to taking a call from the next hardware
customer... This run rate compares with (at the same date point),
approx 120,000 to 150,000 new units of SCO, 50,000 of ISC SVR3, 300
of ISC SVR4 (withdrawn before the SunSoft acquisition) and approx
2,000-3,000 units from each of ICL, MicroPort, Esix and UHC.
You don't get to that level of sales with no advertising, without
significant product quality goals and something else. We all felt
that thet "something else" was our installation process. The
flexibility to use install media that we provided, or that was from a
backup, to use a wide range of sources from a single bootstrap image,
and to have a menu controlled install, or an escape to the shell for
the wizardly, catered to all tastes and needs.
By the time that Michael remembered that he was running a hardware
company, and decided to remove a $1M software budget, we had a design
for a boot process like that below and had mostly implemented and
shipped it for about a year (the missing component for us was the CD
File System and NetWare support, to allow taking the image from a
NetWare Server - I don't think you care about that, yet ;-) ).
+ Floppy boot using BIOS
+ Kernel loading install tools from a variety of sources
+ Install tools loaded core OS with basic components, using an
initial dialog and no further user intervention. The dialog
could be provided by a file to automate installation
processes.
The install object was explicitly designed to be the same
format as a backup image, so that users could rapidly restore
full working systems. Backup images were extended to include
a complete partition table and file system layout, in case
the whole disk had been replaced; it was also possible to
over ride the saved values and set new values to permit easy
resizing of partitions and file systems; or to defragment
heavily fragmented disks :-)
+ Reboot from hard disk went into a fancy character menu
system for selecting optional packages; all dialogue was
conducted at this point or could be extracted from a file, so
that the remainder of the install could be performed without
manual attention.
We would have used the X Window System, but stuff like Tk/tcl
was not available back then. We estimated that we could
adapt an existing USL character menuing system in less time
than it would take to start on an equivalent interpreter for
an X based language.
Mechanically, this process was arranged as:
Disk 1: Kernel with autoconfigured device drivers.
Disk 2: (optional) File system with install tools.
Disk 3: (optional) other network tools.
Disk 1 permitted loading the rest of the install tools from:
the first archive on a tape
NFS mounted resource
tftp server
CD-ROM
Floppy
The point of having the install tools on floppy was that they could
also be used for system reconstruction and administration.
We had very positive response to putting all questions at the front
of each of the two steps of the installation process. The first
stage of questions was oriented towards physical layout of the
disks, as we had what we considered an irreducible minimum set of
stuff. The second round of questions, after the hard disk was
booted, was oriented towards add-on packages and configuring and
tuning the system - finally asking for an image backup so that a
reinstall could reach that exact point.
Our minimal set of questions for default responses (assumes that
network is not selected - then you needed standard network questions).
o Select & insert Install Tools Media (floppy, NFS, tftp, CD-ROM, tape)
o Keyboard language?
o (assume tape, CD-ROM or Floppy is used) Install or Shell for
administration?
o Default installation?
o Date, time & timezone.
If using the network, we provided a tool that gave a fill in form.
Unlike the tools in Linux and FreeBSD, we put everything on one
screen, using curses:
Machine name:
Domain name:
Primary IP Address:
Netmask: (inferred from previous, but could over ride)
Broadcast Address: (inferred from previous replies)
Gateway IP address:
Nameserver IP Addresses (1):
(2):
(3):
NFS Server address or name: (could be TFTP target, instead)
NFS directory for install image: (could be TFTP target, instead)
Time service IP Address:
This form was used to supply entries into 24 different files that USL
used to store system ID's, IP addresses and so on... It was widely
used by organisations that installed multiple systems, so that they
could quickly set up installation sets of addresses and then change
to the real target when installation was complete..
I hope that this helps you to move forward in your design process for
the installation mechanism, and that Dell UNIX still, perhaps, sets a
standard for attention to detail and customer usage :-) I only wish
we'd had the equivalent of the '-c' boot option - it makes my life
vastly easier, working on the range of hardware that we have!
As a final sweetener, X Inside Inc is willing to offer our X Server,
binary executable, in 640x480x4bpp VGA mode only, for free, if you
choose an X based package installation process. We maintain the VGA
code anyway, it runs on everything we know about, including the silly
Weitek VGA chips, nobody buys our Server for 640x480x4bpp usage so it
doesn't damage our sales and justifies the development and testing
work on that mose, and our configuration process is something that I
think is almost right :-) We'll even offer to field support calls for
configuring the X Server in the install process. Knowing that this
may be of interest to other OS vendors, we're already in process of
making the hacks to support this limited functionality. We could
probably have something ready early this week, if you want to take a
look at it.
Cheers, JeremyC.
--
Jeremy Chatfield, +1(303)470-5302, FAX:+1(303)470-5513, email:jdc@xinside.com
X Inside Inc, P O Box 10774, Golden, CO 80401-0610, USA.
Commercial X Server - for more information please try these services
http://www.xinside.com info@xinside.com ftp.xinside.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199501080751.AAA07382>