Archivo

Archivo para noviembre, 2006

Drivers Nvidia 9629 + Beryl – XGL = Más mejoras

miércoles, 8 de noviembre de 2006 Sin comentarios

Hola gente, por fin salieron nuevos drivers de Nvidia para Linux/BSD/Solaris!!! (en su versión estable, claro).

Son los primeros de la serie 9xxx, los cuales permiten que en mi Edgy vuele de un plumazo a XGL con el fin de ejecutar Beryl… Ahora sólo ejecuto X.org 7.1.1 + Beryl.

Es decir, antes: X.org + XGL + Beryl. (Drivers Nvidia 8xxx)

Problema Principal: OpenGL, XVideo y otras extensiones que renderizaban directamente en la memoria de video (por decirlo sencillo, alguien que aclare acá!) no era directo, sí o sí pasaba por el server XGL.

Consecuencias: Lentitud en cualquier cosa que utilice esas operaciones, como ser juegos o reproductores de video. El smooth scrolling en firefox (ignoro por qué era lento antes).

Ventajas: Efectos 3D en el escritorio! Cubos girando, zoom, exposé y varias cosas bonitas.

Ahora: X.org 7 + Beryl. (Drivers Nvidia 9xxx). Al estar estos drivers preparados para soportar las operaciones de un window manager como Beryl directamente, no hace falta XGL, por lo tanto no hace falta un servidor X (XGL) que haga llamadas OpenGL a otro (X.org). Directamente Beryl hace llamadas a X.org.

Menos Componentes = Más velocidad. Y con más facilidades, como por ejemplo OpenGL renderizando con aceleración directa! (sin trucos, Doom 3 y Quake 4!)

Acá hay una captura de un momento glorioso: OpenGL + Composite + Beryl.

Sí, se comía la CPU (como pueden ver en el sensor de carga de CPU), pero era el glxgears, ya que probé el Tux Racer y el Super Tux (juegos que usan OpenGL) y apenas la CPU llegaba al 40% en los dos casos, corriendo Metacity y Beryl.

Instalación
Desde cero es algo largo, pero partiendo de una instalación de XGL + Beryl es relativamente simple (aunque depende de qué howto hayan seguido). Básicamente, fue:

1 – Bajar los nuevos drivers de NVidia. Usé estos repositorios, que preguntando al mantenedor me dijo que «me quede tranquilo», que cuando Ubuntu actualice el kernel él iba a actualizar los paquetes. 😀

2 – Probar que todo funcionara como antes (por las dudas). O sea, si quería podía seguir usando XGL.

3 – Cambiar la configuración de GDM para que no arranque el XGL, sino que cargue X.org. Sólo fue modificar el /etc/gdm/gdm.conf-custom (comentando las 3 líneas que había puesto, bah). Lo dejé como cuando vino del CD de instalación de Ubuntu. ;-D

4 – Agregar una opción al /etc/X11/xorg.conf (como se explica acá).

5 – Listo. Arrancar la sesión de mi usuario y probar…

Bueh, es todo lo que me acuerdo; estuve jugando bastante y el sistema está más liviando; aunque me gustaría que en la nueva versión de Beryl (0.1.2, yo todavía estoy corriendo 0.1.1), se corrijan varios errores muy visibles, y se optimice el funcionamiento en general (tiene algunos cuellos de botella todavía).

Taluego
Marcelo

Categories: codear, linux, tests, ubuntu-ar Tags:

Nueva Versión de TabMixPlus!

lunes, 6 de noviembre de 2006 Sin comentarios

Mi plugin preferido para Firefox de manejo de pestañas por fin fue actualizado para soportar la versión 2.0 de Firefox!

Trae un par de novedades, pero lo más importante es que ya tengo las funcionalidades extra de la versión anterior. 😀

Screenshot:

Acá se puede ver la opción de dejar a Firefox manejar las restauración de sesiones.

Links:
Página en addons.mozilla.org
Página del proyecto

Salu2
PD: Les dejo un link con muchísimas extensiones para Firefox, pero categorizadas.

Categories: codear, web Tags:

Tu /dev/parport0 no existe? (Ubuntu 6.10)

lunes, 6 de noviembre de 2006 1 comentario

Buiinas…

Hoy, queriendo imprimir dentro de una máquina virtual de VMWare con un Windows XP (no pregunten por qué semejante masoquismo! [1]), sobre mi flamante Ubuntu 6.10 Edgy, me encuentro que VMWare no puede usar«/dev/parport0».

«Ja!» Pensé, porque sabía que VMWare no puede utilizar el puerto paralelo mientras CUPS está corriendo y mientras el módulo ‘lp’ está cargado. Entonces hice «sudo /etc/init.d/cupsys stop» y «sudo rmmod lp» para detener el servicio de impresión y el módulo de impresión respectivamente. Después de eso, volví a arrancar el VMWare. Pero ahora el mensaje cambió, y ahora VMWare decía que «/dev/parport0 no existe»… «Eh? – Ahora sí que no sé qué pasa».

Como esto sí funcionaba sobre Dapper, googlié por algún tipo de problema al respecto, y encontré esto:

http://www.murrayc.com/blog/permalink/2005/12/24/wheres-my-parport0/
http://linux.wordpress.com/2006/05/29/running-vmware-workstation-55-on-suse-101/

Y el más definitivo bug:
https://launchpad.net/distros/ubuntu/+source/gnome-cups-manager/+bug/29050

Evidentemente, en algunos casos, parece que aunque uno tenga conectada una impresora de puerto paralelo, Ubuntu 6.10 no crea el archivo que representa ese puerto («/dev/parport0»). Simplemente lo solucioné haciendo un «sudo modprobe ppdev» primero para verificar que VMWare encontraba el puerto paralelo. Y como pude imprimir desde la máquina virtual, agregué la línea «ppdev» (sin comillas) a mi /etc/modules, con el comando «sudo gedit /etc/modules«.

Listo, VMWare puede encontrar mi puerto paralelo.

[1] Cualquier trámite que quieran hacer varias entidades del Estado Argentino (AFIP, Rentas de Buenos Aires…) requiere un aplicativo llamado SIAP, que está hecho con *puaj* VB6+Jet DB, mejor conocido como Access *puaj* y lamentablemente disponible sólo para plataformas Windows.

Saludos
Marcelo

Categories: codear, linux, ubuntu-ar Tags:

Ojo con los Proxys Transparentes de los ISPs

viernes, 3 de noviembre de 2006 1 comentario

Actualización (21/11/2007): Buanzo en su blog aporta un método mejor para evitar esto que describo en este post, cambiando la configuración del apt.

Holas, este post es para comentar algo que me pasa de vez en cuando y que me pone los pelos de punta: los proxys transparentes de los ISPs (Speedy en mi caso). Resulta que como comenté anteriormente, hace poco me actualicé a Ubuntu 6.10 y en estos últimos días salieron algunos parches de seguridad (estoy suscripto a la lista de USN – Ubuntu Security News).

Pero no importa lo que hiciera, siempre tenía este error al hacer apt-get update:

root@marcelo-desktop:/usr/bin# apt-get update
[...]
Des:10 http://archive.ubuntu.com edgy-proposed Release [19,6kB]
Ign http://archive.ubuntu.com edgy-proposed Release
Obj http://archive.ubuntu.com edgy-proposed/main Packages
Obj http://archive.ubuntu.com edgy-proposed/restricted Packages
Obj http://archive.ubuntu.com edgy-proposed/universe Packages
Obj http://archive.ubuntu.com edgy-proposed/multiverse Packages
Descargados 33,9kB en 5s (6588B/s)
Imposible obtener http://security.ubuntu.com/ubuntu/dists/edgy-security/main/
binary-amd64/Packages.bz2  La suma MD5 difiere
Leyendo lista de paquetes... Hecho
W: GPG error: http://archive.ubuntu.com edgy-proposed Release: Las siguientes
firmas fueron inválidas: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key 
W: Tal vez quiera ejecutar 'apt-get update' para corregir estos problemas
E: Algunos archivos de índice no se han podido descargar, se han ignorado,
o se ha utilizado unos antiguos en su lugar.
root@marcelo-desktop:/usr/bin#

– ¿Y esto? – me pregunté. Al principio tenía sólo el problema de «la suma MD5 difiere». Después de seguir intentando (dejé pasar un par de días), se me agregó el tema de que no concordaba la clave pública del repositorio edgy-proposed.

Googlié (así se dice? 😛 ), revolví («apt-get install –reinstall ubuntu-keyring») y nada… hasta que recordé que una vez estuve 2 días esperando que la caché del Proxy Transparente de Speedy se «vaciara» («flusheara», en mi jerga) para que me muestre actualizados los cambios que estuve haciendo en una página web que estaba desarrollando en ese momento.

Cómo detecte (en ese momento) el problema? Fácil: Acá entran los amigos de uno en juego. Resulta que tenía uno con Arnet, otro con Fibertel y otro con Speedy. Yo había modificado la página, vacié mil veces la caché del navegador, y seguía viendo la página «vieja». Les pedí ayuda a mis amigos, y los de Arnet y Fibertel veían perfectamente las modificaciones que yo había subido hacía minutos… pero mi amigo de Speedy no! (y eso que era la primera vez que él entraba a verla, así que no había caché de navegador que valiese).

Lo que pasaba era que el Proxy (transparente, porque yo no tengo que configurar un proxy en mi conexión para navegar) de mi ISP no me estaba «caducando» («venciendo») del caché la página, entonces no consultaba el server original y me devolvía una versión «vieja» de la página, desde su almacenamiento local.

