Debian Jessie, 1 an plus tard

Posté par (page perso) . Édité par Benoît Sibaud, tankey, idéefixe et Nÿco. Modéré par Pierre Jarillon. Licence CC by-sa
44
8
juin
2016
Debian

Debian GNU/Linux 8 (Jessie) est sortie le 25 avril 2015 et plusieurs mises à jour ont ensuite été publiées. La dernière en date constituant Debian GNU/Linux 8.5 vient d'être annoncée samedi 4 juin (de nouvelles images d'installation sont disponibles).

À noter aussi la sortie de Debian GNU/Linux 7.11 Wheezy, qui sera la dernière des versions numérotées 7.x (le support longue durée se poursuit jusqu'en mai 2018 pour les architectures i386, amd64, armel et armhf ; le support normal s'est arrêté le 25 avril 2016).

En outre, une nouvelle édition du livre « Le cahier de l'administrateur Debian » vient d'être publiée par Eyrolles. Le contenu est libre et librement accessible sur le site idoine. Avec ses 538 pages, l'ouvrage pèse maintenant plus d'un kilogramme et sa nouvelle couverture, aussi énigmatique qu’hypnotisante, vous assurera l'admiration de vos collègues si vous l'exposez dans un coin de votre bureau.

Quant à ceux qui seraient à la recherche d'un DVD de Debian, ils peuvent farfouiller dans le rayon informatique de leur marchand de journaux, avec un peu de chance ils trouveront Linux Identity Set n°38 qui en contient un, accompagné de 42 pages.

  • # Support pour Wheezy

    Posté par (page perso) . Évalué à 10. Dernière modification le 08/06/16 à 10:38.

    Une petite précision, le support normal de Wheezy, en accord avec la politique de maintenance des versions stables de Debian, s'est arrêté le 25 avril 2016.

    La responsabilité du support a alors été transférée à l'équipe de Support Long Terme qui est une initiative récente et qui nécessite des fonds pour rémunérer les développeurs chargés du travail de support des très anciennes versions des logiciels qui constituent Wheezy. Le besoin d'un support long terme est avant tout un besoin des entreprises. Les dons sont donc les bienvenus pour maintenir le support long-terme des anciennes versions stables de Debian.

  • # Le support armel/armhf est confirmé pour Debian 7 LTS

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

  • # Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?

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

    Le passage à systemd a fait énormément de bruit à la sortie de Debian 8. Maintenant qu'on a un peu de recul, c'est l'occasion de jeter un coup d'œil dans le rétroviseur. Au final, sur des environnements stables et suite à ce passage de Debian 8 à systemd :

    • Est-ce que certains sont passés de Debian 7 à une autre distribution ? (si oui laquelle, Devuan n'étant pas encore stable) ?
    • Est-ce que certains sont passés à Debian 8 mais avec l'init SystemV ?
    • Est-ce que certains refusaient systemd mais finalement se sont laissés convaincre, et pourquoi ?

    Ceci ne permet évidement pas de faire un sondage fiable, mais si tout le monde joue le jeu, c'est l'occasion d'avoir une idée à la fois de la fuite provoquée par ce changement ; ainsi que du rapport bruit / actions sur des sujets aussi polémiques.

    La connaissance libre : https://zestedesavoir.com

    • [^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?

      Posté par . Évalué à 9.

      Pour ma part, je suis passé en Debian avec systemd.
      Et bien, c'est convainquant et extrêmement rapide!

    • [^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?

      Posté par . Évalué à 10.

      Ceci ne permet évidement pas de faire un sondage fiable, mais si tout le monde joue le jeu, c'est l'occasion d'avoir une idée à la fois de la fuite provoquée par ce changement ; ainsi que du rapport bruit / actions sur des sujets aussi polémiques.

      popcon doit pouvoir t'aider pour ça.

      Perso j'étais sous Debian, je reste sous Debian parce que je sais me débrouiller avec et je me fous de l'init que j'ai. Je faisais mes skeletons avant je fais mes units maintenant.

      Si systemd est discutable, affirmer qu'il est cataclysmique c'est juste rigolo. GnomeShell ou KDE4 ont représenté un changement beaucoup plus violent pour l'utilisateur final que le fait que screen ou tmux fonctionnent pas dans la configuration par défaut de systemd.

      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 an après, qui a changé l'init par défaut ou est passé à une autre distribution ?

        Posté par . Évalué à 10.

        En effet.

        Après, la migration n’est pas sans poser quelques problèmes, mais évidemment pas ceux auxquels on s’attendait ou ceux sur lesquels les détracteurs de systemd s’épanchaient, mais plutôt sur quelques détails. En ce qui me concerne :

        • si on a plusieurs volumes chiffrés, le démarrage en parallèle fait qu’on manque le prompt (on vit très bien avec, mais c’est pas super clair pour l’utilisateur)
        • un cas de deadlock au démarrage (ça, c’est vraiment embêtant) à cause d’un script d’init perso qui foutait la grouille dans le démarrage de systemd (et qui me fait sincèrement douter de la robustesse de certains choix).
        • certains trucs continuent de ne pas marcher correctement, systemd ou pas (par exemple, faire cohabiter un shorewall et un vpn openvpn)

        À côté de ça, j’en ai vu les bénéfices côté utilisateur : le déploiement d’un service est juste plusieurs ordres de grandeur plus simple à configurer avec les fichiers unit de systemd. Rien que pour ça et le temps de boot, ça valait le coup.

        Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

    • [^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?

      Posté par . Évalué à 2.

      Utilisateur fidèle de Debian GNU/Linux testing, je me suis finalement laissé convaincre par les partisans de systemd qui m'ont dit que sysvinit c'était de la merde et que mon desktop devrait booter en moins de 10 secondes pour increaser ma productivity.

      Je suis donc passé à openrc, qui m'a permis de booter mon desktop en moins de 10 secondes, et ce sans rien péter ! Merci les partisans de systemd ! \o/

      splash!

    • [^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?

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

      Est-ce que certains sont passés à Debian 8 mais avec l'init SystemV ?

      Moi.

      À noter que sur d'autres systèmes, je suis aussi passé à Debian 8 avec systemd sans problèmes particuliers.

    • [^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?

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

      Passé en Debian avec systemd

      Pour l'instant un seul problème et beaucoup de cheveux en moins.

      Le fichier /etc/default/bind9 existe toujours mais (surprise) ne sert à rien, il faut modifier
      /etc/systemd/system/multi-user.target.wants/bind9.service.

      Tout le monde a un cerveau. Mais peu de gens le savent.

    • [^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?

      Posté par . Évalué à 8.

      Pour ma part j'étais passé à Fedora au moment d'installer ma dernière machine parce que j'avais envie de tester systemd pour voir comment c'était en pratique. Je trouve que pour l'utilisateur final l'impact principal c'est plutôt de devoir passer par systemctl (et journald) pour des tâches qui utilisaient d'autres choses avant (/etc/init.d/…), comme relancer un service ou quelque chose comme ça.

      Je trouve toujours que le modèle et l'histoire de Debian sont des références dans le monde du libre, et je pense que je repasserai à Debian à ma prochaine machine. Je me retrouve mieux dans son mode de développement très communautaire—même si je ne me suis moi-même jamais impliqué dans le packaging ou l'évolution de la distribution.

      (Dans une certaine mesure c'est un peu comme Firefox: sur certains points techniques Chromium a l'avantage (en particulier le modèle de sécurité est bien mieux pensé), mais je me retrouve mieux dans les efforts de développement ouverts à la communauté de Mozilla (même s'ils ne s'en sortent pas toujours bien, on a toujours le Pocket un peu en travers de la gorge, etc.), donc à défaut de pouvoir soutenir par une contribution active je l'utilise et j'en parle positive autour de moi.)

      Avec la place de plus en plus importante que prennent les gestionnaires de paquets non-distribution (j'utilise opam pour OCaml par exemple), je défère surtout à ma distribution les parties "chiantes" (les trucs que je veux avoir maintenu et sécurisé, mais pour laquelle à part ça je me moque assez de la version disponible etc.) de mon userland, les trucs qui justent marchent et dont je n'ai pas l'intention de suivre l'upstream. Je pense que mes prochaines aventures d'administration système iront dans le sens de Nix (par dessus Fedora ou Debian), et QubesOS, m'éloignant de plus en plus des distributions classiques.

    • [^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?

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

      Dans un contexte professionnel, le passage de plusieurs centaines de serveurs de wheezy à Jessie s'est globalement plutot bien passé. Nous trouvons (mes collegues et moi) que l'intégration de systemd dans debian est quand meme très largement perfectible. L'utilisation de systemd ne pose pas de soucis particulier, néanmoins nous avons été confronté à quelques bug rigolos (le dernier en date étant celui de systemd-login qui hang après un update). Mais surtout c'est l'adoption des mainteneurs de paquets qui n'est pas encore au niveau. Des paquets aussi exotiques que snmpd, ntp utilisent encore les scripts d'inits… Et quand l'intégration est faite, elle est parfois faite a minima, j'ai l'exemple de redis qui utilise un unitfile, mais qui ignore bien gentiment le /etc/default/redis.
      A noter que quelques refractaires ont tenté de resister (installer sysv-core) mais ce n'est pas viable sur le long terme :p

    • [^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?

      Posté par . Évalué à 10.

      En tant qu'utilisateur de base de Debian (depuis potato quand même), j'ai laissé faire l'installation de systemd quand ça s'est présenté. Depuis, bah ça marche pas plus mal que si c'était pire, pas moins bien qu'avant, pas mieux non plus. Il y a quelques détails qui me chagrinent un peu.

      Au démarrage, on ne voit plus les logs du kernel et les services qui démarrent. Oui, moi j'aimais bien voir tout ça, notamment les services, parce que des fois, j'installais un truc pour tester et du coup, je voyais le service au démarrage et je me souvenais qu'il fallait que je désinstalle le bouzin. Maintenant, je ne vois plus rien. J'ai essayé de modifier l'affichage de systemd mais là, on voyait beaucoup trop de choses et donc, rien de pertinent. Dans le même ordre d'idée, on ne voit plus la barre de progression de fsck, et comme ça prend un peu des plombes parfois et qu'on a aucun retour, c'est très agaçant. Enfin, il y a tous ces petits trucs à la con du genre la commande halt qui n'arrête plus complètement la machine (il faut utiliser poweroff), et l'attente d'1m30 quand un service récalcitrant (dont on n'aura pas le nom évidemment) ne s'arrête pas correctement.

      Bref, je trouve qu'on perd un peu en maîtrise quand on est simple utilisateur observateur de son système comme moi. Il y a beaucoup de choses qui sont cachées. Pour la vitesse, je n'ai pas remarqué que ça allait particulièrement plus vite ou moins vite.

    • [^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?

      Posté par . Évalué à 4.

      Je suis toujours sous Debian 7 avec un disque mécanique (7200tpm) et Gnome Shell, je suis dans les 15-20 secondes au boot mais vu que je met toujours mon ordi en veille bah, c'est plus de l'ordre de 3 secondes.

      Néanmoins, j'ai systemd dans mes VMs, les scripts units, bof . J'avoue que la sortie statut et le rendu des logs sont sympas. Après, c'est tout aussi faisable avec l'avant systemd, c'est juste une question de convention et au pire du niveau du system administrateur qui est très fluctuant… non Michu ne crée pas de services.

      Bref, systemd est là, c'est fait. :/

    • [^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?

      Posté par . Évalué à 2.

      Pour mon utilisation, je n'y prête même pas attention. J'éteins machinalement plus souvent mon PC, puisqu'il s'allume en 10 secondes montre en main.

  • # l'installation et le choix des dépôts

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

    J'ai été intrigué lors de mes test d'installation de Debian Jessie par le fait que, dans certains cas (choix du mode texte ? des sites miroirs ? autre chose ?) j'ai eu le choix d'inclure dès l'installation d'autres dépôts (backports notamment) que le principal (main). Mais comment faire pour obtenir ce choix ? Quel cheminement d'installation doit on choisir ?

  • # LinuxFR est pro-Systemd

    Posté par . Évalué à 10.

    Je dois être maso car je vais atteindre le -10 en un temps record, mais il y a tout de même depuis plusieurs mois un phénomène sans pareil sur LinuxFR.

    Si on regarde les votes des commentaires, ceux qui ne parlent pas de systemd tombent dans l'indifférence.
    Ceux qui parlent de systemd déchaînent les votes:
    - Si le commentaire est pro-Systemd, on peut espérer le +10 de pertinence. Ce qu'on a à dire est donc intéressant.
    - Si on est contre systemd, on est systématiquement dans le négatif. Notre commentaire est donc inutile (sûrement car "résistance is futile")

    Personnellement, je ne comprends pas cet engouement qu'il y a pour systemd. A la limite, il se limiterait à la fonction d'init pourquoi pas. Ce serait une alternative de plus et puis voilà.
    Là, franchement, il est hyper complexe, il peut remplacer le vénérable init mais aussi fstab, crontab, iptables, su, udev… avec des choix très discutables sur la gestion de l'UEFI ou plus récemment sur la survie des process après logout (nohup ca veut dire ce que ca veut dire, il n'y a pas besoin d'une option pour ca).

    S'il faut à tout prix remplacer l'init, il y a d'autres alternatives mais qui ont a priori le tort de ne faire que ce qu'ils doivent faire (par exemple openrc souvent cité, mais aussi runit qui est, lui, vraiment impressionnant de rapidité).

    Donc non, je ne comprends pas ce mouvement de foule qui ne jure que par systemd.

    • [^] # Re: LinuxFR est pro-Systemd

      Posté par . Évalué à 4.

      Je viens d'en faire les frais :)

      Mon commentaire pourrait paraître simpliste ou occultant que systemd va au delà mais justement, comme tu le pointes, systemd était vendu comme un remplaçant d'init au départ, donc c'est sur cet aspect là que le comparais et de là, il ne m'impressionne pas et ne simplifie pas ma vie d'admin vétéran car il est effectivement d'une complexité effarente en cas de "fail".
      Sa nomenclature très laide, j'ai vraiment du mal avec mais ce qui m'inquiète et qui a été mainte fois relevé c'est son intrusivité et là, ce sont les pro-systemd qui l'occultent.

    • [^] # Re: LinuxFR est pro-Systemd

      Posté par . Évalué à 9.

      Je pense que ceux qui ne sont pas 100% pour systemd ont juste lâché l'affaire. Ils utilisent autre chose, et basta.
      Perso, quand je vois un article qui va clairement faire l'apologie de systemd, en général, je me contente des 10-20 1ères lignes et je passe à autre chose. Je peux limite deviner le reste sans le lire.

      Les débats autour de systemd que j'ai lu ont toujours été menés à charge contre sysVinit (et la plupart des arguments étaient fondés) mais pas en montrant en quoi systemd était le meilleur (de tous les init).

      Maintenant, parmi les opposants à systemd, certains faisaient de la résistance au changement (genre ceux qui défendaient les scripts de sysVinit…), mais pas tous. D'autres disaient qu'il existe des alternatives, aussi bien voire mieux en terme de maintenance (daemontools/runit étaient régulièrement cités, et je n'ai souvenir d'aucun argument contre eux, étrange… au lieu de ça, la discussion re-déviait sur une attaque à sysVinit qui démontrait combien le bash ne conviens pas pour les scripts d'init, comme si sysVinit en faisait le meilleur usage…).
      N'étant pas fan de systemd, et encore moins de sysVinit, j'ai un peu suivi certaines de ces alternatives et lu quelques articles (pas de grands livres rentrant dans les détails, des articles relativement courts, pas plus de 2 pages A4) s'y relatant (donc mon opinion est clairement partielle).

      • sysVinit, j'avais eu l'occase d'essayer de faire un service… Tout est dit.
      • openrc, je n'en ai pas vu l'intérêt. Je ne l'ai pas considéré assez supérieur à sysVinit pour justifier un remplacement.
      • upstart, réputation à problèmes.
      • uselessd est mort, de mémoire l'auteur affirme que le code de systemd est trop… heu… on va dire, complexe…
      • systemd, et son flou «artistique» sur les limites du projet. Sans parler de son code C assez hermétique (de mémoire, parce que oui, j'ai été voir un peu, il y a perpette).
      • runit. Simple. Efficace. Le code C est lisible et concis. La doc complète (sans les exemples de services) tiendrai, à vue de nez, sans difficulté sur 5 feuilles a4.

      Sur deux VMs, j'ai fait des tests niveau vitesse. À services égaux, runit semble légèrement plus rapide, au démarrage comme à l'extinction.
      C'est probablement égal, une fois pris en compte le manque de précision de mon outil de mesure (horloge système de l'hôte, combiné à un regard vissé sur les fenêtres des VMs) biais d'observation et le fait que la nature même d'une VM virtualbox rend les mesures aléatoires.

      Personnellement, je ne comprends pas cet engouement qu'il y a pour systemd. A la limite, il se limiterait à la fonction d'init pourquoi pas. Ce serait une alternative de plus et puis voilà.

      Je pense que l'engouement est lié à:

      • quelques fortes personnalité qui ont fait du buzz autour, en promouvant son adoption rapide
      • le fait que son inventeur ait été connu avant
      • le fait qu'il fournisse, justement, tant de fonctionnalités. Ça plaît, ça donne l'impression que c'est bien, parce que les logiciels qui ne font qu'une chose, ça n'impressionne pas.
      • du fait de l'engouement, il a bénéficié d'un vrai travail pour remplacer l'init sur plusieurs distributions.

      Runit, puisque tu le cites, n'a, à priori, pas eu le même nombre de personnalités célèbres derrière. Et il ne cherche évidemment pas à faire autre chose que

      1. initialiser le système
      2. superviser les services

      C'est tout de suite moins sexy. Du coup, j'imagine que peu de gens on fait l'effort de fournir des scripts d'initialisation pour une distribution, ce qui n'aide pas non plus.

      • [^] # Re: LinuxFR est pro-Systemd

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

        Je pense que ceux qui ne sont pas 100% pour systemd ont juste lâché l'affaire. Ils utilisent autre chose, et basta.

        Stats Zenitram, la majorité des gens qui critiquent systemd se défoulent pour le plaisir (ça a l'air de faire du bien) et continue d'utiliser leur distro (avec systemd donc).

        Comme beaucoup de changements, les gens réagissent au début et ensuite se rendent compte que rien n'a vraiment changé en fait et/ou que c'est pas si mal en fait, et trouvent alors un nouveau nom à lyncher, et ainsi de suite.

        Je me permet de recopier un commentaire qui m'a bien plu :
        https://linuxfr.org/nodes/109169/comments/1659972
        On m'avais dit qu'une fois que Centos 7 arriverait, les gens partiraient en masse (donc en juillet 2014 ). Puis on a dit "tu verras quand Debian sortira" ( avril 2015 ). Et ensuite "quand ça toucheras Ubuntu" (octobre 2015). Puis "nan mais je voulais dire Ubuntu stable" (avril 2016).

        • [^] # Re: LinuxFR est pro-Systemd

          Posté par . Évalué à 7.

          Stats Zenitram, la majorité des gens qui critiquent systemd se défoulent pour le plaisir (ça a l'air de faire du bien) et continue d'utiliser leur distro (avec systemd donc).

          Stats Freem, la majorité des gens qui critiquent systemd lui font une critique positive. Ça à l'air de faire du bien :D

        • [^] # Commentaire supprimé

          Posté par . Évalué à 5.

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

          • [^] # Re: LinuxFR est pro-Systemd

            Posté par . Évalué à 0.

            Je rencontre exactement les mêmes problèmes que toi dans l'administration de tous les jours (Debian Jessie).

      • [^] # Runit

        Posté par . Évalué à 10. Dernière modification le 10/06/16 à 10:57.

        Pour ma part, j'ai utilisé runit en production, pas juste sur une VM par curiosité. C'est un bon outil, mais j'ai basculé sans hésitation vers systemd quand Jessie est sortie.

        D'abord, il faut rappeler que runit ne suit pas la norme SysVinit. Donc il faut se coltiner l'écriture de scripts en shell pour piloter le démarrage des services, en remplacement de ceux écrits dans /etc/init.d/. Debian ne les fournit pas et qu'il n'y a pas une grosse communauté autour de runit (admirez la litote ;-).

        Mon besoin était de surveiller (monitoring) des services dont l'un n'avait pas de mode démon. Il n'écrivait même pas son PID dans un fichier. Ça a l'air tout bête, mais il n'y a guère d'outil pour surveiller un service de ce type, et le relancer en cas de crash ou de signal d'arrêt. C'est pour ça que j'avais opté pour runit.

        Par contre, je me suis retrouvé avec le problème inverse : il fallait que les services soit lancés en premier plan, sans forker en tâche de fond. Et Runit n'utilise pas les cgroups, donc un service peut échapper à son gestionnaire — à sa décharge, les cgroups sont apparus bien après lui.

        En pratique, je trouvais aussi que runit n'étais pas si simple que ça à administrer. Par exemple, je lançais autant que possible les processus avec des utilisateurs différents, pour des raisons de sécurité. Avec Runit, soit il faut activer un mécanisme global de déclaration dans les répertoires des utilisateurs, soit il faut jouer avec su dans les scripts shell des services. Autre exemple, la gestion des dépendances est vraiment très sommaire : c'est au script shell de tester si ses pré-requis sont là, et de quitter s'il manque quelque chose, ensuite runit essaie de le relancer plus tard.

        Quant à la vitesse, oui runit est rapide, mais je doute qu'il le soit plus que systemd, notamment parce qu'il lance un nouveau shell pour chaque service. De toutes façons, quand une machine démarre en moins de 5 secondes, je ne vais pas faire la course pour quelques dixièmes.

        J'ai du respect pour runit, un petit outil bien fait (hélas peu documenté), mais à mon avis il n'a pas la carrure pour être le gestionnaire de démarrage d'une grande distribution.

        • [^] # Re: Runit

          Posté par . Évalué à 6.

          Mon besoin était de surveiller (monitoring) des services dont l'un n'avait pas de mode démon. Il n'écrivait même pas son PID dans un fichier. Ça a l'air tout bête, mais il n'y a guère d'outil pour surveiller un service de ce type, et le relancer en cas de crash ou de signal d'arrêt. C'est pour ça que j'avais opté pour runit.

          Et une ligne dans /etc/inittab ?

          id:345:respawn:/chemin/process
          

          Ça ne marchait pas ?

          • [^] # Re: Runit

            Posté par . Évalué à 6.

            Ça aurait sûrement marché, mais j'ai du mal à croire que des gens mettent des services comme apache2 dans leur inittab. Pour arrêter un service on change de runlevel?

        • [^] # Re: Runit

          Posté par . Évalué à 3.

          D'abord, il faut rappeler que runit ne suit pas la norme SysVinit. Donc il faut se coltiner l'écriture de scripts en shell pour piloter le démarrage des services, en remplacement de ceux écrits dans /etc/init.d/.

          Hum… sysVinit, il ne fait que lancer des services, il ne les gère pas. Il le faut au travers de scripts shell. Alors tout ce qui gère les services, sors forcément de la «norme» sysVinit.
          Runit, il lance des services, et il les gère. Au travers de scripts shell.

          Le langage shell utilisé est le même pour les deux cas. Du coup, je ne vois pas trop comment runit ferait moins bien que sysVinit?
          Je reconnais n'avoir pas essayé, mais, ça ne marche pas de lancer les scripts de /etc/init.d par runit?

          Et le coup de la norme sysVinit pas respectée, ça ne prend pas.
          Oui, systemd peut lancer des scripts sysVinit (comme runit, j'en suis persuadé), mais il ne respecte pas non plus celle-ci. Donc il faut se «coltiner» (ton terme) l'écriture de fichiers de config avec la syntaxe de systemd .
          Maintenant, je trouve que le shell à une syntaxe de merde (et des mots-clé à la con, genre fi et esac, par contre pas de rof ni de elihw? Mots clé à la con, et même pas consistants! Je ne parlerai pas de test, à chaque fois que je m'en sers, je sors le man!), est bourré de chausses-trappes et à pleins d'autres inconvénients (me semble plusieurs de ces inconvénients on causé la naissance de perl, d'ailleurs).
          Mais pas obligé de connaître le shell pour écrire des scripts runit, rien n'empêche d'utiliser python par exemple (j'en ai vu un exemple sur github, il y a quelques jours).
          D'un autre côté, systemd «impose» un langage, plus simple qu'un langage de programmation. Par contre, il s'agit d'une technologie spécifique, qui ne servira que pour systemd.

          Du coup, vraiment, l'argument de la norme en faveur de systemd et contre runit il est pas terrible :)
          D'ailleurs, le coup d'utiliser un autre langage pour écrire les scripts d'init, pourquoi ne pas l'avoir utilisé pour sysVinit? Je viens de réaliser que je n'ai pas souvenir d'avoir lu quoique ce soit à ce sujet? Ça aurait sûrement pu simplifier énormément les usines à gaz.

          Par contre, je me suis retrouvé avec le problème inverse : il fallait que les services soit lancés en premier plan, sans forker en tâche de fond.

          Oui, c'est le problème, le service doit avoir un moyen de ne pas utiliser le double fork. Qui ressemble quand même pas mal à un workaround, pour moi (traditionnel, certes, mais workaround quand même).

          Par exemple, je lançais autant que possible les processus avec des utilisateurs différents, pour des raisons de sécurité. Avec Runit, soit il faut activer un mécanisme global de déclaration dans les répertoires des utilisateurs, soit il faut jouer avec su dans les scripts shell des services.

          Ou utiliser le programme chpst fourni par runit? Cet outil est vraiment très intéressant, il permets notamment de:

          • changer l'utilisateur
          • les groupes du processus
          • les variables d'environnement (bien apprécié ça, récemment) en définissant un dossier dont chaque fichier/contenu est une variable/valeur
          • créer un fichier de verrouillage. Peut-être que ça aurait pu résoudre ton problème de fichier PID manquant? (je viens de l'apprendre, cette option, j'ai ouvert le man par curiosité)

          Par contre, je ne sais pas s'il y a un workaround contre les programmes qui exigent de forker. À part les forker eux, pour faire sauter le double fork et recompiler, bien sûr :D

          Quant à la vitesse, oui runit est rapide, mais je doute qu'il le soit plus que systemd, notamment parce qu'il lance un nouveau shell pour chaque service.

          C'est vrai, le lancement d'un shell est lent. Celui qui lance des bash à chaque fois dois prendre bien cher… d'un autre côté, celui qui lance juste busybox-static, ça doit être raisonnable, niveau coût.
          Par contre, je ne sais pas du tout comment systemd marche, de ce côté la. C'est un binaire séparé de l'init qui lit la config?

          (hélas peu documenté)

          C'est vrai, la documentation tiens sur peu de place. D'un autre côté, je n'ai pas l'impression qu'il y ait besoin de plus. Après tout, runit délègue au système la plupart de ses actions. Alors que systemd c'est plutôt le contraire, il prend les prérogatives du système pour la plupart des actions du systèmes :)

          il n'y a pas une grosse communauté autour de runit (admirez la litote ;-).

          Oui, je pense que c'est une des raisons qui fait qu'il n'est pas utilisé plus que ça.

          à mon avis il n'a pas la carrure pour être le gestionnaire de démarrage d'une grande distribution.

          Probablement. Le point le plus noir étant probablement sa communauté trop réduite. Du coup, effectivement, peu de scripts sont fournis, et soyons honnêtes, ceux du site officiel semblent un peu obsolètes.
          Je ne pense pas que runit vise à gérer le démarrage d'une grande distribution. Pour moi, il est plus adapté à des distributions qui cherchent à laisser le contrôle à l'utilisateur. Ne serait-ce que par la quasi absence de comportement par défaut.

          • [^] # Re: Runit

            Posté par . Évalué à 8.

            D'ailleurs, le coup d'utiliser un autre langage pour écrire les scripts d'init, pourquoi ne pas l'avoir utilisé pour sysVinit? Je viens de réaliser que je n'ai pas souvenir d'avoir lu quoique ce soit à ce sujet? Ça aurait sûrement pu simplifier énormément les usines à gaz.

            Je ne sais pas chez les autres, mais Debian et dérivées avait une bibliothèque (infâme) shell pour simplifier les scripts d'init. OpenRC a un autre exemple de scripts mieux fait c'est déclaratif (globalement). Ce qui est marrant avec systemd c'est que d'un coup on s'est rendu compte que tout était possible et qu'on était à quelques yakafokon de résoudre toutes les lacunes qu'il avait depuis 20 ans…

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

          • [^] # Re: Runit

            Posté par . Évalué à 6.

            Le langage shell utilisé est le même pour les deux cas. Du coup, je ne vois pas trop comment runit ferait moins bien que sysVinit?
            Je reconnais n'avoir pas essayé, mais, ça ne marche pas de lancer les scripts de /etc/init.d par runit?

            Comme quoi on peut avoir installé runit, le promouvoir comme alternative à systemd, vanter sa documentation… et ne pas avoir compris les principes de base de runit. Ses scripts de lancement doivent rester en premier plan, contrairement aux lancements de démons qu'on trouvent dans /etc/init.d/.

            Du coup, vraiment, l'argument de la norme en faveur de systemd et contre runit il est pas terrible :)

            Merci de ne pas déformer mes propos. Je disais que pour Runit les scripts shell ne suivaient pas la norme de SysVinit. Je n'ai pas comparé avec systemd et son format de configuration.

            Mais si tu viens sur ce terrain, alors parlons de la magnifique norme pour lancer un démon avec SysVinit : chacun se démerde comme il peut avec son shell et les outils du bord. Et bien sûr, les outils standard dans le monde Debian (comme start-stop-daemon) ne sont pas présents chez Redhat. Runit a fait le choix de prendre en charge la démonisation, mais avec l'inconvénient de mal gérer les processus qui forkent. À comparer avec systemd qui s'accommode de tout, y compris les doubles forks. On peut le détester sur plein d'aspects, mais il faut reconnaître qu'il apporte aussi des progrès techniques par rapport à tous ses concurrents, et c'est pour ça qu'il s'est largement imposé.

            • [^] # Re: Runit

              Posté par . Évalué à 2.

              Ses scripts de lancement doivent rester en premier plan, contrairement aux lancements de démons qu'on trouvent dans /etc/init.d/.

              Je sais, oui. Ceci dit, quand on fait une migration, il est quand même utile de pouvoir le faire au fur et à mesure, et c'est d'ailleurs l'impression qui ressort de ce document

              For those services that are not migrated to use run scripts yet, add the corresponding init-script startup to /etc/runit/1

              Je me trompe? D'ailleurs, pas mal de bordel dans /etc/init.d/ n'a pas vocation à resté lancé (initialisation des partoches/réseau, notamment).

              Merci de ne pas déformer mes propos. Je disais que pour Runit les scripts shell ne suivaient pas la norme de SysVinit. Je n'ai pas comparé avec systemd et son format de configuration.

              Tu as, bien sûr, noté le smiley?

              Mais si tu viens sur ce terrain, alors parlons de la magnifique norme pour lancer un démon avec SysVinit : chacun se démerde comme il peut avec son shell et les outils du bord.

              Yep, sysVinit, c'est le pire qui existe à ma connaissance.

        • [^] # Re: Runit

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

          J'ai moi meme utilisé runit pendant des années (et utilise toujours) comme simplificateur de lancement de démon. Je m'explique. Bien souvent nous sommes amenés en mileu professionnel à devoir lancer tel ou tel démon mal packagé et sans scripts (ou avec des scripts d'init moisi). Dans ce cas au lieu de devoir écrire un énieme script j'utilisais runit, avec un certain bonheur. Alors certes il faut que le programme puisse tourner en foreground (j'avoue trouver le fait que chaque programme gére sa propre démonisation pas très bon, et j'aimerais idéalement une version standard de le faire).
          Runit est simple et stupide comme j'aime. Je suis d'accord avec les limitations que tu vois; mais certains ont crée un framework par dessus pour palier ses défauts.
          Par exemples les appliance F5 utilisaient (utilisent) runit comme init. Et ce sont des trucs sérieux :)
          A noter que l'on peut tout à fait utiliser runit (ou un de ces clones) avec les cgroups; il suffit de le wrapper. Bref je vous invinte à tester .

    • [^] # Re: LinuxFR est pro-Systemd

      Posté par . Évalué à 6.

      La cabale n'existe 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: LinuxFR est pro-Systemd

      Posté par . Évalué à 5.

      Je dois être maso car je vais atteindre le -10 en un temps record[…]

      T'es à +8 malgré le coté victime de ton poste (« tout le monde il est contre moi ! »).

      S'il faut à tout prix remplacer l'init, il y a d'autres alternatives mais qui ont a priori le tort de ne faire que ce qu'ils doivent faire (par exemple openrc souvent cité, mais aussi runit qui est, lui, vraiment impressionnant de rapidité).

      Ce qui est drôle1 c'est que tout ceux qui commence par vouloir prendre de la hauteur finissent par présenter leur poulain.

      • Si le commentaire est pro-Systemd, on peut espérer le +10 de pertinence. Ce qu'on a à dire est donc intéressant.
      • Si on est contre systemd, on est systématiquement dans le négatif. Notre commentaire est donc inutile (sûrement car "résistance is futile")

      Le système de notation de linuxfr ne représente pas grand chose, hein ? Faut arrêter de se focaliser là dessus. Il y a des gens qui passent leur temps à expliquer que les like de facebook, les follower de twitter ou les +1 de google sont idiots, mais ils pleures pour des pertinents/inutiles ici…


      1. En fait ça ne l'ai pas. Ça ne l'est plus, des troll sur les systèmes d'init on en a eu énormément. Il y un moment où la majorité des gens veulent juste passer à autre chose et n'ont rien à faire de init, leur distribution fait tout ce qu'il faut pour que ça marche et ça leur suffit. 

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

    • [^] # Re: LinuxFR est pro-Systemd

      Posté par (page perso) . Évalué à 1. Dernière modification le 10/06/16 à 09:50.

      Si on est contre systemd, (…) Personnellement, je ne comprends pas cet engouement qu'il y a pour systemd.

      Parce que ce n'est pas le sujet.
      C'est jugé "inutile" car dans 99% des commentaires, la critique est du troll (dernier journal : il faut une ligne de config pour revenir à "comme avant" et ça râle contre systemd car des gus trouvent "horrible" un choix de config par défaut pour des raisons précises et accusent systemd d'un changement de config par défaut de Debian, n'est-ce pas ridicule?).

      Ce que ne comprennent pas les "anti-systemd", c'est qu'en face il n'y a pas de "pro-systemd", juste des mecs qui trouvent que les mensonges trollesques contre systemd sont inutiles (franchement, si on est objectif sur sa critique de systemd, pourquoi a-t-on besoin de mentir dessus? C'est juste du troll dans 99% des cas).
      un problème sur ta machine? C'est la faute à systemd, hop accusation par défaut sans réfléchir, c'est d'une banalité dans la notion de bouc-émissaire…

      tu commences bien sur la note en te victimisant, mais loupe (encore et encore) le sujet : les anti-systemd n'ont pas affaire à des "pro-systemd", juste à des gens qui rigolent sur les bêtises que peuvent sortir les anti-systemd.

      Donc non, je ne comprends pas ce mouvement de foule qui ne jure que par systemd.

      pas foule ne "jure que par", les gens sont surtout utilisateur du choix des mainteneurs, qui eux ont étudié le sujet plus que toi ou moi et on trouvé la chose utile (et ont dit pourquoi), tout en notant que la majorité des administrateurs système pas "du dimanche" apprécient ce changement (c'est que ça soit être utile, non?).


      Ce qui est lourd, c'est que les anti-systemd pensent toujours qu'ils ont affaire à des pro-systemd dès qu'on leur montre que leur critique contre systemd est stupide.

      • [^] # Re: LinuxFR est pro-Systemd

        Posté par . Évalué à 10.

        c'est qu'en face il n'y a pas de "pro-systemd",

        Et c'est bien triste …

        Microsoft fait de l'open source, Il y a même un Windows SubSystem for linux,

        vi contre emacs n’intéresse plus personne
        et maintenant systemd cela à l'air plutôt bien.

        Cela n'augure rien de bon pour linuxfr, plus aucun journal n'atteint le point Godwin, Pbpg ne vient plus nous voir bref c'est le début de la fin …

        si cela continue comme cela, on va tous finir par regarder et commenter des vidéos de chat (oui l'animal) sur snapchose

        • [^] # Re: LinuxFR est pro-Systemd

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

          faut voir le bon côté des choses : Linux a enfin atteint la maturité pour le desktop !

        • [^] # Re: LinuxFR est pro-Systemd

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

          Je te trouve bien pessimiste. Avec le foot et le Brexit il y a du potentiel pour des journaux trollesques ce mois-ci.

          • [^] # Re: LinuxFR est pro-Systemd

            Posté par . Évalué à 2.

            Le foot ne m’intéresse quasiment pas :
            C'est quand même un sport ou les mecs jouent comme des gonzesses et les gonzesses comme des mecs

            Le Brexit : A par voir David Cameron patauger dans sa connerie je trouve pas cela marrant

            Si ils restent : ils ne pourront plus venir se plaindre comme avant et perdrons de l'influence
            Si ils partent : à mon avis le bordel sera phénoménal pour tout le monde

            Donc c'est du pipeau

            Ya pas de quoi atteindre le point Godwin avec ça …

            • [^] # Re: LinuxFR est pro-Systemd

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

              Une bonne petite histoire autour du code de la route et des motards et tu vas l'avoir ton sport.

            • [^] # Re: LinuxFR est pro-Systemd

              Posté par . Évalué à 3.

              C'est quand même un sport ou les mecs jouent comme des gonzesses et les gonzesses comme des mecs

              Je ne vois pas trop de raison de regretter les points Godwin (même pour rigoler), mais les remplacer par des commentaires sexistes c'est quand même assez triste.

              • [^] # Re: LinuxFR est pro-Systemd

                Posté par . Évalué à 0.

                Ok je reformule :

                Le foot est un des rare sport ou les joueurs "masculins" donnent libre cours à leur coté féminin notamment lors des inévitables chocs inhérents à ce sport.
                Alors que les joueuses donnent l'impression de déployer beaucoup plus d'énergie dans ce sport et ce de manière inversement proportionnellement à leur salaire.

                Désolé ça le fait pas … cette phrase est ridicule
                Personne à envie de répondre et je le comprends bien …

                Je vais rester sexiste tant pis :)

        • [^] # Re: LinuxFR est pro-Systemd

          Posté par . Évalué à 0.

          T'inquiètes pas, Lennart nous sauvera bien à un moment donné…

          • [^] # Re: LinuxFR est pro-Systemd

            Posté par . Évalué à 2.

            Lennart … Linux prêt pour le desktop … 42 … LA LUMIERE !!!!

            je vois la lumière au bout du tunnel … merci je suis sauvé

            ALLELUIA !!!!

      • [^] # Re: LinuxFR est pro-Systemd

        Posté par . Évalué à 6. Dernière modification le 10/06/16 à 16:51.

        Ce que ne comprennent pas les "anti-systemd", c'est qu'en face il n'y a pas de "pro-systemd"

        .

        des mainteneurs, qui eux […] on trouvé la chose utile

        C'est contradictoire, non? Être "pro-whatever", c'est bien être en faveur de whatever? Si on trouve une chose assez utile pour en remplacer une autre, c'est bien que l'on est en faveur de la première, sans obligatoirement considérer que la seconde est absolument mauvaise?

        Pour le reste… il n'y a pas que des extrémistes et des aveugles dans la discussion, ce n'est pas parce que l'on n'apprécie pas systemd qu'on le déteste, et j'ose espérer que ce n'est pas parce qu'on l'apprécie que l'on doit jouer les zélotes.

        • [^] # Re: LinuxFR est pro-Systemd

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

          C'est contradictoire, non?

          Non : les mainteneurs ne sont généralement pas sur LinuxFr, ceux qui répondent ne sont pas les mainteneurs, mais des gens "lambda" voyant l'énormité des pseudo-critiques (même en connaissant très peu de systemd, on peut voir que c'est du n'importe quoi).

          ce n'est pas parce que l'on n'apprécie pas systemd qu'on le déteste

          Les personnes critiquées sont celles qui haïssent (il faut voir la haine que ça peut déclencher, pour un truc ridicule comme un système d'init d'un OS, à croire que les gens n'ont rien de plus important dans la vie).
          Jette un oeil sur les journaux parlant de systemd, ça y va rapidement dans l'insulte gratuite de son mainteneur et des mots haineux, on n'est pas du tout dans la critique objective / "je n'apprécie pas".

          • [^] # Re: LinuxFR est pro-Systemd

            Posté par . Évalué à 4.

            et des mots haineux

            Et ça n’a bien entendu rien à voir avec de tristes sires qui répandent de l’huiledu napalm sur le feu avec des sorties genre « ceux qui critiquent systemd sont des esclavagistes ».

          • [^] # Re: LinuxFR est pro-Systemd

            Posté par . Évalué à 4.

            Il y a besoin d'être mainteneur pour avoir un avis sur systemd? Tout le monde peut avoir un avis, mainteneur ou non. Et donc, tout le monde peut être pro, anti, ou entre les deux.

            Enfin, je suis d'accord que les discours autour de systemd virent souvent à l'extrême.
            J'ai arrêté de suivre la ml de debian à cause de ça et de certains débordements (tant des utilisateurs que des modérateurs) que j'ai constatés (et non, je n'irai pas exhumer des preuves, ça fait longtemps que je n'en ai plus rien à foutre).
            Par contre, je ne crois pas que seuls les anti mènent les «débats» dans la direction des décharges. Pour ma part, j'ai vu pas mal de débats constructifs être pourri par les deux camps extrêmes, ce qui est dommage, parce que j'ai aussi vu des avis constructifs tant des pro que des antis.

            • [^] # Re: LinuxFR est pro-Systemd

              Posté par . Évalué à 2.

              et non, je n'irai pas exhumer des preuves, ça fait longtemps que je n'en ai plus rien à foutre

              Il n'y a pas besoin de faire de l'exhumation : les argumentaires se sont zombifiés ! :-P

              Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

            • [^] # Re: LinuxFR est pro-Systemd

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

              Il y a besoin d'être mainteneur pour avoir un avis sur systemd?

              non, mais y a besoin de faire le taf pour que l'avis compte.

              Tout le monde peut avoir un avis, mainteneur ou non. Et donc,
              tout le monde peut être pro, anti, ou entre les deux.

              Bien sur, mais au final, ceux qui font le boulot décident. Et quand je vois le temps que Devuan a mis pour sortir une beta (sachant que Mageia a mis 4 mois pour sortir la première stable, avec infra, gouvernance, etc), le fait d'avoir eu 0 exode des utilisateurs (cf le journal sur devuan), j'ai tendance à dire qu'avoir un avis est plus facile que faire le taf. Et même si c'est triste, c'est la dur loi du logiciel libre. Si personne fait le taf, le taf est pas fait.

              • [^] # Re: LinuxFR est pro-Systemd

                Posté par . Évalué à 2.

                non, mais y a besoin de faire le taf pour que l'avis compte.

                Suis d'accord. Mais dans ce cas, 90% des avis, pro ou anti, sont inutiles :)

                Bien sur, mais au final, ceux qui font le boulot décident.

                C'est bien pour ça que, malgré que je ne sois pas d'accord avec Debian (parce que mes besoins actuels ne collent pas à leurs objectifs) je respecte profondément cette distribution et le boulot de ceux qui la font vivre.
                franchement, Devuan, j'ai été sérieusement agacé par leur 1er «nom» (debian-fork, ou un truc à la con du style) et leur argumentaire de base. Le fork était peut-être utile et bon, mais de forker sur un troll, ça ne peut pas attirer les gens, fatalement.

    • [^] # Re: LinuxFR est pro-Systemd

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

      Là, franchement, il est hyper complexe, il peut remplacer le
      vénérable init mais aussi fstab,

      mais supporte encore /etc/fstab.

      crontab

      mais supporte encore crontab comme avant. Rajouter l'execution periodique, ç'est quasiment logique (cf upstart et launchd). Entre lancer un soft sur un event (genre tel autre soft vient de se lancer) et lancer un soft sur un event temporel, y a pas grand chose de différent, donc y a du sens de faire les 2.

      iptables

      non. ce que systemd fait, c'est d'activer des regles de nat pour lancer des containers. C'est pas vraiment remplacer iptables, sauf si tu as une vision vachement réduite d'iptables.

      su

      pas vraiment. su va juste changer le userid, et parfois suivant les options, lancer ou pas l'initialisation. machinectl shell va te lancer une session, mais aussi dans un container. Le fait de lancer ça sans changer de namespace est juste une feature logique (vu que le namespace par defaut est juste un namespace comme un autre).

      udev…

      udev a été mergé par les devs upstreams, au cas ou tu as oublié.

      En fait, je pense que si tu prends "le systeme d'init" comme "/bin/init", oui, tu va pas comprendre. Si tu prends en compte "/bin/init et /etc/rc.d" et les fichiers afférants, alors ça prends plus de sens. Genre /etc/rc.d/network, qui va gérer le réseau (comme networkd), /etc/rcS.d/S08mountall.sh va gérer le montage des partoches (d'ou le fait d'avoir un type mount, qui n'est que l'exposition du type interne de systemd pour les montages), et tout les sous morceaux de script qui font l'init.

      Ou pour les distros RH-like, le gros bousin de /etc/rc.sysinit

      avec des choix très discutables sur la gestion de l'UEFI

      Alors, je suppose que tu parles des machines de MSI (https://github.com/systemd/systemd/issues/2402). Comme dit dans le rapport de bug, il y a des raisons de vouloir écrire dans efivars pour des programmes externes. Et on l'a vu avec les gens de tmux, quand on soumet des demandes pour adopter le comportement d'un soft à un changement de systemd, c'est non car c'est à systemd de rien changer, et quand systemd ne change pas pour ne pas casser les programmes, c'est "très discutables" et le comportement aurait du changer.

      On pourrait presque croire qu'il y a aucun moyen de faire le bon choix.

      ou plus récemment sur la survie des process après logout
      (nohup ca veut dire ce que ca veut dire, il n'y a pas besoin
      d'une option pour ca).

      Le pourquoi du comment est pourtant expliqué dans les divers bug reports pour qui veut savoir ce qui est le souci derrière.

      Et je vois pas en quoi nohup change grand chose. Ni même ce que ça veut dire en pratique, vu que ça ne s'applique que pour les programmes avec un concept de tty (vu que tout ce que ça fait, c'est d'ignorer le signal qui est envoyé quand tu perds ton port série, et par extension, ton terminal virtuel). Ça ne veux pas vraiment dire "lance ça en background", et par définition, ça n'a aucun sens sur un programme non lié à un tty (genre certains demons utilise SIGHUP pour autre chose que voir qu'il y a plus personne face à eux ).

      S'il faut à tout prix remplacer l'init,

      alors en fait, si tu regardes un peu l'histoire:
      - gentoo a remplacé son init (openrc)
      - ubuntu a remplacé son init (upstart)
      - apple a remplacé son init (launchd)
      - sun a remplacé son init (smf)

      Fedora avait adopté upstart (et RHEL 6 en a hérité), Suse et Mandriva voulait faire de même. Et je pense que certains BSD ont aussi refait leur init (genre openbsd).

      Donc ouais, depuis un bout de temps, les unix veulent changer leur init.

      il y a d'autres
      alternatives mais qui ont a priori le tort de ne faire que ce
      qu'ils doivent faire (par exemple openrc souvent cité, mais
      aussi runit qui est, lui, vraiment impressionnant de rapidité).

      En fait non, le tort, c'est d'avoir intéressé personne.

      Sur les tonnes de distros de distrowatch, y en a aucune dans le top 30 qui s'est dit depuis que runit existe "tiens, on va mettre ça".

      Openrc, c'est pire. Dans le débat du TC de Debian, personne n'a poussé. Le packager qui s'en occupait était grosso modo tout seul alors que ça aurait collé sans doute mieux aux problématiques de debian. Et dans gentoo, personne n'a corrigé les bugs du au lancement de service en parallèle présent pendant 4 ou 5 ans. Et tout comme upstart, c'était bien dormant avant que systemd n'arrive.

      Donc non, leur seul tort, c'est que ça n'a motivé personne. Et en général, si un truc motiv e personne, y a des chances que ça soit pas si bien que ça, que ça répondes pas aux problèmes des gens. Y a pas à

      Donc non, je ne comprends pas ce mouvement de foule qui ne
      jure que par systemd.

      C'est pourtant pas faute d'avoir eu largement le temps de lire les discutions des 5 dernières années.

      • [^] # Re: LinuxFR est pro-Systemd

        Posté par . Évalué à 1.

        Merci. :)

        Et c'était très intéressant.

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

Suivre le flux des commentaires

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