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

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState