lostwebsite.net blog

So Skype is evil because it’s proprietary?

It’s not hard to find rumors about spyware being deployed with the Skype VOIP software. What is hard to find amongst those rumors are concrete facts. Most of the rumors seems to be unsubstantiated, and some other are based on interpretation on the EULA of Skype. I won’t bother with the later case since legalese is not a language I speak.

This blog is one of the few blog around that take seem to take the matter seriously and brings forward something looking like a real proof that Skype may be stepping over the boundary of user privacy.

For the people who don’t read french, I will summarize the article. The author’s hypothesis is that when a new profile is registered through the Skype desktop client, the software accesses bookmarks stored in the user’s Mozilla Firefox profile. Since it’s not immediately obvious why Skype needs to be doing that, he concludes that the Skype software must be sending that information home for data warehousing, or some other shady practices.

For proof he shows his data that he obtained using the strace command on Linux. strace is a lovely, lovely utility I’ve learned to master in the last few years. It is an utility which shows the system calls that are used by a Linux application. strace is not hard to use but its output can be very voluminous and difficult to decipher. This is not the case here.

…Naaah

The data he obtained looked inoffensive to my eyes just 2 seconds after examining it (I won’t claim I’m the first that saw that: several commenter have pointed it to him).

The blogger singles out several calls to stat64(), which is a system call returns information about a file like its size and last modifications or last access date.

[pid 23964] stat64("/home/phil/.mozilla/firefox/bstiq480.default/bookmarkbackups/bookmarks-2008-12-17.json", {st_mode=S_IFREG|0600, st_size=41718, ...}) = 0
[pid 23964] stat64("/home/phil/.mozilla/firefox/bstiq480.default/bookmarkbackups/bookmarks-2008-12-20.json", {st_mode=S_IFREG|0600, st_size=42052, ...}) = 0

An higher level view of the data shows that Skype actually calls stat64() on all files on the the Mozilla profile of the user, and call open() on the directories he finds, then call getdents() to obtain the list of entries in that directory and so on…. Like any software recursively scanning the filesystem would do. The scan in the profile is stopped at the moment the software finds the user preference file.

This is easily explainable: Skype tries to install a FireFox plugin. It seems the Windows version has an option in the installer to disable that plugin but I have not found the same option in the Skype package.

So, Skype does search inside the user’s Firefox profile, but the only thing he does with the result it obtains is the installation of a plugin for the user’s convenience. It’s not even useful to search the place where it might be sending data since there is no data to send other that what it gathered through its registration wizard.

The final nail can be driven in the coffin on this theory by simple listing all the files opened by Skype during registration. None of the files contain personal information. You can see list of opened files I have extracted from the strace output at the end of this post.

Not evil on an evil operating system either…

Those results have been independently confirmed on Windows by DrFrakenstein, a twitterful, but blogless Code Ninja. He used Process Monitor and confirmed me roughly the same behavior but targeted at Internet Explorer.

So, probably not evil…

I can’t conclude this post by saying that Skype doesn’t include spyware. I simply spent one hour examining very limited data on the activity of the software during registration. Yet, I’m confident enough about my result to keep recommending its use to my family. Use Free alternatives such as Ekiga if you give high important to software freedom. It’s a opinion I respect. Just make sure you have something better that crappy strace analysis before dissing good but proprietary software.

See for yourself…

Here are the data I have obtained by running strace during Skype account creation server.

• The strace data
• The list of files Skype opens

Since I love some good shell-one-liner action, here is the command that extracts the list of opened files from the strace data.

grep open skype.trace | perl -ne '/\"(.*)\"/ && print $1."\n"' | sort | uniq

I find it amazing how your own brain can fool you sometimes. I did not dig this subject very much but I have been intrigues by studies about how people can suggest things to individuals and make them believe in it like it was their own and like it has always been true.

In some circumstances, you can create and believe in your own false memory. This post is about an interesting example of how that has happened to me yesterday night.

At the beginning of the year, I have bought an Asus N10E laptop. It’s a sweet little machine, like a cross between a netbook and a laptop. There is nothing exotic in the configuration of that laptop. The N10 serie of laptops have models that include fancier options. If you look on the net, you will find reviews of the fancier models (see a revew of the N10J). Most of them include a Bluetooth module.

