[TimTheTinker]

> From what I've read of her in the past she seems to be a pretty damn good developer. But in the open source world those are a dime a dozen

Not exactly. Very few people in recent decades have achieved anything comparable to αcτµαlly pδrταblε εxεcµταblε and Cosmopolitan libc - they're in the category of "that should not even be possible". Of course, Tunney's work doesn't touch Fabrice Bellard in terms of sheer breadth and impact, but they're arguably in the same category.

[crote]

The concept of a polyglot[0] has been around for ages: the Wikipedia page mentions an 8-language one going around on Usenet in the 1990s. If it works for source code, and for scripting languages, and for things like PDF+ZIP, why wouldn't there be a pretty good chance the various executable formats are flexible enough to allow for it too?

A libc which is flexible enough to select specific code paths depending on runtime conditions? Every libc already does this to make use of the latest hardware features[1], using the same approach for platform-specific code isn't a huge stretch - you're basically doing a lightweight WINE.

Her work is definitely impressive, but it isn't magic. You'll see similar stuff if you look into the demoscene, or the IOCCC, or a decent chunk of the talks at CCC. And it's not like APE and Cosmo libc are seeing massive adoption: the people who want portability but can't even compile for multiple platforms are probably happier with something like Java due to the better ecosystem support.

[0]: https://en.wikipedia.org/wiki/Polyglot_(computing)

[1]: https://www.phoronix.com/news/Glibc-More-AVX-512-October-202...

[TimTheTinker]

Yes, polyglot binaries are a straightforward extension of the notion of polyglot source code to binary executable files. But APE/Cosmopolitan takes this to insane levels:

- a fully cross-platform libc with cross-platform support built into the output binary, integrated into clang and gcc toolchains

- not just cross-platform, but also cross-architecture: output binaries work unmodified on both AMD64 and ARM64 architectures

- sheer number of executable format compatibilities: it's a polyglot across macOS, linux, windows, 3 BSDs, and a bootable BIOS target

- polyglot not just for executable outputs, but also for PKZIP. You can open and modify an executable using common zip file editors. And post-hoc zipped-in data can be accessed/modified by code in the executable using interfaces in cosmopolitan libc

- Zip polyglot can be used to create portable embeddable code-packaged interpreters where the code being interpreted is loaded/executed from zipped-in data. One example: RedBean is a very high-performance APE-packaged web server that serves data in its zip archive and hosts web service code from Lua scripts in its zip archive. Built-in library enables Lua code to store/retrieve data from zipped-in SQLite databases.

The comparison to the demoscene and IOCCC is apt, but this is at another level because it's all production-ready. The Llamafile format is an APE binary compiled with Cosmopolitan libc with model weights zipped into it.

[saagarjha]

APE is too much of a hack to be called "production-ready". It works, but there really is not much guarantee it will continue to do so.

[TimTheTinker]

There's an "ape loader" that speeds up loading the executable on various platforms -- that will guarantee it continues to work, as it can evolve with the platform to continue support for binary format.