Planeta BSD

No es casualidad que comentara hace poco que han abierto milter.org, porque me acordé de esa web al recibir un correo de Sergey Shapovalov.

Resulta que Sergey está usando bogom en un entorno de pruebas con Solaris 10, antes de pasarlo a producción, y ha descubierto un problema bajo cierta carga (¡ha llegado a tener más de 600 hilos simultáneos!).

Parece que hay un problema con código de 32-bits y stdio con el número máximo de descritores de fichero, que está limitado a 256.

Es cierto que doy soporte (limitado) en Solaris 10, gracias a una cuenta que me hicieron Rubén y Mati en una de sus máquinas, pero bajo ciertas condiciones, y Sergey ha usado Sun Studio 12 (que no sé si trabaja con GCC, como yo recomiendo).

No veo porqué corren el milter como 32-bits, no recuerdo nada de eso en mis pruebas cuando porté el programa a Solaris.

En cualquier caso mis pruebas no fueron tan duras como las que ha hecho Sergey, y además la corrección que propone Sun no es nada traumática, así que este es el cambio principal de esta nueva versión.

Además he incluido una serie de pequeños cambios que he ido haciendo desde que publicara la versión anterior en Octubre del año pasado.

Me alegro que el programa le sea de utilidad a Sergey, y le agradezco el feedback (me mandó un parche). En mi opinión, esta es una de las satisfacciones de desarrollar Software Libre .

Leer el post completo »

Les ha costado, pero por fin han estrenado la nueva versión de milter.org (o al menos me entero hoy), como un catálogo de filtros milter para Sendmail.

Se pusieron en contacto conmigo hace más de un mes ya, con un correo muy formal, para participar en la beta privada del portal junto con otros desarrolladores. Fue gracioso aceptar un acuerdo con Sendmail Inc. para trabajar con ellos como partner .

La web no está mal, cumple su cometido, y yo ya di de alta mi filtro (bogom, del que he hablado por aquí).

La verdad es que cuando me puse a desarrollar el filtro para usar Bogofilter desde Sendmail eché de menos tener más documentación, o que estuviera más accesible, y eso lo han solucionado parcialmente. Además me sorprendía que el dominio milter.org perteneciera a un particular.

Lo feo es que iban a regalar una camiseta a los desarrolladores con el tema de la beta, y ahora parece que nadie sabe nada de eso. En mi opinión se arriesgan mucho: así pueden crearse enemigos que les duren de por vida .

Leer el post completo »

Hace ya algún tiempo comentaba diferencias entre SH (pdksh) y BASH, y hoy me he encontrado algo habitual cuando manejas directorios con muchos ficheros, o como me ha pasado a mi: liberando espacio de /tmp/.

Tenía gran cantidad de ficheros temporales, y otras cosas que no quería borrar, bueno… para eso están los patrones:

# rm /tmp/loquesea.*
-bash: /bin/rm: La lista de argumentos es demasiado larga

¡Anda! Y, ¿ahora qué hago? Bueno, lo más fácil es find(1) al rescate:

# find /tmp/ -name "loquesea.*" -exec rm {} ;

Esta solución hace que se ejecute el rm sobre cualquier fichero encontrado en /tmp/ o subdirectorios que cumpla el patrón indicado. Ojo que el patrón está entre comillas (no lo interpreta el shell, sino find), y veamos porqué la orden original tenía problemas.

Cuando indicamos en el shell un patrón de sustitución, BASH en este caso, reemplaza el patrón por una lista de ficheros que se ajustan a la descripción.

Eso quiere decir que si tenemos:

$ ls
fichero1  fichero2  fichero3  ficha

Al hace un rm fichero*, lo que realmente se ejecuta es: rm fichero1 fichero2 fichero3.

El comando rm(1) puede procesar listas de elementos a eliminar, pero el tamañano de la lista es limitado, y con los ficheros temporales que tenía esta mañana… he superado el límite.

Apuesto a que hay otras formas de solucionar la papeleta, si alguien se anima, que use los comentarios .

Leer el post completo »

Hace ya algún tiempo comentaba diferencias entre SH (pdksh) y BASH, y hoy me he encontrado algo habitual cuando manejas directorios con muchos ficheros, o como me ha pasado a mi: liberando espacio de /tmp/.

Tenía gran cantidad de ficheros temporales, y otras cosas que no quería borrar, bueno… para eso están los patrones:

# rm /tmp/loquesea.*
-bash: /bin/rm: La lista de argumentos es demasiado larga

¡Anda! Y, ¿ahora qué hago? Bueno, lo más fácil es find(1) al rescate:

# find /tmp/ -name "loquesea.*" -exec rm {} ;

Esta solución hace que se ejecute el rm sobre cualquier fichero encontrado en /tmp/ o subdirectorios que cumpla el patrón indicado. Ojo que el patrón está entre comillas (no lo interpreta el shell, sino find), y veamos porqué la orden original tenía problemas.

Cuando indicamos en el shell un patrón de sustitución, BASH en este caso, reemplaza el patrón por una lista de ficheros que se ajustan a la descripción.

Eso quiere decir que si tenemos:

$ ls
fichero1  fichero2  fichero3  ficha

Al hace un rm fichero*, lo que realmente se ejecuta es: rm fichero1 fichero2 fichero3.

El comando rm(1) puede procesar listas de elementos a eliminar, pero el tamañano de la lista es limitado, y con los ficheros temporales que tenía esta mañana… he superado el límite.

Apuesto a que hay otras formas de solucionar la papeleta, si alguien se anima, que use los comentarios .

Leer el post completo »

Desde que estoy en Bilbao ha sido muy socorrido que Gnome venga integrado con su propio servidor VNC (vino, accesible vía Sistema > Preferencias > Escritorio remoto). Eso me permite dar soporte a mi madre en sus pequeños problemillas con el PC.

Pero esta característica out of the box tiene limitaciones, como que vino solo permite acceder a una sesión X11 existente (como la que suele tener abierta mi madre), y no crear tus propias sesiones.

Cuando quiero acceder a ciertos datos de mi máquina que dejé en casa, y vía SSH es imposible porque son datos que dependen de una aplicación con interfaz gráfico, con la conexión que tenemos por aquí a Internet es muchas veces inviable traer aunque sea sólo una aplicación con el protocolo de X11. El no poder crear una sesión me impide trabajar con vino en este caso, porque no hay sesión abierta.

Así que voy a explicar cómo lo he solucionado: permitiendo abrir sesiones X11 vía VNC.

Leer más

Leer el post completo »

Desde que estoy en Bilbao ha sido muy socorrido que Gnome venga integrado con su propio servidor VNC (vino, accesible vía Sistema > Preferencias > Escritorio remoto). Eso me permite dar soporte a mi madre en sus pequeños problemillas con el PC.

Pero esta característica out of the box tiene limitaciones, como que vino solo permite acceder a una sesión X11 existente (como la que suele tener abierta mi madre), y no crear tus propias sesiones.

Cuando quiero acceder a ciertos datos de mi máquina que dejé en casa, y vía SSH es imposible porque son datos que dependen de una aplicación con interfaz gráfico, con la conexión que tenemos por aquí a Internet es muchas veces inviable traer aunque sea sólo una aplicación con el protocolo de X11. El no poder crear una sesión me impide trabajar con vino en este caso, porque no hay sesión abierta.

Así que voy a explicar cómo lo he solucionado: permitiendo abrir sesiones X11 vía VNC.

Leer más

Leer el post completo »

El proyecto Tango es una inciativa de freedesktop.org, que auna desarrolladores y diseñadores de diferentes escritorios para trabajar en la interoperatividad y la tecnología común de los entornos basados en el X Window System, que no es más que un entorno gráfico para sistemas tipo Unix (como Linux o los distintos *BSD).

La verdad es que resulta fácil irse por las ramas hablando de un proyecto como freedesktop.org , así que centrémonos en Tango: se trata de intentar conseguir un entorno gráfico de usuario consistente para las aplicaciones libres, o más bien la experiencia del usuario.

En realidad la parte más visible del proyecto es el juego de iconos de Tango, aunque también se encargan de otras tareas menos agradecidas pero igual de importantes, pese a ser más difíciles de identificar por el usuario.

Algunos iconos de Tango!

Los objetivos del proyecto son: sugerir un aspecto por defecto consistente, estandarizar cómo los desarrolladores llaman a los iconos y dónde se instalan en el sistema (por ejemplo), unas directrices generales independientes del escritorio (ya sea Gnome, KDE, o cualquier otro) para diseñar interfaces y, finalmente, un paquete de iconos lo más completo posible que sigue una guía de estilo uniforme.

¿Cuál es el resultado obtenido? Bien, por una parte tenemos un entorno coherente y uniforme a la vista (no hay iconos que no encajen), siguiendo todas las aplicaciones un estilo constante, y a la hora del trabajo diario me he dado cuenta que es importante.

