mo@LBL-CSAM.ARPA (08/31/84)
THROTTLES TO 104% THRUST! One of the greatest acts of genius in Unix is the understanding that filesystems don't need crap like multiple versions. Having used (extensively) various other operating systems which offer this "feature", I hope I never meet anyone who commits the abominable act of putting such a thing into Unix. Shells which make Unix look like Tenex are bad enough, but are tolerable as curiosities committed by consenting adults in the privacy of their own terminal sessions. To place such a thing in the kernel would surely give you wart on your tongue... This is not a slur on Tenex users; if you like Tenex, please, use it. But Unix is not Tenex, and there are those of us who are glad of it. -Flamin' Mike PS - in my experience, filesytems supporting multiple versions chiefly perform the service of insuring a steady stream of orders for more disk drives.
rcd@opus.UUCP (Dick Dunn) (09/19/84)
>...this is one area where i think UNIX has a weak point. i do not >think that one needs to keep multiple versions after logout, but >should be permitted to do so while logged in. So if you want multiple versions, keep them. If you think lack of file versions is a weak point, you must work for a disk manufacturer! When I worked on a VMS system, I spent more time in an average month deleting extraneous files, fixing up after programs bomb for running out of disk space, and running around trying to find out who was hogging the disk, than I'd spend in a couple of years recovering files under UNIX. If you haven't encountered "versions" the way VMS does them (with a vengeance), consider the standard edit-compile-run cycle while developing or fixing a program. Suppose you're working on abc.c--each edit gets you a new version of abc.c; each compile gets you a new version of abc.o and a.out. An hour or so of fixing and tweaking will easily give you a couple dozen files. >...and if i use the >UNIX standard way of "filename.1", "filename.2", etc., i have a >compatibility problem when i try to downline to tape and then to >VMS, since that system only allows one extension and only 3 let- >ters in the extension, etc. (i know--that is the fault of VMS & >not UNIX, but the problem could be partially solved by allowing >multiple versions... The problem would be better solved by fixing your software that does the move from UNIX to VMS. You might have chosen a different convention for the file versions. (";" and the number is probably a bad choice for UNIX, but you can invent one without too much thought. Then write a simple script to automate it.) -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...Never offend with style when you can offend with substance.
dms@mit-hermes.ARPA (David M. Siegel) (09/21/84)
Multiple file versions is a great feature to have. It does not have to just be an endless sink of disk space. On Twenex systems, for example, a maximum number of generations count is maintained. Endless versions of files only exist if you feel a need for it. The count can be set to one if you wish to be risky. In a typical edit-compile-run session you end up with a large generation number, but only two or three back copies of the program. System daemons can hunt around for people with excess versions and can warn them. It could event delete them if disk space is really tight. Finally, disk space is getting cheaper every day. For 10 grand you can add 500 megabytes to your system. Does anyone know if a unix system that has been hacked to have multiple versions? It would also be nice to have an unremove command... -- David Siegel Usenet: mit-eddie!mit-hermes!dms The MIT AI Laboratory Arpa: dms@mit-hermes.arpa Cambridge, MA 02139
gwyn@BRL-VLD.ARPA (10/02/84)
From: Doug Gwyn (VLD/VMB) <gwyn@BRL-VLD.ARPA> The idea of "UNIX for the masses" was never a good one. A much better concept is "UNIX underlying products for the masses". The standard UNIX interface was designed to support effective software development, not to be accessed directly by non computer professionals. The fact that secretaries et al. can nevertheless use it to do work is an accident, and from the resulting confusion about what UNIX "should" do, a regrettable accident. Talk to one of the UNIX text processing users some day and see just how well their model fits what is really happening; just the other day one of ours told me that she used "/dev/null" to check for eqn usage errors rather than "checkeq". (I finally determined that what she meant was "eqn ... >/dev/null".) The end user (as opposed to system developer) needs the sort of facilities that you have been describing. What we are objecting to is the imposition of these things on developers, who benefit most from the original UNIX design goals. Certainly there were missing functions in older UNIXes, and there are even some missing from the newest versions (there will probably always be more things to use computers for that are anticipated). However, the way to remedy this is to carefully design general, powerful solutions rather than just the first thing that comes to mind. Research 8th Edition UNIX has some improvements along these lines, some of which will appear in publicly-available UNIXes in the near future, but there is yet a ways to go. My main point is that "grafting on" features CANNOT maintain the design integrity; it takes inspired thought comparable to that put into the original UNIX design to obtain the desired elegance. Elegance is NOT just an aesthetic matter, but has real practical benefits (which I have made good use of in past projects).
fouts@ames-nas-gw.arpa (10/02/84)
From: Martin Fouts <fouts@ames-nas-gw.arpa>
I agree with your opening comments about what UNIX was designed for,
but I disagree that system developers don't need the sort of facilities
I have been describing. I am a system developer, and when I have had
some of these facilities I have been more productive then when I
haven't.
>From what I have heard (third hand by deviant paths) 8th Edition Unix
is just trying to solve that same problems that BSD tried to solve,
also by "grafting" missing features onto the system.
I do agree that it takes inspired thought to DESIGN elegant solutions,
but it takes grimey sweat to implement them. Remember that much of the
elegence of the original design came from not having to deal with many
of the truely gritty problems of computing.
----------fouts@ames-nas-gw.arpa (10/02/84)
From: Martin Fouts <fouts@ames-nas-gw.arpa>
I agree in principle that Unix was designed for hack.. (er) system
developers, rather than non professionals, but any application package
is going to reflect the underlying structure.
It doesn't really matter what the original intent was, just as it
no longer matters that all Wirth wanted from Pascal was a teaching
tool. Someone saw some promise beyond the intent, and now Unix is
popping up in a lot of places where it "doesn't belong." I still think
we should try to develope an underlying system which allows development
work to still be done byt leads to good application environments.
After all, the development work we are doing is for that environment.
I appreciate the problem you have with the models people develop, but
"computer scientists" also have problems; I still get asked from time
to time if a particular machine is octal or hexadecimal by people who
should know better. It isn't important that the model exactly reflect
the makeup of the underlying machine, but rather that it can be
accurately used to predict the exterior behavior of the machine.
----------