The diversity of Linux distributions is one of its strengths, but it can also be challenging for app and game development. Where do we need more standards? For example, package management, graphics APIs, or other aspects of the ecosystem? Would such increased standards encourage broader adoption of the Linux ecosystem by developers?
Generally speaking, Linux needs better binary compatibility.
Currently, if you compile something, it’s usually dynamically linked against dozens of libraries that are present on your system, but if you give the executable to someone else with a different distro, they may not have those libraries or their version may be too old or incompatible.
Statically linking programs is often impossible and generally discouraged, making software distribution a nightmare. Flatpak and similar systems made things easier, but it’s such a crap solution and basically involves having an entire separate OS installed in parallel, with its own problems like having a version of Mesa that’s too old for a new GPU and stuff like that. Applications must be able to be packaged with everything they need with them, there is no reason for dynamic linking to be so important in Linux these days.
I’m not in favor of proprietary software, but better binary compatibility is a necessity for Linux to succeed, and I’m saying this as someone who’s been using Linux for over a decade and who refuses to install any proprietary software. Sometimes I find myself using apps and games in Wine even when a native version is available just to avoid the hassle of having to find and probably compile libobsoletecrap-5.so
Static linking is a good thing and should be respected as such for programs we don’t expect to be updated constantly.
Disagree - making it harder to ship proprietary blob crap “for Linux” is a feature, not a bug.
That’s a fair disagreement to have, and a sign that you’re fighting bigger battles than just getting software to work.
Static linking really is only an issue for proprietary software. Free software will always give users the option to fix programs that break due to updated dependencies.
nix can deal with this kind of problem. Does take disk space if you’re going to have radically different deps for different apps. But you can 100% install firefox from 4 years ago and new firefox on the same system and they each have the deps they need.
Someone managed to install Firefox from 2008 on a modern system using Nix. Crazy cool: https://blinry.org/nix-time-travel/
What OS? Unix?
I use nixos. But the package manager its based on, nix, can be used on other OSes.
Statically linking is absolutely a tool we should use far more often, and one we should get better at supporting.
I don’t think static linking is that difficult. But for sure it’s discouraged, because I can’t easily replace a statically-linked library, in case of vulnerabilities, for example.
You can always bundle the dynamic libs in your package and put the whole thing under /opt, if you don’t play well with others.
You’ll never get perfect binary compatibility because different distros use different versions of libraries. Consider Debian and Arch which are at the opposite ends of the scale.
And yet, ancient Windows binaries will still (mostly) run and macOS allows you to compile for older system version compatibility level to some extent (something glibc alone desperately needs!). This is definitely a solvable problem.
Linus keeps saying “you never break userspace” wrt the kernel, but userspace breaks userspace all the time and all people say is that there’s no other way.
Linus got it right, it’s just that other userspace fundamental utilities didn’t.
Yeah, that’s what I mean.
The difference is that most of your software is built for your distribution, the only exception being some proprietary shit that says it supports Linux, but in reality only supports Ubuntu. That’s my pet peeve just so that you know!
Distributions are not the problem. Most just package upstream libraries as-is (plus/minus some security patches). Hence why programs built for another distro will a lot of the time just run as is on a contemporary distro given the necessary dependencies are installed, perhaps with some patching of the library paths (plenty of packages in nixpkgs which just use precompiled deb packages as a source, as an extreme example because nixpkgs has a very different file layout).
Try a binary built for an old enough Ubuntu version on a new Ubuntu version however…
What you described as the weakness, is actually what is strong of an open source system. If you compile a binary for a certain system, say Debian 10, and distribute the binary to someone who is also running a Debian 10 system, it is going to work flawlessly, and without overhead because the target system could get the dependency on their own.
The lack of ability to run a binary which is for a different system, say Alpine, is as bad as those situations when you say you can’t run a Windows 10 binary on Windows 98. Alpine to Debian, is on the same level of that 10 to 98, they are practically different systems, only marked behind the same flag.
The thing is, everyone would agree that it’s a strength, if the Debian-specific format was provided in addition to a format which runs on all Linux distros. When I’m not on Debian, I just don’t get anything out of that…
I think webassembly will come out on top as preferred runtime because of this, and the sandboxing.
People thought the same about JVM