Pablo Hoffman

Una interrogante que surge comúnmente a la hora de implementar un módulo de Linux es que mecanismo elegir para configurarlo. Desafortunadamente para algunos (y afortunadamente para otros) existen varias (quizás demasiadas) alternativas para ello. A continuación presento un resumen de ellas, junto con una comparativa.

Archivo de configuración

Si bien esta alternativa a veces resulta tentadora por su gran flexibilidad, no se recomienda (e incluso está muy mal visto) acceder a archivos desde el espacio del Kernel. Las razones son varias, pero la más importante es la dependencia que se crea entre el módulo y el filesystem (donde se alojaría el archivo de configuración) que es una objeto de más alto nivel y por lo tanto puede no estar disponible desde el espacio del Kernel (donde se ejecuta el módulo). Para una aplicación que corre en espacio de usuario, dicha limitación no es problema ya que el filesystem es un objeto de más bajo nivel y por lo tanto podemos asumir que siempre estará disponible como cualquier otro recurso básico (memoria, procesador).

Parámetros del módulo

Esta técnica consta en pasar la configuración del módulo a través de parámetros en el momento de cargarlo (ya sea con el comando insmod o modprobe). La ventaja de esta técnica es que es la forma más universal de configurar un módulo, y está disponible en cualquier versión de Linux. La desventaja es que carece de flexibilidad ya que solo puede utilizarse por única vez al cargar el módulo y para cambiar sus valores requiere que el módulo sea re-cargado (en realidad sysfs permite cambiar el valor de los parámetros en caliente, pero no tiene forma directa de notificar al módulo de los cambios). Para módulos que precisan una configuración mas flexible y dinámica (por ejemplo, agregar nuevas conexiones a un dispositivo de bloques clusterizado) esta alternativa resulta inviable.

ioctl

La llamada del sistema ioctl implementa un tipo de canal especial de control que permite enviar parámetros de configuración a los módulos y dispositivos activos del sistema. Este canal es independiente del canal (por defecto) de datos que es utilizado para transmitir información y trabajar regularmente con el dispositivo (por ejemplo, /dev/hda). Cada “mensaje” de ioctl consta, básicamente, de un comando y un argumento. Esta puede es una buena alternativa a utilizar para configurar módulos que requieran de configuraciones dinámicas, y tiene la ventaja de que es un mecanismo muy estandarizado puesto que existe desde los albores de Linux y es una llamada del sistema (ioctl(2)) disponible en todos los sistemas POSIX. Sin embargo, en Linux, ioctl está considerado medio obsoleto puesto que existen nuevos mecanismos más modernos que brindan la misma funcionalidad de forma más "prolija". Esto es debido a que para usar ioctl exige el conocimiento del protocolo y las funciones soportadas por el dispositivo que es algo que cambia completamente de dispositivo en dispositivo y no existe ninguna estándarización adecuada.

procfs

Procfs es un sistema de archivos (generalmente montado en /proc) diseñado para acceder a información sobre los procesos que corren en el sistema. Permite tanto acceder como modificar información del funcionamiento del sistema a través de unos archivos virtuales que pueden ser leídos (o escritos) con tales fines. Esta característica (única en su momento) hizo que procfs adoptara una gran popularidad a lo largo del tiempo y (por una razón de conveniencia) su funcionalidad se extendiera a otros usos como la configuración y consulta de módulos y otros parámetros del Kernel. Desde hace ya un tiempo, los desarrolladores del Kernel se han visto preocupados y molestos frente a la degeneración del uso de procfs y para combatirlo decidieron incorporar un nuevo filesystem: sysfs.

sysfs

Sysfs es un sistema de archivos incorporado en el Kernel 2.6 y diseñando para poder acceder (de forma coherente y prolija) a información de los módulos, dispositivos y otros subsistemas activos del Kernel . Fue incorporado con la idea de corregir el uso incorrecto que se le estaba dando a procfs. Sysfs consiste de un sistema de archivos virtual similar a procfc, pero con la diferencia de que está pensado para acceder a información de los objetos del Kernel (dispositivos, buses, módulos, etc), mientras que procfs está pensado únicamente para acceder a información de procesos (de ahí su nombre). Sysfs también especifica una forma estándar de acceder a la información de los objetos del Kernel (ver la documentación de kobject). Sysfs (al igual que procfs) también permite modificar sus archivos logrando así cambiar la configuración del módulo o sistema que se esté configurando. Sysfs pareciera ser, a primera vista, la alternativa ideal para realizar la configuración de un módulo. Sin embargo, la historia no termina ahi, ya que sysfs fue diseñado para obtener información de los dispositivos, no para configurarlos.

configfs

Finalmente, tenemos Configfs es un nuevo sistema de archivos virtual (recientemente incorporado al Kernel) análogo a sysfs y procfs, pero diseñado específicamente para configurar y administrar módulos y dispositivos. La gran diferencia con sysfs es que permite la creación de nuevos objetos del Kernel a través de la llamada del sistema mkdir(2) lo cual brinda una gran flexibilidad a la hora de configurar un módulo en tiempo de ejecución. Además, los archivos de configfs pueden existir de forma independiente del dispositivo, mientras que en sysfs los archivos siempre existen dentro del contexto del dispositivo y por lo tanto el módulo debe estar cargado previamente, cuando en realidad el objetivo de la configuración es proveerle al módulo la información necesaria para cargarse. Haciéndo una analogía con el espacio de usuario, podemos observar que los archivos de configuración existen (en el filesystem) independiente de que sus aplicaciones estén corriendo o no.

Configfs recién fue incorporado en la versión 2.6.16 y aún es un "bicho raro". Muchos todavía lo ven como un capricho de los desarrolladores del Kernel, que no supieron conformarse con sysfs. Otros lo ven como lo que es: una forma de hacer lo mismo, pero de manera más prolija. Si bien la compatibilidad y la estabilidad (siendo un sistema nuevo) le juegan en contra, configfs ha sido muy bien recibido por la comunidad del Kernel, lo cual le augura un muy buen futuro.

Esta es una lista de las aplicaciones que más uso actualmente, ordenada aproximadamente por tiempo de uso. Pensaba dar un estimativo del tiempo que dedico a cada una, pero opté por no hacerlo ya que es algo muy variable, y además no tengo ni idea :).

También aclaro sobre que plataforma las utilizo.

Un par de aclaraciones:

• Algunas aplicaciones que uso frecuentemente (como iCal y Addressbook) quedaron afuera por el poco tiempo real que dedico a usarlas.
• Firefox quedó fuera de la lista por no considerarlo una aplicación sino más bien un entorno donde corren otras aplicaciones (las aplicaciones web). Sino también debería incluir los sistemas operativos. De haber sido listada, probablemente sería la primera.

El año que viene compilaré una nueva lista y veremos como cambia la cosa. Preveo la incorporación de alguna otra aplicación web, además de Google Reader.

Dos por tres surge la pregunta en algún foro o lista de correo:

¿Cómo verificar que un número de cédula uruguaya sea válido?

Vaya a saber quien lo inventó, o de donde salió el algoritmo para generar el dígito de verificación. De cualquier forma, aquí les dejo un script para generar números de cédula de identidad uruguayas (incluyendo el dígito de verificación) que puede ser adaptado fácilmente para usarlo como verificador de cédulas.

El script: cedula.py

Una de las primeras cosas que hice cuando tuve mi tarjeta de crédito internacional fue registrar mi dominio personal, y la principal razón por la que lo hice fue para tener mi propio email, independiente de cualquier proveedor de mails.

¿Por qué tener un email igual a mi nombre?. Varias razones: para que sea independiente de cualquier proveedor (Gmail, Yahoo, etc) y para que sea permanente (asumiendo que no voy a cambiar de nombre, claro está :)). Y así, una vez que tuve mi propio dominio, empecé a usar mi nuevo email personal hosting-free (libre de proveedores). En este momento, en particular, redirijo todo mi correo a Gmail porque me sirve (1. para leer los mensajes desde el celular y 2. como filtro de Spam) pero lo uso solo porque me conviene, no porque esté atado a Google. Actualmente Gmail es el servicio web de mail más poderoso y (para muchos) el único realmente usable. Pero mañana ¿quién sabe?, ¿seguirá siendo Gmail?. A mi realmente no me importa porque, cuando Gmail deje de servirme, simplemente cambio la redirección de mi casilla personal a un nuevo proveedor y listo, me olvido de Gmail. Asi nomás, de la noche a la mañana, como quien se cambia un par de zapatos. Esto me permite tener una dependencia nula con mi proveedor de mail. Y eso es una gran cosa, ya que el e-mail es, actualmente, uno de los mecanismos más fuertemente usados por los sitios para atar a los usuarios.

