En primer lugar y hablando de la organización, esta se merece un 9 sobre 10. Tanto por su capacidad para actuar ante algunos imprevistos y situaciones debidas a mal entendidos, cómo por la eficencia en la organización de los voluntarios, sin embargo el hecho de no tener en cuenta ciertos factores, cómo el tráfico a la hora de calcular los horarios de los autobuses que pusieron a disposición de ponentes (y creo que voluntarios y asistentes) les hace perder puntos.

Sin embargo, y a pesar de ciertas pequeñas incidencias, me llevo muy buen recuerdo (y una caja grande de Guadalines v5 preview por si a alguien le interesa una), así como un pequeño proyecto que estoy estudiando como llevar a cabo (básicamente es un sistema de recuperación de claves o ficheros donde sea necesario disponer de al menos n partes del total para poder recuperarlo), así como un montón de contactos y amistades.

Respecto a mi charla, decir que esta ha sido la que más asistencia ha recibido de todas las que he dado (cosa que me ha gustado mucho), y que la organización me apoyó en todo momentointentando resolver las incidencias que pudiera presentarse. Gracias especiales a la gente de GalPon por prestarme una tarjeta de red PCMCIA ya que la mia se había roto.

Por otro lado decir que ha sido un placer conocer a tanta gente interesada en el Software Libre y hasta a un Evangelista de Microsoft (antiguo usuario de Debian :-/).

Lo último que quiero comentar, y no menos importante, es que ha sido un placer descubrir la gran base de usuarios de Kontinuidad Jabata que existe y haber podido recibir sus sugerencias. Seguid siendo así, este proyecto no podría existir sin vosotros.

Por mi parte ha sido un placer poder asistir a este evento.

Respecto a la Party de Silla poco puedo decir, tan genial como todas las partys pequeñas con un poco de experiencia. Seguid así chicos de SillNet.

Empecemos por plantearnos un par de cosas que, desde mi punto de vista, el Software Libre está haciendo mal:

Como imagino que todos vosotros sabéis, Microsoft no siempre ha dominado el mercado de los Sistemas Operativos. De hecho, incluso llego a distribuir un Unix en sus comienzos, conocido como Xenix  antes de comercializar MS-DOS.

¿Cúal ha sido el punto fuerte de Microsoft que le ha llevado a tal éxito en el mercado de los sobremesa?

Creo que eso es fácil de responder: sus pactos con las distribuidorasde software hicieron que sus programas viniesen preinstalados con la mayoría de máquinas y que los usuarios por desconocimiento, desidia, tiempo o dinero decidían mantener. Por supuesto, todo esto ocurrió antes de que saliese la primera Distribución de GNU/Linux, incluso, antes de que se iniciase el movimiento GNU (en 1983). En ese entonces, las empresas distribuidoras de hardware distribuían un S.O. (y algún otro software) con sus equipos. Por supuesto,  normalmente no solían crear su propio software sino que lo licenciaban de otras empresas, como Microsoft. El gran éxito de los sistemas operativos de Microsoft (y por ende de la estandarización de facto de su programario), se debe a los pactos con estas empresas y de hecho, pese a que los clónicos empiezan a venderse cada vez más, y no suelen llevar ningún software obligatorio incluido, la mayoría de usuarios principiantes suelen optar por un ordenador de marca que lleva Windows y otro software preinstalado lo que hace que sean del tipo encender y listo.

¿Qué podemos deducir de aquí? Creo que a la luz de estos datos resulta bastante evidente que una de las razones del éxito del programario de Microsoft ha sido sus pactos con los fabricantes de Hardware para que vendieran equipos con su sistema operativo preinstalado. Dada la situación actual, resulta evidente que la comunidad del SoftwareLibre, lo tiene difícil para hacer pactos con esos fabricantes, por supuesto esto no se aplica a aquellas empresas que venden sistemas GNU/Linux con soporte como Red Hat o Canonical, sin embargo puede aprovecharse de su principal ventaja, por venderlo junto con las máquinas los fabricantes no han de pagar licencia, aunque si los costes de desarrollo de drivers adecuados, y, amigos míos, ahí está el problema. Al parecer en muchos dispositivos los drivers suelen contener información que los fabricantes no quieren que se conozca y hacer drivers cerrados a causa de la licencia GPL está complicado requiriendo de sistemas que suelen incrementar mucho los costes de desarrollo o obligan a las empresas a liberar drivers libres. Si estuvieramos en una posición de poder, cómo Microsoft. podríamos hacerlo, sin embargo, debido a nuestra baja cuota de mercado a las empresas parece que les sale más a cuento no liberar drivers que liberarlos con todo lo que conlleva. Es por ello que si queremos ganar cuota de mercado, no sólo basta con hacer programas que se acerquen mucho a los programas propietarios para facilitar su uso a los usuarios más inexpertos o con menos tiempo. También tenemos que conseguir que los fabricantes distribuyan software y S.O. libres con sus equipos y para ello es muy importante minimizar sus gastos de implementación y desarrollo, empezando por los drivers, por lo que quizás fuera conveniente ofrecer APIs y módulos que faciliten la realización de drivers no libres, al menos, por ahora. De forma, que a las compañís les salga más rentable distribuir Software Libre con sus equipos que licenciar software privativo.

