Well. Lorem Ipsum vs Donald Knuth. I think they both suck. I have a different hero. Linus Torvalds. He IS good AND actually delivers.
I enjoyed the video. However, both the author and Donald Keith strike as two people who are mainly motivated by aesthetics (which is supremely ironic as they almost define themselves as being the opposite of Loren Ipsum). I like people who deliver results.
I think the author mostly likes the appearance of someone who pays attention to detail. He says that in a movie if it's obvious that the coffee cups are empty, he notices and bothers him. 3 minutes later in his video he has a guy using his laptop at the beach where glare would make it impossible to see anything on the screen.
Back in the pre-GUI era, I did this with all my posts and comments online. All fully-justified, both margins, without any extra whitespace: just careful choice of words, and occasional (but always normal standard) abbreviations.
It was fun, once practised it barely slowed me down, and when people noticed it blew their minds.
Then along came GUIs and proportional fonts and made it all invisible. :'(
72 characters is the standard limit for Git though. This convention has a long tradition from the text-mode days of email and Usenet in 80-column terminals/screens, where 72 characters allowed for the addition of a reasonable number of quoting levels (indicated by prefixing quoted lines with “>”), and/or for other line markers, before exceeding the screen width and having to reformat.
It'd be fun/great if someone made Graal Native work with it. Then things could come full circle and I could compile my Clojure/Java binaries to run everywhere (but now without a VM)
Forget which one, but there's a WASM runtime that's working on running on Cosmo-libc, combined with the WASM graal native port that's going... https://github.com/oracle/graal/issues/3391
I'm quite fuzzy on the technical details - but do you think it'd ever lead to JavaFX running everywhere? It was a while before JFX worked with Graal Native
I'd like to someday be able to easily distribute my little GUI apps (for scientific applications) in a compile-once kind of way. Asking users to install a JVM runtime has turned out to be unworkable (everyone installs the Java 8 runtime b/c that's what comes up first on Google and then the apps silently crash/don't-work and users are confused)
You can commit a lot of sins with ABIs if you throw the academic books into the fire.
For example, on my side I'm developing tooling that allows one to delink programs back into object files. This allows me to commit a whole bunch of heresy according to CS101, such as making a native port of a Linux program to Windows without having access to its source code or taking binary code from a PlayStation game and stuffing it into a Linux MIPS program.
When you're doing that kind of dark magic, it's one of those "know the rules so well you can break them" situation. Instead of following the theory that tells you what you should do, you follow the real-life world that constrains what you can do.
I'm somewhat of the same mind, but I'm fairly sure a study of Operating Systems: Three Easy Steps would get me over the hump. There's no actual reason to suspect this thing would like, sidestep normal process management or memory virtualization or something and run amok... I think.
Years ago I read some of the author's posts (they're active on HN too iirc) about it, and it seemed to me like they were relying heavily on the internals of the loader or dynamic linker on each platform, such that a new release for any given OS could conceivably break your binary.
It's probably a very fun project to hack on but I would advise against distributing the binaries and expecting them to work over the long term.
To my recollection, at least on *nix operating systems, they got some changes made to the POSIX standard to formalize behavior the binaries rely on. So going forward, mere POSIX compliance and ongoing ABI compatibility guarantee the binaries will continue to work on *nix operating systems.
On Windows, backwards ABI and executable compatibility has always been an extremely high priority, so I think the danger of future breakage is low.
Neither of those speak to macOS, but maybe someone who knows more can help clarify.
Why? Hardware and software architectures often have radically different needs from their loader, it doesn't make sense to have one format to rule them all. And any format flexible enough to support all use cases would just be a container for other formats, and in practice, loaders would ignore the variants that they don't/can't support so developers would need to care about porting things anyway.
ELF is pretty stable across many architectures and platforms but it's proven to be inflexible enough for plenty of applications where people develop their own, or alter it in varying ways.
Although this project is undoubtedly very cool, and maybe simplifies build processes by having a single binary, is there any other reason to use it? How does it compare in terms of performance, static linkability, standards conformance, etc. with musl and glibc? I’m curious because I’m picking a libc at the moment for my project.
For many other utilities I use Busybox for Windows (https://github.com/rmyorston/busybox-w32) which is well maintained, fast, and its maintainer is also very responsive to bug reports.
You're basically just benchmarking the WIN32 filesystem versus a Linux VM in that case. The Windows file system is famously slow. It'd make more sense to compare a Cosmo binary running on WIN32 with a WIN32 native program. For example, Emacs has a WIN32 port where they wrote all the Windows polyfills on their own, and because they aren't experts on Windows, the official GNU Emacs Windows releases go a lot slower on Windows than if you just compile Emacs from source on Linux using Cosmo and scp the the binary over to run on Windows. See https://justine.lol/cosmo3/
I would argue it's less about the build process and more about the user experience - no install, no "pick the right binary for your platform", just "download this file and run it". I don't think it's literally a static binary, but on anything but a `FROM scratch` container it might as well be.
Also I think there were some numbers showing that it sometimes had better performance than alternatives, but I can't seem to find the post right now.
The number of people this effects seems like it must be pretty small. There's the subset of people that have more than one OS. There's the subset of those that use command line tools (this explicitly doesn't do GUIs). There's the subset of those that would even think about some convenience of downloading a single binary command-line tool for multiple-OSes rather than use (a) something compiled specifically for that OS or (b) using something specific to that OS (rmdir on windows, rm on linxu/mac).
I use git, I've never felt especially put out that it's a different executable on mac, windows, and linux (situation "a"). I also just use what's common for the OS I'm on since there's so may other differences (C:\foo/bar) vs (/foo/bar) etc... (situation b)
I don't know enough to compare to musl, but I suspect being ISC licensed (similar to musl's MIT license) allows for static linking without upstream impact such as GPL.
Would be curious regarding features and performance comparisons with musl, which seems to come up a little short compared to say gnu libc.
Cosmo author here. We used to build our code with musl-cross-make. Once Cosmopolitan got good enough that we could compile GCC using Cosmo, our build latency dropped in half. https://x.com/JustineTunney/status/1726141024597324189
Cosmopolitan Libc is 2x faster than Musl Libc for many CLI programs like GNU Make and GCC because it has vectorized string libraries like strlen(). Musl won't merge support it on x86. I even mailed Rich patches for it years ago.
Cosmopolitan's malloc() function is very fast. If you link pthread_create() then it'll create a dlmalloc arena for each core dispatched by sched_getcpu(). If you don't use threads then it'll use a single dlmalloc arena without any locking or rdtscp overhead.
Cosmo has pretty good thread support in general, plus little known synchronization primitives from Mike Burrows. You can do things like build a number crunching program with OpenMP and it'll actually run on MacOS and Windows.
Cosmopolitan plays an important role in helping to enable the fastest AI software on CPUs. For example, Mozilla started an open source project called LLaMAfile a few months ago, which runs LLMs locally. It's based off the famous llama.cpp codebase. The main thing Mozilla did differently was they adopted Cosmopolitan Libc as its C library, which made it easy for us to obtain a 4x performance advantage. https://justine.lol/matmul/ I'm actually giving a talk about it this week in San Francisco.
I suspect parent commenter isn't just asking about static linking from the perspective of licensing but about technical feasibility; at least part of the reason people use musl is that static linking glibc isn't well supported.
static musl make is at least 4x smaller than cosmo make
cosmo make probably works on at least 4x the number of operating systems
# cd /usr/local/bin
# file make
make: /usr/local/bin/make: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), static-pie linked, stripped
# stat -c %s make
297104
# cd
# tnftp -4o make https://cosmo.zip/pub/cosmos/bin/make
# stat -c %s make
1397059
Looking forward toward somebody hooking together Python in APE [0], something like pex [1]/shiv[2]/pyinstaller[3], and the pants build system [4] to have a toolchain which spits out single-file python executables with baked-in venv and portable across mainstream OSes with native (or close enough) performance.
Readit News
I enjoy doing this too sometimes and don't find it too difficult, but damn...
I enjoyed the video. However, both the author and Donald Keith strike as two people who are mainly motivated by aesthetics (which is supremely ironic as they almost define themselves as being the opposite of Loren Ipsum). I like people who deliver results.
I think the author mostly likes the appearance of someone who pays attention to detail. He says that in a movie if it's obvious that the coffee cups are empty, he notices and bothers him. 3 minutes later in his video he has a guy using his laptop at the beach where glare would make it impossible to see anything on the screen.
/s
It was fun, once practised it barely slowed me down, and when people noticed it blew their minds.
Then along came GUIs and proportional fonts and made it all invisible. :'(
https://en.wikipedia.org/wiki/Michael_S._Hart#Writing_style
See examples at http://hart.pglaf.org/ .
https://tbaggery.com/2008/04/19/a-note-about-git-commit-mess...
[0]: https://github.com/bytecodealliance/wasm-micro-runtime/tree/...
[1]: https://github.com/dylibso/hermit
I'd like to someday be able to easily distribute my little GUI apps (for scientific applications) in a compile-once kind of way. Asking users to install a JVM runtime has turned out to be unworkable (everyone installs the Java 8 runtime b/c that's what comes up first on Google and then the apps silently crash/don't-work and users are confused)
It's a cool hack but I somehow feel like it should not work.
For example, on my side I'm developing tooling that allows one to delink programs back into object files. This allows me to commit a whole bunch of heresy according to CS101, such as making a native port of a Linux program to Windows without having access to its source code or taking binary code from a PlayStation game and stuffing it into a Linux MIPS program.
When you're doing that kind of dark magic, it's one of those "know the rules so well you can break them" situation. Instead of following the theory that tells you what you should do, you follow the real-life world that constrains what you can do.
It's probably a very fun project to hack on but I would advise against distributing the binaries and expecting them to work over the long term.
On Windows, backwards ABI and executable compatibility has always been an extremely high priority, so I think the danger of future breakage is low.
Neither of those speak to macOS, but maybe someone who knows more can help clarify.
ELF is pretty stable across many architectures and platforms but it's proven to be inflexible enough for plenty of applications where people develop their own, or alter it in varying ways.
I'd rather have a proper interface designed for portability rather than a hacked-together POSIX-but-not-really.
It's rather obvious. It's bandaid that lets us continue on with the current outdated paradigms. Not a real innovation.
I tried rsync for Windows from its "cosmos" pile of binaries (https://github.com/jart/cosmopolitan/releases/download/3.3.1...), and it was too slow to be usable compared to WSL rsync.
For many other utilities I use Busybox for Windows (https://github.com/rmyorston/busybox-w32) which is well maintained, fast, and its maintainer is also very responsive to bug reports.
Also I think there were some numbers showing that it sometimes had better performance than alternatives, but I can't seem to find the post right now.
I use git, I've never felt especially put out that it's a different executable on mac, windows, and linux (situation "a"). I also just use what's common for the OS I'm on since there's so may other differences (C:\foo/bar) vs (/foo/bar) etc... (situation b)
Would be curious regarding features and performance comparisons with musl, which seems to come up a little short compared to say gnu libc.
Cosmopolitan Libc is 2x faster than Musl Libc for many CLI programs like GNU Make and GCC because it has vectorized string libraries like strlen(). Musl won't merge support it on x86. I even mailed Rich patches for it years ago.
Cosmopolitan's malloc() function is very fast. If you link pthread_create() then it'll create a dlmalloc arena for each core dispatched by sched_getcpu(). If you don't use threads then it'll use a single dlmalloc arena without any locking or rdtscp overhead.
Cosmo has pretty good thread support in general, plus little known synchronization primitives from Mike Burrows. You can do things like build a number crunching program with OpenMP and it'll actually run on MacOS and Windows.
Cosmopolitan plays an important role in helping to enable the fastest AI software on CPUs. For example, Mozilla started an open source project called LLaMAfile a few months ago, which runs LLMs locally. It's based off the famous llama.cpp codebase. The main thing Mozilla did differently was they adopted Cosmopolitan Libc as its C library, which made it easy for us to obtain a 4x performance advantage. https://justine.lol/matmul/ I'm actually giving a talk about it this week in San Francisco.
cosmo make probably works on at least 4x the number of operating systems
https://redbean.dev/
https://github.com/jart/cosmopolitan/tree/master/tool/net
The opportunity for data corruption just freaks me out.
Deleted Comment
0 - https://news.ycombinator.com/item?id=40040342
1 - https://docs.pex-tool.org/
2 - https://shiv.readthedocs.io/en/latest/
3 - https://pyinstaller.org/en/stable/
4 - https://www.pantsbuild.org/
https://nuitka.net/
It's already being used for serious things - Mozilla's llamafile and redbean are two examples that come to mind.