Friday, February 21, 2014

Where the armel buildd time went

Wanna-build, wanna-build, which packages spent most time on armel buildd's since beginning of 2013?
         package         | sum(build_time)
 libreoffice             | 114 09:16:34
 linux                   | 113 02:58:50
 gcc-4.8                 | 064 01:21:09
 webkitgtk               | 059 19:09:27
 acl2                    | 043 16:40:50
 gcc-4.7                 | 028 14:03:53
 iceweasel               | 026 19:02:13
 gcc-snapshot            | 026 01:31:21
 openjdk-7               | 020 02:41:53
 php5                    | 019 16:13:22
 llvm-toolchain-3.3      | 017 19:05:38
 qt4-x11                 | 017 02:57:09
 espresso                | 016 03:50:37
 pypy                    | 015 07:07:25
 icedove                 | 014 18:57:08
 insighttoolkit4         | 014 17:16:43
 qtbase-opensource-src   | 014 12:39:09
 llvm-toolchain-3.4      | 012 03:06:15
 mono                    | 011 22:30:13
 atlas                   | 011 20:40:54
 qemu                    | 011 17:11:09
 calligra                | 011 16:05:55
 gnuradio                | 011 15:19:35
 resiprocate             | 011 10:14:56
 llvm-toolchain-snapshot | 011 02:04:44
 libav                   | 010 13:52:03
 python2.7               | 009 18:58:33
 ghc                     | 009 18:28:48
 gnat-4.8                | 009 13:59:57
 axiom                   | 009 12:40:24
 cython                  | 009 00:47:04
 openjdk-6               | 008 16:38:14
 oce                     | 008 10:29:20
 eglibc                  | 008 06:04:26
 ppl                     | 007 20:48:45
 root-system             | 007 17:32:16
 openturns               | 007 10:12:53
 gcl                     | 007 08:02:42
 gcc-4.6                 | 007 02:50:48
 k3d                     | 007 00:36:11
 python3.3               | 007 00:25:42
 llvm-toolchain-3.2      | 007 00:17:59
 vtk                     | 006 17:53:28
 samba                   | 006 17:17:27
 mysql-workbench         | 006 14:36:46
 kde-workspace           | 006 07:31:12
 gmsh                    | 006 04:32:42
 psi-plus                | 006 04:30:08
 octave                  | 006 04:17:22
 paraview                | 006 04:13:25
Timeformat is "days HH:MM:SS". Our ridiculously stable mv78x00 buildd's have served well, but has come to become let them rest. Now, to find out how many of these top time consuming packages can build with parallel make and are not doing so already.

Friday, December 20, 2013

Replicant on Galaxy S3

I recently got my self and Galaxy S3 for testing out Replicant, an android image made out of only open source components.

Why Galaxy S3?

It is well supported in Replicant, almost every driver is already open source. The hardware specs are acceptable, 1.4Ghz quad core, 1GB ram, microsd, and all the peripheral chips one expects for a phone. Galaxy S3 has sold insanely (50 million units supposedly), meaning I won't run out of accessories and aftermarket spare parts any time soon. The massive installed base also means a huge potential user community. S3 is still available as new, with two years of warranty.

Why not

While the S3 is still available new, it is safe to assume production is ending already - 1.5 year old product is ancient history in mobile world! It remains to be seen how much the massive user base will defend against the obsolescence. Upstream kernel support for "old" cpu is open question, replicant is still basing kernel on vendor kernel. Bootloader is unlocked, but it can't be changed due to trusted^Wtreacherous computing, preventing things like boot from sd card. Finally, not everything is open source, the GPU (mali) driver while being reverse engineered, is taking it's time - and the GPS hasn't been reversed yet.

Installing replicant

Before install, from the original installation, you might want to take a copy of firmware files (since replicant won't provide them). enable developer mode on the S3 and:
sudo apt-get install android-tools
mkdir firmware
adb pull /system/vendor/firmware/  
adb pull /system/etc/wifi
After then, just follow official replicant install guide for S3. If you don't mind closed source firmwares, post-install you need to push the firmware files back:
adb shell
mount -o remount,rw /system
adb push . /system/vendor/firmware
Here was my first catch, the wifi firmwares from jelly bean based image were not compatible with older ICS based replicant.

Using replicant

Booting to replicant is fast, few seconds to the pin screen. You are treated with the standard android lockscreen, usual slide/pin/pattern options are available. Basic functions like phone, sms and web browsing have icons from the homescreen and work without a hitch. Likewise camera seems to work, really the only smartphone feature missing is GPS.

Sidenote - this image looks a LOT better on the S3 than on my thinkpad. No wonder people are flocking to phones and tablets when laptop makers use such crappy components.

The grid menu has the standard android AOSP opensource applications in the ICS style menu with the extra of f-droid icon - which is the installer for open source applications. F-droid is it's own project that complements replicant project by maintaining a catalog of Free Software.
F-droid brings hundreds of open source applications not only for replicant, but for any other android users, including platforms with android compatibility, such as Jolla's Sailfish OS. Of course f-droid client is open source, like the f-droid server (in Debian too). F-droid server is not just repository management, it can take care of building and deploying android apps.
The WebKit based android browser renders web sites without issues, and if you are not happy with, you can download Firefox from f-droid. Many websites will notice you are mobile, and provide mobile web sites, which is sometimes good and sometimes annoying. Worse, some pages detect you are android and only offer you to load their closed android app for viewing the page. OTOH I am already viewing their closed source website, so using closed source app to view it isn't much worse.

This keyboard is again the android standard one, but for most unixy people the hacker's keyboard with arrow buttons and ctrl/alt will probably be the one you want.

Closing thoughts

While using replicant has been very smooth, the lack of GPS is becoming a deal-breaker. I could just copy the gpsd from cyanogen, like some have done, but it kind of beats the purpose of having replicant on the phone. So it might be that I move back to cyanogen, unless I find time to help reverse engineering the BCM4751 GPS.

Monday, December 16, 2013

Ollilan hyökkäys sähköautoja vastaan

Viimeksi kun kysyin mitä tämä vero tuo polttoaineveroon verrattuna, LVM:stä vastattiin:
Polttoaineveron suurin ongelma on kuitenkin se, että pitkällä aikavälillä se poistuu. Autoilu tulee sähköistymään, jolloin käyttöä ei voida verottaa enää bensapumpulla.
Tämä on sangen hilpeää. Tyhmempi olisi luullut että polttoainevero olisi haittavero ja olisi vain hienoa jos polttoainetta kuluu vähemmän. Kun muualla sähköautoja yritetään nimenomaan suosia mm. subventoimalla, Suomessa ne koetaan UHKAKSI verokertymälle. Onhan se ihan selkee juttu et menetyt veroeurot on suurempi uhka kuin ilmaston lämpiäminen hiilidioksidipäästöjen kautta! Tämä on yhtä loogista kuin että tupakoinnin vähentyessä aletaan verottamaan vaikka purukumia. Pitäähän veroja kertyä edelleen yhtä paljon (tai enemmän).

Mutta jos kerta sähköautot on verolle pantava ja satelliittiseurantaan laitettava, niin miksei sähköpolkupyörät samalla? .

Boostbike sähköpyörä

Tai polkupyörät ja jalankulkijat muutenkin? Jos ihmiset vaihtavat autoilun pyöräilyyn, sehän on uhka polttoaineveron kertymälle siinä missä sähköautot. Käyttäväthän pyörätkin verovaroin tehtyjä liikenneväyliä maksamatta polttoaineveroa.

Shell on maailman suurin öljy-yhtiö ja Jorma Ollila on Shellin hallituksen puheenjohtaja. Miten hänen voidaan antaa johtaa työryhmää, jossa lyödään sähköautojen yleistymiselle kapuloita rattaisiin? Ja Suomessako ei ole korruptiota?

ps. Ollila sanoo että "Kilometrivero määräytyisi hiilidioksidipäästöjen perusteella". Mutta seuranta ei voi tietää miten paljon hiilidioksidia auto tuottaa. Esim. raskaan kaasujalan käyttö tai huonosti säädetty moottori jää verottamatta kilometrimaksussa.

Monday, July 22, 2013

ACPI on ARM storm in teacup

A recent google+ post by Jon Masters caused some stormy and some less stormy responses.

A lot of BIOS/UEFI/ACPI hate comes X86, where ACPI is used from everything from suspending devices to reading buttons and setting leds. So when X86 kernel suspends, it does magic calls to ACPI and prays that the firmware vendor did not screw it up. Now vendors do screw up, hence lots of cursing and ugly workarounds in the kernel follows. My Lenovo has a firwmare bug where the FN-buttons and Fan stops working if the laptop is attached on AC adapter for too long. The fan is probably a simple i2c device the kernel could control directly without jumping through ACPI hiding layer hoops. But the X86 people hold the view it is better to trust the firmware engineer to control devices instead of having the kernel folk to write device drivers to ... control devices!

Now on ARM(64) the idea of using ACPI is to have none of that.

Instead the idea is to use ACPI only to provide tables for enumerating what devices are available in the platform. Just like what device tree does. Now if this is the same as device tree, why bother?

The main reason is to allow the distribution installer behave same on X86 / ARM / ARM64. This is crucial for distributions like fedora and RHEL where a cabal holds the point of view that X86 distribution development must not be constrained by ARM support. But it also important for everyone that the method of installing your favorite distribution to an ARM64 server is standard and works the same for any server from any vendor. Now while UEFI and ACPI are definitely not my preferred solutions, I can accept them as necessary evil for having a more standard platform.

Monday, February 4, 2013

On behalf of aarch64 porters

Public service announcement

When porting GNU/Linux applications to a new architecture, such as 64-Bit ARM, one gets familiar with the following error message:

checking build system type... x86_64-pc-linux-gnu
checking host system type... Invalid configuration `aarch64-oe-linux': machine `aarch64-oe' not recognized
configure: error: /bin/sh config.sub aarch64-oe-linux failed

This in itself is trivial to fix - run autoreconf or just copy in new versions of config.sub and config.guess. However, when bootstrapping a distribution of 12000+ packages, this becomes quickly tiresome. Thus we have a small request:

If you are an upstream of a software that uses autoconf - Please run autoreconf against autotools-dev 20120210.1 or later, and make a release of your software.

Aarch64 porters will be grateful as updated software trickles down to distributions.

This was the most discussed point during my FOSDEM talk "Porting applications to 64-Bit ARM".

Thursday, December 20, 2012

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ä.

Saturday, October 27, 2012

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.