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

Evita ser hackeado con estos 3 pasos

Hasta ahora creo que no he tocado uno de mis temas favoritos, seguridad informática, y considero que este será el tema que les vengo a contar hoy :) Espero que tras este pequeño artículo puedan tener una mejor idea de lo que puede ayudar a tener un mejor control de sus riesgos y cómo mitigar bastantes al mismo tiempo.

Riesgos por doquier

Es inevitable, en este año solamente, ya llevamos más de 15000 vulnerabilidades descubiertas y asignadas de manera pública. ¿Cómo lo sé? Porque parte de mi trabajo es revisar CVEs en los programas que usamos en Gentoo para saber si corremos software vulnerable, de esta manera podemos actualizarlo y asegurar que todos en la distribución tengamos equipos seguros.

CVE

Common Vulnerabilities and Exposures por sus siglas en inglés, son los identificadores únicos que se asignan a cada vulnerabilidad existente. Puedo decir con mucha alegría que varios Developers de Gentoo apoyan al bien de la humanidad, investigando y publicando sus hallazgos para que puedan ser corregidos y solucionados. Uno de los últimos casos que tuve el gusto de leer fue el de Optionsbleed; una vulnerabilidad que afectaba a servidores Apache a nivel mundial. ¿Por qué digo que estoy orgulloso de esto? Pues porque ellos hacen un bien al mundo, mantener las vulnerabilidades en secreto solo beneficia a pocos, y las consecuencias de esto pueden ser catastróficas dependiendo del objetivo.

CNA

Las CNA son entidades encargadas de solicitar y/o asignar CVEs, por ejemplo, tenemos la CNA de Microsoft, encargada de agrupar sus vulnerabilidades, resolverlas y asignarles un CVE para su posterior registro a lo largo del tiempo.

Tipos de medidas

Vamos a comenzar aclarando que ningún equipo es o será 100% seguro, y como decía un refrán bastante común:

El único equipo 100% seguro es aquel que se encuentra encerrado en una bóveda, desconectado de internet y apagado.

Porque es cierto, los riesgos siempre estarán ahí, conocidos o desconocidos, solo es cuestión de tiempo por lo que frente al riesgo podemos hacer lo siguiente:

Mitigarlo

Mitigar un riesgo no es más que reducirlo (NO anularlo). Este es un punto bastante importante y crucial tanto a nivel empresarial como personal, uno no quiere ser “hackeado”, pero a decir verdad el punto más débil de la cadena no es el equipo, ni el programa, ni siquiera el proceso, es el humano.

Todos tenemos costumbre de culpar a otros, sean personas o cosas, pero en seguridad informática, la responsabilidad siempre es y será del humano, podrás no ser tú directamente, pero si no sigues el camino adecuado, serás parte del problema. Más adelante les doy un pequeño truco para mantenerse un poco más seguros ;)

Transferirlo

Este es un principio bastante conocido, tenemos que imaginarlo como un banco. Cuando tu necesitas cuidar tu dinero (me refiero de manera física) lo más seguro es dejarlo con alguien que tenga la capacidad de resguardarlo mucho mejor que tú. No necesitas tener tu propia bóveda (aunque sería mucho mejor) para poder cuidar cosas, solamente necesitas contar con alguien (de confianza) para que guarde algo mejor que tú.

Aceptarlo

Pero cuando el primero y el segundo no aplican, pues ahí es donde viene la pregunta realmente importante. ¿Qué tanto vale este recurso/dato/etc para mí? Si la respueseta es mucho, pues deberías pensar en los primeros dos. Pero si la respuesta es un no tanto, tal vez simplemente debas aceptar el riesgo.

Hay que afrontarlo, no todo es mitigable, y algunas cosas mitigables costarían tantos recursos que sería prácticamente imposible aplicar una solución real sin tener que cambiar e invertir mucho tiempo y dinero. Pero si puedes analizar aquello que intentas proteger, y no encuentra su lugar en el primer o segundo paso, pues simplemente llévalo en el tercer paso de la mejor manera, no le des más valor del que tiene, y no lo mezcles con cosas que realmente tienen valor.

Mantenerse al día

Esta es una verdad que escapa a cientos de personas y negocios. La seguridad informática no se trata de cumplir con tu auditoría 3 veces al año y esperar que nada suceda en los otros 350 días. Y esto es verdad para muchos administradores de sistemas. Yo hace poco al fin me pude certificar como LFCS (les dejo a ustedes buscar en dónde lo hice :) ) y este es un punto crítico durante el curso. Mantener al día tu equipo y sus programas es vital, crucial, para evitar la mayoría de riesgos. Seguro aquí muchos me dirán, pero el programa que usamos no funciona en la siguiente versión o algo similar, pues la verdad es que tu programa es una bomba de tiempo si no funciona en la última versión. Y eso nos lleva al anterior apartado, ¿puedes mitigarlo?,¿puedes transferirlo?,¿puedes aceptarlo?…

A decir verdad, solo para tenerlo presente, según las estadísticas 75% de los ataques de seguridad informáticas son originados desde el interior. Esto puede ser porque tiene usuarios en la empresa incautos, o malintencionados. O que sus procesos de seguridad no le han hecho difícil a un hacker irrumpir en sus locales o redes. Y casi más del 90% de ataques son originados por software desactualizado, no por vulnerabilidades de día cero.

Piensa como máquina, no como humano

Este será un pequeño consejo que les dejo de aquí en adelante:

Piensen como máquinas

Para los que no comprendan, pues ahora les doy un ejemplo.

Resultado de imagen para john the ripper software

Les presento a John. Entre los amantes de la seguridad es uno de los mejores puntos de partida cuando comienzas en el mundo del ethical hacking. John se lleva de maravilla con nuestro amigo crunch. Y básicamente agarra una lista que se le entrega y empieza a probar las combinaciones hasta encontrar una clave que resuelva la contraseña que busca.

Crunch es un generador de combinaciones. esto quiere decir que tu le puedes decir a crunch que quieres una contraseña con 6 caractéres de largo, que contenga letras minúsculas y mayúsculas y crunch empezará a probar uno por uno… algo como:

aaaaaa,aaaaab,aaaaac,aaaaad,....

Y se preguntarán cuánto tiempo lleva ir por toda la lista seguro… no toma más de unos cuantos minutos. Para los que se quedaron con la boca abierta, permítanme explicarles. Como conversamos anteriormente, el eslabón más débil de la cadena es el hombre, y su forma de pensar. Para una computadora no es complicado probar combinaciones, es algo sumamente repetitivo, y con el pasar de los años los procesadores se han vuelto tan poderosos que no necesitan más de un segundo para hacer mil intentos, o incluso más.

Pero ahora lo bueno, el ejemplo anterior es con el pensamiento humano, ahora vamos por el pensamiento de máquina:

Si le decimos a crunch que empiece a generar una contraseña con solo 8 dígitos, bajo los mismos requerimientos anteriores, hemos pasado de minutos a horas. Y adivinen qué sucede si le decimos que use más de 10, se convierten en días. Para más de 12 ya estamos en meses, además del hecho de que la lista sería de proporciones que no podrían ser almacenadas en una computadora normal. Si llegamos a 20 hablamos de cosas que una computadora no va a poder descifrar en cientos de años (con los procesadores actuales claro está). Esto tiene su explicación matetmática, pero por cuestiones de espacio no se las voy a explicar aquí, pero para los más curiosos tiene mucho que ver con la permutación, las combinatorias y las combinaciones. Para ser más exactos, con el hecho de que por cada letra que agregamos al largo tenemos casi 50 posibilidades, así nos quedará algo como:

20^50 posibles combinaciones para nuestra última contraseña. Ingresen ese número a su calculadora para que vean cuantas posibilidades existen con una clave de longitud de 20 símbolos.

¿Cómo puedo pensar como máquina?

No es sencillo me dirá más de uno pensar en una clave de 20 letras seguidas, sobre todo con el antiguo concepto de que las contraseñas son palabras clave. Pero veamos un ejemplo:

dXfwHd

Esto es difícil de recordar para un humano, pero súmamente sencillo para una máquina.

caballoconpatasdehormiga

Esto por otro lado es súmamente fácil de recordar para un humano (hasta incluso divertido) pero es un infierno para crunch. Y ahora más de uno me dirá, ¿pero no es recomendable también cambiar de manera seguida las claves? Sí, es recomendable, por lo que ahora podemos matar dos pájaros de un tiro. Supongamos que este mes están leyendo El Quijote de la mancha, tomo I. En la contraseña pondrán algo como:

ElQuijoteDeLaMancha1

20 símbolos, algo bastante difícil de descubrir sin conocer a la persona, y lo mejor es que cuando acaben el libro (suponiendo que leen de forma constante :) ) sabrán que deben cambiar su contraseña, incluso el cambiar a:

ElQuijoteDeLaMancha2

Es ya un progreso :) y seguramente les ayudará a mantener sus contraseñas seguras y al mismo tiempo les recordará que deben acabar su libro.

Ya es bastante lo que he escrito, y aunque me encataría poder hablar sobre muchos más temas de seguridad, lo dejaremos para otro momento :) Saludos

