C’est peut-être intéressant sur un netbook. Sur un écran de 1200 pixels de haut (il date d’avant l’hégémonie de la « HD »…), c’est anti-ergonomique.
Le problème est de viser la même interface partout (que ce soit Gnome 3 ou Unity), alors qu’une machine de bureau avec clavier, souris et écran 24″, ça n’est pas la même chose qu’une tablette 7″ — voire un smartphone — avec surface tactile, pas de clavier et pas de souris.
Je suis bien content que mon PC n’ait pas la même interface que mon téléphone et vice-versa.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Dommage, le tiret (-), utilisé par la grande majorité (tous ?) des langages sources pour le signe moins (−), est trop petit pour moi. […]
Comparez avec celui d’Inconsolata p.ex.
Tu as essayé la version actuellement disponible et à chasse variable de Source Sans ou la version à chasse fixe encore en développement ?
Parce que de toute façon, une police à chasse variable, pour du code…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
La clef USB est quand même pas si rare que ça, faut pas déconner. Ensuite, les nouveaux laptops, notamment chez Dell ou Apple, commencent à ne plus venir avec des lecteurs de DVD.
C’est con que cette évolution n’ait pas eu lieu avant que les portables aient adopté un format d’écran qui n’est adapté qu’à la lecture de DVD…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Aussi, même quand les polices sont bien lissées on peut ressentir un sentiment de flou à l'usage, sentiment qu'on ne peut pas avoir avec une police bitmap.
Longtemps, je n’ai pas supporté les polices vectorielles pour leur manque de netteté à l’écran. Avec le « hinting » à fond, même sans gestion des sous-pixels, elles deviennent à mon avis beaucoup plus fréquentables (même la DejaVu Sans Mono, alors qu’à la base je trouve la série DejaVu bien plus réussie pour l’impression que pour l’affichage).
Quant à la Terminus, j’ai deux reproches à lui faire, un gros et un petit :
– les lignes sont trop serrées ;
– la graphie assez carrée des caractères limite les lignes en biais donc l’aspect crénelé, mais ça colle aussi un peu plus les caractères avec leurs voisins, je trouve que ça nuit un peu à la lisibilité.
Moralité : pour mes terminaux, j’en suis resté à la bonne vieille Fixed en SemiCondensed taille 10. Elle fait la même largeur que la Terminus taille 9, mais avec les lignes un peu plus espacées et sans aplatissement des majuscules et des symboles hauts (parenthèses, accolades…).
Pour les éditeurs, je préfère une fonte légèrement plus grosse, donc suivant les conditions de rendu (« hinting », rendu sous-pixel), j’oscille entre une fonte vectorielle et la Fixed en 11 (un peu trop grosse à mon goût).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Et toi tu refuse de voir que des problèmes il en existait avant qui sont corrigés ou qui peuvent être solutionnés avec le système actuel.
Il en existait avant sous Debian voire sous Fedora.
Quels sont ceux que tu vois qui n’étaient pas plus faciles à résoudre avec la solution de Mandriva ?
La prise en charge automatique de plus de deux noyaux dans le choix de démarrage ? Combien de personnes en ont-elles réellement besoin (franchement ça fait des années que je n’ai pas vu de cas où le noyau courant ne permette pas de démarrer) ? Y en a-t-il parmi celles-ci pour lesquelles il ne soit pas facile d’ajouter une entrée dans le fichier de configuration ?
(aller encore un chmod -x /etc/grub.d et paf plus de modifications du fichier de conf quoi qu'il arrive
As-tu essayé ?
Est-ce qu’on ne se retrouve pas plutôt avec un fichier de configuration tronqué ?
Qui plus est, après, il faut gérer soi-même la mise à jour du fichier de configuration sur les distributions dont le fichier du noyau contient le numéro de version.
(sauf si ton gestionnaire de paquet écrase les fichiers que tu as toi même modifiés, mais c'est un problème du gestionnaire de paquet (note que je ne sais pas ce qu'il en est pour apt,
Avec rpm, il y a les fichiers considérés comme des fichiers de configuration, qui sont conservés, et les autres qui sont écrasés. Il me semble que c’est pareil avec pacman, mais j’ai moins de recul pour en être sûr. Cela dit, j’entre toutes mes modifications dans un gestionnaire de versions, ça me permet de repérer d’éventuels problèmes.
En tout cas, les droits des répertoires faisant partie d’un paquet sont restaurés à la mise à jour et je ne suis pas sûr que la différence de droits saute aux yeux avec un gestionnaire de versions.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Ils ont tous repris la solution upstream. Donc si tu veux tirer sur quelqu'un choisi un peu mieux ta cible.
upstream fournit un script pour générer la configuration de Grub 2.
Il n’oblige pas à le relancer à chaque mise à jour du noyau. C’est le choix de la distribution de ne pas utiliser un nom fixe pour son noyau.
D’autre part, ça fait plus de 10 ans que la solution de Mandriva existe.
Fedora a préféré une solution plus complexe. Debian n’a pas vu où était le problème à continuer d’écraser la configuration et avec les modifications qui ont pu être faites par l’utilisateur.
Ce sont leurs choix de l’époque, ça n’a rien à voir avec ce que propose maintenant upstream, tant de temps après.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Ça tombe bien, tu peux. Les machins dans /etc/grub.d/ sont des scripts et tu peux très bien y mettre un 99_my_ugly_regex qui mouline comme un sale pour faire ce que le script de ta distrib faisait avec Grub 1.
Je n’ai jamais dit que je considérais ça comme une bonne solution, c’est juste une autre mauvaise solution, mais bien plus pratique, existant sur une distribution.
À la base, ce qu’on veut, c’est pouvoir conserver plusieurs noyaux, démarrer le dernier par défaut, garder la possibilité de démarrer le précédent en secours (c’est largement suffisant pour l’utilisateur de base), tout en laissant la marge à l’utilisateur avancé de démarrer un noyau de son choix.
Vous voyez autre chose d’utile ?
La solution simple existait déjà il y a plus de 10 ans sur Mandrake : des liens sur le noyau courant et le précédent. Ça fait deux commandes mv et deux commandes ln (il y a aussi l’init ram disk) dans le script post-install du noyau.
Avec ça, il n’y a plus besoin de modifier la configuration de démarrage. Quant aux utilisateurs avancés, ajouter une entrée de menu pour leur noyau à eux n’est pas difficile (il suffit d’adapter une entrée existante dans la configuration), ils peuvent l’ajouter sans problème où ils veulent et sans risque d’avoir à le refaire, puisque la configuration n’a pas à être regénérée, et s’ils l’ont mis par défaut, ça ne risque pas de changer parce qu’à la mise à jour du noyau officiel grub-mkconfig n’aura pas classé les noyaux dans le même ordre.
Évidemment, reprendre une bonne idée de Mandriva, pour Fedora/RedHat, ce serait un déshonneur et pour un debianiste, la honte.
Amuse toi bien avec ton pseudo KISS plein de regex alors que des scripts plus simples font déjà tout pour te simplifier la vie.
C’est de l’humour, c’est ça ?
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Hein ? Pouvoir éditer le fichier de configuration et mettre tout ce que tu veux dedans, ça manque de flexibilité ???
et ça déporte un bout de la conf de ta machine dans /boot.
Oulala ! C’est vraiment affreux !
Fedora avait pensé aux maniaques du rangement : /boot/grub/menu.lst était un lien vers /etc/grub.conf (bon, peut-être pas si tu fais une partition /boot séparée).
Compliquée non, sophistiquée peut être. Il faut prendre 5 minutes pour lire un peu la doc (je croyais les archers fiers de lire la doc eux), pour comprendre comment ça fonctionne de manière précise.
Ouais, ben la fois où un utilisateur m’a demandé si je pouvais fixer l’ordre des entrées de son Grub 2 sur un portable perso, je n’allais pas y passer 3 heures. J’ai regardé la doc d’Ubuntu 5 minutes… et j’ai préféré regarder le contenu du paquet Grub. Solution rapide : j’ai modifié les priorités des scripts dans /etc/grub.d.
Si vraiment tu veux avoir quelque chose en dur pourquoi ne pas rendre non-executable tout les fichiers de /etc/grub.d pour ne garder que celui qui t'intéresse.
C’est comme la solution que j’ai mise en place pour mon utilisateur, ça ne résiste pas forcément à une mise à jour du paquet Grub. J’ai considéré que ça devait arriver moins souvent que les mises à jour du noyau, mais ce n’est pas pleinement satisfaisant pour autant.
Tu trouve que c'est une torture mais ça permet à un tas de monde de faire précisément ce qu'ils veulent.
Allez, le conseil de la doc officielle de Grub 2 pour la question de l’ordre du menu : grub-mkconfig does have some limitations. While adding extra custom menu entries to the end of the list can be done by editing /etc/grub.d/40_custom or creating /boot/grub/custom.cfg, changing the order of menu entries or changing their titles may require making complex changes to shell scripts stored in /etc/grub.d/. This may be improved in the future. In the meantime, those who feel that it would be easier to write grub.cfg directly are encouraged to do so (see Booting, and Shell-like scripting), and to disable any system provided by their distribution to automatically run grub-mkconfig.
Et si tu ne fais pas l'effort de lire ce que j'écris je vois pas pourquoi je continuerais
Effectivement, tu n’as pas compris mon point. Ce n’est pas de chercher la solution à mes problèmes. C’est juste de montrer qu’il y en a un certain nombre qui peuvent se poser.
Hors ce sont des problèmes créés, la manière la plus simple de les résoudre est de ne pas les créer !
Autant grub-mkconfig est tout-à-fait légitime à l’installation du système pour créer la configuration de base, autant regénérer la configuration à chaque mise-à-jour du noyau est disproportionné. La solution utilisée sur les Mandrake il y a plus de 10 ans résout la question de la mise-à-jour de manière pleinement satisfaisante et beaucoup plus simple.
Tout le temps passé à résoudre des problèmes créés et évitables est du temps qu’on ne passe pas à résoudre des problèmes réels ou à faire quoique ce soit d’autre de plus intéressant.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Et sinon tu as encore des arguments ? Parce que simplement dire que c'est plus compliqué alors que je viens de poster une solution à chaque cas d'usage que tu as décrit sans y passer beaucoup de temps c'est assez ironique.
Et si je veux conserver un noyau particulier dans /boot, mais sans qu’une entrée lui soit crée ?
Et si je veux changer l’ordre des entrées du menu sur une machine en multiboot ?
Le moyen que j’ai trouvé au moment était de modifier les priorités dans /etc/grub.d, mais je ne suis pas certain que ça survive à la mise à jour du paquet de Grub.
Peut-être encore des problèmes auxquels tu trouverais une solution, sauf qu’avec un fichier de configuration fixe, c’est immédiat, on édite simplement le fichier, il n’y a pas à chercher de solution.
À un certain stade, la conclusion logique d’avoir à trouver autant de solutions, c’est que grub-mkconfig est le problème.
Comme je l'ai déjà dit on passe d'une tambouille absolument pas kiss (la modification du fichier probablement à coup d'une armée de regex) et spécifique à chaque distribution à un système bien plus souple, bien plus fiable et upstream. Il ne demande qu'à être hacké.
Franchement, je suis sûr que j’aurais fait plus vite à faire un script qui fait à coups de regex le même boulot que celui de Fedora pour Grub 0.9 qu’à maîtriser la logique tordue de grub-mkconfig avec plusieurs fichiers de configuration de plusieurs niveaux et plein d’automatismes qui ne sont pas tous prévus pour être paramétrables.
Si tu cherches de la simplicité d'utilisation plutôt que de la souplesse et du kiss, ubuntu et mandriva sont faites pour toi pas arch. :-)
Merci, je m’arrange bien avec Arch, ils ont même réussi à faire une doc utilisable pour Grub 2, c’est dire. La distrib qui me donne des boutons, c’est Debian : comme grub-mkconfig, elle aime bien apporter des solutions compliquées à des problèmes que je préférerais qu’une distribution ne prenne pas en charge du tout.
Quant à ta définition de KISS, je n’ai pas la même.
Si c’est KISS, le principe doit pouvoir se décrire succinctement.
Exemples :
– « Le fichier de configuration est fixe », c’est KISS.
– « Le fichier de configuration est mis à jour en même temps que le noyau avec une entrée de menu qui reprend les paramètres de la précédente », c’est un peu moins KISS.
– pour grub-mkconfig… je sèche.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Ne prends pas mon expérience comme parole d'évangile. Je ne savais peut être pas me servir de grub 0.97.
Rien à voir : il ne faisait pas ce boulot, il se contentait de prendre en compte son fichier de configuration. C’est le script post-install du paquet du noyau qui s’occupait de sa mise à jour.
Mais mis à part ça pense-tu encore que grub2 va te virer des fonctionnalités ?
Sous Arch, non : il me suffit de ne pas utiliser le script de génération de la configuration.
Sous Fedora oui, le script post-install du noyau de Fedora pour Grub 0.9 couvrait 95 % des fonctionnalités potentiellement utiles (je parle au passé, parce qu’il me semble que la dernière version est passée à Grub 2). Le script de génération de Grub 2, seulement 80 %. Et pour le reste, il faut trouver un moyen plus compliqué de le faire, puisque le fichier de configuration est susceptible de sauter complètement à chaque mise à jour.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Avant je perdais tout et il fallait que je me souvienne de mes modif' (ou que je maintienne un diff).
Ah quand même !
Debian trouve toujours le moyen de me surprendre… mais pas souvent dans le bon sens.
Fedora gérait ça correctement.
La solution Arch est profondément idiote. Il m'arrive de m'amuser avec de la compilation de noyau. Je crée des paquets je les installe, je reboot ça marche super, ça marche pas je boot sur le précédent.
Ça fait des années que j’ai arrêté de compiler mes noyaux.
Mais si je le faisais encore, même si je leur faisait un paquet, je ferai en sorte que le résultat s’appelle vmlinux-user ou quelque chose du genre. Ça suffirait pour qu’en cas de problème, je puisse démarrer sur le noyau standard et downgrader le mien.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
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.
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
Mais pourquoi veux-tu faire générer le fichier de grub2 si tu ne le veux pas ? Tu peux très bien l'écrire à la main comme avant, ça marche aussi et ce n'est pas plus compliquer qu'avant.
J’y pense pour Arch, maintenant que j’ai vu cette doc.
D’un autre côté, je vais avoir à configurer pour le boulot d’autres distributions avec Grub 2 et là je suis moins sûr de pouvoir échapper à la configuration automatique. À voir…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Certains s'en réjouiront, mais pas moi. Le nouveau Grub me semble aussi confus que la page du wiki qui lui est consacrée.
D’un autre côté, elle est plus claire que la dernière que j’ai vue, dont j’avais conclu qu’il y avait plein de fichiers de configuration… mais aucun qui soit prévu pour qu’on puisse configurer (!), entre le fichier généré qu’il ne faut pas modifier parce qu’il est généré et les autres fichiers qui peuvent permettre d’influencer la génération, mais pas de manière immédiate.
Cela dit, je trouve aussi que c’est un recul de plus par rapport aux principes KISS. Je ne migrerai peut-être pas avant d’avoir besoin d’une fonctionnalité que Grub 0.9 ne supporte pas. Faute de mieux, il reste dans AUR (pour ceux qui ne sont pas familiers d’Arch, c’est les contributions)…
Ça y est, on tire à bout portant sur /etc/rc.conf, le fichier de configuration de ce qu'était Arch linux. Il est malade depuis un bout de temps. Cela a commencé insidieusement. Une variable a été supprimée, remplacée par un fichier de configuration indépendant. Puis une autre, et encore une autre, et ainsi de suite jusqu'à ce qu'il ne reste là-dedans que quelques lignes, comme en guise de souvenir.
Et en passant à systemd, la parallélisation du démarrage fera gagner… le temps perdu à lire plus de fichiers.
Il y a un moment (la Fedora de l’époque ne l’utilisait pas réellement), j’avais configuré systemd en mode natif (en gardant la possibilité de démarrer aussi avec rc.sysinit) ; ça marchait plutôt bien, jusqu’à ce que NetworkManager (qui vient aussi de chez Fedora/RedHat…) parte complètement en sucette avec. Vu la complexité de déboguer un tel problème avec systemd, j’ai choisi de m’en tenir à NetworkManager sans systemd, peut-être pas le meilleur des deux, mais celui dont j’avais vraiment besoin.
Bon, j’ai réessayé de booter sur systemd il y a quelques jours, ça remarche avec NetworkManager…
Au niveau temps de démarrage, j’avais chronométré, le démarrage prenait à peu près autant de temps à une seconde près, mais avec le système d’init BSD, je démarre pas mal de services en tâche de fond.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Tout ça pour dire, un bon p'tit coup de NTP et pas besoin de tous ces trucs de relativité.
Sauf que la majorité des serveurs NTP de niveau 1 se synchronisent sur le système GPS.
(Pour ceux qui ne connaissent pas NTP : les serveurs de niveau 2 se synchronisent sur des serveurs de niveau 1, ceux de niveau 3 sur des serveurs de niveau 2…)
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Pareil avec Intel.
Depuis quelques versions du noyau, sur mon portable (chip GM965), une fois sur deux l’écran devient noir un peu après le début du boot (enfin vide, le rétroéclairage n’est pas coupé). Heureusement que j’utilise X.org et pas le mode texte : c’est X.org qui relance l’affichage.
Bref, malgré tout le boulot fait sur les drivers graphiques, ce n’est pas encore ça…
Ce serait pas mal pour ceux qui ne cherchent pas des performances 3D délirantes qu’il existe un chip graphique bateau, mais bien supporté. C’est un peu ce qu’on attendrait d’Intel (vu qu’au niveau des performances, ils ne sont pas dans le peloton de tête), mais ils préfèrent faire 36000 versions, comme les marques de pointe.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Grâce à la concurrence (c’est-à-dire avant que Free n’ait besoin des bénéfices de l’ADSL pour construire son réseau de téléphonie mobile), des FAI pas trop chers, on en a (et encore, ça a plutôt augmenté).
Mais fiables, quel que soit le prix…
En fait, les pannes ne sont pas tellement fréquentes, c’est juste que quand ça t’arrive, ça ne les intéresse pas de réparer, ça leur coûte cher, alors tu es dans la m…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Uniformisation
Posté par Arthur Accroc . En réponse au journal Pourquoi Ubuntu Unity est extraordinaire. Évalué à 8.
C’est peut-être intéressant sur un netbook. Sur un écran de 1200 pixels de haut (il date d’avant l’hégémonie de la « HD »…), c’est anti-ergonomique.
Le problème est de viser la même interface partout (que ce soit Gnome 3 ou Unity), alors qu’une machine de bureau avec clavier, souris et écran 24″, ça n’est pas la même chose qu’une tablette 7″ — voire un smartphone — avec surface tactile, pas de clavier et pas de souris.
Je suis bien content que mon PC n’ait pas la même interface que mon téléphone et vice-versa.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Chasse
Posté par Arthur Accroc . En réponse au journal Source Sans Pro : nouvelle police libre d'Adobe. Évalué à 3.
Tu as essayé la version actuellement disponible et à chasse variable de Source Sans ou la version à chasse fixe encore en développement ?
Parce que de toute façon, une police à chasse variable, pour du code…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Gloubi-boulga
Posté par Arthur Accroc . En réponse au journal Debian Wheezy passe à XFCE ?. Évalué à 3.
C’est con que cette évolution n’ait pas eu lieu avant que les portables aient adopté un format d’écran qui n’est adapté qu’à la lecture de DVD…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Version monowidth
Posté par Arthur Accroc . En réponse au journal Source Sans Pro : nouvelle police libre d'Adobe. Évalué à 3.
Longtemps, je n’ai pas supporté les polices vectorielles pour leur manque de netteté à l’écran. Avec le « hinting » à fond, même sans gestion des sous-pixels, elles deviennent à mon avis beaucoup plus fréquentables (même la DejaVu Sans Mono, alors qu’à la base je trouve la série DejaVu bien plus réussie pour l’impression que pour l’affichage).
Quant à la Terminus, j’ai deux reproches à lui faire, un gros et un petit :
– les lignes sont trop serrées ;
– la graphie assez carrée des caractères limite les lignes en biais donc l’aspect crénelé, mais ça colle aussi un peu plus les caractères avec leurs voisins, je trouve que ça nuit un peu à la lisibilité.
Moralité : pour mes terminaux, j’en suis resté à la bonne vieille Fixed en SemiCondensed taille 10. Elle fait la même largeur que la Terminus taille 9, mais avec les lignes un peu plus espacées et sans aplatissement des majuscules et des symboles hauts (parenthèses, accolades…).
Pour les éditeurs, je préfère une fonte légèrement plus grosse, donc suivant les conditions de rendu (« hinting », rendu sous-pixel), j’oscille entre une fonte vectorielle et la Fixed en 11 (un peu trop grosse à mon goût).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Grub
Posté par Arthur Accroc . En réponse au journal Arch et le tournant. É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 Arthur Accroc . En réponse au journal Arch et le tournant. É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 Arthur Accroc . En réponse au journal Arch et le tournant. É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 Arthur Accroc . En réponse au journal Arch et le tournant. É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 Arthur Accroc . En réponse au journal Arch et le tournant. É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
[^] # tree
Posté par Arthur Accroc . En réponse au journal Mon point de vue sur Archlinux. Évalué à 3.
Sauf que le résultat de la vraie commande tree ressemblerait plutôt à :
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Grub
Posté par Arthur Accroc . En réponse au journal Arch et le tournant. É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 Arthur Accroc . En réponse au journal Arch et le tournant. É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 Arthur Accroc . En réponse au journal Arch et le tournant. É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 Arthur Accroc . En réponse au journal Arch et le tournant. É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
[^] # En fait, pas de problème sous Arch
Posté par Arthur Accroc . En réponse au journal Arch et le tournant. É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: Grub
Posté par Arthur Accroc . En réponse au journal Arch et le tournant. É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
# Grub, rc.conf, systemd
Posté par Arthur Accroc . En réponse au journal Arch et le tournant. É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: Grand classiques…
Posté par Arthur Accroc . En réponse au journal L'esprit UNIX, une culture des mots. Évalué à 2.
C’est pas ma maman, c’est au boulot…
Ou il y a quelques années en version Yahoo. J’ai eu ça aussi.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Proximité géographique?
Posté par Arthur Accroc . En réponse au journal L'ordinateur le plus puissant d'Europe sous SuSE Linux Enterprise Server !. Évalué à 3.
Peut-être qu’il est mieux si tu t’adresses directement à SUSE Allemagne en allemand…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Grand classiques…
Posté par Arthur Accroc . En réponse au journal L'esprit UNIX, une culture des mots. Évalué à 4.
Mieux : « Je n’ai plus Internet » quand c’est le raccourci du navigateur web (je suis sûr que celui-là plaît à Tanguy…).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Contraste !
Posté par Arthur Accroc . En réponse au journal UU.zoy.org, le site qui vous a à la colle.. Évalué à 3.
Le projet est sympa, mais il y a un détail qui me chagrine : avec des couleurs pâles sur fond pastel, le résultat manque cruellement de contraste !
Le résultat en capture d’écran.
À comparer par exemple à gedit ou mieux (sur fond noir, plus reposant, même si ce n’est pas à la mode) : gvim et geany.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Raté !
Posté par Arthur Accroc . En réponse au journal 5-sigma: le boson de Higgs est débusqué !. Évalué à 3.
Sauf que la majorité des serveurs NTP de niveau 1 se synchronisent sur le système GPS.
(Pour ceux qui ne connaissent pas NTP : les serveurs de niveau 2 se synchronisent sur des serveurs de niveau 1, ceux de niveau 3 sur des serveurs de niveau 2…)
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Les bons exemples...
Posté par Arthur Accroc . En réponse au journal Gnome3 et systemd, c'est la fin des haricots!. Évalué à 1.
Le truc imbitable à configurer.
La passoire de sécurité.
Deux trucs que je ne mets pas ou que je vire dans la mesure du possible.
Je n’avais pas d’opinion tranchée, mais tu m’as convaincu.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Intel
Posté par Arthur Accroc . En réponse au journal Quand Linus énervé, Linus faire ça !. Évalué à 5.
Pareil avec Intel.
Depuis quelques versions du noyau, sur mon portable (chip GM965), une fois sur deux l’écran devient noir un peu après le début du boot (enfin vide, le rétroéclairage n’est pas coupé). Heureusement que j’utilise X.org et pas le mode texte : c’est X.org qui relance l’affichage.
Bref, malgré tout le boulot fait sur les drivers graphiques, ce n’est pas encore ça…
Ce serait pas mal pour ceux qui ne cherchent pas des performances 3D délirantes qu’il existe un chip graphique bateau, mais bien supporté. C’est un peu ce qu’on attendrait d’Intel (vu qu’au niveau des performances, ils ne sont pas dans le peloton de tête), mais ils préfèrent faire 36000 versions, comme les marques de pointe.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Fiable ?
Posté par Arthur Accroc . En réponse au journal Le SAV d'Orange ? Nul à ch*er !. Évalué à 4.
Grâce à la concurrence (c’est-à-dire avant que Free n’ait besoin des bénéfices de l’ADSL pour construire son réseau de téléphonie mobile), des FAI pas trop chers, on en a (et encore, ça a plutôt augmenté).
Mais fiables, quel que soit le prix…
En fait, les pannes ne sont pas tellement fréquentes, c’est juste que quand ça t’arrive, ça ne les intéresse pas de réparer, ça leur coûte cher, alors tu es dans la m…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone