Les développeurs Debian ont manifesté leur intérêt pour systemd tout en soutenant l'exploration d'alternatives

Citation:

---

Envoyé par sizvix

Vu que c'est une partie de l'équipe de Debian qui l'a forké, je ne suis pas sûr que l'on puisse les qualifier de "manche à balais" dans ce domaine ...

---

Ce n'est pas parce-que c'est des personnes qui travaillent sur un gros projet OpenSource qu'il sont forcément "bon".

N'importe qui peut commencer à contribuer à un projet OpenSource... Bon c'est pas non plus la porte ouverte à tout le monde sur tout les projets, certains sont même assez regardant sur la liste des contributeurs (Système de parrainage, de test, d'interviews par mail etc), mais il arrive parfois de trouver des absurdités dans le code (parfois justifié, exemple "legacy reason". Ou non comme des quickfix, ou juste parce-qu'ils sont mauvais), sachant que ceux qui peut nous paraitre nulachier, peut ne pas l'être pour d'autres... exemple systemD :aie:

Même nous/vous, ça peut nous arriver d'écrire quelque chose, de revenir plus tard en mode : 8O mais j'avais fumer quoi ? Je devais être fatigué !

Donc voilà, à nuancer, ce n'est pas parce-qu'ils sortent de l'équipe de contributeur de Debian, qu'ils fourniront forcément un travail de qualité. On pourra juger quand on verra les premiers résultats. Wait & see.

Citation:

---

Envoyé par sazearte

Ils ne savent même pas faire un site internet, alors une distribution....

---

Heuuu... On parle de métier relativement différent donc bon...

Citation:

---

Envoyé par sazearte

non ce n'est pas mon site, juste un site que je trouve pratique, c'est quoi le rapport ?

D’après toi je suis un devin, un évangéliste un prophète...., donc j'ai raison.

---

Je pense qu'il imaginais seulement : Que si c'est ton site, t'es sacrément bon. Mais, comme ce n'est pas le cas ...:aie:

Citation:

---

Envoyé par sazearte

Bas j'irais même jusqu’à dire que Linux c'est pour les serveurs globalement, Linux est pas utilisée dans le monde des desktop (2-3% de part de marchés) la ou dans les serveurs c'est 95%.

---

