Optimizing Linux's User Interface
I prefer rxvt to xterm as an X-Windows terminal emulator. Rxvt provides a subset of common xterm features with substantial memory savings. The amounts of physical memory required by xterm and rxvt, as reported by top (a program that displays CPU activity), are 2120KB and 560KB, respectively. Since I commonly run three to four X-Windows terminal sessions simultaneously, I save approximately 6MB of memory by using rxvt. Rxvt does not support Tektronix 4014 emulation or session logging, but this is seldom a concern.
Tcsh has enough features to merit another article, so I will concentrate on just a few aspects with respect to its user interface functions. Most notable is its excellent support of Emacs-style command line editing. Typographical errors are easily corrected by moving the cursor to the error with the arrow keys and using editing commands such as ctrl-D or ctrl-K to make the modification. Previous commands can be edited in the same fashion by first scrolling back through the history list using the up arrow. Filename completion is enabled by putting set filec in .cshrc (the tcsh configuration file located in the user's home directory), which enables the user to type in just a few characters of a long filename and press tab to complete the remainder (assuming those characters are unique). This feature has become so useful and natural to me that I find myself constantly pressing tab in situations which do not support it, such as remote ftp session or when I need to work under MS-DOS. As an example, If I want to view the contents of text file OptimizingLinuxUserInterface, I simply type cat Opttabreturn, and the filename is completed for me—unless there is another file with those first three characters. In that case, I need to supply additional characters.
Tcsh also has advanced ways to set the prompt, which I use to keep track of the present working directory (indentation is important). From my .cshrc:
:set prompt = '\n%B%n@%m%b:%/ %h %# '
gives: root@regal:/home/root 27 #
when working as the user root on the machine regal in the directory /home/root with a current history command number of 27.
I also like the ctrl-alt-Z shortcut tcsh provides to allow me to jump from the shell to a suspended version of Emacs and ctrl-Z to bring me back to the shell. It has eliminated my dependence on Emacs's internal shell, which displays some non-standard behavior regarding key assignments.
Having been accustomed to command.com for many years, my favorite feature of tcsh and other Unix shells are aliases. As have most Linux users, I've aliased extremely common commands such as ls, ls -l, rlogin, and less to l. ll, r, and t (short for type). This is easily done in .cshrc with lines like
alias rlogin 'lr'
Here are a few useful and representative selections from my .cshrc for file viewing, process logging, telnet access, floppy formatting, and remounting the hard drive if it boots read-only (note: the last one comes up all the time frantically in Usenet's comp.os.linux hierarchy).
: alias t 'expand -5 \!* | less' alias pss 'ps -au | grep $user | less' # Syntax: pss <user> alias archie 'telnet archie.internic.net' alias formatfd0 'echo "Using ext2 filesystem." fdformat /dev/fd0H1440; mkfs -t ext2 /dev/fd0H14440' alias remountroot 'set temp = $PWD; cd /; mount -w -n -o remount /; cd $temp'
Excellent shell tools such as tcsh and rxvt are one reason why I consider Linux's interface to be superior to most non-Unix operating systems. DOS, Windows, NT, and even the Mac do not offer this powerful and fast means for program and system interaction.
Fvwm is an excellent choice for a window manager, providing most or all of the functionality of Motif in far less memory (like rxvt compared with xterm). Fvwm was derived from twm code, but designed to use fewer system resources. Informal tests with top show that fvwm uses 700KB of physical memory (RSS) compared to OpenLook's 900KB, twm's 1700KB, and mvwms's (Motif) 1900KB. Not even the author still remembers what fvwm stands for, although I've often heard “feeble virtual window manager”. This is an unfortunate name, since fvwm is far from feeble. [I suggest that this is why the author chooses not to remember what it stands for. —Ed]
Fvwm employs a virtual desktop like olvwm with a maximum size of 32KB pixels squared (I doubt anyone would ever take advantage of such gargantuan proportions), and has a look and feel very similar to Motif. Sticky windows can be assigned which stay on the screen regardless of which virtual desktop is currently being viewed. As with Motif, resizing windows invokes a helpful grid showing the changing dimensions of the window. Shaped windows are supported, but increase memory utilization by 60KB (I don't use these).
Fvwm utilizes “modules”, a concept not shared by other window managers. Modules are separate programs which may be independently developed, yet which are integrated into fvwm. Modules run as separate Linux processes, spawned by fvwm such that a pair of pipes are used to transmit commands back and forth for execution. While this design may be superior for window manager programming, it is particularly important to the average Linux enthusiast because it provides more functionality than most window managers.
Fvwm's man page is very long (36 pages) and complete. More important, the sample configuration file which comes bundled with fvwm is crammed with comments and useful defaults. Fvwm is like other window managers or X-Windows applications in that great control may be exercised over almost every aspect of display. Window color, border size, and window behavior are easily specified in the .fvwmrc or .Xdefaults file. Specific directions for such modifications are available in the default .fvwmrc file. Configuring fvwm should not be difficult.
I find that the most useful desktop interface feature offered by fvwm (and most other window managers) is its root menu. Customization of the root menu provides easy access over almost every aspect of the system. On my Linux workstation, the first five root entries (Apps, Docs, Desktop, Network, and System) are pointers to submenus.
Apps contains all productivity X-Windows applications, like xemacs, xv, etc.
Docs are common ASCII documents which I constantly need to access, such as my to-do list. I also use this submenu to organize the many, many ASCII configuration files used by Linux. Since I have Emacs running at all times, the .fvwmrc statement controlling this entry runs emacsserver:
Exec "To do list" exec emacsclient /home/root/todo &
Emacsserver then loads the running Emacs with my document and switches buffers to display the new document. This method saves memory and minimizes the number of windows on my screen.
Desktop modifies the appearance of the screen and is used to invoke screen savers and change backgrounds. For example, I can call each of the different xlock screen savers in my .fvwmrc with:
Popup "DesktopScreensavers" Exec "Fractal Flame" exec xlock -nolock -nice 0 -mode flame & Exec "Game of life" exec xlock -nolock -nice 0 -mode life & ... EndPopup
I can load and automatically expand any graphic to serve as background wallpaper with:
Exec "Starry skies" xv -root -max -quit /data/wallpaper/VanGogh1.jpg
or create a texture (a small graphic which may be tiled to give an interesting background) with:
Exec "Red brick wall" xv -root -quit /data/wallpaper/redbrick.jpg
Network runs any of the common browsers or utilities, such as FTP, Archie, Gopher, etc. I also use this menu to access the different network daemons currently running.
System lists a wide variety of utilities involved with system administration. For those of you familiar with Windows 3.11, this entry is similar to, but substantially more powerful and customizaable than, the control panel applet. One entry in the submenu runs my perl backup script in a new rxvt window; another opens the excellent keyboard mapping utility xkeycaps:
Exec "Keyboard mapping" exec xkeycaps -keyboard DELL &
Other entries in my root menu start the screen blanker (I have a Nokia monitor which powers down upon receiving a black screen), refresh the window, and exit fvwm.
For an excellent (albeit expensive) reference to extensive root menu customization, see The Shell Hacker's Guide to X and Motif by Alan Southerton.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- New Products
- Linux Systems Administrator
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- Reply to comment | Linux Journal
2 hours 19 min ago
- Reply to comment | Linux Journal
2 hours 35 min ago
- Favorite (and easily brute-forced) pw's
4 hours 26 min ago
- Have you tried Boxen? It's a
10 hours 18 min ago
- seo services in india
14 hours 50 min ago
- For KDE install kio-mtp
14 hours 51 min ago
- Evernote is much more...
16 hours 51 min ago
- Reply to comment | Linux Journal
1 day 1 hour ago
- Dynamic DNS
1 day 2 hours ago
- Reply to comment | Linux Journal
1 day 3 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
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?