Definamos Normal.

El Blog personal de Rafael Rojas

Category: ArchLinux (page 2 of 5)

Distro vs Fork: lo que nunca debe suceder.

Esta entrada me interesa, sobre todo por que es un claro ejemplo de como una comunidad NO se debe comportar.

Allan McRae es uno de los principales developers y mantenedores de ArchLinux, para darle contexto es el que mantiene pacman, glibc, gcc, makepkg y otras herramientas del repositorio core de ArchLinux. Allan un dia en su blog personal (cabe aclarar que es su sitio personal y no un lugar oficial de ArchLinux) escribió una comparativa de los forks (o derivaciones) de ArchLinux

Para no hacer el cuento largo: a la mayoría de los forks les fue mal, con observaciones de Allan de que no entendia porque separaban los repositorios o porque manejaban de cierta forma las actualizaciones. La única que medio salio librada fue Chakra, sobre todo por que esta, a pesar de usar las herramientas de ArchLinux recompila sus paquetes y administra sus actualizaciones.

——————Hasta aqui todo bien ————————————————–

Fuera que unos días después el mismo Allan se clava/especifica en un fork en particular: manjaro.

Con el titulo: “Manjaro Linux: Ignoring Security For Stability” (Manjaro Linux: ignorando seguridad por estabilidad), señala varios puntos que no logra entenderla administración de paquetes de manjaro ya que esta actualiza sus repositorios desde core o extra a diario, pero en vez de moverlos a sus repos estables los mueve a su propio repo de testing, sin razon aparente los deja ahi una semana y luego los libera a sus repositorios, divididos en su propia organización, también sin supuesta explicación alguna: los puntos de McRae fueron:

Porque moverlos a testing, si en realidad no hacen muchas pruebas con los paquetes en base a que tienen solo 3 mantenedores para testear y mantener lo que va a su repositorio core?
El mantener tanto los paquetes puede causar problemas de seguridad por que una distro rolling release puede sacar parches al dia de un paquete, en una semana pueden haber varias revisiones de seguridad de un paquete, y estas actualizaciones no les llega a los usuarios de manjaro mas que semanalmente, de ejemplo utilizo el paquete de Firefox (algo interesante) cuyas vulnerabilidades de la ultima semana fueron abatidas al paso.

Y hasta ahi. Una critica constructiva, basada en ejemplos de aplicación reales y con los puntos bien aclarados del porque esto puede ser una mala idea, Allan McRae se descargo de manjaro, cabe aclarar como termino ese dichoso post:

In the end, I think the idea behind Manjaro – rolling release at a more relaxed pace – can be achieved. I am not entirely familiar with these distributions, but I guess that is exactly what apotsid and LMDE achieve. And they start form Debian Unstable, which is reportedly far more of a minefield than Arch Linux.

Traducción: al final de todo esto, si creo que la idea detrás de Manjaro es plausible.

Reaccionaron bien los developers oficiales de manjaro o los miembros de su comunidad? no, para nada.

Primero revisar los primeros 5 comentarios de su post en su blog personal, uno de ellos por uno de los mantenedores de manjaro 😀
Seguido de varios temas en los foros de manjaro hablando de una supuesta guerra Arch vs Manjaro (cosa que no existió).
Y por ultimo como Allan menciona: el mover paquetes intespestivamente en base a su critica.

Ahora le toco a Allan ser reactivo, al dia siguiente postea otra nota haciendo una dura critica al hecho de que manjaro haya publicado en estable un paquete de idiomas de firefox que tenia un bug reportado señalando de sobremanera que este tipo de administracion de paquetes puede traer en un futuro problemas de seguridad para los usuarios.

Allan tambien se dijo hasta amenazado por la comunidad de manjaro (post borrado) y demas lloriqueos.

La reacción de la comunidad oficial, del sitio oficial de manjaro hacia los posts del blog personal de Allan McRae fue:

