Discussion :

[Tryph]

En plus, ça sera juste a cause du logiciel de boot.... le truc qu'on voit pas et qui dure 30 secondes...
Nawak....

ce qui est nawak c'est de s'exprimer sur un truc dont on ne connait visiblement rien...
je réponds à ton post mais faut pas le prendre seulement pour toi, y en a paquet qui font les cadors sans avoir la moindre idée de implication de l'adoption de SystemD.

après, en guise d'avertissement, je vais commencer par vous dire que je ne suis moi même pas conscient de tout ce qu'implique le passage à SystemD, alors je vais peut être dire un ou deux trucs pas tout à fait exacts, je vais pas vous faire un liste exhaustive de toutes les implications, mais pour avoir lu un ou deux articles sur le sujet je peux au moins vous dire quel est (pour moi) le vrai problème de ce système de "boot" sans faire d'affirmation fumeuse qui vise à faire croire que je maitrise complètement le sujet.

bref, d'après ce que j'ai compris du truc, et qui est selon moi le plus gros problème, SystemD n'est pas un simple système de boot (contrairement à ce que tous ceux qui ne connaissent rien au sujet prétendent).
tradtionnellement, un système de boot se charge de lancer une quantité plus ou moins importante de programmes qui ont tous une tache bien définie. l'une va gérer le son, l'autre le réseau, etc...
avec un simple système de boot qui se contente de lancer des taches spécialisées, si le programme qui gère le son (par exemple) ne nous convient pas, on s'en débarasse, on le remplace par le programme qui nous plait, on fourni son script de démarrage au système de boot et tout roule. le système est modifiable à souhait, un bug dans un programme n'impacte pas le déroulement des autres taches, c'est cool.
maintenant le problème de SystemD est qu'il vise à remplacer ou intégrer une bonne partie de ces taches qui sont lancées au démarrage et qui tournent en tache de fond, à en faire une grande soupe ou tout est mélé et interdependant et ou le remplacement d'un composant du système devient difficile (voire impossible?), ou un bug dans une tache peut potentiellement entrainer dans sa chute tout (ou une bonne partie) le système. forcément on perd en controle sur ce qui compose notre système, on perd aussi en compatibilité entre tous les outils du monde Linux et potentiellement en stabilité.

en gros: fuck le découplage

puisque vous êtes des professionnels de l'informatique, vous devez certainement comprendre que ça a bien d'autres implications que le formatage des messages qui s'affichent à l'écran lors du démarrage de la machine.

perso, je me fous un peu que mon poste soit SystemD ou SysVInit tant que mon système reste stable.
mais je trouve normal que des gens s'inquiètent de l'utilisation par défaut de SystemD surtout sur une distrib comme Debian qui tourne beaucoup sur des serveurs ou il me semble que le controle et la stabilité du système sont deux enjeux très important.
et à partir du moment ou ils n'obtiennent pas gain de cause, je trouve parfaitement normal qu'il fassent ce qu'il faut pour avoir un système qui leur convient (en l'occurence un fork).
ils auraient effectivement pu se contenter de "gueuler" sur des forums et de se lamenter en pensant au bon vieux temps, mais non: ils préfèrent agir, je vois pas en quoi ça peut gèner qui que ce soit.


à tous ceux qui prétendent que ça va compliquer Linux, que ça va rendre le support de Débian plus difficile (etc...) je dirais "arrêtez de boire les gars". les gens qui contineront à utiliser Debian se contenteront de faire comme ils ont toujours fait pour mettre à jour leur système. le fork de Débian n'a absolument aucun impact sur Debian ou sur une quelconque autre distribution.
quand vous voyez une pub pour une nouvelle marque de biscuit à la télé, vous vous demandez si ça va compliquer votre choix devant le rayon biscuit du supermarché? je pense que non...
en quoi l'arrivée d'une nouvelle distrib va compliquer quoi que ce soit pour ceux qui ne souhaite passer à cette distrib? j'ai vu cette assertion plein de fois dans ce topic mais aucune explication, il est peut être temps d'en donner une.

