Journal Systemd dans Debian

Posté par  . Licence CC By‑SA.
Étiquettes :
12
7
fév.
2013

Bonjour.

Le Fosdem 2013 s'est tenu à Bruxelles il y a quelques jours.

Deux développeurs Debian, Tollef Fog Heen et Michael Biebl, y ont présenté une conférence intitulée « systemd in Debian ». Le diaporama de leur présentation est en ligne ici.

Sa lecture nous apprend que systemd sera proposé dans la prochaine Debian stable (Debian Wheezy) qui devrait sortir dans les prochains mois.

Concernant la version suivante de Debian (Debian Jessie) les deux développeurs écrivent que :

sysvinit will most likely remain the default for most installations.

La phrase est lourde de sous-entendus : si, pour certaines installations de Debian Jessie, sysvinit n'est pas la solution par défaut, on comprend que systemd sera alors installé par défaut.

Le Fosdem 2013 accueillait également une conférence de Lennart Poettering « systemd, Two Years Later ». Elle est téléchargeable sur ce ce lien. Lennart Poettering explique que l'utilisation de systemd rend inutile
la présence de ConsoleKit, sysvinit, initscripts, pm-utils, inetd,
acpid, syslog, watchdog, cgrulesd, cron et atd. En effet, systemd
intègre directement les fonctionnalités de ces composants.

