Hacker News Reader

Comment by dboreham | Hacker News Reader

For me the point at which DEC screwed up was in not embracing Unix+, around 1985. If they had done so, then there wouldn't have been a time when everyone had to buy Sun hardware to run Unix. There would instead have been a choice, and many DEC shops would never have converted to Sun. Commentators saying, as the article does, that it was all about the rise of the PC are wrong. PCs were useless toys at that time. Of course DEC may have done down later just as Sun did, in the X86-64 take over.

+I know: Ultrix, blah blah...but seriously no Ultrix wasn't embracing.

View on HN

It goes back to well before 1985. In fact, Ken Olsen explained DEC's Unix "strategy" very clearly back in 1984:

"One of the questions that comes up all the time is: How enthusiastic is our support for UNIX?

Unix was written on our machines and for our machines many years ago. Today, much of UNIX being done is done on our machines. Ten percent of our VAXs are going for UNIX use. UNIX is a simple language, easy to understand, easy to get started with. It's great for students, great for somewhat casual users, and it's great for interchanging programs between different machines.

And so, because of its popularity in these markets, we support it. We have good UNIX on VAX and good UNIX on PDP-11s.

It is our belief, however, that serious professional users will run out of things they can do with UNIX. They'll want a real system and will end up doing VMS when they get to be serious about programming.

With UNIX, if you're looking for something, you can easily and quickly check that small manual and find out that it's not there. With VMS, no matter what you look for -- it's literally a five-foot shelf of documentation -- if you look long enough it's there. That's the difference -- the beauty of UNIX is it's simple; and the beauty of VMS is that it's all there." -- Ken Olsen, president of DEC, DECWORLD Vol. 8 No. 5, 1984

And I can, in fact, verify that what Olsen said about five-foot shelves of manuals too.

And VMS was (and OpenVMS still is) an impressive operating system, some features of which the Unix/Linux ecosystem is just gaining parity with.

That said, It was commodity microcomputer hardware that doomed DEC, not it's faint hearted support for Unix, IMHO.

We're literally _still_ fighting this battle between VMS and Unix. E.g. WSL2.

He was right... Enter Windows NT.

One of the first multi-user systems I had access to was VMS. I'm still fond of it, and have an Alpha in my collection, running OpenVMS.

And he's right. I remember working at a company that had a wall of VMS documentation. It was amazing.

The living computer museum has a VAX running the original VMS, accessible over the internet. Yeah the museum is closed, but the VAX is running, I've just logged in to verify.

I hope they are able to reopen some day. Still hurts that they had to let everyone go

I worked in a VAX shop early on. We had an intern who was pushing Linux on us. He said to me, "Sure, VMS is great, but the downside is you need a wall of manuals." My reply was, "Downside? That's the UPSIDE! You can get an entire wall of manuals for it!"

I still feel that way.

Wow, what functionality did it have that took all those pages to document? Can you offer any examples of things it could do that Unix couldn't?

What sort of things could/can VMS do that Unix couldn't? (Dec 2016) https://news.ycombinator.com/item?id=13205419

Old VMS programmer here. In addition to the above, the thing I remember is that there was more of everything in VMS, and it was all more complicated.

Unix has files which are just strings of bytes. VMS had those, but also several (or many) other file types with records and indices kind of like a database, and a library of functions for each different file type.

Unix has processes. VMS had processes and jobs -- a job is a group of processes, when you log in you start a job, all the subprocesses you start in that login session belong to that job etc. So there are functions for dealing the jobs as well as processes.

Unix has environment variables. VMS had logical names which could be used in a similar way, but there was a process logical name table, a job logical name table, and a system logical name table, and functions for dealing with all of them.

And on and on in this style. Whether you see this as an advantage or disadvantage depends on whether you have an application that can use some of these features, so you don't have to write them yourself as you might have to in Unix.

In addition to that, as the link above explains, VMS had facilities that early Unixes just didn't have, such as clustering - you could connect several VAXes to a common shared file system and share computational load. Also there was DECNET, a complete networking stack, a parallel universe to TCP/IP (which was not so pervasive in the 1970s and 80s). Each of these contributed a couple of thick binders to that wall of documentation.

The VMS manual set was delivered on a pallet! It was bigger and heavier than most of the later VAX computers.

I'd add to that list:

- At the time Olsen made that statement VMS had shareable libraries (DLLs), and none of the several Unixes I used did. The system administrator had to manually enable sharing of their code pages between processes if you wanted that, but they were there.

- The indexed files mentioned above were called ISAM. There were also utilities to reindex them, and load and save them to flat files with fixed column sizes; since that was the common way data was held in those days, it would be like having automatic conversion to and from JSON, XML and CSV now. At extra cost, there was a SQL-like query language, just different enough from IBM's SQL language not to get sued.

- The compilers were far ahead of Unix's. The FORTRAN77 had a lot of IBM extensions, so scientists could just compile their existing programs. It also had keyword extensions to work with the ISAM files. Later on, a newer and better Pascal came out, as well as an Ada.

- Terminal handling was handled by the kernel, in contrast to Unix where applications went off and read /etc/termcap and the user had to babysit eval tset in their dotfiles. If a command line program was nonresponsive, the input was queued instead of being half-duplex interleaved with program output as Unix still does it.

- The symbolic debugger was far ahead of Unix's adb.

My favorite feature of logical names was that they didn't just point to directories -- they could be a search path!

To test new code, all I had to do was create a directory to hold my changes, and copy in just the files I wanted to update. Set the logical name aliasing the code location to search first in my "branch" directory, then in the main directory. Any code in found the top-level search location takes precedence over the main directory.

Boom! Instant branches, but supported at the OS level.

>Wow, what functionality did it have that took all those pages to document? Can you offer any examples of things it could do that Unix couldn't?

Here's an interesting comparison:

http://www3.sympatico.ca/n.rieck/docs/vms_vs_unix.html

Although it's light on internals.

Much more detail can be had from here:

http://www.hoffmanlabs.org/vmsfaq/vmsfaq_contents.html

If you want to check out OpenVMS for yourself, you can get a "community license" and the code once it's released:

https://vmssoftware.com/about/news/2020-07-28-community-lice...

Jesus Christ, having used VMS and SunOs back in the day... this is some serious delusion. From a user/programmer perspective, in my experience VMS just plain sucked compared to SunOS. Probably, this was down to the shell. The VMS shell just SUCKED.

+1 to that.

My first exposure to non-personal computers was via VMS at the university. It was exciting. But then a few months later I got access to a SunOS lab (and shortly after, AIX and HP-UX labs). Mind blown! Instantly in my mind VMS became just a toy, UNIX is where the hacker ethic lived for real. Thirty years later, still on UNIX (BSDs and Linux now). VMS? Yeah..

The manuals were fantastic but their online help was also excellent if the manual shelf was too far away.

What could VMS do that Unix couldn't?

See my post above.

They had real UNIX System V R2 (at least - R3, maybe?)) deployed by 1990 at the latest. GTE Mobilnet had their usage tracking running on whatever the biggest VAX was at the time. I had to fly to Bothell in August 1990 to diagnose a problem with Informix not playing nicely with DEC's bleeding-edge disk array controllers.

Ultrix was lacking compared to SunOS. It only supported static binaries and needed more disk space as a result. Licensing was weird. Open source stuff didn't always "just work" and compile out of the box like it did on Suns. In the early 90's through the dot-com crash, everyone wanted Suns. Still, DEC did some awesome stuff... The Alpha was amazing.

I worked at a mostly DEC shop for a while. They had a lot of VMS systems, but when it came to Unix, they went with Sun.

Reply on news.ycombinator.com