Yesterday, I felt like linking my laptop to my N800 using Bluetooth. I thought it would be like, and that I need needed was to learn how to activate the link and that user-friendly programs would do the rest. I was mistaken. Linux did not detect the Bluetooth device at all. Since I build my own kernel, I decided to check my kernel configuration against other known good configuration for similar models but failed to find anything I would be missing. At that point, I decided to boot back in Windows, thinking I would find more information about Bluetooth there.

At this point, I began to lose patience. Windows had no information about the Bluetooth device in the laptop. I tried reinstalling a few drivers and programs. I even checked the laptop manual, something I seldom do, to see how to activate Bluetooth. It was failure. The normal documented way to activate Bluetooth failed. The Bluetooth device drive was even missing. The BIOS did not have the option to activate or deactivate it.

I began to worry why was my Bluetooth module not working. After all, I had vivid rememberance of the shiny Bluetooth icon displayed on the OSD when I pressed the WLAN hotkey on my laptop.

I first suspected that some experiment I had done in Linux went awry and disabled the Bluetooth module for good, something that could happen by extrapolating from some forums posts on similar problems…

My Occam Razor safety device finally kicked in and I began suspecting I was the source of the problem more than the computer was. After further research, I had to come to this conclusion…

There was probably no Bluetooth module in that laptop!

I write probably for correctness, because the only way to know for sure would mean opening the laptop and search its guts for the Bluetooth chip.

The memory I had of seeing the Bluetooth icon was probably manufactured by my own certitude of that laptop having the Bluetooth option combined with the screen shots of the icon in the laptop manual. The certitude was created by myself using incorrect information since the reviews you can read of this laptop usually talk about Bluetooth, but they usually don’t use of the particular model I own. Some N10E might also have a Bluetooth module pre-installed since it’s an optional feature of the model. Add the fact that the laptop has a Bluetooth led and you have all the ingredients you need to think this laptop would have the Bluetooth module. NCIX, the place from where I ordered the laptop, make no mention of Bluetooth support.

I don’t want to sound overly clever and say I’ve learned my lesson. It’s just too easy to mix up memories with other information. This is just a simple example of what can happen. I feel good about the fact that I was able to sit back and consider that my certitudes might have been fabricated by myself.

I’ve been using the Mercurial Shell Prompt hack for a while until I got annoyed at it. It caused a Python interpeter to start at every prompt, which is expansize especially if your system is already under strain.

This new shell hack is a lot faster much more generic. This small snippet is used to dynamically set the title of the terminal window in the following situation:

• if the terminal is at the prompt, set the title of the window to the name of the current directory
• if a program is running, set the title of the window to the name of the running program

The code is pretty straightforward. It uses prompt expansion and a magical escape sequence which is understood by the terminal.

case $TERM in
    xterm*)
        precmd () {print -Pn "\e]0;%1~\a"}
        preexec () {print -n "\e]0;$1\a"}
        ;;
esac

This is for Zsh. See this page for how to do the same with Bash and other shells.

There are a lot of variants you can make in the format of the title. Check your shell manual for more information.

If you use Konsole or GNOME Terminal, make sure they are configured to actually use what the emulated terminal dumps. Konsole has an option to set the terminal name to what you want so I suppose the GNOME Terminal has a similar feature.

As usual, I’m not claiming I’ve invented this. I probably read this on a blog somewhere, but I don’t remember where. This is too bad for me because I missing on possible pingbacks. Kudos to whoever I’ve picked this from.

Zsh manual links

• Zsh Prompt Expansion
• Zsh Special Functions

In my last post I’ve shown that some people are annoyed at the fact that they can no longer erase their root directory simply by typing rm -rf /. I’m happy that this possibility is removed. I’m not scared that means Linux is being dumbed down. There are already some safeguards in Linux and nobody is complaining about them because they guard even seasoned users to do things that are dangerous or silly.

Proper safeguards

dpkg won’t remove itself

Erasing the primary package manager on your system prevents your from installing any other package. It is hard to argue that it is a good thing to let that happen without warnings.

fdgonthier@moka:~/ > sudo dpkg --purge dpkg
dpkg: error processing dpkg (--purge):
 This is an essential package - it should not be removed.
Errors were encountered while processing:
 dpkg

You can still erase dpkg if you want by using the --force-remove-essential option. I can actually think of reasons somebody might want to do that but this is a bad idea, and probably a mistake, most of the time its attempted. dpkg and apt protect essential and important packages on a Debian system by asking for obscure force options or confirmation, depending on what is attempted.

