Editors Desk

By Steve Litt

• Do we really need GUI on servers and dedicated machines processing transactions, not communicating with humans?
• Does GUI sometimes get in the way?
• Is character I/O as bad as the marketing guys say?

If you find yourself frustrated and longing for a character I/O interface, this issue of Troubleshooting Professional Magazine for you. It discusses some character I/O advantages, and a new menu system that can make character I/O just as user friendly as GUI for everything but layout. So kick back and relax as you read this issue. And remember, if you're a Troubleshooter, this is your magazine. Enjoy!

Steve Litt can be reached at Steve Litt's email address.

Stick Shifts and Command Lines

By Steve Litt

But the South Side Special's best quality was its manual transmission. No rich man's four on the floor -- this was a "three on the tree" -- a column shift so loose clutchless shifting was easy. Once, while eating an ice cream cone, I drove shifting it with my foot (remember, I was 18).

But it wasn't just fun. A manual transmission covers a multitude of sins. When it was running poorly (and that's the norm for a car burning a quart of oil every 50 miles), I could nurse it along by revving high and liberally clutching. And if it wouldn't start, a 6 mph push and a clutch pop were all it needed. And I could improve its horrible gas milage by coasting down hills.

Time passed. The South Side Special blew up, peace signs dissappeared, and manual transmissions became obsolete (except for those wanting to be "sporty"). Modern transmissions last the life of the car, while maintenance-item clutches cost $600 to replace. Automatics are safer for engines -- you can't redline no matter how hard you whomp. And in rush hour traffic drinking a soda (or eating an ice cream cone :-), you're sure glad to have an automatic. Fact is, today there's absolutely no reason to have a stick shift.

Kind of like the command line interface. In its time it allowed the skillful and savvy user to do *anything*, working around limitations and glitches while finding quicker and more innovative ways to work. And if a missed command wiped out the hard disk -- well, a missed shift could blow an engine too. Today's typical computer user has no more use for the command line than he has for a stick shift. The command line is dead.

Or is it? 18 wheeler trucks still have manual transmissions. The driver sacrifices a little "convenience" for the ability to match any load, any traffic, any grade, to his diesel engine. He's a trained professional. He can handle it.

A network server is like an 18 wheeler. It hauls a huge load with a relatively underpowered engine. It certainly doesn't need the further burdon of a GUI. And the driver (scuse me, administrator) needs complete control at all times. He absolutely doesn't want to figure out how to outsmart a "user friendly" system designed to prevent him from putting the machine into certain states.

It's 1:30 AM. The guys with the automatic transmissions and the GUI's are in their third hour of slumber. The radio is playing a truck drivin song, the stars are cold hard points, the air just outside my thin windows is well below freezing, and I'm still cruising.

I could go on all night, but for safety's sake I better pull off and catch some Z's. Tommorrow's another day, and that's a big 10-4 good buddy, over and out.

/sbin/shutdown -h now

Steve Litt can be reached at Steve Litt's email address.

You've Come A Long Way, Baby

By Steve Litt

I didn't have a clue. It had been over a year since I'd touched that code. I'm the kind of developer who wipes his mind clean after completion of a project. My neighbor looked up to me as a role model. Would I let him down?

Getting to a DOS prompt, I took a directory and found a batch file. Viewing it with a type command, I saw it was a compile/run script. Running it produced errors, but nothing that couldn't be fixed editing the batch file and source files to change a few directories.Within 5 minutes it was up and running.

The up and coming developer had a look of worship on his face. "How did you do that? Were you using the command line? Where was your development environment? How did you know what to do? Can you tell me how to do that? How did you change that file? They never taught us any of that in school!"

So here's this guy, only mildly impressed by my Java code, and he goes bonkers over my ability to edit batch files and source code. His CS degree program had taught him that development was drag and drop, with maybe a little hand configuration thrown in.

After he left, I needed to ponder. I took a walk, and the thoughts organized. How nice it was, that a year after touching the program, the same batch file that compiled it served as documentation. That I had control over the directories of the source, and could put ALL the source in a single directory.

I thought back to a very nice Delphi-coded puzzle program, gone forever. All my custom classes had gone in the default directory, somewhere in the Delphi tree (and that directory would have been difficult to change). Those derived classes were wiped out when I re-installed Delphi.

