Systemd c'est de la merde de par sa conception. Et je vais vous dire de manière succinte pourquoi
Déjà c'est quoi les bidules trucs init me demanderez vous. Eh bien init est le premier processus lancé au démarrage du système. C'est un daemon qui continue à fonctionner jusqu'à ce que le système soit arrêté
Ensuite c'est quoi systemd ?
Bien qu'il offre des améliorations séduisantes par rapport aux anciens systèmes init il apporte également des régressions majeures dans de nombreux domaines où Linux est censé exceller : la sécurité, la stabilité et le fait de ne pas avoir à redémarrer pour mettre à jour son système
LE PREMIER PROBLÈME : PID 1
Sur les systèmes Unix, le PID 1 est spécial. Les process orphelins sont repartis vers PID 1. Il existe également une sémantique spéciale des signaux en ce qui concerne PID 1 et, ce qui est peut-être le plus important, si PID 1 se plante ou quitte le système, tout le système s'arrête (kernel panic)
Parmi les raisons pour lesquelles systemd veut/doit fonctionner en tant que PID 1, il y a le fait d'obtenir la paternité de daemons qui se rendent orphelins, empêchant leur parent immédiat de connaître leur PID pour leur envoyer des signaux
Malheureusement, il obtient également les autres propriétés, y compris l'arrêt du système entier lorsqu'il se bloque. Ceci est important car systemd est complexe. Beaucoup plus complexe que les systèmes init traditionnels. Quand je dis complexe, je ne parle pas de lignes de code. Je veux dire en termes d'entrées possibles et de chemins de code qui peuvent être activés au moment de l'exécution. Alors que les systèmes d'initialisation traditionnels ne traitent fondamentalement aucune entrée, à l'exception de SIGCHLD provenant de processus orphelins qui se terminent et de modifications manuelles du niveau d'exécution effectuées par l'administrateur, systemd traite toutes sortes d'entrées, y compris l'insertion et la suppression de périphériques, les modifications des points de montage dans le système de fichiers, et même une API publique basée sur DBus. Celles-ci impliquent à leur tour l'allocation de ressources, l'analyse de fichiers, l'analyse de messages, la gestion de chaînes de caractères, etc. Cela nous amène à ce qui suit :
LE DEUXIÈME PROBLÈME : la surface d'attaque
Sur un système hardened correctement sans systemd, il n'y a qu'un seul processus avec un privilège root qui dispose d'une surface exposée : sshd. Tous les autres processus sont exécutés en tant qu'utilisateurs non privilégiés ou ne disposent d'aucun canal pour leur fournir des informations, à l'exception des informations locales provenant de la racine. L'utilisation de systemd fait donc plus que doubler la surface d'attaque
Ce risque accru n'est pas inhérent à l'objectif de systemd de corriger l'ancien système init. Cependant, il est inhérent à la philosophie de conception de systemd qui consiste à tout foutre dans le processus init sans aucune vergogne ou pitié
LE TROISIÈME PROBLÈME : Redémarrer pour MAJ
Fondamentalement, la MAJ ne devrait JAMAIS nécessiter un redémarrage, sauf si le composant mis à jour est le kernel. Même dans ce cas, pour les mises à jour de sécurité, l'idéal est d'avoir un hot patch qui peut être appliqué en tant que module du kernel chargeable pour atténuer le problème de sécurité jusqu'à ce que le redémarrage avec le nouveau kernel soit approprié
Malheureusement, en déplaçant de grandes quantités de fonctionnalités susceptibles de devoir être mises à jour dans le PID 1, systemd rend impossible la mise à jour sans redémarrage. Cela conduit à ce que "Linux" devienne la risée des fans de Windaube, comme cela s'est produit avec Ubuntu il y a longtemps
LA SOLUTION :
Coller à la méthode Unix : avec des programmes simples et autonomes qui ne font qu'une chose et la font bien !
Essayez d'utiliser des distros sans cette merde, comme Artix, Void, Gentoo (si vous mettez autre chose genre openrc). Ou sinon utilisez des BSD
Déjà c'est quoi les bidules trucs init me demanderez vous. Eh bien init est le premier processus lancé au démarrage du système. C'est un daemon qui continue à fonctionner jusqu'à ce que le système soit arrêté
Ensuite c'est quoi systemd ?
Bien qu'il offre des améliorations séduisantes par rapport aux anciens systèmes init il apporte également des régressions majeures dans de nombreux domaines où Linux est censé exceller : la sécurité, la stabilité et le fait de ne pas avoir à redémarrer pour mettre à jour son système
LE PREMIER PROBLÈME : PID 1
Sur les systèmes Unix, le PID 1 est spécial. Les process orphelins sont repartis vers PID 1. Il existe également une sémantique spéciale des signaux en ce qui concerne PID 1 et, ce qui est peut-être le plus important, si PID 1 se plante ou quitte le système, tout le système s'arrête (kernel panic)
Parmi les raisons pour lesquelles systemd veut/doit fonctionner en tant que PID 1, il y a le fait d'obtenir la paternité de daemons qui se rendent orphelins, empêchant leur parent immédiat de connaître leur PID pour leur envoyer des signaux
Malheureusement, il obtient également les autres propriétés, y compris l'arrêt du système entier lorsqu'il se bloque. Ceci est important car systemd est complexe. Beaucoup plus complexe que les systèmes init traditionnels. Quand je dis complexe, je ne parle pas de lignes de code. Je veux dire en termes d'entrées possibles et de chemins de code qui peuvent être activés au moment de l'exécution. Alors que les systèmes d'initialisation traditionnels ne traitent fondamentalement aucune entrée, à l'exception de SIGCHLD provenant de processus orphelins qui se terminent et de modifications manuelles du niveau d'exécution effectuées par l'administrateur, systemd traite toutes sortes d'entrées, y compris l'insertion et la suppression de périphériques, les modifications des points de montage dans le système de fichiers, et même une API publique basée sur DBus. Celles-ci impliquent à leur tour l'allocation de ressources, l'analyse de fichiers, l'analyse de messages, la gestion de chaînes de caractères, etc. Cela nous amène à ce qui suit :
LE DEUXIÈME PROBLÈME : la surface d'attaque
Sur un système hardened correctement sans systemd, il n'y a qu'un seul processus avec un privilège root qui dispose d'une surface exposée : sshd. Tous les autres processus sont exécutés en tant qu'utilisateurs non privilégiés ou ne disposent d'aucun canal pour leur fournir des informations, à l'exception des informations locales provenant de la racine. L'utilisation de systemd fait donc plus que doubler la surface d'attaque
Ce risque accru n'est pas inhérent à l'objectif de systemd de corriger l'ancien système init. Cependant, il est inhérent à la philosophie de conception de systemd qui consiste à tout foutre dans le processus init sans aucune vergogne ou pitié
LE TROISIÈME PROBLÈME : Redémarrer pour MAJ
Fondamentalement, la MAJ ne devrait JAMAIS nécessiter un redémarrage, sauf si le composant mis à jour est le kernel. Même dans ce cas, pour les mises à jour de sécurité, l'idéal est d'avoir un hot patch qui peut être appliqué en tant que module du kernel chargeable pour atténuer le problème de sécurité jusqu'à ce que le redémarrage avec le nouveau kernel soit approprié
Malheureusement, en déplaçant de grandes quantités de fonctionnalités susceptibles de devoir être mises à jour dans le PID 1, systemd rend impossible la mise à jour sans redémarrage. Cela conduit à ce que "Linux" devienne la risée des fans de Windaube, comme cela s'est produit avec Ubuntu il y a longtemps
LA SOLUTION :
Coller à la méthode Unix : avec des programmes simples et autonomes qui ne font qu'une chose et la font bien !
Essayez d'utiliser des distros sans cette merde, comme Artix, Void, Gentoo (si vous mettez autre chose genre openrc). Ou sinon utilisez des BSD
Reactor Online. Sensors Online. Weapons Online. All Systems Nominal.
Reactor Online. Sensors Online. Weapons Online. All Systems Nominal.
Bon courage pour Linux khey, ça peut être un peu casse couilles au début car y'a pas mal de machins à comprendre et de trucs complètement différents qu'avec Windows. Ça et le fait que tu puisses absolument tout bidouiller, ABSOLUMENT tout (meme si certains trucs faut éviter d'y toucher quand même
), mais avec le temps tu t'habitueras et ça deviendra assez naturel, tu auras une liberté absolue
J'espère que ce pavé te pousseras à éviter systemd
J'espère que ce pavé te pousseras à éviter systemd
Reactor Online. Sensors Online. Weapons Online. All Systems Nominal.
Reactor Online. Sensors Online. Weapons Online. All Systems Nominal.
Autiste
Linux
Autiste
Non
Reactor Online. Sensors Online. Weapons Online. All Systems Nominal.
Linux
Quoi ?
Reactor Online. Sensors Online. Weapons Online. All Systems Nominal.
Il y a SystemD sur Ubuntu ?
Il y a SystemD sur Ubuntu ?
Oui malheureusement. Après je recommande vraiment pas Ubuntu, c'est bloated, leur GNOME est fini à la pisse et canonical force avec des trucs de merde genre les snap
Reactor Online. Sensors Online. Weapons Online. All Systems Nominal.
Oui malheureusement. Après je recommande vraiment pas Ubuntu, c'est bloated, leur GNOME est fini à la pisse et canonical force avec des trucs de merde genre les snap
Je suis sous Ubuntu, est-ce que ça changerait quelque chose à ma vie si je changeais de distribution ?
Je suis sous Ubuntu, est-ce que ça changerait quelque chose à ma vie si je changeais de distribution ?
Ubuntu c'est complètement bloated, passe sous Debian au pire ça te changera pas trop étant donné qu'Ubuntu est basé sur Debian
Après j'ai personnellement du mal avec Debian, mais je suis partisan du "à chacun son système, à chacun ses besoins, à chacun son OS". Si Ubuntu te plait, passe juste sur Debian et tu verras que c'est mieux
Mais sache que rien qu'avec systemd tu auras des problèmes quoi (et Debian utilise aussi systemd)
Après j'ai personnellement du mal avec Debian, mais je suis partisan du "à chacun son système, à chacun ses besoins, à chacun son OS". Si Ubuntu te plait, passe juste sur Debian et tu verras que c'est mieux
Mais sache que rien qu'avec systemd tu auras des problèmes quoi (et Debian utilise aussi systemd)
Reactor Online. Sensors Online. Weapons Online. All Systems Nominal.
C'est quoi concrètement et historiquement systemd ? Pourquoi c'est utilisé notamment ?
Si jamais vous vous demandez d'où vient mon badge golem : 
Sortez le pavé Linux !
C'est quoi concrètement et historiquement systemd ? Pourquoi c'est utilisé notamment ?
Systemd prétend être un remplaçant "moderne et efficace" de SysVinit, un daemon d'initialisation. C'est le premier processus lancé par le kernel et a donc le PID 1. Il est responsable de la création d'autres daemons nécessaires au fonctionnement du système d'exploitation, par exemple le réseau, cron, syslog, etc...
Bien qu'il soit en effet plus moderne et complexe, il a plein de problèmes qui sont souvent oubliés et de trucs vraiment pas ouf. Mais il s'est un peu imposé comme init "par défaut" dans les distros linux avec le temps
Bien qu'il soit en effet plus moderne et complexe, il a plein de problèmes qui sont souvent oubliés et de trucs vraiment pas ouf. Mais il s'est un peu imposé comme init "par défaut" dans les distros linux avec le temps
Reactor Online. Sensors Online. Weapons Online. All Systems Nominal.
Systemd prétend être un remplaçant "moderne et efficace" de SysVinit, un daemon d'initialisation. C'est le premier processus lancé par le kernel et a donc le PID 1. Il est responsable de la création d'autres daemons nécessaires au fonctionnement du système d'exploitation, par exemple le réseau, cron, syslog, etc...
Bien qu'il soit en effet plus moderne et complexe, il a plein de problèmes qui sont souvent oubliés et de trucs vraiment pas ouf. Mais il s'est un peu imposé comme init "par défaut" dans les distros linux avec le temps
Bien qu'il soit en effet plus moderne et complexe, il a plein de problèmes qui sont souvent oubliés et de trucs vraiment pas ouf. Mais il s'est un peu imposé comme init "par défaut" dans les distros linux avec le temps
Je vois, c'est instructif merci
Si jamais vous vous demandez d'où vient mon badge golem :
Systemd c'est de la merde de par sa conception. Et je vais vous dire de manière succinte pourquoi
Déjà c'est quoi les bidules trucs init me demanderez vous. Eh bien init est le premier processus lancé au démarrage du système. C'est un daemon qui continue à fonctionner jusqu'à ce que le système soit arrêté
Ensuite c'est quoi systemd ?
Bien qu'il offre des améliorations séduisantes par rapport aux anciens systèmes init il apporte également des régressions majeures dans de nombreux domaines où Linux est censé exceller : la sécurité, la stabilité et le fait de ne pas avoir à redémarrer pour mettre à jour son système
LE PREMIER PROBLÈME : PID 1
Sur les systèmes Unix, le PID 1 est spécial. Les process orphelins sont repartis vers PID 1. Il existe également une sémantique spéciale des signaux en ce qui concerne PID 1 et, ce qui est peut-être le plus important, si PID 1 se plante ou quitte le système, tout le système s'arrête (kernel panic)
Parmi les raisons pour lesquelles systemd veut/doit fonctionner en tant que PID 1, il y a le fait d'obtenir la paternité de daemons qui se rendent orphelins, empêchant leur parent immédiat de connaître leur PID pour leur envoyer des signaux
Malheureusement, il obtient également les autres propriétés, y compris l'arrêt du système entier lorsqu'il se bloque. Ceci est important car systemd est complexe. Beaucoup plus complexe que les systèmes init traditionnels. Quand je dis complexe, je ne parle pas de lignes de code. Je veux dire en termes d'entrées possibles et de chemins de code qui peuvent être activés au moment de l'exécution. Alors que les systèmes d'initialisation traditionnels ne traitent fondamentalement aucune entrée, à l'exception de SIGCHLD provenant de processus orphelins qui se terminent et de modifications manuelles du niveau d'exécution effectuées par l'administrateur, systemd traite toutes sortes d'entrées, y compris l'insertion et la suppression de périphériques, les modifications des points de montage dans le système de fichiers, et même une API publique basée sur DBus. Celles-ci impliquent à leur tour l'allocation de ressources, l'analyse de fichiers, l'analyse de messages, la gestion de chaînes de caractères, etc. Cela nous amène à ce qui suit :
LE DEUXIÈME PROBLÈME : la surface d'attaque
Sur un système hardened correctement sans systemd, il n'y a qu'un seul processus avec un privilège root qui dispose d'une surface exposée : sshd. Tous les autres processus sont exécutés en tant qu'utilisateurs non privilégiés ou ne disposent d'aucun canal pour leur fournir des informations, à l'exception des informations locales provenant de la racine. L'utilisation de systemd fait donc plus que doubler la surface d'attaque
Ce risque accru n'est pas inhérent à l'objectif de systemd de corriger l'ancien système init. Cependant, il est inhérent à la philosophie de conception de systemd qui consiste à tout foutre dans le processus init sans aucune vergogne ou pitié
LE TROISIÈME PROBLÈME : Redémarrer pour MAJ
Fondamentalement, la MAJ ne devrait JAMAIS nécessiter un redémarrage, sauf si le composant mis à jour est le kernel. Même dans ce cas, pour les mises à jour de sécurité, l'idéal est d'avoir un hot patch qui peut être appliqué en tant que module du kernel chargeable pour atténuer le problème de sécurité jusqu'à ce que le redémarrage avec le nouveau kernel soit approprié
Malheureusement, en déplaçant de grandes quantités de fonctionnalités susceptibles de devoir être mises à jour dans le PID 1, systemd rend impossible la mise à jour sans redémarrage. Cela conduit à ce que "Linux" devienne la risée des fans de Windaube, comme cela s'est produit avec Ubuntu il y a longtemps
LA SOLUTION :
Coller à la méthode Unix : avec des programmes simples et autonomes qui ne font qu'une chose et la font bien !
Essayez d'utiliser des distros sans cette merde, comme Artix, Void, Gentoo (si vous mettez autre chose genre openrc). Ou sinon utilisez des BSD
Déjà c'est quoi les bidules trucs init me demanderez vous. Eh bien init est le premier processus lancé au démarrage du système. C'est un daemon qui continue à fonctionner jusqu'à ce que le système soit arrêté
Ensuite c'est quoi systemd ?
Bien qu'il offre des améliorations séduisantes par rapport aux anciens systèmes init il apporte également des régressions majeures dans de nombreux domaines où Linux est censé exceller : la sécurité, la stabilité et le fait de ne pas avoir à redémarrer pour mettre à jour son système
LE PREMIER PROBLÈME : PID 1
Sur les systèmes Unix, le PID 1 est spécial. Les process orphelins sont repartis vers PID 1. Il existe également une sémantique spéciale des signaux en ce qui concerne PID 1 et, ce qui est peut-être le plus important, si PID 1 se plante ou quitte le système, tout le système s'arrête (kernel panic)
Parmi les raisons pour lesquelles systemd veut/doit fonctionner en tant que PID 1, il y a le fait d'obtenir la paternité de daemons qui se rendent orphelins, empêchant leur parent immédiat de connaître leur PID pour leur envoyer des signaux
Malheureusement, il obtient également les autres propriétés, y compris l'arrêt du système entier lorsqu'il se bloque. Ceci est important car systemd est complexe. Beaucoup plus complexe que les systèmes init traditionnels. Quand je dis complexe, je ne parle pas de lignes de code. Je veux dire en termes d'entrées possibles et de chemins de code qui peuvent être activés au moment de l'exécution. Alors que les systèmes d'initialisation traditionnels ne traitent fondamentalement aucune entrée, à l'exception de SIGCHLD provenant de processus orphelins qui se terminent et de modifications manuelles du niveau d'exécution effectuées par l'administrateur, systemd traite toutes sortes d'entrées, y compris l'insertion et la suppression de périphériques, les modifications des points de montage dans le système de fichiers, et même une API publique basée sur DBus. Celles-ci impliquent à leur tour l'allocation de ressources, l'analyse de fichiers, l'analyse de messages, la gestion de chaînes de caractères, etc. Cela nous amène à ce qui suit :
LE DEUXIÈME PROBLÈME : la surface d'attaque
Sur un système hardened correctement sans systemd, il n'y a qu'un seul processus avec un privilège root qui dispose d'une surface exposée : sshd. Tous les autres processus sont exécutés en tant qu'utilisateurs non privilégiés ou ne disposent d'aucun canal pour leur fournir des informations, à l'exception des informations locales provenant de la racine. L'utilisation de systemd fait donc plus que doubler la surface d'attaque
Ce risque accru n'est pas inhérent à l'objectif de systemd de corriger l'ancien système init. Cependant, il est inhérent à la philosophie de conception de systemd qui consiste à tout foutre dans le processus init sans aucune vergogne ou pitié
LE TROISIÈME PROBLÈME : Redémarrer pour MAJ
Fondamentalement, la MAJ ne devrait JAMAIS nécessiter un redémarrage, sauf si le composant mis à jour est le kernel. Même dans ce cas, pour les mises à jour de sécurité, l'idéal est d'avoir un hot patch qui peut être appliqué en tant que module du kernel chargeable pour atténuer le problème de sécurité jusqu'à ce que le redémarrage avec le nouveau kernel soit approprié
Malheureusement, en déplaçant de grandes quantités de fonctionnalités susceptibles de devoir être mises à jour dans le PID 1, systemd rend impossible la mise à jour sans redémarrage. Cela conduit à ce que "Linux" devienne la risée des fans de Windaube, comme cela s'est produit avec Ubuntu il y a longtemps
LA SOLUTION :
Coller à la méthode Unix : avec des programmes simples et autonomes qui ne font qu'une chose et la font bien !
Essayez d'utiliser des distros sans cette merde, comme Artix, Void, Gentoo (si vous mettez autre chose genre openrc). Ou sinon utilisez des BSD
Tu oublies de dire que grâce à systemd quand on branche une imprimante ou un appareil quelconque le pilote s'installe automatiquement dans la plupart des cas.
Avec les distributions sans systemd il faut bidouiller des lignes de commande pour que l'appareil branché fonctionne
Avec les distributions sans systemd il faut bidouiller des lignes de commande pour que l'appareil branché fonctionne
En ligne
203
Sur ce sujet0