You can’t unmount /

fdgonthier@moka:~/ > sudo umount /
umount: /: device is busy
umount: /: device is busy

That is akin to removing the wheels of a running car. You can’t even force-unmount it.

You really shouldn’t fsck a drive in use

It is possible to do that, but when you call fsck.ext3 on a mounted partition, it will ask you with a rather serious prompt if you really want to proceed. fsck.ext3 has a force option but it has no effects on this prompt. This speaks volume about how much doing this is discouraged.

In good Unix fashion it is still possible to do it if you really want to but the developer of fsck.ext3 has made clear in the man page that you don’t want to do that.

Some kernel modules can’t be unloaded

modprobe has a force option (-f) too. It can be used to unload reluctant modules. It is clearly documented in modprobe manual page that removing by force may crash your system. I’ve used it a few times, it worked a few times, it crashed a few times, but most of the time it will not work if the module is important.

Why should it be possible to remove the module for the computer chipset while it is running? The answer is left to the imagination of the reader. I think its a good thing this kind of module won’t unload.

You can’t kill the init process

kill -9 1 will do nothing. This is actually hardcoded in the Linux kernel. The init process is the mother of all process in the system. Without it, you won’t be able to boot, or reboot, or use your virtual consoles. It is the reaper of zombies so if it dies, prepare for zombie invasion. There is really no reason to kill this process, ever.

You can’t format a mounted filesystem

fdgonthier@moka:~/ > sudo mkfs.ext3 /dev/sda1
mke2fs 1.41.5 (23-Apr-2009)
/dev/sda1 is mounted; will not make a filesystem here!

mkfs.ext3 offers a way to force this but you have to use the force option (-F)twice.

Files in /dev are dynamically recreated

The health of your system is no longer tied to what is in the mysterious /dev directory. You can delete those files if you wan’t, and, depending what you erase, your currently running system may or may not be affected, but those problems will not survive a reboot or the invocation of /etc/init.d/udev restart.

GUI environment won’t let you in the dark

This is something common now. If for some reason, you change your resolution to something your monitor can’t support and your screen goes blank, desktop environment will automatically switch to your last used resolution. This is a safety mechanism preventing desktop users to set their screen to a resolution that leaves them without graphic display. Any resolution can still be configured statically into the system-wide xorg.conf if necessary.

Conclusion

All the safeguards and behaviors I’ve described above go against the Do What I Mean (DWIM) philosophy of Unix, and the something against the semantic of some option of the command: the kernel won’t let you unload your chipset module because it won’t work without it, mkfs.ext3 won’t let your format a partition that is in use because it’s certainly not what you want to do, dpkg won’t let your remove itself because there is a chance you won’t be able to reinstall it after it was removed.

If you think doing anything of what I’ve named above would be totaly stupid anyway, then you are right. Good safeguards aren’t there to nag you, and won’t ask you to double check everything you do. They simply prevent you from doing things that are possibly catastrophically detrimental to your system. Stop thinking rm -rf / should work because the Unix pilosophy about DYIM, because some command you can type have might no meaning at all.

Then a few things surprised me…

While testing potentially destructive commands in my test virtual machine, I’ve found I was able to do things I think I shouldn’t have. There might be some reason those things are possible. If you know why, please comment.

deluser: delete the root user

You can run deluser root as root without problems. This is of no consequences to the system because the root user is always the user with UID 0, but I think many scripts would be broken by that.

mkfs.ext3: tries to formats a directory

I don’t think a directory can hold a ext3 filesystem, yet mkfs.ext3 /etc will still try to proceed, and fail, after showing a warning telling that will probably won’t work.

fdgonthier@moka:~/ > sudo mkfs.ext3 /etc
[sudo] password for fdgonthier:
mke2fs 1.41.5 (23-Apr-2009)
/etc is not a block special device.
Proceed anyway? (y,n) y
mkfs.ext3: Device size reported to be zero.  Invalid partition specified, or
        partition table wasn't reread after running fdisk, due to
        a modified partition being busy and in use.  You may need to reboot
        to re-read your partition table.

Should it even bother to try?

fdisk: delete an active, mounted partition

fsck.ext3 detects that if targeted partition is mounted. I don’t see why fdisk couldn’t do that. I think there is a good chance that deleting a mounted partition is a mistake and there is not even a warning before proceeding.

unmount /proc and /sys

