What you are demonstrating is the userland toolchain. No, what I'm demonstrating is an end-to-end architecture-transparent platform, which includes a complete

What you are demonstrating is the userland toolchain. No, what I'm demonstrating is an end-to-end architecture-transparent platform, which includes a complete userspace toolchain, a universal binary format, and necessary kernel and dynamic linker support. What was suggested above is an improvement by not requiring meddling with the kernel I'm not sure I understand how "meddling" in the kernel is a bad thing when it provides for user-transparent execution of multi-architecture binaries, including transparent emulation of binaries that lack support for the host architecture. It's not as if it's complex or dangerous to parse the Mach-O or FatELF formats, and if you take a page from Mac OS X or qemu, you can even do transparent emulation in userspace. Nothing prevents a userland toolchain for Linux from supporting what you are describing above without kernel modifications. How is it useful to build an easy-to-use multi-architecture binary if the kernel can't actually execute it? Why are you afraid of doing simple parsing[1] of the binary? The kernel already does this -- how do you think ELF loading and shell script execution works? I can imagine this conversation 30 years ago[2] -- "Why should we add shell script shebang parsing/execution support to the kernel? Why not just glue together loader executables that load the shell script" [1] The dead simple Mach-O universal binary loading code: http://fxr.watson.org/fxr/source/bsd/kern/kern_exec.c?v=xnu-1228#L563 http://fxr.watson.org/fxr/source/bsd/kern/kern_exec.c?v=xnu-... [2] The introduction of shebang in UNIX: http://www.in-ulm.de/~mascheck/various/shebang/sys1.c.html http://www.in-ulm.de/~mascheck/various/shebang/sys1.c.html