Wenn man sich mal anschaut, was beim eigentlichen Hauptprojekt Firefox bzgl. Mac-Optimierung schon passiert ist, derzeit abgeht und un naher und ferner Zukunft bevorsteht (z.B. Nutzung von bestimmten Apple Technologien wie Core Animation etc.), so dürfte dieser Satz auch schon längst nicht mehr stimmen.

Abgesehen davon setzt diese Camino-Verion mit diesem Release die Gecko Rendering-Engine der Version 1.9.0.18 ein. Wie wir alle wissen, war diese Stand der Dinge vor gut einem Jahr, also zu Zeiten von Firefox 3.0.x (17.06.2008 bis 30. Juni 2009, als Gecko von der Version 1.9.0.x mit Firefox 3.5 auf die Version 1.9.1 gehoben wurde). Siehe dazu auch , , .

In der Zwischenzeit ist viel in der Fortentwicklung nicht zuletzt auch von Gecko passiert (JavaScript-Geschwindigkeit, Acid3-Test, CSS3 Features, etc.).

Die Rendering-Engine (in diesem Fall: Gecko) ist es, die den Browser zu dem befähigt, was er mit den Webseiten von heute so anstellen kann, nicht das Drumherum, nicht das GUI.

Das sollte jeder Camino-Nutzer wissen, der Webseiten von heute mit Camino betrachtet. Camino hinkt da eklatant zurück. Und auf dem Feld der Betriebssystem-Integration holt Firefox seit einiger Zeit mit großen Schritten auf bzw. liegt gleichauf mit Camino oder hat ihn sogar auch dort langsam überholt (bzw. setzt grad' zum Überholen an).

Und wenn man sich mal die Camino Roadmap anschaut, so wird da in Zukunft mit Camino wohl auch nicht mehr viel passieren.

1. Ist Firefox nicht das Hauptprojekt. Ser Camino Browser hat ein eigenständiges Team, das nichts mit Firefox zu tun hat (betonen sie immer wieder).

2. OMG! Fast 8 Monate alt! Ich weiss nicht wo das Problem liegt. 8 Monate ist wie gerade eben.

3. Camino ist sehr angenehm. Etwas anderes zählt in erster Linie nicht.

@sierkb: Hi. Es gibt bereits eine Experimental-Version (Camino2.1a1pre) die auf Gecko 1.9.2.2pre basiert.

Das ist ein guter und wichtiger Schritt für das Camino-Projekt !

Zu finden hier:

Gruss
mem0

maczock:

Zu 1.: wo kann ich das nachlesen? Meines Wissens sind die Tonangeber des Projektes, allen voran Mike Pinkerton, entweder bei Mozilla beschäftigt und an der Hauptentwicklung von Firefox beteiligt und beschäftigen sich quasi "nebenbei" mit Camino, oder sie sind, wie z.B. Mike Pinkerton, hauptberuflich inzwischen bei Google beschäftigt und werkeln hauptsächlich an Google Chrome herum -- also auch da ist Camino dann eher das Hobby denn das Hauptprojekt.

Daswas Du da meinst, das war einmal -- in den Anfangstagen von Camino. Und ist Jahre her. Und dann wurde das Team entweder aufgelöst bzw. bekam eine Weisung "von ganz oben" die Arbeiten einzustellen, oder/und das Kernteam löste sich dann selber in seine Bestandteile auf... Wie gesagt: Mike Pinkerton arbeitet hauptberuflich inzwischen für Google an der Mac-Version von Chrome, und der damalige Mitinitiator von Camino, Dave Hyatt, hat vor einigen Jahren auch die Fronten gewechselt und arbeitet inzwischen für Apple an WebKit/Safari und ist sehr rege in der HTML Arbeitsgruppe des W3C. Gerade auch der Weggang von Hyatt zu Apple hat nicht zuletzt auch bei Pinkerton die Motivation in den Keller gebracht bzw. Pinkerton hat seine leitende und zusammenführende Funktion beim Camino-Projekt abgegeben an die Community. Von der allerdings mangels Interesse und schwindendem Interesse nicht viel kam und nicht viel kommt.

Camino läuft als Hobby-Projekt einiger weniger, die das als ihr Baby betrachten und nur schweren Herzens loslassen können. Die Hauptentwicklung, die Musik spielt inzwischen bei Firefox. Face it! Dave Hyatt hat das früh erkannt, und auch Pinkerton hat das erkannt, sonst hätten sie nicht die Seiten gewechselt.

Zu 2.: Jeder, wie er mag. Es gibt Leute, die installieren sich noch gerne veraltete Software, die weniger kann und langsamer ist als die aktuelle (dafür aber vielleicht eine schönere Verpackung hat, wobei hier "schön" wirklich Ansichtsache ist)...

Einem Firefox-Benutzer, der sich mit Deiner Begründung noch den Firefox 3.0 installieren würde oder einem Safari-Nutzer, der sich mit der Begründung noch Safari 3.0 installieren oder einem IE-Nutzer, der sich noch IE7 installieren würde obwohl es IE8 gibt, würdest Du einen Vogel zeigen...

Zu 3.: siehe 2.

mem0:

Das mag sein und würde sich auch mit den entsprechenden Hinweisen in der Camino Roadmap decken:

ABER: wann wird diese Version denn fertig sein und ausgeliefert werden? Dann, wenn Firefox schon wieder weitergestapft sein wird und in der Version 4.0 vorliegen wird (also Ende diesen Jahres)? Noch später? 2011? Wie weit wird Gecko dann sein? Bei Version 1.9.5? Bei Version 2.0? Wie weit wird Camino dann, was Gecko betrifft, zurückhinken? Wenn Du Dir die bisherige Entwicklung und die bisherigen Zeitspannen anschaust, dann kannst Du Dir das leicht selber aus- bzw. hochrechnen.

maczock:

Die Gecko-Linie der Version 1.9.0.x lief vom 17.06.2008 bis zum 30.06.2009. Innerhalb einer solchen Linie gibt es i.d.R. keine Feature-Veränderungen, sondern höchstens Bugfixes bzw. Security-Bugfixes.

Featuremäßig ist Gecko 1.9.0.18 (also die Version, die Camino derzeit einsetzt) also auf dem Stand vom 17.06.2008, bestenfalls auf dem Stand vom 30.06.2009. Das aktuelle Bugfix-Release vom 17.02. zählt featuremäßig nicht (wie alle anderen Bugfix Releases übrigens auch nicht), weil es eben ein Bugfix Release ist.

Wenn ich dann mal korrekt zurückrechne (und die Bugfix Releases zwischendurch mal draußen lasse), dann sind das keine 8 Monate, die Camino bzgl. Firefox/Gecko zurückliegt, sondern ganze 12½ Monate mehr, also ganze 20½ Monate. Wie gesagt: die Bugfix-Releases zwischendurch zählen nicht, denn da wurden keine Features hinzugefügt bzw. Gecko in seinen Grundzügen verbessert. Wäre das der Fall, würde sich das auch in der Major/Minor-Nummer der Version widerspiegeln, die sich nur dann erhöht, wenn Features hinzugefügt wurden bzw. wenn Gecko signifikant verbessert worden ist.

HTML5 <audio> und <video> z.B. wurde erst mit Firefox 3.5 (Gecko 1.9.1) hinzugefügt. Ähnliches bzgl. der Verbesserungen der JavaScript-Engine Tracemonkey.
Von alledem profitiert der aktuelle Camino überhaupt nicht: er kann das schlicht noch nicht, weil die verwendete Gecko-Engine das eben nicht kann. Und es wird erfahrungsgemäß noch eine Weile (siehe die Zeitspannen bisher) dauern, bis er es kann.

Was der aktuelle Camino derzeit alles nicht kann aufgrund seiner hinterherhinkenden Gecko-Engine, das kann man sich leicht zusammenreimen, wenn man z.B. die Feature-Liste von Firefox 3.5 und Firefox 3.6 liest.

Ich nutze Camino auf meinem Powerbook G4. Das ist ein alter Rechner und er hat nicht viel Ressourcen.

Firefox braucht bei mir immer so 500MB RAM.
Der Camino ist da deutlich sparsamer.

Das ist für schon ein Grund!

blauzahn:

Derzeit aber auch der einzige Grund, den man gelten lassen könnte.
Und dass auch der so langsam nicht mehr gelten wird bzw. Camino selbst diesem Grund einen Riegel vorschieben wird, das ist spätestens dann offenbar, wenn Camino mal auf die aktuelle Gecko-Linie eingeschwenkt sein wird, welche dann nur noch Cocoa-Support bieten wird bzw. alle neueren Features von Gecko nur noch als Cocoa vorliegen werden und nicht als Carbon-Code. Auch bei Mozilla sind die Totenglocken für Carbon schon längst eingeleitet. Weil Apple das vor Jahren auch so vorgegeben hat.

Das heißt: neue und Cocoa-basierte Sachen wird es auf alten, vornehmlich Carbon-basierten Macs nicht geben können. Bzw. man geht auch bei Mozilla konsequent den von Apple lange angekündigten und empfohlenen 64bit Cocoa-Weg.

Siehe dazu auch:

Mozilla Wiki: Mac:Home Page
Mozilla Wiki: Mac:Roadmap

U.a. steht da für Gecko unmittelbar bevor:

Dann kommen noch die ganzen Features hinzu rund um Core Animation und die Prozesstrennungen für Tabs und für Plugins.
Die alten Mac-Systeme bringen die Voraussetzungen auch bzgl. des Cocoa-Frameworks gar nicht mehr mit, um da noch mithalten bzw. das umsetzen zu können bzw. das dort vorhandene Cocoa-Framework ist auf dem Stand, auf dem es eben ist und wird von Apple da nicht weiter erneuert. Folglich sind einige Dinge auf so alten Systemen gar nicht mehr möglich. Gleiches auch bzgl. des Java-Plugins2, welches von Apple schon seit längerem vorbereitet wird.

Das kleine Camino-Team wird das alles nicht aufhalten und zurückdrehen können.

Und das heißt dann auch irgendwann für bisherige Camino-Nutzer: Ende der Fahnenstange, da wird es irgendwann in nicht allzuferner Zukunft eine letzte, rückwärtsgewandte Camino-Version geben, welche auf alten Systemen wie dem Deinigen noch läuft. Und neuere Camino-Versionen eben nicht mehr. Wenn es denn in der Zukunft noch groß neuere Camino-Versionen geben wird. Weil Firefox immer mehr von dem hat, was einst das alleinige Terrain und der Vorteil von Camino war. Oder es wird keine neueren Camino-Versionen mehr geben, weil die Annäherung zu groß geworden ist, um ein solches Extra-Projekt noch länger zu rechtfertigen und vor allem weil man viel zu wenig Ressourcen (Personal!) hat, um zwei sich auseinanderbewegende Browser-Zweige noch zu pflegen. Das Camino-Team hat ja bei einem einzigen Zweig schon enorme Schwierigkeiten, den Anschluss zu Firefox und Gecko halten.

Es sollte bei den hartnäckigen Camino-Anhängern langsam mal ein Einsehen geben, dass Camino mal ganz am Anfang seine Berechtigung hatte, dass aber sein Zenit inzwischen immer deutlicher überschritten ist. Camino hat seine Zeit und seine Berechtigung gehabt. In der Vergangenheit. Und mittlerweile geht die Fortentwicklung und die Zeit über ihn hinweg und macht ihn langsam aber sicher einigermaßen überholt und obsolet.

Was interessiert mich der der ganze Technik Schmarrn von Gecko & Co.

Camino ist übersichtlich, schnell, anwendungsfreundlich und braucht wenig Resourcen. Genau die Dinge auf die es beim Surfen mit meinem Macbook ankommt.

"und braucht wenig Resourcen"
Wohl kaum
Sowohl Camino als auch Firefox fressen mehr Resouren als Safari.

Ein Grund ist, dass FF oder C bei mehreren geöffneten Tab, die inaktiven, also nicht angezeigten Tabs nicht still legt. Was auch immer auf dem Tab aktiv ist - Flash-Werbung oder animierte Grafiken, werden im Hintergrund durchgenudelt.

Ich bin grad (wieder) auf iCab als Zweit-Browser umgestigen, da sich dieser in der Beziehung wie der Safari verhält und eh auf WebKit basiert.

Ciao... Camino.
Firefox bleibt um evtl. Seiten, die nicht Kompatibel sind öffnen zu können.

sszszszzszsszszzzszszsszzszszszzszzsz:

Das interessiert Dich spätestens dann, wenn Camino Seiten, von denen Du genau weißt, dass sie von anderen Browsern anders/besser/schneller angezeigt werden, nicht so anzeigt, wie Du es gerne hättest, weil seine Rendering-Engine nicht dem aktuellen Stand entspricht.

HTML5 Video kannst Du derzeit knicken mit Camino. Und zwar komplett.
Ebenso die in Firefox in Kürze kommenden Out-of-Process-Plugin-Geschichte, wo jedes Browser-Plugin dann in einem eigenen Prozess läuft. Gleiches bzgl. Out-of-Process-Tabs.
Bzgl. des Acid3-Tests, der einigen Zeitgenossen vor allem der Safari-Fraktion ja monatelang feuchte Träume beschert hat, hinkt Camino folglich auch hinterher und kann noch nicht auf dem Stand mitreden, auf dem sich der aktuelle Firefox befindet.
Core Animation wird in Kürze Einzug erhalten mit Firefox dagegen (z.B. animierte Tabs, die langsam in ihre Position gleiten): , . Viele wesentliche Teile von Firefox werden auf den Core Techniken und auf Core Animation basieren, die erst in Leopard Einzug erhalten haben und in Snow Leopard aus gebaut worden sind.

All' solche Sachen halt. Ob Camino da bei dem vorgelegten Tempo und auch von den verwendeten Frameworks mithalten kann (gerade auch das Entwickler-Personal und die Benutzerbasis betreffend)?

zeko:

Bzgl. Deiner Tabs: warte mal drauf, dass die Out-of-process-Geschichte in Firefox vollständig umgesetzt wird und dann jeder Tab seinen eigenen Prozess erhalten hat (Antreiber bei dem ganzen Vorhaben bei allen Browser-Herstellern: Flash. Um es isoliert zu bekommen und ggf. gesondert abschießen zu können, wenn es mal wieder Amok läuft (memory leaks!) und den ganzen Browser in Beschlag nimmt uns ausbremst). Derzeit konzentriert man sich dort leider noch sehr auf die Windows-Version, die muss wohl zuerst fertig werden und unter die Leute kommen, und dann erst kommt die Version für den mac und für Linux dran...

@sierkb: Ich verstehe diesen ganzen Hype um die Out-of-Process-Plugin-Geschichte nicht !!!

Wenn ich mir beispielsweise Chromium anschaue, bei dem das ja bereits umgesetzt ist, ist die CPU-Last bei Flash-Inhalten doppelt, wenn nicht sogar 3x, so hoch als bei FF/Camino.

Also... was bringt mir dann das ganze, wenn ich mein MacBook nach 10 YouTube Videos wieder an die Steckdose hängen kann !

@oben
Zitat: "Das interessiert Dich spätestens dann, wenn Camino Seiten, von denen Du genau weißt, dass sie von anderen Browsern anders/besser/schneller angezeigt werden, nicht so anzeigt, wie Du es gerne hättest..."

Wenn dem so wäre würde ich ganz unpragmatisch einen der anderen Angesprochen nutzen. Mir gehts um keinen Glaubenskrieg in Sachen Browser. Jeder soll den nützen, mit dem er sich anwendungstechnisch am wohlsten fühlt. Und deshalb sind andere Meinungen genauso OK.

Fakt ist z.B. bei der umfangreichen Livewettseite von b365.com ist Camino flotter, niemals hängt das "Rädchen" zum laden - und er stürzt auch nicht ab. Ob andere da technisch zukunftsträchtiger sind, eine neuere Pre-Betaversion haben oder sonst was - ist mir deshalb wurscht.
Nur die Handhabung in der Praxis zählt. Und da ist Camino zumindest auf meinem 1,5 Jahre alten Macbook voraus.

sierkb: Dein Einsatz für Firefox in allen Ehren...

... aber im Alltagsgebrauch ist Camino (zumindest die Nightlies) nachwievor der schnellere Browser. Da ist der sogar schneller als Safari. Besonders, wenn viele Tabs im Spiel sind. Da ist von dem gigantischen Abständen in diversen Benchmarks absolut nichts zu spüren.

Ich hätte allerdings nichts dagegen, wenn irgend wann mal beide Projekte mergen. Bislang gefällt mir Camino aber nachwievor besser.

mem0:

Mehr Prozesse verschlingen mehr CPU- und RAM-Ressourcen -- jedenfalls mehr als bei einem Thread-basierten Modell, wie das bisher gehandhabt wurde, das ist in soweit korrekt. Und genau deshalb haben sich die Browser-Hersteller auch nicht drum gerissen, hier umzustellen. Weil alles seine Vor- aber auch seine Nachteile hat. Gerade auch bei Mozilla hat man da lange gezögert. Aber einerseits hat gerade Flash alle Browser-Hersteller hier zum Handeln gezwungen, irgendetwas zu unternehmen (die Crash-Logs, die die Browser in Richtung der Betriebssystem-Hersteller und in Richtung der Browser-Hersteller absenden bzw. abgesendet haben, haben in einer Großzahl der Fälle imemr wieder gezeigt: Hauptursache für einen amoklaufenden Prozess/Thread war immer irgendwie Flash bzw. irgendwelche Speicher-Lecks (memory leaks) davon gewesen bzw. ließ sich darauf zurückführen bzw. stand damit in Verbindung. Bei allen Browser-Herstellern). Und wenn Adobe eben nicht in die Puschen kommt, sein Flash ressourcenschonender und vor allem ohne Speicher-Lecks zu bauen, dann mussten sich eben die Browser-Hersteller was einfallen lassen. Und deshalb gibt's dann halt für jedes Plugin und für jeden Tab jeweils eigene Prozesse. Die dann, sollte eine Webseite in einem Tab da mal Amok laufen, getrennt von evtl. anderen offenen Tabs und Webseiten abgeschossen bzw. wieder neu gestartet werden können (auch für Letzteres gibt es zumindest bei Mozilla Pläne, hier z.B. UI-Elemente zur Verfügung zu stellen, die dem Benutzer da was in die Hand geben für den Fall der Fälle).

Profitieren davon tun dann von diesen Maßnahmen alle Plugins und insgesamt eben die Stabilität des Browsers. Und nicht zuletzt dadurch auch das Image des jeweiligen Browsers. Denn wie oft hat man pauschal erstmal dem Browser die Schuld gegeben, wenn er eingefroren war oder abgeschmiert ist, obwohl vielleicht nur ein Plugin bzw. eine Browsererweiterung die eigentlich amoklaufende Ursache war/ist.

Das Ganze wird erkauft durch einen höheren Speicherbedarf und in dem einen oder anderen Fall auch einer etwas höheren CPU-Last (erst recht unter 64bit-Betriebssystemen bzw. 64bit-Anwendungen), das siehst Du richtig. Aber das wird dann eben durch die höhere Gesamtstabilität bzw. durch die größere Kontrolle über amoklaufende Prozesse wieder wettgemacht.

exAgrajag:

Finde ich überhaupt nicht. Bezogen auf Caminos Nightlies.

Das tun sie bereits seit längerem -- zumindest, was Cocoa und die OS-Integration angeht, falls es Dir noch nicht aufgefallen ist -- nur mit dem Unterschied, dass Camino schon seit längerem nicht mit dem hinterherkommt, was bei Firefox alles Einzug erhalten hat, Firefox inzwischen aber ziemlich viel von dem angenommen und integriert hat, was Camino einst von der Mozilla-Suite/Phoenix/Firefox abhob.

Was z.B. die Cocoa-Umsetzung angeht: der Cocoa-Code, der z.B. in Camino drin ist, der ist schon seit Jahren Bestandteil auch der Codebasis von Firefox. Nur lag sie bei Firefox eben brach und wurde nicht genutzt, und von Camino wurde der im gemeinsamen Code-Tree vorhandene Cocoa-Code eben genutzt.

Mir nicht. Schon allein vom Äußeren her mag ich ihn nicht bzw. weniger als Firefox. Und ich empfinde ihn schon vom Äußeren her als größeren Fremdkörper unter MacOSX als Firefox. Überhaupt empfinde ich Firefox besser ins OS integriert als Camino. Und bei manchem, was mancher Nutzer bei Camino als so gelungen lobpreist, muss man bei näherer Betrachtung feststellen, dass das im Detail entweder gar nicht soo gut gelungen ist wie mancher vorschwärmt, bei Firefox inzwischen auch vorhanden ist (nur in meinen Augen eben besser umgesetzt) oder dort auf der Agenda steht, bald umgesetzt zu werden.

Und allem voran eben: Gecko.

Was nutzt mir ein schön ins OS integrierter Browser (wobai einerseits Ansichtsache ist, was "schön" ist und was "gelungene" Integration heißt), wenn er bzgl. seiner Rendering-Engine, bzgl. seines Herzstücks, sprich: wegen dessen er eigentlich Web-Browser heißt bzw. das ihn zum Web-Browser macht, dermaßen der aktuellen Entwicklung zurückhängt wie das Camino tut?

Was ist ein solcher Browser wirklich wert, der zwar für einige Leute schön anzusehen ist (wie gesagt: Ansichtssache, Geschmäcker sind verschieden -- ich finde das Aussehen von Camino im Vergleich zu Firefox hässlich und viel fremdartiger im Vergleich zu anderen nativen Anwendungen), dessen Motor aber 2 Generationen zurückhängt?

Bei mir jedenfalls ist die Leistung der Rendering-Engine in der Bewertung jedenfalls vorrangig vor dem Aussehen des Drumherums. Und zwar deutlich. Der schöne äußere Schein nutzt mir nix. Das ist eigentlich schmückendes Beiwerk.

Meine Bewertung sähe anders aus, wenn Camino eine aktuelle Gecko Rendering-Engine beinhalten würde. Und wenn sein Äußeres anders wäre. Und wenn auf Camino-Seite und entwicklungstechnisch die Post abgehen würde und dort regelmäßig echte Pflöcke in den Boden gerammt würden, an denen sich sowohl Firefox als auch andere Browser ein Beispiel nehmen könnten. Und weil das so nicht ist, präferiere ich eben Firefox -- weil das in dieser Hinsicht (und in letzter bzw. seit geraumer Zeit) dort eher der Fall ist als bei Camino.

Bei Camino passiert eigentlich nix mehr. Außer dass man in recht langen Abständen und zum wiederholten Male auf eine Gecko-Version aufsetzt, die vor 20 Monate aktuell war...

Das Feuer und die Luft brennt inzwischen woanders.

Ich kann nur soviel sagen, daß sich Camino für mich schneller anfühlt, als FF und Safari. Und das ist für mich relevant. Camino macht alles, was ich brauche zur vollsten Zufriedenheit. Und es ist Rocksolide. Ich kann mich an keinen Absturz oder Zwangsabschuss erinnern. Meine Freundin ist vor ein paar Monaten sogar von FF auf Camino umgestiegen, weil ihr die FF-Performance mit vielen Tabs auf den Zünder ging. Sie hat ständig weit >20 Tabs offen – manchmal hab ich das Gefühl, sie nutzt sie als Bookmarks.

Aber alle paar Monate schau ich mir FF mal an – ist eigentlich mal wieder Zeit...

Hst du dafür ein Beispiel?
Bin mir ja ansonsten recht sicher, so stimmt es nicht.

Aronnax:

Mozilla Wiki: Cocoa Widgets

Als erster Hinweis in der Sache. Ansonsten: Code-Tree(s) anschauen.

Und hier siehst Du mehr zum Thema Cocoa-Umsetzung in Gecko:
Mozilla Wiki: Mac:Roadmap

@sierkb
Nun, nicht wirklich
Hierfür haben sie praktisch nichts von Camnio übernommen. Es wurde mehr oder weniger komplett neu erstellt und Camnio hat dann wieder den neuen Kram von FF übernommen, mit einigen Änderungen allerdings.

Und das du ja Quellenangaben über alles liebst
http://boomswaggerboom.wordpress.com/?s=Cocoa+Widgets
http://boomswaggerboom.wordpress.com/2007/01/18/mozilla-mac-os-x-update/

Aronnax:

Deine Aussage widerspricht überhaupt nicht dem, was ich gesagt und zitiert habe.
Spätestens dann, als der besser geschriebene Cocoa-Code im Gecko/Firefox-Tree neu geschrieben und dort angelegt worden ist, ist dann bzgl. Camino Stück für Stück in Camino dieser bessere Code rüberportiert worden -- als besserer Ersatz für den eigenen, schlechteren Code. Und ab dem Moment haben beide aus ein und demselben Code-Repository gezehrt bzw. zehren bis heute: nämlich von dem besser geschriebenen Cocoa-Code, den die Mozilla/Firefox-Leute geschrieben und angelegt haben.

Oder?

Ach, nur dazu etwas, weil es wohl die interessanteste Anekdote zu Camino ist.

Sie hatten Monate daran gearbeitet, Camino/Chimera als neuen Mac Netscape Navigator herauszubringen.
Alles war schon fertig z.B. CDs erstellt u.s.w. und nur wenige, oder gar nur einen Tag bevor es raus kommen sollte wurde es von einem AOL/Time Warner Manager gecancelt.
Alles schon sehr tragisch und auch ein gutes Beispiel, wenn man verstehen will, warum es AOL und Netscape heute nicht mehr gibt

Aronnax:

Zu den Blogeinträgen von Mike Pinkerton: die habe ich vor einer Weile mal alle ziemlich aufmerksam gelesen. Und seitdem auch seinen Feed abonniert. Deshalb habe ich auch mitbekommen, wie er über die 64bit-Portierung von Firefox geschrieben hat bzw. seitdem verfolge ich die mit. In Kürze wird es also auch standardmäßig 64bit builds von Firefox geben, derzeit baut man da noch an der Build-Umgebung bzw. splittet sie auf in Leopard builds und Snow Leopard builds. Hierfür hat man extra eine ganze Build-Armada an Mac Minis dastehen, die einerseits builds unter Leopard und für Leopard erstellen und andererseits welche mit SL, die extra 64bit SL builds erstellen. Von Universal binaries (32bit L/64bit SL) hat man abgesehen.
Ist wohl nur noch eine Frage von Tagen, bis die ersten builds auf den FTP-Servern landen.

Ich habe gestern in diesem Zusammenhang via IRC erstmal diesen Bug hier angestoßen bzw. wiederbelebt, sodass man nun endlich auch mal fürs automatische Updaten der Nightlies via Shell-Skript einen Soll/Ist-Vergleich bzgl. der Version bzw. bzgl. der Build-ID machen kann (und zwar bevor man sich was herunterlädt).

Aronnax:

Ja, die Geschichte ist mir bekannt.
Hier der passende Vortrag im Rahmen der Google Tech Talks dazu, wo Pinkerton das alles nochmal selber in eigenen Worten und sehr eindrucksvoll erzählt. Sehr sehenswert und aufschlussreich dieses Video.
Es gibt auch ein Ars Technica Interview zu dem Thema, wo's auch nochmal niedergeschrieben ist.

Erwarte es ja schon länger, aber niemand, den man so fragt, weiß etwas genaues dazu.
Gut zu wissen, dass es nun wirklich bald losgeht

Aronnax:

Falls es Dich interessiert und Du auf dem Laufenden sein willst zum Thema 64bit builds für Mac, schreibe Dich doch in den CC von folgenden Bugs bzw. lies sie Dir mal durch:

Bugzilla Mozilla: Bug 468509 - Gecko 64-bit Mac OS X support

Bugzilla Mozilla: Bug 519060 - [Tracking bug] officially support Mac OSX 10.6 64-bit builds

Bugzilla Mozilla: Bug 545539 - create new osx10.6 64bit ref image and ref docs
Bugzilla Mozilla: Bug 545542 - Setup 20 new osx10.6 buildslaves with buildbot
Bugzilla Mozilla: Bug 548109 - Reimage 40 old talos-rev2 minis for production 10.6 build/unittest pool

Aronnax:

Nachgereicht:

Mozilla Wiki: Mac:64BitRelEng