Not a surprise. There's a lot of that stuff around, on OpenVMS. There are new systems — yes, using BASIC on OpenVMS — being installed, too.
There are new Itanium servers with support added last year, another (final) generation is planned, and — in preparation for the end of Itanium — an OpenVMS port to x86-64 is presently underway, and there's a new OpenVMS release (for Itanium) is scheduled to arrive this March.
Interesting article. Rather than arguing what can or cannot be done or what might or might not work, here's some code, and some history.
Here's full-mixed-language programmable, locally- and fully-remote-debuggable, mixed-user and inner-mode processing unikernel, and with various other features...
FWIW, here's a unikernel thin client EWS application that can be downloaded into what was then an older system, to make it more useful for then-current X11 applications...
Anybody that wants to play and still has a compatible VAX or that wants to try the VCB01/QVSS graphics support in some versions of the (free) SIMH VAX emulator, the VAX EWS code is now available here:
To get an OpenVMS system going to host all this, HPE has free OpenVMS hobbyist licenses and download images (VAX, Alpha, Itanium) available via registration at:
Not only was it used in production, from the first-hand anecdotal accounts I've heard, the VAX/VMSclusters were near-z/OS level of reliability. For a brief time, it was used both in mission-critical environments as well as in academic institutions (basically two of the three large markets that existed during that era).
Every 10 years, the same thing gets re-invented. Take network block devices/clustered sharing. VMS had high-availability and each node you joined could use it's local disk as an aggregate resource. In the 90s you had AndrewFS and CODA (CMU's golden age IMO). Then Linux had the whole DRDB era which gained traction about 10 years ago right around the time Hadoop was gaining traction. OpenStack has Cinder. 10 years from now we'll have something else.
Anyways, great points and good post. VAXstations are available on ebay for pretty cheap, but I'd personally go with a hobbyist OpenVMS Alpha license running on ES40. I threw a setup together a few years back and it was neat. Thanks for the data-sheet, my father will get a huge kick out of it.
There are presently OpenVMS servers and clusters in production in a number of locations, and new configurations are being installed — primarily for existing applications, obviously.
The most recent OpenVMS release shipped in June 2015, and the next release is due to ship in March 2016.
There's a port to x86-64 underway, as well.
For those looking for hardware for hobbyist use, used Integrity Itanium servers are usually cheaper than used working Alpha and VAX gear, and newer — working VAX and Alpha gear has become more expensive in recent years. Various VAX and Alpha emulators are available, either as open source or available to hobbyists at no cost.
From the FAQ: "A regular "Who Is Hiring?" thread appears on the first weekday of each month. Most job ads are welcome there." Some will accept remote workers.
Compile and then link the application code with the particular pieces of the toolkits that you needed and with the provided kernel into a single download image, and either embed or boot or network boot the target box using it. Remote debugging was available, as well as a relational database, etc.
This is also how most embedded applications utilizing an OS also works these days. The OS is a library, you link in whatever you need from the OS + compile time configuration of OS features etc. + link in whatever you need for your application.
I remember you always had to bundle everything together with the exception of what was already present in the firmware.
Also some books I had access in the mid-90's were all about creating your own libOS with tasks and lightweight communication primitives and then bundling everything together.
Coding since the 80's, but the most embedded stuff I did was PC (bypassing MS-DOS), Amiga and Symbian and reading also PIC programming on Elektor.
So maybe my perception might not be the correct one.
Not just another that knows of VMS and the prior innovations but one whose site taught me many things about those days. Glad to get a chance to say (tips hat) thanks for the info. :)
Wish modern systems were designed and implemented with even half the skill that VMS, etc were. I've never gotten to experience an OS reliable enough that I temporarily forgot reboot command. Desktop Linux will have to do. ;)
I knew HP would kill it after acquisition due to rule of no competing product lines (i.e. VMS vs NonStop). I was relieved that they spun it off to another company that began a Xeon port. Two quick questions that you might know already if you've contacted them:
1. Has the company been more clear privately than the website on how long it will be before a Xeon port materializes?
2. Have they significantly reduced the OpenVMS licensing costs that kept many off it?
OpenVMS and NonStop (NSK) do not compete. Entirely different products and markets.
VMS Software Inc (VSI) have licensed OpenVMS from HPE. They've not acquired the product.
The company was newly formed, not a spin-off of HP.
VSI have been circumspect on their x86-64 release schedule.
The team includes many of the same development folks that ported OpenVMS from Alpha to Itanium.
OpenVMS I64 Itanium software list prices are unchanged from those of HPE. Whether and how much the VSI sales reps might be discounting, you'd have to ask them.
"OpenVMS and NonStop (NSK) do not compete. Entirely different products and markets."
Outside legacy market, I thought they both advertised as being for business-critical systems that can't afford downtime. I remembered plenty of HP advertisements on that for OpenVMS & its clustering. NonStop obviously does that stuff with even better availability due to FT HW/SW. What makes you say they don't compete?
Note: I'm not talking about the five 9's, HW-supported stuff that OpenVMS probably can't touch.
PFS will make it so connections need to be individually attacked but since most PFS is done with Diffie-Hellman variants (susceptible to Shor's algorithm), the group size also needs to be large enough to resist early quantum computers.
For defense against large quantum computers, different PFS schemes need to be used (fortunately not hard to construct from other post quantum primitives).
Google Groups has various options, one of which is a comparatively poor web-based front-end to Usenet. (Yes, there are still active Usenet groups.) Getting this right across multiple browsers isn't easy, but Google Groups postings to Usenet can be pretty badly formatted.
Some history: Google acquired DejaNews and the contents of other usenet archives, and has largely let all of that data languish, with what can sometimes be very weak search abilities of the archives via Google Groups (no hits for XYZ in an active group for XYZ, for instance), and where Google doesn't make the Usenet archives available and visible via the main search Google engine, and has generally become somewhat of problem.
Then there are the folks that dredge up a decades-old usenet thread — possibly having no idea what Usenet is — and post to it, and with the usual hilarity that ensues. "Hey, is PDQ still available?" to a post offering PDQ that originally posted in 1997, etc.
By some appearances, Google Groups is headed in the same direction as Google Reader.
vim works fine on OpenVMS, as it's in use in some other OpenVMS windows right now. (But thanks for the reminder to upgrade to the most current — upgrades underway.)
I'm not particularly inclined to port neovim to OpenVMS right now, as there are a few other projects in the queue ahead of that.
There are new Itanium servers with support added last year, another (final) generation is planned, and — in preparation for the end of Itanium — an OpenVMS port to x86-64 is presently underway, and there's a new OpenVMS release (for Itanium) is scheduled to arrive this March.
https://vmssoftware.com/products.html