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
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.
so, YaST?
I agree. OpenSuse should set the standards in this.
Tbf, they really need a designer to upgrade this visually a bit. It exudes its strong "Sys Admin only" vibes a bit much. In my opinion. 🙂
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.
I find the Darwin approach to dynamic linking too restrictive. Sometimes there needs to be a new release which is not backwards compatible or you end up with Windows weirdness. It is also too restrictive on volunteer developers giving their time to open source.
At the same time, containerization where we throw every library - and the kitchen sink - at an executable to get it to run does not seem like progress to me. It's like the meme where the dude is standing on a huge horizontal pile of ladders to look over a small wall.
At the moment you can choose to use a distro which follows a particular approach to this problem; one which enthuses its developers, giving some guarantee of long term support. This free market of distros that we have at the moment is ideal in my opinion.
The term "dependency hell" reminds me of "DLL hell" Windows devs used to refer to. Something must have changed around 2000 because I remember an article announcing, "No more DLL hell." but I don't remember what the change was.
Small thing about filesystem dialogs. In file open/save dialogs some apps group directories at the top and others mix them in alphabetically with files. My preference is for them to be grouped, but being consistent either way would be nice.
Not offering a solution here exactly, but as a software engineer and architect, this is not a Linux only problem. This problem exists across all software. There are very few applications that are fully self contained these days because it's too complex to build everything from scratch every time. And a lot of software depends on the way that some poorly documented feature worked at the time that was actually a bug and was eventually fixed and then breaks the applications that depended on it, etc. Also, any time improvements are made in a library application it has potential to break your application, and most developers don't get time to test the every newer version.
The real solution would be better CI/CD build systems that automatically test the applications with newer versions of libraries and report dependencies better. But so many applications are short on automated unit and integration tests because it's tedious and so many companies and younger developers consider it a waste of time/money. So it would only work in well maintained and managed open source types of applications really. But who has time for all that?
Anyway, it's something I've been thinking about a lot at my current job as an architect for a major corporation. I've had to do a lot of side work to get things even part of the way there. And I don't have to deal with multiple OSes and architectures. But I think it's an underserved area of software development and distribution that is just not "fun" enough to get much attention. I'd love to see it at all levels of software.
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.
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 don't use any of these, but I'm curious. Could you please write some examples?
It mostly affects people working with ”fun” enterprise hardware or special purpose things.
But to take one example, proprietary drivers for high performance network cards, most likely from Nvidia.
I'd say games. I'd that really takes off, Linux would replace Windows and all other standards will follow.
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.
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.
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.
It did really take off about 5 years ago.
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.