Como un regalo en esta época de fiestas, ha sido liberada la nueva versión estable del kernel. Coñas de Linus aparte, supone un paso interesante en el avance del kernel, añadiendo alguna cosa útil y sentando la base para algunas más. Tal vez incluso un cambio en nuestra percepción del "software".

De la lista de novedades explicada para newbies podemos destacar tres tipos de novedades:

1. Chachipiruli guay pero inútil
2. Drivers
3. Cosas útiles

En la primera, nos encontramos cosas tan rimbombantes como Ext4 o el gestor de memoria de GPU, ambos geniales para jugar un rato... y mantenerlos bien alejados de cualquier sistema en producción.

Con el gestor de memoria de GPU poco se podrá hacer por ahora, mientras que no haya algo que lo aproveche en serio. Es una de las cosas más importantes con los tiempos que corren, la base de una pila de ejecución estándar que aproveche los recursos de las tarjetas gráficas. No más CUDA ni demás inventos vendor-céntricos, una API genérica para todos supondría un gran paso hacia delante.

Más partido se le puede sacar al Ext4, con sus numerosas ventajas como extents, la asignación diferida o la preasignación, sin olvidar el fácil paso de Ext3 a Ext4. Sin embargo, una vez convertido un sistema de ficheros a Ext4, no es tan fácil volver de Ext4 a Ext3. Motivo por el que mejor estarse quietecitos y probarlo bien a fondo antes de arriesgarse a una catástrofe.

De los drivers poco hay que decir. A quien le sirvan, le sirven; a quien no, pues no. Felicidades a los agraciados.

Con eso llegamos a las cosas realmente útiles, aquí y ahora. Aparte de los parches, mejoras de seguridad, y detalles varios en muchas partes, como grandes novedades creo que habría que destacar dos:

Container freezer

Es algo que se llevaba pidiendo desde hace tiempo y que, aunque es poco más que una extensión del hibernado a disco, personalmente estaba esperando con muchas ganas. Puede no parecer obvio a primera vista, pero es un gran avance en la forma que tenemos de ver los programas y servicios de un equipo.

Normalmente, pensamos en un programa como algo que "hay que ejecutar" desde cero, que inicializa su estado a partir de un punto concreto, en el que podemos realizar una serie de tareas que cambian su estado y el de su entorno, y que una vez realizadas acabamos cerrando, con lo que la próxima vez volveremos a tener que ejecutarlo desde cero.

Ahora, con estos parches, podemos empezar a pensar en los programas como "conjuntos de datos con estado", pudiendo inicializarlos no solo en el punto inicial, sino también guardando y restaurando el estado en un punto cualquiera. Esto no solo facilita la migración de procesos entre equipos -parecido a lo que se consigue hoy en día con máquinas virtuales- sino también la posibilidad de guardar un programa a disco, sacándolo de memoria y liberando los recursos relacionados, para poder restaurarlo con el mismo estado en un momento futuro.

Algo así como suspender parte del sistema, manteniendo el resto en ejecución.

IO CPU affinity y SSD

Dos mejoras que permiten aumentar el rendimiento más de un 50% en según qué casos. Resultarán más útiles a quienes manejen grandes cantidades de transacciones de disco -servidores, usuarios de P2P, etc- y a quienes usen discos SSD -servidores, subnotebooks... y cada vez más y más equipos a medida que los discos SSD se hacen más baratos y populares.

Hasta ahora, las operaciones de I/O básicamente se trataban a boleo: según llegaban, se trataban donde pillase, en le CPU que más tiempo libre tuviese. Eso está muy bien en sistemas con una sola CPU, donde tampoco hay mucho para elegir. Sin embargo con varias CPUs -como es cada vez más la norma estos días- resulta más interesante asignar las IOs a la misma CPU que ya tenía los datos en su caché L1. Cierto que la L2 o L3 se suele compartir entre varias o todas las CPUs... pero aún así, es bastante más eficiente usar la L1. Asignando el tratamiento de las mismas IOs a la misma CPU, incluso dedicando una CPU por completo al tratamiento de IOs o un tipo de ellas, se puede aprovechar al máximo el rendimiento de la caché reduciendo al mínimo los accesos necesarios a memoria.