El otro tema  del que quiero hablar es de la famosa guerra de los navegadores. Cómo todos sabréis, una de las principales causas por las que se usa Internet Explorer pese a su calidad es que viene preinstalado en Windows. EnGNU/Linux normalmente el navegador preinstalado suele ser Mozilla Firefox excepto para las distribuciones basadas en KDE que suelen llevar konqueror. Esto implicaría que si de repente los ordenadores empezasen a llevar GNU/Linux preinstalado, IE perdería esta ventaja, con todo lo que conlleva. Sin embargo la salida de Chrome, así como la demostración que vi en la guadec me han hecho plantearme que posiblemente la sencillez de Webkit pueda suponer un problema. ¿Por qué? Supongamos que por ejemplo a mi me gustaría que las pestañas del navegador estuviesen debajo de la ventana, así que gracias a la sencillez de webkit programo un pequeño prototipo y le empìeza a gustar a la gente, esto (si sucediera las suficientes veces) fragmentaría las comunidades de usuarios de los otros navegadores y causaría que uno de los puntos fuertes de los navegadores libres, sus comunidades grandes y que mejoran estos y la experiencia de sus usuarios, desapareciera, y incluso haría que en caso de disponer de ella, la ventaja de la preinstalación también desapareciera, pues por ejemplo una distro basada en XFCE usaría probablemente uno de los navegadores diseñados para ese entorno de escritorio, y incluso a igualdad de escritorios es posible que el navegador preinstalado variase entre distribuciones.

¿Pretendes hacer saltar la alarma? No, de hecho este último planteamiento es una simple teoría. Sin embargo una disminución de la comunidad de desarrolladores debido a un aumento del mercado posiblemente hiciera que la robustez, rapidez de respuesta y buen soporte que tienen actualmente tienen los navegadores libres se minimizase e incluso desapareciera. Evidentemente Webkit es excelente y un gran aporte a la diversidad que favorece la filosodía del Software Libre, sin embargo me preocupa que aumente el número de productos en el mercado excesivamente con las pésimas consecuencias que ello podría acarrear.

For that, I’ll do my best to make a live video stream on the speeches and events I assist usingmy webcam. I know there may be a bit of lag between video and audio (that’s normal and hard to avoid). And that there will be a huge (around 5 to 15 seconds) lag on the video which I hope doesn’t disturbs you.

You’d be able to watch the video stream on:  http://giss.tv:8000/guadecunofficial.ogg I hope you enjoy it.

BTW: I want all the people going to guadec join our Key Signing Party, so… What are you waiting for? Join here!

UPDATE: Due to network instability is imposible to hold a stream anyway I’m recording the speeches and I’ll try to upload them later.

He cerrado una charla  en la guadec. En la que hablaré de streaming de vídeo usando gstreamer. Será viernes 12 de Julio a las 15:20.

También, he cerrado otra en la Hortanet Lan Party. En la que hablaré sobre streaming y emisoras por Internet. El horario de la misma aún lo he de cerrar.

Finalmente he cerrado otra en la Campus Party (shit you little parrot). En la que hablaré también de streaming y emisoras por Internet (y algo de video streaming).  En esta también queda por cerrar el horario.

Empezaremos por ver cual es la primera libertad del Software Libre: La libertad de uso.
La libertad de uso señala que todo el mundo es libre de usar dicho software de la forma que quiera (incluida imprimir los binarios y usarlos como papel de váter). Así que, si de verdad defiendes el Software Libre, entiende que cada cual es libre, por definición, de usar el programa de Software Libre que elija sin que por usar A o B tu tengas derecho a tratar de coartar su libertad para que use otro software.

En vez de esto, amigo mío, y dado que probablemente te pondrás a soltarle defectos del programa que usa a diestro y siniestro y ya que los conoces tan bien, colabora para corregirlos. ¿Cómo? Pues hay muchas maneras, para empezar y ya que sabes que ese programa tiene una serie de fallos y los conoces repórtalos usando su sistema de seguimiento de bugs. Incluso y en vez de gastar energías maldiciendo de dicho programa, y dado que es libre, aprovéchate de las libertades segunda y cuarta, analiza el código, mejóralo y publica las mejoras.

