La FSF quiere implementar una librería que dé soporte al formato PDF. Otra más. No entiendo del todo este último movimiento de la FSF, programar otra librería más de soporte al formato PDF. La razón aducida para no reutilizar poppler (biblioteca base usada por Evince y oKular) estriba básicamente en que poppler está programado en C++ y la FSF quiere programar la librería en C (razones de portabilidad y facilidad de reutilización de la librería por otras aplicaciones GNU también programadas en C,dicen). Como ejemplo de problema de portabilidad indican que si no se hace en C, es difícil que la librería sea utilizada en dispositivos empotrados. Analizan también por qué no quieren reutilizar Ghostscript como base (demasiado orientada al soporte PS y complejo código para modificar). MuPDF tampoco les convence. Así que… van a crear otra librería más de soporte al formato PDF
Autor: diariolinux
Conky: EL monitor de sistema
Nuevo artículo de Basaburu, esta vez explicando el funcionamiento de Conky, un monitor de sistema con poco consumo de recursos:
«He decidido meterle mano al tema de la gestión y el ahorro de energia (en ello ando). Para lo cual me he metido con los kerenls en desarrollo, para vigilar un poco como andan las cosas necesitaba un monitor de sistema que fuera configurable. La elección lógica es Conky una pequeña maravilla, estoy encantado. Así que pretendo en este How To compartir la experiencia.
El site del proyecto: http://conky.sourceforge.net
Para empezar (ya sabéis que soy Debianero convencido)….
</p>
<h1>apt-get install conky</h1>
<p>
Sigue leyendo Conky: EL monitor de sistema
Web de HispaLinux 2007: ¿Fedora = Software Privativo?
¿No? Pues que me expliquen qué pinta ese mensaje de «Se ha detectado software privativo» y el logo de WinXP cuando entro con mi Firefox 2 y Fedora 6 en esa web. Adjunto pantallazo de LiveHTTP Headers con la captura de las cabeceras, por si alguien no se lo cree 😉 (por cierto, muy útil esa extensión…)
Por cierto, lo importante no es ese detalle, sino que os haya picado la curiosidad y acudáis al congreso 🙂
10 Millones de dólares en premios. ¿Participamos?
Eduroam en DELL Latitude D820 con Ubuntu Gutsy: CONECTADO!!!!!!
Actualización: 15/11/2007 Depende del sitio y la hora. No encuentro otra explicación al hecho de que a veces, conecto por Eduroam desde Gutsy (según dónde y a qué hora esté) y a veces no. Al menos, sé rápidamente cuándo voy a conectar: basta con dejar abierto el log /var/log/kern:
$ tail -f /var/log/kern
Si en algún momento veo la siguiente línea: ieee80211_crypt: registered algorithm ‘TKIP’
sé que voy a conectar. Otro problema radica en que cada X tiempo (pueden ser 2 minutos o 20), la conexión se pierde (SIN haberme movido del sitio!)
¿Por qué Linux carga el módulo ieee80211_crypt (en concreto, el algoritmo TKIP) sólo «a veces»? Eso es un misterio…
Varios meses después, por fin lo he conseguido. Escribo estas líneas conectado a Eduroam desde Ubuntu Gutsy con el DELL Latitude D820. Todavía no me lo creo, he estado mirando el cable de red, para asegurarme de que no estoy conectado por cable, varias veces 🙂
El «truco» 1 está aquí (tras varios meses, parece una chorrada, pero es el tornillo que hacía que el cohete no despegara … el caso es que éste cohete tiene miles y miles de ellos 😉
$ gconftool-2 --recursive-list /system/networking/wireless/networks/eduroam
Si tienes algo en esa rama: bórralo con recursive-unset. Además, ojito al parche, porque hay un bug reportado que indica que NetworkManager (n-m en adelante) guarda la contraseña en claro en esa rama de GConf. De hecho, gracias a ese bug me enteré de la existencia de esta rama en GConf.
El «truco» 2 consiste en NO usar NDISWRAPPER, que es el driver «envoltorio» de los drivers Windows que viene por defecto para la tarjeta Broadcom 4311. En concreto, mi tarjeta es:
$ lspci -v
0c:00.0 Network controller: Broadcom Corporation BCM94311MCG wlan mini-PCI (rev 01)
Subsystem: Dell Unknown device 0007
Los módulos que controlan mi tarjeta wifi son: juanan@pdi-laptop:~$ lsmod | egrep ‘(bcm|ieee)’ ieee80211_crypt_tkip 11776 0 bcm43xx 127336 0 ieee80211softmac 31360 1 bcm43xx ieee80211 35656 2 bcm43xx,ieee80211softmac ieee80211_crypt 7040 2 ieee80211_crypt_tkip,ieee80211 ieee1394 96312 2 sbp2,ohci1394
En concreto, estos son los paquetes que he instalado:
El «truco» 3 consiste en NO usar el certificado digital de la UPV. Es curioso, porque en Windows tampoco es necesario y sin embargo, no sé por qué, yo creía que sí. En fin…
El «truco» 4 consiste en USAR un kernel «modernito»:
juanan@pdi-laptop:~$ uname -a
Linux pdi-laptop 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux
El «truco 5» consiste en que la configuración del wpa_supplicant ha de estar en /etc/wpa_supplicant/wpa_supplicant.conf y NO en /etc/wpa_supplicant.conf .
Éste es el contenido de /etc/wpa_supplicant/wpa_supplicant.conf:
ctrl_interface=/var/run/wpa_supplicant
ap_scan=1
eapol_version=1
network={
ssid="eduroam"
proto=WPA
key_mgmt=WPA-EAP
group=CCMP TKIP
eap=TTLS
identity="scpxxxxx"
password="xxxxxxxxxx"
priority=2
phase2="auth=PAP"
}
Aunque realmente no sé si es totalmente necesario, dado que con meter los siguientes datos en la ventana de Network Manager, tal y como se puede ver en la siguiente imagen, ya vale:
Creo que no me dejo nada importante. Cualquiera que tenga problemas con esta tarjeta y esta red, que deje sus comentarios en este post, a ver si conseguimos que todo el mundo conecte sin problemas desde Ubuntu (u otra distro). En la UPV/EHU hay unos 500 portátiles DELL Latitude D820, así que, con que el 10% usen Linux (yo creo que sí, jejeje… optimista que es uno), al menos este mensaje debería de ayudar a 50 personas.