¿Cómo saber que estás listo para contribuir?

Hola a todos :) estos días he cumplido con varios logros personales y ciertamente me han dejado pensando un poco, así que quiero compartir con ustedes los resultados de mi divagar, además de responder de manera indirecta a algunos correos que me llegan al buzón cada cierto tiempo :)

Todos tenemos un principio

Esta es una anécdota que ya he contado en mi primer artículo, pero hasta el día de hoy me sigue impactando en esos momentos que me tomo para reflexionar sobre mi camino en el desarrollo de software. Cuando recién tenía Ubuntu en mi laptop, recuerdo un día haber estado en la biblioteca y haber querido actualizar mi computadora, nunca lo había hecho, pero no sé por qué en ese momento lo necesitaba… creo que había algo que quería instalar para un curso y no aparecía en los repositorios cuando se suponía que debía estar… todavía me acuerdo de la frustración que sentí y el desanimo con el que recorría las listas de resultados de google hasta que encontré la solución… me faltaba ejecutar el oscuro y misterioso comando:

sudo apt-get update

Evidentemente en ese tutorial seguía la línea:

sudo apt-get upgrade

al poco tiempo y leyendo en otros lugares había incluso visto :

sudo apt-get update && sudo apt-get upgrade

pero recuerdo curiosamente haber escrito:

sudo apt-get update && upgrade

pensando que de esa manera se ejecutaría lo mismo :) qué tiempos aquellos…

Todos tenemos más de un principio

Ahora en inevitable que llegue a mi mente el primer momento en que escuché de Kali Linux, ciertamente estaba maravillado por esto de la seguridad, había leído un post que trataba sobre descifrado de claves de redes inhalámbricas, me sentía todo un hacker al momento de ejecutar john.

Horas pasaron en el primer intento por descubrir la clave de una red WEP que se encontraba en las cercanías de mi tarteja de wifi… me llevó un buen tiempo descubrir que las listas de claves por defecto de john solo tenían palabras en inglés, algo que ciertamente no es muy útil en mi ciudad, y mucho menos en las cercanías de donde vivo…

Mi primer libro de ‘hacker’

Recuerdo con mucho cariño mi primer libro de hacker, ciertamente fue todo un desafío… primero porque en ese momento todavía no estaba acostumbrado a leer en inglés, segundo… y más importante aún, porque cada línea de texto me parecía chino mezclado con algún tipo de lenguaje alienígena. Para todos aquellos que se estén preguntando qué libro es ese… la respuesta está aquí :)

Y fue ese un punto interesante en mi camino de aprendizaje, porque ese fue el momento en que descubrí que no me gustaba usar Kali Linux sin saber qué estaba sucediendo a cada paso, ciertamente es interesante correr cosas como nmap o burp o mil y un herramientas más que vienen por defecto. Descubrí que quería saber por qué funcionaban, y cómo lo hacían. Desde ese momento dejé de practicar con las herramientas de Kali y empecé a leer sobre lenguajes de programación.

Y volvimos al primer instante donde todo parecía chino alienígena :) ciertamente entendía poco o nada de lo que leía, y al mismo tiempo seguía y seguía, devorando información en cada rincón de internet a más no poder… evidentemente me preocupaba por conseguir la mejor fuente posible para llenarme de información.

Entrar en lo profundo

Pasó un poco de tiempo y ya estaba en Gentoo, y me llamaba mucho la curiosidad de muchas cosas, y con el pasar de los días aprendía mucho sobre compilación y sobre construcción, y sobre seguridad, y sobre muchas cosas. Pero evidentemente al principio, como en todas las experiencias previas, sentía que leía chino alienígena.

¿Por qué cuento esto?

Pues porque estos días empecé a mandar mis primeros parches (cosas bastante pequeñas) a la comunidad del kernel, hacía mucho tiempo había escuchado que era una comunidad de comentarios despiadados, que no eran el lugar para un novato en el mundo FOSS, que era muy selectivos con lo que se aplicaba y ¿saben lo que he descubierto? que no es nada de eso, si conoces las reglas :)

Ya en otro momento hablamos sobre el entrar a casa a ajena, y no respetar las reglas de casa… evidentemente me ha tomado tiempo aprender estas reglas, aprender a usar git lo suficientemente bien como para mandar un parche adecuadamente, aprender a usar un software de análisis estático de código, aprender a revisar mis trabajos con detenimiento, aprender a comunicarme con la comunidad, aprender a usar vim, aprender C… y sí, al principio todo puede parecer chino alienígena, pero conforme van pasando los días, todo esto cobra sentido y te das cuenta de cuánto has avanzado y cuánto has aprendido.

Hoy

Hoy conozco más comandos y formas de actualizar un sistema de las que podría haber imaginado, lo mismo que hoy conozco y domino en cierta medida el flujo de trabajo colaborativo en una comunidad… hoy leo aquellas páginas (o incluso algunas más complicadas) y no me pierdo en el camino…

Mañana

Si hablamos de mañana… pues todavía hay mucho que quiero aprender, quiero conocer nuevas tecnologías, quiero dominar nuevos lenguajes, quiero construir nuevas comunidades, quiero enseñar a más personas, y probablemente pasará lo que ha pasado en cada primer paso de mi descubrir tecnológico… que no voy a entender nada al principio :) y a esto quería llegar con tantas palabras, mucho se habla de la zona de confort, yo creo que ese es el lugar a donde llegan todos aquellos que creen que han dominado algo… porque tan solo creer que lo has dominado, es ciertamente motivo y razón suficiente para descubrir que te equivocas, y que todavía te falta mucho por recorrer. Al principio tal vez no entiendas, tal vez te equivoques, tal vez incluso quieras tirar la toalla, pero todo eso es necesario para no llegar jamás a la zona de confort, porque si solo haces lo que conoces, ¿qué más confortable que eso?

Este lo dejo hasta aquí porque solo es una pequeña opinión… no quiero que piensen que sé más de lo que en realidad sé, lo poco que he aprendido es porque me he dado el trabajo de nunca estar en una zona de confort por tiempo suficiente como para creer que “domino” algún tema :) y para los que me preguntan que cuándo estarán listos para colaborar en un proyecto o comunidad, pues la respuesta es sencilla…

Si te sientes listo, ya estás tarde.

Gran parte de la aventura está en descubrir cosas :) si ya todo lo conoces y dominas, todo pierde sentido :) es por esto que disfruto tanto aprendiendo sobre GNU/Linux, porque es un mundo que no parece acabar. Cierto es que puedes dedicarte a hacer la misma labor por muchos días o años sin crecer, pero también es cierto que puedes hacer una labor sin dominarla, pero aprendiendo mucho cada día :) Gracias a los que lleguen hasta aquí, y saludos y cuidado con su zona de confort

El 80/20 también afecta la programación

Todos hemos oído sobre la regla del 80/20, aquella que dice que el 80% de nuestro éxito (efectos) proviene tan solo del 20% de nuestras acciones (causas). Pues bien, esta universal verdad también afecta al desarrollo de software, y en este artículo vamos a desgranar un poco de los fundamentos de esta afirmación.

BPM

Business Process Managment, por su siglas en inglés, es una disciplina de gestión (entre otras cosas) que permite comprender de manera visual los procesos que deben realizarse en un negocio (o en muchos otros lugares). Entre sus cualidades principales está el hecho de poder analizar procesos complejos y hacerlos “simples”.

Existen muchas herramientas open source que permiten desarrollar diagramas BPM, la que yo he usado para este artículo es BonitaSoft. Si desean aprender un poco más sobre la gestión de procesos existen muchos tutoriales en internet y libros referentes al tema. Ahora volvamos al tema central.

Proyectos de software

Hoy en día existen muchas metodologías para desarrollar proyectos, están las ágiles, las tradicionales, las mixtas, etc, etc. Un punto que todas tienen en común es la preparación. ¿Qué quiero decir con esto? Que el 80% de tu éxito en este proyecto de software se basará en el primer 20% de todo el proceso, la preparación. 

La preparación de un proyecto

Esto es algo lógico que en la realidad se aplica muy poco (como muchas otras cosas lógicas que son ilógicas en la práctica). Cuando hablamos de preparación debemos entender la capacidad de comprender el problema, entender la solución y sobre todo, el proceso que la solución aplica. Una de las cosas que menos se encuentran en proyectos de software poco profesionales es la falta de documentación sobre dicho tema. Esto normalmente aparece en empresas privadas puesto que el deseo de vender supera al proceso de creación.

