27 de octubre de 2005

"¿Y tu, que algoritmo de congestión TCP usas?"

Pues esa pregunta es buena. Porque al recopilar información sobre los cambios que se producen en el kernel, me enteré que Linux desde 2.6.13 tiene más de uno. Y no solo eso, sino que tambien se puede - ojo al dato señores - seleccionar un algoritmo de congestión diferente para cada socket (con setsockopt())

Y a través de un artículo de LWN, me he enterado de qué algoritmos hay disponibles, y las propiedades que tiene cada uno. Total, que el que se compila por defecto parece estar orientado a redes rapidillas (adsl y demas supongo). Asique he ido a la configuración del kernel y he desactivado ese y activado el "Westwood". No he hecho mediciones pero teóricamente debería ser más óptimo para un triste modem de 56 K (o eso creo)

(Nota: Se puede seleccionar el algoritmo por defecto de entre los compilados en /proc/sys/net/ipv4/tcp_congestion_control, para que no diga nadie que me contradigo a mi mismo cuando escribí eso de que "la gente no debería recompilar los kernels ellos mismos" :P)

26 de octubre de 2005

dos cosas

Las dos cosas interesantes que se están cociendo en el kernel ahora mismo y que en mi humilde opinión hacen babear por lo que podrían llegar a hacer: A CLOCK-Pro page replacement implementation y Adaptive file readahead

El uno parece ser un algoritmo de reemplazo moderno (publicado en Usenix en 2005, según escribe Rick van Riel no ha habido algoritmos mejores que fueran implementables en sistemas operativos de propósito general hasta el 2002, lo que hace pensar que Linux está siendo bastante "innovador" en este aspecto, no todo en el mundo de los sistemas operativos se inventó hace 30 años). Y del otro hablan mejor los números: In fact, Wu claims results which are "pretty optimistic." They include a 20-100% improvement for applications doing parallel reads (Nota: Este debería ser el caso de un servidor web apache/thttpd/etc sirviendo multiples peticiones de páginas estáticas simultaneamente), and the ability to run 800 1KB/sec simultaneous streams on a 64MB system without thrashing

24 de octubre de 2005

Adios, Tarja

Los que sepan quien es Tarja Turunen sabrán a que me refiero. En la página de nightiwsh (que ayer estaba caida por la avalancha de visitas) se puede leer la carta que el resto del grupo la ha entregado al final de la gira. La hechan del grupo

Para los que no sepan quien es Tarja Turunen, decir que es una de las mejores cantantes que hay por ahi de su categoría y no es necesario decir mas del tema, y el que piense que lo digo por ser fan de ellos es libre de bajarse un directo (los discos siempre se retocan) de ellos para comprobar que no es en broma, o bajarse una canción cualquiera del disco, como esta

Como nota curiosa, las agencias de prensa finlandesas, francesas, la propia televisión finlandesa, se han hecho eco del evento. Eso aquí en España no lo veremos en la puta vida, porque aquí los grupos del tipo de nightwish ("jevis") no tienen cabida (del último disco, el que mas éxito internacional ha logrado despues de otros muchos no menos buenos, ponian un single en los 40, demos gracias a dios) y la mayoría de gente piensa que son malos. Como si se pudiera determinar la calidad de un grupo por su estilo, o como si existiera algun estilo en el mundo que no tenga grupos buenos, o como si existiera algun estilo en el que todos los grupos sean buenos. Allí en su tierra natal en Finlandia, quedaron en una ocasión entre los 3 finalistas para ir a Eurovisión a representar a su pais, y eran uno de los grupos mas escuchados del pais, alcanzando puestos altos en las listas de ventas y tal. Pero como acabo de decir, aquello no es España

microsoft shell vs unix shell/python/perl

Ars technica ha publicado una guia bastante detallada de 13 páginas explicando que es MSH (el próximo shell de microsoft)

Le da mil vueltas a bash/ksh/zsh y derivados, por supuesto (no es dificil superar a una tecnología que lleva 30 años estancada, obsoleta en muchos aspectos y sin muchas expectativas de mejorar - bueno, zsh al menos como "shell interactivo" tiene cosas interesantes, pero bash siempre ha sido deprimente incluso comparandolo con otros shells unix), y entra a competir con python, perl & friends, e incluso parece integrarse con .NET.

En la comparación con estos últimos ya no se como saldrá, pero si que se puede decir una cosa: MSH es un shell, igual que bash, no un simple "interprete de scripts" que es lo que son python & perl (aunque se pueden usar en modo "interactivo", dejan mucho que desear como "shells de uso diario y administración del sistema", están diseñados para ser usados desde bash no para sustituirlo). Tal como yo lo veo, ahí está el problema: En unix, estamos acostumbrados a programar cosas en python y "ensamblarlas" a través de tuberias y construcciones de bash. Que no está mal, pero las tuberias no son la solucion a todo: cuando para conseguir los datos de algo en bash para cualquier cosa necesitas hacer "HAZME_EL_TERMINAL_MAS_GRANDE=100 dpkg -l | cut -d ' ' -f 3" está claro que algo falla. Sería fantastico si en bash pudiera hacer kudzu.probe() para extraer los datos del hardware instalado y manipular esos datos en la propia linea de comandos del sistema para administrar alguna cosa en vez de crear algun script que lo haga y ejecutarlo desde el shell con "python script.py"

