D'Oh!

Los absurdos escrúpulos de la Comisión Europea

2009-11-06T15:00:00.000+01:00

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

2009-11-04T19:10:00.000+01:00

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

2009-11-02T18:00:00.001+01:00

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.

Tiendas de aplicaciones: "¡Es la economía, imbécil!" (dos de tres)

2009-10-29T20:00:00.003+01:00

En el post anterior decía que debía ser muy ventajoso para los programadores de iPhone disponer de algo como el App Store que les alivie la carga de la distribución y el cobro de sus programas. Aunque registrarse como desarrollador de iPhone cuesta 99$ por año -que no es poco-, el darlo todo hecho ha facilitado que hordas de desarrolladores se hayan animado a unirse a la tienda. Si esos mismos programadores tuvieran que molestarse en mantener por ellos mismos todo lo que la App Store les da hecho quizás no programarían nada. Muy pocas personas se molestarían en dar su número de tarjeta de crédito en una web perdida para comprar una mísera aplicación de, pongamos, 3.99$. Pero en el iPhone es mucho más fácil conseguir compradores, y eso anima a muchos programadores -que, recordemos, también pueden ser empresas- a probar suerte.

La sociedad siempre acude en masa al mercado en el que se puede ofrecer y demandar cosas tranquilamente; nada puede evitar que los compradores hagan ofertas por las cosas que desean poseer, y siempre habrá productores que intentarán satisfacerlos para enriquecerse. En Internet sin embargo hay una serie de barreras que impiden que los consumidores puedan ofrecer cómodamente su dinero, y pedirlo los productores. Existe el cobro contra reembolso, existe el cobro a una tarjeta de crédito, existe el pago previo a una cuenta bancaria, pero excepto en casos particulares y cosas como Paypal, ninguna ha calado como verdadera alternativa virtual de intercambio de bienes y servicios por dinero.

Se oye con frecuencia que en Internet las cosas son gratis, y que así es como seguirá siendo, porque es lo que pide la gente, y a cada idea útil de pago le saldrá siempre una alternativa gratuita que la echará abajo. Que las cosas han de financiarse como mucho con anuncios. Se trata de afirmaciones cuya falsedad será demostrada -en mi opinión, y para bien o para mal- con el tiempo. Internet no es menos propicio para los negocios que la tienda de la esquina, más bien se trata de que aun no disponemos de un sistema cómodo para hacer transacciones comerciales, y recurrimos a los anuncios como alternativa-para-todo.

Mucha gente aun se sorprende de que los usuarios de iTunes/iPod paguen por la...¡música!, que a pesar del aumento de la velocidad de las líneas de conexión y disminución proporcional del tiempo necesario para bajarse un álbum (la discografía de Joan Manuel Serrat completa, que son una cantidad horripilante de discos, ocupa 2.54 GB, la mitad que un DVD), de las mejoras alucinantes en tecnología P2P y de la expansión de los sitios de descarga directa, las ventas de esa tienda no hayan sino aumentado. No se debe más que a la creación de un mercado, a que Apple ha facilitado, en la medida de lo posible, el pago por Internet. Una vez introducida la información de la cuenta bancaria, el usuario pasa a tener una interfaz donde se le ofrecen varias cosas, se informa de su precio y se permite comprarla a golpe de clic.

Los usuarios de iTunes -o de otras tiendas- que compran música no lo hacen porque Steve Jobs les haya lavado la cabeza o porque sean unos ricachones, lo hacen porque pueden, porque se les hace una oferta y se les ha facilitado poder responder a ella. Y si gran parte del resto de Internet no paga ni un céntimo por su música -o por las noticias de su periódico- no es porque deseen que "todo sea gratis" -¡obviamente, todos querríamos que todo en este mundo fuera gratis!-, sino porque nadie les ha dado oportunidad de hacer una pequeña oferta por conseguirlo a cambio de algo. Quieren disfrutar de las ventajas de bajarse música por Internet, pero se les ha dificultado enormemente pagar por ello, se les incita a recurrir al intercambio P2P (que por otra parte no tiene nada de malo, en mi opinión).

En el caso de App Store, no solo se facilita al usuario la compra, sino que se le facilita al programador la venta. El App Store es un gran centro comercial, y no metafóricamente sino en el sentido literal, en el que la oferta y la demanda reinan con casi absoluta libertad. Los programadores colocan sus aplicaciones en los estantes, suben o bajan los precios durante un par de semanas para observar si las variaciones en la demanda mejoran las ganancias, algunos de quienes no sean capaces de obtener más del 99$ por año que cuesta la suscripción probablemente acaben retirándose de su estante, los consumidores gastan el dinero a su antojo. Un verdadero centro comercial, de comercio de aplicaciones por las que la gente está dispuesta a pagar determinados precios.

Gran parte de la explosión de actividad en la App Store se origina por estos motivos (no toda obviamente: hay muchísimas aplicaciones gratuitas). Al mismo tiempo, esto convierte a Apple en el poseedor de una de las bases de datos más codiciables de Internet. No existe ninguna otra empresa que posea una lista de clientes y sus cuentas de banco más extensa, ni un centro comercial mejor acondicionado que iTunes. Lejos de la imagen de vendedor de hardware, Apple posee uno de los grandes valores de Internet. A día de hoy venden música, películas, y ofrecen estantes a los programadores de aplicaciones para iPhone, pero eventualmente puede ser extendido a la compraventa de cualquier producto digital. ¿Por qué no iba a ser el próximo paso la compraventa de aplicaciones para toda la gama Mac? Creo firmemente que eventualmente Apple lo hará. "Yo también sé jugarme la boca".

El próximo y último artículo sobre tiendas de aplicaciones se titulará: "Tiendas de Aplicaciones: El panorama linuxero".

Tiendas de aplicaciones: próximamente en sus escritorios (uno de tres)

2009-10-26T23:30:00.001+01:00

La App Store del iPhone es todo un fenómeno que cada vez me llama más la atención. Todos la están imitando, y esas cosas no ocurren sin que haya una poderosa razón para ello. Amenaza incluso con extenderse a todos los escritorios y convertirse en algo imprescindible y en la manera de distribuir software. Y para que vean que a este blog le queda mucha cuerda, he acumulado verborrea suficiente como para hacer tres post sobre el tema.

A primera vista la razón de su éxito está en lo cómoda que es para los usuarios, pero como me han señalado aquí alguna vez (Google dice que Javi Santana, que por lo visto conoce el campo), una gran parte está en lo fácil que se lo pone al desarrollador para crear aplicaciones. Sin esa facilidad, no habría tantas aplicaciones, sería como entrar en un supermercado y ver casi todas las estanterías vacías. Y la App Store tiene las estanterías repletas (a pesar de su puritanismo, que ha retirado más de una aplicación de los estantes).

Tambien debe ser un factor muy importante lo fácil que lo tiene el programador para distribuirlas. No hay que tener una página web para que los usuarios descarguen nada (aunque es muchos lo hacen incluyendo un enlace a la página de la aplicación en itunes), con el ahorro del tedioso trabajo que esas cosas siempre implican. Y no olvidemos la enorme facilidad para cobrar. No tienes que pedir un número de tarjeta de cŕedito a nadie, ni enredar con paypal, ni con divisas (las tiendas online no aceptan cualquier tipo de moneda), ni nada parecido, el desarrollador da su número de cuenta a Apple y ellos se encargan de cobrar al cliente y meterte el dinero en el bolsillo. Estas dos cosas, que parecen caprichosas, son más importantes de lo que parecen.

Resumiendo, Apple pretende que los programadores se ocupen de programar -que no es poco- y el resto tratan de resolvertelo ellos.

La App Store parece acertar tan bien a conjugar necesidades de usuarios y desarrolladores, que se me hace imposible concebir que Apple no esté considerando extenderla al escritorio. ¿Por qué no? ¿Por qué no distribuir aplicaciones de escritorio a través de una App Store, incluso las gordas y de pago, como Photoshop? Por supuesto, se trata de un planteamiento distinto al iPhone, los Mac de sobremesa no están -afortunadamente- bloqueados para prohibir la instalación de cualquier tipo de aplicaciones. El crackeo de software de pago sería inevitable, pero ¿es que acaso no lo es tambien ahora? Quien quiere crackear un programa de pago lo va a hacer igualmente; una App Store al menos incentiva la compra.

Creo que las "tiendas de aplicaciones", tanto en su lado atractivo para el usuario como en su comodidad para los desarrolladores, son algo destinado a imponerse poco a poco en todos los ámbitos, se tratan de "un paso más" en la oferta de las plataformas de la que a largo plazo nadie querrá carecer.

¿Que hará Microsoft? Al igual que resto de SOs móviles, tienen su tienda "Skymarket" crecida a la sombra de App Store. Lo curioso es que Microsoft tiene tambien ¡una tienda online para escritorios! Pero es solo para productos propios. Venden cosas como...Windows (lo que todo usuario de Windows quiere, comprar otra copia de Windows). Nada que ver con lo que andamos hablando. Es muy curioso: Microsoft debe gran parte de su fortuna a lo fácil que ha puesto siempre el desarrollo de aplicaciones a partners y los famosos "3rd party". Lo de "Developers, developers, developers" es algo más que un chiste, es una religión en esa empresa. Win9x debe mucho de su éxito a haber sido una gran plataforma sobre la que crear aplicaciones que funcionaban -siguen funcionando- en millones de ordenadores. Lo lógico sería que siendo uno de sus distintivos, vieramos en Microsoft más ímpetu por adelantarse, por ser los primeros en ofrecer, como siempre han ofrecido, la mejor alternativa para los programadores.

Pero no, la obsesión por atender a los programadores parece cosa del pasado, de la antigua Microsoft. La nueva Microsoft, encabezada por Ballmer, está demasiado ocupada añadiendo búsquedas en Twitter a Bing, o anunciando la enésima soplapollez basada en .NET, de esas que son inútiles para el 99% de desarrolladores y aplicaciones existentes. Demasiado ocupados intentando ser las reinas del Web 2.0, están descuidando su (innegable) corona actual como mejor plataforma para desarrollar. Mientras tanto, Apple ha descubierto que una App Store puede desafiar a la aparentemente inevitable tendencia Web 2.0 y conseguir reactivar el desarrollo de aplicaciones en código nativo, justo cuando nadie daba un duro por ellas. Pero de eso más en el siguiente post, que si las musas no cambian de opinión se titulará: "Tiendas de aplicaciones: ¡Es la economía, imbécil!"

¿Reusar o reescribir?

2009-10-14T22:00:00.002+02:00

La lectura del informe trimestral sobre el estado de FreeBSD me ha dejado unas dudas. Para empezar ahí se describen tareas absurdas para ese proyecto, como dedicarse a reescribir con licencia BSD utilidades Unix típicas de GNU. Me dirán que en Linux se ha hecho lo opuesto varias veces, y tendría que darles la razón. Pero se supone que los Linuxeros y los GNUeros somos los zealots, mientras que el sentido práctico siempre fue más característico de los BSDeros.

Luego tenemos la tarea de utilizar Clang en lugar de GCC. Clang es un frontend equivalente a GCC pero basado en LLVM, que está licenciado con licencia BSD. El mundo BSD lleva tiempo librarse de uno de los iconos del mundo Linux, gracias a LLVM su sueño está a punto de hacerse realidad. Aunque se muevan por el mismo deseo de librarse de la GPL, en este caso puede decirse que no se trata de una decisión del todo estúpida, puesto que tienen ciertas ventajas.

En última instancia, encontramos el port de ZFS. Aunque ha sido aceptado sin problemas, me consta que entre los más radicales BSDeros hay varios a los que no les gusta demasiado. No porque no les guste ZFS, sino porque no tiene licencia BSD, y si el tema de la licencia causa sarpullidos cuando se trata de herramientas de espacio de usuario, imaginen en algo que forma parte del kernel. Y aun peor, porque no se trata de un drivercillo ni una herramienta de depuración y análisis como Dtrace, sino un sistema de archivos, que es una pieza clave de todo sistema operativo y en especial de Unix.

A los problemas de licencia hay que añadir otro, más grave en mi opinión. He visto a BSDeros glorificarse ante los usuarios de Linux el disponer de ZFS y Dtrace. Técnicamente su orgullo está plenamente justificado, pero creo que a quien realmente glorifican, sin darse cuenta, es a OpenSolaris. ¿Qué es FreeBSD? ¿Que lo distingue del resto de SOs? Fundamentalmente, un kernel y unas herramientas y documentación y APIs de bajo nivel, bien empaquetados como un solo SO, el resto de software -apache, mysql, python, gnome, x.org- no es distinto de lo que uno puede encontrar en Linux o incluso en Windows en muchos casos. Si apartamos ponemos ZFS a FreeBSD tenemos algo que objetivamente es mucho mejor, pero ya no tenemos FreeBSD, sino OpenSolaris.

