by Orochikaku on 5/17/21, 4:57 AM with 113 comments
by iainmerrick on 5/17/21, 10:54 AM
It looks like a very clever way of packaging an x86 fat binary for multiple platforms, without actually duplicating the code. To support ARM I assume it’ll need to be an actual fat binary, with both x86 and ARM code. At that point, unless I actually test the code myself on both architectures, how can I be confident it’s going to work properly?
If you’re using very simple C constructs and not doing anything fancy, it should work, but it’s not clear to me that this approach is preferable to e.g. a Python script. If you’re doing fancy stuff, it’s a bit more chancy as C isn’t memory-safe and has tons of undefined behavior and platform-specified weirdness.
Java is “run anywhere” because they’ve specified the JVM in massive detail and tried to ensure it actually works the same on all platforms. I don’t see how you can have that same confidence if you’re running machine code everywhere.
I guess I just don’t see the use case where this is compelling. If I write a handy Unix utility in C, I’ll just keep the source code around, and compile it as needed.
It might be handy if you need to move such a utility quickly from Unix to Windows, if you don’t have any dev tools set up. But I can’t think of a situation when I’ve needed that.
by motiejus on 5/17/21, 11:24 AM
> Please note that your APE binary will assimilate itself as a conventional resident of your platform after the first run, so it can be fast and efficient for subsequent executions.
I understand there may be no real way out, but this defeats part of the promise/purpose of PAE: assume I use a pae binary, know it's pae, and implicitly share it or copy it to a different machine. But once I have copied it from ~/bin/ it's not pae any more, it's optimized for my OS/arch!
Assuming the first-run optimization step is necessary, would it make sense to provide `--deoptimize` or `--paeize` flag to the same binary, so it's easy to return to the original, without recompiling it from source? Does it lose information when it optimizes? Can that information be tucked away (with an optional flag or env variable) for this step?
What happens if the binary is read-only?
by slimsag on 5/17/21, 5:16 AM
> Cosmopolitan makes C a build-once run-anywhere language, similar to Java, except it doesn't require interpreters or virtual machines be installed beforehand. Cosmo provides the same portability benefits as high-level languages like Go and Rust, but it doesn't invent a new language and you won't need to configure a CI system to build separate binaries for each operating system. What Cosmopolitan focuses on is fixing C by decoupling it from platforms, so it can be pleasant to use for writing small unix programs that are easily distributed to a much broader audience.
by motiejus on 5/17/21, 10:35 AM
Let's see if I can get some inspiration of how things can be built from this repo?
`o/$(MODE)/depend`, a makefile-looking file with the full dependency tree. It is compiled using tool/build/mkdeps.c. So we have a Makefile generator (Justine, you mentioned elsewhere in this thread you didn't want to invent a build system? :)) The Makefile generator is very specific to this project: parses C files and creates that tree.
It is damn fast and, so far, beautifully documented (at least the build parts I looked). Hell, even documentation lines in file preambles are 72 characters wide, and justified. Crazy. Do you manually justify those?
You are also vendoring statically-built GCC, and the folder with executables is <10MB. LLVM C/C++ toolchain is hundreds of megs, compressed.
I am certainly taking inspiration of being in tight control of the compiler toolchain, and beautiful documentation. Not sure I will write my Makefile generator, since my project is also not that big.
Thanks. Cosmopolitan is giving me much more to look at than an αcτµαlly pδrταblε εxεcµταblε.
by numlock86 on 5/17/21, 6:20 AM
Is my understanding correct that the binary changes itself when first run on the target platform? That sounds like it will trigger a lot of red lights with many automated defensive mechanisms like anti virus.
by barosl on 5/17/21, 6:46 AM
> All you need to do is download the redbean.com program below, change the filename to .zip, add your content in a zip editing tool, and then change the extension back to .com.
> That performance is thanks to zip and gzip using the same compression format, which enables kernelspace copies.
Oh my. Having a web server executable which is a zip archive at the same time is a lovely idea. Have there been any other attempts similar to this?
by adsharma on 5/17/21, 6:32 PM
* Java is slowing our tools down
* amalgamation sqlite style is showing the benefits of tightly written, standalone good old C.
* By extension: monorepos are introducing complexity, since they depend on JVM for blaze/bazel.
* x86 is pervasive in our industry
You get the benefit of better static analysis vs good old C.
by tomcam on 5/17/21, 5:34 AM
> Please note that your APE binary will assimilate itself as a conventional resident of your platform after the first run...
by slimsag on 5/17/21, 5:18 AM
by nicoburns on 5/17/21, 10:30 AM
by saagarjha on 5/17/21, 5:51 AM
by 3v1n0 on 5/17/21, 8:02 AM
by stabbles on 5/17/21, 8:45 AM
by tomcam on 5/17/21, 5:27 AM
by gigatexal on 5/17/21, 9:38 AM
by YesThatTom2 on 5/17/21, 10:43 AM
by hvis on 5/17/21, 12:16 PM
That's funny.
by nabla9 on 5/17/21, 8:22 AM
.. Add Fabrice Bellard's JavaScript engine to third party
.. Add SQLite to third party
by sunmountain on 5/17/21, 6:29 AM
by 1vuio0pswjnm7 on 5/17/21, 8:30 AM