Merci à Thomas Petazzoni pour la correction.

  • # Commentaire supprimé

    Posté par  . Évalué à 10.

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

    • [^] # Re: Excellente nouvelle !

      Posté par  . Évalué à 2.

      Ça dépend chez qui. J'ai eu moins de problèmes sous ArchLinux que sous Fedora. Les deux versions étant à jour.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 4.

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

  • # Mauvaise interprétation

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

    Visiblement, l'auteur du journal n'était pas à la conférence de Lennart à FOSDEM. J'y étais. Donc quand l'auteur de ce journal dit:

    Lennart qualifie d'obsolètes les composants suivant : ConsoleKit, sysvinit, initscripts, pm-utils, inetd, acpid, syslog, watchdog, cgrulesd, cron, atd.

    Alors il interprète mal les slides de Lennart. Dans sa conférence, Lennart dit que systemd rend ces composants obsolètes/inutiles. Si systemd n'est pas utilisé, alors ces composants sont toujours utiles. Évidemment, l'objectif de Lennart est que le plus de monde possible utilise systemd, et que donc ces composants deviennent de moins en moins utiles vu que les fonctionnalités qu'ils proposaient sont intégrés à systemd. Ce qui semble assez logique, et il n'y a pas besoin de crier au loup pour cela.

    Donc il faut comprendre le slide de Lennart comme "systemd rend inutile la présence de ces composants dans le système, car systemd intègre directement les fonctionnalités de ces composants", et non comme "ces composants sont obsolètes".

    • [^] # Re: Mauvaise interprétation

      Posté par  . Évalué à 10.

      Je me permet donc de continuer ta pensée (j'ai regardé la vidéo de la conf):

      l'auteur de ce journal est un plus gros troller que Lennart :)

      • [^] # Re: Mauvaise interprétation

        Posté par  . Évalué à 10.

        Aux alentours de 32:00, Lennart nous sort un troll auquel même l'auteur de ce journal n'aurait pas pensé. Il dit que systemd ne sera pas intégré au kernel mais que le kernel pourrait bien être intégré à systemd. Bon, c'est de l'humour, mais si on s'arrange pour bien sortir la phrase du contexte, la déformer un peu et l'amplifier, on tient un bon sujet de journal ;)

        Tom

    • [^] # Re: Mauvaise interprétation

      Posté par  . Évalué à 5.

      ces composants deviennent de moins en moins utiles vu que les fonctionnalités qu'ils proposaient sont intégrés à systemd

      Je comprends pour la plupart des logiciels mais je suis surpris pour cron et atd. systemd intègre ça ? C'est l'un des trucs que je trouvais sympa dans l'idée d'upstart représenter l'heure et le boot comme 2 évènements du système et de simplement permettre de déclencher des actions lorsqu'ils arrivent.

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

      • [^] # Re: Mauvaise interprétation

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

        systemd intègre des fonctionnalités similaires à celles offertes par crond et atd. Il n'intègre pas crond et atd. Vu ce que fait systemd: réagir aux événements sur les devices (intégration d'udev), réagir aux événements sur les sockets (intégration inetd, socket activations, etc.), ça paraît assez logique qu'il réagisse aux événements "d'heure" et soit capable de déclencher des "choses" à des heures données.

      • [^] # Re: Mauvaise interprétation

        Posté par  . Évalué à 3.

        C'est rendu possible par l'unit 'timer'.
        La manpage decrit comment c'est possible: http://0pointer.de/public/systemd-man/systemd.timer.html et http://0pointer.de/public/systemd-man/systemd.time.html

        Timer files must include a [Timer] section, which carries information about the timer it defines. The options specific to the [Timer] section of timer units are the following:
        […]
        OnCalendar=
        Defines realtime (i.e. wallclock) timers via calendar event expressions. See systemd.time(7) for more information on the syntax of calendar event expressions.

        J'ai cherche s'il y avait des outils convertissant une crontab vers des units 'timer' mais je n'ai pas trouve grand chose. J'imagine que le support de OnCalendar est tout recent, auparavant les timers ne supportaient que des boucles (toutes les heures/jours/semaines a partir du boot…).

        Excusez l'absence d'accents dans mes commentaires, j'habite en Australie et n'ai pas de clavier francais sous la main.

    • [^] # Effectivement, j'ai mal compris.

      Posté par  . Évalué à -2.

      Visiblement, l'auteur du journal n'était pas à la conférence de Lennart à FOSDEM. […] il interprète mal les slides de Lennart.

      Effectivement, je n'ai pas assisté à la conférence, et mon anglais laisse à désirer. Je contacte les bénévoles de Linuxfr pour corriger l'article.

      Désolé pour cette mauvaise interprétation de ma part. 😊

    • [^] # Re: Mauvaise interprétation

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

      alors au début ils vont dire que par exemple cron et les autres outils cités restent maintenus mais qu'il est préconisé de passer par le nouvel outil qu'il est mieux qui est déjà inclus dans systemd, et puis au bout d'un moment les distributions vont dire « oui mais bon maintenant cron c'est obsolète, on ne le fournit plus de base de toute façon c'est libre vous n'avez qu'à l'implémenter vous-même » et on va se retrouver avec des outils comme cron, éprouvé, pratique, qui vont être délaissés à cause de ce systemd.

      Harry Poettering, le magicien qui fait disparaître la philosophie Unix morceau par morceau…

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

      • [^] # Re: Mauvaise interprétation

        Posté par  . Évalué à 0.

        Et cron c'est pas très user-friendly et un peu préhistorique non ?

        Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.

        • [^] # Re: Mauvaise interprétation

          Posté par  . Évalué à 10.

          Ya pas plus user friendly que cron : ne nécessite qu'un éditeur de texte pour être utilisé.

          • [^] # Re: Mauvaise interprétation

            Posté par  . Évalué à 10.

            Ya pas plus useradmin friendly que cron : ne nécessite qu'un éditeur de texte pour être utilisé.

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

            • [^] # Re: Mauvaise interprétation

              Posté par  . Évalué à 9.

              si t'aimes pas le mode texte

            • [^] # Re: Mauvaise interprétation

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

              Je trouve quand même que manipuler cron via des scripts (ce qui est obligatoire dès qu'on veut mettre en place des outils du genre puppet / salt / …) se résume à enchaîner les hacks crades et non fiables.

              Je ne connais pas systemd mais un peu plus launchd, et avoir à poser un fichier (éditable sans problème via des scripts, sans avoir à coder un parseur différent à chaque fois) par commande à lancer est parfois bien pratique comparé à cron.

              • [^] # Re: Mauvaise interprétation

                Posté par  . Évalué à 2.

                Je comprends pas
                je ne connais pas upstart, mais avec cron tu peux bien avoir un fichier par cronjob si tu le veux

                • [^] # Re: Mauvaise interprétation

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

                  Mais seulement pour root, via /etc/cron.d .

                  • [^] # Re: Mauvaise interprétation

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

                    Est-ce la solution recommandée ? Pour moi, on est censé utiliser crontab -e, qui est inutilisable via des scripts.

                    (oui, pour moi la possibilité de configurer grâce à des scripts est vraiment pratique, mais je comprends que ça ne compte pas pour tout le monde)

                    • [^] # Re: Mauvaise interprétation

                      Posté par  . Évalué à 2. Dernière modification le 08 février 2013 à 22:40.

                      Il suffit de modifier le fichier à la mimine puis de faire un SIGHUP vers le démon.
                      Par contre ce n'est pas indiqué dans le man, je trouve que c'est fort regrettable.

                      • [^] # Re: Mauvaise interprétation

                        Posté par  . Évalué à 2.

                        Pas besoin de sighup, regarde mon commentaire au dessus …Quand je ds que crontab est user friendly, on veut pas me croire, mais pourtant les faits sont là.

                    • [^] # Re: Mauvaise interprétation

                      Posté par  . Évalué à 4.

                      crontab >/tmp/fichier_cron

                      Tu fais tes modifs …

                      crontab /tmp/fichier_cron pour prise en compte. Et le tour est joué.

                      Accessoirement, ça permet de revenir en arrière quand tu fais des modifs ….

                      • [^] # Re: Mauvaise interprétation

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

                        ou EDITOR="perl -e + stuff " crontab -e

                        En fait, le coup de faire une modif de contab, c'est de pas avoir de locking. Je suppose qu'il y a peu de risque en pratique, mais je pense que /etc/cron.d est plus sur à ce niveau la.

                        • [^] # Re: Mauvaise interprétation

                          Posté par  . Évalué à 2.

                          Mais pourquoi passer par Perl ? Après tu m'étonnes qu'on va dire que cron n'est pas user friendly …

                      • [^] # Re: Mauvaise interprétation

                        Posté par  . Évalué à 2.

                        Oups, j'mes gouré … :)

                        c'est crontab -l >/tmp/fichier_cron

                        Le reste ne change pas.

                      • [^] # Re: Mauvaise interprétation

                        Posté par  . Évalué à 3.

                        crontab >/tmp/fichier_cron
                        Tu fais tes modifs …
                        crontab /tmp/fichier_cron pour prise en compte. Et le tour est joué.

                        Oh la belle race condition…

                        • [^] # Re: Mauvaise interprétation

                          Posté par  . Évalué à 1.

                          Si pour une raison X ou Y tu passes ton temps à lancer 10000 process qui vont te modifier ta crontab en même temps, c'est que tu as un gros problème.

                          Ensuite si tu n'es pas capable dans ton oganisation de définir une méthode de gestion des cron unique (on parlait ici de l'interfaçage avec d'autres outils de gestion de config par exemple), c'est plus un pb d'organisation qu'un pb d'outil. L'outil doit être capable en amont de gérer les modifications multiples de plusieurs personnes en simultané. Et si tu utilises ce genre d'outil, ce n'est pas non plus pour t'amuser à éditer les fichiers con à la main.

                          • [^] # Re: Mauvaise interprétation

                            Posté par  . Évalué à 5.

                            Effectivement je ne suis capable de rien sauf de prévoir des interfaces qui supportent l'édition concurrente de configurations orthogonales qui n'ont aucune raison d'avoir un impact l'un sur l'autre.

                            Après effectivement on s'en sort très bien avec du scotch et de la ficelle où simplement en misant sur le fait que ça n'arrive jamais. Après tout ca n'arrive jamais hein. D'ailleurs on devrait appliquer ce principe à tout, la concurrence et la cohérence c'est vachement surfait en fait.

          • [^] # Re: Mauvaise interprétation

            Posté par  (site web personnel) . Évalué à 7. Dernière modification le 07 février 2013 à 18:20.

            Ya pas plus user friendly que cron

            Gloups. J'ai failli m'étrangler.

            ne nécessite qu'un éditeur de texte pour être utilisé.

            Et une bonne mémoire.
            Parce qu'avec cette ligne, par exemple :
            23 0-23/2 * * * echo "Tous les jours, à 23mn apres 0h, 2h, 4h…"
            Sans le "echo" je ne comprendrais rien si je n'ai pas regardé l'aide depuis un moment, et je saurai encore moins l'écrire.

            Ya pas plus horrible que cron, plutôt, si il n'est pas accompagné d'une interface utilisateur (et donc : non, il ne faut pas qu'un éditeur de texte, pour que ce soit utilisable, réellement utilisable, par des personnes n'ayant pas que ça à faire que se farcir une doc pour juste mettre une alarme).

            • [^] # Re: Mauvaise interprétation

              Posté par  . Évalué à 4.

              Ya pas plus horrible que cron

              Pas d'accord, il y a vi.

              • [^] # Re: Mauvaise interprétation

                Posté par  . Évalué à 2.

                Na, vi ça va encore (mis à part VIM et ses colorations syntaxiques ou indentations par défaut qui sont assez horribles).
                Emacs dans le genre 'outil pour extra-terrestres ayant 20 doigts par mains" est pas mal dans son genre.

                • [^] # Re: Mauvaise interprétation

                  Posté par  . Évalué à 4.

                  Je vais casser un mythe mais bon, dans 90% des cas, on a besoin que de 2 doigts pour les raccourcis clavier de emacs, soit autant que pour faire un ctrl+c, par exemple. Je ne connais qu'un seul raccourci qui utilise 3 touches, et franchement, on peut s'en passer.

                  Emacs le fait depuis 30 ans.

              • [^] # Re: Mauvaise interprétation

                Posté par  (site web personnel) . Évalué à -2. Dernière modification le 07 février 2013 à 18:41.

                ah… vi… ça fait longtemps que je ne suis pas tombé sur une machine qui n'a pas nano (mon grand sauveur), je l'avais oublié celui-la.
                vi, c'est hors concours dans l'envie qu'il apporte à flinguer une machine qui n'a pas une interface utilisateur compréhensible.

                • [^] # Re: Mauvaise interprétation

                  Posté par  . Évalué à 0.

                  Ya rien de plus user friendly que vi ….

                  .

                  .
                  .

                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .
                  .

                  .
                  (ça c'est pour achever ceux qui ont failli s'étrangler lorsque j'ai parlé du côté user-friendly de cron).

                • [^] # Re: Mauvaise interprétation

                  Posté par  . Évalué à -1.

                  Il y a des gens qui utilisent nano au quotidien?
                  Mais comment fais-tu?

                  Bon, après, j'avoue, je ne connais pas vi, mais vim, et il faut l'admettre: il faut apprendre à s'en servir.
                  D'un autre côté, je n'ai jamais vu de document prétendant qu'il n'y a pas d'apprentissage pour vim, juste affirmant qu'il est plus puissant que la plupart des autres éditeurs de texte.

                  Pour cron user-friendly… j'ai bien rigolé, merci.

                  • [^] # Re: Mauvaise interprétation

                    Posté par  . Évalué à 9.

                    J'utilise nano dès que je dois éditer un fichier texte en ligne de commande, et s'il n'est pas présent je l'installe.

                    J'ai essayé Vim et Emacs, et ce sont des usines à gaz énormes et complexes qui nécessitent d'investir du temps en apprentissage alors que nano est juste intuitif, simple et rapide.

                    En plus, mc utilise nano pour éditer un fichier.

                    • [^] # Re: Mauvaise interprétation

                      Posté par  . Évalué à 5.

                      Je ne doute pas que c'est configurable ou qu'il prend la variable EDITOR

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

                    • [^] # Re: Mauvaise interprétation

                      Posté par  . Évalué à 2.

                      Je ne doute pas que nano soit utilisable. Néanmoins, il est extrêmement simpliste et franchement insuffisant pour le quotidien d'un admin.
                      Quid des remplacements avec regexp, de la coloration syntaxique, des macros, des buffers, des onglets, de la complétion automatique, etc ?

                      Je ne parle que de vim parce que je ne connais pas Emacs, mais si je suis bien d'accord sur la difficulté d'apprentissage, c'est un investissement profitable qui aide à gagner du temps dans la vie de tous les jours en environnement pro.

                      En plus, mc utilise nano pour éditer un fichier.

                      Plus précisément, il utilise son éditeur interne qui est peut-être basé sur nano. Mais sinon, il utilise la variable EDITOR et ça marche très bien.

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

                      • [^] # Re: Mauvaise interprétation

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

                        Je ne doute pas que nano soit utilisable. Néanmoins, il est extrêmement simpliste et franchement insuffisant pour le quotidien d'un admin.
                        Quid des remplacements avec regexp, de la coloration syntaxique, des macros, des buffers, des onglets, de la complétion automatique, etc ?

                        Depuis, on a inventé les interfaces graphiques avec des outils graphiques, nano étant surtout utile pour du dépannage en SSH ou sur la console (bref, des endroits où on évite de mettre des libs plus que nécessaire, donc exit les lib graphiques sur le serveur), donc pas de trucs "avancés" à ce moment la.
                        Du moins pour ceux étant passé au 21ème siècle ;-)

                        • [^] # Re: Mauvaise interprétation

                          Posté par  . Évalué à 3.

                          Si tu as un accès ssh, tu peut même faire un montage sshfs et utiliser un outil graphique.

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

                        • [^] # Re: Mauvaise interprétation

                          Posté par  . Évalué à 2.

                          Je suis d'accord.
                          Je me demande d'ailleurs toujours d'où viens la rumeur qu'il existerait des interfaces graphiques pour vim et emacs?
                          Je pense que gvim n'est qu'un mythe, et que les gens, tels que moi, qui considèrent que les interfaces graphiques ne sont pas forcément si efficaces que ça pour quelqu'un qui dois travailler à longueur de journée avec son clavier et n'a aucun intérêt réel à utiliser la souris si ce n'est atteindre des boutons vitaux qui n'ont pas de raccourcis clavier pratiques sont des abrutis arriérés.

                          Cela dis, dans mon monde d'arriéré, les systèmes d'exploitation n'ont pas besoin de 2Go de RAM, et les utilisateurs sont capables de faire leur travail avec moins de douleurs de poignet (c'est du vécu, avant de revenir aux interfaces plus centrées sur le clavier, mon bras droit me faisait souvent mal. Et je n'ai même pas 30 ans…) et plus de rapidité.

                        • [^] # Re: Mauvaise interprétation

                          Posté par  . Évalué à 4. Dernière modification le 13 février 2013 à 09:24.

                          Je vois pas bien ce que les outils graphiques apportent, niveau efficacité, par rapport à des outils textes (niveau apprentissage/simplicité d’utilisation pour quelqu’un qui édite deux fichiers dans l’année je vois, mais pour l’efficacité, non). L’efficacité, à la base, c’est justement de pouvoir simplement faire gg=G pour indenter tout le fichier plutôt que cliquer sur Édition > Sélectionner tout puis Édition > Formatage > Indentation > Indenter automatiquement.

                          Tant qu’ils offrent les mêmes raccourcis ils peuvent être aussi efficaces on est d’accord, plus efficace je vois vraiment pas comment.

                          De plus, si c’est le mode texte qui te dérange tant que ça, il y a gvim (et il y a la même pour emacs).

                          • [^] # Re: Mauvaise interprétation

                            Posté par  . Évalué à 0.

                            Je suis assez d'accord avec toi : je trouve Windows contre-productif dans l'utilisation que j'en ai tous les jours. Windows n'est pas ue interface pour travailler mais une interface pour bricoler ou jouer.

                      • [^] # Re: Mauvaise interprétation

                        Posté par  . Évalué à 4.

                        Quid des remplacements avec regexp, de la coloration syntaxique, des macros, des buffers, des onglets, de la complétion automatique, etc ?

                        Je ne sais pas pour le reste, mais nano gère la coloration syntaxique.

                        http://wiki.lolica.org/doku.php/articles/nano
                        http://korben.info/rajouter-la-coloration-syntaxique-a-nano.html
                        http://doc.ubuntu-fr.org/nano#ajouter_la_coloration_syntaxique

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

                      • [^] # Re: Mauvaise interprétation

                        Posté par  . Évalué à 2.

                        En plus, mc utilise nano pour éditer un fichier.

                        Plus précisément, il utilise son éditeur interne qui est peut-être basé sur nano. Mais sinon, il utilise la variable EDITOR et ça marche très bien.

                        Non, mc a son propre éditeur interne (qui n'a rien à voir avec nano et qui supporte les expressions rationnelles), mais il a aussi un paramètre (positionné par défaut sur certaines distributions) pour utiliser l'éditeur par défaut du système plutôt que le sien.
                        Et mcedit est également utilisable indépendamment de mc.

            • [^] # Re: Mauvaise interprétation

              Posté par  . Évalué à 7.

              Personnellement je l'utilise sans problème, même s'il faut de temps en temps que je reprenne la doc pour m'assurer de bien faire ce que je veux. après il faut savoir ce que l'on entend par "user friendly". Pour moi un outil "user friendly" est un outil qui ne prend pas des plombes à ce charger, et dans lequel il ne faut pas cliquer 5O fois pour dérouler 13000 fenetres juste pour ajouter ou modifier un paramètre.

              • [^] # Re: Mauvaise interprétation

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

                et dans lequel il ne faut pas cliquer 5O fois pour dérouler 13000 fenetres juste pour ajouter ou modifier un paramètre.

                ben ouvrir un autre terminal, taper man cron, défiler la chose, c'est pas ce qu'il y a de plus "user-friendly" quand même. Je préfère largement un GUI "à la con" qui me fait chier avec 3 fenêtre certes, mais ce GUI est plus rapide que le fichier cron.

                Juste pour ajouter ou modifier un paramètre? Il faut autre chose qu'un éditeur de texte! Ou alors ne pas être utilisateur, mais adorateur du "man cron" et avoir une bonne mémoire, bref, des outils pas forcément des plus disponibles (pas chez moi en tous cas)

                • [^] # Re: Mauvaise interprétation

                  Posté par  . Évalué à 6.

                  Bah pour une utilisation basique, y a pas vraiment besoin de man ni d'une grosse mémoire, une ligne de commentaire suffit dans le fichier cron. Bon après certains cron ont des fonctions spécifique (onboot, etc.) ça peut être intéressant de regarder la référence, mais bon…
                  # m h dom mon dow command
                  minute hour day_of_month month day_of_week sh -c "echo ai-je une bonne mémoire ?"

                • [^] # Re: Mauvaise interprétation

                  Posté par  . Évalué à 9. Dernière modification le 07 février 2013 à 23:26.

                  Je préfère largement un GUI "à la con"
                  et moi une cli "à la cron" …. :)

                  ce GUI est plus rapide que le fichier cron.

                  Pas pour des modifications en masse de plusieurs scripts dont le chemin d'accès aurait changé dans un fichier cron de plusieurs dizaines de lignes (ce qui m'est arivé il n'y a pas tres longtemps d'ailleurs). Si j'avais du modifier les chemins 1 à 1 via GUI, j'y serais encore …

            • [^] # Re: Mauvaise interprétation

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

              Ya pas plus horrible que cron, plutôt, si il n'est pas accompagné d'une interface utilisateur

              Alors qu’avec systemd, bien sûr, ce ne sera pas nécessaire, tout le monde pourra écrire des « timer units » sans jamais consulter la documentation…

              Qu’est-ce que systemd va changer ? Avec cron, les « barbus » éditent leur crontab avec leur vi et leur couteau tandis que les utilisateurs normaux utilisent un « planificateur de tâche » graphique comme ceux fournis avec Gnome ou KDE. C’est dépassé et horrible.

              Avec Systemd, les « barbus » éditeront les fichiers « unit » de systemd avec leur vi et leur couteau tandis que les utilisateurs normaux passeront par un « planificateur de tâche » graphique. Ce sera moderne et user-friendly.

              • [^] # Re: Mauvaise interprétation

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

                Je n'ai pas dit le contraire.
                Je discutais avec totof2000 qui parlais au départ que d'éditeur de texte.
                avec un éditeur de texte, ça ne sera pas mieux.
                Mais il y a d'autres outils (les interface utilisateur qui sont "user-friendly", les fichiers texte c'est pour le débuguage, le scripting et les masochistes :) )

                • [^] # Re: Mauvaise interprétation

                  Posté par  . Évalué à 4. Dernière modification le 07 février 2013 à 22:23.

                  les fichiers texte c'est pour le débuguage, le scripting et les masochistes :) )

                  Pas d'accord … Il y a bien des fois ou je peste contre des interfaces graphiques censées être "user friendly" mais qui ne le sont pas parce que la logique de l'interface est mal pensée (et bien souvent elle ne peut pas être pensée autrement), alors qu'un bête fichier texte permet d'avoir une vue d'ensemble et de naviguer dans le fichier sans se prendre la tête à cliquer dans tous les sens : au pire j'ouvre deux fenetres et visualise le fichier si une partie de celui-ci nécessite de comprendre une autre partie pas visible à l'écran.

                  Dans un GUI ce n'est pas toujours possible d'ouvrir plusieurs instances de la même fenetre mais qui afficherait des paramètres situés à des endroits différents (parfois possible avec des interfaces web avec les onglets mais pas toujours).

                  Alors attention, ne me faites pas dire ce que je n'ai pas dit : la GUI est pratique dans certains cas (notamment lorsqu'on ne sait pas trop ce que l'n fait), mais dans eaucoup de cas celle-ci n'est pas appropriée.

            • [^] # Re: Mauvaise interprétation

              Posté par  . Évalué à 5.

              Tu sais, tu peux mettre des commentaires dans ta crontab…
              Ca evite le besoin de mémoire.

              Et a part ca, c'est quand meme pas tous les jours qu'on a besoin de faire un truc d'assez exotique pour avoir besoin de ressortir la doc

              • [^] # Re: Mauvaise interprétation

                Posté par  . Évalué à 4.

                Et a part ca, c'est quand meme pas tous les jours qu'on a besoin de faire un truc d'assez exotique pour avoir besoin de ressortir la doc

                Justement, le problème est qu'il n'y a pas besoin d'avoir à faire un truc exotique pour devoir lire la doc. Chaque fois que je dois lire ou editer quelquechose dans un crontab j'ouvre la page man pour verifier l'ordre et le nombre de champs. C'est pas ce que j'appelle user-friendly.

                • [^] # Re: Mauvaise interprétation

                  Posté par  . Évalué à 2.

                  Chaque fois que je dois lire ou editer quelquechose dans un crontab j'ouvre la page man pour verifier l'ordre et le nombre de champs.

                  Commentes correctement UNE ligne de ta crontab, et tu connaitras l'ordre des champs…

                  • [^] # Re: Mauvaise interprétation

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

                    C'est connu, on est maître sur tous les serveurs du monde et on fait comme il faut les commentaires sur tous les serveurs du monde.

                    En pratique, on arrive sur des serveurs pas fait par nous.
                    Non, c'est juste que pour des trucs simples, on se tape le man en permanence, sauf exception, c'est tout.

                    • [^] # Re: Mauvaise interprétation

                      Posté par  . Évalué à 4.

                      Personnellement, ce que j'ai remarqué là ou je suis passé, c'est que les cas tordus d'utilisation de cron nécessitant de lire la doc sont des cas ou un ordonnanceur plus évolué ferait mieux l'affaire.

                      Il ne faut pas oublier que cron n'est fait à la base que pour déclencher des taches périodiques avec ordonnancement simple.

                      • [^] # Re: Mauvaise interprétation

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

                        De toute façon c'est rare que l'on arrive à tout se souvenir. Les aides mémoires, c'est aussi fait pour ça, et ça tombe bien, comme j'ai tout mis sur une même page, je n'ai pas besoin d'ouvrir des quantités de man et ça me sert tout le temps.

                        Au pire des cas, dans la plupart des distributions, la syntaxe est rappelée au début du fichier de configuration : 

                        # For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
