Apoc

Un programador de Sun ha anunciado una cosa llamada APOC, "A Point Of Control", y que básicamente parece ser un equivalente del Active Directory (se distribuye través de LDAP, etc) pero en version libre. No está mal que, ya que Red Hat parece haberse comprado el servidor de directorio de Netscape por capricho, venga alguna otra compañía a ofrecer esas cosas que los entornos windows llevan haciendo hace años.

Sistemas de archivos para Linux en desarrollo

Aunque no se hayan oido demasiadas noticias en los últimos años, el sub-mundo del desarrollo de nuevos sistemas de archivos para Linux es tan frenético como siempre. Hay una buena cantidad de ellos que están siendo desarrollados, algunos de ellos con el propósito de pasar a ser el sistema de archivos por defecto de las distribuciones Linux típicas, otros como experimentos, otros comerciales, y otros simplemente reclaman su derecho a existir.

• Ext4: Ext3 es un sistema de archivos con un diseño anticuado, algo reconocido por la mayoría de hackers del kernel importantes, que han llegado a sugerir aprovechar el tirón de Linux para diseñar un sistema de archivos de cero. Sin embargo, el ser anticuado no quita que no se pueda modernizar, y eso es lo que están haciendo en ext4, a quien están quitando el polvo a ext3 como en su día se hizo a ext2 e incorporando técnicas que pueden hacerlo competir durante unos cuantos años más...solo que este es un rediseño mucho más profundo que lo que ext3 fue para ext2: En ese caso, la compatibilidad del formato del disco se conservó en gran parte, en ext4 para nada. ¿Chapuza, por dedicarse a parchear? Bueno, al margen de que haga falta otro sistema de archivos, renovar ext4 no tiene nada de malo. Recordar que en Linux no hay un "plan de desarrollo", y si los programadores de ext4 (junto con IBM y Bull, que tambien colaboran) quieren mejorar ext4, no es cosa de negárselo porque "lo mejor" sería un sistema de archivos nuevo:
  
  • Aumento de los limites de máximo tamaño de disco soportado
  • Se romperá el límite de 32000 archivos por directorio
  • Extents
  • Delayed allocation. Esta característica es especialmente interesante y mejorará el rendimiento una barbaridad, aunque es curioso que Andrew Morton ya la implementó en el desarrollo de 2.5, cuando se dedicaba a programar. Para que la gente se haga una idea de como funciona Linux, el soporte para esto está desarrollado desde hace tiempo, pero se ha decidido que parte del soporte esté en el VFS, y la interfaz debe ser útil tambien para otros sistemas de archivos, en concreto XFS que soporta esta característica por si mismo y podría ser portado a esta nueva interfaz, asi que aunque el soporte está ya de por si implementado, se están rediseñando continuamente los parches de esta interfaz porque aun no es lo suficientemente buena para soportar XFS.
  • Asignación de múltiples bloques de una sola vez en vez de uno a uno, especialmente útil para lo de delayed allocation.
  • El fsck se acelerará de 2 a 10 veces dependiendo de lo lleno que esté el disco
  • Las tablas de inodos se "fabricarán" de forma dinámica en vez de en tiempo de formateo (aunque esta es probable que no incluya porque aun no está implementada y habría que retrasar ext4 uno o dos años, parece ser) .
  • Checksums en los inodos, los extents, el journal...
  • Atributos extendidos que se incluyen dentro del propio inodo, aumentando la velocidad de acceso a los mismos.
  
  Además de todo esto, hay que tener en cuenta que cualquier sistema de archivos ext3 podrá convertirse a ext4 y disfrutar de las mejoras simplemente montándolo como ext4. Los benchmarks preliminares de ext4 son bastante impresionantes y lo ponen a la altura de sistemas de archivos superiores. Y es que la óptima integración entre linux y ext3/4 y la atención que le prestan todos los hackers de la gestión de memoria y vfs y etc hacen que ext4 exprima al máximo todos los mecanismos de Linux. Asi que aunque los ext sean una "mierda", no por ello van a dejar de dar guerra.


• Btrfs: Si hay un sistema de archivos que aspira a reemplazar el predominio de los ext*, ese es btrfs. En parte una clara imitación de algunas características de ZFS, fue comenzado por un programador de Oracle que anteriormente trabajaba en mantener reiserfs en suse: un hacker conocido, con conocimientos de Linux. Su diseño es moderno, y añade gestión de volumenes a lo ZFS, checksum de cada bloque, snapshots....el desarrollo no es tan rápido como ext4, pero no está ni de lejos paralizado, y está ganando algunos desarrolladores (un tipo de Red Hat ha implementado soporte de atributos extendidos) y tiene como adeptos a algunos de los kernel hackers más importante, que probablemente vean en btrfs el sistema de archivos diseñado de cero que ellos querrían para Linux.


