Hacker News Reader

> but largely (functionally) indistinguishable from a UNIX machine when accessing it via teletype (glass or otherwise).

I disagree. I first sat down at a VMS terminal in a library in North Carolina when the OPAC broke and dropped me back to a prompt. I knew Linux passably well at that point but had never used VMS before.

I typed ls, tried dir, that worked, and finally tried help. In half an hour I was investigating the university's network. It was a remarkably easy system to get oriented on. Conversely, no one can be expected to get anything vaguely comparable when sitting down unattended at a unix shell for twenty minutes.

I just tried 'help' on a linux system.

It is absolute garbage.

That's because 'help' on most Linux-based systems is actually a shell builtin which explains other shell builtin commands. This, in turn, is related to the fact that Linux-based systems are flexible - you could use a totally different shell which does not even have the _help_ builtin - while VMS was a comprehensive single-sourced top-down controlled system. Both have their strengths and weaknesses, the fact that you are nearly certain to be using several Linux instances right at this moment gives some indication of which of these systems eventually turned out to be the strongest, warts and all.

help on VMS wasn't a builtin. It was a system-provided program, with data files that could be accessed via other software.

The same was true on MS-DOS, DR-DOS, and OS/2. Microsoft provided a help file compiler with some of its DOS development tools, and IBM provided an INF/HLP compiler and (if memory serves correctly) a message file compiler with the OS/2 SDK (HELP using both hypertext help files and message files on OS/2).

In a normal sized terminal the most useful part is pushed away by the list of built-in commands. IMO it should be printed last, so that it's guaranteed to be displayer to a user who doesn't know how to scroll up:

    GNU bash, version 5.0.18(1)-release (x86_64-pc-linux-gnu)
    These shell commands are defined internally.  Type `help' to see this list.
    Type `help name' to find out more about the function `name'.
    Use `info bash' to find out more about the shell in general.
    Use `man -k' or `info' to find out more about commands not in this list

One of my first tasks as a systems programmer for the Schlumberger corporation in 1986 was to rewrite the VMS help command for use on SunOS. As it turns out, my rewritten version ran nearly twice as fast as the VMS version on VMS.

That design (a nested heirarchy of help topics/subtopics, with some navigation hacks to make getting around easier) was quite good.

But then came hypertext in the form of the web, and at that point, the "help" command just looks like crap.

If you had tried it on an actual Unix system, your experience would have been rather different. AT&T Unix System 5 Release 3.2 had a standalone help command that provided an interactive menu-driven help system. It looked something like this:

    $ help
    help:   UNIX System On-line Help

        Choices      description 
        s            starter: general information

        l            locate:find a command with keyword

        u            usage: information about command 

        g            glossary: definition of terms 

        r            redirect to a file or a command 
        q            Quit
    Enter choice >

> largely (functionally) indistinguishable from a UNIX machine

Although they were functionally similar, there were some practical considerations...

I will say that path names in unix were a simple and elegant , compared to what VMS used.

I recall VMS paths were something like [foo.bar.bletch]something.txt

At the time this was a little cumbersome, but looking back it is much worse.

Yeah, hence the “functionally”. SYS$[HOMES](something username) was weird as heck, but it worked largely the same way.

That looks similar to the first OS I used, RISC OS, which had paths like

  ADFS::Symbiote.$.SchoolWork.English.Essay

That's Filesystem::DiskLabel.$.Directory.Another.Filename. There were no file extensions, but there was a file type stored as metadata (I think on the directory node?).

Given a current filesystem and a current disk, just the path from the root ($) directory was needed.

"[foo.bar.bletch]something.txt"

Why is that better though - isn't that just sheer familiarity?

NB It looks ugly to me as well but a lot of syntax looks ugly until you become familiar with it (C, PostScript, Lisp, Python all seemed pretty weird looking to me first time I used them and I came to really like all those languages over time).

That's a cosmetic difference.

The real difference is when you try to work out whether your binaries are (supposed to be) in /bin, /usr/local/bin, /sbin, etc, whether settings for a specific application and/or daemon are in $config or $.cfg or $.conf or $.cf or $d_config or .ssh and .bshrc in your personal directory, and where your web server and mail logs are.

Because they might be in /var/log - or equally they might not.

Unix was "designed" by hyperactive comedy racoons with ADHD. There's no reason - beyond lack of attention span and professionalism - why basic features and expectations couldn't have been standardised. But the Unix way is to get something sort of working without paying much attention to what other people are doing, lose interest in it, and move on.

Or to hammer away at something for decades adding more and more obscure edge case config options in a text file, all of which need to be set carefully because otherwise the application fails - probably silently, maybe leaving a log message somewhere completely unexpected - and most of which are irrelevant to 90% of users who just want Something That Works.

> that's a cosmetic difference

yes, mostly.

> Unix was "designed" by hyperactive comedy racoons with ADHD.

I have met the authors of lots of significant parts of unix and I have found them - universally - to be smart, competent and introspective.

I also found it interesting that most (85%) of top athletes were introverts.

Now to compare VMS with unix, you'll find there are some things that are better because capitalism works. Someone was in charge of VMS development, and people were paid to solve specific problems for the operating system or customers. But some things are worse because people were in charge of making trade-offs for current customers vs future direction.

On the other hand, unix also has some points in its favor. A lot of things have appeared that would not survive in a commercial business. Ideas seem to live or die depending on their merits more than by fiat.

The thing is - when people want "something that works" it usually involves tradeoffs that people don't want. You can run an older version of centos/rhel and you will find more 'it just works' at the expense of (relatively) older software. (or you can go look at the source and fix it yourself)

And then there was DECnet ....

It's not a cosmetic difference. Unix has a single-rooted filesystem. VMS did not (like DOS). That doesn't invalidate your complaints about file naming and location, but it isn't a cosmetic difference.

Well for starters, those are different folders because they mean different things. If you’re ever trying to figure out where a binary is located, `which` and `whereis` will do that for you. Also programs will list in their `man` page where config files can be set etc, and sometimes they allow multiple options.

But yes, your inability to search anything up or to understand the basics of Unix constitute a complete design failure.

Similar story here - as a physics student, I used VMS in the first year of uni, mainly for its Fortran compiler (WATFOR) and the NAG libraries, and Unix thereafter. Both had advantages and disadvantages, VMS was touted as more secure (as in, security was a fundamental consideration in its design, whereas it wasn't the case for Unix). I particularly liked the automatic versioning of files, making reversion to earlier known-good files simple.

VMS knowledge came in handy years later when I had to work in VMS Fortran on the company VAX - I even coded the VMS Fortran random number generator in g77 (thanks to the excellent documentation) for consistency when we ported our code to DOS after the VAX was shut down.

My freshman exposure to VMS was for an assembly class. The course also seemed to double as a history of computing. This was back in the early 00’s, for reference.