Os

Entwicklungen im Betriebssystem selbst

RISC OS für Nicht-RISC OS-ler

Nebenan auf meinem IT-Blog habe ich versucht, RISC OS für diejenigen zu erklären und zusammenzufassen, an denen unser phantastisches Lieblingsbetriebssystem bisher vorbeigegangen ist. Viel Spaß bei der Lektüre.

Die RISC OS memcpy()-Challenge

Jeffrey Lee hat im RISC OS Open-Forum zur memcpy()-Optimierung aufgerufen. Die bisherige Implementierung in der SharedCLibrary stammt aus 1991 und basiert auf Code von ARM Ltd. 1991 – das war zu Zeiten des ARM3, als die Caches noch klein, ausschließlich 1st level und Write-Through waren, man von 2nd level cache nur träumen konnte und sowas wie write buffering und write coalescing noch in weiter Ferne lagen.

Heute differieren die RISC OS-Plattformen deutlich stärker als damals. StrongARM, ARM11, XScale, Cortex-A8 und Cortex-A9 haben deutlich unterschiedliche Ansätze in punkto RAM-Anbindung. Es gibt gravierende Unterschiede bezüglich der Cache-Architektur, der Verfügbarkeit von Beschleunigern wie der XScale-DMA-Engine oder des NEON-Beschleunigers. Aligned- und Unaligned-Zugriffe haben unterschiedliche Performance-Charakteristiken, ebenso wie Zugriffe auf cached vs. uncached-Speicher. Dazu noch unterschiedliches Verhalten beim Überschreiten von Page-Grenzen.

Liebe Assembler-Frickler: das ist doch mal eine Challenge, wo die investierte Zeit gut angelegt ist. Die Speicherfunktionen in der SharedCLibrary würden bei signifikanten Verbesserungen für eine Beschleunigung von zig C-Anwendungen sorgen.

Zwei RISC OS-Legenden haben schon vorgelegt: Adrian Lees (Aemulor, Cino) und Ben Avison. Also, auf geht’s!

Eine Neuauflage der RISC OS-Lizenzdiskussion

Seit Castle Technology 2006 angekündigt hat, die Sourcen zu RISC OS soweit möglich freizugeben, gibt es die Diskussion über die Lizenz, unter der das geschehen sollte. Verschärft dann seit Mai 2007, als die ersten Sourcen tatsächlich das Licht der Öffentlichkeit erblickten und die Lizenz, unter der dies geschieht, publiziert wurde.

Eine Neuauflage dieser Diskussion läuft gerade im Forum von RISC OS Open.

Ein kluger Mensch würde sich aus dieser Diskussion wegen offensichtlicher Sinnlosigkeit heraushalten. Aber so klug war ich nie. Zu Anfang der Diskussion hatte ich noch die Hoffnung, dass der Threadstarter wenigstens ein Minimum an Lernfähigkeit zeigen würde. Denn wer, der sinnvolle zusammenhängende Sätze formulieren kann, wäre denn nicht lernfähig?

Falsch gedacht. Weder freundlich formulierte Nachfragen noch scharfe Erwiderungen scheinen irgendetwas zu bewirken. Frustrierend.

Was war der Ausgangspunkt? Der Threadstarter hat vorgeschlagen, per Crowdfunding einen Betrag X zu sammeln, um Castle die Rechte an RISC OS abzukaufen um dann RISC OS unter die GPL zu stellen (der Verlauf der Diskussion legt nahe, dass damit die GPLv3 gemeint ist).

Die erste Frage, die sich bezüglich dieser Idee stellt: was wäre der Vorteil davon, die Lizenz zu wechseln? Da gibt es durchaus einige:

  • die Castle Shared Source-Lizenz ist nicht kompatibel zu einigen anderen Open Source-Lizenzen, insbesondere natürlich nicht der GPL, d.h. eine Menge interessanter Code kann nicht ohne Weiteres für RISC OS verwendet werden
  • es existieren durchaus Entwickler, die nur dann an Projekten mitarbeiten, wenn die Lizenz gewissen Anforderungen genügt – mal muss es OSI-zertifiziert, mal ist es GPL
  • die Bedingungen für die kommerzielle Verwendung von RISC OS wären günstiger, d.h. es wären keine Zahlungen an Castle im Rahmen der OEM-Lizenz fällig
  • die Begrenzung auf ARM-CPUs wäre hinfällig

Das sind diskussionswürdige Vorteile, d.h. das Ansinnen sollte nicht direkt verworfen werden.

Was müsste praktisch getan werden, um eine solche Relizenzierung durchzuführen?

  • eine Summe Y müsste aufgebracht werden, um Castle die Lizenz abzukaufen – dabei sind die Regiekosten nicht zu vergessen, um z.B. entsprechende Anwälte fürs Vertragswerk zu bezahlen, die Managementzeit von Castle usw.
  • alle Copyright-Owner der jetzigen RISC OS-Codebase müssten kontaktiert werden, ob eine Relizenzierung möglich ist (und zu welchen ggf. finanziellen Bedingungen)
  • alle Module, die nicht unter die GPL gestellt werden können, müssten nachimplementiert werden

Und ich vermute, dass aus allen drei Gründen die Idee zum Scheitern verurteilt ist. Schon die Veröffentlichung der bisherigen Sourcen hat eine Menge Zeit und Aufwand in Anspruch genommen, und benötigt immer noch “binary blobs” (z.B. MBufManager und ShareFS), die Aufgrund der “linking”-Klausel der GPL verhindern würden, dass ein RISC OS-Image unter der GPL veröffentlicht werden könnte. Es sei denn natürlich, man will auf jegliche Netzwerkfähigkeit verzichten.

Meiner Ansicht nach steht der Aufwand in keinem Verhältnis zum Gewinn. Geld, Zeit, Energie – all das wäre anderweitig in der RISC OS-Welt deutlich gewinnbringender eingesetzt. Und für GPL-Liebhaber gibt es genügend Möglichkeiten, sich einzubringen – Anwendungen, softloadable-Komponenten, Software fürs Disc-Image – es gibt endlose Möglichkeiten.

Ebenfalls zu beachten ist, dass diverse Entwickler auch Vorbehalte gegen die GPL haben (und insbesondere die GPLv3). Die Verwendung der GPL würde neue Probleme schaffen, was die Verwendung von Code unter anderen Lizenzen bedeutet.

Letztlich muss man auch einschätzen, wie groß die Probleme der derzeitigen Lizenz tatsächlich in der Praxis sind. Die ARM-CPU-Klausel? Wer zum Geier wöllte jemals RISC OS auf eine nicht-ARM-CPU portieren? Wer stört sich wirklich an der OEM-Klausel – ist diese im Sinne des jetzigen Zustands der RISC OS-Welt mit immer noch aktiver kommerzieller Szene wirklich ein Nachteil? Was verbessert sich für den gewöhnlichen Entwickler oder Nutzer (nach momentanem Wissensstand würde ich sagen: nichts)?

Vom technischen Standpunkt aus interessant wäre die Frage, wieviel GPL-Code man gewinnbringend für RISC OS einsetzen könnte. Wenn man aber sieht, wieviel BSD-Code man völlig problemlos (lizenztechnisch, nicht implementierungstechnisch!) bereits heute für RISC OS einsetzen könnte aber es wegen fehlender Entwicklerkapazität nicht tut, verliert auch dieses Argument erheblich an Gewicht.

Relevante Quellen zum selbst nachlesen:

Ausnahmsweise sind hier Kommentare zugelassen und erwünscht.

 

Raspberry Pi Ethernet endlich schnell

Laut vertrauenswürdigen Berichten im RISC OS Open Forum hat Colin Granville, dem wir schon die Unterstützung für den isochronen Übertragungsmodus im RISC OS 5 USB-Stack und damit USB-Audio zu verdanken haben, endlich die wirklich harte Nuss geknackt. Bisherige Versionen von RISC OS auf dem Raspberry Pi hatten das Problem, dass der Upload über Ethernet plötzlich sehr langsam werden konnte. Mit den neuesten Änderungen von Colin ist dieses Problem nun Geschichte.

Im Moment gibt es offenbar noch ein Problem, sowohl schnelles Ethernet als auch Audiounterstützung gleichzeitig zu haben – USB-Scanner scheinen aufgrund eines Problems bei der Timeout-Steuerung in DeviceFS nicht mehr zu funktionieren. Riecht nach einer lustigen Runde Remote-Debugging.