A veces me da por probar otro juego de iconos, pero termino por volver a Tango porque se cometen errores que en este proyecto procuran evitar (como iconos que parecen un pegote añadido fuera de contexto, que no se adivina lo que intentan representar, o que no se ven correctamente en todos los tamaños). Así que el trabajo que están llevando a cabo en freedesktop.org parece que sí tiene un sentido y da sus frutos .

Nos pueden gustar más o menos estéticamente, pero desde luego es interesante para el usuario (aunque parezca que no, es más confortable OpenOffice.org con los iconos de Tango que con los que trae por defecto… que son feos hasta decir basta ), y para el desarrollador (los iconos tienen licencia Creative Commons Attribution Share-Alike license, muy conveniente para usarlos en nuestros proyectos).

Si trabajamos con Ubuntu y Gnome, es más que probable que ya estemos usando una versión de Tango algo anaranjada, al menos para el escritorio .

Leer el post completo »

El proyecto Tango es una inciativa de freedesktop.org, que auna desarrolladores y diseñadores de diferentes escritorios para trabajar en la interoperatividad y la tecnología común de los entornos basados en el X Window System, que no es más que un entorno gráfico para sistemas tipo Unix (como Linux o los distintos *BSD).

La verdad es que resulta fácil irse por las ramas hablando de un proyecto como freedesktop.org , así que centrémonos en Tango: se trata de intentar conseguir un entorno gráfico de usuario consistente para las aplicaciones libres, o más bien la experiencia del usuario.

En realidad la parte más visible del proyecto es el juego de iconos de Tango, aunque también se encargan de otras tareas menos agradecidas pero igual de importantes, pese a ser más difíciles de identificar por el usuario.

Algunos iconos de Tango!

Los objetivos del proyecto son: sugerir un aspecto por defecto consistente, estandarizar cómo los desarrolladores llaman a los iconos y dónde se instalan en el sistema (por ejemplo), unas directrices generales independientes del escritorio (ya sea Gnome, KDE, o cualquier otro) para diseñar interfaces y, finalmente, un paquete de iconos lo más completo posible que sigue una guía de estilo uniforme.

¿Cuál es el resultado obtenido? Bien, por una parte tenemos un entorno coherente y uniforme a la vista (no hay iconos que no encajen), siguiendo todas las aplicaciones un estilo constante, y a la hora del trabajo diario me he dado cuenta que es importante.

A veces me da por probar otro juego de iconos, pero termino por volver a Tango porque se cometen errores que en este proyecto procuran evitar (como iconos que parecen un pegote añadido fuera de contexto, que no se adivina lo que intentan representar, o que no se ven correctamente en todos los tamaños). Así que el trabajo que están llevando a cabo en freedesktop.org parece que sí tiene un sentido y da sus frutos .

Nos pueden gustar más o menos estéticamente, pero desde luego es interesante para el usuario (aunque parezca que no, es más confortable OpenOffice.org con los iconos de Tango que con los que trae por defecto… que son feos hasta decir basta ), y para el desarrollador (los iconos tienen licencia Creative Commons Attribution Share-Alike license, muy conveniente para usarlos en nuestros proyectos).

Si trabajamos con Ubuntu y Gnome, es más que probable que ya estemos usando una versión de Tango algo anaranjada, al menos para el escritorio .

Leer el post completo »

Mira que es fácil, pero alguna vez me había pasado que al enviar un correo con mail(1), se me planteaba la necesidad de añadir un adjunto… y siempre tomaba la decisión equivocada: emplear base64. Y encima ya lo había explicado por aquí .

En realidad lo más sencillo es usar la codificación uuencode, que precisamente para eso está .

¿La diferencia? Resulta que la codificación base64 se usa integrada con MIME (que no es otra cosa que Multipurpose Internet Mail Extensions ), mediante Content-Transfer-Encoding, pero los clientes de correo no suelen manejar bien un pegote en base64 en medio del cuerpo de un mensaje sin MIME (usando simplemente el formato descrito en el RFC822), y mail no soporta MIME.

Pero esto no ocurre con uuencode, ya que no hay previsión en MIME para usarlo, con lo que nos podemos encontrar un binario codificado dentro del cuerpo del mensaje en texto plano… y los MUA lo saben .

