Prev: Emacs Time Line, Graphical Chart by Jamie Zawinski - Valuable Resource for Newbies - written: 8-Mar-1999, updated: 29-Oct-2007
Next: Your Helping Heart
From: bolega on 19 Jul 2010 03:29
This interview is NOT found on Richard Stallman's FSF or GNU sites. I
did a google search for this string in title and it did not appear.

Newbies would find it immensely hard to locate it in the absence of
knowledge of its existence.


Original substituted with these to make length shorter.

LC: = Linuxcare:
R: = Richard:
RS: = Richard Stallman:
LWT: = LinuxWorld Today:


#
[Dec 14, 1999] Linuxcare - Linuxcare Interviews
#


LC: One of my favorite documents on the GNU web site is a talk you
gave at Sweden's Royal Institute of Technology in 1986. The way that
talk was structured was 1/3 historical, 1/3 technical, and 1/3 social.
I was wondering if we could spend a bit of time to discuss the
technical part now.

R: Okay.

LC: I understand it's not your focus right now. One of the initial
questions I have is since the portability of ITS [Incompatible
Timesharing System] failed...

R: It had no portability.

LC: Okay, then in the absence of portability, what really made you
think that UNIX was a good idea?

R: It was a portable operating system and it had real users on
different kinds of machines. So it wasn't just portable in theory, but
the portability had been tested. In addition, UNIX had some good ideas
by the standards of the day. Nowadays we take them for granted
perhaps, but compared with other operating systems that I had worked
on they were interesting and powerful; things like pipes and
redirection, shell programming, the convenient fork() and exec()
system calls; these were an advance. So I thought UNIX was a pretty
good idea. Since I had never used it, I didn't know about some of the
things that were actually badly designed. There were some ways in
which UNIX was a step backwards from the other operating systems I had
worked on. For example, the lack of atomic supersede. These days we've
pretty much forgotten what that is. It means that when a program
starts to write a file in UNIX, it starts by truncating the file to
zero length, then it rewrites the contents. This means if somebody
tries to read it at that time they will get a half written file. On
the operating systems I used in the 1970s, there was no danger of that
because the new version would appear instantaneously when it was
closed. Until a certain point, anybody reading the file would get the
old version, and then instantly it would be replaced by the new
version. So anybody reading the file would always get a complete
version.

LC: For example, sometimes it's nice to be able to "tail" a file as
it's being created.

R: Yes it is. There are some uses in that, but it seems to me that
having a special system call you can use to get at a file being
written is better than lacking atomic supersede. At least there was
some way you could get to look at the file while it was being written.
"I don't like the idea of having security within a shared computer
system at all. I also don't like the idea of saying no to everyone by
default."
--Richard Stallman

LC: Doesn't file locking take care of a lot of that?

R: To an extent it works. EMACS has the ability to write it under
another name and rename it. Of course, there's no other name you can
be sure won't cause a problem. There is some ugliness in the design of
UNIX, but fortunately most of it is pretty good.

LC: One of the ugly points you mentioned in the 1986 talk was that of
a security model. You explained that rather than make it easy for
people to do the right thing, it simply forbids them from doing the
wrong thing.

R: You're mixing several issues. One is that I don't like the idea of
having security within a shared computer system at all. I also don't
like the idea of saying no to everyone by default. Now, in fact, I do
that. Our computers have security now, and because I am so bitter
about what I have done, I'm so ashamed of what I have done, that I
treat myself like one of those outsiders. I cannot log in remotely to
the new machines. I know a way that I could, but I won't do it because
the same maltreatment I am giving to everybody I must give to myself
as well out of shame.

LC: One thing I noted in talking to Richard Stevens was the fact that
you were pretty responsible for coming up with the name POSIX.

R: Yes.

LC: Originally it was going to be IEEEIX.

R: I was part of the committee, and that's why I knew what it was
going to be called. When I realized people were all going to be
calling it "UNIX-like," standards for "UNIX-like" operating systems,
because they didn't want to say IEEEIX, I decided I had better get
them a euphonious name on the double. This was after the standard had
been finalized and they were about to officially publish it.

LC: It might be said that the new system could almost be a reference
to the product.

R: It could, except that we don't religiously try to follow it. You
have the POSIXLY_CORRECT environment variable.

LC: There are specific examples where POSIX is specifically seen as
backwards compatibility.

R: Basically, my attitude towards standards is that they are useful.
They help users figure out how to support a variety of systems, and
then they help system implementers figure out how to give the users
what the users will expect. But you shouldn't treat standards as
though they were gods. There's no need to. We support standards in the
ways that are useful to users, and we depart from them when that
becomes more useful to users.

LC: Can you think of any major coups or major features that were
brought to the POSIX table?

R: I can't remember any more. That was in the 1980s. However, I do
remember one where we didn't succeed in persuading them. This was in
the POSIX.2 specification for the utilities. They made a decision that
they would follow System V by default, and in System V when you did
"df" or "du," file sizes were measured in disk block units of bytes.

LC: Right; instead of kilobytes.

