The LTS idea is pretty nice. It does aid users. It does help keep things stable for some. There is a problem though, maybe a few.
The latest issue for me is that newer hardware comes out every year with the LTS typically staying in use for 2 or more years. If you end up having to buy a new computer (due to hardware failure) and it has new technology. The newer XC-1660G-UW92 computer that has a newer Intel UHD chipset for video and a newer SATA mode called “Intel”.
Using a distribution such as Linux Mint, even their latest version, you are going to be stuck on an old kernel. In this case 5.4. This kernel does not have the driver for either the SATA mode for the nvme nor does it have the Intel UHD video chipset. In this case, you can’t install it onto the nvme unless you go in and configure the bios to use ACHI. In the case of the video you can’t use it unless you use compatibility mode which causes your graphics to be extremely slow. The only solution to that is to find a way to install a more modern Kernel, such as Xanmod kernel 5.13.
The problem with using a custom kernel such as Xanmod is that it is updated virtually every day, if you use the repositories. If you don’t use the repositories then you don’t get updates to Xanmod that might fix other issues. So, you are overwhelmed every day with updates from them or you just don’t get any updates from them, unless you are skilled enough to manually manage it.
Therein lies the bigger issue. There are so many things that you have to take into account because each distribution, each developer, each community expects to be able to just work around issues, to modify their product, to require special tweaking, sometimes to just get it to work at all, that the average person trying to take advantage of Linux can never ever hope to become competent enough to manage their own computer.
I’ll give you another example. You want to implement chroot in order to stop unwanted behavior in case someone breaks into your system. You may use some container technology such as Proxmox which allows you and encourages you to create your containers as unprivileged. This then creates an issue when you need to create the device nodes for your chrooted setup. The normal method is to use something known as mknod. Well, you can’t run mknod in an unprivileged container. Who could of guessed? Wow. So, you consider the alternative, which is to create a privileged container. But then you have to worry about the users breaking out of the container and into the host OS. So, then you think, well I’m chrooting them and thus they have a seriously limited number of choices for commands and that should take care of it.
This all goes to the idea that there’s too much complexity and too much special tweaking. Goodness knows you might have to account for all of this 6 months down the road when you’re past the project and then you need to redo it. Boom, you can’t remember what nor why and you wind up re-researching and re-interpreting what you researched and interpreted 6 months ago. And maybe in that 6 months things have changed even more.
Consider SSH has a massive number of parameters, configurations, etc. Consider the command called “screen”. Do a “man screen” at the command line and page down. The number of parameters and choices are overwhelming and you have no hope of remembering it all and staying on top of it enough to make the most effective us of it.
You find that most commands in Linux are like this. There are so many commands and so many options to those that you can’t hope remember it all or effectively use most of it.
The idea that anyone has a good enough understanding of the foundation of Linux to make this work for them is actually rare and those that have the knowledge well they can’t afford to spend all their time helping others. So, Linux drops farther and farther back. That’s the death knell for an OS where it is so complex that you can’t use it. Sure there’s always the desktop, sure. To really take advantage and gain the most of the awesome desktop OS you loose out on taking advantage of all the awesome features of the command line because using and learning both is a mammoth undertaking.
It’s too much for the average user. It will never take the crown unless something happens to bring much of this together. Training or classes won’t help because they aren’t equipped to even tell you the goodness of it all. They can’t figure it all out themselves enough to teach you to figure it out for yourself.
Part of this is that the programs are designed to be “one program does one thing”. This means that you have thousands of program that do just one thing. Learning which things that you need to do can be overwhelming. Of those, knowing which things apply to you, and then knowing how to tweak it to just make it work is a recipe for disaster.
We also have the problem where the developers think of the users as beta testers. The developers only talk to the bug reports and rarely talk with the users about their product. I think Canonical has put some effort into this but they too also are acting like we are their testers. In one sense they allow you to install the whole lamp stack by doing “sudo apt install lamp-stack^”. That really helps, but in other cases such as LXC they only allow you to install it via LXD and that’s done via snaps. And snaps are not all that necessary. They are moreover something you like because you agree with Canonical’s philosophy. If Canonical decides you can only do the install with snaps then you can’t install that without going out to find some 3rd party that has compiled and set up the package in a repository somewhere. They just don’t get that we are all people and have different needs, likes, and values. If the developers would just get it through their head that their work likely will never get them a $100 million or sell for a couple of billion dollars and that they shouldn’t use us, the user base, to attempt that then we’d all be far better off. Write your code because you like writing code, write your code with the end user in mind. Write it with the idea that you may gain recognition for your work but don’t create a multi-headed monster that excludes the vast majority of users.
I’ve worked on problems that have taken weeks to debug because the developers do not write adequate documentation. They don’t fill in between the lines. Their examples are poor and lack context and overall theme. You can’t follow their examples because their examples don’t explain the whole of it. I often don’t see projects that explain what their project is, and how the software actually works. They just write some snippet and the dump some examples out and write conclusions as if you are going to understand this. It’s like you can’t understand what they are writing unless you already know what they are saying.
Something has to change or Linux will forever be a lifelong pursuit and no one will champion their way out of the morass of commands and parameters.