5 ms·

APE works through cunning trickery that might get patched out any day now (and in OpenBSD, it has been). Most people producing cross-platform software don't wa

APE works through cunning trickery that might get patched out any day now (and in OpenBSD, it has been). Most people producing cross-platform software don't want a single executable that runs on every platform, they want a single codebase that works correctly on each platform they support. With that in mind that respect, languages like go letting you cross compile for all your targets (provided you avoid CGO) is delightful... but the 3-ways-executable magic trick of APE, while really clever, doesn't inspire confidence it'll work forever, and for the most part it doesn't gain you anything. Each platform has their own packaging/signing requirements. You might as well compile a different target for each platform.

0x1ceb00da 2y ago
Wasn't elf format modified by upstream to accomodate for cosmo? That makes it kinda official. Still hard to see a use case for it. If you want everyone to be able to run your program, just write a web app, a win32 program, or a java applet. 20 years old java applets still run on modern JVMs.
- bcoates 2y ago
  You can't reasonably assume the end user system has a system JVM installed (they probably don't, in fact) so they're not really an alternative to a fat binary -- if you can install dependencies, you can just pick a single-target binary while you're at it.
  - bpfrh 2y ago
    but you can provide that JVM for different plattforms in a zip file/installer. The more difficult problem with cross plattform apps are always native look and feel and calling native apis in an idiomatic and performant ways.
- bmacho 2y ago
  Justine has similar claims about POSIX allowing binary in shell scripts now > This is an idea whose time has come; POSIX even changed their rules about binary in shell scripts specifically to let us do it. https://justine.lol/cosmo3/ https://justine.lol/cosmo3/ > Jilles Tjoelker from the FreeBSD project played an instrumental role in helping me to get the POSIX rules changed to allow binary in shell scripts, which is what made this project possible. https://justine.lol/ape.html https://justine.lol/ape.html but that's not true, as recently discussed here: https://news.ycombinator.com/item?id=41636569 https://news.ycombinator.com/item?id=41636569
- int_19h 2y ago
  A web app is, well, a web app. Many things don't fit this format, e.g. command line tools. A Win32 program will not run out of the box on either Linux or macOS. Neither will a Java app. The nice thing about Cosmopolitan is that it "just works" as far as end user is concerned. But without firm support from the OSes involved, it is inevitably a hack with questionable long-term stability prospects. What we really need is some kind of standardized low-level (think LLVM bitcode or wasm) architecture- and platform-agnostic binary format that can be JIT-compiled to the same native code that a C compiler would have produced from the source. And that is supported by all major OSes out of the box.
  - jart 2y ago
    Yes that's exactly what we need. And we'll be laughing to the bank when we bundle a browser toolbar with adware into its installer ten years down the road. Oh wait Java already did this. OTOH Cosmopolitan gives you complete autonomy. You don't need a JVM to run a simple native command line program on multiple OSes and I proved that.
    - int_19h 2y ago
      JVM bytecode is obviously not what I was talking about - it is neither low-level (if you can't efficiently compile the entirety of C into it, it's not good enough for this purpose), nor did it ever have universal first-class OS support. And stuff like https://github.com/jart/cosmopolitan/issues/1263 https://github.com/jart/cosmopolitan/issues/1263 shows that just because it works today, it doesn't mean that it'll work tomorrow. What's the guarantee that the same won't happen on Linux or macOS eventually? Don't get me wrong, APE is a hell of a hack, and I love it for that. But it can't be a truly stable platform without guarantees from the underlying OSes to keep all of that machinery working the same way. And if we could actually get them to agree on something like that, why not get them to agree on an actual portable executable format that is future-proof also wrt new CPU architectures? (Note, by the way, that this is orthogonal to the whole notion of fat binaries that contain arch-specific code. That is still a useful optimization to have in practice even if one has portable bytecode, alongside said portable bytecode.)
fragmede 2y ago
> Most people producing cross-platform software don't want a single executable that runs on every platform They don't? Having one file to download instead of a maze of "okay so what do you have" is way easier than the current mess. It would be very nice not to have to ask users what platform they're on, they just click a link and get the thing.
- bluGill 2y ago
  Trade offs. While there is a point to that, memory, bandwidth and storage are not free. Users with constrains will want a smaller executable. Of course all 3 are pretty cheap these days so more and more you can get by with just one does it all executable and nobody will care about the downsides, but lets not lose track of them.
- deleted 2y ago
  [deleted]
- eptcyka 2y ago
  Having the browser get the right URL for the download button is by far the most trivial issue when it comes to multi-platform support.
