1205 points by jart 851 days ago | 240 comments on HN
| Moderate positive
Contested
Editorial · v3.7· 2026-02-28 11:38:59 0
Summary Open Source Freedom & Knowledge Access Advocates
This technical announcement for Cosmopolitan Third Edition engages moderately with human rights through its open source development model, which actively promotes information freedom, community participation, and educational access. While the content itself does not directly address UDHR provisions, the project's practices—transparent development, freely distributed software and documentation, collaborative innovation structures, and public community mechanisms—actively support Article 19 (expression/information), Article 20 (assembly/association), Article 26 (education), and Article 27 (scientific participation).
> The end result is that if you switch your Linux build process to use cosmocc instead of cc then the programs you build, e.g. Bash and Emacs, will just work on the command prompts of totally different platforms like Windows and MacOS, and when you run your programs there, it'll feel like you're on Linux. However portability isn't the only selling point. Cosmo Libc will make your software faster and use less memory too. For example, when I build Emacs using the cosmocc toolchain, Emacs thinks it's building for Linux. Then, when I run it on Windows:
> It actually goes 2x faster than the native WIN32 port that the Emacs authors wrote on their own. Cosmo Emacs loads my dotfiles in 1.2 seconds whereas GNU Emacs on Windows loads them in 2.3 seconds.
Will it allow native like bash script support on Windows? I use windows as my main OS and use cmder for CLI things but really miss proper bash script support.
Other than bash itself, does it mean it can be used to make whole set of GNU tools cross platform?
https://github.com/jart/cosmopolitan/releases/download/3.0.1... is 213MB file which contains "fat binaries" (single binaries that execute on a bewildering array of hardware platforms and operating systems) for dozens of programs, including zip, curl, git, wget, python, ctags and even my own Datasette Python application!
It's absolutely wild that this works.
I just tried it out (on macOS). I downloaded and extracted that zip and did this:
cd ~/Downloads/cosmos-3.0.1/bin
./python -c 'print(4 + 5)'
It refused the first time because of macOS security settings. I had to open the security panel and click "allow"... and then it worked!
It says arm64 linux support, I will have to try this on a raspberry pi. It’s kind of amazing and magical that this person pulled it off. We need a MacArther genius award for software. And this should be the first award.
Every time I see an update from Justine I get so excited. It's like watching the future of computing unfold in real time. It makes me wish we could send them back in time - all of the pieces to make this work have been in place for a long long time but nobody connected all the dots. The funniest part of this post are the instructions to integrate it with autoconf. All of that autotools nonsense wouldn't have had to exist if this had been around!
This is a neat trick and clever technical work, but is it useful in practical terms?
Like, wouldn't you just download the binary that's been compiled specifically for the platform and architecture that you're using? Rather than relying on a potentially quite fragile method of cross-platform execution.
In a way it kind of reminds me of Urbit. Very clever, very cool, but also very niche and more of a hobbyist showcase project than anything else. Not that there's anything wrong with that of course.
> However portability isn't the only selling point. Cosmo Libc will make your software faster and use less memory too.
With that in mind, is there a "slim binary" mode that lets me only export the code to run the binaries on my system, so that I can reap these benefits for personal use without added "bloat" for a feature that I won't need? (where "bloat" is contextual, with the current context being "not actually planning to make use of portability")
As awesome as these are, they're not really portable executables if you can't set their setuid bits and expect them to run as root like with normal executables, right?
Very cool! What would the "gui-version" of this look like? Would you write it once with linux bindings and the executable would succesfully create a window in every operating system?
I'm using Pyinstaller to ship a zero-dependency Python app. It would be amazing if Cosmopolitan could make it portable too. Is anyone working on Pyinstaller+Cosmopolitan integration? I guess a key issue there would be that many Python dependencies ship C extensions which are typically distributed as prebuilt platform-specific binary "wheel" packages via pip. I guess pip would need to start hosting a Cosmopolitan flavor of wheel package in addition to the native ones?
What's almost as impressive as the project itself is the author's responsiveness here. Specifically, they have already built a solution for almost everyone's "but what about my niche use case" reply.
I'm amazed by this. Platform-independence _with the same binary_ is such a neat solution that would really have helped me at a prior job.
Some corporate IT shops manage user machines with tooling that can't deploy software specific to machine os/version/hardware/etc. This often caused problems with 32-bit vs 64-bit windows machines or differing windows versions (XP/Vista/....). We also couldn't easily make linux or osx executables available for the end-users due to corporate IT policies.
Usually when I see yet another variation on this theme my first response is 'oh not, not again', but this time it is more like 'wow, that's really cool' and I hope that it will be further established and that it will see much adoption.
Of course to get fewer distribution formats you had to make one more distribution format but in this one case it might actually work.
I mean, I know why it's not done (parsing floats correctly is a lot harder than it would at first seem to be) and I'm not complaining, more like hinting to some of the fine people that haunt this website who might find such a task interesting.
I can't use wget from homebrew anymore on my computer because of some weird shared library crap but I can download this universal binary and it just works. Whaaaaat!?!
Cosmopolitan is cool and I have some uses in mind for it that I wish to get to.
But what I don't understand is the use case for an exe which supports both running as an user app on normal operating systems and from the BIOS. For which application specifically does it makes sense to run it in both these very different contexts?
Absolutely. cosmos-3.0.1.zip contains bash, GNU coreutils, Emacs, and a whole lot more. All of which run great on the Windows console. On our github release page, there's also a cosmocc zip of a GNU/Linux style GCC compiler. Cosmo provides a refreshing way to build Windows software, because we use the System V ABI (i.e. long is actually 64-bit) when we build Windows software. So there's a much more consistent cross platform development experience.
That was the most interesting part of the article for me. I don't understand how it can be faster, given that there's syscall translation going on. Is this more of a commentary on the quality of the `libc` available on Windows? Or on the quality of the GNU Emacs Windows port?
This is all super impressive especially for such a small team.
But we should keep in mind that this project is what POSIX should have been, this is a big patch to make things right, as they should have been more than 20 years ago.
It seems magical because of the failure of numerous other teams and people who never managed to tackle the portability issue with the right mindset and skills.
Write once, run anywhere has been a slogan for coming up on thirty years. Except all implementations of it have acceded to reality in one or more important aspects, such as needing to install Java separately. And it's not just platform-specific compilation, it's everything that could support platform-specific compilation (if you've never tried to cross-compile from Linux to MSVC, you should), and also all sorts of platform-specific code (like console functions vs terminal sequences, or even stuff as banal as $HOME vs $USERPROFILE). Cosmopolitan still isn't perfect, because it doesn't emulate all of Linux, so you still need kernel32.dll here and there. But it is still the best of any attempts.
For the consumer it's a simple switch(arch) statement to download the right binary.
But for the developer, it means setting up 9 different build pipelines and artifacts (and realistically, most won't bother with BSD builds and a lot still don't bother with arm64 builds).
It's not necessarily a huge hurdle or an unbearable expense with modern CI services, but it's still a massive deal that this project can make it all unnecessary for every single C/C++ developer out there. If this were a paid product, literally millions of companies would be happy to pay a small fee to save on CI costs, time and maintenance.
There's a program that's part of cosmos called `assimilate` which can turn any APE binary into a platform-specific binary.
jart@nightmare:~$ /opt/cosmos/bin/assimilate --help
assimilate: illegal option -- -
actually portable executable assimilate v1.6
copyright 2023 justine alexandra roberts tunney
usage: assimilate [-xapembfchv] [-o PATH] FILE...
-h show help
-v show version
-f ignore soft errors
-b don't remove freebsd from elf os/abi
-c clobber input path w/o making backup
-e convert to elf regardless of host os
-m convert to macho regardless of host os
-x convert to amd64 regardless of host cpu
-a convert to arm64 regardless of host cpu
-p convert to ppc64 regardless of host cpu
-o PATH write modified binary to different file
If you aren't using binfmt_misc then you can also pass the `--assimilate` flag to your APE binary, to turn it into a native executable, without having to use the tool. It's baked into the shell script. Just use the `less` command on any APE file and read the shell script.
Once assimilated, you're free to turn it into a setuid binary.
We also have patches in flight for the Linux Kernel as well as BSDs, to make APE native. https://justine.lol/ape.patch
POSIX / SUS / the Open Group Base Specifications have issues (pun not intended, but I’ll take it), and then those issues have editions. The last one of those is from 2018[1], being a revision of (indeed) the 2008 issue. (I remember Landley being more than a little acidic about this versioning scheme.)
I still have no idea what the quote is referring to, though, and given Justine’s slightly (deliberately?) unhinged manner of writing, I’d give even odds the change is in fact from 2001 or something like that.
Author here. We've got you covered. Search for `MODE=tinylinux` in the https://github.com/jart/cosmopolitan#getting-started section of the README. If you use that build mode, then hello world for x86 linux is only 8kb in size. It's very similar to what you'd expect from Musl Libc. All the Windows / BSD / Mac / BIOS stuff gets removed from the compilation.
That predefined mode is actually a friendly wrapper around a more generalized platform support system Cosmopolitan offers, which is called `-DSUPPORT_VECTOR` where you can define a bitset of specifically what platforms you want to be supported. Then dead code elimination takes care of the rest. The same concept also generally applies to microarchitecture support, where you can have as much or as little runtime dispatching as you want.
I think you can subset supported systems, like you could only compile for x86_64 ELF systems (aka Linux and *BSD) and have the shim be much smaller; presumably a subset of one is also acceptable. I don’t know how (or if) you can do this with the new build environment, though.
I think it'd be pretty sweet to have a basically an APE approach to having a blank GPU framebuffer canvas, and let high level libraries do the rest. Other folks on my team have been floating the idea of getting X to build as an APE binary. Who knows what the future holds? We don't have any resources devoted however to the problem at the moment.
It’s so nice seeing portability over binary size winning all around these days. Such a breath of fresh air. There might be legit cases but for some reason so many people are still hang up on ´but binary size’ for no logical reason whatsoever.
There is no support for dynamic libraries in Cosmopolitan right now, so the libraries would either need to be compiled in (statically) or included in the archive as Python-only libraries. With the later ones, it should be a matter of adding them to the zip archive within the cosmo python executable, which should make them available to your scripts. See the discussion elsewhere in this thread (https://news.ycombinator.com/item?id=38102629) for some additional details.
What I would prefer to see happen in the Python community is for Python packages to embed APE binaries and launch them as subprocesses (ideally using posix_spawn) because then you can mostly just ship pure Python with a few APE programs for your native needs, and nothing about the Python packaging ecosystem needs to change.
That was my dream when I worked on the TensorFlow team. One of the questions I asked myself is, if a MatMul kernel takes milliseconds to perform an op, and it takes microseconds to launch a subprocess, then why do I need to dynamically link a 50mb TensorFlow DSO when I can just whip up a simple C program to perform the very small amount of native math, system calls, and data crunching that I need for TensorBoard?
Well, now with Cosmopolitan, it's finally possible. Just whip up the ~100 or so lines of C/C++ code that's impossible to do with Python into a small fat static APE binary, and vendor that program like any other .txt or .dat file asset. Then launch it when you need to, while never caring or needing to worry about shipping multiple .whl files or setting up Jenkins build farms for BSDs, Windows, etc. Life stays easy.
This is great and all but it’s fundamentally a toy. There are a number of tradeoffs involved here, all so that the same binary runs on multiple operating systems, which isn’t actually very useful. If your program isn’t vaguely portable to begin with, it still won’t work.
It’s a very cool toy and fun personal project, but it’s not much more even though the author really wants it to be. Your code has to be vaguely portable anyway for this to work. So why would you pay the tradeoffs for a binary that runs in multiple operating systems, which is not that useful.
Is anyone working on this? I'll try it out. I've been reading all I can about floats the past few days in order to add support for them in my language. Perfect opportunity.
Super fast. Love of the craft! Never had an experience where wizard type of coders of projects would respond and fix so fast, even before you finish testing of the previous stuff :)
Definitely exciting. Portability of binaries is such a problem these days with all the angst around ABI compatibility in the Linux kernel and the push for containerization (e.g. lots of distros going towards Snap/AppImage). Justine's work seems like it's working towards a research idea from Alan Kay about developing a kind of "Model T" library that provides a solid core for all computing [0].
I'm also kind of jealous. Like most of us I work on big systems with millions of lines of spaghetti code. I think that building very small, reliable tools like Justine's would be much more impactful work.
Look at it the other way round, from someone who wants to put something in the BIOS. It's going to be much more convenient to be able to test as much of that as possible without leaving user mode and actually having to run it by restarting a (potentially virtual) machine.
But also: sbcl. You just know someone's going to do lisp-from-boot with this, if they haven't already.
Content strongly advocates for open source principles facilitating freedom of expression and information access through public repositories, transparent development, and free software distribution.
FW Ratio: 57%
Observable Facts
Page describes publicly available source code repositories on GitHub with no access restrictions.
Documentation is distributed freely online and offline without paywalls or licensing barriers.
Author provides direct email contact ([email protected]) enabling reader communication.
Content explicitly states that software and tools are freely available for download and modification.
Inferences
Open source distribution removes barriers to accessing technical knowledge and enables widespread information circulation.
Public repository structure facilitates transparent development communication and collaborative expression among developers.
Free distribution of source code and documentation supports universal access to information regardless of economic status.
Content emphasizes educational access through comprehensive documentation in multiple formats including installation guides, code examples, commented source code, and public wiki contribution opportunities.
FW Ratio: 57%
Observable Facts
Dedicated 'Full Documentation' section with offline documentation available via 'bin/cosmocc --help.'
Detailed installation guide with copy-paste code examples enables direct hands-on learning.
Page recommends reading source code commentary: 'Read the commentary in greenbean.c if you want to learn more.'
GitHub Wiki explicitly noted as available for community documentation contribution and knowledge building.
Inferences
Multi-format documentation (online, offline, in-source commentary) democratizes technical knowledge across different learning styles.
Specific code examples and annotated source code make complex systems concepts accessible to developers of varying expertise.
Open wiki contribution invites ongoing community participation in knowledge development and refinement.
Content champions participation in scientific and technical advancement through cross-platform innovation, published benchmarks, transparent design decisions, and collaborative development structure.
FW Ratio: 57%
Observable Facts
Project presents technical achievements in cross-platform binary support across six operating systems and two architectures.
Performance data is published transparently with specific metrics (Emacs speed comparison, dash binary memory usage).
Design rationales are explained in detail (e.g., MAP_GROWSDOWN memory optimization, thread cancellation implementation).
Project invites participation from global developer community through open source distribution and public code repositories.
Inferences
Open development and published metrics enable peer review, critical evaluation, and collaborative improvement of technical solutions.
Detailed design explanations facilitate knowledge transfer and enable developers to build on existing work.
Cross-platform design democratizes access to advanced technical capabilities across different user communities and operating systems.
Content explicitly invites freedom of assembly and association through community participation mechanisms including Discord community, GitHub collaboration, and public wiki editing.
FW Ratio: 57%
Observable Facts
Page explicitly invites readers to 'join our Discord community.'
GitHub Wiki is described as 'open to public editing.'
Individual contributors are publicly acknowledged by name (Gautham Venkatasubramanian credited for specific work).
Project uses public GitHub repositories enabling collaborative development and contribution.
Inferences
Community invitation signals commitment to facilitating voluntary association and collective participation.
Public editing policies demonstrate openness to collaborative knowledge creation and shared governance.
Explicit attribution practices validate contributor autonomy and enable recognition of collaborative effort.
Mozilla sponsored our work as part of their MIECO program. Google also awarded me an open source peer bonus. References to Rich Felker (Musl Libc creator) and Mike Burrows (Chubby, Altavista developer).
build 1ad9551+j7zs · deployed 2026-03-02 09:09 UTC · evaluated 2026-03-02 10:41:39 UTC
Support HN HRCB
Each evaluation uses real API credits. HN HRCB runs on donations — no ads, no paywalls.
If you find it useful, please consider helping keep it running.
