Ich glaube, ich muß echt auch mal ne News schreiben und einschicken. Wenn da nochmal Korrektur gelesen wird, dann kann man sich doch wenigstens dahingehend schon mal nicht blamieren. :-)
"Der Hauptgrund sei das Fehlen einer stabilen Linux-Version von Chromium 4." ... "Google habe bislang auch auf Nachfrage nicht kommuniziert, wann eine stabile Linux-Version zur Verfügung stehen wird, offiziell hat Chromium 4 bislang nicht einmal einen Betastatus." ... "Google behandle sie aber als Teil von Chromium und führe daher ständig Änderungen des APIs durch."
Wenn sie noch nicht fertig ist, dann ist sie eben noch nicht fertig. Ist doch Fedoras Problem, wenn sie das unbedingt jetzt schon paketieren wollen statt auf eine stabile Version zu warten.
Aus der gleichen Code-Basis wird eine Windows-Version erzeugt die der User ohne jeden Hinweis auf "nicht fertig" oder "nicht stabil" installiert.
Google sch***** einfach durchgängig auf sämtliche grundlegenden Praktiken der Software-Entwicklung, dass das auch noch in einem Open-Source-Projekt passiert bei dem Leute mitarbeiten möchten die nicht bei Google am Mittagstisch sitzen (wo grundlegende Änderungen ja anscheinend besprochen werden) ist traurig.
Und vor allem ist es ganz sicher keine gute Idee es sich mit den Packagern der großen Distributionen zu verscherzen, auch wenn Google wahrscheinlich sowieso meint dass Chrome OS die Weltherrschaft übernimmt.
>Aus der gleichen Code-Basis wird eine Windows-Version erzeugt die der >User ohne jeden Hinweis auf "nicht fertig" oder "nicht stabil" >installiert.
Die Windowsversion ist schon seit langem stabil. (Glaubste nicht? Probiers aus. ;-))
>Google sch***** einfach durchgängig auf sämtliche grundlegenden >Praktiken der Software-Entwicklung Du meinst wohl "Opensource-Software-Entwicklung". Mich würde interessieren, welche Praktiken das sein sollen. In der Realität ist es doch eher so, dass jedes größere Projekt eine komplett andere Politik fährt.
>Und vor allem ist es ganz sicher keine gute Idee es sich mit den >Packagern der großen Distributionen zu verscherzen, Eine noch schlechtere Idee ist es es sich mit den Usern zu verscherzen...
Nun irgend etwas läuft da wie es sich mir darstellt gewaltig schief. Ich habe hier auf einen Testrechner schon eine Weile die Linuxversion (Beta) von Iron (http://www.srware.net/forum/viewtopic.php?f=17&t=833), welcher ja auf Chromium basiert, laufen und diese ist bisher selbst bei garstigen Seiten nicht abgestürzt. Was also mach das doch nicht allzu große Unternehmen SRWare besser als andere?
Es gab überhaupt keinen Grund, die KHTML Engine als Fork bei Apple weiterzuentwickeln. Es ist zwar Anfangs leichter, auf diese Art und Weise deine Benütigten Features in das Paket einzupflegen, langfristig führt es aber zu einem kompletten Fork der im Endeffekt mehr kostet als wenn man einfach an einem Projekt teilnimmt.
Und Google wiederholt diesen Unfug, anstatt mit upstream zusammenzuarbeiten. Die Folge: Weniger Wiederverwertbarkeit von Code, die Distributionen schwellen an, weil sie diese Doppelgleisigkeiten mittragen müssen, alle verlieren dabei.
Es wäre trotzdem nicht so schnell voran gegangen, wenn man auch noch mit dem ursprünglichen Upstream zusammenarbeiten müsste. Das schwächste Glied in der Kette bestimmt halt das Tempo. Und wenn man dann immer noch alles zusätzlich weniger versierten Entwicklern (ohne irgendwelche kränken zu wollen) erklären muss, dann würde das einfach nur bremsen. Gerade deswegen entwickeln sich Chrome und WebKit so wahnsinnig schnell, weil eben solche Bremsen nicht bestehen.
Also bei Webkit kann ich so ein Wahnsinnstempo gegenüber KHTML nicht feststellen. Die haben mit 10fachem Arbeitseinsatz eine kleine Programmiertruppe die das hauptsächlich in der Freizeit macht noch nicht dramatisch abgehängt.
Und das, obwohl die Rückportierung von Code aus Webkit relativ schwierig ist (d.h. die können nicht einmal so einfach Trittbrett fahren).
KHTML war und ist ein KDE-Projekt, d.h. es besitzt Abhängigkeiten zu Qt und KDE-Libs. Das allein ist schon Grund genug für WebKit. Du glaubst doch nicht, dass Apple für eine Basisbibliothek seines Betriebssystems Qt einsetzt. Genauso wenig würden die KDE-Entwickler auf Signal/Slot verzichten.
Wie sieht das eigentlich mit Debian sid aus, unter chromium sichte ich da nur ein Ballerspiel. gibts ne chance das chromium-browser es nach Debian schafft? gibts nur Probleme mit den geforkten libs oder auch Lizensprobleme?
Von Fliegender Holländer am Do, 3. Dezember 2009 um 02:39 #
Die Aussage ist auch falsch. Es kommen keine Pakete von ihm. Übrigens sowohl für Ubuntu als auch für Fedora. Was andere machen steht woanders geschrieben.
> Da mittelfristig keine Besserung in Sicht ist, wird Fedora - im Gegensatz zu etwa Ubuntu - auch weiterhin keine eigenen Chromium-Pakete ausliefern.
Seit wann liefert denn Ubuntu offiziell Chromium in den normalen Paketquellen aus?
Alles was es für Ubuntu gibt ist ein PPA in dem Daily-Builds von Chromium vorhanden sind. Und diese Pakete sind auch nicht getestet, da sie von einem Bot kompiliert und paketiert werden. Zudem ist das PPA kein offizieller Teil von Ubuntu, sondern ein privates PPA eines einzelnen Entwicklers.
Google gibt Support für Chrome auf Ubuntu/Debian, die bereitgestellten DEB-Pakete tragen sogar das Google-Repository in APT ein. Ubuntu bietet über Launchpad offiziell Nightly Builds an.
Bei Fedora hostet der Maintainer die Pakete auf seiner privaten Webseite.
> Google gibt Support für Chrome auf Ubuntu/Debian, die bereitgestellten DEB-Pakete tragen sogar das Google-Repository in APT ein.
Merkst du was? Es sind Pakete für alle Ubuntu/Debian. Was deine Aussage noch ein wenig blöder macht, ist die Tatsache das es genauso Pakete für OpenSuSE, Mandriva und RedHat gibt. Guckst du hier :
> Ubuntu bietet über Launchpad offiziell Nightly Builds an.
Ich hab per Launchpad auch schon Pakete bereitgestellt (z.B. einen eigene Version des Intel-Grafiktreibers). Macht sie das dadurch zu offiziellen Ubuntu-Paketen? Eher nicht. Die Pakete werden von einem Bot gebaut und paketiert, der Maintainer (Er heißt Fabien Tassin) des PPAs und des Bots ist kein Angestellter von Canonical oder Google, sondern einfach nur ein Mitglied der vollbeschworenen Community.
> Bei Fedora hostet der Maintainer die Pakete auf seiner privaten Webseite.
Prima, schön für ihn.
Nochmal :
Nur weil irgendjemand, irgendein Paket auf Launchpad hostet, wird dieses Paket noch lange nicht zu einem offiziellen Paket von Ubuntu. PPA steht ja auch für "Personal Package Archive" und nicht für "Official Ubuntu Package Archive".
>Alles was es für Ubuntu gibt ist ein PPA in dem Daily-Builds von Chromium vorhanden sind. Und diese Pakete sind auch nicht getestet, da >sie von einem Bot kompiliert und paketiert werden.
Langsam verstehe ich, warum ich den Browser von einem auf den anderen Tag nicht mehr benutzt hab, weil er dann so instabil wurd...^^
Gerade bei Fedora hat man doch häufig svn Builds oder Betaversionen, manchmal sogar in der Default installation - dass dies eine Hürde für Chromium sein soll, wundert mich da.
> Fehler in, meinen Beiträgen korrigiert.
Und das scheint ein Haufen Arbeit zu sein, wenn ich mir den obenstehenden Satz anschaue. Nix für ungut! ;-)
Sebalin.
"Diese sei auch für interessant für andere Browser-Projekte..."
CACert wird kein Hersteller per Default includieren wollen.
Schießmichtot.
Och, nun sei doch nicht so schlecht gelaunt.
Wenn sie noch nicht fertig ist, dann ist sie eben noch nicht fertig. Ist doch Fedoras Problem, wenn sie das unbedingt jetzt schon paketieren wollen statt auf eine stabile Version zu warten.
Google sch***** einfach durchgängig auf sämtliche grundlegenden Praktiken der Software-Entwicklung, dass das auch noch in einem Open-Source-Projekt passiert bei dem Leute mitarbeiten möchten die nicht bei Google am Mittagstisch sitzen (wo grundlegende Änderungen ja anscheinend besprochen werden) ist traurig.
Und vor allem ist es ganz sicher keine gute Idee es sich mit den Packagern der großen Distributionen zu verscherzen, auch wenn Google wahrscheinlich sowieso meint dass Chrome OS die Weltherrschaft übernimmt.
>User ohne jeden Hinweis auf "nicht fertig" oder "nicht stabil"
>installiert.
Die Windowsversion ist schon seit langem stabil. (Glaubste nicht? Probiers aus. ;-))
>Google sch***** einfach durchgängig auf sämtliche grundlegenden
>Praktiken der Software-Entwicklung
Du meinst wohl "Opensource-Software-Entwicklung". Mich würde interessieren, welche Praktiken das sein sollen. In der Realität ist es doch eher so, dass jedes größere Projekt eine komplett andere Politik fährt.
>Und vor allem ist es ganz sicher keine gute Idee es sich mit den
>Packagern der großen Distributionen zu verscherzen,
Eine noch schlechtere Idee ist es es sich mit den Usern zu verscherzen...
Und Google wiederholt diesen Unfug, anstatt mit upstream zusammenzuarbeiten. Die Folge: Weniger Wiederverwertbarkeit von Code, die Distributionen schwellen an, weil sie diese Doppelgleisigkeiten mittragen müssen, alle verlieren dabei.
Glaube auch nicht dass das mehr kostet als wenn man sich die Nerven noch mit irgendeiner Community aufreiben muss statt es einfach selbst zu machen.
Bei KHTML war Apples Verhalten komplett unnötig, und Google hat offensichtlich entschieden nicht daraus zu lernen.
Und das, obwohl die Rückportierung von Code aus Webkit relativ schwierig ist (d.h. die können nicht einmal so einfach Trittbrett fahren).
Für "ein paar Hobby-Programmierer" ist das verdammt gut.
http://blog.jasondonenfeld.com/220
wenn du ihn durchweg benutzen kannst glückwunsch.
KHTML war und ist ein KDE-Projekt, d.h. es besitzt Abhängigkeiten zu Qt und KDE-Libs. Das allein ist schon Grund genug für WebKit. Du glaubst doch nicht, dass Apple für eine Basisbibliothek seines Betriebssystems Qt einsetzt. Genauso wenig würden die KDE-Entwickler auf Signal/Slot verzichten.
html_documentimpl.h verwendet Klassen wie QMap oder QString.
html_documentimpl.cpp enthält connect-Makros.
Kleiner Tipp: http://en.wikipedia.org/wiki/List_of_web_browsers#KHTML-based_browsers
unter chromium sichte ich da nur ein Ballerspiel.
gibts ne chance das chromium-browser es nach Debian schafft?
gibts nur Probleme mit den geforkten libs oder auch Lizensprobleme?
freundliche Grüße an alle Linuxer
iFurz
http://sidux.com/PNphpBB2-viewtopic-t-18859-highlight-chromium.html
läuft hier eigentlich ganz gut.
Ubuntu/Canonical u. Google sind ja auch "best friends"
Seit wann liefert denn Ubuntu offiziell Chromium in den normalen Paketquellen aus?
Alles was es für Ubuntu gibt ist ein PPA in dem Daily-Builds von Chromium vorhanden sind. Und diese Pakete sind auch nicht getestet, da sie von einem Bot kompiliert und paketiert werden. Zudem ist das PPA kein offizieller Teil von Ubuntu, sondern ein privates PPA eines einzelnen Entwicklers.
Wo ist also der Unterschied zu Fedora?
Google gibt Support für Chrome auf Ubuntu/Debian, die bereitgestellten DEB-Pakete tragen sogar das Google-Repository in APT ein. Ubuntu bietet über Launchpad offiziell Nightly Builds an.
Bei Fedora hostet der Maintainer die Pakete auf seiner privaten Webseite.
Merkst du was? Es sind Pakete für alle Ubuntu/Debian. Was deine Aussage noch ein wenig blöder macht, ist die Tatsache das es genauso Pakete für OpenSuSE, Mandriva und RedHat gibt. Guckst du hier :
Google Linux Software Repositories
> Ubuntu bietet über Launchpad offiziell Nightly Builds an.
Ich hab per Launchpad auch schon Pakete bereitgestellt (z.B. einen eigene Version des Intel-Grafiktreibers). Macht sie das dadurch zu offiziellen Ubuntu-Paketen? Eher nicht. Die Pakete werden von einem Bot gebaut und paketiert, der Maintainer (Er heißt Fabien Tassin) des PPAs und des Bots ist kein Angestellter von Canonical oder Google, sondern einfach nur ein Mitglied der vollbeschworenen Community.
> Bei Fedora hostet der Maintainer die Pakete auf seiner privaten Webseite.
Prima, schön für ihn.
Nochmal :
Nur weil irgendjemand, irgendein Paket auf Launchpad hostet, wird dieses Paket noch lange nicht zu einem offiziellen Paket von Ubuntu. PPA steht ja auch für "Personal Package Archive" und nicht für "Official Ubuntu Package Archive".
>sie von einem Bot kompiliert und paketiert werden.
Langsam verstehe ich, warum ich den Browser von einem auf den anderen Tag nicht mehr benutzt hab, weil er dann so instabil wurd...^^
> dass dies eine Hürde für Chromium sein soll, wundert mich da.
Das ist auch keine Hürde für Chromium. Es geht darum, dass Chromium alle möglichen Projekte forkt anstatt mit dem upstream zusammenzuarbeiten.