Es posible que por contra fueses a decir cosas positivas de tu programa. Antes de decir o escribir nada, cierra los ojos un momento y piensa: ¿de verdad las necesita? Es más, piensa: si ya están implementadas en el programa que iba a comentarle, ¿por qué no trato de portarlas a su programa?

Quizás, el problema es que nos cuesta pensar de forma constructiva, y eso probablemente sea una reminiscencia de cuando usábamos porgramas con código cerrado. Cuando usas código cerrado no tiene mucho sentido nada de lo que he dicho ya que si no puedes acceder al código fuente del programa no puedes mejorarlo, pero con el Software Libre es distinto; puedes mejorarlo y hacer casi cualquier cosa con él (incluida la ya comentada de imprimir binarios o fuentes y usarlas como papel de váter). Así que, en vez de desperdiciar esfuerzos en criticar, úsalos en mejorar.

Me despido dejándoos con esta reflexión ¿qué creéis que ve alguien que lee una ardiente discusión entre los usuarios de un programa y de otro?
Pues os lo adelantaré, o que los usuarios de ambos programas son radicales extremistas de mucho cuidado y mejor alejarse de ellos, y por tanto, del programa; o bien, que ambos programas son una basura y no merecen la pena, cosa que pasa especialmente si se usan críticas destructiva, cosa muy frecuente.

La verdad es que la experiencia me está siendo muy útil y divertida. Además he aprendido muchas cosas acerca de cómo actuar frente a un intento de FUD (Fear Uncertainty Doubt, o Miedo Incertidumbre y Duda). A continuación os las detallo.

• NUNCA uses argumentos Ad Hominem y mucho menos insultos. Te hacen quedar cuanto menos de radical y de cara a terceros no aportan argumentos válidos además de predisponerlos en contra de tus ideas. Resumiendo: simplemente con eso has perdido la discusión.
• Intenta ofrecer y citar fuentes que certifiquen lo que dices y exígeselas a aquel contra el que discutes. Normalmente la otra parte no los podrá ofrecer o las ofrecerá de poca fiabilidad lo que hará desconfiar a terceros de sus argumentos.
• Si estás muy cabreado relájate y escribe en otro momento.
• Recuerda, dirígete a la otra parte siempre con respeto y seriedad, nunca sabes que conocimientos puede tener esa otra parte de tí, ni mucho menos si sabe más que tú del tema que estáis discutiendo.
• Por mucho que ellos crítiquen destructivamente lo que tú defiendes, no caigas tan bajo de ponerte a críticar de la misma forma lo que la otra parte defiende. En cambio, indica , si puedes, lo que se está haciendo para solucionarlo. Y más importante, indica las cosas buenas que tiene aquello que defiendes. Si no lo haces así te arriesgas en entrar en una discusión en la que puedes salir perdiendo. Además eso te hará quedar mejor de cara a terceros.
• No hables de aquello que desconoces, si lo haces te arriesgas a no poder seguir la discusión y no poder seguir defendiendo tus ideas.
• No intentes desviar el tema de la discusión a menos que se haya vuelto demasiado tensa. La gente suele tender a perder la concentración en la discusión cuando esto se hace, y además puede quitarte credibilidad.
• Asume, que probablemente aquello que defiendes no sea lo mejor en todos lo casos. Uno de los mayores errores que se suele ver es la tendencia a la estereotipación y a la generalización arriesgándote a que te salgan con casos esquina en la discusión, o a perder credibilidad por parte de los terceros encajados en el estereotipo.
• No te preocupes si la otra parte no dispone de un canal bidireccional para la discusión. Siempre puedes hablar del tema en una entrada de tu blog y enlazar (o si es posible hacer un Trackback) a su artículo.
• No te quejes de la presencia de faltas ortográficas o gramáticas en sus artículos, ni mucho menos las corrijas, no por ello consigues demostrar que está equivocado y puede predisponer en contra tuya a algunas terceras personas.

Seguiré añadiendo más puntos más tarde, pero con eso ya tenéis algunas referencias.

