30 de marzo de 2012
Dell y Linux
Una nota rápida para hacer referencia a este post, que nos recuerda que Dell lleva varios años empleando a gente para asegurarse que Linux funciona correctamente en sus servidores: En los últimos 13 años han corregido cerca de 5.000 fallos en el bugzilla de Red Hat.
Este es el tipo de trabajo en la sombra que no se hace notar mucho, pero que tiene una importancia tremenda.
La balcanización de GNOME
No soy la primera ni la última persona en notar la reciente proliferación de "shells" de escritorio alternativos en el mundo Linux. Porque la lista es considerable: Tenemos Unity, Gnome-shell, Gnome-shell fallback, Gnome-shell con extensiones, Cinnamon, Ubuntu classic, Trinity, Razor-QT...en el mundo del software libre siempre hubo opciones y nunca faltaron excentricidades y nichos de dudoso gusto, pero lo de estos últimos tiempos se pasa de la raya.
Estos forks y alternativas de nuevo cuño tienen algo en común, y es que están circunscritos sobre todo a la órbita gnomera descontenta con Gnome Shell. Si, en el mundo KDE también hay opciones alternativas, pero son poca cosa: Trinity, que es una continuación nostálgica de KDE 3.5 (su equivalente en Gnome sería Mate); y Razor QT, que es una alternativa ligera a lo LXDE basada exclusivamente en QT que en realidad no tiene que ver con KDE. Más allá de eso, no hay conflictos.
¿Por qué? Sencillo: KDE es extraordinariamente flexible. ¿Quiere usted un KDE clon de Unity? Lo hay. ¿Quiere un menú global a lo OS X? También lo hay. ¿Quiere usted algo radicalmente diferente como la propuesta de menús HUD de Ubuntu? También. ¿Quiere una interfaz optimizada para Netbooks? Pues tome. ¿Quiere Cinnamon o algo a lo Gnome 2? Deje de preguntar y configure sus plasmoids. Al ser capaz de adaptarse a todos los gustos, cada uno lo configura como quiere y no hay razones para tirarse trastos a la cabeza. En algunos de los casos mencionados hay que seguir guías, lo cual indica que usar KDE no es la cosa más sencilla del mundo, pero la flexibilidad está ahí.
El caso de Gnome 3 es el contrario. Y antes de nada déjenme aclarar que soy consciente de que mucha gente feliz con Gnome Shell, a pesar de ser el escritorio menos configurable desde la aparición de Windows 95 (oops. Lo siento, no quise hacer daño). Pero quien define la aparición de los shells alternativos no es el grupo de gente que acepta Gnome Shell, sino el de quienes no lo aceptan, un grupo que es numeroso y, desde luego, se hace oir y notar. Esta rebeldía es grave y ha sido ignorada por los gestores del proyecto Gnome durante las fases de diseño, las de desarrollo, tras la primera versión estable, y todavía hoy sigue siendo ignorada.
Si, es cierto que ahora hay extensiones para quienes quieran añadir algunas modificaciones (y por cierto, no deja de ser paradójico que haya quien odie a KDE por tener demasiadas opciones de configuración, y de repente sean felices con las extensiones, que no son más que otra forma de implementar opciones de configuración). En mi opinión las extensiones, más que un cambio de actitud hacia los disidentes, parecen haberse convertido en una excusa para ignorarlos. Esto ha quedado bastante patente con el anuncio de las pretensiones de intentar mover el modelo de uso hacia la aplicación única maximizada y menospreciar los casos de uso de quienes tienen más de dos ventanas visibles simultáneamente (es decir, tabletizar la UI de escritorios que no son ni tabletas ni teléfonos). Hay gente a la que no le gusta nada, y es previsible que sean ignorados una vez más.
El estado de Gnome es triste: la comunidad se ha balcanizado, y no se ve en el horizonte oportunidad de reunificación, ni tan siquiera ganas de buscarla. La mayoría de usuarios de aplicaciones Gnome usan Unity, un shell también criticado, pero mucho más aceptado con las mejoras más recientes (la última versión es francamente buena). La inclusión de Ubuntu Classic (gnome-panel portado a GTK 3) en los repositorios oficiales en la próxima versión de Ubuntu no hace más que crear una válvula de escape que impedirá que la gente acuda a Gnome Shell, y abre la posibilidad de crear una comunidad a su alrededor que cobre vida propia. Respecto a Cinnamon -fork de Gnome Shell con apariencia de Gnome 2-, en los foros linuxeros el clamor popular lo adora con verdadero fervor. "Es lo que gnome shell debería haber sido", se oye decir, y estoy de acuerdo. Está hecho por gente que no es experta en usabilidad, y quizás por eso tiene tanto éxito: se limitan a imitar patrones requeteconocidos y a atender sus gustos y los de sus usuarios, en lugar de romperse la cabeza en intentar cuestionar las costumbres establecidas.
¿Y es todo esto grave? Si, lo es, y mucho: a día de hoy, podemos decir que la dirección oficial del proyecto Gnome está completamente divorciada de la realidad de sus usuarios. Los desarrolladores plasman en Gnome Shell una visión oficial que en la práctica sólo usa una minoría. Siguen implementando novedades que jamás serán vistas por mucha gente que usa Gnome. Hacen planes sin tener en cuenta el impacto que tendrá en los shells que usa la verdadera mayoría. Gnome-oficial se ha convertido en un proyecto endogámico, inconsciente de que su oficialidad no es más que un título nobiliario que ha sido apartado por el clamor popular, en gran medida por que su tozudez e incapacidad de acoger sensibilidades ajenas obligó a la gente a buscarse alternativas. No hay que ser un genio para imaginar qué clase de consecuencias pueden originarse de continuar esta división a largo plazo: más división, renacimiento de antiguas cuestiones nunca resueltas (¿C, C#, Vala, Javascript?) y solidificación definitiva de shells alternativos, y también de forks varios - que tal vez no se limiten al shell.
Estos forks y alternativas de nuevo cuño tienen algo en común, y es que están circunscritos sobre todo a la órbita gnomera descontenta con Gnome Shell. Si, en el mundo KDE también hay opciones alternativas, pero son poca cosa: Trinity, que es una continuación nostálgica de KDE 3.5 (su equivalente en Gnome sería Mate); y Razor QT, que es una alternativa ligera a lo LXDE basada exclusivamente en QT que en realidad no tiene que ver con KDE. Más allá de eso, no hay conflictos.
¿Por qué? Sencillo: KDE es extraordinariamente flexible. ¿Quiere usted un KDE clon de Unity? Lo hay. ¿Quiere un menú global a lo OS X? También lo hay. ¿Quiere usted algo radicalmente diferente como la propuesta de menús HUD de Ubuntu? También. ¿Quiere una interfaz optimizada para Netbooks? Pues tome. ¿Quiere Cinnamon o algo a lo Gnome 2? Deje de preguntar y configure sus plasmoids. Al ser capaz de adaptarse a todos los gustos, cada uno lo configura como quiere y no hay razones para tirarse trastos a la cabeza. En algunos de los casos mencionados hay que seguir guías, lo cual indica que usar KDE no es la cosa más sencilla del mundo, pero la flexibilidad está ahí.
El caso de Gnome 3 es el contrario. Y antes de nada déjenme aclarar que soy consciente de que mucha gente feliz con Gnome Shell, a pesar de ser el escritorio menos configurable desde la aparición de Windows 95 (oops. Lo siento, no quise hacer daño). Pero quien define la aparición de los shells alternativos no es el grupo de gente que acepta Gnome Shell, sino el de quienes no lo aceptan, un grupo que es numeroso y, desde luego, se hace oir y notar. Esta rebeldía es grave y ha sido ignorada por los gestores del proyecto Gnome durante las fases de diseño, las de desarrollo, tras la primera versión estable, y todavía hoy sigue siendo ignorada.
Si, es cierto que ahora hay extensiones para quienes quieran añadir algunas modificaciones (y por cierto, no deja de ser paradójico que haya quien odie a KDE por tener demasiadas opciones de configuración, y de repente sean felices con las extensiones, que no son más que otra forma de implementar opciones de configuración). En mi opinión las extensiones, más que un cambio de actitud hacia los disidentes, parecen haberse convertido en una excusa para ignorarlos. Esto ha quedado bastante patente con el anuncio de las pretensiones de intentar mover el modelo de uso hacia la aplicación única maximizada y menospreciar los casos de uso de quienes tienen más de dos ventanas visibles simultáneamente (es decir, tabletizar la UI de escritorios que no son ni tabletas ni teléfonos). Hay gente a la que no le gusta nada, y es previsible que sean ignorados una vez más.
El estado de Gnome es triste: la comunidad se ha balcanizado, y no se ve en el horizonte oportunidad de reunificación, ni tan siquiera ganas de buscarla. La mayoría de usuarios de aplicaciones Gnome usan Unity, un shell también criticado, pero mucho más aceptado con las mejoras más recientes (la última versión es francamente buena). La inclusión de Ubuntu Classic (gnome-panel portado a GTK 3) en los repositorios oficiales en la próxima versión de Ubuntu no hace más que crear una válvula de escape que impedirá que la gente acuda a Gnome Shell, y abre la posibilidad de crear una comunidad a su alrededor que cobre vida propia. Respecto a Cinnamon -fork de Gnome Shell con apariencia de Gnome 2-, en los foros linuxeros el clamor popular lo adora con verdadero fervor. "Es lo que gnome shell debería haber sido", se oye decir, y estoy de acuerdo. Está hecho por gente que no es experta en usabilidad, y quizás por eso tiene tanto éxito: se limitan a imitar patrones requeteconocidos y a atender sus gustos y los de sus usuarios, en lugar de romperse la cabeza en intentar cuestionar las costumbres establecidas.
¿Y es todo esto grave? Si, lo es, y mucho: a día de hoy, podemos decir que la dirección oficial del proyecto Gnome está completamente divorciada de la realidad de sus usuarios. Los desarrolladores plasman en Gnome Shell una visión oficial que en la práctica sólo usa una minoría. Siguen implementando novedades que jamás serán vistas por mucha gente que usa Gnome. Hacen planes sin tener en cuenta el impacto que tendrá en los shells que usa la verdadera mayoría. Gnome-oficial se ha convertido en un proyecto endogámico, inconsciente de que su oficialidad no es más que un título nobiliario que ha sido apartado por el clamor popular, en gran medida por que su tozudez e incapacidad de acoger sensibilidades ajenas obligó a la gente a buscarse alternativas. No hay que ser un genio para imaginar qué clase de consecuencias pueden originarse de continuar esta división a largo plazo: más división, renacimiento de antiguas cuestiones nunca resueltas (¿C, C#, Vala, Javascript?) y solidificación definitiva de shells alternativos, y también de forks varios - que tal vez no se limiten al shell.
21 de marzo de 2012
Las novedades de Linux 3.3
Perdón por el retraso. Ya se ha anunciado la disponibilidad de la versión 3.3 del kernel Linux. Como principal novedad, la inclusión del código del proyecto Android. También hay otras novedades, como una nueva arquitectura (TI C6X), mejora del balanceado y la habilidad de cambiar de modo RAID en Btrfs, y varias mejoras de red: Una implementación de un switch por software (Open vSwitch) para casos con virtualización, una alternativa más rápida y escalable al driver "bonding", un límite configurable a la cola de transmisión de las tarjetas de red para luchar contra el "bufferbloat", un "control group" para controlar la prioridad del tráfico de red, y otro cgroup para límitar el tamaño de los búferes TCP de cad proceso. También se han incluido drivers nuevos y
muchas otras mejoras y pequeños cambios. La lista completa de cambios,
en inglés,
puede encontrarse aquí, como siempre.
1. Inclusión de Android: Los sistemas basados en Android utilizan el núcleo Linux, pero con algunas modificaciones y añadidos propios. Durante mucho tiempo el código de esas variaciones no ha sido incluido en el repositorio principal, debido a desacuerdos entre los desarrolladores de ambos proyectos. Afortunadamente, tras varios años las asperezas están siendo limadas. Varios subsistemas de Android han sido incluidas en esta versión, y se incluirán más en el futuro. Esto hará las cosas más fáciles para todo el mundo, incluyendo la comunidad Android que hace mods personalizados, o las distribuciones Linux que quieran añadir soporte para programas Android.
2. Btrfs: 'restriping' entre diferentes niveles RAID, mejora del proceso de balanceo, mejores herramientas de depuración:
· Mejora del proceso de balanceo, restriping RAID
En Btrfs, la operación de "balanceo" consiste en reescribir todos los datos del sistema de archivo, haciéndolos pasar de nuevo por los asignadores de bloques y de "trozos" de disco (chunks). Esta operación es necesaria en algunos casosa. Por ejemplo, si se añade un nuevo disco, se necesita un balanceo para redistribuir los datos existentes a ese disco. Este balanceo, sin embargo, funciona siempre para todo el sistema de archivos, y puede tardar varios horas, y no soporta cambio de un perfil RAID a otro.
En esta versión la implementación de balanceo ha sido reescrita. Btfrs puede pausar una operación de balanceo, y posteriormente volver a retomarla donde se dejó. Puede observarse el progreso. También puede hacer "restriping" entre diferentes niveles RAID, es decir, cambiar entre un modo RAID y otro. También permite filtrar la operación de balanceo para que sólo afecte a datos o a metadatos. También permite balancear exclusivamente los grupos de bloques que estén casi vacíos. Las utilidades están disponibles en la rama "parser" de btrfs-progrs.
· Mejor depuración
Btrfs tiene una nueva herramienta de depuración, "integrity check", orientada a desarrolladores. Esta herramienta consiste en escanear cada bloque escrito, y examinarlo para comprobar que las referencias son correctas y consistentes, y que no se está escribiendo nada que pudiera dejar al sistema de archivos en un estado de inconsistencia tras un corte de corriente. Esta herramienta -que tiene unos costes de rendimiento muy altos y no está recomendada para usuarios normales- ayudará a los desarrolladores a encontrar fallos con más rapidez.
3. Open vSwitch: Open vSwitch es una implementación de software de un switch de red. Este proyecto ha existido durante varios años, y ahora se incorpora al núcleo principal. Linux ya tiene un switch virtual (el "bridge"), pero Open vSwitch está diseñado para escenarios más complejos, particularmente para entornos de virtualización (lea el documento "Why Open vSwitch?"
Open vSwitch soporta las interfaces de gestión estándar (sFlow, Netflow, RSPAN, CLI), y está abierto a ser extendido y controlado utilizando Openflow y el protocolo de gestión OVSDB, y está diseñado para ser compatible con los chipsets de switching modernos.Ver openvswitch.org para más información.
4. Mejor vinculación (bonding) de interfaces de red: teaming: Esta versión añade un nuevo driver de red llamado "teaming", cuyo objetivo es ser un reemplazo rápido, escalable, y limpio del driver "bonding". Esta funcionalidad suele utilizarse para vincular dos tarjetas de red y así incrementar el ancho de banda máximo y proporcionar redundancia. En esto momentos están disponibles los modos round-robin y active-backup. La librería de espacio de usuario, junto con un par de aplicaciones de demostración, está disponible en github.com/jpirko/libteam.
5. Luchando contra el bufferbloat: byte queue limit: "Bufferbloat" es un término utilizado para describir los problemas de latencia y tasa de transferencia causados por el excesivo buffering en las diferentes capas de una conexión de red. Se están desarrollando algunas herramientas para ayudar a aliviar esos problemas, y esta característica es uno de ellos.
El "byte queue limite" es un límite configurable de datos que se pone a la cola de envío de paquetes de una tarjeta de red. Como resultado, uno puede tunear cosas como que los paquetes de alta prioridad sean atendidos con una latencia razonable sin tener que vaciar la cola cuando existen datos para enviar. La configuración de estos límites se hace en el directorio de sysfs tx-n de cada tarjeta de red.
6. Límites de buffer TCP controlados con cgroup: Se introduce la capacidad de controlar la memoria utilizada por los buffers del protocolo TCP mediante cgroups (grupos de procesos).
7. cgroup para el control de prioridad de red: El cgroup para el control de prioridad de red permite al administrador configurar la prioridad del tráfico de red para los procesos que son miembros del grupo. En teoría, una aplicación podría configurar la prioridad mediante la opción de socket SO_PRIORITY. Esto, sin embargo, no es siempre posible. Este cgroup permite al administrador asignar un proceso a un grupo y obligarle a seguir la configuración definida. Documentación en Documentation/cgroups/net_prio.txt
8. Mejor redimensionado en vivo de Ext4: Se ha añadido una nueva ioctl y código que permite redimensionar un sistema de archivos Ext4 con mayor rapidez y seguridad. El nuevo redimensionado permite al kernel hacer todo el trabajo, como crear bitmaps y tablas de inodos, puede soportar características como flex_bg y BLOCK_UNINIT, y es mucho más rápido.
9. Nueva arquitectura: TI C6X: La familia de arquitecturas que funcionan en Linux ha aumentado aun más con la incorporación del soporte para Texas Instrument C6X. Esta arquitectura soporta procesadores de la familia C64X de uno y varios cores DSP, sin MMU. Esta arquitectura es VLIW, y tiene un conjunto de instrucciones diseñado para aplicaciones DSP. Para más detalles, vea esta página web de TI. La página del proyecto es linux-c6x.org.
10. Soporte para inicio desde EFI: En esta versión se incluye un objeto EFI que permite que una imagen bzImage x86 sea cargada y ejecutada directamente como una aplicación EFI. Tanto los cargadores BIOS y EFI pueden cargar la misma imagen, permitiendo de ese modo utilizar la misma imagen para ambos casos.
Y eso es todo. La lista completa de cambios en inglés, aquí.
1. Inclusión de Android: Los sistemas basados en Android utilizan el núcleo Linux, pero con algunas modificaciones y añadidos propios. Durante mucho tiempo el código de esas variaciones no ha sido incluido en el repositorio principal, debido a desacuerdos entre los desarrolladores de ambos proyectos. Afortunadamente, tras varios años las asperezas están siendo limadas. Varios subsistemas de Android han sido incluidas en esta versión, y se incluirán más en el futuro. Esto hará las cosas más fáciles para todo el mundo, incluyendo la comunidad Android que hace mods personalizados, o las distribuciones Linux que quieran añadir soporte para programas Android.
2. Btrfs: 'restriping' entre diferentes niveles RAID, mejora del proceso de balanceo, mejores herramientas de depuración:
· Mejora del proceso de balanceo, restriping RAID
En Btrfs, la operación de "balanceo" consiste en reescribir todos los datos del sistema de archivo, haciéndolos pasar de nuevo por los asignadores de bloques y de "trozos" de disco (chunks). Esta operación es necesaria en algunos casosa. Por ejemplo, si se añade un nuevo disco, se necesita un balanceo para redistribuir los datos existentes a ese disco. Este balanceo, sin embargo, funciona siempre para todo el sistema de archivos, y puede tardar varios horas, y no soporta cambio de un perfil RAID a otro.
En esta versión la implementación de balanceo ha sido reescrita. Btfrs puede pausar una operación de balanceo, y posteriormente volver a retomarla donde se dejó. Puede observarse el progreso. También puede hacer "restriping" entre diferentes niveles RAID, es decir, cambiar entre un modo RAID y otro. También permite filtrar la operación de balanceo para que sólo afecte a datos o a metadatos. También permite balancear exclusivamente los grupos de bloques que estén casi vacíos. Las utilidades están disponibles en la rama "parser" de btrfs-progrs.
· Mejor depuración
Btrfs tiene una nueva herramienta de depuración, "integrity check", orientada a desarrolladores. Esta herramienta consiste en escanear cada bloque escrito, y examinarlo para comprobar que las referencias son correctas y consistentes, y que no se está escribiendo nada que pudiera dejar al sistema de archivos en un estado de inconsistencia tras un corte de corriente. Esta herramienta -que tiene unos costes de rendimiento muy altos y no está recomendada para usuarios normales- ayudará a los desarrolladores a encontrar fallos con más rapidez.
3. Open vSwitch: Open vSwitch es una implementación de software de un switch de red. Este proyecto ha existido durante varios años, y ahora se incorpora al núcleo principal. Linux ya tiene un switch virtual (el "bridge"), pero Open vSwitch está diseñado para escenarios más complejos, particularmente para entornos de virtualización (lea el documento "Why Open vSwitch?"
Open vSwitch soporta las interfaces de gestión estándar (sFlow, Netflow, RSPAN, CLI), y está abierto a ser extendido y controlado utilizando Openflow y el protocolo de gestión OVSDB, y está diseñado para ser compatible con los chipsets de switching modernos.Ver openvswitch.org para más información.
4. Mejor vinculación (bonding) de interfaces de red: teaming: Esta versión añade un nuevo driver de red llamado "teaming", cuyo objetivo es ser un reemplazo rápido, escalable, y limpio del driver "bonding". Esta funcionalidad suele utilizarse para vincular dos tarjetas de red y así incrementar el ancho de banda máximo y proporcionar redundancia. En esto momentos están disponibles los modos round-robin y active-backup. La librería de espacio de usuario, junto con un par de aplicaciones de demostración, está disponible en github.com/jpirko/libteam.
5. Luchando contra el bufferbloat: byte queue limit: "Bufferbloat" es un término utilizado para describir los problemas de latencia y tasa de transferencia causados por el excesivo buffering en las diferentes capas de una conexión de red. Se están desarrollando algunas herramientas para ayudar a aliviar esos problemas, y esta característica es uno de ellos.
El "byte queue limite" es un límite configurable de datos que se pone a la cola de envío de paquetes de una tarjeta de red. Como resultado, uno puede tunear cosas como que los paquetes de alta prioridad sean atendidos con una latencia razonable sin tener que vaciar la cola cuando existen datos para enviar. La configuración de estos límites se hace en el directorio de sysfs tx-n de cada tarjeta de red.
6. Límites de buffer TCP controlados con cgroup: Se introduce la capacidad de controlar la memoria utilizada por los buffers del protocolo TCP mediante cgroups (grupos de procesos).
7. cgroup para el control de prioridad de red: El cgroup para el control de prioridad de red permite al administrador configurar la prioridad del tráfico de red para los procesos que son miembros del grupo. En teoría, una aplicación podría configurar la prioridad mediante la opción de socket SO_PRIORITY. Esto, sin embargo, no es siempre posible. Este cgroup permite al administrador asignar un proceso a un grupo y obligarle a seguir la configuración definida. Documentación en Documentation/cgroups/net_prio.txt
8. Mejor redimensionado en vivo de Ext4: Se ha añadido una nueva ioctl y código que permite redimensionar un sistema de archivos Ext4 con mayor rapidez y seguridad. El nuevo redimensionado permite al kernel hacer todo el trabajo, como crear bitmaps y tablas de inodos, puede soportar características como flex_bg y BLOCK_UNINIT, y es mucho más rápido.
9. Nueva arquitectura: TI C6X: La familia de arquitecturas que funcionan en Linux ha aumentado aun más con la incorporación del soporte para Texas Instrument C6X. Esta arquitectura soporta procesadores de la familia C64X de uno y varios cores DSP, sin MMU. Esta arquitectura es VLIW, y tiene un conjunto de instrucciones diseñado para aplicaciones DSP. Para más detalles, vea esta página web de TI. La página del proyecto es linux-c6x.org.
10. Soporte para inicio desde EFI: En esta versión se incluye un objeto EFI que permite que una imagen bzImage x86 sea cargada y ejecutada directamente como una aplicación EFI. Tanto los cargadores BIOS y EFI pueden cargar la misma imagen, permitiendo de ese modo utilizar la misma imagen para ambos casos.
Y eso es todo. La lista completa de cambios en inglés, aquí.
8 de marzo de 2012
Cosas de GNOME
En la blogosfera Linuxera anda corriendo este post sobre la reescritura de la interfaz de la utilidad de discos de Gnome, palimpsest. Y está corriendo por esta frase, que se considera tan representativa del GNOME actual:
Con lo cual se alcanza el meritorio logro de no poder hacer en el escritorio y con una UI algo que si se puede hacer en el instalador de distros como Fedora. ¡Para que luego digan que instalar Linux no es user-friendly!
A estas alturas, no creo que a nadie le sorprenda, claro.
"but we no longer provide any UI to configure LVM or MD RAID itself - you are expected to use the command-line tools to do so yourself"
Con lo cual se alcanza el meritorio logro de no poder hacer en el escritorio y con una UI algo que si se puede hacer en el instalador de distros como Fedora. ¡Para que luego digan que instalar Linux no es user-friendly!
A estas alturas, no creo que a nadie le sorprenda, claro.
Suscribirse a:
Entradas (Atom)