No hardware failsafe system?
"If it's on fire, it's a hardware problem"
"The objective of electronics is to keep the smoke IN the wires"
Operating systems & software aside, there's no excuse for operating commercial machinery that don't have #OSHA required failsafes even if it's just for operator/employee safety. If the software was calling for increasing temperature because a sensor was saying 0 degrees, that's on the sensor, not the software.
Software that operates with proper machinery with failsafes would be monitoring sensor status AND failsafe status such that temperature increase would be called for ONLY...
IF (sensor=less than setpoint) AND (failsafe not tripped) THEN increase temperature ELSE shutdown with error message.
β² ππππππ π³οΈββ§οΈπ¦ - 2024-07-29 23:10:53 GMT
I want to tell a story. This is the story why I started using #Linux. And why I had no Microsoft products in my house since.That year was 1997. Computers on the manufacturing floor at work were mostly open hardware Z80 controlled GE/Fanuc PLC's... or PC's running a several kilobyte assembly language program connected to parallel port I/O boards. And that older stuff worked like a top 24/7/365 unless the power went out or someone accidentally blasted the steam seals near the desktop computer. They were controlling large production lines long as football fields.
Then some engineer who I will never forgive decided to rewrite all the production machine systems in Visual Basic for Windows 95. Windows and other proprietary systems were crashing like crazy. Remember, this is when Windows didn't use memory page protection and was filled with kernel bugs. It was unreal. If a machine had to be restarted, the production had to be restarted and that made a lot of scrap. There were about 30 active production lines running at one time, limited to the 1.6 megawatt agreement with the utilities. If all the Windows machines crashed, it took about 80,000 pounds of raw materials to restart the production lines. Forklifts would be filling up the dumpster on the back dock.
Every night at midnight, proprietary software known as BackupExec would start at midnight. After about half an hour, the load average would increase on the Oracle database and crash it. Every production machine would routinely push the production report and would crash the entire production line if it wasn't there to sync. The whole plant would shut down shortly after midnight, every night. After a week, this got old, fast.
One night, I had a life changing event with a Windows machine. An operator called on the radio that a plastic extruder was on fire. It was a 330,000 kilowatt PVC extruder and the Microsoft Visual Basic computer was showing zero degrees on every heat zone. Obviously with the fire from the barrel heaters, it was at least several hundred degrees. A few moments later was a loud explosion and the plant floor went dark with chlorine gas. I could see light to the right of me and that's where I ran. When smoke cleared, I could see the extruder barrel had shot the thousand pound head across the plant floor like a canon. Fortunately I was only several feet away from being in front of it, so I lived. Visual Basic had an interesting feature where malfunctions like that happened a lot.
That week, a copy of Redhat Linux 4.1 arrived in the mail. I installed it on my new laptop. It was crazy fast. It did everything I wanted. I compiled the kernel. I compiled everything. It could play mp3 music. And it was reliable. It was all fun and games until some years after the IPO. Google did the same thing. I would soon learn we had a term for this. #enshitification
So this is why I love free open source software and despise walled gardens of software companies. I remember #RMS on #UseNet was a bit crazy then, but he made the #GNU software license that made this possible.
That's my Linux story. And how #Microsoft almost killed me. Other people have #Microsoft horror stories, but this one was mine.
