From: Paul Allen <paula@atc.boeing.com>
Subject: (none)
Reply-To: paula@atc.boeing.com
Organization: The Internet
Date: Tue, 7 Apr 1992 19:42:22 GMT

Drew Eckhardt (drew@caesar.cs.colorado.edu) wrote:

|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.
|>
|>[...some of my text omitted...]
|>
|
|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?  

Well, you would know better than I.  If the older binaries are as stable
as you say, my proposal is even more attractive.

|>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.

And that problem doesn't exist now?  I notice that two of the files
comprising the new gcc 2.1 are larger than a 5" HD diskette.  If the
binaries are stable across releases, then any one individual only
needs to get them once.  They don't have to be stored in a single 10Mb
tar file.

|>- 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.

Yep.  Gcc, especially 2.x, is right on the edge of being unmanageable
on small systems.  But this is beside the point.  The compiler is
clearly needed for bootstrapping a system, and must be available in
binary form.  X (IMHO) is out of the question.  I would be extremely
unlikely to use a binary-only X distribution for Linux.  I want the
sources.  If I can't have them, for whatever reason, I probably won't
run the software.

|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.

I *want* to do it myself.  With the exception of essential bootstrapping
tools, I don't need anyone to make binaries for me.  I'm going to build
things like elvis from sources.  The most convenient thing for me would
be to find Linux diffs for elvis on an archive site, possibly accompanied
by the original sources.  Downloading a huge binary just to get the
diffs that are packaged with it is wasteful and inconvenient.

|>- 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 : 
|
|[...simple procedure omitted...]
|
|>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.

This is welcome news, and doesn't detract from my proposal.

|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.
|

A context diff might be smaller than the binary, depending on the
complexity of the port.  Diffs are more useful than a binary because
they let me regenerate the sources from which the binary was built.
And I *will* have the sources for everything I run on my system.

|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.      

Eh?  Actual non-programming end-users?  Going through the hassle of
setting up a Linux system because it's so useful???  Wow!  I don't
see this happing anytime soon.  An end-user who wants to run a word-
processor or a spreadsheet will either use DOS or a Mac, IMHO.
  
|        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.

What's the most important thing?  The binaries, or the sources?  I
think a convenient source/diff distribution should be available.  It
currently is not.  Once the sources are handled, I've got no problem
with providing binaries for those who choose not to compile their own.

Paul Allen