Fedora, yo te saludo

Para que vean que este blog tiene dignidad, voy a renunciar a hablar de la nueva distro de cierto buscador para escribir en su lugar de mi paso a Fedora. Hace 3 años casi exactos que me pasé de Debian a Ubuntu, y ahora repito la historia con otro nombre. No mencionaré el fugaz paso del tiempo, prefiero regocijarme en el avance del progreso.

¿Por qué cambiar? Llevaba ya algún tiempo con la intención. En Fedora colaboran muchos de los trabajadores de Red Hat (y los que no colaboran la usan activamente y mandan parches a través de sus colegas), lo cual significa que varios de los más importantes programadores de software libre mantienen en ella paquetes de su propio software. Ubuntu no es que carezca de personalidades que hagan cosas importantes (pensemos, por ejemplo, en el magnífico upstart), pero no hay tantos como en Red Hat/Fedora, ni de lejos.

Eso marca diferencias. Fedora suele usar versiones muy nuevas de software e incluye features que nadie ha incluido antes; a veces incluyen cosas antes de que sean incluidas en upstream (por ejemplo, mejoras de rendimiento de qemu/kvm que me apetecía mucho probar), pero el mantenedor que te está metiendo esas cosas es el mismo programador que mantiene el código en el proyecto original. Quiero decir que no es lo mismo que usar Debian unstable, donde lo hay una serie de empaquetadores que toman snapshots de un repositorio, y que si se encuentran con un bug serio tienen que esperar a que aparezca un parche en upstream. En Fedora hay menos intermediarios, por decirlo de alguna forma, y como los Red Hateros que colaboran en el proyecto trabajan a sueldo la distro está muy, muy bien atendida y las versiones estables no son en realidad menos estables que cualquiera de Ubuntu, a juzgar por lo que estoy viendo. Aunque hay un detalle importante en esto: Fedora suele centrarse más en el software "base": kernel, gcc, libc, etc; mientras que Ubuntu se centra más en el software del escritorio.

Una vez explicados los motivos, vayamos a las experiencias.

En primer lugar, he aprovechado para pasarme a Btrfs, uno no puede pasarse el santo día hablando de algo y no tragárselo él mismo. Solo mantengo /home y /boot en Ext4, asi que excepto en caso de actualizaciones y uso cotidiano de /tmp/ y /var mi sistema Btrfs se dedica solo a leer datos, que es una función sobradamente sólida para ser usada a diario, y aun si lo usara tambien para /home dudo que tuviera problemas porque está empezando a estar maduro (en 2.6.33 va a ser considerado suficientemente estable para empezar a adoptarlo).

En general, Fedora da la impresión -y digo impresión, porque no se como describir la sensación- de tener peor integración final que Ubuntu, algo comprensible ya que Canonical pone todo su empeño en facilitar las cosas fundamentalmente a los usuarios sin muchos conocimientos, mientras que Fedora parece estar más orientada, por decirlo así, al usuario de Linux que no quiere complicarse la vida pero sabe por dónde se anda. Haciendo analogías con hardware, Fedora es una distro "workstation" -se nota que está hecho por gente que trabaja fundamentalmente en servidores- mientras que Ubuntu es "desktop".

Estas diferencias se notan en cosas puntuales como el acceso a privilegios de root. Fedora sigue teniendo el usuario root con contraseña propia. ¡Y los usuarios normales no pueden utilizar sudo por defecto! Puede que sea apropiado para servidores, pero para el escritorio de una persona creo que el modo de hacer de Ubuntu es suficiente y es mucho más comodo.

Otro aspecto es en la gestión de software: La eterna rivalidad deb vs rpm. Aunque en un principio he notado muchas diferencias, a la hora de la verdad uno se da cuenta de que son meros detallitos, los principios básicos son los mismos. Eso si, yum consume demasiados recursos y, en general, APT y sus repositorios parecen estar mejor organizados. Una cosa que me gustó mucho en Fedora, y quizás sea el segundo factor que más me impulso a cambiar a Fedora, fue la descarga "diferencial" de paquetes (Presto), activada por defecto en esta versión. Nada más instalarlo tenía ya unas cuantas actualizaciones, pero Presto me redujo su tamaño drásticamente, véase este mensaje informativo: "Presto reduced the update size by 84% (from 54 M to 8.9 M)".

Lo que más problemas me dió fue SELinux. Decidí usar mi ex sistema Ubuntu como /home. Mi antiguo $HOME quedaba por tanto en /home/home/usuario/, y, para usarlo cómodamente tambien en Fedora, decidí hacer un enlace simbólico de /home/usuario a /home/home/usuario, así si tenía que volver a Ubuntu por alguna razón, podía hacerlo con tan solo cambiar un parámetro en grub y borrar el enlace simbólico. Esto, que en apariencia parece algo sencillito, resultó ser lo más complicado de hacer, casi un infierno. A pesar de estar los permisos correctos y el enlace simbólico funcionar sin problemas, y a pesar de haber usado chmod -R para cambiar la id de propietario de todos los archivos, resulta que las cosas no tenían el "contexto adecuado", y a pesar de que el enlace era correctísimo, KDM no tenía permiso para acceder al directorio. Sabía cual era el problema, me prefiguraba en la mente como tenían que quedar las cosas una vez solucionadas, pero llegar a dar con los pasos necesarios para arreglarlo fue costosísimo. Me sentí como un novato que llega a Unix por primera vez. Lo peor es que, en realidad, SELinux no es tan complicado: lo peor fue la falta de documentación clara, la ausencia de mensajes de error en comandos que fallaban, y cosas así.

Tuve tentaciones de rearrancar con el parametro "selinux=off", que me hubiera solucionado todos los problemas, pero no lo hice y me alegro, he de decir que estoy encantado con el sistema: cada vez que se produce una falta aparece un popup en el escritorio informandome con detalle del problema y de las posibles soluciones. Pero es cierto que SELinux tiene la gran desventaja de que uno no puede usar un sistema con ello y olvidarse. No es algo transparente, que funcione al margen sin meterse con nadie, al contrario, está presente, se pone en medio a veces, y tienes que convivir con ello, conocer las herramientas más o menos tan bien como los comandos típicos de Unix, y enfrentarte a algún problema de vez en cuando y saber arreglarlo.

La última queja que tengo sobre Fedora es el legal. Bien es sabido que ni Fedora ni Red Hat compilan soporte de NTFS, ni Wine, ni MP3, ni DVD, ni muchos codecs de video, por el riesgo de ser denunciados por infracción de patentes. Son muy estrictos con este tema, y, en mi opinión, hacen bien. Sin embargo, una de estas restricciones afecta a freetype, la librería que hace el antialiasing de las fuentes, varias de las técnicas que se necesitan para renderizar decentemente las fuentes están patentadas, y Fedora las desabilita. En consecuencia, las fuentes en fedora son por defecto horribles. Inusables. Me fastidió mucho que no se ofreciera una solución fácil, o algún paquete alternativo, en Ubuntu se ha facilitado mucho el instalar software propietario e incluso semi-ilegal, y los usuarios lo agradecen, en Fedora no hacen ningún esfuerzo para facilitar nada. Ni tan siquiera tienenmucha documentación para resolverlo. Uno se encuentra con que Amarok empieza a saltar de canción en canción a toda velocidad, sin emitir ningún sonido por los altavoces, y al principio te preguntas si será algún problema de sonido o qué carajo pasará, hasta que recuerdas -porque ya lo sabías antes, sino de qué- el tema de las patentes y googleas hasta dar con una solución. La solución es recurrir a los magníficos repositorios rpmfusion, donde tienen soporte de MP3, DVD e infinidad de codecs, y, por supuesto, una versión de freetype sin las restricciones que tiene Fedora, que mejora la calidad del escritorio una auténtica barbaridad. Más incluso que en Ubuntu, jamás he tenido unas fuentes de tanta calidad en un sistema Linux con tamaños tan grandes (consejo: si quieren hacerse un favor suban un par de puntos el tamaño de sus fuentes y pásense así varios días, comprobarán que las fuentes grandes son agradabilísimas y muy recomendables y que las pequeñas son inaguantables)

Creo que aparte de estas no tengo más quejas, el resto va fenomenal: por alguna razón incluyen un driver Intel notoriamente más veloz que el que tenía en Ubuntu, Btrfs vuela e incluso hace que el disco duro tenga un sonido distinto al habitual y que parece más agradable (caprichos de músico). Se podría decir que en general Fedora es una distro que requiere algunos retoques nada más instalarla pero, una vez hechos, lo cierto es que el resultado me agrada más que mi antigua Ubuntu.

Linux no es tierra para FatELF