• Nilfs: nilfs es un sistema de archivos de los que se llaman log-based, y está financiado por la NTT. Lo de este tipo de sistema de archivos es una de esas cosas que se basan en un consepto del que se deriva todo lo demás: el espacio del disco duro se trata como una especie de cinta circular, o sea, un "log" un "diario" en el cual se van escribiendo las cosas en el último punto donde se terminara de escribir anteriormente. Cuando tiene que reescribir un archivo, no se reescriben los bloques en los que ya se ha escrito: añade el archivo modificado al último punto donde llegue escribiendo el sistema de archivos. Esto tiene varias implicaciones, la primera es que al añadirse siempre los datos en el log, los datos se escriben siempre secuencialmente y la velocidad de escritura es endiablada, la máxima. La segunda es que no necesita journaling: si el ordenador se reinicia repentinamente la coherencia del sistema está siempre garantizada, solo se pierde el archivo que se ha quedado sin escribir. La tercera es que a no reescribirse nada, se dejan copias antiguas de los archivos: es decir, tiene snapshots por la cara. Pero hay quien dice que estos sistemas de archivos, que tienen un par de décadas de edad, no han tenido éxito porque en el mundo real la implementación no es sencilla y tienen sus desventajas. Sin embargo, aquí está esta implementación.


• LogFS: nilfs no es el único sistema de archivos con diseño de "log": LogFS tambien lo es, y su objetivo es reemplazar al sistema de archivos ya presente en Linux JFFS2....que tambien tiene diseño de "log". Los dos están optimizados para unidades de memoria flash. Y es que la memoria flash prácticamente obliga a utilizar sistemas de archivos con diseño "log", porque las memorias flash soportan un número máximo de reescrituras. El diseño "log" va escribiendo datos solamente al final del "log"...de ese modo el desgaste es uniforme entre todos los bloques de la unidad flash. Un sistema de archivos típico, especialmente uno con journaling, reescribe ciertos sectores críticos muchísimas más veces que otros. ¿Y por qué todo el mundo utiliza FAT32 como sistema de archivos en unidades flash? Pues será porque no hace falta, si no es de cajón que una empresa seria, competente y responsable y llena de gente intelijente como Microsoft hubiera sacado uno específico hace años no solo para el Windows CE/Mobile (que supongo que lo tendrá), sino para todos, ¿no?.


• YAFFS: Otro sistema de archivos diseñado para memorias flash de diseño "log". Se presenta como sustituto de JFFS2, y es de código libre, pero nunca se ha planteado la integración en Linux: de hecho, el autor vende comercialmente versiones relicenciadas y lo ha portado a varios sistemas operativos embebidos. LogFS está más verde que yaffs, puesto que fue empezado despues, pero ya es bastante estable y el autor planea incluirlo en el kernel. Diríase que YAFFS era el sustituto de JFFS2, hasta que apareció LogFS.


• Reiser 4: ¿Qué decir sobre Reiser 4? Si no está incluido ya en el kernel Linux no es ya por cuestiones técnicas (que estaban resueltas casi en su totalidad), sino porque la detención y juicio de Hans Reiser y probable sentencia de encarcelamiento hacen temer a los mantenedores del kernel que el sistema de archivos -que es muy complejo- quede sin mantenimiento por falta de recursos. Y existe la posibilidad de que si es incluido en el kernel, la gente empieze a utilizarle y que al dar fallos o al ser marcado como obsoleto por no estar siendo portado a los futuros cambios del VFS, la gente empiece a reclamar al kernel. Si, Reiser 4 da buenos resultados en algunos benchmarks, pero da mal resultado en otros, y parece más sencillo para muchos seguir con ext4 o incluso con ext5 o btrfs antes que tirarse a una bañera infestada de pirañas.


• Unionfs: Más que un sistema de archivos, unionfs es cosa del VFS: Permite que varios directorios o sistemas de archivos se "unan" en uno solo. Es decir: si tienes un directorio con un subdirectorio "a/" y otro con otro subdirectorio "b/", puedes unirlos con unionfs bajo la apariencia de un mismo sistema de archivos. Este concepto lleva años implementado en los BSD libres, si bien la idea original viene de Plan 9


