#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:
El autor está pidiendo confirmación para volver a levantar el repo original.
#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 amenaza legalmente al creador de una aplicación libre para bajar tus datos
twitter.comTuenti 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.#4, #6, #7, Ya no hay excusa: https://diasporafoundation.org/switch_locale/es
· Wiki: https://wiki.diasporafoundation.org/Main_Page/es
· Android: https://f-droid.org/repository/browse/?fdid=com.voidcode.diasporawebclient
· Listado de pods: http://podupti.me
#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
En Linux, Flash sólo estará disponible para Chrome
blogs.adobe.comAdobe 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
#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/