Journal Arch et le tournant

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
43
24
juil.
2012

Comme beaucoup d'entre-vous, je suis avec un peu d'inquiétude l'évolution de nos systèmes d'exploitations. Jusqu'alors, je regardais les évolutions récentes de loin, et me rassurais en me disant que ce n'était pas prêt d'arriver près de chez moi.

Mais les mauvais signes se rapprochent, et j'ai l'impression de n'avoir plus que quelques semaines de quiétude. Les signes les voici:

Grub n'est plus.

Ça y-est, l'ancestral Grub n'est plus. Arch annonce passer à Grub2. Certains s'en réjouiront, mais pas moi. Le nouveau Grub me semble aussi confus que la page du wiki qui lui est consacrée. Foison d'exceptions, syntaxe absconse, fichiers binaires.

On peut apprécier l'amélioration des performances, l'étendue du matériel supporté, les kikoololeries en tous genre maintenant possibles. Mais la vision de l'informatique que me propose Grub2 n'est pas la mienne. Le nouveau Grub, c'est l'obfuscation imposée au nom de la performance technique. Je cherche tout le contraire, la transparence, même au prix d'inconvénients techniques.

Bref, sur Arch, j'utiliserai lilo.

rc.conf est enterré vivant

Ça y est, on tire à bout portant sur /etc/rc.conf, le fichier de configuration de ce qu'était Arch linux. Il est malade depuis un bout de temps. Cela a commencé insidieusement. Une variable a été supprimée, remplacée par un fichier de configuration indépendant. Puis une autre, et encore une autre, et ainsi de suite jusqu'à ce qu'il ne reste là-dedans que quelques lignes, comme en guise de souvenir.

Ce mois-ci, on nous explique que le fichier peut être totalement vidé sans que cela n'affecte Arch. Ceux qui veulent continuer à l'utiliser pourront le faire, mais il est conseillé d'utiliser les fichiers de configurations ad-hoc.

Mais le sujet est si sensible, qu'il faut que quelqu'un dise que ce changement ne change rien. Admirez cette façon de ne pas dire qu'rc.conf est enterré:

I think Tom has done a good job in documenting the best practise and
also supporting the old syntax (which is not "broken" in any way, but
limited…). Allan

On peut se réjouir de voir ainsi l'inter-opérabilité-dans-son-coin-de-linuxien s'améliorer. Mais l'inter-opérable se fait au prix du simplement opérable. L'opérateur c'est moi, et j'étais fort satisfait de ce fichier de configuration centralisé qui me faisait dire que l'informatique bien faite est simple et claire.

Bref, sur Arch, j'utiliserai une configuration dépréciée.

L'init BSD se meurt

Le cavalier et la dame étant hors jeu, le roi peut craindre pour sa vie. Voici la suite du message d'Allan, et ce n'est qu'un message parmi d'autres ayant le même sens:

I have not moved to using the separate configuration files
(and probably will not until we officially move to systemd or I do a new
install) and everything seems to work.

Bref, sur Arch, jutiliserai un init qui n'existera plus.

Arch is dead

Arch linux c'était cette étrange alchimie entre une rolling release apportant aux utilisateurs les paquets les plus récents, et un fonctionnement old school, avec son init BSD, son gestionnaire de paquet en ligne de commande, et l'emphase mise sur l'édition de fichiers de configurations.

On peut certes enlever le moitié de Arch linux et faire un système d'exploitation performant. Mais alors, il faut aussi penser que les utilisateurs suivront la moitié qui leur plaît le plus.

C'est difficile de ne pas nourrir les trolls à propos du tournant que suivent les uns après les autres nos systèmes d'exploitation. Savoir si c'est mieux ou moins bien n'est pas vraiment la question. La question est plutôt de savoir où iront ceux qui trouvent que c'est moins bien.

  • # Grub2 vs Grub1 : Quel est le problème ?

    Posté par  (site web personnel) . Évalué à 10.

    Adepte inconditionnel de grub1, et notamment du mini-shell que l'on a en pré-boot avant le chargement des OS, je dois avouer que j'ai vu son arrivée il y plus de 2 ans, sur Debian Testing, avec une certains crainte.

    Mais franchement, il n'y a pas de quoi faire un plat.

    La syntaxe du grub.cfg est différente du menu.lst ? La belle affaire, ce n'est qu'une syntaxe.

    Réinstallation de grub from scratch, notamment après des manips "foireuse" du genre effacement du MBR par un Windows fraichement installé ?

    Il y a plusieurs méthodes:
    - la technique "old school" : copier-coller d'un /boot/grub venant d'une autre machine, et lancement d'un "grub-install /dev/sdxx". Quand au /boot/grub/grub.cfg, il s'édite à la main sans problème

    • la méthode "dans les règle de l'art" (les commandes sont pour une Debian/Ubuntu)
      • boot sur un live CD
      • montage du "/" defectueux en /mnt/casse
      • montage en bind des répertoires système: mount -o bind /dev /mnt/casse/dev mount -o bind /proc /mnt/casse/proc mount -o bind /sys /mnt/casse/sys
      • chroot: chroot /mnt/casse
      • restauration du mbr, création du /boot/grub/grub.cfg update-grub dpkg-reconfigure grub-pc
      • démontage des "bind" et de la partition
      • reboot sur le disque dur

    Enfin, grub2 permet des trucs réellement sympa, comme le boot à travers une image ISO, sans avoir besoin de la décomprésser (*). C'est idéal pour avoir plusieurs distribs linux sur une même clé USB. Il suffit simplement de copier/coller l'image iso, en temps que fichier simple.

    (*): Exemple pour de l'Ubuntu:
    menuentry "Ubuntu 11.10 - Desktop - i386" {
    insmod ext2
    insmod loopback
    insmod iso9660
    set isofile="/iso/ubuntu-11.10-desktop-i386.iso"
    loopback loop $isofile
    linux (loop)/casper/vmlinuz locale=fr_FR bootkbd=fr console-setup/layoutcode=fr iso-scan/filename=$isofile boot=casper file=/cdrom/preseed/ubuntu.seed noprompt quiet splash --
    initrd (loop)/casper/initrd.lz
    }

    Bref, grub2 c'est bon !

    • [^] # Re: Grub2 vs Grub1 : Quel est le problème ?

      Posté par  . Évalué à 6. Dernière modification le 25 juillet 2012 à 00:07.

      Le problème c’est l’inutilité total des features de GRUB2 dans 99% des cas. Le problème c’est que GRUB1 fonctionnait encore très bien, ça ne servait à rien de le virer totalement des dépôts pour faire chier ceux qui l’utilisent encore.

      J’ai toujours reprocher à Debian de ne pas laisser l’utilisateur tranquille, de toujours forcer la main sur tout (« tiens, et si je patchais à mort ? », « tiens, et si je lançais le daemon que tu es en train d’installer avant même que tu n’ai pu le configurer », etc.) et je me rends compte qu’Arch prend le même chemin.

      Je suis un putain de fan de cette distro, j’en ai trouvé aucune capable de la remplacer et pourtant, ses développeurs me déçoivent de plus en plus.


      Pour info, mon fichier de conf de GRUB :

      (root) |> ~ <| < /boot/grub/menu.lst 
      #
      # /boot/grub/menu.lst
      #
      
      timeout 0
      default 0
      hiddenmenu
      
      title   Arch Linux
      root    (hd0,0)
      kernel  /boot/vmlinuz-linux root=/dev/sda1 ro
      initrd  /boot/initramfs-linux.img
      
      # End Of File
      
      

      Il fait ce qu’on lui demande : il boot un OS sans ouvrir sa gueule. Il fait exactement comme le bootloader de Mac, Windows, FreeBSD et OpenBSD (c’est les seuls autres OS que je connais).

      • [^] # Re: Grub2 vs Grub1 : Quel est le problème ?

        Posté par  . Évalué à 1.

        Je ne sais pas comment c'est avec les autres distros (et j'ai la flemme de chercher…) mais sous arch, il suffit d'éditer le fichier /etc/default/grub et de lancer par la suite grub-mkconfig -o /boot/grub/grub.cfg pour générer le fichier grub.cfg.

        Et chez moi ça se limite à :
        GRUB_DEFAULT=0
        GRUB_TIMEOUT=2
        GRUB_DISTRIBUTOR="Arch Linux"
        GRUB_CMDLINE_LINUX_DEFAULT="verbose init=/bin/systemd"
        GRUB_PRELOAD_MODULES="part_gpt part_msdos"
        GRUB_GFXMODE=auto

        Donc niveau simplicité…

        • [^] # Re: Grub2 vs Grub1 : Quel est le problème ?

          Posté par  . Évalué à 3.

          Faut quand même aussi éditer les fichiers "modèles" dans /etc/grub.d pour faire certaines choses.

          Mais je suis d'accord, GRUB 2 c'est bien. D'ailleurs je ne comprends pas :

          Foison d'exceptions, syntaxe absconse, fichiers binaires.

          Gni ?!

        • [^] # Re: Grub2 vs Grub1 : Quel est le problème ?

          Posté par  (site web personnel) . Évalué à 1.

          Sous Debian, c'est pareil. Le même fichier de conf au même endroit (/etc/default/grub) mais la commande est "update-grub".

          Contrairement à la modif du grub.cfg à la main (toujours possible), ça permet de garder une config de grub cohérente (tenant compte des modifs de l'utilisateur), même en cas de changement/mise à jour de noyau (qui passera par un update-grub).

          There is no spoon...

          • [^] # Re: Grub2 vs Grub1 : Quel est le problème ?

            Posté par  . Évalué à 4.

            Sous Debian, c'est pareil. Le même fichier de conf au même endroit (/etc/default/grub) mais la commande est "update-grub".

            % less /etc/debian_version
            6.0.5
            % less /usr/sbin/update-grub
            #!/bin/sh                       
            set -e
            exec grub-mkconfig -o /boot/grub/grub.cfg "$@"
            
            

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Grub2 vs Grub1 : Quel est le problème ?

              Posté par  (site web personnel) . Évalué à 1.

              Très juste. ;)

              C'était simplement pour mettre en avant le fait que Debian faisait appel à ce script (update-grub) lors des installations qui le nécessitent, et moi avec quand j'en ai besoin.
              Mais peut-être qu'Arch a un fonctionnement similaire du coup ?

              There is no spoon...

      • [^] # Re: Grub2 vs Grub1 : Quel est le problème ?

        Posté par  . Évalué à 2.

        Entièrement d'accord, sauf que je me suis fais moinsé la tronche sur un autre journal après m'être enflamé sur systemd.

        Le principe reste le même. On prend un logiciel qui n'a plus d'évolution majeure mais qui :

        • est simple de configuration et d'utilisation
        • fait le boulot sans jamais faillir
        • n'implémente pas la killer feature qui va servir pour 3% des cas et emmerder tous le monde.

        Des exemples récents :

        • Gnome 2 -> Gnome 3
        • Grub 1 -> Grub 2
        • init BSD -> systemd
        • [^] # Re: Grub2 vs Grub1 : Quel est le problème ?

          Posté par  . Évalué à 10.

          Autant systemd est une hérésie qui mérite le mépris le plus profond de la part de tout bon linuxien (Et même des windowsiens avertis, quand je leur explique qu'il s'agit d'une espèce de meta-DCOM unique et centralisateur ils me regardent comme si j'étais devenu fou. Alors que c'est pas moi qu'il faut soigner), autant grub2 est nécessaire pour plusieurs raisons :

          1) Le ridicule ca va bien 5 minutes :
          Il s'agit peut être de features qui intéressent 3% des gens, mais c'est vrai que les 3% de gens qui voulaient du VFS chiffré sur la partition racine commenceaient sérieusement à se demander si on se foutait pas de leur gueule. Preloader, bootloader, chainboot, chainloader, preboot, extractions du kernel en mémoire vive, chargement des modules et enfin boot. Avec à chaque mise à jour la légère apréhension qui va bien à se demander dans quel état on va retrouver son boot.

          2) C'est pas plus mal de booter un vrai file system :
          Si on omet légèrement EXT4, qui est un FS dont on a bien du mal à dire si il est moderne ou ancien tant il est optimisé dans les coins (pan), la plupart des fs dit "modernes" (ZFS, HammerFS par exemple) ou des pseudofs (LVM2, gvinum/gpart, luks et autre) utilisent une couche d'abstraction qui n'est pas vraiment compatible avec les techno de grub. Bon en bricolant ca finissait par passer d'une façon ou d'une autre, mais bonjour les pirouettes.

          3) Et si je veux 6 partitions actives ?
          La limite de 4 partitions actives est un poil dépassée. J'étais déjà un poil à l'étroit dedans quand les disques faisaient 20Go, alors maintenant qu'ils font 1,5To ca me gave d'autant plus, surtout vu ce qui a été dit précédemment, quand j'ai déjà une partition pour le /boot, une pour le / et une pour mon vrai système de données encapsulé dans du LVM et éventuellement chiffré, je me retrouve à devoir acheter un disuqe supplémentaire ou mettre le swap dans le LVM si je veux garder mon autre OS (Freebsd, mais c'est pareil avec windows). GPT permet de repousser cette limite, seulement grub a besoin d'un MBR classique alors on se retrouve une fois de plus à faire des pirouettes.

          4) Les systèmes UEFI/GPT only arrivent.
          Dans peu de temps, grâce à windows8 (un bonheur n'arrive jamais seul) on aura du secure bidule à tous les étages, et je suis prêt à parier que le secure bidule en question va exiger d'ici deux ans maximum une partoche GPT ou un boot UEFI (ou les deux). Et là ça va commencer à devenir compliqué de mettre des MBR hybrides signés (merci Red Hat), surtout si on veut garder le windows préinstallé. Bien sur il restera toujours la possibilité de vérifier que votre carte mère est compatible grub (sous reserve d'upgrade de firmware à la con) sur les sites spécialisées, mais personnellement quand je fais mes courses j'ai déjà le catalogue des cartes wifi compatible avec mes systèmes (3 tomes avec les numéros de séries- parceque des fois le constructeur il change la puce mais pas la référence) et le catalogue des ACPI qui sont fonctionnelles (4 tomes, avec numéros de série ET de firmware). Donc si je peux éviter de me trimbaler en plus le catalogues des cartes qui tolèrent le boot MBR hybride ca m'arrange (et tant pis pour mon osteo qui aime bien que je me trimballe avec 20 tomes sur moi en toute circonstance).

          En vrac je vous épargne le boot de partoche avec des secteurs 4k/8k/16k, la reprise suspend on disk de partitions cryptées, la regen de pool ZFS en vrac etc.

          Pour finir bien que grub2 soit officiellement encore en beta il est relativement fonctionnel au moment ou les distribs commencent à l'adopter (plus que systemd par exemple qui a forcé trois réécritures de DBus à lui tout seul, et on va rester gentil et pas parler de pulseaudio). Il est également relativement non intrusif (si on veut remettre lilo ou l'ancien grub à la place, pas besoin de désinstaller la moitié du système d'abord).

          On va donc dire que grub2 est un peu vert pour une adoption aussi massive, mais que ca se comprend quand même.

          • [^] # Re: Grub2 vs Grub1 : Quel est le problème ?

            Posté par  (site web personnel) . Évalué à 3.

            Une adoption aussi massive, on parle toujours des utilisateurs arch ?

            • [^] # Re: Grub2 vs Grub1 : Quel est le problème ?

              Posté par  . Évalué à 1.

              Une adoption aussi massive, on parle toujours des utilisateurs arch ?

              Non plutôt d'une adoption massive par les distribs en fait. Il reset plus grand monde sur grub de base…

          • [^] # Re: Grub2 vs Grub1 : Quel est le problème ?

            Posté par  (site web personnel) . Évalué à 3.

            j'ai déjà le catalogue des cartes wifi compatible avec mes systèmes (3 tomes avec les numéros de séries- parceque des fois le constructeur il change la puce mais pas la référence) et le catalogue des ACPI qui sont fonctionnelles (4 tomes, avec numéros de série ET de firmware)

            C'est une hyperbole ou tu as vraiment un fichier à jour de références de matériel qui marche ? Si c'est le cas tu pourrais le partager stp ? (Surtout celui des cartes wifi : si ça pouvait m'éviter de devoir faire joujou avec les tableaux de linuxwireless.org en comparant avec les offres des sites de commerce en ligne, ce serait génial.)

      • [^] # Re: Grub2 vs Grub1 : Quel est le problème ?

        Posté par  . Évalué à 6.

        Le problème c’est l’inutilité total des features de GRUB2 dans 99% des cas. Le problème c’est que GRUB1 fonctionnait encore très bien, ça ne servait à rien de le virer totalement des dépôts pour faire chier ceux qui l’utilisent encore.

        Non mais avoue que c'est quand même pas mal d'avoir un bootloader qui gère 100 % des cas au lieux de 99 % (bon c'est vrai 100 % en vrai j'y crois pas) à part une syntaxe un poil plus évoluée je vois pas trop ce qui change. Youhou ! C'est toujours le même bootloader : The GRand Unified Bootloader.

        Bref autant faire le saut tout de suite. Si vous y réfléchissez, c'est un saut nettement moins important que de passer à systemd :/

      • [^] # Re: Grub2 vs Grub1 : Quel est le problème ?

        Posté par  . Évalué à 1.

        Il faut arrêter de déconner avec la config de Grub 2 !

        https://wiki.archlinux.org/index.php/GRUB_2#Manually_creating_grub.cfg

        • [^] # Re: Grub2 vs Grub1 : Quel est le problème ?

          Posté par  . Évalué à 2.

          Warning: Editing this file is strongly not recommended. The file is generated by the grub-mkconfig command, and it is best to edit your /etc/default/grub or one of the scripts in the /etc/grub.d folder.

          Ah ces archeux, pas moyen de les empêcher de toucher à un fichier de configuration ! C'est strongly not recommended on vous dit !

          Moi /etc/grub.d j'aime bien.

          • [^] # Re: Grub2 vs Grub1 : Quel est le problème ?

            Posté par  . Évalué à 1.

            C'est normal que ce ne soit pas recommandé. C'est une méthode qui nécessite de savoir ce que l'on fait ;) Je ne vois rien de contradictoire entre cet élément et mon commentaire.

            • [^] # Re: Grub2 vs Grub1 : Quel est le problème ?

              Posté par  (site web personnel) . Évalué à 1.

              C'est surtout que si tu lances grub-mkconfig, ça va t'écraser ta config, donc autant éditer le bon fichier.

              • [^] # Re: Grub2 vs Grub1 : Quel est le problème ?

                Posté par  . Évalué à 1.

                Justement, je parle de ne pas utiliser grub-mkconfig. C'est un choix à faire, non recommandé mais que je trouve plus pratique et plus KISS.

                • [^] # En fait, pas de problème sous Arch

                  Posté par  . Évalué à 3.

                  En réfléchissant à la façon dont fonctionnent Fedora ou Debian, il y a une raison pour que ce ne soit par recommandé : avec ces distributions, à chaque mise à jour du noyau, on se retrouve avec des fichiers kernel et initramfs qui ont un nouveau nom, il faut donc mettre à jour le fichier de configuration.

                  À l’époque de Grub 0.9, ces distributions avaient un script spécifique qui devait modifier intelligemment le fichier de configuration en essayant de reporter les options sur le nouveau noyau (cela dit, ça marchait généralement bien).

                  Grub 2, lui, est fourni avec un script qui regénère le fichier de configuration à partir d’autres sources en écrasant complètement l’ancien, donc ce qu’on aurait pu configurer dedans passe à la trappe.

                  Par contre, sur Arch, qui ne garde que le noyau courant avec toujours le même nom de fichier, ou sur Mandriva, qui accède au noyau courant et au précédent par des liens dont le nom ne change pas non plus (si ça n’a pas changé depuis que je n’ai pas utilisé cette distribution), aucun besoin de mettre à jour ce fichier au changement de noyau.

                  Donc on peut aussi bien configurer directement dedans et jeter l’affreux script de génération.

                  Moralité : je ne vais pas être emmerdé sur mes machines sous Arch, même si je passe à Grub 2 ; par contre, je vais être emmerdé avec les distribs que j’installe au boulot avec lesquelles je pourrai difficilement éviter Grub 2.

                  « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

                  • [^] # Re: En fait, pas de problème sous Arch

                    Posté par  . Évalué à 1.

                    La meilleure solution est à mon avis celle de Gentoo (ou Mandriva mais je ne me base que sur tes dires). Chaque kernel a son nom qui inclut sa version mais il y a un lien symbolique de la version en cours vers un nom générique.

      • [^] # Re: Grub2 vs Grub1 : Quel est le problème ?

        Posté par  . Évalué à 6.

        Ce n'est pas parce que c'est inutile pour toi que c'est inutile pour d'autres.

        Pour moi, le simple fait que l'on puisse plus foirer une install de grub2 en virant/déplaçant la partition qui contient les modules m'a fait envie d'essayer grub2 avant même qu'il soit stabilisé. Parce que quand ton bios boote pas sur CD ou sur USB et que ton seul moyen de booter, c'est ton lecteur disquette capricieux, tu peux pas vraiment compter sur ton liveCD pour repartitionner ton disque et réparer ton système après.

        Alors oui, ça à occasionné une belle perte de fonctionnalité pour toi, puisqu'il à fallu réduire le cœur de GRUB2 pour qu'il puisse afficher une ligne de commande qui permet d'explorer les périphériques, leurs systèmes de fichier et charger des modules, le tout dans un programme qui tient dans le MBR, et que cette modularité se ressent dans ses fichiers de configurations qui doivent devenir extensibles (mais t'a de la chance, si c'était Lennart qui avait fait ça, il aurai tenté d'utiliser du XML).

        Mais moi ça me change la vie. Et je choisi grub2 pour la même raison que je choisi mon init : Parce que je veux un système réparable. J'ai eu du plaisir à apprendre les commandes de grub2 qui permettent de s'en sortir quand il trouve pas sa partoche. Et à les utiliser, aussi.

        Ça n'a rien à voir avec grub2 qui serai plus mieux/performant/moderne ou qu'il supporterai de booter BSD.

    • [^] # Re: Grub2 vs Grub1 : Quel est le problème ?

      Posté par  (site web personnel) . Évalué à 7.

      D'accord, vous m'avez convaincu pour Grub2.

  • # Joli lancer

    Posté par  (site web personnel) . Évalué à 10.

    J'ai l'impression que grub 2 est le mal aimé du moment. Ayant compilé des versions svn ( oui, j'ai bien dit svn, avant que grub 2 passe à bzr ), j'ai pas eu le sentiment de me retrouver à quel chose de si compliqué. Certes, le fichier de config était un poil différent, mais ça arrive. Les versions récentes de grub sont capable de lire les fichiers de grub 0.99, dans mon souvenir. Certes, il faut lancer une commande pour créer ton binaire ( efi dans mon cas ) avec les modules que tu choisis, mais c'est pas plus différents que le kernel ou d'un tas de trucs modulaires ( genre une distro ).

    Est ce que par hasard, tu serais pas plus tôt en train de raler sur l'outil d'autodetection des OS fourni avec grub 2 ? Auquel cas, tu seras content de savoir qu'un utilisateur un chouia bricoleur peut s'en passer, si il aime faire les choses à la main. Mais pour ça, il faut bien sur aimer mettre les mains dans le cambouis, et à moins d'être à la limite entre "je veux bricoler mais je veux pas non plus me faire chier", ça ne pose de problème.

    De même, tu sembles ne pas aimer le fait d'avoir plusieurs fichiers au lieu d'un pour le fichier d'init. Mais c'est pas les archeux qui parlent toujours de la philosophie KISS , et tu voudrais garder un fichier fait tout, ce qui ne correspond pas vraiment à la définition de simple ?

    Ou peut être est ce simplement que dire "KISS", c'est un peu se méprendre, car 1 programme qui fait tout, c'est simple, ça fait qu'un programme, mais c'est pas simple, ça fait tout, tout comme plein de programmes, ç'est simple, ils font qu'une chose, mais c'est compliqué, car ils sont pleins.

    Et peut être que KISS, c'est simplement faire moins de chose, auquel cas, tu es juste pas d'accord sur la partie qu'il faut pas faire, ce qui veut dire que pour toi, KISS, c'est faire juste ce que tu comprends et ce que tu veux, ce qui curieusement, ne correspond pas aux mêmes choses pour tout le monde.

    • [^] # Re: Joli lancer

      Posté par  (site web personnel) . Évalué à 7.

      Juste comme ça, tu as déjà utilisé Arch ?

      Parce que bon, plus simple que rc.conf, c'était dur à faire… Surtout quand tu as connu le bordel de ce merdier de /etc/sysconfig …

    • [^] # Re: Joli lancer

      Posté par  . Évalué à 2.

      je vois toujours pas ce que l'on reproche a lilo…

      • [^] # Re: Joli lancer

        Posté par  (site web personnel) . Évalué à 3.

        Le fait que le code soit x86 only, je pense, le fait que l'architecture soit limitant ( ie le fait que lilo doit tenir entièrement dans une zone limité, ce qui interdit le boot sur des trucs plus compliqués que "/boot sur ext2" ), le fait que ça évolue plus trop, etc.

  • # Si si, c'est la question

    Posté par  (site web personnel, Mastodon) . Évalué à 0. Dernière modification le 25 juillet 2012 à 00:09.

    Savoir si c'est mieux ou moins bien n'est pas vraiment la question. La question est plutôt de savoir où iront ceux qui trouvent que c'est moins bien.

    Je ne suis pas de cet avis, au contraire. Est-ce mieux ou moins bien, ce "tournant" que suit Arch, et pourquoi ?
    Par exemple :

    Ça y-est, l'ancestral Grub n'est plus. Arch annonce passer à Grub2. (…) Bref, sur Arch, j'utiliserai lilo.

    C'était ancestral comment, Grub ? Genre plus développé depuis des années, ou encore en marche mais jeté aux orties prématurément ? Vu que la version de lilo dans [core] date de 2011, je présume que Grub était encore plus vieux.

    rc.conf est enterré vivant (…) Mais le sujet est si sensible, qu'il faut que quelqu'un dise que ce changement ne change rien.

    Ça me paraît être une délicate attention. Que ce mode de config soit "déprécié" est-il si dramatique ? Un jour, il ne marchera plus, mais ce jour n'est apparemment pas arrivé.

    L'init BSD se meurt (…) Bref, sur Arch, jutiliserai un init qui n'existera plus.

    Si tu l'utilises, c'est qu'il existe encore, non ?

    Je peux comprendre que ça te stresse qu'Arch suive "les évolutions récentes" et envisage de migrer vers systemd, vu que c'est essentiellement de cela qu'il s'agit ici. Mais je te trouve bien catégorique en affirmant que désormais, la ligne officielle des mainteneurs d'Arch sera de te pourrir la vie en empêchant activement tes bootloaders et autres scripts de fonctionner. Les distros sont-elles vouées à ruiner les espoirs d'une partie de ses utilisateurs à chaque évolution ? systemd représente-il réellement un tel schisme ?

    • [^] # Re: Si si, c'est la question

      Posté par  . Évalué à 5.

      GRUB fonctionnait, il n’y avait aucune raison de le virer complètement des dépôts.

      Sinon, pour te faire plaisir :

      (root) |> ~ <| pacman -Qi grub
      Name           : grub
      Version        : 0.97-21
      URL            : http://www.gnu.org/software/grub/
      Licenses       : GPL
      Groups         : base
      Provides       : None
      Depends On     : ncurses  diffutils  sed
      Optional Deps  : xfsprogs: freezing of xfs /boot in install-grub script
      Required By    : None
      Conflicts With : None
      Replaces       : None
      Installed Size : 2092.00 KiB
      Packager       : Ronald van Haren <ronald@archlinux.org>
      Architecture   : x86_64
      Build Date     : Thu 03 Nov 2011 10:16:30 PM CET
      Install Date   : Sat 16 Jun 2012 09:13:59 AM CEST
      Install Reason : Explicitly installed
      Install Script : Yes
      Description    : A GNU multiboot boot loader
      
      

      Le reste de ton commentaire étant que tu troll, je m’abstiendrai de répondre.

      • [^] # Re: Si si, c'est la question

        Posté par  (site web personnel) . Évalué à 10.

        Linux 1.0 fonctionnait, pourquoi le supprimer des dépôts ?

      • [^] # Re: Si si, c'est la question

        Posté par  . Évalué à 6. Dernière modification le 25 juillet 2012 à 09:58.

        GRUB fonctionnait, il n’y avait aucune raison de le virer complètement des dépôts.

        C'est un peu plus compliqué que cela. Pour "fonctionner", Grub nécessite d'être patché, et nécesssite d'autant plus de patches qu'il vieilli. Et ça, c'est difficilement gérable quand la distro vise à rester proche d'upstream et que les mainteneurs n'ont plus envie de faire de l'archarnement thérapeutique.

        Aussi, Grub n'est pas supprimé des dépôts, il est simplement transféré dans l'AUR, comme tout logiciels non supporté officiellement.

        Tu devrais aussi jeter un oeil à Syslinux, qui remplace avantageusement Grub dans la majorité des cas.

        • [^] # Re: Si si, c'est la question

          Posté par  . Évalué à 2.

          Aussi, Grub n'est pas supprimé des dépôts, il est simplement transféré dans l'AUR, comme tout logiciels non supporté officiellement.

          GRUB aurait pu (aurait du même) être transféré vers [community].

          Rappel, les dépôts officiels sont [core] et [extra].

          • [^] # Re: Si si, c'est la question

            Posté par  . Évalué à 2.

            Rien n'empêche grub legacy de remonter vers [community]

          • [^] # Re: Si si, c'est la question

            Posté par  . Évalué à 4. Dernière modification le 25 juillet 2012 à 10:48.

            GRUB aurait pu (aurait du même) être transféré vers [community].

            Non. Le dépôt "community" consiste en paquets non officiels AUR que les TU (Trusted Users) prennent en charge de maintenir correctement sous forme binaire (mise à jour, patches).

            Si aucun TU ne veut prendre Grub sous son aile, alors c'est dans l'AUR qu'il doit être transféré. Et effectivement, rien n'empêche un TU de remonter grub-legacy vers [community].

    • [^] # Re: Si si, c'est la question

      Posté par  (site web personnel) . Évalué à 1.

      C'était ancestral comment, Grub ? Genre plus développé depuis des années, ou encore en marche mais jeté aux orties prématurément ? Vu que la version de lilo dans [core] date de 2011, je présume que Grub était encore plus vieux.

      Non mais utiliser lilo à la place de Grub c’est stupide, vu que 1) Grub est est toujours disponible, juste, il est dans l’AUR 2) Grub 2 ne remplace pas Grub 1 3) Grub 2 est utilisable 4) Il y a syslinux.

      Ça me paraît être une délicate attention. Que ce mode de config soit "déprécié" est-il si dramatique ? Un jour, il ne marchera plus, mais ce jour n'est apparemment pas arrivé.

      Ça ne marchera pas un jour, et la configuration du système devient debiannesque. C’est de l’anticipation.

      Si tu l'utilises, c'est qu'il existe encore, non ?

      utiliserai c’est de l’indicatif futur. Et c’est aussi de l’anticipation.

      Mais je te trouve bien catégorique en affirmant que désormais, la ligne officielle des mainteneurs d'Arch sera de te pourrir la vie en empêchant activement tes bootloaders et autres scripts de fonctionner.

      Enlever grub de [core] correspond relativement bien à ça, pourtant. Ça veut dire qu’il faut se faire chier à le récupérer de l’AUR pendant l’install, etc…

      systemd représente-il réellement un tel schisme ?

      Ça va juste pourrir la vie. Trois tonnes de fichiers de configurations différents, un init pas customisable (rc.sysinit c’est pratique). Et ça n’importe rien à 99% des utilisateurs, sauf peut-être un temps de boot réduit de 3 secondes.

      Autant les symlinks mis en place pour faciliter l’utilisation de systemd (/run /lib etc) je m’en tape, ça marche pareil, autant les modifications à la configuration du système…

      • [^] # Re: Si si, c'est la question

        Posté par  (site web personnel) . Évalué à 5.

        Trois tonnes de fichiers de configurations différents,
        un init pas customisable (rc.sysinit c’est pratique).

        Euh, pas "customisable", je vois pas, il suffit de créer une unité pour systemd et c'est "customisé"…

        J'ai jamais fait avec systemd mais avec upstart c'est simplissime…

        sauf peut-être un temps de boot réduit de 3 secondes.

        Wai, enfin la dessus, systemd explose un peu la concurrence… J'avais plymouth sur mon laptop (archlinux), depuis que je suis passé à systemd, je pense le supprimer vu qu'il n'a même pas le temps de s'afficher… Et un portable qui démarre en 2 seconde entre syslinux et KDM, c'est bien pratique… (et qu'on vienne pas me parler de mise en veille…)

        Sinon, pour Grub2 vs Grub1, je rappelle que Arch propose syslinux (enfin extlinux) qui fonctionne très bien, qui est très simple à utiliser…

    • [^] # Re: Si si, c'est la question

      Posté par  . Évalué à 1.

      C'était ancestral comment, Grub ? Genre plus développé depuis des années, ou encore en marche mais jeté aux orties prématurément ? Vu que la version de lilo dans [core] date de 2011, je présume que Grub était encore plus vieux.

      Ca soulève une question que je trouve très pertinente : si un programme est stable, n'a besoin d'aucun ajout pour faire ce qu'il doit faire, et qu'il n'a plus de patch, doit-il nécessairement être jeté aux orties ? Personnellement, je pense que non, sauf si il a plus de 15 ans (quoique …).

      Emacs le fait depuis 30 ans.

  • # même avis

    Posté par  (site web personnel) . Évalué à 7.

    1. je comprends trop rien à grub 2 et sa façon d'être configuré. Je m'en sortais très bien avec grub-legacy
    2. Je le disais l'autre jour, on entends les râles d'agonie du cher rc.conf
    3. J'ai essayé systemd, pour voir, et y'a des trucs qui passent mal. genre swap crypté (enfin bon c'est parce la config de arch du /etc/crypttab n'est pas "standard" …)
    4. Pas encore, mais c'est un peu son âme qui s'en va. Je ne dirais pas que c'est la faute des devs de arch. Ils ne font que suivre "upstream", qui se fait de plus en plus contraignant. Et on ne peut plus faire la distro qu'on veut (??). A moins de devoir faire des choix radicaux.

    J'avais l'impression qu'un seul dev poussait à l'adoption des derniers trucs à la mode, et les autres réagissaient plus ou moins mollement pour finalement accepter. Non ?
    C'est sûr: que dire contre le passage de /lib à /usr/lib ? Que dire contre grub2 ?

    P.S.: Je me demande bien comment va réagir Patrick Volkerding face à systemd. Il a déjà dit non à PAM, merde à GNOME…

    • [^] # Re: même avis

      Posté par  . Évalué à 10.

      C'est sûr: que dire contre le passage de /lib à /usr/lib ? Que dire contre grub2 ?

      C'est toute l'histoire. Puisqu'il n'y a rien ou pas grand chose à dire contre, et que c'est upstream, bah, c'est adopté.

      je crois que vous avez râté un passage de la philosophie du projet archlinux. Ces choix, ce n'est pas les développeurs arch qui les font, c'est les développeurs upstream. Les développeurs arch ont fait le choix de suivre les choix upstream, c'est même un peu un des principes fondateurs de arch.

      Donc, les devs de grub ayant choisi de ne plus supporter grub1, arch ne supporte plus grub. Dans le milieu du FHS/Red Hat, ils ont décidé de changer /lib en /usr/lib, il n'y a aucun problème grave à le faire, donc arch le fait. Et c'est tout.

      Ce que vous critiquez comme la perte de l'âme de archlinux, je le vois plutôt comme une réaffirmation de ses principes !

      • [^] # Re: même avis

        Posté par  (site web personnel) . Évalué à 4.

        Arch décide de respecter l'upstream parce qu'elle a décidé d'être KISS, et qu'elle définissait le KISS par l'exemple.

        Le jour ou l'upstream s'éloigne à ce point de ce que Arch définissait comme KISS, il se créé une tension. En suivant l'upstream, Arch respecte certains de ses principes tout en en reniant d'autres.

    • [^] # Re: même avis

      Posté par  . Évalué à 2.

      Je me demande bien comment va réagir Patrick Volkerding face à systemd.

      Ça restera hors de Slack, sauf si la maintenance devient trop problématique (genre ça pète dans tous les coins parce que tout est codé avec systemd en tête).

      On verra, mais déjà à présent, pour avoir les sources d'udev il faut télécharger systemd…

      • [^] # Re: même avis

        Posté par  . Évalué à 2.

        Je trouve au passage la manière qu'a Arch de gérer udev intelligente. Paquet systemd-tools indépendant de systemd.

    • [^] # Re: même avis

      Posté par  . Évalué à 6.

      idem.

      Merci à Sygne pour avoir rédigé ce journal auquel j'adhère à 100 %. (
      d'ailleurs… http://forums.archlinux.fr/post98780.html)

      Que de frustrations face à ces « nouveautés ».

      Mais ceux qui nous traitent de vieux barbus réactionnaires anti-changement font peut-être fausse route : je ne suis pas contre le changement, bien au contraire, si ce changement peut induire plus de simplicité, selon le fameux adage « La perfection de conception est atteinte, non pas lorsqu'on ne peut plus rien ajouter, mais lorsqu'on ne peut plus rien enlever ».

      D'ailleurs je trouve ironique de retrouver cette citation ici :
      https://wiki.archlinux.org/index.php/The_Arch_Way_v2.0_%28Fran%C3%A7ais%29

      Alors oui, aux orties Alsa, pulseaudio, grub, grub2, consolekit, polkit, *kit, xorg et tout ce qui entraine d'inutiles complications.

      Et arrêtez de nous les briser à changer les points de montage (cf. le /media => /run/user/$USER/media/ la dernière trouvaille de udisks2)

      On attend juste des fichiers de configuration simples, clairs, bien placés, pas avoir à bidouiller dans un fichier au nom "logique" du genre /etc/X11/xorg.conf.d/10-evdev.conf pour modifier le mappage clavier, non merci.

      Mais ça ne semble malheureusement pas l'objectif des développeurs de free desktop, ni de ceux de Arch. Dans ces conditions, j'espère qu'il y aura un fork, ou sinon il restera quoi ? Slackware ? Dommage pour les 90 paquets logiciels que j'ai réalisé pour Archlinux, mais ça doit pouvoir se reprendre sur un autre système au pire des cas.

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

      • [^] # Re: même avis

        Posté par  . Évalué à 3.

        Le problème, c'est que ces logiciels veulent couvrir un maximum de cas d'utilisation, du coup, il faut prévoir la configuration qui va avec. Si tu veux de la configuration plus simple, il faut soit développer une surcouche qui va traduire ta configuration simple vers les configurations complexes de ces logiciels, soit développer des équivalents offrant moins de fonctionnalités.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: même avis

        Posté par  . Évalué à 8.

        Le wiki français est sur archlinux.fr déjà.

        Et, donc, permets moi de le citer :

        Archlinux :

        Arch Linux tâche de fournir des logiciels dans leur dernière version stable.

        Kiss :

        Jamais ArchLinux ne prendra l'initiative de cacher ou d'interfacer des fonctionnalités ou des possibilités à l'utilisateur. Si un outil de configuration doit exister, la philosophie d'ArchLinux est de laisser son développement aux auteurs du logiciel

        Tu n'as pas compris ce qu'était Arch. Arch ne va pas modifier les logiciels usptream pour les simplifier. Parce que, justement, tenter de rendre KISS ce qui ne l'est pas, c'est forcément impossible : tu veux que pour simplifier les choses, du code soit ajouté. Mais :

        Il y a bien sûr plusieurs façons d'être simple : la simplicité selon ArchLinux, c'est une conception sans complications (techniques), sans superflu et dont le code reste simple et élégant.
        Jamais ArchLinux ne prendra l'initiative de cacher ou d'interfacer des fonctionnalités ou des possibilités à l'utilisateur. Si un outil de configuration doit exister, la philosophie d'ArchLinux est de laisser son développement aux auteurs du logiciel.

        Toi ce que tu demandes c'est de développer des wrappers permettant de cacher la complexité des logiciels distribués, ce qui va à l'encontre de la philosophie d'arch qui propose de faire le moins de moficfication possible, pour garder les choses simples.

        Donc, ce n'est pas contre Arch que tu râles, mais contre les devs opensource en général. Ce n'est pas arch qui devient moins KISS, mais les logiciels. Encore que. Tu râles contre les kits et les devs, mais tu ne trouves pas pratique de pouvoir mettre un CD et qu'il soit affiché dans nautilus ? Tu ne trouves pas pratiques de pouvoir mettre en veille ton laptop depuis ton user ? etc etc.

        Il faut comprendre que des features avancées demandent… du code plus complexe.

        Maintenant, je vais répondre encore une fois ce que j'ai dit 100 fois :
        si tu n'es pas content, change les choses au lieu de râler. Surtout que :

        De par sa simplicité, ArchLinux permet à l'utilisateur de faire ses propres choix. Il peut alors construire le système qui lui convient, grâce au large choix de paquets à sa disposition. Pour reprendre un mot de Judd Vinet, "Arch est ce que vous en faites !"

      • [^] # Re: même avis

        Posté par  . Évalué à 1.

        Et arrêtez de nous les briser à changer les points de montage (cf. le /media => /run/user/$USER/media/ la dernière trouvaille de udisks2)

        C’est pas GNOME qui fait ça ?

        Je n’ai vu cette connerie que sur le PC de mes parents (la seul Arch avec GNOME que je connaisse). KDE monte toujours dans /media/<label>

        • [^] # Re: même avis

          Posté par  (Mastodon) . Évalué à 2.

          J'ai une arch sans gnome et il monte les fs dans /run/user/$USER/media/ aussi.

          Je ne trouve pas ça idiot, juste déroutant quand on ne le sais pas (mais un simple mount ou df nous renseigne bien vite).

          • [^] # Re: même avis

            Posté par  . Évalué à 3.

            Je ne trouve pas ça idiot

            Ha, si, clairement : on a à peine créé /media qu’on commence déjà à monter des partoches n’importe où dans le FS.

            • [^] # Re: même avis

              Posté par  (Mastodon) . Évalué à 4.

              Ha, si, clairement : on a à peine créé /media qu’on commence déjà à monter des partoches n’importe où dans le FS.

              Ça fait déjà quelques années. Et c'est plutôt /media qui était une bêtise car il n'apportait rien par rapport à /mnt en dehors du nom. La au moins ça répond à un besoin particulier de mettre au même endroit tout ce qui est volatile et propre à un user comme les montage en espace utilisateur.

              • [^] # Re: même avis

                Posté par  . Évalué à 6.

                Tu trouve /media idiot parce qu’on avait déjà /mnt mais tu ne trouve pas /run/user/… idiot. Je ne comprends pas.

                • [^] # Re: même avis

                  Posté par  . Évalué à 2.

                  A titre personnel, je n'ai toujours pas saisi pourquoi /media etait apparu alors le /run/user/$USER/media …

                  Si un Dieu existe, j'espere qu'il va preserver slackware et ses "coproprietaires" pendant encore longtemps :D

                  Note: oui je suis contre le changement pour le changement.

                  • [^] # Re: même avis

                    Posté par  . Évalué à 4.

                    je n'ai toujours pas saisi pourquoi /media etait apparu

                    Je crois que c'était pour éviter des collisions entre ce que les gens avaient déjà défini comme montage et ceux qui étaient automatique. Le but est de ne pas se retrouver avec des trucs comme /mnt/hdd_externe et /mnt/hdd_externe1

                    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                    • [^] # Re: même avis

                      Posté par  . Évalué à 1.

                      j'ai toujours cru que /media c'était justement pour le montage automatique, et /mnt pour le montage manuel.

                      En tout cas /run/user/$USER/media/ ça va être trop pratique quand on a 10 utilisateurs sur le même ordinateur qui lancent leurs sessions en parallèle et qui ont a monter des disques dur externe ou des clés usb

                      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

                      • [^] # Re: même avis

                        Posté par  . Évalué à 3.

                        j'ai toujours cru que /media c'était justement pour le montage automatique, et /mnt pour le montage manuel.

                        C'est ce que je voulais dire en tout cas. J'expliquais pourquoi ne pas avoir choisi /mnt pour le montage automatique.

                        En tout cas /run/user/$USER/media/ ça va être trop pratique quand on a 10 utilisateurs sur le même ordinateur qui lancent leurs sessions en parallèle et qui ont a monter des disques dur externe ou des clés usb

                        C'est ironique ? Parce que ça me semble justement le cas d'utilisation. Évidemment, la majorité des gens ne sont pas dans ce cas mais ça doit être bien utilise sur tout ce qui est serveur multipoint.

                        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: même avis

        Posté par  . Évalué à 4.

        On attend juste des fichiers de configuration simples, clairs, bien placés, pas avoir à bidouiller dans un fichier au nom "logique" du genre /etc/X11/xorg.conf.d/10-evdev.conf pour modifier le mappage clavier, non merci.

        La différence entre cette configuration et le split de rc.conf est la dissémination.

        Par exemple, pour X.org, par défaut sur Arch, les noms des fichiers de configuration sont fonction du driver (evdev, synaptics, etc) mais moi, j’ai un truc du genre :

        • /etc/X11/xorg.conf.d/
          • 10-keyboard.conf
          • 10-mouse.conf
          • 10-trackpoint.conf
          • 10-touchpad.conf

        Alors que pour rc.conf, si j’ai bien compris, on aura :

        • /etc/hostname
        • /etc/vconsole.conf
        • /etc/locale.conf
        • /etc/module-load.d/

        Chacun de ces fichiers a bien sûr sa propre syntaxe (hostname contient le hostname en brut, locale.conf est de la forme clef=valeur, etc.).

        Pour les modules c’est d’ailleurs très drôle :

        • on a besoin de quoi ? Charger des modules précis et configurer des modules.
        • on avait quoi ? MODULES=(<mod1> <mod2> […]) dans /etc/rc.conf et /etc/modprobe.d/ (anciennement /etc/modprobe.conf).
        • on passe à quoi ? Un dossier où, si j’ai bien compris (impossible de trouver de la doc à ce sujet), on va indiquer les modules spécifique à charger et leur configuration.

        Il est où le KISS là dedans ?

        • [^] # Re: même avis

          Posté par  . Évalué à 1.

          D'ailleurs : quelqu'un a-t-il la raison d'avoir créée une nouvelle architecture pour le chargement des modules ?
          Les fichiers dans /etc/modprobe.d/ ne suffisaient pas ?

  • # Le chant du Sygne

    Posté par  . Évalué à 10.

    Utilisateur très satisfait de Arch par ailleurs, je comprends tes remarques/critiques et te rejoins globalement sur le fond.

    L'init BSD est en cours de migration vers systemd depuis un moment déjà sur la plupart des distribs, bientôt il ne restera plus que Slack, et les unix non linux.
    Je suis tout de même passé full systemd sur mon portable pour m'y habituer, puisque c'est l'avenir. Techniquement ça fonctionne bien, c'est beaucoup plus rapide, et pour le moment je n'ai pas été bloqué pour effectuer les opérations courantes, c'est simple.
    Après, comme toi, ce qui me chiffone c'est qu'on s'éloigne un peu trop du tronc Unix standard pour faire du full linux, et j'ai un peu peur de voir arriver une confirmation de scission entre ces cousins.

    Concernant grub-legacy, j'ai migré vers syslinux, et je t'encourage à lui donner sa chance si tu n'utilises pas d'OS non unix (auquel cas, il te faudrait chainer grub ou autre derrière, donc on perd tout l'intérêt), et si tu n'as pas d'EFI. Le fichier de configuration est simple et clair, le projet actif, et KISS dans l'esprit. Ici je rejoins sans réserve tes remarques sur Grub2.

    Pour le rc.conf… le but d'Arch étant d'être au plus prêt du mainstream, quelque part je trouve logique qu'il laisse progressivement la place aux fichiers de conf dédiés des applications concernées. Après, c'est sûr que la centralisation est pratique, mais induit une obfuscation que tu dénonces par ailleurs.

    Longue vie à Arch, puissent les leaders faire les bons choix, je ne vois pas migrer alors que j'ai trouvé mon Graal.

    • [^] # Re: Le chant du Sygne

      Posté par  (site web personnel) . Évalué à 5.

      et je t'encourage à lui donner sa chance si tu n'utilises pas d'OS non unix

      Tu parles de Windows là ? Syslinux via chain.c32 peut très bien booter un windows sans grub.

  • # Grub, rc.conf, systemd

    Posté par  . Évalué à 3.

    Certains s'en réjouiront, mais pas moi. Le nouveau Grub me semble aussi confus que la page du wiki qui lui est consacrée.

    D’un autre côté, elle est plus claire que la dernière que j’ai vue, dont j’avais conclu qu’il y avait plein de fichiers de configuration… mais aucun qui soit prévu pour qu’on puisse configurer (!), entre le fichier généré qu’il ne faut pas modifier parce qu’il est généré et les autres fichiers qui peuvent permettre d’influencer la génération, mais pas de manière immédiate.

    Cela dit, je trouve aussi que c’est un recul de plus par rapport aux principes KISS. Je ne migrerai peut-être pas avant d’avoir besoin d’une fonctionnalité que Grub 0.9 ne supporte pas. Faute de mieux, il reste dans AUR (pour ceux qui ne sont pas familiers d’Arch, c’est les contributions)…

    Ça y est, on tire à bout portant sur /etc/rc.conf, le fichier de configuration de ce qu'était Arch linux. Il est malade depuis un bout de temps. Cela a commencé insidieusement. Une variable a été supprimée, remplacée par un fichier de configuration indépendant. Puis une autre, et encore une autre, et ainsi de suite jusqu'à ce qu'il ne reste là-dedans que quelques lignes, comme en guise de souvenir.

    Et en passant à systemd, la parallélisation du démarrage fera gagner… le temps perdu à lire plus de fichiers.

    Il y a un moment (la Fedora de l’époque ne l’utilisait pas réellement), j’avais configuré systemd en mode natif (en gardant la possibilité de démarrer aussi avec rc.sysinit) ; ça marchait plutôt bien, jusqu’à ce que NetworkManager (qui vient aussi de chez Fedora/RedHat…) parte complètement en sucette avec. Vu la complexité de déboguer un tel problème avec systemd, j’ai choisi de m’en tenir à NetworkManager sans systemd, peut-être pas le meilleur des deux, mais celui dont j’avais vraiment besoin.
    Bon, j’ai réessayé de booter sur systemd il y a quelques jours, ça remarche avec NetworkManager…

    Au niveau temps de démarrage, j’avais chronométré, le démarrage prenait à peu près autant de temps à une seconde près, mais avec le système d’init BSD, je démarre pas mal de services en tâche de fond.

    « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

    • [^] # Re: Grub, rc.conf, systemd

      Posté par  . Évalué à 3.

      D’un autre côté, elle est plus claire que la dernière que j’ai vue, dont j’avais conclu qu’il y avait plein de fichiers de configuration… mais aucun qui soit prévu pour qu’on puisse configurer (!), entre le fichier généré qu’il ne faut pas modifier parce qu’il est généré et les autres fichiers qui peuvent permettre d’influencer la génération, mais pas de manière immédiate.

      Mais pourquoi veux-tu faire générer le fichier de grub2 si tu ne le veux pas ? Tu peux très bien l'écrire à la main comme avant, ça marche aussi et ce n'est pas plus compliquer qu'avant.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Grub

        Posté par  . Évalué à 2.

        Mais pourquoi veux-tu faire générer le fichier de grub2 si tu ne le veux pas ? Tu peux très bien l'écrire à la main comme avant, ça marche aussi et ce n'est pas plus compliquer qu'avant.

        J’y pense pour Arch, maintenant que j’ai vu cette doc.

        D’un autre côté, je vais avoir à configurer pour le boulot d’autres distributions avec Grub 2 et là je suis moins sûr de pouvoir échapper à la configuration automatique. À voir…

        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

    • [^] # Re: Grub, rc.conf, systemd

      Posté par  (site web personnel) . Évalué à 2.

      J’avoue que la page du wiki (.org) est extrêment longue, complexe, et confuse à ce sujet. Quand on lance un grub-mkconfig, on est mal parti. Cette page est, je trouve, plus claire, et ça montre bien que la complexité de grub2 est principalement un ajout dont on peut se passer…

      • [^] # Re: Grub, rc.conf, systemd

        Posté par  . Évalué à 3.

        J'abonde dans ce sens, grub 2 fournit un compilateur de conf qu'on n'est pas sommé d'utiliser.
        Tu peux :

        • écrire directement grub.cfg
        • écrire directement une conf custom strictement comme dans grub1 (ah non, linux remplace kernel, quel changement !) et laisser mkconfig copier direcetement ta conf dans le grub.cfg. mkconfig se charge des trucs de kikoos comme la couleur, etc. Mais comme c'est des trucs de kikoo, si tu en as besoin, pleins toi à toi même, ou édite /etc/default/grub (c'est vrai que oui, c'est une syntaxe atrocement complexe, ça définit des variables et ça leur assigne des valeurs :o ! Et puis, faut avouer que le nom des variables n'est pas du tout évocateur ! Ah wait. Si.)
    • [^] # Re: Grub, rc.conf, systemd

      Posté par  . Évalué à 9.

      D’un autre côté, elle est plus claire que la dernière que j’ai vue, dont j’avais conclu qu’il y avait plein de fichiers de configuration… mais aucun qui soit prévu pour qu’on puisse configurer (!), entre le fichier généré qu’il ne faut pas modifier parce qu’il est généré et les autres fichiers qui peuvent permettre d’influencer la génération, mais pas de manière immédiate.

      Je suis sous la diabolique Debian (Ah ! Ah ! Ah ! (rire maléfique)). Et sur mon système j'ai deux fichiers pour le configurer, mais attention c'est vraiment compliqué :

      • /etc/grub.d/40_custom pour le configurer (celle-ci s'ajoute aux configuration initiales)
      • /etc/default/grub Il permet d'avoir des configuration plus globale que dans le fichier précédent. Je tiens à souligner la complexité :
      $ grep -v "^#\|^$" /etc/default/grub
      GRUB_DEFAULT=0
      GRUB_TIMEOUT=5
      GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
      GRUB_CMDLINE_LINUX_DEFAULT="quiet"
      GRUB_CMDLINE_LINUX="init=/sbin/e4rat-preload"
      
      

      Si je modifie l'un de ces fichiers update-grub2 me génère le /boot/grub/grub.cfg ? C'est une mécanique complexe ? update-grub et update-grube2 ne font que lancer grub-mkconfig. Ce dernier est un script shell qui :

      • analyse les arguments
      • se configure en fonction de l'OS (notamment pour NetBSD et OpenBSD)
      • lance le grub-probe pour :
        • le fs sur le quel est installé la partie userland de grub
        • /boot
        • /
      • source /etc/grub.d/40_custom
      • configure la console
      • exécute chaque fichiers de /etc/grub.d/ et envoie leur sortie dans le grub.cfg

      C'est tellement compliqué qu'il suffit de lire le script.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Grub

        Posté par  . Évalué à 2.

        GRUB_DEFAULT=0
        GRUB_TIMEOUT=5
        GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
        GRUB_CMDLINE_LINUX_DEFAULT="quiet"
        GRUB_CMDLINE_LINUX="init=/sbin/e4rat-preload"
        

        Et si tu veux une autre entrée avec des options différentes et une troisième sans utiliser e4rat, au cas où tu aurais un jour un problème avec ?

        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

        • [^] # Re: Grub

          Posté par  . Évalué à 2.

          J'édite /etc/grub.d/40_custom :

          $ less /etc/grub.d/40_custom
          #!/bin/sh
          exec tail -n +3 $0
          # This file provides an easy way to add custom menu entries.  Simply type the
          # menu entries you want to add after this comment.  Be careful not to change
          # the 'exec tail' line above.
          menuentry 'Debian GNU/Linux, avec Linux 3.3.7-20120522 avec des options top moumoute !!!' --class debian --class gnu-linux --class gnu --class os {
              insmod part_msdos
              insmod ext2
              set root='(hd0,msdos2)'
              search --no-floppy --fs-uuid --set 348f2f55-a3ec-450f-9968-143f0e0b7825
              linux   /boot/vmlinuz-3.3.7-20120522 root=UUID=348f2f55-a3ec-450f-9968-143f0e0b7825 ro init=/sbin/e4rat-preload my_option1 my_option1 my_option1
              initrd  /boot/initrd.img-3.3.7-20120522
          }
          menuentry 'Debian GNU/Linux, avec Linux 3.3.7-20120522 sans e4rat' --class debian --class gnu-linux --class gnu --class os {
              insmod part_msdos
              insmod ext2
              set root='(hd0,msdos2)'
              search --no-floppy --fs-uuid --set 348f2f55-a3ec-450f-9968-143f0e0b7825
              linux   /boot/vmlinuz-3.3.7-20120522 root=UUID=348f2f55-a3ec-450f-9968-143f0e0b7825 ro init=/sbin/init quiet
              initrd  /boot/initrd.img-3.3.7-20120522
          }
          
          

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Grub

            Posté par  . Évalué à 4.

            Et quand tu changes de version du noyau, il faut que tu remettes à jour ce script à la main.
            Avant, le script de Debian pour Grub 0.9 te le faisait pour toutes les entrées, non ?

            Le problème avec Grub 0.9, c’était que chaque distrib devait faire sa tambouille pour ajuster le fichier de config lors des mises à jour du noyau.

            Grâce à Grub 2 (enfin les scripts qui viennent avec), c’est pris en charge directement… mais partiellement seulement.

            Et pourtant la solution existait sur certaines distributions et était simple : que l’installation du noyau maintienne un lien nommé par exemple vmlinuz sur le dernier noyau et vmlinuz.old sur le précédent (il suffit de renommer l’ancien vmlinuz ; je passe sur la version moins tapette et encore plus simple d’Arch, qui considère qu’un seul noyau suffit).

            Les distributions qui utilisent cette solution devraient assumer pleinement et ne pas installer le script de génération de Grub 2, complication inutile pour elles.

            Allez, un nlien dans le thème pour la route.

            « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

            • [^] # Re: Grub

              Posté par  . Évalué à 1.

              Et quand tu changes de version du noyau, il faut que tu remettes à jour ce script à la main.
              Avant, le script de Debian pour Grub 0.9 te le faisait pour toutes les entrées, non ?

              Avant je perdais tout et il fallait que je me souvienne de mes modif' (ou que je maintienne un diff).

              Le problème avec Grub 0.9, c’était que chaque distrib devait faire sa tambouille pour ajuster le fichier de config lors des mises à jour du noyau.

              On est d'accord.

              Grâce à Grub 2 (enfin les scripts qui viennent avec), c’est pris en charge directement… mais partiellement seulement.

              C'est déjà un mieux, non ?

              Et pourtant la solution existait sur certaines distributions et était simple : que l’installation du noyau maintienne un lien nommé par exemple vmlinuz sur le dernier noyau et vmlinuz.old sur le précédent (il suffit de renommer l’ancien vmlinuz ; je passe sur la version moins tapette et encore plus simple d’Arch, qui considère qu’un seul noyau suffit).

              La solution Arch est profondément idiote. Il m'arrive de m'amuser avec de la compilation de noyau. Je crée des paquets je les installe, je reboot ça marche super, ça marche pas je boot sur le précédent.

              Avoir 2 noyaux ça peut être limite. Personnellement j'aime bien savoir sur le quel je boot. Me dire "le dernier" et "le précédent" ça ne me plaît pas.

              En général j'ai 3 noyaux d'installé, celui de la distrib', le dernier que j'ai coupilé et le précédent que je garde jusqu'à ce que je compile le suivant. Au final j'ai un 2.6.32, un 3.2 et un 3.3. C'est un usage particulier de gars tordu ? Peut être mais pour mon cas d'usage je suis content de ce que propose par défaut ma distrib.

              Pour ton cas d'usage grub2 s'adapte facilement :

              #!/bin/sh
              
              LINUX_VERSION=$(...) # ici tu cherche le numéros de version de ton dernier noyau
              # sur ma Debian je ferrais ça :
              # ls /boot/vmlinuz-* | cut -c 15- | sort | tail -n1
              cat <<EOF
              menuentry 'Debian GNU/Linux, avec Linux ${LINUX_VERSION} sans e4rat' --class debian --class gnu-linux --class gnu --class os {
                  insmod part_msdos
                  insmod ext2
                  set root='(hd0,msdos2)'
                  search --no-floppy --fs-uuid --set 348f2f55-a3ec-450f-9968-143f0e0b7825
                  linux   /boot/vmlinuz-${LINUX_VERSION} root=UUID=348f2f55-a3ec-450f-9968-143f0e0b7825 ro init=/sbin/init quiet
                  initrd  /boot/initrd.img-${LINUX_VERSION}
              }
              EOF
              
              

              à mettre dans un fichier de /etc/grub.d/. Ça pourrait être donné par dans ta distrib'.

              Au final par rapport à ce qu'il y avait avant : un fichier unique qui a des conflits entre nos modifications et celles du système et une solution différente par distribution. On a un système qui pose des bases qui gère 80% des utilisations et qui peut facilement s'adapter par les distributions ou l'utilisateur pour des cas d'usage particulier sans aller à l'encontre de l'upstream. Il est même possible de remonter à l'upstream c'est scripts et amélioration.

              Franchement qu'est ce qu'il faudrait de plus ?

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Grub

                Posté par  . Évalué à 1.

                Avant je perdais tout et il fallait que je me souvienne de mes modif' (ou que je maintienne un diff).

                Ah quand même !
                Debian trouve toujours le moyen de me surprendre… mais pas souvent dans le bon sens.
                Fedora gérait ça correctement.

                La solution Arch est profondément idiote. Il m'arrive de m'amuser avec de la compilation de noyau. Je crée des paquets je les installe, je reboot ça marche super, ça marche pas je boot sur le précédent.

                Ça fait des années que j’ai arrêté de compiler mes noyaux.
                Mais si je le faisais encore, même si je leur faisait un paquet, je ferai en sorte que le résultat s’appelle vmlinux-user ou quelque chose du genre. Ça suffirait pour qu’en cas de problème, je puisse démarrer sur le noyau standard et downgrader le mien.

                « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

                • [^] # Re: Grub

                  Posté par  . Évalué à 2.

                  Ah quand même !
                  Debian trouve toujours le moyen de me surprendre… mais pas souvent dans le bon sens.
                  Fedora gérait ça correctement.

                  Ne prends pas mon expérience comme parole d'évangile. Je ne savais peut être pas me servir de grub 0.97. Maintenant j'ai pris le temps de lire 4 petits scripts et de comprendre comment ça doit fonctionner.

                  Ça fait des années que j’ai arrêté de compiler mes noyaux.
                  Mais si je le faisais encore, même si je leur faisait un paquet, je ferai en sorte que le résultat s’appelle vmlinux-user ou quelque chose du genre. Ça suffirait pour qu’en cas de problème, je puisse démarrer sur le noyau standard et downgrader le mien.

                  On s'est mal compris je pensais que tu parlais de vraiment virer les autres linux. Mes noyaux ont un le numéro de version du noyau, la date et un nom parlant pour moi.

                  Mais mis à part ça pense-tu encore que grub2 va te virer des fonctionnalités ?

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                  • [^] # Re: Grub

                    Posté par  . Évalué à 2.

                    Ne prends pas mon expérience comme parole d'évangile. Je ne savais peut être pas me servir de grub 0.97.

                    Rien à voir : il ne faisait pas ce boulot, il se contentait de prendre en compte son fichier de configuration. C’est le script post-install du paquet du noyau qui s’occupait de sa mise à jour.

                    Mais mis à part ça pense-tu encore que grub2 va te virer des fonctionnalités ?

                    Sous Arch, non : il me suffit de ne pas utiliser le script de génération de la configuration.

                    Sous Fedora oui, le script post-install du noyau de Fedora pour Grub 0.9 couvrait 95 % des fonctionnalités potentiellement utiles (je parle au passé, parce qu’il me semble que la dernière version est passée à Grub 2). Le script de génération de Grub 2, seulement 80 %. Et pour le reste, il faut trouver un moyen plus compliqué de le faire, puisque le fichier de configuration est susceptible de sauter complètement à chaque mise à jour.

                    « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

                    • [^] # Re: Grub

                      Posté par  . Évalué à 3.

                      Et sinon tu as encore des arguments ? Parce que simplement dire que c'est plus compliqué alors que je viens de poster une solution à chaque cas d'usage que tu as décrit sans y passer beaucoup de temps c'est assez ironique.

                      Comme je l'ai déjà dit on passe d'une tambouille absolument pas kiss (la modification du fichier probablement à coup d'une armée de regex) et spécifique à chaque distribution à un système bien plus souple, bien plus fiable et upstream. Il ne demande qu'à être hacké.

                      Si tu cherches de la simplicité d'utilisation plutôt que de la souplesse et du kiss, ubuntu et mandriva sont faites pour toi pas arch. :-)

                      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                      • [^] # Re: Grub

                        Posté par  . Évalué à 0.

                        Et sinon tu as encore des arguments ? Parce que simplement dire que c'est plus compliqué alors que je viens de poster une solution à chaque cas d'usage que tu as décrit sans y passer beaucoup de temps c'est assez ironique.

                        Et si je veux conserver un noyau particulier dans /boot, mais sans qu’une entrée lui soit crée ?
                        Et si je veux changer l’ordre des entrées du menu sur une machine en multiboot ?
                        Le moyen que j’ai trouvé au moment était de modifier les priorités dans /etc/grub.d, mais je ne suis pas certain que ça survive à la mise à jour du paquet de Grub.

                        Peut-être encore des problèmes auxquels tu trouverais une solution, sauf qu’avec un fichier de configuration fixe, c’est immédiat, on édite simplement le fichier, il n’y a pas à chercher de solution.
                        À un certain stade, la conclusion logique d’avoir à trouver autant de solutions, c’est que grub-mkconfig est le problème.

                        Comme je l'ai déjà dit on passe d'une tambouille absolument pas kiss (la modification du fichier probablement à coup d'une armée de regex) et spécifique à chaque distribution à un système bien plus souple, bien plus fiable et upstream. Il ne demande qu'à être hacké.

                        Franchement, je suis sûr que j’aurais fait plus vite à faire un script qui fait à coups de regex le même boulot que celui de Fedora pour Grub 0.9 qu’à maîtriser la logique tordue de grub-mkconfig avec plusieurs fichiers de configuration de plusieurs niveaux et plein d’automatismes qui ne sont pas tous prévus pour être paramétrables.

                        Si tu cherches de la simplicité d'utilisation plutôt que de la souplesse et du kiss, ubuntu et mandriva sont faites pour toi pas arch. :-)

                        Merci, je m’arrange bien avec Arch, ils ont même réussi à faire une doc utilisable pour Grub 2, c’est dire. La distrib qui me donne des boutons, c’est Debian : comme grub-mkconfig, elle aime bien apporter des solutions compliquées à des problèmes que je préférerais qu’une distribution ne prenne pas en charge du tout.

                        Quant à ta définition de KISS, je n’ai pas la même.
                        Si c’est KISS, le principe doit pouvoir se décrire succinctement.
                        Exemples :
                        – « Le fichier de configuration est fixe », c’est KISS.
                        – « Le fichier de configuration est mis à jour en même temps que le noyau avec une entrée de menu qui reprend les paramètres de la précédente », c’est un peu moins KISS.
                        – pour grub-mkconfig… je sèche.

                        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

                        • [^] # Re: Grub

                          Posté par  . Évalué à 1.

                          Peut-être encore des problèmes auxquels tu trouverais une solution, sauf qu’avec un fichier de configuration fixe, c’est immédiat, on édite simplement le fichier, il n’y a pas à chercher de solution.

                          Ça manque de flexibilité et ça déporte un bout de la conf de ta machine dans /boot. Si vraiment tu veux avoir quelque chose en dur pourquoi ne pas rendre non-executable tout les fichiers de /etc/grub.d pour ne garder que celui qui t'intéresse. Si tu as quelque chose de fixe parfait, si tu veux quelque chose d'un peu dynamique un appel à grub-mkconfig et c'est terminé.

                          Quand je dis que ça ne demande que ça être hacké.

                          Franchement, je suis sûr que j’aurais fait plus vite à faire un script qui fait à coups de regex le même boulot que celui de Fedora pour Grub 0.9 qu’à maîtriser la logique tordue de grub-mkconfig avec plusieurs fichiers de configuration de plusieurs niveaux et plein d’automatismes qui ne sont pas tous prévus pour être paramétrables.

                          Plus vite peut être, plus fiable, plus maintenable, plus portable à travers les distributions et OS, je ne sais pas.

                          ils ont même réussi à faire une doc utilisable pour Grub 2, c’est dire

                          Ça n'a jamais était fais avant c'est clair : http://wiki.debian-facile.org/manuel:grub2
                          Pour la solution de rendre non executable les fichiers de /etc/grub.d, c'est sur l'un des doc pointé par le site officiel que j'ai trouvé ça (que j'ai trouvé grâce au README du paquet).

                          La distrib qui me donne des boutons, c’est Debian : comme grub-mkconfig, elle aime bien apporter des solutions compliquées à des problèmes que je préférerais qu’une distribution ne prenne pas en charge du tout.

                          Compliquée non, sophistiquée peut être. Il faut prendre 5 minutes pour lire un peu la doc (je croyais les archers fiers de lire la doc eux), pour comprendre comment ça fonctionne de manière précise.

                          Quant à ta définition de KISS, je n’ai pas la même.

                          KISS étant un buzzword à peu près du même acabit que cloud ou web2.0, j'ai le droit de mettre ce que je veux derrière :)

                          Exemples :
                          – « Le fichier de configuration est fixe », c’est KISS.
                          – « Le fichier de configuration est mis à jour en même temps que le noyau avec une entrée de menu qui reprend les paramètres de la précédente », c’est un peu moins KISS.
                          – pour grub-mkconfig… je sèche.

                          Le fichier de configuration est généré par la sortie standard de tout les scripts de /etc/grub.d et paramétré par /etc/default/grub lors d'installation de noyau.
                          Tu trouve que c'est une torture mais ça permet à un tas de monde de faire précisément ce qu'ils veulent. Pour grub-mkconfig, j'ai décris précisément son fonctionnement, c'est de la mauvaise fois. Et si tu ne fais pas l'effort de lire ce que j'écris je vois pas pourquoi je continuerais, un jour peut être que tu lira la doc et tu essaiera de comprendre comment s'en servir sans apriori (tu n'aura alors plus besoin de quelqu'un qui te met le doigt sur les solutions).

                          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                          • [^] # Re: Grub

                            Posté par  . Évalué à 2.

                            Ça manque de flexibilité

                            Hein ? Pouvoir éditer le fichier de configuration et mettre tout ce que tu veux dedans, ça manque de flexibilité ???

                            et ça déporte un bout de la conf de ta machine dans /boot.

                            Oulala ! C’est vraiment affreux !
                            Fedora avait pensé aux maniaques du rangement : /boot/grub/menu.lst était un lien vers /etc/grub.conf (bon, peut-être pas si tu fais une partition /boot séparée).

                            Compliquée non, sophistiquée peut être. Il faut prendre 5 minutes pour lire un peu la doc (je croyais les archers fiers de lire la doc eux), pour comprendre comment ça fonctionne de manière précise.

                            Ouais, ben la fois où un utilisateur m’a demandé si je pouvais fixer l’ordre des entrées de son Grub 2 sur un portable perso, je n’allais pas y passer 3 heures. J’ai regardé la doc d’Ubuntu 5 minutes… et j’ai préféré regarder le contenu du paquet Grub. Solution rapide : j’ai modifié les priorités des scripts dans /etc/grub.d.

                            Si vraiment tu veux avoir quelque chose en dur pourquoi ne pas rendre non-executable tout les fichiers de /etc/grub.d pour ne garder que celui qui t'intéresse.

                            C’est comme la solution que j’ai mise en place pour mon utilisateur, ça ne résiste pas forcément à une mise à jour du paquet Grub. J’ai considéré que ça devait arriver moins souvent que les mises à jour du noyau, mais ce n’est pas pleinement satisfaisant pour autant.

                            Tu trouve que c'est une torture mais ça permet à un tas de monde de faire précisément ce qu'ils veulent.

                            Allez, le conseil de la doc officielle de Grub 2 pour la question de l’ordre du menu : grub-mkconfig does have some limitations. While adding extra custom menu entries to the end of the list can be done by editing /etc/grub.d/40_custom or creating /boot/grub/custom.cfg, changing the order of menu entries or changing their titles may require making complex changes to shell scripts stored in /etc/grub.d/. This may be improved in the future. In the meantime, those who feel that it would be easier to write grub.cfg directly are encouraged to do so (see Booting, and Shell-like scripting), and to disable any system provided by their distribution to automatically run grub-mkconfig.

                            Et si tu ne fais pas l'effort de lire ce que j'écris je vois pas pourquoi je continuerais

                            Effectivement, tu n’as pas compris mon point. Ce n’est pas de chercher la solution à mes problèmes. C’est juste de montrer qu’il y en a un certain nombre qui peuvent se poser.
                            Hors ce sont des problèmes créés, la manière la plus simple de les résoudre est de ne pas les créer !

                            Autant grub-mkconfig est tout-à-fait légitime à l’installation du système pour créer la configuration de base, autant regénérer la configuration à chaque mise-à-jour du noyau est disproportionné. La solution utilisée sur les Mandrake il y a plus de 10 ans résout la question de la mise-à-jour de manière pleinement satisfaisante et beaucoup plus simple.

                            Tout le temps passé à résoudre des problèmes créés et évitables est du temps qu’on ne passe pas à résoudre des problèmes réels ou à faire quoique ce soit d’autre de plus intéressant.

                            « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

                            • [^] # Re: Grub

                              Posté par  . Évalué à 2.

                              Effectivement, tu n’as pas compris mon point. Ce n’est pas de chercher la solution à mes problèmes. C’est juste de montrer qu’il y en a un certain nombre qui peuvent se poser.
                              Hors ce sont des problèmes créés, la manière la plus simple de les résoudre est de ne pas les créer !

                              Et toi tu refuse de voir que des problèmes il en existait avant qui sont corrigés ou qui peuvent être solutionnés avec le système actuel. J'ai montré un tas de solution pour faire précisément ce que tu veux de grub2 (aller encore un chmod -x /etc/grub.d et paf plus de modifications du fichier de conf quoi qu'il arrive (sauf si ton gestionnaire de paquet écrase les fichiers que tu as toi même modifiés, mais c'est un problème du gestionnaire de paquet (note que je ne sais pas ce qu'il en est pour apt, mais avec une diversion on peut empêcher toutes mises à jours de ces fichiers)). Je veux bien que tu ne parle pas de tes problèmes personnels, mais tu n'a pas encore trouvé de cas d'usage qui ne puisse pas être retrouvé. Si tu aime beaucoup le fameux script de chez Fedora, tu peut l'adapter pour la nouvelle syntaxe et le placer dans /etc/grub.d. La doc parle peut être de limitation, mais je pense qu'il parle des scripts upstream. Si tu prend quelques minutes pour faire ton script tu obtiens ce que tu veux (ou en tout cas je n'ai ni rencontré, ni lu sur interne de cas qui ne pouvait pas se faire).

                              Le problème comme je l'ai déjà dis, c'est que tu pars avec un aprioris. Comme tu ne vois pas les cas d'usages qui sont adressé (alors que j'en ai présenté et nous sommes d'accord que la situation des scripts maison de chaque distribution était un problème), tu n'a pas l'air de chercher à voir comment il fonctionne pour l'utiliser.

                              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                              • [^] # Re: Grub

                                Posté par  . Évalué à 2.

                                Et toi tu refuse de voir que des problèmes il en existait avant qui sont corrigés ou qui peuvent être solutionnés avec le système actuel.

                                Il en existait avant sous Debian voire sous Fedora.
                                Quels sont ceux que tu vois qui n’étaient pas plus faciles à résoudre avec la solution de Mandriva ?
                                La prise en charge automatique de plus de deux noyaux dans le choix de démarrage ? Combien de personnes en ont-elles réellement besoin (franchement ça fait des années que je n’ai pas vu de cas où le noyau courant ne permette pas de démarrer) ? Y en a-t-il parmi celles-ci pour lesquelles il ne soit pas facile d’ajouter une entrée dans le fichier de configuration ?

                                (aller encore un chmod -x /etc/grub.d et paf plus de modifications du fichier de conf quoi qu'il arrive

                                As-tu essayé ?
                                Est-ce qu’on ne se retrouve pas plutôt avec un fichier de configuration tronqué ?
                                Qui plus est, après, il faut gérer soi-même la mise à jour du fichier de configuration sur les distributions dont le fichier du noyau contient le numéro de version.

                                (sauf si ton gestionnaire de paquet écrase les fichiers que tu as toi même modifiés, mais c'est un problème du gestionnaire de paquet (note que je ne sais pas ce qu'il en est pour apt,

                                Avec rpm, il y a les fichiers considérés comme des fichiers de configuration, qui sont conservés, et les autres qui sont écrasés. Il me semble que c’est pareil avec pacman, mais j’ai moins de recul pour en être sûr. Cela dit, j’entre toutes mes modifications dans un gestionnaire de versions, ça me permet de repérer d’éventuels problèmes.
                                En tout cas, les droits des répertoires faisant partie d’un paquet sont restaurés à la mise à jour et je ne suis pas sûr que la différence de droits saute aux yeux avec un gestionnaire de versions.

                                « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

                        • [^] # Re: Grub

                          Posté par  . Évalué à 0. Dernière modification le 26 juillet 2012 à 20:49.

                          Franchement, je suis sûr que j’aurais fait plus vite à faire un script qui fait à coups de regex le même boulot que celui de Fedora pour Grub 0.9 qu’à maîtriser la logique tordue de grub-mkconfig avec plusieurs fichiers de configuration de plusieurs niveaux et plein d’automatismes qui ne sont pas tous prévus pour être paramétrables.

                          Ça tombe bien, tu peux. Les machins dans /etc/grub.d/ sont des scripts et tu peux très bien y mettre un 99_my_ugly_regex qui mouline comme un sale pour faire ce que le script de ta distrib faisait avec Grub 1.

                          Alors heureux ?

                          Amuse toi bien avec ton pseudo KISS plein de regex alors que des scripts plus simples font déjà tout pour te simplifier la vie.

                          • [^] # Re: Grub

                            Posté par  . Évalué à 1.

                            Cherche pas c'est différent de grub1 donc saymal.

                            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                          • [^] # Re: Grub

                            Posté par  . Évalué à 1.

                            Ça tombe bien, tu peux. Les machins dans /etc/grub.d/ sont des scripts et tu peux très bien y mettre un 99_my_ugly_regex qui mouline comme un sale pour faire ce que le script de ta distrib faisait avec Grub 1.

                            Je n’ai jamais dit que je considérais ça comme une bonne solution, c’est juste une autre mauvaise solution, mais bien plus pratique, existant sur une distribution.

                            À la base, ce qu’on veut, c’est pouvoir conserver plusieurs noyaux, démarrer le dernier par défaut, garder la possibilité de démarrer le précédent en secours (c’est largement suffisant pour l’utilisateur de base), tout en laissant la marge à l’utilisateur avancé de démarrer un noyau de son choix.
                            Vous voyez autre chose d’utile ?

                            La solution simple existait déjà il y a plus de 10 ans sur Mandrake : des liens sur le noyau courant et le précédent. Ça fait deux commandes mv et deux commandes ln (il y a aussi l’init ram disk) dans le script post-install du noyau.
                            Avec ça, il n’y a plus besoin de modifier la configuration de démarrage. Quant aux utilisateurs avancés, ajouter une entrée de menu pour leur noyau à eux n’est pas difficile (il suffit d’adapter une entrée existante dans la configuration), ils peuvent l’ajouter sans problème où ils veulent et sans risque d’avoir à le refaire, puisque la configuration n’a pas à être regénérée, et s’ils l’ont mis par défaut, ça ne risque pas de changer parce qu’à la mise à jour du noyau officiel grub-mkconfig n’aura pas classé les noyaux dans le même ordre.

                            Évidemment, reprendre une bonne idée de Mandriva, pour Fedora/RedHat, ce serait un déshonneur et pour un debianiste, la honte.

                            Amuse toi bien avec ton pseudo KISS plein de regex alors que des scripts plus simples font déjà tout pour te simplifier la vie.

                            C’est de l’humour, c’est ça ?

                            « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

                            • [^] # Re: Grub

                              Posté par  . Évalué à 2.

                              Évidemment, reprendre une bonne idée de Mandriva, pour Fedora/RedHat, ce serait un déshonneur et pour un debianiste, la honte.

                              Ils ont tous repris la solution upstream. Donc si tu veux tirer sur quelqu'un choisi un peu mieux ta cible.

                              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                              • [^] # Re: Grub

                                Posté par  . Évalué à 2.

                                Ils ont tous repris la solution upstream. Donc si tu veux tirer sur quelqu'un choisi un peu mieux ta cible.

                                upstream fournit un script pour générer la configuration de Grub 2.
                                Il n’oblige pas à le relancer à chaque mise à jour du noyau. C’est le choix de la distribution de ne pas utiliser un nom fixe pour son noyau.

                                D’autre part, ça fait plus de 10 ans que la solution de Mandriva existe.
                                Fedora a préféré une solution plus complexe. Debian n’a pas vu où était le problème à continuer d’écraser la configuration et avec les modifications qui ont pu être faites par l’utilisateur.

                                Ce sont leurs choix de l’époque, ça n’a rien à voir avec ce que propose maintenant upstream, tant de temps après.

                                « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

        • [^] # Re: Grub

          Posté par  (site web personnel) . Évalué à 2.

          Et si tu veux une autre entrée avec des options différentes et une troisième sans utiliser e4rat, au cas où tu aurais un jour un problème avec ?

          Tu as les fichiers /etc/grub.d/*_custom dans lesquels tu peux rajouter les entrées que tu veux

          Le numéro (10, 20, .., 99) sert juste à définir l'ordre dans lequel cela apparaîtra dans le menu

  • # apprentissage d'un archer

    Posté par  . Évalué à -5.

    un petit troll pour la route:
    les Archers vont rée-apprendre a utiliser une distro comme les autres, j'utilise arch et debian et maintenant, je trouve qu'il y a de moins en moins de différence au niveau du grub, ouppsss arch est passer en grub2. ;)

    Merci aux personnes qui mon aidé a trouvé des solutions pour essayer d’écrire sans faute d’orthographe.

  • # Vieux barbus

    Posté par  . Évalué à -5.

    Oh, un troll de vieux barbu ! Et oui, c'etait mieux avant ! Evoluer, c'est le mal !

    Je pense avoir bien resume l'attitude generale de ce journal…

  • # L'immobilisme c'est mal.

    Posté par  . Évalué à 9.

    Tu critiques le changement, sans avoir même pris la peine de voir si les outils qui remplacent ce qui disparait vont te convenir ou pas.
    Tu dis "ce que j'utilisais n'existe plus, et comme ce qui est neuf est différent, ce qui est neuf est mauvais/ne me plait pas."

    Excuse moi, mais je trouve que ton raisonnement est puéril, et trollesque. Dans ton journal il n'y a pas une seule critique construite des nouveaux outils. Mais critiquer le changement, ça ne te semble pas absurde ? Tu crois qu'on ne peut pas changer en mieux ? Tu crois qu'on devrait garder indéfiniment des outils qui marchent et ne pas tenter d'avoir des outils qui marchent mieux ?

    Tu peux ne pas aimer systemd, grub2, gnome3, etc. Mais c'est une autre histoire. POur ne pas aimer, il faut avoir testé en conditions réelles pendant un petit moment, et s'être habitué au changement, ton rejet de tout ce qui est neuf est ridicule.

    En outre tu sembles dire que tu es pris en otage, que tu es obligé de changé. Bah, en temps qu'utilisateur, oui c'est le cas. Il faudrait commencer à comprendre que dans le monde de l'opensource, quand les projets sont développés par des bénévoles, l'utilisateur n'a AUCUN droit. Il n'a que ce que les développeurs veulent bien lui donner. Il faut comprendre aussi que les développeurs ont aussi leur part dans la décision. Un truc qui peut sembler acceptable pour l'utilisateur peut sembler horrible à maintenir à un développeur. Exemple, gnome-panel. Ou dans une moindre mesure, il paraît, grub1.

    Si les développeurs décident de donner autre chose, tu dois t'y plier, utiliser autre chose, ou alors devenir développeur de l'ancien, tu n'as que ces 3 choix. Si ton opinion a quelque poids (aka, si tu ne passes pas ton temps à râler mais que tu l'utilise à t'investir dans le projet), tu parviendras peut être à influencer la décision, mais pas pour des choix aussi importants que ceux là.

      La question est plutôt de savoir où iront ceux qui trouvent que c'est moins bien.
    
    

    Tu sembles croire qu'il n'y a aucune alternative. C'est faux, il y a :

    • le fork
    • {open,Net,Free,DragonFly,PC}BSD
    • solaris (openIdianna)
    • d'autres OS, d'autres distributions comme slackware ou crux qui risquent de resister plus longtemps
    • [^] # Re: L'immobilisme c'est mal.

      Posté par  . Évalué à 2.

      D'autant plus que la futur PC-BSD embarque un lanceur de linux (limité à debian squeeze pas à arch actuellement) dans une jail.
      Le futur est dans BSD ?? La période transitoire peut commencer ;-)

      Bisettes tout le monde.

    • [^] # Résister plus longtemps

      Posté par  . Évalué à 4.

      Heu… Résister plus longtemps c'est jamais une solution. Si les choses changent dans la mauvaise direction, il faut se sortir les doigts du cul et coder un truc qui va dans la bonne.

      • [^] # Re: Résister plus longtemps

        Posté par  . Évalué à 5.

        Non mais moi je m'en fou, je suis parfaitement satisfait par la direction prise.

        Sauf pour journald, qui est une merde indescriptible incapable de fonctionner correctement dans des conditions à peine éloignées de l'idéal (exemple, un OOps, ou autre jolie erreur). Un système de log non robuste, ça sert à quoi ? En général, quand tu veux des logs, c'est pour les erreurs, pas pour lire que tout marche bien en détail.

        • [^] # Re: Résister plus longtemps

          Posté par  . Évalué à 1.

          C'était juste une règle générale hein. Je ne visais personne :p

        • [^] # Re: Résister plus longtemps

          Posté par  . Évalué à 5.

          Sauf pour journald, qui est une merde indescriptible incapable de fonctionner correctement dans des conditions à peine éloignées de l'idéal (exemple, un OOps, ou autre jolie erreur). Un système de log non robuste, ça sert à quoi ? En général, quand tu veux des logs, c'est pour les erreurs, pas pour lire que tout marche bien en détail.

          Il y a des distributions qui l'ont déjà intégrées par défaut ?

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Résister plus longtemps

            Posté par  . Évalué à -1.

            Il y a des distributions qui l'ont déjà intégrées par défaut ?

            probablement toutes (parce que c'est nouveau, donc bien car l'immobilisme c'est le mal, et que ça vient de chez Lennart Poettering), sauf Slackware.

            Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

            • [^] # Re: Résister plus longtemps

              Posté par  . Évalué à 2.

              J'en suis pas aussi sûr étant donné que c'est vraiment très nouveau.

              Le but c'est pas de distribuer des softs en version pré alpha non plus …

              • [^] # Re: Résister plus longtemps

                Posté par  (site web personnel) . Évalué à 3.

                C'est fournit avec systemd donc oui…

                Ici sous Arch, j'ai effectivement journald, enfin j'avais parce que sur un laptop cela ne me sert à rien…

                • [^] # Re: Résister plus longtemps

                  Posté par  (site web personnel) . Évalué à 4.

                  Bah c'est que chez Arch vous aimez Lennart alors, parce que même pour Fedora 18 journald a été recalé.

                  Ou alors Arch package n'importe quoi.

                  Ou alors t'installes n'importe quoi. Ou alors tu dis n'importe quoi.

          • [^] # Re: Résister plus longtemps

            Posté par  . Évalué à 2.

            je ne sais pas, peut être Fedora.

    • [^] # Re: L'immobilisme c'est mal.

      Posté par  . Évalué à 3.

      Non, il n’y a pas d’alternative.

      • le fork

      Pas les compétences ni les moyens techniques ni le temps.

      Je suis administrateur système (et accessoirement réseau), pas développeur, chacun son boulot.

      • {open,Net,Free,DragonFly,PC}BSD
      • solaris (openIdianna)
      • d'autres OS, d'autres distributions comme slackware ou crux qui risquent de resister plus longtemps

      Tu connais une seule distro (parmi celle que tu as cité ou non) qui intègre un gestionnaire de paquet comme pacman ? Rien que ça, ça fait toute la force d’Arch et tout ce pourquoi, même déçu, même en ayant l’air d’être sous Debian, je resterai un Archer.

      Je vais prendre un exemple que tu pourras comprendre : si les Français avaient voté Marine aux dernières présidentielles, tu serai partit ou tu aurai essayé de faire changer les choses ?

      • [^] # Re: L'immobilisme c'est mal.

        Posté par  . Évalué à 4.

        Je suis administrateur système (et accessoirement réseau), pas développeur, chacun son boulot.

        Je ne suis pas sur que la création d'une distribution soit plus du dév que de l'admin. Ensuite beaucoup de dev du libre ne sont dev de formation ni de métier.

        Tu connais une seule distro (parmi celle que tu as cité ou non) qui intègre un gestionnaire de paquet comme pacman ?

        C'est à dire ? Parce que dis comme ça, non aucun n'intègre pacman. Mais c'est quoi qui te plaît dedans ?

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: L'immobilisme c'est mal.

          Posté par  . Évalué à 1. Dernière modification le 25 juillet 2012 à 13:30.

          C'est à dire ? Parce que dis comme ça, non aucun n'intègre pacman. Mais c'est quoi qui te plaît dedans ?

          C'est plus la façon de créer ses propres paquets qui est géniale (même si arch n'a rien inventé de ce côté là). Car dans le fond, la vitesse, la gestion des dépendances … tous les bons gestionnaires de paquets le fond.

          Mais modifier rapidement et facilement le moindre paquet et la capacité à downgrader après une merde, debian, fedora, ubuntu et suse ont du retard.

          1. Faire son PKGBUILD : entre ABS et AUR il y en a des tas à dispo. Il suffit de changer parfois une ligne ou 2 pour avoir un PKGBUILD customisé aux oignons.
          2. "makepkg" (qui créé le paquet pour pacman)
          3. "pacman -U " : c'est installé proprement !

          Là ou certaines distrib, l'upgrade d'une version fait exploser le nombre de threads sur les forums car tout explose (ubuntu), sur Arch on peut déjà downgrader un gnome ou un kernel en toute confiance.

          D'autres (debian) proposent un système similaire pour se créer des paquets perso mais c'est pas aussi bien foutu.

          Pour finir

          Il faut mettre un frein à l'immobilisme.

          • [^] # Re: L'immobilisme c'est mal.

            Posté par  . Évalué à 2.

            Mais modifier rapidement et facilement le moindre paquet et la capacité à downgrader après une merde, debian, fedora, ubuntu et suse ont du retard.

            Des downgrade j'en fais des tas du système complet sous Debian ça marche très bien. Après pour un paquet donné après un problème survenu sur celui-ci,ce n'est pas forcément pratique (il faut aller chercher dans le cache ou le trouver sur un dépôt apt-cache policy est utile pour ça).

            Sinon tu as frugalware qui utilise pacman (ou un fork plutôt je crois).

            Faire son PKGBUILD : entre ABS et AUR il y en a des tas à dispo. Il suffit de changer parfois une ligne ou 2 pour avoir un PKGBUILD customisé aux oignons.

            pkgsrc n'est pas aussi bien pour ça ?

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: L'immobilisme c'est mal.

              Posté par  . Évalué à 1.

              Si, d'ailleurs, ABS est inspiré de pkgsrc. Sauf que l'avantage, c'est que le gestionnaire de paquets binaires est mieux. pkg_radd et ses déclinaisons n'est pas tip/top.

              Quand a pkgin, il n'a pas la qualité de pacman (encore ?).

              • [^] # Re: L'immobilisme c'est mal.

                Posté par  . Évalué à 2.

                Quand a pkgin, il n'a pas la qualité de pacman (encore ?).

                J'allais répondre sur pkgin. Il faut voir l'age des gestionnaires, pkgin est très récent (et a peut être moins d'utilisateurs), mais plus il seras utilisé plus il seras complet.

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: L'immobilisme c'est mal.

              Posté par  . Évalué à 1.

              Sinon tu as frugalware qui utilise pacman (ou un fork plutôt je crois).

              Sauf qu’ils sont passés à systemd depuis longtemps :(

          • [^] # Re: L'immobilisme c'est mal.

            Posté par  . Évalué à -2.

            C'est plus la façon de créer ses propres paquets qui est géniale
            avec pacman tu ne crée pas les paquets ils sont deja crée pour ta machine ce sont des binaires, il n y a pas de sources comme sur gentoo, debian et autre ;)

            D'autres (debian) proposent un système similaire pour se créer des paquets perso mais c'est pas aussi bien foutu.
            a toi de le modifier a ta guise pour qu il te fasse ce que tu demande ;)

            Il faut mettre un frein à l'immobilisme.
            et c est pour cela que les archers rale apres les grand chamboulement qu'il vienne de subir ;)

            Merci aux personnes qui mon aidé a trouvé des solutions pour essayer d’écrire sans faute d’orthographe.

      • [^] # Re: L'immobilisme c'est mal.

        Posté par  . Évalué à 2.

        Tu connais une seule distro (parmi celle que tu as citées ou non) qui intègre un gestionnaire de paquet comme pacman ?

        Il y a Frugalware.

    • [^] # Re: L'immobilisme c'est mal.

      Posté par  (site web personnel) . Évalué à 2.

      Tu sembles croire qu'il n'y a aucune alternative.

      Non, je sais très bien qu'il y a des alternatives, qui sont d'ailleurs très attractives.

      À titre personnel, je me demande si je choisirai un alternative, et si oui, laquelle.

      D'une manière plus générale, je me demande si l'orientation que prend Arch (je persiste à croire que c'est un changement, même si nous ne somme pas d'accord là-dessus) satisfait ses utilisateurs.

      Pour l'ensemble des qualificatifs sympathiques qui assaisonnent ton commentaire : je constate jour après jour être de plus en plus réactionnaire en informatique. Mais je ne crois pas l'être pour la technique pure, et je m'extasie souvent devant une nouvelle solution à un problème. Je ne rejette donc pas tout ce qui est neuf. Mais parfois, sous un progrès technique, je vois des régressions concernant certains principes.

      Ces principes, j'ai du mal à les définir mais tu dois voir de quoi je parle : Ils touchent à une veille notion d'ergonomie, un certain rapport entre l'homme et la machine, rapport qui s'est exprimé dans la philosophie unix, mais aussi dans le logiciel libre. Ils touchent à la possibilité pour moi d'être en mesure de comprendre et de modifier mon environnement informatique. Ils touchent à l'idée que l'informatique relève du langage, donc du dialogue. Idée selon laquelle l'informatique est de l'ordre du sens, sens que je suis en mesure de m'approprier et que je peux exprimer à mon tour. D'une certaine manière, le mot low-tech pourrait convenir.

      Le fichier rc.conf était un bel exemple de cet esprit.

      • [^] # Re: L'immobilisme c'est mal.

        Posté par  . Évalué à 1.

        Une vielle notion d'ergonomie, tu veux dire, comme awk ? Comme euh bash ? AHAH, on ne doit pas avoir la même notion d’ergonomie. J'ai un peu l'impression que ça s'améliore au contraire.

  • # Rolling release

    Posté par  (site web personnel) . Évalué à 10.

    Ton journal m'interpelle, car depuis longtemps utilisateur de Arch Linux, j'ai pu en saisir trois principes de base :

    1) rolling release rapide
    2) kiss
    3) AUR

    Qu'est-ce que cela signifie par rapport à ton journal ?

    1) Archlinux adopte au plus tôt les nouvelles versions upstream. Si tu veux rester sur technologies stables et éprouvées, Arch n'est pas faite pour toi. Si tu n'aimes pas le changement régulier, Arch n'est pas faite pour toi.

    2) Archlinux patch au minimum l'upstream. La version de Grub sur mon système est actuellement la 0.97-21. Qu'est-ce que cela signifie ? Le mainteneur a du modifier 21 fois le paquet pour le faire fonctionner depuis la dernière release upstream. Trop de travail pour le mainteneur sans support upstream, le paquet n'est donc plus maintenu. Beaucoup de paquets dans cette situation subissent le même sort, Grub est simplement plus connu que les autres.

    3) Si un truc ne te plaît pas dans Arch, tu peux le faire toi-même et le partager aux autres dans AUR.
    Beaucoup de gens veulent garder grub-0.97, il est donc dans AUR. Parfait non ? Tu peux donc l'installer sans soucis, où est donc le problème ?
    Si beaucoup de gens veulent garder les initscripts, parfait, ils s'associeront pour le maintenir dans AUR, et tu pourras continuer à les utiliser. Si tu es tout seul dans cas, il faudra t'y atteler alors ;-)

    Voilà, ton journal m'interpelle parce que j'ai plus l'impression qu'il provient d'une incompréhension du fonctionnement d'Arch que d'un problème sur Arch en lui même.

    • [^] # Re: Rolling release

      Posté par  . Évalué à -6.

      La version de Grub sur mon système est actuellement la 0.97-21. Qu'est-ce que cela signifie ? Le mainteneur a du modifier 21 fois le paquet pour le faire fonctionner depuis la dernière release upstream.

      Foutage de gueule :

      (root) |> ~ <| pacman -Qi grub
      […]
      Build Date     : Thu 03 Nov 2011 10:16:30 PM CET
      […]
      
      

      Ça vaut pour ce commentaire aussi : https://linuxfr.org/users/sygne/journaux/arch-et-le-tournant#comment-1370843

      • [^] # Re: Rolling release

        Posté par  (site web personnel) . Évalué à 2.

        Tu m'expliques où je me fous de ta gueule dans la partie que tu cites ?

        • [^] # Re: Rolling release

          Posté par  . Évalué à -5.

          La dernière date de modification est proche de la dernière release upstream.

        • [^] # Re: Rolling release

          Posté par  . Évalué à 0.

          Tu expliques que c’est énormément de boulot de maintenir GRUB, « la preuve, le mainteneur a fait 21 realeases » pour qu’il marche.

          Sauf que tu oublies de préciser que la dernière release elle date de novembre 2011, donc niveau charge de travail, ça va quoi…

          • [^] # Re: Rolling release

            Posté par  . Évalué à 4.

            Cette date ne veut rien dire du tout.Il a arrêter parce qu'il n'y avait plus de bugs ou parce qu'il en avait marre de patcher et que ça fonctionnait suffisamment pour lui ?

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: Rolling release

              Posté par  . Évalué à 1.

              Et alors ? Puisque tout le monde dit que ça fonctionne bien grub1, pourquoi "supposer" que le mainteneur a arrêté de patcher parce qu'il en avait marre ? Si ça fonctionne comme ça ?

              Je m'en fiche complètement moi que le logiciel que j'utilise est vieux et qu'il y a d'autres logiciels plus à jour qui apportent des fonctionnalités dont je n'ai pas besoin.

              Tu gardes bien ton ls tel qu'il est ? Tu fais en sorte qu'il liste plus joliment les fichiers si tu veux, mais pourquoi devoir changer la manière dont tu l'utilises ?

              Pour faire la même chose qu'avant il faut "ré-apprendre" à le faire avec de nouveaux logiciels, c'est juste carrément pas le principe d'Unix à la base : tu développes et tu améliores. Pour moi on aurait du gardé la même syntaxe, voire en proposer une nouvelle "en plus" mais pas "à la place".

              • [^] # Re: Rolling release

                Posté par  . Évalué à 5.

                Et alors ? Puisque tout le monde dit que ça fonctionne bien grub1, pourquoi "supposer" que le mainteneur a arrêté de patcher parce qu'il en avait marre ? Si ça fonctionne comme ça ?

                Justement, il y a des gens qui trouvent que grub1 ne fonctionne pas bien comme ça. Entre le script automatique bancale et les montages raids un peu exotique, ça fait vite du monde.

                Pour moi on aurait du gardé la même syntaxe, voire en proposer une nouvelle "en plus" mais pas "à la place".

                Tu as déjà regarder la différence de syntaxe avant de dire ça ? Ce n'est vraiment pas très différent si tu veux faire la même chose qu'avec Grub 1.

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Rolling release

        Posté par  . Évalué à 4.

        Et en quoi ca vaut pour mon autre commentaire aussi? :]

  • # Fork-les

    Posté par  . Évalué à 2.

    Tout est dit

  • # La gestion des partition a toujours été dans un fichier à part.

    Posté par  . Évalué à 0.

    Bonjour.

    on tire à bout portant sur /etc/rc.conf, le fichier de configuration de ce qu'était Arch linux. Il est malade depuis un bout de temps.

    Beaucoup semble regretter la dépréciation du fichier rc.conf car celui-ci permettait, dans un unique fichier, d'administrer les points essentiels de le machine (le fuseau horaire, les démons à démarrer, les modules à charger, ceux à blacklister, …).

    Si vous êtes dans ce cas, voici une question :

    Sous Archlinux, la gestion des partitions n'a jamais été intégrée dans le rc.conf. En effet, tout ce qui concerne les partitions (points de montage, options de montage, …) est dans un autre fichier, pas dans rc.conf.

    Quelle fut votre réaction en réalisant que, pour gérer vos partitions, il vous faudrait éditer un autre fichier que le rc.conf ?

    • [^] # Autosatisfaction récursive

      Posté par  . Évalué à 1.

      Puisque personne ne me répond, je continue tout seul. :-)

      Le fichier rc.conf contenait des options de configuration très variées sur le système. On y trouvait :

      1. des informations sur le matériel : utilisation d'un RAID ou de LVM, pilotes de périphérique (modules) à charger.
      2. des informations sur le réseau : le nom de l'interface réseau à utiliser, son adresse IP.
      3. des informations sur les logiciels : la liste de démons à lancer.
      4. d'autres trucs : le fuseau horaire, le clavier, etc.

      Tant d'information de nature si différentes, qui n'ont rien à voir entre elles, et tout cela dans un même fichier ! Vraisemblablement, on aurait dû y ajouter la configuration des partitions, non ? Tant qu'à faire un fichier unique de configuration, pourquoi ne pas y mettre également la configuration des partitions ?

      Franchement ?

      Heureusement, cela n'a pas été fait. Mettre l'équivalent du fstab dans le rc.conf aurait peut-être faciliter la vie de l'utilisateur, mais cela aurait surtout compliqué terriblement le fonctionnement du système. Puisque tous les composants du système s'attendent à trouver la configuration des partitions dans le fstab, il aurait été nécessaire d'ajouter du « code d’interfaçage » pour que le système lise la configuration des partitions dans le rc.conf. Et cet ajout de code aurait compliqué le système.

      Utiliser un fichier central de configuration simplifie la vie de l'utilisateur : tout est au même endroit. Mais cela a un inconvénient : tous les logiciels s'attendent à trouver les options de configuration à des emplacements bien définis, pas dans un fichier spécifique à la distribution. Pour que les logiciels s’accommodent de cette spécificité de la distribution, il faut ajouter du « code d'interfaçage » qui alourdit le système (et peut induire des bugs).

      Il me semble qu'il y a eu une erreur d'interprétation sur la philosophie d'Archlinux : certains utilisateurs ont pensé que l'utilisation du système devait être simple, avec, notamment, un fichier unique de configuration. Or, c'est le fonctionnement du système qui se veut le plus simple possible, avec le minimum de code ajouté.

      • [^] # Re: Autosatisfaction récursive

        Posté par  . Évalué à 4. Dernière modification le 26 juillet 2012 à 15:32.

        qui n'ont rien à voir entre elles, et tout cela dans un même fichier !

        Si, elles ont un rapport, c’est les options de configuration du système (par opposition à la configuration de chaque logiciel indépendant).

        La configuration des partitions se trouve dans /etc/fstab et pas dans /etc/rc.conf tout simplement parce que /etc/fstab est le fichier de configuration de mount(8). C’est pour ça aussi que quand tu gères le réseau avec rc.sysinit la configuration se retrouve dans rc.conf, tandis que si tu gères le réseau avec netcfg la configuration du réseau n’y est plus.

        Faut voir rc.conf comme le fichier de configuration de rc.* (rc.sysinit,…), tout comme dhcpcd.conf est le fichier de configuration de dhcpcd.

        • [^] # Re: Autosatisfaction récursive

          Posté par  . Évalué à 1.

          Si, elles ont un rapport, c’est les options de configuration du système (par opposition à la configuration de chaque logiciel indépendant).

          Défini « système ».

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Autosatisfaction récursive

            Posté par  . Évalué à 5. Dernière modification le 27 juillet 2012 à 09:16.

            Dans le cas qui nous intéresse (la gestion de la configuration sous ArchLinux), système = tout ce qui n’est pas géré par un fichier de configuration standard (standard du point de vue du dev upstream), ou bien ce qui est géré par initscripts.

            Une variable d’environnement globale LC_ALL, c’est du système, parce que ça ne correspond à aucun logiciel tiers spécifique.

            Le réseau c’est du système, parce que c’est géré par initscripts. Sauf si tu veux utiliser un autre programme pour configurer le réseau.

            L’activation de LVM c’est du système, parce que c’est géré par initscripts.

            Les partitions c’est pas du système, parce que c’est géré par le programme upstream mount, qui possède déja son fichier de configuration standard (/etc/fstab).

            Le critère est super simple en fait :

            • si une méthode de configuration existe upstream, l’utiliser (parce que arch n’aime pas patcher, et que autrement ça signifie avoir deux endroits pour un même paramètre de configuration, pas glob)
            • sinon c’est dans rc.conf
        • [^] # Re: Autosatisfaction récursive

          Posté par  . Évalué à 0.

          [le fichier rc.conf contient] les options de configuration du système (par opposition à la configuration de chaque logiciel indépendant).

          Cet argument est pertinent pour certains des paramètres contenus dans le rc.conf, pas pour tous.

          Par exemple, le réseau.

          rc.conf contient des paramètres de configuration d'une seule et unique interface réseau. Est-ce que « une seule et unique interface réseau » est une caractéristique du système ?

          Je pense que non, puisque certains systèmes ont plusieurs interfaces réseaux. La configuration de ses systèmes n'est pas possible par le rc.conf, ils nécessitent d'autres logiciels, avec d'autres fichiers de configuration.

          • [^] # Re: Autosatisfaction récursive

            Posté par  . Évalué à 3.

            Ben, le réseau est un parfait exemple.

            Quand le réseau est géré par le système d’initialisation de la distrib (rc.sysinit et co), la configuration se trouve dans rc.conf. Quand le réseau est géré par un logiciel tiers (netcfg par exemple), c’est la configuration du logiciel tiers qui est utilisée, pas rc.conf.

            • [^] # Re: Autosatisfaction récursive

              Posté par  . Évalué à -1.

              Bon, je comprends ton argumentation. :-)

              Ceci étant, puisque personne n'a répondu à la question initiale, je la repose :

              Tout comme l'auteur de ce journal (qui y consacre un paragraphe entier), vous regrettez l'agonie du fichier rc.conf car celui-ci permettait, dans un unique fichier, d'administrer les points essentiels de le machine (le fuseau horaire, les démons à démarrer, les modules à charger, ceux à blacklister, …). Un seul fichier à gérer, c'était si simple !

              L'auteur du journal qualifie d'ailleurs rc.conf comme étant « le fichier de configuration de ce qu'était Archlinux » ! Bigre, ce super-fichier-qui-centralisait-tout était vraiment important !

              Hé les moules, quelle fut votre réaction en réalisant que, pour gérer vos partitions sous Archlinux, il vous faudrait éditer un autre fichier que le rc.conf ?

              Vous pouvez moinsser si ça vous chante, mais répondez aussi à la question.

  • # grub2 compliqué ?

    Posté par  . Évalué à 4.

    Personnellement j'ai du passer a grub2 il y a déjà pas mal de temps pour gérer des superblock raid en 1.x… ça ne m'a pas pris plus de 15mn installation, compréhension de la nouvelle syntaxe et du fonctionnement inclus.

    De plus pour scripter un peu les choses les fichiers individuels dans un dossier c'est quand même très pratique.

    C'est une petite évolution et même si changer de boot manager c'est toujours embêtant et un peu sensible car on aime bien tous quand une machine démarre sans poser de soucis… et surtout sans avoir a booter 10x sur un rescue cd pour réparer une mauvaise conf qui ne fonctionne pas. Mais comme dit pour le coup c'était vraiment pas la mer à boire ça a fonctionné du premier coup alors que la config raid soft + lvm n'est pas la plus basique qui soit.

    Depuis j'en ai profité pour faire évoluer toutes les autres machines dont j'ai la charge vers cette version histoire de ne pas avoir à faire le suivi pour plusieurs versions et pareil : absolument aucun soucis.

    Bref grub2 je l'aime bien tout comme j'aimais bien grub avant et la transition entre les deux n'est vraiment pas violente.

    • [^] # Re: grub2 compliqué ?

      Posté par  . Évalué à -2.

      enfin quelle qu un qui y trouve sont compte, et c est ce que je pense de grub2 ;)

      Merci aux personnes qui mon aidé a trouvé des solutions pour essayer d’écrire sans faute d’orthographe.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.