MentorCruise

Upstream, Appstream y DownStream

La manera tradicional que tenemos para instalar software en los entornos de escritorio de Linux es usando las herramientas de línea de comando o tal vez herramientas gráficas tales como Synaptic y dnfdragora.

dnfragora.

Este tipo de instalación a la que los usuarios de Linux de unos cuantos años estamos acostumbrados no es ni más fácil ni más difícil que buscar aplicaciones, bajarlas y correr un instalador y presionando los botones "Next", "Next"...

Sin embargo, la mayoría de los usuarios finales en la actualidad suelen instalar aplicaciones desde centros de software desde teléfonos celulares, los famosos App Stores, tales como Google Play y Apple App Store.

Como respuesta los dos entornos de escritorio principales de Linux cuentan con herramientas similares: Software (GNOME) y Discover (Plasma) para crear una experiencia de usuario similar:

Centro de Software en Linux

Este clase de programas usan no solamente el sistema de paquetes de la distribució (sea tanto repositorios oficiales como así también de teceros), sino además, pueden usar sistemas como flatpak y snapcraft.

Debajo de estas herramientas tenemos a AppStream la cual proporciona metadatos universales de aplicaciones. Se trata de una especificación de freedesktop.org que resulta beneficiosa tanto para desarrolladores como para usuarios finales.

streams

Photo by Good Free Photos on Unsplash

Puede tratar de manera específica a cada componente de acuerdo a su tipo: aplicación de escritorio, complemento, codec, fuente, etc.

Estos metadatos se guardan en archivos XML. En Fedora, por ejemplo podemos encontrar estos archivos en:

  • /usr/share/app-info/
  • /usr/share/metainfo/

De acuerdo a las directrices para empaquetar software de Fedora, toda aplicación con interfaz gráfica tiene que tener un archivo *.appdata.xml

Debian usa un único archivo YAML en lugar de XML, en Debian Buster para plataforma AMD64 se encuentra en /var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_dep11_Components-amd64.yml.gz.

Estos archivos suelen contener un identificador, nombre, resumen, icono que representa al componente, descripción, categoría, información de versiones. También puede indicar si el componente es esencial para el funcionamiento de un entorno de escritorio y capturas de pantalla. Incluso ofrece el soporte para que el usuario califique la aplicación.

Es muy importante contar con la metadata de las aplicaciones de modo que appstream y programas como Discover y Software funcionen correctamente. Por ejemplo, en el caso del repositorio rpmfusion es necesario instalar un paquete aparte: dnf install rpmfusion-free-appstream-data.noarch

En la actulidad un usuario puede buscar una determinada aplicación del proyecto KDE e instalarla desde KDE's Applications. Supongamos que encuentra a Calligra Stage y decide instalarla:

Link de Appstream

Es decir, se puede ver que tiene el siguiente URI: appstream://org.kde.calligrastage.desktop al ser una herramienta totalmente agnóstica puede usar tanto un repositorio tradicional, como los de flatpak y snapcraft. Es decir, es importante entender que appstream no es un método nuevo de empaquetar software o un nuevo tipo de repositorio. Si la aplicación no está en los repositorios mencionados, obviamente la instalación fallará.

Es decir, luego en Discover:

Discover mostrando Calligra Stage

También, podríamos instalarla directamente usando appstream:

appstreamcli install org.kde.calligrastage.desktop

Para ver el estado:

Podemos ver entonces que appstream funciona como un puente bidireccional, los proyectos upstream pueden facilitar el empaquetamiento y disponibilidad de aplicaciones, y cada distribución (downstream) puede dar a conocer de una manera mucho más amigable el software para los usuarios finales creando un círculo virtuoso.

Fuentes y Más Recursos

¿Es btrfs el sistema de archivos que estábamos esperando?

Digásmolo: btrfs es un sistema de archivos moderno para Linux.

Alguien leyendo esto seguramente va a pensar:

¿Qué está diciendo? ¿Cuál es la novedad? ¿Acaso no se puede rastrear los orígenes de btrfs por lo menos hasta el año 2007? ¿No es cierto que SUSE lo usa desde 2012?

Butter Ef Es

Photo by Nathan Dumlao on Unsplash

Sí, todo es cierto, sin embargo, veamos la siguiente tabla:

Año Filesystem
1993 XFS
1993 NTFS
1998 HFS+
1998 FAT32
2005 ZFS
2006 exFAT
2008 ext4
2009 btrfs
2016 APFS