hyperion2010 2y ago
> Most people We'll I'm used to not being most people, but I'd much rather be able to produce a single identical binary for my users that works everywhere than the platform specific nonsense I have to go through right now. Having to maintain different special build processes for different platforms is a stupid waste of time. Frankly this is how it always should have worked except for the monopolistic behavior of various platforms in the past.
- yencabulator 2y ago
  > that works everywhere This whole discussion is about pointing out that it kinda doesn't.
- bjourne 2y ago
  The binary is only one part of the puzzle (and largely solved by WSL). Installation/uninstallation and desktop integration is just as much of a hassle.
  - deleted 2y ago
    [deleted]
  - cycomanic 2y ago
    I don't get the argument, if the binary part is solved by WSL it isn't useless is it? Otherwise why would MS invest so much resources into it?
    - bjourne 2y ago
      WSL can do a lot more than just run Linux binaries.
  - int_19h 2y ago
    I don't think you can reasonably assume that people have WSL set up on Windows for the purposes of shipping desktop software. Nor does it cover Mac.
    - 2y ago
cyberax 2y ago
> With that in mind that respect, languages like go letting you cross compile for all your targets (provided you avoid CGO) Even that is not a big deal in most of cases, if you use zig to wrap CC: https://dev.to/kristoff/zig-makes-go-cross-compilation-just-work-29ho https://dev.to/kristoff/zig-makes-go-cross-compilation-just-...
- jrockway 2y ago
  Does this still work? The article is from 2021 but when I last tried it this year, Go appeared to (newly) depend on headers that Zig doesn't need and thus it doesn't work. The Github issue was something like "yeah, we don't need those, so I guess Go doesn't work anymore". Without the actual error message I can't find the issue, however, so maybe I imagined this.
  - cyberax 2y ago
    Yes, I use it in my PKCS#11 client glue code.
  - dwattttt 2y ago
    I believe these are the issues: https://github.com/golang/go/issues/52690 https://github.com/golang/go/issues/52690 https://github.com/ziglang/zig/issues/14989 https://github.com/ziglang/zig/issues/14989
karel-3d 2y ago
what worked for me for cross-compiling go: https://github.com/elastic/golang-crossbuild https://github.com/elastic/golang-crossbuild docker images for macos and windows (not linux though) https://github.com/rust-cross/rust-musl-cross https://github.com/rust-cross/rust-musl-cross docker images for linux (yes, it's possible to use the same one for go, you just need to put go binary there) so it's static with musl libc and sure to not have some weird issues with old/new libc on old/new/whatever linuxes (it might be over the top and the zig thing might effectively do the same thing, but I never got it to compile) oh and apple-codesign rust cargo to get through the signing nonsense

0x1ceb00da 2y ago

Wasn't elf format modified by upstream to accomodate for cosmo? That makes it kinda official. Still hard to see a use case for it. If you want everyone to be able to run your program, just write a web app, a win32 program, or a java applet. 20 years old java applets still run on modern JVMs.

bcoates 2y ago
You can't reasonably assume the end user system has a system JVM installed (they probably don't, in fact) so they're not really an alternative to a fat binary -- if you can install dependencies, you can just pick a single-target binary while you're at it.
- bpfrh 2y ago
  but you can provide that JVM for different plattforms in a zip file/installer. The more difficult problem with cross plattform apps are always native look and feel and calling native apis in an idiomatic and performant ways.
bmacho 2y ago
Justine has similar claims about POSIX allowing binary in shell scripts now > This is an idea whose time has come; POSIX even changed their rules about binary in shell scripts specifically to let us do it. https://justine.lol/cosmo3/ https://justine.lol/cosmo3/ > Jilles Tjoelker from the FreeBSD project played an instrumental role in helping me to get the POSIX rules changed to allow binary in shell scripts, which is what made this project possible. https://justine.lol/ape.html https://justine.lol/ape.html but that's not true, as recently discussed here: https://news.ycombinator.com/item?id=41636569 https://news.ycombinator.com/item?id=41636569
int_19h 2y ago
A web app is, well, a web app. Many things don't fit this format, e.g. command line tools. A Win32 program will not run out of the box on either Linux or macOS. Neither will a Java app. The nice thing about Cosmopolitan is that it "just works" as far as end user is concerned. But without firm support from the OSes involved, it is inevitably a hack with questionable long-term stability prospects. What we really need is some kind of standardized low-level (think LLVM bitcode or wasm) architecture- and platform-agnostic binary format that can be JIT-compiled to the same native code that a C compiler would have produced from the source. And that is supported by all major OSes out of the box.
- jart 2y ago
  Yes that's exactly what we need. And we'll be laughing to the bank when we bundle a browser toolbar with adware into its installer ten years down the road. Oh wait Java already did this. OTOH Cosmopolitan gives you complete autonomy. You don't need a JVM to run a simple native command line program on multiple OSes and I proved that.
  - int_19h 2y ago
    JVM bytecode is obviously not what I was talking about - it is neither low-level (if you can't efficiently compile the entirety of C into it, it's not good enough for this purpose), nor did it ever have universal first-class OS support. And stuff like https://github.com/jart/cosmopolitan/issues/1263 https://github.com/jart/cosmopolitan/issues/1263 shows that just because it works today, it doesn't mean that it'll work tomorrow. What's the guarantee that the same won't happen on Linux or macOS eventually? Don't get me wrong, APE is a hell of a hack, and I love it for that. But it can't be a truly stable platform without guarantees from the underlying OSes to keep all of that machinery working the same way. And if we could actually get them to agree on something like that, why not get them to agree on an actual portable executable format that is future-proof also wrt new CPU architectures? (Note, by the way, that this is orthogonal to the whole notion of fat binaries that contain arch-specific code. That is still a useful optimization to have in practice even if one has portable bytecode, alongside said portable bytecode.)

