Mapas

Siempre me han gustado los mapas de los juegos de rol. Los mapas antiguos, en general. Esos en los que todo está dibujado a mano. Pero dada mi falta de herramientas y talento, nunca intenté hacer nada parecido.

Hace unos meses me compré una tableta gráfica Bamboo Fun (6x8 pulgadas). Coincidió con el descubrimiento de l foro de Cartographers Guild. Y me animé a probar.

Les ahorraré mis primeros intentos. Estoy acabando el primero que me atrevo a enseñar, Praathamika:

Si pinchan ahí, saldrá la imagen "grande": 3000x3000, casi 1MB de jpeg. Hay una versión en PNG (3MB) que pueden descargar pinchando aquí.

Los nombres son ridículos (y uno tiene un bug; se ve bastante claro si se fijan, un error con Inkscape), hay muchas incongruencias climáticas (por ejemplo, que no haya un polo norte de hielo marino) y la calidad artística ... bueno ... eche o que hai. Pero estoy muy contento del resultado. Estoy bastante animado, y haré más de éstos con lo que aprendí (sobre todo, por todos los errores que cometí).

Espero que les guste.

Cantautoras pop anglosajonas

Últimamente estoy descubriendo mucha música nueva gracias a last.fm. Soy un orgulloso suscriptor de pago: 3€ al mes me parece poco para todo el beneficio que obtengo.

Hay canciones que me parecen muy buenas, y que parece mentira que nadie más las conozca. Casi todas canciones pertenece al género que yo llamaría "cantautoras pop anglosajonas": chicas más bien jóvenes, que hacen canciones pop sobre amores y desdichas, tocan la guitarra o el piano, y son británicas o americanas. Es un poco embarazoso reconocerlo, porque mis amigos me tienen por heavy. Pero algún día había que salir del armario (musical).

También estoy escuchando el Devil without a cause de Kid Rock (famoso por la canción Bawitdaba y por haber estado casado con Pamela Anderson), el God has a plan for us all de Angtoria y Back into your system de Saliva. No piensen que me he echado a perder del todo.

En resumen: que aquí les pongo una lista de canciones que he escuchado recientemente, de artistas no conocidos aquí (que yo sepa; a lo mejor sí que lo son y soy yo el despistado), y que merecen la pena, con enlace a video en Youtube o similar. El orden es arbitrario, según me voy acordando.

  • Nerina Pallot, Alien (video)
  • A Fine Frenzy, Rangers (video)
  • Sara Bareilles, One sweet love (sólo audio); aunque conocerán más otra, Love song (video)
  • Michelle Branch, Find your way back (sólo audio)
  • Charlotte Martin, Limits of our love (sólo audio)

Sólo cinco, para que no tengan excusa y puedan escucharlas sin perder mucho tiempo. Espero acertar y descubrirles algo nuevo que les guste. Que es de lo que va la vida, al final.

OpenBSD

Vamos a dejar claras algunas cosas sobre OpenBSD:

  • El instalador es de chiste. Me hace gracia que la gente se quejase hace unos años de que instalar Debian era difícil. Comparar aquello con el instalador actual de OpenBSD es como comparar un BMW serie 5 con un Dacia Logan: los dos te llevan al mismo sitio, pero en uno vas un poco más cómodo que en el otro.
  • Es lento. No tengo benchmarks, pero si se creen lo que dicen de Gentoo (que por compilar toda la distribución va más rápida) sin que haya habido nunca un estudio serio que lo apoye, pueden creerse esto también. Supongo que tanto código de auditoría es lo que tiene. Aparte, el sistema de ficheros viene por defecto en modo síncrono. Es más seguro, pero tiene un precio.
  • La gestión de paquetes es inexistente. Tienes pkg_add y derivados, pero lo que instala (con sus dependencias y todo, eso sí) es un tar.gz glorificado. La otra opción es instalar desde fuentes, que todo el mundo sabe que es la mar de cómodo. Es buena idea tener un compilador instalado en un firewall, para que luego si te lo hackean puedan compilarse los exploits nativamente sin tener que bajárselos ya compilados desde algún sitio. Seguro que van mucho más rápido.
  • Soporte de dispositivos. No hay competencia. Aunque entiendo que ahí pasa como al comparar Linux con Windows: si no hay soporte de los propios fabricantes, es difícil. Pero hay que tenerlo en cuenta también.

