In September I didn’t do a 30 day challenge because, frankly, I had a lot of work that I really needed to crunch through at the Googleplex and I didn’t have much spare time. But October is a new month, and so it’s time for a new 30 day challenge.
For October, I’m not going to use any Microsoft software. No Microsoft operating systems (WinXP, Vista, or Windows 7) and no Microsoft Office allowed. I will continue to use their keyboards, because they make very nice keyboards, and I will allow myself to use their websites–sometimes I need to do a query on Bing to test how well they do, for example.
I don’t plan to switch to Apple, although I might try a Mac for a week. Apple products are polished and usable, so why not switch to Apple? That would be a much longer blog post. Apple makes great design decisions for the majority of people, but if you don’t like a particular decision, it can be very difficult to change it. Have you ever wanted to see the exact time (including seconds) on an iPhone? It’s hard to do, and I’m that kind of guy. Another big reason is just that I’m huge believe in free and open-source software, and I want to support that sort of software.
So on Friday I installed Ubuntu on my Windows XP laptop. On Saturday, I downloaded all the data from my pedometer (the software only runs in Windows) and shut down my home Windows XP machine. I already had a machine running Ubuntu at home, but I managed to get it driving two out of my three monitors:
What have I learned so far? The current version of Ubuntu (called “Jaunty Jackalope”) is really quite nice. There’s a lot of polish to the UI and the day-to-day tasks work very smoothly. At the same time, it’s possible to tinker around with something so much (I’m thinking about fonts right now) that you mess things up. But the dev version of Chrome for Linux has been really fast and stable, even though Chrome for Linux isn’t officially supported yet. I spend a large chunk of each day in a web browser, so having Chrome as an option was critical.
I’ll let you know how the 30 days turns out, but right now I’m optimistic.
Recently I treated myself to a solid-state drive (SSD). That’s essentially a hard-drive made out of memory chips. I bought the Intel X25-E Extreme, which uses faster single-level cell (SLC) memory chips instead of slower multi-level cell (MLC) memory chips.
I wanted to put the drive through its paces, so I decided to see how fast I could boot Ubuntu and start Firefox. It turns out that Ubuntu 9.04, code-named Jaunty Jackalope, is just a few days away, and one of the features listed is “significantly improved boot performance.” Perfect! I installed Ubuntu 8.10 from a CD and then followed the incredibly easy instructions to upgrade to the beta of 9.04.
So how fast did Ubuntu 9.04 boot with a solid-state drive? Really freaking fast. Like, “I can’t believe it’s already done” fast. Well, here, watch for yourself:
Total boot time from pressing power to Firefox loaded was about 22.5 seconds, with about 5 seconds of BIOS display on a Thinkpad. Subtracting out the Thinkpad BIOS display time, that means that Ubuntu 9.04 booted into Firefox in about 17.5 seconds. I think I’m going to have a lot of fun with this hard drive. Oh, and Ubuntu 9.04 looks really interesting too.
Added: I collected a couple bootcharts by using bootchart. As Ryan said in a comment, I ran sudo apt-get install pybootchartgui bootchart , then rebooted, then collected the image in /var/log/bootchart . If I’m reading the images correctly, it’s claiming 8.67 seconds for one boot-up and 8.69 seconds for the other boot-up.
Added: Okay, I reinstalled Ubuntu 9.04 so I could use ext4 and it shaved almost a second off the boot time! Check out this image which shows a 7.83 second boot time.
I really want to run Ubuntu, but it shouldn’t be this hard. Plugging in an SD card reader that I picked up from Best Buy shouldn’t cause a hard freeze of my system (on both Gutsy Gibbon and Intrepid Ibex):
The card reader works fine in Windows. At this point, I’m honestly thinking about crashing the Ubuntu Developer Summit that will be held in December at the Googleplex in Mountain View, CA to pick peoples’ brains.
Okay, so Ubuntu freezes hard when you plug in the card reader (sometimes). Unless you report that bug, no one will know to fix it. So I’m trying to follow these instructions for debugging removable devices to do a good Ubuntu bug report, and finding that the instructions are pretty out-of-date.
For example, you’re supposed to kill, then start gnome-volume-manager in a foreground mode to see debugging messages. Except that the latest version of Ubuntu (Intrepid Ibex) doesn’t even install gnome-volume-manager. Oh, you can install it (and you’ll get the sound-juicer package with it). But when you try to run it, you’ll get this helpful message:
It’s easy to find the source code of gnome-volume-manager online, but the relevant function is more cute than informative. Searching for ["live and let die" gnome-volume-manager] finds this post where someone tries to guess what the message means:
Fedora no longer uses gnome-volume-manager to auto-mount removable media — it’s now built into Nautilus. I am guessing that “live and let die” means “hey, someone else is already managing this” but that is pure speculation on my part. So if you get that error message it just means that you shouldn’t have been running it in the first place.
With that clue, you can go back and find this thread where Ubuntu developer wgrant helpfully lets someone know “gnome-volume-manager is no longer necessary either – nautilus does the mounting now.” It is good to find an Ubuntu developer posting answers online. But now I’m not sure how to generate Nautilus debugging logs akin to the gnome-volume-manager logs that fellow Ubuntu folks could use to debug the hard freeze. At least I do know how to generate udevmonitor logs using the new udevadm program.
Please pardon the melancholy tone. It’s just frustrating that plugging in an SD card reader can cause sporadic freezes on my Ubuntu computer. And if you plug in the SD card reader often enough, you may corrupt your system. I do see progress from Hardy Heron to Intrepid Ibex with several annoyances fixed, but there’s still a way to go.
Update: If any Linux/Ubuntu folks want to dig into it, I put all the log files I could think of at http://www.mattcutts.com/files/sandisk/ for folks that want to check it out.
In case you’re looking for the “udevmonitor” program on the Intrepid Ibex version of Ubuntu, it’s changed; use “udevadm monitor” now:
$ udevadm help
Usage: udevadm COMMAND [OPTIONS]
info query sysfs or the udev database
trigger request events from the kernel
settle wait for the event queue to finish
control control the udev daemon
monitor listen to kernel and udev events
test simulation run
version print the version number
help print this help text
It looks like udevmonitor was a symlink, and around April 2008, that symlink was removed. Someone asked about it on the Linux kernel mailing list and received this reply:
All udev tools are in one single binary called “udevadm”, which is
always in /sbin, and not like the old tools spread around in /sbin,
/usr/bin, /usr/sbin. See “man udev” for the reference to udevadm, and
“man udevadm” for the commands, which have been the individual tools
before.
So if you have a USB device that causes a hard freeze of your Linux computer when you plug it in, and you want to run udevmonitor to debug it, use udevadm monitor instead.
(This is a boring post that I’m writing for people that have this same problem in the future. Just skip it.)
Every good Linux user knows that if you want to drop from X down into a text-based virtual terminal, you can press control-alt-F1 (or any other key up to F6), and control-alt-F7 returns you to the graphical mode. But what if that doesn’t work? In my case, it turned out to be my keyboard. My Microsoft Natural Ergonomic Keyboard 4000 has a key marked “F Lock” and unless that FLock key is activated (the “F” LED should be on), the wrong keystrokes were being sent to my Linux Ubuntu version of Intrepid Ibex. How can you debug this? Well, it took me a while.
After some Googling, here’s how I’d write the flowchart:
- If running “chvt 1″ as superroot does work, then you probably have an issue with your keyboard mappings somehow.
- If you have a Microsoft Natural Ergonomic Keyboard 4000, make sure that the “F-Lock” key near the top-right of the main part of the keyboard is properly engaged. The “F” LED below the keyboard should be on.
- Next, run xev (possibly as root) to see raw xevents as you press keys. This thread helped, where the person said
Recently I tried to switch to VT (console) and I couldn’t – Ctrl+Alt+F1 didn’t work (and they used to couple of weeks ago). I don’t even know where to look for the problem; xev detects KeyRelease XF86_Switch_VT_1 event, /etc/inittab contain getty respawns.
When I ran xev myself, and pressed control-alt-F1, I saw an event like
KeyPress event, serial 38, synthetic NO, window 0×3400001,
root 0×1a6, subw 0×3400002, time 1848943, (42,37), root:(1751,59),
state 0×0, keycode 146 (keysym 0xff6a, Help), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
The fact that I saw a “Help” event rather than “XF86_Switch_VT_1″ was what made me suspicious. Sure enough, activating the “F-Lock” key then triggered this event:
KeyRelease event, serial 34, synthetic NO, window 0×3400001,
root 0×1a6, subw 0×3400002, time 2873229, (38,51), root:(1747,73),
state 0xc, keycode 67 (keysym 0×1008fe01, XF86_Switch_VT_1), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False