Linux Problems on the Desktop (2018)

I get the base OS along with a very long list of apps with any distro. For example Arch, Gentoo, Debian, Ubuntu, Fedora, Suse etc - all will curate a lot of apps for me. If I want to go off piste I download the code and crack on. I have several compilers to choose from LLVM, gcc int al out of the box.

tarball installs is pretty much close to the state of Windows app installations. You have to find the bloody things, download them each time and hope you have found the right one and not a trojaned one. Each one needs its own update routine and will not be updated when the rest of the system is updated.

The Windows and Apple software distribution model is archaic compared to all Linux/BSD etc distros.

Please give me an example. The Linux kernel is about a week old on this laptop. The current version of Windows server is called 2019, the last one was 2016 (rofl)

I'd just like to interject for moment. What you're refering to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX.

Many computer users run a modified version of the GNU system every day, without realizing it. Through a peculiar turn of events, the version of GNU which is widely used today is often called Linux, and many of its users are not aware that it is basically the GNU system, developed by the GNU Project.

There really is a Linux, and these people are using it, but it is just a part of the system they use. Linux is the kernel: the program in the system that allocates the machine's resources to the other programs that you run. The kernel is an essential part of an operating system, but useless by itself; it can only function in the context of a complete operating system. Linux is normally used in combination with the GNU operating system: the whole system is basically GNU with Linux added, or GNU/Linux. All the so-called Linux distributions are really distributions of GNU/Linux!

"Good kernels successfully run code. Good desktops successfully help users. I guess different goals require different designs?"

A good desktop needs to run code successful, otherwise every small bug can make a big annoying glitch.

I guess it is more a question of optimizing.

The hardcore linux user uses the terminal and a text editor mainly and kind of despise GUIs. Linux seems to be optimized for them as they are the most active ones using it. And this use case works perfectly.

GUIs are mostly a thing that was added because of the "newbs" but does not get used so much by the core - so they suck as the core group are the ones who know how to fix things. This was the situation when I started to explore the linux world and some things changed, but not much.

But Linux main problems are hardware issues, which is partly because of linux enforced OpenSource nature which wants drivers to be opensource and included in the kernel. And traditional industry does not like that approach. And given the small marketshare of linux desktop ... they don't really have to.

I wish that there would be one unified API for creating desktop programs on Linux. Right now it's somewhat coalesced on GTK/GNOME and Qt/KDE, though there are a number of others out there.

I use Linux in a VM for very hobbyist level embedded development (think Arduino and the like). Driver problems are non-existent, all of the technical problems are non-issues in this environment. The problems that I see are all to do with the lack of a common set of services for building a GUI application.

Why do my text editor and Arduino IDE use different file pickers? It's because my text editor uses the KDE API, but the Arduino IDE uses something else. GIMP uses yet a different file picker from the other two. LibreOffice uses yet another file picker, that's similar to Kate's but slightly different. I'm sure that installing Atom and VS Code would introduce me to two more file pickers.

The reason for this is that each of these programs uses a different GUI toolkit and, as a result, has a different concept of what a file picker needs to look like. Some of them don't even agree on which order the Open and Cancel buttons should be.

Network transparency is another thing that suffers from this. On Windows, you can basically use a UNC path (\\server\share\path\to\file.txt) almost anywhere because the entire system from the file picker all the way down to the file APIs knows about UNC paths. In Linux, KDE apps do this one way, GNOME apps do it a different way, and command line tools need you to somehow mount the target server before you can even think about it. I last seriously used Windows about 14 years ago and I still miss this greatly.

None of these are insurmountable problems, but it needs someone to make a decision about the one true way to do things.