Programación: La psicología de las computadoras

Todos nos vemos íntimamente relacionados con la programación, sea como usuario, como administrador, como programador propiamente, pero en definitiva es algo que va a estar más conectado con nuestras vidas con el pasar de los años.

En este artículo (el comienzo de una pequeña serie que pienso crear) Quiero compartir con ustedes unos cuantos conceptos sobre lo que he ido descubriendo de programación a lo largo de estos años. No pretendo ser sumamente técnico, ya explicaré por qué más adelante. Pero lo que si pretendo es hacer que vean el mundo con mis ojos, y si les gusta cómo se ve, pues que se adentren un poco en él :)

Primero atacaré el punto más simple de todos antes de entrar en detalles.

¿Por qué no voy a hacer un post técnico?

Pues para los que han leído mi post sobre el mejor comando de Linux, sabrán un poco la causa de este enfoque. La tecnología siempre está cambiando, y si yo el día de hoy escribo algo, en el caso de que el post sea bien recibido, pues tendré que estar siempre actualizando la información. En los lenguajes más comunes de hoy, lo único seguro es el cambio. Con esto me refiero (y los programadores me podrán dar la razón) los frameworks siempre están creciendo y modificandose desde sus núcleos, esto es así porque los errores surgen, algunos pueden ser considerados simples bugs, mientras que otros pueden llegar a ser vulnerabilidades.  Esta es la razón por la cual escribir un post sobre un lenguaje específico, hoy por hoy, me garantizaría tal vez unos cuantos meses de utilidad, en el mejor de los casos uno o dos años, pero esa no es la idea :)

La electricidad es importante

Aquellos que hayan investigado un poco sobre los lenguajes más bajos de programación de software sabrán que todo se remonta a la electricidad. Antiguamente la programación se realizaba a nivel de hardware, esto quiere decir que aquellos antiguos relojes, calculadoras, y otros muchos dispositivos, podían cumplir su destino mediante programación por hardware.

El probema

Cambiar programación de hardware es costoso, y complicado :) (al menos eso me han contado :) ). Es por esto que surgieron los procesadores, que en realidad abstraen esa capa de hardware para entregarnos unos cuantos comandos para poder realizar todo aquello que era posible mediante hardware, solo que ahora en la capa de software.

Los procesadores

Los procesadores de hoy en día, tienen un número limitado de funciones, llamadas instrucciones en muchos libros. Estas permiten realizar las funciones más básicas que puede ejecutar el hardware, y movilizar la información a través de la memoria del equipo.

Registers

Los registros son un espacio en el que el procesador almacena información para poder realizar trabajos en el núcleo, dependiendo de la arquitectura pueden tener un distinto tamaño y orden, pero en forma simple, su función es almacenar datos que le indican al procesador uno de los siguientes tipos de trabajo: mover data, aritmética y lógica, y control de flujo. Todo puede resumirse en estos tipos de funcionalidades.

Binario

Los procesadores trabajan a nivel binario, esto quiere decir que solo entienden de 0s y 1s :) . Un dato curioso aquí :D ¿recuerdan los permisos de GNU/Linux? pues, ¿alguna vez se han preguntado cómo realmente reconoce el procesador esos permisos? Simple :) binario. En el nivel más bajo, un procesador entenderá los permisos como una sucesión de 0s y 1s, y ese es el motivo por el cual el octal que formamos tiene los valores para ejecución, 2 para lectura y 4 para escritura. Para los que saben leer binario, entenderán que:

111100101111

Ponen los permisos de lectura, escritura y ejecución para el grupo otros mientras que pone ejecución y lectura para el grupo grupo y solo lectura para el dueño del archivo. Para los más curiosos, los últimos tres 1s activan el setguid, setuid y el sticky bit. Si no saben qué es esto del binario, lo puedo explicar en otro post, si no conocen esto del setuid, setgid y el sticky bit, pues se los dejo de tarea ;) pero también lo puedo explicar en otro lugar si es necesario.

Cuando la curiosidad llama…

Pues si lo me han seguido hasta aquí, entonces ya su curiosidad debería empezar a preguntar bastantes cosas, la primera que quiero responder (y tal vez la única que me permita este post porque ya estoy escribiendo bastante) es: ¿si las llamadas son las mismas, por qué los programas son tan diferentes?

La psicología

La programación es el arte de aprender a leer mentes :) Quiero empezar este apartado con una cita que leí hace un buen tiempo, Edsger Dijkstra dijo:

Si la depuración es el proceso de eliminar errores, entonces la programación debe ser el proceso de introducirlos

Y es que no encuentro una mejor forma de explicar todo esto :) ¿por qué programar es el arte de introducir errores? se preguntará más de uno en este momento. La respuesta es simple, porque nuestras mentes son humanas, y los humanos cometemos errores :) está en nuestra naturaleza, y estará por todo el tiempo en el que el hombre exista en el planeta.

Las computadoras no se equivocan

Los que nos equivocamos somos nosotros, los equipos siempre se limitarán a reproducir lo que les indicamos, no asumen nada, no interpretan nada, no objetan nada, solo leen y actúan. Por eso en otro libro de C alguna vez leí algo como esto:

C es un lenguaje rudo, puedes hacer mucho con él, pero jamás te impedirá dispararte en el pie si eso deseas hacer, o eso le indicas.

Esto es una verdad bastante curiosa :) Puesto que al trabajar a un nivel tan bajo, es posible que muchas operaciones que se realizan puedan ser destructivas, algo que no sucede con lenguajes de nivel un poco más alto, puesto que las capas de prevención de errores son mayores.

Todo es psicología

Cada lenguaje, framework, programador, respeta y sigue algún tipo de filosofía, y si no lo hace, pues no tiene un futuro muy prometedor. Los que trabajamos en UNIX y derivados, probablemente conoceremos la antigua frase:

Haz una cosa, y hazla muy bien.

Esta filosofía es la que siguen algunos proyectos como el kernel, funciones bastante reducidas que solamente hacen una cosa, pero la hacen lo mejor que se puede.

Si nos vamos a otros lenguajes, cada uno tendrá una función y objetivo, algunos más permisivos y otros más restrictivos, pero todos siguiente su propia forma de pensar.

Aprender a leer mentes

Existe un dicho bastante común entre programadores, dice que existen cientos de formas de resolver el mismo problema. Esto es cierto, pero hay algo mucho más profundo de este aspecto. Leer código fuente te permite leer mentes :) no cualquier mente, sino la del programador (o programadores) que lo escribió. Es una especie de diario virtual y profundo :) te permite conocer en profundidad la mente del desarrollador, y en caso de proyectos extensos, te permite ver cómo ha crecido su pensamiento lógico y crítico a lo largo del tiempo. Algo extraordinario y que nutre bastante la mente de los más jóvenes, porque puedes conocer los mejores caminos de personas que tuvieron que descubrirlos :)

Ser consistente

Muchos programadores y especialistas dicen que tenemos que salir de nuestra zona de confort, y aunque es verdad, también es más que necesario mantener ciertos procesos y formatos. Esto es simple de explicar, nuestras mentes son repetitivas y respetan estructuras, si todos los días escribes código de la misma manera, en poco tiempo dejarás de pensar en la forma y te podrás concentrar en el fondo. Esto te permite ver la lógica del programa en lugar de la syntaxis del lenguaje. Y este es le motivo por el que considero que aprender los conceptos siempre será más importante que aprender las formas. Esta es una opinión personal, pero espero que tras leer todo esto puedan entender por qué lo considero así :) además que se los dice alguien que ha tenido que programar en C, Java, Javascript, Python, Ruby, PHP, y otros :) conocer los conceptos facilita escribir el código.

En resumen

Bueno, este es el primer paso de una serie que espero les ayude a pensar de otra manera en el arte de la programación, incluso a que los invite a adentrarse en los conceptos que permiten ejecutar el código que han escrito tal vez cientos de veces, pero que no se han detenido a pensar en lo que realmente hace. Y para los que no han empezado a programar, pero les gustaría, poder priorizar un poco sobre lo realmente importante de conocer :) Saludos

El mejor comando de todo GNU/Linux según yo

Título más que provocativo :P y como siempre, comentario muy personal. Pero con un poco de suerte acabando de leer este post, algunos de ustedes tendrán ganas de probarlo de ahora en adelante ;). Ya sé que quieren saber cuál es el nombre del mejor comando, pero todavía no se los voy a decir :P Esperen un poco de historia primero.

La magia de internet

Resultado de imagen para como construyen cosas antes de stack overflow

Si no reconocen este símbolo, probablemente no han estado muy envueltos en el mundo del desarrollo de software. Hoy en día, este es un punto de referencia para cualquier tipo de pregunta relacionada no solo con programación, existen muchos temas muy interesantes. (Yo mismo participo bastante en la comunidad de Linux & Unix).

Como es de esperarse, esto conlleva grandes ventajas de productividad, dado que en cuestión de segundos puedes encontrar la solución a un problema que si no hubiese sido solucionado y mostrado en la página, te hubiese tomado horas, o tal vez días, resolver (ojo que esto no es nada malo en absoluto).

El problema

Con estas ventajas de hoy en día, ha surgido un gran problema. El conocimiento se está volviendo atómico. ¿A qué me refiero con esto? Pues acompañenme en mi deliberación.

El  otro día quise ir a comprar un buen libro de programación en español ( no tenía ningún nombre en la mente, simplemente quería ver si había algo bueno). Como era de esperarse en mi país, no sé si en los suyos sucederá igual, los libros relacionados a computación estaban en el estante más pequeño y escondido de la librería. Es más, estaban tan escondidos que cuando llegué al que tenía el letrero de “Informática”, me di con la sorpresa de que eran libros de filosofía. Tuve que preguntar a uno de los muchachos que se encontraban trabajando ahí, me miró extrañado, y me mostró un estante lleno de libros que al parecer no se vendían muy seguido.

Entre algunos de los ejemplares que pude encontrar, había un super moderno Word 2003, PowerPoint 2003, Corel x3… incluso libros de Android y Swift que estaban tan descontinuados que no valía la pena pasar de la portada del libro. No es que esté en contra de dichos libros, pero la verdad es que no me imaginaba comprando alguno de estos, mucho menos leyendo uno hasta el final…

El mayor problema

Pero esto no puede ser una causa… lo dudo mucho en realidad. La razón de esto escapa a lo que se ve a simple vista en las librerías, pero es algo bastante evidente si nos ponemos a reflexionar un poco. Los programadores de hoy, no leen. Esta es una triste realidad, que gracias a la magia del internet, cada vez es más general en todo el mundo.

Es verdad que al ritmo al que crece y se desarrolla la tecnología, conseguir libros es algo complicado, siempre se están renovando los lenguajes, o cambiando los frameworks. ¿Qué podemos hacer al respecto? Pues esta es mi solución personal.

El factor decisivo

A lo largo de los más de 30 años que ha existido el software, ¿qué es eso que nunca ha cambiado en lo más minimo? Simple, el elemento principal, el hombre. Si lo pensamos por un segundo verán a qué me refiero; el hombre siempre ha estado ahí, sin importar el lenguaje; el hombre siempre ha estado ahí, sin importar el hardware. El hombre es quien ha definido los conceptos principales sobre el desarrollo.

Hace algún tiempo compré un libro llamado SISTEMAS OPERATIVOS, un enfoque basado en conceptos de D. M. Dhamdhere. Si bien el libro fue publicado en 2008, muchos de los conceptos me parecen tan relevantes el día de hoy, que considero que gran parte de lo que conozco de sistemas operativos se basa en este bello (y un poco extenso) ejemplar.

¿Como afecta esto?

Bueno, toda esta explicación ha tenido un motivo y razón de ser. Mi comando favorito ha sido marginado durante muchos de estos últimos años por este nuevo modo de investigar cosas. Porque antes del internet a la escala en la que nos encontramos ahora, tenía que haber una forma de descubrir todos estos pormenores del día a día.

Para todos los curiosos les pido que ejecuten el siguiente commando:

apropos -s 1,2,3,4,5,6,7,8 a

Les garantizo que habrán visto muchas líneas pasar frente a sus ojos. Y para los que no hayan visto absolutamente nada, primero deben correo

mandb

Tras una breve espera podrán realizar el anterior comando y ver la larga lista de información.

man

Para estas alturas del post ya no existe necesidad de ocultar el nombre de mi programa favorito :)

Y es que simplemente permítanme citar una pequeña referencia de su misma página de manual

Diseño propio. Christopher Díaz Riveros

Esta sección es bastante interesante, como podemos apreciar, existe una clara definición de los tipos de manuales que existen. Mis favoritos se encuentran en el grupo 8 y el 3. Pero seguramente estarán preguntando, ¿cómo accedo a estas páginas? Muy sencillo, man viene de la mano con dos programas que nos hacen la vida bastante sencilla. apropos whatis. El primero nos permite buscar referencias dentro de los manuales (título y descripción) y el segundo nos permite buscar todos los tipos de manuales para cada entrada disponible. Pero vamos a poner un ejemplo para hacerlo más didáctico.

apropos

Veamos que sucede al utilizar apropos man:

Diseño propio. Christopher Díaz Riveros

Como pueden ver, la lista es tan grande que no alcanzó mi terminal para mostrar toda. Apropos busca tanto en el título como en la descripción, por lo que usar palabras pequeñas puede ser poco útil dado que genera muchos resultados. Pero siempre es genial si no recordamos exactamente el nombre del comando.

whatis

Como su nombre lo dice, este programa usa el valor de una entrada de programa y te muestra todas las posibles referencias que encuentre. Para mantener el espíritu, vamos a probar el siguiente comando:

Diseño propio. Christopher Díaz Riveros

Como pueden ver, ahora estamos en un formato mucho más reducido. Esta es una de las mejores partes de whatis, dentro del paréntesis nos indica qué sección de manual está disponible. Como pueden ver, man cuenta con tres entradas: 1, 7 ,1p.

uso

En cualquiera de los casos anteriores, solo basta con ejecutar cualquiera de estos comandos:

Diseño propio. Christopher Díaz Riveros

¡Así de sencillo! :) Podrán ver cada una de las respectivas entradas, pero eso no es todo. Man también es bastante útil al momento de estar dentro del manual, vamos a apretar h mientras estamos dentro:

Diseño propio. Christopher Díaz Riveros

Como puede apreciar, man usa less como paginador. Por este motivo, muchos de los comandos de vim serán útiles en man, y así no es necesario aprender nueva sintaxis ( para los que ya conocen vim) al momento de navegar por las pantallas. Si recuerdan mi post sobre el kernel / y son tus amigos ;)

info

info es un pequeño programa que muestra un texto más amigable en algunos programas ;) va de la mano con man, pero en casos particulares, como muchos de los programas de GNU, info es mucho más detallado (este no es el caso común por cierto).

Pensamientos finales

Este es mi comando favorito y el mejor comando según yo :) Principalmente porque, si nos detenemos a pensar un poco en el asunto, ¿quién mejor que la persona que ha diseñado un programa para explicarte sobre su uso y ventajas? Siempre será mejor la información que llegue de la fuente a cualquier tipo de adaptación (incluso mis posts :P ).

Ya se está haciendo costumbre escribir bastante, pero espero que si han llegado hasta aquí, les pique un poco la curiosidad sobre este maravilloso comando que nos entrega todo el conocimiento de linux en nuestros equipos y sin esfuerzos extra :)

Para los que hayan podido notar, muchos de estos manuales están en inglés, una maravillosa oportunidad de ayudar al mundo hispano es contactar a los desarrolladores (normalmente el final de la página man) y decirles que desean crear una traducción, muchos de ellos aceptarán encantados. Pero por ahora yo me despido.

Saludos,

Tutorial simple para hacer tu primer PR (Pull Request)

Bueno, este si creo que será un tutorial bastante corto y esperemos que didáctico ;). Voy a poner a disposición de ustedes un pequeño repositorio en mi github para que puedan mandar sus PR y al mismo tiempo para que practiquen cómo hacer todos los pasos que voy a dejar a continuación. Aquí el link para hacer sus PR de prueba:

https://github.com/CodeLabora/TuPrimerPR

Bueno, vamos a listar rápidamente los pasos necesarios para mandar un PR:

  1. Fork
  2. Clone
  3. Remote
  4. Branch
  5. Cambios
  6. Add
  7. Commit
  8. Push
  9. PR

Los estoy poniendo en inglés para que encuentren sus respectivas opciones en la línea de comando de git.

Fork

Un fork es tu propia versión de un repositorio de Github. Este te permite clonar el trabajo de otro proyecto y tenerlo en tu cuenta para que puedas cambiar cosas sin preocupación de perder tus cambios. Para realizar un fork solo es necesario ir a la página y dar click al botón Fork que se encuentra en la parte superior derecha.

Diseño propio. Christopher Díaz Riveros

Una vez realizado el fork podrán ver que en su cuenta aparece el repositorio.

Diseño propio. Christopher Díaz Riveros

Clone

Ahora que ya tenemos un repositorio lo vamos a clonar a nuestro equipo. (Asumo que me siguen personas que usan Linux, pero para los usuarios de otros sistemas también existen versiones de git que pueden descargar en su página oficial.

Diseño propio. Christopher Díaz Riveros

Y con nuestro terminal hacemos lo siguiente.

Diseño propio. Christopher Díaz Riveros

Con esto tendremos una nueva carpeta llamada TuPrimerPR en la que estará nuestro proyecto de Github. entramos a la carpeta con el comando “cd TuPrimerPR” y veremos que dentro están los archivos que se encuentran en nuestro fork.

Diseño propio. Christopher Díaz Riveros

(Tengan en cuenta que la cantidad de archivos puede variar dependiendo de lo que encuentren en mi repositorio cuando hagan el fork)

Remote

Este es un paso opcional, pero que evita muchos problemas al momento de trabajar de manera continua en un proyecto. Fork por defecto crea una copia exacta del repositorio, pero en el momento exacto de la creación. Esto quiere decir que si el proyecto sigue avanzando, su repositorio se va a quedar atrasado con el pasar de los días u horas. “git remote ”  nos permite especificar otro punto de descarga (el proyecto original) y así poder actualizar nuestro proyecto cada vez que vemos que el proyecto padre se está actualizando.

Para encontrar tu proyecto padre solo hace falta usar el link que se encuentra justo abajo del nombre de tu repositorio. (Revisen la segunda imagen del apartado Fork). Vamos a agregar este dato a continuación:

Diseño propio. Christopher Díaz Riveros

Este es el proyecto original (lo vamos a llamar upstream para seguir la corriente de muchos proyectos).

Diseño propio. Christopher Díaz Riveros

Como pueden ver, he agregado el remote con ” git remote add <nombre> <URL> ”

Con esto vamos a poder actualizar el proyecto cuando sea necesario, pero no lo vamos a usar ahora porque no es necesario. (Eso lo explico más adelante, o en otro post, dependiendo de la necesidad)

Branch

Los branch (o ramas) permiten crear secciones de código que puedes trabajar en un entorno aislado. Esto quiere decir que lo que hagas en un branch no necesariamente afecta al código original hasta que se utilice un ” git merge “. También es una funcionalidad extra que te permite Github, cada vez que tu creas un branch, Github genera automáticamente la fuente del Pull Request cuando es necesario.

Diseño propio. Christopher Díaz Riveros

Ahora que estamos en nuestra rama especial, podemos trabajar en nuestra contribución.

Cambios

Voy a agregar un par de archivos para que vean cómo se hace.

Diseño propio. Christopher Díaz Riveros

“touch ” nos permite crear un archivo (si es que no existe) en blanco. con esto podemos pasar a nuestro siguiente paso.

Add

” git add ” nos permite agregar archivos a nuestro commit (los explico más adelante). Para ver qué archivos puedes agregar se puede utilizar el comando ” git status ”

Diseño propio. Christopher Díaz Riveros

Con esto tenemos todo preparado para nuestro Commit

Commit

Los commits son marcas (o hitos) en el tiempo. definen un estado para todos los archivos del proyecto y acumulan los cambios necesarios para llegar desde el principio del proyecto hasta el estado actual. Suena un poco complejo, pero es bastante sencillo, solo recuerda que son las escaleras de tu proyecto. Escribimos ” git commit ” y nos saldrá una ventana para escribir nuestro mensaje de commit.

Diseño propio. Christopher Díaz Riveros

Y al finalizar y guardar el texto, veremos algo como:

Diseño propio. Christopher Díaz Riveros

Donde se muestra un resumen de lo que hace el commit.

Push

Con push estamos subiendo a nuestra cuenta de Github todos los commits que tenemos en el equipo que no se encuentran en nuestro repositorio en internet. Esto hará que Github pueda generar el nuevo PR de manera automática.

Diseño propio. Christopher Díaz Riveros

Noten que estamos usando el nombre de nuestro branch y que nos solicita nuestro usuario y contraseña. Al final nos muestra que se ha creado el branch miMejora dentro de nuestra cuenta de Github. Vamos a ver en el navegador lo que hemos conseguido. ;)

PR

Diseño propio. Christopher Díaz Riveros

Como pueden ver, se ha creado una nueva línea que dice “Compare & Pull request”. Esta funcionalidad de Github nos permite crear el PR de manera sencilla, vamos a dar click para ver qué sucede.

Diseño propio. Christopher Díaz Riveros

Github es bastante inteligente. Como pueden apreciar, partes el commit se agregan al formulario para envío. Solo es necesario dar click al botón y listo :) Sencillo.

Extra

Esto es el detrás de cámaras de los proyectos, aparece el PR y el encargado decide si aceptar o no, o escribir más mensajes. En mi caso lo voy a aceptar de manera instantánea.

Diseño propio. Christopher Díaz Riveros

Una vez realizado el merge, podrán ver el log de commits del proyecto y ver su nombre en él.

Diseño propio. Christopher Díaz Riveros

Pero ahora tenemos un problema. Ese commit no aparece en nuestro repositorio, solamente en el del proyecto. ¿Recuerdan nuestro paso de remote? Ahora es cuando rinde frutos :)

Volvemos a nuestro branch master y hacemos lo siguiente:

Diseño propio. Christopher Díaz Riveros

Con esto hemos descargado toda la información del proyecto original a nuestro equipo. Como pueden apreciar, ahí aparece nuestro commit. Ahora vamos a guardar todo este trabajo en nuestro repositorio de Github para poder eliminar el branch que tiene el aporte que ya agregaron al proyecto.

Diseño propio. Christopher Díaz Riveros

Ahora que ya tenemos nuestro repositorio de Github actualizado vamos a borrar nuestro branch, pero primero nos aseguramos que esté dentro de nuestra rama principal (master)

Diseño propio. Christopher Díaz Riveros

Como pueden ver tuve un ligero error, esto era porque me encontraba en mi branch miMejora al momento de quere borrar. Esto se arregla regresando al branch master.

Conclusión

Listo :) tan sencillo como eso. Ahora que dominan los oscuros secretos de Github para mandar PR, espero ver sus contribuciones en diversos proyectos. Y si desean pueden dejar su primer PR en mi repositorio ;) para el recuerdo.

No he tocado mil y un beneficios de Git (OJO, no Github) y como es de esperar de desarrolladores que están ligados a la comunidad del Kernel, Git es una herramienta sumamente poderosa, con cientos de funcionalidades.

Para poder tener una mejor idea de lo que hace y todo el poder de Git, les recomiendo mucho este libro. Estoy seguro que les ayudará bastante a mejorar en el manejo de git.

Saludos y espero que les ayude ;)

Mi primer PR (Pull Request) en Github

Bueno, me tomaré la libertad de salir un poco de mi zona de confort, para entrar en otra de mis zonas de confort :P FOSS. En este post pretendo, así como hice con Gentoo, primero compartir un poco de mi experiencia personal y así tratar de emocionarlos un poco a poder sumergirse de lleno en el mundo de los proyectos y las contribuciones. Sin más que agregar, empecemos:

FOSS

Free and Open Source Software (por sus siglas en inglés) es una corriente que envuelve tanto a proyectos open source como de software libre. No pretendo discutir las diferencias entre ambos ya que ya lo he hecho en repetidas oportunidades, incluso una vez tuve que explicar todo al mismo señor Stallman que me contactó por correo en una de las listas de proyectos que abundan por internet. Un artículo que me emociona mucho y el cual les voy a compartir se encuentra en la página oficial de GNU y como muchos de sus documentos, se encuentran traducidos a diversos idiomas. Les adjunto el link y me tomaré la libertad de citar uno de los párrafos que más me llaman la atención.

https://www.gnu.org/education/edu-schools.es.html

La razón más profunda para utilizar software libre en las escuelas es la educación moral. Esperamos que las escuelas enseñen hechos básicos y habilidades útiles, pero esa es solo una parte de su función. La tarea fundamental de las escuelas es enseñar a ser buenos ciudadanos, incluyendo el hábito de ayudar a los demás. En el ámbito informático, esto se traduce en enseñar a compartir el software. Las escuelas, a partir del jardín infantil, deberían decirle a sus alumnos: «Si traéis software a la escuela, debéis compartirlo con los demás niños. Y debéis mostrar el código fuente en clase, por si alguien quiere aprender. Por lo tanto, no está permitido traer a la escuela software que no sea libre, a menos que sirva para hacer algún trabajo de ingeniería inversa».

Como pueden ver, el software libre es una corriente más que técnica, yo diría moral. Es como acercarnos un paso más a este mundo en el que el egoísmo y la soberbia están de lado y podemos tener gente que realmente comparte y se preocupa por los demás.

Bueno, no pretendo hacerlos fervientes usuarios de software libre, pero los animo a que den un salto por los documentos, y vean lo bueno que puedan rescatar :)

Proyectos

Todo software, ya sea open source o free software, tiene un proyecto y probablemente una comunidad girando a su alrededor. Estos son quienes lo mantienen, mejoran, protegen, etc. Como es de esperarse, mientras más grande es el proyecto, las estructuras se vuelven cada vez más específicas en cuanto a procesos y formas, y evidentemente es lo correcto puesto que a mayor número de participantes, los errores pueden ser mayores si no se tienen bien definidas las formas de colaborar y los procesos para hacerlo.

La principal regla al momento de optar por contribuir a un programa FOSS, es USAR dicho programa :D Y puede que suene un poco tonto lo que digo, pero en realidad tiene mucho sentido. ¿Cómo nacen muchos de los features que incluye un programa? Pues por necesidad. Cada funcionalidad existente surge en base a que alguien (una o muchas personas) necesitan de dicha función. Es por esto que si tu deseas compartir y colaborar a una comunidad, un paso indispensable es que uses lo que desarrollan.

¿Es necesario ser un experto programador?

Yo quiero comenzar esta parte haciendo una simple pregunta. ¿Cómo se convierte uno en un experto programador? Aquí algunos me dirán, pues escribiendo código, y a todas esas personas yo les comento que ese no es el enfoque correcto. ¿Por qué?

Leer código te hace mejor programador

Piensen en esto un poco antes de continuar. ¿Qué escritor nació sabiendo escribir? ¿No es acaso primero aprender a leer, para nutrir el cerebro con muchos otros autores y así eventualmente poder empezar a escribir algo con contenido y valor? Sucede exactamente igual con el código, uno debe aprender a leer mucho antes de aprender a escribir.

Tu código probablemente no es tan bueno

Para los que lleven programando por muchos años, perdón si con esto destruyo sus concepciones de lo que han logrado en todo este tiempo, pero es verdad. Para los que hemos tenido la oportunidad de colaborar en proyectos realmente grandes, lo primero que puedes apreciar es que existe muchísima gente que es muchísimo más talentosa que uno. Evidentemente esto antes que ser una desventaja, es un punto por el cual apoyar en un proyecto te convierte en un mejor desarrollador.

Tener cientos, o tal vez miles, de ojos revisando tu código día a día, te hace descubrir en qué aspectos tu lógica no es la mejor de todas. La principal ventaja de esto es que con el pasar del tiempo, tu cerebro va descubriendo nuevas formas de proceder, y los errores “infantiles” que cometías al principio de tu participación, se convierten en un vago recuerdo.

Con esto solo quiero reforzar el hecho de que un proyecto te hace bien, tanto para aprender a leer como para aprender a escribir código, lo que a la larga te convertirá en un experto programador.

Y… ¿si yo no soy programador?

Este es un punto que quiero tocar también porque mucha gente piensa que si no escribe código, no hay nada que se pueda hacer para ayudar. Este es un mito urbano de los más perjudiciales que existen.

Muchos proyectos requiere de más mano de obra en temas que no son de código de la que requieren para producir código. Tal vez en marketing, o en publicidad, o derecho, incluso en planeamiento de eventos, la ayuda siempre es bienvenida. Además de que te permite conocer nueva gente, el participar en estos proyectos te permite conocer nuevas formas de pensar y al mismo tiempo compartir experiencias nuevas.

¿Cómo participo?

Pues si ya estás aquí, espero que al menos un poco de curiosidad te pique por participar en proyectos FOSS ;) . Para comenzar es necesario comprender que cada proyecto y comunidad tiene su proceso propio. Muchos de estos se juntan en distintos puntos, y divergen en otros, pero al fin de cuentas, el primer punto de referencia para participar será la comunidad del programa que usas.

Página web

Cada página web tiene su propia sección de Contribuye. Y si no la tiene, pues esa es la primer cosa en la que puedes ayudar :D aprende el proceso, conversa con la comunidad, y escribe un pequeño texto para que puedas guiar a otros por el proceso ;) Si ya tienen uno, pero no está en español, pues puedes tomarte un fin de semana para traducirlo y así estarás ayudando a tu proyecto y al mismo tiempo a todos los de habla hispana :) Dos pájaros de un tiro ;)

Listas de correo

Mucha de la comunicación de las comunidades se da por listas de correo, es necesario subscribirse y empezar a tomarse un par de minutos al día para leerlos. Tal vez al principio no entiendas, pero te aseguro que con el pasar de los días o semanas, irás comprendiendo lo que sucede. Antes de darte cuenta, ya estarás escribiendo en la lista, y no pasará mucho antes de que la gente te empiece a preguntar opinión o posibles soluciones (si te esfuerzas claro está ;) ).

Github

Este es un punto crucial para toda persona que desee colaborar en un proyecto FOSS, aprender a manjera Github, o Gitlab, o Bitbucket, o cualquier host que albergue el código del repositorio, te permitirá ayudar de manera tangible a la mejora de la comunidad.

IRC/Gitter/Telegram

IRC (Internet Relay Chat) ha estado desde los primeros días del internet. Así es como la gente se comunicaba antes de whatsapp y los smartphones. Y como es de esperarse, muchos proyectos tienen sus canales de IRC a disposición donde se pueden hacer preguntas y conversar sobre temas del proyecto o comunidad, o tener una charla espontánea :) siempre teniendo cuidado porque uno nuca sabe lo que puede encontrar en internet ;)

Mi primer PR

Bueno, aquí no vengo a explicar cómo es que se hace un Pull Request en detalle, eso lo dejaré para otro post si es que les interesa comenzar a participar.

Como programador

Diseño propio. Christopher Díaz Riveros

Como no programador

Diseño propio. Christopher Díaz Riveros

El primero fue un bug de seguridad en el cual incorporé un parche para resolverlo, el segundo es parte del capítulo 7 del libro de Git. Sigo trabajando en ambos proyectos, incluso hace poco terminé de traducir por completo el programa git al español. (Saldrá en la versión 2.15 ;) )

Son aportes pequeños como podrán ver, no más de 100 líneas de código ( de las cuales bastantes solo fueron copiar y pegar lo que ya existía en un nuevo archivo), pero son mi contribución al proyecto :) y son cosas que yo uso a diario.

Como puede apreciar, la sensación es bastante indescriptible :) ver tu nombre en algo que usas, saber que ayudas a mucha gente en el proceso, y  ¡aprender a hacerlo cada día mejor! ¿Puede acaso haber algo mejor que esto? :)

En conclusión:

Me prometí a mi mismo mantener corto este post pero creo que no ha sido tan corto como esperé que sería :P . En fin, espero que con esto les haya picado un poco la curiosidad por empezar a colaborar en proyectos FOSS. Y pronto poder ver sus commits en muchos programas que ustedes usen a diario ;) disculpen que haga tanto énfasis en esto, pero deben comprender que nadie puede mejorar algo que no conoce, y por eso es indispensable poder conocer antes de mejorar :)

Saludos

 

La guía de los 20 pasos para instalar Gentoo

¡Al fin! Lo que todos estabamos esperando. La tan ansiada guía de instalación de Gentoo Linux, hecha por mí, tomando referencias del Handbook de Gentoo. Antes de empezar a contar los pasos y ver si pude cumplir con mi promesa de mantenerlo simple, deseo hacer un par de aclaraciones.

Esta guía es lo más simple posible

No pretendo enseñarles cómo instalar el último driver NVIDIA, o el último filesystem experimental de alguna empresa. Intentaré dejar todo en lo mínimo de lo funcional, ¿por qué? sencillo, así les dejo algo a ustedes para investigar y aprender ;)

Los pasos de instalación

Voy a resumir de forma muy sencilla los bloques en los que voy a trabajar durante esta guía. Pienso instalar Gentoo en un usb para tomar las caputaras de pantalla, pero pueden replicarlo en su disco duro y seguir conmigo el proceso. Los pasos son los siguientes:

  1. Medio de instalación.
  2. Preparar discos.
  3. Stage3
  4. Make.conf
  5. Chroot
  6. Kernel
  7. Grub
  8. Disfrutar :)

Como pueden ver yo difiero un poco del handbook, pero es porque prefiero juntar todo dentro del mismo paquete para poder realizar un trabajo más limpio, pero en caso de necesitar detenerse a revisar otras opciones no duden en ir al Handbook, ahí estará toda la información que puedan necesitar.

Para esta instalación estaré usando SystemD y GNOME ( explicaré los cambios necesarios para KDE dentro del apartado de GNOME), pero para los aventureros de OpenRC, pues tendrán que hacer su tarea ;) escojo SystemD por lo que ha sido adoptado por muchos otros sistemas y tal vez les sea más familiar a la hora de configurar ciertas cosas mientras van cogiendo experiencia con Gentoo. Sin más que agregar, empecemos:

Medio de instalación:

Les dejo aquí el link de mi anterior post sobre este tema, les recomiendo utilizar una distro que ya tenga entorno gráfico, puesto que es más sencillo revisar el Handbook de esta manera, y siempre se puede repetir todo desde cualquier parte con mayor facilidad. Yo lo haré desde mi Gentoo de siempre con la que escribo estos posts.

Preparar los discos:

Este paso siempre es muy personal, y en realidad siempre es un momento para reflexionar y detenerse a ver cómo deseas que termine tu partición. Como hemos dicho que vamos a mentenerlo simple, no vamos a usar LVM ni RAID, sino simple y puro ext4 en nuestras particiones. yo voy a formatear el usb que es el dispositivo /dev/sdb, evidentemente tienes que acomodarlo a tus necesidades.

Como podrán ver estoy usando fdisk porque pretendo usar MBR para mi sistema, otra tarea por resolver para los que deseen usar UEFI ;)

Crearé un swap simbólico y una partición simbólica home solo para que puedan seguir el paso más sencillo. /boot lo voy a dejar en el directorio raíz porque como mencionamos, lo mantendremos simple. (Ya vamos 1 comando)

Terminaré con una estructura parecida a esta:

terminaremos con w para escribir el disco. Dependiendo de las particiones que hayas hecho y los tipos de filesystem que hayas colocado, tendremos que crearlos con mkfs. Algo como esto:

(Este lo contaré como un solo comando porque es repetitivo ;) (Ya vamos 2 pasos).

Ahora vamos a montar nuestro nuevo sistema dentro de el sistema que ya está encendido. Para esto usamos la herramienta mount. (yo creé el directorio /mnt/gentoo, pero eso puede omitirse) (Ya vamos 3 pasos.)

Con esto ya tenemos el sistema preparado para el siguiente paso.

Stage3:

El stage3 es un comprimido que se descarga desde la página oficial de Gentoo, puedes descargarlo en tu navegador o desde consola, por temas de practicidad yo usaré uno que ya tengo descargado y lo ubicaré en la posición donde monté el sistema (/mnt/gentoo). (Ya vamos 4 pasos)

Solo quiero recalcar aquí que estoy descargando un stage3 con systemd ya incluído. Eso me ahorra bastante tiempo de recompilación puesto que ya varios programas vienen prediseñados con systemd y un perfil con systemd. También quité la opción v de tar para que no aparezca la lista gitante de data extraída, pero si la desean ver, pueden agregarla.

Ahora estamos en esta sección del Handbook

Si desean ver cómo queda todo después de descomprimir solo hace falta usar <code>ls</code> en el directorio, y tendrán algo como esto:

Make.conf:

Ya vamos a más de la mitad del camino, ahora solo tenemos que configurar nuestro corazón. Para esto pueden leer la guía de Gentoo, yo solo haré unos cuantos ajustes, les mostraré el antes y el después para que puedan ver cuánto es lo que yo he cambiado.

Antes:

Después:

Como pueden apreciar, no es mucho lo que agregas, lo más complicado de averiguar son los CPU_FLAGS_x86 que se pueden poner después de la instalación completa y cuando portage ya esté funcionando. De todas maneras es bueno dar un ojeada al Handbook y revisar los links que aparecen para poder tener más información. La lista de mirrors la dejo aquí por si acaso. Solo elijan el que más les acomode. De nuevo, como lo estamos manteniendo simple, vamos a tratar de no variar mucho las cosas.

Otro pequeño retoque que tenemos que hacer ni bien comienza la instalación es copiar la dirección de nuestro repositorio, esto lo logramos con el siguiente comando (Ya vamos… 5 pasos, 6 contando el que sigue)

Esto lo que hace es copiar la configuración necesaria para que portage pueda descargar el árbol de programas, que es la colección de ebuilds que permiten instalar cualquier paquete en Gentoo.

Con esto ya tenemos lo mínimo necesario para poder empezar a usar Gentoo en consola :)

Chroot

Justo ahora nos encontramos en esta sección del Handbook, vamos a copiar nuestro DNS actual, y montar una conexión entre el kernel que está corriendo y nuestro ambiente Gentoo en la partición. Esto lo vamos a hacer con los siguientes comandos

Cabe resaltar que algunas distribuciones tienen que montar unos cuantos sistemas extra, pero por lo menos las veces que he probado con esto ha sido suficiente. Si tienen dificultades, el Handbook todo lo puede ;). ( Ya vamos como…12 líneas de comando, pero este sería el paso número 7)

Ahora vamos a entrar a nuestro nuevo Gentoo… A partir de aquí ya estamos corriendo el nuevo sistema operativo por consola :D

El último comando es opcional, nos indica simplemente en la terminal que estamos dentro del chroot  cambiando el nombre para mejor distinción :) (¡Ya vamos 8!)

Lo primero que vamos a hacer en nuestro nuevo Gentoo es actualizar el repositorio, esto lo logramos con el comando emerge-webrsync. Es normal que aparezcan algunas alertas, es simplemente que se están creando los archivos o direcotorios que antes no existían.

Ahora vamos a configurar unos cuantos detalles antes de actualizar el sistema ( les explico por qué lo hago así en un momento). Primero nuestro perfil, si ya han visto mi post sobre make.conf, habrán podido notar el pequeño extra que dejé sobre los perfiles, ahora es momento de empezar a construir nuestro escritorio preferido, primero revisaremos qué perfil tenemos activo con eselect:

Como podemos ver, contamos con un pefril con amd64 y systemd por defecto (esto se debe a la opción que escogimos de stage3 en la página oficial de descargas). Para seleccionar un perfil podemos usar el número o el nombre, yo pondré gnome con systemd pero si desean kde necesitan escoger plasma. (Si desean otro, pueden dejarlo con el perfil de systemd. (Este es el paso 10 ;) )

El asterisco (*) indica el perfil seleccionado.

Ahora vamos a descargar unos cuantos programas que nos van a servir para terminar nuestra instalación de manera exitosa. Los escribo todos en el mismo comando para ahorrar números ya que me acerco a los 20 :P pero no se preocupen, los explicaré todos:

Bueno, esta es la lista de programas que estoy instalando (la lista en pantalla es más grande por sus dependencias):

  • gentoo-sources: Nuestro conjunto de código fuente para instalar el kernel en el paso siguiente.
  • linux-firmware: Muchos drivers necesarios para diversas computadoras (mi driver de wifi se encuentra en esta lista por ejemplo)
  • genkernel-next: Herramienta especialmente diseñada para facilitar el proceso de compilación de kernel y creación de initramfs (complejidades que escapan a este post, pero que son necesarias para correr systemd)
  • gentoolkit: Conjunto de herramientas de Gentoo que permiten un mejor manejo del sistema.
  • grub: Gestor de arranque, muy importante para poder comenzar a usar nuestro sistema.
  • vim: Simplemente me gusta más que nano (que es el que viene por defento :P ).

Dependiendo de la conexión a internet y la capacidad del procesador, esto puede tardar un buen tiempo. Tomen este tiempo como referencia para los siguientes pasos. ( Ya vamos 11 :O , falta poco ;) )

Ahora vamos a realizar unas configuraciones menores dentro del sistema:

Rápidamente comentando estas líneas por orden:

  • Generamos nuestra zona horaria. Normalmente viene en la forma zoneinfo/<Región>/<Ciudad>. Si necesitan ver su ciudad y región pueden dar un ls al directorio.
  • Generar nuestras locales. Gentoo viene por defecto con muy pocas locales, siempre es recomendable usar UTF-8 y nosotros lo que hacemos es agregar la de nuestro país a la lista y generar todas las de la lista. En mi caso solo he puesto una para que vean cómo se hace.
  • Poner nuestro nombre de host, cualquier nombre basta en este punto ;)

Para los más exigentes… ya vamos por el paso 12 :) ya falta muy poco.

Ahora generaremos el archivo fstab, para los que desconocen su uso, pues a leer en internet ;) pero para darles una idea general, es un archivo que se lee al momento de iniciar el sistema que permite montar todas las particiones en puntos estratégicos del sistema. Por ahora lo vamos a dejar con los valores de nuestras particiones.

Como podemos apreciar estoy poniendo los discos en que he colocado Gentoo. Probablemente ustedes usarán otros nombres (sda) y la cantidad de opciones y tipos que deseen. (Paso 13)

Ahora pondremos la clave de nuestro usuario root.

Si deseamos, este es un bueno momento para crear nuestro usuario o lo podemos hacer depués, pero recuerden montar su directorio home con la partición correspondiente. (Estos pasos pueden contarse como el número 14)

Esta vez estoy poniendo una clave de prueba, pero no se olviden de asegurar bastante bien a su usuario root y a los demás también. ;)

Ahora que ya hemos terminado con todos los pasos previos, el momento de la verdad…

Kernel

Nuestro kernel será un momento de reflexión y lectura, recomiendo bastante dar un vistazo a la documentación de Gentoo referente al tema, en especial tomaré un par de capturas a unas cuantas partes importantes, vamos adelante:

Con esto podremos empezar el proceso de configuración, que para systemd requiere de unos cuantos detalles particulares que mostraré a continuación.

Recuerden que la ruta aparece en la parte de arriba (la segunda línea celeste). Es necesario tener ambos init system como obligatorios <Y> para que se vea como [*].

Algunos módulos necesarios para poder trabajar con Wifi. Porque hoy en día todos usamos wifi :) cfg80211, mac80211.

Como podrán observar, mi tarjeta de red wifi es intel :) todo lo demás simplemente no me sirve, al menos no en mi laptop actual. Cada quién tendrá que usar lo que más le convenga. Recuerda que <code>lspci</code> y <code>lsusb</code> son tus amigos ;)

Una vez terminada la configuración guardamos el archivo con el nombre por defecto y salimos del menú. Ahora empezará a compilar nuestro kernel, sus módulos y se generará un initramfs para lanzar con systemd después.

Una vez terminado, y si por algún motivo les aparece una advertencia al finalizar la compilación, recuerden que pueden volver a repetir el proceso. La configuración se almacena por lo que probablemente solo tengan que buscar las opciones que aparezcan con MAYÚSCULA mediante “/” y cambiar los valores por los recomendables. (Este es nuestro paso 15)

Una vez instalado nuestro nuevo kernel, es hora de decirle a grub que se prepare para correr el sistema. Como pueden ver en la imagen anterior hay un pequeño párrafo de WARNING, nos está informando que nuestro sistema tiene un filesystem distinto de ext2. Esto, y un detalle más, lo vamos a configurar en nuestro grub antes de instalarlo. En el archivo /etc/default/grub hacemos las siguientes modificaciones:

Con esto estamos diciendo a grub que al momento de iniciar el sistema se prepare para usar ext4 en nuestro root ( ) y que el sistema comience con systemd en lugar de OpenRC. Ahora podemos instalar grub en el disco :) ( pasos 16 y 17 hasta ahora ;) )

Ahora vamos a actualizar el sistema por completo. Esta opción puede tardar cierto tiempo dependiendo del perfil seleccionado y la cantidad de paquetes que necesiten ser recompilados. Como los stage3  son generados cada cierto tiempo, es posible que unos cuantos paquetes necesiten actualizarse en comparación con el resto del equipo ( que debería estar lo más actualizado posible) Para que puedan comprender los comandos que usé tendrán que leer man emerge ;) ¿Pensaron que les dejaría todo totalmente masticado para copiar y pegar? :)

Listo, ya casi estamos en la meta :) ahora solo nos falta nuestro entorno de escritorio, en este caso pueden usar gnome conmigo, o elegir plasma, o el que mejor se les acomode :) Este proceso si va a ser bastante largo, por lo que les recomiendo dejar corriendo la máquina por la noche, así cuando despierten ya podrán empezar a usar su sistema ;) (Paso…18 el anterior y ahora el 19)

Ahora viene el proceso que no voy a poder controlar al 100% y en el que es más que probable que les aparezcan errores. Debido a que el conjunto de paquetes es bastante grande, es posible que existan conflictos con los USE flags, así que les voy a enseñar a resolverlos ;)

Con este comando emerge -av <paquete> estamos pidiendo a portage que calcule todas las dependencias, y probablemente al final obtendremos algo parecido a esto.

Presionamos No. Para hacerse una idea de lo que acaba de suceder. Nosotros tenemos un stage3 que vino compilado con distintos USE flags, ¿recuerdan?. Ahora que hemos cambiado el perfil, hemos cambiado también los USE flags que venían por defecto. y ahora portage nos está diciendo que existen USE flags que necesita tener para poder compilar la lista de programas que le hemos pedido (en mi caso gnome).

Para resolver estos problemas vamos a crear un archivo con el nombre del programa (para poder encontrarlo después más fácil) dentro de la carpeta /etc/portage/package.use. (Si la carpeta no existe, pueden crearla con el nombre exacto)

Como en mi lista tengo dos, voy a hacerlo de la siguiente manera:

Con esto tenemos todo listo para volver a intentar :) pero antes de eso, solo quiero aclarar que yo pongo el nombre genérico del programa al principio, después los USE flags personalizados, pueden ser 1 o más, el (-) de adelante dice que lo desactive y cualquier línea que comience con # es ignoada por portage. Sencillo ¿no? :) Esta es la magia de la personalización de Gentoo. Pero el trabajo con portage lo voy a dejar para otro post porque este ya está bastante largo :) (Paso 20, troubleshooting :) )

Volvamos a probar el comando de instalación:

Como es evidente, no hemos acabo bien el paso 20 :P pero ahora estamos frente a 2 errores nuevos que me parecen una estupenda oportunidad para seguir explicando un poco de portage ;)

Los KEYWORD son las etiquetas que tiene un programa que indican qué arquitectura y bajo qué nivel es soportada. En este caso “~amd64″ es la rama “no estable” de amd64. OpenSSL es un programa que siempre viene con una que otra actualización (es muy importante tenerlo actualizado y libre de problemas) así que lo mejor será usar la versión “no estable”. Por defecto los perfiles de laptop soportan “amd64″ o “x86“. Para cambiar esto, es necesario agregar la variable ACCEPT_KEYWORDS=”~amd64″/”~x86″ dentro de make.conf (como dije que voy a mantener simple el post, no lo toco más que esto).

Ahora a lo nuestro, al igual que en el paso anterior, es necesario crear la carpeta package.accept_keywords en /etc/portage y agregar el mismo formato pero con la variable KEYWORD que vamos a usar.

Ya son todos unos expertos en portage ;) ahora vamos a resolver el último problema que hemos visto… cambios de mask. Si son un poco observadores podrán ver lo que les muestro en la imagen y notar que es bastante sencillo.

cabe resaltar que en este archivo, es necesario escribir explícitamente la versión que vamos a usar. En los anteriores es opcional o se puede comenzar con “>=tipo/paquete-versión <variable>” para decir a portage que a partir de esa versión se apliquen los cambios. Volvamos a probar nuestro comando de insalación :)

Nunca me salen tantos errores al momento de instalar pero es estupendo para poder cubrir todo tipo de acontecimiento que les pueda surgir , jajaja :) miremos lo que me apareció:

Aquí portage me está diciendo que tengo múltiples versiones del mismo programa y están en conflicto, ¿recuerdan gentoolkit? Lo instalamos junto con el resto de nuestros programas hace poco. Vamos a usar uno de sus comandos   eshowkw para ver un poco mejor lo que tenemos ahora.

Como podemos ver, ya tenemos una verisón de openssl instalada, el SLOT 0, y nosotros queremos instalar la que tiene la [M] que es es SLOT 0/1.1… el / indica que o es una, o la otra, pero no las dos juntas.

Como vamos a actualizar todos los programas, primero eliminemos el SLOT 0 para poder actualizar de manera sencilla.

como podemos ver, van a quedar un par de librerías en el sistema porque solo hemos borrado el ejecutable, para eliminar las librerías también debemos usar otro comando, pero por ahora lo vamos a dejar como está ;)

Volvamos a probar nuestro gnome :)

¡Todo listo! Y sin querer también cubrimos un grupo de posibles problemas que podrían enfrentar al momento de instalar :)

Ahora lo dejaremos instalando toda la noche, es bastante como podrán ver, casi 1 Gb de descargas :)

Grub

La instalación de grub es bastante directa grub-install /dev/<dispositivo>

Solo cabe mencionar que deben tener claro que es el dispositivo completo y no una partición. Ponerlo en una partición puede hacer que después no funcione nada. Como en otros lugares, se puede descargar os-prober para poder buscar sistemas operativos en otros discos. El comando que muestro tiene unos cuantos defectos por lo que lo estoy corriendo en un USB y debería ser en un disco duro, pero no deberían salir errores con ustedes.

Ahora, ¿recuerdan el paso configuración de grub de hace poco? pues ahora nos viene a ayudar. Tenemos que crear la configuración de nuestro grub para que arranque con systemd y use ext4 como partición para la raíz.

Listo :) ahora ya tenemos grub configurado y listo para arrancar a la siguiente vez que encendamos el equipo. (Terminamos le paso 21)

El último es simplemente puro detalle :) vamos a activar nuestro servicio para poder entrar en el modo visual a la siguiente. También el servicio de NetworkManager para tener nuestro internet ;)

Disfrutar :)

Bueno, hemos llegado al final y creo que solo me pasé por un paso :P , si no tienes hardware de drivers complicados, si has seguido esto de la mano al Handbook, si has podido resolver tus problemas en el camino… ¡FELICIDADES! Eres de los privilegiados que han experimentado la instalación de Gentoo en su máxima expresión :)

Ahora ya es demasiado lo que he escrito, y seguramente empezarán a surgir detalles que tendré que poner en futuras ediciones del tutorial, pero espero que les ayude a comenzar este proceso de instalación :) Conmigo será hasta la siguiente y con otro post que ayude a disfrutar más de Gentoo y su personalización. Evidentemente también empezaré a escribir otros temas que me apasionan :) Git y el Kernel son proyectos en los que colaboro (hay otros más también) o deseo hacerlo, y si gustan les puedo contar un poco del proceso :)

Saludos,

Gentoo: Porque nada es perfecto

Bueno, ya he conversado de mil y un beneficios de Gentoo Linux, y así como yo soy quien les ha contado lo bueno, pues también seré yo el primero en contarles lo no tan bueno, porque prefiero que lo escuchen de mí a que vengan las críticas de otro lugar y no sepan qué responder :) Sin más que agregar, empecemos:

¿Gentoo es mejor?

No, esta es una respuesta muy sencilla :) ninguna distribución es mejor ni peor que otra, cada una tiene su estilo, su filosofía, y su forma de proceder. Evidentemente habrán filosofías que acomoden mejor a distintos tipos de usuarios, pero no por eso podemos calificar de mejor o peor a una u otra distribución. Esto debe quedar claro desde el principio, yo he expuesto algunos de los beneficios que yo considero importantes, y que me han llevado a mantenerme en Gentoo sin necesidad ni deseo de saltar a otra distribución.

lista de distribuciones Linux
Distribuciones Linux

¿La comunidad es poco amigable?

Tampoco, y esta es una triste concepción que se ha esparcido por todo el mundo. Gentoo, y su comunidad, está formado por personas muy talentosas, y al mismo tiempo personas muy ocupadas, gente que colabora desarrollando para Nvidia, Google, Symantec, y mil lugares más, colaboran en Gentoo. Evidentemente todos tenemos cosas que hacer y si en algún momento buscas ayuda y sientes que no te escuchan, pues debes comprender que todos estamos ocupados trabajando, pero eso no debe desanimarte, al contrario. Si tu tienes un problema, es probable que alguien más lo haya tenido antes que tu (a menos , claro, que tu estés desarrollando una tecnología tan de punta que nadie más en el planeta la conozca ni domine a perfección todavía) y si alguien ya lo tuvo, es 80% seguro que alguien más ya lo resolvió. Sigue intentando en la documentación, en los foros, en Google, mil y un lugares donde encontrar información de calidad que pueden ayudarte. Al final del día, habrás aprendido mucho más por tu investigación que lo que podrías retener por la solución que alguien más te dio por el IRC.

