Archive for the 'Tech' Category

Kodak scanner drivers for Linux – not there yet

Published on March 13, 2009 in Tech. Closed

So, Kodak announced the availability of Linux drivers for some of its scanners, together with a frontend application.

While the effort is laudable, they’re not quite there yet. Let’s have a look.

First of all, and contrary to what a few people believe after reading the press release, the drivers themselves aren’t OpenSource, let alone Free Software. They’re all proprietary; read better, the press release clearly mentions that only the frontend application is GPLv2.

Now let’s look at what Kodak offers in its drivers packages. I’ve downloaded LinuxSoftware_i1200_v3.5.tar.gz from the Kodak website, these are the drivers for the Kodak i1200 series.

The archive contains a set of RPM packages, one Debian package corresponding to one of the RPM packages, and a setup script.

One of the packages contains the OpenUSB library, which is released under the LGPL; sources aren’t there, I haven’t asked for the sources, don’t plan on doing so, and am not implying anything regarding license compliance whatsoever. I’ll note that I haven’t seen any written offer for the sources, though, be it in the archive (there’s not even a README in there) or on the website.

So, although Ubuntu is listed as supported, we can say that no Debian packages are provided.

The setup script actually relies on alien to convert them if it thinks it’s running on a Debian-based system, which is determined by the availability of dpkg in the PATH. Using alien is far from ideal.

The packages ship libraries and components under /usr/lib, /usr/local/lib and even /opt, pretty randomly it seems. Let’s repeat here that /usr/local and /opt are strictly reserved for the local administrator and packages must not install anything here. There are other oddities in the paths used by the software stack, like /var/kodak.

It looks like the SANE backend is only a bridge to Kodak’s TWAIN data source, so you’d actually need the whole stack to use it.

All in all, Kodak does no better, I’d even venture to say it does worse, than Epson (Avasys). At least part of Epson’s backend is Free Software, even if it relies on proprietary libraries for some scanners, though unfortunately most if not all of the recent ones.

I also have to mention that Epson is offering both RPM and Debian packages, and by that I mean proper Debian packages. Kodak are far from that, even the RPM aren’t that great (I think the RPM packages even lack dependency information, based on what I’ve read in the setup script, though I haven’t checked).

What Kodak offers here is a GPL frontend for TWAIN that not many people will be using, while keeping the drivers proprietary. Unfortunately their SANE backend isn’t a backend so to speak, and even if it was OpenSource it’d still rely on the rest of the TWAIN software stack.

So, in a nutshell, while I’m very happy to see yet another vendor go down the road of Linux support for its products, I am immensely disappointed by the proprietary nature of the drivers and the low quality of the packages.

I was, of course, investigating the drivers to possibly package them for Debian; as you’ve probably understood, it’s not possible, both technically and legally.

And I kept a little gem from the setup script for the end:

# We need to create a link for the libdbus-1 requirement for openusb,
# but only on Fedora.
if [ -f /etc/fedora-release ]; then
    ln -s /lib/libdbus-1.so.3 /lib/libdbus-1.so.2 2>> /dev/null
fi

As we all know, sonames and soversions are useless and they just keep getting in the way. Duh.

Wow.

Published on April 30, 2008 in Tech. Closed

Put down the crack pipe. Really. Wow.

MacBook Pro power savings

Published on August 3, 2007 in Tech. Closed

Matthew: Thanks for the followup and the summary of the MacBook status wrt power consumption.

I’m running a 2.6.22 kernel with the hrt patchset and a set of patches including your patch to appletouch. Your patch works great and the trackpad’s behaviour is a bit better with it.

I know pretty well what the problems are on my machine, but your summary will probably be useful to a lot of people. I know some of the issues can be fixed or worked around and others cannot.

Also note that I can get something like 3h45 out of my battery under OS X with my standard workload, which is pretty good. If OS X can do that, there’s no reason Linux can’t, however bad Apple’s choices are wrt hardware.

And to make it clear once again, my previous post didn’t criticize the C-states or anything else, but the fact that I see PowerTOP being used more as a blame shifting tool than as a debugging/profiling tool. Though I maintain that UHCI suffers from a bad design, OHCI is a much, much better spec.

PowerTOP: demystifying Intel’s latest marketing coup

Published on August 3, 2007 in Tech. Closed

A couple of weeks ago, Intel has released the PowerTOP utility for Linux, a tool similar to the well known top(1) utility that can help you understand why your laptop battery runtime is as low as 1 hour. You need a tickless kernel (2.6.21 at least on i386, 2.6.22 + hrt patchset on amd64) for that to work, and timer statistics must be enabled.

This is an extremely bright marketing coup from Intel, for essentially two reasons:

  • with PowerTOP, they’re now telling “hey look, the CPU is in C3 xx,x% of the time, it’s saving power!!!” and have some real hard data to back that up;
  • with PowerTOP, they can also tell “hey look, the CPU cannot reach the C3 state for long enough periods because foobar is waking it up too often! That’s not the CPU’s fault!”, again with some real hard data to back that up.

In that, PowerTOP is an incredible PR spinning tool that can shift the blame away from the Intel CPU in your machine to about everything else in your machine – including software!

They’ve done extensive and intensive internal testing, which turned up some bugs and misbehaviours here and there, which is truly great.

They’re also announcing incredibly low “CPU wakeups per second” values, so low that there is no way you can reach such low values on any kind of real world setup. These numbers must be seen in the context of lab testing on otherwise idle machines.

On the “CPU wakeups per second” front, you’ll most probably see that the #1 offender is your UHCI USB controller. A UHCI USB controller produces a thousand interrupts per second, effectively waking up the CPU a thousand times per second even when nothing happens.

So, now it’s all the USB controller’s fault! Ah, wait, UHCI is an Intel spec! (UHCI is a joint effort by Intel and others, Intel being the lead) Fortunately, to be able to put the USB host controller to sleep, you need to put all the USB devices attached to it to sleep too. Here comes the (in)famous CONFIG_USB_SUSPEND kernel option introduced six or so months ago, the one that makes (made, I’ve worked around it in SANE last week-end) your scanner produce only “black scans” and prevents your printer from working properly. So now it’s all the USB devices’ fault.

Brilliant, isn’t it ?

To be honest and complete, once again, CONFIG_USB_SUSPEND exposed a lot of hardware bugs. The USB spec is probably one of the most violated spec these days (together with ACPI I’d say, though it looks like this one is improving lately).

Please don’t get me wrong: PowerTOP is a very useful tool that has its uses, the tickless kernel is of course a very important feature, and CONFIG_USB_SUSPEND would be the icing on the cake if USB devices weren’t so ignorant of the spec.

But the Intel marketing crap behind that really needs to stop. Produce better chips which consume less power, period. My PowerBook G4 could run 4h30 on battery (a machine designed 7 years ago). My Core2 Duo MacBook Pro, with a slightly bigger battery, can only run 1h40 with the same software and workload, with cpufreq enabled etc, etc. Granted, the ATI video card is a big sucker here too.

(I wrote this entry to share my thoughts on the matter, as a reaction to the many mails I’m getting about PowerTOP and the MacBooks, so as to have a reference to point people to, instead of rewriting the same things again and again.)

WTF Award of the week

Published on May 24, 2007 in Tech. Closed

Quoting from the Release Notes for the firmware v1.54.2 for the Thomson ST2030 VoIP telephone, in the “Relevant known limitations” section:

3.1 The display doesn’t show the name of the incoming call when received display name starts with the letter “O” (uppercase).

This raised quite a few eyebrows here, and raised quite a few concerns too. I refuse to even imagine how this kind of bug can happen.

And for those who will have a hard time believing this, we did the test, and, indeed, the CallerID name doesn’t appear on the phone when it starts with an “O”. Shrug.

Once again, XFS saves the day

Published on January 20, 2007 in Tech. Closed

The server hosting this blog just suffered what can only be described as catastrophic hardware failure, thanks to the crap that are Maxtor hard drives, Dell CERC 1.5 RAID controllers and the Linux driver for those (aacraid).

So, the machine got shut down for a moment on thursday night, just the time to move the rack around in the datacenter, and one of the disks did not come back in one piece.

But it did come back online after a reboot, prompting an array rebuild by the controller which took 12.5 hours for 250 GB (RAID 1). And the drive failed again 10 minutes after the rebuild was completed, confusing both the controller and the driver. At that point I could still log into the machine, but any command would trigger nice I/O errors all over the place.

Fortunately, the FS got shut down by XFS automatically on I/O errors and I haven’t lost a single bit of data. The machine came back just fine with the faulty drive removed.

And you thought a RAID controller would help in this case. Obviously this one doesn’t. I need to mention that we’ve observed this behaviour on another machine before this incident, we have another machine suffering from a faulty drive in just the same way, so this isn’t an isolated case and it’s reproducible.

Data recovery, or why I love XFS

Published on May 14, 2006 in Tech. Closed

So, here it is, the hard drive in my mother’s laptop (HP nx9105, 10 months old) just broke down this week, with some important data on it (I do have backups, but it broke down in between 2 backups with some important changes to the data – accounting and payroll).

The laptop was running an AMD64 Sarge on an XFS filesystem. Fortunately, XFS shuts the filesystem down when the underlying block device fails, so the damages are quite limited. dd_rescue to the rescue, only 40 kB of the 40 GB partition couldn’t be recovered. An xfs_repair run later, the FS mounts with only 30 files in lost+found: 10 of them are device nodes, 10 are empty files, another 5 are sockets and the remaining 5 are mails from anacron.

I just love this filesystem. SGI, you guys rock. All of this just went as planned when I installed the machine in July last year; I chose XFS for its ability to not screw up the FS when the underlying block device crashes and for the powerful and reliable set of maintenance tools that goes with it.

Enemies Of Carlotta with Postfix 2.0 and virtual domains

Published on July 18, 2005 in Hacks and Tech. Closed

Well, first off, thanks Lars Wirzenius (liw) for this really fine piece of software, it saved me from the mailman hell I was going to enter.

That being said, here’s the setup, with Postfix 2.0 and virtual domains on a Sarge system; the manpage of eoc is slightly outdated wrt to Postfix it seems, so I hope this will be helpful (with apologies to Planet readers for the length of this entry):

  • Create an eoc or whatever user, who will receive the mails and hold the eoc configuration. I created a system user, with a disabled password and /bin/bash as its shell, member of the list group.
  • su - eoc and create your mailing list, with something like

    enemies-of-carlotta --name=testlist@lists.example.com --owner=foo@example.com --create

    Now, add yourself to the testlist:

    enemies-of-carlotta --name=testlist@lists.example.com --subscribe your@email.address

    As eoc places its configuration data in ~/.enemies-of-carlotta, it’s important to run the enemies-of-carlotta command as the eoc user.
  • Edit /etc/postfix/main.cf, and add the file /etc/postfix/virtual_eoc_aliases to the virtual_alias_map configuration item, e.g.

    ...
    virtual_alias_maps = hash:/etc/postfix/virtual_aliases, pcre:/etc/postfix/virtual_eoc_aliases
    ...

    Now, create /etc/postfix/virtual_eoc_aliases:

    #
    # virtual aliases for EOC (mailing-lists)
    #
     
    /^(testlist|testlist-.*)@(lists.example.com)$/ eoc+lists.example.com_$1

    This way, a mail addressed to (testlist|testlist-.*)@lists.example.com will be redirected to eoc+lists.example.com_<whatgotmatched>.

    You’ll need the postfix-pcre package for this to work, and the recipient delimiter must be set to + (recipient_delimiter = + in /etc/postfix/main.cf). Restart postfix.

  • Send a mail to your test list, it should end up in the mailbox of your eoc user. If it doesn’t, check the postfix logs and fix the problem ;-)
  • Create the .forward file in the user’s homedir, here’s its content

    "| procmail -p"
  • Now, create the .procmailrc file for the eoc user. This is what I came up with:

    PATH=$HOME/bin:/bin:/usr/bin
    LOGFILE=$HOME/eoc-log
    ARCHIVES=$HOME/archives
    THISMONTH=`date "+%Y%m"`
     
    # determine the full list name (list@domain)
    :0
    EOCLIST=| eoc-extract-list $EXTENSION
     
    # set recipient to the full list name, ie list@domain
    RECIPIENT=$EOCLIST
     
    # feed the mail to EOC
    :0
    * ? enemies-of-carlotta --name=$EOCLIST --is-list
    {
    # send the mail to the list
    :0 c
    | enemies-of-carlotta --quiet --incoming
     
    # archive it
    UMASK=033
    :0
    $ARCHIVES/$EOCLIST/${THISMONTH}.mbox
    }
     
    # trap other mails ...
    :0
    trapped-mails

    The eoc-extract-list does nothing more than that, at the moment:

    echo $1 | sed -e 's/\([^_]*\)[_]\(.*\)/\2@\1/'

    The trapped-mails mbox file will need to be emptied periodically; actually, I redirect those mails to another address, feel free to pass them on to Dave Null.
    As you can see, the mails get archived in an mbox by the procmail rule. I use mhonarc to generate a web archive from this mbox.

OK, here you are, your test mailing-list should now be functional. Send a mail, and see what happens.

To add a list, all you have to do is:

  • Add the regexp into /etc/postfix/virtual_eoc_aliases
  • Create the list in eoc

The procmailrc doesn’t need to be modified afterwards. It can probably be improved still, but I’m happy with it as it is now.

Now, if someone knows of a mailing-list archiver that doesn’t suck, I’d be glad to give it a try.

European Parliament rejects Software Patents

Published on July 6, 2005 in Life and Tech. Closed

So, here we are, the European Parliament finally rejected the Software Patents. At last.

With 648 votes against the proposal out of 680 total votes, it’s quite a strong signal towards the European Commission. Hope they’ll learn something from that event.

Thanks to all the folks who worked for that day to happen, especially the FFII and Michel Rocard.

Now, let’s get back to Free Software. We’ve got a C++ transition to do.

Upgrading to Sarge, at last

Published on June 26, 2005 in Debian and Tech. Closed

I upgraded my gateway from Woody to Sarge right after the release, and all went fine on the Debian side. Switching to the 2.6 kernel, while I was at it, has been a bit painful as Linux 2.6 decided it wouldn’t order its network interfaces the same way Linux 2.4 did. I admit that I forgot about that before doing the upgrade.

This week-end, I finally found the time to upgrade my server, and this was a much feared upgrade, as I expected it would take me a whole day to be done with it. It all went rather fine, and I did the whole upgrade in half a day only.

The problems I anticipated were:

  • Switching from Netsaint to Nagios: went fine, as I prepared the Nagios config on a test machine before the upgrade.
  • INN: it just can’t survive an upgrade. Only a couple of minor fixes to inn.conf were needed to get it back up and running — good surprise.
  • NUT: new major version, although I was running a backported version of NUT and no configuration changes were required. But nut-cgi failed to upgrade properly, I had to purge and reinstall it.
  • Postfix/Courier-imap: this is my MX, so, if something goes wrong here, my mail doesn’t arrive anymore. And I absolutely HATE losing mail.

Once everything was back up and running, I switched from Apache to Apache2, then switched to Linux 2.6. The server is much faster now (even with Linux 2.4); especially, deleting mail from my IMAP folders now takes less than a second, where it could take as much as 20 seconds before. Happy I am.

In the end, Debian is still Debian, the upgrades are still painless compared to other distributions, and I love that. Now, if only services could get restarted faster during the upgrade, I’d be even more happy. For now, it’ll do ;-)