Cómo controlar el runlevel en Linux con systemd

La tecnología va evolucionando de forma inexorable con el paso de los años, haciendo que algunos conceptos que se han mantenido intocables con el paso de los años, cambien; cosa inevitable. Esto hace que, nos guste o no, tengamos que adaptarnos a dichos cambios. Uno de los cambios más polémicos que han tenido los entornos de GNU/Linux, es sin lugar a dudas la implantación de systemd, que se ha aplicado a la mayoría de sistemas operativos actuales, con algunas excepciones tales como Devuan. Dicho cambio supone la obligación del aprendizaje de nuevos conceptos, pues aunque en algunos sistemas como Debian o Ubuntu, existen varios enlaces simbólicos para algunas funciones con el fin de que la curva de aprendizaje sea mucho más suave, existen algunas funcionalidades que estamos obligados a aprendernos sí o sí. Uno de dichos conceptos sería el manejo del runlevel del sistema.

Ya se ha hablado de dicho concepto con anterioridad en este blog; pero en dicho caso se trató el concepto con un init de System V; init que ,para bien o para mal, va a tender a desaparecer o perder relevancia progresivamente. En este caso trataremos el el manejo del runlevel, o nivel de ejecución, en un entorno con un init systemd.

Para ello lo primero que tenemos que tener en cuenta es que para hacer referencia a dichos niveles de ejecución, no se hace numéricamente como antes (0, apagado, 1 modo monousuario, etc...), sino que se hace mediante descripciones más técnicas; descripciones a las que luego se hacen referencia mediante enlaces simbólicos, cuyos nombres son parecidos a los usados en System V (runlevel0.target, runlevel1.target...) pero que no dejan de ser enlaces simbólicos, con lo que es mejor tener claros los nombres reales de los niveles de ejecución en systemd. He aquí una pequeña tabla con los runlevels de System V, los nombre "intuitivos" usados en systemd, y los nombres reales utilizados en systemd:

Tabla nombre runlevels

Teniendo claros dichos conceptos, nosotros nos vamos a centrar en los nombres "reales" usados en systemd, sin uso de alias, pues dichos alias puede que en un futuro desaparezcan y es mejor intentar no crear posibles malos hábitos.

Para adivinar el runlevel usado por defecto por el sistema podemos recurrir a la herramienta principal de systemd: systemctl. En concreto habría que recurrir al siguiente comando:

root@debian:~# systemctl get-default
graphical.target

Por defecto, lo más común sería que viésemos el resultado mostrado arriba; es decir el runlevel graphical.target; o lo que sería lo mismo, el runlevel5 en System V. Además, si bien lo más común es que coincidan, podemos ver el runlevel actual de diferentes formas:

La primera, y menos recomendada debido a que con el tiempo la obsoletarán, será mediante el comando usado siempre en sistemas system V; es decir mediante el comando runlevel:

root@debian:~# runlevel
5

Otra forma de conocer el runlevel, es mediante systemctl, el cual ofrece un resultado más preciso pero que desgraciadamente no muestra un valor único; veréis, si os fijas bien todos los nombres acaban en "target", y es debido a que ahora muchos conceptos son denominados así, con lo que si listamos todos los targets cargados por el sistema, tendremos que ver entre dicho listado nuestro runlevel actual; el problema es que si bien la información es fidedigna, requiere o bien poner muchos greps para mostrar únicamente una línea, o fijarse entre las líneas mostradas en aquella que hace referencia al runlevel; he aquí el comando y el resultado mostrado por este:

systemctl list-units --type target |grep loaded

Teniendo en mano la información deseada, ahora podemos proceder a cambiar el runlevel, cambio que se puede hacer de dos formas diferentes.

El primero y el más "sólido" sería cambiando el runlevel por defecto usado por el sistema. Esto haría que a partir del siguiente reinicio siempre se usase dicho runlevel; lo cual en algunos casos puede ser útil aunque habría que ser muy cuidadoso, ya que en dicho caso nunca podríamos usar los "targets" poweroff.target ni reboot.target, pues en caso contrario no podríamos arrancar con normalidad a menos que editasemos el runlevel en el propio GRUB para dicho arranque en cuestión. Dicho cambio se haría mediante el comando systemctl tal que así:

systemctl set-default nombre_target

Por ejemplo:

systemctl set-default rescue.target

Esta acción cambiará el runlevel que cargaremos por defecto y si nos fijamos bien veremos que en realidad lo que realiza es un enlace simbólico desde /lib/systemd/system/nombre_target a /etc/systemd/system/default.target, con lo que en caso de no sentirnos cómodos usando la herramienta systemctl, podemos optar por cambiar el runlevel por defecto de la siguiente forma:

rm /etc/systemd/system/default.target
ln -s /lib/systemd/system/rescue.target \
/etc/systemd/system/default.target

Si en cambio quisiésemos cambiar el runlevel del sistema únicamente para la sesión actual, habría que optar por otro comando de systemctl; en concreto sería:

systemctl isolate nombre_target

Por ejemplo:

systemctl isolate rescue.target

Como veis, la manipulación del runlevel mantiene las mismas bases que en system V, con la diferencia de que se usan herramientas y nomenclaturas distintas; lo más importante dentro de los runlevels de systemd no sería el conocimiento de la herramienta de systemctl, sino la comprensión de las nuevas nomenclaturas de éstos, nomenclaturas que ahora sería "targets" y que estarían estrechamente ligadas a la definición de cada nivel de ejecución.

Espero que os haya resultado útil.

Saludos.

Cómo emular comportamientos de red en Linux con Net Emulation

Tras una buena temporada sin escribir, por fin vuelvo con las pilas cargadas y con un artículo que, en mi opinión puede serle muy útil a muchos. En la ocasión de hoy quiero poneros en un situación hipotética. Tenemos un equipo con un sistema operativo Linux (no importa que sea Debian o Red Hat) con el que queremos emular comportamientos "extraños" de red... Lo normal, y deseado, es que una red esté correctamente gestionada, que el tráfico de red fluya con fluidez, que todos los elementos de la red se comuniquen entre sí sin problemas, etc... Esto es lo deseable, pero no siempre lo que ocurre debido a un sin fin de factores, entre los cuales se encontraría, por supuesto, el factor humano. La cuestión está en que a veces, la mejor forma de resolver el problema, es emulándolo primero para después ver cómo solventarlo, y he ahí donde entra en juego la herramienta tc (Traffic Controller); más concretamente uno de sus módulos llamado netem, más conocido como Net Emulation.

Net Emulation permite crear situaciones que nos permiten emular ciertos comportamientos indeseados, tales como retardos, paquetes erróneos, duplicidades, etc... Es decir que nos permite crear situaciones indeseadas de forma controlada con el fin analizar posibles reacciones por ciertos equipos ante dichas situaciones. Tanto la herramienta Traffic Control como el módulo netem vienen por defecto incluidos en Linux, pues ambos vienen incluidos por defecto con la paquetería de iproute2 con lo que afortunadamente no requieren instalación alguna. 

