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.
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
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.
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…
Systemd 😈
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. 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
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.
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.
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.
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.
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!
One that Linux should've had 30 years ago is a standard, fully-featured dynamic library system. Its shared libraries are more akin to static libraries, just linked at runtime by ld.so instead of ld. That means that executables are tied to particular versions of shared libraries, and all of them must be present for the executable to load, leading to the dependecy hell that package managers were developed, in part, to address. The dynamically-loaded libraries that exist are generally non-standard plug-in systems.
A proper dynamic library system (like in Darwin) would allow libraries to declare what API level they're backwards-compatible with, so new versions don't necessarily break old executables. (It would ensure ABI compatibility, of course.) It would also allow processes to start running even if libraries declared by the program as optional weren't present, allowing programs to drop certain features gracefully, so we wouldn't need different executable versions of the same programs with different library support compiled in. If it were standard, compilers could more easily provide integrated language support for the system, too.
Dependency hell was one of the main obstacles to packaging Linux applications for years, until Flatpak, Snap, etc. came along to brute-force away the issue by just piling everything the application needs into a giant blob.
At this point, package management is the main differentiating factor between distro (families). Personally, I'm vehemently opposed to erasing those differences.
The "just use flatpak!" crowd is kind of correct when we're talking solely about Linux newcomers, but if you are at all comfortable with light troubleshooting if/when something breaks, each package manager has something unique und useful to offer. Pacman and the AUR a a good example, but personally, you can wring nixpkgs Fron my cold dead hands.
And so you will never get people to agree on one "standard" way of packaging, because doing your own thing is kind of the spirit of open source software.
But even more importantly, this should not matter to developers. It's not really their job to package the software, for reasons including that it's just not reasonable to expect them to cater to all package managers. Let distro maintainers take care of that.
I'd say games. I'd that really takes off, Linux would replace Windows and all other standards will follow.
Lenovo and HP have recently announced new non-windows gaming handhelds. It is getting better.
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.
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 price 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% to play games with rootkits built-in, but rather spend it on other things