Teniendo en cuenta que la carga de IO es uno de los principales cuellos de botella en muchos servidores, llegando a requerir soluciones dedicadas que la puedan aliviar, creo que muchos estaremos contentos de ver este parche en producción.

Por otro lado, como vemos en la descripción detallada, se mejora la integración entre los sistemas de ficheros y los dispositivos SSD. Cosas como permitir al sistema de ficheros olvidarse de la asignación diferida (ver Ext4 arriba), o permitir al disco dejar de preocuparse por sectores defectuosos que no contengan datos, resultarán bastante útiles de cara a mejorar el rendimiento.

Juntando ambas, la mejor gestión de IOs en discos SSD -uno de cuyos principales reclamos publicitarios es precisamente soportar grandes cargas de IOPS- y el mejor tratamiento de las características concretas de estos dispositivos, podremos sacar la máxima rentabilidad al hardware. Que, dicho de paso, está bastante carito como para no sacarle el máximo rendimiento posible.

Reflexión final

Para terminar, si nos ponemos a juntar todo lo dicho, puede que estemos siendo testigos de una migración en la forma de ver los programas en sí. Software ejecutándose parcialmente en la GPU, hibernado en discos SSD de alto rendimiento, que pudiésemos cargar en menos de 1 segundo restaurándolo al mismo estado en que lo habíamos dejado.

Tal vez un día no muy lejano ejecutemos los programas sólo al instalarlos, y tal vez alguna vez más si se cuelgan... cambiando totalmente el concepto de "instalar", "ejecutar" o "abrir documento"

Los entornos de desarrollo integrados (IDE, 'Integrated Development Environment') son una herramienta con innegables puntos a favor, que puede ayudar en el trabajo del programador... o hundirle en la miseria.

Muchas son las voces que proclaman las bondades de tal o cual IDE, adaptado a tal o cual lenguaje, plataforma o modelo de desarrollo, y ciertamente muchas de esas bondades existen. Sin embargo, en el corazón de todo IDE, acecha la traición, el (auto)engaño del programador llevado a pensar que el IDE es parte esencial de su modelo de trabajo. Hasta el punto de llegar a confundir lenguaje, plataforma, o lo que sea, con el IDE en sí.

Para entender el problema, necesitamos tomar una vista general del proceso de desarrollo, que nos permite plantear unos axiomas:

• se puede observar un desarrollo de forma abstracta, en forma de módulos funcionales
• o se puede observar de forma concreta, los algoritmos, sus elementos y su interpretación
• pero independientemente del caso, un desarrollador sólo podrá analizar un número limitado de elementos por segundo
• ...y la máquina sólo ejecutará los elementos más concretos posibles (código máquina)

Esto significa, que independientemente de si se analizan elementos más concretos, como podrían ser las líneas de código, o si se analizan los más abstractos, como sería la integración general del sistema, o cualquier otro nivel intermedio... la calidad y funcionalidad aportada por un desarrollo depende exclusivamente de la cantidad de elementos analizados, no del nivel al que se analicen.

Volviendo a los IDEs, muchos prometen la capacidad de agilizar el trabajo de desarrollo, ofreciendo herramientas de análisis a niveles cada vez más altos que permitan "generar automáticamente" los niveles inferiores necesarios. Y ciertamente, lo consiguen.

Sin embargo, al hacerlo no aportan calidad al producto final. Por mucho que un proyecto parezca funcionar tras solo introducir unos pocos elementos, es muy poco probable que acaben plasmados de la forma deseada en una aplicación concreta. Salvo que se trate de resolver los problemas más genéricos y simples a un nivel de abstracción determinado, para los que basten las soluciones más generalistas preparadas por el desarrollador del IDE, un IDE nunca será capaz de aportar la misma calidad que un análisis directo de los elementos implicados. Por mucho que se venda como tal.

Al final, a la hora de la verdad, nada suple el esfuerzo mental necesario para analizar y prever las relaciones entre elementos de cada nivel. Ninguna herramienta puede sustituir esos análisis, pudiendo como mucho facilitar la transcripción de sus resultados.

