Plugin flash en Ubuntu Gutsy

Gracias a las instrucciones del artículo Problema con Plugin de Flash en Firefox Ubuntu ya tengo mi instalación de gutsy con todo lo que necesito para empezar, bueno, me gusta youtube .

Descubriendo Ubuntu Gutsy

Como el código libre empieza por el sistema operativo he instalado Ubuntu Gutsy en el desktop.

No ha sido trivial, todavía hay cosas que son incómodas para un usuario custom, aunque la mayoría de esas cosas parecen ser por problemas de licencias y falta de drivers de los proveedores no por culpa del sistema operativo.

Una genialidad de Ubuntu es el   es el uso del gestor de paquetes synaptic synaptic; , que definiendo de forma adecuada los repositorios de software, es capaz de instalarte fácilmente un montón de aplicaciones.

Mi ejemplo de hoy:

Quería instalar MySql, para ello busque en google por: synaptic ubuntu gutsy mysql y me apareció como resultado de búsqueda:

Apache+MySql+PHP en ubuntu. Seguí los cuatro pasos de la receta y ya lo tengo funcionando como un reloj.

Una diferencia entre ser cliente o parte de la comunidad es la ayuda que recibes de los otros miembros. Encontrar soporte de un proveedor de forma rápida es más difícil.

Código libre por pragmatismo

Open source, Código libre…

Ya hace tiempo que programo en java. Una de las cosas que más me gusta es la cantidad de utilidades que hay hechas para el desarrollo. Esto permite crear aplicaciones muy potentes minimizando el esfuerzo.

Entre las utilidades, librerias, etc. que se pueden utilizar tenemos dos grandes grupos, las de código libre y las otras.

Hace tiempo trabajé en un laboratorio de software en el que desarrollábamos librerías java de gestión. Dentro de nuestras responsabilidades entraba diseño y programación de componentes, test, documentación, mantenimiento y soporte.

De lo anterior me encantaba el soporte en cliente, sobre todo visto desde mi posición actual.

La situación común era llegar allí en un ambiente complicado. El cliente te esperaba con una mezcla de esperanza y enfado, enfado porque se habían gastado un dinero en software que no les iba bien(ya fuera por desconocimiento de uso o por fallo del producto) y esperanza porque pensaban que lo ibas a arreglar todo.

Al llegar allí y ver la situación la forma de encontrar la solución acostumbraba a ser siempre la misma, depurar el código. Que obvio. ¿Sí?¿De verdad es tan obvio?

Nosotros no entregábamos los fuentes con nuestro producto, de hecho en un principio ni siquiera compilabamos los fuentes con información de debug. Esto hacía que cada vez que algún cliente tenía un problema no supiese si era error suyo al utilizar las librerías, bug del producto o problemas de entorno y cuando quería depurar encontraba una caja negra de la cual no era capaz de extraer ninguna información. En ese momento nos llamaban.

Al depurar su aplicación yo sí llevaba los fuentes. La caja negra se convertía en blanca, más todavía por ser una caja blanca hecha por uno mismo, y al poco tiempo el error se solucionaba. No siempre era error del software, la mayoría de veces era por mal uso de este, pero ese mal uso se identificaba de forma clara al depurar accediendo al fuente.

Así, después de semanas o meses con esa pega, se solucionaba en un par de días de soporte on-site. Estoy seguro que, de tener ellos el código fuente, podrían haber solucionado su problema en esas semanas de discusión con los diversos niveles de soporte.

Hace unos meses me pasó algo parecido pero desde el otro lado. Compramos una librería C para integrarla via JNI.

En poco tiempo localicé un par de errores y me puse a montar los test para verificar que eran errores de librería y no de uso, contacté con soporte, me enviaron preguntas, envié respuestas, me enviaron código, encontré errores, etc…

Al final, después de un par de semanas de correos cruzados, conseguí integrar asumiendo algún error que se quedó ahí pero evitandolo con programación cliente.

Estoy completamente convencido qué de haber tenido el código fuente hubiera arreglado todo en la mitad del tiempo y habiendo adquirido además los conocimientos para manejar un futuro error. No olvidemos que si falla algo en producción y hay que contar con soporte de terceros dependes del tiempo que estos terceros tengan para dedicarte. No esperes mucha colaboración si tu proyecto no es estratégico y tienen a toda su gente ocupada.

La conclusión después de todo este texto es: dadas dos librerías a utilizar, una de código libre(aunque no sea gratis) y otra no, sale más rentable a la larga utilizar la libre, aunque a priori sea de peor calidad que la otra. Además la podrás utilizar para que se ajuste exactamente a tus fines.