No más atime con relatime

Por fin, despues de tanto tiempo de discusiones absurdas, en uno de sus arranques Linus ha incluido y activado por defecto relatime. Que es una abreviación de "relative atime". Y "atime" es, a su vez, una abreviación de "access time", donde se almacena la última vez que se accedió a ese archivo.

El problema de atime es que, como consecuencia, cada vez que se lee un archivo hay que realizar una escritura para actualizar ese campo. Algo que no es ninguna minucia, porque los programas están constántemente leyendo cosas, a veces con mucha frecuencia, y se generan auténticas "tormentas" de actualizaciones de atime pendientes. De hecho, es una de las cosas que más pueden enlentecer una máquina. Ya conté hace tiempo que en los pedazo de servidores de kernel.org, el simple hecho de desactivar la actualización del campo atime (con la opción "noatime") les redujo la carga del sistema a la mitad. Un simple doble click en la carpeta del navegador de archivos implica una escritura para actualizar el atime del directorio....y una adicional (en la práctica, varias adicionales) por cada uno de los archivos presentes en el directorio, a los que el navegador de archivos accede para averiguar su contenido. En un servidor web, cada petición HTTP implica una actualización del atime de todos los archivos .html/.php a los que se acceda, generando más escrituras cuantas más visitas se reciben (que es cuando menos se necesita que el disco esté perdiendo el tiempo con actualizaciones de atime)

El caso es que atime es parte de POSIX. Es uno de esos casos donde los estándares se apartan de la realidad, porque desactivar la actualización de atime es uno de los recursos más frecuentes en todo tipo de sistemas operativos (en las comparaciones windows vs linux pagadas por microsoft, lo desactivan siempre, en ambos sistemas), pero como el estándar es el estándar sigue siendo la opción por defecto en muchos sistemas. Y hay algunas utilidades -raras-, como "tmpwatch", que se basan en el campo "atime" para fijarse en si un archivo ha sido accedido recientemente. Asi que aunque se puede estar años funcionando sin atime (como un servidor) y sin tener ningún problema, las distribuciones eran reacias a cambiar una aspecto por defecto del kernel como lo es la actualización del campo atime (aunque algunas, como Ubuntu, lo han hecho). Asi que al final se ha inventado realtime: Se actualiza el campo atime...solamente si entre ese momento y la anterior fecha de atime han pasado más de 24 horas. Eso elimina gran parte de las actualizaciones de atime, pero al mismo tiempo no las elimina del todo.

El resultado es que la mayoría de las distros incorporarán este cambio, y el rendimiento de los equipos de la gente aumentará un poco...por la cara. Creo que es el primer Unix que hace algo así de serie, y ya era hora de que alguien lo hiciera.

Nuevo firewall habemus: adios iptables, bienvenido nftables

Parece ser que Patrick McHardy, uno de los desarrolladores de iptables, ha sacado a la luz la primera versión de nftables, un sustituto de iptables reescrito desde cero y en fase muy alpha. El anuncio original da aun más detalles que la anterior noticia.

Francamente, despues de leer varias veces el anuncio original, no soy capaz de averiguar exactamente qué mejoras tiene respecto a iptables (además los temas de redes me producen sopor y soy un cateto en estas cuestiones). Parece tratarse de una gran mejora en cuanto a como se implementa internamente este tipo de mecanismos, pero exteriormente (en lo que viene a ser lo que el usuario puede hacer con esta herramienta) es lo mismo, exceptuando que desparecen algunas restricciones presentes en iptables, que el "lenguaje" de la línea de comandos parece ser mucho más intuitiva, y que el sistema es, en general, mejor.

La principal mejora a ojos del usuario parece ser que se rompe la relación "una regla, una acción", lo cual a veces obliga a encadenar varias reglas en iptables para ejecutar varias acciones simultaneas sobre un mismo paquete, en nftables parece que se podrían tener varias acciones en una sola regla. El ejemplo que ponen de esto es el de al detectar un determinado paquete, informar de su presencia a los logs, contarlo y posteriormente drop-earlo. En iptables esto parece requerir por narices de tres reglas, en nftables puede hacerse en una (y no se trata de una cuestión del interprete que pueda solucionarse en iptables con algún tipo de comando "wrapper", como han hecho muchos proyectos con propósito de hacer "más fácil" el uso de uptables)

Por lo demás, la descripción indica que el diseño de este nuevo juguetito se ha hecho siguiendo la tradición unixera de separar estríctamente los mecanismos de las políticas, lo cual tiene como resultado una implementación del lado del kernel mucho más pequeña que la de iptables, más simple y muy escalable, y una mayor participación de la herramienta de espacio de usuario en el proceso de la "política" introducida por el usuario. El programa "construye" de algún modo las reglas, crea una representación interna de las reglas que el kernel entiende, se envía al kernel mediante netlink y éste se encargaría de hacer lo que esa representación ordena que se haga. Siento no poder ser más específico, pero parece un tema más apropiado para desarrolladores de compiladores (es decir, un coñazo). Y perdonenme, pero es sábado y es la hora a la que la gente suele empezar a salir a los bares.

¿Como sería un mundo IBM+Sun para el software libre?

Supongo que a estas alturas ya se habrán enterado ustedes del rumor de compra de Sun por parte de IBM. Tiene pinta de ser sospechosamente veraz, por varias razones. Primero, viene del Wall Street Journal, que aunque no deje de ser un periódico tiene cierta reputación. Segundo, en estos precisos momentos el subidón de las acciones de Sun va por el 80% (la oferta teórica de IBM sería del doble del valor en bolsa de Sun al precio de ayer, 6.000 millones). Eso quiere decir que en menos de 24 horas se han metido más de 2.000 y quizás más de 3.000 millones en acciones de Sun, y un movimiento de dinero tan grande suele ser de grandes fondos de inversión, quienes no creo que arriesgarían una cantidad de dinero así (y menos tal como están las cosas) si no supieran con certeza que no van a perderlo. Aunque de la bolsa nunca hay que fiarse, y menos ahora. Por otra parte, hay quien duda de que tenga sentido, pero cuando el rio suena...además, Cisco acaba de entrar en el mercado de los servidores, y HP compró hace casi un año una compañía llamada EDS por 13.000 millones, según dicen para hacer competencia a IBM. Hay quien dice que tiene sentido que eso esté llevando a IBM a hacer esto.

Pero dejando este tema (de la que ya se ha enterado todo el mundo), yo me pregunto (que es algo que ha hecho menos gente y por lo tanto es más susceptible de atraer visitas) ¿cómo sería libre un mundo posterior a esta hipotética transacción entre asquerosos multimillonarios quiebrabancos? Y sobre todo, ¿como influiría al software libre?

La primera gran diferencia estaría en Java. IBM lleva muchos años apoyando a Java, pero con el control del lenguaje y de la VM de referencia (para que vamos a engañarnos: esos comités supuestamente democráticos dejan bastante que desear, y a la hora de la verdad es Sun quien decide lo que se hace o deja de hacer en Java) las cosas cambiarían bastante. Por ejemplo, no creo que IBM fuera tan estúpidamente elitista como lo ha sido y es Sun, no hay más que recordar como ha llevado la competencia con C#, hasta el punto de que .NET pareció, durante mucho tiempo, una plataforma más abierta. Luego está el tema de la plataforma de desarrollo, Netbeans y demás. IBM podría unificar y reforzar al mundo Java.

Respecto a SPARC, sin duda IBM lo mataría. Pero como el futuro de SPARC tampoco ha estado nunca demasiado claro tampoco parece una gran pérdida.

Respecto a Solaris, es más dificil predecir. Por una parte, es dudoso que IBM vaya a echarse atrás en su apoyo a Linux, con todo lo que ha invertido en él. No parece que a IBM le interese centrarse en el desarrollo de sistemas operativos de este tipo, esa es la razón por la que se metieron en Linux, donde la mayor parte del desarrollo lo hacen empresas como Red Hat. IBM aun mantiene a un buen equipo de desarrollo, pero lo hacen tan solo como investigación, no tienen productos que incluyan el kernel Linux, a diferencia de Red Hat o cualquier otra distro. Se desentienden completamente de esos temas, no tienen ni quieren tener su propia distro, mantienen ese equipo de desarrollo solo para que a las demás empresas basadas en Linux les vaya bien, no porque ellos saquen dinero de hacer eso. Con Solaris tendrían que hacer ellos casi todo el desarrollo, tendrían venderlo ellos mismos porque solo Sun vende Solaris, tendrían que intentar generar un "ecosistema" similar al que han generado con Red Hat & cía, pero compitiendo a la vez con Red Hat & cía, que van a seguir apostando por Linux...suena demasiado improbable, pero cosas más raras hemos visto. No descarten nada, incluidas GPL-ificaciones del código.