I’ve deleted the thread about Allan McRae’s criticism of Manjaro.

En resumen

Fue duro McRae en sus criticas? si lo fue, pero lo hizo basado en argumentos, en vez de declararlo troll y juzgarlo como Manjaro-hater por que no debatir sus argumentos con hechos?
El señor odia a Manjaro? no creo, aclaro que la idea detras del proyecto no es mala para nada.
Se porto como un troll? hizo algo para alimentar este pleito? si lo hizo, es de admitir que lo hizo, aunque es de admitir que lo hizo en su blgo- y espacio personal, hay que decir que fue medio troll
La comunidad de Manjaro es victima? no lo es
Esta comunidad actuo como deberia? No, un par de cometarios en su blog o tal vez una aclaracion en su wiki o ducomentacion hubiera sido suficiente, no seguir el juego ni de MacRae ni de los fanboys de ambas distros.
Necesitan reparar o aclarar los errores señalados? si, cuanto antes mejor.
Deben tomar tan a pecho la opinion de MacRae? tan a pecho no, pero considerarla si, sobre todo por el hecho de que es el mantenedor de muchos de los paquetes basicos de Manjaro, es mas mantenedor de Manjaro que sus 3 administradores de core juntos.

Hay actitudes y comportamientos que destruyen mas que todas las criticas externas y patentes juntas, la comunidad se destruye de adentro hacia afuera no de afuera hacia adentro. Coincido con los puntos del primer post del Sr McRae: la administracion de paquetes es confusa pero no coincido y repruebo su forma de afrontar el problema con los de Manjaro. Coincido en que la comunida de manjaro tiene derecho a administrar su fork como se le de la gana, pero no coincido que se vuelvan tan infantiles ante una critica: criticas van a tener, y si quieren llegar a algun lado deben saber afrontarlas (eso o empezar a mantener sus propios paquetes y poder prescindir de las criticas de McRae).

Muy mal para ambas partes

El arte de bloguear sobre ArchLinux

ArchLinux es una de las distribuciones de GNU/Linux mejor documentadas, su wiki se ha comparado a la wiki de otros proyectos como Gentoo en cuanto a contenido, orden y nivel de actualización, incluso usada mucho por usuarios de otras distros por su forma de explicar los procedimientos de instalación y configuración de software.

Por el otro lado sus foros oficiales (tanto en ingles como español) estan perfectamente administrados, las preguntas se redireccionan y se responden rápidamente (casi siempre con una liga al documento de la wiki que responde esa pregunta), los codigos de conducta y de uso estan bien claros y eso hace que sus foros esten casi limpios de posts basura y preguntas innecesarias.

Finalmente quedan los canales IRC oficiales de ArchLinux (tambien con exelente conducta) el feed RSS de noticias y el planet de usuarios de Archlinux, todos canales oficiales con noticias y guias de la distro en cuestion.

Entonces llega la pregunta del millon:

Para que bloguear sobre la instalacion/configuracion de X software si la wiki oficial ya lo tiene explicado de manera clara y detallada? Sirve realmente de algo repetir la misma informacion?

Mi respuesta corta y sencilla: no.

Y es por eso que muchos usuarios de ArchLinux que tienen blogs no gastan su tiempo explicando instalaciones y configuraciones, de eso me di cuenta hace un rato y en vez de copiar-pegar contenido ya hecho para generar trafico en mi sitio, preferí optar por señalar el camino a la documentacion oficial cada vez que un usuario me preguntaba algo sobre esta distro.

Y no me muerdo la lengua (o los dedos en este caso), este sitio contiene varios de los mencionados recetarios (con varios de los pecados antes mencionados cometidos). Dudo que me queden ganas de volver a hacerlo, solamente mantendré las pocas guias posteadas aquí, sobre todo la de instalacion, durante un tiempo mas hasta que sean innecesarias o irrelevantes cumpliendo asi una regla básica de los blogs con guías/tutorarles: la información caduca.

Pero todavía se puede bloguear sobre Arch.

Se puede tener un blog con temática linuxera sin tener que postear recetarios. Son muchas cosas las que suceden alrededor de esta distro, muchísimas noticias, muchos cambios nuevos o no documentados, muchas optimizaciones y personalizaciones con las cuales jugar y como usuarios muchas experiencias personales y soluciones a pequeños problemas que pueden ayudar a alguien mas. Es dificil tener un blog sobre ArchLinux, pero no imposible.

Si tienen una mejor forma de hacer las cosas: actualicen la wiki, el dejar los nuevos métodos en un blog condena la información a perderse en el internet, la wiki da permanencia.

Si de todos modos quisieran postear sus fantabulosas guias de instalacion pues esta bien, cada quien. Un consejo: dejen una liga a la guia oficial de donde sacaron esa información, sean lo mas explicito posibles, avisen de la posible caducidad de la información o mejor aun: mantengala actualizada.

Yo por mi parte seguire siendo Archero, este seguira siendo mi blog personal, seguira siendo un sitio Archero con algunas experiencias personales, y espero que mis tres fieles lectores no se sientan agredidos por mi falta de disposicion para repetir la informacion la posteada.

wiki.archlinux.org es tu amigo.

Benchmark de herramientas para AUR

AUR es el repositorio de usuarios de archlinux donde todos podemos subir un pkgbuild para compilar/instalar/administrar algun paquete de software no soportado oficialmente por la distribucion. El detalle de AUR es que no cuenta con una herramienta oficial para su manejo (asi es, yaourt no es oficial) y los usuarios tenian que ir hasta la pagina de AUR para descargar sus pkgbuilds y tener una administracion a mano.

Despues empezaron a salir muchos scripts, en principio sencillos, que ayudaban al usuario a conectarse al repositorio de AUR y descargar y aplicar estos pkgbuilds, en ingles se llaman AUR Helpers, en español son herramientas para AUR, y eso es lo que es yaourt, packer, aurget y demas.

Hay un monton de herramientas para AUR listadas en la wiki de ArchLinux, muchas muy basicas, otras todavia en desarrollo, unas totalmente abandonadas y todas generalmente hacen mas o menos lo mismo de forma ligeramente diferente. Pero, que pasa si nos ponemos a testear estas herramientas?.

El test, que no esta hecho meramente por procedimiento cientifico, hecho por el usuario monoloco de los foros de ArchLinux nos muestra los resultados de varias pruebas a esta herramienta utilizando el mismo criterio de busqueda y de instalacion: un paquete de python, los resultados:

En orden de velocidad, medida en segundos, de mas rapido a menos rapido

yaourt                 6.365
packer     (A)         6.587
meat       (A)         7.506
pacaur                 7.585
cower      (A)         8.073
spinach                8.786
packer                16.385
aura       (A)        19.426
packer     (A)        19.859
aurget     (A)        20.805
aurora     (A)        21.335
owl        (A)        23.367
owl                   27.197
paktahn               28.349
pbfetch              1:09.67
pbfetch    (A)       1:09.72
PKGBUILDer (A)       1:49.46

El termino (A) indica que la herramienta solamente maneja paquetes de AUR y no de repositorios (no es ayudante de pacman)

En orden de uso de CPU (de menor a mayor)

packer     (A)           0.8%
cower      (A)           1.4%
meat       (A)           1.6%
pacaur     (A)           2.0%
aura       (A)           2.6%
pacaur                   3.2%
spinach                  3.2%
packer                   3.2%
yaourt                   4.6%
aurget     (A)           5.2%
owl                     16.2%
owl        (A)          16.4%
paktahn                 28.2%
aurora     (A)          34.0%
pbfetch    (A)          34.8%
pbfetch                 35.2%
PKGBUILDer (A)          88.8%

Interesante dato a tomar en cuenta si queremos afinar tan a detalle el consumo de recursos de el sistema. hay que aclarar que estos datos son de busqueda de paquetesy tiempo de respuesta, el tiempo de compilacion depende absolutamente de la capacidad de hardware de el equipo.

Si quieren leer la nota original aqui esta el tema en los foros de archlinux.

Ha muerto initscripts, larga vida a initscripts

Bueno tan asi como mueto no, pero se anuncia el fin del soporte de initscripts.

Con el anuncio hace unas semanas de la inclusion de systemd como default en las nuevas instalaciones y consolekit siendo remplazado por logind (una implementacion que es utilizado como un modulo de systemd) esta noticia no es tan sorprendente y solo es parte de la transicion completa que esta haciendo ArchLinux a este gestor de aranque/administrador de recursos.

La nota de Tom Gundersen dice que a vista de que se esta haciendo una migracion a systemd, se esta haciendo poco o nulo testing con los initscripts asi que los bugs y/o peticiones sobe initscripts seran marcados como WONTFIX o “no resolvibles”.

Tambien anuncia que para enero del año entrante es probable que eliminen por completo initscripts y todos los demonios de rc.d de los paquetes para terminar con esta transicion.

¿Todavia no migras a systemd? la wiki oficial de ArchLinux tiene una guia muy completa sobre como hacer esta migracion aqui.

Recuerden: para este tipo de cosas, algo delicadas y con mucho detalle siempre es mejor la wiki oficial.

Nueva ISO de instalacion, incluye Systemd para la imagen Live

La liberación de la nueva imagen de instalación de ArchLinux se acerca mas a el cambio completo a systemd. Utiliza systemd para cargar el sistema live, aunque para la instalación de inicial del sistema base sigue usando initscripts, y al parecer esto va a cambiar en un futuro próximo, así que ya saben: a cambiar a systemd.

Les recomiendo leer las notas de esta iso en la pagina de ArchiLinux, aqui

NOTA: una nueva ISO de instalación no significa que tengan que reinstalar todo el sistema completo otra vez, esta ISO es útil solamente para quienes instalen sistemas nuevos, nuestro sistema ya instalado ya cuenta con todas las características que esta ISO pueda ofrecer.

ArchLinux en LVM

Entre los comentarios habia quedado pendiente la instalacion de ArchLinux en un sistema de discos LVM, como habia quedado en hacerlo aqui esta. Nota: para efectos de este ṕost supongo que saben que es LVM, como instalar archlinux, como particionar y como editar archivos como minimo. Para motivos del ejemplo utilizare una maquina virtual con un disco virtual de 20 GB particionado de la siguiente forma:

Las particiones o discos que vamos a utilizar para LVM deben de ser tipo LVM para poder crear un filesystem sobre ellos mas adelante. Este particionado se puede hacer facilmente con cfdisk, en donde:

  • sda1 es tipo partición lógica de 256 MB de tamaño al inicio de tipo de Linux
  • sda2 es tipo partición lógica de 256 MB de tamaño al inicio de tipo Linux SWAP
  • sda5 es tipo partición extendida de 5 GB de tamaño al inicio de tipo Linux LVM
  • sda6 es tipo partición extendida de 5 GB de tamaño al inicio de tipo Linux LVM
  • sda7 es tipo partición extendida de 5 GB de tamaño al inicio de tipo Linux LVM
  • sda8 es tipo partición extendida de 5 GB de tamaño al inicio de tipo Linux LVM

iniciamos el modulo necesario para manejar LVM:

modprobe dm-mod

Creamos los volumenes fisicos

pvcreate /dev/sda5
pvcreate /dev/sda6
pvcreate /dev/sda7
pvcreate /dev/sda8

Este comando crea una cabecera en cada particion para que pueda ser utilizada por LVM, podempos listar los volumenes fisicos asi: Continue reading

ArchLinux + KDE en la Netbook

Vamos a descansar un poco de los temas de systemd, ¿vale?

