My Latest Opensource.com Column: Top 5 Linux pain points in 2017
 

Thanks again for your feedback and input on the topic.

https://opensource.com/article/17/10...nux-painpoints

--jeremy

1. Documentation

I think it just depends on exactly what documentation your talking about as to weather there's enough or not enough. I've found some really good documentation for different things.

2. Software/library version incompatibility

I can't say I've personally had much if any issues here, but I usually install stuff from repo's. So maybe that's why?

3. UEFI and secure boot

Don't have Windows anymore and my PC just has a normal BIOS (no EFI to be seen).

4. Deprecation of 32-bit

I jumped on the 64-bit bandwagon years and years ago now... so goodbye 32-bit stuff!

5. Deteriorating support and testing for X-forwarding

Never used it, so it doesn't matter to me. :)

Holdovers—and improvements—from last year

Funny you talk about suspend, as I just installed Fedora and that was one of the things I wanted to test (and did); Hibernate worked perfectly, but suspend to RAM well... I thought I'd just killed my PC, as I had to flick the power switch on the power supply to get it to boot up again, as it just kept going beep, and then turning itself off and then back on, with another little beep and just kept doing that, until I turned the power supply switch off and back on again.

Other distro's it was the other way around, suspend to RAM worked no problem but Hibernating it was another story.

Linux pain points
 

Documentation:

I run Arch - the wiki is awesome, so are the forums.

Other docs sites:

IBM has tons of Linux docs
Oracle has tons of Linux and Unix docs
Ubuntu / Canonical has tons of web sites and tons of docs
GNU (linux utilites and apps) has tons of good docs
TLDP has docs, but a lot are now dated ..
Dice has great man pages online

Don't be afraid to search in some other distro's docs - its not like cheating on your partner.

Compatibility (libraries and such):

Get stuff from your distro's repos - nowhere else
For must-have weird things, learn how to build from source (most packages have howto instructions)
try flatpak, snaps, appimage or nix (agnostic apps, packages)

Get good books and read them!

As far as the rest goes, learn to be a Google search expert (and/or Bing, Yahoo, Wikipedia etc).

1. Documentation

Hmmm!! Windows systems are not really any better with either O/S documentation or addon apps such as Office. I've been around Linux since the 90's so I am Ok with getting around Linux. But agreed, it's a more complex O/S for new users, what with no drive letters used etc. So documentation could be improved.

2. Software/library version incompatibility

This is a tricky one for many new users I am aware of. Comparing to a Windows system, user clicks an installer executable and it just does the job 99% of the time. Linux needs to improve even further to what's current on this, especially when there are other required dependency files needed. This needs to be automated far more without a new user having to learn a CLI instruction set to get these dependencies in place. It's easy for long term users to say well CLI is my friend. Remember we are bringing across new users from GIU only environments, with only icons to click on.

3. UEFI and secure boot

This is a given, as even as I saw one commenter mention, does not matter if one does not use Windows anymore, UEFI and Secure boot / EFI is now built into ALL motherboards. So any O/S used will need to be compliant. Linux cannot and has not changed this in implementation, but it can certainly dominate it.

4. Deprecation of 32-bit

Natural progression, and has to happen globally in both hardware and software by 2037. By this time we have to have ALL hardware and software running 64bit, the ultimate Y2K situation far worse than the past one, that many users are not aware of. And this includes our global Internet. So rather than try to fight it, a losing battle, embrace it and what it's benefits are.

5. Deteriorating support and testing for X-forwarding

Again natural progression, and a really old deprecated system, that has served us well, but it's time has come and gone. And we need change to use the new features of current and future technologies. Again embrace it as the future, Wayland will be our next rising star for all of it's pro's and con's, like anything new.

Holdovers—and improvements—from last year

This for me as a long term user is my BIGGEST bugbear, and the proprietary lock of necessary drivers and technologies etc. WHICH SHOULD NOT be the domain of certain greedy corporates. Hardware and it's support through drivers is now a global daily function, and this iron fist grip needs to be smashed, plain and simple. Why should the proverbial PC suffer, when great strides are made in the 'droid mobile world.

