OLPC
Nun bin ich im Besitz eines OLPCs. Die Hardware ist atemberaubend! Die Software hingegen ist nett, aber noch vom Praktikablen entfernt. Alles darueber kann man schon auf http://www.laptop.org/ lesen.
Das Problem bei der Software ist, dass sie teilweisze in Python geschrieben ist. Es hat nichts damit zu tun, dass ich Python nicht mag, sondern damit, dass Python viel Arbeitsspeicher benoetigt und auch viel CPU-Zeit. Jegliche Scriptsprachen in solchem Umfang sind auf solch kleinen Geräten nicht zu empfehlen.
Deswegen werd ich als nächstes Ubuntu oder Debian installieren.
Die Oberfläche sieht zwar ganz simpel aus, dass man glaubt, dass es ganz klein ist, aber wenn man drunter schaut, entpuppt sie sich als ein ungewoehnlich speicherhungriges Vieh.
Viele Dinge von Sugar - die grafische Oberfläche - sind in python geschrieben. Wenn nicht sogar alles. Das merkt man auch sehr schnell, denn alles ist extrem langsam und mehrere Programme zu starten bremst alles aus.
Dabei ist das nicht die Schuld der CPU, sondern einzig und allein, dass python verwendet wurde. Hätte man sich etwas mehr Zeit genommen und hätte zumindest die Bibliotheken in C++ zB. geschrieben, wäre das wesentlich besser gewesen.
| GUI | RAM-Verbrauch in MB |
|---|---|
| Ohne | 36 |
| Sugar | 94 |
| XFCE4 | 74 |
RAM-Verbrauch mit verschiedenen grafischen Oberflächen auf einem Fedora OLPC 703
Statt eines klassischen init-Prozesses wird auf eine eigene Implementation gesetzt, die die Sicherheit erhöhen soll. Sie gehört zu BitFrost, des Sicherheitsframeworks. Dennoch kommt SysVInit zum Einsatz, aber hat nicht die PID 1.
Und hier die größten Speicherfresser, die mehr als 1% RAM benötigen:
X und matchbox sind dabei die einzigen Programme von dieser Liste, die nicht in python geschrieben wurden. Dass X soviel RAM benötigt, ist Ok. Bei matchbox mache ich mir schon ein paar Gedanken. Aber alle die noch mehr RAM benötigen könnte man sehr wohl ersetzen; das muss echt nicht sein, besonders wenn sie schon das siebenfache von X benötigen.
Und bisher wurde wirklich nicht einmal ein Programm gestartet. Wenn also noch andere Programme hinzukommen, dann der RAM ganz schnell voll.
Opera zeigt das Gegenteil: Schnell, wesentlich mehr komfort und Funktionen und dennoch weniger RAM-Verbrauch: 3,9%. Ist halt nicht in Python geschrieben.
Übrigens: yum – das apt-get für RPM-basierte Systeme – ist ebenfalls in Python programmiert und es kommt oft vor, dass yum nicht richtig funktioniert, weil es zuviel RAM benötigt und nicht bekommt. Das ist nicht direkt sichtbar, wenn das Problem besteht, man bekommt nur eine harmlose Meldung, dass %PRE oder %POST fehlschlug und bedeutet, dass unter Umständen was gravierendes passiert ist.
Zwar mag ich weder Gnome noch GTK, aber xfce4 basiert nur auf GTK und sieht ganz nett aus. Und GTK ist nicht ganz so schlimm wie Gnome. ;)
Es ist sehr schnell gestartet, besonders wenn man es mit Sugar vergleicht und bietet sehr viel Komfort.
Leicht zu bedienen ist es ebenfalls, wenn auch für die Kinder der dritten Welt, für die Sugar extra programmiert wurde, nicht so gut geeignet.
Aber für uns Geeks ist es eine gute Wahl. Es wurde mir sowieso vom Verkäufer, dem ich dieses abkaufte, empfohlen.
Neben XFCE4 läft auch Enlightenment 0.17 prima auf meinem OLPC. Sogar mit den Animationen gibt es keine Probleme.
Allerdings ist die Software noch nicht stabil, also sollte man noch mit Problemen rechnen. Einen reproduzierbaren Fehler hab ich bereits entdeckt, der aber auch schon bereinigt wurde.
Es sieht einfach noch super aus!
Man muss nicht, aber man kann die Umgebung vom OLPC auf einen anderen Rechner kopieren und dort Programme kompilieren. Setzt vorraus, dass sshd auf dem OLPC installiert ist und root via ssh erlaubt ist.
$ rsync -aP root@OLPC:/versions/running/ .
/dev fehlt allerdings und sollte kopiert werden:
$ cp -a /dev .
Nun kann man diese Umgebung nutzen:
$ chroot
C$ mount /proc
C$ mount /sys
Nicht vergessen, wenn man fertig ist:
C$ umount /proc
C$ umount /sys
C$ exit
Diese Anleitung setzt die OLPC-Umgebung vorraus. Ob auf dem OLPC oder nur ein chroot ist egal. chroot hat den Nachteil, dass Handarbeit gefragt ist, da uname -r was anderes ausspuckt als wir gern hätten.
Module lassen sich kompilieren, wenn man kernel-devel installiert hat. Problem ist aber, dass dieses Paket dann die falsche Version ist, daher muss man die Datei /etc/yum.repos.d/olpc-koji-update1.repo anpassen: Man fügt zum exclude das Paket kernel-devel hinzu.
Nun kann man das Paket installieren und anschließend Module gegen den Kernel kompilieren.
Ich habe bereits ein Hilfsmittel programmiert.
Diese sollten, wenn nicht anders angegeben, auf allen Systemen funktionieren, nicht nur mit Fedora.
Dieses Programm erlaubt es, die Hintergrundbeleuchtung einzustellen.
Es gibt zwar auch die Möglichkeit einfach den Wert so zu setzen:
$ su -c 'echo N > /sys/class/backlight/dcon-bl/brightness'
(N steht für ein Wert zwischen 0 und 15. 0 bedeutet aus, 1 dunkel … und 15 ganz hell)
Allerdings ist diese Methode nicht sonderlich unmittelbar, da su so einiges noch überprüft.
Besser ist da ein Programm zunehmen, welches man aufrufen kann ohne root zu sein. Das suid-Bit hilft weiter. Scripte in bash oder python sind nicht möglich, da das suid-Bit bei diesen nicht greift.
Daher hab ich dieses Programm geschrieben, welches recht schlank, flink und einfach zu bedienen ist.
Download:
Sourcecode kompilieren:
$ gcc -Os olpc-backlight.c -o olpc-backlight
Das Programm nach /usr/bin kopieren und Rechte setzen:
# cp olpc-backlight /usr/bin/olpc-backlight
# chown root:wheel /usr/bin/olpc-backlight
# chmod g+s /usr/bin/olpc-backlight
# ln -s olpc-backlight /usr/bin/backlight
Nun kann das Programm auch als normaler Benutzer benutzt werden, solange er in der Gruppe wheel ist:
$ backlight 15 # Ganz hell!
$ backlight 0 # Aus!
$ backlight 1 # An, aber nur ganz schwach
$ backlight + # Etwas heller (!= +1)
$ backlight - # Etwas dunkler (!= -1)
$ backlight +4 # 4 Stufen heller
...
Jetzt fehlt nur noch die Integration in Xfce4…
Ich verwende eine 2GB SD-Karte zum testen.
Anmerkung für mich selbst: Eine eigene SD-Karte für mein OLPC
Als Anleitung benutze ich diese Seite: http://eclecti.cc/olpc/ubuntu-mobile-on-an-olpc-xo
Allerdings läft dieser Computer mit Gentoo und ich muss qemu von Hand starten, da es kein qemulauncher gibt. Und zwar so:
qemu -cdrom mini.iso -hda /dev/sdc -net nic,macaddr=<MAC> -net user -m 256 -boot c
Oder wenn man eine Bridge schon eingerichtet hat, kann man dies ausnutzen:
sudo tunctl -b -u <USER> # gibt das <TAP>device zurueck
sudo brctl addif <BRIDGE> <TAP>
qemu -cdrom mini.iso -hda /dev/sdc -net nic,macaddr=<MAC> -net tap,ifname=<TAP>,script=no -m 256 -boot c
Die Installation auf SD-Karte hat funktioniert, doch war es nicht möglich, das System auf dem OLPC zu booten.
Installing_Debian_as_an_upgrade
Funktioniert! :)
Allerdings funktionieren viele Tasten nicht so, wie sie sollten. FN wird bis zur Shell geleitet und somit erzeugt es eine Tilde weil die Taste unbekannt ist.
Inzwischen habeich Debian direkt installiert und nicht als Upgrade. Dies läft perfekt und ist unproblematischer zu verwenden. XFCE4 ist wieder mein Window- und Desktopmanager.
Viel besser ist natürlich der Paketmanger! Ich empfehle jedem Debian statt Fedora zu verwenden. Es gibt keine Probleme beim installieren wie bei Fedora.
Ich habe nach einem passenden Browser gesucht, der alle Seiten vollständig darstellen können, natürlich exklusive Flash. Textbrowser fallen nicht darunter und sind sowieso unkritisch auf dem OLPC.
Werte kann ich momentan noch nicht angeben, auch die Anleitung, wie die jeweiligen Browser installiert werden, fehlen noch.
Zur Wahl hatte ich
Iceweasel lässt sich via apt-get installieren und fertig. Bei den anderen Zwei muss HAnd angelegt werden und erst das entsprechende Repository installiert werden, bzw. das Paket von Hand heruntergeladen werden.
Nach der Installation lassen sich alle 3 gleich starten.
Bisher kein Unterschied zu anderen Systemen.
Aber beim OLPC geht es um Resourcen und hier gibt es Unterschiede:
Zum Testen verwand ich nun meine Homepage und GMail gleichzeitig in je einem Tab.
Im Opera ruckelt alles und es dauert länger. Verwundert niemanden. Bei GMail ist das Scrollen unzumutbar langsam. Chrome ruckelt, aber schon nicht mehr so schlimm. Man kann durchaus mit leben. Allerdings beim Editieren eines Artikels auf meiner Homepage ist es bei Chrome nicht im geringsten m&oum;glich zu Scrollen. Tippen schon garnicht mehr. Im Opera hingegen funktioniert dies tadellos und flüssig.