Focus on Software

Simple Document Management System, djpim, Internal People Tracking System and more.
______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

I couldn't disagree more...

Craig S's picture

I used to be an avid Windows fan... Not so much anymore. But one area where I see that Linux needs huge improvement is in its configuration and the storage of the configuration.

Ok, let's face it, the Windows registry isn't that difficult to edit or modify. It's actually no more difficult than the 1000s (ok, may be hundreds) of text-based conf files you'll find scattered all over your hard disk in Linux (though 75% of these conf files are in /etc). Your grandma probably wouldn't want to learn how to read any one particular conf file and then edit it no more than she would want to learn how to modify the registry and edit that.

So we have a draw so far: both systems for managing configuration information aren't that bad, but they're not that great. Here's where Microsoft failed with the Registry idea as many Linux users have already expressed: the Windows Registry is an on-disk binary format file that requires special tools to view and edit. If something happens to the registry, you can no longer boot your operating system. This is a real problem. However, just because there is a problem with its implementation does not mean it's a bad idea.

So here's what I'm thinking. All programs that need configuration data could save that data to one spot: the Linux "Registry". This registry, however, would not be binary in format. It would be text-based so that it could be edited with any old text editor. "Ok", you say, "but you're still sticking your eggs all in one basket!" Here's how we get around that: should something happen to the registry, the programs would be designed in such a way that should the registry be unavailable they could look to another agreed-upon location where a configuration file would be stored. "How exactly does this solve the problem?" you ask. "Wouldn't we just have a million configuration files on the disk then, anyway, as we currently do?" No. Here's why: the program's configuration data primarily resides in the registry. Let's say something happens to said registry...now you're "screwed"--or are you? Nope. You pop in a bootable CD, copy a configuration file to the "failsafe" configuration script directory, and reboot. The program tries to read the corrupted registry, but can't...so it falls back to the preset location to find a configuration file. It finds one and reads the configuration and now is able to load. I would venture to say, however, that if your registry is corrupted, there are probably other things on your disk that are also corrupted; so this is not a big deal in the grand scheme of things and solves the problem of "if your registry is corrupted you can't boot and you're screwed".

Here's another area where the Linux "Registry" would be a good idea: most Linux distros adhere to the Linux File-system Base hierarchy pretty closely, but not 100%. This is often because of different technical issues between distros, sheer distro developer opinion, or out of "tradition" of the distro. In other words, Red Hat's file system layout is different than Debian's which is different than Slackware's. This sometimes causes problems with packages because they have to guess where a certain dependency library is installed. Sometimes, the package is unable to resolve the location of this library. The Linux "Registry" could hold the locations of all the libraries installed on the system so that packages could locate them. Also, this could aid in dependency tracking for the installation/uninstallation of software.

I know that Linux has the /dev, /sys, and /proc filesystems (and configfs) for device configuration (and let's not forget udevd). I'm not convinced that storing this information in the registry is a good idea, but it's certainly worth at least investigating. I do not advocate "hiding" the /dev filesystem/namespace as Microsoft does with Windows, however.

Anyway, these are my thoughts. In summary, a Linux Registry would aid in

  1. Software Configuration Repository
  2. Software installation/uninstallation dependency tracking, and
  3. Location of system libraries

In the end, there would be a place to store configuration scripts so that, in the case of the registry becoming unreadable, one could place a temporary configuration script should it become necessary. I would be very interested to hear your thoughts on this further. (BTW, I know that back in 2004 there was an attempt at a project to develop a Linux Registry...it didn't look very promising at the outset. I would hope to avoid its pitfalls.)

Regards,

~ Craig

Webcast
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers

Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.

Learn More

Sponsored by AMD

White Paper
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions