Archlinux est-elle en train de se vider un chargeur de AK-47 dans le pied ?

Archlinux se base sur le principe du KISS, en clair la simplicité érigée en règle immuable. Cependant, une annonce sur la liste arch-dev-public a mis le feu aux poudres. Le fichier /etc/rc.conf (colonne vertébrale d’une distribution archlinux) se voit dépouillé de nombre de ses attributs. Au moment où j’écris cet article, le paquet contenant le nouveau /etc/rc.conf est dans le dépot testing.

D’ailleurs, j’ai même exprimé le fond de ma pensée sur la liste arch-general.

Autant dire que cette course à la simplicité entraine une forme de complexité, car au lieu d’un seul fichier, on se retrouve avec 6 fichiers à configurer, en plus du /etc/rc.conf.

Autant dire que cela risque de faire fuir des personnes de bonnes volontés, intéressée par une distribution toujours à jour, vers des distributions plus « connues », comme la Fedora Linux 17 qui me fait franchement de l’oeil.

Cela résume en un éclatement du fichier /etc/rc.conf, qui est réduit à son strict minimum) ; on se retrouve avec :

  • Pour les modules autorisés : /etc/modules-load.d/
  • Pour les modules bloqués : /etc/modprobe.d/blacklist.conf
  • Pour la « linguistique »: /etc/locale.conf (langue) et /etc/vconsole.conf (clavier)
  • Pour le nom de la machine sur le réseau : /etc/hostname
  • Pour le fuseau horaire : /etc/timezone

J’ai réussi à passer mon système avec un /etc/rc.conf monolitique vers cette version « éclatée ». Voici un mode d’emploi, merci VirtualBox pour m’avoir aidé 😉

Voici le /etc/rc.conf d’origine :

#
# /etc/rc.conf – Main Configuration for Arch Linux
#
# See ‘man 5 rc.conf’ for more details
#

# LOCALIZATION
# ————
HARDWARECLOCK= »UTC »
TIMEZONE= »Europe/Paris »
KEYMAP= »fr-latin9″
CONSOLEFONT= »lat9w-16″
CONSOLEMAP=
LOCALE= »fr_FR.UTF-8″
DAEMON_LOCALE= »yes »
USECOLOR= »yes »

# HARDWARE
# ——–
MODULES=(fuse powernow-k8 kvm-amd cpufreq_ondemand microcode vboxdrv vboxnetflt)
USEDMRAID= »no »
USEBTRFS= »no »
USELVM= »no »

# NETWORKING
# ———-
HOSTNAME=fredo-arch

interface=eth0
address=
netmask=
broadcast=
gateway=

NETWORK_PERSIST= »no »

# DAEMONS
# ——-
#
DAEMONS=(syslog-ng !network netfs crond dbus alsa networkmanager cpufreq cupsd ntpd avahi-daemon avahi-dnsconfd gdm)

Et voici la série des fichiers créés pour remplacer le fichier /etc/rc.conf monolithique :

Pour mes modules, j’ai créé un fichier /etc/modules-load.d/vbox.conf contenant les modules virtualbox, et un autre que j’ai appellé /etc/modules-load.d/modules et qui a repris les autres.

#fichier vbox.conf
vboxdrv
vboxnetflt

#fichier modules.conf
fuse
powernow-k8
kvm-amd
cpufreq_ondemand
microcode

Pour la partie linguistique :

#fichier /etc/vconsole.conf
KEYMAP=fr
FONT=lat9w-16
FONT_MAP=8859-1_to_uni

#fichier /etc/locale.conf
LANG=fr_FR.UTF-8

Enfin, pour le réseau et le fuseau horaire :

#fichier /etc/timezone
Europe/Paris

#fichier hostname
fredo-arch

Et voici à quoi ressemble le /etc/rc.conf actuel. Pour info, si on utilise une connexion en dhcp, on peut laisser vide la section « network ».

#
# /etc/rc.conf – Main Configuration for Arch Linux
#
# See ‘rc.conf(5)’ for more details
#

DAEMONS=(syslog-ng !network netfs crond dbus alsa networkmanager cpufreq cupsd ntpd avahi-daemon avahi-dnsconfd gdm)

# Storage
#
# USEDMRAID= »no »
# USEBTRFS= »no »
# USELVM= »no »

# Network
#
# interface=
# address=
# netmask=
# gateway=

Avec l’arrivée de la nouvelle ISO qui est franchement minimaliste – même si on peut passer par une image archboot pour faire une installation plus « poussée » – les personnes s’intéressant à une distribution au format rolling release risque d’être dessus.

Maintenant, restera à savoir si cette course à la simplification extrême ne risque pas de faire des dégats à la communauté archlinuxienne.

14 réflexions sur « Archlinux est-elle en train de se vider un chargeur de AK-47 dans le pied ? »

  1. Ne pas oublier que ce changement est totalement optionnel et la configuration via rc.conf sera maintenue sur le long terme.
    De plus, c’est apparemment nécessaire pour faciliter la transition à System D. Ça risque d’être un sacré bordel, mais j’ai hâte de voir ça 🙂

    1. Totalement optionnel pour le moment. Mais quand le paquet initscripts en question sera dans core, le fichier /etc/rc.conf d’une nouvelle installation sera la version minimale. C’est surtout que dire adieu à la vieille version du /etc/rc.conf qui peut géner, et surtout une configuration un peu plus longue à effectuer.

      Et coté bordel, en ce moment, c’est la loi des série sur archlinux :]

  2. J’ai vu les reactions sur arch-dev-public (merci pour les liens que vous m’avez indiqués hier -p8001, très enrichissants). Je n’ai pas encore testé cette nouvelle iso; je le ferai moi aussi dans VirtualBox, pour voir ce que donne une install par le biais des scripts. C’est vrai que le remplacement à terme de rc.conf par plusieurs fichiers va compliquer la compréhension et la maintenance du système, mais pour certains paramètres (localisation, hostname et interface networking), une fois que c’est réglé on n’a (normalement) pas à revenir dessus. Restent les modules et les daemons. Par contre, la disparition d’AIF risque de décourager de futurs utilisateurs.
    Ce qui me plait dans Archlinux, c’est qu’elle est en rolling-release et donc en constante évolution, avec les risques que cela comporte, et je ne compte pas m’arrêter là. J’ai toujours une Ubuntu en dual-boot pour sa stabilité, mais Archlinux reste mon OS de base. Je n’ai pas l’intention d’en changer pour une Gentoo ou une Fedora ou autre pour l’instant.
    Je ne connais pas encore bien systemd. A voir à l’usage et dans les prochaines évolutions.
    Félicitations pour votre blog, continuez ainsi !

  3. En quoi serai-ce une mauvaise chose ?

    Cela n’a pas l’air si difficile à configurer, de plus au lieu d’un fichier qui gère tout, on passe à plusieurs qui ont une tâche précise à effectuer.

    On gagne en temps quand quelque chose ne vas pas, on pioche la ou c’est nécessaire, pas ailleurs.
    Cela me semble fort simple et agréable.

    Quelles sont tes craintes au juste ?

  4. Salut,
    Je suis à 200% d’accord avec ton avis sur la liste Arch.
    Ton article est intéressant mais fait aussi extrêmement peur. Je ne comprends plus les récents changements, qui sont choisis pour la distrib (Grub déprécié).
    Moi, je n’en veux pas de SystemD. J’ai déjà eu l’occasion de le tester sur deux versions de Fedora (16 & 17), et je trouve pas ça KISS.
    J’espère ne pas être obligé de switcher sur une autre distrib car je suis comme un poisson dans l’eau, sur Arch.
    Sinon, ce sera certainement Slackware…

    1. Grub 0.97 est mort et est abandonné par les codeurs d’origine, remplacé par grub2 au code plus moderne et plus récent.

      Ensuite, libre à chacun de choisir la distribution qui lui convient, mais systemd risque de devenir la norme coté script de démarrage coté distribution linux.

  5. Je trouve cocasse qu’Arch casse sa philosophie de simplicité pour accueillir systemd à bras ouverts… pareil quand j’ai vu qu’ils allaient supprimer leur installeur semi-graphique alors qu’il était très utile.

    Bientôt Arch s’appellera RHFS : RedHat From Scratch 😀
    Oui je sais c’est pas encore Vendredi.

    2. systemd sera la nouvelle norme à terme, que Canonical l’accepte ou pas. AIF est retiré faute de mainteneurs pour le moment. Si tu as le niveau technique, tu es le bienvenu 😉

      Et ce n’est pas la seule distribution a adopté partiellement ou totalement systemd : quid de Frugalware par exemple ?

  6. Je peux me tromper, mais pour moi le principe KISS est plutôt du côté architecture et lien avec l’upstream que du côté simplicité pour l’utilisateur. On n’utilise pas Arch pour avoir une distribution conviviale mais pour avoir une distribution bien faite. Je cite la page officielle:

    « Arch Linux defines simplicity as without unnecessary additions, modifications, or complications, and provides a lightweight UNIX-like base structure that allows an individual user to shape the system according to their own needs. In short: an elegant, minimalist approach. »

    Avoir le hostname dans /etc/hostname par exemple ne me semble pas en contradiction avec ces principes, ni être totalement farfelu.

    En plus, la plupart des paramètres de config en question ne sont faits qu’une fois, à l’installation. En suivant le wiki, qu’on ait à éditer un fichier ou plusieurs, ça ne change rien. Personnellement la seule chose que je modifie de temps en temps, c’est la liste des modules à lancer, et que ce soit dans rc.conf ou dans un fichier dans modules-load.d, honnêtement je ne vois pas trop le problème.

    Bref, la réaction est me semble-t-il disproportionnée par rapport aux changements.

    1. Avoir le hostname dans /etc/hostname par exemple ne me semble pas en contradiction avec ces principes, ni être totalement farfelu.

      Entièrement d’accord.

      En plus, la plupart des paramètres de config en question ne sont faits qu’une fois, à l’installation. En suivant le wiki, qu’on ait à éditer un fichier ou plusieurs, ça ne change rien.

      Vraiment ? Désolé, mais éditer 5 ou 6 fichiers au lieu d’un seul, c’est légèrement plus long.

      Ce qui est « ennuyeux », c’est l’éclatement poussé du fichier unique précédent.

      Personnellement la seule chose que je modifie de temps en temps, c’est la liste des modules à lancer, et que ce soit dans rc.conf ou dans un fichier dans modules-load.d, honnêtement je ne vois pas trop le problème.

      Je fais de même, avec parfois la ligne daemon.

      Cependant, l’ancienne approche était plus « simpliste », et moins fragmentée. Enfin, en ce qui concerne la réaction excessive, je serais plutôt dans les modérés cette fois.

Les commentaires sont fermés.