Editorial 01-02/2017

Viele Single-Board-Computer benötigen proprietäre Software-Komponenten zum Funktionieren. Das schränkt die Leistungsfähigkeit, Sicherheit und die Entwickler-Community ein. Selbst der RasPi 3 plagt sich noch mit einem solchen “Blob” herum.

Sehr geehrte Leserinnen und Leser,

der Film “Blob – Schrecken ohne Namen” von 1958 dürfte beim Zuschauer heute kaum mehr eine Gänsehaut hervorrufen. Dennoch gilt der Streifen (in dem Steve McQueen seine erste Hauptrolle spielte) als Klassiker des Grusel-Genres. Bei der Wahl des Namens für ihr Monster dachten die Filmemacher von damals allerdings kaum daran, dass der Begriff auch nach Jahrzehnten noch Angst und Schrecken verbreiten würde: Noch heute fürchten Open-Source-Enthusiasten das “Binary Large Object” oder kurz Blob.

Software-Entwickler bezeichnen mit diesem Begriff die zu einem Stück Hardware gehörigen Software-Komponenten, wenn deren Quellcode nicht offen liegt und der Hersteller sie nur als binäre Datei zur Verfügung stellt. Viele Netzwerkkarten, RAID-Controller und Grafikchips benötigen ein solches Blob zum Funktionieren; ohne es lässt sich die entsprechende Hardware nicht oder nur eingeschränkt in Betrieb nehmen. Die Folgen zeigt der Artikel zum Odroid-XU4 in diesem Heft (ab Seite 62).

Der mit einer Octa-Core-CPU, Gigabit-Ethernet und 2 GByte RAM ausgestattete SBC toppt auf dem Papier den RasPi locker. Auch bei reinen Rechen- oder Netzwerk-Benchmarks steckt der Odroid-XU4 den RasPi locker in die Tasche. Doch die guten Werte sind schnell vergessen, sobald man den XU4 mit einem grafischen Desktop betreiben möchte: Trotz seiner theoretisch sehr schnellen GPU hinkt der Odroid dem RasPi hier deutlich hinterher. Der Odroid operiert mit einem Blob, um Lizenzeinnahmen zu schützen – finanzielle Interessen des Chipherstellers bremsen also hier die Technik aus. Für den RasPi dagegen liegt der Grafiktreiber im Quellcode vor.

Über Performance-Aspekte hinaus gibt das quelloffene Vorliegen der Software den Entwicklern zudem die Freiheit, einen beliebigen Betriebssystemkern zu verwenden, wohingegen ein Blob in der Regel nur mit einer bestimmten Kernel-Version sauber kooperiert. Blob-Updates liefern die Hardware-Schmieden wegen des hohen Entwicklungsaufwands nur selten.

Doch noch kommt selbst der Raspberry Pi nicht ohne Blob aus. In Form der Dateien start*.elf und bootcode.bin aus /boot liegen auf jedem RasPi proprietäre Komponenten, ohne die er nicht bootet [1]. Das RasPi-Blob kümmert sich unter anderem um den in Silizium gegossenen MPEG-Decoder. Zwar hat die Raspberry Pi Foundation bei der Vorstellung des Open-Source-Treibers versprochen, ihn eines Tages gegen einen “minimalen, offenen Blob” auszutauschen [2], doch in den letzten zwei Jahren wurde es um dieses Thema recht still.

Debian listet daher den RasPi (und so gut wie alle anderen günstigen Alternativen) immer noch als ungeeignete Hardware-Basis für einen kostengünstigen Server [3]. Es ist höchste Zeit, den Raspberry Pi gänzlich zu öffnen – vielleicht ergreift die Foundation diese Chance ja mit einem künftigen Raspberry Pi 4.

Herzliche Grüße,

Christoph Langner

Redakteur