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)'

Likewise, this worked:

    ./datasette -m datasette -p 8000

Git works too:

    ./git clone https://github.com/simonw/sqlite-utils

    ./python 
    Python 3.11.4 (heads/pypack1:65ac8ac, Oct 16 2023, 02:35:05) [GCC 11.2.0] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import sqlite3
    >>> sqlite3
    
    >>> import pathlib
    >>> list(pathlib.Path("/zip").glob("*"))
    [PosixPath('/zip/.symtab.amd64'), PosixPath('/zip/.symtab.arm64'), PosixPath('/zip/usr'), PosixPath('/zip/.cosmo'), PosixPath('/zip/Lib'), PosixPath('/zip/build')]

1: https://justine.lol/ape.html

Also, to add new pure-python packages, you just need to unzip them into a local folder "./Lib", and add that folder to the APE.

It does? I would rather argue that portability between desktop OS matters today less than twenty years ago as the niches are carved out, WSL 2 becomes actually usable and the desktop metaphor as a whole declines.

should also allow anything to run without opening settings

https://github.com/jart/cosmopolitan/tree/master/third_party...

and

https://github.com/trholding/llama2.c

The bigger challenge would be LLM with plugins. Those add all sorts of extra dependencies to help LLM run models directly - PyTorch, Transformers, llama-cpp-python etc.

I'd be surprised to see "llm install llm-gpt4all" work for example, since that pulls in compiled Python wheels and I'm not sure it would know which architecture to use.

pip install DOES work:

    $ ./python -m pip install httpx
    Defaulting to user installation because normal site-packages is not writeable
    Collecting httpx
      Downloading httpx-0.25.0-py3-none-any.whl (75 kB)
        ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 75.7/75.7 kB 2.7 MB/s eta 0:00:00
    ...
    Successfully installed anyio-4.0.0 h11-0.14.0 httpcore-0.18.0 httpx-0.25.0 sniffio-1.3.0

    $ ./python                     
    Python 3.11.4 (heads/pypack1:65ac8ac, Oct 16 2023, 02:35:05) [GCC 11.2.0] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import httpx
    >>> httpx
    

    $ ls ~/.local/lib/python3.11/site-packages
    anyio
    anyio-4.0.0.dist-info
    h11
    h11-0.14.0.dist-info
    httpcore
    httpcore-0.18.0.dist-info
    httpx
    httpx-0.25.0.dist-info
    sniffio
    sniffio-1.3.0.dist-info