Afortunadamente, el email está regido por un protocolo abierto cuyo diseño permite este tipo de libertades, aunque mucha gente no las aproveche.

¿Pero que tiene que ver todo esto con autentificación?. Que, hoy en día, dicha libertad también existe en el terreno de la autentificación y su nombre es OpenID.

¿Quién mejor para probar tu identidad que tú mismo?. Ese es el concepto que está detrás de OpenID y (aunque suena un poco absurdo al principio) resulta completamente lógico, sobretodo en Internet donde uno se identifica por los sitios que posee (blogs, sitios personales, etc).

El funcionamiento es el siguiente: OpenID (que es un protocolo, no un sitio) define un mecanismo de autentificación que permite a un sitio X verificar la identidad de un navegante a través de otro sitio Y que dicho navegante utiliza para probar su identidad. Los sitios utilizados para probar la identidad son llamados Proveedores de Identidad, y son los únicos que "saben" la contraseña del usuario. En realidad el funcionamiento es algo más complejo, pero básicamente es eso. Los que estén familiarizados con Paypal observarán una gran similitud. La diferencia es que OpenID es un protocolo y no un sitio que centraliza las autentificaciones (como Paypal, que centraliza todos los pagos).

Esta separación permite varias cosas, entre ellas:

• tener un único usuario y contraseña para todos los sitios que visitas en Internet (blogs, foros, etc)
• liberar a los sitios que brindan los servicios del trabajo de mantener la autentificación de sus usuarios, lo cual hace el sistema más seguro a nivel global (siempre y cuando el Proveedor de Identidad sea confiable, claro está)
• centralizar la seguridad y la confianza en un solo sitio (el Proveedor de Identidad) lo cual es un gran alivio para el usuario

Aunque, si bien esto permite independizarnos de las autentificaciones de los sitios, igualmente nos genera una dependencia (y mucho más fuerte) con nuestro Proveedor de Identidad. ¡Muy cierto!, pero aquí es donde viene la magia de OpenID. Y dicha magia se llama delegación. El protocolo OpenID permite delegar el Proveedor de Identidad que proveerá nuestra autentificación, lo cual nos permitirá cambiarlo a conveniencia, cuando nos plazca.

Veamos un ejemplo. Acabo de registrarme un usuario en un proveedor de identidad que me inspiró confianza (MyOpenID). Luego de registrarme ellos me dieron una URL (pablohoffman.myopenid.com) que sería mi "usuario OpenID". Es decir, cuando vaya a entrar a un sitio X (que soporta OpenID) tengo que loguearme con dicha URL (en lugar del usuario) y luego autentificarme (con mi contraseña) en mi proveedor de Identidad (MyOpenID). Finalmente, MyOpenID informará al sitio X que yo soy quien digo ser, y el sitio X me "dejará pasar".

Pero la gracia (y aquí viene la cereza de la torta) es que OpenID permite delegar las URLs de autentificación. Por lo tanto, yo voy a utilizar la URL http://pablohoffman.com como usuario OpenID y luego la delegaré a la URL del Proveedor de Identidad que esté usando (actualmente, pablohoffman.myopenid.com). Si en algún momento MyOpenID deja de ser santo de mi devoción, lo único que tengo que hacer es cambiar a otro que me inspire más confianza y actualizar mi OpenID (http://pablohoffman.com) para que "apunte" a la URL de mi nuevo proveedor. Asi de simple. Y no tengo que cambiar nada en todos los sitios de Internet, ya que para ellos voy a seguir siendo http://pablohoffman.com, como siempre. Maravilloso, ¿no?. Un protocolo libre en su máxima expresión. ¡Cero dependencia!.

OpenID es algo que Internet pedía a gritos hace tiempo, un protocolo de autentificación verdaderamente libre (como no podía ser de otra manera).

Estoy seguro de que está aquí para quedarse ya que, por más intereses económicos que tenga en contra, el sistema simplemente es demasiado bueno como para no triunfar. Seguramente aparecerán sitios comerciales que te cobren por brindarte la identificación y lo respalden con su prestigio (similar a como funciona la web segura hoy en día). De hecho, la "provisión de identidad" como servicio de Internet es algo nuevo. También habrán universidades que identifiquen a sus alumnos, empresas que identifiquen a sus empleados y, por supuesto, siempre habremos los que nos gustará autoidentificarnos con nuestro propio sitio (porque no confiamos en nadie :)). Pero el concepto y la filosofía detrás de OpenID no cambia.

¡Larga vida a OpenID!

Nota: Este artículo tiene fines únicamente divulgativos. No pretende ser exhaustivo o técnico. Pueden encontrar más información sobre OpenID en los siguientes enlances:

• Wikipedia (español)
• Sitio oficial (inglés)
• OpenID enabled (inglés)

Parece que el gobierno uruguayo está negociando cual será el estándar que adoptará para la televisión digital y las opciones (mutuamente excluyentes) son: Isdb-T (estándar japonés), DVB (estándar europeo) y Atsc (estándar estadounidense).

Ahora, digo yo: ¿no es un poco tarde para adoptar un estándar de televisión digital (cuya adopción llevará de 5 a 10 años y exigirá el cambio de todos los televisores) cuando el futuro de la televisión ciertamente está definido, y no precisamente por la televisión digital, sino por la televisión por Internet?. Me refiero, obviamente, a los sitios de videos online, categoría que actualmente es liderada por Youtube y Google Video, pero que realmente no importa quien la lidere dentro de unos años, mientras se establezca un estándar común.

Seguramente los fabricantes de televisores (ansiosos por vender) discreparan conmigo, pero creo que es un error adoptar en estos momentos un estándar para una tecnología que bien puede considerarse en vías de quedar obsoleta, sin haber llegado siquiera a su pico de adopción. Iniciativas como la de Adinet TV me parecen mucho más sensatas.

Un país con bajos recursos como el nuestro no debería involucrarse en la adopción de un estándar de tal magnitud sino saltearse una generación y esperar a incursionar en la nueva era de la televisión: la televisión por Internet, que claramente se viene con todo y probablemente dejará obsoleta a la "televisión digital tradicional" mucho antes de lo esperado.

Claro, habrá gente que argumente que la televisión por Internet no tiene la calidad suficiente como para igualar a la televisión digital. Bueno, pues lo mismo dijeron en su momento sobre el formato MP3 y los CDs de audio, y ya ven como les fue... En la televisión (como en cualquier otro medio) la característica que predomina por excelencia es la accesibilidad, no la calidad. Sino pregúntense por que tienen tanta fama las descargas ilegales de películas si su calidad es "tan mala" comparada con la de un DVD.

A modo de ejemplo, supongamos el siguiente caso: me acuerdo de un comercial de una cerveza que vi hace un tiempo, sobre un perro, y me gustaría volverlo a ver. ¡Pero lo quiero ver ahora!, no cuando a la televisión se le antoje pasarlo. Bueno, hoy en día no tengo más que entrar a Youtube y buscar "budweiser ad dog". Eso es accesibilidad.

Pero claro, cuando hay muchos intereses económicos de por medio, ninguna justificación, por más razonable que sea, es lo suficientemente válida.

Para los que todavía no sabían, a fines del año pasado ANTEL inauguró Adinet TV, un portal para ver televisión online que (según dicen) está ganando mucha popularidad entre los uruguayos que residen en el exterior. Por ahora solo hay dos canales disponibles: Televisión Nacional (aka. Canal 5) y Tevé Ciudad, pero ANTEL está dispuesto a prestar su ancho de banda a cualquier otro canal que manifieste interés (aunque desconozco bajo que términos).

ANTEL se manda muchas cagadas pero, cuando tiene una iniciativa buena como esta, hay que reconocerlo. Y hablando de buenas iniciativas, hoy aumentaron la velocidad de todos los ADSLs.

A primera vista, los que usamos Linux podemos sentirnos un poco intimidados por el mensaje "requiere Windows Media Player 9" pero no se preocupen que ya lo he probado y (como dicen nuestros amigos españoles) anda de puta madre!.

Primero que nada, deben registrarse en Adinet, para obtener una licencia para usar el sistema. La licencia viene en forma de una llave de 256 bits (32 caracteres) encriptada con un algún algoritmo de dos vías, ya que se desencriptada por el servidor de streaming para validar la autentificación. Si la licencia de Adinet TV no lo prohibiera, les pasaría el link completo que yo uso, ya que igual no podrían averiguar el usuario y clave a menos que conozcan el algoritmo y la clave de encriptación (y además, tampoco me importaría).

En fin, luego de registrarse encontrarán la llave en los links a los canales: son los 32 caracteres despues del "userID=" Una vez que tengan la llave solo tienen que instalar el VLC (apt-get install vlc, en ubuntu y derivados de debian) y correr los siguientes comandos (para TV Ciudad y Televisión Nacional respectivamente).

vlc "mms://stream1.antel.net.uy/broadcast/WM9_tvciudad?canalID=broadcast/WM9_tvciudad&userID=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
vlc "mms://stream1.antel.net.uy/broadcast/WM9_tnacional?canalID=broadcast/WM9_tvciudad&userID=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"

Sustituyendo siempre las 32 X por su llave personal. También funciona con mplayer pero (a mi, al menos) me anda a los saltos. Parece un problema del codec, pero quizás ya este solucionado en la última versión.

mplayer "mms://stream1.antel.net.uy/broadcast/WM9_tvciudad?canalID=broadcast/WM9_tvciudad&userID=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
mplayer "mms://stream1.antel.net.uy/broadcast/WM9_tnacional?canalID=broadcast/WM9_tvciudad&userID=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"

Esos links probablemente no sean permanentes así que, si llegan a esta página dentro de un tiempo, quizás no funcionen, pero lo que quería transmitirles es que Adinet TV se puede usar sin problemas desde Linux.

This is a pretty simple PHP script that allows you to access your (OpenVPN-based) VPN status (such as connected hosts, received/transferred bytes, etc) through a web page. It fetches the information using OpenVPN management console and displays it in a web-friendly way.

Installation is straightforward:

1. Download the script (see link below), rename it, and place it in a web accessible location. Example:

/var/www/vpnstatus.php

