Native Client: Google stellt ActiveX-Alternative vor

Seit Jahren gibt es immer wieder Gerüchte, wonach der Suchmaschinenbetreiber und Werbevermarkter Google an einem eigenen Betriebssystem arbeiten soll. Angeblich will das Unternehmen dadurch seine Abhängigkeit von anderen Plattformen überwinden. mehr...

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben

[o1] am ++2 --1

Klingt ziemlich gut. Google denkt da zukunftsorientiert

[re:1] am ++--

@KarlKoch23: Auf der einen Seite schon. Und gerade die Open Source Umgebung ist ein wahnsinniger Vorteil. Allerdigs denke ich auch, dass ActiveX sehr weit verbreitet ist und es einige Zeit dauern wird, bis sich Native Client durchsetzen würde.

Bearbeitet am 09.12.08 um 12:01 Uhr.

[re:2] am ++1 --

@Slurp: Na klar dauerts seine Zeit, aber Native Client bietet viel mehr Möglichkeiten. Meiner Meinung nach hat Google mit der Aussage recht, dass es in ferner Zukunft keine wirklichen Betriebssysteme - wie wir sie heute kennen - mehr geben wird. Native Client ist da eindeutig der erste Schritt. Online-Anwendungen werden immer Populärer, Office geht online, Adobe will seine Programme Online stellen und und und. Native Client hat da bessere Voraussetzungen als das heute beliebte ActiveX.

Bearbeitet am 09.12.08 um 11:52 Uhr.

[re:3] am ++--

@KarlKoch23: Da kann ich dir nicht widersprechen.

[re:4] am ++2 --1

@KarlKoch23: Mensch Leute , das heißt "Na(t)ive Client"

[re:5] am ++--

@X2-3800: Aaah lol. Danke für den Hinweis. Gott, das ist ein peinlicher Fehler xD

[o2] am ++3 --3

Google und sowas wie ActiveX ? Wenn ich nur dran denke wieviel Sicherheitslöcher im Chrome sind, von der Datensammlungswut der Firma ganz abgesehen, dann kann ich mir kaum vorstellen das mal einzusetzen.

[re:1] am ++1 --1

@Dario: Schonmal aufgefallen, dass es sich bei Chrome um eine Vorabversion / Beta handelt? Da ist doch logisch, dass noch Fehler und Sicherheitslöcher vorhanden sind. Zudem: Keine Software ist fehlerfrei.

[re:2] am ++4 --1

@Yaenzi: schonmal aufgefallen das es sich bei google bei allem um betas handelt?

[re:3] am ++2 --5

@Yaenzi: Schonmal aufgefallen das Googles Sinn im datensammeln besteht .

Bearbeitet am 09.12.08 um 12:20 Uhr.

[re:4] am ++2 --2

@overdriverdh21: Genau. Google = Böse: MS, Apple usw = Gut: Immer das selbe =)

[re:5] am ++3 --2

@KarlKoch23: Ne Apple ist schlecht das sie im Grundsatz gegen der Regel verstoßen "keine Software bindende Hardware" zu vertreiben , MS ist mir zu Schlampig was der Software angeht . Open Source halte ich für ein generellen Arbeitsplatzvernichter ( Verdrängen von Kommerzieller Software ) .

[re:6] am ++2 --1

@overdriverdh21: ergo alles ist böse ^^

[re:7] am ++1 --

@overdriverdh21: und was ist dann gut? Hello Kitty?

[re:8] am ++1 --

@nkler: man bekommts doch vom Staat nicht anders beigebracht -> Stichwort Schäuble

[re:9] am ++--1

@KarlKoch23: Gegen das derzeitige System zu Rebellieren und alles von Grundauf anders zu machen der Mensch ist sein eigener aber nicht des anderen .

[re:10] am ++--

@overdriverdh21: Rebellieren hilft auch nicht, da schlussendlich gewisse mehr rebellieren als andere und dann ist das was wir heute an Freiheit haben auch flöten...

[re:11] am ++1 --

@overdriverdh21: naja, von der pessimisten-Einstellung - alles = böse - halt ich nichts. Und außer der Datensammelwut - die sowieso jede größere Firma betreibt - sehe ich Google als eine der besten und zukunftsorientiertesten Firmen der Welt. Nicht alles was sie machen ist böse. Bestes Beispiel "Google.org". Aber jetzt sind wir schon ziemlich vom Thema abgewichen.

