Nearly every installation site and their internal support director agrees that the z/OS installations are far less expensive to support, simply because the minimum level of experience for a z/OS engineer is about a magnitude more than a cloud engineer.

They also take this approach of "whatever tool works," but their coding test is "here's some symptoms of the SVG generator misbehaving, figure out what happened and fix it," which requires digging into the commit history, issues, actually looking at the SVG output, etc.

Once you've figured out how the system architecture works, and the most likely component to be causing the problem, you have to convert part of the code to use a newer, undocumented API exposed by a RPC server that speaks a serialization format that no LLM has ever seen before. Doing this is actually way faster and accurate using an AI, if you know how to centaur with it and make sure the output is tested to be correct.

This is a much more representative test of how someone's going to handle doing actual work knocking issues out.

I was extremely surprised to find out that based on ICE’s annual reports, which are still up, Biden’s administration deported far more people than Trump’s did, especially in 2024 due to rule changes which roughly doubled the number of normal deportations. I was further surprised to find out that there were roughly 3.5 times more deportations under Biden than under the first Trump administration.

I suspect that what’s happening is that leadership under Biden did the sensible thing and very quietly snuck up on priority illegal aliens, whereas with Trump, all the media attention is causing similar people to circle the wagons and proactively take steps to avoid enforcement actions.

Despite having all the conveniences of a modern OS, the overall complexity is way lower than a typical Linux distribution. It was all designed by a single firm under tight resource constraints, so the amount of shared common code is way higher, the number of parts is way lower, and it's much more feasible to keep the whole design in your head all at once.

The clustering technology is also state-of-the-art, and has been for decades, even if you treat the cluster members as real-time control machines. Everything you need to build what most people think requires a whole k8s cluster and several helm charts is already built in to the OS. This includes stuff that most people don't think of until later, or try to reinvent on top of the DB. Distributed transactions, propagating the OS security model into the application, industrial-strength audit logs, autodiscovery, it's all built in and works out of the box. Pretty much everyone from a k8s or borg background that I've had to onboard to legacy apps running on OpenVMS clusters is blown away by how simple everything is. Even though there's fine-grained resource quotas and support for bin packing workloads throughout the cluster, it's rarely needed because of how efficient everything is since applications all use a common runtime designed around async paradigms instead of six zillion third party libraries and multiple C runtime libraries per container that can't share memory pages.

Because it has fewer moving parts, almost never needs to be patched, and they kind of got everything right the first time, it's much more deterministic than any other non-embedded operating system you can practically use on modern hardware today. It would absolutely be my first choice, today, if I had to build some kind of highly reliable control system cluster that had to stay up beyond my lifetime. To this day, I see absolutely ancient installs on a regular basis that simply will not die because they keep swapping out cluster members when they fail. Itaniums and Alpha Galaxies with RPS are extremely reliable by themselves too, and their biggest reliability threat is availability of replacement PSUs and memory. The OS was designed in a pre-Internet era where putting a control host out in the boonies somewhere to control some satellite ground station, feeder dam for a hydroelectric system, or military radar had to work, had to stay up, and had to be as reliable as the hardware of the time would allow. There really isn't anything else like it that will give you those kinds of guarantees in a disconnected, IoT-type edge environment, yet also run on modern gear.

One of the major downsides is that learning how to work with the OS to do modern things isn't well documented anywhere (e.g. how to use logical names to emulate Linux namespaces/container technology). DECNet in particular is a real sticking point for everyone, even though Linux has supported it since forever. I think I might be the only person I know with the enterprise networking, Linux, and OpenVMS background to do all the network plumbing required to integrate DECNet with a modern hybrid cloud or hyperconverged stack. It's not hard, but you have to make sure you check off a bunch of stuff from a checklist to make sure everything works. It's getting harder to find Cisco gear that natively supports it too, but using VMs to NFV some vyos routers or whatever to create brouters works just as well as it does for managing all the usual IP north-south and east-west flows in a big production system.

Despite its age, DECNet is a big feature of OpenVMS because of how it supports the clustering technology, MOP, and things like LAT. LAT is a standardized remote serial protocol that lets you do stuff like add a serial port somewhere that the OpenVMS host can see on the network, and it shows up as a native comm device in the operating system. You can open it, toggle the control lines, all that stuff just like a normal serial port connected to the host. This is unbelievably convenient for distributed control systems because everything was designed by a single firm instead of e.g. trying to integrate digi's remote serial drivers into your product or trying to reinvent autodiscovery of RFC2217 devices. There's a lot more serial ports around than you might think, like the QXDM port on your phone, BMCs, deaf TTYs, the console port on your RPis, etc. Having an infinitely expandable host capable of doing real-time control of hundreds of serial ports all at once isn't something I'd consider any other operating system for.

You kind of have had to work at a shop where they built a lot of stuff on top of OpenVMS within the Internet era to get that knowledge, because I'm not aware of any books or other reading material which explains how modern things map onto the corresponding OpenVMS concepts. I should probably write a book or something, because it would be a shame if the underlying concepts faded from our collective memory and the open source community ended up reinventing all this stuff in a much less efficient way spread over a dozen open source projects that don't have a central architectural authority beating everyone up about centralizing common code.

Cutler and his original team really did deliver a complete OS that got everything right the first time, and I can't think of any modern requirements that OpenVMS can't handle from an architectural perspective. I guess the filesystem isn't capable of doing really big work like a huge z/OS data set or a petabyte sized ZFS pool, but then you just use NFS with EFS or a netapp if you have a fortune 500 IT budget. It sounds wrong, but OpenVMS I/O still sets speed records compared to everything else because of the first-class async I/O support in the OS, and how simple the file I/O layer in the OS is. You can explain the entire write() to disk driver sequence of events to someone in 5 minutes for VMS, but I can't imagine trying to explain just the linux dcache in less than an hour. Just walking through all the filter drivers and everything else touching an IRP in a typical Windows machine is like a semester-long course.

I've also had eSIMs from FirstNet and AT&T, no problems there either. Running dual-sim hasn't been a problem either on any of my Galaxy or iPhones.

The 6502 seems to be a technology demonstrator that has no commercial application, as there’s no corresponding low cost power supply for their parts. Because polymer semiconductors are only about 1% efficient, it takes way more power than an energy harvester could supply.

  Location: San Jose, CA
  Remote: Yes.  I travel around the Singapore area for an ongoing project, but I'm based in Silicon Valley and can do on-site or hybrid work in either region.

  Willing to relocate: For the right price.

  Technologies: {AWS, GCP, Azure} plumber. IaC {Windows Server, Linux, NFV} administration. Bash, zsh, C, modern C++, JavaScript/node, Linux, Darwin, Win32/64, Python, Ruby, a bunch of other scripting and frontend languages.  Ansible, Terraform, CloudFormation, Jenkins.  SQL and Mongo, onprem, hybrid, and cloud.
  Résumé/CV: email if needed.
  Email: mackeycam25@gmail.com.