Hacker News Reader

>do something insane like a giant bundle of everything, or static linking

But isn't this exactly what shipping on Windows looks like? I've just checked my Windows partition and there are 43 instances of sqlite dll and 16 instances of Qt5Core.dll because every program that uses those libs needs to include them in their "giant bundle of everything".

Now count up the .NET runtime dlls too!

For every version between 3.5 and 10.

>I've just checked my Windows partition and there are 43 instances of sqlite dll and 16 instances of Qt5Core.dll because every program that uses those libs needs to include them in their "giant bundle of everything".

Oouch, I just got temporary headache just trying to read and comprehend the Windows mess that you mentioned here.

The issue on Linux is that the distro's package manager decides which versions of shared libraries exist system wide, and this works well when you install everything through the package manager. Windows SxS is specifically designed to allow multiple incompatible versions of the same shared component to coexist without forcing the entire Windows install to use it.

But okay, I accept your point. However I'd like to point out that "the OS allows you do something in multiple ways" is different from "this is the only way to do it"

> The issue on Linux is that the distro's package manager decides which versions of shared libraries exist system wide, and this works well when you install everything through the package manager.

Linux takes the lead: make code that depends directly on `kernel32.dll` exposed interfaces and you're in a world of hurt.

The problem pointed out is a distro, library compatiblity, packaging, or sand-boxing problem, not a Linux problem.

> Windows SxS

Now that's one very good Windows idea.

Nothing should prevent your favourite packaging/sandbox tool to present a facade that the file system has some specific files (your specific version of libraries) over some more generic files (say, Flatpak: freedesktop SDK, Steam Pressure Vessel: Steam Runtime) over some even more generic files (your actual distro libraries).

On the other hand, almost _nobody_ and _nothing_ should be touching "libraries" or "utilities" or whatever on my base system!

>The problem pointed out is a distro, library compatiblity, packaging, or sand-boxing problem, not a Linux problem.

Are you suggesting Windows users switch to Linux and not use a popular distro that can provide software they need? Otherwise, its simply a pedantic argument.

>Nothing should prevent your favourite packaging/sandbox tool to present a facade that the file system has some specific files (your specific version of libraries) over some more generic files (say, Flatpak: freedesktop SDK, Steam Pressure Vessel: Steam Runtime) over some even more generic files (your actual distro libraries).

If you introduce a new library in facade 2.0, its not going to work in facade 1.0. You can backport, but how many versions are you realistically going to support indefinitely? Its a good idea, but it doesn't solve the full problem.

> Are you suggesting Windows users switch to Linux and not use a popular distro that can provide software they need? Otherwise, its simply a pedantic argument.

If you use a distro that can provide the software they need, why not?

Or, thinking in a orthogonal way, using a distro that doesn't impose draconian library management requirements, and allows simultaneous use of ABI incompatible versions of a library? Why not? Nixos is out there and has more packages that most other distributions already.

> but how many versions are you realistically going to support indefinitely.

No versions. No indefinite support. And intentionally so. The previous layers just stay there.

The point is to intentionally provide a stable platform - with known bugs and security vulnerabilities frozen forever - something people can build their things upon. And rely on the things the things they have built upon to not be rugpulled from under them at random.

Every now and then, someone might fix a egregious security vulnerability in the platform; someone might fix a egregious usability problem in the platform; someone might implement modern features on a older platform; someone might implement compatibility tweaks - but that should not be considered a given.

I fully expect at minimum to run legacy software on a sandboxed "compatibility mode", if one values the overall safety of the rest of the system. And if you are not legacy software, someone recompiles the software every now and then to the newer platform.

>And rely on the things the things they have built upon to not be rugpulled from under them at random.

So 10 years from now, all popular distros should support versions of Facade 1.0, 1.2, 1.42 through Facade 10.2?

Now do you see the problem?

No, they don't support it. Instead, you need to run it inside a compatibility mode, that probably sandbox or VMs the facade. But your software keeps running.