Mentalidad de compilador:

Hace poco mandé mi primer correo a la lista de correos de Gentoo, como en proyectos grandes como el Kernel o Git, Gentoo también mantiene listas de correos para llevar un archivo público de lo que se desarrolla y lo que se decide en la comunidad. Yo propuse algo que consideraba bueno para la comunida, así que mandé un RFC (Request for Comments) con mi idea. Al poco tiempo empezaron a llegar los peros, y las alertas, como si fuera un compilador de C. Y mi idea resultó no ser tan buena como yo pensé. Seguramente los developers más experimentados tenían sus fundamentos para decirlo.

¿Eso me va a detener de volver a manda otro RFC? En absoluto, lo que todo el mundo debe entender es que cuando se trabajan en comunidades tecnológicas, lo más común es solo advertir sobre posibles errores (como los compiladores) porque cuando algo está bien, no hay necesidad de decir más (como los programas de Linux).

Así que si en algún momento mandan una idea para mejorar la comunidad y esta no es del todo bien recibida, ánimo, la idea puede tener que mejorar, pero las objeciones no son contra la persona, solo contra la idea. Eso al final del día te enseña a pensar mejor y saber argumentar tus ideas, porque si puedes hacer frente a un pero, entonces ya has ganado media batalla.

¿Gentoo es difícil?

Bueno, de verdad espero que con los otros post hayan podido ver que no es ciencia termonuclear (para los que sepan de eso cambien la anterior materia por algo más difícil incluso :P ). Al final de cuentas será tan difícil como tu lo hagas, si decides probar una configuración hiper experimental, probablemente tendrás muchos más problemas que el resto, pero al final del día podrás decir que dominas mucho más un tema :)

El mayor problema de todos

Este si es el problema que he visto en todo el tiempo que llevo en Gentoo… la falta de usuarios, parece ser que en estos días, nadie (o al menos muy poca gente) desea conocer realmente lo que Linux tiene para ofrecer, lo rápido es más fácil (esto es una mentira) y muchas veces optamos por dejar de pensar para simplemente usar (eso me recuerda mucho a otros sistemas operativos que no voy a mencionar aquí :P ). Es por eso que si ven que el model Rolling Release no está a su 100%, o que algún que otro paquete no se encuentra en el árbol de Portage, pues en lugar de perder la fé, ¡puedes ayudar a crecer!

Gentoo tiene muchas formas en las que puedes ayudar a la comunidad, aunque un requisito indispensable es poder hablar/escribir/leer inglés (dado que es una comunidad internacional, el inglés es un lenguaje que une a todos (o a la mayoría al menos)) dentro de nuestros canales de IRC (no estoy seguro si hay un post sobre IRC, pero sino después haré uno ;) )

Dejaré las formas de contribución para otro post, porque son muchas :) y no necesariamente necesitas ser un experto programador de python, o bash, para poder ayudar :) se los dice alguien que no domina ninguno de estos lenguajes a la perfección, pero siempre está dispuesto a aprender sobre algo nuevo :)

En resumen:

Bueno, me sentía obligado a comentar esto antes de lanzarlos al mundo de Gentoo por completo, siempre he creído que para tomar decisiones ( y Gentoo se trata de decidir muchas cosas) es necesario conocer las dos caras de la moneda. Espero que tras este breve post puedan tener un marco un poco más amplio de lo que es la comunidad hoy por hoy, y cómo integrarse a nuestra filosofía. Espero pronto tener el tutorial de instalación y conmigo será hasta otro post.

Saludos,

Gentoo: ¿Por qué no necesitas el ISO de Gentoo para instalarlo?

Bueno, ya nos estamos acercando, prefiero escribir rápido estos pequeños posts para que no se molesten conmigo por no estar escribiendo la guía en estos instantes :p , pero deben comprender que hay tanto por explicar en Gentoo que dejarles el script no me serviría de mucho si después no pueden controlar todo ese poder.

Imágenes ISO:

Todos conocemos las imágenes ISO (bueno todos los que nos hemos enfrentado a una instalación Linux al menos). Esos pequeños ( o ya no tan pequeños como el caso de Ubuntu) comprimidos que almacenan todo el sistema base y lo replican en otra máquina.

El ISO de Gentoo:

El ISO de Gentoo es bastante reducido (270 Mb en modo consola, 2 Gb en modo Live). Pero si se detienen a revisar la página oficial de descargas lo primero que notarán es que tanto el minimal como el live, son actualizados con poca regularidad. Al menos comparado con el stage3 (del cual hablaremos más adelante).

ISO de Gentoo

¿Es necesario?

Para ser 100% sincero con ustedes, no, no es necesario descargar el ISO de Gentoo para instalarlo. Es más, dirán los que ya lo han probado, muchas veces el ISO viene con bastantes limitaciones (por ejemplo el soporte para UEFI, el minimal ISO no cuenta con soporte UEFI). Además, solo es una consola ( se los dice alguien que hace 95% de sus actividades por consola) y hay mejores maneras (al menos más sencillas) de hacer una instalación completa de Gentoo.

Lo que yo hago:

Bueno, este es mi secreto, particiones… ¿Particiones? seguro se estarán preguntando justo ahora. Sí, particiones. Desde mis días en Arch siempre agarré cariño a MBR, con este label hice mi primer instalación de Arch y dado que nunca he necesitado una cantidad descomunal de particiones o he hecho un dual boot con Windows, no he tenido la necesidad de generar mi sistema sobre UEFI.

Lo que tengo justo ahora en mi computadora es un conjunto de 5 particiones, como me da flojera escribir todas, aquí les mando una foto de mi disco.

Diseño propio. Christopher Díaz Riveros

(por cierto, siempre me ha gustado mostrar lo que yo uso, prefiero no hablar solamente de la teoría, sino mostrar lo que para mí funciona, esto puede que no acomode a todos pero si en algo puedo ayudar con esos casos particulares, me avisan)

Como pueden ver, tengo 6 particiones dentro de mi disco duro, usando MBR puedo tener 3 primarias, y gracias a la extendida puedo agregar un poco de SWAP a mi máquina. Además de haber separado mi directorio /home para que en caso de emergencia, mi información no se pierda junto con el sistema. Esto es bastante útil cuando de la nada deja de funcionar tu computadora, puedes simplemente instalar desde cero y montar tu home al final, pan comido :)

Como podrán ver, como todo buen fanático de la seguridad, también tengo mi Kali Linux instalado, y un siempre útil Arch linux. Ahora les comento cómo es que uso estos.

Arch como medio de rescate:

Como pueden inferir por el título, mi Arch es el usb de rescate en caso de emergencia, siempre que sucede algo con Gentoo que no puedo reparar desde el mismo Gentoo, entro a Arch, monto el disco duro de Gentoo y empiezo a arreglar cosas. Además, me gusta mucho un juego llamado Bombsquad que está disponible en AUR ;) siempre que puedo lo juego con mi familia o mi enamorada y mis amigos. Por cierto, solo para dejarlo claro, el Arch también cuenta con GNOME si es que se preguntan si lo he dejado en consola :P

Como Gentoo no necesita de ningún medio de instalación propio, ustedes pueden elegir instalarlo desde cualquier lugar, Arch, Ubuntu, CentOs, etc etc… genial, ¿no es cierto? :)

La magia está en el stage3

El stage3 es un comprimido que contiene todo el árbol de Linux necesario para instalar un sistema. Es gracias a este comprimido que podemos instalar directamente desdse otro sistema operativo. La única condición para usarlo de manera adecuada es que el punto de montaje esté vacío al momento de instalar y recordar que ese será nuestra raíz para el siguiente sistema Gentoo que vamos a construir. Para que se hagan una pequeña idea de lo que consume mi máquina en su sistema aquí les dejo la cantidad de disco usado:

Diseño propio. Christopher Díaz Riveros

Como pueden ver, con 50 Gb es más que suficiente, en realidad es algo exagerado diría yo, y de estos 50 yo uso 8 Gb, incluyendo programas pesados como Virtualbox, Google-chrome (evidentemente tenía que estar disponible en la distribución que ayudó a nacer a las Chromebooks ;) ) y bueno, mi suite de GNOME y uno que otro programa más, pero no nos desviemos del tema…

Una vez descomprimido el stage3, todo lo que hace falta es empezar a hacer los retoques, pero esto lo vamos a dejar para la guía oficial :P

En resumen:

Bueno, ya les conté un poco más sobre cómo se instala Gentoo, su versatilidad le permite poder ser instalado desde distintas distros (algo que creo que muy pocas pueden decir) y al mismo tiempo permite generar un espacio reducido de trabajo. Justo ahora estoy pensando en escribir un último post antes de comenzar la guía. Al buen ritmo que llevo estos días, espero que la guía esté disponible muy pronto :) solo estoy asegurando que no queden cabos sueltos antes de comenzar. Saludos,

PS: Para ver otros posts, mejor pongan en buscar más del autor porque sino se me van a llenar de links :P