Cyrille Pontvieux a écrit 529 commentaires

Mais encore une fois, je ne vois pas la différence avec grub1 ou grub2 sur ton exemple.
Si tu veux résoudre le même problème avec grub2, tu vas dans la doc, qui va te donner les même genre de commandes que celles de syslinux/extlinux, et tu vas te retrouver à taper à peu près la même chose.

Grub2 permet plus de chose que syslinux, celà ne veut pas dire qu'il est complexe de l'utiliser.
Je voudrais juste préciser que je n'ai rien contre syslinux, au contraire, j'aime bien aussi ce bootloader qui est également clair et bien fonctionnel. En fait, je l'utilise sur USB pour chainloader vers du grub2, car l'installation de syslinux dans le MBR est plus simple (pour la plupart des gens et clés USB en fat32) qu'avec un grub2.

Par contre, je trouve qu'on regarde souvent l'utilisation d'un soft, intégré dans cette merde d'Ubuntu, au lieu d'évaluer le soft lui-même. À mon avis, ici c'est le même problème. grub2 est évalué via l'intégration pourrie d'Ubuntu (je vais me faire moinsser pour dire ça, mais bon…)

Je vais répondre simplement : non c'est faux.
Comme indiqué plusieurs fois plus haut, le fichier de config de grub2 c'est grub.cfg, tu l'édites avec un éditeur de texte, celui que tu veux, et basta. Et le fichier n'est en aucun cas différent entre un 32 ou 64 bits (grub2 tourne en mode émulation 32 bits sur un processeur 64 bits de toute façon, et sur un seul processeur/core, pour info).
Je le répète, mais le grub-mkconfig n'est pas nécessaire du tout pour changer un truc dans la config de grub2, donc pas besoin de chrooter ou je ne sais quoi.

Effectivement ce n'est pas spécifié dans la dépêche.
En gros, ce qu'on peut noter comme différences (qui peuvent n'avoir aucun intérêt pour toi) :
- le "stage 1.5" est devenu obligatoire pour booter, permet plus de chose (une console de secours est toujours disponible), et contient un ensemble de fonctionnalités variables (préciser à la compilation). Son nouveau nom est core.img
- le "stage 2" n'existe plus, et c'est juste des modules que l'on charge au besoin. Ces modules peuvent définir un driver de système de fichiers, un interpréteur de commande (parser) ou un ensemble de commandes.
- gettext et utf-8 qui permettent d'avoir une traduction des menus (pour les trucs qui nécessitent des vrais menus, genre un liveCD, ou un truc type SystemRescueCD).
- des possibilités de chainloading dans tous les sens, qui permettent une intégration de ou vers grub2 simplifiée.
- la gestion de nouveaux types de systèmes de fichiers, de table de partition, de BIOS/EFI, d'architecture.
- un vrai shell disponible au boot, qui permet de faire un tas de modifications si on a un problème de boot, ou pour booter quelque chose d'exotique ou inhabituel.
- langage de script shell évolué qui permet de faire des scripts plus simple et plus manitenable (utile aux distributions principalement).
- une gestion des thèmes améliorée.

Ce serait bien de lire le tout et pas de répondre à côté de la plaquer, merci.
Les lignes de syslinux et de grub2 font exactement la même chose : afficher une ligne de menu, charger le noyau, charger l'initrd, booter.

Les lignes qui ont été ajoutés par Sylvain sont inutiles au boot. Sauf évidemment le module pour gérer ses partitions GPT…ce que ne peut pas faire syslinux pour le moment (mais je ne doute pas qu'il finisse par les gérer).
Les lignes ajoutées, permettent de charger une carte de clavier bépo (inutile pour sélectionner la ligne de boot, utile uniquement s'il veut modifier un truc à la volé dans grub2, chose impossible avec syslinux), de dire à grub2 de ne pas changer de résolution au moment de charger le noyau (c'est sympa, mais pas indispensable), charge le module gzio (je ne sais pas pourquoi il charge ce module), charge le module de gestion de partitions GPT, charge le module de gestion d'ext1/2/3/4 (mais ça me semble inutile, je pense qu'il est déjà chargé).
La ligne avec le search permet de définir la variable "root" (permettant de donner la partition sur laquelle démarrer) en cherchant la partoche par UUID, inutile puisqu'on a déjà défini la variable root.
Ensuite y'a deux "echo" qui servent à rien.

Ouais sauf que non, justement.
Là il a copié-collé un truc généré et l'a adapté.
Si tu veux comparer à fonctionnalité égales (donc en supposant que ces partitions sont pas sur du GPT mais du MS-DOS), ça donne :

menuentry 'Archlinux, boot dans l’initramfs' {
  set root='(hd0,msdos1)'
  linux   /boot/vmlinuz-linux ro break=y
  initrd  /boot/initramfs-linux.img
}
menuentry 'Archlinux, système de sauvegarde sur sda6' {
  set root='(hd0,msdos2)'
  linux   /boot/vmlinuz-linux ro  
  initrd  /boot/initramfs-linux.img
}

Ce qui fait 10 lignes. Alors faudrait ptre un peu comparer des choses identiques.

La doc est là, et elle est très bien je trouve. Je vois où tu vois que la doc est sur Ubuntu ?

Booter en utilisant la ROM de la carte réseau, c'est pas con. Je vois pas trop pourquoi grub2 ne pourrait pas le faire. Tout dépend de la taille de l'espace mémoire disponible. Après il manque ptre à grub2 la commande pour installer grub core.img dans cette mémoire, à la différence de ipxe.

Lit plus haut, j'ai indiqué que ce besoin de regénérer la conf n'est pas un problème de grub, mais un problème de distribution à la con.
Sinon grub sait booter en PXE également.

Tout dépend de la distribution que tu utilises.
Le fichier grub.cfg est le seul fichier de configuration lu par grub2.

Après, pour certaines raisons, l'équipe de grub a permit de mettre en place un ensemble de fichier de config (buildtime) qui permettent de générer le fichier de config (runtime).
C'est une option. Ce n'est pas automatique…sur les bonnes distributions.

Pour (re-)générer le fichier de configuration runtime grub.cfg si besoin, il faut lancer grub-mkconfig, qui va lire les fichiers de config buildtime et faire son mic-mac. Ce n'est pas forcément hyper simple à hacker pour ceux habitués à grub1, lilo, etc.
Soit, ben ne lancez pas grub-mkconfig, ignorez ces fichiers buildtime, et modifiez directement grub.cfg, comme avant.

Ah mais nooon… ça marche pas, parce que vous utilisez une distrib de merde, qui s'amuse à exécuter, à votre insu, grub-mkconfig à chaque mise à jour du noyau, de l'initrd ou d'un composant proche du noyau.

Mais il faut bien faire la différence entre une distribution qui a fait le choix de rendre obligatoire le passage par grub-mkconfig, et le fait que grub2 aie permit d'utiliser grub-mkconfig si on veut.

J'utilise Salix, basée et compatible avec Slackware, j'utilise grub2 (des fois LILO aussi sur certaines machines où j'ai pas pensé à changer), et je n'ai pas besoin de me faire chier avec les fichiers de config buildtime. Sur mon propre PC, ça me va, donc j'ai lancé grub-mkconfig, et j'ai mon fichier grub.cfg généré ; sur un serveur je ne le lance pas, et j'ai modifié directement le fichier grub.cfg.
J'imagine que sous Arch, ça doit être la même chose, grub-mkconfig n'est pas lancé implicitement lors d'une mise à jour de paquet.
Doit y avoir aussi d'autres distrib qui font ça correctement ou qui permettent d'activer ou pas l'utilisation automatique de grub-mkconfig. Après y'a les autres…

Entre une fonctionnalité qui fait tout et pas de fonctionnalité, je trouve qu'il y a quand même un juste milieu à trouver.
Pourquoi ne pas proposer la gestion des vidéos via la balise <video> et/ou via un lien de téléchargement ? Si le visiteur ne peut pas lire la vidéo (navigation depuis un navigateur ne gérant pas la balise video ou OS ne gérant pas le format vidéo) on a toujours le comportement actuel, donc rien de perdu. Et si on peut lire la vidéo via la balise <video> et bien c'est toujours ça de gagné, non ?
L'hébergement via Youtube & co, ce n'est pas une option pour moi. Je veux gérer MES vidéos sur MON serveur.

Et il faut arrêter de parler des extensions Charlies Content ou jPlayer. Je les ai testé et ça ne marche pas du tout, en tout cas pas avec la version 2.3 de Piwigo et quelques autres extensions communes. En plus ces solutions sont lourdes et avec une installation compliquée.

J'ai dû écrire moi-même un bout de code pour afficher un bouton « télécharger la vidéo » sur les vidéos (avec un miniature faite sur mon PC avant l'envoi grâce à ffmpeg et imagemagick). C'est un peu moins souple qu'une lecture intégrée dans le navigateur mais bon ça marche bien et c'est mieux que rien.

Bon après je râle, je râle, mais c'est surtout sur la forme. Je trouve que le discours « héberger vos photos vous-même » couplé à un « pour les vidéos, utilisez les hébergeurs en ligne » ne tient pas. Après je conçois largement que ce soit difficile techniquement et que ça ne fait pas partie des priorités de Piwigo.

Bon au final, j'utilise Piwigo pour mes photos de vacances principalement, et j'en suis [b]très[/b] content. Avec un ou deux plugins, ça rend vraiment bien et c'est rapide. Il y a plein de fonctionnalités que l'ont peut activer (ou s'en passer) et le logiciel permet de répondre à plusieurs type d'utilisateurs.

Désolé pour mon côté « râleur ». Je remercie toute l'équipe de Piwigo pour cet excellent outil. Je ne peux pas contribuer mes changements pour la gestion des vidéos car avec ce changement des miniatures ça ne marchera plus, mais si j'arrive à le faire fonctionner avec le nouveau système, c'est avec plaisir que je contribuerai.

Mais c'est clair, c'est génial !!
Moi qui boudait Jamendo depuis leur nouvelle interface à la con. En plus je trouvais plus comment télécharger en OGG. Là je suis bien content ça marche impec.
Hyper rapide, plein de fonctionnalités, génial.

Seul truc que je rajouterais c'est des « title » sur les éléments cliquables. Car même si tu as mis des belles icônes, on a toujours un doute sur la fonctionnalité. Alors bon, en regardant l'URL au survol, on se doute du coup de la fonction, mais un petit tooltip ne serait pas de trop.
Vu que c'est sur git, je ferai ptre une proposition de patch (heuh je suis pas encore très à l'aise avec git, donc ce sera ptre pas tout de suite…)

Déjà indiqué plus haut ici.

Ben sur une prise réseau pour le routeur, sur une prise USB pour l'iPhone…pas compliqué non ?

Les ponctuations doubles (« :;!? ») prennent une espace avant et après. Et en informatique, il est de mise de mettre un espace insécable avant et un espace normal après.

Pertinent.

Mais je corrige en disant que fr-oss ça permet l'accès au capitales accentuées, qu'on peut effectivement utiliser comme des majuscules si besoin ;-)
(Ben quoi c'est bien un journal trollifère — ou on dit trollifaire ? — non ?)

Justement « mél » ne doit s'employer que sur les cartes de visites (ou équivalent), comme « tel. ». Ce n'est pas un nom commun. Pour le nom commun, il est recommandé d'utiliser soit le joli terme inventé par les québécois, à savoir courriel, ou directement le mot anglais « email ».

Salix a également intégré récemment MATE à ses paquets : http://www.salixos.org/forum/viewtopic.php?f=17&t=3396
Une version Live (beta) est également déjà disponible : http://www.salixos.org/forum/viewtopic.php?f=17&t=3406

Exactement ce que je voulais répondre.
Faut ptre lire un peu le but et la façon de fonctionner des distributions que tu choisis et voir si ça correspond à ton besoin ou pas. Ici tes choix ne correspondent pas à ton besoin. Tu veux un truc stable… commence pas par prendre une distro en rolling-release. Ubuntu est également basé (si je ne me trompe pas) sur Debian unstable. Ça parait quand même assez clair non ?
Alors oui, des fois (souvent ?), les « unstable » et/ou les « rolling-releases » ça peut fonctionner un bon moment. Mais tôt ou tard, ça finit par merder. Si on l’accepte dès le départ, alors il n'y a pas de problème, mais si on croit avoir un truc stable alors qu'on a un truc dernier cri, on peut avoir des surprises et être déçu comme tu l'es.

Je te conseille de regarder du côté de distributions stables. Bon tu n'as pas l'air d'aimer Debian (je vois pas pourquoi vu que tu utilisais Ubuntu), je te conseille donc de regarder du côté de Slackware, et plus spécialement de Salix. C'est pas le tout dernier cri, mais c'est stable et maintenu.

De manière général, j'avoue que ça m'agace un peu les gens qui ont testés deux ou trois distro max, pas adaptées à leur besoin, et qui ensuite généralisent leurs problèmes et frustration sur le libre en général.

Moi j'utilise depuis un moment ceci pour Windows (quand je suis obligé d'utiliser cet OS) : http://www.cameuh.net/Software/KeymapWindows
Je le conseille également à des windowsiens qui veulent écrire correctement en français quand ils ne sont pas dans un traitement de texte (pour pouvoir écrire des espaces insécables, des majuscules accentuées, etc.)

Il est passé du statut « expérimental » au statut « pleinement supporté »

J'aimerais simplement qu'on arrête de citer Ubuntu quand on parle de l'environnement Linux en général. Ton lien vers les régressions, soi disant Linux, est en fait un lien vers le bugtracker d'Ubuntu. Je me retiens de troller sur cette distro mais j'en pense pas moins.
Et puis parler de l'environnement Linux (car je pense que le sujet ne parlait pas du noyau), c'est aussi un peu réducteur pour parler des logiciels libres, puisque apparemment c'est le sujet de ton journal.
T'es quand même bien content d'avoir les logiciels que tu mentionnes, même si y'a un ou deux bugs. Tu te plains que l'installeur de LibreOffice ne fonctionne pas en déploiement automatique, mais la version précédente, il me semble que ce n'était même pas supporté. Là, d'après ce que j'ai compris des réponses de mes petits camarades, c'est juste un problème de support de version. Et donc c'est bien GPO qui gère pas bien la dernière version du protocole MSI qu'à suivi, apparemment à tord, l'équipe de LibreOffice. Alors il est où le problème en fait ? Dans le soft libre qui suit les specs fournies par MS, ou dans GPO qui suit pas la dernière spec ?
Et puis arrête de pleurer, y'a un workaround de cité, applique-le et voilà.

Donc la conclusion c'est qu'on parle d'une distro de merde quoi.

Faut arrêter de réduire Linux et ses distributions à trois ou quatre grandes distributions qui font souvent de la merde en ce moment.

Wicd fonctionne très bien, il existe un démon, et des clients pour le configurer, en ligne de commande, en ncurses, en GTK, ptre même qu'il y en a une en Qt je crois.
Et encore, Wicd n'est qu'une aide, on peut le virer (ce que je fais sur les serveurs).

J'utilise Slackware (Salix), et je n'ai aucun des problèmes cités dans le journal, forcément, j'ai pas de systemD de merde (j'adore le nom que ça donne en français d'ailleurs). J'ai lu les specs du truc...ça apporte des solutions à des non-problèmes. La phase de boot n'est pas des plus rapides (pas de parallélisation) qu'il est possible de concevoir, mais ça reste assez rapide...et surtout très simple à comprendre.

J'ai pas non plus de pulseaudio. Dans mon cas, je ne vois pas à quoi ça sert. Alsa fonctionne très bien. Si un jour je voudrais faire un truc qui demande une latence super faible parce que je me suis lancé dans l'édition musicale, je sortirai Jack. Le seul truc que je peux reprocher à Alsa c'est sa manque de doc, et son manque de support réseau. Mais c'est pas qu'on demande à un démon de son pour le desktop je crois.

Bref, Lennart fait et propose des outils. Libre à chaque distro de les intégrer ou non, en évaluant si les specs (et donc les raisons) de ses softs répondent à des problématiques que veut résoudre la-dite distro.

Vous aimez pas les outils de Lennart ⇒ changez de distro ;-)

P.S. Debian n'impose aucun de ces outils aussi il me semble. Arch non plus.

Je trouve que la qualité de traduction des RC est moindre que les précédentes news sur le noyau. C'est moi ou y'a une raison (nouveau traducteur, manque de temps, autre) ?

Sinon le reste est super bien, comme d'hab ;-)
Merci.

Idem sous Salix.
Tu peux installer les mises à jour, et voir pour les nouveaux de fichiers de conf plus tard, quand tu veux, quand t'as le temps. Pas de question, pas d’interaction quelconque lors de la mise à jour d'un ou plusieurs paquet sous Slackware/Salix.
Et y'a un système de notification des mises à jour sur Salix entièrement graphique pour ceux qui veulent tout faire au clic...Cette notification est une notification classique avec une icone qui s'ajoute dans la zone de notification (d'où son nom), quand tu cliques dessus, ça lance le gestionnaire de paquet pour installer les mises à jour.
Ça t'empêche pas de bosser, ça te (re)demande pas 15 fois d'installer les mises à jour ou de redémarrer. C'est quand même pas compliqué de faire un système de mise à jour simple.

Le mieux pour apprendre du shell script, c'est d'en lire pas mal. Déjà tu peux lire les scripts de démarrage de ta distribution. Tu risques déjà d'apprendre un paquet de choses. Ensuite, je te conseille de te faire des petits scripts dès que tu as besoin de quelque chose.
Au début j'ai appris en lisant la man page de bash...donc j'ai appris du bash, pas du shell script portable. Mais ça aide au début, surtout que beaucoup de choses et concepts sont communs. Ensuite, je te conseille de chercher sur le net "no bashism" sur le net. Je n'arrive pas à le retrouver là, mais un type avait mis au point un shell script portable qui parse un script et te dis les choses spécifiques à bash qui sont dedans, où les choses qui ne sont pas portables et te donnes des pistes pour les écrire mieux. J'ai beaucoup appris aussi de cette manière. Je suis sûr qu'il y a moyen de le retrouver ce script...

Vivement le septième décret de cette loi !