Y este es el gran problema de FreeBSD: la debilitación y progresiva pérdida de las señales de identidad que le distinguen en el mundo. Usando ZFS en vez de UFS, usando Dtrace, al final lo que estamos usando es a apache, mysql, python, gnome, x.org, sobre algo que forma parte de OpenSolaris, asi que lo más lógico es que la gente acabe usando el OpenSolaris original en lugar de un SO que se ha convertido en un mero clon suyo.

En mi humilde opinión, FreeBSD como proyecto debería centrarse en tratar de mejorar -"reescribir"- las facetas que lo hacen único, y no perder tiempo en el resto -"reusar"-. Ahora está haciendo lo contrario: reusar en su core el código de otros, y reescribir herramientas básicas que no le distinguen de nadie. Lo mejor es que no necesitan empezar de cero: pueden partir de Hammer, el sistema de archivos de DragonflyBSD (que por sus lazos no puede considerarse un SO totalmente distinto de el, y por tanto considero que no puede hablarse de "reutilización"). Quizás no esté tan preparado para sustituir a UFS (en realidad Hammer es un sistema de archivos orientado estríctamente a servidores), pero al menos lo distinguen del resto. De no hacerlo, corren, a largo plazo, serio riesgo de desnaturalización, si los biólogos me permiten el mal uso del término utilizado para designar el proceso de pérdida de estructura de las proteinas.

Nokia se encadena a QT

2009-10-01T17:30:00.003+02:00

Lo que se preveía y se rumoreaba ha acabado siendo cierto: Tras dormir un buen rato sobre la fria losa de la realidad Nokia ha decidido escuchar a los desarrolladores, que están diciendo que "developing for Nokia platforms sucks". Y en ese artículo enlazado se esclarece la solución que Nokia propone a sus desarrolladores: usar Qt. Si, la misma Qt que usa KDE.

Esto implica que, a largo plazo, Symbian está tan vivo como la carrera política de Francisco Camps (nula, para los que viven al otro lado del Atlántico y no saben quien es ese personaje). Nokia liga así su plataforma de software a Qt y se desliga de la batalla perdida de los sistemas operativos. Puesto que Qt permite desarrollar aplicaciones multiplataforma con facilidad, los desarrolladores deberían (en teoría, ya saben como son estas cosas en la práctica) poder diseñar aplicaciones que puedan funcionar tanto en Maemo como en Windows CE o incluso iPhone. O, al menos, debería ser posible hacerlas funcionar optimamente en cada plataforma con relativamente poco trabajo.

Queda por ver si Nokia es capaz de crear una plataforma de desarrollo y de distribución y compra de aplicaciones tan bien montada e integrada como la de Apple, pero de momento para empezar ya tienen un buen toolkit (que visto por encima sin duda es mas "limpio" que lo de Android y Palm, y visto por debajo dudo mucho que Android y Palm puedan acercarse ni tan siquiera remotamente a la amplitud de funciones de QT)

Las consecuencias para el software libre pueden ser más que considerables. En primer lugar, queda clarísimo cual es el futuro de Qt, que había quedado en entredicho tras la adquisición de Trolltech. Se dudaba de si iban a continuar invirtiendo en mejorar el toolkit. Con esta noticia se puede asegurar que no solo van a continuar invirtiendo, sino que van a invertir muchísimo más que antes, al pasar a ser Qt un elemento clave en el negocio de Nokia, que es una multinacional con mucho interés en recuperar su puesto dominante en el sector.

Los beneficios para KDE y Linux son obvios: Hay muy buena relación entre QT y KDE, de hecho bastantes programadores de QT han sido captados por su trabajo en KDE, aun siguen manteniendo partes del proyecto, en algunos casos son importantes mantenedores. No es sorpresa que ciertas mejoras en QT se hagan a veces pensando en KDE. Y en Nokia no ignoran las posibilidades que este escritorio ofrece, un buen ejemplo es este visor de documentos para maemo, basado en Koffice 2. Vaticino una edad de oro para los fieles de la K. Pero no solo para los KDEeros; recordemos que QT se puede usar tambien para aplicaciones de consola, aunque no haya tantas como podría haber, debido a la restricción de licencias que aplicaba Trolltech y que, recordemos, Nokia ya ha eliminado, relicenciando el toolkit entero bajo la LGPL, la misma licencia que usa GTK.

No se a ustedes, pero a mi una de las cosas que más me disgusta de Linux como plataforma de desarrollo es que para juntar una aplicación haya que recurrir a veces a varias librerías distintas, cada una con diferentes estilos de programación, diferentes lenguajes, bindings, diferente documentacion, diferentes fechas de estabilización, diferentes maneras de gestionar el proyecto, los bugs reportados, herramientas de desarrollo, etc. Ni falta hace decir que a cualquier programador venido de Windows o Apple, el desarrollo para Linux suele parecerle un caos. Siempre admiré a OS X por tener en Cocoa una solución unificada "para casi todo", ni tan siquiera Windows está tan unificado ahora que Microsoft ha dividido (estúpidamente) su imperio en dos con .NET. Nokia querrá hacer de Qt su propio Cocoa, y conseguirá al mismo tiempo que Linux tenga un buen competidor de Cocoa, de ese modo Qt podría convertirse en una gran plataforma para desarrollar aplicaciones Linux, la plataforma de desarrollo que siempre se ha dicho que nos faltaba para atraer la atención de otros programadores.

(Ya se que este post apesta a excesivo optimismo, pero seguramente ustedes no sean tan malvados como para reprocharme el ser optimista, ¿verdad?)

Haciendo dinero con Linux

2009-09-28T20:00:00.002+02:00

¿Cuántas veces no se ha afirmado que con el software libre no se puede hacer negocio? Aun se pasa algún despistado por aquí afirmandolo en los comentarios. Me pregunto como se explicarán estos resultados de Red Hat: Un aumento de las ventas del 11% y de los beneficios del 36.9%. En plena crisis. Para ser un negocio del que es imposible sacar dinero, no está nada mal.

¿Cómo es posible que en plena crisis la gente siga insistiendo en gastarse dinero en Linux, y mucho menos en Red Hat, que no se conforman precisamente cuatro duros? Quizás la mejor explicación la haya dado hoy Michael Tiemann, fundador de Cygnus, la empresa especializada en GCC que Red Hat compró en 1999: "Todo se reduce a mi creencia en que los mercados libres son el mejor modo de hacer funcionar una economía, y si sabes hacer algo de una manera mejor, debe ser posible conseguir hacerlo rentable y exitoso". Un corolario a esta frase es que si Red Hat está mejorando sus resultados, es porque sabe hacer algo mejor que los demás.

Es muy significativo que de los 30 contratos que dicen haber firmado en el trimestre anterior, 23 incluyan virtualización, a pesar de que hacer poquísimo que anunciaron la primera versión con soporte de KVM, RHEL 5.4. Aquí Red Hat tiene una gran ventaja, y es que puede ofrecer KVM como parte dentro de un contrato más amplio que incluya otras cosas. VMware es el rey de la virtualización, pero no tienen un SO. Si uno echa un ojo de vez en cuando, comprobará que los del sombrero rojo están poniendo toda la carne en el asador en lo que concierte a cosas relacionadas con la virtualización, asi que cabe esperar grandes alegrías y esperemos que mucho dinero para Red Hat, Novell y compañía.

Parece que el tal Jim Whitehurst, el CEO de Red Hat, está montándoselo bastante bien.

Como curiosidad al margen de este post, me han pasado el enlace a esta fantástica página: inudge.net, donde se pueden hacer melodías simples y compartirlas en plan 2.0. Para que no se quejen de que este blog es aburrido, aquí pueden escuchar una melodía psicodélica de un servidor, en la que comprobarán los destrozos que puede ocasionar ser fan acérrimo de Mike Oldfield (silenciando todos los instrumentos excepto el primero, el azul, suena remotamente a música de videojuego). De lo más entretenido que he visto en muchísimo tiempo.

Btrfs: Una jungla de B-Trees

2009-09-24T00:00:00.005+02:00

Este artículo describe la estructura interna de Btrfs, enfocado en su B-Tree y en como ha sido combinado en muchas y variadas formas para llegar a implementar la funcionalidad completa de un sistema de archivos de última generación. El texto es largo, pero bastante completo.

Introducción

Btrfs es un alias de "B-tree filesystem". La referencia a los B-trees podría parecer poco importante, los sistemas de archivos (en adelante SdA) y bases de datos los utilizan desde hace décadas. Pero no es casual que Btrfs tenga ese nombre, su estructura está muy influenciada por este concepto y, en realidad, es la característica que mejor lo define y diferencia de otros SdA, incluso de ZFS.

Siendo más concretos, Btrfs no implementa un B-tree tradicional, ya que son poco apropiados para técnicas de COW y snapshots y requerimientos de escalabilidad. ZFS optó, debido a ello, por una técnica inspirada en el slab. Btrfs no ha ido por el mismo camino, escogió otro a raiz de una conferencia para desarrolladores de SdA Linux celebrada en Febrero del 2007. Allí, un tal Ohad Rodeh, trabajador de IBM en sus laboratorios de I+D en Israel, presentó un nuevo tipo de B-tree optimizado para técnicas de COW y snapshots con escalabilidad y snapshots muy eficientes -tanto en términos de tiempo como de espacio-. De hecho presentó sus algoritmos como una ayuda para aquellos interesados en crear algo equivalente a ZFS/WAFL en Linux. Chris Mason, que había trabajado en Reiserfsv3, tomó nota y e implementó esa técnica, y de ahí el código evolucionó hasta convertirse en Btrfs. Queda claro que para comprender cómo funciona Btrfs hay que comprender cómo funciona su B-tree.

El B-tree: nodos e ítems

Los B-trees utilizados en SdA solamente almacenan datos en las hojas del extremo del árbol, concretamente en los ítems. Cada hoja puede contener varios ítems. El resto de nodos solo se utilizan para crear rutas hacia los ítems. Todos los B-trees se ordenan respecto a una clave, la que el programador decida, en el caso de Btrfs es esta:

struct btrfs_key {
u64 objectid;
u8 type;
u64 offset;
}

El primer campo, objectid, de 64 bits, es un identificador de objecto, único para cada objeto (pero un objeto puede estar compuesto por varios ítems, asi que puede haber varios ítems con el mismo objectid). Luego tenemos type, de 8 bits, que indica el tipo de item, es decir, el tipo de datos que contiene. offset indica una posición dentro del SdA (su uso concreto depende del tipo de ítem).

Tanto los ítems como los nodos tiene esta clave, sin embargo, ya se dijo que los nodos solo crean rutas hacia los ítems, por lo que a la clave solo añaden un puntero de 64 bits que indica dónde se encuentra el siguiente nodo/ítem en la estructura. Los ítems por su parte a la clave añaden alguna cosa más:

struct btrfs_item {
struct btrfs_key key;
u32 offset;
u32 size;
}

La clave tan solo identifica al ítem, no es el ítem en sí. En esta estructura se indica, en offset, la localización del ítem en la hoja del B-Tree, y en size su tamaño. Este offset es distinto del offset de la clave, que indicaba una posición absoluta en el SdA. Así es como se agrupan en una hoja los ítems:

[Struct Item0 | Struct Item1 | Struct Item2 | ... |Item2    |Item1 |Item0          ]

El espacio entre paréntesis representa una hoja del árbol. Como se ve, las estructuras que describen los ítems (struct btrfs_item) se agrupan al principio del bloque, y el item de verdad, cuyo tamaño varía dependiendo del tipo de objeto, se encuentra al final, esa localización es la que indica el offset de la estructura btrfs_item. Esta organización responde a motivos de eficiencia. Un detalle curioso es que en el caso de archivos pequeños, los ítems correspondientes al archivo almacenan los datos directamente en el ítem (idea derivada del "tail packaging del reiser v3), permitiendo así un acceso rápido a archivos pequeños.

Esta es una descripción quizás más detallada de lo necesario. Como resumen, lo único que hay que tener presente por encima de todo es que se trata de un B-Tree cuyos ítems se identifican con un identificador de objeto objectid de 64 bits y cuyo formato es especificado por el campo type.

Btrfs utiliza este B-Tree para almacenar todo tipo de cosas en forma de ítems: inodos, atributos extendidos, directorios, snapshots...cada elemento con un objectid independiente y un type que indique lo que son. Esto simplifica la implementación del SdA, pues cualquier operación termina siendo una búsqueda, inserción, modificación o eliminación de ítems de un B-Tree. El código se encuentra en el archivo fs/btrfs/ctree.c, y se encarga de hacer todas las modificaciones de bajo nivel, de rebalancear el árbol cuando es necesario, de aplicar COW, etc, todo automáticamente, sin que las otras capas del SdA tengan que preocuparse de ello.

Un bosque de B-trees: Root B-Tree

Una vez que se conoce el B-Tree, entender el funcionamiento de Btrfs es relativamente simple, solo hay que comprender las ramificaciones y combinaciones de sus conceptos básicos.

Todo SdA tiene un superbloque, es la primera estructura que se lee y la que describe las ubicaciones de todas las demás. Es tambien la única que tiene una localización fija en el disco, todas las demás pueden estar en cualquier parte. El superbloque tiene el formato de la estructura struct btrfs_super_block, que no se muestra aquí debido a su extensión. De sus campos destacaremos csum, que al igual que el csum de struct btrfs_header sirve para detectar corrupción. Y los mas importantes: root y chunk_root, de 64 bits, que indican la localización de dos B-Trees.

¿Dos B-Trees? Si, Btrfs tiene varios. De hecho, el B-Tree root es en realidad la raiz de raices, un árbol que almacena punteros a otros árboles. Actua, por así decirlo, como una especie de directorio de B-Trees.

Una gran ayuda para entender más visualmente Btrfs es la herramienta btrfs-debug-tree, que muestra la estructura del árbol. En el caso de Root tree la salida de btrfs-debug-tree correspondiente es:

root tree
leaf 29364224 items 9 free space 2349 generation 7 owner 1
fs uuid 56650d3d-a7bf-463c-a59f-fc87a454d47e
chunk uuid e7457d2d-b783-4cb1-9f43-aa4843ab02fd
  item 0 key (EXTENT_TREE ROOT_ITEM 0) itemoff 3756 itemsize 239
      root data bytenr 29368320 level 0 dirid 0 refs 1
  item 1 key (DEV_TREE ROOT_ITEM 0) itemoff 3517 itemsize 239
      root data bytenr 29372416 level 0 dirid 0 refs 1

En la primera línea se indica que es el Root tree, la segunda indica el comienzo de una hoja, el número total de ítems que contiene y el espacio libre que le queda para albergar más, y otros datos irrelevantes. La tercera y la cuarta indican las UUIDs del SdA y del Chunk tree (hablaremos de él más adelante). Tras ellos, los ítems. Los datos de la clave son los que están entre paréntesis, y a continuación de éste, el tamaño del ítem y su offset dentro de la hoja. Centrándonos en la clave, presentada en formato (objectid, type, offset), vemos que ambos ítems son de tipo ROOT_ITEM (un tipo de ítems que almacenan información sobre la ubicación de otros B-Trees), y sus objectid indican el tipo de árbol, Extent tree y Device tree respectivamente. Esos objectids presentados en forma de constantes pertenecen a unos rangos reservados. El offset, como vemos, no se utiliza. En la segunda línea de cada item, vemos el texto "root data bytenr", que quiere decir "byte donde se encuentra el inicio del B-Tree". El resto de datos se pueden obviar.

Device Tree

Btrfs no utiliza todo el espacio de un dispositivo tras añadirlo al SdA, sino que utiliza una parte y, según va requiriéndolo, recurre al resto. El Device tree, escogido a propósito del ejemplo anterior, sirve para almacenar información sobre qué partes del dispositivo están siendo utilizadas. Por razones que veremos más adelante, este espacio utilizado no se describe como un solo rango, se divide en varios rangos más pequeños, uno trás de otro. Estos son los ítems.

device tree key (DEV_TREE ROOT_ITEM 0)
leaf 29372416 items 7 free space 3484 generation 5 owner 4
fs uuid 56650d3d-a7bf-463c-a59f-fc87a454d47e
chunk uuid e7457d2d-b783-4cb1-9f43-aa4843ab02fd
  item 0 key (1 DEV_EXTENT 0) itemoff 3947 itemsize 48
      dev extent chunk_tree 3
      chunk objectid 256 chunk offset 0 length 4194304
  item 1 key (1 DEV_EXTENT 4194304) itemoff 3899 itemsize 48
      dev extent chunk_tree 3
      chunk objectid 256 chunk offset 4194304 length 8388608
  item 2 key (1 DEV_EXTENT 12582912) itemoff 3851 itemsize 48
      dev extent chunk_tree 3
      chunk objectid 256 chunk offset 12582912 length 8388608

Los ítems tienen claves con el type DEV_EXTENT (alias de "extent de dispositivo", o sea, rango continuo de bloques en un dispositivo). Su objectid es el identificador de dispositivo al que se hace referencia, que es 1 para el primer dispositivo. Este extraño uso del objectid clarifica cómo usa Btrfs sus diversos B-Trees: Cada uno se utiliza de una forma distinta, o más bien, cada árbol utiliza solo unos tipos concretos de ítems relacionados con su función. El offset indica la parte del disco que se quiere describir, y en los datos del item se indica el tamaño que abarcará esa parte (length), además de repetirse el offset(chunk offset). La primera línea tras cada ítem puede pasarse por alto.

Chunk Tree

El Chunk tree ya se mencionó antes, era aquel cuya posición está especificada en el campo chunk_root del superbloque. Su función es traducir entre el direccionamiento lógico del SdA y el direccionamiento físico del disco. Esto es necesario y se hace en todos los SdA: consideremos un SdA creado en una partición que se encuentra en la mitad del disco, su byte cero podría ser el byte 100.000.000 del disco. En Btrfs esa diferenciación es aun más necesaria, ya que un SdA se expande a varios discos simultaneamente, cada uno con su propio direccionamiento físico.

Es debido a esta función de traducción de direcciones lógicas a físicas que la ubicación del Chunk tree se encuentre en el propio superbloque: para encontrar la ubicación física del Root tree es necesario leer primero el Chunk tree. ¿Y la dirección del propio Chunk tree? Tambien se expresa en direcciones lógicas, asi que el superbloque duplica en su estructura una pequeña parte de información para poder encontrarlo.

Decíamos que el Chunk tree mantiene esas equivalencias lógico<->físicas no en forma de un solo gran rango, sino dividido en trozos (chunks, en inglés). Esos chunks suelen tener entre 256MB y varios GB. ¿De dónde se saca información sobre las direcciones físicas de los dispositivos? Del Device tree, naturalmente. Ya dijimos que ese B-Tree tampoco se definía en un solo gran rango, sino en varios. Y es que el principio y el final de los chunks coinciden exactamente con el principio y fin de los rangos del Device Tree. Un chunk es, por tanto, la representación lógica de una porción de disco.

En este árbol los ítems tienen el type CHUNK_ITEM, que indica que es un ítem con información sobre un chunk. El objectid siempre se asigna al valor de FIRST_CHUNK_TREE (se podría decir que en este caso no se utiliza). El offset indica la dirección lógica inicial del rango con el que se pretende tener una equivalencia física. En el ítem se indica el dispositivo donde éste se encuentra y el comienzo de su dirección física.

FS Tree

Este B-Tree se encarga de almacenar lo que se definiría tradicionalmente como metadatos: Nombres de los archivos y de los directorios, los inodos, información de los atributos extendidos, extents; se trata de la concepción más cercana que la gente tiene del interior de un SdA.

Los ítems de este árbol son algo complejos y de muchos tipos. En Unix, como es sabido, cada archivo tiene su correspondiente inodo, en el FS tree cada archivo tiene varios items, todos con el objectid de su inodo: uno del tipo INODE_ITEM que describe el tamaño y los permisos de acceso de ese archivo, otro de tipo INODE_REF que describe el nombre y número de inodo del directorio en el que se halla, otro EXTENT_DATA que describe la ubicación de los datos del archivo, en el caso de tenerlos. Los directorios, por su parte, tienen tambien varios ítems con el objectid de su inodo, uno de tipo INODE_ITEM, otro de tipo INODE_REF y, por cada archivo que haya dentro del directorio, dos items, uno del tipo DIR_ITEM y otro del tipo DIR_INDEX, ambos conteniendo el nombre y número de inodo de cada archivo correspondiente (la razón de que haya dos ítems por cada archivo se debe a la deficiencia de ciertas APIs de Unix, otros SdA han tenido que hacer cosas similares)

Los items del tipo EXTENT_DATA son los que informan de la ubicación de los datos de los archivos, es decir extents. Contienen en su interior la dirección lógica donde empiezan los datos del archivo, la extensión del extent, si el extent está comprimido, etc.

Extent Allocation Tree

Este es una especie de gestor de espacio libre de Btrfs. Es equivalente a los free space map de otros SdA. En realidad el nombre correcto de este árbol debería ser "used space tree", guarda información sobre las partes de los chunks que están usadas usadas. Se podría decir que su nombre despista un poco.

Este árbol no se toca para nada cuando se leen archivos. El proceso de lectura de un archivo consiste en buscar el archivo en el FS tree, y los ítems indicarán la dirección del disco en la que se encuentran los datos. Btrfs entonces solo tiene que mirar al Chunk tree para saber en qué dispositivo y en qué dirección física tiene que empezar a leer. Solo cuando se añaden, modifican o borran datos es necesario marcar en el Extent tree las partes de espacio que se van a usar, o a liberar las que estaban usadas.

Aparte de esa información, en éste árbol se forman una especie de "grupos de bloques" lógicos, que hacen referencia a grandes extents lógicos de los chunks. El objeto de estos "grupos de bloques" es subdividir el espacio disponible en partes que pueden ser dedicadas a los datos o a los metadatos. Esto se utiliza para poder agrupar separar los datos y los metadatos en chunks distintos.

Checksum tree

Este es el último B-tree. Como su nombre indica, almacena los checksums. Cada item, de type EXTENT_CSUM, contiene el número del byte de cada extent y su checksum.

Subvolúmenes y snapshots

Antes de hablar de estos conceptos, hay que definirlos y diferenciarlos. El snapshot es bien conocido, se trata de una copia idéntica del SdA en el momento en que se toma y que se mantiene inalterado con el tiempo. El subvolumen es un concepto menos conocido: se trata de una especie de nuevo SdA, pero un SdA nuevo de acuerdo con la gestión el espacio en forma de pool. Es decir, no un SdA literalmente aparte, sino uno obtenido del pool.

Un subvolumen vacío no tiene nada dentro, solo los directorios "." y "..". Puede montarse en cualquier directorio. De hecho, existe un subvolumen en todo SdA nuevo llamado "default", que es el que se crea y usa por defecto. Un subvolumen puede tener configurado un límite de espacio, de modo que puede utilizarse como un sustituto de las tradicionales quotas, creando en /home un subvolumen para cada usuario con un límite de espacio determinado.

Sin embargo, internamente subvolúmenes y snapshots son la misma cosa: un FS tree. Uno por cada subvolumen o snapshot. Se diferencian en que el subvolumen es un FS tree vacío, sin archivos ni directorios, mientras que el snapshot tiene ya un montón de archivos y directorios. En realidad los snapshots inicialmente comparten su FS tree con el subvolumen en que se toma, solo se deja una "marca" en nodos e ítems afectados, de modo que cuando cualquiera intente hacer una modificación de su FS tree compartido, el mecanismo COW duplicará las partes modificadas del B-Tree. Puesto que hasta que no sean modificados los ítems que hacen referencia a extents son los mismos para ámbos árboles, los extents que contienen los datos de los archivos se comparten inicialmente, con lo que todo nuevo snapshot comparte todos sus extents de datos y no ocupa prácticamente nada de espacio adicional, solo cuando se modifica un archivo se crea un nuevo extent al que apunta el FS tree que lo haya modificado.

La lista de todos los snapshots y subvolúmenes del SdA se almacena en la raiz de raices, el Root tree. Se almacenan como directorios: literalmente. Cada snapshot o subvolumen tiene un nombre, y en el Root tree se almacena un item de tipo directorio con el nombre e información para encontrar la raiz del FS tree correspondiente.

Mirroring y stripping: regreso al Chunk Tree

El lector sagaz tal vez se haya dado cuenta de hasta ahora no se han mencionado nada sobre la replicación de datos entre varios dispositivos de almacenamiento, ni sobre la capacidad de reescribir, a partir de una réplica, un bloque cuyo checksum erroneo indique corrupción.

Todo se hace en el Chunk tree. Cada item de ese árbol almacenaba equivalencias entre un rango físico de un disco y uno lógico del SdA. Lo que no se mencionó entonces es que cada chunk, además de almacenar información del rango del dispositivo al que quiere representar lógicamente, puede tambien almacenar información sobre más de un dispositivo, e indicar si se quiere que sobre ellos se haga mirroring (copia exacta de los datos) o stripping ("repartir", o dividir los datos del chunk en varios dispositivos).

Esto significa que toda la cuestión de mirroring y stripping se hace a nivel de chunk, cada uno se puede configurar independientemente. Este sistema es muy flexible. Ya dijimos que cada chunk se puede dedicar, por medio del Extent tree, a almacenar solo datos o metadatos. Así es que se pueden configurar los chunks de metadatos con mirroring y los de datos con stripping, por ejemplo. De hecho, esta es la configuración que se utiliza por defecto, se replican los metadatos -esto ocurre incluso dentro de un SdA compuesto por un solo dispositivo- para que las estructuras más importantes del SdA estén salvaguardadas, y los datos se reparten entre varios dispositivos, de haber varios disponibles.

Back references

Esto no tiene nada que ver con B-Trees, pero de todos modos es muy interesante, porque es una característica única de Btrfs. Se trata de una idea extraida de chunkfs, un proyecto creado para resolver la "reparabilidad" de los SdA actuales y que propone una serie de ideas que permitirían crear lo que ellos llaman un SdA "diseñado para ser reparado". Btrfs incorpora buena parte de esas ideas (el nombre "chunk" probablemente derive de chunkfs) , y una de ellas son las "back references", o referencias inversas.

Un ítem de un Fs tree apunta al extent del Extent tree donde se guardan sus datos. Una referencia inversa sería un puntero del extent hacia el ítem del FS tree que lo apuntó. Mantener estas referencias tiene cierto coste, por eso pueden desactivarse, pero aun así se activan por defecto.

Es una información muy preciada que aunque parezca algo paranoica, puede ser muy útil: desde servir para encontrar el ítem que apuntaba a un extent tras descubrirse que éste está corrupto, a poder escanear el disco en busca de extents y poder identificar los que forman parte de un solo archivo fijándose en que los que tienen una misma referencia inversa. Tambien permite reducir el tamaño del SdA, de una forma sencilla, segura y rápida, algo que los SdA tradicionales suelen implementar tarde y mal (por ejemplo, ZFS aun no lo soporta).

Resumiendo...

Se puede sopesar ahora hasta que punto es acertado que el nombre "Btrfs" sea un alias de "B-Tree filesystem". En otros SdA, se crean unas estructuras de datos y se utilizan B-Trees para organizar alguna o algunas de ellas. En Btrfs es al reves, el B-Tree es la estructura de datos fundamental, todas las demás se implementan sobre él. Cada árbol listado en este texto es una especie de instancia del B-Tree modelo.

Toda esta maraña de árboles -más bien jungla- quizás parezca compleja. Incluso podría ser que este texto diera a algunas personas la sensación de que un B-Tree es una estructura demasiado pesada y complicada, y quizás les lleve a pensar que podría haberse ganado en simplicidad no utilizándo tanto árbol excepto en los casos verdaderamente necesarios. Si es así, me temo que mi escritura no es capaz de reflejar la sencillez y limpieza del diseño de Btrfs, en realidad un B-Tree es algo liviano, y es bastante rápido incluso cuando contiene muchos items. Juega a su favor el hecho de que esté preparado para ser escalable en máquinas multicore; diseñar un SdA con las estructuras de datos aptas para ser escalables sería más complicado. La utilización de un B-Tree común que ya ha resuelto esos problemas libra a los programadores de gran parte (pero no todo) ese trabajo.

En cuanto a complejidad, en realidad es sorprendente lo fácil que es comprender todo el diseño a partir de unos pocos conceptos. Una vez que se tienen en la cabeza, cualquiera puede lanzarse a leer gran parte del código y entenderlo sin muchas complicaciones. Hay que hacer notar la limpieza con la que se abstraen ciertos conceptos de otras capas y estructuras. Como comparación, ZFS tambien tiene diferentes niveles bien separados, pero en las estructuras esa diferencia no es tan radical; por ejemplo la estructura encargada de apuntar a un objeto (blockptr_t) contiene el checksum y tres campos de 32+64 bits cada uno en los que se almacena el identificador de dispositivo+desplazamiento de tres copias alternativas, para recurrir a ellas en caso de corrupción. En Btrfs esa información se mantiene separada en el Chunk tree (y una sola vez, no duplicada en cada puntero) y en el Checksum tree , ambos relacionados con los extents del Extent tree por simples rangos de bytes. Podrían añadirse nuevos B-Trees para vaya-a-saber-usted-qué sin que el código ni las estructuras existentes notaran cambio alguno.

En definitiva, Btrfs es un sistema de archivos moderno, con fundaciones muy sólidas y conceptos renovadores que lo harán durar muchos años. Por sus capacidades está muy preparado para sustituir al veterano (pero aun enérgico) Ext4, en cuanto alcance la categoría de estable. Pero tambien sustituirá a reiserfs (v3 o v4), XFS y JFS, lo cual centrará sobre él una mayor atención colectiva de la que Ext4 tiene hoy, que es mucha. En estos momentos su estado de desarrollo podría considerarse como de las últimas versiones alpha; las distros ya empiezan a ofrecer opción experimental en las instalaciones nuevas. Es de suponer que la versión 1.0 vea la luz en la primera parte del año que viene y que pase a usarse como SdA por defecto en las distros a lo largo del 2011.

(Notas: -todo lo referente al Extent Tree y parte del FS Tree han sido revisados desde su redacción original debido a un error conceptual, -se ha eliminado la información sobre la cabecera de cada bloque del btree, no viene mucho a cuento, -se ha simplificado la explicación del B-Tree, -la explicación de los ítems de cada árbol se ha reescrito para ser más visual)

Citas

2009-09-23T15:17:00.001+02:00

"I really enjoy arguing, a big part of my life are these occasional flame threads that I love getting into and telling people they are idiots" - Linus Torvalds

ARMándose

2009-09-17T00:00:00.000+02:00

En este blog ya he citado más de una vez aquella frase de Linus Torvals que decía que si había una arquitectura con alguna posibilidad de acabar con el predominio de x86, era ARM. Posibilidad remota, remotísima, claro, pero posibilidad. Tambien he enlazado aquí a muchos artículos que hablan sobre la guerra declarada por Intel a esta arquitectura en lo que vienen a ser los netbooks y ese otro sector de dispositivos que pueden ser clasificados de forma vaga como "Cosas-Parecidas-al-iPhone".

Hoy se han publicado en los medios noticias sobre la presentación del Cortex A9 que parecen confirmar que ARM se toma su guerra en serio (de la que ya teníamos noticias por sus propuestas de crear netbooks ARM) y que ha decidido presentar batalla. Y, al parecer, pretende presentarla no solo en netbooks y cosas-parecidas-al-iPhone, sino incluso ¡en servidores! Se referirá, obviamente, a grandes clusters de mini-ordenadores ARM para cálculo científico, clouds, y cosas así.

Y es que los ARM son, a día de hoy, mucho más eficientes que cualquier oferta de Intel, lo cual implica ser superior en rendimiento en cualquier cosa que use baterías (pueden crear una CPU que tenga un consumo idéntico que el del competidor, pero con mejor rendimiento), lo cual es muy comprensible si, como dice en el enlace, el tamaño del Cortex A9 es 1/3 del de un Atom. Para que nos vamos a engañar, esa gente sabe hacer procesadores. Sus características técnicas parecen decentes; Jon Stokes dice que espera que sea "extremadamente competitivo" contra sus rivales de Intel en cuanto a rendimiento/Watio.

No todo es bonito, claro. Uno de los problemas de ARM, si tomamos sus planes imperiales en serio, es que es una plataforma de 32 bits. Eso no le supondrá un gran problema en términos de rendimiento, ARM no es tan mala plataforma de 32 bits como lo eran los x86 (en particular su patética escasez de registros, que según cuentan en ciertos programas obligaba a pasarse porcentajes de tiempo de dos cifras moviendo datos de los registros a la memoria y viceversa para "hacer hueco") pero si que les limita en su supuesta pretensión de atacar en el escritorio y en los servidores, 4GB de RAM no son tan raros hoy. Aunque por otra parte ARM podría sacarse un equivalente al PAE de x86...y sacar versiones de 64-bits, por supuesto.

Otro problema es la falta de soporte de Windows NT. El artículo cita estas palabras de un ejecutivo de ARM: "Hemos estado hablando con Microsoft y ya puede usted imaginarse sobre qué". Claro que nos lo imaginamos: Portar Windows 7 a ARM, un Windows de verdad. Ya dije aquí en el pasado que uno de los problemas de Microsoft hoy es no tener un verdadero port de Windows 7 a ARM para poder usarlo en una Cosa-Parecida-al-iPhone, eso les está dejando en desventaja respecto a Apple y Android/Palm. ¿Estaría dispuesto Microsoft a portar Windows 7 a ARM? ¿Y pedir a sus partners y a todos los desarrolladores Windows que recompilen y se adapten a ese port (o, mejor aun, que usen .NET)? Pues la verdad, no sería raro. ¿No portaron acaso Windows XP, un SO de escritorio, a Itanium? Apostar por la muerte de ARM a manos de Intel parece demasiado prematuro: No se sabe si acabará ocurriendo, si de ocurrir será una aniquilación o un arrinconamiento, y de ocurrir sería algo que tardaría mucho tiempo, del mismo modo que tardó una década y más en acabar con las grandes CPUs RISC propietarias (y no acabó con todas). En ese tiempo, no soportar ARM podría suponer un zarpazo mortal para los de Redmond. Si tuviera que apostar por ello apostaría que si, que se decidirán a portar Windows 7 (o 8, o el que venga) a ARM. Hay que arriesgarse, demonios.

Mientras tanto, pueden usar Linux. No soporta las aplicaciones que la gente quiere, se critica a Linux, pero por otra parte en un Windows portado a ARM tampoco habría montones de aplicaciones, como todas aquellas no soportadas, asi que yo tampoco veo que sea un gran problema. Pero ya sabemos como es de rara la gente...

Pongamos que se alinean los planetas, que Microsoft porta Windows a ARM, que tiene un éxito tremendo en los netbooks -probablemente lo tendrá, teniendo en cuenta que aumenta drásticamente la vida de la batería, algo fundamental en esos trastos-, que tiene cierto éxito en los servidores -clusters baratos y con un consumo ínfimo-, tal vez entonces ARM tendría una remota -remota- posibilidad de ir más allá de todo eso y plantearse la posibilidad de acabar con la dominancia de x86. No creo que ocurra, pero es divertido imaginarlo.

Lo que trae 2.6.31

2009-09-10T00:00:00.002+02:00

Este es un resumen de las novedades más importantes de Linux 2.6.31, que acaba de salir hace unos momentos. Resumen: soporte de USB 3.0, un equivalente de FUSE para dispositivos de carácteres, mejora de interactividad del escritorio en escritorios con poca memoria, KMS para ATI Radeon, soporte para "performance counters", un detector de pérdidas de memoria, mejoras de readahead y de btrfs, nuevos drivers...

· Soporte de USB 3: Esta versión añade soporte de USB 3.0, contribuido por Sarah Sharp (Intel), y del hardware que soporta la especificación "eXtensible Host Controller Interface (xHCI) 0.95". Aun no hay hardware xHCI en el mercado, pero estos parches han sido probados en el prototipo de Fresco Logic

· CUSE (dispositivos de caracter en espacio de usuario) y OSS Proxy: CUSE es una extension de FUSE que permite implementar en espacio de usuario dispositivos de caracteres y que ha sido contribuido por Tejun Heo (SUSE).

Puede ser utilizado para muchas cosas, por ejemplo para crear un proxy que envie el audio OSS a través de ALSA o a un sistema de sonido que pueda enviar sonido sobre la red. ALSA tiene una emulación de OSS en el kernel pero desgraciadamente esta emulación está en el kernel y se encuentra detrás de la librería en espacio de usuario que multiplexa el sonido, lo cual significa que si tu tarjeta de sonido no soporta múltiples streams de audio concurrentes (la mayoría de las tarjetas modernas no lo soportan), en un momento dado solamente podrás utilizar ALSA o la emulación OSS, pero no ambas a la vez.

OSS Proxy utiliza CUSE para implementar la interfaz OSS - /dev/dsp, /dev/adsp y /dev/mixer. Desde el punto de vista de las aplicaciones, estos dispositivos son verdaderos dispositivos de carácter, y se comportan exactamente igual, asi que puede utilizarse como un sustituto de la capa de emulación OSS. La aplicación envía audio a esos dispositivos, y el Proxy OSS lo reenviará a un "esclavo". En estos momentos solamente hay un esclavo implementado (pulseaudio)

· Mejora de la interactividad bajo presión de memoria: Las páginas de memoria marcadas como PROT_EXEC son páginas que normalmente pertenecen a programas y librerías que se están ejecutando, asi que debería estar cachearse muy bien para proporcionar buenas experiencias de usuario, porque si no están bien cacheadas, las aplicaciones de escritorio sufrirán largas pausas cuando las rutas de código de la aplicación salten a una parte del código que no está cacheada en memoria y tenga que ser releida desde el disco, que es muy lento. Debido a ciertas mejoras de escalabilidad en la gestión de memoria en los últimos kernels, hay ciertos tipos de carga (comunes) que pueden causar que esas páginas PROT_EXEC sean enviadas a la lista de páginas respaldadas por sistema de archivos (las utilizadas para mapear archivos) que son inactivas y pueden ser borradas de la memoria. El resultado es un entorno de escritorio con poca interactividad: las aplicaciones empiezan a responder mal con demasiada facilidad.

En esta versión, se han aplicacion ciertas heurísticas para que sea mucho más dificil sacar a las páginas de código ejecutable de las listas de páginas activas. El resultado es una experiencia de escritorio mejorada: Benchmarks en escritorios con poca memoria miestran que el tiempo de reloj y las faltas "mayores" de memoria (cuando una aplicación salta a una parte del código que no está mapeada en la memoria) se reducen en un 50%, y los números de pswpin se reducen aproximadamente 1/3, eso significa que la interactividad de los escritorios se dobla en condiciones de presión de memoria. Benchmarks de "flusheado" de memoria en un servidor de archivos muestran que el número de faltas mayores cae de 50 a 3 durante lecturas "calientes" del caché.

· Soporte de Mode Setting para ATI Radeon: En esta versión se añade soporte de Kernel Mode Setting (KMS) para ATI Radeon. El hardware soportado es R1XX,R2XX,R3XX,R4XX,R5XX (hasta la X1950). Se está trabajando para proporcionar soporte para R6XX, R7XX y hardware más moderno (radeon de HD2XXX a HD4XXX).

· Performance counters: El subsistema de Contadores de Rendimiento implementa una abstracción de una serie de registros dedicados a medir el rendimiento que están disponibles en la mayoría de CPUs modernas. Miden el número de eventos como: instrucciones ejecutadas, "cpumisses", errores de predicción en las instrucciones condicionales...sin enlentecer el kernel o las aplicaciones. Estos registros tambien pueden generar una interrupción cuando se pasa de cierto número de eventos - y pueden por tanto utilizarse para analizar el código que se ejecuta en esa CPU. En esta versión, se añade soporte para x86, PPC y soporte parcial para S390 y FRV.

No se espera que los usuarios utilizen ellos mismos la API. En lugar de ello, se ha escrito una poderosa herramienta de análisis: "perf", que está disponible en el directorio tools/perf.

perf soporta varios modos de operacion, como "perf top", que muestra una interfaz semejante a la del comando "top", y que puede restringirse a cualquier conjunto de eventos, procesos o CPU. Existe tambien "perf record", que almacena el registro de un análisis en un archivo, y "perf report", que lee el registro y lo muestra en pantalla, o "perf annotate", que muestra la lista de eventos soportados por el hardware, y "perf stat", que ejecuta un comando y muestra sus estadísticas de rendimiento en la pantalla. Toda la documentación y las páginas man están disponibles en el subdirectorio "Documentation". Algunos ejemplos:

$ ./perf stat -r 3 -- echo -n

Performance counter stats for 'echo -n' (3 runs):

2.337404  task-clock-msecs         #      0.566 CPUs    ( +-   1.704% )
     1  context-switches         #      0.000 M/sec   ( +-   0.000% )
     0  CPU-migrations           #      0.000 M/sec   ( +-   0.000% )
   184  page-faults              #      0.079 M/sec   ( +-   0.000% )
4319963  cycles                   #   1848.188 M/sec   ( +-   1.615% )
5024608  instructions             #      1.163 IPC     ( +-   0.722% )
 73278  cache-references         #     31.350 M/sec   ( +-   1.636% )
  2019  cache-misses             #      0.864 M/sec   ( +-   6.535% )

0.004126139  seconds time elapsed   ( +-  24.603% )


$ perf report -s comm,dso,symbol -C firefox -d /usr/lib64/xulrunner-1.9.1/libxul.so | grep :: | head
2.21%  [.] nsDeque::Push(void*)
1.78%  [.] GraphWalker::DoWalk(nsDeque&)
1.30%  [.] GCGraphBuilder::AddNode(void*, nsCycleCollectionParticipant*)
1.27%  [.] XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)
1.18%  [.] imgContainer::DrawFrameTo(gfxIImageFrame*, gfxIImageFrame*, nsRect&)
1.13%  [.] nsDeque::PopFront()
1.11%  [.] nsGlobalWindow::RunTimeout(nsTimeout*)
0.97%  [.] nsXPConnect::Traverse(void*, nsCycleCollectionTraversalCallback&)
0.95%  [.] nsJSEventListener::cycleCollection::Traverse(void*, nsCycleCollectionTraversalCallback&)
0.95%  [.] nsCOMPtr_base::~nsCOMPtr_base()

