Posts Tagged ‘Linux’


June 29, 2008

These are a few of my most important concerns regarding Linux in general and are not distribution specific.


Because of the rapid development of many programs it seems to me that documentation is rapidly falling way behind the curve. All too often the information is so out of date that it’s almost useless. Conflicts abound between versions. Most documentation is still based on using the time honored command line editing and information programs, but high-level GUI programs are ignored as if these newer programs don’t exist. That’s fine for experienced users, but confusing for newbies. If we are to capture the market and lead the Linux revolution, documentation needs to be up to date and easily accessed by GUI. More interactive tutorials that pop up after an installation are needed.


The current Windows-based model for hardware drivers is a mess. There’s too many incompatibilities, especially when manufacturers change chipsets even in the same model. Why should there be separate drivers? Some years ago there was talk about a universal driver layer for the operating system that a new peripheral or card could communicate with and automatically configure the system. No kernel driver would be required. The driver would be in firmware on the card, but not accessed by the OS. The chipset would identify itself to the kernel, tell it what it function it provides and that would be all that is required. After all, firmware in most cards now can identify themselves to the OS. It would take only a bit more hardware programming to make this possible, and companies wouldn’t have to release drivers or hardware information to third parties.


Hardware detection in Linux has gotten a lot better in the last few years, but there’s still some problems with chipsets that aren’t directly on the PCI bus or ISA plug and play, especially with newer motherboards that have softmodem chipsets. As an example, on my new Averatec 7155 laptop, a state-of-the-art computer at the time I bought it, I had to go through many hoops online finding information about the High Definition Audio (HDA) chipset so I could find the right modem module. I finally got it working by having to compile slmodem with ALSA support – yes, the driver and chipset are part of the sound system! Hardware detection simply can’t see it, although on installation (PCLinuxOS) it found and set up the sound chipset just fine.

However, this problem goes back a few years. The classic IBM Thinkpad 600 had a DSP modem and a Crystal 4236 sound chipset that wasn’t ISA PNP. Earlier hardware detection, for example Red Hat 6, couldn’t see the modem, but could detect the sound chip and set it up. Later versions couldn’t see the sound chipset; this must have been when kernel 2.4 was released. I don’t know why, but workarounds were found to make it function. IBM released the Mwave modem driver and daemon sourcecode, and upon successful compile, installing the module and daemon, the modem would work, but the hardware detection still couldn’t see it. I used this old laptop as a test machine until recently I decided to give it to a friend. I installed Puppy Linux on it and it recognized the sound chip! SUSE 10.2 also found the sound chip, but there’s still problems getting it to work; it still doesn’t see the modem chipset. Why should this condition still exist?

Why are some distributions excellent at hardware detection and others not? Because Linux is open source and all code is available, it would seem that the distribution builders could find and use the best code from other distributions and include it. When better code is written, that should be incorporated. It’s Open Source – steal it!


Whether from a standard CD or DVD install set or livecd, most Linux distros must have all possible hardware drivers available, from the Xorg video drivers to kernel modules. Most distros install all of these, taking up unnecessary drive space, usually not a big problem with the size of current hard drives. The biggest part of a kernel download is modules, most of which aren’t needed for a specific machine. There are hundreds of modules on any Linux machine that will never be used! They must be included because of the diversity of available hardware. The kernel itself is perhaps 1.4MB, depending on what support is built in. Some extra modules are needed to support PNP devices or services software that might be added at any time, but module support for built-in devices is usually fixed for any specific machine. The hard drive(s), video card, monitor, sound card, usb, firewire, pointing device, etc., are usually built into the motherboard and aren’t usually changed. There is needed a more intelligent installation procedure that only installs needed drivers. In the case of kernel modules, instead of installing all of them, why can’t it install just the needed ones seen at install time and allow the user to install others from the install media as requirements change?


There is still needed a Linux distribution for dummies that won’t allow them to change or bork anything at system level. Freespire and Linspire haven’t lived up to their hype. Too many computer users don’t even know what an operating system is or how computers work, they just want to get work done. Newbies and the computer disabled are confused by too many options that they may not need to know. Even installing Windows is too much of a hassle for most people, after all, most people get Windows already installed. Because Linux is so scalable and configurable, let’s limit their choices and give them something that they can’t break. Such a distribution might be offered pre-installed on a new computer or would install from a live CD or DVD and automatically set up separate swap, / and /home partitions, recognize Windows, if installed, ask if the user wishes to delete it or resize the Win partition, if needed, and after a successful install, a tutorial would pop up telling the user what application to use to get and install more packages. Root wouldn’t be accessible, except in limited cases using su or sudo. The package repositories would be fixed and wouldn’t allow installation from any other distribution’s repositories. No compiler or development files or other package manager would be included, although they might be available in extra repositories that wouldn’t normally show up in the installer. No Internet server software would be available – it should be exclusively a workstation distribution. A firewall should be set up automatically during install with no user option to turn it off. This distribution might be sold with phone or web tech support to help with installation problems, with the option to buy extended tech support.

The development team should choose the best packages for user friendliness. Alternative packages that duplicate functions, as in most major Linux distributions, simply wouldn’t be available, thus limiting unnecessary confusion. How many movie and MP3 players do you really need? There should be an option for automatic updates if the user chooses. This system should include Open Office, for example, and all other basic applications for home or SOHO. However, the menu selections would not reference applications, but what function a user wants to do, i.e., write a letter, get/send email, browse web, etc. Whatever desktop is included would be fully configurable, as in other Linux distributions, but don’t give the user another desktop choice. Do give them tutorials on how to configure the desktop and all applications. These restrictions create less problems for the development and packaging teams and make the distribution a more viable option.

I propose we call it KISS (Keep it simple, stupid) Linux.