Hacker News Reader

Comment by smacktoward | Hacker News Reader

That's the core irony of the PC revolution. PCs started out with the explicit goal of being something different than mainframes and minis. But when people started networking them together, the only way to keep them viable was to essentially turn them into mainframes and minis, just in different shaped boxes. So we've gotten to live through 20 years of PC vendors reinventing things that big-iron users had access to long ago.

View on HN

(The original idea behind) PCs continued to exist long after networking, in the form of video game consoles. A Gameboy Advance isn't all that different from an Apple II or an IBM-compatible PC running DOS: both focus on running one executable and giving it complete control over banging bits toward "rich" I/O devices, where instead of abstractions over ugly low-level interfaces, the peripherals have been designed with nice ABIs that are their canonical APIs (and, until the ARM era, the CPUs themselves were also designed such that their ISA, as written in macro-assembler, was the canonical "high-level" language.)

Of course, eventually game consoles became networked too...

I think it was Casey Muratori who made the argument that we could return to having nice ABIs that are canonical APIs, and still have more than one program running via hardware virtualization features. Then any OS would just be like a hypervisor managing all of the OS-less VMs that, from their perspective, are interacting directly with hardware. It was an interesting idea.

Heck, you can get away with that today, by just creating a virtualization platform like Xen, but with much more carefully-thought-out exposed virtio hypercalls; and then writing unikernels against that interface.

Though, from another perspective, this model is exactly what the "transitional" era of game consoles did. The Nintendo Wii U, for example, normally [i.e. during a game] has a unikernel running across two "application processor" cores, that sees those as the only cores and has direct ownership of the peripherals; but then the OS [running on a third, separate, low-power core that the game VM has no knowledge of] can, at any time, force the game VM into the background with an interrupt, whereupon it must relinquish one of its two cores, some memory, and not touch the peripherals at all until the OS says it's okay; and then the OS can use the borrowed high-power application core, memory, and peripheral-hardware ownership to temporarily foreground an OS modal GUI, like a game manual or a web browser or an instant message.

Sadly, this was all abstracted, for the game developer, behind an HLL [that is, C] SDK—which is sadly a "requirement" in the modern era, given that devs are going to be porting their games to/from PCs.

> I think it was Casey Muratori who made the argument that we could return to having nice ABIs that are canonical APIs

Here's the video I think you're referencing:

https://youtu.be/kZRE7HIO3vk

IIRC he mentions that he actually presented the same content in person to staff at Intel, and discusses how it's very hard to get any buy-in even if the engineers consider the approach to make sense.

One interesting part was that it had to become 10x to 100x cheaper to become viable on the PC platform: FPU, MMU, hardware virtualization, vector processors (aka GPUs), etc. It was possible for quite some time thanks to the Moore law.

And VMs that IBM invented on mainframes.

And containers that IBM invented on mainframes.

I don’t think “reinventing” is entirely fair. Along the way, the PC vendors made this technology affordable for the masses. That’s huge.

Including bytecode as executable format, with various ways to convert it into actual machine code before execution.

Reply on news.ycombinator.com