· Soporte de IEE 802.15.4 (Low-Rate Wireless Personal Area Networks): El estándar IEEE 802.15.4 define una red inalámbrica de área personal de corto alcance, bajos ratios de transferencia, bajo consumo de energía y poca complejidad. Ha sido diseñada para organizar redes de sensores, interruptores y otros dispositivos automatizadores. El máximo ratio de transferencia permitido es 250 kb/s y el espacio de operaciones es de alrededor de 10m.

· Soporte de Gcov: Esta versión permite la utilización de Gcov, una herramienta de GCC utilizara para analizar ciertos aspectos del código, con el kernel. Gcov es útil para depurar (¿se ha llegado a este código alguna vez?), mejora de tests (¿como cambio mi test para cubrir estas líneas?), minimizar configuraciones del kernel (¿necesito esta opción si el código asociado no se ejecuta nunca?) y otras cosas.

· Kmemcheck: Kmemcheck es una herramienta de depuración. En concreto, es un comprobador dinámico que detecta y advierte sobre memoria no inicializada. Los programadores de espacio de usuario puede que conozcan el memcheck de Valgrind. La principal diferencia entre kmemcheck y memcheck es que memcheck solamente funciona para programas de espacio de usuario, y kmemcheck solo funciona para el kernel.

Activar kmemcheck en un kernel lo enlentece hasta el punto que la máquina no será usable para cargas comunes, como por ejemplo un escritorio interactivo. kmemcheck tambien hace que el kernel use el doble de memoria de lo normal. Por esta razón, kmemcheck es solamente una opción de depuración.

· Kmemleak: Kmemleak detecta posibles pérdidas de memoria de una manera similar a este recolector de basura, con la diferencia de que los objetos huérfanos no son liberados. En vez de eso, un thread del kernel escanea la memoria cada 10 minutos (por defecto) y muestra cualquier nuevo objeto no referenciado en /sys/kernel/debug/kmemleak y advierte de ello en dmesg. Un método similar es utilizado por la herramienta Valgrind (memcheck --leak-check) para detectar pérdidas de memoria en aplicaciones en espacio de usuario.

· Fsnotify: Fsnotify es un subsistema utilizado para notificaciones del sistema de archivos. Fsnotify por si solo no tiene ninguna API a espacio de usuario, proporciona la base para implementar otros sistemas de notificación como dnotify, inotify y fanotify (este último será incluido en futuras versiones). De hecho, en esta version dnotify e inotify han sido reescritos sobre Fsnotify, eliminando al mismo tiempo el horrible y complejo código que utilizaban esos sistemas. Fsnotify proporciona un mecanismo para que "grupos" se registren para ser notificados de una serie de eventos del sistema de archivos a los que envía dichos eventos, y el bloqueo es mucho más sencillo. Fsnotify tiene otros beneficios, como reducir el tamaño de la estructura que almacena información de un inodo.

· Soporte preliminar para clientes NFS 4.1: 2.6.30 Añadió cierto soporte orientado a desarrolladores de NFS 4.1. Esta versión añade soporte opcional para los borradores de la versión 4.1 en el cliente NFS del kernel.

· Mejoras de readahead: Esta versión incluye un algoritmo de readahead "basado en contexto". El actual algoritmo detecta lecturas entremezcladas de un modo pasivo, el algoritmo nuevo garantiza descubrir la secuencialidad sin importar como estén entremezclados los streams. Los beneficiarios de este algoritmo son las lecturas estrictamente entremezcladas y los procesos con ES cooperativa (por ejemplo, NFS y SCST). Benchmarks de SCST muestran mejoras del 6%~40% en varios casos y consiguen igual rendimiento en otros.

Tambien hay algunas mejoras al readahead de memoria mapeada. En un escritorio NFS-root, el readahead de mmap redujo las faltas mayores de memoria 1/3 sin sobrecargas notables, el IO llevado a cabo por mmap puede reducirse en 1/4.

Esto es todo. Hay otras mejoras, como un driver para dispositivos Intel Wireless Multicomm 3200, mejoras notables de btrfs, IPv4 sobre Firewire...para ver la lista completa, aquí.

¿Grand Central Dispatch, retorno de M:N?

2009-09-02T21:00:00.001+02:00

Como es sabido, a grandes rasgos hay dos maneras de implementar threads en los sistemas operativos, 1:1 y M:N, durante años se mantuvo que M:N era lo más apropiado, sin embargo 1:1 acabó ganando la batalla. Solaris, que era uno de los mayores representantes de M:N, hizo que en Solaris 9 cambiara por defecto a 1:1 por la simple razón de que era más rápido y tenía mucho menos código, Linux 2.6 optó tambien por 1:1 en su NTPL. Con el tiempo, NetBSD y FreeBSD, que se resistían, tambien se pasaron a 1:1.

En OS X 10.6 Apple ha implementado una serie de mecanismos con el propósito de facilitar a los programadores la utilización de todos los cores y procesadores de los sistemas modernos. Es muy recomendable leer la parte del análisis de OS X 10.6 de Arstechnica que habla sobre este tema, concretamente de la página 10 a la 14. Esos mecanismos, que son una de las cosas más interesantes que se han hecho en OS X (no faltará quien diga que eso de gestionar threads es viejo y que no tiene nada de interesante, o que me cite a BeOS sin pararse a leer la parte del artículo donde explica claramente por qué lo que ha hecho Apple es mucho más práctico y eficiente que el "pervasive multithreading"). Todo ello se basa en unas extensiones a C y en una especie de gestor de threads llamado "Grand Central Dispatch".

Este "dispatcher" se encarga de mantener unas listas de los "bloques" que las aplicaciones crean gracias a la ya referida extensión de C, y repartirlos entre unos pocos threads creados a tal efecto. Se podría decir que huele un poco a M:N, es decir, un proceso que ofrece su contexto de ejecución a threads que son controlados por una especie de gestor de procesos (Grand Central Dispatch) que funciona en espacio de usuario...¿o no?

En cierto modo, a primera vista hay analogías, pero mirado en detalle no creo que se pueda afirmar que tiene que ver con M:N. Fundamentalmente porque M:N es un diseño para implementar threads, mientras que GCD es un sistema que gestiona bloques. Aunque estos bloques podrían compararse con threads no parece apropiado hacerlo. Pretenden ser más bien una especie de subunidades de trabajo, mientras que los threads son más bien subprocesos (si alguien tiene opinión al respecto sería interesante). Se podría argumentar que un thread puede utilizarse tambien para crear "subunidades de trabajo" en un programa, pero tambien puede no serlo. Un bloque hace su trabajo y desaparece, un thread puede durar tanto como el proceso que lo creo. De ahí que GCD no sea (y quizás ni tenga) en realidad un verdadero "gestor de procesos", porque no reasigna el tiempo de ejecución de un bloque-proceso a otro dependiendo de diferentes variables, como haría M:N, tan solo se limita a asignar un bloque a un thread y esperar a que termine (aun está por ver/documentar como gestiona GCD un bloque que se queda en un loop). Pero todo este tema de GCD es muy nuevo, y habrá que ver como evoluciona con los años, y como lo imitan en otros SOs que reimplementen la idea.

Nokia N900

2009-08-28T19:05:00.000+02:00

Aunque he tenido tiempo de sobra para actualizar no he querido hacerlo, porque hunde el orgullo de un bloguero publicar cosas que no va a leer el mayor número posible de personas. Además, el resto del mundo tambien ha andado de vacaciones y no ha ocurrido gran cosa que pudiera ser útil para contar aquí.

Ayer sin embargo se anunció una cosa bastante interesante, el Nokia N900. Es un descendiente del N810 y perteneciente a esa línea de productos basados en Maemo que tanto ruido lleva haciendo entre los seguidores del software libre pero que no ha tenido mucho éxito comercial.