fragmede 2y ago

> Most people producing cross-platform software don't want a single executable that runs on every platform They don't? Having one file to download instead of a maze of "okay so what do you have" is way easier than the current mess. It would be very nice not to have to ask users what platform they're on, they just click a link and get the thing.

bluGill 2y ago
Trade offs. While there is a point to that, memory, bandwidth and storage are not free. Users with constrains will want a smaller executable. Of course all 3 are pretty cheap these days so more and more you can get by with just one does it all executable and nobody will care about the downsides, but lets not lose track of them.
deleted 2y ago
[deleted]
eptcyka 2y ago
Having the browser get the right URL for the download button is by far the most trivial issue when it comes to multi-platform support.

hyperion2010 2y ago

> Most people We'll I'm used to not being most people, but I'd much rather be able to produce a single identical binary for my users that works everywhere than the platform specific nonsense I have to go through right now. Having to maintain different special build processes for different platforms is a stupid waste of time. Frankly this is how it always should have worked except for the monopolistic behavior of various platforms in the past.

yencabulator 2y ago
> that works everywhere This whole discussion is about pointing out that it kinda doesn't.
bjourne 2y ago
The binary is only one part of the puzzle (and largely solved by WSL). Installation/uninstallation and desktop integration is just as much of a hassle.
- deleted 2y ago
  [deleted]
- cycomanic 2y ago
  I don't get the argument, if the binary part is solved by WSL it isn't useless is it? Otherwise why would MS invest so much resources into it?
  - bjourne 2y ago
    WSL can do a lot more than just run Linux binaries.
- int_19h 2y ago
  I don't think you can reasonably assume that people have WSL set up on Windows for the purposes of shipping desktop software. Nor does it cover Mac.
  - 2y ago

cyberax 2y ago

> With that in mind that respect, languages like go letting you cross compile for all your targets (provided you avoid CGO) Even that is not a big deal in most of cases, if you use zig to wrap CC: https://dev.to/kristoff/zig-makes-go-cross-compilation-just-work-29ho https://dev.to/kristoff/zig-makes-go-cross-compilation-just-...

jrockway 2y ago
Does this still work? The article is from 2021 but when I last tried it this year, Go appeared to (newly) depend on headers that Zig doesn't need and thus it doesn't work. The Github issue was something like "yeah, we don't need those, so I guess Go doesn't work anymore". Without the actual error message I can't find the issue, however, so maybe I imagined this.
- cyberax 2y ago
  Yes, I use it in my PKCS#11 client glue code.
- dwattttt 2y ago
  I believe these are the issues: https://github.com/golang/go/issues/52690 https://github.com/golang/go/issues/52690 https://github.com/ziglang/zig/issues/14989 https://github.com/ziglang/zig/issues/14989

karel-3d 2y ago

what worked for me for cross-compiling go: https://github.com/elastic/golang-crossbuild https://github.com/elastic/golang-crossbuild docker images for macos and windows (not linux though) https://github.com/rust-cross/rust-musl-cross https://github.com/rust-cross/rust-musl-cross docker images for linux (yes, it's possible to use the same one for go, you just need to put go binary there) so it's static with musl libc and sure to not have some weird issues with old/new libc on old/new/whatever linuxes (it might be over the top and the zig thing might effectively do the same thing, but I never got it to compile) oh and apple-codesign rust cargo to get through the signing nonsense