Chrome soll Synchronisation für Tabs erhalten

Browser Neben den zahlreichen Ankündigungen rund um den Browser Chrome, die im Rahmen der Keynote auf der Entwicklerkonferenz Google I/O vorgenommen wurden, gab es anschließend in einer kleineren Runde noch einen Ausblick auf die Zukunft des Projekts. mehr...

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
noch mehr Traffic -.-
 
@sanem: Die 2 KB...
 
@Mister-X: pro tab vielleicht... je nachdem wie sie syncen kann das ganz schnell viel mehr sein. Und wenn sie das regelmäßig und komplett veranstalten kannste das mit mobilen Datentarifen gleich vergessen.
 
@Johnny Cache: Sind wir mal ehrlich: Die mobilen Datentarife sind eh Müll!
 
@Mister-X: Klar, aber was will man machen wenn man unterwegs ist? Mobile Datentarife gehören nun mal zur Cloud, wenn ich zuhause sitze kann ich meine Daten auch lokal speichern.
 
@Johnny Cache: Ich verstehe dein Problem durchaus. Aber hier ist es wohl einfach mal an der Zeit der Provider endlich mal realistisch zu werden und die Tarife anzupassen.
 
@sanem: Hast du ein 56K-Modem oder einen DSL-Anschluss mit Trafficbegrenzung? Wenn ja: haha. Wenn nein: Wo ist das Problem?
 
@nick1: Selbst mit nem 56K Modem sind 2 KB kein größeres Problem. Außerdem: wer mit 56K auf die Idee kommt zu Synchronisiern, gehört sich verkloppt.
 
Alles schön und gut, aber bevor Chrome keine WYSIWYG Editoren in Foren zulässt, bleib ich bei Firefox.
 
@testacc: Macht nichts.
 
@testacc: Hä? Also bei mir geht das alles, hab nie Probleme in Foren!? Was meinst du?
 
@testacc: Warum sollte Chrome keine WYSIWYG Editoren zulassen?! Totaler quatsch!
 
also sowas wie TabRocket
 
@SpeedFleX: Danke für den Tipp, sehr praktisch!
 
Ja ja, beim IE über ActiveX schimpfen und dann Native Client.
 
@Kirill: Ja und? Der Native Client läuft weiterhin in einer Sandbox und erlaubt keine Zugriffe auf die Systemressourcen. Es werden lediglich in C/C++ geschriebene Funktionen aufgerufen - was wesentlich schneller ist und die Portierung von nativen Anwendungen/Funktionen erlaubt. ActiveX hingegen widerspricht völlig dem Sandboxprinzip (FileSystemObject ...) und ist/war auch nicht wirklich zur Portierung gedacht.
 
@zatarc: Ja und? Dann nehmt halt Java/Flash/Silverlight/CIL. Das gibt es alles schon. Und deine Sandbox kannst du dir, pardon den Ausdruck, sonstwohin stecken. Binärcode ist unsicher per Definition. Es gibt keinen zuverlässigen Weg, das sicher zu machen.
 
@Kirill: Kommt alles nicht an die Performance von C/C++ heran.
Ach und JavaScript hat Code im Zehnersystem oder wie? O_o
Der Native Client läuft im selben Context wie die V8-Engine (die jetzt schon viele JS-Bestandteile in nativen Code übersetzt). Wenn du die Sandbox in dein Po steckst, dann kannst du alle Browser mit JS-Unterstützung dazuschieben, oder was denkst du hindert JS vor dem Zugriff auf Systemressourcen?!
 
@zatarc: So viel mehr Performance hat C++ gegenüber C# auch nicht, dafür unendlich viel mehr Sicherheitsprobleme.
 
@Kirill: Deine "Argumente" sind echt haarsträubend und zeigen, dass du Recht wenig Ahnung in Softwareentwicklung hast.
 
@zatarc: Gleichfalls. Checkst du echt nicht, was der Unterschied zwischen JS und Binärcode ist?
 
@Kirill: Doch: var object = {a: 1, b : function (c) { console.log(c) }}; <= JavaScript. 01010101110101111101 <= Binärcode. Sehr schwer oder? Aber erklär mir nochmal was das jetzt mit der Sicherheit zu tun hat. Falls du dir das nicht vorstellen kannst, JavaScript-Code wird in seiner Lebenszeit auch mal in Binärcode umgewandelt, oder denkst du deine CPU spricht JavaScript? ;)
 
@zatarc: Simpel: Intepretierte Programmiersprachen laufen im Interpreter. Der kann also Code zur Laufzeit überprüfen und ggf. abwürgen. Gib dir mal wieder die CIL, da gibt es z.B. so ziemlich keine Pufferüberläufe, im Gegensatz zu C(++). Gut, C(++) ist mehr oder weniger "broken by design", aber es soll verdeutlichen, dass interpretierte Sprachen eben wegen dem Interpreter rein technisch deutlich sicherer sind. Binärcode dagegen kann man höchstens abschotten, anstatt zur Laufzeit ganz genau zu schauen, was denn ausgeführt wird.
 
