Re: FSF negociations

[Guy Maor <maor@ece.utexas.edu>]

I was tempted to just write, "No to all," and be done with it.  But
let's examine these issues a little more reasonably.  All three
suggestions involve tradeoffs between increased disk space and some
benefit.

> 1. Install 100% unstripped executables on the hard disk.

My /bin + /usr/bin is 18 megs.  I'm guessing it would be about double
with symbols, or an increase of 18 megs.  My / + /usr partitions are
174 megs used, so about a 10% increase in installed size.

What benefits would this give us?  Obviously debugging programs is
easier when the user can provide useful core dumps.  We would not have
to worry about the case where an arcane bug can't even be reproduced
consistently.  We also would not need to interact as much with the user
when a bug is found.  Just ask the user to mail a core or force one
with a SIGABRT.

I'm still undecided on this one.  Ten percent isn't much, but I'm not
entirely convinced that the symbols are THAT useful.  From my readings
of the bug lists, over 80% of the bugs are not of the mysterious
nature, and can be easily reproduced.  We can always ask the user to
recompile the package with symbols.

I do believe that source packages should make producing deb files with
symbols an easy task.  That's a separate issue, and not a terribly
controversial one.  Perhaps RMS will settle for that?

> 2. Install source code on the hard disk whenever the binary package is
>    installed.

du -s of two components of our unstable tree:
133141 binary-i386
221578 source

Let's assume that we'll keep the source gzipped and that gzip gets
about a 2:1 compression ratio.  That's probably inaccurate, but I'm
only interested in a back-of-the-envelope estimate.  About a 100%
increase in installed size is what I figure.

That's really a lot.

The benefits are largely the same as 1, but the costs are an order of
magnitude greater.

Perhaps we can negotiate with RMS on points 1 and 2 by improving our
source packaging.  Several problems exist with our scheme, but they all
have straightforward solutions.  I'd like to discuss this issue with
the other developers, but only after we release 1.1.

> 3. Make X-Windows, Emacs, and VI standard, not optional, parts of the system.

This is the most unreasonable of the suggestions.  Surely RMS does not
believe X or Emacs or vi is for everyone.  So why would he want them to
be required parts of the system?  Perhaps so he can provide system
administration programs that require them.  I really don't think this
is necessary, especially given the size of the first two of these
packages.

Very effective, powerful, and easy-to-maintain programs can be written
with perl, python, ncurses, whatever...  Perhaps there is some benefit
of point 3 that I can't think of.


Conclusion:

1 is the only suggestion I would consider, but it would require
convincing arguments.  A better solution to 1 and 2 may be a better
source packaging scheme.  I'm mystified at 3.


Meta-Conclusion:

We need to consider immediate benefits to the user first and foremost.
It's very nice to have a technically superior product or the RMS Seal
of Approval.  But if nobody installs Debian but ourselves, we lose by
default.


PS:

Bruce, I would be happy if you would forward this message to RMS.  I'm
curious as to why he advocates 2 and 3.  I've observed that discussions
with him tend to become flamewars.  I hope that everybody that
participates keeps a civilized and restrained tone.  After all, we are
the developers of Debian.  We can always just say, "No," and walk
away.


Guy