En realidad es muy fácil, y tan delante de las narices estaba, que no lo veía. Por ejemplo, hacemos un mail prueba@usuario.dom:

1. Escribimos el correo normalmente, por ejemplo con $EDITOR (empleando ~v seguido de salto de linea en la entrada interactiva de mail.
2. Si $EDITOR es vi (espero que sí ), podemos ejecutar :re ! uuencode fichero_adjunto fichero_adjunto, y se leerá en el cuerpo del mensaje la salida de uuencode. El primer argumento es el nombre que tendrá en el adjuntoes y el segundo el fichero a adjuntar.
3. Mandamos en correo normalmente (salimos de $EDITOR guardando el texto, e introducimos un punto seguido de salto de linea).

En el editor veremos algo como:

Hola,

Adjunto texto comprimido con gzip.

Un saludo.

Juanjo

begin 644 texto.txt.gz
M’XL(”/W3B$8“W1E>’1O+G1X=“=S,L-@”`0A.’[5K$%$`KP8DSLP`J(3B(&
M=I'’@>Y%+G/ZOSG`I245-O`*%7′<!/&@YB”&NHLRM5C)-%US>RE(J-8:XFV
;XG]HIK[=.6Q`AUPZOU:B92?Z`-<(E2IE““
`
end

Y la mayoría de los MUA extraerán ese bloque y nos mostrarán un adjunto normal, de forma transparente.

Dependiendo de la versión de uuencode se podrá usar esta misma herramienta para extraer adjuntos de un fichero tipo mailbox o en formato RFC822, o puede que necesitemos uudecode; esto en caso de que nuestro MUA no procese bien el adjunto.

Por si a alguien le interesa, existe documentación sobre el algoritmo de uuencode, que está cubierto por el estándar POSIX.

Leer el post completo »

Mira que es fácil, pero alguna vez me había pasado que al enviar un correo con mail(1), se me planteaba la necesidad de añadir un adjunto… y siempre tomaba la decisión equivocada: emplear base64. Y encima ya lo había explicado por aquí .

En realidad lo más sencillo es usar la codificación uuencode, que precisamente para eso está .

¿La diferencia? Resulta que la codificación base64 se usa integrada con MIME (que no es otra cosa que Multipurpose Internet Mail Extensions ), mediante Content-Transfer-Encoding, pero los clientes de correo no suelen manejar bien un pegote en base64 en medio del cuerpo de un mensaje sin MIME (usando simplemente el formato descrito en el RFC822), y mail no soporta MIME.

Pero esto no ocurre con uuencode, ya que no hay previsión en MIME para usarlo, con lo que nos podemos encontrar un binario codificado dentro del cuerpo del mensaje en texto plano… y los MUA lo saben .

En realidad es muy fácil, y tan delante de las narices estaba, que no lo veía. Por ejemplo, hacemos un mail prueba@usuario.dom:

1. Escribimos el correo normalmente, por ejemplo con $EDITOR (empleando ~v seguido de salto de linea en la entrada interactiva de mail.
2. Si $EDITOR es vi (espero que sí ), podemos ejecutar :re ! uuencode fichero_adjunto fichero_adjunto, y se leerá en el cuerpo del mensaje la salida de uuencode. El primer argumento es el nombre que tendrá en el adjuntoes y el segundo el fichero a adjuntar.
3. Mandamos en correo normalmente (salimos de $EDITOR guardando el texto, e introducimos un punto seguido de salto de linea).

En el editor veremos algo como:

Hola,

Adjunto texto comprimido con gzip.

Un saludo.

Juanjo

begin 644 texto.txt.gz
M’XL(”/W3B$8“W1E>’1O+G1X=“=S,L-@”`0A.’[5K$%$`KP8DSLP`J(3B(&
M=I'’@>Y%+G/ZOSG`I245-O`*%7′<!/&@YB”&NHLRM5C)-%US>RE(J-8:XFV
;XG]HIK[=.6Q`AUPZOU:B92?Z`-<(E2IE““
`
end

Y la mayoría de los MUA extraerán ese bloque y nos mostrarán un adjunto normal, de forma transparente.

Dependiendo de la versión de uuencode se podrá usar esta misma herramienta para extraer adjuntos de un fichero tipo mailbox o en formato RFC822, o puede que necesitemos uudecode; esto en caso de que nuestro MUA no procese bien el adjunto.

Por si a alguien le interesa, existe documentación sobre el algoritmo de uuencode, que está cubierto por el estándar POSIX.

Leer el post completo »