Das Updatesystem von Chrome funktioniert echt gut. Bekomme die Updates gar nicht mit. Laufen komplett im Hintergrund. Nur ein Blick in den Info Button zeigt die aktuelle Version.

So wäre es wünschenswert. Insbesondere für die duzenden Updates die man auf dem Windows PCs machen musste (Java, Flash, HP Druckercenter, Scannercenter etc. ^^ )

Zumindest Windows Update ist dem Mac Äquivalent um Längen voraus. Die Updates werden im Hintergrund heruntergeladen und beim Herunterfahren installiert. Ich als Benutzer werde zu keinem Zeitpunkt von einem Aktualisierungsprogramm genervt, wie es (leider) unter OS X immer noch der Fall ist. Einige Sachen wie Flash und Java lassen sich inzwischen auch automatisch via Secunia PSI auf dem Laufendem halten (sehr empfehlenswertes Programm für alle Windows Benutzer).

das windowsupdate ist die schlimmste Krankheit seit es Computer gibt

das nimmt sich naemlich gern mal das Recht heraus einfach den Rechner herunterzufahren - sehr spassig bei einer Renderfarm

Das ist mir unter Windows 7 noch nie untergekommen. Das höchste der Gefühle an das ich mich erinnern kann, ist ein Hinweis darauf, dass die Installation wichtiger Updates aussteht. Man kann aber durchaus als Administrator via Gruppenrichtlinien einstellen, wann Windows spätestens Updates installiert (mit vorheriger Warnung und Erinnerung, Zwangsinstallation nur für besonders renitente Benutzer), aber das ist meiner Erfahrung nach nicht die Standardeinstellung.

Wenn Du eine Renderfarm kennst, bei der a) Updates nicht über einen eigenen WUS eingespielt werden (wenn's überhaupt dafür Gründe gibt) und b) der Admin es nicht auf die Reihe kriegt das vernünftig zu konfigurieren, dann würde ich mir mal Gedanken über neues Personal machen.

Das wäre ja bei Macusern fatal.Die haben doch immer dieses ominöse "Uptime-Syndrom", die fahren Ihre Rechner doch nie runter.



Ps.: Chrome gefällt mir. hoffe die entwickeln das für MacOSX auch mit Harwarebeschleunigung und Updatesystem etc. ordentlich weiter.

Also ich als MAcuser habe vom Update nix mitbekommen. Gerade die News gelesen und gedacht "dann aktualisiere ich mal". Dann Chrome gestartet, ging zu den Einstellungen und dachte "hmm sah aber gestern noch anders aus" und tada es ist Version 10. Also komplett installiert und alles, ohne, dass ich es merkte.

Mich würde mal n Vergleich Safari < Chrome interessieren.
An der Updatefront für Safari ist es ja ziemlich still.
Muss Chrome hier mit einem Update nach dem anderen daherkommen um auf Safari-Stand zu kommen (man ist natürlich jede Woche in den Medien wenn man jede Kleinigkeit als großes Update verkauft) oder hat Chrome den Safari schon abgehängt?
Weiß hier jemand was?

iEi: Inwiefern "abgehängt"?

iEi:

Wohl eher umgekehrt.

Wohl eher das.

Siehe die laufend aktualisierten Verlaufskurven in dem vom Mozilla-Team geführten Are we fast yet?-Vergleichstest . Die Verlaufskurven zu einem früheren Zeitpunkt:

Und das Google-Team hat jetzt mit deren neuen Crankshaft-JS-Engine nochmal eine Schippe obendraufgelegt. Das Safari-Team muss sich da wohl nochmal etwas anstrengen, um da gegen Google Chrome und Mozilla Firefox 4 mithalten zu können. Zumindest was die JS-Performance angeht. Glücklicherweise befinden die sich alle schon auf einem hohen Niveau , WebKit/Safari hinkt ein klein wenig hinterher (mal sehen, was der wohl demnächst anstehende Safari 5.1 auf Basis von WebKit2 bringen wird).

Absolut betrachtet, sind die alle schon recht ordentlich schnell und auf einem ziemlich ähnlichen Niveau, wie man besonders am Sunspider-Test des WebKit/Safari-Teams und Aza Dotzler (Mozilla) es in seiner privaten Gegenüberstellung sehen kann. Jetzt geht's so langsam eher um die Unterschiede in den Feinheiten -- weiterhin auf einem hohen und bereits schnellen Niveau. Verbesserung aber scheint wohl immer wieder möglich zu sein, wie man bemerken darf.

TITAN
In Punkto Geschwindigkeit, Sicherheitslücken (wichtiger als Geschwindigkeit finde ich), Webstandards etc etc.

sierkb
Danke für die Infos.

Chrome ist toll. Das einzige was immer noch stört ist die sich in der Website am unterem Rand einblendende Statusleiste.

Unter OSX ist natürlich nichts hardwarebeschleunigt!

@fluppy

In den release notes steht nichts davon, dass die Hardwarebeschleunigung der Videowiedergabe auf eine Plattform beschränkt ist.

fluppy:

Bzgl. Chrome: Sicher?
Und allgemein: dann nimm halt einen Browser, der das kann!
Firefox 4 kann's. Vorausgesetzt, Du hast eine Grafikkarte eingebaut (egal, ob nvidia oder ATi oder Intel), die bzgl. OpenGL fit genug ist, um die Befehle zur Verfügung zu stellen, die der Browser benötigt. Bzgl. älterer Grafikkarten (egal, ob nvidia, ATi oder Intel), könnte es sein, dass deren OpenGL-Befehlssatz nicht ausreicht für gewisse vom Browser benötigten Operationen. Bei Firefox 4 hat man deshalb im Moment eine Blacklist und eine Whitelist eingeführt. Auf Firefoxens Blacklist stehen derzeit alle die Grafikkarten, die ein gewisses Alter haben (das Firefox-Team hat da willkürlich ein Datum als untere Grenze gesetzt) oder/und bislang noch irgendwie Probleme bereiten. Betrifft alle Hersteller. So nach und nach werden dann einzelne Grafikkarten freigeschaltet und verschwinden von der Blacklist bzw. kommen, wenn sie keine Probleme machen, dann in die Whitelist. Wer experimentierfreudig ist, der kann per Config-Einstellung diese Blacklist umgehen und seine Grafikkarte trotzdem für Hardware-Beschleunigung via OpenGL freigeben. Allerdings auf eigenes Risiko und nicht selten mit dem Ergebnis, dass der Browser dann ggf. unbenutzbar wird, weil total lahm oder grafische Artefakte zu sehen sind. Hängt also u.a. an dem in der GPU fest verdrahteten OpenGL-Befehlssatz und auch mit dem im Betriebssystem verwendeten Grafiktreiber zusammen, der diesen Befehlssatz dann ansprechen kann. Und: je neuer der Grafiktreiber, desto besser natürlich. BTW: MacOSX 10.6.7 soll ja angeblich u.a. auch neuere Grafiktreiber beinhalten...
Und: wo nix fest verdrahtet im Chip, kann natürlich auch nix per Treiber angesprochen werden, der betreffende Grafikchip ist dann halt einfach zu alt und kann halt weniger. Von daher ist es bei dem ganzen Thema durchaus von Belang, welchen OpenGL-Befehlssatz und in welcher Version der betreffende Chip überhaupt und ganz generell kann. Wo nix ist und gewisse OpenGL-Operationen im Chip nicht vorhanden und per Befehlssatz ansprechbar sind, kann halt auch nix rausgeholt werden -- egal wie alt oder neu der Treiber dann ist. Der betreffende Grafikchip ist dann halt einfach zu alt und kann zu wenig für gewisse Operationen auf dem Gebiet von OpenGL bzw. Hardwarebeschleunigung.

So macht zumindest Mozilla das. Wie Google das macht, weiß ich nicht.

Und um einem gewissen Einwand bzgl. Video-Beschleunigung den Schneid zu nehmen: Firefox 4 tätigt auch die hardwarebeschleunigte Wiedergabe von Video über OpenGL (egal, ob bei einem nvidia-Grafikchip oder einem von ATi oder einem von Intel). Das geht! Und Adobe hat genau das auch jetzt endlich für sich entdeckt und bietet es seit seinem letzten oder vorletzten Flash-Update über diese OpenGL-Schiene an und nennt es dann "Stage"...

Hm hm, ich schaue mir immer mal wieder Benchmark-Vergleiche zwischen Flash, Canvas und DHTML an. Immer noch liegt Flash da vorn und Firefox 4 ist nicht gerade schnell. Inzwischen sage ich dazu auch: leider. Schon seltsam, jede Szene-Demo von vor 10 Jahren kann mehr als ein aktueller Browser heute mit 10x mehr Prozessorpower.

Mein Traum wäre ein richtig schnelles Canvas auf allen Browsern. IE9 sieht da sehr sehr interessant aus. Webkit geht gerade so. Ansonsten sieht es noch mau aus.

ZUm OpenGL-Befehlssatz: Da meine Grafikkarte, eine ATI2600HD den OSX Desktop voll hardwarebeschleunigt anzeigt (Quartz), gehe ich davon aus, das das auch möglich ist in einem Browser und die Grenzen von Mozilla tatsächlich nur willkürlich sind.

Wie oben geschrieben, es geht hier um Browser-2D-Darstellung, nicht um komplexe 3d/Shader was-auch-immer Operationen. Das ist doch alles geplante Obsoleszenz bzw. Unfähigkeit.

fluppy:

Schon mal die betreffenden Demos bzgl. Hardwarebeschleunigung in Kombination mit HTML5, WebGL und Canvas von Mozilla, Google und Microsoft angeschaut und auf Dich wirken lassen?

Standardmäßig der komplette OSX Desktop hardwarebeschleunigt? Und ohne Dein Zutun? Wie kann das gehen, wenn MacOSX QuartzGL (hieß früher: Quartz 2D Extreme) auch unter MacOSX 10.6 standardmäßig ausgeschaltet bzw. deaktiviert hat und man es nur testweise und zu Debug-Zwecken mit dem Quartz Debug Tool (/Developer/Applications/Performance Tools/Quartz Debug.app) oder auch gezielt pro einzelnem Programm nur vorübergehend und nicht dauerhaft aktivieren kann?

Quelle:

Das mit den Updates von Google Chrome im Hintergrund finde ich irgendwie unheimlich, weil ich nicht verstehe wie es funktioniert.

Wie kann sich ein Programm aktualisieren, ohne dass es angeschaltet ist? Wird da nicht irgendein verstecktes Programm von Google installiert, das das eventuell macht?
Dieser Gedanke bereitet mir Sorgen.

Steppenwolf:

Dir kann geholfen werden, und am Schluss bist Du wissender.

Google hat als Dienst/daemon einen Software-Update-Dienst laufen. Der liegt unter /Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/.
Dieser Dienst läuft als launchd-Skript und schaut jede Stunde (genauer: alle 58 Minuten) nach, ob für Deine Software aus dem Hause Google (also Google Chrome, Google Earth etc. pp.) ein Update bereitsteht. Wenn nein, dann beendet sich der Updatedienst wieder und fragt dann eine knappe Stunde später wieder nach und so weiter und so fort.

Es sind zwei launchd-Skripte dafür zuständig:
/Library/LaunchAgents/com.google.keystone.agent.plist
und
/Library/LaunchDaemons/com.google.keystone.daemon.plist

Das eine Skript läuft als LaunchDeamon, das andere als
LaunchAgent (was der Unterschied zwischen beiden ist, ist hier für diese Angelegenheit jetzt nicht von Relevanz).
Findet GoogleSoftwareUpdate ein Update auf Googles Update-Servern, so lädt er diese(s) Update(s) in Form klassischer Disk-Images (.dmg) in ein Cache-Verzeichnis Deines Benutzerverzeichnisses und legt sie dort dauerhaft ab:

~/Library/Caches/com.google.UpdateEngine.Framework.501/Downloads
~/Library/Caches/com.google.UpdateEngine.Framework.502/Downloads

(die Ziffern 501 bzw. 502 sind die User-IDs des ersten Benutzers resp. des zweiten Benutzers, in aller Regel Admin (erster Benutzer, UID 501) und Standardbenutzer (zweiter Benutzer, UID 502))

Schau mal in diese Verzeichnisse bei Dir rein, da wirst Du bestimmt was vorfinden, wovon Du bisher noch nichts wusstest. Da liegen nämlich die vom Google Update-Server heruntergeladenen Diskimages und warten auf ihre Installation.

So. Und wenn Du jetzt zufällig ein Nutzer mit Admin-Rechten bist, hat dieser GoogleSoftwareUpdate-Service auch die Erlaubnis, diese im Hintergrund heruntergeladene Software zu installieren, denn er läuft ja im Admin-Kontext und als Admin darf er ohne nachfragen und Authorisation ins /Applications-Verzeichnis schreiben bzw. dort eine bestehende Google-Applikation mit einer neueren Version überschreiben.
Hat der GoogleSoftware-Agent diese Adminrechte nicht, weil der Service bspw. im Kontext des Standardnutzers läuft, so habe ich jedenfalls die Erfahrung gemacht, dass zwar vom Google Update-Server die notwendigen Dateien zwar heruntergeladen werden in das oben genannte Download-Verzeichnis, doch es findet keine Installation statt, weil die notwendigen Rechte dafür fehlen. Und solange bleiben die heruntergeladenen Diskimages da in dem Download-Verzeichnis liegen, bis sie installiert sind. Können sie nicht installiert werden aufgrund fehlender rechte, bleiben sie da dann trotzdem liegen. Ich hoffe, dass ich das diesbzgl. richtig wiedergegeben habe, dass dann keine Installation stattfindet. Sollte ich damit falsch liegen und es unter einem Standardbenutzer (der ja beschränkte Rechte hat) doch klappen sollte, bitte ich um entsprechende Berichtigung. Ich habe das Teil komplett deaktiviert, weil ich bei mir aus ganz anderen Gründen und auf eigene Art mit eigenen Skripten für die automatische Aktualisierung im Hintergrund sorge.

So. Das ist der ganze Vorgang. Kein Voodoo-Zauber. Alles transparent. Und jetzt kommt noch ein Bonbon :

Wenn Dich das nervt, dass Google da ständig im Hintergrund Updates einfährt und Du lieber alles per hand machen willst bzw. volle Kontrolle haben willst, dann schaltest Du diese beiden betreffenden launchd-Dienste einfach ab bzw. deaktivierst sie. Kann man auf zwei Wegen machen, bei der einen Methode gibt's sogar ganz offiziell von Google Hilfestellung dazu, sogar in deutscher Sprache :

Google: Google-Hilfe: Verwalten von Updates in Google-Software-Update

Eine andere Alternative wäre, die beiden oben genannten launchd-Skripte

/Library/LaunchAgents/com.google.keystone.agent.plist
und
/Library/LaunchDaemons/com.google.keystone.daemon.plist

einfach für launchd zu deaktivieren, sodass sie gar nicht erst aufgerufen werden. Man könnte sie ganz entfernen, also löschen, doch beim nächsten Update von Google Earth oder so, sind sie dann wieder da, weil Google dafür sorgt, dass diese beiden launchd-Skripte an Ort und Stelle sind.
Diese beiden Plist-Dateien sind XML-Dateien. man kann sie entweder mit einem Texteditor editieren oder mit MacOSX' PList-Editor (der, glaube ich, den Developer Tools beiliegt bzw. auf der Installations-DVD drauf ist). Oder man benutzt Peter Borgs geniales Lingon-Werkzeug , welches er für €4.99 im App-Store anbietet (zuvor hat er's jahrelang kostenfrei und als Open-Source angeboten, und so schwirrt es auch noch vielfach im Netz herum, einfach mal schauen, z.B. hier: , seit es den App-Store gibt, hat Peter Borg wohl Blut geleckt und bietet das Tool jetzt für 'nen knappen Fünfer an. Lingon ist diesen Fünfer aber wert, ansonsten halt die etwas ältere kostenfreie Version nehmen).

Wenn Du Lingon verwendest, schaust Du Dir (vorher als Admin einloggen) damit diese beiden genannten PList-Dateien (im Basic-Modus) an und klickst oben rechts den Haken bei [] Enabled weg. Abspeichern und fertig. Das machst Du mit beiden PList-Dateien, und Du hast fortan Ruhe vor Googles automatischem Software-Update.

Wenn Du das Ganze mit dem PList-Editor oder TextEdit machst und diese beiden PList-Dateien editierst, dann musst Du im PList-Editor ganz oben an erster Stelle jeweils lediglich den Schlüssel "Disabled", als Typ "Boolean" und als Wert dann einen Haken "[✓]" setzen. Abspeichern. Fertig.
Editierst Du in TextEdit, so muss die Plist-Datei wie folgt beginnen bzw. um den fettgedruckten Eintrag erweitert werden:

Nun hast Du also 4 Wege kennengelernt, wie Du das automatische GoogleSoftware-Update komplett und dauerhaft deaktivieren kannst: indem Du launchd anweist, diese beiden dafür notwendigen PList-Dateien (bzw. wenigstens eine von beiden) schlicht und einfach nicht auszuführen.

Nix Verstecktes, kein Voodoo. Alles transparent und nachvollziehbar und relativ einfach zu lösen.

nach kurzem Test: Chrome zeigt das ERSTE Mal Webseiten, darunter auch Youtube nicht korrekt an!

Da muss nachgebessert werden.