the-gnu-project

windows版本的emacs

   megabyte.  In programs for which handling very large files was not
   crucial, we encouraged programmers to read an entire input file into
   core, then scan its contents without having to worry about I/O.

   These decisions enabled many GNU programs to surpass their Unix
   counterparts in reliability and speed.

  Donated computers

   As the GNU project's reputation grew, people began offering to donate
   machines running UNIX to the project.  These were very useful, because
   the easiest way to develop components of GNU was to do it on a UNIX
   system, and replace the components of that system one by one.  But they
   raised an ethical issue: whether it was right for us to have a copy of
   UNIX at all.

   UNIX was (and is) proprietary software, and the GNU project's
   philosophy said that we should not use proprietary software.  But,
   applying the same reasoning that leads to the conclusion that violence
   in self defense is justified, I concluded that it was legitimate to
   use a proprietary package when that was crucial for developing free
   replacement that would help others stop using the proprietary package.

   But, even if this was a justifiable evil, it was still an evil.  Today
   we no longer have any copies of Unix, because we have replaced them
   with free operating systems.  If we could not replace a machine's
   operating system with a free one, we replaced the machine instead.

  The GNU Task List

   As the GNU project proceeded, and increasing numbers of system
   components were found or developed, eventually it became useful to
   make a list of the remaining gaps.  We used it to recruit developers to
   write the missing pieces.  This list became known as the GNU task list.
   In addition to missing Unix components, we listed added various other
   useful software and documentation projects that, we thought, a truly
   complete system ought to have.

   Today, hardly any Unix components are left in the GNU task list--those
   jobs have been done, aside from a few inessential ones.  But the list
   is full of projects that some might call "applications".  Any program
   that appeals to more than a narrow class of users would be a useful
   thing to add to an operating system.

   Even games are included in the task list--and have been since the
   beginning.  Unix included games, so naturally GNU should too.  But
   compatibility was not an issue for games, so we did not follow the
   list of games that Unix had.  Instead, we listed a spectrum of
   different kinds of games that users might like.

  The GNU Library GPL

   The GNU C library uses a special kind of copyleft called the GNU
   Library General Public License, which gives permission to link
   proprietary software with the library.  Why make this exception?

   It is not a matter of principle; there is no principle that says
   proprietary software products are entitled to include our code.  (Why
   contribute to a project predicated on refusing to share with us?)
   Using the LGPL for the C library, or for any library, is a matter of
   strategy.

   The C library does a generic job; every proprietary system or compiler
   comes with a C library.  Therefore, to make our C library available
   only to free software would not have given free software any
   advantage--it would only have discouraged use of our library.

   One system is an exception to this: on the GNU system (and this
   includes GNU/Linux), the GNU C library is the only C library.  So the
   distribution terms of the GNU C library determine whether it is
   possible to compile a proprietary program for the GNU system.  There is
   no ethical reason to allow proprietary applications on the GNU system,
   but strategically it seems that disallowing them would do more to
   discourage use of the GNU system than to encourage development of free
   applications.

   That is why using the Library GPL is a good strategy for the C
   library.  For other libraries, the strategic decision needs to be
   considered on a case-by-case basis.  When a library does a special job
   that can help write certain kinds of programs, then releasing it under
   the GPL, limiting it to free programs only, is a way of helping other
   free software developers, giving them an advantage against proprietary
   software.

   Consider GNU Readline, a library that was developed to provide
   command-line editing for BASH.  Readline is released under the ordinary
   GNU GPL, not the Library GPL.  This probably does reduce the amount
   Readline is used, but that is no loss for us.  Meanwhile, at least one
   useful application has been made free software specifically so it
   could use Readline, and that is a real gain for the community.

   Proprietary software developers have the advantages money provides;
   free software developers need to make advantages for each other.  I
   hope some day we will have a large collection of GPL-covered libraries
   that have no parallel available to proprietary software, providing
   useful modules to serve as building blocks in new free software, and
   adding up to a major advantage for further free software development.

  Scratching an itch?

   Eric Raymond says that "Every good work of software starts by
   scratching a developer's personal itch."  Maybe that happens sometimes,
   but many essential pieces of GNU software were developed in order to
   have a complete free operating system.  They come from a vision and a
   plan, not from impulse.

   For example, we developed the GNU C library because a Unix-like system
   needs a C library, the Bourne-Again Shell (bash) because a Unix-like
   system needs a shell, and GNU tar because a Unix-like system needs a
   tar program.  The same is true for my own programs--the GNU C compiler,
   GNU Emacs, GDB and GNU Make.

   Some GNU programs were developed to cope with specific threats to our
   freedom.  Thus, we developed gzip to replace the Compress program,
   which had been lost to the community because of the LZW patents.  We
   found people to develop LessTif, and more recently started GNOME and
   Harmony, to address the problems caused by certain proprietary
   libraries (see below).  We are developing the GNU Privacy Guard to
   replace popular non-free encryption software, because users should not
   have to choose between privacy and freedom.

   Of course, the people writing these programs became interested in the
   work, and many features were added to them by various people for the
   sake of their own needs and interests.  But that is not why the
   programs exist.

  Unexpected developments

   At the beginning of the GNU project, I imagined that we would develop
   the whole GNU system, then release it as a whole.  That is not how it
   happened.

   Since each component of the GNU system was implemented on a Unix
   system, each component could run on Unix systems, long before a
   complete GNU system existed.  Some of these programs became popular,
   and users began extending them and porting them---to the various
   incompatible versions of Unix, and sometimes to other systems as well.

   The process made these programs much more powerful, and attracted both
   funds and contributors to the GNU project.  But it probably also
   delayed completion of a minimal working system by several years, as
   GNU developers' time was put into maintaining these ports and adding
   features to the existing components, rather than moving on to write
   one missing component after another.

  The GNU Hurd

   By 1990, the GNU system was almost complete; the only major missing
   component was the kernel.  We had decided to implement our kernel as a
   collection of server processes running on top of Mach.  Mach is a
   microkernel developed at Carnegie Mellon University and then at the
   University of Utah; the GNU HURD is a collection of servers (or ``herd
   of gnus'') that run on top of Mach, and do the various jobs of the
   Unix kernel.  The start of development was delayed as we waited for
   Mach to be released as free software, as had been promised.

   One reason for choosing this design was to avoid what seemed to be the
   hardest part of the job: debugging a kernel program without a
   source-level debugger to do it with.  This part of the job had been
   done already, in Mach, and we expected to debug the HURD servers as
   user programs, with GDB.  But it took a long time to make that
   possible, and the multi-threaded servers that send messages to each
   other have turned out to be very hard to debug.  Making the HURD work
   solidly has stretched on for many years.

  Alix

   The GNU kernel was not originally supposed to be called the HURD.  Its
   original name was Alix--named after the woman who was my sweetheart at
   the time.  She, a Unix system administrator, had pointed out how her
   name would fit a common naming pattern for Unix system versions; as a
   joke, she told her friends, "Someone should name a kernel after me."  I
   said nothing, but decided to surprise her with a kernel named Alix.

   It did not stay that way.  Michael Bushnell (now Thomas), the main
   developer of the kernel, preferred the name HURD, and redefined Alix
   to refer to a certain part of the kernel--the part that would trap
   system calls and handle them by sending messages to HURD servers.

   Ultimately, Alix and I broke up, and she changed her name;
   independently, the HURD design was changed so that the C library would
   send messages directly to servers, and this made the Alix component
   disappear from the design.

   But before these things happened, a friend of hers came across the
   name Alix in the HURD source code, and mentioned the name to her.  So
   the name did its job.

  Linux and GNU/Linux

   The GNU Hurd is not ready for production use.  Fortunately, another
   kernel is available.  In 1991, Linus Torvalds developed a
   Unix-compatible kernel and called it Linux.  Around 1992, combining
   Linux with the not-quite-complete GNU system resulted in a complete
   free operating system.  (Combining them was a substantial job in
   itself, of course.) It is due to Linux that we can actually run a
   version of the GNU system today.

   We call this system version GNU/Linux, to express its composition as a
   combination of the GNU system with Linux as the kernel.

  Challenges in our future

   We have proved our ability to develop a broad spectrum of free
   software.  This does not mean we are invincible and unstoppable.
   Several challenges make the future of free software uncertain; meeting
   them will require steadfast effort and endurance, sometimes lasting
   for years.  It will require the kind of determination that people
   display when they value their freedom and will not let anyone take it
   away.

   The following four sections discuss these challenges.

  Secret hardware

   Hardware manufactures increasingly tend to keep hardware
   specifications secret.  This makes it difficult to write free drivers
   so that Linux and XFree86 can support new hardware.  We have complete
   free systems today, but we will not have them tomorrow if we cannot
   support tomorrow's computers.

   There are two ways to cope with this problem.  Programmers can do
   reverse engineering to figure out how to support the hardware.  The
   rest of us can choose the hardware that is supported by free software;
   as our numbers increase, secrecy of specifications will become a
   self-defeating policy.