Which areas of Linux would benefit most from further standardization?
-
That already happened though. Tens of thousands of games on Steam can be played by hitting the install and then the play button. Only a few "competitive multiplayer" holdouts with rootkits and an irrational hatred of Linux don't work.
with rootkits
These are eventually going to be blocked on Windows. Microsoft are making changes to what's allowed to run in the kernel after the Crowdstrike issue last year.
-
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?
Flatpak with more improvements to size and sandboxing could be accepted as the standard packaging format in a few years. I think sandboxing is a very important factor as Linux distros become more popular.
-
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. Application 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
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.
-
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. Application 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
I think webassembly will come out on top as preferred runtime because of this, and the sandboxing.
-
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.
-
Yep. Two solid years of steady gaming on various Linux distributions. No issues aside from no more pubg, no more valorant. Oh wait, thatâs not an issue at all. Fuck their rootkits.
Two solid years of steady gaming on various Linux distributions.
And in some cases, even better experience than on Windows (f.e. older games compatibility or higher FPS alongside smoother gameplay)
Tbh, about a year ago i checked the proce difference between various laptops with Windows preinstalled and without any OS. The difference wasn't actually a flat amount of money, it was like +10% (price of the laptop 500$ --- ~ +50$ for Windows | price of the other laptop 1000$ --- ~ 100$ for Windows).
So because of the actual state of gaming on Linux (and overall experience) i wouldn't pay that 10% and spend it on other things
-
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?
Stability and standardisation within the kernel for kernel modules. There are plenty of commercial products that use proprietary kernel modules that basically only work on a very specific kernel version, preventing upgrades.
Or they could just open source and inline their garbage kernel modulesâŠ
-
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. Application 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
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.
-
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. Application 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
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.
-
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?
ARM support. Every SoC is a new horror.
Armbian does great work, but if you want another distro youâre gonna have to go on a lil adventure.
-
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. Application 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
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.
-
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.
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.
-
I'd say games. I'd that really takes off, Linux would replace Windows and all other standards will follow.
This has always been the key. Amazing to me that not many seem to take it seriously.
-
Stability and standardisation within the kernel for kernel modules. There are plenty of commercial products that use proprietary kernel modules that basically only work on a very specific kernel version, preventing upgrades.
Or they could just open source and inline their garbage kernel modulesâŠ
Iâm struggling with this now. Thereâs an out of tree module I want upstreamed, but the author (understandably) doesnât want to put in the work to upstream, so I did. The upstream folks are reluctant to take it because I didnât actually write it.
I really donât know what to do.
-
Flatpak with more improvements to size and sandboxing could be accepted as the standard packaging format in a few years. I think sandboxing is a very important factor as Linux distros become more popular.
Flatpak is very useful for a lot of things, but i really dont think it should be the default. It still has some weird issues. For example if you run a seperate home and root partition flatpak by default will install things into your root partition which quickly fills up. You have to go in and do a bunch of work to get it to use the home partition.
Or for example issues with themeing and cursors. Its a pretty common issue for flatpaks to not properly detect your cursor theme and just use the default until you mess around with perms and settings to fix it.
They also generally get updates slower. I guess maybe if its adopted more that would change but flatpak is already pretty widely used and thats still an issue. Especially for smaller programs not used by as many people.
Keeping it as just something that is good to use for the ones who like a GUI experience and want something simple and easy is great. But if we were to start doing like what ubuntu does with snaps where theyll just replace things you install with the snap version then im not in favor of that at all.
-
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.
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...
-
I'd say games. I'd that really takes off, Linux would replace Windows and all other standards will follow.
Have you tried recently? We've been pretty much at parity for years now. Almost every game that doesn't run is because the devs are choosing to make it that way.
-
I'd say games. I'd that really takes off, Linux would replace Windows and all other standards will follow.
It did really take off about 5 years ago.
-
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?
Configuration gui standard.
Usually there is a config file that I am suppose to edit as root and usually done in the terminal.There should be a general gui tool that read those files and obey another file with the rules. Lets say it is if you enable this feature then you can't have this on at the same time. Or the number has to be between 1 and 5. Not more or less on the number.
Basic validation. And run the program with --validation to let itself decide if it looks good or not.
