In modern times, we have taken the everything breaks all the time, make redundancy and failover cheap/free approach.

VMS(and the hardware it runs on) takes the opposite approach. Keep everything alive forever, even with hardware failures.

So the VMS machines of the day had dual redundant everything, including interconnected memory across machines and SCSI interconnects and everything you could think of was redundant.

VMS clusters could be configured in a hot/hot standby situation, where 2 identical cabinets full of redundant hardware could failover during an instruction and keep going. You can't do that with the modern approach. The documentation was an entire wall of office bookcase almost clear full of books. There was a lot of documentation.

These days, nothing is redundant inside the box level usually, we instead duplicate the boxes and make them cheap sheep, a dime a dozen.

Which approach is better? That's a great question. I'm not aware of any academic exercises on the topic.

All that said, most people don't need decade long uptimes. Even the big clouds don't bother with trying to get to decade long uptimes, as they regularly have outages.

I was actually surprised to see that there's been a release in the last 12 months - I had thought it was dead.

I used it extensively in the late 90's early 00's and really liked it. As a newb sysadmin at the time, the built-in versioning on the fs saved me from more than one self-inflicted fsck up.

I can't imagine there would be any green-field deployments in the last 10 years or so - I'm guessing it's just supporting legacy environments.

It's fun for hobbyists! The first multi-user system I used happened to be a VAX/VMS system, so it brings me back to my youth. I have a VAX running in simh, complete with compilers. The release, VMS 7.3, is almost 25 years old.

There is a pretty good amount of operation-critical stuff like power plants (especially nuclear), radars, traffic management and various finance/insurance/airline services that operate on VMS afaik. Something about very reliable cluster-native operations, or so it would seem. 90's cloud-native.

> Is there any reason to use VMS today other than for existing applications that cannot be migrated?

No, there is no reason to do a greenfield VMS deployment and hasn't been for a long time.

> I've heard its reliability is legendary, but I've never tried it myself.

I've heard the same things but I am doubtful as to their veracity in a modern context. Those claims sound like they come from an era where VMS was still a cutting-edge and competitive product. I'm sure VMS on vaxclusters had impressive reliability in the 1980s, but I doubt it's anything special today. If you look at the companies and institutions that need performance and high reliability today (e.g. Hyperscaler companies or the TOP500) they are all using the same thing: Linux on clusters of x86-64 machines.

I used it a bit at University - most notably it had an Occam system on it that wasn't available on the Sun workstations.

I'm curious about running a VMS system although the admin side looks a bit daunting. The thing I'd really like to do is run X-Windows on an emulator on my home lab, just to see it run.

That is the kind of comment that a well run bulletin board would moderate. Then again, there are probably not enough VMS systems people left to really have an r-war (short of architecture war).

VMS' key feature over Unix is consistency and beyond that it is being interrupt driven at all levels (no wasted cycled polling except for code ported over using POSIX interfaces). VMS was killed by a confluence of business issues, not because it was obsolete or inefficient.

No. Most of the good stuff was lifted into Windows NT decades ago. The rest has been far surpassed over the same time period by Linux and others. A few cool things probably fell into the cracks, but that's common in the industry.

It's interesting in a "what if/parallel universe" kind of way, but I certainly wouldn't touch it for anything new with that licensing.

I had a job at a place in college, back 1997–2000, that was run by a big DEC Alpha server running VMS. VMS was dying then.

