MindlessCode.net

Hi Folks,
I’ve decided to draw up a list of what is wrong with Linux, why people avoid it, and what we can do about it (Note: This is mainly an idea-gathering post for Icewater). Here’s my list, please leave comments and add to this list!

• Hardware Driver Installation: Nooo! Not this can of worms. But seriously, hardware installation is no easy task under any distro of Linux. One of the issues (problems?) with Linux Hardware Support is that most drivers are very dependent on the version of the kernel that you are running. For example, the Linux Drivers for my SmartLink modem will compile under 2.4/2.6 kernels. However, the a module compiled for 2.6.8 won’t work on 2.6.9. Outch! This makes distributing binaries a very hard task. Solution: Provide binaries for many different versions of the kernel. Solution 2 (better): Try and patch kernel version magic.

  Installing drivers is another issue. Usually, RPMs (or native packaging tool) used on are used to install drivers. This isn’t a problem, but RPM doesn’t have a very friendly (GUI) interface (read: none at all). Sure, rpm -ihv smlink-2.9.10-i586-1ice.rpm may be easy for some, but not for Joe Average down the street. Solution: Write a GUI interface for RPM.

  The last issue (that I can think of), is automatic detection of hardware, driver installation, and device setup. Windows XP does a good job of this (in terms of printers–not sure about other hardware). HAL is an awesome hardware detection daemon, using D-BUS for notification of hardware being plugged in and unplugged. A seperate daemon would be needed for setting up hardward that require one-time configuration (e.g., printers and scaners). HAL+D-BUS take care of hardware like digital cameras, which require no configuration. Yet another daemon should be dedicated to interacting with the user through their DE. E.g., if a digital camera is plugged in, ask the user if they would like to start digiKam. A printer being plugged in would tell the user that it had been configured and was ready for use. A scanner would ask to start Kooka, etc. Solution: Write a daemons to deal with hardware configuration, and a daemon to deal with user interaction. Glue them together with D-BUS and use HAL as the back-bone.

  Take a look at this article for more ideas: http://www.ometer.com/hardware.html

• Software Installation and dependency installation. Solution: Yay Autopackage!

• Integration of programs with the users desktops. Again, D-BUS is really helping here. We’re still having problems with Gnome apps not likeing KDE and KDE apps not liking Gnome, etc. In the “perfect world”, the user wouldn’t be able to tell if a program was written using GTK or Qt, or implemented with gtkspell or KSpell. Balloons from Kopete would appear under Gnome. If you hit Ctrl+O in the Gimp, and you are running KDE, a KDE open dialogs with full KIO support would pop up, etc. But…this isn’t the perfect world. Even as KDE and Gnome are agreeing on standards, there is still a lot more that needs to be done. Recent Files for example (implemented by Gnome, but not KDE), and the system-tray protocol. This is implemented by the Giam folks, but KDE (and Gnome?) still need to implement it into their development API. Solution: Patch, patch, patch. Write patches, submit them. libdialogs is part of the solution (I don’t suggest using it now, however!). Patches need to be written for the system tray, recent files, D-BUS needs to be implemented into Gnome programs, rip out DCOP for KDE and replace it with D-BUS, etc.

Any other comments please post below!

This entry was posted on Sunday, March 13th, 2005 at 12:52 pm and is filed under Linux. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.