shap@ucbvax.berkeley.edu@sfdww.UUCP (01/06/87)
What no one seems to have pointed out is that the super users are doing this in response to a real problem. While some emacs users are expert enough to make proper use of the backup facility, new users are not, and the resultant disk space crunches are real and severe. This is what is prompting super-users to do this. Since most users of emacs are non-expert, I propose changing the default behavior of backups to make *one* backup. This backup should have a name distinct from the naming convention of the long term "expert" backups so that super-users can delete old ones to manage their disks. In short, we need two backup flavors. By and large, the superusers aren't out to get people, but they have a real problem, and rms has as usual gone off half-cocked blasting them to hell for incompetence. Richard, I get sick of that and so does everyone else, and it doesn't help your product any. When will you learn that a product doesn't stand on merit - it stands on marketing first, then merit? Not everyone has infinite diskspace on which to hold infinite backups, nor infinite time to solicit individual input on what to delete. Jon Shapiro
rms@PREP.AI.MIT.EDU (Richard M. Stallman) (01/06/87)
The default behavior of GNU Emacs is to make one backup. Numbered backups are an option. I apologize to anyone who felt blasted by my first message on this subject. I did not believe I was blasting anyone. Marketing doesn't impress me, so I prefer to devote my charitable work to software development instead. Those who think that GNU Emacs is no good because of a lack of marketing may wish to volunteer their services in marketing it. Let's talk.
bob@eddie.mit.edu@lmi-angel.UUCP (Bob Chassell) (01/06/87)
I propose changing the default behavior of backups to make *one* backup. .... In short, we need two backup flavors. This is the current default behavior on the current 17.64 release and is described in the manual, which says "At your option, Emacs can keep either a single backup file or a series of numbered backup files.... If you chose to have a single backup file (this is the default)...." ... rms has as usual gone off half-cocked... In this circumstance I do not see how he could do better. Numbered backups were invented because people complained that a single backup is not enough; because at absorbs diskspace, numbered backups are an option that is not the default. I use numbered backups on the files that need them and single backups on the rest. It works well. Also, someone mentioned recently that they were collecting autosave files and weren't keen on them. First, let me say that autosave files are a wonderful invention. I have worked on systems without such a feature and lost work. Autosave files pay for themselves many times over. If you don't want the autosave files to clutter up your directory, set the variable delete-auto-save-files to t. When this is done, Emacs will delete the autosave file when you save the file yourself. This will keep your directories clean.
primer_b@husc4.harvard.edu (jeremy primer) (01/06/87)
In article <8701061644.AA01017@ucbvax.Berkeley.EDU> shap@ucbvax.berkeley.edu@sfdww.UUCP writes some reasonable stuff, but concludes with this diatribe: >By and large, the superusers aren't out to get people, but they have >a real problem, and rms has as usual gone off half-cocked blasting them to >hell for incompetence. Richard, I get sick of that and so does >everyone else, and it doesn't help your product any. When will you learn >that a product doesn't stand on merit - it stands on marketing first, then >merit? Not everyone has infinite diskspace on which to hold infinite >backups, nor infinite time to solicit individual input on what to delete. > >Jon Shapiro The "product" is so good by now that it doesn't hurt much either. If there is no room on a machine for multiple backups, you can always change site-init.el to change the way inexperienced users use GNU Emacs. Dealing with experienced users will, of course, be more difficult :-). rms clearly UNlearned the addage about "marketing first" a long time ago, if he ever had learned it. He's not marketing any of GNU. It's common sense that when a system manager deletes users' files, a conflict or problem is likely to arise. I'm glad rms pointed out that the cron files to do automatic deletion (which have appeared here this week) may be seen as an abuse of superuser privileges at some sites. -------------------------------------------------------------------------- Jeremy Primer primer@husc4.harvard.EDU Department of Mathematics primer%husc4@harvard.ARPA 1 Oxford Street primer@harvsc4.BITNET Cambridge, MA 02138 ...!harvard!husc4!primer
pinkas@mipos3.UUCP (Israel Pinkas) (01/07/87)
This message is directed to those that have been complaining about the behavior of backup files in GNU Emacs. In article <8701061806.AA05139@EDDIE.MIT.EDU> rms@PREP.AI.MIT.EDU (Richard M. Stallman) writes: >The default behavior of GNU Emacs is to make one backup. Numbered >backups are an option. I have been using GNU Emacs on a GPX with only 100Mb disk storage that is shared by about 20 people on a LARGE project. I use the default option, one backup, and have no trouble with that. I have a shell script that removes backup files, and I run this periodically. If it were up to me, I would install the script to remove any backup files that were over 5 days old, as they are guaranteed to be on the backup tapes by then. I realize that retrieving from backup is a pain, but with a project that uses up over half the available disk space, there is not much room for non-essential files. Besides, we have our main developement on a 780 with RCS control. (No flames, please, we don't have NFS and we need the GPX's for development.) >Marketing doesn't impress me, so I prefer to devote my charitable work >to software development instead. Good for you. > Those who think that GNU Emacs is no >good because of a lack of marketing may wish to volunteer their services >in marketing it. Let's talk. If you don;t like the way that Mr. Stallman supplies GNU Emacs, you are welcome to customize it to any degree you wish. He even gives you the sources. Find one other software developer that is willing to do what the Free Software Foundation does. And if you can't stand it, and don't want to fix it yourself, go to someone else and PAY BIG BUCKS for it. Mr. Stallman doesn't owe you anything, he gave you a present. (Don't bite the hand that feeds you and all that stuff.) It's people like you that discourage others from creative developement. Just remeber, Mr. Stallman does have a copyright on GNU Emacs, and it would be within his rights to charge licensing fees in the future. In addition, the manual and the software explicitly state that there is no warantees, nore is the software guaranteed to be usable for specific applications. -Israel -- ---------------------------------------------------------------------- UUCP: {amdcad,decwrl,hplabs,oliveb,pur-ee,qantel}!intelca!mipos3!pinkas ARPA: pinkas%mipos3.intel.com@relay.cs.net CSNET: pinkas%mipos3.intel.com
king@kestrel.ARPA (Dick King) (01/12/87)
Posting-Front-End: GNU Emacs 18.32.5 of Fri Dec 26 1986 on kestrel (berkeley-unix)
In article <357@mipos3.UUCP> pinkas@mipos3.UUCP (Israel Pinkas) writes:
Path: kestrel!labrea!decwrl!sun!oliveb!intelca!mipos3!pinkas
From: pinkas@mipos3.UUCP (Israel Pinkas)
Newsgroups: comp.emacs
Date: 7 Jan 87 16:49:05 GMT
References: <8701061806.AA05139@EDDIE.MIT.EDU>
Reply-To: pinkas@mipos3.UUCP (Israel Pinkas)
Organization: Intel, Santa Clara, CA
Lines: 48
Posted: Wed Jan 7 08:49:05 1987
This message is directed to those that have been complaining about the
behavior of backup files in GNU Emacs.
. . .
Just remeber, Mr. Stallman
does have a copyright on GNU Emacs, and it would be within his rights to
charge licensing fees in the future.
. . .
Neither is true.
The Free Software Foundation, not Stallman, owns the copyrights.
I wrote various improvements to emacs, including the numbered version
system. [please don't flame me -- I anticipated disk space problems
and made it optional, by file, in two ways]. Free Software Foundation
and I have contracts in which FSF promises never to charge a royalty
for any of my various enhancements. Presumably other contributers
have similar contracts, to an extent that only if Mr. Stallman were to
rewrite EMACS or retreat to some horrible early version could he start
charging fees. All contributers would have to allow FSF [NOT rms] to
charge a fee before FSF could do so.
Also note that I have my copy, as do hundreds if not thousands of
other sites, and if FSF started to charge a fee I and the others
could, and many probably would, continue to redistribute without a
fee.
RMS could tire of the project tomorrow. If that happens I suspect
bugs will continue to get fixed [I would fix some] although finding an
"official" home for the "standard" sources would be a bit of a
problem.
-Israel
--
----------------------------------------------------------------------
UUCP: {amdcad,decwrl,hplabs,oliveb,pur-ee,qantel}!intelca!mipos3!pinkas
ARPA: pinkas%mipos3.intel.com@relay.cs.net
CSNET: pinkas%mipos3.intel.com
-dick