Nach dem ersten Anlauf für einen Haiku ARM-Port im Zuge von Johannes Wischerts GSoC 2009 Projekt lief erstmal nicht mehr so viel in diese Richtung. Heute wie damals sind offenbar noch zuviele x86 Baustellen offen, um diese Aufgabe zu stemmen. Zwischenzeitlich haben sich Ithamar Adema, François Revol und zuletzt Alexander von Gluck um ARM gekümmert, aber noch steht der Port ganz am Anfang.
Bei ARM ist ja das Problem, dass es sich nicht wie bei x86 um eine wohl definierte Plattform handelt, sondern dass es eine Unmenge von Lösungen mit unterschiedlichen Chips rund um einen ARM-Prozessor gibt.
Zur Zeit ist der Raspberry PI angesagt, weshalb die jüngsten Bemühungen auch auf dieses preiswerte System abzielen.
Hoffnung auf einen Haiku-Port für den Raspberry könnte nun aus einer unvermuteten Ecke kommen. Beim Panorama Computer Club hat man den PI genauer ins Visier genommen und ist sehr daran interessiert auch Haiku darauf laufen zu sehen. Bisher stecken die Anstrengungen ebenfalls noch in den Kinderschuhen, aber falls jemand Interesse hat mitzuhelfen, insbesondere auch nicht-virtuell beim Besuch im Clubhaus in Duisburg, ist herzlich eingeladen.
Freitag, 19. Oktober 2012
ARM Anstrengungen beim Panorama Computer Club
Abonnieren
Kommentare zum Post (Atom)
An die leider nur kurze Blütezeit des Acorn RISC PCs erinnere ich mich noch gerne. Ich war fasziniert von den Charakteristika der ARM CPU. Der würde in ein Haiku-Konzept eines OSs auf der Basis einer preiswerten Hardware gut passen.
AntwortenLöschenMeine Versuche, am Haiku Projekt mitzuwirken,sind leider bislang daran gescheitert, dass meine Kommunikationsversuche gegen feste Wände gelaufen sind.
Sollte es irgendwann doch noch einmal eine neue Alpha- oder sogar Beta-Version geben, die dann auch auf einem ARM laufen können soll, werde ich erneut meine Mitwirkung anbieten.
Gruß, Reinhard.
Hi Reinhard!
AntwortenLöschenKannst Du ein paar Links zu Deinen Mailinglist-Beiträgen oder Patches auf dem Bugtracker etc. posten? Dann könnte man mal sehen woran es gescheitert ist und die Ursachen ggf. abstellen.
Was den ARM-Port betrifft, bezweifle ich dass es da in absehbarer Zeit eine umfassende Haiku Version gibt. Sicher, nichts ist unmöglich wenn sich motivierte Leute drum kümmern, siehe den weit gediehenen x86_64 Port. Die größte Hürde ist m.E. die fehlende Stabilität der ARM-Plattform: Bemühungen für eine ARM-Plattform (z.B. Johannes' Beagleboard) sind nach einem Jahr "veraltet" wenn eine neue Plattform, z.Zt. Raspberry, erscheint. x86_64 ist dagegen über viele Jahre stabil und gestattet so mehrere Anläufe mehrerer Entwickler über die Jahre.
Aber gut, lassen wir uns überraschen.
Gruß
Humdinger
Da waren schon mehrere frustrierende Anläufe meinerseits, schon zu BeOS und Zeta Zeiten. Jetzt hatte ich mal wieder eine eher lange Pause eingelegt. Es gab da einige schon ziemlich weit gediehene Vorschläge, die String-Verarbeitung auch für UTF8 Strings kompatibel aufzudröseln, jedoch wollte man das nicht. In Ländern ohne Umlaute sieht man eben dafür offenbar keinen Bedarf. Vielleicht ist nun auch die Zeit endgültig für 16-Bit Characters gekommen, und UTF8 hat in Haiku ausgedient.
AntwortenLöschenWas eine aktuelle Plattform für x86_64 für Haiku angeht, wäre ich gespannt interessiert. Es war schon schwierig genug, unter Mac OS X und VMware ein funktionierendes 32er Haiku hin zu bekommen. Ich träume von einer Möglichkeit, eine solche VM auf eine neue alpha oder beta Release hin einfach aktualisieren zu können, und diese danach auch noch vollständig ins Deutsche zu lokalisieren.
Zeitweise hatte ich noch vor, mein 10x8/8x8 Schachprogramm für Haiku komplett überarbeitet neu aufzusetzen. 64-Bit wären hier eine starke Motivationshilfe, Doch was nützte eine interessante Anwendung ohne ein vorzeigbares Zielsystem?
Mit optimistischen Gruß, Reinhard.
> Jetzt hatte ich mal wieder eine eher lange Pause eingelegt. Es gab da einige schon
Löschen> ziemlich weit gediehene Vorschläge, die String-Verarbeitung auch für UTF8 Strings
> kompatibel aufzudröseln, jedoch wollte man das nicht.
Als nicht-wirklich-Programmierer kann ich nicht sagen, wer da wen missverstanden hat... Wen's interessiert, der Thread war wohl dieser:
http://www.freelists.org/post/haiku-development/BString-method-SymbolAt-proposal
Die letzte Mail dort von Michael Lotz deutet an, dass eine Lösung gefunden/umgesetzt wurde. War das in Deinem Sinne, Reinhard?
Ich kann nur sagen, dass ich als User keine Probleme bei der Darstellung von besonderen Symbolen mehr sehen. Selbst Terminal kann mit Dateinamen á la "€urop@" umgehen.
> In Ländern ohne Umlaute
> sieht man eben dafür offenbar keinen Bedarf. Vielleicht ist nun auch die Zeit
> endgültig für 16-Bit Characters gekommen, und UTF8 hat in Haiku ausgedient.
Nachdem ein Großteil der Entwickler aus Deutschland und Frankreich kommen, dürfte es nicht am Desinteresse liegen.
> Was eine aktuelle Plattform für x86_64 für Haiku angeht, wäre ich gespannt
> interessiert. Es war schon schwierig genug, unter Mac OS X und VMware ein
> funktionierendes 32er Haiku hin zu bekommen. Ich träume von einer Möglichkeit,
> eine solche VM auf eine neue alpha oder beta Release hin einfach aktualisieren zu
> können, und diese danach auch noch vollständig ins Deutsche zu lokalisieren.
Die Deutsche Lokalisierung (und über 25 weitere Sprachen) ist so ziemlich abgeschlossen.
Ich hab zwar wenig Erfahrung mit VMs, aber theoretisch müsste man eine neue Haiku Version booten, die alte Partition mounten und dann per Installer das neue Haiku über das alte bügeln können. Komfortabler wirds erst mit den Betas und dem Packagemanagement.
> Zeitweise hatte ich noch vor, mein 10x8/8x8 Schachprogramm für Haiku komplett
> überarbeitet neu aufzusetzen. 64-Bit wären hier eine starke Motivationshilfe, Doch
> was nützte eine interessante Anwendung ohne ein vorzeigbares Zielsystem?
Ich erkenne nicht was an einem 32bit Haiku weniger vorzeigbar wäre als bei einer 64bit Version. Vielleicht kann nicht der komplette Speicher genutzt werden (wobei PAE die Situation entschärft. ...glaub ich, mein Sytsem ist 6 Jahre alt und hat nur 2gb... :) ) und manche Sachen laufen evtl. ein paar Prozent langsamer als optimierter Code für 64bit. Aber die Essenz von Haiku ist davon nicht betroffen.
Gruß,
Humdinger
Was UTF8 angeht glaube ich, dass die wenigsten damit entsprechend gearbeitet haben. Zeichenweise Analyse, Positionsbestimmung, Austausch eines (dynamisch beliebig eingegebenen) Zeichens laufen bei Umlauten eben vor den Baum.
AntwortenLöschen>... Ich erkenne nicht was an einem 32bit Haiku weniger vorzeigbar wäre als bei einer 64bit Version. ...
Entscheidend ist hier ja nicht die sprachlich im Vordergrund stehende Bitzahl - hier würden mir 32 voll ausreichen. Es ist der in x64 Prozessoren verdoppelte Registersatz. Bedenkt man, dass davon stets ein Teil vom System belegt ist, führt der Übergang zu den neuen CPU Möglichkeiten zu einer Verdreifachung der frei verfügbaren Register. Das kann bei einer geschickten maschinennahen Programmierung eine Menge an Tempo ausmachen. Und wenn man sich schon mal die Mühe eines Relaunchs macht, will man auch das Optimum heraus holen.
Gruß, Reinhard.
Hallo Reinhard,
LöschenDeine Kritik an UTF-8 Programmiermöglichkeiten ist vielleicht nicht mehr aktuell? Bitte schau Dir nochmal support/String.h an. Dort gibt es jetzt (sämtliche?) Methoden sowohl als Byte-Position als auch als Char-Position-basiert. Mit "Char" meine ich jetzt ein Multibyte-Zeichen.
Ich habe jedenfalls vor ein paar Tagen am Text-Tool von WonderBrush gearbeitet und diese Methoden haben mir für dynamisch veränderte BStrings auf UTF-8 Basis komplett die Arbeit abgenommen.
Na, wie man sieht schlagen auch bei Dir zwei Herzen in der Brust: Haiku auf Schmalspur-ARM und auch auf Massen-Register-x86_64. Solange keine CPU-Port-Fachmänner dem Projekt zuströmen, ist doch x86_32 ein guter Kompromiss. :)
AntwortenLöschenGruß,
Humdinger
Wie wahr! Mein Herz schlägt eigentlich für die konsistent designte ARM RISC CPU. Leider gibt es dazu noch keine überzeugende Hardware-Umgebung. Der x64 ist dagegen fast bis zu Adam und Eva abwärts kompatibel, verschenkt so etwa 75% mögliche weitere Performance, und sein Assembler ist ein Sammelsurium sonder Gleichen. Aber er beherrscht den Markt und hat nun ab 64 Bit genügend Register frei.
LöschenGruß, Reinhard.