#69 Al parecer era un problema con el sistema de autenticación de un plugin. Ya está solucionado.
#15 Es que no puede ser, estos talibanes del software libre dedican más tiempo a llorar que a hacer las cosas bien.
#52 Se os acabó el chollo de cobrar de Google, ahora tendréis que ganaros los garbanzos.
#79 Aún no me había decidido por ninguno. Gracias por la información.
El módulo de DRM de Adobe será un añadido externo, sólo los usuarios que lo quieran lo activarán y se bajará, pero no vendrá integrado en Firefox. Lo que se implementa es esta posibilidad de tenerlo quien quiera.
Adicionalmente, #14 el resto de navegadores ya implementa DRM integrado en el propio navegador, no como algo adicional.
Pensad que ahora mismo tenemos lo mismo con el plugin de Flash y Silverlight, añadidos que dan acceso al contenido con DRM. Con la diferencia que esto tiene un envoltorio libre con un sandbox que impedirá acceder a cosas que ahora mismo los plugins pueden acceder (identificadores únicos entre sitios, acceso al disco...)
Un resumen y más enlaces en español:
http://www.mozilla-hispano.org/mozilla-ofrecera-la-opcion-de-reproducir-contenido-con-drm-en-firefox/
Al parecer, Tuenti recula:
#43 San cagao
#27 La cosa es que ahí no puedes comprobar si han metido algo en ese .exe. En el repo está con el md5 y puedes comprobar que generándolo con el código sale el mismo exe.
#19 Aquí no se distribuye ningún binario propietario, es un script que usa un API de acceso, es el usuario el que localmente lo usa, no el desarrollador del script.
Tuenti ha amenazado al creador de la aplicación libre 20up, la cual permite bajar todas tus fotos, comentarios y contactos de esta red social, para que retire en 48h la misma por supuestamente violar sus términos de uso. Estos hechos han ocurrido a las pocas horas de aparecer una mención a esta aplicación en El Mundo. El autor ha retirado la aplicación cautelarmente, pero muchos otros usuarios usuarios ya tenían "forks" (más info en los comentarios)
#10 Poder obtener todos tus datos subidos a la red social. Tuenti no ofrece ningún mecanismo para ello.
#7 La ley permite hacer ingeniería inversa de protocolos y APIs cuyo objetivo sea garantizar la interoperatibilidad:
https://en.wikipedia.org/wiki/Reverse_engineering#European_Union
Si no, cerremos samba, libreoffice, ntf3g y decenas de ejemplos más de aplicaciones que usan APIs privadas.
#10 Poder obtener todos tus datos subidos a la red social. Tuenti no ofrece ningún mecanismo para ello.
#8 pregunto desde ignorancia, una cosa es crear tu api a imitacion de otra, ejemplo, libreoffice leyendo .docx y otra usar la API desde los servidores de tuenti para tu aplicacion? seria como distribuir un fragmento binario de ms-word en libreoffice y eso es ilegal
de todas formas si lo hiciera de manera recursiva, es decir un script que lo que hace es ir descargando, pues es la api publica, asi que le pueden acusar si acaso de sobresaturar servidores, pero no de usar la api
#19 Aquí no se distribuye ningún binario propietario, es un script que usa un API de acceso, es el usuario el que localmente lo usa, no el desarrollador del script.
#19 Una API son como los botones del ascensor. Usar la API de Tuenti es como apretar esos botones. No es para nada, como dices, "distribuir un fragmento binario". No se está copiando el código interno que las hace funcionar, que en la analogía del ascensor sería copiar sus circuitos internos.
Tuenti está amenazando porque alguien está apretando los botones de su ascensor.
#4 Debe serlo, puedes verificar el md5 del .exe que se ha creado usando el código del repo o usar el .py desde el intérprete de python en vez del .exe
Algunos teníamos forks creados desde hace meses que siguen online:
http://nukeador.github.io/20up/
https://github.com/nukeador/20up
Otros muchos usuarios lo tenían descargado al ser código libre GPL3.
La noticia en El Mundo de hace unos días: http://www.elmundo.es/happy-fm/2014/03/20/53298c4722601d1d5f8b4575.html?a=b14abed5e26d4879efe9e2e3f16dc3c9&t=1395618402
Tuenti: FaceBook ofrece ese servicio de forma nativa, a ti te lo dan hecho. ¿Que problema ves en esta funcionalidad?
#3: Pues yo no me alegro, porque para los amigos prefiero Tuenti, y FaceBook para las aficiones y demás. Tuenti es más personal y privada.
#1: Interesante, pero esperaré un poco, me sale esto en Virus Total:
TrendMicro-HouseCall TROJ_GEN.F47V0308
El resto de antivirus no detectan problemas. ¿Será un falso positivo?
#4 Debe serlo, puedes verificar el md5 del .exe que se ha creado usando el código del repo o usar el .py desde el intérprete de python en vez del .exe
#3, Motivo:
Telefónica, S.A.
#9 Por alguna razón el enlace https://diasporafoundation.org/switch_locale/es lleva de vuelta a este meneo.
Supongo que habrá algún bug en el código de menéame.
cc:
gallir
#12 No, es esa página que te hace volver al "referer". Es para cambiar el idioma (y nada más).
Muchas gracias a todos por menear la noticia, me alegra ver tanto apoyo!
Lo peor de todo es que encima Tuenti difama: ni utilizo su nombre, ni es una aplicación de phising (está el código fuente, cualquiera lo puede ver).
En octubre ya se pusieron en contacto conmigo para decirme que tenía que cambiar algunas cosillas, entre ellas el nombre (se llamaba "tuentiUp"). Las cambié y no me han dado más la tabarra... Hasta, qué casualidad, el momento en el que salió en El Mundo en la noticia que ha puesto #1. Ya sabían de la existencia de este programa, pero hasta que no se ha hecho famoso, no les ha importado.
#20 Muchas gracias por la aplicación, la acabo de utilizar y funciona genial!
#1 Muchas gracias!
#23 Javascript se compila en tiempo real (JIT) para ejecutarse en la mayoría de motores actuales, con muchas optimizaciones sobre funciones habituales, es muuucho más complejo que tu afirmación de "es interpretado":
http://en.wikipedia.org/wiki/SpiderMonkey_%28JavaScript_engine%29#IonMonkey
WebGL es un estándar, y como tal se espera (y se recomienda) que los navegadores lo implementen. Incluso IE11 lo va a a hacer, Opera 12 tiene parte y en la 15 lo tendrá completo:
http://caniuse.com/#search=webgl
Una aplicación nativa no te asegura que no habrá agujeros de seguridad, fugas de memoria o cuelgues. Actualmente los navegadores suelen trabajar en sanboxes y procesos separados, los nuevos motores como Servo (Firefox) y Blink (Chrome) usará todo el potencial de varias CPUs.
Como digo más arriba, de momento no se tiene el mismo rendimiento 1x que una aplicación en C++, pero se tiene 2x y se espera reducir a 1,5x muy pronto. Estos datos hacen que la universalidad de poder ejecutarse en todo lugar compense una penalización muy baja de rendimiento que cada día es menor.
#21 Lo está:
Compatibilidad: Todos los navegadores modernos. En cualquier sitio donde tengas uno se ejecutará sin tener que reescribir el código.
Rendimiento: Usando la librería asm.js tienes actualmente entorno a 2x comparado con nativo (c++), y cada día se está reduciendo más, en muchos casos mejor rendimiento que una ejecución en máquina virtual java. Hace unos años estábamos hablando de 7 y 8x.
Ten en cuenta que el código está escrito en c++ y compilado a javascript de una forma muy eficiente.
http://www.mozilla-hispano.org/asm-js-compilando-a-javascript/
#22 Javascript es interpretado. Siempre será más lento y tragará más recursos. Fin de la discusión del rendimiento. No todos los navegadores modernos soportan WebGL correctamente. Opera no, por ejemplo. Fin de la discusión de la compatibilidad. Además, el navegador es para ver webs, no para hacer aplicaciones. Agujeros de seguridad, fugas de memoria, cuelgues (del navegador), basta ya de hacerlo todo en el navegador. Es mucho más eficiente una aplicación nativa y se debería optar por eso siempre que fuese posible. No tiene sentido abrir el navegador para ejecutar aplicaciones 3D tipo juegos (aunque sí que tiene sentido usar WebGL par mostrar ciertas cosas)
#23 Javascript se compila en tiempo real (JIT) para ejecutarse en la mayoría de motores actuales, con muchas optimizaciones sobre funciones habituales, es muuucho más complejo que tu afirmación de "es interpretado":
http://en.wikipedia.org/wiki/SpiderMonkey_%28JavaScript_engine%29#IonMonkey
WebGL es un estándar, y como tal se espera (y se recomienda) que los navegadores lo implementen. Incluso IE11 lo va a a hacer, Opera 12 tiene parte y en la 15 lo tendrá completo:
http://caniuse.com/#search=webgl
Una aplicación nativa no te asegura que no habrá agujeros de seguridad, fugas de memoria o cuelgues. Actualmente los navegadores suelen trabajar en sanboxes y procesos separados, los nuevos motores como Servo (Firefox) y Blink (Chrome) usará todo el potencial de varias CPUs.
Como digo más arriba, de momento no se tiene el mismo rendimiento 1x que una aplicación en C++, pero se tiene 2x y se espera reducir a 1,5x muy pronto. Estos datos hacen que la universalidad de poder ejecutarse en todo lugar compense una penalización muy baja de rendimiento que cada día es menor.
El terminal ZTE va dirigido a un mercado muy específico, los usuarios que no tienen aún un smartphone y hasta ahora no se lo han podido permitir, el objetivo no es competir con Android o iOS. Puede parecer difícil de entender en un mercado en el que los teléfonos que salen son para ser el tope de gama y barrer el mercado.
#6 Firefox OS no es un "navegador empotrado" es un SO completo creado con tecnologías web y con el motor Gecko, que además implementa nuevas WebAPIs para que se pueda acceder de forma estándar al hardware.
Ah, y la web está ya lista para que se desarrolle alguna cosa más que un minijuego
http://www.unrealengine.com/html5/
#16 Me quedo con las ganas hasta que pueda pasarme a otro ordenador con Firefox Pero gracias por la referencia
#21 Lo está:
Compatibilidad: Todos los navegadores modernos. En cualquier sitio donde tengas uno se ejecutará sin tener que reescribir el código.
Rendimiento: Usando la librería asm.js tienes actualmente entorno a 2x comparado con nativo (c++), y cada día se está reduciendo más, en muchos casos mejor rendimiento que una ejecución en máquina virtual java. Hace unos años estábamos hablando de 7 y 8x.
Ten en cuenta que el código está escrito en c++ y compilado a javascript de una forma muy eficiente.
http://www.mozilla-hispano.org/asm-js-compilando-a-javascript/
#22 Javascript es interpretado. Siempre será más lento y tragará más recursos. Fin de la discusión del rendimiento. No todos los navegadores modernos soportan WebGL correctamente. Opera no, por ejemplo. Fin de la discusión de la compatibilidad. Además, el navegador es para ver webs, no para hacer aplicaciones. Agujeros de seguridad, fugas de memoria, cuelgues (del navegador), basta ya de hacerlo todo en el navegador. Es mucho más eficiente una aplicación nativa y se debería optar por eso siempre que fuese posible. No tiene sentido abrir el navegador para ejecutar aplicaciones 3D tipo juegos (aunque sí que tiene sentido usar WebGL par mostrar ciertas cosas)
#23 Javascript se compila en tiempo real (JIT) para ejecutarse en la mayoría de motores actuales, con muchas optimizaciones sobre funciones habituales, es muuucho más complejo que tu afirmación de "es interpretado":
http://en.wikipedia.org/wiki/SpiderMonkey_%28JavaScript_engine%29#IonMonkey
WebGL es un estándar, y como tal se espera (y se recomienda) que los navegadores lo implementen. Incluso IE11 lo va a a hacer, Opera 12 tiene parte y en la 15 lo tendrá completo:
http://caniuse.com/#search=webgl
Una aplicación nativa no te asegura que no habrá agujeros de seguridad, fugas de memoria o cuelgues. Actualmente los navegadores suelen trabajar en sanboxes y procesos separados, los nuevos motores como Servo (Firefox) y Blink (Chrome) usará todo el potencial de varias CPUs.
Como digo más arriba, de momento no se tiene el mismo rendimiento 1x que una aplicación en C++, pero se tiene 2x y se espera reducir a 1,5x muy pronto. Estos datos hacen que la universalidad de poder ejecutarse en todo lugar compense una penalización muy baja de rendimiento que cada día es menor.
#9 Llevan trabajando codo con codo desde hace más de un año. Puedes ver los commits tanto de gaia (las apps y la UI) como de B2G (el backend gecko)
https://github.com/mozilla-b2g/gaia
https://github.com/mozilla-b2g/B2G
#6 Telefónica I+D tiene un equipo bastante grande de desarrolladores pagados por ellos que se han integrado con el equipo de Mozilla y están ayudando a desarrollar parte del sistema.
#9 Llevan trabajando codo con codo desde hace más de un año. Puedes ver los commits tanto de gaia (las apps y la UI) como de B2G (el backend gecko)
https://github.com/mozilla-b2g/gaia
https://github.com/mozilla-b2g/B2G
Adobe anuncia un acuerdo con Google por el que las próximas versiones para Linux de Flash sólo estarán disponibles mediante el API PPAPI (Pepper), lo que significa que sólo funcionará en el navegador Google Chrome. Otros fabricantes como Mozilla ya anunciaron en su momento que no iban a implementar PPAPI por considerar que duplican APIs estándar ya existentes https://mail.mozilla.org/pipermail/plugin-futures/2010-April/000088.html
Por aclarar un poco más:
Google tiene un API llamado PPAPI para realizar muchas cosas (no sólo plugins). Mozilla dijo en su momento que no lo iba a implementar porque intenta sustituir muchas cosas que se pueden hacer desde APIs web estándar con sus propios métodos. APIs web estándar como la de geolocalización: http://dev.w3.org/geo/api/spec-source.html
Google llega a un acuerdo con Adobe por la que haya que usar sí o sí PPAPI para usar el plugin de Flash, intentando obligar así a otros fabricantes a que implementen PPAPI si quieren que flash funcione en sus navegadores.
Traducción de la opinión de Robert O'Callahan sobre Pepper:
"Los navegadores ya ofrecen una plataforma API potente para código "aislado": las APIs web basadas en estándares. Actualmente Pepper ofrece algunas funcionalidades que las Web APIs aún no, pero no veo la razón por la que el código nativo tenga una funcionalidad diferente a las aplicaciones web JS."
#2 Corrijo el título para que quede más claro.
Cuando en al actualizad los navegadores se dan tanto la mano en cuestiones técnicas, la pregunta debería ser: ¿Qué navegador se preocupa más por sus usuarios?
http://www.mozilla.org/about/manifesto.es.html
Tuenti ha amenazado al creador de la aplicación libre 20up, la cual permite bajar todas tus fotos, comentarios y contactos de esta red social, para que retire en 48h la misma por supuestamente violar sus términos de uso. Estos hechos han ocurrido a las pocas horas de aparecer una mención a esta aplicación en El Mundo. El autor ha retirado la aplicación cautelarmente, pero muchos otros usuarios usuarios ya tenían "forks" (más info en los comentarios)
Adobe anuncia un acuerdo con Google por el que las próximas versiones para Linux de Flash sólo estarán disponibles mediante el API PPAPI (Pepper), lo que significa que sólo funcionará en el navegador Google Chrome. Otros fabricantes como Mozilla ya anunciaron en su momento que no iban a implementar PPAPI por considerar que duplican APIs estándar ya existentes https://mail.mozilla.org/pipermail/plugin-futures/2010-April/000088.html
Mozilla, a través de su comunidad en España, Mozilla Hispano, celebrará la reciente publicación del navegador web Firefox 4 para escritorio y dispositivos móviles, organizando un evento el día 14 de abril a las 19:30, al que asistirán destacados colaboradores del proyecto, entre ellos Pascal Chevrel, secretario general de Mozilla en Europa. La inscripción es libre y gratuita.
Desde el 1 de enero de 2010, la administración española está obligada por ley a comunicarse con sus ciudadanos usando estándares abiertos, tanto en los documentos a presentar, como en el cumplimiento de ellos en sus páginas webs para el acceso electrónico. Hace unos días se publicaba en el BOE el Esquema Nacional de Interoperabilidad con la explicación detallada.
Mozilla acaba de publicar, tras dos años desde la salida de la versión 2, la versión 3.0 de su cliente de correo Thunderbird. Mozilla Hispano recoge en español un gran listado de cambios y explicaciones en vídeo sobre las mejoras que ofrece a los usuarios.
Mozilla Hispano Labs acaba de publicar la versión final de Tuentifox 0.1, una extensión para usuarios de la red social Tuenti que les permite estar actualizados de sus cambios y añadir contenido a su perfil desde Firefox. La extensión se ha desarrollado por la comunidad tras el taller que Mozilla realizó en Madrid y se ha basado en la participación de los usuarios para ir añadiendo mejoras.
Para celebrar la publicación de la última versión de Firefox, la comunidad de Mozilla ha organizado diversas fiestas a la largo del mundo. Colaboradores, usuarios y curiosos tendrán un día para reunirse y celebrarlo. ¡Apúntate a la más cercana a tu ciudad!
#7 El proceso de inclusión no tiene coste, pero requiere cumplir diversas medidas estrictas de seguridad. Durante todos estos años, si lees el bug verás como se han ido solicitando estas medidas, certificaciones... etc
No ha sido hasta ahora que se han cumplido todas. Aquí tienes el proceso, y puedes auditarlo ya que se ha hecho en abierto:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
#69 Al parecer era un problema con el sistema de autenticación de un plugin. Ya está solucionado.
#15 Es que no puede ser, estos talibanes del software libre dedican más tiempo a llorar que a hacer las cosas bien.
#52 Se os acabó el chollo de cobrar de Google, ahora tendréis que ganaros los garbanzos.
#79 Aún no me había decidido por ninguno. Gracias por la información.
El módulo de DRM de Adobe será un añadido externo, sólo los usuarios que lo quieran lo activarán y se bajará, pero no vendrá integrado en Firefox. Lo que se implementa es esta posibilidad de tenerlo quien quiera.
Adicionalmente, #14 el resto de navegadores ya implementa DRM integrado en el propio navegador, no como algo adicional.
Pensad que ahora mismo tenemos lo mismo con el plugin de Flash y Silverlight, añadidos que dan acceso al contenido con DRM. Con la diferencia que esto tiene un envoltorio libre con un sandbox que impedirá acceder a cosas que ahora mismo los plugins pueden acceder (identificadores únicos entre sitios, acceso al disco...)
Un resumen y más enlaces en español:
http://www.mozilla-hispano.org/mozilla-ofrecera-la-opcion-de-reproducir-contenido-con-drm-en-firefox/
Al parecer, Tuenti recula:
#43 San cagao
#27 La cosa es que ahí no puedes comprobar si han metido algo en ese .exe. En el repo está con el md5 y puedes comprobar que generándolo con el código sale el mismo exe.
#19 Aquí no se distribuye ningún binario propietario, es un script que usa un API de acceso, es el usuario el que localmente lo usa, no el desarrollador del script.
#10 Poder obtener todos tus datos subidos a la red social. Tuenti no ofrece ningún mecanismo para ello.
#7 La ley permite hacer ingeniería inversa de protocolos y APIs cuyo objetivo sea garantizar la interoperatibilidad:
https://en.wikipedia.org/wiki/Reverse_engineering#European_Union
Si no, cerremos samba, libreoffice, ntf3g y decenas de ejemplos más de aplicaciones que usan APIs privadas.
#10 Poder obtener todos tus datos subidos a la red social. Tuenti no ofrece ningún mecanismo para ello.
#8 pregunto desde ignorancia, una cosa es crear tu api a imitacion de otra, ejemplo, libreoffice leyendo .docx y otra usar la API desde los servidores de tuenti para tu aplicacion? seria como distribuir un fragmento binario de ms-word en libreoffice y eso es ilegal
de todas formas si lo hiciera de manera recursiva, es decir un script que lo que hace es ir descargando, pues es la api publica, asi que le pueden acusar si acaso de sobresaturar servidores, pero no de usar la api
#19 Aquí no se distribuye ningún binario propietario, es un script que usa un API de acceso, es el usuario el que localmente lo usa, no el desarrollador del script.
#19 Una API son como los botones del ascensor. Usar la API de Tuenti es como apretar esos botones. No es para nada, como dices, "distribuir un fragmento binario". No se está copiando el código interno que las hace funcionar, que en la analogía del ascensor sería copiar sus circuitos internos.
Tuenti está amenazando porque alguien está apretando los botones de su ascensor.
#4 Debe serlo, puedes verificar el md5 del .exe que se ha creado usando el código del repo o usar el .py desde el intérprete de python en vez del .exe
Algunos teníamos forks creados desde hace meses que siguen online:
http://nukeador.github.io/20up/
https://github.com/nukeador/20up
Otros muchos usuarios lo tenían descargado al ser código libre GPL3.
La noticia en El Mundo de hace unos días: http://www.elmundo.es/happy-fm/2014/03/20/53298c4722601d1d5f8b4575.html?a=b14abed5e26d4879efe9e2e3f16dc3c9&t=1395618402
Tuenti: FaceBook ofrece ese servicio de forma nativa, a ti te lo dan hecho. ¿Que problema ves en esta funcionalidad?
#3: Pues yo no me alegro, porque para los amigos prefiero Tuenti, y FaceBook para las aficiones y demás. Tuenti es más personal y privada.
#1: Interesante, pero esperaré un poco, me sale esto en Virus Total:
TrendMicro-HouseCall TROJ_GEN.F47V0308
El resto de antivirus no detectan problemas. ¿Será un falso positivo?
#4 Debe serlo, puedes verificar el md5 del .exe que se ha creado usando el código del repo o usar el .py desde el intérprete de python en vez del .exe
#3, Motivo:
Telefónica, S.A.
#9 Por alguna razón el enlace https://diasporafoundation.org/switch_locale/es lleva de vuelta a este meneo.
Supongo que habrá algún bug en el código de menéame.
cc:gallir
#12 No, es esa página que te hace volver al "referer". Es para cambiar el idioma (y nada más).
Muchas gracias a todos por menear la noticia, me alegra ver tanto apoyo!
Lo peor de todo es que encima Tuenti difama: ni utilizo su nombre, ni es una aplicación de phising (está el código fuente, cualquiera lo puede ver).
En octubre ya se pusieron en contacto conmigo para decirme que tenía que cambiar algunas cosillas, entre ellas el nombre (se llamaba "tuentiUp"). Las cambié y no me han dado más la tabarra... Hasta, qué casualidad, el momento en el que salió en El Mundo en la noticia que ha puesto #1. Ya sabían de la existencia de este programa, pero hasta que no se ha hecho famoso, no les ha importado.
#20 Muchas gracias por la aplicación, la acabo de utilizar y funciona genial!
#1 Muchas gracias!
#23 Javascript se compila en tiempo real (JIT) para ejecutarse en la mayoría de motores actuales, con muchas optimizaciones sobre funciones habituales, es muuucho más complejo que tu afirmación de "es interpretado":
http://en.wikipedia.org/wiki/SpiderMonkey_%28JavaScript_engine%29#IonMonkey
WebGL es un estándar, y como tal se espera (y se recomienda) que los navegadores lo implementen. Incluso IE11 lo va a a hacer, Opera 12 tiene parte y en la 15 lo tendrá completo:
http://caniuse.com/#search=webgl
Una aplicación nativa no te asegura que no habrá agujeros de seguridad, fugas de memoria o cuelgues. Actualmente los navegadores suelen trabajar en sanboxes y procesos separados, los nuevos motores como Servo (Firefox) y Blink (Chrome) usará todo el potencial de varias CPUs.
Como digo más arriba, de momento no se tiene el mismo rendimiento 1x que una aplicación en C++, pero se tiene 2x y se espera reducir a 1,5x muy pronto. Estos datos hacen que la universalidad de poder ejecutarse en todo lugar compense una penalización muy baja de rendimiento que cada día es menor.
#21 Lo está:
Compatibilidad: Todos los navegadores modernos. En cualquier sitio donde tengas uno se ejecutará sin tener que reescribir el código.
Rendimiento: Usando la librería asm.js tienes actualmente entorno a 2x comparado con nativo (c++), y cada día se está reduciendo más, en muchos casos mejor rendimiento que una ejecución en máquina virtual java. Hace unos años estábamos hablando de 7 y 8x.
Ten en cuenta que el código está escrito en c++ y compilado a javascript de una forma muy eficiente.
http://www.mozilla-hispano.org/asm-js-compilando-a-javascript/
#22 Javascript es interpretado. Siempre será más lento y tragará más recursos. Fin de la discusión del rendimiento. No todos los navegadores modernos soportan WebGL correctamente. Opera no, por ejemplo. Fin de la discusión de la compatibilidad. Además, el navegador es para ver webs, no para hacer aplicaciones. Agujeros de seguridad, fugas de memoria, cuelgues (del navegador), basta ya de hacerlo todo en el navegador. Es mucho más eficiente una aplicación nativa y se debería optar por eso siempre que fuese posible. No tiene sentido abrir el navegador para ejecutar aplicaciones 3D tipo juegos (aunque sí que tiene sentido usar WebGL par mostrar ciertas cosas)
#23 Javascript se compila en tiempo real (JIT) para ejecutarse en la mayoría de motores actuales, con muchas optimizaciones sobre funciones habituales, es muuucho más complejo que tu afirmación de "es interpretado":
http://en.wikipedia.org/wiki/SpiderMonkey_%28JavaScript_engine%29#IonMonkey
WebGL es un estándar, y como tal se espera (y se recomienda) que los navegadores lo implementen. Incluso IE11 lo va a a hacer, Opera 12 tiene parte y en la 15 lo tendrá completo:
http://caniuse.com/#search=webgl
Una aplicación nativa no te asegura que no habrá agujeros de seguridad, fugas de memoria o cuelgues. Actualmente los navegadores suelen trabajar en sanboxes y procesos separados, los nuevos motores como Servo (Firefox) y Blink (Chrome) usará todo el potencial de varias CPUs.
Como digo más arriba, de momento no se tiene el mismo rendimiento 1x que una aplicación en C++, pero se tiene 2x y se espera reducir a 1,5x muy pronto. Estos datos hacen que la universalidad de poder ejecutarse en todo lugar compense una penalización muy baja de rendimiento que cada día es menor.
El terminal ZTE va dirigido a un mercado muy específico, los usuarios que no tienen aún un smartphone y hasta ahora no se lo han podido permitir, el objetivo no es competir con Android o iOS. Puede parecer difícil de entender en un mercado en el que los teléfonos que salen son para ser el tope de gama y barrer el mercado.
#6 Firefox OS no es un "navegador empotrado" es un SO completo creado con tecnologías web y con el motor Gecko, que además implementa nuevas WebAPIs para que se pueda acceder de forma estándar al hardware.
Ah, y la web está ya lista para que se desarrolle alguna cosa más que un minijuego
http://www.unrealengine.com/html5/
#16 Me quedo con las ganas hasta que pueda pasarme a otro ordenador con Firefox Pero gracias por la referencia
#21 Lo está:
Compatibilidad: Todos los navegadores modernos. En cualquier sitio donde tengas uno se ejecutará sin tener que reescribir el código.
Rendimiento: Usando la librería asm.js tienes actualmente entorno a 2x comparado con nativo (c++), y cada día se está reduciendo más, en muchos casos mejor rendimiento que una ejecución en máquina virtual java. Hace unos años estábamos hablando de 7 y 8x.
Ten en cuenta que el código está escrito en c++ y compilado a javascript de una forma muy eficiente.
http://www.mozilla-hispano.org/asm-js-compilando-a-javascript/
#22 Javascript es interpretado. Siempre será más lento y tragará más recursos. Fin de la discusión del rendimiento. No todos los navegadores modernos soportan WebGL correctamente. Opera no, por ejemplo. Fin de la discusión de la compatibilidad. Además, el navegador es para ver webs, no para hacer aplicaciones. Agujeros de seguridad, fugas de memoria, cuelgues (del navegador), basta ya de hacerlo todo en el navegador. Es mucho más eficiente una aplicación nativa y se debería optar por eso siempre que fuese posible. No tiene sentido abrir el navegador para ejecutar aplicaciones 3D tipo juegos (aunque sí que tiene sentido usar WebGL par mostrar ciertas cosas)
#23 Javascript se compila en tiempo real (JIT) para ejecutarse en la mayoría de motores actuales, con muchas optimizaciones sobre funciones habituales, es muuucho más complejo que tu afirmación de "es interpretado":
http://en.wikipedia.org/wiki/SpiderMonkey_%28JavaScript_engine%29#IonMonkey
WebGL es un estándar, y como tal se espera (y se recomienda) que los navegadores lo implementen. Incluso IE11 lo va a a hacer, Opera 12 tiene parte y en la 15 lo tendrá completo:
http://caniuse.com/#search=webgl
Una aplicación nativa no te asegura que no habrá agujeros de seguridad, fugas de memoria o cuelgues. Actualmente los navegadores suelen trabajar en sanboxes y procesos separados, los nuevos motores como Servo (Firefox) y Blink (Chrome) usará todo el potencial de varias CPUs.
Como digo más arriba, de momento no se tiene el mismo rendimiento 1x que una aplicación en C++, pero se tiene 2x y se espera reducir a 1,5x muy pronto. Estos datos hacen que la universalidad de poder ejecutarse en todo lugar compense una penalización muy baja de rendimiento que cada día es menor.
#9 Llevan trabajando codo con codo desde hace más de un año. Puedes ver los commits tanto de gaia (las apps y la UI) como de B2G (el backend gecko)
https://github.com/mozilla-b2g/gaia
https://github.com/mozilla-b2g/B2G
#6 Telefónica I+D tiene un equipo bastante grande de desarrolladores pagados por ellos que se han integrado con el equipo de Mozilla y están ayudando a desarrollar parte del sistema.
#9 Llevan trabajando codo con codo desde hace más de un año. Puedes ver los commits tanto de gaia (las apps y la UI) como de B2G (el backend gecko)
https://github.com/mozilla-b2g/gaia
https://github.com/mozilla-b2g/B2G
Por aclarar un poco más:
Google tiene un API llamado PPAPI para realizar muchas cosas (no sólo plugins). Mozilla dijo en su momento que no lo iba a implementar porque intenta sustituir muchas cosas que se pueden hacer desde APIs web estándar con sus propios métodos. APIs web estándar como la de geolocalización: http://dev.w3.org/geo/api/spec-source.html
Google llega a un acuerdo con Adobe por la que haya que usar sí o sí PPAPI para usar el plugin de Flash, intentando obligar así a otros fabricantes a que implementen PPAPI si quieren que flash funcione en sus navegadores.
Traducción de la opinión de Robert O'Callahan sobre Pepper:
"Los navegadores ya ofrecen una plataforma API potente para código "aislado": las APIs web basadas en estándares. Actualmente Pepper ofrece algunas funcionalidades que las Web APIs aún no, pero no veo la razón por la que el código nativo tenga una funcionalidad diferente a las aplicaciones web JS."
#2 Corrijo el título para que quede más claro.
Cuando en al actualizad los navegadores se dan tanto la mano en cuestiones técnicas, la pregunta debería ser: ¿Qué navegador se preocupa más por sus usuarios?
http://www.mozilla.org/about/manifesto.es.html
¿Cómo es posible que la gente siga repitiendo el mito de que Firefox consume más memoria que otros navegadores? Desde la versión 3, Firefox ha sido el navegador que menos memoria consume y de los que mayor atención ha puesto en que no haya ningún tipo de fuga de memoria añadiendo nuevas características para su control.
#7 llamalo como quieras, pero firefox va muy muy muy muy lento, y chrome no, por lo menos a mi, en dos ordenadores que he probado
#7 ORLY? mira esto http://goo.gl/Oy5mp y dime que es el que menos memoria consume, mismo numero de extensiones, ninguna vamos y mismas pestañas abiertas, 243 Megas mas ocupa firefox y subiendo, ahora mismo esta en 360Megas, chrome en 106.
#26 yo ahora mismo tengo 7 pestañas abiertas en firefox consumiendo 236 Mb (más o menos), si las abro en chrome entre todas me suman 286 Mb. En la versión 3 de firefox sí recuerdo que me llegaba hasta 500 Mb de consumo, pero en esta nunca lo he visto así
#39 las mías son esas mismas versiones rodando en W7
#36 Hasta la versión 3.6.15(aproximadamente) el consumo de memoria del firefox incluia los plugins el flash se come el solo 100MiB sin despeinarse.
#26 ¿Estás comparando dos procesos? Te recuerdo que Chrome usa un proceso por pestaña... lo que tienes que hacer es poner about:memory en la barra de direcciones de Chrome para que te dé los datos
#48 no, no, el process explorer te pone el proceso padre y los hijos el padre suma la memoria de todos los hijos, así lo tengo yo configurado, que cabron!!! el process explorer no suma bien, retiro lo dicho el firefox consume MENOS memoria a mismo numero de pestañas abiertas, es decir con 15, firefox ocupa 360 Megas, chrome 510 Megas, retiro lo dicho, el about:memory es mas fiable que el process explorer, esto me pasa por fiarme de software microsoft.
#51 Nuevamente: tampoco te fíes del todo del about:config porque no estoy seguro de que descuente la memoria común de los procesos: Si tienes dos procesos iguales el SO usa memoria común para la parte ejecutable (en teoría inmutable), pero te contará dos veces esa parte, lo mismo es el process explorer el que tiene razón
#7 El proceso de inclusión no tiene coste, pero requiere cumplir diversas medidas estrictas de seguridad. Durante todos estos años, si lees el bug verás como se han ido solicitando estas medidas, certificaciones... etc
No ha sido hasta ahora que se han cumplido todas. Aquí tienes el proceso, y puedes auditarlo ya que se ha hecho en abierto:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/