> "This system runs an older version Stratus proprietary VOS operating system, which Hogan believes hasn’t been updated since the early 2000s. “It’s been extremely stable,’ he said."
That's not particularly surprising to be honest. If it's a server operating system, on hardware that doesn't change, there's not really a reason to update the OS unless there's a security problem found
It's not really a security strategy, but running an obscure proprietary operating system on a system which probably isn't connected to the internet means that you're only susceptible to highly targeted attacks by a dedicated foe.
Apparently the latest VOS release was in 2025, which means that somewhere there's a team of developers maintaining it. That's really the thing I find the most interesting, that there exists teams developing operating systems like VOS, strange DOS clones or UnixWare (perhaps less so these days). Must be a strange anonymous life.
This perfectly characterizes most embedded systems work. Competent software development using bespoke or off the shelf components that are not mainstream. Nobody ever realizes they’re using your computer software if you’ve done your job right. One day someone throws your appliance away because it’s obsolete.
Most likely not directly connected. I'm assuming this one is doing process control and any internet access it might have must be mediated by other systems.
On a PDP-11 there were 8 registers, R0-R7, with R6 being the (default) stack pointer and R7 being the program counter.
There were 8 address modes for each register.
So a src/dst instruction used up 12 bits for the src/dst+modes, a single register instruction used 6 bits.
You could load the registers directly at addresses 177770 through 177777 on the front panel. So if your program was 5 words long, you could load that into registers R0-R4, then load R7 with the address 177770 and execute.
You could. But thats rarely where the perf hit is. You rarely need more CPU juice than Go provides, and if you do you probably use Rust or C. There is little to gain from dropping down to ASM, as you most likely run on an OS that is more powered than a microkernel, where you would need ultimate low level control.
Where's the irony? They are happy for anyone to be a part of their community, unless you are making other in their community feel unwelcome. It's spelled out in their code of conduct for you. If you're making innuendos that make other people feel unwelcome, you are not welcome
Whats the expiration date on, say, the windows 95 version of paint? Because it still loads just fine on my current windows computer, does everything I'd expect from a paint program, and gets out of the way when I don't need it anymore
>Whats the expiration date on, say, the windows 95 version of paint? Because it still loads just fine on my current windows computer,
When people say software is "expired", "obsolete", "legacy", "limited shelf life", etc ... they're not talking about whether somebody somewhere in the world has the ability or idiosyncratic desire to continue running that old software.
Instead, it means the software's ability to be practical and usable in relation to the rest of the current computing ecosystem. E.g. In this perspective, Win95 MSPAINT is "expired/obsolete" because it can't open .PNG and .JPEG files. In today's world, .PNG/.JPEG files are much more common than the .BMP files that MSPAINT 95 can open.
I still have an old 16-bit Microsoft C/C++ v 7.0 compiler from 1992. Did it expire?!? Well, not literally. There's no ticking time bomb in it that checks the system clock and refuses to run. Instead, the issue is that it doesn't have the newer C99/C++98/C++11 features and I can't use it to compile today's ffmpeg source code. That's what people mean by "expired/obsolete".
I don't think OPs comment was meant to be taken literally word for word. Breaking down language this way is hardly a productive way to discuss. OP is saying that most software has an expiry date, is this even controversial? All active software companies are constantly rewriting their stuff and would love to move to a more optimized stack, if cost of porting is not a factor.
I don't know the expiration date of all software, I only know all software has some expiration date. Maybe that version you're using will not be usable in the next 5 years, and it will prove my point. That doesn't mean you cannot use it anymore, it means better options took over.
I would be interested to see a leaderboard comparison between male and female cubers. As far as I know, there should be no real biological advantage either way
Do you know if they also scan for drug residue using those devices? A while back I was travelling through a German airport, and got pulled aside to get the skin on my stomach and the inside of my bag swabbed, and I assume tested in the same kind of machine. I don't know what I did to warrant a further inspection, but I wasn't going to make a fuss. I sometimes wonder what would have happened if they'd pulled aside one of the guys in my group who were definitely using drugs
A piece of software Lockheed made gave its outputs in US Customary units (not following their specification), and NASA expected it in SI units (as their specification expected)
It seems like it should have been checked by Lockheed not NASA since supposedly NASA provided a specification, that specified the units, and paid for the software no?
> "The output from the SM_FORCES application code as required by a MSOP Project Software Interface Specification (SIS) was to be in metric units of Newtonseconds (N-s)"
(MSOP = Mars Surveyor Operations Program).
One of the recommendations was
> "Conduct software audit for specification compliance on all data transferred between JPL and Lockheed Martin Astronautics"
So yes, NASA should have checked the provided software more thoroughly, but also Lockheed should have actually followed the spec they were given. I doubt the SIS is available online to check any harder
No, if NASA chose not to triple check everything before sending something into space then they are as much to blame as the supplier. Blindly assuming something works like it should without testing it makes an ass out of u and me.
Very fitting for the AI age as well.
"Yeah I just put the specs of the project you're paying me to do (in NASA's case, probably 100% public funds) but Claude the gimp missed the units because all previous training data use Stones and Yards as units, you should have verified it yourself! I just prompt!"
Should have been checked by both. Lockheed should have checked because of contractual obligations; NASA should have checked because of minimal engineering practices (bugs happen in all your dependencies).
They happen and some are put there on purpose too. In this case it's not a "bug" in your dependencies, and yes NASA since it's using public funding should have been more careful, but ultimately it's Lockheed that was paid to do something no?
Lockheed's job is to follow the customer's specifications.
NASA's job is to check to make sure what they paid for is what they received.
I do this every single day as a quality inspector here. I don't know why a bunch of highly-degreed engineers can't do a simple job that a person with oonly a GED does without fail.
Actually no, it's Lockheed's that should have had a test-suite and conformance-suite for it, but probably only has a C-Suite. If the program is non-trivial proving its correctness can be very expensive to prove, both money and time wise, and something that is done contrary to the spec is obviously on the one executing the spec and being paid for it, which probably wasn't cheap and probably these expenses add to the "NASA only burns money..." narrative.
That's not particularly surprising to be honest. If it's a server operating system, on hardware that doesn't change, there's not really a reason to update the OS unless there's a security problem found