• Ceph: Un sistema de archivos distribuido diseñado para escalar masivamente.


• Lustre: Lustre es un sistema de archivos distribuido, de código libre bajo la GPL, ya terminado, diseñado por Cluster Filesystems Inc con el objetivo de servir de sistema de archivos "which can serve clusters with 10,000's of nodes, provide petabytes of storage, and move 100's of GB/sec with state-of-the-art security and management infrastructure". No es broma: Lustre es utilizado en 16 de los supercomputadores del top-500...7 de los cuales se encuentran entre los 10 primeros puestos. Lo que hay que destacar de este sistema de archivos es que está disponible tambien para Solaris, y que la compañía fue comprada por Sun hace tan solo dos meses, pero van a seguir soportando Linux....de momento. Porque un servidor, que es muy mal pensado, piensa que Sun podría relicenciar (con todo el derecho del mundo, vaya por delante) Lustre bajo licencia CDDL al integrarlo bajo OpenSolaris, aunque lo más probable es que en un caso así, lo dual-licenciarían..

Estos son todos los que he encontrado.

Sun, acusada de intentar controlar un proyecto

Parece ser que un ex-trabajador de Sun y fundador del proyecto OpenDS - un servidor de directorio escrito....en Java - ha acusado a la compañía de intentar controlar en una carta abierta.

Por lo visto, Sun decidió mover a sus desarrolladores empleados en OpenDS de Estados Unidos a Francia (para que luego digan del intervencionismo francés, ¿o será por Sarkozy?). A este trabajador y fundador del proyecto le echaron de la empresa, junto con otros 4 programadores de OpenDS. Como buenos desarrolladores de software libre, decidieron seguir con el proyecto a título personal. Pero como consideraban que Sun había contribuido mucho al proyecto, decidieron por su cuenta dar a un empleado de Sun un puesto en el órgano de "gobierno" del proyecto. Sin embargo, cuando se pusieron en contacto con Sun para llevar a cabo estos trámites, Sun les explicó que querían que delegaran todo el gobierno del proyecto en manos de un comité gestionado por Sun. En este punto, los trabajadores "despedidos" fueron amenazados con finalizar sus contratos si no aceptaban, pues aunque habían sido "despedidos", el tiempo del contrato continua durante dos meses más (una cosa de Sun, imagino), tiempo que los trabajadores utilizan aparentemente para encontrar otro trabajo.

El tipo este dice que esta es una acción particular de alguien de Sun y que no cree que tenga que ver con las intenciones de Sun respecto al software libre. Quizás tenga razón, pero yo personalmente no creo que sea tan casual, porque no es la primera vez que Sun tiene problemas con el control político de un proyecto de software libre. Openoffice.org es famoso porque su órgano político está controlado por Sun...y para contribuir código a Openoffice tienes que donar el copyright de tu código...¡a Sun! Java y Opensolaris, más de lo mismo. Esto es lo que Sun tiene que decir respecto a la asignación de copyright de OpenSolaris: "Please note that the OpenSolaris project is following the lead of other open source projects -- requiring contributors to jointly assign their copyright on contributed code.". Por "the lead of other open source projects" debe referirse a OpenOffice.org y a GNU, porque lo que es la mayoría de proyectos de software libre...suelen conservar el copyright del dueño. Imagino que con Java debe ser más de lo mismo, además que en la "comunidad Java", Sun tiene derecho a veto, según tengo entendido.

Perdonenme que sea tan paranoico: No es que crea que Sun tiene intención de "controlar" el software libre, pero si que Sun nunca ha terminado de comprender la totalidad del término "software libre". Quizás se deba a que aun están en el poder muchos de esos ejecutivos que, durante años, dijeron que no tenía sentido liberar Java y decían que Sun era la empresa más pro-software libre que existía aun antes de anunciar la liberación de Opensolaris y Java, y cortaban el desarrollo x86 de Solaris. Quizás las nuevas generaciones pro-software-libre no tengan las manos tan libres como querrían, y quizás por eso las cosas andan un poco así, intentando mantener cierta parcela de poder en la práctica. Porque si no, Sun no tendría ningún inconveniente en que cada contribuidor conserve su copyright ni en mantener control sobre la dirección técnica del proyecto. De hecho, si Sun estuviera tan a favor del software libre, ¿por qué Sun no se une al desarrollo del servidor de directorio de Red Hat, en vez de fomentar uno en pañales y que está escrito en Java? ¿O por qué no libera su servidor propietario? Espero que estas cosas se aclaren, para tener que dejar de vigilar a Sun de reojo.