Google komt met alfa van Chromium voor Linux en OS X

Dat komt omdat Google zich als eerste gericht heeft op het goed werkend krijgen van Google Chrome op het Win32-platform en dat men aanvankelijk het idee had om voor Linux een slap aftreksel van de Win32-versie op te leveren.

Uiteindelijk heeft men besloten om een "echte" Linux-versie te maken, dus eentje die niet als een zeer vreemde eend in de bijt voelt. Dat betekend echter wel dat er veel werk verzet moet worden die eerst niet ingepland stond. Tel daarbij op dat de manier waarom Google de processen opsplits nieuw is (en hoewel 't onder Linux gemakkelijk[er] te realiseren is, de Google Chrome code naar de Win32 API toegeschreven was en dus naar Linux aangepast moest worden)...

Bedenk verder dat het gewoon enorm veel tijd kost om een goede browser te maken, de meeste andere browsers hebben er al 10+ jaar aan ontwikkeltijd op zitten en Google Chrome mag dan wel gebruik maken van WebKit, maar er zijn veel dingen aangepast voor Chrome en die moeten wel allemaal onder de Linux-based OS'en geïmplementeerd en getest worden...

Voor de Mac heeft men hetzelfde probleem, maar dat had men vooraf zelf al ingepland - de Mac OS X gebruiker pikt het nooit als de applicatie niet goed integreerd, maar bij Linux dacht men aanvankelijk nog aan het simpelweg overzetten van de code van Win32 (ik denk ook dat men dit mbv WineLib had willen doen...)

Ik snap niet dat open source programmaatje zo lang word geport naar Linux

Er was bij het ontwikkelen niet echt nagedacht over het portable maken van de code. Chrome is zo dicht tegen Windows-specifieke functies aangeschreven i.p.v. algemene portable code, dat alles weer uit elkaar moet worden getrokken om er een Linux versie van te maken.

Ironisch genoeg heeft Google van Google Earth wel "Qt" gebruikt, waarmee ze wel met 1 codebase hetzelfde product snel op meerdere platformen kan releasen. Waarom dat niet bij Chrome gebeurd is is mij een raadsel.

Hoe kan jij dat weten zonder Chrome geinstalleerd te hebben?

Safari is snel (tenmiste dat zeg jij, nognooit gebruikt) maar misschien is Chrome onder mac nog veel sneller!

Safari is toch veel beter en sneller?
Waarom zou ik Chrome installeren??

Is 'beter' niet een erg subjectief begrip? 'Sneller' kan subjectief zijn, maar is nog te meten met benchmarks en dergelijke.

Verder kan het zo zijn dat men de UI van Google Chrome gewoon fijner vind dan die van Apple's Safari? Ook kan het zijn dat iemand straks onder zowel Linux-gebaseerde besturingssystemen, Mac OS X en MS-Windows dezelfde browser wil gebruiken. En in dat geval heb je nu eigenlijk alleen de keus uit Opera en Mozilla's Firefox en straks kun je dus ook voor Google Chrome kiezen...

Die benchmark is wel al bijna een jaar oud. Er kan in de tussentijd een boel verbeterd zijn.

Een javascript benchmark is ook een vrij zinloze meeting.
Het is hoogstens indicatief maar zegt niet alles over een realistische surf ervaring.
Zo kan een benchmark in een loop 100 keer een identiek javascript statement uitvoeren waardoor je met een JIT precompile veel winst kan boeken maar heb je op een site waar identieke javascript staments maar weinig voorkomen door het precompilen nauwelijk of geen winst.

[Reactie gewijzigd door hAl op vrijdag 5 juni 2009 17:42]

sandboxing op os x schijnt een makkie geweest te zijn omdat freebsd standaard dit soort functionaliteit aanbiedt. voor windows heeft google zelf de basis moeten schrijven voor sandboxing; ms biedt daar geen publieke api voor aan kennelijk

http://arstechnica.com/ap...-os-x-a-piece-of-cake.ars.

Ik betwijfel dus of open source programmeurs hier in grote getale zullen opvliegen om even googles browser te bouwen, zeker als je bedenkt dat google chrome voornamelijk ontwikkeld heeft om verder te concurreren met MS

Bij Mozilla gold al dat je geen programmeur hoeft te zijn om toch bij te kunnen dragen aan het project, door de beta/alpha/nightlies te gebruiken en bugs te melden die je ziet tijdens het gebruik. Iedereen die dus iets meer weer van computers kan dus meehelpen door deze (pre-)alpha versies te gebruiken en de bugs die men tegenkomt te melden.

Natuurlijk is het zo dat Mozilla Firefox inmiddels heel veel wortels heeft in de open source gemeenschap en zo'n beetje standaard bij iedere Linux-distributie meegeleverd wordt. Toch zullen er altijd mensen blijven die weer een andere uitdaging aan willen gaan en meehelpen met Google's Chrome kan voor die mensen weer heel interessant zijn...

enchromium niet uit een "liefde voor het open source idee" voortkomnt waar firefox dichter bij aansluit.

Waarom denk je dat?

Volgens mij is Google redelijk open source minded, kijk bijvoorbeeld eens naar de Summer Of Code die men al weer een aantal jaar achtereen gehouden heeft. Dus men is in elk geval positief tegenover open source...

Ik betwijfel toch dat dit een echt succes zal worden, de opensource community heeft nml al "haar" browser, Firefox, die terecht veel respect krijgt, algemeen als een zeer goede browser beschouwd wordt en een behoorlijke userbase kent.

Chrome marktaandeel groei gaat wel ten koste van FF groei. IE markaandeel daalt nog steeds maar aflopen maand kon niet FF daarvan profiteren maar Chrome wel.

en chromium niet uit een "liefde voor het open source idee" voortkomt waar firefox dichter bij aansluit.
edit:spellingsfoutjes

De render engine komt oorspronkelijk toch echt van linux (of beter: kde), webkit is immers meer een soort fork van khtml.

Ik denk juist dat Google Chrome op Linux meer succes zal hebben dan op Windows (in procenten dan). Linux gebruikers zijn over het algemeen toch meer wat meer tweakers dan Windows gebruikers.

Wbt die statusbar: die verschijnt alleen als hij ook daadwerkelijk wat te melden heeft, daarna verdwijnt hij weer. Geweldig imo

Je baseert je mening over Chrome op een alpha? Prutser

Maar dat wil nog niet zeggen dat de verdere communicatie tussen de host-applicatie en de diverse tabs/windows geen uitdaging is geweest. Een proces isoleren kan dan gemakkelijk zijn, maar daarna moet je het proces nog wel aan kunnen sturen en moet het tab-proces weer gemakkelijk met de 'parent' kunnen praten.

Verder heeft men de UI aan moeten passen op die van Apple, hetgeen ook weer tijd kost...

Dat 1 onderdeel gemakkelijk(er) blijkt te zijn hoeft nog niet te betekenen dat het totaalproces een 'piece of cake' is...