4 ms·
I used to joke that retro computing was my answer to being stuck as a support engineer at AWS working on Kubernetes all day (I was bait-and-switched on what was
by CursedSilicon 2y ago
I used to joke that retro computing was my answer to being stuck as a support engineer at AWS working on Kubernetes all day (I was bait-and-switched on what was originally billed as a Linux support job and dropped into the "Containers" team instead. I had no prior experience with containers and would prefer to never work with them again!)
I built the "Worlds Fastest Windows 98 PC" [1] kicking off a small YouTube channel. And have demoed it live at the local computer festival here in Seattle [2]. Thanks to Re-PC and others in Seattle I've slowly accumulated dozens [3] of old machines of all stripes that absolutely fascinate and delight me with their quirks.
Despite being thrown overboard from AWS over a year ago now, I still very much enjoy retro computing. I would love to be able to turn my hobby into supporting "legacy machines" into a "real" Sysadmin career, but it seems like YouTube is a more likely bet on that front these days.
The biggest thing I've learned from retro computing is an appreciation for viewing things in their historical contexts. Something that is surprisingly difficult to teach "younger people" or programmers who've only ever really worked at FAANG's.
Younger people today bang the drum about rewriting the world in Rust. Rust is great, and I'm not here to argue for or against it.
But when they bemoan using C they seem to misunderstand exactly how big a leap forward C was from pure assembly programming. Just having portable code in the era of everybody having their own bespoke UNIX system (with their own processor architecture to match, of course!) was an absolute game changer. C is entrenched because it was an evolutionary leap in a landscape that was shifting by the day.
Retro computing has taught me that people weren't nearly as "clueless" or "incompetent" as they're derided for these days. These were smart people making the best decisions they could at the time with what they had available.
People in the 1980's didn't "want" to cause Y2K. They simply never thought their software would be in use 20 years later. How could they? Technology was moving at such blinding speed. Just 20 years before them they were still using punch cards and printout teletype machines on mainframes as big as houses!
[1] https://www.youtube.com/watch?v=YETxI4rA_gs https://www.youtube.com/watch?v=YETxI4rA_gs
[2] https://sdf.org/icf https://sdf.org/icf
[3] https://wiki.cursedsilicon.net/ https://wiki.cursedsilicon.net/
- dailykoder 2y ago>Technology was moving at such blinding speed. And still is. Only 14 years ago basically no one had a smartphone. Now you are "forced" to use it for some real life applications. Also LLMs, etc. There is just so much technology atm, that it doesn't feel like such a big leap, but it's moving incredibly fast. Apprently just the hardware leaps got smaller
- exe34 2y agothe hardware used to leap and the software grew new layers of abstraction to keep up. then the hardware speedup slowed down, but the software keeps growing like a cancer.
- pjc50 2y ago> But when they bemoan using C they seem to misunderstand exactly how big a leap forward C was from pure assembly programming. Just having portable code in the era of everybody having their own bespoke UNIX system (with their own processor architecture to match, of course!) was an absolute game changer. C is entrenched because it was an evolutionary leap in a landscape that was shifting by the day. This is very true, but it's also like saying that magnetic tape was a great improvement over punch cards. It definitely was, but that was also a long time ago. C portability always had a huge asterisk attached to it, which was that the language was not going to help you at all with this, nor was it even going to define basic semantics for anything. It was a long time before it defined arithmetic as two's complement, which was bad news for anyone retrocomputing on a ones-complement machine but while you could compile code designed for one on the other there was no guarantee that it would actually work. People built portability systems on top of this such as autoconf. > Retro computing has taught me that people weren't nearly as "clueless" or "incompetent" as they're derided for these days. These were smart people making the best decisions they could at the time with what they had available. I don't think the Rust movement thinks that Kernighan and Richie were incompetent. I've never seen anyone say that directly. What they do argue is that new information is available and circumstances have changed which means that some decisions which may have been reasonable are no longer adequate. And this is not new information! One of the books I learned C from was "C Traps and Pitfalls", by Andrew Koenig .. in 1989. The Morris Worm was 1988. While old software often had higher standards for shipping reliability, because you couldn't simply update it over the Internet (or at all on cartridges!), security was not at the same standard because it is much harder to achieve. (There is also what I might call the "we were always against C" faction: people who, even in the 80s, were using LISP or Pascal (1970) or Modula-3 (1988))
- kazinator 2y agoRust portability is to have types like i16, i32 and i64, which is a trick that C programmers have used for decades to dodge real portability. The first machine that see right on didn't even have 16 bit types. The int type was 18 bits. Modern C does not guarantee that the inttypes.h header will make available int16_t or any of the other exact width types. Real portability means not knowing exactly how wide the types is yet making your code work anyway.
- kazinator 2y agoC was not a great leap forward from Algol 68 and what have you.