PostgreSQL: ¿la base de datos empezó a consumir exageradamente espacio de disco? (actualizado)

En un proyecto gubernamental, donde me desempeño como consultor, estamos trabajando desde hace unos pocos años con el manejador de bases de datos PostgreSQL.

Luego de tener la sorpresa de que nuestro servidor de base de datos (dedicado solo a esa tarea) dejara de funcionar por falta de espacio en disco, tuvimos que iniciar una proceso de auditoría para determinar si las causas eran por uso normal o por alguna situación anormal en su funcionamiento.

Tenía un vago recuerdo que hace unos años atrás la base de datos no superaba los 500 Megas para almacenar los datos en disco. En GNU/Linux los datos se encuentran ubicados en el directorio /var/lib/pgsql/data y con solo hacer un du -h --max-depth=1 sobre el directorio nos mostrará el "uso de disco".

Lo malo de estos casos es que este tipo de situaciones se pueden prever si se cuenta con un Administrador de Bases de Datos (DBA), pero cuando estás en una situación que careces de él, debes repartir tu trabajo diario de desarrollador por el de "DBA Part Time" (con todos los riesgos que conlleva).

Mi sorpresa fue mayúscula al enterarme que a principios de febrero la base estaba consumiendo en el entorno de los 6 Gigas de disco. Luego de seguir su evolución por varios días pude concluir que el crecimiento rondaba los 100 Megas diarios, lo que parecía exagerado teniendo en cuenta la cantidad y el tipo de información que se ingresa por día: generalmente datos "planos", no existiendo ingreso de información "binaria", es decir, documentos, imágenes, etc.

LVM: Logical Volume Management

Primer medida de contención que tuve que tomar fue la de separar en distintas particiones determinadas zonas críticas de consumo de espacio de disco: zona de datos, zona de logs y zona de respaldos (si, es algo que se debe de planear antes, pero así ocurrió por la falta de tiempo y el apuro de cumplir con otras tareas).

Lo que mejor se me ocurrió fue implementar el famoso LVM: Logical Volume Management (Administración de Volúmenes Lógicos).


Esta utilidad no es novedad del ambiente GNU/Linux, en sí muchos sistemas Unix de nivel empresarial ya manejan desde hace mucho tiempo antes este concepto: la idea es contar con una partición física y crear dentro varios volúmenes lógicos, a los cuales les podemos asignar dinámicamente su tamaño.

Lo bueno de esta técnica es que nos permite administrar el espacio a nuestro gusto como si fuera una partición común, pero adaptable según nuestra necesidad, sin tener que estar obligados a crear nuevas particiones, darles formato, mover los datos a la nueva partición, tener el servidor fuera de funcionamiento por un tiempo, etc.



Obviamente, siempre y cuando tengamos un buen margen de espacio libre para poder asignar y desasignar de nuestros volúmenes lógicos.

El mantenimiento de la base de datos

Esta base de datos necesita un determinado "mantenimiento" (en sí, todas lo necesitan) que es provisto en general por una utilidad propia de este motor que se llama vacuum.

En nuestro caso disponemos de una tarea planificada que corre a primera hora de la mañana y a última hora de la noche. Esta aplicación efectuaría el mantenimiento estándar de la base de datos, que comprende (según el siguiente FAQ):

"Para determinar si debe ser usado un indice, PostgreSQL debe tener estadísticas acerca de la tabla. Estas estadísticas son obtenidas usando el comando VACUUM ANALYZE, o simplemente ANALYZE. Utilizando las estadísticas, el optimizador sabe cuantos registros hay en la tabla y de esta manera puede determinar mejor si los índices deben ser usados. Las estadísticas también son valiosas en el momento de determinar el orden de unión o el método de unión óptimos. La obtención de estadísticas debe ser realizada periódicamente conforme los contenidos de las tablas cambien."

¿Qué significa esto? Que debemos programar que corra este utilitario regularmente para hacer este mantenimiento en las horas que se supone no afecten el desempeño de la base de datos.

En nuestro caso usamos un pequeño scripts que tiene la siguiente sintaxis:

time su - postgres -c "vacuum --all --verbose --analyze"

Pero a pesar de todo, este "mantenimiento" se viene haciendo diariamente desde que tenemos la base de datos en producción... entonces, porqué sigue creciendo exponencialmente?

Cuando todo falla, hay que leer los manuales

La base de datos siguió aumentando de tamaño con los días, pero ahora a 200 megas por día. En los últimos días la base de datos había crecido de 6 Gigas a 9 Gigas, y que gracias al LVM se pudo contener al reasignar espacio libre de otras particiones.

Luego de releer nuevamente todos los manuales de las aplicaciones involucradas, el siguiente apartado vuelve a tener sentido para mi:

--full

"Selects "full" vacuum, which may reclaim more space, but takes much longer and exclusively locks the table."

Por los comentarios que estuve leyendo en grupos de discusión, muchos administradores aconsejaban este procedimiento cuando hay mucho ingreso y borrado de información, o cuando se crean o borran abruptamente tablas o bases enteras. El tema era que desde que estamos usando Postgres en producción, nunca usamos la opción "full", solo la alternativa "estándar" (y así lo recomiendan los manuales). La opción vacuum que estábamos usando hace un "bloqueo" a nivel de tuplas para correr el proceso de mantenimiento, y la diferencia con la versión "full" es que el proceso es mucho más profundo y el bloqueo es a nivel de tablas, no siendo posible correrlo en horarios de trabajo de la base de datos.

Actualmente a los scripts de mantenimiento le agregamos el "--full", y la situación cambió radicalmente.

Estos se ejecutan todos los días, 7:30am y 21:30 pm, unas horas antes del uso intensivo de la base de datos. La idea de la primer hora es que la base de datos se encuentre pronta justo antes de la hora crítica de trabajo, y la hora nocturna para adelantar el trabajo de la primer hora (la degradación de la base es acumulativa, por decirlo de alguna manera).

Comentario al margen: de todas formas no sería tan necesario hacer este proceso todos los días, se podría hacer una vez por semana o por mes, según evolucione el uso de la base y el consumo de espacio.

Resultado Final

Bueno, la primera vez que corrió demoro 1 hora y media, y cuando me enteré del resultado final casi me da un infarto: ¡de 9.2 Gigas pasamos a 700 y poco megas! ;-)

Mi primera impresión fue: "¡listo, lo que me faltaba, acabo de destruir la base de datos!" ;-), aunque el comentario proviene de alguien que es normalmente histérico con su trabajo, pues los respaldos estaban al día, y antes de hacer todos estos cambios se hicieron más respaldos adicionales, previendo tener que rearmar la base desde el respaldo (de todas formas, el cambio fue demasiado impactante ;-).

Luego de verificar que los datos eran coherentes, que la base funcionaba, que los logs no reportaban errores, etc, la última evaluación terminó de serenarme: los respaldos posteriores a esta "depuración" tenían el mismo tamaño que los respaldos anteriores. Esto significa que si tomamos en cuenta que el respaldo a través de un dump concluye con un archivo de texto con todas las sentencias sql para rearmar la estructura de las bases existentes, tablas y datos, el hecho que ambos respaldos tuvieran el mismo tamaño garantizaba que los datos eran los mismos (o por lo menos, que era la misma cantidad de información) y que no se habían perdido datos.

Conclusión

Primero, antes de hacer todo esto, _siempre_ debemos estar al día con los respaldos, tenerlos probados que funcionan (auditorías regulares) y que recuperan toda la base de datos sin faltar nada (es el 50% del respaldo tener verificado que funciona). Segundo, no olvidar del mantenimiento de Postgres, y tercero, siempre, "cuando todo falle, lee el manual", aunque sepas que alguna vez lo leíste de arriba a abajo ;-)

Ejemplo de configuración de un mantenimiento regular

En el crontab se podría agendar para que lo haga en horas que no se esté usando la base de datos:

30 7 * * 1-5 /var/respaldos/scripts/mantenimiento_postgresql.sh
30 21 * * 1-5 /var/respaldos/scripts/mantenimiento_postgresql.sh

Y el scripts "mantenimiento_postgresql.sh" podría contener:

#!/bin/bash

ECHO=`which echo`
TIME=`which time`
SU=`which su`
VACUUM=`which vacuumdb`

$ECHO "Mantenimiento Base de Datos"
$TIME $SU - postgres -c "$VACUUM --all --full --verbose --analyze"


PD: no, no, y no, no me gusta el trabajo de "DBA Part Time" ;-)

Documentación

PostgreSQL

• SQL Vacuum

• Vacuumdb (consola)

• Backup & Restore

LVM

• HowTo
  

• Configuración en SuSE

Actualizaciones

• 7/2/2007 - Scripts de respaldos y configuración del crontab.
  

Gmail Drive: "mi respaldo alternativo"

La verdad que esta utilidad, aunque no es oficial (no la hizo Google), y por parte de los autores hay duda de si en algún momento puedan impedir su uso (porque no respeta el contrato de uso del servicio Gmail), la encuentro verdaderamente útil.

Hace no mucho tiempo que adquirí un pendrive de 1 Giga (cada vez que lo digo, me emociono de tener tanta capacidad digital en tan pocos átomos ;-), pero el destino me obsequió que los puertos usb de mi equipo de trabajo no funcionen correctamente, corrompiendo la información que transfiero a él (no me queda otra opción que acceder desde otra máquina).

Historia & Concepto

Este proyecto se inició (no podía ser de otra forma) desde la plataforma GNU/Linux, creando una unidad virtual que permitiera usar la cuenta de Gmail como si fuera un dispositivo local. Nos permite copiar, mover, borrar, etc, los archivos dentro de esa unidad, como si fuera una unidad local. La idea es que existe una "capa de software" que se encarga de "simular" las operaciones tradicionales y traducirlas en operaciones compatibles con una cuenta de correo web con mucho espacio disponible.

La gran ventaja de esta utilidad es que nos permite usar una cuenta Gmail para hacer respaldos de forma sencilla y como si tuviéramos un "pendrive local" (permítanme la licencia poética ;-).

Ejemplo práctico: estás en una empresa que filtran exageradamente el tráfico de Internet, lo cual te impide bajar algunos archivos de importancia (si, según tu criterio personal, no el del administrador ;-). Lo malo, es que el tamaño excede el de un simple diskette, y no cuentas con un pendrive como para transportarlo desde un equipo que no tenga esa restricción (que perfectamente puede ser tu propio equipo hogareño con una conexión a Internet privilegiada). Te conectas con tu unidad virtual, copias el archivo, te desconectas, visitas tu equipo "restringido", te conectas a tu unidad virtual, bajas el archivo.

