Enlil, my primary development system, died of a fried motherboard. My good friend James did all he could to save it, but finally he called me with the bad news. Later he brought over the remains: SATA drives and DDR2 chips. “Thanks for the memories,” I muttered.
I got a great deal on a new ASUS Core i3 notebook for about 1/4 of what I had paid for the HP, with twice the memory and disk space. It came with Windows 7 Home Edition installed – which I promptly erased.
Well, that wasn’t the first thing I did. First, I booted it up to test out all the hardware. If anything didn’t work, I’d want the factory-installed OS still on it when I sent it back. No problems there, though.
The second thing I did was to back up the factory-installed OS in case anything died during the warranty period. Then, I wiped Windows 7 off the disk and installed FreeBSD 8.0-RELEASE amd64.
Free at last!
I have hated Windows for some time now, and I had previously tried a couple of test installs of FreeBSD under VMWare to get my feet wet, with some help from my good friend Chad Perrin. Thus, my initial install went off without a hitch, and I was readily able to build most of the applications I’d need from the ports, including FireFox, OpenOffice (which was quite involved, thanks to having to build Java), VirtualBox, samba, and others. I downloaded vim 7.2 (not in ports yet) and built that as well.
Virtual Box runs better than I had expected. I installed Windows 7 Enterprise 64-bit as a guest OS without a hitch (I still have to develop for Windows), and it seems to run faster under VirtualBox than the factory-installed Win7 ran on bare metal.
Making X not so Windowsish
For an X11 window manager, I started off with WindowMaker, which is what I’ve used on Linux and when playing with FreeBSD before now. Chad had recommended it long ago, and it worked OK. After a little research, though, I discovered xmonad.
Xmonad is a very minimal window manager, designed for productivity and keyboard-orientation. By default, it tiles windows to make the most use of available space, but you can also untile windows or configure it to float windows based on their class or other characteristics. Xmonad is written in Haskell, and all the configuration files are in Haskell as well. Lucky me, I just learned Haskell last month. Xmonad supports up to 9 workspaces, and can use multiple monitors to view multiple workspaces simultaneously.
Here’s a screen shot (click to enlarge):
The left and right panes are uxterm windows. The right one has focus, as indicated by its red border. I’ve mapped the Windows key (mod4) to mod for xmonad (the default is Alt, which is too useful in other apps) — mod+K would move focus “up” to the main window on the left, and mod+J moves down, with wrap-around. mod+L moves the right border of the main window to the right (making it bigger), while mod+H does the opposite. Notice the vi similarilty? mod+shift+enter opens a new uxterm, which in this case would split the right pane vertically. mod+shift+q quits Xorg, mod+1..9 activates the corresponding workspace, mod+shift+1..9 moves the focused window to that workspace. mod+p brings up dmenu, and mod+space changes the layout. By default, layout cycles from main-on-left to main-on-top, then to main-full-screen, then back to main-on-left – but all of the layouts are configurable.
Even though xmonad is very keyboard-centric, it intelligently understand the mouse, in case you accidentally grab it out of Windows Habittm.
The only thing I haven’t figured out yet with xmonad is what key sequence I need to map to be able to lose focus on Windows 7 running in VirtualBox. Windows wants both the Alt and the Windows key, so I have to use the mouse to focus something else in order to use either one – but that means I have to already have another window open to focus. I’m hoping to find some sequence that Windows won’t swallow that I could map to go to a different workspace, or perhaps find a way to avoid having the Windows key captured by VirtualBox at all.
UPDATE: All I needed to do was press the right control key to release keyboard focus, and then all keystrokes go to xmonad. I knew there had to be a simple solution.
Naturally, you can customize the keyboard shortcuts for xmonad, as I have in xmonad.hs which is shown in the left pane above. I’ve mapped mod+f to launch Firefox, Ctrl+Print to let me select a window to capture with scrot, Print to capture the desktop, and I’ve remapped mod+p to launch dmenu with the options that I prefer. I’ve also added a manageHook to specify that any windows of class “Gimp”, “XDaliClock”, or “Gnubg” should be floated rather than tiled. I’ve also customized the colors and border width (I can’t readily see the default 1-pixel border – I need 3, but I don’t like the bright red, so I toned it down).
You may notice the status bar across the top. That’s xmobar, which is designed to work well with xmonad. It, too, is written and configured in Haskell. You can see my .xmobarrc at the top of the right pane. I’ve customized the colors and specified the various commands that need to be run to populate the status bar, as well as the intervals between updates. The “mem”, “loadavg”, and “batt” commands are shell scripts I’ve written to get that information from sysctl. xmobar’s built-in functions use /proc/stat a la Linux, which isn’t available on FreeBSD. If anybody wants to see a copy of those shell scripts, let me know. Maybe I’ll post them on Chip’s Tips.
Look at the memory and load average stats in the status bar. Unlike Windows, when FreeBSD isn’t doing anything, it isn’t doing anything. I also like the free disk space I have after installing all those applications (see the du output at the bottom of the right pane).
The only downside I’ve found so far is the video driver for X11. The Intel Core i3’s integrated graphics processor doesn’t seem to be recognized by the intel driver for X, so I have to use the vesa driver for now. That’s only capable of 1024×768, which on the 1600×900 notebook screen looks like a regular 4:3 TV feed does on a widescreen in 16:9 aspect ratio – everything’s too short and fat. Very small fonts are illegible. The vesa driver also doesn’t seem to want to work with a multi-monitor configuration. If I have an external monitor plugged in, that’s the one it sees (based on reported characteristics — it still displays on the notebook monitor, too) – otherwise it sees the notebook’s monitor only. At first, I couldn’t get it to work with just the notebook’s built-in monitor, but I found that I needed to add a range for horizontal sync and vertical refresh to the xorg.conf file.
A new goddess
Even limited to one screen with compromised resolution, I’m loving this system. It’s so fast and lean, and I feel that I can do anything with it. It certainly isn’t a system for beginners, though. Can you imagine telling your mother to just rebuild the kernel? Not that it’s that difficult on FreeBSD (I have already, in my quest for a video driver), but the mere idea would fill the shorts of most users. Maybe it takes some balls on FreeBSD, but on Windows you can’t do it at all.
With FreeBSD everything is within your grasp. If I work up enough bravado, I might even try writing my own video driver. If something doesn’t work on Windows, too bad. Maybe it will next version, which might be available next year, or six years from now. I’m not going back, Jim!
That’s why I named my new system Libertas.