Path: gmdzi!unido!fauern!ira.uka.de!sol.ctr.columbia.edu!
zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!unreplyable!garbage
From: r...@GNU.AI.MIT.EDU (Richard Stallman)
Newsgroups: gnu.emacs.help,comp.emacs
Subject: Compress
Message-ID: <9103211803.AA00380@mole.gnu.ai.mit.edu>
Date: 21 Mar 91 18:03:13 GMT
Sender: dae...@tut.cis.ohio-state.edu
Followup-To: gnu.emacs.help
Organization: Gatewayed from the GNU Project mailing list
help-gnu-em...@prep.ai.mit.edu
Lines: 4
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.
Path: gmdzi!unido!mcsun!sunic!uupsi!rpi!usc!zaphod.mps.ohio-state.edu!
tut.cis.ohio-state.edu!unreplyable!garbage
From: r...@GNU.AI.MIT.EDU (Richard Stallman)
Newsgroups: gnu.emacs.help,comp.emacs
Subject: Loading compressed .el's
Message-ID: <9103202037.AA15663@mole.gnu.ai.mit.edu>
Date: 20 Mar 91 20:37:44 GMT
References: <9103201842.AA24336@curley.osf.org>
Sender: dae...@tut.cis.ohio-state.edu
Followup-To: gnu.emacs.help
Organization: Gatewayed from the GNU Project mailing list
help-gnu-em...@prep.ai.mit.edu
Lines: 11
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.
True, they won't come after an individual to demand money. They won't
even know about you. However, the more we get in the habit of using
compress, the harder it will be for larger organizations to drop it
when forced otherwise to pay.
We are working on alternative data-compression programs, and so are
other people, but there's no telling when one will be available and
suitable.
Path: gmdzi!unido!mcsun!uunet!ukma!wuarchive!zaphod.mps.ohio-state.edu!
tut.cis.ohio-state.edu!unreplyable!garbage
From: darr...@HPNMXX.HP.COM
Newsgroups: gnu.emacs.help,comp.emacs
Subject: Re: Compress
Message-ID: <9103212300.AA16511@hpnmd.hp.com>
Date: 21 Mar 91 22:52:53 GMT
Sender: dae...@tut.cis.ohio-state.edu
Followup-To: gnu.emacs.help
Organization: Gatewayed from the GNU Project mailing list
help-gnu-em...@prep.ai.mit.edu
Lines: 83
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 r...@WHEATIES.AI.MIT.EDU Thu Sep 1 13:05:25 1988
From: r...@WHEATIES.AI.MIT.EDU (Richard Stallman)
Date: Thu, 1 Sep 1988 20:05:25 GMT
Subject: Emacs 18.52 available
Newsgroups: comp.emacs
Sender: dae...@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%hp...@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.
Path: gmdzi!unido!mcsun!uunet!ukma!wuarchive!zaphod.mps.ohio-state.edu!
magnus.acs.ohio-state.edu!tut.cis.ohio-state.edu!unreplyable!garbage
From: tiem...@CYGNUS.COM (Michael Tiemann)
Newsgroups: gnu.emacs.help,comp.emacs
Subject: Compress
Message-ID: <9103212328.AA01645@cygnus.com>
Date: 21 Mar 91 23:28:18 GMT
References: <9103212300.AA16511@hpnmd.hp.com>
Sender: dae...@tut.cis.ohio-state.edu
Reply-To: tiem...@cygnus.com
Followup-To: gnu.emacs.help
Organization: Cygnus Support, Palo Alto CA; Phone +1 415 322 3811
Lines: 64
Date: Thu, 21 Mar 91 14:52:53 PST
From: darr...@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.
Path: gmdzi!unido!mcsun!uunet!orca!javelin.es.com!javelin!cpetterb
From: cpett...@es.com (Cary Petterborg)
Newsgroups: gnu.emacs.help
Subject: Re: Compress
Message-ID: <CPETTERB.91Mar22113650@mickey.es.com>
Date: 22 Mar 91 16:36:50 GMT
References: <9103212300.AA16511@hpnmd.hp.com> <9103212328.AA01645@cygnus.com>
Sender: n...@javelin.es.com
Followup-To: gnu.emacs.help
Organization: Evans & Sutherland Computer Corp.
Lines: 89
In-Reply-To: tiemann@CYGNUS.COM's message of 21 Mar 91 23:28:18 GMT
Nntp-Posting-Host: mickey.sim.es.com
In article <9103212328.AA01...@cygnus.com> tiem...@CYGNUS.COM (Michael Tiemann)
writes:
> 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.
Okay, I make mods and send them on to FSF who says, "Not what we want,
chuck 'em." And then when a new release is made I have to go back
and make the same mods all over again. There should be some way
to make it easier to globally incorporate changes to the software.
No, I don't have any ideas. Yes, I know about Cygnus.
> > 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.
See above.
> > 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 have found at least 5 bugs, 3 of which I have found and fixed, and
2 more which I just get around because I chased them for a couple of
hours and couldn't dedicate any more time to. I'm not a power bash user
either, but I found 5 bugs! Some were incredibly fundamental to even
running it! I can't believe that others haven't had the same problems
so I haven't bothered reporting them. I guess I was wrong and so I
will report the bugs now. The lack of documentation for Bash is
rediculous as well. I love bash, even with its problems, but support
for it has been bad at best.
> > 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.
I agree
> 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.
What about that FSF? What IS your total annual income, both in dollars
and donations of equipment? Are you really making so much less than
the rest of us in the land of profit?
> Michael
> 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 have no beef with Cygnus. I like what they are doing. I just think
that free software as spoken of my RMS is not really so free. What's
your salary, RMS? (You'll probably say none of my business.) BTW,
I like the software that FSF provides and I try my best to support FSF.
Sorry if I have insighted any flames. Please restrain.
Cary
--
_______________
Cary Petterborg (801)582-5847 x6446
Evans & Sutherland Computer Corp. Simulation Division SLC, UT 84108
USENET: utah-cs!esunix!cpetterb INTERNET: cpett...@esunix.es.com
Path: gmdzi!unido!fauern!ira.uka.de!sol.ctr.columbia.edu!
zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!unreplyable!garbage
From: tiem...@CYGNUS.COM (Michael Tiemann)
Newsgroups: gnu.emacs.help,comp.emacs
Subject: Compress
Message-ID: <9103221922.AA24418@cygnus.com>
Date: 22 Mar 91 19:22:30 GMT
References: <CPETTERB.91Mar22113650@mickey.es.com>
Sender: dae...@tut.cis.ohio-state.edu
Reply-To: tiem...@cygnus.com
Followup-To: gnu.emacs.help
Organization: Cygnus Support, Palo Alto CA; Phone +1 415 322 3811
Lines: 26
> 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
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!
magnus.acs.ohio-state.edu!tut.cis.ohio-state.edu!unreplyable!garbage
From: r...@GNU.AI.MIT.EDU (Richard Stallman)
Newsgroups: gnu.emacs.help,comp.emacs
Subject: compress
Message-ID: <9103311918.AA27156@mole.gnu.ai.mit.edu>
Date: 31 Mar 91 19:18:17 GMT
Sender: dae...@tut.cis.ohio-state.edu
Followup-To: gnu.emacs.help
Distribution: world
Organization: Gatewayed from the GNU Project mailing list
help-gnu-em...@prep.ai.mit.edu
Lines: 33
>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.