@Kirill: Du laberst so ziemlich Schwachsinn. Ein Interpreter überprüft keinen Code, sondern übersetzt ihn nur zur Laufzeit, alles andere wäre quälend langsam und alle modernen JS-Engines greifen schon jetzt auf vorkompilierten Code zurück. Und selbst wenn, was hindert keinen Compiler daran genau das selbe zu tun? Du drehst dich im Kreis. Die Art der Übersetzung spielt absolut keine Rolle bei der Sicherheit, zumal im Chrome sowohl V8 als auch der Native Client und auch alle anderen Plugins in der ein und der selben Sandbox laufen. Da der Native Client die selben Einschränkung wie JavaScript hat (kein Filesystemzugriffe .. etc.) gilt für alle die selbe Hürde: Die Sandbox. Deine argumentlose Abneigung gegen C++ zeigen nur eins: Du hast keine Ahnung von Programmierung. Nicht die Sprache ist unsicher, sondern der Programmierer der die Fehler macht, und die kann man überall machen.
 
@zatarc: Ein Interpreter kann aber Code überprüfen und "illegale" Operationen erst gar nicht in Maschinencode übersetzen. Ebenfalls kann ein Interpreter Dingen wie den allseits beliebten Pufferüberläufen vorbeugen, indem es die Speicherbereiche zur Laufzeit sinnvoll zuweist/überschreiben verhindert. Auf diese Weise entscheht erst kein schädlicher Maschinencode. Liegt Maschinencode dagegen bereits vor, ist der Virus bereits da, den man nachträglich einschränken muss.
 
@Kirill: Und was hindert einen Compiler jetzt daran schädlichen Code auf genau die selbe Art und Weise vor dem kompilieren zu überprüfen? Stichwort Präprozessor?!
 
@zatarc: Zum Beispiel dass man dem Code erst zur Laufzeit ansehen kann, wo es Pufferüberläufe gibt. Wenn Googles Native Client aber unkompilierten Code empfangen und kompilieren soll, warum zur Hölle nicht doch JS/C#?
 
Das mit den Daten von Extensions ist wirklich notwendig. Mir birngt das Synchronisieren von Erweiterungen nichts, wenn die Einstellungen dazu nicht synchronisiert werden.
 
Das Synchronisieren von offenen Tabs ist eine feine Geschichte und nutze ich über XMARKS schon länger
 
Also ich weiß ja nicht wie ihr das seht, aber ich halte das eher für eine sinnlose Aktion. Bei Lesezeichen usw. ist es klar, aber wie genau soll das mit den Tabs funktionieren? Etwa, dass immer dier aktuelle Tab-Zustand synchronisiert wird, ich meinen pac verlassen und an einem anderen PC dann da weitermachen kann wo ich aufgehört hab? Ich schließe ja immer meinen Browser wenn ich ihn nicht mehr brauche, dann wären die synchronisierten Tabs ja auch weg? Also ich versteh es echt nicht.
 
@XP SP4: Naja, viele die ich kenne, haben ihren Browser so konfiguriert, dass man beim Öffnen nicht die Startseite angezeigt bekommt sondern die zuvor geöffneten Tabs. Das heisst am selben PC kann man dann einfach weiterarbeiten. Mit diesem neuen Feature soll das dann Systemübergreifend funktionieren. Wenn du sowieso immer die Startseite oder ein leeres Tab beim Start hast und willst, wird die Synchronisierfunktion bei dir kaum aktiviert.
 
@Big_Berny: Ich zum Beispiel. Ich habe ein paar Webseiten, die immer offen sind. Derzeit sind es 5 (inkl. der Projekte, an denen ich Arbeite). Ist auch praktisch bei Abstürzen (Browser oder System). Aus diesem Grund gehör ich z. B. auch zu denen, die keinen Nutzen am "Home/Startseite"-Button finden.
 
@psylence: Ich übrigens ebenfalls. Den Home-Button kannst du ja in den Optionen deaktivieren. Ich finde ihn noch praktisch, da ich so schnell auf die Neue-Tab-Seite gelange, um etwa geschlossene Seiten, Bookmarks oder meine Favoriten zu öffnen.
 
@Big_Berny: Ich weiß, hab ich auch. Auf die Neue-Tab-Seite kommt man aber auch mit STRG+T bzw. neuen Tab öffnen.
 
@psylence: Stimmt. Ich bin aber mit der Maus meist schneller, da ich bei Surfen die Hände meist nicht auf der Tastatur habe. Ehrlich gesagt arbeite ich aber mehr mit Gesten als den Buttons.
 
@Big_Berny: Ich arbeite so gut wie nur am Laptop, ohne Maus. Da sind Gesten eher unpraktisch. Früher hatte ich die aber auch benutzt.
 
Die neue Tab-Seite ist bereits seit einiger Zeit in den Dev-Builds in den about:flags aktivierbar und besteht aus einer großen Übersicht der bereits besuchten Seiten und einer Touscreen-optimierten Seitensteuerung ähnlich wie bei bei dem iOS-Startscreen. Weiterhin verschwinden auch die Lesezeichen in dieser frühen Version oben aus der Neuen-Tab-Seite, möglicherweise wurde dies jedoch auch einfach noch nicht implementiert.
 
passwort sync fänd ich fein, aber bitte auch aufs smartphone!
 
@navahoo: Passwort Sync gibts bei Chrome schon.
 
@eragon1992: aber nicht in verbindung mit dem androiden oder?
 
@navahoo: Sorry, das weis ich leider nicht, weil ich kein Android Smartphone habe. Hoffen tu ich es aber schon.
Kommentar abgeben Netiquette beachten!

Video-Empfehlungen

WinFuture Mobil

WinFuture.mbo QR-Code Auch Unterwegs bestens informiert!
Nachrichten und Kommentare auf
dem Smartphone lesen.

Folgt uns auf Twitter

WinFuture bei Twitter

Interessante Artikel & Testberichte

WinFuture wird gehostet von Artfiles

Forum