R: Well, it occurred to me that this was not good for anybody, so I
asked them if they could please change it for the sake of the users.
They said, "No, our rules say we follow System V." So I took a poll
and asked users which they preferred, and it was 20:1 in favor of
kilobytes. I sent them the poll results and they said they didn't
care. Unfortunately, I didn't catch this at a time when I could
officially object to it. It was already approved and we had already
had a chance to object, so all I could do was make a comment. So I
couldn't block approval of the standard because I was a voting member
of the committee. I couldn't block approval of the standard on those
grounds, so instead... speaking of coups, this was about the time of
the coup that eliminated the Soviet Union. So, I posted a notice about
the coup in which the evil repressive forces of POSIX were being
thrown off, and as we speak, teams of new developers are taking
control of the major new utilities because they were making the
changes to support K by default. To have an excuse to say that we
still support the spec, if you define the environment variable,
POSIX_ME_HARDER was the original way. Then a slightly prudish board
member convinced me to change it to POSIXLY_CORRECT which I now think
was a mistake. I should have left it as POSIX_ME_HARDER.

LC: I'll ask a stupid question. Have you put any Easter eggs into
anything? Just some wacky key code combination or something?

R: I did once. It was a joke about the C specification which said
#pragma was supposed to do something about implementation design. So I
decided that a particular #pragma should do some absurd thing, just to
point out that it's ridiculous to use pragma for anything, because you
never can tell what it's going to do in some other compiler.

LC: Which pragma was it?

R: I don't remember, but we took it out. There was some pragma that
other people were using and we decided to have compatibility to
support it. We took that out and made it something that was somewhat
useful. The other problem with pragma is you can't use it in macros.
This means that for almost all purposes it's a bad solution. To have a
mechanism that's guaranteed to be wrong is inappropriate for almost
all cases.

LC: Right.

R: I think they finally got the message and started designing other
mechanisms that could be used inside a macro extension. We did
eventually find one situation where a pragma could actually be used to
be appropriate because it was something that never was useful to do in
a macro. I can't remember what it is, but I think you might be able to
find it in the GCC manual.

LC: Speaking of GCC, we've got a couple of questions submitted here by
somebody.

R: Okay.

Linuxare: To what extent does the basic architecture of GCC need
changes to support the language front-ends, such as the new GCC Java
compiler?

R: I don't know anything about what's happening with the Java
compiler. I stopped dealing with GCC around 1992 and I don't know what
changes, if any, were needed. Some changes were needed mainly in the
tree data structure, which is what programs get parsed into.
Occasionally, when you handle a language that has the kind of
construct that hasn't been handled before, if there's no way to
represent it with the existing tree data structure, you need to add
something so you can represent it. Things like methods and core
methods needed a way to be represented, so we added them.

LC: Does GCC still use a LISP-like intermediary language?

R: Printed syntax is what's LISP-like. It's not really LISP-like in
the sense that it consists of tupelos that point to a number of other
tupelos, which is not by any means a new format for priority use. It's
printed out in a LISP-like syntax because that makes it easy to work
with in EMACS.

LC: How did you come to choose LISP as the EMACS engine?

R: LISP is the most powerful programming language, and if you want an
interpreter, LISP is the best. None of the other languages come
anywhere near LISP in their power. The most exciting things about LISP
are read, eval, and print. If you look at other languages, they have
no equivalent for any of those.

LC: Why are there so many parameters?

R: The minimal set of parameters are small, but on the other hand,
there are many standard functions available to do lots of interesting
things with lists. With other languages, you need to define exactly
the data types you want and define all of the basic things for working
on them. Well, they're starting to wise up about template libraries
where you can define various kinds of applications, specific list data
types, and then have various functions that you can substantiate for
any one of those. However, you're still limiting each of those data
types you define to using one particular data type for the elements,
which is not very convenient. With lists, you have one data type, and
you can put anything in any list. You can mix together different kinds
of types of elements. It's so flexible.

LC: One technical point is you don't necessarily limit yourself to a
specific set, but the beautiful thing about LISP is that everything is
a list.

R: Yeah, everything is generic.

LC: You can build functions using a very small set of primitives.
Those functions become useable over lists themselves, or lists of
lists and so on.

R: Any list of anything in your program and you can have all these
built in things that you can do. Not only that, programs are
representable as data, which gives you all sorts of convenient,
powerful things.

LC: That's not unique to LISP though.

R: Well, it is mostly unique to LISP. Yes, you can write a parser for
some other language, and you can invent some data structure to parse
them into, but you will have been the one who invented that data
structure. There will be nothing you can do on it except the things
you provide ways to do.

LC: That's not true. You can do that in Perl for example.

R: Well, with Perl what is their format? They're strings.

LC: Yeah, you can create strings which are programmed.

R: Yes, with string-based interpreters you can represent programs as
strings, and you can interpret them as strings, but you can't parse
their syntax very easily as strings. In LISP, programs are represented
as data in a way that expresses their structure, and allows you to
easily do things to the programs that are based on understanding them.

LC: Right, but you have to count the strings.

R: No, you don't have to count strings. Strings are only in a textual
representation. When it's data, you have lists that are nested in
exactly the same way that the programs are.

LC: This data structure versus pure list argument is one which the
XEMACS people often make.

R: They've apparently been indoctrinated by some rather rigid kind of
object oriented design philosophy, and they feel they should make as
many layers as possible in the program, and at each layer make a whole
bunch of primitives to do everything you could possibly want to do.
This is a recipe for making a program very big and hairy. Sometimes
it's a good thing to do. When the thing has enough hair anyway, then
it's sometimes good to make such a data structure. In the 1980s, there
were people trying to run it in terms where you could only get an
address space of 1 meg. Nowadays, that's an irrelevant design goal,
and EMACS is much bigger than it was and that's okay. If it were just
technical issues separating us and the EX people, I would be willing
to make compromises on those things, but unfortunately it's not just
technical issues.

LC: How much of the current development are you still doing?

R: I'm doing a substantial part of it, but not most of it anymore. I
found a very good person who I think is about to be hired as an EMACS
retainer, who just in the past year and a half rewrote the read/write
completely to support variable response and images in the documents,
and all sorts of other nice things which seem to work. You'll be able
to put postscript into your document and have it display and all sorts
of other neat things. We're headed towards word processor.

LC: Any release dates?

R: No. It will be done sooner if you help.

LC: So what are you doing more of now?

R: I have been compelled to involuntarily promote myself into
management.

LC: Which means no more coding?

R: Not much coding; sad to say. It's much less fun, but it has to be
done.

LC: Also, you seem to be doing a lot of going out and dealing with
issues such as these.

R: Exactly. It's the leadership of the movement that I'm doing.
Sometimes it involves managing people within new projects, sometimes
it involves recruiting, negotiating with other projects, or persuading
people to change their licenses. For instance, I worked for two years
to persuade Berkeley to change its license to get rid of the obnoxious
advertising clause. It took a long time and now it's done, but now we
have lots of other people to persuade.

LC: The BSD people seem to use a new code that they wrote.

R: Exactly. I persuaded them a year and a half or more before I
persuaded Berkeley. They took to the idea very quickly, so they don't
put that into their code, but now they can remove it from the Berkeley
code too.

LC: Getting back to EMACS, I've heard that there are some rather
peculiar methods by which it's compiled.

R: Well, it has to dump itself out. The reason is to avoid taking the
time to load up the standard LISP code every time you start it, so it
actually unexecs itself.

LC: In other words, you compile the base LISP interpreter, then you
load up the LISP codes.

R: Exactly.

LC: Do you share libraries at all?

R: No. Well, it may if you build it on a system where LISP libraries
are being shared. In that case it's using shared libraries, but other
than that, no. The C shared library mechanism is not designed to be
used to link any LISP codes.

LC: Is that how LISP programs are normally compiled? To say it core
dumps itself sounds kind of frightening.

R: No. LISP is interpreted. This is a different issue. This is the
issue of: "How can I go out and make something start running quickly?"
So much of EMACS's interpreted LISP code is the idea that, rather than
starting with something small, having it bootstrap itself, and then
start running interpreted LISP, you actually see something pop up on
the display. There are about 30 files of LISP codes that are
standardly included in EMACS. If EMACS had to load them each time, it
would take probably a minute or so to start up. That would be
inconvenient.

LC: It's basically just a snapshot? Okay, it makes an executable file
that represents the state of what is in memory at that time.

R: Exactly, and that way it starts up like that and all of the loading
and preloading... Well, it still takes much longer to start up than we
wish, but it's much faster than it would be if it didn't do this. In
the old days, it used to take 10 minutes to do that pre-loading. That
was really a pain.

LC: What inspired you to write EMACS?

R: It sort of happened almost by accident. Let me give you the whole
story. In the early 1970s, what we used for editing was TECO. Except,
our version of TECO had a nice display screen feature where at the end
of each TECO command string... because the way you used TECO was, you
typed a command string which was a long or short sequence of commands,
and at the end you would type escape/escape, and that executed all of
these commands. In most versions of TECO you never saw what was in
your text unless you used the command to type it out. But we had some
display consoles, so we put in an automatic redisplay thing where, at
the end of the command string, it would display the current area of
the buffer on the screen automatically. It would keep track of what
was on the screen already, and it would not redisplay the things that
were changed. So that made redisplay faster.
"Guy Steele had the idea of collecting the best ideas of the various
TECO-based editors, and synthesizing them into one editor. We got
together to implement it. After the first night, he dropped out, so I
did most of the work. This became EMACS."
--Richard Stallman

Anyway, somebody else decided to implement a real time editing feature
where you would type single character commands and they would update
the screen immediately. He decided to do this with its own completely
separate redisplay mechanism though, which turned out to be utterly
unusable and painfully inefficient. It didn't work and nobody used it,
so I decided to reimplement that completely and make it display
compatibly with the usual redisplay mechanism. So, you'd go into the
real time editing mode and you wouldn't see any of your text on the
screen change, but then as you typed characters which changed the
text, you would see the redisplay happen immediately. I optimized this
and people actually started to use it. At first there were only a very
limited set of things you could do to your text in this real time
editing mode, so you had to edit it to do anything else like delete or
save a file.

So, somebody said to me, "How about giving us a couple of characters
in the real time editing mode that we can redefine and make them run
TECO macros?" A TECO macro was just a command string that you had
written in advance to serve as a subroutine that you could call up
when you wanted to. So I looked at the idea, and I saw it would be
just as easy to let you redefine any and all of the characters.

LC: Right.

