Comment by krylon | Hacker News Reader

Comment by krylon | Hacker News Reader

Parent Full thread

As for the alleged Bill Gates quote, I read somewhere (Deep C Secrets by Peer van der Linden, I think, but I am too lazy to look it up), that "640k ought to be enough for anyone" did not mean that it was enough for anyone for all times. I am not a fan of Bill Gates, but he is not stupid. And at the time he - allegedly - said it, 640k of RAM was (for a single user!) was indeed a lot! Compare that to the 64k of the C64. It is idiotic to think that he meant that 640k would be sufficient 30 years in the future.

That being said, I actually did install MS-DOS 6.22 on three computers over the last couple of years, because the company I work at does - among other things - industrial automation, and (at least) one of our customers has a plant built with automation technology that can apparently only be programmed and configured with a program running on DOS. And it must do some rather funky things, because the software will reliably fail to talk to the PLC if it is running in a virtual machine or on FreeDOS. And of course the company that has written this software has gone out of business a long time ago, so there won't be any updates, either. ;-) If I didn't have more important things to do, figuring out why it does not work on FreeDOS could have been a lot of fun, but just installing MS DOS was the faster solution.

Still, installing DOS these days is an interesting experience. The whole system comes on three floppy disks, the installation procedure takes about 15 minutes, and the freshly installed system boots up in about 30 seconds, including the BIOS doing its thing. Admittedly, you cannot do very much with it without additional software.

Three floppy disks - that is about 4.5 Megabyte, Ladies and Gentlemen. Today's high end CPUs have as much L2 cache, or more.

And primitive as it is, there are situations where DOS is a reasonable choice.

I'm still glad, though, that I never had to deal with segmented memory. That sounds horrible.

Not to throw in anecdote after anecdote, especially since it is slightly off topic, but I have to share.

I worked at a textile company 17 years ago and the bought brand new "state of the art" embroidery machines from Germany and they ran Windows 3.11 for Workgroups. At the time I was just "the web and IT guy" so it was my job to set up a token ring network with coaxial cables to network these machines together so the control computer could send embroidery designs remotely. This was cutting edge stuff, prior to that we had 3.5" floppies and a sneaker net.

But even at the time Windows 3.11 was 8 years old. To this day it is the only time I have seen token ring. I have "fond" memories of walking through hundreds of feet of coax checking each connection to find out which one came loose and took the entire network down.

Damn I remember doing that same thing around 1994-1996, using coaxial cables and checking all the connections / terminators.

https://en.wikipedia.org/wiki/10BASE2

Even back then when we wanted to add a new host to the network we had to hunt in the "junk bin" in the local store to get a networking card, then pray that it was supported under Linux.

I can say that I've never used token-ring though.

What I don't get is, if this multi-decade-old software is valuable enough to be used today, why isn't it valuable enough for someone to have written a replacement in the intervening decades?

Surely every plant like this would pay something for the ability to run on modern OSes, and presumably there are enough plants using this kind of software to recoup the cost of development?

This isn't software that you can just install and use. This type of software is tightly integrated with the hardware in the factory or distribution center. So, even if there were free software which did the same thing, it would cost a lot of time and money to replace the old, already-working system.

Moreover, for software that was put in place 20 years ago, it's likely that some of the functionality is unknown, i.e. the whole system works together, but exactly what is being done by each piece of software isn't fully understood by anyone still at the company. So it would require a bunch of work to even spec a replacement.

So it's totally rational to keep the existing, working system, even if you need a dedicated PC to administer it.

(Source: I was in a similar situation ~20 years ago.)

People who run industrial processes tend to make careful, conservative choices. "If it ain't broke, don't fix it" is the golden rule, since any downtime can cost serious money. This means staying on old, proven systems is favored over upgrading for the sake of upgrading, even if there are possible improvements.

Context: I used to work on solar power management and control, and developed manufacturing processes to build our hardware.

Well, there's two parts to your question, if there is a demand, why isn't there a supply, and is there really a demand?

For the first part, if the original company has gone out of business, and enough records and knowledge lost and scattered, then it'd actually potentially be very difficult for a new group to identify what the original customers were, much less identify what the potential size of market is today. That's quite a lot of risk to take on (in my mind anyways). Industrial automation is one of those things that people don't openly disclose in a way that makes it easy to canvas the market cheaply.

I wouldn't count on that. Battle-testedness can be a feature, and a new software package means new training for those tasked with maintaining the system. The old one is a known quantity.

In some cases there may be replacements, but they would require newer hardware as well (think expensive lab equipment, not just workstations), which brings the cost much higher than simply replacing the software. My father's environmental testing lab is currently in this predicament, but they finally got rid of their last Windows 3.11 (and older) machines a couple of years ago so it's not like they aren't trying, it just needs to happen incrementally.

They can certainly buy new plcs and new hmis to interface together and do things but it's not like a program written for one plc from one manufacturer is interchangeable with one another. the plc code is fairly close to assembly language and it's written for one particular plc with a particular wiring. I could do it but it does take time and money to complete and even then you lose a bit of institutional knowledge codified by the original codebase. Having delved into plc programs built by others(even with comments that get stripped out if you don't have the original source file and instead download it from the plc directly) it's not easy to do. They certainly do still sell new plcs for industrial automation but the programs are typically bespoke.

The bagging control system at my customers seafood factory still uses DOS, it controls the hardware through 2 serial ports, the hardware has been updated several times since the 80's, There are no drivers or security, just base DOS formatted hard disk and autoexec.bat with a single exe program being called, I just clone the hard disk for them when its time for an update and keep the old PC around for backup.

I've thought of reverse engineering the software but to tell the truth the program and the machine it controls were just built very well and so long as we have spare hardware it could go forever.

Due to driver problems I'm not sure you could even build a system these days that would be guaranteed future proofed for 30+ years.

> the freshly installed system boots up in about 30 seconds, including the BIOS doing its thing.

Honest question/clarification, is that... considered fast?

My DOS system used to boot that fast. A C64 is almost instant. And my old ~2013 Chromebook boots in ~7 seconds into Linux with an eMMC drive (slower than an SSD but still fairly fast). It's only got 2 GB of RAM so when it hits swap it'll bog to a standstill so it's often faster just to hit the reset key than try and recover.

I don't understand modern swap. Ok you can page out a few MB you don't use on a regular basis, but any swapping kills the machine.

I'd far rather OOMkiller killed off non active tabs (there's almost always a web browser using the memory on a desktop), or run away apache processses, than try to swap. For that reason I never configure swap on any of my machines.

It doesn't make sense on a server, but on a desktop, unless it's actively thrashing, swapping is normally fine. It's not cool to kill off the user's possibly unsaved work with a few random process terminations.

There are other, more cooperative ways of doing it. For example, always save enough state to restore after a kill when becoming a background task. But it's also more work.

My experience has been that if the usage grows slowly and the system is instructed to actually load stuff to swap I can safely go to the limits of my swap and physical ram space without any freezes and nothing dying (although ofc taking more time, but the alternative is not using the software at all).

Swap can be useful for batch jobs that need lots of memory to run but the working set is small. Then you can keep the physical memory for the working set and the disk swap for the (larger) whole set of memory.

The regular old swap is slightly technologically behind today's needs. It is supposed to be replaced by things like zram and zswap, that don't kill the machine.

My work laptop - admittedly not a high-end machine - takes about two minutes from power-on to login-prompt. I've seen Windows machines - without SSDs - that had tons and tons and tons of software installed on them, that took 10 to 15 minutes from power-on to login.

Compared to that, <30 seconds is very fast. SSDs have been a real game-changer, though. My home desktop takes less than 10 seconds from boot manager to display manager. I used to be very patient, now I kind of regret all the time I spent waiting for some computer to boot. ;-)

The C64 boots off ROM, IIRC? So that is kind of cheating. ;-) But yes, I had a C64, too, the delay between switching it on and the machine being usable was too low to notice.

The boot time bottleneck (if it can be called that) on my old ABC80 was waiting for the CRT to warm up. The prompt was already there and fading into view a couple of seconds after power-up.

Booting from ROM is one thing. Loading something from tape, that's another story.

The Commodore 64 Kernal is in a ROM so it is a fast boot for the OS, but the 1541 floppy drive is slow unless you use Fastload or Jiffydos, etc.

I think some C64 units had a spare socket for GEOS the GUI made for the C64.

While I agree, it should be noted ROM is actually incredibly slow by today's standards.

Reply on news.ycombinator.com