Es una noticia buena para los usuarios de Linux AMD64 después de tanto tiempo pidiéndolo, porque el plugin de Flash es vital para nuestros sistemas de escritorio si queremos tener una experiencia completa en el uso de la web hoy en día. Su alternativa abierta, el Gnash, aún no está preparado para reemplazarlo completamente. La única opción que teníamos era usar el plugin de 32 bits con el nspluginwrapper (Sobre el plugin de Flash en Firefox/Iceweasel en Debian AMD64: El nspluginwrapper aceptado en Testing), una opción que, aunque nos saca del apuro, es muy inestable y nos obligaba muy a menudo a reiniciar el navegador porque el plugin de Flash dejaba de funcionar.

Es una noticia muy mala para los usuarios de Linux porque es lamentable que en nuestro sistema, que nos gustaría ver libre de todo el software propietario, tengamos que pasar por el aro de dos cosas: del dichoso plugin de Flash y de los drivers cerrados. No es casualidad que a menudo sean componentes de software de nuestros sistemas que desearíamos que fueran algo más estables. Es muy desafortunado que tengamos que depender de que los señores de Adobe sean magnánimos con los pobres bichos raros que usan Linux de 64 bits para poder usar lo que todo el mundo usa, Internet.

Y por supuesto, también es lamentable que diseños web que se podrían hacer de forma perfectamente estándar y llamativa con un poco de CSS, HTML y JavaScript, acaben siendo pasto del todopoderoso y monopolístico Flash para desesperación de aquello que llamamos accesibilidad. El uso de Flash para reproducir vídeos en la web es razonable, aunque sería mucho más deseable que se usara cualquiera de los formatos de vídeo abiertos disponibles. Donde sí tiene perfecta cabida, hay que reconocerlo, es en el campo de las animaciones, como los juegos online o los típicos esquemas interactivos que a menudo nos presentan los periódicos en su edición digital.

Bueno, yo he probado hoy esta nueva versión del plugin en mi Ubuntu 8.10 y he de decir que funciona. No lo he probado intensivamente, pero funciona bien con algún juego (¿habéis probado el Play 99 Bricks?) y con Youtube, Metacafe y ZappInternet. Sin embargo, me da la sensación de que usa muchísima CPU.

Para instalarlo, he desinstalado el paquete flashplugin-nonfree:

 $ sudo dpkg -P flashplugin-nonfree
(Reading database ... 134935 files and directories currently installed.)
Removing flashplugin-nonfree ...
Purging configuration files for flashplugin-nonfree ...

y he hecho un autoremove para que elimine el nspluginwrapper también:

$ sudo apt-get autoremove
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages were automatically installed and are no longer required:
  nspluginwrapper
The following packages will be REMOVED:
  nspluginwrapper
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 483kB disk space will be freed.
Do you want to continue [Y/n]? 
(Reading database ... 134928 files and directories currently installed.)
Removing nspluginwrapper ...
Processing triggers for man-db ...

Finalmente, he descargado el fichero libflashplayer-10.0.d20.7.linux-x86_64.so.tar.gz libflashplayer-10.0.d21.1.linux-x86_64.so.tar.gz y lo he descomprimido en el directorio ~/.mozilla/plugins. Sólo contiene una librería:

~ $ wget http://download.macromedia.com/pub/labs/flashplayer10/libflashplayer-10.0.d21.1.linux-x86_64.so.tar.gz

~ $ cd .mozilla/plugins/

~/.mozilla/plugins $ tar xvf ~/libflashplayer-10.0.d20.7.linux-x86_64.so.tar.gz
libflashplayer.so

Tras reiniciar el navegador, en el about:plugins ya veremos:

Shockwave Flash

File name: libflashplayer.so
Shockwave Flash 10.0 d20

Para instalar el plugin para todos los usuarios del sistema, habría que copiar la nueva librería en /usr/lib/mozilla/plugins/.

En fin, que la noticia deja un sabor muy agridulce. Es como cuando el driver de NVidia va mal y la actualización del driver cerrado arregla el problema. Se agradece la actualización, pero ésta no mitiga la impotencia que da depender de la voluntad que tenga una empresa para arreglar fallos o no hacerlo.

Actualización 20/11/08: The Inquirer: Instalación y rendimiento Adobe Flash 64bits en Linux

:wq

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 14 comentarios
Etiquetas: AMD64, drivers abiertos, Firefox, Flash, GNU/Linux, Ubuntu

Entradas relacionadas

