Jeffrey Lee war nicht faul über die Feiertage und macht uns aktuell das Maul wässrig.
Klar, es ist immer noch ein riesiges Stück entfernt vom eigentlichen Ziel, einem multi-threading multi-core all-singing all-dancing RISC OS. Aber ein Schritt nach dem anderen.
Es ist immer interessant, die Neuigkeiten im RISC OS Open-CVS zu beobachten. Zur Zeit ist der große Frühjahrsputz im Gange.
Es findet ein Merge statt zwischen dem “HAL-Branch” – das ist der Branch, der anno 1998 durch Pace abgezweigt wurde, um das bisher hardwarespezifische RISC OS mit einem “Hardware Abstraction Layer” zu versehen, um so von der engen Bindung an IOMD und VIDC20 wegzukommen, was letztlich den IYONIX pc erst möglich machte – und dem “Head” (der ungebranchte Hauptzweig aller Versionen im CVS-Wording – amüsanterweise redet der Commit-Kommentar von “Trunk”, was auf den SVN-Hintergrund des Autors hinweist, wobei seit einigen Jahren auch der CVS-Head teilweise als “Trunk” bezeichnet wird), der weiterhin ein “RiscPC/A7000-RISC OS” darstellte. Das ist eine sinnvolle Bereinigung, denn der HAL-Branch hat sich über die Jahre als der Hauptentwicklungszweig herauskristallisiert, während der Head so vor sich hindümpelte und keine weitere Pflege geschweige denn Weiterentwicklung erfuhr – was ja auch Sinn ergibt, da es für IOMD/VIDC20-Systeme ja auch einen passenden HAL gibt.
Dazu wurden historische Flags für die bedingte Assemblierung z.B. von 26bit- vs. 32bit-Code, STB-Support, Arthur-Spezifika, Hacks für längst vergangene Hardware etc. entfernt, um den Code vernünftig wartbar zu machen.
Im Ergebnis sollte vor allem das Kernel-Zeugs deutlich übersichtlicher werden, wenn am Ende nur noch eine RISC OS-Variante übrig bleibt: 32bit mit HAL.
RISCOS Open Ltd. hat die Verfügbarkeit einer neuen Testversion des SpriteExtend-Updates zur Verbesserung des JPEG-Supports verkündet. Die Entwicklung erfolgt im Rahmen des Bounties “Update JPEG support”.
Worum geht es? RISC OS unterstützt nativ seit Anbeginn der Zeit nur ein einziges Bitmap-Format: das hauseigene “Sprite”-Format. Also das Äquivalent zu BMPs unter Windows. Mit RISC OS 3.6 änderte sich das: JPEG wurde ab da ebenfalls unterstützt. Und zwar mittels “on-the-fly-decoding”, also nicht wie frühere Tools wie ImageFS(2) per einmaliger Umwandlung ins Sprite-Format. Das hat besonderen Charme, weil es den Speicherverbrauch niedrig hält – das JPEG bleibt halt als JPEG im Speicher, und wann immer ein Redraw verlangt wird, wird dieser Bildschirmausschnitt aus den Originaldaten bepixelt. Man kann diesen Effekt schön sehen, wenn man in Draw einmal das JPEG reinzieht und einmal das in ein Sprite konvertierte JPEG verwendet – am Speicherverbrauch von Draw erkennt man sofort den Unterschied. Und auch bei der Redraw-Geschwindigkeit – da ist die native JPEG-Variante naturgemäß im Nachteil.
Wie so vieles in RISC OS (man denke an den Netzwerk-Stack) ist auch der JPEG-Support in die Jahre gekommen. Der Code basiert auf Version 4 der Library der Independent JPEG Group von 1993, also Steinzeit. Die neueste Version 9b dieser Bibliothek wurde gestern veröffentlicht. Nun ist alt nicht gleich schlecht, aber in diesem Falle sind eben alle JPEG-Weiterentwicklungen an RISC OS spurlos vorüber gegangen, z.B. die Unterstützung für andere Farbräume als YUV (RGB, CMYK), die progressive Codierung anstatt der normalen linearen (häufig genutzt auf Webseiten, so kann man schon während des Herunterladens eines Bildes dieses in zunehmend besserer Qualität darstellen), Interlace-Codierung, die neue arithmetische Codierung zur Verbesserung der Kompressionsrate, die neue lossless-Kompressionsvariante, vergrößerte Farbräume.
Die veraltete Unterstützung sorgte so für seltsame Blüten bei der Anwendungssoftware. In den allermeisten Fällen wurde entweder zuerst die JPEG-Decodierung dem Betriebssystem überlassen, und wenn das Format inkompatibel war, wurde auf eine eigene Implementierung zurückgegriffen. Oder es wurde gleich eine neuere Version der Referenzimplementierung verwendet. Irgendwann sind dann JPEGs aufgetaucht, die die OS-Implementierung in eine Endlosschleife geschickt haben statt einen Fehler zu produzieren. Kurz: die OS-Implementierung wurde eher hinderlich als nützlich.
Höchste Zeit also für den Frühjahrsputz. Den ersten Aktivitätsnachweis gab es Ende November letzten Jahres, gestern nun das Update. Viele Ziele des Updates sind bereits erreicht: Unterstützung für die Progressive- und Interlace-Codierung, andere Farbräume von RGB bis CMYK, die Arithmetic-Codierung. Das bereitgestellte Modul ist “softloadable” auf allen Maschinen ab ARMv4, also im Prinzip für alles ab Risc PC.
tl;dr: Neues SpriteExtend-Modul, viel besser als das alte. Runterladen und ausprobieren.
Übrigens: nach dem Update ist vor dem Update. JPEG XT, JPEP-LS, JPEG 2000, JPEG XR, JBIG…
RISC OS Open Ltd. hat heute mit der Neuigkeit überrascht, dass eine bis dato (mir) unbekannte Firma namens Elesar Ltd. ein Board namens Titanium entwickelt hat. Basierend auf dem bekannten Dual-Cortex-A15-OMAP AM5728 von TI legt es etwas andere Schwerpunkte als die Konkurrenz. 2 GB RAM, sechs USB2.0-Host-Anschlüsse (plus zwei interne), 2x DVI-I, 2x Gigabit Ethernet, 8 MB interner Flash-Speicher, 2 serielle Ports und vier SATA-Ports lautet die interessante Mischung. Das Ganze in einem ATX-kompatiblen Package, mit I/O Shield zum Einbau in Standard-ATX-Gehäuse.
Der m.E. noch interessantere Teil der Nachricht: man macht sich nicht nur um Hardware Gedanken, sondern auch um Software. Piccolo Systems (zu Deutsch: Ben Avison) hat sich um eine anständige Treiberschicht für S-ATA gekümmert. Ein Meilenstein in der RISC OS-Geschichte, wenn wirklich das alte IDE-Gefummel in ADFS endlich abgelöst werden kann. Und wenn dadurch CDVDBurn tatsächlich mal mit “full speed” des Brenners arbeiten könnte.
Nun gibt es also vier “Bewerber” um den Preis “schnellste RISC OS-Hardware”, die allesamt auf dem TI OMAP5 basieren:
Hardware Overload. Gewisse Eigenschaften des Titanium-Boards lassen auf RISC OS-Herkunft schließen: das verhältnismäßig kleine interne Flash-ROM, die zusätzlichen 2K EEPROM, die geradezu “CMOS” schreien. 2 GB RAM als größte sinnvolle Speichermenge, mit der RISC OS umgehen kann. Und tatsächlich: hinter Elesar Ltd. steckt niemand anderes als Robert P. Sprowson, auch als “Sprow” bekannt.
Bin gespannt, was für Eindrücke von/nach der RISC OS London Show eintrudeln.
RISC OS steht (zumindest auf den modernen post-Risc PC-Plattformen) vor einem erneuten Schritt, der potenziell Schmerzen bei der Rückwärtskompatibilität verursachen wird. Hier kann man die Gründe, die RISC OS Open Ltd. dafür anführt, nachlesen. In der GAG-News 141 wurde ebenfalls ein Artikel dazu veröffentlicht.
Kurz zusammengefasst geht es um den Speicherbereich der ersten paar KB, der traditionell “Zero Page” genannt wird und z.B. “Kernel Scratch Space” beinhaltet und die Prozessorvektoren. Und natürlich die Adresse 0, beliebtes Ziel aller nicht initialisierter Pointer der systemunabhängigen Assemblersprachen (vulgo C und Konsorten).
Die Development-Builds seit dem 5.Juli haben die Zero Page nun in den hohen Speicherbereich verschoben und für Userspace-Code unzugänglich gemacht. Alle Software, die absichtlich oder unabsichtlich auf die Zero Page, wir sich mit einem Data Abort verabschieden. Bzw. das wäre der Fall, wenn nicht gleichzeitig eine Analyse- und Logging-Modul namens “ZeroPain” aktiv ist. Dieses beantwortet Lesezugriffe in einer kompatiblen Art und Weise und loggt gleichzeitig diese Zugriffe, um dem Softwareentwickler eine Analysemöglichkeit an die Hand zu geben. Wenn es nach dem veröffentlichten Fahrplan geht, wird ZeroPain ab 1.1.2016 nicht mehr zur Verfügung stehen.
Historisch betrachtet gab es bei RISC OS schon einige Zäsuren bezüglich der Rückwärtskompatibilität, und einige Utilities, die versuchten die Rückwärtskompatibilität wieder zu verbessern oder gar vollständig wiederherzustellen. Von RISC OS 2 nach RISC OS 3 gab es einige Verwerfungen, zum einen aufgrund der althergebrachten Home-Computer-Entwicklungsidee “direkt auf die Hardware”, die an einem großflächigen Wechsel der Peripherie-Chips zerschellte (6551 nach 8250, ST506 nach IDE, 1772 nach 82C710/11). Dann diverse Unterschiede zwischen den Betriebssystemversionen selbst – einige APIs erfuhren subtile Änderungen, und wer nicht genau nach Spec implementiert hatte, wurde kalt erwischt.
Dann kam der Risc PC. Wieder gravierende Änderungen in der Chipsatzlandschaft, dazu ein umgekrempeltes Videosystem um die neuen Grafikfähigkeiten abzubilden. Zig Spiele scheiterten aufgrund der Änderungen des VIDC20 gegenüber dem VIDC1. Game On!, eine Software des ARM Club, stellte einen VIDC1-Kompatibilitätslayer zur Verfügung.
Bis zu diesem Zeitpunkt konnte man mit Fug und Recht behaupten, dass Kompatibilitätsprobleme halt durch unfähige Programmierer zustande kamen – die Doku nicht richtig gelesen, die Hardware direkt angesprochen – selber schuld.
Und dann wurde alles anders. Der StrongARM kam. Harvard- statt von-Neumann-Architektur beim 1st level cache und Writeback- statt Writethrough-Konfiguration, was selbstmodifizierenden Code aus der Bahn warf. 5-stufige statt 3-stufige Pipeline mit subtilen Änderungen beim Verhalten des PC. Und dazu der dramatische Geschwindigkeitsboost, der so manche Software aus dem Takt brachte. Dagegen war dann der Schritt RISC OS 3.7 nach RISC OS 4 ein Kindergeburtstag. Viele Softwarehersteller nutzten die Gelegenheit und machten mit Minimalupdates zur Herstellung der StrongARM-Kompatibilität zum letzten Mal Kasse. Mit StrongGuard des ARM Club stand eine Lösung für Spiele zur Verfügung, für Anwendungen gab es so etwas nie.
Aber die größte Zäsur kam erst danach. Von 26bit nach 32bit. Der IYONIX kam, dazu RISC OS 5, und das Ende des “legacy” 26bit-Adressmodus. Im Prinzip lief danach – außer den reinen BASIC-Erzeugnissen – keine Software mehr. Der geniale Aemulor linderte den Schmerz etwas, aber die Kompatibilität war begrenzt und die Anwesenheit von Aemulor im System hat diverse Nachteile für den regulären Betrieb.
Dann kam das BeagleBoard, und mit ihm die ARMv7-Architektur, wo ARM mal wieder das “nicht-ganz-rückwärtskompatibel”-Spiel spielte. Da das aber nur die relativ selten auftretenden “unaligned loads” betraf, hielt sich der Schaden in Grenzen – solange der Benutzer die “Alignment Exceptions” abschaltete. Was uns wieder zur “ZeroPain” führt, das ja letztlich denselben Ansatz fährt: Verstöße stillschweigend dulden.
Nun also “Zero Page Relocation”. Die Frage lautet wie immer: ist der Gewinn (durch höhere Systemstabilität, für mehr Freiheitsgrade für zukünftige Entwicklung) größer als der Verlust (Software läuft nicht mehr)? Die Antwort liegt vermutlich im Auge des Betrachters – setzt man unersetzliche Software ein, die dann nicht mehr läuft? Es gibt ja nun nicht besonders viele aktive RISC OS-Nutzer (geschweige denn -Entwickler), kann es sich die RISC OS-Welt leisten auch nur einen davon zu verlieren?
Ich muss gestehen: ich habe keine klare Meinung dazu. Endlose Rückwärtskompatibilität führt zu endlos steigenden Aufwänden, was sich ein System wie RISC OS, das nur wenige Entwickler hat, nicht leisten kann. Aber die Anwendersicht hat natürlich erhebliches Gewicht: was soll man mit einem System, das keine Nutzer mehr hat?
Aus meiner Sicht kann es nur einen Ausweg geben: wir brauchen in Zukunft eine wasserdichte Emulationslösung, die solche rückwärtskompatibilitätsbrechende Änderungen abfedert. Im Moment haben wir einen ganzen Zoo von Lösungen: ArcEm, ArchiEmu, ADFFS und Aemulor. Alle haben ihre Nischen und spezifischen Vorteile, sind aber allesamt für den Otto-Normalanwender viel zu kompliziert zu benutzen, bzw. dadurch ausgelöste Effekte sind nicht zu durchschauen. Es bräuchte eine modulare Lösung, zu der auch “normale” Entwickler beitragen können. Mir schwebt eine Art Hypervisor vor, in den man anwendungsspezifisch Kompatibilitäts-Handler einbauen kann, die z.B. bei SWI-Aufrufen wieder Kompatibilität herstellen können. Dazu muss pro Anwendung entschieden werden, ob sie codetechnisch nativ oder emuliert ausgeführt werden soll. Vollständige Emulation mit einer beliebigen RISC OS-Version muss möglich sein, die Fenster der Anwendung der Emulation müssen in das Host-Betriebssystem “seamless” eingebunden werden können. An der Prozessorkompatibilitätsfront könnte sowas wie LLVM durchaus helfen.
Was natürlich auch helfen würden: Open Source allüberall. Wird wohl nicht passieren, und braucht dann ja auch eine Menge Kümmerer, die die Software dann pflegen.
RISC OS macht bekanntlich vieles anders als andere Betriebssysteme. Besonders augenfällig ist das im Bereich Dateisysteme, was regelmäßig für Verwirrung sorgt. Dieser Artikel soll helfen, den Überblick zu bewahren.
Beteiligt am bunten Filesystem-Treiben unter RISC OS sind beispielsweise folgende Kandidaten:
Eine Besonderheit von RISC OS ist die Unterstützung von Image-Filing-Systemen. Darunter versteht man die Möglichkeit, eine einzelne Datei (oder auch ein ganzes Medium wie eine Festplatte, ein USB-Stick oder eine Diskette) als Verzeichnis zu behandeln. Bekannte Implementierungen sind z.B. DOSFS (Zugriff auf FAT-Medien) oder SparkFS (Zugriff auf Archive wie ARC, ZIP und ARJ). Für viele Operationen sind solche Images nicht von normalen Verzeichnissen zu unterscheiden – von der Kommandozeile aus z.B. kann problemlos in den Innereien einer ZIP-Datei herumgefuhrwerkt werden, wenn SparkFS aktiv ist. Alles funktioniert völlig transparent. Nur auf SWI-Ebene kann man herausfinden, ob ein Objekt ein “File” ist, ein “Directory” oder ein “Image” – wobei das “Image” auf dieser Ebene dann entweder als File oder als Directory bearbeitet werden kann.
Basis aller Dateisystem-Dinge ist Fileswitch. Hier registrieren sich alle tatsächlichen Dateisysteme (egal ob “echte” oder “Image-Filing-Systeme” mit ihren “Entry points”). Hier sind die SWIs definiert, die in RISC OS die Schnittstelle zum Dateisystem bilden, von OS_Args über OS_File bis OS_GBPB.
Fileswitch definiert die “special characters” von RISC OS-Dateisystemen wie “$”, “:”, “&” und “%” und die Wildcards “*” und “%”, legt fest dass der Verzeichnistrenner “.” ist und beschäftigt sich mit den berühmten 8 Bytes, die entweder 5 Byte Datestamp + 12 Bit Filetype repräsentieren oder 4 Byte Load address + 4 Byte Exec address. Dazu gibt es noch ein volles Word Attribute.
Fileswitch ist ansonsten weitestgehend agnostisch gegenüber Implementierungsdetails. Zeichensatz? Physikalische Abbildung der logischen Verzeichnisstruktur auf dem Datenträger? Maximale Länge eines Dateinamens? All das bestimmt die Implementierung des Fileswitch-Clients. Die API ist leider nur 32bittig, d.h. die maximale Dateigröße ist auf 4 GiB begrenzt (lange Zeit (vor RISC OS 5.22) konnte Filecore sogar nur 2 GiB-Dateien verwalten). Wichtig zu wissen: Fileswitch ist inhärent case-insensitiv.
An dieser Stelle sollte aber beachtet werden, dass zwar Fileswitch gegenüber vielen Details agnostisch ist, aber leider nicht jede Software, die Fileswitch verwendet. Denn die meisten Entwickler testen ja mit real existierenden Dateisystemen, und oft nur mit einem – Filecore. Wenn sich dann andere Dateisysteme zwar API-konform, aber nicht gleich wie Filecore verhalten, führt das oft zu Verdruss. Beispiele in der Vergangenheit waren das Enumerationsverhalten von Verzeichnissinhalten bei Fat32FS, HostFS oder Sunfish.
Übrigens ist das Dateigrößenlimit von 4 GiB ein größeres Problem, als es zunächst scheint. Denn es limitiert nicht nur (logischerweise) die Größe einer Datei, sondern auch die Größe des Mediums, das ein Image-Filing-System verwalten kann. Deshalb ist DOSFS nicht in der Lage, mit FAT-formatierten USB-Sticks umzugehen und man benötigt Fat32FS, das als “echtes” Dateisystem implementiert ist und daher nicht an das 4 GiB-Limit der Image-Filing-Systeme gebunden ist.
Filecore hat eine lange Historie bis zurück in die Zeit der 8-Bitter. Von Anbeginn der RISC OS-Zeit war das “Filecore E”-Format das native Dateisystem auf Disketten und Festplatten. Lange Zeit (bis RISC OS 4) ein Ärgernis, da limitiert auf maximal 10 Zeichen pro Dateiname und 77 Objekte in einem Verzeichnis. Aber ziemlich clever, was die Platzausnutzung des Mediums angeht (über “shared fragments” erreicht man eine feinere Granularität als die Blockgröße) und die Optimierung mit automatischer Defragmentierung.
Verschiedene RISC OS-Versionen haben unterschiedliche Limitierungen bezüglich Filecore. Alles bis einschließlich RISC OS 3.5 hatte eine maximale Partitionsgröße von 512 MiB (nicht zu verwechseln mit dem alten BIOS-PC-Limit von 504 MiB), alles bis einschließlich RISC OS 3.7x konnte nur 10 Zeichen pro Dateiname und 77 Objekte pro Verzeichnis.
Aktuelle Limits bei RISC OS 5 sind 256 GiB pro Partition bei einer Blockgröße von 512 Bytes. Theoretisch kann Filecore auch andere Blockgrößen (traditionell 1024 Bytes, inzwischen auch 2048 und 4096 Bytes), aber das wird meines Wissens derzeit von keinem Filecore-Client unterstützt.
Jede Filecore-Instanz kann maximal 8 Geräte verwalten, 4 Festplatten und 4 Wechselmedienlaufwerke. In der Theorie wurde das RISC OS 5-Filecore durch einen neuen Aufruf erweitert, um theoretisch bis zu 256 Geräte mit jeweils bis zu 16 EiB (also 16 Milliarden GiB) zu verwalten. Meines Wissens ist das aber nicht ausimplementiert. Insbesondere größere Medien wären schlecht zu handhaben, weil die Größe der Filecore-Map linear mit der Größe des Mediums wächst und vollständig im Hauptspeicher liegen muss.
Geht bei Filecore etwas schief, sind die Bordmittel um etwas zu retten sehr begrenzt. Der *CheckMap-Befehl kann zwar die Map auf Konsistenz prüfen, aber wenn sie inkonsistent ist, gibt es keine Lösungsmöglichkeit. *Verify prüft im Prinzip nur, ob die einzelnen Sektoren bzw. Blocks lesbar sind. Man muss kaputte Sektoren dann von Hand per *Defect als kaputt markieren.
Deshalb sollte jeder RISC OS-Benutzer auf jeden Fall DiscKnight von David J. Ruck in seiner Werkzeugkiste haben. Und zwar auf jedem Medium – besonders auf Netzwerkmedien, auf die man auch im Falle des Falles zugreifen kann, wenn die Platte oder der USB-Stick nicht mehr wollen. Schmale 10 UKP sollte das jedem wert sein.
Besondere Vorsicht ist auch beim Löschen geboten. Es gibt hier keinen (sicheren) Weg zurück, schon der nächste Schreibvorgang kann die soeben gelöschten Daten unwiederbringlich überschreiben. DiscKnight hat deshalb ein Feature, den freien Speicherplatz einer Filecore-Partition in eine Datei zu verwandeln, so kann man ggf. gelöschte Daten wiederherstellen.
Jeder RISC OS-Nutzer kennt ADFS. Ursprünglich (RISC OS 2, Archimedes, als Festplatten noch unsäglich teuer waren) als ADFS::0 der Zugang zum einzigen Diskettenlaufwerk, wird es später um ST506-basierte Festplatten (MFM) und noch später um IDE-basierte Festplatten erweitert. Eines blieb immer gleich: ADFS unterstützt nur eine Partition. Von Drittherstellern gibt es BDFS und EADFS mit Multi-Partition-Support.
ADFS ist, genau wie SCSIFS, SDFS und IDEFS, ein Filecore-Client. In anderen Worten: ADFS kümmert sich darum, Zugriffsroutinen bereitzustellen, um Blöcke von Geräten zu lesen und auf sie zu schreiben. Das logische Dateisystemformat steuert also Filecore, den Zugriff auf die physischen Geräte ADFS.
Selbiges gilt für SCSIFS, das aber nicht nur für die weitestgehend ausgestorbenen SCSI-Geräte zuständig ist, sondern auch für USB-Geräte vom Typ “Mass Storage” – dazu wird über SCSISoftUSB ein Low-Level-Treiber in den SCSIDriver integriert, der USB-Geräte als SCSI-Devices bereitstellt, damit SCSIFS darauf zugreifen kann.
SDFS und IDEFS schlagen in dieselbe Kerbe, nur eben für Zugriff auf SD-Karten und IDE-Geräte, wobei IDEFS von Drittherstellern von IDE-Podules bereitgestellt wurde und meistens mehrere Partitionen unterstützt.
Durch die Konstruktion “xxFS ist das Dateisystem das ein Filecore-Client ist, Filecore ist ein Fileswitch-Client, aber der eigentliche Hardware-Treiber sitzt wieder in xxFS” wurde der Filesystem-Stack von RISC OS oft als “upside-down” charakterisiert.
Mit CDFS und CDROMFS verlassen wir die Welt der Filecore-Clients und nehmen die ersten Dateisysteme, die direkt an Fileswitch andocken, unter die Lupe.
CDFS war anfangs eine “SCSI-only”-Veranstaltung und konzentrierte sich ganz auf das ISO9660-Format, dem Standard für Daten-CDs. Mitte der 90er, als CDROM-Laufwerke langsam gebräuchlich wurden, führte CDFS die Technik des “softloadable drivers” ein – man konnte nun Module bauen (typische Namen: CDFSSoftSCSI2, CDFSSoftATAPI), die die Verbindung zur Hardware übernahmen. Praktisch jeder Anbieter von SCSI- und IDE-Podules hatte seinen eigenen Treiber, dazu kamen generische Treiber von EESOX und IOC (später Pulse Computer) für SCSI sowie Power-tec und EESOX für ATAPI.
CDROMFS von Warm Silence Software (geschrieben von Ian Fry) ist ein Ersatz für CDFS. Und zwar nur für das CDFS-Modul, CDROMFS benutzt die Treiberinfrastruktur von CDFS einfach weiter. CDROMFS versteht mehr Varianten von ISO9660, versteht Joliet und Teile von RockRidge sowie ein Subset von UDF. Außerdem ist CDROMFS ein Image-Filing-System, kann also ISO-Images direkt öffnen – CDFS kann das nur in Verbindung mit CDFaker.
CDFS wurde inzwischen auch weiterentwickelt und versteht seit RISC OS Select und RISC OS 5.20 ebenfalls Joliet.
Im nächsten Teil geht es um die “FAT-Versteher” DOSFS, Fat32FS und Win95FS. Um ein paar interessante Image-Filing-Systeme wie DOSFS, Win95FS, SparkFS, TBAFS und X-Files. Um Netzwerk-Clients wie Sunfish, ImageNFS, NFSClient, LanManFS und LanMan98. Dazu ein kurzer Blick auf HostFS, dem Dateisystem der Emulatoren. Und eventuell PipeFS, das u.a. für den Zugriff auf USB genutzt werden kann.
Ein weiterer zukünftiger Artikel soll skizzieren, was im Bereich Dateisysteme in RISC OS geändert werden sollte. Bei RISC OS Open Ltd. gibt es ein offenes “Filesystem bounty”, das sich mit der Problematik der Partitionierung beschäftigt. Ein erster Schritt ist bereits getan. Die gesamte Roadmap ist hier und hier skizziert.
Rechtzeitig zur Wakefield Show wurde RISC OS 5.22 veröffentlicht. Bekanntlich folgt RISC OS 5 dem “ungerade-gerade”-Versionsnummernschema, wo die geraden Nummern die stabilen Releases repräsentieren und die ungeraden die Entwicklungsversionen.
Aus meiner Sicht relevante Verbesserungen:
Das stabile Release gibt es in den Geschmacksrichtungen IOMD (Risc PC, A7000(+), RPCEmu), Tungsten (IYONIX pc), OMAP3 (BeagleBoard(-xM), BIK, ARMini, Pandora, Touchbook, IGEPv2) und OMAP4 (PandaBoard (ES), ARMiniX, PandaRO).
ARMX6 und OMAP5 (IGEPv5) sind naturgemäß noch zu frisch, um schon im “normalen” Release-Zyklus mitzumischen.
Weitere Infos bei RISC OS Open Ltd.
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.
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!
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:
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?
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.