Journal Laisser systemd de côté dans Debian

Posté par . Licence CC by-sa
Tags :
8
26
nov.
2014

Salut, nal,

Lors du dernier dist-upgrade, j'ai encore eu systemd qui s'est glissé dans les dépendances à installer. Et je ne sais pas trop comment, j'ai eu un éclair de génie à propos d'un outil que j'utilise d'habitude dans un sens, mais dont j'ai réalisé l'utilité dans un autre : apt-mark (enfin, c'est une fonctionnalité de dpkg à la base, il enrobe juste les choses).

En effet, on peut par exemple avec cet outil marquer des paquets qu'on avait installés manuellement comme devant être de nouveau gérés automatiquement (marque auto), ou alors demander de garder la version actuelle d'un logiciel malgré les mises à jour qui pourraient arriver (comme quand on a fait une version sur mesure d'un paquet ; marque hold). C'est cette dernière marque qui peut être utile dans l'autre sens : si on a déjà auparavant supprimé un paquet, et qu'on marque ce paquet comme étant « bloqué », le calcul des dépendances d'installation se fera toujours en essayant de garder non-installé ce paquet ! C'est peut-être évident pour certains, mais je n'avais encore jamais pensé à l'utiliser comme ça.

Ça donne, en root (pour l'aventure) :

apt-get remove systemd
apt-mark hold systemd
Du coup, je n'ai plus la hantise de voir systemd se faufiler dans la prochaine upgrade, et j'utilise de nouveau apt-get avec joie !

  • # Sinon

    Posté par . Évalué à 10. Dernière modification le 26/11/14 à 23:52.

    J'ai ça :
    cat /etc/apt/preferences.d/systemd

    Package: systemd
    Pin: origin ""
    Pin-Priority: -1

    Pour l'instant, ça m'a préservé de systemd

  • # Mwai

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

    Et sinon, ça vous dit pas de changer de distrib plutôt que de poster des journaux inutiles?

    Quand systemd sera le seul init disponible, vous ferez comment? :p

    • [^] # Re: Mwai

      Posté par . Évalué à 10.

      Ils prendront le probleme main une bonne fois pour toute.
      En faisant une e-petition pour demander a lennart d'aller elever des chevres dans le larzac.

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

      • [^] # Re: Mwai

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

        C'est pas sympa pour les chèvres !

        Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

        • [^] # Re: Mwai

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

          C'est surtout pas sympa pour les développeurs de systemd !

          Toutes ces attaques gratuites envers systemd et ses devs (en particulier Lennart Poettering, mais c'est loin d'être le seul dev de systemd), ce n'est pas un comportement très civilisé. Lennart a écrit un article sur google plus à ce sujet:

          I don't usually talk about this too much, and hence I figure that people are really not aware of this, but yes, the Open Source community is full of assholes, and I probably more than most others am one of their most favourite targets. I get hate mail for hacking on Open Source.

          Bref, ça va un peu trop loin.

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

          • [^] # Re: Mwai

            Posté par . Évalué à -10.

            Bref, ça va un peu trop loin.

            Autant les menaces de mort ou les injures je suis contre, autant les invitations à considérer l'élevage de chèvre ou le tricot comme reconversion professionnelle je suis tout à fait pour.
            La communeauté Open Source est pleine de connards certes, mais c'est clairement pas lui qui va faire baisser les stats.

            • [^] # Re: Mwai

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

              Ha oui, quand on est pas d'accord avec une personne, on l'insulte, c'est tellement productif (ça serait trop improductif de plutôt passer son temps à coder une alternative meilleure et à convaincre qu'elle est meilleure).

              Merci pour le commentaire (ce n'est pas le seul dans le genre) très révélateur de la manière de (non) penser des anti-systemd.

              • [^] # Re: Mwai

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

                Merci pour le commentaire (ce n'est pas le seul dans le genre) très révélateur de la manière de (non) penser des anti-systemd.

                Les généralisations outrancières, c'est le mal.

                • [^] # Re: Mwai

                  Posté par . Évalué à 10.

                  En general, oui.

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

              • [^] # Re: Mwai

                Posté par . Évalué à 2.

                de la manière de (non) penser des anti-systemd

                Houlà attention, je suis anti-Lennart - mais je n'ai absolument rien contre systemd. C'est un produit qui ne me concerne pas et dont je n'ai pas (et n'aurai probablement jamais) l'usage. Ceci dit je comprend parfaitement qu'il puisse servir - juste pas du tout pour mes besoins.

                • [^] # Re: Mwai

                  Posté par . Évalué à 8.

                  Ah. Autant j'arrive à comprendre les gens qui sont contre une solution, même si je ne partage pas leur avis. Autant je conçois que le fait d'être contre une solution peut avoir tendance à se situer en opposition avec son développeur, même si cela ne me semble pas être le plus constructif.

                  Mais là tu dis que tu n'a rien contre systemd, mais que tu voudrais refroidir, ou du moins bâillonner Lennart. Très bien. J'espère juste que tu n'es pas armé.

                  • [^] # Re: Mwai

                    Posté par . Évalué à 6.

                    Mais là tu dis que tu n'a rien contre systemd, mais que tu voudrais refroidir, ou du moins bâillonner Lennart.

                    Euh non, j'ai juste dit que l'inviter à élever des chèvres dans le Larzac ne me choquait pas outre mesure. Si il faut détailler :
                    a) Je ne considère pas que d'inviter quelqu'un à élever des chèvres dans el Larzac n'est pas une menace ou une agression telle qu'elle devrait faire l'objet de l'opprobe populaire
                    b) Je ne considère pas non plus que ce serait une perte pour Linux, ou l'Open Source en général si L.Pottering en venait à se détourner de l'écriture du code pour Linux.

                    Je ne souhaite ni sa mort ni sa mutilation, mais très honnêtement son retrait partiel ou total du monde Linux ne me touchera pas. Maintenant à l'inverse son maintien dans Linux, avec sa capacité à détruire l'expérience utilisateur et son dedain vis à vis de toute tentative de création d'environnement un poil perenne, me casse franchement les pieds.

                    • [^] # Re: Mwai

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

                      Maintenant à l'inverse son maintien dans Linux, avec sa capacité à détruire l'expérience utilisateur et son dedain vis à vis de toute tentative de création d'environnement un poil perenne, me casse franchement les pieds.

                      J'adore les gens qui disent le contraire de ce qu'une personne fait pour explication de pourquoi il ne l'aime pas.

                      La vérité semble différente : tu ne l'aimes pas justement parce qu'il aide dans l'expérience utilisateur et créé un environnement pérenne, alors uqe tu veux un truc conservateur qui ferait toujours "comme avant" (donc chiant, pas pour rien que tout le monde veut changer) qui ne change pas tes habitudes à galérer pour le plaisir.

                      Salaud de personnes qui dérangent les gens qui voudraient que tout reste "comme avant". Rigolo de constateur le mensonge que tu fais à toi-même en disant que tu voudrais certaines choses mais rejette ces choses quand elles sont faites.

                      PS : on attend toujours ta solution alternative, depuis le temps où tu penses qu'il a faux.

                      • [^] # Re: Mwai

                        Posté par . Évalué à 10.

                        La vérité semble différente : tu ne l'aimes pas justement parce qu'il aide dans l'expérience utilisateur et créé un environnement pérenne

                        Oh mon dieu tu as raison. Je ne m'en rendais pas compte parce que j'avais un blocage psydhologique, que lui même a déclaré que la poursuite d'un environnement pérenne était idiot et que Kay Sievers ET Greg KH l'ont appuyé dans cette décision. Je ne m'en rendais pas compte non plus parceque jusqu'à présent j'avais un environnement pérenne et que donc au moment ou je l'ai gardé ca a fait un tel choc que j'ai fait un rejet.

                        Je te félicite pour tes talents de psychanaliste, et d'ailleurs je te conseille vivement d'aller également élever des chèvres dans le Larzac, ce serait dommage que tu fasses usage de ce talent sur une personne sensible - là pour le coup vu tes capacités il pourrait y avoir des victimes.

                        on attend toujours ta solution alternative

                        Tu vas attendre longtemps, comme déjà dit plusieurs fois, y compris à toi
                        a) Je n'ai aucun problèmes avec les solutions existantes
                        b) Ecrire une alternative à systemd nécessite quasiment de devoir recréer toute une distribution
                        c) Je suis AdminSys/architecte pas développeur système.

                        • [^] # Re: Mwai

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

                          a) Je n'ai aucun problèmes avec les solutions existantes

                          Donc tu n'auras aucun problème à les maintenir. (tu dis bien que tu n'as aucun problème, donc pas possible que tu ais un problème)
                          Ou est le problème avec systemd qui ne sera jamais chez toi puisque tu maintiens une version sans systemd?
                          A moins que tu mentes, et que ton problème avec l'existant est que plus personne ne veut faire le boulot pourri de maintenance à ta place car il y a mieux.

                          et d'ailleurs je te conseille vivement d'aller également élever des chèvres dans le Larzac,

                          Ha oui, surtout insulter, dire de dégager, quand on est mis face à ses propres contradictions…
                          Ton métier (AdminSys/architecte qui n'aime pas systemd) va disparaitre, le problème va donc être plutôt ce que toi tu vas faire.
                          (Bon, je sais, en pratique tu vas râler pendant quelques années et après faire comme tout le monde : soit t'adapter et utiliser systemd en cachant le fait que tu étais contre avant, soit partir à la retraite).

                          • [^] # Re: Mwai

                            Posté par . Évalué à 10.

                            Donc tu n'auras aucun problème à les maintenir.

                            Aucun non. C'est très simple un système d'init quand c'est pour tes besoins à toi.

                            Ou est le problème avec systemd

                            Une fois de plus je n'ai aucun problème avec systemd.

                            A moins que tu mentes, et que ton problème avec l'existant est que plus personne ne veut faire le boulot pourri de maintenance à ta place car il y a mieux.

                            J'ai plutôt le problème inverse, ni Red hat ni Suse n'ont accepté de garantir une maintenance quelconque de nos systèmes si on passait sous systemd.

                            Ha oui, surtout insulter, dire de dégager, quand on est mis face à ses propres contradictions…

                            Est-ce que tu peux pointer une contradiction s'il te plait ?

                            Ton métier (AdminSys/architecte qui n'aime pas systemd) va disparaitre, le problème va donc être plutôt ce que toi tu vas faire.

                            Tu es madame Irma en plus d'être psychanaliste ? Enfin bon avec les contrats que l'on a avec IBM d'un coté et Intel de l'autre je ne me fais pas trop de soucis pour mon métier. Et une fois de plus j'en ai rien à cirer de systemd, vu que je ne l'utilise pas.

                            soit t'adapter et utiliser systemd en cachant le fait que tu étais contre avant

                            Une dernière fois je ne suis pas contre systemd. Je ne peux matériellement pas me servir de systemd même si je le voulais, et en plus je ne veux pas.

                        • [^] # Re: Mwai

                          Posté par . Évalué à 3.

                          c) Je suis AdminSys/architecte pas développeur système.

                          Ce qui ne t'empeche pas de savoir exactement comment doit etre fait un systeme de boot.

                          C'est souvent comme ca. Des experts pour venir t'expliquer que tu fais n'importe quoi, il y en a des tas. Mais beaucoup moins pour fournir des patches.

                    • [^] # Re: Mwai

                      Posté par . Évalué à 10. Dernière modification le 27/11/14 à 18:04.

                      Maintenant à l'inverse son maintien dans Linux, avec sa capacité à détruire l'expérience utilisateur et son dedain vis à vis de toute tentative de création d'environnement un poil perenne, me casse franchement les pieds.

                      À mon avis tu te trompes de cible… Pottering développe un logiciel libre, c'est quand même son droit, il n'y a rien à critiquer là dessus.

                      EDIT : En plus c'est faut, Pottering ne « détruit » rien, il ajoute ses travaux au reste !

                      Après plein de gens utilise massivement ses logiciels. Donc deux choses :
                      – soit Pottering fait du lobbying intense pour que tout le monde utilise ses logiciels… dans ce cas, je veux bien tes sources d'info
                      – soit beaucoup de gens trouvent ses logiciels intéressants, et les utilise… Dans ce cas, la seule solution démocrate c'est de convaincre les gens d'utiliser autre chose.

                      Comme on est dans le monde du logiciel libre, tu peux créer des alternatives à ses logiciels, et c'est d'ailleurs la voie recommandée… celle qu'à suivie Pottering par exemple, pour « imposer » ses logiciels.

                      Pense que dans la vraie vie, c'est nettement plus violent. Tiens, en ce moment on « impose » à l'éducation supérieure et la recherche les « COMUE ». Malgré 800 directeurs d'unités (sur 1200) contre, des avis de comité technique contre, le Conseil national du CNRS contre, les syndicats contre, ça va a priori se faire. À côté, Pottering passe vraiment pour une lopette dans sa logique de domination du monde.

                      • [^] # Re: Mwai

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

                        Ah, chez moi les "COMUE" sont déjà en place ;)

                        • [^] # Re: Mwai

                          Posté par . Évalué à 2.

                          Chanceux va ! ;-)

                      • [^] # Re: Mwai

                        Posté par . Évalué à 3.

                        Après plein de gens utilise massivement ses logiciels. Donc deux choses :
                        – soit Pottering fait du lobbying intense pour que tout le monde utilise ses logiciels… dans ce cas, je veux bien tes sources d'info
                        – soit beaucoup de gens trouvent ses logiciels intéressants, et les utilise… Dans ce cas, la seule solution démocrate c'est de convaincre les gens d'utiliser autre chose.

                        C'est un petit peu des deux. systemd est intéréssant, mais systemd est trop complexe, trop gros (80 binaires qui font des choses totalement différentes et normalement indépendante : logind, udev, networkd, …), et enfin difficile à maintenir. D'un autre côté, systemd est plus « performant », plus standardisé, peut-être plus facile à utiliser pour les developeur.

                        Le fait que Lennart travail pour RedHat, et le fait que RedHat controle quasi entièrement Fedora et RHEL a fortement aidé à l'adoption de systemd. Le libre, ce n'est pas que des gens qui travaillent sur leur temps libre.

                        Comme on est dans le monde du logiciel libre, tu peux créer des alternatives à ses logiciels, et c'est d'ailleurs la voie recommandée… celle qu'à suivie Pottering par exemple, pour « imposer » ses logiciels.

                        Si on me paye pour ça, si on me donne la capacité de le mettre ensuite par défaut dans deux des plus grosses distributions Linux, je fonce, comme Lennart. Sortir cet argument à chaque fois c'est vraiment de mauvaise foi.

                        En plus il est fait en sorte que se soit difficile d'écrire une alternative car ils « standardisent » tout, en utilisant dbus, même des modules qui sont en théorie parfaitement indépendant d'un système d'initialisation, udev et networkd sont les exemples parfait. Ensuite les pro-systemd viennent dire : « Ah mais tu peux réécrire chaque module de systemd, ils sont totalement indépendants car ils utilisent une interface dbus standardisée ». Beuuuuurk.

                        Autre gros point faible: quasi tout les projets de Lennart sont très mal documentés.

                        • [^] # Re: Mwai

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

                          , trop gros (80 binaires qui font des choses totalement différentes et normalement indépendante : logind, udev, networkd, …),

                          Si c'est à la Linux (le noyau), c'est horrible un gros binaire
                          Si c'est à la Linux (l'idée un outil par tache), c'est horrible trops de binaires.
                          Et puis, Debian c'est trop gros (tu te rends comptes, des milliers de paquets), c'est pas bien…

                          Argument présent uniquement pour avoir un truc à dire, mais ça reste pourri.

                          Le fait que Lennart travail pour RedHat, et le fait que RedHat controle quasi entièrement Fedora et RHEL a fortement aidé à l'adoption de systemd.

                          Clair, une distro (en plus du rpm "qui pue") ça impacte toutes les autres ditros (même celles qui aiment deb, tiens d'ailleurs pourquoi deb est toujours la alors que rpm est utilisé par RH et Fedora?)
                          Argument pourri encore.

                          Autre gros point faible: quasi tout les projets de Lennart sont très mal documentés.

                          La c'est plus que pourri, c'est carrement du mensonge foutage de gueule en espérant que les gens ne réfléchissent pas.


                          Impressionnant tout ce qu'on peut inventer quand on a décidé d'être contre sans avoir régardé, juste pour le principe (et ensuite on invente tout ce qu'on peut pour ne pas changer de position).

                          Et plus ça va dans le temps, plus les anti-systemd doivent chercher loin de chez loin dans leurs "explications"…

                          • [^] # Re: Mwai

                            Posté par . Évalué à 2.

                            Si c'est à la Linux (le noyau), c'est horrible un gros binaire
                            Si c'est à la Linux (l'idée un outil par tache), c'est horrible trops de binaires.
                            Et puis, Debian c'est trop gros (tu te rends comptes, des milliers de paquets), c'est pas bien…

                            Mon dieu, tu mélanges tellement tout…

                            en plus du rpm "qui pue"

                            …Mais ne me fait pas dire ce que je n'ai pas dit.

                            La c'est plus que pourri, c'est carrement du mensonge foutage de gueule en espérant que les gens ne réfléchissent pas.

                            Pour avoir tenté de configurer PulseAudio à la main, pour avoir tenter d'utiliser DBus (abandonné devant l'horreur du truc, essayes), OUI, LA DOCUMENTATION DES PROJETS DE LENNART EST À CHIER. D'ailleurs, je tente régulièrement tout les mois (ou les deux mois) de mettre pulseaudio sur ma machine, mais il refuse toujours de marcher, toujours, toujours, TOUJOURS. Et oui je reprend a chaque fois la doc, j'y passe des heures, je ne déconne pas, juste parce-que j'ai besoins de skype pour des clients ou des amis.

                            Impressionnant tout ce qu'on peut inventer quand on a décidé d'être contre sans avoir régardé, juste pour le principe (et ensuite on invente tout ce qu'on peut pour ne pas changer de position).

                            Je rêve…

                            • [^] # Re: Mwai

                              Posté par . Évalué à 10.

                              Pour avoir tenté de configurer PulseAudio à la main, pour avoir tenter d'utiliser DBus

                              Dbus n'est pas un projet de lennart mais de Havoc Pennington , donc tu cites UN seul projet de lennart que TU trouves mal documenté , personnellement je trouve que avahi ou systemd ( qui sont pour le coup la des projets initiés par lennart ) sont plutôt TRES bien documenté .

                              C'est quand même dingue cette fâcheuse habitude de cracher sur Lennart même sur des trucs qu'il n a pas fait, on le voit souvent accusé d'avoir aussi commis network-manager.

                            • [^] # Re: Mwai

                              Posté par (page perso) . Évalué à 4. Dernière modification le 28/11/14 à 08:28.

                              Pour avoir tenté de configurer PulseAudio à la main

                              yum install pulseaudio
                              pacman -S pulseaudio
                              apt-get install pulseaudio
                              zypper in pulseaudio

                              Vas y, explique nous la distrib pourrie que tu utilises… Le projet est très bien documenté: http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/

                              Après, il faut la lire et la comprendre… Mais ça reste le boulot des intégrateurs, je ne connais plus une seule distrib ou pulseaudio ne fonctionne pas out of the box.

                              Idem pour dbus, 1erement ce n'est pas un projet de lennart mais d'un dev de gnome, tu confonds avec udev, ça montre ton niveau d'incompétence.

                              • [^] # Re: Mwai

                                Posté par . Évalué à 5.

                                Vas y, explique nous la distrib pourrie que tu utilises… Le projet est très bien documenté: http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/

                                Je suis très content de PA, mais les débuts ont été difficile (au moins sous Debian sur mes machines).

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

                                • [^] # Re: Mwai

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

                                  Les difficultés étaient dû à PA ou alors PA étaient le révélateur de problème dans les drivers audio ?

                                  • [^] # Re: Mwai

                                    Posté par . Évalué à 3.

                                    En quoi le fait qu'il est possible qu'il y ai des bug dans les drivers dédouanes PA d'être fiable ? Que certaines fonctions ne marchent pas parce que ce n'est pas possible vu l'état d'un driver c'est une chose, ne pas avoir de son du tout alors que le driver permet techniquement de le faire (ALSA y arrivait) c'était un vrai problème.

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

                                    • [^] # Re: Mwai

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

                                      Sauf que Alsa contenait une grande liste de correctifs pour palier les bogues des pilotes pour communiquer avec ces cartes là, PulseAudio ne l'a pas fait (si le pilote est mauvais, on corrige le pilote ou le périphérique mais pas le serveur de son…).

                                      Bref, non, ce n'est pas si déconnant que ça.

                                      • [^] # Re: Mwai

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

                                        Sauf que Alsa contenait une grande liste de correctifs pour palier les bogues des pilotes pour communiquer avec ces cartes là, PulseAudio ne l'a pas fait

                                        Je ne comprends pas, là. PulseAudio est en aval de ALSA (ou en amont, ça dépend du point de vue), si ALSA fait le nécessaire pour « palier les bogues des pilotes », PulseAudio devrait en bénéficier automatiquement (comme n’importe quel programme qui utiliserait ALSA directement)…

                                        Pourquoi faudrait-il que PulseAudio refasse ce qui est déjà fait dans ALSA ?

                                    • [^] # Re: Mwai

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

                                      Que certaines fonctions ne marchent pas parce que ce n'est pas possible vu l'état d'un driver c'est une chose, ne pas avoir de son du tout alors que le driver permet techniquement de le faire (ALSA y arrivait) c'était un vrai problème.

                                      Si je résume … s'il y a un problème dans l'espace noyau, le responsable n'est pas le noyau et il n'est pas nécessaire de faire des corrections. C'est à l'espace utilisateur de s'adapter aux bugs. C'est bien cela ton point de vue ?

                                      Je suis bien content que Lennart ne soit pas de ton avis :)
                                      Il y eu aussi des discussions au moment du développement de gnome-shell ou firefox sur les problèmes liés aux drivers graphiques. Je suis bien content également qu'il n'y ait pas de contournement hideux dans ces logiciels.

                                      A titre personnel je ne suis pas nostalgique de l'avant PA en tout cas …

                                      • [^] # Re: Mwai

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

                                        A titre personnel je ne suis pas nostalgique de l'avant PA en tout cas …

                                        Je me rappelle encore de l'époque où il fallait écrire un fichier de config pour dmix à la main… Et même avec ça on avait pas le quart des fonctionnalités de PA.

                                        C'est de plus en plus difficile de savoir ce que fait sa machine, mais c'est aussi de plus en plus facile de l'utiliser.

                                        • [^] # Re: Mwai

                                          Posté par . Évalué à 3.

                                          Moi je me souviens très bien de l'arrivée de pulseaudio, qui a foutu en l'air plein de truc qui marchaient; perso j'étais sous arts (artsd) à l'époque, j'avais tout qui marchait, (dont l'usage à travers de réseau), et lorsque pulseaudio a été imposé par la distrib, ça a tout cassé.

                                          Bon aujourd'hui ça marche, (encore que je n'ai pas encore essayé le réseau, j'en ai plus besoin), mais sachant qu'a l'époque il y'avait déjà jack (jackd), qui faisait la même chose, je me demande s'il était vraiment nécessaire de pousser un truc aussi immature dans les grande distributions, un peu comme kde4.0…

                                          Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                                          • [^] # Re: Mwai

                                            Posté par . Évalué à 5.

                                            mais sachant qu'a l'époque il y'avait déjà jack (jackd), qui faisait la même chose

                                            Non justement , ils ne font pas la même chose et n'ont pas le même but
                                            http://0pointer.de/blog/projects/when-pa-and-when-not.html

                                            • [^] # Re: Mwai

                                              Posté par . Évalué à 0.

                                              1) c'est vendredi, j'ai le droit :)

                                              Non justement , ils ne font pas la même chose et n'ont pas le même but

                                              2) MacOS le fait bien,
                                              3) Arts répondait déjà au besoin autre que professionnel, pourquoi développer un nouveau truc?
                                              4) j'aime bien déterrer les vieux trolls ;)
                                              5) c'est vendredi.

                                              Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                                          • [^] # Re: Mwai

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

                                            Moi je me souviens très bien de l'arrivée de pulseaudio, qui a foutu en l'air plein de truc qui marchaient; perso j'étais sous arts (artsd) à l'époque, j'avais tout qui marchait, (dont l'usage à travers de réseau), et lorsque pulseaudio a été imposé par la distrib, ça a tout cassé.

                                            Sauf erreur de ma part, aRts a cessé d'être développé en 2004 (due to a variety of fundamental development and technical issues, cf wikipedia), et pulseaudio a été installé par défaut sur Ubuntu (une des premières distribs à l'avoir installé par défaut) à partir de 2008.

                                            Et puis faire marcher l'ensemble des applis Linux à l'époque de aRts, il fallait quand même drôlement s'accrocher, avec des couches de compatibilité dans tous les sens, parce qu'entre oss, alsa, aRts, et esd, c'était pas folichon.

                                            Et pulseaudio fait bien plus que ce que faisait aRts (une gestion simple du multi carte-son, ce qui est loin d'être un cas particulier aujourd'hui).

                                            • [^] # Re: Mwai

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

                                              Je rajoute aussi que systemd n'est pas un système d'init. C'est un ensemble de logiciels bas niveau (tout comme kde est un ensemble de logiciels graphiques). Du coup, oui, il est moins complexe à comprendre que ce qu'il remplace.

                                      • [^] # Re: Mwai

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

                                        C'est simpliste comme raisonnement. La question n'est pas celle de la responsabilité (évidemment que le composant qui a le bug est responsable, et doit être corrigé), mais du maintien des fonctionnalités: si il existe un moyen de faire marcher, aussi moche soit-il, il est normal que tout composant ne l'utilisant pas soit perçu comme fautif.
                                        En gros, non il n'est pas normal de remplacer un composant qui marche par un autre qui marche moins sous prétexte qu'un tiers est pourri. La bonne démarche est de (faire) corriger les bugs, puis seulement de procéder au remplacement, et d'utiliser les contournements dans l'intervalle. Forcément ça prend plus de temps (notamment parce qu'on ne peut pas mettre la pression sur le composant fautif par le biais d'utilisateurs frustrés), mais au moins il n'y a pas de dommages collatéraux.

                                        Sinon en allant par là on pourrait aussi estimer que les applis n'ont pas à contourner les bugs des libs, les libs n'ont pas à contourner les bugs des drivers, les drivers n'ont pas à contourner les bugs du noyau, le noyau n'a pas à contourner les bugs du compilateur, et le compilateur n'a pas à contourner les bugs du CPU (et du reste du matos d'ailleurs). Alors oui, à la fin on aurait sans doute un système très élégant où tout le monde fait exactement ce qu'il doit…
                                        Ou alors peut-être qu'on n'aurait rien du tout parce que tout le monde serait en train d'attendre qu'un fondeur produise le CPU parfait, alors qu'aucun fondeur ne survit plus de 3 mois puisque virtuellement personne n'achète de CPU (pourquoi faire quand on n'a même pas de compilo fonctionnel?)

                                        Bref, sans pragmatisme on ne va pas très loin. Ou, dit autrement, le fantasme de la réécriture complète qui va corriger tous les problèmes par la pureté architecturale n'est que ça, un fantasme. De ce point de vue la gestion de l'introduction de PA était un désastre: pas d'un point de vue "scientifique", mais d'un point de vue d'ingénieur.
                                        La seule raison pour laquelle c'est "passé", c'est que ce n'était "que" de l'audio.

                                        C'est un fait, en matière d'informatique le monde entier tourne sur des workarounds dégueu.

                                        • [^] # Re: Mwai

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

                                          Tu oublis que les problèmes ont été révélés grâce à PulseAudio, pas avant, donc quand certaines distributions comme Fedora ont rempli des rapports de bogues là dessus il me semblait bien plus sage d'attendre la correction dans le noyau directement plutôt que d'attendre et de corriger à l'arrache dans PulseAudio.

                                          • [^] # Re: Mwai

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

                                            tu rigoles ça fait des années que des serveurs audio sont pondu pour palier aux déficiences d'alsa (et de OSS version linux avant) pulseaudio n'a été que le nième révélateur de ces problèmes.

                                        • [^] # Re: Mwai

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

                                          En gros, non il n'est pas normal de remplacer un composant qui marche par un autre qui marche moins sous prétexte qu'un tiers est pourri.

                                          Sauf que Lennart n'a rien remplacé. Il a proposer et des mainteneurs de distributions ont décidés de replacer.

                                  • [^] # Re: Mwai

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

                                    Une partie au moins devait être dû à la complexité inhérente de PulseAudio, dont Lennart Poettering, probablement plus réaliste que ses fan-boys, est d’ailleurs bien conscient. Il n’a jamais caché que « intégrer PulseAudio dans une distribution n’est pas une mince affaire » — “Adopting PA in a distribution is a fair amount of work, given that it interfaces with so many different things at so many different places.”

                              • [^] # Re: Mwai

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

                                « Après, il faut la lire et la comprendre… Mais ça reste le boulot des intégrateurs, je ne connais plus une seule distrib ou pulseaudio ne fonctionne pas out of the box. »

                                C'est peut-être là que le bat blesse : d'antan l'étape intégrateur n'était pas indispensable. Le pékin moyen (sous linux, pas Mme Michu) pouvait s'installer à peu près n'importe quel programme. En ce qui me concerne, j'ai essuyé mes premiers échecs définitifs à installer/configurer des programmes (autrement fonctionnels) à la main seulement très récemment, après plus de 15 ans sous Linux ou autres Unix. Alors même si je ne souhaite pas prendre position dans la querelle des anti/pro systemd c'est vrai que cet état de fait ne laisse pas de me chagriner. J'aurais apprécié, en tant qu'utilisateur moyennement averti, de ne pas me retrouver laissé sur le bord de la route par l'apparition de docs outrageusement techniques et jargonneuse que je ne suis plus capable d'employer, et qui sont visiblement destinées uniquement à des intégrateurs experts.

                                • [^] # Re: Mwai

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

                                  D'un autre côté, toute l'informatique était plus simple avant.
                                  Avant n'importe quel programmeur était capable d'avoir une bonne vision du code de la plupart des logiciels qu'il utilisait, il pouvait connaître le fonctionnement de son matériel et l'exploiter très facilement. Aujourd'hui rien qu'une CG c'est bien plus complexe que n'importe quel ordinateur du début des années 90. Maîtriser la pile réseau ou USB d'un OS est un véritable challenge (les normes étant très volumineuses), tu as des couches d'abstraction de partout et de la sécurité de partout là où avant tu pouvais faire n'importe quoi n'importe quand.

                                  Les programmes aussi ont grossi et se complexifient, plus personne ne connait le code de Linux ou d'un autre gros programme sur le bout des doigts, ils sont trop gros alors qu'avant même un développeur moyen pouvait maitriser tout ceci.

                                  Bref, c'est inhérent à toute l'informatique, cet univers évolue trop vite pour que tout le monde suive et s'est énormément complexifié pour répondre aux besoins de tous ce qui laisse sur le carreau de nombreux amateurs. Mais c'est comme ça et ce n'est pas propre au libre ou à Linux en lui même.

                                  L'informatique est peut être le seul domaine et la seule science où personne n'a maitrisé tout l'état de l'art à un instant t car comme tout secteur après la 1ère GM, ça évolue trop vite pour qu'une personne seule puisse suivre le rythme.

                                  • [^] # Re: Mwai

                                    Posté par . Évalué à 7. Dernière modification le 29/11/14 à 15:32.

                                    D'un autre côté, toute l'informatique était plus simple avant.

                                    J'aime bien cette phrase. J'ai fait le même constat.

                                    Mais, plutôt que de me dire «l'informatique est devenue compliquée et il faut s'y faire», j'ai tenté de répondre à la question «pourquoi?»

                                    Il n'y a pas qu'une seule réponse. Mais ce que j'ai constaté — et de plus en plus — c'est que les gens, dont les développeurs, ont de moins en moins la capacité à comprendre l'énoncé d'un problème et ont de moins en moins la capacité à résoudre un problème complexe autrement qu'en mettant en place des solutions compliquées (j'utilise complexe et compliquée à dessein). J'ai fait ce constat en observant les gens autour de moi (mais pas seulement), ainsi que les logiciels mis en place et en faisant bilan sur bilan tout au long de ma vie.

                                    L'informatique est-elle donc plus compliquée? ou plus complexe?

                                    Est-elle plus compliquée? Impossible de répondre sans généralisation excessive. Mais si elle est plus compliquée, c'est peut-être aussi parce que ceux qui sont derrière n'ont pas la capacité à trouver une solution logique et optimisée à un problème complexe. J'insiste sur le fait que «complexe» et «compliqué» ne sont pas inter-dépendants.

                                    Est-elle plus complexe qu'avant? Certainement. Mais si c'est le cas, est-ce que cela justifie des solutions si compliquées, que seuls des experts de haut niveau soient à mêmes de les comprendre et de les maîtriser?

                                    Parfois il est des problèmes qui ne doivent pas être résolus. Je veux dire par là que, lorsqu'on définit un projet, une limite claire et incontestée doit être tracée entre les problèmes inhérents au projets, c-à-d auxquels le projet lui-même fournit une solution et ceux qui sont hors-sujet. Or c'est précisément définir ce qui est hors-sujet la tâche la plus ardue et la tentation est grande. Vouloir résoudre des problèmes qui n'entrent pas dans le cadre du projet rend la solution finale non seulement complexe mais compliquée.

                                    Pendant l'évolution d'un projet, grande est la tentation à ajouter des fonctionnalités. Mais avec l'ajout de fonctionnalités, si elle n'a pas été planifiée scrupuleusement depuis le début, il arrive que certaines d'entre elles remettent en cause la raison même de l'existence du projet. Ceci n'est qu'un exemple de ce que j'ai observé. Il en résulte des projets tentaculaires, des monstres voraces en ressources ou que sais-je encore.

                                    Dans mon expérience personnelle, par exemple, j'ai rarement vu des projets qui prenaient en compte les aspects sociaux et humains. Il n'est pas rare d'entendre «C'est à l'utilisateur de s'adapter» ou «Il faut vivre avec son temps», qui vont à l'encontre des bases de l'analyse des systèmes d'information. Et ce sont des phrases de ce type qui sont invoquées lorsque des utilisateurs, réfractaires aux changements, provoquent la lassitude et l'agacement des intégrateurs. Et c'est cet agacement qui provoque l'erreur classique consistant, in fine, de guerre lasse, à appliquer cette sentence à tous ceux qui s'y opposent, fourrant dans le même sac opposants légitimes et crétins réfractaires-tout-court. On pourrait comparer cette situation à la loi de Godwin dans les discussions: classer les opposants à un projet dans une catégorie revient à tomber dans le cliché du nazisme dans une discussion qui s'éternise et qui finit par lasser. Dans tous les cas, c'est l'incompréhension et la frustration qui gagnent.

                                    Je ne dis pas que systemd répond à ce paradigme mais je retrouve dans les litanies d'opposition à systemd des arguments que j'ai moi-même observés depuis le début de ma carrière, bien avant qu'on parle de systemd. C'est suffisant pour moi à considérer que ceux qui s'opposent à ce projet ont probablement de bonnes raisons de le faire. Ceci ne signifie pas qu'il n'y a pas, dans le tas, de crétins sectaires et conservateurs mais ranger, improprement, tous les contestataires dans cette catégories est une grave erreur de jugement.

                                    • [^] # Re: Mwai

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

                                      Moi aussi, j'ai tendance à penser comme ça, instinctivement. C'est important, l'instinct. Statistiquement, trop de gens critiquent systemd pour qu'il n'y aie pas anguille sous roche. Dans la vraie vie c'est pareil. J'aime bien aussi quand on me dit "tu as juste peur" comme si la peur ne servait pas aussi à se protéger. Red flags rising. Ce mouvement de foule m'en rappelle d'autres.

                                      Si j'étais un ennemi de GNU/Linux (Naaan, impossible, hein ?) mon seul souhait serait que toutes les distros y passent, pour pouvoir planifier un futur à plus ou moins long terme où tous les postes sous Linux sont sous systemd. C'est logique : Si ton ennemi est trop compliqué, simplifie-le. Je vois déjà poindre les commentaire doux-amers à base de security through obscurity, faites-vous plaize. Si ton ennemi est multiple, réduis-le.

                                      Mais moi je suis un conspirationniste qui suinte la haine et glace le sang, faut prendre ça en compte aussi :p

                                • [^] # Re: Mwai

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

                                  qui sont visiblement destinées uniquement à des intégrateurs

                                  Faut pas abuser non plus, la doc de pulseaudio est compréhensible, je dis juste que ça "juste marche".

                                  Sinon, je galérais plus sous Linux y'a 15 ans quand je devais compiler 15 libs juste pour lire un divx avec LAMP…

                                  Linux A??? Media Player, quelqu'un se souvient ce que voulait dire la A? C'était un soft développé par un étudiant français.

                                  • [^] # Re: Mwai

                                    Posté par . Évalué à 2.

                                    Linux A??? Media Player, quelqu'un se souvient ce que voulait dire la A? C'était un soft développé par un étudiant français.

                                    A pour Animation http://pauillac.inria.fr/lamp/

                                • [^] # Re: Mwai

                                  Posté par . Évalué à 9.

                                  On parle pas d'un logiciel que tu ./configuke && make && make install là, mais d'une brique du systeme.

                                  • Pour avoir alsa sous Linux 2.4 c'était un peu plus compliqué que ça aussi (patch du noyau, interfaçage avec le serveur de son quasi-obligatoire à cette époque)
                                  • Pour installer et configurer PAM en 1999 fallait s’accrocher aussi, et apprendre des concepts totalement nouveaux.
                                  • L'arrivée de HAL et de sa clique (on appelait cet ensemble comment d'ailleurs à l'époque ?) en 2005 a bien fait baver les Linuxiens devant de bô screenshots, mais pour l'installer et l’intégrer au systeme, merci !

                                  Non les briques de base du systeme n'ont jamais été faciles à installer, surtout quand tu veut être en avance sur ton temps en utilisant un distrib testing (donc avec des programmes pas encore totalement intégrés/configurés dedans) voir encore plus en installant les nouveautés toi-même pour griller tout le monde.

                                • [^] # Re: Mwai

                                  Posté par . Évalué à 9.

                                  Le pékin moyen (sous linux, pas Mme Michu)

                                  C'est qui le pékin moyen sous Linux ?

                                  D'expérience, parmi les utilisateurs de Linux, on voit vraiment de tout. Tu as des devs, des vrais, des barbus, qui prennent du café en argument et retournent du C++. Tu as des profils moins, voire pas du tout techniques, qui trouvent l'éthique du logiciel libre intéressante. Tu as quelques types dont la machine Windows avait tellement ralenti à coup de bloatwares que Linux lui a offert une seconde vie. Tu as la mère/la grand-mère/la copine (et leurs équivalents de sexe masculin) de linuxiens, elles veulent que ça juste marche, et coup de bol, ça juste marche. Tu as des opposants chinois/syriens/cubains/whatever. Tu as des sysadmins comme des utilisateurs de machines de bureau. Tu commences même à avoir des gamers ! Et encore, là je te présente des catégories discrètes mais tu as tout un continuum au sein de chacune.

                                  Au final, il y a une telle diversité d'usages et de profils que la notion de moyenne n'a pas grand sens. On a des groupes, assez hétérogènes, mais aux frontières poreuses malgré tout. Ce qui ne fait que refléter la diversité des usages de l'informatique au sens large.

                                  Et c'est tant mieux ! C'est comme ça que Linux a une chance de se démocratiser. Si la liberté 0 était une condition sine qua non, les libertés 1 et 3 seraient fictives et le logiciel libre ne libérerait finalement que du code (pour citer un blog bien connu). Il est là le boulot des intégrateurs ! Il permet à des gens dont les connaissances techniques sont faibles, nulles, ou orientées dans un autre domaine d'utiliser des logiciels efficaces, de qualité, et qui marchent, honnêtement, remarquablement bien quand on voit à quelles tortures on les soumet.

                                  Ça, ce sont les sources. Le mouton que tu veux est dedans.

                        • [^] # Re: Mwai

                          Posté par . Évalué à 10.

                          Autre gros point faible: quasi tout les projets de Lennart sont très mal documentés.

                          La doc de systemd est très bonne et complète. De plus, c'est le système d'init le plus documenté que j'ai jamais vu. Quand on compare à la non-doc de SysV ou Upstart, y'a pas photo !

                          Le fait que Lennart travail pour RedHat, et le fait que RedHat controle quasi entièrement Fedora et RHEL a fortement aidé à l'adoption de systemd. Le libre, ce n'est pas que des gens qui travaillent sur leur temps libre.

                          Non, systemd a aussi reçu beaucoup de résistance interne chez RH et a été au départ un sideproject de Lennart. Et Archlinux a été une des premières à l'adopter, pour les raisons expliqués ici : pas de trace de RH là dedans.

                          C'est un petit peu des deux. systemd est intéréssant, mais systemd est trop complexe, trop gros (80 binaires qui font des choses totalement différentes et normalement indépendante : logind, udev, networkd, …),

                          D'un autre côté, systemd est plus « performant », plus standardisé, peut-être plus facile à utiliser pour les developeur.

                          Il est plus facile à utiliser, tout simplement : plus de fiabilité, plus de retour sur les problèmes, plus d'informations utiles dans le journal, etc…

                          Si on me paye pour ça, si on me donne la capacité de le mettre ensuite par défaut dans deux des plus grosses distributions Linux, je fonce, comme Lennart. Sortir cet argument à chaque fois c'est vraiment de mauvaise foi.

                          Et concrètement ? Un pot de vin aux mainteneurs, tu crois ? Ha !

                          En plus il est fait en sorte que se soit difficile d'écrire une alternative car ils « standardisent » tout, en utilisant dbus, même des modules qui sont en théorie parfaitement indépendant d'un système d'initialisation, udev et networkd sont les exemples parfait. Ensuite les pro-systemd viennent dire : « Ah mais tu peux réécrire chaque module de systemd, ils sont totalement indépendants car ils utilisent une interface dbus standardisée ». Beuuuuurk.

                          networkd est optionnel.
                          udev permet de peupler /dev, c'est un peu important pour booter.

                          Et oui, systemd est un ensemble d'outils maintenus dans un seul dépôt, "à la BSD" : ça permet d'avoir un tout cohérent.

                          Quant au fait que faire une alternative à systemd revient à re-créer systemd : ça tient du fait que systemd est généralement adopté et que revenir en arrière ne sera pas accepté.

                          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                        • [^] # Re: Mwai

                          Posté par . Évalué à 10.

                          mais systemd est trop complexe, trop gros (80 binaires qui font des choses totalement différentes et normalement indépendante : logind, udev, networkd, …)

                          Tu suggeres quoi alors?
                          Qu'on mette les 80 binaires en un? En quoi ca va arranger les choses?
                          Qu'on sorte les 80 binaires de systemd et dans leur propre projet? En quoi ca changerais la complexite? Ca revient juste a changer leur nom, ca va pas nous avancer des masses.
                          Qu'on se separe des 80 binaires tout simplement? Et que donc on se passe des fonctionalites des 80 binaires (qui servent bien a quelque chose quand meme, quoi que t'en penses).

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

                          • [^] # Re: Mwai

                            Posté par . Évalué à -8.

                            Qu'on sorte les 80 binaires de systemd et dans leur propre projet? En quoi ca changerais la complexite? Ca revient juste a changer leur nom, ca va pas nous avancer des masses.

                            C'est exactement ce que je suggérerai. C'est même exactement ce que je ferais. Cela permet d'avoir des interfaces claires, des trucs (plus) facilement debugable et maintenable et cela permettrait aux autres de facilement développer une alternative. De mon point de vue, on perd en complexité, on divise le problème en plusieurs sous problèmes indépendant.

                            • [^] # Re: Mwai

                              Posté par . Évalué à 10.

                              En quoi on aurait des interfaces plus claires?
                              Tu changes juste le nom du projet, ca va pas magiquement resoudre le probleme de l'interdependence intrinseque de tous ces composants. Au contraire, ca va juste rendre plus dure la tache de comprendre le tout.

                              Dit autrement, les 80 binaires ne sont pas le probleme, le probleme c'est qu'un systeme d'init moderne est complexe par nature. Gueuler sur lennart va pas changer grand chose au probleme, et on entends pas beaucoup de suggestion constructives, juste des gens qui gueulent que "pffouuulala, l'informatique, c'est dur de nos jours, c'etait mieux avant quand ca en faisait vachement moins".

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

                              • [^] # Re: Mwai

                                Posté par . Évalué à 2.

                                En quoi on aurait des interfaces plus claires?

                                Parceque justement, si on veut que tout fonctionne bien il faut que « l'interface » soit claire. Il faut que le rôle du programme soit clairement établi.

                                Tu changes juste le nom du projet, ca va pas magiquement resoudre le probleme de l'interdependence intrinseque de tous ces composants. Au contraire, ca va juste rendre plus dure la tache de comprendre le tout.

                                Tu ne changes pas juste le nom, tu le rends independant, et c'est là ou est la différence majeure. Dit moi, tu comprends mieux comment fonctionne un système d'init (si on peut encore appeller cela comme ça) aujourd'hui (systemd upstart), ou avant, à l'époque de SysvInit/runit/etc.. ? Moi c'était avant.

                                Dit autrement, les 80 binaires ne sont pas le probleme

                                C'est très juste.

                                le probleme c'est qu'un systeme d'init moderne est complexe par nature.

                                Non, je ne pense pas. Bon il faut maintenant clairement définir ce qu'est un système d'init, parceque si on considère que tout ce que fait systemd (y compris networkd et les autres) fait partie du rôle du système d'init, alors oui, c'est complexe. Mais le système d'init n'est pas censé s'occuper du réseau, s'occuper de /dev, il est censé coordonner l'initialisation de ton système. Et la, c'est plus simple.

                                Gueuler sur lennart va pas changer grand chose au probleme, et on entends pas beaucoup de suggestion constructives, juste des gens qui gueulent que "pffouuulala, l'informatique, c'est dur de nos jours, c'etait mieux avant quand ca en faisait vachement moins".

                                Exactement comme l'argument du « Ben vasi, fork ! », c'est de mauvaise foi. Mon temps n'est pour l'instant pas infini.

                                • [^] # Re: Mwai

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

                                  Dit moi, tu comprends mieux comment fonctionne un système d'init (si on peut encore appeller cela comme ça) aujourd'hui (systemd upstart), ou avant, à l'époque de SysvInit/runit/etc.. ? Moi c'était avant.

                                  Si tu parles du fonctionnement interne du système d'init (le code), alors ça ne change rien, je ne le connais pas plus maintenant qu'avant.

                                  Si tu parles de comment utiliser le système d'init, alors je trouve ça plus facile maintenant. Un tas de scripts d'init étaient imbitables, différent d'une distribution à une autre, non-documentés…

                                  C'est vachement plus facile pour moi aujourd'hui d'écrire un script d'init que ça ne l'était avant, et je peux le faire avec plus de fonctionalités.

                                  • [^] # Re: Mwai

                                    Posté par . Évalué à -2.

                                    C'est vachement plus facile pour moi aujourd'hui d'écrire un script d'init que ça ne l'était avant, et je peux le faire avec plus de fonctionalités.

                                    Si l'on compare SysVInit et systemd, je te rejoins. Mais par exemple je trouve runit (par défaut dans Debian 6 je crois bien) plus facile à utiliser, et beaucoup plus souple. Je faisais quasi tout avec runit et j'en était très très content.

                                • [^] # Re: Mwai

                                  Posté par . Évalué à 5.

                                  Exactement comme l'argument du « Ben vasi, fork ! », c'est de mauvaise foi. Mon temps n'est pour l'instant pas infini.

                                  Et les dév de LL ont un bien sûr un temps infini qui doit servir à régler tes problèmes ? Qu’est-ce qu’on doit comprendre ? Tu n’as pas le temps… mais les autres devrait l’avoir ?

                                • [^] # Re: Mwai

                                  Posté par . Évalué à 10.

                                  Parceque justement, si on veut que tout fonctionne bien il faut que « l'interface » soit claire. Il faut que le rôle du programme soit clairement établi.

                                  Ah ben heureusement que t'es la pour accorder le peu de ton temps disponible a lennart et lui donner des conseils, parce qu'il y avait pas pense. D'ailleurs personne n'y avait pense.

                                  Bon, maintenant que tu nous a rappele ce qu'on apprends aux etudiants a leur deuxieme cour d'informatique en deug, si tu passais a la vitesse superieure?
                                  Prend n'importe lequel de ces 80 binaires, et explique nous en quoi son role est mal defini, et ce que tu ferais pour le definir plus precisement, ainsi que comment tu modifierais son interface.

                                  Mais le système d'init n'est pas censé s'occuper du réseau, s'occuper de /dev, il est censé coordonner l'initialisation de ton système. Et la, c'est plus simple.

                                  Oui, c'est sur que quand on remplace des actions concretes par une vague phrase qui ne veut pas dire grand chose, ca parait plus simple. Qu'est ce que tu disais deja sur l'importance d'avoir des roles clairement definis?
                                  Tant qu'on y est , si tu pouvais nous expliquer en quoi sysv coordone quoi que ce soit, ca serait sympa. De ce que j'en sait, sysv coordonne pas grand chose, il se contente de lancer des scripts dans un ordre defini par l'utilisateur, qui se coordonent tant bien que mal eux meme.

                                  Et d'ailleurs, en quoi le reseau et /dev ne font pas partie de l'init? Remplir /dev, ca parait etre qq chose d'assez important a l'init quand meme, non? Ca va etre vachement plus dur de demarrer si tes disques ne sont pas dans /dev, tu crois pas?
                                  Et demarrer tes services reseaux, ton pare feu et ce genre de choses, ca marcherait pas un chouilla mieux apres que tes interfaces reseaux soient montees?

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

                                  • [^] # Re: Mwai

                                    Posté par . Évalué à -1.

                                    Ah ben heureusement que t'es la pour accorder le peu de ton temps disponible a lennart et lui donner des conseils, parce qu'il y avait pas pense. D'ailleurs personne n'y avait pense.

                                    « le peu de ton temps disponible », non, ne me fait pas passer pour le chevalier blanc, ni batmand.
                                    « et lui donner des conseils », je ne lui donne pas de conseils, je dis juste comment j'aurais fait, et peut-être comment je ferais.
                                    « parce qu'il y avait pas pense. D'ailleurs personne n'y avait pense. », FUD ? Je crois bien oui…

                                    Bon, maintenant que tu nous a rappele ce qu'on apprends aux etudiants a leur deuxieme cour d'informatique en deug, si tu passais a la vitesse superieure?

                                    Voila. Si tu as la flemme de cliquer, je pourrais résumer assez facilement: « on nous apprend à être des automates de traduction UML vers Java ».

                                    Prend n'importe lequel de ces 80 binaires, et explique nous en quoi son role est mal defini, et ce que tu ferais pour le definir plus precisement, ainsi que comment tu modifierais son interface.

                                    Je veux bien mais cela vas me prendre beaucoup de temps : je le ferais plus tard, quand la motivation sera revenu. Je dit ceci car cela doit faire à peu près 1 heure que j'écris ce commentaire et je commence à saturer.

                                    Oui, c'est sur que quand on remplace des actions concretes par une vague phrase qui ne veut pas dire grand chose, ca parait plus simple.

                                    Okay, tu m'en veux et je ne sais pas pourquoi.

                                    Qu'est ce que tu disais deja sur l'importance d'avoir des roles clairement definis?

                                    L'importance d'un rôle clairement défini, c'est que cela vas directement dans le sens de la fameuse maxime (version courte) : « Écrivez des programmes qui effectuent une seule chose et qui le font bien ». Et si tu veux comprendre pourquoi c'est important, je t'invite avec enthousiasme à lire « The Art Of Unix Programming » (TAOUP). Car non seulement tu trouveras une réponse bien meilleur que ce que j'aurais pu t'écrire, mais aussi parceque cela ne concerne pas uniquement UNIX, mais belle et bien la programmation en général.

                                    D'ailleurs, je ferais bien enseigner la plupart des principes et de la méthodologie présente dans le TAOUP en DUT. Sisi, tu peux d'ores et déjà cliquer sur « inutile », si ce n'est pas déjà fait.

                                    Tant qu'on y est , si tu pouvais nous expliquer en quoi sysv coordone quoi que ce soit, ca serait sympa. De ce que j'en sait, sysv coordonne pas grand chose, il se contente de lancer des scripts dans un ordre defini par l'utilisateur, qui se coordonent tant bien que mal eux meme.

                                    Il est vrai que « coordonner » n'est peut-être pas le meilleur mot, mais tu as parfaitement décrit l'idée : « il se contente de lancer des scripts dans un ordre defini par l'utilisateur ». C'est simple, c'est efficace, ça marche. Comme systemd à ses début. Oh oui, si Lennart et les autres contributeurs avaient cessé d'ajouter des fonctionnalités, je n'aurais rien à dire. En gros avant que systemd ne « mange » udev, systemd faisait son boulot, et rien d'autre.

                                    Et d'ailleurs, en quoi le reseau et /dev ne font pas partie de l'init? Remplir /dev, ca parait etre qq chose d'assez important a l'init quand meme, non? Ca va etre vachement plus dur de demarrer si tes disques ne sont pas dans /dev, tu crois pas?

                                    Lancer le programme qui gère le réseau et le programme qui gère /dev fait partie de l'init, mais gérer le réseau et /dev ne font clairement pas partie de l'init. Si tu comprends toujours pas alors je ne vois vraiment pas comment l'expliquer. C'est la différence qu'il y a entre « lancer » (ou exécuter) et « gérer ».

                                    Et demarrer tes services reseaux, ton pare feu et ce genre de choses, ca marcherait pas un chouilla mieux apres que tes interfaces reseaux soient montees?

                                    Sisi, d'ailleurs c'est à cela que servent les systèmes d'init normalement : gérer l'ordre de lancement des programmes, comme tu l'as si bien décrit plus haut.

                                    • [^] # Re: Mwai

                                      Posté par . Évalué à 4.

                                      Blabla, tu tournes autour du pot, au final tu dis rien de concret, a part enoncer des banalites vielles de 35 ans sans expliquer en quoi les choses sont mal faites, tout ca pour finir par un "j'expliquerais plus tard, j'ai la flemme la".
                                      Mais bizarrement, t'as quand meme prit le temps de pondre un long commentaire.

                                      Lancer le programme qui gère le réseau et le programme qui gère /dev fait partie de l'init, mais gérer le réseau et /dev ne font clairement pas partie de l'init.

                                      Ca tombe bien, ils ne font pas partie de l'init, c'est pour ca qu'ils sont dans des binaires a part. Par conre, il semble qu'ils soient suffisament proche de l'init pour justifier une integration poussee avec systemd, ce qui est justement la discussion ici. Ca aide beaucoup que systemd soit au courant de ce qu'ils ont fait/ou ils en sont pour savoir ce qu'il doit faire ensuite.

                                      Sisi, d'ailleurs c'est à cela que servent les systèmes d'init normalement : gérer l'ordre de lancement des programmes, comme tu l'as si bien décrit plus haut.

                                      Tout le monde n'est pas d'accord, visiblement. Macosx a launchd, solaris smf. Meme windows le gueux a un fonctionnement similaire.

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

                            • [^] # Re: Mwai

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

                              Rassure moi, t'es pas développeur?

                              • [^] # Re: Mwai

                                Posté par . Évalué à -2.

                                Haha, non, je suis programmeur.

                                • [^] # Re: Mwai

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

                                  Je vais répondre à ton post précédent… Tu veux que chaque binaire assure un rôle établi mais sauf erreur de ma part,c'est le cas des binaires de systemd,en tout cas plus que le nombre de commandes internes d'un shell…
                                  Dire que sysvinit était moins complexe que systemd,c'est juste oublier qu'il est basé sur un composant complexe dont le rôle dans l'init de ta machine est encore plus absurde que networkd…

                            • [^] # Re: Mwai

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

                              De mon point de vue, on perd en complexité, on divise le problème en plusieurs sous problèmes indépendant.

                              On perdrait en factorisation, c’est certain.
                              Mais en complexité, j’ai des doutes.

                              La factorisation du code, c’est le point que j’apprécie le plus dans l’adoption de systemd (l’éco-système) par la plupart des grandes distributions.

                              • [^] # Re: Mwai

                                Posté par . Évalué à 0.

                                La factorisation du code, c’est le point que j’apprécie le plus dans l’adoption de systemd (l’éco-système) par la plupart des grandes distributions.

                                De quel « code » parles tu ? Si tu parles du code source, il y a peu de réutilisation dans le code de systemd. Et ce n'est pas très étonnant car il n'y pas vraiment de parties commune dans networkd et dans logind par exemple…

                                • [^] # Re: Mwai

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

                                  Le code des scripts d'init. Fini les 150 implems quasi (tout est dans le quasi) identique de start/stop/restart (si je l'implémente en faisant stop puis start, je mets un sleep entre les deux ? si oui, de combien de secondes ? je fais quoi si le stop n'a pas tout stoppé ? et d'abord je le sais comment qu'il a pas tout stoppé ?) et j'en passe.

                        • [^] # Re: Mwai

                          Posté par . Évalué à 6.

                          C'est un petit peu des deux. systemd est intéréssant, mais systemd est trop complexe, trop gros (80 binaires qui font des choses totalement différentes et normalement indépendante : logind, udev, networkd, …)

                          Pourquoi est ce que ce sont des choses "normalement indépendante" ? Qu'est ce qui interdit à un meme projet de fournir des outils pour ces differentes choses ?

                          mkdir et md5sum ce sont des commandes totalement différentes, et pourtant elles font toutes les 2 partie de coreutils (qui lui meme fait partie du projet GNU).

                          Et de manière generale, le projet GNU fournit tout un tas d'outils pour faire des choses totalement différentes. Et ca n'a l'air de déranger personne.

                          et enfin difficile à maintenir.

                          Les developeurs de systemd n'ont pas l'air d'avoir de problème particulier à le maintenir.

                          Si on me paye pour ça, si on me donne la capacité de le mettre ensuite par défaut dans deux des plus grosses distributions Linux, je fonce, comme Lennart. Sortir cet argument à chaque fois c'est vraiment de mauvaise foi.

                          Oui par ce qu'il est evident que systemd a été adopté par tout un tas de distribution uniquement par ce que Lennart travail pour Red Hat.

                          En réalité, systemd a été introduit dans Fedora en suivant le processus normal. Et les gens qui se sont chargés de l'introduire dans differentes distributions ont été convaincus de l'interet de systemd par ce que Lennart a été capable de l'expliquer de facon convainquante (voir les nombreux postes sur son blog qui expliquent en detail toutes les raisons qui ont poussé à la création de systemd), pas par ce qu'il y a ecrit Red Hat sur sa carte de visite.

                          En plus il est fait en sorte que se soit difficile d'écrire une alternative car ils « standardisent » tout, en utilisant dbus, même des modules qui sont en théorie parfaitement indépendant d'un système d'initialisation, udev et networkd sont les exemples parfait. Ensuite les pro-systemd viennent dire : « Ah mais tu peux réécrire chaque module de systemd, ils sont totalement indépendants car ils utilisent une interface dbus standardisée ». Beuuuuurk.

                          Et tu proposes quoi ? De surtout pas standardiser de moyen de communication entre les differents modules ? En quoi standardiser cela est il une mauvaise chose ?

                          Autre gros point faible: quasi tout les projets de Lennart sont très mal documentés.

                          C'est une blague ?

                          Il faut vraiment etre de mauvaise fois pour affirmer que systemd est très mal documenté …

                          Le blog de lennart contient des tas de tutoriels pour présenter toutes les fonctionnalités de systemd, et toutes les options sont documentées dans des pages de man.

                    • [^] # Re: Mwai

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

                      son retrait partiel ou total du monde Linux ne me touchera pas.

                      C'est l'avantage avec toi, pas besoin de souhaiter ton retrait vu que tes contributions doivent se résumer à peau de zob…

                    • [^] # Re: Mwai

                      Posté par . Évalué à 10.

                      Maintenant à l'inverse son maintien dans Linux, avec sa capacité à détruire l'expérience utilisateur et son dedain vis à vis de toute tentative de création d'environnement un poil perenne, me casse franchement les pieds.

                      Alors chez moi avahi je m'en suis jamais servi mais je comprends très bien le besoin.
                      Wikipédia donne l'exemple suivant :

                      Par exemple, un utilisateur peut brancher son ordinateur sur un réseau et trouver instantanément des imprimantes pour imprimer, des fichiers à lire et des personnes à qui parler…

                      Un truc qui automatise la découverte de services, pour moi c'est clairement une amélioration de l'expérience utilisateur.

                      Quant à systemd… Je vais pas tout refaire, mais en gros :

                      • tu as un contrôle plus fiable des services (expérience utilisateur améliorée)
                      • tu as toutes les sorties d'erreurs dans le journal
                      • tu as une compatibilité avec les scripts (on préserve l'expérience utilisateur : au pire, elle est pareil qu'avant)
                      • il va enfin permettre d'avoir la couche TTY en espace utilisateur (un truc léger), et d'abandonner l'horrible couche TTY du kernel sur laquelle même Alan Cox (et beaucoup d'autres) se sont cassé le coccyx.
                      • il permet de résoudre des problèmes tels que :
                        • la prise en charge du multiseat (oui on peut faire sans, mais le but c'est d'avoir la même qualité de support partout, pas juste de la débrouillardise au cas par cas),
                        • avoir xorg rootless (une faille de sécurité en moins, c'est mauvais pour l'expérience utilisateur ?!)
                        • lancer des services utilisateur (systemd --user)
                        • avoir des entrées du journal qui commencent bien plus tôt dans le processus de démarrage qu'avec syslog
                      • etc…

                      Alors oui ce n'est pas le premier systemd-like, ni le premier à résoudre les problèmes que j'ai cité, mais c'est le premier à être accepté par les distributions, et ça change tout. Parce que un systemd super mais utilisé par 3 tondus, c'est joli mais ça sert à rien.

                      D'ailleurs, systemd est tellement "mauvais" qu'il fait fait même des émules chez BSD… ;-)

                      Et pour PulseAudio est aussi clairement un plus pour l'expérience utilisateur :

                      • il a permis de virer beaucoup de bogues dans les pilotes ALSA
                      • il permet de gérer le volume par application
                      • il permet de changer la sortie sonore de n'importe quelle application
                      • essaie de gérer des enceintes bluetooth avec ALSA… tu vas vite revenir vers PA
                      • il est compatible avec l'existant (genre FlashPlayer qui ne connaît que ALSA)
                      • il a une architecture légère (CoW), une latence faible (c'est juste hyper-important pour du son), et il est modulaire
                      • etc …
                      • les cartes sons sont de plus en plus bêtes. En 1998 sur ma AWE64 j'avais du hardware mixing, du MPU-401, de la synthé FM OPL3… y'a rien de tout ça sur un AC'97 ou un bidule HDA aujourd'hui. Tout se fait en espace utilisateur, via PA/ALSA (et Timdity pour le MIDI)

                      Si ce que fait Lennart et ses collègues et si "mauvais", qu'est ce que ça va être quand il va coder sérieusement ! ;-)

                      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                      • [^] # Re: Mwai

                        Posté par . Évalué à 3.

                        Alors pour faire rapide, "casser" l'expérience utilisateur ça veut dire faire qu'un truc qui fonctionnait avant ne fonctionne plus maintenant. C'est parfois nécessaire (mais c'est rare) et c'est parfois même souhaitable (virus et compagnie).
                        Le fait d'apporter quelque chose de nouveau c'est "enrichir" l'expérience utilisateur. Donc Oui Lennart enrichit ET casse l'expérience utilisateur.

                        Cependant ce qui est nocif c'est de n'en avoir rien à faire de casser l'expérience utilisateur, c'est à dire que l'on se moque bien de savoir si il y a des régressions, perte de compatibilité ou autre effets de bords quand on passe de la version N à la version N+1. Et là dessus Lennart est champion. Le problème avec ce genre de direction de projet c'est que du coup une entreprise (c'est à dire un service client à maintenir, des contrats à honorer, des workflow certifiés à respecter etc. ) ne peut pas s'appuyer sur le projet. Parce que rien ne garanti que la version N+1 sera encore compatible avec tout ce qui a été mis en place. Donc on s'en passe.

                        • [^] # Re: Mwai

                          Posté par (page perso) . Évalué à 1. Dernière modification le 27/11/14 à 19:22.

                          T'en as pas marre de raconter des conneries…

                          3 mises à jour de Debian pour un logiciel de backup propriétaire, 3 fois que je modifie le script sysvinit pour qu'il reste compatible…

                          • [^] # Re: Mwai

                            Posté par . Évalué à 4.

                            Là je veux bien que tu détailles. Parce que honnêtement sur Debian même la structure de fichiers est super stable, donc à moins que tu ne sois victime de udisk2 (qui a décidé de jouer les Lennart niveau pérennité) je vois pas trop ce qui peut provoquer ça.

                          • [^] # Re: Mwai

                            Posté par . Évalué à -1.

                            3 mises à jour de Debian pour un logiciel de backup propriétaire

                            De backup propriétaire, tu es sur Debian, c'est l'éditeur du logiciel que tu utilises qu'il faut blamer.

                            3 fois que je modifie le script sysvinit pour qu'il reste compatible…

                            Tu sous entends que toi, tu as des problèmes avec SysVInit, et donc que tout le monde à des problèmes avec SysVInit ?

                            • [^] # Re: Mwai

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

                              De backup propriétaire, tu es sur Debian, c'est l'éditeur du logiciel que tu utilises qu'il faut blamer.

                              Impressionnant la capacité à ne pas voir que l'interface n'est pas stable contrairement à ce que les anti-systemd veulent faire croire.

                              Tu sous entends que toi, tu as des problèmes avec SysVInit, et donc que tout le monde à des problèmes avec SysVInit ?

                              Tiens, remplace SysVInit par systemd dans ta phrase et…

                              De pire en pire les conneries (désolé, pas d'autres mots) qu'on peut lire de la part des anti-systemd.

                              • [^] # Re: Mwai

                                Posté par . Évalué à 3.

                                Impressionnant la capacité à ne pas voir que l'interface n'est pas stable contrairement à ce que les anti-systemd veulent faire croire.

                                Ah non au contraire. J'ai hâte de voir cette interface non stable qui fait qu'après une mise à jour de Debian le script d'init casse. Je suis même vraiment curieux. J'ai même filé une porte de sortie en parlant de udisk2 qui a changé son format de nommage du jour au lendemain (Bon ça fait un cassage, il y en aura encore deux autres à expliquer).

                                • [^] # Re: Mwai

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

                                  J'ai changé de taf et je ne me souviens pas des détails mais bon, un peu de lecture pour toi:
                                  Init script broken

                                  • [^] # Re: Mwai

                                    Posté par . Évalué à 7.

                                    Tu es au courant que sur la recherche que tu me donnes, les 2 premières pages sont exclusivement dues à des mises à jour du script d'init qui ne marche plus ?
                                    Ça clairement ça arrive souvent, tu veux rajouter une option ou corriger un bug dans un script d'init et ça casse quelque chose ailleurs. Mais c'est juste un bug dans le script. Et là c'est pour des scripts génériques qui font 12 000 tests et doivent prendre en compte 200 configurations.
                                    Mais le comportement inverse, I.E je fais une mise à jour du système et mon ancien script d'init ne marche plus sur un binaire qui n'a pas été mise à jour, est rarissime.

                                    J'ai fait des centaines de script d'init et sur des versions early alpha, sur des pull CVS compilés à la mano avec des options bizarres, et même sur du matos pas encore commercialisé avec des pilotes constructeurs à peine sortis du labo. J'ai du avoir peut-être trois ou quatre fois le coup ou après une mise à jour j'ai du modifier le système d'init. Une fois à cause de udisk2 (qu'on a bazardé depuis), une fois suite à une modification de bash (c'était il y a 7 ou 8 ans de mémoire, et encore c'est plutôt de ma faute, j'aurai pas du écrire un script en bash au lieu de sh) et encore une fois parce qu'était passé de DHCPv6 à NDP (donc là encore c'est plutôt de ma faute).

                                    Mais un script d'init qui casse trois fois suite à trois mises à jour Debian sur un binaire qui ne bouge pas, j'ai jamais vu. Donc là je vais me sentir obligé de dire BULLSHIT.

                            • [^] # Re: Mwai

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

                              De backup propriétaire, tu es sur Debian, c'est l'éditeur du logiciel que tu utilises qu'il faut blamer.

                              Bah faudrait savoir, on vient de m'expliquer que sysvinit c'est trop de la balle parce que ça fonctionne sans jamais rien modifier…

                              Tu sous entends que toi, tu as des problèmes avec SysVInit, et donc que tout le monde à des problèmes avec SysVInit ?

                              Oui, tout le monde a des problèmes avec ce truc, en particulier les mecs qui font des distribs, les éditeurs de logiciels, …

                        • [^] # Re: Mwai

                          Posté par . Évalué à 3.

                          une entreprise (c'est à dire un service client à maintenir, des contrats à honorer, des workflow certifiés à respecter etc. ) ne peut pas s'appuyer sur le projet.

                          Trop dur pour les entreprises de ne plus pouvoir compter sur le boulot des autres pour satisfaire ses clients. Et fournir un dév pour maintenir ce qui doit l’être, c’est sans doute trop dur aussi…

                          Donc on s'en passe.

                          Donc, en fait, tout va bien.

                        • [^] # Re: Mwai

                          Posté par (page perso) . Évalué à -4. Dernière modification le 27/11/14 à 19:30.

                          Alors pour faire rapide, "casser" l'expérience utilisateur ça veut dire faire qu'un truc qui fonctionnait avant ne fonctionne plus maintenant.

                          FUD (il ne casse pas plus que les merdes qu'il y avait avant, juste que tu considère "normal" quand ça casse avec les logiciels d'avant que tu ne t'en rends même plus compte).

                          Le problème avec ce genre de direction de projet c'est que du coup une entreprise (c'est à dire un service client à maintenir, des contrats à honorer, des workflow certifiés à respecter etc. ) ne peut pas s'appuyer sur le projet.

                          Ouais, clair, RH et SUSE ils font que de la vente aux particuliers tellement systemd ne répond pas aux besoins des entreprises.


                          Encore une fois, Lennart ne t'empèche aucunement de payers les mainteneurs qui vont se faire chier à maintenir les trucs à l'ancienne (tu as dit n'avoir aucun problème, donc tu n'as aucun problème pour financer le service que toi seul veut aujourd'hui). Lennard ne te fdérange aucunement. Alors pourquoi le détester?


                          C'est triste de lire ce genre de mensonges, aveuglements et incohérances juste à cause de la résistance aux changement… Le conservatiste est très imaginatif dès qu'il faut tout faire pour rester "comme avant" (je viens de sortir d'une A.G. pour un immeuble, j'ai eu le droit aux mêmes délires incohérants sur pourquoi il faut "garder comme avant" des choses, même comportement conservatiste de partout, si ça peut te rassurer)

                          • [^] # Re: Mwai

                            Posté par . Évalué à 10.

                            FUD (il ne casse pas plus que les merdes qu'il y avait avant, juste que tu considère "normal" quand ça casse avec les logiciels d'avant que tu ne t'en rends même plus compte).

                            Je t'invite vivement à lire The Linux Way et également Bashage de Linus
                            On peut aussi citer Ca sert à rien d’espérer que les chose soient différentes de la réalité

                            En ce qui concerne le "cassage" avec les logiciels d'avant (à savoir les API kernel, udev et rsyslog), ça s'est produit (rarement), je m'en suis rendu compte (assez vite je pense - c'est quand même vital ces choses là) - j'ai ouvert des bugs et ça a été corrigé. Je n'ai jamais eu de commentaires du type "Dans 2 mois on casse le truc qu'on a mis en place il y a trois mois, mettez à jour tout de suite ou ne venez pas pleurer plus tard". Et ça tombe bien d'ailleurs, parce que deux mois pour faire les tests de régression sur une archi, c'est quand même très court.

                            Ouais, clair, RH et SUSE ils font que de la vente aux particuliers tellement systemd ne répond pas aux besoins des entreprises.

                            Il font du support développement chez RH et Suse ? Genre si je décide de créer une appli basé sur une fonctionnalité systemd et que cette fonctionnalité disparait ils me filent un billet ? Genre si j'ai des connexions avec udev en netlink ils me filent combien ?
                            Non mais sérieusement, évidemment que RH et Suse sont capable d'adapter leur distrib aux modifs systemd, c'est leur métier - mais toi si tu n'as pas une équipe de 30 devs et les machines de tests qui vont bien en 24/24 je continue franchement à te déconseiller de te baser sur une API systemd pour quoi que ce soit de non trivial.

                            Lennart ne t'empèche aucunement de payers les mainteneurs qui vont se faire chier à maintenir les trucs à l'ancienne

                            Ben vu que notre matériel ne peut pas fonctionner avec systemd, c'est ce qui se passe. Par contre tu fais bien de dire qu'ils se font chier, les pauvres ils n'ont quasiment rien à faire.

                            Lennart ne te dérange aucunement. Alors pourquoi le détester

                            Il ne m'impacte pas, mais il me dérange dans son attitude que ce soit vis à vis du noyau, des divers mainteneurs extérieurs, des utilisateurs etc.

                            C'est triste de lire ce genre de mensonges, aveuglements et incohérances juste à cause de la résistance aux changement…

                            C'est triste les gens bornés. Es-tu tellement sur que la seule raison au monde que pourrait avoir une personne de ne pas vouloir utiliser systemd c'est d'être un vieux schnock aigri, mythomane et réactionnaire ? Si oui je ne peux plus rien pour toi.

                            • [^] # Re: Mwai

                              Posté par . Évalué à 2.

                              Es-tu tellement sur que la seule raison au monde que pourrait avoir une personne de ne pas vouloir utiliser systemd c'est d'être un vieux schnock aigri, mythomane et réactionnaire ?

                              Ça fait pas 10 ans que tu joue ce rôle sur linuxfr ? J'ai un peu souvenir de trolls waylands entre toi et misc ou il réfutait entièrement un post "argumenté" de toi, et je suis à peu prêt certain de pouvoir remonter le temps et trouver d'autres évolutions ou tu joues très bien ce rôle.

                              • [^] # Re: Mwai

                                Posté par . Évalué à 3.

                                J'ai un peu souvenir de trolls Waylands entre toi et Misc ou il réfutait entièrement un post "argumenté" de toi

                                Sur Wayland ? J'ai toujours eu plutôt de la sympathie pour ce projet, à part peut être tout au début. Quand à Misc on s'est frité plusieurs fois sur systemd, mais généralement je répondais à ses arguments.
                                Je viens rapidement de regarder mes commentaires (En tant que Kaane, phxonx ou khane). J'ai souvenir de m'être fait démonté point par point sur OpenGL et sur Erlang principalement, mais sur wayland ? Franchement si tu retrouves la source je veux bien (ceci dit sans aucune arrière pensée)

                            • [^] # Re: Mwai

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

                              En ce qui concerne le "cassage" avec les logiciels d'avant (à savoir les API kernel, udev et rsyslog), ça s'est produit
                              (rarement)

                              T'es plus crédible à la première phrase…

                              Tu te souviens le nombre d'outils différents qu'il y a eu sous Linux avant udev pour faire ce que fait ce dernier aujourd'hui?

                              Alors dire que sous Linux, rien ne casse, c'est juste une grosse blague… Bien, sur avec un exemple comme syslog, tu te mouilles pas trop… Les fichiers de conf de vim n'ont pas bougé non plus, c'est fout ça!

                              Ensuite, tu nous parles des API de systemd mais dans le cas de remplacer un script bash dégueulasse par un fichier d'init systemd, je dis que je vois pas le rapport…

                        • [^] # Re: Mwai

                          Posté par . Évalué à 2. Dernière modification le 27/11/14 à 19:59.

                          Cependant ce qui est nocif c'est de n'en avoir rien à faire de casser l'expérience utilisateur, c'est à dire que l'on se moque bien de savoir si il y a des régressions, perte de compatibilité ou autre effets de bords quand on passe de la version N à la version N+1. Et là dessus Lennart est champion.

                          Source ? Preuves ?

                          Je suis passé par des dizaines de versions de PA et de systemd (j'utilise PA depuis qu'il a été intégré à Ubuntu, et systemd depuis qu'Archlinux l'a adopté vers mi-2012) : aucune régression (j'ai pas dit aucun bug, hein).

                          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                      • [^] # Re: Mwai

                        Posté par . Évalué à -3.

                        Un truc qui automatise la découverte de services, pour moi c'est clairement une amélioration de l'expérience utilisateur.

                        Sur un serveur, ou justement tu cherches à limiter les ressources auxquelles celui-ci se connecte, c'est sur que c'est utile.

                        la prise en charge du multiseat (oui on peut faire sans, mais le but c'est d'avoir la même qualité de support partout, pas juste de la débrouillardise au cas par cas),

                        Sur un serveur, je m'en moque.

                        il permet de changer la sortie sonore de n'importe quelle application
                        essaie de gérer des enceintes bluetooth avec ALSA… tu vas vite revenir vers PA
                        il est compatible avec l'existant (genre FlashPlayer qui ne connaît que ALSA)
                        il a une architecture légère (CoW), une latence faible (c'est juste hyper-important pour du son), et il est modulaire

                        Encore une fois sur un serveur j'en ai rien à faire. Systemd, sur un poste de travail, ça ne me gèil permet de changer la sortie sonore de n'importe quelle application
                        essaie de gérer des enceintes bluetooth avec ALSA… tu vas vite revenir vers PA
                        il est compatible avec l'existant (genre FlashPlayer qui ne connaît que ALSA)
                        il a une architecture légère (CoW), une latence faible (c'est juste hyper-important pour du son), et il est modulaireas plus que ça mais sur un serveur, je ne vois pas à quoi ça sert.

                        • [^] # Re: Mwai

                          Posté par . Évalué à 6.

                          Sur un serveur, ou justement tu cherches à limiter les ressources auxquelles celui-ci se connecte, c'est sur que c'est utile.

                          Si tu installe et actives avahi sur ton serveur, c'est ton problème.

                          Sur un serveur, je m'en moque.

                          Très bien, c'est pas imposé.

                          Encore une fois sur un serveur j'en ai rien à faire.

                          Si tu installe et actives PulseAudio sur ton serveur, c'est ton problème.

                          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                      • [^] # Re: Mwai

                        Posté par . Évalué à -7.

                        Par exemple, un utilisateur peut brancher son ordinateur sur un réseau et trouver instantanément des imprimantes pour imprimer, des fichiers à lire et des personnes à qui parler…
                        ```Un truc qui automatise la découverte de services, pour moi c'est clairement une amélioration de l'expérience utilisateur.
                        

                        En gros un truc qui utilises des ressources pour quelque chose dont j'ai pas besoin au mieux …

                        il permet de résoudre des problèmes tels que :

                        la prise en charge du multiseat (oui on peut faire sans, mais le but c'est d'avoir la même qualité de support partout, pas juste de la débrouillardise au cas par cas),
                        avoir xorg rootless (une faille de sécurité en moins, c'est mauvais pour l'expérience utilisateur ?!)
                        lancer des services utilisateur (systemd --user)
                        avoir des entrées du journal qui commencent bien plus tôt dans le processus de démarrage qu'avec syslog

                        des trucs qui me servent a rien encore

                        il a permis de virer beaucoup de bogues dans les pilotes ALSA
                        il permet de gérer le volume par application
                        il permet de changer la sortie sonore de n'importe quelle application
                        essaie de gérer des enceintes bluetooth avec ALSA… tu vas vite revenir vers PA
                        il est compatible avec l'existant (genre FlashPlayer qui ne connaît que ALSA)
                        il a une architecture légère (CoW), une latence faible (c'est juste hyper-important pour du son), et il est modulaire
                        etc …
                        les cartes sons sont de plus en plus bêtes. En 1998 sur ma AWE64 j'avais du hardware mixing, du MPU-401, de la synthé FM OPL3… y'a rien de tout ça sur un AC'97 ou un bidule HDA aujourd'hui. Tout se fait en espace utilisateur, via PA/ALSA (et Timdity pour le MIDI)
                        

                        pareil….

                        • [^] # Re: Mwai

                          Posté par (page perso) . Évalué à -1. Dernière modification le 28/11/14 à 11:40.

                          des trucs qui me servent a rien encore

                          tu viens de découvrir que sur ta machine 99% des fonctionnalités (regarde juste le noyau Linux) ne te sont pas utiles mais c'est quand même la? Bravo!

                          Linux à la poubelle, il y a plein de fonctionnalités dont tu ne te sers pas (quelle idée de risquer une MAJ, autant rester en 2.6 par exemple, pour la maintenance c'est toi qui paye comme pour la distro sysV, ça n'a pas l'air de te déranger de payer si plus personne n'est interessé à le faire gratos dans une mutualisation, la mutualisation ne t'es pas utile)

                          qu'est-ce qu'il ne faut pas lire dans le genre égoiste mais qui veut quand même que les autres bossent gratos (pour la maintenance, par exemple)…

                        • [^] # Re: Mwai

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

                          Ça ne te sert à rien, donc tu ne l’utilises pas, donc… tu te sens en position de le critiquer ?

                • [^] # Re: Mwai

                  Posté par (page perso) . Évalué à -2. Dernière modification le 27/11/14 à 20:06.

                  Houlà attention, je suis anti-Lennart - mais je n'ai absolument rien contre systemd.

                  Faut vraiment que tu explique aux idiots comme moi pourquoi tu es anti-Lennart.
                  - Lennart n'a pas décidé d'inclure systemd dans les distros (pourquoi les gnes sont contre Lennart alors qu'il n'a aucun droit de décision sur l'inclusion ou non de ses projets dans les distros? Pourquoi ne pas en vouloir aux mainteneurs qui ont fait le choix?)
                  - Tu en as pas besoin, donc tu n'as pas à utiliser (libre à toi d'utiliser une autre distro faite par des mainteneurs qui te plaise).
                  - En fait, Lennart n'a aucun impact sur toi, il ne décide de rien sur toi, il ne peut même pas imposer quoi que ce soit (grande liberté, c'est même pas un personnage d'Etat avec un choix unique pour tous les citoyens, tout le monde est libre de choisir comme il veut), pourquoi être anti une personne qui ne fait rien contre toi?

                  Plus j'écris, et plus je n'ai qu'une conclusion : tu es anti-toi-même, seul décisionnaire (si à la limite tu en voulais aux mainteneurs qui ont décidé de ne plus bosser gratos pour toi, on pourrait dire que tu as la haine de ne plus avoir des travailleurs gratos… Mais on peut même pas dire ça).

              • [^] # Re: Mwai

                Posté par . Évalué à 3.

                C'est marrant que ce soit toi qui tienne ce genre de discours…

                Il ne faut pas décorner les boeufs avant d'avoir semé le vent

            • [^] # Re: Mwai

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

              La communeauté Open Source est pleine de connards certes, mais c'est clairement pas lui qui va faire baisser les stats.

              Et toi non-plus. Au fait, tu sais qu'il y a pas que le Larzac, tu peux aussi ouvrir une boucherie porcine en Arabie Saoudite, ou un restaurant de fruits de mer au Tibet, ne te gènes pas pour nous.

              • [^] # Re: Mwai

                Posté par . Évalué à 3.

                Pour les plus libristes, on peut aussi aller vendre du sable dans le sahara.

                • [^] # Re: Mwai

                  Posté par . Évalué à 8.

                  ça se vendrait ….
                  le sable du sahara est rond et ne peut servir a faire du ciment par exemple
                  dubai importe beaucoup de sable

            • [^] # Re: Mwai

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

              C'est triste ton avis sur les connards

      • [^] # Re: Mwai

        Posté par . Évalué à 10.

        pour demander à Lennart d'aller élever des chèvres dans le Larzac.

        Tu voulais plutôt dire :

        1. Faire du lait de chèvre.
        2. Le récupérer et faire du fromage.
        3. Monter tout un circuit de distribution qui irait plus vite et de manière plus simple au consommateur.
        4. Forcer tous ses concurrents à faire pareil pour réduire les coûts.
        5. Éradiquer 99% des fromages car il est reconnu que seul celui fait avec des chèvres dans le Larzac est bon pour la santé.
        6. Dominer le monde.
        • [^] # Re: Mwai

          Posté par . Évalué à 9.

          Ouai tout compte fait vaut qu'il continue à faire des logiciels informatiques, parce que vivre dans un monde sans roblochon, saint nectaire, étorki, tomme, camemdert, raclette, coulommiers, mimolette, compté, brie, bleu, roquefort, munster, livarot, morbier, et j'en passe moi je ne considère pas ça possible :-D

          kentoc'h mervel eget bezan saotred

          • [^] # Re: Mwai

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

            En tant qu'amoureux du fromage, tu pourrais donc faire un petit don XD

          • [^] # Re: Mwai

            Posté par . Évalué à 4.

          • [^] # Re: Mwai

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

            Je sais, il y a un "et j'en passe" dans ta phrase mais je tiens à évoquer également le Banon, un petit fromage de chèvre qui, quand il est bien affiné, me donnerait envie de faire des centaines de kilomètres jusque dans le Vaucluse pour aller en manger.

            • [^] # Re: Mwai

              Posté par . Évalué à 2. Dernière modification le 27/11/14 à 22:20.

              Ba non j'ai volontairement évité tout fromage de chèvre.

              Faire du lait de chèvre.
              Le récupérer et faire du fromage.
              Monter tout un circuit de distribution qui irait plus vite et de manière plus simple au consommateur.
              Forcer tous ses concurrents à faire pareil pour réduire les coûts.
              Éradiquer 99% des fromages car il est reconnu que seul celui fait avec des chèvres dans le Larzac est bon pour la santé.

              car le formage de Lennart est un chèvre :-D

              Au passage je ne connais pas le Banon tu viens d'éveiller ma curiosité.

              kentoc'h mervel eget bezan saotred

      • [^] # Re: Mwai

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

        Ajoute ta suggestion!

        Écrit en Bépo selon l’orthographe de 1990

  • # rédac'

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

    rho, bah, tu peux faire un tour sur https://linuxfr.org/redaction/news/systemd-a-t-il-des-problemes-d-init pour y ajouter ta prose, sans partir du postulat "je ne veux pas de systemd" mais en indiquant ce que cela t'enlève de l'avoir

  • # Ca ne règle pas la source du problème

    Posté par (page perso) . Évalué à -1. Dernière modification le 27/11/14 à 08:09.

    je n'ai plus la hantise de voir systemd se faufiler dans la prochaine upgrade

    Ca ressemble surtout à soigner les symptomes mais pas la source du problème.
    Il faudrait en parallèle aller voir un psy pour soigner cette hantise dont tu es incapable de décrire objectivement les raisons (non, la résistance au changement n'est pas une raison objective, on ne ferait plus de changements sinon).

    • [^] # Re: Ca ne règle pas la source du problème

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

      Systemd évoluant, mes griefs à son égard disparaissent petit à petit (quoi qu’ils n’ont jamais vraiment porté sur la partie technique du projet), mais parler de problème psy à propos de contrôle de mise à jour, c’est vraiment n’importe quoi !

      Ici benoar ne parle pas d’un système fraîchement installé mais de son système du quotidien, sur lequel l’init utilisé lui importe, ce qui laisse présager qu’il a déjà touché à la gestion de son init (j’utilise Debian et j’ai des scripts init custom auxquels je devrai faire attention lors de la mise à jour). Éviter une mise à jour silencieuse de l’init me paraît la moindre des choses, et sa solution est élégante puisqu’elle laisse le gestionnaire de dépendances travailler en lui donnant l’information « pas de systemd ». Le jour où il n’y aura plus de solution, il lui faudra alors relâcher cette règle et porter ses scripts de démarrage persos (ajouter les unités correspondantes etc.). Ce n’est pas de la résistance au changement que de s’assurer qu’en attendant ça marche sans surprise !

      Visiblement tu n’as jamais touché à ton système d’init et tu t’en fous, très bien, mais certains ont déjà mis les mains dans le cambouis sur leur système et un changement d’init peut être une migration majeure, d’où la « hantise » d’une mise à jour non-souhaitée.

      Tu peux aussi aller voir un psy pour comprendre d’où te vient ce besoin de critiquer les choix des autres dès qu’ils diffèrent des tiens, en leur prêtant des intentions qu’ils n’ont pas exprimées. Une fois ce problème compris, je te promets que les commentateurs de LinuxFr se feront un plaisir de t’aider à écrire des commentaires pertinents et cordiaux, deux qualificatifs que tu cumules rarement (bien que séparément, je ne remets pas en question ta contribution souvent positive au contenu du site).

      • [^] # Re: Ca ne règle pas la source du problème

        Posté par . Évalué à 4.

        Ici benoar ne parle pas d’un système fraîchement installé mais de son système du quotidien, sur lequel l’init utilisé lui importe, ce qui laisse présager qu’il a déjà touché à la gestion de son init (j’utilise Debian et j’ai des scripts init custom auxquels je devrai faire attention lors de la mise à jour)

        A-t-il essayé au moins ? Chez moi j'ai touché à mon init quand c'était SysV, et je suis passé à systemd sans m'en rendre compte (grâce à sa rétrocompatibilité).

        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

        • [^] # Re: Ca ne règle pas la source du problème

          Posté par . Évalué à 6. Dernière modification le 27/11/14 à 09:59.

          Si son système marche bien actuellement, pourquoi prendre le moindre risque ? L'init SysV est encore maintenu par Debian, après tout.

          • [^] # Re: Ca ne règle pas la source du problème

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

            Oué enfin avec cette logique il n'aurait jamais du essayer de mettre à jour sa distrib si elle marchait bien.

            • [^] # Re: Ca ne règle pas la source du problème

              Posté par . Évalué à 10.

              Entre installer un système d'init et mettre à jour des logiciels et bibliothèques, le risque n'est pas le même… Je pensais que c'était évident.

              • [^] # Re: Ca ne règle pas la source du problème

                Posté par . Évalué à 7.

                Concrêtement, ça change quoi ?

                des paquets indispensables, il y en a plein : linux-image, libc, apt, etc. Qu'est ce qui fait que systemd est différent du reste ?

                • [^] # Re: Ca ne règle pas la source du problème

                  Posté par . Évalué à 9.

                  C'est différent car il a déjà un système d'init. On parle ici de remplacer une brique de base par une autre très différente. Il n'a peut-être pas envie / pas le temps de modifier son GRUB fait maison. Il n'a peut-être pas envie, ou pas le temps, d'apprendre à utiliser un nouveau système d'init alors que celui qu'il a en ce moment fonctionne.

                  Le vieil init est encore officiellement supporté par la distro, pour rappel.

                  Je te retourne la question: concrètement, pourquoi passer à systemd là-tout-de-suite-maintenant, pour lui ? Je ne vois aucune urgence, et s'il n'a pas le temps de regarder ce que ça change pour lui, il va juste se retrouver avec un init qu'il ne maîtrise pas.

                  Tout ça me fait penser à quelqu'un qui va installer Linux sur la machine d'un pote "parce que c'est mieux que Windows", sans se demander si ça lui est d'une quelconque utilité.

                  • [^] # Re: Ca ne règle pas la source du problème

                    Posté par . Évalué à 2.

                    Y'a pas à toucher GRUB, pourquoi toucher à GRUB ??

                    "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                    • [^] # Re: Ca ne règle pas la source du problème

                      Posté par . Évalué à -1.

                      Je savais que je n'aurais pas dû parler de ce détail: tu n'as retenu que ça de mon commentaire. C'est le reste qui est important.

                    • [^] # Re: Ca ne règle pas la source du problème

                      Posté par . Évalué à 2.

                      car lorsque tu foire l'INIT systemV->systemD , comme son nom ne l'indique pas tu ne démarre pas, et dans ce cas tu te retrouve couillon avec ton grub et sa console pour tenter d'avoir un accès root.

                      ouais ouais je sais il n'y a aucun problème à le faire

                      • [^] # Re: Ca ne règle pas la source du problème

                        Posté par . Évalué à 2.

                        lorsque tu foire l'INIT systemV->systemD , comme son nom ne l'indique pas tu ne démarre pas, et dans ce cas tu te retrouve couillon avec ton grub et sa console pour tenter d'avoir un accès root.

                        Ça dépend aussi de comment tu t'y prends.

                        Dans la procédure Debian de mise à jour vers systemd ( https://wiki.debian.org/systemd#Configuring_for_testing ) tu ne changes pas directement l'init par défaut, tu changes d'abord le paramètre de boot à la main la première fois pour vérifier que le système démarre et si tout s'est bien passé, tu peux alors le définir en tant qu'init par défaut.

                        Lors de ce genre de manipulations, avoir une clé USB sous la main pour pouvoir démarrer en mode rescue, ça permet d'avoir l'esprit tranquille si quelque chose doit absolument mal se passer.

                  • [^] # Re: Ca ne règle pas la source du problème

                    Posté par . Évalué à 5.

                    On parle ici de remplacer une brique de base

                    C'est quoi une brique de base ? Non parce que des briques qui changent il y en a:
                    – linux-image : change de version tout les 6 mois… et pourtant ça peut casser pas mal de chose !!
                    – libc/eglibc: changement de projet pour la libc…
                    – dernier exemple : gnome. Ils sont passé de gnome2 à 3, qui change complètement.

                    Pour l'utilisateur final, il me semble que le changement de gnome2/3 est nettement plus perturbant que systemd, qui est totalement transparent pour une grande partie des gens !

                    Je te retourne la question: concrètement, pourquoi passer à systemd là-tout-de-suite-maintenant, pour lui ?

                    Remarque que je n'ai rien contre le fait de rester sur sysvinit, c'est la liberté de chacun. L'auteur a sûrement ses raisons, je ne critique pas.

                    Mais quand tu parle de « risque », je ne suis pas convaincu : à mon avis il y a bien plus de risque à rester sur un truc obsolète plutôt que de suivre le choix par défaut de la distribution, qui s'inscrit dans une tendance générale.

                    C'est d'ailleurs un des rôles des distributions : diminuer le risque de panne pour les utilisateurs, mais c'est une autre histoire.

                    • [^] # Re: Ca ne règle pas la source du problème

                      Posté par . Évalué à 6.

                      Mais quand tu parle de « risque », je ne suis pas convaincu : à mon avis il y a bien plus de risque à rester sur un truc obsolète plutôt que de suivre le choix par défaut de la distribution, qui s'inscrit dans une tendance générale.

                      Merci, enfin un argument qui cherche élever le débat. Oui, ok, il y a un risque à rester sur un vieil init qui va disparaître. Mais pour l'instant, c'est là, c'est supporté par Debian et ça marche pour lui.
                      Lorsqu'il voudra un jour installer un .deb extérieur qui ne sera prévu que pour systemd, il aura alors un problème. Donc un besoin. Donc une raison d'installer et apprendre systemd. Mais pour l'instant, le besoin, il n'existe pas.

                      L'auteur a sûrement ses raisons, je ne critique pas.

                      Et dans ce fil de commentaires, tu es bien le seul… Les autres lui reprochent de ne pas installer systemd !

                  • [^] # Re: Ca ne règle pas la source du problème

                    Posté par . Évalué à 10.

                    Je te retourne la question: concrètement, pourquoi passer à systemd là-tout-de-suite-maintenant, pour lui ?

                    Parce que sinon il est résistant au changement.

            • [^] # Re: Ca ne règle pas la source du problème

              Posté par . Évalué à 7.

              C'est vrai il aurait meme du garder son bash tout troue de la version original de 2013…
              Les mises a jour cela ne concerne pas que "je met la derniere version du logiciel".

              • [^] # Re: Ca ne règle pas la source du problème

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

                Il faut qu'on m'explique comment systemd peut être installé comme ça par une update de sécurité de Debian Wheezy (la dernière stable en date, donc si tu veux pas autre chose que des mises à jour de sécurité on a celle-la, on est bien d'accord) qui a systemd en "technology preview" seulement.

                Je suis étonné d'ailleurs par "dist-upgrade" dans le journal, et pas "update". Ou alors on ne parle pas de la même chose…

                • [^] # Re: Ca ne règle pas la source du problème

                  Posté par . Évalué à 0. Dernière modification le 27/11/14 à 12:13.

                  Il faut qu'on m'explique comment systemd peut être installé comme ça par une update de sécurité de Debian Wheezy

                  Je n'ai pas de debian sous la main mais sous ubuntu (qui n'a pas encore systemd comme init) tu as tout de meme systemd qui est installe car demande par certains applications (je sais ce n'est pas un systemd complet mais le paquet il est la).

                  Je suis étonné d'ailleurs par "dist-upgrade" dans le journal, et pas "update". Ou alors on ne parle pas de la même chose…

                  Et pourquoi voudrais tu faire un "update" tout court plutot que un "dist-upgrade"?

                  Je rappelle:

                  man apt-get

                  update : La commande update permet de resynchroniser un fichier d'index répertoriant les paquets disponibles et sa source.

                  dist-upgrade : La commande dist-upgrade effectue la fonction upgrade en y ajoutant une gestion intelligente des changements de dépendances dans les nouvelles versions des paquets

                  • [^] # Re: Ca ne règle pas la source du problème

                    Posté par (page perso) . Évalué à -10. Dernière modification le 27/11/14 à 12:18.

                    Je n'ai pas de debian sous la main mais sous ubuntu (qui n'a pas encore systemd comme init)

                    Comme Debian. Donc peur irrationnelle de l'auteur du journal et des auteurs de commentaires qui ont peur que les scripts d'init cassent, CQFD.

                    Et pourquoi voudrais tu faire un "update" tout court plutot que un "dist-upgrade"?

                    "upgrade", typo.

                    qui donne "de même, des paquets qui ne sont pas déjà installés ne sont ni récupérés ni installés"

                    • [^] # Re: Ca ne règle pas la source du problème

                      Posté par . Évalué à 7.

                      Tu as vraiment tendance à prêter aux autres des propos qu'ils n'ont pas dits. Il a "peur que les scripts d'init cassent" ? Où as-tu lu ça ?
                      Le risque existe, même infime. Par ailleurs, il y a deux possibilités:
                      * la mise à jour installe un sous-morceau de systemd, sans le reste --> ça n'apporte rien fonctionnellement et ton système est moins simple. Autant l'éviter, donc
                      * la mise à jour installe systemd en complet, à la place de l'init SysV --> même si tout se passe bien, il faudra passer du temps à apprendre systemd. Son système d'init SysV le satisfait aujourd'hui, il n'y a donc aucun besoin en face. Ce n'est donc pas une priorité.

                      Je vais finir par une conclusion à la Zenitram:
                      C'est marrant les gens qui pensent que ce qui est mieux pour eux est forcément mieux pour la Terre entière. TOI tu as envie que LUI mette à jour son init vers systemd. Sauf que lui, il n'a pas envie, peut-être pas le temps, et apparemment pas besoin. Il a le droit de respirer ?

                      • [^] # Re: Ca ne règle pas la source du problème

                        Posté par . Évalué à -4.

                        Le risque existe, même infime.

                        Quel risque EXACTEMENT ?

                        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                        • [^] # Re: Ca ne règle pas la source du problème

                          Posté par . Évalué à 2.

                          Oh allons, pitié, disons, un bug ? Un script particulièrement pourri qu'il aurait conçu ? Le risque zéro n'existe pas en informatique.

                          Mais sinon, j'en déduis que tu es d'accord avec le reste ?

                          • [^] # Re: Ca ne règle pas la source du problème

                            Posté par . Évalué à -2.

                            Alors pourquoi il accepte les mises à jours de toute le reste (y compris du kernel, qui peut tout autant avoir des bugs et qui est bien plus critique que l'init) et pas de SysV vers systemd, d'autant plus que ce dernier est compatible avec les scripts ?

                            C'est pas cohérent !

                            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                            • [^] # Re: Ca ne règle pas la source du problème

                              Posté par . Évalué à 6.

                              Parce que pour systemd ce n'est pas une mise à jour, c'est un changement de logiciel. Il va, magiquement, savoir utiliser systemd juste après la mise à jour ?

                              C'est très cohérent: vu qu'il a le choix (enfin en vous lisant, j'ai des doutes…), il choisit la mise à jour la moins impactante, et donc de rester sur SysV.

                              Bizarrement, personne ne conteste l'élément essentiel de mes commentaires: il n'a pas besoin de passer à systemd.

                              • [^] # Re: Ca ne règle pas la source du problème

                                Posté par . Évalué à -10. Dernière modification le 27/11/14 à 15:31.

                                Parce que pour systemd ce n'est pas une mise à jour, c'est un changement de logiciel. Il va, magiquement, savoir utiliser systemd juste après la mise à jour ?

                                Passer de linux 3.14 à linux 3.15, c'est pas un changement de logiciel peut-être ?

                                Une mise à jour, ça ne change pas le logiciel… Ben ça met à jour quoi alors ?

                                Quant à savoir utiliser systemd :
                                - y'en a pas besoin pour booter avec systemd, ça va fonctionner avec les scripts existants
                                - les commandes se ressemblent fortement (et c'est voulu)
                                - une mise à jour de sysV ver systemd, l'utilisateur lambda ne voit aucune différence… (il touche pas à l'init)

                                "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                                • [^] # Re: Ca ne règle pas la source du problème

                                  Posté par . Évalué à 10. Dernière modification le 27/11/14 à 15:53.

                                  Ça vire à la mauvaise foi, là. J'ai dit: un changement de logiciel. Tu es la première personne que je rencontre à comprendre ça comme un changement de version d'un même logiciel.

                                  Passer de linux 3.14 à linux 3.15, c'est une mise à jour.
                                  Passer de linux 3.14 à hurd 0.008, c'est un changement de logiciel.

                                  Si tu ne vois pas la différence, on peut arrêter là la discussion.

                                  Sinon, continuons. Systemd c'est mieux, la mise à jour c'est automagique, génial. Je suis d'ailleurs assez d'accord sur ces points, de toute façon.
                                  Par contre:
                                  - les commandes se ressemblent, certes… se ressemblent. Donc lorsqu'il fera /etc/init.d/network restart, ça va marcher ? non. Ou à moitié. En tout cas, ce n'est pas la bonne méthode.
                                  - l'utilisateur lambda ne saurait même pas que le système d'init a changé lors de l'upgrade. Hors-sujet: on n'est pas face à l'utilisateur lambda, on est face à quelqu'un qui a bidouillé son init et souhaite en garder la maîtrise.

                                  Bref, on en revient toujours au même point, inlassablement: systemd c'est super, mais ce n'est pas une raison suffisante pour le forcer à changer son init.

                                  Je vais arrêter là, parce que ça fait déjà 4 quatre fois que je me répète, et j'ai l'impression de parler à un mur.

                                  • [^] # Re: Ca ne règle pas la source du problème

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

                                    lorsqu'il fera /etc/init.d/network restart, ça va marcher ? non. Ou à moitié. En tout cas, ce n'est pas la bonne méthode.

                                    service network restart fonctionne tout aussi bien avec systemd qu’avec SysV.
                                    Je ne serais d’ailleurs pas étonné que ça fonctionne aussi avec OpenRC et autres upstart…

                                  • [^] # Re: Ca ne règle pas la source du problème

                                    Posté par . Évalué à -1.

                                    Toujours pas convaincu, et ce commentaire exprime ma pensée.

                                    "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                              • [^] # Re: Ca ne règle pas la source du problème

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

                                Ceci dit, wheezy a forcé un support obligatoire des tags LSB dans les scripts d'init. C'est aussi une source d'erreur potentiel, et j'ai vu 0 personnes en parler et/ou raler et/ou demander un GR sur le sujet.

                                Bien sur qu'il y a des trucs qui ne vont pas marcher, comme par exemple, un script interactif au boot ( mais qui n'aurait pas marcher sans doute en wheezy non plus ). Maintenant, d'une part, y a encore quelques mois avant la release de jessie, et il y a encore quelques mois après la release. Et si le souci, c'est que Debian release trop vite, on peut difficilement dire que ç'est la fate à systemd.

                                Car des changements, y en a a toujours. L'exemple que je donne sans arrêt, c'est apache 2.4, mais je peux aussi donner les versions majeurs de php au moment de php4 et je peux te dire que du code php, c'est autrement plus long à fixer que 3/4 scripts d'inits.

                                Donc perso, je pige pas le fait de se focaliser sur systemd et d'idéaliser complétement le reste en occultant les pétages réguliers de la compatibilité par divers upstreams.

                                • [^] # Re: Ca ne règle pas la source du problème

                                  Posté par . Évalué à 3.

                                  Donc perso, je pige pas le fait de se focaliser sur systemd et d'idéaliser complétement le reste en occultant les pétages réguliers de la compatibilité par divers upstreams.

                                  Parce qu'au bout de trente répétitions, il y a quelque chose que je n'arrive pas à faire rentrer dans la tête de ceux qui me répondent: jusqu'à preuve du contraire, l'auteur du journal n'a pas besoin de systemd. C'est tout ! point.

                                  C'est bien gentil de défendre systemd bec et ongles, sauf que ce n'est pas systemd que je critique, c'est le fait de vouloir absolument que quelqu'un l'installe alors qu'il n'en a pas le besoin. systemd, c'est un init qu'il ne connaît peut-être pas encore, et manifestement il souhaite maîtriser son init. Il faudrait arrêter de faire semblant de ne pas voir la différence entre le passage d'une version à une autre d'un logiciel qu'on connaît déjà, et le passage d'un logiciel à un autre qui n'a pas du tout la même logique.

                                  • [^] # Re: Ca ne règle pas la source du problème

                                    Posté par . Évalué à 4.

                                    +1

                                    Perso je suis pas super expert sur le sujet, et je saurais pas te dire de deux systèmes d'init lequel poutre le plus du mammouth dégraissifié, mais l'histoire avec les mises à jour chelous ça me fait penser à la situation suivante :

                                    L'autre jour je vais récupérer ma voiture chez le garagiste. C'était un problème tout bête, fallait juste faire la vidange de la courroie d'entraînement de l'autoradio et des essuies-glaces :o En deux jours c'était torché, mais au moment de récupérer ma bagnole le garagiste me dit « Ouais alors on a fait tout ce qu'il fallait, par contre on a aussi changé les pompons sur le rétroviseur et le chien qui remue la tête à l'arrière, ils étaient tout pourris on vous en a mis des mieux. » Alors là jménerve tu vois j'étais sur le point de lui faire manger du poivre au mec ! Pis après il me dit « C'est gratuit. ». Ah bon ok.

                                    C'est vrai que c'est pas super grave tu vois, après tout c'est juste un putain de chien qui remue la tête, c'est pas comme si j'en avais besoin tous les jours, déjà il était tellement moche qu'on pouvait difficilement faire pire, et puis même si c'est pire, au pire, tant pire je le remplace par un autre en deux secondes c'est super simple.

                                    Mais avec systemd c'est plutôt la situation suivante :

                                    L'autre jour je vais rerécupérer ma rebagnole chez ce putain de regaragiste. C'était un problème tout bête, y fallait juste faire le dégivrage du réservoir diesel du starter de la roue de secours :o Un truc tout simple en trois jours c'était torché, mais au moment de récupérer ma bagnole le mec y me dit « Ouais alors on a fait tout ce qu'il fallait, par contre on a aussi changé le moteur celui d'avant était nul on en a mis un mieux. ».
                                    Je suis désolé< mais NON ! Putain de bordel de manche à couilles jvais te faire manger 6 kilos de poivre par l'autre boutte moi tu vas voir ! :o Alors là après il me dit « C'est gratuit. ». Mais t'inquiète mon poulet, le poivre je vais pas te le facturer non plus ! :o « Nan mais vous allez voir il est mieux ce moteur l'autre il était vraiment nul avec celui-là ça ira plus vite et puis tous les problèmes que vous aviez pas avant, ben là vous les aurez pas non plus ! En plus ça vous dérange pas la dernière fois pour le chien qui remue la tête vous avez pas fait autant votre difficile ! ».

                                    Bon alors qu'une chose soit claire. Quand on me change des applications de haut niveau jore le chien qui remue la tête, je m'en fous. Il y a des chances qu'il soit mieux, des chances qu'il soit pareil, des chances que ce soit moins bon, mais l'enjeu est pas énorme et en cas de problème je peux m'en débarrasser facilement, c'est pas comme si tout le fonctionnement de la bagnole reposait dessus.

                                    PAR CONTRE quand on me change un truc comme le moteur EXCUSE-MOI mais ça me fait dinguelinguelingue dans le fond de la tête avant même que j'aie appuyé sur le bouton start :o Certes les chances que ce soit effectivement moins bon que le précédent sont pas plus grandes que pour le chien qui remue la tête, mais là l'enjeu n'est pas le même ! Là j'avais un moteur peut-être pas au top du top fashieunne de la collection printemps-automne, mais que j'utilise depuis 10 ans et que je connais bien, et on veut me le remplacer du jour au lendemain par un truc que je connais pas du tout, en me disant que peu importe si les interfaces sont pas pareil ce qui compte pour toi c'est juste la couleur du tableau de bord, le reste tu n'as pas besoin de le savoir, blablabla. Mais mayrde ! Surtout que ça marchait déjà très bien avant :o

                                    Alors t'es gentil mon poulet, tu retires tout ton merdier et tu me remets le moteur que j'avais avant. Le jour ou j'aurai besoin de ton nouveau moteur à la mode je te ferai signe.

                                    « Euh ben c'est-à-dire que… En fait cette nouvelle génération de moteur elle est très complexe… et le moteur pour qu'il tienne il doit être soudé à tout le reste… alors on va pas pouvoir vous le changer comme ça… D'ailleurs on avait prévu de vous changer toutes les autres pièces au fur et à mesure dans les jours qui suivent pour assurer une compatibilité maximale… »

                                    Putain ! NAN mais je RAAAAAAAAIYVE !! \°□°/
                                    C'est pas juste du poivre que je vais te faire bouffer mon canard ! C'est ton putain de moteur, avec la carrosserie, le châssis, l'autoradio, la roue de secours, le bouton start et le chien qui remue la tête !
                                    DAIGAJE sale tchakapan ! (╯°□°)╯ ︵ ʇɐH pǝᴚ ǝʇsıƃɐɹɐ⅁

                                    La dernière fois qu'un truc pareil m'était arrivé c'était quand j'utilisais Gnome 2 sous debian, et que du jour au lendemain je me suis retrouvé avec un nouvel environnement de bureau - visiblement un truc très expérimental, sûrement une version alpha - auquel je ne m'attendais pas du tout, et où je ne trouvais même pas le bouton "redémarrer" ! Bon apt-get install xfce-desktop, puis le problème était résolu.

                                    Là avec systemd j'ai été plus prudent, je l'ai mis on hold (c'est avec la touche "=" dans aptitude), mais du coup les jours suivant à chaque mise à jour il voulait me supprimer un paquet ! Un coup c'était network-manager, un autre coup c'était le display manager, un autre coup c'était le machin pour monter les disques. À chaque fois j'ai du trouver des alternatives, ça m'a bien fait chier. Bon là y'a une période de calme, ouf. J'avais peur qu'on me demande de virer DéBuCe :o

                                    Ouais alors du coup quand je voyais des gens dire que sysvinit c'était de la merde que que systemd allait résoudre tous mes problèmes, ça me faisait bien marrer. J'intervenais, jore :

                                    • Mais j'ai pas de problèmes avec sysvinit !
                                    • Hein ?! Oo Comment c'est possible tout le monde sait que sysvinit c'est de la merde c'est outdated, t'as forcément des problèmes !
                                    • Ah non avec sysvinit j'ai pas de problèmes, enfin j'avais parce que depuis que systemd est arrivé dans debian y'a plus rien qui marche !
                                    • Hein ?! oO plus rien qui marche avec systemd ?! C'est pas possible systemd c'est parfait ! Oo
                                    • Ah non, avec sysvinit ! J'ai conservé sysvinit et y'a plus rien qui marche !
                                    • Ha ! Alors tu vois bien que sysvinit c'est de la merde !

                                    Qu'est-ce que tu veux répondre à ça :/

                                    Alors ptet que ça sert pas à grand chose de faire des journaux qui critiquent systemd, ok je veux l'admettre, mais en tout cas c'est bien de faire des journaux qui expliquent comment on peut s'en passer. Parce que pour ceux qui veulent pouvoir continuer à utiliser Linux sans systemd, ça fait avancer le schmilblick. Par contre ça ne plaît pas aux systemdiens, allez savoir pourquoi.

                                    Les systemdiens, tu critiques systemd sans proposer de solution, ils râlent. Tu critiques systemd en proposant une solution, ils râlent. En fait ce qui les emmerde c'est que tu critiques systemd. Et après il vont dire que c'est les anti-systemd qui râlent tout le temps. :o

                                    splash!

                                    • [^] # Re: Ca ne règle pas la source du problème

                                      Posté par . Évalué à 0. Dernière modification le 29/11/14 à 19:18.

                                      PAR CONTRE quand on me change un truc comme le moteur

                                      L’analogie avec ta bagnole est super pertinente! Mon dieu, il fallait le dire que Linux t’appartenait! Personne n’était au courant. Faut pas faire des cachotteries comme ça… Les dévs, ils savaient même pas que tu leur avais demandé de réparé ton Linux, ils ne savaient même pas qu’ils n’étaient que des garagistes mal dégrossis qui touchent impunément à ton OS. Ces couillons graisseux, ils croyaient qu’ils pouvaient développer ton Linux comme bon leur semble. C’est quand même couillon, ça!

                                      Merci d’avoir prévenu. Tout va bientôt rentrer dans l’ordre maintenant que tu les as avertis de leur grosse bévue. Ils vont remettre le vieux moteur que tu ne leur as pas demandé de changer.

                                      ;)

                                    • [^] # Re: Ca ne règle pas la source du problème

                                      Posté par . Évalué à 2.

                                      Alors t'es gentil mon poulet, tu retires tout ton merdier et tu me remets le moteur que j'avais avant. Le jour ou j'aurai besoin de ton nouveau moteur à la mode je te ferai signe.

                                      T'as du rater un truc important la, c'est pas trop comme ca que ca fonctionne. Les developeurs Debian mettent à disposition gratuitement un OS. Si la facon dont il évolue ne te convient pas, tu es libre de ne pas l'utiliser, ou d'y contribuer pour essaier de le faire évoluer comme tu le souhaite. Mais pas d'éxiger qu'ils fassent ce que toi tu as décidé.

                                      Il y a une petite difference avec ton garagiste: dans un cas tu es un client, dans l'autre non.

                                      PAR CONTRE quand on me change un truc comme le moteur EXCUSE-MOI mais ça me fait dinguelinguelingue dans le fond de la tête avant même que j'aie appuyé sur le bouton start :o Certes les chances que ce soit effectivement moins bon que le précédent sont pas plus grandes que pour le chien qui remue la tête, mais là l'enjeu n'est pas le même ! Là j'avais un moteur peut-être pas au top du top fashieunne de la collection printemps-automne, mais que j'utilise depuis 10 ans et que je connais bien

                                      Oui et puis le noyau linux d'il y a 10 ans fonctionnait egalement très bien. Et l'enjeu est au moins aussi important que pour le systeme d'init. Pourquoi est ce qu'il a été mis à jour ?

                                  • [^] # Re: Ca ne règle pas la source du problème

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

                                    j'ai pas besoin de certaines fonctions de la glibc, je fait pas un foin car elles sont disponible, car je sais que trop de modularité a un cout. J'ai pas besoin de 90% des paquets dispo dans ma distributions, et ça prends du temps pour calculer les dépendances, et pareil, je demande pas à les virer spécialement pour moi.

                                    C'est pareil ici. C'est bien joli de croire que le libre s'écrit tout seul, mais c'est pas le cas. A un moment, tu te dit que plutot que faire 2 fois le travail, tu va le faire qu'une fois, et tant pis si il y a des choses dont les gens ont "pas besoin", car ce qui est rare, c'est le temps de contribution, pas les besoins utilisateurs. Donc on optimise pour réduire les "couts" en terme de temps sur le contributeur, pas l'utilisateur de la contribution la plupart du temps ( j'écarte le cas plus complexe ou il y a plusieurs contributeurs chainés dans la chaine de de production vers l'utilisateur final ).

                    • [^] # Re: Ca ne règle pas la source du problème

                      Posté par . Évalué à 2.

                      Comme Debian. Donc peur irrationnelle de l'auteur du journal et des auteurs de commentaires qui ont peur que les scripts d'init cassent, CQFD.

                      Tu es con ou quoi? Ubuntu n'utilisera systemd pas avant la version 15.04 c'est a dire l'annee prochaine. Donc oui je suis desole mais je n'utilise pas systemd car ma distrib ne l'a pas encore.

                      ton deuxieme point rien compris mais j'ai comme l'impression que tu trolls sur des trucs que tu ne connais pas/plus…

          • [^] # Re: Ca ne règle pas la source du problème

            Posté par . Évalué à 10.

            systemd devient super courtant, donc il y a fort à parier qu'il sera mieux testé, mieux gérés par les logiciels, il y aura plus d'aide dessus, etc.

            Donc rester sur un système obsolète n'est pas forcément un bon choix non plus.

      • [^] # Re: Ca ne règle pas la source du problème

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

        Ici benoar ne parle pas d’un système fraîchement installé mais de son système du quotidien

        Si il veut un système quotidien n'évolue pas, il utilise Debian stable!

      • [^] # Re: Ca ne règle pas la source du problème

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

        certains ont déjà mis les mains dans le cambouis sur leur système et un changement d’init peut être une migration majeure, d’où la « hantise » d’une mise à jour non-souhaitée.

        Le paquet systemd pour Debian ne fournit pas les liens lui permettant d’être utilisé comme système d’init. L’installation de ce paquet ne change pas le système en place.
        benoar ne fait donc pas ça pour éviter/retarder un changement d’init mais pour éviter toute trace de systemd sur sa machine.

        • [^] # Re: Ca ne règle pas la source du problème

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

          Cela doit être rigolo, une vie sans /lib/systemd/systemd-udevd.

          Debian Consultant @ DEBAMAX

          • [^] # Re: Ca ne règle pas la source du problème

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

            Les vrais barbus utilisent MAKEDEV enrobé de scripts shell (POSIX le shell bien sûr).
            C’est tellement KISS tu vois…

            • [^] # Re: Ca ne règle pas la source du problème

              Posté par . Évalué à 2.

              Sinon, il y a eudev comme solution intermédiaire…

              • [^] # Re: Ca ne règle pas la source du problème

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

                Vu qu’il s’agit d’un fork d’udev, ça ne suffira pas à satisfaire les allergiques au "code de Lennart".

                • [^] # Re: Ca ne règle pas la source du problème

                  Posté par . Évalué à 2.

                  D’un autre coté, il ne me semble pas que μdev contiennent beaucoup de code de Lennart…
                  De plus, il faut arrêter de penser que les gens critiques juste parce qu’ils allergiques.

                  • [^] # Re: Ca ne règle pas la source du problème

                    Posté par . Évalué à 9.

                    Quand on est pas convaincus par les arguments techniques et qu'on a migré en 2 secondes à systemd sans le moindre problème, on a des doutes sur la rationnalité des critiques.

                    • [^] # Re: Ca ne règle pas la source du problème

                      Posté par . Évalué à 1.

                      Je ne suis pas convaincu pour plein de raison technique que je ne réexposerai pas pour me mettre au même niveau que :

                      et qu'on a migré en 2 secondes à systemd sans le moindre problème, on a des doutes sur la rationnalité des critiques.

                      Néanmoins, pour l’avoir actif sur une debian Jessie, je n’aime pas le fait de n’avoir que deux lignes pendant la phase de démarrage… mes partitions sont clean, et la LED du disque tourne… je préférais l’ancien système parce qu’au moins je savais où il en était. L’autre raison, c’est que je m’attendais bêtement à un démarrage rapide, ce n’est pas le cas. Donc voilà, oui, il fait le job, mais si tu vas par là, pourquoi utiliser GNU/Linux puisque Windows et MACOS font le job.
                      Moi, j’ai choisi GNU/Linux pour la liberté de pouvoir choisir et configurer son OS.

                      • [^] # Re: Ca ne règle pas la source du problème

                        Posté par . Évalué à 3.

                        Aaah, les trolls sur le boot graphique et l'affichage de l'état du boot et la référence à "autant utiliser windows", merci, je viens de rajeunir de 10 ans.

                        • [^] # Re: Ca ne règle pas la source du problème

                          Posté par . Évalué à 1.

                          Détrompe toi, le boot n’ai pas graphique, c’est du texte avec un jolie curseur. Enfin, un écran vide avec de ligne et un curseur.

                          Quand à la « référence » je me mets au niveau.

                          • [^] # Re: Ca ne règle pas la source du problème

                            Posté par . Évalué à 1.

                            Oups, pardon pour l’orthographe, grammaire… je vais aller me coucher !

                          • [^] # Re: Ca ne règle pas la source du problème

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

                            Sous ma Fedora le boot est graphique, mais si j'appuie sur echap j'ai une ligne par démarrage de service avec [OK] quand c'est fini. Certes ça fait moins d'info que sous ma debian de 2006, sauf que sur celle-ci j'avais 1500 lignes qui défilaient en 30s donc je ne voyais au final rien.

                            Bref ce qu'on peut déduire de nos messages : avec systemd + fedora on sait où le boot en est, et avec systemd + debian non. Le problème est donc debian.

                            • [^] # Re: Ca ne règle pas la source du problème

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

                              Sans compter que les logs restent quoiqu'il arrive disponibles après le boot effectué, tu peux même coder un programme qui t'envoie une notification s'il y a eu une erreur au démarrage (Fedora en avait un avant). Je trouve plus intelligent d'être prévenu en cas d'erreur que de vérifier systématiquement au démarrage si tout s'est bien passé (ce qui est difficile car le démarrage est rapide).

                          • [^] # Re: Ca ne règle pas la source du problème

                            Posté par . Évalué à 0.

                            Quand à la « référence » je me mets au niveau.

                            Quel niveau exactement ? Tu peines à trouver des problèmes qui sont des problèmes.

                            • [^] # Re: Ca ne règle pas la source du problème

                              Posté par . Évalué à 5.

                              Je réponds à ça :

                              Quand on est pas convaincus par les arguments techniques et qu'on a migré en 2 secondes à systemd sans le moindre problème, on a des doutes sur la rationnalité des critiques.

                              Que j’interprète, sûrement à tort comme :

                              Dans ce que j’ai lu rien de technique ne me correspond, j’ai essayé 2 secondes et chez moi ça marche sans le moindre problème. Donc ceux qui donnent des explications technique ne sont pas rationnels.

                              Il y a plein de population qui utilise GNU/Linux, mon père, ma mère… eux le système d’init il s’en moque. Le geek un peu intéressé, systemd c’est bien, ça marche chez moi, et je peux facilement faire des petites modifs. L’admin qui administre plein de machines chez différents clients, qui a investi des centaines de jours pour avoir un système qui marche. Et qui derrière cette petite révolution voit les centaines de jours d’adaptation et de validation arriver avant que son client (banque, grand compte…) n’accepte ça.
                              Et une fois déployé, pas de chance une faille de sécurité oblige à prendre une version corrigé, à mince, il faut prendre la dernière version dans la branche master ce qui tire de nouveau, noyau… et là tu repars sur un cycle de vérification pendant que la faille est disponible. Tant qu’il n’y aura pas une version LTS de systemd avec des mise à jour de sécurité, une partie des admin freinera forcément des quatre fers.

                              Mais ce n’est pas parce que tu es dans une des populations que les inquiétudes des autres sont ridicules.

                              Je en sais pas si c’est plus clair.

                              • [^] # Re: Ca ne règle pas la source du problème

                                Posté par . Évalué à 7.

                                Et une fois déployé, pas de chance une faille de sécurité oblige à prendre une version corrigé, à mince, il faut prendre la dernière version dans la branche master ce qui tire de nouveau, noyau… et là tu repars sur un cycle de vérification pendant que la faille est disponible. Tant qu’il n’y aura pas une version LTS de systemd avec des mise à jour de sécurité, une partie des admin freinera forcément des quatre fers.

                                Genre Redhat ou Suse ne vont pas backporter les patchs comme les 2000 autres logiciels qui sont dans leur distrib ?

                              • [^] # Re: Ca ne règle pas la source du problème

                                Posté par . Évalué à 0.

                                Et puis c'est quoi encore cette histoire du master de systemd qui dépend du dernier noyau en date ? systemd 217 dépend de la version 3.7 a minima ( quasiment 2 ans donc ) , pas de de la version 3.17. Je vois que les FUDs que balance kaane< dans la news en cours de rédaction ont bien pris.

                                • [^] # Re: Ca ne règle pas la source du problème

                                  Posté par . Évalué à 7.

                                  Je vois que les FUDs que balance kaane< dans la news en cours de rédaction ont bien pris.

                                  Bonjour,
                                  N'hésite surtout pas à dénoncer mes "FUD" dans la dépêche en cours de rédaction. Pour information le "FUD" doit faire référence à ce texte :

                                  Soyons clair, on s'attend à ce que systemd et le noyau soient mis à jour simultanément. On ne prend pas du tout en charge le mélange d'un noyau vraiment vieux avec un systemd vraiment récent. Jusqu'ici, on s'est concentré sur la prise en charge par systemd du noyau, jusqu'à une version antérieure de 2 ans (ce qui veut dire la 3.4 actuellement), mais même cela devrait être considéré avec précaution.

                                  Qui est un post de Lennart Pottering. cf Post Original

                                  Donc a) merci de ne pas appeler FUD ou déni chacun de mes posts b) si vous avez quelque chose à me dire n'hésitez pas, je n'ai jamais mordu personne et c) n'hésitez pas non plus à me ridiculiser, par exemple en postant des sources crédibles qui me contredisent.

                                  Pour le problème du jour : Lennart a annoncé dans le post déjà cité plu haut :

                                  Also note that at that point we intend to move udev onto kdbus as transport, and get rid of the userspace-to-userspace netlink-based tranport udev used so far.

                                  Ce qui se traduit par, "Veuillez aussi prendre note qu'à partir de maintenant nous avons l'intention d'utiliser kdbus comme protocole de communication pour udev, et de nous débarrasser de la liaison userspace vers userpace basé sur netlink que nous utilisions jusque là".
                                  Dont acte dans le source trunk du dernier udev il n'y a plus de liaison netlink. Donc le prochain systemd/udev (sauf revirement) ne sera compatible qu'avec les kernel ayant kdbus.
                                  C'est quoi le premier kernel avec kdbus déjà ?

                                  • [^] # Re: Ca ne règle pas la source du problème

                                    Posté par . Évalué à 5.

                                    Bon bah testons alors :)

                                    le kernel n'est pas le dernier donc surement pas avec kdbus
                                    uname -a => Linux plop** 3.14.25**-1-lts #1 SMP Fri Nov 21 19:41:09 UTC 2014 x86_64 GNU/Linux

                                    je viens juste de compiler la branche master de systemd
                                    pacman -Qv systemd-git => systemd-git 217.443.g895b3a7-1

                                    et pourtant :
                                    1/ ca boot sans erreur
                                    2/ networkd que j'utilise fonctionne et networkctl ne me retourne aucune erreur.

                                    Bref, quel est le problème ?

                                    • [^] # Re: Ca ne règle pas la source du problème

                                      Posté par . Évalué à -1.

                                      Le problème est que tu es en train d'utiliser une fonctionnalité obsolète de systemd, qui n'est là que pour assurer la transition et qui est vouée à disparaître. Effectivement, ça marche pour la version 217. C'est tout ce qu'on peut en déduire.

                                      L.P. a toujours dit que systemd serait fortement lié au noyau, et utiliserait le plus possible ses fonctionnalités. Donc, comme il le dit lui-même, ça marchera avec des noyaux un peu plus vieux, mais faudra pas pousser trop loin.

                                      C'est un choix qui apporte des avantages au niveau technique, mais qui peut apporter aussi des pièges niveau maintenance.

                                      • [^] # Re: Ca ne règle pas la source du problème

                                        Posté par . Évalué à 4.

                                        Le problème est que tu es en train d'utiliser une fonctionnalité obsolète de systemd, qui n'est là que pour assurer la transition et qui est vouée à disparaître. Effectivement, ça marche pour la version 217. C'est tout ce qu'on peut en déduire.

                                        Heureusement que j ai precisé avoir compilé depuis le trunk master…. c'est un peu le sujet .

                                        • [^] # Re: Ca ne règle pas la source du problème

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

                                          Nan mais c'est Kaane aussi. Il va te dire "tel truc trunk marche pas sans ça", et rien que le fait qu'il soit pas foutu d'utiliser le bon terme ( trunk, c'est pour svn, pas git ) montre qu'il maitrise pas vraiment le sujet.

                                          Ensuite, tu va lire le code source, tu va voir que udevd utilise encore un socket netlink ( genre dans worker_new, http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udevd.c#n174 ), et la, tu as compris qu'il a du prendre sans doute du faire une faute dans un grep et qu'il conclue à la vavite.

                                          Jamais il va pointer vers du code, ou ce genre de choses, faut toujours passé du temps à double vérifier ses affirmations, car ça a l'air sérieux, mais en pratique, non. Suffit de voir les dépêches sur systemd d'il y a 1 ou 2 ans, ou j'ai quand même passé un bon paquet de temps à expliquer les choses, car ce genre de comportement est à mon sens toxique pour la communauté, car ça masque les critiques légitimes en les recouvrant de bullshit.

                                          • [^] # Re: Ca ne règle pas la source du problème

                                            Posté par . Évalué à 10.

                                            Nan mais c'est Kaane aussi.

                                            Perdu, là en l'occurence c'était Christophe Chapuis.

                                            _ Il va te dire "tel truc trunk marche pas sans ça", et rien que le fait qu'il soit pas foutu d'utiliser le bon terme ( trunk, c'est pour svn, pas git ) montre qu'il maitrise pas vraiment le sujet._

                                            Si il y avait dans le GIT systemd une seule autre branche que master, je serais presque tenté d'être d'accord avec toi. Mais trunk ca veut dire tronc, et quand il n'y a pas de branches à l'arbre ça décrit parfaitement l'endroit ou se trouve le code source.

                                            et la, tu as compris qu'il a du prendre sans doute du faire une faute dans un grep et qu'il conclue à la vavite.

                                            J'ai peut être fait une faute dans un grep, ou été perdu par le va et vient des connections udev et de sd-bus, mais j'aimerai également te rappeler que c'est la position officielle de Lennart :

                                            To make this clear, we expect that systemd and kernels are updated in
                                            lockstep. We explicitly do not support really old kernels with really
                                            new systemd. So far we had the focus to support up to 2y old kernels
                                            (which means 3.4 right now), but even that should be taken with a grain
                                            of salt, as we already made clear that soon after kdbus is merged into
                                            the kernel we'll probably make a hard requirement on it from the systemd
                                            side.

                                            I am tempted to say that we should merge the firmware loader removal
                                            patch at the same time as the kdbus requirement is made. As that would
                                            be a clean cut anyway…

                                            Also note that at that point we intend to move udev onto kdbus as
                                            transport, and get rid of the userspace-to-userspace netlink-based
                                            tranport udev used so far. Unless the systemd-haters prepare another
                                            kdbus userspace until then this will effectively also mean that we will
                                            not support non-systemd systems with udev anymore starting at that
                                            point. Gentoo folks, this is your wakeup call.

                                            Lennart

                                            Donc niveau conclusion à la va-vite, c'est pas franchement ça. Il s'agit du point de vue officiel de la personne en charge du projet systemd.

                                            Jamais il va pointer vers du code, ou ce genre de choses

                                            Non mais je pointe vers des project leader qui suivent le code de très près, ce qui permet a) d'éviter de mauvaises interpretations du code, b) de ne pas mélanger mon opinion personnelle avec cette interprétation et c) de rendre le truc compréhensible par des gens qui ne lisent pas le C système (dont j'avoue volontiers faire partie).

                                            car ce genre de comportement est à mon sens toxique pour la communauté, car ça masque les critiques légitimes en les recouvrant de bullshit.

                                            Le comportement qui consiste à traiter sans distinction toutes les personnes qui ne sont pas intéressées par systemd d'ignorants nocifs est elle beaucoup plus constructive. Il y a des histoires de pailles et de poutres sur le sujet je crois.

                                    • [^] # Re: Ca ne règle pas la source du problème

                                      Posté par . Évalué à 3.

                                      Bref, quel est le problème ?

                                      Plusieurs, à commencer par le fait que je ne sais pas à quelle version de commit correspond systemd-git 217.443.g895b3a7-1 (mais bon c'est accessoire). Ensuite le problème de liaison netlink ne se pose que sur les machines ne disposant pas de libsystemd. C'est systemd/udev qui est cassé niveau expérience utilisateur, pas systemd intégralement.

                                      Donc avant soit on utilisait libsystemd avec tout le reste de l'environnement systemd derrière, soit on utilisait netlink.
                                      Dans l'état actuel du trunk (et je suis prêt à parier que ca va rester en place) soit on utilise libsystemd, soit il faut se rabattre sur kdbus (et donc coder toute une API userspace pour interfacer kdbus). L'option netlink n'existe plus.

                                      Si tu préfères il n'est absolument plus possible d'utiliser la nouvelle version de udev en l'état sans systemd complet sur un kernel sans kdbus.

                                      Pour finir il ne s'agit pas d'un délire personnel, mais bien d'une position 100% assumée par Lennart, pour laquelle j'ai donné et le lien et la traduction.

                                      • [^] # Re: Ca ne règle pas la source du problème

                                        Posté par . Évalué à 2.

                                        Plusieurs, à commencer par le fait que je ne sais pas à quelle version de commit correspond systemd-git 217.443.g895b3a7-1

                                        C est le naming d'arch qui est un peu étrange cf https://wiki.archlinux.org/index.php/VCS_PKGBUILD_Guidelines#Git , mais en gros c est compilé depuis le trunk d'il y a quelques heures ( j'ai vu qu il y avait eu quelques commit après )

                                        Donc avant soit on utilisait libsystemd avec tout le reste de l'environnement systemd derrière, soit on utilisait netlink.
                                        Dans l'état actuel du trunk (et je suis prêt à parier que ca va rester en place) soit on utilise libsystemd, soit il faut se rabattre sur kdbus (et donc coder toute une API userspace pour interfacer kdbus). L'option netlink n'existe plus.

                                        Donc en gros t'es un peu hors sujet , on parlait évidement de l'utilisation classque de systemd en entier pas d'un cas particulier ou on utilise juste la version udev de systemd avec un autre init.

                                        • [^] # Re: Ca ne règle pas la source du problème

                                          Posté par . Évalué à 0.

                                          Donc en gros t'es un peu hors sujet

                                          Euh.. Tu m'accuses de FUDer, je prend le seul truc qui pourrait éventuellement correspondre à tes accusations et j'étaye. J'y peux rien si le seul truc qui ressemble vaguement de loin, de nuit et dans le brouillard au FUD dont tu m'accuses porte sur systemd/udev.

                                          Je me défend contre ce sur quoi tu m'attaques, donc je ne vois absolument pas en quoi je pourrais être hors sujet.

                                          • [^] # Re: Ca ne règle pas la source du problème

                                            Posté par . Évalué à 0.

                                            Ce que je te reproche c'est que tu parles d'une utilisation de udev bien particulière et trop vague ( volontairement ? ) dans la dépêche en cours de redaction ( apparement il y a eu des modifs récentes qui sont bien plus claires et je t'en remercie ) et que certains personnes comme la personne a laquelle j'ai répondu ont compris "si on utilise l'init systemd et qu'on upgrade faut aussi upgrader le noyau !!!" ce qui est factuellement faux. Pour moi fin du débat.

                                  • [^] # Re: Ca ne règle pas la source du problème

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

                                    Je ne sais pas si tu fudes, mais il est clair que soit tu selectionnes tes points, soit tu fait preuve d'ignorance.

                                    Parce que avoir un kernel à jour en même temps que l'userspace, ça arrive relativement plus souvnet que tu veux faire croire.

                                    Exemple, udev avant que ça devienne part au projet systemd :
                                    http://lwn.net/Articles/193603/

                                    ( 2006, pour les gens qui veulent pas cliquer ). Et pour les gens qui veulent pas cliquer aussi, on voit GKH poser la question de "pourquoi on va supporter les trucs que les créateurs refusent de supporter plus longtemps".

                                    Autre exemple ? Iptables, et notamment des projets approchants comme ipset, etc. Tu mets à jour ta distro, et il te faut une version plus à jour de tel ou tel truc interne.

                                    Des APIs exposés sous la forme de chemin dans le système de fichier, y en a des tonnes. Le changement de pilote pour les disques IDE et le renommage des noms de disques qui a suivi ( hda/sda ) est un exemple de trucs qui a du casser des scripts. Les changements dans /sys aussi.

                                    Le monde s'est pas arrêté de tourner pour autant. Découvrir juste aujourd'hui le problème des ABI/API c'est juste avoir été sous un igloo depuis longtemps.

                                    Et le mail de Lennart prévient à l'avance qu'il va falloir s'adapter au changement. Je pense avoir lu sur lwn que l'idée est de déprécier l'interface au bout de ~2 ans, ce qui laisse largement le temps de pouvoir faire des mises à jours, donc on est loin des suppositions de "on va devoir mettre à jour le jour de la sortie".

                                    • [^] # Re: Ca ne règle pas la source du problème

                                      Posté par . Évalué à 3.

                                      On est parti

                                      Exemple, udev avant que ça devienne part au projet systemd :
                                      http://lwn.net/Articles/193603/
                                      ( 2006, pour les gens qui veulent pas cliquer ). Et pour les gens qui veulent pas cliquer aussi, on voit GKH poser la question de "pourquoi on va supporter les trucs que les créateurs refusent de supporter plus longtemps".

                                      Il a posé la question et la réponse a été le support de HAL jusqu'en 2010 à peu près et le retrait total des distribs qui n'a eu lieu que vers 2011. On est loin de la rupture d'API du jour au lendemain.

                                      Des APIs exposés sous la forme de chemin dans le système de fichier, y en a des tonnes. Le changement de pilote pour les disques IDE et le renommage des noms de disques qui a suivi ( hda/sda ) est un exemple de trucs qui a du casser des scripts.

                                      hda c'etait (et c'est toujours à ma connaissance) pour le PATA de base (nappe de 40 connecteurs) ou le PATA 60Mb/s, SDA c'est pour le scsi, le SATA et certains mode en PATA (généralement 80 et 100Mb/s - nappe 80 connecteurs). Pour se retrouver avec un changement de nom qui casse le script il faut soit changer le disque, soit trifouiller dans le bios soit carrément changer de carte mère. On va dire que c'est pas franchement de la faute du kernel sur ce coup là.

                                      Autre exemple ? Iptables, et notamment des projets approchants comme ipset, etc. Tu mets à jour ta distro, et il te faut une version plus à jour de tel ou tel truc interne.

                                      Il te faut une version plus à jour si tu veux utiliser les nouvelles fonctionnalités.Mais pour le reste… Quand on est passé de IPCHAINS à NetFilter Linus a tout fait pour que les scripts soient compatibles (il y avait des modifications minimes à faire) et plus fort encore, vu le tollé que la migration de 2.0 à 2.2 avait été suite à la rupture entre IPFWADM et IPCHAINS, NetFilter était aussi compatible avec IPFWADM. Donc on pouvait passer de 2.0 à 2.4 quasiment sans toucher à ses règles firewall.

                                      Les trois exemples que tu donnes vont exactement dans le sens contraire de ce que tu veux démontrer, le maintien de l'expérience utilisateur est une priorité du noyau (et du système Linux en général) depuis des années. Et ce n'est pas par réactionnite aiguë, c'est parce que quand le systèmes bouge trop ou trop vite, les administrateurs perdent confiance et soit changent de produit, soit restent sur le produit précédent.

                                      • [^] # Re: Ca ne règle pas la source du problème

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

                                        sda n'a pas toujours été utilisé pour les disques SATA, j'ai eu au tout début du support du hda si ma mémoire est bonne… C'était sous Mandrake, Misc peut surement confirmer ou dire que j'ai un peu la mémoire qui flanche…

                                        Ensuite, essaye de faire tourner une vieille distrib sur un noyau récent, tu verras que plein de chose partent en couille…

                                        • [^] # Re: Ca ne règle pas la source du problème

                                          Posté par . Évalué à 3.

                                          sda n'a pas toujours été utilisé pour les disques SATA, j'ai eu au tout début du support du hda si ma mémoire est bonne…

                                          Tout au début il n'y avait pas le support AHCI/SATA natif dans Linux pour de nombreux chipsets. On devait donc régler le bus en mode compatibilité ou legacy - grosso-modo une émulation du PATA. Donc le disque était reconnu comme PATA par le noyau.

                                          Ensuite, essaye de faire tourner une vieille distrib sur un noyau récent, tu verras que plein de chose partent en couille…

                                          Ben Honnêtement pas tant que ça. Il y a bien sur tout ce qui dépend des linux-headers qui est à recompiler à la main et Xorg est une cause perdue si il y a plus de 9/10 mois de différence entre les deux noyaux. Mais pour le reste ca passe pas mal du tout. Honnêtement en environnement serveur entreprise (qui est à mon sens le seul genre d'environnement ou il y a un interet à se livrer à ce genre de pratiques) ca se fait. La période horrible à ce genre de jeux là ca a été le passage de GCC 4.2 à GCC 4.4 et une liste d'incompatibilités longue comme le bras. Là oui quand tu veux migrer ton kernel et les outils liés à ce kernel dans une version récente, tout en gardant tout le reste sur des versions obsolètes mais en ayant quand même les nouvelles bibliothèques systèmes qui sont linkables par les vieux paquets. Là tu douilles.

                                          Ceci dit quand tu fais ça c'est que tu cherche à préserver un ou deux logiciels (généralement proprios) pas toute une distrib fonctionnelle donc tu fini par y arriver quand même.

                                        • [^] # Re: Ca ne règle pas la source du problème

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

                                          Je confirme, mais visiblement, c'est un temps que Kaane a du soit oublier, soit ne pas connaitre, car ça remonte quand même à longtemps ( facile 7 à 10 ans ).

                                    • [^] # Re: Ca ne règle pas la source du problème

                                      Posté par . Évalué à 10.

                                      Le monde s'est pas arrêté de tourner pour autant.

                                      Mais des gens s'en plaignent depuis longtemps. Sérieux tente de lancer Unreal Tournement 2003 ou 2004 sur une distribution aujourd'hui. Prend même Debian old stable si ça te fais plaisir. A mon dernier essaie il y avait à minima un problème sur la manière dont était géré le son. Tu peut probablement le lancer, mais il va te falloir une série de hacks.

                                      Ces problèmes on en a déjà beaucoup trollé dessus et c'est être dans le déni que de ne pas le voir. On expliquera que ce n'est un problème que pour les logiciels propriétaires, que pour les logiciels qui ne sont pas maintenus, etc, oui dans un monde parfait tout le monde est totalement à jour, on a des armés de millions de packageurs pour chaque distribution, tous les logiciels qui ne sont pas tout à fait maintenus sont inutiles, mais bon en attendant il y a des gens qui essaient de se servir de linux dans des conditions pas optimales.

                                      Ces gens n'ont pas l'air très intéressants pour la communauté vu qu'au lieu d'essayer de stabiliser les choses, on accélère la fuite en avant.

                                      Ces gens pourtant c'est ceux qui font la fierté de linux (HPC et calcul scientifique). Je présume que ça ne représente pas quelque chose de très important pour l'habitué des flamewares.

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

                                      • [^] # Re: Ca ne règle pas la source du problème

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

                                        je sais, même déjà à l'époque de UT99, c'était compliqué. Le faire tourner 3/4 ans après, il fallait ressortir les vielles libs dans un chroot.

                                        Je suis d'accord pour dire que c'est un souci, je suis juste pas d'accord pour dire que systemd est le premier exemple, et donc ralé sur ça spécifiquement sur systemd, c'est faire preuve de mauvaise foi. Et accuser spécifiquement lennart alors qu'il ne fait que suivre la voie tracée par les codeurs noyaux et tout le reste de l'écosystème depuis des années, c'est simplement n'importe quoi. Des gens utilisent ça pour se donner un argument de respectabilité illusoire auprés des nouveaux venus. Et c'est un peu comme les gens du mouvement gamergate qui parle d'éthique dans le journalisme dans le jeu video d'un coup, alors que c'est un souci depuis des années ( exemple connu, Marc Lacombe aka Marcus ayant quitté Gameone à cause des pressions d'Infogramme sur la redaction ), et certains s'en servent pour se donner une image présentable pour juste se défouler et attaquer les gens. C'est moindre dans le libre, mais on retrouve quand même au moins un mec qui fait parti des 2 mouvements ( aka MikeeUSA, aka Gregory Smith, etc ).

                                        mais si c'était tellement un souci pour le libre, les gens utiliseraient Netbsd, Centos ou ce genre d'OS qui promettent une compatibilité plus longue. Si c'était un souci suffisamment important, les gens ne rejetteraient pas la LSB comme contraignante mais l'adopteraient. Ou on aurais plus de tests automatisés d'ABI/API via http://ispras.linuxbase.org/index.php/ABI_compliance_checker . moins de gens à se jeter sur ruby/go/node etc et la catastrophe d’écosystème pas ultra mature et stabilisé.

                                        Et ce qu'on voit plutôt, c'est que les devs veulent les nouvelles versions des libs ( Google Chrome et RHEL 6 pour ne citer que cet exemple, gcompris qui avait besoin d'un gtk récent et les discussions de son auteur ici il y a une paire d'année ).
                                        C'est que ça fait chier de garder la compatibilité alors qu'on peut juste faire un code dump sur ruby.

                                        • [^] # Re: Ca ne règle pas la source du problème

                                          Posté par . Évalué à 5.

                                          Je suis d'accord pour dire que c'est un souci, je suis juste pas d'accord pour dire que systemd est le premier exemple, et donc ralé sur ça spécifiquement sur systemd, c'est faire preuve de mauvaise foi.

                                          On est d'accord.

                                          mais si c'était tellement un souci pour le libre, les gens utiliseraient Netbsd, Centos ou ce genre d'OS qui promettent une compatibilité plus longue. Si c'était un souci suffisamment important, les gens ne rejetteraient pas la LSB comme contraignante mais l'adopteraient. Ou on aurais plus de tests automatisés d'ABI/API via http://ispras.linuxbase.org/index.php/ABI_compliance_checker . moins de gens à se jeter sur ruby/go/node etc et la catastrophe d’écosystème pas ultra mature et stabilisé.

                                          Tu mélange beaucoup de choses :

                                          les gens utiliseraient Netbsd

                                          Non, parce que NetBSD n'a pas les même performances que linux et parce qu'il n'a pas le même support (autant matériel que logiciel).

                                          Centos ou ce genre d'OS qui promettent une compatibilité plus longue

                                          CentOS et RHEL (et peut être Suse) c'est ce qui est utilisé oui, mais ça n'empêche pas d'avoir des cassures franches.

                                          moins de gens à se jeter sur ruby/go/node etc et la catastrophe d’écosystème pas ultra mature et stabilisé.

                                          Ce ne sont pas les même personnes, ni les même applications. Il y a une grosse partie de technophiles, qui font du web entre autres qui veulent utiliser les toutes dernières techno pour présenter des interfaces les plus agréables possibles à leur client (c'est entre autre ce que fait Google, Amazone, Twitter, Facebook, etc). Mais ça n'empêche pas d'avoir des gros utilisateurs de linux utiliser du code Fortran, C, C++ et ADA pas ou moyennement maintenu pour faire du calcul haute performance, du trading haute fréquence, pour faire tourner leur banque, leur production industrielle, pour faire tourner des applis scientifiques (je pense à ce qu'on trouve par exemple dans les accélérateurs de particules).

                                          On parle bien de types d'utilisateurs totalement différents. C'est vrai qu'on voit sur le web plus de personnes qui font du web (comme c'est bizarre), comme ils sortent une nouvelle techno tous les dimanches matin ils ont toujours pleins de choses à dire.

                                          Pour savoir pourquoi ces gens ne participent pas à la LSB et au test automatisées d'ABI. Je pense que c'est pas leur habitudes, que les trolls (et les fortes personnalités) font peur. Qu'ils maintiennent des vielles appli donc qu'ils ne peuvent pas comme ça être LSB compliant.

                                          Je ne dis pas que ces gens n'ont pas de défaut et que la faute reviens qu'aux mainteneurs, je dis que le problème existe et que c'est entre autre là dessus qu'AIX fais son beurre.

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

                                          • [^] # Re: Ca ne règle pas la source du problème

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

                                            Non, parce que NetBSD n'a pas les même performances que linux et
                                            parce qu'il n'a pas le même support (autant matériel que
                                            logiciel).

                                            Certes, mais on peut pas avoir le beurre et l'argent du beurre. La compatibilité a un cout humain, et le temps que tu passes à tester et à vérifier que rien ne casse, c'est du temps que tu passes pas à optimiser et à coder pour du nouveau hardware.

                                            Un exemple stupide. Tu codes ton unix like avec l'infra video du moment, et en l'espace de 5 ans, tout change et il te faut de la 3d partout. Si tu t'occupes de la compatibilité, alors tu va maintenir 2 couches. Si tu t'en fout, alors tu va t'occuper que de la dernière. Et tu va passer plus de temps à rendre la dernière rapide/propre/etc que si tu avais que la moitié ou 75% du temps.

                                            Bien sur, ça n'explique pas tout pour netbsd, mais ça explique une partie.

                                            Et peut être qu'une innovation rapide mais chaotique et cahoteuse à la Linux marche mieux pour avoir le support du hardware et des perfs, ce qui ensuite attire plus de gens, dans un cercle vertueux.

                                            Et en effet, des boites comme IBM, HP, RH font leur beurre sur les demandes de stabilité.

                                            • [^] # Re: Ca ne règle pas la source du problème

                                              Posté par . Évalué à 4.

                                              Bien sur, ça n'explique pas tout pour netbsd, mais ça explique une partie.

                                              Ça n'est surtout pas pour ça que kNetBSD est moins performant que linux. C'est plus une question de main d’œuvre. S'occuper des performances c'est long, pas tout le monde veut ou est capable de le faire. NetBSD s'intéresse à d'autres problématique (à raison).

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

                                              • [^] # Re: Ca ne règle pas la source du problème

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

                                                Je ne suis pas sûr que s'occuper des performances est plus coûteux en terme de main d'œuvre que de faire évoluer un système sans régression. Intuitivement, je dirais d'ailleurs que c'est l'amélioration des performances avec régressions (minimes) qui est plus facile.

                                                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                      • [^] # Re: Ca ne règle pas la source du problème

                        Posté par . Évalué à 8. Dernière modification le 28/11/14 à 08:05.

                        Il te suffit d'enlever quiet aux arguments de boot… Par défaut systemd est plutôt bavard.

                        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                      • [^] # Re: Ca ne règle pas la source du problème

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

                        Néanmoins, pour l’avoir actif sur une debian Jessie, je n’aime pas le fait de n’avoir que deux lignes pendant la phase
                        de démarrage…

                        Vois ça avec debian, ce n'est pas systemd:
                        http://bencord0.files.wordpress.com/2013/09/systemd-boot.png

                        • [^] # Re: Ca ne règle pas la source du problème

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

                          Vois ça avec debian, ce n'est pas systemd

                          Tu rigoles? quelle utilité à râler sur les vrais coupables quand on a le plaisir d'avoir un bouc émissaire?

                          J'ai l'impression que le pire dans cette histoire est qu'il y ai si peu de monde à faire remarquer que les coupables sont les mainteneurs de distros (coupables du choix, coupables de la configuration…), c'est triste ces gens aiment s'inventer des coupables (des fois, on se demande comment l'Etat de droit arrive à fonctionner avec autant de gens ne s'interessant pas à la recherche de coupable mais juste à la recherche d'une personne sur qui concentrer sa haine).

            • [^] # Re: Ca ne règle pas la source du problème

              Posté par . Évalué à 0.

              Le tout setuid root, sinon c'est pas drôle

      • [^] # Re: Ca ne règle pas la source du problème

        Posté par . Évalué à 2.

        Merci, tu as bien résumé ma pensée, avec un ton très intelligent et mesuré, j'aime bien ça.

        C'est effectivement problématique qu'il y ait des attaques agressives des deux côtés. Mais laissons les méchants cracher leur bile, et trollons ensemble gentiment dans la joie !

        Perso, j'attends de voir si uselessd devient une alternative potable, il me semble vraiment intéressant.

    • [^] # Re: Ca ne règle pas la source du problème

      Posté par . Évalué à 8.

      On a droit de faire ce qu'on veut non ? Le sysadmin est maître de sa machine ?
      Alors ce genre de remarque…

  • # Dépendances

    Posté par . Évalué à 2.

    Et quand tu auras la moitié des paquets qui dépendront de systemd, et qui ne voudront donc pas s'installer, il faudra bien trancher dans le vif (accepter systemd ou changer de distrib/OS)…

    • [^] # Re: Dépendances

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

      Et encore. Même FreeBSD commence à s'y mettre. FreeBSD Plans for the Next Ten Years :

      « The last item about service start-up improvements comes down to dramatically redoing or replacing /etc/rc.d and becoming more systemd-like. In fact, this FreeBSD presentation even earned the praise of Lennart Poettering. »

      • [^] # Re: Dépendances

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

        Heureusement MS Windows semble épargné par cette épidémie.
        ----->

        • [^] # Re: Dépendances

          Posté par . Évalué à -1. Dernière modification le 27/11/14 à 13:50.

          ainsi que Mac Os X (en plus c'est libre, mais ça semble ressembler à systemd).

          • [^] # Re: Dépendances

            Posté par . Évalué à 5.

            Euh, c'est l'inverse : c'est systemd qui s'en inspire (enfin de ça, et d'upstart).

            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

            • [^] # Re: Dépendances

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

              Et plus précisément, launchd a inspiré systemd sur ce qu'il fallait faire, et upstart sur ce qu'il ne fallait pas faire.

            • [^] # Re: Dépendances

              Posté par . Évalué à -2.

              je sais que c'est antérieur (les dates sont indiquées sur wp), quoi qu'il en soit les deux se ressemblent, c'est pas parce que launchd ressemble à systemd que ça indique un sens d'inspiration.

  • # ou alors installer init

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

    Autre solution, tu installes init qui est un méta-paquet pour choisir son syteme d'init parmi systemd, upstart et sysvinit. Par la suite, si un paquet demande spécifiquement systemd (il y en a) ton init ne changera pas.

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

    • [^] # Non…

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

      Le paquet init garantit la présence d'un des trois systèmes d'init, rien d'autre.

      Debian Consultant @ DEBAMAX

      • [^] # Re: Non…

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

        Ah oui tiens… flute je croyais qu'on pouvait choisir avec debconf.
        Je profite de l'expert : c'est possible à faire (pour plus tard) ou ce serait trop compliqué ou inutile?

        Note pour ceux qui l'ignoreraient: Cyril est un éminent developeur Debian.

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

        • [^] # Re: Non…

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

          Pour l'absence de debconf etc., il suffit de constater l'absence de scripts de mainteneur ({pre,post}{inst,rm}) : /var/lib/dpkg/info/init.*.

          Je ne vois pas trop à quoi pourrait servir de forcer une telle chose. L'approche qui consiste à utiliser l'apt pinning pour indiquer une préférence au gestionnaire de paquets me semble relativement appropriée. Il manque probablement un patch ou deux dans les release notes pour avoir « I want to keep sysvinit. » dans la documentation qui va bien.

          (Ton commentaire est gentil mais c'est exagéré.)

          Debian Consultant @ DEBAMAX

          • [^] # Re: Non…

            Posté par (page perso) . Évalué à 4. Dernière modification le 27/11/14 à 16:16.

            Pourquoi se casser la tête avec du pinning alors qu’on a le paquet systemd-shim qui sert justement à éviter l’installation du système d’init de systemd ?
            Et pour ceux qui ne supportent pas de voir la chaîne de caractères "systemd" dans un nom de paquet (ne riez pas, j’en connais), ne leur reste plus que le boycott de tous les paquets dépendant d’une quelconque libsystemd-foo.

            Et pour ce qui est de conserver SysV comme système d’init lors du passage à Jessie, c’est un jeu d’enfant :
            1. ajout des depôts de Jessie à la Wheezy
            2. apt-get update
            3. apt-get install systemd-shim sysvinit-core
            4. apt-get dist-upgrade
            5. Hop, une Jessie avec SysV

            • [^] # Re: Non…

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

              J'ai indiqué que je trouvais l'approche mentionnée au départ (apt pinning) appropriée, et que la notion de sélection via debconf ne me semblait ni convaincante ni nécessaire. Pas que le pinning était la seule et unique vraie façon véritable d'arriver au résultat désiré.

              Quant à systemd-shim, cf. les discussions concernant libpam-systemd etc. L'ordre dans les dépendances alternatives peut donner des résultats différents en fonction de l'ensemble de paquets de départ et de l'ensemble des paquets à installer/mettre à jour.

              Debian Consultant @ DEBAMAX

            • [^] # Re: Non…

              Posté par . Évalué à 1. Dernière modification le 30/11/14 à 18:06.

              Et pour ceux qui ne supportent pas de voir la chaîne de caractères "systemd" dans un nom de paquet (ne riez pas, j’en connais)

              C’est dingue comme ça déchaîne les passions… quel besoin de tourner en dérision les gens qui ne sont pas d’accord avec toi ?

              ne leur reste plus que le boycott de tous les paquets dépendant d’une quelconque libsystemd-foo.

              Ça risque d’être un peu compliqué, en tout cas sur un desktop :

              % apt-cache rdepends libsystemd-login0
              libsystemd-login0
              Reverse Depends:
              systemd-dbg
              systemd
              python-systemd
              libsystemd-login-dev
              pulseaudio
              mate-screensaver
              systemd
              libsystemd-login-dev
              pulseaudio
              dbus-1-dbg
              dbus

        • [^] # Re: Non…

          Posté par . Évalué à 1.

          Je viens de découvrir un paquet s'appelant init-select qui semble pouvoir permettre le choix entre les init

          • [^] # Re: Non…

            Posté par . Évalué à -5. Dernière modification le 27/11/14 à 21:55.

            C'est un peu ça le problème de Daubian aujourd'hui : même des admins qui l'utilisent depuis plus de 10 ans en sont maintenant à aller à la pêche pour trouver comment ça peut se configurer…

            Bref, y'a longtemps que KISS s'est barré en courant/pleurant.

  • # Alternative (uselessd, ...)

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

    Bloquer systemd "en attendant que" est intéressant à savoir faire, mais un pis-aller.

    Comme l'a dit benoar, il y a uselessd, qui peut constituer une alternative intéressante, techniquement et philosophiquement.

    (à titre personnel, j'ai réussi à lui faire booter un des mes systèmes jusqu'à la GUI, mais attends de peaufiner un peu avant d'en faire un journal)

Suivre le flux des commentaires

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