• Sobre el plugin de Flash en Firefox/Iceweasel en Debian AMD64: El nspluginwrapper aceptado en Testing (3)
• Web Fonts, fuentes descargables para la web (2)
• vga=ask y los modos VESA disponibles en el sistema (2)
• Ubuntu y Debian eliminan ms-sys de sus repositorios (2)
• sysstat, la colección de herramientas de monitorización de rendimiento (2)
• Notas sobre la función wptexturize de WordPress, sobre los navegadores que convierten el código HTML a UTF-8 y sobre Unicode/UTF-8 (2)

Feed enhanced by Better Feed from Ozh

Así, a menudo he tratado de divulgar el problema que existe con los drivers para los chipsets gráficos de VIA, tanto aquí:

• Sobre las VIA EPIA (VI): Gráficos y vídeo acelerado por HW en Linux con la EX10000EG
• Petición para que VIA tome una postura clara respecto a Linux
• VIA anuncia una iniciativa para mejorar los drivers de Linux (con un par de actualizaciones)

como en Barrapunto:

• Petición para que VIA cree drivers decentes para Linux
• Petición a VIA para que cree drivers decentes de Linux (II)
• Petición a VIA para que cree drivers decentes de Linux (III)
• Petición para que VIA cree drivers decentes para Linux
• VIA anuncia una iniciativa para mejorar los drivers libres para Linux
• VIA publica un driver abierto para Xorg

Y es que existe una necesidad de que VIA facilite (creándolo directamente o ofreciendo la documentación adecuada) un driver abierto y de buena calidad para Linux. Es algo que nos beneficia mucho a nosotros, los usuarios, pero aún más a la propia VIA. ¿Alguien piensa que los modestos procesadores y chipsets de VIA pueden tener algún futuro con un Windows Vista que va a pedales en sistemas de última generación? Evidentemente, no. Su nicho de mercado estrella es el de sistemas enfocados a ser usados con aplicaciones de Internet de bajo consumo, como es el caso de los miniportátiles o nettops.

VIA necesita que su hardware funcione bien en Linux más incluso que nosotros los usuarios. Pensemos en cuáles son los miniportátiles más conocidos que hay en el mercado en el momento de escribir estas líneas: Está el Asus EEE, con procesador de Intel (Celeron o Atom), el Acer Aspire One, también con Intel Atom y el HP Mini Note 2133, el único con hardware de VIA. Todos ellos ofrecen la opción de usar Linux en ellos, como no podía ser de otra forma si queremos hacer un uso eficiente de nuestro “débil” hardware. ¿Es posible que VIA rasque algo en este mercado sin sacar drivers decentes?

Cuando en Enero promovimos la petición online para que VIA creara o facilitara drivers decentes, yo creo sinceramente que sí que conseguimos algo: no que VIA por fin diera su brazo a torcer y lo que antes era un no rotundo pasara a ser un si en letras gigantes. Nuestro logro fue, posiblemente, conseguir que esos directivos de VIA encorbatados y que probablemente nunca habían visto otra cosa que no fuera Windows se dieran cuenta de que algo iba realmente mal en su colaboración con la comunidad de Linux que tan necesaria les iba a resultar en los próximos meses.

Colaborar con la comunidad de software libre no es exactamente lo que ha hecho VIA de crear el sitio http://linux.via.com.tw/ y decir: ¡Ea! ¡Ahí tenéis los drivers que queríais! ¡Pesados! No, eso ya lo teníamos peor o mejor en viaarena.com. Colaborar con la comunidad es enviar parches a los desarrolladores del kernel, mantenerlos, colaborar con los chicos de openChrome para mejorar lo existente, o al menos crear documentación útil. En cualquier caso, podemos consolarnos con que menos es nada.

Cuando en Julio VIA anunció el fichaje de Harald Welte muchos pudimos hacernos ilusiones de que el panorama podía cambiar y que podríamos encontrarnos con una colaboración honesta con la comunidad.

Sin embargo, pese a la aparente voluntad de VIA de cambiar las cosas con este movimiento, parece que nos vamos a encontrar con un escollo mucho más grande que ha estado persiguiendo al software abierto desde hace años: las patentes.

(...)

