4 ms·

> a platform that's simple enough to stay compatible forever Two things that make this impossible in a general sense: security vulnerabilities, and hardware th

> a platform that's simple enough to stay compatible forever Two things that make this impossible in a general sense: security vulnerabilities, and hardware that fails and is no longer manufactured. It's only possible by defining the forever-platform as a sandbox abstraction, such that the containing layers can be updated for vulnerabilities and hardware. This is what happened with the old game platforms, but even that is leaky. The NES Zapper is at least one case that remains troublesome. More generally, input and display lag always pose a problem and always will, since there always must be some translation layer for hardware that won't exist forever. It's not just a matter of software programming. The hardware matters. For your forever-platform to truly work, it would need to include hardware manufacturing instructions from raw materials. Which is possible, but you can see where it goes out of feasible scope for any commercial endeavors.

kragen 4y ago
I am definitely talking about defining a sandbox abstraction, not mass-producing a piece of hardware. I agree that defining a sandbox abstraction is the only way to achieve what I am proposing. (This has been key to software longevity since ALGOL-60 and the IBM 360's microcoded implementations, but I'm proposing to go a lot further than the IBM 360 did.) I also agree that we have to aim higher than mere commercial endeavors can in order to achieve the forever-platform. Security vulnerabilities at that level are a non-problem. There are no security vulnerabilities in Wirth RISC, in Nock, in Chifir, in the UM, or in the λ-calculus, and there never will be. There probably aren't any security vulnerabilities in uxn/Varvara. None have ever been discovered in the 8086, which is orders of magnitude more complex than what I'm talking about. The 6502 did have some, but they were in the hardware implementation, not the architecture, and are not present in modern 6502 emulators. Input and display lag can be a problem, it's true, but there are many applications that can tolerate a lot of lag. A guitar pedal cares a lot more about lag than a paint program, which cares more than a word processor, which cares more than a compiler. Hardware manufacturing instructions are not needed as long as people have access to some kind of programmable computer on which to implement the forever-platform emulator.
- vikingerik 4y ago
  If you define anything involving timing and lag as out of scope, then yes, any computational sandbox can be run by any computational host with sufficient resources to maintain state, of course. Hardware still matters for input and output. For your platform to run a guitar pedal, you'll need some way to physically get an audio signal in and out if you want it to be of any use.
  - kragen 4y ago
    Agreed. And timing and lag do matter a lot for human–computer interaction. Common platforms won't be able to meet the latency demands of VR/AR rendering or guitar pedals anytime soon even without an extra emulation layer. But I think they can do Voxel Space Comanche or MilkyTracker.

kragen 4y ago

I am definitely talking about defining a sandbox abstraction, not mass-producing a piece of hardware. I agree that defining a sandbox abstraction is the only way to achieve what I am proposing. (This has been key to software longevity since ALGOL-60 and the IBM 360's microcoded implementations, but I'm proposing to go a lot further than the IBM 360 did.) I also agree that we have to aim higher than mere commercial endeavors can in order to achieve the forever-platform. Security vulnerabilities at that level are a non-problem. There are no security vulnerabilities in Wirth RISC, in Nock, in Chifir, in the UM, or in the λ-calculus, and there never will be. There probably aren't any security vulnerabilities in uxn/Varvara. None have ever been discovered in the 8086, which is orders of magnitude more complex than what I'm talking about. The 6502 did have some, but they were in the hardware implementation, not the architecture, and are not present in modern 6502 emulators. Input and display lag can be a problem, it's true, but there are many applications that can tolerate a lot of lag. A guitar pedal cares a lot more about lag than a paint program, which cares more than a word processor, which cares more than a compiler. Hardware manufacturing instructions are not needed as long as people have access to some kind of programmable computer on which to implement the forever-platform emulator.

vikingerik 4y ago
If you define anything involving timing and lag as out of scope, then yes, any computational sandbox can be run by any computational host with sufficient resources to maintain state, of course. Hardware still matters for input and output. For your platform to run a guitar pedal, you'll need some way to physically get an audio signal in and out if you want it to be of any use.
- kragen 4y ago
  Agreed. And timing and lag do matter a lot for human–computer interaction. Common platforms won't be able to meet the latency demands of VR/AR rendering or guitar pedals anytime soon even without an extra emulation layer. But I think they can do Voxel Space Comanche or MilkyTracker.