And how about all those Clarion 2.1 programs, lost due to a single byte corruption of a .APP file (of course, I had backups, but it's tough getting knocked back even a day). And the granddaddy of all development environment obfuscations, Microsoft Visual C++, with their bizarre templates replacing the Windows message loop, and their "resource files", and their comments saying "don't edit here". The fact is, much "environment" developed software is uncompilable after a year of inactivity.

My Symptom Description Wizard, developed in obsolete, command-line Sun JDK, will compile forever. My modern, Delphi puzzle program is gone forever.

We've come a long way, baby!

Steve Litt can be reached at Steve Litt's email address.

Apples and Oranges

By Steve Litt

No-brainer, huh? Remember the days before GUI, of trying to remember command syntax? The DOS help program, or Unix man pages? Good riddance to bad rubbish!

GUI interfaces have menu interfaces (or the graphical equivalent of a menu interface) to organize commands and guide the user. Obviously GUI menus are superior to Character I/O's command lines.

Are GUI interfaces more user friendly? Could this be a trick question? Five more seconds (tick, tick, tick).

Yes, GUI interfaces are more user friendly!

BUZZZZ! Sorry, wrong answer!

Menu interfaces are absolutely more user friendly than command line interfaces, but both GUI and Character I/O can be equipped with either a command line or a menu interface. Let's compare GUI and Character I/O environments with the same user interface. Apples with apples. For tasks not involving layout, there's little intrinsic usability distinction between GUI and Character I/O, as long as they both use the same interface.

Customarily, Character I/O environments do not have menus. But not always. As far back as 1984, Epson CPM computers came with rudimentary menu interfaces. All through the 1980's, you could buy several menu interfaces that rode piggyback on the command line. Numerous organizations have created homegrown menu interfaces.

In the April, 1998 Troubleshooting Professional Magazine, I made the following boast: "Don't like Unix commands and shellscripts? Make a menu to run your machine. Heck, if I get 50 people wanting it, I'll make the menu program myself.". I didn't get 50 requests, but since beginning to market Linux servers, I've found the number one objection to be "Linux is too hard to configure and administer.". That objection is obliterated by a good menu system backed by a well-designed menu structure.

So I created the menu program. It's designed to be completely OS independent, although the alpha version runs only on Linux. And better yet, the design of its Menu Definition Files allows the same commands to be run off the same menu structure in environments as diverse as Teletype, Curses, Ansi.sys, Win GUI, X, Java, HTML, and any other environment. Even stand alone programs can access the menu structure.

It has been released as Open Source Software under the GPL. Its web page is in the URLs section at the bottom of this Troubleshooting Professional Magazine issue. If you'd like to be part of this GPL project, known as the Universal Menu System, please email me.

Too bad you didn't win today's big prize, but you can still win the grand prize and stay in the game. Get it wrong and you're history. Here's you question. Is there a speed and reliability penalty associated with a GUI interface on your server?

Hear the clock ticking? No pressure, but your answer to this question can determine whether your IT efforts succeed or fail.
 

Steve Litt can be reached at Steve Litt's email address.

Feeding the Army

By Steve Litt

So who, in their right mind, would send an army of occupation to an area already doing the nation's bidding?

Software vendors. They send an army, 786432 strong (1024x768), to run continuous heavy processes like file, print, web, and email service, as well as file transfer programs. Who feeds the army? Your computer. And if a supply line fails, you get the blue screen of death. Or a hard freeze. Or continuously degrading performance. Basically, a forced reboot, and maybe lost data.

Maybe I'm making too much of feeding this pixel army. After all, even at 16 bit color and 1024x768 resolution, it's only 1.5 Meg -- about one percent of a small server's memory. Trouble is, the real resource drain isn't memory consumption, it's maintenance of those pixels. Pens, canvasses, rectangle invalidations, fonts. And the granddaddy of all troublemakers, the video driver.

There's a reason help desks worldwide include switching to Standard VGA as an early troubleshooting step. Think back to your own experiences -- how often was the video driver or one of its files or DLLs implicated in crashes?

My experience tells me video drivers decrease a session's life span more than daily breakfasts of six eggs washed down with whisky. In desktop productivity usage, rebooting twice a day is not a problem, and is certainly a small price to pay for WYSIWYG page layout. But in a server usage, where sessions must last months and configuration is limited to numbers, names and options, GUI is too high a price to pay.

So by all means, do your word-processing, graphics and web design in a GUI environment. But when it comes to continuously running systems like servers and dedicated processes, feeding the GUI army can lose the war.

Steve Litt can be reached at Steve Litt's email address.

Linux Log: Text Menus Eliminate a Major Objection to Linux

Linux Log is now a regular column in Troubleshooting Professional Magazine, authored by Steve Litt. Each month we'll explore a facet of Linux as it relates to that month's theme.

It had been building up for so long. Long before I became a Linux advocate. Maybe even before the late 1980's, when I got fed up with Microsoft. It started when "user friendliness" became the only thing that mattered.

"User friendly", the alter on which the marketing bigwigs sacrificed performance, reliability, and just plain common sense, while the throngs bowed and chanted "amen". "User friendly", the rational for GUI. For "We do it all for you" development environments in which every code change resembles a trivia game, or maybe construction of a Rube Goldberg machine. The excuse for interfaces that mimic human irrationality, thereby promoting ever stranger errors, rather than trying to raise users to a higher standard. But especially, GUI.

The marketing types knew darn well you don't need GUI to make a computer easier to use for novice and expert alike. At least not for non-layout tasks like server OS's. I knew it too. But being lazy, I delayed a few years...

GUI apologists continually extoll the "usability" of their GUI interface over the Linux command line interface. Cmon guys, let's compare apples with apples. Windows' "usability" comes from their Start Menu, so let's not compare it with Linux in command line mode. Apples to apples -- let's compare Windows to a Linux server running a text mode menu. Linux will win hands down.

Now don't get me wrong. GUI has its place. I wouldn't want to lay out this web page without it. But servers have no layout -- just config options. Servers are administered remotely by clients having GUI, so servers don't need GUI. And servers have enough problems staying up for months at a time, without having to administer a quarter million pixels and a (probably flaky) video driver. There's only one reason to put GUI on a server -- so a certain company in the Pacific Northwest (and I don't mean Boeing) can differentiate their product and take your money.

It was the Linux-bashing that finally made me mad enough to do it.

I wrote the Menu Program. Not just any menu program, but the Universal Menu Program (UMENU for short). Universal because it will run on absolutely any terminal or emulator. It outputs only printable characters and newlines to stdout. No escape sequences, control codes, or graphical drawing. It accepts only letters and punctuation from the keyboard. No alt, ctrl, esc, or function keys.

It's configurable on any Linux/Unix computer, and will soon be Windows compatible also. It's written in ultra-portable Perl, and uses the computer's file system to keep track of menus, commands and hierarchy. No database to maintain. Completely and easily configurable with any text editor. You can make different menu hierarchies for different groups. Of course, you can design new menus -- as many as you want. Who gets what can be controlled by one or two environment vars. UMENU can be started from .bash_profile or any other startup script.

It's non-obtrusive. Using the shipping defaults, it's entirely self-contained in its own directory tree (which can be anywhere in your file system). There's not even an install program. Once you've gunzipped and tar --extracted it, you simply run the program from its program directory. To deinstall it, simply remove its tree, and it will be gone without a trace.

UMENU is absolutely free, licensed via the GNU General Public License (GPL). It's perfectly legal for you to download a copy (http://www.troubleshooters.com/umenu/download/index.htm), and put it on the computers of a few hundred of your best customers. Or on a server with a few hundred users. Or modify it for use in a browser, and put it on the Internet for millions to use. No software metering or software police. No $100,000 fine if you make a mistake or an employee is less than honest. The GPL will basically let you do anything other than making the software or its decendents proprietary.

There are many ways to think of a menu program. To the novice it's a lifesaver. To the expert it's an automated, minimum keystroke cheat sheet. To those in between it saves time with less keystrokes and less instruction reading. To touch typists it's nothing short of greased lightning. To me it's vindication of a long-held grudge.

So I issue you this challenge. Do not use GUI servers. Do not accept weekly crashes, application degradation, poor performance and troubleshooting nightmares on Redmond's menu interface. Get yourself a nice text-mode menu on a Linux or Unix box. Any text-mode menu. It doesn't need to be mine -- after all, I make no money on the Universal Menu System.

And to those of you who want to get involved, I issue another challenge. Join the Universal Menu System Software Project. We need configuration tools and help making the same code base run on Unix, Linux, Dos and Windows. We need menu designers. We need documentors. We need versions for browser, curses and GUI (yes, GUI) interfaces, so that the same menus will work the same way no matter how you view them. Join us! The project website is http://www.troubleshooters.com/umenu/index.htm. The download web page is http://www.troubleshooters.com/umenu/download/index.htm.

Life can be much simpler without GUI. Anger's bad for your health. So if you're angry like I was, do what I did. Don't get mad, get even.

Steve Litt is the originator of the UMENU Software Project. He can be reached at Steve Litt's email address.

Letters to the Editor

All letters become the property of the publisher (Steve Litt), and may be edited for clarity or brevity. We especially welcome additions, clarifications, corrections or flames from vendors whose products have been reviewed in this magazine. We reserve the right to not publish letters we deem in bad taste (bad language, obscenity, hate, lewd, violence, etc.).

Submit letters to the editor to Steve Litt's email address, and be sure the subject reads "Letter to the Editor". We regret that we cannot return your letter, so please make a copy of it for future reference.

How to Submit an Article

All submissions become the property of the publisher (Steve Litt), unless other arrangements are previously made in writing. We do not currently pay for articles. Troubleshooters.Com reserves the right to edit any submission for clarity or brevity. Any published article will include a two sentence description of the author, a hypertext link to his or her email, and a phone number if desired. Upon request, we will include a hypertext link, at the end of the magazine issue, to the author's website, providing that website meets the Troubleshooters.Com criteria for links and that the author's website first links to Troubleshooters.Com.

Submissions should be emailed to Steve Litt's email address, with subject line Article Submission. The first paragraph of your message should read as follows (unless other arrangements are previously made in writing):

I (your name), am submitting this article for possible publication in Troubleshooters.Com. I understand that this submission becomes the property of the publisher, Steve Litt, whether or not it is published, and that Steve Litt reserves the right to edit my submission for clarity or brevity. I certify that I wrote this submission and no part of it is owned by, written by or copyrighted by others.

URLs Mentioned in this Issue

• http://www.troubleshooters.com/umenu: The website for the Universal Menu System Open Source Project
• http://www.troubleshooters.com/umenu/download/index.htm: The download site for the (free, Open Source) Universal Menu System (this version works only on Linux, but upcoming versions will work with Windows and with UNIX).
• http://www.microsoft.com: The guys who make Windows NT, a very nice server OS that would be as good as Linux if it was faster and more reliable.