Juste pour compléter, Linux a aussi 85% de parts de marché au niveau des smartphones :-) (source: Wikipedia -- http://en.wikipedia.org/wiki/Mobile_...m#Market_share)

Ce qui pose problème avec systemd, c'est principalement la sécurité.

System.d si vous lisez un peu, c'est quasiment un kernel au dessus du kernel.
Donc un nid à failles de sécurités, pourquoi réinventer la roue?

Le problème est là.

Et ce n'est pas comme si c'était peu important.

Le Kernel Linux est une vraie garantie contre la NSA et autres (pas chez Ubuntu à mon avis).

Si vous avez 2 sous de jugeotte, ca signifie aussi que les autres OS en ont un. (à ma connaissance on n'a pas entendu d'annonce similaire pour MacOS ou Windows).

Voilà. Traitez moi de parano si vous voulez, mais moi j'installerais du devuan, quelquesoit la laideur de leur site.

Tu peut installer Devuan, mais qu'es ce qu'il prouve que ce fork sera suivie dans le temps ? sera telle stable, les mises a jour de sécurité serons t'il (s'il y'en a) déployée rapidement ?


Je ne critique pas le fait de faire un fork de Debian, mais il faut rester prudent avec cette distribution, on se lance pas dans l'inconnu, surtout en production.

Et j'ai peur que Devuan soit juste un moyen de dire "Eh moi j'suis pas content de SystemD" sans vision a long terme du projet.

Ah la "communauté" linux ... la pire du monde informatique !!!!

Pop-corn time

Citation:

---

Envoyé par sazearte

Arrête de faire semblant de pas comprendre et de faire exprès de mal interpréter mes propos.

Je parle de Vista, car aujourd'hui tout le monde est content des changements apportée par Vista (sous Windows 7/8), SystemD va faire du dégât au début sous Debian 8.0 mais dans 3ans vous lui lécherez le c... .

Devuan est vouée a disparaitre, si il n’enlève que systemD et apporte rien d'autre.
Si Ubuntu était restée un simple fork de Debian plus personne ne l'utiliserais aujourd’hui.
Au passage Ubuntu utilise pas sysV...

Utilisée Ubuntu en tant que serveur c'est possible mais pas conçue pour, déjà ubuntu est très gourmand par défaut.


Bas j'irais même jusqu’à dire que Linux c'est pour les serveurs globalement, Linux est pas utilisée dans le monde des desktop (2-3% de part de marchés) la ou dans les serveurs c'est 95%.
Bien sur on peut utilisée Debian sur desktop (je l'utilise), mais il plus utilisée dans les serveurs que sur pc.

---

C'est vrai que le modèle de process est un peu primitif, avec l'arrivé de midori & co la distance va encore grandir. M'enfin moi la communauté linux, elle est comment dire composé de malades ... ils ne sont pas capable de parler sans insulter tout le monde. Et ils se prennent pour le centre du monde.

Information : je me suis inscrit exprès à cause de cette polémique systemd.
L'hystérie autour de systemd par des gens qui n'y comprennent strictement rien n'est pas pire ici qu'ailleurs, ce n'est que le hasard qui fait que je poste ici. Pour information, je connais l'administration système Linux et sysvinit depuis au moins 1997. Je réponds à tous les critères invoqués par les UVA (Unix Veteran Admin). Je suis aussi le projet systemd depuis ses débuts, et je connais parfaitement les problématiques des distributions, et en particulier les gros problèmes de sysvinit. sysvinit que je n'utilise plus depuis des années pour mes propres OS, que je monte moi-même.
Bref, contrairement à une majorité des personnes impliquées dans cette hystérie, je sais de quoi il retourne et de quoi je parle. Les mainteneurs des distributions aussi, et ils ont autre chose à faire que se chamailler avec des gens qui ne comprennent rien mais parlent sans savoir.

Citation:

---

Envoyé par azimuth

Ce qui pose problème avec systemd, c'est principalement la sécurité.

System.d si vous lisez un peu, c'est quasiment un kernel au dessus du kernel.
Donc un nid à failles de sécurités, pourquoi réinventer la roue?

Le problème est là.

---

Le problème n'est pas là, et tu ne comprends strictement rien à ce qu'est systemd. Ce n'est pas la chose la plus affligeante que j'ai pu lire mais bon.
Systemd est plus sécurisé que n'importe quel système d'init sous Linux : il prend en compte de base du MAC comme SMACK ou SELinux si l'on veut.

Citation:

---

Envoyé par azimuth

Et ce n'est pas comme si c'était peu important.
Le Kernel Linux est une vraie garantie contre la NSA et autres (pas chez Ubuntu à mon avis).
Si vous avez 2 sous de jugeotte, ca signifie aussi que les autres OS en ont un. (à ma connaissance on n'a pas entendu d'annonce similaire pour MacOS ou Windows).
Voilà. Traitez moi de parano si vous voulez, mais moi j'installerais du devuan, quelquesoit la laideur de leur site.

---

Comme l'a indiqué Julian Assange, Debian a de fortes chances d'être rempli de failles exprès via la NSA et autres. De nombreuses failles étaient présentes dans Debian (par exemple la faiblesse des clés générées) contrairement à d'autres distributions, permettant facilement à la NSA de rentrer dans tous les Debian installés. Ce genre de failles est conséquent sur Debian. Cela n'a rien à voir avec systemd de toutes façons.

Je vais partir du réel problème qu'ont les détracteurs de systemd qui y comprennent qqch : ils doivent apprendre un nouveau système d'init.
C'est le seul et unique problème. Tout le reste n'est que du mensonge pour rallier les ignorants à leur cause. Parce qu'ils perdent beaucoup de pouvoir avec systemd, même face à des admins débutants, en tout cas en ce qui concerne l'init.
Parce que systemd est plus simple et règle une tonne de problèmes de sysvinit, dont plus personne ne veut. Quand je dis personne, je parle des mainteneurs de distributions et des développeurs de daemons. Parce que sysvinit est une horreur insoluble pour gérer l'init d'un système. C'est invisible pour la plupart des utilisateurs grâce au travail immense des mainteneurs, mais ça plante encore dans énormément de cas, à cause de nombreux problèmes insolubles avec du shell comme des race conditions, des pertes de processus fils, des pertes d'informations d'erreur envoyées par les daemons, une inadéquation à gérer la nature dynamique des périphériques, l'impossibilité de savoir si un process est toujours en fonction ou pas, l'impossibilité de gérer des configurations complexes, ...
Ceux qui ont vraiment eu à gérer sysvinit et ses tonnes de scripts shell comme moi, ont très vite voulu s'en débararasser. C'est pourquoi depuis 2001, j'ai dégagé cette horreur et installé autre chose. Les mainteneurs de distributions ainsi que les développeurs de logiciels, libre ou pas, ont le même problème, souvent ils jettent l'éponge et laissent chaque distribution créer un script de démarrage pour leur outil. Même s'ils le fournissent ce script, il est de toute façon souvent remplacé par les distributions. C'est pourquoi tous ces systèmes d'init ont fleuri, la vérité c'est que sysvinit est complètement dépassé et inadéquat depuis plus de 15 ans.
Mon système d'init (j'avais fini avec simpleinit-msb) est devenu vraiment obsolète en 2009, et je ne pouvais plus le maintenir dans mon coin, donc à cette époque, j'ai cherché un remplaçant valable. J'ai commencé par tester Upstart, mais j'ai eu de gros problèmes avec dbus. Et puis est arrivé systemd juste à temps. La promesse de systemd était un rêve éveillé pour tout admin système, c'est pourquoi les soi-disants admin réfractaires ne sont pour moi pas de vrais admins Linux comme ils le prétendent. Un véritable administrateur Linux s'adaptera à systemd en moins d'une semaine. Et le bénéfice sera incomparable.

systemd a réussi le tour de force de réaliser ses promesses, et d'unifier l'init des distributions. Pour moi, c'est juste du bon sens et rassurant que quasiment toutes les distributions Linux principales l'aient adopté, ainsi que les développeurs de daemons : éliminer tous les problèmes de sysvinit tout en apportant d'importantes améliorations, c'est juste un rêve. On a très vite vu des mainteneurs de nombreuses distributions venir se greffer au développement, tant la promesse était belle. Elle est maintenant remplie et de belle manière, mais il y a encore du travail, donc systemd bouge encore très vite par rapport à ce que peut accepter une distribution "stable".

systemd a réussi là où tous les autres systèmes d'init Linux ont échoué, mais cela ne m'étonne pas, vu que la direction du projet a été clairement définie dès le départ.

Les ignorants ensuite, gobent des choses invraisemblables comme "votre système va crasher si le PID 1 crashe". Ce qui est une évidence et n'apporte aucune information. En revanche c'est ce que l'on appelle du FUD. Beaucoup de détracteurs disent avoir testé systemd et ne pas aimer ou carrément détester. Mais ils ne disent pas pourquoi. Probablement parce qu'ils ne savent pas, n'ont rien testé, n'y comprennent rien et seraient ridicules. Tous ceux qui ont cité une raison se sont rendus ridicules auprès de vrais admins. J'ai pu lire ici je crois, qu'avec systemd, une personne ne voyait plus quels services ont échoué ou pas. systemd affiche ces informations, permet de les retrouver après que la console ait été effacée, bref, cette personne n'est, j'espère, pas un admin.

En fait, de nombreuses distributions ont déjà été influencées par systemd avant même de l'intégrer : systemd a poussé de nombreux changements, comme la possibilité de fair de mtab un lien dans /proc (buggé auparavant), l'idée d'avoir un (/var)/run sur un FS volatile (ce qui n'était pas le cas auparavant et causait tout un tas de problèmes), les xattr sur les tmpfs, de nombreux bugs dans le noyau ou améliorations, le premier à réellement utiliser des options du noyau Linux (cgroups, console) ce qui implique que systemd ne fonctionne que sous Linux, la gestion du multiseat enfin fonctionnelle, ...

Pour les nombreux services disponibles dans systemd, ils répondent chacun à une problématique de démarrage du système, contrairement à ce que je peux lire par des gens qui n'ont jamais eu à gérer ou créer de nombreuses architectures différentes. Un des plus flagrants est la gestion du montage et de la vérification des systèmes de fichier au démarrage. Ce truc est si compliqué et bourré d'erreurs avec sysvinit, que les distributions maintenant, par défaut, vous mettent tout dans une partition racine plus un home : une hérésie totale de nos jours et une catastrophe attendant de se produire. Des systèmes plantés au démarrage parce qu'une vérification de disque a échoué, j'en ai vu dans ma vie. Et dès qu'on commence à parler de LVM, avec en plus du RAID, voire en plus un FS chiffré, là les histoires d'horreur commence, et aucun sysvinit n'est capable de gérer cela correctement, ni même les plus récents : c'est un des cas où les admin vétérans commencent à créer leurs propres scripts, avec des sleep partout, de véritables horreurs qui fonctionnent la plupart du temps mais peuvent crasher à n'importe quel boot en pratique. J'ai eu exactement ce genre de choses à faire. systemd est le premier init qui a permis de corriger de nombreux bugs dans LVM, et me permet de monter de tels systèmes sans aucun problème, sans bidouille. Et également de les éteindre proprement, ce qui n'est pas gagné avec d'autres init.

La mise en place du réseau est encore un autre problème qui encore aujourd'hui dans Debian, est buggé au possible, et juste inutilisable. Tous ceux qui ont essayé de changer l'adresse réseau à partir d'une connexion SSH savent de quoi je parle. systemd a donc implémenté une méthode pour gérer cela. Et puis certaines machines n'ont pas d'horloge RTC ou un RTC défaillant, et les logs deviennent incompréhensibles ou inutilisables, il a donc été ajouté à systemd un outil pour gérer ce cas, avant de passer la main à un daemon NTP par exemple. De même, un grand nombre de logs étaient perdues au démarrage, ou dans la sortie standard/erreur des daemons, et très difficile à réconcilier, c'est une des raisons d'être de journald.
La console dans le noyau Linux est une merde sans nom que personne ne veut plus toucher et le noyau propose des API pour l'implémenter en userspace. Mais personne ne s'est jamais attelé à la tâche. Encore une fois, systemd est le premier (et sera probablement le seul) à s'y mettre depuis tout ce temps (en fait, il y a eu kmscons en fait déjà, mais aucune distrib ne le propose en standard). Et les ignorants (ceci comprend les medias parlant du libre) trouvent le moyen de présenter cela comme du négatif alors que ce n'est que du positif. Un peu comme tout systemd en fait.

Bref, ce fork va se planter, et toute cette polémique mourra d'elle-même, parce que depuis même avant systemd, ce sont toujours les mêmes yakafokon qui parlent mais ne font rien, et personne n'a été foutu d'apporter une alternative à systemd.
Regardez logind (fait partie des outils fournis par systemd) : cela fait plus de 10 ans qu'on demande de partout des API pour implémenter le multiseat. Logind est la seule implémentation qui le permette, grâce aux fonctions de systemd. Les DE n'ont d'autre choix que d'utiliser celui-ci puisque c'est la seule implémentation viable aujourd'hui.

Quant aux gens qui sortent des trucs du style "bah suffit de faire un mount quand on insère une clé USB", comment dire... Ces gens-là ne sont pas dignes d'être écoutés. Je trouvais cela déjà inadmissible dans les années 90 et j'ai toujours tout fait pour que des utilisateurs qui n'y comprennent rien puissent brancher leur clé et pouvoir utiliser leur clé sans être admins Unix : mes enfants sont tous sur mes Linux et n'ont jamais eu ce genre de choses à faire.

Quant aux serveurs, ils se porteront bien mieux, c'est le cas pour tous les miens et tous ceux où j'ai installé systemd. Un vrai init qui fonctionne comme promis c'est juste incomparable. Un Apache qui s'éteint vraiment, un bind qui s'éteint vraiment et redémarre donc correctement, une machine qui boote même quand un disque non essentiel est mort, c'est incomparable.

Citation:

---

M'enfin moi la communauté linux, elle est comment dire composé de malades ... ils ne sont pas capable de parler sans insulter tout le monde. Et ils se prennent pour le centre du monde.

---

Si tu parle de moi, je ne t'ai pas insulter, et je me sens très bien mentalement.

Sinon, j'ai installer la nouvelle beta de Debian 8, 1 chose et sure, sa déboite !!!!, sa boot en 2 secondes, c'est impressionnant le gain de performance et ce pas que au boot, mais aussi sur les applications.

Citation:

---

mais ça plante encore dans énormément de cas

---

Oui je confirme...

Citation:

---

Parce que sysvinit est une horreur insoluble pour gérer l'init d'un système.

---

Effectivement, quand j'ai voulue m'y mettre j'ai rien compris, donc j’étais retourner a Fedora.

Citation:

---

Envoyé par Ookaze

Debian a de fortes chances d'être rempli de failles exprès via la NSA et autres. De nombreuses failles étaient présentes dans Debian (par exemple la faiblesse des clés générées) contrairement à d'autres distributions, permettant facilement à la NSA de rentrer dans tous les Debian installés.
[...]
La mise en place du réseau est encore un autre problème qui encore aujourd'hui dans Debian, est buggé au possible, et juste inutilisable.
[...]

---

he ben, faut aller prévenir toutes les entreprises qui ont des serveurs sous Debian des dangers qu'ils courent à utiliser une telle distribution.

Citation:

---

les distributions maintenant, par défaut, vous mettent tout dans une partition racine plus un home : une hérésie totale de nos jours et une catastrophe attendant de se produire.

---

je ne suis pas un expert de ton niveau (en tout cas je ne me prétend pas détenteur de la vérité absolue comme toi) mais je n'ai encore jamais vu une distribution Gnu/Linux qui ne permette pas de faire le partitionnement exactement comme on le veut...
bon j'ai pas essayé des centaines de distribution, tout juste 5 ou 6, mais j'en pas vu une seule qui impose de faire seulement 2 partitions (un pouur le home et une pour le reste).
tu veux bien nous expliquer de quelles distributions tu parles?


sinon, c'est con t'as l'air d'avoir quelques connaissances, mais y a quelques aspect de ta diatribe qui ruinent complètement ta crédibilité:
- les jugements à l'emporte pièce sans la moindre justification
- le manichéisme (beaucoup en font preuve, c'est pas juste un de tes travers, mais ça fait un peu fan-boy de dire "systemd c'est le messi, tout ce qui a existé avant n'était que succession de merde)
- l'égo surdimensionné (les "moi je sais" toutes les 3 lignes, les "ceux qui ne pensent pas comme moi sont des ignorant" régulièrement. c'est peut être la vérité, mais le répeter comme un lietmotiv tout au long de ton texte, on dirait que tu essaies de te convaincre toi même)
- pas un mot sur les véritables problèmes de systemd qui ont été évoqué ici

Citation:

---

Envoyé par Ookaze

Regardez logind (fait partie des outils fournis par systemd) : cela fait plus de 10 ans qu'on demande de partout des API pour implémenter le multiseat. Logind est la seule implémentation qui le permette, grâce aux fonctions de systemd. Les DE n'ont d'autre choix que d'utiliser celui-ci puisque c'est la seule implémentation viable aujourd'hui.

---

Salut,

Comme je n y connais pas grand chose dans tout ca et que le mot multiseat ne me parlait pas j ai fait une petite recherche et je suis tombe sur cette page wikipedia :
https://en.wikipedia.org/wiki/Multiseat_configuration
Il n y a pas un mot sur systemd et il semble que des solutions existent.
Est ce que la page n est pas a jour ?
est ce que les solutions existantes sont comparables a ce que propose systemd ?
quelle est ton opinion la dessus ?

Citation:

---

Envoyé par Tryph

he ben, faut aller prévenir toutes les entreprises qui ont des serveurs sous Debian des dangers qu'ils courent à utiliser une telle distribution.

---

