PC-Ecke > # PC-Games und News
Emulatoren für diverse Spielekonsolen
SiLæncer:
Retro-Arcade-Anbieter will fragwürdige kommerzielle MAME-Konkurrenz ausschalten
Der Retro-Spielmaschinen-Anbieter UltraCade Technologies hat den Zorn der MAME- und Open-Source-Gemeinschaft auf sich gezogen, indem man versucht sowohl den Namen MAME als auch das entsprechende Logo als eigene Marke anzumelden. In zwei offenen Briefen hat sich UltraCade-CEO David R. Foley nach teils heftiger Kritik an die MAME-Gemeinschaft gewandt und beteuert, damit nur gegen Konkurrenten vorgehen zu wollen, die mit billigen MAME-basierten Arcade-Systemen ohne Lizenzen für die Originalspiele werben und damit sowohl UltraCade als auch MAME schaden würden.
Der UltraCade-CEO wähnte in seiner ersten Stellungnahme und im MAME-Forum die Konkurrenz hinter der scharfen Kritik an der Markenanmeldung. Foley will mit der Marke eigenen Aussagen zufolge nur gegen die Anbieter vorgehen, die den freien Multiple Arcade Machine Emulator (MAME) entgegen dessen Nutzungsbestimmungen kommerziell vertreiben und ihren Kunden bei der Beschaffung von unerlaubt kopierten Spielen helfen würden. Die Verwendung des Namens und des Logos sei hingegen nicht geplant.
"Unser Ziel ist es, das kommerzielle Angebot von Maschinen mit illegal erworbenen ROMs zu unterbinden. Ich glaube dass unsere Ziele parallel laufen können", so Foley. Selbst arbeite man schon seit langer Zeit mit Spielepublishern zusammen und erwerbe ständig weitere Titel für die eigene Plattform.
Im offiziellen MAME-Forum sieht man die Anmeldung der Marke kritisch, da UltraCade zu MAME nichts beigetragen habe und durch seine unerbittlichen Methoden selbst an MAME vergehen würde. In Frage gestellt wurde auch der Sinn der Markenanmeldung, denn selbst wenn UltraCade die Namensrechte besäße, würden dies nicht automatisch eine Verringerung entsprechender kommerzieller Arcade-Systeme auf MAME-Basis bedeuten.
In seiner zweiten Stellungnahme erklärte Foley deshalb erneut, dass man kein Interesse an einer Nutzung des MAME-Namens oder -Logos habe. "Wir wollen nur Wege finden, um die illegale Distribution von klassischen Arcade-Spielen zu verhindern. Wir werden unsere [Marken-]Anmeldung gerne stornieren und mit dem MAME-Team zusammen arbeiten um sie den rechtmäßigen Eigentümern zukommen zu lassen; doch wir wollen sichergehen, dass die Marke nicht an jemanden geht, der sie kommerziell nutzen will."
UltraCade will nun mit der Community zusammen arbeiten, zumindest hat Foley seine Bereitschaft dazu geäußert, und verspricht, weitere alte Arcade-Spiele für einen vernünftigen Preis auf den Markt zu bringen. Die weitere Entwicklung bleibt also abzuwarten.
Quelle und Links : http://www.golem.de/0502/36447.html
SiLæncer:
Beschreibung einer gesellschaftlichen Utopie
M.A.M.E. steht für Multiple Arcade Machine Emulator und der Name ist heute, nach 10 Jahren Entwicklungszeit, schon fast eine Untertreibung. Mittlerweile emuliert die Software etwa 3500 verschiedene Arcade-Spiele aus alten, aber auch aus jüngeren Zeiten. Es bleibt nicht mehr sehr viel auszugraben in diesem Bereich der digitalen Archäologie, weshalb das multiple im Namen schon beinahe eine Untertreibung darstellt. Möglich wurde der immense Umfang des Projekts allein durch eine globale Kollaboration von vielen Freiwilligen. Ich möchte den 10. Geburtstag zum Anlass nehmen, meine persönlichen Erfahrungen als Teilnehmer dieses Projektes zu beschreiben und die Anfänge einer gesellschaftlichen Utopie daraus abzuleiten.
Es gibt sie noch, die bewundernswerten Leistungen, die nur Gemeinschaften von enthusiastischen Kollaborateuren vollbringen können, dessen bin ich mir sicher. Ich habe es erlebt und erlebe es noch immer, wenn ich auch selbst in den letzten Jahren wenig Code dazu beigetragen habe. Das M.A.M.E. Projekt wurde am 5. Februar 1997 von Nicola Salmoria mit der Freigabe des Quellcodes zur Version 0.1 seines Emulators gestartet. MAME 0.1, das umbenannte MultiPac, konnte mehrere Versionen von Pac-Man emulieren und bald kamen weitere Spiele hinzu - zunächst die, die auf fast identischer Hardware liefen.
Schon sehr bald nach Veröffentlichung der ersten Version setzte dann ein Effekt ein, den viele vermutlich von den bekannteren Vertretern der konzertierten Entwicklung freier Software her kennen: von Linux und OpenBSD, Apache und Sendmail, Mozilla und wie sie alle heißen. Die Umschreibung konzertierte Entwicklung beschreibt den Vorgang recht gut, denn wie bei einem Konzert spielen viele Instrumente vielleicht kleine, aber jeweils wichtige Rollen, ohne die das Gesamtwerk unvollständig wäre. Ich bin in der glücklichen Lage, im Falle von MAME ein wenig aus der Innenansicht einer solchen Kollaboration vermitteln zu können. Und ich bin natürlich froh, mit meinem Beitrag zu MAME ein wenig zurückgeben zu können an die, die auch für mich solche Dinge wie freie Betriebssysteme und die ganze Welt der freien Software geschaffen haben.
Das MAME-Projekt leistet nebenbei noch Aufgaben, die eigentlich staatliche wären, nämlich die Sicherung und Bewahrung der Geschichte und Kultur eines Teils der Jugendzeit einer ganzen Generation. MAME erhält und dokumentiert die Geschichte und Kultur der ungefähr Mitte bis Ende der 1970er Jahre aufkommenden Arcade-Spiele. Archive und Museen wären für diese Aufgabe zuständig und sind es mittlerweile auch offiziell, doch wie sollten es Kuratoren und Archivare leisten, die zerfallenden und oft schon irreparablen Artefakte der Anfänge der Arcade-Spiele für zukünftige Generationen zu bewahren? Wie sollten sie die Unmengen der Entwicklungen kategorisieren, katalogisieren, archivieren und noch dazu erlebbar erhalten? Es muss für sie beinahe unmöglich sein, denn sie sind vielleicht nicht immer enthusiastisch genug oder schlicht technisch überfordert mit dieser Aufgabe.
Am Anfang stehet eine Idee – und der Wille, andere am Ergebnis teilhaben zu lassen
Wie kommt es zu einer solchen Kollaboration von Freiwilligen? Wie kommt ein Projekt zustande, dem keine Planung, ja nicht einmal eine konkrete Absicht in Richtung eines Großprojektes vorausgehen? Ich kenne die ursprüngliche Intention Nicola Salmorias nicht, als er die erste Version seiner Arbeit freigab und kann daher nur meinen eigenen Antrieb in weit weniger erfolgreichen Projekten zu einem solchen Schritt darlegen.
Man hat sich also für ein Thema interessiert, man hat etwas herausgefunden und auch ein Stückchen Software geschrieben, das es zuvor so noch nicht gab. Nun kann man sich für einen von zwei Wegen entscheiden. Man kann versuchen, daraus in irgendeiner Weise einen Gewinn zu erzielen, indem man die Idee selbst oder die Anfänge der eigenen Umsetzung vermarktet. Dies aber ist nicht bei allen Arten von Software möglich und im Falle von MAME wäre es, wegen der vielen Fußangeln der das so genannte Geistige Eigentum umrankenden Gesetzgebung, unmöglich gewesen. Der alternative Weg ist, dass man andere teilhaben lässt am eigenen Stolz auf das bereits Geleistete. Man veröffentlicht seine Idee, seinen Quellcode, sein Projekt und wartet ab, was weiter passiert. Genau genommen gibt es auch noch einen dritten Weg. Man lässt alles in einem der gammeligeren Bereiche seiner Festplatte herumliegen und wartet darauf, dass ein Projekt irgendwann ohne Spuren zu hinterlassen im Orkus der misslungenen Datensicherungen verschwindet. Dieser Weg wird meist wohl eher unfreiwillig beschritten.
Am Anfang steht also eine Idee und meist auch noch die spezifische Begabung, sich um einen Teilaspekt dessen, was einen wirklich interessiert, was man sich selbst zum Hobby auserkoren hat, in neuartiger und für andere interessanter Weise zu kümmern und so den ersten Schritt zu tun. Man steckt sich selbst ein Ziel, um zu sehen, ob man etwas erreicht, und will dann, falls dies tatsächlich gelungen ist, andere auch an der eigenen Freude über den Erfolg teilhaben lassen. Es steckt sicherlich auch Eitelkeit in dem Beginn und vielleicht auch in einem großen Teil der weiteren Entwicklung eines jeden freien Softwareprojektes. Es steckt aber vor allem ein kreativer Umgang mit neuen Techniken in MAME, denn vor 10 Jahren war das Internet noch nicht sehr verbreitet und eine weltweite Kollaboration wie die, die zu dem führte, was MAME heute ist, wäre wenige Jahre zuvor noch unmöglich gewesen.
Ich vermute, dass ein solcher Antrieb, also eine gewisse Eitelkeit, auch in jedem Künstler steckt, der seine Musik vor Publikum spielen will, der seine Prosa oder Lyrik vortragen will, der seine Bilder auf einer Vernissage oder seine Werke in einem Museum ausstellen will. Es gibt wenigstens eine Art der Beschäftigung mit dem Computer, wenigstens eine Art des Lösens von selbstgestellten Aufgaben, die sich als künstlerisches Schaffen bezeichnen lässt - und vermutlich gibt es sogar viele. Sicherlich gilt dies nicht für jede Software, denn bei weitem nicht jedes Projekt enthält auch nur irgendeinen Ansatz einer Leistung im Sinne von künstlerischem Schaffen. In einigen Projekten kann die Entwicklung von Software eher schon mit klassischer Maloche vergleichbar sein, wie vielleicht mancher Leser aus eigener Erfahrung bestätigen wird. Die Freiwilligkeit und die Arbeit aus reinem Interesse unterscheiden, wie ich meine, hier die Kunst vom Gewerbe.
Der wesentliche Unterschied zwischen einem nichtöffentlichen Projekt, also einer sogenannten closed source software und der Art von Entwicklungsumfeld, unter die MAME zu rechnen ist, also der open source software, besteht darin, wie die daran beteiligten Entwickler zusammenkommen. Es ist klar, dass es in einem normalen Projekt ab einer gewissen Größe einen fähigen Projektleiter geben muss, ja geradezu ein Führungs-Genie, das die Leitung der Entwicklung und die Koordination der Entwickler übernimmt. Solche Projektleiter sind oftmals die in den anglizismenüberladenen Stellenanzeigen gesuchten Senior Software Developers, die während ihrer langjährigen Erfahrung bei der Entwicklung von Software nebenbei auch gelernt haben, wie die Konzeption von Projekten anzugehen ist, wie Mitarbeiter frühzeitig richtig einschätzt werden können und wie Probleme vorausgesehen und möglichst vermieden werden. Und manch ein kleines oder auch großes Projekt wird bereits daran gescheitert sein, dass es eben kein Genie an der Spitze gab, welches den Überblick über die Erfordernisse und die notwendige Personalstruktur für eine erfolgreiche Realisierung gehabt hätte. Die Namen der genialsten Fehlleistungen im Bereich großer Software-Projekte in Deutschland dürften heute nicht nur den Programmierern unter den Lesern geläufig sein.
Das Bedürfnis der Korrektur als ein wichtiger Schritt zur Mitarbeit
Im Gegensatz dazu existiert bei einem Projekt wie MAME zunächst nur ein stinknormaler, aber vielleicht visionärer, Programmierer, der seine Idee von Beginn an offenlegt. Er wird, da er kein Genie ist - auch wenn ich bei Nicola in diesem Punkt nicht ganz sicher bin - den einen oder anderen Fehler in seiner ersten Version gemacht haben. Wenn er den kompletten Quellcode bis zu diesem Zeitpunkt selbst geschrieben hat, dann wird er eher viele Fehler gemacht haben. Falls er vor allem auf vorhandenen Bibliotheken aufgebaut hat, wird er vielleicht nicht immer die beste Wahl getroffen haben.
In jedem Falle wird sich aber unter denjenigen, die den frei erhältlichen Quellcode betrachten, die ihn durcharbeiten und zu verstehen versuchen, auch einige geben, die sich ausgerechnet in ihrem Spezialgebiet angesprochen fühlen. So kommt es dazu, dass sich einige dieser Fachleute für einen Teilbereich des Projektes berufen fühlen, etwas an dem veröffentlichten Projekt zu bemängeln und im Idealfall direkt eine Verbesserung beizusteuern. Manche werden bald Erweiterungs- und Generalisierungsmöglichkeiten sehen, die dem Initiator nicht klar waren. Es wächst schrittweise ein Team aus Menschen aus der ganzen angeschlossenen Welt zusammen, die ihre jeweiligen Spezialkenntnisse zusammentragen und bei passender Gelegenheit einbringen.
Nach meiner eigenen Beobachtung scheint das Bedürfnis zu korrigieren zunächst durch eine Art des gewöhnlichen gelernten oder geerbten Konkurrenzdenkens angestoßen zu werden. Mein Einstieg bei MAME war Ende der 1990er der Beitrag einer etwas genaueren und korrekteren Emulation des Z80 Mikroprozessors. Die ersten Kontakte waren Fehlerbeschreibungen und Hinweise auf Ungenauigkeiten im damaligen Z80-Core per E-Mail an Nicola Salmoria und Mirko Buffoni. Dieselben Fehler hatte ich bei meinen eigenen Versuchen zuvor auch schon gemacht und es hatte lange gedauert, sie zu finden und auszumerzen. Ich wurde auf die Mailingliste der Entwickler eingeladen und irgendwann schrieb ich dann einen komplett neuen Quellcode für diese CPU-Emulation, nur basierend auf den vorherigen Erfahrungen und auf bereits korrigierter Dokumentation zu den Interna dieser CPU.
Ein solcher Neubeginn ist eine Sache, die manch betagtem Projekt irgendwann gut zu Gesicht stünde. Es muss nicht unbedingt ein Neuschreiben des kompletten Codes sein, denn manchmal reicht es vielleicht aus, sich an den Programmierstil des Vorgängers zu gewöhnen. In besagtem Fall wollte ich aber unbedingt alles besser machen. Eine gewisse Zeit lang war ich dann tatsächlich mittendrin statt nur dabei und konnte einige tausend Zeilen Code beitragen, einige weitere CPU-Emulationen für MAME schreiben und ein paar Treiber zur Emulation abstruser Hardware (z.B. DECO-Cassette-System) beisteuern. Auch ein weniger geglückter Versuch, ein Spiel ohne CPU zu simulieren (Pong), gehört zu meinen Erfahrungen aus und mit MAME.
Irgendwann ist es dann so weit, dass man stolz darauf sein kann, seinen Beitrag zu etwas geleistet zu haben, das man sein Hobby nennt und für das man auch schon zuvor viel seiner Freizeit hergegeben hatte. Man ist froh und glücklich, dass die eigene Leistung, wie klein sie auch sein mag, im Rahmen eines Projektes nützlich ist, das weit über das hinaus geht, was man alleine je hätte leisten können. Der eigentliche Antrieb dazu, freiwillig und unbezahlt etwas zu einem Projekt beizutragen, ist sicherlich genau dieses Erfolgserlebnis und das Gefühl, etwas Sinnvolles geleistet zu haben. Und ja, mir ist bewusst, dass dies nur so lange möglich ist, wie man sein Geld aus anderer Quelle erhält, genau dazu aber später noch mehr.
Irgendwann kommt der erste Rückschlag
Andere im Team beginnen, Fehler darin zu finden, worin man sich selbst schon als Perfektionisten und als beinahe päpstlich unfehlbar ansah. Hier ein dummer logischer Fehler, dort eine Fehlinterpretation des Fliegendrecks auf dem Jota als I-tüpfelchen und schließlich hat man noch durch mangelnde Aufmerksamkeit und Weitsicht richtig üble Fehler in das Projekt oder den Code anderer eingebracht. Und wir wissen spätestens seit Lubarskys Gesetz der kybernetischen Entomologie: Es gibt immer noch einen weiteren Bug. Das Auffinden des vorletzten Fehlers im eigenen Code durch einen anderen im durchaus wechselnden Team der Entwickler passiert aber notwendigerweise irgendwann, denn es gibt bei jedem Problem und der niedergeschriebenen, versuchten Lösung auch einen Teilaspekt, mit dem sich ein anderer Spezialist noch ein wenig besser auskennt als der vergleichsweise Generalist, der man selbst ist. Und wenn es keinen Teilaspekt mehr gibt, der ungenau oder verbesserungswürdig wäre, dann gibt es doch ein übergeordnetes Konzept, das zu erkennen einem selbst die Größe und der Weitblick fehlte.
Die Frage, ob man an diesem Punkt bei einem Projekt bleibt, oder ob man mehr oder wenig beleidigt das Weite sucht, liegt vielleicht am jeweiligen Selbstverständnis und der bereits erlangten Selbstsicherheit oder auch Abgebrühtheit. Viele Spezialisten, auch und gerade in der Spezies der Programmierer, neigen zu einer sehr speziellen Variante des Autismus. Diese Neigung drückt sich in so gelegenen Fällen durch einen Rückzug von oder Austritt aus der Gemeinschaft der Entwickler aus. Wenn so jemand sich in seinen Ansichten korrigiert, sich demokratisch überstimmt oder gar vom Überlegenen verbessert sieht, sich bei einem dummen Fehler ertappt oder sonstwie überholt oder ausrangiert erkennt, dann nimmt er einfach seinen Hut und geht. Manchmal ist es auch nur eine Auszeit, ein Rückzug zur Besinnung. Dennoch ist die Teilnahme an einem Projekt wie MAME nicht als Einbahnstraße anzusehen, bei der jeder nur seinen Code abliefert und außer dem Endprodukt sonst nichts erhält. Vielmehr gibt das Projekt einem Teilnehmer auch neue Fähigkeiten in sozialer Kompetenz zurück, sowohl in der Einschätzung der eigenen Person, als auch im Umgang mit den Kollaborateuren.
Wie sieht es unter diesem Aspekt und im Vergleich dazu bei, ich nenne sie mal so, herkömmlicher arbeitsteiliger Projektarbeit aus? Dort werden oftmals ähnliche Situationen entstehen. Jemand macht Fehler und es gibt hoffentlich einen Kollegen, der sie erkennt und darauf hinweist oder sie direkt ausmerzt. Wenn es niemanden gibt, dann bleibt das fertiggestellte Produkt später unnötigerweise fehlerhaft. Passieren Fehler bei vielen Projekten oder andauernd, dann zeugt dies dafür, dass ein mit der Projektleitung beauftragte Genie wenigstens einen der Mitarbeiter, zum Beispiel mich, in seinen Kompetenzen falsch eingeschätzt hatte. Das Führungs-Genie ist offensichtlich keines. Andererseits führt das Erkennen von Fehlern, wenigstens bei deren zu häufigem Auftreten oder bei zu großem Konkurrenzdruck im Team, auch leicht zu sehr nachteiligen Auswirkungen für den Fehlerverursacher, die sich unter dem unschönen neudeutschen Wort Mobbing zusammenfassen lassen. Schlimmer noch: Fehler können schnell den Job und damit oft genug die Existenz kosten, wenigstens aber den gewohnten Lebensstandard.
Die Freiheit, versagen zu dürfen
Dieser Artikel ist ein Plädoyer für die Entwicklung von Software unter möglichst wenig existenziellem Druck und unter möglichst großer Wahrung von Freiheiten. Die selbstgewählten Schwierigkeiten und die noch nicht erreichte Gelassenheit beim Eintreten der Feststellung, dass man sich selbst überschätzt hatte, sind für viele schwer genug zu verkraften, auch ohne dass davon direkt ihre Existenz betroffen sein müsste. Ich vertrete somit die Ansicht, dass Software-Projekte von allgemeinem Interesse und gesellschaftlicher Nützlichkeit in offener Form und mit freiwilliger Beteiligung der Entwickler ausgeführt werden sollten.
Der Grund ist schnell gesagt, denn er liegt beinahe genau dort, wo auch die Gründe für das Überdauern der in Erinnerung gebliebenen Wunderwerke unserer Altvorderen liegen, die sie im Bereich der Wissenschaften und der Künste zustande gebracht haben. Der Grund liegt in der Freiheit, versagen zu dürfen. Der Weg zu jeder herausragenden Leistung ist gepflastert mit den Bruchstücken und Trümmern der Versuche derer, die sich zuvor vergeblich darum gemüht hatten. Das ist es, was wir uns wieder vergegenwärtigen sollten.
Die Gesamtleistung eines Teams von freiwilligen Entwicklern, die sich ihre Aufgaben aussuchen können und die dabei Fehler machen dürfen, ja notwendigerweise machen müssen, wenn nur die Anzahl der Kollaborateure groß genug ist, lässt sich wohl kaum je mit einem ausgewählten, von einem Projektleiter zusammengestellten Team erreichen. Wer in einem Team von freiwilligen Entwicklern dabei bleibt, obwohl er erkennen musste, dass er nicht das Genie ist, für welches er sich selber hielt, hat dennoch viel zu erwarten. Er wird aus den Fehlern lernen, die er zuvor gemacht hatte. Er wird neue Erfahrung gewinnen aus der Art, wie andere seine Fehler korrigierten. Er wird diese spezielle Art von für ihn vielleicht typischen Fehlern immer seltener machen und er wird, nachdem die erste Ent-Täuschung überwunden ist, erfreut darüber sein, dass er dennoch dabei geblieben ist. Er wird irgendwann erkennen, dass auch sein Beitrag notwendig war, damit das große Ganze gelingen konnte. Er wird seine eigene Leistung besser schätzen lernen. Er wird mehr Selbstbewusstsein erlangen, als er zuvor hatte. Er ist, kurz gesagt, glücklicher.
Was sind im Vergleich dazu die Konsequenzen für denjenigen, der (zu) viele Fehler in einem klassisch organisierten Projekt macht? Er wird entweder versuchen, seine Fehler zu vertuschen oder, schlimmer, sie jemand anderem im Team anzulasten. Wenn er klug und anständig ist, dann wird er sich irgendwann nach einem Beruf umsehen, in dem er weniger Fehler machen muss, falls dies möglich ist. Sollte er aber bei seinen Vertuschungsversuchen auffliegen, dann fliegt er auch leicht aus seinem Job und damit aus seiner sozialen Sicherheit. In Deutschland landet er dann leicht in dem sozialen Abgrund, der mit einem unsäglichen, weil verbrannten, Namen verbrämt mittlerweile leider nur mehr eine Umschreibung für "zum Leben zuwenig - zum Sterben zuviel" ist.
Förderung der Wissensgesellschaft
Dieses Plädoyer spricht also dafür, die Entwicklung von für die Gesellschaft nützlicher oder notwendiger Software auf ein völlig neues, aber gleichzeitig uraltes Konzept umzustellen. Die Gesamtleistung einer Gruppe von freiwillig zusammenarbeitenden Menschen, also von Kollaborateuren im positiven Sinne, wird notwendigerweise mit der Zeit höher werden, als die von ausgewählten, zusammengestellten Teams jemals sein kann, da selbst die Randfiguren und die Versager aus dem heutigen Sprachgebrauch von denjenigen lernen wollen und lernen werden, die ihnen ihre Fehler aufzeigen, ohne sie dafür zu verachten oder gar zu verbannen.
Der ausgedienten Idee der Leistungsgesellschaft und dem unerträglichen, weil allgegenwärtigen, Leistungsdruck sollten wir die verdiente Abfuhr erteilen. Niemand hat, bloß weil er sich neu-liberal nennt, das Recht, die durch genetische Vorbedingungen oder soziologische Umgebungsvariablen völlig zufälligen Voraussetzungen des Einzelnen als Maßstab für dessen Teilnahmewürdigkeit an der Gesellschaft und deren Errungenschaften und Fortentwicklung herzunehmen. Jeder Mensch kann etwas, oftmals etwas sehr spezielles und leicht zu übersehendes, und die überalterte Idee der Leistungsgesellschaft hat sich lange schon als unfähig erwiesen, für jeden Menschen die angemessene Würdigung seines Beitrags zum Ganzen zu liefern.
Wir müssen Politiker in Deutschland und in der EU dafür gewinnen, nun wirklich einmal Budgets in derselben Größenordnung, wie sie oft genug unnötigerweise an global agierende Konzerne verschenkt werden, in die Entwicklung freier Software zu stecken. Universitäten und Hochschulen boten schon immer einen Rahmen dazu, der aber ergänzt und erweitert werden sollte. Es wäre sehr befruchtend, würde man den einfachen Hauptschüler und die berüchtigte Frau von der Straße in die Lage versetzen, bei solchen Projekten mitzuarbeiten, die ihn oder sie interessieren. Das eigene Interesse sollte mit Vorrang vor gemessener Leistung behandelt werden und ein größeres Vertrauen in Selbstkritikfähigkeit des Einzelnen sowie in die Selbstorganisationsfähigkeit von kollaborativen Gruppen wäre hilfreich.
Eine Bereitstellung von offenen Mailinglisten, Wikis, Archiven und Foren für Deutschland- oder EU-weit geförderte Projekte, in denen sich Interessierte treffen könnten, wäre ein erster Schritt. Die vorgeschriebene Offenlegung allen gewonnenen Wissens, aller Software, sowie aller Erkenntnisse aus staatlich finanzierten Projekten für jeden gehörte selbstverständlich dazu. Kurz gesagt sollte der Weg in eine Wissensgesellschaft nicht bloßes Lippenbekenntnis sein, sondern tatkräftig auch finanziell angegangen und bestritten werden mit den Mitteln, die derzeit kontraproduktiv in die Abschottung von Wissen, in Ausweitung der Ungleichheiten oder gar in die Verbreitung von Verdummung gepumpt werden. Die gezielte Förderung von Projekten, in denen sich Fachleute wie Quereinsteiger, Hobbyisten wie Profis, Endanwender wie Entwickler treffen würden, ließe dann in Schritt zwei eine Aufwandsentschädigung für die Arbeit und die investierte Zeit der freiwilligen Kollaborateure zu.
Die Utopie am Ende einer solchen Entwicklung ist natürlich eine Gesellschaft, in der jeder sich ein oder mehrere ihn interessierende Gebiete aussuchen kann, um in den offen zugänglichen Projekten und Arbeitsgemeinschaften zu den jeweiligen Themen teilzunehmen. Die Interessen sollten ohne weiteres wechseln können, falls sie sich als Irrweg, als Selbstüberschätzung oder als zu kurzlebig herausstellen.
Der Kern dieser Utopie ist die vollständige Entkopplung der Arbeitsleistung von der Existenzsicherung und damit die Absage an den Leistungsdruck, der rein aus dem Selbsterhaltungstrieb entsteht. Ein jeder sollte beliebig viele Fehler machen und auch komplett versagen dürfen - ist dieser überholte Begriff unvermeidlich? Es wären immer genügend Kollegen, Generalisten und Spezialisten als Nichtversager da, die diese Fehler erkennen und auffangen würden, die den Fehlerverursacher aber ohne Arroganz zu verbreiten mitlernen ließen und ihm bei seinem totalen Versagen immer noch neue Wege zeigen könnten, die er versuchen könnte. Im übelsten anzunehmenden Fall, ich denke etwa an Trollerei und Intrigenspinnerei, würde die restliche Gruppe von Kollaborateuren jemanden auch ignorieren und einfach machen lassen, denn diese Dinge wären ja aus der Erfahrung mit vergleichbaren Projekten bereits bekannt und würden durch die größere Gesamtleistung der Gruppe mitgetragen. Die Volksweisheit: "Jeder taugt zu etwas und sei es als schlechtes Beispiel" könnte ohne weiteres wörtlich angewandt werden.
Wenn ich hier meine Erfahrungen mit einer vergleichsweise kleinen Gruppe ohne weiteres auf die Gesellschaft der ganzen Welt interpoliere, dann möchte ich mir und anderen damit diese Utopie und die Möglichkeit ihrer Umsetzung erhalten. Diese Utopie ist der Inhalt meines Traums von einer lebenswerten Gesellschaft, auf dessen Aufführung auf einer Bühne der realen Welt ich einen kurzen und erhellenden Blick werfen durfte. Die Idee der Funktionsfähigkeit einer freiwilligen Kollaboration ist in dieser relativ kleinen Gruppe der MAME-Devs keine Utopie, eben weil sie nachweislich realisierbar war. Wenn diese Utopie je im großen Rahmen versucht werden sollte, dann wahrscheinlich lange nach meinem Ende, aber auch das stimmt mich nicht trauriger, als der aktuelle Zustand dieser Welt und der immer ungangbarere Weg, auf dem sehr viele sich lust-, hoffnungs- und perspektivlos voranschleppen müssen. Wohin eigentlich?
Quelle : www.heise.de
SiLæncer:
Universalemulator für viele längst vergessene (Home-)Computer und Spielekonsolen; basiert auf dem MAME-Kern
Die Auflösung des Akronyms MESS, „Multiple Emulator Super System“, sagt alles: Der Universalemulator bringt viele längst vergessene (Home-)Computer und Spielkonsolen unter einem Dach zusammen, von Atari 2600 bis ZX81.
MESS ist ideal, um den Gören Computerspiele aus der eigenen Kindheit zu zeigen und klarzumachen, dass man auch ohne kreischende Lüfter auf der Grafikkarte Spaß haben kann. Freilich lässt sich auch perfekt der Highscore von damals verbessern oder die längst vergessen gewähnten Kenntnisse des im ROM integrierten Basic-Dialekts auffrischen. Wissen Sie noch den Befehl, um das Inhaltsverzeichnis von der 1541-Floppy des Brotkastens zu laden?
Der Ansatz von MESS, eine universelle Basis zu bauen, die für jedes zu emulierende System letztlich nur eine Beschreibung erhält und ansonsten auf fertige Emulationscodeblöcke zurückgreift, erinnert nicht von ungefähr an den Multiple Arcade Machine Emulator (MAME), der verschiedene Spielautomaten in ähnlicher Weise emuliert - MESS und MAME teilen eine große Menge Code, werden aber von getrennten Teams vorangetrieben und getrennt veröffentlicht.
MESS selbst kennt rund 150 Systeme. Um ein einzelnes dieser Systeme zu beleben, braucht es aber die Original-ROMs und Images von den seinerzeit gebräuchlichen Datenträgern, das können Disketten, Kassetten, Cartridges oder sogar Lochkarten und -streifen gewesen sein. Den gleichzeitigen Vertrieb von Emulationssoftware mit ROM- und Disk-Images untersagen die MESS-Entwickler aufgrund rechtlicher Bedenken.
Wer solche Images nicht selbst anfertigen kann oder will, kann sich mit einer Suchmaschine geduldig an die Fersen etlicher Server heften, die dieses Material im Internet zum Download anbieten. Anders als bei heute aktueller Software operieren die Anbieter der Dateien in einer Grauzone, denn heute ist oft nicht mal mehr klar zu ermitteln, wer etwa die Rechte am BIOS des einstigen Robotron-Mikrocomputers hält ...
Zwar ist MESS für den Mac und als X/Linux-Software zu haben, aber die reichen nicht an die Windows-Version heran: In der Mac-Variante laufen viele Systeme nicht und in der X-Version scheitert mitunter die Steuerung der emulierten Systeme mit Maus und Tastatur, und den Komfort einer grafischen Bedienung darf man auch nicht erwarten; es gibt zwar Ansätze, eine MESS-Oberfläche für Gnome oder KDE zu konstruieren, doch die sind meistens schon vor Jahren im Sande verlaufen ...
Die von MESS nachgebildeten Systeme laufen längst nicht alle perfekt. Eine vollständige Liste findet sich auf der Homepage des Projekts - ein paar Beispiele: Apple II+/e/c und Commodore in allen Spielarten, Pet, VC20, C64 und C128, Colour Genie, TSR-80 und TI-99, Oric, ZX81 sowie diverse Schneider-Computer. Es finden sich auch Exoten wie BeBox und Apple Lisa in der Liste - sie sind allerdings (noch) nicht komplett unterstützt.
Während heutige Emulatoren und Virtualisierungslösungen wie VMware, VirtualPC oder QEMU einen nahezu aktuellen PC perfekt nachbilden wollen, emuliert MESS tatsächlich die alte PC-Hardware, etwa einen PC/XT oder AT mit 80286-CPU. Es kann deshalb etwa eine Bus-Maus (nicht mit einer PS/2-Maus zu verwechseln) anbieten, wie sie ältere PC-Betriebssysteme womöglich erwarten, zum Beispiel Windows 1 oder Visicorps Visi On. Auch überfordert es die alte Software nicht mit unbekannten CPU-Eigenschaften oder einem unvermutet großen Hauptspeicher.
http://www.mess.org/
SiLæncer:
Weitere Infos sowie ein Changelog findet sich hier : http://mamedev.org/
SiLæncer:
Weitere Infos sowie ein Changelog findet sich hier : http://mamedev.org/
Navigation
[0] Themen-Index
[#] Nächste Seite
Zur normalen Ansicht wechseln