Hacker News Reader

Comment by cyberpunk | Hacker News Reader

I know a defence company that has a bunch of vaxes stored in low oxygen environments because they legally have to be able to provide software updates to firmware they’ve written for the next 20 or so years and it was written on a vax.

They had some great stories trying to get something or other running again where they had to fly one of the original designers over to hand solder a board back into action.

How we do that today is a bit of an interesting problem I don’t think they’ve convincingly solved; basically maintaining nightly builds forever — a couple 1U’s of kubernetes in deep storage ain’t gonna do it, you’re not gonna be able to solder a xeon back to life..

I know I’d rather be trying get a load of c99 rebuilt for some mips or other after 20 years that some random version of rust.

View on HN

> I know I’d rather be trying get a load of c99 rebuilt for some mips or other after 20 years that some random version of rust.

Rust 1.0 is 11 years old and it's still trivial to compile Rust code from then. I doubt that will change in the next 9 years.

C is an absolute nightmare in comparison. I tried to compile some old C code I had for Nordic nRF51 chips, only a few years after the chips became available. I gave up. Broken links, missing documentation, etc. etc. I can see why other people here are saying it's standard practice to archive a VM. Not really necessary for Rust.

shrug I guess we have different experiences. Any even small sized rust application I've come across rivals nodejs for amount of deps it pulls in.

Sure, just vendor them in, simples, right?

You could do (it is simple), but all the code is stored on crates.io so there's no real need.

An exception is for crates that wrap C code which might get the code from elsewhere but those are quite rare.

And they’re immutable, forever? No one can pull a leftpad?

Yes, they are immutable. It's only possible to "yank" a specific version, which will prevent new dependencies, but it will still be available for download for existing dependencies.

https://doc.rust-lang.org/cargo/commands/cargo-yank.html

To elaborate on "prevent new dependencies", dependency resolution will never choose a yanked version. However the yanked version remains hosted.

I tried to compile and run some C code from 1991 using a modern C compiler:

https://github.com/sshine/dikumud/commits/master/

It wasn't plug-and-play.

My guess is that when Rust code gets 30 years old, the problem would more likely be that you can't find an already compiled compiler that will work for that old code, and that the compilers themselves need bootstrapping. So you'll just fast-forward the code to work on a new compiler instead.

> you can't find an already compiled compiler that will work for that old code

If it's pure Rust code then the latest Rust compiler will almost certainly work.

The issue will be if some of the crates wrap C code... but that kind of proves the point.

> Rust 1.0 is 11 years old and it's still trivial to compile Rust code from then. I doubt that will change in the next 9 years.

Maybe it's trivial to compile Rust code but it's not trivial to build a project with dependencies. I'm trying to get my feet wet with an official USB example project from Embassy on my RP2040. It doesn't work in the latest git repo for some unknown reason (might be my fault, probably is, but it's not obvious to me).

I'm assuming it worked at some point, maybe something changed and someone forgot to update something somewhere (there are lots of example projects). So I thought I'd "git bisect" until I find a working version and go from there. Well, I cannot get it to build against anything older than a year ago and that version also isn't working for me. It's dependency and Rust edition hell.

Isn't Charon VAX officially supported by HP/Compaq/DEC these days?

> I know a defence company that has a bunch of vaxes stored in low oxygen environments because they legally have to be able to provide software updates to firmware they’ve written for the next 20 or so years and it was written on a vax.

So uh, will these ever make it to an auction site you think?

I have an Acer Chromebook with Celeron N3060 CPU and it runs the SIMH VAX emulator with 64MB for the VAX at the same speed as a Vaxstation 4000/60 and likely the disk is much faster.

I like OpenVMS and am slowly learning more about it; no reason to wait until you see those hit eBay :-)

Reply on news.ycombinator.com