I was just a lowly kid programmer working on a side project, so I can't tell you whether it's still uniquely good at something to justify its usage today. It worked. But it was weird and arcane (not that Unix isn't, but Unix won) and using it today for a new project would come with a lot of friction.

At the end of his interview some folks linked to, he points out still being at Microsoft working on a project related to AI looking into using Linux on XBox racks.

His series on YouTube, Dave's Garage, has really helped me to conceptualize Operating Systems in the past that I used, but didn't really fully understand. I started with Atari DOS, but moved to the 286 roughly around the time it started to become popular, along with MS-DOS. I'm 45 now, so didn't think about things as deeply back then, as far as constraints and why things may have been built the way they were. I think his series really does a great job at looking into both technology and company politics (especially his time at Microsoft).

https://youtu.be/xi1Lq79mLeE?feature=shared

He's a high level technical fellow as far as I know but he's also 83. I suspect his involvement these days, if any, is purely advisory to a limited group of core NT kernel and RDOS engineers.

He brought down the empire by committing the ultimate offense: walking across the street and taking the additional money. Hundreds of thousands of people lost their careers, millions more disrupted because of his selfish act. In the 9th Circle will be at least your hero, RMS of GNU and Vint of PPP and Carly of "That Face."

How was the Alpha a bad bet? x86-64 didn't exist yet, and the architecture was pretty solid technologically. It died because DEC died, not the other way around.

> The story as far as I know, goes like this

That is not really accurate or representative at all, no.

> In 2014, a shop called VMS Software Inc (VSI) strikes some kind of deal with HP where they get to develop and support new versions of VMS while older versions continue to belong to HP. As part of this, they finally announce an x86-64 port. This port first sees the light of day in 2020.

And interesting factoid about the x86-64 port is that they've switched to LLVM-based compilers rather than making x86-64 backends for their legacy compilers.

Let me try to recap a fairer version...

> Back in the late 1970s Dave Cutler and his team create VMS at DEC as the next generation operating system for DEC's new flagship product, the VAX minicomputer.

Not exactly.

In the '60s DEC made several of the leading minicomputers. One was a 16-bit box, the PDP-11, a critical machine in the history of Unix as the first new platform it was ported to.

(It was written on an 18-bit DEC mini, the PDP-7. Part of the reason that the PDP-11 got big was that the industry was moving to 8-bit bytes and 16-bit words.)

The VAX was the 32-bit extended version of the PDP-11. It added virtual memory: VAX stands for Virtual Address Extension.

Cutler wrote one of the most successful PDP-11 OSes, RSX-11. He was famously much faster than rival teams, so got the job of writing a 32-bit OS for the new 32-bit machine.

> VMS is good by all accounts and was a successful product, but Unix goes on to dominate the minicomputer and emerging server market for the next decade.

Not really. VMS 1.0 was 1977. Its clustering is still the best-of-breed today, able to present multiple heterogenous machines (VAX, Alpha, Itanium and x86-64) as a single virtual host on the network, with multiple nodes sharing drives, with nodes able to join and leave while the cluster stays up. Uptimes in decades are normal with OS upgrades happening in that time.

DEC enjoyed 10-15yr of dominance in its sector before Unix started to become much of a threat. The first SUN workstation wasn't for 5 years yet. The first SPARC not for another 12yr.

> Then in the 1990s DEC goes out of business

Nope nope nope.

Cutler proposes a plan: a successor to the VAX, a 32-bit RISC chip (PRISM), and a successor to VMS, a multi-personality OS (MICA) to run on it.

DEC says no. It does not believe that microcomputers and Unix are threats, and it spends $ _billions_ on VAX 9000, a series of mainframe-class VAX machines. By the time they eventually ship, the performance is uncompetitive.

Mind you while it's doing this it's selling tons of VAXes including high-end workstations; I bought several and ran clusters of them.

Microsoft headhunts Cutler and his core team with him. It gives him OS/2 3.0 to finish, the portable (CPU-independent) version. They built it on Intel's next-gen RISC chip, i860: the x86 times ten. Codename: N-10. The OS is renamed OS/2 NT for N-Ten.

Note: officially denied now, yes, I am fully aware. Don't believe everything you hear.

Cutler implements his planned MICA multi-personality OS, able to emulate other OSes at kernel level, as NT. Most OS/2 stuff is junked but at launch it can format and use OS/2 HPFS disks and run OS/2 text-mode binaries, and an optional add-on to run Presentation Manager GUI apps is available.

DEC rescues PRISM, upgrades it to 64-bit, and calls it Alpha. Fastest CPU in the industry and the first 64-bit single-chip processor. Runs Unix, VMS, and Windows NT. First non-x86 chip to get Linux ported to it.

DEC also uses this experience to design the first superscalar ARM, called StrongARM.

DEC also gets a very sweet deal on NT for Alpha; the rumour is that DEC has proof that Cutler used MICA code in NT and has MS over a barrel.

DEC remains a major industry force. It also makes networking kit, printers, HDD and tape drives, Ethernet chipsets, PCs -- it's almost a one-stop shop. You can built an entire enterprise network entirely from DEC kit from the screens to the keyboards to the Ethernet switches. I did.

> sells VMS to Compaq, but not before porting it to their doomed Alpha CPU architecture.

Way off. Not even close.

DEC's lost MICA project, now called Windows NT, eats into its revenues. It loses market share to cheap x86 PCs and an OS based on a DEC design.

Compaq buys DEC. It's too big to digest and Compaq gets in trouble.

> Then in 2000s Compaq goes out of business and gets acquired by HP, and together they port VMS to the doomed Itanium CPU architecture.

Not really, no.

Cash-rich HP, which has lots of experience with managing non-x86 lines, acquires one of its biggest competitors in the x86 space, which has zero such experience.

HP buys Compaq. HP has its own RISC chip, its own Unix, its own fault-tolerant systems, all kinds of legacy stuff. It is quite used to killing old product lines. It also has a high-end enterprise email server that is compatible with MS Exchange.

HP makes good money from its partnership with MS, though.

So, HP kills HP OpenMail and sells the IP to Samsung, trades Alpha to Intel in return for killing its RISC chip... it goes all-in on MS and being the premium enterprise MS partner. Anything that rivals anything from Intel or Microsoft, HP kills.

HP works with Intel to make an EPIC chip that it tells customers will replace its PA-RISC.

HP merges the surviving DEC enterprise (non-x86) kit into its enterprise lines.

It announces it's killing VMS.

I wrote this: https://www.theregister.com/2013/06/10/openvms_death_notice/

There is a big customer outcry.

> In 2014, a shop called VMS Software Inc (VSI) strikes some kind of deal with HP where they get to develop and support new versions of VMS while older versions continue to belong to HP. As part of this, they finally announce an x86-64 port. This port first sees the light of day in 2020.

HP spins off VMS to a new company.

https://www.theregister.com/2014/07/31/openvms_spared/

As there is no new Alpha or Itanium kit, the new company's proposition is to help customers nurse VMS on Alpha or Itanium until it has an x86-64 VMS.

It delivers this by 2020.

Remember that there aren't as many drivers in VMS core as in Linux (were just amd DRM driver dwarfs some older kernel versions), and ACPI for all its complexity also handles as portability layer between a lot of differences that in VMS' past involved having to release an entire special release of the system just to get it to boot, now covered by ACPI support.

Also, we don't know how much of that is test code, samples (for testing, for example)

I seems to have read somewhere that there are really only three ACPI implementations: Microsofts, Intels (used in Linux and FreeBSD, among others) and OpenBSDs. So I wonder if VMW might be a fourth, or if they are also using the Intel implementation.

ACPI is a monster. 1,100 page spec: https://uefi.org/sites/default/files/resources/ACPI_Spec_6_5...

There’s a ton of different tables you have to parse and as I recall there’s a whole bytecode you need to be able to execute.

Yes! VAX/VMS became OpenVMS back in the 90's. It runs on VAX, Alpha, Itanium, and x86-64.

>really "user friendly". and then they're wining that nobody contributes to the opensource for VMS.

Yep, one of the first versions of the x86 version one could download everything and it was planed to renew the license once a year. They then canceled the the license after only one year to provide a new image every year (as if i want to reconfigure my system every year).

That's not how you attract dev's or users.

Sounds like a company that has enough high paying legacy clients that they still offer a bit of support, but want that free open source work without improving it to make that work easier to complete.

At some point I was contacted to do a VMS port of Go, for the new x86 port (I have written the Go ports for arm64, sparc64, and for Solaris). In the end it all fizzled out because they couldn't arrange for some sort of license for me such that I would actually be able to run VMS.