Que bonito es compartir, DAVid !! (1ª parte)

   Bueno, con este título seguramente no queda muy claro de que va esto, pero seguro que estás de acuerdo conmigo en lo bonito que es compartir, es algo que de pequeñitos nos enseñan que es mucho mejor que ser egoista y querer las cosas sólo para uno mismo. Y esa idea la hemos llevado al mundo interconectado de hoy en dia donde un ordenador no tiene sentido por si solo, si no tienes acceso al mundo exterior o a recursos compartidos con los demás, de que sirve. Pues de eso va todo esto, de como compartir teniendo en cuenta que todos somos diferentes pero no por ello deben tener unos preferencia sobre los otros.

   No estoy filosofando sobre la naturaleza humana aunque lo pueda parecer, sino sobre los diferentes sistemas operativos y protocolos de compartición de ficheros que existen hoy en dia y de como cada uno tiene sus propias preferencias por uno u otro protocolo a la hora de definir lo que es un recurso compartido (curiosamente cada uno considera que la forma “natural” de compartir es el protocolo propio de su plataforma). Lo ideal sería que, independientemente del sistema operativo que usemos, podamos tener acceso a los recursos de forma totalmente transparente y que luego se presenten en cada sitio adaptados a las condiciones especiales de cada uno. Ésta es la idea detrás del protocolo HTTP, pensado e ideado para compartir información en forma de documentos de texto facilmente accesibles desde cualquier navegador sobre cualquier plataforma: un documento en particular debería poder accederse y obtener el mismo resultado independientemente de la presentación final, pero en esencia el contenido será siempre el mismo.

   Si esto es algo natural para los documentos, ¿porqué no lo es para los ficheros?

 

Anatomía de… el asignador de losas de Linux

Empiezo con éste una serie de artículos, traducidos de los originales de M.Tim Jones (mtj@mtjones.com) y que se pueden encontrar en el servicio de documentación técnica de IBM. Algunos de ellos ya tienen algunos meses de antigüedad, lamentablemente los he descubierto recientemente a partir del último publicado, pero los voy a ir traduciendo en el orden cronológico de publicación intentando traducir uno cada semana.

Puesto que muchas veces la designación técnica de algunos elementos y algoritmos descritos en estos artículos suele ser la inglesa, sin que exista una traducción válida, adjuntaré a cada traducción literal que haga de estos conceptos el nombre original en inglés.

Y una vez expuestos estos dos puntos, empiezo con el cuerpo del artículo original.

 

Anatomía del asignador de losas (slab allocator) de Linux

[artículo original]

Un buen rendimiento del sistema operativo depende en parte de la habilidad del propio sistema para gestionar eficientemente los recursos. En los viejos tiempos, los gestores de pila (heap memory managers) eran la norma, pero el rendimiento se veia afectado por la fragmentación y la necesidad de reasignar memoria. Hoy, el núcleo de Linux® usa un método que fue originado en Solaris pero que ha sido usado en sistemas empotrados durante algún tiempo ya, asignando memoria como objetos basándose en su tamaño. Éste artículo explora las ideas tras el asignador de losas (slab allocator) y examina sus interfaces y sus usos.

 

Actualización automática de repositorios RPM

Probablemente una de las causas por las que el usuario medio ha encontrado Ubuntu como una distribución atractiva frente a otras más clásicas es, además de por una buena selección de aplicaciones sencillas, el sistema Debian de actualización de software: apt-get.

Para los que, como yo, venimos del mundo RedHat y funcionamos con sistemas que han heredado su gestión de paquetes RPM, quizá nos parece algo incontrolable el hecho como apt-get gestiona las descargas, ya que simplemente te instala todas las dependencias que te hagan falta y la última versión de todo. Esto en una instalación de usuario típica es fantástico, porque de una manera sencilla configuras las actualizaciones automáticas y siempre estás al día sin preocuparte de que necesitas y si tienes que quitar este o aquel paquete para poder poner el nuevo. Pero en un sistema de servidor no es tan trivial: cambiar la versión de una determinada libreria o aplicación puede hacer que otra, que depende exactamente de aquella, deje de funcionar sin razón aparente.

En ese sentido, el sistema RPM es mucho más selectivo y te permite un mayor control de lo que tienes instalado, y te permite incluso definir desde donde lo quieres instalar (del DVD original, de internet, de un disco en otro ordenador…). Esta es la gran ventaja, a mi modo de ver, del sistema RPM: no necesitas una conexión a internet en cada PC, y esto en una red local de una empresa puede ser el escenario.

De cualquier modo, y teniendo en cuenta la posibilidad que tiene RPM de usar repositorios definidos en algún sitio, podemos emular el funcionamiento de actualización automática de apt-get.

 

Breve manual de comandos básicos de consola

Existen una enorme cantidad de comandos de consola en el mundo *NIX, esto proporciona a éste entorno una potencia y flexibilidad increíbles pudiendo hacer absolutamente de todo y teniendo control absoluto sobre los procesos que lanzamos en nuestro sistema y sobre los ficheros que manejamos, así como sobre su contenido. Pero esta flexibilidad no es fácil de asimilar ni de controlar, y de hecho uno de los primeros problemas que se encuentra con el novato en el mundo Llinux suele ser un entorno hostil y extraño en el que debe dejar a un lado el ratón y tener en la memoria los comandos, ya que no hay iconos ni ayudas visuales, sólo una línea de comandos que espera pacientemente que se le diga qué debe hacer.

Se echa en falta en esos momentos un manual sencillo, no-completo (ya que una lista completa de todos los comandos GNU y de la shell que usemos es tan extensa que no sabríamos por donde empezar), y sobre todo centrada en lo esencial para poder empezar a movernos.

En ésta página voy a intentar formar una lista de comandos que puedan servir a cualquiera para empezar a moverse por la consola, evidentemente hay muchísimos más y seguramente me dejo alguno que alguien pueda pensar que es esencial. Pero creo que con éste listado se pueden realizar todas las funciones básicas del sistema, y aprender el resto sobre la marcha usando los manuales y la ayuda del sistema será sólo cuestión de tiempo y práctica, cosa que por otra parte resulta vital para moverse en éste entorno en el que debemos tener siempre buena memoria para recordar comandos, ubicaciones de ficheros, …

Se admiten todo tipo de correcciones y/o añadidos, que en todo caso podrían ir a parar a un listado de comandos avanzados. Espero que ésto pueda ser de utilidad a alguien.

 

Porqué es difícil recuperar un fichero borrado de EXT3

[traducción del artículo original que se encuentra en ésta página]

Todos lo hemos hecho antes: accidentalmente tecleas el argumento incorrecto al hacer rm o seleccionas el fichero incorrecto para su borrado, al pulsar enter te das cuenta de tu error y tu estómago da un vuelco. Y cuando vas a buscar la copia de seguridad del sistema no hay ninguna.

Hay muchas herramientas de desborrado para sistemas FAT y NTFS, pero hay muy pocas para EXT3, que es actualmente el sistema de fichero por defecto de muchas distribuciones Linux. Esto es debido al modo en que los ficheros EXT3 son eliminados: información crucial que almacena donde está localizado el contenido del fichero es eliminada durante el proceso de borrado.

En este artículo, echaremos un vistazo a bajo nivel de porqué la recuperación es dificil y a algunas aproximaciones que son efectivas algunas veces. Usaremos herramientas de código abierto para la recuperación, pero las técnicas no son completamente automáticas.

 

PHP y la codificación de caracteres

Ya sé que esto no tiene que ver específicamente con linux, puesto que PHP es un lenguaje de programación multiplataforma, pero si es uno de los más usados en entornos linux para desarrollos web (evidentemente también hay otros como Perl, Python, Java, etc…). Por eso y por los problemas que pueden surgir con la codificación e internacionalización de caracteres es que creo que éste es un tema delicado.

Últimamente casi todas las distribuciones (mandriva 2007, ubuntu feisty, opensuse, …) funcionan enteramente de manera nativa con sistema utf-8 para evitar los típicos problemas con los “caracteres especiales”, o lo que los americanos/ingleses consideran que es especial simplemente porque no corresponde con su alfabeto. Muchas veces esos caracteres se pueden evitar, sobre todo en idiomas como el castellano o cualquier otro que use el mismo alfabeto, simplemente no incluyendo acentos, eñes, etc… pero otras veces es más complicado, no siempre se puede escribir según qué evitando todo eso. Y es peor en otros idiomas que usan distintos alfabetos, estos son los que promueven el uso del alfabeto utf-8 que es mucho más lógico.

 