El tiempo que pasó entre su anuncio y su desaparición fue tan corto que los trolls casi no tuvieron tiempo de pensar argumentos para las discusiones. A pesar de recordar prematuramente al Titanic, FatELF, la idea de juntar los binarios para varias arquitecturas en uno solo, recorrió todos los blogs y sitios de noticias como la pólvora. Pero al final el barco se ha hundido. No diré que me alegro, porque tampoco es de buenos ateos ser puntilloso, pero este hundimiento se veía venir. Y es que francamente este invento tenía, en la práctica, poco de útil.

Hay muchas cosas que Linux puede copiar de Mac OS X u otros sistemas operativos, pero en lo que se refiere a saber convivir con varias arquitecturas, me parece que es más bien al contrario, que es Linux quien puede enseñar un par de cosas. No se suele oir mucho, pero a día de hoy Linux es el SO con más soporte de arquitecturas, por encima de NetBSD. Además, las soporta además desde hace mucho, desde 1995, asi que desde muy pronto se tuvo que lidiar con los problemas que originaban.

Por ejemplo, los sistemas de archivos de algunos SOs están habituados a funcionar en una sola arquitectura, y si mueves el disco de, por ejemplo, un sistema de archivos UFS creado en un SPARC a un x86, no puede leerse, porque la versión para SPARC escribe los datos en formato big-endian y x86 los lee esperando que sean little-endian, es decir, no puede leerlos. En cambio, los sistemas de archivos de Linux estan diseñados para que un disco pueda intercambiarse entre sistemas diferentes sin problemas: El código está adaptado para transformar desde/hacia un tipo de formato a otro en todas las rutas del código que lean o escriban datos al disco, y los datos siempre se escriben en un solo formato (little endian, generalmente).

Cuando se crearon los sistemas de paquetes en Linux, se diseñaron con soporte de varias arquitecturas. Y el principal argumento en contra de FatELF es este: Que el tema de las arquitecturas ya está perfectamente solucionado en Linux desde mucho antes que a Steve Jobs se le ocurriera cambiar PPC por x86. Para Mac OS X los binarios universales les van bien, claro: su modelo para distribuir aplicaciones no es mediante repositorios, y en el switch de arquitectura fue necesario usar aquel truco del viejo Nextstep para facilitar la transición. Pero en Linux la cosa cambia. Los repositorios se ocupan del problema

Aun quedan los programas "de terceros", ¿qué sería de ellos? ¿No les vendría bien FatELF? Pues dudosamente, empezando con que cualquier programador "de terceros" debería, en principio, hacerlo mediante paquetes, que siempre serán varios debido a la fragmentación linuxera. Ignorando ese punto, tendrían que decidir para cuantas arquitecturas van a compilar: x86-32, x86-64, PPC, IA64, SPARC...puede que no sea necesario preocuparse de muchas de esas arquitecturas por su escasa relevancia, claro, pero ahí está el asunto: ¿de cuales te preocupas, y de cuales no? En Apple está todo claro, porque además de software hacen hardware y se sabe a qué hay que atenerse, pero en Linux todo está muy indefinido.

En el caso de que en Linux necesitaramos distribuir algo con soporte de varias arquitecturas en un solo archivo, resultaría mucho más fácil y lógico (y así se lo he indicado al tipo creador de FatElf en un flamewar, sin recibir respuesta) añadir soporte a RPM/DEB para poder crear meta-paquetes que tengan dentro todos los paquetes de las diversas arquitecturas. El instalador (dpkg/rpm) escogería el adecuado para el equipo en el que se instala y voilá, ya tienes distribución multi-arquitectura en un solo archivo...y sin tocar una sola línea de código del kernel, y evitando tener binarios gigantescos en el sistema para una arquitectura que no se utiliza. No es además nada dificil implementarlo: básicamente se trataría -quizás literalmente- de un archivo tar con varios paquetes dentro.

Si nadie lo implementa es por la simple razón de que a nadie le hace falta. FatELF es una idea en infructuosa búsqueda de un problema que resolver.

Los absurdos escrúpulos de la Comisión Europea

El retraso de la adquisición de Sun por parte de Oracle por parte de la Comisión Europea, para detectar posibles riesgos de monopolio, cada vez me parece más estúpido. No es que un servidor sea de los que creen que a las multinacionales no hay que vigilarlas, pero la vigilancia actual probablemente podría mejorarse.

Entiendo que el trabajo de una comisión antimonopolio no debe ser fácil: tienen que controlar a las multinacionales en una sociedad donde las multinacionales son aceptadas y dominan buena parte de la economía y tienen permitido hacer casi de todo. Los límites de lo que pueden y no pueden hacer son tremendamente difusos, la repercusión mediática es considerable, las presiones deben ser numerosas...

