29 de marzo de 2009

No más atime con relatime

Por fin, despues de tanto tiempo de discusiones absurdas, en uno de sus arranques Linus ha incluido y activado por defecto relatime. Que es una abreviación de "relative atime". Y "atime" es, a su vez, una abreviación de "access time", donde se almacena la última vez que se accedió a ese archivo.

El problema de atime es que, como consecuencia, cada vez que se lee un archivo hay que realizar una escritura para actualizar ese campo. Algo que no es ninguna minucia, porque los programas están constántemente leyendo cosas, a veces con mucha frecuencia, y se generan auténticas "tormentas" de actualizaciones de atime pendientes. De hecho, es una de las cosas que más pueden enlentecer una máquina. Ya conté hace tiempo que en los pedazo de servidores de kernel.org, el simple hecho de desactivar la actualización del campo atime (con la opción "noatime") les redujo la carga del sistema a la mitad. Un simple doble click en la carpeta del navegador de archivos implica una escritura para actualizar el atime del directorio....y una adicional (en la práctica, varias adicionales) por cada uno de los archivos presentes en el directorio, a los que el navegador de archivos accede para averiguar su contenido. En un servidor web, cada petición HTTP implica una actualización del atime de todos los archivos .html/.php a los que se acceda, generando más escrituras cuantas más visitas se reciben (que es cuando menos se necesita que el disco esté perdiendo el tiempo con actualizaciones de atime)

El caso es que atime es parte de POSIX. Es uno de esos casos donde los estándares se apartan de la realidad, porque desactivar la actualización de atime es uno de los recursos más frecuentes en todo tipo de sistemas operativos (en las comparaciones windows vs linux pagadas por microsoft, lo desactivan siempre, en ambos sistemas), pero como el estándar es el estándar sigue siendo la opción por defecto en muchos sistemas. Y hay algunas utilidades -raras-, como "tmpwatch", que se basan en el campo "atime" para fijarse en si un archivo ha sido accedido recientemente. Asi que aunque se puede estar años funcionando sin atime (como un servidor) y sin tener ningún problema, las distribuciones eran reacias a cambiar una aspecto por defecto del kernel como lo es la actualización del campo atime (aunque algunas, como Ubuntu, lo han hecho). Asi que al final se ha inventado realtime: Se actualiza el campo atime...solamente si entre ese momento y la anterior fecha de atime han pasado más de 24 horas. Eso elimina gran parte de las actualizaciones de atime, pero al mismo tiempo no las elimina del todo.

El resultado es que la mayoría de las distros incorporarán este cambio, y el rendimiento de los equipos de la gente aumentará un poco...por la cara. Creo que es el primer Unix que hace algo así de serie, y ya era hora de que alguien lo hiciera.

20 de marzo de 2009

Nuevo firewall habemus: adios iptables, bienvenido nftables

Parece ser que Patrick McHardy, uno de los desarrolladores de iptables, ha sacado a la luz la primera versión de nftables, un sustituto de iptables reescrito desde cero y en fase muy alpha. El anuncio original da aun más detalles que la anterior noticia.

Francamente, despues de leer varias veces el anuncio original, no soy capaz de averiguar exactamente qué mejoras tiene respecto a iptables (además los temas de redes me producen sopor y soy un cateto en estas cuestiones). Parece tratarse de una gran mejora en cuanto a como se implementa internamente este tipo de mecanismos, pero exteriormente (en lo que viene a ser lo que el usuario puede hacer con esta herramienta) es lo mismo, exceptuando que desparecen algunas restricciones presentes en iptables, que el "lenguaje" de la línea de comandos parece ser mucho más intuitiva, y que el sistema es, en general, mejor.

La principal mejora a ojos del usuario parece ser que se rompe la relación "una regla, una acción", lo cual a veces obliga a encadenar varias reglas en iptables para ejecutar varias acciones simultaneas sobre un mismo paquete, en nftables parece que se podrían tener varias acciones en una sola regla. El ejemplo que ponen de esto es el de al detectar un determinado paquete, informar de su presencia a los logs, contarlo y posteriormente drop-earlo. En iptables esto parece requerir por narices de tres reglas, en nftables puede hacerse en una (y no se trata de una cuestión del interprete que pueda solucionarse en iptables con algún tipo de comando "wrapper", como han hecho muchos proyectos con propósito de hacer "más fácil" el uso de uptables)

Por lo demás, la descripción indica que el diseño de este nuevo juguetito se ha hecho siguiendo la tradición unixera de separar estríctamente los mecanismos de las políticas, lo cual tiene como resultado una implementación del lado del kernel mucho más pequeña que la de iptables, más simple y muy escalable, y una mayor participación de la herramienta de espacio de usuario en el proceso de la "política" introducida por el usuario. El programa "construye" de algún modo las reglas, crea una representación interna de las reglas que el kernel entiende, se envía al kernel mediante netlink y éste se encargaría de hacer lo que esa representación ordena que se haga. Siento no poder ser más específico, pero parece un tema más apropiado para desarrolladores de compiladores (es decir, un coñazo). Y perdonenme, pero es sábado y es la hora a la que la gente suele empezar a salir a los bares.

18 de marzo de 2009

¿Como sería un mundo IBM+Sun para el software libre?

Supongo que a estas alturas ya se habrán enterado ustedes del rumor de compra de Sun por parte de IBM. Tiene pinta de ser sospechosamente veraz, por varias razones. Primero, viene del Wall Street Journal, que aunque no deje de ser un periódico tiene cierta reputación. Segundo, en estos precisos momentos el subidón de las acciones de Sun va por el 80% (la oferta teórica de IBM sería del doble del valor en bolsa de Sun al precio de ayer, 6.000 millones). Eso quiere decir que en menos de 24 horas se han metido más de 2.000 y quizás más de 3.000 millones en acciones de Sun, y un movimiento de dinero tan grande suele ser de grandes fondos de inversión, quienes no creo que arriesgarían una cantidad de dinero así (y menos tal como están las cosas) si no supieran con certeza que no van a perderlo. Aunque de la bolsa nunca hay que fiarse, y menos ahora. Por otra parte, hay quien duda de que tenga sentido, pero cuando el rio suena...además, Cisco acaba de entrar en el mercado de los servidores, y HP compró hace casi un año una compañía llamada EDS por 13.000 millones, según dicen para hacer competencia a IBM. Hay quien dice que tiene sentido que eso esté llevando a IBM a hacer esto.

Pero dejando este tema (de la que ya se ha enterado todo el mundo), yo me pregunto (que es algo que ha hecho menos gente y por lo tanto es más susceptible de atraer visitas) ¿cómo sería libre un mundo posterior a esta hipotética transacción entre asquerosos multimillonarios quiebrabancos? Y sobre todo, ¿como influiría al software libre?

La primera gran diferencia estaría en Java. IBM lleva muchos años apoyando a Java, pero con el control del lenguaje y de la VM de referencia (para que vamos a engañarnos: esos comités supuestamente democráticos dejan bastante que desear, y a la hora de la verdad es Sun quien decide lo que se hace o deja de hacer en Java) las cosas cambiarían bastante. Por ejemplo, no creo que IBM fuera tan estúpidamente elitista como lo ha sido y es Sun, no hay más que recordar como ha llevado la competencia con C#, hasta el punto de que .NET pareció, durante mucho tiempo, una plataforma más abierta. Luego está el tema de la plataforma de desarrollo, Netbeans y demás. IBM podría unificar y reforzar al mundo Java.

Respecto a SPARC, sin duda IBM lo mataría. Pero como el futuro de SPARC tampoco ha estado nunca demasiado claro tampoco parece una gran pérdida.

Respecto a Solaris, es más dificil predecir. Por una parte, es dudoso que IBM vaya a echarse atrás en su apoyo a Linux, con todo lo que ha invertido en él. No parece que a IBM le interese centrarse en el desarrollo de sistemas operativos de este tipo, esa es la razón por la que se metieron en Linux, donde la mayor parte del desarrollo lo hacen empresas como Red Hat. IBM aun mantiene a un buen equipo de desarrollo, pero lo hacen tan solo como investigación, no tienen productos que incluyan el kernel Linux, a diferencia de Red Hat o cualquier otra distro. Se desentienden completamente de esos temas, no tienen ni quieren tener su propia distro, mantienen ese equipo de desarrollo solo para que a las demás empresas basadas en Linux les vaya bien, no porque ellos saquen dinero de hacer eso. Con Solaris tendrían que hacer ellos casi todo el desarrollo, tendrían venderlo ellos mismos porque solo Sun vende Solaris, tendrían que intentar generar un "ecosistema" similar al que han generado con Red Hat & cía, pero compitiendo a la vez con Red Hat & cía, que van a seguir apostando por Linux...suena demasiado improbable, pero cosas más raras hemos visto. No descarten nada, incluidas GPL-ificaciones del código.

Respecto a OpenOffice y Mysql, creo que sería beneficioso un cambio, especialmente en el primer caso. No creo que IBM esté obsesionado con mantener derechos de copyright en todo el código (de hecho, en GCC se lo ceden gustosamente a GNU), que es un gran problema y ha causado ya un fork en go-oo.org. Mysql espero que lo venda, o que lo mantenga, sería muy triste que intentara matarlo (no estamos hablando de cerrar el código ni nada, sino simplemente de cortar la inversión en mejoras) para evitar competencia a DB2, pero desgraciadamente es algo que podría pasar. Esten muy atentos a este punto porque es muy importante, pero no olvidemos que aun está postgresql...

En los servidores, IBM alcanzaría una cuota de venta de servidores del 42%, muy por encima del 29% de HP, en segundo lugar. ¿Acudirá HP a los juzgados antimonopolio? No sería sorprendente, están muy de moda. Por otra parte, Sun tiene muchos productos hardware relacionados con el almacenamiento (provenientes de la compra de storagetek) y montones de otras cosas que a saber que carajo va a pasar con ello.

En fin, esperemos a ver si se confirman los rumores, a ver como evoluciona el tema. Sea cual sea el resultado, esperemos que sea beneficioso para el software libre.