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