Unfortunately "./python -m pip install llm" didn't quite work, I got this:

    ./python -m pip install llm                   
    Defaulting to user installation because normal site-packages is not writeable
    Collecting llm
      Downloading llm-0.11.1-py3-none-any.whl (36 kB)
    Requirement already satisfied: click in /zip/Lib/site-packages (from llm) (8.1.6)
    Collecting openai (from llm)
      Downloading openai-0.28.1-py3-none-any.whl (76 kB)
        ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 77.0/77.0 kB 31.0 MB/s eta 0:00:00
    Collecting click-default-group>=1.2.3 (from llm)
      Downloading click_default_group-1.2.4-py2.py3-none-any.whl (4.1 kB)
    Collecting sqlite-utils>=3.35.0 (from llm)
      Downloading sqlite_utils-3.35.1-py3-none-any.whl (67 kB)
        ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 67.2/67.2 kB 4.9 MB/s eta 0:00:00
    Collecting sqlite-migrate>=0.1a2 (from llm)
      Downloading sqlite_migrate-0.1b0-py3-none-any.whl (10.0 kB)
    Requirement already satisfied: pydantic>=1.10.2 in /zip/Lib/site-packages (from llm) (1.10.12)
    Requirement already satisfied: PyYAML in /zip/Lib/site-packages (from llm) (6.0)
    Collecting pluggy (from llm)
      Downloading pluggy-1.3.0-py3-none-any.whl (18 kB)
    Collecting python-ulid (from llm)
      Downloading python_ulid-2.2.0-py3-none-any.whl (9.4 kB)
    Requirement already satisfied: setuptools in /zip/Lib/site-packages (from llm) (68.0.0)
    Requirement already satisfied: pip in /zip/Lib/site-packages (from llm) (23.1.2)
    Requirement already satisfied: typing-extensions>=4.2.0 in /zip/Lib/site-packages (from pydantic>=1.10.2->llm) (4.7.1)
    Collecting sqlite-fts4 (from sqlite-utils>=3.35.0->llm)
      Downloading sqlite_fts4-1.0.3-py3-none-any.whl (10.0 kB)
    Collecting tabulate (from sqlite-utils>=3.35.0->llm)
      Downloading tabulate-0.9.0-py3-none-any.whl (35 kB)
    Requirement already satisfied: python-dateutil in /zip/Lib/site-packages (from sqlite-utils>=3.35.0->llm) (2.8.2)
    Requirement already satisfied: requests>=2.20 in /zip/Lib/site-packages (from openai->llm) (2.31.0)
    Collecting tqdm (from openai->llm)
      Downloading tqdm-4.66.1-py3-none-any.whl (78 kB)
        ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 78.3/78.3 kB 41.9 MB/s eta 0:00:00
    Collecting aiohttp (from openai->llm)
      Downloading aiohttp-3.8.6-cp311-cp311-macosx_11_0_arm64.whl (343 kB)
        ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 343.5/343.5 kB 3.5 MB/s eta 0:00:00
    Requirement already satisfied: charset-normalizer=2 in /zip/Lib/site-packages (from requests>=2.20->openai->llm) (3.2.0)
    Requirement already satisfied: idna=2.5 in /zip/Lib/site-packages (from requests>=2.20->openai->llm) (3.4)
    Requirement already satisfied: urllib3=1.21.1 in /zip/Lib/site-packages (from requests>=2.20->openai->llm) (2.0.4)
    Requirement already satisfied: certifi>=2017.4.17 in /zip/Lib/site-packages (from requests>=2.20->openai->llm) (2023.7.22)
    Collecting attrs>=17.3.0 (from aiohttp->openai->llm)
      Downloading attrs-23.1.0-py3-none-any.whl (61 kB)
        ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 61.2/61.2 kB 41.9 MB/s eta 0:00:00
    Collecting multidict=4.5 (from aiohttp->openai->llm)
      Downloading multidict-6.0.4-cp311-cp311-macosx_11_0_arm64.whl (29 kB)
    Collecting async-timeout=4.0.0a3 (from aiohttp->openai->llm)
      Downloading async_timeout-4.0.3-py3-none-any.whl (5.7 kB)
    Collecting yarl=1.0 (from aiohttp->openai->llm)
      Downloading yarl-1.9.2-cp311-cp311-macosx_11_0_arm64.whl (61 kB)
        ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 61.3/61.3 kB 427.1 kB/s eta 0:00:00
    Collecting frozenlist>=1.1.1 (from aiohttp->openai->llm)
      Downloading frozenlist-1.4.0-cp311-cp311-macosx_11_0_arm64.whl (46 kB)
        ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 46.7/46.7 kB 14.8 MB/s eta 0:00:00
    Collecting aiosignal>=1.1.2 (from aiohttp->openai->llm)
      Downloading aiosignal-1.3.1-py3-none-any.whl (7.6 kB)
    Requirement already satisfied: six>=1.5 in /zip/Lib/site-packages (from python-dateutil->sqlite-utils>=3.35.0->llm) (1.16.0)
    Installing collected packages: sqlite-fts4, tqdm, tabulate, python-ulid, pluggy, multidict, frozenlist, click-default-group, attrs, async-timeout, yarl, sqlite-utils, aiosignal, sqlite-migrate, aiohttp, openai, llm
    ERROR: Could not install packages due to an OSError: [Errno 2] ENOENT/2/No such file or directory: '/Users/simon/.local/bin/sqlite-utils'