Afortunadamente, hay alternativas. El problema, como siempre, es hacer que la gente las use, que sustituyan a bash por defecto como shell (y al que se le ocurra decir que "python es lento" que se pregunte primero si los scripts que usamos hoy están orientados a tareas de "alto rendimiento"), que puedas hacer de todo en ellas sin tener que recurrir a "ayudas de terceros", etc etc. En cualquier caso, un servidor va a hacer apt-get install ipython

19 de octubre de 2005

inotify

El otro día en un thread sobre inotify se leia una cosa interesante. El jugo de inotify es monitorizar cosas sobre inodos. Entre otras cosas, puedes decirle a inotify, con IN_DELETE_SELF, que te avise de cuando un archivo va a ser borrado

Y aquí venía el problema curioso. Inotify vigila a los inodos, y como buen sistema unix, en linux la ruta "/foobar/archivo" no es mas que un "enlace" a un inodo. Puedes borrar ese enlace a ese inodo para borrar el archivo, puedes hacer que apunte a otro inodo, pero el inodo antiguo seguirá ahí y puedes seguir escribiendolo o leyendolo (razón por la cual en unix es posible sobreescribir un archivo mientras está abierto, ej: al actualizar paquetes)

Y ahí está el problema: Si quieres "espiar" con inotify y con IN_DELETE_SELF el momento de borrado de un archivo, te encontrarás con que despues de hacer un "rm" inotify no notifica nada porque el inodo aun existe. El problema es que en unix no puedes monitorizar el borrado de un archivo monitorizando inodos (y por tanto, con inotify) - unix no funciona asi. Asi que como bien dijo linus, la propia existencia de IN_DELETE_SELF es estúpida. No es un defecto de unix ni de inotify: Es una consecuencia del diseño de unix, asi que como dice linus en el mensaje, si quieres monitorizar el borrado de un archivo no tendras mas remedio que monitorizar al directorio. Aunque parece absurdo a primera vista (al menos a mis ojos), esa es la manera "correcta" de hacerlo en unix. Me parecia algo curioso para comentar.

17 de octubre de 2005

¡por fin! escritura para NTFS

Anton Altaparmakov es el PUTO AMO. En el último anuncio del -mm ha anunciado que ya tiene soporte COMPLETO para escritura en NFTS (le falta el soporte para crear y borrar archivos, algunos problemas con archivos fragmentados) pero supongo que si ha llegado hasta este punto, es cuestión de tiempo...

Y digo PUTO AMO porque hay que tener huevos, muchos huevos, para implementar un sistema de archivos complejo como lo es NTFS sin NADA DE DOCUMENTACION de parte del autor. Como referencia, el soporte de UFS para sistemas de archivos de freebsd, que tiene el codigo 100% abierto y es mucho mas sencillo que NTFS y muy parecido en diseño a ext2, solo tiene soporte de lectura, y a saber si tendrá el de escritura algun dia. Lo dicho, el puto amo.

16 de octubre de 2005

solaris vs freebsd vs linux

De eso va mas o menos interesante artículo que compara los kernels de solaris, freebsd y linux desde un punto de vista constructivo (que no es poco). Algunas cosas son curiosas

Solaris has support for a "fixed priority" class, a "system class" for system threads (such as page-out threads), an "interactive" class used for threads running in a windowing environment under control of the X server

En Linux, Ingo Molnar propuso cosas parecidas (añadir algo que permitira marcar a las X & friends como "interactivos" para poder tratarlos de manera especial, o poner las X a prioridad -10 para olvidarse de los problemas). Linus lo rechazó frontalmente: In short, you're taking a very NT'ish approach - make certain programs run in the "foreground", and give them a static boost because they are magically more important. And you're ignoring the fact that the heuristics we have now are clearly fundamentally broken in certain circumstances

Esta es la misma la razón por la que de momento Linux no incluye (de momento) la capacidad de cambiar de tipo de scheduler "en vivo" como hacen solaris y otros unix "serios" (que haberlos haylos): En linux se cree que si tienes que recurrir a eso es porque el scheduler principal tiene un bug, y que lo mas logico es arreglar ese bug, no "workaroundear" el problema añadiendo complejidad. Supongo que es ese tipo de actitud la que hace que prefiera linux a los demás.


Linux divides machine-dependent layers from machine-independent layers at a much higher level in the software. On Solaris and FreeBSD, much of the code dealing with, for instance, page fault handling is machine-independent. On Linux, the code to handle page faults is pretty much machine-dependent from the beginning of the fault handling. A consequence of this is that Linux can handle much of the paging code more quickly because there is less data abstraction (layering) in the code. However, the cost is that a change in the underlying hardware or model requires more changes to the code

