\begindata{text,3528704} \textdsversion{12} \template{default} \define{global } \define{footnote attr:[Flags OverBar Int Set] attr:[FontSize PreviousFontSize Point -2]} \define{blue } \flushright{\smaller{\ \begindata{writestamp,3558816} Datastream version: 1 %o %A, %Y andysans12 717962438 \enddata{writestamp,3558816} \view{writestampview,3558816,25,0,0} }} \majorheading{Producing a CDROM Release of Andrew} \center{\bold{Susan Straub, Gary Keim - Andrew Consortium Carnegie Mellon University}} \indent{\subheading{Abstract: } To gain access to new markets, we wanted to make Andrew easily available, a task to which CDROM seemed well suited. This paper describes the issues we had to deal with in creating a multiple-binary and source distribution on CDROM. The biggest problems were in freeing the binary executables from dependence on their location in the file space and in tailoring access software to make the various components accessible via a variety of hardware and operating systems.} Why did we put out a release of the Andrew system on CDROM? First, and most importantly, we came to the conclusion that the growth in popularity of Andrew has been limited by the high entry cost to get started. We needed something closer to a turnkey system that made it easy for people who have heard of Andrew through word-of-mouth to get a real taste of what it can mean to live in a media-rich environment. Second, we wanted to archive the efforts of the ITC over the past 10 years onto a permanent medium. Third, we choose CDROM over other media because of several attractive properties: it's size makes it possible to pack up multiple set of binaries, allowing us to cover the set of most widely used platforms; there are CDROM format standards (ISO9660 & Rock Ridge) so CDROMs can be accessed by anyone with the right equipment, and the relatively fast direct access makes it possible to execute binary data directly from the disc. Indeed, the CDROM was large enough we were able to include much of the auxillary software that can be used to complement the Andrew functionality--such as tools for building X11 software, printing, spelling correction, and bit map manipulation and conversion. Although CDROM technology is not new, utilization of that technology has come slowly in the UNIX world. We believe that we may have been one of the first organizations to release both source and binaries of a system for multiple platforms on a single CDROM. \heading{Planning} There are many issues to consider well in advance of actually attempting to press you first "proof" disk. The first question you should ask yourself is, "Who is the target audience?" That answer to that question helps you formulate an initial idea of what to include on the disk. Intertwined with this issue is that of which data format to encode your data set. In the UNIX world, there are two important standards, the original ISO9660 and the newer Rock Ridge Extensions to 9960. ISO9660 is a DOS-like filesystem with filenames in the format aaaaaaaa.aaa;vvv and a directory depth limited to eight levels. This is the most widely implemented CDROM format, both in the UNIX and PC world. For this reason alone, we found it important that our data be accessible via ISO9660-compliant CDROM devices. The Rock Ridge Extensions to the ISO9660 CDROM format provide a filesystem with normal UNIX semantics--the disc represents a single UNIX directory. This simplification greatly improves access to the data set, allowing CDROM producers to concentrate their effort on putting valuable data on the disc. The Rock Ridge format has of late become the UNIX industry defacto standard, with companies like SunSoft supporting it in their SunOS release version 4.1.2 (Solaris). Since one of our goals is that the disc lead a long and prosperous life, it was clear that we should also support the Rock Ridge format. We were able to satisfy both data encoding requirements with a CDROM pre-mastering product from Young Minds, Inc.\footnote{\ \begindata{fnote,3541600} \textdsversion{12} 308 W. State St., Suite 2B Redlands, CA 92373 \enddata{fnote,3541600} \view{fnotev,3541600,18,15,0}} called \bold{\typewriter{makedisc}}. Since the Rock Ridge encoding is a superset of the original ISO9660 standard, we were able to encode for both formats. Since we support Rock Ridge, we knew that we needed to minimally provide a logically stuctured UNIX directory. While still in the design stage we made the assumption that we would somehow be able to uniformly and directly access the data with all ISO9960 devices on the market. If this assumption had been valid, we would have been able to maintain UNIX filesystem purity, without having to resort to the use of compressed, tar files anywhere in the data\footnote{\ \begindata{fnote,3518224} \textdsversion{12} \enddata{fnote,3518224} \view{fnotev,3518224,19,0,0}Resorting to this method of data access effectively means vitiating the advantages of direct access with CDROM technology}. Alas, this was not to be the case and so we provided compressed tar versions of the binaries and sources on the disc. Here is an outline of the top-level directories of the cdrom: SCRIPTS installation and access scripts for the CDROM doc helpdocs - all the help files in PostScript papers - a collection of ATK papers in two formats src andrew - source of Andrew User Interfaced System util asnap, cd_link, ispell, patch, psroff, bdffonts, imake, makedepend, pbmplus 4 binary trees: rs_aix31, hp700_80, pmax_ul4, sun4c_411 each having the sub-directories andrew util, and X11 Although we aimed to make the installation process as easy as possible for patrons of both CDROM formats, this aim was offset by the desire to give as much freedom as possible in installing the software. For example, it is always nice to let the software reside anywhere in the directory structure as opposed to demanding that it be installed at a certain location. This concern became one of our biggest due to the fact that, until this release, the Andrew binaries could not easily be moved around. Furthermore, some characteristics of the installation depend upon the encoding format of the data set. You will recall that the more prevelant ISO9660 standard limits both filenames and directory depths while the Rock Ridge Extensions to that standard have not such restrictions and, in fact, make the contents of the CDROM a UNIX directory. If we only had to worry about the Rock Ridge encoding, we could have provided the data set in it's most natural form -- a UNIX directory. In this situation, we nearly have a turnkey system: the only steps necessary for executing the binaries directly from the disc would be (1) mount the disc as a Rock Ridge filesystem, (2) set two environment variables (ANDREWDIR & PATH). The situation is more complicated with ISO-9660, due to the limitations previously discussed. The user of a ISO-9660 compliant CDROM device must be aware that, in order to execute the Andrew binaries on the disc, some directory must be created in a read/write filesystem that maps the ISO9660 filesystem on the disc to the UNIX names and directory structure of the original data set. This is not necessary of a Rick Ridge user, since they can treat the contents of the disc as a regular UNIX directory. Further complicating the installation process is the notion that the binaries can be executed directly from the disc or they may be copied from the disc into a read/write filesystem. There are costs and benefits to both access methods. Running the binaries from the disc saves on read/write filesystem space, costing only the space consumed by the linktree, while copying the binaries to disk could cost as much as 70 megabytes (for the HP 720 "Snake") for the Andrew distribution alone. The other advantage to driect execution from the disc is that it takes less time to create the linktree than to copy the binaries off the disc. This lowers the time it takes to actually see what Andrew has to offer. The downside on running from disc is that you must leave the disc mounted while using the binaries. Also, CDROM devices have a longer seek time (the time it takes the laser to move to the next track) resulting in lower performance. From the preceding discussion, you can infer the advantages of first copying the binaries to a read/write filesystem. If you copy the binaries to disk it will take you longer to get started and it will cost you significant disk space, but it will provide you better performance. \section{Implementation:} \blue{\italic{Answer the question "How did we make concrete our design?"} } A. Building binaries for each platform B. Gathering auxillary sources C. pre-mastering i) makedisc ii) pfs D. Scripts E. Documentation F. Testing \section{Results:} \blue{\italic{ Answer the questions "How well did we implement our solutions? Did we satisfy our motivations? Did we reach our goals?" }} A. Time to usage B. Sizes of the components C. Bugs i) in the scripts ii) in the binaries D. Testimonials \section{Conclusions:} \blue{\italic{ Answer the question" What did we learn from this experience?}" } A. Task estimation was way off B. Testing is crucial C. The need for planning and tracking a plan. \section{ References:} \enddata{text,3528704}