From: drew@caesar.cs.colorado.edu (Drew Eckhardt)
Subject: Re: Binaries considered harmful
Organization: University of Colorado at Boulder
Date: Tue, 7 Apr 1992 07:46:14 GMT

In article <1992Apr7.054001.3797@athena.mit.edu> paula@atc.boeing.com writes:
>(Subject line with appologies to E. Djikstra.  :-))
>
>I have a proposal that I'd like people to consider.
>
>I've been following Linux from the sidelines since last year sometime.
>I've noticed that with each release some of the old binaries from the
>previous release no longer work.  When people ask why some command or
>other no longer works, the answer is often to recompile with the new
>library, or with the new include files.  It seems to me that having
>lots of old binaries around on the archive sites is causing more 
>problems than it's worth.  Clearly, you need to have binaries for the
>compiler and enough commands to bootstrap a system.  I think it's
>counterproductive in the long run to distribute binaries for commands
>that are not essential for bootstrapping.  They'll all eventually
>be broken by some new release.
>

Other than programs which depend on the internal structure of 
Linux (this would be the ps packages, the file system utilities
such as fdisk, etc), what programs have broken with new releases of 
Linux?  

Some programs suffered because of bad library functions, 
and needed recompiling, but there's  a difference 
between one person recompiling at several hundred.

Except for files I have corrupted, or that were broken 
in the first place and subsequently fixed, much of what 
I'm using is from the .11 distribution (the file
utilities, bash until just recently, awk, sed, make, etc).  I 
had been compiling my kernel with the original 'C' compiler 
until 2.1 offered C++ and shared libaries, sufficient 
incentive to switch.

>So here's my proposal:
>
>- In addition to the binary boot and root images that currently 
>  accompany new releases, a companion tarfile should be released
>  containing things like the compiler for that release and other
>  stuff that was too large to fit in the root image.


The difficulty with one big tar file is in downloading it,
passing it through your internet site without incuring the wrath
of the sysadmins and disk quotas,  transfering it on floppy 
disks, etc.

>- Software that is not needed for bootstrapping should be placed in the
>  archives in source or diff form only.

I'm glad you have the disk space and time to spare.  I don't. 
The last time I built gcc, it used over 30M of disk space.  The last time
I built X, it took close to 200M of disk space, and 24 hours to 
build on a 50Mhz 68030 with 16M of real memory (This is somewhat longer 
than it had to be, as the 
disks were NFS mounted).  X is an extreme case, but exemplifies the
kind of software that people will be running on Linux as it becomes
more refined, stable, and popular.

The smaller programs (shell utils, file utils, mtools, elvis / micro
emacs) can be dealt with, but it is still more convienient for users 
to have a binary available so they don't have to do it themselves.

>- Part of the process of installing a new Linux release is to recompile
>  everything.
>

When I've installed a new linux release, it's 
consisted of getting the new boot image, getting the new kernel
source, and performing the following procedure : 

cd /usr/tmp 
tar xvf /dev/b1.44 

zcat /usr/tmp/bootimage* > /vmunix+

Reboot vmunix+. If it works, untar the sources, 
add in my favorite patches, do a make (About 8 
minutes with the old C compiler on a 386-33), and boot 
/usr/src/linux/Image.

If that works

mv /vmunix /vmunix- 
mv /usr/src/linux/Image /vmunix

The only thing this has ever broken was the simple ps package.

>I may be missing something really obvious here, but I just don't see
>the need for all these binaries.  I'd rather just have sources.  With
>the exception of a few things that simply couldn't be compiled, Minix
>has always been a source-only system.  (You got the binaries when you
>bought Minix, and sources/diffs from the net kept you current from then
>on.) I see no reason that Linux needs to work differently.  
>
>I invite your comments, criticisms, flames, or whatever.
>
In conclusion : 

1.  Things are not as unstable as you claim they are, and I would 
	venture to say that most upgrades are in pursuit of 
	having the latest, neat new features, or bug fixes to
	the source.

2.  Binary distributions are significantly smaller than
	source distributions, take less time to
	download, less disk space, and less time
	because they don't need to be compiled.

An example of a mid size program, gdb, in source and 
binary distributions.  The binary is ~800k uncompressed,
the source 8M, ten times as large.  

-rw-r--r--   1 drew     wheel     3105370 Apr  2 01:24 gdb-4.4.tar.Z
-rw-r--r--   1 drew     linux      469777 Mar 11 02:06 gdb-4.4.tar.Z 

3.  Linux is getting real users, not hackers.  These people 
	want something that works like DOS, they
	see something they like, grab it from their 
	favorite BBS, and run it.  Period.      

	I'm not saying that it's a good thing, 
	but given the little trouble it takes, 
	it's not a bad thing to offer a binary 
	distribution for these people.
	 


Source should be freely available to anyone who wants it, 
but a more convienient binary distribution should also
be available.