Category: Linux

MobileMe bugs: Image upload with Linux based browsers impossible

Well, the MobileMe gallery upload seems to only like Mac browsers. I have only my SuSE box here, so I tried to upload using Chrom 5.0 and Firefox 3.5. No luck. Both browsers throw errors. Just like this:

So far, I cannot find any documentation on this behaviour. I would have assumed that either FFox or Chrome would work. MobileMe on OS X says it supports FFox and Safari. But since Safari is not available on Linux, I thought I might try FFox and Chrome. Now waiting for a MobileMe chat support guy. I doubt they are educated enough to actually help me…


Update: The chat guy was friendly, and had one hint: update to FFox 3.6. I was still on 3.5. And sure enough: now the upload works. Only one file at a time, though. But I found out even more on my own. It seems all the images are accessible from your iDisk as well. They are stored in Web/Sites/_gallery/id. Where id is the number of your gallery. However, you cannot just upload pictures there. Every image needs to be put in a separate directory. Every directory must then have the following files:


exif.json
large.jpg
medium.jpg
square.jpg
web.jpg


The exif.json is obviously a JSON style EXIF data block, e.g. like this:
{“data”:{“infoSensing”:”One-chip color area sensor”,”infoExposure”:”Normal program”,”infoExposureIndex”:”–“,”infoFNumber”:”2.8″,”infoDistance”:”–“,”infoGPSLongitude”:”8° 15&#39 35.40″ E”,”infoWidth”:”2,048 pixels”,”infoName”:”IMG_0133.jpg”,”infoDigitizedDate”:”Thu, 19 Aug 2010 12:18:20 PDT”,”infoFocalLength”:”3.85 mm”,”infoHeight”:”1,536 pixels”,”infoExposureTime”:”0.003846154″,”infoGPSLatitude”:”50° 0&#39 5.40″ N”,”infoAperture”:”f/3.0″,”infoMetering”:”Average”,”infoShutter”:”1/260″,”infoSize”:”1022.27 KB”,”infoBrightness”:”–“,”infoCameraModel”:”iPhone 3GS”,”infoMaxAperture”:”–“,”infoCameraMake”:”Apple”,”infoExposureBias”:”–“,”infoFlash”:”32″,”infoOriginalDate”:”Thu, 19 Aug 2010 12:18:20 PDT”,”infoGPSAltitude”:”115.00 m”,”infoISOSpeed”:”64″,”infoLightSource”:”–“,”infoSoftware”:”4.0.2″},”status”:1}
This should be easily created by a short shell script, using “exiftool -s image.jpg” and some awk magic. The image files in the folder are:

large.jpg: 2048×1536 (original resolution? at least for iPhone 3GS)
medium.jpg: 427×320 (approx. iPhone screen resolution)
square.jpg: 160×160 (thumbnail)
web.jpg: 1024×768

For portrait, I assume that the width and height are swapped. Have not checked this yet. Later, I will try to whip up a bash or Python script which produces these files automatically from a list of input images. Let’s see if this works.

Oh yes, one more thing: In Linux you can easily mount the iDisk with “wdfs  http://idisk.me.com/your-id iDisk/
“.

Update 2: A quick check revealed that the iDisk interface is quasi read-only. Writing new albums or pictures there will not show up in the gallery itself. That would have been too nice. So I guess this is only possible via the (unpublished?) HTTP API of MobileMe itself. Just like the Picasa API for uploading and manipulating photos. But it seems the API is quite hard to decipher, which is sad, given that Google practically documents all their APIs and encourages mashups and websites using their services.

Yellow pages when printing with Debian?

We had the problem of yellow tinted printouts on our Debian Testing machines. With my OS X machine, I did not have this problem, although both system use CUPS 1.4.3 for printing. It seems that Ghostscript was the culprit. The pstopdf filter to be exact. This bug report in the Debian bug tracker describes the exact same problem. The idea is to comment out the “-dUseCIEColor” option. I am not sure in how far this will also change the colour reproduction, but since our systems are not colour calibrated anyhow, I think this will not matter.

Syncing iPod Touch and iPhone with Linux

Ok, so I just tried out the new libimobiledevice. Installation was a breeze, using the provided OpenSUSE repository. A first run of ideviceinfo returned successfully detailed information about the attached iPod Touch. I also upgraded libgpod4. But Amarok 2.3 did not show a thing. Mounting of the iPod needed to be done manually using “ifuse ~/my-ipod-dir”. Supposedly, this happens automatically with Gnome, usin gvfs. But since I am using KDE, this is at the moment a no-go. Ok, so Amarok fails at this point in time. What about gtkpod? It works, although it throws some mysterious error message (“Eweiterte Informationen werden nicht verwendet” — wtf?), and that program is dog-slow. I though iTunes is bad, but this program is really, really slow as a snail. But here a proof of concept that I was able to sync to albums to the device:


What I did not yet try is syncing contacts, notes and bookmarks. With gtkpod, you need to specify a program to do that. No idea which one that is supposed to be. Keeping my MobileMe contacts in sync with my Linux desktop would be nice, though. Also, syncing from within Amarok is mandatory for me, but does not work currently. So let’s wait and hope the situation gets better with time. So far I will continue to sync my device with OS X.

Extremely slow SMB performance over WiFi using OS X

I have an OpenSUSE machine running a Samba server to provide files to my network. Now when I use the MacBook Pro to access those files, this happens awfully slow, with 80-200 KiB per second. I never figured out why, since rsync and sftp work very fast (for WiFi at least), at speeds of around 1.2 MiB per second. Today I googled for it, and it turns out that OS X delays ACK packages. I have no clue why it does that and what good this does, but you can disable it by running:

sudo sysctl -w net.inet.tcp.delayed_ack=0
After that, my SMB transfers jumped to 1 MiB per second, minimum. You can presumably make this change permanent by adding “net.inet.tcp.delayed_ack=0” to the file /etc/sysctl.conf. This will then be applied during system startup.
Update: Here is a nice explanation why the performance of OS X suffers sometimes, when using delayed ACK, and also why it might be useful in some cases.

Automatic security updates for Debian

I was wondering how to configure automatic security updates for Debian. Especially for Debian stable, which I am running. Turns out it’s easy. First, you just install cron-apt. Second, you can configure it by editing /etc/cron-apt/config. I learned from some other blog, that setting one variable helps in getting actually emails for the upgrades, namely setting MAILON=”upgrade” in this file does the trick. And lastly, there is a directory /etc/cron-apt/action.d, which contains all the actions that cron-apt will execute. In there is a file named 3-download, which I changed to look as follows:

autoclean -y
upgrade -y -o APT::Get::Show-Upgraded=true
The second line is changed from “dist-upgrade -d …”, because you don’t want any automatic dist-upgrades. That might leave your server in a horrible state. Also, instead of only downloading (-d), you want it to install the upgrades as well. That’s all and should help you keep up with security patches more easily.
Update: The updates seem to work fine! Tonight I got the first email that notified me of a successful security update.