1. Descarga el driver para Linux.
2. Arranca el instalador, pero no continúes. Esto descomprimirá los ficheros del instalador en el directorio actual. El instalador utilizado en su caso es el ati-driver-installer-9-10-x86.x86_64.run .
3. Abre un nuevo terminal, cambia al directorio en el que han sido extraídos los ficheros, el cual tendrá un nombre similar a fglrx-install.08df92 .
4. Ahora aplica los siguientes cambios al fichero firegl_public.c .

   En la línea ~1028 de:

     for (i = 0; i < __KE_MAX_SPINLOCKS; i++)
   		  dev->spinlock[i] = SPIN_LOCK_UNLOCKED;
       

   a:

     for (i = 0; i < __KE_MAX_SPINLOCKS; i++)
   		  DEFINE_SPINLOCK( dev->spinlock[i] );
       

   Y en la línea ~5001 de:

     init_MUTEX(&(mutex_obj->mutex));
     

   a:

     semaphore_init( &(mutex_obj->mutex) );
     

5. Vuelve al terminal del instalador, continúa y finaliza la instalación.

Captura de William Hook.

Entre los cambios «se actualiza el kernel estándar a la versión 2.6.31.5, más el update para Btrfs de la versión 2.6.32; se actualiza también el kernel alternativo a la versión 2.6.27.38; se actualiza DMRAID a 1.0.0-rc16 y mdadm a 3.0.2 —hardware y software RAID—; se actualiza LVM a 2.02.51 —la versión 2 del Gestor de Volúmenes Lógicos—; se actualiza xorg-server a la versión 1.6.3.901 —tanto el servidor como los drivers—; se reemplaza el framebuffer de Xvesafb a Xfbdev —ejecuta wizard para utilizar este modo gráfico—; se actualiza GParted a la versión 0.4.8 y se añade Super Grub Disk 1.21 —el cual incluye GRUB 1.96—.

Descarga la imagen ISO de SystemRescueCD —238 MB, MD5—.

Foto de Mr.Thomas.

Lo cuenta en su blog. Para quienes no tienen problema alguno con la forma de trabajar actual, avisa de que esta característica será opcional. La idea es que la ventana pueda contener los puertos para cada una de las imágenes que están siendo editadas, e incluso que varias de ellas puedan ser mostradas al mismo tiempo, gentileza de Michael Natterer. Queda avisado también que queda aún trabajo por hacer.

El pantallazo proporcionado por Martin, desde luego, ayuda a ir poniéndote los dientes largos.

Visto en gimpusers.com.

El desarrollador web: «Está subiendo».
El administrador de sistemas: «Está reiniciando».
El hacker: «Lo hace un script».
El artista 3D: «Está renderizando».
El consultor IT: «Es tu problema».
El programador: «Está compilando».

¿El linuxero?

¿Deberías actualizar ya? La pregunta puede desde luego ser hecha de muchas formas. ¿Estabas contento con la estabilidad de tu sistema actual? ¿Aprecias realmente estar manejando un sistema lo que viene a decirse «en producción»? ¿Cómo de excitante te resulta trabajar al filo de la navaja, y a qué estás dispuesto a renunciar a cambio?

No creas nada de lo que te dicen acerca de que una actualización como ésta se lleva a cabo fácilmente y sin dolor de cabeza alguno. Si la estabilidad de tu sistema es importante para ti, no dudo en recomendarte esperar dos o tres semanas hasta que todas las posibles cuestiones problemáticas derivadas de la actualización estén lo suficientemente bien documentadas.

Si te atreves a dar el salto, simplemente pulsa Alt+F2 y ejecuta:

  update-manager -d
  

Y sigue ahora todas las instrucciones en pantalla. Con una conexión ADSL de una velocidad razonable en dos horas ya deberías haber terminado. Ah, por supuesto, si utilizas un Ubuntu personalizado como mi Ubuntu Studio, los pasos son exactamente los mismos.

¿Con qué problemas puedes encontrarte? En mi caso han sido éstos:

