Get the top HN stories in your inbox every day.
simonw
simonw
Here's a bit of a clue to how it works:
./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
<module 'sqlite3' from '/zip/Lib/sqlite3/__init__.pyc'>
>>> 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')]
mhink
Yup, this is basically it. If you check out the "Actually Portable Executable" blogpost by the same author [1] and go to the "PKZIP Executables Make Pretty Good Containers" section there's a note on the approach.
ForHackernews
absolutely impressive
ahgamut
The "/zip/" folder refers to the ZIP store inside the actually portable executable -- you can run `unzip -vl ./python` to see what's inside.
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.
JyB
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.
flakes
I think a lot of the "logical reason" is driven by more the ephemeral, sandboxed, execution tools. e.g. a `docker run` or `serverless` architectures, where full root filesystems are populated on demand. Less executable data size there can go a long way in reducing latency/price.
musicale
> Less executable data size there can go a long way in reducing latency/price.
According to the article, Cosmo's fat binary dash was 30% larger but ran faster and used less real memory than Alpine's x86-linux-only version.
However there is still probably a 30% overhead for storage and copying.
guenthert
> It’s so nice seeing portability over binary size winning all around these days.
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.
mat_epice
Binary size was a lot more of a problem before customers had to buy 8-16 GB of RAM to run a web browser.
summarity
sudo xattr -rd com.apple.quarantine /path/to/binary/or/app
should also allow anything to run without opening settings
BiteCode_dev
Now imagine nuitka and gcc bundled as a standalone cross plateform binary so you can basically compile a cross plaform python exe from any script.
hoosieree
Am I doing something wrong? I tried this on MacOS 12.6.9 and every binary I've tried so far gives a similar "zsh: exec format error":
$ unzip cosmos-3.0.1.zip
$ cd bin
$ ./python -c 'print(2+3)'
zsh: exec format error: ./pythonjart
You need to upgrade to zsh 5.9, or backport the patch I sent them two years ago: https://github.com/zsh-users/zsh/commit/326d9c203b3980c0f841... If you can't upgrade zsh, then the workaround is to say `sh -c ./ape-program` or `bash -c ./ape-program` instead of `./ape-program`.
hoosieree
Awesome, the workaround worked for me. Thanks for the quick reply (and your amazing work on cosmopolitan and the rest)!
skybrian
I wonder if llm would work?
simonw
Base https://llm.datasette.io/ should work just fine, but it's basically a thin Python wrapper around the OpenAI Python library which then makes HTTP requests to their API.
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
<module 'httpx' from '/Users/simon/.local/lib/python3.11/site-packages/httpx/__init__.py'>
$ 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<4,>=2 in /zip/Lib/site-packages (from requests>=2.20->openai->llm) (3.2.0)
Requirement already satisfied: idna<4,>=2.5 in /zip/Lib/site-packages (from requests>=2.20->openai->llm) (3.4)
Requirement already satisfied: urllib3<3,>=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<7.0,>=4.5 (from aiohttp->openai->llm)
Downloading multidict-6.0.4-cp311-cp311-macosx_11_0_arm64.whl (29 kB)
Collecting async-timeout<5.0,>=4.0.0a3 (from aiohttp->openai->llm)
Downloading async_timeout-4.0.3-py3-none-any.whl (5.7 kB)
Collecting yarl<2.0,>=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'ahgamut
Yes, so pip works because the Python APE has OpenSSL built-in.
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
undefined
eatonphil
> 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.
Impressive stuff.
stephc_int13
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.
resonious
I think this could be said about pretty much any good invention. The physical world doesn't change much, so the only barrier to invention is human. And I suspect most inventions have someone imagining it long before some other person actually builds it.
stephc_int13
I disagree.
Most new development in tech, including software, have some dependencies on something that was not available before.
zik
Is it the job of linux OS people to provide multi-platform executable compatibility with every other OS? That seems like a stretch considering that no OS has ever done that.
uncomputation
You have it backwards on two counts. First count is the point of POSIX is any OS vendor doesn’t need to worry about any other OS compatibility. Just implement POSIX interfaces. Second count is that is OP’s exact point: it never has been done before, because too many OS vendors give POSIX very little thought. This helps realize the original vision of POSIX.
hju22_-3
Ah, yes, let's just keep on going without trying to make things better for anyone instead. That's sure to make things better!
Improvement doesn't come from passiveness. Someone, somewhere, will have to start first.
AYoung010
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?
vitiral
IIUC there is no syscall translation, it's more like there are separate libc implementations and the correct one gets selected at program start based on the OS.
ReactiveJelly
So like in-process WINE?
PrivateButts
Could be like the improvements seen when running applications using DXVK. My understanding is that sometimes these translation layers can use newer and more efficient methods than the path that a native implement for the time would use. I'm not a subject matter expert though, and could be completely off base.
mprovost
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!
appleskeptic
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.
tstack
> all so that the same binary runs on multiple operating systems, which isn’t actually very useful.
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.
folknor
Man oh man, how come I didn't find this tool 6 months ago? I think you need more topics/tags on the github repo :-D
Extremely cool, I will definitely check out lnav when I get a chance. I've been battling with the big players for a few months now and their systems are just so overengineered and complex for my needs that it's silly.
I just need tail -f for 10-ish servers and desktops.
I haven't even read the project readme, but I presume lnav is exactly what I wanted. Excellent!
dizhn
I just wrote a similar thing. A simple CLI that posts alerts and heartbeats to Alerta. I used Go mainly for the same reason. (But I also couldn't write it in C or C++ :D)
semiquaver
Can you elaborate? I’m not sure I follow your argument. A requirement to write portable C doesn’t seem so insurmountable to render the project a mere toy.
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?
zamadatix
Multi-arch seems completely different than multi-platform. The former is obviously useful, the user isn't necessarily going to understand why a program which ran on their MacBook isn't runnable on their older iMac because it's ARM only. The two programs can also still use highly specific OS integrations, GPU acceleration APIs, and make assumptions about being a macOS system. The stretch to multi-platform comes at a much higher cost in limitations for a much more dubious level of gain, as badass as it is from a technical perspective. When I say "cost" e.g. on Windows I have to rename the executable to end in .exe be able to launch it, when I do simple text based programs like nano do run... but they are completely unusable. Bash runs but I can't select, copy, or paste text with the mouse. It's borderline unusable if the app does more than behind the scenes processing only.
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.
pjmlp
ISO C and POSIX don't provide support for anything beyond CLI applications and daemons.
Sure if one wants to live in the world of UNIX before X Windows, I guess it is ok.
refulgentis
I don't understand what's useful here either. It's not inherently useful to have my `ls` on Mac be the same one as chromeOS, I'm happy with whatever is on either.
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.
bambax
Not sure what you mean by that, but a lot of great things start as toys.
That even explains part of their success: nobody pays attention to toys, and once they become ubiquitous it's too late to fight them.
maliker
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.
[0] https://web.archive.org/web/20070625105727/http://www.intel-...
AMICABoard
exactly!
AMICABoard
I swear this is the coolest project ever!!! I am using cosmo for our stuff too. jart & the team is super dedicated and responsive.
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.
haptic
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.
piaste
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.
zamadatix
Does this really change if Cosmopolitan e.g. outputs 9 different artifacts instead of 1 artifact merging all 9? The advantage you're describing seems to lie mostly in "a C/C++ build system which can actually cross compile without pulling your hair out" not "a C/C++ build system which produces a binary I can take from BSD to Windows and execute unmodified".
vanderZwan
Building a system capable of the latter is what enables the former.
EDIT: not sure what is controversial about this statement. I'm not saying it's the only solution, but it does qualify.
8organicbits
You'll still need nine test pipelines.
pie_flavor
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.
jart
I agree. You sound like you're speaking from experience. If so, I'd love to hear what sort of stuff you're building with Cosmo, if you're able to share! Feel free to reach out anytime (privately or discord) and let me know what the project can be doing to better serve your needs.
appleskeptic
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.
matheusmoreira
I can only hope my own projects reach 10% the coolness of this "toy" one day.
refulgentis
It's not a personal attack
legends2k
I noticed a similar comment from you in the same thread. If you don't write portable software, it doesn't mean the world isn't writing portable software in C, C++, Rust, etc. To list a very few ones:
Blender, GIMP, Emacs, Vim, Pidgin, Evince, Firefox, gEdit, Inkscape, Krita, FFmpeg, Python, Perl, ... I could go on and on.
pjmlp
That "portable" software is full of conditional compilation flags and wrappers to OS specific APIs.
appleskeptic
You can write portable software… and then compile it for each platform to get the best performance and functionality.
wrs
That whole comment could equally apply to webassembly, and people seem pretty excited about that.
smcameron
Cool. Somebody still needs to teach sscanf how to parse floats though. https://github.com/jart/cosmopolitan/issues/456
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.
matheusmoreira
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.
jart
I'm so happy to hear you're interested in this problem. There's two packages in the Cosmo repo you could depend on for doing this: third_party/double-conversion/ and third_party/gdtoa/. Both libraries are pretty good, but I think double-conversion is the more impressive of the two. It'd be great to see scanf() parse floats with double-conversion if it's possible. One last thing, if any of the non-standardized features of our scanf() implementation get in your way, then I'm not super attached to them and they can be deleted.
matheusmoreira
Pull request sent.
https://github.com/jart/cosmopolitan/pull/924
Oops, I only now realized there's a test suite. I'll be adding tests too... After I get some sleep.
matheusmoreira
I see. I'll try those libraries out. Was about to try writing my own algorithm despite not having a math background. The libraries will definitely be easier. Cosmopolitan can actually link against those despite being the libc?
I'm building my copy of cosmopolitan right now. If I succeed, I'll send you a pull request on GitHub.
vanderZwan
> 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")
jart
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.
havnagiggle
Would you consider this a competitive replacement of Busybox? Curious if you've compared, since they also take liberty in cutting out uncommon functionality.
mananaysiempre
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.
cryptonector
HN doesn't allow non-ASCII in usernames?
guidoism
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!?!
So so so awesome.
c-c-c-c-c
> POSIX even changed their rules about binary in shell scripts specifically to let us do it.
What does this refer to?
The latest POSIX standard was released 2007. [1]
jart
Author here. See https://austingroupbugs.net/view.php?id=1250 and https://austingroupbugs.net/view.php?id=1226 with a major shoutout to Jilles Tjoelker from the FreeBSD who helped make it possible back then!
mananaysiempre
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.
[1] https://pubs.opengroup.org/onlinepubs/9699919799.2018edition...
csande17
The references to POSIX "approval"/"changes" in Cosmopolitan docs are usually talking about bugs like this: https://austingroupbugs.net/view.php?id=1250
I'm not sure whether the proposed changes have actually made it into a published edition of the specification.
mananaysiempre
This looks to be the one, thank you! Doesn’t look to have gotten into the current version [the sh(1) page in the version I linked still refers to text files]. (The bug is also tagged tc3-2008, when the last corrigendum released is TC2, and the change was marked applied in 2019. So it makes sense it hasn’t found its way into a release yet.)
tedunangst
Don't think this is the bug they refer to, but it's one affecting sh input rules. There are others.
jacquesm
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.
NotSammyHagar
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.
hughes
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.
Seems to be a really well thought-out project.
AMICABoard
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 :)
Get the top HN stories in your inbox every day.
There's so much cool stuff in this post.
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:
It refused the first time because of macOS security settings. I had to open the security panel and click "allow"... and then it worked!Likewise, this worked:
That started a https://datasette.io/ server running on port 8000.Git works too:
That git binary is 6.3MB, and I believe that same exact file can be copied to a Linux or Windows machine and will work the same way.