Esperé un par de días hasta que la página «caducara» en el Proxy (totalmente fuera de mi control, claro), y magia: solita se actualizó (y eso que probé con los encabezados http para hacerla vencer… pero nada, se ve que el proxy que están utilizando debe tener algún problema, ni idea)…

Bueh, recordando este inconveniente que me sucedió hace un tiempo, me dije: «no será un problema del proxy de Speedy que me está mandando una versión corrupta de los índices de los repositorios?» Entonces, para «burlar» cualquier proxy (y en este caso, el de Speedy), se debe usar otro proxy, je.

Fue tanto como googlear por proxys anónimos (hay bots que escanean la red en busca de proxys mal configurado, sin autenticación, libres de uso) y encontré una página con Proxys catalogados por país (tercer link de Google, je). (Ojo, puede que dentro de un tiempo no sirvan…)

Entonces fue tanto como probar al azar las IPs de la lista; uno no me contestaba, el otro me daba 111 – Conexión rehusada, hasta que encontré uno que empezó a bajar los índices del repo de Ubuntu:

Intento 1:

root@marcelo-desktop:/usr/bin# export http_proxy=http://201.37.117.34:8080
root@marcelo-desktop:/usr/bin# apt-get update
0% [Conectando a 201.37.117.34 (201.37.117.34)] [Conectando a 201.37.117.34
(201.37.117.34)] [Conectando a 201.37.117.34 (201.37.117.34)] [...]

Intento 2:

root@marcelo-desktop:/usr/bin# export http_proxy=http://201.21.222.112:6588
root@marcelo-desktop:/usr/bin# apt-get update
Err http://www.kubuntu.org edgy Release.gpg
No pude conectarme a 201.21.222.112:6588 (201.21.222.112). -
connect (111 Conexión rechazada)
Err http://espergreen.com edgy Release.gpg
[...]

Intento 3:

root@marcelo-desktop:/usr/bin# export http_proxy=http://200.19.159.35:3128
root@marcelo-desktop:/usr/bin# apt-get update
Des:1 http://www.kubuntu.org edgy Release.gpg [189B]                                                                                      
Des:2 http://archive.canonical.com edgy-commercial Release.gpg [191B]                                                                     
Des:3 http://security.ubuntu.com edgy-security Release.gpg [191B]                                                                         
Des:4 http://www.amd64.aceracerftw.com edgy Release.gpg [189B]
[...]
Obj http://archive.ubuntu.com edgy-proposed/multiverse Packages
Descargados 26,1kB en 1m35s (273B/s)
Leyendo lista de paquetes... Hecho
root@marcelo-desktop:/usr/bin#

¡Joya! Como el destino de la conexión era otra IP distinta de la de los repositorios de Ubuntu, el Proxy de Speedy sí o sí tenía que conectarse a esa IP «desconocida» (que al ser otro proxy me comunicaba con los repos de Ubuntu!). De esta manera, obligo a que no use lo que tiene en su caché.

root@marcelo-desktop:/usr/bin# apt-get upgrade
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias   
Leyendo información de estado... Hecho
Se actualizarán los siguientes paquetes:
imagemagick irb1.8 libimlib2 libmagick++9c2a libmagick9 libpq4
libreadline-ruby1.8 libruby1.8 libwv-1.2-1
linux-restricted-modules-2.6.17-10-generic
linux-restricted-modules-common nvidia-glx rdoc1.8 ri1.8
ruby1.8 ruby1.8-dev screen wv
18 actualizados, 0 se instalarán, 0 para eliminar y 0 no actualizados.
Necesito descargar 21,4MB de archivos.
Se liberarán 20,5kB después de desempaquetar.
¿Desea continuar [S/n]?

Magia!! 😀

Todos (o casi todos) los comandos de consola que utilizan el protocolo HTTP utilizan la variable de entorno «http_proxy» para usar proxy en su conexión (aunque podría haber usado el archivo /etc/apt/apt.conf, pero es otra historia). Así fui cambiando de IP de proxy probable hasta que uno me contestó. Y como ven, no me dió ningún error de MD5 que no concuerda, ni de clave pública errónea. Pude burlar al proxy de Speedy! 😀

(Y actualizar mi Ubuntito también, je) 😀

Ojo, que igual era necesario sólo para el ‘update’. Al fin y al cabo, bajar los paquetes por medio de un proxy taarda muucho. Al final, una vez que por el proxy bajé los índices y no me dió error, hice un «export http_proxy=» (sin nada), para volver a la conexión directa y bajar los paquetes sin proxys en el medio.

Así que ya saben: si tienen problemas de refresco/actualización de recursos en la web, chequeen de esta manera. Obviamente es mucho más lento (e inseguro también, ya que podemos sufrir un MITM Attack) usar un proxy de un tercero que de forma directa, pero… prefiero correr el riesgo y actualizar mi Ubuntu. Después de todo, los paquetes del repo de Ubuntu vienen firmados.

Buenas noches!
Marcelo

Categories: codear, linux Tags: