Journal Non, systemd n'est vraiment pas parfait ! (ni prêt)

Posté par  . Licence CC By‑SA.
Étiquettes :
17
9
nov.
2012

Non, systemd n'est vraiment pas parfait ! Alors, oui, je veux bien croire qu'il améliore pas mal de choses,
qu'il est plus "beau" plus rapide, plus "simple" et peut-être même qu'il rend le poil de votre poney luisant !

Mais, tout de même, je ne suis pas convaincu que ce soit une bonne idée que de précipiter un projet si "jeune".
Remplacer une partie si important de notre système d'en un temps aussi court !

Un exemple tout con, aujourd'hui, je viens de me rendre compte que, par défaut, screen/t-mux ne fonctionne plus avec systemd ! Et oui !

Quand on lance screen depuis un environnement graphique, lui-même démarrer depuis un service systemd, celui-ci fera partie du cgroups du service.
Si bien que quand on désira fermer Xorg proprement (CAD, en terminant le service) screen étant dans le cgroups de ce dernier,
se fera killer…. Bref, 60% de l'intérêt de screen perdu !

Alors, oui,
j'imagine qu'il doit surement avoir un moyen d'écrire une règles pour sortir screen du cgroup
voir crée un nouveau cgroups pour lui… Mais tout de même, là, j'ai l'impression d'être un bêta testeur !

Cela me rappelle un peut les propos de Lennart qui expliquait que si PulseAudio n'avais pas été "forcer"
(comprendre mis par défaut dans une distribution GNU/Linux populaire) il ne serait jamais aussi rapidement stable qu'il peut l'être aujourd'hui :

«..franchement nous n'avions pas vraiment d'autre option que de le pousser dans les distributions quand nous l'avons fait.
Certes Pulseaudio n'était pas un logiciel sans bug…»

«…Et puis quelle autre option est-ce que nous aurions eu ? C'est très naïf de croire que, si nous avions attendu plus longtemps avant de pousser Pulseaudio vers les distributions, les choses auraient été différentes : vous ne pouvez pas corriger les bugs que vous ne connaissez pas, et les incitations et les ressources humaines sont trop faibles pour avoir des corrections avant qu'il y ait la pression inhérente à un logiciel déjà intégré dans une distribution.»

cf: Un entretien avec Lennart Poettering - LinuxFr.org

Bref, là, j'ai l'impression qu'il nous refait exactement la même avec systemd…
Il nous prend pour des bêtas testeurs !

  • # Pas con

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

    L'argument de Lennart se comprend parfaitement dans l'optique de Fedora, laboratoire d'expérimentation de Red Hat. C'est assez logique de ce point de vue.

    Du coup Debian a pas tort d'attendre que les trucs soient un peu éprouvés avant de les inclure en général.

  • # Et merde !

    Posté par  . Évalué à 4.

    Cet article n'a pas été soumis à une relecture, merci de me flageller avec un câble RJ45 !

    • [^] # Re: Et merde !

      Posté par  . Évalué à 3.

      Profites-en pour relire ton avatar avec "man rm" à côté.

    • [^] # Re: Et merde !

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

      Cet article n'a pas été soumis à une relecture, merci de me flageller avec un câble RJ45 !

      Techniquement, un "cable RJ45" n'existe pas. On parle plutôt de "paire torsadée", dont le modèle de prise se nomme "RJ45". Sinon, tu peux éventuellement parler de cable "10BT, 100BT ou 1000BT".

      Atem18, un administrateur réseaux traumatisé par ses cours de réseaux de première année de BTS.

      • [^] # Re: Et merde !

        Posté par  . Évalué à 4.

        Tu as tout à fait raison.

        À ma connaissance on n'utilise pas la connectique RJ45 avec autre chose que de la paire torsadée (et on n'utilise pas de la 4 paires torsadées avec une autre connectique que RJ45…) d'où le raccourcis sémantique si courant.

        Bon courage pour surmonter ton traumatisme scolaire ;)

        • [^] # Re: Et merde !

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

          À ma connaissance on n'utilise pas la connectique RJ45 avec autre chose que de la paire torsadée (et on n'utilise pas de la 4 paires torsadées avec une autre connectique que RJ45…) d'où le raccourcis sémantique si courant.

          Tu as tout à fait raison, toi aussi. Après, j'ai dis ça pour le taquiner un peu. Il vaut mieux à mon sens dire "câble RJ45" que "câble internet".

          Bon courage pour surmonter ton traumatisme scolaire ;)

          Ne t'en fais pas, j'ai juste retenu ça. J'ai préféré oublier les cours qui dataient de 1993 et qui parlaient des cd-rom qui allaient être une révolution dans l'informatique, puisque remplaçant les disquettes. Va savoir pourquoi. :p

          • [^] # Re: Et merde !

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

            Il vaut mieux à mon sens dire "câble RJ45" que "câble internet".

            Tseeee, il faut dire « facecable » de nos jours.

        • [^] # Re: Et merde !

          Posté par  . Évalué à 4.

          Si, les câbles console de certains équipements réseaux (routeurs Cisco notamment) utilisent une connectique RJ-45, mais le câble est un câble plat. Exemple :

          Titre de l'image

          (bon, on peut aussi se flageller avec ça, ça doit marcher aussi bien…)

          • [^] # Re: Et merde !

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

            Les anciens câbles réseau était aussi plat. C'est de la daube car cela ne tiens pas le débit mais pour du RS232, c'est largement suffisant sur des courtes distances…

      • [^] # Re: Et merde !

        Posté par  . Évalué à 2.

        Le câble s'appelle UTP, FTP ou STP, et on mentionne généralement sa catégorie.

  • # pam_systemd

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

    Ça ne résout pas ton problème : http://0pointer.de/public/systemd-man/pam_systemd.html ?

    • [^] # Re: pam_systemd

      Posté par  . Évalué à 10.

      depuis quand PAM résoud des problèmes ? :-)

    • [^] # Re: pam_systemd

      Posté par  . Évalué à 2.

      Je pense…

      Mais comme je l'ai dit, « il doit surement avoir un moyen d'écrire une règles pour sortir screen du cgroup ».

      (Merci au passage !)

    • [^] # Re: pam_systemd

      Posté par  . Évalué à 2.

      Si j’ai bien compris, un utilisateur qui écrit un programme tout simple qui se détache, pour qu’il tourne en arrière plan jusqu’à une prochaine session. Il doit en plus de coder son programme, ajouter une règle à systemd sinon celui-ci tue le process quand même ? Ou j’ai pas bien compris ?

      Si c’est ça, c’est encore pire, ça éloigne carrément de la philosophie UNIX.

      • [^] # Re: pam_systemd

        Posté par  . Évalué à 5.

        ou simplement des bonnes pratiques de la programmation …

        • [^] # Re: pam_systemd

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

          Il ne faut pas non plus tout mélanger.

          Un des principes d'UNIX est de bien séparer les choses. Mettre une session dans un container cgroup est assez logique. Cela n'a rien à voir avec systemd d'ailleurs et pourrait certainement être fait avec le système actuel.

          Fermer le cgroup à la fin de la session pour tout nettoyer est aussi logique. C'est déjà fait sur les machines de calculs dont les gestionnaires de tâches place les job dans des cpuset. En effet, un job qui demande 12h a 12h mais pas 13 ! Donc au bout de 12h, on tue tout et pour savoir quoi tuer, on regarde le cgroup… Il n'y a pas d'autres solutions fiables à ma connaissance.

      • [^] # Re: pam_systemd

        Posté par  . Évalué à 6.

        Ça fait plus d'un an que j'utilise systemd et tmux et je n'ai jamais rencontré ce problème, j'ouvre/je ferme des sessions X, aucun soucis avec les sessions tmux démarrés sous tty ou X.
        Par défaut, systemd ne tue pas les processus utilisateurs (pam_systemd permet de le configurer plus finement, mais il y a une clé de configuration globale dans systemd-logind.conf Cf. man), donc c'est probablement un problème de configuration.

        Si on parle de la maturité de systemd, je rappelerais que quand la majorité des distros Linux l'ont adopté, Upstart était loin d'être parfait non plus (c'est d'ailleurs un demi-succès puisqu'en dehors d'Ubuntu personne n'utilise les jobs Upstart natifs)
        Je comprends pas qu'on puisse regretter init SysV, avec le pare-feu, c'est l'un des deux trucs qui me font préférer les systèmes *BSD (IPtables, ça aussi c'est de la belle merde)

        • [^] # Re: pam_systemd

          Posté par  . Évalué à 3.

          https://bugzilla.redhat.com/show_bug.cgi?id=612712 (le ticket Fedora correspondant a désormais plus de 2 ans)

        • [^] # Re: pam_systemd

          Posté par  . Évalué à 5.

          Si on parle de la maturité de systemd, je rappelerais que quand la majorité des distros Linux l'ont adopté

          Qui l'avait adopté en dehors d'Ubuntu, Fedora et RHEL ?

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

            Posté par  . Évalué à 1.

            debian, Maemo, ChromeOS (d'ailleurs James Scott Remnant le mainteneur d'Upstart a été embauché par Google), etc… La plupart des distros majeures ont une intégration satisfaisante d'Upstart même si pas toujours par défaut.
            Pour opensuse, ça s'est joué au fil du rasoir, quand l'intégration d'Upstart a été jugé mature pour passer en production, ils ont décidés de passer à systemd. Idem pour d'autres distros qui ont pas mal lanternés (Frugalware entre autre) et qui du coup sont passés directement à systemd.

            • [^] # Re: pam_systemd

              Posté par  . Évalué à 6.

              Upstart est disponible dans Debian mais n'est pas l'init par défaut. Ça me semble quand même être loin de la majorité des distributions.

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

          Posté par  . Évalué à 4. Dernière modification le 09 novembre 2012 à 23:39.

          Donc une configuration d’un module de l’init est requise pour qu’un programme où on fait un setsid pour créer une session et un fork pour détacher le processus fils, puis que le père se tue de façon à ce que le fils devienne orphelin et qu’il soit adopté par le père de tous (init), comme le prévois POSIX, ne fonctionne pas systématiquement. Suis-je le seul à trouver que ça fait beaucoup de petits défaut ?
          Après, que ce soit configurable ok, mais que le système d’init modifie la façon dont les processus vivent me gène. C’est au noyau de faire ça.

        • [^] # Re: pam_systemd

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

          (IPtables, ça aussi c'est de la belle merde)

          Je veux bien que tu développes là.

          • [^] # Re: pam_systemd

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

            Pas très dur, il est en train de dire que la syntaxe ne lui plait pas…

            Alors certes PF est vraiment plus intuitif dans l'écriture des règles mais cela ne permet en aucun cas de dire que iptables c'est de la belle merde.

            • [^] # Re: pam_systemd

              Posté par  . Évalué à 4.

              Pas très dur, il est en train de dire que la syntaxe ne lui plait pas…

              La syntaxe d'IPtables est juste imbitable mais ce n'est pas la seule raison.
              IPtables ne permet pas de modifier une règle dynamiquement (même si ipset comble partiellement ce besoin aujourd'hui), le traitement des paquets est particulièrement complexe alors qu'avec PF ça revient à faire passer le paquet à travers les règles listés dans la conf de manière linéaire.
              Faire du NAT, de la limitation de bande passante, c'est beaucoup plus simple avec PF qu'avec IPtables.
              C'est uniquement mon point de vue en tant que sysadmin bénévole, je n'ai aucunement la prétention de comparer les perfs ou les fonctionnalités entre les deux solutions.

              • [^] # Re: pam_systemd

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

                ça revient à faire passer le paquet à travers les règles listés dans la conf de manière >linéaire

                C'est aussi le cas d'iptables…

                • [^] # Re: pam_systemd

                  Posté par  . Évalué à 5.

                  La différence entre un bon pare-feu et un mauvais pare-feu, c'est que le bon pare-feu fait passer les paquets à travers les règles listées dans la conf de manière linéaire, alors que le mauvais pare-feu… aussi, mais c'est un mauvais pare-feu.

                  http://www.youtube.com/watch?v=vH2GdDrJpKg

  • # C'est insultant !

    Posté par  . Évalué à 2.

    Comment oses-tu manquer de respect au bêta-testeurs ?! Tu devrais avoir honte !

  • # Laisse moi deviner tu utilise Fedora non?

    Posté par  . Évalué à 2.

    Donc tu es un béta testeur oui, puisque le but de Fedora est de faire de l'intégration pour RedHat.

    • [^] # Re: Laisse moi deviner tu utilise Fedora non?

      Posté par  . Évalué à 2. Dernière modification le 09 novembre 2012 à 16:49.

      Nope ! Même pas ! Frugalware

    • [^] # Re: Laisse moi deviner tu utilise Fedora non?

      Posté par  . Évalué à 7.

      Le but de Fedora c'est de faire ce que veut faire la communauté Fedora.
      Contrairement à d'autres distros, nous n'avons pas de dictateur à vie qui décide pour nous -contributeurs- et toutes les décisions techniques sont prises par le Fesco qui est entièrement élu par les contributeurs actifs.
      Dire que Fedora fait de l'intégration pour RedHat, c'est aussi vrai que de dire que Debian fait de l'intégration pour Ubuntu & cie.

      • [^] # Re: Laisse moi deviner tu utilise Fedora non?

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

        D'ailleurs, la preuve est qu'il y a plein de projets RH qui sont pas dans Fedora :
        - pulp/katelo/etc, qui sont à la base de systemengine, etc de cloudform ( dispo depuis juin sur RHEL )
        - openshift, qui était déjà déployé en prod avant d'arriver dans Fedora
        - ovirt est pas dispo dans Fedora, il y a encore plein de paquets à faire ( et ovirt, c'est le pendant communautaire de rhev, la plateforme de virtualisation qui est déja dispo en version 3 )
        - jboss et co, dans la majeure partie des projets sont pas dans Fedora ( et le peu sont depuis très peu de temps, pour faire rentrer ovirt )
        - ceylon, pas dans Fedora pour le moment

        Et c'est pas des produits mineurs pour la plupart, bien au contraire. Si personne n'est motivé ou n'a le temps pour le faire rentrer dans Fedora, ou si ça prends du temps, y a pas de laisser passer "je suis payé par le plus gros sponsor, faut me faire le taf ou faut bacler".

        Donc dire que Fedora sert d'expérimentation est une grosse simplification. Autant dire que Ubuntu a servi de beta test pour openstack, vu qu'ils ont fait sans doute du taf dessus avant que ça arrive comme Technological Preview dans RHEL.

      • [^] # Re: Laisse moi deviner tu utilise Fedora non?

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

        Je pense quand même qu'il y a une certaine influence de Red Hat sur Fedora, notamment pour pousser les nouveautés de Lennart et cie

        • [^] # Re: Laisse moi deviner tu utilise Fedora non?

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

          Fedora a refusé systemd par défaut sur le prétexte qu'il n'y avait pas assez de documentation pour Fedora 15 ( ou 14 ), firewalld a été repoussé sur le même prétexte pour Fedora 17 et parce que le système était pas fini, la refonte de l'ui d'anaconda a été repoussé plusieurs fois aussi.

          Si il y a une influence, je trouve qu'elle a tendance à se plier bien facilement aux demandes de la communauté et du FESCO.

          Et faut pas non plus se leurrer, il y a une équipe QA chez RH, que ça soit via Fedora ( genre adam williamson ) que sur chaque produit, il suffit de voir les offres d'emploi pour s'en convaincre. Donc Fedora n'est pas la pour remplacer la QA ou l'équipe R&D de RHEL ( surtout vu l'usage de Fedora sur les serveurs ), et comme c'est du libre, il ne faut pas oublier tout le monde bénéficie des bugs corrigés via Fedora ( et encore plus inversement, tout un tas de monde fait du taf en dehors de Fedora qui bénéficie à Fedora ).

          • [^] # Re: Laisse moi deviner tu utilise Fedora non?

            Posté par  (site web personnel) . Évalué à 2. Dernière modification le 10 novembre 2012 à 12:45.

            Je n'ai pas compris le rapport de ton dernier paragraphe avec la discussion (l'influence de RH sur Fedora) ?
            Pour le 1er paragraphe, c'est intéressant et je l'ignorais, merci

            • [^] # Re: Laisse moi deviner tu utilise Fedora non?

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

              Dans le sens où Fedora n'est pas qu'un laboratoire pour RH et par RH mais est un laboratoire également pour tous les Logiciels Libres dans son ensemble.
              Car les technologies développées dans Fedora étant libres, tout le monde peut en tirer profit pour la suite, que ce soit les autres distributions ou les logiciels eux mêmes.

              Si demain des développeurs Debian viennent chez Fedora pour tester des technologies pas suffisamment stables pour aller chez eux, Fedora acceptera et Debian pourra l'implémenter chez elle une fois qu'elle trouvera le résultat satisfaisant. Quand tu regardes la plupart des nouveautés de Fedora sont proposés et développés par des membres de la communauté elle même, pas de Red-Hat, cela prouve l'ouverture de son développement à d'autres expérimentations que celles de Red-Hat.

              • [^] # Re: Laisse moi deviner tu utilise Fedora non?

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

                Un meilleur exemple serait plus eucalyptus, qui intègre son système de cloud computing dans Fedora, ou cloudstack ( même si les efforts de packaging sont en attente pour le moment ). On peut citer sugar, qui est dérivé de Fedora mais pas RH, ou des choses fait par dell :
                https://fedoraproject.org/wiki/Features/AgentFreeManagement
                http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming

                Perso, je pense qu'il devrait y avoir plus de boites qui font des choses autour de Fedora car ça ne peux que rendre le libre plus fort, mais je comprends que ça ne soit pas le plus évident à justifier auprès du chef, et qu'il va falloir un paquet de boites avant d'arriver à rattraper tout ce qui est investi par RH.
                ( au passage, je pense que c'est valable aussi pour Suse et pour Ubuntu, et l'idéal AMHA est d'atteindre un équilibre comme Debian ( ou ans une moindre mesure, Mageia ))

        • [^] # Re: Laisse moi deviner tu utilise Fedora non?

          Posté par  . Évalué à 7.

          Sans être "à l'intérieur" ni de RH, ni de Fedora (donc peut-être plus objectif, mais peut-être aussi moins bien renseigné?), j'ai l'impression suivante:

          Oui, RH a une certaine influence sur Fedora. Mais cette influence est gagnée à travers la participation au projet Fedora, sans garantie de convergence d'intérêt.
          Si RH réussit à faire élire une armée de développeurs RH aux commandes, alors ils sont maître à bord, s'ils n'en casent pas un seul, ils ne sont même pas représentés!

          Du coup, ils ont tout de même intérêt à mettre des ressources propres sur le projet Fedora, et je trouve ça très sain comme relation.

      • [^] # But de la communauté Fedora ?

        Posté par  . Évalué à 6.

        Le but de Fedora c'est de faire ce que veut faire la communauté Fedora.

        Fedora installe toujours sendmail 8 par défaut, non ?
        RedHat vend toujours du support dessus ?

        Sinon, quelle est la raison de conserver cette usine à gaz délirante en 2012, plutôt que de le mettre à la place qu’il mérite : dans l’histoire ?

        Autant Pulse Audio à ses débuts, Gnome 3.0 et systemd, on peut se dire que c’est pour être à la pointe, mais sendmail ?

        Ou alors le but de la communauté Fedora n’est pas la modernité, mais juste la complexité : toujours choisir les trucs les plus compliqués, même vieux, même quand il y a de meilleures solutions plus simples ?

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

        • [^] # Re: But de la communauté Fedora ?

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

          Ou alors le but de la communauté Fedora n’est pas la modernité, mais juste la complexité : toujours choisir les trucs les plus compliqués, même vieux, même quand il y a de meilleures solutions plus simples ?

          C'est un bon moyen pour se sentir important.

  • # ArchLinux

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

    Je lance screen dans konsole.

    Je quitte KDE -> KDM

    Je me log en root:
    # systemctl stop kdm.service

    $ screen -r

    Oh, je retrouve ma session screen…

    Merci de renommer ton journal: Non, frugalware n'est vraiment pas parfaite ! (ni prête)

  • # En même temps..

    Posté par  . Évalué à 10.

    Il nous prend pour des bêtas testeurs !

    C'est un peu l'idée sous Linux, non ? On est des gentils contributeurs qui utilisons un système gratuit qu'on peut modifier et améliorer, c'est une communauté où chacun met la main à la pâte..

    Après, si tu veux rester tranquille, profiter du système et avoir un esclave sur qui crier en cas de bug, tu peux toujours sortir le porte-monnaie.

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

    • [^] # Re: En même temps..

      Posté par  . Évalué à 6.

      tous le monde peut contribuer n'implique pas que les projets soient en phase béta-test perpétuelle.

      (/me regarde debian - )

      • [^] # Re: En même temps..

        Posté par  . Évalué à 0.

        Je me fais la même remarque ces dernier temps sur Archlinux, AMHA, "Rolling Release" n'est normalement pas synonyme de Testing.

        • [^] # Re: En même temps..

          Posté par  . Évalué à 4.

          Bah comment tu évites les bugs d'empaquettage si tu ne passes pas par une phase de testing ?

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

          • [^] # Re: En même temps..

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

            Bah comme pour le code, en codant sans bug.

            Franchement, je pige pas que les gens fassent encore l'erreur de rajouter des bugs dans le code, alors qu'on sait tous qu'il faut éviter. On voit bien le retard technologique de la France et les raisons profondes de son manque de compétitivité.

          • [^] # Re: En même temps..

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

            En faisant deux paquets? myapp-stable et myapp-bleeding-edge?

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

            • [^] # Re: En même temps..

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

              Et ça ne va pas du tout causer une explosion combinatoire sur l'interaction entre les paquets. La façon de s'en sortir, c'est de faire comme gentoo, une distro source. Sauf que ça rajoute d'autres contraintes et d'autres problèmes.

          • [^] # Re: En même temps..

            Posté par  . Évalué à 2.

            Surement car je ne parlais pas de branche testing, je parlais simplement mon ressenti d'utilisateur de la branche dite "stable" et que j'ai juste l'impression d’être "tombé" en "testing" sans l'avoir demandé.

            • [^] # Ça pourrait être pire…

              Posté par  . Évalué à 3.

              Au moins les bugs finissent par être corrigés sans qu’on ait à réinstaller une nouvelle version, pas comme sur Fedora (remarquez « Status: CLOSED NEXTRELEASE »).

              La Fedora 17 est la pire Fedora que j’aie vue (je l’utilise depuis la 6, mais j’ai sauté la 16) : si on a le malheur d’activer un service qui ne l’est pas par défaut, au mieux, on se retrouve avec une temporisation à l’arrêt du système, au pire avec un fonctionnement aléatoire.

              C’est la preuve que systemd n’était absolument pas prêt, surtout pour une distribution pas en rolling release. Accessoirement, la Fedora 17 l’embarque en version 44 ; les développeurs d’Arch n’ont pas été assez fous pour mettre systemd par défaut avant la version 194.

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

    • [^] # Re: En même temps..

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

      Regarde l'orthographe. Il a écrit bêtas testeurs, pas bêta-testeurs. Ça change tout.

Suivre le flux des commentaires

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