| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
|---|---|---|---|---|---|---|
| < | > | |||||
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | 31 | |||
Choose skin
Michael K. Johnson
I used to use the galeon web browser. I got used to having tabs on the right side of my browser; I can have lots of tabs and read what is in them. This works in part because I devote one workspace entirely to a full-screen browser.
When galeon maintenance ceased, I did not update until I found the vertigo Firefox extension. Then I stayed on Firefox 1.5.0.x until vertigo supported Firefox 2. Now, I have been staying on Firefox 2 because vertigo does not support Firefox 3. This is starting to feel familiar.
Today, I found a mention of Tree Style Tab as supported by Firefox 3. Trying it out, I was pleasantly surprised; the configuration options are better, and I like the tree style where you can see which tabs were opened from other tabs (this can be disabled if you don't like that feature, though).
Now, the only thing that keeps pushing me back to Firefox 2 is the fact that Firefox 3 does not actually bring up a window, even if I specify -safe-mode, unless I completely remove my .mozilla directory. I haven't yet figured out what it is in my .mozilla directory that is confusing Firefox 3 that badly. This makes me sad.
Update: The problem was that this build of Firefox 3 (I don't know about any other builds) has a broken profile manager, and my profiles.ini setting of StartWithLastProfile=0 causes Firefox to start the profile manager and quit. Changing that 0 to a 1 works around the problem for now; I *usually* choose the default profile anyway, and I do know how to edit profiles.ini to change the default profile even without the profile manager working.
Cristian Gafton laments the demise of the 4:3 aspect ratio laptop screen on Lenovo thinkpads, and says that he is now looking at other brands of laptops as a result. I wish him luck; I suspect that other brands are doing the same thing as a result of concentration of production on 16:9 due to widespread consumer demand. For example, all the HP laptops I could see on the HP website were widescreen. I had to cruise the Dell site for a while before I found the Latitude D530 ("entry level") with a 4:3 aspect ratio. The Gateway site buries this so deep that I lost interest before finding any 4:3 screens (if they carry any). Most Fujitsu laptops are widescreen; the only 4:3 I found on their website are the LifeBook S2210 and Stylistic tablets (all 13" XGA). At this point, I got tired of investigating.
I like pixels. So much so that I've paid extra to get laptops with 1600x1200 screens. One of my main problems with the 1600x1200 screen was that four 80x24 terminal sessions using the huge classic 10x20 X font (now represented as MiscFixed 18) that I love so much do not quite fit on it. In particular, they don't quite fit side-by-side, even if you disable scrollbars. My 1680x1050 widescreen laptop, however, can do that (even with scrollbars on the terminal windows if I choose to use them) with room to spare, and without covering the GNOME toolbar. This makes me happy.
Somewhat as a sidenote, but equally easier to read on the wide screen, I've also changed my coding window arrangement. Two terminal sessions, each with multiple tabs, full-height, 80 characters wide, side by side. I generally write code in tabs in the left-hand terminal session and write/run tests in the right-hand terminal session. In vim, of course.
Oh, and with regard to the various batteries, the 9-cell batteries are still available as of this blog post... Update: It appears that different T61 laptops use completely different batteries, with different voltages, physical interfaces, and capacities. Not what I would have expected for the Thinkpad line, at any rate.
NetworkManager updates seem to do a very poor job of maintaining compatibility with configuration saved by earlier versions of NetworkManager. I don't know if it is lack of sane schema migration or something else, but when (after updating the NetworkManager stack) networking goes flaky, I sometimes have to do the following steps to return my system to having working networking.
$ killall nm-applet $ sudo service NetworkManager stop $ gconftool-2 --recursive-unset /system/networking $ sudo service NetworkManager start $ nm-applet&
Of course, this removes all my networking configuration, so I have to start over. But that's better than totally broken (or just flaky) networking.
It is very annoying when the system that requires this action belongs to a less Linux-savvy family member whose networking has just been damaged by an update to NetworkManager.
I sure hope that as NetworkManager moves to being the core network configuration tool for systems, it gets more reliable! As it is, I feel that NetworkManager has been earning the epithet "NetworkMangler" that I've heard applied to it so often.
I have a dual-boot system that, on rare occasions, finds itself running windows. It used to be limited to taxes and GPS database programming, but now it is limited to taxes, GPS database programming, and logitech harmony programming.
Since I so rarely run windows, I keep forgetting or repressing how hard it is to use, and how easily it breaks, catastrophically. I rant loudly whenever things break under Linux about how unacceptable it is.
I just went through the exercise of doing my taxes in turbotax. It occasionally went unresponsive or would simply quit displaying some of its user interface elements, but a restart would bring it back. Once turbotax disappeared entirely right in the middle of using it. (Oh, that's why it auto-saves so often. I guess they expect that.)
Then I wanted to print some forms. Of course, I don't have a printer connected, so I figured I'd just print a PDF (or postscript, that would be OK too) and print it later.
Half an hour later, muttering, I went downstairs to plug my computer into the laserjet. It's an HP LaserJet 1320 -- supports PCL6 and Postscript, has USB, and has been trivially supported under Linux for years. I figured I'd just move the USB cable temporarily to the machine running windows.
Or maybe not.
I tried letting windows try to install the driver automatically. Several times. Then I went to the HP web site, and downloaded three different drivers to try (no help from HP on which drivers to use). None of them worked. I finally, in desperation, found the CD that shipped with the printer. No luck. An hour and twenty minutes later, you'd think that at least I'd still have a working system, even if I couldn't print the tax forms.
I remember jokes about suspend/resume from years ago: "My laptop suspends fine, it's just resume that doesn't work so well." Unfortunately, after these attempts to get printing working, the system no longer shuts down. It just hangs indefinitely with nothing displayed on a blue background. The only way to get it to shut down is to hold the power button down until the hardware timeout passes and the system is forcibly shut down. It's not the "blue screen of death" -- it's the normal (for me) blue background shown during shutdown, it just never goes away. Call it the "blue screen of zombie", I guess.
Of course, setting this printer up under Linux took all of about one minute some years ago, and it has worked flawlessly ever since.
And no, I'm not crazy enough to be running vista with all its performance and driver problems. This is a recent XP install as shipped on a thinkpad.
Afer all that trouble, I find (back on my trusty Linux system) that the IRS site has the form in PDF, that it is a fillable PDF, and that evince can fill it in. This will take all of a couple minutes; I don't even have to use a pen except to sign the form.
Last week, I spent a lot of my time working on a Conary feature: reporting possibly excessive elements of the buildRequires list. For years, Conary has been recommending additions to the buildRequires list when it notices possible reasons that something might be missing, whether that is because of a dependency, an entry in config.log, or Conary itself running a program.
Recently, those requirements have gotten so good that if you cook a recipe on a system with a full set of software installed, most of the time Conary figures out all the things you need to build. And the better job we do of making Conary do that, the more interest there has been in making Conary tell you which elements of your buildRequires list are not needed.
It took some work to make Conary actually record all the necessary dependencies rather than only the ones that it found missing, but after that, I was able to make Conary report the potential extras. And it has been finding real cases of excess buildRequires. For example:
info: Possible excessive buildRequires: ['userspace-kernel-headers:devel']
I found that while building lvm2 as a sample test package, and it's absolutely true: 'userspace-kernel-headers:devel' is part of the superclass and doesn't need to be mentioned in the lvm2 recipe at all.
However, Conary's recommendations for removing excess build requirements are only as good as its recommendations for adding missing ones; they are opposite sides of the same coin. And while an extraneous build requirement rarely causes much trouble, a missing build requirement is generally catastrophic. Therefore, take these recommendations with a grain of salt. There's a reason that it says Possible in the informational message!
This feature will require both Conary 2.0.12 and conary-policy 1.0.16, neither of which is yet released as I write this...