Learning from the dot-configs

I learn a lot from other people’s configuration files. They’re not always out in the open, so it’s always fun to find one or two, and see how other people do things.

Some people are kind enough to simply post their files online, sort like like this .bashrc offered by Jared. I actually learned a new option for shopt there, and the list of aliases is interesting too.

(Of course, the real value in Jared’s site is the massive, planet-crushing list of console applications collected over time. Learning a new option or variable or alias from a bashrc is pretty cool, but that list overshadows everything else.)

Now the grandaddy repository of configuration files is still probably dotfiles.org. Anything you could possibly want is in there, and it’s arranged in such a way that post your own too. The key to using that site is not to say, “I want a sample conf file for mplayer,” but rather to peruse the files that people offer, and see if there’s something that appeals to you.

And if you’re using elinks, don’t bother trying to preview the configuration files since they tend to get smushed around and are hard to read. (Other browsers seem to show them OK.) Everything is accessible through wget or curl though, so it may be easier to just download them and skim through them at your leisure. Add the parts you like to your own configuration files, and see how the world spins up as a result.

fbterm, meet Wikipedia’s POTD

It’s sad to say this, but I’ve already begun to run out of viable wallpaper now that I can use fbterm to paint a background for my terminal systems. It’s sad only because over the years I’ve really only collected about eight or 10 that I consider worth keeping, and the rest have all gone the way of the delete key.

And using fbterm on the Celeron has added a curve ball to the way I usually do business around here. Not only is there quite a bit more screen space, and not only is that screen considerably larger than any other one in the house, but it’s a good display, clean and clear, and being able to use wallpaper on it means I like to tinker with a lot of different images. And those eight I saved are pretty much already boring.

What would be nice is to be able to yank an artistic or interesting image at random from somewhere on the web, crank down on the brightness so it’s suitable as a background to fbterm, and run through the entire business without having to repeat that over and over again, every time I turn on the machine.

Oh, but I never offer a problem without a solution. …

A couple of years ago I managed to hot-wire the Wikipedia Picture of the Day as a pipe menu for Openbox, using feh in its most popular function, background painter. And since the kind soul who creates the presized images of the POTD is still doing it, it’s just a short hop to automation.

There are lots of ways to do this; I’ll stick with wget and imagemagick; if you know of a lighter but as-versatile console image management tool, please speak up. First step is to grab that image off the web; this is the easy part.

wget -q http://toolserver.org/~daniel/potd/potd.php/commons/1024x768 -O $HOME/.potd.jpg

I want it in the same place every time, with a predictable and understandable name. The q flag tells wget to be quiet, while the -O lets me output to a different file name — this time, a dotted file name. I could just leave the file name as “1024×768″ but I have a tendency to go on wild deleting rampages, and calling it “.potd.jpg” keeps me from purging it out. Note that there are lots of different sizes to choose, including some common screen dimensions.

That was the easy part; this is the hard part: toning down the image so that it doesn’t render the text invisible.

convert -modulate 20,100,100 $HOME/.potd.jpg $HOME/.potd.jpg

Of course, every picture is going to be different. I picked 20 percent brightness because I figured too dark is better than too light. Feel free to adjust those numbers, if you dare.

After that, starting fbterm is really just a matter of jumping from one script to the next. There’s one small catch though: The script that appears in the man pages for fbterm suggests feeding the k option to stretch the image to fit the screen, regardless of its dimensions.

But the POTD hosting site precrops the image to 1024 pixels across, and lets the depth fall free. That means a vertical image is going to be short and fat, rather than of natural dimensions.

The easiest way to solve that problem is to pull the k flag out of the fbterm-bi script, since the image we pull is already the right dimension.

If you think that too simple, or if you have a screen with unusual dimensions, you’ll want to download the full image rather than the presized one, then ask imagemagick to crop it down to size.

convert -crop 1024x768 $HOME/.potd.jpg $HOME/.potd.jpg

This will scale it to the dimensions of a screen, starting at the upper left corner and catching only the available dimensions. Beyond that there’s not much I can suggest; you’ll have to get your hands dirty. Your screen of a different shape than mine (probably) and each picture that comes off the site is going to be of another shape.

And since the point here was to automate this as much as possible, I probably won’t worry if a picture is slightly stretched or off-cropped. Such is life. Tomorrow is a new day, and brings a new picture of the day.

In any case, the last line of your POTD script should feed the fbterm-bi script with the name of the image. And since the name and location are predictable …

$HOME/.scripts/fbterm-bi.sh $HOME/.potd.jpg

And that should be the end. Collate, save and make executable with chmod +x .scripts/fbterm-potd.sh. Copy-and-pasters, here’s the entire business in one small patch.

wget -q http://toolserver.org/~daniel/potd/potd.php/commons/1024x768 -O $HOME/.potd.jpg
convert -modulate 20,100,100 $HOME/.potd.jpg $HOME/.potd.jpg
$HOME/.scripts/fbterm-bi.sh $HOME/.potd.jpg

Don’t forget to trim the fbterm-bi script of that one character, and to make sure all these scripts are in the right place, or things won’t work quite right. Of course, you never get any guarantees from me anyway. …

iotop for better disk monitoring

A learned a long time ago about the vmstat 1 command, which will allow you to watch some of the action that’s happening in your system. It’s a useful command, and I find myself relying on it most often when I want to get an idea of drive input and output.

But for an application that is dedicated to watching drive throughput as it occurs, by process, iotop is a better solution.

In the vein of iftop, htop and perhaps even iptraf, iotop looks a lot like the age-old top, and behaves similarly too. Process by process, you get a full list of everything running and what it requires in disk access. Aside from that there are some filters available, a batch mode that will run uninterrupted, sorting options and so forth, as you might expect.

It’s a python program, and as mentioned in the past, programs that run through python or other interpreters can be more taxing on underdog hardware. I get the feeling this one is fairly lightweight though, and considering it might help you pinpoint that annoying drive hog somewhere, it’s probably worth the resources it requires.

P.S.: fbterm in the background once more. Suddenly I have a use for all my old wallpaper again. …

fbterm: Birth of the cool for the console

It’s time to put another console myth to rest — that consoles are boring to look at. Just to emphasize, this is not Xorg:

That is screen with the vertical split patch running in fbterm, which can display wallpaper borrowed from a framebuffer image viewer. No X, no tiling window managers, no fancy kernel recompilation. All that in a measly 27Mb or less, puttering along at 300Mhz and 1024×768.

I’ve mentioned fbterm in the past, as a way to add a few other oddball features to your text-only experience — like turning the entire display on its side. As I understand it, it’s really just a terminal emulator that pushes itself up against the framebuffer, in the same way xterm or urxvt or any of emulator of your choice pushes itself up against the X server display. It just doesn’t have any window borders.

But that does mean you’ll want to get the best possible screen dimensions you can, and that could require you to make sure the proper dimensions are set when you boot the machine. For a refresher on that, take a look at this chart, or better yet, look over Ali Gunduz’s short tutorial on finding unusual framebuffer codes. And remember to pick the highest color depth your system can do, or your wallpaper will appear psychedelic. If it isn’t already.

After that, the fbterm man pages show a simple script that pipes a image through fbv, which fbterm snaps and then uses as an underlay (is that a word?) for its terminal session. Sort of the same way aterm or other terminal emulators allow you to apply a particular backdrop to their work areas. I suppose if you wanted you could use fim or fbi or any other framebuffer viewer, but I haven’t tried it.

Here’s the script, in case you just want to cut-and-paste.

#!/bin/bash

# fbterm-bi: a wrapper script to enable background image with fbterm
# usage: fbterm-bi /path/to/image fbterm-options

echo -ne "\e[?25l" # hide cursor

fbv -ciuker "$1" << EOF
q
EOF

shift
export FBTERM_BACKGROUND_IMAGE=1
exec fbterm "$@"

(Double-check that against man fbterm, because WordPress.com enjoys eating code, even if it’s nested in sourcecode tags. )

fbterm will need fontconfig, libjpeg, libungif, libtiff and a few other packages that you probably don’t usually have installed on a console-only system, but the results are worth it. You can feed it almost any font you like in any size you like, which means you now have the luxury of moving away from the traditional console fonts and picking up more exotic ones.

You can set the foreground and background colors either in the script or as fbterm is running, to make text easier to read against your image. What you see in the screenshot above was actually converted to grayscale in Gimp then shaded considerably, so the text colors would be more visible. What you do with your wallpaper is your business though.

A couple of downsides — I’ve noticed that font displays between standard framebuffer-based consoles and fbterm’s emulation seem a little skewed; for an example, there ought to be grids and borders drawn in a lot of the applications you see above. Not that it’s a huge deal, and I probably can fix that with a little tinkering, but I should mention it.

I should also mention that in Arch, fbterm commandeers the entire framebuffer and holds it hostage until the session is complete. Pressing CTRL+ALT+F2 and so forth don’t have much effect so long as fbterm has your attention. The upside of that is fbterm’s ability to run multiple window instances, so what you lose in a couple of extra tty’s you gain back in an equal (if not greater) number of simultaneous emulator sessions. Edit: This is not true; actually, it seems I have four or five busted F-keys.

Additionally, you might get weird behavior from things like mplayer, which are used to painting over the framebuffer too, and the two things might have a little argument if you run them at the same time. Or they might play well together. It depends.

Personally I plan on using this a lot more, just because it makes the screen a lot more attractive and because I like the idea of flaunting this for the GUI junkies and Xorg-addicts. At 300Mhz with less than 30Mb in use, I get the same degree of function as a computer 10 times as fast and 30 times as much memory. And now I can get the same degree of pretty, too.

Quicker framebuffer scrolling

Somehow I wandered onto this page the other day, and found a rather nifty framebuffer speedup tip. Adding this to your kernel boot line should give you quicker redraws when text is scrolling.

video=vesafb:ywrap,mtrr:3

That works for me in both Crux and Arch, and I imagine any recent kernel should be able to work with it. For my extremely-slow-on-the-redraw Pentium, there wasn’t much of a difference to see. And in the case of a full-screen redraw of an application — in other words, not scrolling text — there isn’t any visible difference at all. So for example, resizing mc on the Pentium wasn’t any cleaner.

But I could see a small bump on a slightly faster machine using the framebuffer, and in the case of the X60s, it was much quicker. Too bad that’s not the one that really needs improvement. …

Words to live by

I only have a few minutes this evening, so rather than share something of my own creation, I shall borrow the words of BoneKracker, who had this to say when discussing a preference for the command line over a file manager.

(File managers) just get in the way and slow you down. It’s like having somebody holding a map in front of your face when you’re trying to drive.

Oh, how I wish I had written that.

You no longer have my support

A long time ago, I used to be a software pirate. It’s no secret; my hands were dirty from as far back as the 8-bit computer generation, from trading illegally copied software in stacks of 5 1/4-inch floppy disks. Sometimes by the boxload.

And even as recently as a couple of years ago, I made a case for “piracy” because the restrictions built into DVD region settings were an enormous hassle, and were preventing legitimate owners from using a product they had paid for, with real money. That still grates me, too.

But now, I completely withdraw my support for any kind of software or movie or music piracy, regardless of the grounds or the situation. You no longer have my sympathy whatsoever, period.

I hear people jabber a lot about fighting a backhanded war, a sort of battle of obstruction by pirating software, as if their efforts made it somehow more difficult for the software and entertainment industries to protect their products. I’ve heard people say they pirated music or movies as some sort of revenge effort, against an industry that continues to release shoddier and shoddier stuff.

And sometimes I might have even agreed. But not any more. Any legitimacy or rationalization or sense of nobility you might claim by illegally downloading software or movies or music completely evaporated with the Humble Indie Bundle.

Because in spite of the price, which was conceivably as low as one U.S. cent, and in spite of the option to donate all of that one cent to charity and leave the developers with nothing, some people still stole it.

Where is your nobility now? Where is your sense of revolution and damn-The-Man, when you subvert a product available for less money than is probably under the cushions in your sofa?

You’re not Robin Hood, you’re not a closet-dwelling anarchist or a technophiliac revolutionary any more. You’re a thief.

You can give me any sob story you like: I have five kids to feed. I am homeless and vagrant. I am saving my money for college. I’m saving the developer’s bandwidth by using an illegitimate torrent. The sun was in my eyes.

Nonsense. All you’ve done is prove that your motive isn’t revolutionary, that you aren’t a technophiliac anarchist, and there’s no nobility or sense of insurgency involved in your pirating. And if you would stoop to steal a penny from a charity, then your motives in every other case are equally clear.

You’re just a thief.

The 1.2Kb python browser script

It’s time for another round of name-that-browser.

You can comfortably ignore the blue box in the upper left hand corner. This was meant to be a dual-purpose screenshot, showing the mystery browser on the right, along with mplayer playing a conventional DVD rip in Musca on a 300Mhz Celeron. Unfortunately, for reasons unbeknownst to mortal man, I got a blue box there rather than an action shot from the movie, which defeated half the purpose.

But there are no tricks or gimmicks at work here, except to say that the browser is all of about 1.5Kb on disk, written in python and has webkit as its core. No toolbars, controls, address bar or menus, save the right-click menu that appears with some very primitive options in it.

And the answer is … I don’t know.

juancarlospaco posted it in reply to a question about lightweight browsers, and considering it’s just a 42-line python script, it’s probably a contender for lightweight champion, graphical division.

The name, however, remains a mystery to me. Perhaps it’s a well-known python exercise, or just a sample code snippet. In any case, you’re looking at it in Arch, with nothing more than gtk2 and the pywebkitgtk package from community installed. It’ll get 100/100 on the Acid3 test, renders images and fonts precisely and beautifully, and as you can see in that picture, can run at 300Mhz alongside Xorg, mplayer, alsaequal, alsamixer and Musca … and everything is hovering around 64Mb of memory total. Impressive.

But what’s the use in that? What good is a control-less browser window that needs to be fed a URL from the command line, a la python browser.py http://kmandla.wordress.com ?

Well, if you’re one of those half-and-half tiling desktop users who prefers a console-only arrangement against X (like Awesome or xmonad or dwm) it should be fairly obvious. Here’s a worthy replacement for heavyweight graphical browsers that won’t encumber a running system and still give you a graphical page display.

So if you’re torn between elinks and Firefox, this might serve as a decent middle-ground. It’s guiltless: None of the lard that comes with Firefox, and yet you still get accurate and faithful page displays.

I could also see where this might be useful for page designers or web coders, who need something that can jack up a page quickly, then drop out of sight. Instant page view, so to speak. I’m sure there are other possibilities here that I haven’t thought of, that you could offer.

Now if only I knew the name. …

P.S.: Just for the record, because I have a feeling I’m going to be looking for the code in the future. …

#!/usr/bin/env python
import sys
import gtk
import webkit
DEFAULT_URL = 'http://www.google.com' # Change this as you Wish
class SimpleBrowser: # needs GTK, Python, Webkit-GTK
    def __init__(self):
        self.window = gtk.Window(gtk.WINDOW_TOPLEVEL)
        self.window.set_position(gtk.WIN_POS_CENTER_ALWAYS)
        self.window.connect('delete_event', self.close_application)
        self.window.set_default_size(350, 20)
        vbox = gtk.VBox(spacing=5)
        vbox.set_border_width(5)
        self.txt_url = gtk.Entry()
        self.txt_url.connect('activate', self._txt_url_activate)
        self.scrolled_window = gtk.ScrolledWindow()
        self.webview = webkit.WebView()
        self.scrolled_window.add(self.webview)
        vbox.pack_start(self.scrolled_window, fill=True, expand=True)
        self.window.add(vbox)
    def _txt_url_activate(self, entry):
        self._load(entry.get_text())
    def _load(self, url):
        self.webview.open(url)
    def open(self, url):
        self.txt_url.set_text(url)
        self.window.set_title('%s' % url)
        self._load(url)
    def show(self):
        self.window.show_all()
    def close_application(self, widget, event, data=None):
        gtk.main_quit()
if __name__ == '__main__':
    if len(sys.argv) > 1:
        url = sys.argv[1]
    else:
        url = DEFAULT_URL
    gtk.gdk.threads_init()
    browser = SimpleBrowser()
    browser.open(url)
    browser.show()
    gtk.main()

P.P.S.: The title of this post has a typo in it; that should say 1.5Kb, like it does everywhere else.

ROX-desktop and some very loud wallpaper

I’ve seen a few screenshots of ROX-desktop around the Internet, and for fun I decided to put it together myself. This time I tried to cover up my amateur efforts by picking some rather loud wallpaper, as you can see.

 

This was done in Arch by building the zeroinstall-injector from AUR, and using the ROX-all package that’s available from the ROX web site. This was a plain-Jane installation from the command line, with only the xorg group and gtk2 to hold everything up.

It has a look of its own, which I mean as a compliment. Many of the basic functions of a “desktop” are handled quite fluidly with ROX, and not just file management. Everything from mounting drives to creating desktop icons to arranging custom panels are all looped through ROX-filer, which means generally speaking there’s only one place you have to go to control the environment. The window manager is OroboROX in the photos, although you have the option to use others if you like.

ROX-session will even hotwire your startup files to jump straight to ROX-desktop. And there are definitely enough little doo-dads and whirligigs here to keep you entertained while you learn the ropes. Desktop clocks, weather applets, network monitors, wallpaper switchers and so forth, all aimed at ROX-and-company but probably exportable to other desktops.

This is usually the part where I say something a teeny bit negative, in order to keep the presentation balanced and encourage you to try it for yourself. But to be honest, just about everything I tried with ROX-desktop was snappy and quick, light and comfortable, clear and understandable. And since 99 percent of the setup is handled through some sort of GUI interface, fans of the rodent will dig it.

I do have some advice, if you decide to try it for yourself: See if Debian is any easier to use, as opposed to Arch. There are precompiled packages available on a separate Debian repository, and to be honest, most of what I tried to use in Arch didn’t work, or spewed error messages or needed a distinct and unavailable support. I guess that’s because I started it up without a lot of common underpinnings. You might even want to install it over Gnome, and see if it’s easier that way.

But I liked it. It has its own way of doing things and you can adjust that within comfortable boundaries, if you must. It’s straightforward, quick, light, customizable, intuitive and full-featured. And if you don’t rely on loud wallpaper, it might even appeal to a few other people.

Three things Phoronix couldn’t measure

I expected more drama when Phoronix did the smart thing, and finally put numbers to the Arch-over-Ubuntu rumor, and branded it as a myth. But for what I’ve seen, users on both sides seem to nod and accept the results, without too much scuffling.

For me, it was good to see that (with very few exceptions) performance in Ubuntu and performance in Arch are pretty much identical, and rely more on hardware than the actual software that runs it. On the other hand though, there are some differences between Arch and Ubuntu that Phoronix didn’t (and can’t really, so it’s not their fault) test, and I guess most Arch users would cite these as big reasons for using it.

1. AUR. Until you’ve used it, it’s hard to appreciate the simplicity and beauty of a community-maintained repository of installation scripts. Ubuntu, with its Debian roots, inherits a huge list of software and that’s a good thing. But for example if you want to install an esoteric addon to xmms, you’ll have to go it alone — even more so because Ubuntu hasn’t offered xmms for years now. Having a script-based system that allows you to confidently build software — and customize it before you do — is a huge bonus for me.
2. pacman. In terms of number crunching, the two operating systems run hand-in-hand, but putting aptitude next to pacman is a completely different race. For all its virtues, history and accomplishments, aptitude is just nowhere near as fierce an animal as pacman. The time it takes to refresh, download and install new software in Ubuntu is ridiculous when it’s compared with Arch, and that’s not because Ubuntu relies on a GUI — it takes a long time to do those things at Ubuntu’s command line. pacman simply runs circles around aptitude, and there’s no polite way to say that.
3. Svelte. Svelte isn’t an application, it’s a philosophy. Ubuntu is a top-down system, giving you everything at once and then sitting back to watch the look on your face. Arch is a bottom-up system, where you’re given the tools to assemble a system, and the opportunity to let your imagination run wild. Arch’s reputation for speed might not rely on performance at the hardware level, but simply in the fact that you don’t get any bloat, unless you install it. Those ringing praises for Arch’s speed aren’t because it moves faster at the core levels, but because the systems you build yourself are innately faster than the ones Ubuntu releases. Look around this site for a few illustrations of that. (And yes, you can do similar things with Ubuntu.)

This isn’t an Ubuntu-Arch flame war, and I am not necessarily a proponent of one or the other. I use whatever suits my fancy on any particular day of the week, and if you want to know the truth, the longest-running, most stable systems I have don’t run either Arch or Ubuntu.

I am happy to know that at their most fundamental levels performance is roughly equal, but the reason I use one over the other has more to do with the way they are managed, and the tools they offer. And if most Ubuntu users and most Arch users thought about it the same way, then maybe that’s why there wasn’t any drama.