5 ms·

I don't understand what the issue is with cross-compiling software, especially for different architectures. This seems more geared for running a binary on the s

I don't understand what the issue is with cross-compiling software, especially for different architectures. This seems more geared for running a binary on the same architecture across multiple different operating systems. This is great and all until you use some API that isn't the same on those operating systems. I imagine once you see something like this attempting to use comparable features and APIs as Go or something else, that you'll see the bloat increase to be equal in size if not more.

diffxx 4y ago
> I don't understand what the issue is with cross-compiling software, especially for different architectures. Agreed. The cosmopolitan project is incredible hacking and I appreciate the author's ingenuity, but this has always felt a little bit to me like a solution in search of a problem. How is cosmopolitan software intended to be distributed? If the answer is on the internet, I don't see how a single fat binary helps the end user dramatically more than separate download links. For the developer, cross compilation can be automated as part of deployment. The platform specific binaries should both be smaller than the universal ape binaries and won't resort to hackery to work properly.
- jart 4y ago
  Because end users use multiple operating systems these days. Also, no. The operating system integration code is tiny in the grand scheme of things. Consider Fabrice Bellard's JavaScript interpreter. If I build it for six operating systems, then it's 782kB: master jart@nightmare:~/cosmo2$ ls -hal o/tiny/third_party/quickjs/qjs.com -rwxr-xr-x 1 jart jart 782K Aug 30 10:53 o/tiny/third_party/quickjs/qjs.com If I build it for just Linux, then it's 710kB: master jart@nightmare:~/cosmo2$ ls -hal o/tinylinux/third_party/quickjs/qjs.com -rwxr-xr-x 1 jart jart 710K Aug 30 10:52 o/tinylinux/third_party/quickjs/qjs.com That's a 72kB difference, which includes all those Windows NT hacks and bare metal support. Why not just stuff it in there and be done with it? That way you only have to list one file on your download site.
  - ghoward 4y ago
    This is still a solution in search of a problem. Hosting artifacts is not that expensive. Disk space is cheap.
  - kelnos 4y ago
    > Because end users use multiple operating systems these days. Do end users commonly want to copy programs between OSes, or will they usually just revisit the project's website and download it again? My feeling is it would be the latter. And if we're talking about running multiple OSes on the same computer, is it common to share filesystems between those OSes? It's been a while since I ran more than one OS, but trying to do that wasn't remotely pleasant. I think this is a huge technical achievement, and I do think there are some use cases for it here and there, but I personally don't see a big benefit over just using a CI system to automatically create a build for each OS/arch combination at release time. I also wonder about the trade offs involved in using a different libc. As an example, when I was looking into musl, I realized that it didn't use NSS (unsurprising, since that would defeat the whole zero-dependency static linking thing), and therefore had no support for multicast DNS (well, not that NSS is required, but they also didn't, and had no plans to, integrate mDNS support of their own). I've pretty much abandoned using musl (and Alpine for containers) due to random quirks and gotchas like this that end up biting me somewhere down the line.
    - jart 4y ago
      Are you telling me that you don't see the benefit to clicking a build button on Linux, scp'ing to your website, and saying done -- versus -- setting up Jenkins, buying a Windows license, buying an Apple license, setting up six VMs, and then once your devops industry is in place, waiting fifteen minutes for the thing to build across all N platforms, and assuming there's no error with all your #ifdef soup needed to support building on six different operating systems with six different sets of tools, then extracting your binaries from all the Jenkins instances, scp'ing them to your website and setting up a download link for each one, and finally hoping that the end user clicks the correct one -- I mean are you being serious? Why use APE when you can just hire a devops team to do your releases.
NateEag 4y ago
I think the main appeal is the simplicity. There's one deliverable. One. Users cannot download the wrong build, because the wrong build doesn't exist.

diffxx 4y ago

> I don't understand what the issue is with cross-compiling software, especially for different architectures. Agreed. The cosmopolitan project is incredible hacking and I appreciate the author's ingenuity, but this has always felt a little bit to me like a solution in search of a problem. How is cosmopolitan software intended to be distributed? If the answer is on the internet, I don't see how a single fat binary helps the end user dramatically more than separate download links. For the developer, cross compilation can be automated as part of deployment. The platform specific binaries should both be smaller than the universal ape binaries and won't resort to hackery to work properly.

jart 4y ago
Because end users use multiple operating systems these days. Also, no. The operating system integration code is tiny in the grand scheme of things. Consider Fabrice Bellard's JavaScript interpreter. If I build it for six operating systems, then it's 782kB: master jart@nightmare:~/cosmo2$ ls -hal o/tiny/third_party/quickjs/qjs.com -rwxr-xr-x 1 jart jart 782K Aug 30 10:53 o/tiny/third_party/quickjs/qjs.com If I build it for just Linux, then it's 710kB: master jart@nightmare:~/cosmo2$ ls -hal o/tinylinux/third_party/quickjs/qjs.com -rwxr-xr-x 1 jart jart 710K Aug 30 10:52 o/tinylinux/third_party/quickjs/qjs.com That's a 72kB difference, which includes all those Windows NT hacks and bare metal support. Why not just stuff it in there and be done with it? That way you only have to list one file on your download site.
- ghoward 4y ago
  This is still a solution in search of a problem. Hosting artifacts is not that expensive. Disk space is cheap.
- kelnos 4y ago
  > Because end users use multiple operating systems these days. Do end users commonly want to copy programs between OSes, or will they usually just revisit the project's website and download it again? My feeling is it would be the latter. And if we're talking about running multiple OSes on the same computer, is it common to share filesystems between those OSes? It's been a while since I ran more than one OS, but trying to do that wasn't remotely pleasant. I think this is a huge technical achievement, and I do think there are some use cases for it here and there, but I personally don't see a big benefit over just using a CI system to automatically create a build for each OS/arch combination at release time. I also wonder about the trade offs involved in using a different libc. As an example, when I was looking into musl, I realized that it didn't use NSS (unsurprising, since that would defeat the whole zero-dependency static linking thing), and therefore had no support for multicast DNS (well, not that NSS is required, but they also didn't, and had no plans to, integrate mDNS support of their own). I've pretty much abandoned using musl (and Alpine for containers) due to random quirks and gotchas like this that end up biting me somewhere down the line.
  - jart 4y ago
    Are you telling me that you don't see the benefit to clicking a build button on Linux, scp'ing to your website, and saying done -- versus -- setting up Jenkins, buying a Windows license, buying an Apple license, setting up six VMs, and then once your devops industry is in place, waiting fifteen minutes for the thing to build across all N platforms, and assuming there's no error with all your #ifdef soup needed to support building on six different operating systems with six different sets of tools, then extracting your binaries from all the Jenkins instances, scp'ing them to your website and setting up a download link for each one, and finally hoping that the end user clicks the correct one -- I mean are you being serious? Why use APE when you can just hire a devops team to do your releases.

NateEag 4y ago

I think the main appeal is the simplicity. There's one deliverable. One. Users cannot download the wrong build, because the wrong build doesn't exist.