VSI OpenVMS v9.0-G Released (x86 port)

Does VMS do anything better than Unix today? Anything besides asynchronous is?

I'm incredibly excited about this. I can't wait until I have it running on my Threadripper some day. Good memories there I treasure like crazy.

I’ll always have a soft spot for VMS, the first “big computer” OS I ever used. And perhaps did a bit of hacking (allegedly) back in 1990.

Did the hobbyist licensing [1] get resolved? I was inspired by the work of Andrew Back [2] getting VMS clusters working on Raspberry Pis.

The fact that it’s still around today is a testament to our purest technologist passions. I’m old enough to remember how we though the (open) web would be (creating one of the first 100 websites), and now curmudgeony enough to complain about what it’s become. Come on, we all know it’s at least a bit shit. But also awesome.

I guess I was lucky enough to be around VMS, SunOS and NextSTEP in a 12 month period and filled with the optimism that the intersection of them, with some of that all seen mostly via an Amiga interface, could become. Man, they were the days.

I think that even with all the pressures put upon the creative devs, product folks, and hard-working ops and support folks that we’re all driving towards what’s best for our organisations - despite the mediocre early 20 MBAs and managers who’ve have no formal training.

Apologies for the extra episode of HCF but in those days it was more exciting than helping folks with cloud, IAC, etc.

But I’m just a grumpy ops bloke. Off to write something in BASIC on my Spectrum and remember why computers are fun.

[1] http://www.openvmshobbyist.com/news.php [2] https://web.archive.org/web/20190620014639/https://www.rs-on...

[EDIT[ typo “produce folks” and “product folks” are completely different!

No, that's not what x32 is for.

On x86-64, Linux supports legacy 32-bit apps (i386 ABI) and native 64-bit apps (x86-64 ABI). However, the x32 ABI isn't either of those. x32 is actually a hybrid 32-bit/64-bit architecture, that lets you use some of the newer features of x86-64 (such as increased number of registers) while keeping 32-bit memory addresses. The theory behind it is that for apps that don't really need a 64-bit address space, 32-bit pointers consume less RAM than 64-bit ones. Using less RAM can have flow-on performance benefits – you fit more in the CPU cache, etc.

While x32 is a nice idea in theory, it never really took-off. It is adding a lot of complexity (a third architecture for distributions to support) in exchange for merely modest performance improvements. And it has nothing to do with backward compatibility – that is the role of the i386 ABI, not the x32 ABI. i386 ABI gives binary backward compatibility, x32 ABI requires a recompile. It might be a little bit easier to port from i386 to x32 than from i386 to x86-64, given the pointers remain 32-bit; however, in practice, people either just stick with the existing i386 ABI binaries, or skip it and make the code changes for 64-bit.

> Seems like the kind of thing that OS X desperately needed...

Apple didn't have to discontinue 32-bit application support for macOS. They made a commercial decision that doing so would save on engineering resources. It ultimately had a business/financial motivation not a purely technical one.

It possibly made their task of implementing x86 emulation on ARM somewhat easier. However, they always could have either (a) invested more to support emulating 32-bit x86 on ARM as well (b) limited x86 emulation on ARM to 64-bit but continue supporting 32-bit on native x86. The fact that they didn't do either (a) or (b) – again, ultimately a business/commercial decision about where to invest, not a technical one.

(And the truth is, 32-bit application support isn't completely discontinued. x86-64 macOS still supports running 32-bit code, as demonstrated by the Codeweavers branch of Wine. They removed the 32-bit libraries from the OS, and blocked the execution of 32-bit Mach-O executables, but there still exists an API which applications like Wine can use to manually set up a 32-bit address space and run some 32-bit code in it.)

I thought about this a while after this, and yeah, I'd agree. Although as far as scheduling and IPC goes, I'd say this is less about "raw performance" as taking a chunk of CPU cycles and better utilizing it. So a VM running under Linux/KVM could experiment there in useful ways.

There are still new/tweaked ways to manage/divide raw hardware, though. Stuff like trying to reduce UI latency which would be hard to do through a PV interface and needs bare metal.