We all love Linux, right. Or at the very least, we like it a lot. Well, we’re using it. Seriously though, this operating system provides us with an intellectual challenge, efficiency and satisfaction that we do not encounter elsewhere. However, that does not mean our favorite toy is perfect.
When blinded with science and love, it is quite easy to forgive mistakes and problems, and that is exactly what we’re not going to do today. We will discuss a handful of big, glaring issues that plague Linux, and how their resolution would make it so much better and fun for its user. And remember, it’s not about Microsoft. It’s not about doing better than the competition. It’s about bettering yourself. Always. In no particular order, follow me.
People like to use the word pet peeve. I prefer beastial ornery. For me, this is one of the major faults you can encounter with desktop distributions. In the enterprise world, they handle this well, but the price is a fair dose of conservatism and change freeze. At home, with biannual releases, so many spins and forks, and new software coming and going away faster than you can say Dedoimedo, consistency comes far down the ladder, bashing its chin against the chipped wood rungs.
I think it’s much worse having software that worked and then stops working than one that never worked in the first place. Expectations are a canine of female persuasion. Once you get used to something, it is very hard to let go. And once your favorite software starts misbehaving all of a sudden, you go berserk.
Methinks most distro developers should focus on quality like it’s a sacred life-or-death thing. Make sure that whatever works keeps working, even if it means ditching new features or new options. But you can’t have things suddenly going dead on you, especially when you have no bloody clue it’s about to happen.
Once long ago, I had to spend a lot of time cupsing and mugging and spooning the printer configuration to get it running. I even used HP drivers for a Lexmark printer, and it worked well. Kept on working well for many years, approx. until the advent of Gnome 3, be it coincidence or not. Then, across the board, including desktop environments that have nothing to do with Gnome 3, the printing utilities stopped behaving well. For example, browsing Samba shares is a gamble in the past two years. Kubuntu, Fedora, friends and family, take your pick, some work, some don’t. And going back to consistency, they sometimes work. It’s like playing hopscotch in a mine field full of bouncing APERS. Lovely jubbly.
Perhaps most Linux users do not care much about printing, but a handful of normal people do, and for them, the expectation of having a robust printing tool is kind of a must. More than that, even if certain vendors cannot be supported, through no fault of Linux right, one should still have the ability to try to connect to a printer and fail. The right to choose must be there. Now, as a bonus, much better support for a wider range of devices could definitely improve the overall printing experience.
In some distributions, the system menu search is good, decent or even great. In others, it’s a joke. Try searching for the word print across the Ubuntu family range. There’s your exercise. Report back your findings.
Taking Ubuntu as an example, even though the underlying system is the same, the desktop environment is different in each, and accordingly, the results. Blame it on KDE and Unity and Xfce and whichever, right. Wrong. We go back to consistency, and that means end-to-end products with a complete spectrum of solutions. So if a distribution ships with a specific set of programs and tools, those should be tailored to provide the best experience.
You can’t just grab a few libraries, a graphical frontend and call it a day. Specifically, the search functionality is quite flawed. It is invoked using completely different methods in different distributions and their default sessions. Then, sometimes, the same combo of mouse actions and keyboard shortcuts triggers a different response. Search results are not consistently shown on the desktop, and the quality of results varies greatly. Depth of search and regular expressions are not used in a uniform fashion across the board, and users are left wondering why their mood is swinging so badly.
Integration between services
Since most Linux tools are developed separately, barring a few large, cohesive desktop environments that try to provide a complete experience , it is tricky finding the right way of sharing data between programs. In fact, KDE is probably the only framework that does this moderately well. But then, you want Firefox, Chrome, LibreOffice, Skype, and other non-standard tools that are not an integral part, and problems start cropping.
Google is also trying to bridge the gap by sort of giving you just the browser and making it act as a gateway to your world of online applications. However, on a classical desktop, with no clear-defined rules how software should communicate with its peers, you end up with a broken model. So if you sign into your browser, you may need to repeat the same thing with half a dozen other utilities, just to get the desired functionality. I’m not saying we should all tie ourselves into a Borg collective blindly, but the option for convenience should be there. There’s more than just the clipboard for sharing data, but it seems like we’re stuck in the 1993 mode of work.
It’s a wild west of text. When something goes wrong, most distributions will spring a message telling you about it, maybe, if they feel like doing it. You will feel ever so slightly confused, because the geek lingo is not helpful at all. If, for some reason, you dismiss the errors, you may not always find them in the system logs, provided you can find system logs, that is. And when you do, you will have partial information, and maybe nothing at all, because the logging facility may be ever so slightly different for this or that application.
Users don’t benefit much from the way notifications are displayed either. Some go into the top right corner, others into the left. Some pop up, some pop under, and the rest hide shyly away until you feel curious enough to click them open. Others will die away into obscurity.
Following up on these error and warning messages is not easy, either. If you want to upload bug reports, you will be asked to sign in here and there, or download debuginfo packages, breaking your work flow, making you sweat extra just to be a good Samaritan. On other occasions, the developers will not even have given you an option to report your findings.
Software installation rollback
In a typical Linux desktop updating from official repositories, if you install a new version of a program and you don’t like it, well, most of the time, you’re screwed. You cannot always find old releases, and even if you can, you end up with shared library dependency problems. The same applies to drivers and kernels, although you do get some basic version control by being able to boot into older kernels in the GRUB menu. But you still end with a problem of mixing newer drivers with older kernels, for example.
In the application space, the problem is even more acute. If you install newer versions of your favorite applications, for whatever reason, the old files will be gone. Deleted. Completely replaced. On a plus side, Linux installations do not grow in size between updates, because the libraries and binaries are being overwritten with new ones. Conversely, when new stuff hits your disk, it’s there, and the olden stuff has been annihilated. At the moment, there’s no elegant way of managing your software installations, except by manually blocking updates, but you really need to know what you’re doing, in advance. The only seemingly reasonable way of mitigating this is by using BTRFS snapshots, but this is not an immediate, plug-and-play solution for the masses.
I’d like to see a friendly system-wide functionality that lets you roll back older versions of programs and tools, even if it means retaining big, heavy copies of system files in separate directories or virtual roots or whatever you want to call them. Likewise, I’d like to see new drivers compiled for all available kernels, and not just the latest one, automatically grabbing a whole bunch of headers for the necessary compilations, so that users can enjoy the latest drivers for their hardware without upgrading the kernel. Or vice versa. Flexibility to the max. Does not solve the built-in functionality, but it’s a start.
If you stick to the official repositories, you should be fine. But woe any users who tries to install something that has not yet been added to the master server. What happens then? People extract all kinds of archives and run all kinds of scripts and end up with all kinds of installations on their system, including non-standard paths, non-standard libraries, statically compiled objects, private versions of runtime engines, and other atrocities. Then, when you start mixing RPM with DEB with an extra dose of alien, you end up with a beautiful proverbial hangover, starting before you even had fun. Not fair, right.
It is impossible to force the million vendors out there to make their software work in a single unified manner, because some like Java, some like C, others use scripts, and so forth. But it is entirely possible to create a mandatory interface for how non-repository installations should be managed. Where the files ought to go, how they should be registered and maintained. Something of this kind would make distros cleaner and safer, as well as reduce the clutter under /opt, /usr/local, /home, and other arbitrary directories of choice for software installations.
We talked about this in the past. But there’s a significant shortage of help material in various distributions, and worse yet, a standard into how the help material should be written. The availability of self-service prose varies between terse text files and flowing guides rich with screenshots. You may also find yourself without any help at all, or reading something written five years back. Nothing like keeping a tedious log of everything your software does, long after you’ve lost interest in maintaining the now minus six release.
IRC and forum posts are also often advertised as legitimate support channels, and they might be, for a keen enthusiast, but that means you have network working all right and you’re geeky enough to find these. What if you don’t even have basic Internet access?
Finally, help files are not an excuse for a lack of basic functionality. If a help file is a 10-page tutorial on setting up Wireless using goat blood and vi, then perhaps the help file should be merged into software so it does automatically all that it preaches in text. That’s the best way of making the manuals shorter and more effective.
By reading this article, you may assume it’s all bad. Far from it. There’s a lot of good in Linux. Still, it can be so much better. Not in the purely technological sense, but in the way it is delivered to the end user and mated to his and her expectations. Again, I will not compare to either Windows or OS X, because that’s not the point. The grass is greener on the other side applies not. What we want is our lush turf.
Thinking quickly, off the top of my enormous head, in capacity not size, the Linux desktop mostly lags in the finer details that connect its various pieces, the one element where you know your product has been made by a hundred independent entities with little collaboration. There has to be more effort in tying it all together, and it comes on several levels, including software installation management first and foremost, the help you get when you struggle, overall consistency of the experience, service integration, information availability, and my special cookie, the printing. It may not be as important, but when it fails, the whole ship of professionalism goes down as if torpedoed for six straight hours.
I am not certain if this is a standalone article, or a part of a series, because I can think of a few more pressing issues, but listing them all would blunt the impact of the message. You may also have ideas, so feel free to share them. Stay pretty.