Muchas veces, cuando usas entornos de escritorio en sistmeas GNU/Linux te encuentras con que hay aplicaciones “bonitas” y otras que tienen una apriencia más descuidada. Esto suele deberse a que cada una ha sido creada usando librerías distintas que representan los widgets (entendiendo por widget desde un cuadro de texto hasta una barra de desplazamiento), de formas distintas.
Este problema suele ser un problema “menor” de cara a la mayoría de usuarios experimentados, pero para un usuario que empieza pueden llegar a echarle atrás, lo curioso es que, por lo general, dichos widgets suelen ser similares, por no decir idénticos. En este caso, tengo una propuesta que pueden llegar a ser útil:
Cambiar el paradigma actual en el que las aplicaciones las que se encargan de dibujar los widgets y su contenido por otro en el cuál mediante un protocolo estándar (semejante al que existe actualmente para comunicarse con el servidor de las X) sea el sistema de escritorio el encargado de dibujar los mismos de acuerdo a las preferencias del usuario.
Dicho protocolo debería de poder ser extensible para la adición de nuevos widgets y debería ser decidido de forma consensuada por representante de los desarrolladores de los principales sistemas de escritorio y debería definir entre otras cosas los tipos de widgets existentes, sus parámetros y, de quererse retrocompatibilidad, una clase en versiones anteriores que ofrezca unas características semejantes. Esto sería semejante a los documentos que indican que puede esperar una aplicación de un gestor de ventanas que tan buenos resultados han dado y es un acercamiento al paradigma del HTML con hojas CSS en el cuál el código sólo se encarga de decir qué hay que dibujar y algunos atributos mientras que el CSS se encarga de decir cómo dibujarlo y el navegador lo dibuja. Con esto se lograría una uniformidad bastante buena en la visualización, y los desarrolladores de librerías para la generación de GUIs podrían centrarse en ofrecer una API más cómoda (o rápida) a los desarrolladores en vez de tratar de ofrecer nuevas características visuales que no necesariamente funcionaran de forma correcta en todos los sistemas de escritorio.

Otro problema que discutimos era la dificultad que tenían para comunicarse aplicaciones desarrolladas con librerías diferentes. Esto, por ejemplo, queda patente en la existencia de algunas aplicaciones que no pueden copiar o pegar a otras (entre otras cosas). En este caso y dado el sistema actual, la solución sería un sistema de capas, así en la capa superior estarían las aplicaciones, en la inferior el sistema de intercomunicación proveído por la librería, y en la última el entorno de intercomunicación de entornos. Este debería de nuevo ser definido por representantes de los desarrolladores de estos sistemas y ofrecer una forma unívoca de identificación de aplicaciones y una forma segura de trasmisión de datos entre aplicaciones que usasen una segunda capa distinta. De esta forma, cada cuál podría seguir usando internamente los sistemas de comunicación propios (por ejemplo el Gnome VFS) con las ventajas que conlleve su uso de cara a otras aplicaciones que usen el mismo sistema, pero garantizando una serie de servicios mínimos de cara al resto de aplicaciones.

Hay muchos otros temas que surgieron en la discusión, pero estos fueron los que más me llamaron la atención. Me despido recordándoos que protocolos cómo por ejemplo el HTTP usado para el envío de datos o el SMTP, usado para enviar e-mails, llevan años definidos y estandarizados y se han ido extendiendo conforme aumentaban las necesidades sin dejar de lados a las versiones anteriores, quizás por la suma de ambos factores estén tan extendidos a día de hoy. Así que recordad, usad estándares siempre que podáis, así conseguiréis unas aplicaciones más uniformes y agradables.

Todo empezó cuando yo iba a acudir a mi segunda Campus Party, ahí descubrí un proyecto conocido como Radio Campus al que me inscribí para encargarme de la parte técnica y sacarlo adelante. Entre muchas otras cosas, había que decidir la aplicación que se encargaría de controlar la emisión, en ese momento, surgieron dos alternativas: Kontinuidad Jabata y Soma. Un chcico, llamado ksys, que colabora en una radio libre de Barcelona comentó que ellos la usaban y que tenía bastante soporte de la comunidad española por lo que la decisión estaba tomada.

Conforme iba trabajando con ella y montándola me surgieron algunos problemas que corregí y cuyos parches envié a la lista. Allí me comentaron que el principal problema por el que pasaba el proyecto en ese momento era la falta de desarrolladores ya que el anterior desarrollador ya no tenía tanto tiempo para el mismo. Al principio rechacé la oferta, optando por hacer alguna contribución ocasional; pero tras algún tiempo, y al ver que durante el verano había dedicado bastante tiempo al proyecto decidí hacerme desarrollador de forma oficial y algún tiempo después tenía privilegios de acceso al CVS del proyecto. Así fue cómo me encontré con esta edición del CUSL, el año pasado quise participar pero no tenía suficientes conocimientos ni un proyecto, pero este año me decidí a participar con él. Y así fue como añadí soporte a alsa y me puse a mejorar Wjabata y la documentación del proyecto.

Sin embargo todo esto no hubiera sido posible si no hubiera llegado al proyecto Radio Campus originado por la gente que trabaja en Campuseros.net ni mucho menos de no haber sido por algunas campuseras que iniciaron el proyecto hace algún tiempo aunque no pudieron llevarlo a buen puerto y que se reúnen en su comunidad. Y a las que estoy muy agradecido.