nmap: mapeando la red

“nmap” es una herramienta impresionante para configurar, explorar y verificar agujeros de seguridad en redes de todo tipo. Es multiplataforma y está disponible tanto a nivel de consola como en aplicaciones gráficas que le hacen de frontend (”knmap” y similares).

Si leemos la página de manual que tengamos en cualquier distribución linux sobre esta herramienta, veremos la infinidad de opciones y posibilidades que tiene, tantas que se hace muy dificil llegar a ser capaz de entender todo su potencial, sobre todo para alguien que no tenga mucha idea de cómo funciona el tráfico de red, las topologías, servicios, puertos, etc….

He encontrado éste artículo muy interesante en castellano sobre como utilizar este comando con todas sus opciones, desde cero las opciones que pueden ser más comunes, creo que vale la pena que le echeis un ojo.

 

Linux y la teoría de la relatividad: el tiki-taka del kernel!

Parece increíble poder mezclar estos tres conceptos, pero parece ser que el pingüino nos tenia reservada una pequeña sorpresa temporal, al menos en la versión x86-64 que no parece estar muy fina a pesar de llevar ya cierto tiempo en el mercado los procesadores a los que va destinado.

Vayamos al grano, tengo una máquina AMDX2 de 64 bits con un núcleo pre-compilado de la Mandriva2007 para x86-64. El rendimiento es más que aceptable, va muy rápido y no ha dado ningún problema salvo tener que encontrar todo el software que me ha hecho falta en la versión adaptada a esta arquitectura (para poder instalar via RPM, evidentemente podría, y lo he hecho con algún paquete, haber compilado los fuentes, pero no siempre es tan sencillo como pueda parecer)

En cualquier caso, hace unos dias he tenido serios problemas de “continuidad” con el funcionamiento de esta máquina, ya que me aparecían “kernels oops” que la reiniciaban o que la dejaban en un estado inestable en el que la mayoría de señales no funcionaban (fallaba algún subsistema y todo lo relacionado con él también). Los “oops” tenían que ver con IRQs, con E/S de disco cuando haciamos trabajo intensivo sobre él, etc…

 

KDE y el DCOPserver

Hoy al reiniciar el PC con Mandriva 2007 que tengo, y que se había parado por algún corte de corriente, no he podido reiniciar el modo gráfico por un error al cargar el escritorio KDE:

Could not read connection list /home/user/.dcopserver _localhost_0.
Por favor compruebe que el programa “dcopserver” se esta ejecutando

Después de googlear un rato buscando alguna solución al problema este, me he encontrado con varias soluciones de gente:

 

/etc/hosts

Hace poco tuve que instalar un nuevo servidor en el trabajo, y por supuesto le puse un nombre para que sea más fácil de encontrar que no por la IP. Era algo relativamente sencillo hacer que el resto de servidores le conocieran: simplemente una entrada en el fichero /etc/hosts correspondiente haría que la resolución de IP fuera directa. Pero en los clientes güindous, que por alguna razón no están dentro de ningún dominio sinó simplemente dentro de una misma red por máscara, no parecía tan sencillo. Después de darme de cabezazos con la configuración de un servidor DNS local, me acabé rindiendo a la evidencia: esto hay que dejárselo al que sabe y tendré que usar la IP para encontrar el servidor…

Pues justo cuando empezaba a desfallecer, pensé ¿no tendrá el güindous alguna cosa parecida al fichero hosts en su configuración de la red? seguro que sí, que hay alguna ventanita o pestaña o … donde se pueda registrar la lista de máquinas conocidas. Y resulta que, después de un ratito de googlear, encuentro un señor que dice que el mismo fichero que en linux existe y que está en

c:/windows/system32/drivers/etc/hosts
(en el caso de win2k es en c:/winnt)

Voy para allá, y cual es mi sorpresa al abrir el fichero, ver que es un fichero de texto en el mismo formato exacto que el fichero *nix, pero lo más grande es que en el comentario inicial donde describe el formato de cada una de las lineas pone que es un formato registro por M$ (tócate los cojones!!)