La comisión ha logrado grandes beneficios para la sociedad, como forzar a Microsoft a proporcionar documentación a Samba (que, ojo, está haciendo enormes progresos pasito a pasito), pero en otros aspectos deja que desear. Por ejemplo, forzó a Microsoft a tener una versión de Windows sin Windows Media Player, cuando lo que hacía falta era poder desinstalarlo. El resultado fue que de la versión sin WMP se vendió prácticamente ninguna copia y Microsoft no hizo nada para permitir la desinstalación. Recientemente hemos visto a la Comisión hacer caso de las peticiones de Opera sobre el monopolio IE. Cualquier persona con dos dedos de frente puede deducir, mirando las estadísticas de Firefox, que un navegador puede tener éxito si se lo propone y es bueno. A pesar de que el fracaso de Opera es responsabilidad suya, consiguieron que la Comisión obligara a Microsoft a plantearse lo de aquella ridícula "Ballot Screen"...pero no forzaron a Microsoft a permitir la desinstalación de IE.

Quiero decir con todo esto que me parece muy bien que se aprieten las tuercas a las multinacionales, pero hay que apretarselo en el sentido adecuado, no en el de aflojar. Hacer una versión sin WMP no ayudó a debilitar su predominancia monopolística. Casi nadie quiere usar Opera, por mucho que lo ofrezcan en una pantalla (si lo quisieran ya tendría una cuota decente, como Firefox). Es obvio que la Comisión no tiene ni idea de informática, que no tienen expertos que les aconsejen los caminos idoneos. O les tienen y no les escuchan. Parecen guiarse por términos económicos, "este producto es un monopolio y si hacemos esto la competencia tendrá oportunidades", pero las multinacionales les marean y se marean ellos mismos, y acaban aprobándose soluciones absurdas.

Ahora tenemos el caso de la adquisición de Sun. La Comisión se preocupa, y hace bien, es su trabajo, de cómo puede afectar la compra de la mayor base de datos de software libre por parte de la mayor base de datos propietaria. Hace bien la Comisión al preguntarse si Oracle carecerá de incentivos para mejorar MySQL para hacerse competencia a si mismo.

Pero MySQL es software libre. Como han señalado muchos, Oracle no puede parar MySQL, porque si intentan sabotearla, consciente o inconscientemente, otra empresa -ya han surgido algunas- correrán a llenar el vacío. Los trabajadores de MySQL pueden incluso dejar Oracle y meterse a trabajar en exactamente el mismo código en otra empresa. El software libre no permite crear monopolios (una de las grandes razones por la que muchos capitalistas e inversores no confían en él). No hay, por tanto, miedo de que Oracle acabe con MySQL. No se confundan, es obvio que sería mucho mejor para todos si volviera a ser una pequeña empresa independiente, simplemente no veo razón para creer que la compra pueda derivar en una muerte del proyecto que de pie a un mayor monopolio.

En cualquier caso el proceso regulatorio es lentísimo, lo cual perjudica a todos al retrasarse la decisión final, y sus cada vez impredecibles decisiones dan pie a pensar a los norteamericanos que tenemos manía y miedo a sus empresas. A día de hoy la Comisión es una ruleta ante la cual todo comprador no sabe seguro cual va a ser el resultado, esto no beneficia a Europa en nada. Para decir a Oracle que deben escindir MySQL y convertirlo en empresa independiente no debería necesitarse tanto tiempo.

Upstart

Una pequeña nota para enlazar a este magnífico artículo sobre upstart. Es uno de esos cambios que se ha hecho poquito a poco y sin que la mayoría de gente nos enteremos de qué es y como funciona; en ese artículo lo explican con maestría.

Tiendas de aplicaciones: El panorama linuxero

Despues de escribir sobre la posible generalización de las tiendas de aplicaciones en todas las plataformas debido a sus ventajas económicas, solo queda examinar cómo se enfrente Linux a este fenómeno.

Mucha gente ha dicho, yo tambien, que las App Stores son una imitación de los sistemas de gestión de paquetes de Linux como APT y Yum. Hay que reconocer que, en gran medida, son exactamente eso. Ubuntu lleva ya un tiempo con una aplicación gráfica donde el usuario puede instalar miles y miles de aplicaciones a golpe de click.

