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.
|Speed Up Your Web Site with Varnish||Jun 19, 2013|
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
- Speed Up Your Web Site with Varnish
- Containers—Not Virtual Machines—Are the Future Cloud
- Linux Systems Administrator
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Non-Linux FOSS: libnotify, OS X Style
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- RSS Feeds
- Reply to comment | Linux Journal
1 hour 42 min ago
- Reply to comment | Linux Journal
5 hours 42 min ago
- Yeah, user namespaces are
6 hours 58 min ago
- Cari Uang
10 hours 29 min ago
- user namespaces
13 hours 23 min ago
13 hours 49 min ago
- One advantage with VMs
16 hours 17 min ago
- about info
16 hours 50 min ago
16 hours 51 min ago
16 hours 52 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?