bull4.html 36 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792793794795796797798799800801802803804805806807808809810811812813814815816817818819820821822823824825826827828829830831832833834835836837838839840841842843844845846847848849850
  1. <!-- This HTML file has been created by texi2html 1.30
  2. from bull4.texi on 28 January 1995 -->
  3. <TITLE>GNU's Bulletin, vol. 1 no. 4</TITLE>
  4. <H1>GNU's Bulletin, vol. 1 no. 4</H1>
  5. <HR>
  6. <H1><A NAME="SEC1" HREF="bull4_toc.html#SEC1">GNU's Bulletin February, 1988</A></H1>
  7. <P>
  8. GNU's Bulletin is the sporadically published newsletter of the <BR>
  9. Free Software Foundation, bringing you news about the GNU project.
  10. <P>
  11. <B>Please note:</B> we have moved to a new address: <BR>
  12. Free Software Foundation<BR>
  13. 675 Massachusetts Avenue<BR>
  14. Cambridge, MA 02139 USA<BR>
  15. Telephone: (617) 876-3296 <BR>
  16. Electronic mail: gnu@prep.ai.mit.edu <BR>
  17. <P>
  18. <HR>
  19. <P>
  20. <H1><A NAME="SEC3" HREF="bull4_toc.html#SEC3">GNU's Who</A></H1>
  21. <P>
  22. The GNU Team has grown larger in the last few months: <B>Brian Fox</B> and
  23. <B>Opus Goldstein</B> have joined <B>Jay Fenlason</B> as the only employees of
  24. the Foundation. Most recently, Brian created a stand-alone texinfo
  25. formatter and browser and is now working on <CODE>sh</CODE>, the shell. Stacey
  26. is running the mail room, distributing tapes and manuals and generally
  27. doing every thing that programmers do not do (e.g. interfacing with the
  28. "real" world). <B>Jay Fenlason</B> has just finished the profiler and is
  29. now working on miscellaneous utilities.
  30. <P>
  31. <B>Richard Stallman</B> continues to do countless tasks, including refining
  32. the C compiler, GDB, GNU Emacs, etc.; he has also written a termcap manual
  33. and several other documents. <B>Robert J. Chassell</B> publishes our
  34. manuals, and serves as the Foundation's treasurer. <B>Chris Hofstader</B> has
  35. become our fund raiser. (Don't be surprised if he asks you for money.)
  36. Finally, <B>Len Tower</B> continues to handle electronic administrivia
  37. (mailing lists, information requests, and system mothering).
  38. <P>
  39. <HR>
  40. <P>
  41. <H3><A NAME="SEC4" HREF="bull4_toc.html#SEC4">GNU's Bulletin</A></H3>
  42. <P>
  43. Copyright (C) 1988 Free Software Foundation, Inc.
  44. <P>
  45. Editors: Stacey (Opus) Goldstein, Robert J. Chassell, Leonard Tower Jr.
  46. <P>
  47. Writers: Richard M. Stallman, Opus Goldstein, Michael Tiemann
  48. <P>
  49. Illustrations: Etienne Suvasa, Jean-Marie Diaz
  50. <P>
  51. Order form: Karl Berry, Kathryn Hargreaves
  52. <P>
  53. <BLOCKQUOTE>
  54. Permission is granted to anyone to make or distribute verbatim
  55. copies of this document as received, in any medium, provided that
  56. the copyright notice and permission notice are preserved, and
  57. that the distributor grants the recipient permission for further
  58. redistribution as permitted by this notice.
  59. </BLOCKQUOTE>
  60. <P>
  61. <H1><A NAME="SEC5" HREF="bull4_toc.html#SEC5">What Is the Free Software Foundation?</A></H1>
  62. <P>
  63. by Richard M. Stallman
  64. <P>
  65. The Free Software Foundation is dedicated to eliminating restrictions
  66. on copying, redistribution, understanding and modification of software.
  67. <P>
  68. The word "free" in our name does not refer to price; it refers to
  69. freedom. First, the freedom to copy a program and redistribute it to
  70. your neighbors, so that they can use it as well as you. Second, the
  71. freedom to change a program, so that you can control it instead of it
  72. controlling you; for this, the source code must be made available to
  73. you.
  74. <P>
  75. The Foundation works to give you these freedoms by developing free
  76. compatible replacements for proprietary software. Specifically, we
  77. are putting together a complete, integrated software system "GNU" that
  78. is upward-compatible with Unix. When it is released, everyone will be
  79. permitted to copy it and distribute it to others; in addition, it will
  80. be distributed with source code, so you will be able to learn about
  81. operating systems by reading it, to port it to your own machine, to
  82. improve it, and to exchange the changes with others.
  83. <P>
  84. There are already organizations that distribute free CPM and MSDOS
  85. software. The Free Software Foundation is doing something different.
  86. <P>
  87. <OL>
  88. <LI>
  89. The other organizations exist primarily for distribution; they
  90. distribute whatever happens to be available. We hope to provide a
  91. complete integrated free system that will eliminate the need for any
  92. proprietary software.
  93. <P>
  94. <LI>
  95. One consequence is that we are now interested only in software that fits
  96. well into the context of the GNU system. Distributing free MSDOS or
  97. Macintosh software is a useful activity, but it is not our goal. For
  98. information on how to get the software we do distribute, please see the
  99. article later in this issue, `How To Get GNU Software'.
  100. <P>
  101. <LI>
  102. Another consequence is that we will actively attempt to improve and extend
  103. the software we distribute, as fast as our manpower permits. For this
  104. reason, we will always be seeking donations of money, computer equipment or
  105. time, labor, documentation and source code to improve the GNU system.
  106. <P>
  107. <LI>
  108. In fact, our primary purpose is this software development effort;
  109. distribution is just an adjunct which also brings in some money. We
  110. think that the users will do most of the distribution on their own,
  111. without needing or wanting our help.
  112. </OL>
  113. <P>
  114. <H3><A NAME="SEC6" HREF="bull4_toc.html#SEC6">Why a Unix-like System?</A></H3>
  115. <P>
  116. It is necessary to be compatible with some widely used system to give
  117. our system an immediate base of trained users who could switch to it
  118. easily and an immediate base of application software that can run on
  119. it. (Eventually we will provide free replacements for proprietary
  120. application software as well, but that is some years in the future.)
  121. <P>
  122. We chose Unix because it is a fairly clean design which is already
  123. known to be portable, yet whose popularity is still rising. The
  124. disadvantages of Unix seem to be things we can fix without removing
  125. what is good in Unix.
  126. <P>
  127. Why not imitate MSDOS or CP/M? They are more widely used, true, but
  128. they are also very weak systems, designed for tiny machines. Unix is
  129. much more powerful and interesting. When a system takes years to
  130. implement, it is important to write it for the machines that will
  131. become available in the future; not to let it be limited by the
  132. capabilities of the machines that are in widest use at the moment but
  133. will be obsolete when the new system is finished.
  134. <P>
  135. Why not aim for a new, more advanced system, such as a Lisp Machine?
  136. Mainly because that is still more of a research effort; there is a
  137. sizeable chance that the wrong choices will be made and the system
  138. will turn out not very good. In addition, such systems are often tied
  139. to special hardware. Being tied to one manufacturer's machine would
  140. make it hard to remain independent of that manufacturer and get broad
  141. community support.
  142. <P>
  143. <H3><A NAME="SEC7" HREF="bull4_toc.html#SEC7">Our First Large Donation.</A></H3>
  144. <P>
  145. Software Research Associates, a Japanese software house, has donated
  146. $10,000 to the GNU project. In addition they plan to send us a
  147. Sun-like SONY workstation and lend us a staff programmer for 6 months.
  148. <P>
  149. This represents the influence of Kouichi Kishida, who organized the
  150. Japanese Sigma project (to stimulate Unix competence in Japan), only
  151. to conclude later that the project had gone astray and that a "grass
  152. roots movement" was needed instead. We hope to be this movement.
  153. <P>
  154. <H1><A NAME="SEC8" HREF="bull4_toc.html#SEC8">GNUs Flashes, February 1988</A></H1>
  155. <P>
  156. by Richard M. Stallman
  157. <P>
  158. <UL>
  159. <P>
  160. <LI>
  161. <B>Some parts of BSD are becoming free.</B>
  162. <P>
  163. After years of urging from us and others, the people who maintain
  164. Berkeley Unix have decided to release various parts of it (those which
  165. don't contain AT&#38;T code) separately as free software. This includes
  166. substantial programs which we hope to use in GNU, such as TCP/IP
  167. support and the C-shell.
  168. <P>
  169. <LI>
  170. <B>Berkeley and GNU project cooperating.</B>
  171. <P>
  172. The next release of Berkeley Unix may contain Make, AWK and SH from the
  173. GNU project instead of those from Unix.
  174. <P>
  175. The reason is that they would like to have improvements in these programs
  176. like those in system V.3; but they find the new restrictions on V.3
  177. licenses unpalatable. Both we and they hope they never get a V.3 license.
  178. We may help them avoid it by providing alternative software.
  179. <P>
  180. GNU Make already supports the system V features; a volunteer is now writing
  181. the extensions for Gawk.
  182. <P>
  183. <LI>
  184. <B>Shell disappointment.</B>
  185. <P>
  186. For a year and a half, the GNU shell was "just about done". The author
  187. made repeated promises to deliver what he had done, and never kept them.
  188. <P>
  189. Finally I could no longer believe he would ever deliver anything.
  190. <P>
  191. So Foundation staff member <B>Brian Fox</B> is now implementing an imitation
  192. of the Bourne shell. Once it is done, we will extend it with the
  193. features of the Korn shell, thus coming to Berkeley's aid.
  194. <P>
  195. <LI><B>We may use Sprite, or the Sprite file system with MACH.</B>
  196. <P>
  197. We still hope to use the MACH kernel from CMU when it becomes free,
  198. after the parts of Berkeley Unix which currently form part of it have been
  199. replaced as planned.
  200. <P>
  201. The MACH people say that in a month or two certain new features
  202. (call-outs from the kernel to user code) should be ready that will
  203. enable us to start working on replacing some of these parts with new
  204. code.
  205. <P>
  206. One thing we are considering is adapting the file system from
  207. Berkeley's Sprite kernel for use in MACH. This file system was
  208. designed from the beginning to work in a distributed manner. The file
  209. system is the largest part of MACH that needs replacement, now that
  210. the Berkeley TCP/IP code, also used in MACH, has been declared free.
  211. <P>
  212. <LI>
  213. <B>GNU Make is done.</B>
  214. <P>
  215. The GNU version of Make is now ready, and will be distributed soon.
  216. It features conditionals, pattern rules, and indirect search for
  217. implicit rules, and built-in functions for text processing.
  218. <P>
  219. Here is how a GNU Makefile can say that the file `foo' is linked
  220. from the object files of all C source files in the current directory:
  221. <P>
  222. <PRE>
  223. objects=$(subst .c,.o,$(wildcard *.c))
  224. foo: $(objects)
  225. $(CC) -o foo $(objects) $(LDFLAGS)
  226. </PRE>
  227. <P>
  228. <LI>
  229. <B>Most libraries are done.</B>
  230. <P>
  231. <B>Roland McGrath</B>, who contributed a great deal to GNU Make, has a nearly
  232. complete set of ANSI C library functions. We hope they will be ready some
  233. time this spring. These join the GNU <CODE>malloc</CODE>, <CODE>regexp</CODE> and
  234. <CODE>termcap</CODE> libraries that have existed for some time.
  235. <P>
  236. Meanwhile, <B>Steve Moshier</B> has contributed a full series of mathematical
  237. library functions.
  238. <P>
  239. <LI>
  240. <B>Profiler replacement done.</B>
  241. <P>
  242. Foundation staffer <B>Jay Fenlason</B> has recently completed a profiler to
  243. go with GNU C, compatible with `prof' from Berkeley Unix. I hope it
  244. will be distributed with GNU C soon.
  245. <P>
  246. <LI>
  247. <B>Termcap Manual.</B>
  248. <P>
  249. We are now publishing the first thorough manual for Termcap, which some
  250. have suggested ought to be entitled "Twice as much as you ever wanted to
  251. know about Termcap".
  252. <P>
  253. <LI>
  254. <B>GNU mailer being done.</B>
  255. <P>
  256. <B>Landon Noll</B> and <B>Ronald Karr</B> of Amdahl are writing a mail queueing and
  257. delivery system, called Smail. This project will be a supported part
  258. of Amdahl's UTS system--and it will be available on exactly the same
  259. terms as GNU Emacs!
  260. <P>
  261. We may use this mailer for the GNU system, or another mailer that
  262. <B>Rayan Zachariasen</B> is writing, whichever turns out better.
  263. <P>
  264. <LI>
  265. <B>Ghostscript status</B>
  266. <P>
  267. Ghostscript, the free Postscript for GNU, will with luck be finished by
  268. <B>Peter Deutsch</B> (except for bugs) in March. Therefore, it might be ready
  269. for us to distribute a few months later.
  270. <P>
  271. <LI>
  272. <B>Emacs version 18.50</B>
  273. <P>
  274. This version, to be available in a few weeks, will fix many bugs and add
  275. support for the 80386, the Sun 4, the Convex, the IRIS 4d and the HP 9000
  276. series 800; also support for system V.3; and add support for version 11 of
  277. the X window system.
  278. <P>
  279. <LI>
  280. <B>GDB can read COFF format.</B>
  281. <P>
  282. COFF is the hairy executable file format used on system V.
  283. Recently <B>Dave Johnson</B> of Brown University contributed support
  284. for reading COFF files in GDB, the GNU debugger. This code will
  285. appear in GDB 2.5, accompanying Emacs 18.50.
  286. <P>
  287. As a result, it should now be possible to use GDB on system V
  288. without a large amount of work.
  289. <P>
  290. In general, support for COFF isn't important for the GNU project,
  291. since we are going to use the BSD object file format in GNU.
  292. Everything said below about VMS applies to COFF support as well.
  293. <P>
  294. <LI>
  295. <B>G<CODE>++</CODE>, the GNU C<CODE>++</CODE> compiler.</B>
  296. <P>
  297. <B>Michael Tiemann</B> of MCC has written a C<CODE>++</CODE> compiler as an extension
  298. of GNU C. This is the first compiler that compiles C<CODE>++</CODE> directly
  299. instead of preprocessing it into C.
  300. <P>
  301. G<CODE>++</CODE> is now being tested at several sites. Michael believes it is as
  302. reliable as AT&#38;T's C<CODE>++</CODE> preprocessor, but this still leaves a long way
  303. to go before it is a solid product.
  304. <P>
  305. G<CODE>++</CODE> comes with GDB<CODE>+</CODE>, a version of GDB that supports C<CODE>++</CODE> class
  306. operations in its expression evaluator.
  307. <P>
  308. <LI>
  309. <B>GDB and GNU C support the 32000.</B>
  310. <P>
  311. GNU C has now compiled itself correctly on the Sequent 32000 system.
  312. The port was done by Michael Tiemann of MCC, who says it is more
  313. reliable than Sequent's compiler and yields a 40% speedup for several
  314. programs including a prolog interpreter.
  315. <P>
  316. Support for the 32000 is now released in GNU C version 1.17, along
  317. with existing support for the 68000 series and the VAX.
  318. <P>
  319. GDB support for the 32000 is in GDB 2.5, to appear with Emacs 18.50.
  320. <P>
  321. <LI>
  322. <B>GNU C ports in progress.</B>
  323. <P>
  324. People are working on porting GNU C to the IBM 370, to the IBM RT/PC,
  325. and to the 80386. The 80386 is the easiest; there is little doubt
  326. that this port will be available in a few months at most. The other
  327. machines have more troublesome architectural differences and it isn't
  328. yet certain whether GNU C can handle them fully without significant new
  329. features.
  330. <P>
  331. <LI>
  332. <B>GNU C is becoming reliable.</B>
  333. <P>
  334. GNU C bug reports are becoming less frequent, suggesting that it is
  335. approaching a state of reliability. People are still reporting bugs,
  336. but they also say they think there are fewer bugs than in commercial
  337. compilers.
  338. <P>
  339. <B>John Gilmore</B> is now compiling all of BSD Unix with GNU C. He has
  340. found several bugs, but not a great number for such a large amount
  341. of code never before compiled.
  342. <P>
  343. <LI>
  344. <B>GNU C for VMS.</B>
  345. <P>
  346. Fed up with the deficiencies of the VMS C compiler, <B>David Kashtan</B>
  347. from SRI decided to spend a couple of weeks and make GNU C run on
  348. VMS. After making considerable changes to satisfy the VMS C compiler,
  349. he got it running and was able to take most of the changes out.
  350. <P>
  351. We hope to deliver VMS support in GNU C version 1.19 or 1.20,
  352. but we can't be certain when he will finish merging it and deliver it.
  353. (Uh oh, I hope it's not going to take a year...)
  354. <P>
  355. When VMS support is delivered to us, the usual GNU C sources will contain
  356. everything needed for it, but you won't be able to compile them with the
  357. standard VMS C compiler due to its various incompatibilities and
  358. deficiencies. You will need a binary of GNU C. We plan to offer mag tapes
  359. with VMS backup savesets containing binaries as well as sources.
  360. <P>
  361. Other GNU programs currently working on VMS include GNU Emacs and Bison.
  362. <P>
  363. Please don't ask us to devote effort to additional VMS support,
  364. because it is peripheral to the GNU project. We merge in and support
  365. VMS ports that users do, because it is hard to refuse to pass on work
  366. that other people have done. But even when the changes are clean,
  367. this drains considerable effort from our real goal, which is to
  368. produce a complete integrated system. (When they aren't clean, we
  369. summon up the courage to ignore them.) Merging VMS GNU Emacs and
  370. reorganizing the changes to ease future maintenance consumed several
  371. weeks even though the "real work" was done by others. I hope we have
  372. learned not to let this happen again.
  373. <P>
  374. <LI>
  375. <B>Looking for a tech writer.</B>
  376. <P>
  377. We are trying to hire a technical writer, but so far we have not found
  378. anyone suitable. It seems that tech writers are not as likely as
  379. programmers to accept a pay cut to work for our cause. We still have
  380. a couple of candidates who are possible, and we're still looking.
  381. <P>
  382. </UL>
  383. <P>
  384. <H1><A NAME="SEC9" HREF="bull4_toc.html#SEC9">GNU C++</A></H1>
  385. <P>
  386. <I>brings Object Oriented Programming to GNU</I>
  387. <P>
  388. by Michael Tiemann
  389. <P>
  390. C<CODE>++</CODE> is among the most popular languages for object-oriented
  391. programming, for two reasons: it is nearly a superset of C, thus
  392. making it easily accessible to the C user community, and it is
  393. supported by AT&#38;T, which leads a standards-hungry public to believe
  394. that, by subscribing to C<CODE>++</CODE> (as opposed to SmallTalk, Objective C, or
  395. many other alternatives), they are following "the standard". About
  396. a million lines of code have been written in C<CODE>++</CODE>.
  397. <P>
  398. Last summer, I was faced with the task of selecting a language to use for a
  399. new computer architecture project. So strong was the influence of
  400. C<CODE>++</CODE>, that the only decision I could make was "which one".
  401. C<CODE>++</CODE> from AT&#38;T looked like the logical choice, except for two
  402. problems: it is proprietary software, and it is a preprocessor which
  403. converts C<CODE>++</CODE> code into C code. This is slow and means that the
  404. constructs and concepts of C<CODE>++</CODE> aren't available in the debugger.
  405. <P>
  406. I decided to see whether we could quickly modify GNU C into a C<CODE>++</CODE>
  407. compiler that has the quality people expect from compilers for other
  408. languages, such as easy retargetability and source-level debugging
  409. support. I could--and I have.
  410. <P>
  411. The GNU C<CODE>++</CODE> compiler is intended to implement the C<CODE>++</CODE>
  412. programming language, as specified in Stroustrup's reference manual. Since
  413. most of the GNU C compiler is language-independent, it only took six months
  414. to make a general beta-test release. There are still gaps and bugs, but I
  415. am working hard on finishing it. All the optimizations of GNU C apply
  416. equally to C<CODE>++</CODE>. I have also added C<CODE>++</CODE>-inspired
  417. optimizations. Some of them, such as inlining functions, will also work in
  418. some cases for C; others, such as optimizing virtual functions, are
  419. strictly C<CODE>++</CODE>.
  420. <P>
  421. GNU C<CODE>++</CODE> is not only the first free C<CODE>++</CODE> compiler; it is the
  422. first <EM>direct</EM> compiler for C<CODE>++</CODE> available at any price, and it
  423. is the first C<CODE>++</CODE> implementation to interface with a C<CODE>++</CODE>
  424. source-level debugger (GDB<CODE>+</CODE>, a modification of the existing GNU
  425. debugger).
  426. <P>
  427. GNU C<CODE>++</CODE> is therefore remarkable from a technical point of view, but
  428. it is even more remarkable organizationally, because it is free
  429. software whose development was paid for by the Microelectronics and
  430. Computer Technology Corporation (MCC), a consortium established in
  431. 1982 to do long range research for around 20 shareholder companies.
  432. <P>
  433. In January, six months after I started working on GNU C<CODE>++</CODE>, the group
  434. of MCC shareholders sponsoring the computer architecture project were
  435. told for the first time that I was writing free software. It was easy
  436. to imagine they might disapprove, Scrooge-like, or even insist on
  437. halting the work. But it was just the opposite: our cooperation with
  438. the Free Software Foundation was good news to them. Technology
  439. transfer is one of the most difficult barriers for shareholders to
  440. overcome when picking up MCC research.
  441. <P>
  442. When MCC delivers specialized software, it comes with no experts beyond
  443. those who wrote it, and it is all but unusable except by painful learning.
  444. When we deliver software that relies on a proprietary environment which
  445. they do not have access to, that software becomes an expensive hostage of
  446. its environment. By providing software which can be made accessible to
  447. anybody, without fear of compromising cooperative agreements, it gives the
  448. shareholders freedom to use that technology in ways previously unavailable
  449. to them.
  450. <P>
  451. Our group was specifically congratulated on its achievement of delivering
  452. technology that they wanted, and making that technology available via the
  453. Free Software Foundation. Considering that this is the first free software
  454. that MCC has ever sponsored, and the incredibly positive reaction that we
  455. received, it is very exciting to think of the possibilities that lie ahead.
  456. <P>
  457. <H1><A NAME="SEC10" HREF="bull4_toc.html#SEC10">GNU Software Available Now</A></H1>
  458. <P>
  459. <UL>
  460. <LI>
  461. <B>GNU Emacs</B>
  462. <P>
  463. In 1975, Richard Stallman developed the first Emacs: the extensible,
  464. customizable real-time display editor. GNU Emacs is his second
  465. implementation of Emacs. It's the first Emacs available on Unix
  466. systems which offers true Lisp, smoothly integrated into the editor,
  467. for writing extensions. It also provides a special interface to
  468. MIT's free X window system, version 10, which makes redisplay very fast.
  469. <P>
  470. GNU Emacs has been in widespread use since 1985 and often, as at
  471. MIT's Project Athena, displaces proprietary implementations of Emacs
  472. because of its greater reliability as well as its good features
  473. and easier extensibility.
  474. <P>
  475. GNU Emacs (as of version 18.50) has run on many kinds of Unix systems:
  476. those made by Alliant (system release 1, 2 or 3), Amdahl (UTS), AT&#38;T (3b
  477. machines and 7300 pc), CCI 5/32 and 6/32, Celerity, Convex, Digital (Vax,
  478. not PDP-11), Dual, Elxsi 6400, Encore, GEC 93, Gould, HP (9000 series 200,
  479. 300 or 800 (Spectrum) but not series 500), IBM (RT/PC running 4.2 and AIX),
  480. Integrated Solutions (Optimum V with 68020 and VMEbus), Iris (2500 Turbo
  481. and 4D), LMI (Nu), Masscomp, Megatest, MIPS, NCR (Tower 32), Nixdorf Targon
  482. 31, Plexus, Pyramid, Sequent, Stride (system release 2), Sun (any kind),
  483. Tahoe, Tektronix (NS16000 system), Texas Instruments (Nu), Whitechapel
  484. (MG1), and Wicat. These include both Berkeley Unix and System V (release
  485. 0, 2, 2.2 or 3). Emacs also runs on several 80386 machines. It also runs
  486. on Apollo machines and on VAX/VMS.
  487. <P>
  488. GNU Emacs use is described by the GNU Emacs Manual, available from
  489. the Free Software Foundation.
  490. <P>
  491. <LI>
  492. <B>GDB</B>
  493. <P>
  494. GDB is the source-level C debugger written for the GNU project in 1986. It
  495. offers many features not usually found in debuggers on Unix, such as a
  496. history that records all values examined within the debugger for concise
  497. later reference, multi-line user-defined commands, and a strong
  498. self-documentation capability. It currently runs on VAXen under 4.2 and
  499. 4.3bsd, on Suns (systems version 2 and 3), and on some 32000 systems.
  500. <P>
  501. A users' manual for GDB is available from the Foundation.
  502. <P>
  503. <LI>
  504. <B>GNU CC</B>
  505. <P>
  506. The GNU C compiler is a fairly portable optimizing compiler. It generates
  507. good code for the 32000, 68000, 68020 and Vax. It features automatic
  508. register packing that makes register declarations unnecessary. It supports
  509. full ANSI C as of the latest draft standard. The texinfo source of the
  510. manual "Internals of GNU CC" is included.
  511. <P>
  512. <LI>
  513. <B>Bison</B>
  514. <P>
  515. Bison is an upward-compatible replacement for YACC, with additional
  516. as-yet-undocumented features. It has been in use for several years.
  517. <P>
  518. <LI>
  519. <B>X Window System</B>
  520. <P>
  521. X is a portable, network transparent window system for bitmap displays
  522. written at MIT and DEC. It currently runs on DEC VAXstation, Lexidata 90,
  523. and most Sun Microsystems displays, with others in the works. X supports
  524. overlapping windows and fully recursive subwindows, and provides hooks for
  525. several different styles of user interface. Applications provided include
  526. a terminal emulator, bitmap editor, several window managers, clock, window
  527. dump and undump programs, hardcopy printing program for the LN03 printer,
  528. and several typesetting previewers.
  529. <P>
  530. Version 10 of X Windows is distributed on the GNU Emacs tape; version 11
  531. (which is totally incompatible) is distributed on the GCC tape. Emacs
  532. version 18.50 will support both versions 10 and 11.
  533. <P>
  534. <LI>
  535. <B>MIT Scheme</B>
  536. <P>
  537. Scheme is a simplified, lexically scoped dialect of Lisp, designed at
  538. MIT and other universities for two purposes: teaching students of
  539. programming, and researching new parallel programming constructs
  540. and compilation techniques. MIT Scheme is written in C and runs on
  541. many kinds of Unix systems.
  542. <P>
  543. Sorry, we do not distribute documentation with the the current distribution
  544. version of MIT Scheme. A new standard for Scheme has been designed by the
  545. various labs that work on Scheme, and work is going on at MIT to change MIT
  546. Scheme to fit. Once that is done, the standard will serve as a manual for
  547. MIT Scheme. At that time, we will distribute both the new release of
  548. Scheme and the standard. In the meantime, several books have been
  549. published about Scheme.
  550. <P>
  551. <LI>
  552. <B>Hack</B>
  553. <P>
  554. Hack is a display oriented adventure game similar to Rogue.
  555. </UL>
  556. <P>
  557. <H1><A NAME="SEC11" HREF="bull4_toc.html#SEC11">The GDB Song</A></H1>
  558. <P>
  559. <I>with thanks to Joel Bion, Mark Baushke, and Lynn Slater</I>
  560. <P>
  561. Somebody asked us what was GDB. With apologies to Oscar Hammerstein
  562. II, Richard Rodgers, and Julie Andrews, we offered the following reply:
  563. <P>
  564. Let's start at the very beginning, a very good place to start,
  565. <P>
  566. When you're learning to sing, its Do, Re, Mi; <BR>
  567. When you're learning to code, its G, D, B. <BR>
  568. <P>
  569. (background) G, D, B.
  570. <P>
  571. The first three letters just happen to be, G, D, B.
  572. <P>
  573. (background) G, D, B.
  574. <P>
  575. (Chorus)
  576. <P>
  577. <DL COMPACT>
  578. <P>
  579. <DT>G!,
  580. <DD> GNU!, it's Stallman's hope,
  581. <DT>B,
  582. <DD> a break I set myself.
  583. <DT>D,
  584. <DD> debug that rotten code,
  585. <DT>Run,
  586. <DD> a far, far way to go.
  587. <DT>Print,
  588. <DD> to see what you have done,
  589. <DT>Set,
  590. <DD> a patch that follows print.
  591. <P>
  592. <DT>Quit,
  593. <DD> and recompile your code - - -
  594. <P>
  595. </DL>
  596. <P>
  597. <PRE>
  598. That will bring it back to G,
  599. D,
  600. B,
  601. &#60;link&#62;
  602. </PRE>
  603. <P>
  604. (Resume from the Chorus)
  605. <P>
  606. <H1><A NAME="SEC12" HREF="bull4_toc.html#SEC12">Why Was Copyright Invented?</A></H1>
  607. <P>
  608. by Richard M. Stallman
  609. <P>
  610. Now that copyright is becoming a public nuisance that the public tries
  611. to ignore, copyright owners try to justify this imposition by calling
  612. it an intrinsic right. As they tell it, their intrinsic right is a
  613. tradition that makes the public good irrelevant.
  614. <P>
  615. This is contrary to the facts of the history of copyright.
  616. <P>
  617. The Supreme Court has stated explicitly what copyright was for.
  618. Writing for the Court, Justice Stewart explained:
  619. <P>
  620. <BLOCKQUOTE>
  621. The immediate effect of our copyright law is to secure a fair return
  622. for an "author's" creative labor. But the ultimate aim is, by this
  623. incentive, to stimulate artistic creativity for the general public good.
  624. `The sole interest of the United States and the primary object in
  625. conferring the [copyright] monopoly,' this Court has said, `lie in the
  626. general benefits derived by the public from the labors of authors.'
  627. </BLOCKQUOTE>
  628. <PRE>
  629. <TT> </TT>---Fox Film Corp. v. Doyal (286 US 123, 127)
  630. </PRE>
  631. <P>
  632. So when copyright interferes with the public use of a program, that
  633. directly attacks the reason for having copyright.
  634. <P>
  635. <H1><A NAME="SEC13" HREF="bull4_toc.html#SEC13">When Programs Become Available</A></H1>
  636. <P>
  637. <I>or Rather, how NOT to find out when a program becomes available...</I>
  638. <P>
  639. by Richard M. Stallman
  640. <P>
  641. I have dared to make a few predictions about when certain programs
  642. will be ready for distribution. Now, after the fact, I hope that
  643. wasn't a mistake.
  644. <P>
  645. Creating a given program often takes much longer than expected. If
  646. this happens, many of you who are eager to use it might have the idea
  647. of phoning or writing to ask me whether the program is available yet.
  648. Or, even worse, to describe which parts are completed, or which
  649. machines it will be ported to, or how easy it will be to port to
  650. certain machines, or which features are going to be implemented.
  651. <P>
  652. Some of these questions have no answers. When a program isn't
  653. finished, we don't know which features we will add while finishing it.
  654. We don't make plans to port programs because our usual policy is to
  655. leave porting up to you. This is a way of recruiting wider
  656. participation.
  657. <P>
  658. Responding to all possible inquiries would divert time and energy and slow
  659. the completion of the program, causing even more inquiries. Were we to
  660. permit this to happen, the amount of time left to devote to programming
  661. could approach zero.
  662. <P>
  663. Only you can save the GNU project from this absurd fate. Please
  664. exert your will power, be patient, and wait for us to announce that
  665. programs are available. If you would like to see more GNU software
  666. appear faster, the best thing to do is to volunteer a significant
  667. amount of your time.
  668. <P>
  669. The best way to find out quickly when a piece of GNU software is released
  670. or updated for general on-line distribution is to arrange to receive the
  671. info-gnu mailing list on which our announcements are made. To receive
  672. info-gnu, send a request to
  673. <P>
  674. <CODE>ucbvax!prep.ai.mit.edu!info-gnu-request (usenet)</CODE>
  675. <P>
  676. <CODE>info-gnu-request@prep.ai.mit.edu (internet)</CODE>
  677. <P>
  678. Some specific programs such as Emacs, GCC, GDB, GNU Chess, and G<CODE>++</CODE>
  679. have specific mailing lists of their own on which new versions are
  680. announced. To be on these lists, just mention in your request which
  681. programs you are interested in.
  682. <P>
  683. Tape distribution normally starts some weeks later than on-line
  684. distribution, either because we demand a higher standard of
  685. reliability for users who cannot easily get upgrades, or because we
  686. are hopelessly confused and can't get our act together. We generally
  687. make another electronic announcement when tape distribution starts.
  688. You can order tapes in advance if you wish, if you understand that
  689. delivery may be delayed for many weeks while we work on reliability.
  690. <P>
  691. When we expect true reliability to take many months to achieve, we may
  692. offer a beta-test tape at an earlier date, as we are doing with GNU C.
  693. We announce these tapes in the usual ways.
  694. <P>
  695. If you can't receive Usenet or Internet mail and you are planning to order
  696. a tape of a specific program, you can telephone the Foundation to find out
  697. whether the program is available for tape distribution. Our phone number
  698. is (617) 876-3296. It is best to call in the morning, EST, as you will be
  699. more likely to reach Opus Goldstein, our office and shipping person,
  700. rather than our tape machine. In general, Opus cannot contact each
  701. person individually to say when a tape is ready, but perhaps an arrangement
  702. can be made if it is important.
  703. <P>
  704. If you are planning to get a copy from someone else, please ask that
  705. person to inform you when it is ready. This will spread the burden.
  706. <P>
  707. If you are truly desperate for a prognostication, you might try
  708. consulting your local fortune-tellers. They don't know any less than
  709. we about the future.
  710. <P>
  711. <H3><A NAME="SEC14" HREF="bull4_toc.html#SEC14">GNU Wish List</A></H3>
  712. <P>
  713. <UL>
  714. <LI>
  715. Money, as always. Please remember, we are tax-deductable and, among other
  716. things, we want to hire somebody to write documentation!!!
  717. <P>
  718. <LI>
  719. Office equipment, e.g. a desktop copier; a nifty new phone answering
  720. machine that deletes old messages; a couple of Sun workstations or VAXen;
  721. 1200/2400/4800/9600 baud modems; and an electric typewriter that has a
  722. delete key.
  723. <P>
  724. <LI>
  725. Highly knowledgible technical people to write excellent documentation on
  726. a volunteer basis.
  727. <P>
  728. <LI>
  729. Top flight programmers to help write utilities and compilers for new
  730. languages.
  731. <P>
  732. <LI>
  733. Clipings of media articles mentioning GNU.
  734. </UL>
  735. <P>
  736. <H1><A NAME="SEC15" HREF="bull4_toc.html#SEC15">How To Get GNU Software</A></H1>
  737. <P>
  738. All the software and publications from the Free Software Foundation
  739. are distributed with permission to
  740. copy and redistribute. The easiest way to get a copy of GNU software
  741. is from someone else who has it. Just copy it from them.
  742. <P>
  743. If you have access to the Internet, you can get the latest
  744. software from the host <TT>`prep.ai.mit.edu'</TT>. For
  745. more information, read the file <TT>`/u2/emacs/GETTING.GNU.SOFTWARE'</TT>
  746. on that host.
  747. <P>
  748. If you cannot get the software from a friend or over the net, the Free
  749. Software Foundation distributes tapes for a copying and distribution fee.
  750. See the order form on the inside back cover.
  751. <P>
  752. If you do not have net access, and your computers cannot use either of the
  753. two media we distribute on, you must get our software from third party
  754. groups--people and organizations that do not work with us, but have our
  755. software in other forms. For your convenience, other groups that are
  756. helping to spread GNU software are listed below. Please note that the Free
  757. Software Foundation is <I>not</I> affiliated with them in any way, and is not
  758. responsible for either the currency of their versions or the swiftness of
  759. their responses.
  760. <P>
  761. These Internet sites have some GNU programs available for anonymous FTP:
  762. <CODE>louie.udel.edu</CODE>, <CODE>nic.nyser.net</CODE>, <CODE>bu-it.bu.edu</CODE>,
  763. <CODE>uunet.uu.net</CODE>, <CODE>spam.istc.sri.com</CODE>, and <CODE>simtel20.arpa</CODE>
  764. (under PD:&#60;UNIX.GNU&#62;).
  765. <P>
  766. Information on how to uucp some GNU programs is available via electronic
  767. mail from: <CODE>arnold@skeeve.UUCP</CODE>, <CODE>ihnp4!hutch!barber</CODE>,
  768. <CODE>hqda-ai!merlin</CODE>. Also, you can ask:
  769. <CODE>hao!scicom!qetzal!upba!ugn!nepa!denny</CODE> or else from:
  770. <CODE>postmaster@uunet.uu.net</CODE>.
  771. <P>
  772. Ohio State also uucps GNU programs. They post their instructions monthly
  773. to newsgroup <CODE>comp.sources.d</CODE> on Usenet. Current details from Karl
  774. Kleinpaste <CODE>karl@tut.cis.ohio-state.edu</CODE> or
  775. <CODE>karl@ohio-state.arpa</CODE> or <CODE>...!cbosgd!osu-cis!karl</CODE>; or Bob
  776. Sutterfield (substitute bob for karl in the above addresses).
  777. <P>
  778. Information on obtaining floppy disks of GNU Emacs for the AT&#38;T Unix PC
  779. (aka 3B1 or PC7300) is available via electronic mail from:
  780. <CODE>brant@manta.uucp</CODE>.
  781. <P>
  782. <H1><A NAME="SEC16" HREF="bull4_toc.html#SEC16">Thank GNUs</A></H1>
  783. <P>
  784. Thanks to all those mentioned in GNU Flashes.
  785. <P>
  786. Thanks to the MIT Laboratory for Computer Science, and its head,
  787. <B>Professor Dertouzos</B>. The LCS has provided FSF with the loan of a
  788. Microvax for program development.
  789. <P>
  790. Thanks to the MIT Artificial Intelligence Laboratory for invaluable
  791. assistance of many kinds.
  792. <P>
  793. Thanks to <B>Nobuyuki Hikichi</B> of Software Research Associates, Tokyo, for
  794. porting GCC to the SONY NEWS machine. Thanks also for the $10,000 they
  795. contributed.
  796. <P>
  797. Thanks to NeXT, Inc., for their improvements to the GNU Assembler and the
  798. Gnu DeBugger.
  799. <P>
  800. Thanks to <B>Micheal Tiemann</B> of MCC for extending GCC and GDB to handle
  801. C<CODE>++</CODE> and for porting GCC to the 32000 with some contributions from
  802. <B>Jan Stein</B> of the Chalmers Computer Club.
  803. <P>
  804. Thanks to <B>Ted Lemon</B> who wrote parts of the RTL reader and printer for GCC.
  805. <P>
  806. For porting GCC, thanks to <B>Charles LaBrec</B> (Integrated Solutions 68020
  807. system); to <B>Greg Satz</B>(HPUX); to <B>David Kashtan</B> (VMS).
  808. <P>
  809. Thanks to <B>David S. Hayes</B> for enhancing GNU diff.
  810. <P>
  811. Thanks to <B>Dan LaLiberte</B> for spearheading the GNU Emacs Lisp Programmers
  812. Manual, and to <B>Bill Lewis</B> and <B>Tom Scott</B> who have been working on
  813. putting it all together.
  814. <P>
  815. Thanks to <B>Wolfgang Rupprecht</B> for providing floating point support for
  816. GNU Emacs.
  817. <P>
  818. Thanks to <B>Torbjorn Granlund</B> for fast implementations of <CODE>split</CODE>,
  819. <CODE>wc</CODE>, <CODE>cmp</CODE>, <CODE>cat</CODE> and <CODE>cp</CODE>.
  820. <P>
  821. Thanks to all those who have contributed ports and extensions, as well as
  822. those who have contributed other source code, documentation, and good bug
  823. reports.
  824. <P>
  825. Thanks to those who sent money and offered help. Thanks also to those
  826. who support us by ordering Emacs manuals and distribution tapes.
  827. <P>
  828. The creation of this bulletin is our way of thanking all who have
  829. expressed interest in what we are doing.
  830. <P>
  831. <HR>
  832. <P>
  833. <PRE>
  834. -------
  835. | |
  836. Free Software Foundation, Inc. | stamp |
  837. 675 Massachusetts Avenue | |
  838. Cambridge, MA 02139 | here |
  839. | |
  840. -------
  841. </PRE>
  842. <P>
  843. <HR>