Focus on Software

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

I sure see a lot of requests to do things the Microsoft Way, but I see little sense in it. A number of recent converts want to get away from Microsoft for whatever reason, but then expect everything to be done in the Microsoft way. I would never even mention Microsoft except as a bad example. Now I hear a cry for a Linux registry. Good grief, Charlie Brown! This is one of the elements in Windows that causes more problems than it solves. Why move simple, easy-to-read and edit (okay, not always so simple to read) files out of /etc and cram them into one large file that requires special tools to edit? I vividly remember a promise that the Windows registry would never have to be edited, that it was only for use by the system. To date, I have never seen a Windows system that did not need the registry edited. But I guarantee the learning curve on the files in /etc is a lot less steep than the Windows registry. So before screaming for changes, why not make sure that whatever changes are proposed are changes for the better? Linux needs to improve, but a Linux registry will not qualify as an improvement.

Simple Document Management System:

This simple document management system is exactly what it says it is: simple. It is simple to install and simple to use. I've seen other document management systems, and while this one does not seem to have all the flair of some others, it works exceedingly well. The nicest part is that it uses a web browser. That document you need that's halfway around the world is now accessible. Of course, if it's a sensitive document, you'll want to use a secure web server. It uses ACLs, so you can restrict who can do what with the documents. Requires: MySQL, web server with PHP4 and MySQL support, a web browser.


This utility, called Daryl Jones' Personal Information Manager (djpim), is a well-implemented web-based information manager. It can be used for a number of things, including tracking projects within a department. As a “Personal Information Manager” it lacks an integrated calendar. You can pop up a small calendar in two places, but it's not quite the same. Other than that, if you need to be reminded of a list of tasks, this utility is aesthetically pleasing and well organized. Requires: Web server w/PHP and MySQL support, MySQL, a web browser.

Internal People Tracking System:

If you have folks scattered all over town, or worse, all over the state, you can keep track of them with this little tool. You might want to add or change some of the IN/OUT information provided in the web page, but that's easily done. The most difficult part of using IPTS is going to be making the employees use it. Requires: MySQL, web server w/PHP and MySQL support, web browser, and Perl modules: HTML::Template, CGI_Lite, DBI, and DBD::mysql.


If you have very sensitive data, you can use this utility to break up the data into multiple, encrypted files. By putting each resulting file on a different server and telling someone where to find them, only someone with access to all the files can reassemble them. No password is required to encrypt or decrypt, but it is necessary to have all the required files intact. The only disadvantage is that your storage requirements will, at a minimum, double. Requires: libcrypt, libm, libc, libdl.


This shell script makes sure the services you want running at all times continue to run. If they are not running, it restarts them and sends you an e-mail. No more wondering if all the services you need are running or not. If, for some reason, the service can't be restarted, you'll see that in the e-mail message as well. Requires: a Bourne shell, recommends cron.


Just what we needed, another system performance monitor. But wait, this one is a little different, and you might want to take a second look at it. It boasts a couple different modes and supports multiple CPUs for those fortunate enough to have them. You can see a graph showing each CPU and its memory or view a histogram of each CPU's load one at a time. Requires: libslang, glibc, libdl, libm.


For all you market wizards out there, GtkPortFolio is a very well-done quote downloader. It's easy to use. This is what is really better termed userware. Want to add a symbol? No need to edit files, just put the symbol in the Add Symbol box, and it will be remembered. Don't know a symbol? Put the company's name in the search box, and it will open Netscape and show you the symbol(s) it found. It's about as simple as it comes. Requires: Perl, perl modules: Gtk, Gtk::Gdk::ImlibImage, Finance::Quote, Finance::YahooChart, Time::localtime, LWP::Simple.


If you've ever used Netscape, you know how large the cache can become. Or maybe you don't, but let me tell you it can get very large. This utility allows you to use a GTK GUI to browse through your Netscape cache. You can select from two views: tree view or sorted view. The sorted view allows you to see the various entries sorted by URL (default), size, access time or mime type. Both views allow you to delete any file in the list. Now's your chance to dump some of those really large cached files. Hit the sorted view, sort by size, scroll down to the bottom, right click on your largest entries, select delete and recoup some space. Requires: libdb, libgtk, libgdk, libgmodule, libglib, libdl, libXext, libX11, libm, glibc.

Until next month.

David A. Bandel ( is a Linux/UNIX consultant currently living in the Republic of Panama. He is coauthor of Que Special Edition: Using Caldera OpenLinux.



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 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' 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 didn't look very promising at the outset. I would hope to avoid its pitfalls.)


~ Craig