Those pseudofilesystem have become necessary to a lot of program. It’s a bit weird that you can just unmount them without warnings.

More silly things…

cat /dev/urandom > /dev/mem will very quickly crashes your system. There are multiple variant to that, which are all as efficient as rm -rf / at causing harm to a Linux system.

Those silly commands are unlikely to outside forum of Linux users that love to abuse n00bs, so safeguarding against them is of little importance. Still, why should a superuser shell should have such a raw access to disk devices? Is it necessary? Is there a way to mitigate that?

If you like that post, please subscribe to my
RSS feed. More readers would motivate me to keep writing at least once a week.

A followup…

This entry now has a followup: Good safeguards.

Update

It was pointed to me from Reddit and from a commenter that the -f flag in rm -rf is the force flag and isn’t part of the command. I’m willing to admit I’m wrong and probably overuse the force flag, but I didn’t remember how I got that bad habit.

I then retried the rm -r command on a directory in /tmp. This directory is owned by me but happens to include some files owned by root. I’m allowed to erase those files, but for each file I don’t own, I get a prompt asking me to confirm. This gets annoying quickly and had this not been a test I would have hit Ctrl+C and re-run the command with -f. If you often work with directories with mixed permissions (and I do), you can quicly get into the habit of running rm using the force flag.

This weakens the value of the -f flag for protecting against the huge mistake that is erasing /.

Original post

Did you know that rm -rf / no longer works on recent Ubuntu version? I bet you did not because this command tends to be a bit destructive.

I did not know that. I’ve never been bitten by an accidental rm -rf / but the possibility scares the hell out of me whenever I do a command in my root directory or whenever I write scripts thats erase files.

I’m a seasoned Linux user, yet I was pleased to know that Ubuntu now has that command refuse to work by default. rm -rf / now comes with the implied --preserve-root switch which returns an error when it attemps to erase the root directory.

I’m happy because that command has little reasons to exists beyond the mere fact that rm -rf is meant to unconditionnally erases files and directory: ie, a sole rmsysroot command would not exists. It would make as much sense as a car designed to only crash into the first tree.

Yet, some people oppose such a safeguard. The people that oppose this are probably the kind that made some people come up with sarcasms such as this lovely t-shirt.

LWN’s John Corbet has made a pretty good article about why its a good thing that rm -rf / is safeguarded against errors so I’m not going to rewrite a whole article about that. Let’s just repeat what I find important:

