> As can be seen from the threads, the typical response to being told an app broke is to blame the app developers, rather than fix the problem.
This is false. Actual problems get fixed, and very quickly at that.
Normally the issues are from proprietary applications that were buggy to begin with, and never bothered to read the documentation. I'd say to a paying customer that if a behaviour is documented, it's their problem.
> Normally the issues are from proprietary applications that were buggy to begin with, and never bothered to read the documentation. I'd say to a paying customer that if a behaviour is documented, it's their problem.
… But that's exactly why Win32 was great; Microsoft actually spent effort making their OS was compatible with broken applications. Or at least, Microsoft of long past did; supposedly they worked around a use-after-free bug in SimCity for Windows 3.x when they shipped Windows 95. Windows still has infrastructure to apply application-specific hacks (Application Compatibility Database).
I have no reason to believe their newer stacks have anything like this.
The issue I see most often is someone compiled the application on a slightly newer version of Linux and when they try to run it on a slightly older machine it barfs saying that it needs GLIBC_2.31 and the system libc only has up to GLIBC_2.28 or something like that. Even if you aren't using anything that changed in the newer versions it will refuse to run.
That's an ergonomic deficiency. In practice, you probably need more than glibc, so then you have to make sure that other bits are available in this chroot. And if it so happens that one of the build tools that you rely on needs a newer version of glibc than the one you're building against, it still breaks down.
On Windows, you specify the target version of the platform when building, and you get a binary that is guaranteed to load on that platform.
Do you build software on your desktop machine and ship it? Do you not build in a chroot (or container, how the cool kids call them nowadays) to make sure the build is actually using what you think it should be using?
You have to build in a chroot or similar in any case. Just use the CORRECT one.
> On Windows, you specify the target version of the platform when building, and you get a binary that is guaranteed to load on that platform.
Except if you need a c++ redistributable… then you must ship the redistributable .exe setup inside your setup because windows. Let's not pretend shipping software on windows is easier.
Anyway all of this only applies to proprietary software. For free sotware the distribution figures it all out, does automatic rebuilds if needed and so on.
Really, just stick to free software, it's much easier.
You don't need chroot to make sure that your build uses correct versions of all dependencies; you just need a sane build system that doesn't grab system-wide headers and libs. Setting up chroot is way overkill for this purpose; it's not something that should even require root.
In case of Windows SDK, each version ships headers that are compatible going all the way back to Win9x, and you use #defines to select the subset that corresponds to the OS you're targeting.
With respect to the C runtime, Windows has been shipping its equivalent of glibc as a builtin OS component for 7 years now. And prior to that, you could always statically link.
Flatpak throws the baby out with the bathwater though. For example, on Ubuntu 22 if you install Firefox and don't have snaps enabled it installs the Flatpak, but if you do it can't access ffmpeg in the system so you can't play a lot of video files. It also fails to read your profile from Ubuntu 20 so you lose all of your settings, passwords, plugins, etc... It also wants to save files in some wierdass directory buried way deep in the /run filesystem. System integration also breaks, so if a Gnome app tries to open a link to a website the process silently fails.
> it can't access ffmpeg in the system so you can't play a lot of video files.
That's a typical packaging bug. Libraries should be bundled in the build or specified as a runtime dependency.
> It also fails to read your profile from Ubuntu 20 so you lose all of your settings, passwords, plugins, etc... It also wants to save files in some wierdass directory buried way deep in the /run filesystem. System integration also breaks, so if a Gnome app tries to open a link to a website the process silently fails.
All of this sucks and the user experience here needs a ton of work. I get the technical issues with co-mingling sandboxed and unsandboxed state, but there needs to be at least user-friendly options to migrate or share state with the sandbox.
A replacement for the xdg-open/xdg-mime/gio unholy trinity that offers runtime extension points for sandboxes might be nice. Maybe I could write a prototype service.
I think the issue with ffmpeg is that it needs to access GL driver libraries in order to support hardware acceleration. The GL libraries are dependent on your hardware and have to match what you have installed on the system. So you'd end up having to support a hundred different variations of Firefox flatpacks and users would have to make sure they match when installing, and remember to uninstall and reinstall when they update their graphics drivers.
This is false. Actual problems get fixed, and very quickly at that.
Normally the issues are from proprietary applications that were buggy to begin with, and never bothered to read the documentation. I'd say to a paying customer that if a behaviour is documented, it's their problem.