Shallow Thoughts : : Aug
Akkana's Musings on Open Source Computing and Technology, Science, and Nature.
Sat, 25 Aug 2007
On a seemingly harmless trip to Fry's,
my mother got a look at the 22-inch widescreen LCD monitors
and decided she had to have one. (Can't blame her ... I've been
feeling the urge myself lately.)
We got the lovely new monitor home, plugged it in, configured X
and discovered that the screen showed severe vertical banding.
It was beautiful at low resolutions, but whenever we went to
the monitor's maximum resolution of 1680x1050, the bands appeared.
After lots of testing, we tentatively pinned the problem
down to the motherboard.
It turns out ancient machines with 1x AGP motherboards
can't drive that many pixels properly,
even if the video card is up to the job. Who knew?
Off we trooped to check out new computers.
We'd been hinting for quite some time that it might be about
time for a new machine, and Mom was ready to take the plunge
(especially if it meant not having to return that beautiful monitor).
We were hoping to find something with a relatively efficient Intel Core 2
processor and Intel integrated graphics: I've been told the Intel
graphics chip works well with Linux using open source drivers.
(Mom, being a person of good taste, prefers Linux, and none of us
wanted to wrestle with the proprietary nvidia drivers).
We found a likely machine at PC Club. They were even willing to
knock $60 off the price since she didn't want Windows.
But that raised a new problem. During our fiddling with her old
machine, we'd tried burning a Xubuntu CD, to see if the banding
problem was due to the old XFree86 she was running. Installing it hadn't
worked: her CD burner claimed it burned correctly, but the resulting
CD had errors and didn't pass verification. So we needed a CD burned.
We asked PC Club when buying the computer whether we might burn the
ISO to CD, but apparently that counts as a "data transfer" and their
minimum data transfer charge is $80. A bit much.
No problem -- a friend was coming over for dinner that night,
and he was kind enough to bring his Mac laptop ...
and after a half hour of fiddling, we determined that his burner
didn't work either (it gave a checksum error before starting the
burn). He'd never tried burning a CD on that laptop.
What about Kinko's? They have lots of data services, right?
Maybe they can burn an ISO. So we stopped at Kinko's after dinner.
They, of course, had never heard of an ISO image and had no idea how
to burn one on their Windows box.
Fearing getting a disk with a filesystem containing one file named
"xubuntu-7.04-alternate-i386.iso", we asked if they had a mac,
since we knew how to burn an ISO there.
They did, though they said sometimes the CD burner was flaky.
We decided to take the risk.
Burning an ISO on a mac isn't straightforward -- you have to do
things in exactly the right order.
It took some fast talking to persuade them of the steps ("No, it
really won't work if you insert the blank CD first. Yes, we're quite
sure") and we had to wait a long time for Kinko's antivirus software
to decide that Xubuntu wasn't malware, but 45 minutes and $10 later,
we had a disc.
And it worked! We first set up the machine in the living room, away
from the network, so we had to kill
when the install hung installing "xubuntu-desktop" at 85%
(thank goodness for alternate consoles on ctl-alt-F2) but otherwise
the install went just fine. We rebooted, and Xubuntu came up ...
at 1280x1024, totally wrong. Fiddling with the resolution in xorg.conf
didn't help; trying to autodetect the monitor with
dpkg-reconfigure xorg crashed the machine and we had to
Back to the web ... turns out that Ubuntu "Feisty" ships with a bad
Intel driver. Lots of people have hit the problem, and we found a
few elaborate workarounds involving installing X drivers from various
places, but nothing simple. Well, we hadn't come
this far to take all the hardware back now.
First we moved the machine into the computer room, hooked up
networking and reinstalled xubuntu with a full network, just in
case. The resolution was still wrong.
Then, with Dave in the living room calling out steps off a web page
he'd found, we began the long workaround process.
"First," Dave suggested, reading, "check the version of
Let's make sure we're starting with the same version this guy is."
dpkg -l xserver-xorg-video-intel ... "Uh, it isn't
installed," I reported. I tried installing it. "It wants to remove
xserver-xorg-video-i810." Hmm! We decided we'd better do it,
since the rest of the instructions depended on having the
intel, not i810, driver.
And that was all it needed! The intel driver autodetected the monitor
and worked fine at 1680x1050.
So forget the elaborate instructions for trying X drivers from various
The problem was that xubuntu installed the wrong driver:
the i810 driver instead of the more generic intel driver.
(Apparently that bug is fixed for the next Ubuntu release.)
With that fix, it was only a few more minutes before Mom was
happily using her new system, widescreen monitor and all.
[ 14:23 Aug 25, 2007
More linux |
permalink to this entry |
Tue, 21 Aug 2007
Dave and I are helping my mom shop for a new computer to drive a
22-inch widescreen monitor, 1680x1050 (long story, more on that later).
This is how we find ourselves in Circuit City staring at a
candidate PC on the lower shelf running a 19-inch widescreen at 1440x900.
Unfortunately that's not the resolution we were hoping to check.
There's an unplugged 22-inch LCD on the shelf right above it,
just like the one we're trying to get working.
A salesguy comes by and ask if we have any questions, so I ask him,
"Is there any way we can plug that monitor into this computer to see
if it works?" and explain our mission.
He's amenable, and plugs it in,
but Windows doesn't notice the new monitor. I try Display
Settings but it's still maxed out at 1440x900.
I ask the salesguy, "Can we try rebooting or something?
Maybe that'll make Windows see it."
He looks puzzled. "But it's already running a widescreen monitor."
I point to the Display Settings window. "But it's only running at
1440x900, and that's the most it'll let us use."
He says, "Oh, you wanted to run that 22-inch at full resolution?"
Me: "Well, yeah."
Salesguy: "But ... then your text will be small!"
[ 11:42 Aug 21, 2007
More humor |
permalink to this entry |
Sat, 18 Aug 2007
I'm forever having problems connecting to wireless networks,
especially with my Netgear Prism 54 card. The most common failure mode:
I insert the card and run
(udev is supposed to handle this, but that stopped working a month
or so ago). The card looks like it's connecting,
says it has the right IP address and it's marked up -- but try to
connect anywhere and it says "no route to host" or
"Destination host unreachable".
I've seen this both on networks which require a WEP key
and those that don't, and on nets where my older Prism2/Orinoco based
card will connect fine.
Apparently, the root of the problem
is that the Prism54 is more sensitive than the Prism2: it can see
more nearby networks. The Prism2 (with the orinoco_cs driver)
only sees the strongest network, and gloms onto it.
But the Prism54 chooses an access point according to arcane wisdom
only known to the driver developers.
So even if you're sitting right next to your access point and the
next one is half a block away and almost out of range, you need to
specify which one you want. How do you do that? Use the ESSID.
Every wireless network has a short identifier called the ESSID
to distinguish it from other nearby networks.
You can list all the access points the card sees with:
iwlist eth0 scan
(I'll be assuming eth0
as the ethernet device throughout this
article. Depending on your distro and hardware, you may need to
or whatever your wireless card
calls itself. Some cards don't support scanning,
but details like that seem to be improving in recent kernels.)
You'll probably see a lot of ESSIDs like "linksys" or
"default" or "OEM" -- the default values on typical low-cost consumer
access points. Of course, you can set your own access point's ESSID
to anything you want.
So what if you think your wireless card should be working, but it can't
connect anywhere? Check the ESSID first. Start with iwconfig:
lists the access point associated with the card right now.
If it's not the one you expect, there are two ways to change that.
First, change it temporarily to make sure you're choosing the right ESSID:
iwconfig eth0 essid MyESSID
If your accesspoint requires a key, add
to the end of that line. Then see if your network is working.
If that works, you can make it permanent. On Debian-derived distros,
just add lines to the entry in /etc/network/interfaces:
Some older howtos may suggest an interfaces line that looks like this:
up iwconfig eth0 essid MyESSID
Don't get sucked in. This "up" syntax used to work (along with pre-up
and post-up), but although man interfaces still mentions it,
it doesn't work reliably in modern releases.
Use wireless-essid instead.
Of course, you can also use a gooey tool like
gnome-network-manager to set the essid and key. Not being a
gnome user, some time ago I hacked up the beginnings of a standalone
Python GTK tool to configure networks. During this week's wi-fi
fiddlings, I dug it out and blew some of the dust off:
You can choose from a list of known networks (including both essid and
key) set up in your own configuration file, or from a list of essids
currently visible to the card, and (assuming you run it as root)
it can then set the essid and key to whatever you choose.
For networks I use often, I prefer to set up a long-term
scheme, but it's fun to have something I can run once to
show me the visible networks then let me set essid and key.
[ 15:44 Aug 18, 2007
More linux |
permalink to this entry |
Sun, 12 Aug 2007
The best thing at Linuxworld was the Powertop BOF,
despite the fact that it ended up stuck in a room with no projector.
The presenter, Arjan van de Ven, coped well with the setback and
managed just fine.
The main goal of Powertop is to find applications that are polling or
otherwise waking the CPU unnecessarily,
draining power when they don't need to.
Most of the BOF focused on "stupid stuff": programs that wake up
too often for no reason. Some examples he gave (many of these will
be fixed in upcoming versions of the software):
- gnome-screensaver checked every 2 sec to see if the mouse moved
(rather than using the X notification for mouse move);
- gnome volume checked 10 times a second whether the volume has changed;
- gnome-clock woke up once a second to see if the minute had rolled
over, rather than checking once a minute;
- firefox in an ssl layer polled 10 times a second in case there was a
- the gnome file monitor woke up 40 times a second to check a queue
even if there was nothing in the queue;
- evolution woke up 10 times a second;
- the fedora desktop checked 10 times a second for a smartcard;
- gksu used a 10000x/sec loop (he figures someone mistook
milliseconds/microseconds: this alone used up 45 min on one battery test run)
- Adobe's closed-source flash browser plugin woke up 2.5 times a
second, and acroread had similar problems (this has been reported to
Adobe but it's not clear if a fix is coming any time soon).
And that's all just the desktop stuff, without getting into other
polling culprits like hal and the kernel's USB system. The kernel
itself is often a significant culprit: until recently, kernels woke
up once a millisecond whether they needed to or not. With the recent
"tickless" option that appeared in the most recent kernel, 2.6.22,
the CPU won't wake up unless it needs to.
A KDE user asked if the KDE desktop was similarly bad. The answer
was yes, with a caveat: Arjan said he gave a presentation a while back
to a group of KDE developers, and halfway through, one of the
developers interrupted him when he pointed out a problem
to say "That's not true any more -- I just checked in a fix while
you were talking." It's nice to hear that at least some developers
care about this stuff! Arjan said most developers responded
very well to patches he'd contributed to fix the polling issues.
(Of course, those of us who use lightweight window managers like
openbox or fvwm have already cut out most of these gnome and kde
power-suckers. The browser issues were the only ones that applied
to me, and I certainly do notice firefox' polling: when the laptop
gets slow, firefox is almost always the culprit, and killing it
usually brings performance back.)
As for hardware, he mentioned that
some linux LCD drivers don't really dim the backlight when you
reduce brightness -- they just make all the pixels darker.
(I've been making a point of dimming my screen when running off batteries;
time to use that Kill-A-Watt and find out if it actually matters!)
Wireless cards like the ipw100 use
a lot of power even when not transmitting -- sometimes even more than
when they're transmitting -- so turning them off can be a big help.
Using a USB mouse can cut as much as half an hour off a battery.
The 2.6.23 kernel has lots of new USB power saving code, which should help.
Many devices have activity every millisecond,
so there's lots of room to improve.
Another issue is that even if you get rid of the 10x/sec misbehavers,
some applications really do need to wake up every second or so. That's
not so bad by itself, but if you have lots of daemons all waking up at
different times, you end up with a CPU that never gets to sleep.
The solution is to synchronize them by rounding the wakeup times to
the nearest second, so that they all wake up at
about the same time, and the CPU can deal with them
all then go back to sleep. But there's a trick: each machine has to
round to a different value. You don't want every networking
application on every machine across the internet all waking up at once
-- that's a good way to flood your network servers. Arjan's phrase:
"You don't want to round the entire internet" [to the same value].
The solution is a new routine in glib: timeout_add_seconds.
It takes a hash of the hostname (and maybe other values) and uses that
to decide where to round timeouts for the current machine.
If you write programs that wake up on a regular basis, check it out.
In the kernel, round_jiffies does something similar.
After all the theory, we were treated to a demo of powertop in action.
Not surprisingly, it looks a bit like top. High on the screen
is summary information telling you how much time your CPU is spending
in the various sleep states. Getting into the deeper sleep states is
generally best, but it's not quite that simple: if you're only getting
there for short periods, it takes longer and uses more power to get
back to a running state than it would from higher sleep states.
Below that is the list of culprits: who is waking your CPU up most
often? This updates every few seconds, much like the
program. Some of it's clear (names of programs or library routines);
other lines are more obscure if you're not a kernel hacker, but
I'm sure they can all be tracked down.
At the bottom of the screen is a geat feature: a short hint telling
you how you could eliminate the current top offender (e.g. kill the
process that's polling). Not only that, but in many cases powertop
will do it for you at the touch of a key. Very nice! You can try
disabling things and see right away whether it helped.
Arjan stepped through killing several processes and showing the
power saving benefits of each one. (I couldn't help but notice, when
he was done, that the remaining top offender, right above nautilus,
was gnome-power-manager. Oh, the irony!)
It's all very nifty and I'm looking forward to trying it myself.
Unfortunately, I can't do that on the
laptop where I really care about battery life. Powertop requires a
kernel API that went in with the "tickless" option, meaning it's
in 2.6.22 (and I believe it's available as a patch for 2.6.21).
My laptop is stuck back on 2.6.18 because of an IRQ handling bug (bug 7264).
Powertop also requires ACPI, which I have to disable
because of an infinite loop in kacpid (bug 8274,
75174). It's frustrating to have great performance tools like
powertop available, yet not be able to use them because of kernel
regressions. But at least I can experiment with it on my desktop
[ 14:06 Aug 12, 2007
More linux |
permalink to this entry |
Sat, 11 Aug 2007
Last week was the annual trek to Linuxworld.
There wasn't much of interest on the exhibit floor. Lots of
small companies doing virtualization or sysadmin tools.
The usual assortment of publishers. A few big companies,
but fewer than in past years. Not much swag. Dave commented
that there was a much higher "bunny quotient" this year than
last (lots of perky booth bunnies, very few knowledgeable people
working the floor). The ratio of Linux to Windows in the big-company
booths was much lower than last year, especially at AMD and HP,
who both had far more Windows machines visible than Linux ones.
The most interesting new hardware was the Palm Foleo. It looks
like a very thin 10-inch screen laptop, much like my own Vaio only
much thinner and lighter, with a full QWERTY keyboard with a good
feel to it. The booth staff weren't very technical, but apparently
it sports a 300MHz Intel processor, built-in wi-fi and bluetooth,
a resolution a hair under 1024x768 (I didn't write down the
exact numbers and their literature doesn't say), a claimed battery
life of 5 hours, and runs a Linux from Wind River.
The booth rep I talked to said
it would run regular Linux apps once they were recompiled for
the processor, but he didn't seem very technical and I doubt it
runs X, so I'm not sure I believe that. For a claimed price of
around $400 it looks potentially quite interesting.
Their glossy handout says it has VGA out and can display PowerPoint
presentations, which was interesting since the only powerpoint
reader I know of on Linux is OpenOffice and I don't see that
running on 300MHz (considering how slow it is on my P3 700).
Apparently they're using Documents To Go from DataVis, a PalmOS app.
Aside from that there wasn't much of interest going on.
They split up the "Dot Org Pavilion" this year so not all the
community groups were in the same place, which was a bummer --
usually that's where all the interesting booths are (local LUGs,
FSF, EFF, Debian, Ubuntu and groups like that: no Mozilla booth
this time around). But this year
the dotorgs were too spread out to offer a good hangout spot.
It didn't look like there was much of interest at the conference
either: this year they gave us Exhibit Hall pass attendees a free
ticket to attend one of the paid talks, and I couldn't find one
on the day we attended that looked interesting enough to bother.
However, that changed at the end of the day with the BOF sessions.
The Intel Powertop BOF was an easy choice -- I've been curious about
Powertop ever since it was announced, and was eager to hear more about
it from one of the developers. The BOF didn't disappoint, though the
room did: they didn't even provide a projector (!), so we all had
to cluster around the presenter's laptop when he wanted to show
something. Too bad! but it didn't keep the BOF from being full of
I'll split that off into a separate article.
[ 12:34 Aug 11, 2007
More conferences |
permalink to this entry |
Mon, 06 Aug 2007
All the news media carried stories on how our (US) legislators
voted in a bill on Friday night that greatly eased the rules on
wiretapping. The House followed through and passed the bill on
The new updates to FISA, the Foreign Intelligence Surveillance Act,
will allow the NSA or the attorney general to authorize
monitoring of telephones or email, without a warrant, if the
comunications involve people
"reasonably believed to be outside the United States".
The story reported in most of the papers is that Democrats were against
the bill and wanted a version which required warrants in more cases.
But the President threatened
to hold Congress in session into its scheduled summer recess if it did
not approve the changes he wanted -- and that was enough,
apparently, for the Senate to vote for warrantless surveillance of
Americans. (I confess I don't quite understand why the president can
hold Congress in session indefinitely until he gets the vote he wants.
Can't they just vote No?)
What I couldn't find in any of the stories was a breakdown of the
votes. What about our presidential candidates? Did they support
warrantless wiretapping -- or, perhaps worse, just not care about
the ramifications of a bill if further consideration of it might cut
into their vacation time?
Finding Senate votes is very easy. Googling for senate votes
takes you right to the Senate.gov
of recent votes by Senator name or by state.
Here are the
The House is harder. They
don't seem to have a nice "recent votes" page like the Senate does,
or any obvious way to find bills (I had little luck with their site
search), though a pressec.com
story gave a link to the bill on Thomas.loc.gov,
which links to an official House.gov vote count.
In the absence of pressec.com's help, the easiest way to find House
voting records is to use the
How did they vote?
I was happy to see that all the major Democratic candidates in
Congress voted against the smarmily named "Protect America Act",
including Hillary Clinton, Barack Obama, Joe Biden, and Christopher Dodd,
and (in the House) Dennis Kucinich.
John Kerry (who is not an official candidate) didn't vote.
On the Republican side, candidate Sam Brownback voted for the bill,
while candidates John McCain, Tom Tancredo and Ron Paul didn't vote.
Of course, I was also interested in my local legislators.
California Senator Dianne Feinstein voted for passage
(why do people keep voting her back in?)
while our other senator, Barbara Boxer didn't vote.
In the House, my representative, the always sensible Zoe Lofgren,
voted against the bill. In fact, she spoke
out against it, saying "This bill would grant the attorney
general the ability to wiretap anybody, any place, any time without
court review, without any checks and balances.
I think this unwarranted, unprecedented measure would simply
eviscerate the 4th Amendment." Hurray, Zoe!
House Speaker Nancy Pelosi also voted against.
How did your legislators vote?
[ 14:20 Aug 06, 2007
More politics |
permalink to this entry |