Tom's Hardware learned that candidates would oversee machines running 166 MHz processors with 8 MB of RAM, which are used to display important technical train data to...
The fact they’re still running on dos is a clue that either they can’t figure out how to upgrade or they don’t want to upgrade or they simply won’t allocate the budget to upgrade.
It generally boils down to money. Shops like that are toxic. They somehow don’t have the budget to keep their business afloat, means you’re not getting a raise.
If you take this job, you’re obsolete. Getting the next job will be tough. You’re interview at the next potential role what did you do at your current role? I ran dos on 30 year old machines. Interviewer: I’m sorry, but we need someone with experience in Windows ME.
If you take this job, you’re obsolete. Getting the next job will be tough.
There is a meme that COBOL programmers still make bank to this day because no one learns COBOL and old enterprise systems run on COBOL. How much of this is true?
It’s going to be a mess of things written in 6 different languages, magic numbers all over the place. Unit tests? Predates all that. Even if you tried, the first you’ll know about an error is when you turn the news on and there’s two trains upside down and on fire.
It is definitely the exact opposite of this. Even though I understand why you would think this.
The thing with systems like these is they are mission critical, which is usually defined as failure = loss of life or significant monetary loss (like, tens of millions of dollars).
Mission critical software is not unit tested at all. It is proven. What you do is you take the code line by line, and you prove what each line does, how it does it, and you document each possible outcome.
Mission critical software is ridiculously expensive to develop for this exact reason. And upgrading to deploy on different systems means you’ll be running things in a new environment, which introduces a ton of unknown factors. What happens, on a line by line basis, when you run this code on a faster processor? Does this chip process the commands in a slightly different order because they use a slightly different algorithm? You don’t know until you take the new hardware, the new software, and the code, then go through the lengthy process of proving it again, until you can document that you’ve proven that this will not result in any unusual train behavior.
Why use MS-DOS? Why don’t we just re-write it in Rust?
Edit: I should have mentioned /s in my comment. It’s never a good idea to rewrite a mission-critical software.
The fact they’re still running on dos is a clue that either they can’t figure out how to upgrade or they don’t want to upgrade or they simply won’t allocate the budget to upgrade.
It generally boils down to money. Shops like that are toxic. They somehow don’t have the budget to keep their business afloat, means you’re not getting a raise.
If you take this job, you’re obsolete. Getting the next job will be tough. You’re interview at the next potential role what did you do at your current role? I ran dos on 30 year old machines. Interviewer: I’m sorry, but we need someone with experience in Windows ME.
There is a meme that COBOL programmers still make bank to this day because no one learns COBOL and old enterprise systems run on COBOL. How much of this is true?
We should just re-implement DOS in Rust and call it RS-DOS.
DROS (DISC and Rust based Operating System)
Because they like their OS to be Dirty
You think the existing system is documented?
It’s going to be a mess of things written in 6 different languages, magic numbers all over the place. Unit tests? Predates all that. Even if you tried, the first you’ll know about an error is when you turn the news on and there’s two trains upside down and on fire.
It is definitely the exact opposite of this. Even though I understand why you would think this.
The thing with systems like these is they are mission critical, which is usually defined as failure = loss of life or significant monetary loss (like, tens of millions of dollars).
Mission critical software is not unit tested at all. It is proven. What you do is you take the code line by line, and you prove what each line does, how it does it, and you document each possible outcome.
Mission critical software is ridiculously expensive to develop for this exact reason. And upgrading to deploy on different systems means you’ll be running things in a new environment, which introduces a ton of unknown factors. What happens, on a line by line basis, when you run this code on a faster processor? Does this chip process the commands in a slightly different order because they use a slightly different algorithm? You don’t know until you take the new hardware, the new software, and the code, then go through the lengthy process of proving it again, until you can document that you’ve proven that this will not result in any unusual train behavior.