I'm a huge fan of FreeBSD. So much so that all my systems are running the latest version (8.1 as of this writing). Many of my blog posts are about FreeBSD or mention it in some way. So maybe that's why it bothers me to say this: FreeBSD just isn't well suited for a portable computer. I've fought it for some time and come to the conclusion that Linux just works better on laptops. A few of my gripes:
- Non-journaled filesystems suck. Using UFS + soft-updates helps but can be tedious on large drives. I think journaling + soft-updates is coming in 9.0 so maybe the level of suck will be less. Nonetheless, having to fsck a drive is an idea whose time has passed.
- ZFS kicks major butt but really needs a 64-bit CPU plus several gigs of memory, which leaves older laptops like mine out to dry. I can't get it to work as a root filesystem on any of my portable systems. I get a kernel panic on my i386 machines and the boot loader doesn't properly recognize my drives on my lone amd64 laptop.
- There's no good wireless manager for any of the BSDs. Linux has one called Wicd. It works with anything you throw at it, including WAPs that require an SSL certificate. You can do most of that in FreeBSD but it requires you to edit several config files. Try changing between locations that use different SSIDs or different encryption. Wicd continues to just work without needing to change any configs, even with the built in ncurses interface. Wicd is heavily tied to Linux (it makes use of the Linux proc filesystem) so porting it would basically require a rewrite.
- For some reason, Xorg seems to be hit or miss, driver-wise. It frequently hard locks on one of my systems with a Radeon but not another with a newer Radeon. I've never seen a lock up using the proprietary Nvidia drivers but the Nouveou drivers don't support 3D acceleration on all cards. I realize that most of the Xorg stuff is the same between BSD and Linux so that begs the question of why I see this on BSD but not Linux?
FreeBSD is rock solid on my desktop machines and ZFS on the root file system is a dream, so it's a bit disheartening that that experience didn't carry over to laptop-land. So, after dealing with the above annoyances I decided to throw my favorite Linux distribution on my laptops: Gentoo.
I wrote about Gentoo some time ago, ironically because I was critical of some things I needed in FreeBSD before I made the switch. Gentoo is unlike every Linux distribution out there (except the Linux From Scratch project) in that you have to build it in order to use it. This can be a serious turn off for folks that just want to install and get on with life, but I find it very intriguing and a great way to understand Linux at a much deeper level. The same idea holds when you want to install software; instead of prepackaged archives, you build it from source. This process is made easier with the Portage software management system, but you can tweak a near limitless amount of things to get exactly the kind of system you want. No bloat, no muss, no fuss.
With Gentoo installed, your next step to laptop bliss is to install Wicd to manage both your wired and your wireless interface (assuming you have one). Wicd is in the base Portage system, and assuming you chose the "desktop" Portage profile, installing Wicd should install a bunch of stuff. If you followed the Gentoo installation documentation, you probably added one or more of your Ethernet interfaces to your init scripts. Delete the net.eth scripts, but leave the net.lo script for the loopback interface. Add wicd to your init scripts by using 'rc-update add wicd default'. This ensures the wicd daemon starts so you can connect to networks. Since you don't have Xorg installed, you can use the ncurses interface by typing wicd-curses. Check out the man page for wicd for more details.
Next up is getting Xorg installed. This can take a while, but it basically involves specifying your video card type and input method (typically evdev on modern versions of the Linux kernel) in the /etc/make.conf file. Building Xorg will likely take quite a while so now might be a good time to catch up on your bash.org quotes. Make sure you get hald and dbus started and added to your init scripts when the build completes.
With the X server built, we're in the home stretch. The next thing to install is some sort of desktop environment like Gnome or KDE, or my preference, a simple window manager. You are, of course, free to install whatever tickles your fancy but for all my portable systems, nothing, and I mean NOTHING, beats StumpWM for a window manager. StumpWM is a rewrite of the Ratpoison window manager in Common Lisp. Ratpoison is heavily inspired by GNU Screen, so if you're an avid screen user, you'll feel right at home with both Ratpoison and StumpWM. Let me give you a few reasons why I think you should give one of these window managers a try before you go kicking and screaming back to Gnome or KDE.
- First and foremost, they're keyboard-driven. You're on a laptop, probably with an annoying touch pad or worse, the little pencil eraser pointer-thingy. Why would you inflict that kind of pain on yourself when you'll be far more productive if you could just keep your fingers on the keyboard?
- Ever fly commercial? Ever get stuck in coach next to someone that doesn't know the meaning of personal space? Good luck using an external mouse when you're crammed in like a sardine at 60,000 feet.
- If you write code for a living or even just as a hobby (you weirdo ), your brain will appreciate not having to break concentration to reach for a mouse when you need to switch between terminals or editors.
- They automatically maximize windows for you. You can see everything without needing to get a window sized just right with the mouse. You can, of course resize windows and split them as needed.
- Pretty much anything you can do on a laptop would be enhanced by a window manager that is keyboard controlled.
With all the above in mind, you'll want to pick either Ratpoison or StumpWM to use. Ratpoison is written in C, uses minuscule amounts of memory, and is easily installed using the 'emerge' command. StumpWM is written in Common Lisp, so you'll need to install that first. If hearing the word Lisp sounds vaguely familiar, it should be. Lots of other open source software is written in Lisp or uses it, such as Emacs and The Gimp. Some closed source software uses Lisp as well.
To get a Lisp interpreter, you'll want to install either the CLISP interpreter or the SBCL interpreter. I highly recommend you install SBCL instead of CLISP. Add the following to your '/etc/portage/package.use' file (you may need to create the /etc/portage directory and the package.use file if they don't exist):
media-libs/gd fontconfig dev-lisp/sbcl doc
Next, add the following to your '/etc/portage/package.keywords' file:
Your USE flags in '/etc/make.conf' should look at minimum like the following:
USE="sbcl -qt4 -kde X dbus hal -cups"
This should get you a working install of StumpWM but the version in Portage is pretty old and looks like it hasn't been touched in some time. Plus it doesn't even compile a StumpWM binary for you! Instead, you should use the version in the Git repository. In addition to making the changes above, emerge the following ports like so:
sudo emerge -av cl-clx cl-ppcre autoconf
You may need to install Git in order to grab the StumpWM source. Grab the StumpWM source like so:
git clone git://git.savannah.nongnu.org/stumpwm.git
I generally just keep the StumpWM source in my home directory. It doesn't take much space at all and there are several goodies in there. Go into that directory now and type "autoconf". Once that completes, type "./configure" You should see a lot of messages whizz by. Make sure the output of the configure script shows you're using SBCL. Once that completes, type "make". That should actually compile the StumpWM and Stumpish (Stumpish is a "shell" to StumpWM) binaries for you. Once that completes, you should have a StumpWM binary in your ~/stumpwm folder and a Stumpish binary in your ~/stumpwm/contrib folder. Copy both to /usr/local/bin as root. I tried adding my ~/stumpwm folder to my PATH and running it that way but it just doesn't work right, so installing both to /usr/local/bin is the way to go.
With a fresh copy of StumpWM built, add it to your .xinitrc: "echo 'exec stumpwm' >> ~/.xinitrc" and fire up a startx! You should see a welcome message. If you do, congrats! If not, you may want to try the StumpWM wiki.
Below is my .stumpwmrc file for you to pick apart and customize for your own needs:
;; My key bindings (in-package stumpwm) (define-key stumpwm:*top-map* (stumpwm:kbd "F12") "mode-line") ;; switching window (define-key stumpwm:*top-map* (stumpwm:kbd "M-Up") "pull-hidden-previous") (define-key stumpwm:*top-map* (stumpwm:kbd "M-Down") "pull-hidden-next") ;; switching frames (define-key *top-map* (kbd "M-Page_Down") "fnext") ;; switching groups (define-key stumpwm:*top-map* (stumpwm:kbd "M-Left") "gprev") (define-key stumpwm:*top-map* (stumpwm:kbd "M-Right") "gnext") (define-key stumpwm:*top-map* (stumpwm:kbd "M-F1") "gselect 1") (define-key stumpwm:*top-map* (stumpwm:kbd "M-F2") "gselect 2") (define-key stumpwm:*top-map* (stumpwm:kbd "M-F3") "gselect 3") (define-key stumpwm:*top-map* (stumpwm:kbd "M-F4") "gselect 4") (define-key stumpwm:*top-map* (stumpwm:kbd "M-F5") "gselect 5") ;; splits (define-key stumpwm:*top-map* (stumpwm:kbd "M-s") "vsplit") (define-key stumpwm:*top-map* (stumpwm:kbd "M-S") "hsplit") (define-key stumpwm:*top-map* (stumpwm:kbd "M-q") "only") (define-key stumpwm:*top-map* (stumpwm:kbd "M-r") "remove") ;; programs (define-key stumpwm:*top-map* (stumpwm:kbd "M-c") "exec xfce4-terminal") (define-key stumpwm:*top-map* (stumpwm:kbd "M-F") "exec firefox-2") ;; mouse (setf *mouse-focus-policy* :sloppy) ;; prefix key (set-prefix-key (kbd "Pause")) ;; wallpaper ;; (stumpwm:run-shell-command "display -window root '/home/<USER>/backgrounds/someimage.jpg'") (stumpwm:run-shell-command "fbsetbg -l") ;; ff command (define-stumpwm-command "firefox" () "Run or switch to firefox." (run-or-raise "firefox" '(:class "Firefox"))) (define-key *root-map* (kbd "w") "firefox") ;; Multimedia Keys (load "/home/<USER>/.stumpwm/multimedia-keys.lisp") ; Brightness Adjust (Fn + Up/Down) (run-shell-command "xmodmap -e \'keycode 212 = XF86LaunchE'") (run-shell-command "xmodmap -e \'keycode 101 = XF86LaunchD'") (define-key stumpwm:*top-map* (stumpwm:kbd "XF86LaunchE") "exec brightness +") (define-key stumpwm:*top-map* (stumpwm:kbd "XF86LaunchD") "exec brightness -") ;; Load Mode line ;; (load "/home/<USER>/.stumpwm/modeline-config.lisp") (toggle-mode-line (current-screen) (current-head)) ;; show the time in the mode-line (setf *screen-mode-line-format* (list '(:eval (run-shell-command "date '+%R, %F %a'|tr -d [:cntrl:]" t)) " | [^B%n^b] %W")) ;; Modeline Group Scrolling (setf stumpwm:*mode-line-click-hook* (list (lambda (&rest args) (cond ((eq (second args) 5) (run-commands "gnext")) ((eq (second args) 4) (run-commands "gprev")))))) ;; Theming ;; (load "/home/<USER>/.stumpwm/effects.lisp") ;; Male's code for key sequence display (defun key-press-hook (key key-seq cmd) (declare (ignore key)) (unless (eq *top-map* *resize-map*) (let ((*message-window-gravity* :bottom-right)) (message "Keys sequence: ~A" (print-key-seq (reverse key-seq)))) (when (stringp cmd) ;; Give 'em time to read it. (sleep 0)))) (defmacro replace-hook (hook fn) `(remove-hook ,hook ,fn) `(add-hook ,hook ,fn)) (replace-hook *key-press-hook* 'key-press-hook)
Feel free to use what you can and look around for anything I missed. It'll take a bit of getting used to, but once you do, using a keyboard driven, tiling window manager on your laptop becomes second nature and you wonder how you went without it. For a great video introduction to StumpWM, go here. Enjoy!
So I finally made the jump to a multiple monitor setup, and boy is it NICE! I've been using a dual screen setup at work for several years and found that it really does boost productivity. I had previously been using a single Apple 23" HD display I bought in 2004 when I bought a PowerMac G5. While I was a little apprehensive at first, it turns out that configuring a dual screen setup in FreeBSD is really quite simple.
First, you'll need to physically set your monitors up, including placing them on your desk and running the power and video cables. For video, you really will want to use at least DVI. VGA just doesn't cut it these days, both in terms of clarity and resolution. Fortunately, just about any display you can buy these days has a DVI connector (most have both VGA and DVI). Don't skimp on monitors either. You do have to look at them for some period of time so you'll want something with a good contrast ratio and response rate. I managed to snag two Samsung SyncMaster 2243 22" LCD monitors for $179 a piece at Microcenter (marked down from $219 a piece). I don't recommend going above this size if you sit close to your screens (and most of us do) because you may end up straining your eyes with very large displays. Also, don't just line the screens up side by side either. You'll want to have a somewhat concave layout so it feels more natural to your eyes and brain. I set my screens so that they meet in the middle of my desk and then a tilt them inward a few inches where they meet. Do this by lightly pushing against the place where the bezels meet with your thumb. You may need to adjust the pitch and tilt of the screens afterward to get the bezels properly lined up. With that done, connect the power and video cables. If you are connecting new screens to your system while you are already in your window manager, I would highly recommend powering down your system. I tried a warm reboot on mine after attaching the screens and was greeted by a kernel crash.
When your system boots, you might be greeted with a clone display (same picture on both monitors) or you may see output on just one screen. I'm no expert on Nvidia graphics cards, so I can't tell you what to expect for a given card. For my setup, I've got a Nvidia GeForce 9500GT. It's a low end card by today's standards for sure, but I don't do much gaming at all, so it meets my needs. Depending upon your setup, you may be greeted by either a display manager (Gnome Display Manager, etc...) or just a login prompt. I prefer to keep it simple and shun a display manager for the comfort of a black screen and a login prompt.
Once logged in, you'll need a shell, so open a terminal if you're in a window manager. Most users of Xorg these days can get by without a configuration file since Xorg is much better at configuring hardware on its own these days. If you have a static Xorg configuration and have your resolution hard coded, you may see nothing but gibberish. You can either reboot into single user mode and move your configuration file to a backup or just reattach your old screen. Personally, I never specify a resolution since Xorg gets it right anyways. If you do not have an Xorg config, su to root and use the following command to generate one:
# Xorg -configure
This should dump a file called xorg.conf.new in root's home directory. Open that file up in your favorite editor. Under the Device section, add the following line:
Here's what my Device section looks like:
Section "Device" Identifier "Card0" Driver "nvidia" VendorName "nVidia Corporation" BoardName "G96 [GeForce 9500 GT]" BusID "PCI:1:0:0" Option "TwinView" EndSection
Next, look for the Screen section. Under that will be several subsections named Display that are used for different color depths. In each of these, we need to add the Virtual directive. The parameters will be different depending on your screen resolution. Since my two screens are capable of a resolution of 1680x1050, I simply double my width parameter to 3360 (we want to span the width of the desktop across the two screens, remember?) to get a Virtual directive of "Virtual 3360 1050". Here's what it looks like for 24 bit depth:
SubSection "Display" Virtual 3360 1050 Viewport 0 0 Depth 24 EndSubSection
With both the TwinView option and the Virtual directive added, copy the configuration over to /etc/X11/ as just xorg.conf. You should be able to restart X or start it up if you're not using a display manager. You should see one gigantic screen! If not, check your settings. You may need to use Xrandr. It gets installed by default with the xorg-apps port. If you don't have the xrandr command, you may need to rebuild that port with the Xrandr option enabled. You can test it out by typing "xrandr" at a terminal prompt. You should see a good amount of output including your two display connectors (probably DVI0 and DVI1 or some variation), as well as the supported resolutions. If you do, try the following command:
% xrandr --output DVI1 --right-of DVI0
If you see a single large desktop, congratulations! You'll want to add the above command to your startup. This is usually at the top of the xinitrc file for non-GDM users or xsessions for GDM users.
Enjoy your added productivity and enormous desktop!
Those of us that type a lot will eventually begin to feel the effects of such an activity manifest as some sort of pain, most likely carpal tunnel syndrome. As somebody who has touch typed for the better part of 15 years, I definitely feel the effects every now and then. Several years ago I heard of an alternate keyboard layout called "Dvorak" that allegedly helped reduce the stress on your hands, but could potentially give you a free speed boost. I won't go into the nitty-gritty details, but encourage you to take a look at the Wikipedia article.
There are two ways to use the Dvorak layout: in the console and in Xorg. They're both quite easy to switch to as well.
To switch over your console, you can either run the sysinstall program as root or just manually specify the keymap using kbdcontrol -l "us.dvorak". Using sysinstall ensures that the Dvorak layout is retained after a reboot, whereas the kbdcontrol command does not. Switching back is as simple as using kbdcontrol -l "us" and removing the entry from rc.conf if you used sysinstall.
For Xorg users, simply open a terminal and run the following to toggle back and forth:
setxkbmap dvorak setxkbmap us
If you are using a desktop environment such as Gnome or KDE, you should be able to change the layout using the appropriate control panel.
I hope to work my way up to my QWERTY speed fairly quickly and be proficient in both layouts, but I'll certainly need to practice. For the record, this post took about 40 minutes to compose with my layout switched to Dvorak...
Ever since ZFS became production ready on FreeBSD 8 (and backported to 7), I've been itching to switch to using it and getting rid of UFS. For one, UFS is OLD. It was first used in 4.2BSD if that gives any indication. The most salient problem with UFS is the lack of real journaling. True, you have the soft-updates feature, but soft-updates are an alternative to journaling. This may not be a problem for users with older hardware and smaller hard disks, but with today's multi-terabyte drives, a power failure or system crash can lead to painfully long waits as fsck verifies the consistency of your file system.
To that end, I followed this handy guide to installing a FreeBSD system on a pure ZFS-only setup. Note that you'll end up with a system with no traces of UFS whatsoever, meaning you have to use the ZFS bootloader and can't dual boot anymore. If that's not to your liking, have a look at the index of ZFS on root guides. If you need to dual boot, you'll want to follow one of the MBR guides. For my needs, if I find myself needing to boot to another operating system, I simply hit F12 when my system is performing a POST test and choose a different drive to boot to. It's simple and separates your operating systems so they don't affect one another. Another alternative is to use virtualization if your needs aren't too demanding.
One thing none of the ZFS on root guides show you is also one of the most important: how to update and rebuild your system! If you're a developer you probably already know how to do this, but for the rest of us, it's important to know how to properly update your system when needed.
To begin, you'll want to sync your source tree. Instructions for that are located in the handbook, but it really boils down to using csup to synchronize source from a cvsup server to your local machine. If you do anything that requires building a kernel module, you're probably familiar with this. With your source tree synchronized to your desired version of FreeBSD, you can follow the the handbook guide to rebuilding world.
Once you have installed the kernel, reboot into single user mode as the guide tells you. Issue the "mount" command. You'll notice that no filesystems are mounted except for devfs and the root ZFS filesystem you marked as legacy. The handbook tells you to use "mount -a -t ufs" but obviously this won't work since we have banished UFS from our FreeBSD box. To mount all the ZFS mountpoints you have, simply use "zfs mount -a". This should mount everything except for / (root) as read-write. To enable a writable file system root, use "mount -uw /" and then "mount -a" to mount anything else. The "-uw" option unsets any mount options and then sets the write bit so you can write to that mount point. At this point you should be able to use mergmaster and installworld to finish rebuilding your system. One important task you must do before rebooting into your updated system is to install updated boot code. This is done with the following command after installing the new world: "gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 disk" where disk is the name of the drive you installed to (usually ad0). With this, you should have an updated system with ZFS as your file system!
I've been happily using FreeBSD 7.2 on my IBM Thinkpad T40 and decided it was time to upgrade to the latest and greatest: FreeBSD 8. FreeBSD 8.0 brings many changes to the base system, but one of the more significant ones is the configuration of wireless (802.11) networking. After a bit of mucking around, I've figured out some interesting things that relate to wireless, especially on the Thinkpad T40.
The biggest change is that you no longer configure the physical device interface. That is, no more "ifconfig_" where interface is either ath or ipw or some variation. Instead, you create a pseudo-interface, map it to the physical interface, and from there, configure your IP settings on the pseudo interface.
Another important point is the the existing ipw2100 driver that the Thinkpad relies on is horribly broken in FreeBSD 8. This means we'll have to configure the interface using NDIS instead. Don't worry though, it's not that difficult.
To begin, go to the Lenovo website and download the wireless drivers. There are several there, so be sure to grab the one for the Intel 2100 802.11b wireless interface. The filename should be 1rwc89ww.exe. Unfortunately, you'll need a nearby Windows machine to decompress the executable. Alternatively, you could probably download the same driver from Intel's website directly, but it's likely to be a self-extracting executable as well. Regardless of which method you use to obtain the driver, the two files we're interested in are named W70N501.INF and W70N51.SYS. The first file describes how to install the driver on a Windows computer and the second file is the actual driver itself.
Next, we need to convert the Windows driver to a kernel module that FreeBSD understands. To do this, go to the directory containing the two files mentioned above and type "% ndisgen W70N501.INF W70N51.SYS". From here, the ndisgen utility will prompt you for a few questions. Just continue to keep hitting enter. Note that you'll want to have a source tree on your system that is in sync with your kernel so ndisgen is able to build a kernel module. Consult the FreeBSD handbook in order to learn how to synchronize a source tree to your system. When finished, you should see a new file named W70N51_SYS.ko in your directory. Copy this file to the /boot/modules directory. You might even convert it to lower case to make things easier.
Now that we have a suitable driver in place, we need to load up the ndis API. To do this, type "sudo kldload if_ndis" and "sudo kldload ndis". To load our fancy new driver, type "sudo kldload W70N51_SYS" (or the lower case equivalent if you changed case). We're now ready to configure IP addressing.
I'll take the simplest use case and assume you're using WPA authentication and getting an IP address via DHCP. Add the following lines to /etc/rc.conf
The first line incorporates the new wireless interface in FreeBSD 8. It creates a "wlan0" pseudo-interface and maps it to the physical ndis interface. The second line simply tells the ifconfig command to use WPA authentication and to grab a dynamic IP. Next, add the following to your /boot/loader.conf to make these changes permanent:
At this point, you can either reboot the laptop or restart networking using "/etc/rc.d/netif restart". If you choose to restart networking, you might have to manually create the pseudo-interface using the following command: "ifconfig wlan0 create wlandev ndis0". If you are upgrading your laptop, you may wish to remove all the ipw* entries from both configuration files as they are no longer needed.
Using this configuration, one odd bug I've run into is that my wireless interface comes up and associates with the WAP but I do not get an IP address. I suspect that this could possibly be due to the fact that the DHCP server is on a different box, but I'll have to run a few debugs to see where it's sticking.
Using ndis, while a little clunky initially, has proven to be a much better replacement for the built in ipw driver. While I was on FreeBSD 7.2 and even Linux, my wireless interface would frequently reload the driver firmware. I'm told that's due to a bursting configuration on the WAP but I don't have bursting enabled and no other wireless device on my network displays the same behavior. Along with the cool changes in FreeBSD 8, this makes BSD on my laptop that much more enjoyable!
I have to admit, I'm a bit of a glutten for punishment. For some reason, I actually enjoy the challenge of lesser-known distributions. While I've been taking a good hard look at FreeBSD and how it might meet my needs, it is still lacking several key applications I rely on: VirtualBox (yes, it's in ports, but have you actually gotten it to work? I haven't) and the Adobe Flash player (tried gnash, didn't work. Adobe won't cough up an amd64 FreeBSD player). Granted, these are minor hiccups but other things are also keeping me from using FreeBSD on my main desktop.
To that end, I've been happily using Debian Lenny. It's nice because it generally works on anything you throw at it and the apt utility can't be beat for software management. Apt can also be a royal pain in the ass. I tried for hours to get it to play nicely and install mplayer with the codecs I wanted but there seemed to be a "stuck" package on my system that wouldn't upgrade. My other annoyance with apt is that applications aren't always updated as fast as they should be. The main one that comes to mind is Pidgin, the IM client that connects to all the different messenging networks. Again, I wrestled with apt for weeks, trying to get the latest greatest version of Pidgin without having to move over to Sid. I even tried using the backports repository. Still no dice.
That's when I started thinking about FreeBSD again. I've been using it successfully on a new laptop I've got (article on that to follow at some point) but there my requirements are much less. So then I thought about Gentoo. Gentoo has all the Linux goodness and a system called portage that isn't unlike the FreeBSD ports tree. In fact, portage was inspired by FreeBSD's ports system! So I set out to install Gentoo on my main desktop box.
I've got fairly vanilla hardware so I was sure that it was all supported. (specs: Intel Core2 Quad Q6600, 6 GB PC-8500 RAM, 2x 1 TB hard drives (one for backup), EVGA Geforce 9500 GT, Intel Pro/1000 NIC, Gigabyte EP45-3DSL motherboard, Logitech USB mouse and keyboard) I was happy to see that I was right. I simply burned a CD of the weekly minimal installer CD and booted up. Gentoo is interesting because unlike most other distributions of Linux, you aren't confronted with a happy graphical installer. Nope, you get dropped to a root prompt and have to go from there. Fortunately, the documentation is impeccable and very easy to follow. To take full advantage of my hardware, I followed the AMD64 guide, located here. I was lazy when I installed and opted to use Gentoo's "genkernel" package to build my kernel for me. I may trim down my kernel at a later point and remove all the junk that's not needed. After about 45 minutes, I had a bare system up and running.
The fun part is deciding where to take it from there. Since I'm using this machine as a desktop box, I installed Xorg and my current favorite window manager, XFCE. Like FreeBSD, Gentoo compiles all software from source code so you can really take advantage of your hardware. Unlike FreeBSD, however, Gentoo's portage system is a lot easier to use. Instead of drilling down the ports tree to find what you want, then issuing a "make install clean", you simply use the 'emerge' utility. This is as simple as "emerge --search <someapp>" to search for something and then "emerge <someapp>" to install it. emerge is definitely more powerful than that (I'm using it to update my entire system as I'm writing) so it's well worth either looking at the man page or the online documentation.
I did run into a few kinks along the way. After having a base system installed along with XFCE, I wanted sound so I can listen to some tunes while working. Since genkernel pretty much gives you a kitchen sink kernel, ALSA support was already in the kernel (which by the way, is how it's supposed to be moving forward I'm told). The only thing I had to do was to emerge the alsa-utils port so I'd get the mixer app and startup scripts. Documentation for that is located here.
The other kink I ran into was the need to dual boot that other OS. Yes, I still play the occasional game here and there but by and large, my days are spent in Linux doing stuff. The grub section under the installation guide is helpful, but not in a case where you've got Windows installed on a different drive. The problem is that Windows wants to be on the first drive and can't fathom why you'd want to boot into any other OS. To remedy this, I added the following information to my grub.conf file:
title Windows XP rootnoverify (hd2,0) map (hd0) (hd2) map (hd2) (hd0) chainloader +1
In my case, my Windows drive is the third physical hard disk installed (the first being the Linux installation and the second being the backup drive). Remember, in Grub-land, hard disks start at zero. Since Windows doesn't like not being the first drive, you have to trick its boot loader into thinking it is. This is where the map commands shown above come in handy. The last line just tells grub to seek 1 sector from the start of the partition (usually the boot sector).
So far I'm really impressed with Gentoo. I no longer have to worry about conflicts (emerge takes care of it for you) or outdated packages (emerge builds the latest/greatest depending on your system profile). My system is clean, has only what I actually use, and I have a far more thorough understanding of what's going on. What's not to like??
I've been looking for ways to improve the performance of my web site. Now that the biggest hurdle (MySQL) has seen dramatic improvements on FreeBSD (see article here), the only other hurdle really is PHP.
With a few quick Google searches, I found this article. The author details several of the tools needed to improve WordPress performance, but the one in general that helps seems to be eaccelerator, a PHP cacheing extension. I've noticed a dramatic improvement in performance so far. So what do you think? Is my site any faster?
No, I didn't fall off a cliff. Been busy with lots of stuff:
- Passed the CCDP ARCH test and became a CCDP on April 25th!
- Lots of house remodeling projects
- Working on my final Cisco test (for now : ), the MPLS exam
- Various other sundries
On the FreeBSD front, I found an old 250GB SATA drive and installed it in my current rig as the only drive (just to be sure I don't screw something up). Not surprisingly, rebuilding the kernel and world with the latest 7.2 Release is quite snappy as compared to the Thinkpad T40. I was pleased that the Nvidia driver in ports worked without a hitch though it has no 3D acceleration whatsoever. For that you need Nouveau. I went my usual install route: install the minimal FreeBSD distribution, build world and build kernel, build Xorg from ports (including mouse, keyboard, Nvidia driver, and vesa driver for backup) with HAL support, build some sort of window manager (Fluxbox is my current favorite), install a shell (I'm torn between bash and zsh), and install Firefox 3. The entire process took about an hour and a half.
All of my hardware either worked out of the box or worked after a few tweaks but I used the i386 version of FreeBSD, not the AMD64 version. Before I built HAL, I had to use a PS/2 keyboard in order to actually install. Either I missed something or USB hotplug support isn't there out of the box and needs to be added to rc.conf. I was pleasantly surprised to see that my Blackberry was recognized when I plugged it in. It didn't automount or anything but it was neat to see it get recognized. I've yet to get it to work, but there is a ports version of barry available. Barry is a little rough around the edges but I was able to back up my Blackberry Curve 8320 to my Linux box with it.
It seems like FreeBSD is maturing and quite rapidly. Now that VirtualBox is coming for FreeBSD, the only barrier left is either getting a native 64-bit Flash plugin/player or for Gnash to mature rapidly. I tried Gnash on i386 FreeBSD and it works, but only part of the time.
I still watch with a bit of wonder and amazement at the effort that goes into an Open Source operating system and applications. That the developers can get their projects working with little or no support from hardware vendors is nothing short of amazing.
Not too long ago I wrote a how-to article on how to get FreeBSD 7.0 working on my IBM Thinkpad T40. Among other things, I omitted a section on getting proper video drivers working. The graphics chip is an ATI RV250 (Mobility 9000). This means the driver you should use is the 'radeon' driver. Use 'pciconf -lv |grep ATI' to see which chip you've got. After toiling a bit with it, I figured out how to get the Open Source ATI drivers working.
Because I want to generally keep my systems pretty current, I recently installed FreeBSD 7.1 on my T40. It's important to know that the FreeBSD project generally breaks up development into three separate releases, namely CURRENT, STABLE, and RELEASE, in order of most bleeding edge to most stable. After building Xorg 1.6.0, I tried to start an X session just to see if I would get the ugly TWM desktop. To my surprise I got just a black screen but that was it. Even more surprising was that the usual "three finger salute" (ctrl + alt + backspace) didn't kill my X session. I then hit 'alt + F2' to log into another vty and manually kill off X. Here's where the fun began. It killed more than X; it locked my entire machine up. I continued futzing with my xorg.conf, kernel modules, and locking my system up for a good hour. I then threw in the towel and wound up asking a friend who's a FreeBSD developer WTF was going on. I learned a few interesting facts:
- The DRM code in 7.1 was more than 2 years old
- It is not necessary to manually load or pre-load any kernel modules for video
- X.org should work well with ATI graphics cards (but the amd64 release may not work) since the ATI driver model has had substantial structural changes to it.
On the first point, there's two ways around the old code: Either download/burn/install the FreeBSD 7.2 release candidate or rebuild world. Since I'm a glutton for punishment, I decided to rebuild world. It's not actually that hard, just time consuming. Use the 'csup' utility to grab the entire CVS source tree from your nearest csup server and follow the directions listed here to rebuild your system using the RELENG_7 tree.
The second point is easy enough. There's no need to add anything to your /boot/loader.conf file in order to get X working. X.org will load any necessary kernel modules when you type 'startx'. As an interesting aside, I actually locked my system up when attempting the unload the radeon.ko kernel module when I had learned that preloading isn't necessary. Doh!
Once you've rebuilt your system and are running 7.2-STABLE, it probably wouldn't be a bad idea to rebuild your installed ports. This isn't necessary per se since X.org should work without even building a config file, but it is a good step, just to make sure everything is up to date. I use the portupgrade utility located in /usr/ports/ports-mgmt/ with the following: portupgrade -aRr. That should upgrade all outdated ports recursively as well as recursively rebuilding dependencies.
I'll expand on the last point a bit. ATI has been much more generous with contributing documentation to the Open Source community than Nvidia. In fact, Nvidia hasn't contributed anything other than a proprietary driver for Linux and FreeBSD, though there's a project called Nouveau which aims to build an Open Source Nvidia driver. Because of this, FreeBSD has an Open Source ATI driver (/usr/ports/x11-drivers/xf86-video-radeonhd and usr/ports/x11-drivers/xf86-video-ati) and using the old proprietary fglrx driver is no longer necessary. There's one hiccup to this though. The driver has to be re-worked every time a new ATI chip comes out. To solve this, ATI is moving towards the same unified driver model Nvidia has used for years and taking it a step further. They now have an Open Source BIOS abstraction layer called ATOMBios. The idea is to make it easier to more rapidly deploy drivers for new graphics cards. Read all about that in this article. Bravo ATI!
By the time you finish reading this, your ports should be up to date and you should be able to use hardware accelerated ATI drivers on your Thinkpad. I'm running XFCE4 on my Thinkpad and it's causing me to reevaluate the old "FreeBSD vs. Linux" question. Maybe I'll spend a little more time working on the other parts that I overlooked in my article.