Tenemos una solución a su medida para cada necesidad.

  • Teléfonos: 91 229 56 76 / 615 02 49 05.
  • Fax: 91 229 56 76.
  • EMail: david@web2times.com.
  • Puede contactarnos también a través de nuestro formulario.

Desarrollo / Internet / Publicidad / Creatividad

Desarrollo / Internet / Publicidad / Creatividad

D'Oh!


  • Curiosidades python

    Me ha parecido curiosa esta manera de corregir un typo en todas las páginas de un wiki. No sabía que existían este tipo de librerías, python siempre logra sorprenderme.


  • Novedades en systemd
    Desde que Lennart Poettering, autor de Pulseaudio, anunció el nacimiento de systemd, un reemplazo de init/upstart (si quieren, también pueden leer el enlace anterior en este otro sitio en el que me copian el texto del blog sin poner ni una cita), han pasado 4 meses. Suele pasar en ocasiones que un proyecto sale a la luz y la luz lo seca o lo debilita como a un brote reciente (caso de Wayland, tan revolucionario y tan raquítico a la vez). No ha sido este caso. Systemd se ha saltado etapas de crecimiento a una velocidad pasmosa y ya se acerca a árbol, como puede comprobarse en este post de Lennart sobre la evolución del proyecto.

    En primer lugar, han implementado los varios tipos de "unidades" que habían prometido y faltaban. Han añadido las unidades timer. Su propósito es sustituir la funcionalidad de cron (aunque de un vistazo a la documentación es evidente que aun le falta funcionalidad para lograrlo por completo). Otro tipo de unidad es path, que puede utilizarse para invocar automáticamente un servicio cuando hay actividad en alguna parte del sistema de archivos, o cuando se crea un directorio determinado (es, por así decirlo, una especie de herramienta para usar inotify). Y el último tipo de unidad implementado es swap, que indica a systemd las particiones de intercambio que hay que montar (recordemos que, entre otras cosas, systemd pretende conseguir que /etc/fstab sea teóricamente innecesario).

    Otra novedad importante es que systemd se ha integrado con todo lo que ha encontrado por delante: SELinux a la hora de crear directorios o sockets, TCP wrappers, PAM, y los inicios/paradas de los servicios se reportan al sistema de auditoría del kernel. También se ha integrado el sistema con D-Bus, de modo que los servicios que utilicen las interfaces D-Bus para comunicarse con los clientes pueden informar de ello en sus archivos de configuración, y systemd se encargará de arrancar automáticamente esos servicios cuando un cliente intente comunicarse con él (básicamente se trata de lo mismo que se hace con los sockets de red, pero aplicado a las conexiones D-BUS).

    Otra novedad, muy curiosa, es cómo han utilizado las características de systemd para conseguir que no se pierda absolutamente ningún mensaje destinado a archivos log, desde el arranque del sistema hasta su apagado. Nada más iniciarse, systemd se pone a escuchar en el socket /dev/log, y envía los mensajes que allí se envían al buffer del kernel (el de dmesg). Posteriormente se arranca syslog (a quien se cede el control de /dev/log), el cual, como primera operación, guarda ese buffer del kernel en el disco. De ese modo, no se pierde ni un solo mensaje. Es más, si syslog muere por cualquier razón, o cuando el sistema se está apagando y hay que apagar el proceso, se restablece la comunicación /dev/log -> dmesg.


    Respecto a la adopción, parece que systemd va a ser el sistema de inicio por defecto para Fedora 14. A esto ayuda, no cabe duda, que los mecanismos de systemd hacen posible convivir servicios con configuraciones systemd y otros con configuraciones antiguas sin que haya problemas de ningún tipo. Upstart necesitó ser tremendamente conservador para evitar problemas (pagando como precio el no estar aun terminado, de acuerdo con su autor). Systemd no necesita tantos cuidados. Quizás sea esa la razón por la que ya hay paquetes y scripts disponibles para OpenSUSE, Debian, Gentoo y Arch. Aunque en Debian habría problemas para utilizarlo como sistema de inicio por defecto, porque systemd sólo funciona para Linux y Debian está empeñada en soportar kernels BSD...


  • Dos pájaros de un tiro
    A Oracle solo le faltó anunciar algo de MySQL para hacer triplete. Android y Opensolaris apuntalados por Larry Ellison el mismo día. Desde que se anuncio la compra de Sun todo fueron especulaciones sobre qué haría Oracle con su rutilante compra a precio de saldo, la más común en círculos linuxeros, incluido este blog, era la sospecha de que el señor Ellison antepondría absolutamente todo a su avaricia, como así ha sido. En fin, fue bonito mientras duró. Sirvan estas líneas de apoyo póstumo a Sun y su plan de apoyo al software libre.

    Como ya saben, este blog se precia de no ser una de esas fotocopiadoras que regurgitan lo que otros escriben en la blogosfera, aquí se generan vómitos propios. Por lo tanto asumo que ustedes ya habrán leído la avalancha de noticias sobre el tema. Lo que le preocupa a este humilde servidor de ustedes es...¿y ahora qué?

    El asunto de Android y su implementación de Java es peliagudo. Uno no acaba de adivinar el propósito de Oracle. Un sudor frío me recorre la espalda al pensar que tal vez quería la posesión de Java simplemente para exprimir la dependencia que de Java tienen quienes han escrito miles y miles de líneas de código en él. ¿Qué otra opción cabe? Si su intención es mantener la unidad de Java, nada les ayudará a lograr ese fin declararlo tecnología propiedad exclusiva de Oracle. A las plataformas de desarrollo y lenguajes de propósito general se les asume una libertad similar a la de los estándares de Internet. Que te demanden por no seguir un estándar o unas librerías al pie de la letra es una manera de decir: "Esto es nuestro, no se atreva a tocarlo, limítese a usar nuestros programas". Se dirá que Java en realidad sí es verdaderamente libre, con la pequeña condición de adherirse incondicionalmente al estándar, pero hay analogías, salvando las diferencias, con el modelo de sindicato único de ciertos regímenes.

    Naturalmente, Oracle es libre de hacer lo que desee con su propiedad, pero Java ya no será verdaderamente libre, al menos para sus usuarios. Y esto es un cambio radical para el que sigue siendo uno de los principales lenguajes de programación del mundo. Porque una de las claves para la construcción del imperio de Java fue una especie de consenso con el resto de la industria. La única razón por la que una compañía como IBM apoyó con tanta fuerza este lenguaje creado por el que en su día era quizás su más fiero competidor, es que sabían que Sun jamás se iba a aprovechar de su posición para fastidiar a los clientes de IBM. Es de imaginar que los señores de Big Blue estarán hoy pero que muy enfadados y preocupados por este rumbo escogido por Oracle. De hecho, teniendo en cuenta que Larry Ellison ha declarado a IBM como su mayor enemigo, ¿no es posible que las adquisición de Java no tenga otro objetivo que fastidiar a IBM?

    El tema de OpenSolaris es menos preocupante, porque podemos ser cínicos y tomarlo como buenas noticias para Linux. Por muy Linuxero que uno fuera, en su día la liberación de Solaris solo cabía aceptarse como buena, muy buena noticia para el software libre. Pero ahora, aunque el software libre salga perdiendo, Linux en particular sale reforzado, ya que el escenario principal de sistemas operativos de software libre vuelve a ser exclusivamente suyo. Incluso si Oracle hace de Solaris un gran sistema operativo, con más maravillas del tipo de ZFS, sus competidores por inercia invertirán en Linux...en los hilos de los sitios de noticias, hay personas interesadas en dejar OpenSolaris y volver a Linux (o al menos a FreeBSD, que por otra parte sale mal parado por todo este asunto). No se puede pillar a los usuarios de OpenSolaris igual que a los de Java. Así que vaya lo uno por lo otro.


  • Las novedades de Linux 2.6.35
    Linus ha anunciado la versión 2.6.35, como siempre aquí está la traducción castellana de las novedades principales. A vista de pájaro, esta versión añade soporte para repartir automáticamente la carga de red entrante entre varias CPUs, soporte de Direct I/O para Btrfs, un modo de journaling alternativo para XFS, inclusión de la interfaz del depurador KDB, varias mejoras de perf, aceleración de vídeo H.264 y VC1 en hardware Intel G45+, soporte del futuro Intel Cougarpoint, un sistema de defragmentación de la memoria, soporte de L2TP versión 3 (RFC 3931), varios drivers y muchas pequeñas mejoras más. Lista completa en inglés aquí.


    · Reparto automático entre varias CPUs del tráfico de red de entrada: Las tarjetas de red actuales han mejorado su rendimiento hasta el punto de que para una sola CPU moderna es cada vez más difícil mantener el ancho de banda de recepción al máximo. Dos nuevas características, contribuidas por Google, ayudan a repartir automáticamente la carga de los paquetes de red entrantes entre varias CPUs (los salientes ya se reparten por si solos). El procesado de protocolos(IP, TCP) se ha modificado para que pueda hacerse en paralelo. Cada dispositivo de red utiliza diferentes heurísticas para decidir en qué CPU se procesará el paquete (hash de la cabecera del paquete, afinidad con la CPU en la que se está ejecutando la aplicación que lo va a recibir). Esta característica emula por software lo que una tarjeta de red multiqueue hace en hardware. Un benchmark de 500 instancias del test netperf TCP_RR con 1 byte de petición y respuesta en una e1000e montada en un servidor con CPU Intel de 8 cores ascienden de 104K tps a 303K tps. Un test RPC con 100 threads en cada host, va de 103K tps a 223K, y con menos latencia.

    · Mejoras Btrfs: Direct I/O y -ENOSPC completo. Direct I/O es una técnica utilizada para saltarse el caché a la hora de escribir. Esto daña el rendimiento (es como montar un sistema de archivos en modo "sync"), pero es utilizado extensivamente en grandes bases de datos a las que les gusta implementar su propio cache optimizado. -ENOSPC completo: Linux 2.6.32 ya tenía soporte de -ENOSPC para el uso común del sistema de archivos, pero existían varios casos raros en ciertas operaciones complejas, como operaciones de gestión de volumenes, en los que podía haber fallos. El código -ENOSPC de esta versión maneja correctamente todos los casos: balanceo de espacio libre, gestión de discos, logging de fsync y otros.

    · XFS delayed logging: Esta versión añade un nuevo modo de journaling para XFS llamado "delayed logging", que ha sido modelado según los sistemas de journaling de Ext3/4 y reiserfs. Permite acumular múltiples transacciones asíncronas en memoria. La reducción del ancho de banda utilizado para el log decrece en gran medida, y las cargas que hacen un uso intensivo de los metadatos aumentan su rendimiento en la misma proporción. El formato de disco del journal no ha cambiado, solo las estructuras en memoria y el código. Esta característica es aun experimental, asi que no está recomendada excepto para pruebas. Puede activarse con la opción "-o delaylog"

    · Frontend del depurador KDB: Linux ha tenido un depurador desde 2.6.26, llamado Kgdb. Pero desde hace años existen dos depuradores para Linux, Kgdb y KDB. La diferencia entre ambos siempre fue que Kgdb requiere un ordenador adicional en el que ejecutar una instancia de gdb, que permite una depuración profunda. KDB, en cambio, puede utilizarse en el mismo ordenador, pero sus características de depurado son más simples. En esta versión se ha incluido también el depurador KDB, pero modificado para funcionar sobre los mecanismos internos de KGDB.

    · Mejoras de perf:
      - Modo "live" perf-inject: Hasta ahora, los usuarios tenían que ejecutar "perf record" y "perf report" en dos comandos diferentes. Perf-inject introduce un modo "live", que permite grabar y reportar en un solo comando, como por ejemplo perf record -o - ./hackbench 10 | perf inject -v -b | perf report -v -i - . Pero esto es demasiado complejo, asi que se ha añadido soporte para invocar automáticamente el modo live si no se especifica record/report. Por ejemplo: perf trace rwtop 5. Cualquiera de los scripts listados en 'perf trace -l' pueden utilizarse directamente el modo live.
      - perf kvm: Una herramienta para monitorizar el rendimiento de las VMs desde el host.
      - perf probe: Soporte para acceder a miembros de las estructuras de datos. Con est, perf-probe acepta miembros de estructuras (es decir, acepta los operadores punto '.' y flecha '->') como argumentos. Ejemplos: # perf probe --add 'schedule:44 rq->curr'. O # perf probe --add 'vfs_read file->f_op->read file->f_path.dentry'
      - Mejorar --list: para mostrar las sondas existentes con número de línea y nombre de archivo. Esto permite comprobar fácilmente qué linea está "sondeada". Por ejemplo:
    # perf probe --list
    probe:vfs_read (on vfs_read:8@linux-2.6-tip/fs/read_write.c)
       - Implementación de una UI en la consola con newt.

    · Mejoras gráficas: i915: Soporte de aceleración para vídeo H.264 y VC1 en hardware G45+, soporte del futuro Intel Cougarpoint, monitorización de energía y autorefresco de memoria en hardware Ironlake. Radeon: Trabajo inicial para la gestión de energía, simplificación y mejora del reseteo de GPU, implementación varias partes importantes para soportar chips Evergreen, permitir el uso de VRAM no mapeable, soporta para cuando no hay salidas de vídeo conectadas.

    · Compactación de memoria: Este es un mecanismo que trata de reducir la fragmentación externa de la memoria que intenta agrupar las páginas utilizadas y las libres en un gran bloque de páginas usadas y un gran bloque de páginas libres, lo que permite hacer asignaciones de memoria grandes que no son posibles si hay fragmentación. La implementación consiste en dos escanners, uno de páginas a migrar, que empieza a buscar páginas utilizadas por el principio de la zona de memoria, y otro de páginas libres, que empieza a buscar páginas libres por el final. Cuando ambos escanners se encuentran en el medio de la zona, se mueven las páginas utilizadas al lugar de las libres. Las pruebas han mostrado que la cantidad de I/O requerido para satisfacer una gran asignación disminuye drásticamente. La compactación puede activarse de tres modos diferentes: manualmente, escribiendo algún valor a /proc/sys/vm/compact_memory. Puede activarse manualmente, pero para una sola zona determinada, escribiendo algún valor a /sys/devices/system/node/nodeN/compact. Y también se activa automáticamente cuando no se consigue asignar una gran porción de memoria.

    · Soporte para múltiples tablas de ruta multicast: normalmente, un router multicast ejecuta un demonio en espacio de usuario que decide con un paquete fijándose en las direcciones de origen y destino. Esta característica añade soporte para múltiples tablas de rutas multicast, así el kernel es capaz de tomar las interfaces y las marcas de los paquetes y ejecutar múltiples demonios en espacio de usuario simultaneamente, cada uno manejando una sola tabla.

    · Soporte de L2TP versión 3 (RFC 3931): Esta versión añade soporte para Layer 2 Tunneling Protocol (L2TP) version 3, RFC 3931.

    · Protocolo CAIF: Se trata de un protocolo utilizado por módems ST-Ericsson.

    · ACPI Platform Error Interface: Soporte para la ACPI Platform Error Interface (APEI). Este sistema mejora especialmente la gestión de NMI (interrupciones no enmascarables). Además, soporta una tabla para guardar errores MCE en flash.


    Esto viene a ser todo. Como siempre, aquí está la lista completa.


  • Lo táctil entra en el escritorio
    Apple ha anunciado un nuevo invento: el Magic Trackpad. Me resulta personalmente muy gracioso, porque la semana pasada sin ir más lejos a un servidor le llegó a casa su nueva tableta Wacom Bamboo Touch & Pen: Una tableta gráfica con capacidades táctiles. Que venía a sustituir a mi antigua Bamboo no-táctil. Efectivamente, uso tabletas gráficas como reemplazo del ratón. Por eso me llama la atención este asunto.

    El nombre del invento, "Trackpad", le hace honor, ya que está lejos de ser una tableta gráfica. Lo de Apple es, literalmente, un trackpad gigante, algo inútil para diseño gráfico, donde la sensibilidad a la presión de los lápices de las tabletas gráficas gana por goleada. Está pensado por tanto para ser utilizado como reemplazo del ratón, que irónicamente es para lo único que yo uso mi tableta. Para serles sincero, de haber sabido de la existencia de este aparato una semana antes, no me hubiera comprado mi tableta. Y no tanto porque esté diseñado explícitamente para lo que yo quiero usarlo sino sobretodo porque es 30 eurazos más barato (seguramente por prescindir de la sensibilidad del lápiz de una tableta gráfica). Aunque he de decir que las capacidades gráficas de un tableta son algo por lo que merece la pena pagar 30€ y más (aunque si soy totalmente sincero el entorno ideal que me gustaría probar a día de hoy sería un aparato con formato iPad conectado vía wireless a mi ordenador)

    Pero lo que me sorprende de este aparato es la generalización de las interfaces táctiles. Hace dos días que los fabricantes de teléfonos móviles se volvieron locos por las pantallas táctiles, y ya tenemos cosas táctiles metiéndose en los escritorios. Que Apple se haya molestado en fabricar este aparato por ellos mismos deja claro que creen en lo táctil como elemento primario de interacción también para el escritorio, es decir, para todo tipo de dispositivos. Eso lo ha dejado bastante claro el iPad, que, entre otras cosas, se vende bien porque la gente normal prefiere mil veces una pantalla táctil al dispositivo infernal de los portátiles: si, también es un trackpad, pero su ridículo tamaño hace que se tengan que aplicar al puntero velocidades de aceleración enormemente diferentes (aceleración enorme en movimientos rápidos, cuando se quiere transportar el puntero a grandes distancias, aceleración casi nula en movimientos lentos, para fijar el puntero exactamente donde queremos ponerlo) y muy poco intuitivas (la degradación de aceleración rápida a lenta es brusca). Por eso el gadget más utilizado en los portátiles tras el cargador -que el iPad también evita prescindiendo de esos procesadores rapidísimos que tanta gente dice que Apple debería haber utilizado- es un miniratón.

    Pero una vez aumentado el tamaño del trackpad esas divergencias de aceleración se aminoran y pasan a ser las del ratón de toda la vida (que también tiene aceleración cambiante) . Si creen que algo así es poco intuitivo, se equivocan. En realidad, no se trata de una eliminación del ratón, sino de su perfeccionamiento. Utilizamos el ratón para mover un puntero, y los botones para iniciar acciones, pero para ello dependemos de esos trozos de plástico que ponemos debajo de nuestros manos para que una luz intensa o bolita detecte el movimiento. Un trackpad o una tableta con capacidades táctiles no pretenden cambiar esto, sino prescindir del plástico y empujar el puntero de una manera diferente.

    Y puedo asegurarles -lo he podido probar en mi Wacom- que acercar el puntero a un botón con la sensibilidad de las yemas de los dedos es más intuitivo que hacerlo empujando un trozo de plástico, y que hacer click dejando caer el dedo es más cómodo que accionando el mecanismo de un ratón (aunque al principio se cuesta acostumbrarse). Eso sin entrar en poder hacer scrolling en el navegador -donde seguramente pasen casi todo el tiempo- simplemente arrastrando dos dedos. Mención aparte es la capacidad de las tabletas gráficas, cuando se usa con lápiz, de poder configurarse en modo "absoluto", es decir, que cada punto de la tableta pasa a tener un equivalente en la pantalla, de modo que la esquina inferior izquierda lleva siempre a la esquina inferior izquierda de la pantalla, no hay "arrastre": A mi esta funcionalidad me encanta, pero en la funcionalidad táctil parece ser mejor la técnica de arrastre. Parece ser que todo es cuestión de gustos. Si quieren probar algo nuevo, les recomiendo comprarse una Wacom Bamboo Touch o el Magic Trackpad. Eso si, en Linux el soporte de Wacom está presente (ellos mismos pagan a un programador para que lo soporte) pero necesita mejoras en sus capacidades táctiles, y del Magic Trackpad de momento no esperen nada.


  • Caraterística segura del próximo modelo de iPhone
    "La mejor calidad de recepción de todo el mercado".

    En serio, conociendo la forma tradicional de actuar de Apple, y tras el duro golpe a su orgullo -por muchas explicaciones que den, tener que regalar un protector de goma es una humillación a su imagen- me parece inevitable.


  • OpenSolaris lanza un ultimatum a Oracle
    Según nos hemos enterado por el blog de un tal Ben Rockwood, el OpenSolaris Governing Board (OGB), o sea, la máxima entidad administrativa de la comunidad OpenSolaris, ha lanzado un ultimatum a Oracle: O envían un representante de la compañía para tratar el futuro de la comunidad y del desarrollo de OpenSolaris antes del 16 de Agosto, o la OGB se autodisolverá y devolverá la gestión de la comunidad a Oracle, algo que vendría a ser equivalente a certificar su muerte.

    Esta medida drástica sin duda ha sido provocada por la clamorosa ausencia de actualizaciones de OpenSolaris. Se suponía que su próxima versión debería haber visto la luz en Marzo (tras haber sido retrasada un mes). En Marzo no apareció nada, y se dijo a la comunidad que la nueva versión se retrasaría hasta Junio. Estamos a principios de Julio, y ni rastro de nuevas versiones. Si hay motivos razonables que justifiquen tal retraso, Oracle no se los ha comunicado a la comunidad, no ha dado ni una sola explicación.

    En un post de hace dos días, relacionado con este asunto, un tal Giovanni Tirloni revela como el número de casos PSARC (un sistema burocrático para hacer propuestas de nuevas características de Solaris) que no son revelados a la comunidad ha aumentado drásticamente hasta un 30% del total. Dicho de otra manera, que Oracle está planeando las nuevas características de Solaris en secreto, al margen de la comunidad. Desde luego todas estas cosas no son señales esperanzadoras. Esta situación es la que empuja a la OGB a tomar la medida drástica del ultimatum, a forzar a Oracle a aclarar sus planes de software libre, o a sincerarse y acabar con la farsa.

    ¿Qué hará Oracle? Difícil adivinarlo. Por las declaraciones hechas hasta hoy, no parece que tengan intención alguna de hacer que Solaris vuelva a ser un SO completamente propietario. Lo revelado hasta hoy apunta más bien a que quieren hacer una mezcla de partes privativas y libres con mayor presencia -mayor de la que ya de por si hacía Sun- de partes privativas. De ir por ese camino, es dudoso que la comunidad acepte alegremente tales reglas, y aun aceptándolas OpenSolaris no dejaría de ser una farsa que jamás desarrollaría una verdadera comunidad. Algunos en la comunidad hablan ya de volver a Linux/FreeBSD.

    De matar Oracle la utopía de un Solaris verdaderamente libre, la única esperanza estaría en algo como Nexenta, que es una compañía análoga a Red Hat, con su distro de OpenSolaris propia, con la que es capaz de sacar algún dinero con el que contratar a programadores propios e impulsar el desarrollo del SO libre ellos solos. Claro que también cabe la posibilidad de que Oracle espabile y arregle todo este absurdo meollo de OpenSolaris en el que ellos mismos han decidido introducirse. ¿Pero acaso no han tenido ya tiempo de sobra para arreglar las cosas y no lo han hecho?


  • Linux y la fragmentación: el asignador de bloques de Ext4
    Continua la serie de artículos sobre la fragmentación en sistemas de archivo Linux (parte 1, 2, 3). Este nuevo post trata sobre las novedades que incorporó Ext4 a su asignador de bloques. La información está sacada de este documento, y se puede también encontrar en un gran comentario al principio del archivo fs/ext4/mballoc.c.

    El sistema de asignación de bloques es en gran medida el corazón de todo sistema de archivos, y los algoritmos utilizados tienen una gran importancia. Se trata de uno de esos puntos clave cuyos mecanismos siempre deben estar bien aceitados. No solo se les exige evitar la fragmentación, temática de esta serie de posts, también se les pide ser endiabladamente rápidos y muy escalables.


    Una de las técnicas de organización del espacio que la mayoría de sistemas de archivos utilizan es subdividir el espacio disponible en partes de varios cientos de MB, de ese modo el sistema de archivos puede operar en varias subdivisiones a la vez casi independientemente. En el caso de Ext4, esa subdivisión se llama "grupo de bloques", y tiene un tamaño de 128 MB. Cada grupo de bloques tiene una serie de bloques dedicados a tareas especiales: hay unos en los que se almacenan los inodos (y cuya cantidad es estática y determinada por mkfs, razón por la que Ext4 no puede variar el número de inodos dinámicamente); también hay un bloque que se emplea en almacenar un mapa de bits que indica los bloques libres y los utilizados, y otro mapa de bits utilizado para indicar qué inodos están siendo utilizados. Cuando se va a iniciar una operación en un archivo, la decisión de asignación de bloques comienza, en principio, en el grupo de bloques al que pertenece el inodo del archivo, el cual suele asignarse en el grupo de bloques en el que está el inodo del directorio.

    Ext4 dispone de dos espacios de preasignación principales a partir de los cuales se asignan bloques en un grupo de bloques: preasignación de CPU y preasignación de inodo. Las preasignaciones son rangos de bloques que no están siendo utilizados, pero están reservados y, en principio, no serán utilizados por nadie más. Si el archivo va a tener un tamaño menor a 16 bloques (64 KB), se utiliza el primer espacio de preasignación, si no, el segundo. De no poder atender la petición de asignación del espacio de preasignación, se procede a buscar espacio libre en un sistema de asignación "buddy" que contiene el resto del espacio que no está u ocupado o en las preasignaciones.

    La razón por la que existen dos espacios de preasignación es para evitar que los archivos creados en una presignación no se entrometa en las del otro. Los archivos pequeños en un mismo directorio (por ejemplo, /etc/*) se benefician de estar ubicados uno a continuación del otro, los archivos grandes de asignaciones grandes y continuas. El sistema de preasignación de inodos (archivos grandes) también tiene, aparte de la preasignación, un sistema de "reservas" para casos en los que múltiples archivos se escribien simultáneamente.


    Existe una forma muy curiosa de probar este sistema de preasignaciones, un ejemplo que curiosamente apareció en el segundo post de esta serie: la prueba del archivo al que se le añadía un bloque (4KB) en 200 ocasiones consecutivas, y que resultaba tener una fragmentación notable:


    ----------------------------------------------------------------
    ["oflag=append conv=notrunc" son ambos necesarios para que se vayan añadiendo datos al archivo, "conv=fsync" sincroniza el archivo a disco para asegurarse de que no se queda en RAM]
    # for i in `seq 200`; do dd if=/dev/zero of=prueba bs=4K count=1 oflag=append conv=notrunc,fsync; done
    [Un montón de datos de salida de dd]
    ----------------------------------------------------------------

    Este archivo esta bastante fragmentado a pesar de ser un test simple y estar el sistema de archivos de pruebas completamente vacío. Echando un ojo a la salida detallada de filefrag, se puede intentar adivinar las causas de este comportamiento:

    ----------------------------------------------------------------
    # filefrag -v prueba
    Filesystem type is: ef53
    File size of prueba is 819200 (200 blocks, blocksize 4096)
     ext logical physical expected length flags
       0       0    34304               3
       1       3    34816    34306      1
       2       4    34307    34816      3
       3       7    34817    34309      1
       4       8    34310    34817      2
       5      10    34818    34311      1
       6      11    34312    34818      1
       7      12    34819    34312      1
       8      13    34313    34819      2
       9      15    34820    34314      1
      10      16    33808    34820    184 eof
    prueba: 11 extents found
    ----------------------------------------------------------------

    2 pequeños extents de 3 bloques, 2 de 2 bloques, 6 de 1 bloque...y luego uno grande de 184 bloques. ¿Por qué esa distribución tan absurda de los bloques? Si sumamos todos los extents pequeños -todos menos el de 184 bloques- obtenemos exactamente 16 bloques (64 KB). Precisamente el límite mencionado entre el espacio de preasignación para archivos pequeños y el de archivos grandes. ¿Que ha ocurrido? Parece ser que mientras el archivo era menor de 16 bloques, Ext4 le asignó espacio de la preasignación para archivos pequeños; una vez que creció más allá de ese tamaño se le asignaron bloques de espacio de preasignación para archivos grandes, que colocó los 184 bloques restantes contiguos, uno detrás de otro...


    ¿Por qué, sin embargo, se han creado tantos fragmentos pequeños en la preasignación de CPU, optimizada para archivos pequeños? El problema es que la preasignación de CPU, llamada "per-CPU" en su idioma original, contiene en si mismo varias preasignaciones, una para cada CPU. Esta técnica per-CPU es muy común en el kernel Linux, se tratan de arrays de variables, una para cada procesador del sistema, para que cada CPU pueda operar en su variable sin interferir con las demás. En el caso de la preasignación de CPU de Ext4, más que por cuestiones de escalabilidad el objetivo es que las asignaciones de un mismo proceso -que se ejecuta en una CPU determinada- estén físicamente juntas. El comando tar, por ejemplo, podría desempaquetar un conjunto de archivos pequeños, y al ejecutarse tar en una misma CPU, los desempaquetaría en el espacio de preasignación de esa CPU.

    ¿Qué ha ocurrido entonces en el ejemplo anterior del archivo? Pues que mi sistema tiene 2 CPUs, y el proceso dd se ha ejecutado cada vez en una de las CPUs, de modo que en cada añadidura de 4KB se utilizaba el espacio de preasignación de cada CPU. Cuando, por casualidad, dd se ha ejecutado en la misma CPU dos o tres veces seguidas, ha logrado crear pequeños extents de 2 ó 3 bloques, pero cuando había alternancia entre las CPUs utilizadas era necesario empezar un nuevo extent discontiguo respecto al anterior. Y hay un modo muy simple de confirmar esta teoría, que es forzar la ejecución de dd en una CPU determinada, utilizando taskset(1):

    ----------------------------------------------------------------
    # for i in `seq 200`; do taskset -c 1 dd if=/dev/zero of=prueba bs=4K count=1 oflag=append conv=notrunc,fsync; done
    [Un montón de datos de salida de dd]
    # filefrag -v prueba
    Filesystem type is: ef53
    File size of prueba is 819200 (200 blocks, blocksize 4096)
     ext logical physical expected length flags
       0       0    34304              16
       1      16    33808    34319    184 eof
    prueba: 2 extents found
    ----------------------------------------------------------------

    Esta vez dd ha accedido en todas las ocasiones al mismo espacio de preasignación de CPU, y por consiguiente ha ubicado los 16 primeros bloques contiguos.

    Para terminar el post, ¿por qué, podría preguntarse alguien, hay un límite entre ambas preasignaciones para archivos pequeños y grandes que está fijado 16 bloques, por qué ese número? Ese valor es, en realidad, configurable, y se puede cambiar en el archivo /sys/fs/ext4/DISPOSITIVO/mb_stream_req. Y con esto se descubre ese desconocido directorio, que como se puede comprobar, contiene otros archivos de configuración, varios de ellos parámetros para tunear el comportamiento del asignador de bloques (y documentados en Documentation/ABI/testing/sysfs-fs-ext4). La disponibilidad de tales parámetros demuestra que la asignación de bloques es un tema muy complejo, que puede necesitar atención en casos especiales o susceptible a optimizaciones para una carga determinada. Espero que todo esto demuestre que el tópico de que Linux no sufre fragmentación es muy opinable y depende de multitud de factores (y eso que ni siquiera se ha mencionado la necesidad actual de que los diferentes archivos de una misma aplicación estén contiguos), de ahí que la disponibilidad de e4defrag es necesaria y bienvenida.


  • Linux y la fragmentación: "delayed allocation"
    El anterior post tenía ejemplos de fragmentación de archivos en Ext4. Hay que recalcar que eran ejemplos muy muy simples, que en el mundo real ocurren cosas muchas más complejos como que haya una actualización de seguridad mientras algún programa hace otra cosa. Había afirmado que este post detallaría los algoritmos de asignación de bloques de Ext4, pero en su lugar tratará sobre la técnica "delayed allocation" (asignación retardada), que es quien se encarga de llamar a esos algoritmos y por tanto condiciona su funcionamiento.


    En los sistemas de archivos sin asignación retardada, cuando una aplicación llama a write(), como parte de esa llamada se asignan los bloques para los datos. Aunque los datos no se vayan a escribir al disco en ese preciso momento y vayan a permanecer hasta decenas de segundos en el cache, aunque durante ese tiempo los bloques asignados no sean escritos, se asignarán igualmente. Este sistema puede provocar fragmentación, dado que en muchos casos se necesitan múltiples llamadas a write() para escribir enteramente un archivo. Se llamará, por tanto, al asignador de bloques en todas esas escrituras. Y, ¿cómo puede el asignador predecir todas las escrituras que se van a hacer, cómo predecir que un archivo va a llegar a los 2 GB cuando recibe el encargo de asignar los bloques para del primer mega? Simplemente no puede.

    La técnica de asignación retardada, utilizada en sorprendentemente pocos sistemas de archivos (concretamente: en Ext4, XFS, ZFS, Btrfs y HFS+; su escaso uso se debe a haber sido considerada como peligrosa durante mucho tiempo), retrasa la asignación de los bloques hasta el momento en el que el caché se sincroniza al disco. Las llamadas a write() no provocan ninguna asignación de bloques, quienes las provocan son las rutinas de la VM cuando decide que es hora de sincronizar el caché. Este sistema permite que la escritura al disco de ese archivo se haga de una sola vez. El asignador de bloques sabe el tamaño total a asignar, tiene más información, por lo tanto puede tomar decisiones de asignación más inteligentes. En Ext4 existe una forma muy gráfica de ilustrar el funcionamiento de este mecanismo con ayuda, cómo no, del comando filefrag:

    ----------------------------------------------------------------
    $ # Creamos un archivo de 4KB sin sincronizarlo inmediatamente al disco
    $ dd if=/dev/zero of=prueba bs=1K count=4
    [salida de dd]
    $ filefrag -v prueba
    Filesystem type is: ef53
    File size of prueba is 4096 (1 block, blocksize 4096) 
     ext logical physical expected length flags
       0      0        0              1 unknown,delalloc,eof
    prueba: 1 extent found
    ----------------------------------------------------------------


    Como vemos, filefrag no muestra la ubicación lógica ni física del archivo, la muestra como "unknow, delalloc". Es decir, que no se sabe, y que está en estado de asignación retardada: La ubicación simplemente no existe aun, está aun pendiente de realizarse. Sin embargo, si ordenamos sincronizar inmediatamente después el caché con el disco...

    ----------------------------------------------------------------
    $ sync
    $ filefrag -v prueba
    Filesystem type is: ef53
    File size of prueba is 4096 (1 block, blocksize 4096)
    ext logical physical expected length flags
      0      0    36681               1  eof
    prueba: 1 extent found
    ----------------------------------------------------------------

    Como se ve, ya se ha asignado su bloque (igualmente se hubiera escrito al disco si dejamos pasar el tiempo).


    Este sistema es muy bonito. Sin embargo, sería un error afirmar que es una receta para la infalibidad contra la fragmentación, ya que la sincronización del caché al disco se hace cuando a la VM le de la gana...y el comportamiento de la VM es muy, muy variable. En situaciones de poca memoria, una de las primeras cosas que hace es solicitar la sincronización del caché con el disco. Dada una situación extrema de escasez de memoria, se dará el caso de que nada más enviar una llamada write() la VM ordenará la sincronización del caché y provocará una asignación de bloques casi inmediatamente, aproximándose al comportamiento de sistemas de archivos sin asignación retardada.

    Una prueba empírica: en el primer ejemplo del post anterior se escribían dos archivos de 10GB en paralelo, los parámetros de dd eran "bs=512M count=20", lo cual hacía que cada dd ocupara en memoria 512MB. El resultado fue de 164 y 155 extents en cada archivo. Repitiendo la prueba pero con parámetros "bs=1G count=10" hace que los dos procesos dd ocupen 2GB, lo cual aumenta la presión de memoria en mi sistema y provoca mayores llamadas de sincronización de la VM. Resultado, 305-311 extents por archivo, con mayor entrecruce de ambos archivos en el disco.

    Por lo tanto, se observa como la fragmentación del sistema de archivos puede variar con algo tan trivial como la presión de memoria del sistema (y noten que muy a menudo se hacen benchmarks sin intentar reproducir este tipo de condiciones), y cómo es poco prudente afirmar la ausencia de fragmentación en Linux. Todo esto viene a girar alrededor de un concepto ya afirmado en el primer post: Todos los archivos se enfrentan a GBs y GBs de espacio libre, y la decisión de colocar un archivo en un lado u otro depende muy en gran medida de la implementación.

    El próximo post tratará -esta vez si- sobre los algoritmos de asignación de bloques de Ext4.


  • Linux y la fragmentación: provocando fragmentación en Ext4
    El anterior post defendiendo la existencia de fragmentación bajo Linux fue recibido con escepticismo. Para ser justos, la excesiva longitud del anterior post llevó a no extenderlo más de lo necesario. En este post, mostraremos un par de casos triviales en los que se puede observar fragmentación en sistemas Linux usando Ext4.

    En primer lugar, una prueba muy simple, escribir dos archivos grandes a la vez. Se lanzan en paralelo dos procesos dd que crearán sendos archivos de 10 GB. Para que no haya dudas, la prueba se hace en un sistema de archivos recién formateado (nota: dd parece ocupar la memoria especificada en bs, es decir, en este test los dos procesos dd ocupan 1GB de RAM)

    ----------------------------------------------------------------
    # for i in `seq 2`; do (dd if=/dev/zero of=prueba-$i bs=512M count=20 &); done
    ----------------------------------------------------------------

    Una vez terminados de crear los archivos, se examina la fragmentación....

    ----------------------------------------------------------------
    # filefrag prueba*
    prueba-1: 164 extents found
    prueba-2: 155 extents found
    ----------------------------------------------------------------

    Antes de continuar, aclarar que el tamaño máximo de un extent en Ext4 es de 128 MB. Eso quiere decir que dada una asignación de bloques perfecta, un archivo de 10 GB ocuparía 80 extents contiguos. Sin embargo, los archivos recién creados han necesitado el doble (en otros sistemas o con diferentes parámetros de dd puede haber muchos menos o muchos más, y tiene su explicación).

    No suena nada bien, y los detalles pueden revisarse comprobando la ubicación y límites de cada extent con filefrag prueba* -v (cuya extensa salida no pondré aquí). En mi caso hay varios extents de tamaño máximo, 32768 bloques -128 MB-, pero también varios de 4096 -16 MB- y alguno incluso con menos, varios de 20 y pico mil, 16 mil, 12 mil...en definitiva: irregular. Si cotejamos datos de la columna "physical" de ambos archivos, el problema es más evidente: los extents de los dos archivos se van entrecruzando. Por ejemplo, el primer extent de archivo-1, el primero de archivo-2, y el segundo extent de archivo-1, van uno detrás de otro.

    Y esto es con dos archivos. Imagínense 5 ó 10. O más. Y no estamos hablando de casos extravagantes y sacados de contexto, sino simplemente de copiar archivos.

    Hay que ser justos y señalar que esto no es un problema de rendimiento en equipos comunes, ya que una cosa es fragmentarse en pedacitos de pocos KB por todo el disco, y otra hacerlo en pedazos de 128 ó incluso 16 MB, esta fragmentación probablemente ni siquiera se note en benchmaks. Sin embargo, no sirve de excusa para ignorarla. En equipos donde se requieran sistemas de almacenamiento profesionales es de imaginar que Ext4 no de la talla (por esta razón existen empresas con sistemas de archivo e incluso SOs propietarios especializados exclusivamente en optimizar casos como estos). Pero tampoco hay que irse por las nubes, bastaría con copiar dos archivos grandes a la vez a través de una interfaz gráfica para reproducir este problema.

    Pero hay otros ejemplos simples. ¿Qué tal, por ejemplo, un archivo vacío al que se añaden 4KB (1 bloque) 200 veces, simulando una especie de archivo de log que va creciendo? En un sistema de archivos Ext4 nuevamente formateado desde cero, por supuesto. Cabría esperar que simplemente se añadieran los 200 bloques uno detrás de otro, ¿verdad?

    ----------------------------------------------------------------
    ["oflag=append conv=notrunc" son ambos necesarios para que se vayan añadiendo datos al archivo, "conv=fsync" sincroniza el archivo a disco para asegurarse de que no se queda en RAM]
    # for i in `seq 200`; do dd if=/dev/zero of=prueba bs=4K count=1 oflag=append conv=notrunc,fsync; done
    [Un montón de datos de salida de dd]
    # filefrag prueba
    prueba: 9 extents found
    ----------------------------------------------------------------

    Si echamos un ojo a los datos de filefrag prueba -v, resulta que los 200 bloques están divididos en un extent con 184 bloques, otro con 7, dos con 2, y cinco con 1, y los extents no son contiguos entre ellos. Fragmentación discriminada y absurda (tengo una teoría razonable que explique este absurdo comportamiento, pero tendrá que esperar a un artículo posterior).

    En definitiva, como se puede ver la fragmentación en Linux ocurre. Probablemente se podrían buscar más casos, algunos de ellos retorcidos como variar el tamaño de los archivos asignados con truncate(1) o archivos "sparse"...pero estos casos son simples y demuestran que no hace falta romperse la cabeza para encontrar fragmentación en Linux. Si quieren encontrar fragmentación en sus propios sistemas, prueben a buscar con filefrag por su $HOME. Sugiero empezar por este:

    # filefrag ~/.mozilla/firefox/*.default/*.sqlite


    Los archivos places.sqlite, cookies.sqlite, formhistory.sqlite y urlhistory3.sqlite, que corresponden a las bases de datos sqlite que utiliza Firefox en versiones modernas, seguramente estén divididos en varios fragmentos si su perfil de Firefox lleva funcionando un tiempo. Cosas como esta, entre otras, son las que hacen que nada más arrancar Firefox y se trata de introducir una url, la AwesomeBar tarde un poco más en leer el disco y reaccionar. Si son administradores de bases de datos, los archivos de la base de datos pueden tener cierta fragmentación acumulada. /var (las bases de datos de paquetes dpkg/rpm en particular) también son buenos candidatos. ¿A que ahora los desfragmentadores no parecen una idea tan estúpida? (un modo cutre y fácil de imitarlos es copiar el archivo fragmentado en otro y mover el archivo copiado al original)

    El próximo post será sobre el funcionamiento de los algoritmos de asignación de bloques de Ext4. Ya puestos, por qué no hacer de esto una serie...


  • Linux y la fragmentación: si, ocurre
    El tópico de que Linux no necesita desfragmentación ha vuelto renacer. Suele hacerlo periódicamente, aunque por desgracia eso no lo haga más cierto. Ese argumento de que los sistemas de archivos en Linux no se fragmentan o que lo hace tan poco que apenas se nota, y que en NTFS en cambio lo hacen una barbaridad, nunca va acompañado, si se fijan, de una explicación. Eso es porque no la hay.

    Creo que el origen del mito es visual. Windows tiene un desfragmentador de serie que muestra (mostraba) un bonito gráfico donde se ve el estado y progreso de la fragmentación, la cual deja de ser un concepto abstracto para volverse algo real, que se puede percibir mediante los sentidos. Oh, mira cuanta fragmentación. En una instalación Linux típica no hay ningún desfragmentador y mucho menos con gráficos, y al no verse nada es como que no existe (o se obtiene la cifra media de fragmentos/archivo, que es una bonita manera de ocultar la realidad con estadísticas): Oh, no tenemos fragmentación. Pero aunque no la veamos, existe. Hubo un tiempo en el que un servidor de ustedes muy de vez en cuando movía todo su sistema de una partición a otra del disco duro (cp -a), y la disminución del tiempo de inicio del sistema y del tiempo que transcurre entre KDM/GDM y la aparición del escritorio se podían medir en el reloj y en el menor carraspeo del disco duro. Apostaría a que la acertada decisión de eliminar la parte visual del desfragmentador en Windows Vista/7 se debe a la falsa sensación de conocimiento que mucha gente creía tener con las imágenes visuales.

    Hay un par de cosas respecto a este asunto de la fragmentación que la mayoría de la gente (y en este blog, gente = frikis/geeks) desconoce de los sistemas de archivos. La primera es que los sistemas de archivos tienen muchas partes en común. El asignador de bloques para los datos, en particular -responsable de la fragmentación-, es un asignatura bastante común a todos, por no mencionar esos oscuros rincones en los que el sistema de archivos se funde de manera ambigua con la gestión de memoria.

    En segundo lugar, una cosa es el formato físico del sistema de archivos, y otra su implementación. Una buena implementación puede incluso tapar los defectos de un sistema de archivos antiguo, y hacerlo mejor que uno nuevecito con una mala implementación. En Linux hay ejemplos muy próximos en los dos sentidos. Ext3/4 son sistemas de archivos viejos, desfasados, a diferencia de, por ejemplo, NTFS, que es claramente más moderno. Sin embargo la implementación de Ext4 es sobresaliente, capaz de competir con NTFS sin problemas e incluso con XFS en algunos puntos. En cambio Reiserfs v3 tiene un diseño muy nuevo, pero su implementación deja bastante que desear, por eso las empresas se pasaron a Ext4. Y algo con tanto prestigio como ZFS en todo su esplendor tuvo, nada más ser publicado y antes de mejorarlo, un algoritmo de asignación de bloques que se podía resumir con la frase "aquí te pillo, aquí te mato".

    Uniendo los dos párrafos anteriores, se puede obtener la conclusión de que tomar decisiones de asignación de bloques que creen o no fragmentación en la disposición de los datos en el disco duro depende en gran medida de la implementación.

    En principio, en teoría cualquier sistema de archivos puede hacer magníficas decisiones de asignación de bloques en lo que se refiere a fragmentación (otra cosa es el rendimiento y otros factores). Un buen ejemplo para comprenderlo es el caso de dos procesos escribiendo datos simultáneamente a dos archivos diferentes. Un asignador de bloques simple entrecruzará a lo largo del disco duro los datos de ambos archivos: primero un trozo del primer proceso, luego otro del segundo, posteriormente otro trozo del primero, etc, causando una fragmentación masiva. En cambio, un buen sistema debería detectar esta situación y tratar, por lo menos, de que los trozos que se entremezclen sean de un gran tamaño. Este tipo de heurísticas no dependen del formato del disco, y aunque cierto es que la facilidad para implementarlas esté influida por otros aspectos del sistema de archivos, a base de empeño un buen programador con muy poco respeto por la humanidad podría hacer maravillas hasta con FAT.

    Resumiendo: Toda discusión sobre la fragmentación debería estar razonada en base a los algoritmos de asignación de bloques, que son quienes causan o evitan esa fragmentación. Los de Windows/NTFS no se conocen ni se conocerán nunca en detalle, pero los de Linux si que se conocen (aunque en todo google solo existan un par de referencias). Sin embargo, nunca los he visto expuestos en una discusión (no, esto no es suficiente), en cambio de Windows siempre se supone que no tienen absolutamente ni una sola línea de código dedicada a evitar la fragmentación, lo cual es una presunción (veo la imagen del desfragmentador, luego creo saber) demasiado atrevida. Sirva de ejemplo de desconocimiento de este tema que a pesar de que Ext4 incorpora varios cambios para evitar diferentes tipos de fragmentación, en tiempos del reinado del Ext3, que carece de esos cambios (y por tanto se fragmenta más), se afirmaba de todos modos que Linux no sufría fragmentación. O, peor aun, se afirma que los sistemas de archivos Unix previenen la fragmentación basándose en...¿exactamente qué hechos? (es más, ZFS y Btrfs se fragmentan una auténtica barbaridad por virtud de las técnicas COW).

    Echen en Linux un ojo a la herramienta filefrag, como curiosidad yo tengo una ISO de un DVD en un Ext4 bajada con wget que está dividida en mil y pico extents. Y un SVG de 1.2 MB con 8 (un caso muy raro), y varias películas divididas en cientos cada una. Fragmentación pura y dura bajo un kernel 2.6.35-rc3 (eso si, si obtenemos la cifra media de fragmentos/archivo, los miles de archivos menores de 4KB rebajarán la media y harán que parezca que no pasa nada). Y no todo es culpa del sistema de archivos, no es casualidad que POSIX tenga la función fallocate(), es una prueba de que existen casos en los que un asignador de bloques no pueden predecir el futuro. Además, hay que tener en cuenta la fragmentación entre diferentes archivos, un tipo de fragmentación muy importante para el rápido inicio del sistema y de las aplicaciones y que prácticamente requiere un desfragmentador. No es casualidad que XFS, Ext4, y Btrfs tengan desfragmentadores, simplemente se necesitan (para Btrfs puede llegar a convertirse en un requisito).

    Por supuesto, si usted quiere puede vivir sin desfragmentador, e incluso las distros Linux podrían no usarlo bajo la regla de que casi nunca hace falta, pero por esa regla de tres también Windows podría eliminarlo basándose en esa lógica. Lo acertado de Microsoft en este campo es que en vez de negar el problema y pretender que no existe, han proporcionado una herramienta para arreglarlo (también es bonito lo que hace OS X, defragmentar automáticamente un archivo al abrirlo si detecta que está fragmentado). Es como el caso de "no-tenemos-fsck-porque-nuestro-sistema-de-archivos-no-lo-necesita", puedes negar que necesitas un fsck todo lo que quieras, pero el mundo real es muy puñetero y aparecen usuarios necesitándolo. Lo mismo para los desfragmentadores.

    Este tema es muy amplio (y se podría hablar de las mejoras de algoritmos que usa Ext4 y tal, y casos que no cubren), pero definitivamente no será en esta entrada, que ya es lo suficientemente larga...


  • Fusion, la posible venganza de AMD
    Por si ustedes se han metido debajo de las piedras, hoy AMD ha mostrado al público por primera vez AMD Fusion, una mezcla de CPU + GPU, que AMD ha dado en nombrar APU (si, APU). Y esto tiene su cosa, porque el equivalente de Intel, Larrabee está más muerto que vivo, y esto puede cambiar las tornas en la eterna lucha por la dominancia entre ambas compañías.

    Efectivamente, quizás no lo sepan (no se ha hablado mucho del tema), pero Larrabee, ese nombre tantas veces repetido (en este blog se le dedicaron un par de apasionados posts), ha sido -por decirlo de un modo amable- reseteado. Tal como predijeron los de Nvidia, hacer una GPU es muy diferente de hacer una CPU, e Intel no tenía experiencia y se iba a pegar. Y se la ha pegado. Como solución de emergencia, andan juntado una CPU tradicional con un chip integrados de los suyos, que sería útil si no fuera porque tienen un rendimiento mediocre. Si las operaciones en GPUs empiezan a extenderse en el software nadie va a conformarse con un chip diseñado para mostrar un escritorio Windows, Office, DVDs y juegos 3D muy simples.

    AMD Fusion es diferente, es una CPU verdaderamente integrada con una GPU, hasta el punto de que comparten componentes. Las alternativas tradicionales requieren que la comunicación entre CPU y GPU se haga a través de los buses típicos (PCIE, interconexión de procesadores hypertransport), con la consiguiente latencia y consumo de energía. La GPU de un Fusion en cambio comparte el controlador de memoria con la CPU. AMD dice que la GPU usará unas partes de la memoria central, la CPU otras, y que las transferencias entre ambas son muy rápidas, sin molestias de los variados buses. No hay razones para creer que no sea así, y es de imaginar que AMD Fusion rendirá magníficos números.

    AMD parece creer -o al menos lo cree el departamento de marketing que ha escrito los documentos que estoy leyendo- que la Ley de Moore se continuará cumpliendo en el futuro....con ayuda de sus APUs, es decir, no sólo añadiendo cores, o añadiendo transistores a las CPUs tradicionales, sino con GPUs. Creen que los programadores van a utilizar, vía OpenCL, masivamente los "cálculos vectoriales" SIMD, y que las APUs van a formar parte cotidiana de nuestro futuro. Los gráficos se verán beneficiados sin duda, de hecho a día de hoy no se puede tener una interfaz moderna sin ayuda de una GPU. ¿Se imaginan una pantalla táctil sin los efectos gráficos al moverse en una lista, en una web, cambiar de pantalla, etc? Hay un apartado especial para los dispositivos móviles, ya que la óptima integración permite alargar la vida de las baterías sin renunciar al rendimiento.

    Todo esto es muy bonito leído así, claro. ¿Pero qué tiene esta historia de la venganza del título y de la horrible frase inicial? Pues mis elucubraciones sobre un posible retorno de AMD al liderazgo en el campo de los procesadores, perdido desde que Intel pateó al Opteron.

    La compra de ATI fue considerada un gran fracaso, AMD perdió una barbaridad de millones en la operación y puso a la compañía en una posición parecida a la de Sun antes de ser engullida por Oracle. Pero si la compra fracasó desde el punto de vista financiero, la ventaja que están sacando de aquello es el liderazgo en la fusión entre GPU + CPU. Intel acaba de volver a la posición de salida, y es imposible que alcance al equipo de ATI en varios años. Nvidia hace fantásticas GPUs, y para ser competitivos han diseñado su propio SoC ARM, pero ellos no diseñan los procesadores ARMs ni tienen la gente necesaria para integrar ambos como puede hacerlo AMD....esto quiere decir que AMD no tiene ningún rival cercano en este campo, si no media una compra de Nvidia por parte de Intel. ¿Estamos ante el regreso de AMD? El tiempo lo dirá, pero al menos las cartas parecen tenerlas.

    (Nota: Tambien hoy SGI anuncia que está disponible sus equipos Altix UltraViolet, de los que ya se habló en este blog hace tiempo y que están relacionados con este tema)


  • Opinando sobre Haiku
    Pues si, he probado la Alpha 2 de la R1 de Haiku. Y como tengo un blog, cuento mi impresión. Siento decepcionar por adelantado a quien espere una opinión positiva: Francamente, no entiendo que haya quien siga poniendo a este SO como ejemplo de lo que deben ser los SOs en el futuro. Eso, y que me encanta intentar ganar lectores perdiendo a otros.

    No me interpreten mal. Entiendo que haya gente que escriba SOs alternativos, entiendo que haya gente que reescriba AmigaOS, BeOS o el propio Windows en código libre. Lo entiendo, lo admiro, y en algunos casos hasta lo apoyo (Wine me parece un proyecto imprescindible). Linux, en su día, fue uno de esos SOs alternativos, y sin la tozudez de sus defensores, si no se hubieran abrazado a sus aspiraciones más que a la triste realidad de lo que tenían entre manos, jamás habría salido de ese estado.

    Sin embargo, no entiendo que un SO como Haiku se refugie en una especie de penitencia-imitación hasta el punto de haberse preocupado de implementar compatibilidad a nivel de código fuente y a nivel binario con un SO que nunca tuvo tantas aplicaciones como para hacer esa compatibilidad algo de vida o muerte. La actitud de los desarrolladores de Linux en sus primeros años siempre fue la contraria, más dispuestos a inventar cosas por si mismos que a fotocopiar exactamente las de otros Unix.

    Uno se enfrenta por primera vez al escritorio de Haiku, le da al "botón de inicio" y lo primero que le viene a la cabeza es: Windows 98. ¿Qué otra idea va a venir, si la presentación de la lista de programas en forma de menú es idéntica, y la barra de tareas vertical es el mismo concepto que Microsoft ha abandonado en Windows 7? La interfaz es del mismo estilo: color gris uniforme, sin ningún tipo de degradado o animación simple. El diseño de las interfaces de usuario, muy a los 90. En el aspecto estético, es un viaje al pasado. Y que no se diga que la apariencia no es importante: Lo es porque la abundancia de adornos inútiles sin impacto en el rendimiento demuestran superioridad técnica ("yo puedo permitírmelo y tú no"), y lo es especialmente para un SO que pretende ser lo mejor en los escritorios.

    Todo esto, repito, es normal y no es algo criticable (Linux tampoco es que sea precisamente perfecto), pero a uno le vienen los beoseros hablando del Sagrado Grial de los escritorios y tal, atacando con cualquier cosa cuando comentas en que a día de hoy el líder del asunto escritoril es OS X, y luego al probarlo
    en ningún momento le da a uno la sensación de que esto sea el futuro de los escritorios. De hecho, parece más bien un pasado ya superado, además de compartir los mismos errores de los escritorios actuales. El escritorio de BeOS y sus APIs no fue fundado sobre la aceleración de GPU que CoreAnimation o Clutter tratan de proporcionar, sino sobre el mismo modelo "2D" que ha demostrado ser insuficiente para, por ejemplo, hacer animaciones vitales para las interfaces táctiles. La única novedad gráfica que me ha parecido interesante es el visor de procesos que muestra una lista de procesos y barras que cambian dinámicamente en un menú contextual. Y no es algo precisamente revolucionario ni que no esté al alcance de otros toolkits.

    Y quien dice gráficos, dice lo demás. Las novedades revolucionarias de BeOS ya no lo son tanto. ¿Volumen de sonido para cada aplicación? Linux lo tiene con Pulseaudio (tengo un plasmoid en mi escritorio con el que controlo los volúmenes de las diferentes aplicaciones que es francamente cómodo). ¿Queries del sistema de archivos? Akonadi tendrá más potencia que ese sistema. ¿Aprovechar las múltiples CPUs de un sistema multicore? El Gran Central Dispatch de OSX 10.6 logra lo mismo, excepto que es más potente y más simple de implementar en las aplicaciones. ¿Microkernel? Haiku ya no lo es, ha traicionado esos principios por razones de rendimiento.

    En mi opinión, lo que debería hacer el proyecto Haiku es olvidarse de emular al viejo y superado BeOS, y construir un verdadero SO de escritorio del futuro. Tienen la posibilidad de ello porque tienen una ventaja que ningún SO tiene hoy en día, que es no partir completamente de cero, y poder permitirse modificaciones radicales al sistema. Cuanto más tarden en ponerse a ello, más difícil tendrán esa tarea.


  • Más rápido de lo que se esperaba
    Interesantes tiempos estos que vivimos, en los que contemplamos en directo eventos como la liberación de VP8 ayer o la nueva Google TV de hoy. Sin embargo, la sensación que deja leer información de las charlas de la Google I/O 2010 es distinta. Tiene más que ver con uno de las notas de prensa que ha publicado Google estos días: La Web como la plataforma de desarrollo predilecta, la más requerida, en la que más dinero se invierte.


    Esclarecedor ha sido ese momento de la keynote inicial de Google en la que hacen recuento de las aplicaciones de escritorio "tradicionales" más importantes del mundo, y como a partir de 2004 no ha aparecido ninguna gran aplicación nueva: El mismo año en que empiezan a salir a la luz cosas como Gmail o Google maps. Otro muy esclarecedor ha sido cuando han explicado con números que la TV es un medio mucho más masivo que internet, y que con GoogleTV, al mezclar TV e Internet, se abre la posibilidad de aplicaciones webs a toda esa gente.

    El Google I/O de este año se ha establecido por lo tanto como el evento clave para anunciar las novedades más importantes en la web, el que define el rumbo que se seguirá. Sitios como http://mugtug.com/darkroom/ o http://www.clicker.tv han sido las encargadas de mostrar ayer el estado actual de las aplicaciones HTML5 -que no consta solo HTML- y de demostrar que no va en broma.

    No sé a ustedes, pero a mi todas estas noticias de hoy me han dejado por fin claro el lugar de las aplicaciones web en el mundo, un lugar que hasta el día de hoy nunca había logrado comprender con claridad. Me parece que ese lugar es el de toolkit, con aspiraciones de lograr algo análogo a QT, Cocoa o .NET, pero distinto, y sin eliminar ni quitar relevancia a todo lo que no son toolkits (la definición de "toolkit", por supuesto, es otro tema). Todo esto no invalida los toolkits tradicionales, claro, pero los hace menos relevantes. ¿Es una locura pensar que de aquí a unos años la plataforma gráfica para juegos no de consola por definición será WebGL, y no Directx, por poner un ejemplo? ¿Es una locura que Gnome 3 tenga algunos de sus programas en Javascript?

    Parece ser, por tanto, que todo este asunto de la web está avanzando a pasos agigantados, que ya no estamos teorizando sobre lo que veremos dentro de unos años sino que estamos ya en él, sumergiéndonos más y más con cada nueva versión del navegador. Parece que el futuro ha llegado mucho más rápido de lo que se esperaba.


  • Lo que trae Linux 2.6.34
    Perdonen la falta de detalles, pero no he tenido tiempo de terminarlo (y quizás así sea mejor, porque me obliga a resumir). 2.6.34 ha sido publicado, entre las novedades están dos sistemas de archivos, un driver para obtener rendimiento de red nativo con KVM, mejoras de Btrfs, lockdep para RCU, optimizaciones de kprobes, mejoras de perf, suspensión/resumen del sistema asíncrono, soporte preliminar de Radeon 5xxx....he aquí una explicación detallada. La lista completa en inglés está aquí, como siempre (aunque a lo mío yo no lo llamaría "inglés", y de hecho siempre viene alguien detrás a corregirme pequeños fallos):

    · Ceph: Un sistema de archivos distribuido, que puede considerarse vagamente similar a los conceptos de lustre o el googlefs. Es decir, distribuye varias copias de los datos entre los servidores, y si uno de ellos falla se replica en otro. Como suele ocurrir en este tipo de sistemas de archivo, los datos y metadatos se almacenan por separado, pero a diferencia de otros como Lustre, Ceph permite tener múltiples servidores de metadatos. Su autor principal es Sage Weil, quien lo inicio como parte de su tesis. En este artículo (o en este otro) se explica en detalle su funcionamiento. De progresar, podría hacer frente a Lustre y, además, estar mejor integrado en Linux. Una cosa curiosa es que Ceph utiliza para implementar ciertas características funcionalidades exclusivas de Btrfs (y, de hecho, han enviado parches para implementarlas), de modo que Ceph utiliza Btrfs como almacen seguro de sus objetos. Cabe notar además que es un sistema de archivos aun muy experimental

    · LogFS: Es un sistema de archivos diseñado para dispositivos basados en "memoria flash" (SSD) y, como su nombre indica, su diseño está basado en la idea de estructura en forma de log (es decir, todas las operaciones del sistema de archivos se van añadiendo linealmente a la cabeza de log). Puede considerarse como el sucesor de JFFS2, al que supera en prácticamente todos los sentidos. A diferencia de otros sistemas de archivos para dispositivos SSD, tiene soporte rudimentario para funcionar en dispositivos basados en bloques (discos duros).

    · Mejoras de Btrfs: En esta versión, Btrfs añade varias cosas:
       · La capacidad de configurar qué subvolumen es el subvolumen por defecto. Esto permite cosas como, a la hora de actualizar el sistema, tomar un snapshot, actualizar, y configurar a a las actualizaciones como subvolumen por defecto. Y, si algo falla, se reconfigura el snapshot anterior como subvolumen por defecto. De hecho, ya existe en F13 un plugin que automáticamente toma snapshots antes de las actualizaciones y modifica incluso la configuración de Grub, permitiendo probar una versión de Fedora y volver a la anterior en caso de tener problemas con ella.
       · Se ha añadido una nueva herramienta para gestionar btrfs, el comando "btrfs". Esta herramienta reemplaza a todas las herramientas anteriores.
       · Se ha añadido la capacidad de listar todos los subvolúmenes del sistema (comando btrfs subvolume list)
       · Se ha modificado el cálculo de df (que, para btrfs es mucho más complejo de lo normal), y se ha añadido un df propio detallado (comando btrfs filesystem df)
       · Se pueden defragmentar archivos individuales, e incluso rangos determinados dentro de un archivo.

    · Vhost net: Se trata de un driver que realiza una optimización para las funciones de red de virtio (la interfaz de IO de Linux para interactuar con eficiencia entre huéspedes e invitados de virtualización). Este driver elimina 4 llamadas al sistema por cada paquete de red, y consiguientemente toda la sobrecarga que ello implica. De ese modo, los invitados de un sistema KVM pueden tener un rendimiento de red prácticamente idéntico al del hardware nativo.

    · Kprobes jump: Kprobes es el sistema que utiliza Systemtap para insertar "sondas" (probes) en puntos aleatorios del código kernel. Estas sondas insertan la instrucción "int3", que provoca una interrupción que el código de kprobes atiende obteniendo todos los datos que sean necesarios para Systemtap. En esta versión, Kprobes puede utilizar una simple instrucción "jmp", es decir, para llamar a Kprobes simplemente se hace un salto de código, que es mucho más eficiente. Con "int 3", una sonda tarda 0.5-1 microsegundos en desapacharse, con "jmp" apenas 0.1. Esto hace que la instrumentación en vivo sea aun menos notable en el sistema.

    · Mejoras de perf: una nueva herramienta que analiza estadísticas de bloqueos (perf lock), y soporte para análisis entre distintas plataformas, por ejemplo un x86-32 bits y un SPARC 64 bits. Esto permite "empaquetar" los datos de un análisis de una carga concreta, y enviarselos por email a alguien para que sepa revisarlos y encontrar problemas.

    · Lockdep para RCU: Lockdep es una herramienta de depuración que trata de precedir posibles fallos en los bloqueos del código mientras se ejecuta el sistema. Sin embargo, hasta ahora no incluía depuración para uno de los tipos de bloqueo más importantes y complejos de Linux, RCU. Esta versión, se añade soporte para ello.

    · Generalized TTL Security Mechanism, private VLAN proxy arp: Dos nuevos RFCs (5082 y 3069). El primero es un sistema de protección especialmente útil para proteger routers contra ataques con paquetes BGP.


    · Suspension/resumen asíncrono: Hasta ahora, la suspensión y resumen de los dispositivos en Linux era síncrono, es decir, se hacían las operaciones de suspensión y resumen del dispositivo uno detrás de otro. En esta versión se hacen en paralelo, lo cual acelera el proceso, especialmente el de resumen del sistema, aunque de momento solo lo utilizan los dispositivos PCI, USB y SCSI.

    · Alternancia entre GPUs: Algunos portátiles incluyen múltiples GPUs, una de bajo rendimiento y consumo y otra de alto, y permiten cambiar dinámicamente entre ambas. Esta versión añade soporte para ello en Linux (aunque requiere reiniciar las X).

    · Soporte preliminar de Radeon HD5xxx: Pero solo preliminar...

    · Driver Ballon de VMware: El "Balloning" es una técnica que permite limitar la memoria que utilizan los invitados en los sistemas virtualizados con colaboración del invitado. Con este driver, los invitados Linux en huéspedes VMware podrán realizar esta función correctamente.


    Esto es todo. Para la lista completa, ya saben, aquí.


  • systemd, otro reemplazo de init
    Justo cuando parecía seguro que upstart era el futuro, cuando todas las distribuciones lo habían integrado o planeaban hacerlo, ocurre lo que tantas veces en el mundo linuxero: Sale alguien implementado algo totalmente diferente porque no termina de gustarle la nueva propuesta. Estas cosas sin duda son una enorme pérdida tiempo en muchos casos, pero también una gran fuente de creatividad. Ese es el caso de systemd, el nuevo juguete de Lennart Poettering (tambien creador del magnífico Pulseaudio).

    Pero antes, algo sobre upstart. En lugar de usar dependencias de unos archivos a otros, como hicieron varias intentonas de paralelización del sistema tradicional sysvinit, las dependencias son en base a eventos. Por ejemplo, al iniciarse el sistema upstart genera el evento "startup". A continuación, upstart interpreta todos los archivos de eventos (trabajos, en jerga upstart) de /etc/event.d que tengan la dependencia "start on startup". El trabajo puede ejecutar un script, un comando, o emitir un evento ("emit mi-propio-evento"). En este último caso, upstart ejecutaría todos los trabajos que tengan un "start on mi-propio-evento". Tambien hay eventos específicos para interfaces de red, etc.

    Poettering ha aplicado otro punto de vista al problema. Prescinde de las dependencias y la sincronización la relega a mecanismos sistémicos de bajo nivel. Bajo systemd todos los servicios del sistema podrían arrancarse a la vez, sin preocuparse de que tal servicio depende de otro. Por ejemplo, podría arrancarse X.org antes que D-Bus (que X.org necesita para pedir a udev la lista de dispositivos de entrada). Esto, claro está, causaría un fallo en el inicio de X.org, las dependencias de upstart existen, precisamente, para prevenir este problema. ¿Y qué hace systemd para evitar el fallo de X.org?

    El truco utilizado es el mismo que utiliza inetd o el launchd de Mac OS X. Buena parte de las dependencias de sysvinit o de  upstart están para que un servicio (ej, X.org) espere a que otro servicio arranque y cree un socket Unix (ej, el socket de D-Bus) para poder comunicarse con él. Bien, pues resulta que esos sockets pueden crearse antes de que los servicios (D-Bus en este caso) arranquen. systemd, mismamente, puede crearlos -pero sin "escuchar" lo que se envía a ellos-, y las aplicaciones (X.org) pueden conectarse e incluso escribir a ese socket, porque el kernel va guardando en un buffer todo, a espera de que alguien se decida a leerlo. Solo cuando esto sucede, systemd decide iniciar el servicio (D-Bus), que una vez finalizado su arranque se pone al día leyendo los buffers acumulados. Esto implica que las dependencias no son necesarias, systemd crearía todos los sockets de todos los servicios pero sin iniciar ninguno inicialmente, solo los arrancaría a medida que los clientes los intentan utilizar.

    Hay una gran ventaja de este sistema sobre upstart, derivado de la ausencia de dependencias. Si en upstart hay, por ejemplo, varios servicios que tienen la línea "start on dbus", al iniciar D-Bus se iniciarán esos servicios (X.org, avahi, networkmanager, vaya usted a saber). Esto ocurre incluso si no era esa la intención del administrador. Con systemd esta situación no es posible. Simplemente se iniciaría X.org, o Networkmanager, o avahi, y D-Bus sería iniciado automáticamente sólo cuando alguien intente leer su socket.

    Aun con todo lo hasta aquí descrito, systemd no sería más que una reimplementación del launchd de Mac OS X. Sin embargo, no se queda ahí. Poettering identifica otro "punto de contención" en el inicio: los montajes en el sistema de archivos. Ciertos servicios tienen que esperar a que ciertos puntos de montaje estén disponibles antes de iniciarse. Además, al iniciar el sistema hay que montar -y quizás fsck'ear- los sistemas de archivo que indique /etc/fstab (y mientras se hace esta tarea quizás se pierde la oportunidad de iniciar algunos scripts que tienen sus puntos de montaje ya montados). systemd se basa en el viejo y fiable autofs (un "montador automático") para aplicar la misma idea que en los sockets: todos los montajes posibles se pre-crean sin que esté montados realmente, y autofs los irá montando de verdad -y quizás fsckeando- a medida que los servicios intenten acceder a ellos, pero no antes. Con este sistema, systemd hace que /etc/fstab sea algo obsoleto o al menos prescindible.

    Todo esto ya de por si hace de systemd una seria alternativa a upstart y una mejora respecto a otros sistemas de inicio. Sin embargo, un sistema de inicio debe hacer más cosas que gestionar lo descrito anteriormente. Debe intentar reiniciar un servicio si se cae, o apagarle y enviar una alerta al administrador si se cae demasiado. Para hacer bien esta tarea de niñera, el sistema de inicio debe tener conocimiento de lo que hacen todos los procesos hijos que los servicios crean, algo que no es sencillo en Unix (upstart lo logra analizando datos de /proc), ya que los procesos "nietos" del sistema de inicio pueden perderse y existir a su aire sin que su "abuelo" se entere de qué ocurre.

    Para solucionarlo Poettering usa, en vez de los trucos que utilizan otros sistemas, una de las novedades más potentes y menos conocidas de los últimos kernels: "Control Groups" (cgroups). cgroups son "grupos de procesos" elegidos al azar, y que comparten, como grupo, una serie de características. Los hijos de un proceso de un cgroup heredan la pertenencia a ese cgroup. Esto permite a systemd gestionar a nietos y biznietos con seguridad. Pero tengamos en cuenta que las propiedades configurables de los cgroups pueden ser cosas como límites de CPU, de memoria, de prioridad de disco...pues systemd tambien permite, ya de paso, que los servicios puedan configurar todas esas características. Por ejemplo, updatedb puede configurarse para usar una prioridad de disco baja.

    Hay mucho más que decir de este sistema: los tipos de archivos de configuración, o units, una UI para visualizar los servicios -escrita en Vala-, planes de una unit timer que sustituiría a cron, una unit swap, potencial reemplazo al menos de parte de la funcionalidad de los gestores de sesion de los escritorios (gnome-session/kdeinit), etc. Y varias funcionalidades avanzadas (por ejemplo, guardar el estado de los servicios en un momento dado, apagarlos todos, ir a un shell de emergencia, y regresar al estado anterior). El documento del proyecto es una lectura muy recomendable. Aun así, podemos decir que es, en principio, conceptualmente superior a upstart, y es muy fácil de migrar a él por no ser necesario reescribir scripts y crear nuevas dependencias.

    Dado que Poettering trabaja para Red Hat, no será sorprendente que Fedora lo adopte en futuras versiones.


  • MeeGo y su pequeña ventaja en la salida
    El proyecto MeeGo ha tenido 6 presentaciones en la conferencia "Linux Foundation Collaboration" -últimamente hay una barbaridad de estas conferencias-, y en una de ellas, Arjan Van De Ven, ex-Red Hatero y trabajador de Intel, describe la organización de la nueva distro:

    "Architecture maintainers are responsible for integrating hardware-specific patches into the single MeeGo source base - upstream first" policy for patches!". Es decir, los fabricantes tendrán que ocuparse de conseguir por su propia cuenta la inclusión en el kernel de las modificaciones y drivers que utilicen para que Linux soporte su harware.

    Los fabricantes de hardware, ya se ha dicho por aquí varias veces, solo piensan en vender hardware. Se olvidan pronto del software. Se dan, por esta razón, casos de fabricantes de hardware que han adaptado toda una distro para su producto sin preocuparse de contribuir el código. Luego han puesto a la venta el dispositivo, han publicado el código modificado en un FTP, y se han olvidado del asunto. Pueden hacerlo así, claro, y en algunos casos no importa. Para eso está el software libre.

    Otros muchos, en cambio, pronto descubren lo contraproducente de este sistema. Tienen que mantener el software, y se encuentran con miles de líneas de código que tienen que cargar a su espalda. Tarde, descubren que mucho mejor hubiera sido preocuparse de adaptar el código y meterlo en upstream en su día. El mejor ejemplo de esto es Android. No quisieron contribuir su código al kernel. DiBona -el jefe de opensource en Google- despreció las críticas que se hicieron al respecto. Creían que podían vivir solos, por su cuenta. Ahora se encuentran con una situación infernal: Las decenas de empresas interesadas en Android están basando su trabajo en un repositorio interno de Google. La cantidad de código no presente en upstream está creciendo rápidamente.

    Ahora, Google se encuentra con que cada vez que quieran actualizar el kernel de Android, tienen que hacer un esfuerzo enorme para portar todo ese código a la nueva versión (lo mismo que les pasa con los kernels de sus servidores, que tienen 300.000 LoC de parches sobre un kernel 2.6.26).

    Tras todo este nulo esfuerzo por sincronizarse con upstream, Google no solo se encuentra con que les hubiera costado menos contribuir que mantener el código por su cuenta, se encuentran con que más de un teléfono que hoy lleva Android no podrá actualizarse en el futuro. Drivers propietarios no actualizados, bases de código desactualizadas, no mantenidas. Ahora, tarde ya -pero mejor tarde que nunca- han contratado a dos programadores con la única misión de incluir el código de Android en upstream, para arreglar el problema. Bienvenida sea esta magnífica iniciativa, pero MeeGo, con su política de "upstream first" (la misma que usa Red Hat), tiene el problema resuelto de antemano.


  • Dejándome en evidencia
    En la serie de tres entradas que hice farfullando sobre las tiendas de aplicaciones, me jugué la boca diciendo que creía firmemente que Apple acabaría extendiendo la App Store a toda la gama Mac.

    Hoy, Steve Jobs confirma explícitamente -últimamente está contestando a mucha gente mediante email, curiosa iniciativa mediática- que de App Store en OS X 10.7, nada de nada. Porca miseria. En realidad no me doy por vencido: La pregunta contiene dos cuestiones diferentes, y la respuesta es demasiado genérica.

    En cualquier caso, da igual: Si Steve no quiere una App Store, Ubuntu si, y francamente tiene una magnífica pinta.


  • El plugin ODF de Oracle para Microsoft Office
    Oracle ha empezado a cobrar por el plugin ODF que Sun desarrolló para Microsoft Office. Mucha gente parece haberse escandalizado por ello, y yo también al principio...pero al final ha acabado pareciéndome incluso buena idea.

    Y es que a quien más daño hace no disponer de ese plugin es, en realidad, a Office. Dado que se puede decir que ODF ha triunfado, la carencia de buen soporte de ODF es un problema para Office, y una ventaja para Openoffice.


  • RHEL 6 Beta 1
    Red Hat ha anunciado la disponibilidad de la primera beta de Red Hat 6. Se trata de un evento muy importante, dada la importancia de Red Hat, y para ellos en particular es un importante salto hacia adelante: RHEL 5 fue publicado en 2007 y su base ya es vieja. Por ejemplo, su kernel base es el 2.6.18 (estamos por la 33), y aunque tienen disponibles paquetes alternativos con versiones más nuevas, y han portado varias novedades de versiones nuevas a 2.6.18, sigue siendo un lastre de cara a los nuevos clientes (los programas que se certifiquen para RHEL tienen que soportar esa versión). Y quien dice el kernel, dice todo lo demás.

    Asi que RHEL 6 es un importante lavado de cara. La base con la que se compararán otros SOs, el espejo en el que se mirarán otras distros. De este modo Red Hat recoge beneficios de todas las mejoras que los programadores de la compañía han hecho en todos estos años.

    ¿Qué hay de nuevo en esta versión? La documentación de la Beta aun no está completa, pero los aspectos fundamentales están claros. Basado en el kernel 2.6.32, promociona a Ext4 como sistema de archivos primario, y mención a XFS como opción escalable, y a btrfs como experimental. LVM tiene varias mejoras. , varias mejoras tambien en el apartado de gestión de energía, con la inclusión del modo "tickless". Inclusión de toda una suite para facilitar la gestión de clusters. Inclusión tambien de Netlabel (que permite aplicar políticas SELinux a paquetes de red), y, por supuesto, adopción sin complejos y sin backports de todo lo relacionado con KVM y libvirt, y abandono de Xen como host. Sin olvidar el gestor de procesos CFS y los "control groups" que tanto juego darán a los admins. Y perf y Systemtap a todo trapo, claro. Y KMS.

    En resumen: Nada que pueda sorprendernos. Todo lo que ya conocemos y usamos en distros como Fedora, Ubuntu o Suse desde hace 3 ó 4 años. Al fin y al cabo, se trata de una distro que se centra en la estabilidad. Hay que compararlo, claro, con lo que han estado utilizando los clientes de Red Hat hasta ahora, que por cuestiones de estabilidad han preferido no arriesgarse aun con algunas de estas cosas. Pero si tenemos en cuenta de dónde sacan el dinero las empresas que más contribuyen código libre, como Red Hat, esta renovación supone sangre nueva, un impulso.

    Un detalle cargado de significado: Incluyen y consideran una novedad importante a Nouveau, el driver para tarjetas Nvidia.

Reklam Publicidad / TodoProducción / En Buena Zona / Trazos3D / Marcha100 / MenudoPiso! / Alfa Inmobiliaria / esRadio


 

website visitor statistics

 

Copyright © 2010 Web2Times Consultores. Todos los derechos reservados.
Teléefono: 91 229 56 76 / 615 02 49 05. EMail: david@web2times.com.
San Sebastián de los Reyes (28702 - Madrid)