Como muchos de los que leen estos artículos trabajan o están relacionados con la tecnología, no está de más mencionar que si en algún momento de sus vidas laborales se encuentran con una empresa/proveedor que no cumple con una buena preparación, es casi 80% seguro :P que el proyecto no va a salir bien.

La abstracción es la clave

Esto es algo que he aprendido de mi tiempo usando GNU/Linux, y que demuestra una y otra vez ser clave en el proceso de creación de software. La capacidad de abstraer problemas para convertirlos en cosas más “simples” es vital para poder generar código elegante, y sobre todo duradero. Y tal vez esta es una de las principales diferencias de los grandes proyectos profesionales y los proyectos que crecen sin control alguno. Los primeros piensan, comprenden y estructuran el proceso mientras que los segundos lo mantienen funcionando sin necesidad de entenderlo.

Stager

Este es el nombre del proyecto que desarrolla el instalador de Gentoo, como pueden imaginar, este es un proceso bastante complejo, puesto que soporta una gran cantidad de arquitecturas. Otro factor a tener en cuenta es la cantidad de configuraciones que soporta, a nivel de kernel, init system, etc. Y les cuento todo esto porque además es mi proyecto de tesis, el cual debo acabar antes de terminar de estudiar. Evidentemente no puedo hacer un programa que contemple absolutamente todas las opciones posibles en tan poco tiempo ( hasta julio del próximo año), pero al menos puedo generar uno que permita instalar de manera muy básica un sistema funcional.

Entendiendo el proceso de instalación

Gracias a las herramientas de BPM, se puede generar un diagrama de proceso que nos permite entender los pasos necesarios para la instalación exitosa de Gentoo en un equipo.

proceso de instalación de Gentoo
Diseño propio. Christopher Díaz Riveros

A pesar de contener varios procesos y subprocesos, evidentemente se ha resumido bastante y se puede apreciar que contamos con 18 pasos lineales. Esto es importante porque una aplicación que cuenta con una estructura lineal es sencilla de implementar, y al mismo tiempo se puede generar paralelismo en alguno o varios de los subprocesos en caso de ser necesario.

Otro factor importante es que nos permite abstraer conjuntos de procesos por tipo, por ejemplo, definir un subproceso kernel nos permite saber que existen tareas específicas dentro del mismo que están directamente relacionadas con el proceso de instalación de un kernel de manera exitosa.

Sub-proceso "kernel"
Diseño propio. Christopher Díaz Riveros

De esta manera cada paso “complejo” se convierte en uno “simple” de manera global, sin perder los detalles necesarios. Esto facilita la visibilidad del conjunto sin disminuir el nivel de especificación necesario para cumplir el proceso de manera exitosa. Y tampoco podemos negar que es más sencillo ver la imagen que leer todo el Handbook de golpe :)

Ahorra tiempo

Otra ventaja evidente es que al no contar con un lenguaje de programación directamente conectado, es posible realizar el análisis de la lógica sin necesariamente perder tiempo en la implementación del lenguaje. Esto es una ventaja comparado con la cantidad de tiempo que se puede invertir en implementar una funcionalidad para al final descubrir que va a ser descartada porque existe una solución más eficiente. Como lo que serían las soluciones en pseudo-código (algo que también es ignorado por muchos “desarrolladores” pero que no debería serlo).

Dirigir proyectos se hace fácil

Teniendo en cuenta estos conceptos, la dirección de proyectos (de cualquier índole) se hace más sencilla, porque enfocamos los esfuerzos donde realmente son necesarios, y si esta parte es hecha de manera correcta, el resto cae por su propio peso. Espero que les ayude a la curiosidad y los motive a investigar sobre el BPM, la algoritmia y quién sabe, tal vez los anime a ayudarme con mi tesis :P Muchas gracias por llegar hasta aquí y ya nos estamos viendo pronto. Saludos

 

Nuestro primer mes juntos :)

Este es un pequeño artículo de celebración puesto que ya llevamos compartiendo un mes en la comunidad :) No necesito plantear un tema muy elaborado y lo dejaré en pequeñas reflexiones y tal vez comentarios, así que sin más que agregar, empecemos: :)

El primer paso siempre es el más difícil

Las dudas

