Linux

Where app data is stored.

~/.local

~/.config

~/.var

~/.appname

Sometimes more than one place for the same program

Pick one and stop cluttering my home directory

Rewrite the entire kernel exclusively in rust!

-hehehe-

I'm not sure whether this should be a "standard", but we need a Linux Distribution where the user never has to touch the command line. Such a distro would be beneficial and useful to new users, who don't want to learn about command line commands.

And also we need a good app store where users can download and install software in a reasonably safe and easy way.

interoperability > homogeneity

Each monitor should have its own framebuffer device rather than only one app controlling all monitors at any time and needing each app to implement its own multi-monitor support. I know fbdev is an inefficient, un-accelerated wrapper of the DRI, but it's so easy to use!

Want to draw something on a particular monitor? Write to its framebuffer file. Want to run multiple apps on multiple screens without needing your DE to launch everything? Give each app write access to a single fbdev. Want multi-seat support without needing multiple GPUs? Same thing.

Right now, each GPU only gets 1 fbdev and it has the resolution of the smallest monitor plugged into that GPU. Its contents are then mirrored to every monitor, even though they all have their own framebuffers on a hardware level.

While all areas could benefit in terms of stability and ease of development from standadization, the whole system and each area would suffer in terms of creativity. There needs to be a balance. However, if I had to choose one thing, I'd say the package management. At the moment we have deb, rpm, pacman, flatpak, snap (the latter probably should not be considered as the server side is proprietary) and more from some niche distros. This makes is very difficult for small developers to offer their work to all/most users. Otherwise, I think it is a blessing having so many DEs, APIs, etc.

Manuals or notifications written with lay people in mind, not experts.

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

Domain authentication and group policy analogs. Honestly, I think it's the major reason it isn't used as a workstation OS when it's inherently more suited for it than Windows in most office/gov environments. But if IT can't centrally managed it like you can with Windows, it's not going to gain traction.

Linux in server farms is a different beast to IT. They don't have to deal with users on that side, just admins.

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.

Standardizing package management? Imagine everyone being stuck with .rpm

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.

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.