As a retro enthusiast, I've been asked "why bother with old technology" a few times and, in my opinion, the best answer is simply "because I like it". There are probably some underlying objective reasons behind that which I'm not consciously aware of (like maybe studying old technology makes me a better tech person today, some kind of indirect pedagogical effect), but I can't really pinpoint that specifically, and it can be a bit tiresome sometimes. Next time I guess I'll link them to this article!
Got any recommendations for a good vintage computer to get started with that's more advanced than the C64? I took a course on C64 assembly and it was pretty good but I wanted to learn something a bit more complex but not as complex as a modern architecture.
Any of the 68000-based machines may be worth a look. Atari ST, Amiga 500/1000, early Macs. There are also SBCs available that use the 68K.
An early-ish 8086/8088 PC clone is a possibility, but the Atari/Amiga/Macs will have better graphics options and won't have segment/offset memory addressing.
I'm thinking an eighties workstation like a Sun 3. If you can find one, an SGI Indigo or early NeXT cube. Much closer to an Amiga than to a modern system, but even more funky and exotic hardware.
I wouldn't consider an X server running on one of those "still useful" but others might disagree.
I used an IBM PPC-based 43P as a work machine for some time. It can't run a modern browser, but back then using NetBeans running on my laptop was perfectly doable. Using Emacs and a terminal will work really well. Using one of these machines as a workstation is not much different from an older Raspberry Pi - you'll need to do the heavy lifting on the other side of the network anyway.
The killer feature of this specific 43P was that it came with a gargantuan Intergraph CRT monitor.
I'll add to the other suggestions with any of the Acorn Risc OS line[1].
They're the original Arm based computers (not counting the development processor for the BBC Micro) and some of the earliest system on a chip computers.
Might be fun if you fancy playing with Arm assembly language.
I’ve been working on getting a Macintosh II to boot A/UX a sys v Unix. My eventual goal is to use it for doing the K and R C exercises, and just generally see what Unix was like.
AU/X was a pretty weird Unix, an SVR2 base with various SVR3 and BSD bits bolted on, all topped off with a mostly-functional (classic) MacOS 7 emulation layer. It wasn't much like other, contemporary Unixen. I did some rather serious time with it in a previous life, and really grew to hate it.
SCO Unix (or OpenDesktop or whatever they're calling it now) would be an example of a 'state of the art' x86 Unix before Linux matured. I, however, was always more fond of Dell Unix SVR4 for x86; a more 'pure' Unix. Install images are 'around'. It's new enough to be familiar and comes with a bunch of extras (like a pile of ported GNU tools). Interactive or Microport SVR3 are a little more old-skewl, if that's where you're at. Xenix is very old school, and shows you what you can to with very limited x86 hardware (esp Xenix for the 8086 or 80286), and you'll find a lot of tools you might want don't compile for various reasons (like a K&R C compiler). Other folks shipped an x86 SVR3 or SVR4, but they generally added very little to the AT&T code base.
If you go the emulated route (e.g. SIMH), I'd go with BSD 4.3 or Sun SunOS 3.5. That's where I started out with Unix so there's a lot of nostalgia there.
Not quite sure what you're after but you can get a Voyage 200 graphing calculator for not much more than a RasPi now - it's got a Motorola 68000, a qwerty keyboard, a sunlight-readable screen, a serial jack, a useful OS with many games, a C IDE, a disassembler (both onboard!)... and it runs on 4 alkaline batteries.
One possible advantage is that it can be easier to learn the fundamentals when they aren't as obscured by as many later layers of smoothing over and/or complexity. For instance, it's very common for schools to teach assembler based on older tech, because it's simpler to deal with. Older tech will more directly expose you to the underlying issues with the foundations of the technology.
For an example of something that smooths a lot of things over, using a nice, high-level USB library is abstracting away a huge amount of the issues involved with that sort of signaling. If you want to deeply understand how computers communicate with each other over wires, you're probably better off studying RS-232 first.
When I was first learning how to program I felt this way. High level languages were unsettling in that I knew they were doing a ton of "stuff" but I didn't know what. Old 8-bit micros get you closer to understanding how computers work.
I've been doing web development since the late 1990s. I don't know every fiddly detail of every current web technology, but I can pretty much pick up any of them, read the docs for an hour, and have them going in just a bit more time, because I've got a solid foundation from working on things back when even XMLHTTPRequest was but a fever dream.
I was recently speaking online to someone trying to get into it from a fresh start, and they lent me their perspective (kinda like a rubber duck debugging session), and I was a bit appalled at how hard it is to get into web development at this level now. I ended up recommending an approach in which one recapitulates the browser's development cycle if you want to really understand what's going on out there... it isn't the best choice technically in the short term because it's a long path to tread just to do "this one thing", but if you want to be similarly flexible and know how to work with the mess of technologies out there, for path-dependent and historically-contingent reasons (that is, opposed to any other good reasons), I think it may still be the best way to go.
And to be honest, there's still a lot you can do with server-side generated HTML, the tags in modern HTML, and a bit of pure Javascript. There are good reasons to move beyond that; I don't mean that in a "back in my day" sort of way. But if you do start there, the rest of the stack makes a lot more sense than trying to start directly with React as your first intro to the web, as fine as React may be.
I'm learning web dev right now, after not having really touched it since about the turn of the century.
I bounced off of React & friends a few times before discovering the Lean Web movement. I'm genuinely happier for having found it. As a beginner, things like React and Elm feel opaque and obscenely complicated, all in order to solve problems that I don't actually have. Vanilla HTML+CSS+JS offers a much more pleasant learning curve, and has made it a fair bit easier to maintain momentum as I learn. From what I can tell, I'll probably also be able to take them really, really far before I need to adopt a front-end framework.
I'm actually kind of wondering, now that I am more familiar with the history of the technology, if the continuing popularity of front-end frameworks is largely a hold-over from an earlier time when Web standards were weaker. Vanilla JavaScript and CSS have become a lot more capable over the past few years, but dropping back down to them may be technically or socially difficult. It's always easier to add more things to the pile than it is to take them away. Sunk costs and all that.
I learned pdp-11 assembler (in octal) and I think it is one of the most consistent/orthogonal instruction sets I've ever used. Maybe they cleaned up pdp-10?
I'm not familiar with 6800, but I've heard people rave about 6809. I did do some 68000, and it was pretty good too.
Oh, and IBM 370 type assembly is pretty interesting too, and very high level. for example, I think they could pretty much 1:1 map fortran statements to assembly statements. I also vividly recall the 4-register block move with pad - src addr, src len, dest addr, dest len, and pad was a high-order byte in one of them.
One fascinating feature of some old computers like the 8-bit Commodores and Ataris are the intelligent peripherals. The computer wouldn’t need to wait for IO operations as long as the data would fit in the peripheral’s buffers.
One thing I've never truly appreciated until I started reading the Dolphin Blog [0] is the many nuances physical hardware has, AND how software developers often leverage these nuances (which aren't typically reproduced, for example, with an emulator). With this perspective, I think we should memorialize old tech.
being poor and unable to transition, and also you just might not want a cop in your home. fucking libera.chat troll admins called me anprim. fucking idiots
Older technology is extremely practical for teaching (yourself or others) because it's (mostly?) simpler than what exists today.
For example writing an emulator for an older 8-bit CPU will be a simple problem overall to tackle than x86.
That said, sometimes using modern technology is better for teaching since there are more tools and resources that exist today to help you learn today's technology than there are for older technology.
So it depends. But it's definitely worth not completely ignoring old technology when learning a topic in case the older tech _is_ easier to learn because it's simpler.
Sometimes older technology is easier to develop for, mostly because there's more documentation, more stack overflow discussions, better understanding of quirks, ect.
I used to have an old 5150 (recently sold, as it’s not my particular retro niche). The source code for the BIOS was listed in the manual for the machine. I was mildly and pleasantly surprised. I suppose a modern equivalent would be the firmware source code for your motherboard being downloadable from the vendor. I guess there’s edk2, but I’d be content never to touch that again.
A lot of this is complexity. The underlying systems are so complex that it is not really practical to try to explain them to the end user. But another part of this is political. Some parts are hidden on purpose to support features like DRM or to preserve a vendor's trade secrets.
I play around a lot with retro networking and have exposed myself to all sorts of old protocols, technologies, etc. that maintain my interest much more than the IP monoculture of today.
Also I get to practice skills I otherwise wouldn’t. I’ve done more hardware hacking reverse engineering in retro stuff than modern stuff, partially because it’s simpler, partially because I actually have a real goal or objective, versus just doing something for rote.
Every age, this age not excepted, has programmers who somehow find the energy to go out of their way to advocate for writing non-portable code.
"Who cares if it doesn't run on 80386?"
"Who cares if it doesn't run on PowerPC?"
"Who cares if it doesn't run on 64 bit?"
"Who cares if it doesn't run on ARM?"
And now: "Who cares if it doesn't run on 32 bit?"
They write code that makes assumptions about endianness, about sizes of pointers, about floating point formats, and then come up with rationalizations about why it shouldn't matter if their code only compiles and runs on one architecture.
If we had taken all of them at their word, every architectural upgrade would require a rewriting of a majority of software instead of a recompile, and the open source world would be vastly different, and not in a good way.
Old technology is a way to teach people about our roots, how our current path was informed by those roots, the lessons learned from mistakes, and the lessons learned from the successes.
Not disagreeing at all with your well expressed point, but: I wrote code to fully utilize the machines I had at the time. When new systems became available, the code needed to be re-written to fully exploit the new just as much as it needed to be de-crufted from the obsolete.
Code that has been functional, untouched, for decades has a nobility; but a job that has been worth re-coding the solution every few years is actually important.
I think you're maybe framing it the wrong way around. It often takes more energy to write portable code than non-portable code.
"This isn't something I want to spend my time on" isn't a rationalization, it's a simple statement of preference. I personally feel absolutely no cognitive dissonance or regret about all the hand-coded PPC I wrote a couple decades ago, nor do I accept someone else wanting me to feel bad about it. It was (and needed to be) optimized for the machine I was working on at the time, and if I were moving it to a new platform, I probably would have wanted to do the same for it, too. As it turns out, though, the need never arose. The code was abandoned before the platform was. In short, YAGNI.
Similarly, "This isn't a worthwhile expenditure of our company's resources," isn't a rationalization, it may be a simple statement of business reality. To take a simple example, a video game studio producing an exclusive title has very different incentives around code portability than an indie studio that plans to release on 5 different platforms. What's the point of developing your game to work on iOS if you have no plans to - and may even be contractually not allowed to - release it on that platform?
Long ago I discovered that people don't get emotionally invested in your little perf- or platform-specific hacks if they don't have to look at them.
With function inlining, you can often move your little weirdo bit of code into a function that is off the main call path and if people don't like it, they don't have to look at it. Also the fact that your change is in a single commit means they can always revert it if they don't like it (a bluff almost nobody calls).
More importantly, when it comes time to port the code, the intent of your weird little code is both known and self-contained. They can decide what to do about it and have a path to do it.
When your clever tweaks are peppered throughout your data architecture and half of the code base, then porting is a costly affair. And in some cases just updating your tools is hampered as well.
It's true. Though I suspect that the proportion of code whose portability is hampered by clever code like this is vanishingly small compared to the volume of code whose portability is hampered by things like, "assumes POSIX-style file handling", "makes lots of DOS syscalls", or "targets AVR microcontrollers."
Most software doesn’t live very long, and opportunity costs can be huge. For every Minecraft ported to every platform there are several Atari 2600 games that nobody cared about.
Creating emulators today is vastly better use of resources than anyone writing ancient console games considering long term portability issues.
Well, do you really care if your web application or mobile application runs on an 80386?
But, to get more practical: The wider your compatibility surface is, the harder and more time consuming your software is to write.
I once worked on a C# desktop product in the early 2010s where we had a requirement to support Windows XP. This prevented us from using newer features in C#, like the task API, which added a lot of complexity to our UI code. (It's much easier to write UI code in C# when you can "await" in one line instead of dealing with callbacks.)
Another drawback (of remaining compatible with Windows XP) was that we had to stick with an old version of .Net, which had bugs. Specifically, we were making a XAML UI, but XAML support in .Net for Windows XP was buggy.
Furthermore, we had to test our product on Windows XP, in addition to both 32-bit and 64-bit versions of Vista, 7, and 8.
Eventually product management realized that it cost more to support Windows XP than the additional sales it would make, so they dropped the requirement.
So, yes, "Who cases if it doesn't run on XYZ." Supporting "everything" often has real consequences and real costs.
"This code only has to run on the 1401, when we get a new system it won't be compatible, so it won't be around long anyway. Next time we'll write a better version incorporating our experience from this one, and taking advantage of the new hardware."
Then IBM System 360 made things backward compatible, and the world broke. We saved tons of programmers time, and Y2K was a secondary effect of those savings.
when I work on old machines, I often get an overwhelming feeling that modern machines are wasteful. there was so much room to be clever and careful, but instead we just kept throwing more hardware at our problems
You of course know this already but it's not the machines that are wasteful, but rather the software we run on them and - by extension - the developers who create that software.
UI latency is a never ending source of frustration to me, in large part, because it simply shouldn't exist with the computing power we have at our fingertips.
On the other hand we have Microsoft Outlook and Microsoft Teams that are both absolute bastions of waste and instability. And not just in compute terms either, but in terms of my time - the finite number of breaths and heartbeats I have left - that is squandered in waiting around, restarting, rebooting my machine, because of these unstable, crashy behemoths.
It is true. Too much fancy animations, too much other stuff internally too, wastes energy. Also bad user interfaces, and bad documentation, and too complicated designs, and many other problems. I prefer without all of that stuff; it looks better to me and can be worked better too if it is done in the less wasteful way, I think.
This article talks about hardware, but for me it raises software equivalents in mind. Lately, I've been looking at Datalog. It's an old ass query language that's found a slight resurgence in specific niches.
Sometimes, old ideas are not fully known or understood, as our field is relatively new. Going back to the writings of Engelbart or Papert, I've discovered some new things about original intent that the first implementations missed.
My use of old computing technology is really in support of old music synthesizer technology. For instance my Yamaha VL1, one of the first and greatest waveguide physical modeling synthesizers, does not allow full editing of the model parameters from the keyboard itself. Yamaha made a few editors for it that use MIDI SYSEX to edit the models. Unfortunatley those only run on MacOS System 7. So I have to keep an ancient mac for that.
Many of my synths use 3.5" floppies. The ones that use FAT formatting can easily be used with a USB floppy on a modern computer, but the ones that have their own proprietary disk formats (most of them) require software with direct access to the floppy that can't be got through a USB connection. So, for those, I have an old Windows laptop with built-in floppy and software like Omniflop to manage those disks.
Probably one of the greatest things to make old tech more manageable (for me) is the SCSI2SD project, which makes an SD card into a SCAI device. Since SCSI was hugely popular with classic samplers (synths that can record audio and use the recorded audio as the sound source in the synth sound) I have a half dozen SCSI2SD drives so I don't have to keep ancient parallel SCSI dive alive.
I collect things like old Mp3 players because they are interesting examples of product design and UX design. But mostly it's because I just think they're neat.
I don't know if "technology" is limited to digital tech, but I am having a lot of fun working on vintage analog gear, specifically tube amps. It helps me think about totally different types of engineering problems than my day-to-day work.
I realise everyone is probably already aware but Adrian's Digital Basement on youtube is a lot of fun to watch. I don't have access to the hardware or diagnostics that he has but I really appreciate remembering what things were like 30 years ago. Electronics is fun!
There’s a sayings, the C language was developed to compile for the PDP-11.
In the meantime much has happened. So Modern processors were designed to seamlessly run existing software.
For example Memory used to be fated the processors clock cycles so fetches were free. Now it’s 100x slower. So we put caches in to fool the software into thinking it’s just as fast as it used to be.
So all software runs in a bubble like it was still running on a PDP-11.
Just like the body continues to carry around a liquid environment with a salinity level equal to the ancient ocean.
58 comments
[ 2.7 ms ] story [ 151 ms ] threadAn early-ish 8086/8088 PC clone is a possibility, but the Atari/Amiga/Macs will have better graphics options and won't have segment/offset memory addressing.
But then they aren’t much simpler than our modern desktops running their own Unixes.
I wouldn't consider an X server running on one of those "still useful" but others might disagree.
The killer feature of this specific 43P was that it came with a gargantuan Intergraph CRT monitor.
They're the original Arm based computers (not counting the development processor for the BBC Micro) and some of the earliest system on a chip computers.
Might be fun if you fancy playing with Arm assembly language.
https://en.wikipedia.org/wiki/RISC_OS
https://en.wikipedia.org/wiki/Acorn_Archimedes#Later_A-serie...
https://en.wikipedia.org/wiki/Risc_PC
[1] I say Risc OS but they actually also supported a Unix like called Risc ix.
There are some resources here if you’re curious and want to see screenshots. (Not my site)
What did you use A/UX for?
If you go the emulated route (e.g. SIMH), I'd go with BSD 4.3 or Sun SunOS 3.5. That's where I started out with Unix so there's a lot of nostalgia there.
For an example of something that smooths a lot of things over, using a nice, high-level USB library is abstracting away a huge amount of the issues involved with that sort of signaling. If you want to deeply understand how computers communicate with each other over wires, you're probably better off studying RS-232 first.
But then I did some programming for a 6800 with something like 40 simple instructions, and I "got it", and the -10 became simple, too.
I was recently speaking online to someone trying to get into it from a fresh start, and they lent me their perspective (kinda like a rubber duck debugging session), and I was a bit appalled at how hard it is to get into web development at this level now. I ended up recommending an approach in which one recapitulates the browser's development cycle if you want to really understand what's going on out there... it isn't the best choice technically in the short term because it's a long path to tread just to do "this one thing", but if you want to be similarly flexible and know how to work with the mess of technologies out there, for path-dependent and historically-contingent reasons (that is, opposed to any other good reasons), I think it may still be the best way to go.
And to be honest, there's still a lot you can do with server-side generated HTML, the tags in modern HTML, and a bit of pure Javascript. There are good reasons to move beyond that; I don't mean that in a "back in my day" sort of way. But if you do start there, the rest of the stack makes a lot more sense than trying to start directly with React as your first intro to the web, as fine as React may be.
I bounced off of React & friends a few times before discovering the Lean Web movement. I'm genuinely happier for having found it. As a beginner, things like React and Elm feel opaque and obscenely complicated, all in order to solve problems that I don't actually have. Vanilla HTML+CSS+JS offers a much more pleasant learning curve, and has made it a fair bit easier to maintain momentum as I learn. From what I can tell, I'll probably also be able to take them really, really far before I need to adopt a front-end framework.
I'm actually kind of wondering, now that I am more familiar with the history of the technology, if the continuing popularity of front-end frameworks is largely a hold-over from an earlier time when Web standards were weaker. Vanilla JavaScript and CSS have become a lot more capable over the past few years, but dropping back down to them may be technically or socially difficult. It's always easier to add more things to the pile than it is to take them away. Sunk costs and all that.
I'm not familiar with 6800, but I've heard people rave about 6809. I did do some 68000, and it was pretty good too.
Oh, and IBM 370 type assembly is pretty interesting too, and very high level. for example, I think they could pretty much 1:1 map fortran statements to assembly statements. I also vividly recall the 4-register block move with pad - src addr, src len, dest addr, dest len, and pad was a high-order byte in one of them.
[0] https://dolphin-emu.org/blog/
For example writing an emulator for an older 8-bit CPU will be a simple problem overall to tackle than x86.
That said, sometimes using modern technology is better for teaching since there are more tools and resources that exist today to help you learn today's technology than there are for older technology.
So it depends. But it's definitely worth not completely ignoring old technology when learning a topic in case the older tech _is_ easier to learn because it's simpler.
I play around a lot with retro networking and have exposed myself to all sorts of old protocols, technologies, etc. that maintain my interest much more than the IP monoculture of today.
Also I get to practice skills I otherwise wouldn’t. I’ve done more hardware hacking reverse engineering in retro stuff than modern stuff, partially because it’s simpler, partially because I actually have a real goal or objective, versus just doing something for rote.
Indeed - recently discovered the Transputer and Connection Machine and their attempts to build and code parallel machines!
More modern examples of retro tech include Chuck Moore's GA144 a forth based 144 core asynchronous chip
"Who cares if it doesn't run on 80386?"
"Who cares if it doesn't run on PowerPC?"
"Who cares if it doesn't run on 64 bit?"
"Who cares if it doesn't run on ARM?"
And now: "Who cares if it doesn't run on 32 bit?"
They write code that makes assumptions about endianness, about sizes of pointers, about floating point formats, and then come up with rationalizations about why it shouldn't matter if their code only compiles and runs on one architecture.
If we had taken all of them at their word, every architectural upgrade would require a rewriting of a majority of software instead of a recompile, and the open source world would be vastly different, and not in a good way.
Old technology is a way to teach people about our roots, how our current path was informed by those roots, the lessons learned from mistakes, and the lessons learned from the successes.
Code that has been functional, untouched, for decades has a nobility; but a job that has been worth re-coding the solution every few years is actually important.
"This isn't something I want to spend my time on" isn't a rationalization, it's a simple statement of preference. I personally feel absolutely no cognitive dissonance or regret about all the hand-coded PPC I wrote a couple decades ago, nor do I accept someone else wanting me to feel bad about it. It was (and needed to be) optimized for the machine I was working on at the time, and if I were moving it to a new platform, I probably would have wanted to do the same for it, too. As it turns out, though, the need never arose. The code was abandoned before the platform was. In short, YAGNI.
Similarly, "This isn't a worthwhile expenditure of our company's resources," isn't a rationalization, it may be a simple statement of business reality. To take a simple example, a video game studio producing an exclusive title has very different incentives around code portability than an indie studio that plans to release on 5 different platforms. What's the point of developing your game to work on iOS if you have no plans to - and may even be contractually not allowed to - release it on that platform?
With function inlining, you can often move your little weirdo bit of code into a function that is off the main call path and if people don't like it, they don't have to look at it. Also the fact that your change is in a single commit means they can always revert it if they don't like it (a bluff almost nobody calls).
More importantly, when it comes time to port the code, the intent of your weird little code is both known and self-contained. They can decide what to do about it and have a path to do it.
When your clever tweaks are peppered throughout your data architecture and half of the code base, then porting is a costly affair. And in some cases just updating your tools is hampered as well.
Creating emulators today is vastly better use of resources than anyone writing ancient console games considering long term portability issues.
But, to get more practical: The wider your compatibility surface is, the harder and more time consuming your software is to write.
I once worked on a C# desktop product in the early 2010s where we had a requirement to support Windows XP. This prevented us from using newer features in C#, like the task API, which added a lot of complexity to our UI code. (It's much easier to write UI code in C# when you can "await" in one line instead of dealing with callbacks.)
Another drawback (of remaining compatible with Windows XP) was that we had to stick with an old version of .Net, which had bugs. Specifically, we were making a XAML UI, but XAML support in .Net for Windows XP was buggy.
Furthermore, we had to test our product on Windows XP, in addition to both 32-bit and 64-bit versions of Vista, 7, and 8.
Eventually product management realized that it cost more to support Windows XP than the additional sales it would make, so they dropped the requirement.
So, yes, "Who cases if it doesn't run on XYZ." Supporting "everything" often has real consequences and real costs.
"This code only has to run on the 1401, when we get a new system it won't be compatible, so it won't be around long anyway. Next time we'll write a better version incorporating our experience from this one, and taking advantage of the new hardware."
Then IBM System 360 made things backward compatible, and the world broke. We saved tons of programmers time, and Y2K was a secondary effect of those savings.
UI latency is a never ending source of frustration to me, in large part, because it simply shouldn't exist with the computing power we have at our fingertips.
On the other hand we have Microsoft Outlook and Microsoft Teams that are both absolute bastions of waste and instability. And not just in compute terms either, but in terms of my time - the finite number of breaths and heartbeats I have left - that is squandered in waiting around, restarting, rebooting my machine, because of these unstable, crashy behemoths.
Sometimes, old ideas are not fully known or understood, as our field is relatively new. Going back to the writings of Engelbart or Papert, I've discovered some new things about original intent that the first implementations missed.
Many of my synths use 3.5" floppies. The ones that use FAT formatting can easily be used with a USB floppy on a modern computer, but the ones that have their own proprietary disk formats (most of them) require software with direct access to the floppy that can't be got through a USB connection. So, for those, I have an old Windows laptop with built-in floppy and software like Omniflop to manage those disks.
Probably one of the greatest things to make old tech more manageable (for me) is the SCSI2SD project, which makes an SD card into a SCAI device. Since SCSI was hugely popular with classic samplers (synths that can record audio and use the recorded audio as the sound source in the synth sound) I have a half dozen SCSI2SD drives so I don't have to keep ancient parallel SCSI dive alive.
In the meantime much has happened. So Modern processors were designed to seamlessly run existing software.
For example Memory used to be fated the processors clock cycles so fetches were free. Now it’s 100x slower. So we put caches in to fool the software into thinking it’s just as fast as it used to be.
So all software runs in a bubble like it was still running on a PDP-11.
Just like the body continues to carry around a liquid environment with a salinity level equal to the ancient ocean.