But 'nix's are definitely making great inroads and are impacting our daily digital lives. So hopefully very soon we will realize a level playing field with 'nix's being right up there in the user world, beyond mobiles.

I am glad this was brought up. I have to have x11-forwarding for work. I spend the day sshed (is that a word?) into other machines. I don't need much forwarded, just my editor.

Even at home, I have VMs that I ssh into to support other distros or versions of Slackware. This is how I get around 2. Software/library version incompatibility.

And, realistically, I will need this for the next 10 years. Companies still use RedHat 6, (heck, some still use RedHat 5!) RedHat 7 will be around for a long time.

1. Documentation
Imagine someone who really loves linux, but is in life science. There were never *any* computer science classes, no scripting, no experience with clusters, doesn't know Bayesian from Boolean, and is basically forced to use Windows all their lives at work. The majority of Documentation out there is made in good faith, but falls short of describing "everything" or uses jargon unintentionally. And if only the document formatting was consistent! Not Foo or BAR or <brackets> that [change], or indenting that is important and/or automatic. Geeze even Markdown must have 5 or more flavors now. The ROI on your time isn't good. The number Linux distros alone is intimidating. There is a general file format of a Linux install, but even those folders off the root change with different distros. Something at the beginning of the learning curve needs to be invariable and easy. This isn't a rant (kinda sounds like one but that's not the intention). I just wish when someone says RTFM, there was really only one manual to get started reading.

2. Software/library version incompatibility
Don't see how this can be avoided. I think Linux does way better than other OS's

3. UEFI and secure boot
I've been running linux for ten years but still have to google what those terms mean. So no qualifications to discuss these topics.

4. Deprecation of 32-bit
Yeah, sorry about that 32-bit, your days are over. Would still like 32-bit drivers for peripherals though.

5. Deteriorating support and testing for X-forwarding
Back in the eighties using X always seemed to be unstable, or slow. Stopped using it back then.

It would be great if there was a "beginners linux" that was highly secure, and didn't change for several years.

Perhaps documentation is never good enough for any software, but in general I have found all the documentation I need online for Linux as someone with no prior experience so it cannot be too bad!

Documentation: I have experienced this in a few cases. The worst case was Manjaro documentation. The best documentation I found in the Linux community was from Arch. If developers would use Arch as an example on how to produce documentation it wouldn't be listed as a problem.

1. Documentation: A lot has been made of Linux community support and active forums and yes there is a lot of information "on the web" in user forums etc. but the problem is when you do a search for something you get a lot of "answers" from 5 or more years ago. Or for a different release than you've specifically included in the search terms. A lot of it doesn't apply to current distros/releases. Especially for a newwer user it's hard to tell what does and doesn't apply. This problem is not just confined to Linux. Look up some Windows problem and you'll still see "answers" for Windows 2000 for example even if you specify Window 10. There doesn't seem to be a way to sort out new posts from 5 or 10 year old posts. Plus the search functions within a particular forum don't seem to work that well. And that leads me to another point. You see a lot of responses to questions with "this has been answered before" but it's likely the op couldn't find the answer so that's why they are asking. "his has been answered before" is not a helpful response especially when the link to WHERE this has been answered before is not provided.

4. Deprecation of 32-bit: The reason a lot of people get introduced to Linux is because they don't want to buy a new computer just because Microsoft obsoleted XP and Vista. These older computers may have 64 bit processors but not much RAM. I've never found a definitive answer but from what I can tell 32 bit is preferrable on low RAM machines. Since the beginning of the year I have converted at least a dozen from XP or Vista to Linux for customers. I have a couple in the shop now. They are lucky if their old PC has more than 1GB or maybe can even take much more, if they were willing to buy it. Every one of these customers are now happy Linux users. I use Lubuntu 32bit on real low spec, Mint XFCE 32bit on 1GB machines and Mint XFCE or Cinnamon 64 on the better ones. The next computer they buy will have a 'modern' processor and lots of RAM but if they hadn't already been introduced to Linux it will probably also have Windoze.

I'm surprised to find documentation at the top of your list. One of the things that drew me to Linux was the abundant documentation. There's no documentation at all for Windows that I know of. Oh, there are loads of books and articles on how to do things in Windows but none at all on how Windows works or how to fix it when it doesn't work. If I want to know how some part of Linux works, there are loads of articles out there.

My chief grouse is that the less common video cards are so poorly supported. I have an old laptop with Via graphics and the video only works after hibernation if I use hooks to unload the driver when shutting down and reload it on waking up. I never did manage to get it to wake up after sleep. I know what people say: don't blame Linux for that, blame the hardware manufacturers. But it's still a nuisance.

Problems with package management
 

This is not an intrinsic Linux problem, but my most vexing experience was with packages of binaries, supposedly prepared to make life easier than compiling and linking a program with extensive dependencies from sources, that contain versions of dependent programs or libraries that are incompatible. Most packages continually update all versions of all constituent code to the latest without testing the final result. Reporting bugs to package managers has not met with timely responsiveness.

As a Linux user in the last 18 years, I think I have some kind of overview. Indeed, the listed ones are probably the most painful problems. Interesting to see the first two problems and the last one are persistent, they were problems in some form 18 years ago, too. The other two did not exist.

1./ Documentation quality, IMO, can be very different. Too often software is well documented for S/W developers, less for simple users. There are many solutions that are evident for software people, unknown for users. I wish more user level documentation.

2./ Software compatibility. This used to be the hard part of Linux usage many years ago. This has basically changed, IMO mainly because most popular distributions have a really huge collection of applications and those programs are compatible with the rest of the distribution (with some rare exceptions). Installation of programs not available in the distribution repository still might start a long battle. Things evolved much, but I still find several programs, which require a special version of a library program, that is not available in the repository, as it has already a newer version. One can simply put a link to the newer one, this often helps as they are compatible. But when you need to do this 10 times for 10 different library items, is painful. And from simple Linux users you can not expect to play in the libraries! Software developers should take into account their programs are not only developed for that single Linux box they are using!

3./ UEFI is a big devil, I was afraid of it. However, since its omnipresence I have installed 3 Linux systems without problems. It seems to me the popular distributions can correctly handle this feature.

4./ The 32-bit problem is something new. Newest distributions do not any more deliver 32-bit libraries but a few programs require them. Installing these might be a problem.

5./ I have never had problems with remote X (if you mean this with X-forwarding). For me it was always working, from other room, other building or even from another country. I think this is one of the strongest features of Linux. As I heard with Wayland the life will not be easier, because of its strict access rights policy. I think here the developers should really keep usability in mind, consider use-cases in large scale. Security is important, but can kill usability.

Another general remark. It is interesting to see, in the Linux landscape sometimes old problems, that were thrown out through the window reenter again through the door. A new example: when KDE changed from 3.5 to 4.0 many users remarked they were unable to put different wallpapers to different desktops. Developers corrected this after a while. Now, with KDE 4.16 the problem reentered. Why? Did developers forget the previous fiasco? Similar problems were observed in LibreOffice, too.

I'm an low-average-skilled GNU/Linux young user. In these days i'm reflect about some overall issues and I wrote and sent one mail for Gnu.org criticizing some aspects of their philosophy related to application of these in year 2017/18. For me the principal issue live in a obsolete way to approach to present-day end-user which isn't the same of the 80s-90s: in the past computers are less pervasive in the common life and their users were often skilled or desiderous to become skilled, often for carefree passion; today everyone use a computer or a similar device for real need and many people are unskilled or poorly-skilled, but also they don't have enough time or possibility to progress as required (for example in many work context where isn't required any specific skilling into computer science but where computers and its productive and reliable utilization is important however).

Anyway I now comment your points:

• Documentation: The issue isn't the documentation itself (internet is full of guides, handbooks, wikies etc...), but the time or other efforts needs for face them; I think that today every task should be intuitive, self-documented in its structure and design, and confortable, indipendently from their docs and many of these tasks aren't so good, including some principal or common operations (which have poor human-readable sintax and strangely haven't an official GUI or almost an Ncursed-based interactive front-end after 25 years of development, for example about querying hardware and drivers supporting, kernel modules, processes status etc...) and above all their many various possible unexpected or expected results which ofter require too much tricky countermisures. Seems that Linux is a toy for playing rather then a productive tool; twenty year ago this could was forgivable, but today no!
• SW compatibility: Dependances chains are often too much rigorous, and sometimes beyound any justification; they waste user freedom in many ways and compromise in various manners the strenght of the GNU/Linux via dispersion and confusion (why so high number of precompiled packages standards for example??? Why those wars between init scripts or desktop environments etc... when instead could be sometimes better join development forces, at least for core packages???) Official repositories are a much riskless source of SW, but often they don't offer every SW needing, and sometimes neither very popular and usefull utilities. Packages require too much updating tasks... Too much often... SW too much faster become obsolete and packages which don't join themselves to this bad trend fastly become badly-supportable. For me OS should allow to install more versions of the same SW/libraries, allowing also less stifling dependances built and developers should be much careful about retrograde compatibility.
• UEFI: I haven't yet issues with UEFI. I cannot say much.
• 32bit: See SW compatibility point.
• Xorg-server: X is too old but seems that many people don't see this; Wayland is itself mature but isn't well supported by many important packages... We need a new mainstream project which could become a standard tecnology.
  

I'm interesting to known your point of view about mine. Contact me please if you would known more.

Maybe the software compatibility thing is over-represented due to some particular Slackware specific thing in the last year? For example, I noticed the AppImage for the popular painting/animation program Krita required a newer QT than what Slackware provided. (But otherwise, it works well with other distributions due to newer QT.)

More broadly, the popularity of Debian would tend to produce a sudden drop in software compatibility issues just after a Debian Stable release - which just occurred last year. So more broadly, I'd expect an overall drop since Debian is popular. But the cycle repeats itself...as the current Debian Stable gets more and more stale, you see more and more software compatibility issues. Users want more recent software, and/or use AppImages etc...

Yes there are wonderful Linux references like "how Linux Works" by Brian Ward which can be downloaded at
https://ebooks-it.org/1593275676-ebook.htm and "The Linux Command Line" by William Schotts at
http://linuxcommand.org/tlcl.php. I liked these so much I actually bought the hardcopies.

But Linux references like the above are very general. When you are trying to learn the details about some particular program or package it's not so easy. For example, grub uses os-prober to build the list of OSs installed. Somehow it determinss what to call each item on the list. But where does it get the names. After much searchinbg, I found out where in Linux partitions, but not in Windows partitions. What is the program that adds the ability to drag and drop shortcuts from Firefox to the desktop on Pepperment but not on Lubuntu, even though both are LXDE? ...etc. Whoever made the distro or wrote the program know, but it's not well documented and not easily found by searchoing on line.

I've been working on Windows for 20 years and have bought lots of books about the various versions but none have really told me so much about how Windows works as the above-referenced for Linux, and definitely not very much about how to fix it. I've found that they all had large sections that have told me how to do things I already knew about or didn't care about. On the other hand, how to do things in the Windows GUI may be much easier to find out than for a particular Linux distro, because there's too many different distros even within the same family (i.e Mint Cinnamon, Mate, XFCE...) and the documentation for the average GUI user is not complete. The command line scares off most people.

BRVCF, the reason for preferable 32bit O/S on low RAM systems, is that 32bit mathematically cannot resolve more than 3.2GB of RAM. So this is the reason for older machines where RAM is not available on the market anymore to upgrade, and the unit might only have 1GB, 2GB or 3GB. If they had 4GB, then one could upgrade to 64bit, as 64bit can exceed the limit of 3.2GB.

BUT as I said in my post above, 32bit processing will have to eventually disappear completely. And that is not just because of a whim, but the ultimate of Y2K issues in 2037.

Regards
Andrew

Last time I checked, 2 raised to the power of 32 was equal to 4 GB, not 3.2 GB.

I don't see that it is specifically how much RAM can be resolved that matters. Both resolve up to 3.2GB. The way I understand it is that 64 bit uses twice the space for addressing, etc. thus all things being equal the code will use more resources and on low RAM systems and this is a performance hit that outweighs whatever other advantages 64 bit has. I see lots of on line forum discussions/opinions about this and the concensus seems to be that it is better to install 32 bit on low RAM systems even if they have 64 bit processors. But so far I have found no clearly authoritative publication.
I don't see that as a problem because by that time, I doubt there will be any computers around that have only 1GB or RAM or can't handle 64 bit. But there are tons of low-RAM computers that will probably keep running for another 10 years. It would be a shame that Linux goes the way of Windows and forces obsolescence of hardware by upping the minimum requirements too much.

Documentation
 

Not sure how Documentation has the #1 spot. Are voters reading the documentation? Only thing I can think of regarding documentation is so much of it is way over my head, I don't blame documentation for that... even Windows documentation has improved, it used to be like auto-mobile owners manual "problem: car doesn't start, solution: put key in ignition..." anyhow, after 7 years of Linux (i still love it) I doubt that I will ever become a programmer/coder, the languages just don't click in my brain - I've done a lot of PLC and DCS (industrial) programming since Windows 3.11 but using proprietary tools/software that others built and working within the confines of such, and still do, ABB (formerly Elsag/Bailey) Network 90, Infi-90, CADEWS, ConductorNT; Fisher-Provox; Rockwell A/B PLC-2,3,and 5, SLC500, Compact Logix, and a little Control Logix; TI-530; Modicon 980; GE-Fanuc; DSM; CPP; Opto22; (Function Code; ladder-logic; SFC); Trace Environmental; Vim; EMCS,,, a few others and learned all of them usually within the year I start, but that ain't happened in Linux coding - so i do the alternative, look for what fixes other peoples similar problems and apply it with the vaguest sense of what the fix is actually doing - i write a lot of my own documentation when solving a problem or learning a new task (gleaned from resources already available) just so it sinks into my brain for next time. Now all good things must come to pass, like with a rolling distro when you get an update that is near flawless beautiful, you can't hold on to it because it will soon be obsolete and its upgrade maybe bumpy for a the next until when??? Its all good - my hats off to the minions that develop, and support all aspects of Linux code, packages, docs, etc - what a great bunch of awesome humanity!

My point wasn't that documentation is bad, but that so many flavors of Linux are being developed, the documentation is impenetrable for a beginner. Where do you start? (And if you ask that question, how many answers will you get?). Only speaking for myself, and a recent example, installing a driver for an eSATA card was easy in CentOS, but obscure in Ubuntu. The docs are out there, but for slow-witted old folk, those four penguins in the upper left corner represent days of the week! If there are gonna be 100 Linuxes, there needs to be a common core for beginners, or Linux will remain the language of the computationally elite, and may code itself into extinction.
I couldn't agree more! My 32-bit linux box at home was the only hope for turning my old 35mm color slides into digital images, and the SCSI card driver worked perfectly.

Things need to be made more consistent. For example, in Mint 18.2 XFCE menu the system settings category is "System" but in Cinnamon it is "Administration." Minor difference but if you are trying to tell a non-technical newbie how to do something, or write a user guide, it is a problem.

Slowness in startup and sluggish execution.
==========================================

I wish there was a converter from java or javascript to C or C++ or to another compiled language.
The things I am reading about Linux boot up and execution from the web have to be with slow boot and with sluggish desktop functionality.

Linux should boot from an SSD in 10 seconds, From a spinning disk, in 20 seconds. Because of JS, it's much much longer.

My experience with converting optimized shell script code to C execution was a 100 to 1 gain.

A shell script that ran in 15 minutes in C, (doing the same single thread activity), required two seconds with the C code.
A C/C++ object can complete it's actions about 10 times faster than the quivalent javascript item.

Its time for more courses about using Linux to appear on the web. We need at least 2 to 4 youtube examples to show installation of Linux for single boot or dual boot. We as a society have cellphone-itus. If it takes two minutes to read the explanation about a topic, we quit. Its TL;DR syndrome (Too Long; Did not Read)
.