Archlinux utilise désormais systemd par défaut pour les nouvelles installations

Posté par  . Édité par Davy Defaud, Benoît Sibaud, baud123, Nÿco et B16F4RV4RD1N. Modéré par j. Licence CC By‑SA.
42
14
oct.
2012
Arch Linux

Les bénévoles qui maintiennent Archlinux ont choisi d’utiliser systemd par défaut pour les nouvelles installations. systemd remplacera le vénérable système d’initialisation SysVinit et gérera les processus.

Pour l’instant, cette décision ne concerne que les nouvelles installations d’Archlinux. Mais elle devrait vraisemblablement se généraliser à tous. L’annonce officielle précise d’ailleurs que :

Pour le moment, les paquets initscripts et sysvinit, [qui sont remplacés par systemd], restent disponibles depuis nos dépôts.

En effet, les développeurs ne souhaitent pas maintenir plusieurs systèmes d’initialisation, et la migration d’Archlinux vers systemd est planifiée de longue date.

Sommaire

Quelques considérations

Cette décision (qui a enthousiasmé Lennart Poettering, l’auteur de systemd) était pressentie depuis plusieurs mois : en premier lieu, udev a été remplacé par systemd-tools. Par la suite, des fichiers de configuration furent modifiés pour être compatibles avec systemd. Enfin, le démon netcfg (chargé du réseau) abandonna la compatibilité avec les scripts d’initialisation de SysVinit.

D'après plusieurs développeurs d'Archlinux, systemd deviendra, tôt ou tard, une brique essentielle à de nombreux logiciels :

You need to move [to systemd] because the rest of the Linux ecosystem will require systemd at some point, just like it now requires udev. [lien]

I expect that third-party packages (GNOME, NetworkManager, polkit, etc.) at some point will stop working well without systemd. [lien]

I don’t use systemd or know how it works or compare to initscripts but I am aware that we’ll need to switch to it eventually as more and more projects will depends on it. So the sooner the better. [lien]

Exactly the same position, +1. [lien]

La décision fut finalement prise : systemd sera installé par défaut sous Archlinux, il gérera l’initialisation du système, ainsi que les processus.

La migration d’Archlinux vers systemd revêt une connotation particulière. Jusqu’à présent, une caractéristique d’Archlinux était un système d’initialisation proche de celui des systèmes BSD : les scripts de démarrage des démons se trouvaient dans le répertoire /etc/rc.d, et le fichier /etc/rc.conf listait les démons qui devaient être lancés au démarrage.

Cette spécificité de la distribution disparaît donc, au profit d’une solution qui se veut plus « générique », et qui allégera la charge de travail des bénévoles qui maintiennent Archlinux.

Que va devenir SysVinit ?

Si la décision de remplacer SysVinit par systemd est approuvée par la quasi‐unanimité des développeurs, c’est loin d’être le cas chez les utilisateurs. En effet, énormément de personnes ont posté sur la liste de discussion arch-general (et aussi sur LinuxFr.org) pour regretter le choix des développeurs.

Malgré cela, SysVinit ne sera vraisemblablement plus maintenu par les développeurs d’Archlinux. Le maintien d’une compatibilité entre les deux systèmes d’initialisation demande un travail conséquent que les développeurs ne feront pas.

Cependant, tout n’est pas perdu pour SysVinit. En effet, si les développeurs principaux ne le maintiennent plus, d’autres peuvent s’en charger. Un appel à volontaire est lancé (et relayé sur LinuxFr.org) pour maintenir SysVinit et proposer une version recompilée des paquets qui nécessitent déjà systemd. Très pragmatiquement, SysVinit sera maintenu… si quelqu’un le maintient.

Les utilisateurs d’Archlinux peuvent facilement proposer et maintenir un paquet en dehors des dépôts officiels grâce à l’Arch User Repository. Il s’agit d’un dépôt communautaire où les utilisateurs proposent des scripts d’installation de logiciels. On peut y proposer des paquets qui ne sont pas officiellement pris en charge par la distribution. Plus d’informations sur l’Arch User Repository : en anglais et en français.

Si le maintien de la compatibilité entre SysVinit et systemd est trop complexe, il est possible de dériver Archlinux pour créer une nouvelle distribution prenant en charge uniquement SysVinit. Souvenons‐nous qu’un fork de FreeBSD (DragonFly BSD) est né car certains choix techniques des développeurs FreeBSD étaient contestés. C’était en 2003 ; neuf années plus tard, ce fork est toujours là.

La distribution Archbang, qui utilise comme base Archlinux, a d’ailleurs clairement manifesté sa volonté de « forker » dans le cas où Archlinux ne laisserait plus le choix du système d’initialisation à ses utilisateurs, ce qui se traduirait avant tout par une « contamination » (sic) d’Archlinux par GNU/Lennax.

Pourquoi passer à systemd ?

Tom Gundersen, l’un des développeurs d’Archlinux, détaille les raisons du passage à systemd dans ce message.

Remarque : ce long message est en anglais. Vous pouvez proposer une traduction dans les commentaires. En attendant, en voici un résumé :

Les lacunes a priori de systemd semblaient être de ne pas être en bash, d’être dû à Lennart Poettering, ainsi que son format de journal, son utilisation de dbus, son PID 1 élevé et d’avoir peut‐être un concurrent meilleur. Finalement, il pense que ces lacunes sont en fait des avantages, et, par ailleurs, qu’elles n’en sont pas de si importantes.

Les distributions utilisant systemd

Pour finir, voici une liste des distributions utilisant systemd, au 14 octobre 2012 :

À l’heure actuelle, Debian, Ubuntu, Gentoo et Slackware n’utilisent pas systemd par défaut. L’utilisation de systemd par Debian semble improbable pour l’instant.

En conclusion

Et encore une distribution qui utilisera systemd par défaut ! L’enfant terrible du diabolique Lennart Poettering gagne du terrain. systemd deviendra‐t‐il une brique essentielle à de nombreux logiciels ? Les développeurs de logiciels feront‐ils toujours l’effort de programmer pour des systèmes d’exploitation n’utilisant pas systemd ? Quelle compatibilité pour les systèmes d’exploitation non‐Linux ?

L’avenir nous le dira. D’ici là, vous pouvez contribuer à Archlinux, en écrivant des articles sur les wikis (anglais ou français), en effectuant des rapports de bogues ou bien en donnant de l’argent !

Aller plus loin

  • # Debian et systemd

    Posté par  . Évalué à 8.

    L'utilisation de systemd par Debian semble improbable pour l'instant.

    Cette affirmation est basée sur un article qui date de presque deux ans. De l'eau a peut-être coulé sous les ponts depuis ?

    • [^] # Re: Debian et systemd

      Posté par  . Évalué à 1.

      A vérifier avec wheezy ou sid.

      Merci aux personnes qui mon aidé a trouvé des solutions pour essayer d’écrire sans faute d’orthographe.

    • [^] # Re: Debian et systemd

      Posté par  . Évalué à -2.

      Vu que le poulain de Debian (Ubuntu) est à fond sur upstart et qu'il semblerait qu'ils n'ont nullement l'intention de considérer systemd (http://www.markshuttleworth.com/archives/1121) je doute vraiment que cela arrive (à court terme en tout cas).

      • [^] # Re: Debian et systemd

        Posté par  . Évalué à 8.

        C'est ubuntu qui est basé sur debian, pas l'inverse…

        Please do not feed the trolls

        • [^] # Re: Debian et systemd

          Posté par  . Évalué à -2. Dernière modification le 14 octobre 2012 à 18:55.

          Oui merci je suis d'accord avec ceci.

          Mais justement si Debian passait à systemd cela signifierait plus (+) de boulot pour les devs ubuntu pour se passer du tentaculaire systemd et mettre leur solution maison à la place en plus du discrédit de celle-ci (la distro mère préfère utiliser une solution concurrente plutôt que celle de sa fille).

          Donc je vois plutôt des conséquences "politiques" sur la distribution mère en gros.
          Sachant l'immense popularité d'Ubuntu et le fait qu'ils en profitent indirectement, ils pourraient avoir des réticences vis à vis de systemd à cause des choix de cette dernière.

          • [^] # Re: Debian et systemd

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

            Aujourd'hui debian n'utilise pas upstart, c'est déjà un boulot tentaculaire. Je ne vois pas bien ce que changerait le passage à systemd. Il faut réécrire les scripts de démarrage.

            Le fichier init de upstart n'ont strictement rien à avoir avec les scripts d'init actuels de debian.

            J'ai du mal a comprendre où tu veux en venir avec ton commentaire.

          • [^] # Re: Debian et systemd

            Posté par  . Évalué à 3.

            Debian ne rend aucun compte à Ubuntu.
            Il y certes des contributeurs communs aux deux distributions, mais Ubuntu en tant qu'entité n'est pas vraiment réputée pour être un gros contributeur de Debian.
            A partir de là, ce que veut Ubuntu, je crois que ça n'entre pas dans les paramètres de prise de décision.

            Si on suit les discussions, Debian pourrait bien migrer à systemd, avec en parallèle un script de conversion systemd vers les anciens scripts init en bash. Ça permettrait de faire cohabiter les 2 solutions sans charge supplémentaire à quelques exceptions près (les paquets qui ont des besoins non triviaux).

            Ceci dit, Debian a une variante sur noyau FreeBSD, et je doute qu'elle s'en sépare de sitôt. Donc si systemd devient trop envahissant, ce sera un problème…

            • [^] # Re: Debian et systemd

              Posté par  . Évalué à 5.

              Ceci dit, Debian a une variante sur noyau FreeBSD […]

              Ainsi qu'hurd et à une époque on parlait de portage vers le noyau NetBSD. Sans chercher à faire rire, Debian cherche depuis longtemps a avoir différent noyaux et avoir des scripts d'init différents pour chacun deviendrais compliqué à maintenir.

              Peut être que la solution serait un openrc qui mange exactement le même format que systemd, comme ça il n'y aurait pas à réécrire les scripts pour chaque noyau ou d'une manière inverse demander à systemd d'exécuter les scripts init classiques (voir des script Openrc).

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

    • [^] # Re: Debian et systemd

      Posté par  . Évalué à 6.

    • [^] # Re: Debian et systemd

      Posté par  . Évalué à 5.

      À mon avis, c'est pas près d'arriver, vu que d'une part Debian ne fournit pas que Linux comme noyau, et que d'autre part systemd n'est pas entièrement compatible avec les script système de Debian.

      Voir par exemple ce bug : Debian a étendu la crypttab avec quelques options bien pratiques (en particulier keyscript qui permet entre autres d'utiliser une clef USB pour déverrouiller des volumes), mais ces options ne sont pas prises en charge par systemd.

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

    • [^] # Re: Debian et systemd

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

      Effectivement, les paquets Systemd sont disponible depuis plus de 6 mois sous debian et l'intégration est repoussée à cause du freeze de wheezy, mais c'est une question de temps plus que d'improbabilité !

      J'ai d'ailleurs un serveur expérimental debian (en VM) qui utilise Systemd sans problème majeur…

      Ubuntu, c'est une autre histoire, ils ont investi beaucoup dans upstart, leur système de démarrage et pour l'instant semblent s'y accrocher… Cependant, AMHA, devant l'adoption massive des distributions, il semblerait logique qu'ils infléchissent leur décision d'ici une version ou 2… Rien n'est jamais figé dans Ubuntu !

      • [^] # Re: Debian et systemd

        Posté par  . Évalué à 2.

        Effectivement, les paquets Systemd sont disponible depuis plus de 6 mois sous debian et l'intégration est repoussée à cause du freeze de wheezy, mais c'est une question de temps plus que d'improbabilité !

        La disponibilité du paquet n'indique rien :

         % apt-cache policy upstart minit
        upstart:
          Installé : (aucun)
          Candidat : 0.6.6-1
         Table de version :
             0.6.6-1 0
                500 http://ftp.fr.debian.org/debian/ squeeze/main amd64 Packages
        minit:
          Installé : (aucun)
          Candidat : 0.10-5
         Table de version :
             0.10-5 0
                500 http://ftp.fr.debian.org/debian/ squeeze/main amd64 Packages
        
        

        Et je suis sur stable.

        Si tu as un lien d'un mainteneur ou un développeur sur le sujet ça m'intéresse.

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

        • [^] # Re: Debian et systemd

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

          Si tu as un lien d'un mainteneur ou un développeur sur le sujet ça m'intéresse.

          systemd n'a pas été rejeté et je pense qu'une fois la prochaine stable sortie, le débat reprendra… Donc pour l'instant, difficile de se prononcer pour Debian…

          Pour SlackWare, Pat a dit: "je l'adopterai quand il aura fait ses preuves"

  • # Un mal nécessaire ?

    Posté par  . Évalué à 10.

    Cela fait une bonne année que je l'utilise et j'ai jamais eu aucun soucis.
    La gestion des services et de leurs dépendances est enfantine, le démarrage est plus que rapide, la gestion des ressources est vraiment optimisée (services à la demande) etc…..
    Techniquement (en tout cas pour moi) systemd n'a aucun égal dans le monde GNU/Linux et sysvinit paraît vraiment archaïque à côté…

    …Cependant, c'est compréhensible que la tendance tentaculaire et poussive de systemd risque de provoquer pas mal de remous et certains choix (logs binaires) sont pas du goût de tout le monde (bien qu'il est tout à fait possible d'utiliser un logger traditionnel). La transition aurait pû être plus douce et moins invasive pour les autres distributions qui ne sont pas forcément intéressées pour le moment, mais le fait est que systemd tisse de plus en plus de liens qui font qu'il deviendra quasi inévitable pour tous. Un récent exemple étant le merge d'udev dans systemd, et bien que je sois vraiment satisfait de systemd je n'aime pas ça non plus car on devrait toujours avoir le choix sur GNU/Linux…

    Mais bon certains diraient que c'est un mal nécessaire car il est vrai que sysvinit a fait son temps et que la nostalgie n'a pas souvent que du bon pour l'évolution…

    • [^] # Re: Un mal nécessaire ?

      Posté par  . Évalué à 0.

      Je suis d'accord, j'ai migré sous full systemd sur archlinux et j'en suis très content, ça démarre bcp plus vite !

    • [^] # Re: Un mal nécessaire ?

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

      Plus que le choix, c'est avant tout l'entremêlement de couches qui n'ont a priori rien à voir les unes avec les autres qui m'inquiètent. Quand on lit que GNOME pourra dépendre d'un init particulier, on croit rêver… Oser prononcer ce genre de phrases quelques années en arrière relevait de la folie pure.

      Moi j'attends la première alerte de sécurité dans systemd pour refroidir un peu tout le monde.

      • [^] # Re: Un mal nécessaire ?

        Posté par  . Évalué à 1.

        Quand on lit que GNOME pourra dépendre d'un init particulier, on croit rêver…

        Déjà, c'est faux, c'est même complétement faux. Il dépend d'une API. Maintenant, au lieu de lancer un troll dans le vents, que donne ton argument si tu prends la peine de le justifier ? Je ne dis pas qu'il est mauvais, mais qu'en l'état de ta formulation, il est un peu faible.

        Parce que, je peux l'appliquer à autre chose :

        quand on voit des applications unix qui dépendent de l'API POSIX, on droit rêver ! Ah non. On rêve pas.

        Du coup, je serais heureux de savoir ce qui te pose réelement problème là dedans.

        • [^] # Re: Un mal nécessaire ?

          Posté par  . Évalué à 3.

          Personnellement, ce qui me gêne est de lire que de plus en plus de choses vont dépendre de systemd. Ca me décoit assez, j'ai toujours pensé que sous GNU/Linux on serait libre de choisir les briques qu'on veut, et qu'on pourrait les changer indépendamment du reste.

          Emacs le fait depuis 30 ans.

          • [^] # Re: Un mal nécessaire ?

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

            j'ai toujours pensé que sous GNU/Linux on serait libre de choisir les briques qu'on veut

            Justement, ce qu'il te dit, c'est que GNOME dépend d'un bout d'API et pas d'un logiciel en particulier. Aujourd'hui, cette API en question n'a qu'une seule implémentation, systemd, mais qui en plus de faire ce que GNOME veut fait plusieurs autres choses. Si quelqu'un est pas content et veut séparer les choses (ce qui est une bonne idée), il n'a qu'à implémenter juste ce dont GNOME a besoin.

            YAKAFOKON, au final, même si en pratique je n'ai aucune idée de la difficulté d'implémentation.

            • [^] # Re: Un mal nécessaire ?

              Posté par  . Évalué à 6.

              Ubuntu a implémenté cette API pour upstart.

              « 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: Un mal nécessaire ?

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

      Pareil, ça fait un moment que je suis passé à systemd, et ça fonctionne pas mal du tout.

      Bon, j'avoue que j'ai un peu tiqué quand une mise à jour a introduit journald et qu'il a fallu faire une manip' pour le faire fonctionner avec syslog-ng.

      De la même manière, récemment systemd s'est mis à implémenter les fonctions d'acpid, et je fus étonner de voir mon système suspendre en ram que je fermais l'écran du laptop. Mais là aussi, ça se paramètre.

      Le gros boulot va être de convertir tous les script sysvinit vers systemd. Mais du coup, ça va remonter upstream et profiter à tout le monde.

      • [^] # Re: Un mal nécessaire ?

        Posté par  . Évalué à 0.

        Sa gestion des fonctions de l'acpid n'est pas au point. Les distrib qui utilisent systemd le fond surchauffer. C'est bête non ?
        J'ai installé au départ archlinux (il y a 15 jours), en full systemd. Paf surchauffe du coco.
        J'ai testé toutes les distrib récentes, y compris celles que je n'aime pas : même résultât.
        J'ai testé une ubuntu (que je n'aime pas non plus, mais ma pile wifi fait planter le noyau debian) : pas de pb. Comme j'avais absolument besoin d'une machine fonctionnelle je suis resté comme ça, mais non systemd n'est pas forcément finis.
        C'est peut-être surtout ça le problème. Ce programme n'est simplement pas finis. Les tests de debugage en grandeur réel ça doit aider red-hat, pas les autres distribs !

        PS : le portable est un acer, plus jamais j'en achèterai un !

        • [^] # Re: Un mal nécessaire ?

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

          Mais de quoi tu parles, systemd s'occupe juste de gérer les évènements ACPI, si ca chauffe, c'est surement plus un problème de noyal…

          • [^] # Re: Un mal nécessaire ?

            Posté par  . Évalué à 0.

            tant qu'il y est, systemd, ca serait bien qu'il passe un coup de balai dans le salon, c'est degueulasse

            et si il pouvait faire les vitres et la vaisselle, ca serait sympa

            • [^] # Re: Un mal nécessaire ?

              Posté par  . Évalué à 2.

              Ah, et faut qu'il aille directement chez Zézette parce que j'ai paumé les clefs du camion.

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

            • [^] # Re: Un mal nécessaire ?

              Posté par  . Évalué à 1.

              Moi j'ai essayé d'utiliser systemd pour qu'il enlève les bugs sur OpenOffice, et ben il le fait pas non plus!

              Vraiment pas finie cette bouse! Mon pare-feu est fichu maintenant!!

      • [^] # Gros boulot

        Posté par  . Évalué à 2.

        Le gros boulot va être de convertir tous les script sysvinit vers systemd. Mais du coup, ça va remonter upstream et profiter à tout le monde.

        C’est déjà fait pour beaucoup et ça, ça peut n’être fait qu’une seule fois pour toutes les distributions.

        Le gros boulot, ça va être pour chaque utilisateur qui avait paramétré son système finement de reparamétrer tous les services qui viennent avec systemd et qui ont remplacé des services classiques, et il y en a de plus en plus.

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

      • [^] # Re: Un mal nécessaire ?

        Posté par  . Évalué à 3.

        Question : il existe quoi comme outil avec une GUI (en mode texte ou non) pour configurer _systemd_ ? Du style ntsysv, sysvconfig ou encore sysv-rc-conf ?

        J'en avais trouvé un seul avec ma Fedora 17, mais il plantait misérablement au premier bouton cliqué.

        • [^] # Re: Un mal nécessaire ?

          Posté par  . Évalué à 3.

          GUI (en mode texte ou non)

          Donc tu voulais dire UI :)

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

          • [^] # Re: Un mal nécessaire ?

            Posté par  . Évalué à 9.

            Pas exactement, car une CLI est une UI, et c'est exactement ce que je ne veux pas ! Mais effectivement, le terme de GUI ne convient pas vraiment et celui de GUI-like (pardon, de simili-IUG) serait plus approprié car il inclut les TUI.

            Tout le monde SUI ?

  • # Parallèle avec dragonfly

    Posté par  . Évalué à 10.

    Je trouve le paralèle avec dragonfly un peu gros. Ici, on parle d'un système d'init, qui ne change pas grand chose en réalité. C'est un peu comme si on disait qu'il fallait forker ubuntu avec chromium proposé par défaut. Les différences entre DragonFly et FreeBSD vont largement au delà du choix d'un logiciel, fut il aussi aussi basique qu'init. Toutefois, je suis d'accord avec l'idée véhiculée.

    D'une manière générale, je trouve que la dramatisation de cette histoire est un peu ridicule, et le fanatisme de certains me fait un peu peur. Je trouve que l'ambiance de la communauté est devenue assez malsaine ces derniers temps à cause de fanatiques professant leurs haine à l'encontre des devs (ou pour les devs, ça vaut pour les deux camps), dégradant le climat sain dans lequel un projet open source peut prospérer.

    La haine à l'encontre de projets comme Gnome ou systemd est à mon sens sans objet. Un utilisateur pur n'a aucun droit. Être en désaccord avec un choix technique est un fait, mais l'action est la seule réponse valable. Monopoliser le temps de tout le monde dans des débats stériles ne bénéfie à personne, et freine l'évolution des projets libres.

    Pour moi, un utilisateur n'a aucun droit, et encore moins le droit de faire chier le monde en râlant sans cesse. Quand des devs bénévoles s'investissent dans un projet libre, ils font ce qui leur semble bon, et qui plus est, ce qui leur plait. Si un utilisateur n'est pas d'accord, il peut certe exprimer son opinion dans la mesure ou elle apporte quelque chose de NOUVEAU au débat, car c'est dans la communauté que se construit un projet. Mais il doit le faire constructivement. Et les débats passionés qu'on peut voir actuellement sont tout sauf constructifs. Dans le monde de l'opensource, rien n'est du aux utilisateurs, et tout est à construire, tout se gagne. Ensemble.

    This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

    Un utilisateur n'aime pas systemd ? Soit. Et bien, qu'il n'utilise plus Arch, ou qu'il code une autre solution. Mais on n'a pas besoin de le savoir, jours après jours, de manière de plus en plus violente. Mais assez de débats stériles avec des arguments bancals, assez de flamewars inutiles, tout cela est malsain.

    • [^] # Re: Parallèle avec dragonfly

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

      Pour moi, un utilisateur n'a aucun droit, et encore moins le droit de faire chier le monde en râlant sans cesse.

      En gros, il a le droit de fermer sa gueule, c'est ça ?

      • [^] # Re: Parallèle avec dragonfly

        Posté par  . Évalué à 4.

        Ou de devenir contributeur, au choix.

        • [^] # Re: Parallèle avec dragonfly

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

          Cette réponse serait pertinente si tout utilisateur avait les capacités pour contribuer, ce qui est très loin d'être le cas. Ensuite, il y a ceux qui ont les capacités mais qui font autre chose, qui contribuent autre part. Enfin, il y a ceux qui peuvent contribuer et qu'on envoie chier (genre «non, non, on ne mettra pas de #ifdef dans mon code pour assurer une meilleure portabilité»).

          • [^] # Re: Parallèle avec dragonfly

            Posté par  . Évalué à 3.

            non, non, on ne mettra pas de #ifdef dans mon code pour assurer une meilleure portabilité

            Encore heureux. #ifdef c'est sale. Un programme bien conçu n'utilise pas #ifdef pour assurer la portabilité, mais il sépare le code portable et le code dépendant d'une plateforme dans des fichiers différents, et laisse le système de build choisir quels fichiers compiler.

            Cette réponse serait pertinente si tout utilisateur avait les capacités pour contribuer, ce qui est très loin d'être le cas.

            Pourquoi ? Elle est pertinente quoiqu'il arrive. Tu es en train de me dire qu'un utilisateur qui n'a pas les capacités de contribuer n'a d'autre choix que de fermer sa gueule. Et bien oui, s'il n'a pas de solution à proposer. Un tel utilisateur ferme sa gueule, ou alors il peut payer quelqu'un pour coder ce dont il a besoin. Kickstarter existe par exemple.

            Je ne vois pas en quoi c'est un problème. Des devs bénévoles ne sont pas là pour répondre aux besoins de tout le monde. Ils écrivent du code pour répondre à un besoin particulier et le distribuent pour que des gens qui ont le même besoin qu'eux puissent en profiter. C'est déjà beaucoup. Tu ne peux pas leur demander de combler tout les besoins de tout le monde sur terre.

            Si le besoin qu'ils comblent ne correspond pas au tient, bah soit tu contribues/modifies, soit tu trouves una utre logiciel qui correspond mieux à tes besoins, soit tu payes quelqu'un/convaint quelqu'un de dev quelque chose pour tes besoins.

            Mais c'est pas en trollant sans cesse que les gens vont convaincre les devs de faire ce que eux ils veulent et non ce que les devs veulent eux même.

            • [^] # Re: Parallèle avec dragonfly

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

              Encore heureux. #ifdef c'est sale. Un programme bien conçu n'utilise pas #ifdef pour assurer la portabilité, mais il sépare le code portable et le code dépendant d'une plateforme dans des fichiers différents, et laisse le système de build choisir quels fichiers compiler.

              Tu devrais en parler à Lennart, il n'est pas au courant.

              Tu es en train de me dire qu'un utilisateur qui n'a pas les capacités de contribuer n'a d'autre choix que de fermer sa gueule.

              Non, ça c'est toi qui le dit. Moi, j'ai posé la question.

              Des devs bénévoles

              C'est tout à fait ça, Lennart c'est un brave bénévole, il vit d'amour et d'eau fraîche.

              • [^] # Re: Parallèle avec dragonfly

                Posté par  . Évalué à 4.

                Tu devrais en parler à Lennart, il n'est pas au courant.
                Lennart a choisi de ne pas écrire du code portable, parce que ça simplifie largement sa base de code. Je ne vois pas en quoi c'est un problème. C'est son parti pris, il fait ce qu'il veut. Si tu trouves que c'est un problème, tu peux forker. Mais perso, je trouve que lennart fait beaucou pour la portabilité.

                Ce qui est important, c'est les interfaces. Aux dernières nouvelles, les BSD n'utilisent pas le même init que GNU. Ni la même libc. Personne ne crie au scandale, du moment qu'il y a des interfaces standards documentées. Et c'est le cas de systemd.
                De toute manière, les systèmes BSD rechigeraient à porter systemd dans leur base, vu que c'est GPL. Donc, ce je ne vois strictement aucun problème de portabilité. De plus, la transition sysvinit → systemd n'a RIEN changé de ce point de vue.

                Non, ça c'est toi qui le dit. Moi, j'ai posé la question.

                oui c'est ce que je dis. Et je ne vois pas en quoi c'est mal.

                C'est tout à fait ça, Lennart c'est un brave bénévole, il vit d'amour et d'eau fraîche.
                systemd est un projet de bénévole oui. Et quoi qu'il arrive, même quand il travaille pour Red Hat, il ne travaille pas pour n'importe quel user, il travaille pour les clients Red Hat. Les utilisateurs clients de Red Hat ont payé pour avoir le droit d'ouvrir leur gueule, pas l'utilisateur lambda.

                • [^] # Re: Parallèle avec dragonfly

                  Posté par  . Évalué à 10.

                  Les utilisateurs clients de Red Hat ont payé pour avoir le droit d'ouvrir leur gueule, pas l'utilisateur lambda.

                  a) La communauté (même ceux qui ne développent pas, qui ne traduisent pas etc.) a toujours le droit d'ouvrir sa gueule du moment qu'elle utilise. Les admins sys sont la raison d'exister de Red Hat.
                  b) Les clients Red Hat (dont je suis bien malgré moi, saloperie de certif Oracle) ouvre suffisament sa gueule pour que Red Hat n'ait pas encore choisi aujourd'hui si oui ou non ils allaient utiliser systemd (). Personellement et en l'état systemd est juste inutilisable pour tout un tas de choses (cf mes nombreux commentaires dans les journaux pour ceux qui ont du temps à perdre). Si Red Hat passe à systemd, et si systemd ne fait pas des progrès majeurs (boot predictible, gestion des templates, prise en compte de l'environnement, gestion des fs chiffrés en dehors des deux pseudo-fs pris en charge actuellement) je ne peux pas passer en 7.0.

                  De toute manière, les systèmes BSD rechigeraient à porter systemd dans leur base, vu que c'est GPL.
                  Ca n'a jamais empêché les *BSD de rajouter des programmes dans les ports. Seulement si on fait le bilan des trucs portés par BSD ces derniers temps :
                  - HAL : mort
                  - DBus : toujours pas de gestion de la sécurité, déborde de plus en plus sur le système alors qu'il est encore bancal au niveau desktop (notamment quand il y a plusieurs opérations en attente)
                  - UDev : en cours de massacre actif pour être rendu compatible systemd, au point que Linus et Greg KH se demandent sérieusement si ils ne vont pas le reprendre dans les outils kernel

                  Donc on fait un bilan rapide et on se dit que systemd (qui est loin d'être fini et complet et qui se veut linux only depuis le début) c'est même pas la peine d'essayer de le porter.

                  • [^] # Re: Parallèle avec dragonfly

                    Posté par  . Évalué à -10.

                    a) La communauté (même ceux qui ne développent pas, qui ne traduisent pas etc.) a toujours le droit d'ouvrir sa gueule du moment qu'elle utilise. Les admins sys sont la raison d'exister de Red Hat

                    Et ça sert à quoi à part faire chier le monde ?

                    • [^] # Re: Parallèle avec dragonfly

                      Posté par  . Évalué à 10.

                      Et ça sert à quoi à part faire chier le monde ?

                      En fait ça fait pas chier le monde. Si un mec soulève un problème que tu n'avais pas vu ou t'aide à comprendre un aspect que tu avais manqué ça peut faire économiser du temps et de l'argent. Ca peut aussi éviter que ton programme soit rejeté par des personnes que tu aimerais avoir de ton coté (par exemple si tu essayes de vendre des OS professionnels et qu'il y a pas mal d'admins systèmes, autant chez tes clients qu'en dehors, qui font la gueule - c'est peut être qu'il faut revoir ta copie).

                      Aussi tout le travail qui est fait par la communauté, n'est plus à faire. Donc tout ce qui est doc/how-to/explications qui se retrouvent sur les blogs ou les sites spécialisés sont une garantie de visibilité et d'acceptation de ta techno. De la même façon si toute personne qui cherche à faire un truc un poil complexe avec ta techno et qui en faisant une recherche sur internet tombe sur des horreurs (soit des pages qui descendent ta techno en flamme, soit des pages qui donnent des méthodes bien gruik avec pleins d'intervention manuelle à faire et aucune garantie que ça survivra à une mise à jour) ben là aussi tu te vides un chargeur dans le pied.

            • [^] # Re: Parallèle avec dragonfly

              Posté par  . Évalué à 10.

              Pourquoi ? Elle est pertinente quoiqu'il arrive. Tu es en train de me dire qu'un utilisateur qui n'a pas les capacités de contribuer n'a d'autre choix que de fermer sa gueule. Et bien oui, s'il n'a pas de solution à proposer.

              Vous savez, il y a d'autres moyens de contribuer à un projet que de pondre du code ou donner : Tester, suggérer (poliment), remonter les bugs, traduire…

              Il ne faut pas oublier que à moins qu'un logiciel soit fait pour une niche, la cible principale de la plupart des logiciels sont ces "simples utilisateurs", donc leur retour d'un point de vue utilisateur doit être quand même primordial pour les développeurs… Ça se saurait si tous les utilisateurs d'ordinateurs au monde étaient des développeurs avertis.

              Je ne vois pas en quoi c'est un problème. Des devs bénévoles ne sont pas là pour répondre aux besoins de tout le monde. Ils écrivent du code pour répondre à un besoin particulier et le distribuent pour que des gens qui ont le même besoin qu'eux puissent en profiter.

              Comme c'est le cas que des utilisateurs prennent le temps de tester des logiciels (sans garantie hein), remontent les bugs et font des suggestions pertinentes afin que ces développeurs améliorent les dits logiciels. En plus de faire connaître ces logiciels à plus de monde (donc plus de retours, de nouveaux contributeurs etc…).
              Je vois pas pourquoi opposer les développeurs et donateurs/sponsors aux utilisateurs vu que les uns dépendent des autres et vice-versa.

              À vous entendre on croirait que tous ces utilisateurs qui codent pas sont forcément des trolls sans vergogne qui en ont rien à foutre des développeurs. Je dis pas que les trolls n'existent pas, mais c'est pas une raison de mettre tout le monde dans le même panier.

              • [^] # Re: Parallèle avec dragonfly

                Posté par  . Évalué à 2. Dernière modification le 14 octobre 2012 à 20:00.

                Ces gens là je ne les classe pas dans des utilisateurs,mais des contributeurs.

                • [^] # Re: Parallèle avec dragonfly

                  Posté par  . Évalué à 8.

                  Faudrait savoir!!

                  Donc en gros, un utilisateur qui teste systemd et/ou une nouvelle version de Gnome, qui rencontre plein de problèmes, qui trouve ça pas pratique, et qui le fait savoir, c'est un Troll qui devrait fermer sa gueule parce qu'il ne contribue pas.

                  Mais un mec qui teste et fait des retours, c'est un contributeur.

                  Y'a un filtre sur les messages suivant ce qui plait aux dévs?

                  -il me demande de changer ça mais moi je veux pas: s'il insiste, c'est un Troll, sinon, c'est un utilisateur qui ferme bien sa gueule comme il faut

                  -il me demande de changer ça, et je veux bien: c'est un contributeur respectable

                  • [^] # Re: Parallèle avec dragonfly

                    Posté par  . Évalué à 2.

                    Y'a un filtre sur les messages suivant ce qui plait aux dévs?

                    Quelqu'un qui teste, qui remonte des bugs et/ou qui poste une critique constructive sur la mailing liste des développeurs est un contributeur.
                    Quelqu'un qui teste et qui balance un « c'est trop nul, les développeurs font des choix pourris à l'encontre des utilisateurs !!!! » sur DLFP1 sont des troll.

                    Il y a 2 grosses de différences entre les 2 approches :

                    • dans le premier cas, il y a une tentative de discussion avec les développeurs ;
                    • dans le premier cas, il y a une volonté d'améliorer les choses plutôt que de considérer qu'il faut tout jeter.

                    1 : par DLFP j'entends n'importe quel canal qui n'est pas dans la liste des moyens de communication décrite sur le site du projet souvent les développeurs ont une mailing list et éventuellement un canal IRC. Facebook, google+, DLFP, clubic ou je ne sais quel forum ce n'est pas un moyen de contacter les développeurs en question. De plus c'est plus diplomate de commencer par un canal spécialisé (et public) avant de commencer à baver sur une solution, disons que ça rend pas les développeurs plus enclins à l'écoute (oui oui ils sont humain et peuvent se braquer si tu commence par les prendre à revers).

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

              • [^] # Re: Parallèle avec dragonfly

                Posté par  . Évalué à 10. Dernière modification le 14 octobre 2012 à 20:05.

                À vous entendre on croirait que tous ces utilisateurs qui codent pas sont forcément des trolls sans vergogne qui en ont rien à foutre des développeurs.

                Des trolls, pas forcément, mais beaucoup prennent clairement le dév pour un larbin qui doit satisfaire leurs besoins, en faisant des remarques désobligeantes du genre "c’est quand même stupide d’avoir fait tel choix", des menaces du genre "pour un logiciel qui se veut une référence, vous devriez quand même faire mieux, sinon je retourne chez Microsoft", des exigences du genre "qu’est-ce que vous foutez, cette fonctionnalité, on la demande depuis si longtemps", des remarques pénibles "ouh, ce bug existe depuis des années, qu’est-ce que vous branlez ?", et les pires, ce sont les entreprises qui râlent "nous, on est sérieux, il y a des régressions, là, soyez sérieux, bordel, c’est inutilisable, là, votre truc".

                • [^] # Re: Parallèle avec dragonfly

                  Posté par  . Évalué à 6.

                  Autant je suis d'accord pour dire que les retours genre "machin c'est de la merde!" ne sont pas constructifs et n'incitent pas non plus à creuser pour trouver l'origine de la colère, autant le topo n'est pas rose non plus du côté des développeurs.

                  Quand on dit "les utilisateurs peuvent contribuer en remontant les bugs, par exemple".
                  Ben oui. Si les utilisateurs remontent les bugs, et que 3ans après, ils sont toujours là, avec 0 réponse, faut bien se dire que ça ne donne pas envie d'en remonter plus. Qui prend qui pour un con, là?
                  Rien que répondre "j'ai bien lu le rapport de bug, mais je n'ai pas le temps de corriger" ou "je ne corrigerai pas parce que …".
                  Au moins ça éviterait de propager l'idée que certains devs prennent leurs utilisateurs pour de la merde.

                  Quand les utilisateurs demandent en masse un changement, et que les dévs répondent "je m'en branle de ce que vous pensez et ce que vous voulez, je fais ce que je veux ; si tu sais pas coder je t'emmerde!", faut pas s'attendre à un grand moment de tendresse en face non plus.

                  Attention, je ne dis pas que c'est l'ambiance générale, même sur les projets les plus critiqués.

                  Mais là j'ai l'impression de lire une charge gratuite sur la masse des utilisateurs qui sont à couteaux tirés contre les braves développeurs innocents et tellement dévoués. Faut arrêter aussi l'image du dév Libre Bisounours contre l'armée des utilisateurs esclavagistes.

                  • [^] # Re: Parallèle avec dragonfly

                    Posté par  . Évalué à 0. Dernière modification le 16 octobre 2012 à 10:40.

                    j'ai l'impression de lire une charge gratuite sur la masse des utilisateurs qui sont à couteaux tirés contre les braves développeurs innocents et tellement dévoués

                    Tu veux dire que les dévs sont coupables de ne pas être assez serviles ? En tout cas, à mes yeux, oui, ils sont ’’innocents’’ sur ce point. Les utilisateurs ont les droits accordés par la licence, et C’EST TOUT. Faire du LL, ce n’est pas être aux ordres. Il faut lire les licences de temps en temps :

                    THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ’’AS IS’’ AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS OR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS AND CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

                    Quant aux dévs, je ne prétends pas qu’ils sont dévoués, je dis justement qu’ils ont parfaitement le droit et raison de ne pas l’être.

                    Si les utilisateurs remontent les bugs, et que 3ans après, ils sont toujours là, avec 0 réponse, faut bien se dire que ça ne donne pas envie d'en remonter plus. Qui prend qui pour un con, là?

                    Le suivi des bugs, c’est extrêmement exigeant en ressources, et sur certains projets les dévs y passeraient tout leur temps s’ils devaient répondre à tout le monde (non, je n’exagère pas). Ça ne veut pas dire qu’on méprise l’utilisateur, ça veut dire qu’on n’a pas le temps. Si on prenait le temps de répondre à tout le monde, on arrêterait de coder.

                    Quand les utilisateurs demandent en masse un changement, et que les dévs répondent "je m'en branle de ce que vous pensez et ce que vous voulez, je fais ce que je veux ; si tu sais pas coder je t'emmerde!", faut pas s'attendre à un grand moment de tendresse en face non plus.

                    Le ton et la manière de répondre sont essentiels, mais même si tu dis poliment que tu n’as pas l’intention de suivre telle demande des utilisateurs, on te crachera quand même à la gueule. Et c’est bien ce qui me fâche : que certains utilisateurs considèrent qu’on leur doit quelque chose.

                    J’estime ne rien devoir à mes utilisateurs. Je n’ai de la reconnaissance que pour les contributeurs qui m’aident.

                    • [^] # Re: Parallèle avec dragonfly

                      Posté par  . Évalué à 6.

                      Je vais prendre volontairement un cas hypothétique et particulier:

                      Un logiciel en version N est massivement utilisé. Des milliers de gens s'en servent, tous les jours.
                      C'est un logiciel qui accueille des contributeurs.
                      Un développeur très brillant s'y intéresse. Il se propose d'aider les développeurs, qui sont moins professionnels et acceptent volontiers l'arrivée de ce "poids lourd" du développement.

                      Le type commence à faire des changements. Les utilisateurs font des remontées: les changements ne vont pas, selon eux, dans le bon sens. En tout cas, ils ne vont pas dans le sens d'une plus grande facilité d'utilisation.
                      "Ah mais je m'en branle! Les utilisateurs ont qu'à coder! Je leur dois rien!"
                      C'est la réponse qu'ils auront du type brillant, qui continuera à faire pleins de changements, qui facilitent la vie des autres développeurs, et agacent de plus en plus les utilisateurs.
                      "Ah mais les utilisateurs, on s'en branle! Ils ne codent pas!"

                      Conclusion: pense ce que tu veux de ta base utilisateur. Mais demande-toi pourquoi, ou pour qui tu codes?
                      -pour répondre à un besoin personnel: c'est tout-à-fait louable, et effectivement personne d'autre que toi ne sait aussi bien ce que tu veux
                      -pour le plaisir: ben fais-toi plaisir! tant mieux!
                      -pour la gloire: auprès de qui? tu comptes l'avoir comment?
                      -pour améliorer un logiciel: comment tu définis l'amélioration? un code propre, un framework super bien foutu, ce sont des outils, pas des accomplissements en soi

                      Curieusement tous les projets ne suscitent pas de fronde de la part de la "communauté" (terme ô combien vague, mais disons que les retours sont inégaux sur les projets). On dira qu'il y a corrélation entre les projets les plus visibles des non-techniciens et la médiocrité de certains retours…

                      Cela dit, l'attitude:
                      "Je sais ce qui est bon pour les utilisateurs et pas vous! Je continue!" c'est incohérent: ou alors dis franchement à la base utilisateur actuelle que tu veux qu'elle dégage! C'est pas la cible.

                      et "ce bug, j'ai pas le temps de le corriger, j'ai des trucs plus importants à faire", c'est presque la même chose, ça dépend qui il affecte et à quel niveau de gravité.

                      Il y a quelques gros projets très populaires qui attirent autant les dévs que les utilisateurs. Ce ne sont pas mes oignons, mais je dirais que si le projet est important, c'est parce qu'il est très utilisé. S'il est très utilisé, c'est que les utilisateurs sont contents. Des utilisateurs qu'on n'écoute pas, ou qu'on n'écoute plus ne participeront plus à rendre le projet populaire.

                      Quand on est dév, on ne peut pas non plus avoir le beurre et l'argent du beurre: "je veux coder sur un projet qui est utilisé par des dizaines de milliers de gens à travers le monde, mais ce qu'ils pensent, je m'en tamponne parce qu'ils ne codent pas!".
                      Ben si les premiers devs qui ont monté le projet avaient pensé comme ça, il serait mort depuis belle lurette, le projet! Et si trop de contributeurs pensent comme ça, il va mourir tout pareil!

                      (attention: je n'ai pas dit que c'était ton cas, d'ailleurs je ne sais pas sur quoi tu bosses)

                      • [^] # Re: Parallèle avec dragonfly

                        Posté par  . Évalué à 1.

                        "Je sais ce qui est bon pour les utilisateurs et pas vous! Je continue!" c'est incohérent: ou alors dis franchement à la base utilisateur actuelle que tu veux qu'elle dégage! C'est pas la cible.

                        Quel que soit le changement, quand c'est un changement important, il y aura des gens pour raler. Et je pense qu'il n'y a aucune raison d'ecouter plus particulierement ceux qui crient le plus fort. Si les developeurs écoutent les arguments qui leur semblent convaincants, ignorent le reste, et font ce qui leur semble etre le mieux, ca me semble etre la bonne chose à faire.

                      • [^] # Re: Parallèle avec dragonfly

                        Posté par  . Évalué à 4. Dernière modification le 16 octobre 2012 à 12:41.

                        "Ah mais je m'en branle! Les utilisateurs ont qu'à coder! Je leur dois rien!"

                        Soyons clair. J’apprécie la politesse, mais ça ne m’empêche pas d’être ferme. Merci toutefois de ne pas extrêmiser ma position.

                        Le cas que tu évoques est assez particulier. Par ailleurs, dans tous les cas, le dév doit composer avant tout avec les contributeurs, les autres dévs, qu’ils soient géniaux ou pas, ça n’a pas d’importance. Et Dieu sait que ce n’est pas simple d’arriver à toujours se mettre d’accord entre contributeurs.

                        Le problème est souvent une question de vision et de choix d’orientation du projet. Et ici, il y a rarement consensus. Je reproche à certains utilisateurs de croire que leur vision est la seule bonne, combien même, nous, dévs, on se fait parfois engueuler pour des raisons totalement contraires. Les contributeurs ont parfois du mal à se mettre d’accord entre eux, et les utilisateurs exigeants se figurent toujours stupidement que leur besoin est celui de tous les utilisateurs. Rien n’est plus faux. Combien de fois ai-je vu, comme dév et comme utilisateur, des utilisateurs demander au nom de tout le monde (alors que, moi, utilisateur, je suis bien content du choix des dévs) de faire comme ils le désirent. Je pense par exemple au nouveau choix de développement de Firefox, qui a suscité tant de remous, moi, comme simple utilisateur, j’en suis très content. Sur mon projet, on m’a souvent demandé, avec plus ou moins de politesse, d’aller dans un sens, alors que quelques jours plus tôt, on m’a fait la demande exactement contraire. Crois-tu que l’utilisateur exigeant en a quelque chose à faire de l’autre utilisateur ? Non, pas du tout. L’utilisateur est aussi égoïste que le dév.
                        Par ailleurs, crois-tu qu’on sache réellement ce que veut la majorité ? Je te garantis que ce n’est pas le cas. Et les utilisateurs qui se figurent toujours parler au nom de tout le monde ne le savent pas non plus.

                        Mais demande-toi pourquoi, ou pour qui tu codes?

                        Pour moi, et pour ceux à qui ça plaît. Et j’ai de la chance, on semble apprécier ce que je fais. Du moins en partie, il y a un point sur lequel je vais probablement revenir, puisque je n’ai presque que des mauvais retours. Mais je ne me précipite pas.

                        pour améliorer un logiciel: comment tu définis l'amélioration? un code propre, un framework super bien foutu, ce sont des outils, pas des accomplissements en soi

                        Oui, pour améliorer un logiciel, voilà. C’est ça ma vraie motivation.
                        Comme personne n’est d’accord, je me sens assez libre d’aller dans le sens qui me plaît et qui semble plaire. Mais, je le répète, difficile de savoir ce qu’il en est. L’argument d’autorité souvent évoqué (’’tout le monde veut comme moi’’) n’a pas prise sur moi, je sais qu’il est faux, et en plus je peux le prouver. :)

                        Des utilisateurs contributeurs qu'on n'écoute pas, ou qu'on n'écoute plus ne participeront plus à rendre le projet populaire.

                        Fixed. :)
                        Par ailleurs, j’écoute toujours. Puis ceux qui font décident. Voilà.

                        Quand on est dév, on ne peut pas non plus avoir le beurre et l'argent du beurre: "je veux coder sur un projet qui est utilisé par des dizaines de milliers de gens à travers le monde, mais ce qu'ils pensent, je m'en tamponne parce qu'ils ne codent pas!".

                        L’erreur de ton raisonnement, c’est de penser que ceux qui râlent parlent au nom de la majorité. Ce n’est pas toujours le cas. C’est même probablement rarement le cas.

                        Dans mon projet, les remarques et orientations pertinentes ont toujours été faites par des gens qui ont participé au moins un peu, qui en ont au moins un peu compris les limites actuelles, les contraintes et, d’une manière générale, l’état des choses.

                        Enfin, écouter ses utilisateurs, ce n’est pas du tout la garantie d’étendre sa base d’utilisateurs. L’exemple le plus frappant que j’ai constaté concerne OpenOffice. À l’époque d’OOo, lors du projet de la refonte de l’interface graphique, il y eut une levée de boucliers de la part des utilisateurs d’OOo, car ça ressemblait vaguement à des rubans. OOo a subi une véritable attaque en règle de la part des utilisateurs (’’vous copiez MS, c’est horrible’’). Ce n’était pourtant qu’un prototype, des tests, mais la gueulante a été si forte que le projet est tombé à l’eau.
                        Pourtant, en d’autres lieux, sur des forums informatiques, comme PCInpact, le sentiment était contraire : ’’enfin des rubans, enfin ils revoient leur interface pour un truc moderne, c’est pas trop tôt, enfin ils ont compris’’, etc. Évidemment, des deux part, c’était plus divisé que je ne le dis, mais il y avait clairement une nette différence d’opinion entre les utilisateurs d’OOo (en général plutôt contre le projet) et les utilisateurs en puissance (plutôt favorables au projet). Évidemment, les premiers ont remporté la manche, puisque les autres n’ont rien dit. Et ailleurs, en dehors du projet, les utilisateurs en puissance se demandent encore ’’mais quand vont-ils enfin rénover l’interface?’’

                        Question : vaut-il mieux écouter les utilisateurs qu’on a déjà ou ceux qu’on pourrait avoir ? Ignorer la question en répondant seulement ’’il faut écouter les utilisateurs’’, c’est faire peut-être l’impasse sur quelque chose de bien plus désiré que l’état existant.

                        N’est-ce pas Steeve Jobs qui disait qu’ils ne fallait pas écouter ses utilisateurs, car ceux-ci ne savent pas ce qu’ils veulent, et qu’il faut leur montrer qu’ils veulent quelque chose qu’ils n’arrivent pas à imaginer. Je n’aime pas Apple, ni les rubans, mais c’est en partie mon sentiment.

            • [^] # Re: Parallèle avec dragonfly

              Posté par  . Évalué à 3.

              Encore heureux. #ifdef c'est sale.

              J'espère que tu n'utilises pas toutes ces bibliothèques mal conçues, livrées avec ta distribution Linux, qui osent utiliser des #ifdef y compris dans les fichiers d'en-tête :

              $ cat /etc/debian_version 
              6.0.6
              $ grep -r "#ifdef" /usr/include/ | wc -l
              3398
              
              

              (même la glibc, oui oui)

              • [^] # Re: Parallèle avec dragonfly

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

                Tu n'a pas compris ce que disait l'auteur. La citation exacte est:

                Encore heureux. #ifdef c'est sale. Un programme bien conçu n'utilise pas #ifdef pour assurer la portabilité, mais il sépare le code portable et le code dépendant d'une plateforme dans des fichiers différents, et laisse le système de build choisir quels fichiers compiler.

                Bien sûr que la glibc utilise ifdef pour se protéger (entre autre) contre les imports multiples.

          • [^] # Re: Parallèle avec dragonfly

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

            Je ne vois pas bien pourquoi un développeur ne pourrait pas organiser son code comme il le veut …

      • [^] # Re: Parallèle avec dragonfly

        Posté par  . Évalué à 10. Dernière modification le 14 octobre 2012 à 19:43.

        En gros, il a le droit de fermer sa gueule, c'est ça ?

        Les utilisateurs ont les droits accordés par la licence.
        Ils ont aussi le droit de râler et de hurler à la lune, et le développeur a le droit de n’en avoir rien à carrer et de dire qu’ils n’ont qu’à coder ce qu’ils désirent.

        Tout va bien.
        :)

      • [^] # Re: Parallèle avec dragonfly

        Posté par  . Évalué à 4.

        Et probablement pas de rapporter des bugs… Ce genre de commentaires m'enervent au plus haut point (pas le tiens celui au dessus). Je tiens d'ailleurs a faire remarquer que Linus Torvalds, un petit gars qui n'y connait pas grand chose en developpement, a rajoute un truc dans les logs: le nom de ceux qui ont rapporte un bug.

        • [^] # Re: Parallèle avec dragonfly

          Posté par  . Évalué à 10.

          Tu confonds rapport de bug et la beugler avec la meute. Y'en a qui saisissent encore la différence.

    • [^] # Re: Parallèle avec dragonfly

      Posté par  . Évalué à -2.

      Un utilisateur pur n'a aucun droit

      Il a le droit de ne pas vouloir utiliser un logiciel, en particulier sous GNU/Linux. Et si un logiciel est autant rejeté, tout en étant autant imposé dans un OS c'est qu'il y a un problème, non ?

      Emacs le fait depuis 30 ans.

      • [^] # Re: Parallèle avec dragonfly

        Posté par  . Évalué à 8.

        Si il est autant rejeté pourquoi la plupart des distros l’intègrent petit à petit et pourquoi l'effort pour le dégager est si marginal ? Si ça pose tant de problème que ça y'en a bien deux ou trois qui vont finir par se sortir les doigts plutôt que de vocaliser non ? Tout ce qui a fait avancer les choses est parti de la. Des mecs qui ont cherché à résoudre leur problème.

        Le problème c'est que la plupart de ceux qui parlent n'ont jamais essayé ou essayer de lire la doc et de se former. C'est dommage ca pourrait donner des discutions plus intéressantes… Mais critiquer est bien plus à la mode que contribuer.

        • [^] # Re: Parallèle avec dragonfly

          Posté par  . Évalué à 1. Dernière modification le 15 octobre 2012 à 01:35.

          Si il est autant rejeté pourquoi la plupart des distros l’intègrent petit à petit et pourquoi l'effort pour le dégager est si marginal ?

          La plupart ? Je ne vois que 7 distributions dans cet article, c'est loin de faire les 322 distributions recensées dans distrowatch, et les 600+ visible sur ce site, après la liste des OS existants. Bien sûr une partie est constituée de fork qui suivront la mouvance de la distro parente (CentOS par ex), mais d'autres ne le feront pas (ArchBang par ex). Au final je me demande combien est-ce qu'il y aura de distros qui vont adopter systemd, et dont combien à contrecoeur.

          D'autre part, je parlais d'utilisateur, pas de mainteneur de distribution. Un utilisateur n'est pas forcément capable de maintenir SysVInit ou ue autre solution, il n'est d'ailleurs pas forcément informaticien. Par contre, il peut vouloir ne pas utiliser une brique de sa distribution et vouloir la remplacer par une autre. L'ennuie est que même en maintenant SysVInit ce ne sera pas forcément évident.

          Emacs le fait depuis 30 ans.

          • [^] # Re: Parallèle avec dragonfly

            Posté par  . Évalué à 4.

            J'aimerais bien savoir ce qu'un non informaticien pourrait bien avoir à reprocher à systemd…

            • [^] # Re: Parallèle avec dragonfly

              Posté par  . Évalué à -1.

              Qu'il ne fait pas son job… je ne boote pas mes systèmes existants ( pas d'initramfs et pas /sur par sur /), c'est un peu cocasse pour un init.

              Maintenant, systemd embarque un moteur http :
              http://www.spinics.net/lists/fedora-devel/msg171856.html

              Je veux bien qu'il réponde au problème d'un init orienté évènementiel, qu'il fasse de la supervision de démons…
              mais il fait plus d'un million ligne de code! Oui il fait plus qu'un init… mais en attendant il n'init pas tous les cas existants…

              • [^] # Re: Parallèle avec dragonfly

                Posté par  . Évalué à 3.

                1 million de lignes ? Tu as des sources ?

              • [^] # Re: Parallèle avec dragonfly

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

                mais il fait plus d'un million ligne de code!

                git clone http://anongit.freedesktop.org/git/systemd/systemd.git
                cd systemd/
                find . -type f  | xargs wc -l
                ...
                  259880 total
                
                

                260000 lignes en contant les scripts les man, la doc. C'est déjà énorme soit, mais il faut pas abuser non plus.

                • [^] # Re: Parallèle avec dragonfly

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

                  Surtout que tu comptes le code de logind, journald, les utilitaires de conf…

                  • [^] # Re: Parallèle avec dragonfly

                    Posté par  . Évalué à 2.

                    Non il compte tout les fichiers. C'est tellement grossier comme métrique qu'elle ne sert à rien; déjà que le nombre de lignes de code ne veut pas dire grand chose. Autrement pour rester dans les mesures inutiles, systemd c'est un peu plus gros que rsyslog en LOC C… Du coup c'est énorme ou pas ?

                • [^] # Re: Parallèle avec dragonfly

                  Posté par  . Évalué à 3.

                  allez, par curiosité :

                  925 text files.
                  861 unique files.                                          
                  342 files ignored.
                  
                  http://cloc.sourceforge.net v 1.56  T=4.0 s (140.8 files/s, 47077.2 lines/s)
                  --------------------------------------------------------------------------------
                  Language                      files          blank        comment           code
                  --------------------------------------------------------------------------------
                  C                               257          29422          10139          98287
                  XML                             118           4015           1608          22215
                  C/C++ Header                    155           2868           3214           6296
                  make                              6            750            234           3177
                  Perl                              1             52             31           1447
                  m4                                6            137             44           1357
                  Bourne Shell                      7            149            143            744
                  Bourne Again Shell                1             90            163            611
                  HTML                              1             65              3            368
                  Python                            5             80            141            204
                  Javascript                        3             31              6            148
                  XSLT                              1             11             17             22
                  awk                               1              2              0             11
                  Lisp                              1              1              3              3
                  --------------------------------------------------------------------------------
                  SUM:                            563          37673          15746         134890
                  --------------------------------------------------------------------------------
                  
                  
              • [^] # Re: Parallèle avec dragonfly

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

                /usr CELA NE SERT PLUS A RIEN. Une fois démarré, /usr en réseau ou /, c'est pareil niveau perf donc autant choisir la seconde solution…

                Maintenant, systemd embarque un moteur http :

                Faux, c'est journald, un processus à part.

                • [^] # Re: Parallèle avec dragonfly

                  Posté par  . Évalué à 3. Dernière modification le 15 octobre 2012 à 09:35.

                  /usr CELA NE SERT PLUS A RIEN.

                  L'existant?

                  Faux, c'est journald, un processus à part.

                  Alors explique-moi les commentaires de Lennart:

                  "In other words: systemd and journald are separate enough from each other
                  to make them two processes, but way too integrated to separate them from
                  each other entirely and allow one running without the other.
                  "

                  http://www.spinics.net/lists/fedora-devel/msg172203.html

                  • [^] # Re: Parallèle avec dragonfly

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

                    L'existant?

                    Ca fait des années que plus personne ne fais cela. Tu boot en PXE une disque complet, pas un disque local avec un /usr distant et quand bien même tu ferais encore cela, ça doit prendre 10 minutes à changer.

                    Alors explique-moi les commentaires de Lennart:

                    Ben, que systemd communique avec journald et que journald reçoit les informations de l'autre donc effectivement, ils sont dépendants l'un de l'autre… Mais si tu supprime journald, systemd va continuer à tourner mais sans rien enregistrer dans les logs…

                    • [^] # Re: Parallèle avec dragonfly

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

                      systemd va continuer à tourner mais sans rien enregistrer dans les logs…

                      En voilà une solution satisfaisante !

                    • [^] # Re: Parallèle avec dragonfly

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

                      Ca fait des années que plus personne ne fais cela

                      FAIL !
                      Désolé de te l'apprendre mais tu es très loin d'être omniscient..

                      J'ai toujours mis /usr et /var séparés sur LVM afin de pouvoir adapter leur taille (et donc en réserver plus pour /home). Et non, je ne met pas / sur LVM afin de pouvoir booter si le LVM foire (on ne sait jamais).
                      C'est également le partitionnement recommandé par le guide d'installation Gentoo.

                      De plus, avoir un / minimal permet de réduire les risques d'erreur sur cette partition. Et oui, ça m'a servi, deux fois (sur deux portables différents, une fois sur /usr et l'autre sur /var justement). Dans un cas j'ai pu booter et réparer la partition dans le train avant d'arriver chez un client.

                      Donc OUI, ça peut servir ; OUI, ça fonctionne très bien, et sans connerie d'initramfs. Du moins ça fonctionnait très bien avant que les dévs de udev ne décident sciemment de tout foutre en l'air.

                      Greg KH, reviens, ils sont devenus fous !

                      • [^] # Re: Parallèle avec dragonfly

                        Posté par  . Évalué à 3.

                        Et non, je ne met pas / sur LVM afin de pouvoir booter si le LVM foire (on ne sait jamais).

                        Quel est l'intérêt ? Autant avoir un live-cd/usb dans ce cas, il y a beaucoup plus de chance que ce soit plus utile.

                        « 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: Parallèle avec dragonfly

                  Posté par  . Évalué à 4.

                  Faux, c'est journald, un processus à part.

                  Non, il y a bien eu libmicrohttpd ajouté à systemd. Dans le but de faciliter certains dialogue avec journald d'accord, mais les lignes de codes vont bien dans systemd (la partie journal-gateway). Lennart semble même penser à ajouter une gestion des certificats avec TLS et tout le toutim.

                  Ceci étant c'est désactivé par défaut, donc à moins de vouloir journal-gateway SANS http, ça ne pose pas vraiment de problème.

                  • [^] # Re: Parallèle avec dragonfly

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

                    journal-gateway est un démon à part donc il n'est pas dans systemd.

                    • [^] # Re: Parallèle avec dragonfly

                      Posté par  . Évalué à 7.

                      journal-gateway est un démon à part donc il n'est pas dans systemd.

                      Euh… Si tu vas par là rien n'est systemd. journal-gateway est dans l'arbre systemd direct, n'est utilisé que par systemd, n'a aucun intéret hors de systemd etc.
                      Sinon on peut dire que systemctl n'est pas sytemd parce que c'est un programme à part.
                      systemd est un ensemble d'outils, certains obligatoires, d'autres optionnels, mais je vois pas à quel titre on pourrait séparer journal-gateway du reste de systemd.

                      • [^] # Re: Parallèle avec dragonfly

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

                        Euh, le reproche qui est fait à systemd est que le pid 1 a des dépendances dans tous les sens… Donc, si on s'en fout qu'un démon autre que le pid 1 dépende de x ou y…

                        • [^] # Re: Parallèle avec dragonfly

                          Posté par  . Évalué à 4.

                          Euh, le reproche qui est fait à systemd est que le pid 1 a des dépendances dans tous les sens

                          C'est un des reproches fait à systemd.
                          Un autre reproche est que pour avoir un systemd complet et fonctionnel il faut se frapper une chaine de bootstrapping monstrueuse. Une lib de plus (même une petite lib) n'est pas anodine.
                          Encore un autre reproche est que les versions minimales des distribs (ie utilisées pour déboguer une fonctionnalité ciblée) commencent à être impactées assez négativement par cette pléthore de libs qu'on se ramasse dès l'init.

            • [^] # Re: Parallèle avec dragonfly

              Posté par  . Évalué à 7.

              Je réponds ici, mais c'est un peu hors-sujet:

              En fait, pour systemd, le non-informaticien, je pense qu'il s'en fout, parce que la seule chose qu'il verra c'est que le système démarre plus vite, et il trouvera que c'est super!

              Les 2 personnes les plus susceptibles d'être affectées par le changement sont:
              -le mainteneur de distro
              -l'administrateur système

              Les deux ne sont peut-être pas des contributeurs upstream, mais je crois que leur retour à eux est quand même très très important.

              On peut dire ce qu'on veut du développeur qui code bénévolement et fait ce qu'il veut. Mais à la fin, la question est:
              Qui va utiliser le résultat?

              Les distros commencent à migrer, on peut donc se dire que les mainteneurs y voient leur intérêt.
              Cela dit, quand on lit des trucs genre "on migre parce que la dépendance sur systemd et les outils associés va augmenter", ça fait peur!
              On se demanderait presque si on n'a pas une caste de développeurs qui prend les décisions dans une tour d'ivoire et impose leurs changements aux utilisateurs!
              Bon, ce n'est qu'un petit extrait, ailleurs, ce que je comprends c'est que "tout ce qui est reproché à systemd d'un point de vue technique n'est pas un problème".

              Les admins? Je n'en sais trop rien. Peut-être qu'ils s'en foutent parce qu'ils n'utilisent pas systemd, ni dbus, ni rien dans le genre? (je ne suis pas admin, je ne sais pas de quoi ils ont besoin).

              On peut aussi considérer que les utilisateurs "hobbyistes" sont des admins (genre moi: j'administre mon PC, quoi!). Pour moi je dois dire que je m'en fous un peu aussi.
              Je m'inquiète seulement d'une possible linuxisation excessive des logiciels Libres, mais aujourd'hui, difficile à dire. Un autre truc qui pourrait m'inquiéter, ce serait que l'utilisation des outils deviennent de plus en plus compliquées, mais systemd n'a pas l'air bien compliqué à utiliser, juste différent.

              Après, il y a ceux qui ne verront pas systemd sur leur machine, mais qui sont concernés par ses effets de bord:
              En premier lieu ici, les systèmes BSD, dans une moindre mesure, les distros genre Debian (Debian/kFreeBSD).
              Le système d'init en soi, je ne pense pas que ce soit le plus gros problème.

              Le plus gros problème, c'est la dépendance croissante de certaines applis avec des fonctions purement linuxiennes.

              Ont-ils leur mot à dire? Strictement parlant, non: ils n'ont qu'à coder un équivalent (c'est ce que je comprends des explications de Lennart Poettering et autres partisans farouches de systemd)

              Moralement parlant, c'est vachement moins justifiable de les envoyer chier. Il fut une époque où on ne parlait pas de hiérarchie dans le monde Libre, et encore moins de hiérarchie basée sur le nombre d'utilisateurs.

              Mais à la fin, le juge de paix, c'est la base utilisateur!
              Si on change quelque chose dans un logiciel, et que tous les utilisateurs fuient, il faut considérer 2 cas:
              1. Je m'en fous, l'appli est pour mon besoin personnel.
              2. Je codais pour un truc massivement utilisé avant, il est temps de se poser des questions.

              L'inertie risque d'être forte, mais si on voit des migrations massives vers des systèmes qui n'utilisent pas systemd (d'autres distros Linux ou des systèmes BSD), alors il faudra se poser des questions!

              En ce qui me concerne, si Debian migre, je ne changerai pas de distro, ou alors par curiosité.

              • [^] # Pourquoi passer à systemd ?

                Posté par  . Évalué à 4.

                quand on lit des trucs genre « on migre parce que la dépendance sur systemd et les outils associés va augmenter », ça fait peur!
                […]
                Bon, ce n'est qu'un petit extrait, ailleurs, ce que je comprends c'est que « tout ce qui est reproché à systemd d'un point de vue technique n'est pas un problème ».

                La lecture du long message (en anglais) de Tom Gundersen (le mainteneur de SysVinit dans Archlinux) est intéressante. Il précise plusieurs raisons techniques qui justifient, à ses yeux, l'adoption de systemd. Ça se passe sur ce lien (seule la seconde partie du message est pertinente, après le « Benefits »).

                J'avais incorporé son message dans le corps de la dépêche, mais les modérateurs l'ont supprimé à la publication. 😞

                • [^] # Re: Pourquoi passer à systemd ?

                  Posté par  . Évalué à 6.

                  La lecture du long message (en anglais) de Tom Gundersen (le mainteneur de SysVinit dans Archlinux) est intéressante. Il précise plusieurs raisons techniques qui justifient, à ses yeux, l'adoption de systemd. Ça se passe sur ce lien (seule la seconde partie du message est pertinente, après le « Benefits »).

                  C'est très intéressant. Grosso modo :

                  1. il supporte des configurations mouvante (hot plug) : on branche un disque, il lance fsck et le monte proprement
                  2. on peut connaître l'état du système : systemd connaît l'état de tout les deamons
                  3. c'est modulaire : on peut remplacer des parties par nos propres scripts (et ces parties sont bien documentées), il dit que c'est plus compliqué avec rc.sysinit car les dépendances sont moins claires
                  4. on peut plus facilement lancer un service à la demande notamment avec udev
                  5. les sockets activation et dbus activation permettent de simplifier les dépendances
                  6. on gagne en sécurité via les cgroup
                  7. on peut capitaliser les fichiers de descriptions de services (fini les scripts spécifiques à chaque distribution)
                  8. c'est plus simple pour eux d'être plus proche de l'upstream
                  9. logind fait le boulot que consolekit devrait faire (suivre les sessions utilisateurs, donner des droits, etc)
                  10. il est rapide ou pas, mais il s'en fout

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

                  • [^] # Re: Pourquoi passer à systemd ?

                    Posté par  . Évalué à 5.

                    Oui, c’est intéressant :

                    il supporte des configurations mouvante (hot plug) : on branche un disque, il lance fsck et le monte proprement

                    Ça peut déjà être fait avec udev.

                    on peut connaître l'état du système : systemd connaît l'état de tout les deamons

                    On peut également savoir quels sont les services actifs sur les init standard. Que le PID1 le sache apporte quoi au juste ? Une manière différente d’interroger ?

                    c'est modulaire : on peut remplacer des parties par nos propres scripts (et ces parties sont bien documentées), il dit que c'est plus compliqué avec rc.sysinit car les dépendances sont moins claires

                    Ok. C’est un problème spécifique à Arch.

                    on peut plus facilement lancer un service à la demande notamment avec udev

                    On peut le faire aussi, il suffit d’avoir udev.

                    les sockets activation et dbus activation permettent de simplifier les dépendances

                    Ok. Je suis d’accord avec ça. Même s’il faut faire confiance à l’outil plutôt que de connaître parfaitement son produit.

                    on gagne en sécurité via les cgroup

                    Mouai, c’est déjà possible aussi.

                    on peut capitaliser les fichiers de descriptions de services (fini les scripts spécifiques à chaque distribution)

                    C’est vrai, l’uniformisation du system permet d’uniformiser les configs… mais si c’était un argument, il n’y aurait pas 300 distribution GNU/Linux. Quitte à uniformiser, je préfère openrc. En même temps, je suis gentooiste.

                    c'est plus simple pour eux d'être plus proche de l'upstream

                    Je ne vois pas en quoi tu es plus proche de l’upstream. Cela veut dire que c’est les développeurs qui vont faire les fichiers de config de systemd ? Ça rejoint l’argument de l’uniformisation.

                    logind fait le boulot que consolekit devrait faire (suivre les sessions utilisateurs, donner des droits, etc)

                    À bon. Consolekit ne répond pas aux exigences. Quand je lis devrait je comprends que consolekit ne répond pas au besoin de cette personne d’Arch, mais en quoi c’est-il ce que consolekit _devrait faire_ ? Les dév de consolekit doivent le savoir également, et donc faire la correction, non ?

                    il est rapide ou pas, mais il s'en fout

                    La rapidité n’est pas un argument, on est d’accord.

                    J’avoue que je n’avais lu que les 3 premières raisons. La seule bonne raison, à mes yeux, c’est l’uniformisation. Hélas, j’aurais préféré un truc du genre freedesktop, qui définisse une norme, plutôt que systemd.

                    Bientôt, ce sera Lennart/Linux qu’il faudra écrire ;-). Je ne suis toujours pas convaincu par les arguments, même si je comprends que beaucoup le soit. La suite sera intéressante.

                    • [^] # Re: Pourquoi passer à systemd ?

                      Posté par  . Évalué à 2.

                      il supporte des configurations mouvante (hot plug) : on branche un disque, il lance fsck et le monte proprement

                      Ça peut déjà être fait avec udev.

                      C'est peut être plus simple avec systemd qui écoute les évènement udev, plutôt que d'écrire son propre script pour udev ?

                      On peut également savoir quels sont les services actifs sur les init standard. Que le PID1 le sache apporte quoi au juste ? Une manière différente d’interroger ?

                      Je crois que l'idée c'est d'avoir une vision globale du système. Savoir pour un service donné s'il est lancé ou pas est simple, mais le faire de manière globale avec des services lancés à la demande (par socket activation, dbus activation ou udev) c'est plus compliqué.

                      les sockets activation et dbus activation permettent de simplifier les dépendances

                      Ok. Je suis d’accord avec ça. Même s’il faut faire confiance à l’outil plutôt que de connaître parfaitement son produit.

                      Je ne comprends pas ce que tu veux dire dans ta seconde phrase ? Je pense que l'idée c'est de ne pas mettre une dépendance sur un service appelé par gnome via dbus occasionnellement par exemple.

                      C’est vrai, l’uniformisation du system permet d’uniformiser les configs… mais si c’était un argument, il n’y aurait pas 300 distribution GNU/Linux. Quitte à uniformiser, je préfère openrc. En même temps, je suis gentooiste.

                      Je pense qu'il compare rc.sysinit et systemd. Il ne parle pas de l'ensemble des alternatives et de leur intérêt à chacune.

                      logind fait le boulot que consolekit devrait faire (suivre les sessions utilisateurs, donner des droits, etc)

                      À bon. Consolekit ne répond pas aux exigences. Quand je lis devrait je comprends que consolekit ne répond pas au besoin de cette personne d’Arch, mais en quoi c’est-il ce que consolekit devrait faire ? Les dév de consolekit doivent le savoir également, et donc faire la correction, non ?

                      J'ai traduit modestement ce qu'il disait, mais c'est peut être une subtilité que j'ai introduit malencontreusement. La vo :

                      logind will finally deliver on what consolekit was supposed to do: we can now track user sessions and seats, assign permissions to resources on-the-fly etc. This should be the topic of a separate message, as it is too much to get into. Suffice it to say that I'm very happy that we are finally getting these features working as they should.

                      C'est le « consolekit was supposed to do » qui m'a fait penser qu'il ne faisait pas ce qu'il était censé faire.

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

                      • [^] # Re: Pourquoi passer à systemd ?

                        Posté par  . Évalué à 1.

                        Ok. Je suis d’accord avec ça. Même s’il faut faire confiance à l’outil plutôt que de connaître parfaitement son produit.

                        Je ne comprends pas ce que tu veux dire dans ta seconde phrase ?

                        En fait, c’est une déformation professionnelle. Je suis obligé de prouver par A + B que le code produit ne peut jamais faire autre chose que ce qui est demandé. Mon propos était que systemd permet de démarrer les systèmes à la demande, donc de ne plus s’intéresser à savoir qui à besoin de quoi. Puisque l’outil s’autodémerdera©. Je trouve que c’est une perte de compétence et de connaissance du système. Ça apportera de la flexibilité par contre. Ai-je été plus clair ?

                        J'ai traduit modestement ce qu'il disait, mais c'est peut être une subtilité que j'ai introduit malencontreusement

                        Mon anglais n’étant pas meilleur que le tien, à mon avis, ta traduction me va.

                    • [^] # Re: Pourquoi passer à systemd ?

                      Posté par  . Évalué à 1.

                      c'est plus simple pour eux d'être plus proche de l'upstream

                      Je ne vois pas en quoi tu es plus proche de l’upstream.

                      Ce que je comprends : jusqu'à présent, les scripts initialisant le système d'exploitation étaient propres à chaque distribution ; chaque distrib' devait faire l'effort de les maintenir.

                      Sous Archlinux, ces scripts étaient /etc/rc.sysinit, /etc/rc.single, /etc/rc.multi et /etc/rc.shutdown.

                      À présent, pour les distributions utilisant systemd, ces scripts sont mutualisés. Cela allège le travail de maintenance de la distribution.

                      j’aurais préféré un truc du genre freedesktop

                      Le site officiel de systemd est hébergé sur freedesktop.org : http://freedesktop.org/wiki/Software/systemd/ 😄

                      • [^] # Re: Pourquoi passer à systemd ?

                        Posté par  . Évalué à 3.

                        En fait c'est un problème purement humain.
                        Les scripts d'init ont toujours pu être identiques d'une distrib à l'autre. Mais personne n'a jamais tenté d'uniformiser.
                        Avec systemd c'est un bon prétexte pour uniformiser puisqu'il faut tout changer. Mais uniformiser n'est en rien obligatoire avec systemd. Et peut-être que dans 3 ans il y aura des différences dans tous les sens.

                        • [^] # Re: Pourquoi passer à systemd ?

                          Posté par  . Évalué à 1.

                          En fait c'est un problème purement humain.

                          Non. C'est un problème qui possède une composante humaine.

                          Systemd (comme openrc) apportent une uniformisation (et une simplification) ils poussent vers un standard. Les mécanismes de base sont déjà implémenté (vérifier que le service n'est pas déjà lancé par exemple). Bien sûr tu peut contourner ces mécanismes pour créer les tiens mais ça demande un travail beaucoup plus important que celui de suivre les mécanismes classiques. Debian utilise des fonction « start-stop-deamon » mais je crois justement que c'est spécifique à Debian.

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

                      • [^] # Re: Pourquoi passer à systemd ?

                        Posté par  . Évalué à 1. Dernière modification le 16 octobre 2012 à 14:44.

                        Si c'est un problème de mutualisation, pourquoi les distrib. ne font pas un système de distribution binaire commun?
                        Par exemple, celui de Red-Hat pour tous les appli binaires communes à toutes les distrib. puis modulo des arbres spécifiques à chaque distrib. pour ce qui n'intéresse pas Red Hat. Pourquoi les mainteneurs ne font pas ça?
                        Ca leur faliciterait la vie, un gros arbre commun, de plus comme le matos sera Red Hat moins de gestion matériel.

                        Pourquoi ne pas mutualiser le boot et l'init sur linux aussi?
                        Pourquoi ne pas caser tout ce qui est nécessaire au boot dans un bien sympa initramfs géré avec dracut (celui-ci gère aussi l'orienté événement)?
                        Tout le monde aurait le même script automatisé? Mise à jour? hop script dracut!

                        Pourquoi ne pas faire un partitionnement commun, unique?
                        hop /boot et / sans /usr puisqu'il ne sert plus à rien!

                        Comme tous les scripts démons seront tous mutualisés par systemd… plus personne n'aura à s'en faire.

                        On pourrait aussi mutualiser les méthodes d'install!
                        hop par défaut /boot et / .
                        Quoi tu es admin? hop mode expert raid,lvm sur / (qui aura /share /local /var /bin /sbin /home) ou bien du nfs?
                        Franchement pourquoi les distrib. ne font pas un installeur commun.

                        En plus c'est génial tout ça car on aurait un seul endroit pour géré les rapports de bug! Et on aurait plein de beta testeur!

                        Une pour les mutualiser toutes!

                        Enfin de compte Lennart a complètement raison, autant faire un OS complet à la BSD.

                        • [^] # Re: Pourquoi passer à systemd ?

                          Posté par  . Évalué à 0.

                          Inspire bien fort, fais de la relaxation, respire.

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

                          • [^] # Re: Pourquoi passer à systemd ?

                            Posté par  . Évalué à 2. Dernière modification le 16 octobre 2012 à 14:58.

                            Mais je suis très sérieux! Au final, s'il y a un problème de maintenance, donc de personne pourquoi ne pas mutualiser tout? Faire comme font les BSD, un OS, avec un noyau, un userland spécifique puis un dépôt tiers?

                            Que l'on réponde franchement, pourquoi ne pas faire ainsi?

                            • [^] # Re: Pourquoi passer à systemd ?

                              Posté par  . Évalué à 0.

                              Faut garder un minimum la tête froide. Les différent gestionnaires de paquets viennent de dissensions qui n'ont jamais étaient résolu (malgré une tentative avec LSB). Là en l’occurrence une partie des mainteneurs de distributions arrivent à se mettre d'accord pour cette solution. Oui ce n'est pas une solution spécifiée de manière collégiale mais c'est des fois comme ça que ça marche le mieux (qu'il n'y a pas des discussions de durée infinie). Hors de c'est deux choses, il reste la gestion du réseau et ensuite ? Tout le reste du système est identique ou presque d'une distribution à l'autre (modulo la configuration par défaut). Ubuntu maintiens ses spécificités (upstart et unity).

                              Tout cela a créé des dizaines de flameware et des milliers de troll, c'est pas pour cela qu'il ne faut pas se réjouir quand des distributions arrivent à améliorer leur interopérabilité.

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

                              • [^] # Re: Pourquoi passer à systemd ?

                                Posté par  . Évalué à 1. Dernière modification le 16 octobre 2012 à 15:28.

                                c'est pas pour cela qu'il ne faut pas se réjouir quand des distributions arrivent à améliorer leur interopérabilité.

                                Interopérabilité de quoi? On est sur un OS identique avec des toolchains identiques, un userland aussi différent qu'il y a de différences génétique entre l'homme et le singe!
                                Si être interopérable, c'est de sauter entre un Gnux,systemd/linux debian Gnome et un Gnu,systemd/linux KDE fedora… alors la communauté linuxienne a un problème.

                                Les différent gestionnaires de paquets viennent de dissensions qui n'ont jamais étaient résolu (malgré une tentative avec LSB).

                                Comme il y a en ce moment avec systemd….
                                et franchement qu'est-ce que ça change a aptitude install, un synaptic, yum, pour les utilisateurs/admin ..etc tant que ça gère les dépendances et ça installe. D'ailleurs il y a pakagekit maintenant…
                                L'autre problème des mainteneurs, c'est la gestion des dépendances et le versionning… pourquoi ne pas mutualiser?

                                • [^] # Re: Pourquoi passer à systemd ?

                                  Posté par  . Évalué à -1.

                                  c'est pas pour cela qu'il ne faut pas se réjouir quand des distributions arrivent à améliorer leur interopérabilité.

                                  Interopérabilité de quoi? On est sur un OS identique avec des toolchains identiques, un userland aussi différent qu'il y a de différences génétique entre l'homme et le singe!

                                  Pourquoi tu dis vouloir être pris au sérieux ? Être interopérable c'est pouvoir faire fonctionner un script par exemple un script de démarrage de postgre sur fedora comme sur maegia.

                                  Si être interopérable, c'est de sauter entre un Gnux,systemd/linux debian Gnome et un Gnu,systemd/linux KDE fedora… alors la communauté linuxienne a un problème.

                                  Si tu te demande pourquoi tu semble n'être qu'un trolleur de bas étage voici la raison. Tu peste sans argumenter, tu pointe du doigt toute une série de logiciel sans expliquer pourquoi (qu'est ce viens faire Debian, Fedora et KDE ici ?).

                                  Mais pour parler sérieusement (puisque c'est ainsi que tu veux qu'on prenne tes messages). Systemd a défini avec précision ces interfaces ce qui permet de le remplacer. Ubuntu le fait avec upstart. Systemd est hébergé par freedesktop qui est l'organisation qui s'occupe de définir ce genre de standard. Là où sysinit est juste un standard de fait peu défini.

                                  Réellement je n'ai pas encore touché à systemd et je suis plutôt attiré par sysint et openrc, mais c'est pas une raison pour faire preuve de mauvaise fois.

                                  Comme il y a en ce moment avec systemd….

                                  7 distributions majeures y sont passées. Même si ubuntu continue a garder upstart, gentoo openrc et debian autre chose, ça reste une harmonisation importante.

                                  et franchement qu'est-ce que ça change a aptitude install, un synaptic, yum, pour les utilisateurs/admin ..etc tant que ça gère les dépendances et ça installe. D'ailleurs il y a pakagekit maintenant…

                                  Les différences ce sont estompée (dans le temps dpkg gérait les paquets virtuels ce que rpm ne faisait pas, aujourd'hui yum peut télécharger des delta de paquet ce qu'apt n'est pas capable de faire, la gestion des fichiers de config n'est pas une chose aisée, Debian grâce à Raphël Herzog travail sur la possibilité d'installer des paquets de différentes architectures c'est quelque chose que l'on ne trouve pas à ma connaissance ailleurs). pakagekit n'est qu'une abstraction par dessus.

                                  L'autre problème des mainteneurs, c'est la gestion des dépendances et le versionning… pourquoi ne pas mutualiser?

                                  Il y a des projets dans ce sens (je crois me souvenir qu'un Debian Project Leader bossait dessus), mais l'ampleur de la tâche est immense ce qui fait que c'est long.

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

                                  • [^] # Re: Pourquoi passer à systemd ?

                                    Posté par  . Évalué à 2. Dernière modification le 16 octobre 2012 à 19:43.

                                    Pourquoi tu dis vouloir être pris au sérieux ?

                                    si je veux être vraiment sérieux, je ne poste pas sur trollfr… sinon précédemment, c'était une figure de style. Franchement, parler de systemd est infaisable ( c'est d'ailleurs pour ça que je m'étais branché sur la mutualisation).

                                    Être interopérable c'est pouvoir faire fonctionner un script par exemple un script de démarrage de postgre sur fedora comme sur maegia.

                                    Non pour moi ça c'est être compatible…

                                    Je ne sais même pas si on peut vraiment parler d'interopérabilité entre les différentes distro… il faudrait avoir différents "opérateurs" dont la structure même du système soit différente ce qui n'est pas vraiment le cas.
                                    Je prends les distro. comme étant pratiquement un même opérateur ( un GNU/Linux).

                                    je mets ça en référence pour développer mes propos:

                                    Si tu te demande pourquoi tu semble n'être qu'un trolleur de bas étage…

                                    tu penses ce que tu veux, personnellement, je m'en fiche, ce n'est pas mon problème.

                                    Tu peste sans argumenter, tu pointe du doigt toute une série de logiciel sans expliquer pourquoi (qu'est ce viens faire Debian, Fedora et KDE ici ?).

                                    Pour dire que tu peux mettre n'importe quels projets à côté, parler d'interopérabilité pour des GNU/linux n'a pas de sens ( en tout cas pour moi ).

                                    Mais pour parler sérieusement (puisque c'est ainsi que tu veux qu'on prenne tes messages). Systemd a défini avec précision ces interfaces ce qui permet de le remplacer. Ubuntu le fait avec upstart. Systemd est hébergé par freedesktop qui est l'organisation qui s'occupe de définir ce genre de standard. Là où sysinit est juste un standard de fait peu défini.

                                    Si je voulais parler sérieusement ( le vrai sérieux): la plupart des noyaux sont de plus en plus orienté évènements avec des interfaces asynchrones/non bloquantes (epoll, /dev/poll, aio, kqueue), celà permet une meilleure montée en charge.
                                    systemd/upstart/klaunchd/init SMF de solaris sont tous orientés événements et c'est ce que veut tous les partisans de systemd. Pour eux c'est un design moderne, que n'importe quel autre type d'init n'a pas et qu'il est un non sens d'utiliser ( cf flamewar debian-dev a propos RFC sur openrc). En quoi un paradigme orienté évènement est-il bon pour un init?

                                    Pour ce qui est de la supervision: il existe déjà des alternatives (runit et s6 de Bernstein). Pour les init BSD il a un projet FreeBSD pour de la supervision. En quoi ces alternatives sont mauvaises ou pas populaires?

                                    Réellement je n'ai pas encore touché à systemd et je suis plutôt attiré par sysint et openrc, mais c'est pas une raison pour faire preuve de mauvaise fois.

                                    Je te signale encore que je ne parlais pas de systemd mais de mutualisation, lance le troll une fois de plus si tu veux… mais je n'interviendrais pas.

                                    Systemd est hébergé par freedesktop qui est l'organisation qui s'occupe de définir ce genre de standard.

                                    FreeDesktop n'est pas un peu linux-centré, non? ( j'sais pas. Il y a des gars coté solaris ou de BSD qui s'éclament dans leur "standards"?) La dernière fois que j'ai entendu quelque chose c'est pour KMS/GEM avec une refonte énorme du code et un pétage de câble côté FreeBSD pour leur port.
                                    Finalement, c'est quoi un standard FreeDesktop? ( ça c'est la vraie question sérieuse)

                                    • [^] # Re: Pourquoi passer à systemd ?

                                      Posté par  . Évalué à 0.

                                      Je te signale encore que je ne parlais pas de systemd mais de mutualisation, lance le troll une fois de plus si tu veux… mais je n'interviendrais pas.

                                      Oula. Je me suis juste contenté de retranscrire en français les raisons qui amènent à systemd pour le mainteneur d'Archlinux (il me semble qu'il est relativement bien placé pour en parler). C'est toi qui par au quart de tour sur des propos que je n'ai pas tenu (juste retranscrit sans donner mon avis).

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

                                      • [^] # Re: Pourquoi passer à systemd ?

                                        Posté par  . Évalué à 1.

                                        C'est toi qui par au quart de tour sur des propos que je n'ai pas tenu (juste retranscrit sans donner mon avis).

                                        ???
                                        Je suis intervenu sur la mutualisation.
                                        Après c'est toi qui interprète que c'est tendu.

                                        ensuite tes dires:

                                        Mais pour parler sérieusement (puisque c'est ainsi que tu veux qu'on prenne tes messages). Systemd a défini avec précision ces interfaces ce qui permet de le remplacer. Ubuntu le fait avec upstart. Systemd est hébergé par freedesktop qui est l'organisation qui s'occupe de définir ce genre de standard. Là où sysinit est juste un standard de fait peu défini.[…]"

                                        Personnellement, ca n'a rien à voir avec mon intervention initiale (le reste je trouvais pertinent).

                                        Si on doit parler d'init (hors mutualisation des ressources), moi je veux bien. J'ai une question pourquoi un design orienté événement est pertinent pour un init?

                                        • [^] # Re: Pourquoi passer à systemd ?

                                          Posté par  . Évalué à 2.

                                          Je suis intervenu sur la mutualisation.

                                          Excuse-moi j'ai mal suivi à qui tu répondais.

                                          Personnellement, ca n'a rien à voir avec mon intervention initiale (le reste je trouvais pertinent).

                                          Je répondais à tes « Gnux,systemd/linux debian Gnome et un Gnu,systemd/linux KDE fedora » où j'avais l'impression que tu parlais d'un couplage fort entre le DE et systemd.

                                          J'ai une question pourquoi un design orienté événement est pertinent pour un init?

                                          En fait les « ordinateurs » (au sens large, tablettes comprises) sont des modulaires et leur évènement évolue dynamiquement (ils passent de connectés à une prise à une alimentation sur batterie, ils changent de réseau (pour passer d'un réseau ethernet, à du wifi ou un modem 3G), on y connecte un (ou pas) une imprimante, un disque dur en plus,…). Tout ces changements demandent soit des initialisations soit des lancement ou retrait de service. La solution des inits évènementiels consiste à dire que tout est évènement (le démarrage, l'arrêt, etc). La seconde est plus simple à prendre en main et elle me semble plus naturelle.

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

          • [^] # Re: Parallèle avec dragonfly

            Posté par  . Évalué à 6.

            L'ennuie est que même en maintenant SysVInit ce ne sera pas forcément évident.

            C’est là tout le problème.
            J’ai presque songé à me proposer pour maintenir SysVInit, mais si pour conserver un système pleinement fonctionnel, il faut aussi forker PolicyKit, Network Manager et reprendre le développement de ConsoleKit, c’est rédhibitoire.

            Dommage, mon expérience de SystemD (je l’essaie en mode natif depuis mai ou juin 2011) m’a fait apprécier la valeur d’un système de démarrage sub-optimal, mais simple et robuste comme l’ancien système de démarrage d’Arch.

            La conclusion qu’on peut tirer de tout ça, c’est qu’à partir du moment où RedHat emploie des développeurs clés un peu partout dans l’écosystème Linux, on peut difficilement échapper à leurs évolutions, même en utilisant une autre distribution.

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

          • [^] # Re: Parallèle avec dragonfly

            Posté par  . Évalué à 6.

            La plupart ? Je ne vois que 7 distributions dans cet article, c'est loin de faire les 322 distributions recensées dans distrowatch, et les 600+ visible sur ce site, après la liste des OS existants. Bien sûr une partie est constituée de fork qui suivront la mouvance de la distro parente (CentOS par ex), mais d'autres ne le feront pas (ArchBang par ex). Au final je me demande combien est-ce qu'il y aura de distros qui vont adopter systemd, et dont combien à contrecoeur.

            Je sais pas si tu es au courant, mais les utilisateurs des 322 ou 600+ distributions sont loin d'être réparti uniformément. Si tu rajoutes Debian, *buntu et peut être Gentoo à la liste, t'as atteint le 90% des utilisateurs.

            Et je parle même pas du poids que le seul Red Hat/Fedora a dans l'écosystème Linux.

      • [^] # Re: Parallèle avec dragonfly

        Posté par  (site web personnel) . Évalué à 2. Dernière modification le 15 octobre 2012 à 09:25.

        Et si un logiciel est autant rejeté, tout en étant autant imposé dans un OS c'est qu'il y a un problème, non ?

        Tu confonds ceux qui râlent avec un "autant rejeté". Au pif, il doit y avoir 1% de gros râleurs derrière leur chaise qui ne se bougent pas le cul pour proposer mieux, 1% d'utilisateurs contents du changement et 98% qui s'en foutent tant que ça marche et que ça allège le boulot des mainteneurs.

        Toi, tu crois que ceux qui gueulent le plus fort sont représentatifs, ce n'est pas le cas. Pour troller, c'est comme les 0.01% de manifestants qui essayent de vendre leur propagande "nous sommes les 99%" alors qu'ils sont que 0.01% et n'ont le soutiens que de quelques autres pour-cent.

        Bref, faudrait arrêter de confondre "grande gueule" et "être représentatif".

        Il a le droit de ne pas vouloir utiliser un logiciel, en particulier sous GNU/Linux.

        Il a le droit, personne ne t'interdit d'utiliser une distro qui te convient. Par contre, liberté en face de ne pas faire ce que toi tu veux. Et si il n'y a pas correspondance, libre à toi de mettre la main à la patte… Arch cherche des mainteneurs de SysV! Mais attention, c'est plus dur que de râleur derrière son écran…

        D'autre part, je parlais d'utilisateur, pas de mainteneur de distribution. Un utilisateur n'est pas forcément capable de maintenir SysVInit ou ue autre solution, il n'est d'ailleurs pas forcément informaticien. Par contre, il peut vouloir ne pas utiliser une brique de sa distribution et vouloir la remplacer par une autre. L'ennuie est que même en maintenant SysVInit ce ne sera pas forcément évident.

        Il peut payer des gens compétents pour le faire. Ce n'est pas une excuse, ça démontre juste que tu veux le beurre, l'argent du beurre et le cul de la crémière, les gens en face ne sont pas tes esclaves, tu as le choix d'apprendre, payer, ou utiliser ce qu'ils proposent, tu as le choix (mais effectivement, pas le choix de ne rien faire tout en demandant tout, c'est con pour toi).

        C'est impressionnant cette capacité à trouver n'importe quelle excuse pour gueuler sans se bouger.

        • [^] # Re: Parallèle avec dragonfly

          Posté par  . Évalué à 1.

          Tu viens de me donner une idée de business:
          payer des dévs pour maintenir systemd sur quelques distros clés, et vendre le résultat à bas coût pour les utilisateurs…

          En plus, si la boite se vautre, je pourrai dire que c'est la faute à linuxfr!! \o/

          Quelqu'un veut me prêter des sous? C'est pour un investissement absolument sans risque, promis!

  • # Grâce au passage à Systemd

    Posté par  . Évalué à 9.

    Je viens de migrer mon ArchLinux vers systemd, et le principal changement que j'ai pu constater, c'est que maintenant je peux enfin activer ou désactiver l'utilisation de ntp depuis le panneau des « Paramètres systèmes » de Gnome.
    Bref, un résultat mineur même à l'échelle du travail réduit que m'a demandé la transition (merci le wiki officiel), mais j'imagine que ça permettra plus de trucs du même genre par la suite, alors pourquoi pas ?
    Aussi, maintenant les petits Ok qui confirment que tout va bien sont à gauche au lieu d'être à droite. Plus pratique pour quel Ok correspond à quel ligne de texte, même si c'était sans doute déjà possible à faire avant me fera-t'on remarquer.

    LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140

  • # Passge salutaire à systemd

    Posté par  . Évalué à 10.

    Depuis 3 mois que je suis passé à systemd, j'ai retrouvé un emploi.
    Les gosses me jettent moins de pierres lorsque je suis dans la rue.
    Les seins de ma femme sont plus gros.

    Par contre il fait de plus en plus froid, c'est très net. C'est la raison pour laquelle je pense revenir à l'ancien système.
    Tant pis pour les nichons.

  • # Et la compatibilité

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

    Ce qui me dérange un peu dans cette histoire, c'est le côté Linux-centric : Linux s'éloigne de plus en plus d'Unix pour devenir un objet à part entière, et il va être de plus en plus difficile de porter les logiciels entre différents systèmes.

    Voilà pour le troll.

    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: Et la compatibilité

      Posté par  . Évalué à 7.

      Tu fais comme pour le milliard d'autres options et de différences qui existent quand tu fais du multiplate-forme. Sois tu utilises le plus petit dénominateur commun des inits (c'est à dire ce que tu faisais avec tes anciens scripts) et là le portage systemd c'est 5 minutes. Soit tu décides de tirer parti des fonctionnalités offertes par une plateforme et tu protèges ce code et prévois un mode dégradé quand les fonctionnalités ne sont pas la.

      Si tu n'arrives pas à faire de mode dégradé c'est à priori signe qu'il manquait quand même quelque chose.

    • [^] # Re: Et la compatibilité

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

      C'est pas un troll, c'est un problème.

      Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

      • [^] # Re: Et la compatibilité

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

        Note que on a le même problème avec bash vs sh. Une très très grande partie des scripts shell qui sont écrits aujourd'hui se croient compatible sh alors que dans les faits, ils ne sont compatibles que bash. Les subilités sont extrèmement pointues, je ne m'en rappelle plus mais dans les faits, on a bloqué à coup de script le shell qu'on utilise (par exemple, dans l'init Sys5).

        Le même problème existe aussi avec gcc. Nombre de logiciels libres écrits en C ou C++ ont en fait vérouillé leur plate-forme indirectement par l'utilisation de constructions supportées uniquement par gcc (au hasard, les macros avec nombre d'arguments variables).

        Bref, plus ça va, plus on se recentre sur des logiciels dominants de l'écosystème. Est-ce un problème à ce point-là ? Je n'en suis pas sur.

        • [^] # Re: Et la compatibilité

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

          Ce n'est pas un problème, il y aura un Linux pour les serveurs et un Linux pour les postes clients.

        • [^] # Re: Et la compatibilité

          Posté par  . Évalué à 3.

          Note que on a le même problème avec bash vs sh. Une très très grande partie des scripts shell qui sont écrits aujourd'hui se croient compatible sh alors que dans les faits, ils ne sont compatibles que bash. Les subilités sont extrèmement pointues, je ne m'en rappelle plus mais dans les faits, on a bloqué à coup de script le shell qu'on utilise (par exemple, dans l'init Sys5).

          L'arrivée de dash et sa popularité font que ce problème précis se réduit. Par contre ce n'est pas parce qu'un script est bourn shell qu'il est POSIX (parce que oui grep, ls, sed, awk, wc, etc ont des extensions gnu ou bsd (en tout cas pas POSIX)).

          Du coup c'est pas un bon exemple pour ta conclusion :

          Bref, plus ça va, plus on se recentre sur des logiciels dominants de l'écosystè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: Et la compatibilité

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

          Nombre de logiciels libres écrits en C ou C++ ont en fait vérouillé leur plate-forme indirectement par l'utilisation de constructions supportées uniquement par gcc (au hasard, les macros avec nombre d'arguments variables).

          Les macros avec nombre d'arguments variables font partie de la norme C99 et de C++11. Seulement, elles ont un problème de conception, le nombre variable est obligatoirement supérieur ou égal à 1 plutôt que 0. D'où une syntaxe GNU qui permet d'éliminer ce problème.

          Mais d'une manière générale, oui, il existe un nombre certains d'extensions, qui parfois rejoignent la norme suivante (comme les commentaires C++ qui étaient une extension puis qui ont rejoint la norme C99).

    • [^] # Re: Et la compatibilité

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

      Linux s'éloigne de plus en plus d'Unix

      Déjà, c'est GNU/Linux, pas Linux.

      Et vu que GNU is not Unix, c'est une bonne chose, non ? :p

      • [^] # Re: Et la compatibilité

        Posté par  . Évalué à 1.

        Sérieusement apprend la signification de ce que tu dis. La lecture de la biographie de Stallman pourrait être instructive quant au sens avec le quel il faut comprendre GNU (bien qu'il s'agisse de culture hacker c'est accessible même à ceux qui ne l'ont pas). :)

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

        • [^] # Re: Et la compatibilité

          Posté par  . Évalué à 5.

          Tu as pas vu le smiley ?

          • [^] # Re: Et la compatibilité

            Posté par  . Évalué à -1.

            Oui mais pour le coup si ça avait était de l'ironie, j'aurais préféré un point d'ironie. C'est plus clair, parce que ce n'est pas parce que c'est dis avec le sourire que c'est de l'ironie. :)

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

            • [^] # Re: Et la compatibilité

              Posté par  . Évalué à 5.

              Je préfère qu'on évite de finir avec des commentaires qui ressemble à des mails de juriste avec un disclamer de 42 paragraphes à la fin pour dire que c'est de l'humour.

              « 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: Et la compatibilité

                Posté par  . Évalué à 0.

                Je me suis mal exprimé. Je dis juste que je n'ai pas saisie si c'était de l'ironie ou simplement dis avec le sourire.

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

Suivre le flux des commentaires

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