Top 5 Linux pain points in 2017

Poor documentation heads the list of Linux user woes to date. Here a few other common problem areas.
641 readers like this
641 readers like this
Top 5 Linux pain points in 2017

Internet Archive Book Images. Modified by Opensource.com. CC BY-SA 4.0

As I discussed in my 2016 Open Source Yearbook article on troubleshooting tips for the 5 most common Linux issues, Linux installs and operates as expected for most users, but some inevitably run into problems. How have things changed over the past year in this regard? Once again, I posted the question to LinuxQuestions.org and on social media, and analyzed LQ posting patterns. Here are the updated results.

1. Documentation

Documentation, or lack thereof, was one of the largest pain points this year. Although open source methodology produces superior code, the importance of producing quality documentation has only recently come to the forefront. As more non-technical users adopt Linux and open source software, the quality and quantity of documentation will become paramount. If you've wanted to contribute to an open source project but don't feel you are technical enough to offer code, improving documentation is a great way to participate. Many projects even keep the documentation in their repository, so you can use your contribution to get acclimated to the version control workflow.

2. Software/library version incompatibility

If you've wanted to contribute to an open source project but don't feel you are technical enough to offer code, improving documentation is a great way to participate.
I was surprised by this one, but software/library version incompatibility was mentioned frequently. The issue appears to be greatly exacerbated if you're not running one of the mainstream popular distributions. I haven't personally encountered this problem in many years, but the increasing adoption of solutions such as AppImage, Flatpak, and Snaps leads me to believe there may indeed be something to this one. I'm interested in hearing more about this issue; if you've faced it recently, tell me about it in the comments.

3. UEFI and secure boot

Although this issue continues to improve as more supported hardware is deployed, many users indicate that they still have issues with UEFI and/or secure boot. Using a distribution that fully supports UEFI/secure boot out of the box is the best solution here.

4. Deprecation of 32-bit

Many users are lamenting the death of 32-bit support in their favorite distributions and software projects. Although you still have many options if 32-bit support is a must, fewer and fewer projects are likely to continue supporting a platform with decreasing market share and mind share. Luckily, we're talking about open source, so you'll likely have at least a couple options as long as someone cares about the platform.

5. Deteriorating support and testing for X-forwarding

Although many longtime and power users of Linux regularly use X-forwarding and consider it critical functionality, as Linux becomes more mainstream it appears to be seeing less testing and support; especially from newer apps. With Wayland network transparency still evolving, the situation may get worse before it improves.

Holdovers—and improvements—from last year

Video (specifically, accelerators/​acceleration; the latest video cards; proprietary drivers; and efficient power management), Bluetooth support, specific WiFi chips and printers, and power management, along with suspend/resume, continue to be troublesome for many users. On a more positive note, installation, HiDPI, and audio issues were significantly less frequent than they were just a year ago.

Linux continues to make tremendous strides, and the constant, almost inexorable cycle of improvement should ensure that continues for years to come. As with any complex piece of software, however, there will always be issues.

With that said, what technical Linux issues did you find most common in 2017? Let me know about them in the comments.

Jeremy Garcia is the founder of LinuxQuestions.org  and an ardent but realistic open source advocate. Follow Jeremy on Twitter: @linuxquestions

31 Comments

https://github.com/AppImage/AppImageKit/wiki/Desktop-Linux-Platform-Iss… highlights some of the current compatibility issues. These need to be solved as the general mindset is shifting from the distribution as your only source of applications to the distribution as a platform you can run upstream-provided, upstream-supported software on, regardless of which particular distribution you happen to be running.

I am surprised you were not aware of library version incompatibility issues with Linux. This is a big problem for software developers who find it very hard to release anything that will run on multiple Linux distributions over multiple releases. Linux developers seem to think API stability is unimportant, since they routinely make running software obsolete by changing library program APIs, making the software crash or even make the source program unbuildable without source code changes to accommodate the new APIs. Add to this the many Linux application packaging systems. The result is chaos, and this is a major reason why vendors stay away from Linux. In contrast, Microsoft takes care that old programs continue to run on new releases of Windows.

To be fair, I said that "I haven't personally encountered this problem in many years"... and I haven't. I don't think it's fair to point to this issue as the main driver behind some vendors not supporting Linux, however. The main issue there is the very low marketshare that Linux has on the desktop. That said, many points in the link probono provided are reasonable and we certainly have improvements to make as an ecosystem.

--jeremy

In reply to by Mike Cornelison (not verified)

The Software/library version incompatibility problem has always been an issue especially on the developer side. Your comment about low marketshare is a "chicken or egg" problem. Which comes first making a better ecosystem for app availability or getting companies to build for Linux.

The fundamental problem is the developer has to deal with distro versioning to this day. This is why DEBs are made for multiple versions of Ubuntu and not just Ubuntu. These DEBs might not work in Debian so more need to be made. RPMs for Fedora, openSUSE, Mageia, etc are all different so yet more pain.

This is what creates the fear of companies to devote resources to such an infrastructure, it's just way too much work to justify it.

Snaps, AppImages, and Flatpaks are VERY important to the future of the platform to gain any massive desktop adoption.

In reply to by Jeremy Garcia

I'm still waiting to be able to dock a laptop and use the external display to be fixed. Laptops and docking stations have been around for quite sometime. Just recently I tested the functionality with an up-to-date distro and it is still an issue.

If that stuff is the worst we got, we've come a looong way.

Fortunately none of these five effect me.
1. I have never read documentation in my life.
2. I only run mainstream popular distributions now. ( The first Solus and Point taught me that lesson.)
3. Purchased refurbished Win7 laptop with no UEFI.
4. Only use 64 bit distributions. Why would I ever want to run 32 bit?
5.. Not a power user. If it works most of the time, I am a happy camper.

Totally not kidding. I will never go back to Windoze!

> 4. Only use 64 bit distributions. Why would I ever want to run 32 bit?

To get more performance out of your hardware. 32-bit makes a computer with less than 2GB RAM work better. If you have 4GB or more, 64-bit might be a tad bit faster.

Actually, the question is the opposite: what uses demand 64-bit?

In reply to by One Happy Linux User (not verified)

>To get more performance out of your hardware.

64 bit vastly exceeds 32 bit systems.

> 32-bit makes a computer with less than 2GB RAM work better.

That is not really true if the hardware is 64 bit compatible. If the hardware is 32bit then it makes sense why people would want 32bit distros but otherwise it doesnt really make sense in a day to day usage. It would be good in a very specific usecase like turning hardware into a headless workhorse.

>Actually, the question is the opposite: what uses demand 64-bit?

Actually the question isn't that because 32bit maxes out at using around 3.7GB of RAM so beyond that amount 64bit is immediately better because it can use it.

In reply to by Kant B. Wong (not verified)

>>To get more performance out of your hardware.

> 64 bit vastly exceeds 32 bit systems.

You know there are benchmarks online, don't you? This post might be useful:

https://askubuntu.com/questions/7034/what-are-the-differences-between-3…

I certainly don't use "vastly" for some 10% gains in speed.

>> 32-bit makes a computer with less than 2GB RAM work better.

> That is not really true if the hardware is 64 bit compatible.

But it is true, if you must do more I/O to load bigger application and data files. A computer is not just the CPU...

> If the hardware is 32bit then it makes sense why people would want 32bit distros but otherwise it doesnt really make sense in a day to day usage.

Sure, and many people still got 32-bit only PCs.

Day-to-day usage deals with small numbers like those in a point-of-sale computer, not like in a weather predicting supercomputer.

> It would be good in a very specific usecase like turning hardware into a headless workhorse.

On the contrary, 64-bit is for specific cases. You don't need it to make texts, for normal graphic editing (I use Gimp all the time in 32-bit), for internet browsing (like right now), to watch videos (yeah, even movies), banking, email, budget programs, etc.

>>Actually, the question is the opposite: what uses demand 64-bit?

> Actually the question isn't that because 32bit maxes out at using around 3.7GB of RAM so beyond that amount 64bit is immediately better because it can use it.

Indeed, and I'd probably use it if I had _one_ computer with 4GB RAM or more. But even then, please note that 64-bit usefulness only starts if the application requires more than 3.7GB.

It's not about 64-bit being better, but it's about being mandatory. Unicode made clear that 8-bit wouldn't do; 32-bit allows for a 4GB (or 3.7) address space and that is enough for most tasks. We record 5GB DVDs with that!

