Planeta BSD

Despues de solucionar el problema en el ERP de la farmacia X, se pretende realizar una reingenieria que consiste en migrar la aplicacion misma a un entorno logico y fisico mas moderno. La idea es automatizar ciertos procesos rutinarios que son tediosos y solucionables, ademas de ofrecer un mejor desempeño general en cuanto al trabajo diario.

Para lo cual se barajan varias opciones, pero me he inclinado por estudiar dos:

1. Ejecutar el interprete BBX y el ERP mismo sobre una maquina NetBSD con compatibilidad para binarios de SCO UNIX.
2. Hacer pruebas con el interprete PRO/5 que es la solucion que actualmente entrega BASIS, sobre Slackware Linux, con algun kernel 2.4.x.

Para cualquiera de los dos casos hay que tener en cuenta una cantidad de detalles sumamente imporantes, como por ejemplo:

• El sistema funciona con cuentas de sistema operativo.
• Los permisos se administran con perfiles definidos para la shell.
• El manejo de los path es distinto en los distintos Unix.
• Que cada uno de los modulos funcione en su 100%

Otro factor importante es dar de baja el antiguo shellscript que usaban para los backups, y hacer uso de algun sistema mas eficiente como: amanda o bacula.

Por el momento es lo que me encuentro estudianto, espero pronto poder ir contando los avances realizados en esta travesia.

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 »

Se ha publicado un excelente Tutorial para el manejo de IPFW dedicado a usuarios noveles. Además se incluyen reglas básicas para un servidor web.

Leer el post completo »

El nuevo release de la antigua Slackware ya esta disponible. Esta nueva versión es la primera en traer un kernel de la serie 2.6 en la instalación base. Alguna de las cosas interesantes que trae (además del kernel) son HAL, KDE 3.5.7, XFCE 4.4.1, Xorg 7.2 (Wow!!) y como siempre update de todos sus paquetes, que mantienen la estabilidad, flexibilidad y seguridad de la distribución mas antigua de Linux (viva!)

Mas información acá

Y para bajar, click acá!

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 »

Ya no solamente es Theo de Raadt con sus comentarios sobre los bugs en este procesador, sino también se añade Matt Dillon a la polémica.

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 »