This post has trivially to do with arm-netbooks.
I'll say, risc architectures would be optimal for an ideal virtual machine that minimizes hardware awareness in userland, which has to do with Urbit, and; has to do with what I perceive Blender could be.
Blender to me, long seemed designed for discovery learning. I perceive that as, 'the [infamous] Blender way'.
Why none could properly document nor tutorial'ize Blender. Always intended as a practical toy. Never to grow-out of...
Until v2.8 .
Violating potential for discovery learning, with a persistent toolbar where previously only the toolbox-selecting-multitool and the window-clone-or-close-multitool persisted, remaining the only tools needing persistence.
Much like the Linux kernel aims for ideal hardware implementation, Blender should aim for ideal graphics processing for any given hardware. Named blender-modes shouldn't exist; only two blender-modes should exist: "Render" (for static media) and "Engine" (for dynamic media). Likewise, as the Linux kernel seeks to maximize its hardware targets, so too should Blender in to perpetuity. Even for hardware unpractical for rendering or compiling, Blender should integrate EVM render and EVM compile, or alternatively SaaSS (but only mainline SaaSS after EVM etcetera, On Principle).
Blender shouldn't integrate a programming environment designed for aspiring programmers; Blender should integrate a "toy language" as a programming environment that aims to enable critical fun and intuition where even seemingly random language assortments generate interesting affects that encourage further exploration.
Like every OS should have boot-to-browser as a function, so too every OS should have boot-to-blender as a function. All the while, both interfaces should encourage discovery learning.
v2.8 removes "game engine" mode, as-if to say "yeah, we're narrowing our scope, so what?" while almost imagining "competing in the here-and-now is more fun than grasping at a future we won't get to witness ourselves".
CC0