uh interessant. aber langsam muss man ja wirklich aufpassen, dass man nicht zuviel von google benutzt

Ja, wobei das richtig lustig werden könnte

Ich bin skeptisch, ob das mit einem x-beliebigen Programm funktioniert. Vielleicht mit einem, das sich selbst genügt, aber manche laufen ja nicht mal an, wenn es keine Schreibberechtigung auf dem C Laufwerk gibt.

Na dann Adieu Plattformunabhängigkeit ....

@Google: ActiveX gibts schon lange *sick*

Dann brauchen sich die Kiddies in Zukunft die Spiele garnicht mehr erst per Torrent ziehen, sonder können sie gleich vom kasachischen Server direkt ausführen

@gentux: Wer ActiveX auf Windows aktiviert ist selbst schuld. *sick*

Das interessante Fakt dürfte sein, dass es auf IE nicht geht. Das wiederum ist eine Art Kampfansage an Herrn Steve B., der sich um Yahoo und Netzkrams immernoch sehr bemüht.

Bei sowas sagt der Gegenüber immer gern "Dat gibt Kriech, jetz'".

Es ist sehr klar, was dies sein soll: Man will Performance und ein paar Features gewinnen für Webanwendungen und kämpft um die Herrschaft beim Web-OS. Vorteil: Man hatt alle Kunden, PC, Mac, Linux,..
Nachteil: Riesen Overhead und problematische Netzunabhängigkeit und natürlich die Sicherheit der Daten, welche mit diesen "Netprogrammen" laufen. Wenn das nur bei Open Office im Netz bleibt, ist es ohnehin eher nicht sooo interessant. Zumindest in meinem Umfeld will man nicht jeden Schrieb und Steuerabrechnung von Google gelesen wissen. Wie berechtigt das ist und wie oft Wordscanner nach "Bomben", "Terror" und Co suchen, wissen wir ja nicht.

Kasachischer Server: Nee, es ist noch besser: Die Spamsoftware läuft direkt auf deinem Rechner. Das meiste davon nutzt deine Power

Mögliche politische Antwort nach 10 Jahren: Kyrillisches verbieten, kommt vielleicht noch - und 3 Jahre später wird es dann wieder aufgeweicht, so wie die Rauchergesetze und vieles mehr.

Was für ein sinnlos-Projekt. LLVM hat mit dem Mythos aufgeräumt, das JIT-Compilierung Programme zwangsläufig langsamer macht. Fachleute im Compilerbau waren aber auch schon vorher fähig zwischen den Nachteilen der Implementierungen wie z.B. der JVM und denen des Konzepts an sich zu unterscheiden.

Was bringt Googles Native Client also?

Erst mal, er schränkt die Plattformunabhängigkeit ein. Der Client muss trotzdem den Code auf bestimmte Eigenschaften überprüfen, um zu verhindern, dass der Code im Adressraum des Browsers etwas anstellt, ohne aber die Ausführung zu simulieren (was ganz sicher langsamer als JITC wäre). Das ist eigentlich unmöglich, außer man gibt struktuelle Eigenschaften vor, welche die Mächtigkeit des nativen Codes einschränken bzw. bestimmte Operationen nur über sichere Umwege ermöglichen.

Und was bedeutet das? Die Überprüfung kostet genau wie das Compilieren Rechenzeit. Die Umwege bestimmte Operationen durchzuführen kosten Rechenzeit. Am Ende steht kein Rechenleistungsgewinn, aber eine Menge möglicher (architekturabhängiger) Sicherheitslücken.

Das ganze ist IMO nur ein Marketingprojekt ohne technischen Sinn, das versucht sich den Irrglauben der überwältigenden Mehrheit der Anwender zu nutzen zu machen, ohne nativen Code wären massive Geschwindigkeitseinbußen unvermeidbar.

feux… Und warum?

Ich halte auch nicht sonderlich viel von dem Projekt (zumindestens auf Basis der im Artikel geposteten Informationen).

Viel interessanter fand ich das Backend für einen C-Compiler in Flash. Eine Quake-Demo lief dort innerhalb von Flash (war auf einer Adobe-Konferenz).

Wenn man einmal die übliche Diskussion um Plugins (insb. Flash,Silverlight) ausser Acht lässt, ist der Weg von Adobe in meinen Augen sinnvoller, da nicht architekturspezifisch.

also den Sinn von sowas werde ich wohl nie verstehen. So lange ich ein Plug-In dafür installieren muss kann ich das Teil/Programm nicht überall nutzen. Und damit ist der Sinn der Webanwendung für mein Verständnis bei gleich null. Warum sollte ich die Annehmlichkeiten eine "richtigen" Applikation für einen Webbasierte Anwendung fallen lassen?
Klar das Google das gerne hätte. Die wollen ja auch wissen was ich da schreiben, spiele oder sonst in meinem Büro mache. Aber will ich das wirklich? Nee, ganz ehrlich. Egal ob Google, Apple oder MS.

Den Vergleich mit ActiceX fand ich übrigens gar nicht mal schlecht. Ist für mich auch so ein Ding was ich als Programmierer nie unterstützen würde.

Google entwickelt Plug-In zur Autodestruktion von Rechnern bei Zimmertemperatur

Ja, bestimmt. Glaubt ihr mir nicht?

Geil. Das Teil ist ganz klar die Zukunft.

Java war eine gute Idee. Aber: Langsam, kryptisch, hässlich.

ActiveX war keine gute Idee: Proprietär, unsicher.

Übrigens sind das keine langsamen „Webanwendungen“. Es geht darum, den Browser als API zwischen OS und Applikation zu schieben. Also ein Abstraktionslayer. Da werden eher keine xmlhttprequests über das Netz gehen - die API implementiert ja lokalen Hardwarezugriff, warum sollte man also was über´s Netz jagen?

Jeder Anwendung, die auf einem Rechner was will, nutzt i.d.R. vorhandene Routinen: Öffne mir eine Datei, lösche sie wieder,… es geht lediglich darum, dem Browser eben diese Befehle beizubringen.

Das wird das next big thing.

ratti
Und was lässt Dich glauben, dass das besser ist? Das Marketingwort "native"?

Wie willst Du denn verhindern, dass ein Plug-in in nativem Code, das zum selben Prozess wie der Browser gehört und damit exakt die gleichen Zugriffsrechte auf dessen Adressraum hat, diese Zugriffsrechte missbraucht?
Anweisungen, welche den Speicherinhalt verändern ganz verbieten und jeden Schreibzugriff auf den Speicher über eine Subroutine der Host-Anwendung abwickeln? Einen Emulator für die nativen Anweisungen verwenden? Das Plug-in in einem eigenen Prozess laufen lassen? Das sind grob die Möglichkeiten, die Google hat, alles mit solchem Overhead verbunden, dass außer dem Buzzword "native" noch weniger als nichts von den angeblichen Geschwindigkeitsvorteilen nativer Anwendungen übrig bleibt.

Google sollte lieber auf den LLVM-Zug aufspringen und ein Konzept Software Isolierter Prozesse darauf aufbauen. Maschinencode Softwaremäßig unter Kontrolle bringen zu wollen ist dagegen hoffnungslos, deshalb haben wir ja die ganzen hardwaregestütztem Isolationskonzepte in den CPUs..