La fecha de btrfs la situamos en 2009, ya que fue el año en que fue incorporado en Linux. En comparación a los demás sistemas de archivos de Linux es el más moderno (sí, ya se que existe stratis). Otro objetará diciendo que cronológicamente no hay mucho diferencia entre ext4 y btrfs. Sin embargo, leamos lo que dijo Theodore Ts'o:

Aunque ext4 tiene características mejoradas, no es un avance significativo, usa tecnología vieja y es una solución a corto plazo.

Y respecto a btrfs tuvo estos comentarios auspiciosos:

ofrece mejoras en escalabildad, confiabilidad, y facilidad de administración

Ah, ¿Ya dije que Ts'o es uno de los principales desarrolladores del sistema de archivos ext4?

Comparado con los demás sistemas operativos la ventaja es mucho más clara (HFS+ y NTFS). El sistema de archivos APFS es cierto es relativamente nuevo y apareció junto con macOS High Sierra. Es decir: Apple se tomó casi 20 años en crear un nuevo sistema de archivos. También hay que decir que en cuanto a funcionalidades, APFS y btrfs están prácticamente igualados.

Btrfs ofrece una buena cantidad de características, las que me parece importante resaltar son:

  • Subvolúmenes: Es un directorio que funciona como un volumen. Como tal, tiene su propia espacio de inodos. Por ejemplo:

Cada subvolumen tiene su propio espacio de inodos

Cada uno de estos archivos muestran un dispositivo diferente:

Cada volumen tiene un número de dispositivo distinto

No obstante, cabe aclarar que no son dispositivos de bloque distintos como podría ser un volumen lógico en LVM.

Cada subvolumen puede ser montado con diferentes opciones e incluso en un +arbol completamente independiente para el usuario o aplicaciones que accede al mismo.

  • CoW: Los usuarios de Linux estamos acostumbrados a usar enlaces duros y enlaces simbóicos. Cada uno tiene sus ventajas y limitaciones. Esta funcionalidad permite copiar un archivo usando otro inodo pero sin consumir más espacio, ya que referencia en realidad al archivo original. Si se hace una modificación en la copia, los metadatos comienzan a apuntar a los nuevos datos. Gracias esta característica podemos hacer subvolumenes que contengan una instantánea de otro subvolumen existente. Todo esto de una manera mucho más consistente que con LVM.

  • Compresión: Otra de las ventajas es la compresión transparente, la cual puede ser por el sistema de archivo entero, por directorio o por archivo (pero por ahora, no por subvolumen).

Hay muchas razones para creer que btrfs puede y/o debería reemplazar a ext4 o xfs. De paso recordemos que xfs no soporta achicar un sistema de archivos y si pensamos zfs como una buena opción, hay problemas tanto de licenciamiento como en rendimiento (ver el artículo de Valerie Aurora, creadora de relatime y autoridad en la materia). Las ediciones de Fedora 33 para estaciones de trabajo y SUSE/openSUSE usan btrfs como sistema de archivos predeterminado. De esta manera podríamos prescindir de LVM e incluso de mdadm para RAID (btrfs tiene su propio soporte para RAID - aunque hay que tener en cuenta que RAID[56] no se considera estable aun). El proyecto btrfs debería tener cuidado de sí mismo, tiene tantas funcionalidades que como dice el dicho "lo perfecto es enemigo de lo bueno" (Ah, por cierto el autor de la frase es de Voltaire, alguien que precisamente no se conformaba con poco). Es decir, el único riesgo que veo en el futuro es convertirse en algo tan complejo que sea difícil de administrar o mantener. Veremos en unos años si logra posicionarse como el sistema de archivos de código abierto más utilizado.

Fuentes y más recursos

Como Usar XDMCP en Linux

  1. Habilitar XDMCP en el servidor

[XDMCPServer] enabled=true port=177

Habilitar el puerto con nftables

Mejor que Xnest howto de tldp.org es viejo gdm mencionan a inittab

  1. Reiniciar Lightdm

systemctl restart lightdm

  1. Dar acceso con nftables

  2. Crear túnel desde el cliente

ssh -N -f -L 10001:localhost:177 sergio@xdmcp-server

  1. Hacer una petción por xdmcp

X -query xdmcp-server -port 10001

Como Compilar un kernel Linux en 10 pasos

Licencia de Creative Commons
Autor: Sergio Belkin. Este obra está bajo una licencia de Creative Commons Reconocimiento-CompartirIgual 4.0 Internacional.

Advertencia

El kernel que viene con las distribuciones es suficiente para la mayoría de los casos. Usar un kernel compilado a mano puede dejar el sistema inusable sino se realiza correctamente. No debería usarse en sistemas en producción salvo que se sepa exactamente qué, por qué y para qué se hace. Hay distribuciones que limitan o no proveen el soporte en sistemas Linux con kernels compilados a mano. Siempre es recomendable hacer un backup tanto del directorio /boot como del directorio /lib/modules.

Motivación

Si no has leído la Advertencia por favor no sigas. Leela detenidamente y seguimos. ¿Ya está? ¡OK! ¿Por qué compilar un kernel hoy en 2020? Un razón es que al compilar se puede aprender que funcionalidades proporciona el kernel, deshabilitar funciones que sabemos no vamos a usar, probar nuevas características ausentes en la versión del kernel de la distribución y también para entender más cómo trabaja el sistema operativo. Este how-to ha sido probado tanto en Debian 10 como en CentOS 8. En una máquina con 2GB y un único procesador llevaría menos de una hora hacerlo (obviamente cuantos más sean los módulos o componentes agregados más va a tardar). Recordar que se puede compilar como un ususuario común y luego pedir privilegios de root para instalar. Basta de palabras y manos a la obra.

1. Instalar los pre-requisitos

yum groupinstall "Development Tools" && yum install ncurses-devel zlib-devel binutils-devel elfutils-libelf-devel libkcapi-hmaccalc openssl-devel

En Debian, deberíamos instalar:

apt -y install build-essential libncurses-dev

2. Bajar las fuentes del kernel

Recomendable bajar o la rama Longterm o bien la Stable, por ejemplo:

curl -L -O https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.8.15.tar.xz

3. Desempaquetar las fuentes

tar avxf linux-5.8.15.tar.xz

4. Entrar en el directorio de las fuentes

cd linux-5.8.15

5. Tomar como referencia el kernel que estamos usando

cp /boot/config-$(uname -r) .config

6. Tomar como base los módulos del kernel que están en uso actualmente 😉 😉

make localmodconfig

(Le damos Enter hasta que termine)

7. Configuramos nuestro kernel a medida

make menuconfig

Esta parte es la más importante. Podemos dejar todo como está pero probablemente haya algo que no estamos usando que no se va a compilar y necesitaremos después. Entonces es importante recorrer algunas secciones para revisar si falta algo, en especial lo que tiene que ver con Netfilter, File Systems, etc . Por ejemplo: tomar los recaudos suficientes si el sistema está virtualizado o si usa containers.

Una vez hecho los ajustes necesarios, guardamos y salimos.

8. Compilamos el kernel

make

9. Instalamos los módulos del kernel con privilegios de root

sudo make modules_install

10. Instalamos el kernel con privilegios de root

sudo make install

¡Listo! Podemos reiniciar y comenzar a usar el kernel compilado por nosotros mismos.

Uso de Paquetes en NeoVim

¿Qué es lo que hace grande a Neovim? Que posee pequeños, pero múy convenientes mejoras acorde a los nuevos tiempos, pero sin reinventar toda la rueda. A veces es buena tener que tirar todo abajo, crear algo completamente nuevo, y empezar todo desde cero. Sí, a veces, pero no siempre, Neovim mantiene todo lo bueno de Vim. Como lo dicen sus desarrolladores:

In matters of taste, prefer Vim/Unix tradition. If there is no relevant Vim/Unix tradition, consider the "common case".

Ya hemos hablado sobre Neovim alguna vez en Lo viejo, lo bueno y lo nuevo en Neovim . Se pueden extender las funcionalidades de neovim, de manera similar a las de su predecesor, el editor Vim. Estas extensiones están escritas en un lenguaje de scripting conocido también VimL. Las extensiones se conocen como plugins y es así como las llamaremos de aquí en más. También tengamos en cuenta que muchas de las cosas que discutiremos aquí aplican para Vim también.

Hay dos tipos de plugins:

  • Globales: Funcionan para todo tipo de archivos.
  • Filetype: Sirven para un tipo particular de archivos.

Veamos un listado de estos archivos:

ls -l /usr/share/nvim/runtime/plugin
total 72
-rw-r--r-- 1 root root  2499 ago  4 21:07 gzip.vim
-rw-r--r-- 1 root root    45 ago  4 21:07 health.vim
-rw-r--r-- 1 root root   429 ago  4 21:07 man.vim
-rw-r--r-- 1 root root   107 ago  4 21:07 matchit.vim
-rw-r--r-- 1 root root  7085 ago  4 21:07 matchparen.vim
-rw-r--r-- 1 root root  9872 ago  4 21:07 netrwPlugin.vim
-rw-r--r-- 1 root root  1929 ago  4 21:07 rplugin.vim
-rw-r--r-- 1 root root  1778 ago  4 21:07 shada.vim
-rw-r--r-- 1 root root   236 ago  4 21:07 spellfile.vim
-rw-r--r-- 1 root root  2271 ago  4 21:07 tarPlugin.vim
-rw-r--r-- 1 root root 10466 ago  4 21:07 tohtml.vim
-rw-r--r-- 1 root root   202 ago  4 21:07 tutor.vim
-rw-r--r-- 1 root root  2510 ago  4 21:07 zipPlugin.vim
Plugin Funcionalidad
gzip Editar archivos comprimidos con gzip
health Framework para solucionar problemas de configuración
man Abrir páginas del manual en el editor
matchit Extiende la funcionalidad del comando %
matchparen Resalta paréntesis coincidentes
netrwPlugin Handles file transfer and remote directory listing across a network
rplugin Manejo de plugins remotos
shada Datos Compartidos entre las sesiones de neovim
spellfile Descarga de archicos de ortografía
tarPlugin Exploración de tarballs
tohtml Conversor a html
tutor Tutorial
zipPlugin Exploración de archivos zip

Si consideramos el archivo del plugin man contiene lo siguiente:

" Maintainer: Anmol Sethi <anmol@aubble.com>

if exists('g:loaded_man')
  finish
endif
let g:loaded_man = 1

command! -bang -bar -range=0 -complete=customlist,man#complete -nargs=* Man
      \ if <bang>0 | set ft=man |
      \ else | call man#open_page(v:count, v:count1, <q-mods>, <f-args>) | endif

augroup man
  autocmd!
  autocmd BufReadCmd man://* call man#read_page(matchstr(expand('<amatch>'), 'man://\zs.*'))
augroup END

Estos scripts pueden contener comandos de modo normal y modo ex, estructuras de control, funciones, listas, diccionarios e incluso objetos.

Además, neovim posee una API con la cual se pueden hacer desarrollos en otros lenguajes de programación, es así como existe neovim-java - Java Client for Neovim API | neovim-java, neovimi (node.js), nvim-client - LuaRocks, equalsraf/neovim-qt: Neovim client library and GUI, in Qt5., etc.

neovim-qt

Se pueden escribir plugins en lenguajes distintos a VimL, por ejemplo far.vim está desarrollado en python:

Se debe ejecutar :UpdateRemotePlugins cada vez que un plugin remoto se instale, se actualice, o se borre. Esto generará o actualizará un archivo manifest, por ejemplo:

cat ~/.local/share/nvim/rplugin.vim 
" node plugins


" python3 plugins
call remote#host#RegisterPlugin('python3', '/root/.local/share/nvim/plugged/far.vim/rplugin/python3/far', [
      \ {'sync': v:false, 'name': '_far_nvim_rpc_async_invoke', 'type': 'function', 'opts': {}},
     \ ])


" ruby plugins


" python plugins

Paquetes de plugins

Paquetes

Photo by Handy Wicaksono on Unsplash

A partir de la versión 8.0 de Vim, el editor tiene la capacidad de instalar paquetes. Podríamos trazar una analogía con los paquetes RPM ( o deb), por ejemplo, el paquete rpm coreutils viene con más de una herramienta: tr, sort, tail; etc. Un paquete en vim de manera análoga puede contener más de un plugin.

Es decir, considerando el siguiente escenario:

Paquetes en Vim/Neovim .

El paquete nuake se va a cargar automáticamente al abrir el editor, mientras que el otro plugin vim-eunuch podrá activarse con el comando :packadd eunuch

Algo interesante en neovim es que podemos ver los plugins que ya vienen con el editor con el comando :help standard-plugin-list y con :help local-additions los paquetes que vamos agregando:

Gestores de plugins

Ahora bien, la manera nativa de manejar paquetes de Vim (que Neovim toma) es un tanto manual. Es muy ventajoso usar un gestor de plugins, el cual siguiendo la analogía con paquetes rpm (o deb) sería algo parecido a lo que representa yum/dnf/zypper respectivamente).

Existen varios gestores de plugins:

Yo uso vim-plug porque:

  • Requiere muy poca configuración: una lista con los paquetes de plugins deseados.
  • Instala y actualiza todos los paquetes de nuestra lista o los que seleccionemos.
  • Detecta y elimina plugins que borramos de nuestra lista.
  • Muestra el estado de los plugins.
  • Genera instantáneas de nuestros paquetes con su configuración, con la posibilidad de restaurarlas.
  • Posee atajos de teclado.

Para deshabilitar todos los plugins se pueden desabilitar con nvim --noplugin.

Algo que puede ser muy útil: poner el listado de plugins en un archivo separado. Esto es: creando un archivo ${XDG_CONFIG_HOME:-$HOME/.config}/nvim/plugins.vim y en el archivo ${XDG_CONFIG_HOME:-$HOME/.config}/nvim/init.vim teniendo una simple línea:

runtime plugins.vim

Entonces, comentando esa línea es una manera alternativa para deshabilitarlos.

Pero hay más: supongamos que tenemos esta configuración en el archivo ${XDG_CONFIG_HOME:-$HOME/.config}/nvim/plugins.vim:

"nuake plugin
Plug 'Lenovsky/nuake' , { 'on': 'Nuake' }  

nnoremap <F4> :Nuake<CR>

El paquete nuake no se cargará automáticamente en el inicio, pero lo hará cuando usemos el atajo de teclado F4. ¿No es genial?

En tiempos en los que tanto se declama la agilidad, como contrasentido se ofrecen editores que consumen muchos recursos, con desarrollos no exentos de torpezas y caprichos impuestos de antemano. El minimalismo de Vim como de Neovim nos permite adaptarlo de acuerdo a lo que necesitemos la posiblidad de agregar distintas funcionalidades, sea para desarrollo, mejor usabilidad y experiencia del usuario (sí: el desarrollador o sysadmin también es un usuario). Finalmente, si bien tanto Vim como Neovim poseen el soporte nativo para manejar paquetes de plugins, encuentro en vim-plugin una manera mucho más conveniente de hacerlo.

Más Recursos

Plan Táctico y Estratégico de la Memoria en Linux

La mitología en torno a la memoria en Linux ha producido una serie de relatos:

  • Linux puede funcionar con muy poca memoria RAM.
  • Linux consume mucha memoria.
  • Una partición SWAP debe tener entre 1 a 2 veces la memoria RAM.

Como vemos algunas historias son más recientes, otros más antiguas, pueden ser parcialmente ciertas y hasta contradictorias entre sí.

Este artículo tiene como propósitos:

  • Explicar de manera sencilla el funcionamiento de la memoria en Linux, desmitificando también algunos conceptos.
  • Enumerar y describir tácticas para que el uso de la memoria proporcione la mejor usabilidad y experiencia del usuario.
  • Ofrecer alternativas para que cada uno elija la mejor opción de acuerdo a sus necesidades.



Definiciones

Vamos a repasar algunos conceptos básicos que de manera más o menos frecuente usamos, usaremos metáforas en el camino. Ninguna metáfora es perfecta, pero nos ayudan a entender la realidad.

Memoria Virtual

Generalmente el adjetivo virtual en informática significa algo que provoca la ilusión de ser otra cosa. Por ejemplo, un archivo regular puede hacerse pasar por un disco físico. En el caso de la memoria virtual, el sistema operativo nos ofrece una cantidad de memoria mucho mayor a la que existe físicamente.

Si queremos comprar algo que sale $100000 pero solamente podemos pagar la décima parte, tal vez podamos pedir un crédito para que se financie la compra y pagar $10000 por mes. El sistema operativo hace algo parecido con la memoria.

De parte del hardware en particular la CPU necesita poder traducir las direcciones de memoria virtual a la memoria física.

Algo muy importante: Linux trata de usar la mayor cantidad de memoria posible, para poder ejecutar las aplicaciones y acceder a los archivos de la manera más rápida posible. De manera que si la memoria libre es baja no es necesariamente un indicativo de un problema.

Swap

Los usuarios ocasionales de Linux y aun muchos sysadmins tienen una idea negativa sobre "la swap". Simplificaciones extremas y conceptos anticuados la han convertido en le gran villana de la historia del sistema operativo.

Si comparamos a la memoria con un escritorio, sin swap podría lucir así:


Prescindir de swap no es una opción sana.

Photo by Ashim D’Silva on Unsplash



Así que primero vamos a decir lo que no es:

  • No es la memoria virtual sino que forma parte de la técnica que realiza el sistema operativo para administrar la memoria.
  • No es un espacio de reserva ni un último recurso.
  • No es algo que el sistema operativo pueda alegremente prescindir aun cuando la cantidad de memoria RAM física sea grande.

Nuestro escritorio con swap:

Analogía de Swap

Photo by Alexandru Acea (edited by me) on Unsplash



¿Los cajones de un escritorio los usamos cuando lo tenemos abarrotado de cosas? No, los usamos para guardar cosas que no son de alta prioridad. Aunque es cierto, si luego queremos usar esa tijera o aquel destornillador en algún momento requerirá un poco más de trabajo, tendremos que abrir el cajón, buscarlo, extraerlo, etc.

Ah, y la swap también sirve para hibernar, aunque honestamente no se cuanta gente mantiene esa práctica.

Page

Es un bloque de memoria virtual.

Page table

Podemos pensarlo como un índice usado por el hardware que refiere cada dirección de memoria virtual a una dirección de memoria física.

Page Fault

Una page fault ocurre cuando un programa intenta acceder a un bloque que está mapeado en el espacio de direcciones pero no está cargado en la RAM. Si bien no es un problema grave pero implica que el programa tendrá que recuperar la información desde el disco, que es un proceso más lento.

Page cache

Es el espacio en que los archivos y metadatos utilizados suelen guardarse para poder acceder a ellos de manera más rápida.

Page cache


Tipos de memoria

File Memory

Es la memoria relacionada con el Page Cache.

Anonymous Memory

El adagio unixista (en su versión simplificada) que dice que todo es archivo parece tener influencia aquí. Tal vez es por eso que la memoria que no está asociada a un archivo o al sistema de archivos se la reduce con el adjetivo de anónima.

Thrashing

Es cuando el sistema agresivamente traduce direcciones físicas a direcciones virtuales y libera bloques de memoria que no se han usado de manera reciente. La ejecución normal de las tareas puede resentirse. En entornos de escritorio la usabilidad y la experiencia del usuario se ven fuertemente afectadas. La swap puede colaborar evitando al menos un poco el thrashing.

A veces puede suceder cuando la memoria física (RAM) es insuficiente.

Memory Pressure

Memory pressure** es el trabajo que tiene que hacer Linux cuando hay déficit de memoria. En ciertas situaciones puede haber demora en la ejecución de tareas, y que el rendimiento se vea seriamente afectado y llevado al extremo puede causar OOM (Out-of-Memory): el agotamiento total de la memoria para que el sistema operativo pueda continuar funcionando correctamente.

OOMKiller

El OOM killer es un proceso del kernel que se dispara solamente si la memoria disponible bajó a niveles críticos, en este escenario selecciona una o más tareas para finalizarla con la intención de que el sistema pueda seguir funcionando.

oom_score

A cada proceso se le asigna un puntaje, cuanto más alto es, más susceptible es a ser terminado por OOMKiller. El comando choom permite ver y/o ajustar dicho valor.

choom

Tuning

Ahora veremos diferentes tácticas que podemos usar para optimizar el uso de la memoria.

cgroupv2

cgroup es un mecanismo para organizar los procesos de manera jerárquica y distribuir los recursos del sistema a lo largo de la jerarquía en una manera controlada y configurada.

Un cgroup se compone de un núcleo que es responsable primariamente en organizar de manera jerárquica los procesos y controladores que comúnmente distribuyen un tipo específico de recurso del sistema a lo largo de la jerarquía.

En la versión 2 de cgroup un proceso no puede pertenecer a diferentes grupos para diferentes controladores. Si el proceso se uno al grupo alfa, todos los controladores para alfa tomarán control de ese proceso.

ps mostrando cgroup

Supongamos que los procesos de un cgroup (y todos los grupos hijos) usan poca memoria, podríamos decirle al kernel que reclame memoria de otros cgroups. Esto es precisamente lo que hace el parámetro memory.low.

el parámetro memory.low

Otro parámetro interesante para monitorear es memory.pressure, la primera línea que tiene el tiempo físico de una o más tareas demoradas debido a la falta de memoria. La segunda sería lo mismo pero para todas las tareas del grupo, por ejemplo: full es lo mismo pero para todas las tareas del grupo, por ejemplo: Por ejemplo:

cat /sys/fs/cgroup/user.slice/memory.pressure
some avg10=0.00 avg60=0.13 avg300=0.12 total=1690238
full avg10=0.00 avg60=0.10 avg300=0.09 total=1394199

Significa que algunas tareas del grupo de control user.slice en los últimos 10 segundos no tuvo demoras, pero si tuvo un 0,13% de retraso en el último minuto y 0,12% en los últimos 5 minutos. En total estas tareas llevan acumulados casi 1,7 segundos. La segunda línea representa lo mismo pero para todas las tareas del grupo.

zram

zram es por así decirlo, una manera cool de usar swap gracias a un módulo del kernel.

zram, swap pero cool

Photo by chuttersnap on Unsplash

En lugar de gastar espacio en un disco (sea rígido o sólido) usamos dispositivos de bloque en la propia RAM. Los bloques swapeados se guardan comprimidos. Esto discos virtuales son rápidos y ahorran memoria.

Una de las pocas desventajas que tiene esta metodología es la incapacidad para poder hibernar el sistema operativo, al no estar presente la partición en un almacenamiento de tipo persistente.

zram

Sistemas de archivos

El journal de ext4 puede ser lento, xfs puede ser una mejor alternativa o mejor aun btrfs.

EarlyOOM

El oom-killer del kernel solamente se dispara en situaciones extremas y le puede llevar mucho tiempo hasta que puede enviar SIGKILL a los procesos que sean necesarios para poder liberar memoria. Durante ese tiempo probablemente el usuario no pueda interactuar con el sistema operativo.

EarlyOOM trabaja en espacio de usuario y por lo tanto se puede anticipar y ser mucho más rápido.

El comportamiento predeterminado en Fedora es que si hay menos del 10% de RAM y/o SWAP libre, earlyoom envía una señal de terminación a todos los procesos con oom_score más alto. Si la RAM como SWAP libre bajan por debajo del 5%, earlyroom enviará una señal para matar todos los procesos con oom_score más elevado.

La idea es recuperar la usabilidad (especialmente en un entorno de escritorio) lo antes posible.

El problema es que EarlyOOM no soporta al momento la medición de la memory pressure como indicativo para tomar decisiones.

nohang

Este servicio es mucho más configurable y aporta una mejor solución que EarlyOOM.

Algunas funcionalidad son:

  • Se puede elegir la acción que realizará en una situación OOM.
  • Ofrece varios criterios para elegir los procesos a finalizar.
  • Soporta zram
  • Puede usar memory pressure para tomar una acción.
  • El archivo de configuración es medianamente sencillo



zswap

Con zswap no reemplazamos el espacio swap en el disco sino que usamos un caché comprimido en la RAM. Este método ahorra I/O, obteniendo entonces mejor rendimiento y alargando la vida útil de discos flash o sólidos. La única desventaja es usar algo de tiempo del procesador para realizar la compresión.



zswap

Photo by Pineapple Supply Co. on Unsplash



Mediante el caché se logra una diferenciación entre páginas más usadas (zswap) y menos usadas (swap).

oomd

El servicio oomd es un proyecto en el que están trabajando en Facebook para integrarlo con systemd. Por ahora es un proyecto para manejo de memoria a gran escala, y bastante más complejo de configurar.

Resumen

  • Swap no es la villana de la película
  • Si existe la opción de migrar a otros sistema de archivos aunque con características un tanto experimental, elegir btrfs. Una opción más moderada es xfs.
  • El tuning de cgroupv2 puede traer grandes beneficios, no obstante existen proyectos y distribuciones que no lo usan.
  • EarlyOOM es una solución rápida y aplicable a una amplia gama de sistemas Linux, aunque no siempre es la más exacta ni más elegante.
  • El servicio nohang (o no hang-desktop) es una opción más madura aunque algo más compleja que EarlyOOM.
  • El servicio oomd desarrollado por Facebook es seguramente la opción más adecuada para escenarios más complejos y de manejo de memoria a gran escala.
  • Si se desea ahorrar espacio en disco se puede reemplazar la swap por zram, sacrificando la opción de hibernar el sistema.
  • La opción zswap es más sofisticada, aunque dependemos del uso de swap en disco.



Photo by sk on Unsplash

Fuentes consultadas

Tutorial de LXC

Containers

Photo by frank mckenna on Unsplash

LXC es una herramienta extraordinaria, algo intermedio entre un chroot y una máquina virtualizada completamente. Usando el mismo kernel que el sistema anfitrión podemos tener sistemas operativos invitados en el propio filesystem. Es decir, cada SO invitado en un directorio. Pero la documentación y la interacción de los distintos componentes puede tornar algo tricky el proceso. Cansado de lidiar con documentación desperdigada por aquí y por allá decidí crear mi propio tutorial. Intentando en lo posible ser distro-agnóstico.

