|
|
|
|
|
|
|
|
by David A. Bandel
By the time you read this column, several distributions will be offering the new 2.4.x Linux kernel. Much work has gone into it, and a new facet has been added: a /devfs file system. It will be interesting to see if distribution makers use this particular facet. I've seen more debate on this particular feature than on any other--the camps remain divided.
The arguments don't collide directly. The arguments for devfs run along these lines: the /dev file system is populated with hundreds of entries for all possible devices. The number and type of devices is about to explode with the use of USB and IR. Each entry requires one inode, which results in the use of 4096 bytes of disk space for each entry. Because these are node entries (i.e., device files), that's basically wasted space; the inode contains all required information. The arguments against devfs are primarily implementation-based--this isn't how it should be done, and it's kludgy. This argument could easily be used with many new implementations, which is why some kernel developers oppose its inclusion in the kernel: it needs more time to mature. I won't take sides, but I will tell you I've been using it since before mid-April and it's working the way it should, for me. If necessary, you can still create entries, but they should be created by the modules as they load. I expect many improvements will be made in the months ahead. I think this is an exciting idea even if the implementation needs work.
For those of you who remember a game called Air Traffic Controller or ATC, this game should bring back memories. What I can remember of ATC was that it was not easy to keep all those little planes that came on and off the screen too fast, apart. Well, I still can't. Guess my decision not to become a real air traffic controller was a good one--at least based on this game. It requires libgnomeui, libart_lgpl, libgdk_imlib, libSM, libICE, libgtk, libgdk, libgmodule, libXext, libX11, libgnome, libgnomesupport, libesd, libaudiofile, libm, libdb, libglib, libdl, glibc and libz.
This particular game goes way back. I remember playing this one on a dumb DEC terminal connected to a mainframe somewhere; I just can't remember what it was called. Then came a qbasic clone that used monkeys throwing explosive bananas at each other--same game. Aim your sights on the mountains or valleys where the other cannons are, and try to blow them up before they get you. Between this game and AirTraffic above, I've obviously had too much fun this month (or too much spare time on my hands--not). It requires libgtk, libgdk, libgmodule, libglib, libdl, libXext, libX11, libm, libXpm and glibc.
tt is a time tracker that is very simple to use. In fact, the easiest way to use it is as part of a shell script that turns it on and off. You define the projects you're working on, and tell tt to start timing that project. When you've finished working, tell tt to stop. The data from tt can be exported in several formats into a MySQL database, an ASCII file, etc. While not included, I'm sure a small button with project names could be put on your X desktop. Then you could just click a project on and off as you work on it. It requires Perl 5 and the following Perl modules: POSIX, Time::Local, Sys::Hostname and Fcntl.
Do you have to keep track of employee schedules? Perhaps you have a dozen or so folks working for you who need schedules. phpSched might be able to help you. Once you set it up, employees can even request when they want to be on. You (or whoever controls the schedule) get final say. You can see who's scheduled next week, last week or even last month. Everything is saved in a MySQL database. It requires a web server with PHP and MySQL, and a frames-capable browser.
Perl Mail Client (pmc) is very basic, but gets the job done. It uses the mbox format, which most other mail clients don't seem to want to do. This habit of graphical e-mail clients emptying your mailbox can be annoying if you're temporarily stuck on a non-graphical terminal (and non-graphical clients look ugly in an xterm box on your pretty graphical screen). pmc gets around the problem. It's not elegant, but it is functional. It requires Perl 5 and the following Perl modules: Gtk and Net::SMTP.
For web sites, there are counters and there are counters. I've seen gaudy counters, broken counters, graphics-only counters (usually on Lynx-unfriendly, completely graphical pages) and more. This counter is different. It can be graphical if you want, or text. It's easily changed in a config file. The text is unobtrusive. I put a sample on the home page on my system, and I hardly noticed it. And it works. It does require that the server parse the page, but I'm not convinced that's a particular problem. It requires glibc and a web server that parses HTML.
This address book is not fancy, just a place for names and numbers and some text where you can put an address. It keeps a file in your home directory with the entries, so those of you who don't like SQL databases can use it. The data file is readable by only the application, and no import or export button is available yet. It requires libgtk, libgdk, libgmodule, libglib, libdl, libXext, libX11, libstdc++, libm and glibc.
David A. Bandel (dbandel@pananix.com) is a Linux/UNIX consultant currently living in the Republic of Panama. He is co-author of Que Special Edition: Using Caldera OpenLinux.