Showing posts with label arch. Show all posts
Showing posts with label arch. 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. 

Thursday, December 24, 2015

Extender tu partición / (root) sin herramientas gráficas; parte I.


PARA ENTENDER este artículo, te sugerimos aprender los conceptos de filesystem, directorio, particiones y documentación adicional sobre fdisk.

Si te atreviste a configurar manualmente tus particiones cuando instalaste tu distro, probablemente te preguntaste ¿cuánto espacio necesito para mi partición root? ¿cuántas particiones necesito? ¿cuánto espacio asigno  a una partición swap? 

Todas estas preguntas ya tienen respuesta en las wikis y documentos oficiales de cada distro. Para usuarios expertos, determinar cuánto espacio debe de ser asignado a qué, es fácil. Para los n00bs totales, también porque dejan que los instaladores lo hagan todo por ellos. 

Pero para los que estamos aprendiendo en el ruedo, puede que esas respuestas no nos ayuden totalmente y necesitemos un poco de flexibilidad; tal vez por error o por desconocimiento, asignamos manualmente espacio suficiente para instalar el sistema base y conforme instalamos más paquetes, vemos que nos quedamos sin espacio adicional en la partición, aun teniendo espacio extra en nuestro disco. Si ese sos vos, te explicamos cómo agrandar/estirar/alargar tu partición root vía Terminal, mientras tu sistema operativo está corriendo. A esto se le conoce como LIVE/ONLINE ROOT PARTITION RESIZING o "redimensionamiento de la partición root en vivo/en línea".

PREGUNTA IMPORTANTE ¿por qué habría de usar este método cuando existe Gparted o cuando puedo usar una imagen en vivo desde  un CD/USB? Porque tal vez estás aprendiendo de admiministración de sistemas o corriendo un servidor como en mi caso, o tal vez ya sos un administrador y tenés un servidor de producción al que forzosamente necesitás extenderle el root; o puede que no dispongás de otro sistema o imagen, o simplemente porque sos jarcor (hardcore) y querés aprender a hacerlo sin usar interfaces gráficas (GUIs). Si este es tu caso, seguí leyendo. De otra forma, buscá en línea cómo  usar Gparted, que es más fácil y apropiado para usuarios que no se sienten cómodos trabajando en Terminal porque no tienen el conocimiento y/o no desean aprender a usarla.


Nuevo equipo, jugando con microservidores.

Ratos de no escribirles.

He llegado a la conclusión de que este blog difícilmente tendrá un desarrollo "lineal". Inicialmente decidí que sería una especie de manual introductorio para novatos GNU/Linux. Durante el tiempo que no escribo, aprendo de administración Linux, programación, microcontroladores y demás; esas cosas no considero necesarias para un novato; pero compartiré las cosas que considere útiles. Algunas de ellas pueden ser de nivel básico y otras requieren un conocimiento mayor en esto o aquello. 

Esta actualización podría ser un poco "avanzada" puesto que habla de hardware y un poco de soluciones de almacenaje.

Me hice de nuevo equipo y me deshice de mi Phenom 960T. Ahora, tengo una laptop intel (i5 4210u, 8GB, Nvidia 840M, 720p, WiFi, Bluetooth, parlantes, teclado y 1TB que reemplacé por mi SSD de 128GB) en la cual tengo Freya. Ya tengo unos tres meses en ella y no me quejo de nada :) ¿Por qué tanta RAM y un i5? porque serán útiles durante mi aprendizaje de FOSS. 

Desde hace un par de años vengo con la idea de construir mi propio servidor multipropósito y alojarlo en casa. Existe un invento llamado "la nube", y otro llamado "servidor NAS" pero para todo el material que tengo (software, imágenes, música, etc.) y como prefiero armar mis propios equipos y aprender del FOSS, quise hacer mi propio servidor. 

Ya tenía mi PC de escritorio y se me ocurrió que tenía el suficiente músculo para hacerla un servidor (Phenom 960T quad core, convertible en hexacore; 2GB Nvidia GTX 650 Ti Boost de EVGA, Asrock 990FX Extreme3; 8GB de RAM Kingston Hyper X Beast; OCZ SSD de 128GB SATA III; 2x 3TB Western Digital Caviar Red SATA III; radiador Corsair H60; Cooler Master CM 690 II; -lector de tarjetas y sin unidad óptica interna :v ); pero honestamente, casi no le usaba y sería un consumo de energía excesivo para lo que quiero.

Me di la tarea de buscar desde hace unos años y encontré la solución perfecta: motherboards embebidas (SoC, Single Chip computers); son simplemente motherboards de factor pequeño (usualmente micro ATX, baby ATX, mini ITX o incluso Pico ITX) con procesadores de bajo consumo (usualmente, procesadores de laptop); que toman RAM de escritorio o laptop y tienen varios puertos SATA. Son populares en países de Asia y el primer mundo occidental, para entusiastas que deciden hacer sus propios Home Theater PCs (HTPCs) o micro servidores e incluso como PCs domésticas para quines no tienen exigencias altas (gaming, creación multimedia, compilar código,  virtualización, etc.).

Durante los tres-cuatro años que contemplé la idea, llamaron mi atención una motherboard Zotac con un AMD Turion de doble núcleo (ya bastante viejo, pero de bajo consumo), una AsRock con un AMD Zacate E-350, y una Asrock con el AMD Kabini A4-5000. Todos procesadores originalmente pensados para laptops. También varios Intel (los Intel Celeron Bay Trail son muy buenos, pero valen un poquito más y tienen menos puertos SATA III: aquí estamos considerando algo llamado escalabilidad).

El Kabini me pareció perfecto para el trabajo puesto que trae cuatro puertos SATA III (lo que me permitiría poner dos o más discos en RAID 1), aparte de tener un TDP de W, y ser quad core... de apenas a 1.5GHz, pero es suficiente para lo que hará: proveer almacenaje en mi red local y tal vez alojar sitios en WordPress para cuando retome el tema; en todo caso, tengo dos núcleos extra en comparación al E-350.  podría beneficiarme de los múltiples núcleos

Mientras tanto, aprendí a instalar Arch vía VirtualBox en mi laptop (virtualizar requiere bastante RAM según los SOs que se corren). No considero hacer una guía al respecto porque ya existe: está en la Wiki de Arch, y siguiendo su filosofía me adhiero al principio #KISS (keep it simple, stupid!) y por eso es que te sugiero: #RTFM (read the fucking manual!). 

Hace unos dos meses, me llegó la mini ITX; conecté mi otro  SSD a la mobo Kabini e instalé Arch hace unos cuantos sábados. Como está pensada para servidor, no requiero de un Entorno de Escritorio; aun así, instalé Awesome WM como lo hice en el Arch de VirtualBox. Tal vez hable de Awesome en otra entrada después. En mi tiempo libre me di a la tarea de auditar mis discos duros y consolidar todos mis archivos en mi disco duro externo. Ya luego configuro RAID 1, un par de daemons y copio la info de mi disco duro externo a ellos. 

Leyendo de administradores y desarrolladores angloparlantes, aprendí ciertos trucos a implementar en mi servidor, pero... la cagué al configurar la instalación;

... apenas y le asigné 15GB de espacio a la partición root. El sistema base de Arch pesa menos de 3.5GB ( # df -h muestra 3.4GB usados hasta ahora, que tiene paquetes extra que he instalado), pero preveo que podré necesitar más espacio en un futuro cercano. 

Así que en la próxima entrada, te compartiré cómo hice para extender la partición root.

Y eso. Felices fiestas :) 

Entradas populares.