Aquí está:

¡Espero que lo disfruten!

Un abrazo peligroso

¿Cuán genuino es la movida de Microsoft hacia el Software Libre?

dangerous

Photo by Samuel Scrimshaw on Unsplash

Recientemente Dona Sarkar dijo:

Windows no puede ser de código abierto por cuestiones como pueden ser nuestras políticas de privaciad y protección de datos. Un proyecto que empieza siendo de código abierto puede mantenerse así, pero uno que ha nacido dentro de un entorno cerrado, es más difícil de abrir.

Aquí nos presentamos con una falacia. Primero: ¿qué tiene que ver las políticas de privacidad y protección de datos con la apertura del código fuente?

Cualquiera con un mínimo de conocimiento profesional en informática encontrará esa explicación problemática.

¿Qué impedimentos tiene que tener el código fuente de un programa para contravenir las políticas de privacidad y protección de datos?

A mi en principio se me ocurren solamente dos, supongamos que tenemos un programa llamado ABC123 de la empresa ficticia Example Inc. Puede ser el que el código fuente utilce código patentado por otra empresa llamado AnotherOne Inc. En algún momento de la historia Example Inc. y Another Inc. hicieron un acuerdo de no revelación de código fuente.

Ese puede ser perfectamente un obstáculo para la revelación del código fuente. Pero claro en ese caso no tiene nada que ver con el interés por privacidad o la salvaguarda de los datos de los usuarios.

Otra posibilidad que sería ciertamente nefasta es que el programa almacene datos sensibles de las personas.

El código fuente de acuerdo a Wikipedia es

Es cualquier colección de código, posiblemente con comentarios escrito usando un lenguaje de programación legible por humanos, usualmente como texto plano.

Es decir, el código fuente es escrito por los programadores, los datos no forman parte y no debería haber razones para considerarlo así. Y si alguien considera que los datos sí forman parte es grave porque están utilizando los datos del usuario con fines comerciales.

Y el funcionamiento del programa ABC123 está desarrollado de una manera en el que sea imposible disociar los datos de del resto del código está ciertamente mal diseñado y el usuario está siendo damnificado por esa situación.

Lo cierto es que hasta ahora nadie le ha preguntado seriamente a Microsoft por qué no libera el código fuente de Windows.

Fuentes:

El principio de Le Châtelier

Ya siendo adolescente me fascinaba el principio de Le Châtelier que enuncia:

Si se presenta una perturbación externa sobre un sistema en equilibrio, el sistema se ajustará de tal manera que se cancele parcialmente dicha perturbación en la medida que el sistema alcanza una nueva posición de equilibrio.

No siempre los equilibrios son ventajosos, a veces necesitamos romperlo para conseguir un beneficio.

Crisis

unsplash-logo Jan Tinneberg

¿Qué sucede si pensamos esto en términos sociales?

De hecho, hay un principio similar en economía formulado por Paul Samuelson en 1947. En biología este concepto se conoce como homeostasis.

Probablemente, la humanidad nunca estuvo ante una perturbación del equilibrio desde la segunda guerra mundial o incluso desde la caída del muro de Berlín.

¿Qué está haciendo hoy el equilibrio para restablecer el equilibrio? Creo que es una pregunta.

Es importante que nuestros dirigentes estén en el aspecto ético a la altura de las circunstancias. Pero entendiendo también que viejos conceptos son insuficientes. Una discusión entre "más estado" o liberalismo no alcanza. Es importante entender el grado en que la tecnología hoy nos rodea. Para qué se usa. Quienes son los dueños.

En un tiempo en que todos corremos detrás de los servicio de Internet, creo que más que nunca tenemos que hacernos preguntas sobre ella. Cuestionarnos la obsesión por los datos, por la rapidez vacía de resultados benéficos reales sobre las personas.

Un tiempo para que podamos descubrir que un empleado feliz puede ser más creativo y más productivo. El trabajo del hombre respetando a la naturaleza y por ende al mismo hombre contenido en ella.

Por primera vez después de mucho tiempo empezábamos a perder la vergüenza de decir que las personas son más importantes que las ganancias económicas.

Sin embargo, pudimos ver claramente en los últimos días como han aparecido las fuerzas que pretenden restablecer un equilibrio que perjudica a las grandes mayorías, dentro las cuales están los que menos tienen.

Enlaces de Interés