Nota: mis respetos al administrador de la seguridad de la red ;-) El concepto de "seguridad informática" supera el solo hecho de restringir determinadas extensiones de archivos desde Internet.

Muchos podrán decir: "eso ya lo hago hoy día, me envío correos con documentos adjuntos", pero esta utilidad nos simplifica y nos da más flexibilidad en el proceso de respaldo. Si borramos un archivo, este se elimina de la cuenta de Gmail, podremos crear estructuras de directorios, ordenar jerárquicamente, etc, como si fuera un "sistema de archivos" completo ("filesystems").

El proyecto original se llama Gmail Filesystem y corre en GNU/Linux. Luego, usuarios inquietos y envidiosos ;-) decidieron hacer una utilidad similar para Windows que se llamó GMail Drive shell extension.

Nota: como no pude hacer una instalación "sencilla" del proyecto original en su sistema original, opté por comentar el proyecto "hermano", que sí se instaló sencillamente y sin mayores problemas (prometo armar un artículo que trate el tema de instalarlo en GNU/Linux).

Al instalar este pequeño cliente obtendremos un disco virtual que aparecerá en nuestro sistema Windows con el nombre de GMail Drive.

¿Cómo funciona?

Si presionamos sobre él, nos solicitará una cuenta de Gmail y nuestra clave. Si logramos conectarnos con éxito (y nuestra conexión a Internet es minimamente decente) ya podremos utilizarlo.

La operación es similar a lo que ya estamos acostumbrados a hacer en el explorador de Windows, nos posicionamos en cualquier archivo de nuestro disco, botón derecho -> copiar, luego nos posicionamos en el "disco virtual" y le damos botón derecho -> pegar.

Tips

El primer error de novato (el que yo hice al principio) es copiar todo deliberadamente en la unidad, sin ningún tipo de orden. Si nos posicionamos sobre el espacio donde están nuestros archivos, al presionar el botón derecho, nuestro menú contextual nos mostrará la opción "folder", lo que nos permite crear las carpetas dentro de nuestra unidad virtual.

Podemos seguir usando la cuenta, aunque yo recomiendo crear una nueva para uso exclusivo de este sistema (un simple tema de orden). La gran ventaja de este sistema es que si ingresamos a Gmail como si fuéramos a leer nuestro correo (que es lo que estamos haciendo, al final de cuentas ;-) veremos los correos que representan los archivos copiados a nuestro disco virtual como un "correo con un archivo adjunto". Lo bueno de esto es que también podemos acceder a nuestros archivos y bajarlos sin tener que estar en un sistema con el GMail Drive instalado.

Bugs

Si, ya encontré uno. O por lo menos, se parece. Si intentamos copiar un archivo con "nombre largo", nos dará un mensaje de error. Aparentemente existe una limitante o simplemente un error cuando el nombre es *muy* largo (largos normales, nada disparatado). Sí se pueden superar los mágicos 8 caracteres ;-).

En la captura de pantalla pueden ver algunos archivos con nombre largos que subí. Todavía tengo que determinar (o encontrar en la documentación) cual es el verdadero límite y como se origina (porque supuestamente no existe ese límite en la cuenta de Gmail).

Por último, no olvidar que el tamaño máximo de los archivos a subir a nuestra unidad virtual no puede superar los 10 Megas, pues es el límite por correo que soporta Gmail. De todas formas, esto no es impedimento para marcar varios archivos de 10 megas cada uno, copiarlos y pegarlos en la unidad (los sube uno a uno, de a 10 Megas).

Pedido: no tuve tiempo de investigar, pero si alguien conoce o recomienda un procedimiento "cómodo" y "simple" desde GNU/Linux para armar un respaldo partiendo de uno o varios archivos grandes y armar varios paquetes comprimidos de 10 Megas (ya saben hacia donde voy ;-), que me lo cuente ;-)

Hasta ahora no sé si se puede hacer con el TAR respaldos multivolumen acotándolos a 10 Megas por parte ;-)

¡Saludos!

"Cómo Ser Un Programador: Un Resumen Corto, Comprensivo y Personal"

En muchos sitios recomiendan la lectura de este ensayo, y debo ser sincero, todavía no terminé de leerlo como para poder dar una opinión formada del mismo.

Lo que sí estoy seguro, es que de "corto" no tiene nada ;-)

Les dejo una breve introducción y el enlace a la traducción al castellano (también está la versión original en inglés, pero si la traducción es buena, fomentemos nuestro idioma ;-).

"Ser un buen programador es difícil y noble. La parte más difícil de hacer real una visión colectiva de un proyecto de software es lidiar con los compañeros de trabajo y con los clientes de uno. Escribir programas de computadora es importante y requiere gran inteligencia y habilidad. Pero realmente es un juego de niños comparado con todo lo demás que un buen programador debe hacer para lograr que un sistema de software tenga éxito tanto para el cliente como para la miríada de colegas por quienes se es parcialmente responsable. En este ensayo intento resumir tan concisamente como sea posible esas cosas que desearía que alguien me hubiese explicado a mí cuando tenía veintiuno.

Esto es muy subjetivo y, por lo tanto, este ensayo está condenado a ser personal y algo testarudo. Me confino a mí mismo a los problemas que un programador muy probablemente tiene que enfrentar en su trabajo. Muchos de esos problemas y sus soluciones son tan generales a la condición humana que probablemente pareceré predicativo. A pesar de ello tengo fe de que este ensayo será útil."

