exchange with Richard Stallman

[bruce@pixar.com (Bruce Perens)]

The following is an exchange I've been having with Richard Stallman over
yesterday and this morning. My conclusion is that what he is asking for
is not stuff that it's reasonable for us to do, that that Debian can not
work together with FSF.

	Bruce

From: Richard Stallman <rms@gnu.ai.mit.edu>

I would like to talk with you about whether working together is still
possible.  Since we have different goals, that may or may not be
possible.

There are the major technical issues I am strongly concerned about:

1. We need to have packages with unstripped executables.

2. We need to encourage people to write documentation in Texinfo.

3. We need simpler installation with clear documentation.

4. We need a complete separation between what we distribute
and all non-free software.


1. One of the aims of the GNU project is to encourage people to debug
problems they encounter.  We would like people to install executables
with symbols, if they are willing to.

Distributing stripped executables puts a lot of pressure on users to
install all executables stripped; an unstripped executable requires a
big extra effort (recompiling from source).

So we want our CD to contain executables with debugging symbols.  This
way, people who prefer to strip them will easily be able to do so, but
people who prefer to keep the symbols will also have an easy time.

The only efficient way to do this is to ask package maintainers to
supply executables with debugging symbols.  It is easy to convert a
package with unstripped executable into a package with stripped
executables; the reverse transformation is impossible.

2. You want to represent documentation in HTML.  It appears that Lynx
is now free, so this is no longer impossible for the FSF.  But we
still want to encourage people writing new documentation to write it
in Texinfo--not just in HTML.

Can we agree on a compromise whereby HTML is used as a universal least
common denominator format for delivering documentation, but we both
encourage people to write in Texinfo?

3. The installation procedure needs to be further simplified.  This is
actually not a single issue, but a collection of subissues.  For
example, the X installation needs to be clearly documented.  The
choice of time zones should be classified in a simple and consistent
way.

4. In order to practice what we preach, we can't distribute a program
that we can't include in the GNU system.  We can't encourage people to
use these programs or tell people where to get them.

We can omit the non-free packages from our CD and we can make an ftp
site which doesn't have them.  We can do those things on our own.  But
they may not be enough.  We also have to avoid mentioning any of the
non-free packages, or mentioning that there is such a thing as
non-free packages, in the parts that we do distribute.

For example, the version of the package specs that I saw mention that
there are non-free packages.  We would not want to distribute that file.

I don't think it would be a lot of work to structure the information
so that the parts we don't want to include are separated from the
rest.  The question is whether you want to do this.

>From bruce Fri Mar 22 21:51:22 1996

Richard,

> 1. We need to have packages with unstripped executables.

This point should not be difficult.
As we approach a multi-architecture release it becomes more important
that there be a standard way to pass compiler flags into the package
makefiles. Most of them accept CFLAGS and LDFLAGS passed in, probably
a number of them need changes to make that work. You'd have to re-build
all packages with different compiler flags. This should be automatic
once the initial problems are worked out. I think you would have to
do a separate build, as I doubt we'd want this option for our main
release, due to space considerations.

Do you have evidence that this works as a debugging strategy? I would
think that the second step in debugging would be to change the program,
rebuild, and try it again. Thus, the user is going to have to build at
least once. Thus, we might be more productive by simply making it as
easy as possible for the user to rebuild a package.

> 2. We need to encourage people to write documentation in Texinfo.

I think you've had a difficult time marketing Texinfo to the world for
all of the years it's been available. I don't see that this is going
to be an easier sell now, with so many people starting to write for
WWW as their primary medium. I can make HTML work as a common
denominator. I have not yet come up with any ideas that would make it
easier to market Texinfo to people who contribute their effort.

> 3. We need simpler installation with clear documentation.
> For example, the X installation needs to be clearly documented.  The
> choice of time zones should be classified in a simple and consistent way.

I'm trying. The installation tool does a lot more hand-holding now.
1.1 will still require the user to run the disk-partitioning
tool. 1.2 will have a simplified disk tool that I am writing. Ian Murdock
wrote an installation for you that did not require partitioning disks,
but it required that the user erase an entire disk to run it and was
not considered practical.

The time zones aren't that big a deal to improve. X is a much larger
issue, and one that we won't get to for 1.1 .

> 4. We need a complete separation between what we distribute
> and all non-free software.

This is another reason for FSF to take Debian and re-build it to their
specifications when we make a release. I don't think editing the few
files that mention non-free software and removing some packages is a
very big job.

I think the fundamental issue here is one of philosophical purity.
We aren't convinced that we can afford not to be heterodox.
Because you are identified with your philosophy, you can't be anything
but orthodox. It's going to be difficult to have a meeting of minds
because of this.

	Thanks

	Bruce

From: Richard Stallman <rms@gnu.ai.mit.edu>

    I think you would have to
    do a separate build, as I doubt we'd want this option for our main
    release, due to space considerations.

What space considerations do you mean?  Don't you have a disk
available where you could store the unstripped packages alongside the
stripped ones?

    Do you have evidence that this works as a debugging strategy?

Yes, plenty.

     I would
    think that the second step in debugging would be to change the program,

Sometimes users do that, but more often it is not necessary.
Usually they make backtraces and examine data, and from that
I can see what is wrong.

Even if they do ultimately rebuild, perhaps because I send them a fix
to try, that can't happen until they have examined and debugged and
given me the information I need.  People are more likely to do that if
they have symbols.


You want to distributed stripped packages; we want to distributed packages
with symbols.  The easiest way of doing this that I can see is as follows:

* Package maintainers supply unstripped packages.
* You collect the unstripped packages on one disk.
* You keep corresponding stripped packages on another disk.
* When you get an updated unstripped package, you store
it in the unstripped disk.
* You copy it to the stripped disk.
* You run a shell script on the copy, to strip it.

Why make it necessary for us to rebuild all the packages when it is so
easy to make it unnecessary?  Is part of this difficult for you?

From: Richard Stallman <rms@gnu.ai.mit.edu>

    I have not yet come up with any ideas that would make it
    easier to market Texinfo to people who contribute their effort.

All I'm asking you to do is to say to users, "Please write new
documentation in Texinfo."  It will have some amount of effect,
and it is easy to do.

From: Richard Stallman <rms@gnu.ai.mit.edu>

    I'm trying. The installation tool does a lot more hand-holding now.
    1.1 will still require the user to run the disk-partitioning
    tool. 1.2 will have a simplified disk tool that I am writing. Ian Murdock
    wrote an installation for you that did not require partitioning disks,

We want to offer the user the easy alternative of bypassing
partitioning.

Could you please keep the alternative code for bypassing the
disk-partitioning step as part of your sources, even if it
is normally turned off?  It could be turned on by the presence
of some empty file that we would add to our distribution.

This would avoid the problems that come from forkage.
One file would work for you and for us.

    I don't think editing the few
    files that mention non-free software and removing some packages is a
    very big job.

It might not be.  It depends on two questions:
1. Do the distribution terms for these files permit that editing?
2. Do we know which files have to be edited?

Can you minimize the number of important files that mention
the non-free packages?


Since our release won't be the same as yours, we will have to do some
work.  What I want to avoid is the need for disproportionate work, or
disproportionate risk of error, such as would result if we had to
rebuild all the packages or edit a large number of files.

To: Richard Stallman <rms@gnu.ai.mit.edu>
Subject: Re: Can we work together

Richard,

I think the answer is No, we can not work together.

	Thanks

	Bruce
--
Pixar Animation Studios: Reality is not our business.
Pixar's "Toy Story", at greater than $184,200,000 in domestic box office
receipts, is the #1 movie released in 1995!