Ahora bien: dicho todo esto, el sistema de firewalling es muy bueno (y no es otra ironía, lo digo completamente en serio). Ya había oído que la sintaxis de pf era mucho mejor que la de iptables, pero como uno es un poco talibán de lo suyo y se está convirtiendo en un carcamal reaccionario con el paso de los años, no le había prestado mucha atención.

Tengo nuevo ordenador desde hace unas semanas, y no quería "ensuciar" la instalación de escritorio con muchos programas "de servidor" que usaba para mantener una pequeña infraestructura de máquinas virtuales para pruebas: squid, dnsmasq, enmascaramiento con iptables (vean mi entrada anterior sobre Firestarter y FWBuilder), etc. Lo que hice fue crear una máquina virtual que hace todas esas cosas, conectada por un lado a la red "externa" (la que recibe IPs por DHCP desde el router de Internet) y por otro a una red interna en la que cuelgo las máquinas virtuales. Podría haberle puesto Linux, como a todas las demás, pero como soy un friki le puse OpenBSD.

La parte de configurar los "repositorios" de paquetes, instalar dnsmasq y squid y configurarlos para que arranquen con el inicio del sistema ya hizo saltar algunas de mis fobias anti-BSD. El sistema de arranque, en concreto: yo siempre he sido más de SysV, con su directorio init.d y sus miles de scripts de control de servicios; el sistema BSD de "el gran script arrancador" me parece un atavismo informático. Pero funciona, y tampoco iba a pegarme tanto con esto como para quejarme.

La parte del firewall me llevó algo más, por desconocimiento de cómo "hablar firewallés" con OpenBSD. Y fue un agradable descubrimiento. Ejemplos a continuación.

Esto es lo que quería hacer: dada una red interna (la 10.0.0.0/8) configurada en el interfaz "interno" (em1) de la máquina, en la que van a estar las máquinas virtuales, debía permitirse el paso de todo el tráfico desde esa red y enmascararlo con la IP del interfaz "externo" (em0). Con iptables serían dos reglas (suponiendo eth0 y eth1):

iptables -A FORWARD -i eth1 -s 10.0.0.0/8 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/8 -j MASQUERADE

Lo primero que se puede hacer en OpenBSD con pf y que no se puede hacer con iptables es algo tan básico como definir grupos. Por ejemplo, éste con las redes internas:

localnets = "{ 10.0.0.0/8 }"

Que podría ampliar a más redes, incluyéndolas en la misma variable. No vean la de bucles for que he hecho yo con iptables porque no tiene una cosa así. Ridículo. Hay algo llamado ipset que lo implementa, pero claro, no está en la versión "oficial". Y eso implica parchear y mantener algo distinto a lo que viene con la distribución. Que va a ser que no.

Hacer lo que quería con pf sería:

pass in on em1 from { $localnets } to any
nat on em1 from { $localnets } to any -> em0

Me rasca un poco eso del "->" para indicar la dirección IP con la que se va a hacer NAT (en este caso, la que sea que tenga el interfaz em0). Admitámoslo como una extravagancia más de OpenBSD.

Son dos líneas, exactamente igual que con iptables. Pero les reto a presentarles las dos versiones a alguien que no sepa nada ni de iptables ni de pf, y que diga cuál de las dos prefiere. La versión de OpenBSD es mucho más fácil de ver, y hace lo mismo, que es lo importante. Si un día tengo ganas y tiempo, a lo mejor intento crear la configuración de un firewall complicado que tenga ahora con iptables usando pf. Sólo por ver si la diferencia se hace todavía más grande o se mitiga un poco. Una cosa que no sé si se puede hacer en pf, por ejemplo, son cadenas de usuario para agrupar las reglas. A lo mejor metiéndose más a fondo descubro que no, y otras limitaciones que no son visibles a simple vista.

