On Fri, Jul 15, 2016 at 10:44 AM, Swift Griggs <swiftgri...@gmail.com> wrote: > 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.
Indeed. As you've seen, I use both. No need to be all "Commodore vs Atari" about it. ;-) >> 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? I mean vs ethernet-type networking. The physical layer stuff has fewer variants to worry about with Ethernet vs serial (3mbps vs 10mbps vs 100mbps, and 10Base5 vs 10Base2 vs 10BaseT vs flavors of fiber as opposed to all the parameters one has to match up to get any two machines talking over a serial link). Where this matters is that all our modern gear was developed in an environment where nearly everything being transported across it is TCP/IP. Try pushing DDCMP over the wire. ISTR there's now some TCP wrappers to get gear to be willing to handle these packets, but that just adds to the complexity and frustration. With serial DDCMP, we just hooked up two sync serial ports up with a modem eliminator (which provides the baud-rate clocking for both hosts) and it "just works" (since there are few options to configure at that point). All the configuration is a layer or two up as you set up the logical nodes in your network. Entirely unlike TCP/IP and Unix networking in terms of workflow and type/quantity. This is not a "A is better than B" argument - it's just some descriptions of the elements of the process and how they are different. >> 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. Sure. Absolutely no argument. Just pointing out that comparing DCL to shell isn't exactly apples-to-apples either. If anything, measured in arbitrary units, DCL is a half-step over shell scripting and a half-step below Perl (etc.) scripting. > However, you don't have as many opportunities to write line-noise > in DCL (joke!). :-) Have you ever seen a string of ''' used to dereference DCL args? Definitely the hardest thing about getting a working complex DCL script. >> 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'. I don't mean file permissions, I mean system privileges. Some UNIX filesystems have ACLs (VMS has _very_ well developed ACLs, but that's not what I mean). I mean "I am root" or "I am not root" in UNIX land becomes, "what system object/resource do you wish to access? Read or write? Do you have one of the following privileges: NETMBX, TMPMBX, GROUP, GRPPRV, ACNT, ALLSPOOL, BUGCHK, EXQUOTA, GRPNAM, PRMCEB, PRMGBL, PRMMBX, SHMEM,ALTPRI, AUDIT, OPER, PSWAPM, SECURITY, SYSLCK, WORLD,DIAGNOSE, IMPORT, MOUNT, SYSGBL, VOLPRO, READALL,BYPASS, CMEXEC, CMKRNL, DETACH, DOWNGRADE, LOG_IO, PFNMAP, PHY_IO, READALL, SETPRV, SHARE, SYSNAM, SYSPRV, UPGRADE? Want to mount a disk? In Unix, a user is told "must be root". In VMS, you need MOUNT. You can give someone MOUNT and none of the other privs, meaning this user can mount disks or tapes but not necessarily read physical memory or bypass file permissions or write to device registers or any of the other privileged tasks. It's not all-or-nothing; you grant the level of access required and no more. (http://www.mi.infn.it/~calcolo/OpenVMS/ssb71/6015/6017p014.htm#vms_privileges_tab) >> 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. Yes. That was one I just dodged. If stuff I was porting did a fork(), I just found something else to port instead. The workarounds, as you point out, are non-trivial and don't map 1:1 to what fork() does. -ethan
