From owner-freebsd-hackers Sat Jan 7 23:56:09 1995 Return-Path: hackers-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id XAA11797 for hackers-outgoing; Sat, 7 Jan 1995 23:56:09 -0800 Received: from crab.xinside.com (crab.xinside.com [199.120.247.2]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id XAA11791 for ; Sat, 7 Jan 1995 23:56:02 -0800 Received: (jdc@localhost) by crab.xinside.com (8.6.8/8.6.5) id AAA07382 for freebsd-hackers@freebsd.org; Sun, 8 Jan 1995 00:51:58 -0700 From: Jeremy Chatfield Message-Id: <199501080751.AAA07382@crab.xinside.com> Subject: Re: Graphical installations and such To: freebsd-hackers@freebsd.org Date: Sun, 8 Jan 1995 00:51:57 +0000 (MST) In-Reply-To: <199501080359.TAA21255@estienne.cs.berkeley.edu> from "Justin T. Gibbs" at Jan 7, 95 07:59:20 pm Organization: X Inside Inc, P O Box 10774, Golden, CO 80401-0610, USA. Phone: +1(303)470-5302 Reply-To: jdc@crab.xinside.com X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 9576 Sender: hackers-owner@freebsd.org Precedence: bulk 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