Mission Control

June 10th, 2009

In case you haven’t noticed, there is a pretty common theme among geeks: “Because I can.”

One of the things I was looking forward to in Fedora 11 is better support for dual monitors. I wasn’t disappointed, the UI is very intuitive and it just worked, allowing me to share my laptop screen onto a spare monitor (seriously, I have too much hardware just lying around). So my home office now looks like:

Mission Control

Something else to realize is that with my synergy setup, a single mouse/keyboard is used to control both systems, meaning I can move the mouse from the leftmost side of the laptop to the rightmost side of the right monitor, an act that currently requires me to pick the mouse up to get more space 6 times (yes, I actually counted).

Not sure how long I’ll try this setup out; I’m guessing I’ll have a wicked headache before lunch. But that doesn’t change the fact that my office looks like a NOC right now.

I love you, Newegg

June 9th, 2009

I ordered the replacement video card for my MythTV box–

Actually, that’s not entirely accurate. I could have ordered a cheap replacement card for the Myth box. All it really needs to do is output to DVI, nothing fancy. The alternative is to take my video card from my gaming rig and move that to the Myth box, providing a reason to upgrade my gaming rig. That’s way more expensive, but I was careful to just tell the wife “I ordered a replacement video card.” I never said if I was using a cost optimal solution.

Where was I… oh ya, so I ordered a new video card yesterday at lunch. It arrived today at lunch. For no extra charge. When science perfects instant teleportation of objects, Newegg is going to raise the bar by just guessing at what hardware you need and sending it before you realize you need it.

*Poof*

June 9th, 2009

Last week I was catching up on some shows I recorded on my MythTV box (essentially a computer made into a home made Tivo) when the picture just disappeared. When I rebooted, it didn’t even show the BIOS, so I figured the video card died. I built the box back in 2004 and it’s always on, so it actually had a really good run.

While I’m waiting for the replacement card to arrive from newegg.com, I decided to take the existing card out, make sure the fan still spun, and reseat it back into the motherboard. It was worth a shot.

The inside of the box itself was a disaster. I try to air dust my desktops about once a month, but apparently I’m behind on this one. I tried to take a picture, but it doesn’t do it justice. I’ll simply point out that there is a dead spider inside.

Whenever I’m dealing with a piece of hardware that doesn’t work, I inevitably turn it around in my hands looking for… well, I don’t know what I’m looking for. I’m not an engineer, so short of seeing smoke coming from a part, no amount of physical inspection has ever yielded results.

This time was a bit different. Take a look at the second column of cylinders on the card below. I don’t know what they are or what they do, but I’m pretty sure the tops aren’t supposed to be blown out like that. The one closest to the camera even had what looked like ash coming out of it.

Burnt Video Card 1

Burnt Video Card 2

Might be time to plug in some of the fans I disabled to make the box run quieter. :)

And as a public service announcement, airdust your computer. It will love you for it.

Vim Recipes

June 4th, 2009

A coworker sent out the following link to the Spacewalk mailing list.

Vim Recipes

Don’t know what Vim is? Google it, I haven’t gotten around to blogging about it and Emacs yet. After you’ve googled it, install it. Yes, they have a Windows version.

Rather than being a straight user guide, it’s more of a guide on how to do useful shit in Vim. I took to Emacs keys much more easily (to the point that I remapped IntelliJ to use the common ones), but I’m really trying to force myself to get better with Vim. The recipes guide reads much better than any of the other tutorials I’ve looked into for Vim and has already shown me a number of useful tips.

For instance, the one thing that has always bothered me about Vim was how many steps it takes to save a file. I’m the kind of person who instinctively saves whatever I’m working on every time I stop to think. I’ve lost too much time by fat fingering something and closing the window without saving. In Emacs, that’s a very quick sequence:

Ctrl-x, Ctrl-s

It may look a little weird, but after using Emacs for 10 minutes, an easy key stroke to mindlessly use. In Vim, it takes a few more steps:

Esc  (to exit insert mode)
:w
i  (or a, to enter insert mode again so I can, ya know, actually type something)

That’s a lot of movement around the keyboard for something I do several times a minute (I stop to think a lot). Page one of that recipes guide already showed a useful way around that:

Use [Ctrl]+o in Insert mode to switch to Normal mode for one command, then return to Insert mode. For example, [Ctrl]+o gqas enters Normal mode, reformats the current sentence, then returns you to Insert mode.

In other words, it eliminates both the need to press escape as well as having to explicitly enter back into insert mode. So my mindless save now looks like:

Ctrl+o
:w

Much nicer. Even if that was all I picked up from the guide, it’d have been well worth it.

I won’t go into more specifics, but I was able to easily find information on repeating commands. I tend to use a lot of dividers in my text files, so being able to quickly generate 60 hyphens as a section header was a sore spot when learning Vim after Emacs. I’m also a big fan of temporary macros to repeat a sequence of changes, which I’m still figuring out how to do in Vim.

Eventually I want to write a bit more of a general introduction blog on Vim and Emacs (where I may explain the religious war between the two) in hopes I can convince my students to learn a real text editor (no, Wordpad doesn’t count and you ask for help while using Notepad, I’m docking your grade). I can’t stress enough that at some point in your career you will find yourself on some form of Linux/Unix/Solaris box where at least being able to navigate and edit text in Vi is pretty much required knowledge.

Synergy on Fedora 10

May 18th, 2009

Synergy

Ahhh… laziness. It was becoming too hard to rotate my chair the 10 degrees to turn and use my laptop keyboard and mouse. In the past I have used Synergy to share a single keyboard/mouse across multiple computers. Rather than requiring a hardware switch like a KVM, it lets you treat multiple computers as if they were the same desktop. In other words, I can literally use a single mouse to slide the cursor across multiple machines, treating them almost as if it was just a multiple screen display. You can even copy and paste across multiple computers.

So in the above picture, the keyboard and mouse on the tray is being used to control both the desktop and the laptop at the same time. When I slide the cursor off the left of the center monitor, it starts moving the cursor on my laptop. Win.

Here’s a quick overview of the steps to connect my desktop (guardian) as the host (in other words, the keyboard and mouse are connected to it directly) with my laptop (jdob-lt).

1.) Install synergy on both machines. Back when I first used this a few years (and jobs) ago, it was a bit of a pain in the ass to install. Life is a lot easier now since it’s included in the Fedora repositories.

yum -y install synergy

2.) Write the configuration file on the host machine. I’m normally a big fan of text-based configurations, but in this case I think a graphical configuration would make life a lot simpler. The configuration file can be put anywhere, so for consistency I put mine in /etc (make sure it’s readable by whatever user will be running the server daemon).

The following is my configuration file with comments where applicable. Keep in mind my comments are mostly my interpretation of what I’ve pieced together, so if there’s any source of confusion, RTFM.

# Declares the machines that will be connected.
# I used the hostnames of the machines, but there
# may be another means for identification.
section: screens
guardian:
jdob-lt:
end
 
# Describes the orientation of the screens in
# relation to each other. Read as "guardian has
# jdob-lt to the left" and "jdob-lt has guardian to its
# right". Yes, both directions need to be specified.
section: links
guardian:
left = jdob-lt
jdob-lt:
right = guardian
end
 
# I haven't played with this much, but this prevents
# the screen savers from syncing up.
section: options
screenSaverSync = false
end

3.) Start the server daemon. There are two binaries that come with the synergy package, one for the server (synergys) and one for the client (synergyc). Starting the server daemon is as simple as running the server binary and specifying the configuration file.

synergys --config /etc/synergy.conf

Additionally, the -f flag can be passed to the executable to cause it to run in the foreground. This is useful in debugging while you’re getting things set up. For instance, you’ll see messages such as:

DEBUG: CClientProxy1_0.cpp,404: received client "jdob-lt" info shape=0,0 1680x1050
NOTE: CServer.cpp,278: client "jdob-lt" has connected
INFO: CServer.cpp,447: switch from "guardian" to "jdob-lt" at 1679,521
INFO: CScreen.cpp,116: leaving screen
...
INFO: CServer.cpp,1440: screen "guardian" updated clipboard 1
DEBUG: CClientProxy1_0.cpp,278: send clipboard 1 to "jdob-lt" size=119
INFO: CServer.cpp,447: switch from "jdob-lt" to "guardian" at 42,761
INFO: CScreen.cpp,98: entering screen

One last server note, you’ll have to open up port 24800 if you use the synergy default.

4.) Start the client. Similar to the server executable, -f can be passed to keep the process in the foreground and view logging information. When starting the client, simply specify the location of the host (in this case, I have /etc/hosts configured to resolve “guardian” to its static IP).

synergyc guardian

If it connected correctly, you should see logging on the server similar to what’s posted above. A little more apparent is to simply try to slide the cursor from one screen across to a screen on the other computer. If it works, then you’re running.

5.) Sit back and admire the leetness.

The one thing I haven’t bothered with yet is setting this up to automatically run. It’s probably not much to set up some simple init.d scripts (I believe the client will auto-retry by itself in the cases it starts up before the server), I just haven’t taken the time to try yet.

Oh, and for the unenlightened, it runs on Windows too. And yes, you can connect Windows to Linux through synergy. Awesome.

Dreaming in Code

May 6th, 2009

Dreaming in Code

I’ve been reading Dreaming in Code for the past week. I forget where I first heard of it, but after a recommendation from a coworker on the Spacewalk team (thanks Partha) I finally followed through with checking it out.

The subtitle does a good job of explaining the book’s purpose: “Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software”. I hesitate to call it a case study in software projects because I don’t think it does justice to the book’s relaxed, conversational style. Rather than reading like a formal study, it’s the story of the development of Chandler an open source personal information manager with high goals. Rosenberg also provides a ton of related information to help frame the choices the Chandler team had to make, which increases the book’s audience significantly to include non-professionals.

I wish I was in a position to assign required reading for CSC majors. I’m not sure what class this would fall under (the most likely candidate is Software Engineering). Even then, the bigger challenge is convincing students of the value.

In short, anyone considering a career in programming needs to read this book. It provides an incredibly good insight into what it’s like to work on an actual project, an insight that students normally only get with experience after they’d graduated. Like I said, it’s presented more as a story of what happened rather than a technical manual, so it’s not painful to read.

But I cannot stress enough how much I would have appreciated such a detailed look into a real software project before I started on my career. Software Engineering text books describe what to do “by the book”. This book shows you a more realistic view of how those theories and practices can (and often do) go wrong.

JON 2.2 Released

April 29th, 2009

Congratulations to the JON team on the 2.2 release. Before moving to my current position on the Spacewalk team I spent two years on the JON team so it’s awesome for me to see the massive progress the product has made.

More information and screenshots at the JBoss.ORG Feed.