Tu n'as absolument rien compris à ce que j'ai écrit, il est évident que tu n'es pas un administrateur. On parle de faire des choses comme reconfigurer le réseau d'une quelconque façon alors que l'on a qu'une session SSH pour administrer. Mais bon, tu ne comprendras pas plus et ce n'est pas grave, ceci ne t'était pas destiné mais tu t'es senti obligé de répondre sans être concerné et sans comprendre.

Citation:

---

Envoyé par Tryph

je ne suis pas un expert de ton niveau (en tout cas je ne me prétend pas détenteur de la vérité absolue comme toi) mais je n'ai encore jamais vu une distribution Gnu/Linux qui ne permette pas de faire le partitionnement exactement comme on le veut...
bon j'ai pas essayé des centaines de distribution, tout juste 5 ou 6, mais j'en pas vu une seule qui impose de faire seulement 2 partitions (un pouur le home et une pour le reste).
tu veux bien nous expliquer de quelles distributions tu parles?

---

Le problème est que tu n'as pas compris ou bien tu as zappé les deux petits mots "par défaut" qui se trouvaient dans la phrase.
Il est toujours possible de partitionner autrement, mais reste assuré que le niveau de compétence alors demandé va bien au-delà de ce que même un administrateur de base connaît. Et je parle des distributions Debian et Red Hat/Fedora.

Citation:

---

Envoyé par Tryph

- pas un mot sur les véritables problèmes de systemd qui ont été évoqué ici

---

Je passe les attaques ad hominem, je n'ai pas le temps pour ces gamineries, surtout que tu n'as aucune autorité pour me juger, et que tu es libre de rester dans ton incompréhension totale de ce qui se passe autour de systemd.
Aucun problème de systemd n'a été évoqué ici. Et c'est le cas la plupart du temps dans ces discussions.
Il y a bien eu des hypothèses avec des "si" et des trucs complètement farfelus, ou pire, des vrais problèmes mais dus en fait à la distribution et pas à systemd, montrant que leur auteur ne sait pas faire la différence et donc n'est pas qualifié pour critiquer systemd dans ce cas (faire des rapports de bug c'est difficile, d'autant plus quand on ne maîtrise pas le sujet).
J'aimerai bien voir des cas concrets de problèmes, mais les seuls que j'ai vu jusqu'ici, des vrais problèmes, c'est sur la ML des dev de systemd que je les ai vus. Et ils sont pris en compte lorsqu'ils sont pertinents. Un grand nombre de fonctionnalité ajoutées à systemd (que certains disent trop complexe) viennent de la nécessité de régler ces vrais problèmes pour des utilisateurs.

Citation:

---

Envoyé par quicky2000

Salut,

Comme je n y connais pas grand chose dans tout ca et que le mot multiseat ne me parlait pas j ai fait une petite recherche et je suis tombe sur cette page wikipedia :
https://en.wikipedia.org/wiki/Multiseat_configuration
Il n y a pas un mot sur systemd et il semble que des solutions existent.
Est ce que la page n est pas a jour ?
est ce que les solutions existantes sont comparables a ce que propose systemd ?
quelle est ton opinion la dessus ?

---

Question tout à fait pertinente. Si tu as lu le passage concernant GNU/Linux, tu auras vu que ce sont de vieilles méthodes, qui imposent d'utiliser de vieilles versions buggées de XOrg, qui imposent d'utiliser des outils dont certains n'existent même plus (en tout cas via les liens fournis dans l'article, certains sont morts, et pas des moindres comme MDM), mais surtout tu verras la galère que c'était pour mettre tout ça en place. Il suffit de regarder les howtos et les conditions à la mise en oeuvre, ainsi que les limitations.
En bref, cet article n'est tout simplement pas à jour sur ce qui se fait de mieux en la matière sous Linux (mais ce n'est pas une nouveauté sur Wikipedia). Parce que bon, l'amélioration du multiseat avec systemd ça date quand même de 2012. Cet article de Phoronix de l'époque résume bien la situation : http://www.phoronix.com/scan.php?pag...multiseat_kick .
Tu noteras qu'une des principales raisons de l'ajout des drivers DisplayPort récemment dans le noyau, c'est pour supporter les configurations multiseat, KMS règle aussi ces problèmes, et avec une console en userspace (seuls les devs de kmscons et de systemd se sont attelés à la tâche) on finira de régler les derniers problèmes. Depuis cet article Wikipedia, même XOrg a implémenté des fonctions pour améliorer le support du multiseat. Wayland le supporte d'office.
Avec systemd (et pulseaudio, etv un XOrg assez récent ou un Wayland, et les dernières fonctions du noyau Linux), tu plugges et ça marche tout seul. C'est tout l'intérêt d'un init comme systemd qui prend en compte que de nos jours, tout est géré dynamiquement sur Linux, en particulier au niveau du noyau. Donc quand le userspace ne sait pas gérer, c'est une galère.

Citation:

---

Envoyé par Ookaze

Question tout à fait pertinente. Si tu as lu le passage concernant GNU/Linux, tu auras vu que ce sont de vieilles méthodes, qui imposent d'utiliser de vieilles versions buggées de XOrg, qui imposent d'utiliser des outils dont certains n'existent même plus (en tout cas via les liens fournis dans l'article, certains sont morts, et pas des moindres comme MDM), mais surtout tu verras la galère que c'était pour mettre tout ça en place. Il suffit de regarder les howtos et les conditions à la mise en oeuvre, ainsi que les limitations.

---

Oui c est ce qu il me semblait avoir compris

Citation:

---

Envoyé par Ookaze

En bref, cet article n'est tout simplement pas à jour sur ce qui se fait de mieux en la matière sous Linux (mais ce n'est pas une nouveauté sur Wikipedia). Parce que bon, l'amélioration du multiseat avec systemd ça date quand même de 2012.

---

Ca vaudrait peut etre le coup de mettre un ou deux mots sur systemd avec les references qui vont bien pour ceux qui souhaiteraient approfondir non ?

Citation:

---

Envoyé par Ookaze

Cet article de Phoronix de l'époque résume bien la situation : http://www.phoronix.com/scan.php?pag...multiseat_kick .
Tu noteras qu'une des principales raisons de l'ajout des drivers DisplayPort récemment dans le noyau, c'est pour supporter les configurations multiseat, KMS règle aussi ces problèmes, et avec une console en userspace (seuls les devs de kmscons et de systemd se sont attelés à la tâche) on finira de régler les derniers problèmes. Depuis cet article Wikipedia, même XOrg a implémenté des fonctions pour améliorer le support du multiseat. Wayland le supporte d'office.
Avec systemd (et pulseaudio, etv un XOrg assez récent ou un Wayland, et les dernières fonctions du noyau Linux), tu plugges et ça marche tout seul. C'est tout l'intérêt d'un init comme systemd qui prend en compte que de nos jours, tout est géré dynamiquement sur Linux, en particulier au niveau du noyau. Donc quand le userspace ne sait pas gérer, c'est une galère.

