Kohlmeisenbrut – Nachwuchs im Garten : Mühsam ernährt sich das …
Nach dem Regen…(1)
Kohlmeisenbrut – Nachwuchs im Garten : Nach dem Regen…
Füchse: Opfer im Straßenverkehr(1)
Kohlmeisenbrut – Nachwuchs im Garten : Füchse: Opfer im Straßenverkehr
Fritz!Box Firmware mit Freetz erweitern(6)
Dennis Komnenovic : Hi, Ich bin zwar kein Netzwerk-Admin, sondern...
Daria : ich wollte, dass Du schon ein wenig genauer wirst. Welche Dienste...
11. Augsburger Linux-Infotag 2012 (4)
Ofey : Also ich will nicht direkt behaupten, der Linux Tag sei schlecht...
Jumper : Es ist schwer, den Minecraft-Spieler sowie das geöffnete ICQ auf...
Klopapier für Linux-Hasser – jetzt bei NORMA!(5)
MacWomble : Klarer Fall von Fehlinterpretation: Warum für Linuxhasser? Bei...
Der Radiergummi der Tagesschau(8)
Hartmut : 100% d’accord! Kurz und knackig: Fehler 1: Auf Spekulation...
Bernd L. : Die Kritik an der Korrektur ist nachvollziehbar, aber ich...
Anonymus : Der Vorwurf kann nur die intransparente Korrektur sein....
ckuri : Was ist denn die genaue Kritik? Das die Tagesschau das vermeldet...
lsdev ist ein einfaches Werkzeug zum Anzeigen von Harwareinformationen. Dazu liest lsdev liest folgende Dateien aus dem Verzeichnis /proc aus…
/proc/ioports (I/O Addresses) /proc/interrupts (IRQ Channels) /proc/dma (Direct Memory Access Information)
…und fasst die Informationen dann in einer Übersicht zusammen. Hier ein verkürztes Beispiel:
Ein Notebook kann wegen seines geringen Stromverbrauchs auch als kleiner Heimserver fungieren, der mit SSH ferngewartet wird. Wenn die Administration des Servers über Secure Shell stattfindet, dann läuft das Display des Laptops den ganzen Tag und verbraucht völlig unnötig Energie.
Doch wie kann man das Display des Laptops abschalten?
Ein erster Ansatz wäre xset. Mit …
xset dpms force off
… kann man auf der grafischen Oberfläche den Monitor abschalten. Doch zwei Haken hat die Sache: Erstens erfordert dies eine grafische Oberfläche auf dem Server und die ist auf den meisten Servern nun mal nicht vorhanden. Und zweitens schaltet sich das Display nach der nächsten Mausberührung oder dem nächsten Tastendruck wieder an (und ich kann hier nur für meinen Jaunty Jackalope sprechen).
Die Lösung für einen Server ohne X heißt vbetool. Dieses kleine Programm führt BIOS Code aus, um den Status von Hardwarekomponenten zu ändern. Bei Ubuntu und Debian lässt sich das Tool über die Paketquellen installieren:
sudo apt-get install vbetool
Greife ich nun über meine Ubuntukiste per SSH auf den Server zu, schaltet der folgende Befehl den Monitor komplett ab (doch Vorsicht: wer dies ohne Fernzugriff tut, muss damit rechnen einen kalten Neustart machen zu müssen. [EDIT: warum eigentlich? Sich einzuloggen und den Befehl vor dem geistigen Auge einzutippen geht eigentlich auch ohne, dass man es sieht. Getestet - funktioniert ]). So, hier also der Befehl, um das Display abzuschalten:
vbetool dpms off
Nun ist Schicht im Schacht. Auch Tasteneingaben oder Mausbewegungen können das Display nun nicht mehr aus dem Schlaf reißen. Den nächsten Neustart überlebt die Einstellung allerdings nicht. Um das Display im laufenden Betrieb wieder einzuschalten, geben wir über SSH ein:
vbetool dpms on
Um das Display auch nach jedem Neustart außer Gefecht zu setzen, editieren wir die Datei /etc/rc.local (Ubuntu/Debian) und fügen den Abschaltebefehl “vbetool dpms off” einfach hier ein. Dann wird der Befehl bei jedem Wechsel in einen Multiuser-Runlevel (und dazu gehört auch der Neustart) ausgeführt.
Wieviele Watt bzw. Euro man mit dieser Methode sparen kann, werde ich in einem meiner nächsten Artikel beleuchten.
[UPDATE: Die von mir gemessene Stromersparnis betrug ca. 4 Watt, gemessen mit dem Haushaltsmessgerät von Brennenstuhl. ]
Verwandte Artikel:
Was Hardware im Standby verbraucht
Wer braucht mehr Strom: Ubuntu oder Vista?
Infos über Laptopakkus aus dem Verzeichnis /proc
Gerade auf Systemen mit mehreren Partitionen oder Festplatten kann man schnell den Überblick verlieren, was auf welcher Partition zu Hause ist.
Sind die Partitionen nicht mit aussagekräftigen Labels (“Filesystem volume names”) belegt, kann dies die Wartung und das Management eines Dateisystems erheblich behindern. Im Extremfall, z.B. beim Löschen einer scheinbar nicht mehr benötigten Partition, kann dies sogar zu Datenverlust führen. Im Folgenden wird beschrieben, wie man sich Labels von Dateisystemen anzeigen lässt und wie man diese manipulieren kann. (Bild: Open Clip Art Library, public domain)
Zunächst wollen wir wissen, ob eine Partition (hier: /dev/sda7) bereits mit einem Label ausgestattet ist. Dies können wir z.B. mit dem Befehl tune2fs und der Option -l (wichtig: kleines “l”!) erreichen:
sudo tune2fs -l /dev/sda7
tune2fs 1.41.4 (27-Jan-2009)
Filesystem volume name: jaunty-home
(Ausgabe verkürzt)
Um uns diese Information für alle Partitionen anzeigen zu lassen, befragen wir blkid:
sudo blkid
bill@testbox:~$ sudo blkid
[sudo] password for bill:
/dev/sda1: UUID="(...)" TYPE="ntfs"
/dev/sda2: UUID="(...)" LABEL="winrec" TYPE="ntfs"
/dev/sda5: UUID="(...)" TYPE="ext3" LABEL="jaunty-tmp"
/dev/sda6: TYPE="swap" UUID="(...)"
/dev/sda7: UUID="(...)" TYPE="ext3" LABEL="jaunty-home"
/dev/sda8: UUID="(...)" TYPE="vfat" LABEL="media"
/dev/sda4: UUID="(...)" TYPE="ext3"
(Ausgabe verkürzt)
Nun wollen wir die Partition /dev/sda4, die bisher kein Label hat, mit einem ausstatten. Hierzu ziehen wir wieder tune2fs heran, diesmal mit einem großen “L” (L=Label). Auf dieser Partition lagert das Verzeichnis /var von Jaunty und dies wollen wir auch kenntlich machen:
sudo tune2fs -L jaunty-var /dev/sda4
Das selbe Resultat können wir auch mit dem Befehl e2label erreichen:
sudo e2label /dev/sda4 jaunty-var
Nun noch schnell prüfen, ob bei /dev/sda4 das neue Label angekommen ist:
sudo blkid | grep jaunty-var
/dev/sda4: UUID="(...)" TYPE="ext3" LABEL="jaunty-var"
Es gibt sicher noch weitere Möglichkeiten, Volume Labels zu managen. Da die Tools auf der Kommandozeile universell verfügbar sind und ein X-Server nicht immer zur Verfügung steht, wird an dieser Stelle auf grafische Frontends nicht eingegangen. Hinweise zu grafischen Frontends werden gerne in den Kommentaren entgegengenommen.
Wer schon mal eine Maschine mit mehreren Netzwerkkarten in ein Netzwerk integriert hat, kennt vielleicht das Problem: Welche RJ45-Buchse entspricht nun eth0, eth1 und eth2?
Wie kann man die Schnittstellen möglichst schnell zuordnen? Der folgende Befehl bringt die Netzwerkkarte eth0 für 30 Sekunden zum Blinken und identifiziert sie eindeutig, ohne Kabel zu stecken und groß herumzupingen (erfordert root-Rechte):
ethtool -p eth0 30
Um diese Methode für alle drei Karten in einem Aufwasch anzuwenden, verwenden wir die folgende Befehlskette (Jede Schnittstelle soll 15 Sekunden blinken, dann geht’s weiter zur nächsten):
for NIC in eth0 eth1 eth2; do echo "Jetzt blinkt $NIC"; ethtool -p $NIC 15; done
Auf diese Methode aufmerksam geworden bin ich durch diesen Blogeintrag.
Bildlizenz: Public Domain
Wikimedia (Lizenz: GPL2)
Hardware im Standby verbraucht offenbar mehr Strom, als viele Menschen vermuten. In einem vorangegangenen Artikel hatte ich untersucht, ob es einen Unterschied im Stromverbrauch bei Suse, Ubuntu und Vista gibt. Dieser Artikel befasst sich mit der Frage, wieviel Strom gängige Hardwarekomponenten im Standbymodus verbrauchen. Zum Einsatz kam wieder das Messgerät Brennenstuhl PM230. Untersucht wurden 2 verschiedene Notebookmodelle, ein komplettes Desktopsystem (inklusive PC, Flachbildschirm, Drucker), sowie eine externe Festplatte. Die gemessenen Werte können natürlich nur grobe Anhaltspunkte geben; andere Modelle können von den von mir gemessenen Werten abweichen. Mit “Standby” meine ich den Zustand eines Geräts, das im ausgeschalteten Zustand per Netzkabel an die Stromversorgung angeschlossen wird.
Messergebnisse: Offenbar verbrauchen PCs erheblich mehr Watt im Standby als Laptops. Meine Kiste zumindest brachte es jedenfalls auf stattliche 16 Watt, während die beiden Laptops sich mit je mageren 2 Watt zufrieden gaben. Ein Medion Flachbildschirm wurde im Standby mit immerhin 7 Watt Verbrauch gemessen. Ein Drucker (HP C5280) kam auf 14 Watt. Eine externe Festplatte (Toshiba) zog durch den Adapter im ausgeschalteten Zustand 4,5 Watt. Das komplette Desktopsystem mit PC, Drucker, Flachbildschirm und externer Festplatte müsste im Standby also (theoretisch) 16+7+14+4,5=41,5 Watt verbrauchen. Die tatsächliche Messung aller Komponenten gemeinsam ergab schließlich ca. 36 Watt. Ich bin kein Elektriker und kann den Unterschied nicht erklären. Vielleicht kann der Leser zur Aufklärung beitragen.
Die Kosten: Gehen wir davon aus, dass das getestete System 1 Jahr an eine reguläre Steckleiste (ohne roten Kippschalter) angeschlossen wäre. Wenn die KWh 37 Cent kostet, wieviel würde ein solches Desktopsystem im Standbymodus in einem Kalenderjahr verbrauchen? Insgesamt würden 315,36 KWh verbraucht. Dies würde mich die Summe von 116,68 Euro kosten!
Ein nicht ganz unerheblicher Betrag, den ich da zu blechen hätte, alleine dafür, dass meine Hardware REIN GAR NICHTS tut! Wem das egal ist, der geht halt einen Tag im Jahr (wenn`s langt!) nur dafür auf die Arbeit, damit er seine Hardware fürs Nichtstun bezahlen kann. Zum Glück habe ich schon längst Steckleisten mit Kippschalter im gesamten Haushalt eingeführt und nutze fast nur noch Laptops. Es muss ja nicht gleich mit dem buzzword Green IT daherkommen; aber beim Standbybetrieb besteht auf jeden Fall erhebliches Potenzial, Kosten zu sparen und die Umweltverschmutzung zu reduzieren. 2 Steckleisten mit Kippschalter und je 8 Steckplätzen gibt`s schon ab 5 Euro bei IKEA.
In einem weiteren Beitrag möchte ich mich dann in den nächsten Tagen noch der Frage zuwenden, was Hardwarekomponenten im Betrieb verbrauchen (hier kommt dann auch der Router zum Zug). Nur so zum Spaß (da ich sie eh alle gemessen habe), werde ich dann auch einige Ergebnisse über Haushaltsgeräte wie Fön, Funktelefon und Wasserkocher veröffentlichen…
James Watt (1736-1819)
Gibt es Unterschiede im Stromverbrauch zwischen einzelnen Betriebssystemen oder sind diese nur marginal? Um diese Frage zu beantworten, habe ich mir für 20 Euro das Energie-Messgerät PM230 von Brennenstuhl gekauft, um die Probe aufs Exempel zu machen. Das Gerät hat nach Herstellerangaben ein Messgenauigkeit mit einer Fehlertoleranz von max. 5%. Unter gleichen Bedingungen konnte ich allerdings ziemlich exakt die gleichen Messergebnisse reproduzieren.
Der Testaufbau: Um die Betriebssysteme unter möglichst gleichbleibenden Bedingungen zu testen, wurde ein Multibootsystem verwendet (Ubuntu 9.04, Suse 11.0, Windows Vista). Getestet wurde auf einem Laptop HP Pavilion dv6000 mit 1GB Arbeitsspeicher. Der Prozessor war ein Intel Core 2 (T5500, 1.66GHz). Als Grafikkarte kam eine Nvidia Geforce Go 7400 zum Einsatz. Getestet wurden auf jedem System der Verbrauch in Watt unter 2 Bedingungen. Zunächst wurde das System im “Leerlauf” getestet, d.h. nach dem Booten (ohne laufende Anwendungen). Jedes System wurde nach dem Booten 10 Minuten nicht angelangt, so dass alle Initialisierungen abgeschlossen waren und das Gerät einen konstanten Wattverbrauch anzeigte.
Grenzen des Tests: Neben der Messtoleranz ist dieser Test sicherlich dadurch begrenzt, dass die Systeme eine unterschiedliche Geschichte aufweisen. Es wurden hier Systeme verglichen, die verschieden lang in Benutzung waren, wobei Ubuntu das meistgenutzte (aber erst vor einem Monat aufgesetzte System war, während Vista das am seltensten genutzte System war. Alle 3 Systeme sind als typische Endnutzersysteme konfiguriert (ohne dass darauf besondere Dienste laufen würden). Nun aber ran an die Messwerte!
Stromverbrauch im ausgeschalteten Zustand: Zunächst habe ich (systemunabhängig) gemessen, ob der Laptop auch Strom verbraucht, wenn er zwar ausgeschaltet ist, aber mit dem Netz verbunden ist. Tatsächlich verbraucht der Laptop auch hier Strom, nämlich 2,3 Watt. Wäre das Gerät also für ein Jahr in einer normalen Steckdose eingestöpselt, würde es, ohne je einmal im Betrieb zu sein, rund 20 Kilowattstunden verbrauchen. Bei einem Strompreis von angenommenen 37 Cent/kWh würde uns dieser Spaß ca. 7,50 Euro kosten. In einem späteren Artikel werde ich weitere Messergebnisse (Acer Aspire, Drucker, WLAN-Router, externe Festplatte, Desktop PCs) veröffentlichen. Soviel sei schon verraten: Mein HP ist – wie James Watt – ein richtiger Schotte. Andere Hardwarekomponenten verbrauchen locker das 4 bis 5fache beim Nichtstun!
Stromverbrauch im “Leerlauf”: Ubuntu Jaunty Jackalope verbrauchte im gebooteten Zustand ohne laufende Anwendungen im Mittel ca. 36,5 Watt. Suse 11.0 kam im Mittel auf ca. 36,7 Watt. Vista verbrauchte auch ca. 36,7 Watt. Man kann also getrost sagen, dass alle drei Betriebssysteme in meinem Test im Leerlauf in etwa die gleiche Menge Strom verbrauchten. Erwartet hatte ich eigentlich, dass Vista am meisten verbraucht. Zum Spaß habe ich dann noch eine Puppy 2.11 Live-CD gebootet. Auch Puppy brauchte im Leerlauf ca 36,5 Watt.
“Suspend to RAM”: Auch in diesem Test kam es zu keinen nennenswerten Unterschieden. Sowohl Ubuntu, als auch Vista verbrauchten in diesem Zustand knapp 7 Watt. Bei Suse ließ sich dieser Zustand überhaupt nicht herstellen. Der Versuch endete mit einer Fehlermeldung.
Fazit: In Bezug auf den Stromverbrauch im Leerlauf und im suspend-to-ram weisen die getesteten Systeme keine nennenswerten Unterschiede auf. Eine interessante Erkenntnis ist sicherlich , dass auch abgeschaltete Geräte Strom verbrauchen können. Welche Hardwarekomponenten im Standby richtige Stromfresser sind und welche Komponenten wieviel im laufenden Betrieb verbrauchen wird der Gegenstand eines meiner nächsten Artikel sein.
Link: Stromverbrauch von Laptopakkus unter Linux
Dieser Artikel beschreibt, wie man auf Ubuntu 9.04 eine SD Card zur Installation von Android auf Freerunner erkennt, partitioniert und mit den korrekten Dateisystemen ausstattet.
Partitionieren für Android
Diese Anleitung sollte größtenteils auch für andere Betriebssysteme gültig sein und bezieht sich auf die Installation auf den internen Flash des Freerunner. Die zweite Möglichkeit, Android direkt auf die sd card zu installieren, wird hier im englischen Wiki beschrieben. Den Vorgang des Flashens an sich habe ich bereits in einem früheren Artikel beschrieben. (Bildquelle: Wikimedia – Lizenz:Creative Commons Attribution ShareAlike 2.0)
Einstieg
Anders als bei Open Moko images benötigt eine Installation von Android auf Freerunner zwei Partitionen: Die erste Partition (/dev/mmcblk0p1) muss im Format FAT sein. Auf dieser Partition (später als /sdcard gemountet) werden all die schönen Bildchen, mp3s und andere Daten landen. Android benötigt eine zweite Partition (/dev/mmcblk0p2, später als /data gemountet), um betriebssystemspezifische Android-Daten zu speichern (Format: ext3).
SD Card erkennen
Zunächst überprüfen wir ob die SD Card überhaupt von unserem Desktopsystem erkannt wird und wie sie bezeichnet wird. Wir müssen die SD Card also über irgendeine beliebige Schnittstelle (hier: SD Card Slot) für Jaunty zugänglich machen. Nach dem Einstecken in den SD Slot poppt bei meinem Jaunty ein Fenster auf, wodurch ich weiß, dass die Karte von Ubuntu erkannt wurde. Um mehr Infos zu erhalten nutze ich auf der Kommandozeile ein ` dmesg |tail ‘ :
# dmesg | tail
[ xxxx.xxxxxx] mmc0: new SDHC card at address 8fe4
[ xxxx.xxxxxx] mmcblk0: mmc0:8fe4 SU08G 7.40 GiB
Meine “8 GB” Karte trägt also die Gerätebezeichnung /dev/mmcblk0 und wird mit 7,4 GB Fassungsvermögen angegeben.
SD Card partitionieren
Mit fdisk kann man die SD Card partitionieren und eigentlich auch die entsprechenden Dateisysteme erstellen. Während auf meiner 2GB SD Card fdisk beide Aufgaben mit Bravour gelöst hat, funktionierte dies bei meiner 8GB Karte nicht. Die Dateisysteme wurden zwar scheinbar korrekt angelegt. Doch weder erkannte Android später das Dateisystem (Bootvorgang abgebrochen), noch erkannte 9.04 die Dateisysteme. Die Lösung war schließlich, mit fdisk zu partitionieren und mit mkfs die Dateisysteme anzulegen. Wir starten fdisk also mit:
sudo fdisk /dev/mmcblk0
Wir legen die erste Partition als FAT an, die zweite als ext3. In meinem Fall legte ich die erste Partition als FAT16 mit 3 GB an. Für die Android-Partition spendierte ich großzügige 312 MB. Hier einige fdisk Optionen:
m zeigt alle Optionen an
d löscht eine Partition
n legt eine neue Partition an
t ändert den Dateisystemtyp einer Partition
p zeigt die Partitionstabelle an
q beendet fdisk ohne zu speichern
w beendet fdisk und speichert alle Änderungen unwiderruflich
Dateisysteme anlegen:
Nun wollen wir der ersten Partition ein FAT16 Dateisystem verpassen, welches zur späteren besseren Erkennung das label “fat_andr” (Bezeichnung frei wählbar) tragen soll. Wer FAT32 will, nimmt die Option “-F 32″: sudo mkfs.vfat -n fat_andr -F 16 /dev/mmcblk0p1 Analog dazu erstellen wir nun ein ext3 auf der zweiten Partition mit dem label “sys_andr”: sudo mkfs.ext3 -L sys_andr /dev/mmcblk0p2 Fertig!
Android installieren/flashen:
Nun können wir die SD Card an Freerunner übergeben und Android durch Flashen mit dfu-util installieren. Sehr nützlich ist auch das englische Wiki (siehe links weiter unten), ohne das dieser Artikel sowieseo nie zustande gekommen wäre. Ein deutschsprachiges Forum zu Android auf Freerunner gibt es bei freeyourphone.de
http://linuxnetz.wordpress.com/2009/05/05/android-auf-freerunner-einstieg-und-usb-networking/
http://wiki.openmoko.org/wiki/Android_on_Freerunner#On_Linux
http://wiki.openmoko.org/wiki/Android_on_Freerunner#Installing_Android_on_an_SD_card
http://www.freeyourphone.de/portal_v1/viewforum.php?f=18
Nachdem ich mich in zwei früheren Artikeln mit dem Flashen des Freerunner sowie Zugang per OpenSSH (OM und FDOM) befasst habe, wende ich mich in diesem Artikel der Plattform Android auf dem Openmoko Freerunner zu.
INSTALLATION:
Um Android auf Freerunner zu installieren, muss die SD Karte mit 2 Partitionen formatiert werden (eine FAT und eine EXT3). Außerdem habe ich den Qi Bootloader installiert. Die genauen Anleitungen zur Vorbereitung der Karte und der Installation durch Flashen des Freerunner sind im Wiki Android on Freerunner beschrieben. In meinem Fall kamen Michael Trimarchi`s Images zum Einsatz (http://panicking.kicks-ass.org/download/): freerunner-v14.6.jffs2 (als root fs) und uImage-v17.bin (als kernel image). Das Partitionieren erwies sich als die einfachere Übung. Mit der Ausnahme, dass die im Wiki beschriebene Formatierung der SD Card mit mkfs für die FAT-Partition fehlschlug. Stattdessen machte fdisk die FAT16 Partition ohne zu Murren. Das Flashen der Images per USB-Anschluss erfordert das Tool dfu-util. Auf Ubuntu 9.04 kann dies über die Paketquellen bezogen werden. Das Flashen erfolgte dann nahezu problemlos (bei Problemen der Erkennung von devices siehe auch: Flashen des Freerunner). Android bootete zwar, das Touchpad funktionierte jedoch erst nach der dritten Installation. Keine Ahnung warum.
[EDIT: Mehr Infos zur Installation auf die SDCard gibt es in einem später erschienenen Artikel: Freerunner (Android): SDCard für Installation vorbereiten]
ERSTE POSITIVE EINDRÜCKE:
Mein erster Eindruck von Android war durchaus positiv. Nach 2 Tagen Android kann ich sagen: Vom look and feel ist Android (im Vergleich zu den von mir bis dahin getesteten Distros) eine Klasse für sich. Optisch sehr ansprechend, fingerfreundlich und intuitiv zu bedienen. Es bootet relativ zügig (im Vergleich zu OM und FDOM) und läuft bis jetzt sehr stabil. Die vorinstallierte Menüauswahl und die Optionen zur Konfiguration sind groß. Sehr praktisch ist, dass man AUX und POWER zur Navigation verwenden kann. AUX schließt die zuletzt gestartete Anwendung, POWER öffnet ein Menü.
ERSTE NEGATIVE EINDRÜCKE:
Als erstes habe ich versucht, WLAN (über settings >> Wifi settings) aufzusetzen. Mein heimisches Netz wurde zwar erkannt und ich kam mühelos zum Dialog, um das Passwort einzugeben. Aber wie? Zwar kann man mit einem kurzen Druck auf POWER über ein Menü ein keyboard herzaubern, doch diese liegt später unter dem Wifi-dialog und kann nicht benutzt werden. Hier habe ich mich das erste Mal nach FDOM zurückgesehnt…
Dasselbe Problem gilt für die Eingabe der PIN der SIM-Card. Keine PIN-Eingabe ohne Tastatur. Damit ich erst mal erreichbar bleibe, habe ich die SIM-Card in mein altes Telefon gesteckt und die PIN einfach deaktiviert…
Ein allgemeines Problem bei Freerunner scheint die Lautstärke beim Empfang von Telefonaten zu sein. Auch bei Android hätte ich es gerne ein, zwei Stufen lauter.
USB-NETWORKING PER ADB (SHELL)
Für das Keyboardproblem scheint es zwar einen workaround zu geben, bei dem ein tool installiert wird, um Textinhalte per copy und paste einzufügen. Diesem habe ich mich aber noch nicht zugewendet (und habe auch den link des Forenthreads verloren). Ich versuche die Dinge lieber mit einer shell per USB-Networking zu lösen. Mag Android optisch noch so ansprechend gestaltet sein – ein Zugriff per shell auf das Dateisystem ist einfach unersetzlich zur Konfiguration. Sonst kann man sich gleich ein x-beliebiges Sony Ericsson kaufen (Oh! Nein!). Und so geht`s:
Für den Shellzugriff über einen PC nutzt man adb. Zunächst sollte man das binary von adb herunterladen und innerhalb von PATH ablegen. Shellzugriff erfordert einen reboot des Freerunner. Beim Neustart muss der Freerunner bereits per USB-Kabel mit dem Rechner verbunden sein. Im folgenden Beispiel wurde Ubuntu 9.04 genutzt. Sollte es Probleme geben, kann es helfen, WLAN abzuschalten. An Stelle der Schnittselle eth1 kann es durchaus sein, dass diese usb0 oder sonst irgendwie heißt. Freerunner hat als Standard IP-Konfiguration 192.168.0.202. Zunächst muss also die Schnittstelle so konfiguriert werden, das sie im selben Netzwerk liegt:
sudo ifconfig eth1 192.168.0.200 netmask 255.255.255.0
Dann müssen folgende Befehle ausgeführt werden:
adb kill-server
ADBHOST=192.168.0.202 adb devices
Es ist ein gutes Zeichen, wenn man darauf eine Ausgabe wie die folgende erhält:
* daemon not running. starting it now *
* daemon started successfully *
List of devices attached
emulator-5554 device
Nun kann die shell auf dem Freerunner gestartet werden
adb shell
Voila! Fernzugriff per Ubuntu-Desktop auf Freerunner (mit Android).
FAZIT:
Ob Android mein bevorzugtes System auf Freerunner wird, ist fraglich. Unter FDOM liefen WLAN und GPS, eine Tastatur war immer zur Verfügung. Schauen wir mal, wie es mit Android weitergeht. Schließlich stehe ich ja erst am Anfang meiner Android-Expedition. Dies ist nur mein persönlicher Erfahrungsbericht. Über Hinweise, Ergänzungen usw. würde ich mich freuen.
Am Anfang war der Computer – und zwar ohne Maus. Text wurde über Tastaturen auf flimmrige Bildschirme geschickt. Keine Spur von graphischen Anzeigegeräten.
Quelle: Wikimedia (Lizenz: GFDL v1.2)
Erst um 1963/64 begann ein Team um Doug Engelbart und William English am Stanford Research Institute mit der Entwicklung eines Anzeigegerätes, das zunächst den sperrigen Namen “X-Y-Positions-Anzeiger für ein Bildschirmsystem” trug. Auch bei Telefunken in Deutschland wurde -in etwa zur selben Zeit – an (der späteren) “Maus” geforscht. Die Telefunken-Maus funktionierte bereits mit dem Prinzip der Rollkugel und wurde 1968 – einige Wochen vor Engelbarts Maus – der Öffentlichkeit präsentiert.
Am 9.12.1968 stellte das Forscherteam um Doug Engelbart seine Forschungsergebnisse rund 1000 Computerexperten auf der Fall Joint Computer Conference in San Francisco vor. Von dieser Präsentation existiert ein run 100-minütiges höchstinteressantes Video, das in 35 kleine Clips zerschnitten ist und hier angesehen werden kann. Wer das tatsächliche Stück Hardware “Maus” zu Gesicht bekommen will, der kann sich z.B. Clip 3 ansehen.
http://www.heise.de/newsticker/Auf-den-Spuren-der-deutschen-Computermaus–/meldung/136901
http://sloan.stanford.edu/MouseSite/
http://de.wikipedia.org/wiki/Maus_(Computer)#Geschichte
(Verwandter Artikel: Mit Smartmontools die Gesamtlaufzeit einer Festplatte ermitteln)
Lizenz: GNU Free Documentation License
EINSTIEG: Oft kündigt sich so ein Absturz z.B. durch ungewöhnliche Geräusche an. Mit smartmontools kann man überprüfen, ob sich die Festplatte in einem kritischen Zustand befindet und ob die Platte bald das Ende ihrer Lebensdauer erreicht haben könnte. Der Software zu Grunde liegt SMART (Self Monitoring, Analysis and Reporting Technology). SMART ist eine systemübergreifende Analysesoftware, die fest in der Firmware fast aller moderner Festplatten integriert ist. Hier belegt SMART einen kleinen Bereich, der nicht überschrieben werden kann.
INSTALLATION: Auf den meisten Linuxsystemen sind smartmontools nicht standardmäßig installiert. Unter Ubuntu installiert man das Paket per Synaptic oder mit:
sudo apt-get install smartmontools
Das Paket smartmontools besteht aus dem Befehl smartctl und dem Daemon smartd. Im Folgenden soll ein typisches Nutzerszenario für den manuellen Check mit smartctl (auf Ubuntu) dargestellt werden (für die Platte: /dev/sda). Nicht näher eingegangen wird auf smartd, ein Daemon, der die Festplatte regelmäßig checkt, die Ergebnisse loggt und bei kritischem Zustand per email den Admin alarmieren kann.
AKTIVIERUNG: Obwohl SMART auf den meisten modernen Platten integriert sein sollte, muss es nicht zwangsläufig aktiviert sein – so könnte z.B. eine entsprechende Einstellung im BIOS dies verhindern. Nach der Installation von smartmontools wollen wir also zunächst herausfinden, ob SMART überhaupt aktiviert ist (benötigt root-Rechte):
Sollte SMART auf /dev/sda zwar verfügbar (“available”), aber nicht aktiviert (“disabled”) sein, können wir dies manuell nachholen:
BASISCHECK:
Hier gibt es mehrere Variationen. Um einen schnellen Check der Platte durchzuführen, verwendet man:
ERWEITERTER CHECK: Nun wollen wir aber doch eine detaillierte Auflistung der Fähigkeiten dieses Festplattenanalysetools. Welche Attribute kann smartmontools erfassen? Welche aktuellen Werte hat unsere Festplatte? Ab welchem Wert wird es kritisch? Die Antwort auf diese Fragen liefert:
ATTRIBUTE_NAME beschreibt die untersuchte Eigenschaft
VALUE beschreibt den gemessenen Wert
WORST beschreibt den schlechtesten jemals gemessenen Wert
THRESH beschreibt den Wert, ab dem Besorgnis gelten sollte
Beispiel:
Bedenklich in diesem Beispiel ist das Attribut Seek_Error_Rate. Gemessen wurde ein Wert unter 100, in der Vergangenheit wurden sogar einmal nur 72 gemessen. Ab 67 kann ein Ausfall der Festplatte drohen.
GRÜNDLICHER CHECK:
Nun wollen wir unsere Platte einem ausführlicheren Test unterziehen, wobei auch die Mechanik und der Datendurchsatz getestet werden. Zur Verfügung stehen uns ein Selbsttest in der Kurzform oder in der ausführlichen Form. Um mehr (auch über die die erwartete Dauer der Tests) herauszufinden geben wir ein:
Der Kurztest würde also 2 Minuten dauern, der lange self-test ca 53 Minuten. Um den Kurztest zu starten, verwenden wir:
Analog dazu würden wir den ausführlichen Check durchführen mit:
TESTERGEBNISSE ABRUFEN: Während des Test schreibt die Software die Ergebnisse in eine Logdatei. Um das Testergebnis aufzurufen, verwendet man:
Beispiel:
smartmontools funktioniert nicht auf externen USB-Platten. Es wird auch nicht jeden Festplattenabsturz zuverlässig voraussagen können. Um eine gewiefte Backupstrategie wird man also trotz smartmontools nicht herumkommen.
LINKS:
http://smartmontools.sourceforge.net/
http://wiki.ubuntuusers.de/Festplattenstatus
http://de.wikipedia.org/wiki/Self-Monitoring,_Analysis_and_Reporting_Technology
Artikel