El uso de este módulo en sí es bastante sencillo, si bien es importante conocer la estructura general que es necesaria conocer:

tc qdisc acción dev nombre_interfaz usuario netem acción_netem

Aquí podemos ver cuatro partes en cursiva, que serían las que variarían dependiendo de nuestras necesidades, cada parte tendría el siguiente significado:

• Acción: Cuando escribimos el comando siempre hay que especificar si se va a añadir un comportamiento personalizado, si se va a modificar o eliminar. Es decir que en esta parte podemos optar por hacer: add, change o del. Es importante tener en cuenta que una vez añadido una emulación a la interfaz de red, no podremos hacer otro add, sino que tendremos que hacer un change para modificarla o un del para eliminarla.
• Nombre_interfaz: Simplemente le decimos sobre qué interfaz de red queremos aplicar la emulación de red.
• Usuario: El usuario que realizará el cambio de comportamiento. Por lo general siempre será root.
• Comportamiento: Finalmente diríamos que comportamiento queremos emular; es decir qué emulación de red queremos hacer. Esta parte al ser algo extensa la explicaré con más detalle más adelante.

Teniendo clara esta estructura base, podemos empezar a realizar las primeras emulaciones de red.

Comenzaremos con una emulación muy sencilla pero muy útil, que es la de la implantación de retardos. Esto hace que cualquier interacción realizada con esta interfaz tardará un tiempo extra en ser realizada. Esto se logra gracias al comportamiento delay, cuyo comando completo sería:

tc qdisc acción dev nombre_interfaz usuario netem delay retardo_en_milisegundos

He aquí un comando a modo de ejemplo en el que vamos a añadirle un retardo de 200 ms a la interfaz de red eth0, con el usuario root:

tc qdisc add dev eth0 root netem delay 200ms

Una forma muy fácil de comprobar el efecto de este cambio es haciéndole un simple ping a la IP de dicha interfaz de red, tal y como podéis ver en la siguiente imagen:

Además de poner un retardo de Xms, podemos también hacer que dicho valor no siempre sea fijo, sino que oscile entre ese valor y Xms arriba o abajo de forma aleatoria. Por ejemplo si pusiésemos el mismo comando de antes con una oscilación de 10ms, la latencia del ping podría ser hasta 10ms mayor o menor.  He aquí el comando que haría referencia a exactamente dicho ejemplo:

tc qdisc add dev eth0 root netem delay 200ms 10ms

En la imagen de a continuación podemos apreciar esa oscilación:

Obviamente podemos hacer más cosas aparte de crear retardos; otra funcionalidad muy útil de este módulo sería la de la posibilidad de que los paquetes recibidos se consideren como "perdidos", es decir que hayan paquetes que no hayan llegado a su destino. Para ello, en vez de recurrir al comportamiento delay recurriremos a loss, comportamiento en el que especificaremos qué % de paquetes queremos que se "pierdan". Por ejemplo podemos hacer que la mitad de los paquetes no lleguen a su destino, para lo cual el comando sería el siguiente:

tc qdisc add dev eth0 root netem loss 50%

Al igual que antes, con un simple ping también podemos verificar que ahora alrededor de la mitad de los paquetes enviados se perderán; he aquí una pequeña muestra a modo de ejemplo:

Casi tan grave como la perdida de paquetes es la duplicidad de éstos, cosa que afortunadamente también es emulable en Linux. Dicha emulación es posible gracias al comportamiento duplicate y usa la misma sintaxis que el anterior comando, sustituyendo, obviamente, loss por duplicate.

tc qdisc add dev eth0 root netem duplicate 50%

En este caso algunos de los pings que mandemos al equipo recibirán como respuesta que hay una duplicidad; es decir que respondería como si hubiesen dos equipos con la misma IP en la misma VLAN. Dichos pings con respuesta de duplicidad en la red tendrían la etiqueta DUP!, tal y como se puede ver en la siguiente captura:

Otro problema que puede surgir en una red es que los paquetes de red se encuentren corruptos, cosa que también podemos emular gracias corrupt que tiene la misma sintaxis que el anterior comando, sustituyendo duplicate por corrupt.

tc qdisc add dev eth0 root netem corrupt 50%

En este caso, la respuesta que recibiremos al hacerle ping será que se esperaba un valor determinado pero que han recibido uno diferente al que se debía, mostrándonos algo como lo de la captura mostrada aquí abajo:

Estas serían las diferentes emulaciones que se pueden hacer gracias a esta herramienta; emulaciones que, en mi opinión, no son pocas y pueden ser de gran ayuda a la hora de intentar reproducir problemas reales para después encontrarles solución. La potencia de el módulo Net Emulation queda patente ya que es increíblemente flexible y versátil. Obviamente las funciones pueden combinarse; es decir que se puede hacer que haya un delay determinado, con un % determinado de paquetes erróneos otro % determinado de paquetes duplicados, etc... Por ejemplo, podemos querer editar una de las reglas que hemos creado atrás para que tenga toda esta combinación de comportamientos; con lo que en vez de usar add, usaremos change para obtener el siguiente comando:

tc qdisc change dev eth0 root netem delay 100ms 20ms \
loss 1% duplicate 0.5% 

Como podéis observar, el comando no es más que una combinación de los atrás vistos, con el cual se puede combinar una latencia alta con un pequeño porcentaje de paquetes perdidos y uno aun menor de duplicados. Un detalle importante a la hora de hacer uso de la función change; si nos fijamos en el valor anterior, se hace un change a los valores delay, loss y duplicate. Si anteriormente hubiese sido especificado un valor para corrupt, la acción change no modificaría su valor ni lo eliminaría a menos que se especificase específicamente. Es decir que si por ejemplo hubiésemos hecho un corrupt del 50% y luego hubiésemos introducido este comando, el valor de corrupt sería siendo el mismo.

Finalmente, para eliminar estos comportamientos especiales por completo, podemos recurrir a la acción del, para lo cual simplemente habría que escribir:

tc qdisc del dev eth0 root netem

Tal y como se puede ver en este artículo, la emulación de diferentes situaciones "conflictivas" es más sencillo de lo que parece, y afortunadamente, todo ello se puede hacer desde cualquier equipo con Linux instalado y sin herramienta especial alguna, estando dicha emulación al alcance de todo el mundo.

Espero que os haya resultado útil.

Saludos.

Flatpak: El "rival" de Snap creado por Red Hat

Hace alrededor de dos meses, con la aparición de la nueva LTS de Ubuntu, se habló en este blog sobre una de las características más novedosas de esa distribución: Los paquetes Snap. Dicho paquetes suponen una revolución en lo que se refiere a la paquetería, pues aportaba por un lado más seguridad todo lo instalado mediante dichos paquetes se realizaba en "sandboxes" aislados del resto de paquetes, haciendo que cualquier posible daño al programa instalado mediante Snap, no repercutiese en el resto... Además Snap también hacía desaparecer la necesidad de descargar las dependencias necesarias para el paquete en cuestión, pues ya las incluye todas dentro de éste (haciendo que obviamente, el paquete pesase bastante más que un paquete "normal). La cuestión está que Snap es un recurso exclusivo de Ubuntu y era obvio que Red Hat iba a tomar cartas en el asunto... Y así ha sido, pues Flatpak ha sido oficialmente anunciado por dicha compañía, haciendo que la "guerra" de paquetes vuelva de nuevo, con la diferencia de que en este caso los miembros serían Snap y Flatpak en vez de deb y rpm.

Con el total respaldo de Red Hat, Flatpak parece llegará para quedarse y para impulsar el uso de éste en vez de Snap, argumentando tener las mismas características que Snap, pero no solo eso sino que además argumenta tener una cualidad que ningún otro sistema de paquetes posee: La posibilidad de acabar con una de las mayores pegas del mundo Linux, que es nada más y nada menos que la fragmentación. Es decir que su gran baza consiste en que dicha paquetería podría usarse como un standard válido para cualquier distribución lo cual hace que Flatpak sea una alternativa bastante atractiva. Por otro lado, si bien un paquete Flatpak siempre ocupará más que un rpm o deb, al parecer van a intentar reducir su tamaño lo máximo posible haciendo que las librerías y/o otros componentes estén deduplicados (Parece un concepto inventado, pero existe), con lo cual lograrían no solo que ocupasen menos en el disco duro, sino que los tiempos de descarga del paquete Flatpak sea el mínimo posible...

Obviamente a Flatpak le queda tiempo por madurar... Es una tecnología nueva, y probablemente necesite de cierto tiempo para ir puliéndose progresivamente... Es más, de momento parece que estos paquetes estarán disponibles únicamente en Fedora, pues probablemente querrán que esta distribución sirva como "campo de pruebas" antes de arriesgarse a incluirlo en Red Hat; una decisión muy inteligente por su parte, dicho sea de paso.

Al igual que Snap, los paquetes disponibles actualmente son bastante escasos, pero lo cierto es que actualmente tienen algunos paquetes de mucha relevancia ya disponibles bajo dicho formato, tales como LibreOffice o GIMP, con lo que todo apunta a que van a apostar fuertemente por dicha tecnología, si bien obviamente la decisión de usar dichos paquetes o no, recaerá, al menos de momento, en el usuario final... 

Todo parece que Ubuntu y Red Hat han puesto toda la carne en el asador y que la "carrera" entre ambos no ha hecho más que comenzar... Con Snap respaldado por Ubuntu y Flatpak por Red Hat, indudablemente ambos llegarán lejos ¿Logrará uno superponerse al otro? Yo espero que ambos triunfen, pues indudablemente Linux está compuesto de "sabores" y elecciones, y la adopción de una única elección supondría una situación muy parecida a la vivida con systemd. Lo que es indudable es que ambas tecnologías darán que hablar en los próximos años, cosa que esperemos que sirva para impulsar el uso del software libre.

Espero que os haya resultado interesante.

Saludos.

Diferencia entre virtualización KVM y OpenVz

Hoy quiero hablaros sobre una de las mayores modas del presente: La virtualización. En anteriores artículos ya he hablado algo sobre tecnologías de virtualización, tales como Proxmox, pero hasta ahora me he centrado más en la herramienta que en el concepto... Cosa que en general no es malo, pero hoy quiero hablar de la virtualización en un sentido más teórico con el fin de que entendáis qué tipo de virtualización elegir dependiendo de vuestras necesidades.

A lo largo de los años la virtualización ha ido evolucionando y ha ido adaptándose a las necesidades de los usuarios y/o del mercado. Dicha evolución se ha traducido en diferentes tipos de virtualización que van mucho más allá de las herramientas "clásicas", tales como VMware o VirtualBox, otorgándonos un amplio abanico de posibilidades para elegir. Entre dichos tipos, hay dos de ellos que han demostrado ser los más eficientes de todos y los más "innovadores" en el campo de la virtualización. Dichos tipos de virtualización se denominan Virtualización a nivel de sistema operativo y Virtualización a nivel de Kernel; si bien son más conocidos por las herramientas que hacen uso de dichas tecnologías: Openvz y KVM (respectivamente).

Ambas virtualizaciones son muy útiles, pero tienen una serie de diferencias entre sí que, si bien a primera vista no pueden parecer muy significativas, en la práctica pueden ser decisivas a la hora de decantarse por una elección u otra. Para entender la diferencia entre ambas lo mejor sería entender lo que nos ofrece cada tipo de virtualización.

Comencemos por la virtualización a nivel de sistema operativo. Esta tecnología virtualiza los sistemas sobre el propio sistema operativo, es decir que, a diferencia de las virtualización tradicional, no usa ninguna capa intermedia de virtualización. La máquina virtual creada mediante esta tecnología es denominada container, y tiene la gran ventaja de que tiene un gran rendimiento y que permite hacer cambios en el container sin necesidad de apagar/reiniciar dicho container. Dichos cambios pueden ser desde cambiar el tamaño del disco duro hasta aumentar la memoria RAM. El motivo de dicha eficiencia en los containers es que éstos comparten el mismo kernel y los mismos binarios que el sistema operativo original, haciendo que se pierda muy poca eficiencia en el entorno virtualizado... Aún así, dicha compartición  hace que el container solamente pueda tener instalado un sistema operativo que tenga unos binarios parecidos al sistema operativo original. La tecnología de de containers es usada en distribuciones Linux, con lo que es imposible crear un container Windows. Además, si por ejemplo el sistema operativo original fuese Debian; no podríamos instalar un container con un sistema operativo basado en tecnología Red-Hat. Con lo que a modo de resumen se podría decir que los containers:

• Son muy eficientes a nivel de rendimiento.
• Ofrecen una gran flexibilidad a la hora de manipular el hardware virtualizado, pues se puede modificar éste sin necesidad de reiniciar, cosa especialmente útil para un servidor web o un servidor ftp.
• Usa el mismo Kernel y binarios que el sistema operativo original.
• Tiene ciertas limitaciones con los sistemas a instalar. Solo puede instalar distribuciones "parecidas" a la original y es imposible instalar Windows.

La virtualización a nivel de Kernel, en cambio, es algo más "sutil" que los containers, Esto es debido a que convierte el kernel en hipervisor (capa intermedia de virtualización), y hace que la virtualización se ejecute en el propio núcleo del sistema operativo, logrando una gran eficiencia y estabilidad... Esto no significa que la máquina virtual que instalemos comparta el mismo núcleo que el sistema operativo original (como ocurre con los containers) sino que la capa de virtualización se encuentra en el núcleo en vez de en el sistema operativo (como ocurre habitualmente), quitando capas innecesarias y haciendo que la virtualización sea muy eficiente. Otra de las grandes ventajas que ofrece este tipo de virtualización con respecto a los containers, es que las máquinas virtuales creadas aquí  son completamente independientes del sistema operativo original, haciendo que sea una alternativa mucho más recomendable en términos de seguridad. Resumiendo, esta virtualización ofrecería:

• Máquinas virtuales que pueden ser tratadas cómo sistemas independientes (a diferencia de los containers). Esto significa que puede instalar sistemas de cualquier tipo, incluido Windows.
• Máquinas virtuales que ofrecen un gran rendimiento.
• Máquinas virtuales que se pueden securizar de forma eficiente.

Visto esto, se podría decir que en caso de instalar un sistema operativo Linux, habría que valorar si deseamos una máquina más orientada a la estabilidad/seguridad, para lo cual usaríamos KVM; o una máquina más orientada a la flexibilidad y escalabilidad, para lo cual usaríamos OpenVz. Obviamente habría que tener cuidado con los sistemas que instalaríamos en los containers, pues hemos de tener en cuenta que los binarios tienen que ser compatibles con el sistema operativo original. En caso de optar por un sistema operativo Windows; aquí la única opción posible sería KVM, pues sería el único que ofrecería un entornos virtualizado independiente.

Espero que con este pequeño articulo os hayan quedado más claros los conceptos más importantes de la virtualización y que gracias a esto tengáis una pequeña referencia las ventajas y desventajas que ofrece cada tipo de virtualización.

Saludos.

Alien, el conversor universal en Linux

Hola a todos; hoy os vengo con un pequeño  pero muy interesante articulo que a más de uno le puede resultar muy útil. Todos sabemos que Linux está lleno de diferentes "sabores"... A algunos les gustan más los sistemas relacionados con el mundo empresarial como pueden ser CentOS o Red Hat, mientras que otros prefieren optar por el clásico Ubuntu por la gran cantidad de información disponible en Internet, o Debian por su estabilidad. Otros prefieren optar por sistemas menos conocidos y escogen sistemas como Arch o Manjaro... Todos pertenecen a Linux, pero cada sistema operativo tiene sus particularidades y sus características que lo convierte en un "sabor" único. Aún así la gran mayoría se pueden englobar en tres grandes categorías (hay más, pero serían las más conocidas): Debian, Red Hat y Arch. Esto es debido a que si bien existe una enorme variedad de sistemas disponibles, la gran mayoría están basados en sistemas ya existentes, sistemas que en la gran mayoría de las veces son los tres que he mencionado; especialmente los dos primeros, ya que Arch es bastante menos conocido/usado.

Debian y Red Hat tienen muchas diferencias entres sí, y si bien con la llegada de systemd se han puesto varias cosas en común; todavía existen muchas características únicas de estos dos sistemas. Entre ellas estarían los paquetes que éstos usan: RPM para Red Hat y DEB para Debian.

A la hora de querer instalar un nuevo software en una distribución, tendríamos dos opciones disponibles: La primera y más práctica sería recurrir al gestor de paquetes del sistema operativo, con el cual podemos instalar casi instantáneamente una enorme cantidad de herramientas; dichos gestores se denominarían apt-get en Debian y yum en Red-Hat. Obviamente estos repositorios no son infalibles y no tienen todos los paquetes existentes, con lo que a veces es necesario instalar los paquetes .deb o .rpm a mano, cosa bastante sencilla en general; ¿Pero qué pasa cuando dichos paquetes no existen? ¿Qué pasa cuando buscamos un paquete para Debian pero solo existe para Red Hat o viceversa? Ahí es donde entraría la herramienta de la que os quiero hablar hoy: Alien.

Alien es una herramienta muy sencilla e intuitiva que permite convertir paquetes de formato deb en rpm y viceversa. La conversión generalmente da problemas y convierte casi al instante los paquetes de un formato a otro, ahorrándonos tener que recurrir a métodos o herramientas alternativas. La conversión de un paquete .deb a .rpm se realizaría usando esta estructura:

alien -d paquete.rpm

En cambio si deseásemos realizar una conversión inversa; es decir de .rpm a .deb, usaríamos el parámetro -r:

alien -r paquete.deb

Un buen ejemplo de ello sería el paquete Networker; también conocido como lgtoclnt.

alien -d lgtoclnt-7.5.1-1.i686.rpm

El problema que tiene dicha conversión es que por defecto no incluye los scripts de pre-instalación y post-instalación; scripts que aplicarían las configuraciones relacionadas con el paquete. Esto en la mayoría de las ocasiones puede ser un problema, con lo que lo mejor es incluirlos mediante el parámetro --scripts.

alien --scripts -d lgtoclnt-7.5.1-1.i686.rpm

Además, alien es capaz de tratar con más paquetes además de los rpm y lo deb, que si bien son menos conocidos, existen. En concreto es capaz de tratar los paquetes tipo .tgz (pertenecientes a Slackware), los paquetes .slp (pertenecientes Stampede) y paquetes LSB. La conversión a dichos formatos se realizaría mediante los siguientes parámetros:

• -t: Conversión a formato .tgz.
• --to-slp: Conversión a paquetes .slp.
• -l: Conversión a formato LSB.

Como podéis ver las características de este conversor nos puede permitir transformar paquetes que en un principio no estaban disponibles para nuestras distribuciones, convirtiéndola en una herramienta de un valor incalculable.

Espero que os haya resultado útil.

Saludos.

Preload: Qué es y para qué sirve

En esta ocasión quiero hablaros de uno de los recursos más útiles y usados en el mundo de Linux para mejorar el rendimiento del sistema operativo en general, esta utilidad requiere que pase algo de tiempo para que nosotros notemos alguna diferencia; se trata de la utilidad preload, un paquete de software que monitoriza nuestro sistema y determina qué aplicaciones son las que más usamos, haciendo que éstas se pre-carguen en la memoria RAM para poder usarlas con mayor rapidez. Obviamente el determinar qué es lo más usado requiere que la aplicación lleve instalada un tiempo, con lo que hasta pasados unos días no notaremos ninguna diferencia en el equipo. Esta aplicación es especialmente útil en entornos de escritorio, si bien puede ser perfectamente usada en servidores.

Esta aplicación es un demonio, es decir una aplicación que corre en segundo plano, así que una vez instalada no tendremos que preocuparnos por ella a menos que queramos aplicarle alguna configuración personalizada. Dicho así todo suena fantástico, si bien la preload no está instalado en el sistema... Afortunadamente, la gran mayoría de los repositorios actuales lo incluyen por defecto, así que únicamente tendremos que hacer la instalación desde éstos para tenerlo disponible, lo cual es tan sencillo como escribir en la terminal:

En Debian
apt-get install preload
En Red Hat
yum install preload

En un principio así tendríamos el demonio instalado y operativo, consiguiendo que las aplicaciones más usadas estén pre-cargadas en la RAM. ¿Qué logramos con esto? Qué cuando arranquemos el ordenador, ya tengamos algunos bytes de la memoria RAM cargados en la caché con la información necesaria para cargar dicha aplicación, reduciendo los tiempos de carga en hasta un 50%, pues no tiene que realizar operación alguna para cargar dichos recursos; dicho ahorro en esas tareas conlleva en un gran ahorro de tiempo, cosa especialmente notoria con ciertas aplicaciones "pesadas" tales como libreoffice, que cargan prácticamente al instante gracias a preload. Obviamente existen más aplicaciones en las que se notaría la diferencia; he aquí una pequeña gráfica con algunas comparaciones de antes y después de algunos programas:

Si bien la configuración por defecto de este software es lo suficientemente efectiva como para servirnos en la gran mayoría de los casos, a veces necesitamos un funcionamiento más personalizado; ya sea por que queremos excluir ciertas parte del sistema de dicha monitorización o por que queremos que preload use un máximo de memoria RAM menor al determinado (esto se realiza para evitar que preload use demasiada RAM ). Para personalizar el comportamiento de este demonio, tendremos que recurrir al fichero de configuración /etc/preload.conf.

Este fichero tiene múltiples parámetros configurables que pueden ayudarnos a monitorizar el sistema a nuestro gusto o a ocultar ciertos elementos de dicho "ojo". Los parámetros más importantes serían:

• cycle: Probablemente el parámetro más importante de todos, especifica cada cuantos segundos hace una revisión del sistema. Pasados esos segundos analiza las aplicaciones que están en marcha y evalua si la información cargada en la caché es la adecuada; tras dicho análisis también evalúa qué información es conveniente tener precargada en la caché. El valor por defecto es 20 (el valor establecido estaría en segundos) y los propios desarrolladores advierten que no es recomendable poner un valor demasiado bajo, ya que estaríamos forzando al sistema a hacer revisiones constantes cada muy poco tiempo y podría sobrecargar el sistema operativo con tantos "ciclos" tan seguidos. Una pequeña curiosidad de este parámetro es que siempre tiene que tener asignado un número par.
• minsize: Este valor es muy importante también, pues establece el tamaño MÍNIMO que debe de tener un proceso en ejecución. A cuanto más pequeño sea el valor, mayor será el número de procesos que monitorizará (ya que el requisito para que el proceso sea monitorizado será mucho más laxo). El parámetro está establecido en bytes y por defecto tiene un valor de 2000000.
• autosave: Este parámetro es el encargado de guardar el estado de preload (por si este fuese detenido por cualquier motivo). Al igual que cycle, es recomendable no poner un valor excesivamente bajo, ya que estaríamos haciendo trabajar al equipo con demasiada intensidad. El valor por defecto es de 3600 segundos; es decir de una hora.
• memtotal,memfree y memcached: Aunque son tres parámetros distintos, su correlación hace que sea más útil explicarlos en conjunto que por separado. La combinación de estos tres valores tienen como objetivo evitar que el equipo consuma demasiada ram; es decir evitar que cachee demasiada memoria y deje el equipo sin memoria para hacer el resto de tareas. Los valores usados son desde -100 a 100 y los valores usados por defecto son: -10, 50 y 0 respectivamente. Esto puede sonarnos raro pero significaría lo siguiente: Usa como máximo el 50% de la memoria ram libre menos un 10% de la memoria total (de ahí el -10) más un 0% de la memoria caché en uso. Estos valores por defecto son de por sí lo suficientemente eficientes para evitar que nos quedemos sin memoria, aunque siempre se puede querer ajustar un poco más.
• mapprefix: Los directorios especificados en este parámetro serán excluidos de la monitorización de preload, cosa útil cuando queremos que el contenido de la carpeta en cuestión no se pre-cargue en la memoria RAM. En caso de querer especificar más de un directorio, habría que separarlos mediante el caracter ;.
• exeprefix: Cumple la misma función que mapprefix, con la diferencia de que en este caso se especificarían binarios y no directorios.

Como podéis ver el archivo de configuración es relativamente sencillo de entender y aunque como bien he dicho no es necesario realizar configuración alguna en este para poder disfrutar de esta magnifica utilidad, siempre viene bien conocer lo que la utilidad nos ofrece con el fin de poder personalizarla a nuestro gusto en el futuro.  

Espero que os haya resultado útil.

Saludos.

Lost+found; qué es y qué hacer con él

Aunque los sistemas basados en Linux son muy robutos y estables, como todo son susceptibles de tener problemas cuando hay apagones, cierres del sistema operativo forzosos etc; dejando bloques y/o archivos corruptos. Ya en su momento vimos qué hacer al respecto con fsck, pero a veces no basta con usar dicha herramienta y empezar a usar el PC con normalidad, sino que es necesario rebanarse un poco los sesos debido a que aún con dicha medida nada parece funcionar. Eso es debido a que algunos de los ficheros que han sido recuperados o arreglados han cambiado su ubicación; concretamente se ubican en un directorio muy particular que no existía hasta que se ejecutó el comando fsck. Se trata del directorio lost+found.

Este directorio, alojado en el directorio raíz (/), guarda todos y cada uno de los ficheros restaurados por la utilidad fsck, si bien lo restaurado sigue una nomenclatura diferente a la habitual... Esto se verá claramente tan pronto como hagamos un listado del contenido del directorio como a continuación.

1. ls -la /lost+found/
2. total 368
3. drwxr-xr-x 3 root root   4096 ene 24 10:32 #103805
4. drwxr-xr-x 3 root root   4096 ene 24 10:32 #105488
5. drwxr-xr-x 3 root root   4096 ene 24 10:32 #125836
6. -rw-r--r-- 2 root root   2473 ene 24 16:03 #127864
7. -rw-r--r-- 2 root root  18505 ene 24 16:03 #127865
8. -rw-r--r-- 2 root root  56140 ene 24 16:03 #127866
9. -rw-r--r-- 2 root root  25978 ene 24 16:03 #127867
10. -rw-r--r-- 2 root root  16247 ene 24 16:03 #127868
11. -rw-r--r-- 2 root root 138001 ene 24 17:33 #127869
12. -rw-r--r-- 2 root root  63623 ene 24 17:33 #127870
13. -rw-r--r-- 2 root root  34032 ene 24 17:33 #127871
14. -rw-r--r-- 2 root root   2536 ene 24 17:33 #127872

Si os fijais bien los ficheros mostrados en el listado están compuestos por una # seguido de una serie de números; esos números representan el número de inodo. Un inodo no es nada menos que una estructura de datos que contiene toda la información de un fichero o directorio: estructura, datos, permisos, fecha de creación, etc... Pero entre dichos datos NO se encuentra el nombre. Es por ello que cuando fsck recupera algo, no lo representa con el nombre, sino con el número de inodo, pues es lo que él usa para identificar al archivo. 

En caso de que lo recuperado se trate de un directorio, una de las ventajas que tiene es que si bien el nombre del directorio está representado con su número de inodo, el contenido de éste es mostrado con normalidad, lo cual supone una gran ventaja. En cambio para revisar un archivo no queda otro remedio que jugar con diferentes utilidades para ver qué es o cual es su contenido.  Para ello hay algunos comandos que en mi opinión pueden ser de ayuda. Estos comandos serían:

• file: Probablemente el más útil de todos; muestra el tipo de fichero del archivo en el que se ha ejecutado el comando, lo que ayuda mucho a acotar nuestra búsqueda. Ejemplo:

file #103805

• cat: Al conocer el tipo de fichero, si se trata de un documento o de un fichero de configuración, una de las mejores formas para consultar el contenido del fichero sin editarlo sería mediante cat. Ejemplo:

cat #103805

• exiftool: Una de las mejores formas de conocer un fichero es analizandolo en profundidad ¡y qué mejor para ello que revisar sus metadatos! Exiftool es una herramienta que no está instalada por defecto en el sistema, pero que puede ser instalada mediante apt-get o yum sin problemas. Gracias a esta utilidad podremos revisar y manipular los metadatos a nuestro antojo. Ejemplo:

exiftool #103805

Conociendo exactamente qué es cada inodo, habría que copiar cada uno de éstos a su lugar correspondiente y renombrarlos con sus nombre originales para hacer que todo regrese a la normalidad. Es un proceso que puede resultar tedioso, pero que con las tres herramientas mencionadas puede ser algo más ameno, especialmente cuando podemos estar hablando de decenas o incluso centenares de inodos.

Espero que os haya resultado útil.

Saludos.

Comparación de sistemas de ficheros Linux

Tras unas navidades cargadas de mucho descanso, turrón, cenas y ambiente familiar, vuelvo a la carga con las pilas cargadas para afrontar este nuevo año, que espero que sea como mínimo tan bueno como el anterior. En esta ocasión vengo a estrenar el año con un concepto teórico, pero que es indudablemente interesante conocer: Los sistemas de ficheros.

Una de las virtudes que ofrecen los sistemas Linux, es la libertad que nos ofrecen para hacer prácticamente lo que queramos sin molestas restricciones impuestas por los desarrolladores del sistema operativo. Esta libertad es criticada por algunos, pues hay cosas que no son implantadas por defecto por el sistema, sino que tienen que ser implantadas por nosotros; aún así ese abanico de posibilidades ofrecido estos sistemas también hace que podamos escoger las alternativas que mejor se adapten a nuestros gustos o necesidades. Tal es la libertad que ofrece, que podemos incluso llegar a escoger el sistema de ficheros que deseamos usar; si bien obviamente siempre ofrece un sistema por defecto para aquellos que quieren hacer una instalación rápida o quieren que el sistema operativo simplemente funcione. Generalmente lo ofrecido por defecto por estos sistemas son más que suficientes para satisfacer las necesidades de todos, pero eso no significa que no existan otras alternativas por allí, alternativas que aunque no sean usadas habitualmente, conviene saber que existen y que están allí, disponibles y a la espera de ser usados por cualquier usuario. Es por ello que este post quiere informar un poco sobre estos y esclarecer cualquier posible duda que podamos tener... ¿Cual elegir? ¿Por qué usar esos sistemas de ficheros en vez los de por defecto? Intentaré explicar las opciones presentes y al mismo tiempo evitar aburriros con detalles demasiado técnicos, pues lo importante es tener unas nociones generales.

Extended file system 2/3/4

Los primeros sistemas de ficheros de Linux eran denominados ext2 (Extended fyle system 2), si bien con el tiempo este tipo de sistemas de ficheros fueron evolucionando e incorporando mejoras. Estos sistemas realizan un desgaste muy leve en los sistemas de almacenamiento, especialmente en los discos SSD o memorias USB; además los problemas de velocidad y fragmentación son mucho menores que los que sufre por ejemplo NTFS (el sistema de archivos de Windows). En las versiones dos y tres es posible almacenar ficheros de hasta 2 TB, pero en la última versión, ext4, podían almacenar archivos de hasta 16TB. Ext2 es considerado hoy en día como un sistema de archivos obsoleto, pero debido a que todavía hay algunas máquinas antiguas que lo soportan, ext3 suele ser el sistema de archivos más usado, ya que es compatible con su predecesor. Aún así, es recomendable que a la hora de instalar un sistema operativo nuevo se usará un sistema de archivos ext3 o ext4, ya que la última versión es mucho más rápida que su predecesor y está todavía mejor preparado para evitar la fragmentación.

ButterFS

Aunque ya hablé con bastante profundidad sobre él en este post, reiteraré un par de puntos muy importantes de este sistema de ficheros. El primero es que btrfs, cuyo nombre real es ButterFS o Butter File System, es considerado el sistema de archivos del futuro; es decir que los extended file system dentro de un tiempo se considerarán como alternativas "antiguas". Esto es debido a que este gran sistema de ficheros incluye un funcionalidad muy útil, que se trata de la creación de instantáneas o snapshots del sistema operativo; instantánea que hace una imagen exacta de lo que tenemos en un momento determinado y que podemos hacer que se restaure en cualquier momento, dejando el sistema operativo en el mismo estado en el que estaba cuando realizamos la instantánea, con los mismos ficheros, mismos cambios, etc... que los que teníamos en dicho momento. En resumen, se trataría de una funcionalidad muy parecida las que incorporan los entornos de virtualización de hoy en día, tales como VMWare, Proxmox o VirtualBox. Aunque hoy en día se usa en algunos entornos, no es considerado un sistema de archivos del todo maduro aún, con lo que todavía no es del todo recomendable implantarlo en entornos críticos. Aún así, es muy recomendable probarlo y experimentar y familiarizarse con él, pues seguramente sea muy usado a corto plazo.

Reiserfs

Uno de los sistemas de ficheros menos populares en la actualidad; no por que sea de menor calidad que el resto, sino porque es incompatible con los sistemas más usados en la actualidad: extended file system. Este sistema de ficheros está pensado para trabajar muy rápido con ficheros de pequeño/mediano tamaño, aún cuando haya una gran cantidad de estos en el sistema. La única pega que tiene es que con ficheros muy grandes no es tan eficiente; es más, es considerado lento en ese aspecto. No es un sistema adecuado para un entorno pensado para el almacenamiento de grandes volúmenes de información, pero sí que es una opción interesante para entornos de escritorio o entornos en los que sabe que se van a trabajar con pequeños o medianos ficheros.

XFS

Este sistema es uno de los más antiguos que existen, pero se han ido haciendo constantes mejoras e incluso hoy en día es una opción viable que se contempla que puede sustituir, al igual que btrfs, los extended file system de la actualidad. Este sistema está pensando para trabajar con ficheros de tamaños gigantescos; el máximo teoríco sería de 8 EB, o lo que sería lo mismo 8192 petabytes. Hoy en día no se ha creado nada parecido, y además para sacarle partido a este sistema se necesitaría un hardware equivalente; es decir un hardware de última generación con un muchísimos discos en RAID, clusteres, etc... Es decir que este sistema está especialmente orientado para trabajar con servidores que tengan que trabajar con grandes volúmenes de información. Aunque durante muchos años ha sido casi un desconocido, ha ido ganando popularidad los últimos años y la mayoría de las personas que lo han probado en un entorno de escritorio normal y corriente no han experimentado problemas.


Esto sería todo por hoy; espero que con esto os haya quedado un poco más claro lo que nos puede ofrecer cada sistema de ficheros. Yo personalmente recomiendo probar btrfs, pues más de uno se llevará una grata sorpresa con él; si bien Linux destaca por la libertad de elección y la gama de "sabores" que siempre nos deja elegir, con lo que siempre podemos elegir aquel que más nos apetezca.

Saludos.

Qué Linux usar?

La mayoría de los que optan por probar el mundo de Linux, tan pronto como empiezan a investigar el tema se dan cuenta de que Linux no todo es Ubuntu (sin intención de menospreciar el trabajo de éste) y qué existe un gran número de distribuciones en el mercado, pero... ¿En qué se caracterizan todos éstos? ¿Qué sistema deberíamos elegir? En está decisión influyen en gran parte los gustos y preferencias personales de cada uno, si bien hay algunos puntos que en mi opinión sería interesante tener en cuenta antes de optar por cualquier sistema operativo. Obviamente en este post sería imposible mencionar a todos, si bien intentaré mencionar a los más populares.

Ubuntu

Comencemos con el sistema predilecto por la gran mayoría de la comunidad de Linux: Ubuntu, basado en Debian. El sistema más recomendado para aquellos que desean empezar en este mundo, aunque bien es cierto que hay mucha gente que tras probar este sistema decide no probar ningún otro debido a su gran satisfacción de éste. Querido por muchos, y odiado por otros muchos tambien, es sin duda el sistema más popular basado en Linux y uno de los que más ha dado que hablar debido a sus "arriesgadas" decisiones o a sus intentos de darle un toque más personal a su sistema operativo... No cabe duda que este sistema ha demostrado mucho y seguirá demostrando en el futuro, y además es sin duda uno de los sistemas más intuitivos que nos podemos encontrar en la actualidad... Muchas personas consideran a Ubuntu como el sistema de los principiantes exactamente por ese motivo, pero durante los últimos años ha demostrado que es una opción perfectamente válida para entornos empresariales y tareas "serias", además de ser uno de los sistemas operativos favoritos para las super computadoras.

Otro gran punto a su favor es que tiene una comunidad muy activa y que podemos encontrar una enorme cantidad de información en el foro de la comunidad y en su página oficial, con lo que en caso de tener un problema es muy probable que podamos solucionarlo.

Lo mejor: Muy intuitivo y con mucha información en internet. No requiere tener demasiados conocimientos para manejarlo a nivel de usuario y la gran mayoría del software desarrollado para Linux tiene en cuenta a este sistema, con lo que rara vez nos veremos "excluidos" con los paquetes de software.

Lo peor: A veces, en su intento de tener un toque "personal" y actualizado, Ubuntu ha tomado decisiones que no han gustado del todo a la comunidad; véase su entorno de escritorio propio (Unity) o la decisión de implantar versiones de software/kernel demasiado pronto.

Debian

No podría realizar este post sin mencionara a mi sistema favorito... Debian. En la actualidad podemos encontrar un enorme número de sistemas operativos basados en éste, sistemas que tienen una gran deuda con Debian. Debian destaca por ser el "padre" de una gran variedad de sistemas operativos, entre otros Ubuntu. El auge de éste sistema y sus hijos durante los últimos años ha posicionado al "grupo" de Debian e hijos a la cabeza de los sistemas más usados dentro del mundo de Linux, si bien existen algunas pequeñas, pero significativas diferencias entre Debian y el resto...

La primera diferencia que tiene es que todo el sistema en sí es muy robusto comparado con el resto debido a que todo paquete que instalado en Debian es bastante antiguo y a que hasta que el paquete no se haya demostrado que es "estable", no es implantado en Debian; Esto es bueno y malo al mismo tiempo, pues se posee un sistema muy robusto, pero nunca con las últimas versiones de software/kernel. 

Debian es uno de los pocos sistemas que se caracteriza por instalar lo mínimo indispensable para que el sistema funcione... Esto hace que el sistema tenga instalado únicamente lo que nosotros necesitemos; ahorrándonos molestos paquetes de software que nunca usaremos... Gracias a ésto el sistema requiere de bastante poco espacio mínimo en el disco duro. 

El sistema puede funcionar en equipos de bajas prestaciones sin problemas; es más, en un equipo de 512 MB puede correr un Debian 8 sin demasiadas complicaciones, cosa que muchos otros serían incapaces de conseguir.

Otro de los factores que hacen que Debian sea diferente a la mayoría es que tiene una filosofía de "Libertad" que otros (no todos, pero sí unos cuantos) carecen; ésta filosofía radica en que solo usan drivers "libres" cuyo código puede ser revisado para verificar que efectivamente hacen lo que dicen hacer... Esta decisión hace que el sistema operativo use drivers confiables, pero al mismo tiempo hace que no se tenga acceso a todos los drivers de todos los fabricantes y se tengan que optar por drivers "genéricos" que a veces pueden dar problemas (especialmente los drivers de red).

Lo mejor: Muy robusto y capaz de funcionar en equipos de bajas prestaciones. Además tiene una filosofía que respeta las libertades del usuario. Es el padre de una gran variedad de distribuciones con lo que se sabes defenderte en este sistema operativo, la curva de aprendizaje para desenvolverte en el resto es irrisorio.

Lo peor: Se pueden tener problemas con los drivers, cosa que hará que tengamos que comernos la cabeza en más de una ocasión... Además el sistema rara vez tendrá los paquetes de software más actuales.

Red Hat

El Linux más comercial y orientado a las empresas... Su largo soporte del sistema operativo (7 años) y su estabilidad lo hacen perfecto para las grandes empresas; si a eso le sumamos el hecho de que ofrecen asistencia técnica directa y a que es, con diferencia, el sistema que menos problemas tiene con los drivers, podría decirse que es probablemente el sistema más completo para los servidores, si bien todo esto se paga, y red hat solamente puede ser comprado (sus precios varían en función de las necesidades) o, en caso de querer disfrutarlo gratis, probarlo durante únicamente 30 días... Es innegable reconocer que red hat ofrece soluciones muy completas, aunque hay muchos servidores e incluso super computadoras que funcionan con Ubuntu y que no tienen problemas, todo depende de las necesidades de cada individuo y empresa.

Lo mejor: Muy completo en todos los sentidos. Rara vez habrá problemas de drivers. En caso de tener problemas se puede obtener soporte técnico del propio Red Hat. Ofrecen formación, certificación, etc... También es "padre" de un buen número de distribuciones como Fedora y CentOS.
Lo peor: Es una distribución de pago cuyo coste es bastante elevado. Si no tienes experiencia en Linux (sea la distribución que sea), no es recomendable usarlo.

Fedora

Uno de las principales alternativas a Red Hat y uno de los más usados en entornos de escritorio por aquellos que prefieren usar sistemas basados en éste. Este sistema destaca por tener siempre el software más reciente, cosa que hace que el equipo siempre esté a la última, con sus correspondientes ventajas y desventajas... No siempre lo más nuevo es lo mejor, y es por eso que a veces la implantación de versiones de software demasiado nuevas hace que el usuario final... Aún así desde que Red Hat compró esta compañía/sistema, es necesario reconocer que el sistema es más "estable" de lo que solía ser anteriormente... La gran pega de este sistema es su escaso soporte a las versiones de sistema que saca, pues son 13 meses (lo que viene a decirse prácticamente un año), lo que conlleva a una constante actualización de sistema operativo...

Lo mejor: Ofrece las últimas versiones de software para todo y es el sistema perfecto para adaptarse a los sistemas Red Hat.
Lo peor: Demasiado novedoso con algunos paquetes. El soporte que da a sus versiones es bastante corto.

OpenSuse

Una distribución un tanto diferente del resto basada en Suse... Es uno de los pocos que se han atrevido a "jugar" con btrfs, de la cual han podido sacar el magnifico snapper. No es ni de lejos tan conocido como los que he mencionado anteriormente, aunque bien es cierto que es un sistema muy estable y con cierto toque de distinción del resto... Snapper, Susestudio... Pequeños pero curiosos detalles muy interesantes... Además los paquetes descargados para este sistema son los más fáciles de instalar, aunque he de decir que no hay tantos programas como gustaría. Otro punto a favor es que se instala muy fácil y rápido.

Lo mejor: Facil de instalar y con aplicaciones y funcionalidades muy útiles e interesantes.
Lo peor: No es tan conocido como el resto, lo que puede hacer que probablemente cueste un poco más encontrar documentación en caso de tener problemas... Aún así, poco a poco está ganando popularidad.

Manjaro

Una distribución basada en Arch, podría considerarse como el Arch para dummies que, a diferencia de su "padre" puede ser instalado con facilidad... Comparte las mismas caracteristicas que Arch pero está diseñado para ser más "cercano" al usuario final... Eso significa que comparte prácticamente las mismas ventajas y desventajas que el otro: Es muy robusto y no requiere cambiar de versión pues va actualizandose constantemente... Al igual que Fedora, siempre va la última, con la diferencia de que aquí no hay versiones de sistema operativo sino que siempre es el mismo actualizandose constantemente. Obviamente es un sistema con varias desventajas: La curva de aprendizaje es un poco más dura que la que tiene el resto (en caso de querer recurrir a la consola) y aunque hay mucha documentación en internet de su padre, arch, es la rama de Linux con menos usuarios con diferencia, lo cual convierte al grupo "archer" en el más pequeño de todos y hace que pedir ayuda sea mucho más complicado que con el resto... Esa falta de popularidad también hace que cuente con muchos menos paquetes que el resto.

Lo mejor: Una vez instalado siempre se irá a la última y no requerirá instalar versiones de sistema operativo futuras.
Lo peor: Si se usa este sistema uno debe de concienciarse de que opta por la rama más compleja y menos apoyada de todas.

Estas serían a groso modo las características globales de cada distribución, aunque los gustos personales influyen en gran manera en la decisión de cada uno... Yo actualmente estoy encantado con Debian ¿Y vosotros? ¿Qué distribución usáis?

Saludos.

Machinect shell, el nuevo enemigo de su

Recientemente se ha visto que el creador de systemd, Lennart Poettering, ha vuelto liberado una nueva versión de systemd, en la cual, una vez más, se ha generado cierta polémica. Este programador, el cual trabaja en Red Hat, siempre se ha caracterizado por ser impositivo con sus productos, a veces con razón y otras veces no tanto, pero la verdad es que su última creación, systemd, ha sido con diferencia la más polémica de todas desde su inicio, ya que va en contra de la filosofía de UNIX, en la cual un programa hace una cosa y la tiene que hacer bien. A nivel de usuario final systemd ha supuesto una mejora innegable, pues el tiempo de carga del sistema ha mejorado considerablemente con este nuevo init; el problema radica en que este init otros demasiados servicios además de los del arranque; servicios que en opinión de muchos no deberían ser controlados por systemd... 

Hasta ahora la experiencia general con systemd no ha sido tan ingrata como cabría esperar y a nivel de arranque sí que se ha notado una mejora considerable, y aunque incluye utilidades como systemctl o machinectl que sí que son bastante "intrusivas", con el tiempo la gente ha llegado a aceptar (más o menos) estas funciones. Durante unos cuantos meses las masas se han mantenido en silencio con respecto a este init pero hace poco systemd ha vuelto a hacer de las suyas al ver que Lennart ha estrenado un comando sustituto del archiconocido su... Este sustituto se denomina machinectl shell, y la argumentación liberal de Lennart para añadir esta variante ha sido la siguiente (palabras textuales):

"Long story short: "su" is really a broken concept. It will given you kind of a shell, and it's fine to use it for that, but it's not a full login, and shouldn't be mistaken for one.

THis has come up many times, but nothing really changed, hence closing this now. I understand this is confusing and unexpected, but well, that's UNIX."

En resumen: Su es un concepto "roto" que no genera una shell completa y que ello puede ser resultar confuso, ya que no crea un login completo (aunque dé la sensación de que es así). 

Esto en parte es cierto, ya que al parecer te crea una nueva shell 100% independiente que no tiene relación alguna con las anteriores sesiones... ¿Ahora bien, se trata de un concepto roto? ¿Da lugar a confusiones y/o problemas? Sinceramente, en todos los años que llevo usando Linux no he tenido ningún problema o confusión con sudo ni su ni ningún derivado, y no conozco a nadie que me haya dicho "su es un lío" o "su no está bien hecho"... ¿Así pues, es realmente necesaria esta implantación? De momento la mayoría de las personas, a excepción claro está de los fanáticos de systemd, les parece un comando poco útil que no sustituirá a nuestro querido su, pero hay personas que ven esta implantación como un intento más de "subyugar" a todos los sistemas operativos bajo el systemd de Red Hat. ¿Tendrán razón estos especuladores?  Lo cierto es que este nuevo comando se ve de momento poco necesario...

Yo de momento me quedo con mi compañero su, el cual siempre se ha mantenido fiel y confiable... y vosotros, ¿Qué comando preferís?

Saludos.