Tuesday, March 1, 2016

¿Cómo escojo una distro me recomiendan? Parte II

¿Cuál distro te recomiendo? La que resuelva tus necesidades. Tenés que definir cuáles son tus necesidades. Tus necesidades están compuestas por 
  1. Tus necesidades y expectativas. 

  2. Las limitaciones de tu hardware.


Tus necesidades como usuario.  

Tenés que considerar estas cosas:  
  • Tipos de release:
    • Estable, fijo o estándar: ya fue testeado, auditado, probado, certificado que no dará pedos -a menos que seás travieso y hagás cambios significativos en archivos de configuración, o que usés software o paquetes que no están en los repositorios oficiales de esa distro. En estas, usualmente todo el equipo de desarrollo aprobó su lanzamiento; todos hiceron un "thumbs up". Idealmente, querés un release oficial. Las organizaciones desrarrolladoras programan y anuncian fechas de lanzamiento. Dentro de estos releases, hay una subdivisión:
      • LTS ("Long Term Support"): reciben desarrollo y/o soporte técnico adicional por cierta cantidad de años; el soporte usualmente es un extra pagado (Canonical ofrece una versión Ubuntu LTS, por ejemplo).
    • Versiones Pre-Alpha, Nightly Builds, Alpha, Beta, Release Candidate, experimental, en desarrollo o términos afines que se refieran a lo contrario de un release oficial. Para simplificarlo, son un  "prototipo", un trabajo en progreso; son orientadas a desarrolladores, miembros respetados de la comunidad, programadores, auditores, etc. y  seguramente tendrán bugs, pedos, errores, lentitud, pantallazos y tormentas de pupú de vez en cuando. Es así porque no están listas para el usuario final. Simple. Y los que saben de desarrollo, pueden experimentar, auditar, e incluso reparar bugs, agregar cosas, modificarlas y mejorarlas. Es como si le diera mi prototipo de automóvil a un ingeniero mecánico para que haga "peer review". Si no sos un desarrollador, te recomiendo que te alejés de ellas, o al menos NO LAS USÉS COMO tu distro principal/en tu pc principal, por paz mental.
    • Rolling release: distribución en actualización constante.
    • Todo esto, tiene que ver con el ciclo de lanzamiento de software. Wikealo para aprender más, si te interesa.
  • Apariencia (influenciado por mayor o menor medida por tu hardware y habilidades técnicas) :
    • Old School.
    • Simple, minimalista.
    • Elaborada.
    • Con animaciones y efectos fluidos.
    • Transparencias.
    • Sin efectos en absoluto.
  • El propósito de tu PC: 
    • Navegar por la web
    • Ver porno
    • Jugar en FB
    • Jugar cosas de varoncito.
    • Revisar tu email.
    • Universidad.
    • Trabajo.
    • Desarrollar programas.
    • Diseño gráfico.  
    • Fapping a 1080p ó 4K.  
    • Crear, renderizar, etc. 
    • Desarrollar, programar.
    • Ver pelis.
    • Escuchar música.
    • Mezclar música. 
    • Usarla para tu trabajo.
  •   Nivel de dificultad: 
    • Usuarios domésticos (mejor conocidos con los "normalitos"), principiantes en Linux que quieren aprender Linux, estudiantes de programación/
    • Usuarios familiarizados con GNU/Linux, entusiastas,
    • Usuarios avanzados: sysadmins, hackers, desarrolladores de GNU/Linux.
  • Otros factores: 
    • Similitud a Windows o Mac OS para facilitar la transición a GNU/Linux.
    • Curva de aprendizaje pequeña.
    • Evitar usar le Terminal tanto como sea posible.

Monday, February 15, 2016

¿Para qué compilar desde fuente?


Sigo sin entender para qué cojones debo de compilar.

Así pensaba yo también. No tiene sentido usar algo si no entiendo primero su utilidad. Te comparto un ejemplo/experiencia que tuve. 

Me moví a Arch porque busco algo más ligero que Freya y a la vez, algo que me ayude a aprender sobre la instalación y mantenimiento del sistema operativo: algo que me permita "tener control" de los detalles, para aprender de estos. Como sabemos, Arch requiere ser instalado "desde el suelo": el sistema base no tiene GUI, es sólo el prompt y una CLI. Vos agregás componentes según tu voluntad y preferencias.
Estoy usando Awesome WM en lugar de un Destkop Environment completo. También uso urxvt como Terminal, en lugar de una terminal pesada. Esto hace mi escritorio ligero. Ahora bien, extraño la transparencia en Terminal, como la de Pantheon-Terminal en Freya, porque permite trabajar en Terminal sobre tu navegador por ejemplo, y leer cosas mientras trabajás en Terminal. Esto me lleva a un predicamento: 

  • Podría instalar Pantheon-Terminal en Arch, pero no quiero algo tan pesado ni con barra de menú porque es un desperdicio de pixeles... más aun en una laptop. Quiero ahorrar pixeles y dedicarlos a más contenido, no a botones.
  • En todo caso, la selección de Terminal no es el problema; Awesome WM no soporta transparencias de manera nativa, sino que require un "composite manager", gestor de composición de ventanas para lograrlo. Esto significa que puedo usar virtualmente cualquier Terminal y tener transparencia, siempre y cuando tenga un Composite Manager.
