On January 25th the OSDL released their 2006 Linux client survey analysis, which identified the following barriers for Linux deployment on desktops:
- Application availability
- Quality of peripheral support
- End user training
- Desktop management issue
It is not that applications don’t exist for the Linux desktop, but users grow accustomed to certain applications that they just can’t live without.
Users report they are missing applications as Microsoft Office (OpenOffice.org is the alternative), Adobe Photoshop (which has The Gimp as the closest, but still far alternative), AutoCAD (with QCad as a very far similar) and others.
For peripherals, this is the list:
- Printers
- Personal storage devices (i.e. USB memory)
- Scanners
- Digital cameras
- Mail and messaging devices
- Web cam / video
- Smartphones
However, it is still difficult to buy a printer at your local electronics store and expect it to work out of the box on a Linux machine. While most printers are supported on Linux, there is still a lag from the time when a printer hits the market to when the driver driver is available and automatically installed on your computer by a commercial distro update.
And as a Linux user, I must add that when the device works, it usually won’t work with its full set of capabilities, because drivers are usually written by third parties on the OSS world – and not by their manufacturers, which are expected to have a much deeper knowledge (and project commitment) on these hardware capabilities.
So the problem is a committed application and drivers development. Well, how can companies commit themselves to develop desktop software (which means friendly to non-technicall users) in a world that had not decided yet about some elementary standards? Yes, there is the FreeDesktop.org initiative but the standards they are focused on are more related to KDE-Gnome interoperability.
Most important standards that must be defined will find their home in a layer bellow: LSB. But unfortunately, the Linux Standard Base still has a big job to finish and still seems to have difficulties to catch up with ISVs.
As an example, there is no de facto standard defined for things as trivial as a configuration files format for the whole system, not only for desktop apps. This is particularly important because configurations are what makes software run in a specific way. They are the soul of any software (while code is the body). A popular standard for configurations will provide ways for any software to collaborate with, and auto-configure any other software. On Windows, this was successfully achieved with its registry. On Linux, similar but broader and better alternatives exist (as the Elektra Initiative), but this is a subject that seems to not inspire the OSS community.
Standards bodies can’t do everything alone. The community must be ready for changes, adaptations, and have courage to throw away code that was not choosed by the standard, and start focusing on what was selected to be part of it. Courage to stop reinventing the wheel. For example, on a vanilla KDE installation you will find about 4 different media players (Amarok, Juk, kboodle, noatun, etc) and 3 different plain editors (kate, kedit, kwriter). If you have Gnome installed on same system, add a few more to each class of applications (and to the icons that will appear on your menus). This is confusing, fat and bad.
Another important fact on the analysis is a 49% desktop share for Canonical’s Ubuntu Linux, against RHEL and SLED with 16% each. RHEL and SuSE are more popular on servers and are essentially and structurally different distributions, but both use RPM as their packaging system. While Ubuntu is radically different from both, based on Debian, with the DEB format for packages. A well known and well used packaging system is very important on a desktop world, because this is what guarantees an easy, painless software installations and upgrades. So if I am an ISV with limited technicall staff and time resources, how should I package my software for easy deployment? DEB or RPM? If RPM, should I focus on Red Hat or SuSE flavors? Though questions.
Application vendors cannot afford to develop, distribute, and support applications across a fragmented Linux market.
Red Hat and Novell should look at their future server market, paying attention on what is happening today on the desktop. History shows that people tend to bring to work (and to servers) what they like and use on their desktops at home. This is Ubuntu’s long term strategy and they seem to be succeeding, at least on their first phase.
For example, on a vanilla KDE installation you will find about 4 different media players (Amarok, Juk, kboodle, noatun, etc) and 3 different plain editors (kate, kedit, kwriter).
Actually no. You get this if you install all available KDE related software packages, but I’d hardly call this “vanilla”
The only two programs listed above that are most likely installed in parallel are Kate and KWrite, since they are actually like two interfaces to the same program, one as a simple editor and one as a multi document editor.
However, there is always the possibility that a distributor has a different packaging and package combination policy and you might end up with weird “duplications” without having been asked.
Kevin, in real world, 90% of people that put themselves to install Linux, make a full installation.
Thats because they don’t know how to handle dependencies later, because this is a completely different task on each distribution.
The remaining 10% is people like you and me that sort of know what they are doing.
But, talking about myself, I use to make full installations too, because storage is cheap today, and I may not have the CDs available later.
“Full installation” is still a certain combination of packages.
Linux distributions have different philosphies how this combinations should look like.
Some install all competing applications of the same type in order to let the user choose which of them suites their needs best.
Some install a subset but still more than one application per type, e.g. Firefox and Konqueror
Some install just a single application per type.
Distributions have this differences because the either have or aim at different target groups. If a user does find a distributions choice overwhelming or too limiting, they are either not in the distributions target group, or have failed to communicate their problem with their vendor.
All of the listed packaging policies are OK and every user will likely prefer one more than the others.
Personally I like to do minium installations and then specifically install needed applications, so I chose a distribution that allows me to do that.