Con el N900 la cosa podría cambiar, principalmente porque lo han convertido en lo que siempre se quiso que fuera: un teléfono, que unido a las impresionantes mejoras que han tenido lugar en Maemo 5 lo convierten en...otro imitador del iPhone (incluso su página web es una copia de apple.com), pero en uno decente. E inesperado, porque creo que no había mucha gente que esperara que Maemo se convirtiera en un contendiente relevante en el tema de los sistemas operativos para smartphones. Yo al menos pensaba que acabarían optando por Android sin complicarse la vida, pero el giro que supone Maemo 5 cambia mucho las cosas.

La pena de Maemo es que de haber tenido Nokia un poco más de voluntad, podrían haberlo convertido en lo que Android pretende ser: una plataforma para todo tipo de fabricantes que quieran usar Linux en sus dispositivos. Y en realidad hasta se podría decir que Nokia aun podría intentar lograrlo: Habrá que ver como evolucionan todas las plataformas, pero estando Maemo en manos de una compañía que tambien diseña el hardware y con notorias ganas de invertir para conservar su liderazgo, y siendo Maemo una plataforma más "nativa" (nada de Java ni de Javascript, a diferencia de Android y de Palm) y por tanto más amigable para los desarrolladores de software libre, todo se andará.

Pues no, los periódicos digitales de pago no son "el pasado"

2009-08-10T20:00:00.002+02:00

Resulta incluso tierno encontrar aun gente que ataque con tanta vehemencia a quienes afirman que el futuro del periodismo no es la gratuidad digital, y les reprochen, cómo no, de no conocer Internet y de no querer despegarse del vetusto papel. Estas personas no creen que nada en Internet pueda ser de pago, que todo ha de ser gratuito y financiarse por otros medios, como publicidad. O estoy muy equivocado, o estas personas se han perdido ya medio telediario de esa Internet que tanto dicen conocer.

La cruda realidad es que muchos de los diarios digitales que pululan por los procelosos mares de Internet no solo no generan beneficios, sino que tienen pérdidas. Su financiación ha corrido a cargo de los "anticuados" periódicos de papel. Oh, the irony. Dicho de otra forma: No es que los propietarios de los medios de comunicación odien la red y quieran "acusarla de todos sus males". Si siguen atados al papel no es por atavismo, es porque es del papel de dónde sacan el dinero que paga sus facturas. Sin embargo, ese papel que paga las nóminas de los periodistas encargados de escribir las noticias de los diarios digitales es tachado de "obsoleto".

Y en realidad, eso de que los medios están atados al papel es un cuento chino. Todos los periódicos relevantes tienen páginas web desde hace años, y no son precisamente malas. Los medios de comunicación son uno de los sectores que con más rapidez, ganas y éxito adoptaron la nueva realidad de la red. Acusarles de no saber adaptarse a los nuevos tiempos, como si fueran discográficas, no tienen ningún sentido. Que muchas empresas de comunicación estén quebrando o tengan serias dificultades económicas a pesar de tener una magnífica presencia en Internet debería hacer reflexionar a más de uno. Pero en vez de eso, se limitan a sacar argumentos de la chistera como "no saben implementar modelos publicitarios eficientes". Ellos, sentados en su casa, con su blog y su adsense, sin duda pueden dar clases de como gestionar un negocio que necesita tener y mantener corresponsales en Palestina.

Mientras hubo dinero y crédito de por medio y todo iba bien los medios se tiraron de cabeza, unos más pronto, unos más tarde, a Internet. Con el tiempo, no tener presencia en la red se vió en el sector como señal de fracaso; aunque la empresa fuera rentable si no tenía una buena web sus noticias no tenían los minolles de visitas que disfrutaban los competidores. Asi que hasta el último mono terminó apuntándose, y aunque todos tenían muchas dudas sobre la rentabilidad, tenían pocas sobre que el futuro, fuera el que fuese, pasaba por la red, asi que se concluyó que había que puesto que era absurdo apartarse de la senda del Progreso, había que echarse la mochila a la espalda y andar hasta llegar a algún destino, aunque no se supiera cual era. Esperar a que alguien descubriera el mejor modo de sacar dinero de Internet, y acto seguido copiarle. Los internautas, por supuesto, optamos por los medios gratuitos, y los de pago fueron crucificados hasta que dejaron de serlo. Pero no se encontró la solución del dinero, y una vez gastada la plata, toca retirada.

A nuestro cruzado contra el papel le gusta pensar que los magnates de los medios son idiotas, viejos que no entienden Internet. Pero en realidad estos señores entienden de negocios, internet mediante o no, bastante más que cualquier bloguero de tres al cuarto, incluido un servidor. La economía no consiste tan solo en satisfacer las necesidades del usuario, es decir, en crear medios digitales gratuitos solo porque lo piden todos los internautas. Los internautas quieren, por supuesto, que todo sea gratis, pero eso ya se presupone. Sin embargo, si mantener un periódico, digital o no, requiere más dinero del que la publicidad es capaz de generar, la empresa se verá obligada, tarde o temprano, a sacar más dinero de algún lado. Y si la única solución que le queda es cobrar por acceso a parte de su información, lo hará -estará obligado a hacerlo, si no quiere quebrar-, y el consumidor tendrá que fastidiarse y limitarse a establecer un precio. Que no es tanta tragedia: ¿No hemos pagado durante siglos por los periódicos de papel? ¿Exactamente dónde está la catástrofe en hacer lo mismo en Internet? ¿A qué viene ese fundamentalismo de la gratuidad?

Es dificil concretar como acabará el mundo periodístico, pues depende totalmente de lo que la sociedad esté dispuesta a pagar por informarse, y nadie puede predecir las futuras decisiones colectivas de la sociedad. ¿Quien podía haber predecido en su día que el ser humano sería capaz de pasarse el día viendo televisión financiada con intervalos publicitarios de 10 minutos? Nadie soportará eso, hubiera opinado yo. Y sin embargo, ahí está. Nadie quiere pagar por la música ni por las películas en Internet, se vaticinó, y parecía la verdad más clara de entre todas las relacionadas con la red, y sin embargo ahí está iTunes, y gente comprando, en pleno siglo XXI y en medio de la revolución de las "nubes", minolles de apps para el iPhone. ¿Serán los medios verdaderamente gratuitos, y se financiarán mediante un modelo publicitario que aporte más beneficios, a base de, por ejemplo, invadirlo todo con anuncios, como hacen en la televisión? ¿O se volverá a los medios de pago?

La decisión final, repito, depende de lo que la gente esté dispuesta a aceptar y lo que las empresas estén dispuestas a -y puedan- ofrecer, y el resultado final está por ver. En cualquier caso, tachar las propuestas de pago como algo "del pasado" es absurdo, especialmente teniendo en cuenta el estado del sector y que sus principales jugadores están hablando de ir en esa dirección. Eso si, algunas cosas están claras. En primer lugar, el modelo ganador será aquel que sea capaz de sacar la mayor cantidad de dinero posible, si un periódico online de pago es capaz de tener más ingresos que uno gratuito que se financia con publicidad, el gratuito acabará cambiando de modelo para sacar más pasta. En segundo lugar, por regla bastante general la gente siempre preferirá conseguir información de periodistas o blogueros a generarla él mismo, del mismo modo que la gente prefiere comprar ropa y no coserla él mismo, no sé de dónde ha salido esa absurda superstición de que en pleno siglo XXI, y exceptuando a cuatro gatos, a la gente le va a dar por gastar su tiempo libre en esas cosas.

Saber colocarse en la foto

2009-08-02T15:30:00.004+02:00

Los políticos conocen la vital importancia de saber colocarse en las fotos. Vía The Open Road, me entero de que Ballmer ha dado un discursito en el que parece querer colocarse en el medio de la foto de las plataformas. Paso a citar unas frases de lo más interesantes:

"I want to describe our value proposition. We are a high-volume player. We don't not, like Apple, believe in low-volume, very high prices. Apple's a great company does a fine job, but their model says high margin, high quality, high price, that's kinda how they come to market.

We say we want BIG market share, but with big market share you take the lower price. Well, along comes Linux, and they say, we have no price, which of course, we know for IP and other reasons, of course they have a price. But they say we have no price. The problem you have with these so-called free alternatives is there's also not the incentive to a lot of the hard work to build out the ecosystem to support the hardware vendors that is required.

"So a model like ours, which is high volume and high value but low priced but not free. You could say are you guys in the middle ground or are you where you want to be? And I say we're exactly where we want to be.

En primer lugar, es curioso que Ballmer ponga a Apple como una compañía que vende pocas cosas a altos precios. El iPhone no es precisamente un producto que se venda poco, ni su precio es tan alto, si se lo compara con sus competidores; si lo fuera no se vendería tanto.

En segundo lugar, resulta curioso que se ponga a Apple y el software libre por separado. A pesar de que los cenizos de la FSF, con su presidente a la cabeza, afirmen un montón de tonterias sobre Apple, la realidad es que Apple, sin ser una compañía 100% opensource, ni tener como objetivo el fin del software propietario, es una empresa que utiliza el software libre con bastante más frecuencia de la que se suele recordar. Su núcleo BSD/APSL (del cual FreeBSD se ha beneficiado a menudo), todo su entorno de shell y utilidades básicas Unix, GCC, python, ruby, CUPS, Apache, Samba, Webkit, etc etc....no falta quien opina que Apple es el mejor ejemplo de como sacar dinero al software libre. Sin embargo, Ballmer los considera como dos extremos fundamentalmente diferentes.

En tercer lugar, resulta muy cómico eso de que el software libre no tiene incentivos para "construir el ecosistema" que necesitan los fabricantes de hardware. Que yo sepa, a Red Hat le sobran incentivos, y no precisamente ideológicos, para desear construir ese ecosistema. Tampoco parece ser consciente Ballmer de la revolución que supone para los fabricantes de hardware el software libre. Con Linux, los fabricantes de hardware dejan de ser meros clientes de un "ecosistema" intocable que les vende una determinada empresa, para convertirse ellos mismos en parte del ecosistema. El cambio de mentalidad que supone explica en gran medida las numerosas dificultades que tienen muchas empresas en entender como han de adoptar ellos mismos a Linux en sus planes. Irónicamente, el mejor ejemplo de esto es Microsoft, quien recientemente publicó miles de líneas de código GPL para que Linux funcione correctamente sobre su plataforma de hardware virtual. Fue la propia Microsoft mediante ese código quien se encargó de que Linux estuviera preparado para el "ecosistema hyper-v", Linux no tuvo que gastarse ni un duro ni hacer ninguna preparación especial para ello.

El gran artículo que iba a escribir

2009-07-30T18:13:00.006+02:00

La mala suerte existe. En el post de ayer mencioné que estaba preparando un artículo que yo pensaba que iba a gustar mucho. Ese magnífico post iba a ser una descripción detallada de cómo es y funciona btrfs a bajo nivel, que llevaba preparándo tan seriamente como si aquí me fueran a pagar por escribirle. Como nadie había escrito aun algo así (es lo que tienen las cosas nuevas), pensaba que tendría bastante éxito en la bloglucosa linuxera hispana. Ya andaba yo regocijándome por adelantado, como en el cuento de la lechera, de los dos regalices que iba a poder comprarme con lo que me diera adsense por las visitas. Asi que imagínense mi sorpresa hace apenas 15 minutos, cuando me pongo a leer la versión gratuita de "LWN weekly edition" liberada esta semana y llego a este artículo.

