Algo de humor para comenzar el nuevo curso.

Esperemos que poco a poco el soporte de drivers a linux mejore por parte de todos los fabricantes de hardware, y que estas tiras cómicas pasen a formar parte del pasado.

Odio a broadcom.

Llevaba tiempo detras de un netbook. Estaba a la espera de encontrar uno que cumpliera dos requisitos fundamentales:

• Salida HDMI.
• Resolución de pantalla de 1280x768 (la minima requerida por DPP para funcionar)

Y por fin, el pasado mes de Junio, paseando (cotilleando más bien) por un mediamark,  tope con este cacharro. Estaba expuesto como superoferta, es decir, al mismo precio que en redcoon, pero en este caso me ahorraba los gastos de envio, asi que no me lo pense y me lo lleve a casita.

Lo primero que hice, fue quitar la porqueria de Windows 7 starter que traia para poner un fabuloso Linux Slackware 13.37 de 64 bits, y un Windows 7 Enterprise. Primeros problemas con Windows 7, driver de la tarjeta wifi. Cuando vi que era broadcom me puse a temblar, no era nuestro primer encuentro. La primera vez fue con un portatil acer, localizar un driver que funcionase me costo unas 3 horitas, ya que el driver de la web de acer no funcionaba, y por supuesto en la web de broadcom no habia nada. La historia se repetia, sin drivers en la web del portatil ni en la del fabricante de la tarjeta wifi. Baje muchos de webs de hp, acer... etc, nada, no tiraba ninguno. Al final consegui uno tras 2 horitas de nada, lo encontre aquí. Ya me imaginaba que en linux la cosa también estaria fea. Pero no, pese a que el último kernel disponible no soportaba la tarjeta, la fabulosa gente de linuxwireless.org ya daba soporte para dicha tarjeta.

http://linuxwireless.org/en/users/Drivers/b43

Siguiendo sus instrucciones de instalación no tuve ningún problema. Eso si, de momento no funciona en modo ad-hoc, solo managed, espero que cuando se incluya dentro del kernel en el futuro se solucione este problema.

Congelando al más astuto.

Vuelta de vacaciones. Sentimientos cruzados de alegría por volver a ver a los compañeros, y tristeza por el final del verano, un gran verano: curso en Valladolid, despedidas de soltero, bodas, y el gran Europe tour 2011 en el bandidito, a ver cuando pongo algunas fotillos en el flickr (tengo que filtrar de las 2800 que tengo).

Pero aqui estamos para hablar de cosas de informática, así que vamos a ello. Como cada año, por estas fechas toca formatear y preparar los equipos con todo el tinglado de linux, maquinas virtuales, italc... etc para finalmente clonarlos con drbl. Espero poder contar muchas cosillas del drbl en futuros post, es una pasada de live cd para clonacion de equipos. El caso es que hoy mirando que guardar de los equipos, me acorde de un pequeño shell script que me sirvió para neutralizar a los alumnos más rebeldes. Durante el pasado curso, dichos alumnos al sentirse muy oprimidos por el autoritario y abusivo uso de italc que les impedia jugar a thewest y similares superjuegos online, decidieron desconectar el cable de red para poder sentirse más libres jugando a sus juegos localmente (sin internet... pero libres). Ante tal despliegue de técnica, el italc no podía defenderse, asi que se me ocurrió escribir un pequeño script para ayudarle a seguir su dictadura.

El script es el siguiente:

ping -c 1 192.168.0.50 > /dev/null 2> /dev/null

if [ $? -eq 1 ]; then
     killall -s STOP X
else
     killall -s CONT X
fi


Teniendo en cuenta que el ordenador del profesor es la ip 192.168.0.50 dentro de la red local, este script lanza un ping, si el resultado es positivo le manda al servidor X (entorno gráfico) la señal de continuar, en caso contrario (cuando el alumno desconecta el cable), manda la señal de pausa a dicho proceso. Resultado, el ordenador se queda congelado, no funciona ni tan siquiera el teclado para matar las X. Si se vuelve a conectar el cable, cuando se vuelva a lanzar el script, el ordenador se descongelara al recibir el proceso X la señal de continuar.
Para que esto funcione, debemos añadir la ejecución del script al crond del sistema (comando crontab -e) para que se lance cada... digamos.... ¿20 segundos?. Aquí podemos poner el valor que queramos. Por ejemplo, con esta línea ejecutamos cada 2 minutos todos los scripts de la carpeta /etc/crond/cron.hourly que tengan permiso de ejecución.