The current problem is that your software no longer runs. That's a 100% denial of service problem.

I want to run a modern OS with modern features and still run any software that I already paid for 5, 10, 20 years ago.

Out of curiosity, have you asked customers to run your software in a VM? How did that conversation go?

> I want to run a modern OS with modern features and still run any software that I already paid for 5, 10, 20 years ago.

I already have a bunch of software that I paid for more that 20 years ago and I can't use most of it outside of full VMs. Microsoft didn't ask me if I didn't use them anymore before removing Win16 support.

> Out of curiosity, have you asked customers to run your software in a VM? How did that conversation go?

Customers never got a choice "where to run your software" when all software I develop ends up hidden inside a SaaS service or being delivered via representational state transfer code on demand. They either run it on a browser sandbox or it doesn't run.

You can also simply use Flatpak with the Freedesktop Runtime. It runs everywhere regardless of the distribution. For games Steam offers something similar with the Steam Runtimes. You simply develop for that one container and the software will still be running in 20 years. Even though, of course, making software proprietary isn’t best practice. If you make everything open source from the start the various Linux distributions and users can adapt it themselves for their distribution and eventually modernize it as well.

From the flatpak docs:

> A given branch of the Freedesktop runtime has a 2 year support period after which they are declared EOL.

EOL doesn't mean you can't install or use it anymore. It simply means you shouldn't use it anymore because security updates are no longer available. You face the same problem with Windows software that is no longer updated. The only difference is that no one tells you it's no longer supported.

If my employer would still pay me the same salary, I couldn't care less about the license. I'm all for outsourcing this problem to the package managers.

> With Linux, you have to target specific distros, do something insane like a giant bundle of everything,

This is what you do for Flatpack, Steam, or Docker. All these are popular options.

> Oh and I almost forgot.. install scripts that detect distros, install dependencies.

Most distros offer tooling to make packages for their package managers. With them you declare the dependencies you want and the package manager does the rest.

> And god help you if you need to ship a kernel module.

The right way to do it is to open source it and let the installer compile the software against the kernel headers. Sysdig and VirtualBox do that.

>This is what you do for Flatpack, Steam, or Docker. All these are popular options.

Yes, Flatpak is decent, but its a separate runtime with its own sandbox and perms that can sometimes make things more awkward for things like accessing host components installed outside of flatpak e.g. IDE running installed compilers, and compilers accessing project files inside the sandbox. But yes, its nice when it works.

Docker is the nuclear option. Fundamentally, I don't see Docker as a good and legitimate way to ship software (I already ranted about the giant bundle of everything approach!). I can also image my entire dev box as a VM and ship software that way too :P

I'm eternally confused by what an ABI actually is. Especially now that people say the win 32 api is the stable Linux ABI. Genuine question, what is the difference as they both seem to be conflated.

A library with a stable ABI means that newer releases of that library do not break compatibility with old binaries linked against it. This is why old Windows apps still work on newer OSes.

For example in a typical C library, as long as you don't rename or remove any existing functions/exports (or change their signatures), you can continue to add new ones over time without breaking forwards compatibility (old binaries can link/call into the newer library and still work). This is also important for security reasons and not just application compatibility.

Usually projects will only make ABI-stable changes within minor versions, and leave the breaking changes to major versions where upgrading or recompiling the original application becomes necessary.

For C++ this is more complicated because it's all compiler-dependent (no language-defined ABI), and with classes you typically can't re-arrange anything (like class members) without breaking compatibility.

Thank you. So windows historically has been careful to ensure that it's abi is stable where as Linux relies more on users recompiling against binaries, which is a problem if you are shipping binaries rather than source code? Presumably package managers try to handle this by ensuring you dependencies are up to date?

Correct.

The Linux (and BSD) ecosystems are not geared for shipping binary-only software. Everything is designed for distributions to package software _from source_, so there's no stable ABI.