I finally replaced the stock headunit of my car with a linux carpc that I built. It was several years I was planning it... But after one year of using a fmradio transmitter that was picking up all sort of interference, and due the lack of any mp3 or aux-in capability of my cd player I decided it was time to stop with the hacks and to finally build the real thing with linux.

Hardware list: Carnetix P1900 with macpack, linitx 7" transflective touchscreen lcd, mac mini, BU353 sirf star IIII usb, nova-t usb2 dvb-t and amplified dvb-t car antenna, r100 usb radio, bluetooth usb dongle, THA-275 amplifier (sounds great). (in the pic you'll see the THA-475 but one week later I later I replaced with a THA-275 in 2-ohm configuration for various reasons not relevant to mention here)

If I would do it again surely I wouldn't bother to add the dvb-t and fm radio receivers, this is only wasted money and wasted time: dvb-t reception is bad while driving, a few buildings are enough to temporarily lose signal. Fm radio is too low quality and I don't like its content in Italy, if compared to all radios available with 3G streaming (through my cellphone). elisa supports natively both an huge list of great southcast radios and youtube. So if 60G of space aren't really enough to fit all you need on the road, 3G streaming is surely preferable any dvb-t or fm radio. wifi streaming of course works too (wpa_supplicant with madwifi driver) but obviously not while driving.

I also had to make a few changes to wine sources for focus and alsa and another very important hack to suspend.c so that it waits 5 seconds after it switched to console before it freezes, and so that it waits 5 seconds also after resume before it switches back from console to graphics mode. Without such an hack resume can't work reliably and touchscreen calibration is always screwed up after resume. The usb gps also isn't resuming as /dev/ttyUSB0 but it changes from USB0 to USB1 after every suspend/resume cycle, so in the script that runs s2disk I simply rename ttyUSB1 to ttyUSB0 after s2disk returns and that's enough to make resume work flawlessy for the gps apps.

As GUI I'm running KDE3.5 on it (suspend/resume make it play in less than than 30seconds after turning on the car, shutdown time is irrelevant as it happens after I'm already out of the car but it also doesn't take more than 30-40 sec) and I switch between gps apps and elisa with a vertical panel with only a taskbar in it, that grows in size when more apps are run. I've also configured a couple of mouse gestures to simulate alt-tab, and to iconize apps, or move them above the edge of the screen (screen resolution is native 1:1 at 800x480 so screen it's not very tall and not all control windows fit).

In practice I only use the elisa media player and the gps apps and I switch between them with the tiny panel-taskbar. They all runs fullscreen without kde borders, and I set them with properties of 'keep below others' so the tiny taskbar remains visible in the foreground in the bottom right corner (and growsup, growsleft not).

I had to leave 20G to osx practically only as bootloader and to be able to upgrade the bios if I ever want to. The bootloader could be moved to the efi partition but I heard of boot time delays if one does that, so I didn't bother to lose 20G to avoid risking to boot in more than 20-30sec, 60G are more than enough to fit all my data. Still better to lose 20G because of osx than because of other proprietary OS ;-).

On the touchscreen side the major trouble was calibration, swap_xy has to be set in the kernel driver and still swapy of evtouch has to be set in the X config file (or you can invert maxy and miny values). The taptimer has to be set to 150 and the longtouchtimer to 250, or there's no chance you'll ever be able to right click with the halftap trick. After that even right click is fully reliable.

I also added a gotemp USB termometer in the back of the lcd (where the p1900 is also located) to monitor temp with a cron job that launch an xmessage if temperature exceedes some limit. Another script monitor the core 2 duo internal temp sensors to be sure the macmini doesn't overheat. After driving two hours with heating on in the car, the back of the touchscreen (inside the dash) didn't exceed 55 degrees which is fine, the mac mini core 2 duo CPUS stayed around 60 degrees so ambient around the cpu was suppsedly lower than 60 degrees. elisa and the gps tracking my position at all times don't take more than 50% of the cpu in average which leaves the cpu always at the lowest freq available with the ondemand cpufreq controller.

When I need to upgrade software or upload data I only need to unplug usb, carnetix and vga cables to get the macmini out of the passenger tray and boot it with the power supply near my access point so I connect to it with ssh, rsync and vnc.

Overall it's working perfectly and it largely exceeded my best expectations, both in terms of sound quality, usability and safety.

I can't touch the touchscreen while driving but setting a long enough playlist is enough to avoid needing that.

While reading about the bailout I run into this...

I never liked the idea of my taxes burning in engine jets but I would have liked that even less.

If you're interested about Virtualization I suggest to read this report about my views, hope you like it ;-).

Never seen a weird place like Formentera, all people there speaks Italian, it doesn't feel like being in Spain at all. In Canada at least somebody speaks French ;-). It's a great place to have a vacation nevertheless, the sea is cool and there are nice parties and events by night often on the beach in very Italian style.

Yesterday I returned from the KVM Forum 2008. The conference was great.

My presentation about the MMU Notifier was admittedly a bit too complex for people not actively working on the mmu.c code. MMU Notifier is a fairly small patch but the complexity of understanding what it does and how it works is quite high. You should read the slides if you're interested about that. I didn't bullettize them much, that was a cons during the presentation, but it's a bonus to read them online.

The trip also reminded me how much I like San Francisco and California!

For quite a while I couldn't connect to the internet using bluetooth /dev/rfcomm0 with the Samsung Z720, despite the /dev/ttyACM0 worked with with the supplied usb cable. The trick is to change channel 1 to channel 4 in the /etc/bluetooth/rfcomm.conf file (this is with Gentoo after unmasking the latest bluez-libs-3.28, bluez-utils-3.28-r1 packages and kernel is 2.6.24, but it should work the same for any recent distro). I didn't know the modem channel was different from 1... Now even both kmobiletools and gammu works using /dev/rfcomm0 like with ttyACM0.

The ping latency I get with bluetooth to reach my asterisk server at home (including the latency of the adsl, vpn etc..) is slightly above 100msec but usually below 150msec with HSDPA. With EDGE I usually get more than 300msec. Usb cable or bluetooth don't seem to make a lot of difference for the latency.

I didn't bother to measure the bandwidth with rfcomm but it should decrease it from 7mbit of HSDPA over ttyACM0 to 2.1mbit of EDR.

As for the AT commands needed to establish the ppp connection with HSDPA (or UMTS or EDGE or GPRS) this is my wvdial.conf:

[Dialer Defaults]
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
ISDN = 0

[Dialer z720-bt]
Init4 = AT+CGDCONT=1,"IP","your.apn"
Modem Type = USB Modem
;Modem = /dev/ttyACM0
Modem = /dev/rfcomm0
Baud = 921600
Phone = *99**1*1#
Stupid Mode = on
Username = yourusername
Password = yourpassword
;Auto DNS = on
Auto Reconnect = off
Dial Attempts = 1
Carrier Check = no

You likely want to turn Auto DNS on if you don't use a dns server behind the vpn. Hope this helps if you had my same rfcomm problem with the the Z720.

After 8 years and half yesterday was my last day of work for Novell/SUSE.

While on one hand I'm extremely excited about my new job and the huge potential of the products that I'll be working on starting today (that's why I changed job after all ;-), on the other hand I'm sad to leave Novell after so long. The environment of SUSE Labs is fun, friendly, clever and productive. I didn't leave because of things like the Microsoft deal (which for various reasons I consider irrelevant as far as open source development is concerned, and financially speaking it was probably a no brainer decision for Novell to take so I certainly couldn't complain much about it), or unhappiness about the job. It's just that a new opportunity presented itself with a startup I strongly believe in, working on a really cool technology that I like, need and use so much myself ;-).

Now that I left, I think I can definitely recommend Novell as a great company to work for, to be partner with and to be customer of.

This is an interesting article of my Prof. of Operative Systems and good friend of mine at Bologna University. I learnt so much from him... It was a real pleasure to listen to his lectures every day back then in my University days ;-).

After reading the article on /. my first thought was this. No I didn't write that comment! But since I had the exact same thought of this QuantumG guy it means we're either both right or we are thinking wrong the exact same way ;-).

Anyway Linus's right about LSM, those arguments that LSM should be removed to improve security made me hylarious. Anybody caring about that kind level of security would start off immediately by turning off kernel modules as a whole, and dropping /dev/mem from the kernel etc.. making the whole argument about LSM void.

Linus's totally right about the inode vs pathname flamewars too, actually anybody who pretends to know what "chown 700 /home/user" does, should be able to understand that too IMHO. Yes, the max pathname limit isn't totally beautiful, but being prevented to use absolute pathnames in fs syscalls if the abs pathname is longer than a page isn't beautiful either... A firewall doesn't need to be flexible, it needs to be secure, so a limit in the max pathname doesn't decrease its security in any way. If you want theoretical perfection and unlimited recursive paths, I guess you'll be able to write perfect and bug free applications too not needing any security module, so you certainly don't care ;-).

Also guess why it wasn't selinux to find that skype was reading the firefox profile... Just a coincidence? Well, perhaps, but I think Ted's reply in the thread is a slightly better explanation for that.

Yesterday I come back from the SUSE Labs Conference. Given that I spend most of the time working alone from my office, it was great to spend a week in a nice place in the mountains (practically in the middle of nowhere) with lots of colleagues from all over the world. When not in my place, I spend most summer weekends near the beach, so I kind of enjoy to see the forest mountain places in the summer too. And cz beer was great too (as expected ;).