• unguarded rm -rf / might not just happen on the command line, but in scripts too, and at times where you can’t just hit Ctrl+C to save a part of your day
• its just too easy to make a syntax error in a command and type rm -rf / tmp/* when you meant to type rm -rf /tmp/*
• if you really want to remove /, you can use the --no-preserve-root switch.

Now let’s just look at the people who opposes this. Here are some pearls form people complaining about this new feature. I’ve found them on the Launchpad bug report and a blog funnily named Ubuntard. I think naming the authors of those quotes is useless. Suffice to know and weep that they exists.

Also, this directly conflicts with the functionality of the ‘-f’ switch, without which there ALREADY IS CONFIRMATION OF EVERY DELETION.

Bullshit. The -f is not a confirmation, it’s part of the command. Confirmation should come after the command.

So, what’s next? Patch dd to prevent it from wiping your partition?

Well, yes, dd sucks indeed should probably changed. But that’s the subject for another blog post. The point is that I use rm -rf at work up to several times per hour, and I use dd a few times per year. I doubt this is generalizing to say that rm has a much higher potential for errors for every Linux shell users than dd ever has and ever will.

Couldn’t agree more with you. If people don’t know what they are doing, they shouldn’t be working the command line anyway.[...]

rm is not a gun, dynamite, or C4. It erases files. I’ve got 172583 files on this small computer, chances are some of them are superflous and need to be erased. There should not be any remote risk that I erase all my disk if I want to remove just one.

Safety if for bitches. Knowledge is for winners.

No comments. Let’s just say that I hope this person finds a creative, unsafeguarded, way to nuke his system.

[...] come to think of it, if I’d been given a stupid error message telling me not to do that, I’d probably have punched a hole in my CRT instead.

… or yeah, he can do that too! I could go on for quite a while, but the pearl, that is actually repeated more than once, is the invocation of the “Unix philsophy”.

Changes of this nature are destructive to the philosophy of *nix, and is a step closer to the laughable click-the-dialog-box security of Windows Vista.

This is a safeguard; a satefy cushion. This is the program saying “You can’t really be that stupid so I’m not letting you do that!”

Don’t tell me about this so called Unix philosophy! Unix is evolving and when technology evolves, it also tends to grow features that keep people from shooting themselves in the foot. This is why cars have airbags, this is why some laptops have spill guards and free-fall sensors, and also why your water heater doesn’t blow up your house.

Just like people that want to drive without airbags can just remove them, Unix doesn’t bolt the --preserve-root option onto the rm command. It’s probably easy enough to take the coreutils package, change its build options to disable --preserve-root. I could probably write some instructions to do that in a few paragraphs, but since I think doing that would be stupid, I won’t!

I have been looking for database design application on Linux for a while. I even recently started searching for something compatible with Linux through Wine too. The Ubuntu and Debian package database is devoid of anything useful beyond Dia, which I hate for reasons that do not belong to this rant-free blog. There are some tools around for MySQL but it is not the SGDB I’m the most found of. I’m particularily interested in PostgreSQL

It was a revelation to me when I found 2 free (as in beer) design application on the PostgreSQL Wiki. I was even more surprised that both loaded and seemed to work out of the box in just about 30 seconds after their download. I’m not sure about the licensing terms but they certainly look safe to use for FOSS development.

I have not tried either extensively. I just believe both application needs to be linked since they seem to be hard to find. I might review one of them here some day.

Open System Architect

This has an impressive number of button, menus and and various gadgets. It is in fact pretty intimidating at first. It has the feel of a professionally developed application.

It is open-source but sadly does not seem to be actively maintained. This is something I fear I might discover after some prolongued use.

SQLPower Power*Architect

This simple looking application is in Java, which is a showstopper for some people. A good Java application isn’t something that stops me, but I admit Java applications sometimes have problem at setup time if they are not properly packaged.

This application doesn’t have that problem. It run fine when started with a canonical java -jar file.jar command.

The application does look funky a bit on my computer. The fonts are serif and heavily anti-aliased. It look clunky a bit. The screenshots on the site don’t have that problem. It might be a quirk related to my Java distribution or my some font handling problem on my Linux distribution. I need to investigate. That aside, the GUI is simple and no as scary as Open System Architect. If I could fix the font glitch, it will be sweet.

This is also open source. They have a Google Code project.

This little Bash snippets scans the Debian dpkg database for packages whose configurations files have been modified.

This only touches configurations files which are packaged and made known to dpkg. Some package manually handle their configuration file in maintainer scripts. A good example of that is /etc/network/interfaces which is an important configuration file but not automatically handled by dpkg.

This is as useful as you want to make it. I use it to track changes I’ve done which could end up with a conflict during a package upgrade. If you want a more thorough tracking of configuration changes, use something like etckeeper.

Notice I took some care to use more Bash’isms, to optimize the script. I was able to optimize by just a few percents. The bulk of the time must spent calculating MD5 sums.

#!/bin/bash

for pkg in /var/lib/dpkg/info/*.conffiles; do
    p1=${pkg#/var/lib/dpkg/info/}
    p=${p1%%.conffiles}
    IFS=$'n'
    for cfsum in $(dpkg-query -W -f='${Conffiles}' $p); do
        IFS=' '
        c=($(eval "echo $cfsum"))
        if [ -r ${c[0]} ]; then
            sum=${c[1]}
            cur_sum=($(eval "md5sum ${c[0]}"))
            if [ $sum != ${cur_sum[0]} ]; then
                echo "$p: ${c[0]}"
            fi
        else
            echo "Can't access file: ${c[0]}." > /dev/stderr
        fi
    done
done

This will output something like this:

$ ./check_changed
bash: /etc/bash.bashrc
console-tools: /etc/console-tools/config
libldap2: /etc/ldap/ldap.conf
ntp: /etc/ntp.conf
...

I will not go over the story of the OpenSSL fiasco again. Let’s just say that a developer inserted a particular patch in Debian OpenSSL package that he shouldn’t have. The patch was flawed in ways subtile enough that it escaped review 2 years. Long story short, Debian was left in a rather immense accumulation of fecal matter.

This was bad and made a lot of people object to the fact that software are patched in Linux distributions. It is true that software developers usually are the best person to fix the bugs in their software. What is still true but perhaps less obvious, is that most software developers are not ready or able to work in close cooperation with distribution developers so that their software are perfectly packaged without bugs and in time for a distribution release.

Distribution developers need to patch software for various, good, reasons, to ensure the best quality software distribution to their users, in a timely fashion.

Today I will examine three different kind of patch and try to justify why Debian developers, or distribution developers in general, will develope them. What is very important to note is that Debian, and probably most other distributions, wants that the patch the developers produce are sent to the original developers in the software they are packaging. In the case of the Debian distribution, this is mandated by the Debian Policy Manual, in section 4.3. That way, the patch can be eventually integrated in a future release, and the patch removed for the package for that new release.

The lesser divergence from upstream, the better. The OpenSSL fiasco is certainly a proof of that.

Plain bugfixes

It is a frequent occurance that packages are patched to fix small software bug. It is often inconvenient for a software packager to wait for a new release each time a bug is reported in the software they are responsible of. In some case, that release may come after several months (years), during which the bug will stay unfixed, which may in some case make the package unusable.

Patches are often pulled from the development repository of the software, if they can be backported to the version currently in the distribution.

Debian developers will then patch software when they can, to the best of their knowledge. It is recommended that they consult with the maintainer of the software before uploading their change to the distribution.

Patch example

http://patch-tracking.debian.net/patch/series/view/nano/2.0.7-4/ja_help_freeze.patch

In the case of the nano package, the existance of the patch is documented in the changelog of the package.

Compiler fixes

Like all other package in the distribution, compilers evolve and are eventually upgraded. Debian usually test new compilers ahead of time so they can stamp out compilation bugs early.

In case compilation fails for a package with a new version of a compiler, Debian developers will sometimes prefer to patch the program instead of asking the upstream developer to build his program with a recent or possibly unreleased version of the a compiler. They will patch the program to make it work with the new compiler and transmit the patch to the original developers for their future use.

Patch example

http://patch-tracking.debian.net/patch/series/view/qtodo/0.1.2-5/20-gcc.dpatch

This patch adapts the program to a newer than the one that was probably used to develop the package.

FHS bugfixes

The Debian distribution try to closely follow the Filesystem Hierarchy Standard (FHS). This is actually mandated in the Debian Policy Manual, section 9.1 so, if a program puts a file in a wrong place, it is viewed as a important bug.

Fortunately, most developers will follow the FHS, by habit or consciously. This simplify the packaging process, most program won’t need to be changed to be compliant. Sometimes though, some developers consider that it is not improper that a global configuration file is put outside /etc, or that image files can be put in /var.

Patch example

http://patch-tracking.debian.net/patch/series/view/trac/0.10.3-1etch4/01_use_global_config

This patch tells the Trac web application to look for its configuration file in /etc instead of /usr/share.

That will be enough for today. I think I’m already beyond the “tl;dr” level for most people. I will try to find some more example of types of patch done by packagers in another blog post.

The player

I’ve got this little device recently to replace my 256mb MP3 player. I was pleased that I got it pretty cheap during Black Friday from NewEgg Canada. NewEgg “leaked” their Black Friday rebates to Canada and reduced the price of that player to 85 CAN$ which is pretty cheap for a 8gb model.

At first, I must admit I was a bit sad with bugs and some missing features of the player. It is obviously an entry-level player. I’ve managed to find a satisfying way to work around all the bugs and uploaded 8gb of music to it and I’m happy since. I did not realize 8gb was that much content.

This post is a concentrate of the bugs I’ve found on the player and how I work around them. If you have better solutions, please comment on this post.

The bugs

MTP support

This is not really a bug, since this device works in UMS/MSC mode. Since I like to explore the capacities of my devices, I’ve nonetheless tried to get it to work.

For most Linux users, this player won’t work in MTP mode. I’ve only managed to make it work on very recent snapshots of libmtp. I got it to upload, but not to delete. I have not investigated that. Don’t count on MTP to work well until the next major Ubuntu release, Jaunty Jackalope. If MTP support was good, the most important bug on this player would be alleviated, but as it is not the case, please read on.

Bad sorting

The first and by far most annoying bug I’ve found is that the player doesn’t sort the ID3 tags on the player. The music files are displayed in the order they are uploaded on the player. If the player worked well with MTP, this wouldn’t be a problem because the media player will upload the files to the player in the correct order. File manager such as Konqueror don’t do that as it’s possibly slower to get the files from the disk in any kind of order. They are also multithreaded so that multiple files are copied at the same time. So if you upload on the player using Konqueror, the order will be screwed up. With file managers, the only options would be to copy files one by one by hand. This is obviously not a scalable process.

I’m satisfied to use rsync to copy files from my MP3 directory to my player. rsync copy and write the file in order.

rsync --verbose \
        --recursive \
        --times \
        --whole-file \
        --delay-updates \
        --modify-window=1 \
        --delete-before ~/Media/mp3/* .

I’m not exactly sure how this work and I now that my music is on the player, I don’t care enough to investigate it. Of course, I this probably is not perfect. I think that if I make changes inside an album, then rsync will just sync the changed file and thus the order inside the album will be screwed up. This could be automated but order will never be quite right. The only solution is correct sorting on the firmware, but, until that is fixed by iRiver, I’ll be happy to just reformatted the player and redo the copy overnight with rsync when I want to change the content of the player.

ID3v2.3 vs ID3v2.4

Most of my MP3 were correctly tagged using ID3v2 tags, but I initially did not know there were several incompatible versions of ID3v2. Amarok, as most MP3 players, read any ID3v2 versions, but writes only ID3v2.4 tags. The device simply cannot read those tags and will put files tagged in such way in the “Unknown Artist/Unknown Album” bunch, which is a PITA.

The first solution I’ve found was to use Kid3. It has a function to convert tags back and from ID3v2.3 and ID3v2.4. Kid3 is a fine program despite some UI shortcomings, but it doesn’t scale to gigabytes of files.

The next best thing was to use the EyeD3 library. EyeD3 is a simple Python program and library to manage ID3 tags. It includes features to convert between ID3v2 versions. I’ve lost the small script I’ve done to mass convert my MP3 files to ID3v2.3, but it looked a bit like that (untested) snippet.

tag.link("/some/file.mp3", eyeD3.ID3_V2)
tag.update(eyeD3.ID3_V2_3)

If I ever rewrite the script, I’ll post it here.

.ogg and Vorbis tags

The device doesn’t read Vorbis tags. For some people, this would be a total let-down. Not for me. I re-encoded I had as OGG to MP3. I have not investigated this further.

Playlists

The device uses .PLA playlists. The format of .PLA playlists is detailed here. I have not yet found the time look at this as playlists are not a killer feature for me.

LPlayer for the rest of us

I don’t consider I’ve discovered anything. All that informations I list here was scattered around the net. If you want more informations, please do Google and you will eventually find some.

The most important page I’ve found for LPlayer owner is LPlayer for the rest of us, which is a blog post similar to mine. I’ve tested all the information he has posted there and managed tp update my firmware, and encode a video to play on the player. Kudos to Tim De Pauw.

This is an annoyance I found got around to solve.  In Konsole, with a basic X configuration, when you type AltGr Space, you get a non-breakable space. It might happen in other things X terminal/shell combo, or the both of them might not matter at all.

If you are an heavy shell user, you might hit the AltGr Space combo by accident. This wouldn’t be bad if the shell made it somehow obvious that what you entered in a non-breakable space. The fact is that it doesn’t and it’s then totally impossible to distinguish a regular space with a non-breakable space after it was typed in the shell.

cd $HOME
zsh: no such file or directory: cd /home/fdgonthier

After typing such a command quickly, I was often left wondering what the hell was wrong with my command, since, as far as I could see, it was syntaxically correct.

The problem is that since there is a non-breakable space between cd and $HOME, Zsh wants to execute the whole command as a single command. Since I didn’t know I could even type non-breakable space in X, I checked what the hell the shell was doing by using strace. strace is my favorite diagnosis tool for any kind of problems in Linux. Programs don’t lie when they are spied with strace. The problem is obvious:

execve("cd\302\240/home/fdgonthier", ["cd\302\240/home/fdgonthier"], [/* 30 vars */]) = -1 ENOENT (No such file or directory)

It took me a while but I’ve found that \302\240 is the Unicode sequence for non-breakable space. Once I have found that, I Google search lead me to Launchpad bug 218637.

On this page, you see that you can disable non-breakable space using a xkb option in xorg.conf. Simply add the following in the InputDevice section related to your keyboard.

...
Option "XkbOptions"    "nbsp:none"
...

or use

setxkbmap -option "nbsp:none"

in a console, your favorite initialization file, or elsewhere.