Leer el resto de ¿Tendremos algún día un driver abierto de VIA completo? (1,533 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 5 comentarios
Etiquetas: drivers, drivers abiertos, GNU/Linux, openChrome, VIA, VIA EPIA

Entradas relacionadas

• VIA anuncia una iniciativa para mejorar los drivers de Linux (5)
• Sobre las VIA EPIA (VI): Gráficos y vídeo acelerado por HW en Linux con la EX10000EG (4)
• Sobre las VIA EPIA (III): Linux en una SP8000E (4)
• Petición para que VIA tome una postura clara respecto a Linux (4)
• Sobre las VIA EPIA (V): La EPIA EX10000EG en Linux (3)
• Ya tenemos un plugin de Flash nativo para Linux de 64 bits (2)

Feed enhanced by Better Feed from Ozh

En la página de las distribuciones que han obtenido la certificación de alguna versión LSB aparecen, cómo no, las más comerciales: las Red Hat, SUSE o Madriva así como la OpenSUSE 10.2. No aparece ninguna Debian y de Ubuntu sólo sale la 6.06, aunque no es algo que sus desarrolladores ignoren, ya que tenemos la página Debian and the Linux Standard Base, en la página de LSB Distribution Status aparece como planned y además hay varios paquetes encaminados a conseguir la compatibilidad con la LSB:

$ apt-cache search lsb
alien - install non-native packages with dpkg
insserv - Reorder boot sequence based on LSB init.d script dependencies
lsb - Linux Standard Base 3.1 support package
lsb-appchk2 - LSB v2.x Application checking tool
lsb-appchk3 - LSB v3.x Application checking tool
lsb-base - Linux Standard Base 3.1 init script functionality
lsb-build-base2 - LSB v2.x Development tools base package
lsb-build-base3 - LSB v3.x Development tools base package
lsb-build-cc2 - LSB v2.x Development environment lsbcc package
lsb-build-cc3 - LSB v3.x Development environment lsbcc package
lsb-build-desktop3 - LSB v3.x Development tools desktop package
lsb-core - Linux Standard Base 3.1 core support package
lsb-cxx - Linux Standard Base 3.1 C++ support package
lsb-desktop - Linux Standard Base 3.1 Desktop support package
lsb-graphics - Linux Standard Base 3.1 graphics support package
lsb-pkgchk3 - LSB v3.x package checking tool
lsb-qt4 - Linux Standard Base 3.1 Qt4 support package
lsb-release - Linux Standard Base version reporting utility
lsb-rpm - Red Hat package manager for LSB package building

La LSB es incluso un estándar ISO desde 2005 (ISO/IEC 23360), aunque no está extenta de polémica, ya que hay quien piensa que esto de la LSB es un negociete que se han montado cuatro que viven de hacer estándares para viajar y ganar buenos sueldos a costa de las distribuciones importantes, ya que en realidad los tests destinados a certificar no son los más adecuados (Linux Standard Base approved as international standard, Do you still think the LSB has some value?).

Bueno, sea como sea, el asunto es que un subconjunto de la LSB es el Filesystem Hierarchy Standard. Mientras que la LSB es un mamotreto ilegible, la FHS es un documento de apenas 52 páginas muy conciso, útil y casi de imprescindible consulta para cualquiera que quiera meterse de verdad en el mundo Linux y quiera enterarse bien de cosas como por qué hay ficheros que se guardan en /usr/bin/, y no en /sbin/ o en /usr/share/, /usr/sbin/ o /usr/local/bin/. El FHS es la base del capítulo 16 del documento “core” de la LSB y lo podemos descargar suelto de The home of the Filesystem Hierarchy Standard (FHS).

(...)

Leer el resto de La Linux Standard Base está hecha… ¡en Windows! (462 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 22 comentarios
Etiquetas: DocBook, FHS, GNU/Linux, LSB, Windows, WTF

Entradas relacionadas

• Wake on LAN (2)
• VPN con OpenSSH (2)
• Usando ntfsclone y dd para clonado por red con netcat (2)
• SMB connection failed: Insufficient server memory to perform the requested function. (2)
• Samba/CIFS: Enlaces simbólicos y Unix CIFS Extensions (2)
• rsync siempre sincroniza ciertos ficheros. Ver los segundos de la fecha de un fichero. (2)

Feed enhanced by Better Feed from Ozh

El tema es el siguiente: Si programamos una aplicación de las convencionales y la distribuimos bajo los términos de la GPL (sea la v2 o la v3), tenemos que facilitar el código fuente a todos aquellos a los que les proporcionemos binarios de la aplicación. Pero si modificamos código GPL sólo para usarlo nosotros (o en el ámbito de nuestra empresa, por ejemplo), no necesitamos ponerlo a disposición de quien nos lo pida:

Does the GPL require that source code of modified versions be posted to the public?

The GPL does not require you to release your modified version, or any part of it. You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization.

But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program’s users, under the GPL.

Thus, the GPL gives permission to release the modified program in certain ways, and not in other ways; but the decision of whether to release it is up to you.

Pongamos un ejemplo. Imaginemos que modifico el código de Linux, MySQL o bash que son GPL, pero que esas modificaciones sólo las uso yo o en el ámbito de mi empresa. En ese caso, no tengo obligación de proporcionarle dichos cambios a nadie. Pero ahora imaginemos que alguien se entera de mis cambios y está interesado en ellos, tal vez incluso ofreciendo una remuneración y nosotros nos avenimos a ello. En tal caso, no podemos proporcionarle sólo los binarios, sino que también tendremos que proporcionarle el código fuente con las modificaciones y además, esa persona podrá distribuir el código modificado a quien quiera, incluso gratis aunque nosotros sí que le hayamos cobrado. Recordemos que no hay ningún problema en vender software licenciado bajo la GPL, lo único es que no podemos esperar que si esa persona se lo distribuye a otras, esas otras también nos paguen:

(...)

Leer el resto de La licencia Affero (AGPL) y su relación con la GPL (2,174 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 10 comentarios
Etiquetas: Affero, CMS, GPL, licencias, WordPress

Entradas relacionadas

• WordPress y el cambio de hora (1)
• Servir con Apache imágenes con marca de agua (watermark) (1)
• Recuperar una entrada perdida de WordPress. MySQL Point-in-Time recovery: mysqlbinlog. (1)
• Primer aniversario del blog (1)
• OpenID en WordPress.org y cómo usar WordPress.com como proveedor de identidad (1)
• Notas sobre la función wptexturize de WordPress, sobre los navegadores que convierten el código HTML a UTF-8 y sobre Unicode/UTF-8 (1)

Feed enhanced by Better Feed from Ozh

Siendo el caso del Epson Perfection 2480 uno de los casos más fáciles que podemos encontrar para configurar un dispositivo hardware que no esté directamente soportado por el kernel, nos toca reconocer que a Linux aún le queda un buen camino que recorrer en el área del reconocimiento automático del hardware, algo que sin el apoyo real de los fabricantes nunca será posible del todo. Este dispositivo está bien soportado en Linux, pero como el firmware es cerrado, no puede ser incluido en distribuciones que tengan un mínimo reparo a las licencias del software que incluyen.

En la época de Windows 95 anterior a la llegada del 98 teníamos otro escáner, un Mustek Paragon 6000p de puerto paralelo. Estábamos contentos con aquel escáner, aunque como el 486 no tenía EPP/ECP, la velocidad de transmisión de imágenes al PC era lamentable. Pero bueno, el caso es que cuando salió Windows 98, Mustek no sacó drivers para este nuevo sistema operativo. Incluso hoy en día, si vamos a la página de drivers del 600 III EP Plus (¡el 6000p no está!) vemos que sólo hay drivers para Windows 95. ¿Qué pasó? Pues que si migraba no tenía escáner. Ahí me di cuenta de que si el escáner estaba soportado en Linux con un driver abierto (sí que lo está, aunque no sé desde cuándo), jamás me tendría que preocupar en adelante porque un dispositivo hardware dejara de estar soportado. Desafortunadamente, aquel escáner tuvo una muerte temprana, pero si aún estuviera funcionando, yo, en 2007, más de 10 años más tarde, podría poneros capturas obtenidas con él con mi Debian, pero desde luego no podría hacer lo mismo con Windows XP ni con Vista.

Estos problemas le ocurrieron a mucha gente cuando Windows 98 no aceptaba los drivers de Windows 95 y el fabricante no hacía drivers para dispositivos de un año o dos de antiguedad para Windows 98. Volvió a ocurrir cuando muchos dispositivos quedaron en la cuneta en el paso a Windows 2000. Ahora, como los drivers de Windows 2000 sirven para Windows XP, llevamos mucho tiempo sin vivir estos problemas y se nos habían olvidado, pero con la salida de Vista, de nuevo está ocurriendo que ante la ausencia de drivers para Vista, muchos tienen que elegir entre su hardware o Vista (que yo lo tendría claro, pero en fin, para gustos están los colores).

Es el paraíso de los fabricantes. No me extrañaría que desearan con todas sus fuerzas que con cada nueva versión Microsoft cambiara el formato de sus drivers para que todos los usuarios tiraran a la basura sus dispositivos totalmente funcionales y compraran nuevos compatibles con el nuevo Windows Tuerto de turno.

Y es que comprar hardware para el que exista un driver en Linux te garantiza que tu hardware morirá cuando tú quieras, no cuando quiera el fabricante dejar de soportar el dispositivo porque con dos años ya está obsoleto.

Pero no sólo eso: Hay esforzadísimos programadores de drivers de Linux que se lo curran muchísimo para, contra el viento y la marea de los fabricantes que no proporcionan las especificaciones de sus dispositivos, crear drivers usando ingeniería inversa de los drivers de Windows. Su labor es altamente loable, pero no hemos de conformarmos con eso. Un driver obtenido por ingeniería inversa normalmente será de peor calidad que uno hecho a partir de las especificaciones. Así que, como dicen los americanos, tenemos que votar con nuestros euros y favorecer a los fabricantes que proporcionan las especificaciones de su hardware o, incluso mejor, que favorecen e impulsan la creación de drivers abiertos.

El poder está en nuestras manos si lo usamos bien. Si te vas a comprar una tarjeta WiFi fíjate en que Ralink hace un esfuerzo grande para que tengamos buenos drivers para sus chips, fíjate en que Intel proporciona los mejores drivers abiertos de procesadores gráficos de hoy en día, fíjate en que con la ayuda para hacer drivers para Linux que proporciona VIA a los desarrolladores y los que ella misma distribuye, las placas VIA EPIA van mejor en Linux que en Windows…

…y fíjate en que si ahora mismo NVidia y ATI cerraran sus puertas, nos quedaríamos con tarjetas gráficas compradas por entre 100 y 600€ que en pocos meses no servirían para nada que no fuera 2D.

Por tanto, por favor, antes de comprar cualquier hardware nuevo, comprueba previamente si está soportado en Linux. Estarás favoreciendo a los fabricantes que colaboran con la comunidad de código abierto, estarás perjudicando a los que no lo hacen y, sobre todo, saldrás ganando tú. Es posible que no uses Linux ni quieras usarlo en el futuro, pero haciéndolo así sabes que dentro de 10 años, si quieres volver a usar ese dispositivo que tienes en el armario, podrás hacerlo, aunque tenga que ser con Linux.

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 12 comentarios
Etiquetas: drivers, GNU/Linux, Windows

Entradas relacionadas

• Wake on LAN (2)
• VPN con OpenSSH (2)
• Usando ntfsclone y dd para clonado por red con netcat (2)
• SMB connection failed: Insufficient server memory to perform the requested function. (2)
• Samba/CIFS: Enlaces simbólicos y Unix CIFS Extensions (2)
• rsync siempre sincroniza ciertos ficheros. Ver los segundos de la fecha de un fichero. (2)

Feed enhanced by Better Feed from Ozh

Linux is about choice: Linux va de poder elegir libremente entre múltiples alternativas para hacer lo mismo… Necesitas un servidor de correo y tienes el sendmail, el qmail, el exim,…, necesitas un editor de textos y tienes el vi, el emacs, el joe, el nano,…, necesitas un escritorio y tienes GNOME, KDE, Xfce,…, necesitas una distribución de Linux y tienes Fedora, Suse, Debian, Ubuntu, Gentoo…. Aunque tanta posibilidad de elección es lo maravilloso del software libre para muchos, para otros muchos, es lo malo, ya que la diversidad genera dispersión de usuarios y que se reduzca el know-how de determinadas aplicaciones.

No es fácil decir si de la diversidad nacen los flames (como Red Hat vs Suse, Debian vs Ubuntu vs Gentoo, KDE vs GNOME, vi vs emacs, Linux vs ***BSD) porque los usuarios de un producto realmente quieren que los usuarios del contrario se pasen a usar el suyo o para demostrar su superioridad ante los que usan el otro o por qué, pero ciertamente, aparecer, aparecen… Y realmente, parece que está demostrado que no es posible convencer a nadie en este tipo de discusiones.

Dicho esto, yo tenía curiosidad por saber qué distribuciones y escritorios usaban los famosos de este mundillo… no por generar nuevas discusiones, sino pura curiosadad por saberlo y por ver si podía encontrarlo buceando por Internet. Ha sido muy difícil en la mayoría de los casos y los resultados no son siempre ni lo satisfactorios, ni lo recientes, ni lo exactos que desearía, pero en cualquier caso, aquí están, con las fuentes de la información incluidas en los enlaces…

(...)

Leer el resto de ¿Qué distribución/escritorio prefieren 10 protagonistas del Software Libre? (1,835 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 37 comentarios
Etiquetas: Alan Cox, Andrew Tridgell, distribuciones, Donald Knuth, escritorios, Ian Murdock, Keith Packard, Linus Torvalds, Miguel de Icaza, Richard Stallman, Theo de Raadt

Entradas relacionadas

• Los DPI en pantalla en Windows y Linux (1)

Feed enhanced by Better Feed from Ozh