• El kernel 2.6.31 no arranca —en mi caso, dado que corro Ubuntu Studio, la versión rt de ese kernel—. Se presenta durante el arranque este mensaje de error.

    udevadm trigger is not permitted while udev is unconfigured
    

  Si se presenta este problema es porque no han sido creadas las imágenes initramfs para los nuevos kernel instalados. Ejecuta:

  $ sudo update-initramfs -u -k all
  

• No es posible activar los efectos de escritorio. Resulta en mi caso que en la nueva versión de las Xorg el módulo radeon no detecta que el módulo agpgart está cargado y de ahí que no active las DRI. Queda patente por un rendimiento penoso de las glxgears. Si buscas en Google posibles soluciones a este problema, se recomiendan distintas configuraciones a ser aplicadas al fichero de configuración en /etc/X11/xorg.conf. El pequeño inconveniente es que en Karmic Koala, ¡este fichero ha desaparecido! Xorg detecta perfectamente la configuración gráfica a ser aplicada sin necesidad del mismo, aunque sí lo utiliza si existe. Para solucionar mi problema sólo tengo que crear un nuevo xorg.conf así:

    $ sudo Xorg -configure
    

  Entrando en el sistema desde una consola y deteniendo gdm primero. La llamada crea un xorg.conf.new en tu directorio actual. Y ahora añadiendo esta línea a la sección Device.

    	Option "BusType" "PCI"
    

  Que arranquen las X y se detecte el bus AGP no quiere por supuesto decir que mientras escribo esto, por ejemplo, DRI esté activo. Menos mal que para la práctica mayoría de las cosas para las que uso este ordenador, la aceleración no es necesaria. Ya veremos cuando abra Audacity…

• El gestor de entrada al sistema gdm ya no está, ya no existe, ha sido cambiado por xsplash. El arranque del sistema es desde luego más rápido, pero el nuevo gestor de entrada es realmente pobre de aspecto. No estoy hablando aquí de un problema, más bien sólo de un susto. Pero tendrás que acostumbrarte.

¿Has actualizado? ¿A ti cómo te ha ido?

Capura de Kage Tora

Un primer consejo es, desde luego, desactivar las extensiones mientras no las estás necesitando. Firebug, por ejemplo, es, desde luego, una aplicación killer para desarrolladores web que hace imprescindible a Firefox. Pero ralentiza el uso del navegador, y es raro que la necesites más que un par de ocasiones al mes —a no ser, por supuesto, que seas un profesional en el tema—. Lo dicho para Firebug vale para muchas otras extensiones complejas. Yo, por ejemplo, hoy por hoy sólo necesito Google Gears para subir clips a YouTube. El resto del tiempo está desactivada.

Por lo demás hay una serie de parámetros que es posible optimizar, y se listan debajo. Puedes, por supuesto, visitar about:config y configurarlas una por una. O puedes llevar ese código a prefs.js. La sugerencia es, desde luego, llevar esas opciones a un fichero user.js en el directorio de configuración de Firefox, junto al citado prefs.js. El fichero user.js es así portable de máquina en máquina. En mi caso, estas opciones están en todas las máquinas donde uso Firefox.

user_pref("network.http.pipelining", true);
user_pref("network.http.proxy.pipelining", true);
user_pref("network.http.pipelining.maxrequests", 30);
user_pref("nglayout.initialpaint.delay", 0);
user_pref("config.trim_on_minimize", true);
user_pref("browser.cache.memory.capacity", 27648);
user_pref("browser.cache.memory.enable", true);
user_pref("network.prefetch-next", false);
user_pref("network.http.max-connections", 60);
user_pref("network.http.max-connections-per-server", 32);
user_pref("network.http.max-persistent-connections-per-proxy", 16);
user_pref("network.http.max-persistent-connections-per-server", 16);
user_pref("network.dns.disableIPv6", true);
user_pref("content.notify.backoffcount", 5);
user_pref("ui.submenuDelay", 0);
user_pref("plugin.expose_full_path", true);
user_pref("browser.sessionhistory.max_total_viewers", 2);
user_pref("browser.sessionhistory.max_entries", 10);

