The main take away from this is that much like the VAX-11/780, all of the processors we run Linux on today have embedded controllers that run first.
In history we see "The VAX-11/780 included a subordinate stand-alone LSI-11 computer that performed microcode load, booting, and diagnostic functions for the parent computer."[1]
In the present, there are many layers of embedded controllers doing essentially the same thing the LSI-11 did for the VAX. In both cases, the main OS has little to no control over those controllers.
Oxide Computers has been making a lot of column inches out of pointing out that those controllers run closed source software so we are losing control of our machines. Linux is running in a simulation at this point, and we should be doing something to fix that.
I honestly think they're the most interesting thing going on in tech at the moment - they're actually creating tech instead of just using it to schedule taxis. I wish I had an ounce of the talent they're looking for, because they're doing the things I love reading about, not the things I end up doing.
However it is precisely the cloud that that is making the OS irrelevant by having containers, language runtimes and type 1 hypervisors, all OS agnostic.
While on the embedded space we are seeing adoption of FOSS OSes with various levels of POSIX compatibility with MIT/BSD/Apache licenses, more appealing to OEMs.
Case in point: AFAIK, some Raptor Computing machines have an ASpeed processor which is powered on first. It then loads the bootROM from a removable flash chip on the motherboard, the bootROM initializes the rest of the hardware and loads BMC from another flash chip on the motherboard. The BMC does whatever hardware initialization still must be done and only then it runs the bootloader. The bootloader (petitboot, I think) scan the drives for bootable media and shows a menu for the user to choose what to boot.
The ASpeed and the POWER computers are somewhat independent after that point. If I had enough money, I'd get one of those machines just for the peculiarities of its hardware.
A small anecdote. We needed to reboot our 11/780. We couldn't find the boot floppy for the LSI-11. An operator found one folded up in a drawer. We un-folded it, tried to "iron out" the creases with our hands, put it in..
the vax booted.
TL;DR those 8" floppies were really well designed. Like DECTAPE, there was a lot of block repeats.
DECTAPE (pdp11 and Dec-10 era) was good. The 11/750s used a small front console tape cassette of some sort which I never liked. I think by that stage the preboot LSI-11 had been miniaturised into something on a board in the main chassis. on the 11/780 it was literally a wart on the inside of one of the front doors, down low with the floppy slot pointing upwards.
I think the ones I worked on were far later in the series.
Monash university (where I didn't work) had 11/780s with very unusual memory boards: they had de-soldered the chips and replaced them with bigger ones, with one leg bent "up" like a cockroach waving hello. These were tied to spare lines on the backplane somehow, to make the machine have double the address space because of "one extra bit" -I suspect they were getting round high cost memory boards from the original source.
"If you're not playing with 36 bits, you're not playing with a full DEC!" -DIGEX (Doug Humphrey), KA10 owner, Pro-PDPer and Anti-VAXer, taunting the 32 bit VAX weenies at DECUS.
I think that's not really true. Thin client handles input and output. Nowadays even websites can work offline on client device. There're plenty of mobile apps which work offline. I don't want to pay for mobile Internet, so my phone works in offline mode usually. I have offline books, offline maps, offline docs and so on. Modern phones are extremely powerful with very fast CPUs and large amounts of RAM. It would be a waste to use them as thin clients.
I think we're moving that way, though. The more ubiquitous high-speed wireless internet gets, the more appealing it sounds to move your computing to a central repository. Stadia was popular and successful even if it didn't show a fat enough profit curve for Google.
All this is great as far as it goes, but I do worry that it's gonna be an excuse, in 10 or 20 years, to start moving basically everything into the cloud, where it can be easily monitored.
I don't have time to look at the included video right now. But based on the excerpted points, I think for modern SOCs there is a good point to all of this. Modern computers are not just a fancy VAX, but they're not truly conceptually like a mainframe either.
The key with a mainframe architecture is abstraction between the components, separate memory spaces, no memory mapped IO, etc.
I'd also say that the Unix (Linux) we use today has more to do with UNIX/32V and 3BSD, than with the Unix that ran on either the PDP-7 or even the PDP-11.
Multiprocessing came into Unix fairly early too, within a year or two of the introduction of the VAX. All that effort was rolled into SysV later.
This disregards the fact that most of the interesting peripherals in the VAX were also computers running firmware.
The distinctions are almost entirely arbitrary, and this is really just another "no true Scotsman" argument, with some "free software" angst tossed in for good measure.
> The key with a mainframe architecture is abstraction between the components, separate memory spaces, no memory mapped IO, etc.
That's what the video was about. That the every component is in a little box with its own OS that communicates via some defined ABI with the box that happens to run Linux that runs your apps.
The talk mentioned in article is ignoring one thing, the people who buy that stuff and want to build "just some compute" want to have a black box to talk to, send their IO requests and get their data back in.
Now that's not to say that part shouldn't be open, but really integrating it into "one OS" isn't that beneficial. Making that open would result in majority (sans GPU and maybe DSP) of the system still run "a tiny piece of code that provides interface for the bigger OS to do its job". About only place where user wants the integration is between compute elements (GPU/CPU/DSP) and even that is mostly just "provide API to the applications", OS can't abstract away interface to make work happen seamlessly, the best it can do is to pass it to the userspace app in consistent way.
I think "just" the open part would be enough honestly. Then the OS stops being limited to interface baked into closed blob and the open driver can innovate on that together with the OS.
I'm not a huge buyer of the "your phone is like a mainframe in your pocket" thing.
Maybe there's deep historical similarities but I think your phone is so much more powerful than most mainframes ever were that the analogy seems misplaced.
Also the software has, well nothing in common at any practical level.
Altogether I don't really see any parallel between phones and mainframes except they're both computers and both run a distant descendant of unix. And I don't recall that many mainframes running unix or even TCP/IP.
They're similar in that they are computers but hey lots of things are.
In history we see "The VAX-11/780 included a subordinate stand-alone LSI-11 computer that performed microcode load, booting, and diagnostic functions for the parent computer."[1]
In the present, there are many layers of embedded controllers doing essentially the same thing the LSI-11 did for the VAX. In both cases, the main OS has little to no control over those controllers.
[1] https://en.wikipedia.org/wiki/VAX