Gratuitous Window Dressing, Part 1
Linux gives you the power to define how you work. It gives you choices.
When you work with that other OS day in and day out, choice isn't really something you need to worry about. There is one way to do things, and that is pretty much that. Linux, in an effort to be helpful, complicates the matter. Choice? What am I supposed to do with that? Well, for one thing, by defining how you work and the environment you work in, you may find that you work better--after all, the machine is supposed to mold to your needs and not the other way around. At least that's what we were originally led to believe.
The whole desktop experience stems from our old friend XFree86, the free X Windows System. When you start your GNOME or KDE session, you are starting far more than X-Windows. In fact, most people running Linux have never seen their system running only X-Windows since we usually work with window managers. Window managers define how your session looks to you, how windows are positioned, what kind of decorations are involved, backgrounds, titlebars, themes and more. The window manager you use depends on a couple of different things. If you use something like gdm (the GNOME display manager) or kdm (KDE display manager) to log in, you have the option of choosing the desktop environment you want to use. If you are like me, you enjoy typing something like this to start your X-Windows session.
startx -- -bpp 16
With this, the window manager I use is defined in my $HOME/.xinitrc file. There is a system-wide version of that file as well (should you not have one in your home directory), and you can usually find it in the /etc/X11/xinit directory. It is actually called system.xinitrc but needs to be called .xinitrc in order to be read in your home directory. For the examples we are going to explore, I want you to work with as basic a file as is possible, so we are going to start from scratch. What I want to do is show you how to manipulate your X-Windows environment at a pretty low level. Ready?
Okay, who wants to see what their X Window System looks like, er, um, well, naked? Then try this little experiment with me. Using your favorite editor, whether it be nano, pico, vi or Emacs (I will use vi), edit your ".xinitrc" file. Wait. I should probably warn you that depending on your Linux distribution, you might have a ".Xclients" file instead (we'll talk about that later). The system I am using to write this article is running Red Hat 6.2 and things work just fine whether I use .xinitrc or .Xclients. Personally, I always use the .xinitrc file for my mucking about.
Quick caution note. Do an ls -al .xinitrc in your home directory. If you find a .xinitrc file there, rename it to something like .xinitrc.bak for this experiment. If you find a .Xclients file, do the same (well, rename it to .Xclients.bak, not .xinitrc.bak -- but you know that). That way we can always get it back later. In fact, you are probably going to want to after I show you this. Here's my file; create something that looks the same.
If you don't have rxvt (a terminal emulator program) on your system, then use xterm instead. Before we go any further down this road, we are going to use the free command and make some notes about memory usage. You might want to print this out because I am going to take away your desktop for a few minutes, whether it be GNOME, KDE or twm (tw what?). Close all your applications, log out of your desktop and return to console mode. If your desktop starts automatically at boot time, there are a couple of ways to close it. If you are running something like Debian or Storm, you can, after you have closed all your other X-Windows applications (not counting your xterm window), run this command:
By the way, kdm could just as easily been gdm or even xdm, depending on what login display manager you are using. In a Red Hat system, where the display manager is controlled from the /etc/inittab file, you should edit the file and comment out the following line (by putting a # symbol in front of the line):
Now, type init q (careful not to type a number instead of that "q") and close your desktop. From the login display manager, you may have to Ctrl-Alt-Backspace to finish the whole thing. Another way is to do a "ps" and kill the login display manager process. Of course, you could just reboot instead, but we don't reboot here unless we have to...and even then.... When it comes time to put things back to normal, remember to uncomment that line.
Whew! So many different ways to do the same thing. Anyhow, when you are back in console mode (I hear some smart guy in the back commenting that they always were in console mode), type the free command and look at the output. The following is from my own system.
total used free shared buffers cached Mem: 127784 78540 49244 14212 16380 38560 -/+ buffers/cache: 23600 104184 Swap: 122936 70780 52156
Notice in particular the second row, under the "used" heading. Not counting memory allocated to buffers and cache, I am using 23600 kilobytes of memory (lots of servers running, mail, httpd, postgresql, fonttastic, etc.). I did the same on a Storm Linux system I've been playing with (without quite so many services running) and the numbers were barely 7.5 meg. Now, let's try our naked X Window System, shall we? From the command prompt, type startx.
You'll notice a completely unadorned rxvt terminal session sitting on a featureless background. The first thing I want you to do is run the free command, and take note of the change in memory utilization now that this plain and boring X-Windows session is running. Now move your mouse pointer. Did you try to grab the terminal window in order to move it? Doesn't work, does it? All right, let's type a command in that terminal window, something like xcalc. What happens?
The calculator comes up but starts in the same position as the X-Windows terminal which doesn't make for a particularly useful working environment. It's enough to make you think that your regular desktop environment is more than just GWD. Use control-C to interrupt the xcalc and type exit at the command prompt. The system will return you to the console.
All right, let's try one other thing before we return to the regular desktop. In your micro .xinitrc file, change the line that says "rxvt" (or "xterm") to this instead:
Once that is done, start X-Windows again. Once again, you have a pretty boring X-Windows display, but if you left-click with your mouse, it brings up a menu. This is the face of the Tab Window Manager (which is what twm stands for). You can move windows around, resize them, iconize but not much else. You can modify that menu, by the way. In fact, depending on your version of Linux, you might find that there isn't so much as an xterm available in that menu. Your best bet is to just log off (yes, that is on the menu although you can always use the X-Windows emergency exit, Ctrl-Alt-Backspace). To add something to that menu, copy the system twmrc file from its location in the /etc/X11/twm directory into your home directory. The system file is called system.twmrc and you want the one in your home directory to be called .twmrc. Using your favorite editor, go down near the bottom of the file. The menu section starts with the words "menu defops". After one of the "" f.nop lines, add the commands you would like to see on your menu. I decided to keep it simple.
"" f.nop "Rxvt" !"/usr/bin/rxvt &" "Xcalc" !"/usr/x11R6/bin/xcalc &"
Now, startx again and left-click on the boring X-Windows screen. See your new commands in the menu? Start an X-Windows terminal. Cool, eh? Maybe not? So, why on earth would you want to do something like this? Type that free command again. Look at the memory usage. Now, get out of X-Windows, get rid of your all too basic .xinitrc file and restart using your own regular window manager, whether it be GNOME or KDE. Open an xterm window and type free again.
On that note, I leave you until next time. Take care everyone, and remember that a little gratuitous window dressing never hurt anyone. X-Windows needs no warning labels.
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
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- 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