Al ser, además, parte integral del sistema, tambien gestionan las actualizaciones no solo de las aplicaciones sino del software del propio sistema. Eso hace, entre otras cosas, que las actualizaciones entre versiones de una distro sean -en mi opinión- mucho más fiables que en otras plataformas, que sin bien pueden actualizar entre versiones sin demasiados problemas, lo hacen a ciegas, blandiendo la espada y dejando que Dios reconozca a los suyos. En una actualización importante de una distro Linux puedes tener un problema de dependencias debido, por ejemplo, a algún paquete instalado a mano. O a un paquete rebelde de algún repositorio no prioritario. O cualquier otro problema. Pero eso tambien forma parte del concepto de fiabilidad: Hay un problema y el sistema te lo señala claramente, y te dificulta y hasta prohibe actualizar hasta que no lo resuelvas; intenta, en resumen, impedir que el sistema entre en un estado indefinido, trata de evitar el problema antes de que ocurra. Hay gente que maldice los gestores de paquetes de Linux y su sistema de dependencias, pero no se dan cuenta de los problemas posteriores que evitan.

Hay muchas razones para amar nuestros gestores de paquetes; suponen un adelanto de 10 años (apt 0.0.1 nació el 31 de Marzo de 1998) al App Store de Apple. Durante este tiempo han supuesto un inconveniente para la distribución de software a base de programas individuales, pero si el modelo de los repositorios se generalizara, sería algo del pasado. Seríamos, por tanto, unos pioneros en el tema.

Sin embargo, no todo es tan bonito. El App Store es algo más que un mero repositorio. Como decía en el artículo anterior, en realidad es un supermercado que permite ejercer los mecanismos de oferta y demanda. Es un lugar virtual para ofrecer productos y pagar cómodamente por ellos. Los sistemas como APT son ajenos a eso, no se pueden comprar ni vender aplicaciones, no son un mercado, y por lo tanto los programadores no tendrán ningún incentivo para poner programas de pago en ellos, tendrían que construirse su sistema anticopia y de cobro online.

La cuestión, claro, es si Linux quiere o debe crear un mercado de aplicaciones. Choca frontalmente con el concepto de software libre. Desde ese punto de vista, APT no necesita ni permitir cobrar ni permitir vender aplicaciones. Además, aunque se permitiera la existencia de ofertas comerciales, la orientación del software libre tiende a reemplazar toda oferta comercial con alternativas libre, asi que quedarían pocos resquicios para construir aplicaciones por las que la gente esté dispuesta a pagar dinero. Asi que Linux en principio no necesita tal sistema...para pagar por aplicaciones.

Otra cuestión es la de pagar por otros servicios, como video, música, o cualquier otra cosa. Si la compraventa tiene dificultades en Internet, y si la solución es crear un sistema que permita a la gente pagar/cobrar dinero de/a su cuenta fácilmente, la ausencia de tal sistema para Linux supone una desventaja que solo una empresa basada en web 2.0 y protocolos abiertos, como google, podría suplir.

Un detalle importante que Linux puede aprender de las tiendas de aplicaciones es la barrera de entrada. En la App Store, un desarrollador puede registrarse, pagar su cuota de 99$ y subir su aplicación en relativamente poco tiempo; tras una revisión, Apple decide si la incluye, si hay algún problema serio con ella no la acepta o la borra cuando lo detecta. El proceso es relativamente sencillo. Sin embargo, para poder incluir una aplicación en un repositorio como los de Ubuntu o Debian hay que convertirse en desarrollador de la distro y atravesar un intrincado laberinto de burocracia. No se diferencian a los mantenedores de la distro y a los que quieren subir y mantener una pequeña aplicación, aunque ésta sea libre. Esto desalienta que, por ejemplo, alguien de Facebook suba y mantenga un programa para acceder a su página, o que un desarrollador de cierta aplicación libre suba y mantenga su aplicación en los repositorios de Ubuntu o Debian: siempre hay que esperar a que lo haga un mantenedor.

Tal vez fuera útil que las distros como Ubuntu y Debian concibieran una nueva clase de colaborador, un colaborador que no pretende ser desarrollador de la distro sino mero mantenedor de un pequeño programa, que pueda empezar a hacerlo fácil, casi automáticamente, que todo lo que haga no pueda afectar más que a su paquete, que haya un sistema para borrar su aplicación si su programa comete alguna infracción. Los repositorios PPA de Ubuntu son un gran paso en ese sentido, pero quizás haga falta algo más.