Respecto a OpenOffice y Mysql, creo que sería beneficioso un cambio, especialmente en el primer caso. No creo que IBM esté obsesionado con mantener derechos de copyright en todo el código (de hecho, en GCC se lo ceden gustosamente a GNU), que es un gran problema y ha causado ya un fork en go-oo.org. Mysql espero que lo venda, o que lo mantenga, sería muy triste que intentara matarlo (no estamos hablando de cerrar el código ni nada, sino simplemente de cortar la inversión en mejoras) para evitar competencia a DB2, pero desgraciadamente es algo que podría pasar. Esten muy atentos a este punto porque es muy importante, pero no olvidemos que aun está postgresql...

En los servidores, IBM alcanzaría una cuota de venta de servidores del 42%, muy por encima del 29% de HP, en segundo lugar. ¿Acudirá HP a los juzgados antimonopolio? No sería sorprendente, están muy de moda. Por otra parte, Sun tiene muchos productos hardware relacionados con el almacenamiento (provenientes de la compra de storagetek) y montones de otras cosas que a saber que carajo va a pasar con ello.

En fin, esperemos a ver si se confirman los rumores, a ver como evoluciona el tema. Sea cual sea el resultado, esperemos que sea beneficioso para el software libre.

Lo que traerá Linux 2.6.29

Despues del formato en doble artículo de la versión anterior cabía esperar que esta, la 2.6.29, fuera algo más austera en cuanto a la importancia de sus novedades, pero no ha sido así. Solamente la cuestión apodada modesetting se merecería varios artículos para hablar (alguien que conozca bien el tema del tema) de las profundas implicaciones que conlleva, pero yo no pienso hacer ni uno solo separado. Directamente traduciré aquí todo lo que he puesto en la versión original inglesa de la lista de novedades para Linux 2.6.29, y que Dios reconozca a los suyos.

Modesetting: Cuando hablamos de "mode setting", queremos decir configurar cosas como la resolución y la profundidad de color de la pantalla. En otras palabras, configurar lo que haga falta de la tarjeta gráfica para que se puedan dibujar cosas en la pantalla. Puede parecer algo fácil de implementar pero la gente que se dedica a los gráficos asegura que diseñarlo e implementarlo bien es más dificil de lo que parece, razón por la que se ha tardado tanto tiempo. Para empezar, configurar la tarjeta gráfica implica asignar memoria de la tarjeta gráfica, lo que significa que antes de hacer toda esta historia de modesetting, era necesario tener el gestor de memoria GEM e incluirlo en el kernel, lo cual no ocurrió hasta la versión anterior, 2.6.28.

Implementarlo bien es mucho más dificil si uno considera como funciona la arquitectura gráfica de los sistemas Linux hoy en día. Tenemos varios drivers compartiendo el mismo hardware (la tarjeta gráfica): El driver VGA del kernel, los drivers framebuffer, los drivers DRM del kernel, los drivers en espacio de usuario de X.org, los drivers DRI de espacio de usuario, y otros drivers en espacio de usuario (ej: svgalib). Es una pésima idea. Por ejemplo, el driver en espacio de usuario de X.org es una implementación completa de todo lo que se necesita para hacer funcionar la tarjeta gŕafica en modo 2D, y cuando se inicia X.org todo va bien. Pero cuando se cambia de X.org a un terminal virtual (Control+Alt+F1), el driver X.org tiene que dejar de gestionar la tarjeta gráfica, porque se necesita pasar el control a otro driver: el driver de la consola fb. Asi que el driver X.org guarda el estado de la pantalla, se reinicia la tarjeta gráfica y se pasa su control al driver fb, que tiene que reinicializar completamente la tarjeta de nuevo (esa es la razón por la que hay esa pausa durante el cambio), incluso si la resolución en X.org y en la consola fb es la misma. Cuando vuelves a X.org, la tarjeta necesita ser reconfigurada de nuevo. Esta arquitectura es confusa, proclive a dar muchos fallos, y es dificil de hacer funcionar correctamente en algunos casos, por ejemplo, es más dificil despertar el sistema tras haberlo suspendido/hibernado con este diseño porque el driver X.org está en espacio de usuario y la suspensión/hibernado es (debe ser) transparente para él, asi que no tiene constancia de que debe reiniciar el hardware antes de continuar dibujando tras despertar el sistema por completo, necesitando por tanto un ayudante en forma de programa en espacio de usuario o en firmware que a veces puede no funcionar correctamente (pantalla negra, cuelgue).