---

Ok merci pour les infos

Citation:

---

Envoyé par Ookaze

J'aimerai bien voir des cas concrets de problèmes, mais les seuls que j'ai vu jusqu'ici, des vrais problèmes, c'est sur la ML des dev de systemd que je les ai vus. Et ils sont pris en compte lorsqu'ils sont pertinents. Un grand nombre de fonctionnalité ajoutées à systemd (que certains disent trop complexe) viennent de la nécessité de régler ces vrais problèmes pour des utilisateurs.

---

Du concret ? et bien, sur 7 PC, 4 ne s'éteignaient plus depuis le passage à systemd.
Un autre (sur lequel je gardais systemd pour surveiller) faisait une "analyse LSB" à chaque démarrage après une maj, sans aucune raison. Et ça durait 4 minutes !
Après une mise à jour sur le PC suivant, même chose. J'ai donc dégagé systemd de mes portables et PC de bureau. Depuis, plus de problème.
J'ai une machine virtuelle sur laquelle je testais le futur jessie pour mon serveur, Systemd est soit-disant compatible avec les vieux scripts sysV. J'ai un script qui lance des machines virtuelles selon les postes connectés ou non. J'étais obligé de le lancer à la main car si non, il se lançait 2 fois.

J'ai essayé systemd et pour toutes ces raisons + le fait de ne pas avoir le choix + que ça ne colle pas avec la philosophie DEBIAN, je ne veux pas/plus de systemd sur mon serveur ni ailleurs. Ca ne fonctionne pas encore correctement et il n'y a pas de recul pour une DEBIAN STABLE digne de ce nom !

Ce fork dont la plupart des adorateur systemd affichent une mort avant la naissance est une bonne chose. Je lis tous les jours leur mailing liste, et je trouve que ça avance, et que ça discute de choses importantes aussi ! Si ce fork devient un echec. Il reste slackware et les BSD !

Personne n'est contre une évolution des outils d'init, mais pas comme le propose systemd.

Tu peux dire ce que tu veux et insulter tout le monde de débile aussi. Ca changera rien.

Citation:

---

Envoyé par Ookaze

Tu n'as absolument rien compris à ce que j'ai écrit, il est évident que tu n'es pas un administrateur. On parle de faire des choses comme reconfigurer le réseau d'une quelconque façon alors que l'on a qu'une session SSH pour administrer. Mais bon, tu ne comprendras pas plus et ce n'est pas grave, ceci ne t'était pas destiné mais tu t'es senti obligé de répondre sans être concerné et sans comprendre.

---

effectivement je ne suis pas administrateur système (en même temps c'est écrit "Développeur informatique" juste son mon pseudo, c'était pas difficile à deviner), pas professionnellement en tout cas, je me contente d'administrer mon serveur perso sous... Debian (faut que je pense à changer un de ces jours pour éviter de me faire voler mes photos par la CIA :aie:)

Citation:

---

Envoyé par Ookaze

Le problème est que tu n'as pas compris ou bien tu as zappé les deux petits mots "par défaut" qui se trouvaient dans la phrase.
Il est toujours possible de partitionner autrement, mais reste assuré que le niveau de compétence alors demandé va bien au-delà de ce que même un administrateur de base connaît. Et je parle des distributions Debian et Red Hat/Fedora.

---

le niveau de compétence pour faire un partitionnement custom va bien au delà des compétences d'un administrateur de base...? bah bordel...
c'est quoi un administrateur de base? un gars qui se contente de cliquer sur suivant à chaque étape d'une install sans rien customiser?
parce que bien que n'étant pas administrateur pro, je n'ai jamais connu d'échec en cherchant à me faire un partionnement custom.
juste pour que tu nous fasse profiter de tes grandes connaissances, tu mettrais quoi toi comme partionnement par défaut?

Citation:

---

Je passe les attaques ad hominem, je n'ai pas le temps pour ces gamineries, surtout que tu n'as aucune autorité pour me juger, et que tu es libre de rester dans ton incompréhension totale de ce qui se passe autour de systemd.

---

les attaques ad hominem... comme tu y vas.
tu t'es senti offensé à la lecture de "égo surdimensionné" sans doute?
imagine ce que doivent ressentir les gens qui te lisent et qui sont qualifiés d'ignorants toutes les 3 ou 4 phrases. tu estimes donc que tu as autorité pour juger les autres toi.
pas le temps pour ces gamineries hein... pas le temps de prendre un peu de recul sur ce que tu écris non plus visiblement

Citation:

---

Aucun problème de systemd n'a été évoqué ici. Et c'est le cas la plupart du temps dans ces discussions.
Il y a bien eu des hypothèses avec des "si" et des trucs complètement farfelus, ou pire, des vrais problèmes mais dus en fait à la distribution et pas à systemd, montrant que leur auteur ne sait pas faire la différence et donc n'est pas qualifié pour critiquer systemd dans ce cas (faire des rapports de bug c'est difficile, d'autant plus quand on ne maîtrise pas le sujet).
J'aimerai bien voir des cas concrets de problèmes, mais les seuls que j'ai vu jusqu'ici, des vrais problèmes, c'est sur la ML des dev de systemd que je les ai vus. Et ils sont pris en compte lorsqu'ils sont pertinents. Un grand nombre de fonctionnalité ajoutées à systemd (que certains disent trop complexe) viennent de la nécessité de régler ces vrais problèmes pour des utilisateurs.

---