R: So I did that, and other people really went to town redefining
these realtime editing characters, until eventually just a very few of
them were left with their standard definitions. People had written
several different packages, essentially editors written in TECO. So
TECO had changed from being the editor, to a system for writing
editors. Then Guy Steele had the idea of looking at these various TECO-
based editors that people had written, collecting the best ideas of
them all, and synthesizing them into one TECO-based editor that would
end all TECO-based editors. He did a lot of work designing a new
command set that would be clean and symmetrical, and then we got
together to implement it. Then after the first night it happened, he
dropped out, so I did most of the work. This became EMACS, and it
basically replaced the other TECO-based editors. When it caught on,
other people wrote implementations of the same basic idea, but not
using TECO typically. Greg Greenberg, I believe, was the first one to
use LISP as the language to implement the editor in. Then, people
working for a system I can't recall, tried the approach of writing
their own LISP interpreter and implementing most of the editor in
that, and it worked well. So I used that for doing my second
implementation of EMACS. Then, to gain portability, I wrote the LISP
interpreter, the parts of the editor that had to run really fast, and
some editing primitives, all in C.

LC: Like which ones?

R: Well, like insert some text in the buffer, delete some text in the
buffer, communication with subprocesses, and so forth.

LC: Wasn't the LISP interpreter written using lex and yacc?

R: No, absolutely not. There's no reason to use lex and yacc to write
a LISP interpreter. The syntax is so simple you don't need it. You'd
just be making things harder.

LC: I understand that you had a version on your LISP machine too.

R: Yeah, there was an EMACS-like editor written in LISP machine LISP.

LC: Did you work on the development of that?

R: I did some, but not very much except in the later stages in the
time of the war with Symbolix. There were some neat features I added,
like the selective undo feature where you could select a region and
undo the last change in this region.

LC: Oh, that's cool.

R: Now the new EMACS has that feature too.

LC: What's the key for that?

R: You use it with CTRL-U as an argument that requests selective undo.
Also, a trangient mark mode. When you have a region active then undo
the last action.

LC: So C-u and then what?

R: Either C-Xu or C-_.

LC: Are there any plans to include Guile bindings in EMACS?

R: Well, I want to switch over to replace EMACS LISP with Guile.

LC: Oh, that's interesting.

R: Because Guile, which is the new project scheme interpreter, is our
standard for extensibility. It's a library. It's designed that you
build it into your program, and then you make the lower level parts of
your program into added scheme packages. Oh, here's a new feature you
can see. You can see here that one of the words in this buffer is
highlighted. EMACS 21 supports faces on TTY's.

LC: Cool.

R: It has lots of other neat features too.

LC: So you're running EMACS 21 here?

R: Well the development sources are not finished. We're still putting
new features into it.

LC: It's been a rumor that TECO had such a first impact.

R: It was designed to be something you edit with, not designed to be a
programming language.

LC: Right.

R: It was really lousy as a programming language. So the lesson of
EMACS was, pick a good programming language to write your editor in,
and your sensibility language really ought to be designed to be a good
programming language. You shouldn't think you should throw away what
you know about programming language design. Well, obviously the best
programming is LISP.

LC: Any real words can be considered a TECO macro?

R: Yeah, just about anything.

LC: So you can figure out what your names did?

R: I never did that. We didn't have that game. However, I do remember
that there was an editor, not TECO, in which the command EDIT
{carriage return} would wipe out the text that you were editing
because it means "everything delete, insert T." Now if you only did
everything DELETE {carriage return} you could undo the change. There
was just a one level undo buffer.

LC: But not with a standard text editor.

R: Not on that system. I never edited on a UNIX machine until I had
EMACS to edit with. I was at MIT, and there were other things that I
could edit with. I could save the files over the net, so I did my
editing on a LISP machine.

LC: Every time, I've heard people say that the reason they're still
working on the HURD is because it was a good design and it's almost
done.

R: Yes. Unfortunately, progress right now is very slow. We don't have
anybody working on it full time, and I wish we did.

LC: What are some of the major big wins?

R: Well, the big win is that it's a collection of individual servers
that communicate with each other, and each user can replace the ones
he or she doesn't like.

LC: Such as the scheduling, or what?

R: Well, the scheduling is actually done inside the micro kernel, but
you can write your own memory managers, you can write your own file
systems, and you can write your own terminal driver. So, you can
replace your own terminal driver. You can't replace somebody else's,
and as an ordinary user you can set up additional file systems that
you've written, different file names, and then people can open them.

LC: What advantages would this have over other micro kernels?

R: I don't know very much about a lot of micro kernels, but I know
that the OSF multiservers were designed specifically to mimic the
features of UNIX. That would trap the system call handler, which would
send a message to a server, and the server would cooperate to get the
job done. As far as the user program was concerned, it would have only
the features of UNIX. The HURD was designed to completely expose to
the user program the various servers. So something that would be a
system call in Unix would just be a function in the library. It would
send various messages to get the job done, and you could send messages
to those same servers any time you wanted. So, all of the underlying
implementation was made available, and you could take advantage of
whatever you wanted. In addition, the multiserver derived some benefit
of modularity due to the fact that it was divided into these several
servers, but you couldn't replace the servers you were using. Only the
operator could make an alternate kind of server run. That would be
good for debugging a new version of the servers, but it didn't give
the user any additional power.

