Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!usc!bloom-beacon!apple!vsi1!altos86!dtynan
From: dtynan@altos86.Altos.COM (Dermot Tynan)
Newsgroups: comp.os.minix
Subject: Re: compression
Message-ID: <3545@altos86.Altos.COM>
Date: 18 Jul 89 23:14:24 GMT
References: <2888@ast.cs.vu.nl>
Organization: Altos Computer Systems, San Jose, CA
Lines: 31

In article <2888@ast.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) writes:

	[About the number of disks needed to distribute Minix, and
	 a compression algorithm].

If I remember correctly, the scheme you mentioned is the same one used by
'pack' on AT&T System V.  It doesn't come close to compress-16, in terms
of space savings.  However, a full 16-bit compress may be difficult to
implement.  In the past, I have thought about generating a version of
'compress' which used a disk-file, instead of memory.  However, such a
version would be *extremely* slow.  Particularly on a 4.77MHz 8088.

	For initial distribution of the Minix code, this probably isn't
too bad.  I guess if I were going to do it, I would link a miniature
version of the OS (with the BIOS-wini driver, no RS232, etc), which would
boot on just about any PC (IBM, that is, something similar for Atari, etc).
Then, just include the binaries for those utilities which are needed to
boot the system.  Then, archive everything, to increase the disk efficiency,
and use a 16-bit compress to cut it down to about 35% of its original size.

Now, what you have is an "inflatable" operating system.  The user would
boot the mini-root, and run a shell script called "install", which would
run for three or four weeks (:-), and generate a complete installation on
his/her hard-disk.  The big problem with a scheme like this, is the
install script has to be pretty bullet-proof.  Comments?
						- Der
-- 
	dtynan@altos86.Altos.COM		(408) 946-6700 x4237
	Dermot Tynan,  Altos Computer Systems,  San Jose, CA   95134

    "Far and few, far and few, are the lands where the Jumblies live..."