Esto es algo con lo que quiero comenzar :) a decir verdad siempre es complicado dar el primer paso en algo, recuerdo mucho el primer mail que mandé a Gentoo, pidiendo entrar al equipo de seguridad. Al principio pensaba… ¿Cómo voy a poder ayudar YO a todas estas personas inteligentes y hábiles? o ¿Acaso estaré a la “altura” de la comunidad? o Tal vez no pueda comunicarme bien con ellos o no los entienda… o mil y un cosas más que pueden venir a la mente :)

La realidad

Pero la realidad es que no es gente de otro mundo no muerden ni atacan de la nada (alguno que otro será un poco gruñón :P pero sucede en todo lugar :) ). Esto me recuerda que aquel mail lo mandé pero no empecé a participar hasta como mes y medio después, esto debido a que tenía otros pendientes y tal vez involuntariamente lo estaba aplazando.

El siguiente paso

Tal vez esta bella experiencia de aprendizaje hizo mucho más sencillo el atreverme a fundar CodeLabora, comenzar a participar en Git, empezar a escribir aquí :) y muchas cosas más, puesto que al tener la confianza de que YO tenía algo de valor para compartir, era más sencillo poder iniciar nuevos proyectos.

Ahora ustedes

Pero ¿por qué les comento esto? Pues porque si yo pude, ustedes también pueden :) no niego que implica tiempo, dedicación, y uno que otro error por ahí (no tantos si somos cuidadosos) pero la sensación de aportar algo al mundo entero es sumamente gratificante :) y espero que esto anime a más de uno a empezar a colaborar en su comunidad/instituto/universidad/trabajo/etc…

Así que, no importa si no sabes mucho, incluso si no sabes nada sobre un tema :) participar es la mejor forma de aprender, y estar en comunidad te ayuda a aprender de aquellos que ya cruzaron el camino y descubrieron los caminos seguros :) Eso es un poco de lo que trata CodeLabora (alguno que otro me ha mandado correso al respecto) y es un lugar donde se puede compartir experiencias :)

Ser autodidacta es lo mejor que existe

Esto va para los más jóvenes (jeje me siento viejo diciendo esto porque yo también soy jóven :P ), pero es una de las lecciones más importantes que he aprendido en mi vida como desarrollador.

El instituto/universidad/colegio es el punto de partida

NUNCA crean que lo que les enseña el instituto/universidad/… es suficiente. Hace poco leía un artículo que desmitificaba un poco aquellos elevados sueldos de desarrollador en USA. Y es cierto que solamente en Silicon Valley pueden darse el lujo de pagar esos elevados salarios, pero no es un lujo que viene gratis. Saber usar un framework o una librería no te va a poner en el nivel de un trabajo así. Y esto es algo que a mi me mueve bastante al momento de aprender cosas

Aprende a crear GNU/Linux no solo usar GNU/Linux

Existe el ya acuñado término “superusuario” (no me refiero al root). Según este, los superusuarios son aquellos administradores/desarrolladores/usuarios que no solamente son capaces de usar de manera correcta las herramientas, sino que también son capaces de crearlas o modificarlas de acuerdo a las circunstancias.

Y es que eso aplica a cualquier lenguaje/framework/herramienta del planeta. Ser dependiente de algo/alguien por la pereza de no entenderlo es uno de los mayores males que nos podemos hacer los que trabajamos o usamos tecnología hoy en día. Esto no aplica a cosas de las que puedes depender porque de no hacerlo sería algo sumamente complicado o consumiría mucho tiempo de crear.

La zona de confort

Este seguro será un punto que lanzará uno que otro comentario de “corrección”, pero hay que admitirlo, la zona de confort es muy confortable :) y hay gente que se “estanca” en el mismo uso o tecnología por años, sin aprender algo nuevo cada día (yo también tengo mis temporadas en las que no quiero aprender más, es normal), pero la idea es siempre estar pendiente para poder evitar que ese “estancamiento” dure por mucho tiempo.

No importa de dónde vengas, sino cuán duro trabajes

Esto es algo que me gustaría recalcar, porque yo entiendo que muchos dirán que la universidad/institución de la que egresas es importante, pero es solo una parte pequeña comparada con todo el trabajo que uno debe realizar para poder ser alguien en el mundo. Y con esto no desprestigio a las entidades, sino que aliento a las personas que todavía estudian a demostrar que no necesitan un título del MIT para poder brillar a nivel tecnológico :)

Tú eres capaz de cambiar el mundo

Empieza siempre tendiendo tu cama

