Journal GNOME systemd : et la guerre ne fait que commencer

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
26
19
oct.
2012

Comme l’annonçait gnumdk, GNOME va requérir systemd.

  • Une page sur le wiki GNOME est apparue pour expliciter le fait que les mainteneurs GNOME doivent supporter Linux, et qu’il est libre à eux de travailler pour d’autres plates‐formes. Et même :

GNOME applications are not intended to be fully functional when used outside of environments based on GNOME Shell.

traduction :

Les applications GNOME ne sont pas supposées être pleinement fonctionnelles lorsque utilisées dans des environnements non basés sur GNOME Shell.

  • Bastien Nocera veut faire de systemd une dépendance forcée pour gnome-settings-daemon power plugin.

  • Un contributeur GNOME‐BSD, Antoine Jacoutot, s’en inquiète calmement. Le débat a eu lieu sur cette liste de discussion.

Les discussions en cours confirment ce qui n’était que supposé jusqu’ici. Et, comme le fait remarquer Sebastien Bacher, cela peut aussi impacter des distributions GNU/Linux. Par exemple, Ubuntu.

  • # Alors

    Posté par  (site web personnel) . Évalué à 9. Dernière modification le 20 octobre 2012 à 14:50.

    À noter, quand même, que depuis je suis passé à systemd, et que l’init BSD ne me manque finalement pas.

    Par contre, je ne comprends pas pourquoi Bastien Nocera veut en faire une dépendance forcée. De ce que j’avais lu, systemd doit remplacer gnome-session et ksmserver (pour KDE), et rien n’empêche le projet de continuer à fournir son gestionnaire de session pour les OS sans systemd.

    J’ai loupé un truc ?

    • [^] # Re: Alors

      Posté par  . Évalué à -7.

      oui, que maintenant il ne faudra plus dire GNU/Linux mais GNU/Lennax.

      Le but de systemd c'est uniquement de noyauter les projets libres pour obliger l'utilisation de certaines technologies, pas de booter plus vite.

      « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

      • [^] # Re: Alors

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

        Le but de systemd c'est uniquement de noyauter les projets libres

        Mais vous y croyez tous sérieusement à ces conneries ?
        Ce que j'adore c'est qu'en général ceux qui taillent systemd ne l'utilisent même pas / ne l'ont jamais utilisé.

        De mon côté, j'ai découvert que j'avais un systemd sur mon poste… en lisant la liste des distros l'intégrant dans un troll linuxfr… comme quoi ça change en fait… rien pour la plupart des gens.

        Ma distrib tourne au poil, et c'est surtout ça qui est important.

        • [^] # Re: Alors

          Posté par  . Évalué à 4.

          Mais vous y croyez tous sérieusement à ces conneries ?

          Oui; Nous ne sommes pas dans un monde de bisounours, et l'égo démesuré est assez présent dans le monde du libre.

          Ce que j'adore c'est qu'en général ceux qui taillent systemd ne l'utilisent même pas / ne l'ont jamais utilisé.

          Remarque complètement stupide : je ne veux pas d'Iphone, je critique l'Iphone, et je n'aurais pasle droit de le faire parce que je n'en ai pas ?

          Ce serait encore plus stupide d'en acheter un juste pour avoir le droit de dire que c'est de la merde, ou que ça ne me convient pas.

          La c'est pareil : systemd, je n'en veux pas : je vois très bien ce que c'est, je n'ai pas à m'en servir pour comprendre que c'est pourri.

          Ma distrib tourne au poil, et c'est surtout ça qui est important.

          On en reparlera quand le truc se vautrera lamentablement, ou que tu devras intervenir sur les process de démarrage.

          • [^] # Re: Alors

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

            Pourquoi systemd devrait se nécessairement vautrer lamentablement, et pourquoi ce serait nécessairement douloureux d'intervenir sur les process de démarrage ? Il me semblait que systemd était conçu entre autre pour simplifier la gestion des process et rendre cette tâche moins pénible (moins traditionnelle, mais la tradition n'a rien à avoir avec la pénibilité). Ce qui ne signifie pas que c'est une tentative réussie, mais qui ne signifie pas non plus que c'est une tentative ratée !

            Merci de donner de vrais arguments !

            ce commentaire est sous licence cc by 4 et précédentes

            • [^] # Re: Alors

              Posté par  . Évalué à 3.

              1/ Parce qu'on est vendredi
              2/ Parce que la volonté affichée du développeur de Systemd est de faire du Linux Only
              3/ Parce que à raisonner comme ça on ne fait pas mieux que Microsoft ou Apple
              4/ Parce que GNU/Linux se prétend être un Unix, mais s'en éloigne de plus en plus.

              • [^] # Re: Alors

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

                Bof, c'est Lennart/Linux qui s'en éloigne. GNU se porte très bien, ça fait longtemps que le G de GNOME ne veut plus dire GNU en pratique.

              • [^] # Re: Alors

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

                pour 2 : Il vaut mieux faire du "Linux Only", que du "distro only", c'est plus portable.

              • [^] # Re: Alors

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

                2/ Parce que la volonté affichée du développeur de Systemd est de faire du Linux Only

                Combien de fois il va falloir le dire. Il ne veut juste pas avoir à maintenir les autres OS, au risque de rendre le code incompréhensible. Il ne veut pas de #ifdef pour ne pas le rendre illisible. La manière de gérer systemd pour un autre kernel est donc de forker, et se synchroniser pour récupérer ce qui est indépendant de l'OS. Cela permet à chaque implémentation d'être spécifique, sans rendre le code abscons. De plus, s'il y a des choses à abstraire un minimum pour que la gestion de différents kernels se fasse plus simplement au niveau code, cela m'étonnerait que Lennart refuse les patchs.

                Lennart a fait du code multi-plateforme pour Avahi, et en a tellement souffert qu'il ne veut plus revivre la même chose. Ça peut se comprendre, non ?

                • [^] # Re: Alors

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

                  Ça peut se comprendre, non ?

                  non !

                  Je veux bien admettre qu'il ne veuille pas assurer lui le portage du logiciel. Mais qu'il refuse les patchs est inacceptable.

                  • [^] # Re: Alors

                    Posté par  . Évalué à 10.

                    Mais qu'il refuse les patchs est inacceptable.

                    Pas du tout. Ce qui serait inacceptable, c'est qu'il refuse que tu les appliques. Or jusqu'à preuve du contraire, tu as les sources, tu es libre de patcher et diffuser tes modifications, voire même de forker.

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

                  • [^] # Re: Alors

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

                    Et pourquoi serait-ce inacceptable ? Il y investi déjà beaucoup de temps, et il a déjà la gentillesse de mettre son travail à disposition sous forme gratuite et libre. À moins de signer un contrat avec lui et de le rémunérer, personne ne peut exiger quoique ce soit de lui. C'est ça aussi le libre.

                    Si quelqu'un n'est pas content avec son travail, il n'a qu'à forker et le faire lui-même. On n'est jamais mieux servi que par soit-même.

                    • [^] # Re: Alors

                      Posté par  . Évalué à 10.

                      Il y investi déjà beaucoup de temps, et il a déjà la gentillesse de mettre son travail à disposition sous forme gratuite et libre.

                      trop gentil l'employé de Red Hat qui développe à titre gracieux sur son temps de travail.

                      « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

                      • [^] # Re: Alors

                        Posté par  (site web personnel) . Évalué à 5. Dernière modification le 19 octobre 2012 à 22:50.

                        Cet employé suit les directives de son entreprise. Cette entreprise fait des logiciels Linux. C'est donc normal qu'il favorise Linux dans ses développements.

                        Après, que ce soit un bénévole ou que ce soit une société privé ne change rien au problème. Il(s) fait/font ce qu'il(s) veul(ent). Point.

                  • [^] # Re: Alors

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

                    Donc il me semble qu'il faut arrêter tout le modèle de développement moderne. Parce qu'une branche d'un logiciel dans git, c'est aussi un fork. En gros il demande aux gens de maintenir une branche spécifique à chaque OS pour que le code soit plus simple. Ça te convient mieux ?

                    • [^] # Re: Alors

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

                      Il y a une seule branche Linux pour gérer des dizaines d'architectures. Il suffit de le vouloir et d'organiser son code et son arborescence en conséquence.

                      • [^] # Re: Alors

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

                        Très mauvaise exemple vu que tu reste centré sur Linux.

                        Or, là on parle de Linux et des autres OS et si on suit cette logique, prenons un autre exemple:
                        le driver ext2 linux et le driver ext2 sont il développé au même endroit, réponse: non.

                        Tu vas me dire que le driver dépend de truc propre au noyau, ben ca tombe bien, systemd aussi.

                        • [^] # Re: Alors

                          Posté par  . Évalué à 2.

                          Tu vas me dire que le driver dépend de truc propre au noyau, ben ca tombe bien, systemd aussi.

                          Mince, je croyais que systemd s’exécutait en userland…

                          • [^] # Re: Alors

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

                            Être en userland, ça rends pas les choses portables par magie. Il est ou le port BSD de iptables, ou le port linux de la commande jail ?

                            Systemd utilise des APis propre à linux ( comme les cgroups, udev, mais encore d'autres comme l'api pour charger des modules, selinux ( de façon optionnel ), le systeme de namespace de linux et divers API, une liste avait été posté ). Il est donc aussi dépendant de linux que shorewall ou NetworkManager puisse l'être.

                            Sauf que dans le cas de nm, personne ne se précipite pour faire le taf ( curieusement ) alors que le dev accepte les patchs. Donc oui, râler sur "on refuse les patchs", c'est joli. Mais en pratique, personne ne fait le taf quand même. Autant arrêter l'hypocrisie. Sans cgroups, systemd ne marche pas. Donc y a aucun sens à faire le portage tant que ça manque sur les autres noyaux.

                  • [^] # Re: Alors

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

                    Mais qu'il refuse les patchs est inacceptable.

                    J'aurais peut-être utilisé un autre mot, comme "paresseux", après tout, il y a la possibilité de faire du code multiplateforme sans trop de #ifdef (inclusion conditionnelle de fichiers plateform-specific), mais "inacceptable", j'ai un peu de mal avec cette notion dans un modèle de développement libre où chacun a le droit de coder "ce qu'il veut".
                    En tout cas, que ça soit inacceptable pour toi, ça on l'a bien compris :)

                    • [^] # Re: Alors

                      Posté par  . Évalué à 8.

                      chacun a le droit de coder ce qu'il veut.

                      Mais quand on veut être la prochaine pierre angulaire des distributions, on est plus le petit développeur qui code dans son coin pendant son temps perso non plus.

                      Maintenance et portabilité ne sont pas antinomiques non plus. Un certain nombre de code ont réussi a combiner les deux.

                      Mais visiblement le lennart c'est comme du apple "ceci est une révolution, il faut tout changer" mais la façon de faire du code…

                      • [^] # Re: Alors

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

                        Alors j'aimerais que tu m'expliques comment autant de développeurs/mainteneurs/distribs utilisent son boulot ? Manque de lucidité ?

                        • [^] # Re: Alors

                          Posté par  . Évalué à 1.

                          temps/volonte/s'en tape royal/etc

                          • [^] # Re: Alors

                            Posté par  . Évalué à 3.

                            Tu pense que des gars qui maintiennent sysintv dans Fedora, Maegia, Arch ou je ne sais qu'elle autre distrib' sont du genre à s'en foutre ? C'est eux qui mangent les rapports de bugs de sysintv ou de systemd, c'est eux qui font le vrais boulot de SAV, c'est eux qui vont réellement se rendre compte si systemd pose problème ou pas.

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

                  • [^] # Re: Alors

                    Posté par  . Évalué à -2.

                    Mais qu'il refuse les patchs est inacceptable.

                    Cool, je me demandais comment j'allais pouvoir répandre mon rootkit.

                  • [^] # Re: Alors

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

                    Mais qu'il refuse les patchs est inacceptable.

                    Euh, t'as déjà bossé sur un projet libre toi ? Il me semblait que oui pourtant…

          • [^] # Re: Alors

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

            Perso, j'ai déjà eu un souci sur systemd avec la version de dev de Fedora. Et c'était pas plus douloureux que n'importe quel plantage d'un truc au boot ( genre, sshd se lance pas ). Dracut m'a filé un shell, j'ai regardé ce qu'il y a eu comme souci ( à savoir systemd qui plante au démarrage ), le bug était déjà remonté sur le bugzilla, j'ai fait un rollback, et j'ai attendu l'upgrade.

            Donc parfait, on peut en parler ( en tout cas, moi, je peux, toi, je sais pas ). Rappelle moi, ton expérience avec le sujet est ?

            • [^] # Re: Alors

              Posté par  . Évalué à -4.

              ahaha lol.

              hum pardon.

              ca c'est un système d'init fiable. certaines upgrades empêche de démarrer certains services…

              • [^] # Re: Alors

                Posté par  . Évalué à 4.

                ca c'est un système d'init fiable. certaines upgrades empêche de démarrer certains services…

                "j'ai déjà eu un souci sur systemd avec la version de dev de Fedora". Je crois que tout les OS en branche dev que j'ai eu sont parti en miette un jour ou l'autre. C'est un peu fait pour ça. Qui plus est avec Fedora qui pousse énormément de technos et changement. Ce me semble pas un critère très fiable pour juger de quelque chose, que les branches de dev ca casse c'est pas une breaking news.

                Maintenant si tu arrives à analyser la situation et pouvoir tirer un jugement objectif de son message tu es très très fort.

                • [^] # Re: Alors

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

                  sauf qu'avec sysvinit, tu n'est pas obligé d'attendre un nouveau binaire ou de downgrader. Tu peux modifier les script shell. Et ça, pour un sysadmin, c'est une énorme différence.

                  Au rythme ou ça va, Linux sera comme windows. Au moindre pépin faudra tout réinstaller !

                  • [^] # Re: Alors

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

                    C'est vrai que si la version fourni par ta distrib du shell utilisé à l'init fait un segfault (ou toute lib qu'il utilise), c'est vrai que ca va vachement t'aider.

                    • [^] # Re: Alors

                      Posté par  . Évalué à 3.

                      J'ai déjà eu un shell qui plante¹, et ce n'est pas aussi grave que tu ne le pense. En particulier, sysvinit n'utilise pas de shell pour lancer les getty.

                      ¹: Ce n'était pas un bug du shell, mais une corruption de son binaire.

                      • [^] # Re: Alors

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

                        J'ai pas dit que c'était grave, j'ai dis que c'était équivalent à systemd qui se foire.

                  • [^] # Re: Alors

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

                    Non, l'équivalent serait d'avoir init qui segfault en lisant /etc/inittab. ( et en fait, la seule raison pour laquelle init ne segfault pas, c'est parce que personne n'y touche jamais )

                    Enfin, j'étais la lors du souci, et je pense toi non, donc tu m'excuseras de pouvoir dire si c'était dur ou pas, et toi, de pas avoir la moindre légitimité à ce sujet.

              • [^] # Re: Alors

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

                Non, c'est vrai que cela n'arrive jamais avec une distrib de dev…

                Des plantages de script d'init, j'en ai eu sous Mandrake cooker, Fedora, ArchLinux…

              • [^] # Re: Alors

                Posté par  . Évalué à 3.

                ca c'est un système d'init fiable. certaines upgrades empêche de démarrer certains services…

                C'est clair que systemd n'a pas 30 ans de maturité. D'ailleurs, il ne les aura pas avant une trentaine d'années. Je vois pas en quoi c'est un problème qu'un logiciel aussi jeune ai des bugs. Oui même s'il est hyper important pour le système. Linux aussi a des bugs.

                Le problème serait plutôt d'essayer de comprendre pourquoi les gens qui prennent des distribution bleding edge ne comprennent pas qu'ils acceptent de facto d'avoir des logiciels qui peuvent avoir des bug et qui n'ont pas forcément quelques dizaines d'années de maturité.

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

          • [^] # Re: Alors

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

            Mais vous y croyez tous sérieusement à ces conneries ?

            Oui; Nous ne sommes pas dans un monde de bisounours, et l'égo démesuré est assez présent dans le monde du libre.

            Oué enfin là c'est plus une histoire de bisounours c'est croire qu'il écrit volontairement de la merde (il faudrait déjà le prouver) juste pour dominer ?
            Mouai…

            je vois très bien ce que c'est

            Pourrais-je en douter ?
            Car ce que je voulais dire au fond c'est que la majorité des critiques sont "ouin lennart il en fait que ce qu'il veut" et n'ont pas la moindre once d'objectivité.
            On entend/lit partout "systemd say de la marde ca pe po marcher, au mieux tomber en marche"
            Et sur ce point, ben non. Où sont les personnes qui ont de vrai problème avec ?
            Sur mon poste je ne m'en suis même pas rendu compte qu'il fonctionnait tellement c'est transparent pour l'utilisateur.

            Mais une remarque bien générale : si vous n'êtes pas content de systemd, commencez par aller discuter avec les mainteneurs des distributions que vous utilisez, il semble que beaucoup ne soient pas du tout du même avis que vous. Et si vraiment ça ne va pas, sortez-vous les doigts et faites autre chose.
            En attendant y'a quand même pas grand monde qui propose autre chose, et en dehors des trolls y'a pas beaucoup d'arguments sérieux contre ce qu'il fait.

        • [^] # Re: Alors

          Posté par  . Évalué à 10.

          Je préfère préciser que je ne connais pas systemd en profondeur avant toute chose, donc loin de moi l'idée de critiquer la chose (visiblement, on a vite fait d'être catalogué comme hyper-résistant au changement, ou comme raleur professionnel à la moindre critique donc je prends les devants !).

          Mais il faut quand même distinguer 2 choses :
          A) avoir systemd sur son système et le fait que ça boote normalement
          B) l'administrer au jour le jour (avec des cas un peu louches)

          Pour A), j'ai envie de dire : heureusement ;) C'est quand même la moindre des choses, sinon j'imagine qu'il n'y aurait même pas débat possible sur systemd.

          Quand je boote un Windows, il fonctionne ! Idem avec une Fedora 17/systemd, et idem avec une Debian Squeeze/sysvinit. Plus ou moins vite peut être, mais ça boote. Dois-je en déduire que tout est parfait pour autant sous le capot ?

          Par contre, pour B), quand j'ai un problème au démarrage, sous Windows, je suis perdu. J'ai beau chercher à droite et à gauche, essayer de refaire la chaine de boot, je ne m'en sors pas (certainement à cause d'un manque de connaissances, certes).

          Avec sysvinit (ou l'init bsd), je peux bricoler, faire des trucs hyper sales, mettre des echo, des exit, des tests… je débuggue, et une fois mis la main sur le problème, j'enlève et je patche proprement.

          J'ai l'impression que les gens avec systemd ont peur de perdre un peu de ce contrôle. Moi le premier d'ailleurs. Mais peut être qu'on peut s'en sortir aussi facilement qu'avec un init classique. C'est parfait, ArchLinux (la distrib que j'utilise) vient d'y passer, je vais pouvoir m'y frotter de plus près, et me faire mon propre avis.

          Mais en tout cas, si je me contente de rajouter un init=/usr/lib/systemd/systemd à mon kernel, et que par magie, je retrouve mon espace de travail, je ne vais pas pour autant me dire "Roh là là ces trolleurs de linuxfr, ils y entendent rien, ça fonctionne parfaitement systemd !".

          • [^] # Re: Alors

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

            Euh, si t'as une erreur au boot avec systemd, tu ne modifies rien, tu lance journalctl et tu regardes ce qui s'est passé.

        • [^] # Re: Alors

          Posté par  . Évalué à 8.

          Mais vous y croyez tous sérieusement à ces conneries ?

          Que Redhat a tout interet a controler cette brique de base du systeme, oui!
          Que Redhat ne voit pas d'inconvenient a en faire une dependence de plein d'autres projets, les rendent doucement Linux-only, oui!
          Que Redhat trouve tres bien que les projects "concurrents" perdent du temps a redevelopper des dependences/libs pour remplacer systemd au lieu d'investir du temps et de l'argent sur autre chose, oui!

          Apres, au niveau purement technique, systemd c'est tres bien mais un peu jeune. Du coup il y a encore plein de choses qu'il ne peut pas tout a faire encore remplacer (voir les longues discussions ici-meme a ce sujet avec des exemples). Ca va s'ameliorer avec le temps bien sur, et ca ne fait aucun doute que tout ces cas seront pris en compte un jour.

          Par ailleurs, systemd a un ensemble de dependences important et un bootstrap complique (c'est pas forcement entierement voulu, mais si ca complique la vie des autres et donne un avantage a l'employeur des mainteneurs, c'est pas forcement negatif, hein). Cette tendance a tout vouloir regrouper ne plait pas a certains. Moi ca me derange pas tant que du travail est fait pour ameliorer les choses et essayer de minimiser les problemes (ce qui ne semble pas encore etre trop le cas malheureusement).

          Ce que j'adore c'est qu'en général ceux qui taillent systemd ne l'utilisent même pas / ne l'ont jamais utilisé.

          En fait le probleme c'est qu'on a d'un cote des gens qui critiquent l'aspect politique (et une petit partie qui pointent les faiblesses techniques mais non redhibitoires, mais c'est perdu dans le flot de critiques) et de l'autre des supporters qui repondent uniquement sur l'aspect technique. Forcement, ca ne mene a rien.

          • [^] # Re: Alors

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

            En fait le probleme c'est qu'on a d'un cote des gens qui critiquent l'aspect politique (et une petit partie qui pointent les faiblesses techniques mais non redhibitoires, mais c'est perdu dans le flot de critiques) et de l'autre des supporters qui repondent uniquement sur l'aspect technique. Forcement, ca ne mene a rien.

            Il suffit de poser la question.

            Pour le côté technique :
            Est-ce que je pense que SystemD fait bien son job ? Oui. Est-ce que je pense que c'est surtout les habitudes et la peur du changemement qui font que certaines personnes ne veulent pas l'adopter ? Oui.

            Pour le côté politique:
            Est-ce que l'influence croissante de Red Hat sur le projet GNOME me gêne ? Oui. Forcément quand un certain nombre de systèmes sont maintenus par des gens embauchés par Red Hat, ça rend plus sensible aux décisions desdits mainteneurs. Encore que je ne pense pas que leur choix soit déterminé par leurs employeurs sur ce point.

          • [^] # Re: Alors

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

            J'aime bien les théories du complot, mais j'ai pris gout à des théories plus sophistiqués et qui tiennent pas avec des bouts de ficelles et ou on voit en 3 lignes le truc, donc tu m'excuseras de faire 2/3 remarques sur tes croyances.

            Que Redhat a tout intérêt a contrôler cette brique de base du système, oui!

            L'init classique des distros rpms, tu crois que ça venait d'ou ?

            Le paquet initscript de mandriva, c'etait un fork de celui de fedora….
            Au passage, je te ferait remarquer la présence de la dite société dans

            Que Redhat ne voit pas d'inconvenient a en faire une dependence de plein d'autres projets, les rendent doucement
            Linux-only, oui!

            Plein ? Pour le moment, c'est la gestion de l’énergie dans gnome.

            Et le mainteneur Solaris explique bien que le code est déjà linux only
            https://mail.gnome.org/archives/desktop-devel-list/2012-October/msg00081.html

            Les gens réclament des interfaces freedesktop, mais c'est exactement de ça qu'il s'agit, à savoir d'une interface freedesktop , celle de logind pour remplacer l'interface via consolekit, qui n'était pas portable sur netbsd ou openbsd, ou windows, ou le hurd, donc la portabilité était déjà absente. Ou celle via upower, qui devait être sans doute aussi trés linux only. J'ai vérifié, y a grosso modo 10 000 lignes de code C dans systemd-logind. Pour comparaison, telepathy-gabble (qui traine à coté sur mon disque ) fait 99 000 lignes de code.

            Alors peut être que les gens voudraient avoir une interface différente, et ça a été discuté sur https://bugzilla.gnome.org/show_bug.cgi?id=680689

            De ce que je voit, le but est d'avoir un démon qui gère "je suis connecté, j'ai besoin de bloquer le suspend". Rien de transcendantalement complexe à refaire.

            Que Redhat trouve très bien que les projects "concurrents" perdent du temps a redevelopper des dependences/libs
            pour remplacer systemd au lieu d'investir du temps et de l'argent sur autre chose, oui!

            Systemd est :
            - en GPL/MIT
            - avec le code source dispo
            - avec de la doc ( en plus du code ) sur l'interface utilisé
            - développé de manière ouverte

            Ça ne prone pas en faveur d'une tentative de maximiser le temps perdu pour les autres projets.

            En fait, c'est la le noeud de la théorie. Si les gens utilisent systemd, alors ç'est en faveur de RH car d'aprés toi, ça donne du controle, donc RH devrait tout faire tout pour. Mais si les gens passent du temps à éviter systemd et à la refaire, alors c'est selon toi aussi en la faveur de la boite car ils perdent du temps.

            Mais attends, y a mieux. RH pourrait prendre le code d'un concurrent ( genre celui d'upstart ) et le mettre dans son produit, comme ça, la charge de maintenance est pas pour eux, et donc ils y gagnent sur le long terme.

            OU RH pourrait garder du vieux code, comme ça, ils peuvent vendre du support sur un truc qui ne bouge pas, donc les couts sont réduits, donc ils y gagnent.

            En fait, pousser systemd partout, pousser systemd juste sur Fedora, garder init, pousser upstart, dans tout les cas, on peut trouver un moyen de dire que RH va y gagner. À partir de la, si pour tout X, Y est vrai, est ce qu'on peut pas simplement déduire qu'il y a pas de relation de cause à effet entre X et Y ?

            • [^] # Re: Alors

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

              Pour le moment, c'est la gestion de l’énergie dans gnome.

              Ce qui gêne les gens c'est le "pour le moment". On ne va pas se voiler la face: si le mainteneur d'un module central décide de passer à systemd et d'abandonner les anciennes méthodes, c'est la porte ouverte à une utilisation massive. Ce n'est techniquement pas un mal, mais cela envoie un signal négatif à ceux qui veulent GNOME sur autre chose que du Linux, ou aux Linux qui n'ont pas le temps ou l'envie de passer à systemd. Rajouter une charge de boulot à d'autres personnes, ce n'est jamais fun pour elles.

          • [^] # Re: Alors

            Posté par  . Évalué à 1.

            Que Redhat ne voit pas d'inconvenient a en faire une dependence de plein d'autres projets, les rendent doucement Linux-only, oui!

            Pourquoi ? Tu pense que BSD fais de la concurrence à RH ? Ou alors tu crois que Solaris ou AIX (ou je ne sais quel autre unix) seraient prêt à changer leur init ?

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

      • [^] # Re: Alors

        Posté par  . Évalué à 10.

        Il parait même que le but ultime de lennart est d'imposer le Communisme pour manger des enfants

        Ca va ta parano ?

        • [^] # Re: Alors

          Posté par  . Évalué à 6.

          N'importe quoi!
          Il veut imposer la pédophilie et manger des communistes!

      • [^] # Re: Alors

        Posté par  (site web personnel) . Évalué à 8. Dernière modification le 19 octobre 2012 à 16:03.

        Perso, j'espère bien que KDE 5 pensera à regarder du coté de systemd pour avoir un gestionnaire de session alternatif.

        Et avoir mes logs utilisateurs de l'ensemble des mes applications accessibles dans journald avec les possibilités de filtrage plutot qu'un gros .xsession-errors bien dégueulasse, je suis pas contre.

        • [^] # Re: Alors

          Posté par  . Évalué à 10.

          Perso, j'espère bien que KDE 5 pensera à regarder du coté de systemd pour avoir un gestionnaire de session alternatif.

          Heu, pourquoi ? J’espère au contraire que KDE restera portable… au point d’être disponible sur BSD, windows, MAC et même GNU/Linux.

          • [^] # Re: Alors

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

            Parce que continuer à fournir ksmserver pour les autres OS avec un ifdef dans le cmake, c'est pas très dur…

        • [^] # Re: Alors

          Posté par  . Évalué à 2.

          Rien ne t'empêche d'avoir un log unifié plutôt que ~.xsession-errors. C'est une option standard de xdm (et kdm, gdm je ne sais pas). Tu dois pouvoir rediriger vers journald (jamais essayé).

          "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

          • [^] # Re: Alors

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

            Tu ne dois pas bien comprendre comment fonctionne journald…Si systemd ne control pas le lancement des applications, alors la recherche sera aussi pourri qu'avec .xsesssion-errors.

            • [^] # Re: Alors

              Posté par  . Évalué à 3.

              Il était tard, j'ai pas réfléchi, confondu journald et syslogd, et répondu à une partie de ton problème (remplacer .xsession-errors). ;-) En plus y'avait du brouillard dehors! Et mes 42 nains de jardin s'étaient échappés! J'avais pas toute ma tête quoi!

              "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: Alors

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

        Le but de systemd c'est uniquement de noyauter les projets libres pour obliger l'utilisation de certaines
        technologies, pas de booter plus vite.

        En fait, le seul truc vrai, c'est la fin. le but n'est pas de booter plus vite.

        Pour le reste, même en relisant lentement, je pige pas, le but serait d'imposer l'usage d'une technologie afin de ?

        D'obtenir plus de richesses ?

        Plus de pouvoir ?
        Faire taire les opposants politiques ?

        Un vendor lockin autour du système de boot, ce qui bloquerais toute alternative ?

        Je doit pas avoir assez d'imagination, mais c'est sans doute le fruit d'un lavage de cerveau du à mon installation de Fedora sur mon portable, sinon je verrais la guerre en cours, avec tous les morts que ça entraine, tout ces gens qui ont donnés de leur vie pour que gnome soit sans systemd.

        • [^] # Re: Alors

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

          Plus de pouvoir ?

          Pour RedHat, certainement.

          • [^] # Re: Alors

            Posté par  . Évalué à 8.

            Un init pour les gouverner tous, un init pour les trouver, un init pour les amener tous et dans les ténèbres les lier…

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

          • [^] # Re: Alors

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

            C'est pas systemd qui va changer grand chose, si avoir du code libre donne un pouvoir énorme, c'est déjà trop tard :
            http://community.redhat.com/contributions/

            Et je me souviens pas avoir vu personne dire "mandriva va avoir plus de pouvoir avec pinit", ni l'équivalent avec arch, gentoo ou même Ubuntu avec upstart ( upstart qui a été mis sur rhel, sur fedora, et sur divers distros à l'époque ).

      • [^] # Re: Alors

        Posté par  . Évalué à 5.

        Oui, et en fait, Lennart Poettering est un franc-maçon sioniste illuminati.
        Il commence par les projets libres, mais son équipe travaille sur le contrôle du mooooonde!

        • [^] # Re: Alors

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

          personellement, j'ai hâte de pouvoir faire

          systemctl disable capitalism.service

          \Ö<

          • [^] # Re: Alors

            Posté par  (Mastodon) . Évalué à 3. Dernière modification le 19 octobre 2012 à 20:10.

            Tu peux déjà faire un systemctl enable communism.service
            mais le résultat n'est pas garanti (et puis, le soft ne semble plus trop maintenu)

            • [^] # Re: Alors

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

              Depuis qu'il a eu des plantages assez sales ?

              • [^] # Re: Alors

                Posté par  (site web personnel) . Évalué à 7. Dernière modification le 19 octobre 2012 à 20:22.

                c'est là qu'on voit que le système de dépendance est mal fait. Quand j'utilise mes propres scripts, je ne suis pas obligé d'utiliser soit capitalism, qui gère très mal les ressources, soit communism, qui est beaucoup trop contraignant. j'utilise un script fait à la main, anarchism, qui est à la fois kiss, souple, rapide et léger.

                \Ö<

    • [^] # Re: Alors

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

      Ben je connais pas ConsoleKit mais visiblement on parle bien de cela => "login sessions"

      Ce qui explique que la même problématique se pour gnome-shell.

      A noter au passage, sur freedesktop.org

      ConsoleKit is currently not actively maintained. The focus has shifted to the built-in seat/user/session management of Software/systemd called systemd-loginctl

      • [^] # Re: Alors

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

        Magnifique, on a maintenant des piles de lennarteries, qui non content d'être par définition incompréhensibles au commun des administrateurs Unix spécialisés, sont en plus en train de prendre la poussière pendant qu'il en entasse de nouvelles.

        Je ne sais pas vous, mais quand j'ai une assiette sale, je la lave, plutôt que d'en acheter une autre. Même si c'est une assiette à 42 fonctions conçue par moi et que je suis le seul à comprendre comment elle marche. Surtout si c'est le cas, en fait.

        • [^] # Re: Alors

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

          En quoi consolekit est un produit de lennart ?

          L'auteur initial est "William Jon McCann", en 2006. ( http://cgit.freedesktop.org/ConsoleKit/log/?ofs=350 )

          Ne serais pas tes lunettes qu'il faut laver plutôt que tes assiettes ?

          • [^] # Re: Alors

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

            Ce n'est peut-être pas de Lennart, mais c'est tout à fait dans le style, tous ces BiduleKit.

            • [^] # Re: Alors

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

              Tout ça parce que ça fini par Kit ?
              T'as pas un meilleur argument ?

              • [^] # Re: Alors

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

                Eh bien déjà, c'est quoi ConsoleKit par rapport à PolicyKit ?

                • [^] # Re: Alors

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

                  A ce que j'ai compris

                  consoleKit utilise policykit

                  policykit est un outil global pour gérer les permissions
                  consolekit permet de gérer les permissions aux niveaux d'une session utilisateur

                  Par exemple, si je veux démarrer une machine virtuelle avec virt-manager/libvirt le processus est le suivant :
                  Démarrage de virt-manager
                  Connexion de virt-manager au démon libvirt
                  Libvirt demande une autorisation
                  Policykit informe le processus qu'une autorisation a été défini pour m'autoriser à me connecter à libvirt
                  Libvirt va demander à l'agent consolekit de m'authentifier (si l'authentification a déjà été fait auparavant rien se passe (suivant les paramètres définis), ou sinon m'affiche une fenêtre où pour entrer le mot de passe nécessaire
                  Consolekit avertit policykit que l'autorisation est faite
                  Policykit renvoit le feu vert à libvirt
                  Virt-manager est connecté à libvirt, je peux avori accés à mes VMs.

                  • [^] # Re: Alors

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

                    non, c'est pas exactement ça. Policykit demande a un agent , agent qui va demander le mot de passe ou la méthode d'autorisation ( soit mot de passe de l'user, soit root, soit autre chose, c'est souple ). Ensuite, polkit peut aussi décider en se basant sur consolekit ( genre "le droit de regler l'heure est dispo pour la personne connecté physiquement sur la machine sans mot de passe" ).

                    Consolekit, il gère juste qui est connecté sur la machine, sur un tty, graphiquement, etc ( http://www.freedesktop.org/software/ConsoleKit/doc/ConsoleKit.html ). Voir par exemple la sortie de ck-list-sessions

                    Parmi l'usage, ça permet notamment de couper le son quand on change d'user ( fast user switching ), de savoir si un utilisateur est connecté en ssh, en tty ou en graphique et d'agir en conséquence ( l'usage en ssh ne donne pas accès à la carte son si quelqu'un est déjà la, pour des questions évidentes d'accès en lecture ( micro, etc )).
                    Le but étant de gérer de façon plus intelligente que les simples droits unix les problématiques comme "qui a l'accès au clavier à un temps T, à qui je file la clé usb qui vient d'être branché, etc". Des trucs que windows ou os x gère depuis toujours de façon cohérente pour l'utilisateur ( comment, je sais pas ).

                    Policykit permet de faire des trucs relativement sympas, comme dire "seul les gens de tel groupe peuvent administrer les vms en local", ou bloquer le fait de partager la connexion en wifi sauf si on file le mot de passe root. Ça permet à l'admin d'un poste client de vraiment regler au poil, même si tout n'utilise pas encore ça, et même si je trouve que parfois, c'est pas assez granulaire. Mais les bases sont la.

                    • [^] # Re: Alors

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

                      Consolekit, il gère juste qui est connecté sur la machine, sur un tty, graphiquement, etc ( http://www.freedesktop.org/software/ConsoleKit/doc/ConsoleKit.html ). Voir par exemple la sortie de ck-list-sessions

                      On a réinventé les commandes who et w, c'est ça ?

                      ( fast user switching )

                      C'est quoi ça, taper Ctrl + Alt + Fx pour aller sur une autre console et se loguer en tant que quelqu'un d'autre ?

                      Policykit permet de faire des trucs relativement sympas, comme dire "seul les gens de tel groupe peuvent administrer les vms en local", ou bloquer le fait de partager la connexion en wifi sauf si on file le mot de passe root. Ça permet à l'admin d'un poste client de vraiment regler au poil, même si tout n'utilise pas encore ça, et même si je trouve que parfois, c'est pas assez granulaire. Mais les bases sont la.

                      Et tu connais des administrateurs qui utilisent ces possibilités ?

                      • [^] # Re: Alors

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

                        Et tu connais des administrateurs qui utilisent ces possibilités ?

                        ben comme expliqué plus haut, je l'utilise :)

                        Sinon, beaucoup de monde (sans forcément le savoir).
                        Le fait que les utilisateurs puissent définir des connexions ethernet/wifi avec NetworkManager est lié aux permissions définies par PolicyKit.
                        (le fichier en question s'appelle chez moi : /etc/polkit-1/localauthority/10-vendor.d/01-org.freedesktop.NetworkManager.settings.modify.system.pkla)

                        Par contre Misc, il y a un truc que je ne comprends pas très bien tant ton explication :
                        Quels sont les autres agents d'authentifications de policykit si ce n'est pas l'agent de consolekit ?

                        • [^] # Re: Alors

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

                          Y a un agent dans gnome, un dans gnome-shell, un pour kde. Par agent d'authentification, faut comprendre "popup qui demande le mot de passe", y a rien de compliqué.

                          Moi sur une Fedora, j'ai un rpm polkit-gnome, mais il y a aussi polkit-kde, polkit-qt, lxpolkit pour que le look and feel colle.

                      • [^] # Re: Alors

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

                        On a réinventé les commandes who et w, c'est ça ?

                        Consolekit gère aussi les permissions.
                        https://wiki.archlinux.org/index.php/ConsoleKit

                        C'est quoi ça, taper Ctrl + Alt + Fx pour aller sur une autre console et se loguer en tant que quelqu'un d'autre ?

                        Le bouton "changer d'utilisateur" dans gnome/kde ou autre, qui va verrouiller ta session, couper la musique et s'assurer que l'autre personne puisse accéder aux clés usb en local pendant que tu es pas en face, entre autre. une feature que windows xp propose depuis le début, au passage.

                        Et tu connais des administrateurs qui utilisent ces possibilités ?

                        Moi, et je le prouve :

                        http://svnweb.mageia.org/adm/puppet/modules/libvirtd/templates/50-template-libvirt-remote-access.pkla?revision=985&view=markup

                        template issue de la config puppet du projet mageia, pour dire "tel personnes dans tel groupe ldap ont le droit de lancer virt-manager pour couper les bécanes ou de les relancer sans avoir les droits root". S

                        inon, tu as aussi des gens qui laissent les utilisateurs faire les updates sans mot de passes via packagekit ( sauf erreur de ma part, c'est le cas au boulot même si j'ai pas la bécane sous la main pour vérifier ).

                        • [^] # Re: Alors

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

                          tu as aussi des gens qui laissent les utilisateurs faire les updates sans mot de passes via
                          packagekit

                          C'est le comportement par défaut de apper sous ArchLinux.

              • [^] # Re: Alors

                Posté par  . Évalué à 1.

                Nan mais ça rime avec rootkit, c'est donc forcément mauvais.

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

              • [^] # Re: Alors

                Posté par  . Évalué à 1.

                lennart est juste fan de K2000

            • [^] # Re: Alors

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

              Tu as lu le code, ou tu te bases sur la terminaison en *Kit?

            • [^] # Re: Alors

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

              Le truc est que consolekit ne pouvait pas fonctionner (dixit un dev ArchLinux), seul un init comme systemd pouvait lui permettre de faire le boulot et du coup lennart a fait un autre outils directement intégré à systemd, ce me semble logique.

        • [^] # Re: Alors

          Posté par  . Évalué à 1.

          Je ne sais pas vous, mais quand j'ai une assiette sale, je la lave

          ecp.adr te manque tant que ça ? :p

    • [^] # Re: Alors

      Posté par  . Évalué à 1.

      oui l'init bsd c'est slackware qui l'utilise pas mandrake mageia qui on un init SysVinit

  • # C'est mort

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

    La force de Linux et d'unix en général était d'être un système modulaire (un besoin, une appli), simple (tout est fichier), scriptable aisément (il suffit de piper les applis les unes derrière les autres).

    Bref, sa force était de pouvoir s'adapter à tous les besoins en un minimum d'efforts.

    Aujourd'hui, on veut faire un gros bloatware au point d'avoir des interdépendances cycliques entre le processus init 1, les daemons et les applications graphiques (et je mets de coté les bibliothèques). Et sous prétexte de gagner 3s au boot !!

    Depuis 15 ans Linux gère le multiseat, GNOME a supprimé cette fonctionnalité il y a presque 4 ans maintenant. Les régressions et bridage de cette plate-forme opéré mois après mois, versions après version sont devenus insupportable à l'usage. L'ego des devs prompt a constamment réinventer la roue, supprimer puis remettre des détails, plombe le développement de Linux sur le desktop.
    On en est à lire dans les releases notes de la 3.6 la satisfaction des devs a avoir réintégré la fonction "éteindre" dans un menu ou d'avoir une énième fois modifié la fenêtre permettant de tester de double clic de sa souris !! AU SECOURS !!

    • [^] # Re: C'est mort

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

      un besoin, une appli

      http://linuxfr.org/users/arcaik/journaux/archlinux-est-morte#comment-1397011

    • [^] # Re: C'est mort

      Posté par  . Évalué à 8.

      Aujourd'hui, on veut faire un gros bloatware au point d'avoir des interdépendances cycliques entre le processus init 1, les daemons et les applications graphiques (et je mets de coté les bibliothèques). Et sous prétexte de gagner 3s au boot !!

      Heu non le pretexte pour Gnome ce n'est pas la vitesse de boot. C'est il me semble de se débarrasser de kilomètres de code système distro-dependant pour reposer sur des services afin de pouvoir proposer une bonne intégration.

      Du coup je pense que quand tu dis:

      La force de Linux et d'unix en général était d'être un système modulaire (un besoin, une appli), simple (tout est fichier), scriptable aisément (il suffit de piper les applis les unes derrière les autres).
      Bref, sa force était de pouvoir s'adapter à tous les besoins en un minimum d'efforts.

      il faut aussi réfléchir pourquoi on en arrive là. C'est facile de s'inventer un monde idéal, mais il me semble intéressant d'essayer d'entrevoir le vrai puzzle. Les desktops ont besoin de pouvoir parler au système et d'utiliser ses fonctionnalités. Mais personne n'a jamais fait un effort pour que cela soit facile, bien fait et portable. Du coup le premier qui arrive rafle le marcher.

      L'ego des devs prompt a constamment réinventer la roue, supprimer puis remettre des détails, plombe le développement de Linux sur le desktop.

      Cela dit, si ils arrêtent de développer y'a linux sur le desktop vu que linux sur le desktop c'est eux qui l'ont fait ;)

      • [^] # Re: C'est mort

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

        il faut aussi réfléchir pourquoi on en arrive là. C'est facile de s'inventer un monde idéal, mais il me semble intéressant d'essayer d'entrevoir le vrai puzzle.

        Pour avoir développé ma propre distrib pendant plusieurs années, je connais assez bien le "puzzle" et les scripts de démarrage.
        Ce que je vois se profiler aujourd'hui m'effraie.

        Avec systemd, gérer les services est devenu une plaie. Avant chkconfig ou ntsysv était un jeu d'enfant.

        Le passage a systemd me rappelle l'époque du passage de devfs à udev (gros bordel, multiple réécriture, réintégration silencieuse des fonctions de devfs) puis intégration de udev dans systemd avec nouvelles régressions à la clé au point que Linus pousse une nouvelle gueulante.

        • [^] # Re: C'est mort

          Posté par  . Évalué à 9.

          Avec systemd, gérer les services est devenu une plaie. Avant chkconfig ou ntsysv était un jeu d'enfant.

          Alors ça, c'est faux ou alors je veux des preuves.

          Au contraire, j'ai voulu il y a quelques jours modifier le comportement de mon système à un moment très particulier du boot, et avec systemd ça se fait tout seul: une unité avec les entrées After et Before et un bête appel de commande.

          J'aurais pu le faire avec Sysv, mais en écrivant un script qui prend en compte start, stop, les lsb-functions, et en vérifiant bien que ça se lance pile au bon moment. Bref, pas envie, trop long.

          Je maintiens qu'en tant qu'admin, systemd simplifie la vie, et qu'il n'empêche pas de bidouiller, à condition de lire la doc (ce que personne ne veut faire).

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

          • [^] # Re: C'est mort

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

            J'ai lu l'article sur SystemD dans Linux Magazine n°153, et franchement, il n'y a pas de quoi fouetter un chat ! De plus, il semble que certaines syntaxes ont été conservées (genre: appel à chkconfig, à service), histoire de conserver une certaine rétro-compatibilité. Pas de quoi s'arracher les cheveux !

            • [^] # Re: C'est mort

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

              c'est la théorie, ce qui est prétendu dans la documentation…
              Dans la pratique, sur ma Fedora 17, quand je lance chkconfig j'ai ce message :

              Avertissement : cette sortie n'affiche que les services SysV et n'inclut pas les services
              natifs systemd. Les données de configuration de SysV peuvent être surchargées par la configuration
              native de systemd.

              et à peine 5 services configurable.

              Avec ntsysv, je n'ai plus le message d'avertissement et les mêmes 5 services à configurer :/

              • [^] # Re: C'est mort

                Posté par  . Évalué à 3.

                Mauvaise distribution, changer distribution.

                Avec Debian, j'utilise invoke-rc.d et update-rc.d avec ou sans systemd.

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

                • [^] # Re: C'est mort

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

                  Avec Debian, j'utilise invoke-rc.d

                  Utilise plutôt service. invoke-rd.d est fait pour autre chose, précisément pour être utilisé dans les scripts d'installation des paquets, et de ne faire quelque chose que lorsque c'est censé. Par exemple, invoke-rc.d apache2 restart ne redémarrera le serveur Web que s'il est censé être démarré dans le niveau d'exécution actuel. En particulier, si tu as désactivé son démarrage avec update-rc.d, invoke-rc.d apache2 start ne le démarrera pas.

              • [^] # Re: C'est mort

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

                Et pourquoi tu veux utiliser chkconfig et pas systemctl ?

              • [^] # Re: C'est mort

                Posté par  . Évalué à 1.

                Il ne liste pas les services de systemd dans l'autocomplétion, mais tu peux quand même les contrôler avec chkconfig.

        • [^] # Re: C'est mort

          Posté par  . Évalué à 10.

          Pour avoir développé ma propre distrib pendant plusieurs années, je connais assez bien le "puzzle" et les scripts de démarrage.

          C'est que tu n'as absolument rien compris à mon message. Gnome ils s'en balancent de la partie init. Ce qui les intéresse c'est la partie services pour que leur frontend aillent taper sur des services à l'interface connue plutôt que de se taper la merde de l' intégration avec le quadrillon de systèmes existant avec un flow d’exécution tout moisi pour faire des actions tout ce qu'il y a de plus standard. C'était le point de départ de policykit, découpler les actions d'administration privilégiées des gui. Rien de bien nouveau. C'est pas bien compliqué de comprendre que les devs d'application veulent pouvoir appeler des services qui abstrait le bordel. Si en plus on peut gérer les privilèges de manière fine c'est mieux.

          Maintenant une distro, 90% du temps c'est refaire la même glue que les autres. Rien de bien intéressant ou qui fasse avancer "linux sur le desktop" ou en comprendre les problématique. Tu compiles ce qui existe et basta.

          Avec systemd, gérer les services est devenu une plaie. Avant chkconfig ou ntsysv était un jeu d'enfant.

          Perso je trouve pas. Pour avoir installer des services non prévu dans ma distrib cette semaine c'est clairement plus simple et DRY qu'avec un init sysV.

          Ce qui ne veut pas dire qu'il n'y a pas de manques fonctionnels pour certains usages.

          • [^] # Re: C'est mort

            Posté par  . Évalué à 4.

            Si en plus on peut gérer les privilèges de manière fine c'est mieux.

            C'est complètement stupide. Policykit est une plaie. C'est une des raisons qui m'ont fait abandonner Arch parce que entre deux mises à jour, il fallait refaire toute la chaine des droits parce qu'un nouveau truc nécessitait la configuration de PoliciKit avec des commandes à la con. Gerer certains droits au niveau du GUI peut avoir du sens, mais une gestion trop fine est contre productive.

            • [^] # Re: C'est mort

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

              Policykit est une plaie.

              Sous Arch peut être (j'en sais rien, je n'utilise pas de GUI pour faire quoi que ce soit sous Arch) mais sous Ubuntu et Fedora cela fonctionne très bien.

          • [^] # Re: C'est mort

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

            Maintenant une distro, 90% du temps c'est refaire la même glue que les autres.

            Et les 10% restant font la différence.

            Rien de bien intéressant ou qui fasse avancer "linux sur le desktop" ou en comprendre les problématique.

            C'est tout le contraire

            Tu compiles ce qui existe et basta.

            Juste fais le !

      • [^] # Re: C'est mort

        Posté par  . Évalué à -1. Dernière modification le 20 octobre 2012 à 13:06.

        Heu non le pretexte pour Gnome ce n'est pas la vitesse de boot. C'est il me semble de se débarrasser de kilomètres de code système distro-dependant pour reposer >sur des services afin de pouvoir proposer une bonne intégration.

        l'integration c'est les distros qui le font pas gnome ça tombe bien

        Cela dit, si ils arrêtent de développer y'a linux sur le desktop vu que linux sur le desktop c'est eux qui l'ont fait ;)

        j'utilise pas gnome

        • [^] # Re: C'est mort

          Posté par  . Évalué à 4.

          Oui bien sur c'est magique les mecs de Gnome font des mockups, et les distro implémentent tout. C'est étrange quand je regarde les paquets fait pas les distros je ne vois pas cette partie. Tu vis vraiment dans un autre monde. Il suffit de lire le thread donné dans le journal pour voir des exemples de pourquoi ils veulent la dépendance sur systemd. À partir de la on peut commencer à discuter, et expliquer qui il y d'autres solutions pour arriver au même niveau fonctionnel.

          Autrement il suffit de tracer le code autour des points d'intégration pour comprendre.

    • [^] # Re: C'est mort

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

      Rien ne t'empêche de désinstaller systemd, GNOME et tout les outils qui ne te conviennent pas.

      Rien ne t'empêche de changer de distribution si tu n'es plus en accord avec la philosophie de ta distribution, c'est d'ailleurs pourquoi il y a tant de distributions.

      Le but de systemd était de proposer un système d'init qui exploite 100% des fonctionnalités de Linux, et de ne pas se cloisonner dans la norme POSIX, c'est louable. En effet, pourquoi développer des fonctionnalités si c'est pour que personne ne les utilisent en prétextant "Ça n'est pas POSIX".

      systemd est un logiciel qui dans le concept est très intéressant, car il offre une vision différente du processus d'init. Cela ne veut pas dire que j'accroche pour autant.

      Je remarque beaucoup, dans les commentaires de ces sujets à troll, une confusion entre init et gestion des services.

      Pour moi, l'init c'est :

      • amorcer la machine ;
      • monter les partitions ;
      • faire quelques checks.

      Ceci peut être fait très simplement avec des scripts shell (c'est ce qui était fait avant).

      Maintenant on a un deuxième besoin, la gestion des services :

      • lancer le service ;
      • logguer le service ;
      • superviser le service (relancer en cas de crash, …).

      Selon moi, cette partie la ne concerne plus l'init, mais le superviseur. Et des superviseurs il y en a plein, mais je ne citerai que supervisord, qui est très simple d'utilisation (plus simple encore que systemd je trouve).

      Donc pour résumer, systemd fourni une solution d'init et de supervision unifiée, c'est bien cela ?

      https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

      • [^] # Re: C'est mort

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

        Donc pour résumer, systemd fourni une solution d'init et de supervision unifiée, c'est bien cela ?

        Là ça devient plutôt un lupanar unifié en fait…

      • [^] # Re: C'est mort

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

        Maintenant on a un deuxième besoin, la gestion des services

        Excuse moi, mais ça fait 40 ans maintenant que UNIX et Linux gère naturellement et sans aucun problème ses daemons !

        lancer, logger et superviser un daemon serait l’apanage, la killer features de systemd. On croit rêver !! Mais comment faisait t'on avant !!

        • [^] # Re: C'est mort

          Posté par  (site web personnel) . Évalué à 0. Dernière modification le 19 octobre 2012 à 16:48.

          Oh oui, j'ai dit que c'était la killer feature de systemd, j'ai même nié l'évidence que des superviseurs existaient.

          J'ai même été dire que systemd était une innovation, et le premier à faire ce qu'il implémente.

          Merci de me prêter des propos qui ne sont pas les miens.

          Quand je dis "Maintenant", c'est une formulation. Cela ne veut aucunement dire que le besoin n'existait pas avant.

          https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

        • [^] # Re: C'est mort

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

          hum…
          et comment on lance un service à la demande ?
          Genre lorsque j'ai une trame ssh qui arrive, je démarre ssh
          Car c'est bien ce que permet systemd, non ?

          • [^] # Re: C'est mort

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

            inetd

            Tu as d'autres innovations sous le coude ?

            'tain on dirais des iFanboys qui découvre l'innovation révolutionnaire du copier/coller sur leur iPhone ou la lecture aléatoire sur leur iPod !!

            Bientôt on va apprendre que c'est grâce à systemd que l'on peut faire du multitâche !

            • [^] # Re: C'est mort

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

              c'est grâce à systemd que l'on peut faire du multitâche !

              https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

            • [^] # Re: C'est mort

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

              OK, c'était probablement un mauvais exemple mal formulé

              Pourtant lorsque je regarde les articles précédents, https://linuxfr.org/news/le-point-sur-udev-et-systemd#toc_1 par exemple ou https://linuxfr.org/news/le-point-sur-udev-et-systemd#comment-1386443, ça indique plutôt une différence, non ?
              inetd permet de monter des systèmes de fichier seulement lorsqu'on y accède ? (c'est une vrai question puisqu'il est utile de préciser)

              'tain on dirais des iFanboys …

              Et que dire d'une sacré population de réfractaire au changement qui fait tout pour discréditer son boulot sans proposer grand chose en face ?

              • [^] # Re: C'est mort

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

                inetd permet de monter des systèmes de fichier seulement lorsqu'on y accède ?

                heiinnnnnn oO
                Tu peux relire TA question a laquelle JE réponds et m'expliquer par quel cheminement intellectuel tu arrive à poser cette question ? Moi je suis perdu !

                (c'est une vrai question puisqu'il est utile de préciser)

                google est ton ami

                • [^] # Re: C'est mort

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

                  T'es surtout en train de dire que systemd ne sert strictement à rien.
                  Et moi je te demande si systemd ne serait pas capable de faire ça alors que les autres solutions non.

                  Mais bon, vu que tu es tellement hermétiquement anti-systemd et que de toute façon saitaimieuavan…

                  • [^] # Re: C'est mort

                    Posté par  . Évalué à 4.

                    Comme dit plus haut, automount est capable de le faire. Donc Systemd ne sert à rien. Il veut juste faire trop de choses. A force de faire trop de choses on finit par mal les faire.

                    • [^] # Re: C'est mort

                      Posté par  . Évalué à -5.

                      Oui, et l'avantage quand on ne fait rien, c'est qu'on risque pas de mal le faire.

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

                      • [^] # Re: C'est mort

                        Posté par  . Évalué à 1.

                        heureusement que les exemples précédents parlent de choses qui existent déjà.

                        Emacs le fait depuis 30 ans.

                      • [^] # Re: C'est mort

                        Posté par  . Évalué à 2.

                        Gni ? alors pour toi automount ne fait rien ?

                  • [^] # Re: C'est mort

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

                    Et qu'est ce que cette fonctionnalité a à faire dans le processus 1 ? En quoi c'est un progrès ?
                    lorsque Lennard va intégrer un busybox-like(1)(2) dans systemd, on va encore trouver des gus pour crier au génie sous prétexte que sysvinit ne l'a pas fait !

                    automountd et autofs fonctionne très bien si on a besoin de ce genre de fonctionnalité.

                    (1) À l'inverse busybox intègre un init, mais ça c'est bien et cohérent :)
                    (2) Au point où il en est, il a déjà du faire 50% du boulot :/

                    • [^] # Re: C'est mort

                      Posté par  . Évalué à 5. Dernière modification le 20 octobre 2012 à 08:20.

                      Et qu'est ce que cette fonctionnalité a à faire dans le processus 1 ? En quoi c'est un progrès ?

                      Qu'est-ce que tu en sais, que c'est le processus 1 ? Forcément, critiquer sans connaître, c'est facile.

                      Le processus 1 se contente de gérer des unités, ce sont les unités qui ensuite font ce genre de boulot. En gros comme avant avec init et autofs.

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

              • [^] # Re: C'est mort

                Posté par  . Évalué à 1.

                inetd permet de monter des systèmes de fichier seulement lorsqu'on y accède ? (c'est une vrai question puisqu'il est utile de préciser)

                Pour ça ya automount.

                • [^] # Re: C'est mort

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

                  Pour ça ya automount.

                  Automount n'utilise pas le fstab et donc ne fait pas parti du processus d'init de Linux. C'est un logiciel à part.

                  • [^] # Re: C'est mort

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

                    Si c'est dans le fstab, c'est qu'on en a tout le temps besoin. le "à la demande" n'a aucun sens dans le processus de boot.

                    La LSB (Linux Standard Base) précise que les binaires nécessaire au boot du système sont rassemblé à la racine dans les répertoires /bin, /sbin et /lib. Les autres logiciels étant dans /usr qui peut alors être sur une autre partition, un autre périphérique, voire sur le réseau via NFS.

                    Bien sûr, systemd ayant des interdépendances dans tous les sens a décrété qu'on mets tous dans /usr, tant pis pour les utilisateurs qui ont des usages un peu plus fin :/

                    • [^] # Re: C'est mort

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

                      Euh non, ça veut pas dire qu'on a toujours besoin. Le mot clé noauto, il est pas la pour faire joli et n'avoir aucun effet. Il y a quand même une époque ou il fallait monter à la main les cdroms et les disquettes, et c'était dans /etc/fstab.
                      Les plus chanceux pouvait passer par un patch kernel ( genre automount, mis dans le kernel mandrake ), ou via autofs. D'ailleurs, c'est encore dans la config par défaut d'autofs.

              • [^] # Re: C'est mort

                Posté par  . Évalué à 2.

                inetd permet de monter des systèmes de fichier seulement lorsqu'on y accède ?
                Non, puisque inetd ne fait que répondre à des sollicitations réseaux. Par contre, autofs le fait.
                Je t’assure, toutes les super fonctionnalités existe déjà. Juste que c’est un outil par fonctionnalité…

                • [^] # Re: C'est mort

                  Posté par  . Évalué à 0.

                  Marrant, systemd aussi.

                  Comme dit plus haut, systemd c'est juste l'init. Pour chaque fonctionnalité, il y a une unité (qu'on peut bien entendu désactiver).

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

                  • [^] # Re: C'est mort

                    Posté par  . Évalué à -4.

                    Marrant, systemd aussi.

                    Marrant, systemd reprend donc des trucs qui existent, pour changer la façon de les configurer.

                    Comme dit plus haut, systemd c'est juste l'init.

                    Chut, tu vas cassé le truc. Pour certains, systemd est le messie. Quand à re-développer des units, pour des trucs qui existent déjà, à part faire payer une nouvelle formation à un administrateur, je ne vois pas l’intérêt. Lennart, qui a l’air d’être si bon, d’après son fan club, n’aurait-il pas dû faire un truc vraiment innovent ? Plutôt que de reprendre des trucs qui existe et tout mettre ensemble et dépendant ?

                    • [^] # Re: C'est mort

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

                      En gros, tu te pleins qu'on redéveloppe des trucs déjà existant? Tu devrais arrêter le logiciel libre tout de suite, ce un principe de base: "Si je code un truc qui répond mieux au besoin, alors il remplacera la concurrence"

            • [^] # Re: C'est mort

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

              inetd, ça reste une blague. Tu veux sans doute dire "xinetd", déjà, et sauf erreur de ma part, xinetd gère pas les sockets unix ( exemple cups, exemple mysql, exemple ldap pour ne citer que 3 qui me viennent à l'esprit ).

              Tu peux aussi lire http://0pointer.de/blog/projects/inetd.html ou http://0pointer.de/blog/projects/socket-activation.html pour voir ou sont les différences.

          • [^] # Re: C'est mort

            Posté par  . Évalué à 4.

            Hummm….

            xinetd par exemple ?

            Enfin, je dis ça, je dis rien…

            cd /pub && more beer

            • [^] # Re: C'est mort

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

              xinetd, c'est sympa, mais ca fonctionne pas sans sysvrc. Donc du coup, tu te retrouves avec deux systèmes de gestion des services complètement hermétiques…

              • [^] # Re: C'est mort

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

                Mais WTF ? xinetd fonctionne avec n'importe quoi qui soit capable de lancer un binaire. Si systemd n'est pas fichu de faire ça, c'est à mettre à la poubelle ce truc.

                • [^] # Re: C'est mort

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

                  Non, tu n'as pas compris, j'ai dit: xinetd est un truc à part qui n'est pas intégré au système d'init. Donc tu as deux façons de lancer un même service qui peuvent en plus rentrer en conflit.

        • [^] # Re: C'est mort

          Posté par  . Évalué à 9.

          Excuse moi, mais ça fait 40 ans maintenant que UNIX et Linux gère naturellement et sans aucun problème ses daemons !

          C'est tellement naturel que chaque distribution doit développer ses propres scripts !

          Compare Red Hat et Debian, tu verras à quel point c'est naturel…

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

          • [^] # Re: C'est mort

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

            Il y a trop de standard pour gérer les scripts de démarrage. Créons en un de plus !

          • [^] # Re: C'est mort

            Posté par  . Évalué à 3.

            a peu près de la même façon.

            Ensuite que tu ais des interfaces d'administrations différentes ne veut pas dire que le principe de fonctionnement en dessous n'est pas le même.

            Devines quoi, quand je fais un lien à la mimine dans rc3.d , que ce soit dans une vieille redhat (sans systemd) ou dans une debian … ca marche.

            Alors c'est vrai, maintenant c'est plus tellement vrai avec un gestionnaire de service qui fonctionne par dépendances, mais dans le principe ça marche toujours.

            • [^] # Re: C'est mort

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

              Ok, maintenant copie /etc/init.d/networking de Debian vers Redhat et regarde ce qu'il se passe…

              • [^] # Re: C'est mort

                Posté par  . Évalué à 0.

                Pourquoi faire ?

                • [^] # Re: C'est mort

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

                  Je répondais à ça.

                  ne veut pas dire que le principe de fonctionnement en dessous n'est pas le même.

                  • [^] # Re: C'est mort

                    Posté par  . Évalué à 3.

                    Et en quoi ta remarque répond-elle à la question ?

                • [^] # Re: C'est mort

                  Posté par  . Évalué à 2.

                  Si comme il le dit c'est « a peu près de la même façon », ça devrait marcher sans trop de modifs, non ?

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

            • [^] # Re: C'est mort

              Posté par  . Évalué à 7.

              Devines quoi, quand je fais un lien à la mimine dans rc3.d , que ce soit dans une vieille redhat (sans systemd) ou dans une debian … ca marche.

              Ben non, ça ne marchera pas parce que Debian fonctionne par défaut en niveau 2, alors que Red Hat fonctionne en 3. C'est bête, hein ?
              En plus, tu oublies un peu les distributions qui n'utilisent pas des trucs comme les niveaux d'exécution, genre Gentoo, Arch ou Slack.

              De toute manière, un système d'init c'est pas juste des liens. C'est aussi appeler des binaires qui ne sont pas au même endroit, ne travaillent pas au même endroit, n'utilisent pas les mêmes utilisateurs ou carrément n'ont pas le même nom. Je pense à apache qui est appelé apache2 chez Debian et httpd chez Red Hat. Je te laisse imaginer l'écart entre entre les scripts.

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

              • [^] # Re: C'est mort

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

                En general, la configuration du réseau va aussi dans le systéme d'init, tout comme le chargement des modules, l'application des sysctl, etc, etc. Le réseau est pas unifié sous systemd, mais le reste l'est déja plus, et ça, ça aide pour les ISVs a mon avis. Et les admins. Même si une distro n'est pas d'accord avec systemd, reprendre les interfaces, ça peut faire un pas en avant vers moins de différences gratuites.

        • [^] # Re: C'est mort

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

          Excuse moi, mais ça fait 40 ans maintenant que UNIX et Linux gère naturellement et sans aucun problème ses daemons !
          Dit pas de la merde. La gestion des daemons, c'est pas "sans aucun problème". J'ai donné 15 fois les exemples, mais je vais les redonner, même si je sais que ça va pas rentrer.

          Tu prends apache, qui va forker une paire de fois avant de lancer un cgi ( donc un autre process ) en perl qui va lancer encore des softs ( genre imagemagick ) en tache de fond. Si le cgi claque, tu va perdre la trace du process qui va devenir un zombie. C'est pas ce que j'appelle sans souci.

          Tu prends bind, qui s'éteint de façon asynchrone, et qui requiert de rajouter sleep dans restart ( et donc interdit de faire "stop"/"start" en shell ). C'est pas sans souci.

          Tu prends un soft mal codé ( genre sympa qui attends que pgsql soit up avant de continuer ) ou malconfiguré ( genre mcollective avec daemonize = 0 qui du coup passe pas en background et qui bloque le boot de ta bécane ). C'est pas sans souci.

          Tout ça, c'est des exemples que j'ai vu il y a moins de 3 ans sur des distros modernes sur des serveurs en production. Et en pratique, quand tu regardes le code des softs, tu vois que personne ne sait exactement comment lancer un daemon proprement ( genre, aller sur /, faire un double fork, écrire le pid, se détacher du terminal, etc ), donc forcément, des softs qui font de la merde, y en a des tonnes, et à moins d'avoir vécu sur un igloo loin du monde réel ou isolé du travail au jour le jour sur une distro, tu peux pas dire "ça marche depuis 40 ans" et garder ta crédibilité.

          Ça fait 40 ans que le système d'init est écrit dans un langage ( le shell, pas le bash ) sans espace de nommage, sans tests, sans gestion avancé des chaines, sans tableau, sans gestion du parallélisme, ou le fait de lire un fichier requiert de faire un fork/exec. C'est des bouts de ficelles. Apple a refait le système d'init. Solaris l'a refait. Ubuntu l'a refait. Gentoo l'a refait. Personne ne se dit vraiment "y a une raison" ?

          • [^] # Re: C'est mort

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

            Ça fait 40 ans que le système d'init est écrit dans un langage ( le shell, pas le bash ) sans espace de nommage, sans tests, sans gestion avancé des chaines, sans tableau, sans gestion du parallélisme, ou le fait de lire un fichier requiert de faire un fork/exec. C'est des bouts de ficelles.

            Ce que tu liste ne sont en rien des défaut dans un système modulaire ou chaque brique effectue une tâche et la fait bien.
            La parallélisme, pour gagner 3s au boot, n'est pas une fonctionnalité fondamentale. Effectuer des fork/exec pour lire un fichier et la base même d'UNIX. Il a été conçu pour cet usage.

            • [^] # Re: C'est mort

              Posté par  . Évalué à -2.

              Et pour les tableaux et les chaines, tu fais quoi? Tu pipes la sortie des commandes array, set, hashmap et string?
              Pas mal comme concept.

              Un jour va falloir accepter que les dogmes eriges au debut des annees 70 ne sont pas tous valable 40 ans plus tard. Tu sais, l'informatique a pas mal evolue depuis.

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

            • [^] # Re: C'est mort

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

              On parle pas des fondements d'unix, on parle du système d'init qui est moisi car justement, on estime que sa seule fonction et interface, c'est de lancer le soft et advienne que pourra. On a donc rajouter par dessus un système de scripts qui fait une chose , copier celui du voisin avec divers variations, et ça donne les soucis que j'ai listé.

              Et c'est bien parce que init ne fait qu'une chose, à savoir lancer un programme qui va lancer des scripts qui va lancer d'autres scripts que c'est le merdier.

              Systemd a une autre approche, ou on considère que le boot, c'est un ensemble d'unité qui doit être lancé et orchestré pour avoir un système qui marche. Ou on se dit que monter un fs, c'est autant un truc de boot que de lancer sympa ( dont le script lance 4 demons à la suite par exemple ).

              Ça remets en cause ta vision des idées d'unix, sans doute. Mais ça corrige les problèmes que tu as nié, et c'est pas négligeable.

              • [^] # C’est pas encore ça…

                Posté par  . Évalué à 5.

                Ça remets en cause ta vision des idées d'unix, sans doute. Mais ça corrige les problèmes que tu as nié, et c'est pas négligeable.

                Tu expliqueras ça à ma Fedora 17, qui bloque habituellement de 30 s à 5 mn lors de l’arrêt.

                Il semble que systemd attende après rpc.lockd et rpc.statd, qui n’arrivent pas à retrouver leurs billes, ce qui n’est pas étonnant vu que le réseau est déjà arrêté ; nfs-lock.service est pourtant sensé l’être aussi depuis longtemps, donc ils ne devraient plus être là.

                La conception vachement chiadée de systemd est sensée éviter ce genre de problèmes et ce sera peut-être le cas quand tout sera au point, mais en attendant, pour résoudre soi-même un problème de ce type, c’est moins évident qu’avec les vieux scripts…

                « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

    • [^] # Re: C'est mort

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

      La force de Linux et d'unix en général était d'être un système modulaire

      Enfin l'une des raisons de pas trop paniquer face à ces débats, c'est que GNOME <> Unix. D'autres bureaux, ce n'est pas ce qui manque, on ne va pas en dresser une liste.

      Si UN des bureaux pense faire mieux en se concentrant sur une plate-forme spécifique et même uniquement avec gnome-shell, ce n'est ni la mort de Linux ni quelque chose d'absurde, même s'il ne faut pas négliger la contrepartie.

    • [^] # Re: C'est mort

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

      Depuis 15 ans Linux gère le multiseat, GNOME a supprimé cette fonctionnalité il y a presque 4 ans maintenant
      (…)
      L'ego des devs (…) plombe le développement de Linux sur le desktop.

      Si Gnome arrête de supporter des fonctionnalités, c'est justement pour se rendre plus accessible au utilisateurs desktop. La question qui se pose pour eux est simple : Quel pourcentage d'utilisateurs font du multiseat par rapport à quel pourcentage de temps ils vont devoir consacrer à cette fonctionnalité ? En se posant cette question, il faut aussi se rappeler que l'objectif de Gnome est de rendre accessible l'informatique libre à un maximum de monde. Ils ne ciblent donc pas les geeks mais les utilisateurs lambda. Combien d'utilisateurs lambda ont l'usage du multiseat ?

      Il ne faut pas perdre de vue que chaque fonctionnalité et chaque plateforme supplémentaire à supporter prends du temps (parfois beaucoup), et va impliquer potentiellement moultes bugs. Les-dits bugs risquent d'ailleurs d'embêter aussi les gens qui n'utilisent pas les-dites fonctionnalités.

      Petit blague de dev IHM dont je ne retrouve plus la source:
      "How do you turn software into bloatware ?"
      "One feature request at a time."

      On en est à lire dans les releases notes de la 3.6 la satisfaction des devs a avoir réintégré la fonction "éteindre" dans un menu ou d'avoir une énième fois modifié la fenêtre permettant de tester de double clic de sa souris !! AU SECOURS !!

      Ça s'appelle de l'ergonomie, et pour les utilisateurs desktop, c'est autrement plus important que le support du multiseat.

      • [^] # Re: C'est mort

        Posté par  . Évalué à 3.

        perso j'ai mis des utilisateurs lambda sur kde et ca marche très bien.

        Arrêter de penser que les utilisateurs lambda sont trop con pour cliquer sur une souris.

        Par contre s'amuser a changer le fonctionnement un peu à chaque fois (kde3 vs kde4 par ex. Je ne connais pas assez gnome pour en parler), certes c'est plus kikoolol, mais ça ça n'aide pas.

        Bon heureusement que lxde et wmaker s'amusent pas a tout changer a chaque version.

        • [^] # Re: C'est mort

          Posté par  (site web personnel) . Évalué à 1. Dernière modification le 19 octobre 2012 à 22:51.

          Arrêter de penser que les utilisateurs lambda sont trop con pour cliquer sur une souris.

          Ce n'est pas une question d'être trop con ou pas. C'est une question de faire des interfaces graphiques claires et ergonomiques. Autrement dit, des interfaces où l'utilisateur ne perd pas son temps à tout configurer et à nager dans des options et autres subtilités dont il n'a rien à cirer. En bref, des interfaces qui font ce dont il a besoin et rien d'autre.

          Je n'ai rien contre des interfaces surchargées en options comme Kde ou Xfce (chacun ses goûts après tout). Mais il faut comprendre que l'objectif de Gnome n'est pas de faire une suite logicielle fournissant les options désirées par toutes les personnes existantes sur cette planète. Son rôle est de rendre l'informatique libre accessible aux utilisateurs lambda (comprendre les 90~99% des gens, non-informaticiens en première ligne). Ça implique de ne pas les noyer directement dans 25000 choix différents dès les 5 premières secondes, sinon ils seront dégoûtés et vont abandonner avant même d'avoir vraiment essayé. Ces utilisateurs lambda peuvent aussi bien être la grand-mère qui vit au-dessus de chez moi, qui vient d'apprendre que je suis informaticien (oh désespoir), qui me demande qu'est-ce que c'est Facebook et est-ce que je peux rendre son ordinateur plus rapide. Ou alors ça peut aussi bien être le geek qui se satisfait très bien d'une interface bien faite et dont les réglages par défaut lui conviennent très bien dans l'ensemble (moi par exemple).

          Après libre à ceux qui aiment configurer leur système plus en détails d'opter pour une interface plus coincoin.

          Avec ça en tête, je trouve que Gnome 3 est une interface idéale à mettre par défaut sur toute distribution se voulant user-friendly et rapidement fonctionnelles après l'installation. Tout ces trolls du type "bouh! Gnome ne supporte pas X" ou "c'est la faute à Gnome si Linux ne perse pas sur le desktop" me semblent clairement complètement à coté de la plaque.

      • [^] # Re: C'est mort

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

        Quel pourcentage d'utilisateurs

        … lambdas qui utilise le terminal? Pourtant Gnome en fournit un!

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: C'est mort

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

          Chuuuuut, mais chuuuut ! Plus un mot, j'espère qu'ils n'ont rien entendu et qu'il n'est pas trop tard, sinon ils vont nous l'enlever, le terminal…

      • [^] # Re: C'est mort

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

        Quel pourcentage d'utilisateurs font du multiseat par rapport à quel pourcentage de temps ils vont devoir consacrer à
        cette fonctionnalité ?

        En fait, c'est plus "combien de personnes qui demandent ça sur linuxfr vont consacrer du temps à faire du code ou contribuer". Et qu'on me dise pas "ça prends du temps". Oui, ça prends du temps, mais si les gens veulent pas le prendre, faut pas râler si d'autres ( en l'occurrence les devs upstreams ) font le même choix.

        • [^] # Re: C'est mort

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

          Linux Mint continue d'utiliser GDM 2.20 et donc d'avoir un gestionnaire de connexions extrêmement personnalisable et fonctionnellement complet.

          Qu'apporte de plus les nouvelles versions de gdm à part la suppression de nombreuses fonctionnalités ?

          Sinon, les autres gestionnaires de connexions proposent depuis toujours le multiseat. J'en vient à penser que les devs des autres projets sont plus compétent.

          • [^] # Re: C'est mort

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

            D'avoir quelqu'un qui maintient, et pas juste quelqu'un qui fait de la compilation. Si tu regardes bien, Linuxmint ne fait pas de mises à jours de sécurité autre que celle de Canonical, et ils savent pas coder propre ( CVE-2012-1566 comme je le dit si souvent ).

            Et systemd supporte le multiseat : http://www.freedesktop.org/wiki/Software/systemd/multiseat
            Tu noteras aussi https://bugzilla.gnome.org/show_bug.cgi?id=655380

            • [^] # Re: C'est mort

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

              TOUS les systèmes de login gère le multiseat !!
              C'est pour ça que tu as plusieurs consoles accessible via Alt+Fn

              Tous les gestionnaires de connexions X gère le multi seat X SAUF gdm !

              Que systemd le gère aussi n'est pas un exploit et c'est le minimum qu'on lui demande vu que c'est une des fonctionnalités basiques et fondamentales de init et /etc/inittab que de lancer getty sur une console virtuelle !

              Quant à ton rapport de bug, je note surtout que si Lennart fournit un patch pour GDM pour ramener la fonctionnalité multiseat, c'est surtout dans sa stratégie de faire de systemd une dépendance indispensable à GNOME

              Cela fait pourtant plus de 4 ans que des patchs "normaux" sont proposé pour ramener cette fonctionnalité.
              https://bugzilla.gnome.org/show_bug.cgi?id=536355

              • [^] # Re: C'est mort

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

                gdmflexiserver marche encore sur ma machine, il te faut quoi de plus pour du multiseat ?

                • [^] # Re: C'est mort

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

                  Faire tourner un gdm sur la puce 2D intégré à un serveur pour les connexions d'admin local et en faire tourner un autre sur la carte GPU 3D additionnelle pour les connexions distantes avec Virtual GL.
                  Accessoirement, récupérer l'affichage 3D lorsque l'on travaille en local sur la puce 2D (note: la carte GPU 3D n'a pas de sortie VGA…)

                  Je t'écoutes…

                  • [^] # Re: C'est mort

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

                    Plus je relit ce que tu demandes, plus ça me semble embrouillé, mais ça doit être moi. Tu parles d'inittab et tu dis que c'est normal que systemd supporte ça alors qu'on parle de multiseat. Bien que ça soit exact, c'est pas exactement la même chose. Si je te dit "gdm supporte le multiseat, tu peux aller sur le terminal avec ctl alt f1", tu va pas être d'accord. Donc gardons le multiseat à la définition communément prise pour gdm, à savoir avoir 2 fois le matos ( 2 cartes graphiques, 2 moniteurs, 2 claviers, 2 souris )

                    Le souci principal pour gdm, c'est pas de pas supporté d'être lancé 2 fois ( comme j'ai dit, gdmflexiserver montre bien que c'est faisable, ne serais ce que via le flag -n ). Le souci, c'est pas de lancer xorg 2 fois ( pareil, c'est trivial à faire à la main, je viens de le refaire ). Le souci, c'est "je branche une clé usb, qui va la voir sur son bureau".

                    Lancer xorg avec une config spécifique ( genre qui pointe sur l'adaptateur pci de la carte ), ça se fait. Lancer gdm en lui faisant croire qu'il est dans Xnest, ça se fait aussi. ( ou même sans ça, lancer 2 fois gdm avec un prefix différent ) C'est d'ailleurs le premier lien. Voir mieux, lancer xorg sur un periph usb, ça se fait ( http://0pointer.de/blog/projects/multi-seat )

                    La ou ça devient touchy, c'est le partage de la puce 3d. Sauf que sauf erreur de ma part, ça n'a rien a voir avec le multiseat tel que la plupart des gens l'entendent, vu que l'idée, c'est d'avoir 2 claviers, 2 souris, 2 écrans. La, tu es dans le même cas que quelqu'un avec une carte nvidia optimus, avec 2 puces. Sauf erreur de ma part, c'est pas très bien supporté pour le moment.

                    Donc la solution serait de gérer le client local comme si c'était un client distant. Ie, d'avoir un xorg dédié à faire tourner virtualgl ( pas besoin de gdm pour ça, vu que personne ne se connecte en local dessus ), et de faire tourner gdm sur l'autre puce, et d'utiliser un client ( par exemple vnc ) pour lancer les applis comme si c'était un thin client.

                    Mais je suppose que ça réponds pas à ton besoin ?

  • # Pop-corn

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

    Bon bon bon, la vase est plein, avec un peu de chance ce sera la goutte qui met le feu aux poudres. Plus qu'à s'installer confortablement avec un grand bol de pop-corn.

    • [^] # Re: Pop-corn

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

      Et il va se passer quoi ? Des gens vont … se disputer sur une liste de diffusion.

      Sincèrement, est ce que les séries télés sont si nulles de nos jours qu'on se retrouve à devoir inventer du drama dans le libre ? ( et linuxfr est soft quand je compare à omg ubuntu )

    • [^] # Re: Pop-corn

      Posté par  . Évalué à 8.

      +1. Perso je me marre bien avec les avis anti-systemd.

      Entre refus du changement, FUD gratis, méconnaissance du sujet, attaque ad hominem et ad personam sur le créateur… Tout est réunis pour une discussion mesurée et productive :-)

      Heureusement que le côté pro-systemd est niveau 5 en troll des cavernes pour soutenir le débat !

      • [^] # Re: Pop-corn

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

        C'est vrai qu'on peut dire merci à Lennart, les trolls GNOME vs KDE n'avaient plus de succès, grâce à lui, Da Linux French Troll is not dead!

        • [^] # Re: Pop-corn

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

          Oui, mais la vraie nouveauté, ce qui fait que ça marche super bien, c'est que cette fois-ci c'est un trolleur qui code, et pas qu'un peu ! Forcément, ça dérange…

  • # Bah

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

    Ah, un tel sujet un vendredi…

    GNOME applications are not intended to be fully functional when used outside of environments based on GNOME Shell.

    Ils auraient pû s'arrêter à "GNOME applications are not intended to be fully functional."

    M'enfin, une raison de plus pour que je continue sans Gnome.

    Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

    • [^] # Re: Bah

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

      En pratique, c'est rien de nouveau. Par exemple, kwin n'avait toutes les fonctionnalités ( intégration avec lilo ) qu'avec kdm pendant un temps ( et c'est pas pour dire "kde le fait aussi", c'est juste que c'est un exemple qui était ressorti à l'époque ou c'était mon bureau ). Moi, ça me parait normal et même sain pour l'innovation.

      • [^] # Re: Bah

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

        Euh, je sais pas ce que fait kwin dans ta phrase mais doit y avoir une erreur :) Peut être voulait tu parler de plasma-desktop ?

        • [^] # Re: Bah

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

          non je parle de kde 3, mon exemple date un peu. Ceci dit, c'était pas forcément kwin, mais l'outil responsable de la boite de dialogue "log out" de kde 3.4 ou .5, ça devait être lui, non ?

  • # API disponible

    Posté par  . Évalué à 1.

    Il me semble qu'on avait déjà parlé que les APIs de systemd (elles sont sur dbus) étaient documentées et qu'il était donc possible de les réimplémenter si besoin.

    Dans notre cas, c'est de logind qu'on parle, elle n'a encore été réimplémentée par personne mais ça va peut-être se faire maintenant.

    • [^] # Re: API disponible

      Posté par  . Évalué à 3.

      Ça change rien au fait que ces API puent et qu'elles sont extrêmement limitées. Si demain quelqu'un invente un nouveau paradigme de sessions, et bien il ne pourra pas forcement implémenter l'API logind. C'est pas en figeant des comportement qu'un écosystème peut évoluer. On pourrai trouver des exemples pour démonter toutes ces API.

      • [^] # Re: API disponible

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

        Et donc, la solution est de garder la compatibilité avec l'ancien systéme ( en l'occurence consolekit ) car 1) ça pue pas 2) ça peut encore évoluer vers un nouveau paradigme ?

        Ce qui est bien, c'est que quand systemd fait trop de choses, ça pue, et quand ça en fait pas assez et ça prends pas en compte des concepts non définis et non existants pour le moment, ça pue quand même. Donc tout le monde est d'accord pour dire qu'il y a un juste milieu, sauf que personne ne le code ou ne l'explicite ( voir même ne le défend, car la, c'est "on pourrait trouver des exemples", mais pas besoin d'en donner, ni même de faire remarquer qu'on peut toujours rajouter une API autre par la suite si besoin )

        • [^] # Le problème…

          Posté par  . Évalué à 9.

          Ce qui est bien, c'est que quand systemd fait trop de choses, ça pue, et quand ça en fait pas assez et ça prends pas en compte des concepts non définis et non existants pour le moment, ça pue quand même.

          Le problème, c’est quand systemd remplace des trucs existants, mais sans faire leur boulot à fond.

          Par exemple, logind prend en charge le boulot d’acpid. Sauf qu’acpid, quand on rabat l’écran de son portable, il lance un script, qu’on peut personnaliser pour mettre le portable en hibernation uniquement si l’on est sur batterie. Avec logind, ce n’est pas prévu (si jamais ça l’est, ce n’est pas documenté), donc on se retrouve à utiliser aussi acpid, mais il faut en plus configurer logind pour ignorer le rabat de l’écran.

          Deuxième exemple : systemd gère l’automount. Oui, enfin pour les cas triviaux, pas pour des tables de montages centralisées sur LDAP ou NIS. Enfin sur ce coup-là au moins, il ne se met pas en travers du chemin.

          Quand systemd fera tout le boulot des composants qu’il prétend remplacer, cette critique sera caduque, mais on en est encore assez loin (et si Lennart essaye de remplacer tout le système avant de finir l’existant, ça pourrait durer…).

          « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

          • [^] # Re: Le problème…

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

            Pour ton premier exemple, je pense que tu peux juste déclencher une action "bloquer le lid switch" via dbus quand tu as du courant ( en écoutant upower ou le demon kivabien en fonction du bureau ) et en envoyant via dbus un inhibitor kivabien sur logind :
            http://www.freedesktop.org/wiki/Software/systemd/inhibit

            Et je pense qu'on manque d'un framework haut niveau pour dbus, surtout vu l'importance que ça prends. Quelque chose du style du shell, ou tu peux réagir à des events, et en déclencher d'autres via des pipes.

            • [^] # Re: Le problème…

              Posté par  . Évalué à 2.

              Merci.

              Cela dit, il manque encore l’appel du menu de déconnexion quand on appuie sur le bouton marche/arrêt plutôt que l’arrêt direct.

              Cela dit, la Fedora le gère peut-être, il faudrait que je regarde comment.

              « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

          • [^] # Re: Le problème…

            Posté par  . Évalué à 1.

            Pour ton deuxième exemple, ça n'a pas de sens de dire que que systemd ne gère pas l'automount venant d'une source ou d'une autre, puisque systemd lui-même ne comprends qu'une chose : les units (de mount et d'automount).
            Systemd est fourni avec un programme auxiliaire (un générateur, celui pour fstab est /usr/lib/systemd/system-generators/systemd-fstab-generator) lancé avant la phase de résolution des dépendances et qui lit /etc/fstab et génère les units correspondantes. Tu peux tout à fait coder un programme qui fasse la même chose mais prend ses infos via LDAP ou NIS à la place de lire dans le fstab.

            Conclusion : faut mieux lire la doc avant de dire que c'est pas possible de faire tel ou tel truc.

            • [^] # Re: Le problème…

              Posté par  . Évalué à 4.

              Tu peux tout à fait coder un programme qui fasse la même chose mais prend ses infos via LDAP ou NIS à la place de lire dans le fstab.

              Je pourrais coder un programme pour faire… ce qu’autofs fait déjà avec juste un peu de configuration.
              Ça n’infirme pas ce que je dis : il manque encore des trucs, pas forcément au cœur de systemd, mais aux services qui l’accompagnent.
              Alors ce n’est peut-être pas gros, mais c’est un peu par ci, un peu par là…

              Conclusion : faut mieux lire la doc avant de dire que c'est pas possible de faire tel ou tel truc.

              L’ennui, c’est qu’en même temps que la doc de systemd, il faut se taper la doc de son automount, la doc de journald, la doc de logind… Et dans certains cas, il faut déjà trouver la bonne (par exemple que c’est celle de logind pour la gestion du bouton marche-arrêt)…
              C’est bientôt la moitié du système qui est remplacée d’un coup. Ça fait beaucoup en une seule fois.

              « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

  • # Si c'est un complot...

    Posté par  (site web personnel) . Évalué à 1. Dernière modification le 26 octobre 2012 à 17:31.

    à supposer que ce soit un complot de red hat…
    ça n'évince pas les autres distribs GNU/Linux par définition.
    les *bsd ? Ce ne sont pas des concurrents à ma connaissance.
    Solaris : tout ça pour empêcher Solaris d'utiliser GNOME ? possible ?

Suivre le flux des commentaires

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