LC: Can you make reference to the new Mach?

R: There is a new version of Mach that we maintain, but we didn't
write Mach, and we did that basically once all the work on Mach came
to an end.

LC: Could you expand a little bit on the PDP-10?

R: The PDP-10 had several nice things. One is that it was a very
symmetrical design. The instructions formed very symmetrical classes,
including a number of instructions that were NOOP's. If you hit the
class of instructions that were complete, there were a few things that
were trivial and didn't do anything useful. In many cases, there were
several different instructions that would do the same job just because
trivial cases of two different classes of instructions were the same.
Another very nice thing about the PDP-10, was that each word of 36
bits was big enough to hold two addresses. In effect, it was designed
for LISP, you see. It was the original LISP machine. So, because it
was a word addressed machine, you could address a megabyte using just
18 bits, and this megabyte consisted of 256K of 36 bit words, each
capable of holding two pointers to other words.

LC: Right.

R: Another nice thing about the PDP-10 was, if you looked at a word,
you could pretty much tell from its contents what kind of data it
contained, whether it contained text, or instruction, or a pair of
addresses, or just one address, or just some number. Typical values
were different enough that you could generally tell, and this is a big
help for debugging.

LC: Other than the PDP-10, what would be your favorite architecture?

R: As you point out, the PDP-10 was great for its day, but eventually
its address base just became too small. There was no way to extend it
cleanly to a larger address base, so it really was obsolete. Nowadays,
I basically don't pay attention. It doesn't matter so much anymore,
and now that you write in something portable rather than assembler
language, you have no reason to prefer one architecture to another.
Back when everybody was writing in assembler language, it really was
much more of a joy to program for the PDP-10.

LC: Any final thoughts?

R: I'm not very good at making up final thoughts.

LC: Anything?

R: If you're trying to debug a program, get into the symbolic debugger
as soon as possible. Assuming that you've got a reproducible test
case, don't bother wasting any time looking at the cases that don't
fail. Just use the debugger to find out what happens in a case that
does fail. Use breakpoints, and then stepping, to localize the problem
until you see where it's happening. Other approaches that might seem
like shortcuts usually end up taking longer. This one is sure and
steady, and it will generally find you the problem faster than any
other method. But when there is no reproducible test case, then that's
a different kind of fish, and you may have to put debugging buffers
and save information into your program, so you can get enough
information to figure out what happened.

LC: There was also a program change with the debugger. [Heisenbug]

R: Do you know about the bug that depends upon the phase of the moon?

LC: I've heard about this.

R: We always liked to talk about the bugs that depended on the phase
of the moon. So, when Guy Steele wrote the Rabbit compiler, which is a
scheme compiler, he made it print out a comment at the beginning which
showed the time it was compiled and so on, but it also put in the
phase of the moon. So, you could always look. If you had a bug that
depended on the phase of the moon, you could look at the thing and see
at what phase of the moon it was compiled, and that might help you
figure out what went wrong. Eventually, he got a bug report about a
certain program that had been compiled once, and worked, and when it
was compiled at another time it didn't work. So, he looked and he
discovered that when the initial comments were printed out, the LISP
feature that would automatically put in a line break if a line got too
long was activated on one occasion, because the phase of the moon took
too many characters to print out. So, it triggered that feature, and
the last part of the phase of the moon was on another line, and
therefore it wasn't marked by comments. So it was just sitting there
in a file, whereas at another time the phase of the moon didn't take
up so many characters, and the whole thing was properly commented. So,
this was a bug that actually depended on the phase of the moon. You
can take that as a final thought.


#
[Dec 13, 1999] Linux Today Richard Stallman -- Boycott Amazon!
#

Amazon has obtained a US patent (5,960,411) on an important and
obvious idea for E-commerce: the idea that your command in a web
browser to buy a certain item can carry along information about your
identity. (This works by sending back a "cookie", a kind of ID code
that your browser received previously from the same server.) Amazon
has sued to block the use of this simple idea, showing that they truly
intend to monopolize it. This is an attack against the World Wide Web
and against E-commerce in general.

The idea in question is that a company can give you something which
you can subsequently show them to identify yourself for credit. This
is nothing new: a physical credit card does the same job, after all.
But the US Patent Office issues patents on obvious and well-known
ideas every day. Sometimes the result is a disaster.

Today Amazon is suing one large company. If this were just a dispute
between two companies, it would not be an important public issue. But
the patent gives Amazon the power over anyone who runs a web site in
the US (and any other countries that give them similar patents)--power
to control all use of this technique. Although only one company is
being sued today, the issue affects the whole Internet.

Amazon is not alone at fault in what is happening. The US Patent
Office is to blame for having very low standards, and US courts are to
blame for endorsing them. And US patent law is to blame for
authorizing patents on computational techniques and patterns of
communication--a policy that is harmful in general. (See
lpf.ai.mit.edu for more information about this issue.)

Foolish government policies gave Amazon the opportunity--but an
opportunity is not an excuse. Amazon made the choice to obtain this
patent, and the choice to use it in court for aggression. The ultimate
moral responsibility for Amazon's actions lies with Amazon's
executives.

