/usr friendly

Posté par  (site web personnel) . Modéré par Lucas Bonnet. Licence CC By‑SA.
35
4
nov.
2011
Fedora

« Le FHS du LSB est bien, mais “ / ” est un sacré bordel, il faut tout de même l’avouer. » Ceux qui auront compris cette phrase seront certainement d’accord. Pour les autres, LSB signifie Linux Standard Base, cela définit tout un ensemble de standards autour de GNU/Linux, dont… le FHS, qui est le Filesystem Hierarchy Standard, qui définit l’emplacement des fichiers.

À la racine, c’est‐à‐dire la base du système de fichiers, notée « / », on range notamment les données et les programmes statiques dans « /usr », bien. Ensuite, on range les binaires dans « /bin » et « /sbin », et les bibliothèques dans « /lib » et « /lib64 ». Oui, mais voilà, on range aussi des binaires dans « /usr/bin » et « /usr/sbin », et des bibliothèques dans « /usr/lib » et « /usr/lib64 ».

La proposition vient de Harald Hoyer et Kay Sievers, deux développeurs Red Hat, et est soutenue par Lennart Poettering. L’héritage de 30 ans d’UNIX est clairement à simplifier. Le but est de :

  • fusionner « /bin », « /sbin » et « /usr/sbin » dans « /usr/bin » ;
  • déplacer le contenu de « /lib » dans « /usr/lib » ;
  • déplacer le contenu de « /lib64 » dans « /usr/lib64 » ;
  • créer des liens symboliques pour rester compatible :
    • « /bin » vers « /usr/bin »,
    • « /sbin » vers « /usr/bin »,
    • « /lib » vers « /usr/lib »,
    • « /lib64 » vers « /usr/lib64 ».

Facile à retenir : « sbin », c’est has been ! Hum.

Ceci faciliterait grandement le montage et démontage des systèmes de fichiers, le démarrage du système, les instantanés (snapshots), la virtualisation, etc..

Aller plus loin

  • # Commentaire supprimé

    Posté par  . Évalué à 8.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: la messe est dite

      Posté par  (site web personnel) . Évalué à 10.

      Pareil. Il suffit d'avoir le support de ce personnage critiqué et critiquable pour que le projet soit lui-même critiqué.
      Si il faut faire des modifications, elles doivent être plus importantes que simplement fusionner ces répertoires. Il faut supprimer le /tmp global (et tous les endroits world-writable), simplifier les 3 ou 4 endroits où l'on trouve de la doc (/var, /usr/doc, /usr/share/doc,...), virer tout ce qui est configuration et données statiques de /var, réordonner le bordel de /etc, etc.

      Et surtout ne pas annoncer qu'on a le support de gens notoirement détestés dans la communauté.

      • [^] # Re: la messe est dite

        Posté par  . Évalué à 2.

        Le /tmp global c'est bien, mais il aurait plutôt sa place dans /var, non? Le /home aussi d'ailleurs.

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

        • [^] # Re: la messe est dite

          Posté par  . Évalué à 5.

          /tmp et /var/tmp ne garantissent pas la même durée de vie aux données.

          /var/tmp est persistant au reboot (fichiers de cache divers que tu ne veux pas réindexer à chaque redémarrage ou les fichiers d'historique par exemple) tandis que /tmp sera vidé automatiquement à chaque redémarrage.

          Dans le cas de /tmp, il est alors possible d'utiliser le système de fichier tmpfs qui te permet d'accélerer les temps d'accès en moyenne.

          (voir certains commentaires plus bas pour d'autres détails)

          • [^] # Re: la messe est dite

            Posté par  . Évalué à 3.

            /var/tmp est persistant au reboot (fichiers de cache divers que tu ne veux pas réindexer à chaque redémarrage ou les fichiers d'historique par exemple) tandis que /tmp sera vidé automatiquement à chaque redémarrage.

            Beuh? Tu peux très bien vider /var/tmp tout comme /tmp est actuellement vidé.

            Par contre, argument reçu pour le tmpfs.

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

          • [^] # Re: la messe est dite

            Posté par  (site web personnel) . Évalué à 1.

            Là où l'on voit que les devs de fedora aiment bien donner des coups de pied dans ce genre de fourmilière, c'est que justement dans fedora, le /tmp n'est pas vidé à chaque redémarrage. D'ailleurs ça m'embête bien sur le PC de ma compagne (équipé de fedora), car /tmp s'encrasse.
            Je crois qu'il supprime les fichiers quand ils ont dépassé une certaine limite d'âge.

            La lumière pense voyager plus vite que quoi que ce soit d'autre, mais c'est faux. Peu importe à quelle vitesse voyage la lumière, l'obscurité arrive toujours la première, et elle l'attend.

            • [^] # Re: la messe est dite

              Posté par  . Évalué à 4.

              D'ailleurs ça m'embête bien sur le PC de ma compagne (équipé de fedora), car /tmp s'encrasse.
              Je crois qu'il supprime les fichiers quand ils ont dépassé une certaine limite d'âge.

              Je te parie une bière que tu peux le paramétrer (durée de conservation des fichiers, nettoyage à chaque démarrage, nettoyage à partir d'une certaine taille), en cherchant 5 minutes.

              NB: je n'ai jamais utilisé Fedora.

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

    • [^] # Re: la messe est dite

      Posté par  (site web personnel) . Évalué à 10.

      Oui mais ce que j'aime bien chez Lennart Poettering, c'est qu'il se bouge le cul pour faire des propositions (et même les réaliser), il n'hésite pas à mettre des coups de pied dans la fourmilière… Après il n'est pas parfait mais il a de l'énergie… veut faire avancer les choses.

      Je ne suis pas un spécialiste du domaine, je ne porterai pas de jugement sur le bien fondé de l'idée ou non.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 8.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: la messe est dite

          Posté par  . Évalué à -1.

          L'histoire m'a appris qu'il ne faut pas juger les gens sur la quantité des propositions et leur réalisation mais plutôt sur la qualité des réalisations

          avahi, pulseaudio, systemd pour ses principales oeuvres, qui sont soit des briques de bases d'une distro GNU/Linux soit en passe de le devenir.
          Si il faisait que de la merde, je pense qu'on l'aurait oublié depuis longtemps.

          • [^] # Re: la messe est dite

            Posté par  . Évalué à 10.

            qui sont soit des briques de bases d'une distro GNU/Linux soit en passe de le devenir

            Aucune trace de ces «briques de base» dans ma Slackware 13.37. Linux != Fedora.

            • [^] # Re: la messe est dite

              Posté par  . Évalué à 4.

              Tu oublies Debian, OpenSuSE, Mageia, Frugalware, ArchLinux etc ... Sans oublier les gadgets à base de linux (WebOS, MeeGo, OpenWRT, etc ...). Malhonneteté cd key.

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 8.

            Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: la messe est dite

            Posté par  (site web personnel) . Évalué à 5.

            avahi est une daube en entreprise... C'est encore un protocole à la Apple conçu pour le familial ou la PME.

            Avahi ne me dérange pas en soi tant qu'il ne devient pas une dépendance nécessaire à l'environnement de bureau...

            • [^] # Re: la messe est dite

              Posté par  . Évalué à 5.

              Avahi n'est pas un protocole, c'est une implémentation de découverte de service pour le bureau. Après le fait que ça soit de la merde en barre "architecturée" par Lennart et le fait qu'il ne supporte rien d'autre que zeroconf, qu'il ne pourra jamais rien supporter d'autre que zeroconf et que tu puisse crever si tu veux remplacer Avahi par autre chose, c'est la faute d'Avahi et de Lennart, ce n'est pas la faute de zeroconf.

              zeroconf fait ce pour quoi il à été prévu (remplacer AppleTalk). C'est parfaitement normal qu'il réponde pas à tout les besoins. Ce qui n'est pas normal, c'est qu'Avahi ne propose pas d'utiliser un autre protocole fait avec ses petites mains et que Lennart soit aussi condescendant envers ceux qui cherchent à résoudre ce problème avec des patches.

              • [^] # Re: la messe est dite

                Posté par  . Évalué à 2.

                c'est surtout que cela ne sert a rien. Demarre avahi et essaye donc de t'en servir pour partager un fichier avec quelqu'un utilisant un ipad. Cela ne marche pas.

                • [^] # Re: la messe est dite

                  Posté par  . Évalué à 3.

                  quel est le putain de rapport avec Avahi ? zeroconf c'est de la publication/découverte de service, après c'est un autre service qui prends le relais. T'as vu où dans la norme msDNS que ça gérait le partage de fichiers ? Il n'y a aucune honte à consulter pour ses problèmes de malcomprenance !

                  • [^] # Re: la messe est dite

                    Posté par  . Évalué à 1.

                    Ouhais je suis pas rentre dans les details. En gros, avahi avec ssh service qui est non vu et donc non accessible par un ipad a la con. Maintenant ca marche (peut etre) super bien sur ... Fedora/RH encore une fois mais bon sur Opensuse et ubuntu cela ne sert a rien.

                    Putain on critique Microsoft de faire des trucs qui tourne uniquement sous leurs OS pourris mais Fedora/RH c'est un chouilla dans la meme categorie a force.

                    • [^] # Re: la messe est dite

                      Posté par  . Évalué à 3.

                      Ouhais je suis pas rentre dans les details. En gros, avahi avec ssh service qui est non vu et donc non accessible par un ipad a la con. Maintenant ca marche (peut etre) super bien sur ... Fedora/RH encore une fois mais bon sur Opensuse et ubuntu cela ne sert a rien.

                      Suis les conseils de GeneralZod: Consulte.

                      Avahi ne publie que les services qui s'enregistrent auprès de lui ou qui sont définis par l'administrateur. Si on peut criser sur le fait que l'admin n'a aucun contrôle fin sur les services que des simples utilisateurs peuvent publier, pour une fois Lennart laisse l'administrateur configurer les services qu'il veut publier.

                      OpenSSH ne supporte pas Avahi (il a raison !), donc il faut soit que l'administrateur se bouge son PWD dans /etc/avahi/services, soit que sa distribution le fasse pour lui.

                      Personnellement, moi j'aime pas quand une distrib à comme valeur par défault de lancer un serveur SSH avec login par mot de passe activé, et crie à tout le monde qu'on à un service SSH d'ouvert. Et faut croire que je suis pas le seul, si j'en crois les distribs que tu cite ;)

                      • [^] # Re: la messe est dite

                        Posté par  . Évalué à 2.

                        Merci de me prendre pour un con mais je suis au courrant de cela et les fichiers sont bien la ou ils doivent etre puisque c'est moi qui les ais mis. Mais ceci est un tres tres bon exemple de ce qu'est Avahi: un truc absolument pas fait pour le commun des mortels. Cela lui aurait troue le cul de mettre les fichiers la ou il fallait et de mettre des options de configuration/demarrage dans une GUI? Ah merde c'est vrai il bosse chez RH et donc utiliser Gnome...

                        Et rate pour les distribs en question, elles font cela comme il se doit mais du coup ce truc lance au demarrage n'est qu'un gros truc inutile.

                        • [^] # Re: la messe est dite

                          Posté par  . Évalué à 1.

                          Mais ceci est un tres tres bon exemple de ce qu'est Avahi: un truc absolument pas fait pour le commun des mortels.

                          Pour Lennart, ça serait plutôt openssh qui n'est pas fait pour le commun des mortels, puisqu'il ne supporte pas Avahi. Et non, Avahi ne peut pas automagiquement détecter des services qui ne dépendent pas de lui. Si il le faisait, alors ça deviendrai vraiment un logiciel effrayant et un trou de sécurité béant, donc non, il va pas rajouter des fichiers tout seul pour des services qu'il connaît pas. Quand à l'interface de configuration, c'est à la distrib de la faire. Comme pour tout les démons.

                          Avahi est déjà assez pourri comme ça, arrête de vouloir le rendre encore plus merdique.

          • [^] # Re: la messe est dite

            Posté par  . Évalué à 5.

            avahi, pulseaudio, systemd pour ses principales oeuvres

            Tu es en train de tirer une balle dans le pied...

            • avahi ca marche pas ou c'est pas user friendly. En tout ca c'est inutile dans la vraie vie et cela n'evolue plus du tout.
            • pulseaudio: Il a fallu de nombreuse annee pour que cela fonctionne en dehors de RH/Fedora ce qui est un comble tout de meme.
            • systemd : on verra mais vu les deux exemple au dessus je suis pas convaincu
            • [^] # Re: la messe est dite

              Posté par  . Évalué à 1.

              avahi ca marche pas ou c'est pas user friendly. En tout ca c'est inutile dans la vraie vie et cela n'evolue plus du tout.

              Je m'en sers pour le partage de médias (audio, vidéo), d'écran (vinagre \o/), éditeur collaboratif (Gobby), dépôt mercurial (extension zeroconf) etc ... ça n'évolue pas, le protocole zeroconf n'a pas évolué, mais en même temps pour de la découverte de services, ça fait déjà très bien son taff, faut pas pousser mémé dans les orties.

              pulseaudio: Il a fallu de nombreuse annee pour que cela fonctionne en dehors de RH/Fedora ce qui est un comble tout de meme.

              Il a fallu plusieurs années pour que ça marche correctement sur Ubuntu parce que les mainteneurs de pulseaudio dans Ubuntu sont des gros mongols qui sont pas foutus d'envoyer un mail au mainteneur upstream. En 4 ans, j'ai jamais eu de soucis avec PA que ce soit sur Fedora, openSUSE, Debian, ArchLinux, Mandriva, Frugalware, etc ...

              systemd : on verra mais vu les deux exemple au dessus je suis pas convaincu

              ça fait un an que j'utilise au quotidien et mis à part peut-être launchd, y a pas mieux.

            • [^] # Re: la messe est dite

              Posté par  . Évalué à -9.

              En tout ca c'est inutile dans la vraie vie et cela n'evolue plus du tout.

              C'est quelle partie exactement de découverte automagique de service que tu considères inutile dans la vraie vie?

              If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

        • [^] # Re: la messe est dite

          Posté par  . Évalué à 2.

          « Secouer son cul » n'est pas un métrique intéressante.

          Tu trouve ?

          se secouer le cul

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

          • [^] # Re: la messe est dite

            Posté par  . Évalué à 7.

            À titre personnel, il m'est extrêmement désagréable de voir des images dans les commentaires de linuxfr. Je trouve que cela gâche la qualité des débats, trolls et poilades de ce site.
            Quand il s'agit en plus d'un gif animé, je ressens alors la forte pulsion de fabriquer une poupée vaudou pour que l'auteur du post rêve de lolcats des nuits entières jsuqu'à qu'il se repente.
            Bref, je ne comprends vraiment pas pourquoi il est possible de poster des images. Mais, comme je ne suis pas dictateur sur ce site, je me contente de mettre un petit -1.

            Par contre, serait-il possible de convenir de ne poster que des images "SFW" (Safe For Work), c'est à dire qui ne vont pas décrédibiliser complètement celle ou celui qui expliquera à son ou sa boss que lire linuxfr est de la "veille technologique" et peut donc se faire pendant les heures de travail ? Surtout quand il s'agit d'une dépêche portant sur un sujet sérieux ! Évidemment je ne m'en prendrais qu'à moi même si tombais sur ce genre de gif en ouvrant un journal qui s'appellerait "Jolies Nimages".

            • [^] # Re: la messe est dite

              Posté par  . Évalué à 1.

              À titre personnel, il m'est extrêmement désagréable de voir des images dans les commentaires de linuxfr. Je trouve que cela gâche la qualité des débats, trolls et poilades de ce site.
              Quand il s'agit en plus d'un gif animé, je ressens alors la forte pulsion de fabriquer une poupée vaudou pour que l'auteur du post rêve de lolcats des nuits entières jsuqu'à qu'il se repente.

              La force du web (et plus précisément du HTML, c'est de pouvoir modifier au niveau client la gueule de ce qu'on télécharge. Tu peut très bien bloquer les images.

              Bref, je ne comprends vraiment pas pourquoi il est possible de poster des images. Mais, comme je ne suis pas dictateur sur ce site, je me contente de mettre un petit -1.

              Ça peut être utile à de vrai choses comme montrer des graphiques. Si ça ne plaît vraiment pas le suivi est là pour ça.

              Par contre, serait-il possible de convenir de ne poster que des images "SFW" (Safe For Work), c'est à dire qui ne vont pas décrédibiliser complètement celle ou celui qui expliquera à son ou sa boss que lire linuxfr est de la "veille technologique" et peut donc se faire pendant les heures de travail ? Surtout quand il s'agit d'une dépêche portant sur un sujet sérieux ! Évidemment je ne m'en prendrais qu'à moi même si tombais sur ce genre de gif en ouvrant un journal qui s'appellerait "Jolies Nimages".

              Tu as tout a fait raison. C'est une erreur de ma part.

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

              • [^] # Re: la messe est dite

                Posté par  . Évalué à 2.

                La force du web (et plus précisément du HTML, c'est de pouvoir modifier au niveau client la gueule de ce qu'on télécharge. Tu peut très bien bloquer les images.
                [...]
                Ça peut être utile à de vrai choses comme montrer des graphiques. Si ça ne plaît vraiment pas le suivi est là pour ça.

                Un lien vers un tel graphique me paraît suffisant.
                Pourquoi je n'aime à ce point là pas les images dans les commentaires ? Parce que je crois que sur le long terme, la forme a une influence sur le fond. Assez empiriquement, j'ai l'impression qu'une forme dépouillée encourage des discussions de qualité (encore une fois, qu'il s'agisse de sujet sérieux, de poilade ou de troll), tandis qu'une forme où tout est permis, poussée à l'extrême, bah ça fait un forum où il n'y a plus que des smileys, des avatars, des signatures de dix lignes et des gifs animés. Bon je n'ai vraiment pas peur que linuxfr devienne un jour comme ça ; même avec une forme permissive, cela dépend quand même essentiellement des participants. Mais, à mon avis, dans une certaine mesure, et à participants égaux, une forme un peu austère favorise une discussion de meilleure qualité. Bloquer les images individuellement ne résoudrait rien à mes yeux.

                Tu as tout a fait raison. C'est une erreur de ma part.

                Merci, je range tout de suite ma poupée vaudou. ;-)

                • [^] # Re: la messe est dite

                  Posté par  . Évalué à 2.

                  Au passage l'astuce que j'utilise quand je surf sur linuxfr au boulot c'est d'utiliser l'extension policy request et de débloquer les images qui m'intéressent uniquement.

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

  • # les binaires, bof

    Posté par  . Évalué à 8.

    Bof, c'est une proposition peu intéressante.

    L'emplacement des binaires n'est pas trop un problème en soit. un coup de $PATH ou de which et ça roule.

    Non, le vrai problème est /etc

    • [^] # Re: les binaires, bof

      Posté par  (site web personnel) . Évalué à 8.

      Et quel est le problème avec /etc au juste ?

      • [^] # Re: les binaires, bof

        Posté par  . Évalué à 10.

        On y trouve des fichiers où il faut écrire au boot ou pendant le fonctionnement de la machine (mtab, resolv.conf...) ce qui oblige à des contorsions s'il faut que / soit read-only (voir p.ex. http://wiki.debian.org/ReadonlyRoot ).

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 3.

          Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: les binaires, bof

            Posté par  (site web personnel) . Évalué à 9.

            Non, /run. /var, c'est plutôt pensé pour les données variables de services, comme le courrier électronique. Il était utilisé pour les fichiers liés au fonctionnement des serveurs eux-mêmes, mais /run a été créé pour cet usage.

            • [^] # Commentaire supprimé

              Posté par  . Évalué à 10.

              Ce commentaire a été supprimé par l’équipe de modération.

              • [^] # Re: les binaires, bof

                Posté par  (site web personnel) . Évalué à 5.

                Non en effet, il n'est pas dans la FHS pour le moment, mais il a été adopté par plusieurs distributions afin de simplifier le démarrage, justement. Parce qu'au démarrage, on a besoin d'un tel répertoire, et que /var/{run|lock} ne sont pas forcément disponibles à ce moment-là.

                • [^] # Commentaire supprimé

                  Posté par  . Évalué à 4.

                  Ce commentaire a été supprimé par l’équipe de modération.

                  • [^] # Re: les binaires, bof

                    Posté par  . Évalué à 7.

                    Le plus parlant est udev, qui est démarré très tôt (typiquement tu n'as que la partition root qui est montée), et qui, avant l'invention de /run, mettait ses données "runtime" dans /etc/.udev, ce qui n'était pas très propre.

                    Il y a d'autres services qui faisaient de même à divers endroits, et, bien évidemment, rien de standardisé ou prédictible.

                    Donc je trouve que /run est plutôt bien venu, même s'il n'était pas utile du temps où le FHS a été créé, le temps béni du mknod.

                • [^] # Re: les binaires, bof

                  Posté par  . Évalué à 7.

                  http://xkcd.com/927/

                  Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

            • [^] # Re: les binaires, bof

              Posté par  . Évalué à 7.

              Chuuut, /run est je crois aussi soutenu par Lennart Poettering.

            • [^] # Re: les binaires, bof

              Posté par  . Évalué à 4.

              Moi j'aimerais bien savoir pourquoi debian (et peut être d'autres) s'obstinent à coller les fichiers de zone de bind et les document root apache dans des sous répertoires de /var.

              • [^] # Re: les binaires, bof

                Posté par  (site web personnel) . Évalué à 4.

                Ça aurait plutôt sa place dans /srv en effet, mais l'organisation de /srv est laissée à discrétion de l'administrateur, par conséquent une distribution ne peut pas y imposer d'organisation a priori.

                • [^] # Re: les binaires, bof

                  Posté par  (site web personnel) . Évalué à 5.

                  Un gestionnaire de paquet ne devrait pas avoir le droit d'écrire dans /srv /opt et /usr/local

                  Il y a un espace pour a distrib et un espace pour l'administrateur système. J'ai une SUSE avec des paquets propriétaires qui mettent des merdes partout, c'est absolument ingérable...

              • [^] # Re: les binaires, bof

                Posté par  (site web personnel) . Évalué à 2.

                Moi j'aimerais bien savoir pourquoi debian (et peut être d'autres) s'obstinent à coller les fichiers de zone de bind

                Ben typiquement ça varie (transfert de zone par exemple).

                Pour www ça se discute, sous FreeBSD c'est dans /usr/local/www et ça me plait pas trop non plus.

                les pixels au peuple !

                • [^] # Re: les binaires, bof

                  Posté par  . Évalué à 3.

                  Je croyais que /usr/local était réservé à l'admin système.

                  « 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

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 3.

          Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 5.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: les binaires, bof

          Posté par  . Évalué à 5.

          Chez Apple c'est ce qu'ils ont fait, à peu de chose près. Ils ont bien compris que demander son avis à la communauté était tout sauf productif.

          • [^] # Re: les binaires, bof

            Posté par  . Évalué à 3.

            Même pas la peine de changer de kernel: il y a GoboLinux.

            Personnellement je trouve que tout ce bazar est causé par les hiérarchie des systèmes de fichier classique (qui sont d'ailleurs insuffisante car on y ajoute des liens) et j'espère qu'un jour on passera à un système par label, plus besoin de se casser la tête avec "LA HIERARCHIE UNIQUE PARFAITE", chacun voit son système de fichier en regardant les labels qui l’intéresse..

            • [^] # Re: les binaires, bof

              Posté par  . Évalué à 4.

              C'est quoi un système par label?

              • [^] # Re: les binaires, bof

                Posté par  (site web personnel) . Évalué à 9.

                J'imagine que c'est un gros sac où tous les fichiers sont mis en vrac, sans noms ni hiérarchie, mais avec des étiquettes clef=valeur. Au lieu de ranger, on étiquette, et au lieu d'aller consulter par un nom précis, on cherche.

              • [^] # Re: les binaires, bof

                Posté par  . Évalué à 3.

                Un système ou un fichier est identifié par une série de nom sans que ce soit nécessairement hiéarchique, un peu comme on trie son courrier avec gmail.

                L'avantage tu peux avoir des tags utiles pour les admin sys (présence dans l'early boot ou pas, sur quel disque) sans que ça interfère avec les utilisateurs 'normaux'.

                • [^] # Re: les binaires, bof

                  Posté par  . Évalué à 2.

                  L'idée est intéressante, mais est-ce que la gestion des droits ou l'analyse d'un système de fichier ne va pas devenir un cauchemar?

                  • [^] # Re: les binaires, bof

                    Posté par  . Évalué à 1.

                    Pas beaucoup plus que l'existant: les labels existent déjà on appelle ça un "chemin".

                    C'est juste qu'il sont contraint à être hiérarchique ce qui est souvent trop contraignant..
                    D'ailleurs, on a inventé les liens pour contourner cette contrainte, les labels généralisent juste ça.

                    • [^] # Re: les binaires, bof

                      Posté par  (site web personnel) . Évalué à 8.

                      D'ailleurs, on a inventé les liens pour contourner cette contrainte

                      Référence nécessaire. Les liens physiques sont une fonctionnalité normale d'un système de fichiers qui découple le nom du contenu, et les liens symboliques une fonctionnalité permettant une indirection, mais de là à dire qu'ils ont été introduit pour ça…

                • [^] # Re: les binaires, bof

                  Posté par  . Évalué à 4.

                  Ah, comme les adresses IPV6, les identifiants de partition ou de disque par exemple ? Pourquoi ne pas utiliser les inodes tant qu'on y est ? C'esst vrai, c'est débile retenir un nom de fichier.

                • [^] # Re: les binaires, bof

                  Posté par  (site web personnel) . Évalué à 3.

                  mkdir /vrac     # répertoire de stockage de tous les fichier
                  mkdir /pouet    # étiquette « pouet »
                  mkdir /pouic    # étiquette « pouic »
                  echo "Toto" > /vrac/toto
                  ln /vrac/toto /pouet/toto  # on étiquette le fichier toto par « pouet »
                  ls /pouet       # quels sont les fichiers étiquetés « pouet » ?
                  
                  
                  • [^] # Re: les binaires, bof

                    Posté par  (site web personnel) . Évalué à 1.

                    Notez que, vu ce que j'en pense, j'aurais probablement mieux fait de s/vrac/bordel/…

                  • [^] # Re: les binaires, bof

                    Posté par  . Évalué à 5.

                    Bien que j'ai le même avis que toi sur ce système, ton exemple est biaisé parce que la seule opération ensembliste possible est l'union, alors que l'intersection serait utile et la différence aussi.

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

                    • [^] # Re: les binaires, bof

                      Posté par  (site web personnel) . Évalué à 1.

                      Bah, avec tous les outils Unix qu'on a on devrait bien y arriver. Avec des fichiers temporaires, hélas, certes. Mais bon, les outils pour lister en faisant des opérations ensemblistes sur des répertoires, ça se code…

                      • [^] # Re: les binaires, bof

                        Posté par  . Évalué à 8.

                        Autant faire du relationnel avec les outils qui vont bien : un base relationnelle et le langage de requête adéquat.

                        Et on appellerait ça Nepomuk.

                        • [^] # Re: les binaires, bof

                          Posté par  . Évalué à 2.

                          Certes, mais le problème après est qu'il faut que ça marche et que ce soit performant.
                          J'attends de voir les retours sur 4.7.3, ça a l'air intéressant.

                          Note bien qu'un système de fichier normal a déjà un coût important puisque qu'il masque l'organisation du disque et si tu accèdes a plusieurs fichiers c'est dans un ordre assez aléatoire plutôt que d'utiliser l'ordre des blocks sur les disque (*).

                          Sauf ce coût là, on y est tellement habitué que personne n'y pense (et puis proposer d'utiliser les numéros de blocks plutôt que des noms de fichier, ça va pas aller bien loin ;-) ), mais si Nepomuk a un cout en perf raisonnable, je serai vraiment curieux de voir ce que les devs de GoboLinux peuvent faire avec Népomuk..

                          *: dans le papier: As an example, a tar of the Linux kernel tree was 82.5 seconds using GNU tar, while our modified tar completed in 17.9 seconds.

                          • [^] # Re: les binaires, bof

                            Posté par  . Évalué à 4.

                            Oh ! Nepomuk fonctionne pas trop mal. C’est plutôt le bouzin complet et intégré qui a la hoquet quand ça lui chante… Perso. les bugs qui me sautent ou m’ont sauté à la figure sont surtout du côté de l’indéxeur (il faut bien réaliser que ce truc doit avaler n’importe quelle série de données binaires et arriver à trouver à quoi ça peut bien correspondre… c’est un boulot horrible à mettre en place). Et que je sache c’est surtout à l’indexeur qu’on en veut (ralentissements dûs à la première indexation, base gigantesque, …).

                          • [^] # Re: les binaires, bof

                            Posté par  . Évalué à 4.

                            C'est un peu comparer des pommes et des carottes que de dire que "un FS à un coût car il est vient par dessus d'un bloc layer et que ce dernier est plus rapide si l'on se contente de lire des blocs dans un ordre intelligent". D'ailleurs le papier cité montre simplement sur ce point qu'on peut optimiser en faisant des choses intelligente dans l'userspace, ce qui est normal, le noyau n'ayant pas d'oracle à sa disposition capable de lui dire ce que l'userspace est en train de vouloir faire d'un point de vue de très haut niveau. Le noyau étant encore moins capable de patcher automatique à la volée l'userspace en question pour lui faire faire des choses plus intelligentes, il faut bien qu'un humain s'en occupe.

                            J'accorde néanmoins qu'il est bon de rappeler que les FS ne sont pas magiques aux personnes à qui ça aurait pu échapper.

                    • [^] # Re: les binaires, bof

                      Posté par  . Évalué à 2.

                      Tu t'es pris pour MS (et sur un projet ayant échoué, si je ne m'abuse...) ?

                • [^] # Re: les binaires, bof

                  Posté par  (site web personnel) . Évalué à 3.

                  Sous *nix, un fichier est identifié par le numéro majeur et le numéro mineur du périphérique sur lequel il est stocké, et par son numéro d'i-nœud. Il a par ailleurs un certain nombre de noms, ce nombre pouvant être positif ou nul — ce dernier cas se produisant lorsqu'on supprime le dernier nom d'un fichier qui est toujours ouvert par un processus.

                  En particulier, un fichier n'est pas identifié par son nom, et peut avoir plusieurs noms. Que te faut-il de plus ?

                  • [^] # Re: les binaires, bof

                    Posté par  . Évalué à 2.

                    Que te faut-il de plus ?

                    Un système de hard link pour les répertoire et je pense qu'on doit avoir un système assez souple.

                    • [^] # Re: les binaires, bof

                      Posté par  (site web personnel) . Évalué à 2.

                      Ah, exact. Pas de chance, c'est impossible, entre autre pour une raison imparable : dans un répertoire qui a plusieurs noms, c'est qui .. ?

                      • [^] # Re: les binaires, bof

                        Posté par  (site web personnel) . Évalué à 0.

                        Celui du contexte :-)

                        Seul problème effectivement, le comportement ne serait plus le même qu'avec les liens symboliques (truc qui pose d'ailleurs tout un tas de problèmes n'étant pas toujours très intuitif, par ex, créer
                        ln -s /usr/bin ~/monbin
                        puis regarder le résultat de
                        ls -l ~/monbin/..

                        Ce n'est pas impossible, preuve en est, c'est ce qui est utilisé par Mac OS X pour réaliser timemachine (le système d'archivage d'Apple).

                    • [^] # Re: les binaires, bof

                      Posté par  . Évalué à 2.

                      En même temps, demander un système de fichier non hiérarchique … puis se plaindre que les répertoires ne peuvent pas bénéficier des « tags » à base de ln dans un système hiérarchiques… c’est… comment dire… schizophrène ?

                      • [^] # Re: les binaires, bof

                        Posté par  . Évalué à 2.

                        Tu n'as pas bien suivi le débat.
                        Il me demandait ce qui manque quand on a un système de fichier hiérarchique + les hard link par rapport a un système a base de tags, et je lui ai répondu:
                        les hards links sur les répertoires.

                        Si on a ça les 2 sont équivalents, oui.

                        • [^] # Re: les binaires, bof

                          Posté par  . Évalué à 1.

                          Tu n'as pas bien suivi le débat.

                          Faudrait savoir, en fait vous voulez un système de fichier taggé-mais-qui-a-quand-même-une-hiérarchie ? Parce que l’idée que je me fais d’un système de fichier par tag, c’est très précisément l’idée d’abandon d’une hiérarchie.

                          • [^] # Re: les binaires, bof

                            Posté par  . Évalué à 1.

                            Les idées c'est:

                            • on-veut-un-système-non-hiérarchisé
                            • on-a-déjà-un-système-non-hiérarchisé-c'est-le-système-unix-avec-les-dossiers-les-fichiers-et-ln
                            • non-en-fait-il-manque-ln-sur-les-dossiers
                            • [^] # Re: les binaires, bof

                              Posté par  (site web personnel) . Évalué à 1.

                              Les répertoires, ça sert à faire une hiérarchie. Par conséquent, vous ne voulez pas de répertoire, donc vous n'avez pas besoin de liens physiques sur les répertoires.

                              • [^] # Re: les binaires, bof

                                Posté par  (site web personnel) . Évalué à 4.

                                Ouais super, t'expliques à quelqu'un qui veut des tags comment les simuler de façon très chiante avec un système hiérarchique, il te montre qu'il manque des trucs, et maintenant tu lui réponds qu'il en a pas besoin.

                                T'as oublié tes pilules...

                                • [^] # Re: les binaires, bof

                                  Posté par  . Évalué à 6.

                                  Je ne comprends pas. Dans un FS non hierarchisé la notion de répertoire n'existe pas, non ?
                                  Un fichier n'est contenu que par un ensemble de libellé.

                                  Tanguy Ortolo, pense qu'il serait possible avec un hack un peu tordu d'utiliser les dossiers et les lien en dur comme des tags. Je ne vois pas l'utilité de faire des lien en dur sur des dossiers.

                                  Si c'est pour hiérarchiser les tag, je ne vois pas l'intérêt d'avoir souhaité au départ ne pas avoir de hiérarchie. Parce que si c'est pour dire qu'il faut créer un tag bin dans le tag usr par exemple c'est réinventer la roue.

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

          • [^] # Re: les binaires, bof

            Posté par  . Évalué à 3.

            Chez Apple c'est ce qu'ils ont fait, à peu de chose près. Ils ont bien compris que demander son avis à la communauté était tout sauf productif.

            Oui enfin, tout le merdier BSD sous-jacent ainsi que les services récupérés d'ailleurs fonctionnent encore avec des /bin, des /usr des /var et peut-être même /etc (en plus des jolis /Applications, /Developer, /System /Users - qui sont par ailleurs localisés - ).

            • [^] # Re: les binaires, bof

              Posté par  . Évalué à -6.

              (en plus des jolis /Applications, /Developer, /System /Users - qui sont par ailleurs localisés - ).

              Non. C'est juste le finder qui change le nom affiche, mais ouvre un terminal et fait un cd tu verras que le nom du répertoire ne change pas.
              Idem avec cmd shift g dans le finder.

              If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

        • [^] # Re: les binaires, bof

          Posté par  (site web personnel) . Évalué à 0.

          Tu devrais passer à OSX toi ;-)

        • [^] # Re: les binaires, bof

          Posté par  . Évalué à 10.

          /Configuration, ça serait plus parlant. Puis on aurait aussi /Libraries
          et /Data pour toutes les données du systèmes.

          Pfiu ça fait beaucoup de répertoires... Pourquoi ne pas les regrouper dans un répertoire principal que l'on appellerait, euh... Documents and Settings ?

        • [^] # Re: les binaires, bof

          Posté par  . Évalué à 4.

          moi j'appelle etc "Eléments Textuels de Configuration" ...
          ça revient au même ...

        • [^] # Re: les binaires, bof

          Posté par  . Évalué à 5.

          on pourrait l'appeler /Configuration, ça serait plus parlant. Puis on aurait aussi /Libraries pour toutes les bibliothèques du système, tant qu'à faire /Executable pour tous les exécutables du système et /Data pour toutes les données du systèmes.

          Tant qu'à faire pourquoi "/ProgramFiles" pour /bin, ça serait nettement plus simple pour ceux qui sont passés de Windows à Ubuntu.

      • [^] # Re: les binaires, bof

        Posté par  . Évalué à 2.

        Et quel est le problème avec /etc au juste ?

        Personnellement, j'aimerais avoir un /usr/etc où se trouverait la config des logiciels installés dans /usr. Après tout, c'est bien fait comme ça pour /usr/local/etc...

        Sinon
        * Le coup du /run sorti de /var, c'est très bien! Et mettons mtab et consorts par la même occasion!
        * La fusion des bin ne me semble avoir que des inconvénients (déjà évoqués).
        * j'ai du mal avec /var/www aussi. Je mettrais bien www dans /home, ne serait-ce que pour des raisons de simplification de mes sauvegarde...

        J'ai un peu l'impression que ces messieurs pensent beaucoup aux desktops personnels et oublient d'autres déploiements de Linux (Terminaux plus ou moins légers, embarqué...).

        • [^] # Re: les binaires, bof

          Posté par  (site web personnel) . Évalué à 0.

          /etc/local ce serait une bonne idée en effet. En revanche, il y a déjà /etc/opt, par exemple. Je ne sais pas où tu as vu un /usr/local/etc mais c'est horrible.

          /var/www c'est déprécié, tu peux mettre tes sites sous /srv, avec une convention à ta discrétion, par exemple /srv/www. Les serveurs Web fournis par les distributions sont configurés avec /var/www parce que justement, comme l'organisation de /srv est laissé à la discrétion de l'administrateur, ils ne peuvent pas faire de choix arbitraire dedans.

        • [^] # Re: les binaires, bof

          Posté par  (site web personnel) . Évalué à 2.

          Ah, pour mtab, excellente idée, l'avoir sous /etc est une horreur.

          • [^] # Re: les binaires, bof

            Posté par  . Évalué à 5.

            $ ls -l /etc/mtab 
            lrwxrwxrwx 1 root root 17 Apr  5  2011 /etc/mtab -> /proc/self/mounts
            
            
        • [^] # Re: les binaires, bof

          Posté par  . Évalué à 2.

          Personnellement, j'aimerais avoir un /usr/etc où se trouverait la config des logiciels installés dans /usr. Après tout, c'est bien fait comme ça pour /usr/local/etc...

          Par défaut, c'est le cas, dans le ./configure:

           Installation directories:
             --prefix=PREFIX         install architecture-independent files in PREFIX
                                     [/usr/local]
           [...]
             --sysconfdir=DIR        read-only single-machine data [PREFIX/etc]
          
          

          Donc "./configure --prefix=/usr" va utiliser /usr/etc.

          Par exemple, dans debian/ubuntu:
          samba:

                      --prefix=/usr \
                      --sysconfdir=/etc \
          
          

          bind:

                          --prefix=/usr \
          [...]
                          --sysconfdir=/etc/bind \
          
          

          Si ta distribution fait comme ça et que tu n'es pas d'accord, tu peux toujours te plaindre, changer de distro ou créer la tienne ^^.

    • [^] # Gainsbourg

      Posté par  (site web personnel) . Évalué à 10.

      ♩♫ Aux armes /etc... ♩♫

      http://gregr.fr

    • [^] # Re: les binaires, bof

      Posté par  . Évalué à -4.

      On peut quand même se poser la question si avoir autant de répertoires pour des binaires ça ne fait pas un peu beaucoup tout de même. J'ai d'ailleurs toujours un peu de mal à saisir la différence entre bin et sbin (si je me rappelle, on trouve dans /bin les binaires essentielles au démarrage du système, et les autres c'est dans /sbin).
      Par contre lier les 4 répertoires dans /usr/bin, ça risque d'être un joli bazar ce répertoire après vu le nombre de binaires présents.

      • [^] # Re: les binaires, bof

        Posté par  (site web personnel) . Évalué à 7.

        à l'origine

        dans /bin c'est les commandes de base des utilisateurs
        dans /sbin celles réservées aux admins

        tout est expliqué là : http://fr.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

        • [^] # Re: les binaires, bof

          Posté par  (site web personnel) . Évalué à 10.

          Pas besoin de préciser « à l'origine » : c'est toujours le cas.

          • [^] # Re: les binaires, bof

            Posté par  . Évalué à 3.

            Sauf pour systemd qui fout ses trucs dans /bin au lieu de /sbin

            • [^] # Re: les binaires, bof

              Posté par  (site web personnel) . Évalué à 10.

              C'est pour ça que Lennart veut tout changer maintenant. Il a pas bien lu la doc quand il a implémenté systemd et maintenant il préfère changer la distrib.

        • [^] # Re: les binaires, bof

          Posté par  . Évalué à 2.

          D'ailleurs c'est intéressant à noter que sous certaines distributions qui semblent suivre la FHS (Debian par exemple), sbin n'est pas le $PATH de l'utilisateur normal et il faut devenir root pour accéder aux binaires. Alors que pour d'autres (ArchLinux par exemple), sbin a été ajouté au $PATH pour le simple utilisateur, ce qui fait que du coup on ne voit plus trop la différence entre bin et sbin pour ces cas là.

          • [^] # Re: les binaires, bof

            Posté par  (site web personnel) . Évalué à 2.

            C'est la 'touch' debian ;-)

            • [^] # Re: les binaires, bof

              Posté par  . Évalué à 9.

              Et c'est très bien ainsi. Dans les programmes dans sbin ne sont pas utiles à un utilisateur normal.
              Vouloir fusionner bin et sbin ne me semble pas une bonne idée.

              • [^] # Re: les binaires, bof

                Posté par  . Évalué à 4.

                normalement oui.
                Je reviendrais quand même sur deux trois comme
                - lsof
                - ifconfig / ip

                Parce que ces programmes permettent d'accéder à des informations utiles (et aussi les modifier si on su, d'où le fait qu'elles sont dans /sbin).

          • [^] # Re: les binaires, bof

            Posté par  . Évalué à 6.

            pas besoin de devenir root pour accéder aux binaires. Pour les exécuter généralement oui. Par exemple pour zieuter ce qu'ifconfig cause, il suffit de taper un /sbin/ifconfig, pas besoin d'être root pour cela.

            • [^] # Re: les binaires, bof

              Posté par  . Évalué à 0.

              Donc au final, autant laisser /sbin dans le PATH, c'est toujours frustrant de devoir mettre le chemin complet pour accéder en lecture-seule à des commandes.

              • ifconfig/ip pour l'adresse IP
              • fdisk -l pour la liste des partitions
              • iwconfig/iw pour le WiFi
              • modinfo pour des infos sur un module kernel (me ditent pas que c'est une command admin parce que c'est compliqué, lsmod est bien dans /bin, y'a pas de raison)
              • [^] # Re: les binaires, bof

                Posté par  (site web personnel) . Évalué à -2.

                Pour l'admin, oui. Un utilisateur ordinaire qui n'a de toute façon pas accès à ces commandes en écriture se moque bien de les avoir en lecture seule.

                • [^] # Re: les binaires, bof

                  Posté par  (site web personnel) . Évalué à 4.

                  Pour l'admin, oui. Un utilisateur ordinaire qui n'a de toute façon pas accès à ces commandes en écriture se moque bien de les avoir en lecture seule.

                  Mmmh ? Bah alors, et l'anti-Minitel 2.0 ? Si un utilisateur non-admin expose un service (sur un port > 1000 évidemment) il peut vouloir utiliser ifconfig en lecture seule pour savoir quelle adresse communiquer à ses amis, non ?

                  La séparation /bin /usr/bin je veux bien, mais /sbin pas dans le $PATH c'est limite de la sécurité par l'obscurité.

                  • [^] # Re: les binaires, bof

                    Posté par  (site web personnel) . Évalué à 5.

                    Il ne s'agit pas de sécurité mais de commodité. L'utilisateur ordinaire préfère probablement ne pas être encombré par des commandes qui ne lui servent pas. S'il préfère les avoir en autocomplétion, super, il a aussi le droit de modifier son $PATH.

                    Avec cette séparation bin/sbin, on a le choix entre disposer facilement de toutes les commandes ou seulement celles destinées à une simple utilisation. Sans cette séparation, ben on n'aurait pas le choix !

                    • [^] # Re: les binaires, bof

                      Posté par  (site web personnel) . Évalué à 0.

                      Faisons un répertoire / par binaire alors, comme ça chacun pourra bien configurer son PATH comme il veut. Et ça change pas que ton « si t'as pas le droit de l'utiliser en écriture, alors t'en as pas besoin en lecture » était une bonne grosse connerie.

                      • [^] # Re: les binaires, bof

                        Posté par  (site web personnel) . Évalué à 4.

                        Et ça change pas que ton « si t'as pas le droit de l'utiliser en écriture, alors t'en as pas besoin en lecture » était une bonne grosse connerie.

                        Mais bordel, on a le choix ! Séparer /bin et /sbin permet aux gens de régler leur $PATH selon leurs besoin.

                        • [^] # Re: les binaires, bof

                          Posté par  . Évalué à 6.

                          je te rappelle qu'on est en train de répondre à :

                          Alors que pour d'autres (ArchLinux par exemple), sbin a été ajouté au $PATH pour le simple utilisateur,

                          ça reste toujours séparé en /bin et /sbin

                          Et va te laver la bouche au savon, c'est mal de jurer.

                          Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

                        • [^] # Re: les binaires, bof

                          Posté par  (site web personnel) . Évalué à 2.

                          Mais bordel, on a le choix ! Séparer /bin et /sbin permet aux gens de régler leur $PATH selon leurs besoin.

                          Tu n'as pas beaucoup de choix. Ton argument fait qu'on doit mettre une binaire par répertoire, pour le choix.
                          cd va être /bin/cd/cd
                          ls va être /bin/ls/ls
                          etc...

                          Comme ça, tu auras les choix, tu règles ton $PATH vraiment suivant ton besoin, parce que 2 répertoires séparés bizarrement, ben c'est pas un choix.

                          Pourquoi t'arrêter à 2 répertoires arbitraires alors que ton argument impose de faire un répertoire par binaire?

                          • [^] # Re: les binaires, bof

                            Posté par  . Évalué à 9.

                            cd va être /bin/cd/cd

                            Mauvais exemple, cd est une commande interne du shell, il n'y a pas de binaire correspondant ;-)

                            • [^] # Re: les binaires, bof

                              Posté par  (site web personnel) . Évalué à 0.

                              C'est malin, on m'avais toujours dit que tout était fichier sous Linux, on m'a menti!

                              • [^] # Re: les binaires, bof

                                Posté par  . Évalué à 10.

                                cd n'a pas de sens a exister en dehors du shell en fait. Il se contente de changer le répertoire de travail. Si c'était une commande externe, ça changerai le répertoire travail de la commande cd, mais celui du shell resterait inchangé.

                                • [^] # Re: les binaires, bof

                                  Posté par  . Évalué à -2.

                                  Et si le shell substitue "cd" par ". cd" en dur dans son code source ? Hein ? Hein ?

                                  • [^] # Re: les binaires, bof

                                    Posté par  . Évalué à 2.

                                    Il faudrait que ce soit un script shell qui utilise une commande built-in du shell.

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

                                    • [^] # Re: les binaires, bof

                                      Posté par  (site web personnel) . Évalué à 3.

                                      Non, pas plus. Si c'est un sous-processus, c'est mort, il ne peut pas agit sur le répertoire courant de son processus père.

                                      • [^] # Re: les binaires, bof

                                        Posté par  . Évalué à 2.

                                        . ou source ça permet d'éxecuter un script shell dans le shell courant.
                                        Une commande built-in c'est une commande du shell qui ne crée pas de nouveau processus (c'est ce que font cd, echo, set, etc).

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

                                        • [^] # Re: les binaires, bof

                                          Posté par  . Évalué à 1.

                                          Plus sérieusement, en revenant à la réponse de M. Barret, je ne comprends pas. N'est-il pas possible de manipuler l'environnement depuis un exécutable ? Le fameux dernier paramètre dans cette signature :

                                          int main (int argc, char** argv, char **envp)
                                          
                                          
                                          • [^] # Re: les binaires, bof

                                            Posté par  . Évalué à 3.

                                            Les dossier courant n'est une variable d'environnement (bien que certains shells ont une variable $PWD). Pour changer de dossier ont utilise l'appel système chdir(2) ou fchdir(2).

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

                                            • [^] # Re: les binaires, bof

                                              Posté par  (site web personnel) . Évalué à 5.

                                              Et puis, autoriser cela remettrais cause les principes d'UNIX d'héritage père fils ou un fils n'influe pas sur le père (pas de variable globale). C'est une des raisons de la solidité du modèle UNIX et de sa robustesse face au virus et autres cochonneries. C'est pour cela que je ne suis pas toujours fanatique de système de GUI moderne qui oublie un peu tout cela - bus global pour faire des espèces de variable globale (avec plus de gestion de la notion de groupe principale et d'autres choses amusantes).

                                              Dans les anciens gestionnaire de fenêtre, on faisait un restart ou un reload pour avoir une prise en compte. Par parfait mais on ne faisait pas des modifications tous les jours. Maintenant, on met du dbus partout mais un jour, un ver va se propager la dedans et on devra avoir un firewall dbus !

                                              • [^] # Re: les binaires, bof

                                                Posté par  . Évalué à 2.

                                                La seule raison pour laquelle mon . cd ne marchait pas c'était à cause de la création de processus, en effet.

                                                Par contre, essayez "set PWD=[path]" et vous verrez que vous avez changé de répertoire (en bash 4.1 du moins).

                                                • [^] # Re: les binaires, bof

                                                  Posté par  . Évalué à 2.

                                                  Oui mais ça ne marche que pour bash (ça ne marche pas pour dash ni pour zsh).

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

                  • [^] # Re: les binaires, bof

                    Posté par  (site web personnel) . Évalué à 5.

                    C'est peut être que ifconfig devrait être dans /bin mais pas forcément pour tous les programmes de /sbin.

                    D'ailleurs, il faut utiliser la commande ip qui EST dans /bin

                    ip link show

                    Mettre la commande ifconfig dans /sbin, c'est un moyen de la déprécier... (bien que je la trouve plus simple que ip).

                    • [^] # Re: les binaires, bof

                      Posté par  . Évalué à 4.

                      Désolé mais si ip et ifconfig sont dans 2 répertoires séparés, alors que ce sont 2 commandes "synonymes" quelque part ça montre assez bien le coté plutôt arbitraire de la séparation..

                      • [^] # Re: les binaires, bof

                        Posté par  (site web personnel) . Évalué à 3.

                        La commande ifconfig est obsolète... elles ne sont pas donc synonymes à 100%. Il me semble normal de "cacher" de l'utilisateur une commande obsolète mais de la garder un certain temps quand même pour les anciens scripts !

                        • [^] # Re: les binaires, bof

                          Posté par  . Évalué à 1.

                          ca aurait été plus malin et plus clair de mettre dans un répertoire genre /deprecatedbin ou/dbin ca aurait été plus clair je trouve.

                          • [^] # Re: les binaires, bof

                            Posté par  . Évalué à 3.

                            Ça aurait péter tous les scripts qui utilise le chemin d'accès complet.

                            « 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: les binaires, bof

                          Posté par  (site web personnel) . Évalué à 6.

                          Le vendredi 04 novembre 2011 à 23:41 +0100, Sytoka Modon a écrit :
                          > ifconfig est obsolète.

                          t'a un lien qui decris pourquoi ?

                          • [^] # Re: les binaires, bof

                            Posté par  (site web personnel) . Évalué à 2.

                            En cherchant 30s, j'ai retrouvé cela...

                            http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538433
                            http://www.debian.org/doc/manuals/debian-reference/ch05.en.html

                            Je crois qu'il y a des soucis avec IPv6... je ne sais plus bien. Debian pousse iproute2 qui installe la commande ip qui gère aussi les routes.

                            Je dois dire que 90% de mes scripts utilisent encore ifconfig... La migration va être longue ;-)

                            • [^] # Re: les binaires, bof

                              Posté par  . Évalué à -8.

                              Debian pousse iproute2

                              Debian pousse le dernier gadget de chez apple? étonnant.

                              If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                          • [^] # Re: les binaires, bof

                            Posté par  . Évalué à 5.

                            En réalité, la différence est relativement fondamentale. Ifconfig et ip n'ont pas la même façon de discuter avec le noyau. ip utilise netlink, qui permet de rajouter facilement des nouvelles options et est très flexible.

                            ifconfig quand a lui utilise encore les ioctl. L'objectif est de ne plus ajouter d'ioctl pour les services réseaux (car c'est lourd, Wikipedia explique bien pourquoi), et toutes les nouveautés à ce sujet du noyau doivent donc passer par ip (ou tout autre outil qui discute par netlink).

                            Pour l'utilisateur final qui n'a pas de gros besoins la différence reste surtout dans l'affichage... Personnellement je trouve ip plus pratique à l'usage, car il fait toute la configuration de la couche IP à lui tout seul (alors que sinon faut utiliser ifconfig, route...).

                    • [^] # Re: les binaires, bof

                      Posté par  . Évalué à 1.

                      D'ailleurs, il faut utiliser la commande ip qui EST dans /bin

                      Sous debian, archlinux, slackware et gentoo (au moins), la commande ip est dans /sbin

                      • [^] # Re: les binaires, bof

                        Posté par  (site web personnel) . Évalué à 3.

                        which ip
                        /bin/ip

                        J'avais fais l'essais avant de le dire (je suis sous debian squeeze).

                        • [^] # Re: les binaires, bof

                          Posté par  . Évalué à 1.

                          Ah ok, sous debian, c'est plus subtil :

                          $ ls -l /sbin/ip 
                          lrwxrwxrwx 1 root root 7 May 12 21:41 /sbin/ip -> /bin/ip
                          
                          
                    • [^] # Re: les binaires, bof

                      Posté par  (site web personnel) . Évalué à 3.

                      Le vendredi 04 novembre 2011 à 22:18 +0100, Sytoka Modon a écrit :
                      > ip link show

                      ip addr show plutot non ?

                    • [^] # Re: les binaires, bof

                      Posté par  . Évalué à 2.

                      [~]$ which ip
                      /sbin/ip

                      Ben pas chez moi

                      • [^] # Re: les binaires, bof

                        Posté par  . Évalué à 2.

                        En fait ça ne veut rien dire, si le binaire est présent/symlinké dans /sbin et /bin, ça dépend de l'ordre de ton $PATH.

                • [^] # Re: les binaires, bof

                  Posté par  (site web personnel) . Évalué à 2.

                  Pour l'admin, oui. Un utilisateur ordinaire qui n'a de toute façon pas accès à ces commandes en écriture se moque bien de les avoir en lecture seule.

                  Bof bof, quand on admine on le fait en utilisateur normal et on passe root seulement si besoin est.

                  Après la frontière est parfois floue, sous FreeBSD ping est dans /sbin (ben oui, commande système et en suid root) par exemple.

                  les pixels au peuple !

                  • [^] # Re: les binaires, bof

                    Posté par  . Évalué à 2.

                    sous FreeBSD ping est dans /sbin (ben oui, commande système et en suid root) par exemple

                    C'est dommage je sais pas sous FreeBSD, mais sous linux il y a une capabilities qui permet de ne pas lui donner suid root (CAP_NET_RAW, je ne pense pas qu'il constitue une faille, en tout cas moins que le suid).

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

              • [^] # Re: les binaires, bof

                Posté par  . Évalué à 5.

                ifconfig/ip pour l'adresse IP

                netstat -ie
                
                

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

    • [^] # Re: les binaires, bof

      Posté par  . Évalué à 1.

      Surtout que tous les gens qui ont mis un /usr et un / sur différente partitions seront dans la mouise (c'est à dire l'ensemble des PC que j'ai installé)

  • # Grosse connerie

    Posté par  (site web personnel) . Évalué à 10.

    Ce serait une grosse connerie, ça. /usr/(s)bin existe aujourd'hui précisément pour être séparé de /(s)bin afin de permettre des installation où, par exemple, /usr serait sur NFS, et ne pourrait être monté… qu'à une certaine étape du démarrage, avant laquelle /(s)bin suffirait.

    Bref, dans Fedora et autre ils font ce qu'ils veulent, mais cette idée ne s'imposera pas de façon générale. Debian ne pourra pas y adhérer, notamment.

    • [^] # Re: Grosse connerie

      Posté par  . Évalué à -10.

      Autant fusionner usr/bin et bin je suis plutot contre, mais fusionner bin et sbin je suis 100% pour

      Pour rappel le s de sbin ne signifie static ce qui est complètement outdated a l'heure actuelle

      • [^] # Re: Grosse connerie

        Posté par  (site web personnel) . Évalué à 10.

        Pour rappel le s de sbin ne signifie static ce qui est complètement outdated a l'heure actuelle

        Absolument pas, le "sbin" est la pour stocker les programmes dédiés a l'administration système et/ou rservés au super utilisateur,
        et le "s" est pour "system".

        http://www.pathname.com/fhs/pub/fhs-2.3.html#SBINSYSTEMBINARIES

        • [^] # Re: Grosse connerie

          Posté par  . Évalué à 2.

          Moi je croyais que le s était pour setuid bin ?

          D'ailleurs setuid tout court signifie en vérité set uid = 0 non ?

          Les noms de répertoires dans Unix sont sur trois lettres car à l'époque on comptait chaque octet. Maintenant ça paraît inutile vue la puissance que l'on a, même dans l'embarqué. Mais qui sait si un jour on aura pas besoin d'un Unix pour un nano-ordinateur biologique avec une mémoire de 4ko ? Je suis pour garder les noms de répertoire à trois ou quatre caractères. Après on peut effectivement adapter : /run vs /var/run par exemple.

          Je me suis toujours demandé d'où venaient ces noms :

          /bin : facile, c'est binary.
          /usr : user ?
          /var : variable ?
          /etc : là c'est plus dur, et cætera ?

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 1.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: Grosse connerie

              Posté par  . Évalué à 1.

              Cet acronyme est complètement anachronique et n'a aucun sens dans l'histoire d'Unix. Le nom du répertoire /etc provient bien de "et caetera".
              De plus, des noms des répertoires que tu as cité, aucun d'entre-eux n'a réellement existé sous Unix.

            • [^] # Re: Grosse connerie

              Posté par  (site web personnel) . Évalué à 5.

              Sous AIX (ou HP-UX j'ai un trous), le home du compte root était directement sous / !

              J'adore les UNIX propriétaire ;-)

          • [^] # Re: Grosse connerie

            Posté par  (site web personnel) . Évalué à 2.

            /usr => Unix System Ressource

            http://fr.wikipedia.org/wiki/Usr

            • [^] # Re: Grosse connerie

              Posté par  . Évalué à 1.

              Il s'agit encore d'un anachronisme. Le nom "usr" signifie "users", c'est a dire le répertoire personnel des utilisateurs. Sa fonction a néanmoins bien changé sur les dérivés d'Unix récents.

              • [^] # Re: Grosse connerie

                Posté par  . Évalué à 3.

                Il s'agit encore d'un anachronisme

                Tu veux dire rétroacronyme plutôt non ?

                • [^] # Re: Grosse connerie

                  Posté par  . Évalué à 1.

                  C'est effectivement un rétro-acronyme, mais c'est aussi un anachronisme parce que sa définition ne correspond pas du tout à l'utilisation qui était faite de ce répertoire à l'époque.

              • [^] # Re: Grosse connerie

                Posté par  (site web personnel) . Évalué à 1.

                Tu as une source ou un exemple stp ?
                Je n'ai jamais vu /usr utilisé comme /home à part peut-être sous novell (je ne me rappelle plus très bien : je n'utilise plus de novell depuis ... hooouuu longtemps :)).

          • [^] # Re: Grosse connerie

            Posté par  . Évalué à 4.

            Moi je croyais que le s était pour setuid bin ?

            non

            D'ailleurs setuid tout court signifie en vérité set uid = 0 non ?

            Non. setuid signifie set uid = uid of owner. Si l'owner est 0, ce qui est courant, le résultat est bien set uid = 0. Mais en aucun cas setuid tout court signifie systématiquement que de mettre uid = 0

    • [^] # Re: Grosse connerie

      Posté par  (site web personnel) . Évalué à 5.

      L'idée est que le montage de / est fait par l'initrd , donc à quoi ça sert d'avoir des binaires dans /bin et /sbin quand ils sont déja dans l'initrd.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 4.

        Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Grosse connerie

        Posté par  (site web personnel) . Évalué à 1.

        À pouvoir se passer d'initrd ? C'est encore utile sur certaines architectures.

        • [^] # Re: Grosse connerie

          Posté par  (site web personnel) . Évalué à 10.

          Il y a aussi des systèmes qui n'ont pas d'initrd du tout, des BSD par exemple, je pense. Or la FHS n'est pas spécifique à Linux, même si on sait déjà que Lennart n'en a rien à foutre des autres Unices.

          • [^] # Re: Grosse connerie

            Posté par  . Évalué à 10.

            Je peux aussi me customiser un système GNU/Linux facilement sans initrd, et il serait appréciable que des hippies n'essayent pas de niquer tout l'écosystème au pretexte que OIN C'EST COMPLIQUÉ YA DEUX REPERTOIRE BOUHOUH JE PEUX PLUS DORMIR. Lennart est notoirement connu pour n'en avoir rien à battre de toutes les fonctions existantes et des uses case qui ne l'intéressent pas, ce qui fait que même quand il a des idées intéressantes sur d'autres point, sa tendance à vouloir répandre ses softs à sa sauce partout (et le fait qu'il y arrive pas mal, en plus) en fait un type dangereux pour les gens qui utilisent vraiment les Unix comme des Unix et non pas comme des Windows/Mac Os X inférieurs.

            • [^] # Re: Grosse connerie

              Posté par  (site web personnel) . Évalué à 1.

              comme des Unix et non pas comme des Windows/Mac Os X inférieurs.

              Oué enfin sur ce point j'aurais tout de même séparé windows et mac question unix...

      • [^] # Re: Grosse connerie

        Posté par  . Évalué à 10.

        donc à quoi ça sert d'avoir des binaires dans /bin et /sbin quand ils sont déja dans l'initrd.

        Que certaines distribs n'utilisent pas d'initrd ?

        Désolé, mais quand je compile mon kernel, je mets en dur dedans le mini pour démarrer (FS, réseau et affichage) et le reste en module (carte tuner ou sondes températures par exemple). Donc, je n'ai pas besoin d'initrd.

        L'initrd aurait même plutôt tendance à me casser les baballes d'ailleurs.

        Mon kernel n'a pas vocation à booter sur 42000 configs différentes donc pas besoin de me trimballer tout le kernel ou presque en modules chargés direct au cas où j'aurais le matos X ou Y.

        Pour le reste, cette propale est Linux-centric et non, perso, le FHS tel qu'il est pour l'instant à moi me parait bien.

        Merger /bin et /sbin d'un côté et /usr/bin et /usr/sbin de l'autre me paraît être juste une grosse connerie.

        Déjà, si le FHS était appliqué correctement en entreprise, ça serait un gros plus. Marre de voir des "/application" "/logiciels" "/projets" "/mescouilles" etc. Avant de modifier la norme, essayons d'appliquer celle déjà en vigueur.

        cd /pub && more beer

        • [^] # Re: Grosse connerie

          Posté par  . Évalué à 2.

          Déjà, si le FHS était appliqué correctement en entreprise, ça serait un gros plus. Marre de voir des "/application" "/logiciels" "/projets" "/mescouilles" etc. Avant de modifier la norme, essayons d'appliquer celle déjà en vigueur.

          Je plussoie avec vigueur !!!

          Je ne me remets toujours pas des chemins débiles type /var/opt/etc ou /etc/opt/usr que je me tape tous les jours au taff ....

        • [^] # Re: Grosse connerie

          Posté par  (site web personnel) . Évalué à 2.

          Déjà, si le FHS était appliqué correctement en entreprise, ça serait un gros plus. Marre de voir des "/application" "/logiciels" "/projets" "/mescouilles" etc. Avant de modifier la norme, essayons d'appliquer celle déjà en vigueur.

          Ou alors cela montre que le FHS n'est, dans l'intégralité des cas :

          • pas compris
          • pas utile
          • pas adapté
          • pas pratique

          Et d'ailleurs si certains développeurs veulent modifier la norme c'est bien que le besoin existe, même si ça ne convient peut-être pas à tous les cas de figure (ça reste une question).

          • [^] # Re: Grosse connerie

            Posté par  (site web personnel) . Évalué à 1.

            Non non non, ça montre seulement que ce n'est pas compris. Dans l'immense majorité de ces abus, il existe un chemin standard qui conviendrait, seulement le responsable n'était pas au courant parce qu'il n'a pas la FHS en livre de chevet, c'est tout.

            • [^] # Re: Grosse connerie

              Posté par  (site web personnel) . Évalué à -1.

              Non non non, ça montre seulement que ce n'est pas compris

              Absolument pas.
              A moins que tu arrives à prouver qu'une seule solution existe, je ne vois pas comment tu peux affirmer cela.
              D'ailleurs, tu en montres tout de suite un exemple : s'il est nécessaire d'avoir la FHS en livre de chevet pour savoir où placer ses fichiers, que c'est compliqué et qu'il y a potentiellement un problème.
              D'ailleurs le simple fait que certains cherchent d'autres solutions, y compris dans l'écosysteme linux, c'est qu'il y a une raison.
              Et on voit aussi que d'autres font différemment sans problème (oui, mac)

        • [^] # Re: Grosse connerie

          Posté par  . Évalué à -1.

          Comment faire un / crypté si on n'a pas de initrd ?

    • [^] # Re: Grosse connerie

      Posté par  . Évalué à -3.

      C'est un besoin assez spécifique, et tu peux très bien ajouter le dossier NFS dans ton PATH, ou mettre carrément un lien symbolique de /bin vers ton dossier NFS

      Et ce n'est pas changer pour changer (vive le progrès !), mais plutôt une amélioration logique et réfléchie d'une tare qu'il nous reste de l'héritage d'UNIX et que tout le monde avait fini par accepter.

      « En fait, le monde du libre, c’est souvent un peu comme le parti socialiste en France » Troll

      • [^] # Re: Grosse connerie

        Posté par  . Évalué à 2.

        Sur Hurd ils avaient prévu de supprimer /usr et de simplement utiliser unionfs à la place, ce qui est quand même beaucoup plus élégant que d'avoir plusieurs niveaux de hiérarchie (/bin, /usr/bin, /usr/local/bin) et d'utiliser beaucoup PATH.

        Pour ajouter des binaires provenant d'un montage NFS, il suffit de le monter quelque part (/mnt/nfs?) et d'ajouter /mnt/nfs à l'unionfs principal.

        • [^] # Re: Grosse connerie

          Posté par  . Évalué à 6.

          Sur Hurd ils avaient prévu [...]

          Pourquoi avaient ? Hurd est mort ?

          • [^] # Re: Grosse connerie

            Posté par  . Évalué à 3.

            De mon point de vue oui.

            En gros, quand le projet Hurd/L4 a commencé à avancer, les gars de Hurd/L4 se sont aperçus que Hurd était mal conçu, les gars de Hurd ont dit que L4 n'était pas adapté à Hurd et ont dit qu'il vallait mieux attendre le prochain micronoyau.

            (ensuite ça a fait la même chose avec Coyotos)
            (ensuite ils se sont dit que le micronoyau devait aller de pair avec la définition du système, ils ont commencé à travailler sur Viengoos et Hurd-NG)

            On est en 2011, il n'y a rien de neuf depuis Hurd/Mach dans les années 90.

          • [^] # Re: Grosse connerie

            Posté par  . Évalué à -10.

            Effectivement.
            Pour être mort, faut deja avoir vécu.

            If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

    • [^] # Re: Grosse connerie

      Posté par  (site web personnel) . Évalué à 4.

      Ce serait une grosse connerie, ça. /usr/(s)bin existe aujourd'hui précisément pour être séparé de /(s)bin afin de permettre des installation où, par exemple, /usr serait sur NFS, et ne pourrait être monté… qu'à une certaine étape du démarrage, avant laquelle /(s)bin suffirait.

      Un autre avantage de l'utilisation de plusieurs préfixes où les préfixes sont associés à des systèmes de fichiers distincts: c'est utile pour la récupération des erreurs.

      Avec des partitions séparées:
      - on réduit le temps de récupération de la racine du système de fichiers s'il a été mal démonté;
      - on cloisonne les corruptions de données et on augmente les chances de garder un système racine sain;
      - on peut effectivement monter le système racine en read-only, pour éviter la corruption des fichiers système par une application malveillante.

    • [^] # Re: Grosse connerie

      Posté par  . Évalué à 1.

      Il me semble que systemd râle bruyamment quand /usr n'est pas sur la même partition que / ?

      • [^] # Re: Grosse connerie

        Posté par  (site web personnel) . Évalué à 6.

        Il me semble que systemd râle bruyamment quand /usr n'est pas sur la même partition que / ?

        Ben il ne devrait pas, c'est justement à être sur une autre partition que / que sert /usr!

        • [^] # Re: Grosse connerie

          Posté par  . Évalué à 2.

          Je n'ai pas d'opinion forgée sur le sujet, mais je suppose que c'est la raison pour laquelle Lennart est pour la fusion de /bin et /usr/bin.

          • [^] # Re: Grosse connerie

            Posté par  (site web personnel) . Évalué à 10.

            Ca prouve une chose si cela est vrai, c'est que systemd est beaucoup trop rigide pour tout baser dessus et il ne tiendra pas 10 ans à cette allure...

            Bref, cela me fait plus penser à un problème de conception !

            • [^] # Re: Grosse connerie

              Posté par  . Évalué à 1.

              Si tu lis les liens que j'ai mis (ce que tu n'as visiblement pas fait), tu verras que le problème ne se situe pas au niveau de systemd proprement dit mais d'autres services très communs qui sont invoqués au début du processus de boot principalement via des règles udev. Les problèmes sont liés aux locales, aux libs (notamment dbus), aux bases de données USB/PCI et autres trucs liés.

              • [^] # Re: Grosse connerie

                Posté par  . Évalué à 6.

                pourquoi il ne le monte pas plutôt alors ? Gérer ce genre de dépendance c'est je trouve le B-A BA de ce que devrait faire un système d'init.

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

              • [^] # Re: Grosse connerie

                Posté par  (site web personnel) . Évalué à 3.

                J'ai fais exprès de ne pas lire le lien pour simplement réagir sur la forme.

                Ce que j'en pense est que systemd a vouloir tout gérer dès le début me semble avoir un problème de conception s'il est aussi rigide. Il me semble normal qu'une partie du système ne soient pas monté au tout début (/usr ou autre (des services sous /srv...)). Si des programmes ont besoin de /usr, soit il faut les démarrer plus tard, soit il faut déplacer les dépendances de /usr vers /, soit il faut que le service se lance en mode dégradés puis se recharge au fur et à mesure des montages.

                L'ordre de montage et le lancement des services a toujours été un jeu subtil (bidouille _netdev dans fstab...). Une bonne archi doit pouvoir gérer cela. Je ne dis pas que c'est simple !

                Peut être systemd avec dbus et tout le tralala est un peu gros pour être le job 1... Pourquoi pas un systemd minimal qui au fur et à mesure du boot chargerait des greffons ?

                • [^] # Re: Grosse connerie

                  Posté par  . Évalué à 2.

                  Sauf que le problème principal ici ce sont les règles udev, et que udev prédate systemd. Et tu as besoin de udev pour trouver tous tes disques. Et sans /usr tu ne peux pas trouver les disques USB ou les controleurs PCI vu que c'est là que se trouvent les bases de données. Systemd proprement dit n'a pas de dépendances dans /usr. Comme il le dit sur la page, systemd est ici uniquement le messager, pas le problème.

                  On pourrait peut-être désemberlificoter tout cela, mais apparemment tout le monde s'en fout, ou en tout cas personne ne s'y intéresse suffisemment que pour corriger le problème.

                  • [^] # Re: Grosse connerie

                    Posté par  (site web personnel) . Évalué à 6.

                    Pourquoi ne pas tout simplement mettre les bases de données USB et PCI dans /lib ? On a bien un /lib/modules ! D'après ce que tu dis, cela semble plus un bogue udev que systemd...

        • [^] # Re: Grosse connerie

          Posté par  (site web personnel) . Évalué à 2.

          Tiens, d'ailleurs c'est le cas historiquement…

          • [^] # Re: Grosse connerie

            Posté par  (site web personnel) . Évalué à 3.

            De ma vie je n'ai jamais eu / et /usr sur la même partition! Au risque de passer pour un jeune dinosaure…

            Sous FreeBSD que j'utilise depuis 2000, l'outil d'installation crée une partition différente pour /usr' et je n'ai jamais vu l'intérêt d'y changer quelque chose: l'ensemble des fichiers écrits dans/a une taille peu fluctuante entre les mises-à-jour (du moins, mon dossier/` n'a jamais explosé!).

            Je ne parvies ni à me souvenir ni à retrouver un petit texte que j'avais lu expliquant pourquoi un dossier et une partition /usr avaient été introduits, et quelles nouvelles raisons pour son introduction avaient été trouvées au fur et à mesure que certains progrès techniques rendaient caduques les anciennes.

  • # Fedora

    Posté par  . Évalué à 1.

    Si j'ai bien compris, ce changement en concerne que les prochaines versions de FEDORA. Il ne s'agit pas de changer la LSB ?

    • [^] # Re: Fedora

      Posté par  . Évalué à 2.

      Non, c'est des changements proposés dans le FHS et qui semblent réaliser l'unanimité autour.

  • # Commentaire supprimé

    Posté par  . Évalué à 10.

    Ce commentaire a été supprimé par l’équipe de modération.

  • # euhhh

    Posté par  (site web personnel) . Évalué à 10.

    Corrigez-moi si je me trompe mais pour moi :
    - /sbin : les binaires systèmes essentiels (ex: ifconfig, su, sh ...)
    - /usr/sbin : les binaires systèmes non-essentiels (ex: route, ...)
    - /bin : les binaires applicatifs essentiels
    - /usr/bin : les binaires applicatifs non-essentiels
    idem avec lib.

    Donc pourquoi vouloir tout mélanger ?! C'est comme ranger les couteaux à poisson avec les couteaux à viande. tssss

    • [^] # Re: euhhh

      Posté par  (site web personnel) . Évalué à 4.

      • /usr/sbin : les binaires systèmes non-essentiels (ex: route, ...)

      Je te corrige car tu te trompe :

      $ which route
      /sbin/route

      route est un utilitaire essentiel, comment tu fais pour communiquer avec le monde extérieur si tu ne peux pas configurer tes routes ?

      • [^] # Re: euhhh

        Posté par  . Évalué à 6.

        Je te corrige car tu te trompes :

        Idem.

        • [^] # Re: euhhh

          Posté par  (site web personnel) . Évalué à 3.

          Erf la honte.
          /me se flagelle à coups de câble Ethernet.

          • [^] # Re: euhhh

            Posté par  (site web personnel) . Évalué à 7.

            câble catégorie 5 ou 6, pas câble Ethernet, ce serait confondre la fonction avec l'usage. D'ailleurs tu en fais un usage légitime qui n'a rien à voir avec le protocole Ethernet, à ce que je vois.

      • [^] # Re: euhhh

        Posté par  (site web personnel) . Évalué à 0.

        C'est pas faux et c'est vrai que je suis en /sbin après vérification :)
        Par contre sous Debian et SLES tu es en /sbin et sous Solaris en /usr/sbin.

    • [^] # Re: euhhh

      Posté par  . Évalué à 1.

      je ne suis pas admin système de haut vol (seulement du mien de système), alors je peux dire des conneries (ça ne changera pas bcp de d'habitude...), mais si je trouve nécessaire de séparer les binaires systèmes "sensibles" des autres (/usr/sbin et /usr/bin), par contre je trouve idiot de dupliquer des emplacements de binaires en pseudo catégories, cf. les fameux /usr/games/ /usr/share/games (wtf ?) /usr/local/games etc), ça veut dire quoi, que les jeux c'est moins important que par exemple un éditeur xml ?

      Quitte à séparer les binaires, pourquoi ne pas les mettre dans /usr/share/programme1, /usr/share/programme2 etc (ou équivalent plus parlant), en même temps que les données et la notice ? Comme ça quand on en a marre de jouer à kdiamond, on supprime /usr/share/kdiamond et il ne reste pas des bouts de logiciel un peu partout (dans /usr/man/kdiamond, dans /usr/doc/kdiamond/html, dans /usr/bin/kdiamond etc). Ah mais oui il y a le gestionnaire de paquets pour s'occuper de cela... et pour les programmes compilés maison, c'est dans /usr/local/doc/machin etc . Au final, au bout de 6 mois on ne sait plus si on a installé ce logiciel via le gestionnaire de paquets ou à la main et ça devient un beau bordel.

      Plus urgent, il serait temps aussi de déplacer une fois pour toute ces cochonneries de .dossiers présents dans le ~/, dans un ~/.config ou autre. Il y a des bidouilles pour simuler cela (par exemple http://freecode.com/projects/libetc que je n'ai pas eu le courage de tester, par peur de tout casser), mais il faudrait peut-être le faire de manière plus systématique et par défaut sur toutes les distributions.

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

      • [^] # Re: euhhh

        Posté par  (site web personnel) . Évalué à 1.

        ça veut dire quoi, que les jeux c'est moins important que par exemple un éditeur xml ?

        Non, ça veut dire qu'un type au travail n'en a pas besoin, et peut ainsi ne pas s'encombrer d'une autocomplétion sur les jeux, par exemple. Et s'il les veut, eh bien il change son $PATH, il a le droit aussi.

        La séparation entre logiciels d'administration, logiciels d'utilisation et jeux est pertinente. On pourrait aller plus loin mais il faut un compromis ; celui-ci est probablement historique, et assez pratique pour qu'on n'ait pas envisagé de le changer.

      • [^] # Re: euhhh

        Posté par  (site web personnel) . Évalué à 3.

        Ah mais oui il y a le gestionnaire de paquets pour s'occuper de cela... et pour les programmes compilés maison, c'est

        … dans /opt/logiciel. Et ça reste très propre.

        Plus urgent, il serait temps aussi de déplacer une fois pour toute ces cochonneries de .dossiers présents dans le ~/, dans un ~/.config ou autre.

        http://standards.freedesktop.org/basedir-spec/latest/. De rien.

        • [^] # Re: euhhh

          Posté par  . Évalué à 2.

          Malheureusement, tout le monde n'a pas l'air de la respecter ...

          https://bugzilla.mozilla.org/show_bug.cgi?id=259356

          Chez moi, cela reste un joyeux bordel. Cache, données temporaires, configuration, on y trouve de tout !

        • [^] # Re: euhhh

          Posté par  . Évalué à 2.

          Je me demande si un jour des logiciels comme vim, emacs et ceux qui se configure via ${HOME}/.Xdefault y passeront.

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

        • [^] # Re: euhhh

          Posté par  . Évalué à 2.

          et pour les programmes compilés maison, c'est
          … dans /opt/logiciel. Et ça reste très propre.

          sauf que make install généralement installe ça dans /usr/local/share (make prefix=$chemin/machin install n'est pas toujours pris en compte, et parfois certains binaires s'attendent à trouver les données dans un dossier particulier, genre /usr/lib/logiciel), et s'il faut faire des modifications compliquée pour installer un logiciel, autant faire un paquet.

          http://standards.freedesktop.org/basedir-spec/latest/. De rien.

          merci, je connais, et ça reste très peu suivi, y compris sur des projets récents, c'est une vraie plaie.

          Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

          • [^] # Re: euhhh

            Posté par  . Évalué à 1.

            C'est pour ça qu'il vaut mieux mettre le prefix=/usr/local/bidule lors de l'appel du ./configure au cas où il y aurait des variables fixées en dur lors de cette phase ou de la compilation.

            • [^] # Re: euhhh

              Posté par  (site web personnel) . Évalué à 1.

              Ça, c'est une violation de la FHS. Si tu as besoin d'un préfixe, tu as le choix entre /, /usr, /usr/local et /opt/logiciel. Mais certainement pas /usr/local/logiciel.

              • [^] # Re: euhhh

                Posté par  . Évalué à 1.

                moi j'utilise "$HOME/dvp/" , c'est pas FHS, mais ca sépare le système d'un utilisateur particulier.

                Sinon, dans /opt/bin /opt/lib/ etc... (enfin quand j'ai le courage).

                • [^] # Re: euhhh

                  Posté par  (site web personnel) . Évalué à 2.

                  Sinon, dans /opt/bin /opt/lib/ etc... (enfin quand j'ai le courage).

                  Ça c'est encore une violation de la FHS. Si tu veux classer les binaires, les bibliothèques et tout séparément, tu as /usr/local pour ça. /opt n'est pas un préfixe, c'est un répertoire pour des préfixes distincts.

                  • [^] # Re: euhhh

                    Posté par  (site web personnel) . Évalué à 0.

                    Au passage, il ne me viendrais pas a l'idée de mettre des binaires dans /usr/local, /opt est là pour ça.

                    • [^] # Re: euhhh

                      Posté par  . Évalué à 2.

                      /usr/local est bien pour les applications… mais locales : /usr/local ne devrait pas être sur NFS (p.ex.).

                      /opt peut être déporté (NFS…).

                      • [^] # Re: euhhh

                        Posté par  (site web personnel) . Évalué à 1.

                        beh /usr/local peut aussi être déporté (/usr existe pour cette raison) et d'après la FHS /usr/local est dédié aux -données- locales, alors qu' /opt est dédiés aux programmes optionnels => http://fr.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
                        Donc tu peux considérer un programme (une lib ou autre) comme une donnée mais dans ce cas, quelle différence entre /opt et /usr/local ?

                        • [^] # Re: euhhh

                          Posté par  . Évalué à 3.

                          Ce n’est pas parce que /usr est déporté que /usr/local l’est.

                          /usr/local est, je cite wp:en (un peu plus complète que wp:fr) : « [a t]ertiary hierarchy for local data, specific to this host. Typically has further subdirectories, e.g., bin/, lib/, share/ ». data est donc bien ici à prendre au sens large, sinon pourquoi bin et lib ?

                          Il y a aussi une note complétant cette description : « Historically and strictly according to the standard, /usr/local/ is for data that must be stored on the local host (as opposed to /usr/, which may be mounted across a network). » qui redit bien la non-déportation de /usr/local.

                          Et le reste de la note : « Most of the time /usr/local/ is used for installing software/data that are not part of the standard operating system distribution (in such case, /usr/ would only contain software/data that are part of the standard operating system distribution). It is possible that the FHS standard may in the future be changed to reflect this de-facto convention). » me conforte dans l’idée que /usr/local contient des applications.

                          Donc, oui, il y a toujours eu un chevauchement entre /opt et /usr/local dans le but, surtout pour lorsqu’on ne déporte rien, mais /opt contient un répertoire par application¹ (/opt/openoffice/{bin,lib,…}, /opt/jdk/{bin,lib,…}) alors que /usr/local est une hiérarchie comme / et /usr (avec l’utilisation du programme stow pour rendre tout ça plus propre).

                          ¹ Une note renvoie sur la bonne section de la FHS

                          • [^] # Re: euhhh

                            Posté par  (site web personnel) . Évalué à 1.

                            Après quelques recherches (plus) approfondies, voici ce que j'ai trouvé :

                            Concernant /usr/local :
                            tu as raison concernant les programmes : c'est une hiérarchie, du même type que /usr, dédiée au programmes installés par localement par l'admin et qui ne doivent pas être affectés par les mises à jour du système (contrairement à /usr qui lui peut être mis à jour par la distribution). (source : http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY)
                            En revanche, d'après cette source c'est partageable par un groupe d'hôtes donc la note de wikipedia est incorrecte : si plusieurs hôtes peuvent se partager un /usr/local commun c'est qu'il n'est pas obligatoire de stocker sur l'hôte cette hiérarchie, ou alors je ne comprend pas comment tu la partage (par rsync ???).

                            Concernant /opt :
                            /opt est destiné aux "add-on application software packages". Il y a toutefois une hiérarchie optionnelle prévue dans /opt (/opt/bin, /opt/lib, etc.) mais elle est réservée à l'admin et les softs doivent être dans des répertoires dédiés et doivent pouvoir fonctionner sans les repertoires /opt/bin et assimilés.
                            Pour ma part, je comprends qu'on y met "logiciels additionnels packagés". En gros, les trucs ne faisant pas partie de la distribution mais packagés par le fournisseur : java-sun, eclipse si tu l'installes toi même, firefox, perl si tu ne prend pas celui de la distro (oui j'utilise aussi une debian ;)) ...

                            Donc de ce que j'en comprends, la différence profonde entre /opt et /usr/local c'est, outre la structure, que les programmes de /opt sont susceptibles d'êtres mis à jour par le système du fournisseur du package logiciel (firefox, cpan, eclipse...), alors que ceux de /usr/local ne doivent pas être affectés par un tel système.
                            Pfiou, on va y arriver :)

                            • [^] # Re: euhhh

                              Posté par  . Évalué à 2.

                              Perso dans /opt, je met les logiciels Java qui ont juste besoin d'être dézipé (netbeans, glassfish, maven, tomcat, etc …).

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

      • [^] # Re: euhhh

        Posté par  . Évalué à 1.

      • [^] # Re: euhhh

        Posté par  (site web personnel) . Évalué à 4.

        Plus urgent, il serait temps aussi de déplacer une fois pour toute ces cochonneries de .dossiers présents dans le ~/, dans un ~/.config ou autre. Il y a des bidouilles pour simuler cela (par exemple http://freecode.com/projects/libetc que je n'ai pas eu le courage de tester, par peur de tout casser), mais il faudrait peut-être le faire de manière plus systématique et par défaut sur toutes les distributions.

        Amen sur ce point, mais ce n’est pas aux distrbutions d’y faire quelque chose… Une convention a été proposée, c’est aux développeurs upstream de l’implémenter dans leurs logiciels.

        libetc est une bidouille, le jour où les distributions auront recours à ce genre de choses pour pallier aux déficiences des logiciels on sera arrivé au niveau de Microsoft, qui virtualise le système de fichiers ou la base de registre pour permettre à des applications codées avec les pieds (par des développeurs qui se croient encore sous Windows 9x, et qui cherchent à stocker les préférences directement dans C:\Program Files au lieu de %HOME% par exemple) de fonctionner à peu près correctement.

        • [^] # Re: euhhh

          Posté par  (site web personnel) . Évalué à 3.

          s/pallier aux déficiences/pallier les déficiences/

          (Honte sur moi — mais quand même, il a trop raison ce mec.)

    • [^] # Re: euhhh

      Posté par  (site web personnel) . Évalué à 3.

      Sur la partition racine vont les fichiers nécessaires à l'amorce du système et son entretien, tout le reste dans /usr: c'est la règle qui définit essentiel.

  • # différencier les binaires linkés statiquement des autres.

    Posté par  (site web personnel) . Évalué à -2.

    /sbin est aussi utilisé pour stocker des binaires statiques. Ces binaires peuvent avoir plusieurs raisons d'être:
    * pour le démarrage sans répertoire de librairies
    * en cas de problème -démarrage dégradé-
    * En cas de problème ou d'environnement spécial avec ld preload (/etc/ld.so.preload)

  • # Vendredi

    Posté par  . Évalué à 10.

    Le portable sur les genoux, au coin du feu, avec un bon gros troll sur DLFP... un vendredi comme au bon vieux temps.

    Vous voulez pas la jouer soft ? Je suis pas contraignant... vous voulez la jouer hard ? On va la jouer hard

    • [^] # Re: Vendredi

      Posté par  . Évalué à 1.

      J'aurais tendance à dire que c'est un vendredi chargé en trolls entre cette dépêche, celle sur KDE 3.5 et le journal sur Gnome Shell. Heureusement qu'il n'y a rien sur le code de la route ni sur une question de société tel que l'avortement.

      • [^] # Re: Vendredi

        Posté par  (site web personnel) . Évalué à 1.

        Le vendredi 04 novembre 2011 à 16:37 +0100, Nonolapero a écrit :
        > Heureusement qu'il n'y a rien sur le code de la route ni sur une question de société tel que l'avortement.

        C'est triste ton opinion sur la façon de conduire des avorteuses grecques.

  • # /lib64

    Posté par  (site web personnel) . Évalué à 4.

    est une bidouille fait au moment de l'amd64.

    Debian a beaucoup bossé la question du multi-arch et a proposé une solution générique qui est en cours d'implémentation dans dpkg notamment. Pourquoi ne pas reprendre la solution debian ici ?

    Pour le reste, c'est du Lennart, un peu tout refaire pour des raisons de ménage. A vrai dire, ca semble pas spécialement intéressant au premier abord...

    Pour le /tmp global, debian le vide à chaque boot et c'est génial. Les tmp chez les utilisateurs ne sont jamais nettoyé... C'est pas bon non plus !

    • [^] # Re: /lib64

      Posté par  . Évalué à 0.

      Pourquoi ne pas reprendre la solution debian ici ?

      Pourquoi Debian a pas repris la solution RPM ? ça doit faire des années qu'on le fait dans Fedora, SuSE ou Mageia (et ses ancètres).

      • [^] # Re: /lib64

        Posté par  (site web personnel, Mastodon) . Évalué à -4.

        Pourquoi Debian a pas repris la solution RPM ? ça doit faire des années qu'on le fait dans Fedora, SuSE ou Mageia (et ses ancètres).

        Je retourne régulièrement tester les fedora, et à chaque fois la lenteur de la gestion des pacakges rpm me gonfle! Dpkg/apt me semble beaucoup plus rapide.

        • [^] # Re: /lib64

          Posté par  . Évalué à 6.

          ça n'a juste aucun rapport avec le multi-arch.

        • [^] # Re: /lib64

          Posté par  (site web personnel) . Évalué à 2.

          Dans ce cas va tester urpm* et tu verra que la lenteur n'est pas forcément liée à rpm.
          Bon après, franchement les paquets ça s'installe pas tous les jours (ou alors on a pas du tout le même usage...)

          • [^] # Re: /lib64

            Posté par  . Évalué à 2.

            Effectivement, perso j'ai tendance à installer / desinstaller des paquets au moins toutes les semaines, et certaines semaine tous les jours. Certains dev peuvent potentiellement installer des paquets des dizaines de fois par jour.

      • [^] # Re: /lib64

        Posté par  (site web personnel) . Évalué à 5.

        Pourquoi Debian a pas repris la solution RPM ?

        Mauvaise question. La bonne question, c'est : pourquoi RedHat n'a pas repris la solution DEB au lieu de développer son propre système RPM ? Désolé si je brise vos rêves, mais le premier système de gestion de paquets, c'est celui de Debian, hein.

        • [^] # Re: /lib64

          Posté par  . Évalué à 3.

          pourquoi RedHat n'a pas repris la solution DEB au lieu de développer son propre système RPM ? Désolé si je brise vos rêves, mais le premier système de gestion de paquets, c'est celui de Debian

          Parce que le premier n'est pas forcément le meilleur?

          Le preuve: avant, il y avait des téléphones portables, maintenant il y a l'iphone...
          Ok, c'est pas le meilleur exemple mais bon..

        • [^] # Re: /lib64

          Posté par  . Évalué à 10.

          Désolé si je brise vos rêve, mais le premier système de gestion de paquets (encore maintenu), c'est celui de slackware, hein.

      • [^] # Re: /lib64

        Posté par  (site web personnel) . Évalué à 6.

        parce que Debian a généralisé cela au multi-arch ou on peux faire un mix avec de l'ARM par exemple. C'est très bien expliqué par Raphaël Hertzog dans dpkg.

        http://lists.debian.org/debian-devel-announce/2011/06/msg00002.html
        http://wiki.debian.org/Multiarch/

        La source initiale mais j'en suis pas sur...

        http://raphaelhertzog.fr/2011/07/06/mes-activites-debian-en-juin-2011/

    • [^] # Re: /lib64

      Posté par  . Évalué à 2.

      Sous ArchLinux, /tmp est un tmpfs, ce qui fait qu'il est toujours supprimé lorsque l'ordinateur s'éteint. Auparavant, il s'agissait simplement d'un répertoire dont le contenu était supprimé lors de l'extinction et/ou de l'allumage, ce qui faisait entre autre que si l'ordinateur était coupé brusquement (typiquement, une coupure de courant), en démarrant sur un autre système d'exploitation, on pouvait aller regarder les fichiers dans /tmp.
      Maintenant, je suis peut-être un peu cruche, mais je ne vois pas ce qui empêche de reproduire ces deux comportements d'être appliqués à l'échelle de chaque utilisateurs plutôt qu'à l'échelle du système. Il y a bien moyen de faire exécuter des scripts lors de la connexion et déconnexion d'un utilisateur.

      LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140

      • [^] # Re: /lib64

        Posté par  . Évalué à 3.

        L'utilisation de tmpfs pose d'autres problèmes. Certains logiciels utilisent /tmp pour leurs fichiers temporaire. Quand le fichier temporaire fait 4Gio (par exemple pour créer une image iso et la graver sans demander à l'utilisateur d'effectuer les deux étapes séparément.

        Le problème dont tu parle devrais, je pense, pouvoir se faire sur disque avec un système de fichier en espace utilisateur (avec FUSE).

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

        • [^] # Re: /lib64

          Posté par  (site web personnel) . Évalué à 2.

          Le vendredi 04 novembre 2011 à 17:11 +0100, Barret Michel a écrit :
          > Quand le fichier temporaire fait 4Gio

          Où est le probleme puisqu'une fois la ram utilisée, il le mettra sur le disque dans la partition de ton choix ?

          • [^] # Re: /lib64

            Posté par  (site web personnel) . Évalué à 2.

            J'ai eu du mal à comprendre, donc pour ceux qui seraient dans mon cas : swap.

            • [^] # Re: /lib64

              Posté par  . Évalué à 3.

              C’est quand même un peu couillon de faire un tmpfs pour au final le retrouver dans le swap. Au final il aurait été plus simple de laisser le système gérer le cache disque (dont un /tmp en dur) tout seul comme un grand…

            • [^] # Re: /lib64

              Posté par  . Évalué à 1.

              Parce que le swap n'est de toute façon pas aussi grand que l'est la partition de /tmp ?
              Sérieusement, sur un desktop avec 4Go de ram, je vois pas l'intérêt du swap. D'ailleurs je l'ai viré de mes ordis, si ya plus de ram, ya plus de ram. Je vais pas attendre 3 minutes devant un écran complètement freezé que le kernel foute tout en swap, et tant pis pour le programme trop gourmand, il aurait été inutilisable de toute façon.

              • [^] # Re: /lib64

                Posté par  . Évalué à 6.

                D'une part c'est pas le problème soulevé.
                D'autre part si un jour tu te met à faire de l'hibernation avec tes machines, tu remettra des partitions de swap, je pense.

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

                • [^] # Re: /lib64

                  Posté par  . Évalué à -6.

                  Hibernation je m'en fous, et encore plus avec un système de fichiers crypté, j'ai du mal à voir comment ça serait possible.

                  • [^] # Re: /lib64

                    Posté par  (site web personnel) . Évalué à 9.

                    Et pourtant ça marche : l'initrd se charge de restaurer le système hiberné après que tu as fourni ce qu'il faut pour déchiffrer le disque (et donc l'état hiberné). Tu devrais essayer un peu les distribs post 2006 :-D

                  • [^] # Re: /lib64

                    Posté par  . Évalué à 5.

                    He ben tant mieux pour toi mais ne nous dis pas que :

                    Sérieusement, sur un desktop avec 4Go de ram, je vois pas l'intérêt du swap.

                    Parce que oui il y en a toujours des cas d'utilisation (et oui tu n'es pas le seul utilisateur au monde).

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

                    • [^] # Re: /lib64

                      Posté par  . Évalué à 2.

                      enfin même avec un desktop. Tu as une appli qui commence à faire n'importe quoi et phagocyte la ram, tu es "content" d'avoir du swap
                      -> 1°) pour éviter de planter la machine et permettant d'avoir une solution de repli
                      -> 2°) détecter le problème avec le ralentissement de la machine (bon ok c'est pas normalement le but escompté).

                      Perso j'ai 8Go de ram, et j'utilise principalement mon pc en desktop, ben j'ai une partoch de swap (et des fois j'ai même rajouter temporairement un fichier de swap).

                      Par contre la règle de deux fois la ram pour la swap...

                      • [^] # Re: /lib64

                        Posté par  . Évalué à 3.

                        Par contre la règle de deux fois la ram pour la swap...

                        Personnellement je met la même taille plus 100 Mio pour faire de l'hibernation. 2 à 8 Gio c'est quoi sur des disques qui font facilement plus de 500 Gio.

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

                        • [^] # Re: /lib64

                          Posté par  (site web personnel) . Évalué à 3.

                          Personnellement je met la même taille plus 100 Mio pour faire de l'hibernation.

                          Pareil sur portable.

                          2 à 8 Gio c'est quoi sur des disques qui font facilement plus de 500 Gio.

                          Ça par contre c'est un peu moins pertinent avec la déflation d'espace avec les SSD.

                          • [^] # Re: /lib64

                            Posté par  . Évalué à 3.

                            Ça par contre c'est un peu moins pertinent avec la déflation d'espace avec les SSD.

                            Pas encore essayer ces choses là. Mais en effet les ssd sont petits et leur taille diminue avec le temps.

                            Je pense que le plus important avec ce genre de matos c'est de limiter les écritures (pas de atime, limiter les log, jouer sur les quota ou l'espace disque réservé à root pour ne pas sur charger le disque, FS non-journalisé mais transactionnel, …).

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

                            • [^] # Re: /lib64

                              Posté par  (site web personnel) . Évalué à 2.

                              Bah toi qui fais du Java / RoR / ché plus quoi, tu devrais. Sur mon portable pro j'ai gagné presque 50% de temps de compilation sur mon projet Grails / Spring / ant :-D

                              Sinon ce que je voulais dire c'était pas trop une question de longévité (pas constaté de souci, en même temps c'est un SSD Intel, pas une merde noname), mais juste que quand t'as un disque de ~100Go (une taille raisonnable pour un SSD), d'un coup tu la sens plus, la partoche de 10Go de swap, que sur un HDD de XTo.

                              • [^] # Re: /lib64

                                Posté par  . Évalué à 2.

                                Bah toi qui fais du Java / RoR / ché plus quoi, tu devrais. Sur mon portable pro j'ai gagné presque 50% de temps de compilation sur mon projet Grails / Spring / ant :-D

                                Tu as tout a fait raison. Mon seul frein c'est le prix. Ils commencent a devenir abordable mais pas assez pour que j'en achète un sans en avoir un vrai besoin.

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

                                • [^] # Re: /lib64

                                  Posté par  . Évalué à 2.

                                  D'un autre côté, avec les inondations de la semaine dernière, le prix des disques dur va monter, donc les SSD auront l'air comparativement plus abordables.

                      • [^] # Re: /lib64

                        Posté par  . Évalué à 1.

                        -> 1°) pour éviter de planter la machine et permettant d'avoir une solution de repli

                        Si la machine se met à swapper, c'est souvent parce qu'une appli se met à démesurément consommer de la ram, parce que je ne suis pas proche de la limite en temps normal.
                        Et le temps que le kernel le fasse, l'écran est proche du gel complet, et la seule chose que je cherche à faire à ce moment là, c'est un xkill de l'appli qui bouffe tout. Si je ne met pas de swap, c'est le kernel qui s'en charge pour moi, je gagne du temps.

                        -> 2°) détecter le problème avec le ralentissement de la machine (bon ok c'est pas normalement le but escompté).

                        Quand tout le système va a la vitesse de firefox réécrit en java et sur un 486, tu t'en fous un peu, tu penses plutôt "stopper ça" le plus vite possible.

          • [^] # Re: /lib64

            Posté par  . Évalué à 3.

            Soit tu as défini une taille de tmpfs inférieur et le programme renvoie une erreur (ou se vautre c'est selon), soit il n'a pas ce genre de problème et c'est la mémoire que les programme peuvent utiliser qui va manquer à ce moment là tu swap et ça fait mal aux performance de la machine (et de son utilisabilité).

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

      • [^] # Re: /lib64

        Posté par  (Mastodon) . Évalué à 1.

        Avec pam_mount, j'ai bien un ~/tmp en tmpfs par utilisateur. Pour le /tmp, j'ai arrêté le ramdisk, c'est trop petit :)

      • [^] # Re: /lib64

        Posté par  (site web personnel) . Évalué à 3.

        AMA, la bonne solution c'est d'avoir des « vrais » (i.e. pas de tmpfs) /tmp et /var/tmp (éventuellement fusionnés et symlinkés) et d'utiliser tmpwatch [1] dans une tâche cron quotidienne pour assurer le nettoyage. Comme ça:

        • Pas de risque d'exploser la RAM en cas de gros fichiers temporaires;
        • Le nettoyage est fait régulièrement même en cas de plantage de la machine ou si on ne reboote pas (j'ai une machine avec des uptimes qui se comptent en mois et je suis bien content que les fichiers temporaires soient nettoyés un peu plus souvent que ça !)

        [1] http://fedorahosted.org/tmpwatch/

      • [^] # Re: /lib64

        Posté par  . Évalué à -1.

        Il ne faudrait pas induire les gens en erreur. Il n'y a pas de /tmp en tmpfs par défaut sous ArchLinux. Vous avez dû suivre le wiki à propos du SSD.
        https://wiki.archlinux.org/index.php/Maximizing_Performance#Mounting_.2Ftmp_to_RAM

        • [^] # Re: /lib64

          Posté par  . Évalué à 2.

          Tu m'a fait douter, je suis allé vérifier ici :
          http://www.archlinux.org/packages/core/any/filesystem/
          Il me semble que cela confirme qu'il y a bien un tmpfs par défaut. Le wiki n'est pas à jour, ce qui peut arriver.

          LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140

        • [^] # Re: /lib64

          Posté par  (site web personnel) . Évalué à 1.

          si si, sur les installations récentes. j'en ai fait l'expérience récement en voulant compiler un gros truc sur une installation fraiche sur un netbook (avec "seulement" 1 giga de ram)

          \Ö<

        • [^] # Re: /lib64

          Posté par  . Évalué à 2.

          Ça date de cet été. Zieute ton /etc/fstab.pacnew

    • [^] # Re: /lib64

      Posté par  . Évalué à 1.

      Pour la durée de vie des fichiers dans /tmp sous Debian, c'est réglable (voir TMPTIME dans /etc/default/rcS).

      Reynald

  • # FHS for human beings

    Posté par  . Évalué à 0.

    Attention, je vais troller :

    Et pourquoi on ne reprendrait pas tout à zéro, avec des noms lisibles par des êtres humains?

    /usr, /tmp, /home, /mnt, /etc, /dev, /sys, /proc, /var ça voulait sûrement dire quelque chose à une époque.

    /Devices à la place de /dev
    /configuration à la place d' /etc
    /Logs pour les journaux systèmes
    /Applications pour TOUTES les applications
    /Libraries pour TOUTES les bibliothèques
    /Users pour les répertoires utilisateurs
    /Shared à la place de /srv

    etc, etc..

    Ah bah oui, c'est fortement inspiré de Mac OS, mais faut avouer qu'ils avaient mis le doigt sur un truc.

    • [^] # Re: FHS for human beings

      Posté par  . Évalué à 10.

      /Devices à la place de /dev

      Ce n'est toujours pas lisible pour les êtres humains non anglophones. Je propose que les distributions s'adaptent à chaque langue, c'est encore mieux.

      Ah, le bonheur d'aller farfouiller dans /Périphériques pour dépanner un système en vrac, ça n'a pas de prix :)

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

      • [^] # Re: FHS for human beings

        Posté par  . Évalué à 2.

        UTF-8 pour tous et auto-complétion!

        Il faudrait que ce soit le shell qui s'occupe de l'internationalisation dans ce cas.

        En locale US, on ferait cd /Devices
        En locale FR, on ferait cd /Périphériques ou cd /Devices, ça reviendrait au même, d'ailleurs je crois que sous Win 7 ça marche comme ça, on peut taper C:\Utilisateurs ou C:\Users.

        • [^] # Re: FHS for human beings

          Posté par  . Évalué à 10.

          Merde, j'ai été pris au sérieux :(

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

        • [^] # Re: FHS for human beings

          Posté par  (site web personnel) . Évalué à 9.

          C'est pas beau, faut que ça soit lisible par quelqu'un qui n'y connais rien, avec un système moderne rien ne vaut des noms qui décrivent bien ce qu'il y a derrière:

          /Les Accès aux Périphériques
          /Les Programmes de l'ordinateur
          /La Configuration du système
          /Les Documents des Utilisateurs
          
          

          En ligne de commande, même avec la complétion, ça va être un plaisir. Et pour les scripts...

          Pfff. N'ont que ça a faire chez Fedora ?

          L'utilisateur simple reste principalement dans son /home/moncompte. Et ensuite, c'est le PATH qui indique où on cherche les binaires, donc que ça soit dans différents directory, ça n'a pas d'impact - le PATH a même l'avantage qu'on peut en ajouter certains si l'on veut.

          Feraient mieux de pousser/patcher et remonter en amont pour que les logiciels adoptent les normalisations XDG de stockage des préférences.

          Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

          • [^] # Re: FHS for human beings

            Posté par  . Évalué à 1.

            Il ne s'agit pas forcément de rendre l'arborescence Linux accessible à tout le monde, mais de faciliter l'apprentissage pour ceux qui veulent mettre les mains dans le cambouis, ou les développeurs qui veulent savoir où mettre leurs fichiers. Ça incitera d'ailleurs ces dernier à continuer de développer pour Linux.

            Une certaine interprétation du KISS.

            • [^] # Re: FHS for human beings

              Posté par  . Évalué à 5.

              T'as du fumer des trucs chelou. Si tu veux mettre les moins dans le cambouis tu peux aller acheter quelques livres chez ton libraire préféré, qui t'expliqueront très bien à quoi sert /usr and co. C'est quoi la prochaine étape sinon, recoder tous les programmes de l'univers en visual basic pcq c'est plus simple à lire que du C++, et croire qu'un type lambda sans formation va magiquement savoir coder après avoir lu 3 lignes de VB sans aucune autre documentation ?

              • [^] # Re: FHS for human beings

                Posté par  . Évalué à 1.

                [sarcasme]
                Rassure-toi, mon matos est de qualité.
                [/sarcasme]

                Revoir la FHS des distribs Linux n'est pas crucial puisqu'effectivement tout est documenté. Mais c'est tout de même devenu un certain bordel avec les années, alors si on peut simplifier les choses autant le faire. Moins le processus d'apprentissage est long, plus nombreux sont les gens à maîtriser l'outil.

                Quand je parle de mettre les mains dans le cambouis, je ne parle pas de recoder les programmes. Je pense plus aux développeurs qui viennent d'autres OS et qui veulent comprendre assez vite comment packager leurs applis pour Linux, puisqu'ils ont déjà plusieurs plateformes à supporter.

            • [^] # Re: FHS for human beings

              Posté par  (site web personnel) . Évalué à 6.

              Perso je pense que les personnes qui se mettent a développer leurs softs sont capables de lire et comprendre le FHS, je ne crois pas que ça soit ça qui freine le fait de développer sous Linux.

              Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

      • [^] # Re: FHS for human beings

        Posté par  (site web personnel) . Évalué à 3.

        Pas de souci, il suffit de mettre dans un fichier .directory la traduction en 42 langues du nom du dossier et de modifier les appels systèmes pour aller lire le nom dans ce fichier !

        A oui mais c'est risqué de faire ça au un aussi bas niveau. Faisons le que pour les outils graphiques alors et pour les dinos qui utilisent la ligne de commande, à eux de connaître le vrai nom.

        -> []

        L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

    • [^] # Re: FHS for human beings

      Posté par  . Évalué à -1.

      Tu oublies l’essentiel.
      Comment un linuxien pourra frimer face aux noobs si tout le monde peut comprendre ? Un système utilisable sans prendre la peine de lire des tonnes de pages de manuel, c’est vraiment trop nul. Ça fait user-friendly kikoolol. Les trucs intelligibles, c’est pour les neuneus.

      En plus, ça voudrait dire que même Microsoft avait de l’avance (un peu). Impensable. Blasphématoire.

    • [^] # Re: FHS for human beings

      Posté par  (site web personnel) . Évalué à 5.

      Et pourquoi on ne reprendrait pas tout à zéro, avec des noms lisibles par des êtres humains?

      Je suggère un C:\ avec tout dedans.

      les pixels au peuple !

    • [^] # Re: FHS for human beings

      Posté par  (site web personnel) . Évalué à 3.

      C'est exactement ce que fait GoboLinux: http://www.gobolinux.org/

      • [^] # Re: FHS for human beings

        Posté par  . Évalué à 1.

        In GoboLinux you don't need a package database because the filesystem is the database: each program resides in its own directory, such as /Programs/Xorg-Lib/7.4 and /Programs/KDE-Libs/4.2.0.

        Ca ouvre des perspectives intéressantes je trouve

        • [^] # Re: FHS for human beings

          Posté par  . Évalué à 2.

          Un meilleur fonctionnement, peut-être. :°

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

      • [^] # Re: FHS for human beings

        Posté par  . Évalué à 1.

        Ce qui paraît séduisant chez Gobolinux, c'est la possibilité d'installer et de désinstaller proprement et simplement (et sans base de donnée) plusieurs versions d'un même programme ou d'une même librairie.

        De même que le système des recettes, qui installe directement une application à partir des sources du site web d'origine, sans modification, ni passage par l'intermédiaire d'un dépôt. Théoriquement, vu qu'on peut refaire ses propre recette en quelques lignes. Il y a moyen de suivre les derniers mise à jour presqu'en temps réel.

        En théorie. En pratique ça rend le système compliqué à utiliser pour un débutant. J'imagine que ça doit rappeler la Slackware à ses débuts :-)

  • # Win32

    Posté par  . Évalué à 10.

    Peut-être bientôt :

    mv /usr /system32

    • [^] # Re: Win32

      Posté par  . Évalué à 3.

      toudoup bruit de la fenetre "admin" de vista

    • [^] # Re: Win32

      Posté par  . Évalué à 2.

      En fait system32 c'est plutôt un genre de /etc/lib oO

    • [^] # Re: Win32

      Posté par  . Évalué à 3.

      Avec tous les binaires 64-bits dedans. Les 32-bits iront dans /LoL64 (en plus il rox ce nom) avec :

      if (!redir_disabled && !strncmp(path, "/system32/", strlen("/system32/")) {
        path += strlen("/system32") - strlen("/LoL64");
        memcpy(path, "/LoL64", strlen("/LoL64"));
      }
      
      

      quelque part dans Linux.

      Et un dev chargé de maintenir ça expliquera dans des blogs post a quel point cette idée est brillante et à quel point on aime nos utilisateur et on se soucis de la retrocompatibilité.

      • [^] # Re: Win32

        Posté par  . Évalué à 3.

        Sauvez des compilos, utilisez sizeof().

        • [^] # Re: Win32

          Posté par  . Évalué à 4.

          Utilisez sizeof() - 1, tu veux dire.

        • [^] # Re: Win32

          Posté par  . Évalué à 2.

          Contrairement à une idée répandue (et compréhensible), « sizeof » ne prend pas de parenthèse en C. On n'est obligé de les mettre que lorsque c'est la taille d'un type que l'on mesure (même syntaxe qu'un cast, donc).

  • # Logique ?

    Posté par  . Évalué à 3.

    fusionner « /bin », « /sbin », et « /usr/sbin » dans « /usr/bin » ;

    Pourquoi /usr/bin dans ce cas ? Si y'a plus de séparations entre les programmes la raison d’être d'/usr disparaît, alors pourquoi le garder ?

    Évoluer d'accord, mais les choses ont étés créées avec une certaine logique et il faut conserver une logique, pas forcement celle du dépars. Si tu te contente de patcher à la gruïk sans te soucier la cohérence de l'ensemble « à partir d'aujourd’hui on balance tout dans /usr/bin », j’imagine dans 25 ans :

    • Pourquoi on installe les logiciels sous /usr ?
    • PARCE QUE C'EST COMME ÇA.

    Encore quelques idées du genre et ça va être sympas à étudier la FHS...

    • [^] # Re: Logique ?

      Posté par  (site web personnel) . Évalué à 4.

      L'idée est de pouvoir mettre /usr sur une partition séparé pour pouvoir faire des snapshots btfs, pour monter ça en readonly, etc. Chose un chouia moins facile à faire avec /. C'est expliqué dans le thread donné en lien.

  • # Poettering

    Posté par  . Évalué à 10.

    Bref, pour résumer, on a un type qui pense pouvoir révolutionner le démarrage des distributions linux, qui casse complètement toutes les compatibilités posix et qui se rend compte que si /usr est monté à part, plus rien ne marche. Du coup au lieu de dire que son système est mal fichu dès le départ, il veut rompre avec plus de 40 ans d'organisation parce qu'il pense que ce sera mieux. Belle mentalité.
    Une fois qu'il se rendra compte que l'organisation des fichiers proposés ne convient pas aux cas x ou y, il fera changer udev, puis X, puis bash et là, plus rien ne marchera.
    Je ne dis pas qu'il ne faut pas de changement, juste qu'il faut normaliser au maximum et que oui, ça prend du temps. Si on regarde xmpp, il a mis énormément de temps à être normalisé, mais maintenant tout le monde l'utilise.

    Honnêtement, l'utilisateur lambda n'en a rien à faire de l’arborescence et de la différence entre /bin, /usr/bin … L'admin système lui a appris avec cette arborescence et n'a pas besoin de se compliquer la vie, refaire ses scripts… Surtout s'il utilise plusieurs systèmes Unix. Le débutant admin apprendra comme tout le monde. Ce n'est quand même pas très compliqué. Les développeurs/mainteneur de paquets n'auront pas à maintenir plusieurs arborescences avec toutes les erreurs possibles.

    • [^] # Re: Poettering

      Posté par  . Évalué à 2.

      Bref, pour résumer, on a un type qui pense pouvoir révolutionner le démarrage des distributions linux, qui casse complètement toutes les compatibilités posix et qui se rend compte que si /usr est monté à part, plus rien ne marche. Du coup au lieu de dire que son système est mal fichu dès le départ, il veut rompre avec plus de 40 ans d'organisation parce qu'il pense que ce sera mieux. Belle mentalité.

      Encore une fois, ce n'est pas systemd qui a du mal avec /usr mais udev.

      « 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: Poettering

        Posté par  . Évalué à 7.

        Oui, mais ça marchait bien avec l'ancien système d'init non ?

        De toute façon, ça rejoint quand même mon propos, puisque udev a remplacé hald alors qu'il était lui-même "révolutionnaire" et il (udev) est linux-only.

        • [^] # Re: Poettering

          Posté par  . Évalué à 2.

          Je ne suis pas sûr mais si j'ai bien compris, ça marche mais pas tout le temps (ou ça marche mais il y a des comportements étrange après). Du coup, comme ils ne veulent pas d'un truc bancale, ils ne le prenne pas en charge.

          « 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: Poettering

          Posté par  . Évalué à 1.

          udev n'a pas vraiment remplacé hald... c'est un peu comme si tu disais que alsa a remplacé arts. Il n'y a pas remplacement, il y a juste "cette couche intermédiaire ne sert à rien".

          udev a plutôt remplacé devfs et hotplug, et le problème est identique avec sysvinit.

        • [^] # Re: Poettering

          Posté par  . Évalué à 3.

          Oui, mais ça marchait bien avec l'ancien système d'init non ?

          Pas mieux qu'avec systemd.

          Étienne

    • [^] # Re: Poettering

      Posté par  . Évalué à 7.

      Bref, pour résumer, on a un type qui pense pouvoir révolutionner le démarrage des distributions linux, qui casse complètement toutes les compatibilités posix et qui se rend compte que si /usr est monté à part, plus rien ne marche

      Tu résumes mal. Primo, Posix n'a jamais normalisé le démarrage ni le la hiérachie du système de fichiers. Secundo, pour le démarrage, même au sein des init SysV, la portabilité est quasi-inexistante en dehors des systèmes LSB (et la plupart des distros y compris Debian fournissent des scripts non-LSB). Ça fait des années qu'il y a un consensus au sein des distros GNU/Linux pour passer à autre chose, pendant un moment, c'était Upstart, mais il était de fait abandonné par son mainteneur et n'a pas su créer une communauté autour de lui quand systemd a été lancé.
      Pour avoir écrit des scripts d'init pour plusieurs distros, je préfère largement les unités systemd bien carrés au bordel actuel à base de scripts shells et de routines spécifiques à chaque distro.
      Tertio, le FHS c'est une initiative faite par les distros GNU/Linux pour normaliser la hiérarchie, sauf qu'elle n'est pas parfaite et qu'aucun membre ne l'a respecte. Lennart a permis de ressusciter le groupe de travail en lançant des discussions pertinentes, les discussions pour le FHS 3.0 sont ouvertes à tous, et les choix finaux seront votés.

      Faut arrêter la paranoïa anti-Lennart, c'est une grande gueule avec des opinions très tranchées (notamment sur *BSD° certes, mais c'est un type super compétent et avec qui on peut bosser. Si vous voulez parler à des murs, essayez de bosser avec les mainteneurs d'Unity ou de XBMC sur une autre plateforme que celle de référence.

      • [^] # Re: Poettering

        Posté par  . Évalué à 4.

        Faut arrêter la paranoïa anti-Lennart, c'est une grande gueule avec des opinions très tranchées (notamment sur *BSD° certes, mais c'est un type super compétent et avec qui on peut bosser. Si vous voulez parler à des murs, essayez de bosser avec les mainteneurs d'Unity ou de XBMC sur une autre plateforme que celle de référence.

        C'est vrai qu'au moins il essaye de faire changer les choses. La seule chose que je reproche, c'est que ça n'a pas l'air structuré et que l'on change de solution tous les quatre matin.

        • [^] # Re: Poettering

          Posté par  . Évalué à 10.

          C'est surtout que les lennarteries sont toujours des solutions globales qui impose des changements à toutes les applications de telle sorte que les dites applications finissent toujours par dépendre de cette solution. Et si tu veux faire la même chose avec une alternative, tu fini toujours par crever.

          Alors qu'avant on avait pas de problèmes pour faire tout ce qu'on voulait avec des logiciels indépendants et des protocoles un peu indépendants.

          • [^] # Re: Poettering

            Posté par  . Évalué à 3.

            C'est surtout que les lennarteries sont toujours des solutions globales qui impose des
            changements à toutes les applications de telle sorte que les dites applications
            finissent toujours par dépendre de cette solution. Et si tu veux faire la même chose
            avec une alternative, tu fini toujours par crever.

            Un peu comme Steve Jobs, quoi…

      • [^] # Re: Poettering le Uwe Boll du monde Unix

        Posté par  . Évalué à -3.

        Ce n'est pas tant qu'il bouge son "cul", il y a RedHat derrière et cela lui donne un poids certains.
        Moi ça me dérange que l'avenir de Linux soit dirigé par cette boîte multimilliardaire et part le Uwe Boll du monde Unix.

Suivre le flux des commentaires

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