I’ve just released a maintenance release of pommed. Nothing new under the sun in this one:
There are a couple of ideas floating around, we’ll see if any one of those lands into a future release.
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.
I’ve been doing some code lately, fixing things here and there, and over the last few days gave mt-daapd some attention.
First, I was reported a segfault of mt-daapd when reloading web pages too fast. Surprisingly, it turned out to be a stupid omission in a simple routine and it is hard to hit without disabling the cache in the browser.
Now, I just fixed something that’s been bugging me for a while: mt-daapd did not handle Avahi daemon restarts, leading to mt-daapd becoming invisible to clients relying on mDNS until you restarted it.
And, wow, that went a bit further than expected. As I expected, the simple piece of code needed to handle that wasn’t there. But still it did not work, as it turns out the event loop for the Avahi polling wasn’t being run. Replace stupid code reinventing the wheel by the Avahi-provided wheel and there, it works. But not when run as a daemon (aka foreground only). Well yes, starting the thread before daemonizing isn’t going to work well, so fix that. EPIC WIN \o/
As mt-daapd’s upstream is not active anymore I’m accumulating fixes for mt-daapd in the Debian package, to the point I’m starting to consider setting up a git repository somewhere with those fixes and possibly some more code rework if I feel like it.
I’ve migrated pommed to git yesterday. The public URLs for the git repository are:
git://git.debian.org/git/pommed/pommed.git
http://git.debian.org/git/pommed/pommed.git
The SVN repository will disappear shortly.
How not to start your day, from the all-hardware-sucks department.
For years, I’ve been struggling to keep my machines quiet. I’ve miserably failed for years, and pretty much gave up once I realised that the quiet parts I was looking for just did not exist. Last year, I finally found what I was looking for:
I’ve been very happy with this hardware for both my workstation and my filer. Well, until today. No need to mention that this hardware is not exactly cheap, but the price is right for the quality.
So, wake up today, do random things, grab my TomTom, unplug it from the workstation it’s sucking its power from, do things, plug it back in the USB port so it won’t draw its battery. This is how it went:
Check machine temp, PSU temp, attempt to restart PSU, check UPS, check cables, replace power cable and bypass UPS. Admit defeat for this round and accept the PSU as dead. Pull out the machine, rip out the fscking damn PSU.
Grab the tools, crack the PSU open. Notice bulging and leaking capacitors.
Yes, this PSU is anything but cheap, yet it uses el-cheapo chinese capacitors. Antec, you suck, big time. For the past decade everybody in the industry has known that el-cheapo chinese capacitors manufactured after 1999 are total crap, using an electrolyte that isn’t actually one because its formula was stolen by industrial spies who got totally PWNED and ended up stealing a bad formula.
(If you need a reference, google for “singing capacitors”. Note that singing capacitors can also happen with good parts used in a crappy electronic design. Like that 100 Mbps D-Link switch over there, or that Sony-Ericsson mobile phone charger. Hmm. Not everybody can hear it, I do.)
A healthy, young capacitor should not bulge nor leak. A capacitor that leaks, bulges or sings is a crappy capacitor and needs to be replaced with a quality part ASAP. I’ve been routinely replacing such capacitors on my older motherboards (manufactured between 1999 and 2001) in the past years. I’ve not had the problem in ANY of my el-cheapo PSU, and did not replace any capacitor in any of them to date.
Fortunately, the machine did not suffer any further damage, nor did the TomTom. Everything is up and running again with a spare PSU. I’m now going to replace the fscking capacitors on this PSU, replace the fuse, probably R&R a couple of high-voltage transistors too (they have a tendency to fry before the fuse blows out) and get it back up and running.
Then I’ll do the same with the other PSU in the filer, because that machine has 8 disks attached, so draws more power and hence is much more vulnerable. Fuck you Antec.
Two fixes in this release, let’s start with the more important one :)
The DBus configuration file shipped with pommed now explicitly allows method calls to org.pommed, which is needed with the newer versions of DBus where the default configuration on the system bus has been made more strict to close a security hole. If the pommed clients stopped working for you after a DBus update, replace /etc/dbus-1/system.d/pommed.conf by the dbus-policy.conf file shipped with pommed.
Second fix is related to the Apple wireless (Bluetooth) keyboard, which previous versions of pommed would recognize just fine but reject because it exposes a type of events usually indicative of a mouse (and pommed doesn’t listen to mouse devices). This is now fixed for this particular keyboard, so pommed will react to the hotkeys on this keyboard too.
For the complete list of changes, see the ChangeLog file in the source distribution. Comments at the usual address :)
pommed 1.24 is out; this is a maintenance release addressing the HID changes in the 2.6.28 kernel.
HID quirks have been split out into hardware/vendor-specific submodules; consequently the sysfs path for the fnmode parameter changed as it’s now handled by the hid_apple module and that needed to be accounted for.
No rush if you’re running an older kernel :)
I’m not saying it lightly: the end goal is censorship, no matter how nicely you try to put it.
The goal is to discourage people from posting. They call it “peer pressure”, which is nothing else but the politically correct equivalent expression for “intimidation”. The end result is censorship.
The idea of censoring the mailing lists has actually been mentioned very clearly in the recent discussions on -devel, and I never thought it would go past that, but it’s actually happening. By the way, this could actually morph into a shitty karma system that wouldn’t let you post past your monthly allowance and “credit” “earned”. How’s that for you?
You refer to those +1/-1 mails; I find them silly, annoying, useless and a waste of bandwidth and CPU time. That used to be called a “me too” and generally despised and frowned upon.
If you actually want to score posts or posters, get a decent MUA and set up its scoring system the way you like. But keep that to yourself.
As Aigars told, there are mail to web forum “gateways” (more like rendering engines for a mail archive, actually) that will present mails to a list in a crappy web forum of some sort that will come with all kind of crap like scoring, karma and whatever.
There’s an essential difference between web forums and our mailing lists, though: forums of this kind use nicknames all over the place, our mailing lists use real names. There are privacy issues involved, and I’m not giving up on that, either.
You want to stop flamewars? Stop replying, especially to tell how intolerable it is and other shit. Just let the damn thing die already. Funny how the well-meaning people are feeling “harassed” on the mailing lists when they, themselves, are harassing people they disagree with.
We don’t all have the same views, culture etc. We’re not all friends, and we probably never will be. Guess what? It’s OK! Get over it and work with each other, because that is what we are here for. If you (general) can’t get over it, I’m afraid this Project is not the appropriate place for you.
Imposing a monoculture of politically correct crap is not an answer to the perceived “problems”.
This proposal leaves me speechless. The replies even more. The sole fact that there are positive replies kills me.
I’m really starting to think that this Project could do a lot better without some people. Now if you’ll excuse me for a sec, I have a urgent need to vomit.
Reality check, people. Get back on the ground.
Christian notes, and rightly so, how much this vote sucks, for various reasons.
There are too many viable options (as far as releasing Lenny is concerned) and that makes it tricky to vote in a useful way. And Christian got bitten by it: do not vote by ranking all options 1 to 7, or this vote will end up being our most EPIC FAIL to date. With that many options, the votes will end up diluted and who knows what the result will be.
For this vote to succeed and be meaningful, it’s pretty much required to rank several options equally. That is, and provided it matches your views, ranking the “Let’s release Lenny and give the finger to the zealots” options at the same level.
Be careful when voting on this one. IT’S A TRAP.