Journal Joli bug

Posté par . Licence CC by-sa
Tags :
31
16
juin
2011

Ho que voici un joli bug du logiciel Bumblebee. Ça mérite une nomination pour le bug de l'année !

Petit message ému à tous nos chers développeurs : un bug, ça arrive, c'est pas grave. Le pauvre utilisateur que je suis vous remercie en tout cas de les corriger !

  • # quand même

    Posté par . Évalué à 10.

    un bug, ça arrive, c'est pas grave

    parfois quand même un peu (/usr c'est quand même /usr)

    207829⁶+118453⁶=193896⁶+38790⁶+14308⁶+99043⁶+175539⁶

    • [^] # Re: quand même

      Posté par . Évalué à 8.

      Si c'est bien rattrapé, tu perds pas de données uniques (i.e. non retrouvables sur les interwebs avec de l'huile de coude).

      À part d'éventuels /usr/local/*

      Je préfère perdre /usr que /home ;)

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

      • [^] # Re: quand même

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

        Si c'est bien rattrapé, tu perds pas de données uniques

        /usr/home par défaut sous FreeBSD

        • [^] # Re: quand même

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

          Historiquement /lib et /bin contenaient les binaires indispensables au boot du système, et /usr/ était ensuite monté (contenant /usr/lib et /usr/bin) pour les logiciels. (disquettes ou autres).

          D'ailleurs, dans Hurd il a ensuite été proposé d'utiliser unionfs à la place du système obsolète de /usr/, et donc de supprimer /usr/ (pour des raisons de compatibilité, /usr/ serait un lien symbolique vers /).

          Donc la question c'est, pourquoi avoir /usr/home, puisqu'il suffit de monter dans /home à la place et on peut le faire assez tard (et on peut le faire avant que /usr/ soit monté).
          À moins que ça ne soit pas un point de montage, mais directement un dossier. Donc un / tout petit, un gros /usr avec les logiciels ET les données utilisateurs. (Bizarre quand même, quand tout le monde, y compris les utilisateurs les plus débutants, ont une partition pour leur OS et une autre partition pour leurs données).

          • [^] # Re: quand même

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

            J'ai jamais compris la hiérarchie sous les UNIX :)

            Par exemple, pourquoi le $HOME de root n'est pas dans /home ? Pourquoi /home quand il y a /usr (je trouve /usr/home logique) ? Pourquoi les scripts de démarrage vont dans /etc et pas dans (je vais dire une connerie, mais c'est juste un exemple) /boot ?

            Y a plein d'incohérences dans ce genre dans la hiérarchie.

            • [^] # Re: quand même

              Posté par . Évalué à 10.

              pourquoi le $HOME de root n'est pas dans /home

              parce que dans les entreprises, souvent (autrefois? Encore aujourd'hui?) le $HOME n'était qu'un point de montage NFS (NIS/"Yellow page") et que 'root' peut avoir besoin d’accéder à son $HOME sans le réseau? :)

              Pourquoi /home quand il y a /usr ?

              Parce que /usr et /home "peuvent" être des partitions séparées (et qu'un montage dans un montage peut poser problème)

              Pourquoi les scripts de démarrage vont dans /etc et pas dans /boot ?

              Parce que /boot n'existe pas dans une architecture "standard" SYSTEM V ?
              Ou bien parce que certains scripts de démarrage doivent être dans '/' (donc dans /etc) et que /boot n'est pas forcément monté sur un système (c'est déconseillé pour des raisons de sécurité :)

              Il n'y a pas de mauvais outils, il n'y a que de mauvais ouvriers

            • [^] # Re: quand même

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

              Par exemple, pourquoi le $HOME de root n'est pas dans /home ?

              et si le problème est que tu n'arrive pas à monter /home? Si /home est innaccessilbe (disque de données HS)?

              Pourquoi /home quand il y a /usr (je trouve /usr/home logique) ?

              de ce que je comprend, /usr sert à stocker des données "récupérables" non uniques à ta personne (programmes, libs...)
              Si j'ai un problème avec la machine, /usr part à la poubelle.

              Pourquoi les scripts de démarrage vont dans /etc et pas dans (je vais dire une connerie, mais c'est juste un exemple) /boot ?

              /boot, c'est pas pour booter? /etc c'est pas de la configuration après le boot?

              Ca me parait au contraire pas idiot... Le nommage n'est pas du tout sexy (surtout "etc"!), mais la logique se tient (à peu près)

              • [^] # Re: quand même

                Posté par . Évalué à 6.

                Le nommage n'est pas du tout sexy (surtout "etc"!),

                D'un autre coté, je préfère largement un nom court comme "etc" plutôt qu'un truc à rallonge avec des espaces dedans comme on voit souvent chez les voisins d'en face, qui auraient appelé ca "Editable Text Configuration"...

                • [^] # Re: quand même

                  Posté par . Évalué à 1.

                  "/conf" aurait tout de même été plus lisible.

                  • [^] # Re: quand même

                    Posté par . Évalué à 5.

                    Voui, mais il semble qu'a l'origine des temps, il n'y avait pas la dedans que des fichiers de configuration, mais aussi tout ce qu'on n'avait pas pu caser ailleurs, avec des scripts (rc), des donnees administratives (passwd), et cetera.

                    Pour rester lisible, logique et court, "/mess" aurait été pas mal, mais bon...

                    • [^] # Re: quand même

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

                      dans ce cas un /misc alors

                      • [^] # Re: quand même

                        Posté par . Évalué à 1.

                        il faut voir aussi qu'à l'origine, la mémoire et le disque étaient très limités et donc, un caractère économisé c'était mieux (d'où les trigrammes des répertoires: /bin /usr /tmp /var /etc et les digrammes des binaires: ls, cp, dd, rm, ...)
                        /mess, /misc <-- 4 caractères ( vilain gourmand en octets ! :D )

                        Il n'y a pas de mauvais outils, il n'y a que de mauvais ouvriers

                        • [^] # Re: quand même

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

                          /boot
                          /home
                          /proc
                          /root
                          (pour ne pas citer /media, /initrd, /lib64 arrivés plus tard, ni /lost+found)

                          • [^] # Re: quand même

                            Posté par . Évalué à 2.

                            Je parlais de l'origine :)
                            Dans les années '70, tous ces répertoires n'existaient pas, c'est Linux qui les a amené parce que dans les années '90, on avait déjà plus de mémoire et de disque dur, donc on pouvait "se permettre".
                            lost+found est effectivement une exception.

                            Il n'y a pas de mauvais outils, il n'y a que de mauvais ouvriers

                            • [^] # Re: quand même

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

                              Et pire que tout, on a maintenant /media !
                              Je me demande si je peux le supprimer vu que je n'utilise que /mnt et que ça me fait perdre du temps niveau autocomplétion.

                              DLFP >> PCInpact > Numerama >> LinuxFr.org

                        • [^] # Re: quand même

                          Posté par . Évalué à 3.

                          J'ai cru lire une fois que le nombre de caractères limités, sur les commandes et les dossiers standards sous Unix, c'était pour s'adapter à des terminaux qui n'affichaient pas en retour la commande tapé, afin d'éviter les erreurs de frappe.

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

                          • [^] # Re: quand même

                            Posté par . Évalué à 10.

                            le nombre de caractères limités [...] c'était pour s'adapter à des terminaux qui n'affichaient pas en retour la commande tapé[e]

                            Non, non. La vraie raison, c'est que les gros geeks barbus aux cheveux longs étaient des grosses faignasses. Moins y'avait de touches à taper, mieux ils se portaient...

                            Donc, tant que le mot restait reconnaissable (eg. usr -> user, etc -> editable text files, bin -> binaries, lib -> libraries...), pas de soucis, on raccourcissait.

                            Et pour tous ces répertoires/fichiers souvent modifiés (à l'époque, pas de DHCP, de DNS tel qu'on le connait, pas d'auto-completion...), c'était plus rapide à taper. Et les modifier était réservé à ces gros geeks bouffeurs de pizzas, et souvent ils en étaient les seuls utilisateurs. Alors, faire un truc compréhensible par le commun des mortels, pensez-vous...

                            Il y avait aussi la propension toute naturelle chez les mêmes geeks poilus d'utiliser un langage à eux, leur jargon. Et dans ce jargon, les voyelles étaient souvent éludées. Pas toujours, juste souvent. Il fallait quand même que le mot reste reconnaissable...

                            Et surtout, les terminaux était petits, donc plus les noms étaient courts, plus les listings étaient compacts, plus on pouvait en mettre à l'écran. D'où le nom de ls : list short.

                            Hop,
                            Moi, barbu aux cheveux longs, bouffeur de pizzas. Mais pas gros ni trop poilu ! ;-)

                            Oh, et en parlant de jargon.

                            • [^] # Re: quand même

                              Posté par . Évalué à 1.

                              k, 1 gt it. fukin l4m3rs frm the past.

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

            • [^] # Re: quand même

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

              Ce n'est pas des incohérence, c'est de l'histoire et de la logique.

              À une époque l'espace coûtait cher et les données étaient stockées sur différent type de supports. Sur un disque local et relativement rapide d'accès (pour l'époque) mais tout petit car cher, on stockait le minimum pour faire démarrer le système et faire un peu de maintenance.
              Donc sur cet espace il fallait les binaires et librairie de base et le home de root pour qu'il puisse ce loger pour la maintenance en cas de problèmes.

              Une fois que ce système minimum était chargé, on pouvait monter dans /usr le reste du système stocké en local aussi mais un support moins cher, plus lent mais avec plus d'espace comme un lecteur de bandes magnétiques.
              C'est dommage que ce soit plus lent mais c'était le prix à payer pour avoir l'espace pour stocker un système complet.

              Les utilisateurs on aussi leur données de stockées sur un support différents: sur un serveur de données qui est connecté à tous les autres et qui permet à chaque utilisateurs d'avoir ces données n'importe où. (les début du cloud en fait... mais sur bandes magnétiques...)
              Donc on monte ça sur /home et le root n'est pas dedans car lorsqu'on ce connecte en root ce serveur n'est pas forcément déjà accessible.

              Et dernière question : pourquoi ne pas monter /home dans /usr/home ? Tout simplement parce que sur un même serveur tu peux vouloir démonter le /usr pour en monter un autre. Les bandes magnétiques sont pas forcément suffisament grosses pour stocker tous les programmes nécessaire aux différents utilisateurs, et plus une bande est longue plus le temps d'accès moyen est long.
              Tu peux avoir un /usr pour les mathématiciens et un pour les physiciens et une fois de temps en temps tu changes. Si le /home est monté ailleurs c'est plus simple.

              Donc, d'un point de vue historique c'est parfaitement logique.

              • [^] # Re: quand même

                Posté par . Évalué à 5.

                L'historique est exact dans les grandes lignes, le premier Unix que j'ai utilisé en 1983 (HPUX) s'installait sur des disques de 5 ou 10 Mo (ce ne pas une faute de frappe). Il faut dire que le système complet tenait sur 20 Mo.

                Par contre, je suis surpris par ta description de systèmes de fichiers sur bandes magnétiques.

                Les seuls que j'ai connus étaient des «recovery tapes» (l'équivalent du «live CD» avant que les CD existent). On ne les utilisait qu'en dernière extrémité (disque non bootable) car les temps d'accès étaient extrêmement longs.

                Utiliser une bande magnétique pour une des partitions du système était inimaginable. Même si les temps d'accès avaient été supportables, les bandes ne fonctionnent correctement qu'en accès séquentiel. Les accès aléatoires résultant de l'organisation du système de fichiers provoquent des avances rapides et rembobinages incessants qui usent très vite les mécaniques et les bandes.

                • [^] # Re: quand même

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

                  J'avoue avoir simplifié un peu par flemme et pour rendre le contraste un peu plus fort pour bien faire comprendre l'idée.

                  Le système que j'avais en tête date à peu près de ton époque si je ne me trompe pas: fin 70 ou début 80. Je ne l'ai pas utilisé moi même car à cette époque mes doigts étais trop petits pour le clavier ;-) mais j'en ai beaucoup discuter avec un de ces grincheux qui regrettais la belle époque...

                  Les calculateurs n'était pas très riches en disque-durs et donc seul la base du système étais installée en permanence. Une fois que la base avait bootée elle chargeait depuis des bandes magnétique le reste du système sur un autre disque qui était ensuite monté sur /usr.
                  Quand une équipe avait finis ses calculs, on pouvait mettre les bandes de l'équipe suivante qui venais remplacer l'autre sur le disque.

                  J'ai pas garder le souvenir exact de tous les détails, ce qui m'a le plus amuser c'est toutes les anecdote sur comment s'arranger pour que les changement soient retarder le plus possible pour profiter du maximum de temps de calcul avant de ce faire virer par « ces emmerdeurs de physiciens qui font des trucs inutiles à côté des magnifiques calculs de mathématiques fondamentales... ».
                  Une autre époque où l'on s'amusait différemment... mais quand je vois comment ça ce passe dans mon labo, je me dit qu'au final le résultat est toujours le même, quelle que soit la puissance de calcul disponible, on se bat toujours pour l'utiliser...

            • [^] # Re: quand même

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

              Par exemple, pourquoi le $HOME de root n'est pas dans /home ?

              Pour être accessible même si /home ne l'est pas. /home est souvent un système de fichiers dédié, /root jamais.

              Pourquoi /home quand il y a /usr (je trouve /usr/home logique) ?

              Parce que ça n'a tout simplement rien à voir. Le nom /usr est historique, mais son contenu, c'est des logiciels et leurs données et bibliothèques, pas des fichiers des utilisateurs.

              Pourquoi les scripts de démarrage vont dans /etc et pas dans (je vais dire une connerie, mais c'est juste un exemple) /boot ?

              Parce qu'ils sont considérés comme des fichiers de configuration, et que de toute façon, il ne concernent pas le bootstrap qui ne se conçoit que comme de quoi charger le noyau. Typiquement par exemple, /boot contiendra un chargeur de démarrage fortement dépendant de la plate-forme.

            • [^] # Re: quand même

              Posté par . Évalué à 2.

              Pourquoi les scripts de démarrage vont dans /etc et pas dans (je vais dire une connerie, mais c'est juste un exemple) /boot ?

              Il y a au moins un intérêt, c'est que ça me permet d'avoir une partition /boot commune en multiboot Linux/Linux (je le fais avec Slackware/Arch).

          • [^] # Re: quand même

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

            Donc la question c'est, pourquoi avoir /usr/home, puisqu'il suffit de monter dans /home à la place et on peut le faire assez tard (et on peut le faire avant que /usr/ soit monté).

            Le coup du /usr/home (avec un lien /home), je pense que c'est un truc historique de l'installateur que personne n'a pris le temps de changer.

            Par défaut pw crée les $HOME dans /home


            static struct userconf config =
            {
            0, /* Default password for new users? (nologin) */
            0, /* Reuse uids? */
            0, /* Reuse gids? */
            NULL, /* NIS version of the passwd file */
            "/usr/share/skel", /* Where to obtain skeleton files */
            NULL, /* Mail to send to new accounts */
            "/var/log/userlog", /* Where to log changes */
            "/home", /* Where to create home directory */
            0777, /* Home directory perms, modified by umask *

            Ceci dit c'est un OS pour lequel tu n'as pas franchement besoin de monter /usr

            Tous les logiciels hors système de base étant dans /usr/local, c'est plutôt lui qu'il faut monter à part.

            Du coup :
            /
            /usr/local/
            /usr/home
            /tmp
            /var

            Ça fait un partitionnement cohérent.

      • [^] # Re: quand même

        Posté par . Évalué à 5.

        Je préfère perdre /usr que /home ;)

        Ça se discute, /home j'ai juste à détarer le backup de la veille, 10 minutes maxi, /usr faut tout réinstaller, plusieurs heures au minimum!

        • [^] # Re: quand même

          Posté par . Évalué à 4.

          /home j'ai juste à détarer le backup de la veille, 10 minutes maxi

          Pour les utilisateurs qui font des sauvegardes uniquement.

          /usr faut tout réinstaller, plusieurs heures au minimum!

          Pour l'utilisateur lambda qui ne fait pas de sauvegardes, la réinstallation de /usr se résume à mettre le CD de sa distribution, cliquer à répétition sur "suivant", car un utilisateur lambda se contente souvent de l'environnement complet GNOME ou KDE et les quelques logiciels non-intégrés viendront après.

          • [^] # Re: quand même

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

            L'utilisateur lambda n'utilise pas Bumblebee.

            « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

  • # dans le même style

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

  • # Licence

    Posté par . Évalué à 2.

    Et en plus, c'est sous licence Beer-ware !

    Si jamais vous aviez le /usr qui vous grattait, vous savez ce qu'il vous reste a faire..

  • # Et les tests ?

    Posté par . Évalué à 4.

    Qu'un bug arrive, ce n'est pas grave, que ce bug soit commité ce n'est pas grave, qu'il soit releasé sans que personne ne s'en soit aperçu, cela arrive régulièrement. Sauf dans ce cas précis, on ne peut pas ne pas s'apercevoir de ce bug et cela signifie pour moi que personne n'a exécuté la ligne qui bug, donc personne n'a testé le script d'installation.

    Du code qui est exécuté en root nécessite plus d'attention que le reste, surtout si il fait des rm. Le plus drôle n'est donc pas le bug en lui-même, mais qu'il soit arrivé dans une release sans problème et que des personnes ont réinstallé leur système à cause de cela.

    Alors, certes, ce n'est pas évident à tester, les scripts sont différents pour Ubuntu, Fedora et Opensuse... es-ce le prix de la diversifié de linux ou juste la fainéantise des développeurs ? Je penche pour la fainéantise et l'excès de confiance en leur code.

    • [^] # Re: Et les tests ?

      Posté par . Évalué à 2.

      Ces tests sur les paquets sont à faire sur un système/une machine (éventuellement machine virtuelle) dédiée. Il faut donc mettre en place cette infrastructure (et il faut des compétences particulières pour le faire !).
      Comme c'est un projet libre et qu'on veut en général que toute autre personne puisse lancer les mêmes tests que les développeurs principaux, simplement à partir du dépôt de code, il faut donc documenter cette infrastructure et la rendre reproductible chez tout autre potentiel futur développeur.
      Tout cela peut être particulièrement lourd et long à mettre en place.
      C'est aussi une question de moyens, je ne sais pas combien il y a de développeurs, mais en plus le projet semble être divisé, et les efforts sont encore plus fragmentés.

    • [^] # Re: Et les tests ?

      Posté par . Évalué à 4.

      Je penche pour la fainéantise et l'excès de confiance en leur code.

      Regarde le commit qui a mené au truc. C'est vraiment une typo à la con. Effectivement il aurait fallu tester mais faire les tests pour toutes les plateformes c'est un enfer qui demande une grosse infra et énormément de de temps. En pratique c'est irréalisable pour la plupart des projets.

      En général tu commit sur du code que tu vas exécuter donc tu as la plateforme sous la main pour vérifier mais dans ce type de commit y'a des grandes chances que tu corriges juste un truc rapporté par un utilisateur et que tu n'ai pas le moyen de tester les changements. La ça tombe vraiment au mauvais endroit mais celui qui n'a jamais commité une typo débile me jette la pierre. Fainéantises est donc un bien grand mot, je t'invite à valider un projet sur X versions de Y distribs pendant quelques mois et on en reparle.

      • [^] # Re: Et les tests ?

        Posté par . Évalué à 0.

        Tout cela peut être particulièrement lourd et long à mettre en place.

        _

        Effectivement il aurait fallu tester mais faire les tests pour toutes les plateformes c'est un enfer qui demande une grosse infra et énormément de de temps.

        A vrai dire, je ne faisais même pas référence à une infrastructure sophistiquée de tests. Seulement qu'il existe des testeurs qui possèdent la plateforme correspondante et qui teste le code avant la release (une release candidate quoi). De telle sorte qu'une personne qui télécharge la release ne se retrouve pas avec du code que personne n'a exécuté.

        Dans le cadre de ce projet, il faut déjà un nvidia avec la technologie Optimus, et ensuite à première vu, il faut tester les trois distributions supportées (Ubuntu, Fedora et Opensuse). Donc trois testeurs maxi pour le script d'installation, mais là n'est pas le problème. Le problème c'est juste que c'est chiant car ce n'est pas le travail d'un développeur de s'occuper de tout cela.

        dans ce type de commit y'a des grandes chances que tu corriges juste un truc rapporté par un utilisateur et que tu n'ai pas le moyen de tester les changements.

        A vrai dire, dans ce type de commit, dans un vrai projet, quand moi je rapporte un bug, le gars me demande de tester à partir du repository (master, voire dans une branche spéciale), et une fois que j'ai confirmé que ça marche cela passe en release (ou dans la branche master). Cela ne demande pas plus de ressource et ajoute une sécurité.

        Fainéantises est donc un bien grand mot, je t'invite à valider un projet sur X versions de Y distribs pendant quelques mois et on en reparle.

        N'oublie pas que dans mon message j'ai également indiqué: es-ce le prix de la diversifié de linux , tu penches donc de ce coté là. Pour ma part, je suis un vrai fainéant et j'assume: je ne gère en général qu'une seule distribution.

    • [^] # Re: Et les tests ?

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

      personne n'a testé le script d'installation

      Ici c'est plutôt le script de sinstallation.

      « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

  • # Sécurité supplémentaire dans les gestionnaires de paquets?

    Posté par . Évalué à 7.

    Si je ne m'abuse (au moins pour les deb), un empaquetage sans vérification ne permettrait pas d'exécuter la commande, parce que /usr n'appartient pas au paquet bumblebee.

    Me trompe-je?

    Jamais regardé comment c'était fait en pratique d'ailleurs.

    • [^] # Re: Sécurité supplémentaire dans les gestionnaires de paquets?

      Posté par . Évalué à 0.

      Non, j'en doute, il n'y a pas un utilisateur créé pour chaque paquet installé.
      Si tu fais de la merde dans ton script qui sera exécuté en root, tu fais de la merde dangereuse.

      Je ne crois pas qu'il y'ai une politique debian spécifique a ce sujet. (créer obligatoirement un utilisateur pour un paquet spécifique, excepté les daemons peut être ?)

      • [^] # Re: Sécurité supplémentaire dans les gestionnaires de paquets?

        Posté par . Évalué à 2.

        Je crois que tu as manqué d'imagination!

        Après vérification, Debian vérifie bien quel fichier appartient à quel paquet, grâce à une base de données des paquets et pas en créant un nouvel utilisateur à chaque fois (heureusement d'ailleurs, j'imagine pas le bordel dans /etc/passwd!!).

        On trouve d'ailleurs de temps en temps un bug tel que "paquet refuse de s'installer parce que fichier machin appartient à autre paquet" ou dans le genre.

        Je n'ai pas vérifié, mais je ne vois pas d'obstacle à l'implémentation de la même fonctionalité pour RPM. Donc elle y est peut-être déjà!

Suivre le flux des commentaires

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