1. Enable OpenVPN management console (if you haven't already done so) adding the following line to the OpenVPN configuration file:

management localhost 7505

1. Restart OpenVPN

That's it!. Just access http://yourhost/vpnstatus.php to see your VPN status in a web-friendly way.

This instructions assume you'll place the script on the same machine running OpenVPN. Otherwise, you'll have to edit the script and modifiy it accordingly (changing the localhost to the name of your OpenVPN host) and also change the management option in your OpenVPN configuration to listen in other addresses.

Download the script here: vpnstatus.txt. Don't forget to rename it to a .php extension.

Hace unos días, leyendo una noticia sobre el desarrollo de un cerebro artificial, me llamó la atención el comentario sobre la posibilidad de obtener la inmortalidad a través de esta tecnología, puesto que da para cuestionarse varias cosas:

¿Cuál sería el mecanismo?. ¿Hacer "backups" periódicos de tu cerebro para (en caso de morir) poder restaurarlo en un "cuerpo virgen"?. Que sería exactamente un "cuerpo virgen"?. ¿Un cuerpo "criado" artificialmente con un cerebro en blanco?. ¿Acaso sería eso posible?. Y, suponiendo que lo fuera, un cuerpo adulto (con un cerebro vacío) no debería ser considerado un ser humano. De lo contrario, estaría amparado por los derechos humanos que prohibirían este procedimiento.

¿Que pasaría, por ejemplo, si se llegara a restaurar el cerebro de una persona en otra sin que la primera hubiese muerto?. Habría dos personas iguales, no necesariamente física, sino psicológica y mentalmente. Dos personas que comparten los mismos recuerdos, las mismas vivencias, las mismas pasiones. ¿Como te sentirías sabiendo que existe otra persona idéntica a vos?. ¿Se perdería el concepto metafísico de individuo?

Lindo tópico para un libro de sci-fi... Si alguien sabe de alguno sobre el tema, que avise.

Greg Kroah-Hartman no es la típica celebridad informática que todo el mundo conoce, sino más bien el gurú hacker que está detrás de muchas cosas pero cuyo nombre pasa desapercibido.

Mi primer contacto con Hartman fue hace unos años cuando leí su libro Linux Device Drivers (una auténtica "biblia" en la materia) y de un tiempo a esta parte me he venido topando muy seguido con su nombre por diversas razones (por destacar alguna de ellas, el primer DDK (kit de desarrollo de drivers) para Linux).

Otro de sus últimos aportes es la creación difusión de una comunidad de desarrollo de drivers para Linux. No es que sea algo innovador, ya que esa comunidad existió desde siempre (y en eso basa Linux su popularidad). Lo innovador es el enfoque "oficial" que le está dando, abordando temas como los acuerdos de confidencialidad (NDA, por si sigla en inglés), el sello "supported by linux", etc. Me parece una buena iniciativa que solo puede terminar bien. Linux tiene cada vez más peso a nivel de escritorio (ni que hablar de servidores) y las compañías ya no pueden darse el lujo de ignorarlo tan fácilmente.

Me gustaría aprovechar la oportunidad para ofrecerme localmente (en Uruguay, el país donde vivo) para el desarrollo de drivers Linux, aunque no creo que haya muchas empresas que lo demanden. Desgraciadamente, en Uruguay solo se hace software. ¡Que alguien me desmienta, por favor!

Luego de dos meses de desarrollo y un mes y medio de pruebas del NotiUY 2.0 me vengo a enterar que el sitio no funciona en Internet Explorer.

Es que últimamente estoy tan alejado de Windows y su apestoso browser que no me había percatado que el mundo seguía atado a Microsoft. Ya antes me había topado con problemas similares de compatibilidad, pero nunca el impacto que me causó fue tan alto. El único browser que no tengo a mano (ya que uso Linux y Mac) tenía que ser justo el único browser diferente a los demás, y también el más usado.

Ahora tengo que ponerme a perder horas de mi vida ajustando el CSS para que se vea en el IE, para que la mayoría de la gente pueda ver el sitio. Suena razonable, al fin y al cabo los pobres e inocentes usuarios no tienen la culpa, ¿o si?. Me remito a la frase bíblica "Perrdónalos señor, no saben lo que hacen", aunque sea ateo.

Bueh, ahora tengo dos opciones: meter hacks dentro del CSS para que el mismo archivo sirva para todos los browsers, o hacer un stylesheet separado para el IE. Yo prefiero la segunda opción ya que nunca me gustó eso de hackear los CSS (y en eso discrepo con Zeldman, aunque sus explicaciones sean muy elocuentes) puesto que no lo considero "compatible hacia adelante", lo cual es incluso peor que no ser compatible hacia atrás. Me refiero a que los hacks que hoy en día engañan a los browsers pueden perfectamente romperse en futuras versiones de los browsers que hoy funcionan bien. Asi que nada de CSS hacks para mi, gracias. A remangarse y hacer un CSS nuevo, por supuesto que bien sencillito y con el correspondiente mensaje exhortando a los usuarios a usar un navegador de verdad.

Por otro lado me puse a pensar... ¿vale la pena perder el tiempo con un browser que tiene más de 6 años y está pasando a ser obsoleto?. Pues no, probemos con el IE 7, seguro que ese ya funciona bien. ¡Pero no!. Aunque se ve un poco mejor, sigue viéndose horrible. Definitivamente, el Internet Explorer es un cáncer!. Espero que Internet se pueda liberar pronto de él, pero todos sabemos que el cáncer es difícil de curar. Por suerte, el antídoto viene en camino. :)

Una imágen vale más que mil palabras, asi que les dejo una comparación de como se ve el sitio en IE y otros browsers. ¡Encuentre las siete diferencias semejanzas!.

NotiUY 2.0 en Firefox, Opera, Safari, Konqueror,
Camino, Omniweb, et.al

NotiUY 2.0 en Internet Explorer 6