Es decir, que la utilidad de un IDE se centra en que sea un editor de texto avanzado, optimizado para el nivel de abstracción al que se trabaje en un momento determinado, no un proveedor de soluciones mágicas que permite reducir drásticamente las inversión de tiempo y esfuerzo. Una mera forma de no tener que cambiar de ventana, o no necesitar otro monitor al lado al que mirar de vez en cuando.

Los IcyBox IB-168SK-B de Raidsonic son unos curiosos racks para disco duro, que no necesitan caddy ni cosas raras para poder sacar y meter los discos.

Hace algún tiempo que le tenía echado el ojo a este invento, así que con el cabreo de que se fundiesen dos discos duros (por suerte en garantía) y tener que cambiar algunos de un PC a otro, mover particiones, copiar datos, etc... pues ya de paso aprovecho a pedir unos cuantos en MOD-PC para mejorar la capacidad de reacción ante desastres. No más desmontar equipos para mover discos duros.

Cada rack viene en su correspondiente caja de cartón con propaganda:

Dentro de la caja encontramos:

• 1x rack
• 1x adaptador de corriente molex->Serial ATA
• 2x llaves
• 4x tornillos
• 1x manual

Dada la simplicidad de la instalación, el manual realmente no hace falta para gran cosa. El adaptador de corriente hará falta si nuestra fuente de alimentación no dispone de suficientes conectores de corriente SATA, y los tornillos dependerán del modo de instalación de dispositivos 5 1/4 en nuestra caja.

Las llaves son dos copias iguales de una llave simple, cilíndrica con cuatro muescas no personalizadas y un saliente que hace girar el mecanismo de la cerradura. Todos los racks traen la misma llave, por lo que más que una medida de seguridad real, son una forma de evitar abrir el rack en un descuido.

En las fotos anteriores podemos ver el mecanismo de cierre de la llave, y en las siguientes vemos dónde encaja en la puerta.

La puerta tiene una placa de metal, que al introducir un disco hace presión al cerrarla. Como una especie de muelle, asegurando que el disco esté bien encajado en el conector. Desgraciadamente, esto también es la causa del problema que vemos en el vídeo del principio.

El funcionamiento del mecanismo de expulsión es bastante simple: al abrir la puerta se empuja el disco desde dentro.

Como añadido interesante, están los silenciadores de goma que aislan las vibraciones del disco duro y evitan que se transmitan a la caja. Esto es especialmente importante en caso de tener más de un disco duro, pues la resonancia entre ellos, amplificada por los paneles laterales de la caja, puede causar ruidos bastante molestos.

El rack también incluye un led con cable de conexión, que supuestamente habría que conectar a la placa base. En la práctica, a menos que solo se use un disco duro, o que la placa base tenga más de un conector, este led tiene bastante poca utilidad. Tal vez se podría conectar a alguna otra cosa para otro tipo de señalización.

El conector de corriente y datos Serial ATA, realmente es un adaptador macho-hembra, de lo más simple que se puede encontrar. Por tanto también de lo más robusto y menos intrusivo, al no necesitar alimentación, no tener puntos de fallo en circuitería (de la que carece) ni introducir retardos en la conexión. Podemos comprobar cómo no afecta para nada a la conexión en estas gráficas de velocidad.

Si nos fijamos en la parte trasera de este rack, es bastante baja, facilitando la ventilación. La puerta del rack también tiene ranuras, permitiendo tanto introducción como extracción de aire para refrigerar el disco duro, en función de la presión interior de la caja.

Si se desea acoplar un ventilador para mayor seguridad, aunque el rack no esté de por sí preparado para ello, en una instalación típica quedará espacio para añadir un ventilador de 80x80mm entre el conector y el borde de la bahía de 5 1/4, que aportará suficiente flujo de aire como para mantener los discos a una temperatura razonable.

Pros:

• Permite interambiar discos SATA sin necesidad de tornillos
• Funcionamiento robusto, sin electrónica
• Silenciadores de goma
• Espacio libre para ventilación

Contras:

• El cierre con llave falla si se cierra mal
• El led es prácticamente inútil
• No contempla nada para sujetar un ventilador

Dónde comprar