[re:12] am ++--

@KarlKoch23: Jede Firma hat ein Positives Projekt aber das denke ich gilt in erster Linie der ablenkung .

[re:13] am ++--

@overdriverdh21: Na, klar. Nur wir, das kleine Volk, wollen was ändern. Alle die Geld haben machen sowas nur um die Kunden zu befriedigen und um von der bösen wahrheit abzulenken. Sag mal, glaubst du das wirklich? Es mag zwar für manche geldsüchtige Firmen zutreffen, jedoch denke ich nicht für Google. Da Google für die wenigsten Produkte Geld verlangt, ist dies für mich einer der größte Beweise das sie nicht nur auf Geld aus sind, sondern wirklich was ändern wollen. Naja, jeder hat da seine eigene Meinung =)

[re:14] am ++--

@KarlKoch23: WTF? KEINE Firma dieser Welt hat ne andere prio als Gewinn... Du glaubst doch nicht google macht irgendwas umsonst!?!?!

[re:15] am ++--

@veox: ich mach einen unterschied zwischen Geldsucht und Gewinn..

[o3] am ++1 --2

Irgendwie erinnert mich das nicht nur an ActiveX, sondern auch an Microsoft .NET, Silverlight, Mono und Moonlight. Ich finde Google sollte sich lieber bei den zuletzt genannten Projekten engagieren statt das Rad nochmal neu zu erfinden.

[re:1] am ++2 --

@DennisMoore: Googles erklärtes Ziel ist es, dass die Anwendungen plattformUNabhängig vom Browser aus laufen. Bei Mono bzw. Moonlight ist man nicht sicher, ob die Kompatibilität auch in späteren Versionen noch gegeben ist (Mono hat aktuell mit den 3.x-Schnittstellen Probleme, bei Moonlight weiß ich es nicht...), außerdem kann MS maßgeblich (indirekt) Einfluss auf die Entwicklung nehmen. Ich persönlich kann die Entscheidung Googles nachvollziehen, lieber eine Eigenentwicklung zu starten anstatt nur teilweise portable Schnittstellen weiterzuentwickeln, nicht zuletzt, da Google und MS alleine der Geschäftspolitik wegen (OpenSource und Datensammeln vs. Proprietär, mal absichtlich übertrieben beschrieben) direkte Konkurrenten sind...

Bearbeitet am 09.12.08 um 12:01 Uhr.

[re:2] am ++--1

@DennisMoore: Und Bill Gates sprach: Es werde Licht! und es ward Licht

[re:3] am ++1 --1

@woot: Und nur weil eine Idee von MS kommt ist sie per se schlecht?
Alle beschweren sich immer wieder das Microsoft sich nie an irgendwelche Standarts halte, aber wenn Google das gleiche tut is es OK? Was nützen denn Standarts, wenn jeder Firma für das gleiche Problem wieder ein Neues Rad erfindet, nur um sich irgendwie von den anderen zu Unterscheiden?

[re:4] am ++--

@torweh: Microsoft wird von mir diesmal nicht kritisiert. Ich mache mich nur über Dennis lustig.

[re:5] am ++--

@Astorek: Die Technik auf der die genannten Technologien basieren ist doch frei zugänglich (Common Language Specification, Common Language Runtime). Somit müßte Google nicht mal Mono supporten, sondern könnte etwas eigenes auf der Basis bauen. @woot: Ich seh schon. Du hast absolut keine Ahnung von dem was hier angesprochen wird.

[o4] am ++7 --3

So ein Quatsch. Die Aussage "Zugriff auf die gesamte Leistungsfähigkeit heutiger Prozessoren geben soll" bedeutet, dass die Konzepte moderner Betriebssysteme über den Haufen geschmissen werden. Direkter Zugriff auf die Hardware war doch eines der größten Probleme, die Krücken wie Win 3.1 hatten. Keine Anwendungssicherheit, kein richtiges Multitasking, Freiheit für alle Viren. Einer der Vorteile, die mit modernen OS oder auch mit Java kamen war die Abstraktion von der Hardware. Aber so dumm werden die hoffentlich nicht sein. Also kein Zugriff auf die volle Leistung der Prozessoren. Nehmen wir den nächsten Satz: Browserunabhängigkeit und gleichzeitig IE bleibt außen vor. Wenn das mal kein Widerspruch ist. Also keine Browserunabhängigkeit. Kommt Betriebssystemabhängigkeit und native Coede-Module. Entweder ist es nativ oder unabhängig, aber beides geht wohl nicht. Also auch keine Betriebssystemunabhängigkeit. Es würde ja wohl auch keiner sagen, dass ActiveX browser- und betriebssystemunabhängig ist. Open Source für Sicherheit, wie oft muss man dieses Märchen noch hören. Ob etwas Open Source ist hat überhaupt nichts damit zu tun, ob die Software gut ist. Es gibt Unmengen an extrem schlechter Open Source Software, aber es gibt auch sehr gute Open Source Software, siehe z.B. Linux oder Firefox. Open Source ist super und Sicherheit ist super, aber aus dem einen ergibt sich nicht automatisch das andere. Die nächste Aussage lautet "leistungsfähigere Werkzeuge zur Bildbearbeitung anbieten könnte, als es bisher unter Verwendung von JavaScript und der Server-seitigen Datenverarbeitung möglich wäre". Das impliziert, 1. dass Java und Javascript sehr langsam sind und 2. dass Server sehr langsam sind. Wenn ich eine große Bildberechnung auf meinen Mobiltelefon oder Netbook mache statt auf meinem 8-Prozessor, 64 Gb Ram Server, dann wird das sicher nicht unbedingt schneller. Die Aussage ist so also definiv nicht haltbar. Insgesamt eine sehr trollige News.

[re:1] am ++1 --1

@Timurlenk: der gedanke kam mir auch auf, besser hätt ichs nicht ausdrücken können

[re:2] am ++3 --

@Timurlenk: Ich denke die wollen eine Laufzeitumgebung die nicht als VM läuft, sondern nativ auf dem Betriebssystem. Also genau das was Java von .NET unterscheidet. Das ist der Knackpunkt. Somit laufen "Native Client"-Anwendungen auf jeder Plattform quasi nativ und nutzen somit das gesamte Leistungspotential. Das wäre die Basis. Das Sicherheitsmodell befindet sich auch in der Laufzeitumgebung und ist aufs OS abgestimmt. Browserunabhängigkeit ist Sache des/der Plugins. "Das impliziert, 1. dass Java und Javascript sehr langsam sind" ... Das stimmt auch. Javascript weils auf ner Engine im Browser läuft und Java weils in einer VM läuft.

Bearbeitet am 09.12.08 um 12:03 Uhr.

[re:3] am ++1 --

@DennisMoore: "Also genau das was Java von .NET unterscheidet." Wie meinst du das? Sowohl Java als auch .NET nutzen einen JIT-Compiler und laufen somit pseudo-nativ. Gut, .NET-Programme kann man mit einem Tool dauerhaft zu nativem Code kompilieren, aber für Java gibt es das sicherlich auch.

[re:4] am ++2 --

@TiKu: .NET Programme werden in der Regel nur beim ersten Starten durch den JIT Compiler gejagt. Bei allen weiteren Starts wird nach Möglichkeit dirket aus dem Cache geladen und das Programm läuft dann wie jedes normal Compilierte Windows Programm.

Bei JAVA wird aber noch eine Runtime, die Java VM, dazwischen geschoben, und damit haben Java Programme die gleichen Performance Probleme wie Ältere VB6 Programme: Die Runtime ist nicht an die Möglichkeiten des lokalen Systems angepasst, sondern emuliert nur eine identische Hardware für alle Anwendungen.

Deshalb ist in der Regel die Performance von .NET Programmen höher als die von JAVA oder ähnlichen Konzepten.

[re:5] am ++--

@torweh: Die Runtime, zu der ein Garbage Collector usw. gehört, hast du doch bei .NET auch - selbst nach dem JITten?! Oder irre ich mich da? Der Unterschied zwischen Java und .NET besteht meiner Meinung nach hauptsächlich darin, dass a) .NET nicht auf eine einzelne Programmiersprache ausgelegt ist, b) .NET geJITtete Assemblies cached und c) .NET allgemein etwas weiter geht als Java (sowohl was die Features wie Hotspot-Optimierung, funktionale Sprachelemente usw. angeht als auch was den Umfang der Klassenbibliothek angeht). Als d) könnte man noch anführen, dass .NET nur auf dem Papier plattformunabhängig ist, Java dagegen auch in der Realität.

[re:6] am ++1 --

@TiKu: Eine Art von Runtime hat man ja immer, ob es nun die C(++) Runtime oder die .NET Runtime ist. Der Unterschied liegt darin was diese Runtime alles können soll/muss. Bei C/C++ ist die Runtime nichts weiter als ein sammlung häufig genutzer Funktionen ohne echte Aktive Teile. Bei JAVA emuliert die Runtime mehr oder weniger einen kompletten PC ohne sich um Tatsächlich vorhanden Hardware zu kümmern. Bei .NET geht man einen Mittelweg. Die meisten Funktionen der Runtime sind Passiv und bilden nur Teile des Platform SDK's auf eine gemeinsame, Sprachunabhängige Datenstruktur ab. Andere Teile wie z.B. der Garbage Collector überwachen dagegen Aktiv die ausgeführten Programme. Im großen und ganzen sind diese Aktiven Komponenenten aber auch wieder an die jeweilige Hardware angepasst und damit performanter als die entsprechenden JAVA Teile. Ein Unterschied zwischen JAVA und .NET ist deshalb auch die Möglichkeit unter .NET Hardware direkt anzusprechen, wenn man dann auf ein wenig Unabhägigkeit verzichtet.

[re:7] am ++--

@torweh: "Bei JAVA emuliert die Runtime mehr oder weniger einen kompletten PC ohne sich um Tatsächlich vorhanden Hardware zu kümmern." Heißt das, Java-Programme werden nicht beim Aufruf geJITtet, also zu nativem Code kompiliert, sondern quasi interpretiert? Ich war bisher der Meinung, dass Java ebenfalls diesen Mittelweg geht.

[re:8] am ++1 --

@TiKu: In JAVA wird vom JITer auch echter Maschienen Code erzeugt, in der Beziehung unterscheiden sich JAVA un .NET nicht besonders. Bei Java "spricht" das so übersetzte Programm dann aber nicht direkt mit Windows, sondern es ist noch eine Schicht zwischen dem JAVA Programm und Windows, die Java VM. Ein .NET Programm kann tatsächlich direkt alle Windows (oder bei MONO Linux) Funktionen aufrufen, man kann zum Beispiel das echte "Windows" Fenster-Handle abrufen und wenn man möchte sein Windows Forms Fenster auch mit einem "normalem" Windows API - ShowWindow Befehl verschwinden lassen.
Unter JAVA ist das nicht möglich. Das JAVA Prgramm kennt nur die JAVA Runtime, das Tatsächliche darstellen eines Fensters übernimmt hier auschließlich die JAVA Runtime, die es ihreseits wieder an die Windows GDI oder den Browser weiter deligiert. Und das kostet natürlich Zeit und Resourcen und manche sachen sind so einfach nicht möglich. Deshalb ist JAVA im Prinziep aber auch Sicherer, Ein Fehler in einem JAVA Programm bleibt normalerweise auch in der JAVA Runtime, während man mit .NET durchaus auch den komplette Rechner zum Abstürzen bringen kann.

Bearbeitet am 09.12.08 um 15:54 Uhr.

[re:9] am ++--

@torweh: Ach so meinst du das. Ja, das stimmt. Wobei Windows Forms ja ein Auslaufmodell ist und bei WPF ist es nur noch bedingt so wie du schreibst. Bei WPF sind die Buttons usw. keine eigenen Fenster mehr, sondern innerhalb eines Anwendungsfensters (zum Teil auch schon für das Fenster selbst) macht WPF auch sein eigenes Ding. Die Folge ist, dass man WPF-Anwendungen recht leicht erkennt, weil sie nicht 100% nativ aussehen.

[re:10] am ++--

@torweh: "Ein Fehler in einem JAVA Programm bleibt normalerweise auch in der JAVA Runtime, während man mit .NET durchaus auch den komplette Rechner zum Abstürzen bringen kann." ... Das ist so nicht ganz richtig. Auch .NET kann den Rechner nicht abstürzen lassen, weil es sich um Managed-Code handelt. Das schlimmste was passieren kann ist, dass man den Prozess abschießt. Problematisch wirds erst wenn man auch "unsicheren Code" in .NET aufruft, z.B. mit DllImport native Funktionen importiert und dann über PInvoke aufruft.

[o5] am ++1 --