Firefox: una extensión para manejar múltiples "pestañas" (tags)

Una de las características del navegador Firefox son sus famosas "pestañas" (tags) que nos permiten en una única ventana poder tener varias "pestañas" con sitios distintos cada una.

Introducción: ¿para qué sirven las pestañas?

Un uso práctico: si estamos en un sitio que tiene muchos enlaces a otras páginas (con contendidos que te interesan leer también), mientras vamos leyendo una página podemos ir presionando con el botón central del mouse sobre los enlaces y estos se irán abriendo en pestañas nuevas. Cuando terminamos de leer la primer página, tendremos ya cargadas en las siguientes pestañas las nuevas páginas.


Sirve para ahorrar tiempo de espera, o para no olvidarnos que queremos leer también esos enlaces.

Técnicas para mejorar el uso de las pestañas

Para fanáticos de la lectura y la navegación compulsiva (con mucho de "infoxicación") podremos llegar a tener en nuestro navegador una cantidad "exagerada" de pestañas, dificultando su manejo. Por ejemplo, si tenemos pocas pestañas es fácil encontrar lo que buscamos al leer el texto que resume el título de la página (generalmente el espacio no es suficiente). El problema empeora cuando tenemos 15 o más pestañas y no da el espacio para disponer de un texto con un largo suficiente, lo cual hace que ya no sepamos a qué se refiere.


Una solución es ir leyendo la primer pestaña a nuestra izquierda, e ir cerrando luego de leida (forma rápida: [Control]+[w]), lo que libera espacio para visualizar las demás descripciones de las pestañas.

Pero si estamos saltando de una pestaña a otra, sin orden, y sin poder cerrar las ya leidas (no queremos perderlas), la situación se complica aún más.

La extensión "Reveal"

Bueno, una solución es la siguiente "extensión" (una utilidad para extender la funcionalidad de nuestro navegador Firefox): Reveal

Esta extensión nos ofrece, presionando [F2], visualizar todas las pestañas abiertas como pequeñas capturas de pantalla (facilitando su reconocimiento), permitiendo seleccionar a cual queremos ir con un simple "click".

Es mucho más intuitivo ver una vista miniatura de la página que queremos seleccionar (nos damos cuenta por los colores, la estructura, las imágenes, o directamente con ver el texto del título completo) que ver el título en una pestaña en donde solo se perciben unas pocas letras por la falta de espacio.


Otra de sus características es contar con un buscador, lo cual facilita aún más la selección de una pestaña particular: si colocamos "google" nos traerá todas las pestañas que tengan el texto "google" en su título (varias pestañas con consultas en google, una con nuestro gmail, etc). Y existen otros criterios de búsqueda: url, página, etc.


Muy recomendable, y la animación de las mini-ventanas apareciendo en nuestro navegador, muy disfrutable ;-)

Actualización(04/02/2005): luego de probarlo unas horas, les cuento dos detalles: cuando tienes muchas ventanas y la pantalla no permite mostrar todas las capturas de las pestañas, debes usar las teclas [Re Pág] y [Av Pág] (retroceder y avanzar página, en inglés "Page Up" y "Page Down") para "paginar" o "avanzar por páginas" y visualizar el restante grupo de páginas.

Pero el verdadero "tips" es que puedes usar el menú contextual sobre la captura de la pestaña como si estuvieras en la pestaña, lo que significa que puedes hacer: botón derecho sobre la imagen de la ventana, opción "cerrar", e ir cerrando las pestañas que quieras.


Si lo pruebas en combinación al buscador, es realmente rápido manejar múltiples pestañas.

(ando como "perro con dos colas" con esta nueva extensión ;-)

Si lo dijo Einstein ...

"Los grandes espíritus siempre han encontrado la violenta oposición de las mentes mediocres. Estos últimos no pueden entender que un hombre no se someta irreflexivamente a los prejuicios hereditarios sino que emplee honestamente y con coraje su inteligencia."

"La mente intuitiva es un regalo sagrado y la mente racional es un fiel sirviente. Hemos creado una sociedad que rinde honores al sirviente y ha olvidado al regalo. "

"No es que sea muy inteligente, es solo que llevo mucho tiempo entre problemas"

"Tengo lo bastante de artista como para dibujar libremente con mi imaginación. La imaginación es más importante que el conocimiento. El conocimiento es limitado, la imaginación da la vuelta al mundo"

"Lo más importante es no dejar de interrogarse. La curiosidad tiene su propia razón de existir. Uno no puede evitar asombrarse cuando contempla los misterios de la eternidad, de la vida, de la maravillosa estructura de la realidad. Es suficiente si uno trata simplemente de comprender un poco de este misterio cada día. No hay que perder jamás la sagrada curiosidad"

"Leer, después de cierta edad, desvía demasiado a la mente de su búsqueda creativa. Cualquier hombre que lee mucho y emplea poco su propio cerebro cae en hábitos perezosos de pensamiento"

"No sé cómo será la III Guerra Mundial, pero sí la IV... con piedras y palos"

"El sentido común es esa colección de prejuicios que se adquieren cuando cumples 18"

"Todo aquel que nunca cometió un error, jamás ha intentado nada nuevo"

"Si buscas resultados distintos, no hagas siempre lo mismo"

"Si A igual a éxito, entonces la fórmula es: A=X+Y+Z, donde X es trabajo, Y es juego y Z es mantener la boca cerrada"

