Live data from Hacker News

OpenVMS State of the Port to x86_64 [pdf]

vmssoftware.com

61–70 of 108 posts

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

#61

OpenVMS supports nine programming languages,six of which use a DEC-developed, proprietary back-end code generator on both Alpha and Itanium. We are creating a converter to internally connect these compiler front-ends to the open source LLVM back-end code generator, which targets x86_64 as well as many other architectures. (The other three compilers have their own individual pathways to the new architecture.) This sho…

If you worked for one of their bigger customers, chances are someone paid for source access and it was available on an internal server :) I browsed through a copy a few jobs ago and it's honestly kind of boring.

Boring in this context sound correct.

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

#62

OpenVMS supports nine programming languages,six of which use a DEC-developed, proprietary back-end code generator on both Alpha and Itanium. We are creating a converter to internally connect these compiler front-ends to the open source LLVM back-end code generator, which targets x86_64 as well as many other architectures. (The other three compilers have their own individual pathways to the new architecture.) This sho…

VAX/VMS was always open sourced and available first on microfiche and later on CD. I don't know if this continued after Compaq and then HP came to own the code but that's how it started life. The only censored code was the license management facility, which realistically, was trivially subvert-able if you knew VAX assembly language.

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

#63
post #33
post #16

Earlier quoted context omitted.

Could you give an example of such an industry? VMS to me has always been that OS that everyone claimed to be better than UNIX-likes, but none could explain why.

Here's a couple of examples for you: I Sysadmined a VMS box running on a couple of AlphaServers (2100 and 2100A) if I recall. At one point a disgruntled employee had taken a 22 rifle into the server room and shot several rounds at the equipment, only 1 bullet hit, but it went through a RAM bank, the system disabled the faulty hardware and continued running. The other cool part was the interchangeable boards - the sys…

Ever work with Sun servers? Yeah, you could swap out cards, CPU, ram, drive, power, without halting or rebooting the OS. But not just Sun servers. This is not a feature unique to Alphaservers/VMS.

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

#64
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

Both LinuxThreads and the current NPTL are implementations of POSIX threads. NPTL is closer to the standard, but if your code doesn't need the stricter conformance, it could run on either with no changes.

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

#65
post #62

OpenVMS supports nine programming languages,six of which use a DEC-developed, proprietary back-end code generator on both Alpha and Itanium. We are creating a converter to internally connect these compiler front-ends to the open source LLVM back-end code generator, which targets x86_64 as well as many other architectures. (The other three compilers have their own individual pathways to the new architecture.) This sho…

VAX/VMS was always open sourced and available first on microfiche and later on CD. I don't know if this continued after Compaq and then HP came to own the code but that's how it started life. The only censored code was the license management facility, which realistically, was trivially subvert-able if you knew VAX assembly language.

While a factually correct description of what was made available, I don't think that's quite the intended meaning of "open source".

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

#66
post #47
post #20

Earlier quoted context omitted.

But that's the thing: places which fit those requirements usually run some IBM solution (AS/400 and the likes). I've never encountered VMS in production before, so I'm really curious to some concrete examples of companies using it.

We use it at our company (financial software). One of the reasons being that the code is older than Linux and VMS was a good bet at the time. We have almost entirely moved away from it and onto Linux but considering the decades of code and systems built on and around it, it is truly a monumental task to move off VMS while keeping a system used by very high paying clients running smoothly.

If your employer is who I think it is - you still have many years to go. :-)

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

#67
post #16

Earlier quoted context omitted.

There are still a non-trivial pile of organizations out there that rely upon VMS. I still can hardly believe it myself when I run into them, but as I understand the situations when I ask out of curiosity, these are relatively lower-margin organizations, and the cost of rewriting their VMS applications for them greatly exceeds the cost of adopting a platform that is a port to a major chip architecture and emulating th…

Could you give an example of such an industry? VMS to me has always been that OS that everyone claimed to be better than UNIX-likes, but none could explain why.

In the days when I used VMS it was common for applications to be tied into the hardware. Therefore you only really ran a fairly bespoke set of applications that were specific to your business. Therefore it is never possible to eulogise fully about the cool wonders of VAX VMS as everything was domain specific.

I worked in remote sensing at a time when UNIX workstations were taking over the show. Again applications were tied into the hardware so if you needed an SGI for your code, that was what you had and again it was hard to fully explain the merits of a given platform in a way that makes sense to a Windows user.

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

#68
post #65
post #62

Earlier quoted context omitted.

VAX/VMS was always open sourced and available first on microfiche and later on CD. I don't know if this continued after Compaq and then HP came to own the code but that's how it started life. The only censored code was the license management facility, which realistically, was trivially subvert-able if you knew VAX assembly language.

While a factually correct description of what was made available, I don't think that's quite the intended meaning of "open source".

"Open source" historically meant just that: that you could look at the source, in contrast to machine code-only software.

Only later did the term got confused with "free software" idea from Stalman and the "preferred form for making modifications" as he put it.

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

#69
post #62

OpenVMS supports nine programming languages,six of which use a DEC-developed, proprietary back-end code generator on both Alpha and Itanium. We are creating a converter to internally connect these compiler front-ends to the open source LLVM back-end code generator, which targets x86_64 as well as many other architectures. (The other three compilers have their own individual pathways to the new architecture.) This sho…

VAX/VMS was always open sourced and available first on microfiche and later on CD. I don't know if this continued after Compaq and then HP came to own the code but that's how it started life. The only censored code was the license management facility, which realistically, was trivially subvert-able if you knew VAX assembly language.

This isn't quite correct. What was - and still is - made available to customers willing to pay for it were listings, generated by the compilers, not the original sources. There are more bits and pieces besides LMF that are excluded, sometimes for security reasons, sometimes for legal reasons. Also not made available, are any of the build procedures. What was never done, is release the sources under an open-source license. The source listings are intended as a debugging aid, not as a way to rebuild the OS.

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

#70
post #68
post #65

Earlier quoted context omitted.

While a factually correct description of what was made available, I don't think that's quite the intended meaning of "open source".

"Open source" historically meant just that: that you could look at the source, in contrast to machine code-only software. Only later did the term got confused with "free software" idea from Stalman and the "preferred form for making modifications" as he put it.

That's an interpretation that I had not seen before. You would probably need to provide some more references to evidence for that claim in order to combat the down voting.
Post reply on HN