Con modesetting, todos esos problemas desaparecen. El aspecto modesetting de las tarjetas gráficas se centraliza en los drivers del kernel. Puede que esto parezca mucho código para meterlo en el kernel, pero en realidad es lo contrario: Hay una sola base de código encargada del modesetting, lo cual significa que el tamaño de todo subsistema gráfico se reduce. Y como solo hay una implementación, y se comparte más el código, la calidad y robustez del código se incrementan. Además, esta es una tarea que verdaderamente corresponde a los drivers del kernel (es como lo han hecho sisempre todos los demás sistemas operativos, incluyendo algunos Unix propietarios). Pero todo esto es solo una pequeña parte de todos los beneficios: La suspensión e hibernación funcionan mejor, porque todo el trabajo lo hace el driver del kernel tal y como se hace con el resto de hardware. X.org ya no necesita privilegios de root (hasta ahora se habían necesitado tan solo porque los drivers necesitaban acceder al hardware para implementar los drivers en espacio de usuario), haciendo posible ejecutar X.org sin permisos de root, lo cual es una gran mejora y deja a X.org dedicarse a la tarea que se supone que le corresponde: dibujar cosas, no toquetear el hardware. Tambien se hace posible imprimir "oopses" del kernel (o incluso una BSOD al estilo de Windows ;) en la pantalla si el kernel falla mientras se trabaja en X.org. Y por si todo esto no fuera suficiente, tambien se consigue una consola FB que funciona sobre modesetting y GEM, haciendo que los viejos drivers FB se vuelvan innecesarios y conservando al mismo tiempo su funcionalidad. Y con modesetting ya no se necesita resetear el hardware cuando se cambia de X.org a un terminal virtual, y cuando se cambia, si la resolución es la misma, no hay necesidad de cambiar nada, haciendo posible la creación de una pantalla de arranque sin artificios gráficos inesperados.

Sin embargo, probar modesetting no es fácil. En el lado del kernel, solo el driver de Intel añade soporte de modesetting (el soporte para otros drivers está en proceso y será incluido en futuras versiones). En el lado de X.org es aun más dificil. Porque cuando el soporte de modesetting en el kernel está activado, se REQUIERE que el driver X.org driver tambien tenga soporte de modesetting. Si activas el soporte para modesetting y no tienes un driver de X.org con soporte modesetting, X.org NO podrá funcionar de ningún modo e incluso podría colgar tu máquina. No hay ningún modo de solucionar esto, excepto desactivar el soporte modesetting del kernel. Ahora mismo, solo los drivers de Intel parecen tener una versión estable con soporte de modesetting, el soporte para otros drivers está aun en desarrollo

Btrfs: Btrfs es un nuevo sistema de archivos desarrollado de cero siguiendo los principios de diseño de otros sistemas de archivo como ZFS o WAFL. Fue creado por Chris Mason, un programador de Oracle que trabajó varios años en Reiserfs v3. Se espera que se convierta en el reemplazo de los sistemas de archivos Ext como el sistemas de archivo más utilizado. Se puede encontrar más infomación en el wiki de btrfs. Btrfs se encuentra bajo desarrollo, lo cual significa que es INESTABLE, y aunque en los últimos meses se ha estabilizado bastante no debes asumir que usarlo es seguro. Se está incluyendo en el kernel del mismo modo que se incluyó ext4dev, para mejorar el desarrollo. Asi que se recomienda no utilizarlo para nada que no sea pruebas, benchmarks y desarrollo. El plan actual del equipo de btrfs es sacar una versión 1.0. No se espera que el formato de disco vaya a cambiar más (aunque lo hará si se encuentra algún fallo crítico).