#
# For more information see the manual pages of crontab(5) and cron(8)
#
# m h  dom mon dow   command

                        je trouve ça personnellement plus pratique que le planificateur de tâches windows par exemple.

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

                  • [^] # Re: Mauvaise interprétation

                    Posté par  . Évalué à 5.

                    Commentes correctement UNE ligne de ta crontab, et tu connaitras l'ordre des champs…

                    Même pas la peine : c'est déjà fait d'origine sur Debian et ses dérivées, sur Red Hat, et dans le fichier vide contenu dans les sources de cron. J'imagine que c'est en fait le cas dans toutes les distributions.

                    • [^] # Re: Mauvaise interprétation

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

                      C'est le cas car tout le monde est passé à cronie, qui a pris le patch debian sur le sujet.

                      IE, la version cron d'avant ( ie, vixie cron ), non maintenu, n'a jamais fait ça de base.

                      • [^] # Re: Mauvaise interprétation

                        Posté par  . Évalué à 2.

                        tout le monde est passé à cronie

                        Pas Debian en tout cas.

                        la version cron d'avant ( ie, vixie cron ), non maintenu, n'a jamais fait ça de base

                        Exact : elle ne contient pas de fichier crontab, je viens de vérifier.
                        Ça c'est crétin. C'est un source qui date de 1994. Autres mœurs.

          • [^] # Re: Mauvaise interprétation

            Posté par  . Évalué à 2.

            Euh, suffit juste de jouer avec ton éditeur de texte et d'un lien symbolique (ou pas si t'es crade) pour activer une unité systemd (timer ou autre)

      • [^] # Re: Mauvaise interprétation

        Posté par  . Évalué à 3.

        Tu sais, FreeBSD, c'est bien aussi. Et si c'est trop compliqué pour toi, essaie PC-BSD.

      • [^] # Re: Mauvaise interprétation

        Posté par  . Évalué à 6.

        alors au début ils vont dire que par exemple cron et les autres outils cités restent maintenus mais qu'il est préconisé de passer par le nouvel outil qu'il est mieux qui est déjà inclus dans systemd, et puis au bout d'un moment les distributions vont dire « oui mais bon maintenant cron c'est obsolète, on ne le fournit plus de base de toute façon c'est libre vous n'avez qu'à l'implémenter vous-même » et on va se retrouver avec des outils comme cron, éprouvé, pratique, qui vont être délaissés à cause de ce systemd.

        cron et les autres outils seront maintenus tant qu'il y aura quelqu'un pour les maintenir. Si un jour plus personne ne veut s'en charger c'est quand meme pas la faute de Lennart ?

      • [^] # Re: Mauvaise interprétation

        Posté par  . Évalué à 7.

        Dans la vidéo, lorsqu'il parle de cron, Lennart précise bien qu'il considère qu'il n'est pas entièrement rendu obsolète par systemd. systemd serait plus expressif et plus simple, mais cron garde l'avantage de permettre un crontab par utilisateur.

        • [^] # Re: Mauvaise interprétation

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

          mais cron garde l'avantage de permettre un crontab par utilisateur.

          Pour combien de temps ?

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

    • [^] # Re: Mauvaise interprétation

      Posté par  . Évalué à 5.

      Dans sa conférence, Lennart dit que systemd rend ces composants obsolètes/inutiles.

      Je me suis récemment retrouvé avec SystemD sur un portable. Et effectivement, il intègre beaucoup de choses (gestion des évènements ACPI de base, genre fermeture clapet, bouton d'arrêt). Ça m'avait d'ailleurs pas mal surpris de retrouver ça là-dedans.
      Par contre, ça reste de la gestion de base : pas de détection branché/débranché (histoire d'ajuster les paramètres de conso, par exemple) ou autre.
      On ne peut pas non plus changer le mode d'hibernation. Par défaut, l'hibernation est en mode platform (cf. /sys/power/disk), qui dans mon cas ne marche pas. Autant, avec PM on peut assez facilement passer ça en mode shutdown, c'est une variable à changer.
      En utilisant du tout SystemD, c'est impossible, il faut au moins faire intervenir un script externe (en gros : retour à PM) :
      https://bugs.freedesktop.org/show_bug.cgi?id=58679
      Et ça n'est pas prêt de changer, vu que Lennart considère que ce n'est pas à l'userspace de faire un truc qui devrait être géré par le kernel.

      Bref, ça rend acpid/PM/autres moins utiles. Mais inutiles, non, clairement.

      • [^] # Re: Mauvaise interprétation

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

        Dans le même ordre d’idée, systemd ne semble pas pouvoir remplacer complètement cron, la syntaxe des « timer units » n’étant pas aussi expressive qu’une crontab :

        Timer units currently have no support for calendar times (i.e. cannot be used to spawn things "at 6 am every Monday", but can do "run this every 7 days"), but for the usual /etc/cron.daily/, /etc/cron.weekly/, … should be good enough, if the time of day of the execution doesn't matter (just add four small service and timer units for supporting these dirs. Eventually we might support these out of the box, but until then, just write your own scriplets for this).

        — systemd Optimizations

        • [^] # Re: Mauvaise interprétation

          Posté par  . Évalué à 2.

          C'est faux, voir mon commentaire precedent: http://linuxfr.org/nodes/97330/comments/1429417
          L'option OnCalendar propose justement les calendar times:

          OnCalendar=
          Defines realtime (i.e. wallclock) timers via calendar event expressions. See systemd.time(7) for more information on the syntax of calendar event expressions.

          Tu peux faire des trucs comme ca:

          Thu,Fri 2012-*-1,5 11:12:13
          Mon-Thu,Sat,Sun --* 00:00:00
          Mon,Fri --01,02,03 *:30:45

          (extraits des manpages que j'ai citees precedemment)
          La page dont tu parles n'a pas ete mise a jour.

          Excusez l'absence d'accents dans mes commentaires, j'habite en Australie et n'ai pas de clavier francais sous la main.

      • [^] # Re: Mauvaise interprétation

        Posté par  . Évalué à 10.

        J'étais présent à la conférence (et même eu l'occasion de papoter avec lui et Kay), et je vous conseille de regarder la vidéo parce qu'il explique très clairement son point de vue. L'idée est que bon nombre de ces utilitaires (du moins ceux qui interagissent avec le noyau) ont pas mal de code dupliqué, sont très petits et mal maintenu. L'idée est de centraliser le développement de ses utilitaires en un endroit pour avoir un ensemble cohérent (et non pas monolithique Cf. mon dernier nourjal). Il a même souligné que c'était la pratique BSD (tout ce qui a trait à l'OS est développé dans le même gestionnaire de sources), bien que ça ne soit guère possible de le faire avec Linux qui propose différentes surcouches.
        systemd est avant un framework pour construire l'ensemble des utilitaires nécessaires pour former un système d'exploitation cohérent avec le noyau Linux, il n'impose pas le remplacement des composants précédemment cités, vous pouvez les utilisez en // de systemd, vous ne bénéficierez pas des avancées fournies par le projet.

        Ceux qui ont été présent à la conférence de Vincent Untz sur GNOME, on même pu entendre Bastien Nocera expliquait comment le passage à systemd a pu résoudre certains bugs complexes liés au matériel et virer du code non maintenu (je précise: systemd n'est pas un composant obligatoire pour utiliser GNOME, certaines fonctionnalités annexes ne sont plus accessibles tout simplement). Contribution accepted.

        La conférence était claire, limpide et s'est très bien passé malgré un public pas forcément acquis (je m'attendais même à un clash qui n'a pas eu lieu)

  • # Je ne comprends pas ces sous-entendus

    Posté par  . Évalué à 10.

    Concernant la version suivante de Debian (Debian Jessie) les deux développeurs écrivent que :

    sysvinit will most likely remain the default for most installations.

    La phrase est lourde de sous-entendus : si, pour certaines installations de Debian Jessie, sysvinit n'est pas la solution par défaut, on comprend que systemd sera alors installé par défaut.

    Ah bon ? Moi je lis que le défaut sera sysvinit sauf cas exceptionnels.

    • [^] # Re: Je ne comprends pas ces sous-entendus

      Posté par  . Évalué à 10.

      ca va, y a pas que moi qui l'ait comprise dans ce sens là aussi

      • [^] # Re: Je ne comprends pas ces sous-entendus

        Posté par  . Évalué à 2.

        Quand je vois ce qui se dis au sujet de systemd sur la ml debian, je doute que les développeurs n'imposent un tel changement.
        De toute façon, ça ne risque pas, puisque, pour rappel, debian supporte aussi un kernel bsd, et comme tout un chacun ne cesse de le rappeler, systemd n'est pas portable.

        Je pense juste qu'il y aura le choix à l'installation, quand on prend les questions en mode expert, chose qui n'est pas encore le cas à l'heure actuelle, sysvinit étant un paquet vital, contrairement à systemd.
        Au hasard, il vont faire un paquet vital qui dépende sois de l'un, soit de l'autre, histoire que l'on ne sois pas obligé de taper "Oui, je suis parfaitement conscient que je risque de casser le système" quand on installe systemd et supprime sysvinit, à la virgule près? (Enfin, je dis à la virgule près, parce que le moindre caractère force à retaper, mais je n'ai pas cité le message exact :) )

        Perso, je suis plutôt favorable à l'utilisation de systemd, surtout intégré par les dev de Debian qui ont tendance à faire des config par défaut très propres et très clairement documentées. Même celle de vim est lisible, à défaut d'être exhaustive dans ses commentaires.
        Je me souviens avoir testé, en supprimant sysvinit, rien n'a cassé. Je suis revenu à sysvinit pour la simple raison que ça n'avais rien apporté à mes yeux à ce moment (il faut dire que les scripts d'init étaient toujours utilisés donc…), et que depuis j'ai cassé mon système, alors je n'ai pas refait la bascule.

        • [^] # Re: Je ne comprends pas ces sous-entendus

          Posté par  . Évalué à 3.

          De toute façon, ça ne risque pas, puisque, pour rappel, debian supporte aussi un kernel bsd, et comme tout un chacun ne cesse de le rappeler, systemd n'est pas portable.

          Rien n'oblige l'init par défaut à être le même pour toutes les archis.
          Par exemple, le noyau par défaut n'est pas le même pour les archis amd64 et kfreebsd.

          • [^] # Re: Je ne comprends pas ces sous-entendus

            Posté par  . Évalué à 1.

            Avoir les mêmes paquets partout simplifie les tests (il ne faut pas croire que tous les paquets Debian sont tous testé de la même façon) et la documentation.

            « 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: Je ne comprends pas ces sous-entendus

            Posté par  . Évalué à 2.

            Rien n'oblige l'init par défaut à être le même pour toutes les archis.

            Ouai mais il faut se palucher dans les paquets le script sysvinit et le fichier ini systemd. Le programme de conversion ini systemd vers les scripts d'init n'est pas encore terminé, je crois.

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

  • # Ah l'anglais...

    Posté par  (site web personnel) . Évalué à 10. Dernière modification le 07 février 2013 à 15:23.

    Ce type est le plus monstrueux troll de l'univers.

    Surtout quand on lui fait dire ce qu'il ne dit pas, par le biais de mauvaise traductions.
    Bon, je vais essayer de faire mieux (même si je ne suis pas très doué).
    - "Most" : la plupart des. Différent de "certaines". Donc pas par défaut.
    - "Obsoletes" (je pense qu'il faut bien noter le "s" à la fin) : rend obsolète (sous-entendu : si tu installes son logiciel, et non pas de manière générale). Ce qui calme le troll de suite.
    2 lignes, deux changements de ton suivant le traduction.

    Donc sauf erreur de traduction de ma part (je suis preneur de correction pour améliorer mon anglais), le trolleur sembler être Sylvain Blandel plus que Lennart Poettering.

    • [^] # Re: Ah l'anglais...

      Posté par  . Évalué à 3.

      Dire que systemd est par defaut sur la plupart des installations, revient au meme que dire qu'il n'est pas pas defaut sur certaines installations.

      Par contre, je le comprends egalement dans le sens: sysinit restera par defaut, c'est-a-dire installe sur la plupart des installations. J'imagine mal Debian choisir une certaine architecture qui aurait systemd par defaut alors que la majorite garde sysinit.

      Excusez l'absence d'accents dans mes commentaires, j'habite en Australie et n'ai pas de clavier francais sous la main.

      • [^] # Re: Ah l'anglais...

        Posté par  . Évalué à 5.

        Dire que systemd est par defaut sur la plupart des installations, revient au meme que dire qu'il n'est pas pas defaut sur certaines installations.

        Par exemple les installations pour lesquelles on choisit expressément systemd ou un composant qui le necessite ?

        • [^] # Re: Ah l'anglais...

          Posté par  . Évalué à 3.

          Non quand on choisit expressément un composant, ça n'est plus une installation par défaut. Un composant qui le nécessite ok. Je pense qu'ils font référence a un élément majeur, comme un bureau par exemple…

    • [^] # Re: Ah l'anglais...

      Posté par  . Évalué à -1.

      (j'ai contacté les modérateurs pour faire corriger la partie « Lennart qualifie d'obsolètes les composants suivant … »)

      Pour la phrase :

      sysvinit will most likely remain the default for most installations.

      (attention, mon anglais n'est pas terrible) Je la traduirais par « Sysvinit restera certainement le choix par défaut pour la plupart des installations ». J'en déduis qu'il existera quelques installations où sysvinit ne sera pas utilisé par défaut. C'est-à-dire que, pour quelques installations de Debian Jessie, c'est systemd qui sera utilisé par défaut.

      J'espère que les ambiguïtés seront levées lorsque cette conférence sera disponible en ligne. Si vous êtes meilleur que moi en anglais 😄 vous pouvez contacter les auteurs de la conférence, Tollef Fog Heen et Michael Biebl. Leurs adresses de courriel figurent en haut à gauche de leurs pages respectives.

      • [^] # Re: Ah l'anglais...

        Posté par  . Évalué à 1.

        J'en déduis qu'il existera quelques installations où sysvinit ne sera pas utilisé par défaut.

        J'imagine (imagination => pas de preuves) que ce sera exactement de la même façon qui fait que gnome n'est pas utilisé par défaut sur 2 CDs n°1 alternatifs, l'un étant dédié à KDE, l'autre à XFCE/LXDE.

        Ce qui implique que les gens qui auront systemd par défaut, auront choisie l'image avec systemd par défaut. Et les images avec KDE/XFCE/LXDE par défaut ne sont pas spécialement mises en avant, et sont donc certainement les moins téléchargées.
        Si on applique la même logique, excepté un nombre de "CD n°1" qui explose, il y aura effectivement un petit nombre d'installations par défaut qui auront systemd.

        Rien de choquant, et je préfère de toute façon que mon OS me donne le choix.

  • # Gnome dans debian

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

    Certains composants de gnome devenant dépendants de systemd, debian forcément fait face à cette question.

    Voir aussi http://np237.livejournal.com/33660.html.

    • [^] # Re: Gnome dans debian

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

      l'autre solution étant de lourder Gnome…

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

    • [^] # Re: Gnome dans debian

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

      Il suffit de virer gnome!

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

      • [^] # Re: Gnome dans debian

        Posté par  . Évalué à 10.

        en meme temps "vider un gnome" pour "remplir un troll"

        fallait oser…

    • [^] # Re: Gnome dans debian

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

      Certains composants de gnome devenant dépendants de systemd

      Tu veux dire certains composants de gnome dépendent sur une API DBUS documentée et ré-implémentable par d'autre programme ?

      https://mail.gnome.org/archives/desktop-devel-list/2012-October/msg00062.html

      • [^] # Re: Gnome dans debian

        Posté par  . Évalué à 4.

        Tu veux dire […] une API DBUS documentée et ré-implémentable par d'autre programme ?

        Tu veux dire comme l’API win32, ou toutes les autres API du monde ?

    • [^] # Re: Gnome dans debian

      Posté par  . Évalué à 5.

      Vincent Untz l'a évoqué dans sa conférence, il est acquis que systemd sera une dépendance de GNOME uniquement pour les fonctionnalités non essentielles au bon fonctionnement de GNOME.
      1. tu as systemd, tu as la full GNOME experience
      2. tu n'as pas systemd, certaines fonctionnalités secondaires seront désactivées. La plupart repose sur du code non maintenu, et le projet GNOME acceptera tout patch pour les rétablir (y compris basé sur le code précédemment viré)
      La réalité est que 99.5% des contributeurs GNOME sont sous Linux, le problème est qu'il y a un manque cruel de développeurs sous les plateformes moins favorisées comme les *BSD. La question se poserait tôt ou tard.

      • [^] # Re: Gnome dans debian

        Posté par  . Évalué à 10.

        D'un autre côté, avoir un bureau Gnome avec des fonctions manquantes, c'est un peu être en avance sur la prochaine version de Gnome, donc de quoi se plaint-on?

        ------------> [ ]

  • # Intégration de LXC

    Posté par  . Évalué à 10.

    Moi, ce qui m'a impressionné c'est que systemd qui s'appuie à fond sur cgroups est passé à la vitesse supérieure en intégrant les LinuX Containers. On peut déjà limiter les ressources à un ensemble de processus créés par un service systemd très finement (essayer de le faire avec sysvinit …, lors de la conférence, Lennart a donné le très bon exemple d'apache/php/mysql), mais on pourra à l'avenir confiner un processus.

    Une feature F19 consiste à poursuivre l'effort sur systemd-nspawn (qui permet de lancer un conteneur LXC) afin d'arriver à avoir l'équivalent des zones Solaris à terme. Les conteneurs serait même activable via socket, on envisage même d'utiliser ça pour faire des clouds haute-densité (autre feature F19 dont l'implémentation dépendra de l'avancée de celle-ci) [1]
    https://fedoraproject.org/wiki/Features/SystemdLightweightContainers
    https://fedoraproject.org/wiki/Features/High_Availability_Container_Resources

    [1] je précise que la liste des features pour F19 est encore en cours de discussion, et que celles-ci n'ont pas encore été approuvées même si il y a de fortes chances qu'elles soient acceptées.
    https://fedoraproject.org/wiki/Releases/19/FeatureList

  • # Kernels compatible ?

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

    systemd n'est pas compatible avec freebsd, c'est à cause du userland ou du kernel ?

    En gros il se passe quoi pour debian/hurd et debian kfreebsd ?

    • [^] # Re: Kernels compatible ?

      Posté par  . Évalué à 10.

      systemd s'appuie sur des APIs spécifiques au noyau Linux (cgroups, signalfd, timerfd, fanotify etc…)
      Ça n'a jamais posé problème que l'ensemble des fonctionnalités proposés par systemd ne soit pas portable car c'est déjà le cas en pratique !
      Ce qui dérange certains, c'est la dépendance à l'API systemd par les bureaux, compréhensible du fait qu'historiquement, ces API étaient mal documentées donc difficilement réimplémentable et pensées linux-only (alsa, udev etc..).
      Néanmoins, systemd a l'avantage par rapport à ses prédécesseurs d'être extrêmement bien documenté, d'avoir stabilisé son API externe (qui peut être réimplémenté indépendemment de systemd). Il y a même un tableau résumant la stabilité et la portabilité des différentes API de systemd

      Il y a très clairement un terrain d'entente possible, sachant qu'au final, ce que demande les communautés BSD et Linux/systemd sont au final assez proches. La difficulté est surtout d'arriver à trouver un processus pour formaliser ces APIs externes (qui au final simplifie la maintenance des projets).

Suivre le flux des commentaires

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