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.

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)
.