Journal udev forké

Posté par . Licence CC by-sa
48
4
sept.
2012

udev, le gestionnaire de périphériques dans /dev vient d’être forké. C’est grâce à cet outil que l’on peut, par exemple, monter automatiquement des disques externes ou des clés USB, et les afficher dans un explorateur. En effet, udev reçoit des messages de la part du noyau et les traite en fonction d’un ensemble de règles définies dans les répertoires rules.d. Ainsi, il est possible de lancer des sauvegardes dès que le disque dur correspondant est branché sur la machine.

Au mois d’avril, les sources de udev ont été déplacé dans l’arborescence de systemd. Le but est de forcer l’utilisation de systemd pour pouvoir utiliser udev, illustré par la célèbre citation de Lennart :

Yes, udev on non-systemd systems is in our eyes a dead end, in case you
haven't noticed it yet. I am looking forward to the day when we can drop
that support entirely.

Que l’on peut approximativement traduire par : « Oui, udev sur les systèmes non-systemd est à nos yeux un cul de sac, au cas ou vous n’auriez pas encore remarqué. J’attends avec impatience le jour où nous pourrons entièrement laisser tomber ce support. » Cette phrase a lancé tout un tas de commentaires, par exemple sur reddit. Lennart, son caractère, et son rêve, GNU/Lennax, étant probablement encore moins appréciés qu’Ulrich Drepper (tous passés par Red Hat).

L’incorporation d’udev dans systemd est assez contraignante puisqu’il faut non seulement télécharger tout le paquet systemd, mais aussi appliquer des patchs, par exemple ceux de Linux From Scratch, pour avoir un système cohérent. Le nouveau fork permet de résoudre ces problèmes, par exemple sous Gentoo.

Le plus gros problème, d’un point de vue idéologique, étant systemd. En effet il s’agit d’un gros logiciel (plusieurs dizaines de milliers de lignes de code) incorporant tout un tas de fonctionnalités, avec des dépendances largement discutables pour un système d’initialisation (notamment D-BUS), tout en étant entièrement spécifique à Linux. Si vous avez perdu votre temps à apprendre les scripts shells, vous pouvez tout remballer pour apprendre la nouvelle syntaxe pour systemd. Là aussi, devant le passage en force que font certains développeur pour passer à systemd, notamment sous ArchLinux (un comble étant donné que rc.conf était l’une de ses grandes forces), différents forks sont à attendre.

  • # la guerre de s unices

    Posté par . Évalué à  10 .

    apres la guerre des unices qui a tuer les unix proprio (et a laissé l opportunité d`expansion à Linux) voici la guerre fratricide des linux

    hallucinant

    • [^] # Re: la guerre de s unices

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

      Bof. Ça va vite tourner à la guerre de Lennart contre le reste du monde. Il l'a un peu cherché en même temps.

      • [^] # Re: la guerre de s unices

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

        Pas sûr. Pour ma part, je trouve son travail plutôt pas mal. L'init sysV actuel est quand même bien pourri.

        Et si le script shell finit par mourir, c'est pas moi qui me plaindrais :) On a fait largement mieux depuis comme langage.

        • [^] # Re: la guerre de s unices

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

          Moi aussi je trouve ça pas mal dans l'idée, mais ce mec est un troll-né… Coder volontairement pour Linux seulement, et envoyer chier les autres comme des malpropres…

          • [^] # Re: la guerre de s unices

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

            Est-ce qu'il a déjà refusé des patchs qui apportaient la portabilité vers d'autres noyaux ? (c'est une vraie question)

            • [^] # Re: la guerre de s unices

              Posté par . Évalué à  10 . Dernière modification : le 04/09/12 à 20:30

              Lennart a annoncé qu’il refuserait les patchs pour d’autres systèmes (il n’aime pas les #ifdef), et que c’est aux autres systèmes à proposer une émulation de Linux pour que systemd tourne dessus.

              • [^] # Re: la guerre de s unices

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

                .. ou de maintenir un fork avec lesdits patches. C'est exactement ce qui est fait pour OpenSSH. La version pour Linux est annotée "p" (pour portable), ce n'est pas directement celle de OpenBSD.

                • [^] # Re: la guerre de s unices

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

                  Pour rappel la version portable de OpenSSH est maintenu par l'équipe de OpenSSH. C'est une volonté de leur part de faire un logiciel pour OpenBSD puis de le rendre portable partout ce qui fait que les sources sont légèrement différente.

                  Lennart ne maintient pas deux branches à ce que je sache ?

              • [^] # Re: la guerre de s unices

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

                Sa position, si je la résume, m'a l'air de tout à fait tenir :

                "Si vous voulez rendre systemd compatible avec d'autres noyaux, ça va créer un machin horrible à maintenir, je ne veux pas le faire. Mais quiconque veut le faire peut"

                Autrement dit : le systemd de Lennart ne sera pas compatible avec autre chose que Linux, mais rien n'empêche JohnDoe de créer JDsystemd qui sera compatible avec tous les noyaux, et qui peut même être accepté partout.

                C'est incroyable ça. Le type fait le logiciel comme il l'entend, il le rend dispo à tout le monde, mais on trouve le moyen de se plaindre de lui parce qu'il ne veut pas bosser à l'oeil pour son propre noyau.

                Bon sang, systemd est même sous LGPL, qui contient quand même ce bout en ALL CAPS :

                COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE

                Si ça ne fait pas ce que tu veux, dommage pour toi, Lennart et les contributeurs ne te doivent rien. Forke donc !

                • [^] # Le thread dont vous éte le Mollah

                  Posté par . Évalué à  10 . Dernière modification : le 04/09/12 à 23:29

                  C'est exactement ça, quand le créateur de GCompris a exposé les différentes demandes plus ou moins folles de communautés tout le monde a dit qu'il doit faire ce qu'il veut, que c'est son travail et que c'est déjà gentil de le mettre à la disposition de tous, ce qui ne sont pas contents n'ont qu'a forker…

                  Et là on retrouve les mêmes, sauf que cette fois ça c'est eux la communauté chiante, le libre c'est leur science et il savent mieux que Lennard ce qu'il doit développer.

                  • [^] # Re: Le thread dont vous éte le Mollah

                    Posté par . Évalué à  10 .

                    Si c'était Lennart le problème, tout le monde s'en cognerait.

                    Le problème avant tout c'est la volonté de l'imposer partout via des astuces comme l'intégration d'udev citée dans ce journal, et que les distributions commencent à suivre le mouvement.

                    Systemd n'a pas vraiment fait ses preuves et a des avantages pratiques peu tangibles par rapports aux autres systèmes d'init. Par contre il permet d'isoler complètement une partie de l'userland GNU/Linux et aliéner le reste des systèmes d'exploitations libres, et ça s'est dangereux.

                    • [^] # Re: Le thread dont vous éte le Mollah

                      Posté par . Évalué à  10 .

                      Le problème avant tout c'est la volonté de l'imposer partout via des astuces comme l'intégration d'udev citée dans ce journal, et que les distributions commencent à suivre le mouvement.

                      Plusieurs trucs me pose problème dans ta phrase :

                      – la volonté de l'imposer : à mon avis, si les distributions commence à fournir systemd, c'est qu'il y a des raisons techniques. Il me semble plutôt « choisit » que « imposer ».

                      – astuces comme l'intégration d'udev : encore une fois, il me semble que les développeurs d'udev ne sont pas contre cette inclusion… ce n'est donc peut⁻être pas une astuce pour l'imposer, mais une astuce pour facilité la maintenance…

                      Plutôt que de troller sans fin, il nous faudrait donc des preuves fortes comme quoi ces choix ne sont pas fait sur des critères techniques, mais grâce à des stratagèmes indignes de Lennart (payer des putes aux dev, menacer leurs familles de représailles, etc.).

                      Quand à l'argument inverse, je me base sur ceux qui font – les développeurs, mainteneurs de distributions – et qui font confiance à systemd, pour me dire que le choix a été fait suivant des contraintes techniques et non suivant des contraintes politiques.

                    • [^] # Re: Le thread dont vous éte le Mollah

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

                      Il n'essaie pas d'imposer Linux. Ce qu'il veut, c'est pouvoir tirer parti de fonctionnalités performantes, qui sont parfois spécifiques à Linux. Or, si tu dois faire un système qui est compatible avec tout le monde, tu dois te limiter au plus petit dénominateur commun. Tu perds donc soit en fonctionnalité, soit en vitesse. Mais le but même du bazar c'est d'être le plus rapide possible ! Pour faire un boulot efficace, il faut donc une version spécifique à chaque OS, et il ne veut pas s'amuser à les développer et les maintenir lui même, ce qui peut se comprendre.

                    • [^] # Re: Le thread dont vous éte le Mollah

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

                      Bon ok stop. Je te laisse lire un des post de base de Lennart :
                      http://0pointer.de/blog/projects/systemd.html
                      Ainsi que (cité dans un commentaire plus bas), celui d'un dev ArchLinux (qu'on peut pas vraiment accuser d'être à la solde de RedHat):
                      https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530

                      Les gros avantages tournent autour du fait que le design est plus adapté au monde moderne : Contrairement à init standard, systemd considère que tout peut être hotpluggé (pas besoin d'attendre que tout soit monté avant de fsck). Il permet de starter les services en parallèle sans utiliser de hacks comme c'est le cas actuellement. Il permet d'avoir un journal centralisé du stdout/stderr de tous les processus et de facilement trouver ce qu'un processus a loggé (via des metadata). J'en passe et des meilleurs.

                      Donc maintenant, si quelqu'un d'autre que Lennart propose des réponses (avec du code qui marche, pas au café du commerce) à ces problèmes, y'a probablement plein de distribs qui seront content de proposer l'alternative. Mais voilà, y'a personne qui ne le fait.

                      • [^] # Re: Le thread dont vous éte le Mollah

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

                        2) it is modular: all of what is now rc.sysinit is split out into many independent services, each of which is well documented and easy to understand. I.e., if you don't like how systemd e.g. does it's fstab handling, then you can write your own little helper (in bash if you wish) to replace the official one. Doing this in the old initscripts is much harder because 1) it is not so clear which parts of rc.sysinit are dependent on eachother 2) any changes you do you'll have to merge on every update.

                        J'aime bien cette partie qui fout à la poubelle les arguments de anti systemd qui pense qu'ils pourront plus contrôler leur système après alors que c'est tout l'inverse…

                        • [^] # Re: Le thread dont vous éte le Mollah

                          Posté par . Évalué à  6 .

                          Ah c'est modulaire ? Comment on enlève D-Bus de ce machin ? Et comment on enlève sa gestion des cgroups si j'ai pas envie d'activer cette option dans mon noyau ?

                          Quand on compare ça à un inittab ou on peut remplacer /etc/init.d/rc par ce que je veux, y compris par un machin utilisé par trois pélerin, ou un machin custom qui utilise des cgroups, c'est plutôt systemd le binaire monolithique.

                          Ah, on peut ne pas utiliser le machin systemd qui monte les partoches ? Ah on pouvait pas le faire avant avec sysvinit ? C'est bizarre ça, je me souviens l'avoir fait pourtant…

                          Pareil sur l'argument sur les dépendances: d'une part il y a les entêtes LSB (et insserv, qui est tout sauf un hack), et l'argument sur les changements à maintenir est aussi valable pour un systemd custom.

                          • [^] # Re: Le thread dont vous éte le Mollah

                            Posté par (page perso) . Évalué à  3 . Dernière modification : le 05/09/12 à 14:12

                            Quand on compare ça à un inittab ou on peut remplacer /etc/init.d/rc par ce que je veux

                            Tu rajoutes init=/bin/ton_init.sh dans les paramètres de ton noyau et cela fera ce que tu veux… Si t'as pas envie de dbus, je vois pas pourquoi t'aurais envie de udev donc y'a pas de problème… Ton Linux fonctionnera comme tu le veux.

                            • [^] # Re: Le thread dont vous éte le Mollah

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

                              Si t'as pas envie de dbus, je vois pas pourquoi t'aurais envie de udev donc y'a pas de problème…

                              Tu peux détailler s'il te plais ? A ce que je sache udev sert à créer les devices ce qui ne nécessite aucunement dbus.

                              • [^] # Re: Le thread dont vous éte le Mollah

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

                                Je précise que c'est une techno linux only qui n'est pas obligatoire pour démarrer comme dbus… Pourtant systemd dépend aussi de udev et cela n'a pas l'air de gener ;)

                      • [^] # Re: Le thread dont vous éte le Mollah

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

                        Donc maintenant, si quelqu'un d'autre que Lennart propose des réponses [ … ]

                        Et s'il n'y avait pas de questions ? Et si la raison d'être opposé à systemd est que le init traditionnel est la meilleure réponse à la problématique du démarrage ?

                        L'init sys V apporte toutes les réponses nécessaire à la majorité des cas, systemd est une optimisation pour un nombre de cas restraints : les serveurs n'ont pas besoin de systemd (les quelques secondes de gagnées ne valent pas la simplicité de corriger le démarrage s'il y a un problème), les portables et les ordinateurs de bureaux entrent et sortent de veille (ils démarrent une fois chaque mois), donc pas besoin de systemd.

                        Demander des changements aussi profonds aux systèmes pour un concept presque révolu, le démarrage, c'est la mauvaise réponse aux questions : comment améliorer la veille prolongée et comment faire que l'ordinateur passe par la séquence de démarrage que lors de la première utilisation ?

                        On ne doit pas améliorer le démarrage, on doit fournir :

                        • Mise à jour du noyau à chaud
                        • Support veille en RAM et veille sur disque fonctionnel (et synchro, lors de la veille en RAM, la veille sur disque doit être faite afin de prévenir en cas de perte d'alimentation)
                        • Vérification, réduction et agrandissement du système de fichier en ligne
                        • Ajout et suppression de composant matériel à chaud (y compris processeur et RAM)
                        • Migration d'un système automatique depuis un disque vers un autre

                        Si on arrive à ça, l'informatique aura avancé de manière très significative. Et on s'y approche, mon ordinateur de tous les jours démarrent une fois chaque deux mois mais c'est pas encore parfait.

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

                        • [^] # Re: Le thread dont vous éte le Mollah

                          Posté par . Évalué à  5 .

                          Et si la raison d'être opposé à systemd est que le init traditionnel est la meilleure réponse à la problématique du démarrage ?

                          Tu pars très mal avec ça. Dire qu'initsysv est une bonne solution, je comprends la meilleure ça me semble présomptueux. Il y a toujours possibilité d'améliorer un logiciel, ce serait bien triste sinon. Note que je ne dis pas que systemd est meilleur (j'en sais rien) juste qu'en informatique je n'ai pas encore trouvé de logiciel qui implémente « la meilleure solution » à un problème quelque soit ce problème.

                          Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                          • [^] # Re: Le thread dont vous éte le Mollah

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

                            Je ne dis pas que c'est la meilleure ou la moins bonne, je dis que ça pourrait être la meilleure solution. Qui sait, dans une infinité d'années, l'humanité, après avoir expérimenté, testé, mesuré une infinité de solutions pour le démarrage pourrait juger que l'init sys v, dans l'absolu, est la meilleure solution.

                            Là seule chose que je sais, c'est que systemd est un code n'ayant que deux ans et quand je vois, dans le code, autant de goto, de dizaine de return par fonction et de pointeurs non-initialisés à NULL, je me dis que systemd n'est pas prêt pour être en production.

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

                            • [^] # Re: Le thread dont vous éte le Mollah

                              Posté par . Évalué à  5 .

                              autant de goto, de dizaine de return par fonction et de pointeurs non-initialisés à NULL, je me dis que systemd n'est pas prêt pour être en production.

                              Ça ne veut pas dire grand chose sur la qualité du code. Il faudrai plutôt mesurer le bloat, la factorisation, la gestion des erreurs et le nombre d'erreurs que sort un analyseur de code statique ou dynamique.

                            • [^] # Re: Le thread dont vous éte le Mollah

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

                              autant de goto

                              Comme dans le noyau Linux

                              de dizaine de return par fonction

                              Comme dans le noyau Linux

                              de pointeurs non-initialisés à NULL

                              Mwai, ca ce discute, mais bon, quand tu fais:

                              Manager *m;
                              
                              assert(_m);
                              assert(running_as >= 0);
                              assert(running_as < _MANAGER_RUNNING_AS_MAX);
                              
                              if (!(m = new0(Manager, 1)))
                                              return -ENOMEM;
                              
                              

                              Ca n'a absolument aucun intérêt de l'initialisé à 0 quand tu fais l'init 3 lignes plus bas…

                              Mais bon, après, tout ce que tu dis, c'est ce qu'on m'a appris à l'école mais c'est un peu la guerre de clocher entre les devs system et les devs objets.

                              • [^] # Re: Le thread dont vous éte le Mollah

                                Posté par . Évalué à  3 .

                                Surtout que linux fait la guerre aux initialisations à zéro qui prennent au final une place dingue dans le binaire finale.

                                "La liberté de tout dire n'a d'ennemis que ceux qui veulent se réserver le droit de tout faire". "La question n'est pas de savoir si vous avez quelque chose à cacher. La question est de savoir si c'est nous qui contrôlons le gouvernement ou l'inverse

                                • [^] # Re: Le thread dont vous éte le Mollah

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

                                  Ça ne peut pas être optmisé par le compilateur ce genre de truc ? Genre si une assignation n'est lue dans aucun chemin d'exécution, on la vire.

                                  « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                                  • [^] # Re: Le thread dont vous éte le Mollah

                                    Posté par . Évalué à  1 .

                                    Le compilo ne peut pas forcément le voir à tout les coups.

                                    "La liberté de tout dire n'a d'ennemis que ceux qui veulent se réserver le droit de tout faire". "La question n'est pas de savoir si vous avez quelque chose à cacher. La question est de savoir si c'est nous qui contrôlons le gouvernement ou l'inverse

                                    • [^] # Re: Le thread dont vous éte le Mollah

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

                                      Qu'il y ait quelques cas, je veux bien croire mais que ça « prennent au final une place dingue dans le binaire finale » même avec des optimisations d'un compilateur, j'aimerais comprendre.

                                      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                                      • [^] # Re: Le thread dont vous éte le Mollah

                                        Posté par . Évalué à  2 .

                                        J'avais lu un article sur le sujet il y a bien longtemps sur kernelnewbies ou lwn, mais impossible de remettre la main dessus.

                                        J'imagine qu'ils incluent aussi les mise à zéro des structures allouées sur le tas, donc à travers de pointeur et donc les compilos ne font rien.

                                        "La liberté de tout dire n'a d'ennemis que ceux qui veulent se réserver le droit de tout faire". "La question n'est pas de savoir si vous avez quelque chose à cacher. La question est de savoir si c'est nous qui contrôlons le gouvernement ou l'inverse

                                • [^] # Re: Le thread dont vous éte le Mollah

                                  Posté par . Évalué à  2 .

                                  Est ce que c'est vraiment une histoire de place dans le binaire ou le fait que ça soit plus facile pour un analyseur statique de détecter des mauvais chemins ou on utilise une variable sans qu'elle soit initialisée à une valeur qui à du sens ?

                                • [^] # Re: Le thread dont vous éte le Mollah

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

                                  Soit on fait les init à zero et ça rale "le binaire est trop gros et bloated".
                                  Soit on le fait pas, et on rale "le binaire est mal écrit".

                                  Du coup, y a vraiment l'impression qu'écrire en C, c'est jamais possible de faire du code qui soit vu comme beau par les codeurs C.

                                  • [^] # Re: Le thread dont vous éte le Mollah

                                    Posté par . Évalué à  2 .

                                    Disons qu'il y a beaucoup de règles "à la con". L'initialisation à zéro permet de masquer des erreurs en injectant une valeur qui peut être bonne (à la limite je préfère 0xFFFFFFFF pour un entier). Je pense que l'on voulait parler de l'initialisation à null des pointeurs pour qu'un déférencement introduise directement une erreur de protection mémoire.

                                    J'imagine aussi que ce genre de règle devienne obsolète avec le temps, quand les compilateurs sont capables de détecter l'usage de variable non initialisé.

                                    "La liberté de tout dire n'a d'ennemis que ceux qui veulent se réserver le droit de tout faire". "La question n'est pas de savoir si vous avez quelque chose à cacher. La question est de savoir si c'est nous qui contrôlons le gouvernement ou l'inverse

                        • [^] # Re: Le thread dont vous éte le Mollah

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

                          les serveurs n'ont pas besoin de systemd

                          C'est vrai que le reprise d'un service sans coupure en cas de segfault d'un service, c'est pas du tout intéressant…

                          les portables et les ordinateurs de bureaux entrent et sortent de veille (ils démarrent
                          une fois chaque mois)

                          T'en connais beaucoup des gens toi qui n'éteignent pas leur pc et même leur portable ?

                          • [^] # Re: Le thread dont vous éte le Mollah

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

                            les serveurs n'ont pas besoin de systemd

                            C'est vrai que le reprise d'un service sans coupure en cas de segfault d'un service, c'est pas du tout intéressant…

                            Non, pas sans savoir pourquoi et comme le service est redondant, il n'y a pas de problèmes pour les utilisateurs.
                            Quand un truc s'arrête brutalement, je veux savoir pourquoi avant de le redémarrer (ne serait-ce que pour m'assurer qu'il ne va pas se comporter sauvagement quand il est redémarré).

                            T'en connais beaucoup des gens toi qui n'éteignent pas leur pc et même leur portable ?

                            Les utilisateurs Apple parce que la veille disque et RAM fonctionne à merveille. Moi parce que j'ai passé deux heures à bidouiller mon système pour que ça fonctionne presque à merveille.
                            Et pour les utilisateurs Windows, de plus en plus.

                            Par contre, les utilisateurs Linux sont toujours à éteindre/allumer leur machine parce que s'ils mettent en veille, et bien c'est plus long : le réveil met du temps avant de planter et devoir, finalement, redémarrer brutalement la machine.

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

                            • [^] # Re: Le thread dont vous éte le Mollah

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

                              Quand un truc s'arrête brutalement, je veux savoir pourquoi avant de le redémarrer

                              Tu travailles dans une MJC, c'est ça ?

                              De plus, si vraiment t'as un service non critique, ben tu dis à systemd de pas le redémarrer automatiquement.

                              • [^] # Re: Le thread dont vous éte le Mollah

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

                                Tu travailles dans une MJC, c'est ça ?

                                C'est quoi ça ?

                                De plus, si vraiment t'as un service non critique, ben tu dis à systemd de pas le redémarrer automatiquement.

                                Ou plutôt je surveille que les services critiques nécessitant un redémarrage immédiat avec un outil qui ne fait que ça et qui le fait bien.

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

                                • [^] # Re: Le thread dont vous éte le Mollah

                                  Posté par . Évalué à  7 .

                                  Sauf que systemd est idéalement placé pour se rendre compte que le service disparaît au moment où il disparaît. Idem s'il bloque. Il reçoit le sigchld, il contrôle le socket, bref, il est où il faut pour ça.

                                  Les services externes de monitoring (mon, monit, god et consorts) ne font que du polling, donc si tu vérifies tes services une fois toutes les 5 minutes tu cours le risque de rester avec un service down pendant 4:59 au pire des cas. Systemd peut réagir immédiatement.

                                  J'attends la sortie de wheezy justement pour pouvoir utiliser systemd sur des serveurs, justement pour avoir cette surveillance qui fonctionne bien mieux avec systemd qu'avec mon.

                        • [^] # Re: Le thread dont vous éte le Mollah

                          Posté par . Évalué à  2 .

                          le problème du temps de démarrage reste quand même présent, et c'est sympa de voir des gens qui s'en préoccupent au moins un minimum.

                          je sais pas vous, mais je suis en dualboot sur mon laptop essentiellement à cause de matériel non supporté sous linux et qui me sont nécessaire au boulot.
                          mettre en veille le pc (unix ou windows, hein) c'est pas top: faudrait déjà que ça marche avec unix. sous windows, c'est pas mal supporté.
                          ceci dit, mon portable mets presque le même temps pour démarrer à froid que pour revenir dans un état fonctionnel depuis une veille sur disque.

                          ensuite, quand tu veux monter tes partitions sur l'autre système histoire de passer des fichiers d'un système à l'autre: oups: filesystem non libéré, tu ne peux pas. obligé de passer par un reboot pur et simple.
                          et NON, la clé USB ou le disque externe n'est pas la pour palier à ce défaut.

                          enfin, je ne parles pas des mises a jour qui vont de facto te demander un reboot.

                          je vais pas rentrer dans le débat pour savoir si telle ou telle vision est la meilleure, mais en caricaturant exprès: pitié, c'est pas parce que vous êtes 4 avec des macbooks uniquement en veille prolongée que personne ne démarre jamais son ordi.

                        • [^] # Re: Le thread dont vous éte le Mollah

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

                          les serveurs n'ont pas besoin de systemd (les quelques secondes de gagnées ne valent pas
                          la simplicité de corriger le démarrage s'il y a un problème),

                          Je sais pas pour toi, mais moi, sur mes serveurs, pouvoir avoir un /tmp séparé par service ( directive privateTmp de systemd ), pouvoir retirer le réseau d'un daemon ( PrivateNetwork ), mettre une partie du FS en readonly voir le faire disparaitre , bref tout ce qui est mis ici : http://0pointer.de/blog/projects/security.html et le faire facilement avec 1 ligne, ça me parait pas mal. Libre à toi de croire ensuite que ton serveur ne va pas en tirer un bénéfice. résumer systemd a "ça boute plus vite", c'est faire preuve d'un sacré manque de curiosité.

                          Sinon :

                          Mise à jour du noyau à chaud

                          Y a ksplice. Grande nouvelle, c'est le merdier car tu dois connaitre la version exacte du noyau que tu as pour faire un patch qui va modifier les structures à la volée. Sinon, tu as le hurd qui propose ça via son architecture de micronoyau.

                          Support veille en RAM et veille sur disque fonctionnel

                          La veille en ram marche parfaitement sur mon portable lenovo, donc le souci est du coté du hardware,
                          pas du software.
                          Le suspend hybride existe aussi : http://daniel.hahler.de/use-hybrid-suspend-method-by-default
                          Ma suggestion est donc de mieux choisir ton matos.

                          Vérification, réduction et agrandissement du système de fichier en ligne

                          Resize2fs le fait depuis le kernel 2.6.14, sauf erreur de ma part.XFS le fait aussi depuis longtemps. Et lvm permet de retailler les partitions depuis toujours. Grub 2 propose le but sur une machine en lvm pur ( avec raid et chiffrement, etc ). Toutes les distros supportent lvm et ext2 ou plus. Donc faut juste que tu fasses l'installation comme il faut.

                          Ajout et suppression de composant matériel à chaud (y compris processeur et RAM)

                          Premier lien sur google pour le cpu hotplug :
                          http://www.cyberciti.biz/faq/debian-rhel-centos-redhat-suse-hotplug-cpu/
                          Si tu veux tester, il faut par contre du hardware qui le supporte, genre sans doute du hardware virtuel.

                          Pareil, memory hotplug, supporté par linux depuis des années :
                          http://www.kernel.org/doc/Documentation/memory-hotplug.txt

                          Je vais pas énumérer les composants, mais je sais que alsa supporte l'ajour de carte son ( et pulseaudio gére ça aussi dynamiquement, que ça soit un appareil genre apple airport, un écouteur bluetooth ou de l'usb ), qu'on peut rajouter des cartes réseaux de tout type, des periphs d'entrées de tout types, et qu'au final, c'est rarement coté soft que le souci se pose.

                          Donc si tu as besoin de rajouter des cpus à chaud, je te propose en effet de virtualiser plus. Ou d'acheter du matos qui supporte ( genre les serveurs haut de gammes IBMs s/390 etc )

                          Migration d'un système automatique depuis un disque vers un autre

                          Process par process, tu as des trucs genre cryopid

                          Pour l’intégration au kernel, il y a des efforts depuis des années :
                          http://lwn.net/Articles/478111/
                          http://lwn.net/Articles/375855/

                          Dragonfly bsd le propose aussi, d'ailleurs :
                          http://leaf.dragonflybsd.org/cgi/web-man?command=checkpoint&section=ANY

                          Et pour tout un systéme, tu as la migration de vm de qemu/kvm
                          http://www.linux-kvm.org/page/Migration

                          Donc installe juste tes machines comme noeud d'un cluster ovirt, archipel ou autre, et tu pourras migrer tes systémes. ( alors oui, y a un overhead mais on peut pas tout avoir )

                          Globalement, sur toutes les améliorations que tu demandes, toute sauf une sont déjà la. Certaines sont bloqués par d'autres choses genre le matériel ( non existant autre que dans une vm ou sans doute plus cher ) genre l'archi du truc ( le hurd étant pas réputé terrible niveau perf, ksplice étant ultra spécifique à chaque update ).

                      • [^] # Re: Le thread dont vous éte le Mollah

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

                        Donc maintenant, si quelqu'un d'autre que Lennart propose des réponses (avec du code qui marche, pas au café du commerce) à ces problèmes, y'a probablement plein de distribs qui seront content de proposer l'alternative. Mais voilà, y'a personne qui ne le fait.

                        Le système d'initialisation utilisé par NetBSD et FreeBSD permet tout ça, simplement, et à base de shell scripts.

                        • [^] # Re: Le thread dont vous éte le Mollah

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

                          Là, tu prends des risques en tant que BSDiste à venir t'immiscer dans un fil de discussion sur une fonctionnalité typiquement linuxienne !!
                          Ceci dit, je suis bien d'accord. De plus, les scripts shell qui sont dans /usr/local/etc/rc.d sont finalement assez simple.
                          Mais le problème n'est pas là !
                          <ironique>Le boot d'un FreeBSD reste très long et c'est d'ailleurs la raison pour laquelle il n'est pas prêt pour le Desktop</ironique>.

                  • [^] # Re: Le thread dont vous éte le Mollah

                    Posté par . Évalué à  1 .

                    Je n'ai pas posé la question dans le journal sur GCompris, mais si rien n'a changé, le créateur de GCompris vend une version non libre compilée pour windows de GCompris. Je suppose que c'est une telle version que les différentes communautés voulaient. Donc ils payent probablement pour.

                    Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

                • [^] # Re: la guerre de s unices

                  Posté par . Évalué à  7 .

                  Le type fait le logiciel comme il l'entend

                  Oui enfin bon, il bosse pour RH.

                  • [^] # Re: la guerre de s unices

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

                    Tiens, j'aimerais savoir: il m'a l'air d'avoir un sacré caractère ce monsieur, donc est-ce que RH lui dit ce qu'il doit coder, ou est-ce qu'il fait plutôt ce qu'il veut (et pense être bon) et est force de proposition chez RH ?

                    Par exemple, Linus a un contrat avec la Linux Foundation qui dit qu'il a le droit de faire ce qu'il veut. Donc il "bosse" pour eux, mais fait ce qu'il veut.

                    • [^] # Re: la guerre de s unices

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

                      Suffit de lui demander, il traine sur irc ( genre, freenode, nick mezcalero ), il a un compte google plus, un email ( voir plusieurs ). tu peux aussi le trouver à des confs IRL genre le FOSDEM.

                      Ceci dit, aussi loin que je me souvienne, il avait déjà le même caractère quand il était étudiant ( au vue de la page http://0pointer.de/lennart/projects/atitvout/ vu que j'avais ça sur mon portable de l'époque )

        • [^] # Re: la guerre de s unices

          Posté par . Évalué à  4 .

          Est-ce que cela n'aurait pas été plus simple de faire un yanobash (yet an other bash) qui serait simplement plus rapide à l'exécution ?

          "La liberté de tout dire n'a d'ennemis que ceux qui veulent se réserver le droit de tout faire". "La question n'est pas de savoir si vous avez quelque chose à cacher. La question est de savoir si c'est nous qui contrôlons le gouvernement ou l'inverse

          • [^] # Re: la guerre de s unices

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

            Déjà fait avec dash. Ça ne résout pas le problème des scripts shell plus ou moins bordéliques et surtout différents sur chaque distribution Linux !

            • [^] # Re: la guerre de s unices

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

              En même temps, c'est un problème que des gens ne veulent pas voir résolu, car ça impliquerais de collaborer au lieu de bosser dans son coin. Voir même, de renoncer à des trucs.

          • [^] # Re: la guerre de s unices

            Posté par . Évalué à  7 .

            Non, car le nombre de fork + exec ne diminuerait pas, le nombre de fichiers a acceder sur le systeme reste eleve, chaque unite de demarrage resterait complexe et dependante de la distribution. Au final, le shell restera toujours inefficace face a un programme qui fait toute l'init.

            Sans compter que, avec systemd, il est possible d'optimiser beaucoup de chose. On peut, par exemple, arriver a generer un cache compose d'un unique fichier decrivant tout le boot. En terme de performance et d'efficacite, par design, un programme comme systemd a un avantage impossible pour un script shell a atteindre.

            • [^] # Re: la guerre de s unices

              Posté par . Évalué à  3 .

              D'ailleurs est-ce que les fork/exec ne pourrait pas être plus rapide ?

              De plus, l'interpréteur connait une partie des programmes utilisé par le shell et pourrait les "précharger".

              "La liberté de tout dire n'a d'ennemis que ceux qui veulent se réserver le droit de tout faire". "La question n'est pas de savoir si vous avez quelque chose à cacher. La question est de savoir si c'est nous qui contrôlons le gouvernement ou l'inverse

              • [^] # Re: la guerre de s unices

                Posté par . Évalué à  2 .

                Difficilement et compare a la vitesse de l'equivalent windows, Linux est deja tres optimise. Le probleme principal, c'est que tu dois faire :
                - destruction des anciennes pages
                - chargement du nouveau programme
                - chargement des dependences
                - linkage
                - initialisation du programme et des dependences
                - execution
                - retour du resultat
                - nettoyage de la memoire

                Forcement, face a juste execution + retour du resultat, tu as zero chance d'y arriver meme avec la meilleur volonte du monde :-) Ensuite systemd amene aussi d'autres amelioration, comme des optimisations entre les differentes taches que tu ne peux pas faire en shell vu que chaque process est isole. Et ainsi de suite.

                • [^] # Re: la guerre de s unices

                  Posté par . Évalué à  -3 .

                  Mais la lenteur est effroyable :

                  $ time for i in {1..100}; do echo "plop" | wc | wc 2&> /dev/nul ; done
                  
                  real    0m5.539s
                  user    0m1.173s
                  sys     0m4.666s
                  
                  

                  La mise en place de wc pourrait être rapide. Le binaire des librairy est partagé en mémoire, pourquoi ne pas faire pareil pour le code des binaires ? On peut imaginer un préchargement dés le lancement de interpréteur de "echo" et "wc", comme le script est linéaire, les mêmes instances pourrait rester en mémoire, seul les données devraient être mises à zéro.

                  Ou alors, que l’interpréteur intègre un loadeur et utilise les binaires comme des plug-in, pour économiser les fork. Dans un script purement linéaire, cela devrait être la solution la plus rapide.

                  "La liberté de tout dire n'a d'ennemis que ceux qui veulent se réserver le droit de tout faire". "La question n'est pas de savoir si vous avez quelque chose à cacher. La question est de savoir si c'est nous qui contrôlons le gouvernement ou l'inverse

                  • [^] # Re: la guerre de s unices

                    Posté par . Évalué à  4 .

                    Mais la lenteur est effroyable :

                    Tu tournes sur un 286 DX ? Chez moi c’est 10 fois plus rapide que ça, et à la base l’idée que lancer 200 processus aussi simples que wc (echo est un built-in normalement) prenne plus d’une seconde est absolument délirant.

                    • [^] # Re: la guerre de s unices

                      Posté par . Évalué à  3 .

                      Son but étant de montrer le cout d'un fork
                      tu peux faire le test avec de 1 à 50 wc

                      ce qui est plus intéressant, c'est que chez moi ce n'est pas tant le temps passé dans le noyau qui coute, mais bien le temps en userland

                      time for i in {1..100}; do echo "plop" | wc   2&> /dev/null ; done
                      
                      real    0m0.208s
                      user    0m0.340s
                      sys     0m0.164s
                      
                      
                      time for i in {1..100}; do echo "plop" | wc  |wc |wc|wc |wc|wc |wc|wc  2&> /dev/null ; done
                      
                      real    0m0.478s
                      user    0m2.272s
                      sys     0m0.860s
                      
                      
                    • [^] # Re: la guerre de s unices

                      Posté par . Évalué à  -4 .

                      sur un cygwin en fait sur un core i5.

                      "La liberté de tout dire n'a d'ennemis que ceux qui veulent se réserver le droit de tout faire". "La question n'est pas de savoir si vous avez quelque chose à cacher. La question est de savoir si c'est nous qui contrôlons le gouvernement ou l'inverse

                  • [^] # Re: la guerre de s unices

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

                    pourquoi ne pas faire pareil pour le code des binaires

                    C'est déjà le cas sur tout OS digne de ce nom, sauf s'il autorise la modification du segment .text de tes programmes, évidemment!

                  • [^] # Re: la guerre de s unices

                    Posté par . Évalué à  1 .

                    Pourquoi je suis en négatif ? Il est interdit de publier un bench pour montrer que le shell est lent ?

                    "La liberté de tout dire n'a d'ennemis que ceux qui veulent se réserver le droit de tout faire". "La question n'est pas de savoir si vous avez quelque chose à cacher. La question est de savoir si c'est nous qui contrôlons le gouvernement ou l'inverse

                    • [^] # Re: la guerre de s unices

                      Posté par . Évalué à  3 .

                      tu as juste montré que cygwin est lent

                      • [^] # Re: la guerre de s unices

                        Posté par . Évalué à  2 .

                        C'est pas parce que le test sous linux est plus rapide que cela ne reste pas lent.

                        Au moment d'écrire le test, je n'avais qu'un cygwin sous la main, mais la lenteur reste pour linux aussi.

                        "La liberté de tout dire n'a d'ennemis que ceux qui veulent se réserver le droit de tout faire". "La question n'est pas de savoir si vous avez quelque chose à cacher. La question est de savoir si c'est nous qui contrôlons le gouvernement ou l'inverse

                        • [^] # Re: la guerre de s unices

                          Posté par . Évalué à  2 .

                          Personne ne nie que le shell est lent,
                          mais même mon rectificatif n'a aucun intérêt
                          il faudrait un point de référence, et voir si la partie shell en elle même engendre une surcharge importante et préjudiciable par rapport à une solution sans shell

                          • [^] # Re: la guerre de s unices

                            Posté par . Évalué à  2 .

                            A quoi cela servirait ? Mon but est juste de montrer que les shells sont lent. C'est tout. Ensuite, il y a un paquet de solution envisageable. Je ne cherchais pas de coupable.

                            "La liberté de tout dire n'a d'ennemis que ceux qui veulent se réserver le droit de tout faire". "La question n'est pas de savoir si vous avez quelque chose à cacher. La question est de savoir si c'est nous qui contrôlons le gouvernement ou l'inverse

                            • [^] # Re: la guerre de s unices

                              Posté par . Évalué à  2 .

                              Ok
                              je pense tout de même que ce bench n'est pas probant
                              on constate juste qu'avec un process qui ne fait pratiquement rien (wc), 1/3 du temps est passé dans le noyau
                              A prioris on aurait le même problème si tu faisais la même chose en C

                              • [^] # Re: la guerre de s unices

                                Posté par . Évalué à  2 .

                                Tu enfonces une porte ouverte là.

                                Mais j'inclue la gestion du fork() dans la vitesse du shell.

                                "La liberté de tout dire n'a d'ennemis que ceux qui veulent se réserver le droit de tout faire". "La question n'est pas de savoir si vous avez quelque chose à cacher. La question est de savoir si c'est nous qui contrôlons le gouvernement ou l'inverse

            • [^] # Re: la guerre de s unices

              Posté par . Évalué à  -7 .

              Marrant, tu parle d'efficacité mais sur tous les ordinateurs où j'ai pu tester systemd (opensuse ou fedora), j'ai eu le sentiment que le temps de boot avait augmenté. Pas terrible quand même pour un truc qu'on nous annonçait comme le messie des systèmes d'init.

              • [^] # Re: la guerre de s unices

                Posté par . Évalué à  10 .

                C'est la classe de faire des mesures de perfs sur des sentiments…

                Linuxfr, le portail francais du logiciel libre et du neo nazisme.

              • [^] # Re: la guerre de s unices

                Posté par (page perso) . Évalué à  2 . Dernière modification : le 05/09/12 à 12:06

                2 secondes sur mon laptop entre syslinux et kdm avec systemd, voilà mon sentiment…

                Après, il faut savoir ce que l'on test, en gros, si on installe systemd en mode compatibilité sysvinit, y'a peux de chance que ça aille plus vite… Mais c'est surement trop dur de lire une doc…

        • [^] # Re: la guerre de s unices

          Posté par . Évalué à  0 .

          Et si le script shell finit par mourir, c'est pas moi qui me plaindrais :) On a fait largement mieux depuis comme langage.
          
          

          Quel remplaçant proposes tu ?

          (j'inclus dans les scripts shell les langages de script comme le python etc … )

          • [^] # Re: la guerre de s unices

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

            (j'inclus dans les scripts shell les langages de script comme le python etc … )

            Pas moi. Python et Ruby ne peuvent plus vraiment être qualifiés de langages de script… Et quand bien même, dire que tous les langages de script sont équivalent au langage POSIX shell, c'est osé…

          • [^] # Re: la guerre de s unices

            Posté par . Évalué à  6 .

            Perso moi il m'arrive de faire des scripts système en php.

            (oui vous pouvez moinser).

            • [^] # Re: la guerre de s unices

              Posté par . Évalué à  5 .

              Beurk !

              Bien qu'étant pour la liberté de choix des langages et des méthodes en générales, beurk quand même.

              Mais bon si c'est toi qui maintiens …

              Qu'apporte systemd par rapport à l'ancienne méthode (rc.* /etc/init.d inittab et autres), quelqu'un peut me résumer les grandes lignes s'il vous plait, j'ai bien lu la première page et la page wikipedia mais comme l'arrêt et le reboot d'une machine sont des situations exceptionnelles ET que le systeme "classique" est facile a suivre et a peu près logique.

              Dans certain cas il vrai qu'optimiser le boot et le reboot est important :) (non je ne citerais pas de nom) mais dans d'autres il s'agit de script lancé qu'une ou 2 fois tout les 2 ou 3 ans alors même si c'est pas tip top au poil l'essentiel c'est que ca marche non ?

              Donc si quelqu'un pouvait me dire ce qu'apporte systemd, cela serait sympa

              Merci d'avance

              • [^] # Re: la guerre de s unices

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

                il s'agit de script lancé qu'une ou 2 fois tout les 2 ou 3 ans

                Sympa ta machine trouée

                Donc si quelqu'un pouvait me dire ce qu'apporte systemd, cela serait sympa

                Tu peux lire la page wikipedia avec comme condition de ne pas avoir de préjugés, et tu auras la réponse.
                Question inverse : pourquoi vouloir l'ancienne méthode que les mainteneurs de distro ne veulent plus si on l’utilise que 2 ou 3 fois par an? Ca fait beaucoup de réaction pour un truc peu utilisé…

                • [^] # Re: la guerre de s unices

                  Posté par . Évalué à  6 .

                  Question inverse : pourquoi vouloir l'ancienne méthode que les mainteneurs de distro ne veulent plus si on l’utilise que 2 ou 3 fois par an?

                  Tu veux dire : "Pourquoi ne pas rajouter à un OS tout un tas de fonctionnalité dont tu n'as pas besoin et dont tu ne te servirais que très rarement si tu les avais à disposition ?"

                  Ben écoute chacun fait comme il veut bien sur, mais personnellement les trucs dont je ne me sers pas je ne les installe pas. Il y a près de 15000 packages dans ma distrib, j'évite de les installer tous.

                  • [^] # Re: la guerre de s unices

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

                    Tu veux dire : "Pourquoi ne pas rajouter à un OS tout un tas de fonctionnalité dont tu n'as pas besoin et dont tu ne te servirais que très rarement si tu les avais à disposition ?"

                    La réponse est pourtant simple : parce que plus personne n'est intéressé à maintenir ta chose (je parie que le fork va être abandonné bientôt, car quasi tout le monde sera tourné vers systemd) car il y a mieux et plus maintenable (à commencer par du monde intéressé).

                    Encore une fois, si ça intéresse réellement des gens de passer son temps à maintenir la chose, vous pourrez encore utiliser la chose. Si. Super l'argument : bon les gars, il y a des gens qui veulent leur ancien truc juste parce qu'ils ont du mal à suivre le changement, mais attention, aucun n'est prêt à payer, on fait ce qu'ils ont envie ou on les laisse se faire plaisir dans la complainte des vieux n'aimant pas le changement? Ca a un nom : résistance au changement.

                    Il y a près de 15000 packages dans ma distrib, j'évite de les installer tous.

                    Quel est le rapport? Ici, tu remplaces un package par un autre, pas un de plus.

                    • [^] # Re: la guerre de s unices

                      Posté par . Évalué à  10 .

                      La réponse est pourtant simple : parce que plus personne n'est intéressé à maintenir ta chose

                      Dans le cadre d'un système d'init la question ne se pose pas. SystemV en lui même est très simple à maintenir, ce qui coute cher ce sont les scripts d'init. Mais à moins que Linux/systemd n'envoient tous les autres systèmes à la casse on aura toujours des scripts raisonnablement simple à adapter chez les *BSD pour toutes les applications phares.

                      C'est la puissance de SystemV : en quelques minutes je peux écrire un script de démarrage qui correspond exactement à mes besoins. Le seul problème qui va se poser c'est au niveau du démarrage des couches réseaux (ip, gre, pptp etc.) mais bon les scripts n'ont pas été réécrits pour le passage ifconfig -> iptables (il y a 16 ans, presque 14 ans qu'ifconfig est en deprecated) donc on peut légitimement se demander si ils vont l'être pour systemd.

                      bon les gars, il y a des gens qui veulent leur ancien truc juste parce qu'ils ont du mal à suivre le changement

                      Non, c'est juste que systemd est une mauvaise idée. Il s'agit ni plus ni moins que de la nième tentative pour normaliser Linux, on sait ce qui est arrivé aux précédentes et on a pas envie d'investir dans un truc qui va forcément se péter la gueule. (comprenons nous bien, par péter la gueule je veux aussi bien dire disparaitre que d'être obligé d'évoluer dans de telles proportion que d'ici trois ans les scripts systemd auront autant de ifdef et d’exceptions que les inits actuels).

                      • [^] # Re: la guerre de s unices

                        Posté par . Évalué à  0 .

                        mais bon les scripts n'ont pas été réécrits pour le passage ifconfig -> iptables (il y a 16 ans, presque 14 ans qu'ifconfig est en deprecated) donc on peut légitimement se demander si ils vont l'être pour systemd.

                        C'est pas iptables mais iproute

                        D'autre part au moins Redhat utilise iproute dans ces scripts network et probablement network-manager

                        • [^] # Re: la guerre de s unices

                          Posté par . Évalué à  -1 . Dernière modification : le 05/09/12 à 15:02

                          C'est pas iptables mais iproute

                          J'ai cru qu'il parlait d'ipchains au départ quand j'ai lu le post ^^

                          Par contre iproute j'ai pas sur ma debian… ip route ou ip addr par contre oui ;) ip addr est quand même plus proche de la sortie de ifconfig.

                        • [^] # Re: la guerre de s unices

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

                          En fait, c'est toujours pareil, tu dit "tel truc est déprécié", la plupart des gens font rien. Tu retires, ça crie de partout.

                          les scripts réseau de rh sont aussi ceux qui sont utilisés par les autres distros rpm-based, donc ça a migré également.

                          Les debians utilisent ifup, un executable, donc je suppose qu'il fait direct les appels aux ioctls ( comme NetworkManager, au passage ). j'ai trouvé encore des appels à la commande "route" ceci dit dans un script.

                          J'ai rien pigé au script de gentoo, donc je peux pas dire, mais je pense que ça a du être migré.

                          Au final, les distributions ont fait leur taf. Ce qui coince, c'est toujours pareil, c'est le reste du monde. Et qui doit faire le travail pour que d'autres puissent ne rien faire ? Les distributions… ( et souvent gratuitement, avec le sourire )

                      • [^] # Re: la guerre de s unices

                        Posté par . Évalué à  8 .

                        La difference majeur, c'est qu'une unite systemd peut etre fourni par le projet upstream et fonctionnera sur toutes les distribs. Ca veut dire moins de boulot dans la distrib, integration a terme plus rapide des nouveautes et teste plus large. Pour les mainteneurs, c'est un gain, pour les developpeurs, c'est un gain.

                        Non, c'est juste que systemd est une mauvaise idée.

                        Si c'etait une si mauvaise idee, pourquoi la majorite des gens qui font des distribs, developpe des plateformes ou developpe du soft sur Linux suivent le mouvement ? Ni upstart ni openrc n'ont reussi a gagner une tel attraction. Et ni Lennart ni Red Hat ne paye ces gens pour adopter systemd, ils le font parce que techniquement, c'est une meilleur solution que l'existent. Cela leur facilite la vie, leur permet d'avoir un systeme plus dynamique, plus maintenable et plus efficace…

                        Ensuite il y a un truc que tu n'as pas compris, Linux est base sur l'evolution. Tous les logiciels, les bibliotheques vivent et meurent au gres de l'apparition d'une concurrence plus efficace, d'une mainteneur plus motive and so on. Linux est un eco systeme ou les theorie Darwinnienne s'applique. Il n'y a rien de stable ad vitam eternam. Si la communaute dans sa majorite pense que d'aller dans une direction est mieux, c'est ce qui se passera.

                        Tu peux de maniere individuelle choisir de ne pas la suivre. C'est ton droit. Et tu peux le faire, tu as les sources. Mais il y a un prix a payer, le faire soi meme. A toi de choisir.

                        • [^] # Re: la guerre de s unices

                          Posté par . Évalué à  2 .

                          Si c'etait une si mauvaise idee, pourquoi la majorite des gens qui font des distribs, developpe des plateformes ou developpe du soft sur Linux suivent le mouvement ?

                          Parce que ça leur offre plein d'avantage, il manque c'est l'avis de l'utilisateur, ou surtout de l'admin
                          ce que je dis est un troll gratuit, je ne suis pas admin (ou que de mes serveurs perso), et je connais peu/pas systemd, et je dirai même qu'à titre perso j'y vois certains avantage
                          Mais j'imagine assez facilement les craintes d'un admin: un composant critique et bas niveau éffectuant énormément de taches et interagissant avec des composants haut niveau, à la place d'un ensemble de composant n'effectuant chacun qu'une seule tache.

                          • [^] # Re: la guerre de s unices

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

                            Parce que ça leur offre plein d'avantage, il manque c'est l'avis de l'utilisateur, ou surtout de l'admin

                            L'utilisateur ne voit absolument pas systemd (ou alors, on n'a pas la même notion d'utilisateurs…)
                            L'admin, qu'est-ce qui te fait dire que ce n'est pas mieux pour lui aussi? Et si "c'était mieux avant", ils ne verront aucun inconvénient à faire le boulot de maintenance ou à payer les mainteneurs pour faire le boulot pourri de maintenance de ces vieux trucs.

                            C'est fou comme on peut vouloir demander tout aux autres…

                            • [^] # Re: la guerre de s unices

                              Posté par . Évalué à  1 .

                              L'utilisateur ne voit absolument pas systemd (ou alors, on n'a pas la même notion d'utilisateurs…)

                              tu as raison, je pense même que ça apportera des plus à l'utilisateur lambda, ne serait ce que pour les futurs ihm qui controleront l'outil via dbus

                              L'admin, qu'est-ce qui te fait dire que ce n'est pas mieux pour lui aussi?

                              peut être, néanmoins je vois souvent les admins pestés contre les bloatware surtout pour tout ce qui est critique (et j'ai la prétention de croire que c'est le cas du système d'init, ainsi que de pas mal de features que systemd reprend a son compte)
                              on trouve dans systemd n'est plus qu'un système d'init, il prend en charge inetd, reprend a son compte une partie de ce que fait cron, fait du monitoring de process, etc… mais fait (actuellement) doublons avec d'autres process courrament utilisés

                              C'est fou comme on peut vouloir demander tout aux autres…

                              Pas plus que ce qu'on lui demande à lui même.
                              Faut arrêter ce genre de logique, le dev fait un taf, le mainteneur fait un taf, l'admin fait un taf, les 2 premiers sont sensé travaillés pour que le 3ème puisse faire son travail correctement (oui je sais, moi aussi j'ai fait des patchs qui ne servaient qu'à moi même)
                              l'admin on lui demande suffisament de choses pour qu'il ne se fasse pas chier à maintenir lui même des système que d'autres considèrent comme deprecated.
                              Mais en effet, si la solution ne lui convient pas, il passera sur autre chose

                              • [^] # Re: la guerre de s unices

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

                                Tu n'as pas répondu à la principale question : L'admin, qu'est-ce qui te fait dire que ce n'est pas mieux pour lui aussi?

                                PArce que la, ce que je vois, c'est que l'admin n'a plus à ce taper du script bash à la con (bash, c'est quand même dans les trucs les plus merdiques à débuguer) et qu'en plus, ses fichiers de config seront les mêmes sur toutes les distros qu'il a à gérer. Et ça, ça a une valeur… systemd est peut-être la pour répondre au problèmes de l'admin?

                                Rappel : systemd est sponsorisé par RedHat, dont le but est de vendre. Et il n'y a pas mieux pour vendre du Linux que de se mettre l'admin dans la poche, qui argumentera sur le gain de temps de la distro.
                                J'ai plutôt l'impression que les gens qui refusent le changement se braquent, mais que sinon systemd répond à un réel besoin de la part de tous les gens impliqués.

                                • [^] # Re: la guerre de s unices

                                  Posté par . Évalué à  4 .

                                  Si c'était la seconde partie:
                                  risque pour la stabilité, moins de souplesse dans les déploiement

                                  systemd est peut-être la pour répondre au problèmes de l'admin

                                  Bien sur, ça ne veut pas dire que cela y réponde
                                  mais ça y répond peut être très bien, je rebondissais juste qu'on n'ait pas placé l'admin dans la liste des gens ayant de bonne raison d'adopter systemd

                                  perso je ne suis pas admin, ceux que je connais ne sont pas fan, surtout pour le coté bloat et le risque pour la stabilité de leur système.

                                  en plus, ses fichiers de config seront les mêmes sur toutes les distros qu'il a à gérer

                                  Mouais, ou la minorité d'admin qui n'ont que linux en unix

                                  systemd est sponsorisé par RedHat, dont le but est de vendre. Et il n'y a pas mieux pour vendre du Linux que de se mettre l'admin dans la poche, qui argumentera sur le gain de temps de la distro.

                                  Mouais, et c'est grâce à l'admin que linux c'est développé.
                                  Néanmoins vendre et répondre au besoin ne vont pas nécessairement de paire, même si redhat est la mieu vendue je n'ai pas l'impression qu'elle fasse l’unanimité chez les admins (changement brutal de techno, support couteux, etc…)

                                  J'ai plutôt l'impression que les gens qui refusent le changement se braquent

                                  Si il y a une constante, c'est bien ça: beaucoup d'early adopters qui veulent tout changer tout de suite, et beaucoup de gens craintifs au changement.

                                  Néanmoins ici je vois des arguments intéressants , philosophiques (bloat, adoption trop rapide par les distros) et techniques (problème avec l'utilisation de partition chiffrés, vpn, dépendances, linux only, services en doublon )

                                  • [^] # Re: la guerre de s unices

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

                                    et techniques (problème avec l'utilisation de partition chiffrés, vpn, dépendances, linux only, services en doublon )

                                    Ces problèmes ne sont-ils pas simplement un manque de fonctionnalités dû à la jeunesse de la chose? Ca peut évoluer, comme tout nouveau logiciel qui fait bouger les choses. Si ont attend de répondre à tous les besoins avant de commencer à déployer, on ne déploie plus jamais rien et on meurt face à la compétition.
                                    Pour le "linux only", udev est linux only et ne pose pas de problème philosophique aux critiqueurs, donc ce n'est pas un argument.

                                    • [^] # Re: la guerre de s unices

                                      Posté par . Évalué à  5 .

                                      Ces problèmes ne sont-ils pas simplement un manque de fonctionnalités dû à la jeunesse de la chose?

                                      Certainement, mais actuellement c'est vu comme des régressions, d'où la critique sur l'adoption trop rapide par les distros

                                      Pour le "linux only", udev est linux only et ne pose pas de problème philosophique aux critiqueurs

                                      Mouais, j'ai entendu pas mal de critique sur udev aussi (mais bon on sortait de devfs, de hotplug et de je ne sais plus quoi d'autre, donc les critiques devaient être émoussées)
                                      de plus il est plus facile de se passé de udev que du système d'init.

                                      Mais bon je trolle je trolle, le peu que je connais de systemd me plait bien (ptet que je suis devenu un trolleur de haut niveau finalement), même si je lui reproche certaines choses (la non portabilité, le coté bloat, j'ai même lu qu'à terme ça voulait remplacer cron ! ). De toute façon quoique quelqu'un fasse (y compris ne rien faire) il y aura toujours des mécontents

                    • [^] # Re: la guerre de s unices

                      Posté par . Évalué à  7 .

                      les conseilleurs ne sont pas les payeurs. Tu n'utilises pas Linux, ça te sert à quoi de promouvoir systemd ?

                      parce que plus personne n'est intéressé à maintenir ta chose

                      si si, beaucoup de gens sont contre systemd, le risque que tout bloque en cas de problème de démarrage n'est pas négligeable. La conception est bizarre aussi (dépendance à Linux etc)

                      Déjà Debian ne va pas l'utiliser par défaut donc va sans doute continuer à maintenir "la chose". http://www.h-online.com/open/news/item/Debian-testing-a-systemd-to-sysvinit-converter-1670713.html

                      Gentoo ne va pas l'utiliser par défaut non plus : https://wiki.gentoo.org/wiki/Systemd

                      D'autres sont prêts à travailler sur divers fork si nécessaires :
                      http://bbs.archbang.org/viewtopic.php?pid=17877#p17877

                      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: la guerre de s unices

                        Posté par . Évalué à  3 .

                        Tu n'utilises pas Linux, ça te sert à quoi de promouvoir systemd ?

                        Il a déjà expliqué qu'il utilisait Linux. Pas sur son poste de travail mais ailleurs. Je suppose sur des serveurs/routeurs ?

                      • [^] # Re: la guerre de s unices

                        Posté par (page perso) . Évalué à  4 . Dernière modification : le 05/09/12 à 12:30

                        La conception est bizarre aussi (dépendance à Linux etc)

                        C'est sûr, c'est super étonnant qu'un système d'init cherche à tirer parti de toutes les fonctionnalités de l'OS plutôt que d'un sous-ensemble… =)

                        • [^] # Re: la guerre de s unices

                          Posté par . Évalué à  10 .

                          C’est quoi les fonctionnalités de Linux ? Celles activées dans le .config de Fedora ? de Debian ? dans un noyau compilé avec yes | make config ? Et quelle version de Linux ?

                          Parce qu’on a beau parler des BSD, faut pas oublier que le noyau lui-même peut ne pas avoir les cgroups d’activés par exemple. Et qu’on peut tout à fait utiliser un userland récent sur un noyau beaucoup moins récent. Ce genre de problématique, d’expérience, est assez courant sur les VPS, ce n’est pas juste du « et si » dans le vent. Dans ce cas, qu’est-ce qu’il va faire, systemd-je-veux-absolument-utiliser-toutes-les-dernières-fonctionnalités-de-linux ? Se vautrer lamentablement ?

                          • [^] # Re: la guerre de s unices

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

                            Il va pas démarrer, en effet. D'ailleurs, il y a eu des soucis avec lxc au début, car lxc utilise aussi les cgroups, et il y a eu clash sur l'usage en simultané des 2 ( souci corrigé depuis ).

                            Ceci dit, j'ai pour le moment vu personne se plaindre de ça à part toi, et bien que la remarque soit valable et génante pour ton usage, je pense qu'il y a donc un choix à faire sur ce que tu supportes en tant que distribution, et pour la plupart, l'usage en VPS est minoritaire AMHA.

                      • [^] # Re: la guerre de s unices

                        Posté par . Évalué à  4 .

                        beaucoup de gens sont contre systemd

                        Donc tout va bien. S'il y a tant de gens que ça, il y a en bien quelques-uns qui vont maintenir les autres solutions (dont le fork de udev).

                        Du coup, tu es parfaitement libre d'utiliser leur solution plutôt que systemd et autres, et tu peux laisser tranquilles ceux qui préfèrent systemd au lieu de tenter de les convaincre que ce qu'ils utilisent, c'est de la merde.

                        Je ne vois pas pourquoi on se prend la tête à ce point.

                        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                        • [^] # Re: la guerre de s unices

                          Posté par . Évalué à  3 .

                          Voilà, exactement. D'un côté on a Red Hat qui paie des gens (a priori pas mauvais techniquement) pour developper systemd, de l'autre on a un nombre indéterminé de gens (sans doute en majorité des admins plutôt que des devs), et c'est évident que maintenir l'init façon SysV ou BSD va se faire naturellement, en dehors de leurs heures de travail

                  • [^] # Re: la guerre de s unices

                    Posté par . Évalué à  0 .

                    +1
                    c'est pour cette raison que je demande si VRAIMENT cela vaut le coup systemd si cela apporte
                    le truc_de_la_mort_ki_tue sinon pourquoi changer une équipe qui gagne ?

                    bien souvent en informatique la DERNIERE version n'est qu'un truc marketting pour se faire remarquer ou pour faire du chiffre d'affaire donc sans interet.
                    Si ya une raison technique, du mieux du plus simple alors je ca m'interresse

                    A+

                    • [^] # Re: la guerre de s unices

                      Posté par . Évalué à  0 .

                      c'est pour cette raison que je demande si VRAIMENT cela vaut le coup systemd si cela apporte
                      le truc_de_la_mort_ki_tue sinon pourquoi changer une équipe qui gagne ?

                      Va demander aux mainteneurs des plus grosses distributions. Si elles y passent toutes progressivement, c'est qu'elles y trouvent un intérêt, même si nous utilisateurs ne voyons pas lequel.

                      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                      • [^] # Re: la guerre de s unices

                        Posté par . Évalué à  10 .

                        raisonnement dangereux.

                        Nos responsables politiques ont surement raison de privatiser les services publiques même si nous, utilisateurs, ne voyons pas lequel.
                        Le monde de la finance a surement raison de spéculer sur les matières premières même si nous, utilisateurs, …

                        • [^] # Re: la guerre de s unices

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

                          raisonnement dangereux.

                          Tout est une question de confiance. Manifestement tu n'as pas confiance en nos responsables politiques ni au monde de la finance.

                          En étant utilisateur d'archlinux j'ai confiance en ces développeurs qui m'ont toujours amené une entière satisfaction, lorsque systemd sera mis par défaut j'y passerai comme tout le monde.
                          Si pour une raison ou une autre je ne suis pas satisfait les développeurs perdront ma confiance et j'irai voir ailleurs.

                        • [^] # Re: la guerre de s unices

                          Posté par . Évalué à  4 .

                          Il y a une difference. Tu peux le faire toi meme. Il y a une doc, tu peux lire, apprendre, comprendre, verifier et agir.

                          La politique, c'est une autre histoire. Faut raconter aux gens ceux qu'ils veulent bien entendre sur le moment. Apres la realiter et les consequences ont peu d'importance.

                          Pour la finance, il y a clairement un manque d'information, de culture economique, scientifique et geostrategique importante qui fait que bon nombre de personne ne sont pas capable de comprendre ceux qu'on raconte. Entre autre chose, la speculation sur les matieres premieres a une influence minimal sur leur prix. A leur actuel, la principale raison de la monte du prix, c'est la rarefaction du petrole a bas cout…

                          • [^] # Re: la guerre de s unices

                            Posté par . Évalué à  3 .

                            Tu rigoles j'espère ? La politique, ça commence au niveau zéro, celui de l'engagement militant. Si un truc ne te plaît pas, et que tu ne participes pas d'une manière ou d'une autre pour contribuer à ce qu'elle change, tu es aussi coupable qu'un admin qui (au hasard) ne saurait pas faire plus que scripter (parce que bon, le dév système et la prog en C, ça fait 10-20 ans qu'il en fait plus…).

                            • [^] # Re: la guerre de s unices

                              Posté par . Évalué à  4 .

                              Non, je ne rigole pas. Les gens ne veulent pas entendre la realite. Ils ne veulent pas qu'on leur parle des contraintes du monde reel. Il faut leur vendre du reve et celui qui leur raconte les bobards les plus proches de leurs aspirations se fait elire. Le principe est de bien connaitre son electorat, savoir qu'elle partie de la population choyer pour maximiser ses votes et se faire elire. J'ai arrete de croire aux bisounours, il y a quelques annees deja !

                              Il n'y a rien a attendre de la politique, ni du gouvernement.

                      • [^] # Re: la guerre de s unices

                        Posté par . Évalué à  3 .

                        Va demander aux mainteneurs des plus grosses distributions. Si elles y passent toutes progressivement, c'est qu'elles y trouvent un intérêt

                        ouais, comme de juste, à part Mageia et Frugalware, les autres sont des distributions commerciales (ou des sous-marins de ces distributions, comme Fedora ou OpenSuse). Et vu que c'est red hat qui pousse la techno, c'est qu'elle doit y trouver un intérêt commercial, par exemple pour encourager à faire des logiciels qui ne tournent que sous Linux, dans un contexte précis, et pousser de plus en plus vers leurs services. À mon avis c'est guère plus compliqué que ça et tout le monde s'engouffre connement là dedans.

                        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: la guerre de s unices

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

                          Ou alors systemd répond à un besoin que sysvinit n'est pas capable de comblé…

                          Parce que bon, tu oublies quand même ArchLinux dans l'histoire, et tu le fais exprès en plus pour appuyer ton propos.

                        • [^] # Re: la guerre de s unices

                          Posté par . Évalué à  5 .

                          Wouah ! Une theorie du complot des distributions Linux commerciales ! Joli, j'avais pas encore rencontre une telle idee… Lennart, il aurait pas tue JFK ? Et ca serait pas ca soucoupe volante qui s'est crashe a Roswell ?

                        • [^] # Re: la guerre de s unices

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

                          Et arch aussi. Et tu noteras qu'il y a des distros commerciales comme Ubuntu qui n'ont pas suivi.

                          Donc on trouve grosso modo dans ceux qui proposent pas :
                          - Debian qui ne bascule pas car ils ont des raisons techniques ( kfreebsd, hurd )
                          - slackware et autres pour des questions de minimalisme
                          - gentoo qui le propose en option ( à la méthode gentoo )
                          - mint, parce que mint fait 0 devs sur la plateforme et fait juste de la repompe de ubuntu
                          - openembedded, pas de probléme avec hurd/kfreebsd, pas de souci de minimalisme => proposé en option comme gentoo

                          Du coté des autres distros à but commerciales, tu as :
                          - Ubuntu, qui le propose pas car ils ont leurs propres trucs, à savoir upstart ( upstart qui a été intégré dans RHEL et Fedora, mais personne ne va crier au complot dans ce cas la, car c'est juste quand un truc a du succès qu'il y a complot )

                          En gros, pour chaque distro qui propose pas, on trouve une raison de pas le faire.

                          Regardons maintenant les distros qui proposent :
                          - opensuse, mageia, fedora, mandriva, rosa => pas de souci techniques comme Debian ( ie linux only ), pas de souci de minimalisme comme lfs ( ie, udev, dbus sont déja la ), pas de système de boot maison aussi avancé comme Ubuntu

                          curieusement, aucune des raisons des autres ne s'appliquent. Donc la question est de savoir pourquoi est ce que :
                          - les distros n'ont pas décidé de faire leur truc
                          - les distros n'ont pas décidé de garder les anciens initscripts

                          Alors le 1, c'est simple, parce que ça coute des ressources. Et le 2, c'est simple, parce que personne n'a vraiment envie de s'occuper d'une grosse pile de trucs bash pour avoir en plus moins de fonctionnalités. Pour le moment, ça va, mais si dans 1 ou 2 ans, faut intégrer des nouveautés, ça devient vite galère.

                          Et peut être que l’intérêt est juste la, c'est de proposer un système qui correspond plus au besoin des mainteneurs ( genre, tu sais, les gens qui te file gratuitement leur boulot sous la forme d'une distribution ) et que c'est pour ça que les distros y passent ? Et parce que du coup, ça laisse du temps pour faire autre chose.

                          conclusion, on a une paire de distros qui n'ont pas de raisons de refuser un truc, pas envie de se taper le cout de maintenance du à une divergence, trouve des avantages à basculer et qui, du coup, bascule dessus.

                          C'est vraiment bien foutu ce complot

                          • [^] # Re: la guerre de s unices

                            Posté par . Évalué à  3 .

                            • Debian qui ne bascule pas car ils ont des raisons techniques ( kfreebsd, hurd )

                            Debian ne bascule pas, mais elle fournit tout de même systemd pour ceux qui veulent.

                            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                • [^] # Re: la guerre de s unices

                  Posté par . Évalué à  -1 .

                  Sympa ta machine trouée…

                  c'est quand même un poil abusé leur truc !!! Il n'y a pas tous les 3 jours un bug de sécurité impliquant un reboot du noyau !

                  • [^] # Re: la guerre de s unices

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

                    Il a parlé d'années, et si, c'est troué dans ce cas, que ça te plaise ou pas. Je n'ai jamais parlé de jours.
                    D'ailleurs, il y a une infographie sur le lien que j'ai mis, clique dessus…

              • [^] # Re: la guerre de s unices

                Posté par . Évalué à  3 .

                l'arrêt et le reboot d'une machine sont des situations exceptionnelles

                J'adore les affirmations autoritaires de ce genre… nan mais sans blague, personne n'utilise linux en dualboot peut-être ? personne n'eteint son Pc sans utiliser la veille ? sans compter que très souvent le boot par SSD est plus rapide que la sortie de veille sur disque. On est loin de situations exceptionnelles, bien au contraire.

                • [^] # Re: la guerre de s unices

                  Posté par . Évalué à  -1 .

                  Pardon, je précise dans le cas ou Unix et Linux sont utilisés comme serveur, ce pour quoi il est fait à l'origine, et d'ailleurs c'est pour les autres cas dual boot, portable etc … que je recherche des infos sur systemd.

            • [^] # Re: la guerre de s unices

              Posté par . Évalué à  4 .

              php, c'est déjà moisi dans le domaine pour lequel il a été conçu (le web), alors l'utiliser pour autre chose… Ça ne donne vraiment pas envie…

            • [^] # Re: la guerre de s unices

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

              Je faisais ça aussi ! Et puis j'ai découvert python !

              Faut dire qu'entre SH et Perl, on a envie d'autre chose. Mais avec le temps, la prog bash, ça rentre (mais ça ressort vite).

              • [^] # Re: la guerre de s unices

                Posté par . Évalué à  -2 .

                plus 2
                mais comme je le disais plus haut, le shell (ksh bash meme le bourne shell) ont encore de longues années d'avenir. car comme le papier et le crayon ils sont proche de la perfection dans leur usage courant.

              • [^] # Re: la guerre de s unices

                Posté par . Évalué à  4 .

                Laisse Perl tranquille ! Il t'a rien fait ! :-(

            • [^] # Re: la guerre de s unices

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

              Et tu n'as pas constaté que quand ton "script système php" se lance la CPU commence à fumer comme pas possible ?

              C'est ce qui m'a fait me tourner vers perl et dash…

              Fuse : j'en Use et Abuse !

              • [^] # Re: la guerre de s unices

                Posté par . Évalué à  5 .

                Non.

                D'une façon assez générale, je sais objectivement la raison pour laquelle php est un mauvais langage (voir là par exemple http://sametmax.com/deterer-le-cadavre-dun-troll-non-php-nest-pas-simple/ ), contrairement à beaucoup de gens agissant de façon mimétiques en disant php c'est de la merde sans en avoir la moindre idée de pourquoi mais ayant l'impression d'être aussi, voir plus, intelligent que les autres.

                Php me permet d'avoir une syntaxe simple, lisible, et une rapidité de déploiement non négligeable, je suis pas un développeur pro et la documentation très accessible du langage me permet de faire les choses proprement sans y passer des heures.

                Alors, objectivement, oui php est pas le meilleur langage du monde, sauf qu'en réalité, il est tout à fait fonctionnel tant qu'il ne s'agit pas d'écrire des applications extrêmement complexes et tout à fait maintenable car c'est un langage à la syntaxe simple et lisible.

                (et je terminerais avec encore un peu de psychologie inverse en disant une fois encore que vous pouvez moinser ce commentaire dans le but que vous fassiez exactement le contraire, bien évidement)

                • [^] # Re: la guerre de s unices

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

                  Hello,

                  On est un peu en dehors du débat, mais je tenais juste à te dire que je ne dénigre pas le php, j'ai fais mes premières armes dessus et continue de l'utiliser à outrance depuis plus de 12 ans pour tout ce qui est www !

                  J'ai pris sa défense il y a pas longtemps et j'ai appris, contrairement à ce que tu penses, que le php est en ascension pour tout ce qui est application lourde ! Pour diverses raisons : performance, rapidité d’apprentissage…etc..

                  Tes arguments _ que je rejoins _ sont pourtant à côté de la plaque par rapport à mon commentaire… J'utilise le langage de Rasmus, mais plus pour la partie administration système car #!/usr/bin/php est un shebang qui pèse sur la CPU !

                  NON => Si si ! Fait un traitement de plus d'une minutes en shell php, lance un top et constate…
                  Ce langage est fait pour le web, plus de 75% des serveurs web l'utilisent !
                  Mais faire avec son pear des scripts systèmes est un détournement qui n'est pas approprié.

                  Fuse : j'en Use et Abuse !

                  • [^] # Re: la guerre de s unices

                    Posté par . Évalué à  1 .

                    Désolé, mon commentaire regroupaient aussi des réponses aux autres commentaires de la même teneur qui étaient au dessus du tiens. Mon propos était un peu plus global.

                    Sinon, en ce qui concerne mon usage, ce n'est pas quelque chose que j'ai constaté. J'utilise le shebang /usr/bin/php aussi et ça n'a jamais posé problème en ce qui me concerne. Après les scripts que j'écrie en php sont rarement des daemons, donc ils ne s'exécutent jamais très longtemps.

        • [^] # Re: la guerre de s unices

          Posté par . Évalué à  10 .

          Et si le script shell finit par mourir, c'est pas moi qui me plaindrais :) On a fait largement mieux depuis comme langage.

          mmmm je ne crois pas au langage unique qui pourrait tout faire et surtout plaire a tout le monde, le scripts shell va mourir, comme le papier et le crayon … c'est annoncé depuis longtemps longtemps … mais c'est pas pour tout de suite :)

        • [^] # Re: la guerre de s unices

          Posté par . Évalué à  7 .

          On a fait largement mieux depuis comme langage.

          une phrase qui ne veut pas dire grand chose. "mieux" selon quels critères ?
          C'est sûr qu'il y a pleins de langages plus adaptés que le shell pour écrire des applications complexes, mais il y a aussi des cas d'usage pour lesquels je n'ai pour l'instant rien trouvé de "mieux" que le shell.

          L'analogie pourrie du jour: une perceuse est "mieux" qu'une chignole si on veut percer 10000 trous, mais uand on veut percer un pauvre trou dans une planchette, une chignole, c'est "mieux" qu'une perceuse.

      • [^] # Re: la guerre de s unices

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

        Lennart contre le reste du monde??? Son travail a l'air bien apprécié, ça semble partie pour toutes les distros majeures contre les petites… Pas sûr que Lennart ne gagne pas.

        • [^] # Re: la guerre de s unices

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

          Pas toutes les distros majeures, pas Debian en tous cas.

          • [^] # Re: la guerre de s unices

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

            Source ? Parce que systemd marche quand même plutôt pas mal sous Debian… Tu as une position officielle indiquant que ça ne passera jamais par défaut ?

            • [^] # Re: la guerre de s unices

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

              Déjà entendu parler de Debian GNU/kFreeBSD ?

              • [^] # Re: la guerre de s unices

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

                Ah oui tiens, j'avais pas pensé à ça… Mais ça veut forcément dire que le système d'init par défaut sur Debian GNU/kfreebsd et sur Debian GNU/Linux seront les mêmes ?

                Josselin Mouette disait justement que tous les paquets de Debian GNU/Linux ne marchaient pas sur Debian GNU/kfreebsd.

                • [^] # Re: la guerre de s unices

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

                  Il y a eu un summer of code pour résoudre le souci ( de la même façon que debian avait résolu le souci des menus avant la norme freedesktop ).

                  En gros, tu as un format de base ( genre le format .ini de systemd ), et tu peux générer un script d'init pour debian kfreebsd, pour le hurd, etc.

                  Ensuite, comme systemd utilise quand même des fonctionnalités difficiles à émuler partout ( genre les cgroups, l'intégration de selinux, le filtrage des appels systèmes des programmes lancés, le fait de lancer les applis dans un chroot avec montage particulier de certains répertoire ), je suis pas sur que ça puisse vraiment transposer tout dans un script shell, sauf à se retrouver avec un truc comme autoconf.

                  • [^] # Re: la guerre de s unices

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

                    Certes, ça pourrait vite devenir très compliqué. D'un autre côté, le problème principal, ce serait un mainteneur Debian qui écrit la config pour systemd et ne fournit plus de script shell.

                    Combien de paquets ont des besoins particuliers (au-delà de start/stop/etc. classiques), et quelle charge de travail supplémentaire pour maintenir les script pour les deux systèmes d'init sur ces paquets?

                    (En fait, si j'ai bien compris, même sous systemd, quand on a des besoins spécifiques, l'idée est de retomber sur un script shell au lieu du fichier de config systemd, j'ai bon?)

                    Dans le pire des cas, la solution "générique" simple couvrirait déjà la plupart des besoins.

                    • [^] # Re: la guerre de s unices

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

                      Tu appelles quoi "besoin particulier" ?

                      À vue de nez je pense que tu veux dire 2 trucs :

                      1) les services avec des actions en plus ( genre, postgresql, dump de la db via le script d'init ).
                      C'est une chose qui fait pas stricto sensu parti du script d'init. En général, ça a été mis dedans parce le script d'init a besoin de la config du daemon, et sans doute pour des questions d'ergonomie et d'affordance ( ie, pour le modèle mentale de l'utilisateur, le script est la porte d'entrée sur la manipulation du daemon, un dump de la db est une manip de ce genre donc on rajoute la fonction )

                      Avec systemd, tu doit faire un script à part ( vu que tu peux pu intégrer ça dans le script principal ). Il y a un emplacement spécifique quand tu utilise ça avec service pour garder l'intégration ( genre service pgsql dump va appeler /XXX/pgsql/dump ). La différence entre "j'écris du code que je mets avec un case en plus dans un script" et "j'écris du code que je mets dans un fichier à un endroit spécifique" est pas flagrante. En fait, tu peux juste garder ton script d'init qui fait appel à ton 2eme script.

                      2) les services qui ne sont pas des daemons classiques. Exemple, tu as un truc à lancer au démarrage, mais c'est pas vraiment un daemon, c'est juste la configuration de l'affichage sur un ecran lcd 4" du nom de la machine ( le seul exemple que j'ai trouvé qui ne soit pas géré autrement ). En gros, tu doit lancer une paire de commande pour charger le matos, et lancer ce que tu veux écrire. Ben ça, oui, tu peux lancer un script shell, ou un programme en C. Ou tu peux lancer les commandes à la suite dans le fichier systemd, avec plusieurs lignes Execstart, en précisant "c'est normal si il reste aucun process à la fin" et "ne fait pas de tracking de PID". IE pour les actions spécifiques, rien n'empeche de faire encore du shell. Après tout, si le but est de lancer des softs, personne ne va vérifier si le soft est en C, en python, en perl, en bash ou autre. Donc pareil, si tu codes bien, tu as fichier que tu appelles depuis un script classiques ou systemd.

                      Maintenant, en pratique, j'ai du mal à voir ce qui requiert des dizaines de commandes spécifiques au boot, à part le réseau et perso, je pense que ça peut sans doute être mieux intégré et de plus haut niveau que sous la forme d'un script shell.

                      Mais du coup, est ce que tu penses à autre choses pour "besoins non spécifiques" ?

                      • [^] # Re: la guerre de s unices

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

                        C'est le genre de trucs qui vient en tête. Après, je ne prétends pas connaître tous les cas de figure et tous les scripts de tous les paquets qui ont un script init. C'est pour ça que je demande: dans le pire des cas, combien de scripts à "porter" de l'un à l'autre.
                        Comme tu dis, en plus d'une quantité limitée de scripts, le gros du boulot resterait commun.

          • [^] # Re: la guerre de s unices

            Posté par (page perso) . Évalué à  1 . Dernière modification : le 05/09/12 à 10:55

            pas Debian en tous cas.

            Pourtant, systemd est bien dans Debian (Testing et +) : http://packages.debian.org/search?keywords=systemd&searchon=names&suite=all&section=all&sourceid=mozilla-search

            Il n'est pas présent par défaut, mais est instable :

            # aptitude install systemd
            Les NOUVEAUX paquets suivants vont être installés : 
              libpam-systemd{a} libsystemd-id128-0{a} libsystemd-journal0{a} systemd 
            **Les paquets suivants seront ENLEVÉS : 
              klogd{a} sysklogd{a}**
            0 paquets mis à jour, 4 nouvellement installés, 2 à enlever et 0 non mis à jour.
            Il est nécessaire de télécharger 1 558 ko d'archives. Après dépaquetage, 3 774 ko seront utilisés.
            
            

            Je ne suis cependant pas assez joueur pour avoir testé sur ma machine principale… :)

            • [^] # Re: la guerre de s unices

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

              Il faut installer systemd-sysv aussi je crois, sinon c'est toujours sysvinit qui fonctionne. Pour ma part je suis joueur :)

              • [^] # Re: la guerre de s unices

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

                En fait non, c'est pas indispensable, tu peux activer systemd sans systemd-sysv avec une option à passer dans grub.

                Installer systemd-sysv, c'est pour ceux qui ne veulent pas revenir en arrière.

                Pour ma part, je suis juste assez joueur pour avoir l'option dans grub et bien tester avant de sauter le pas définitivement.

            • [^] # Re: la guerre de s unices

              Posté par . Évalué à  10 .

              Systemd est dans Debian, et alors ?
              Upstart aussi l'est, tout comme file-rc (encore un truc zarbe utilisé par trois pélerins…)

              Tu viens juste de prouver que Debian est une distribution qui laisse le choix du système d'init à utiliser. Ça tombe bien, c'est pour ça que je l'aime.

        • [^] # Re: la guerre de s unices

          Posté par . Évalué à  4 .

          Le problème n'est pas tant dans son travail que dans la méthode et la communication.

          • [^] # Re: la guerre de s unices

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

            Personnellement, je préfère une forte gueule qui se bouge le cul et qui fait évoluer l'éco-système Linux (et virer ces script d'init, c'est une belle évolution) que des gens "gentils" qui laissent la situation pourrir au point de ne plus être compétitif. Bon, après, il y a pire : les forte gueules qui râlent sur les évolutions sans se bouger le cul :-D.

            • [^] # Re: la guerre de s unices

              Posté par . Évalué à  4 .

              Personnellement, je préfère une forte gueule qui se bouge le cul et qui fait évoluer l'éco-système Linux (et virer ces script d'init, c'est une belle évolution)

              C'est une évolution. Belle, pas sur, dans le bon sens, non plus. Perso je prefere un systeme peu performant (au sens vitesse d'execution) mais facile à comprendre et maintenir qu'un truc plus performant auquel je ne comprend rien. Et je n'ai pas envie de passer 10 heures à apprendre un nouveau systeme qui me ferait gagner 30 secondes à chaque reboot, si je ne reboot mon serveur que quelques fois par an… C'est pas rentable.

              (…) que des gens "gentils" qui laissent la situation pourrir au point de ne plus être compétitif.

              Prouve le. En quoi la situation était en train de pourrir ? J'ai pas remarqué ce pourissement, perso. Pareil, le coup de plus être compétitif : par rapport à quoi ? Tu crois vraiment que sur un serveur, le temps de boot est un critère de compétitivité pour un OS ?

              Bon, après, il y a pire : les forte gueules qui râlent sur les évolutions sans se bouger le cul :-D.

              Il y a ENCORE pire : les fortes gueules qui gueulent sur les fortes gueules qui ralent sur les evolutions qui les emmerdent.

              • [^] # Re: la guerre de s unices

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

                10 heures à apprendre un nouveau systeme qui me ferait gagner 30 secondes à chaque reboot,
                si je ne reboot mon serveur que quelques fois par an

                Si tu pouvais passer 10 minutes à comprendre ce que fait systemd plutot que de montrer que tu n'en sais rien… Si systemd avait été créer pour gagné 30 seconde au boot, alors upstart suffisait…

            • [^] # Re: la guerre de s unices

              Posté par . Évalué à  7 .

              Moi ce que j'aime c'est les « gentils » qui préfèrent bosser et communiquer de manière posée plutôt que de lancer un flameware à chaque fois qu'ils ouvrent leur MUA. Si si il y en a pleins. Même Shuttleworth s'est calmé et a arrêté d'être aussi gamin. Les grands noms (Torvalds, RMS, De Raadt, etc) le font rarement. Il n'y a guère que chez RedHat et gnome qu'ils n'ont pas compris que la communication peut se faire autrement.

              Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

    • [^] # Re: la guerre de s unices

      Posté par . Évalué à  10 .

      Il y a aussi eu la guerre des navigateurs, sans laquelle on utiliserait tous IE, la guerre des BSD, qui a donné naissance à OpenBSD ou DragonFly, la guerre des compilateurs qui a donné naissance à EGCS puis GCC 3, la guerre des FAI, la guerre des forfaits de téléphone portable, etc. Que du mal ;-)

      • [^] # Re: la guerre de s unices

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

        Bah c'est ce qu'il dit: les Unix proprio ont été détruits, c'est une bonne chose non ?

        Comment ça j'ai mal compris ?

    • [^] # Re: la guerre de s unices

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

      Avant, rien n'était compatible, chaque distro avait son système d'init, son système de paquet, sa version de chaque composant, donc son abi.

      maintenant c'est pareil.

      C'est moi ou d'une part, les gens cherchent du sang et du drame la ou il y en a pas, et les gens ont la mémoire aussi courte que le slip d'un stripteaser dans un casino de las vegas ?

      • [^] # Re: la guerre de s unices

        Posté par . Évalué à  5 .

        Justement, Systemd cherche à unifier le système de démarrage en supprimant notamment les scripts de lancement qui sont toujours propres à chaque distribution… donc on va plutôt dans la bonne direction.

        • [^] # Re: la guerre de s unices

          Posté par . Évalué à  6 .

          Ou plutôt dans la mauvaise. Si ces scripts étaient spécifiques, c'est qu'il y avait peut-être une raison. Raison qui n'est peut-être valable que dans certains cas, mais c'est largement suffisent.

          Moi je n'ai pas envie d'installer D-Bus sur un serveur à moitié embarqué juste pour pouvoir admirer la rapidité du boot.

          • [^] # Re: la guerre de s unices

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

            Moi je n'ai pas envie d'installer D-Bus sur un serveur à moitié embarqué juste pour pouvoir admirer la rapidité du boot.

            Et pourquoi pas? C'est si horrible que ça?
            Pourquoi ce principe sur D-Bus et pas sur tous les autres composants qui seraient tout autant "inutiles" sur ta machine? Ca bouffe 1 Go de RAM?

            C'est juste un dogme sur lequel s'arc-bouter…

            • [^] # Re: la guerre de s unices

              Posté par . Évalué à  10 .

              Et pourquoi pas? C'est si horrible que ça?

              Oui.
              Déjà il y a des dépendances dans tous les sens, ça ne peut être piloté correctement que via DBus (donc pour le debug il va falloir créer un client DBus avec des droits démentiels et des cgroups transversaux), c'est fortement incompatible avec pas mal de méthodes de chiffrement de la partition de boot (grosso-modo tous sauf luks), ca monopolise des ressources mémoires (les cgroups c'est loin d'être gratuit, surtout en embarqué) etc.

              Mais surtout :
              - C'est fait par Red Hat, les experts en "on laisse tomber la fonctionnalité phare de la version précédente". Si vous avez investi dans les technos de virtualisation à la sauce Red Hat, vous savez de quoi je parle.

              • Il faut réécrire profondément les scripts d'init pour en tirer partie. Certes on peut créer assez rapidement des scripts qui fonctionnent du moment que l'on force une exécution séquentielle (c'est d'ailleurs ce que font pas mal de distribs en ce moment) mais pour que systemd apporte quelque chose il faut repenser l'init. Quand on voit qu'en près de 14 ans de déprécation les scripts utilisant ifconfig n'ont pas tous été réécrit et que iwconfig n'est toujours pas complètement intégré à au set d'outils iproute2 …

              • Vu la gueule de la stabilité API des linuxeries du passé (HAL, DBus, SELinux etc.) je n'investirais pas de temps à apprendre systemd. Et quand je n'aurais pas le choix (tous les linux avec systemd) je créerai un script bien gruik dans un cgroup absolu (tous les pouvoirs) qui lancera un bon vieux script shell en mode séquentiel. Bref il y aura un script init2 sur ma machine sur lequel je pourrais intervenir en mode texte avec pour toute arme une console et un vi.
                Mais bon le truc c'est que ce qu'il y a de plus chiant dans Linux (bien plus que de gérer les dépendances et de faire un système de packages cohérent) c'est de faire des scripts d'init. C'est probablement la seule raison pour laquelle j'utilise une distrib toute faite et pas un LFS ultra customisé. Donc la perspective de devoir tous les réécrire et les maintenir pendant les deux ou trois ans que va mettre systemd à crever ne m'enchante pas.

              • [^] # Re: la guerre de s unices

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

                Donc la perspective de devoir tous les réécrire et les maintenir pendant les deux ou trois
                ans que va mettre systemd à crever ne m'enchante pas.

                L'espoir fait vivre hein, bon courage :p

                • [^] # Re: la guerre de s unices

                  Posté par . Évalué à  4 .

                  L'espoir fait vivre hein, bon courage :p

                  Si encore c'était un espoir. Mais je connais déjà un gros client RH qui utilise massivement oracle avec des scripts d'init custom pas piqué des hannetons. Et là ils sont en train de bomberder le support RH de questions pour être iso fonctionnel en systemd.
                  Je ne pense pas un seul instant que RH va accepter de perdre ce client (même si 5 ans de support c'est long, tu peux être sur qu'à la première version d'Oracle qui n'est plus certifié sur le RH qu'ils utilisent ils changent de crêmerie).

                  Donc comme RH veut garder ce client (et rpobablement d'autres avec des problematiques similaires) je suis prêt à parier qu'ils vont mettre des gruikeries dans leur systemd… Et de là c'est juste une question de patience.

                  • [^] # Re: la guerre de s unices

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

                    Pfff, ca devient insupportable les mecs qui parlent de systemd sans savoir de quoi ils parlent…

                    Ca doit prendre 2 minutes de faire une "unit" systemd qui lance des scripts shell comme le faisait sysvinit…

                    Mais bon, c'est tellement plus simple d'utiliser la bonne vielle technique du Fear, uncertainty and doubt.

                    • [^] # Re: la guerre de s unices

                      Posté par . Évalué à  1 .

                      Ca doit prendre 2 minutes de faire une "unit" systemd qui lance des scripts shell comme le faisait sysvinit

                      Et qui va créer 32 watcher si tu utilise apache en mode démon+fast cgi avec 32 spawn, et comme mentionné dans un autre post on va être gentil et pas parler d'Erlang ou des programmes qui utilisent du GPGCU.
                      La seule bonne façon d'utiliser systemd c'est d'avoir des démons et des outils de controle (type apachectl) qui parlent courament le DBus.
                      Et je veux pas de DBus dans mon apache, je ne veux pas de watcher, je veux des perfs maximale parceque j'ai des centaines de milliers de connexion par minute et que le roundtrip DBus est loin d'être gratuit.

                      Donc non, pour des programmes aussi marginaux que apache, mysql, postfix, JBoss, Oracle etc. il va falloir rajouter des trucs dedans pour que ca marche intelligemment avec systemd, des trucs qui vont géner les perfs et dont moi, personellement, je n'ai rien à foutre.

                      • [^] # Re: la guerre de s unices

                        Posté par (page perso) . Évalué à  3 . Dernière modification : le 06/09/12 à 00:46

                        La seule bonne façon d'utiliser systemd c'est d'avoir des démons et des outils de controle
                        (type apachectl) qui parlent courament le DBus.

                        Faux, surtout que apachectl, c'est l'exemple type de l'outils codé parce que sysvinit ne répondait pas aux besoins… T'inquiètes, si systemd devient vraiment le standard, ton apachectl, il va partir dans /dev/null

                        Et je le redis: systemd n'a pas besoin de dbus pour fonctionner et pour controller les services

                        • [^] # Re: la guerre de s unices

                          Posté par . Évalué à  2 .

                          Faux, surtout que apachectl, c'est l'exemple type de l'outils codé parce que sysvinit ne répondait pas aux besoins…
                          On passe sur la logique tarabiscotté (il est faux de dire que A a besoin de B pour fonctionner avec C vu que A a été créé à cause de D)
                          Ensuite tu penses sincèrement que toutes les options de apachectl seront codées dans un init un jour, notamment les options des modules compilés statiquement dans apache ? Parce que apachectl fait ça aussi.

                          T'inquiètes, si systemd devient vraiment le standard, ton apachectl, il va partir dans /dev/null

                          Clairement, si systemd devient le standard, apache laisse tomber windows, Mac et *BSD.

                          Et je le redis: systemd n'a pas besoin de dbus pour fonctionner et pour controller les services

                          CF mon autre post dans l'autre thread pour cette question, systemd est aveugle et sourd sans DBus. (ce qui ne l'empêche pas de lancer des services d'accord, mais pour le contrôle on repassera)

                          • [^] # Re: la guerre de s unices

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

                            CF mon autre post dans l'autre thread pour cette question, systemd est aveugle et sourd
                            sans DBus. (ce qui ne l'empêche pas de lancer des services d'accord, mais pour le contrôle
                            on repassera)

                            Ce qui est faux, comme je te le démontre dans l'autre journal, il fonctionne très bien sans dbus.

                  • [^] # Re: la guerre de s unices

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

                    En fait, le support est passé à 10 ans, comme indiqué sur Linuxfr :
                    https://linuxfr.org/news/le-support-de-redhat-enterprise-linux-passe-a-10-ans

                    D'autre part, RHEL 6 tourne avec upstart, et visiblement, ça n'a pas l'air de déranger grand monde ( vu que personne n'en parle et j'ai pas entendu de grand cri ), et le support de sysV par systemd est au même niveau que celui d'upstart ( ie, ça se lance directement les scripts de /etc/init.d )

                    Enfin, sachant que oracle avait déjà décidé de prendre son temps pour la certif de RHEL 6 ( http://blog.vishalgupta.com/2011/09/19/oracle-11gr2-on-rhel6/ ), donc j'ai l'impression qu'une version d'oracle non supporté sur RHEL est un événement déjà arrivé.

                    Moi, quand je relit ton histoire, je vois juste un client qui collabore avec son fournisseur sur un produit pas encore sorti, et ça me semble relativement positif comme façon de faire. Et à te lire, tu en reviendrais presque à le regretter, voir à imaginer des luttes de pouvoir qui n'existent pas. On pourrais même croire que tu sous entends que RH ne va pas pousser les bugfixes upstream, ou qu'il y a pas moyen de supporter proprement les scripts shell avec autre chose que sysV ( voir même que tes scripts magiques feraient des trucs si magiques que ça marcherais pas )

                    Tu serais pas un peu aigri et totalement subjectif ?

                    • [^] # Re: la guerre de s unices

                      Posté par . Évalué à  6 .

                      donc j'ai l'impression qu'une version d'oracle non supporté sur RHEL est un événement déjà arrivé.

                      Ne pas confondre pas encore supporté et non supporté. Je reviens dessus dans un instant.

                      Moi, quand je relit ton histoire, je vois juste un client qui collabore avec son fournisseur sur un produit pas encore sorti, et ça me semble relativement positif comme façon de faire.

                      C'est très positif comme façon de faire. Il faut bien voir que les scripts d'init custom sont une plaie à maintenir, et que c'est la partie sur laquelle il est le plus complexe d'obtenir du support. Donc forcément il vaut mieux s'y prendre à l'avance. Le truc est que l'on peut lancer des scripts shells standard avec systemd mais que ça coince quand même à pas mal de niveaux.
                      Par exemple systemd essaye de suivre le double fork de la daemonisation comme il peut, parceque le plus souvent le processus qui est lancé immédiatement n'est pas le processus définitif. Au bout d'un temps X (qui dépend de tout un tas de paramètres y compris l'age du capitaine et les exceptions codées en dur) il va choisir un ou plusieurs processus à surveiller comme étant "le(s) bon(s)" processus.

                      Dans le cas d'un cluster qui peut mettre un certain temps à se synchroniser avant de démarrer (des fois plusieurs minutes, rarement quelques heures) le bon processus est lancé très tard et le processus daemonisé en premier qui ne fait que la synchro s'arrête. systemd n'aime pas du tout ce comportement, et on a pas de moyen simple de lui envoyer un message pour dire "tout va bien c'est XXXX le vrai processus".

                      Il existe des méthodes de contournement (on peut passer certaines infos d'un processus à un autre en systemd) mais ca fait des scripts complexes avec des exceptions, des tests et des cas aux limites un peu douteux.

                      Tu serais pas un peu aigri et totalement subjectif ?

                      Si bien sur pourquoi ? Mais pour autant la question à se poser est de savoir si j'ai tort ou pas…

                      • [^] # Re: la guerre de s unices

                        Posté par . Évalué à  2 .

                        Ne pas confondre pas encore supporté et non supporté. Je reviens dessus dans un instant.

                        Je suis pas revenu dessus.
                        Une des conditions pour la certif Oracle est de pouvoir faire monter les disque dur en raw directement par l'appli Oracle. Apparament (je ne suis pas complètement dans le secret des dieux) ca peut poser des problèmes avec systemd.
                        Le problème sera très certainement résolu bientôt, mais la question est de savoir comment.

                        Mon pari (et la c'est personnel et je l'admet un peu trollesque) est que pour faire face à tout un tas de situation (dont celle mentionnée plus haut) systemd va devoir se rapprocher progressivement d'un shell complet (voire d'un mini OS vu le nombre d'outils qui lui sont rajoutés chaque mois).

                        Red Hat ne peut pas se permettre d'essuyer un refus de certification de la part d'Oracle, donc si systemd bloque systemd sera poussé à évoluer, et ca le met dans une situation désagréable (un système d'init qui s'adapte à un programme userland c'est pas forcément glop).

                      • [^] # Re: la guerre de s unices

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

                        Sincèrement, j'apprécierais d'avoir une discussion ou je suis pas obligé de sans arrêt sortir la documentation pour dire "voila comment faire tel chose" pour dire que la personne avec qui je discute qu'elle semble être dans le faux.

                        En l’occurrence, dans le cas que tu donnes, c'est prévu, tu peux désactiver le fait de trouver le pid via GuessMainPid=no, et juste utiliser un fichier de pid comme avant. Nombre de modif de systemd : 0, tout le taf est poussé sur le mec qui fait l'unit, en l’occurrence pour un soft proprio ou l'upstream ( ou le packageur ).

                        C'est dans les premières lignes de la page de man, avec les options "forking", "oneshot", ou "remainAfterExit".

                        http://0pointer.de/public/systemd-man/systemd.service.html

                        Donc si, on peut lui dire de faire ça, car ça reste assez flexible.

                        Ensuite, si le souci, c'est l'orchestration de services sur le réseau ( ie, ce que tu parles quand tu dis "cluster", c'est pas le but de systemd ou de sysv init, plus le but d'outils comme juju, mcollective, noah, et des dizaines d'autres qui fleurissent depuis l’avènement du cloud.

                        Enfin, tu parles de certif Oracle, mais sachant que OEL est juste une bête recompilation de RHEL avec une paire de patches et de modifs ( genre, btrfs par défaut ), tu penses vraiment que Oracle va dire "on certifie pas notre db sur notre distro" si jamais sa distro d'origine passe à systemd par défaut ?
                        ( et visiblement, c'est fort probable au vue de patch comme https://www.redhat.com/archives/libvir-list/2012-June/msg00374.html ).

                        Ou tu penses que Oracle va juste décider de maintenir un system de boot différent à base d'initscripts pur, quitte à proposer moins de fonctionnalités que ses concurrents ( car comme la dépêche sur opensuse le laisse supposer, suse semble aussi bien parti pour basculer ), une doc et des outils d'admins différents etc.

                        • [^] # Re: la guerre de s unices

                          Posté par . Évalué à  1 .

                          Sincèrement, j'apprécierais d'avoir une discussion ou je suis pas obligé de sans arrêt sortir la documentation pour dire "voila comment faire tel chose" pour dire que la personne avec qui je discute qu'elle semble être dans le faux.

                          Et moi donc j'apprécierai que tu lises la doc que tu me balances avant de me dire que je suis dans le faux.

                          Je récapitule pour ce qui ne suivent pas : on a un process qui éventuellement fork et repasse la main à l'init avant de commencer une synchronisation et finalement de lancer le vrai processus.
                          On va partir du principe que le process ne fork pas pour simplifier le boulot, mais c'est encore pire si il fork

                          Les options intéressantes :

                          RemainAfterExit=
                          PIDFile=
                          ExecStart=
                          ExecStartPre=, ExecStartPost=

                          Dès le départ je suis obligé d'aller remplir le PIDFile avec le PID de mon premier élément sinon ca s'arrête et systemd concluera à un echec de lancement.
                          Ensuite je poursuis ma synchro. Quand ma synchro est finie problème :
                          Soit j'avais mis RemainAfterExit à TRUE et là je peux fermer mon process de synchro l'esprit tranquille, mais si mon process principal ne se lance pas, ben systemd ne sera jamais mis au courant du fait que ca ne marche pas. Pareil si le process se lance mais meurt par la suite.

                          Soit j'avais mis RemainAfterExit à FALSE et là c'est le drame parceque je ne peux pas fermer mon processus de synchro avant d'être sur que la mise a jour des PID a bien eu lieu dans systemd. Sauf que je sais pas quand elle a lieu la mise à jour. Donc je boucle en mode texte du systemctl jusqu'à ce que le PID modifié soit pris en compte. (Je ne sais pas si ca a changé, mais en vrai le nouveau PID dans le fichier ne sera jamais pris en compte)

                          On triche avec ExecStartPre, je lance la moitié de mon script d'init en pre pour la synchro et l'autre moitié en normal.
                          Problème : si la synchro se foire, l'autre commande n'est jamais executée. Sauf si je mets un - devant ma commande, auquel cas l'autre commande est toujours executée. Sauf que je veux du "des fois oui, des fois non". Donc il faut que j'étoffe mes deux scripts pour que le second script puisse récupérer et analyser les résultats du premier script (BEURK). Donc non seulement j'ai deux scripts à maintenir au lieu d'un, mais en plus j'ai du boilerplate qui vient se rajouter en plus sur l'existant.
                          Sauf que si le second script plante pendant le démarrage, il n'est pas dit qu'il aura fait le ménage avant que le plantage. Donc un petit troisième script en ExecStartPost pour passer le balais….(que tant qu'à faire je met aussi en ExecStartPre des fois que).

                          YOUPI trois scripts pour le prix d'un avec du boilerplate en plus…

                          Ensuite, si le souci, c'est l'orchestration de services sur le réseau

                          Non le soucis c'est de passer le service dans un état dans lequel il pourra être orchestré par la suite. C'est dire cohérent, synchronisé, stable et avec les bon paramètres de connexion connus.

                          _Ou tu penses que Oracle va juste décider de maintenir un system de boot différent à base d'initscripts pur, quitte à proposer moins de fonctionnalités que ses concurrents _

                          Non c'est quasiment certain que systemd évoluera pour s'adapter au besoin. Je doute sincèrement que RH aille au bras de fer (c'est à dire dise à Oracle : soit c'est comme on veut, soit il va vous falloir trouver une nouvelle distrib de référence). Aucun interet pour eux. Si ils le font - c'est à dire si ils refusent de rajouter des gruikeries dans systemd malgré un besoin Oracle je leur tire mon chapeau, et j'applaudirai des deux mains. Mais très honnêtement (et il s'agit de mon opinion personnelle là) je n'y crois pas.

                          • [^] # Re: la guerre de s unices

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

                            Et sinon, c'est quoi le logiciel de merde en question ? Oracle DB?

                            Parce que moi, j'aurai tendance à dire que l'éditeur, si systemd devient le défaut, il va corriger son soft en faisant deux units:
                            - Une qui lance la synchro sans forker
                            - Une seconde qui lance le programme définitif quand l'unit précédente est terminée.

              • [^] # Re: la guerre de s unices

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

                J'aime assez le coté péremptoire de ton commentaire qui fait croire que tu t'y connais sur systemd, suivi par "je n'investirais pas de temps à apprendre systemd". Faut savoir, tu connais systemd sur le bout des doigts pour expliquer comment dbus est obligatoire pour le debug ( ie, tu as eu à débugguer ? ), ou tu n'y connais rien et tu es juste un raleur aigri ?

                Je penche pour le second, personnellement, mais je te laisse le bénéfice du doute.

                En fait, je penche pour le second parce que tu sembles tourner les choses pour un bon FUD.

                "pour avoir les fonctions qu'on a pas pour le moment, faut faire du boulot". En effet c'est logique, si tu veux des trucs qu'un script shell fournit pas, faut le refaire autrement. Mais sinon, les scripts marchent encore. Service marche encore.

                Et contrairement à ce que tu crois, y a pas mal de distro qui font plus d’exécution séquentielle. RHEL, ubuntu ont upstart. Mandriva/Mageia a un système qui lance tout en même temps depuis 2006 ( pinit ). Et la plupart font de la gestion automatique de l'ordre via un système de tags LSB.

                En fait, tu oublie aussi que les paquets des distros sont migrés, donc le travail de refonte est déjà fait ( comme les migrations à python 3 ou gcc 4, en fait ).

                Pour la pérennité, prends au moins des trucs qui ont disparus ( genre oss, genre ipchains ), car selinux est la depuis facile 10 ans, et il n'a pas changé des masses, il a surtout eu des features en plus. Dbus existe depuis au moins 5 ans, et pareil, les changements sont pas révolutionnaires. Certes, hal a disparu.

                Et sinon, comme tu avoues bien que faire des scripts d'init, c'est chiant, tu te rends bien compte que tu valides le point de vue des packageurs qui pousse à migrer à systemd ?

                • [^] # Re: la guerre de s unices

                  Posté par . Évalué à  2 .

                  _Faut savoir, tu connais systemd sur le bout des doigts pour expliquer comment dbus est obligatoire pour le debug _

                  A l'heure actuelle il y a une personne qui connait systemd sur le bout des doigts et peut-être 150 qui le connaissent vraiment très bien. Je ne fais pas partie de ces élus, et j'éviterai aussi longtemps que possible d'en faire partie.

                  En ce qui concerne DBus, à l'heure actuelle (sauf erreur de ma part) on ne dispose que de deux façon de dialoguer avec systemd : systemctl et DBus.
                  Si on utilise systemctl on a un nombre (pour l'instant) limité de fonctions. Un autre utilitaire systemadm est en cours de création, mais il ne fonctionne qu'en mode graphique.
                  Et systemctl est assez pourri. (Ce n'est pas un troll, tout le monde est d'accord là dessus même chez RH/Fedora). Pourri pourquoi ? Parcequ'il est très incomplet et pas forcément cohérent avec lui même. Sur les commandes un peu complexe on se retrouve à faire du ;echo $ $ $ pour pouvoir lire le résultat, pour certaines opérations il faut aller shooter des symlinks à la main etc.

                  Systemctl permet de faire très simplement toutes les opérations de base (restart, reload, reboot, status, changement d'init etc.) par contre pour les opérations un peu plus complexe il faut soit passer par des variables d'environnement, ce qui nécessite un peu de jonglerie. Par exemple que veut dire :
                  On top of that basic environment variable substitution is supported. Use ${FOO} as part of a word, or as word of its own on the command line, in which case it will be replaced by the value of the environment variable including all whitespace it contains, resulting in a single argument. Use $FOO as a separate word on the command line, in which case it will be replaced by the value of the environment variable split up at whitespace, resulting in no or more arguments. Note that the first argument (i.e. the program to execute) may not be a variable, and must be a literal and absolute path name.

                  Et l'air de rien ça complique pas mal la mise en mode maintenance…

                  • [^] # Re: la guerre de s unices

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

                    on ne dispose que de deux façon de dialoguer avec systemd : systemctl et DBus.

                    C'est vrai qu'avant, a part pouvoir faire start/stop/status/reload, on avait vachement plus de possibilités…

                    • [^] # Re: la guerre de s unices

                      Posté par . Évalué à  1 .

                      C'est vrai qu'avant, a part pouvoir faire start/stop/status/reload, on avait vachement plus de possibilités…

                      Ben avant le systeme d'init se prenait pas pour un système de controle. Donc un bête script rc de type

                      #!/bin/sh
                      trucctl $*    
                      
                      

                      marchait plutôt pas mal. Même si en vrai on était obligé de rajouter des tests pour tout un tas de cas à la con.

                      • [^] # Re: la guerre de s unices

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

                        Et c'est toujours possible avec systemd, je ne vois pas le problème.

                        « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                        • [^] # Re: la guerre de s unices

                          Posté par . Évalué à  2 .

                          Et c'est toujours possible avec systemd, je ne vois pas le problème.

                          Si je fais systemsctl reload "monfichier de conf" ca va executer tructl reload "monfichierdeconf" ou ça va me mettre un message d'erreur ?
                          Parce que la dernière fois que j'ai testé ca me mettait un message d'erreur.

                          • [^] # Re: la guerre de s unices

                            Posté par . Évalué à  3 .

                            Ben tu lances « tructl reload "monfichierdeconf" », au moins tu es sûr de ce que ça fait.

                            Ce que tu ne veux pas admettre, c'est que tu ne perds strictement rien.

                            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                            • [^] # Re: la guerre de s unices

                              Posté par . Évalué à  2 .

                              Ben tu lances « tructl reload "monfichierdeconf" », au moins tu es sûr de ce que ça fait.

                              Même pas. Parce que tructl reload peut relancer le processus principal (qui s'occupe juste de créer des sous process qui font le boulot eux-même) et dans ce cas là je ne sais pas comment systemd va réagir. Une fosi de plus je peux changer le comportement de systemd pour lui dire d ene pas surveiller les PID ou de ne pas accorder d'importance au contenu des cgroup, mais dans ce cas là systemctl status renverra des infos erronées.

                              De la même façon si tructl reload lance de nouveaux processus, je ne vais pas savoir facilement les intégrer dans le bon cgroup, donc systemctl restart risque là aussi de faire n'importe quoi.

                              Au final si je veux pouvoir utiliser tructl, il faut que je n'utilise QUE tructl. Mais là si j'ai des dépendances dans un sens ou dans l'autre il faut aussi que je les gère à la main. Bref je refais un système d'init parallèle.

          • [^] # Re: la guerre de s unices

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

            À vrai dire, sur un serveur à moitié embarqué j'aurais tendance à utiliser un système largement utilisé afin d'éviter au maximum des problèmes.

            Si je résume, systemd c'est au final plus de fonctionnalités, moins de bugs, plus rapide. C'est quoi l'intérêt de garder un sysv à l'ancienne qui est lent et moins testé?

            Personnellement je ne l'utilise pas encore parce que je ne veux pas casser mes systèmes, mais je l'activerais sûrement lors d'une nouvelle installation sur une distribution qui le supporte.

            • [^] # Re: la guerre de s unices

              Posté par . Évalué à  7 .

              À vrai dire, sur un serveur à moitié embarqué j'aurais tendance à utiliser un système largement utilisé afin d'éviter au maximum des problèmes.

              Ça tombe bien, j'utilise Debian.
              Plus sérieusement, ça dépend de ce qu'on appelle "à moitié embarqué". Mais bien souvent, il y a au moins une des contraintes de l'embarqué à tenir compte. Moi dans mon cas, c'est un manque de RAM, mais j'ai quand même un disque dur pour swapper. Donc je vire tout ce qui prend de la RAM et qui ne swappe pas bien, du genre ifplugd qui passe son temps à poller alors qu'on peut faire sans si on daigne utiliser netlink, ou… D-Bus.

              Si je résume, systemd c'est au final plus de fonctionnalités, moins de bugs, plus rapide. C'est quoi l'intérêt de garder un sysv à l'ancienne qui est lent et moins testé?

              [Référence nécessaire]. Sérieux, d'ou tu sort que systemd est plus tésté que sysv ? Et je veux bien des tests sur la rapidité de systemd sur des petites machines. Quand aux nouvelles fonctionnalités, c'est bien pour celui qui les attend, mais c'est pas mon cas.

              • [^] # Re: la guerre de s unices

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

                Je me base sur le fait que :

                • systemd est de plus en plus utilisé sur les grosses distributions linux, et puisque l'écosystème évolue quand même assez vite sous linux, dans quelques mois le support sysv pour différents projets pourra très bien être moins réactif que systemd (À savoir si il y a une modification qui pose problème dans le script d'init, ça sera plus rapidement vu avec systemd qu'avec sysv, surtout si c'est un cas peu courant)
                • sysv, utilisé sur les différentes distributions linux, est surtout impacté par les scripts associés. Il suffit de comparer les init debian et gentoo, toutes les deux basées sur sysvinit. Ce qui me fait dire par exemple qu'un script sysv gentoo est installé sur beaucoup moins de machines que le script systemd équivalent.

                J'avais installé un init systemd minimal sur un système ARM et ça démarrait rapidement mais vu le peu de services lancés c'est un peu normal et j'ai pas vraiment regardé plus loin sur la consommation mémoire ou quoi (en même temps faut voir ce qu'on appelle "petite machine", c'était quand même un CortexA9 1GHz dual core avec 1Go de RAM).

                Sinon il me semble que dbus est une dépendance de systemd parce que Lennart propose un set de fonctionnalité fixé, mais rien ne semble vraiment en dépendre (pas systemctl par exemple), donc à mon avis un petit patch devrait permettre de désactiver facilement dbus.

                • [^] # Re: la guerre de s unices

                  Posté par . Évalué à  3 .

                  systemd dépend de la libdbus car il propose une "activation dbus" similaire à l'activation par socket, mais utilisant un nom dbus. Si on avait un autre mode d'IPC de type bus répandu il dépendrait probablement de la lib idoine pour fournir également une activation paresseuse pour ce protocole d'IPC.

            • [^] # Re: la guerre de s unices

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

              C'est quoi l'intérêt de garder un sysv à l'ancienne qui est lent et moins testé ?

              C’est vrai que l’init System V est un truc trop récent et trop peu utilisé en production pour avoir été longuement testé.

              (Et que dire de l’init BSD, c’est carrément expérimental ça, faut aimer jouer avec le feu pour utiliser un truc aussi peu rôdé.)

          • [^] # Re: la guerre de s unices

            Posté par . Évalué à  6 .

            Si ces scripts étaient spécifiques, c'est qu'il y avait peut-être une raison.

            Par curiosité, laquelle ?

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # Pas compris

    Posté par . Évalué à  5 .

    Quel intérêt de lier systemd et udev ? Des performances, des fonctionnalités, une meilleur architecture ?

    Un fork est-il nécessaire ? Serait-il impossible de proposer un patch pour udev, avec les même avantages, mais sans dépendance dure entre systemd et udev ?

    Sans connaître les motivations qui poussent à ce fork, difficile de se faire une opinion, et de savoir si c'est une question de facilité pour les développeurs de systemd, ou un fork réellement justifié.

    • [^] # Re: Pas compris

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

      Au yeux de celui qui forke, c'est toujours justifié, la question est plus "est ce que le fork va tenir la route" ( perso, j'aurais tendance à dire "non" ). Car c'est bien joli de forker, mais faut le maintenir. C'est pas faire le git clone le souci, c'est les 500 git commit et push par la suite.

  • # « On ne vous met pas le couteau sous la gorge »

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

    Il y a quelques temps on disait que Lennart n'imposait pas ses créations aux autres… eh bien LOL.

    C'est vraiment fatigant toutes ces distribs qui imposent leurs « technologies ». Qu'ils cherchent à mettre au point de nouveaux trucs, OK, que certains les aiment et en veulent sur leurs machines, OK. En revanche, y aller à coup de « c'est moi qui développe tel outil standard » et « c'est moi qui développe tel nouveau joujou, donc autant lier les deux pour que tout le monde utilise aussi mon joujou parce que ça me fait du bien à l'égo », ça saoule. Red Hat a trouvé sa petite variante du embrace, extend and extinguish, il semblerait.

    On a affaire à une sorte de mondialisation des distributions, tout se ressemble et tout devient fade. Et cela est vaguement soutenu par quelques kékés qui pensent que c'est un bien pour que Linux soit « prêt pour le desktop » (re-LOL).

    Bientôt quoi ? Xorg ne voudra plus rien lancer d'autre que Gnome 3 ? Personnellement, je suis venu sur Linux pour la liberté de choisir, enfin bon…

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

    • [^] # Re: « On ne vous met pas le couteau sous la gorge »

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

      C'est vraiment fatigant toutes ces distribs qui imposent leurs « technologies ». Qu'ils cherchent à mettre au point de nouveaux trucs, OK, que certains les aiment et en veulent sur leurs machines, OK.

      T'aimes pas, bah tu utilises une autre distrib que celles que tu décris. OK.

      En revanche, y aller à coup de « c'est moi qui développe tel outil standard » et « c'est moi qui développe tel nouveau joujou, donc autant lier les deux pour que tout le monde utilise aussi mon joujou parce que ça me fait du bien à l'égo », ça saoule. Red Hat a trouvé sa petite variante du embrace, extend and extinguish, il semblerait.

      Bah c'est-à-dire que si ça déplaît à toute la planète… allez-y les mecs ! Faites un truc qui plait à tout le monde ! Du coup tout le monde délaissera le boulot de Redhat !

      cela est vaguement soutenu par quelques kékés

      Les quelques kékés qui financent tous les développements. Mais, vas-y, ton garage attend tes 4 potes.

      • [^] # Re: « On ne vous met pas le couteau sous la gorge »

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

        T'aimes pas, bah tu utilises une autre distrib que celles que tu décris. OK.

        J'utilise Slackware depuis fin 2005, si tu veux savoir.

        Et son mainteneur, Patrick Volkerding, commence à avoir du mal à résister à certains changements. Il ne veut pas de PAM, mais va finir par l'ajouter parce que tous les gros composants ne laissent plus la possibilité de s'en passer à moins de patcher. Et à mon avis, il va finir par devoir faire pareil pour PulseAudio et systemd, alors que ces composants ne correspondent pas à sa vision des choses. C'est lui qui le dit.

        Finalement, je suis passé à OpenBSD parce qu'ils m'ont l'air de mieux tenir le coup, mais ça n'a pas l'air tellement facile pour eux non plus…

        Bah c'est-à-dire que si ça déplaît à toute la planète… allez-y les mecs ! Faites un truc qui plait à tout le monde ! Du coup tout le monde délaissera le boulot de Redhat !

        Je pense que c'est vain et dangereux de vouloir faire un truc qui plait à tout le monde. Par contre, laisser la possibilité à chacun de choisir ce qu'il préfère, c'est toujours une bonne chose, selon moi.

        J'aimerais juste avoir la possibilité de garder mon init BSD quelques années, entre autres. Mais ça sent le sapin.

        Les quelques kékés qui financent tous les développements. Mais, vas-y, ton garage attend tes 4 potes.

        Tu peux garder ce ton de merdeux condescendant pour tes amis parisiens. Patrick Volkerding, dont je parlais plus haut, développe sa distrib Linux depuis 20 ans avec quelques potes, je pense que son point de vue sur l'écosystème Linux est quand même plutôt pertinent. Il n'a pas le portefeuille de Red Hat, mais j'aimerais qu'il puisse défendre sa vision des choses encore un moment.

        Systemd est pertinent pour pas mal de distribs et d'utilisateurs, mais, dans tous les cas, le fait que udev soit absorbé par systemd est une aberration. Surtout quand, quelques mois plus tard, les gros composants (développés par ceux qui ont le portefeuille) casseront la compatibilité avec l'ancienne version d'udev.

        Les « kékés » dont je parlais, c'était une référence à quelques blogueurs qui pensent qu'il ne devrait exister qu'une seule distrib Linux et que nous devrions tous y contribuer pour aller combattre le méchant Windoze. Et accessoirement, Lennart serait notre messie. Ils traînent parfois ici et me font à la fois peur et rire.

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

        • [^] # Re: « On ne vous met pas le couteau sous la gorge »

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

          mais ça n'a pas l'air tellement facile pour eux non plus…

          Gni??? Pas facile? C'est pas bientôt fini? "imposer", "pas facile", mais… Fait le boulot, point. Ils offrent, ils n'obligent pas. Par contre ils sont libres de ne pas faire ce que tu voudrais, tant que tu n'es pas leur employeur.

          Tu peux garder ce ton de merdeux condescendant pour tes amis parisiens.

          Eh oh, c'est qui qui balance des "imposer" n'importe comment? Bordel, c'est libre! Bordel, on est libre de ne pas prendre! Le reste existe toujours, et tu peux forker si plus personne ne s’intéresse à ta vision. Ah oui, il faudra bosser, mais il est hors de question d'être ton esclave aussi. Ils sont libres, comme toi.

          Ils traînent parfois ici et me font à la fois peur et rire.

          C'est sûr, à continuer comme ça depuis 10 ans, ta vision est… Clairvoyante.

          • [^] # Re: « On ne vous met pas le couteau sous la gorge »

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

            Ah, ça a mordu.

            L'argument bien facile du « fais le boulot » et « t'es libre de forker ».

            Il y a une différence de ressources entre la boîte qui finance les développeurs et de simples utilisateurs qui n'en seraient pas satisfaits.

            Surtout quand la boîte s'en fout des autres points de vue. Voir les citations de Lennart plus haut, ou les listes de diffusion d'OpenBSD où tu liras des choses marrantes sur les développeurs de GCC ou Mozilla, par exemple.

            Parfois, ça peut tout à fait se comprendre, techniquement. D'autres fois, c'est tout à fait intentionnel et ça pourrait facilement être évité. Le code a beau être libre, il n'est pas forcément maintenable par d'autres personnes que leurs vrais développeurs.

            Tu vas vraiment aller dire aux BSD d'aller forker systemd ? Ils n'en veulent pas et le code est énorme et il a été développé en partant du principe qu'il ne fonctionnerait que sur Linux. Puis Gnome ne voudra plus fonctionner sans systemd, et donc plus de Gnome sur les BSD.

            Connais-tu seulement des forks qui aient coexisté sur le long terme ? Y en a toujours un qui étouffe l'autre. Et à mon avis, ça sera celui de Red Hat, parce qu'il sera utilisé par une majorité de distribs. Et une bonne partie de celles-ci se mettront à l'utiliser parce que d'autres composants casseront, à leur tour, la compatibilité pour tout ce qui est différent de systemd.

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

            • [^] # Re: « On ne vous met pas le couteau sous la gorge »

              Posté par (page perso) . Évalué à  8 . Dernière modification : le 04/09/12 à 23:11

              L'argument bien facile du « fais le boulot » et « t'es libre de forker ».

              Tu as dû louper la partie : on n'est pas ton esclave. La liberté, c'est aussi la liberté de faire ce qu'on a envie (et ce qu'on croit meilleur)

              Il y a une différence de ressources entre la boîte qui finance les développeurs et de simples utilisateurs qui n'en seraient pas satisfaits.

              C'est ton problème. A toi de trouver le financement pour ce qui te plait, ce que tu crois meilleur, à mettre les gens d'accord. Le libre n'est pas faire ce qu'il te plait gratos. Et Lennart n'est pas ton employé. La, il semble que le monsieur, avec ses priorités, arrive à attirer suffisamment de monde pour que ça marche. Lui. A toi de démontrer que ta solution est meilleure.

              C'est ça la beauté du libre aussi. Etre libre.

              • [^] # Re: « On ne vous met pas le couteau sous la gorge »

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

                Tu as dû louper la partie : on n'est pas ton esclave. La liberté, c'est aussi la liberté de faire ce qu'on a envie (et ce qu'on croit meilleur)

                La liberté n'existe vraiment que quand elle ne restreint pas sciemment celle des autres.

                systemd ressemble de plus en plus à un cheval de Troie. Il touche aux scripts de démarrage, il touche à Gnome, il touche à udev. Je te parie que d'ici 2 ans, vouloir se passer de systemd sera quasiment impossible.

                C'est ton problème. A toi de trouver le financement pour ce qui te plait, ce que tu crois meilleur, à mettre les gens d'accord. Le libre n'est pas faire ce qu'il te plait gratos. Et Lennart n'est pas ton employé. La, il semble que le monsieur, avec ses priorités, arrive à attirer suffisamment de monde pour que ça marche. Lui. A toi de démontrer que ta solution est meilleure.

                C'est ça la beauté du libre aussi. Etre libre.

                J'ai l'impression d'avoir un ultra-libéral devant moi. Quelqu'un abuse de sa situation, mais heureusement je suis libre de faire pareil si je ne suis pas content, quel argument et quelle idée de la liberté (t'as qu'à avoir un bon portefeuille si tu veux défendre ta vision des choses !).

                Je ne demande pas à démontrer que ma solution est meilleure. J'aimerais juste que ma vision des choses puisse continuer de cohabiter avec la sienne. Actuellement, je peux encore me passer de systemd, techniquement, mais ça ne va pas durer. Que Fedora ait besoin, développe et utilise systemd, c'est normal. Qu'elle empêche les autres distributions de s'en passer (indirectement mais tout à fait intentionnellement), c'est anormal. Ils empêchent volontairement la compatibilité avec tout ce qui ne les intéresse pas (et c'est pas un patch qu'il faudrait, mais une totale réécriture) et ensuite ils rendent un composant majeur dépendant de ce nouveau composant.

                Je dois te dire que dans ma tête, quand j'évalue un logiciel, j'ai une cinquième liberté fondamentale en tête. Celle de se dire « est-ce que ce logiciel n'empêchera pas le développement d'alternatives ? ». Dans ce sens-là, des composants tels que xf86-video-nv ou systemd n'ont pas l'éthique libre, pour moi. Car ils m'enlèvent une liberté de façon tout à fait intentionnelle.

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

                • [^] # Re: « On ne vous met pas le couteau sous la gorge »

                  Posté par . Évalué à  3 .

                  systemd ressemble de plus en plus à un cheval de Troie. Il touche aux scripts de démarrage, il touche à Gnome, il touche à udev. Je te parie que d'ici 2 ans, vouloir se passer de systemd sera quasiment impossible.

                  Ben si ce sera possible, il te suffira de creer quelque chose de meilleur et les gens l'adopteront. Il n'y a rien qui empeche les gens de modifier le code ou bien ?

                  Je ne demande pas à démontrer que ma solution est meilleure. J'aimerais juste que ma vision des choses puisse continuer de cohabiter avec la sienne. Actuellement, je peux encore me passer de systemd, techniquement, mais ça ne va pas durer.

                  Fais un fork, ou convainc les gens que ta solution vaut la peine d'etre supportee. Simplement dire "je veux pas changer" n'est pas une raison suffisante pour se taper la maintenance de ton truc, sinon fais le toi-meme.

                  Je dois te dire que dans ma tête, quand j'évalue un logiciel, j'ai une cinquième liberté fondamentale en tête. Celle de se dire « est-ce que ce logiciel n'empêchera pas le développement d'alternatives ? ». Dans ce sens-là, des composants tels que xf86-video-nv ou systemd n'ont pas l'éthique libre, pour moi. Car ils m'enlèvent une liberté de façon tout à fait intentionnelle.

                  Tu peux toujours forker et avoir ton propre truc, rien ne l'empeche. Et au final si ta solution est meilleure, alors les gens l'adopteront, si non, ben c'est probablement une bonne chose qu'ils ne se tapent pas le support de ton truc.

                • [^] # Re: « On ne vous met pas le couteau sous la gorge »

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

                  J'aimerais juste que ma vision des choses puisse continuer de cohabiter avec la sienne.

                  Elle peut : tu peux prendre l'ancien udev, et travailler dessus. D'ailleurs, c'est le cas ici. Tu n'as toujours pas dit pourquoi des mecs que tu ne payes pas devraient bosser gratos pour toi et faire un truc qu'ils trouvent inutiles.

                  J'ai l'impression d'avoir un ultra-libéral devant moi.

                  Plutôt à un mec qui se tape aussi des gens qui pensent savoir ce qui est mieux pour le monde, qui se tape d'autres personnes qui voudraient que que ce mec devrait faire des choses gratos pour eux parce que "tu comprend, il faudrait que je puisse continuer avec l'ancien système qui ne te sert plus", bref qui se tape des sangsues qui veulent le beurre, l'argent du beurre et le cul de la crémière.

                  Les autres, ceux qui ne développent pas, savent tout mieux que le développeur de ce qu'il y a de mieux et d'important à faire. Ou pas.

                  Ici, systemd n'enlève aucune liberté, tu es tout à fait libre de ne pas l'adopter. D'ailleurs, il y a un fork. On va voir si il y a assez de gens intéressés par ce fork… Tu aurais aussi pu avoir tout le loisir d'embaucher Lennart ou sponsoriser financièrement la perte de temps à faire ces maintenances inutiles pour lui (ça serait utile pour lui du coup), mais non, ici, on râle sur un forum, c'est gratuit c'est plus facile.

                  Lennart fait ce pour quoi il est payé, que ça vous plaise ou non c'est la vie. Ca ne vous plait pas, libre à vous de proposer mieux (par exemple un système qui permet de "cohabiter" avec les autres). On va voir juste si vous arrivez à être aussi bon et rapide ("time to market") que lui.


                  Le problème que je vois est surtout que quand un produit marche, il faut surtout le casser au maximum, s'en plaindre, dire que "c'et pas dans l'esprit du libre" qui n'existe pas (hop, on invente une cinquième liberté perso). Avant c'était Ubuntu le grand méchant, c'est un peu passé, hop le suivant est systemd. Jaloux? Le point commun? Ca répond au besoin des gens, qui l'adoptent.

                • [^] # Re: « On ne vous met pas le couteau sous la gorge »

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

                  Dans ce sens-là, des composants tels que xf86-video-nv ou systemd n'ont pas l'éthique
                  libre, pour moi.

                  Dans ce sens-là, tu dois penser la même chose de udev avant systemd non? Ce truc codé pour Linux et qui bloque la liberté des BSDistes…

            • [^] # Re: « On ne vous met pas le couteau sous la gorge »

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

              Tu vas vraiment aller dire aux BSD d'aller forker systemd ? Ils n'en veulent pas et le code est énorme et il a été développé en partant du principe qu'il ne fonctionnerait que sur Linux. Puis Gnome ne voudra plus fonctionner sans systemd, et donc plus de Gnome sur les BSD.

              Connais-tu seulement des forks qui aient coexisté sur le long terme ? Y en a toujours un qui étouffe l'autre. Et à mon avis, ça sera celui de Red Hat, parce qu'il sera utilisé par une majorité de distribs.

              Bah… ouais.

              Salut, dinosaure.

              • [^] # Re: « On ne vous met pas le couteau sous la gorge »

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

                Bah… ouais.

                Salut, dinosaure.

                "Those who don't understand Unix are condemned to reinvent it, poorly." – Henry Spencer

                Salut, petit système d'exploitation qui me plaisait bien. Tu vas devenir un Windows gratuit très mauvais.

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

  • # La lutte contre Lennart m'énerve un peu

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

    Je trouve, particulièrement agaçant d'attaquer Lennart en lui mettant sur son dos des maux dont il n'a aucune responsabilité.
    Ce type est un trolleur hors catégorie, comme Miguel de Icaza, Linus Torvals, RMS, Eric Raymond, et la liste est probablement bien plus longue. Je suis d'accord dessus, mais troller n'a aucun rapport avec le travail effectué. On peut critiquer les personnes précédentes, dont Lennart, pour leur trolls et réactions parfois très sévères mais techniquement pour la plupart d'entre eux, le travail reste d'une grande qualité.

    Lennart est donc critiquable pour ses prises de positions, soit. Cependant, je trouve étonnant qu'on reproche toujours à Lennart ses logiciels alors que la plupart des distributions ont adopté son travail et dont il n'a aucun pouvoir de décision dans ces équipes si différentes. Oui Lennart travaille pour Red-Hat ce qui lui a ouvert les voies de Red-Hat et Fedora. Je veux bien croire que Red-Hat a une influence décisionnel dans l'écosystème GNU/Linux. Mais si c'était de la merde en boîte, j'ai de gros doutes que Debian, Ubuntu, Mandriva/Mageia, Suse, ArchLinux et autres acceptent ces logiciels en standard ou options. D'autant plus que certaines équipes de dévs n'hésitent pas à aller en contre-sens vis à vis de Red-Hat s'ils jugent nécessaires.
    Donc Lennart n'a rien imposé du tout à qui que ce soit, à aucun projet que ce soit. Donc j'ai du mal à voir le désastre ou le problème. Si les distributions suivent, avec leurs développeurs expérimentés, je pense qu'il y a de bonnes arisons sans subir de menaces de la part de Lennart (qui n'a de toute façon aucun moyen de pression).

    Et je peux également ressortir la problématique de la compatibilité UNIX. Oui UNIX c'est un système robuste et large avec un ensemble d'API commun pour facilité les portages et l'administration système de manière général. Le problème est que trop de compatibilité tue la compatibilité. *BSD ne doit pas être un Linux sous une autre licence, si c'était le seul intérêt de *BSD ça n'intéresserait pas grand monde. Il faut des différences entre les systèmes, c'est bien pour l'innovation, les performances et les possibilités. J'ai du mal à saisir l'intérêt d'avoir un gestionnaire de boot comme init commun à tous, d'autant que *BSD a suivi une voie différente que Linux sur ce point et que init montrait des signes de faiblesses. N'est-il pas mieux d'avoir des différences entre les systèmes ? Pas trop mais un minimum quand même ?

    Enfin si ça vous plait d'avoir des OS qui se ressemblent tellement que la seule différence est la version de Firefox employée ou la mascotte disponible, ça vous regarde mais ça ne m'intéresse personnellement pas. Du temps que la compatibilité reste globalement bonne pour porter facilement les applications et dialogues entre système, ça me va et systemd n'est pas un frein particulier à cela.

    • [^] # Re: La lutte contre Lennart m'énerve un peu

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

      J'ajoute volontiers qu'on a de la chance d'avoir des systèmes sous licence libre ce qui permet à chacun d'apporter ce qu'on veut.
      Si vous souhaitez ne pas dépendre de systemd pour une raison ou une autre, vous pouvez participer à un projet pour ça. Vous pouvez porter systemd pour avoir ce système disponible pour *BSD, Hurd, Plan 9 et autres ce qui permettrait de garder une compatibilité entre « UNIX ».

      En tout cas, vous ne pouvez forer personne de faire quelque chose qu'il ne veut pas pour vous faire plaisir. Les développeurs cherchent souvent à se faire plaisir à eux d'abord. Donc à moins de payer des gens pour ça, vous pouvez donner votre touche personnelle aux projets. ;)

    • [^] # Re: La lutte contre Lennart m'énerve un peu

      Posté par . Évalué à  10 .

      Lennart n'a rien imposé du tout à qui que ce soit, à aucun projet que ce soit.

      C’est le sujet de ce journal. L’incorporation d’udev à systemd est une forme de chantage, que le fork tente de corriger. Il y a aussi eu la tentative de dépendance obligatoire dans GNOME.

      Enfin si ça vous plait d'avoir des OS qui se ressemblent tellement que la seule différence …

      Au contraire, les Linux actuels utilisent de systèmes d’initialisation différents (par exemple : SystemVinit, OpenRC, upstart, systemd). Le problème de systemd est justement qu’il tente de se rendre obligatoire (par udev ou par GNOME). Si systemd fournissait une alternative non obligatoire au système d’initialisation, on pourrait se contenter de l’ignorer si ça ne nous plaisait pas.

      Les logiciels libres ce n’est plus seulement les libertés fondamentales d’accès aux sources et de modification. C’est aussi de pouvoir choisir ce que l’on veut dans l’écosystème, c’est à dire l’interopérabilité.

      • [^] # Re: La lutte contre Lennart m'énerve un peu

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

        C’est le sujet de ce journal. L’incorporation d’udev à systemd est une forme de chantage, que le fork tente de corriger. Il y a aussi eu la tentative de dépendance obligatoire dans GNOME.

        Bof non, ce n'est pas du chantage. Les gens peuvent abandonner systemd si ça ne leur va pas, ou de garder udev également d'autre part si besoin.
        Gnome n'a pas accepté le fait de dépendre de systemd, même s'il a proposé il ne pouvait pas l'imposer à Gnome s'ils ne le voulaient pas (et si Gnome avait accepté, ils en ont le droit).

        Le problème de systemd est justement qu’il tente de se rendre obligatoire (par udev ou par GNOME).

        Les projets udev et Gnome n'ont pas et ne sont pas obligés de dépendre de systemd s'ils ne le veulent pas. S'ils acceptent ce n'est pas la faute à Lennart ou systemd en soit.

        Les logiciels libres ce n’est plus seulement les libertés fondamentales d’accès aux sources et de modification. C’est aussi de pouvoir choisir ce que l’on veut dans l’écosystème, c’est à dire l’interopérabilité.

        Je ne vois aucune des 4 libertés qui rendent cette disposition obligatoire… Au contraire, un logiciel libre est libre de se foutre des autres projets s'il le souhaite… Et chacun est libre de modifier ce logiciel pour l'adapter aux autres.

        • [^] # Re: La lutte contre Lennart m'énerve un peu

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

          Bof non, ce n'est pas du chantage. Les gens peuvent abandonner systemd si ça ne leur va pas, ou de garder udev également d'autre part si besoin.

          udev est devenu un incontournable. Les alternatives comme mdev ne sont pas assez complètes (pas de support lvm/raid…). Or il est clairement annoncé que l'utilisation sans systemd risque de ne plus être supportée. En gros dès que les dévs de udev vont en avoir marre, ça va gicler. Et on peut leur faire confiance, c'est déjà arrivé avec la fin du support des /var et /usr séparés depuis udev-181.

          C'est bien du chantage. Et c'est le droit des développeurs de udev, je suis bien d'accord. Mais du coup il ne faut pas trop s'étonner du fork.

          • [^] # Re: La lutte contre Lennart m'énerve un peu

            Posté par . Évalué à  -3 .

            Les alternatives comme mdev ne sont pas assez complètes (pas de support lvm/raid…)

            Hé bien, si tout ceux qui se plaignent se retroussent les manches, ça ne sera plus un problème, non ?

            Juste se plaindre sans essayer d'améliorer la situation, ça ne sert à rien.

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

            • [^] # Re: La lutte contre Lennart m'énerve un peu

              Posté par . Évalué à  5 .

              Tout dépend du niveau de contributions des uns et des autres. D'autre part tout le monde n'a pas le même temps à disposition.

              Enfin bref, y'a rien dans la loi qui interdit de se plaindre, au contraire c'est assez sain et vouloir nier ça est une abération.

              • [^] # Re: La lutte contre Lennart m'énerve un peu

                Posté par . Évalué à  1 .

                C'est sûr, rien n'interdit de se plaindre. Tout comme rien n'oblige non plus de prendre en compte ces plaintes.

                Mais si c'est constructif et ça tente d'apporter quelque chose, il y a déjà plus de chances que ça soit écouté.

                Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: La lutte contre Lennart m'énerve un peu

        Posté par . Évalué à  3 . Dernière modification : le 04/09/12 à 21:32

        Si les informations de ce journal sont exactes, je pense pour ma part, que si un système est techniquement supérieur à un autre, il peut le prouver point par point face à ses concurrent de manière rationnelle tout en sachant que ceux ci bénéficie eux du fait qu'ils ont dans un certains nombre de domaine fait leur preuve.

        Il n'est pas nécessaire d'utiliser le système de dépendance de manière détourner pour qu'il soit utilisé.
        Cette technique ressemble effectivement au embrace et extend… (c'est comme le fait de rester sous Word car il est le seul à pouvoir lire les documents DOC sans aucune perte de formatage ….)

        Actuellement je n'ai pas encore vue d'étude quantifée entre systemD et le script shell. Je ne vois pas pourquoi je devrais accordé ma confiance dans l'utilisation de ce nouveau système à moins de me le prouver par A + B.

        Le fait de faire les choses de manière fallacieuse n'est pas un gage de confiance …

        Un système techniquement supérieur n'a pas besoin qu'on le soutienne par des techniques détournées, il suffit à lui meme pour convaincre.

        Ajouté quelque chose à la vérité c'est le transformer en mensonge…

        • [^] # Re: La lutte contre Lennart m'énerve un peu

          Posté par . Évalué à  -4 .

          Euh… je suis pas sur que tu serve vraiment ton propos là:

          Le fait de faire les choses de manière fallacieuse n'est pas un gage de confiance …

          (Le gras est de moi.)

          Ajouté quelque chose à la vérité c'est le transformer en mensonge…

          PS: merde moi aussi j'ai rajouté du gras sur ta vérité

        • [^] # Re: La lutte contre Lennart m'énerve un peu

          Posté par . Évalué à  10 .

          Vous croyez que le merge de systemd et udev, c'est fait comment ? Lennart a debarque sur la ML de udev en prenant en otage les familles des developpeurs de ce projet ?!

          Si udev a finit dans systemd, c'est que les mainteneurs de udev ont trouve que c'etait une bonne idee. Ils l'ont accepte et meme voulu, on merge pas du code par magie ! C'est un choix qui doit aider ces deux projets et les faire avancer plus efficacement.

          Alors faut arreter avec vos theories du complot et vos histoires de restriction de liberte. Les developpeurs font les choix techniques qui leur semblent les meilleurs, si jamais ca vous convient pas faite un fork et prouve que vous avez raison en le faisant depasser l'original (C'est clairement l'objectif du fork de udev). Ce sera une competition technique et pas des idiotes theories complotistes qui veulent des rapports d'evaluation geostrategiques…

          • [^] # Re: La lutte contre Lennart m'énerve un peu

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

            si jamais ca vous convient pas faite un fork et prouve que vous avez raison en le faisant depasser l'original (C'est clairement l'objectif du fork de udev)

            Forker un composant système comme udev, c'est autre chose qu'un explorateur de fichier ou un navigateur web. Le problème de la compatibilité des API risque de se poser.

            Ce sera une competition technique

            Malheureusement, être le meilleur techniquement n'est ni une assurance de réussite ni même un pré-requis.

        • [^] # Re: La lutte contre Lennart m'énerve un peu

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

          Actuellement je n'ai pas encore vue d'étude quantifée entre systemD et le script shell. Je ne vois pas pourquoi je devrais accordé ma confiance dans l'utilisation de ce nouveau système à moins de me le prouver par A + B.

          moi je n'ai pas le temps de lire des études comparés de tous les logiciels que j'utilise alors je fais confiance aux développeurs de ma distribution…

      • [^] # Re: La lutte contre Lennart m'énerve un peu

        Posté par . Évalué à  10 .

        la tentative de dépendance obligatoire dans GNOME.

        Ce point a déjà été discuté précédemment. Gnome ne dépend pas de systemd, mais il dépend d'interfaces D-Bus diverses (genre org.freedesktop.hostname1) spécifiées au sein de freedesktop.org, et qui sont pour l'instant uniquement implémentées par des petits utilitaires fournis par systemd. Ces interfaces sont triviales (vraiment) et peuvent être implémentées facilement par un autre outil.

        Il s'agit juste de déplacer la maintenance des outils spécifiques aux distros au sein des distros au lieu de les garder au niveau de l'upstream, car de toute façon les outils upstream (system-tools-backend) ne supportaient que redhat, debian et opensuse.

        • [^] # Re: La lutte contre Lennart m'énerve un peu

          Posté par . Évalué à  7 .

          Pourquoi ces interfaces sont-elles fournies par systemD, et non par un programme autonome ? Elles interagissent en profondeur avec SystemD, ou est-ce juste car c'est le même auteur ?

          • [^] # Re: La lutte contre Lennart m'énerve un peu

            Posté par . Évalué à  3 .

            Juste car c'est le même auteur, tu peux tout à fait faire tourner ces petits programmes triviaux sans systemd, certaines distro le font. Ça utilise probablement un .so commun mais ça marche aussi avec sysvinit.

          • [^] # Re: La lutte contre Lennart m'énerve un peu

            Posté par . Évalué à  4 .

            Elles interragissent reellement en profondeur avec systemd declenchant des evenements auquel des units peuvent reagir entre autre chose. Mais rien n'empeche une distrib de recoder un daemon qui a la meme API DBus. En fait techniquement, c'est la meilleur solution. Systemd fournit une infra qui permet au projet upstream de propager plus facilement leurs ameliorations dans les distribs en diminuant les acces a des fichiers ou des scripts custom.

            Pour un projet upstream, c'est juste ideal. Je me plug sur l'API DBus, et je n'ai plus a avoir un truc custom par distrib. Forcement, ca facilite la vie de tout le monde, sauf ceux qui veulent etre different… A eux de developper leur demon de remplacement, c'est pas tres difficile en meme temps. Mais ca deplace clairement les problemes sur ceux qui les creent ce qui est une bonne chose.

            • [^] # Re: La lutte contre Lennart m'énerve un peu

              Posté par . Évalué à  -2 .

              Si tu veux remplacer systemd par un autre démon qui à la même API D-Bus, et bien désolé, mais tu dépendra toujours de D-Bus, et ça sera toujours une putain de mauvaise idée. Alors oui, tu peut te recoder la libdbus (comme ça tu pourra là faire un peu moins viellotte tant qu'à faire), mais bon, systemd est bloat de base, on pourra pas faire moins pire en étant compatible.

              (Hé! j'ai cru comprendre que tu voulais une alternative à systemd, alors je t'ai recodé son interface D-Bus dans un recodage de l'interface libdbus pour que tu puisse t'interfacer avec libdbus pendant que tu t'interface avec D-Bus!)

              Enfin bref, question remplacabilité et modularité on à fait mieux.

              • [^] # Re: La lutte contre Lennart m'énerve un peu

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

                Et sinon, toi tu codes quoi de beau qu'on puisse admirer la qualité et le non bloat de ton travail, si il y'en a ce dont je me permet de douter…

              • [^] # Re: La lutte contre Lennart m'énerve un peu

                Posté par . Évalué à  2 .

                Wouhou, ca se transforme en troll sur DBus ! Bon, tu proposes quoi comme alternative a DBus ? Un truc libre, standard avec des outils et facilement integrable par tout le monde ?

                A ma connaissance, il n'y a rien. Et non, faire des IPC direct a la mano avec les daemons, n'est pas une bonne reponse. Car cela duplique du code, rend difficile l'interoperabilite et l'ecriture de frontend alternatif.

                Certe techniquement dbus, ca pourait etre plus lege, plus rapide, plus efficace, mais tu peux proposer des patchs pour ca. Je rappel, le code est libre et tous les utilisateurs de libdbus en profiteraient… Avantage d'avoir une brique comune !

                • [^] # Re: La lutte contre Lennart m'énerve un peu

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

                  Y a binder \o/

                  http://developer.android.com/reference/android/os/Binder.html

                  sinon, y a aussi les bons vieux RPC de Sun, pour nfs. Il y a eu corba ( bonobo ).

                  mais la vraie solution, c'est de mettre directement le passage de message dans le kernel, et de ressortir un micro noyau, soit à la qnx, soit le hurd.

                  Et je pige pas, si tout le monde veut un truc modulaire et KISS, y a le hurd. L'archi est propre, il y a du taf pour tous :
                  - portage de logiciel sur le hurd ( genre, ne pas utiliser MAX_PATH )
                  - écriture de documentation ( genre, un guide pour linuxien, comment afficher son ip, etc )
                  - des tests, des présentations, etc

                  ou du plus complexes, genre écriture de pilote, etc.

                  • [^] # Re: La lutte contre Lennart m'énerve un peu

                    Posté par . Évalué à  2 .

                    Et je pige pas, si tout le monde veut un truc modulaire et KISS, y a le hurd.

                    Oui enfin si on parle d’IPC, 9p peut faire tout ce que fait DBus de façon nettement plus propre (dans Plan9 tout est fichier, contrairement à Unix), avec une implémentation beaucoup plus légère.

                • [^] # Re: La lutte contre Lennart m'énerve un peu

                  Posté par . Évalué à  3 .

                  Une alternative à D-Bus ? Pourquoi pas … aucune ?

                  Ça ne me gène pas que D-Bus soit utilisé sur la session de madame michu. Un processus qui plante tout le bureau quand il merde, il y en a suffisamment, alors un de plus ou un de moins …

                  Mais sur un système de boot, non, quoi. Déjà la libdbus est extrêmement chiante à intégrer dans un programme, surtout si tu n'a pas une mainloop des années 90. Et encore faut t'il en avoir un, de programme qui tourne.

                  Ensuite, ne faire qu'une API qui parle à travers des sockets, c'est franchement lourdingue. Une socket, ça à plein de cas d'erreurs différents qui sont chiants à gérer pour faire des choses simples : une socket peut se fermer en plein millieu à n'importe quel moment, peut rester sans réponse indéfiniment, ou peut recevoir de la merde.

                  À coté, quand je fait un service monservice reload, Je demande rien à personne. Le fork peut merder, l'exec aussi et j'ai peut-être un sigchld à ignorer, et hop c'est fini. Un système de boot pourra choisir de lancer le service directement à partir de /sbin/service ou alors pourra charger son D-Bus lourdingue et planter lamentablement avec fallback sur la première solution en cas de problème). Si j'ai envie d'une information supplémentaire sur l'opération, je peux regarder le code de retour. C'est vrai que c'est très limité, et c'est sans doute la première chose que je changerai si on me demandait de faire une API systemd-like.

                  Et voilà comment une API qui existe presque déjà est plus simple, plus fiable, plus portable et plus facilement implémentable (et donc remplaçable) que n'importe quel machin avec du D-Bus dedans: Si tu veux causer au système de boot, tu lance un programme avec des arguments spécifiés. Va trouver un système de boot qui ne puisse pas implémenter ça !

      • [^] # Re: La lutte contre Lennart m'énerve un peu

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

        Pour moi, le chantage, c'est quand tu forces quelqu'un à faire quelque chose, en le menaçant de lui faire autre chose s'il n'obéit pas.

        Là, je ne vois pas trop quelle est la menace brandie en cas de désobéissance, alors que c'est tout de même l'élément le plus important du chantage.

  • # systemd et arch

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

    quelques liens sur le (futur) passage d'archlinux à systemd :
    http://allanmcrae.com/2012/08/switching-my-laptop-to-systemd/
    http://jasonwryan.com/blog/2012/08/04/systemd/

    de ce que j'ai pu lire rapidement sur les ml, ce choix a l'air approuvé par tous les dev, et j'ai tendance à faire confiance à ces gens là pour faire les bons choix. Du coup je suis passé à systemd et ca ne me marche pas plus mal qu'avant, donc d'un point de vue utilisateur ca me va :-)

    Un autre lien avec un post du dev qui s'occupe de cette migration, sur les raisons techniques notamment: https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530

    • [^] # Re: systemd et arch

      Posté par . Évalué à  10 .

      Ça fait plus d’un an que je suis passé à systemd sous Arch, en mode natif (à l’époque, la Fedora 15 ne l’utilisait qu’en mode compatible).

      Ma conclusion principale est que systemd n’est pas stable, au sens Debian du terme, c’est-à-dire que les bugs changent régulièrement.

      Étonnament (systemd n’était à l’époque qu’un paquet du dépôt community), il y a un an, tout fonctionnait nickel.
      Actuellement, j’ai ce bug, qui n’existait pas à l’époque, et entre les deux, c’était NetworkManager qui partait systématiquement en sucette à l’arrêt du système et systemd qui attendait de très longues minutes après.
      Et déboguer l’arrêt du système, ce n’est pas trop pratique… j’étais bien content de m’être gardé la possibilité de démarrer avec rc.sysinit.

      À part ça, la prise en compte de la ligne DAEMONS de rc.conf, que j’avais désactivée (l’idée était d’être en mode natif mais en gardant la possibilité de démarrer avec rc.sysinit), a aussi été réactivée (ce n’est plus la même procédure pour la désactiver) et journald est arrivé sans que je l’aie demandé. Je me demande si je pourrai échapper à Pulseaudio, Avahi et aux prochains projets de Lennart, bons ou mauvais…

      Bref, à mon avis, systemd n’est pas encore mûr et si l’on veut un truc simple et fiable, mieux vaut en rester au vieux système d’init. Pour ma part, je l’ai remis par défaut.

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

      • [^] # Re: systemd et arch

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

        C'est un peu facile de cracher sur systemd quand on utilise ArchLinux…

        Ca fait des mois que l'init standard Archlinux me fait des FAILS sur toutes mes machines aléatoirement (un shutdown sur trois) donc dois je en déduire que l'init Archlinux n'est pas stable ?

        Par contre, sur mon laptop sous ArchLinux avec systemd, je n'ai aucun problème…

        • [^] # Re: systemd et arch

          Posté par . Évalué à  2 .

          Avec systemd, les dépendances entre services sont renseignées d’origine, probablement presque toujours correctement (après, si on a par exemple mis les paramètres pour autofs dans l’annuaire LDAP, il faut peut-être ajuster soi-même).

          Par contre, l’init standard démarre les services dans l’ordre où tu les as indiqués et les arrête dans l’ordre inverse. C’est à toi de mettre le bon. As-tu essayé de le changer ?

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

      • [^] # Re: systemd et arch

        Posté par . Évalué à  2 .

        Je me demande si je pourrai échapper à Pulseaudio, Avahi et aux prochains projets de Lennart, bons ou mauvais…

        Pour Avahi, il est devenu une dépendance pour Cups sous Archlinux donc ça a déjà commencé…

        Par contre, pas de dépendance à Pulseaudio à ma connaissance.

        • [^] # Re: systemd et arch

          Posté par . Évalué à  3 .

          Déjà qu'il faut maintenir ces propres PKGBUILD pour samba et kvm :

          • kvm -> dépendant de bluez -> dépendant de bluetooth
          • samba -> dépendant de libcups -> dépendant de avahi

          Bluetooth et Avahi, ça a de la gueule sur un serveur en prod !

          • [^] # Re: systemd et arch

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

            Bluetooth et Avahi, ça a de la gueule sur un serveur en prod !

            Mon dieu!!! Y'a deux dépendances vers une pauvre librairie, c'est la fin du monde, t'as raison, recompile tout! A ta place, je passerai sous Gentoo histoire d'optimiser un peu tout cela, ca se trouve, tu pourrais virer directement le support cups de samba, puis virer le support usb de cups, …

            Et en plus, dans le cas de Arch, les paquets étant peu découpé, le service est installé mais je ne pense pas qu'il se lance tout seul.

    • [^] # Re: systemd et arch

      Posté par . Évalué à  4 .

      de ce que j'ai pu lire rapidement sur les ml, ce choix a l'air approuvé par tous les dev

      C'est d'ailleurs assez marrant de constater que c'est approuvé par les dev mais désapprouver par une relativement grosse partie de la communauté.

      C'est exactement le même problème que lors du passage à GRUB2, de la suppression de AIF, etc.

      • [^] # Re: systemd et arch

        Posté par . Évalué à  3 .

        C'est toujours pareil : on voit que ceux qui ne sont pas d'accord sont ceux qui n'auront pas à se taper le boulot de développement et de maintenance.

        Et tout ça gratuitement, bien entendu.

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # Loin de la foule

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

    Le truc qui me frappe avec systemd, et c’était déjà vrai avec Pulseaudio, c’est que je suis complètement largué. Largué par Linux, on pourrait me conseiller de passer à Windows. Sauf que pour comprendre le fonctionnement de Windows, il a fallu que je passe par Linux. Et du coup j’y suis resté.

    La liberté de vérifier ou de retoucher le code source : pas les compétences pour ça. En revanche, la liberté de complicité avec le système, et d’en tirer le meilleur parti, Linux OK pour moi. La simplicité d’init de Slack ou d’Arch m’allaient très bien.

    Linux a la réputation de ne pas être immédiatement abordable. Je le traduis autrement : il est formateur. Ou du moins il l’était. Beaucoup de windowsiens autour de moi n’arrivent pas à différencier le programme de son icône sur le bureau. Avec Linux, c’est impossible, et impossible de ne pas comprendre ce que sont un répertoire ou un fichier invisible.

    Cette pédagogie ambulante était à mon avis le meilleur argument en faveur de Linux sur le bureau. Il est vrai que les facilitateurs comme Ubuntu conserveront une bonne valeur ajoutée par rapport à Windows. Il est vrai aussi que les arcanes n’ont jamais cessé d’être abscons.

    Mais les profanes — entendre : tous ceux qui n’achètent pas un ordi pour devenir informaticiens — pouvaient apprendre avec Linux tout ce qu’ils ont besoin de savoir, tout ce qui permet de ne pas être largué devant sa bécane.

    Or, voici qu’au bout de 15 ans d’utilisation, grâce à systemd d’abord, et surtout à la logique de débats d’initiés dont il procède si elle était amenée à s’étendre, je suis bouté hors du système. Un peu comme les bricoleurs sont dépassés par l’électronique des voitures.

    Pas dramatique pour moi, si Arch casse je continuerai avec ma partition Xubuntu et le /home partagé. Mais j’entrevois disparaître le Linux que j’ai connu pédagogique, à forte valeur ajoutée pour l’utilisation familiale. Le Linux passerelle entre les pros et les quidams.

    Linuxien risque de devenir être hacker ou ne pas être.
    La curiosité de ne plus être un droit d’entrée suffisant.
    Le créneau minoritaire de plutôt se réduire que s’agrandir.

    Est-ce un bien, est-ce un mal, je ne trancherai pas.

    • [^] # Re: Loin de la foule

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

      Euh, comprendre le fonctionnement de systemd, c'est à la porté de toute le monde, t'inquiètes que les prochains Linuxiens qui n'ont connu que cela le comprendront, après si tu ne veux pas faire d'effort…

      Bref, c'est plus abordable de comprendre la conf de systemd que de comprendre la syntaxe de bash pour un profane…

      • [^] # Re: Loin de la foule

        Posté par (page perso) . Évalué à  3 . Dernière modification : le 05/09/12 à 14:58

        La syntaxe de bash est-elle même compréhensible.
        Ca me fait rire de lire que le système actuel à coup de bash est compréhensible. Ca l'est que pour les esprits qui se sont fait tordre poru arriver à lire du bash. Pour les autres, systemd a l'air bien plus lisible. Ah la résistance au changement…

        • [^] # Re: Loin de la foule

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

          Je suis assez d'accord.

          Craindre l'arrivée de systemd parce que cela fait 10 ans (ou plus) que l'on utilise et maîtrise sysV, que l'on ne veut pas tout réapprendre et surtout risquer bugs et plantages pour cause de méconnaissance d'une techno neuve, je le comprends tout à fait.

          Après tout, quand ça fonctionne comme on veut, on veut pas que ça change, et je le comprends.

          Mais reporter la faute sur systemd alors que l'on ne connait pas l'outil, est injuste.

          Quel est le problème ? Systemd s'impose ? Et alors ? Lennart a menacé de mort tous les mainteneurs de distros du monde pour passer à son truc ?

          La réalité c'est que les besoins en informatique changent, et que le but d'une distro et de répondre à des besoins plus ou moins divers en fonction de l'orientation du projet. Mais jamais une distro n'a pour objectif de répondre à mon besoin à moi et uniquement le mien.

          Si systemd s'impose c'est peut-être simplement que mes besoins ne sont pas ceux de la plupart des utilisateurs des distros concernées (ou de leurs mainteneurs).

          De plus la situation est loin d'être catastrophique :

          Amoureux des scripts bash ? Systemd est compatible avec les scripts sysV.

          Unixiens pur et dur ? Ça fait longtemps qu'il fallait passer à BSD, et c'est là peut-être l'occasion de s'y mettre.

          Ça me fait penser au fork de Gnome 2 ça. Pourquoi forker Gnome 2 quand XFCE existe ? Pour contrer le sort ? Parce qu'on ne veut pas penser un monde dans lequel Gnome 3 existe ?

          Franchement XFCE et Gnome 2 c'est kif-kif-bourricot. À ceci près que le premier est plus léger et plus freedesktop-compliant (ce qui devrait plaire au unixiens-anti-lennart…).

          Pour le reste Linux et son écosystème n'a jamais été un Unix pur et dur.

          C'est pour ça que je l'aime, son côté "laboratoire" d'idée.

          Alors oui, moi, les systemd, les upstart, les pulseaudio et les Gnome 3, ça me plaît. Les FreeBSD et les jails aussi.

          Y a suffisamment de choix pour que tout le monde soit content non ?

          • [^] # Re: Loin de la foule

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

            Je me suis intéressé à Systemd. Je n’ai pas trouvé de documentation qui me soit accessible.
            Il est possible que la question se réglera pour mon cas personnel.

            Ce n’est pas cela qui m’inquiète. Je me suis formé à Linux quand il démarrait par étapes visibles et bien documentées.

            La meilleure façon de marcher, c’est de mettre un pied devant l’autre. Ça n’a l’air de rien, mais cette progression par étapes de Lilo au choix d’un window manager en passant par le prompt, quand on découvre l’ordinateur, aide énormément pour la suite à situer les éléments les uns par rapport aux autres.

            À l’inverse, je vois beaucoup de profanes totalement perdus quand ils se retrouvent immédiatement devant l’interface de Windows. Ils ne savent pas par quoi commencer devant cette profusion, et ils ne savent pas non plus par quel bout prendre la documentation, quand documentation il y a.

            Quelques années plus tard, ils ont encore besoin d’aide pour retrouver leurs fichiers, dans les cas extrêmes. Tous les cas ne sont pas extrêmes, heureusement. Et certains s’en sortent très bien. Mais que de temps gagné avec Linux !

            Systemd et Pulseaudio m’inquiètent parce qu’ils semblent avant-coureurs d'un fonctionnement sur mode circulaire, comme l’interface de Windows, et je crains qu’à terme Linux devienne inabordable pour le commun des mortels.

            Je ne critique pas cette évolution. Je défendrai bec et ongles qu’il a représenté une formidable opportunité pour le grand public. Mais qui en aura profité ? Il y faut de la curiosité et un concours de circonstances. Ou du marketing.

            Je vous parle d’un temps que les programmeurs ne peuvent pas connaître : l’ordinateur tout nouveau dans le paysage, et qu’il va falloir dompter. Ça vous paraît simple. Pour d’autres c’est plus compliqué.

            Et Linux pouvait leur simplifier la tâche. Hors mézigue, je ne suis pas sûr qu’il ait jamais tenu ce rôle, qui lui allait comme un gant. Alors, peu importe peut-être la disparition de ce potentiel.

            • [^] # Re: Loin de la foule

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

              Je n’ai pas trouvé de documentation qui me soit accessible.

              https://wiki.archlinux.org/index.php/Systemd#Writing_custom_.service_files

              • [^] # Re: Loin de la foule

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

                Sorry, I don't speak English.
                Je connaissais déjà cette page. Et j’en avais trouvé une ou deux autres en Français, pas sur le site d’Arch.
                Il m’est arrivé de déchiffrer d’autres pages in English, pas celle-là.
                Et celles en Français non plus.
                Ça viendra peut-être un jour mais merci quand même.

                • [^] # Re: Loin de la foule

                  Posté par . Évalué à  4 .

                  Oui enfin, pour travailler dans l'informatique, savoir lire l'anglais technique est un peu la base.

                  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                  • [^] # Re: Loin de la foule

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

                    Oui enfin, pour travailler dans l'informatique, savoir lire l'anglais technique est un peu la base.

                    C'est sûr qu'avec une réflexion comme ça, Linux va toucher de plus en plus de monde…
                    Donc si tu cherches un peu, tu verras qu'eqfm ne bosse pas forcément dans l'informatique et que je pense qu'il n'est pas le seul à utiliser Linux et à ne être pas être "informaticien".

                    • [^] # Re: Loin de la foule

                      Posté par . Évalué à  9 .

                      OK, raccourci trop rapide.

                      Je vais préciser ma pensée :
                      « pour administrer un ordinateur, savoir lire l'anglais technique est un peu la base. »

                      Parce que j'ai un peu de mal à voir qui d'autre qu'un admin peut avoir à chercher la doc de Systemd.

                      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                    • [^] # Re: Loin de la foule

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

                      Attend, j'ai l'impression dans dans une faille spatio-temporelle? La on parle bien de systemd, ou d'un utilisateur normal d'ordinateur?

                      Une personne qui utilise Linux n'a pas besoin de bidouiller systemd, et son interface est en français (ou autre, il y a plein de traductions)
                      Une personne qui bidouille Linux en touchant à systemd, ce n'est plus un simple utilisateur de Linux et alors désolé mais ne pas comprendre l’anglais technique ça craint un max quand même. Et dire qu'on se pose encore cette question en 2012, et ben…

                      Bientôt, on demandera à mettre les commentaires pour chaque ligne de code on de conf dans 100 langues plutôt que l'anglais avant que le code soit accepté, comme si on a que ça à foutre…

                      Alors un conseil : avant de s’intéresser à systemd, il vaut mieux apprendre l’anglais de base, c'est autrement plus utile, bien plus important, ne serait-ce que pour voyager un peu en dehors de la France. Drôles de priorités.

                      • [^] # Re: Loin de la foule

                        Posté par (page perso) . Évalué à  4 . Dernière modification : le 06/09/12 à 10:55

                        Une personne qui bidouille Linux en touchant à systemd, ce n'est plus un simple utilisateur de Linux et alors désolé mais ne pas comprendre l’anglais technique ça craint un max quand même. Et dire qu'on se pose encore cette question en 2012, et ben…

                        Ben ouais, je suis un vieux con et un vieux con qui a eu des non-anglophones en formation de programmation. D'ailleurs, c'était à l'époque où Microsoft, comme toi, s'est rendu compte que fournir des supports en français pour les dites-formations est totalement inutile car le programmeur doit connaître l'anglais technique. Enfin, il faut peut-être plus y voir un intérêt économique qu'autre chose.

                        Mais sinon quand toutes les notices d'utilisation seront en chinois, tu diras quoi ? Qu'il est absurde de pas parler le chinois ?

                        Alors un conseil : avant de s’intéresser à systemd, il vaut mieux apprendre l’anglais de base, c'est autrement plus utile, bien plus important, ne serait-ce que pour voyager un peu en dehors de la France.

                        Pour info, en dehors de la France, y a encore plein de pays où on ne parle pas forcément l'anglais et encore moins l'anglais technique.

                        Drôles de priorités.

                        C'est ton avis mais dis-toi que pour d'autres, tu fais de l'informatique plutôt que du VTT alors que le VTT c'est bon pour la santé… Drôle de priorités

                        • [^] # Re: Loin de la foule

                          Posté par (page perso) . Évalué à  3 . Dernière modification : le 06/09/12 à 11:09

                          Mais sinon quand toutes les notices d'utilisation seront en chinois, tu diras quoi ? Qu'il est absurde de pas parler le chinois ?

                          Voila, tu n'as pas d'argument pour ce dont on parle (un élément très technique), tu noies le poisson avec un truc qui n'a rien à voir (des manuel d'utilisation de l'outil).

                          Sinon, si le chinois devient la langue de référence pour la communication internationale, oui il sera absurde de ne pas parler chinois. On n'en est pas la. C'est triste de voir qu'en 2012 on reste encore sur cette idée de ne savoir lire qu'une seule langue est acceptable. Tu m'étonnes que la France perd de sa stature (c'est con, car le français perd même son statut de langue diplomatique).

                          Il n'est pas non plus important de savoir nager. Ni conduire. Mais on peut aussi parler de savoir compter. ça peut être utile aussi, bien plus que systemd traduit pour quelques personnes ne comprenant pas l'anglais. Il y a des domaines primordiaux quand même, nager, conduire, l'anglais de base lu en font partie!

                          • [^] # Re: Loin de la foule

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

                            J’en connais beaucoup dont la scolarité a été perturbée par des raisons x ou y et parfois dès la naissance. Laissons une chance à ceux qui ne sont pas nés avec une cuillère dans la bouche, et n’ont pu acquérir la maîtrise de l’anglais qui en découle. Laissons une chance à ceux qui ont préféré apprendre d’autres langues, en admettant même que le choix leur ait appartenu.

                            • [^] # Re: Loin de la foule

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

                              J’en connais beaucoup dont la scolarité a été perturbée par des raisons x ou y et parfois dès la naissance.

                              Ca empêche d’apprendre plus tard? Ca n'a pourtant pas l'air d’empêcher l'apprentissage de systemd après la scolarités…

                              n’ont pu acquérir la maîtrise de l’anglais qui en découle

                              On ne parle pas de maîtrise, mais de base.

                              Laissons une chance à ceux qui ont préféré apprendre d’autres langues, en admettant même que le choix leur ait appartenu.

                              J'en connais un paquet qui ont préféré d'autres langues. Mais ces personnes ont aussi des bases d’anglais.

                              Va falloir trouver d'autres excuses pour convaincre.

                              • [^] # Re: Loin de la foule

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

                                L’anglais c’est une chose, systemd c’en est une autre, l’écosystème systemd-udev c’en est encore une autre.

                                Oui, des difficultés initiales ou tout simplement des urgences bouffeuses de temps peuvent rendre impossible l’apprentissage tardif de l’anglais. Ne cherche pas à comprendre, ce n’est pas une équation.

                                Et je ne parle pas de mon cas personnel sur ce coup-là.

                                Un anglais de base pour lire de la documentation technique : tu parles sérieusement ?

                                J’en resterai là parce que le journal est axé sur les conséquences de l’interdépendance entre udev et systemd. Faut-il ou non devenir des Zenitram clonés, le sujet m’intéresse déjà moins.

                            • [^] # Re: Loin de la foule

                              Posté par . Évalué à  4 .

                              J’en connais beaucoup dont la scolarité a été perturbée par des raisons x ou y et parfois dès la naissance

                              Je ne savais pas qu'en loupant sa scolarité, on perdait toute chance de s'éduquer par la suite.

                              Grande nouvelle : à l'école, tu n'apprends quasiment rien. Tout ce que je fais aujourd'hui, je l'ai appris sur le tas. Les études ne m'ont servi qu'à apprendre une méthodologie et une façon de travailler.

                              Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                              • [^] # Re: Loin de la foule

                                Posté par . Évalué à  3 .

                                Grande nouvelle : à l'école, tu n'apprends quasiment rien. Tout ce que je fais aujourd'hui, je l'ai appris sur le tas. Les études ne m'ont servi qu'à apprendre une méthodologie et une façon de travailler.

                                C'est vrai à partir du lycée, mais il me semble que ce que tu apprends bettement avant sert de socle, socle particulièrement difficile à rattraper par la suite (il suffit de voir les galères de ceux qui tentent d'apprendre à lire à 30 ans)

                                • [^] # Re: Loin de la foule

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

                                  C'est clairement dur de rattraper la scolarité, oui.
                                  Mais à partir du moment où tu t’intéresse à systemd, on peut considérer que tu as le niveau pour apprendre l'anglais, on est loin de l'apprentissage de la lecture.

                                  Tout est question de priorités…

                                  • [^] # Re: Loin de la foule

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

                                    La question au départ n’était pas l’apprentissage de systemd ou de la lecture, mais celui de l’ordinateur.
                                    Et des répercussions de l’interdépendance entre systemd et udev sur les vertus pédagogiques de Linux. Mais je reconnais que ça peut être un faux problème, vu que dans ma zone je n’ai jamais vu de non-informaticiens, à part moi quand je croise une glace, intéressés par Linux.

                                  • [^] # Re: Loin de la foule

                                    Posté par . Évalué à  1 .

                                    Tu as pensé à traduire le manuel en BD pour ceux qui ne savent pas lire ? C'est horripilant ce centrisme sur les élites qui savent lire ! Tu ferras quoi quand la configuration de Systemd se fera en brainfuck ?

                              • [^] # Re: Loin de la foule

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

                                Entièrement d’accord avec des nuances.

                                Question difficultés sociales, la pente peut être très longue à remonter. Je ne parle pas de moi, mais j’ai eu à côtoyer, voire à m’impliquer. Et dans ces cas-là, ce n’est pas l’anglais qu’il urge d’apprendre, c’est l’écriture du français.

                                À l’école, ce que tu apprends, ce n’est pas seulement ce qu’on t’enseigne. Tu y apprends aussi à te sentir plus ou moins en phase avec la société. Et quand tu es en phase avec ta classe, ta scolarité même si tu es un cancre, avec la société, ça te paraît tellement naturel que tu auras par la suite du mal à mesurer les difficultés de ceux qui n’ont pas eu cette chance.

                                L’essentiel de ce qui t’est utile, tu l’apprends effectivement hors de l’école. Mais le passage plus ou moins réussi à l’école n’est pas sans incidences sur cet apprentissage encore.

                          • [^] # Re: Loin de la foule

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

                            Voila, tu n'as pas d'argument pour ce dont on parle (un élément très technique), tu noies le poisson avec un truc qui n'a rien à voir (des manuel d'utilisation de l'outil).

                            Nous n'étions pas en train de parler de la qualité technique de systemd ou de sa configuration, on est en train de parler de la disponibilité d'une documentation de l'outil donc je n'ai pas d'argument à donner sur l'élément technique.

                            Maintenant crois-tu que parce que quelqu'un ne parle pas anglais, il n'a pas envie de comprendre un peu plus comment son système fonctionne, comme le permet Linux ? Et donc, tu préfères largement dire à cette personne :

                            Arrêtes-toi tout de suite, vas d'abord apprendre l'anglais, c'est vital. Après, tu pourras commencer à administrer un Linux.

                            C'est assez gonflé.

                            Effectivement, d'un point de vue technique, d'après ce que j'ai pu voir, systemd n'est pas horrible à configurer. Cela ne demande pas forcément un grand niveau d'anglais pour comprendre approximativement mais ne pas traduire, c'est fermer la porte à des gens que ça intéresse et qui n'ont pas forcément ton niveau en anglais.

                            C'est triste de voir qu'en 2012 on reste encore sur cette idée de ne savoir lire qu'une seule langue est acceptable. Tu m'étonnes que la France perd de sa stature (c'est con, car le français perd même son statut de langue diplomatique).

                            Là, c'est toi qui rajoute n'importe quoi. Mais si tu veux parler de ça, pas de problème. Combien d'Anglais et d'Américains continuent à étudier le français ? Eux pensent qu'une seule langue est acceptable, tant que c'est la leur. Alors oui, je suis d'accord qu'il faut apprendre l'anglais mais ce n'est pas une obligation.

                            Tu m'étonnes que la France perd de sa stature (c'est con, car le français perd même son statut de langue diplomatique).

                            Tant que des gens auront ton discours, y a pas de raison que ça s'inverse et que la langue française survive puisqu'elle va devenir inutile.

                      • [^] # Re: Loin de la foule

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

                        L’intérêt, pour un non-informaticien, n’est pas de pouvoir bidouiller son système, mais d’en comprendre le fonctionnement pour en tirer le meilleur parti. Pulseaudio, le mariage de raison d’udev et systemd, ça tourne à l’écosystème spaghetti, comme l’interface de Windows. Ça ne facilite pas la compréhension, et partant la prise en main par les non-informaticiens. Je bidouille très peu, uniquement par nécessité et en suivant le guide. Mais tout ce que j’ai appris de Linux m’aide énormément pour utiliser ne serait-ce que LibreOffice.

                  • [^] # Re: Loin de la foule

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

                    Sauf que là il est question de Linux pour les non-informaticiens.

                    • [^] # Re: Loin de la foule

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

                      Les non informaticiens qui vont être perdu sous Linux parce qu'ils ne peuvent plus comprendre le fonctionnement de l'init de leur OS (ce qui de plus est faut)… AH AH AH!

                      • [^] # Re: Loin de la foule

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

                        Ahahahah !! T'as raison, bosses ton anglais parce que là, t'es dans le faux :D

                        En tout cas, j'aime bien ton élitisme qui interdit aux non-informaticiens de s'intéresser au fonctionnement de leur OS.

                      • [^] # Re: Loin de la foule

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

                        Non. Un système d'init qui devient trop complexe pour devenir une porte d’entrée.
                        Moi je m’en fous, j’ai déjà suffisamment de pieds dans le système pour m’en tirer toujours.
                        Mais quand j’y suis entré, c’était quand même bien pratique de savoir par quel bout commencer.
                        Le système d’init, par exemple et pas que lui, était comme un alphabet.
                        Comparativement à Windows où manquait la pierre de Rosette.
                        Systemd + udev n’y enlèvera pas grand-chose immédiatement.
                        Mais à terme…

                        • [^] # Re: Loin de la foule

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

                          J'avoue que je rejoins les autres sur le sujet: en quoi est-ce que la config de systemd te parait plus compliquée que init?

                          Dis-moi si je me trompe: avec sysvinit, on peut aller lire des scripts bash pour savoir ce qu'ils font. Et c'est pareil avec plein d'autres trucs sous Linux: des scripts bash, des commandes shell, on voit tout de suite ce que ça fait.

                          systemd est codé en C. Du coup, on ne "voit pas" ce que ça fait en se baladant dans l'arborescence. On sait que ça utilise les fichiers de config, mais pour en faire quoi? Il faut aller lire le code source…
                          La barrière technique pour lire un source C et le comprendre est plus élevée que pour lire un "bête" script shell.

                          Maintenant, si tu veux retomber en territoire que tu peux appréhender, il va effectivement te falloir lire de la doc. Ça tombe bien, entre tous les journaux et dépêches sur le sujet ici, on peut trouver ce qu'il fait et comment il marche, et tout est expliqué en Français.

                          Enfin, se contenter des scripts init pour comprendre l'init, c'est très réducteur, et finalement, cette facilité cache d'autres éléments importants du processus. Donc grâce à systemd, tu vas pouvoir trouver plus d'infos sur la problématique du lancement des services (démonisation, récupération du PID, tout ça: on peut lire voire écrire des scripts init sans comprendre le problème).

  • # Merci Lennart

    Posté par . Évalué à  10 .

    Merci Lennart, merci udev.
    Merci car j'apprends dorénavant (bon, ça fait un an quand même) à faire la connaissance d'une petite communauté que je trouve géniale : NetBSD.

    Mon opinion ne vaut sûrement rien, mais j'ai une petite envie de m'exprimer (puis pour une fois écrire sur linuxfr)

    Ca fait une bonne dizaine d'années que je touche à du linux, au moins 5 ans à gentoo, système linux que j'aime bien (pour le moment).
    Je ne suis pas admin. pro ( mais dépanne les windows, les linux des autres et administre mes quinzaine de bécanes chez moi) ;
    je ne suis pas développeur pro. (bien que j'automatise mes tâches et que je code pour mon job. pour acquérir des données);
    je suis ce qu'on pourrait appelé un simple petit utilisateur avancé.
    Dans ce contexte je ne peux pas critiquer le job de Lennart bien que j'arrive à comprendre (à peu près) le système d'init. .

    J'ai vecu les périodes chez gentoo avec le passage du Xorg.conf à du xml hal fdi. pour au final revenir à un Xorg.conf.

    J'ai connu ( et je connais ) les systèmes en *kit (avec le mélange polkit/policykit), pour me rendre compte qu'au final ConsoleKit est deprecated.

    Je connais dernièrement, l'arrivée dans l'arbre instable de gentoo une version udev où le support /usr sur une partoche autre que la racine n'est plus supporté… alors que la plupart de la doc. conseille celà. , que mes systèmes sont tous montés de cette manière depuis x années, que je n'utilise pas de initram sur gentoo depuis x années…

    Comme je ne peux pas me plaindre ( je n'ai de toute façon pas droit au chapitre), j'ai fait ce que conseillent les "extrêmistes" boutonneux linuxiens (j'en étais un dans ma prime jeunesse mais c'est fini), je migre pour plus de liberté. Ca me prend du temps, mais j'en suis content.

    Ma seule tentative avec systemd, c'était avec une opensuse au boulot, c'était en gros il y a un ans (oui j'avais voulu laissé la chance à opensuse). Le changement de version 11.4 vers 12.0 c'est mal passé puisque j'ai basculé sous gentoo. Systemd ne lançait pas le système, avec des messages que je ne maitrisais pas; heureusement il y avait encore une possibilité de boot avec l'init sys V. Tout ça pour dire que probablement, c'est un manque d'intégration ( un problème venant de moi-même vous pouvez me dire, mais bon je n'en étais pas à ma première expérience).
    L'histoire de /usr et udev, c'est je crois la chose de trop en tout cas pour moi et pour pas mal d'utilisateurs ( cf. mailing list gentoo et forums).

    Ainsi, mon seul message à propos de systemd/udev, c'est:
    Testez les *BSD.
    Une communauté vraiment sympa. (merci miod, gaston, bapt, imil,…)
    Des systèmes KISS et stables.
    Il y a bien entendu quelques problèmes, mais bon qui n'en a pas ;) ?

    En tout cas merci Lennart, et bon troll!

    • [^] # Re: Merci Lennart

      Posté par . Évalué à  4 .

      Je suis d'accord avec toi. Je trouve cool cette remise en cause. Ça donne l'occasion de se poser des questions (la distribution que j'utilise est-elle vraiment celle qu'il me faut ? devrais-je m'impliquer plus dans ma distribution pour peser sur ses choix ? le système d'exploitation que j'utilise est-il celui qui me convient ?). C'est jamais négatif de se poser ces questions, soit ça permet de trouver mieux soit de réaffirmer les raisons de nos choix.

      Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

      • [^] # Re: Merci Lennart

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

        Je trouve aussi que c'est effectivement une grande occasion pour tester d'autres choses.
        Perso, en 2001, c'est la multitude de variantes d'emplacements de fichiers de configuration sous les différents Linux qui m'a fait passer à FreeBSD 4.2.
        Après, pour ce qui est de systemd, j'ai pas trop d'avis mais effectivement, on est toujours plus à l'aise avec ce que l'on connaît et ça prend un peu la tête de ré-apprendre un énième truc.
        Enfin bon, le jour où j'y serai obligé, je ferai comme les copains parce que, même si j'ai peut-être les connaissances, je n'ai ni l'envie ni le temps de m'amuser à faire et maintenir un fork de quoique ce soit.

    • [^] # Re: Merci Lennart

      Posté par . Évalué à  5 .

      je me retrouve dans ton commentaire.

      Je n'ai pas spécialement envie de me prendre la tête avec la découverte un nouvel OS (et notamment recréer des paquets dont j'ai besoin), mais je crois que j'en ai ma claque de ces fameuses "nouveautés" ou "évolutions" (grub2, *kit, pulseaudio qui n'a jamais marché, et maintenant systemd) qu'il n'est pas possible de refuser sans faire aveux de non-remise en cause de ses habitudes de vieux.

      Aussi quitte à prouver qu'il est toujours possible de changer, je préfère quand même passer à un OS qui me semble plus sain, par exemple FreeBSD via PCBSD, à moins que j'essaye Slackware. À voir. J'avais testé PCBSD il y a quelques temps, ça me paraissait très bien.

      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: Merci Lennart

      Posté par . Évalué à  -2 .

      C'est propre à Gentoo ce problème d'udev et de usr qui peut pas être sur une autre partition?

      Je suis globalement d'accord pour dire que certaines nouvelles techno ont mis plus de temps à mûrir qu'elles n'auraient dû, et que d'autres font carrément du tord à l'utilisateur fidèle/final (je pense à Gnome 2.0, je ne connais pas Gnome 3.0). Cependant, j'apprécie énormément SystemD, que j'ai trouvé très simple à prendre en main, et que je trouve très prometteur.

      Certes, ça va faire du boulot pour les admin, ça obligera peut-être certains de créer leur propre init (pour l'embarqué je croyais que c'était la règle), mais j'ai du mal à voir en quoi il ne réponds pas aux besoins du plus grand nombre, simplement de manière compréhensible.

      Je pense que le mécontentement viens plus de l'admin, qui monitor des applications et surveille le système, qui ne veut surtout pas être emmerder par un truc qui en fait trop, que du développeur qui déteste les forks, les scripts et le code non optimisé.

      • [^] # Re: Merci Lennart

        Posté par . Évalué à  2 .

        C'est propre à Gentoo ce problème d'udev et de usr qui peut pas être sur une autre partition?

        Non, ça semble propre à systemd…

        Pourquoi tout les fans de systemd crachent-ils sur gentoo ?

        • [^] # Re: Merci Lennart

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

          Systemd l'oblige maintenant mais la justification était, lors de la mise en place de cette obligation, que de toute façon ça ne marchait déjà pas (à cause d'udev je crois).

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

          • [^] # Re: Merci Lennart

            Posté par . Évalué à  2 .

            Je réagissais car sur ma gentoo, j’ai un contre exemple. udev marche et j’ai un /usr séparé. Je dois être une exception…

            • [^] # Re: Merci Lennart

              Posté par . Évalué à  1 .

              Quelle version de udev as-tu?
              Es-tu en stable ou instable?
              Si tu es en stable, tu es sur une vieille version de udev et tu peux avoir une partition contenant /usr séparée de celle contenant la racine.
              Si tu utilises l'arbre instable ce n'est plus le cas… et tu auras besoin d'un initramfs.

              D'ailleurs tu as du recevoir la news à propos de udev:
              eselect read list
              news : 2012-03-16-udev-181-unmasking

              • [^] # Re: Merci Lennart

                Posté par . Évalué à  2 .

                Oui, je suis en stable pour udev. Le message que tu pointes, j’ai dû le lire en mars, mais depuis j’avais oublié.

                De quel programme à t’il besoin qui soit dans /usr et qui ne l’était avant ? ou plutôt qu’il n’avait pas besoin avant ?

                • [^] # Re: Merci Lennart

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

                  Les besoins n'ont pas changé. Simplement quand un programme n'était pas encore disponible, udev mettait l'action en attente et la rejouait quand /usr et /var étaient montés. Et ça marchait très bien.

                  Seulement un matin les dévs en ont eu marre et on décidé que c'était "broken" plutôt que se demander si c'était pas leur architecture qui l'était.

        • [^] # Re: Merci Lennart

          Posté par . Évalué à  1 .

          Non, ça semble propre à systemd…

          Pourquoi tout les fans de gentoo crachent-ils sur systemd ?

          Avant de propager des idiotiesFUD, essayes un peu de te renseigner par toi-même : separate usr is broken

          • [^] # Re: Merci Lennart

            Posté par . Évalué à  3 .

            Pourquoi tout les fans de gentoo crachent-ils sur systemd ?

            En fait, j’ai réagi tard sur le sujet. Mais au bout d’un moment, j’en ai eu marre de lire des remarques sur gentoo. Et de lire des gens qui sont passé à GNU/Linux récemment encenser ce genre de chose parce que c’est trop bien, ça ressemble à leur ancien OS.

            Je me sens vieux. Les répertoires /bin et /sbin sont là pour avoir les softs nécessaire au démarrage et /usr (note: ressemble à user), pour tout ce qui n’est utile que lors d’une session utilisateur. Pourquoi casser ça ?

            Les gens quittent Windows parce que pas interropérable… puis, une fois sous GNU/Linux, on fait du Linux, parce que programmer de manière portable demande de la rigueur. Si je n’aime pas systemD, ce n’est pas pour le but (atteint partiellement par l’init gentoo), mais bien la manière de faire. Le libre ne passera jamais plus loin tant que les gens ne feront pas des applis portables.

            Si j’ai été désobligeant avec quelqu’un, je le prie de m’en excuser. Mais je continue à ne pas comprendre l’intérêt.

            • [^] # Re: Merci Lennart

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

              sont passé à GNU/Linux récemment

              Ca fait 13 ans que j'utilise GNU/Linux et c'est pour ça que je fait mon vieux…

              Parce que bon, j'espère que tu charges encore tes clés usb à la main parce que sinon, ca craint, ca ressemble trop à ton ancien OS (si tu l'as utilisé un jour).

              Les répertoires /bin et /sbin sont là pour avoir les softs nécessaire au démarrage et /usr
              (note: ressemble à user), pour tout ce qui n’est utile que lors d’une session utilisateur.
              Pourquoi casser ça ?

              Parce que ca sert plus à rien? On est plus dans les années 70, si c'était fait comme cela, c’était par contrainte, pas parce que c'est plus cool.

              Le libre ne passera jamais plus loin tant que les gens ne feront pas des applis portables.

              Ben va demander à Linus de ne plus rajouter de fonctionnalité dans son OS tant que les BSDs n'ont pas la même fonctionnalité et va demander à la même chose aux BSDistes vis à vis de Linux, tu vas te faire recevoir…

              Systemd n'est pas portable, pas parce que Lennart ne sait pas coder, mais parce que Linux propose des fonctionnalités non POSIX qui sont utilisés par ce dernier.

              • [^] # Re: Merci Lennart

                Posté par . Évalué à  2 .

                Ca fait 13 ans que j'utilise GNU/Linux et c'est pour ça que je fait mon vieux…

                Félicitation, nous avons autant de « bouteille » sous GNU/Linux. Tu peux me rajouter du NextStep, HP-UX à partir de 93.

                Parce que bon, j'espère que tu charges encore tes clés usb à la main parce que sinon, ca craint, ca ressemble trop à ton ancien OS (si tu l'as utilisé un jour).

                Je l’ai très longtemps fait à la main. Parce que je trouvais ça plus simple que le nommage immonde de hotplug. Je ne vois rien de compliqué dans un mount.

                On est plus dans les années 70

                Je suis pas SI vieux ! :'(

                Ben va demander à Linus de ne plus rajouter de fonctionnalité dans son OS tant…

                Je me souviens de l’époque ou le noyaux 2.2 était stable. On y mettait que des corrections. Le 2.3 (deuxième chiffre impair) était la branche instable, dans laquelle on ajoutait les nouvelles fonctionnalités, les changements d’interfaces du noyau… une fois stabilisé, ça devenait la 2.4.

                Puis un jour en 2.6, je ne sais pas pourquoi, la main branche du kernel à commencer à avoir des interfaces mouvantes, parce que le nouveau scheduler est chouette… ça a apporté beaucoup de dynamique à Linux. Les distributions et les lib bas niveau ont suivies. Aujourd’hui, je me demande si ça ne va pas porter préjudice à Linux et GNU/Linux sur le long terme.

                Après, une aproche de type system D est très bien pour des tablettes. Moins bien pour un desktop (c’est mon avis) et pas terrible pour un serveur. Notamment, à cause de cette nouvelle politique de fuite en avant sur les projets. Une faille sur la version n, c’est pas grave, on la corrige sur la n + 3, et on continue. Sauf que pour des grosses boites, il faut être sûr que le changement de version n’induira pas d’effet de bord.

                Faire des drivers, du développement sur des systèmes critiques avec un maximum de briques réutilisables, c’est mon métier. Le soir je ne développe pas pour des projets libres. Aux yeux de certains ici, cette expérience ne vaut rien. Je ne m’étendrai pas plus sur ce sujet. Maintenant, si quelqu’un est prêt à m’offrir un boulot pour faire des drivers libres, des softs sans pertes de salaire, je veux bien. Mais pour ça, il faudrait que je prenne le temps pour le faire et passer moins de temps avec ma famille. Alors, oui, je critique. En ai-je le droit ?

                • [^] # Re: Merci Lennart

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

                  Une faille sur la version n, c’est pas grave, on la corrige sur la n + 3, et on continue.

                  Euh, dans quel monde ?

                  Canonical: 5 ans de support gratuit sur les mises à jour de sécurité
                  Redhat et Suse: J'en sais rien mais plus j'imagine vu que c'est payant

                • [^] # Re: Merci Lennart

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

                  Une faille sur la version n, c’est pas grave, on la corrige sur la n + 3, et on continue. Sauf que pour des grosses boites, il faut être sûr que le changement de version n’induira pas d’effet de bord.

                  Si une grosse boite a besoin de la version n, elle n'aura aucun problème à payer pour le patch. Ceux qui ne corrigent pas sont les mainteneurs principaux, mais la beauté du libre est qu'une grosse boite peut patcher aussi, ou un autre prestataire. Tu es libre.

                  PS : je trouve certes que Mozilla joue un jeu dangereux avec ce non support de vieilles version car il y a plein d'admins prosélytistes qui se retrouvent dans la merde (et eux ne peuvent pas décider de lacher le fric pour payer le patch), mais c'est un choix de la part de Mozilla. Les "grosses boites" comme tu dis ont vachement de mal à sortir leur portefeuille, c'est aussi leur choix, je comprend que Mozilla laisse tomber. Surtout que le monde évolue, et comprend plein de boites qui ont compris qu'il vaut mieux coder des sites standards et faire des projet en "release often" et du coup ça passe vachement mieux maintenant.

              • [^] # Re: Merci Lennart

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

                Parce que ca sert plus à rien? On est plus dans les années 70, si c'était fait comme cela, c’était par contrainte, pas parce que c'est plus cool.

                La séparation bin/sbin était une contrainte de l'époque en effet qui n'a plus vraiment de raison d'être. Par contre séparer le système des applications me semble toujours aussi pertinent.

                • [^] # Re: Merci Lennart

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

                  Par contre séparer le système des applications me semble toujours aussi pertinent.

                  Sur un Unix qui n'a pas de gestionnaire de paquet, ca peut être logique, mais sous GNU/Linux, faut m'expliquer…

                  • [^] # Re: Merci Lennart

                    Posté par . Évalué à  3 . Dernière modification : le 07/09/12 à 12:09

                    Ca veut dire la racine au final, vraiment? C'est le premier système de fichier à être monté, non?
                    Pourquoi ne devrait-on pas mettre l'init /etc, /bin, /sbin la-dedans et dire au noyau de monter /usr comme racine? Au final qu'est-ce cela va changer?
                    Au final, pourquoi garder /usr? Ca sert à rien. Puis pour garder un semblant de bout de compatibilité, faisons un lien symbolique /usr.
                    /usr a perdu son intérêt puisqu'il possédait les données utilisateurs avec les /home…

                    Si je n'ai pas peur de vraiment casser avec l'histoire ( à près tout au diable les vieux râleurs, c'est pas eux qui codent), et que je voudrais rendre linux bien plus agréable, je changerais complètement l'arborescence et les noms! C'est vrai à quoi sert FSH, vraiment?
                    voyons:
                    /boot pour tout ce qui est boot
                    /apps pour toutes les applis
                    /sys pour tout ce qu'a besoin le système pour démarrer (montage, hotplug, etc…)
                    /conf pour tout ce qui est conf
                    /users pour les données utilisateurs
                    /data pour les données du système
                    /dev pour les devices
                    /virt pour tous les systèmes de fichiers noyau…
                    Poussons l'arborescence:
                    /apps/lib
                    /apps/bin
                    et
                    /sys/lib
                    /sys/bin

                    Plus simple, plus comprehensible, ne trouvez-vous pas?

                    … puis si on regarde un peu, ça me rappelle quelquechose…

              • [^] # Re: Merci Lennart

                Posté par . Évalué à  5 .

                Parce que bon, j'espère que tu charges encore tes clés usb à la main

                Étant donné que les mêmes qui poussent systemd aujourd’hui ont joué avec « alors on peut monter les disques amovibles avec HAL, finalement non, finalement si, finalement HAL disparait, mais vous pouvez monter vos clés avec udisk (qui a changé de nom d’exécutable une ou deux fois), finalement non, finalement si » pendant des années, oui, j’ai fini par me décider à monter mes clés usb à la main (ou plutôt me faire un petit script en suid qui faisait ça).

                • [^] # Re: Merci Lennart

                  Posté par . Évalué à  2 .

                  j’ai fini par me décider à monter mes clés usb à la main (ou plutôt me faire un petit script en suid qui faisait ça).

                  pacman -S pmount :)

          • [^] # Re: Merci Lennart

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

            Mais CE N'EST PAS CASSÉ !

            Le /usr (et /var est aussi concerné) séparé fonctionne en ce moment même sur mes machines, avec udev, et sans initrd. Depuis 2006 au moins. Ce qui est mentionné dans ton lien montre effectivement un problème. Mais ça montre un problème dans l'architecture de udev, pas dans le /usr (et /var) séparé.

            Et ça rale beaucoup chez Gentoo avant tout parce que c'était le partitionnement recommandé dans les guides d'installation, donc la plupart des utilisateurs sont dans ce cas.

            • [^] # Re: Merci Lennart

              Posté par . Évalué à  0 .

              Mais CE N'EST PAS CASSÉ !

              Petit extrait du lien :

              The binaries called from these rules are sometimes located on /usr/bin, or link against libraries in /usr/lib, or use data files from /usr/share. If these rules fail udev will proceed with the next one, however later on applications will then not properly detect these udev devices or features of these devices

              Effectivement, c'est de la faute d'udev si un device déclenche une règle et que le binaire correspondant ne peut-être lancé car il se trouve dans /usr qui n'est pas encore monté.

              Ce n'est pas parce que quelque chose tombe en marche 99.9% des cas, qu'il faut en déduire que ça marche tout le temps.

              • [^] # Re: Merci Lennart

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

                Et c'est pas parce que ça marche que c'est pas chiant. Vérifier de manière non automatisable la chose, ça coute du temps. Tu peux voir "mon binaire a besoin de /usr/lib/libtoto.so.3" facilement. Tu peux pas voir "mon binaire lance tel logiciel depuis son code source, ou depuis les régles udevs ou depuis un script bash un soft dans /usr".

                Debian a toujours fait en sorte que ça soit possible, mais ça reste un travail manuel, avec tout les risques que ça comporte ( genre loupé un cas obscur ). Au final, conceptuellement, au lieu d'avoir les choses faites dans l'initrd et dans le système, c'est fait juste à un endroit, ça me parait plus sain.

      • [^] # Re: Merci Lennart

        Posté par . Évalué à  3 .

        /usr is broken par udev dans la version 181.

        Pourquoi?

        C'est voulu car "c'est vieux", "pas d'intérêt", "unmaintainable":

        les arguments sont ici,

        avec une discussion sur la mailing-list de Fedora,

        un point de vue du côté de FreeBSD,

        puis les discussions sans fin sur la mailing-list gentoo,
        avec des remarques intéressantes ici,
        , par là… enfin bref partout!

        Par contre, je suis désolé pour les non anglicistes, je n'ai plus la patience de traduire…

      • [^] # Re: Merci Lennart

        Posté par . Évalué à  3 .

        Je ne crois pas que ça soit un problème de gentoo, mais bien une volonté de faire disparaître /bin et /sbin pour les mettre dans /usr/bin et /usr/sbin.
        De là, mount n'est plus accessible que depuis /usr/bin, et donc tu ne peux pas monter /usr s'il n'est pas déjà monté au préalable.
        Il te reste comme choix de faire une bidouille tordue dans ton initrd (ya déjà une bascule de / puisque tu démarres avec le / de ton initrd, et qu'à un moment du boot tu passes à celui de ton système, mais là il faudra prévoir de déjà avoir monté /usr, et de lui faire suivre la bascule de / !), ou alors d'avoir /usr dans ta partition root.

        Un truc que j'avais fait il y a pas mal d'années, quand je m'amusais avec mes trois machines persos, c'était justement d'avoir le /usr sur le réseau et partagé en NFS, la maintenance du système devient de fait triviale, tu n'as pas à prendre en compte l'espace pris par le système sur une petite machine type serveur qui aurait peu d'espace disque, et ça peut être monté en lecture seule pour apporter plus de sécurité à un firewall ou un serveur par exemple.
        J'ai arrêté de le faire parce que j'ai arrêté d'avoir trois machines utiles allumées en permanence, et que mon serveur est sur une mini machine ARM à consommation réduite, mais donc sans compatibilité binaire avec ma machine perso en x86. Et que ça marche moins bien pour un portable aussi, ça lui enlève sa capacité à être utilisé en déplacement, tout de suite c'est moins utile ^

        Yth.

        • [^] # Re: Merci Lennart

          Posté par . Évalué à  2 .

          Apparemment, en lisant les liens fournis par wolowizard juste au dessus, la bidouille de l'initrd est assez simple à faire, et pourrait largement être automatisée dans les distribs.

          En conclusion on peut utiliser /usr sur une partition différente de /, et avec systemd, mais en utilisant un initrd prévu pour.

          Yth.

          • [^] # Re: Merci Lennart

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

            la bidouille de l'initrd est assez simple à faire

            Euh non, faire un vrai initrd avec des contrôles histoire de pas faire n'importe quoi, c'est pas aussi simple qu'un exemple.

            De plus, dès qu'on a du LVM, du Raid ou du NFS, ça complexifie encore la chose.

            Enfin, il faut refaire l'initrd quand un binaire inclus dedans est mis à jour (utilitaires lvm/raid/nfs par exemple). Sachant que les binaires sont des versions statiques et pas celles qu'on trouve dans /usr.

            Donc oui c'est faisable, mais non ce n'est pas trivial.

          • [^] # Re: Merci Lennart

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

            Ce que dracut peut faire. C'est expliqué ici :

            http://unix.stackexchange.com/questions/18057/dracut-and-separate-usr

            • [^] # Re: Merci Lennart

              Posté par . Évalué à  0 .

              Oui.

              "mode ironique"
              On devrait mettre dracut comme dependance de fonctionnalité à systemd/udev…
              A quand le merge de dracut dans systemd/udev?
              "end mode ironique"

Suivre le flux des commentaires

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