This will become a point of reference for future comments which seek to promote this or that favored Linux distribution. People tend to read some of my blog posts in isolation from the others on the same topic. Not much I can do about that, but I can offer mile posts along the way to sum up current positions in what, for me, is an ongoing discussion. This post is subject to modification as I become better informed.
Requirements:
1. If the distribution in consideration does not offer, at a minimum, three years of support for any past release, they will not be considered. As it is, three years is too short, but in an effort to be fair, I’ll start that low. Less than three years is out of the question — end of discussion. Now, to make sure we nail this down, I care not a whit if that support comes via volunteers in the user community, even third party, as long as somewhere in a quick Google search the common user can find a reliable resource for his/her distro which offers bug fixes and security updates, without major changes in how that user experiences the OS. Third party packages which are not updated for security or bug fixes, but just a one-shot enhancement, count as a failure. Be careful whom you recommend if you rely on third party efforts. Further, the whole thing fails if some simple GUI tool, or automated script, does not exist to handle the update process itself. If there is a simple way to add a repository without typing, that’s acceptable, provided users can typically find such resources without having to join a forum.
2. There also must be a 64-bit version. I don’t care about your biases, I know from personal experience on several different machines: 64-bit audio and video is better. That’s reason enough. More to the point, there is now almost no excuse for having a 64-bit system with tons of 32-bit media support. Flash, codecs, and such are all available in 64-bit in sufficient quantity and quality to satisfy most common users. And, if your 32-bit and 64-bit don’t appear to be virtually identical to common users, you aren’t trying hard enough. On a related note, unless you are intentionally targeting older hardware, there is no excuse for not making your 32-bit optimized on i686.
3. The dirty secret (not so secret) in Linux is lack of support for proprietary technology. Blame whomever you like; we don’t have legal access to all the multimedia codecs out there without paying extra money to the likes of Fluendo. For the average user, this looks like something is broken. As a work-around, the community has produced projects in places where such things aren’t enforced, and folks just download the product. Distros appropriately warn users they are on their own, even while it is tacitly acknowledged the distro’s user community makes it really easy to go that route. I maintain this should be an option for the average user, and making it hard is not acceptable. Let users take the risks.
Obviously, these three requirements eliminate the vast majority of Linux distros. This is not about how good they are as Linux, but whether they will meet the needs of the typical users I deal with every day in my computer ministry. The preceding paragraphs really are a minimum standard, just barely tolerable at that. I’m not asking anyone to suck up to cranky aging users, but to realize you won’t get your favorite distro onto more desktops until you decide these people matter to you. If you can’t find a way to staff a three-year support term for older releases of your product — the entire distribution — don’t bother advocating your distro for these discussions. If you don’t have simplified GUI tools for configurations, both 64-bit and 32-bit, and a way to grab multimedia support, you aren’t in the running. I know of only three major groups which come close to these requirements.
Ubuntu and Friends: This includes derivatives such as Mint, but excludes similar distros which don’t offer any long-term support for their stuff. Obviously, this excludes every release of X/K/Ubuntu not marked LTS.
Canonical offers one epic failure. There is no GUI tool for correcting a failure to detect video hardware. Not just on my current hardware, but I’ve had various incarnations of Ubuntu fail on several different machines. If it does not correctly identify the monitor, the common user is stuck. Why it is there is no tool for, at the very least, entering the basic specs of the monitor to get a proper display, I can’t imagine. This is broken. Of course, doing it really right means either listing a database of monitors with known specs, or some means to read a standard Windows *.INF file to get it. As long as Canonical does not add this feature, they cannot claim their product is for “newbies.” Fix this and Ubuntu could easily become my number one choice to offer ordinary users.
There’s been a lot of discussion about the GUI package selection tools, but Synaptic is what most people find when they go looking. This is great if you have some idea what you are doing, but I’d never ask a common user to try it without a long tutorial session. There is a need for a simpler version which lists packages in categories non-techies would recognize, and not list every package. Common users don’t need to know about liboddball 5.3-7. Just about everything else is tolerable.
openSUSE: Three year support is standard with every release.
SUSE sets the standard in GUI config tools. Nothing else comes close, because these tools actually work as designed and as advertised. Aside from complaints it is bloated (so is Ubuntu), the one thing which stymies adoption with the common user is the path to multimedia upgrades. Companies based in the US, at least, cannot offer proprietary codecs for all the popular media formats without paying the fees. For now, Novell isn’t doing that. Thus, users must take legal responsibility for such inclusions by adopting the typical Open Source work-arounds. Fine so far, but instead of simply leaving that open, SUSE releases broken multimedia apps which cannot use added codecs. These have to be replaced with versions which aren’t crippled.
If the user hunts down the community solution and tries the one-click upgrade, the process is pretty shaky. More than once, on different releases of openSUSE, I’ve encountered dependency loops which leave even savvy technicians befuddled. The community forums are loaded with complaints. Whomever is setting this up has not bothered to fix it when flaws are found. That is, it doesn’t stay fixed, or it isn’t fixed well enough. The script which runs YaST through a set of changes remains broken for 10.3 and 11.0, particularly on 64-bit. Further, something in the process too often corrupts the RPM database, and that fix is really obscure. This is an example of unofficial third party support which is unreliable, and I can’t recommend it. Thus, we are left with the original packages in their intentionally broken state.
There are other problems with openSUSE, but I feel they fall within the range of things we might expect from ambitious projects. I note no one is building another project from SLED/SLES because, while SRPMs are available for the main release, they are not available for fixes and updates. Non-subscribers get one annual roll-up service pack, and that’s not acceptable. So far, no subscribers have stepped forward to release their copy of any SRPMs, which is completely legal.
RedHat Clones: There have been several projects, but so far, only CentOS and Scientific Linux remain fully viable. Both of these have pretty much pledged not to do anything which breaks compatibility with RedHat’s product. If it runs on RHEL, it should run on those two.
I’ve had lots of trouble with Scientific Linux installations not connecting for updates, apparently because the default install does not setup Yum properly. This shows up on more than one release. Users are left with parsing the complicated Yum documentation, and there is no simple solution offered from the SL community. There are no user friendly forums I’ve been able to find. That leaves us with CentOS.
Because of RHEL’s standard seven year support cycle, CentOS more than meets the minimum. There are adequate GUI tools for most everything it does. However, the current attempt at putting a GUI on Yum is pretty bad. Further, the likelihood common users will want something not already bundled from RHEL is a given, so third party support is necessary. It exists in the form of RPMForge, ATRpms, EPL, etc. Further, it appears these are updated as warranted, so the support matches the longevity of the underlying OS. The packages found in those repositories do a great job of filling in the blanks for common users.
However, the means to including those extra repositories is not user friendly. Indeed, the whole assumption of CentOS is providing a free version of RHEL, with all the requirements of a very competent techie user. This is not what you offer to common users. That is, unless you repackage it. In this one thing, CentOS and RHEL shine. With some effort, CentOS could be repackaged for the ordinary desktop user. Take out all the server-centric stuff, add in a couple of third party default desktop comforts, with the source repos included in the updater by default, and the whole thing is much more reasonable. It may even fit on a single CD.
For this reason, my current project is aimed at taming and sweetening CentOS for common users. In the background, there is at least one developer working on something from scratch, a Linux meta-distro which could be added on top of a couple of other distros to provide a profile of enhancements most likely to satisfy the common user expectations. It is likely we will move away from the GNOME/KDE war completely, using something else entirely. The current candidate is ROX Desktop, but it’s loaded with eccentric defaults which may prove difficult to wrestle.
As a final consideration, I have worked a great deal with users suffering various forms of vision impairments. The totally blind users are wholly different category, and I am simply not competent with that, but users needing enhanced display and sound features I understand. For now, nothing matches Orca, which is currently tied to GNOME. I suppose we can say in all fairness, such a project will never be finished, but the version I’ve tested is 1.0, and it really falls short. From what I can tell, version 2.x requires the latest and greatest from GNOME, which is simply not feasible on my current CentOS 5 system. However, GNOME themes for high contrast are some of the best.
What does ’64-bit audio and video is better’ actually mean to you ? Better how ?
On the same machine, using various distros, testing both 64-bit and 32-bit versions of the same release: 64-bit plays smoother and fuller audio, dynamic range is broader, the video is cleaner (less fuzz and speckling), and a greatly reduced likelihood of jerking. This applies to audio and video feed from files on the drive, played from removable media, and from the Net. Yes, there are other factors, but if your hardware is 64-bit, chances are good it will have a subtle difference when you run it with a 64-bit OS and 64-bit apps and codecs.
Hi Ed,
as a programmer, engineer, and audiophile, I find it very hard to believe that the OS has anything to do with audio sound, dynamic range, or video cleanliness. Is this your perception, or do you have references that investigate this further ? Have you done double blind testing for example ? Jerkiness I could understand, but there are many more factors than just 32 bit vs 64 bit.
This is a completely different discussion from ‘how many bits do you use for your audio or video coding’ – obviously 16 bit audio is a huge improvement over 8 bit audio, and in some audio processing applications 24 and 32 bit audio can actually make a difference under the right circumstances.
I’m willing to be convinced otherwise with some evidence, but 64-bit hardware for your OS and programs on its own does *nothing* to broaden dynamic range.
Sorry, Thomas, but I can’t help you on that. I don’t footnote everything I read or experience. So while I remember reading some stuff which contradicts your assertion, it’s not important enough for me to chase it down again. The closest I come to blind testing is my wife sitting next to me, without a clue what I was doing except messing with my computer again. She heard me playing a test file I use often, and wanted to know why it sounded better. It’s altogether possible there are other explanations.
I’ll guess you’ll just have to remain unconvinced, while I continue on in light of my paltry experiences. That’s sort of what my original statment meant: You may have objective evidence to the contrary, but I’m convinced it matters on the basis of my experience. For reasons I may probably never be able to explain to everyone’s satisfaction, I’m not convinced the scientific method explains the full reality of human experience. You can safely ignore me, since I’m mostly harmless 😉
Pingback: Personal Preference: Debian Lenny AMD64 « Just Passing Through