Esto no es un anuncio de un jabón. De hecho, quiero defender que, al menos cuando se trata de divulgar sobre Software Libre, mantengamos lo más posible nuestras manos sucias, por lo que el jabón no tiene lugar aquí. El Software Libre, aunque tiene una vertiente teórica o incluso estética –nos gusta–, no deja de tener como centro la informática, esto es, un tipo de ingeniería. No hablo aquí de títulos académicos oficiales, tampoco, ya que es evidente que no hace falta tener un título para usar ni para escribir sobre Software Libre, pero sí se requiere un conocimiento práctico técnico –”ingeniería”–; es decir, para poder escribir de Software Libre se requiere experiencia –no “experiencias”, porque en plural dicha palabra se refiere a sensaciones vividas– que sólo se puede adquirir mediante la práctica, el error repetido que lleva al acierto por aprendizaje tozudo por apasionado.

Dejadme que cuente la historia que lleva a que escriba esta entrada. Resulta que cuando monté el presente servidor, mi prioridad era “hacer que funcione”. Esto llevó a que configurara el servidor Apache de una manera un tanto primitiva, simplemente, porque no me di el trabajo de leer en profundidad sobre qué son ni cómo se configuran en él los llamados VirtualHosts. Mi prioridad era migrar el blog e instalar en él una serie de servicios que me interesaba tener el servidor. Claro, sin VirtualHosts, esos servicios acabaron “colgados” del dominio principal como subdirectorios en lugar de utilizar subdominios… Eso simplificó, por accidente, la gestión del HTTPS, pero afectaba a largo plazo la posibilidad de escalar los servicios o, por ejemplo, migrar alguno de ellos a un servidor diferente manteniendo la URL. Ahora bien, WordPress se encargaba de forzar una redirección del dominio principal a www.etccrond.es y una redirección ad hoc redirigía y forzaba que se utilizara HTTPS para los servicios que lo necesitaban.

Por curiosidad, una vez que todo se estabilizara después de unas semanas, me propuse organizar un subdominio para cada servicio, excepto este blog, que ha quedado en el dominio principal –los más avispados os habréis percatado de que la URL ya no lleva “www”–. Pues bien, no sé por qué –estas cosas pasan– entendí de forma incorrecta cómo se utilizaban los VirtualHosts y qué son los registros CNAME en DNS. Los dos errores me llevaban a callejones sin salida cada vez que intentaba hacer los cambios que quería. Sin embargo, llegó un momento en que con la ayuda de los compañeros Zagur de Portal Linux y Rubén Moreira, ensayos y errores, horas de lectura y horas de tocar todo lo tocable bajo el directorio /etc/apache2, dos neuronas en mi cerebro hicieron contacto sináptico y entendí la obviedad –obviedad ahora, no entonces– de que el VirtualHost es seleccionado por Apache mediante el atributo ServerName, que es el que se comprueba como una expresión regular comparándose con la petición HTTP, que el CNAME es lo mismo que un enlace simbólico en un sistema UNIX, pero que Apache tiene que conocer como ServerAlias, y que para crear subdominios “simplemente” debemos crear un VirtualHost para cada subdominio, con su ServerName y que cada subdominio debe ser registrado en DNS. Seguramente los más duchos en estas cosas estaréis sonriendo un poquito y pensando cómo puede ser que no supiera algo tan sencillo… para quien está constantemente con estas cosas. Sí, realmente es sencillo, pero me confundía que hubiera un VirtualHost llamado “predeterminado” que creía, equivocadamente, que era jerárquicamente superior al resto.

Ahora bien, seguramente era un poco imperdonable que montara un servidor sin estos conocimientos, pero una vez resuelto, al ver por la madrugada en que conseguí que funcionara, la sensación de satisfacción fue inigualable. La misma sensación la hemos tenido todos los que estamos metidos en cualquier afición técnica cuando hemos conseguido que algo funcionara. Uno acaba viendo el resultado con cierto orgullo por el trabajo bien hecho al tiempo que con cierta vergüenza por haber dado tantos tumbos sin rumbo para poder conseguirlo.

