Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenVMS State of the Port to x86_64 [pdf]

vmssoftware.com

Post reply on HN
Print view View original

51–60 of 108 posts

Re: OpenVMS State of the Port to x86_64 [pdf]

#51

Post by wogna »

andrewbinstock wrote: post #41
wogna wrote: post #15

Earlier quoted context omitted.

That's not really a fair comparison: Windows I/O completion ports are a proprietary standard that is part of the NT kernel, while POSIX AIO is just a user-space libc extension that was added later on (as far as I know, none of the kernel-space posix AIO proposals got merged in). It's easier to get things right when you defined your own standards, at the cost of portability. But even then, you might argue that that co…

If you're talking about Linux specifically, that's not quite accurate history. Prior to POSIX threads, Linux had it's own threading model--Linux Threads--which frankly was terrible. They added the full POSIX later on in part b/c the Linux threading was so awful. [1] has more detail. [1] https://en.wikipedia.org/wiki/LinuxThreads

True that, but I was talking about the POSIX async I/O API: http://pubs.opengroup.org/onlinepubs/009695399/basedefs/aio.... I don't know much about the LinuxThreads-era.

Re: OpenVMS State of the Port to x86_64 [pdf]

#52

Post by srean »

wogna wrote: post #15
srean wrote: post #8

Earlier quoted context omitted.

I hear that VMS is one of those OS's that got its concurrency API done right (BeOS would be another). Windows NT inherited a lot of that. To give an example, POSIX compliant asynchronous I/O on Linux is not that great (it used threads internally). There is also non POSIX async I/O on linux. But these are fare less mature and time tested and over all not a very uniform API.

That's not really a fair comparison: Windows I/O completion ports are a proprietary standard that is part of the NT kernel, while POSIX AIO is just a user-space libc extension that was added later on (as far as I know, none of the kernel-space posix AIO proposals got merged in). It's easier to get things right when you defined your own standards, at the cost of portability. But even then, you might argue that that co…

Proprietary or not is something quite orthogonal to my comment. I was commenting on the design of the API, its implementation and the leak of the abstractions used etc. etc. Async was never Unix's strength, plan9 might have fixed matters somewhat if it caught on.

Re: OpenVMS State of the Port to x86_64 [pdf]

#53

Post by inopinatus »

cm2187 wrote: post #44
sqldba wrote: post #29

Earlier quoted context omitted.

I worked with it for 7 years and the software ran car dealerships. That codebase is 40 years old now and still had remnants from the 70s where it had been originally built for the VAX. Migrating it to a new architecture would not be trivial. That software is extremely tied into the underlying inter-process messaging protocols and data file formats provided by the operating system. You're not just working with a singl…

I am always curious to understand what corporate process on earth can take a decade to be rebuilt. It can be complex but not that complex. Particularly something like car dealership. We are not talking about some super diverse supply chain and interfacing with lots of different hardware, etc.

The key point in the GP is nobody really understood how it worked anymore. No matter how accessible the domain generally might seem, once a system becomes a mysterious black box sans documentation or continuing expertise then no CIO is prepared to sign off the migration, for fear of missing a business rule or special case.

I've been the guy that left taking all the knowledge with him, years later learning that they've lost the documentation & the source code but the system is still running.

I've seen this occur in other domains (finance and education sectors) and basically the black box hangs on until either the unit, or the entire business, ceases to exist.

I did see one project that attempted a like-for-like reimplementation via a carve-out process and it was a decade-long gigadollar boondoggle that has basically crippled the enterprise that tried it.

Re: OpenVMS State of the Port to x86_64 [pdf]

#57

Post by iheartmemcache »

lb1lf wrote: post #50
derefr wrote: post #10

Earlier quoted context omitted.

My question is, which of those "interesting ideas" didn't end up in Windows NT? Is there anything other OSes (Linux, ⋆BSD, macOS) could learn from VMS, that they can't better learn from WNT?

Please bear with the lack of details, as my (very limited) VMS experience involved an offline system which never broke, but: it is amazingly tolerant of hardware failures, I recall sitting slack-jawed over the AlphaStation manual after learning you could hot-swap just about anything - including CPU boards! Granted, that is as much (if not more!) a feature of the hardware architecture than the OS - but amazing still.…

Fun fact: Windows 2008 R2 and Itanium 2 had lock-step fault-tolerance. (Which is on par with the other "biggies"-- VMS, IBMs OS360/MVS, and HP (nee Compaq Tandem)).

On a more relevant note, I know x86-64 Xeon's can mark bad RAM, disk drives, and network cards, and hot-swap them all out out (and has been able to do so for > 10 years) on most motherboards (it's supported at the OS level for Windows server), not sure if it ever had full CPU failure support though.

Re: OpenVMS State of the Port to x86_64 [pdf]

#58

Post by voidmain0001 »

wogna wrote: post #17
protomyth wrote: post #13

Earlier quoted context omitted.

Clustering - OpenVMS does clustering amazingly well. that is one thing that NT, Linux, and the BSDs could learn. Although, DragonFly BSD is working on the file system clustering with HAMMER 2.

Could you elaborate on how it did things better than the common cluster file systems of today? (OCFS2, Hadoop, Ceph, etc.)

I don't have VMS experience, but rather AS/400 and iSeries experience. The difference vs generic purpose OS (Linux, Windows, OSX) is that the AS/400, and I'm going to assume VMS since they operated in similar markets, had these features baked in by the manufacturer. OS/400 on the AS/400 was a menu based system. If the menu option existed, the feature was available, and it was as simple as flipping the bit to YES to enable a feature. Enable clustering? Select Yes, add the information of the cluster and you were done. It just worked. Did it work well? I guess. There was no way to know if it could be done better since it was a manufacturer's enabled feature. Of course Linux, Windows, OSX can do the same thing as OS/400 on AS/400 but with a lot of configuration, and a lot of jumping through hoops [it's not called Hadoop for nothing ;-)].

Re: OpenVMS State of the Port to x86_64 [pdf]

#59

Post by krylon »

In the x86_64 server space (which is, what, 90% of the server market today?), the choice of operating systems is basically between Windows and some variant of Unix (Solaris and its open source offspring, numerous GNU/Linux distros, and *BSD).

Adding another system to the mix, especially one that has been in development for ~40 years, is an interesting proposition in itself. Add to that the reputation OpenVMS has for reliability and security, and I could certainly see a bright future for it on commodity hardware.

Whether that actually comes to pass is another question, but there is at least potential.

Re: OpenVMS State of the Port to x86_64 [pdf]

#60

Post by krylon »

rollthehard6 wrote: post #39
chx wrote: post #37

Earlier quoted context omitted.

Atomic plants. Why? I guess because it doesn't stop. https://www.theregister.co.uk/2013/06/19/nuke_plants_to_keep... http://www.mapps.l-3com.com/candu-plant-control-systems.html

See also Tandem, another HP owned system now. https://en.wikipedia.org/wiki/NonStop_(server_computers)

Which makes me wonder - does anyone know if HP has plans to port NonStop to some non-Itanium platform?

I have never worked with this system, but I have heard great things about its scalability and availability.

Post reply on HN