No voy a pasarme a OpenBSD, ni nada parecido. Sólo me gustaría que alguien portara pf a Linux, o hiciera un front-end tipo pf para iptables. Parece que la siguiente generación de los firewall en Linux, nftables, será más parecida a pf. Pero por lo poquísimo que he visto, parece más bien algo más complicado. Sería cambiar una cosa difícil por otra igual de difícil, que no es mucho progreso.

Aalguien debería mandarle un CD de OpenBSD a la gente de netfilter para que pensara en ello.

Firewalls personales para Linux

Hoy he desinstalado firestarter. Me hacen falta ciertas reglas de iptables las máquinas virtuales que uso para pruebas, y pensé que con firestarter podría hacerlo sin tener que editar ficheros en línea de comandos. No quería algo tan serio como lo que hago a diario en el trabajo. Quería algo sencillo, relajado, aunque no fuera muy seguro. Al fin y al cabo, es para mi ordenador de escritorio, que ya está detrás de un router/firewall.

Firestarter es muy fácil de usar, pero nunca acabó de funcionar bien del todo. Había permitido que los equipos conectados al interfaz br0 (en el que están las máquinas virtuales) salieran a Internet, pero no funcionaba DHCP. Lo permití desde cualquier sitio y cualquier interfaz, y seguía sin funcionar. Luego descubrí que una VPN que tengo con el ordenador que alberga esta web tampoco funcionaba. Permití todo el tráfico desde la red de la VPN, y seguía sin funcionar. Veía muchos paquetes ICMP rechazados desde sitios que monitorizo con smokeping para ver la salud de la red (extraño, porque era yo quien iniciaba los pings). Permití todos los ICMP ... y seguía sin funcionar.

Hoy he estado buscando alternativas. Hace mucho tiempo había llegado a tres "finalistas": firestarter, otro para KDE que ni recuerdo, y fwbuilder. El problema con el de KDE es que no uso KDE, y el problema con fwbuilder es que, para lo que yo quiero, es demasiado potente. Está muy bien, pero es demasiado para algo tan sencillo como lo que yo quería. Para que se hagan una idea, antes de usar firestarter era un fichero en /etc/init.d con tres o cuatro líneas llamando a iptables.

Pensé en ufw, pero lo descarté porque sólo vale para el propio equipo. Para hacer enmascaramientos y cosas "avanzadas" necesitas hacer algo de magia negra. No hay mucha diferencia entre eso y mis scripts.

Viendo que no hay más remedio, he instalado fwbuilder.

Cosas que no me gustan de fwbuilder:

  • Como ya dije, es demasiado complicado para lo que yo quiero. Necesitas saber de firewalls para usarlo. A mí me da igual, pero no lo recomendaría a alguien que quiere un "firewall de escritorio" típico. Sólo la configuración de un "objeto firewall" ya es bastante liosa si no sabes qué estás haciendo.
  • Necesita entrar por ssh como root en el firewall (localhost, en mi caso) para actualizar las reglas, o con un usuario que por sudo pueda escribir donde las tienes.
  • Es un servicio del sistema. Es decir: no hay un icono en la bandeja del sistema en el que pinchas y puedes cambiar cosas, activar o desactivar el firewall, y todo eso. Tienes que tirar de terminal para hacerlo.
  • Por lo anterior, la instalación requiere que toques cosas en el sistema si quieres que funcione "bien": tienes que configurar un usuario que pueda levantar el firewall con sudo, crear un directorio para las reglas e instalar un script init.d y un fichero en /etc/default que vienen en los ejemplos (no se hace por defecto porque puedes tener el firewall en otro sitio que no sea donde editas las reglas).
  • Mi configuración de fwbuilder tiene cuatro reglas en fitler y una en nat. Para hacerlo, entre media hora y 45 minutos, sobre todo definiendo interfaces y hosts. Soy un poco maniático y estuve buceando entre las opciones de fwbuilder para ver qué podían hacer, pero quitando ese tiempo tardaría un mínimo de 15 minutos en haber configurado mis cuatro reglas.

    Luego hay que añadir otros cinco minutos cuando descubrí que la comunicación desde las máquinas virtuales a Internet funcionaba muy bien, pero no así desde el equipo que hace de firewall. Cuando vi que Google no respondía empecé a sospechar que faltaba afinar un poco el firewall.

    Una vez hecho, no hay mucho más que tocar. Voy a tener durante un tiempo fwbuilder a ver qué resultado da. Me temo que implique volver a lanzar un terminal para activar el firewall cada vez que reinicie (que, por suerte, no es muy a menudo), pero de momento lo asumo. En unas semanas veré si acabo harto y vuelvo a alguna solución más user friendly.

Linux es fácil

Tanto como extirparse un cálculo renal con una cucharilla de postre. Usando los pies.

Sí, estoy un poco mosqueado.

Desde la actualización de Ubuntu "Jaunty" a "Karmic" tenía varios "problemillas". El primero, que no funcionaba el dongle USB Wifi, con lo que no tenía Internet. El segundo, que no funcionaba el sonido. Nada importante, como ven. Lo normal en una actualización entre distribuciones (presuntamente) estables. Para que luego digan de Debian.

El problema de la Wifi lo solucioné cambiando de dongle (por suerte, tenía dos distintos). El problema del sonido lo arreglé tocando la configuración de pulseaudio tras una furiosa búsqueda en Google y Launchpad. pulseaudio es como un supositorio: sabes que a largo plazo será bueno para ti, pero el mal rato que vas a pasar mientras te lo ponen no te lo quita nadie. Ahora mismo hay mucha gente a la que le da problemas, pero es una arquitectura superior que permite mucho más de lo que permitían los servidores de sonido actuales. Todas las distribuciones lo han adoptado, y a pesar de lo que parece, en general funciona bien.

Pero lo dicho: un supositorio.

El cambio que tuve que hacer en la configuración de pulseaudio fue mínimo: descomentar una línea y ya está. Pero para alguien que se acabe de instalar Ubuntu no sería tan fácil. Tendría que bucear entre los bugs de Ubuntu, saber qué es ALSA, saber qué es pulseaudio ... No sería fácil. En absoluto.

Y lo de hoy fue la guinda. Me di cuenta de que no me funcionaba la entrada de línea. Ahí es donde enchufo la salida del multiefectos de la guitarra, con lo que si no hay entrada de línea, no hay sonido de guitarra. Pensé que sería cuestión de jugar un poco con alsamixer, como otras veces que he actualizado el kernel. Pero no: a pesar de que los volúmenes estaban bien, y de que en el monitor de pulseaudio se veía que había sonido en la entrada de línea, no se oía nada de lo que entraba por ahí.

La primera búsqueda de Google me llevó a probar a indicar un parámetro model para el módulo snd-hda-intel, según esta lista. Ya lo había probado hacía tiempo cuando tuve otros problemas con la tarjeta de sonido, y aunque entonces lo arregló, ahora no hubo suerte. De hecho, el problema que tenía entonces era el mismo que el de ahora, y un par de búsquedas más me hicieron recordar qué era lo que había tenido que hacer: activar el analog loopback de la tarjeta, uno de los "switches" de alsamixer.

Que no aparecía por ningún lado.

Seguí buscando y vi que a otra gente le había pasado lo mismo: el control de analog loopback había desaparecido. En ese bug se indicaba una entrada del changelog de ALSA en el que se decía que, como daba muchos problemas, lo habían quitado por defecto. Ahora se podía activar con el hint "loopback = yes".

Por supuesto, ni idea de a qué se refería con lo de "hint", ni cómo aplicarlo.

