Mon, 30 Aug 2004
A few years ago I came into posession of a video entitled "Godzilla vs. Mito Komon". Most people, I suspect, have heard of Godzilla, but not necessarily Mito Komon. Mito Komon was both the title and star of a very long-running Japanese TV show set in 17th century Japan.
The video itself was apparently done by an art student as a project. He wrote the script, directed the film, and acted all of the parts (including Godzilla, Great Majin, and several high-voltage electrical towers). I have been unable to find out who did the fansubbing.
Since I haven't found anyplace else to get it, I've put together a torrent of the video. Behold, Godzilla vs. Mito Komon.
Wed, 25 Aug 2004
This evening, a pickup truck ended up on the Light Rail tracks around Northern Parkway. To say that the MTA didn't handle it well would be an understatement.
I left work at about 5:20 and arrived at the Light Rail stop a little before 5:30. There was already a train there, sitting with its doors open. I asked people what the wait was and was told there was some accident. I waited a while and eventually the driver announced that he would go to the Lutherville stop. No word on what was going on, just, "I'm going to Lutherville." When we got there (two stops down the line), the driver announced that he had to stop until he was told he could go. I considered taking the 8 bus from there, but figured that whatever shuttle system the MTA had set up would still be faster than the 8. Eventually, we got moving again, traveled to the next station, Falls Road, and the driver said we all had to get out. That was the extent of the communication from the driver. He was minimally informative and gave no indication of what the MTA was doing to cope with the situation.
At the Falls Road stop, I looked around for any MTA personnel so I could see what was going on. There were none. I pulled out my system map, figured out what buses I needed to take, and set out. On my way out I passed an MTA supervisor's car driving in, so I went back to see what was up. The woman assured me that there were shuttle buses on the way; she'd left at the same time they had, but she'd taken back roads impassable to buses. I was told that the buses would take us to the North Avenue Light Rail stop, at which point we could board a train and continue south. Replacement Light Rail drivers got out of her car, switched places with the drivers of the trains at the stop, and she and the old drivers drove off.
Roughly fifteen minutes later a bus arrived, disgorged its passengers and then closed its doors. When someone went to ask the driver what was going on, they discovered that the driver had been told to take people from North Avenue to Falls Road, but hadn't been told anything about bringing people back. She called her supervisor (a different person than I had talked with), who also didn't know anything about it, but told her to bring us down to North Avenue. On the way back I talked with the driver a little. She had been given only the roughest of directions on how to get to the Falls Road stop, and those had been given verbally; a passenger had supplied her with the necessary details.
By the time we got to the North Avenue stop, the tracks appeared to have been reopened; the first train to go by was northbound and went north past us. I waited about 15 minutes more before a southbound train arrived.
All told, I got home two hours later than normal. Given the circumstances, I could have understood some delay, but the MTA's mishandling of the situation led to even worse conditions.
A distilled version of this tale will be filed with the MTA as a complaint, not that I expect them to do anything about it.
Wed, 04 Aug 2004
I primarily use Unix-based computers, mostly Linux. On those computers, I live in text mode. This entry is an attempt to document the software I find most useful to my text-mode guerrilla lifestyle. Included are links to the programs I rely on, links to alternative programs, and links to my config files.
screen (.screenrc, .screenrc-mithrandir). Simply indispensable. It slices and dices console sessions. Pretty much everything I do, I do in screen. For extensive details, see my ode to screen.
zsh
(.zshrc,
.zshenv,
.zshprompt).
My shell of choice. Think of all the good features of bash, ksh, and
tcsh rolled together. (Without much of the ickiness, particularly the
csh heritage.) Personally, the killer application of zsh was that
fact that not only did it have context-sensitive completion but
(unlike tcsh) it shipped with hordes of completion definitions right
out of the box. Type 'dpkg -L fo<tab>' and zsh
will autocomplete on the Debian packages currently installed on your
system. With an ssh-agent running, type 'scp
otherhost:fo<tab>' and zsh will ssh to the other system
and autocomplete on the files available on that host.
irssi (config, theme). The best IRC client I've come across, certainly beating out IrcII, BitchX, and even epic. Multiple windows, extensible, tons of plugins available.
bitlbee. This is actually an IRC-to-Instant-Messaging gateway. It allows me to use AIM, Jabber, and the like from within my preferred chat program, irssi.
snownews. curses-based RSS aggregator. I shopped around a bit before finding an aggregator that I liked. snownews does everything I need.
mutt (.muttrc, config directory). Possibly the best mail client around, GUI or not. While pine is okay (and simpler to use), mutt is much more customizable and scales better to large volumes of email.
procmail (.procmailrc). Slices and dices my email. I have procmail rewriting things so they're easier for me to deal with, sorting my list mail into separate mailboxes (automatically; no need to add new lists by hand), and checking (and dealing with) spam. Essential to my email usage.
Emacs (.emacs). My text editor of choice. Feel free to substitute XEmacs or vi (preferably vim) at your own preference. I prefer emacs to vi, though I know a decent amount of vi, as any sysadmin should. I actually like XEmacs a little better than GNU Emacs, but GNU Emacs has better UTF-8 support.
w3m. Web browser. Among other things, w3m does tabbed browsing, though it's not multithreaded, so you can't read one tab while another is loading. It even has image support; run it with a valid $DISPLAY and it'll render images on the page. There are other text-mode browsers, most notably links. I'm not tremendously familiar with links because w3m fills all of my needs. (My original decision between the two came about because w3m had better HTML support, but I don't believe this is any longer the case.) The grandaddy of text-mode browsers is, of course, lynx, but it's lagged far behind w3m and links in support for newer aspects of HTML.
moosic (config). This is a music jukebox. The features that distinguish it from other such programs are twofold. First, it runs as a standalone server; you interact with it via a command line client. (In theory, a curses or GUI client could be written, but to my knowledge none yet has.) Second, it's customizable with regards to how it plays music. It has a config file where you tell it what programs to use to play various music formats (it does come with reasonable defaults). A program with similar design is mpd. mpd does its own music playing, which allows some advantages over moosic, but moosic has much better playlist management.
mplayer (config). Okay, this is kind of a hedge. I do indeed use it purely in text mode on occasion--it has better support for streaming media (usually mp3s) than any of the actual mp3 players I use. mplayer's main advantage is that it will play pretty much any video format I throw at it. (I'm not quite masochistic enough to watch the videos in aalib, though.)
surfraw
(.surfraw.conf).
surfraw is a collection of command-line based jumping-points to
various web-based information, mostly searches. For a quick google
search, I need only go to a command line and type 'sr google
my search terms'. (Debian uses a single program,
'sr', as a wrapper for all of the surfraw "elvi". On
other systems, you would probably just run 'google your
search terms'.)
wget. The swiss-army-knife of grabbing things off the web (and via FTP). I've automated many downloads, some tweaked in interesting ways, with wget.
tdl. Completely command-line todo list manager. Along similar lines is DevTodo; I haven't really played with it because tdl does everything I need. Those two are both command-line based. For more of a todo list editor, you might want to take a look at hnb or woody. (Though, of those two, hnb has better support for todo lists.)
Those are the bigger programs that jump to mind most readily. I use a host of other programs, too. Listed briefly, they are: less (pager), mpg321 (mp3 player), GnuPG (OpenPGP implementation) (options), aumix (volume control), teTeX (TeX implementation), pal (nice colored calendar with a number of features), bc (simple command line calculator), dict (actually a dictionary network protocol but their command-line client is also named 'dict'), mp3gain (normalization of mp3s (ideally should be done non-destructively via ID3v2 but no one supports that)), netcat (connect directly to TCP sockets), BitTornado (bittorrent client; slightly nicer than the standard one), subversion (source revision control; nicer than cvs), abcde (CD ripper) (.abcde.conf), lame (MP3 encoder), nmap (portscanner), hping (packet generator), and tcpdump (packet sniffer).
I do normally run X; it lets me have multiple xterms on the screen at once. For managing those xterms, I run ion (config directory), a tiling window manager.
There are a couple of GUI programs I use regularly. I've already mentioned mplayer; you really need a pixelmapped interface to watch movies. There's also Ethereal, an excellent network sniffer and protocol analyzer (much nicer than plain tcpdump), and GnuCash, one of the best asset management programs I've come across. (But see clacct for straight command line checkbook balancing.) Oh, and Firefox, for those websites that just won't work with w3m.
Just a listing of the many ways that screen is indispensable to my way of using my computer.
The biggest thing is, of course, the fact that screen is detachable. Start screen, start a program, detach screen while in the middle of doing something, log out, login later, reattach, program is just as I left it. This works at a distance, too. I can leave my home and go elsewhere (work, friend's house, etc.) and be able to ssh to my home computer, reattach screen, and pick up exactly where I left off.
Second only to detachability is screen's multiplexing capability. A screen session can contain many different windows, each running a different program. This allows me to have an entire workspace within screen. I can have an editor in one window, working on some source code; a shell in another window, where I might be doing trial runs of the program; a web browser in a third window, which could be looking at some documentation; and so on. My normal screen setup has 15 windows, which I use for various purposes.
I can specify what programs to run from screen's config file. So when I start screen, my default workspace is already seeded with all the programs I use regularly (text editor, IRC client, web browser, mail client, etc.). I use this capability just to start some programs that I never even interact with, for example SETI@Home. Running it within screen ensures that it's running at all times (I always have a screen session running) and only one instance is ever running (I do everything within one screen session).
I can attach to the same session multiple times. So my customary graphical workspace is three xterms, all attached to the same screen session. This gives me more visual real estate, while allowing me to be very flexible. The windows displayed by each of the xterms change depending on what I'm doing at the moment.
Screen understands several different character encodings. I run all of my programs in UTF-8 mode. When I'm attached to my local xterms, screen passes the UTF-8 characters straight through, because the xterms can handle it. On friends' computers, screen translates the UTF-8 into ISO-8859-1, showing all the characters it can and filling in question marks for those it can't. Likewise for my serial terminal, which uses a CP437 charset. (I'll admit that that last took some work on my part.)
I can also input most Unicode characters via screen's digraph support. Press the right escape characters, enter an RFC1345 digraph, and whatever program I'm currently using gets a UTF-8 character. (This also took a little work--I had to patch screen to get digraph support for non-ISO-8859-1 characters.)
Screen keeps a separate scrollback buffer for each window. I have it set to keep a very large number of lines, which has come in useful on several occasions, especially since you can search through the scrollback buffer. ("What was the exact output of that command?" ::search:: "Ah, that was it.")
I've used screen's monitoring capabilities a lot. It can watch a particular window and notify you when there's new activity ("Oh, something happened in that log file.") or when it's been silent for a time ("Oh, that long-running compile is done.")
Screen supports having a caption line across the bottom of the screen. I use it to give me an omnipresent clock, as well as showing me info on the current window. The capability also exists to run arbitrary programs and put their output in the caption. On my laptop, I do this with information on the current state of its battery.
Instances of screen can be password protected, to prevent others from getting at your programs. I find this feature useful when using screen in a semi-public area where I might need to leave the computer for a time.
There are some features that, while not mind-blowing, are just nice to have around. Normally, when the last program in a window exits the window closes. With zombie control, the window remains, and you can restart the program with a single keypress. Very useful for windows dedicated to particular programs.
While I don't use it regularly, screen's multiuser support has been useful on a couple of occasions. When doing some collaborative programming, I created a single, multiuser screen session, and all of us connected to it. It proved very useful for sharing information among the group of people. ("Just go over to window 7, where I'll show you how feature X works...")
There are, of course, plenty of other useful aspects to screen. These are just the ones that I rely on or have found myself relying on. I encourage anyone who uses a command line regularly to give screen a try.
For further information:
- Official GNU screen page.
- Old screen FAQ, not really maintained anymore, but still has some useful information.
- screen-users mailing list, hosted by the FSF's Savannah project.
