Problemas con Ubuntu: El disco duro tiene Muchos Sectores Erroneos

Ayer llegó a mis manos un dell inspiron 1545 en su cajita recién despachado. Venía con win 7  home.

Después de revisar que el hardware fuera el que correspodía al solicitado y revisar que todo funcionara bien con el win7 de fábrica; procedí a formatear e instalar ubuntu 9.10 karmic koala.

Lo primero que me apareció fue: -”El disco duro tiene Muchos Sectores Erroneos” en rojo. Un fsck desde el live cd, corrigió un error de no haber montado adecuadamente. Ahora, Cada vez que inicio los supestos sectores dañados aumentan, primero 52, luego 82… pero hay un problema: el disco no tiene errores, está nuevo; fsck dijjo que no habían y otras distros que probé dicen lo mismo.

Paseando por la red después de que casi me diera un ataque cardiaco, descubrí que es muy probable que sea un bug.

Debo admitir que este es lejos uno de los bugs más molestos que he experimentado con ubuntu (¡y por monesvol que he experimentado muchos!). Esperaré unos días por la solución, si no logro encontrar una… tal vez…win7.

Similar:

http://www.soloubuntu.com/2009/10/problemas-con-ubuntu-el-disco-duro.html

El bug en cuestión:

https://bugs.launchpad.net/ubuntu/+source/libatasmart/+bug/438136

Spaz en ubuntu64 jaunty

Si spaz se instala pero no aparece ninguna ventana al ejecutarlo; pruebe en la consola:

GTK_PATH=/usr/lib32/gtk-2.0 /opt/Spaz/bin/Spaz

Por lo menos a mí me ha funcionado ok así.

Arreglando el bug de amsn de conexión.

Resumo las entradas anteriores: – Las versiones que están en los repositorios de ubuntu 9.04 rc de tcl y tk provocan que amsn no se pueda conectar si se usan carácteres extraños (tildes, gatos) en la contraseña.

Para arreglarlo:

-Bajarse las última versión de tcl y tk. Descomprimirlas:

$tar xzf tcl8.5.x-src.tar.gz
$tar xzf tk8.5.x-src.tar.gz

- Compilarlas e instalarlas:

 $cd tcl/unix
 $./configure --prefix=/usr/local --includedir=/usr/local/include/tcl8.5 --enable-shared --enable-threads --enable-64bit \
  --mandir=/usr/local/share/man --enable-man-symlinks --enable-man-compression=gzip && make CFLAGS="-g -O2 -D_REENTRANT"
 $sudo make install
 $cd ../..
 $cd tcl/unix
 $./configure --prefix=/usr/local --includedir=/usr/local/include/tcl8.5 --enable-shared --enable-threads --enable-64bit \
 $ --mandir=/usr/local/share/man --enable-man-symlinks --enable-man-compression=gzip && make CFLAGS="-g -O2 -D_REENTRANT"
 $sudo make install

Bajarse el último amsn, descomprimirlo, compilarlo e instalarlo:

$wget http://amsn.sf.net/amsn_dev.tar.gz
$tar xzvf amsn_dev.tar.gzcd
$cd amsn/amsn*
$./configure --with-tcl=/usr/local/lib --with-tk=/usr/local/lib
$make
$sudo make install

Hasta aquí debería funcionar con simplemente un:

$amsn

, si no funciona y arroja una ventana de error tkxpixmap o algo así, hay que:

$sudo mv /usr/bin/wish /usr/bin/wish_backup
$sudo ln -s /usr/bin/wish /usr/bin/wish8.5

Y con esto debería funcionar.

Amsn, bug de conexión tcl tk.

Siguiendo con la entrada anterior, me propuse crear un pequeño cliente de msn similar al messenger de micro$oft pero que -a diferencia de emesene, amsn y kmess- funcione de verdad.

En eso estaba, conociendo la API de msn para java cuando me topé con un amigo en el pidgin (único cliente de amsn que funciona seriamente), quien, conociendo mi dilema me dijo: “¿Y por qué no ayudas en el amsn?”.

Así, después de gruñir un poco por la idea de meterme en un proyecto desarrollado en un lenguaje que no manejo -casi nada- (python) terminé por aceptar que siempre es mejor cooperar en un proyecto ya formado que empezar uno nuevo.

Y luego de unas cuantas horas de búsqueda encontré la falla, no era ningún cambio de protocolo ni nada por el estilo. El problema radica en las librerias tcl y tk. Resulta que si el amsn se compila desde las fuentes usando tcl8.4 y tk.8.4 y luego se ejecuta usando wish8.4 (o wish por defecto o simplemente como “amsn”), corre sin problemas y conecta ok, pero se ve extremadamente horrible (por culpa de  las versiones 8.4 de tcl y tk que no soportan antialiasing).

En cambio, sí amsn se compila con tcl8.5, tk8.5 y se ejecuta con wish8.5, se ve muchísimo mejor pero deja de ser capaz de conectarse sí es que la contraseña posee carácteres raros; que es lo que a mí me interesa pues me es totalmente inútil un cliente de mensajería incapaz de conectarse (y no voy a cambiar mi contraseña si eso significa hacerla insegura).

Acto seguido entré a la página de amsn. Allí traté de colocar un nuevo post en su foro pero, como era de esperarse, había que registrarse. Pero para registrarse habia que conocer la respuesta a la pregunta secreta antispam de su formulario de registro, que estaba escondida en algún lugar de las reglas (era chocolate), y había que tipear letras de una imagen (clásico antispam) que, ho, sorpresa, no funciona pues hay que adivinar si un palito es una “l” o una “i”, pero como no soy ningún Chris Angel, no pude adivinar y me dijo: “You have exceeded the number of registration attempts for this session. Please try again later“. O sea que como no soy psíquico no tengo derecho a una cuenta en ese foro y me quedé sin poder registrarme para informar del bug. Ahora bien, si alguien tiene una cuenta en el foro de amsn y puede avisar sería muy útil, sobretodo para que no vengan con la farsa esa de que el cliente no conecta por que micro$oft cambió el protocolo (aunque una una vez haya sido verdad).

opera portable y facebook.

Pues, la última versión de opera portable a la fecha, se cae si tratan de usar el cargador simple de fotos de facebook… Empiezo a sospechar que el problema más que en los navegadores, está en el propio facebook

(no, no es tan obvio como parece).

Chrome y facebook.

Alrededor de diez minutos y ya le encontré una pifia al chrome: El botón “publicar” de facebook no funciona.

Veamos cuanto tardan en arreglarlo.