En el bug no lo explicaban. Siempre se agradece que te digan parte de la solución a tu problema para que puedas probarte a ti mismo encontrando el resto. Eso curte. Crea carácter. Distingue a los hombres de los niños. Si yo estuviera probando Ubuntu, al llegar aquí hubiera tirado el ratón por la ventana en un ataque de frustración y hubiera instalado Windows.

Media hora y varias búsquedas en Google más tarde, encontré un documento llamado "More notes on HD-Audio driver" que está en los fuentes de ALSA. Este pequeño fichero de 16 páginas de amena documentación técnica, en texto plano, es lo que cualquier usuario medio podría leer y comprender en un momento para hacer troubleshooting de sus problemas de sonido. Si "usuario medio" implica varios años de experiencia con Linux, claro.

En la sección "HD-Audio Reconfiguration" explica que el módulo snd-hda-intel se puede reconfigurar en caliente usando los ficheros de /sys. En este punto es necesario incluir el texto original, para gozarlo en toda su gloria:

The following sysfs
files are available under each codec-hwdep device directory (e.g. 
/sys/class/sound/hwC0D0):

vendor_id::
  Shows the 32bit codec vendor-id hex number.  You can change the
  vendor-id value by writing to this file.
subsystem_id::
  Shows the 32bit codec subsystem-id hex number.  You can change the
  subsystem-id value by writing to this file.
revision_id::
  Shows the 32bit codec revision-id hex number.  You can change the
  revision-id value by writing to this file.
afg::
  Shows the AFG ID.  This is read-only.
mfg::
  Shows the MFG ID.  This is read-only.
name::
  Shows the codec name string.  Can be changed by writing to this
  file.
modelname::
  Shows the currently set `model` option.  Can be changed by writing
  to this file.
init_verbs::
  The extra verbs to execute at initialization.  You can add a verb by
  writing to this file.  Pass three numbers: nid, verb and parameter
  (separated with a space).
hints::
  Shows / stores hint strings for codec parsers for any use.
  Its format is `key = value`.  For example, passing `hp_detect = yes`
  to IDT/STAC codec parser will result in the disablement of the
  headphone detection.
init_pin_configs::
  Shows the initial pin default config values set by BIOS.
driver_pin_configs::
  Shows the pin default values set by the codec parser explicitly.
  This doesn't show all pin values but only the changed values by
  the parser.  That is, if the parser doesn't change the pin default
  config values by itself, this will contain nothing.
user_pin_configs::
  Shows the pin default config values to override the BIOS setup.
  Writing this (with two numbers, NID and value) appends the new
  value.  The given will be used instead of the initial BIOS value at
  the next reconfiguration time.  Note that this config will override
  even the driver pin configs, too.
reconfig::
  Triggers the codec re-configuration.  When any value is written to
  this file, the driver re-initialize and parses the codec tree
  again.  All the changes done by the sysfs entries above are taken
  into account.
clear::
  Resets the codec, removes the mixer elements and PCM stuff of the
  specified codec, and clear all init verbs and hints.

Pero ahí estaba: el fichero hints, que es a lo que se referían en el changelog. Supuse entonces que lo que había que hacer era añadir loopback = yes a ese fichero, tal que así:

echo "loopback = yes" > /sys/class/sound/hwC0D0/hints

Y luego, reconfigurar la tarjeta:

echo 1 > /sys/class/sound/hwC0D0/reconfig

Con eso ya aparecía el control de analog loopback en alsamixer, y ya funcionaba el sonido de la entrada de línea.

¡Jo, qué fácil era!

Si es que al final uno se da cuenta de que no es que Linux sea difícil: es sólo que no se ha parado a buscar durante hora y media entre bugs, posts de foros y documentación técnica. Cualquiera podría hacerlo.

Creo que éste tampoco será el año de Linux en el escritorio.

PS: y por encima, un bot me ha llenado de spam varias de las entradas del weblog. Ya ni del capcha se puede fiar uno.

Syndicate content