Después de documentarme, aprendí que el Composite Manager llamado Unagi, es ligero y de hecho,  fue desarrollado para Awesome WM. Unagi es un paquete adicional en Arch (y diría que en muchas otras distros). No toda la gente lo usa ni lo necesita, así que no tiene sentido para los desarrolladores de Arch, incluirlo como paquete oficial en el sistema base; hacerlo sería abusar del almacenaje de quienes no lo usarán: esta sería una definición justa del término BLOATWARE. Por eso Unagi está en el AUR, el Repositorio de Usuarios de Arch; acá hay software de calidad, en tarballs, listo para ser descargado, compilado e instalado manualmente por quien desee usarlo. 

Así que, para ejemplificar los pasos que te compartí antes, hice lo siguiente:


$ wget https://aur.archlinux.org/cgit/aur.git/snapshot/unagi.tar.gz
$ tar xvf unagi.tar.gz
$ cd unagi 
$ cat PKGBUILD 
$ makepkg -s 
$ sudo pacman -U unagi.tar.xz

Explicación: descargué el tarball (paquete comprimido), lo extraje, creó un directorio con contenido; me moví a ese directorio, leí el script de instalación o PKGBUILD (es recomendado leer el script de instalación -si entendés de bash-scripting :v para confirmar que el script está limpio y no tiene nada malicioso.); compilé el paquete asegurándome de forzar dependencias a ser instaladas (el script incluye referencias a esas dependencias), e instalé el paquete... aunque pude ahorrarme la última línea y usar $ makepkg -sri  en su lugar.



Y listo. Ahora que tengo Unagi instalado, puedo trabajar en las configuraciones apropiadas dentro de Awesome para hacer que mi terminal sea transparente. Y esa, es otra historia. Hasta pronto :)

Overview: Instalar paquetes desde el código fuente.

A veces no encontrarás cierto software en los repos oficiales de tu Distro. Esto es por diversas razones: a lo mejor es software privativo y ponerlo en los repos oficiales contradice la filosofía de la Distro, o no es soportado directamente porque no es totalmente estable o compatible con la Distro o su DE oficial; tal vez está en versión Beta o Alfa incluso, etc. Sin embargo, siempre podés instalar ese software, si vas a un repo no-oficial de tu Distro (como el AUR en Arch) o si vas a un repo externo. Lo que tenés que hacer es algo llamado "compilar el código fuente" (compile/build from source).

Vamos a detallar las instrucciones para compilar en la CLI desde Arch. En esencia, el procedimiento total es igual en toda Distro, pero algunos comandos cambian. 

Pre-requisitos.

Antes de todo, necesitás: 
  • Un usuario regular. Por motivos de seguridad no podés instalar paquetes del AUR o repositorios externos, desde Root. 
    • Truco personal: tengo un directorio dentro de /home/usuario exclusivo para descargar paquetes fuente y compilarlos. $ mkdir ~/AUR_downloads
  • Que Arch tenga instalado el base-devel (devel= "development"; o sea, un conjunto de paquetes para desarrollo): $ pacman -S --needed base-devel
    • Específicamente, los paquetes que se requieren son: 
      • gcc (Compilador GNU para C, C++, Java, etc.)
      • wget (para descargar los paquetes comprimidos, alias "tarballs")
      • makepkg (para compilar localmente)
      • fakeroot (como dije en el punto principal anterior, instalar como root no es recomendado ni permitido; fakeroot "emula" un ambiente root para instalar paquetes desde código fuente).
         

Procedimiento.

Una vex tenés todo esto, podés instalar paquetes no-oficiales. En esencia, el proceso es simple: 
  • Descargar el paquete, o tarball (esto es un archivo .gz; usás wget).
    • $ wget foo.gz
  • Descomprimir/extraer el paquete ( se usa $ tar xvf ); un directorio nuevo es creado (Por eso tengo un fólder sólo para paquetes, para mantener todas los tarballs y los directorios extraídos organizados) con algunos archivos; PKGBUILD, README y otros. compilados.
    • $ tar xvf foo.gz
    • $ cd foo
  • Compilar e instalar el paquete (en Arch se usa $makepkg; en otras distros esto puede variar); esto producirá un archivo con el nombre del paquete, en formato .xz). Se puede con una de estas formas:
    • $ makepkg -sri   (compila, resuelve dependencias e instala).
    • O de esta forma: 
      • $ makepkg -s
      • $ sudo pacman -U foo.xz
  • Regocijarte y fappear a lo grande. 

Tuesday, January 19, 2016

Menos es más: Linux para equipo legacy y de gama baja

frugalidad.

(Del lat. frugalĭtas, -ātis).
1. f. Templanza, parquedad en la comida y la bebida.

A veces no necesitás más RAM, un CPU* más costoso, una PC nueva o una versión más reciente de Windows. A veces sólo necesitás reconsiderar tus paradigmas y hábitos. A veces no necesitás más mierda, al contrario; a veces lo que tenés es suficiente, y en algunos casos incluso necesitás dejar ir cuanta mierda sea posible de tu vida en lugar de envidiar a otros y ansiar más. 

Lo que me gusta de Linux en comparación a sistemas privativos, es su flexibilidad. Podés usarlo en una máquina de mil dólares como podés instalarlo en un equipo viejo o de gama baja y aun así tener una PC funcional que te dure largo rato. 

Vamos a considerar equipo legacy y de GAMA baja a: 
  • 2GB de RAM o menos, (en legacy, DDR2 o anterior).
  • Procesador de dos núcleos actual, o uno socket LGA775 o Socket AM2 (estas plataformas fueron lanzadas entre el 2005-2006)
  • Video integrado o incluso, una gráfica discreta entry-level
  • Interfaz SATA II - IDE 
  • Laptops doble nucleo de bajo consumo con procesadores AMD serie A/Thurion/Zacate/Athlon, o Intel Celeron/Pentium/Atom de generaciones viejas. Cualquier cosa que tenga cuatro threads, podemos o un Turbo Booster, podemos considerarlo algo de gama mayor.

 

 

Esencialmente, lo que buscás es EVITAR EL BLOATWARE.

 

Para principiantes, instalar una distro con cualquiera de estos entornos ligeros/window managers:

    • LXDE
    • XFCE
    • LXQT 
    • Mate
    • Openbox
Listo. Para un novato que quiere algo simple, listo y fácil de usar; eso sería lo que busca. Podemos mencionar algunos ejemplos (pero sigo recomendando, buscar en línea por más alternativas en distrowatch.com):

Xubuntu, Lubuntu, BunsenLabs, CrunchBang Plus Plus (derivados del extinto y mítico Crunchbang, desarrollado por Corenominal), Fedora XFCE spin o LXDE spin, Linux Mint, Puppy Linux, Porteus, Point Linux.


Para novatos atrevidos e intermedios  instalar un sistema base; esto provee mejor control sobre qué instalar/usar, y aprovechamiento de recursos... aunque requiere mayor conocimiento y tiempo.

  • O sea, la pura CLI, y comenzar a construir su propio escritorio desde ahí.
    • Debian.
    • Arch
      • Incluso si no instalás Arch, su Wiki es asombrosa.
    • Slitaz
    • Slackware
    • Gentoo
      • También tienen documentación excelente.
    • Ubuntu mínimo
      • Francamente, he encontrado info útil en su foro angloparlante.
    • Cualquier cosa que diga "CLI" o "No GUI" cuando completás su instalación.
  • Instalar un gestor de ventanas en lugar de un entorno completo, como por ejemplo:
    • Flotantes:
      • Blacbox o sus derivados a continuación:
        • Openbox.
        • Fluxbox.
    • Tiling o de "fichas/bloques" (podrán parecer feos o "simples" a quienes vienen acostumbrados al maquillaje y demás superficialidades: 
      • Awesome Window Manager (también es flotante)
      • DWM
      • Xmonad
      • i3 
      • JWM (usado en Puppy)
  • Usar aplicaciones minimalistas y de preferencia, basadas en Terminal en lugar de una GUI (particular , por ejemplo:
    • midnight commander como visor de archivos/directorios ($cm)
    • $top o $htop en lugar de Gnome System Monitor. 
    • nano/vim/emacs en lugar de gedit, scratch, atom, etc. Aquí hay argumentos sólidos por parte de programadores para seguir usando un editor de texto pesado (se integran con sus IDEs, tienen autocompletar, etc.); para un novato, sería sano seguir mi recomendación.
    • Hay incluso, navegadores en CLI: Lynx, por ejemplo. 

  • Usar la jodida CLI, CLI, CLI. 
Esto te va a permitir ahorrar espacio en disco y evitar desperdiciar segundos al arranque con cosas que no necesitás/no usás. Naturalmente, para lograr esto, necesitás más tiempo, conocimiento, etc.






*Cuando digo CPU, no me refiero al "cajón", "case" o "chassis", me refiero al microchip, microprocesador, el Intel, AMD, VIA, ARM, de un computador.

Monday, January 18, 2016

Problemas.

La vida es la suma de todo lo que sucede y de lo que nosotros y el colectivo, tenemos conocimiento. Parte de la vida, consiste en problemas; son parte de ella y son inevitables; esto no es una opinión ni una cuestión democrática... los problemas existen y ya. Así como en la vida, en el campo de la tecnología también tenemos problemas. Y respecto a ellos, podemos: 

• no hacer nada.
• dejar al problema ser, si es leve.
• pedir ayuda.
• esperar que alguien más lo resuelva.
• reiniciar la aplicación o la PC - a veces esto funciona.
• formatear la PC para ahorrarnos la frustración y evitar buscar la solución.
• comprar otra PC -como algunos de mis amigos hacen.
• hacer distro hopping.
• pagar por soporte. 
• hacer muchos clicks cuando la PC se traba y pretender que estamos resolviendo el problema mientras la PC toma su tiempo para resolver el problema por su cuenta (es un equivalente a orar en el mundo real).
• DIY: do it yourself.

Yo opto por el DIY; se requiere un poco de pelotas extra, el hacer las cosas por cuenta propia. Esto no te hace "más especial" o "úniko", pero te aporta cosas buenas como ser humano. Te da paciencia, ejercita tu mente, te vuelve más resiliente a las frustraciones, te hace pensar de forma no-convencional, simplificar las cosas, descomponer los problemas, pensar en distintas maneras de resolver un mismo problema, te vuelve recursivo, creativo, pragmático, organizado, etc. Te vuelve  un poco menos lento y dependiente de otros. 

Ahora, tener la buena voluntad no basta. Estoy seguro que más de alguna vez, muchos de nosotros tuvimos las intenciones de resolver un problema con nuestras distros alguna vez y luchamos hasta que nos venció. Esto pasa, no porque el problema sea imposible de resolver (sí existen problemas imposibles, pero son muy inusuales), sino porque nos hace falta método, experiencia y conocimiento necesarios para resolverlo. 

Para todo qué, hay un cómo. Esta entrada no es un manual técnico como tal, sino que constituye un resumen de lo que he aprendido en mi vida laboral como técnico en hardware.


Para resolver un problema, primero tenés que entender el problema.

Una de las cosas que quiene trabajamos en esta industria aprendemos con el tiempo, la práctica, los clientes y la experiencia es eso: identificar el problema es lo primero. Esencialmente se trata de procurar un diagnóstico correcto del problema, para proveer la solución efectiva. No se puede poner la cola al burro si no se sabe dónde está el jodido burro. 

Sólo este primer paso involucra un montón de cosas de qué hablar. Tal vez luego ampliemos la explicación. 


Una vez hemos identificado el problema, tomamos acciones correctivas.

Una vez sabemos cuál es el pedo, sus causas e implicaciones, buscamos las soluciones; puede que ya existan soluciones a él; puede que haya una sola o varias. Lo importante es, tomar acción e implementar las soluciones que tenemos disponibles. Este paso no es realizable, o si lo es, no es eficiente ni efectivo si no hemos cumplido con el anterior. Ojo.


Una vez resuelto el problema, implementamos acciones preventivas.

Curarse en salud. Esto varía según la causa del problema y el control que tenemos de las variables del entorno: si tuvimos un un problema causado por un controlador de video y resolvimos usando otro controlador, pues será inevitable que surja el mismo problema si nos vemos forzados a reinstalar el mismo sistema operativo (aunque aquí ya no sería tan problema, porque tenemos conocimiento previo, y resolverlo debería entonces, implicar menos tiempo y esfuerzos). 

Las acciones preventivas pueden ser tan simples como anotar las cosas que hicimos para resolver el problema y guardarlas en un lugar seguro (el artículo anterior es una forma de acción preventiva que tomé respecto a un reto/problema que resolví), hasta reportar un bug, educar a un usuario, crear documentación que antes no existía al respecto, cambiar código fuente, implementar un proceso nuevo, replantear un algoritmo, etc. Cualquier cosa que te ayude a evitar en el mejor de los casos o mitigarlo en caso de reincidencia a futuro.


Cierre. 

El closure es algo necesario; los cierres implican el fin de un ciclo y el inicio de otro. Hacen bien tanto mental como emocionalmente. En todas las culturas, sucesos importantes, celebraciones y demás eventos, y cada uno tiene un cierre. Ayuda al individuo para recuperar el sentido de perspectiva respecto al tiempo y el espacio. Personalmente, una vez haya resuelto un problema o no haya podido resolverle (de nuevo, no todo puede resolverse), hago una evaluación personal: ¿qué aprendí de esto? ¿cómo me beneficio de ello? Al final, ganar o perder no importa tanto como sacar lo mejor de ambas circunstancias para uno y los demás. Perder es ganar si uno es capaz de pensar en términos de funcionalidad; ganar es perder si fuera del sentimiento de logro uno no aprende nada de la circunstancia. Una vez has reconocido las lecciones aprendidas, es hora de cerrar capítulo y moverse.

Por ahora eso es todo. Como dije antes, esta no es un manual detallado  como una descripción a grandes rasgos de un proceso que nos puede ayudar a todos a mejorar nuestras habilidades de resolución en GNU/Linux y por qué no, la vida en general :)

*Salvadoreñismo: achicopalarse.

Saturday, January 16, 2016

Manipulando I/O con pipelines.

Advertencia:

• Recomiendo leer las entradas de $man  $cat, $watch, $history y $less antes de seguir leyendo esto.
• He recomendado previamente wikear e investigar acerca del concepto I/O. Es importante que veamos todas las interacciones con nuestras PCs (y yo me atrevo a incluir, la vida en general) de esa forma: 

Input | Output

Entrada | Salida

O sea: 

Causa | Efecto
Instrucciones | Resultados.

Mientras entendamos esto, todo bien; caso contrario, te toca leer manuales externos porque a este punto, asumimos que estamos claros con este concepto y evitaremos elaborar.

Intro:

He instalado VirtualBox en un servidor. Me conecto al servidor desde mis otros equipos desde la CLI (eso es un cuento para luego... ahorita no joven). Hice una pausa en este proyecto por un par de semanas porque obtuve una netbook de segunda mano y he pasado jugando con Arch en ella. Para configurar una virtualbox en Terminal, hay que hacer varias cosas y apenas las recordaba hoy, enero/16; a grandes rasgos: crear una nueva virtual machine, asignarle x cores del cpu, x cantidad de RAM y VRAM, crear un HDD virtual, un ODD virtual, agregar controlador, etc.

Viendo a futuro, y contando con que planeo usar otra unidad de arranque para el servidor, o pueda cagarme en algo (cosa que hago a menudo :v ), probablemente necesite reinstalar virtualbox, o al menos borrar una VM, clonar, crear, restaurar otra. Por ello, quiero guardar un resumen de los comandos usados (como lo hice al aprender a instalar Arch recientemente); a modo de referencia.

**** Resumen ****

Necesito extraer los comandos que he usado para configurar la VM dentro del servidor. El comando (el principal) para gestionar Virtual Machines dentro de VirtualBox en la CLI es:

$vboxmanage
(o sea, "virtualbox manage": gestionar caja virtual). Recuerdo que lo he usado una, y otra, y otra**10 vez). Tuve una idea: buscar todas las instancias de ese comando, copiarlas y pegarlas en un documento de texto que luego puedo guardar en mi netbook u otro equipo. Para ello:

$ history | grep -i vboxmanage > vbox_resumen-de-comandos.txt


Y listo. Si has revisado las entradas antes mencionadas, sobran las explicaciones. Una vez creado el documento, lo abro:

$ less  vbox_resumen-de-comandos.txt

Y veo  todas las instancias que he usado del mismo comando (algunos de ellos, repetidos o con "typos"). Luego de eso, es posible editar  y depurar los errores (con gedit, leafpad, nano, etc.); incluso, puedo agregar notas aclaratorias. Creo tener una entrada antigua sobre editores de texto en este blog; te invito a buscarla. Eso es todo; gracias por leer :D

History: registro de comandos.

A veces olvido los comandos que he usado. Cuando esto pasa, escribo:

$ history

Con esto veo los comandos ejecutados por el usuario actual. Si quiero saber el usuario conectado, hago:

$ whoami
(como en who am I?)

A veces opero como root; entonces para ver los comandos ejecutados como root, hago esto:

$ su root
(ingreso password)
# history
(recordemos que el #, signo numeral, hash o hashtag, representa a root)


Y ellos aparecen. Si nuestro historial de comandos es extenso, apenas veremos los comandos recientes en panatalla; dependiendo de la Terminal desde la cual ejecutamos esto, a veces el scrolling con el mouse o la barra de scrolling vertical no funcionan; entonces nos apoyamos de otro comando: less, capaz de recibir el input de history  por medio de una pipeline (se dice "paip-lain"; hemos mencionado esto antes a grandes rasgos y te invitamos volver a leer esa entrada para aprender/recordar) y procesarlo de forma navegable. Recordemos el asunto del I/O:

input | output

entrada | salida



El asunto suena complejo, pero es tan simple como escribir esto:


$ history | less
y listo. Sin complicarnos. Vas a poder navegar a lo largo de todos los comandos (enumerados) que has escrito.

El mejor ejemplo que podemos usar, es aplicar la pipeline a tu PC. Adelante y hasta luego :)


EDITADO, enero/17, 00:44 horas, San Salvador: el colega Carlos Egüez mencionaba hace una hora en nuestro grupo, algo que he olvidado incluir:

Control + R en el prompt regular de Terminal: busca interactivamente un comando y muestra resultados a lo "auto completar".

Seguido de
$ history | less

el comando "history" enumera los resultados; una vez has identificado el comando que vas a reutilizar, es posible hacer esto:

$ !n 
donde n es el numeral que identifica al comando deseado. Por ejemplo, un fragmento de mis comandos:

486  screenfetch
 487  scrot
 488  clear

$ !486
es lo mismo que gatillar:

$ screenfetch.

Gracias Carlos por el feedback :D es exactamente esto para lo cual debe de existir la comunidad.

Less: leer output con calma.

Te aconsejamos wikear los conceptos "input" y "output", o "entrada" y "salida" respectivamente. Para que la PC haga algo, hay que ordenarle por medio de comandos, clicks, enter, etc. cada vez que lo hacemos, le damos un input; esta analiza/procesa/opera/transforma/computa/se coge al input y usualmente luego,  te muestra/vomita/escupe/caga la respuesta en la cara: esto es el output.

Imaginemos que queremos leer un documento, tarea, reporte, chat sexual travieso o cualquier cosa que tengamos guardada en la PC. Como lo vimos antes, podemos usar

$ cat nombre_del_asunto

$ cat toma el input, busca el archivo; si lo encuentra, te lo muestra; caso contrario te saca el dedo y dice que no lo encuentra. En ambos casos hay input-output. Digamos que todo va bien; el resultado se mira a grandes rasgos: 

output output output output output output output output output output output output output output output output output output output output output output output output output output output output output output output output output output output output output output y listo.

Esto va muy bien si el documento es breve y tenemos un display con suficiente espacio vertical, y si hemos maximizado la ventana de Terminal. Cuando no es este el caso, veremos solamente el final del documento: 

$ cat derechos_universales_de_los_ortos_peludos

maldita sea, una idea incompleta... output output output output output output output output output output output output output output output output output output output output output output output output output output output output output output output este es apenas el culo de todo el documento... la cagaste, jaja.

Cuando esto sucede, mandamos a la mierda a $cat y usamos 

$ less 

quien permite navegar con las flechas (prefiero esto:  jode menos las manos y evita quemar tiempo innecesario al despegar una mano del teclado para usar el mouse) del teclado.

De nuevo:
$ less

Toma tu input (el nombre de un archivo de texto, script, incluso el output de otro comando... pero eso no lo veremos ahora) y te da el output de forma navegable; la Terminal cambia al "modo visual"; este "modo visual" es tomado de VI (se dice "vi ai", "uve i" un editor de texto legendario, usado por algunos programadores profesionales aun). Para salir de este modo, al igual que para salir de VI, presionamos "q" como en quit; y listo. Hay mucho para hablar al respecto de less; esto nos basta por el momento; te recomendamos #RTFM (read the fucking manual) para mayor info:

$ man less
$ less --help
((por cierto, ambos comandos mostrados arriba usan el "modo visual" de VI: "q" para salir)

Y listo.

Por cuestiones de eficiencia y practicidad, en lugar de poner un ejemplo, te invito a realizar este ejercicio: localizar las licencias GNU-GPL en el filesystem de tu distro para comparar el uso de cat y less; vas a notar la diferencia,
$ less es un comando muy flexible. La flexibidad es poder. Hasta luego :)

Thursday, January 14, 2016

Niveles Sayayín en Linux.

A grandes rasgos, tu nivel de Sayayín Linux, se define por tu experiencia en GNU/Linux:

Nula.

Hasta hace unos días, no sabía qué cojones es Linux y todavía no sé qué putas es la parte de la  "GNU"; ¿es la versión geek de la ONU? Por cierto, dónde putas está la tecla "any"?  

 

Primera vez: último día virgen. 

Después del despelote, conseguí una copia de una distro. La bajé torrenteada o vía descarga directa, descubrí que el Windows Media Player no sirve para quemar ISOs (de hecho, no sirve para mucho, a excepción de mostrarme las portadas de los álbumes de música que no tenían portada, porque obviamente me espía y se conecta al internet para darle mi identidad al gobierno estadounidense); alguien me dijo que podía instalar un sistema operativo en una USB y hasta en una micro SD... wow, ¡este siglo es una gran época para vivir!

Después aprendí a cambiar la secuencia de booteo de mi pc para evitar arrancar windows y poder correr el medio de instalación donde puse Linux. Seguí el wizard de instalación cuyo requisito mínumo es tener un IQ equivalente al de un periquito australiano, y listo: arranqué al escritorio.

Básica: n00b.

He usado Linux un par de veces, he hecho "distro hopping" y eso... sé un poco de Terminal... y la uso para poner mi escritorio bonito, pero la Terminal no es santo de mi agrado y mejor le pido a alguien que me dé la respuesta a problema que yo causo cuando no la sé. 

Logré instalar los drivers de mis dispositivos privativos, pude activar los botones para disminuir la luz en la pantalla de mi laptop. Descubrí que Outlook no es el único cliente de correo que existe; de hecho, descubrí qué significa la palabra "cliente" en el concepto "cliente de correo" y por deducción, en informática en general. Instalé Flash; ya puedo ver porno en internet y fapearme sin licencias propietarias... success!!! 

Como pingüino básico, necesito ayuda para resolver problemas.

A veces cuando tengo problemas, voy a FB y escribo en mayúsculas  "¡AYUDA!" para que me tiren la respuesta; si no me la dan, hago rabieta  y me regreso a Windows temporalmente o pruebo otra distro a ver si me corre mejor... y si no, uso otra, y otra... y así... creo que le llaman "distro hopping".

Intermedia: entusiasta.

He configurado Linux en distintos equipos (ahora entiendo que cada equipo y cada distro operan a veces de maneras diferentes); me siento cómodo usando la Terminal; sé cómo agregar repos no oficiales, e instalar programas desde los binarios o el código fuente. Sé leer, escribir, sumar, contar, atarme los zapatos y limpiarme el culito después de ir al baño, así que soy capaz de leer y entender un mensaje de error, una advertencia o al menos, localizar información sobre los problemas y sé dónde buscar info y respuestas para resolverlos. Descubrí las man pages, y los foros y documentación oficial de mi distro; ellos son mi punto de partida cuando necesito ayuda. Voy a Gentoo o la Ubuntu o Arch Wiki a buscar respuestas, sin importar si uso Fedora, Kali o Mint, porque sé que ahí las encontraré. He aprendido un par de buenas prácticas de seguridad y las aplico. He configurado una distro desde el sistema base hasta dejarla como quiero. Lo he hecho varias veces. Podría incluso guardar mis snapshots para reutilizarlos de ser necesarios. Comparto mis configuraciones cool con otros unixeros (sé cuál es la diferencia entre Unixero y Linuxero).

Como pingüino intermedio, sé cómo buscar soluciones a los problemas. 
No estoy  seguro si lo que he aprendido me vuelve un "usuario intermedio", porque entiendo que, como en artes marciales "un cinta negra es un cinta blanca que nunca se rindió", y que, como dice Hatsumi Sensei, "everything is basics" (todo a partir de las reglas y principios básicos). Sobretodo, tengo el conocimiento y la decencia suficiente para saber que instalar Conky o usar Android no cuentan como "tengo experiencia con GNU/Linux" para entrar al nivel básico en esta lista :v turn down for what???!!!!

Avanzado.

Sé resolver problemas, personalizar mi equipo en aspectos técnicos (lo estético ya está fuera de discusión aquí porque es una cuestión de gustos personales y opiniones, no algo absoluto), soy capaz de monitorear y entender procesos, elaborar reportes administrativos, determinar puntos de falla, y administrar mi(s) equipo(s) de forma remota; desarrollo mis propios scripts para automatizar tareas, uso versiones Alphas y Betas para aprender y descubrir aspectos de rendimiento más que de apariencia; sé cómo migrar datos en mi red de forma segura. 

