Seguimos hablando del célebre parche de las 200 líneas de código para aclarar un poco la situación con respecto a ese método alternativo que acaba de aparecer y que hemos detallado en el post anterior. Lo cierto es que aplicar un método u otro no debería dar resultados distintos -a pesar de que algunos usuarios creen que el método «manual» es más eficiente- porque, atención, son equivalente.
Lo explicaba Linus Torvalds en un mensaje a la lista LKML en la que debatían sobre este parche y sobre el método alternativo descubierto por Lennart Poettering. En dicho mensaje Linus comentaba lo siguiente en respuesta a la afirmación de Poettering:
«Básicamente esta es la forma en la que el parche se probó originalmente – haciendo los cambios a mano, sin tener de hecho un parche accesible. Yo le dije a la gente que esto parecía funcionar realmente bien. Y Mike [Galbraith] hizo que funcionara así de forma automática [con el parche en el kernel].
Esto es algo que queremos que esté accesible a todos los usuarios, y en todos los shells, y asegurarnos de que se consigue de forma automática. Incluyendo a usuarios que disponen de distribuciones antiguas, y facilitarlo con un método único. Y así podremos aplicar el cambio a otras heurísticas que podemos ver fácilmente en el kernel. Y de esta forma lo conseguiremos de forma mágica sin que los usuarios siquiera se enteren.
De repente no parece que sea tan maravilloso jugar con bashrc, ¿no?
Ese es a lo que me refiero. Podemos impulsar el cambio en el kernel, y todo «simplemente funcionará». Podemos hacer que esa característica que ya está disponible en el kernel se convierta en algo útil.
La configuración a nivel de usuario para algo que debería funcionar sin más es molesta. Podemos hacerlo mejor que eso.
Y podemos también verlo de otro modo: si encontramos una forma mejor de hacer algo, no deberíamos decir: «bueno, si los usuarios lo quieren disfrutar, pueden hacer esta «<cosa técnica aquí explicada>». Si realmente hay una forma mejor de hacer las cosas, simplemente deberíamos hacerla. Si hacemos que el usuario tenga que hacer estas cosas a mano no podremos tener dicha opción como una característica del sistema.
En cualquier caso, no estoy diciendo que no deberíamos permitir a los usuarios que usaran los cgroups. Por supuesto que también pueden hacerlo a mano. Pero no deberíamos hacer que los usuarios necesitaran hacer cosas tontas que podemos proporcionar más fácilmente por nosotros mismos [en el kernel].
Es la elección entre decirle a todo el mundo: «deberíais hacer esto», y «podemos hacer esto por vosotros». En mi caso siempre elegiría la segunda opción. Sabemos que debería hacerse así. ¿Por qué entonces deberíamos decirles al resto que lo hicieran por nosotros?»
Lennart Poettering, el autor original del método alternativo, ha admitido ese punto de vista, pero también avisa de que este parche no es para todos los usuarios:
«El parche al kernel del que estamos hablando aquí no tiene relevancia para los usuarios normales. Solo es relevante para gente que ejecuta mplayer desde una terminal, y luego hace un «make -j» desde otra.
Podéis seguir el resto del interesante debate en LKML, pero lo que tenéis claro es que ambos son métodos que llevan al mismo resultado, y mientras que el parche acabará aplicándose al kernel de forma transparente -esperemos que pronto esté disponible para nuestras distros- la forma alternativa es para los impacientes que quieran probar esta mejora.
Aunque atención: los usuarios normales con cargas de trabajo «sencillas» apenas notarán nada.