Sucede que hace unos años le compre a mi esposa una netbook para que la usara para su escuela y dejara de quejarse que “mi linux” no tenia una suite de oficina” donde pudiera trabajar 😀

Una Dell Inspirion Mini 1012 con un procesador Intel(R) Atom(TM) CPU N450 @ 1.66GHz 1GB de RAM (que expandi a 2GB), grafica intel 965 y 200 GB de disco duro.

Ah, y para su escuela le quite el infame windows XP que traia y le meti ubuntu 8.10 (de aquella epoca) junto con openoffice creo, le sirvio de maravilla.

Bien, ahora acabo su carrera y la netbook paso a ser objeto de mis experimentos, con la nocion de que ya conozco entornos ligeros como openbox, LXDE o XFCE y que la netbook ha pasado por ubuntu + unity, fedora y arch con distintos escritorios, me dispuse a probar Arch + KDE, el resultado?

Y que hice? Continue reading

Noticia: ArchLinux se movera definitivamente a systemd

Como lo venia mencionando desde hace tiempo: los cambios recientes en la configuracion de ArchLinux eran para darle cabida a systemd, tambien habia comentado que ese iba a ser un cambio a corto plazo.

Pues el plazo es mas corto de lo que parece.

Via Google Plus (si, hay gente que utiliza G+) me entero por la cuenta de ArchLinux que la discusion en las listas de correo de Arch llego al punto de ya hacer la migracion definitiva:

Systemd has a overall better design than SysV, lots of useful administrative features and provide quicker boot up. Considering that it has been around in our repositories for some time and that it could be considered stable enough for production use, I would suggest to replace iniscript by systemd once the ‘Missing systemd units’ is over. Thus we will avoid duplicating our efforts on two init systems.

Any objections to start the migration process ?

Cheers,

Stéphane

A lo cual las respuestas de esta propuesta han sido aprovatorias y de acuerdo con el cambio. Para cuando el cambio? para cuando los detalles de algunos conflictos con las unidades de systemd sean portadas a Arch (cosa de un par de semanas a lo sumo).

Tambien supone la eliminacion de los initscripts, aunque hay developers que lo quieren seguir manteniendo como legacy bajo la suposición de que sera innecesario en un futuro cuando todos los servicios requieran de systemd para funcionar.

Bienvenido sea el cambio entonces!

De netcfg y otros demonios (figurativamente)

Siguiendo con la epoca de grandes cambios en la configuración y citando (otra vez a Allan McRae: “Being on the bleeding edge is not much fun without the occasional cut” este sábado pasado se anuncio el cambio de configuración de netcfg sacandolo del /etc/rc.conf a /etc/conf.d/netcfg

Netcfg, para quien no ha oído hablar de el, es una herramienta de configuración de red utilizando perfiles de red, es una herramienta de linea de comandos para manejar distintas redes, perfiles de red o interfaces de red, si usan Network o NetworkManager esto no los afecta en absoluto.

Tal parece ser (a mi muy personal opinion) que el cambio de initscripts a systemd se convertira en un hecho en el cercano futuro, como se aclaro en los foros de ArchLinux.org esto no significa que los usuarios con initscripts tengan que forzosamente cambiar a systemd dado a que se va a mantener ese soporte por algun tiempo, solo que systemd seria el gestor de inicio y de sistema por default en las nuevas instalaciones y con opcion a actualizar los sistemas ya instalados.

En otras notas recomiendo mucho la entrada en el blog de Alla McRae sobre que es lo que realmente define a ArchLinux en estos tiempos de cambios (lectura en ingles)

La semana pasada, por estar incapacitado en descanso y reposo obligatorio inicie una pequeña idea que tenia en mente: SI AIF ya fue abandonado ¿por que no actualizarlo? despues de un par de dias modificando el instalador AIF me desespere un poco por que es realmente un desastre de instalador, asi que hice lo que naturalemnte todo linuxero con algo de tiempo en las manos haria: hacer mi propio instalador 😉

No es mas que bash scripts con menus hechos en dialog y es un trabajo en progreso: Continue reading

Aclarando un poquito

Dificilmente encontraremos usuarios de Arch donde ArchLinux haya sido la primera distro de GNU/Linux que hayan utilizado. Siempre he pensado de esta distro como algo en lo que te adentras con previo conocimiento de causa de algunos fundamentos basicos de que es y como manejar una distro de Linux.

 

En este ultimo año ha habido mucho mas usuarios que se han metido a ArchLinux (y eso en cierto modo es genial), yo lo justifico con las decisiones poco populares de algunas otras distros o la creciente buena reputación que se estaba haciendo de Arch, cualquier razon que haya sido da igual. Pero el problema de esto es que muchos de estos usuarios llegaban con una idea erronea de ArchLinux, no entienden aun la filosofía KISS de ella, no entienden el teje y maneje de la comunidad, critican los cambios tan frecuentes y fuertes de la distro sin entender que eso es parte de la naturaleza de Arch.

Ultimamente he leido comentarios de gente realmente enojada con Arch por los recientes cambios, siendo que dichos cambios son mejoras incrementales perfectamente documentadas en la wiki y en el boletin de noticias del sitio oficial de ArchLinux y en sitios como este. Y ese es el problema: muchos usuarios venidos de otras distros, acostumbrados a otros modos, creen que aqui es igual: que aqui se va a liberar un metapaquete que les hara todos los cambios de manera automatica, y no es asi.

Ubuntu y Fedora son excelentes distros, ambas se preocupan de dejarle al usuario un sistema al 100% funcional y con los cambios mas recientes, si hay algun problema retienen la version de la distro hasta que se soluciona. Rara vez el usuario tiene que meterle mano al sistema a menos que asi lo desee para algo especifico. En Arch es lo contrario:

Arch Linux se fija y toma en cuenta a los usuarios GNU/Linux dándole total, y solo total, control sobre todo el sistema.

Tomado de la wiki de ArchLinux sobre la filosofia de arch (lectura recomendable por cierto).

Y todo se puede resumir a eso: Arch le da el control y responsabilidad al usuario, incluso del romper el sistema.

Añadido a eso hay algo que los nuevos usuarios de Arch deben entender: esta distro no concursa por popularidad. lleva 10 años siendo asi y seguira siendo asi incluso en epocas cuando Arch se vuelva el “sabor Linux favorito de la semana”. No se trata de alejarlos, ni de tratarlos con soberbia, simplemente si la comunidad y la documentacion de Arch ha sido tan admirada por su contenido y limpieza es por que los usuarios seguimos estos lineamientos.

Si tienes un problema:

  • Revisa si el problema no es por una mala instalacion o un paquete desactualizado
  1. Revisa los mensajes de error del programa, ahi estara el detalle.
  2. Antes de preguntar algo lee la wiki (RTFM). Si te mandamos a leer la wiki es porque los archeros hemos pasado mucho tiempo actualizando y documentando todo, ahi esta para que lo uses.
  3. Si aun asi no encuentras respuesta revisa en los foros o sitios a ver si alguien no tuvo el mismo problema y le fue resuelto
  • Lee el codigo de etica de los foros
  • Aprende a solucionar tus propios problemas
  • Si al hacer pacman -Syu te aparece un mensaje, cualquiera. Revisa archlinux.org por posibles cambios de paquetes y configuraciones.
  • No te quejes de los cambios, Arch es Rolling Release, el cambio es parte de su naturaleza.
  • SI no te convence todo o alguno de los puntos anteriores, tal vez Arch no sea para ti realmente, no te preocupes, hay muchas otras distros geniales de donde escoger.

..y lee la wiki!

Older posts Newer posts

© 2019 Definamos Normal.

Theme by Anders NorenUp ↑