hors sujet: "ce qui est sa plus grande qualité est aussi son plus gros défaut" c'est la dernière phrase de Nabila ou quoi? pourquoi j'ai lu cette phrase qui ne veut rien dire aussi souvent sur ce topic...?
l'ouverture du code est une qualité.
le fait qu'on puisse forker un système est une qualité.
ça permet de diversifier l'offre, ça n'a aucun impact sur ceux qui ne veulent pas profiter des nouvelles offres, je vois pas en quoi ça peut être un défaut.

[Pierre GIRARD]

Debian forké à cause de systemd

Ça s'appelle : "Se tirer une balle dans le pied"

Autant je comprends le Fork de OpenOffice lors du rachat de SUN par Oracle, autant (déjà) je ne comprends pas que OpenOffice et LibreOffice n'aient pas re-fusionnés lors de la reprise par la fondation Apache.

Là, c'est encore pire, c'est une querelle de chapelle. Ridicule ! dans tous les cas, c'est pas ce genre de sottises qui me fera abandonner OpenSUSE. Ce dernier n'est pas parfait, loin de là, mais ça reste plus que jamais mon préféré.

[RyzenOC]

Le modèle de processus dans Linux n'a pas évoluer en 30ans !
Un nouveau modèle a été créé avec Vista : Virtual immersive science and technology application Un espace d'adressage virtuel propre, Un code exécutable, Des descripteurs d'accès aux objets,Un contexte de sécurité...

SystemD apporte son lots de fraîcheur.

[vohufr]

sazearte > tu tournes en rond non ? Le principe même du PC n'a pas évolué depuis bien plus que ça, et ça te gène ?



- Donc oui sysVinit est vieux, oui c'est lent, très modulable, mais ça marche !
- Systemd est jeune, rapide, mais on a pas de recul, et il est envahissant et moins modelable !

Debian à toujours laissé le choix à ses utilisateurs, ça n'est plus le cas. Un fork va naître.

Voilà, tout est dit, chacun fait sa vie, son choix. Vous critiquez le fork, alors que personne ne vous l'impose et ne changera rien à votre vie. Au pire le fork ne tiendra pas et ça change toujours rien pour vous.
Laisser le libre vivre

[RyzenOC]

non, juste que faut "moderniser" Linux et arreter de défendre des technos vielles et plus adaptée au machine

[vohufr]

non, juste que faut "moderniser" Linux et arreter de défendre des technos vielles et plus adaptée au machine

Tu sais quoi de ce qui est adapté ou pas ? T'es pas à la place de tout le monde. On répète encore et encore que c'est un problème de choix ! Debian ne laisse plus le choix de l'init (répété et répété ici 100fois, puisque systemd n'est pas désinstallable complètement)

Si J'AI envie de laisser sysVinit ça me regarde, et si debian me le permet plus, elle ne répond plus à la philosophie qu'elle défendait. Donc soit je la quitte, soit je vais vers un fork s'il existe.

Arrêtez de croire que tout le monde veut du desktop qui boote en 2 secondes !

[Traroth2]

Pour une recap des arguments pour et contre systemD : http://www.infoworld.com/article/260...pocalypse.html

[Tryph]

non, juste que faut "moderniser" Linux et arreter de défendre des technos vielles et plus adaptée au machine

moderniser pour le simple fait de moderniser en se foutant des principes qui ont contribué à faire la stabilité de Linux et son succès sur tous les supports autres que les PC desktop, je suis pas certain que ça soit une bonne chose.

SysVInit est vieillissant et plus tellement adapté aux machine actuelles certes. je pense que pas grand monde ne dira le contraire. en fait il me semble même que la plupart des détracteurs de SystemD sont d'accord avec ça.
Mais ça n'oblige en aucun cas à se ruer sur le premier "remplaçant" venu sous le seul prétexte qu'il parallélise le lancement des taches au démarrage.

S'il faut perdre la flexibilité, la compatibilité et potentiellement la stabilité pour gagner 30 secondes (et la satisfaction d'avoir utilisé tous les coeurs) au démarrage je comprend parfaitement que des gens soient réticents.

