Hacker News Reader

Comment by jart | Hacker News Reader

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.

View on HN

> 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.

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.

We are slaves to the current system.

Tools like go-releaser does everything you said already automatically and doesn't need 6 different operating systems and can be ran on GitHub. Also, why would you not just use the built-in package manager to install an app? I don't think anyone is denying that it is an achievement and has limited purpose but in my opinion you're overly enthusiastic about it and in the real world it isn't that practical. I hate to say it but fanatics sometimes ruin cool stuff because they want everyone to be as fanatic as them.

This is still a solution in search of a problem. Hosting artifacts is not that expensive. Disk space is cheap.

Reply on news.ycombinator.com