Focus on Software
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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- SourceClear Open
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Google's SwiftShader Released
- Non-Linux FOSS: Caffeine!
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide