Sananen Ruuhkamaksusta

Ruuhkamaksun idea on yksinkertainen - mitä kovempi ruuhka, sitä kovempi maksu. Maaseudun hiljaisten teiden ajaminen olisi halpaa kun taas ruuhka-aikaan kaupunkiin ajaminen kallista. Itse asiassa kaupungissa ajamisesta voisi ylipäätään laskuttaa enemmän. Ruuhkamaksua pitäisi kerätä yksityisyyttä loukkaamatta, ja maksun kiertämisen pitäisi olla hankalaa.

Minulla on uutinen - Meillä on jo tuollainen ruuhkamaksu.

Sitä kutsutaan polttoaineveroksi.

Ruuhkamaksun keräyslaite

Ruuhkassa ajaminen on nykivää kaasun ja jarrun polkemista. Auton moottori syö ruuhkassa helposti 2-3 kertaa enemmän bensaa kuin tasainen ajaminen ruuhkattomilla teillä. Näin autoilija maksaa ruuhkassa jopa kolme kertaa enemmän polttoaineveroa. Polttomoottori mittaa tarkasti ajettua matkaa, ja maksattaa autoilijalle lisälaskua ruuhka-ajon lisäksi mm. isolla autolla ajamisesta, raskaan kaasujalan käyttämisestä ja turhasta ajamisesta ylipäätänsä. Polttoaineverosta ei kerry viranomaisille rekisteriä kansalaisten liikkeistä.

Polttoainevero on suoraan vero siitä kuinka paljon autoilija lämmittää maapalloa hiilidioksidipäästöillään. Ja ilmasto on kai pohjimmiltaan se syy miksi ruuhkamaksua halutaan! Polttoainevero tekee siis jo kaiken sen mitä ruuhkamaksu toivoo - ilman että tarvitsee rakentaa kallista valvontajärjestelmää.

Liikenneministeriön raportissa satelliittivalvontaan perustuva ruuhkamaksun luominen maksaisi kuulemma 200-300 miljoonaa, ja ylläpitokustannukset vuosittain 10% tästä eli 20-30 miljoonaa. Tieto ja Accenture tekee taattua laatua aikataulussa, budjetissa ja ilman yksityisyyttä vaarantavia bugeja - uskokoon ken tahtoo. Herääkin epäilys, että koko hankkeen tarkoitus on vain luoda työllisyyttä it-konsulteille ja autoasentajille.

Automatka töihin on useimmille mukavuus- eikä hintakysymys. Tämän voi jokainen itse todentaa katselemalla moniko länsiväylän ruuhkassa matelevista autoista on järkevä ja edullinen pikkuauto ja moniko kalliimpi ja mukavampi iso auto. Jos kaupunkiautoilua halutaan vähentää, pitää tehdä tehdä julkisista mukavampia ja kätevämpiä kuin autoista. Monelle julkiset ovatkin kätevämpiä - siksi julkisilla on paljon käyttäjiä Helsingissä. Miten vielä useammalla julkiset saataisiin kätevämmäksi, olisikin sitten toisen blogipostauksen asia.

Eturivin Audi jonottaa Helsinkiin siksi että se on halpaa?

ps. Ruuhkamaksu-työryhmää vetää Shellin hallituksen puheenjohtaja Jorma Ollila - ehkä siksi yksinkertaisemmat ratkaisut kuten esim. polttoaineveron korotus ei ole käynyt työryhmän mielessä.

My 5 eurocents on the Rasberry Pi opengl driver debacle

The Linux community rather unenthusiastic about the open source shim to Raspberry PI GPU. I think the backslash is a bit unfair, even if the marketing from Raspberry was pompous - It is still a step in the right direction. More raspberry PI hardware enablement code is open source than before.

A step in the wrong direction is "locking firmware", where a loadable firmware is made read-only by storing it to a ROM. It has been planned by the GTA04 phone project, and Raspberry foundation also considers making a locked GPU ROM device. This is madness that needs to stop. It may fulfill the letter of FSF guidelines, but it is firmly against the spirit. It does not increase freedom - it takes away vendors ability to provide bugfixes to firmware, and communities possibility of reverse engineering the firmware.

F-droid store for android

Christopher complained that in android, you need a user account to install software. That is not true, there is F-droid which is a catalog of Free/Open Source Software, no user account needed.

Lack of multitasking is yes annoying sometimes, yes, but that is really a poweruser problem. Most users don't load web pages in background while playing. Most users will simply not bother with web pages that take too long to load. Given the choice, most users will prefer a snappy UI over a UI that allows proper multitasking. N900 was never snappy, stutters were common, and it would often hang for long times if you had too many apps or browser windows open at the same time. Even for Android there are way more complaints about non-fluid UI than lack of proper multitasking. It is thus only logical for the Android developers to concentrate in developing a snappier UI over improving multitasking.