El ejemplo que he dado es uno de mi propia cosecha, pero bien sabéis cómo a lo largo de muchos episodios de su podcast o del mío el Cangrejo Linuxero y yo resumíamos nuestras batallas ¿contra? diversas aplicaciones, Jabber, etc., porque teníamos ganas de conseguir la combinación perfecta de mensajería privada, libre pero cómodo para “convertir” a amigos y familiares… un reto bastante ambicioso, como veis. Detrás de cada programa había horas de intentar hacer que las cosas funcionasen, algunas veces con éxito, otras no tanto, pero el aprendizaje era y sigue siendo constante y, al final, se torna incluso una especie de lucha por el orgullo de que un pedazo de código no nos va a ganar la partida. Gracias a ese tipo de indagaciones se aprenden mejor los conceptos de los que uno haya podido escuchar hablar e incluso se consigue formar el criterio para valorar una u otra tecnología como más adecuada para los objetivos que uno tenga: pienso por ejemplo en cómo acabamos descartando él y yo el uso de OTR en favor de OpenPGP porque necesitábamos algo independiente del cliente. Conocer la teoría es sencillo, pero aplicarla y entender dónde falla o cómo se debe complementar con otros conocimientos para que las csoas funcionen de verdad sólo es posible cuando uno profundiza hasta conseguirlo, pasen las horas que pasen, ocurran los fracasos que ocurran.

Esta es la gran fuerza motriz del Software Libre: el espíritu del hobby. Poder tener acceso al código y, además, la libertad total para hacer con él abre un océano de posibilidades insospechadas que trascienden el propio código: es difícil que un programa libre impida al usuario poder configurar a su gusto buena parte del funcionamiento del programa sin tener que tocar el código fuente. Esta transparencia y libertad también en el uso corriente, que es consecuencia de seguir la misma filosofía que llevó en primer término en publicar el código como Software Libre, permite que un usuario pruebe con cambiar algún parámetro para poner a punto el programa según sus necesidad y, cuando más de un usuario lo hace pruebas, de pronto nos encontramos con que alguno de ellos publica sus resultados en algún blog o alguna wiki que, luego, otro usuario podrá aprovechar para repetir el proceso o, como a veces me ha pasado, para “inspirarme” y conseguir vencer un problema o inconveniente de características similares.

Es natural, por tanto, que esté absolutamente en contra del llamado distrohopping. El saltar de una distribución a otra o, a un nivel más particular, de una aplicación a otra para cierta tarea da la sensación de que uno está aprendiendo, pero realmente no hay nada más lejos que la realidad. Echando mano de mi experiencia docente, puedo decir que el aprendizaje en general requiere una confrontación constante con problemas reales que deban ser resueltos para conseguir un objetivo más allá del objeto que se manipula, en este caso, el uso de un determinado sistema operativo. Es ahí cuando se demuestra que un sistema no es más que una herramienta, pero una herramienta siempre lo es para algo y la resolución de problemas prácticos es la esencia de la mente ingenieril, seamos o no ingenieros. No os engaño: yo mismo mantengo un par de máquinas virtuales para echar, de vez en cuando, una mirada a qué hacen las distribuciones en algún aspecto que me gusta consultar, pero de ninguna manera saltaría de distribución en distribución en mi sistema real de trabajo sólo por capricho. Las pocas veces que he cambiado lo he hecho porque algo en la distribución me provocaba un problema cuya solución o no llegaba a tiempo o no era satisfactoria o no existía.

El distrohopping no genera ningún conocimiento de verdad, más allá de clichés superficiales sobre cómo instalar una distribución –y hoy, ¿qué distribución es difícil de instalar salvo unas pocas?– y cómo mejorar su aspecto gráfico. El conocimiento sobre la instalación es útil, pero su aplicación, para quien usa el sistema para lo que tiene que ser utilizado, es absolutamente excepcional: normalmente uno busca instalar su sistema operativo la menor cantidad de veces posible. Así pues, quien salta de distribución en distribución se encuentra periódicamente con un sistema “recién nacido” y podrá ser un experto en esa puesta a punto inicial, pero de seguro abandonará el sistema antes de que la inercia del sistema en un uso real muestre algún problema real que solucionar de cuya solución la comunidad pudiera aprovecharse. Es, en cierta forma, un uso egoísta del Software Libre y un derroche de posibilidades de poder mejorar sistemas y aplicaciones informando de fallos que pasen más allá de la instalación, que, insisto, es absolutamente excepcional.

Lo que reivindico es el hobby. El ensuciarse las manos probando soluciones para problemas, no “probando cosas”. Lo primero encuentra su raíz en las ganas de aprender y lo segundo, en cambio, en una ludopatía irracional. Por supuesto, todos tenemos nuestros intereses y habrá quien querrá aprender más sobre redes que sobre programación y otros sobre cómo crear una mejor experiencia de usuario que sobre documentación técnica, pero lo que debemos grabarnos a fuego es que la libertad que nos ofrece el Software Libre está allí para ser utilizada. Si simplemente nos contentamos con un uso pasivo, la libertad no se irá, pero no crecerá ni servirá para nada más que como bonito adorno en la estantería.

 

Imagen: Jamie Buscemi’s bajo licencia CC-BY 2.0.

Fuente: etccrond

¿Quién está en línea?

Hay 18059 invitados y ningún miembro en línea