Go to
Prem Kurian Philip's Home Page
Things I would like to see in Linux
I have used Linux since 1994 when a friend of mine managed to get his dad to bring him a Linux CD from South Korea. During this time, I have seen a lot of changes happening to Linux. And each year, I get the same question being asked:
Is this XXXX the year when Linux conquers the desktop?.
The answer has always been, =it may be, if these x issues are sorted out.=
These are my list of x issues which needs to be sorted out before Linux hits the desktop big time.
1. Better Device Driver Management
Everytime I mention this I get flamed by Linux fans who claim that Linux supports more devices out of the box than does any other OS in the world. They are right to an extent - yes, the Linux kernel has more drivers in it than the MS Windows XP or MS Windows Vista installation CDs.
But they forget the fact that most hardware comes with Windows drivers and these can be easily installed using a setup.exe installer. It is not necessary for MS to ship these drivers with the Windows installation CDs. This is possible because Windows supports binary drivers. You can have a MS Windows XP Service Pack 2 installed and then install the same device driver as when you had MS Windows XP Service Pack 1.
On Linux, a driver compiled for version 2.6.x of the kernel cannot be installed on a computer with 2.6.(x+1) kernel and vice versa. The user will necessarily have to compile the driver into the kernel statically or have it as a loadable module. The drivers will have to be recompiled everytime the kernel is updated.
This is because Linus and other Linux developers are against supporting binary-only kernel modules. They are also not willing to freeze on an interface for drivers.
Manufacturers such as Nvidia and ATI get around this problem by supplying an interface code themselves. To get a binary driver from Nvidia or ATI into the Linux kernel, the interface code supplied by them must be compiled and installed into the kernel. Note that Nvidia and ATI do provide the pre-compiled binaries for the interface code for various kernel releases.
However, this is at best a cludgy implementation. In my humble opinion, it would really help if the kernel developers froze on a driver interface layer which allows for binary only drivers and which allows binary drivers to be installed across kernel releases without requiring specific driver binaries for each point release of the kernel.
Supporting binary drivers has the following advantages:
1. If binary driver support is available, it will become possible for device manufacturers to release Linux drivers along with their installation CDs.
2. This will also mitigate the need to store all the drivers in the kernel source tree. The kernel source tree will become much smaller and therefore kernel updates will require downloading a much smaller file.
3. A trusted driver repository could be created on the net allowing users to update to the latest drivers by using a simple driver update mechanism which will download the latest version of the driver and install it on the PC.
LICENSING ISSUES: One of the primary problems with binary drivers is that it would violate the terms of the GPL
2. Better Configuration Management
On Linux, applications store their configuration across multiple directories in different files with different formats. To compound this problem, the different Linux distros each store the configuration files in different directories.
Linux desperately needs a configuration management framework which provides the following:
1. A standardized API for reading and writing configuration settings
2. Creation of configuration entries in XML format in prescribed directories
3. Provides the storage of configuration information across the network
4. Supports a robust access control mechanism
5. Supports reading and setting configuration across the network thus allowing the usage of automated configuration management tools in a enterprise environment
6. Supports versioning of configuration settings
7. Supports rollbacks of configuration settings
8. Supports installers
9. Supports human readable and editable configuration repositories
I believe Java is an excellent choice for developing such a configuration management framework. Java supports a rich configuration management API allowing configuration to be stored and retrieved from XML files, from properties files (name=value format) etc.
3. Better User Interface Framework
The current crop of user interface improvement occurring on Linux is more towards adding eye candy than actually working out the usability issues with the interface. Beryl and other efforts are focussed on adding 3D to the user interface and adding transparency and the like. But the problems with X remain.
Some of the issues with X which irk me are:
1. It has its own device management layer for handling everything from the graphics card, to the input devices, the printer etc. Handling the devices is the job of the OS, why is X having to deal with this? If the Linux kernel is compiled with support for a particular graphics card, X should be able to detect the card and use it without any issues. Alternatively, (see point 1) if a binary driver for a graphics card is installed, X should be able to automatically start working with this card without requiring the usage of tools such as xvidconfig etc. Many distributions have their own edition of tools for dealing with X configuration and this further compounds the pain that is X.
2. Mice sensitivity - I often have the problem with the mice being too sensitive on Linux.
3. Configuration management of X apps is a real challenge.
4. Default class library for Linux
I would love to see a rich class library for Linux. This class library should allow for reusable objects which can then be used across the system. An example is, if
OpenOffice is installed on the Linux PC, then
OpenOffice could
expose its functionality as objects which can then be reused by scripts and other applications on the PC. Perhaps, a scheduling client could use the
OpenOffice writer object for its content edit control and then use the SMTP object installed by thunderbird to shoot of a email to a contact picked out from the thunderbird's contact list object.
This implies that the class library must support something similar to JNDI allowing applications to
register their objects with them and allowing other apps to query for and retrieve an instance of this object. Something like this is doable using existing technology available in Java. I am actually veering towards preferring
Java for this class library.