Este es un video que me emociona mucho, no solo por su contenido, sino por lo que representa en mi vida. Yo intento (no siempre me funciona :P ) tener todos los días mi cama al despertar, lo que no sucede nunca es que al final del día sigue destendida, pero es un hábito que he adquirido con el tiempo. Sumamente recomendable ver el video de principio a fin :)

Tu representas a la comunidad

Esto lo aprendí hace mucho, pero lo he reforzado en Gentoo con el pasar de las semanas. Recuerden siempre que ustedes representan a su comunidad, yo hoy por hoy represento a Gentoo, represento a Perú, represento a CodeLabora, y a muchas otras personas y lugares que la lista sería muy larga para comentar ahora, pero una cosa es clara:

Siempre, sin importar donde esté, debo pensar que no soy solo yo el que se afecta por mis palabras o acciones.

Recuerden siempre que lo que escriben o dicen queda guardado por mucho tiempo, y todo debe ser dicho y hecho como para que después de haber pasado toda una vida, uno pueda seguir orgulloso de dicha acción o palabra :) Esto espero que ayude a muchos en el futuro y en el presente :)

Reflexión final

Este artículo intentaré mantenerlo corto, y pues a pesar de que me gustaría compartir muchas más cosas, creo que esto es suficiente por hoy. Solo me queda agradecer a cada uno de ustedes, por darse el tiempo de leer, compartir, comentar estas pequeñas contribuciones al mundo FOSS, intento siempre responder a los mensajes y también intento no dejar dudas en lo que digo en caso de necesitar se aclaradas. Así que si gustan comentar, compartir, corregir, sientanse totalmente libres de hacerlo :) y gracias por este gran tiempo juntos, espeor que siga así durante mucho más ;) Saludos

Holy wars: Uno de los mayores problemas *NIX

Hay un tema del que no he podido escapar en todo mi tiempo saltando entre distribuciones, escogiendo programas, programando, incluso leyendo en o sobre todo lo relacionado a Linux o UNIX… Las Guerras Santas (Holy Wars en su más conocido término).

¿La primer guerra santa?

Bueno, el término fue oficialmente popularizado por Danny Cohen en un artículo sobre endianness, más específicamente sobre las controversias entre el formato little-endian vs el big-endian. Para los más curiosos, la endianness especifíca el orden en el que los bytes son leídos, cada uno representa una filosofía dinstinta y por este mismo motivo, son imcompatibles por definición. Esto divide el mundo de los procesadores en dos y genera pequeños satélites llamados middle-endian, usado basntante en tecnologías ARM y otras, los cuales pueden leer ambos formatos.

Otros grandes ejemplos

Dentro de los más grandes ejemplos de la actualidad tenemos el eterno combate entre GNOME y KDE, la ya antigua rivalidad entre vim y emacs, e incluso a nivel de sistema operativo, la no tan conocida rivalidad entre Linux y [Free|Net|Open]BSD. Estos son algunos de los ejemplos, que han sido motivo de incontables posts, artículos, tésis, incluso libros. Recuerdo mucho un Libro de O’Reilly sobre Bash que  fue escrito por algún seguidor de emacs, esto es evidente por algunos comentarios típicos contra vim, como la falta de “naturalidad” en el uso de sus accesos de teclado. En fin, la cantidad de información es abundante en estos temas.

La espada de doble filo

La historia nos ha mostrado que incluso de las rivalidades más encarnizadas nacen cosas buenas, una de estas es el avance tecnológico. Mucho se ha hablado sobre la ruptura de C y C++, algunos llamando “puritanos” a los otros y diciendo mi lenguaje es mejor. Aunque en cierto punto de la historia C++ utilizó C como base para crear nuevas funcinalidades (estamos hablando de aproximadamente 30 años atrás) hoy por hoy, ambos lenguajes han evolucionado tanto que se podrían considerar dos totalmente distintos, y cabe mencionar que con casi las mismas funcionalidades en ambas partes. Por otro lado tenemos la evolución visual de algunos Frameworks como Qt o WebKit, utilizados abuntantemente en KDE y GNOME respectivamente. Esta “competencia” ayuda a ambos a mantenerse despiertos y mejorar cada día las funcionalidades que ofrecen.

En el nivel técnico

Pues cuando vemos esto desde un punto de vista totalmente técnico, las opciones pueden volverse “objetivamente” mejores o peores, y es que esto es una realidad tangible, uno puede describir un software o programa en cuanto a medidas de tiempo, o de carga, o de estrés, o cualquier otra imaginable. Esto ayuda a las decisiones de cada individuo, puesto que da fuerza a los argumentos, y puede esclarecer mejor las necesidades que se necesitan cubrir, y los riesgos que se deben tolerar. En este punto las cosas son un poco más claras y si se llevan de una manera cordial, pueden resolver muchos conflictos, pero el problema surge cuando…

La política entra en juego

Este es un punto sensible, así que intentaré no dar muchas vueltas al asunto. Todo es bueno hasta el punto en el que comienzan los extremos, cuando empiezas a creer que tu solución es simplemente mejor que cualquier otra y todo el mundo debería estar de acuerdo contigo. Este es posiblemente uno de los puntos más complicados de todo el Open Source, e incluso del Software Libre.

Yo he tenido oportunidad de conversar directamente con ambos grupos, y a decir verdad ambos se encuentran bastante politizados, al punto de decirme: “Si te vas con ellos, no vengas con nosotros”. Y es que para su concepción de la vida, solo existe el negro o el blanco, ningún punto medio o gris. Ahora muchos estarán de acuerdo conmigo y otros no tanto, pero la vida no es solo blanco y negro, existen el gris y los matices (incluso en cosas en las que no deberían existir, pero es inevitable).

Lo gracioso de todo esto es que los que “dirigen” estos grupos, al menos los que he tenido la posibilidad de conocer, no programan, y piensan que el ideal del software va tan más allá del mismo software, que la programación ha quedado marginada en el olvido.

Mi opinión personal en este tema

Solo voy a hacer una acotación a lo que yo considero importante del software libre y el open source, ciertamente ambos tienen muchos puntos en común, pero difieren tanto en aquellos que no son comunes,  que no deja de ser motivo de disputa para ambos bandos.

Yo creo que en el mundo de hoy, el software privativo (aquél que te impide la libertad esencial de poder pensaraprender) es el mayor enemigo. A mi siempre me ha gustado saber por qué suceden las cosas en mi computadora, y considero que un programa que no te permite conocer lo que sucede es el mayor enemigo que puedes tener.

En este punto el Open Source y el Software Libre concuerdan (aunque no lo quieran admitir), y es que uno por motivos prácticos y el otro por motivos éticos, desean que los usuarios sean capaces de contribuir y aprender del código fuente.

El punto donde empieza el problema es respecto a la libertad de distribución. El Open Source es un poco más restrictivo que el Software Libre, este es el punto de partida para muchos conflictos de filosofías. Pero yo lo veo de la siguiente manera:

En este mundo el negro viene a ser el software privativo, aquel que no te permite conocer realmente lo que sucede, ni por qué sucede. En un punto más gris, tenemos al Open Source, el cual no te entrega todas las libertades  pero al menos te permite tener el código a disposición para aprender y mejorar. El lado blanco vendría a ser el software libre, por contar con ideales más éticos en los que el software tiene que estar a disposición de la comunidad y ayudar a todos sin esperar beneficios a cambio.

La utopía

Si todos fueran como el blanco, pues no habría necesidad de dinero, pero tal vez las cosas serían muy distintas por lo que la gente solo trabajaría por vocación, y no por necesidad. En este punto es donde se confirma la existencia de grises en nuestras vidas, si bien uno puede ayudar al mundo con proyectos Libres, el mundo no por eso va a dejar de exigirte todo lo que exige siempre.

Esto suena muy bueno, pero la verdad es que todos necesitamos dinero en este mundo, y aunque el software libre pueda ser lo más blanco que se pueda encontrar, siempre existirán los negros dominando no solo el mercado, sino también las mentes de los consumidores. Y siempre existirán deudas con el Estado, y cualquier otro tipo de cosas que te obliguen a necesitar dinero.

Gentoo

Este es uno de los puntos que más me gustan de Gentoo, la capacidad de elegir. Esto no solamente implica poder elegir software, sino que también enseña a pensar por uno mismo. Y como en todo lugar, también existe política, y bandos, y demás. Pero lo bueno es que siempre existe la libertad de elegir, en especial cuando alguno de los bandos no sigue tu forma de pensar. (Tenía que meter esto aquí porque como habrán visto, una gran parte del FOSS (Free and Open Source Software) trata de filosofías.

Reflexión final

Las filosofías son buenas, ayudan a resolver problemas mediante nuevas perspectivas. Esto es algo que siempre será útil para todo el mundo, pero el problema comienza cuando un grupo desea imponer su filosofía. Nunca es bueno decir “esto es mejor” como se ha visto mucho en el mundo Linux, con el típico:

Ubuntu/Fedora/Mint/Manjaro/… es mejor que Ubuntu/Fedora/Mint/Manjaro/…

No existen mejores absolutos, simplemente siguen distintas filosofías.

Yo me considero alguien bastante tolerante en el tema, me he acostumbrado a creer que nada puede ser absolutamente bueno o malo cuando viene de alguna persona. Todo tiene matices y yo me siento inclinado a compartir las cosas que yo considero útiles. No pretendo hacer que todo el mundo me siga en mi forma de ver y usar la tecnología, pero soy consciente que no muchos usan o prueban las cosas que yo uso, así que intento compartir eso para que otros puedan tener un punto de referencia al respecto :)

Ya me he extendido mucho esta vez, pero me pareció un tema bastante interesante para tratar. Saludos,

¿Por qué preferimos la línea de comandos a los GUIs?

Revisando otros artículos me topé con esta pequeña pregunta que me causó mucha gracia, es verdad que una de las primeras cosas que nos sacan en cara usuarios de otros sistemas (excepto FreeBSD) es que no usamos los GUIs. A decir verdad, a mi también me pareció bastante curioso al principio de mi viaje por GNU/Linux. Debo admitir que con el pasar del tiempo, ahora utilizo mucho más la línea de comandos que cualquier otro programa con GUI, y muchas veces prefiero programas dentro de la línea de comando a programas más elaborados con GUIs deslumbrantes.

El mito

En realidad esto no es más que un mito urbano, pues a diferencia de otros sistemas cuyos nombres no serán mencionados aquí, es en GNU/Linux donde realmente tienes libertad de elección. Ya quisiera que en otros sistemas existiera la versatilidad que existe aquí. Pero veamos en más profundidad este asunto, que sino no quedan claras muchas cosas:

Servidores

Todos hemos oído de la palabra Servidor, algunos creen que son esas super computadoras que alimentan Google o Amazon, o la que está en tu empresa. Pero la realidad es que un Servidor responde a un modelo de trabajo. Usamos este término para hacer referencia a que tenemos un programa que está a disposición de los usuarios (clientes) y les entrega algo. Un ejemplo básico es Apache, el cual se usa para servir páginas web en internet. Este programa entrega html a los clientes que lo soliciten.

Servidor de imágenes

Pero no solamente un servidor puede estar en las super computadoras que hacen posible Google y otras muchas empresas, incluso la laptop más “antigua” puede ser un servidor, de manera especial cuando hablamos de imágenes. Todos corremos un servidor de imágenes en nuestras laptops para poder tener una pantalla funcional, en este caso el servidor y el cliente son la misma persona. El ejemplo más común es X (conocido como xorg-server en muchas distribuciones) y su nuevo reemplazo Wayland. No vamos a dar una explicación detallada de por qué el org, o cómo es que Wayland funciona, o las filosofías que existen atrás de estos grandes proyectos, pero si vamos a dejar claro que es gracias a ellos que nosotros podemos contar con un navegador web como Firefox o Chrome, o muchos otros programas.

Gestor de ventanas

Los gestores de ventanas trabajan directamente con el servidor de imagen, su trabajo es de un nivel más “bajo”, puesto que gestionan (valga la redundancia) cómo es que se crean, modifican, cierran las ventanas. Suelen ser bastante simples y sobre estos se construyen los entornos de escritorio. La lista es grande, pero solo dejaré aquí la idea de que son softwares minimalistas, los cuales permiten tener un control bastante básico del servidor de imagenes.

Entorno de escritorio

Un conjunto más especializado de software que permite no solamente un funcionamiento del servidor de imagen, sino también proporcionan capacidades de personalización. Dentro de estos los más antiguos y pesados son KDE y GNOME, pero también tenemos entornos más ligeros como LXDE o Mate, Cinnamon, etc.

CLI (Command Line Interface)

Tras un breve repaso por el mundo de los servidores de imágenes, ahora nos centramos nuevamente en nuestro tema. CLI, implica todo aquel programa que se ejecuta por línea de comando, ya sea git, vim, weechat, o bueno, cualquier otro que se les venga a la mente. Pueden apreciar que estoy hablando de programas que si bien se ejecutan en la línea de comando, muestran una especie de “interfaz gráfica” como weechat o vim. Para todos los que no los hayan probado, se los recomiendo, son básicamente los que uso todo el día.

Por qué CLI es mejor que GUI

Intentemos algo bastante sencillo :) El otro día quería trabajar en un parche para Portage (el gestor de paquetes de Gentoo). Como todo buen proyecto colaborativo, la cantidad de líneas de código supera los 70k. Intenten abrir eso en un IDE como NinjaIDE (Portage está escrito en Python) y no tardarán en notar que en lo que empieza a cargar la pantalla, su máquina se pone sumamente lenta (al menos mi i7 si lo hacía) y esto solamente tratando de abrir el código y cambiar al color por defecto de “ayuda”.

Ahora intenten hacer lo mismo con vim, a mi me cargó en cuestión de milésimas de segundo, y al mismo tiempo que ponía los colores “bonitos” y todo lo demás.

CLI ha estado mucho antes

Algunos aquí dirán que esos programas son antiguos, yo los llamo robustos. Si pudiesen ver la cantidad de horas invertidas en construir emacs, vim, gdb, y otros cientos de programas para consola, podrán notar que la cantidad de código y funcionalidades es tan grande que practicamente ya han solucionado todo lo que necesitaban solucionar. Muchos GUI para programas que ya son robustos en su CLI jamás tendrán la misma cantidad de funcionalidades, esto sencillamente porque si hicieramos una pestaña para cada subcomando disponible de por ejemplo git, nos perderíamos entre las opciones y sería contraproducente, porque haría difícil el trabajar.

CLI es más rápido

La mágia comienza con la tecla Tab, esta no solamente es tu mejor amiga al momento de navegar por los escritorios en tu terminal, sino que cuando está bien configurada, te permite acortar sentencias largas a 2 letras y un Tab, 3 letras y un Tab, o incluso una letra y un Tab.

Pero esta no es la única ventaja, los que hemos tomado el tiempo de aprender vim o emacs podemos decir que aunque la curva de aprendizaje sea un poco mayor a la de los IDE de estos días, al final los resultados de productividad son asombrosos, uno no se imagina el tiempo que puede perderse al mover un mouse. El tener las manos en el teclado el 90% del tiempo no solo enseña concentración, además, el hecho de escribir tanto en el teclado te hace bastante ágil y productivo. Y ahora volvemos al punto anterior, al llevar tanto tiempo con nosotros, programas como estos ya cuentan con todas las funcionalidades que se le puedan ocurrir a alguien, un dicho bastante común para los que usamos vim me viene a la mente:

Si usas más de 4 teclas, puede haber una forma mejor.

Sencillo pero poderoso, vim te permite hacer todo con la gran cantidad de teclas y combinaciones posibles, uno nunca deja de aprender, pero no deja de ser verdad también que para poder usarlo no es necesario saberlas todas, bastan unas 10 o 15 para empezar a ser más productivo.

CLI te da el control absoluto

Cuando uno ejecuta operaciones con el mouse, o programas desde el servidor de imágenes, no siempre se tienen presente todas las configuraciones extra que se ejecutan al momento de dar click, esto no sucede con la terminal, aquí tu tienes el poder absoluto de lo que se ejecuta o no, con qué opción o hasta qué punto. Con el tiempo te vas dando cuenta que necesitas menos de lo que piensas, y eso te ayuda a hacer las cosas de forma más centrada.

GUI también tiene lo suyo

No voy a decir que todos deberíamos usar CLI siempre, eso tampoco es lo ideal, yo mismo uso GUIs casi todo el tiempo, para escribir este post estoy usando mi Chrome, y para ver mis correos uso Evolution (aunque también uso mutt bastante últimamente). Y supongo que este es el mayor mito de todos… que la gente piense que GNU/Linux son solamente termianles, a mi me gusta mi entorno de escritorio, es bastante minimalista, pero a mi me gusta así :) Y usualmente solo tengo dos o tres programas corriendo, mi Chrome, mi Evolution y mi terminal :)

Estos son unos de los motivos por los que me gustan tanto las CLI y por los que los invito a darles una oportunidad, puede que después terminen como yo usando más CLIs que GUIs ;) Saludos