Igual que esta. Linux tendrá mas codigo dependiente de máquina, pero sacrificar el rendimiento de algo tan importante y tan utilizado por ahorrar esfuerzos a la hora de programar es algo que no va con el "espiritu linux"


Y la mejor de todas: Solaris, FreeBSD, and Linux are obviously benefiting from each other. With Solaris going open source, I expect this to continue at a faster rate.

14 de octubre de 2005

hay que saber perder

Acabo de leer en el blog de Rusty Rusell (el creador de netfilter) una gran frase, en el que destaca las virtudes positivas del entorno "arisco" que hay en el kernel y la poquísima tolerancia que hay frente a la basura (actitud que no se ve en "otros proyectos", y así les va, haciendo rondas de optimización y de reducción de memoria a su software años despues de haber sacado la primera version estable porque ya no entra mas basura en el cubo):

"One thing I gained from working on the kernel: a good sense of when code is crap. If my code is good, it is not because I am smart, but because I refuse to release stuff which stinks, so I'm forced to spend time cleaning it up. The harsh environment of the linux-kernel mailing list trains you to do this yourself

I'm reluctant to harshly criticize the code of others, because I am aware how hurtful such words can be. On the other hand, without such harshness, you end up, say, using a helper thread in the implementation of a library. Not because you're stupid, but because you haven't developed a pavlovian shudder at the thought of releasing such a thing"

Y para los que no lo conozcan, aquí esta la "netfilter song" de rusty que le dió por postear un día como respuesta a un email que preguntaba como funcionaba netfilter:

> The biggest difference is that INPUT chains NOW *behind* "routing
> decision".
>
> So what is the real path of packet?
>
> Rusty?

Rusty reading netfilter:
     ______
    / /  \    /  o  o     \ .____, /
    \______/
  ^^^      ^^^
[TABqwertyiop[]\]

My ASCII art sucks, I know.  Perhaps I should try a different form of
expression:

  When a packet on a network
  Enters Linux from a NIC,
  Or PPP, ISDN,
  Or even via SL/IP,

  It goes right into net_bh,
  Which sees it is IP,
  And hands it via ptype->func()
  To old ip_rcv().                         [pron: `EYE-PEE receive']

  This calls the PRE_ROUTING hook,
  Where ipfwadm was,                       [pron: `EYE-PEE-FWADM']
  And ipchains lived here as well,
  But not iptables, 'cause...

  PRE_ROUTING is for NAT NAT NAT,
  Redirection and so on,
  Inadaquate for filtering,
  So iptables is gone...

  To LOCAL_IN, the one true hook,
  Where filtering ought to be,
  Because we know this very box,
  Is its destiny.

  On the way out, it's just the same,
  'Cause filtering now takes place
  As local packets leave the box,
  In LOCAL_OUT, with grace.

  But what, you ask, are we to do
  About packets passing through?
  Where should we now filter them
  Please give us this one clue?

  Not in PRE_ROUTING nor in POST,
  We don't need three ways here,
  The one true place to filter these,
  Is the FORWARD hook, it's clear.

  The FORWARD hook is just the same,
  But we've added just one thing,
  You get incoming interface,
  As well as outgoing.

Chorus:

  iptables is so cool,
  It makes my packets sing,
  That Rusty he is one hot coder,
  OOPS: my box is crashing...

   Rusty.

10 de octubre de 2005

Changelog del kernel para humanos

(Y si, pongo changelog y no "registro de cambios" :P)

Pues asustado/preocupado por la falta de un changelog decente para linux, me dió por recoger información de varias fuentes: "post-halloween" de Dave Jones, "2.6 status" de Guillaume Boissiere, sección del kernel de LWN.net, google, changelogs oficiales, y seguir día a día todo lo que va a pasando a partir de ahora en el gracias a la maravillosa interfaz web de git con RSS incluido.

Y con toda la información que ha salido de ahí he creado http://wiki.kernelnewbies.org/LinuxChanges. Que todo el mundo coincidirá que es genial y útil, no porque sea buena sino porque no hay nada semejante a esto (con el permiso de LWN)

4 de octubre de 2005

Daría mi vida por.....

Mientras escribía un script que automatize el proceso de actualizar y compilar automaticamente los 3 ó 4 proyectos de los que me gusta "tirar de CVS", y acordándome de que el protocolo de red de Plan 9 devuelve los errores en forma de cadenas de error y no "códigos de error", me he dado cuenta de una cosa: Daría mi vida por que los comandos Unix devolvieran cadenas de error y no absurdos numeros.

Necesito saber qué código de retorno devuelve CVS cuando no hay ninguna actualización en el CVS, y sinceramente me vendría muy bien que el script tuviera algo del estilo: "if cvs update = "No updates found"" en vez de un absurdo "if cvs update = 0".