"El telégrafo sin hilos no es difícil de entender. El telégrafo ordinario es como un gato muy largo. Pones la cola en Nueva York y el gato maúlla en Los Ángeles. El telégrafo sin hilos es lo mismo pero sin el gato"

"¡Triste época la nuestra! Es más fácil desintegrar un átomo que un prejuicio."

"Solo hay dos cosas infinitas: el universo y la estupidez humana, y no estoy muy seguro de lo primero"

Fuente: Astroseti

Una frase a colación de los anteriores artículos...

"La meta principal de la educación es crear hombres que sean capaces de hacer cosas nuevas no simplemente de repetir lo que otras generaciones han hecho; hombres que sean creativos, inventores y descubridores.
La segunda meta de la educación es la de formar mentes que sean críticas, que puedan verificar y no aceptar todo lo que se les ofrece."

Jean Piaget
Psicólogo suizo (1896-1980)

Robado de: Creative Minds

Para reflexionar: Linus Torvald no adoptará la GPL 3 para su kernel

La verdad que esta noticia me deja muy contento por el hecho de que existan opiniones y formas distintas de hacer las cosas.

Es sano que los "gurúes" discrepen, que Linus Torvalds tenga una postura distinta a Richard Stallman, que exista gente que opine distinto y discrepe, y que exista la libertad de poder expresar su opinión. Creo que la oposición de ideas nos enriquece y nos permite reflexionar, y tal vez, cambiar de postura si nos damos cuenta en el intercambio de opiniones que estábamos equivocados.

Pero no siempre es así... casi nunca es así

Me vuelvo a preguntar: ¿muchos de los integrantes de esta comunidad no se estarán convirtiendo en personas demasiado arrogantes, orgullosas y necias al no aceptar posturas distintas a las suyas? ¿es válido solo aceptar a quién piense como nosotros?

Y lo peor, es que se podría esgrimir que vienen del "enemigo" con intenciones de hacernos daño, pero sucede que cuando vienen de integrantes de la propia comunidad tampoco son aceptadas.

No creo que sea muy sana esta actitud.

¿Nos estamos aislando? ¿ni siquiera escuchamos a nuestros colegas?

Lo que yo dudo es si las "personas comunes" (nosotros) podremos tener la misma libertad de discrepar y de discutir con educación nuestras ideas con los "líderes" de estos movimientos (desde un desarrollador, a un directivo de un grupo de usuarios, o con Richard Stallman).

Al final de cuentas, nosotros somos la mayoría la que da el sustento a la comunidad. En sí, somos la "comunidad", los que le damos el poder a los "líderes".

¿Libertad para el software, pero no para opinar?


Hace poco tiempo estuve intercambiando correos con Richard Stallman porque le pedí su opinión sobre la serie de artículos (muy humildes) que escribí con la siguiente pregunta como título "¿Talibanes del Software Libre?" (parte 1, parte 2, parte 3).

Nota: Ya lo he explicado varias veces, los he escrito en tono de reflexión y con una postura de abogado del diablo (apoyo el Software Libre, no busco su destrucción ;-).

Lamentablemente nos quedamos discutiendo sobre los "términos" y no sobre el "contenido" (y eso dará para un nuevo artículo que voy a escribir con tiempo).

Como le dije a Stallman: "Lo que evidencio en mis escritos es una observación de la realidad (no de mi imaginación) y veo en ella que se está optando por actitudes 'extremistas' e 'intolerantes' ".

Muchos me dirán que me metí en la "boca del lobo", pero estoy defendiendo mi derecho a opinar, a discrepar, y expresarme. Como de la misma forma respeto el derecho de otros a opinar distinto, y si lo desean, a no opinar (como terminó pasando en este caso).

No quiero seguir usando metáforas, pero con el tiempo muchos grupos importantes dentro de la comunidad se están pareciendo a "dictaduras" del estilo de Cuba (con todas las salvedades del caso ;-). Si apoyas al régimen, bien, pero no hay lugar para los que están en contra o para quienes discrepan con parte o con todo el mensaje de la "corriente oficial".

Pero bueno, Stallman finalmente prefirió no responderme porque (por lo que yo entendí) no toleraba mi postura crítica.

Extracto de la noticia original, fuente Kriptópolis:

"Linus Torvalds, creador del kernel y líder de Linux, ha anunciado que Linux no adoptará la versión 3 de la licencia GPL, según diversas fuentes ([1],[2]) debido al tratamiento restrictivo que ésta dispensa a los DRM, es decir, los sistemas de protección de contenidos con copyright. Torvalds afirmó ya hace más de dos años que no quiere que Linux sirva para hacer política, y que le gustaría que Linux pudiera servir para todo, incluso para cosas que personalmente pudieran no gustarle..."

Actualización (28/01/2006)

Fuente MexicoExtremo:

"Esto sólo ratifica una añeja discusión entre Richard Stallman (fundador de la FSF y creador de la GPL) y Torvalds, ya que el primero pretende que no exista ningún tipo de limitación en el acceso a los programas y la información, mientras que el segundo, al haber trabajado en empresas y organizaciones comerciales, busca un equilibrio entre la comunidad de software libre y la parte corporativa."

Actualización (6/02/2006)

La traducción es por parte de Linux Para Todos, y el artículo original de Newsforge:

«Literalmente siento que —como desarrolladores— no tenemos el derecho moral para forzar nuestras reglas a los fabricantes de soporte físico»

«No somos cruzados, tratando de forzar a la gente a arrodillarse antes nuestro Dios superior. Estamos tratando de mostrar a otros que la cooperación y la apertura trabajan mejor.»

"Remuneración del Sector Tecnología de la Información" (actualizado 21/01/2007)

Este es un estudio que está disponible libremente en el sitio de la Universidad ORT donde soy alumno desde hace casi 10 años (actualizando infinitamente la carrera) y próximamente podré desquitarme (seré docente de la misma ;-).

Este estudio fue hecho por la CUTI, donde muestra muy brevemente (2 páginas) cuales son los salarios promedios que se perciben en Uruguay hasta el año 2004 (después de una crisis que se podría decir que se inició en el año 2000 y se acentuó en el 2003).

Hay varias salvedades a tener en cuenta:

• Son precios "nominales", lo que significa que hay que hacer todos los descuentos legales correspondientes (en los sueldos menores estaríamos hablando promedialmente de 15% menos y en los más altos hasta casi 25%).
• Los precios están en dólares, pero se reconoce en el estudio que mayormente ya se encuentran pesificados (lo que hace que con la conversión estos sueldos se desvaloricen aún más).

Lo bueno

• En mi opinión la mayoría de los informáticos de este país (aunque creo pasa en otras profesiones) son reticentes a hablar de los sueldos que se perciben. Tal vez por orgullo, por vergüenza o por pudor (o las tres cosas). Lamentablemente esto hace que no podamos tener "valores de referencia" reales y poder saber donde estamos parados (y las empresas se aprovechan de ello). Con este estudio, podremos tener -por lo menos- una referencia.

Lo malo

• Los "sueldos de referencia", analizando la región, son bajos. Tomando los países limítrofes: en Argentina reciben promedio el doble que en Uruguay, y en Brasil casi el triple.
• Seguimos careciendo de una organización que nos respalde. A pesar que existe la CUTI, esta organización respalda a las empresas, no a sus empleados.
• Se reconoce en el documento que la "pesificación salarial" perjudicó a todo el personal del sector, no así a las empresas. Antes de la crisis, la mayoría de las empresas no se animaba a salir del país, durante la crisis, las empresas estuvieron obligadas a buscar otros mercados o perecer. Gracias a esto, los sueldos se mantuvieron en pesos y las empresas (al salir de la crisis) continuaron ganando en dólares (donde el cambio de moneda los beneficia al tener todos los gastos en pesos).
• No se ha fijado un laudo mínimo. Siguiendo el revivido (por el nuevo gobierno) Consejo de Salarios, la propia CUTI hace referencia en una FAQ que al no existir una "negociación" (no hay una organización que respalde a los informáticos) "al no haberse producido la negociación, no se establecieron salarios mínimos por categoría funcional. Esto otorga una mayor flexibilidad a las empresas" (sic). Lo malo es que explícitamente se habla que la función de los "consejos de salarios" era "establecer salarios mínimos, categorías y otros beneficios"(¿salimos nuevamente perjudicados?).

Nota Mental: ¿Será que por la propia actitud "introvertida e individualista" que caracteriza a los informáticos es que no podemos juntarnos y organizarnos para defender y reclamar nuestros derechos?

Conozco a muchos informáticos con títulos universitarios que están recibiendo sueldos de programadores.

Y creo que todos conocemos el común denominador de nuestro mercado: las más importantes empresas de nuestra plaza se ufanan de su éxito en el exterior, pero a la hora de contratarnos los sueldos no se ajustan al nivel de responsabilidad y conocimientos que nos solicitan.

Y ni que hablar que en nuestra plaza la mayoría de las empresas "obliga" (directamente o indirectamente) a trabajar más de las legales 8 horas diarias. Y doy un seguro 99% que ninguna paga horas extra (considerada casi "mala palabra" por nuestros empleadores).

¿Tenemos derechos? ¿o solo obligaciones?

¿Esta es la Industria de las TI que se quiere desarrollar? ¿a costa de explotar a los empleados?

Otra evidencia de la situación que estamos viviendo: en las empresas de nuestra plaza se prefiere pagar por 4 programadores "junior" en vez de un solo programador "senior", evidenciando que no se prioriza en absoluto la calidad sobre la cantidad.

Hoy parece que la meta es disminuir al mínimo el costo "salarios"; pero esta reducción afectará -indudablemente- la productividad de las personas y la calidad de los proyectos.

Cuando uno tiene contacto con colegas que trabajan en distintas empresas con clientes fuera del país, el comentario es recurrente: "estamos muy atrasados", "me llamaron para volver a armar los casos de uso", "el cliente está desconforme", "ya superamos el presupuesto", "el sistema debió ser recortado", etc.

Como decía Joel Spolsky en su blog Joel On Software con el artículo Alcanzando las notas altas:

"El problema real con usar muchos programadores mediocres en vez de un par de buenos programadores es que no importa cuanto trabajen, nunca producirán nada tan bueno como lo que los buenos programadores pueden producir"

En definitiva, parece que la respuesta es una sola, como dice el refrán: "La culpa no es del chancho, es de quién le rasca el lomo" (traducción: "La culpa es nuestra").

Actualización (24/01/2006): en la sección Facultad de Comunicación y Diseño de la ORT se encuentra el documento Aranceles profesionales de diseño, que como dice su nombre, son aranceles predefinidos para profesionales del área de diseño a mayo de 2005.

Tal vez esto sea algo que nos está faltando a los informáticos: un "valor de referencia" que nos ayude a "organizar" el mercado. Una de las razones que se esgrime a la hora de justificar los bajos salarios es que hay profesionales (y no tanto) que aceptan estos sueldos, y si las empresas no consiguieran personal con estas ofertas, se verían obligadas a mejorarlas.

Un ejemplo: una empresa de origen hindú, Tata Consultancy Services (TCS), que se encuentra radicada desde hace unos años en nuestro país viene recolectando todos los informáticos que encuentra que tengan conocimientos de Java. Nuestro mercado es tan pequeño que en poco tiempo empezaron a escasear y las empresas locales -con muy buena fama de pagar sueldos bajos, como el caso de IBM - tuvieron que empezar a subir sus ofertas.

¿Será hora de que "salgamos del armario"? (no digo "tomar las armas", pero por algo hay que empezar ;-)

Enlaces directos a los documentos:

• Remuneración del Sector Tecnología de la Información
• Aranceles profesionales de diseño

"¿Talibanes del Software Libre?", tercera parte

Siguiendo en la línea de los comentarios que he recibido al respecto
de los post sobre "¿Talibanes del Software Libre?", parte 1 y parte 2, me veo en la obligación de seguir explicando porqué deberíamos ser más autocríticos con el rechazo a una ley que obligue a usar Software Libre en la administración Estatal.

En uno de los comentarios escritos por un "usuario anónimo" se me pregunta sobre el sentido de mi frase: "¿nunca se pusieron a pensar que si obligan a usarlo estaríamos creando el "Monopolio del Software Libre"?" de la siguiente forma:

"¿Me puede explicar la forma en la que se puede generar un monopolio mediante una licencia GPL? Puede explicarme también ¿en qué forma la licencia GPL impide a una empresa, a cualquier empresa, dar soporte o servicios sobre un determinado programa?"

Desde ya, gracias por verter aquí tu opinión ;-)

Como nos decía un docente de "Diseño UML" (magistrales clases, por
cierto ;-):

"Si me cambian el contexto, debo cambiar la solución"

Esto se aplicaba cuando nosotros creábamos una solución a un problema determinado y luego venía alguien a criticarla diciendo "sí, todo muy lindo, pero si ocurre *tal situación* este diseño no funcionará".

La solución, o mejor dicho, la autocrítica que intento promover está basada en cierto "contexto" y si lo cambiamos constantemente, deberé cambiar el contenido de la autocrítica o no se podrá entender ni aplicar ;-)

No interesa la realidad particular de España

Pasando en limpio, no quiero hablar en profundidad de la realidad de España porque la desconozco (y tampoco es mi intención que para expresar esta idea deba hacerlo), y si la conociera, muy probablemente sería subjetivo y llegaría a estar de acuerdo en muchas razones que se esgrimen para justificar una ley (aunque seguiría no estando de acuerdo con la creación de una la ley para ese propósito).

Pero en lo que no puedo estar de acuerdo es que se distorsione el mercado y se cometan injusticias contra empresas por querer solucionar los problemas de un Estado (que pudieron ser generados por la mala administración de sus propios políticos) a través de una ley que obligue a comprar solo productos de Software Libre (¿?).

Cuando libertad está solo en el nombre del software

Todo el mundo discute y argumenta los altos costos del Estado, de malos gastos, y de cuanto se ahorraría con una medida como esta (y se repite en todas partes del mundo).

¿No nos estaremos equivocando al querer aplicar una "solución" para paliar un problema que se debería solucionar desde otro ámbito? (mejora en la administración general, compras estatales, optimización de recursos, políticas de gasto, etc).

Lo que quiero discutir y criticar es la idea general (y generalizada)
del concepto de "libertad" que se intenta aplicar imponiéndola a través de leyes. Si analizamos los argumentos de sus defensores, creo que es imposible que exista "libertad" si nos obligan a seguir un modelo que tal vez no estemos de acuerdo y no lo compartamos, o directamente por no ser objetos de ningún beneficio (lo explico más adelante).

¿Se puede ser Juez y Parte?

¿El modelo de la GPL de la Free Software Foundation, es el único modelo a seguir?, ¿es el más justo?, ¿no hay otros modelos? ¿Si elegimos GPL, no estamos discriminando y no dando lugar a otras alternativas?

¿Quién será juez y parte? ¿los presidentes de los Grupos de Usuarios de Linux (donde han nacido las iniciativas para crear este tipo de ley)? ¿los empresarios del Software Libre? ¿los presidentes de los Grupos de Usuarios que son a la vez empresarios del Software Libre?

Y no es menor la pregunta, ya que ellos son los "autores" o "co-redactores" de las mismas: ¿quién regula estos Grupos de Usuarios? ¿Son verdaderamente organizaciones sin fines de lucro? ¿o son lobbies para preparar negocios donde unos pocos elegidos serán los beneficiados?

Siguiendo en la postura de "Abogado del Diablo" (yo vivo comercialmente del Software Libre), pregunto: ¿no es un negocio redondo y muy conveniente estar en ambas partes? ¿Puedo ser promotor de leyes que obliguen a usar Software Libre a través de organizaciones "sin fines de lucro" pero que luego me beneficio directamente porque mi empresa ahora se convierte en proveedor único (o por lo menos con grandes ventajas) del Estado?