We can hope that the court will find this patent is legally invalid,
Whether they do so will depend on detailed facts and obscure
technicalities. The patent uses piles of semirelevent detail to make
this "invention" look like something subtle.

But we do not have to wait passively for the court to decide the
freedom of E-commerce. There is something we can do right now: we can
refuse to do business with Amazon. Please do not buy anything from
Amazon until they promise to stop using this patent to threaten or
restrict other web sites.

If you are the author of a book sold by Amazon, you can provide
powerful help to this campaign by putting this text into the "author
comment" about your book, on Amazon's web site. Please send mail to
amazon(a)gnu.org when you do this, and please tell us what happens
afterward.


#
[Aug 17, 1999] LinuxWorld Today An interview with Richard Stallman
by Joe Barr
#

....Richard's Rasputin-like appearance, his long dark hair and beard,
as well as his history of exposing reporters as bumbling idiots, had
me on edge. But his voice and features, his eyes in particular, are
remarkably warm and friendly. His message -- that software should be
free (as in freedom, not as in price) -- has remained so resolute over
the years that many, myself included, assumed the messenger would be
just as hard and unyielding. I was wrong.

LWT: As I was preparing for this interview, there was a certain amount
of fear as I worried about things like offending you by saying "Linux"
instead of "GNU/Linux."

RS: It's not so much that I would be offended, and especially if it
was a mistake. I'm mainly concerned, not with what you say to me,
because after all I know the situation. What matters is what you say
to other people as to whether you are setting them straight about the
history of the system or spreading the usual confusion. That's what
really matters.

LWT: I read an interview that you did with Byte Magazine in 1986, and
I was struck by two things. First, if I had listened in to that
interview in 1986, I would have thought you were a madman to talk
about the possibility of a system that would allow people to be
productive with their computers based on all free software.

RS: You see, I had an advantage. I knew it was possible. I was doing
it, along with a bunch of other people back at MIT in the 1970s. We
had a time-sharing system that had been developed by the hackers at
the AI Lab. That was their job, developing the operating system. I
joined that community rather late. It started in the '60s and I joined
it in 1971. The system already existed and ran, and I added to it. So
I knew it was possible. I didn't have to speculate whether we could
succeed in developing another one. Whether we could get together
enough people, that I couldn't be sure of. But that it was possible in
principle, I didn't have to guess.

LWT: I was also struck by the fact that in 1986 you were saying
exactly the same things that you are saying today.

RS: So either you can say that I am steadfast, or that I don't know
how to learn anything.

LWT: I think the results speak for themselves. But I think that it is
remarkable that you had a vision, a consistent vision, and it's a big
part of world today. It's a powerful force in the world.

What's lacking in the GNU system today? What's still to come?

RS: Well, we don't have a really good, free Web browser, and there are
a number of things like audio compression and video compression, which
we don't have and we might be unable to have in the US because of
patents. We are still working on a free replacement for ssh. People
are working still on the free replacements for Microsoft Office. There
are some free word processors. Whether they are good enough, I don't
know. I don't think there is any free desktop-publishing software yet,
but there needs to be.

LWT: The things you are mentioning are almost all applications.

RS: Well, the core of the system we've got, so that's not where things
are missing. After all, the issues of freedom apply the same to
application programs as they do to the operating system. I decided we
should aim for the operating system first because you need an
operating system first. You can't do anything without an operating
system. Whereas these individual applications, any given application,
maybe many people don't need it. They can do their work without it.
But now that we've got an operating system, yes, it's time for free
applications. So that freedom can spread across the whole spectrum of
software and all computer users can have freedom fully.

LWT: Is there a new operating system nearing life?

RS: I'm sorry, I don't understand that.

LWT: Like GNU/Hurd.

RS: The Hurd is not an operating system, it's a kernel. The GNU
operating system is working, but using Linux as the kernel. It works.
It is a reliable, solid kernel. It's as good as any Unix kernel ever
was, and as a result the GNU system with Linux as the kernel is a
reliable, solid system.

Right now, work on the GNU Hurd is very slow, unfortunately. I wish
there were somebody smart working full-time on it, but there isn't.
The result is that we have it running but we haven't written the
things to take advantage of the advanced architecture to actually give
the user benefits from it. And until we find somebody to do that, it's
not going to be really of direct, practical use to people.

So I hope someone arrives, but whether GNU Hurd succeeds or not, the
GNU system as a whole has succeeded.

LWT: You've written a number of programs. Emacs, gcc, gdb. I'm
forgetting something major here, but with the software that you've
contributed, with the GNU manifesto, with the Free Software
Foundation, what do you think is the most important thing that you've
done for free software?

RS: Well, you're looking at all the various parts of something that's
really important as a whole. The GNU Manifesto laid out the plan to
build a community in which people could have freedom by using
exclusively free software. Now to do this, we needed an operating
system that was wholly free software. That's GNU. So the various
programs I wrote are important because they helped us get there. They
are pieces of the GNU system. But what is really important is the
whole GNU system.

That's, after all, why Linux is important. Because it's used as a
piece in the GNU system, in the version of GNU that people actually
use. So, none of these individual pieces would actually matter all
that much if we didn't have the whole system.

