El principal desarrollador de Flash para Linux ha publicado en su blog una versión beta del conocido plugin. ¡Se acabaron nsplugginwrapper y demás ñapas!
#8#7 eso entra en el apartado de ñapas, pq tira de un wrapper ;) Instalable siempre ha sido.. pero nunca nativo. El rendimiento es un asquito y peta a ratos, como los patos...
#12Bueno, primero sacan la versión 10 para 32 bits quesífuncionabien (antes la 9 era un dolor de cabeza constante) y ahora sorprenden con esta tremenda noticia!!, que interesante se está poniendo esto.
#14#12 eso es relativo... con la 9 en linux se veia todo bien (los videos a pantalla completa bastantem mal, pero bueno)...a hora con la 10, se ven bien, pero me he tenido que instalar el flashblock en el firefox por que segun que flash de publicidad cierra directamente el navegador.
#17Justo hace una semana le estuve explicando a un cliente que el Flash le daba problemas en su portátil con Linux porque su procesador era de 64bits. El Gnash, por desgracia, aún no está todo lo maduro que sería deseable.
#18#14 y #16 jeje pues como siempre todo es relativo. A mi el flash 9 hacía que firefox se guindara a cada rato y en el mejor de los casos hacía que se cerrara de repente, pero luego desde el mismo momento que empecé a probar la beta 2 de flash 10 ya no he vuelto a tener esos problemas, aunque hay una página en particular que está atestada de videos y animaciones flash (y hablo de por lo menos 10 a 20 por portada, e incluso más) y esa sí hace que firefox la pase mal porque empieza a jalar recursos como loco tratando de abrir todos los swf pero eso lo arreglo con lo mismo que menciona #14, usando flashblock :)
Por cierto que ahora que lo pienso, aún estoy con la RC 2 de flash 10, pero bueno ya que me va bien voy a aplicar aquello de " sifuncionanoloarregles " para no actualizarlo, al menos por ahora.
#25¿Alguien sigue usando flash a estas alturas? Si solo sirve para banners de publicidad y chorradas en youtube (te descargas el flv y lo ves donde te de la gana).
Que se hubiesen espabilado en su día, que seguir usando sistemas a 32 bits es un poco lamentable.
#30Pues esto no deja de ser un apaño, simplemente arregla un poco las cosas hasta que aparezca otro procesador, o cualquier otro cambio de arquitectura que haga que la cosa vuelva a estar complicada, por no hablar de qué pasa con arquitecturas más minoritarias que no tienen plugin.
Lo que hace falta es que el plugin de flash sea libre, un binario está bien, pero es un parche.
#31#30 eso, que en lugar de hacer las cosas bien adobe, lo libere y le solucionen la papeleta otros mientras siguen ganando dinero.
Me da a mi que el flash tiene que ser internamente una chapuza de escandalo, por los problemas que estan teniendo para portarlo a linux(y cualquier otra cosa distinta de windows) y a 64 bits.
Hay que joderse, años y años con la guerra de navegadores, el intentar que se respeten los estándares, y ahora que por fin nos empezamos a librar poco a poco de la dependencia de IE, que tenemos Firefox, Opera, el motor WebKit, etc. resulta que una sola empresa tiene toda la web cogida literalmente por los huevos con el puto flash.
No me extraña que Gnash sea el proyecto de máxima prioridad de la FSF...
#34#32 Quizá no liberen el código del reproductor Flash, y mucho menos de los editores, pero al menos han liberado las especificaciones hace poco así que ahora cualquiera puede leerlas e implementar su propio reproductor sin riesgo a ser demandado por Adobe, lo que seguro que ayuda a proyectos como Gnash. www.openscreenproject.org/
#35Sé que esto no es la noticia (o sí?) pero querría destacar el hecho que, (por vez primera?) se ha publicado la versión para GNU/Linux ¡antes que para cualquier otro SO!
#36#34 Sí, pero el esfuerzo que se necesita para implementar un reproductor independiente es tremendo, y a ver quién garantiza que funcione con cualquier swf... Es muy jodido, además Flash siempre irá actualizándose cada poco tiempo añadiendo nueva funcionalidad. Es lo mismo que ocurre con el "estándar" de Office 2007. Especificación pública pero en la práctica imposible de implementar.
No nos engañemos, ni Gnash ni sfwdec ni ningún proyecto estará nunca a la altura del plugin oficial.
Adobe compró Macromedia y ahí la jodimos, porque ellos mismos se han encargado de frenar SVG todo lo posible, que es el único estándar abierto que algún día y con JavaScript podría competir cara a cara con Flash.
En Opera, por ejemplo ya se hicieron demostraciones de vídeos embebidos en páginas web usando SVG, ya veremos qué pasa al final con HTML 5. Si al menos se pudiera evitar tener que usar Flash para ver vídeos sería un enorme paso.
#38#15: el software de 64 bits NO funciona mejor que el de 32 bits. Según todas las experiencias, y después de muchos años de tener procesadores de 64 bits, el resultado es que es muy raro un programa que muestre alguna diferencia de performance al correr en 64 bits. La única ventaja real es que con procesadores de 64 bits se puede acceder a más de 4GB de RAM de manera directa. Cuando el procesador es de 32 bits si bien se puede tener más de 4Gb, cada programa tiene acceso a un máximo de 4GB por vez.
#40#39: podrías dar algún ejemplo? Porque en mi caso lo primero que probé fue mplayer y mencoder y era considerablemente más LENTO en 64 bits. Después investigué un poco y todas las comparaciones de velocidades que encontré indicaban diferencias mínimas y no necesariamente a favor de la versión de 64 bits. Tal vez algún programa en particular presente ventajas pero difícilmente justifica los inconvenientes que suelen plantearse (aunque cada vez son menos).
#41¿Que tal van linux (me da igual la distro) con 64 bits? ¿se nota mucha diferencia con respecto a los 32, o va mas o menos igual? Ya que por lo que he leido la ponen bastante mal, incluidos los ultimos comentarios.
Pregunto porque la verdad no lo he probado (problemas para encontrar drivers y programas de 64 bits, mas que nada).
#42La ventaja de usar la arquitectura de 64 bits, a parte de poder direccionar más memoria, es el mayor número de registros de propósito general disponibles, que era un problema grave en x86-32.
Pero de hecho la mejora más importante no ha sido la introducción de los 64 bits, sino los sets de instrucciones paralelos al set del x86 que han ido saliendo a lo largo de los años desde el Pentium, es decir MMX, 3DNow! y SSE (128 bits) con todas sus variantes, que están hechos para cálculos complejos. Y de paso, también alivian en parte la falta de registros generales.
Y eso en sí no tiene nada que ver con los 64 bits.
El problema es que para sacarle partido tanto a una cosa como a la otra, se necesita que el compilador genere código específico y sobretodo que lo haga bien, y no es nada fácil. O eso o que los programas incorporen código en ensamblador ya programado a mano en esos sets de instrucciones, cosa que ya ocurre con los programas o librerías que lo necesitan, básicamente de audio/video.
La realidad es que en la práctica para la mayoría de programas se nota muy poco. El problema es que seguimos arrastrando la arquitectura x86, en parte por Windows y ahora también en parte porque Apple finalmente se bajó los pantalones.
#43#36 El esfuerzo será todo lo tremendo que quieras, pero antes no podías tirar de especificaciones porque Adobe te podía demandar si las usabas sin su permiso, al menos ahora te las da.
Y no compares eso con el OOXML porque puede o no ser lo mismo, el tema es si Adobe lo hará bien o no, si Microsoft lo ha hecho mal no quiere decir que los demás lo vayan a hacer igual, al fin y al cabo existen cientos de especificaciones implementadas en montones de lugares que se lo han tenido que currar, desde protocolos como TCP/IP, lenguajes como HTML, compiladores para C++, maquinas viruales como la de Java, ...,tanto de código abierto como cerrado, algunos más simples que Flash y otros más complejos, unos con especificaciones, pero que funcionan y evolucionan día a día.
Lo que hay que saber es si Adobe hará bien ese trabajo, por ejemplo dando las especificaciones durante el desarrollo para que otros grupos puedan mantener el ritmo y no solo cuando ya estén cerradas y su reproductor en la calle. Así que por ahora juzgar un proyecto que acaba de empezar me parece apresurado. De momento es bueno y como mínimo los desarrolladores de reproductores alternativos se ahorrarán la ingeniería inversa que sí que es muy costosa en tiempo.
#45#44 La verdad es que da lo mismo, si usas una distro de 64 bits y te va bien, perfecto, si no, no te comas la cabeza...
#43 A ver, de acuerdo, al menos no hay que ir descifrando binarios y el OOXML es seguramente mucho más grande y complicado, pero Flash no deja de ser un problema para el desarrollo de la web. Todos los estándares como TCP/IP, C++ y compañía o llevan abiertos toda la vida, o son lo suficientemente pequeños como para que "cualquiera" los implemente, o son lenguajes de programación lo suficientemente importantes como para que sea necesario que alguien haga una implementación libre.
Flash debe liberarse, porque por mucho que Gnash funcionara perfecto, no tienes herramientas libres para crear animaciones en ese lenguaje, Adobe no las sacará probablemente nunca, y nos quedaremos en una situación de "play only" que no nos conviene.
Si Adobe liberara por completo Flash, ya sería otra cosa. De momento es un problema. Hoy tienes plugin, mañana no lo tienes, hoy te cambio la especificación, mañana me espero para que te de tiempo a implementar tu plugin... o no.
Nadie te garantiza nada.
Por eso digo que al menos para el tema de los vídeos es muy necesario que los desarrolladores de navegadores se pongan de acuerdo con SVG + JavaScript. Por eso está el tema calentito con HTML 5.
Aunque precisamente por fin he conseguido que nspluginwrapper funcione como debe...
meneame.net/story/peticion-adobe-para-dar-soporte-flashshockwave-64-bix
Una petición online cumplida :D
Mira, un problema menos
Por cierto que ahora que lo pienso, aún estoy con la RC 2 de flash 10, pero bueno ya que me va bien voy a aplicar aquello de " si funciona no lo arregles " para no actualizarlo, al menos por ahora.
Muy buena noticia!!
Que se hubiesen espabilado en su día, que seguir usando sistemas a 32 bits es un poco lamentable.
Para el que no lo sepa, y quiera probarlo, solo tiene que copiar el .so a /usr/lib/mozilla/plugins
Lo que hace falta es que el plugin de flash sea libre, un binario está bien, pero es un parche.
Me da a mi que el flash tiene que ser internamente una chapuza de escandalo, por los problemas que estan teniendo para portarlo a linux(y cualquier otra cosa distinta de windows) y a 64 bits.
Hay que joderse, años y años con la guerra de navegadores, el intentar que se respeten los estándares, y ahora que por fin nos empezamos a librar poco a poco de la dependencia de IE, que tenemos Firefox, Opera, el motor WebKit, etc. resulta que una sola empresa tiene toda la web cogida literalmente por los huevos con el puto flash.
No me extraña que Gnash sea el proyecto de máxima prioridad de la FSF...
No nos engañemos, ni Gnash ni sfwdec ni ningún proyecto estará nunca a la altura del plugin oficial.
Adobe compró Macromedia y ahí la jodimos, porque ellos mismos se han encargado de frenar SVG todo lo posible, que es el único estándar abierto que algún día y con JavaScript podría competir cara a cara con Flash.
En Opera, por ejemplo ya se hicieron demostraciones de vídeos embebidos en páginas web usando SVG, ya veremos qué pasa al final con HTML 5. Si al menos se pudiera evitar tener que usar Flash para ver vídeos sería un enorme paso.
es.youtube.com/watch?v=e_Pe9AgkO3Q
en.wikipedia.org/wiki/HTML_5
Sé que había un proyecto que se cargó Carla Bruni. Seguiremos dependiendo de Adobe hasta que tengamos una herramienta de creación libre.
Pregunto porque la verdad no lo he probado (problemas para encontrar drivers y programas de 64 bits, mas que nada).
Pero de hecho la mejora más importante no ha sido la introducción de los 64 bits, sino los sets de instrucciones paralelos al set del x86 que han ido saliendo a lo largo de los años desde el Pentium, es decir MMX, 3DNow! y SSE (128 bits) con todas sus variantes, que están hechos para cálculos complejos. Y de paso, también alivian en parte la falta de registros generales.
Y eso en sí no tiene nada que ver con los 64 bits.
El problema es que para sacarle partido tanto a una cosa como a la otra, se necesita que el compilador genere código específico y sobretodo que lo haga bien, y no es nada fácil. O eso o que los programas incorporen código en ensamblador ya programado a mano en esos sets de instrucciones, cosa que ya ocurre con los programas o librerías que lo necesitan, básicamente de audio/video.
La realidad es que en la práctica para la mayoría de programas se nota muy poco. El problema es que seguimos arrastrando la arquitectura x86, en parte por Windows y ahora también en parte porque Apple finalmente se bajó los pantalones.
Y no compares eso con el OOXML porque puede o no ser lo mismo, el tema es si Adobe lo hará bien o no, si Microsoft lo ha hecho mal no quiere decir que los demás lo vayan a hacer igual, al fin y al cabo existen cientos de especificaciones implementadas en montones de lugares que se lo han tenido que currar, desde protocolos como TCP/IP, lenguajes como HTML, compiladores para C++, maquinas viruales como la de Java, ...,tanto de código abierto como cerrado, algunos más simples que Flash y otros más complejos, unos con especificaciones, pero que funcionan y evolucionan día a día.
Lo que hay que saber es si Adobe hará bien ese trabajo, por ejemplo dando las especificaciones durante el desarrollo para que otros grupos puedan mantener el ritmo y no solo cuando ya estén cerradas y su reproductor en la calle. Así que por ahora juzgar un proyecto que acaba de empezar me parece apresurado. De momento es bueno y como mínimo los desarrolladores de reproductores alternativos se ahorrarán la ingeniería inversa que sí que es muy costosa en tiempo.
Entonces, hoy por hoy, y dado los quebraderos de cabeza que da, realmente no merece la pena pasarse a 64 bits,¿ no?
#43 A ver, de acuerdo, al menos no hay que ir descifrando binarios y el OOXML es seguramente mucho más grande y complicado, pero Flash no deja de ser un problema para el desarrollo de la web. Todos los estándares como TCP/IP, C++ y compañía o llevan abiertos toda la vida, o son lo suficientemente pequeños como para que "cualquiera" los implemente, o son lenguajes de programación lo suficientemente importantes como para que sea necesario que alguien haga una implementación libre.
Flash debe liberarse, porque por mucho que Gnash funcionara perfecto, no tienes herramientas libres para crear animaciones en ese lenguaje, Adobe no las sacará probablemente nunca, y nos quedaremos en una situación de "play only" que no nos conviene.
Si Adobe liberara por completo Flash, ya sería otra cosa. De momento es un problema. Hoy tienes plugin, mañana no lo tienes, hoy te cambio la especificación, mañana me espero para que te de tiempo a implementar tu plugin... o no.
Nadie te garantiza nada.
Por eso digo que al menos para el tema de los vídeos es muy necesario que los desarrolladores de navegadores se pongan de acuerdo con SVG + JavaScript. Por eso está el tema calentito con HTML 5.