pip install requires modifying the APE, so I end up installing pure-Python libraries as follows:

    mkdir Lib
    ./python -m pip download httpx
    unzip ./*.whl -d ./Lib
    mv python python.com # in case the next step doesn't work
    zip -r ./python.com Lib
    mv python.com python

  Packages to install: 1 (use-package-2.4.5).  Proceed? (y or 
  n) y
  Operation [ Install 1 ] started
  Contacting host: melpa.org:443
  Opening TLS connection to ‘melpa.org’...
  Opening TLS connection with ‘gnutls-cli --x509cafile nil -p 
  443 melpa.org’...failed
  Opening TLS connection with ‘gnutls-cli --x509cafile nil -p 
  443 melpa.org --protocols ssl3’...failed
  Opening TLS connection to ‘melpa.org’...failed

> 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.

Impressive stuff.

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.

I must be missing something. How are you getting from "just implement POSIX interfaces" to "compile once run everywhere"?

Wouldn't the former just promise that you could compile the same source on any POSIX-compliant OSs and get a binary that runs on that OS, on that architecture?

I like to mention my use case when this comes up: my log file viewer (https://lnav.org) uploads an agent to remote hosts in order to tail log files on that host[1]. While lnav itself is not built using cosmo, the agent is. So, it works on multiple OSs without having to compile and include multiple versions of the agent.

[1] - https://lnav.org/2021/05/03/tailing-remote-files.html

That even explains part of their success: nobody pays attention to toys, and once they become ubiquitous it's too late to fight them.

The suite of useful tools included in the post seems like a good counter example to the claim that this is inherently not useful for anything serious.

Fat multi-arch binaries are a thing on other platforms like darwin, where they are used extremely widely. What makes this approach so different?

With that in mind, "plugins" to cross platform applications instead of standalone apps could be an interesting use case though. That's something which has typically went towards per platform, interpreted/jited, or VM'd solutions - all of which have their downsides for a typical user, don't really care about the rest of the system as much, and don't need to be anything but "behind the scenes processing" in most cases.

Sure if one wants to live in the world of UNIX before X Windows, I guess it is ok.

If this means I can FFI link against one ONNX library instead of one for linux64, Linux ARM, macOS arm, macOS Intel, android, iOS, win x64, win ARM, I'm all for it though.

The code to do it would probably go in here: https://github.com/jart/cosmopolitan/blob/master/libc/stdio/...

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'm building my copy of cosmopolitan right now. If I succeed, I'll send you a pull request on GitHub.

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.

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.

Blender, GIMP, Emacs, Vim, Pidgin, Evince, Firefox, gEdit, Inkscape, Krita, FFmpeg, Python, Perl, ... I could go on and on.

Perhaps not what you intended, but I believe this is that exactly what Cosmopolitan is doing: - They are writing portable software in that it can run on various architectures and operating systems - They compile it for each platform, even if the output is a single binary - For the best performance and functionality, they mention several examples of how Cosmopolitan outperforms the native alternatives

I'm sure there are plenty of rebuttals ("Emacs on Windows is a port", "Cygwin isn't portable", "they could make the native version of $WHATEVER more performant", "Cosmopolitan isn't always faster", etc.), all of which are well and good, but would be missing the bigger picture, which is that there are reasons for both approaches (among others!) to exist, an idea that far transcends software.

Kinda feels like they are super intelligent alien beings from another planet trying to save us from software bloat and fragmentation.

> POSIX even changed their rules about binary in shell scripts specifically to let us do it.

I don't know what to say.

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")

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.

So so so awesome.

Of course to get fewer distribution formats you had to make one more distribution format but in this one case it might actually work.

What does this refer to?

The latest POSIX standard was released 2007. [1]

1: https://standards.ieee.org/ieee/1003.1/7101/

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.

[1] https://pubs.opengroup.org/onlinepubs/9699919799.2018edition...

I'm not sure whether the proposed changes have actually made it into a published edition of the specification.

https://austingroupbugs.net/view.php?id=1250

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.

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.

On my laptop (ASUS GA503QM, 5800HS), running /usr/bin/true to completion takes around 400μs, demonstrated by these three different approaches to spawning a thousand processes:

  $ python -m timeit -n 1000 --setup 'import subprocess' 'subprocess.run(["/usr/bin/true"])'
  1000 loops, best of 5: 441 usec per loop

  $ rustc -o x - 

If you’re going to be using such calls often, spawning just one persistent process and using IPC for I/O is likely to be much faster.

Indeed.

> I’m not certain of the current state though I think it improved a few years ago

It did? I feel like it gets slower and slower every time.

> I believe it’s still considerably more than one millisecond; 10–20ms is the vague number that’s lodged in my memory, but not supported, and I can’t test it now. (I invite anyone running Windows to provide figures.)

Yep. On the Windows 10 machine I have it's around 4ms, though that's antivirus and other similar sources of slowness disabled. You could probably get it closer to 2-3ms on a faster machine, but that's the ballpark.

PyTorch and the neural net implementations built on it are the whole reason I'm using Python at all. If the answer was "build the native extensions you need for PyTorch/etc into the Python binary" that would be fine too, I have no love for dynamic library loading. But I don't see the PyTorch team going out of their way to change anything about their build process or runtime to work with Cosmopolitan, as much as I wish they would, so my guess is I won't be able to use Cosmopolitan Python for the foreseeable future.

Seems to be a really well thought-out project.

Ah, that brings me to something else that someone like jart might want to take on:

# bringing static linking for C into the 21st century

What's wrong with static linking in C? Well, it's still stuck with 1970s semantics, while dynamic linking has much nicer semantics. Specifically:

  - static linking flattens the dependency
    tree, which causes

  - symbol collision issues

  - also, there's no RPATH equiv. for static
    linking

  - write dependency metadata (-lfoo, rpath,
    -L/...) into a "hidden" .o that has just
    this metadata encoded in it

  - make the static linker look for that
    metadata in dependencies and resolve
    conflicts the same way as in dynamic
    linking

  - for each link-edit, including the final
    link-edit of the executable, require
    only that direct -lfoo dependencies be
    listed

AFAIK, the gnu dynamic linker doesn't do any namespacing (as opposed to Solaris').

In the versioned symbols case this is done via decorating symbols in the dependent with the SONAME and version of the dependency that is expected to provide them. In direct binding this is done by decorating symbols in the dependent with just the SONAME of the dependency that is expected to provide them.

The versioned symbol technique allows a shared object to provide multiple versions of a symbol with the same name, which can be useful for some things, but direct binding is just much easier to use than versioned symbols: just add `-B direct` to the link-edits and you're done.

Even in the absence of symbol versioning and direct binding, the fact that each object records its dependencies means that symbol conflicts will be only among those dependencies, and this can be discovered at link-edit time.

LD_PRELOAD interposers, on the other hand, can cause symbol conflicts in spite of all the foregoing. For this you can use `-B protected` or similar, but you may not want to.

> In the Cosmos, every program is statically linked and contains a PKZIP central directory where its /usr/share dependencies are embedded.

Sounds really neat, even the data and configuration files are linked into the executable. Can't wait to see what else you'll come up with.

Other than bash itself, does it mean it can be used to make whole set of GNU tools cross platform?

Even though Windows 10 already has Terminal and I was getting

     [error 2147942405 (0x80070005) when launching `C:\bin\bash -l']

    PS C:\WINDOWS\system32> $ACL = Get-ACL -Path C:\Users\jtunn
    PS C:\WINDOWS\system32> $ACL | Set-ACL -Path C:\bin

  The application was unable to start correctly (0xc0000142).

    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

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

Is there an actual written spec somewhere describing how this works? What happens if the APE embeds an ELF header and something else? Or multiple ELF headers?

https://i.ibb.co/v4s0Xpj/IMG-1221.png

Love your work!

Users don't install software anymore, outside of mobile. Most things are now doable through the browser. The browser isn't perfect, but from a user perspective, it's a much better app delivery service than anything that's existed before

The only things I find myself installing recently are text editors, programming languages/command line tools, and games. What else? WSL is pretty good so I can even run a lot of Linux things from within Windows now

If I need something that needs raw power that's too much for a browser, like a database server or running an LLM model, I'm just gonna use Linux - why do I need cross compatibility?

Web apps require servers, servers that need to be patched, updated, certificates, DDOS protection, and a number of other things. The apps themselves need management, and maintenance. So a "web app" is a service, no matter how you slice it.

An installed program can work for decades. My personal Wiki (WikidPad) that I run every day, is from an installer compiled in 2015. It just works. I tried to run it under Linux, where it was installed from source, and it won't work. The folks at WxWindows made a major breaking change, so none of the GUI forms/dialogs work, it just seems to work, until you need to change a setting, then it dies.

In theory, you could now create an installer that would work for the next 20 years without issue across operating systems.

That’s a pretty strong statement without any evidence to back it up. It sounds like the kind of statement I hear often from people who spend all of their time in the web-dev echo chambers. Lots of us install software and don’t spend much time in browsers beyond browsing the web and the handful of Electron apps that we have no choice but to use.

But it’s not hyperbole to say the browser has become the dominant software delivery platform outside of mobile. Email, CRMs, CMSs, electronic dictionaries, word processors, online chat, filing tax returns are just a few examples of things that used to require installing native apps and now are largely browser-based.

2. Browsers are great at GUI apps, but depend on HTTP servers and emulate terminals poorly.

So I view the two as being complementary. I imagine it's one of the reasons why Mozilla supported the project. Both platforms solve the portability problem, except for fundamentally different areas. Put them together and you get something greater than the sum of your parts.

Just kidding, I’ve played around with some of the stuff @jart and other contributors have created and it’s mind blowing. Well done and keep up the good work.

My above repo contains example with the Rust standard library that build as fat executables with Cosmopolitan Libc.

I also got ripgrep to build https://github.com/ahgamut/ripgrep/tree/cosmopolitan, but it wasn't part of the cosmocc binaries because some crates that are part of the build require `#!feature(rustc_private)]` to be added to their source code. Same goes for bat and fd.

To summarize, Rust CLI tools can be built with Cosmopolitan Libc, but to build them like we can build gcc/emacs/git right now, we will need some support and Rust expertise.

Also it says it supports WASM (wasi?) so some applications might work out of the box with that.

(say, Qt WebAssembly? ...something else?)

Or is there a even better route to run-anywhere Cosmopolitan apps with a GUI?

You can then integrate additional libraries as you please, such as sqlite3 to give yourself fast, local database access over an endpoint on the embedded HTTP/S/2 (or websocket) server.

I personally haven't been focusing on bare metal support myself the past several months, but we've got a talented member of the team (tkchia) who actively works on maintaining metal and expanding its capabilities. See also the list of supported system calls for bare metal here: https://justine.lol/cosmopolitan/functions.html As you can see, we still have a lot of work to do. But it's really cool to have, and I have high hopes for it someday as a cloud native deployment format. Hypervisors are in many ways the new OSes, so why do we need a traditional OS in-between?

If you haven't and you're on Firefox, go to `about:preferences#privacy`, then scroll to the bottom and you should be able to activate it there.

Anyone knows roughly how it is broken down? Because that seems massive for a small team. Or is it counting the LOCs of softwares it has wrapped up/fork of libc?

    $ for x in ape examples libc/* tool/* net/* test/*/*; do echo $x $(wc -l $x/*.{c,cc,S,h,sh,mk,inc} $x/*/*.{c,cc,S,h,sh,inc} $x/*/*/*.{c,S,h,sh} $x/*.S | tail -n1 | awk1); done 2>/dev/null | sort -nrk2 | head -n25
    libc/calls 38690
    libc/tinymath 33400 (mostly copied from fdlibm/arm/musl/freebsd/openbsd actually)
    libc/intrin 28243 (a good chunk of this is from arm and llvm)
    libc/nt 26738 (it's just win32 interface boilerplate)
    libc/stdio 21829
    examples 19740 (a big chunk of that is actually dash)
    libc/sysv 18305
    tool/build 17811
    test/libc/xed 17581 (mostly generated actually)
    libc/nexgen32e 16695
    tool/net 15058
    libc/str 12150
    tool/viz 11511
    libc/runtime 10823
    test/libc/calls 9460
    ape 7507
    libc/sock 7436
    tool/plinko 7075
    libc/proc 6956
    net/http 6901
    libc/thread 6757
    libc/vga 5518
    test/libc/stdio 5057
    libc/log 4759
    libc/time 4749
    test/libc/tinymath 4555
    libc/testlib 4217

  bin ./bash

Why non-native?

I'd stay away from it unless you have a very pressing need.

- Nevertheless, well done!

Nevertheless - well done!

The first sub-title headline tells you, but it isn't clear to someone new if this is "one of the features of something" or "the thing."

> Build Once Anywhere, Run Anywhere C/C++

I clicked to the home page and then to here: https://justine.lol/cosmopolitan/

Then I understood!

> Cosmopolitan Libc makes C a build-once run-anywhere language, like Java, except it doesn't need an interpreter or virtual machine.

While anyone familiar probably finds these comments "stupid", just some helpful advice to the author - if it matters to you, there are people discovering this for the first time who might not realize what "it" is until you tell them!

That's the gripe! It's all context! Here it is with SUNSHINE 3.0.1:

     After nearly one year of development, I'm pleased to announce our version 3.0.1 release of Sunshine. The project is an entirely new day. For starters, Apple sponsored our work as part of their FLOWER program. Google also awarded me an open source peer bonus for my work on Sunshine, which is a rare honor, and it's nice to see our project listed up there among the greats, e.g. OPEN, QUIT, etc. In terms of this release, we're living up to the great expectations you've all held for this project in a number of ways. The first is we invented a new widget that lets you grow large dirt which...

If you've never read their blog or announcements before, I don't know why you would expect them to cater to you.

HN's headline policy makes it especially hard here, because the submitter can't provide context.

Its odd to think someone should not expect new user interest when they've made a new thing. Announcements are for new users and old users alike.

- a compiler outputting a portable executable

- POSIX shims for multiple platforms that get statically linked to resulting binary

I'm not sure why it compares itself to Java, the closest thing would be Cygwin/MinGW.

Why not?