Squashfs: Squashfs es un sistema de archivos de solo lectura y altamente comprimido que es muy conocido por ser utilizado como base de los Live-CDs de las distribuciones Linux más comunes y de algunas distribuciones para dispositivos embebidos como routers. Usa compresión zlib (en un futuro habrá soporte lzma) para comprimir archivos, inodos y directorios. Los inodos en el sistema son muy pequeños y todos los bloques son compactados para minimizar los datos extra. Soporta tamaños de bloque mayores que 4K (hasta 1M, tamaño de bloque por defecto 128K).

SquashFS 4.0 soporta sistema de archivos y archivos de 64 bits (mayores de 4 GB), información completa uid/gid, enlaces duros y marcas de tiempo. Su propósito es ser utilizado como sistema de archivos de solo lectura, para archivos (en los casos donde se podría utilizar un .tar.gz), y en dispositivos embebidos bajos en recursos. Se puede encontrar más información y las herramientas en espacio de usuario (necesarias para crear el sistema de archivos) en http://squashfs.sourceforge.net

Tree RCU: Esta característica soluciona un problema de rendimiento en la implementación clásica de RCU (un tipo de sistema de bloqueo que utiliza Linux para lograr gran escalabilidad) que desembocaba en contención interna del mecanismo en sistemas con más que unas pocas cientas de CPUs; el RCU clásico fue diseñado para máquinascon 16-32 CPUs. "Tree RCU" aplica una jerarquía, reduciendo en gran medida la contención en el bloqueo de primer nivel en grandes máquinas.

WiMAX: 2.6.29 incluye soporte de WiMAX, que proporciona transmisión inalámbrica de datos a grandes distancias: 75 Mbit/s. Está basada en el estándar IEEE 802.16. Esta pila ha sido proporcionada por Intel, e incluye un driver para los dispositivos Intel Wireless WiMAX/Wi-Fi Link 5x50 USB/SDIO.

Soporte Wireless del modo Access Point:La pila wifi mac80211 está ahora preparada para soportar el modo AP. Requiere hostapd. Este modo solamente se puede configurar a través de cfg80211 (no con iwconfig y/o WEXT).

Cifrado de nombres de archivo en eCryptfs: eCryptfs implementa cifrado transparente de los contenidos de un archivo. En esta versión tambien puede cifrar el nombre del archivo. Cada nombre cifrado tiene un prefijo que indica que eCryptfs debe intentar descifrar el archivo, razón por la que eCryptfs no podrá gestionar correctamente los nombres de archivo que estén cerca del límite máximo del nombre de archivo.

'Congelado' del sistema de archivos: Linux no tiene nada que congele temporalmente las escrituras en un sistema de archivos. Asi que no es posible tomar una copia de seguridad que mantenga consistencia con el sistema de archivos mientras está montado y siendo utilizado. Muchos sistemas de archivo comerciales (por ejemplo, VxFS) tiene una característica que pausa las escrituras temporalmente, en esta versión Linux añade una característica similar.

Soporte de swap en el controlador de memoria, y otras mejoras: Esta característica añade gestión de swap al controlador de recursos de memoria. Anteriormente, el controlador no podía controlar el swap utilizado por los procesos de un cgroup, permitiendo por tanto que un solo proceso acabara con todo el swap. Ahora, puedes limitar el uso de memoria+swap de cada cgroup. Sin embargo, añade cierta sobrecarga de recursos, asi que es configurable. Otra característica añadida al controlador de memoria es el soporte de jerarquías, configuración de swappiness por cada, estadísticas mejoradas y mejor gestión de oom.

Soporte de 4096 CPUs en X86: El núcleo de Linux soporta ese número de CPUs, pero había problemas en el código específico x86. Hay una estructura de datos, cpumask_t, que se utiliza para representar a todas las CPUs del sistema. Con 4096 CPUs esa estructura se volvió demasiado grande, causando desbordamientos de pila. El código ha sido modificado para utilizar punteros para esa estructura en lugar de utilizar la pila, haciendo posible tener máquinas x86 con 4096 CPUs (si, existen).

Modo sin journal para Ext4: Desde que nació Ext3, hubo gente que nunca quiso utilizar journaling por varias razones. En esta versión, Ext4 añade soporte para funcionar sin journaling. El resultado es una pequeña mejora de rendimiento comparado con el Ext4 normal, pero sobre todo, una gran mejora sobre Ext2.

Checksums de los metadatos en OCFS2: OCFS2 (un sistema de archivos para clusters) utiliza ahora checksums para los metadatos, para asegurar la integridad.

Pues eso es todo. La lista completa y detallada está aquí, como siempre.

Phoronix, el nuevo OSNews

OSNews.com es todo un clásico en el mundillo del software libre. No es que sus editores se distingan por su opinión neutral, actualizaciones, bueno sitio web o cualquier otro valor "periodístico". Lo que distingue a OSNews del resto de sitios de Internet es su temática.

Su nombre ya marca la diferencia: "Noticias sobre sistemas operativos". Hay muchas páginas donde se habla de Windows, Linux y Mac, pero como marcas, como "productos". Pero OSNews no solo se dedica a tratarlos como sistemas operativos, sino tambien a todos los aspectos de "bajo nivel". Es el único sitio donde te puedes encontrar una noticia sobre una nueva versión de KDE, otra de un parche que acelere X% la operación Y en GTK, otra de un artículo a fondo sobre un sistema de archivos, otra sobre Haiku o ReactOS, otra sobre los futuros planes de desarrollo de GCC o X.org. Era un sitio centrado en las novedades y sucesos importantes en todos los aspectos de bajo nivel de los sistemas operativos libres sin dejar a un lado a los sistemas operativos propietarios o los experimentales. Para todo geek linuxero era un sitio cojonudo.

Pero en los últimos meses, algo ha cambiado.

El cambio empezó cuando Eugenia dejó la gestión del sitio a manos de Thom Holwerda. Eugenia era una chica que, por ejemplo, se mantenía suscrita a las listas de Gnome, GTK, KDE, X.org y muchos otros proyectos, así estaba al tanto de cualquier novedad. No se si Thom está suscrito a esas listas, pero si sé que si se hace eco de algo es a través de algún artículo de terceros que los fieles de OSNews envian al buzón de sugerencias. Su página ha pasado de un sitio donde se generaban noticias, el primer sitio donde un hecho importante y no advertido por ningún otro medio pasaba a ser noticia, a ser un sitio que ha caido en la comodidad de limitarse a aceptar los enlaces sugeridos por sus lectores. Según mi modo de valorar las cosas, no parecen ofrecer nada que pueda interesarme, recuerdan a microsiervos. Sus noticias son siempre enlaces a otros sitios, no aportan nada, ni una opinión interesante, en la mayoría de los casos tan solo son cut&paste de los sitios originales.

Pero aun es peor. Una vez que un sitio así pasa de ser un sitio de noticias a un blogroll, se empieza a volver selectivo. Hace unos cuantos meses OSNews introdujo la "Page 2": Un sitio donde quedan relegadas las noticias que según los editores son "poco importantes". Cosas como KDE 4.2.1, o la RC del SP2 de Vista, quedan marginados a esa página, mientras que una noticia que informa de una futura "app store" para blackberrys está en la principal. Y aun peor: Hace unos días mande una noticia donde Ted Tytso informa de que ha conseguido acelerar el fsck de Ext4 un 40% adicional....¡y no lo publicaron en ningún lado!

Está claro que ha dejado de ser un sitio donde los lectores tradicionales no tenemos cabida.

Afortunadamente, hay un sustituto. Ese sustituto es Phoronix (RSS). Echen un ojo al RSS, gracias a Phoronix me enteré de cuando Gallium3D entró en la versión de desarrollo de Mesa, de la evolución de DRI2, de la evolución de los drivers libres para gráficas Nvidia (Nouveau) o los de Intel, , de cuando entró el soporte de EXA y X-Video en el repositorio del driver libre de ATI/AMD, de las novedades de cada versión nueva de Wine y Qemu o QT, de la última versión de gnash, de que Intel está planeando soportar la API VDPAU en sus drivers...si no están suscritos a Phoronix, puede que ni tan siquiera sepan de lo que estoy hablando, porque ningún otro sitio considera todo eso como noticia. En OSNews no se ha publicado nada de todo lo que acabo de citar. Eso si, han contado que el Live CD de Haiku -su obsesión particular- "impresiona", aparentemente porque arranca y tiene antialiasing.

En Phoronix no solamente se sigue informando de lo que se nos hubiera informado en el antiguo OSNews, sino que lo hacen bastante mejor: mucho mejor análisis técnico, benchmarks propios -no muy acertados a veces, pero van mejorando-, etc. Crean noticias. La mejor prueba de todo lo que digo es que, si uno busca en OSNews, se da cuenta de que buena parte de las noticias interesantes en los últimos meses han sido enlaces a Phoronix. Lo malo de Phoronix es que la web es insoportable, y los artículos largos y elaborados tienen esa típica estructura de división en páginas que se usa para aumentar las visitas, pero gracias al RSS no es un gran problema.

Los drivers propietarios atacan de nuevo

En Phoronix se hacen eco de los problemas que sufren los usuarios que utilizan los drivers propietarios de Nvidia:

"La mayoría de usuarios de las últimas generaciones de tarjetas gráficas (de 8800 en adelante) están sufriendo cuelgues precedidos de corrupción en la pantalla. Este problema ha existido desde Noviembre de 2008 y está limitado a versiones del driver 180.xx, que desafortunadamente es la única que Nvidia mantiene. Volver al 177.82 hace que los problemas desaparezcan. Nvidia solamente se centra en implementar nuevas características pero parece ignorar los fallos graves."

Quienes funcionan con Windows saben que esta no es una excepción que se sufra solo Linux. Ya dijo Microsoft en su día que el 30% de todos los cuelgues en Vista estaba causado por Nvidia...y no es raro instalar la última version estable de los drivers de Nvidia/ATI y encontrarse con que aparecen nuevos fallos que antes no estaban.

Los drivers propietarios suponen poner tu sistema en manos de la compañía que fabrica el hardware, en su buen o mal hacer en materia de drivers, en su atención al cliente... Como en un PC de escritorio típico hay mucha variedad de hardware, dependes de multitud de empresas: Una para la tarjeta gráfica, otra para la tarjeta de sonido, otra para el chipset, otra para la tarjeta de red, otras cuantas para los artilugios USB. En fin, que es un panorama divertido, especialmente a la hora de actualizar: que si viaarena.com por aquí, ati.amd.com por allá...cada compañía poniendo nombres (¡¡) a sus drivers en páginas de terrorífica usabilidad, confusión entre el nombre del hardware que compras y el número del chip por el que el fabricante cataloga los drivers (un servidor se ha aprendido el formato de la lista de IDs PCI de pciids.sf.net para suplir la falta de lspci en Windows), si tu hardware no es "moderno" tienes que jugar a buscar la última versión de drivers que te valga, y eso suponiendo que la empresa no haya decidido borrar de su página web esos drivers obsoletos. O encontrarte lo que vi una vez: drivers que requieren que introduzcas un número de licencia del hardware para cargarse...

Ante este horror la respuesta de windowseros es que compres hardware de calidad. El problema es, ¿qué ocurre cuando marcas de calidad como ATI deciden dejar de soportar una tarjeta, como me pasó a mi? ¿O qué pasa con la mierda de drivers gráficos que una compañía seria como Intel hizo para Vista? Es fácil decir echar las culpas a los malos fabricantes de hardware, pero una vez que un cliente compra algo de hardware va a usarlo aunque sea de una compañía mala, y si los drivers son malos el cliente no se sentirá a gusto con su sistema.

Yo soy de los que piensa que una de las grandes ventajas de Linux es precisamente su soporte de hardware. Cada vez que tengo que tocar algo de Windows, me sorprende su infierno de drivers. Sin ser perfecto, una vez que uno compra hardware compatible -con Intel siempre se consiguen buenos resultados-, te solucionas la vida. Tu hardware estará soportado siempre por defecto en todas las distros sin tocar nada ni actualizar nada. No tendrás mucho de qué preocuparse. Eso es porque en Linux, se separa el hardware de la creación y mantenimiento del driver, puedes comprar hardware a compañías chapuceras, y tener un buenos drivers y un soporte que puede llegar a proporcionarte la misma compañía que crea el SO.

(Que conste que no he mencionado el tema del software libre para nada)