*/2 * * * * /usr/bin/run-parts /etc/cron.hourly 1> /dev/null

Pegas de este invento: como el equipo del profe no arranque tendremos que montar algo a lo que se pueda hacer ping con esa ip para que los equipos funcionen.... y como se rompa el swicht tendremos problemas. Por ello, solo puse este script en los equipos necesarios.

Nvidia al horno.... mmmm, que rico¡¡

Hace unos meses que me comentaron un método curioso para reparar placas base. Algunos problemas en soldaduras pueden producir un mal funcionamiento del dispositivo, e introducir el componente en un horno a 200 ºC durante 10 minutos puede repararlo. Me sorprendió bastante, y buscando información al respecto por internet se leía de todo, pero vi que sobre todo se utilizaba para reparar un modelo de tarjeta gráfica Nvidia, y algunas videoconsolas ante ciertos errores genéricos.

En teoría, la soldadura de los componentes al PCB se realiza por un tipo de bolas de estaño denominadas BGA, y un exceso de calor continuado puede deteriorar la soldadura. Pero al igual que en algunas series, un personaje sufre amnesia por un golpe en la cabeza, y tras otro golpe similar recupera la memoria (aunque lo previsible y lo que sucedería en la realidad sería dejarle aún peor), en nuestro caso, un nuevo exceso de calor puede solucionarlo, y eso si que es una realidad, aunque en un principio parezca que lo unico que puede hacer es empeorar las cosas. Al ser un problema originado por un exceso de temperatura, no es de extrañar que las tarjetas gráficas sean uno de los componentes que más sufren este problema, debido a la gran cantidad de calor que generan y la escasa refrigeración que suelen tener, sobre todo en videoconsolas y portatiles.

Aún así me parecía raro, y yo quería probarlo. La primera prueba la hice con una placa base estropeada, que por supuesto no encajaba en el perfil que estaba buscando, y el experimento no sirvió de nada.

Hace un mes se me presento una nueva oportunidad, el portátil de un amigo con aceleradora Nvidia dejo de mostrar la imagen en el monitor, y tampoco funcionaba la salida vga, era lo que andaba esperando. Pero a mi amigo no le pareció gustar la idea de meter la placa al horno, además es de otra ciudad, por lo que lo llevo a arreglar... 180€ de nada sino recuerdo mal, seguro que por hacer lo mismo que quería hacer yo, y encima al mes le vuelve a fallar, menos mal que tenia garantía de 1 año en la reparación

Ayer, un alumno parecía tener un problema similar en su portátil, veía la imagen en 2/3 de la pantalla, y con lineas extrañas. El ya conocía el sistema del horno, y lo probo.... y funciono¡¡. Hoy el portátil funcionaba perfectamente. En el siguiente vídeo se ve como se realiza la operación en un portátil exactamente igual que el suyo, aunque el lo hizo introduciendo la placa completa en el horno a 200 ºC durante 10 minutos, el del vídeo es algo más radical, como tira con el soplete el tipo xD. 

Firefox 4.... ¿en Mozilla no tienen ingenieros del software?

Por fin salio la esperadisima nueva versión de Slackware, hemos tenido que esperar un año pero por fin tenemos la versión 13.37, en  32 y 64 bits, lejos quedan ya los dias de slamd64 x). Entre las principales novedades (sistema de archivos btrfs, archivos de configuración para instalación por pxe boot... etc, etc) trae el navegador firefox 4. Dejando a parte todas las mejoras de seguridad incluidas, no se por que esperaba que el cambio de idioma fuese ya normal, con un cuadro de dialogo dentro de las preferencias del navegador.... pero no, siguen igual ¿Donde queda la ingenieria del software y el analisis de requisitos, casos de uso... etc? me parece una opción bastante importante para que por la versión 4 sigamos asi. Pues el cambio sigue haciendose como describo en este post, y el archivo xpi lo podemos descargar de aqui.