Aunque prefiero hardware con algo de garantía de calidad, motivo por el que acabé pidiendo unos cuantos en MOD-PC (para todos los equipos), se pueden encontrar otros modelos, copias, ¿plagios?... en páginas como eBay o DealExtreme (Hong Kong) por una fracción del precio oficial.

(Enlaces rápidos: fotos en Flickr, vídeos en Youtube)

Nunca se me dio bien la física, siempre hacía demasiadas preguntas:

- ...y además el Culombio es Amperio por segundo - sentenciaba el profesor.
- ¿Por qué?
- Por la fórmula.
- Pero, ¿por qué?
- Porque sí.
- ¡Porque sí tu puta madre! - pensaba yo, mientras dibujaba fractales al margen.

Así que nunca se me dio bien la física.

Demasiados profesores desencantados con la vida, hartos de enseñar algo completamente diferente a lo que habían estudiado, leyendo libros y exigiendo que se los transcribiésemos de memoria en el examen. Una pérdida de tiempo. Ni a los que se lo empollaban sin entender les ha servido de nada -no hay cosa que se olvide más rápido que los conocimientos no relacionados- ni a los que queríamos entender nos ayudaba en nada.

De hecho, a algunos escépticos de nacimiento nos entraba por un oído, y salía por el otro. ¿Empollar basura sin sentido? No gracias, prefiero jugar con el debugger o leerme la ayuda del Visual C.

Hasta hoy, 15 años más tarde, cuando se me ocurre pelearme con Google para calcular el peso que puede aguantar un imán circular de 50x20mm y 1.33 Teslas... cuando tras saltar de web en web caigo en la página del Amperio en la Wikipedia, donde aparece esta bonita nota:

Proposed future definition

Since a coulomb is approximately equal to 6.24150948×10¹⁸ elementary charges, one ampere is approximately equivalent to 6.24150948×10¹⁸ elementary charges, such as electrons, moving past a boundary in one second.

As with other SI base units, there have been proposals to redefine the kilogram in such a way as to define some presently measured physical constants to fixed values. One proposed definition of the kilogram is:

The kilogram is the mass which would be accelerated at precisely 2×10^-7 m/s² if subjected to the per metre force between two straight parallel conductors of infinite length, of negligible circular cross section, placed 1 metre apart in vacuum, through which flow a constant current of exactly 6 241 509 479 607 717 888 elementary charges per second.

CIPM Recommendation 1 (CI-2005)

[...] possible adoption by the 24th CGPM in 2011.

¡Por fin! ¡12 años han tardado en darse cuenta de la estupidez!... o unas decenas más. No se define el Culombio en función del Amperio, ¡sino el Amperio en función del Culombio! No se define el Amperio en función del Kilogramo, ¡sino el Kilogramo en función del Amperio!

Durante todo ese tiempo, todo el mundo copiándoles como borregos, creyendo ciegamente en la infalibilidad de un organismo tan ilustre y responsable como el encargado del SI. Criticando impunemente a los que se atrevían a llevar la contraria "sin preparación". Para que luego esos mismos se llamen "científicos", ¡ja! Creyentes paletos, eso es lo que son algunos, desde que nacen hasta que mueren.

Ya sé, ahora me vendrá alguno a decir que qué más da "a=b" que "b=a". Salvo por el detalle de que una definición es "a=>b" vs. "b=>a", lo cual los interesados podrán consultar en su libro de texto relativo a lógica y deducción, en la sección que trata de los axiomas.

Para los que opinamos que la física no debería dejar de responder el "por qué" salvo al toparse con la filosofía, la postura de más de uno -defendiendo a capa y espada axiomas sin más motivo- siempre nos ha parecido estúpida y falta de lógica. De poco sirve admirar a Feynmann u otras mentes brillantes, si no se lo aplica uno a uno mismo. Es más: admirarlos puede ser tan solo otra muestra de su creencia en el argumento de autoridad, tan científica como la creencia en dios o en el hada madrina.

PD: Lo del imán, depende de la permeabilidad magnética, grosor e intensidad de los campos magnéticos inducidos en las placas/objetos que se le peguen, datos que por ejemplo en los aceros pueden variar bastante, por lo que habrá que comprar el imán -o uno similar- y hacer el experimento, en vez de calcularlo de antemano.