On Fri, 15 Jul 2016, Ethan Dicks wrote: > It was a huge deal in the late 80s and into the 90s. I was on both > sides, so mostly, I watched.
This thread has definitely been the most civil discussion and set of anecdotes I've seen when folks discuss VMS and Unix in the same thread. I usually don't bring up VMS because I'm not that well versed in it, and when I make one mistake in the nomenclature or some other triviality, someone usually gets butthurt and tries to make a fool out of me or just scream bloody murder. However, folks have been nice this time, for which I breathe a sigh of relief. Of course there is still time for someone to troll... :-) > I've written device drivers, system utilities, and application code for > both. >From your experience and depth on both platforms, it sounds like you have a well rounded perspective. I have merely hours of experience in VMS but years in UNIX. I've never written any device drivers outside of stubs or proof of concept stuff I've done in tutorials. However, I've written a lot of C utilities and app code and most of that was on UNIX platforms, but a little in DOS or on the Amiga. > If I have choice, I'll grab something UNIXy to do my work on - I'm not > particular as to flavor. I'll reach for NetBSD first, FreeBSD second, and then it's just "whatever will work" if those are off the table. For play, I love to work with obscure, obsolete, specialized, or otherwise interesting UNIX variants. > How well do you think it would go if all you had was SLIP and PPP? Do you mean versus some other point-to-point protocol or versus just using serial terminal emulation? If it's versus DECnet, I'd say that it'd go quite well. I've used both SLIP and PPP (and loads of others) to build networks with Unix boxes and/or Cisco routers. When I worked for Cisco I implemented a LOT of PPP links. They work great. They create a nice interface for you to apply ACLs, routing rules, etc.. I have zero problem with either. In fact, there are extensions to PPP such as multi-link and VJ compression that make it rock even harder. Personally, I've had super-wonderful experiences with the protocol. My only doubt is that if it was used on very old equipment it might have been too CPU or memory intensive versus something much more simplistic or efficient. > All serial, all day. We still got a lot done. There isn't anything wrong with serial, as far as I'm concerned. It's got it's place and it did a great job for folks. It still does in many cases. > That said, it was easier (to me) to write full-on apps and utilities in > DCL than sh or csh. Well, I'm a C programmer, as I mentioned, as well as a UNIX zealot and I am pretty allergic to csh. Again, it's just a style issue, but I wish that Bill Joy didn't name it "csh" because it's not something I'm happy to see associated with C coders (folks automatically assume you want csh if you're a c-coder sometimes). I'll definitely take any form of Bourne shell (sh ksh zsh bash) before I resort to csh. Fortunately, most folks seem to agree and csh is pretty niche these days. That's not to say there aren't very enthusiastic users of csh, too. As far as DCL goes, I'll just say this, without 'while' and 'for' I'm sorry, it's a PITA. As a programmer, I find shell scripting to be much more flexible due to more language features and sugar. Sure, you can use 'if'-statements to cobble together a replacement for most situations, but it's clumsy & ugly from what I've seen. > It would be a fairer comparison to develop a complex app in Perl vs DCL > (Perl would win, but it has a lot going for it). Feature wise, I don't see much of a comparison. Perl would trounce DCL in a comparison involving functionality. It's not a fair fight or apples to apples in my mind at all. Plus, Perl isn't a CLI interpreter (though I suppose you could try it that way). DCL is. Hence, I'd compare it to shell script. However, you don't have as many opportunities to write line-noise in DCL (joke!). :-) > The regularity and predictability of args and options is definitely a > strength in DCL. Args are entire words, not letters which change from > app to app. That is the big thing that DCL has going for it, if you ask me. > Next thing - how about those args to 'dd'? Crazy. Now how about > 'tar'... etc., etc. I use this stuff every day, but I have internalized > a massive amount of UNIX trivia to be able to do so. This is always the criticism of UNIX environments versus VMS & DCL. It's valid, I think. I agree with you about the whacky args to 'dd', 'tar', and others (SysV vs BSD 'ps', I could go on and on). > VMS requires far less random factoid knowledge to get stuff done on the > command line. There's a system command line parser, and it helps with > the consistency. I've also been told that the way the help is put together in VMS tends to make the CLI args and switches more consistently well-documented. That's a lesson for some clever UNIX variant to learn, or perhaps it's the "wild west" nature of UNIX that actually attracts some people. It's the whole "less regulation" idea, maybe. I don't know. However, I would like to see some improvements here and there. UNIX isn't perfect. There are plenty of dingy spots. However, to me it's like democracy - it's the best of a bunch of bad systems. > Much stronger. There are dozens of privileges you can grant so someone > can do their job and not overstep things. UNIX says, "all or nothing. > Don't screw up." Well, while I agree VMS is much stronger when we talk about it in the context of the 1990s. However, it's certainly not "all or nothing" even in older UNIX variants. There *are* 'group' and 'other' permissions, not just 'owner'. The problem for that model is when you need an exception. Ie.. someone wants to write to a file that they don't own, aren't in the proper group for, and you can't add them to the group for some reason, PLUS you can't open up the file permissions. That's the the most common situation that serves as an argument for POSIX ACLs. It's the "textbook example". Having said that, let's talk real for just a sec. The current crop of Unix variants often have equal or better authentication/authorization systems. Take a look at SElinux, Cgroups, Capabilities, and POSIX ACLs. Put those all together and you can do everything that VMS can plus a ton more. The modern discussion also mirrors the storage capabilities of VMS. It has has shadow-sets (essentially RAID1) for a long time and they nailed that functionality very early on as well as made the ODS file system aware of it. However, post LVM2, ZFS, BTRFS, DRBD / HAST, and/or compared to modern VxVM & VxFS, VMS is lacking a very long list of valuable and important features that are freely available now in many UNIX variants. > OTOH, I learned a *lot* porting utilities and games from > comp.sources.unix and comp.sources.games to VMS. Some things were a lot > harder than others. I think the biggest stumbling block is the lack of fork() in VMS. They have threads and some hacks like LIB$SPAWN, instead. However, in most cases, I'll take a fork() model over threads any day. Concurrency and marshalling threads has always been a PITA, IMHO. It's not that fork() gets out of it, it just forces a more simple structure/design (again, just my opinion based on experience). -Swift