Microsoft ha anunciado la tableta Surface, y el día del anuncio la prensa y toda la gente no dejaba de ponerlo por las nubes, algo comprensible que lo hagan porque parece un buen aparato. Sin embargo, se hace obvio que no es especialmente rompedor. Su gran aportación al mercado es un teclado de 3mm que por su finura puede integrarse en la propia funda, de modo que puede transportarse y utilizarse como portátil en cualquier lado
Es un buen invento, no cabe duda. Pero los chinos ya lo venden por 39€ con gastos de envío gratuitos para el iPad2, que de paso protege contra golpes, y les hay más baratos. Vale, el de Microsoft es mejor, pero quiero decir que tampoco es una algo revolucionario. Pero seamos justos, el hecho de ser una tableta convencional tampoco supone un fracaso. De hecho, el Surface parece una magnífica tableta convencional, capaz de venderse bien. Además, hay mucha gente que no conoce la existencia de los fundateclados opcionales, y debido a ello han seguido utilizando sus portátiles habitualmente. Creo que no me equivoco si pienso que a Apple le hubiera gustado ser el primero en vender algo así.
El asunto interesante es lo que esta tableta implica en el negocio de Microsoft, una compañía que solía dedicarse a hacer software que los fabricantes y ensambladores de hardware preinstalaban. Es obvio que a esa gente no les hace ni puñetera gracia que Microsoft intente competir contra ellos en su propio terreno. Ser "partner" de Microsoft implica algo más que usar sus productos y conseguir descuentos, también incluye colaboración plena a la hora de desarrollar nuevas versiones de Windows. Con el Surface, sin embargo, parece que Microsoft ni tan siquiera les ha avisado de su existencia y presentación.
Esta ocultación plantea unas cuantas incógnitas. Bien podría ser, como sugiere el artículo anteriormente enlazado, una especie de aviso a sus partners para que se pongan las pilas, una forma disimulada de decirles con arrogancia "esto es lo que tenéis que fabricar, merluzos". Es una posibilidad, aunque me parece muy poco probable que Microsoft tenga que recurrir a esto para comunicarse con ellos. Hay otra, que es la que más se ha mencionado, y es que Microsoft se está planteando en serio convertirse en un vendedor de hardware más.
Esta opción es particularmente interesante, porque significaría que eso de una empresa haciendo software y otra integrando hardware se ha acabado, nos estaríamos adentrando en una nueva era en el que las únicas empresas relevantes son las que saben juntar hardware y software. En otras palabras, significaría que el modelo de Apple de integrar hardware y software ha pasado de ser una excepción en la informática de consumo, de la que se hablaba hace no tantos años como una reliquia histórica destinada a desaparecer, a convertirse en el modelo a seguir.
Si esa es la intención de Microsoft, no cabe duda que nos esperan tiempos interesantes en el sector. Un sector donde el protagonista no es el hardware, sino el software y cómo se integra ese software con el hardware, con la nube, con otros equipos con el mismo software, y con las necesidades e intereses de los desarrolladores de aplicaciones. El hardware ha pasado a ser una función residual externalizada a Asia, y precisamente por ser algo residual y fácil de contratar, sólo las empresas con software y programadores capaces de darle vida podrían tener éxito en él. Si queremos un "año del escritorio Linux" antes de irnos a la tumba, quizás deberíamos prestar atención a estas tendencias.
24 de junio de 2012
18 de junio de 2012
El renacer de XFS
La vida de XFS da para muchas curiosidades. La publicación de su código con licencia GPL y port fue uno de los hitos fundamentales de la historia de Linux, uno de esos cambios cruciales que permitieron a Linux empezar a ser tomado muy en serio. XFS puede considerarse como el mejor sistema de archivos hasta la aparición de
ZFS.
Sin embargo, la relación entre XFS y la comunidad linuxera han tenido varios altibajos. Nunca fue capaz de reemplazar a los Ext como sistema de archivos por defecto, tal y como cabría esperar en un principio. Su uso en los instaladores siempre estuvo considerado como algo alternativo, no ya respecto a la familia Ext sino incluso respecto a Reiserfs. A este confinamiento a un papel secundario contribuía mucho, en mi opinión, la falta de apoyo de un comunidad muy importante, la del kernel.
Y es que durante mucho tiempo, SGI intentaba mantener sincronizadas las bases de código de Linux e Irix, lo cual impedía una transición completa y hacía que XFS fuese un "ciudadano incómodo" que no se integraba muy bien con Linux. Estos problemas han sido solucionados poco a poco hasta quedar bien resueltos, pero el otro gran problema era que si bien XFS era muy bueno "con archivos grandes", como se solía decir, no lo era para otras cosas.
En concreto, XFS era verdaderamente malo con cualquier uso extensivo de metadatos. Pero malo, malo. Ext4 puede ser 20-50 veces más rápido en operaciones con metadatos, una descompresión de un .tar que en Ext4 toma 3 ó 4 segundos, en XFS tarda 60, según palabras de los desarrolladores de XFS. Y si bien mucha gente utilizó XFS para su ordenador de escritorio creyendo (erróneamente) que era más rápido, la gente del kernel no se dejaba engañar, ni tampoco los mantenedores de las distribuciones.
Para entender por qué XFS era tan lento, hay que recordar algo que se ha repetido aquí varias veces: al igual que hay navegadores lentos y rápidos para ejecutar el mismo código javascript, en un sistema de archivos lo fundamental es su implementación, mucho más que su formato de disco. El código de Ext3 y 4 tienen una optimización que permite unir varias transacciones que estén en memoria antes de ser escritas a disco en una sola, de modo que son registradas en el journal y posteriormente al disco simultáneamente. Al descomprimir un .tar se crean miles de archivos, cada uno de los cuales es internamente una transacción, y Ext4 las unifica de modo que se convierte en una sola.
XFS no tenía esa clase de optimizaciones, pero finalmente la han implementado. Y además, unas cuantas mejoras más de escalabilidad y rendimiento, todo ello sin haber modificado el formato del disco (que sigue siendo excelente). El resultado de todo este trabajo sitúa a XFS en un lugar muy interesante: un sistema de archivos de mejor diseño que Ext4, un código de igual o mejor calidad, un rendimiento igual o superior en cualquier situación (muy superior, cuando hablamos de muchos discos y CPUs), igual de bien integrado con el resto del kernel que Ext4, y tan bien mantenido como Ext4 (Red Hat ha contratado a varios desarrolladores históricos de XFS)...la conclusión obvia parece ser: ¿para qué seguir usando Ext4?
Esa es la atrevida propuesta que hace un desarrollador de XFS en este vídeo (que es la motivación de este post), y que viene a resumirse en que el futuro de los sistemas de archivos en Linux será usar Btrfs por defecto, y XFS para quien necesite rendimiento y escalabilidad extra. Esta última distinción, que indica una discapacidad de Btrfs, puede sorprender, pero tiene algo de cierto: XFS no duplica los metadatos por defecto, ni los comprime, ni provoca fragmentación masivama debido a copy-on-write, lo cual le permite ser más escalable en situaciones extremas, y por tanto le permite tener un futuro sólido en grandes servidores, a pesar de no ser un sistema de archivos "de última generación". Además, están planeando un cambio de formato de disco en el cual piensan incluir checksums de metadatos, añadir información extra para facilitar la tarea del fsck, e implementar la capacidad de hacer un "scrubbing" online; es decir, intentarán implementar algunas de las ventajas de Btrfs, todo ello con vistas a seguir siendo un buen sistema de archivos en el futuro, algo que Ext4 no podrá hacer con facilidad.
Mi veredicto personal es que probablemente tiene razón, y que a medida que Btrfs reemplace a Ext4 como sistema de archivos por defecto, XFS lo acabará superando también como sistema de archivos alternativo.
Sin embargo, la relación entre XFS y la comunidad linuxera han tenido varios altibajos. Nunca fue capaz de reemplazar a los Ext como sistema de archivos por defecto, tal y como cabría esperar en un principio. Su uso en los instaladores siempre estuvo considerado como algo alternativo, no ya respecto a la familia Ext sino incluso respecto a Reiserfs. A este confinamiento a un papel secundario contribuía mucho, en mi opinión, la falta de apoyo de un comunidad muy importante, la del kernel.
Y es que durante mucho tiempo, SGI intentaba mantener sincronizadas las bases de código de Linux e Irix, lo cual impedía una transición completa y hacía que XFS fuese un "ciudadano incómodo" que no se integraba muy bien con Linux. Estos problemas han sido solucionados poco a poco hasta quedar bien resueltos, pero el otro gran problema era que si bien XFS era muy bueno "con archivos grandes", como se solía decir, no lo era para otras cosas.
En concreto, XFS era verdaderamente malo con cualquier uso extensivo de metadatos. Pero malo, malo. Ext4 puede ser 20-50 veces más rápido en operaciones con metadatos, una descompresión de un .tar que en Ext4 toma 3 ó 4 segundos, en XFS tarda 60, según palabras de los desarrolladores de XFS. Y si bien mucha gente utilizó XFS para su ordenador de escritorio creyendo (erróneamente) que era más rápido, la gente del kernel no se dejaba engañar, ni tampoco los mantenedores de las distribuciones.
Para entender por qué XFS era tan lento, hay que recordar algo que se ha repetido aquí varias veces: al igual que hay navegadores lentos y rápidos para ejecutar el mismo código javascript, en un sistema de archivos lo fundamental es su implementación, mucho más que su formato de disco. El código de Ext3 y 4 tienen una optimización que permite unir varias transacciones que estén en memoria antes de ser escritas a disco en una sola, de modo que son registradas en el journal y posteriormente al disco simultáneamente. Al descomprimir un .tar se crean miles de archivos, cada uno de los cuales es internamente una transacción, y Ext4 las unifica de modo que se convierte en una sola.
XFS no tenía esa clase de optimizaciones, pero finalmente la han implementado. Y además, unas cuantas mejoras más de escalabilidad y rendimiento, todo ello sin haber modificado el formato del disco (que sigue siendo excelente). El resultado de todo este trabajo sitúa a XFS en un lugar muy interesante: un sistema de archivos de mejor diseño que Ext4, un código de igual o mejor calidad, un rendimiento igual o superior en cualquier situación (muy superior, cuando hablamos de muchos discos y CPUs), igual de bien integrado con el resto del kernel que Ext4, y tan bien mantenido como Ext4 (Red Hat ha contratado a varios desarrolladores históricos de XFS)...la conclusión obvia parece ser: ¿para qué seguir usando Ext4?
Esa es la atrevida propuesta que hace un desarrollador de XFS en este vídeo (que es la motivación de este post), y que viene a resumirse en que el futuro de los sistemas de archivos en Linux será usar Btrfs por defecto, y XFS para quien necesite rendimiento y escalabilidad extra. Esta última distinción, que indica una discapacidad de Btrfs, puede sorprender, pero tiene algo de cierto: XFS no duplica los metadatos por defecto, ni los comprime, ni provoca fragmentación masivama debido a copy-on-write, lo cual le permite ser más escalable en situaciones extremas, y por tanto le permite tener un futuro sólido en grandes servidores, a pesar de no ser un sistema de archivos "de última generación". Además, están planeando un cambio de formato de disco en el cual piensan incluir checksums de metadatos, añadir información extra para facilitar la tarea del fsck, e implementar la capacidad de hacer un "scrubbing" online; es decir, intentarán implementar algunas de las ventajas de Btrfs, todo ello con vistas a seguir siendo un buen sistema de archivos en el futuro, algo que Ext4 no podrá hacer con facilidad.
Mi veredicto personal es que probablemente tiene razón, y que a medida que Btrfs reemplace a Ext4 como sistema de archivos por defecto, XFS lo acabará superando también como sistema de archivos alternativo.
7 de junio de 2012
Chris Mason se va de Oracle
Hoy es noticia linuxera que Chris Mason, creador y principal programador de Btrfs, anuncia que se va de Oracle, la compañía en la que trabajaba. Y como el autor de este blog piensa que los programadores y sus circunstancias son muy importantes, hay que mencionarlo. Empecemos diciendo que para la comunidad linuxera es sin duda un gran alivio que un programador tan importante para Linux abandone una compañía que pretende que las APIs puedan ser copyrighteables. Para nuestra desgracia, no se tienen noticias de que Chris Mason haya prendido fuego a Oracle a su salida.
Como cuenta en el propio anuncio, no hay nada que temer por Btrfs, seguirá manteniéndolo y desarrollándolo como siempre. Sin embargo, algunos hemos notado desde hace un tiempo que Chris Mason no escribía tanto código como solía (el retraso del fsck es un ejemplo de esto), ni estaba tan presente en el día a día. Que estaba ocupado con otras cosas, vaya. Y aunque no era una alarma crítica para Btrfs, puesto que ya tiene programadores de sobra, era desde luego una situación poco deseable (el retraso de fsck es, de nuevo, una prueba de ello).
La nueva compañía en la que trabajará será Fusion IO. De este compañía se pueden decir varias cosas. La primera, que se dedica a desarrollar memoria flash para almacenamiento SSD. La segunda, que esta compañía ya tiene en su nómina a Jens Axboe, el principal programador y mantenedor de la capa de bloque de Linux (con el objetivo evidente de que Linux funcione muy bien con SSDs). Y la tercera, que es donde trabaja Steve Wozniak como "chief scientist".
Si, ese Wozniak.
Cabe decir, por tanto, que Chris Mason está en un buen lugar y que puede que incluso sea mejor para Btrfs y Linux en general.
Como cuenta en el propio anuncio, no hay nada que temer por Btrfs, seguirá manteniéndolo y desarrollándolo como siempre. Sin embargo, algunos hemos notado desde hace un tiempo que Chris Mason no escribía tanto código como solía (el retraso del fsck es un ejemplo de esto), ni estaba tan presente en el día a día. Que estaba ocupado con otras cosas, vaya. Y aunque no era una alarma crítica para Btrfs, puesto que ya tiene programadores de sobra, era desde luego una situación poco deseable (el retraso de fsck es, de nuevo, una prueba de ello).
La nueva compañía en la que trabajará será Fusion IO. De este compañía se pueden decir varias cosas. La primera, que se dedica a desarrollar memoria flash para almacenamiento SSD. La segunda, que esta compañía ya tiene en su nómina a Jens Axboe, el principal programador y mantenedor de la capa de bloque de Linux (con el objetivo evidente de que Linux funcione muy bien con SSDs). Y la tercera, que es donde trabaja Steve Wozniak como "chief scientist".
Si, ese Wozniak.
Cabe decir, por tanto, que Chris Mason está en un buen lugar y que puede que incluso sea mejor para Btrfs y Linux en general.
Suscribirse a:
Entradas (Atom)