I think Cosmopolitan support on OpenBSD is broken (since 7.5?). And IIRC it also conflicts with WINE on Linux without explicit binfmt support. It's amazing and laudable that Cosmopolitan managed to thread the needle the way that it did, but it's also entirely unsurprising that it's been broken; and even if fixed would be broken again.
Unless something has changed since I last looked at it, cosmopolitan depends directly on the host's raw syscall interface everywhere but Windows (on Windows, it correctly dispatches syscalls through supported userspace libraries, e.g. `kernel32.dll`).
This is unsupported, undocumented, and unstable on every target cosmopolitan supports other than Linux — macOS and (Free|Net|Open)BSD define their syscall ABI as private and subject to arbitrary change, and they do change it. The only supported syscall interface is via their userspace libraries, and binaries that target the syscall ABI directly will fail on future releases.
Furthermore, while cosmopolitan binaries are multi-arch (amd64/arm64 currently) and multi-OS (Linux/Windows/macOS/...), they are arch-specific and OS-specific. Once support for a new target has been added to cosmopolitan, existing binaries must be rebuilt to include it; existing binaries cannot run simply by porting a common runtime.
On top of all that, the APE executable format relies on ill-defined fallback heuristics — which may or may not be implemented by a shell — for executable files that fail with ENOEXEC after first calling `exec()`, but look like they may be '#!'-less shell scripts. Unsurprisingly, this is unreliable, depends on the user's shell, and means that programmatically executing an APE executable using `exec`, `posix_spawn()`, etc, will simply fail.
Cosmopolitan is neat hack, but it's not a viable multiplatform executable format, runtime sysytem, or distribution mechanism. Something like WASM + WASI seems much more likely to fulfill this function in the future.
> Cosmopolitan is neat hack, but it's not a viable multiplatform executable format, runtime sysytem, or distribution mechanism.
It's the best we have to ensure programs will be kept running. The multiple payloads are like a rosetta stone.
If I had 1 wish, I would make wine support sixel output + VNC to a localhost port + webgl or equivalent to extend this redundancy to GUIs
> Something like WASM + WASI seems much more likely to fulfill this function in the future.
Time will tell, but given 2 binaries (Sun Java vs Windows i386) from the same time period, the one that was "much more likely to fulfill this function in the future" is much harder to use
p-code is a neat technology, but failing at what it was supposed to achieve
Cosmopolitan is very impressive indeed, although it is a very different approach than byte code systems like the p-System, Java, and .NET. Each approach has its merits.
wahern|10 months ago
frumplestlatz|10 months ago
This is unsupported, undocumented, and unstable on every target cosmopolitan supports other than Linux — macOS and (Free|Net|Open)BSD define their syscall ABI as private and subject to arbitrary change, and they do change it. The only supported syscall interface is via their userspace libraries, and binaries that target the syscall ABI directly will fail on future releases.
Furthermore, while cosmopolitan binaries are multi-arch (amd64/arm64 currently) and multi-OS (Linux/Windows/macOS/...), they are arch-specific and OS-specific. Once support for a new target has been added to cosmopolitan, existing binaries must be rebuilt to include it; existing binaries cannot run simply by porting a common runtime.
On top of all that, the APE executable format relies on ill-defined fallback heuristics — which may or may not be implemented by a shell — for executable files that fail with ENOEXEC after first calling `exec()`, but look like they may be '#!'-less shell scripts. Unsurprisingly, this is unreliable, depends on the user's shell, and means that programmatically executing an APE executable using `exec`, `posix_spawn()`, etc, will simply fail.
Cosmopolitan is neat hack, but it's not a viable multiplatform executable format, runtime sysytem, or distribution mechanism. Something like WASM + WASI seems much more likely to fulfill this function in the future.
csdvrx|10 months ago
It's the best we have to ensure programs will be kept running. The multiple payloads are like a rosetta stone.
If I had 1 wish, I would make wine support sixel output + VNC to a localhost port + webgl or equivalent to extend this redundancy to GUIs
> Something like WASM + WASI seems much more likely to fulfill this function in the future.
Time will tell, but given 2 binaries (Sun Java vs Windows i386) from the same time period, the one that was "much more likely to fulfill this function in the future" is much harder to use
p-code is a neat technology, but failing at what it was supposed to achieve
mbessey|10 months ago
_mlbt|10 months ago
detourdog|10 months ago