• El pipelining en las conexiones HTTP 1.1 reduce la carga de red y el tiempo de carga de las páginas sobre conexiones cuando la latencia es demasiado elevada. Teóricamente no todos los servidores lo soportan y podrían comportarse incorrectamente si reciben peticiones de este tipo, de ahí que muchos aconsejen no activarlo. Yo no he encontrado problemas y sí una mejora clara en el rendimiento. 30 es una buena cifra para el máximo número de este tipo de peticiones concurrentes.
• Tiene sentido visualizar la página ya según empieza a ser cargada, de ahí que se elimine cualquier intervalo antes de empezar a hacerlo.
• Mejora también el rendimiento permitir que la aplicación haga swap una vez minimizada. De esta forma se libera memoria que hace más agil el uso de tu sistema operativo.
• Almacenar en una cache imágenes, elementos de interfaz de usuario o páginas seguras acelera el rendimiento. ¡Piensa en la diferencia que supondría tener que decodificar estas últimas cada vez que son cargadas!
• Una opción polémica es la de permitir la precarga de las páginas tras los enlaces que componen una página. Yo voto por liberar a la CPU de la tarea de precargar enlaces que probablemente no van a ser seguidos.
• El ADSL y en general toda banda ancha permite un número mayor de conexiones HTTP concurrentes que las que permitían las conexiones por módem. Aumentar ese valor hoy por hoy mejora el rendimiento en todos los casos.
• Mientras IPv6 no exista, desactivarlo también mejora el rendimiento.
• Posiblemente sea sólo psicológico, pero eliminar el retardo con el que se abren las opciones del menú de la aplicación repercute en la sensación de un mejor rendimiento.
• Por último, es improbable que te interesen páginas más allá de las diez últimas visitadas. Se libera así memoria y mejora el rendimiento de la aplicación y del sistema operativo.

Haz la prueba y deja un comentario. ¿Notas la mejora en el rendimiento? Yo desde luego que sí. ¿Algún truco más?

Ah, el usuario de Ubuntu dispone por supuesto de Firefox tal cual. El usuario de Debian puede aplicar exactamente las mismas opciones en Iceweasel.

Captura de Pentadact.

He aquí que mucha gente prefiere sin embargo la simplicidad de xterm. Son muchos los que corren entornos de escritorio más sencillos como Openbox o Fvwm. Aún utilizando GNOME, hay ocasiones en las que xterm es la opción escogida. Por ejemplo, cuando quieres correr una emulación de terminal con una fuente en un tamaño determinado. Eh, tu cliente IRC de consola con una fuente de ancho fijo te recuerda mucho más a los viejos tiempos de las BBS y los módems a 2.400 baudios.

El problema es que es complicado trasladar información entre el xterm y el resto del escritorio. El clipboard de GNOME es el canal estándar para copiar y pegar información entre las aplicaciones creadas para dicho entorno de escritorio. Pero xterm sigue utilizando el primary. Se trata del viejo buffer estándar de las X. Almacena el texto que resaltas con el ratón y, al pulsar el botón central del mismo, dicho texto se envía a la aplicación resaltada como si estuviese siendo introducido desde el teclado. Éste es el único buffer utilizado por xterm, y no hay forma de comunicar los dos.

Es posible, sin embargo, aunque no esté lo suficientemente documentado, forzar a que las últimas versiones de xterm utilicen el clipboard además del primary. Pruébalo.

$ xterm -xrm 'XTerm*VT100.translations: #override : select-end(PRIMARY, CLIPBOARD, CUT_BUFFER0)'
  

Para que sea válido en cualquiera de las ejecuciones de xterm añade estas líneas a tu fichero Xdefaults.

  ! Support Gnome clipboard
XTerm*VT100.translations: #override : select-end(PRIMARY, CLIPBOARD, CUT_BUFFER0)
  

Ojo. Recuerda que si usas GNOME, ese fichero debe llamarse ~/.Xdefaults-`hostname`.

Captura de pantalla de heipei.

