Darktable and Nikon Z 30

Views: 175

Unfortunately the NEF format used by the Nikon Z 30 is not supported by Lightroom 6.0 (yes, that was the last version that I could actually buy and sort of own), so I tried Darktable. The Z 30 is not in the list of supported cameras, but the Z 50 is. And Nikon would not have changed the format within the Z cameras, now would they?

Trying to open one of the files results in error messages:

RawSpeed:Unable to find camera in database: 'NIKON CORPORATION' 'NIKON Z 30' '12bit-compressed'
Please consider providing samples on <https://raw.pixls.us/>, thanks!
[rawspeed] (xxx_0059.NEF) bool rawspeed::RawDecoder::checkCameraSupported(const rawspeed::CameraMetaData*, const string&, const string&, const string&), line 170: Camera 'NIKON CORPORATION' 'NIKON Z 30', mode '12bit-compressed' not supported, and not allowed to guess. Sorry.
[temperature] failed to read camera white balance information from `xxx_0059.NEF'!
[temperature] `NIKON CORPORATION NIKON Z 30' color matrix not found for image
[temperature] failed to read camera white balance information from `xxx_0059.NEF'!
[temperature] failed to read camera white balance information from `xxx_0059.NEF'!
[colorin] could not find requested profile `standard color matrix'!

The same goes for 14bit versions.

However, as the Z 50 is supported, I tried just changing the signature of the files. Darktable is fine with that and can load the files.

However, I do not know if that would lead to issues with eg. white balance or other processing which might be different for the Z-cameras. But it works for me and now. To change the signature of all files in the current directory, you can use:

perl -pi -e 's/NIKON Z 30/NIKON Z 50/g' *

As I found out later, it looks like there is already an issue logged in github regarding the Z 30. The solution described in there works for me – it is after all the same general idea: Z 30 and Z 50 files are essentially the same. If you add the definition to your cameras.xml file (which is at /usr/share/darktable/rawspeed on my system), darktable works with Z 30 files as expected.

Linux: warum geht meine Festplatte nicht in den Schlafmodus?

Views: 191

Ich habe mich nach langer Zeit wieder entschieden, dass einer meiner Server mit Gentoo laufen soll, statt mit Ubuntu. Im Zuge des Umbaus kam dann auch ein RAID mit netto 30 TB Speicherplatz zum Einsatz.

Ich möchte immer, dass meine Festplatten nur dann angeschaltet sind, wenn sie auch benutzt werden, daher setze ich gewöhnlich mit hdparm -S40 /dev/sd? einen sleep timeout von knapp 4 Minuten.

Nachdem ich alle notwendigen Daten auf das RAID kopiert hatte, blieben die Festplatten noch aktiv.

lsof brachte leider keine Erkenntnis, aber grob jede Sekunde schrieb irgendetwas auf das RAID. Ich bin dann auf laptop mode tools gestoßen, was ich mir auch mal näher ansehen muss. Das verspricht, dass ich Energieoptionen besser einstellen kann und auch, Festplattenaktivität besser analysieren kann.

Aber mit ps aux fiel mir dann noch der prozess ext4lazyinit auf. Dieser sorgt – sehr simple ausgedrückt – dafür, dass die eigentliche Formatierung der Platte im Hintergrund geschieht, und die Festplatte schon genutzt werden kann. Das ist auch schön so, aber ich hätte doch gerne, dass das bald vorbei ist.

Die Geschwindigkeit, in der ext4lazyinit arbeitet, kann mittels mount Optionen eingestellt werden (man 5 ext4):

   init_itable=n
          The lazy itable init code will wait n times the number  of  mil‐
          liseconds  it  took to zero out the previous block group's inode
          table. This minimizes the impact on system performance while the
          file system's inode table is being initialized.

Und das schöne hier ist, dass das im laufenden Betrieb gemacht werden kann:

mount -o remount,init_itable=0 <mount point>

Ich hoffe, das ist schon der einzige Prozess, der die Festplatten wach bleiben lässt, aber ich werde es sehen, wenn die Initialisierung wirklich durch gelaufen ist.

TBS5520SE – Multi-standard TV Tuner USB Box

Views: 1536

Die kleine Box in schwarzen Metall verspricht, alles an Fernsehsignalen empfangen zu können, was so hier verfügbar ist.

An der Frontseite 2 LEDs, einmal in blau, um zu zeigen, dass das Gerät arbeitet, und einmal in grün, damit wird angezeigt, dass auf der aktuellen Frequenz ein Sender gefunden wurde. Aber davon sagt die nicht wirklich vorhandene Anleitung nichts. Außerdem sind die LEDs viel zu hell, reine Funktionsindikatoren sollten leicht sichtbar, aber nicht grell sein. Neben einem Monitor aufgestellt stört die Helligkeit massiv. 

Die Box hat einen Antenneneingang sowie einen LNB-Anschluß und ein USB-2.0 Interface.

Das Gehäuse ist aus Metall und hat ein paar Lüftungsschlitze. Die Beschreibung sagt: “Neben der guten Ausstattung und dem modernen Interface wurde auch auf eine geringe Leistungsaufnahme und damit eine niedrige Abwärme, für geräuschlosen Betrieb, geachtet.”. Ein Lüfter ist sicher auch nicht notwendig, aber das Gerät wird schon warm, die Lüftungsschlitze sind gerechtfertigt und gut.

Empfangbar seien DVB-S / S2 / S2X, DVB-C / C2, DVB-T / T2 und ISDB-T. Und das passt auch wunderbar zum zentralen Chip in dem Gerät, dem Si21832B. Dieser dekodiert all diese Standards für uns.

Daneben gibt es noch einen CY7C68013A für die USB-Kommunikation. Außerdem ein paar Verstärker- und Logikchips, aber keine Überraschung.Kommen wir zu den Treibern. Diese können von der Webseite herunter geladen werden, im Lieferumfang ist kein Datenträger – der sowieso nur veraltete Versionen haben würde.

Ich habe zum Ansehen des Video-Streams den kostenlosen TBS-Viewer ausprobiert. Der Sendersuchlauf hatte mich direkt demotiviert. Der Empfangstyp war auf Satellit voreingestellt.

Ein Wechsel auf DVB-T (‘Terrestrisch’) setzt immer die Transponderliste “DMB-TH Hong Kong” als Standard.Ein Suchlauf (Korrekt auf Transponderliste: DVB-T2 Deutschland gestellt) lieferte keinen Sender, über die gesamte Frequenzliste hinweg. Spezifisches Scannen einzelner Frequenzen, die hier definitiv empfangbar sind und unverschlüsselte Sender übertrage (514 MHz und 706 MHz), lieferten auch 0 Sender. Den Grund dafür liefert die etwas schwache Anleitung: absolut wichtig ist TBS 5520 SE ChangeMode-Tool v1.0.0.2, mit diesem kann der Empfangsmodus geändert werden. Bei mir war der auf Satellit voreingestellt; nur mit diesem Tool kann auf DVB-T2 umgestellt werden.

Danach funktionierte dann auch der Suchlauf im TBS-Viewer. Allerdings ist die Empfindlichkeit des Empfängers eher mittelmäßig. Eine mickrige Antenne, die auch an einem Fernseher hier eher schwierigen Empfang liefert, die aber an einer Xoro-Box sehr gut funktioniert, liefert auch am TBS-5520 keinen befriedigenden Empfang. Vermutlich braucht man mit dem Gerät meistens eine aktive Antenne.

Zum Test wollte ich auch den kostenpflichtigen DVB-Viewer installieren – TBS Viewer lief noch – und erhielt die Fehlermeldung, dass DVB-Viewer noch liefe. Meine Vermutung ist da klar, dass der TBS-Viewer eine verfiesemantuckte Version des DVB-Viewers ist.

Also: es funktioniert alles, aber die Dokumentation stinkt schon anrüchig, und die Lösung des Empfangsumschaltens mittels des Change-Mode-Tools ist suboptimal. Technisch Interessierte werden keine Schwierigkeiten damit haben, aber es ist nicht gut.

Ein für mich wichtiger Kaufgrund war die Zusage “Treiber für sämtliche 32- und 64-bit Betriebssysteme befinden sich im Lieferumfang: Win XP, Vista, Win 7/8/10 und Linux.” “Sämtliche 32- und 64-bit Betriebssysteme” … MacOS ist schon einmal nicht dabei, somit ist sämtliche eine leere Versprechung. Linux ist ein verlockendes Versprechen für mich; ich will immer noch den Empfang von Fernsehen auf einem Raspberry Pi machen, und das Dekodieren dann auf anderen Clients. Leider unterstützt der Raspberry Pi h.265 nicht. Linux und sämtliche klingt wunderbar. ARM-Linux scheint da aber nicht wirklich drunter zu fallen.

Mehr zum Linux-Treiber später….

Eigener Mapserver mit Openstreetmap, Mapnik und OpenLayers

Views: 7688

Damit die Anfragen unserer Programme nicht immer die Openstreetmap-Server belasten, und ich damit mit besserem Gewissen auch ein paar Versuche durchführen konnte, habe ich mich mit Mapnik etwas auseinander gesetzt. Unter Switch2OSM gibt es schon Anleitungen, wie das umgesetzt werden kann, allerdings hatte ich die erst später gefunden. Und viele andere Informationen, die man so findet, sind falsch oder veraltet.

In dieser Anleitung finden Sie, wie Sie aus den Source-Dateien von mod_tile und vorkompilierten Paketen einen eigenen Tile-Renderer aufbauen können.

Zunächst die Vorbereitungen

Ubuntu 16.04 / 17.04

Alle benötigten Pakete sollten sich installieren lassen mit

$ sudo apt-get install libmapnik-dev mapnik-utils git subversion \
dh-autoreconf apache2-dev apache2 unzip postgis make cmake g++ \
libboost-dev libboost-system-dev libboost-filesystem-dev \
libexpat1-dev zlib1g-dev libbz2-dev libpq-dev libproj-dev \
lua5.2 liblua5.2-dev

Debian 8

Mapnik ist hier nur als Version 2.2 vorhanden. Da es dann Probleme mit Umlauten in der Karte geben kann, ist das keine valide Option. Daher müssen Pakete von Testing mit installiert werden. Da dies einiges im System auf neue Versionen updatet, ist diese Methode nicht für jeden empfehlenswert. Zum Testen kein Problem, aber auf Produktivsystemen ist die Gefahr, bestehende Funktionen zu zerstören, durchaus gegeben.

Also: Sie wurden gewarnt.

In /etc/apt/sources.list müssen die Testing-Quellen hinzu gefügt werden:

deb http://deb.debian.org/debian testing main contrib non-free

Und dann neu laden:

$ apt-get update

Mit dem Folgenden sollten sich alle benötigten Pakete installieren lassen:

$ apt-get install libmapnik3.0 libmapnik-dev mapnik-uitls subversion \ 
    unzip git dh-autoreconf apache2-dev apache2 cmake make cmake \ 
    g++ libboost-dev libboost-system-dev libboost-filesystem-dev \ 
    libexpat1-dev zlib1g-dev libbz2-dev libpq-dev libproj-dev lua5.2 \
    liblua5.2-dev postgresql postgis

Mapnik-Style

Als nächsten laden wir den Mapnik-Karten-Style:

$ mkdir ~/src
$ cd ~/src
$ svn co http://svn.openstreetmap.org/applications/rendering/mapnik mapnik-style
$ cd ~/src/mapnik-style
$ sudo ./get-coastlines.sh /usr/local/share

im Verzeichnis ‘inc’ befinden sich Definitionen, die noch aus den Templates angepasst werden müssen:

$ cd inc
$ cp fontset-settings.xml.inc.template fontset-settings.xml.inc
$ cp datasource-settings.xml.inc.template datasource-settings.xml.inc
$ cp settings.xml.inc.template settings.xml.inc

Die settings.xml.inc wird geändert (wie auch in den Kommentaren beschrieben) in:

<!--
Settings for symbols, the spatial reference of your postgis tables, coastline s$
-->

<!-- use 'symbols' unless you have moved the symbols directory -->
<!ENTITY symbols "symbols">

<!-- use the '&srs900913;' entity if you have called osm2pgsql without special $
<!ENTITY osm2pgsql_projection "&srs900913;">

<!-- used for 'node in way' ST_DWithin spatial operations -->
<!-- Use 0.1 (meters) when your database is in 900913     -->
<!-- Use 0.000001 (degrees) when your database is in 4326 -->
<!ENTITY dwithin_900913 "0.1">
<!ENTITY dwithin_4326 "0.00001">
<!ENTITY dwithin_node_way "&dwithin_900913;">

<!-- use 'world_boundaries', which is the usual naming for the local folder the$
<!ENTITY world_boundaries "/usr/local/share/world_boundaries">

<!-- use 'planet_osm' unless you have customized your database table prefix usi$
<!ENTITY prefix "planet_osm">

datasource-settings.xml.inc:

<!--
Settings for your postgres setup.

Note: feel free to leave password, host, port, or use blank
-->

<Parameter name="type">postgis</Parameter>
<!-- <Parameter name="password">%(password)s</Parameter> -->
<!-- <Parameter name="host">%(host)s</Parameter> -->
<!-- <Parameter name="port">%(port)s</Parameter> -->
<!-- <Parameter name="user">%(user)s</Parameter> -->
<Parameter name="dbname">gis</Parameter>
<!-- this should be 'false' if you are manually providing the 'extent' -->
<Parameter name="estimate_extent">false</Parameter>
<!-- manually provided extent in epsg 900913 for whole globe -->
<!-- providing this speeds up Mapnik database queries -->
<Parameter name="extent">-20037508,-19929239,20037508,19929239</Parameter>

mod_tile und renderd

Der Teil, der dann die Karten-Tiles erzeugt und ausliefert, wird über mod_tile im Apache gesteuert. renderd wird nur dann angesprochen, wenn die entsprechende Kachel noch nicht erstellt worden war.
Alos müssen wir dann jetzt mod_tile und renderd von github holen und kompilieren:

$ cd ~/src
$ git clone git://github.com/openstreetmap/mod_tile.git
$ cd mod_tile
$ ./autogen.sh
$ ./configure
$ make
$ sudo make install
$ sudo make install-mod_tile

Die Konfiguration für den Render-Daemon muss noch nach /etc/ geschrieben werden, damit der auch weiß, was er tun soll. In ~/src/mod_tile/ besteht schon eine renderd.conf, die allerdings angepasst werden muss:
Unter [mapnik]:

plugins_dir=/usr/lib/mapnik/3.0/input/

Unter [default]:

URI=<Pfad, unter dem die tiles geliefert werden sollen, default: /osm_tiles/>
HOST=<hostname>
XML=<Pfad zum Mapnik-Style>

Der XML-Pfad muss lesbar sein für den User, unter dem renderd laufen wird. In diesem Beispiel ist es der aktuelle Benutzer, der auch die mapnik-styles in seinem src-Verzeichnis hat. Also wäre es

XML=/home/<MeinBenutzer>/src/mapnik-style/osm.xml

Die so geänderte Datei muss dann nach /etc/renderd.conf kopiert werden:

$ sudo cp renderd.conf /etc/renderd.conf

Damit ist mod_tile und mapnik verfügbar. Damit der Apache das Modul auch läd ist in /etc/apache2/mods-available ein entsprechendes Load-Script notwendig:

$ sudo sh -c 'echo "LoadModule tile_module /usr/lib/apache2/modules/mod_tile.so" > /etc/apache2/mods-available/tile.load'

Das Modul muss dann noch aktiviert werden:

$ sudo a2enmod tile

… und in der Website-Konfiguration konfigriert werden:

$ sudo nano /etc/apache2/sites-enabled/000-default.conf

unter ServerAdmin folgendes hinzu fügen:

LoadTileConfigFile /etc/renderd.conf
ModTileRenderdSocketName /var/run/renderd/renderd.sock
# Timeout before giving up for a tile to be rendered
ModTileRequestTimeout 3
# Timeout before giving up for a tile to be rendered that is otherwise missing
ModTileMissingRequestTimeout 30

Noch nicht den Apachen neu starten. Erst testen wir, ob die Konfiguration unseren Vorstellungen entspricht:

$ sudo apachectl -t

Die Ausgabe sollte lauten:

[Thu Apr 20 10:39:32.261241 2017] [tile:notice] [pid 10497:tid 139902994429824] Loading tile config default at /osm_tiles/ for zooms 0 - 20 from tile directory /var/lib/mod_tile with extension .png and mime type image/png
Syntax OK

Das Laufzeit-Verzeichnis für den renderd muss noch erstellt werden, und die Rechte dem Benutzer zugewiesen werden. Das gleiche auch für den tile-cache:

$ sudo mkdir /var/run/renderd /var/lib/mod_tile
$ sudo chown `whoami` /var/run/renderd /var/lib/mod_tile
$ sudo chmod 777 /var/run/renderd /var/lib/mod_tile

Importieren von Kartendaten

Damit auch sinnvolle Tiles erzeugt werden können, müssen Kartendaten vorhanden sein. Diese können aus verschiedenen Quellen bezogen werden. Geofabrik stellt netterweise Auszüge zur Verfügung. Um erstmal das Setup zu prüfen sollte nicht mit dem Import des World-Files begonnen werden, eine kleine Region reicht aus. Bremen z.B. hat im Moment 16.3 MB (zu finden unter http://download.geofabrik.de/europe/germany.html)

$ mkdir ~/osm && cd ~/osm
wget http://download.geofabrik.de/europe/germany/bremen-latest.osm.pbf

Und dann osm2pgsql zum Laufen kriegen:

Also besorgen wir uns das von github und kompilieren es:

$ cd ~/src
$ git clone git://github.com/openstreetmap/osm2pgsql.git
$ cd osm2pgsql
$ mkdir build && cd build
$ cmake ..
$ make -j3
$ sudo make install

Benutzer, Datenbank und Erweiterungen für Postgres müssen erstellt werden:

$ sudo -u postgres createuser `whoami`
$ sudo -u postgres createdb gis
$ sudo -u postgres psql -d gis -c 'CREATE EXTENSION postgis; CREATE EXTENSION hstore;'

Und dann importieren wir die Bremen-Daten, die wir vorher herunter geladen haben.

$ osm2pgsql --create --database gis ~/osm/bremen-latest.osm.pbf

Für diesen kleinen Datensatz reicht der Aufruf auf den meisten Rechnern, weitere Parameter (insbesondere -C und –flat-nodes) werden in der Dokumentation von osm2pgsql erklärt.

Und dann mal alles starten

Somit ist alles installiert, was wir brauchen, und wir können den Render-Daemon starten.

$ cd ~/src/mod_tile
$ ./renderd

Dann koppelt sich renderd von der startenden Shell ab und läuft im Hintergrund. Für Fehlersuche empfiehlt sich die Version mit Output:

$ ./renderd -f -c /etc/renderd.conf

Weiterhin muss der Webserver neu gestartet werden, damit die Konfiguration auch greift:

$ sudo systemctl restart apache2

Darstellung mit OpenLayers 4

Zum Abschluss noch ein einfaches Beispiel, wie die Ergebnisse dann auch im Browser angezeigt werden können. Dazu schreiben wir folgendes in eine Datei map.html:

<!DOCTYPE html>
<html>
  <head>
    <link rel="stylesheet" href="https://openlayers.org/en/v4.1.0/css/ol.css" type="text/css">
    <style>
      .map { height: 95vh; width: 100%; }
    </style>
    <script src="https://openlayers.org/en/v4.1.0/build/ol.js" type="text/javascript"></script>
    <title>OpenLayers example</title>
  </head>
  <body>
    <div id="map" class="map"></div>
    <script type="text/javascript">
    var map = new ol.Map({
      target: 'map',
      layers: [
        new ol.layer.Tile({
            source: new ol.source.OSM({url: '/osm_tiles/{z}/{x}/{y}.png', maxZoom: 20})
        })
      ],
      view: new ol.View({
        center: ol.proj.fromLonLat([8, 53]),
        zoom: 8
      })
    });
    </script>
  </body>
</html>

Dann sollte unter http://mein.server/map.html eine Karte mit den Kartendaten von Bremen gerendert werden.

Openstreetmap Karte nur mit Bundesland Bremen

Beim ersten Aufruf kann das durchaus seine Zeit dauern, da die Kacheln noch alle erstellt werden müssen. Je nach Zoomstufe und erzeugendem Server ist eine Minute Bearbeitungszeit nicht ungewöhnlich. Je näher man rein zoomt, desto mehr Details müssen auch von der Datenbank abgefragt werden, daher variiert das Erstellen der Kacheln mit dem Zoomlevel.
Sind die Kartendaten einmal als Bild vorhanden, werden sie danach aus dem Cache geliefert (der steht in /var/lib/mod_tile, der Aufbau der Karte im Browser ist dann erheblich schneller.

Brother HL-1110 Treiber unter Linux/CUPS/Raspian

Views: 1164

Da einer meiner Raspberry-Pis anderer Aufgaben wegen im Dauerbetrieb arbeitet, wollte ich ihn auch als Drucker-Spooler nutzen. Einer meiner Drucker ist ein Brother HL-1110, und wie alles, was ich betreibe, soll der nur dann angeschaltet sein, wenn er wirklich benötigt wird, außerdem soll er im gesamten Netzwerk verfügbar sein.

Um den Drucker per CUPS anzusprechen, muss natürlich erstmal CUPS installiert werden. Ich gehe mal davon aus, dass das schon geschehen ist. Um den Brother-Drcker darüberzu nutzen, muss aber auch ein entsprechender Treiber vorhanden sein. Von der Brother-Support-Seite sind DEB- und RPM-Pakete vorhanden, aber keins, dass direkt auf Raspian funktioniert. Aber es gibt die gute Nachricht, dass der Quell-Code verfügbar ist. Und letztlich braucht es für CUPS nur einen kleinen Teil davon.

Ausgepackt gibt es PPD/brother-HL1110-cups-en.ppd, was man CUPS beim Einrichten eines neuen Druckers direkt als File-Upload geben kann. Zusätzlich braucht es noch filter/brother_lpdwrapper_HL1110, das kopiert man auf dem Ziel-System nach /usr/lib/cups/filter kopiert.

Danach ist der HL-1110 über CUPS für jeden Rechner im Netzwerk verfügbar (je nach Sicherheitseinstellungen, natürlich). Vor allem aber kann ich erst den Druckbefehl abschicken, un später den Drucker anmachen.

 

Update 2017-06-25

Da fehlen wohl ein paar Informationen.

Meine Prämisse: ich drucke von Windows aus auf einen Netzwerkdrucker; die Treiber für den Drucker sind unter Windows installiert.

Wird auf den Drucker etwas ausgegeben, hängt offensichtlich die Verarbeitung davon ab, welcher Datentyp geliefert wird. Wird von Linux aus – z.B. die Testseite von der CUPS-Administration – gedruckt, ist der Datentyp “application/vnd.cups-postscript”. Für den wird brother_lpdwrapper_HL1110 als Treiber genommen (definiert in der PPD). CUPS testet, ob diese Datei vorhanden ist, meldet sonst aber einen Fehler.

Wird hingegen von Windows mit den GDI-Treibern gedruckt, ist der Datentyp “application/vnd.cups-raw”, für den kein Filter definiert ist, da er auch nicht benötigt wird. Der Drucker versteht die erzeugte Datei direkt.

Somit ist CUPS hier nur mit der Verwaltung beschäftigt.

Um den Drucker unter Windows zu installieren, kann man den Druckertreiber von Brother runterladen, tatsächlich den Drucker über USB anschließen (das dämliche Installationsprogramm geht davon aus, dass nur lokaler Druck möglich ist…), den Drucker wieder abziehen und an den Raspberry Pi anschließen.
Oder man entpackt das Paket (z.B. Download für Windows 10 64bit) mit 7zip, dann erhält man unter install\driver\gdi\32_64 die Treiber, die man beim Einrichten des Netzwerkdruckers braucht. Dann entfällt das physische Anschließen.

Mit dem “Source”-Paket, das Brother da anbietet kann kein voll funktionierender Druckertreiber gebaut werden. Da fehlen sehr viele Dateien, insbesonder der Source für rawtobr3, ansonsten könnte man sich alles noch aus den verschiedenen RPM- und DEB-Paketen zusammen suchen.

Immer noch keine Raspberry-Pis

Views: 624

Wie im Forum von Raspberry-Pi zu lesen ist, ist der Verkaufstermin auf Ende Januar verschoben worden. Damit verpasse ich die 2. Gelegenheit, zu einem Geburtstag die Dinger in der Hand zu haben. Die ersten 10 Beta-Boards werden zwar bei ebay versteigert, aber so sehr ich den Laden auch unterstützen möchte, die limitierten Versionen mit Echtheitszertifikat kann ich mir nicht leisten.

Raspberry Pi wohl erst Anfang Dezember

Views: 603

Gnarf, ich kann es ja gar nicht abwarten. Ich “brauche” in jedem Raum meiner Wohnung einen Computer, der mindestens als Surfstation funktioniert. Möglichst noch Musik und Filme abspielen kann und natürlich sollten die Rechner vor allem komplett passiv gekühlt sein und nichts an Strom verbrauchen. Letzteres macht mein Hauptdesktop schon genug, schließlich muss der aber auch aktuelle Spiele anbieten können.

Meine Versuche mit EPIA-Rechnern waren schon nicht verkehrt, aber die (Strom-)Kosten/Nutzen waren noch nicht ganz das, was ich eigentlich wollte. Zumal mich auch die Treiber für die Grafikkarte unter Linux nicht überzeugen konnten, und die passiv betreibbaren Versionen an manchen Stellen schon etwas nervig langsam waren.

Aber dann las ich von Raspberry Pi Systemen. Sie könnten einiges meiner Träume wahr machen. Zu Preisen von 25 oder 35 $ (ohne / mit Netzwerk) und bei einem Verbrauch von ~3,5 Watt und erstaunlich guter Grafikkarte und (aber wen wundert es wirklich) komplett passiver Kühlung sind sie schon extrem verführerisch. Externes wird alles über USB angeschlossen, bis auf Bild (HDMI) und Ton (3,5mm Klinke). Die Stromversorgung erfolgt durch einen Mini-USB-Anschluß (5V) , also ziemlicher Standard, und kann auch durch Batterien erfolgen. PoE wird erstmal nicht zu den Fähigkeiten gehören, aber das kann man mit Adaptern auch noch selbst schustern.

Zu einem nutzbaren Computer fehlt also nur noch Tastatur/Maus, ein Display und ggf. ein Massenspeicher. So klein wie das Ding ist, kann man das sicher in ein Displaygehäuse integrieren oder einfach hinten dran kleben. Wenn dann noch ein Touchscreen dran kommt… Ach, ich will das Teil.

Leider wird der Verkauf nicht wie erst geplant im November starten, vorraussichtlich Anfang Dezember. So lange muss ich noch auf mein zukünftiges Spielzeug warten, gesetzt dem Fall, ich bin schnell genug beim Bestellen. Die Nachfrage dürfte meiner Meinung nach die erste Charge von 10.000 Stück weit übersteigen.