Journal Vive la simplification !

Posté par .
Tags : aucun
15
3
juil.
2010
Ce pourrait être un journal du vendredi, mais non.

Ce petit mémo juste pour relater quelques déboires arrivés lors de l'installation d'une Lucid Lynx sur un ordi de bureau tout neuf. Et au passage demander un petit coup de main s'il y a unubuntu-maniaque dans la salle.

Donc installation par clé usb (unetbootin) d'une LL 64 bits.

Disons-le tout net : bluffant ! Fabrication de la clé bootable, installation, partitionnement, etc., tout bien.

Temps de démarrage de quelques secondes entre le BIOS et le login graphique.

Jusqu'à présent, ça va.

Ont été reconnus sans histoire la carte réseau, la carte graphique ATI RS880 [Radeon HD 4200] avec le driver libre (effets 3D assurés), le son, la webcam, l'imprimante Samsung laser couleur clp-315 (juste le problème qu'elle imprime beaucoup trop sombre en couleur, mais le problème est le même avec toutes les distributions). On pourrait critiquer que l'imprimante scanner combinée brother cdp-135c ne soit pas installée automatiquement, mais les paquets d'impression sont dispo, et l'outil graphique d'installation fonctionne. Il y a juste les paquets de scanner qui ne sont pas dispo, et on se demande pourquoi (il faut aller chez Brother et bidouiller un peu à la main les fichiers de config).

Si on veut vraiment chipoter, l'outil graphique de KDE propose les paramétrages de "L'imprimante" (pourquoi n'y en aurait-il qu'une seule ?), et propose l'installation d'une nouvelle imprimante réseau, mais pas USB. Sentant la ruse (de toutes façons, il n'y a guère d'autre choix), je demande l'installation de l'imprimante réseau, et on me propose, à ce moment-là seulement, l'installation de l'imprimante USB. Des malins, je vous dis !

Là où ça se gâte, c'est pour la définition de l'écran. La machine est raccordée à un écran 1600x1024 qui a la particularité de ne pas renvoyer d'information sur sa définition. Vu que tout est automatique, je me retrouve avec du 1024x768. Pas vraiment sympa.

Le bidule graphique basé sur xrandr ne dit pas mieux. Et je ne trouve pas d'outil de configuration.

Connaissant le problème, je me dis que je vais ajouter

# 1600x1024 @ 60.00 Hz (GTF) hsync: 63.60 kHz; pclk: 136.36 MHz
Modeline "1600x1024_60.00" 136.36 1600 1704 1872 2144 1024 1025 1028 1060 -HSync +Vsync

à mon xorg.conf (merci gtf).

Souci, il n'y a pas de xorg.conf (on vous l'a dit : c'est moderne !)

Je suis donc amené à lancer X -configure sur une console de texte, X étant fermé, pour créer un xorg.conf.

Nouveau souci : il n'y a pas de bouton pour quitter X. J'ai tenté des "init" avec un petit chiffre, mais rien ne m'a rendu la main avec une console texte pure.

Pas de problème : je vais redémarrer l'ordinateur en mode réparation. Zut ! Je n'ai pas de menu de GRUB. Pas moyen d'intervenir sur le démarrage.

OK OK, têtu comme je suis, je me dis que je vais bidouiller le fichier menu.lst de GRUB, mais encore non ! Il n'y a pas de menu.lst (ce qui explique peut-être qu'il n'y ait pas de menu à l'écran lors du démarrage). Automatique, on vous dit !

Donc, ça devient assez compliqué d'effectuer cette tâche autrefois simple. J'ai peur de me planter en bricolant un xorg.conf incompatible et de ne plus pouvoir redémarrer, vu le peu de maîtrise que j'ai sur le système.

J'attends les rigolards me répondre : "bien fait, gros nase, ubuntu, c'est tout pourri ! Tu n'avais qu'à mettre archfedosuse" ou ce genre de chose. Malheureusement, mon expérience m'a montré qu'il n'en est rien (je n'en suis pas à ma première installation !).

Quand je compare à la tant décriée Mandriva, ce n'est ni mieux, ni pire.

On touche là la principale raison pour laquelle les assembleurs ne veulent pas mettre de Linux à leurs clients : ils ne veulent pas passer une journée entière à finaliser le bazar sur une machine où, il faut bien le reconnaître, 99% des choses s'installent facilement du premier coup.

Quant aux "Mme Michu", n'ayant pas le réflexe google et voulant un fonctionnement sans faille sans taper la moindre commande, ce genre de mésaventure risque de les décourager rapidement.

Bientôt 20 ans après, Linux, ça se mérite toujours !
  • # xrandr

    Posté par . Évalué à 10.

    Tu pourrais créer la résolution pour ton écran externe avec la commande xrandr sans avoir à tripatouiller ton xorg.

    Cela étant, je partage ton amertume quant à l'automatisation à outrance, en fait, l'automatisme en soit ne me dérange, au contraire, mais avoir supprimé les voies habituelles qui fonctionnaient plutôt bien, ça m'emmerde, pour le dire simplement. :)
    • [^] # Re: xrandr

      Posté par . Évalué à 6.

      Ah tiens, une réflexion que je me suis faite, la première fois que j'ai constaté que le xorg.conf de la v1.6 (?) était obsolète, que Grub2 ne faisait plus de menu.lst.

      Mais c'est aussi trés général. Ca forke, évolue, mais ce genre de soucis est plutot le quotidien. C'est un paradoxe qui mérite d'être étudié, parce que généralement, nous libriste on aime bien capitaliser sur l'apprentissage, mais on change assez souvent de structures, sans forcément que ce soit pertinent.

      Pour xorg.conf, si tu le crées, il le prendra normalement en compte.
      • [^] # Re: xrandr

        Posté par . Évalué à 2.

        Un peu le même genre de problème quand j'ai voulu migrer une Hardy LTS vers Lucid Lynx.
        En gros je me suis tapé tous les problèmes qui sont apparus au fil des versions entre ces 2 LTS.
        Pour le xorg j'étais embêté vu que ma machine n'est connectée à aucun écran et faisait office de "serveur" mais je trouvais pratique de pouvoir lancer des applis X ou un vnc. Du coup je me suis résolu à supprimer tous les paquets graphique vu que j'étais incapable de démarrer une session X sans écran. (et bon courage pour avoir la liste des paquets à supprimer pour passer d'une Ubuntu desktop à une Ubuntu server).
        Pour grub2, c'est clair que c'est + complexe à configurer, mais bon on s'y fait...
        • [^] # Re: xrandr

          Posté par . Évalué à 5.

          Pour grub2, c'est clair que c'est + complexe à configurer, mais bon on s'y fait...

          Plus complexe ? Je ne crois pas .... C'est différent, certes mais pas plus complexe. Celà dit Grub2 fait plus de choses donc c'est normal que ça paraisse plus complexe.
    • [^] # Re: xrandr

      Posté par . Évalué à 4.

      En effet, j'ai le même soucis sauf que de mon côté ça vient de ma carte qui n'est pas encore bien supportée (ATI Mobility Radeon HD 5450). Du coup j'ai un script qui est exécuté au lancement de GNOME et me configure mon écran externe comme il faut s'il est branché.

      #!/bin/sh

      XRANDR=/usr/bin/xrandr
      GREP=/bin/grep

      INTERNAL_OUTPUT="LVDS"
      EXTERNAL_OUTPUT="VGA-0"


      $XRANDR -q | $GREP $EXTERNAL_OUTPUT | $GREP " connected "
      if [ $? -eq 0 ]; then
      $XRANDR --newmode "1680x1050@74.9" 187.00 1680 1800 1976 2272 1050 1053 1059 1099 -HSync +VSync
      $XRANDR --addmode $EXTERNAL_OUTPUT "1680x1050@74.9"

      $XRANDR --output $EXTERNAL_OUTPUT --mode "1680x1050@74.9"
      $XRANDR --output $INTERNAL_OUTPUT --mode "1366x768"
      $XRANDR --output $EXTERNAL_OUTPUT --left-of $INTERNAL_OUTPUT
      $XRANDR --output $INTERNAL_OUTPUT --pos "1680x282"
      fi


      exit 0
      • [^] # Re: xrandr

        Posté par . Évalué à 4.

        Tu pourrais aussi faire un bugreport, car normalement ce genre de problème ne devrait pas arriver. Ça peut venir de driver graphique, comme t'es sûr une carte assez récente.

        PS: en disant ça j'ai supposé que tu utilises le driver libre (radeon), tu peux aussi essayer pour le proprio mais le résultat est moins garanti
        • [^] # Re: xrandr

          Posté par . Évalué à 1.

          Pour ma part, les Ubuntu récentes n'a jamais voulu marcher avec mes PCs à base de Geforce 2 (driver nvidia-legacy). Bref, suis resté sur une Debian que j'ai configuré comme il fallait plutôt que de partir sur une Ubuntu que j'aurais dû dé-configurer...

          Autre souci : avec l'écran de mon père (un Samsung T190 qui renvoie également des informations EDID erronées), je m'en suis sorti avec les trucs suivants dans xorg.conf (tout n'est peut-être pas nécessaire, mais j'ai tâtonné... Je crois que c'est le DisplaySize qui a été déterminant dans mon cas) :

          Section "Device"
          Identifier "Configured Video Device"
          Driver "nvidia"
          Option "IgnoreEDID" "True"
          Option "UseEdidFreqs" "False"
          Option "ModeValidation" "NoDFPNativeResolutionCheck,NoMaxPClkCheck, NoEdidMaxPClkCheck"
          Option "UseEdidDpi" "FALSE"
          # Option "ModeValidation" "NoMaxPClkCheck, NoEdidMaxPClkCheck"
          Option "AddARGBGLXVisuals" "True"
          Option "AllowGLXWithComposite" "True"
          EndSection

          Section "Monitor"
          Identifier "Configured Monitor"
          HorizSync 30.0 - 81.0
          VertRefresh 56.0 - 75.0
          DisplaySize 431 269
          Option "CalcAlgorithm" "XServerPool"
          Option "DPMS"
          UseModes "Modes[0]"
          EndSection

          Section "Modes"
          Identifier "Modes[0]"
          ModeLine "1440x900" 106.5 1440 1520 1672 1904 900 901 904 932
          EndSection

          Section "Screen"
          Identifier "Default Screen"
          Monitor "Configured Monitor"
          DefaultDepth 24
          SubSection "Display"
          Depth 24
          Modes "1440x900"
          EndSubSection
          EndSection

  • # grub2

    Posté par . Évalué à 2.

    "OK OK, têtu comme je suis, je me dis que je vais bidouiller le fichier menu.lst de GRUB, mais encore non ! Il n'y a pas de menu.lst (ce qui explique peut-être qu'il n'y ait pas de menu à l'écran lors du démarrage). Automatique, on vous dit !"

    Ubuntu n'utilise pas grub2 ? Donc /boot/grub/grub.cfg si je me souviens bien. (pas sur qu'il soit sage de l'editer directement par contre)
    • [^] # Re: grub2

      Posté par . Évalué à 7.

      En effet, il ne faut pas éditer ce fichier à la main, il vaut mieux éditer les /etc/default/grub2, /etc/grub.d/*...
      • [^] # Re: grub2

        Posté par . Évalué à 10.

        C'est là que j'aime encore plus lilo et son /etc/lilo.conf très KISS.

        On a beau dire que c'est ennuyant de devoir penser à relancer la commande "lilo", je trouve que c'est tout de même largement moins contraignant que lorsque l'on doit s'amuser avec la configuration de plus en plus improbable et éparpillée de grub.

        Maintenant, dépanner une Ubuntu me parait presque aussi frustrant que de dépanner un Windows : je n'ai rien contre l'automatisme, sauf quand celui-ci restreint de plus en plus la possibilité de configurer soi-même son système.

        De nos jours, les fichiers de configuration sont de plus en plus conçus pour une interface graphique, donc, quand celle-ci montre ses limites... aïe.

        Un « parfait » exemple : gstreamer. Il s'obstinait à vouloir utiliser ALSA alors que j'utilise OSSv4. Sa configuration, chez moi, c'est : ~/.gstreamer-0.10/registry.x86_64.bin (comme son nom l'indique, c'est inconfigurable avec un éditeur de texte). Magnifique. Comment configurer ça ? Uniquement avec l'interface de KDE ou GNOME. Oui oui, je pense vraiment avoir bien regardé la doc[1] ; ça ne peut être manuellement configuré qu'avec une interface graphique (à moins, peut-être, de le compiler avec gconf, chose dont je ne veux pas non plus parce que tout aussi aberrante à mes yeux). Donc j'ai du installer KDE4 parce que gstreamer n'a pas su détecter automatiquement que j'utilisais OSS et pas ALSA. (Sous ubuntu c'est encore pire lorsque l'on veut configurer son système audio et que l'on souhaite avoir la liberté de ne pas utiliser PulseAudio : [2])

        [1]: http://www.gstreamer.net/data/doc/gstreamer/head/faq/html/ch(...)
        [2]: https://bugs.launchpad.net/ubuntu/+source/gnome-media/+bug/4(...)

        Alors maintenant, si l'on construit le système *d'abord* autour des interfaces graphiques et que l'on préfère partir du principe que l'automatisme sera parfait parce que, de toutes façons, « l'utilisateur est un idiot », bah... moi j'ai l'impression de perdre, petit à petit, une liberté que m'apportait aussi le logiciel libre : celle de garder le contrôle de mon système.

        Quelques citations pour la route :
        "This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface." – Doug McIlroy
        "Unix is simple. It just takes a genius to understand its simplicity." – Dennis Ritchie
        "Those who don't understand UNIX are condemned to reinvent it, poorly." – Henry Spencer

        GRUB3 will be Elisp serialized as XML jited to JVM running as Eclipse plugin on a Mac running in a virtual PC in a Xen instance on a 286er.

        • [^] # Re: grub2

          Posté par . Évalué à 7.

          De nos jours, les fichiers de configuration sont de plus en plus conçus pour une interface graphique, donc, quand celle-ci montre ses limites... aïe.

          .... Merci qui ? Merci XML!!!
        • [^] # Re: grub2

          Posté par . Évalué à 5.

          Deux solutions pour les gens comme nous :
          - se tourner vers les distrib' qui gardent ce mode de pensée comme archlinux, debian, zenwalk (je crois) ou gentoo (bien sur pour les logiciels qui ne sont vraiment pas fait pour alors c'est mort)
          - se tourner vers d'autres OS les BSD par exemple

          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

          Posté par . Évalué à 2.

          De nos jours, les fichiers de configuration sont de plus en plus conçus pour une interface graphique, donc, quand celle-ci montre ses limites... aïe.

          Non, le plus pénible avec les GUI de configuration, c'est qu'elles écrasent l'existant.

          Du genre: tu cliques tu cliques tu cliques pour utiliser un AP WiFi, tu mets ta clef. Bon. Tu regardes le contenu de /etc/network/interfaces: rien n'a changé.

          Pour rappel (je le dis aux gens qui développent les GUI de config du réseau sous Gnome et KDE), sur les distros basées sur Debian, le fichier /etc/network/interfaces sert à stocker la configuration du réseau. Elle n'a rien à foutre dans ~/.gnome2/gnome.d/gconf.xml/whatever.

          THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

          • [^] # Re: grub2

            Posté par . Évalué à 4.

            Ce n'est ni le travail de KDE, ni le travail de GNOME.
            C'est le boulot du Network Manager…
            Perso je trouvais ça trop pénible donc je fais tout en console avec du ifup/ifdown, et ça «juste marche»…
    • [^] # Menu GRUB

      Posté par (page perso) . Évalué à 1.

      D'autre part si tu veux avoir accès au menu GRUB, il te suffit de presser ma touche Shift au démarrage.
      • [^] # Re: Menu GRUB

        Posté par (page perso) . Évalué à 3.

        En même temps si tu le sais pas, c'est pas ce qu'on appel "simple"
      • [^] # Re: Menu GRUB

        Posté par (page perso) . Évalué à 10.

        Donc faut venir chez toi pour presser sur ta touche shift ? C'est avec une IP codé en dur dans du code généré automatiquement qu'il ne faut pas éditer à la main que cette fonctionnalité est implémenté ? :)
      • [^] # Re: Menu GRUB

        Posté par . Évalué à 4.

        Le projet gnome a une philosophie qui s'applique parfaitement à ça :

        Les fonctionnalités qui ne se voient pas n'existent pas.

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

  • # Services...

    Posté par . Évalué à 6.

    Nouveau souci : il n'y a pas de bouton pour quitter X. J'ai tenté des "init" avec un petit chiffre, mais rien ne m'a rendu la main avec une console texte pure.
    C'est si compliqué d'arrêter le service kdm/gdm ?

    Je veux dire, je fais ça sur diverses distribs depuis au moins 4 ans, le init N n'a jamais été un gage de bon fonctionnement (exemple : debian par défaut en init 2 y compris avec le serveur X, alors qu'un init 2 sur une mandriva va arrêter le serveur X).

    P.S : "service kdm stop" sur ubuntu
    • [^] # Re: Services...

      Posté par . Évalué à 1.

      ou "sudo stop kdm"

      ou "telinit 1"

      pour les méthodes violentes. Sinon fermer la session et utiliser le menu de kdm pour passer en mode console.
  • # Arrêter X11

    Posté par . Évalué à 2.

    Pour gnome :
    service gdm stop

    Sous kde je ne sais pas, mais service kdm stop sera peut être ton ami.

    La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".

  • # C'est ton écran

    Posté par . Évalué à 5.

    En fait si je comprends bien, la cause de tes soucis c'est ton écran pourri qui ne se conforme pas aux standards ? (Car je suppose qu'un écran répondant aux standards VESA ou n'importe quoi d'autres doit donner des informations sur lui-même à la carte). C'est quoi la marque de cet écran, qu'on en n'achète pas ?

    Sinon, Ubuntu utilise Grub2 donc il est possible que le fichier de conf est changé par rapport à Grub Legacy (/boot/grub/grub.conf ou menu.lst). De plus, si Grub n'apparait pas c'est sûrement parce que le timeout est trop court, mais si tu restes appuyer sur une touche flèche (par exemple) avant le grub, tu devrais pouvoir arriver le grub. Ça m'arrive parfois avec Grub Legacy sur Fedora lorsqu'aucun autre OS n'est présent sur le PC, dans ce cas inutile de mettre un timeout sur le Grub, ça fait perdre du temps au boot pour rien.
    • [^] # Re: C'est ton écran

      Posté par . Évalué à 2.

      En fait si je comprends bien, la cause de tes soucis c'est ton écran pourri qui ne se conforme pas aux standards ?

      Ca n'est pas forcément l'écran. Ca peut aussi être la carte graphique. J'ai déjà eu ce genre de problème avec un écran parfaitement détecté avec une carte et bloqué avec une résolution à la con avec une autre carte. Pourtant, En utilisant les info EDID (get-edid/parse-edid) l'écran donnait bien toutes les résolutions supportées.
      J'ai eu aussi le cas sur un portable : Info EDID correcte, résolution mal détectée.
      Il semble y avoir plusieurs méthodes pour remonter les infos sur ce que supporte un écran (EDID, DDC,...). Les résultats sont souvent différents. Tout dépend de ce que la carte/le driver de la carte utilise,
      • [^] # Re: C'est ton écran

        Posté par (page perso) . Évalué à 2.

        Autant essayer avec le driver proprio dans ce cas ?

        Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

        • [^] # Re: C'est ton écran

          Posté par (page perso) . Évalué à 4.

          J'ai ce problème avec mon portable, le résultat est le même avec un écran externe. Et il n'existe pas de driver proprio sous linux puisque c'est une intel.

          « 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: C'est ton écran

            Posté par (page perso) . Évalué à 2.

            Peut-être mais pour lui il y a des drivers proprios :
            Ont été reconnus sans histoire la carte réseau, la carte graphique ATI RS880 [Radeon HD 4200] avec le driver libre (effets 3D assurés)

            Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

        • [^] # Re: C'est ton écran

          Posté par . Évalué à 1.

          Pour l'écran, j'ai utilisé le driver Nvidia (Nouveau était encore très jeune). Pour le portable, c'était une puce intégrée Intel avec le driver libre. Même problème dans les deux cas.
        • [^] # Re: C'est ton écran

          Posté par . Évalué à 3.

          Et quand en plus on rajoute un kvm entre les deux…
  • # Évolution...

    Posté par . Évalué à 7.

    Hé oui, Linux évolue...

    Regarde, ils ont enlevé des trucs de /proc, c'est affreux, c'est parti dans /sys...
    Regarde, ton devfs est dynamique, c'est terrible.
    Diantre, où est mon /etc/lilo.conf ? Ha, c'est grub, donc /boot/grub/menu.lst ? Ho mon dieu, /boot/grub/grub.cfg ? Ça ne finira jamais ?

    Puis bon, sous Windows c'est pas mieux hein...

    Où sont les autoexec.bat, les command.com, les C:\Documents and Settings, le NTLDR...

    C'est vrai que c'est assez terrible pour nous "informaticiens" : étant donné le flot continu de changement, quand on regarde légèrement en arrière, on est vite impressionné et submergé par le nombre de changements....
    • [^] # Re: Évolution...

      Posté par . Évalué à 4.

      moi ce que j'aimerais comme évolution :
      - Une interface graphique qui ne crashe pas les fenêtres d'applications quand elle s'arrête.
      - Une interface graphique en CTRL+ALT+F7 , ou CTRL+ALT+F9 , mais qui me laisse la possibilité, pour d'autres ressources , d'en lancer une autre en CTRL+ALT+F8 ou CTRL+ALT+F10 ...
      - Des consoles virtuelles ( ttyv ) en mode texte toujours accessibles.
      - Dans les outils des gestionnaires de bureau, des machins qui touchent au système, à la compil, et aux choix de modules du noyau.
      - une simple console accessible permettant de lancer des applications graphiques, que ce soit une console texte ou un "fond d'écran+menu K/Gnome/XFCE "
      - un outil me permettant de réellement choisir les drivers à appliquer à tel ou tel matos, avec une sauvegarde simple du mode précédent. Pareil pour les logiciels-sous-couche aux applications ( ALSA, OSS ... )
      - Une interface facilement modulable pour réduire l'épaisseur de ces énormes bordures de fenêtres , ou de la même façon cliquer pour avoir la possibilité de restaurer la session ou de choisir, en fonction des sessions, le lancement de telle ou telle application.
      - Une possibilité de jouer avec toutes les résolutions d'écran, soit en " lissant " par le calcul la résolution obtenue, soit en laissant tel quel ( avec comme conséquences : pixellisation et flou sur les LCD ) .
      - plus généralement, la possibilité facilement de jouer avec toutes les entrées sorties, en désactivant simplement Bluetooth Webcam ou Wifi ,ou modifier le keymap " à la volée".
      - Pour les logiciels dispos dans les gestionnaires de paquets , tout ce qui existe aujourd'hui quelle que soit la distrib est suffisamment parfait pour ne plus y toucher.
      Udev, Hal, toussa, vis-àvis de ce qu'en fait l'utilisateur au quotidien, c'est un peu secondaire.

      Mais sinon, je suis d'accord avec l'auteur du journal: tout ce qui s'est passé ces 2 dernières années avec l'intégration de HAL et le nouveau grub a été très mal documenté , très mal expérimenté, et les méthodes "pour s'en sortir' sont beaucoup moins connues que lorsqu'il s'agissait de faire un simple X -configure , démarrer X avec ce xorg.conf.new , et le tuer à l'aide d'un CTRL+ALT+BACKSPACE .

      D'ailleurs sur le Web, à ce sujet, c'est le désert le plus total...
      Ce qui laisse un goût amer à ceux qui avaient l'habitude de s'appuyer sur " la communauté" pour comprendre les choses.

      Sedullus dux et princeps Lemovicum occiditur

      • [^] # Re: Évolution...

        Posté par . Évalué à 5.

        - Une interface graphique qui ne crashe pas les fenêtres d'applications quand elle s'arrête.
        +1, on peut espérer que dans le "mouvement DRI2" ce changement devienne implémentable...

        - Une interface graphique en CTRL+ALT+F7 , ou CTRL+ALT+F9 , mais qui me laisse la possibilité, pour d'autres ressources , d'en lancer une autre en CTRL+ALT+F8 ou CTRL+ALT+F10 ...
        - Des consoles virtuelles ( ttyv ) en mode texte toujours accessibles.

        Heu, il me semble avoir ça depuis des années. À une époque je faisais tourner Looking Glass sur un serveur X en Ctrl+Alt+F8, et j'avais encore mes consoles texte.

        - Dans les outils des gestionnaires de bureau, des machins qui touchent au système, à la compil, et aux choix de modules du noyau.
        Un make xconfig intégré à KDE ou Gnome ?

        - une simple console accessible permettant de lancer des applications graphiques, que ce soit une console texte ou un "fond d'écran+menu K/Gnome/XFCE "
        Yakuake ? Krunner ? Ou un retour de l'applet d'exécution d'une commande ça serait fun tiens, à coder si ça n'existe pas...

        - un outil me permettant de réellement choisir les drivers à appliquer à tel ou tel matos, avec une sauvegarde simple du mode précédent. Pareil pour les logiciels-sous-couche aux applications ( ALSA, OSS ... )
        Mauvais problème : il faudrait ne pas avoir de choix pour le pilote, avoir un seul pilote qui soit fonctionnel, libre, intégré au noyau, stable...

        - Une interface facilement modulable pour réduire l'épaisseur de ces énormes bordures de fenêtres , ou de la même façon cliquer pour avoir la possibilité de restaurer la session ou de choisir, en fonction des sessions, le lancement de telle ou telle application.
        Heu, il me semble qu'il y a tout ça dans KDE...

        - Une possibilité de jouer avec toutes les résolutions d'écran, soit en " lissant " par le calcul la résolution obtenue, soit en laissant tel quel ( avec comme conséquences : pixellisation et flou sur les LCD ) .
        Un écran LCD est fait pour une seule résolution, ne cherche pas...

        - plus généralement, la possibilité facilement de jouer avec toutes les entrées sorties, en désactivant simplement Bluetooth Webcam ou Wifi ,ou modifier le keymap " à la volée".
        Perso je change à la volée le keymap uniquement de mon typematrix avec un simple setxkbmap -device 42 fr bepo...

        Mais sinon, je suis d'accord avec l'auteur du journal: tout ce qui s'est passé ces 2 dernières années avec l'intégration de HAL et le nouveau grub a été très mal documenté , très mal expérimenté, et les méthodes "pour s'en sortir' sont beaucoup moins connues que lorsqu'il s'agissait de faire un simple X -configure , démarrer X avec ce xorg.conf.new , et le tuer à l'aide d'un CTRL+ALT+BACKSPACE .
        D'ailleurs sur le Web, à ce sujet, c'est le désert le plus total...

        C'est pire que ça : tu trouves pas d'aide parce que ça va dépendre de la distribution, de sa version et de l'âge du capitaine.
        Truc drôle : tu parles de l'intégration de HAL à X.org... Tu sais que ce n'est plus le cas désormais et que xorg.conf fait son retour sous la forme d'un dossier xorg.conf.d ?
        • [^] # Re: Évolution...

          Posté par . Évalué à 2.

          Truc drôle : tu parles de l'intégration de HAL à X.org... Tu sais que ce n'est plus le cas désormais et que xorg.conf fait son retour sous la forme d'un dossier xorg.conf.d ?

          Ca commence à être pénible cette façon de tout splitter comme ça ...
          • [^] # Re: Évolution...

            Posté par . Évalué à 2.

            Au contraire, il y a de nombreux cas où je trouve ça très pratique.
            Dans le cas de X.org ça permet de se retrouver avec un fichier de configuration par pilote plutôt qu'un gros fichier global, simplifiant donc la gestion des mises à jour en cas de modification des options par défaut d'un fichier de conf.
            Et y'a encore un xorg.conf "global" si nécessaire.
          • [^] # Re: Évolution...

            Posté par (page perso) . Évalué à 5.

            Ca commence à être pénible cette façon de tout splitter comme ça ...

            C'est ce qu'il y a de mieux pour ne pas que les mise à jour via ton système de paquet n'écrasent pas tes modifications personnelles. En plus, ça s'installe facilement avec les paquets (chaque driver ajoute son fichier au lieu d'en modifier un global) et tu peux facilement transférer un fichier de config d'un système à l'autre.

            « 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: Évolution...

          Posté par . Évalué à 4.

          Heu, il me semble avoir ça depuis des années. À une époque je faisais tourner Looking Glass sur un serveur X en Ctrl+Alt+F8, et j'avais encore mes consoles texte.
          Je me suis même amusé à lancer Gnome sur un Ctrl Alt F9 et KDE sur un Ctrl Alt F10 :)
          Le soucis, c'est qu'il y a des voix pour faire disparaître ça.


          Un make xconfig intégré à KDE ou Gnome ?
          oui, et plus que ça.
          Ce qui pose la question de la gestion des process graphiques qu niveau de l'userland. :)

          Yakuake ? Krunner ? Ou un retour de l'applet d'exécution d'une commande ça serait fun tiens, à coder si ça n'existe pas...
          plutôt au niveau de la console virtuelle ( tty1 par exemple ).
          Je n'ai aucune idée de comment faire ça mais oui, ça doit être fun à coder. :)


          Heu, il me semble qu'il y a tout ça dans KDE..
          ce qu'il manque à KDE, à ce niveau, c'est des tailles plus petites que la version " petite " .
          Je soupçonne les vieux dev d'avoir dépassé la cinquantaine et de souffrir de faiblesses visuelles . :)

          Un écran LCD est fait pour une seule résolution, ne cherche pas...
          oui mais il me semble que le serveur X est déjà capable de gérer ça ( simulation d'une résolution différente ) .

          Perso je change à la volée le keymap uniquement de mon typematrix avec un simple setxkbmap -device 42 fr bepo...
          oui ça existe aussi en graphique, mais ce qui n'existe pas, c'est le reste . ( avec une IHM j'entends )

          Tu sais que ce n'est plus le cas désormais et que xorg.conf fait son retour sous la forme d'un dossier xorg.conf.d ?
          oui , un peu tant mieux, mais juste que ça va être chaud de trouver des howto ( comment faire ) sur les divers choix , en dehors de l'installation automatisée. :)

          Sedullus dux et princeps Lemovicum occiditur

      • [^] # Re: Évolution...

        Posté par . Évalué à 10.

        C'est aussi le web qui évolue en minitel 2.0.

        Il y a 10 ans, tu trouvais des notices, des gens qui avaient joué avec leur système *et* pris le temps de documenter ca sur le net.

        Maintenant, ca doit exister, mais c'est aussi noyé dans la diarrhée des sites "à forte visibilité".

        Bref, de ce côté là aussi on a "évolué"....
    • [^] # Re: Évolution...

      Posté par . Évalué à 1.

      Oui, et c'est quoi l'intérêt de sortir des truc du /proc/ pour le mettre dans un /sys/ ? Mis à part changer continuellement les normes? Nan, parce que déjà le /srv/ et le /opt/ je trouve ça débile, mais là...

      Parce-que le problème, c'est que tu auras toujours un développeur qui va trouver que c'est mieux de mettre son fichier ici et pas là. Maintenant, si on veut la cohérence, va peut être falloir respecter une ou deux règles quand même. L'évolution c'est bien, mais quand on auras plus de trente répertoires sous / parce que chacun auras trouvé que c'est mieux d'avoir un /conf plutôt que /etc/ , on aura un système lourd, pénible à déplomber et sur lequel on as pas envie de développer.

      L'évolution c'est bien seulement quand ça part pas dans tout les sens.

      Quand à GRUB et LILO, les limitations du second on fait que le premier est devenu nécessaire. Après, rien n'empêche de faire un fork de LILO pour le remettre au gouts du jour!

      Keep It Simple!
      • [^] # Re: Évolution...

        Posté par . Évalué à 3.

        En fait c'était pas forcément très malin de mettre tout ce bordel dans /proc (d'où un surnom de /porc...) au départ.
        Donc on ne fait que corriger des erreurs du passé...
        • [^] # Re: Évolution...

          Posté par . Évalué à 3.

          Ouai, t'as raison, mettre toute la conf dans /etc/ c'est pas une bonne idée non plus. Non, puis mettre toutes les données utilisateur dans /home/ c'est con comme idée, faudrait créer un autre répertoire pour ça. Ha et puis sortir la doc de /usr/ ce serait pas mal. Pourquoi pas un /doc/ ? Et les log dans var, c'est nul : vive le /log/...
          bon, faisons un ls / :
          bin etc home lib media opt sbin srv users
          boot misc proc sys tmp usr system var conf
          cdrom dev initrd lost+found mnt root log doc

          Bon, ok, c'est un peu trafiqué, en réalité, ça fait plus chez moi...

          On peu en faire pas mal comme ça, mais je pense que revoir l'organisation à l'intérieur des répertoires de base serait plus profitable à Linux que d'ajouter un répertoire supplémentaire sur le / à chaque fois qu'il y'a un truc que tu trouve pas à sa place...

          Après, tout changer et tout réorganiser, pourquoi pas, ça donnera l'occasion de préparer Linux 3, ce qui ne serait peut être pas un mal, mais il faut arrêter de mettre dix mille répertoires sous / sinon ça va devenir un bordel sans nom!
          • [^] # Re: Évolution...

            Posté par . Évalué à 3.

            Le hurd supprime bien /usr hein.
            Et la présence d'éléments qui ne soient pas liées aux processus ou à l'aspect logiciel du système dans /proc est plus ou moins perturbante.
            Pourquoi avoir un /proc/acpi ? Je veux dire, quelle est la logique derrière ce placement ?

            Au passage, c'est mignon de taper sur /sys, mais ça date déjà de plus de 5 ans...
            • [^] # Re: Évolution...

              Posté par . Évalué à 2.

              Au passage, c'est mignon de taper sur /sys, mais ça date déjà de plus de 5 ans...
              Gros coup de vieux, ça fait 7 ans…
            • [^] # Re: Évolution...

              Posté par . Évalué à 2.

              Hurd c'est pas Linux : ça revient à ce que je disais : Quitte à changer l'arborescence, autant la revoir entièrement et le système avec. Ce serait une évolution réelle et pas simplement des pansement sur un système avec un long passé.

              Que l'histoire de /sys date de 7 ou 10 ans, c'est aussi con que /media, /cdrom et /mnt. C'est pas parce qu'une décision est vieille qu'elle n'est pas stupide.
              • [^] # Re: Évolution...

                Posté par . Évalué à 2.

                La décision de normaliser et simplifier l'accès à la configuration des pilotes et du noyau te paraît stupide ? Fichtre !
                Après, libre à toi de monter le sysfs où tu veux, même dans un /etc/sys si ça te plaît…
                • [^] # Re: Évolution...

                  Posté par . Évalué à 2.

                  Loin de moi cette idées, je ne suis pas suffisamment qualifié pour dire ce qui est bien ou pas dans le noyaux Linux.
                  Par contre, je ne voi pas le rapport avec le fait de rajouter un énième répertoire sous /. Et le fait est que sys et monté par défaut sur /, mis à par la flemme...
                  Maintenant, tu va me dire que /media et /cdrom et /mnt c'est plus mieux que de tout mettre par défaut dans /mnt hein? Je sais que nous autres informaticien sommes des feignasses (ben oui quoi! le but c'est quand même de faire bosser les machines à notre place le plus possible!), mais rajouter un /mnt/ devant cdrom, c'est pas la mort...

                  Alors oui, on peu le corriger soit même, mais ce serait bien d'avoir une arborescence de fichier simple et clair par défaut...
                  • [^] # Re: Évolution...

                    Posté par . Évalué à 2.

                    Je n'aime pas non plus la présence de /media, /cdrom ou /selinux par exemple hein.
                    Mais /sys me semble logique et légitime, c'est tout…
        • [^] # Re: Évolution...

          Posté par . Évalué à 4.

          Plus précisément, tout ce qui concerne le matos a bougé dans /sys. Ce qui concerne le kernel reste dans /proc.
      • [^] # Re: Évolution...

        Posté par (page perso) . Évalué à 2.

        Oui c'est ce qui est fait : http://www.pathname.com/fhs/ et les distributions respectent assez bien ça.

        "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

  • # Ubuntu n'est plus adaptée aux bidouilleurs et pas assez pour Mme Michu

    Posté par . Évalué à 1.

    Je commence à croire qu'Ubuntu est devenue trop automatisée, donc trop peu flexible, pour ceux qui aiment bidouiller leur système.

    Par contre pour le commun des mortels ce n'est pas suffisamment ergonomique :
    - encore un petit manque de cohérence dans le système qui persiste (les boutons "oui/non/annuler" qui changent de place - et parfois de noms - selon les applications).
    - on voit bien l'absence de politique d'accompagnement des assistants qui ont des styles différents (normal, c'est souvent des projets indépendants qui sont intégrés dans la distribution)

    Et puis il y a le sempiternel problème de pilotes, ça au moins ce n'est pas la faute des distributions, ni celle de la Fondation Linux. Tant que les constructeurs ne jouent pas le jeu, la situation ne changera pas.
  • # old school

    Posté par . Évalué à 7.

    je me rends compte que les vieux cons (les slackers toussa) sont au courant des bidouilles liées à hal, xorg, ... et savent toujours se démerder, même sur la pire des distribs qui soit disant ne laisse rien faire.

    Par contre M. et Mm. Michu, qui se disent gros g33k l33t5 parce qu'ils ont un Linux, ont raté une étape importante dans leur apprentissage : la veille technologique.

    Tous les soucis évoqués ici sont liés à l'évolution des outils en effet, comme ça a été évoqué. Évolution pas forcément dans le sens que certains aimeraient, mais en se tenant un minimum au courant des grosses nouveautés (comme cette histoire de "xorg.conf qui n'existe plus", un xorg magique, dingue non ?) on évite les journaux qui crachent sur une distrib qui en prend déjà plein la gueule pour des vrais raisons; inutile donc de faire de la diffamation.

    Signé, un Slacker qui n'a pas honte d'avoir une Ubuntu sur son laptop (même s'il n'en est pas forcément content, mais pour d'autres raisons).
    • [^] # Re: old school

      Posté par . Évalué à 1.

      Ubuntu c'est parce qu'il l'utilise mais je pense que personne n'est dupe sur le fond du problème, et n'assimile pas ça à une distro spécifique.
    • [^] # Re: old school

      Posté par . Évalué à 5.

      Bah justement ma Slack me laisse bien plus simplement bidouiller :) Mais je suis d'accord que l'on ne va pas demander à tout le monde d'utiliser une Slack ou distribution similaire pour avoir le contrôle de sa machine.

      Que la configuration soit un peu plus délicate à modifier sur une distribution qui a simplifié les choses pour la majorité des cas, c'est un compromis que je ne trouve pas du tout mauvais.

      Pour le xorg.conf, je trouve que ça va, par exemple. La détection automatique a l'air bonne, même sur des configurations assez exotiques, mais dans tout les cas, on a la possibilité de continuer à utiliser un xorg.conf (enfin, encore faut-il savoir comment le remplir, du coup). Et HAL s'en va.

      Mais ça devient inquiétant quand toute la configuration se fait en XML/base de registre/format binaire, ou que l'on perd en liberté de choix (se passer de PulseAudio sur les distributions user-friendly -- mais tu sais aussi que Pat doit "résister" de plus en plus pour garder son init à la BSD, ne pas avoir à inclure PAM et tout ce qui devient implicitement « standard » parce que poussé par les grandes distros, etc.).

      Signé un autre slacker que tu connais bien (mais pas vieux !)

      GRUB3 will be Elisp serialized as XML jited to JVM running as Eclipse plugin on a Mac running in a virtual PC in a Xen instance on a 286er.

      • [^] # Moins de XML avec X.org

        Posté par . Évalué à 2.

        Pour le xorg.conf, je trouve que ça va, par exemple. La détection automatique a l'air bonne, même sur des configurations assez exotiques, mais dans tout les cas, on a la possibilité de continuer à utiliser un xorg.conf (enfin, encore faut-il savoir comment le remplir, du coup). Et HAL s'en va.

        Mais ça devient inquiétant quand toute la configuration se fait en XML/base de registre/format binaire,


        En ce qui concerne xorg.conf justement, XML repart avec HAL. Et ce n’est pas moi qui vais le regretter !

        La configuration de mon touchpad, par exemple, est (re)passée de ça (je ne mets que le début) :
        <?xml version="1.0" encoding="UTF-8"?>

        <deviceinfo version="0.2">
          <device>
            <match key="info.capabilities" contains="input.touchpad">
            
              <merge key="input.x11_driver" type="string">synaptics</merge>
              <merge key="input.x11_options.SHMConfig" type="string">true</merge>
              <merge key="input.x11_options.MaxTapTime" type="string">200</merge>

        à ça :
        Section "InputClass"
           Identifier      "Touchpad"
           MatchIsTouchpad "on"

           Driver          "synaptics"
           Option          "SHMConfig" "true"
           Option          "MaxTapTime" "200"

        Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

  • # Réponses à tous

    Posté par . Évalué à 4.

    Prise en mains en mode texte : service gdm stop.

    Mise en place des paramètres kivontbien dans xorg.conf = le modeline est refusé.

    ->utilisation du driver proprio = tout marche impec sans rien paramétrer.

    Donc, l'écran n'est pas si mauvais, c'est juste le driver libre qui ne va pas.

    Conclusion : il y a encore du boulot dans le libre. :-(
    Autre conclusion : quand on utilise une distro qui se prétend user-friendly, on peut s'attendre à avoir des assistants de configuration pour mettre ses propres paramètres sans se farcir des heures de documentations pas toujours adaptées.

    Autre conclusion : je n'ai rien contre l'évolution des choses, mais il faut bien reconnaître que les périodes de transition sont toujours délicates : documentation obsolète, incohérences des différentes couches logicielles, inadaptation des outils qui fonctionnaient précédemment, temps d'aprentissage, etc., le tout à échelle de quelques mois.

    Merci à ceux qui ont aidé : toutes les manips qui ont réussi étaient dans le thread !
  • # la doc, la doc, la doc

    Posté par (page perso) . Évalué à 2.

    Ce que je reproche le plus, c'est que toute cette évolution ne s'accompagne pas de la doc kivabien. Si dans le man en question, il y a la piste, avec quelques exemples, ou le nom de la chose qui prend en charge avec une vraie doc, il n'y aurait pas tant de soucis.

    Je sais que la doc c'est pas l'activité préférée du hacker, mais cela devrait être l'activité principale d'une distribution. Il me semble bien loin le temps ou, sans internet, juste avec son install, on avait TOUT dans sa machine pour la faire fonctionner, documentation comprise (même en anglais), maintenant il faut de plus en plus chercher _obligatoirement_ sur internet et trouver quelqu'un qui donne un début de piste, en évitant les "ca marche bien sur ma slack/lfs/truc/chose.

    ps : un vraie doc, hein, pas juste le tartinage un peu obsolète que l'on garde depuis 2 ans
  • # Utilise Gentoo

    Posté par (page perso) . Évalué à 1.

    Rien ne marche, mais au moins, c'est facile à débugger.

    (À chaque fois que j'installe Gentoo sur un portable je regrette un peu… mais pas tant que ça)

    DLFP >> PCInpact > Numerama >> LinuxFr.org

Suivre le flux des commentaires

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