La imagen de esta semana está en movimiento, y consiste en una interesante propuesta de Google que termina de eliminar las barreras que el desarrollo de aplicaciones web basadas en la nube pueden tener: un SDK que permite ejecutar código nativo del sistema (como C o C++) directamente desde el navegador.
Comentarios
Eso no es lo que permitía el Internet Explorer mediante controles Active X hace ya muchos años? y no fue una fuente interminable de problemas?
#2 La diferencia es que Native Client ejecuta el código en un Sandbox y no permite ejecutar instrucciones que no son seguras.
Bueno y luego es open source y multiplataforma.
#3 bonita teoria
#3 Como ejecutas codigo nativo en un Sandbox? O bien metes un emulador de por medio o te metes en temas de hipervisores.
De cualquier otra manera no veo como puedes evitar que codigo que corre directamente en el sistema(nativo, sin vm) ejecute el mismo tipo de instrucciones que el proceso que lo instancio puede.
#5 La wiki explica cómo lo hacen más o menos: http://en.wikipedia.org/wiki/Google_Native_Client
Desde luego es mejor explicación que la del enlace
#6 Ni Flash, ni Java ni JavaScript pueden competir en velocidad con código nativo.
En cuanto a qué hacer con los ARM... no parece una tecnología diseñada para estos procesadores, me temo... Pero oye, no iban a ser todo ventajas.
#8 Pero, que yo recuerde, en la arquitectura de 64 bits (AMD64) se ha eliminado la segmentación, precisamente porque no se utiliza. Entiendo que eso significa que ésto no puede funcionar en modo 64bits, sólo en 32 bits.
#8 pues espero que no triunfe, no quiero que internet sea lo que dice #12.
#8 De la wikipedia:
Native Client is notable for its novel sandboxing technique which makes use of the x86 architecture's rarely-used segmentation facility
¿Segmentación rara vez usada? Pues habrán cambiado mucho los sistemas operativos, pero diría que los pantallazos azules no dejan de ser una versión coloreada del mensajito de toda la vida de 'Violación de segmento' de cuando te pones a programar punteros en C sin tener ni idea y acaban apuntando a china
#3 y ese sandbox no es lo mismo que un Applet de Java?
¿Y ejecutando código nativo no te estás cargando la "portabilidad" de la web?
#3, eso, y más cosas:
- Es abierto.
- Es multiplataforma.
- Utiliza lenguages que ya existen.
#14 Realmente no. Este utiliza un lenguaje que existe y le da una API para que interactúe con el navegador. Cualquier navegador que integre esto podría intepretarlo. Y es platform-independent, eso es lo mejor de esto. Haces un juego con esto, y vale para todos los sistemas.
Si la gente se anima a programar en esto, es una forma de crear aplicaciones multiplataforma, y además, eficientes y en red.
#3 define 'sandbox'.
Estoy con #2. Esto tiene pinta de acabar siendo el mismo coladero de virus que los ActiveX.
#2: Eso es un disparate, para ser exactos.
Antes de poner algo así en mi máquina me pongo un Outlook (con Wine, eso sí :-P).
Aquí huele a vulnerabilidad de gravedad extrema. Al tiempo
Pues se me ocurren dos cosas:
a)Si metes código nativo, ¿qué haces con los ordenadores que no sean x86? (por ej. arm) ¿Haces distintas versiones de la web para distintas arquitecturas?. Si ya dentro de x86, ¿también será distinto para linux/windows/mac?
b)Para solucionar lo anterior, metes el compilador en la pág web, y le damos la bienvenida a las dependencias, pero a otro nivel.
Sinceramente, me parece mejor el concepto flash/java/javasript.
#6. no lo conozco en detalle, pero no puede ser peor que flash.
Para esto directamente programo una aplicación a medida y listo.
¿Os imagináis entrar en Meneame y que no funcione bien por que solo esta compilada para Windows de 32bits?
#12 no estará compilada, si no en código fuente C/C++ (o algo tipo bytecode/.object?), que si no se utilizan librerías extrañas, es de lo más estándar que puede haber y casi cualquier ordenador lo compilaría.
De todas formas acabo de tener un Dejavú muy grande, con MPEG21 ya lo hice, vaya que no es nada nuevo:
- Mozilla ofrecía unas librerías que permitían ejecutar desde JavaScript código C++.
- En un objeto podías meter un código javascript que directamente ejecutaba código que podía manipular la canción.
#25 He visto el vídeo. En el ejemplo de "Hello world" llama desde javascript a una función hecha en c++.
Supongo que la funcionalidad principal es esa, llamar desde javascript a c++, nunca que la aplicación principal esté en c++ . Si es así, puede que pase los ficheros objetos, sin linkar, aunque lo que yo supongo que hará es crear algún tipo de fichero objeto especial con todas las librerías enlazadas estáticamente.
#26 por eso, no es nada nuevo porque en la fundación Mozilla ya lo tenían montado
Se llama SpiderMonkey, yo lo usé para el caso de objetos multimedia e iba de coña.
http://www.mozilla.org/js/spidermonkey/
http://www.jsdb.org/embedding.html
La principal 'novedad' es que creo que los de google han conseguido la 'compilación del código', porque no vería otra novedad a eso.
#25
En el vídeo se ve claramente como en cuanto hacen una mínima modificación les toca compilar a mano.
Para usar ByteCode ya existe una cosa llamada Java, que no necesita acabar la compilación, cosa que si haria falta si le envías un fichero objeto comun, y segun que cosas envies, te tirarias un ratito compilando...
Pero vamos, aun que fuera mágico y se compilara en tiempo de descarga etc etc... esta limitado solo a tres sistemas operativos concretos, y a una plataforma concreta.
No funciona en PowerPC, no funciona en ARM, no funciona en Solaris, no funciona en las consolas.. etc etc.
#12 Esto no es para hacer paginas web, es para hacer aplicaciones que funcionen en el navegador.
En vez de tener que programar para windows, linux, mac, android etc se programa en Native Client que es multiplataforma y multiarquitectura y listo.
Es mas bien como java pero con rendimiento nativo.
#32 si funciona en ARM, lo pone muy clarito.
http://code.google.com/p/nativeclient/
Si quieren sustituir los S.O actuales por otros basados completamente en "cloud computing" la llevan clara.
Para mi, el código nativo y el procesamiento en la nube son conceptos totalmente diferentes que deben coexistir, y nunca pisarse el uno al otro.
Habrá aplicaciones que será cómodo ejecutar en la nube (correo, video/musica en streaming, web) y otras que directamente será imposible o si se puede, será un infierno conseguirlo (mega aplicaciones tipo CAD, diseño gráfico, procesamiento de video, juegos).
¿Para que matarse en portar Adobe Protoshop CS5 para que se pueda ejecutar en la nube cuando es 100.000 veces más fácil hacerlo de modo nativo?. Y siguiendo este hilo argumental, ¿para qué diseñar un SDK que permita ejecutar código nativo desde un explorador cuando es más fácil hacer directamente el programa en código nativo?.
#18
Aparte de eso aunque lo consiguieran a mí no me hace gracia ceder tanto control.
Empiezo a estar un poco hartito de los clubes de fan-boys... PP, PSOE, Apple, Google...
Si esto lo dice Google... es una "interesante propuesta"... si lo dice un ruso... es un virus.
Me encanta el detalle de que Native Client lo abrevien como NaCl.
Native Client, la sal de la web
Le estamos dando facilidades a skynet para que controle todo.
Está claro que existe mucha gente deseosa de poder incrustar en la web aplicaciones mucho más intensivas.
Si que es cierto que en gran manera viene a ser un ActiveX (y que solo por eso ya asusta) pero este parece más serio y limpio ya que trae un sandbox (algo que ActiveX nunca hizo por lo que se ganó tan mala fama), aun así sigue teniendo muchos de los problemas de ActiveX (necesitas versiones compiladas para cada plataforma), y los que iran apareciendo como posibles violaciones del sandbox y los peligros que eso trae.
Lo más interesante es que no rompe el paradigma de desarrollo web, ya que la presentacion sigues haciendola como siempre (HTML+JS+CSS), solo que ahora puedes delegar aquellas partes con una carga de procesamiento mucho más elevada para que se ejecuten en nativo, y eso ,como dicen, abre muchas puertas al desarrollo web.
No será una tecnologia corriente que todos usen en sus webs, más bien una opción high-tech que algunas empresas grandes utilizaran para hacer aplicaciones web multimedia bastante bestias, y eso merecerá la pena de ver.
Yo es que no sé por qué. pero todo esto que empiezan a hacer estos navegadores me da muy mala espina.
Los navegadores web ya no son navegadores, son editores de video, juegos, reproductores, etc... me siento viejo y nostálgico.
¿Otro plugin más para el navegador? En plena batalla Apple vs Adobe por el plugin de flash y se propone otra solución, que además es dependiente de la plataforma (problema de que el código sea nativo). Amén de los potenciales riesgos de seguridad que esto conlleva, incluso si se ejecuta en un entorno "sandbox". Por ejemplo Silverlight quiere ampliar continuamente las limitaciones de seguridad establecidas en el explorador para dar más flexibilidad a sus aplicaciones. Sinceramente no veo yo muy claro el futuro de est SDK.
Quizá para webs públicas no aporte mucho, pero en aplicaciones de intranet le veo muchas ventajas, ya que permitiría hacer las interfaces en Python o Ruby, por ejemplo.
El navegador como plataforma para construir aplicaciones.
Un sandbox?? cual?? Grand Theft Auto o Assassins Creed???
No sé, pero el único uso útil que podría ser hasta el momento son los juegos de video online, para que agregar una capa extra como lo es el navegador, si se puede ejecutar directamente desde el disco duro de la PC
No me entero mucho, pero por lo que interpreto es una(s) aplicacion(es) que instalarás en tu ordenador sin preocuparte el SO que tengas y utilizando el navegador como interface gráfica, no se correrá mas riesgo que con cualquier otra aplicación que te instales.
Yo veo en la actualidad los navegadores como intermediarios perfectos para aplicaciones de todo tipo, y si los juegos empiezan a hacer uso de estqa combinación si que se podrá jugar a cualquier cosa desde cualquier SO y plataforma, asi como utilizar cualquier procesador de textos por ejemplo.
Independientemente de que la opción de Google sea mejor o peor, el camino es bastante acertado creo.
Duplicada: Google Native Client y la portabilidad web (ENG)
Google Native Client y la portabilidad web (ENG)
blog.chromium.orginteresante, pero hoy por hoy existen muchos lenguajes para programar en web y solo se utilizan aquellos que son compatibles con la mayoria de navegadores web.
¿Alchemy?
No necesitas versiones compiladas para cada plataforma.
http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf
El mismo ejecutable servira (con el sdk actual todavia no) para linux/windows/mac en x82/x82-64 y arm lo que abarca el 99% de los ordenadores portatiles y telefonos moviles.
Qué fué de, que pasó con Google go ?
http://en.wikipedia.org/wiki/Google_go
¿Y la ventaja cual es? No lo entiendo, la manía de querer hacer maravillas dentro de la ventana del navegador. La aplicación se tendrá que descargar igualmente y será más insegura, en vez de hacer como toda la vida, bajarse el programa y ejecutarlo y ya está. ¿Versiones multiplataforma? Un estándar y se acabó. ¿Comodidad? Un botón que ponga "ejecutar" y se acabó. La única diferencia será que en vez de abrirse el programa por sí sólo, se abrirá dentro de la ventana del navegador, consumiendo más recursos para hacer la misma cosa.
No sé, no me convence. Si quieren usar un "Native Client" que lo hagan, pero externo al navegador. Vamos a terminar dependiendo demasiado de un sólo programa.
Con todo esto se está perdiendo el concepto de navegador...
Si realmente lo que se quiere hacer son aplicaciones potentenes, se pueden hacer independientes de los navegadores para tener un funcionamiento óptimo.
Como ya habéis comentado, lo veo una fuente de problemas como ya pasó con ActiveX.
Nada nuevo... de esto en el 2008 ya se habló, salvo que no era "GOOGLE" quien lo proponía, si no una asociación si nánimo de lucro asturiana (españa) en la que iba a ejecutarse código nativo en el navegador. http://wwwhatsnew.com/2008/04/18/redewa-nueva-plataforma-de-trabajo-online-se-aproxima/