Fresh Fish 4/FreshFish_May-June1994.bin/bbs/gnu/emacs-18.59-bin.lha/lib/emacs/18.59/etc/INTERVIEW

Text File | 1987-09-16 | 25KB | 435 lines

               GNU'S NOT UNIX

         Conducted by David Betz and Jon Edwards

          Richard Stallman discusses his public-domain
            UNIX-compatible software system
               with BYTE editors
                  (July 1986)

Copyright (C) 1986 Richard Stallman.  Permission is granted to make and
distribute copies of this article as long as the copyright and this notice
appear on all copies.

Richard Stallman has undertaken probably the most ambitious free software
development project to date, the GNU system.  In his GNU Manifesto,
published in the March 1985 issue of Dr. Dobb's Journal, Stallman described
GNU as a "complete Unix-compatible software system which I am writing so
that I can give it away free to everyone who can use it...  Once GNU is
written, everyone will be able to obtain good system software free, just
like air."  (GNU is an acronym for GNU's Not UNIX; the "G" is pronounced.)

   Stallman is widely known as the author of EMACS, a powerful text editor
that he developed at the MIT Artificial Intelligence Laboratory.  It is no
coincidence that the first piece of software produced as part of the GNU
project was a new implementation of EMACS.  GNU EMACS has already achieved a
reputation as one of the best implementations of EMACS currently available
at any price.

BYTE: We read your GNU Manifesto in the March 1985 issue of Dr. Dobb's.
What has happened since?  Was that really the beginning, and how have you
progressed since then?

Stallman: The publication in Dr. Dobb's wasn't the beginning of the
project.  I wrote the GNU Manifesto when I was getting ready to start the
project, as a proposal to ask computer manufacturers for funding.  They
didn't want to get involved, and I decided that rather than spend my time
trying to pursue funds, I ought to spend it writing code.  The manifesto was
published about a year and a half after I had written it, when I had barely
begun distributing the GNU EMACS.  Since that time, in addition to making
GNU EMACS more complete and making it run on many more computers, I have
nearly finished the optimizing C compiler and all the other software that
is needed for running C programs.  This includes a source-level debugger
that has many features that the other source-level debuggers on UNIX don't
have.  For example, it has convenience variables within the debugger so you
can save values, and it also has a history of all the values that you have
printed out, making it tremendously easier to chase around list structures.

BYTE: You have finished an editor that is now widely distributed and you
are about to finish the compiler.

Stallman: I expect that it will be finished this October.

BYTE: What about the kernel?

Stallman: I'm currently planning to start with the kernel that was written
at MIT and was released to the public recently with the idea that I would
use it.  This kernel is called TRIX; it's based on remote procedure call.  I
still need to add compatibility for a lot of the features of UNIX which it
doesn't have currently.  I haven't started to work on that yet.  I'm
finishing the compiler before I go to work on the kernel.  I am also going
to have to rewrite the file system.  I intend to make it failsafe just by
having it write blocks in the proper order so that the disk structure is
always consistent.  Then I want to add version numbers.  I have a complicated
scheme to reconcile version numbers with the way people usually use UNIX.
You have to be able to specify filenames without version numbers, but you
also have to be able to specify them with explicit version numbers, and
these both need to work with ordinary UNIX programs that have not been
modified in any way to deal with the existence of this feature.  I think I
have a scheme for doing this, and only trying it will show me whether it
really does the job.

BYTE: Do you have a brief description you can give us as to how GNU as a
system will be superior to other systems?  We know that one of your goals is
to produce something that is compatible with UNIX.  But at least in the area
of file systems you have already said that you are going to go beyond UNIX
and produce something that is better.

Stallman: The C compiler will produce better code and run faster.  The
debugger is better.  With each piece I may or may not find a way to improve
it.  But there is no one answer to this question.  To some extent I am
getting the benefit of reimplementation, which makes many systems much
better.  To some extent it's because I have been in the field a long time
and worked on many other systems.  I therefore have many ideas to bring to
bear.  One way in which it will be better is that practically everything in
the system will work on files of any size, on lines of any size, with any
characters appearing in them.  The UNIX system is very bad in that regard.
It's not anything new as a principle of software engineering that you
shouldn't have arbitrary limits.  But it just was the standard practice in
writing UNIX to put those in all the time, possibly just because they were
writing it for a very small computer.  The only limit in the GNU system is
when your program runs out of memory because it tried to work on too much
data and there is no place to keep it all.

BYTE: And that isn't likely to be hit if you've got virtual memory.  You may
just take forever to come up with the solution.

Stallman: Actually these limits tend to hit in a time long before you take
forever to come up with the solution.

BYTE: Can you say something about what types of machines and environments
GNU EMACS in particular has been made to run under?  It's now running on
VAXes; has it migrated in any form to personal computers?

Stallman: I'm not sure what you mean by personal computers.  For example, is
a Sun a personal computer?  GNU EMACS requires at least a megabyte of
available memory and preferably more.  It is normally used on machines that
have virtual memory.  Except for various technical problems in a few C
compilers, almost any machine with virtual memory and running a fairly
recent version of UNIX will run GNU EMACS, and most of them currently do.

BYTE: Has anyone tried to port it to Ataris or Macintoshes?

Stallman: The Atari 1040ST still doesn't have quite enough memory.  The next
Atari machine, I expect, will run it.  I also think that future Ataris will
have some forms of memory mapping.  Of course, I am not designing the
software to run on the kinds of computers that are prevalent today.  I knew
when I started this project it was going to take a few years.  I therefore
decided that I didn't want to make a worse system by taking on the
additional challenge of making it run in the currently constrained
environment.  So instead I decided I'm going to write it in the way that
seems the most natural and best.  I am confident that in a couple of years
machines of sufficient size will be prevalent.  In fact, increases in memory
size are happening so fast it surprises me how slow most of the people are
to put in virtual memory; I think it is totally essential.

BYTE: I think people don't really view it as being necessary for
single-user machines.

Stallman: They don't understand that single user doesn't mean single
program.  Certainly for any UNIX-like system it's important to be able to
run lots of different processes at the same time even if there is only one
of you.  You could run GNU EMACS on a nonvirtual-memory machine with enough
memory, but you couldn't run the rest of the GNU system very well or a UNIX
system very well.

BYTE: How much of LISP is present in GNU EMACS?  It occurred to me that it
may be useful to use that as a tool for learning LISP.

Stallman: You can certainly do that.  GNU EMACS contains a complete,
although not very powerful, LISP system.  It's powerful enough for writing
editor commands.  It's not comparable with, say, a Common LISP System,
something you could really use for system programming, but it has all the
things that LISP needs to have.

BYTE: Do you have any predictions about when you would be likely to
distribute a workable environment in which, if we put it on our machines or
workstations, we could actually get reasonable work done without using
anyt