Cross-compiling binaries for Windows is easier than building natively

There's some documentation on this in some WSL issues on GitHub, but it's not just NTFS. It's stuff like the broader filesystem architecture's inclusion of pluggable 'filters' (kinda neat, but each layer of them incurs a performance cost) or the way commands on other operating systems depend on caches for certain syscalls that Windows doesn't keep, or keep anything equivalent to.

Too tired to go find them atm

I tried that with Rust, actually. My Manjaro was running a much newer version of Glibc than my server so I had to deal with that.

First I tried to get it to link to a different system library but no package manager is happy with multiple major versions of glibc.

Then I tried MUSL but it turns out the moment you enable MUSL several OpenSSL packages used in very common dependencies don't compile anymore. There was something about a custom OpenSSL path that I would need to specify and a cert file I'd need to package, but I gave up at that point.

The solution was to use a Docker image of an ancient version of Debian with an old version of glibc to build the file. I have no idea how you'd deal with this crap if your version of glibc is even older or if you don't have glibc, my conclusion was "I guess you can't use the usual HTTP crates then".

Oh, and the "just statically link everything" approach is also terrible for security patches because most developers don't release security patches with the same urgency as library developers do. GnuTLS had some pretty terrible problems a while back that were quickly resolved with an update but the most recent version of some binaries online are still vulnerable because the devs chose to statically link GnuTLS and abandoned the project a while back.

Libraries are an enormous pain point for Linux development and even static linking won't always be there to save you. This is one of the reasons some game developers choose to release a "Linux version" of their game by just packaging Proton/Wine with their executable and making sure their game performs well under the compatibility layer. All the different versions of all the different distributions and all the different flavours are impossible to keep up with.

Linux devs have chosen to ship entire Linux core libraries with their applications in the form of AppImage/Flatpak/Snap/Docker to solve this problem. If static linking solved all problems, Docker wouldn't have taken off like it did.

Rather it's their baroque ACL permission system, which is not able to cache inherited perms.

Swift itself works on most platforms. The problem with using Swift cross platform is that Apple only bothered to make their GUI toolkit available for their platform in the same way Microsoft only makes their dotnet GUI platforms available for Windows (without resorting to "official" replacements that are owned by the same company but not built into the system, like Xamarin).

As a consequence, many Swift libraries only focus on macOS, just like many dotnet libraries focus on Windows (though recent efforts have improved that situation). You can probably get a lot of them working on Linux as well and if you use Swift for command line tools or web applications. I suppose you can probably run the most important tools cross platform, but the non-native ecosystem is clearly a second class citizen.

The big difference between XCode and VSCode is that Apple doesn't claim XCode is open source; also, XCode is more comparable to Visual Studio than VSCode in terms of SDK integration and preconfigured tooling.

Huge parts of the Darwin kernel are actually publicly accessible while Microsoft only provides kernel sources under NDA in things like education projects. Unless you count the WinXP source code leak, that is.

C# is sort-of mostly open source-ish except that debugger features are closed and the community has little say in its development.

Apple did in fact put effort into making Swift cross platform, as outlined here[1]; though their intention is that Swift programs use the system runtime on macOS/iOS/iPadOS, they put the effort into making a base layer freely available for other operating systems to gain some portability.

I'd personally argue that Apple and Microsoft are similarly if not equally open in their development, but Microsoft advertises itself much more "open source" than Apple. Apple's approach of "you can look but you can't touch" is a lot more explicit and their supposed openness comes up in fewer marketing materials.

[1]: https://github.com/apple/swift-corelibs-foundation

Can you explain how musl is related to this DNS resolving problem?