Showing posts with label administración de equipo. Show all posts
Showing posts with label administración de equipo. Show all posts

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. 

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

Monday, July 20, 2015

¿Qué son los PPAs? ¿Y qué es un repositorio?

Primero, que quede claro que cuando hablamos de PPA, nos referimos a un concepto relacionado a Canonical Ltd. (entiéndase, Ubuntu y distros derivadas).

Un PPA, o Personal Package Archive,  (en español sería Archivo de Paquete/es Personal/es) simplemente es una colección de software que usualmente no está incluida en una distro en específico. Típicamente, un repositorio se enfoca en un solo programa, pero pueden incluir más, dependiendo de la persona, equipo u organización que los mantienen. Un PPA puede enfocarse en software que todavía no ha sido lanzado (o sea,  que está en etapas alpha, beta o candidato).

En pocas palabras, un PPA es un repositorio de software especial, en el cual, desarrolladores cargan (suben, dan upload) a "paquetes fuente" para ser armados y publicados en el repositorio de APT de Launchpad

Podés leer más de esto, acá.

¿De qué me sirve agregar un PPA?  

En esencia, para extender las capacidades de tu Distro según tus necesidades como usuario, desarrollador, administrador. Te pongo unos cuantos escenarios reales por los que he pasado en las últimas semanas, donde los PPAs han sido de ayuda:

• Usar un PPA te permite instalar herramientas o aplicaciones que no venían preinstaladas en tu distro -como el editor Atom que instalé en mi Freya, por ejemplo. Freya al igual que Luna, trae Scratch  preinstalado. Scratch es un editor de texto bastante bueno aunque de hecho, no lo había usado hasta hace unos días atrás. Un buen amigo me recomendó Atom para un proyecto colaborativo que estaremos iniciando. Pude haber usado Scratch, pero el  asunto es que Atom tiene muchas mayores prestaciones: por ejemplo, el autocompletar cuando se escribe un comando, o una variable, la forma en la que los menúes son invocados, mostrados, ocultados, la modularidad, el "feeling" y la apariencia. Atom resembla mucho a Chrome... y es que está basado en Chromium. Se le puede modificar a tu antojo y hacer un mar de cosas que no vamos a mencionar ahora. 

Atom, editor de texto. Para descagarlo e instalarlo, según estas instrucciones, necesitarás agregar primero el APP o PPA de Atom.
$ sudo add-apt-repository ppa:webupd8team/atom
$ sudo apt update
$ sudo apt install atom

Lo mismo sucedió con Noise. Tuve problemas reproduciendo desde mi librería -aunque eso es un problema que estaré diagnosticando en las siguientes semanas- y después de encontrar escasa información al respecto, decidí instalar Tomahawk y Amarok, reproductores que hacen su trabajo  genialmente.

• Usar un PPA te permite añadir complementos a una aplicación, e incluso, usar ciertas versiones o secciones de un programa, sin tener que recurrir a la versión completa, que podría consumir más recursos de tu hardware. Tomo como ejemplo la vez que instalé Deluge-console, el cliente de Torrents recientemente en Freya.  


Si tu distro no tiene un programa, podés habilitar los PPAs de otra distro derivada o emparentada para accesar a él. 

• Usar un PPA te permite obtener software de manera segura. Como hay organizaciones de reconocida reputación detrás de los repositorios más populares, es más seguro descargar una aplicación para Linux que uno de los tantos .exe que hay en internet para Microsoft Windows.

También podés agregar PPAs de otras distros cuando la tuya no incluye ciertos paquetes, como en el caso de ciertos Icon Packs que describimos acá. En este sentido, tené en cuenta que no todos los PPAs son "oficiales" o reconocidos; hay unos que son mantenidos por desarrolladores independientes y poco conocidos.


¿Cómo se añade un PPA?

Así:

$ add-apt-repository ppa:nombredeLaunchPadusualmenteacá/nombredelppa

Por ejemplo, en nuestro artículo de cómo agregar Icon Packs


$ add-apt-repository ppa:moka/stable 

Aquí agregaríamos la versión estable de los paquetes en el PPA del Equipo de desarrollo Moka, que contiene por ejemplo, icon packs.  Es siempre recomendable hacer un "update" después de agregar un PPA: 
$ sudo apt-get update

También podríamos agregar el PPA de Shutter, para luego instalar la aplicación del mismo nombre que hace capturas de pantalla (screenshots):

$ sudo add-apt-repository ppa:shutter/ppa
$ sudo apt-get update
$ sudo apt-get install shutter 

Screenshot de Shutter.


Más info, acá. Ahora, no todo es color de rosa con los PPAs y no todos son buenos. Pero de eso hablaremos luego. Hasta pronto.

CLI sobre GUI: fondo sobre forma.

En este artículo, y este otro, les he hablado de cómo correr aplicaciones desde la CLI*, o Terminal. Antes de proseguir, quiero que todos tengamos clara la relación entre Forma y Fondo: 

Forma: continente, el envoltorio, el cómo.
Fondo: el contenido, la idea, el qué.

Una de las cosas más importantes para todo usuario de Linux, es aprender a usar su Terminal y unos cuantos comandos básicos como los que Jimmy nos compartía. A medida avanzamos en el uso de Linux, vemos que la CLI nos puede simplificar las cosas, o también complicarlas si no sabemos qué carajo estamos haciendo. Por ejemplo, ¿sabías que es posible abrir una página de búsqueda en tu navegador desde Terminal? Suponiendo que tenés Firefox o Chromium en tu distro, tratá:

$ firefox linuxdesobrevivencia.blogspot.com
$ chromium-browser elementary.io

Esto te ahorra el tiempo de ir al menú, buscar la applicación, darle click, esperar a que la GUI** cargue, mover el mouse a la barra de direcciones (o F6, si sos no sos tan lento) , ingresar la dirección, darle click al botoncito de la derecha (o apretar Enter, si no sos tan lento), esperar a que la página cargue, y disfrutar del fappin' después de seleccionar un video en exquisita alta definición. Dos simples bloques de texto sintetizan 40 años en el desierto de la GUI.

Como mencionaba en el  artículo de Deluge Console, podés abrir Terminal, arrancar deluge-console, agregar un archivo torrent, y dejarlo leeching/seeding mientras ves tu porno favorito desde tu navegador. 

Seguramente alguien puede pensar: "pero chele, ¿por qué y para qué querés correr una aplicación a puras letras y comandos? Si la rueda de caucho ya está inventada, ¿por qué querés seguir usando una rueda de piedra? La CLI es una cosa vieja, de los tiempos de MS-DOS" Mi respuesta es simplemente, por conveniencia. 

Claro, lo que es conveniente para mí, no puede serlo para vos. Eso lo tengo claro y no pienso convencer a nadie de que mi forma de operar y adminstrar mi equipo es la forma en la que deberías de gestionar el suyo. Ahora, si sos de la gente que le dedica tiempo a encontrar una mejor forma de hacer las cosas, te comparto lo que he aprendido sobr usar Linux: Aquí es donde radica la belleza de Linux. 

La Terminal te simplifica muchas cosas:

• Al correr tus aplicaciones vía CLI-Terminal, estás ahorrando el uso de recursos para tareas de mayor prioridad. Esto es importante cuando tu equipo cuenta con recursos limitados y necesitás gestionar diversas tareas a la vez. El consumo de RAM que implica mantener de una interfaz gráfica es reducido cuando la tarea se ejecuta desde terminal. De la misma forma, el uso de CPU, espacio en disco, aparte que tu atención  no se dispersa en los botoncitos, barritas, backgrounds, soniditos y animaciones. 

Raspberry Pi, modelo B: 256MB de RAM y 700Mhz de CPU. No es el tipo más rápido ni más fuerte, pero es lo suficientemente pequeño y ecológico como para hacer un servidor de descargas o headless server que ha corrido durante la noche cuando mi equipo principal está apagado.

• La CLI es importante para administradores de servidores: usualmente un servidor no tiene interfaz gráfica: como administrador querés usar tus recursos de forma eficiente y ejecutar tareas sin afectar negativamente la disponibilidad de recursos para la ejecución de otras tareas. Los administradores no suelen tener una consola tipo Alienware Command Center como este: 

Ejmplo de cómo la forma tiene alta importancia: Alienware Command Center para cambiar las luces de una Area 51. No poseo los derechos de esta imagen ni de la marca. Sólo la muestro con propósitos educativos. La forma es importante particularmente en objetos y bienes de lujo; la forma da status, alimenta el ego, nos hace sentir mejor y sana el horror vacui

Si no algo más o menos así: 

Fondo como prioridad: administración de un servidor remoto con el comando "htop", una versión versátil y turbocargada de "top". Aquí, htop muestra un CPU con 64 núcleos y 64GB de RAM. Toda distro de Linux tiene top por defecto. Si abrís tu terminal y escribís "top" vas a ver esto de forma menos gráfica y probablemente con menos procesadores. Pero por supuesto,  podés instalar con "$ sudo apt-get install htop", y disfrutá :)

• Incluso para proyectos caseros, como un servidor local, de firewall, de base de datos, etc., la Terminal te va a ahorrar tiempo y la molestia de tener que instalar software de terceros para monitorear algo tan simple como el tiempo de finalización de una descarga o carga, navegar entre directorios y copiar un archivo desde un equipo a otro, etc. ¿Para qué gastarías en licencias, ancho de banda, o recursos de tu servidor y tu workstation en renderizar la GUI cuando podés administrar y operar desde la CLI? Sí, es cierto que existen herramientas de assistencia remotas gratuitas para uso doméstico... como TeamViewer que te permite operar y acceder a tu workstation desde tu smartphone pero, ¿qué tal si tu batería tiene poca carga y sólo buscás iniciar o finalizar un programa?

¿Para qué necesitás botones, colores y defectos espaciales***? Si tu equipo tiene un cantidad relativamente escasa de RAM o de poder de procesamiento, no querés desperdiciar músculo en cosa que van a volver más lenta la ejecución de una tarea. Fondo ante todo.

No quiero armar debate; como diseñador gráfico aficionado, valoro la importancia del diseño y la estética visual; lo que digo es que no debemos de confundir la falta de íconos con fealdad: que una aplicación carezca de elementos visuales no significa que no sea usable; que no haya una forma elaborada, no implica que algo sea menos estético. De hecho, la Terminal tiene su atractivo: la belleza de lo simple -y en todo caso, si insistís en la importancia de lo estético-pero-funcional como tu servidor, podés aplicarle transparencia con ~/.devilspie como lo hice alguna vez en Fedora 20... o en el caso de Freya, la Terminal es transparente de fábrica y te funciona trabajar en ella mientras leés este blog :v

¿La CLI es mejor, más rápida y eficiente que la GUI? Depende quién lo pregunte. La GUI es una representación visual de la CLI. Un botón de "cerrar ventana", representa un comando de salir/suspender una aplicación. La GUI es la síntesis visual de la CLI; la CLI es la síntesis en código de la GUI. Para un usuario de casa, la GUI es el camino a escoger; de la misma frma para un creador de contenido multimedia, el asunto de una interfaz gráfica no viene al caso porque sí es necesaria para sus propósitos, como puede serlo para un agente de ventas, o un profesional de contabilidad.  

Lo que digo es que, para un usuario de Linux que quiere expandir su conocimiento y habilidades, la CLI es el Santo Grial.

Usar la CLI no es andar en llantas de piedra; al contrario: la CLI es más rápida siempre y cuando aprendás a escribir rápido, a usar tu teclado como se debe, a desprenderte de tu mouse y sobretodo a desarollar la capacidad de visualizar y conceptualizar sin asistencia visual...  pero esto es algo que usuarios dependientes de la GUI difícilmente van a entender.

Saludos.


*Command Line Interface: El "command prompt", terminal de comandos, terminal, etc. 
** Graphic User Interface: Interfaz gráfica: íconos, botones, cuadros, figuras geométricas, representaciones simbólicas de los comandos. Lo que volvió popular a Windows en un inicio; una de las mayores razones del éxito de iOS, de Android.
*** Efectos especiales.

Monday, June 9, 2014

[Gnome] System Monitor.

En windows hay Task Manager: Ctrl + Alt + Del (o Ctrl + Shift + Escape), sirve para ver las tareas que corren, ver la gráfica del uso de RAM y CPU; y usualmente se usa como quien llama a los salvavidas al momento de dar las patadas de ahogado... cuando la máquina se está trabando. En otras ocasiones peopres, es como llamar al Chapulín Colorado por ayuda porque es poco probable que te sirva de mucho... puede que termine trabando tu máquina aún más... y que al final el pedo se resuelva dejando al tiempo pasar... 

Acá, tenés al Gnome System Monitor. Cumple con la misma función, y su interfaz resulta hasta un poco más fácil de asimilar:



Este es un trabajo en progreso. Creamos la entrada, para poder relacionar otro artículo a este. Falta incluir más imágenes ilustrativas, e incluir instrucciones de instalación para cuando no instalás una Distro empacada en Gnome. Pero regresá a mirar esto de nuevo, en unas cincuenta y cuatro semanas... Nos vidrios al ratón Chele :D

Entradas populares.