QAA@PSUVM.BITNET (03/19/88)
Once again the traditional battle of which is better - Unix or VMS has
surfaced on the net. Usually I just read these discussions and chuckle
because overall they are pretty entertaining. However, this time I figured
I'd add my two cents into the discussion.
Rather than approach specific things which make one system better than or
worse than the other, I pose one simple question - What is the definition
of "compatability" that's used in reference to UNIX?
Surely you don't expect a VAX-UNIX program to run on a different UNIX box
without recompiling it, then where's the compatability between UNIX systems?
Of course, that's an over simplification of the problem, but I think it
makes a reasonable point. Sure, porting software from one UNIX system to
another may be easier than porting from machines with different operating
systems, the fact remains, some conversion would most probably need to be
performed.
As for a direct comparison of UNIX versus VMS, well UNIX is fine for those
CS types who have the time to learn the system, but consider the average
department who uses a machine in an "application/education" based environment.
I would hate to try to teach first time users say in Architecture how to
use UNIX. Yet, I see these students who've never touched a keyboard before
become quite productive working with VMS in a very short period of time.
** flame on **
To all UNIX lovers - give me ONE good reason why "rm" is better than "delete"
to delete a file. And of course, there's the "wonderful" "help" on UNIX
systems - I won't even begin to touch that one...:)
** flame off **
The other discussion about MIPS of these 'fantastic' and inexpensive
workstations, as compared to the bumbling old VAX minis seems rather
narrow minded. Sure, I wouldn't argue the fact that there are a lot
of high powered workstations out there that in raw compute power will
run circles around your average VAX, but has anyone ever considered
adding in I/O and other factors into those ratings? Let's take the
VAX 8800 as compared to an equivalent 6-12 MIPS workstation. Can you
see 300-400 people logged onto the workstation - ALL at the same time?
My point is simple - when you consider the 'power' of a machine - don't
forget to factor in things such as throughput - unless you're going to
dedicate the machine to ONE person. MIPS as a rating is very mis-leading
in this sense, all it measures is pure compute cycles, not the overall
throughput of a given machine.
Well, enough for now - I welcome opposing opinions!
-Tim Bieling, system coordinator
Architecture Computer Lab
Penn State University
Email: BIELING@PSUARCH.BITNET (a VAX/VMS site :)
"The opinions expressed here are .... [the usual disclaimer]"dhesi@bsu-cs.UUCP (Rahul Dhesi) (03/20/88)
In article <36568QAA@PSUVM> QAA@PSUVM.BITNET writes: >To all UNIX lovers - give me ONE good reason why "rm" is better than "delete" >to delete a file. The VMS "delete" command has some serious flaws. It can't recursively delete a directory subtree. It will also blindly delete a file even if it has multiple directory entries for it, thus invalidating them with no warning to the user. (This is really a VMS file system problem.) Also, "delete" simply aborts with an error if the file that the user wanted to delete is write-protected, instead of allowing the user to override the protection as the UNIX "rm" command does. While VMS does have some interesting and useful features, its "delete" command is surely not one of its strong points. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
hydrovax@nmtsun.nmt.edu (M. Warner Losh) (03/21/88)
In article <2413@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >In article <36568QAA@PSUVM> QAA@PSUVM.BITNET writes: >>To all UNIX lovers - give me ONE good reason why "rm" is better than "delete" >>to delete a file. > >The VMS "delete" command has some serious flaws. It can't recursively >delete a directory subtree. It will also blindly delete a file even if >it has multiple directory entries for it, thus invalidating them with >no warning to the user. (This is really a VMS file system problem.) How many times does this happen. VMS does not really support file that have more than one link. Are you saying that if I print a file then delete it, before it has a change to clear the queue, I end up with garbage on the disk? I don't think so. >Also, "delete" simply aborts with an error if the file that the user >wanted to delete is write-protected, instead of allowing the user to ^^^^^^^^^^^^^^^ This is wrong. I just delete a file that had delete permission, but no write permission. >override the protection as the UNIX "rm" command does. The VMS delete command WILL allow a user to delete the file if the file has DELETE protection for the file. If you don't have delete permission, then you can't delete the file at all. Period. That's the way VMS works. It is for security reasons. -- bitnet: losh@nmt.csnet M. Warner Losh warner@hydrovax.nmt.csnet ! Don't know if this works, let me know. csnet: warner@hydrovax.nmt.edu uucp: ...{cmcl2, ihnp4}!lanl!unmvax!nmtsun!warner%hydrovax
dboyes@uoregon.UUCP (David Boyes) (03/22/88)
In article <36568QAA@PSUVM> QAA@PSUVM.BITNET writes: >Rather than approach specific things which make one system better than or >worse than the other, I pose one simple question - What is the definition >of "compatability" that's used in reference to UNIX? Compatibility: The same source program will compile *without modification* on any machine running the same version of Unix (or a version of Unix that provides compatible library routines). >Surely you don't expect a VAX-UNIX program to run on a different UNIX box >without recompiling it, then where's the compatability between UNIX systems? Why not? I use the same sources on a Sys Vr3 system and a 4.3bsd system. Same program runs fine on my beloved IBM 4341. VMS is the only system I've had to change my ray tracing program for. >another may be easier than porting from machines with different operating >systems, the fact remains, some conversion would most probably need to be >performed. Not exactly true. A program that uses the standard library routines and uses curses for full screen i/o will work without modification on 99.978% of Unix systems. Programs that take advantage of features like Sys V shared memory or semaphores or V-system task groups will naturally need rewriting. >** flame on ** >To all UNIX lovers - give me ONE good reason why "rm" is better than "delete" >to delete a file. And of course, there's the "wonderful" "help" on UNIX >systems - I won't even begin to touch that one...:) >** flame off ** Explain it as 'rm' *removes* a file from the disk. Inexperienced users here haven't had too much trouble with that. Quite frankly, VMS help is not all that impressive. Any help system that won't look at help files in my OWN directory first is a bit silly -- how am I supposed to know if it's going to look right without seeing how it's going to look from the HELP environment? Come on, guys -- even IBM figured this one out. Library files - bah. >narrow minded. Sure, I wouldn't argue the fact that there are a lot >of high powered workstations out there that in raw compute power will >run circles around your average VAX, but has anyone ever considered >adding in I/O and other factors into those ratings? Let's take the >VAX 8800 as compared to an equivalent 6-12 MIPS workstation. Can you >see 300-400 people logged onto the workstation - ALL at the same time? You're missing the point. The whole idea of workstation computing is to AVOID 400 people sharing the same CPU. In a distributed environment, it doesn't make a bit of difference whether I'm running my 1024x1024 raytracing jobs or a 1Mx1M image enhancement job while you're editing away on your latest opus. You have your CPU to use in any way you want and I have my CPU to use in any way I see fit. Let the big machines do things like handle disk service or sharing expensive high-speed peripherals like high-volume laser printers, etc. With inexpensive high-speed network media, it is now really more cost effective to get a load of workstations and network the heck out of them using something like NFS. Most of the real use (MY OPINION!!) of large machines is to access large volumes of shared data -- a task easily done using NFS and workstations. If I choose to do ray tracing of an image based on how many people in Illnois voted for Bozo the Clown, J. Random Luser shouldn't have to care. My work should have no impact on his session -- and it doesn't, in a workstation environment. >My point is simple - when you consider the 'power' of a machine - don't >forget to factor in things such as throughput - unless you're going to >dedicate the machine to ONE person. Why not? With Suns/Apollos/Masscomps/Convexes/etc. being far cheaper than their approximate DEC equivalents, why should I have to share? Why shouldn't I throw a job on the machine that will sit and munge for a week? I can't do that with a large DEC box. >-Tim Bieling, system coordinator >Email: BIELING@PSUARCH.BITNET -- David Boyes | ARPA: 556%OREGON1.BITNET@CUNYVM.CUNY.EDU Systems Division | BITNET: 556@OREGON1 UO Computing Center | UUCP: dboyes@uoregon.UUCP 'How long d'ya think it'll be before just us oldtimers remember WISCVM?'
nevin1@ihlpf.ATT.COM (00704a-Liber) (03/23/88)
In article <2413@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >In article <36568QAA@PSUVM> QAA@PSUVM.BITNET writes: >>To all UNIX lovers - give me ONE good reason why "rm" is better than "delete" >>to delete a file. > >The VMS "delete" command has some serious flaws. It can't recursively >delete a directory subtree. Are you sure about this?? It's been a long time for me (slightly over a year since I last did any serious VMS work), but I thought that $ DEL [...]*.*;* (or something close to that) would do it. Now, if you rename one of the subdirectories so that it doesn't have the .DIR extension, that's a different story ... >It will also blindly delete a file even if >it has multiple directory entries for it, thus invalidating them with >no warning to the user. (This is really a VMS file system problem.) There is also the converse: UNLINKing a file with only one link instead of DELeting it left the space allocated but no way to reallocate it short of reloading the system. In general: LINK in VMS is a very poor kludge of the equivalent in UNIX. >Also, "delete" simply aborts with an error if the file that the user >wanted to delete is write-protected, instead of allowing the user to >override the protection as the UNIX "rm" command does. I think that this is because any user (not necessarily the owner) can delete a file if he has the correct privileges or he is on the access list or the permissions on the file allow him to delete it. You can get burned by this feature of 'rm', though. If you are doing a 'rm -i *' and you are not really paying attention, you'll probably rm a few files you really didn't want to get rid of. Of course, I'm also the guy who, just after finishing up a class assignment written in Modula-2 (under VMS), did a $ DEL/CONFIRM *.MOD;* instead of $ DEL/CONFIRM *.OBJ;* without paying attention, and managed to DELETE all my source!! So much for confirmation messages!! (I guess I can put a smiley here--I still managed to get an 'A' in the course :-)) >While VMS does have some interesting and useful features, its "delete" >command is surely not one of its strong points. If we have to debate on the DELETE vs rm issue, it's time that this discussion ended!! :-) :-) -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) "The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill." / (_</_\/ <__/ / <_ These are solely MY opinions, not AT&T's, blah blah blah
QAA@PSUVM.BITNET (03/24/88)
Well, I think I made my point - there really is no 'correct' answer to the whole OS argument. I could pick at all sorts of things on both Unix and VMS, but it'd be pointless. Each site has special needs, and requirements - and as such, each OS deserves consideration. As for ending these OS wars - you have my vote. I get real sick of seeing unfair comparisons made, and justifications for one or the other on information which isn't entirely accurate. After reading through all of the current postings, as well as ones from the previous 'war', I haven't learned anything new, nor have any of the postings ever convinced me that either OS is 'better'. (what ever 'better' is) Well, off to better discussions... -Tim Bieling Programmer/coordinator - Architecture Computer Lab Penn State University Standard disclaimer: "These opinions ...."
carl@CITHEX.CALTECH.EDU (Carl J Lydick) (03/28/88)
> >The VMS "delete" command has some serious flaws. It can't recursively > >delete a directory subtree. It will also blindly delete a file even if > >it has multiple directory entries for it, thus invalidating them with > >no warning to the user. (This is really a VMS file system problem.) > How many times does this happen. VMS does not really support file that have > more than one link. Are you saying that if I print a file then delete it, > before it has a change to clear the queue, I end up with garbage on the disk? > I don't think so. Not only does VMS "really support" files that have multiple links, some of their layered products REQUIRE them (for example, if you're running VAX-11 RSX, you'll find that the files SYSEXE.DIR;1, SYSLIB.DIR;1, and SYSHLP.DIR;1 [I think these are the three] in SYS$SYSROOT: all have multiple links). What does your question about printing a file have to do with the question? Nothing, as far as I can see. > >Also, "delete" simply aborts with an error if the file that the user > >wanted to delete is write-protected, instead of allowing the user to > ^^^^^^^^^^^^^^^ This is wrong. I just delete a file > that had delete permission, but no write permission. > >override the protection as the UNIX "rm" command does. > > The VMS delete command WILL allow a user to delete the file if the file > has DELETE protection for the file. If you don't have delete permission, > then you can't delete the file at all. Period. That's the way VMS works. > It is for security reasons. The appropriate comparison is that "rm" lets you override the file protection IF YOU HAVE THE PRIVILEGE TO OVERRIDE IT in the middle of the execution of the command. Under VMS, you can change the protection of the file IF YOU HAVE THE PRIVILEGE TO CHANGE IT, then use DELETE again; however, you can't do this as part of the DELETE command.