rms@GNU.AI.MIT.EDU (Richard Stallman) (03/22/91)
In my own work, I'm not going to install support for using compress as long as it's something we can't safely use. Some people advise not worrying about the issue, which means counting on it to be bypassed before it becomes acute. But this seems risky and unwise to me.
darrylo@HPNMXX.HP.COM (03/22/91)
RMS says: > In my own work, I'm not going to install support for using compress as > long as it's something we can't safely use. Some people advise not > worrying about the issue, which means counting on it to be bypassed > before it becomes acute. But this seems risky and unwise to me. [ Normally, I'd keep my mouth shut, as (1) I like the FSF, (2) this topic doesn't belong here, and (3) I really don't have the time to write a reply. However, I can't pass this up. ] RMS says that we should not use compress. Well, that's fine, but we do not yet have a good replacement. Until the FSF releases "GNU file reduction" or whatever, people will continue to use compress, and they'll continue to use compress, and they'll continue to use compress, ad nauseam. This brings up a another "hot" topic: the "timelyness" of FSF software. I'm worried that the world will pass by the FSF. I'm sure that I am not alone when I say that I support the FSF, and that I really appreciate what they are doing. However, the incredibly slow rate of software development is nearly unbelievable (I like to think of it as "legendary"). I realize that part of the problem may be beyond the control of the FSF, but the two biggest offenders are GNU Emacs and Bash. Those people who follow the Bash saga will know what I'm talking about. I'm not trying to insult the developers of GNU Emacs or Bash -- I really appreciate what they are doing. However, I would appreciate it if the FSF would take MUCH MORE CARE with announcing schedules. It's very, super, incredibly, unbelievably annoying when a developer says that program "X" will be released in a couple of weeks, and then months, or even years, pass by. The developers of GNU Emacs have gotten better -- at least they are no longer giving out rough schedules. My favorite message is (NOTE THE DATE): ------------------------------------------------------------------------------- From rms@WHEATIES.AI.MIT.EDU Thu Sep 1 13:05:25 1988 From: rms@WHEATIES.AI.MIT.EDU (Richard Stallman) Date: Thu, 1 Sep 1988 20:05:25 GMT Subject: Emacs 18.52 available Newsgroups: comp.emacs Sender: daemon@eddie.MIT.EDU Lines: 11 Emacs 18.52 is now available on prep.ai.mit.edu in /u/emacs/edist.tar-18.52.Z. This file is around 4 meg. Compressed differences from 18.51 are in /u/emacs/diff-18.51-18.52.Z. They are 542000 bytes. This is the last release of Emacs I intend to make before version 19. The first test releases of version 19 will probably be in 6 to 9 months. Version 19 already has support for multiple X windows, per-buffer mouse commands, scroll bars, and European character sets. I don't know what other new features it will have. ------------------------------------------------------------------------------- *OVER* *FOUR* *YEARS* *AGO*, HP had an internal MULTI-WINDOW version of GNU Emacs V18.44, with scroll bars, etc., working under X10 (that's VERSION TEN of X-windows), and it was ported to X11. A year or two ago, Epoch appears (Epoch is better than HP's version, BTW). What's taking the FSF? If two independent groups can create a multi-window version of GNU Emacs, in a relatively short period of time, what is taking the FSF so long? Sure, making Emacs work on both X-windows and terminals is more work, but this doesn't account for the vast time differences. Given the quality of the existing FSF software, I can't believe that the FSF programmers are not as good as anyone else. What gives? Has the development stopped? -- Darryl Okahata UUCP: {hplabs!, hpcea!, hpfcla!} hpnmd!darrylo Internet: darrylo%hpnmd@relay.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion or policy of Hewlett-Packard or of the little green men that have been following him all day.
tiemann@CYGNUS.COM (Michael Tiemann) (03/22/91)
Date: Thu, 21 Mar 91 14:52:53 PST From: darrylo@hpnmxx.hp.com RMS says: > In my own work, I'm not going to install support for using compress as > long as it's something we can't safely use. Some people advise not > worrying about the issue, which means counting on it to be bypassed > before it becomes acute. But this seems risky and unwise to me. [ Normally, I'd keep my mouth shut, as (1) I like the FSF, (2) this topic doesn't belong here, and (3) I really don't have the time to write a reply. However, I can't pass this up. ] RMS says that we should not use compress. Well, that's fine, but we do not yet have a good replacement. Until the FSF releases "GNU file reduction" or whatever, people will continue to use compress, and they'll continue to use compress, and they'll continue to use compress, ad nauseam. Why does everybody have to wait for RMS to do something with free software? Why can't people take more initiative...enough that they don't depend only on one person. This brings up a another "hot" topic: the "timelyness" of FSF software. I'm worried that the world will pass by the FSF. I'm worried about a related problem: the "timeliness" of people's recognition of how they are allocating their resources. I'm worried that too many people will miss too many opportunities just waiting for others to do their work for them. I'm sure that I am not alone when I say that I support the FSF, and that I really appreciate what they are doing. However, the incredibly slow rate of software development is nearly unbelievable (I like to think of it as "legendary"). I realize that part of the problem may be beyond the control of the FSF, but the two biggest offenders are GNU Emacs and Bash. Those people who follow the Bash saga will know what I'm talking about. I don't really know. I've been running bash for about a year, and I love it. Occaisionally somebody replaces my bash with a newer version, but since I've never had a problem (well, more than one), I don't find out until it comes up in conversation. Of course I'm not a power bash user, so perhaps my perspective is not that important. I'm not trying to insult the developers of GNU Emacs or Bash -- I really appreciate what they are doing. However, I would appreciate it if the FSF would take MUCH MORE CARE with announcing schedules. It's very, super, incredibly, unbelievably annoying when a developer says that program "X" will be released in a couple of weeks, and then months, or even years, pass by. FSF has very little control over an amazingly large problem. When you consider that their total annual income is probably less than $1M, that they are a non-profit organization, primarily devoted to serving hackers by sharing with them, you'll realize just how unimportant the needs of company X or company Y can appear. Michael Disclaimer: I work for a company that cares how company X and company Y are having their needs met by free software.
darrylo@HPNMXX.HP.COM (03/22/91)
> Why does everybody have to wait for RMS to do something with free > software? Why can't people take more initiative...enough that they > don't depend only on one person. > > This brings up a another "hot" topic: the "timelyness" of FSF > software. I'm worried that the world will pass by the FSF. > > I'm worried about a related problem: the "timeliness" of people's > recognition of how they are allocating their resources. I'm worried > that too many people will miss too many opportunities just waiting for > others to do their work for them. Well, I'm more than willing the help the FSF, but I'm only qualified to work on GNU Emacs, a project which the FSF says needs no more volunteers. I'm one of the main enhancers of GNU Emacs within HP. -- Darryl Okahata UUCP: {hplabs!, hpcea!, hpfcla!} hpnmd!darrylo Internet: darrylo%hpnmd@relay.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion or policy of Hewlett-Packard or of the little green men that have been following him all day.
tiemann@CYGNUS.COM (Michael Tiemann) (03/23/91)
> Disclaimer: I work for a company that cares how company X and company Y > are having their needs met by free software. Just goes to show you a bit about the ideals of RMS. The free software that is supposed to be a help to everyone can be expensive to a few. Cygnus charges up to $100,000.00 for support for one set of tools (like gdb, gcc, g++) on a platform. Cygnus cares about company X and company Y because you make your living at it. Would you do the same job for free? I don't think that the price we charge has anything to do with free software. Freedom and price are different, unrelated issues. RMS's ideals are ideals about freedom. I see a tangible, competititve advantage to these benefits, and apply them to business. $100,000 is *cheap* compared to what most companies throw away on software development each year. Compare $100k to the $1M to $2M that most large companies are paying (via internal or external costs), and you'll see that we're cheap, though not without cost. All software we develop is freely redistributable, leading me to claim that we still do write "free software". Anyway, idealistically, I hope that more people can recognize the importance of putting their money into free software, so we can all benefit from the economies of scale that truly standard, universal software has to offer. Michael
rms@GNU.AI.MIT.EDU (Richard Stallman) (04/01/91)
>It's not a good idea for people to introduce further use of compress, >because it's patented, and Unisys wants us to pay for the privilege. HUH? Last I heard, they didn't care about software implementations -- they were concerned with hardware ones. I became concerned about use of compress when Unisys told the POSIX committee that the implementors of POSIX systems (of which the GNU project might be one) would have to pay royalties for use of LZW. There was a time when (it seemed) Unisys planned to attack only hardware implementations, but that was some years ago. James Woods told me that even at that time, their lawyer said that demanding royalties from individual end users of compress would be an "enforcement problem". In other words, only practical difficulties would stop Unisys from doing just that! Luckily, compress has been removed from the POSIX spec. However, as long as users keep using compress, they will give other users a reason to use it, which means the community won't be free of danger from it. The FSF will switch over to one of Bernstein's programs soon unless a better alternative matures sooner. Even if/when it existed, the intention to leave software implementations alone was just a policy--something they were able to change at any time, and did. This shows the danger of relying on the forebearance of a corporation: it will last only as long as it is expedient. The only way we can be safe is not to give them the power to interfere with our work.