puisque tu as l'air de bien connaitre systemd, dis moi si les assertions suivantes sont des fantasmes (c'est possible mais tu n'en as pas parlé pour le moment et, pour moi, ce sont des gros problème de systemd):
- avec systemd, on perd en modularité: on ne peut pas remplacer un certain nombre de composants lancés au boot (comme c'était le cas avec sysv) car systemd est un gros paquet qui intègre plein de fonctionalité prévues pour fonctionner ensemble et pas avec autre chose
- systemd étant un gros ensemble de fonctionalité, il est de facto plus sujet à disfonctionnement qu'un simple programme qui fait une seule chose. toutes les fonctionalités de systemd étant liées, le disfonctionnement d'une de ces fonctionnalité peut impacter les autres fonctionalités (ce qui n'est pas le cas avec sysv qui se contente de lancer des taches automones). et donc on peut éventuellement perde en stabilité.

dis moi si je me trompe, je suis un peu ignorant... mais je comprends vite... mais faut m'expliquer longtemps :aie:

Sinon il y a ce post sur Linux-Fr qui parle de la guerre zelateur/delateur de Systemd.
Je trouve que ca decrit tres bien ce qu on lit/vit dans ce thread et pourquoi les deux camps ne se comprennent pas

Citation:

---

Envoyé par vohufr

Du concret ? et bien, sur 7 PC, 4 ne s'éteignaient plus depuis le passage à systemd.
Un autre (sur lequel je gardais systemd pour surveiller) faisait une "analyse LSB" à chaque démarrage après une maj, sans aucune raison. Et ça durait 4 minutes !
Après une mise à jour sur le PC suivant, même chose. J'ai donc dégagé systemd de mes portables et PC de bureau. Depuis, plus de problème.

---

Tu n'as donné aucun problème concret de systemd, tu as cité des incidents qui sont tous liés à la distribution. systemd propose une compatibilité avec les scripts sysv, mais ce n'est pas une panacée, à cause principalement du bordel que sont ces scripts. Cela permet juste d'aider les mainteneurs à migrer, et ne pas avoir à tout faire d'un coup.
C'est révélateur de la galère qu'on dû supporter les mainteneurs des scripts sysv depuis des années, c'est exactement pour cette raison qu'ils ne peuvent pas tout tester rapidement et sont obligés de garder les scripts sysv.
Bref, c'est un problème de distribution comme je le disais. Il y a une raison à "l'analyse LSB", contrairement à ce que tu dis, mais si tu dis ça c'est que manifestement tu ne connais rien aux scripts SYSV et leurs nombreux problèmes, qui ont amené des hacks comme LSB, et je n'ai pas la prétension de te le faire découvrir en quelques lignes. C'est que c'est une longue histoire.
De plus, il me semble que si tu as utilisé une Debian, systemd n'est pas encore par défaut dans une version stable, mais je peux me tromper là-dessus.

Citation:

---

Envoyé par vohufr

J'ai une machine virtuelle sur laquelle je testais le futur jessie pour mon serveur, Systemd est soit-disant compatible avec les vieux scripts sysV. J'ai un script qui lance des machines virtuelles selon les postes connectés ou non. J'étais obligé de le lancer à la main car si non, il se lançait 2 fois.

---

Tu n'es pas la première personne qui découvre que son système est vérolé par endroits (très facile avec des scripts shell malheureusement), mais est tombé en marche à un moment donnné, et est resté dans cet état des années. systemd est intransigeant et veut une config correcte à tout moment, pour que ce genre de choses n'arrive plus. Ca évite les plantages inexplicables aux redémarrages par exemple. J'ai en tête le souvenir d'une personne qui se plaignait que systemd ne montait pas une de ses partitions. Il s'avère qu'une option de configuration de son filesystem était erronée (et donc probablement non prise en compte) depuis des années, était silencieusement jetée par le script sysv, mais avec systemd, l'option devait être valide. Bref, l'utilisateur est venu se plaindre de systemd sur la ML, et est reparti en sachant que systemd n'y était pour rien, et mieux encore, lui avait permis de corriger sa vieille config pourrie.

Citation:

---

Envoyé par vohufr

J'ai essayé systemd et pour toutes ces raisons + le fait de ne pas avoir le choix + que ça ne colle pas avec la philosophie DEBIAN, je ne veux pas/plus de systemd sur mon serveur ni ailleurs. Ca ne fonctionne pas encore correctement et il n'y a pas de recul pour une DEBIAN STABLE digne de ce nom !

---

Tu n'es pas admin donc ce n'est pas de ta faute de ne pas avoir cherché la source de ces problèmes, tu as eu la réaction naturelle d'attribuer la faute à systemd, soit. Il reste que l'on aura toujours le choix sous Debian, mais vu le boulot que les scripts sysv demandent aux mainteneurs et aux développeurs, je pense effectivement que bientôt, ces scripts sysv ne seront plus maintenus. Ce qui, pour les détracteurs qui assurent que les scripts sysv fonctionnent parfaitement, ne devrait pas être un problème. Mais quand ils vont voir la montagne de boulot ingrat que c'est en réalité, et un boulot récurrent contrairement à leur croyance... Evidemment, sous Debian, ils sont encore en phase de transition, donc que ça ne fonctionne pas encore correctement n'est pas étonnant, surtout avec les scripts sysv qui font tout et n'importe quoi. Sur d'autres distributions qui ont migré depuis longtemps, ça fonctionne très bien.

Citation:

---

Envoyé par vohufr

Ce fork dont la plupart des adorateur systemd affichent une mort avant la naissance est une bonne chose. Je lis tous les jours leur mailing liste, et je trouve que ça avance, et que ça discute de choses importantes aussi ! Si ce fork devient un echec. Il reste slackware et les BSD !

---

Ce fork est effectivement une bonne chose. Ceux qui n'ont pas encore compris que ceux qui l'ont initié disent en substance "ralliez-vous à nous pour faire le boulot que nous ne ferons pas" vont vite s'en rendre compte. Quant à ceux qui parlent de slackware et BSD, cela me surprend (retour en arrière dans un cas, changement complet de userspace dans l'autre, contre juste un changement d'init, ça n'a aucun sens), surtout que la plupart n'ont déjà pas les compétences techniques pour comprendre les problèmes actuels, mais bon c'est leur choix. Mais je sais qu'ils vont vite déchanter, ces gens-là ne savent pas de quoi ils parlent. Je ne sais pas non plus qui ils croient convaincre.

Citation:

---

Envoyé par vohufr

Personne n'est contre une évolution des outils d'init, mais pas comme le propose systemd.
Tu peux dire ce que tu veux et insulter tout le monde de débile aussi. Ca changera rien.

---

Tu peux dire ce que tu veux et inventer des insultes proférées contre toi si tu veux, mais les mainteneurs de distributions (ceux qui font le boulot) et les développeurs d'applis de plus en plus nombreux sont pour l'évolution des init telle que la propose systemd. Et c'est la seule chose qui compte.

Tu racontes n'importe quoi. C'est pas parce t'écris des pavés que tu as raison.

Citation:

---

Tu n'as donné aucun problème concret de systemd, tu as cité des incidents qui sont tous liés à la distribution

---

Heu... si, puisque lorsque je désinstalle systemd tout fonctionne. Il te faut quoi de plus ?

Citation:

---

systemd propose une compatibilité avec les scripts sysv, mais ce n'est pas une panacée, à cause principalement du bordel que sont ces scripts.

---

Ha bon ? systemd n'arrive pas à être compatible avec les scripts systV ? Qu'ils ne les gère pas alors ces "méchants scripts bash", plutôt que de faire un truc qui fonctionne pas avec. C'est encore une façon détournée d'accuser les scripts init de malfonctions alors que c'est systemd qui les utilise mal. Même si la situation est temporaire, c'est inacceptable.

Concernant le problème LSB. Ma soit disant méconnaissance de tout ce que tu veux, n'empêche pas que la désinstallation de systemd à retirer ce problème. Mais ça, tu ne veux pas l'entendre.

Citation:

---

Tu n'es pas la première personne qui découvre que son système est vérolé par endroits (très facile avec des scripts shell malheureusement), mais est tombé en marche à un moment donnné, et est resté dans cet état des années. systemd est intransigeant et veut une config correcte à tout moment, pour que ce genre de choses n'arrive plus. Ca évite les plantages inexplicables aux redémarrages par exemple. J'ai en tête le souvenir d'une personne qui se plaignait que systemd ne montait pas une de ses partitions. Il s'avère qu'une option de configuration de son filesystem était erronée (et donc probablement non prise en compte) depuis des années, était silencieusement jetée par le script sysv, mais avec systemd, l'option devait être valide. Bref, l'utilisateur est venu se plaindre de systemd sur la ML, et est reparti en sachant que systemd n'y était pour rien, et mieux encore, lui avait permis de corriger sa vieille config pourrie.

---

Vérolée ? pardon ?

"... mais est tombé en marche à un moment donnné, et est resté dans cet état des années." pour un gros nulos comme moi ça donne quoi formulé autrement stp ?
Tu parles ensuites d'intransigeance de config correcte et blablablaaa. Mais pour moi, lorsqu'on détecte une erreur annule l'execution non ?

Donc, dans mon cas, j'ai fait un script tellement pourri (parce que je suis très très nul), et que systemd, intransigeant qu'il est, décide de le lancer 2 fois ? MDRRR :D hmmm. c'est très intéressant.

(excuse moi, mais je m'autorise l'utilisation de mots assez forts, histoire qu'on puisse se comprendre, étant donné que tu aimes les jugements vite fait !)

Citation:

---

Tu n'es pas admin donc ce n'est pas de ta faute de ne pas avoir cherché la source de ces problèmes, tu as eu la réaction naturelle d'attribuer la faute à systemd, soit.

---

Comme tu es bon ! Ton pardon était nécéssaire à ma survie.

Ne pas être "admin" professionnel ne veut rien dire. Quand tu installes quelque chose, heu.. pardon, quand quelque chose s'installe automatiquement durant une mise à jour (et que tu n'as pas vraiment le choix), et que ce qui fonctionnait ne fonctionne plus, je dégage ce que je viens d'installer.
- J'ai pas à chercher comment bidouiller le truc soit disant révolutionnaire pour que ça marche.
- je me fiche des difficultés que les dev du truc révolutionnaire doivent faire pour que la transition soit facile. C'est LEUR problème. Quand on veut mettre une révolution en route, il faut assurer et pas faire semblant et accuser tout le reste d'être "merdique" (qui, on le rappelle, fonctionne depuis 30 ans ?)

Citation:

---

Il reste que l'on aura toujours le choix sous Debian

---

NON, c'est faux, ça été dit et redit et c'est juste ça le problème. On s'en fiche que systemd existe s'il reste facile de s'en débarraser au besoin.

Citation:

---

Evidemment, sous Debian, ils sont encore en phase de transition, donc que ça ne fonctionne pas encore correctement n'est pas étonnant, surtout avec les scripts sysv qui font tout et n'importe quoi. Sur d'autres distributions qui ont migré depuis longtemps, ça fonctionne très bien.

---

Effectivement ça n'est disponible obligatoire que sur Jessie qui est en testing. Depuis 10 ans que j'utilise debian, je n'ai jamais connu tant de problèmes en testing. Disons que la "révolution" en vaut la peine...

Citation:

---

Ceux qui n'ont pas encore compris que ceux qui l'ont initié disent en substance "ralliez-vous à nous pour faire le boulot que nous ne ferons pas" vont vite s'en rendre compte.

---

Oui ? c'est le cas pour n'importe quel projet open source de cette taille non ? On a une idée, et ensuite on essaye d'attirer un max de monde pour alléger le travail de chacun.

Citation:

---

Quant à ceux qui parlent de slackware et BSD, cela me surprend (retour en arrière dans un cas, changement complet de userspace dans l'autre, contre juste un changement d'init, ça n'a aucun sens).

---

Retour en arrière ? slackware est l'une des distribution linux les plus ancienne encore en vie, une des plus dérivée. Elle n'est en rien un retour en arrière. Elle permet justement d'en faire ce qu'on veut. C'est ce qu'on attendait de Debian.
Et passer à BSD peut être bien enrichissant. Evidément, ça ne se fait pas du jour au lendemain. Et alors ?
Ce n'est pas tant le problème du changement d'un init, mais bien plus de choses, comme toutes celles qui font débat.

Si ça n'a aucun sens pour toi, c'est pas pour ça que ça doit pas avoir d'importance pour d'autres.

Citation:

---

Tu peux dire ce que tu veux et inventer des insultes proférées contre toi si tu veux.

---

Contre moi ? j'ai jamais dit ça et tu l'as bien compris, c'est la façon que tu as de t'adresser aux gens qui est insultante, et je ne suis pas le premier à te faire la remarque.

Citation:

---

.. mais les mainteneurs de distributions (ceux qui font le boulot) et les développeurs d'applis de plus en plus nombreux sont pour l'évolution des init telle que la propose systemd. Et c'est la seule chose qui compte

---

Une fois de plus, c'est on avis personnel, partagé par d'autres oui, mais ce que tu nommes une évolution pour s'avérer être une dégradation, et est partagé par d'autres aussi.
Donc la seule chose qui compte c'est pas ton avis sur la question, ou l'avis d'un groupe de personne.
La seule chose qui compte, pour un logiciel libre qui se dit "universel" c'est que TOUT LE MONDE y trouve son compte. Ce qui n'est plus le cas.

Citation:

---

Envoyé par Tryph

effectivement je ne suis pas administrateur système (en même temps c'est écrit "Développeur informatique" juste son mon pseudo, c'était pas difficile à deviner), pas professionnellement en tout cas, je me contente d'administrer mon serveur perso sous... Debian (faut que je pense à changer un de ces jours pour éviter de me faire voler mes photos par la CIA :aie:)

---

Désolé, j'ai une approche pragmatique : je ne regarde pas qui écrit ou son profil, je réponds uniquement au texte, j'ai toujours fait comme ça, sauf quand une personne se démarque.

Citation:

---

Envoyé par Tryph

le niveau de compétence pour faire un partitionnement custom va bien au delà des compétences d'un administrateur de base...? bah bordel...
c'est quoi un administrateur de base? un gars qui se contente de cliquer sur suivant à chaque étape d'une install sans rien customiser?
parce que bien que n'étant pas administrateur pro, je n'ai jamais connu d'échec en cherchant à me faire un partionnement custom.
juste pour que tu nous fasse profiter de tes grandes connaissances, tu mettrais quoi toi comme partionnement par défaut?

---

Pour la partition système, si possible du RAID1 logiciel (indépendant du contrôleur) donc deux disques. A part la partition de boot, tout le reste en LVM, y compris la racine.
Le partitionnement comprend une racine / contenant /usr, une partition pour /tmp (si possible en tmpfs cappé à 1 Go), une partition /var et une partition /home en strict minimum.
Si possible une partition /root, une /usr/local, puis ensuite on peur découper /var si nécessaire selon le type de serveur. On peut aussi découper son /usr pour une machine perso.
Déjà là les distributions commencent à avoir du mal, mais les mainteneurs font bien leur boulot. Mais quand on commence à avoir des disques externes qui peuvent arriver n'importe quand, parfois plusieurs secondes après le démarrage, là ça commence à suer et souvent les admins doivent mettre la main à la patte.
Ne parlons même pas des cartes réseau, même encore aujourd'hui, en dehors de systemd, on peut se retrouver avec des cartes réseau inversées, et là c'est la catastrophe.

Citation:

---

Envoyé par Tryph

les attaques ad hominem... comme tu y vas.
tu t'es senti offensé à la lecture de "égo surdimensionné" sans doute?
imagine ce que doivent ressentir les gens qui te lisent et qui sont qualifiés d'ignorants toutes les 3 ou 4 phrases. tu estimes donc que tu as autorité pour juger les autres toi.
pas le temps pour ces gamineries hein... pas le temps de prendre un peu de recul sur ce que tu écris non plus visiblement

---

Il y a 15 ans, j'étais jeune et naïf et je faisais du support aux utilisateurs sur les forum, jusqu'à ce que je comprenne pourquoi toutes les personnes avec un minimum de compétences abandonnaient. J'ai également fini par laisser tomber. Ce genre de déviation vers la personnalité de celui qui écrit ("ego surdimensionné") je l'ai vu écrit des dizaines de fois (à moi et à d'autres) par des gens qui au lieu d'essayer de prendre en compte les arguments techniques qu'on leur donne, comme ça demande du travail de leur part, changent de sujet vers un terrain moins difficile. Mais le problème technique, lui, n'est toujours pas réglé : c'est une pure perte de temps.

Citation:

---

Envoyé par Tryph

puisque tu as l'air de bien connaitre systemd, dis moi si les assertions suivantes sont des fantasmes (c'est possible mais tu n'en as pas parlé pour le moment et, pour moi, ce sont des gros problème de systemd):
- avec systemd, on perd en modularité: on ne peut pas remplacer un certain nombre de composants lancés au boot (comme c'était le cas avec sysv) car systemd est un gros paquet qui intègre plein de fonctionalité prévues pour fonctionner ensemble et pas avec autre chose

---

On va pouvoir commencer à travailler.
Quels sont ces composants lancés au boot par les scripts sysv que l'on pouvait remplacer (ensuite je vais demander "et remplacer par quoi" si tu veux anticiper) et que systemd remplace ?
Je suppose que ceux qui s'en plaignent les citent ainsi que des exemples de remplacement. Dans le cas contraire tu vas pouvoir commencer à entrevoir la vacuité technique des personnes qui disent cela.

Citation:

---

Envoyé par Tryph

- systemd étant un gros ensemble de fonctionalité, il est de facto plus sujet à disfonctionnement qu'un simple programme qui fait une seule chose. toutes les fonctionalités de systemd étant liées, le disfonctionnement d'une de ces fonctionnalité peut impacter les autres fonctionalités (ce qui n'est pas le cas avec sysv qui se contente de lancer des taches automones). et donc on peut éventuellement perde en stabilité.

dis moi si je me trompe, je suis un peu ignorant... mais je comprends vite... mais faut m'expliquer longtemps :aie:

---

Pas de problème. La première assertion est fausse et compare des oranges et des pommes : des fonctionnalités avec des programmes.
Il y a tellement de non sens dans tout cela, que ça va me prendre du temps à tout te décrire : je ne serai pas exhaustif.
Si tu parles des fonctionnalités, tu parles donc du dépôt git systemd. Celui-ci comprend les fonctionnalités de l'init lancé comme PID 1, ainsi que tout un tas d'autres fonctionnalités nécessaires à booter une machine sous Linux. C'est-à-dire que tu parles de la même chose que l'init sysvinit avec tous les scripts shells et autres binaires spécifiques à chaque distribution nécessaires à booter une machine sous Linux. Bref, pas de différence à part qu'il y a plus de force de travail sur chaque fonctionnalité de systemd que sur chacun des scripts shell ou binaires de chaque distribution Linux, Debian y compris.
Si tu parles d'un simple programme, tu parles de l'init PID 1 je suppose, et systemd fait effectivement plus de choses que celui de sysvinit. Déjà, systemd s'assure de faire le boulot que sysvinit était censé faire mais n'a jamais réussi à faire : gérer les daemons et leurs fils. Donc de facto systemd est meilleur. Mais il est vrai qu'il propose également de prendre en compte des aspects sécurité fournis par le noyau Linux (SMACK, SELinux), d'autres de cloisonnement liées aussi à la sécurité (équivalent chroot), la gestion des ressources (mémoire, CPU, ...) fournie par le noyau Linux et liées aux sessions.
Donc oui, sur le PID 1, systemd fournit plus de possibilités de dysfonctionnements. Par exemple, si tu as inclus une sécurité empêchant ton serveur Apache de voir autre chose que les répertoires qu'il a le droit de voir, la bidouille cachée dans une config Apache permettant d'accéder à un répertoire interdit ne fonctionnera plus.
S'il y a un bug ou un manque de fonctionnalité dans le noyau Linux (et systemd a permis d'en lever plusieurs), ça ne fonctionnera pas non plus dans certains cas.

La seconde phrase est tout aussi fausse dans sa totalité. Toutes les fonctionnalités de systemd ne sont pas liées, et je ne vois pas en quoi le dysfonctionnement d'une de ces fonctionnalités peut impacter les autres. systemd est au contraire spécifiquement designé pour qu'une fonctionnalité n'impacte pas les autres ou le moins possible. Or c'est bien le cas pour sysv, qui non, ne se contente pas de lancer des tâches autonomes, et ne fait certainement pas gagner en stabilité. Rien que l'arborescence des niveaux d'init inclus des dépendances.
Tu n'as sans doute jamais vu des boots se planter sur des fsck de FS non nécessaires au boot, mais j'en ai vu plein sous sysvinit. Rien que cette histoire de montage des disques est un problème très compliqué, sous Ubuntu ils ont un programme C spécifique pour gérer cela.
Il faudrait me donner des exemples de fonctionnalités qui pourraient en impacter d'autres, mais par exemple, je pense au serveur de temps, qui, si le réseau (d'admin par exemple) était perdu, sous Debian, me bloquait des boots de serveurs pendant de longues minutes.