Linux Journal Interviews Robert Nation
Larry: Although I've seen your name listed in various pieces of software documentation, I realize that I know few personal details. Would you fill me in on your background?
Robert: I grew up in Ithaca, NY, where my father is a professor at Cornell University. I received my bachelor's and master's degrees in Electrical Engineering from Cornell. Since then I've been worked at Raytheon, in Massachusetts, and Sanders, in southern New Hampshire. I've been living in Merrimack, NH for several years now, with my wife (also from Cornell and upstate NY) and three children—ages 4, 5 and 7.
Larry: What sort of work are you currently pursuing?
Robert: I work for Sanders, a Lockheed-Martin Company. Sanders is a leading supplier of electronic counter-measures equipment for the U.S. military. Sanders also works in communications and battle-field situational awareness areas. I've been working on systems to detect and classify helicopters and tanks at long range from the sounds they make and to identify scuba divers from their echo in a high frequency sonar.
Larry: How did you get involved with programming free software?
Robert: After I started work at Sanders, I realized that Unix workstations were an excellent tool for signal analysis—in field tests, we record data from some prototype radar, sonar or acoustic system, then load the data onto our workstations to figure out the best approach for performing computer-aided detection and classification of the targets.
Around 1990, I saw Linux mentioned on the Net and thought that maybe a low-cost PC could be used for the signal analysis—with the advantage that PC Laptops are cheap. They can also be easily taken on field tests for on-site data analysis to tune systems parameters while we are actually in the process of testing the system. I bought a PC and started learning about Linux to track this trend—and also brush up on my computer and software skills at the same time.
Larry: How did you become motivated to create FVWM, now one of the most widely-used window-managers in the Linux community?
Robert: My original reason for creating FVWM was to help me view spectrograms of recorded data. A spectrogram is a plot that shows time on the horizontal axis, and frequency on the vertical axis. The brightness of each pixel in the plot indicates the amount of power that was received at that frequency and time. I like to complicate matters by using color to indicate the direction of arrival of the data too. Anyway, I started looking at bigger and bigger spectrograms—until they were eventually 2000 pixels by 400 pixels, and I didn't want to loose resolution by squeezing the image onto one screen. TVTWM or VTWM would have been good enough for the job, but I wanted to learn something about X11 programming, so I started ripping apart TWM to create FVWM.
Larry: What do the acronyms FVWM and RXVT stand for?
Robert: FVWM stands for Feeble Virtual Window Manager. The original releases (around version 0.8 or so) had almost no user selectable features, so it really was feeble. I think the only thing that you could change was the color of the window borders.
RXVT is Rob's version of XVT. I believe XVT stands for X Virtual Terminal.
Larry: How do you think FVWM compares with TWM as far as size, speed, and memory?
Robert: Although a few early versions of FVWM were smaller (less memory usage) than TWM, I'm sure that this is no longer the case. Also, people tend to use FVWM modules, which consume even more memory.
TWM was not too much of a memory pig in the end—except that it initialized a table of possible mouse-button and shift/alt combinations that was fairly large. That table was used to store binds of menus to mouse buttons. I believe that TWM even initialized the table, so it really had to be allocated and then largely swapped out. After I discovered that problem, FVWM didn't have much advantage over TWM.
As far a speed is concerned, TWM uses less decorations, so it is somewhat faster. This doesn't seem to make much difference with todays fast displays, though.
Larry: What do you think of the newer FVWM variants which have been proliferating recently?
Robert: I use FVWM-95 now. I think that the task-bar is a good feature, and motif appearance/compatibility is a bit outdated in this new Microsoft era. I haven't spent a lot of time looking at Afterstep or the other variants of FVWM, but I did notice an increasing trend to use shaped color pixmaps for a lot of gadgets, and these really slow down the X terminal that I use at work.
Larry: What were the progenitors of RXVT, and what compelled you to began developing it?
Robert: RXVT is based on XVT, which is still available on the net. XVT worked fine, but was a little slow at updating the screen. I poked around for a while, mostly to learn more X11 stuff. I also added the option for in-line graphics, which I thought would be really useful for scientific plotting—you could issue a plot command, see the results and have the plot scroll away like any other text. Although I've used that feature quite a bit, it didn't turn out to be as useful as I had hoped. I do occasionally use Xgraph to look at a bunch of scatter plots and end up with a million plots all over the screen. The graphics capability in RXVT does eliminate that problem.
Larry: Browsing through a book of Linux manual pages, I saw your name in the credits of the top program. What was your involvement?
Robert: There was a version of top that directly read kernel structures to get the process information, but it needed to be recompiled every time the kernel changed and had to be updated frequently. There was also a brand new version of the /proc-based ps program. All I did was combine the two, taking a lot of the display software from the old version of top, and the process information software from ps, to make the /proc-based version of top that you see now. It took about two evenings, and other people have maintained it since I first distributed it.
Larry: Have you worked on any other Linux software other than the programs mentioned above?
Robert: Nothing that I have distributed. A few months ago I tinkered with a small graphics server, similar to mgr, but with the ability to update windows other than the top-most window and to update several windows at once—not just the active window. I got the windowing system and text windows working in monochrome, but never finished the rest of the graphics capability.
Larry: Do you have plans to finish the graphics server?
Robert: Probably not, since I just bought a new home computer with a whopping 16MB of memory, and X runs very nicely on that equipment. It was an interesting learning experience, though. The software needed to figure out where windows overlap and update them correctly and efficiently is not trivial.
Larry: What were your first experiences with and impressions of Linux?
Robert: I started using Linux in about 1990. I think it was version 0.9 or so. I was very impressed—I installed an SLS distribution which I downloaded to the Sun computers at work and installed from floppy. As I recalled, it worked perfectly. I still use that same installation at home, upgraded piecemeal to the latest kernel, compilers and libraries. Throughout all those years, I only remember one kernel that had significant problems and had very few problems installing packages.
We've just started using Linux at work now. There is a significant issue in system maintenance—since the Suns come with complete but rare updates, and Linux comes with continuous, piecemeal updates, we don't know if its cheaper to pay the extra money for Sun hardware and save the cost in system administration, or just buy PCs and take the system administration risk. We're using it experimentally now and will be taking a prototype submarine communications system out to sea next year, using a Linux laptop as a console for a rack of VME equipment.
Larry: Why was Linux chosen for this communications system?
Robert: We're using Linux to run the graphical displays (X11). Sanders has been using X11 and Sun workstations for displays for a long time now, so we have a significant knowledge and experience base. Our choices for the submarine system were:
Connect a CRT monitor directly to the Real-time system—this is acceptable, but its hard to get bulky CRTs into a submarine—they have to load through a 30 inch diameter torpedo loading hatch, which is about 2 stories high.
Use a separate Sun workstation—same problem
Use a Sun laptop—very expensive and a little slow.
Use Windows—we have very little programming experience.
Use Linux—we made this choice because of low cost, good level of in-house programming experience and software source code that is generally compatible with Sun software.
Larry: Any thoughts about Linux or other subjects you'd like to add?
Robert: I don't know how much more you could ask for in Linux—the developers have done a fantastic job of getting this operating system together. I'm glad to see that some software vendors are supporting matlab versions of their software now, but I wish there was more available. I wonder if there is a market for someone to license limited rights to software like Word or PowerPoint, and then port, sell and support it for Linux.
I would like to know if anyone is working on a next-generation user interface. I suppose that this could be voice activated, or more interesting, some kind of 3-D, maybe virtual reality thing. I keep thinking of the brief excerpt from Jurassic Park where they showed an interesting 3-D file manager and wondering if there are any ideas there.
Larry: Thanks for your time.
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!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Rogue Wave Software's Zend Server
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