Hacker News Reader

> OpenVMS's command line interface is designed around a mistake-prone operator who hasn't had their coffee. It doesn't have, say, the 'rm -rf /' problem. Unix's CLI assumes a perfect operator who gets everything right the first time.

Funny you should say that. On a VMS build server, I was once cleaning up a build and ran a "DEL [...]* .OBJ;*" (HN auto-formatting doesn't allow me to display this properly without inserting a space after the first asterisk). I started to wonder why it was taking a very long time to complete when it hit me... I had run it from the root-level of DKA0:, not from the build directory. Needless to say, the entire OS had to be restored/rebuilt.

This is easily the biggest mistake I have made in my 20-year career as a sysadmin (or system manager as we call it in the VMS world). Don't get me wrong, I love VMS for many of the reasons you've stated, and more; I wish it was more widely used in the industry. But don't be fooled; you don't need to be on a Unix system to make mistakes of disastrous consequences. They can happen anywhere!

Actually, M. Cutler's contempt for Unix design philosophy is not well documented. It's an unsupported edit to Wikipedia, and lots of recycling of that.

The subject came up on StackExchange recently, with someone asking for the meaning of the Wikipedia claim. No-one could find it actually documented. There's documentation of an incident where M. Cutler showed contempt for people who were connected to DEC Ultrix, calling them "sorry excuses for engineers". However the source for that is an anecdote, related in a book years later, told by one of the very people so addressed, who might have had an incentive to thumb xyr nose at M. Cutler.

The book "Show-stopper!: The Breakneck Race to Create Windows NT and the Next Generation at Microsoft" (1994, G. Pascal Zachary) quotes: "Unix is like Cutler's lifelong foe," said one team member who'd worked with Cutler for nearly two decades. "It's like his Moriarty. He thinks Unix is a junk operating program designed by a committee of Ph.D.s. There's never been one mind behind the whole thing, and it shows. So he's always been out to get Unix."

(Why "M."?)

Now contrast with https://en.wikipedia.org/wiki/Special:Diff/320402189 , the widely recycled Wikipedia edit and the claim that had to be explained; which that does not even support, let alone explain.

The Armando Stettner named in https://en.wikipedia.org/wiki/Special:Diff/320396668 and other edits by the same person is the person who told the "sorry excuses for engineers" anecdote about xyrself, recorded in A Quarter Century of UNIX by Peter H. Salus.

The irony is that there is better, more specific, documentation of M. Cutler's opinion of OS/2 (specifically its mutex mechanism) than there is of M. Cutler's opinion of Unix.

> G. Pascal Zachary

I don't consider him a reliable source; he had a reputation for scandal mongering and misrepresentation.

I'd point out that at least one reference to Cutler and Unix in the book purports to be a direct quote from one of the team. If you're going to argue that he just made that quote up, I guess I can't argue with you of course.

> at least one reference to Cutler and Unix in the book purports to be a direct quote from one of the team

It could still be taken out of context, which was a common tactic of Zachary's when he wanted to misrepresent something. Or the team member the quote purports to be from could have been misunderstanding or misrepresenting or exaggerating Cutler's actual views, and Zachary could have picked that particular team member to quote from because it fit the narrative he was trying to construct, and ignored other team members who were saying different things.

For an example of Zachary's methods from the viewpoint of someone he interviewed and then misrepresented, see here:

https://www.fourmilab.ch/autofile/www/chapter2_99.html

M. is a common abbreviation for "monsieur". Perhaps the GP speaks French?

> He thinks Unix is a junk operating program designed by a committee of Ph.D.s.

Posix is the junk operating system designed by committee, but given their advertising, I'm not surprised he would confuse the two.

Posix doesn't exist on its own in isolation.

OpenVMS absolutely does crash. I was actively involved with a very large cluster - and with enough abuse - individual nodes will tip over - and if you aren't careful - you can take down an entire cluster.

It was an interesting OS. Some different ideas in there. But the idea that it never crashes is simply false.

Anecdotally, VMS had a command to exclusively allocate resources which I learned on a predecessor OS RSTS/E. Predecessor in the sense that some command syntax carried over; I have no clue how much RSTS/E source if any made its way into VMS. Regardless, the idea was you would ALLOC the line printer or tape drive to prevent anyone else from stepping on you.

At Digital's NCC booth in 1981 or 1982 (I forget) they were showing off clustered VAXes with the nodes named after colors. I jokingly typed ALLOC RED:: and discovered that allocating an entire node to yourself crashed the cluster.

I cracked "root" on ours as an undergrad, so going to claim that the security wasn't all that, at least lacking a perfect operator. (And didn't they distribute it with vendor backdoors for a long time?)

Beyond that, AFAIK it didn't have pipes, which was a real limitation for creating, well, pipelines to stream process data far larger than available RAM.

I miss the days, but not the OS.

Somewhere I have a printout (green ruled 132-column line printer of course) of the SYS$SYSTEM:SYSUAF.DAT file showing my account with all 32 privilege bits set (including of course: "change mode to kernel"). This after spending the weekend writing a perfect VT-100 "trojan" that I left running on an operator terminal with some social engineering, grabbing the system user password which I then used to escalate my account's privileges.

Coincidentally, a few minutes later, the 780 threw a fatal memory error and shut down. My 17 year old self assumed he had broken the VAX, returning to work (I was an intern) on Monday morning expecting to be fired.

Writing the trojan, which had to correctly implement all the terminal timeouts, responses to ctl-y and so on, was quite a challenge. Required me to understand $QIO, by reading the microfiche copy of the terminal handler BLISS-32 source code.

Pipes wasn't a thing until v7.something or other. A bunch of lexical functions weren't implemented until then too.

Pipes very much existed before v7. At a bare minimum they're in v6 as I remember them from Lyon's, but I think they were as far back as v3.

Yeah, sure...from § 11.13.2 of TFM[1]:

> In OpenVMS Version 7.1, the DCL PIPE command was introduced.

Ask me how I really know OpenVMS v6 doesn't have pipes.

[1] http://h30266.www3.hpe.com/odl/axpos/opsys/vmsos84/6489/6489...

I thought you were talking about Unix, hence my Lyon's comment.

I thought the GP's context made that clear, but fair enough.

I remember when I developed Java for OpenVMS. On Unix you send a kill signal to get a thread dump from the Java process. On OpenVMS you sent a mail to the process! Something like a mail, it was not a SMTP mail but mail-like.

Mailbox?

http://h30266.www3.hpe.com/odl/axpos/opsys/vmsos84/BA554_900...

This is the main VMS interprocess communication mechanism.

> Under Linux, all I/O is synchronous but possibly nonblocking, and all disk I/O is blocking

This is no longer true with io_uring.

It wasn't entirely true even before io_uring. The previous Linux AIO API has too many caveats and pitfalls, but there were narrow use cases where it could do genuine non-blocking asynchronous disk IO.

Yup - assuming you had filesystem support anyway. Seastar has a useful tool named “fsqual” for determining whether a given filesystem is capable of using kernel async IO in a non-blocking fashion.

FWIW, linux got pretty decent true async IO with io_uring, at last.

Cluster-wide batch queues built-in, a cluster-wide file system, etc.

Samba support is awful, though.

Yes and TCP/IP support in general on VMS was not great. Performance was a consistent problem. It was clearly a second class citizen for a very long time.

Part of my day job is maintaining our home-grown data processing system on an old VMS (Itanium) cluster. We've been trying to get rid of it for close to 7 years now but don't seem much closer than when we started.

For things that OpenVMS is good at, it is REALLY good at. Everything else... is pretty antiquated.

Did VMS TCP/IP support suffer due to poor effort from Digital, or as an inherent side-effect of the kernel design?

Could poor TCP/IP performance have been a consequence of 'real asynchronous I/O support'?

Berkeley sockets is obnoxious [Example]. But the advanced user can get fine control over it. If you have a use-case that is vulnerable to back-pressure, with Berkeley sockets you can manage that away. Some friendlier API designs would have worse options.

Berkeley sockets is ubiquitous, and there is not much to compare it to. Insights from VMS would be interesting.

--

:Example. A selector indicates that a socket is ready for read/write. But what that actually means is contextual, depending on whether it was created as a client or server socket. You can't attach metadata to the socket to assist with that. Rather, you have to maintain parallel structures.

IMO, one of the significant scaling bottlenecks for VMS was there were only a handful of spinlocks that governed kernel activity. The one that I remember was IOLOCK8 (sp?). Any ethernet frame handling would have to hold that for a period of time. The underlying code that those stacks use to manage their inbound ethernet frames is likely quite old and would require significant work to reduce contention around that lock.

To put it differently, a modern 10 gig ethernet card likely generates too much traffic to be effectively handled by that code. And if you had more than one 10 gig card in a box, they would contend around that common spin lock.

I'll add in that you could run a fairly simple program on Linux that simply blasted out very small UDP packets and point it at a VMS node - any port is fine - you'll drive up the interrupt mode on that box. You won't need much traffic. Smaller packets are better because you want to punch it with lots of packets. It won't be much actual bandwidth. VMS performance here is kind of sad.

As a bonus feature, if your VMS TCP/IP stack is configured to send ICMP replies when there is nothing there at the given port, you'll create even more grief because now the stack is busy trying to receive the blast you give it and send out replies too.

Thanks for these notes. It's neat that you have a hypothesis for the source of the problem that goes down to the types of locks.

Are you talking about a lock held for regular interrupt-driven packet delivery, or a lock held even when an Ethernet card wants to DMA into a kernel ring buffer?

I don't think DMA is an option in VMS land. Just a lock held for regular interrupt driven packet delivery. Been a while since I've dealt with it.

This provides an in-depth description of the VCI API which is used to write your own ethernet frame handler. Some descriptions of when IOLOCK8 is held.

https://rtk.mirrors.pdp-11.ru/_vax/openvms.org.ru/vci1.html#...

> "Fat fingering" a command could have disastrous consequences; in most cases on VMS, the command interpreter will raise a syntax error. OpenVMS also has file versioning built into the file system

For all this talk of fat fingering, you failed to mention that a simple purge is all it takes for all that file versioning to disappear...and you don't even have to type out the whole 5 letters. Besides, file versioning != revision control, and there are modern interoperability nuisances with it too.

Perhaps the most annoying thing with VMS is it'll allow you to set default (equivalent to cd for those unfamiliar with VMS CLI) to a directory that doesn't exist without even a courtesy warning. It was so batshit annoying that I wrote my own implementation of cd in DCL to ensure that never happened, along with updating command prompt to reflect current directory (just like Windows cmd) and certain bashisms like ~ for home directory, etc.

> Oh, and OpenVMS doesn't crash. Like, ever.

Yeah, sure...not really.

The VMS directory structure is bizarre when you first see it. dev:[dir1.dir2.dir3]file.ext;rev for a full path... Don't forget about [000000] for the root directory.

None of those things are helpful when it's a restrictive commercial endeavor. There are many things that are technically very fancy but simply unreachable by most people due to administrative restrictions. Those restrictions are a far bigger barrier to usage and success than the technical capabilities, especially in a dynamic, fast-moving and interconnected world.

I suppose that is also why this was posted here on HN: being tied to the grace of some commercial entity isn't exactly pleasurable.

But there are high end applications where companies are willing to take that hit. OpenVMS is used in some nuclear power plants. When you have data coming in from tens or hundreds of thousands of sensors, and processing that data is vital to keep things from exploding, you want something that can process it all in real time and never crash.

BASF's STOP is another example of a very specific purpose operating system geared entirely around security.

I can't find any info on BASF's STOP; can you link me to something relevant? It's up my alley personally, would love to learn more.

There's not much info out there publicly. Here's what I found:

https://www.baesystems.com/en/product/stop-os

https://en.wikipedia.org/wiki/XTS-400

Yes, but that doesn't have much to do with hobbyist or student licensing, does it. If you are an energy company you probably have some sub-sub-sub budget line somewhere for 'computer license' stuff.

Are you familiar with the instrumentation on nuclear plants? I can’t imagine there are high tens of thousands or hundreds of thousands of variables let alone sensors to be monitored. On the hydro plants I work on there are about 1000 variables per turbine generator unit and another 1000 for the substation and river system that are centrally recorded.