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 Olivier (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
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 Anonyme . É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 :
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 Alex_erson . É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/grubet de lancer par la suitegrub-mkconfig -o /boot/grub/grub.cfgpour générer le fichiergrub.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 Marotte ⛧ . É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 :
Gni ?!
[^] # Re: Grub2 vs Grub1 : Quel est le problème ?
Posté par madhatter (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 barmic . Évalué à 4.
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 madhatter (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 stopspam . É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 :
Des exemples récents :
[^] # Re: Grub2 vs Grub1 : Quel est le problème ?
Posté par Kaane . É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 Misc (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 Kaane . É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 gnuzer (site web personnel) . Évalué à 3.
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 Kaane . Évalué à 3.
C'est une hyperbole ou tu as vraiment un fichier à jour de références de matériel qui marche ?
Malheureusement c'est une hyperbole, je fais aussi joujou avec des tableaux
mais cadeau quand même :
http://www.freebsd.org/relnotes/CURRENT/hardware/support.html#WLAN
C'est pour FreeBSD, mais tout fonctionne sous Linux aussi.
Ca fait un tableau de plus pour faire joujou avec…
[^] # Re: Grub2 vs Grub1 : Quel est le problème ?
Posté par Marotte ⛧ . Évalué à 6.
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 eric gerbier (site web personnel) . Évalué à 3.
100% ?
Pas chez moi en tout cas : grub2 refuse (sur une fedora 17) de s'installer sur une partition (/dev/sda6).
J'ai du revenir sur grub1. Le problème semble connu (il a été remonté chez fedora), mais pas corrigé.
[^] # Re: Grub2 vs Grub1 : Quel est le problème ?
Posté par Reihar . É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 Marotte ⛧ . Évalué à 2.
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 Reihar . É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 Maxime (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 Reihar . É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 Arthur Accroc . É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 Reihar . É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 Batchyx . É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 navaati . Évalué à 0.
(je pense que tu trouvera difficilement du XML dans les softs développés par Lennart, dieu merci)
[^] # Re: Grub2 vs Grub1 : Quel est le problème ?
Posté par Batchyx . Évalué à 3.
On parie ?
Avahi, tu connais ? Regarde dans /etc/avahi/services/
[^] # Re: Grub2 vs Grub1 : Quel est le problème ?
Posté par navaati . Évalué à 2.
Ah, gg, j'avais (mal) vérifié Avahi pourtant. Je m'incline.
[^] # Re: Grub2 vs Grub1 : Quel est le problème ?
Posté par Sygne (site web personnel) . Évalué à 7.
D'accord, vous m'avez convaincu pour Grub2.
# Joli lancer
Posté par Misc (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 gnumdk (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 modr123 . Évalué à 2.
je vois toujours pas ce que l'on reproche a lilo…
[^] # Re: Joli lancer
Posté par Misc (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 Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 0. Dernière modification le 25 juillet 2012 à 00:09.
Je ne suis pas de cet avis, au contraire. Est-ce mieux ou moins bien, ce "tournant" que suit Arch, et pourquoi ?
Par exemple :
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.
Ç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é.
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 Anonyme . Évalué à 5.
GRUB fonctionnait, il n’y avait aucune raison de le virer complètement des dépôts.
Sinon, pour te faire plaisir :
Le reste de ton commentaire étant que tu troll, je m’abstiendrai de répondre.
[^] # Re: Si si, c'est la question
Posté par Ph Husson (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 zerkman (site web personnel) . Évalué à 5.
le 0.9 a fonctionné pendant longtemps aussi
[^] # Re: Si si, c'est la question
Posté par Spyhawk . Évalué à 6. Dernière modification le 25 juillet 2012 à 09:58.
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 Anonyme . Évalué à 2.
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 Reihar . Évalué à 2.
Rien n'empêche grub legacy de remonter vers [community]
[^] # Re: Si si, c'est la question
Posté par Spyhawk . Évalué à 4. Dernière modification le 25 juillet 2012 à 10:48.
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 mathieui (site web personnel) . Évalué à 1.
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 ne marchera pas un jour, et la configuration du système devient debiannesque. C’est de l’anticipation.
utiliserai c’est de l’indicatif futur. Et c’est aussi de l’anticipation.
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…
Ç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 gnumdk (site web personnel) . Évalué à 5.
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…
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 Astaoth . Évalué à 1.
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 solsTiCe (site web personnel) . Évalué à 7.
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 Enjolras . Évalué à 10.
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 Sygne (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 Ignatz Ledebur . Évalué à 2.
Ç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 Reihar . É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 B16F4RV4RD1N . É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 claudex . É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 Enjolras . Évalué à 8.
Le wiki français est sur archlinux.fr déjà.
Et, donc, permets moi de le citer :
Archlinux :
Kiss :
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 :
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 :
[^] # Re: même avis
Posté par Anonyme . Évalué à 1.
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 Psychofox (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 Anonyme . Évalué à 3.
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 Psychofox (Mastodon) . Évalué à 4.
Ç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 Anonyme . Évalué à 6.
Tu trouve
/mediaidiot parce qu’on avait déjà/mntmais tu ne trouve pas/run/user/…idiot. Je ne comprends pas.[^] # Re: même avis
Posté par Xavier Maillard . É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 claudex . Évalué à 4.
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_externeet/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 B16F4RV4RD1N . É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 claudex . Évalué à 3.
C'est ce que je voulais dire en tout cas. J'expliquais pourquoi ne pas avoir choisi
/mntpour le montage automatique.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 Anonyme . Évalué à 4.
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 :
Alors que pour rc.conf, si j’ai bien compris, on aura :
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 :
MODULES=(<mod1> <mod2> […])dans/etc/rc.confet/etc/modprobe.d/(anciennement/etc/modprobe.conf).Il est où le KISS là dedans ?
[^] # Re: même avis
Posté par Ambroise . É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 ?
[^] # Re: même avis
Posté par mathieui (site web personnel) . Évalué à 1.
Systemd.
[^] # Re: même avis
Posté par gnumdk (site web personnel) . Évalué à 2.
Vu qu'un systeme peut tourner avec plusieurs init au choix lors du boot, il valait mieux ne pas utiliser l'ancien nommage…
# Le chant du Sygne
Posté par ekyo . É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 gnumdk (site web personnel) . Évalué à 5.
Tu parles de Windows là ? Syslinux via chain.c32 peut très bien booter un windows sans grub.
[^] # Re: Le chant du Sygne
Posté par Enjolras . Évalué à 2.
Non, il ne sait pas booter windows, il sait appeler le boot loader de windows.
[^] # Re: Le chant du Sygne
Posté par gnumdk (site web personnel) . Évalué à 3.
Et grub il fait quoi ?
[^] # Re: Le chant du Sygne
Posté par Enjolras . Évalué à 4.
La même chose, mais je vois pas quel est le rapport avec la choucroute. C'est pas parce que grub sait pas booter windows que syslinux sait booter windows.
# Grub, rc.conf, systemd
Posté par Arthur Accroc . É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.
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)…
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 claudex . Évalué à 3.
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 Arthur Accroc . Évalué à 2.
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 mathieui (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 Enjolras . Évalué à 3.
J'abonde dans ce sens, grub 2 fournit un compilateur de conf qu'on n'est pas sommé d'utiliser.
Tu peux :
[^] # Re: Grub, rc.conf, systemd
Posté par barmic . Évalué à 9.
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_custompour le configurer (celle-ci s'ajoute aux configuration initiales)/etc/default/grubIl permet d'avoir des configuration plus globale que dans le fichier précédent. Je tiens à souligner la complexité :Si je modifie l'un de ces fichiers
update-grub2me 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 :/etc/grub.d/40_custom/etc/grub.d/et envoie leur sortie dans le grub.cfgC'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 Arthur Accroc . É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 ?
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Grub
Posté par barmic . Évalué à 2.
J'édite
/etc/grub.d/40_custom: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 Arthur Accroc . É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 barmic . Évalué à 1.
Avant je perdais tout et il fallait que je me souvienne de mes modif' (ou que je maintienne un diff).
On est d'accord.
C'est déjà un mieux, non ?
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 :
à 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 Arthur Accroc . Évalué à 1.
Ah quand même !
Debian trouve toujours le moyen de me surprendre… mais pas souvent dans le bon sens.
Fedora gérait ça correctement.
Ç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 barmic . Évalué à 2.
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.
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 Arthur Accroc . Évalué à 2.
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.
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 barmic . É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 Arthur Accroc . Évalué à 0.
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.
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.
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 barmic . Évalué à 1.
Ç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.dpour 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é.
Plus vite peut être, plus fiable, plus maintenable, plus portable à travers les distributions et OS, je ne sais pas.
Ç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).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.
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 :)
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 Arthur Accroc . Évalué à 2.
Hein ? Pouvoir éditer le fichier de configuration et mettre tout ce que tu veux dedans, ça manque de flexibilité ???
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).
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.
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.
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.
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 barmic . É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. 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.det 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 Arthur Accroc . Évalué à 2.
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 ?
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.
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 jyes . Évalué à 0. Dernière modification le 26 juillet 2012 à 20:49.
Ç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 barmic . É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 Arthur Accroc . Évalué à 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.
C’est de l’humour, c’est ça ?
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Grub
Posté par barmic . Évalué à 2.
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 Arthur Accroc . Évalué à 2.
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 Olivier (site web personnel) . Évalué à 2.
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 hitmanu . É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.
[^] # Re: apprentissage d'un archer
Posté par Reihar . Évalué à 2.
Heu, configurer une arch et une debian, c'est pas du tout la même chose.
# Vieux barbus
Posté par cedric . É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…
[^] # Re: Vieux barbus
Posté par zerkman (site web personnel) . Évalué à 10.
C'est triste, ton avis sur les vieux barbus
# L'immobilisme c'est mal.
Posté par Enjolras . É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à.
Tu sembles croire qu'il n'y a aucune alternative. C'est faux, il y a :
[^] # Re: L'immobilisme c'est mal.
Posté par mornik . É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 Reihar . É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 Enjolras . É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 Reihar . Évalué à 1.
C'était juste une règle générale hein. Je ne visais personne :p
[^] # Re: Résister plus longtemps
Posté par claudex . Évalué à 5.
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 B16F4RV4RD1N . Évalué à -1.
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 dguihal . É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 gnumdk (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 Sufflope (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 Enjolras . Évalué à 2.
je ne sais pas, peut être Fedora.
[^] # Re: L'immobilisme c'est mal.
Posté par Anonyme . Évalué à 3.
Non, il n’y a pas d’alternative.
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.
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 barmic . Évalué à 4.
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.
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 stopspam . Évalué à 1. Dernière modification le 25 juillet 2012 à 13:30.
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.
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
[^] # Re: L'immobilisme c'est mal.
Posté par barmic . Évalué à 2.
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).
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 Enjolras . É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 barmic . Évalué à 2.
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 neil . Évalué à 1.
Sauf qu’ils sont passés à systemd depuis longtemps :(
[^] # Re: L'immobilisme c'est mal.
Posté par hitmanu . Évalué à -2.
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 Lutin . Évalué à 2.
Il y a Frugalware.
[^] # Re: L'immobilisme c'est mal.
Posté par Sygne (site web personnel) . Évalué à 2.
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 Enjolras . É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 paulez (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 Anonyme . Évalué à -6.
Foutage de gueule :
Ça vaut pour ce commentaire aussi : https://linuxfr.org/users/sygne/journaux/arch-et-le-tournant#comment-1370843
[^] # Re: Rolling release
Posté par paulez (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 Reihar . Évalué à -5.
La dernière date de modification est proche de la dernière release upstream.
[^] # Re: Rolling release
Posté par paulez (site web personnel) . Évalué à 2.
Hum, je cite le manuel de grub legacy sur gnu.org,
Ça fait quand même plus de sept ans d'écart non ?
[^] # Re: Rolling release
Posté par Reihar . Évalué à 0.
Au temps pour moi, je pensais que c'était bien plus récent que ça.
[^] # Re: Rolling release
Posté par paulez (site web personnel) . Évalué à 5.
Non mais quand on dit que Grub 1 n'est plus maintenu upstream, ce n'est pas une légende ;-)
[^] # Re: Rolling release
Posté par Reihar . Évalué à -3.
Ah mais j'imaginais un truc du genre 2009. J'ai probablement confondu avec un autre projet.
[^] # Re: Rolling release
Posté par Anonyme . É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 claudex . É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 karchnu . É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 claudex . Évalué à 5.
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.
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 Spyhawk . Évalué à 4.
Et en quoi ca vaut pour mon autre commentaire aussi? :]
# Fork-les
Posté par lordblackfox . Évalué à 2.
Tout est dit
# La gestion des partition a toujours été dans un fichier à part.
Posté par Sylvain Blandel . Évalué à 0.
Bonjour.
Beaucoup semble regretter la dépréciation du fichier
rc.confcar 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 dansrc.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 Sylvain Blandel . Évalué à 1.
Puisque personne ne me répond, je continue tout seul. :-)
Le fichier
rc.confcontenait des options de configuration très variées sur le système. On y trouvait :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
fstabdans lerc.confaurait 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 lefstab, il aurait été nécessaire d'ajouter du « code d’interfaçage » pour que le système lise la configuration des partitions dans lerc.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 Moonz . Évalué à 4. Dernière modification le 26 juillet 2012 à 15:32.
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/fstabet pas dans/etc/rc.conftout simplement parce que/etc/fstabest le fichier de configuration demount(8). C’est pour ça aussi que quand tu gères le réseau avecrc.sysinitla configuration se retrouve dansrc.conf, tandis que si tu gères le réseau avecnetcfgla configuration du réseau n’y est plus.Faut voir
rc.confcomme le fichier de configuration derc.*(rc.sysinit,…), tout commedhcpcd.confest le fichier de configuration dedhcpcd.[^] # Re: Autosatisfaction récursive
Posté par barmic . Évalué à 1.
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 Moonz . É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 :
rc.conf[^] # Re: Autosatisfaction récursive
Posté par Sylvain Blandel . Évalué à 0.
Cet argument est pertinent pour certains des paramètres contenus dans le
rc.conf, pas pour tous.Par exemple, le réseau.
rc.confcontient 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 Moonz . É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.sysinitet co), la configuration se trouve dansrc.conf. Quand le réseau est géré par un logiciel tiers (netcfgpar exemple), c’est la configuration du logiciel tiers qui est utilisée, pasrc.conf.[^] # Re: Autosatisfaction récursive
Posté par Sylvain Blandel . É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.confcar 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.confcomme é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 Chris K. . É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 hitmanu . É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.