Journal Petites brèves en vrac

Posté par  (Mastodon) . Licence CC By‑SA.
Étiquettes :
13
24
avr.
2020

Dans cette série de petites brèves, quelques liens vers des ressources en lien avec de récentes intervention sur LinuxFR. De quoi nourrir un troll ou votre réflexion (selon votre envie).

Apprendre à aimer systemd

J’adore le titre de cet article présent sur opensource.com. Derrière ce titre, une contribution assez longue sur systemd, systemV et pas mal de réflexions. Ne vous attendez pas à une position dogmatique. L’auteur vous comprendra très bien si vous n’aimez pas systemd, il aime aussi beaucoup systemV. Évidemment, spéciale dédicace à totof2000 :-).

Un Captcha libre, c’est possible

Cette vidéo trouvée sur PyVideo (merci à jihele de nous avoir fait passé l’info) intéressera évidemment les nombreux contributeurs en sens divers et opposés dans le fil de conversation suite au journal Cloudflare abandonne le reCAPTCHA de Google

Des bloqueurs de pub économes en énergie

Moi, j’avais toujours cru que je n’utilisais des bloqueurs de pub que pour mon confort personnel mais en fait, je sauve la planète (oui, oui, il y a sans doute là une exagération poétique ou autre). Cette étude s’est intéressée à trois bloqueurs de pub libres (les bloqueurs pas forcément les pubs qui sont libres) sous l’angle de la réduction de consommation d’énergie. Et au final, cela ne semble pas si négligeable. Bon, les esprits chagrins me rappelleront rapidement et à raison l’effet rebond. Bande de tristes sires !

Sinon, vous ne voyez pas de lien avec une actualité récente sur LinuxFR ? Mais si, c’est un article très cohérent (c’est important la cohérence): une étude sur des logiciels libres sous licence libre. Une licence libre pour vrai de vrai, Zenitram proof. Ceci me fait penser aux discussions qui ont suivi ce journal-là.

  • # Effet rebond et pub

    Posté par  . Évalué à 5.

    Souvent l’effet attendu pas rebond de la pub c’est de [t’envoyer sur d’autres sites qui vont te donner envie de consommer tout en chargeant d’autres pubs qui vont]*

    Donc je sais pas à quel genre d’effet rebond on peut s’attendre, mais là en tout cas ça ressemble plus à une mesure de distanciation sociale ou de confinement :)

    [évidemment, pour respecter une certaine tradition, j’ai répondu avant de lire les liens ou même de terminer le journal]

    • [^] # Re: Effet rebond et pub

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

      Ici, les tristes sires diraient (et ils auraient sans doute raison, au moins en partie) que

      1) Si disons qu'un bloqueur de pub te permet de réduire de 20% la consommation d'énergie sans doute qu'au final la réduction de consommation d'énergie sera bien plus faible voire négative.
      2) Premier point, réduire la consommation d'énergie s'accompagne ici a) d'une réduction du coût (à mon avis négligeable ou en tout cas négligé par la plupart) et b) d'une réduction du temps perdu à attendre que la pub se charge.
      3) Le rapport coût (financier + temps) / satisfaction de la activité de surfer sur ~~les vagues ~~ le net s'améliore => incitation à surfer plus
      4) L'effet précédent peut surpasser la diminution de consommation énergétique initiale. En d'autres mots, le fait que l'on surf plus parce qu'il est plus agréable de surfer peut augmenter plus la consommation énergétique que ce que l'on gagne grâce au bloqueur de pub.

      On pourrait arriver à une conclusion proche si on pense que le budget-temps pour internet est en fait une constante. C'est à dire que le temps passé sur internet est indépendant de l'intérêt ou du coût de surfer mais est déterminé de manière exogène (24h - temps pour dormir - temps pour manger - …). Dans ce cas-là, le bloqueur de pub n'a pratiquement pas d'effet sur la consommation énergétique.

      Après avoir poster ceci, je vais lire ton commentaire pour voir si j'y réponds :-)

      Surtout, ne pas tout prendre au sérieux !

  • # Captcha libre > ubuntu.com

    Posté par  . Évalué à 2.

    Il serait bon que ça se diffuse dans le domaine du libre, quand je vois que le site d'Ubuntu fait aussi appel à reCaptcha : https://ubuntu.com/blog/ubuntu-20-04-lts-arrives

    aussi sur le salon xmpp:linuxfr@chat.jabberfr.org?join

  • # « Apprendre à aimer systemd »

    Posté par  . Évalué à 6.

    Laisse moi deviner, encore un coup du Dr Folamour ?

  • # Commentaire supprimé

    Posté par  . Évalué à 5.

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

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 5. Dernière modification le 25 avril 2020 à 10:43.

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

      • [^] # Re: LibreCaptcha

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

        Des nouvelles de l'auteur ?

        Je me demandais si une manière simple ne serait pas de demander de reconnaître la ou les vignettes tirées de l'image. Cela fait (si je ne me suis pas trompé) \sum_{i=1}^9 [9!/((9-i)!i!)]=511 réponses possibles, donc moins de 0.2% de réussite pour un bot basique.

        Des variantes sont possibles, trouvez une à trois vignettes parmi les 16 proposées (696 réponses possibles).

        Surtout, ne pas tout prendre au sérieux !

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 2.

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

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 3.

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

          • [^] # Re: LibreCaptcha

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

            Merci pour le retour !

            Cela va dans le sens de ce que l'on imaginait, non ?

            Surtout, ne pas tout prendre au sérieux !

  • # Merci pour la dédicace ... :)

    Posté par  . Évalué à 5.

    L’auteur vous comprendra très bien si vous n’aimez pas systemd, il aime aussi beaucoup systemV. Évidemment, spéciale dédicace à totof2000 :-).

    C'est vraiment un billet très intéressant. Il ne me fera pas aimer mieux systemd, mais c'est peut être l'article le plus complet ue j'ai vu sur le sujet, avec explications et schémas à l'appui.

    En fait, une phrase résume bien la raison pour laquelle je n'aime pas systemd : "A full exposition of systemd would take a book on its own." alors que les systèmes d'init plus classiques n'ont besoin que d'un chapitre dans un bouquin d'admin système, et de connaitre un peu le scripting shell pour être compris.

    • [^] # Re: Merci pour la dédicace ... :)

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

      En fait, une phrase résume bien la raison pour laquelle je n'aime pas systemd : "A full exposition of systemd would take a book on its own." alors que les systèmes d'init plus classiques n'ont besoin que d'un chapitre dans un bouquin d'admin système, et de connaitre un peu le scripting shell pour être compris.

      Je pense que la véritable erreur est là. systemd n'est pas juste un système d'init, c'est une collection de services bas niveau dont gestionnaire d'init mais aussi de session, etc. Donc il est normal qu'il soit plus complexe et complet, l'ensemble des parties de systemd est bien plus vaste que init.

      En plus systemd a de nombreux comportements qui sont fournis d'entrée de jeux. Il suffit de configurer le service pour exploiter le comportement qu'on veut. init de SysV est vraiment rudimentaire, la complexité est en fait dans le script shell du service et tu dois tout faire à la main. Donc oui systemd est complexe à côté, mais la complexité est cachée à l'utilisateur et assumé de manière commune à tous les services.

      Et systemd peut prendre en charge de manière uniforme tous les services, configurer SELinux, le redémarrage en cas de crash de l'application, etc. Avec init chaque service le fait à sa sauce, parfois ne le gère pas, parfois de manière différente d'un autre, etc. Bref, ce n'est pas parfait non plus…

      Il faut comparer ce qui est comparable, systemd n'est pas qu'un système d'init et au niveau fonctionnel systemd gère la complexité lui même et ne la reporte pas sur le shell et les scripts de démarrages de chaque service.

      • [^] # Re: Merci pour la dédicace ... :)

        Posté par  . Évalué à 6.

        Je pense que la véritable erreur est là. systemd n'est pas juste un système d'init, c'est une collection de services bas niveau dont gestionnaire d'init mais aussi de session, etc. Donc il est normal qu'il soit plus complexe et complet, l'ensemble des parties de systemd est bien plus vaste que init.

        Une erreur de quoi ? Il ne s'agit pas d'une erreur, je sais très bien que systemd est plus qu'un système d'init et c'est bien ça que je lui reproche.

        En plus systemd a de nombreux comportements qui sont fournis d'entrée de jeux.

        Comportements qui posent problème lorsque tu n'es pas dans les cvlous. Systemd oblige ton besoin à s'adapter à l'outil, plutôt que de s'effacer et de laisser l'admin faire ce qu'il a a faire.

        Il suffit de configurer le service pour exploiter le comportement qu'on veut.

        Encore faut-il que le comortement en question soit implémenté dans systemd.

        init de SysV est vraiment rudimentaire, la complexité est en fait dans le script shell du service et tu dois tout faire à la main.

        Sur la plupart des OS qui implémentent le même type d'approche, la plupart du temps, tu as tout ce qu'il faut pour configurer un service proprement. Et dès que tu as un besoin qui sort de ce qui t'es proposé" tu peux implémenter le comportement que tu veux. Rien n'oblige de le faire en shell, tu peux le faire avec du python, du ruby, lua, ou n'importe quoi d'autre.

        Donc oui systemd est complexe à côté, mais la complexité est cachée à l'utilisateur et assumé de manière commune à tous les services.

        J'aime pas les trucs qui me cachent des choses. D'ailleurs l'une des raispons qui ml'ont fait préférer Unix à Linux il y a longtemps, c'est justement cette simplicité et souplesse du système de démarrage.

        Et systemd peut prendre en charge de manière uniforme tous les services,

        Si tous les services devaient être démarrés de la même façon …. là encore il t'empêche de faire ce que tu veux. Dans 90% des cas ça va marcher, mais quand tu te trouves dans les 10% de cas qui ne rentrent pas dans les clous ça sera une grosse galère.

        Avec init chaque service le fait à sa sauce, parfois ne le gère pas, parfois de manière différente d'un autre, etc. Bref, ce n'est pas parfait non plus…

        Oui enfin, quand un service fait les choses différemment des autres c'est bien souvent parce qu'il a besoin de faire les choses différemment.

        • [^] # Re: Merci pour la dédicace ... :)

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

          Une erreur de quoi ? Il ne s'agit pas d'une erreur, je sais très bien que systemd est plus qu'un système d'init et c'est bien ça que je lui reproche.

          Ta comparaison repose sur l'aspect init, ce n'est pas correcte de focaliser son attention dessus alors qu'il propose plus.

          Comportements qui posent problème lorsque tu n'es pas dans les cvlous. Systemd oblige ton besoin à s'adapter à l'outil, plutôt que de s'effacer et de laisser l'admin faire ce qu'il a a faire.

          Sur la plupart des OS qui implémentent le même type d'approche, la plupart du temps, tu as tout ce qu'il faut pour configurer un service proprement. Et dès que tu as un besoin qui sort de ce qui t'es proposé" tu peux implémenter le comportement que tu veux. Rien n'oblige de le faire en shell, tu peux le faire avec du python, du ruby, lua, ou n'importe quoi d'autre.

          Oui, c'est vrai qu'il y a 25000 façons de redémarrer un service qui a échoué, de configurer les droits SELinux et compagnie… Avec init tu dois toujours te le farcir toi même. Pourtant c'est un besoin de base.

          Et comme systemd permet d'appeler un shell ou ce que tu veux, par effet de bord tu peux faire ce que tu veux si le comportement de systemd ne te plaît pas. Il y a d'ailleurs de quoi exécuter des scripts init classiques avec systemd. Donc en gros : tu peux faire comme avant si tu y tiens.

          J'aime pas les trucs qui me cachent des choses.

          Rien n'est caché, le code de systemd est dispo si tu y tiens.
          Personnellement en lisant une unité systemd j'ai en quelques secondes les propriétés essentielles du service. Et je peux en déduire son comportement quelque soit le service.

          Si c'est un script init à l'ancienne, pour peu qu'il ne soit pas trivial il te faudra bien plus de temps pour en retirer les mêmes informations. Et comme aucun script init n'est rédigé de la même façon contrairement à une unité systemd, prédire le comportement demande de réévaluer le script systématiquement.

          Oui enfin, quand un service fait les choses différemment des autres c'est bien souvent parce qu'il a besoin de faire les choses différemment.

          Non, c'est juste que pas tout le monde pense à couvrir tous les besoins. Normal, ce n'est pas simple à anticiper. Même quand tu es le développeur de l'application ou le mainteneur dans une distribution.

          Pas tout le monde pense à gérer le cas d'un service qui plante et qui doit redémarrer automatiquement, pas tout le monde pense à ajouter des règles SELinux, pas tout le monde pense à bien gérer les dépendances du service comme s'assurer que le réseau soit opérationnel avant, etc.

          Si le mainteneur n'a pas fait son boulot correctement (indice, ça arrivait souvent) tu devais te démerder et c'était chiant. Ici cela se règle très simplement.

          Je travaille en embarqué par exemple, contrôler ce qui se passe j'aime bien aussi. Mais sur chaque projet où c'était de l'init classique, je devais régler les mêmes problèmes à la con, réinventer la roue 20 fois, etc. systemd gère tous ces problèmes d'entrée de jeu, écrire une unité systemd qui fait ce que tu veux est très simple. Je n'ai littéralement jamais eu de soucis avec, c'est un confort incroyable.

          Donc oui, avec l'init tu as plus de contrôle direct, oui, car toute la difficulté repose sur le dos de l'administrateur. Ce n'est selon moi pas la bonne approche. Si l'admin veut reprendre le contrôle avec systemd, il le peut de toute façon en cas de besoin.

      • [^] # Re: Merci pour la dédicace ... :)

        Posté par  . Évalué à 4.

        AMHA le point le plus essentiel c'est pas une question d'init uniquement ou pas. C'est des approches différentes.

        Quand tu conçois un système tu peux avoir 2 approches différentes (c'est une dichotomie il y en a d'autres) :

        • la méthode sysv : tu est simple et basique et tu expose la complexité à tes utilisateurs
        • la méthode systemd : tu prend pour toi la complexité, les utilisateurs ne l'ont pas

        Tu retrouve ce découpage dans pleins de choses : pour le web en python les micro framework face à django par exemple. Les outils de builds à la maven face à make ou ant.

        Ces dernière années on a tendance à décrire les simples comme non-opiniated et les autres comme opiniated. On parle aussi du principe de convention over configuration pour les second.

        Comprendre cette différence c'est à mon avis important pour comprendre la démarche à adopter face à chacun d'eux.

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: Merci pour la dédicace ... :)

      Posté par  . Évalué à 4.

      et de connaitre un peu le scripting shell pour être compris.

      C’est quand la dernière fois que tu as géré les cgroups, les capabilities, la reprise sur erreur avec « back-off », la création de fichiers/dossiers temporaires, la dépendance entre services et point de montages, etc. avec « un peu de scripting shell » ?

Suivre le flux des commentaires

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