In reply to by Michael Tunnel…

3/ refurbish win7 laptop with no UEFI can be 32 bit
4/ that's why you might need a 32 bit distribution

In reply to by One Happy Linux User (not verified)

Hi Jeremy,

Your first point is exactly how I feel about Open Source. Would you have any recommendations on projects where I can start contributing ?
Thank you

No specific project recommendations, but generally speaking I'd say pick a project that interests you or that you're passionate about and jump in. It can be intimidating, but I think you'll find most projects genuinely welcome the help.

--jeremy

In reply to by Tomut

Documentation is indeed the number one problem. Linux generally runs error-free, but there are quite frequently mostly minor nuisances that crop up, usually in the desktop environment (KDE or GNOME). These environments are horrendously complex, have config files scattered all over the Linux system, and virtually NOTHING is documented. And despite the GUI config system having hundreds of options, the one you need isn't there.

So you end up with some nuisance that can only be fixed by editing some text file out of the tens of thousands existing on your system.

The ONLY way to find out what to do is waste a day going on some forum and hope someone knows what file to access. Then, of course, you find out your distro either doesn't have that file or it's not in the location the helper suggested or it's overwritten by some other file.

Good luck with that!

For me, the hibernation/resume support is what provides more headaches.

Hi, everybody, here are my views on the mentioned pains:

> 1. Documentation

Not much of a problem for me. It's true that there have been times without any hint on how to solve a certain situation, but these have been rare, fortunately.

As a general rule, good souls point to solutions -- it just takes a little time to find it (thanks to Google).

> 2. Software/library version incompatibility

Now, this has been somewhat of a problem to me.

First, when installing a certain very important application (PKCS-11, smartcard support s/w), I was surprised to see current libraries were not adequate; hence, I had to install older libraries. Fortunately, old and new work well on the same PC.

On another occasion, a lot more worrying, I had to select a distribution with lsb support (which is less common today) because of a printer (Epson) whose drivers depend on it. In the end, I had to use an available old machine to act as printer server for other ones which run distros without lsb.

> 3. UEFI and secure boot

I didn't face that problem, since my computers are not that new. Inthe few cases I needed to deal with that, I had to turn off secure boot. Since my computers are not exposed (I mostly use them at home).

> 4. Deprecation of 32-bit

This has been a great hassle. I see no real benefit in using 64-bit and my computers often have small RAM memory (one even has 1GB).

I do it all at 32-bit (including watching movies). I suspect I'll need a more powerful PC if I ever start to get 4K movies, but then again I'm not sure about the need of 64-bit -- though, with more than 4GB RAM, I might end up not caring much about the issue.

Personally, I think 64-bit is not a bad thing, but going 64-bit only is a mistake.

> 5. Deteriorating support and testing for X-forwarding

Not much experience here, but as I have some uses planned, I guess I won't be using Wayland so soon...

Of all those other "holdovers", I fortunately didn't experience any of them; HiDPI could become a problem if I manage to acquire a beefier monitor (currently using 1920x1080, no problem), so I'd better pay some attention to that topic.

I'd submit the problem is not so much documentation as the fact the developers are too quick to make changes that appear to have little consequence beyond breaking existing documentation.

Pretty much any search about Linux things not originally BSD or SysV uncovers lots of "documentation" most of which is incorrect simply because of configuration file/directory changes. Very frustrating!

While these issues do sound more like annoyances than life-altering problems, you would think with the amount of time Linux has been around that they would cease to exist by now. Nevertheless, I still use and believe in Linux whole heartedly.....and while I too have issues with certain things not "looking" or "acting" properly in the world of Linux and open source (such as a mangled login screen on Linux Mint with the XFCE desktop!) I'm just too deeply into Linux to bother moving back to Windows or (heaven forbid!) delving into the world of Macs! Seriously though I wish there was some better documentation provided with the various distros, and not just the "Welcome to ABC Linux" stuff either!.....but detailed, comprehensible documentation on troubleshooting a myriad of issues, and while I understand that not EVERY issue can be foreseen....all it takes is like an hour to scour various web sites and forums to "hear" what's being complained about the most, decipher what the problem might be, and offer two or three solutions as to how to fix it. Just sayin'.

As far as documentation, it's probably the one entry point to giving back to open source where almost everyone can be of some help. Like the saying goes, "if you're not part of the solution, you're part of the problem". How many people spend time figuring out things on their own or in some Q&A forum, but then don't pass it on by submitting helpful documentation for others?

I have found that when using several different Linux distributions on the same computer and attempting to use a boot loader with GPT file systems and the GRUB EFI boot loader, you can easily run into issues where some distributions are recognized and others are not, particularly when you set some up with a secure UEFI configuration. Not all distributions do it right, and some won't support secure UEFI at all. Moreover some distributions don't appear to see distributions with Btrfs partitions on the GPT while others default to the Btrfs partition format.

Chain loader capabilities are more complicated to use with GRUB 2 and GRUB EFI, making it even more difficult to resolve these issues.

Fedora and openSUSE are able to correctly load EFI, so if I want to run a mixture of different types of distributions I have had to use one of them to manage the boot loader.

The recent Linux Mint distribution is one example of a distribution that doesn't always recognize this mix. When I installed Mint and used it to control the MBR it failed to include openSUSE in the list of bootable distributions even though openSUSE was on sda6 prior to the Mint installation.

Perhaps there are ways to resolve such issues, such as creating all distributions with the same file system types and the same type of EFI configuration, but this is precisely what is very inconsistent with the configuration of various distributions.

the single biggest problem here in the office is something seemingly trivial as multi monitor support.

sure, multi-monitor setup if fully supported and well functioning but as soon as you start using different setups on different locations (like taking the laptop to a customer and hooking up to a monitor or beamer) 2 out of 3 times things get really messed up with monitors not showing an image or just a little black rectangle where your mouse pointer cant escape from and only way to get out of it is by completely deleting the stored profiles in $HOME/.local/share/kscreen/*.

what i do to make it a bit more bearable is a simple keyboard short cut that executes that statement when needed (which means you also loose your default profile) because a non technical user completely freaks out when stuff goes black.

so in the end you always get the same reaction: why doesnt it just simply work like on windows.

perhaps with wayland these troubles will be solved for once and for all because in the office you can't afford that your screens get messed up.

and yes, telling them about graphics driver hell in windows just wont be listened to at such moments.

too bad that writing documentation is not considered as a contribution by most developers... or for sure, I would write more.

These are not the primary problems. The primary problem is - there is no one Linux. If I want to install Linux, I need to struggle with the choice - Ubuntu? RedHat? Debian? Gnone? KDE? ? ? And there are strong lobbies for each who refuse to even consider another opinion. This, IMO, this is the biggest challenge for Linux. If I want to run Linux, I should be able to just take something and run.

As a new linux user, I had a number of perfectly good systems that it was not wise for me to run as they were made obsolete by windows. I was bamboozled by the number of distros available and really not able to pick. I finally just downloaded a bunch of iso's and tried each one out. The one that let me get wifi and print for a noob on the most different pieces of hardware (mostly ex windows XP) was the winner (Ubuntu Mate - I just could not cuddle up to unity)

Counter-thought on documentation. Is documentation the problem, or the complexity of products with 20 or so command line flags, 5 of which inter-op?

True. Remember when word processing software came with a documention BOOK? Modern software needs no documentation.

In reply to by Lewis Cowles

As a relative newcomer to Linux I can only make two comments...
documentation is something I have found lacking. Google has helped greatly and I do have some textbooks at hand (Unbuntu Unleashed 2017 & Ubuntu Linux Bible), so I get by. I have not pursued the "man pages" to any great extent yet but will get there too!
The last comment I have is...
Thanks to all the developers of Linux for their efforts. I am done with Windows.

Where could a charming gentleman such as myself contribute a small app that I made and cannot do without that works on every linux system I have used - which is many many? It's a TCL, wish command, load at startup thing.

Linux (desktop) is what it has always been, a hobbyist toy. I've used Linux since its creation. It still has poor documentation, low reliability, and is still prone to hosing itself. For example, I just updated Fedora. No sound. Yeah, I can fix it. Do hours of reasearch. Manually install drivers, rebuild kernel, manually edit config file, etc. But why? Just install Windows and it's going to work. 99.99 % of the time with no documentation needed.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.

Find the perfect open source tool

Project management, business intelligence, reporting, and more. Check these popular projects.