The fact that Android has given 400+ million Linux computers out in the hands of consumers is one of the MOST AMAZING THINGS ever. But it seems others on FOSS community seem to consider Android a rather unfortunate event, because it's not "Real Linux" or "100% free software" or "because it's not bug free". Err, like Maemo or MeeGo ever is any of those...

It is fair to complain about usability quirks Android as enduser. But if you believe Free Software, you should also see the opportunity the open source parts of Android provides to you fix it to your needs. After all, the point of Free Software is that you don't need to depend on the upstream to fix you everything? Christoph complains that the stock email app is lacking. Android Email app is Open Source (Maemo and N9 email apps are not). Android email has been forked as K-9 Mail. The app lifecycle is fixable allowing you to return from browser to the mail you were at - at least a plenty of other apps manage to do that.

The question is, are we consumers or creators. If we are just sitting waiting to Google provide us a perfect shrinkwrapped Android, we could just as well use iPhone or Windows phone. We should instead see Android as an opportunity - when it's 90% open source, fix the remaining closed source bits like open source 3D drivers and open source replacements for proprietary interfaces.

Adventures in perlsembly

Some Debian packages are missing important optimizations. This one was noticed when comparing openssl benchmarks by monkeyiq to the results got on a pandaboard (OMAP 4430). Being a Cortex-A9, it should have clearly been same or faster than the N9 in the benchmark (OMAP 3630). And it was, except for AES benchmarks. Since AES is quite important, that seemed a bit odd. Turns out, that Debian/Ubuntu package had some hand-crafted arm assembler optimizations missing. Enable them, and the results with openssl speed command benchmark were quite nice:

The 'numbers' are in 1000s of bytes per second processed.

benchmark    debian       with patch +%
sha1         55836.67k -> 73599.08k +31.811%
aes-128 cbc  18451.11k -> 36305.34k +96.765%
aes-256 cbc  13552.30k -> 27108.31k +100.027%
sha256       20092.25k -> 43469.45k +116.349%
sha512       8052.74k  -> 37194.28k +361.884 %
rsa 1024     1904.2v/S -> 3650.5v/s +91.708 %

Curiously, the assembler code is actually in perl files that output assembler code. This kind of code is affectionately called "perlsembly". A bug with patch has been filed, hopefully applied at the soonest.

Mosh - better remote shell

In this age of 3d accelerated desktops and all that fancy stuff, one does not expect practical innovation happening in the remote terminal emulation area. But it has just happened. It is called Mosh, a shorthand for "Mobile Shell".

What does it do better than ssh we have learned to love?

• Less lag! Being UDP based, it is not prone to TCP congestion effects. Considering that voip, games and everything else latency critical has been UDP based, it is (almost) surprising that it wasn't done for interactive terminals before...
• Even less lag! Mosh provides local echo and line editing when the other side is not being responsive. To do this, mosh actually becomes a terminal emulator of it's own. This stuff is sweet on unstable 3G and conference wifi networks.
• Survives suspending. Resume your laptop and *bam* all your remote mutt and vim editors are still there instead of the "connection reset" you get from ssh.
• Roaming. Got another IP? Moved from wifi to ethernet to 3G? your sessions are still open! Another thing a TCP based protocol couldn't do easily...

It doesn't replace ssh, as it still borrows authentication from ssh. But that's cool, as you can keep your ssh authorized keys.

Available in Debian unstable,testing and Backports today, and many other systems as well. Hopefully an Android client comes available soon, as the above mentioned advantages seem really tailored for android like mobile systems.

Caveat: This is new stuff, and thus hasn't quite been proven to be secure.

Cross Compiling with MultiArch

Congrats to the Ubuntu Folk for the new LTS release. Incidentally this is also the first release where our work on MultiArch bears fruit. We can now cross-compile relatively easily without resorting to hacks like scratchbox, qemu chroot or dpkg-cross/xdeb.

Lets show short practical guide on cross-building Qemu for armhf. The instructions refer to precise, but the goodiness is on the way to Debian as well. Biggest missing piece being the cross-compiler packages, which we have an Summer of Code project. The example is operated in a chroot to avoid potentially messing up your working machine. Qemu-linaro is not a shining example, as cross-building it doesn't work out of box. But that is educational, it allows me to show what kind of issues you can bump into, and how to fix them.

 $ sudo debootstrap --variant=buildd precise /srv/precise

Edit the /srv/precise/etc/apt.sources.list to the following (replace amd64 with i386 if you made an i386 chroot)

deb [arch=amd64] http://archive.ubuntu.com/ubuntu precise main universe
deb [arch=armhf] http://ports.ubuntu.com/ubuntu-ports precise main universe
deb-src http://archive.ubuntu.com/ubuntu precise main universe

Edit the /srv/precise/etc/dpkg/dpkg.cfg.d/multiarch by adding the following line:

foreign-architecture armhf

Finally disable install of recommends by editing /srv/precise/etc/apt/apt.conf.d/10local:

APT::Install-Recommends "0";
APT::Install-Suggests "0";

Install the armhf crosscompiler the chroot

 $ sudo chroot /srv/precise/
 # unset LANG LANGUAGE
 # mount -t proc proc /proc
 # apt-get update
 # apt-get install g++-arm-linux-gnueabihf pkg-config-arm-linux-gnueabihf

Get the sources and try to install the cross-buildeps:

 # cd /tmp
 # apt-get source qemu-linaro
 # cd qemu-linaro-*
 # apt-get build-dep -aarmhf qemu-linaro

As we see, the build-dep bombs out ugly, with a them of "perl" being unable to be installed. This is because apt-get can't figure out if we should install and armhf or amd64 version of perl. We don't use the required syntax yet in Build-Dep line, "perl:any", as dpkg and apt in previous released don't support it. Thus back porting would no longer be possible. One way to fix it, would be to drop perl build-dep, as perl is already pulled by other build-deps. But lets instead show howto install it the build-deps manually. First we build system build-deps, then target architecture ones:

 # apt-get install debhelper texinfo
 # apt-get install zlib1g-dev:armhf libasound2-dev:armhf libsdl1.2-dev:armhf libx11-dev:armhf libpulse-dev:armhf libncurses5-dev:armhf libbrlapi-dev:armhf libcurl4-gnutls-dev:armhf libgnutls-dev:armhf libsasl2-dev:armhf uuid-dev:armhf libvdeplug2-dev:armhf libbluetooth-dev:armhf

And try the build[1]:

 # dpkg-buildpackage -aarmhf -B

Which sadly errors out. Turns out the cross-build support in debian/rules is broken. Instead of --cc we need to feed an --cross-prefix to the ./configure of qemu. Edit the debian/rules with replacing

-  conf_arch += --cc=$(DEB_HOST_GNU_TYPE)-gcc --cpu=$(QEMU_CPU)
+  conf_arch += --cross-prefix=$(DEB_HOST_GNU_TYPE)-

Optional: Since we are cross-compiling from a multicore machine, lets also add parallel building support, by changing the override_dh_auto_build: rule to have --parallel flags in debian/rules as well:

override_dh_auto_build:
        # system build
        dh_auto_build -B system-build --parallel
ifeq ($(DEB_HOST_ARCH_OS),linux)
        # user build
        dh_auto_build -B user-build --parallel

        # static user build
        dh_auto_build -B user-static-build --parallel

Try the build again:

 # export DEB_BUILD_OPTIONS=parallel=4 # I have dual-core hyperthreading machine, build with all four threads
 # time dpkg-buildpackage -aarmhf -B
 ...
dpkg-buildpackage: binary only upload (no source included)

real    18m53.425s
user    65m42.570s
sys     2m50.383s

The Native build of qemu-linaro took 4h 11min.

[1] You should not build as root - but to keep instructions short, I'm not explaining howto add and use a unprivileged user in a chroot. Do as I *say*, not as I *do*!

CuBox

Just recently arrived from DHL, a solid-run CuBox. I guess nobody who knows me will be surprised when I tell it features an ARM cpu. Specifically an Marvell Armada 510. It features ARMv7 compatibility, with a slight twist of replacing NEON extensions with iWMMX extensions. On the boasting side Armada 510 promises 1080p video decoding and OpenGL ES graphics acceleration (closed source, unfortunately).

The tiny form factor of CuBox is pretty much more than the impressive amount of connectors included;

* Gigabit ethernet
* 2*USB
* eSATA
* HDMI out
* s/pdif optical audio out
* microSD slot
* microUSB serial/jtag port

The last item being important as it makes CuBox unbrickable.. Some will probably lament the lack of WiFi/Bluetooth, but get everything in one device ;). Besides, the USB slots are there to be filled..

Getting started was an slightly rough ride, as in the included Ubuntu (10.04 LTS), X refused to start. After wrongly suspecting that my Display was at fault, turned out the microSD included was slightly corrupted, and some critical contents of xkb-data package were garbage. After reinstall of that package, everything worked, including playing Big Buck Bunny in FullHD with totem.

Biggest disappointment so far is the non-mainline kernel, based on old 2.6.32.9. Some mainline support of Armada 510 exist, but will it work with the proprietary graphics code?