Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That's outrageous...

1. RE: FORTRAN. VAX FORTRAN was the most awesome implementation of FORTRAN ever. FORTRAN because these systems didn't have much RAM and CPU power was limited. FORTRAN went into the background for a while when the C fad began in the early 1980s; however, academics cringed at C for reasons that the industry would eventually learn "the hard way" and FORTRAN came back along with a government knee-jerk reaction called Ada and a pile of 4GLs starting with DATATRIEVE --up until processors and RAM allowed for more productive use of more powerful "safe" language systems (Java, C#, Python, Swift).

2. RE: ITANIUM. DEC created VAX/VMS for the break-thru 32-bit VAX-11 architecture and then ported it to its break-thru 64-bit Alpha architecture and rebranded it as OpenVMS. The Alpha chip was really powerful, but it was produced only by DEC's Hudson chip plant (which also produced the StrongARM chip whose descendants are in all of the smartphones). To address the customer need for a second supplier for that chip, DEC began to shop around the Alpha architecture to other semiconductor manufacturers. One of those was Intel --which decided not to become a second source and a little while later, announced the Pentium series that revived its ALL BUT DEAD x86 architecture using patented concepts found only in DEC's Alpha chip. There was a lawsuit and the settlement was that Intel would buy the Alpha chip and Hudson plant. This resulted in the Itanium architecture, which the then owner of DEC (HP) decided to embrace for OpenVMS and its other HP operating systems. As the Pentium chip gained momentum, Intel realized it would be more profitable to use the tech to make X86_64 architecture. Meanwhile, Microsoft, which was all but ready to dump the ALL BUT DEAD x86 architecture (in favor of MIPS and PowerPC), pivoted with Windows NT and released full support for X86_64. Considering that Windows NT was developed by the original computer scientists behind VMS and considering the dominance of Windows on the desktop and the low cost of X86_64 hardware (due to economies of scale), it was no surprise that Itanium fell out of favor, and OpenVMS along with it (though there were many heroic efforts to "rescue" OpenVMS from that dead architecture, HP had no real interest --at least not in time).

3. RE: VMS TCP/IP. This cracked me up. I wrote one of the first TCP/IP stacks for VAX/VMS on a VAX-11/780 using InterLAN hardware. You are correct that VMS pre-dates TCP/IP --but dude it was only by like 1-2 years! VMS was uses with XNS/ITP (upon which TCP/IP was based). TCP/IP is le grand garbage --as the entire planet knows now and DEC had bet heavily on something called OSI to replace DECnet. But some f'n jack head named Vincent Cerf created an async implementation for TCP/IP that allowed the bazillion Windows PC to hop on the Internet (what could go wrong) and that quickly became Microsoft RAS which destroyed the universe quickly. All of the stable and secure networking systems died. Bill Gates was interviewed at one point and responded to a question about what the biggest unexpected development had been with a dumb look saying he had failed to predict the sudden end of distance-and-time based pricing for data communications. So now, dude in St. Petersburg can show off his genetic superiority by hacking the microcode in the Intel Ethernet controllers in your laptop from 8,000 miles away at virtually no cost. Enjoy!

4. VMS knowledge are hackers. This is among the most outrageous comment I've read on the Internet. VMS was all about structure and discipline. If you weren't a computer scientist (or college student) you weren't even getting a job working on one! What you probably observed had nothing to do with VMS but just maintaining legacy code in general.

5. RE: "interesting". VMS was the most powerful operating system ever created well into the modern era. You can imagine that the guys creating Windows NT at Microsoft (who previously developed VMS for DEC back East) were not being allowed to create the true successor to VMS --the idea was to get something working on small cheap PCs that would be sold to all of the small businesses, not on continuing to perfect the product of 30 years of engineering (as VMS descended from their prior RSX11 and RT11 operating systems) as they had been doing first to the 78032 "chip" and later to the Alpha processors. I think around 2015, Windows, Linux and MacOS finally began to pull away from where VMS was (back in 1990). One can only imagine how powerful VMS would have become when run on something like the MacPro 7,1 that Apple announced.

In conclusion, true industry leaders, many of whom did not support VMS back in the day (because they were forced to embrace crummy UNIX System 3, V and BSD "hacks" for lack of access to the incredible DEC engineering resources), will tell you that VMS (and TCP/IP) are stories of lost art that severely setback the pace of mankind's development. The reasons are many: Bill Gates' well known BS, Vincent Cerf's destructive efforts to advance PPP, alleged theft of intellectual property by Intel that set off the downward spiral of DEC, skyrocketing memory prices due to market manipulation and Carly "That Face" Fiorina.

Consider yoh-self schooled.



Hard to detect sarcasm or parody here, but this is a great example of someone condemning the systems which were cheap (or license-free), widely available, worked well enough for most people, and provided huge benefits to millions, because it doesn't comply with his own narrow view of how it should be done.

> If you weren't a computer scientist (or college student) you weren't even getting a job working on one!

Exactly. A system whose priority is preventing people from ever using it.


> example of someone condemning the systems which were cheap (or license-free), widely available

Right!

> , worked well enough for most people

Well, with a mouse click, the Chinese can cause most of the self-balancing mobility devices (scooters, etc.) within a few miles of all military bases and schools to turn off while doing 10-20mph down the street (thus seriously injuring the rider). Goin' be tough to fight a war with ripped up ACL/MCLs and broken bones! 100% of the technology came from the fruit of Richard Stallman's religion.

Can't feel me? Okay, how about if you work for the federal government or have a credit file in the United States (or much of Europe) and all of your financial information is stolen so that the data can now be used to kill your family (either literally or financially) if you don't give them something they know you have and that want (or maybe even if you do!).

So I respectfully disagree with "well enough for most people" because impressionable tech kids didn't know any better ("everybody is doing it") and were convinced to give away their advanced technology over the Internet to people who can't or shouldn't handle it because they want to kill us (literally or financially), aren't trusted and/or don't have the proper education.

Fortunately the passage of time heals all wounds and much that free software movement was really just a bunch of knock-offs of truly new art that was created by companies that have been drifting "sideways" lately (since their founders left) and that's given the governments (barely) enough time to catch up. Soon, code will have to (by platform regulation and eventually federal law) be signed by a third-party before it can run on some unsuspecting user or business' computing platform. But also, there are the Amazing and Wonderful Services that are scooping up all of the millions of would-be idiot developers and subsidizing their lack of educations to ensure that they don't get into too much trouble (and to quickly identify and neutralize them if they are trouble). There's such a demand for this service that they're able to use the revenue to fund a fleet of friggin' spaceships and deep sea exploration platforms.

> his own narrow view of how it should be done

Right again! But note that narrow views coming from some people are far better than the consensus of many people. I know that breaks Star Trek or something, but it happens to be how American business works, for example.


I knew guys who ran VMS systems out of their homes, back in the 90's. It was fairly accessible.


How many of them had the manuals? Very few. The famous "Orange Wall of Manuals" was often secreted away, for the wizards to consult, but not for the masses to enlighten themselves with.


One guy, at least, had manuals. VMS also had an excellent help facility.


Oh, sure. What was the format of an executable file?

Nostalgia is a trap. Wallowing in the idealized "good old days" blinds you to the true scope of history and cuts you off from progress.


Hah. I've forgotten.

Retrocomputing is just a hobby of mind. It's fun to play around with those old systems.


As near as I could ever find, the format of a VMS executable file did not appear in the DEC manuals. I meant that as a commentary on the "VMS had great docs" sentiment.

At one point, I was convinced that understanding the format of an executable file (a.out, COFF, XCOFF, Mach-O, ELF, .com, .exe, PE, etc) was important to understanding the operating system itself. I spent a fair amount of effort and some money buying books trying to find the VMS executable file format. Couldn't find a hint.


It did, sigh. It was in the LINK'ER documentation. RSX/VMS was all about object modules being shared between concurrently running applications in separate user spaces (because RAM was crazy expensive and DISK was crazy slow and expensive).

The format for runtime libraries, executables and memory-mapped sections in general descended from the PDP11 a bit and I believe it changed radically (for the first time in decades) with the introduction of the 64-bit Alpha architecture under "Open"VMS.


Alas, the LINKER documentation (https://www.itec.suny.edu/scsys/vms/ovmsdoc073/v73/4548/4548...) I can find only includes a description of the "object language" for VAX (https://www.itec.suny.edu/scsys/vms/ovmsdoc073/v73/4548/4548...) and Alpha (https://www.itec.suny.edu/scsys/vms/ovmsdoc073/v73/4548/4548...). It does say that Itanium VMS used ELF format executables. So I think it's still an open question as to whether VAX/VMS or Alpha/VMS executable file format ever had documentation.

How did ELF format files play in VMS' idea of process-as-elaborate-address-sapce, where running a command involved reading or mapping in an executable, and then jumping to the entry point? Or did I64 VMS abandon the unusual VMS process model?


Thank you! I'm serious, I bought several books and inquired of VMS experts (on usenet, that long ago) looking for anything about VMS executable format. This is the first hint I've gotten.


I have a friend who converted a coat closet in his house into a datacenter large enough for a MicroVAX II with air-conditioning. He had run terminal lines to every room in the house to plug-in VTs. That said, he had a legit reason for doing it. Basically writing code 24x7 a day for his customers in those pre-laptop days.


Cool! I'm looking to pick up a VAX or AlphaStation on EBay.


You sound a lot like some of the people I worked with, hey Tim :).

1. The codebase that I was working on was not awesome, it was a mix of Fortran (while i am a fan of and would much rather use that than C for scientific code) and DCL. Lots of stuff that was clearly a design afterthought, but with decades of momentum and an attitude of "just keep it working"

2. There's a lot of history in VMS, but unfortunately it's primarily used to support legacy projects, and with intel not making anymore itanium doesn't seem like there is a future. I couldn't even get a working version of the netbeans plugin to work with it. Basically I got the plugin with no support, despite having a service contract, because there was no engineering supporting fixes.

3. Could have been that the way we wrote out networking was a mess, but I do believe that TCP/IP was an add-on feature that was not part of the kernel.

4. That statement was exclusive to the people i worked with. They were not CS guys, they were support people that had enough experience with the system to get a spot in engineering. They knew how "that" system worked, but not how to solve problems without relying on legacy code that was based on obsolete ideas. I shit you not there were delays in the code because the network was "too fast" and the process couldn't handle it.

5. Solaris is the bomb too.

Take a chill pill, boo


For #3, you are correct. VMS originally required a separate third party product to support TCP/IP. MultiNet was one of the more popular stacks: http://www.process.com/products/multinet/

Newer releases (6.0 and above, I think?) do have DEC's TCP/IP layered product included. I believe it was called "UCX"...


Bless Your Heart.

BTW, this will give you the warm fuzzies:

https://www.vmssoftware.com/updates_port.html


In your shoes, I would ask Larry Ellison to acquire you and then boot it on a MacPro 7,1 to be released with every layered application that DEC ever sold, plus ORACLE for VMS and the whole documentation suite on readthedocs --oh and a VSL (sort of like WSL2 in Windows10) with one of the nicer window managers from the Linux world. I know his current plan is to take on Werner's cloud but he doesn't have enough heartbeats left to see that through, whereas this plan legitimately does for ORACLE what buying Next Inc. (and switching to Intel processors) did for/to Apple. Peace.


Wow, that's recent!

I hope they are optimizing the design to run in a VM, with drivers only for fake VM devices, one of each kind.


Err...why? VMS has dealt with real hw for years.....


Because chasing behind current hardware is a massive waste of time when your only legitimate real purpose is to provide a stable, performant place to run legacy software systems. Let Linux or BSD do the endless, thankless job of rewriting drivers.


> As the Pentium chip gained momentum, Intel realized it would be more profitable to use the tech to make X86_64 architecture.

...which they didn't make but licensed from AMD, no?


5. This brings up something interesting, I wonder how many other good systems/designs/code were killed because they were proprietary and got steamrolled by something open source? It's like in nature, survival of the fittest is a lie, it is survival of those who ended up reproducing.


>If you weren't a computer scientist (or college student) you weren't even getting a job working on one!

This isn't remotely true.


I forgot about the Field Service techs hah. Straight (outta DeVry) programmer analyst types like https://www.denofgeek.com/movies/superman-iii/27817/what-sup... were pretty much considered users in the DEC world. That is, there was a distinction between systems programmers and applications programmers (who might use a DEC-specific forms-management library or a database API but didn't really even necessarily know what model their harmless-to-the-other-users code was running on).


Agreed. Our high-school had a microVAX for back Office. 100% bespoke software in COBOL, replete with a FTE software engineer. High school me learned COBOL and helped out at lunchtimes / after school (it was boarding school near the equator - so an air conditioned VAX room was wonderful!) Got a free place in uni for my trouble :-)


Must feel bad to be Betamax.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: