Free as in speech

There have been a number of discussions on sane-devel in the past months revolving around the SANE2 standard (still in development) and/or extensions to the current SANE1 standard. SANE2 is an effort that has been “ongoing” (on and off, mostly off, unfortunately) for a number of years already.

This led to a number of questions being raised, most notably this one: do we need SANE2, or can we get away only with extensions to SANE1? Or should we just redesign the whole stack from the ground up?
This matter is undecided as of yet, but extensions to SANE1 are planned, being discussed or in the making for some of them.

During the discussions, a fork of SANE has been announced, dubbed “SANE Evolution”. No idea where that is going, but it’ll probably end up being merged back into SANE in the end.

So, in a nutshell, things are moving again (albeit slowly), which is good news considering the project was mostly asleep in recent times.

To celebrate that (and because I now have total control over my free time again), I’ve been working on the network side of SANE again. In 2 weeks (3 week-ends, roughly):

• saned has been turned into a regular, full-fledged daemon
• mDNS/DNS-SD service announcement & discovery has been added to saned and the net backend (using Avahi)
• I have 20% of a WireShark dissector for the SANE protocol written, and already spotted (and plugged) an information leak bug in the net backend thanks to it

Turning saned into a regular daemon made it possible to clean up a good chunk of the code duplication that was introduced by my previous AF-indep/IPv6 work; the startup code is readable again.

The Avahi support is (I hope) a very nice thing as, when enabled, configuration of the net backend on the client side is no longer needed. This is an experimental feature still and as such it’s disabled by default at build time. I have a couple of ideas to improve that feature, but this means saned will have to evolve even more so it’ll take some time.

The WireShark dissector is a tool for working on enhancing the network protocol. It proved useful already with the information leak I spotted with it (though it’s minor). It’ll be a long work to extend the network protocol and implement that into saned and the net backend in a backward-compatible manner.

In June last year, I bought a TomTom GPS device. Their use of Linux on the device was a clear plus in their favour, but it was only that, given that overall they’re the best devices available.

Unfortunately, the TomTom HOME software that is needed to manage the device is not as good as the device itself.

An account on their website is needed for updates and the online shop, and as I usually do, I used an email address in the form jb+something@jblache.org. That’s a trick most of us use to trace back the origin of spam, usually revealing that some company sold its customer database. I’ve been doing that for years.

I was quite happy that the website did not reject the address as being invalid; that’s something that happens everytime the random web developer maintaining the site decides to start “validating” email addresses, for some value of email addresses.

For the following 8 months I’ve been using this address as the account login (don’t really have the choice, anyway) with the TomTom HOME software. Last month, the v2 of the said software was finally made available for Mac OS X.

Where the v1 used to accept my email address, the v2 would now reject it. You guessed it, Joe Random developer decided to start validating email addresses in TomTom HOME.

I reported the regression (and here, something must be said about their infamous support website), with pointers to the relevant RFCs. In the following email ping-pong, they managed to:

• Pretend the password was the problem. I have to say here that the software displays a big red “invalid email address” next to the email address field as soon as I enter the + character. No mistake possible here.
• Send me my login and password, in clear text, when I never asked for that. That also means they’re storing passwords in clear text. IT’S 2008 FOR FUCK’S SAKE! STOP STORING CLEAR TEXT PASSWORDS, DAMMIT.
• Pretend their email platform is the most secure in the world. Ever heard of SSL? TLS? Clearly not.
• Pretend it’s not a regression in the v2 of TomTom HOME. We’re not speaking the same language, it seems.
• Pretend the email address is invalid. No surprise there, but it’s clear they did not bother reading the fucking RFC.

Last but not least, their last reply was: “we found that the standard does not apply to us. Please change your email address for a valid one.”

Now, I’m left wondering: does the GPS standard apply to TomTom devices? I truly hope so.

I’ve finally got enough information to complete the MacBookAir1,1 support, it’s been tested and it works.

I’ve also got the information I needed for the new MacBook Pro and MacBook released in February 2008, but there I’ll need some feedback. I have some doubts on which machine uses which keyboard+trackpad assembly.

• The MacBook Air uses an entirely new device, the so-called “MultiTouch” trackpad, dubbed “WellSpring”
• The MacBook Pro has got a “MultiTouch” trackpad in its latest revision, so it’s using a WellSpring device too, and I think it’s using the WellSpring II device
• The MacBook hasn’t got the “MultiTouch” trackpad, I think it still uses a Geyser IV-HF device

I’ll need to confirm those two last points, so if you are running pommed on either one of these machines, your feedback is welcome.

On a slightly related note, I have some sound troubles on my MacBookPro2,2 with 2.6.24.3 which I didn’t have with 2.6.24.2. I cannot play WAV files anymore, be it with pommed, with aplay or with any other software. In the best case, the sound is distorted and too fast, in the worst case I can’t hear anything at all. And they call it the stable tree, hmgrmpf.

I’ve released pommed v1.15 this week-end with support for the new power_supply class which is used to report ACPI power information starting with kernel 2.6.24.

This release also contains pretty much everything needed for the MacBook Air1,1, except the keyboard/trackpad USB IDs which I couldn’t grab yet. So expect v1.16 for the MacBook Air as soon as I’ll have those IDs.

http://lists.debian.org/debian-devel-announce/2008/01/msg00006.html

I fear it’s a little bit too late to introduce a release goal such as this one, which will probably have quite a few (tricky) side effects.

I think it’s time to stop piling release goals, or we’re never going to release.

Jan 26 11:26:35 arrakis sshd[2515]: pam_unix(ssh:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=my-debian.org
Jan 26 11:26:38 arrakis sshd[2515]: Failed password for invalid user myra from 88.151.100.103 port 53744 ssh2

Note the rhost in the first line: my-debian.org. And, indeed:

% host my-debian.org
my-debian.org has address 88.151.100.103

Whois tells me:

Registrant ID:DI_6983786
Registrant Name:Czibulya Gergely

LART, anyone ?

Spamming every @*.debian.org email address you can find to advertise your new website related to free software is not a good idea. At all.

If you know this person IRL, please make heavy use of the cluebat on him.

kthxbye.

A bugfix release for pommed, fixing a crash when the default beep file is not available. One part of the audio code we’ve reused had a broken error handling, and you know how that kind of things tend to end (badly).

Also, the default beep sound was pretty horrible according to the feedback I’ve got so far, so the default beep sound has changed and another sound is shipped if you don’t like the default (the clicking sound that was in gpomme).

Pommed v1.13 is out and features a couple of new features and a bugfix for a potentially annoying bug.

This release adds support for the MacBook3,1 LCD backlight; turns out the 965GM works pretty much the same way the previous versions did.

Following my previous post on the subject, I’ve added the ability to run a script when the video switch button is pressed. The script is run by the frontend, so you need to have either gpomme or wmpomme running; see the documentation in the INSTALL file for details. Feedback on this feature and sample scripts for the different machines are welcome.

In v1.11, I moved the beep code from gpomme to pommed, making pommed beep on volume change. Not everybody likes this, so you can now turn that off in the config file (beep = no in the audio section).

And, last, the bugfix. Pommed could turn into a CPU hog under certain circumstances; this releases fixes that, and though most systems won’t trigger this bug, you should upgrade if you’re running 1.11 or 1.12.

The radeonhd xorg driver recently gained full RandR 1.2 support, I’ve tested it out moments ago and it works. It just works. (DIE fglrx, DIE DIE DIE).

Joy and happiness today, and thanks to Julien CRISTAU, it’s even packaged in experimental (I owe you a beer, obviously).

Now, given that we now have a working video driver, and an opensource one even, let’s think about implementing something in pommed for that nice little video switch button that’s on F7.

I don’t really know how to go about implementing the video switch feature. Either I’m doing it in pommed in the form of a shell script that will have to “steal” the user’s X session, or I’m doing it in the frontends, which will obviously be a bit easier.

Which raises another question: shell script around xrandr, or RandR support in the frontends?

That latter option doesn’t look terribly appealing to me, as it involves quite some code that will have to be maintained up-to-date wrt RandR evolutions, and that also means being backward-compatible with older RandR versions etc.

So it’s probably going to be only a simple shell script, executed by the frontend.

I’d like more input on this, so if you have a take on how it should/could be done, please drop me a mail. Otherwise you’ll have to live with whatever I’ll come up with ;-)