Otra posibilidad, atacando el argumento esgrimido de que este tipo de medidas generan dinero en la economía local y no se va del país: ¿al quitarles competidores para proveer al Estado, los proveedores del Software Libre no podrían ser también enormes empresas extranjeras como Red Hat, Novell, etc?

¿Y quién dice que en una situación tan beneficiosa no se conviertan en monopolios del Software Libre? (no permitiendo, directa o indirectamente, que otros competidores del Software Libre participen).

Monopolio del Software Libre

Nunca hablé del monopolio como dominio del mercado de una única empresa, siempre hice referencia a un probable monopolio del software libre, es decir, a un conjunto de personas o empresas que pudieran acaparar un mercado por el simple hecho de que las reglas obliguen solo al uso de este tipo de software, excluyendo a que las demás empresas pudieran competir en igualdad de condiciones.

Nota: tal vez no sea lo mejor usar el término monopolio para definir la idea que quiero transmitir, pero por falta de alternativas, la seguiré usando hasta que encuentre otra ;-)

Reconozco que el Software Libre disminuye el riesgo y la vida de un monopolio, pero no creo que lo evite completamente. Por ejemplo, en un monopolio con estas características sería una cuestión de tiempo para que las empresas más pequeñas se adapten rápidamente y finalmente, con un alto costo, las empresas más grandes, logrando equilibrar el mercado. Pero es indiscutible que en el proceso se verían perjudicadas muchas empresas y beneficiadas unas pocas (por lo menos en un período de tiempo).

¿Pero, no era que estábamos buscando que el beneficiado fuera el usuario final?

"¿Y por qué usan un modelo privativo?"

Y creo que alguien me dirá: "sí, la culpa la tienen ellos por seguir una comercialización a través de un modelo de software privativo".

¿Pero al final de cuentas, esto es ilegal? ¿el software privativo es ilegal? ¿no fuimos nosotros como consumidores los que pusimos a las empresas donde están ahora? ¿compramos sus productos porque nos servían o porque nos obligaban? ¿Qué nos impide, al existir actualmente nuevas alternativas, sacarlos de ahí? ¿al existir alternativas, nos pueden obligar?

¿Entonces, es necesario una ley que "obligue"?

Y vuelvo a repetir: ¿es justo que obliguemos a cambiar el modelo de negocio de las empresas? ¿no debería ser el mercado y los consumidores que obliguen a cambiar a las empresas?

¿O será que a unos pocos les conviene que esto sea así?

¿Verdaderamente los usuarios son libres dependiendo del Software Libre?

Y llegamos a un tema muy discutido: ¿poseer el código de forma libre,
nos hace a los usuarios ser "libres" ante nuestros proveedores? ¿o en la realidad, solo los proveedores pueden llegar a tener el conocimiento suficiente para llegar a obtener esta tan "vendida" libertad?

¿Verdaderamente los usuarios somos libres con el Software Libre? ¿o lo son los programadores que nos proveen de las soluciones que consumimos los usuarios (y que tal vez trabajen también con los proveedores)?

¿Llega verdaderamente esa "libertad" a los "usuarios no-programadores"?

El mercado está cambiando solo...

De todas formas, para que se queden tranquilos los "Talibanes del Software Libre" ;-), el mercado ya está "obligando" a cambiar a las empresas que proveen soluciones privativas: los clientes piden que se cumplan los "estándares", que exista verdadera "compatibilidad" e "integración" entre productos, no estar limitado a una sola plataforma, quieren productos "multiplataformas"... simplemente los usuarios están reclamando sus derechos pero a través de mecanismos "no violentos" (es decir, sin violentar los derechos de nadie) optando por el producto que los "libere de ataduras".

Concluyo con unas frases que me parecen muy reflexivas y que se pueden aplicar a nuestro "contexto" de autocrítica ;-):

"Un error no se convierte en verdad por el hecho de que todo el mundo crea en él." - Gandhi

"Cada vez que se encuentre usted del lado de la mayoría, es tiempo de hacer una pausa y reflexionar." - Mark Twain

Actualización (16/01/2006): estuve releyendo definiciones en Wikipedia y llego a la conclusión que tal vez la expresión correcta sería "Oligopolio del Software Libre", más que "Monopolio del Software Libre" (pero aún tengo mis reservas ;-).

"Fedora Core 5 incluirá Mono"

Publicado en Tux.cl (ellos se basan en osnews.com):

"La distribución Linux Fedora Core 5 incluirá Mono junto con algunas de sus aplicaciones estrellas como Beagle y F-Spot. Mono, proyecto auspiciado por Novell, provee todo el software necesario para desarrollar y ejecutar aplicaciones .NET en Linux."

Estuve viendo estas aplicaciones, y la verdad que parece que tienen futuro. Es la primera vez que me entero de su existencia, aunque creo haber visto en alguna presentación a Miguel de Icaza usando F-Spot (y es raro que las distribuciones no las incluyeran desde hace tiempo en su instalación).

Este es un buen ejemplo práctico del uso de la tecnología Mono para crear aplicaciones reales. Habría que probar de usar el IDE del proyecto e intentar crear una aplicación sencilla y evaluar el costo/beneficio de su desarrollo.

Si todavia no conoces este proyecto estas a tiempo de visitar la enciclopedia Wikipedia y conocer la historia del Proyecto Mono.