Cosmopolitan v3.5

Original Article ↗ Hacker News Discussion ↗

Cross‑platform and architecture support

  • Cosmopolitan (Cosmo) binaries can be “fat” APE executables that run on both amd64 and arm64, including modern macOS on Apple Silicon.
  • The same binary can run across multiple OSes (Linux, macOS, FreeBSD, Windows, etc.), sometimes as a native binary, sometimes via being parsed first as a shell script.
  • There are edge cases: some Linux distros (e.g., CentOS/Rocky 8, certain ARM64 kernel configs) still have issues; a fix for older address-space assumptions helped but didn’t solve all cases.
  • Android kernel support exists at the binary level; app-level integration is unclear.

Mechanics, POSIX changes, and APE polyglots

  • APE binaries are polyglot: valid DOS/PE/ELF/Mach‑O plus shell script headers.
  • POSIX shell rules were relaxed to allow binary data after an initial shell-parsable region, enabling this trick.
  • There’s debate whether POSIX “approves” the specific implementation; some argue the spec text doesn’t fully sanctify APE-style payloads.

Use cases and projects

  • Notable uses: llamafile (portable LLM runner), redbean (single-file web server with Lua), and demos like portable Python and GNU tools.
  • WAMR (a WASM runtime) has Cosmo support, enabling higher-level stacks like Hermit.
  • People are interested in portable GUI stacks via embedded web UIs, Java/Graal Native, and potential Python single-file tools.

Performance, libc design, and comparisons

  • Cosmo focuses on fast, static, cross‑OS binaries and a self-hosting toolchain (cosmocc).
  • Claims: 2× faster than musl for many CLI workloads due to vectorized string routines; fast malloc with per-core arenas for threaded code.
  • Some benchmarks (e.g., rsync on Windows) show slow real-world performance, but others attribute this to Windows I/O rather than Cosmo itself.
  • The C++ STL is being “reinvented” to reduce include bloat and drastically improve compile times.

Skepticism, stability, and standards conformance

  • Enthusiasts see Cosmo as a way to avoid heavy runtimes (JVM, Node, Electron) and to ship “download once, run anywhere” binaries.
  • Skeptics worry about:
    • Reliance on loader/ABI corner cases that may break on future OS releases.
    • Non‑conforming libc behavior vs POSIX/glibc.
    • Long‑term production suitability.
  • Others counter that Cosmo now avoids many brittle tricks (e.g., MAP_FIXED), depends on stable ABIs, and aims for longevity.

Alternatives and open questions

  • Comparisons to WebAssembly: Cosmo uses native CPU code (faster) vs VM bytecode; WASM still attractive for some.
  • Questions remain about GPU support, broad binfmt integration across Linux distros, and whether Cosmo will see widespread mainstream adoption.