Para todos los que trabajan con Ardour me alegra anunciar el lanzamiento de Ardour 2.8.3. Se trata principalmente de una versión de mantenimiento, pero que incluye al menos tres nuevas características muy interesantes. También un gran número de arreglos, desde la compilación con las últimas versiones del compilador hasta pequeños problemas en la interfaz de usuario o incluso cuelgues ocasionales. Visita http://ardour.org/download como de costumbre para descargar las fuentes o los binarios para OS X.

— Ardour 2.8.3 no incluye ya una versión modificada de libsndfile sino que confía en la versión instalada en el sistema, la cual debe ser al menos la 1.0.18. Asegúrate de que fue compilada con soporte para FLAC y Ogg/Vorbis si quieres que Ardour pueda trabajar con esos formatos. La forma más sencilla de comprobarlo es ejecutar sndfile-info sobre un fichero FLAC u Ogg/Vorbis para comprobar si puede leer su contenido.

— Ardour puede ahora abrir sesiones en las que no puede escribir, por ejemplo, sesiones en medios de sólo lectura o en sistemas de ficheros donde no se dispone de permisos de escritura.

— Facilita medición de la latencia mediante el plugin de inserción basado en jdelay. No es automático, ha de ser iniciado por el usuario en la interfaz correspondiente.

— Facilita también automatización básica de los parámetros On/Off para los plugins. Aún no se permite edición gráfica, así que la solución de momento es un tanto grosera, si bien sólo puede mejorar en el futuro.

— El API OSC soporta ahora el comando locate.

Para una lista completa de características y problemas resueltos visita Ardour.

«Veamos. DRM, Windows Vista, .NET, Kindle Remote Erasing System, ¡Wow! ¡Incluso Google Sidewiki! Su experiencia es impresionante, baje directamente al séptimo infierno. Ha sido usted ascendido. Enhorabuena, amigo.»

Viñeta de The Scientific Cartoonist.

Harrison es líder mundial en fabricación de consolas analógicas y digitales. Presentan ahora Mixbus, una versión a medida de Ardour para OS X.

Mixbus mejora Ardour facilitando funciones críticas de mezclado asociadas a una interfaz física, tecnología que llaman «True Analog Mixing». Se basa en los renombrados diseños de consola de las series 32 y MR de Harrison, y en su tecnología propietaria de mezcla digital. Mixbus permite al usuario grabar, editar y mezclar una actuación musical tal cual sale de la caja, consiguiendo un sonido que nos devuelve a la era dorada de la grabación analógica.

Según Ben Loftis, dirección de producción de Harrison, «la marca no quería lanzar una estación de trabajo convencional para un mercado ya saturado. En su lugar, utilizamos la plataforma libre Ardour como motor de grabación y editado. Ardour lleva aquí casi 10 años y tiene miles de usuarios, es una plataforma consolidada y utilizándola no contribuimos a fragmentar el mercado de las estaciones digitales de trabajo».

La idea original tras Mixbus parte de un plugin de banda de canal de Harrison. Pero tras algo de experimentación resultó obvio que los plugins simples no interaccionan correctamente y no recrean la funcionalidad de una consola. De ahí que las estaciones de trabajo digitales habituales no recuerden a la forma de trabajar con los viejos sistemas analógicos. Después de una intensa fase de experimentación, el diseño se ha transformado en una banda de canal que combina las características de Ardour y las de Harrison.

Para los familiares con el diseño actual de Ardour, Mixbus ha sido implementado como plugin LADSPA de código cerrado que facilita el comportamiento de la banda de canal típica de Harrison. Súmesele un conjunto de grandes pero no intrusivos cambios en el núcleo de Ardour. Todo el código fuente, excepto el correspondiente al plugin está disponible en el repositorio svn habitual de ardour.org. Harrison ha apoyado el desarrollo de Ardour durante mucho tiempo, y van a seguir colaborando en el mismo. Parte de los beneficios de la venta de Mixbus serán destinados a los desarrolladores de Ardour y al incremento de los esfuerzos de desarrollo.

Gracias a Thomas Vecchione de Seablade y a Malte Rogake por sus revisiones al diseño y las pruebas durante el desarrollo de Mixbus.