Un artículo en el que Valerie Aurora (la chica del artículo del otro día) no solamente da una descripción de como funciona btrfs internamente, tambien nos cuenta su historia, las diferencias de su diseño con el de ZFS (que son más importantes de lo que podría parecer) y las ventajas que implican, etc. Asi que les recomiendo que lo lean (ranking D'oh de 0-10: 11). Con lo cual el magnífico post que iba a preparar pierde parte de su gracia. Adios a los regalices. Sic transit gloria mundi.

Aun así, pienso escribir mi post, porque el artículo de LWN se limita a describir el b+tree, y hay muchos otros aspectos interesantes.

Clutter 1.0, virt-manager 0.8 y...Debian

2009-07-29T20:00:00.002+02:00

Los blogs no son ajenos a la inactividad propia del verano (en parte, porque me estoy preparando para un artículo que creo que gustará mucho, y además hay que apoyar las terrazas de los bares en estos momentos de crisis para que no desaparezcan), sin embargo hoy parece ser un día noticioso apropiado para hacer lo que cualquier medio de comunicación: Mezcla indiscriminada de noticias irrelevantes.

La primera noticia es la publicación de Clutter 1.0.0. A diferencia de lo que pueda parecer viendo sus vínculos gnomitas, esta magnífica librería no está basada en GTK (existe código para "embeber" escenas de clutter dentro de aplicaciones GTK, pero tambien se ha hecho algo idéntico para QT), aunque si en GLib. A pesar de su juventud ya ha sido utilizada ampliamente en Moblin, y el Gnome Shell del futuro Gnome 3.0 tambien la utiliza, y tras llegar a la versión 1.0 no hay razón para pensar que su adopción no se va a propagar al resto de proyecto. Todo parece indicar que con el tiempo terminará siendo una librería clave para los escritorios Gnome (QT tiene sus propios inventos equivalentes en camino).

Otra noticia es la publicación de virt-manager 0.8. En esta versión se añaden wizards para añadir el puerto serie, paralelo, tarjetas gráficas a las VMs, rediseño del wizard de clonación de VMs, rediseño de partes de la UI incluyendo la ventana principal, icono en el systray, UI para manipular parámetros de seguridad y soporte para asociar una VM a una CPU concreta...en resumen: casi todo mejoras de UI. Algo que no es sorprendente, ya que virt-manager no es más que una UI para libvirt, pero no por eso es menos importante, de hecho es bastante importante. El código de todos estos proyectos, por cierto, al igual que el de libvirt, y muchas de las mejoras que se están añadiendo a QEMU sale en gran medida del bolsillo de Red Hat.

Por último, tenemos la noticia de que Debian va cambiar su ciclo de desarrollo para pasar a otro en el que la "congelación" se harán cada dos años. El propósito parece ganar "predictibilidad", yo lo llamaría más bien poner algo de orden, y no cabe duda que lo logrará Pero aunque sus enormes esfuerzos por mantener una gran distribución muy estable y muy segura -en ese aspecto no tienen envidia de las grandes distros comerciales- son loables y muy necesarios, incluso imprescindibles para un gran número de usuarios, Debian sigue con su eterno problema de ser demasiado antigua para el escritorio del geek linuxero medio.

La eterna respuesta de Debian a este dilema es: "usa testing". Y eso es lo que ha terminado siendo Debian: una gran masa de usuarios que usa stable en servidores, más una masa que usa testing o unstable para el día a día. A menudo no lo hacen por capricho, sino por obligación: sale hardware nuevo -en dos años sale mucho hardware nuevo, y además en stable nunca se utiliza la última versión stable de upstream, lo cual agrava el problema aun más- y el Linux/X.org de la última versión estable no lo soporta, asi que resulta más comodo arrancar directamente en testing que ponerse a utilizar backports que de todos modos introducen software nuevo e inestable equivalente al de testing. Allí, en testing, o en unstable se acaban usando sucesivas versiones upstream estables de Gnome/KDE/X.org/Linux antes de que Debian saque una sola de su stable. Pero testing no es equivalente a Ubuntu o Fedora, asi que la gente sigue utilizando y pasándose a otras distros, y Debian ha pasado a ser noticia una vez cada x años mientras que el resto de distros se llevan toda la fama y la mayoría de base de usuarios de escritorio. El contrato social de Debian dice en su punto 4:

"Nuestra prioridad son nuestros usuarios y el software libre: Nos guiaremos por las necesidades de nuestros usuarios y de la comunidad del software libre. Sus intereses serán una prioridad para nosotros. Daremos soporte a las necesidades de nuestros usuarios para que puedan trabajar en muchos tipos distintos de entornos de trabajo."

Sin embargo, viendo el comportamiento tradicional de Debian más bien parece que dijera "nos guiaremos por el ideal de construir la distribución más estable y segura de todas, todo lo demás es secundario". Como resultado, muchos de sus usuarios se han pasado a otras distros, en especial Ubuntu, en busca de una necesidad de modernismo que Debian se niega a cumplir tan bien como las cumplen otros.

En mi opinión, Debian infrautiliza estúpidamente su vasto potencial no haciendo, por ejemplo, lo que hace Canónical: nuevas versiones cada 6 meses y, de vez en cuando, una versión LTS que es estable, contiene software moderno y, al mismo tiempo, promete soporte a largo plazo. No es tan estable como una -stable de Debian, pero acaba siéndolo con el tiempo porque van incorporando las versiones bugfix de upstream que Debian stable incluirá de serie cuando sea publicada tiempo despues. El soporte de hardware de Ubuntu LTS es moderno e incluye siempre la última o penúltima versión estable del kernel, según coincidan las fechas: Debian 5.0 salió en Febrero de este año con Linux 2.6.26, una versión de Julio del 2008, Ubuntu 8.04 LTS salió en Abril del 2008 y su kernel era de Enero de ese mismo año. Y ni a los admins más conservadores les gusta empezar proyectos con versiones de, por ejemplo, PHP, anticuadas; ya que vas a hacer algo nuevo mejor empezar con la última versión estable más moderna y que se vaya ajando ella sola con el tiempo. Por eso no es ninguna sorpresa que cada vez más gente esté utilizando tambien Ubuntu LTS en servidores.

No fue por voluntad propia

2009-07-23T16:30:00.001+02:00

Al final, me alegro de no haber escrito ese post donde decía que Microsoft había publicado drivers GPL para que Linux funcione en Hyper-V solo porque tenían la presión comercial de que Linux funcionara virtualizado en sus servidores. Porque al final se ha revelado que, en realidad, lo han hecho para no ser acusados de violar la GPL.

Resumiendo, parece ser que Microsoft ya tenía esos drivers, pero eran el típico blob binario + algo de código-pegamento para encajarlo en el kernel. Violaba, por tanto, la licencia, al igual que lo hace prácticamente todo driver binario, aunque hay casos que pueden escapar a la noción de "derivado" de la GPL. En cualquier caso, parece que se pusieron en contacto con Microsoft, y bien sea por miedo a que la prensa mundial les acuse de violar el copyright de Linux (¡Violadores!), o porque Greg Kroah-Hartman les ha aclarado las dudas que podrían tener respecto al software libre, o por una mezcla de ambas (personalmente siempre opto por las mezclas), se decidieron a liberar el código y, en una magnífica operación de marketing, han presentado esta liberación de código como una colaboración con el software libre. Y todos nos lo habíamos tragado.

Habría que preguntarse por los aspectos morales. ¿Debemos reprochar a Microsoft la violación de la GPL a pesar de todo? ¿Hay que ridiculizarles por haber montado esta operación de encubrimiento de un delito contra el copyright? ¿Debería Greg Kroah-Hartman haber dicho algo sobre el tema? Yo pienso que no: la GPL exije que se muestre el código, y aunque no lo hicieran al principio, parece que han accedido rápida y fácilmente a hacerlo -presionados o no-, asi que en la práctica ha cumplido. No se puede decir lo mismo de otras empresas.

Por otra parte, está claro que estamos ante una excepción. Microsoft tiene que tener cierto interés en que Linux pueda funcionar bajo Hyper-V correctamente tan solo para que la gente no se vea forzada a recurrir a Vmware/Xen/KVM (por cierto, ya que sacamos a KVM a la palestra, miren que bonita futura feature para virt-manager). Dudo que volvamos a ver cosas tan notables como esta.

Sobre ZFS y btrfs

2009-07-16T15:00:00.001+02:00

No se pueden imaginar las horas que me he pasado googleando y leyendo en busca de las diferencias de btrfs respecto a ZFS y las ventajas o desventajas que tienen. Aparte de la idea de "punteros inversos" de btrfs, y su sfck, no parecía haber ninguna más. No es tan fácil encontrar datos, al ser tan nuevos aun no se ha escrito mucho en detalle sobre ellos. Por eso me ha agradado encontrar por fin algo leyendo esta entrevista a Valerie Aurora, desarrolladora de sistemas de archivos en la nómina de Red Hat, donde dedica un par de párrafos a describir esas diferencias. Pero lo más importante, y lo que la concede autoridad extra, es que tambien fue empleada de Sun y co-desarrolladora de ZFS durante dos años. Sabe, por tanto, de lo que habla, y su posición es más neutral que la de otros:

"ZFS and btrfs are similar in structure and goals in a lot of ways. Features they share are copy-on-write everything, checksums, writable snapshots, storage pooling, simple administration, ad nauseum. More interesting are the major differences in architecture. At the highest level, ZFS uses plain ol’ trees of pointers to blocks, FFS-style, and variable block sizes, inspired by the SLAB kernel memory allocator. Btrfs uses a specialized, COW-friendly form of b-trees (as presented by Ohad Rodeh at LSF ‘07) and extents. Btrfs is actually slightly more exciting than this: every single piece of data or metadata in btrfs is an item in a b-tree, and items are packed together indiscriminately, without regard to their types. ZFS reduced all file system metadata and data to objects and related operations; btrfs reduced them all to items in a b-tree. Now all the interesting decisions are about how to assign keys to items and order them inside the b-tree.

Now for personal opinion/zealotry time. Initially, I thought the ZFS approach was the simpler and cleaner - at the time, the code to manage b-trees and extents was complicated enough, and adding copy-on-write and checksums to that made your brain want to explode. It took Ohad Rodeh’s simplified, robust b-tree algorithms and Chris Mason’s everything-is-an-item insight to change my mind. I’m a convert."

¿Por qué tiene éxito Twitter?

2009-07-14T00:00:00.000+02:00

No voy a esconder la cabeza, yo siempre pensé, y creo que lo he dicho aquí, que Twitter era una mierda pinchada en un palo, que iba a durar lo que durara la moda, y que en el remoto caso de que la gente fuera tan idiota como para querer usar algo así, los servicios de mensajería instantanea podían copiar la idea fácilmente y, ya de paso, subir el límite de caracteres. El tiempo ha probado que estaba equivocado. ¿Por qué ha tenido tanto éxito twitter, entonces?

Una de las claves es la que podría afirmarse que es su principal debilidad: la brevedad de los mensajes. Autolimitar la expresividad a un puñado de caracteres en principio es una limitación absurda, pero no lo es. En una entrevista, Borges contaba que podía parecer que el verso libre es más sencillo que el verso tradicional, pues evita la obligación de tener que encajar los versos en la rima y la métrica concreta de la versificación escogida. Sin embargo, aclaraba Borges que con el tiempo había llegado a la conclusión opuesta: El verso con una estructura definida es un recipiente que obliga al pensamiento a adaptarse a unos límites, a ir en una dirección definida, mientras que con el verso libre el poeta se enfrenta a las infinitas posibilidades del lenguaje y tratar de discernir en ese pajar inabarcable no ya una aguja, sino la mejor de todas las pajas (batalla inhumana). Con Twitter pasa algo parecido, la necesidad de limitarse a 140 caracteres obliga a los usuarios a prescindir de los malos usos que aparecerían de disponer de más espacio, incita a concentrar la máxima expresividad en el mínimo espacio, hace de cada algo interesante que merece la pena leer. Muchos de los Tweets ni siquiera alcanzan el límite ni parecen requerir más, pues los usuarios se adaptan mentalmente a él.

Además, la brevedad consigue que leer decenas de Tweets sea algo sencillo, empleando tan solo unos pocos segundos. Al aumentar la longitud de los mensajes el tiempo necesario para leerlos y contestarlos puede multiplicarse exponencialmente. La fluidez de las conversaciones en Twitter depende directamente del límite de caracteres.

La otra clave del éxito de Twitter sin duda son las posibilidades de comunicación entre usuarios, que se han logrado combinando elementos del IRC y del IM. Hay millones de personas, y puedes dirigir tus mensajes a cualquiera de los usuarios, que todo el mundo los lea, y que el mundo lea los tuyos. Es decir, las comunicaciones entre personas son fundamentalmente públicas, porque incluso cuando son entre dos personas la conversación es accesible a otros, y se escribe teniendo esto en mente (si, se pueden configurar las actualizaciones como privadas, pero la mayoría no lo hacen). Esta es la razón por la que ningún sistema de IM puede lograr el éxito de twitter implementado un "visor de cambios de estado" de los contactos (como ha hecho Messenger). El modelo IM es fundamentalmente de relaciones privadas y estancas, se requiere agregar al contacto y que él te acepte. Twitter permite comunicarse con cualquiera sin que él te acepte. Puedes seguir a alguien sin que él te siga a ti, y viceversa. Hay algo remotamente parecido a "canales". Mal visto, Twitter es un IRC con gestión de contactos adaptada al carácter público de las conversaciones, con almacenamiento persistente y con interfaz web.

Mirado así, está claro que Twitter no es ninguna moda, sino que es algo que va a durar. Eso si, tarde o temprano lo comprará alguien porque por muy útil que sea me parece dificil sacar un solo céntimo de beneficios al sitio. Y no esperen que yo lo use, me cree una cuenta hace dos años, puse un mensaje de prueba y no he vuelto a encontrar motivos para decir nada más.

¿Qué demonios ha anunciado realmente Google?

2009-07-08T17:30:00.000+02:00

Todo el mundo lo está llamando cosas como "Chrome OS", "cloud-based operating system", "PC operating system", pero no habrá fuerza divina que me impida continuar utilizando las convenciones de toda la vida y denominar a lo que acaban de anunciar "distribución Linux". Otra distribución Linux más, pues no tiene nada que ver con Android.

La primera impresión que da este anuncio es que la comunidad Linux y del software libre se enfrenta a una nueva era. El apoyo de Google me parece que será tan importante y decisivo como lo fue en su día el de IBM. Al igual que en aquel caso, Google no parece sacar beneficio de este SO, al fin y al cabo sus ingresos vienen de la publicidad, el corazón real de su negocio son sus gigantescos clusteres. ¿A qué viene invertir tiempo, dinero y reputación en esto, si la interfaz de sus aplicaciones web funciona igual en IE que en Chrome, salvando las diferencias técnicas entre ambos? IBM confió en Linux no para ganar dinero con ello -no tiene su propia distro-, sino más bien como barrera contra Microsoft, parece aceptable pensar que Google esté haciendo exactamente lo mismo.

Pasando al SO en concreto, ¿qué anuncia realmente Google? En todos los sitios web donde se ha hablado, donde se está hablando de este anuncio, se ha dicho que la frase "los sistemas operativos en los que funcionan los navegadores fueron diseñados en una era en la que no había web" es una pulla hacia Windows. Mi opinión sin embargo es que tambien se refiere tanto a Linux como a Mac OS X. Y cuando dice que el nuevo SO Chrome es "nuestro intento de re-pensar como deberían ser los sistemas operativos", da la impresión de que no están hablando de crear la enésima distribución Linux, ni tan siquiera de ofrecer una distro con un nuevo sistema de ventanas, como afirman que han hecho, sino de algo diferente.

De momento solo sabemos de cierto que la descripción del stack de software de esta distro como "un sistema de ventanas nuevo sobre un kernel Linux" podría ser casi literal. Todo lo demás todo son conjeturas. Sin embargo, teniendo en cuenta la experiencia con Android, podemos decir que Google no tiene el más mínimo respeto a lo establecido; por ejemplo Android añade un nuevo subsistema de IPC en el kernel, y un nuevo modelo de seguridad, y muchos otros cambios (que, dicho sea de paso, han irritado a mucha gente, por considerarlos innecesarios y/o por haber sido hechos en sus oficinas, sin pedir opinión a nadie, sin esforzarse lo más mínimo por facilitar o incluso hacer posible que esas cosas pudieran ser incluidas en la rama principal del kernel).

Eso fue con Android, pero Android es Android. Cabe pensar que en este otro "Chrome OS" Google haya empleado a su mejor gente. La falta de respeto a lo establecido sería la misma, pero la genialidad de los programadores podría ser bastante más alta. Teniendo empleada a gente como Rob Pike, creador de Plan 9, ¿alguien cree posible que se dediquen a repensar "como deben ser los sistemas operativos" sin consultarle?

Cabría pensar, si se diera este último caso, que este nuevo SO fuera un gran proyecto de R&D, que incluso mandara a POSIX a tomar viento. O tal vez sea tan solo un envoltorio bonito de Chrome y un nuevo sistema de ventanas super-mega-guai. Me temo que para hacerse una idea real tendremos que esperar a que Google empiece a dar más detalles.

Valencia es la tierra del...sofware libre

2009-07-02T19:00:00.000+02:00

Me acabo de enterar por LWN que Valencia (la comunidad autónoma) está aproximándose cada día más hacia el software libre, demostrando una vez más esas teorías del equilibrio entre el Bien y el Mal. Es decir, que el hecho de tener un gobierno autonómico que ha llevado a Valencia a ser proporcionalmente la comunidad con mayor deuda pública -a pesar de haber vivido una década de vacas gordas con boom inmobiliario que les permitia reducirla o al menos no aumentarla- no es obstáculo para que haya gente competente que tome buenas decisiones buena (para que no me llamen partidista añadiré que Castilla y León, que tambien ha estado gobernada por el mismo partido durante mucho tiempo, es la segunda menos endeudada, solo por detrás de Euskadi).

¿Por qué menciono todos estos datos económicos? Porque creo que son más importantes de lo que parecen, ¿se dedicaría Valencia a derrochar dinero en excentricidades de GNU/hippies con los tiempos que corren? Lo dudo (en realidad no lo dudo, los gobiernos derrochan dinero continuamente, pero sin falsas afirmaciones rotundas los posts quedan mucho peor).

La verdad es que tampoco es algo nuevo en la comunidad valenciana, hace tiempo que tienen su propia distro, y tambien tienen el aparentemente muy famoso gvsig, un programa cuya instalación en Linux es una tortura, por cierto (lo sé por experiencia propia, tuve que ayudar a alguien sin conocimientos de Linux a instalarlo). El proyecto de transición a software libre en realidad comenzó en 2003.

Los miembros del proyecto han escrito un magnífico informe sobre todo el proceso, donde se detalla los retos y dificultades a los que han tenido que enfrentarse. Y la verdad es que tras leerlo, da la impresión de haberse llevado el tema con mucha más seriedad que en Munich. Los dos principios sobre los que se basa todo el asunto son estos:

El proyecto no se financiará con recursos nuevos. Sólo se utilizarán los recursos ya asignados al Servicio de Organización e Informática.
Debe minimizarse la repercusión del proyecto en el trabajo diario del personal de la conselleria. Lo fundamental es el trabajo y no la herramienta

Como se puede ver, no se trata de ninguna guerra de religión, sino que se ha tomado como un objetivo dentro de las actividades del departamento, y al margen de intereses políticos. En el caso de Munich, no solo se ha enfatizado y publicitado exageradamente como "migración a Linux"; la decisión la tomó el ayuntamiento, no el departamento de informática, como consecuencia de ello se ha tomado como un proyecto ideológico de todo-o-nada, con un coste especial de 35€ millones, algo más que lo que hubiera costado mantenerlo todo con software propietario (esto lo han reconocido los propios promotores del proyecto).

Para que luego pensemos que en España no sabemos hacer las cosas bien cuando nos ponemos...

La insoportable levedad de Mono (II)

2009-06-27T22:00:00.001+02:00

(Continuación de la primera parte)

Todas esas razones ya de por si suponen un problema para Mono considerando su objetivo de convertirse en plataforma de programación para Gnome. Pero dejando de lado estas razones que afectan más bien a los programadores, tambien hay que mirar las cosas del lado del usuario. Y en ese lado del campo, la razón por la que Mono no se ha convertido en algo imprescindible para los usuarios de Gnome es la ausencia de aplicaciones.

Personalmente, no tengo Mono instalado en mi sistema, tampoco lo tenía cuando utilizaba Gnome. Es decir, no lo necesito. ¿Tal vez no me he adentrado en el mundo de aplicaciones Mono? Bien, hagámoslo ahora, echemos un ojo a esto y a esto. Pero por mucho que lo miro y remiro, no veo nada que me interese de verdad, no veo nada imprescindible. Si que tengo aplicaciones pygtk de las que no podría prescindir (no podría vivir sin virt-manager), tengo alguna que otra aplicación GTK hecha en C o C++, tengo hasta una aplicación que hace uso de wxWidgets en su versión GTK, amule. Pero nada con Mono. ¿Monodevelop? Tengo eclipse, o Kdevelop. ¿Beagle? Pregunten a Ubuntu porque se pasaron a Tracker. ¿Gnome Do? Los paneles y menus normales me son suficientes. ¿Banshee? Este si que es atractivo, pero yo diría que lo es fundamentalmente por las carencias de rhytmbox. ¿F-spot? Tambien es atractivo, incluso intenté usarlo, pero ciertos bloqueos de la interfaz y fallos diversos me hicieron desinstalarle, y como tampoco soy de los que necesita un gestor de fotos no fue una gran pérdida.

En resumen, que a la hora de la verdad, las únicas aplicaciones Mono que personalmente veo algo interesantes son (aparte de mod_mono, que sin duda será útil para migraciones de ASP.NET) son banshee y f-spot, pero ninguna se me hace imprescindible, puedo prescindir de ambas fácilmente, o encontrar equivalentes superiores. Tal vez para algunas personas si que sean críticas, pero no dejan de poder contarse con los dedos de la mano.

Pero ojo: una de las aplicaciones estrella de Mono que se suelen citar es Tomboy. Y he de reconocer que cuando veo a alguien poner a una aplicación de notas como ejemplo del potencial de Mono lo siento, pero me da la risa. Y no porque las aplicaciones de notas sean cosa de risa -para muchas personas son imprescindibles y les ayudan a mejorar su productividad-, sino porque tampoco es que sean precisamente la aplicación más interesante que se puede enseñar en un escritorio. Cualquier programador novato puede solventar casi todas las necesidades básicas de los usuarios de aplicaciones de notas con una implementación muy simplista (como la que yo uso en KDE). La "wikificación" y la sincronización en red de notas que tiene no serán tan sencillas, pero tampoco son features precisamente críticas -sospecho que muchas aplicaciones de notas no tienen esas cosas simplemente porque les importa un rábano-, y tampoco es que se puedan programar solo usando C#.

El potencial de Mono debería mostrarse a los usuarios no con una aplicación de notas, sino con algo con más sustancia. Algo como, por ejemplo, una reescritura de Evolution (se dice que Mono surgió precisamente como reacción a su inmantenibilidad). O de Gimp, o de Openoffice, o de Pidgin, incluyendo una reimplementación completa de los protocolos de red. ¿Les parece que pido mucho? Es mucho, pero ya ven, no son propuestas exageradas: KDE tiene un equivalente de Evolution, de Gimp, de Pidgin y de OpenOffice.org, todas ellas más que decentes. Y todas ellas en....C++. Si Mono es tan awesome y tan superior a otros lenguajes de programación pues, carajo, deberían tener cosas así. Deberían demostrar su awesomeness con algo acorde a su grandeza, no con aplicaciones de notas.

Teniendo en cuenta la ausencia de aplicaciones imprescindibles, ¿debería ser sorprendente que una distro evite incluir mono por defecto en sus CDs? Las distros no son tan burras como algunos piensan, muchas han incluido e incluyen los drivers de nvidia y ati, y el plugin flash -o facilitan enormemente su instalación- cuando es necesario, cuando se trata de algo verdaderamente imprescindible la teología de licencias pasa a un segundo plano. En el caso de Mono, a mucha gente le desespera, y con razón, tener que incluir todo el runtime para unas pocas aplicaciones. Y a los usuarios tambien, claro.

La lista de los 500 principales

2009-06-23T18:00:00.003+02:00

Hoy acaba de ver la luz la edición de Junio de la lista de los 500 supercomputadores más potentes del mundo.

Las tendencias vienen a ser las de siempre: El 88.60% (443) utiliza Linux -y muchos de ellos utilizan Lustre-, frente a un 87.80% de hace 6 meses y un 85.40% de hace un año. Windows mantiene su cuota de cinco equipos (1%), Mac OS X sale de la lista (lo cual no creo que quite el sueño a ningún maquero), y Sun mantiene 1 equipo con OpenSolaris. En cuanto a procesadores, Intel sigue dominando, IBM es segundo gracias a los Cell, y AMD en tercer lugar.

Lustre es un magnifico ejemplo del desorden interno que sufría Sun (aunque no tan bueno como el de Java). Lustre es un sistema de archivos distribuido opensource diseñado en principio para Linux y muy exitoso: lo utilizan 2/3 de todos los equipos del TOP500, 7 de ellos están entre los 10 más potentes. Su equipo de desarrollo fue comprado para Sun, pero aun hoy Lustre sigue funcionando solo para Linux, con promesas de llegar a funcionar sobre ZFS desde 2007 (puede que se convierta en realidad con Lustre 2.0, que está en versión Alpha).

Como consecuencia (dejando de lado otras ventajas de Linux, como su soporte de Infiniband anterior al de otros sistemas), de los 5 equipos que Sun tiene en el TOP500 (más dos compartidos con Dell), todos excepto uno son Linux. No sé si se capta la ironía: Sun mantiene en nómina a los desarrolladores de Lustre, venden 5+2 equipos que entren en el TOP500 (fuera de esa lista habrá más, claro), todos excepto uno sin su SO, mientras que sus competidores venden alrededor de 330 sistemas con ese mismo software. Hasta desarrollar de cero un sistema de archivos distribuido sobre ZFS les hubiera salido más barato y rápido.