De hecho, laboro en el área: Configuro y administro positivos en una red, entiendo cuál el concepto verdadero de "hacking" y sé que es mucho más amplio que el concepto que los niños rata tienen. Corro servidores de producción, hago pruebas de seguridad, sé cómo cuidar mi red y a mis usuarios. 
Evito tomar screenshots de operaciones internas porque sé que eso es confidencial. No me mato peleando en FB porque alguien menciona a Windows o Mac; estoy ocupado administrando la red/base de datos/desarrollando código/gestionando usuarios/haciendo seguridad forense, etc.

Como pingüino avanzado, trabajo para resolver problemas en mi equipo y mi red de usuarios.

Contribuyente.

Aporto a la comunidad ya sea con código propio o auditando código ajeno, reporte de bugs, soluciones, modero foros, mantengo paquetes en una distro, he sido nombrado "usuario confiable" por un proyecto, audito cambios, trabajo con gente de forma local o remota para desarrollar proyectos y darlos a la comunidad.

Como pingüino contribuyente, aporto para que otros puedan obtener ayuda y resolver sus problemas.
 

Creador.

Hago software que causa impacto en la sociedad. Inicio mi propia distro, DE, Framework, plataforma móvil, plataforma en la nube, herramietntas de gestión. Lidero un proyecto. Realizo ideas.

Como pingüino creador, yo creo soluciones a los problemas. 

NOTA: pueden faltar o sobrar cosas y niveles incluso, si sos más detallado y técnico. Esto es, medio en serio, medio cómico y su objetivo es, invitarte a la auto-evaluación objetiva: sin sentimentalismos, ni acusasiones, ni adulaciones, para que podás identificar dónde estás parado y hacia dónde podés ir... si te lo proponés y trabajás por ello. Saludos :)

Wednesday, January 13, 2016

Aprender GNU/Linux de forma fácil y rápida.

La entrada Soy nuevo en GNU/Linux ¿cuál distro me recomiendan? Parte I no era la solución mágica que algunos esperaban; pero es más un intento de guía personal. Creo firmemente que el individuo debe de aprender y crecer a nivel personal, no sólo técnico o intelectual. En la medida que aprendés y transferís principios de una disciplina a otra, tu criterio se amplía en lugar de volverse más angosto. 
Abrí la mente, abandoná el ego; 
Tomá lo bueno, desechá lo malo.
No puedo obligarte a pensar, sentir, ser y vivir como yo, pero desde fuera de un problema las cosas se miran de forma distinta y uno puede notar detalles que, difícilmente se ven cuando uno está sumergido en el problema: uno no sabe lo que no sabe.
  1. Uno no sabe lo que no sabe (uno tiene un problema y no sabe/lo considera problema).
  2. Uno sabe que hay algo que no sabe (reconoce que hay un problema).
  3. Uno descubre qué es eso que no sabe (de a poco, define el problema)
  4. Uno aprende al respecto (conceptos, elementos, dinámicas, relaciones, principios, reglas; se apoya en gente que sabe, expertos, etc).
  5. Uno investiga y conoce más del tema. Esto ayuda a delimitar el problema y a entenderlo mejor. Se establece un proceso para resolver el problema.
  6. Uno aplica lo aprendido metódicamente (resolución del problema).
  7. Uno repite pasos hasta resolver el problema (iteración).
  8. Uno observa, mide resultados y evalúa,  calibra, hace ajustes para la siguiente vez (feedback, iteración y depuración del proceso que se había definido).
  9. Uno resuelve más problemas con el nuevo conocimiento (se gana experiencia, se especializa). 
  10. Uno aporta nuevas ideas, procesos, soluciones (uno se vuelve especialista, experto)
  11. Uno comparte y ayuda a otros a resolver los problemas (replica el modelo y la comunidad, sea del carácter que sea, se beneficia).
  12. Todos tienen un orgasmo infinito; Dennis Ritchie, Richard Stallman y Linus Torvalds sonríen complacidos mientras Bill Gates y Steve Jobs lloran por la irritación en la entrepierna.
¿Qué putas tiene que ver esta mierda con GNU/Linux? Todo, mi joven saltamontes, todo.  Aprender, des-aprender, re-aprender.

  • Aprender algo útil.
  • Des-aprender hábitos perjudiciales o ineficientes.
  • Re-aprender prácticas útiles que se dejaron atrás.
Saludos :)

Soy nuevo en GNU/Linux ¿cuál distro me recomiendan? Parte I

Todos nos preguntamos eso al inicio. 

Cuando escuché de GNU/Linux por primera vez, pensé que era una sola cosa, una sola organización, un escritorio, un set de aplicaciones, uno solo. 

Ahora entiendo que Linux es un sistema (no sólo informático sino también) orgánico; como tal es entero, completo en sí mismo; y a su vez, diverso. Es la síntesis de miles de esfuerzos globales. Hace tres-cuatro años, mi interés primordial era: ¿cómo putas lo instalo? 

Me documenté y llegué a varios blogs -angloparlantes; enfatizo el hecho de que se encuentra mucha más info en ese idioma; es el latín moderno- que instruían cómo instalarlo. Ya sabía como instalar Windows desde una USB, así que el tema no fue completamente ajeno. En las instrucciones, el primer paso implícito en todos los blogs, era:
Escogé tu distro
Yo: ¿Ah? ¿Qué putas es una distro?
Cuando se trata de conocimiento y aprendizaje, usualmente una sola pregunta no se resuelve con una respuesta, sino haciendo más preguntas. Leí sobre las distros y me fascinó que cada una lucía diferente a la otra, y que incluso una misma podía tener distintas apariencias y usos. Entonces escuché de "distros estables", "distros a la vanguardia", "distros minimalistas", "distros amigables", "distros esotéricas", etc., etc., etc. Vi screenshots y algunos me parecían "aburridos", otros me resultaban una imitación de Windows, otras una copia de Mac OS; otras me parecían increíbles y fascinantes, y así. 

Estoy seguro que vos también has pasado por esto y también te hiciste la pregunta del millón:

¿Cuál distro instalo?

Si andás en las redes sociales y sos miembro de grupos de GNU/Linux, habrás visto la misma pregunta hecha varias veces al día en cada grupo. Todos los días llega un primerizo/a porque escuchó maravillas de Linux, y se animó a probarlo. Pero descubre que  el tema de Linux es un poco más extenso, porque tiene más opciones versus Mac OS y Windows [esto es porque Linux es flexible y modular; pensá en GNU/Linux como un juego de Lego; como puede ser un modelo F1 ya armado, puede ser una cubeta llena de legos listos para que vos creés lo que se te dé la gana]. 

Cuando aparece un "nuevo", quienes tenemos ya un tiempo usando GNU/Linux, de alguna forma sentimos algo de responsabilidad por ellos; todos fuimos primerizos. Si practicaste artes marciales o un deporte en equipo y llegaba gente nueva de vez en cuando, entenderás la importancia de esto. GNU/Linux es lo que es porque alguien (Linus) inició la kernel, y después otro llegaron otras leyendas míticas y organizaciones que aportaron a la causa. Ayudar es bueno. Pero creo que,

... necesitamos replantearnos lo que entendemos por ayuda. Veamos el asunto desde dos ángulos:


• Muchas veces, la ayuda que los n00bs pedimos, se trata de que alguien más busque algo por nosotros. O sea, pedimos cínicamente que nos hagan la tarea; tal vez por simple pereza o porque no sabemos dónde buscar, qué preguntar, cómo preguntarlo; entonces buscamos a un humano que decodifique nuestras dudas.

• Por otro lado, la ayuda que a veces damos a otros n00bs, se limita a tirar respuestas aleatorias, basadas en juicios y opiniones personales, como si se tratase de un juego Pokemon: 
¡Pikachu, instala Fedora XFCE!
¡Estás bobo, usa KDE mi Charmander, quedará "ermozo"!
Tontuelithoss ustedes no saben; uso mi carta de Manjaro turbo cargado con mil widgets de Conky... también te va a correr en una netbook con 1GB de RAM... Fatality :v :v :v
Consideremos esto:

• Pedir ayuda implica que definás primero el problema que necesita solución.
• Pedir ayuda no significa "háganme la tarea... sóplenme la respuesta".
• Pedir ayuda tampoco es igual a "decidan por mí por favor".

• Dar ayuda no significa escupir respuestas como dogmas religiosos inamovibles. Esto no es un concurso de preguntas y no vas a ganar una Range Rover por dar más respuestas correctas como cotorra.
• Dar ayuda no significa tomar mis opiniones como verdades absolutas e imponerlas a otros.
• Lo que me sirve a mí, puede servirle a alguien más, o tal vez pueda causarle más problemas (esto aplica cuando alguien tiene una netbook y le sugieren que instale Fedora con Gnome 3.x y le ponga Compiz para tener los workspaces como un dado 3-D.
• Lo que me gusta a mí puede gustarle a alguien más o parecerle caca mal cagada.

Pedir y dar ayuda debe de ser útil para todos: todos deberíamos de aprender de ello; tanto el que la solicita, como el que la da, como los espectadores.

Escribí esta primera parte, para que reflexionemos y pensemos en términos de eficiencia y optimización de recursos: No hay pregunta estúpida; hacer la misma pregunta que se hizo literalmente miles de veces antes, tampoco te hace estúpido. Seamos sensatos: considerá si otros deberían darte de su tiempo para responder una pregunta hecha mil veces antes, cuando la respuestá está a unos clicks en un motor de búsqueda. Si pudiste escribir en un  grupo social para preguntar algo que todos nos preguntamos antes, estoy seguro que también sos capaz  de encontrar la respuesta sin tener que crear otra thread y desperdiciar espacio, quitar visibilidad a los posts ajenos que pueden ser más urgentes, y gastar el tiempo ajeno. 

Pensalo sin sentimentalismos, sin ponerte a la defensiva; dejá eso para la gente que no crece como persona ni como profesionales. Mirá al  espejo, tomá lo bueno, desechá  lo malo. Esto no es una regañada o una bofetada ni un insulto, es un llamado a tu inteligencia. Sé que del otro lado del internet hay alguien inteligente -si has leído hasta acá, sos lo suficientemente paciente y dispuesto a aprender; y  eso es lo esencial para crecer en GNU/Linux y resolver problemas en general :)

En la segunda parte te compartiré algunos criterios objetivos a considerar a la hora de escoger una distro. Pero me gustaría que compartás este artículo con tus amigos Linuxeros. Entre más seamos quienes practicamos el buen uso de los recursos, podremos llegar a más gente y ayudarnos de forma más sana, efectiva, eficiente.

Iniciativa, proactividad, autonomía, sentido común, independencia, autogestión, autodidáctica.


Hasta entonces, suerte :D

Entradas populares.