Those files capture the ACPI events and handle them via a custom script in
/etc/acpi/actions/volume.sh, which uses amixer from alsa-utils. Volume
control worked just fine, but muting was a real pain to get working correctly
due to what seems like a bug in amixer - amixer -c1 sset Master playback toggle
doesn't toggle correctly - it mutes fine, but then doesn't unmute all
the channels it mutes!

I worked around it by figuring out the specific channels that sset Master
was muting, and then handling them individually, but it's definitely not as clean:

So in short, really pleased with the X250 so far - the screen is lovely, battery
life seems great, I'm enjoying the keyboard, and most things have Just
Worked or have been pretty easily configurable with CentOS. Happy camper!

Just picked up a shiny new Fujitsu ScanSnap 1300i ADF scanner to get
more serious about less paper.

I chose the 1300i on the basis of the nice small form factor, and that SANE
reports
it having 'good' support with current SANE backends. I'd also been able
to find success stories of other linux users getting the similar S1300
working okay:

I plugged the S1300i in (via the dual USB cables instead of the power
supply - nice!), turned it on (by opening the top cover) and then ran
sudo sane-find-scanner. All good:

found USB scanner (vendor=0x04c5 [FUJITSU], product=0x128d [ScanSnap S1300i]) at libusb:001:013
# Your USB scanner was (probably) detected. It may or may not be supported by
# SANE. Try scanimage -L and read the backend's manpage.

Ran sudo scanimage -L - no scanner found.

I downloaded the S1300 firmware Luuk had provided in his post and
installed it into /usr/share/sane/epjitsu, and then updated
/etc/sane.d/epjitsu.conf to reference it:

And so far gscan2pdf 1.2.5 seems to work pretty nicely. It handles both
simplex and duplex scans, and both the cleanup phase (using unpaper)
and the OCR phase (with either gocr or tesseract) work without
problems. tesseract seems to perform markedly better than gocr so
far, as seems pretty typical.

So thus far I'm a pretty happy purchaser. On to a paperless
searchable future!

Bought a new car stereo a few weeks ago to replace the broken
CD-stacker that came with our Ford Fairmont.

In researching the options it seemed that the mainstream
choices these days were for stereos with auxiliary-in jacks
at the front, so you could plug your music player in, and/or
units that would play mp3s. Turns out that latter option
means they will play mp3s that you've burned onto CDs, not
off something super-high-tech like a memory stick. Hmmm.

Well, that's not quite true. Newer units are starting to
appear with USB slots that will play music off a USB memory
stick, so there are actually starting to be some useful
options available. I didn't see any that took anything like
compact flash or SD cards however.

They also don't seem to know anything much about codecs
except MP3, WMA, WAV, and some AAC. Being the open source
geek that I am, I was keen to get something that supported
ogg vorbis, but I
could not find any information (including with my google-fu)
on models that might support this. I did find one guy, however,
who'd burnt a bunch of tracks in different formats to a CD
and then just gone down and tried out all the units at his
local hi-fi store. That sounded like a plan!

So I ended up testing a bunch of units at my local JB Hi-Fi
and Strathfield stores, and the good news is that about half
of them actually played ogg vorbis just fine. I guess they're
just using stock sound decoder chips, which these support a
whole bunch of codecs out of the box. Sure would be nice if
they could manage to advertise the codecs they actually
support though.

We ended up going with a
Kenwood KDC-MP4036U,
which advertises support for "MP3/WMA/AAC Files", but
plays at least ogg vorbis just fine as well. It's supposedly
AU$429 RRP, but we picked it up for $180 at the big
post-Christmas sale at
Strathfield,
so clearly it pays to shop around.

So far it's working really nicely - I've got most of the
girls' music and stories on a 4GB USB stick and get them to
drive the music selection from the back using the remote
control. Way more music than 6-CDs ever gave us, and
without the hassle of a separate music player or ipod.

One of this afternoon's tasks was this: order some graphics cards
for a batch of workstations. We had a pretty good idea of the kind
of cards we wanted - PCIe Nvidia 8600GT-based cards. The unusual
twist today was this: ideally we wanted ones that would only take
up a single PCIe slot, so we could use them okay even if the
neighbouring slot was filled i.e.

select * from graphics_cards
where chipset_vendor = 'nvidia'
and chipset = '8600GT'
order by width desc;

or something. Note that we don't even really care much about price.
We just need some retailer to expose the data on their cards in a
useful sortable fashion, and they would get our order.

In practice, this is Mission Impossible.

Mostly, merchants will just allow me to drill down to their
graphics cards page and browse the gazillion cards they have
available. If I'm lucky, I'll be able to get a view that only
includes Nvidia PCIe cards. If I'm very lucky, I might even be
able to drill down to only 8000-series cards, or even 8600GTs.

Some merchants also allow ordering on certain columns, which
is actually pretty useful when you're buying on price. But none
seem to expose RAM or clockspeeds in list view, let alone card
dimensions.

And even when I manually drill down to the cards themselves,
very few have much useful information there. I did find two
sites that actually quoted the physical dimensions for some
cards, but the in both cases the numbers they were quoting
seemed bogus.

Okay, so how about we try and figure it out from the
manufacturer's websites?

This turns out to be Mission Impossible II. The manufacturer's
websites are all controlled by their marketing departments and
largely consist of flash demos and brochureware. Even finding
a particular card is an impressive feat, even if you have the
merchant's approximation of its name. And when you do they often
have less information than the retailers'. If there is any
significant data available for a card, it's usually in a pdf
datasheet or a manual, rather than available on a webpage.

Arrrghh!

So here are a few free suggestions for all and sundry, born
out of today's frustration.

For manufacturers:

use part numbers - all products need a unique identifier,
like books have an ISBN. That means I don't have to try and
guess whether your 'SoFast HyperFlapdoodle 8600GT' is the
same things as the random mislabel the merchant put on it.

provide a standard url for getting to a product page given
your part number. I know, that's pretty revolutionary, but
maybe take a few tips from google instead of just listening
to your marketing department e.g.
http://www.supervidio.com.tw/?q=sofast-hf-8600gt-256

keep old product pages around, since people don't just buy
your latest and greatest, and products take a long time to
clear in some parts of the world

include some data on your product pages, rather than
just your brochureware. Put it way down the bottom of the
page so your marketing people don't complain as much. For
bonus points, mark it up with semantic microformat-type
classes to make parsing easier.

alternatively, provide dedicated data product pages, perhaps
in xml, optimised for machine use rather than marketing.
They don't even have to be visible via browse paths, just
available via search urls given product ids.

For merchants:

include manufacturer's part numbers, even if you want to
use your own as the primary key. It's good to let your
customers get additional information from the manufacturer,
of course.

provide links at least to the manufacturer's home page, and
ideally to individual product pages

invest in your web interface, particularly in terms of
filtering results. If you have 5 items that are going to
meet my requirements, I want to be able to filter down to
exactly and only those five, instead of having to hunt for
them among 50. Price is usually an important determiner of
shopping decisions, of course, but if I have two merchants
with similar pricing, one of whom let me find exactly the
target set I was interested in, guess who I'm going to buy
from?

do provide as much data as possible as conveniently as
possible for shopping aggregators, particularly product
information and stock levels. People will build useful
interfaces on top of your data if you let them, and will
send traffic your way for free. Pricing is important, but
it's only one piece of the equation.

simple and useful beats pretty and painful - in particular,
don't use frames, since they break lots of standard web
magic like bookmarking and back buttons; don't do things
like magic javascript links that don't work in standard
browser fashion; and don't open content in new windows for
me - I can do that myself

actively solicit feedback from your customers - very few
people will give you feedback unless you make it very clear
you welcome and appreciate it, and when you get it, take it
seriously

End of rant.

So tell me, are there any clueful manufacturers and merchants
out there? I don't like just hurling brickbats ...

Problem #1: the RedHat anaconda installer kernel doesn't support these cards
yet, so no hard drives were detected.

If you are dealing with a clueful
Linux vendor like 3ware, though, you can just go to their comprehensive
download driver page,
grab the right driver you need for your kernel, drop the files onto a
floppy disk, and boot with a 'dd' (for 'driverdisk') kernel parameter
i.e. type 'linux dd' at your boot prompt.

Problem #2: no floppy disks! So the choices were: actually exit the office
and go and buy a floppy disk, or (since this was a kickstart anyway) figure
out how to build and use a network driver image. Hmmm ...

Turns out the dd kernel parameter supports networked images out of the box.
You just specify dd=http://..., dd=ftp://..., or dd=nfs://..., giving it
the path to your driver image. So the only missing piece was putting the
3ware drivers onto a suitable disk image. I ended up doing the following:

We've been chasing a problem recently with trying to use dual
nvidia 8000-series cards with four displays. 7000-series cards
work just fine (we're mostly using 7900GSs), but with 8000-series
cards (mostly 8600GTs) we're seeing an intermittent problem with
one of the displays (and only one) going badly 'fuzzy'. It's not
a hardware problem because it moves displays and cables and
cards.

Turns out it's an nvidia driver issue, and present on the latest
100.14.11 linux drivers. Lonni from nvidia got back to us saying:

This is a known bug ... it is specific to G8x GPUs ... The
issue is still being investigated, and there is not currently
a resolution timeframe.

So this is a heads-up for anyone trying to run dual 8000-series
cards on linux and seeing this. And props to nvidia for getting
back to us really quickly and acknowledging the problem. Hopefully
there's a fix soonish so we can put these lovely cards to use.

We've been having a bit of trouble with these motherboards under linux
recently. The two S4/S5 variants are basically identical
except that the S5 has two Gbit ethernet ports where the S4 has only one,
and the S5 has a couple of extra SATA connections - we've been using both
variants. We chose these boards primarily because we wanted AM2 boards
with multiple PCIe 16x slots to use with multiple displays.

We're running on the latest BIOS, and have tested various kernels from 2.6.9
up to about 2.6.19 so far - all evidence the same the same problems. Note
that these are much more likely to be BIOS bugs, we think, than kernel
problems.

The problems we're seeing are:

kernel panics on boot due to apic problems - we can workaround by specifying
a 'noapic' kernel parameter at boot time

problems with IRQ 7 - we get the following message in the messages log
soon after boot:

after which IRQ 7 is disabled and whatever device is using IRQ 7 seems to
fail intermittently or just behave strangely (and "irqpoll" would just
cause hangs early in the boot process).

This second problem has been pretty annoying, and hard to diagnose because it
would affect different devices on different machines depending on what bios
settings were on and what slots devices were in. I spent a lot of time chasing
weird nvidia video card hangs which we were blaming on the binary nvidia
kernel module, which turned out to be this interrupt problem.

Similarly, if it was the sound device that happened to get that interrupt,
you'd just get choppy or garbled sound out of your sound device, when other
machines would be working flawlessly.

So after much pain, we've even managed to come up with a workaround: it turns
out that IRQ 7 is the traditional LPT port interrupt - if you ensure the
parallel port is turned on in the bios (we were religiously turning it off as
unused!) it will grab IRQ 7 for itself and all your IRQ problems just go away.