Après c'est certain que si tout ce que vous avez retenu du système c'est "il fait du parallèle plutôt que du série" c'est certain que ça doit paraitre tentant.
mais faut pas seulement voir ce qu'on gagne avec un nouveau système, faut aussi accepter de voir ce qu'on perd.
et en l’occurrence, je ne suis pas certain que la balance avantage/inconvénient soit très favorable à SystemD.

Ça, je ne dis pas le contraire, mais de là à faire un Fork, c'est peut-être aller vite en besogne, et à terme, ça risque de faire plus de dégâts qu'autre chose. Mais bon, c'est typique de l'homme en général, quand deux factions se forment, le premier réflexe est de se déclarer la guerre. La discussion, elle vient après.

quels dégats ce fork pourraient-ils bien faire?

en l’occurrence la discussion a eu lieu avant le fork il me semble et pour résumer, il me semble que ça s'est passé comme ça:
*** au départ ***
A: SystemD viole certains principes fondamentaux de UNIX, c'est une grosse tambouille monolithique qui veut tout gérer et qui se prend pour un noyau au dessus du noyau, c'est pas bien.
B: très bien on va faire voter une petite dizaine de gens influents dans la communauté pour statuer sur ce sujet.
*** après le vote ***
B: le vote a eu lieu: vous l'avez dans l'os.
A: très bien on va forker

la suite logique me parait effectivement être un fork...
et les forks ne sont pas forcément de mauvaises choses, d'ailleurs tu annonçais tout à l'heure être fidèle à OpenSuse. Il me semble que Suse est un fork de Slackware... ça ne te pose aucun problème...? penses-tu que le fork qui a donné Suse à causé des dégâts? as-tu l'impression que c'est la guerre en Suse et Slackware?

[RyzenOC]

Ben sous Linux c'est un modèle conçue dans les années 1970, qui a un peu évoluée avec l'évolution des différentes version du système UNIX puis GNU/Linux.

SystemD apporte une évolution non négligeable.


@abel.cain, je n'ai pas bu, mais si t'a une meilleur idée dis le nous !
SystemD sera imposée, le fork vas faire un gros bide. Toutes les autres distribution sérieuse sont sous SystemD.

[RyzenOC]

Je dirais : tout le monde.

Donc Windows 8 est instable ?, je vois ton niveau de compétence.
EDIT: Si tu parle de la sécurité, oui il faut nuancer, c'est clair que mettre Windows en sur un serveur, cela semble moins sécurisée qu'un serveur Debian, mais je parlais plus de la partie desktop.

Les avantages de systemD je l'ai ai répéter 2 fois mais bon comme je suis gentil je vais te les répeter :

il offre une plus grande parallélisation, ayant comme effet un temps de démarrage beaucoup plus court. De 10 secondes à 1 seconde dans certains cas !
La parallélisation est du a en utilisant des sockets et des bus.
Il permet de monter ou démonter les points de montage

Pour les logs (certain on le culot de ce plaindre de cette révolution) ils sont authentifiés afin de réduire les chances de corruptions lors d'un piratage, ils sont portables, et l'outil comporte une gestion de saturation de l'espace disque afin de mieux gérer les traces. Cerise sur le gâteau: tout les services géré par systemd sont automatiquement logué,

[Pilru]

Les avantages de systemD je l'ai ai répéter 2 fois mais bon comme je suis gentil je vais te les répeter :

il offre une plus grande parallélisation, ayant comme effet un temps de démarrage beaucoup plus court. De 10 secondes à 1 seconde dans certains cas !
La parallélisation est du a en utilisant des sockets et des bus.
Il permet de monter ou démonter les points de montage

Pour les logs (certain on le culot de ce plaindre de cette révolution) ils sont authentifiés afin de réduire les chances de corruptions lors d'un piratage, ils sont portables, et l'outil comporte une gestion de saturation de l'espace disque afin de mieux gérer les traces. Cerise sur le gâteau: tout les services géré par systemd sont automatiquement logué,

La parallélisation : Booter en 5 sec au lieu de 20, la belle affaire !
Le (dé)montage des points de montage : Je ne comprend pas l'argument.
Les logs : même authentifiés, cela n’empêchera pas un pirate de vriller les logs pour les rendre illisibles. Et les chances de corruption sont au contraire bien plus grandes. Une erreur dans un fichier texte n’empêche pas de lire le reste. Une erreur dans un fichier binaire et c'est tout le fichier qui est illisible.

Sinon, un fork de systemd existe : uselessd.

[gangsoleil]

Là, c'est encore pire, c'est une querelle de chapelle. Ridicule !

Du point de vue utilisateur, tu as parfaitement raison. Du point de vue développement, c'est tout le contraire : l'explication de Tryph est assez bonne, et je l'imagerai comme ceci : systemD, ça touche les fondations de l'immeuble : l'utilisateur ne les voit pas directement, il ne les utilise pas directement même s'il casse une cloison ou perce un mur porteur, mais tout repose quand même dessus.

Et si l'immeuble s'effondre parce qu'un utilisateur plante un clou, ça va, au minimum, jaser.

Alors attention, je n'ai pas dit que systemD allait faire planter toutes les distrib, je dis que dans un système dont la philosophie est "chacun fait une chose et une seule", le petit nouveau qui fait tout deux fois, il est forcément mal vu.

Et pour ma part, c'est vrai qu'un gros bouzin qui gère tout, je ne suis pas fan,

[Pierre GIRARD]

...Et pour ma part, c'est vrai qu'un gros bouzin qui gère tout, je ne suis pas fan,

Ça, je ne dis pas le contraire, mais de là à faire un Fork, c'est peut-être aller vite en besogne, et à terme, ça risque de faire plus de dégâts qu'autre chose. Mais bon, c'est typique de l'homme en général, quand deux factions se forment, le premier réflexe est de se déclarer la guerre. La discussion, elle vient après.

[Porkepix]

Pour répondre aux nombreuses personnes qui « ne voient pas les dégâts que ça peux causer », c'est pourtant très simple : scission des personnes travaillant sur Debian, moins de contributeurs et donc moins d'évolutions possibles, ou plus de temps à consacrer par contributeur, ou plus de temps pour chaque version etc etc.

Oui, avoir le choix est toujours le mieux lorsque c'est possible (je ne sais pas si c'est possible ou non, je ne connais clairement pas assez le sujet ici pour avancer une affirmation).
Donc pouvoir choisir le système d'init aurait été bien.
À défaut de faire cela, le choix a été donné à la communauté : ce fameux vote a eu lieux, et il a été en faveur de SystemD.

Maintenant, faut voir ce qu'on recherche : oui, gagner un peu de temps au boot (voire même beaucoup) est agréable. Maintenant, sachant qu'on parle aussi beaucoup de serveurs, je suis étonné que personne n'ait fait cette remarque : qui reboote son serveur tous les matins ? Sérieusement ? Les serveurs c'est plutôt réputé pour avoir des uptime de fous.

Une autre solution possible aurait été de travailler à proposer un autre système d'init à la fois rétro-compatible, et regroupant le meilleur de SysVInit et SystemD.

[ddoumeche]

Comme beaucoup je suis sans opinion tranché sur le sujet mais Debian étant une excellente distribution, que j'utilise depuis ses débuts (même si les clients préfèrent Centos), je ne doute pas qu'elle arrivera à surmonter cet écueil.

Ceci dit, je ne pense pas que les forkeurs aient tort sur le principe, ni qu'ils vont forcément se planter. L'historique récent des innovations dans les distributions Linux montre parfois de l'arrogance de la part des innovateurs, des échecs, et une faillite du leadership. L'équilibre est délicat a trouver.

Linus Torvald qui a une certaine expérience sur la conduite de projets open source et parfois une vision de l'avenir de Linux a dit :

"I don't actually have any particularly strong opinions on systemd itself. I've had issues with some of the core developers that I think are much too cavalier about bugs and compatibility, and I think some of the design details are insane (I dislike the binary logs, for example), but those are details, not big issues..."

A suivre sur http://www.zdnet.com/linus-torvalds-...md-7000033847/

[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à.

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.

[RyzenOC]

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.

[redcurve]

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

Pop-corn time

[Ookaze]

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.

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.

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.

[RyzenOC]

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.

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

Oui je confirme...

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.