Of course, there are many pieces in the system, and some of them were
written by others for completely different purposes. But whenever I
wrote a piece, I was doing that to get to that ultimate goal. And so I
don't think it's useful to look at individual pieces. If you want to
judge their importance, the way to judge them is to ask "how much did
they help us reach the overall goal" rather than "how useful is this
piece of software in isolation."

LWT: What do you take the most personal satisfaction from? Is the GNU
Manifesto more important than the software?

RS: I would say that determinedly standing for freedom and insisting
that we should aim for a completely free system and not settling for
anything less is the most important thing I've done.

LWT: I've heard you described as a socialist, or a communist. Do
politics enter into the Free Software Foundation?

RS: Politics do, but I'm not a socialist or a communist.

LWT: How would you describe yourself?

RS: Well, I guess I am a sort of combination between a liberal and a
leftist anarchist. I like to see people working together, voluntarily,
to solve the world's problems. But, if we can't do that, I think we
should get the government involved to solve them.

The idea of democracy is that it enables the citizens in general to
put a check on the power of the richest, and these days in America we
are failing to use that tool, which of course, leads to a harsh life
for most people.

LWT: Especially the contrast between the world's wealthiest man, Bill
Gates, who has derived his wealth entirely from proprietary software,
where people have no choice at all in the selection on the one hand..

RS: Well, I should point out that people who are determined enough do
have a choice. I was in the same position as lots of people said they
were in, and I decided I wasn't going to use that. When I started the
GNU project, Microsoft was not particularly important or particularly
large, but what you can accurately say is that the only other choices
were difficult ones. Most people look at those difficult choices and
say that's too hard for me. Because they are not absolutely determined
to get freedom. The most important thing about the GNU project is that
it is giving people an alternative to proprietary software that is
easier, and because it is easier, more people feel they can choose it.
So that's the way it spreads freedom to people, by giving them a less
heroic way they can get freedom.

Anyway, the people who call me a communist are engaging in Red-
baiting. It's a standard thing. If anybody criticizes something about
what business is doing, at the present, they get called a communist.

When people said, "Don't pour poison in the river," they were called
communists. But they didn't want to abolish business. They wanted to
abolish pouring poison into the river. The free software movement is a
lot like that. It's a lot like the environmental movement because the
goal is not to abolish business, the goal is to end a certain kind of
pollution. But in this case, it's not pollution of the air or the
water, it's pollution of our social relationships.

When somebody says, here is this nice thing that you will enjoy using
but if you share it with your neighbor we'll call you a pirate and put
you in jail, they are polluting society's most important resource,
which is goodwill, the willingness to cooperate with other people.

LWT: If I understand what you have said and written previously, that
was the impetus for you.

RS: Yes, that is the reason why I decided to dedicate my efforts to
free software. To change an ugly system. And I don't mean a computer
system. I mean a social system.

LWT: I heard you last night, at the award ceremony, saying that you
had lived for a time in your office at MIT. Do you still live at MIT?

RS: No, they won't let me. I would like to, it's very convenient.

LWT: How do you pay your bills? What revenues do you have?

RS: These days I get paid for speaking. I've made a living in various
ways. At one point, for most of a year after GNU Emacs was first
developed, I was selling copies of GNU Emacs. And then for several
years I was doing free-software support. I was accepting commissions
to add new features to the C compiler, teaching classes about Emacs
and about how to program gcc.

I guess I would have continued doing that except I got a big prize and
didn't have to do it anymore.

LWT: So you have your basic needs taken care of.

RS: Well, they are now. But when I started the GNU project I couldn't
be assured of that. I wasn't rich and I didn't know how I was going to
make a living. But fortunately, I live cheaply. I've resisted
acquiring the expensive habits that some other people pick up as soon
as they get enough money to. You know, like houses and cars and
children and boats and planes. Art collecting. People tend to think,
"I have money now, let me look for some frivolous thing to blow it
on." But my idea was, "I'm going to save this so that in the future I
won't have any worries about it." Living cheaply helps doing that. It
also enabled me to decide what I was going to do with my life instead
of having money decide for me.

LWT: Are you still writing software?

RS: Not an awful lot. I've been forced to promote myself into
management.

LWT: So you're providing the leadership for FSF.

RS: Well, I try to. I still find time to fix bugs in Emacs and to add
new features. But it's not as much time as I wish.

LWT: Do you spend most of your time on the speaking circuit? Doing
shows like this?

RS: I spend most of my time traveling. That's partly because when I go
someplace, I try to enjoy it. So I don't just go there and go out
again as soon as possible. Usually I stay there for a while. That's if
it's a place I enjoy going. If it's a place that I don't particularly
want to go, then I would only go there if I thought it was really
important.

LWT: It's a big thrill for me to meet you.

RS: So spread the word, that this is about freedom.

LWT: That is your message.

RS: Urge people to endorse the free software philosophy instead of the
open source philosophy.

LWT: And the distinction being?

RS: The distinction is the open source philosophy is about how to make
reliable, powerful software. They emphasize the practical values. And
they are not wrong, but they are not everything. I think that freedom
is more important than powerful, reliable software. All else being
equal, I want powerful, more reliable software. But if I have to
choose between a more powerful program or my freedom, I would choose
my freedom.

I will use free software even if it is less powerful, or less
reliable, because freedom is the most important thing, and that is
what the Free Software movement is about. How we get freedom. We want
to make software powerful and reliable, because that way more people
will use it and have freedom.

LWT: Why doesn't the Free Software Foundation approach Netscape, AOL,
whoever, and say "Give us Mozilla, and we'll complete the project."

RS: Well, I never thought of it. I don't know if we can do technically
a better job than they are doing, maybe we could. I see no reason to
think that Netscape wants to give it up. Do they want to? I mean, I
haven't heard. I suspect that they want to finish it.

LWT: I'm sure they do, but there are a lot of people unhappy with the
licensing, perhaps.

RS: I'm unhappy with the licensing of Netscape. It's a free software
license, but it has certain flaws. I've asked them to change it;
whether they will, well, that's up to them.

LWT: But they are not getting buy-in from the developer community.

RS: That's an interesting phenomenon. I don't know why that is. I
don't remember exactly what [Mozilla's lead developer] Jamie Zawinski
said the reason was. Do you remember?

LWT: Yes. He gave several reasons. Number one, it is very, very
complex software. Expectations were too high to deliver too much too
soon. It is not a trivial task. Number two, he said that Netscape was
doing all the development, or 90 percent of the development.

RS: What was his reason for why other people didn't join in? Does he
have an idea of why that is? He wouldn't necessarily know. None of us
would necessarily know. But he would have maybe been paying attention
to figure out why people didn't join in.

LWT: I don't believe he said why.

RS: I don't know why. I think that maybe the fact that their license
was not an unbiased license, it gave Netscape special privilege with
other people's code. I can imagine that was part of the reason.

LWT: Whatever the reasons are, it hasn't received social acceptance.

RS: It's also conceivable that Netscape is competing with itself.
People who are not firmly committed to free software and to freedom
think it is okay to use Netscape. That is, not Mozilla, but the
Netscape browser that is still available as binaries only. And if they
are happy using that, then they see no reason to worry about or care
about Mozilla.

LWT: What browser do you use?

RS: I use Lynx. I'm not terribly interested in pictures anyway. I
consider eye-candy distracting and annoying in Web pages. It makes
them hard to read and the ads are likely to be graphical, and I don't
want to see the ads.

LWT: I'm struck by the fact that two of the ways you've made a living
since beginning this walk are very similar to what Michael Tiemann, co-
founder of Cygnus Solutions, has done, except on an individual basis
instead of on a corporate basis.

RS: Absolutely. Indeed.

LWT: Michael Tiemann told me that when he read the GNU Manifesto, he
saw a business plan where others saw what you were saying.

RS: Well, actually, he may have seen one aspect of what was there.
Because I talked in the GNU Manifesto about ways that there could be
free software businesses. But my main concern was not about business,
it was about freedom.

Yes, I've done business. I've personally done free software business.
I think that free software business is a good thing. But although we
do business to make a living and live, there are things that are above
and beyond that. Such as making the world a better place. So I was
aiming for something beyond making a living. Yes, I do business to
make a living, and I'm not ashamed of that. But if that's all I did,
it wouldn't be so important.

LWT: The concepts of freedom, as you have given them, as they apply to
software -- to what other forms of expression should they apply?

RS: Some of the issues transfer over to things to things like books
and music that you may have on your computer, and some of them don't.
For some of them it is useful to make modifications of them, and for
some of them it's not.

LWT: Because of their utility?

RS: Because of how people use them and what they are made of. Making
changes in novels is not as important as it is in software. Programs
are made to be run, whereas novels are made to be appreciated. So, it
is essential that people have the freedom to make changes to software
and publish the modified versions. I don't think it is essential to
have that freedom for novels.

But on the other hand, the freedom to make a copy for your friends is
essential for any kind of thing that might be published and you might
have on your computer.

LWT: How can people get involved with the Free Software Foundation?

RS: Take a look at www.gnu.org. We've got a number of suggestions for
how people can help by writing code or helping to administer our
systems if you're a good system admin wanting to work, or by writing
documentation. We really need documentation. We need good
documentation writers more than we need good programmers. So if you've
got the skill to write good documentation, that's what you should do.
When people show up to program, offering to write software, and I find
out they can write documentation, I beg them to write documentation
instead. Because good documentation is essential and for a free system
we need free documentation. Documentation that we can distribute as
part of the system. There are many manuals that are published about
free software, but most of them are not free. Of course, I'm always
talking about freedom, not price. The problem is that the text of
these manuals is restricted. You are not allowed to copy them and
redistribute them and publish modified versions of them.

LWT: Have you heard about the book that IDG Books, LinuxWorld,
Nicholas Petreley, and I are going to do? The OpenBook?

RS: No, but I may be interested in it.

LWT: It will be freely redistributable and modifiable.

RS: Wow. Well if that's the case, then that sounds exactly like what
we need more of. Be sure and tell me about it.

LWT: I certainly will. It will be written by the community, Nicholas
and I will only serve as editors.

RS: What will it be about?

LWT: It will be about "Essential Linux."

RS: I hope you'll call it GNU/Linux.


 | 
Pages: 1
Prev: Emacs Time Line, Graphical Chart by Jamie Zawinski - Valuable Resource for Newbies - written: 8-Mar-1999, updated: 29-Oct-2007
Next: Your Helping Heart