domingo, diciembre 03, 2006
Presentación en la U.Central
El viernes pasado dí la presentación "Programación de Aplicaciones Multipataforma en Linux con Gtk+", en el 3er Encuentro de Open Source y Nuevas Tecnologías realizado en la Universidad Central.
Para los que asistieron, el esquema de la presentación y el ejemplo se encuentran disponibles aquí.
Espero que los enlaces les sean útiles.
Para los que asistieron, el esquema de la presentación y el ejemplo se encuentran disponibles aquí.
Espero que los enlaces les sean útiles.
miércoles, noviembre 15, 2006
Java GPL
Bueno, para todos ya debería ser conocida la noticia: Sun decidió liberar las fuentes de Java.
Me llamó la atención varias cosas sustanciales:
En general, una muy buena noticia. Eso sí, falta bastante todavía para tener Java Sun GPL en las distribuciones, ya que recién se liberó el código de HotSpot (el motor JIT) y JavaC (el compilador). El próximo año se completará con la biblioteca.
En mi opinión, un triunfo para la comunidad de software libre, y sobre todo para los que trabajaron tanto tiempo en un Java libre (con proyectos como Kaffe, Classpath, Cacao, Jamvm, SableVM, GCJ, etc.).
Notable que ahora que los Java libres existentes son capaces de correr muchas aplicaciones Java (Classpath tiene implementado un 99.9% de la API de Java 1.4 y un 95% de la API de Java 1.5) por fin Sun libera de una vez su propia plataforma.
Por lo pronto, espero con ansias la liberación de la biblioteca de Java, para poder completar Classpath y contar con todas las alternativas de Java compitiendo al mismo nivel.
Me llamó la atención varias cosas sustanciales:
- La licencia, GPL más excepciones de Classpath, las que permiten que ciertos archivos puedan ser enlazados en aplicaciones no GPL. Classpath es la implementación de la biblioteca de Java utilizada en casi todos los proyectos de Java open source hasta ahora, utilizar la misma licencia hace que se pueda mover código entre los dos proyectos sin problemas.
- El grado de preparación para el anuncio: hasta hay videos de Richard Stallman en el sitio de Sun.
- Ya está disponible el repositorio de subversion con las fuentes.
En general, una muy buena noticia. Eso sí, falta bastante todavía para tener Java Sun GPL en las distribuciones, ya que recién se liberó el código de HotSpot (el motor JIT) y JavaC (el compilador). El próximo año se completará con la biblioteca.
En mi opinión, un triunfo para la comunidad de software libre, y sobre todo para los que trabajaron tanto tiempo en un Java libre (con proyectos como Kaffe, Classpath, Cacao, Jamvm, SableVM, GCJ, etc.).
Notable que ahora que los Java libres existentes son capaces de correr muchas aplicaciones Java (Classpath tiene implementado un 99.9% de la API de Java 1.4 y un 95% de la API de Java 1.5) por fin Sun libera de una vez su propia plataforma.
Por lo pronto, espero con ansias la liberación de la biblioteca de Java, para poder completar Classpath y contar con todas las alternativas de Java compitiendo al mismo nivel.
Etiquetas: java, open source
lunes, octubre 23, 2006
Java en los celulares
Hace algún tiempo tuve en mis manos un celular con la posibilidad de ejecutar aplicaciones en Java, un Siemens A65. Esto, obviamente, hizo que me tentara de averiguar cómo es programar para un dispositivo como este.
Bueno, obviamente la plataforma MIDP - Mobile Information Device Profile, es bastante más limitada que un PC estándar, pero es sorprendente lo que un pequeño celular puede hacer.
Y la gracia de contar con un lenguaje así, y una plataforma relativamente estandarizada, es toda la documentación y la facilidad de programar para dicha API.
Así que manos a la obra, instalé EclipseME, el Wireless Toolkit de SUN y a programar.
El resultado, dos pequeños juegos que espero a alguien le sean útiles, disponibles aquí.
Al final el celular se estropeó bastante luego (no alcancé a tenerlo ni cuatro meses), pero espero que a otros les sea útil.
Bueno, obviamente la plataforma MIDP - Mobile Information Device Profile, es bastante más limitada que un PC estándar, pero es sorprendente lo que un pequeño celular puede hacer.
Y la gracia de contar con un lenguaje así, y una plataforma relativamente estandarizada, es toda la documentación y la facilidad de programar para dicha API.
Así que manos a la obra, instalé EclipseME, el Wireless Toolkit de SUN y a programar.
El resultado, dos pequeños juegos que espero a alguien le sean útiles, disponibles aquí.
Al final el celular se estropeó bastante luego (no alcancé a tenerlo ni cuatro meses), pero espero que a otros les sea útil.
miércoles, mayo 10, 2006
Mi primer Notebook
Luego de mucho tiempo vitrineando diferentes opciones, compré un notebook.
Es un Acer Aspire 3623NWXCi, básicamente un notebook relativamente pequeño, con un procesador Celeron-M de 1.5GHz, pantalla de 14" de 1280x800 (ancha), red inalámbrica, disco de 40GB, combo lector DVD/grabador de CD y 256Mb RAM.
Todo lo anterior por 378 lucas en Tecnostore. Y claro, sin windows!.
El notebook corre Ubuntu (uso el beta de la versión 6.06) muy bien, todo funciona sin necesidad de trucar nada. Eso sí, si se desea instalar con sólo 256Mb de ram, recomiendo no usar el live-CD, ya que el proceso de instalación es mucho más lento.
Dado lo bien que ha resultado, me propuse a escribir un pequeño review del computador, por si a alguien también le interesa.
El notebook viene en una caja bastante pequeña, la primera foto la muestra con un CD adelante para comparar el tamaño, y en la segunda puede verse el interior al abrirla. La caja completa pesa 3.9kg.
El contenido se ve a continuación, el manual de usuario, un CD con drivers (inútil para los usuarios de Linux), el transformador, cable de teléfono para el modem y el notebook.
El tamaño es bastante pequeño y liviano, 2.4kg sólo y 2.6kg incluyendo el transformador (que es el peso mínimo que debo cargar). Las fotos siguientes muestran vistas desde varios ángulos.
Las conexiones disponibles son las mínimas, a la derecha tres puertos USB, el modem y la red 10/100, a la izquierda un slot PCMCIA, la unidad óptica y el agujero para el candado. Adelante tiene los conectores de audio y dos botones, uno para activar/desactivar la red inalámbrica y el otro para el bluetooth en los modelos que poseen (en este caso, no sirve para nada), y atrás tiene el conector VGA y la entrada de alimentación.
De fabrica el notebook viene instalado con una instalación mínima de la distribución "Limpus", en modo de texto. Esto realmente no permite hacer nada útil, por lo que es necesario instalar alguna distribución por cuenta propia.
El notebook viene con 256Mb de ram instalados de fábrica en un So-DIMM DDR2 en el primer slot de memoria, con un segundo slot disponible para ampliación. Existe también un modelo con 512Mb ya instalados, pero viene con los dos slots llenos, por lo que se dificulta instalar memoria adicional.
En mi caso, compré 512Mb adicionales por 37 lucas (en PCFactory), con lo que el computador pasó a tener 768MB de ram, suficiente para mis necesidades.
Bueno, en un post a continuación hablaré de la instalación de Ubuntu y el funcionamiento del software.
Es un Acer Aspire 3623NWXCi, básicamente un notebook relativamente pequeño, con un procesador Celeron-M de 1.5GHz, pantalla de 14" de 1280x800 (ancha), red inalámbrica, disco de 40GB, combo lector DVD/grabador de CD y 256Mb RAM.
Todo lo anterior por 378 lucas en Tecnostore. Y claro, sin windows!.
El notebook corre Ubuntu (uso el beta de la versión 6.06) muy bien, todo funciona sin necesidad de trucar nada. Eso sí, si se desea instalar con sólo 256Mb de ram, recomiendo no usar el live-CD, ya que el proceso de instalación es mucho más lento.
Dado lo bien que ha resultado, me propuse a escribir un pequeño review del computador, por si a alguien también le interesa.
Primeras Impresiones
El notebook viene en una caja bastante pequeña, la primera foto la muestra con un CD adelante para comparar el tamaño, y en la segunda puede verse el interior al abrirla. La caja completa pesa 3.9kg.
El contenido se ve a continuación, el manual de usuario, un CD con drivers (inútil para los usuarios de Linux), el transformador, cable de teléfono para el modem y el notebook.
El tamaño es bastante pequeño y liviano, 2.4kg sólo y 2.6kg incluyendo el transformador (que es el peso mínimo que debo cargar). Las fotos siguientes muestran vistas desde varios ángulos.
Las conexiones disponibles son las mínimas, a la derecha tres puertos USB, el modem y la red 10/100, a la izquierda un slot PCMCIA, la unidad óptica y el agujero para el candado. Adelante tiene los conectores de audio y dos botones, uno para activar/desactivar la red inalámbrica y el otro para el bluetooth en los modelos que poseen (en este caso, no sirve para nada), y atrás tiene el conector VGA y la entrada de alimentación.
De fabrica el notebook viene instalado con una instalación mínima de la distribución "Limpus", en modo de texto. Esto realmente no permite hacer nada útil, por lo que es necesario instalar alguna distribución por cuenta propia.
El notebook viene con 256Mb de ram instalados de fábrica en un So-DIMM DDR2 en el primer slot de memoria, con un segundo slot disponible para ampliación. Existe también un modelo con 512Mb ya instalados, pero viene con los dos slots llenos, por lo que se dificulta instalar memoria adicional.
En mi caso, compré 512Mb adicionales por 37 lucas (en PCFactory), con lo que el computador pasó a tener 768MB de ram, suficiente para mis necesidades.
Bueno, en un post a continuación hablaré de la instalación de Ubuntu y el funcionamiento del software.
miércoles, julio 13, 2005
Temas de Debian
Asombroso
A veces me parece increíble como algunas personas se manifiestan. Acabo de ver este BUG reportado en Debian: BUG #318193: xserver-xorg maintainer is spitefull.
Por otra parte, algunos ya se habrán dado cuenta de las dos grandes transiciones que ser viven en Debian Unstable en este momento: cambio a gcc-4.0, el que con una nueva ABI de C++ requiere recompilar todas las bibliotecas y aplicaciones en C++; y el reemplazo de XFree86 4.3 por el servidor de XOrg.
Por esto, en este momento gran parte de la distribución inestable no se puede instalar. No es un muy buen momento para probarla :-)
Y por último, boo (ver mi mensaje anterior) ha sido incluido en Debian, junto con el plugin para monodevelop, en el paquete "monodevelop-boo".
A veces me parece increíble como algunas personas se manifiestan. Acabo de ver este BUG reportado en Debian: BUG #318193: xserver-xorg maintainer is spitefull.
Por otra parte, algunos ya se habrán dado cuenta de las dos grandes transiciones que ser viven en Debian Unstable en este momento: cambio a gcc-4.0, el que con una nueva ABI de C++ requiere recompilar todas las bibliotecas y aplicaciones en C++; y el reemplazo de XFree86 4.3 por el servidor de XOrg.
Por esto, en este momento gran parte de la distribución inestable no se puede instalar. No es un muy buen momento para probarla :-)
Y por último, boo (ver mi mensaje anterior) ha sido incluido en Debian, junto con el plugin para monodevelop, en el paquete "monodevelop-boo".
jueves, abril 28, 2005
Boo... el fantasma de Python.
¿Han visto Boo?
Muchos sabrán que yo no soy un gran amante de Python. Entre las cosas que me disgustan están la lentitud de ejecución y la falta de verificación estática en las llamadas a los métodos.
Bueno, me enteré que no soy el único - eso era evidente en realidad :-), y que existe una comunidad de desarrolladores que han creado un nuevo lenguaje, basado en Python pero ligado a .NET (o a Mono, como se quiera decir).
Este es Boo, y ya es posible usarlo para desarrollar programas en serio, por ejemplo usando Mono en Linux.
Un ejemplo:
Para ejecutar el ejemplo, pueden usar directamente el intérprete de Boo: 'booi ejemplo.boo', o si no puede compilarse: 'booc ejemplo.boo', lo que genera un ejecutable de .NET, 'ejemplo.exe'
Un ejemplo de sesión es:
El mismo código en Python sería así:
Además del hecho de que prefiero BorderWidth=10 a set_border_width(10), Boo tiene muchas otras cosas que me gustan:
Por último, existe ya un plugin para desarrollar en Boo usando MonoDevelop, lo que significa que el depurador integrado, la sugerencia de código y la generación de plantillas funciona. Y más encima, el código generado es multi-plataforma (si se usa gtk#, obviamente).
Si alguien quiere ayuda para instalar en Linux, usando Mono, pregunten.
Muchos sabrán que yo no soy un gran amante de Python. Entre las cosas que me disgustan están la lentitud de ejecución y la falta de verificación estática en las llamadas a los métodos.
Bueno, me enteré que no soy el único - eso era evidente en realidad :-), y que existe una comunidad de desarrolladores que han creado un nuevo lenguaje, basado en Python pero ligado a .NET (o a Mono, como se quiera decir).
Este es Boo, y ya es posible usarlo para desarrollar programas en serio, por ejemplo usando Mono en Linux.
Un ejemplo:
import Gtk from "gtk-sharp"
def pres():
print "Hola"
def salir():
print "Chao!"
Application.Quit()
Gtk.Application.Init()
w = Gtk.Window("Ejemplo")
b = Gtk.Button("Presioname")
w.Add(b)
w.BorderWidth=10
b.Clicked+=pres
w.DeleteEvent+=salir
w.ShowAll()
Gtk.Application.Run()
Para ejecutar el ejemplo, pueden usar directamente el intérprete de Boo: 'booi ejemplo.boo', o si no puede compilarse: 'booc ejemplo.boo', lo que genera un ejecutable de .NET, 'ejemplo.exe'
Un ejemplo de sesión es:
Como se ve, es similar a Python usando pygtk, pero a mi juicio bastante más simple.
~/devel/dotnet/boo/ejemplos$ booc example.boo
~/devel/dotnet/boo/ejemplos$ ./example.exe
Hola
Chao!
~/devel/dotnet/boo/ejemplos$
El mismo código en Python sería así:
import gtk
from gtk import *
def pres(o):
print "Hola"
def salir(a,b):
print "Chao!"
gtk.main_quit()
w = Window()
w.set_title("Ejemplo")
b = Button("Presioname")
w.add(b)
w.set_border_width(10)
b.connect('clicked',pres)
w.connect('delete_event',salir)
w.show_all()
gtk.main()
Además del hecho de que prefiero BorderWidth=10 a set_border_width(10), Boo tiene muchas otras cosas que me gustan:
- Tiene verificación de tipos, con inferencia de tipos para evitar declaraciones innecesarias. Sin embargo, si se quiere, se pueden utilizar variables sin tipo para cosas específicas.
- Utiliza "early binding", esto significa que las llamadas a los métodos se buscan en tiempo de compilación (y luego durante el JIT), no durante la ejecución. Esto sólo es posible gracias a lo primero.
- Al compilarse a código CIL, utiliza la misma tecnología de JIT que la implementación de .NET en que se ejecute, lo que lo hace un lenguaje rápido.
Por último, existe ya un plugin para desarrollar en Boo usando MonoDevelop, lo que significa que el depurador integrado, la sugerencia de código y la generación de plantillas funciona. Y más encima, el código generado es multi-plataforma (si se usa gtk#, obviamente).
Si alguien quiere ayuda para instalar en Linux, usando Mono, pregunten.
miércoles, febrero 23, 2005
Rescate de Sistema
Uf!
La semana pasada me topé con uno de esos problemas que hacen odiar el hardware.
A continuación, la (larga) historia:
Preliminares
Como buen seguidor de Debian, tengo sid instalado en mi casa. Pero no tengo internet, por lo que actualizo cada un par de días copiando los nuevos paquetes en un disco ZIP, que llevo desde la pega.
Tengo un PC ya más bien viejo, un Duron de 600MHz, placa PC-Chips barata. Y tengo actualmente instalado un núcleo 2.6.10-ac4, que instalé para probar. Disco de 80Gb, con la partición de Debian (root+home) de 20Gb sobre reiserfs, más otras particiones para archivos multimedia grandes.
Dia 1
Bueno, como decía antes, la semana pasada estaba copiando desde el ZIP USB al disco local y el USB se quedó pegado. Como mi mouse también es USB y está en el mismo HUB, me quedé sin mouse. Y la luz del ZIP quedó encendida.
Un 'dmesg' mostró que no había mayores problemas, por lo que decidí simplemente desconectar el ZIP y ver que pasaba. Y no pasó nada, seguia encendida la luz.
Así que decidí desconectar el HUB entero. En ese momento, el PC entero se quedó pegado, ya no funcionaba el teclado. Así que reinicié.
Ahora comenzaron los problemas. El sistema no hacía nada. Grub decía que no podía cargar la segunda etapa desde el sistema de archivos. Y por lo tanto, quedaba pegado. Y ya eran las 21:30...
"Buscaré un disco de rescate". Ups, no encuentré nada muy actual... un montón de discos de Debian, pero ninguno booteable. Unos discos de woody, con kernel 2.4.18 fue lo más nuevo que encontré.
Luego de bootear, la partición no montaba, el núcleo alegaba. Y en el CD no hay herramientas para revisar particiones reiserfs (astuta idea instalar todo en una partición reiserfs).
Finalmente, recordé que en el disco duro antiguo, que todavía tengo instalado en el PC, instalé Fedora Core 2 para probarlo, tiempo atrás.
Booteando desde el CD de woody, monté la partición de Fedora, un chroot y luego grub-install hicieron posible bootear de ese disco como secundario.
Una vez dentro de Fedora, busco los programas de reiserfs... ¡no están!
Pienso un rato... ¿de donde saco los reiserfsprogs?... Afortunadamente, tenía varios CD's con paquetes Debian (cada cierto tiempo los grabo con las actualizaciones para mi PC). Y encontré en uno de ellos el paquete de Debian reiserfsprogs, el que descomprimí utilizando el viejo método infalible: ar+gunzip+tar.
Finalmente tenía mi caja de herramientas completa. Ahora, proceder a ejecutar 'reiserfsck' en la partición muerta.
Bueno, no se ve muy bien. "Error en el superbloque principal" y otros similares (obviamente no recuerdo bien todos los mensajes), pero la verificación se llevó a cabo.
Luego de unos minutos, el programa termina diciendo amablemente que se encontraron errores que solo se repararán con la opción "--rebuid-tree", osea reconstruir el árbol completo desde cero. Y la documentación advierte hacer primero un respaldo de la partición antes de usar dicha opción. Complicado hacer un respaldo de 20Gb si ni siquiera puedo acceder a los datos dentro.
Como no tenía otra opción, aplique rebuid-tree. Y comenzó diciendo que demoraría 6000 segundos en terminar, verificando 4 millones de bloques. Afortunadamente demoró bastante menos (como media hora).
Además, para agregar un poco de emoción al asunto, por error maté el proceso antes de que terminara, por lo que tuve que empezar de cero...
Finalizada la reconstrucción del árbol, reiserfsck declara que encontró unos 40 directorios perdidos, con muchos archivos dentro...
Al montar la partición (todavía desde Fedora), veo que en realidad no tengo directorio raíz, esta todo en 'lost+founds'. Ahora sé por qué grub no encontraba su famosa segunda etapa. Que gracioso...
Afortunadamente, identificar los directorios más importantes, como 'usr', 'var' y 'etc' dentro de lost+founds fue bastante sencillo. Y luego de unos minutos el directorio raíz ya parecía una raíz de Linux. Claro que dentro de 'lost+founds' quedaban bastantes cosas sin identificar.
Probé hacer un chroot hacia el directorio recién poblado, pero fue imposible. Aprendí que el enlazador dinámico ('ld.so') de Debian es incompatible con el núcleo de Fedora Core 2 (problemas con "excec shield" por lo visto). Eso hace difícil ejecutar grub.
Luego de un par de rebooteos más, finalmente logré bootear hacia mi instalación de Debian. Ahora, a verificar las firmas de los paquetes para ver que cosas es necesario reinstalar. Eran como 100 (de unos 1500) paquetes con problemas.
Eso fue el día 1. Finalmente, casi a las dos de la madrugada terminé (soy bueno para quedarme pegado en el PC).
Dia 2
Al día siguiente en la pega grabé dos discos con todos los paquetes que cupieron de Debian, desde una lista de lo que tenía instalado en mi PC. Me pareció mejor así, para tener un respaldo de lo que estaba instalado.
Al llegar a mi casa, re-instalé todo lo que tuviera cambios con respecto a los md5sum's guardados.
Y luego hice un respaldo (siempre es bueno) de mi home, utilizando 'dar', que encuentro la herramienta ideal para respaldos en CD's. Cupo en tres discos.
Pero al realizar el respaldo surgieron problemas: varios archivos de mi home tenían tamaños gigantes, de varios gigas (eran archivos con hoyos, por lo que un simple 'du' no lo notaba). Procedí a borrar varios archivos,
mientras que otros tuvieron arreglo simplemente cortando la cola.
Epílogo
Antes de ayer volví a tener problemas. Algunos de los archivos gigantes, al borrarse, dieron errores que no tome en cuenta mayormente.
Pues el Lunes, al bootear mi PC, expresó que la partición tenía errores irreparables y era necesario un nuevo "--rebuid-tree". Afortunadamente no quedó nada malo luego de terminar (esta vez no encontró muchos archivos perdidos).
Espero que la cosa mejore, ya estoy pensando un cambio de sistema de archivos (me tinca probar ahora XFS), pero eso demorará un buen tiempo, por lo que esperaré un mejor momento.
¡Ah, lo olvidaba!. En el intertanto, grabé un CD de rescate con todas las herramientas necesarias. Encontré en internet un mini-cd llamado "RIP" (rescue is possible), basado en kernel 2.6.10 y con todos los chiches para rescate. Lo modifique agregando 'dar', además cambié el lynx por links, comprimí la documentación para que consumiera un poco menos de memoria y agregué un script de 'zless'.
La gracia de RIP es que utiliza sólo ramdisk, no necesita que el CD esté insertado para funcionar, por lo que puede usarse para rescatar desde CD aunque tenga un solo CD-ROM, o grabar CD's, etc.
La semana pasada me topé con uno de esos problemas que hacen odiar el hardware.
A continuación, la (larga) historia:
Preliminares
Como buen seguidor de Debian, tengo sid instalado en mi casa. Pero no tengo internet, por lo que actualizo cada un par de días copiando los nuevos paquetes en un disco ZIP, que llevo desde la pega.
Tengo un PC ya más bien viejo, un Duron de 600MHz, placa PC-Chips barata. Y tengo actualmente instalado un núcleo 2.6.10-ac4, que instalé para probar. Disco de 80Gb, con la partición de Debian (root+home) de 20Gb sobre reiserfs, más otras particiones para archivos multimedia grandes.
Dia 1
Bueno, como decía antes, la semana pasada estaba copiando desde el ZIP USB al disco local y el USB se quedó pegado. Como mi mouse también es USB y está en el mismo HUB, me quedé sin mouse. Y la luz del ZIP quedó encendida.
Un 'dmesg' mostró que no había mayores problemas, por lo que decidí simplemente desconectar el ZIP y ver que pasaba. Y no pasó nada, seguia encendida la luz.
Así que decidí desconectar el HUB entero. En ese momento, el PC entero se quedó pegado, ya no funcionaba el teclado. Así que reinicié.
Ahora comenzaron los problemas. El sistema no hacía nada. Grub decía que no podía cargar la segunda etapa desde el sistema de archivos. Y por lo tanto, quedaba pegado. Y ya eran las 21:30...
"Buscaré un disco de rescate". Ups, no encuentré nada muy actual... un montón de discos de Debian, pero ninguno booteable. Unos discos de woody, con kernel 2.4.18 fue lo más nuevo que encontré.
Luego de bootear, la partición no montaba, el núcleo alegaba. Y en el CD no hay herramientas para revisar particiones reiserfs (astuta idea instalar todo en una partición reiserfs).
Finalmente, recordé que en el disco duro antiguo, que todavía tengo instalado en el PC, instalé Fedora Core 2 para probarlo, tiempo atrás.
Booteando desde el CD de woody, monté la partición de Fedora, un chroot y luego grub-install hicieron posible bootear de ese disco como secundario.
Una vez dentro de Fedora, busco los programas de reiserfs... ¡no están!
Pienso un rato... ¿de donde saco los reiserfsprogs?... Afortunadamente, tenía varios CD's con paquetes Debian (cada cierto tiempo los grabo con las actualizaciones para mi PC). Y encontré en uno de ellos el paquete de Debian reiserfsprogs, el que descomprimí utilizando el viejo método infalible: ar+gunzip+tar.
Finalmente tenía mi caja de herramientas completa. Ahora, proceder a ejecutar 'reiserfsck' en la partición muerta.
Bueno, no se ve muy bien. "Error en el superbloque principal" y otros similares (obviamente no recuerdo bien todos los mensajes), pero la verificación se llevó a cabo.
Luego de unos minutos, el programa termina diciendo amablemente que se encontraron errores que solo se repararán con la opción "--rebuid-tree", osea reconstruir el árbol completo desde cero. Y la documentación advierte hacer primero un respaldo de la partición antes de usar dicha opción. Complicado hacer un respaldo de 20Gb si ni siquiera puedo acceder a los datos dentro.
Como no tenía otra opción, aplique rebuid-tree. Y comenzó diciendo que demoraría 6000 segundos en terminar, verificando 4 millones de bloques. Afortunadamente demoró bastante menos (como media hora).
Además, para agregar un poco de emoción al asunto, por error maté el proceso antes de que terminara, por lo que tuve que empezar de cero...
Finalizada la reconstrucción del árbol, reiserfsck declara que encontró unos 40 directorios perdidos, con muchos archivos dentro...
Al montar la partición (todavía desde Fedora), veo que en realidad no tengo directorio raíz, esta todo en 'lost+founds'. Ahora sé por qué grub no encontraba su famosa segunda etapa. Que gracioso...
Afortunadamente, identificar los directorios más importantes, como 'usr', 'var' y 'etc' dentro de lost+founds fue bastante sencillo. Y luego de unos minutos el directorio raíz ya parecía una raíz de Linux. Claro que dentro de 'lost+founds' quedaban bastantes cosas sin identificar.
Probé hacer un chroot hacia el directorio recién poblado, pero fue imposible. Aprendí que el enlazador dinámico ('ld.so') de Debian es incompatible con el núcleo de Fedora Core 2 (problemas con "excec shield" por lo visto). Eso hace difícil ejecutar grub.
Luego de un par de rebooteos más, finalmente logré bootear hacia mi instalación de Debian. Ahora, a verificar las firmas de los paquetes para ver que cosas es necesario reinstalar. Eran como 100 (de unos 1500) paquetes con problemas.
Eso fue el día 1. Finalmente, casi a las dos de la madrugada terminé (soy bueno para quedarme pegado en el PC).
Dia 2
Al día siguiente en la pega grabé dos discos con todos los paquetes que cupieron de Debian, desde una lista de lo que tenía instalado en mi PC. Me pareció mejor así, para tener un respaldo de lo que estaba instalado.
Al llegar a mi casa, re-instalé todo lo que tuviera cambios con respecto a los md5sum's guardados.
Y luego hice un respaldo (siempre es bueno) de mi home, utilizando 'dar', que encuentro la herramienta ideal para respaldos en CD's. Cupo en tres discos.
Pero al realizar el respaldo surgieron problemas: varios archivos de mi home tenían tamaños gigantes, de varios gigas (eran archivos con hoyos, por lo que un simple 'du' no lo notaba). Procedí a borrar varios archivos,
mientras que otros tuvieron arreglo simplemente cortando la cola.
Epílogo
Antes de ayer volví a tener problemas. Algunos de los archivos gigantes, al borrarse, dieron errores que no tome en cuenta mayormente.
Pues el Lunes, al bootear mi PC, expresó que la partición tenía errores irreparables y era necesario un nuevo "--rebuid-tree". Afortunadamente no quedó nada malo luego de terminar (esta vez no encontró muchos archivos perdidos).
Espero que la cosa mejore, ya estoy pensando un cambio de sistema de archivos (me tinca probar ahora XFS), pero eso demorará un buen tiempo, por lo que esperaré un mejor momento.
¡Ah, lo olvidaba!. En el intertanto, grabé un CD de rescate con todas las herramientas necesarias. Encontré en internet un mini-cd llamado "RIP" (rescue is possible), basado en kernel 2.6.10 y con todos los chiches para rescate. Lo modifique agregando 'dar', además cambié el lynx por links, comprimí la documentación para que consumiera un poco menos de memoria y agregué un script de 'zless'.
La gracia de RIP es que utiliza sólo ramdisk, no necesita que el CD esté insertado para funcionar, por lo que puede usarse para rescatar desde CD aunque tenga un solo CD-ROM, o grabar CD's, etc.