Hmm ich finde die Idee von Google super, lässt sich bestimmt einiges mit machen. Besonders wenn Native Client auf Google Gears usw trifft sollte man programmiertechnisch einiges realisieren können. Gears stellt beim User die Datenbank und NC ermöglicht die Befehle...quasi Googles Antwort auf M$ Access mit besserer Webunterstützung. Muss der User nur eine Seite aufrufen, schon klappen alle Funktionen...statt die Runtime zu installieren und die .mdb zu starten. Würde dann auch .asp ähnliche Funktionalitäten auf nicht Windows Webservern ermöglichen...oder seh ich das falsch?

[o6] am ++--1

"Einzig Microsofts Internet Explorer bleibt außen vor." Das ist zwar schon mal ganz gut. Aber ActiveX bei Windows ist ja das Scheunentor für Schadsoftware. So was proprietäres braucht kein Mensch, der plattformunabhängig arbeiten möchte. Diesen Dreh möchte Google allerdings hinbekommen. Ich habe da meine Zweifel...

[re:1] am ++1 --

@tk69: Es ist aber immer eine frage, wofür man seinen PC einsetzten möchte. Je Performanter eine Aufgabe gelöst werden kann, desto besser.

Plattform unabhägigkeit ist ein gerne genutzter Werbespruch, der in der Regel nur bedeutet, das man eine Aufgabe auf nicht dafür geeigneter Hardware ausführt und man meistens ewig auf das Ergebnis warten kann

Jeder Anwender, den ich kenne verzichtet gerne auf Platform unabhängigkeit, wenn seine Aufgaben schnell und zufriedenstellend gelöst werden.

[re:2] am ++--1

@tk69: Kein Mensch der nur denken kann wird ActiveX aktivieren...graus, das ist eine der schlimmsten Erfindungen der IT-Geschichte...dass sie den IE nicht supporten verstehe ich hingegen nicht(der 8er ist ganz ok)...

Bearbeitet am 09.12.08 um 19:39 Uhr.

[re:3] am ++--

@bluefisch200: Lern bitte erstmal was ActiveX ist bevor du so laut dagegen wetterst. ActiveX wurde nicht für den Webeinsatz entwickelt, sondern lediglich für diesen adaptiert. Außerhalb des Webs ist ActiveX alles andere als eine schlimme Erfindung.

[re:4] am ++--1

@TiKu: Nun wirds aber besser....mit der Aussage hast du dich gerade selber diskualifiziert, ich kann ueber die ActiveX Komponenten deine gesamte HD, in XP sogar, fals der User mit Admin surft, ohne Warnung, deine HD auslesen, mit deinen Files rumhantieren etc...

Bearbeitet am 09.12.08 um 21:05 Uhr.

[re:5] am ++--

@bluefisch200: Und? Bei einer Desktop-Anwendung ist das durchaus erwünscht. Bei einer Webanwendung natürlich nicht, deshalb habe ich ja in dem Satz "Außerhalb des Webs ist ActiveX alles andere als eine schlimme Erfindung" den Webbereich auch ausdrücklich ausgenommen. Ich halte die Integration von ActiveX in den Webbrowser nämlich selbst für eine dumme Idee. Übrigens kannst du über ActiveX meine Festplatte NICHT ungefragt auslesen wenn ich einen aktuellen IE6 oder IE7 nutze, denn dann werde ich gefragt bevor eine ActiveX-Komponente ausgeführt wird - auch wenn ich als Admin surfe.

[re:6] am ++--

@TiKu: Keine Ahnung, wusste ned dass die nun auch fragen, habe Vista, dachte mach er nur dort, ist aber nett das zu wissen...

[o7] am ++--

Also, das was Google jetzt hier machen möchte finde ich irgendwie überflüssig. Es gibt ja bereits Java, was auf so ziemlich jeder Hardware und Software funktioniert mit den exakt gleichen Programmen. Java ist zwar noch nicht ganz open source, aber auf gutem Weg dort hin, wie es mir scheint.

[re:1] am ++--

@3-R4Z0R: Siehe (o4, re:4), da hat Benutzer "torweh" es schön anschaulich beschrieben... Google will ja erreichen, dass deren Programme ebenfalls die komplette Leistungsfähigkeit eines Systems herauskitzeln können, wenn sie es wollen... Mit Java ist das dank JVM nicht möglich (natürlich hat Java dafür andere Vorteile, keine Frage).