Bevor aufgrund ihres scheinbar naheliegenden Charakters auf Migration zur Archivierung digitaler Objekte gesetzt werden kann, ist diese Strategie in ihren möglichen Auswirkungen zu bewerten. Migration wirft auf den verschiedenen Ebenen, in denen sie durchgeführt werden kann, eine Reihe kleinerer und gravierenderer Probleme auf.
Auch wenn die Emulation viele Probleme einer funktionalen Langzeitarchivierung elegant zu lösen hilft, so ist sie doch nicht in allen Fällen die erste Antwort auf diese Frage. Eine gute Diskussion der Fragen von Emulation und Migration gibt [Holdsworth und Wheatley 2004]
3.6. EMULATION UND MIGRATION IM VERGLEICH 73
anhand einer Reihe von in Großbritannien durchgeführten Forschungsprojekten.44 Einige un-oder noch nicht befriedigend gelöste Probleme im Zusammenhang mit Emulationsstrategien stellt [Sereiens und Hilf 2003] zusammen.
Migration als Archivierungsstrategie Migration erweist sich dort als vorteilhaft, wo per-manent auf eine große Anzahl digitaler Objekte mit jeweils aktuellen Anwendungsprogrammen zugegriffen werden soll. Lernprozesse für den Umgang mit der notwendigen Software finden permanent statt. Deutlich schwieriger wäre schon die Vorstellung, dass Benutzer noch mit der Software der ersten Rechnergenerationen von vor zwanzig Jahren und mehr umgehen können.
Ebenfalls vorteilhaft kann sich die einfache Weiterverarbeitung migrierter Objekte er-weisen. Sie lassen sich mit den aktuellen Werkzeugen verändern und leicht in bestehenden Systemen durchsuchen oder publizieren. Damit einhergehen können Verbesserungen gegen-über dem Originalformat. Man muss sich nur einmal vorstellen, welche Möglichkeiten des Layouts und der Dokumentauszeichnung gegenüber den ersten einfachen Textbearbeitungs-und Textsatzsystemen bestehen. Beispiele sind Multimedia-Dokumente wie Präsentationen oder Querverbindungen mit Verweisen.
Dokumente, die permanent in Benutzung stehen, werden quasi automatisch in ihrer Qua-lität überwacht, womit Änderungen bei der Datentransformation schon früh auffallen sollten und eine eventuell notwendige Reaktion zeitnah erfolgen kann. Migration erweist sich als unproblematisch, wenn die Authentizität der Objekte sichergestellt ist (Abb. 3.10).
Zumindest bei häufig verwendeten Dokumenttypen werden sich mit hoher Wahrschein-lichkeit Standards etablieren. Für diese Standards ist der Bedarf an Konversionswerkzeugen entsprechend hoch, so dass von einer guten Verfügbarkeit ausgegangen werden kann. Die eben geschilderten Vorteile betreffen häufig jedoch nur eine Teilmenge des Gesamtdatenbe-standes. Zudem weichen die Anforderungen von Bibliothekaren und Archivaren an digitale Objekte stark von denen der ”normalen” Benutzer ab. Bei Migration handelt es sich nicht um eine einheitliche Methode zum generellen Umgang mit digitalen Objekten. Sie umfasst ein ganzes Strategiebündel. Die Einzelstrategien hängen sehr stark von den beteiligten Quell-und Zielformaten ab Quell-und lassen sich damit kaum generalisieren.
Sehr kritisch wird die Migration als Langzeitarchivierungsstrategie in [Rothenberg 1999], S. 13 sowie [Rothenberg 2002], S. 13 ff. beleuchtet.
Migration von digitalen Objekten primären Interesses Kriterien, wie Suchbarkeit, Betrachtung in aktuellen Computern und Weiterverarbeitbarkeit, sprechen für die Migration von digitalen Objekten in ihre jeweils passende Repräsentation. Wenn dabei gleichzeitig die Originale aufgehoben werden, so kann in emulierten Umgebungen jederzeit die Authentizi-tät des migrierten Objekts festgestellt werden. Ebenso bietet die Emulation die Möglichkeit erfolgte Migrationsschritte erneut nachzuvollziehen.
Jedoch bleiben etliche digitale Objekte von vornherein von der Migration ausgeschlossen:
Alle dynamischen Objekte, wie Programme, Bibliotheken und Betriebssysteme, deren Quell-code nicht offen liegt, können nicht auf die jeweils aktuelle Plattform übertragen werden.
Vielfach ist das Interesse an diesen Objekten zu klein, als dass es sich ökonomisch lohnt, hier
44Vgl. Abschnitt 2.6.
Abbildung 3.10:Vorschlag einer Einordnung verschiedener digitaler Objekte in Abhängigkeit ihres Typs in eine Langzeitarchivierungs-Strategiematrix.
eine Softwaremigration anzustoßen. Zudem sind die Abhängigkeiten von Programmen und Bibliotheken vom Betriebssystem und einer darunterliegenden bestimmten Hardwareschicht zu komplex, als dass sich dieses Unterfangen auf eine Vielzahl digitaler Objekte anwenden ließe.
Migration von Emulatoren und ihrer Hilfsmittel Migration kann zudem für Emulato-ren eine nicht zu vernachlässigende Option darstellen, wie im Abschnitt 4.8 bereits ausgeführt wurde. Gerade dadurch, dass sich an der emulierten Umgebung aufgrund ihres historischen Charakters nichts mehr ändert, kann es einfach sein, einen Emulator auf eine neue Umge-bung zu portieren, mithin zu migrieren. Hierbei handelt es sich häufig nur um Änderungen im Benutzer-Interface, die nicht zwingend eine komplette Neuprogrammierung eines Emulators erfordern müssen. Ändert sich die Host-Plattform aufgrund technischen Fortschritts, so haben nur vollständige Emulatoren eine Chance auf Migration. Andernfalls müsste eine komplette Emulation der vormals nur virtualisierten Komponenten hinzugefügt werden.
Ebenfalls von Interesse ist die Migration von Hilfsprogrammen, die beispielsweise zum Lesen oder Umwandeln der verschiedenen Containerformate der eingesetzten Emulatoren verwendet werden. Dieses gilt ebenso für Programme zum Einhängen von Festplatten-, ISO-oder Disketten-Images in das Dateisystem der gerade verwendeten Plattform. Diese Frage-stellungen werden im späteren Abschnitt 7.7.2 behandelt.
3.6. EMULATION UND MIGRATION IM VERGLEICH 75
Menge der zu berücksichtigenden Objekte Migration setzt am digitalen Objekt selbst an. Es handelt sich um einen periodisch notwendigen Prozess. Die Wiederholung einer not-wendigen Anpassung kann man zwar durch die Wahl von Standardformaten reduzieren, aus-zuschließen ist sie jedoch nicht. Bei sehr großen Objektzahlen kommen damit nur automatisch ablaufende Migrationstechniken in Frage, besonders da die Menge der Daten stetig zunimmt.
Bei der Wahl einer geeigneten Emulationsebene lässt sich die Zahl der zu beachtenden digitalen Objekte deutlich besser überschauen (Abb. 3.8). Die Menge der Rechnerarchitektu-ren, besonders wenn man sich auf die populären und für die Erstellung der meisten Objekte am häufigsten eingesetzten Plattformen beschränkt, ist im Verhältnis zur Zahl der Objekte verschwindend klein.
Die Grenzen der Emulation zeigen sich derzeit für komplexe Netzwerkanwendungen, die eine ganze Reihe verschiedener, miteinander vernetzter Maschinen involvieren. Hierzu zählen beispielsweise große Online-Spiele. Ebenfalls stoßen Emulationsstrategien an ihre Grenzen, wo um spezielle, nicht dokumentierte Hardware, wie Dongles zum Schutz von Software, geht.
Emulatoren können zwar das Aussehen alter Benutzer-Interfaces abbilden. Ihre Begrenzung liegt jedoch in den Aspekten der eigentlichen Hardware: Aussehen, bestimmtes Verhalten von Peripheriegeräten oder die Haptik lassen sich nicht übertragen.
77
4 Emulatoren - Recherche und Auswahlkriterien
Hardwareemulatoren können, wie im letzten Kapitel ausgeführt wurde, zu einer wichtigen Säu-le der Langzeitarchivierung digitaSäu-ler Objekte werden. Möchte man die Klasse der zugreifbaren Objekte um dynamische erweitern, führt kein Weg am Erhalt der geeigneten Ablaufumge-bungen für diese Objekte vorbei. Wie bereits dargestellt, eröffnet ein Hardwaremuseum keine wirklich zuverlässige Langfristperspektive, denn die Archivierung von alten Computern wird langfristig aus vielen Gründen kostenintensiv und zunehmend risikoreich. Deshalb bietet eine virtuelle Sammlung vergangener und sich im Prozess der Ablösung befindender Rechnerar-chitekturen eine sinnvolle Alternative mit etlichen Vorteilen.
Emulatoren für die unterschiedlichen Computersysteme werden daher zu einem zentra-len Bestandteil eines zu schaffenden Softwarearchivs. Dieses Softwarearchiv kann seinerseits wieder einen Bestandteil eines OAIS-basierten Langzeitarchivs bilden. Emulatoren sind eben-so wie die eigentlich interessierenden Primärobjekte von Veraltung betroffen und teilen mit diesen identische Probleme.
Die Aufgabe dieses Kapitels besteht darin, eingangs zu zeigen, dass bereits eine große Menge an Hardwareemulatoren im Laufe der letzten 30 Jahre entstanden ist. Hierzu erfolgte eine Recherche nach verfügbaren Emulatoren. Soweit es möglich erschien, wurden kursorische Tests vielversprechender Ansätze auf deren Ausführbarkeit auf einer möglichen Host-Plattform durchgeführt. Hierbei wurde die Intensität und Vollständigkeit der Überprüfung auf generelle Funktionsfähigkeit bewusst niedrig gehalten. Die tatsächliche Erstellung der relevanten Aus-wahlkriterien hängt von den jeweiligen Archivierungszielen der Gedächtnisorganisationen ab.
Zur Kategorisierung und späteren Sichtung spielen Metadaten, die Informationen zum Emu-lator oder Projekt liefern, eine Rolle. Da diese ebenfalls aus Sicht einer Archivaufnahme von Bedeutung sind, führen sie die Liste der Kriterien an.
Weiterhin beschäftigt sich dieses Kapitel mit der Aufstellung zusätzlicher Auswahlkriteri-en, die helfen sollen:
• als wichtig erachtete Klassen digitalter Objekte zu bedienen,
• institutionelle Rahmenbedingungen in Betracht zu ziehen,
• relevante Benutzergruppen und ihre (vermuteten) Bedürfnisse zu identifizieren,
• technische und nicht-technische Charakterisierungen vorzunehmen und die Vollständig-keit der Nachbildung abzuschätzen,
• Anhaltspunkte zur ökonomischen Bewertung zu erhalten und
• die Langfristorientierung abzuschätzen.
Abbildung 4.1: Gruppen von Auswahlkriterien für die Liste der ins Archiv aufzunehmenden oder wünschenswerten Emulatoren.
Die Emulatoren selbst sind Applikationen, die auf der jeweils aktuellen Rechnerplattform des Archivnutzers oder in einer geeignet definierten Bezugs- oder Referenzumgebung ablau-fen. Diese Umgebungen sind Bestandteil der Betrachtungen in Kapitel 6. Hierbei greifen sie auf eine Reihe von Ressourcen zu, die vomHost-Systemzur Verfügung gestellt werden. Um-gekehrt müssen sie die Nutzungsumgebung für das jeweilige Zielobjekt möglichst vollständig und umfassend nachbilden.
Die Auswahl der inzwischen kommerziell erhältlichen sowie als Open Source Software ver-fügbaren Emulatoren oder Virtualisierer ist inzwischen recht umfangreich geworden, so dass häufig sogar mehr als ein Emulator für eine bestimmte Rechnerarchitektur zur Verfügung steht. Jedoch eignet sich nicht jeder Emulator gleichermaßen für die Zwecke des Langzeitzu-griffs.
Nicht alle Auswahlkriterien lassen sich auf alle Rechnerplattformen und ihre Emulato-ren anwenden. So existiert für frühe ArchitektuEmulato-ren keine deutliche Unterscheidung zwischen Betriebssystem und Applikation. Home-Computer verfügten über eine jeweils recht fest defi-nierte Hardware, die zusammen mit einer Art Firmware verbunden ausgeliefert wurde. Diese Firmware enthält typischerweise eine einfache Kommandozeile und einen Basic-Interpreter.
4.1. RECHERCHE VERFÜGBARER EMULATOREN 79
Nicht alle für den Betrieb von Emulatoren benötigten Komponenten, wie beispielsweise die genannte Home Computer Firmware, ist frei verfügbar. Für die X86-Architektur liegt der Fall mit der Verfügbarkeit eines Open-Source-System- und Grafikkarten-BIOS einfacher.
Ein wichtiges, jedoch schwer abzuschätzendes, weil in die Zukunft reichendes Kritierium ist die langfristige Perspektive: Die Emulatoren sind wie jedes Primärobjekt von Veraltung betroffen. Um nicht dadurch die Les- oder Zugreifbarkeit der interessierenden Objekte zu gefährden, sind geeignete Maßnahmen zur Langzeiterhaltbarkeit dieser Software zu ergreifen.
Inzwischen existiert eine Reihe von Ansätzen, die Migration, Modularisierung oder Kapselung zur Erreichung dieses Ziels nutzen. Diese sind teilweise schon im Einsatz oder befinden sich in Erforschung und Entwicklung.
Aus Sicht der Langzeitarchivierung besteht zudem eine Divergenz: Der überwiegende Anteil von Emulatoren und Virtualisierern wurde aus ganz anderen als Langzeitarchivierungs-gründen erstellt. Sie sind heutzutage Standardwerkzeuge in der Softwareentwicklung. Nichts-destotrotz eignen sich viele der im folgenden vorgestellten Werkzeuge für eine Teilmenge möglicher Langzeitarchivierungsaufgaben.
4.1 Recherche verfügbarer Emulatoren
Das Konzept der Hardwareemulation existiert erstaunlich lange. Die Idee, Rechnerarchitek-turen in Software nachzubilden, hat viele Gründe, die von der Bereitstellung einer Entwick-lungsplattform für andere Gerätetypen bis zum Enthusiasmus gegenüber speziellen Maschinen reicht. Die dafür notwendige Software lief üblicherweise als Programm außerhalb des privi-legierten Kernel-Kontexts und war damit mit jeder für die jeweilige Plattform erhältlichen oder erstellten Applikationen vergleichbar. Deshalb standen am Anfang dieser Arbeit Unter-suchungen, welche Programme bereits vorhanden sind oder an welchen in dieser Richtung gelagerten Projekten gearbeitet wird (Abschnitt A.1).
Ziel war es, einen ersten Überblick zu gewinnen, um abschätzen zu können, für welche Rechnerarchitekturen relevante Emulatoren, damit sind produktiv nutzbare oder sich dahin entwickelnde Programme und Projekte gemeint, zur Verfügung stehen. Dabei wurden für die Host-Systeme anfangs keine Beschränkungen angenommen, da sich für im Sinne der Langzeitarchivierung gute Werkzeuge1 auch in geschachtelten Umgebungen einsetzen lassen.
Die erste Recherche nach verfügbaren Emulatoren wurde bewusst weit gefasst. Ausgewer-tet wurden in erster Linie Internet-Quellen. Diese haben gegenüber Büchern oder gedruckten Periodika den wesentlichen Vorteil, dass sie einerseits die jeweils aktuellsten Informationen bereithalten und andererseits oft gleichzeitig die Möglichkeit des Bezugs der ausführbaren Programme oder der Quelltexte erlauben. Generell lässt sich bei dieser Art der Recherche bereits auf eine Relevanz schließen: Wenige Referenzen bei Projekten oder Produkten lässt auf zu geringe Kundenzahl oder sehr kleine User-Communities schließen. Das birgt häufig die Gefahr einer fehlenden Nachhaltigkeit.
Parallel dazu erfolgte eine kursorische Recherche in den einschlägigen (deutschsprachi-gen) Computer-Magazinen,2 um zu verhindern, dass in der Menge der oft unstrukturierten
1Die Zahl der relevanten Referenzplattformen wird klein sein (Abschnitt 6.5), lässt sich aber durch Emulator-Stacking erweitern, siehe hierzu Abschnitt 4.7.
2ct, iX aus dem Heise-Verlag inclusive Online-Auftritt mit [HZV 2007], seriös mit dem höchsten
Verbrei-Informationen des Internets wichtige Emulatorprojekte übersehen werden. Sie ergab keine zu-sätzlichen Erkenntnisse. Stattdessen lieferte sie Anhaltspunkte und Testberichte oft vielver-sprechender Ansätze auf deren Ausführbarkeit auf einer Host-Plattform und deren generellen Funktionsfähigkeit.
Die nachstehenden Untersuchungen nehmen zuerst wenig Rücksicht auf die Relevanz der einzelnen Plattformen. Diese hängt stark von der Zielgruppe (Abschnitt 4.5) und ihren langzeitzuarchivierenden digitalen Objekten ab.