systemd est un projet composé de trois parties distinctes :
- un processus d’initialisation,
systemd, qui s’occupe de gérer le démarrage, du lancement du noyau Linux à l’interface graphique, et de la surveillance des processus ; - un ensemble d’outils qui contrôlent le processus systemd, notamment
systemctl, et qui permettent, entre autres, de suivre, redémarrer et arrêter les différents services d’une machine ; - un jeu d’outils qui peuvent être utilisés comme base pour la création d’un système d’exploitation complet — un peu à la manière de ce que le projet GNU propose, mais avec une portabilité beaucoup plus réduite.
La première version de systemd a été publiée le 30 mars 2010. Presque cinq ans plus tard, quasiment toutes les distributions majeures l’ont adopté.
Remplaçant un composant central du système, il n’est pas étonnant que l’arrivée de systemd ait provoqué de nombreuses réactions. Elles ont parfois été violentes, mais pourquoi au juste ?
Cette dépêche éminemment collective (à peu près tous les contributeurs habituels sont venus participer, pour faire court) présente un état des lieux des opinions en présence, dans une démarche de remise à plat et d’apaisement, un peu similaire à celle entreprise ici ou là et visible ici.
Sommaire
- Introduction
- Arguments et points de débat
- Conclusion
- Les titres de dépêche auxquels vous avez échappé
Introduction
Les discussions sont souvent enflammées concernant systemd, et comme le sujet est un peu technique, il est parfois difficile de s’y retrouver. Pas de panique, il vous est expliqué de façon simple ce qu’est systemd, comment il se démarque des systèmes qu’il est censé remplacer, ainsi que les arguments des parties en présence.
Démarrage du système
Lorsqu’un ordinateur démarre, il initialise les différents composants de l’ordinateur (processeur, mémoire vive, disque dur, carte graphique, etc.) et effectue quelques vérifications basiques, puis démarre le cœur du système d’exploitation : le noyau (ici, Linux). En effet, c’est la partie qui communique directement avec les périphériques comme le clavier, la souris, la mémoire ou l’écran et permet leur utilisation.
Lorsque le noyau est chargé, l’ordinateur n’est pas encore prêt à l’emploi. Le noyau délègue au système d’initialisation le lancement du reste du système, selon la configuration établie par l'administrateur. Il lance les services d'arrière-plan (montage des périphériques de stockage, configuration du réseau, messagerie…) et l'interface utilisateur, qu’elle soit graphique ou pas. Le système d’initialisation possède aussi une autre fonction : récupérer les processus qui sortent de leur session. En effet, dans tous les Unix-like—et cela inclut GNU/Linux—tous les processus doivent avoir au moins un processus père, sauf le tout premier processus lancé (PID 1). Si un processus renie son père (on dit qu'il est démonisé), le noyau le rattache alors au premier processus.
Hormis le noyau, il est donc le premier processus lancé sur la machine (ce qui explique l’appellation « PID 1 » — « processus n°1 ») et le dernier à s'arrêter, car il contrôle tous les autres. Par conséquent, le système d’initialisation est un composant critique du système car s’il ne fonctionne pas, la machine ne démarre pas. D’où sa robustesse requise.
Jusqu'à récemment ce programme était souvent SysVinit, mais des remplaçants, plus ou moins compatibles, se sont multipliés ces dernières années, comme Upstart qui est l'init par défaut d'Ubuntu. Un init de type SysV fonctionne comme suit : il lit le fichier /etc/inittab qui lui indique quoi faire à un niveau d'exécution (runlevel) particulier, puis il démarre, redémarre ou arrête automatiquement les services selon le niveau choisi par l'utilisateur.
La syntaxe de ce fichier n’étant pas turing complète, les administrateurs ont préféré déléguer l’essentiel du démarrage à des scripts rc nommés dans ce fichier et appelés par init.
Ces scripts sont aujourd’hui décriés à cause du travail dupliqué entre les distributions, de la difficulté réelle ou supposée de les maintenir et de leurs limites. Sont-elles supposées ou avérées ? Là est toute la question ! Quelques exemples :
tous ne sont pas, par exemple, forcément compatibles avec des composants tels que selinux (ou autre LSM à la mode) ;
il est difficile de lancer un service uniquement suite à un événement. Par exemple, lors du branchement d’une clé USB ;
il est difficile de s'assurer qu'un service (par exemple, sshd) sera relancé automatiquement en cas d'arrêt.
Le système d’init nécessite un travail d’intégration important dans la distribution ; il ne peut donc pas, la plupart du temps, être changé facilement par l’utilisateur.
Adoption de systemd
(bonus image Commitstrip : Systemd World : le parc est ouvert)
systemd est utilisé ou sera utilisé sur :
- Fedora depuis presque 4 ans,
- openSUSE, Mageia, Arch Linux depuis plus de 2 ans,
- RHEL (Red Hat Entreprise Linux) et SLES (SUSE Linux Entreprise Server) depuis moins d’un an,
- Debian 8.0 et Ubuntu 15.04.
Il y a cependant deux absents parmi les distributions majeures :
- Gentoo, qui utilise par défaut OpenRC (une implémentation moderne du format traditionnel SysV), mais laisse la possibilité d’utiliser systemd ;
- Slackware, dont la philosophie l’a souvent poussé à adopter les nouvelles technologies bien après les autres distributions.
Dans les distributions moins connues, on peut aussi citer Linuxconsole ou Crux.
C’est un logiciel relativement jeune pour un composant d’une telle importance. Son adoption a été fulgurante et beaucoup de personnes pensent que ce changement a été trop rapide, pas assez réfléchi, voire carrément forcé.
En dehors de l’adoption des logiciels eux-mêmes, la philosophie de systemd a rencontré de l’écho auprès de FreeBSD qui envisage de développer un système d’initialisation dont le fonctionnement est plus proche de systemd.
Qu’est‐ce qui différencie systemd du système précédent ?
Tout d’abord, quelques explications techniques.
Le projet systemd est écrit avec le langage de programmation C. Il s’agit d’une collection de logiciels sous forme de binaires. Le pilotage des services se fait grâce à des fichiers de configuration.
À première vue, cela ressemble à SysV (écrit en C, formé de trois exécutables et configuré par le fichier « inittab »), mais la grande différence est que SysV suit une approche minimaliste qui déplace une grande partie de l'initialisation des services dans des programmes écrits en Shell et utilisant des bibliothèques externes (par exemple, « start-stop-daemon » pour l'init Debian). À contrario, systemd implémente un large éventail d'actions afin de décourager l'utilisation de scripts de lancement. En pratique, un service SysV pour sshd a pour élément central un script de quelques centaines de lignes (script Shell qui peut être utilisé indépendamment de l'init), alors que sous systemd le service sera généralement piloté par un fichier texte d'une dizaine de lignes (dans une syntaxe spécifique à systemd).
On vante souvent la simplicité des anciens systèmes d’init : en effet, quoi de plus simple que des fichiers textes exécutables, certes pas forcément triviaux, mais dont on peut lire l’exécution ligne par ligne ?
En éditant ces fichiers, on a une maîtrise totale du démarrage de l’ordinateur (à partir du moment où l’on est capable de comprendre le code). Mais modifier le système d’init en lui-même peut poser problème lors de mises à jour ou simplement parce que ce code n’a pas été testé.
Systemd remplit les mêmes fonctions que les précédents systèmes, mais il met l’accent sur la simplicité d’utilisation et sur une maîtrise du système plus poussée et moins éparpillée, ce qui est parfois vu comme l’opposé de la philosophie Unix.
Ainsi, beaucoup de choses qui nécessitaient auparavant de modifier des scripts Shell existent maintenant sous la forme d’un simple paramètre dans un fichier. Le comportement est codé dans systemd ce qui permet de mutualiser beaucoup de code et de rendre les fichiers souvent beaucoup plus courts.
Pour la plupart des gens, utiliser systemd ou SysVinit ne fait aucune différence, y compris pour la vitesse de démarrage ; pour bidouiller, tout dépend des outils que l'on maîtrise, soit les outils systemd et leur syntaxe de configuration, soit la programmation Shell, les outils de suivi de processus et la configuration SysV.
Alternatives
Upstart
Créé pour Ubuntu, est la seule alternative adoptée par des distributions de famille différentes (RHEL et Fedora, openSUSE). Aujourd’hui, la décision de Debian d’adopter systemd pour sa prochaine version stable a poussé Ubuntu à lui emboiter le pas, Upstart sera donc probablement abandonné.
OpenRC
Développé et utilisé par Gentoo, est l’alternative à systemd la plus souvent citée. Elle est basée sur un init SysV traditionnel, un cœur en C compilé et des scripts Shell. Pour résumer, OpenRC est plus simple, son cœur possède moins de fonctionnalités que systemd et il ne dépend pas de Linux.
Uselessd
C'est un fork jeune et non-stable de systemd. De nombreuses fonctionnalités ont été supprimé, et on peut utiliser musl ou uClibc (principalement pour l’embarqué, mais pas uniquement : par exemple des distributions légères comme Alpine y ont recours) là où l’auteur principal de systemd refuse de prendre en compte d’autres libc que la glibc.
D'autres systèmes d'init moins connus ont aussi vu le jour par le passé : on se souvient du système d'init de Pardus, de InitNG, d’expérimentations à base de make -j …, de runit, fastboot et d'autres encore. Aucun d'eux n'a percé, même si certains véhiculaient de bonnes idées.
À la suite du rejet par le comité Debian de maintenir par défaut deux systèmes d’initialisation différents, les responsables du site Debian fork ont annoncé qu’ils forkeraient effectivement Debian. La distribution, nommée Devuan, sera donc une Debian sans systemd. Une collecte de fonds a été lancée pour soutenir le démarrage du projet. Le système d’initialisation de Devuan n'est pas encore connu.
Apports de systemd
Comme on le voit, l’adoption de systemd est loin de s’être faite sans heurts. Quels avantages ont permis à systemd de contrebalancer l’avalanche de critiques, lors des décisions concernant son adoption ?
Tout d’abord, techniquement, il ne faut pas perdre de vue que systemd apporte certaines fonctionnalités qui ne se retrouvaient pas dans l’ancien système. En voici une liste non-exhaustive :
- Allocation fine des ressources (processeur, mémoire, E/S, etc) aux services, grâce aux fonctionnalités avancées du noyau comme les cgroups ;
- Surveillance améliorée (grâce aux cgroups, un processus ne peut pas s'échapper, même en forkant) ;
- Log plus complet (commençant plus tôt, comprenant aussi la sortie standard et les sous-processus, proposant un aperçu centralisé de l’état des services ou un résumé des erreurs de démarrage…) ;
- Possibilité de démoniser tout processus en le relançant automatiquement s'il s'arrête (à la façon de "runit", bien au-delà de ce que permet "start-stop-daemon") ;
- Séparation claire entre les services fournis par la distribution et les services créés par l’administrateur, avec la possibilité pour l’administrateur de personnaliser les scripts de la distribution sans avoir à les dupliquer ;
- Système de template dans les unités de lancement (par exemple un seul fichier getty@.service peut être utilisé pour gérer un nombre arbitraire d’instances : getty@tty1.service, getty@tty2.service…).
À un niveau moins technique, systemd est le seul projet à apporter les espoirs suivants dans le monde GNU/Linux :
- Centralisation du développement des briques de base du système, ce qui permet une certaine normalisation entre différentes distributions GNU/Linux ;
- Simplification du processus d’empaquetage des services en maintenant un seul fichier service en amont ;
- Normalisation des formats de logs, grâce à journald.
Ces points sont moins techniques car auraient très bien pu être réalisés avec l’ancien système pour peu que les distributions et les différents projets aient pu se mettre d’accord ; il reste toutefois au crédit du projet systemd d’avoir réussi à lancer cette dynamique.
Arguments et points de débat
Philosophie UNIX
La philosophie UNIX est plutôt : au lieu d’écrire un gros logiciel pour résoudre un problème, écrire plein de petits logiciels qui se concentrent sur une étape de la résolution du problème, fonctionnent orthogonalement et utilisent un protocole clair. L’intérêt est qu’avec cette stratégie, il est beaucoup plus facile d’adapter son travail pour résoudre un problème « voisin » et qu’on résout potentiellement beaucoup plus de problèmes (plus les composants sont orthogonaux, plus la combinatoire de ces composants est intéressante). Cf. : http://marmaro.de/docs/studium/unix-phil/unix-phil.pdf.
La limite de ce modèle est quand diverses couches doivent intervenir. Les logiciels sont alors sur des sables mouvants, les interdépendances devenant importantes. Il est quasi impossible de faire évoluer les logiciels indépendamment. L'exemple typique est la crosscompilation de Linux, GCC et la libc qui ne fonctionnent que pour des versions bien précises.
Un des reproches que l'on fait souvent à systemd est son non-respect de la philosophie Unix. Son résumé le plus connu est celui fait par Douglas McIlroy :
Écrire un bon programme qui ne réalise qu’une seule tâche. Écrire des programmes coopérant entre eux. Écrire des programmes qui gèrent des flots de données textuelles, car cette interface est universelle.
Comme tous les aphorismes, derrière ces quelques mots se cache une réalité plus complexe ; ainsi, Eric Raymond décrit environ 17 règles, qu’il explicite dans son livre L'Art de la Programmation Unix. On peut par exemple y lire (chapitre 4) une mise en garde contre une interprétation trop superficielle de cette citation :
Le conseil de Doug McIlroy « faire une seule chose, et la faire bien » est souvent compris comme un conseil de simplicité. En fait, il porte aussi sur l’orthogonalité, ce qui est au moins aussi important.
L’orthogonalité est importante car elle garantit l'indépendance réelle. Ainsi l'usage du texte comme format d'échange est primitif, mais a le bon goût de rester un format stable dans le temps.
Autrement dit, dans la philosophie Unix, l’approche pour résoudre un problème est d’écrire plein de petits logiciels qui se concentrent sur une étape de la résolution du problème, fonctionnent orthogonalement et utilisent un protocole clair, au lieu d'écrire un gros logiciel.
De ce point de vue, la principale critique faite à systemd est de ne pas respecter ces principes d’indépendance et d’orthogonalité (on ne peut pas, par exemple, séparer la gestion du cycle de vie des services de la gestion des cgroups). Pire encore, systemd tend à détruire l’orthogonalité dans des parties qui l’étaient précédemment ; ainsi Lennart a annoncé récemment que udev nécessiterait systemd, alors que les deux problématiques « gestion du matériel » et « gestion de l’initialisation du système » étaient clairement séparées auparavant.
Le monde des Unix-like possède en fait plusieurs philosophies — qui toutes tendent vers le même but : rassurer l'utilisateur et l'administrateur système. La chose la plus importante pour une entreprise (ou pour un professionnel de façon générale) est la pérennité de ce qu'il crée. Rien n'est plus désagréable que de mettre en place une méthode de travail pour créer des outils et des produits et de devoir tout mettre à la poubelle du jour au lendemain pour cause de changement massif dans la technologie. C'est parfois nécessaire, la technologie évoluant, mais c'est rarement bien accueilli.
De fait, les différentes philosophies existantes dans le libre sont là pour permettre aux professionnels de s'investir sereinement dans une technologie. Parmi les plus populaires, on a le KISS (Keep It Simple, Stupid), le rasoir d'Ockham et le Don't Repeat Yourself.
De plus, chaque gros projet a une philosophie ou, en tout cas, met l'emphase sur un aspect de leur stratégie de développement, toujours dans le but de rassurer l'utilisateur.
Pour le noyau Linux, le mot d'ordre est : « ne jamais casser l'expérience utilisateur ». En d'autres termes une correction ne doit jamais entraîner de régressions touchant l'espace utilisateur (Linus est très attaché à cela).
Pour FreeBSD, il s'agit de respecter le principe de la moindre surprise. Pour OpenBSD, le but est la sécurité et la chose la plus mise en avant est le respect de séparation des privilèges.
Concrètement, chaque outil de systemd fait une chose et la fait bien et tous ces outils sont développés ensemble afin de fournir une « boîte à outils » cohérente, un peu comme certains *BSD maintiennent tout un tas d’outils de base dans un même dépôt.
Systemd en tant qu'ensemble se focalise grandement sur l'aspect « Don't Repeat Yourself » les redondances de code sont limitées au maximum et les étapes de démarrage sont factorisées autant que possible. Cela garantit une bonne maintenabilité du code et évite de devoir agir sur plusieurs éléments séparés du code pour corriger un problème. Et il s'appuie aussi une approche type « rasoir d'Ockham », on enlève tout ce qui n'est pas strictement nécessaire. Repenser le PID 1.
Cependant, l'approche a des défauts, le PID 1 (systemd init) se retrouve à faire de très nombreuses choses (démarrage, suivi, restrictions de droits, application de cgroups, escalade de privilèges, changements de priorité, etc.). C'est une conséquence de la factorisation du code, les fonctions qui permettent (par exemple) de lancer, arrêter et suivre un processus sont souvent très liées, pour éviter de dupliquer du code il faut donc que ces fonctions soient dans le même processus.
Un autre défaut de l'approche systemd est que de nombreux processus deviennent fortement interdépendants. L'init systemd a absolument besoin de udev et de journald pour fonctionner par exemple, et bien que les binaires soient disjoints - ils sont fortement couplés (cf section plus bas).
Pour finir, dans un souci de simplicité et pour conserver la maintenabilité du projet dans son ensemble, systemd n'hésite pas à couper les ponts avec l'existant ou à intégrer des fonctionnalités de base dans son sein, puis à les faire évoluer dans son sens.
C'est sûrement ce dernier aspect qui pose le plus de problèmes, notamment avec l'intégration de udev (processus chargé de matérialiser coté utilisateur les différents périphériques connectés) dans le projet systemd. En l'absence de vision claire la distribution Gentoo a décidé de forker udev (c.-à.-d. développer en parallèle une version plus adaptée à leurs besoins) udev-ng vs eudev
Dans cet article, Greg KH annonce que le projet systemd n'a pas de buts à long terme bien définis, mais qu'il va forcer la main des distributions pour qu'elles suivent une structure dans laquelle les modifications sont sous contrôle, plutôt que de continuer à réinventer la roue en permanence.
Deux ans plus tard, Lennart Poettering annonce que les nouvelles versions de udev seront incompatibles avec les anciennes et devront nécessairement reposer sur un noyau récent (utilisation de kdbus). C'est le dernier avertissement pour Gentoo
Le projet systemd fournit environ 80 binaires. Parmi ces binaires, quelques exemples :
- /sbin/init (systemd) ne s'occupe que de l'init ;
- journalctl ne s'occupe que de consulter le journal ;
- udev s'occupe de découvrir les périphériques et peupler /dev ;
- hostnamectl s'occupe de la gestion du nom d'hôte (hostname) de la machine ;
- machinectl s'occupe de la gestion des conteneurs lancés par systemd ;
- coredumpctl s'occupe des vidanges système (core dump) ;
- systemd-analyze s'occupe d'inspecter la vitesse du démarrage ;
- systemctl permet de gérer les services.
D'un point de vue sécurité, systemd limite aussi les droits et capacités des services qu'il lance (il permet par exemple à Xorg — et Weston — d'être lancé sans qu'il soit root) appliquant ainsi la séparation des privilèges.
Couplage fort vs couplage faible
Tout d'abord il faut bien comprendre ce qu'est le couplage. Lorsque deux outils informatiques doivent interagir l'un avec l'autre et s'échanger des informations, on dit qu'ils sont couplés et la force de ce couplage est évaluée en termes de modifications à faire dans un logiciel quand l'autre évolue.
Jusqu'ici, SysVinit était faiblement couplé avec le noyau Linux : SysV n'utilisait que le strict minimum des API de Linux pour démarrer.
Systemd change très fortement la donne à ce niveau là. Systemd profite de multiples API du noyau pour contrôler et gérer les services, notamment :
- les control groups ;
- inotify ;
- les capabilities ;
- les namespaces ;
- audit ;
- fanotify.
C'est là d'où vient tout son intérêt et sa fiabilité. Mais, au fur et à mesure de ses évolutions, systemd n'hésite pas à se détacher des anciennes versions du noyau, des anciennes versions de D-Bus et udev ou encore des outils systemd précédents. Exemple :
Soyons clair, on s'attend à ce que systemd et le noyau soient mis à jour simultanément. On ne prend pas du tout en charge le mélange d'un noyau vraiment vieux avec un systemd vraiment récent. Jusqu'ici, on s'est concentré sur la prise en charge par systemd du noyau, jusqu'à une version antérieure de 2 ans (ce qui veut dire la 3.4 actuellement), mais même cela devrait être considéré avec précaution.
L'avantage de cette méthode est qu'elle permet d'avoir un ensemble limité de situations à prendre en compte et, de fait, limite les problèmes de rétrocompatibilité au minimum. L'inconvénient est que la masse de tests à faire pour monter en version est nettement accrue. En effet une mise à jour de systemd signifie nécessairement une mise à jour de udev et peut signifier une mise à jour de D-Bus, du noyau, des stratégies cgroups/SELinux, voire d'une partie de la hiérarchie de fichiers.
Dans un environnement où l'administrateur n'a pas forcément la maîtrise intégrale de ses systèmes (par exemple, pilotes propriétaires pour une baie de disque, programmes propriétaires ou non maintenus, mais nécessaires au fonctionnement de l'entreprise, hébergement de services ou de machines virtuelles pour des clients) - les tests peuvent être très complexes, voire impossibles à faire. La capacité à faire les mises à jour sereinement est mise à mal. Cependant, la capacité à ne pas mettre à jour l'ensemble du système et à bricoler avec une vieille version du noyau (par exemple) est, elle, complètement oblitérée. Plus on prend de retard sur des mises à jour systemd, plus la quantité de tests à faire pour s'assurer d'une non régression augmente et plus il va être dur de faire corriger les soucis rencontrés en upstream.
Les mises à jour sont donc complexes à faire, mais la non mise à jour n'est pas une option envisageable, même à court terme (systemd évolue à grande vitesse et des changements majeurs non rétrocompatibles se produisent tous les six mois environ — dernier en date udev nécessite désormais kdbus).
On peut donc comprendre une certaine réticence vis-à-vis de ce couplage fort par tout administrateur qui a soit de nombreux services au sein de son service informatique (i.e. beaucoup de tests), soit des applications fermées (i.e. d'un jour à l'autre, il va falloir lancer en urgence une migration parce que l'application X ne fonctionnera plus).
Journaux au format binaire
Il est reproché à systemd d'avoir des journaux systèmes (ou logs) au format binaire, alors que Syslog les stocke au format texte. Cela permet notamment :
- de disposer de fonctions de recherche puissantes via
journalctl(filtrage par date, application, etc., un peu comme une base de données) ; - d’intégrer des données binaires — telles que la vidange (dump) d’un résultant d’un plantage — directement dans le journal ;
- de ne pas laisser n’importe qui ayant un accès root le pouvoir de modifier le journal (tel qu’un intrus voulant effacer ses traces).
Cependant, pour pouvoir traiter les journaux avec les outils qu’on utilise habituellement pour manipuler du texte, il faut utiliser journald. Cela signifie qu’en cas de problème, le format binaire ne peut pas être lu par une plateforme ne disposant pas de systemd.
D’autre part, l’indexation automatique de journald ne concerne que des éléments internes et connus, la recherche d'un élément arbitraire (par exemple une poignée de main SIP) nécessite toujours une recherche complète ou l’utilisation d’un système d’indexation externe type plein texte.
Un fichier binaire est plus sensible à la corruption qu’un fichier texte ; par exemple, il suffit généralement d’écrire une suite aléatoire de caractères au début du journal pour rendre l’ensemble du fichier inexploitable. Une autre technique consiste à apposer un sceau (seal) au début.
Cependant, comme avec syslog, les journaux sont répartis en plusieurs fichiers et journald est capable de gérer certains types de corruptions. Cela étant dit, des journaux qui se corrompent facilement peuvent devenir une vraie difficulté pour les administrateurs système quand ils doivent diagnostiquer des problèmes.
D’autre part, le format binaire de journald lui permet d'être actif très rapidement, et de mettre en log le tout début de l’initialisation de l'espace utilisateur qui était jusqu'alors non supervisable. Un flux binaire a besoin de nettement moins de fonctions du noyaux actives. On n’a, par exemple, pas besoin des locales, des maps de caractères, de faire attention aux caractères de contrôle, etc.
Cependant, il est tout à fait possible de paramétrer journald pour envoyer tous les journaux à syslog, retrouvant ainsi le format texte avec des informations supplémentaires (en effet, journald est capable de récupérer des informations plus tôt pendant le démarrage).
L’embarqué
Les fonctionnalités et la maîtrise qu’offre systemd se paye en terme de ressources utilisées. Par exemple, un développeur Debian nous apprend que systemd nécessite 236 kio à 550 kio de bibliothèques additionnelles à charger en mémoire et que la taille résidente en mémoire est de 1,8 Mio, soit 1 Mio de plus que Sysvinit. Autant dire que même sur un Raspberry Pi, ça ne fait aucune différence à l’utilisation.
Si systemd est aussi conçu pour et utilisé sur des plateformes embarquées, systemd peut se révéler trop gourmand sur certaines configuration particulièrement limitées. D’ailleurs, systemd ne fonctionne qu’avec la glibc et ne peut pas être utilisé, par exemple, avec les bibliothèques standards C plus légères qu’on retrouve sur certains systèmes embarqués.
Réécriture d’outils
On dit souvent que systemd réinvente la roue (syndrome NIH).
En effet, systemd intègre des fonctionnalités fournis par d’autres logiciels (par exemple, inetd ou cron). Cela permet à systemd de rendre ces fonctionnalités plus faciles à utiliser par systemd et par l’utilisateur.
systemd propose aussi des outils ayant comme but d’être des alternatives plus simples (moins de code), légères (moins de fonctionnalités) et sécurisées (moins de privilèges nécessaires) par rapport aux outils qui existent déjà, lesquels sont relégués au traitement des cas les plus complexes.
Au final, beaucoup de personnes se sont inquiétées de voir systemd réécrire et maintenir des outils qui existaient déjà, doutant de l’utilité réelle de ce travail en comparaison de la charge de développement et de maintenance supplémentaire.
L’étendue du projet systemd
Un argument important porte sur la forme du projet beaucoup plus que le fond technique. En effet, ce qui au départ n’était qu’un projet de système d’initialisation englobe désormais tout un tas d’autres outils et est défini par ses mainteneurs comme une plateforme modulaire qui fait la glu entre les applications et le noyau Linux.
Cette plateforme est développée comme un écosystème à la BSD, c’est pourquoi les outils jugés nécessaires sont tous développés en interne et maintenus dans le même dépôt. Il est alors légitime de s’inquiéter qu’un seul projet maintienne autant d’outils importants si on n’a pas confiance (que ça soit techniquement ou que ça soit des relations qu’ils entretiennent avec les autres projets).
D’autre part, certains outils sont difficiles à utiliser sans systemd comme udev (cf. udev), ce qui pose des interrogations quant à la possibilité de réutiliser ces composants ailleurs (comme on pourrait l’attendre d’un outil Unix).
En effet, il est devenu compliqué d’utiliser udev seul pour les distributions n’utilisant pas systemd, au point qu'on lui associe souvent, par abus de langage, le slogan adopte, étend et étouffe.
L’équipe de développement de Gentoo a créé un fork d’udev nommé eudev qui fonctionne sans systemd. C’est évidemment du travail en plus pour Gentoo mais n’importe quelle distribution peut maintenant utiliser eudev pour se passer de systemd.
Influence de Red Hat dans le développement de systemd
On reproche de temps en temps à systemd d’être le produit de Red Hat pour couler GNU/Linux (c’est rarement dit de manière plus subtile). Mais plus précisément, on reproche à Red Hat de forcer l’adoption de leurs logiciels.
Il faut rappeler que 26 personnes ont droit de commit sur le projet et 40 personnes contribuent tous les mois. D’un autre côté, Red Hat emploie 3 des 4 plus gros contributeurs à systemd, à savoir Lennart Pottering, Kay Sievers (développeur de udev) et Tom Gundersen (qui est aussi développeur Arch Linux).
Pourtant, les équipes de maintenance des distributions ont surement longuement réfléchi avant de choisir d’inclure ou non systemd, car c’est loin d’être un changement trivial. Le fait que Red Hat engage des gens pour travailler dessus est un point positif, c’est sûr, mais c’est loin d’être le seul critère pour l’intégration ou non de systemd.
Dépendance de GNOME à systemd
Depuis la version 3.8, GNOME dépend de systemd pour certaines fonctions liées à la gestion de l’énergie et aux paramètres système.
En réalité, systemd fournit une fonctionnalité utile via une interface documentée que le projet GNOME a décidé d’utiliser pour se simplifier la vie, plutôt que ConsoleKit qui n'est plus maintenu depuis plusieurs années. Cela a permis à Ubuntu de réimplanter l’interface pour faire fonctionner GNOME et donc a permis à Ubuntu GNOME de naître.
Il est logique que systemd expose de nouvelles interfaces de programmation pour accéder au matériel, et il est compréhensible que GNOME veuille en tirer parti. Il est cependant dommage que le fait d’utiliser GNOME sans systemd demande du travail supplémentaire aux distributions utilisant un autre système d’init. Cela est toutefois cohérent avec la politique de GNOME de réduction du nombre de fonctionnalités.
Jusqu'à présent, les autres environnements de bureau ont été plus prudents et essaient d’éviter les dépendances les liant à un système d’exploitation en particulier ou demandant un travail d’intégration supplémentaire.
Par exemple, KDE et Xfce4 tirent parti des avancées de systemd mais fonctionnent sans. Cela demande plus de travail, mais on peut espérer dans le futur que des projets comme systembsd permettent de profiter de certaines fonctionnalités de systemd sans lui et de se débarrasser du vieux code.
Attitude des développeurs de systemd
Lennart Poettering
C’est l’auteur de systemd, qui mène toujours aujourd’hui en grande partie son développement. Il est employé par Red Hat pour travailler sur systemd.
Il a développé PulseAudio, le logiciel qui gère le son dans la majorité des distributions GNU/Linux. Pourtant, PulseAudio a une mauvaise réputation. Il est souvent désigné coupable par défaut des problèmes de son. L’histoire est en réalité bien plus complexe.
Certains affirment également que « systemd est un jouet qu’il abandonnera quand il en aura marre », rappelant qu’il a abandonné le développement d’Avahi. Ce dernier est également peu apprécié à cause de son fonctionnement parfois jugé intrusif.
Bref, si parler du comportement des développeurs de systemd est pertinent, il faut éviter de tomber dans le piège de l’Argumentum ad personam qui n’indique pas grand chose sur la qualité du logiciel.
Il y a un poste pour les adorateurs de L. Poettering : Startup and Shutdown System Expert
Conclusion
Voilà, à présent vous devriez mieux comprendre les débats enflammés concernant systemd.
systemd apporte plein de bonnes choses, mais a aussi ses points négatifs et il devient de plus en plus difficile de s’en passer. Après tout, utiliser des logiciels libres, c’est une question de choix… non ?
Cette dépêche ne prétend pas être parfaitement neutre, mais grâce à la participation de courants opposés dans une relative bonne ambiance où chacun à fait des concessions, elle essaie d’être au plus près des faits et d’apporter pour chaque argument un contre-argument.
Les titres de dépêche auxquels vous avez échappé
- Pourquoi systemd existe ?
- systemd a-t-il des problèmes d’init ?
- Pourquoi systemd, pourquoi la vie ?
- Pourquoi systemd est bon pour votre santé
- La réponse à la question sur l’univers, la vie et systemd
- all your init are belong to systemd
- Je suis systemd
- GNU/Systemdnux
- 3 utilisateurs sur 6 aiment dé
- systemd : Yes we Kaane !
- The fabulous fairy tale of systemd and the 50 bastards.
- Nous partîmes 500 et paf systemd.
- xcomcmdrd.
- systemd dans ta gueule, connard
- systemd, haters are gonna ♫ hate hate hate ♫
- l'antisystemdisme, un mal français
- systemd, une lumière dans la nuit
- systemd : let's drop Linux
- systemd ne t'a rien demandé
- systemd président, Zino 1er ministre, MultiDeskOS aux affaires étrangères
- (systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !) ah non vous n'y avez pas échappé
- systemdivise
- systemd : il ne passera pas par moi.
- systemd sera le genre humain.
- systemd : l'union sacrée
- Souriez, vous êtes systemd :)
- Kabaled
1 000 commits, 50+ participants, 25+ titres, 1 dialogue de sourds
Aller plus loin
- Site officiel du projet systemd (613 clics)
- Article Wikipédia sur systemd (675 clics)
- Journal « Pourquoi les zélateurs et détracteurs de systemd ne s’entendront jamais » (894 clics)
- Systemd: The Biggest Fallacies (229 clics)
# Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par coid . Évalué à 1.
.
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par yohann (site web personnel) . Évalué à 10.
parce que c'est le noyau qui va bientôt faire partie de systemd
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par Reihar . Évalué à 9.
Kerneld ?
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par FantastIX . Évalué à 3.
gnulinuxd
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par BAud (site web personnel) . Évalué à 7.
GNUhurd
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par FantastIX . Évalué à 0.
gnurd
J'aime pas le "uhu".
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par walker17x . Évalué à -8.
Entièrement d'accord , systemd et wayland devraient etre combiné au kernel , quand aux drivers eux devraient étre séparé ( un peu comme pour windows NT ) , cela donnera bien plus de stabilité et de performances
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par Johnvox . Évalué à 10.
Je pense que le but premier du noyau est de s'interfacer avec les périphériques physiques (RAM, etc.)
Le but du noyau est de rester léger avant tous, de plus nombre de projet d'OS (embarqué, utilisation précise) utilise le noyau linux mais pas forcement de processus d'init conventionnel (SysV, systemd). Intégrer le processus init apporterai en sois une unique solution d'initialisation alors que cela ne doit pas être le cas, initialisé des modules de réseaux de capteurs n'est pas comme l'initialisation d'une machine desktop/laptop
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par PolePosition . Évalué à 1.
A noter que la libc et GRUB, en plus du kernel, vont être intégrés à systemd.
La date prévue pour ces commits est le 1er avril.
On aura bientôt des distros genre "Arch/systemd221".
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par DerekSagan . Évalué à 8.
La vraie question c'est: va-t-on intégrer Gnome ou KDE à systemd ? Ensuite on pourra se demander aussi, mais c'est secondaire, si cette intégration doit se faire à l'aide d'emacs ou de vi.
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par Atem18 (site web personnel) . Évalué à 10.
Gnome, étant donné que Red Hat sponsorise le développement de Gnome et de systemd. Et l'intégration doit se faire à l'aide de vim, car emacs pouvant faire office d'init, il est donc un concurrent direct de systemd.
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par Misc (site web personnel) . Évalué à 3.
Ceci dit, il y a des travaux sur le fait d'avoir la pile tcp/ip en userspace, et avoir des interpréteurs directement lancé à la place du kernel (notamment sur des VM, voir le projet Mirage, erlang on xen, etc).
Donc la question de la séparation kernelspace/userspace est en effet remis en cause. Après tout, pendant longtemps, on a eu les drivers graphiques en dehors du kernel. ( et on a encore des drivers en dehors pour l'USB, par exemple, ou les imprimantes ).
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par xcomcmdr . Évalué à 2.
Ce serait sympa. C'est ce que fait Windows depuis Windows 7 (enfin ça a l'air d'être prévu depuis longtemps par WDDM, mais c'est avec Win7 que ça s'est concrétisé) et qui lui permet de redémarrer le pilote en cas de plantage sans que l'utilisateur ne perde sa session, et permet de mettre à jour le pilote graphique sans redémarrer.
Bon, j'ai eu quelques écran bleus quand même à cause de pilotes graphiques Intel, c'est pas parfait. ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par DerekSagan . Évalué à 3.
Peut-être parce qu'aucune de ses fonction ne nécessite de ne pas être dans l'espace utilisateur…
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par Kaane . Évalué à 4.
Parce que la fonction principale d'un init est d'assurer la mise en place et le maintien de l'espace utilisateur.
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par reno . Évalué à 0.
Mais une "partie de systemd" va être dans le noyau: KDBUS, pour améliorer les perfs et la sécurité.
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par xcomcmdr . Évalué à 2.
euh, kdbus ne fait pas partie de systemd, c'est juste d-bus dans le noyau, disponible pour tout le monde.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par reno . Évalué à 4.
Oui enfin sur la discussion sur lkml systemd est évoqué. La raison principal de l'effort d'intégration de d-bus dans le noyau est parce que systemd l'utilise..
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par Renault (site web personnel) . Évalué à 3.
Oui enfin ça n'a pas l'air de déplaire les développeurs emblématiques de Linux car ils y participent eux mêmes ! S'ils l'acceptent c'est bien qu'ils l'estiment nécessaire, Linus sait faire savoir quand il n'aime pas du tout une idée et qu'il refuse sa mise en œuvre.
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par reno . Évalué à 3.
Une question: pourquoi trouves-tu nécessaire d'ajouter ça?
Je n'ai en aucun cas critiqué l'intégration de KDBUS ou suggéré que ça dérangeait ou déplaisait à quelqu'un.
Il faut arrêter la parano: ce n'est pas parce que certains sont contre systemd que tout le monde l'est..
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par claudex . Évalué à 5.
Il y a des arguments invoqués par ceux qui pousse le développement de KDus, notamment le fait que ça permet des transfert de données 0-copy et donc de meilleurs performances.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par BAud (site web personnel) . Évalué à 10.
ce n'est pas parce que tu n'es pas parano qu'ils ne sont pas après toi :-)
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par Thomas Douillard . Évalué à 1.
je blo
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par Tangi Colin . Évalué à 7.
oui enfin y a pas que pour systemd que sa serait bénéfique. Les premiers a avoir poussé pour un bus de communication au niveau kernel c'est le projet Genivi (Projet de la linux fondation pour promouvoir linux dans les véhicules) qui ont pondu http://projects.genivi.org/afbus-dbus-optimization/home . KDBUS en est l'héritier. On peut mettre beaucoup de chose sur le dos de systemd mais faut pas tout mélanger non plus.
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par reno . Évalué à 5.
Ça tombe bien, il ne semble pas avoir suggéré ça.
Quand je lis ça: http://lwn.net/Articles/580194/ ça me laisse à penser que l'implication des devs de systemd a quand même bien aidé pour cette nouvelle tentative d'avoir d-bus dans le kernel.
# Upstart
Posté par cosmocat . Évalué à 6.
Il me semble que ChromeOS utilise Upstart et que Google est loin d'être prêt à passer à autre chose donc il risque d'être zombifié encore pendant encore un moment…
[^] # Re: Upstart
Posté par walker17x . Évalué à -6.
ChromeOS est basé sur Gentoo et utilise une version modifié de OpenRC
[^] # Re: Upstart
Posté par Atem18 (site web personnel) . Évalué à 5.
https://sites.google.com/a/chromium.org/dev/chromium-os/chromiumos-design-docs/software-architecture
En gros, ils utilisent le gestionnaire de paquet de Gentoo et Upstart.
# Moins de liberté, pour plus de sécurité
Posté par Brunus . Évalué à -10.
Moins de liberté, pour plus de sécurité…c'est ce qui me frappe en lisant cette excellent dépêche.
J'ai toujours cherché plus de liberté, à tous points de vue, dans mon utilisation de l'informatique.
Depuis 1998 j'utilise donc des systèmes libres, au sens de la licence bien sur.
Là je sens comme une sorte de malaise profond depuis quelques années avec l'arrivée de ce gros changement qu'est systemd.
"Qui est près à sacrifier sa liberté pour plus de sécurité ne mérite ni l'une ni l'autre." T.Jefferson.
J'aime Gnome, j'aime Debian, je n'aime pas systemd.
Je veux avoir le choix et je ne devrai pas avoir à fournir plus d'efforts que par le passé pour y accéder.
C'est un des principe de base de l'utilisation des logiciels libres et je le sens très affaiblit ce principe dans le contexte de l'adoption de systemd par autant de distributions.
Pour des devs de Gnome c'est "pratique" certes…ok…on s'arrête là ?
"On ne choisit pas un logiciels d'abord pour le confort qu'il apporte mais avant tout pour le niveau de liberté qu'il apporte." RMS.
Et je pense qu'il faut appliquer ce principe autant aux licences qu'aux interactions entre programmes.
Arrêtez ce train je veux descendre !
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Renault (site web personnel) . Évalué à 10.
Le LL, c'est une licence, un code source. Ça n'a rien à voir avec la liberté de bidouillage sans modifier le code source lui même.
Tu as des tas de LL de très bonne qualité qui ne permettent pas de bidouiller facilement mais leur qualité de LL est du au code source qui est accessible à tous ses utilisateurs et pour faire ce qu'ils en veulent.
Si le LL signifie pour toi que tu peux bidouiller n'importe comment ton système, tu t'es trompé d'endroit. Enfin, techniquement tu es toujours libre de faire ce que tu veux dans ton système mais il va falloir coder un petit peu et construire une distribution différente.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Astaoth . Évalué à 1.
On m'a toujours vendu les OS libre comment permettant de faire ce qu'on souhaite dessus, de les personnaliser comme on le souhaite, en bref comme la possibilité d'avoir le choix, contrairement aux OS propriétaires tel que Windows ou Mac OS, et ce ci sur des sites assez impliqués dans le libre et de certaines distributions. M'aurait-on menti toutes ces années ?
Emacs le fait depuis 30 ans.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Renault (site web personnel) . Évalué à 10.
C'est là où il y a le mélange des genres.
Le LL c'est du code source et la possibilité à chaque utilisateur de faire ce qu'il veut du programme et du code source (modulo quelques limitations suivant la licence).
Par conséquent, cette liberté permet (mais pas obligatoirement) la constitution de communautés d'utilisateurs et de développeurs où potentiellement tout le monde peut contribuer. C'est un système de partage, tu prends ce que les gens proposent, tu en fais presque ce que tu veux et tu peux donner en retour.
Donc non, dire que GNU/Linux tu peux en faire ce que tu veux resteras vrai : le code source est là, à toi d'en disposer, de les modifier de sorte à ce que cela te convienne. Si tes idées plaisent, tu pourras peut être avoir des utilisateurs et des contributeurs et tu auras crée une distribution.
Cela ne signifie pas que toutes les distributions doivent respecter la volonté de tous ses utilisateurs. Les distributions font constamment des choix de technologies à inclure pour satisfaire des besoins : stabilité, nouveauté, simplicité, personnalisation, usage serveur ou embarqué, etc. En général d'ailleurs, quand tu utilises une distribution tu fais confiance à ces contributeurs pour ces choix.
Debian, Fedora, Ubuntu et autres n'incluent pas tous les LL existants, font des choix sans issue de secours (présence de logiciels proprio, formats de paquets, système d'init ou serveur d'affichage, options de compilations, version à utiliser pour chaque paquet, etc.). Ici systemd a été globalement choisi par la plupart des grandes distributions. Ça peut potentiellement rendre la bidouille plus complexe. Mais ça ne retire rien au côté de personnalisation et de liberté du LL et des distributions concernées. Car comme avant, tu n'es pas privé de prendre le code source et de le modifier. Tu aimes tu prends, tu n'aimes pas, fais toi même. Les gens proposent quelque chose dont chacun peu en faire ce qu'il veut, on peut ne pas aimer le résultat, mais on ne peut exiger qu'ils répondent à nos besoins car on a aucun moyen de le demander. On remercie ou on ignore et on passe à autre chose quitte à répondre à son propre besoin par soi même.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par BAud (site web personnel) . Évalué à 5.
il reste tout de même slackware, gentoo et peut-être un jour devuan au moins proposant systemd au choix… cela reste dans l'esprit du logiciel libre de promouvoir la diversité, même si systemd ne remet pas en cause cette diversité par essence (étant du logiciel libre, chacun peut le porter et l'adapter pour son *BSD préféré aussi même si certaines fonctions bien identifiées ne concerneraient que le noyau Linux, dans un premier temps).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Christophe . Évalué à -1.
Mais c'est bien de ce 1% dont on parle là. Les 99% sont couverts depuis bien longtemps par systemd. Et j'ai l'impression que justement, ce qui embête, c'est que systemd court après ces 1%, et cette hiérarchisation de l'importance des fonctionnalités est peu visible, que ce soit dans systemd ou dans les distributions.
Séparer un peu plus clairement les choses, ou proposer un "systemd-light" permettrait aux utilisateurs d'avoir enfin un gestionnaire de démarrage à l'étendue un peu plus stable, sans sacrifier les atouts offerts par systemd.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par DerekSagan . Évalué à 8.
Et c'est quoi les trucs que tu retires pour avoir une version allégée ?
Parce qu'au bout du compte il n'y a pas tant de chose que ça dans systemd (ceci n'est pas un dénigrement de systemd mais au contraire un compliment: kiss).
Tu veux retirer les montages, sockets et autres ressources et ne gérer que les processus ?
Pourquoi pas, mais globalement le fait de pouvoir gérer à un seul endroit ce qui était avant disséminé entre les scripts d'init sysv, inetd[1], daemon-tools[2] et un gestionnaire de groupe de service[3] ça va clairement dans le sens de la simplification et de la cohérence, même si c'est un petit peu plus compliqué que ce que faisait le seul et pauvre init avant.
Maintenant la notion de service est cohérente et pratique.
Et si tu ne gères vraiment que des processus, t'es pas vraiment géné par les fonctionnalités que tu n'utilises pas, et t'as une interface plus cohérente qu'avant avec systemctl qui remplace d'un coup les scripts inits/service d'un côté et chkconfig/update-rc.d de l'autre.
[1] http://fr.wikipedia.org/wiki/Inetd
[2] http://cr.yp.to/daemontools.html
[3] lire LRM ici: http://www.linux-ha.org/wiki/Cluster_Glue
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Christophe . Évalué à 2.
Je parle du projet systemd, pas du binaire. En dehors de systemd et journald, bien peu de modules systemd sont absolument indispensables, et sont surtout des versions simplifiées d'outils déjà existants.
D'ailleurs, je trouve que tu as plutôt bien listé ce qui est indispensable dans systemd et qui fait sa force. Maintenant, quid du reste ?
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Anonyme . Évalué à 2.
Le reste, personne ne force les gens à l'utiliser. Ni les distributions à l'installer. Donc c'est quoi le problème ? Que ca soit disponible ?
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par DerekSagan . Évalué à 2.
Le reste ?
Quel reste ?
Il y a quoi d'autre de notable dans systemd ?
Parce que si ce que tu veux retirer pour avoir une version allégée ce sont des trucs complètement anodins (genre cgtop) à quoi bon ?
C'est comme négocier de ne pas acheter le papier peint quand tu achètes une maison…
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Christophe . Évalué à 3.
Si c'est modulaire mais que tout est essentiel, on n'a pas la même définition de "plateforme modulaire".
Ne peut-on pas mettre dans des paquets "addons" les "modules" correspondant à logind, networkd, autrechosed ? Personnellement je trouverais ça plus sain: c'est une façon d'évaluer les dépendances entre les différents éléments du projet.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par lolop (site web personnel) . Évalué à 4.
Modulaire, c'est juste une histoire de découpage qui permet a priori de remplacer un élément par un autre.
Le fait que certains modules soient ou non optionnels c'est autre chose.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Tonton Th (Mastodon) . Évalué à 1.
Bon, et pour ceux qui utilisent intensivement
xinetd, il est prévu quelque chose ? Par exemple pouvoir continuer à l'utiliser en parallèle ou à la place des fonctionnalités proposées par systemd ?[^] # Re: Moins de liberté, pour plus de sécurité
Posté par JJD . Évalué à 2.
Ben c'est juste une question de configuration : tu peux parfaitement ne pas activer (ou désactiver) l'écoute sur une socket particulière (port TCP/UDP ou socket Unix) par systemd et laisser ce travail à ton xinetd favori.
Ça va juste demander un effort d'adaptation et d'apprentissage des commandes permettant de gérer cette configuration.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par chaispaquichui . Évalué à 10.
Le premier Calimero est arrivé rapidement :)
C'est pitoyable de balancer des tirades sur la liberté alors que ce que tu veux réellement, c'est empêcher les autres d'utiliser un projet que tu n'aimes pas.
Tu n'aimes pas systemd ? Va argumenter avec les développeurs et les mainteneurs qui décident de l'utiliser (tu sais, les mecs qui créent des logiciels que tu aimes bien utiliser gratuitement). Au pire, contribue, fork ou change de distro.
C'est le monde du libre, t'es libre de ne pas aimer et de changer.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par arnaudus . Évalué à 10.
Bah, en plus, l'argument de base est débile. Un truc écrit en bash serait "plus libre" qu'un truc écrit en C? Le gars est en train de dire que Linux serait beaucoup plus libre avec un kernel écrit dans un langage de script. On va vachement loin avec des raisonnements comme ça…
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Tonton Th (Mastodon) . Évalué à 7.
Fabrice Bellard doit déja y songer.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Misc (site web personnel) . Évalué à 10.
Il est mal formulé, mais ce qu'il veut dire, c'est que pour lui, le bash est plus accessible que le C. Ensuite, autant je suis d'accord avec ça pour certaines personnes, autant je suis pas sur que ça soit généralisable d'une part, et si important d'autre part.
C'est pas généralisable car je pense que python serait plus accessible sur le principe que bash, et que du point de vue des nombres de devs, des choses comme javascript ou php serait sans doute plus important, ce qui veut pas dire que c'est une bonne idée. Sur la population ciblé des sysadmins, des choses comme perl ou ruby me semble aussi connu que bash (surtout ruby avec la montée de puppet/chef), et fournisse de meilleurs libs et un écosystème plus haut niveau. Mais quand tu connais que le bash, forcément, tu te dit que ç'est ce qu'il faut utiliser.
Et l'argument est aussi celui qui a été utilisé pour justifier que les softs de l'OLPC soient écrit en python et modifiable par les utilisateurs directement dans l'interface.
Et c'est pas si important d'autre parce que globalement, tout est écrit en autre chose que bash. Le libre n'a pas vraiment été bloqué par le fait que beaucoup de choses étaient en C avant, et j'aurais même tendance à dire que les sysadmins de l'époque des débuts d'unix savaient faire du C, vu le nombre de soft écrit en C à ce moment la par des admins ( typiquement, des trucs comme cron/atd, sendmail, et autres trucs historiques ).
Donc oui, y a des gens pour qui bash est naturel et ils voient ça comme une privation de la liberté de comprendre et d'étudier de la GPL. Mais c'est une privation lié à une limitation de leur savoir sur le moment plus qu'une limitation absolu, donc pour moi, l'argument ne suffit pas à justifier de ne pas changer.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Brunus . Évalué à 4.
C'est triste ton point de vue sur les Caliméros…
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Madcoy . Évalué à 10.
Tout est résumé dans cette phrase. Les gens veulent avoir le choix, mais ils veulent que d'autres fassent le boulot à leur place sinon c'est une perte de liberté pour eux. Vous avez toujours le choix de rester sur les vieilles technos ou de coder pour que les anciennes techno reste à jour. Mais ne demandez pas aux autres de faire le boulot pour vous.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Brunus . Évalué à 4.
Et ça ne te vient pas à l'esprit que je puisse déjà être impliqué dans assez de projets liés (de près ou de loin) au libre pour ne pas avoir assez de temps pour m'impliquer dans un fork de Debian ou Gnome ?
Si je me permet de commenter c'est parce que j'estime être en mesure de le faire au regard de ce que j'ai déjà fait pour le libre et en particulier pour les distributions Linux telles que RedHat, Mandrake/Mandriva, Ubuntu, Debian…
De plus je n'ai pas critiqué le travail réalisé sur systemd, il faut bien relire ce que j'ai posté.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Renault (site web personnel) . Évalué à 8.
Il n'empêche que tu mélanges beaucoup de concept lié à la liberté pour justifier ta position alors qu'elle ne tient pas vraiment.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Astaoth . Évalué à 2.
Si tu lis attentivement la phrase que tu cites, il ne demande pas à ce que les autres fassent le boulot à sa place, il désapprouve d'avoir encore plus de boulot à faire.
Emacs le fait depuis 30 ans.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par chaispaquichui . Évalué à 10. Dernière modification le 24 février 2015 à 23:25.
Et à quel moment systemd va lui donner plus de boulot qu'avant ? Wep, il va devoir lire quelques pages de man et effectuer quelques tests, rien de nouveau pour un mec qui utilise Linux au quotidien.
Faut arrêter d'exagérer avec ça… A croire que les gens passent leur vie à interagir en permanence avec le système d'init… Je suis admin système et avant, c'était une véritable agonie d'écrire un script de démarrage correct pour un processus sous Linux… C'était pas élégant, bourré de race condition, pas compatible entre les distribution… Depuis systemd, j'ai échangé la commande service par systemctl, je peux écrire des units très facilement, exprimer des dépendances de manière élégante et copier/coller mes unités sans crainte de voir le processus se vautrer lamentablement. Que du bénéfice en somme.
Alors oui, moi aussi parfois je soulève un sourcil quand je vois la dernière nouveauté intégrée dans systemd. Puis je me souviens que je ne suis pas seul au monde, que les gens ont des besoins différents et que systemd essaye d'y répondre…
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Moonz . Évalué à 10.
Exemple:
Lennart Poettering
Note aux altercomprenants qui sévissent dans le coin. Je ne dis pas (je précise : je ne sous-entend même pas) que les devs systemd sont obligés de faire ce qu’on dit parce qu’ils sont nos esclaves (oui, aussi bizarre que ça puisse paraître, il faut préciser ça si on veut pas se faire traiter d’esclavagiste). Tout ce que je dis, c’est que l’assertion « le mouvement dans l’écosystème Linux initié par systemd impose plus de boulot aux développeurs de solutions alternatives » est un fait admis par Lennart lui-même, ce n’est pas une lubie des anti-systemd. D’ailleurs, ceux qui ont un peu de mémoire se souviendront que ça a même été un argument utilisé par Lennart lors du débat systemd/upstart chez Debian : avec tous les changements à venir (chamboulement des cgroups, intégration kdbus/wayland, changements udev…), upstart va avoir beaucoup de difficultés à tenir le rythme :
Autrement dit : dans le futur, les alternatives à systemd seront forcées de suivre le rythme d’évolution imposé par systemd, et ce sera quelque chose loin d’être trivial.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Renault (site web personnel) . Évalué à 3.
Oui et ? C'est une sorte de sélection naturelle, si ça hérisse trop le poil de certains il faut un contre-mouvement plus fort.
Des cas comme ça, il y en a des tas tous les jours sans que cela fasse grand cas. Linux a détrôné BSD il y a bien longtemps comme OS UNIX-like libre. Son développement suit un rythme effrénée qu'ils ont du mal à suivre. C'est comme ça.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par xcomcmdr . Évalué à 9.
Et les alternatives à Xorg, Wayland, et Linux elles sont où ?
Bizarrement, ça gêne autant QUE pour systemd…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par anaseto . Évalué à 10.
Perso, j'ai pas cette impression. Ou plutôt, je vois pas qu'est-ce qu'ils auraient à suivre, ça marche déjà bien comme ça, et de mieux en mieux. Bref, je vois pas trop pourquoi parler de sélection naturelle, comme si les BSD étaient en voie d'extinction alors qu'ils sont bien vivants (pas moins qu'avant, j'ai l'impression).
Je précise que si je suis sous OpenBSD ce n'est pas à cause du système d'init, dont je me fous pas mal, du moment que ça démarre, que par défaut ça marche et que pour activer les deux-trois démons que je veux ça reste simple (une petite commande ou une ligne dans un rc.conf.local ça me va). En fait, la raison principale pour laquelle je suis passé dessus c'est que c'est plus simple pour mes besoins (tout ce dont j'ai besoin ou presque vient de base après une installation de moins de dix minutes) et que quand on ouvre une page man on est sûr d'avoir la vraie documentation, qui plus est bien écrite et concise.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Renault (site web personnel) . Évalué à 8.
Typiquement pour les pilotes ils ont beaucoup de retard, notamment pour ce qui touche aux cartes graphiques liés à la complexité propre de ces pilotes mais aussi aux abstractions qui ne sont pas identiques au sein de ces noyaux vis à vis de Linux.
C'est un exemple parmi tant d'autres qui peuvent causer de gros désagréments vis à vis des utilisateurs.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par anaseto . Évalué à 10.
Ce que tu veux dire, c'est qu'avec OpenBSD il faut faire un peu plus attention en achetant du matériel qu'avec Linux aujourd'hui. Eh bien, oui, c'est le cas. Mais c'était aussi le cas avant sous Linux, et il n'était pas mort pour autant, il attirait quand même du monde, c'est juste que le public s'est élargi depuis que ça s'est industrialisé et que le support matériel arrive plus tôt (ou arrive tout court), comme sous windows, et c'est probablement une bonne chose pour le libre, mais ça n'invalide pas d'un coup d'autres formes d'existence non plus.
Par rapport à ta remarque concernant les pilotes graphiques, curieusement, je n'ai eu aucun problème avec les cartes graphiques, justement : à peu près tout semble marcher (3D et tout) du moment qu'on évite nvidia.
Bref, que chaque système a ses plus et ses moins, qui conviennent plus à tel ou tel utilisateur, c'est une réalité, mais je vois vraiment pas l'intérêt de vouloir dire à ceux qui utilisent un système différent du sien qu'ils sont « détrônés », alors qu'ils n'ont sans doute jamais eu la moindre envie de monter sur aucun trône.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Brunus . Évalué à -7. Dernière modification le 25 février 2015 à 14:28.
Mais bien sur !
Et tu as lu un peu les documents liés à la dépêche ?
Dans un de ces documents tu verras clairement établi que les "anti-systemd" auront bien du mal à se faire entendre tellement la balance penche du coté de chez Redhat qui maîtrise le développement de ce dernier ainsi que de Gnome (entre autres…).
Les employés de Red Hat à eux seuls dominent le gros du noyau Linux, le système de base GNU, GNOME, NetworkManager, beaucoup de projets affiliés aux standards Freedesktop.org (Polkit, notamment) et plus encore. Il n'y a aucun moyen de concurrencer un vaste groupe d'individus rémunérés comme celui-ci.
Extrait de : https://linuxfr.org/users/mrspackman/journaux/pourquoi-les-zelateurs-et-detracteurs-de-systemd-ne-s-entendront-jamais
Il n'y a rien qui gigote dans ta tête après avoir lu ça ?
systemd est un choix stratégique pour, à priori, amener les systèmes Linux vers une adoption plus importante dans le contexte du desktop.
Depuis quand les utilisateurs et développeurs de systèmes libres doivent il subir les choix stratégiques des commerciaux ?
Que cela soit une option possible je trouve cela très intéressant, surtout d'un point de vue technique, rien à redire là dessus.
Là ce que je vois c'est qu'en fonction de mes choix de système base, je vais devoir, ou pas, dire adieu à Gnome à moins d'y investir des heures de temps que je n'ai pas.
Et donc, on m'a imposé une perte de liberté.
Et si ça se produit pour Gnome il y a de forte chance pour que ça se produise pour d'autres choses.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par xcomcmdr . Évalué à 7. Dernière modification le 25 février 2015 à 14:38.
systemd n'a rien à voir spécifiquement avec le desktop. systemd est généraliste.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Le Pnume . Évalué à 7.
Là j'ai besoin d'explication. Quelle liberté as tu perdu ?
Si la version n+1 du logiciel Tartempion ne me convient pas, je peux toujours utiliser la version n ou utiliser Tortompion à la place qui lui me convient. Ou comme Tartempion est sous GPL, je peux le modifier, payer qq un pour le modifier ou essayer de fédérer une communauté de personnes tout autant mécontentes que moi des évolutions que les développeurs ont intégrées (ils sont d’ailleurs absolument libres de le faire, il ne te doivent rien) et le forker.
Explique moi en quoi des développeurs devraient prendre en compte tes choix de base ?
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Astaoth . Évalué à -5.
C'est vrai en théorie, mais assez dur en pratique à cause du partage des bibliothèques. GNU/Linux n'est pas fait pour ce genre de chose. J'ai pu l'expérimenter à l'époque où j'utilisais le driver proprio de ATI : via le jeu des dépendances (et donc des bibliothèques partagées), je ne pouvais plus rien installer ni mettre à jour.
Emacs le fait depuis 30 ans.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par freem . Évalué à 7.
C'est moi ou tu compares un logiciel propriétaire, que tu ne peux compiler, à des logiciels libres, que tu peux compiler contre la version de la lib que tu veux?
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Misc (site web personnel) . Évalué à 4. Dernière modification le 28 février 2015 à 11:09.
La liberté de bénéficier gratos du travail d'intégration des gens qui font le boulot bien sur. En fait, il a toujours la liberté, c'est juste que l'intégration lui plait pas, donc il doit la refaire. Et c'est plus gratos, faut investir de son temps.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par gouttegd . Évalué à 10.
Pas besoin de systemd pour ça.
Dès l’instant où ce n’est pas toi qui fait le boulot, tes choix sont dictés par ceux qui le font (le boulot). Il n’y a rien d’anormal à ça, et il te « suffit » de faire le boulot toi-même pour retrouver toute ta liberté.
Par exemple, selon tes termes, je suis moi-même « privé » de la liberté d’utiliser GNOME.1 J’ai fait le choix d’utiliser Slackware, et le mainteneur de Slackware a, lui, fait le choix de ne pas continuer à intégrer cet environnement dans sa distribution (gérer KDE et GNOME simultanément, c’est trop de travail pour un seul homme).
Face à ce genre de situation, il y a ceux qui se plaignent qu’on leur vole leur liberté, et ceux qui retroussent leurs manches.
Bon, c’est pas comme si j’avais envie d’utiliser GNOME de toute façon. :P ↩
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Zenitram (site web personnel) . Évalué à 9.
Et les conneries repartent…
Comme si RH avait le moindre pouvoir sur Canonical, Debian, et surtout son concurrent SUSE.
C'est du FUD de personnes frustrées par la liberté des autres, et seulement ça.
Rien à voir avec une quelconque dictature de RH.
Que tu sorte ça en dit long sur comment tu considères la liberté.
systemd n'a pas plus à voir avec le desktop qu'avec les serveurs.
Mais tu veux que les autres aient ce temps pour toi.
Je veux la liberté de t'avoir comme esclave. tu refuses? Mais tu m'imposes une perte de liberté, tu es méchant!
S'il te plait, accepte ce que tu demandes aux autres, soit mon esclave afin que je ne perde pas de liberté.
Conneries : on ne t'impose rien, tu veux imposer.
Mais voila, c'est reparti, les conneries de personnes qui refusent que le monde n'aille pas dans leur sens, et travestissent alors les mots pour se faire passer comme victime (qu'ils ne sont absolument pas).
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Moonz . Évalué à 6.
Bien sûr que oui il en a, non pas en tant que concurrent, mais en tant q’upstream (RH est un très gros contributeur aux projets upstreams, que ce soit du côté du kernel, de Gnome, ou de systemd).
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par HSimpson . Évalué à 3.
La solution est simple, pour le bien de linux, il faut que RedHat arrête de contribuer upstream!
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par xcomcmdr . Évalué à 3.
Pour le bien de Linux, il faut que RedHat écoute linuxfr (ou pas).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par ookaze . Évalué à 1.
C'est faux, va lire l'interview de Lennart de Linux Voice (http://www.linuxvoice.com/interview-lennart-poettering/), la deuxième question retrace l'historique, et systemd est entièrement un choix technique. Si tu peux suivre l'historique de systemd sur le blog de Lennart P., tu verras que depuis le départ les arguments techniques, ainsi que toutes les évolutions. Je suis le projet depuis le début puisque je cherchais à remplacer mon simpleinit-msb qui devenais impossible à maintenir, et j'avais galéré avec dbus + upstart sur mon OS.
On ne t'a enlevé aucune liberté ! Quelle est donc cette liberté que tu as soi-disant perdue ?
Et qui est ce "on" ? Ça ne peut être que ta distribution.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Misc (site web personnel) . Évalué à 7.
Le terme que tu cherches est peut être "intégration" plus que "adoption".
Ensuite, ouais, Gnome ne sa cache pas de vouloir s'intégrer dans la plateforme, et de s'appuyer sur les APIs existantes pour se focaliser sur les couches les plus hautes. La coopération entre projets libres, c'est aussi ça et Si KDE et GNOME délègue la gestion du suspend à un composant externe, ça fait toujours ça de moins comme code à dupliquer et à corriger 2 fois.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Joff54 . Évalué à 3.
Tu veux descendre ? Bah descend et prend un autre train au lieu de te plaindre. Sur un *BSD par exemple, c'est libre aussi.
Utilise OpenBSD, tu pourras gérer ton démarrage en sh via le rc.local.
Chaque chaussure son pied.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Brunus . Évalué à 2.
Pourquoi critiquer les gens qui se plaignent de devoir changer de système base après des années de fidélité et de travail de promotion de ce système ?
C'est interdit de se plaindre des choix des commerciaux des vendeurs de distribs ?
Bien sur que je vais chercher une alternative, j'ai commencé il y a un certain temps, mais ce n'était pas le propos de mon commentaire.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par xcomcmdr . Évalué à 4.
Parce que tu ne changes pas de système d'exploitation. Tu changes d'init pour quelque chose qui est beaucoup plus complet, c'est tout. D'ailleurs pour la plupart, ce changement est transparent (ça l'a été pour moi sous Archlinux).
Non, mais c'est pas non plus interdit de réagir à ces plaintes.
D'abord, parce que c'est risible : ça existe un vendeur de distrib' ? J'en doute.
Et puis, ce sont les mainteneurs de distros qui ont voulu ce choix pour se simplifier la vie. Tu sais, ceux dont tu utilises sûrement la distribution gratuitement et sans rien leur devoir en retour.
Et ton OS a changé bien avant ça et on en faisait pas tellement tout un fromage, ou en tout cas pas à ce point :
- Ubuntu qui passe à Upstart à ses débuts
- ALSA -> PulseAudio
- XFree86 -> Xorg
- GRUB -> GRUB2
- Gnome 2 -> Gnome 3 (oui bon là y'a eu presque autant de guerres que pour systemd)
- Gnome 2 -> Unity (idem)
- KDE 3 -> KDE 4
- devd -> udev
- dbus -> kdbus
- etc. …
Et pourtant passer de KDE 3 à KDE 4 ou de Gnome 2 à Gnome 3, ça touche bien plus l'utilisateur moyen que systemd.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Astaoth . Évalué à 5.
Ca ne l'a pas été pour moi sous ArchLinux. Passage en shell de secours obligatoire, avec recherche de la doc pour régler le problème sur un écran 4" (bawi, j'ai pas 50 ordis chez moi qui ont un écran). Pourtant, sans avoir fait de modif précise du système.
C'est pas ce que fait Suse avec sa version payante ?
Sinon je suis d'accord avec toi, à quelques détails près. Parmi les logiciels que tu as cités, pour une partie d'entre eux il est toujours possible de s'en passer : par exemple un système marche très bien sans modification sans PulseAudio ou avec Grub Legacy.
Emacs le fait depuis 30 ans.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Zenitram (site web personnel) . Évalué à 0. Dernière modification le 25 février 2015 à 15:48.
Ce que tu critiques, c'est ce que tu aimes : un système vivant, la liberté des gens.
Donc bon, c'est surtout incohérent (surtout, tu n'es pas obligé de changer, merci le libre tu peux garder pendant 1000 ta version actuelle si tu veux, faut juste faire le taf que les autres ne veulent pas mais c'est normal de ne pas prendre les autres pou ses esclaves).
Les commentaires non anti-liberté des autres avaient pourtant été absents pendant quelques heures…
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Misc (site web personnel) . Évalué à 3.
Tu as le droit de te plaindre, mais ça veut pas dire que les gens vont pas te répondre. Le droit de râler s'applique aussi à tes propos, et si tu estimes ça chiant, fait preuve d'un peu d'empathie et dit toi qu'il y a des devs qui se prennent ça pour le moindre changement qu'ils font.
Et si tu te dit que ça n'apporte rien au débat, pose toi la question de savoir ce que redire ce qui a été dit 100 fois apporte aussi.
# Merci
Posté par Serge Julien . Évalué à 10.
Merci pour cette dépêche très intéressante, claire et complète, et bravo pour avoir gardé un ton neutre. Personnellement, je suis utilisateur de base et le système d'init est donc un composant de l'OS dont je peux me permettre de ne presque rien savoir. Mais j'ai lu tout ceci avec grand intérêt, encore merci.
[^] # Re: Merci
Posté par Daweed . Évalué à 5.
Merci également.
Même situation pour moi. Je suis un utilisateur (plus ou moins avancé) et j'avais jamais pris le temps de comprendre toutes ces réactions sur systemd.
Je suis sur Fedora depuis ses débuts et j'ai donc migré sans plus de questions il y a un moment. Mais je comprends mieux le dilemme pour les admins systèmes notamment.
Un petit constat pour ma part: au début j'avais lu qu'un des avantages c'était notamment la rapidité de boot avec la parallélisation de lancement des services. Mais franchement, depuis les dernières versions de FC, je trouve que la rapidité de lancement en a pris un bon coup.
Encore Bravo pour cet article.
[^] # Re: Merci
Posté par freem . Évalué à 4.
Ça n'était pas, au moins il y à 1-2 ans, un des objectifs, mais une conséquence de la parallélisation des lancements de process, ainsi que de la notion de démarrage de service à la demande.
Je ne sais pas pourquoi tant de gens utilisent cet argument fallacieux…
Je cite: http://0pointer.de/blog/projects/the-biggest-myths.html. Et l'explication: «Yes, systemd is fast (A pretty complete userspace boot-up in ~900ms, anyone?), but that's primarily just a side-effect of doing things right. »
Il me semble que c'était un peu plus clair avant, à l'époque ou je m'intéressais à systemd et ou je considérais que c'était un remplaçant possible pour l'init de mon système.
Maintenant, sur un système qui ne lance pas de services lourds (et certains DEs le sont, lourds), systemd n'apporte strictement rien en terme de vitesse, ou quelque chose de suffisamment négligeable pour qu'un utilisateur ne puisse pas le voir.
Dans ton cas de système qui ralentit, c'est peut-être parce que tu as ajouté des choses au démarrage, qui ont, par exemple, un fort accès disque: quand le système attends après les disques, il attend, que le processeur parallélise les tâches ne changera rien. Quand une machine est lente, toujours regarder d'où vient le goulet. Sur un PC, en général, c'est le disque dur. Ou la connexion internet quand on fait du téléchargement.
[^] # Re: Merci
Posté par Pierre Jarillon (site web personnel) . Évalué à 3.
Je viens d'installer Mageia 5 sur un Intel I7 à 4 double cœurs. Comme j'ai installe l'applet Systemloadviewer, je peux voir que les 8 cœurs sont sollicités en même temps. La parallélisation est donc effective.
[^] # Re: Merci
Posté par oinkoink_daotter . Évalué à 4.
<minute pédante>
Attention à la terminologie, in "I7 à 4 double cœur", ça ne fait pas 8 cœurs, mais 4 coeurs hyperthread-és (et c'est pô pareil).
</minute pédante>
[^] # Re: Merci
Posté par i M@N (site web personnel) . Évalué à 2.
merci aussi … la note de cette dépêche va certainement s'envoler pour rejoindre celles du noyau.
Pour le titre dommage qu'on ait échappé à "Je suis systemd"!
wind0w$ suxX, GNU/Linux roxX!
[^] # Re: Merci
Posté par jseb . Évalué à 3.
Avec un titre pareil, le premier commentaire eut probablement été: «PAN!»
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
[^] # Re: Merci
Posté par Foutaises . Évalué à 2.
Effectivement, je me suis amusé à faire tourner un jeu (World of warcraft) sur différentes combinaisons de cœur ou cœur-ht sur mon Core2Quad (2 cœurs + 2 cœurs-ht), avec de 1 à 4 cœurs activés, et lorsque le jeu tourne sur des cœurs-ht uniquement, il sort à la louche 50% d'images par seconde en moins que lorsqu'ils tourne sur des cœurs.
[^] # Re: Merci
Posté par freem . Évalué à 2.
Et?
Je n'ai jamais dis que la parallélisation n'était pas effective. J'ai dit que ce qui ralentit le plus le boot, je doute que ce soit le temps de calcul CPU nécessaire à charger pléthore de programmes, mais le temps d'accès nécessaire pour récupérer les données sur le disque.
D'ailleurs, combien de retours j'ai lus ou entendus disant qu'ils ont passé leurs boot de presque 1 minute à quelques secondes en changeant le disque mécanique par un SSD? Je ne pourrais pas les compter… (parce qu'il y en à trop)
Sinon, je suis curieux, ton applet, c'est pas un truc qui se plug sur une barre quelconque du bureau, c'est à dire après que le système soit initialisé? Dans ce cas, c'est pas un peu sans rapport avec l'init?
[^] # Re: Merci
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
Euh, oui, justement, et c'est pour ça que c'est intéressant de paralléliser. Il n'y pas que le CPU qui en bénéficie, ça permet justement d'utiliser les temps de latences de certains composants pour faire autre chose. Typiquement, lancer les services qui n'ont pas besoin du réseau pendant qu'on attend une adresse IP via DHCP.
[^] # Re: Merci
Posté par gnx . Évalué à 2.
Mais non, ça c'est l'histoire réécrite par Poettering. Si tu remontes 3 ans plus tôt, quand il annonce systemd et ses objectifs, il place bien la vitesse seule en tête de ces objectifs. C'est pas compliqué, ça se trouve sur le même blog. Ensuite, comme un argument de l'opposition était que l'important pour un init était d'être propre et sûr, que l'on se fichait de la vitesse et que la course à la vitesse était potentiellement néfaste, hop ! le Poettering a éhontément modifié sa façon de présenter les choses.
[^] # Re: Merci
Posté par claudex . Évalué à 6.
J'avais aussi ce souvenir mais en lisant http://0pointer.de/blog/projects/systemd.html en diagonal, je ne vois pas où il dit que la vitesse de boot est un objectif. Il dit bien par contre que le démarrage est plus rapide avec le mode de fonctionnement de systemd.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Merci
Posté par freem . Évalué à 3.
C'est où? Je me sens déjà fatigué d'aller chercher un truc potentiellement inexistant sur le blog d'un type qui ne m'intéresse pas des masses, et qui parle d'une techno qui ne m'intéresse absolument plus.
[^] # Re: Merci
Posté par David Marec . Évalué à 6.
"Rethinking PID1", dès le premier paragraphe…
```
[^] # Re: Merci
Posté par ookaze . Évalué à -4.
Il est pourtant bien écrit là qu'un init qui monte rapidement un système est un bon init, et pas que c'est un objectif de systemd.
Il est ensuite indiqué ce qu'il faut selon l'auteur pour obtenir un bon init (en 2010+).
Il est précisé ensuite la pensée de l'auteur par ce qu'il entend par "fast", et c'est répété partout : tout est lancé en parallèle en fonction des événements, et surtout pas de manière sérialisée.
On ne parle pas de booter en quelques secondes de moins là, on parle de maximiser le CPU et les IO disponibles, comme précisé ensuite, et pas seulement au boot, mais pendant toute la durée où l'espace utilisateur et monté.
L'auteur parle également de la gestion de l'aspect dynamique du noyau, qui doit être géré par l'init. Il y a beaucoup de choses dans ce blog en fait.
Ceci afin de ne pas se retrouver avec des boucles d'attente sur des montages de disques ou carrément des boots crashés comme j'ai vu si souvent avec sysvinit.
Les arguments dans ce post décrivent la réflexion qui a conduit à systemd, pas les objectifs de systemd. Et la rapidité intrinsèque aux choix effectués montrent selon l'auteur que c'est un bon init s'il suit sa définition d'un bon init.
Il me semble qu'il y a un autre blog de l'auteur qui explique les objectifs de systemd (l'ensemble de logiciels, pas juste l'init).
[^] # Re: Merci
Posté par David Marec . Évalué à 2.
Splendide démonstration de mauvaise foi.
[^] # Re: Merci
Posté par freem . Évalué à 3.
Merci.
Voici le lien du coup.
# On n'est pas vendredi !!!
Posté par netchaiev . Évalué à 10.
Je m'insurge !! Maintenant systemd amène les trolls le Mardi
Il faut forker Linuxfr !!! -> Linuanfr.org
Qd même on aurait du sortir cette dépêche vendredi 13 , cela aurait coller à la perfection …
```
# Z spotted
Posté par CHP . Évalué à 5.
Gni ? Y'a VRAIMENT plus d'une personne qui a pu prétendre ça, de facon sérieuse, que Red Hat voudrait couler Linux ? Dans le but de se couler son propre business (qui est, rappelons le, de vendre du support et des formations sur Linux ?) ou juste dans le but de passer pour des cons ?
Perso j'y crois pas. Ca ressemble plutot aux mauvaises habitudes d'un de nos habitués.
J'ai ri. Merci !
[^] # Re: Z spotted
Posté par xcomcmdr . Évalué à 2.
Suffit de fouiller un peu sur le Web. Exemple :
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Z spotted
Posté par CHP . Évalué à 10.
Je comprends peut-être mal, mais ce que je comprends ici c'est "Red Hat veut tuer les autres distributions Linux". C'est totalement différent de "Red Hat veut tuer Linux". Qu'une entreprise veuille piquer des parts de marché à ses concurrents, ca me parait beaucoup plus probable qu'une entreprise qui veuille tuer son propre business.
[^] # Re: Z spotted
Posté par Renault (site web personnel) . Évalué à 4.
Cela n'empêche pas que ça arrive, parfois. Par exemple Kodak, roi de la photographie chimique a crée la photographie numérique et ils n'existent plus dans le milieu. :)
[^] # Re: Z spotted
Posté par CHP . Évalué à 3.
"Une entreprise s'est tuée elle-meme par erreur" != "Une entreprise cherche à tuer son propre marché"
[^] # Re: Z spotted
Posté par Renault (site web personnel) . Évalué à 4.
Je ne dis pas le contraire, mais les gens semblent supposer que systemd va tuer Red-Hat sans qu'ils en aient conscience.
[^] # Re: Z spotted
Posté par xcomcmdr . Évalué à 3.
Bon, faut vraiment ressortir tous les posts débiles qui diabolisent Red Hat, Lennart, et systemd depuis que systemd est sorti ?
Voilà : le message est clair : si on arrête pas systemd, Linux va disparaître et Red Hat avec. Il faut stopper Red Hat dans son action suicidaire, etc…
Ou encore :
tuer linux = tuer redhat. Et vu que systemd vient de RedHat…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Z spotted
Posté par CHP . Évalué à 4. Dernière modification le 24 février 2015 à 13:34.
et
"Une entreprise est en train de faire une connerie, ce qui menera peut-être selon moi à la destruction de son propre marché" != "une entreprise cherche à tuer son marché"
Toujours pas convaincu.
EDIT :
Je crois qu'il va falloir, oui, si tu veux trouver plus convaincaint.
[^] # Re: Z spotted
Posté par Moonz . Évalué à 5.
Où arrives-tu à lire ça ?
Le mec il dit :
Et non pas seulement (qui pour le coup irait dans le sens de ton interprétation) :
Le type ne dit pas que Linux va disparaître, le mec dit que Linux va être approprié par RedHat.
[^] # Re: Z spotted
Posté par Misc (site web personnel) . Évalué à 2.
ce qui prouve qu'il y a quand même toute une éducation à refaire.
Parce que d'une part, ça fait des années que Red hat contribue sur des tonnes de projets ( http://community.redhat.com/software/ ), ça fait des années que Red hat est dans le top des contributeurs kernels, et du système de base ( gcc, glibc, coreutils, etc ).
Donc si tout d'un coup, la personne s'en rends compte, c'est soit qu'il avait pas la moindre idée de comment c'était fait avant et donc, un manque d'éducation sur la chaine de production, un peu comme le fait qu'on ne sait pas d’où vient la bouffe ou nos chaussures. Ou le fait d'attribuer incorrectement l'origine uniquement au distributeur, auquel cas on peut se poser la question de l'impact de certaines distribs qui se positionnent comme "linux = nous" (je parle d'Ubuntu, pour être clair.. )
[^] # Re: Z spotted
Posté par Astaoth . Évalué à 1.
Et avec d'autres sophismes dans le genre, Socrate est un chien parce qu'il a quatre pattes.
Emacs le fait depuis 30 ans.
# spelld
Posté par ɹǝıʌıʃO . Évalué à 8.
définit → défini
tirent partie des avancés → avancées
[^] # Re: spelld
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci
[^] # Re: spelld
Posté par El Titi . Évalué à 3.
chaque outil de systemd fait une chose et la fait bien et tous ces outils sont développé
es ensemble afin de fournir une « boîte à outils » cohérente…
et il est compréhensible que GNOME veuille en tirer parti*
e*.…
Par exemple, KDE et Xfce4 tirent parti*
e* des avancées de systemd mais fonctionnent sans.[^] # Re: spelld
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
[^] # Re: spelld
Posté par flan (site web personnel) . Évalué à 2.
Il y a également un « À contrario », qui s'écrit « A contrario ».
[^] # Re: spelld
Posté par El Titi . Évalué à 2. Dernière modification le 24 février 2015 à 23:44.
Un autre défaut de l'approche systemd est que de nombreux processus deviennent fortement interd*épendantS*
[^] # Re: spelld
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Corrigé, merci (et non pour « a/à contrario », depuis 1990).
# Gentoo...
Posté par Fabien PRORIOL . Évalué à 10.
Finalement, ceux qui n'aime pas systemd peuvent se mettre a Gentoo, ça leur ferait en plus un grand bien, quelque part de marché en plus…
Surtout que Gentoo et vraiment une très bonne distribution; bien que souvent mis de coté…
[^] # Re: Gentoo...
Posté par xcomcmdr . Évalué à 10.
Ceux qui apprécient systemd peuvent aussi utiliser Gentoo sans aucun problème. ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# Erratas
Posté par freem . Évalué à 7.
Le ton semblant plutôt neutre, ce qui est rare quand ça touche systemd, je me permets quelques remarques:
Me semble que sysVinit sera toujours supporté, juste, pas par défaut. S'il n'y à pas de citation confirmant la quote, je continuerai de penser que Debian 8 supportera sysVinit.
Pas sans systemd, mais, sans systemd par défaut.
La notion importante dans ces 2 quote, c'est le "par défaut". C'est aussi la raison pour laquelle je suis mitigé concernant devuan.
[^] # Re: Erratas
Posté par Benoît Sibaud (site web personnel) . Évalué à 8.
Cf http://devuan.org/ Titre de la page « Devuan GNU/Linux - Debian without systemd. », citation « with the first goal of removing systemd ». Y a pas marqué « par défaut » sur le site officiel.
[^] # Re: Erratas
Posté par freem . Évalué à 5.
Exact.
Mon erreur viens du fait que j'avais lu à ce sujet:
Auteur: Noel Torres
Pour épargner aux autres la lecture du fil, en résumé: il y à 2-3 personnes qui rejettent totalement l'idée même d'avoir un support systemd, tandis que les autres considèrent que, si quelqu'un accepte de maintenir systemd sans qu'il n'envahisse le reste, alors pas de souci pour le support de systemd.
Maintenant… position officielle ou pas? Aucune idée.
Donc, mea culpa: il semble bien que devuan sera sans systemd, peut-être à moins que quelqu'un ne s'occupe de la maintenance.
[^] # Re: Erratas
Posté par rogo . Évalué à 2.
C'est aussi ce qu'il me semble. J'avais laissé un commentaire pendant la phase de rédaction pour pointer ce passage qui me semblait fallacieux, pour ne pas dire mensonger. Mais je n'avais pas voulu corriger moi-même, échaudé par quelques mauvaises expériences dans Wikipedia sur les sujets polémiques.
[^] # Re: Erratas
Posté par Samuel Thibault (site web personnel) . Évalué à 4.
Je confirme que sysvinit sera maintenu comme possibilité dans Debian. Après, comme toujours, c'est une question de s'en occuper. S'il y a des gens pour le faire, ça continuera. Si personne ne se remonte les manches, ça ne continuera pas. C'est aussi simple que ça.
[^] # Re: Erratas
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# Très bon article
Posté par adinsx (Mastodon) . Évalué à 3.
Très bon article. En tout cas, sans être particulièrement neutre, les avis me paraissent équitablement répartis.
# si ce titre n'est pas un appel au troll
Posté par modr123 . Évalué à -6.
….
# Temps de rédaction ?
Posté par Anthony Jaguenaud . Évalué à 5.
Salut, j’ai participé au débat à un moment, et ai même écris quelques lignes, mais ça fait plusieurs mois déjà. Cette dépêche ne détient-elle pas le record du temps passé en rédaction ?
Ce temps est-il connu ?
# Cela confirme mon avis sur cette brique système : sympa sur les dekstop , incensée sur un serveur !
Posté par ledufakademy . Évalué à -10.
Il fout une belle merde et à mon avis ce n'est que le début : merci Lennard.
Certes niveau perf. c'est ingénieux, niveaux modularité on touche le fonds …
a+
[^] # Re: Cela confirme mon avis sur cette brique système: sympa sur les dekstop , incensée sur un serveur
Posté par xcomcmdr . Évalué à 5.
Mais c'est quoi cette rumeur que systemd c'est pour le desktop.
Le premier utilisateur et développeur de systemd, c'est RedHat. Le desktop, RedHat s'en fout.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Cela confirme mon avis sur cette brique système: sympa sur les dekstop , incensée sur un serveur
Posté par gouttegd . Évalué à 2.
Mais c’est quoi cette rumeur que Red Hat Enterprise Linux c’est que pour les serveurs ?
[^] # Re: Cela confirme mon avis sur cette brique système: sympa sur les dekstop , incensée sur un serveur
Posté par Christophe . Évalué à 10.
Mais c'est quoi cette rumeur qu'il y a une rumeur ?
[^] # Re: Cela confirme mon avis sur cette brique système: sympa sur les dekstop , incensée sur un serveur
Posté par El Titi . Évalué à 10.
Ca met tout le monde de mauvaise rumeur, en plus.
[^] # Re: Cela confirme mon avis sur cette brique système: sympa sur les dekstop , incensée sur un serveur
Posté par Thomas Douillard . Évalué à 3.
Un ptit rhum tout à l'heure devrait alléger l'atmosphère.
[^] # Re: Cela confirme mon avis sur cette brique système: sympa sur les dekstop , incensée sur un serveur
Posté par Misc (site web personnel) . Évalué à 7.
Alors je rajoute un bémol, il y a des nuances entre "ne fait rien du tout" et "mets tout son pognon dessus". Le desktop pour RH est entre les 2. Il y a un produit ( cf site web, chercher "RHEL Workstation" ), il y a des clients ( cf site web également, genre pixar ). Il y a des gens payés dessus ( cf les gens dont on trouve le nom dans les changelog et les gens payé sur gnome ).
Ensuite, ouais, y a pas besoin d'aller éplucher les rapports donnés à la SEC pour dire que c'est pas le produit qui ramène le plus de pognon ( et ça en ramène assez pour autofinancer l'équipe, d'après le chef de l'équipe Desktop chez eux que j'ai croisé au Guadec à Strasbourg ).
Donc ça pourrait trés bien être un truc sponso par RH et utile sur le desktop.
Le fait est que systemd offre des fonctions utiles pour le serveur:
- le fait de tuer de manière sure un service
- les limitations de ressources via cgroups
- la gestion des containers
- le fait de placer chaque service dans un environnement propre et répétable
- un système de HA rudimentaire (via la relance automatique, chose qu'on demande parfois à un opérateur humain de faire)
- l'activation par socket, ce qui permet de faire du "à la demande", et donc d'augmenter la densité des services par serveur
- l'isolation des services, pour une plus grande sécurité d'un service exposé sur le réseau (PrivatTmp, blacklist de syscall, etc )
C'est des fonctions qui répondent plus à des problématiques "serveur" que des problématiques 'desktop'.
# C'est une honte.
Posté par KiKouN . Évalué à 10.
Autant de titre et aucun avec 42.
[^] # Re: C'est une honte.
Posté par ariasuni . Évalué à 3.
C'était pas suffisant?
Écrit en Bépo selon l’orthographe de 1990
# Le bon chasseur et le mauvais chasseur
Posté par El Titi . Évalué à 2.
…
Autrement dit, dans la philosophie Unix, l’approche pour résoudre un problème est d’écrire plein de petits logiciels qui se concentrent sur une étape de la résolution du problème, fonctionnent orthogonalement et utilisent un protocole clair, au lieu d'écrire un gros logiciel.
Y'aurait pas comme une petite manière de tourner en rond ?
Sinon pour un profane vis à vis de toutes les entrailles de Linux comme moi, cet article est très intéressant et vraiment abordable.
Il manque juste une petite explication ou un lien sur les cgroups.
Ce que j'en retiens c'est qu'avant tous les services devaient se repalucher de gérer mêmes tâches à chaque fois souvent de manière différente et que systemd permet de gérer ceci de manière transverse et unifiée.
Si je résume, les linuxiens viennent de découvrir la programmation par aspect.
Bravo, vous serez bientôt au niveau des architectes J2EE (Il est pas mignon celui-là ?)
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par rogo . Évalué à 5.
Les cgroups permettent de coller une balise sur un processus. C'est particulièrement utile parce que cela permet notamment :
Le 1 est tout simple : on peut limiter le volume de mémoire, la quantité de processeur ou d'entrée/sortie auquel le cgroup aura accès.
Le 2 rend possible de suspendre une application pour la redémarrer plus tard. Une sorte d'hibernation partielle.
Le 3 est à mes yeux fondamental, c'est le seul moyen que je connaisse pour surveiller totalement un processus, et c'est ce que fait systemd, cf systemd for Administrators, Part II. Sinon, à coup de forks et autres astuces, une application peut fausser compagnie à son moniteur.
D'ailleurs, le besoin tout simple de lancer une appli en mode démon avec redémarrage automatique en cas d'arrêt, ce besoin naturel était très dur à satisfaire avec sysvinit. start-stop-demon ne suffit pas, et si le processus n'écrit pas son pid, monit non plus. Il fallait bidouiller ou recourir à runit et toute sa complexité. Désormais, ça se fait en 5 lignes évidentes.
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par zul (site web personnel) . Évalué à -1.
Quelle est ta métrique de complexité ? Pour moi runit est globalement beaucoup plus simple que systemd (et portable OS/libc/compilateur :)).
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par rogo . Évalué à 5.
Runit est plus simple que systemd. Trop simple, d'ailleurs, puisque, bien qu'étant prévu pour servir d'init, personne ne l'envisage sérieusement. En tout cas, je ne l'ai jamais vu apparaître dans les discussions sur le passage à systemd, upstart, ou openrc.
Donc on se retrouve à utiliser runit comme un complément au système d'init. Avec ses propres commandes, comme
sv, ses propres répertoires et fichiers de configuration, son système de log intégré, son espace utilisateur configurable séparément, etc. Tout ça en parallèle deservice, de /etc/init.d/, de rsyslog, etc. Bref, le terme de complexité me semble justifié.Personnellement, j'avais pataugé plusieurs heures pour installer runit comme "monitoring & respawn system". La doc succincte, le peu d'utilisation, et les messages minimaux n'ont pas aidé. Et je n'aurais pas osé y toucher ensuite sans mon mémo perso. Une fois passé à systemd et désinstallé runit, j'ai lu une doc, et en un quart d'heure la migration était faite.
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par ariasuni . Évalué à 3.
Ou la traduction systemd pour les administrateurs publiée sur Linuxfr.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par xcomcmdr . Évalué à -2. Dernière modification le 24 février 2015 à 18:33.
Oui et ça s'appelle de l'overengineering. ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par Benoît Sibaud (site web personnel) . Évalué à 10. Dernière modification le 01 mars 2015 à 18:23.
En même temps, si on peut tracer « sept lignes rouge parallèles, deux à l'encre rouge, deux à l'encre verte et le reste transparent, dont une en forme de chaton », on peut bien avoir plein de petits logiciels tous orthogonaux entre eux, du moment qu'on choisit bien les couleurs, dont un en forme de systemd.
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par ariasuni . Évalué à 2.
Lien qui marche: http://www.universalsubtitles.org/en/videos/wKpYdZPoiNaH/en-gb/693505/
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par Misc (site web personnel) . Évalué à 5. Dernière modification le 26 février 2015 à 10:58.
Ce que je retiens, c'est surtout que si ce point de la philosophie unix était important, on tournerais plus sous qnx ou le hurd. Voir même sur darwin, si je me souviens bien.
Voir même celui de NT, qui est une espace de micro noyau aussi, sauf erreur de ma part.
Donc bon, c'est bien joli de citer des textes sacralisés sans les comprendre et sans savoir, mais ça fait quand même passé les gens pour des rigolos.
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par freem . Évalué à 3.
Hum… parce qu'entre un micro noyau et les autres composants, c'est du texte qui circule? La philosophie UNIX telle que je la voit, c'est 1) des binaires séparés qui ne font qu'une chose et la font bien et 2) de la communication en texte brut.
Le point 1 dégage d'office le hurd :) encore, tu aurais parlé de minix…
Dans le cas des composants d'un kernel, je doute que ce soit très pertinent.
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par xcomcmdr . Évalué à 2.
Au bout d'un moment, à force de couper les cheveux en quatre, tout ce que tu fais c'est gagner en complexité.
idem, c'est pas forcément le meilleur choix. Le texte brut, c'est verbeux, difficile à parser, etc…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 0.
En plus d'être (comme ça a été dit plus haut) verbeux et difficile à parser… ça n'existe tout simplement pas. Parce que "texte brut" sans aucune précision, ça ne donne pas la moindre idée de l'encodage à utiliser. Et un format texte sans son encodage, c'est le drame…
La connaissance libre : https://zestedesavoir.com
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par freem . Évalué à 4.
Comment quelque chose qui n'existe pas peut-il être verbeux?
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par Moonz . Évalué à 3.
Text-based protocol
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
C'est "raw-Text-based protocol" qui n'existe pas.
"La première sécurité est la liberté"
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par Moonz . Évalué à 3. Dernière modification le 26 février 2015 à 16:19.
(et pour continuer à faire du mal à ces pauvres insectes, « texte brut » est tout à fait clair et fait référence à une dichotomie bien réelle, c’est par opposition à « texte formaté » type .doc/.rtf/.odt)
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par Tonton Th (Mastodon) . Évalué à 3.
Oh ! un fufeur !
latin-1 ou utf-8 ?
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par Moonz . Évalué à 3. Dernière modification le 26 février 2015 à 16:25.
Plain text
(qui est explicitement écrit dans l’article Text-based protocol)
Ho, et avant de me dire « oui mais texte brut en français c’est pas ça », regardez quelle est la version française de l’article anglais…
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Quel encodage ? Parce que si ton programme attend du pure ASCII 7 bits, il va faire des trucs marrants avec de l'utf8. Surtout si il interprète les caractères de contrôle.
Le passage à l'UTF8 sur les consoles Linux ne s'est pas fait de façon très joli.
"La première sécurité est la liberté"
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par Moonz . Évalué à 1.
C’est écrit dans l’article lié plus haut.
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par Misc (site web personnel) . Évalué à 5.
Je vois pas ou est marqué "du texte brut" dans ce qui est cité, c'est une interprétation de ta part sur ce que tu estime être clair. Techniquement, du xml serait aussi du texte brut, ça n'a rien de clair en pratique.
C'est marqué "des moyens de communication clair". Des appels RPC définis (exemple, l'API qu'un process doit implémenter pour un filesystem sur le hurd) sont des moyens clairs de communication ( sauf si tu penses que l'API posix, à base de grosso modo les mêmes primitves, n'est pas clair et donc ne respecte pas l'esprit UNIX.
On peut quand même voi comment une simple phrase sorti de son contexte et répété advitam eternam en guise d’épitome d'un ouvrage exposant l'état de l'art de la recherche d'il y a 40 ans dans un domaine bougant à toute vitesse est encore trop compliqué pour que les gens l'utilisent pour exprimer une idée clair.
Je commence à trouver ça curieux qu'un groupe fortement imprégné par l'esprit scientifique en revienne presque à des méthodes shamanique de vénération des textes "anciens" sans avoir le moindre recul vis à vis d'eux et de leur propre position.
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par Moonz . Évalué à 10.
« Voici la philosophie Unix : écrire un bon programme qui ne réalise qu’une seule tâche. Écrire des programmes coopérant entre eux. Écrire des programmes qui gèrent des flots de données textuelles, car cette interface est universelle. » (McIlroy)
« La tradition Unix encourage les programmes qui manipulent des formats simples, en mode texte, orientés flot et indépendants des équipements. Unix appelle de tels programmes des filtres ; ils reçoivent un simple flot de texte en entrée, le traitent et génèrent un simple flot de texte en sortie. » (Eric Raymond)
Tu interprètes (très) mal la situation à mon avis.
Comme tu dis, Unix est là depuis plus de 40 ans, dans un domaine extrêmement mouvant. Ce n’est probablement pas un hasard ; il y a très certainement des invariants dessous susceptibles d’expliquer sa longévité. La « philosophie Unix » que beaucoup ici traitent avec mépris, c’est justement une tentative d’isoler et expliciter ces invariants, dans l’objectif d’en tirer des leçons pour l’architecture logicielle en général.
Bien sûr, l’analyse peut être fausse, les conclusions erronées voire contreproductives. Mais ce n’est pas en balançant nonchalamment « 40 ans ; trop vieux » (alors qu’au contraire, la longévité serait plutôt bon signe) ou « chamanisme irrationel » (alors que justement, quand on creuse un peu, on se rend compte que la philosophie Unix, elle sort pas d’un chapeau, elle sort d’un gros boulot d’analyse effectué par de nombreuses et éminentes personnes).
Si tu prends l’exemple justement de l’insistance des interfaces textuelles, il y a plusieurs raisons à ça. La plus importante selon moi est la suivante : cela te force à faire une distinction entre la représentation algorithmique de tes données, la représentation fonctionnelle de tes données, et la représentation sémantique de tes données. Représentation algorithmique : comment représenter les données en mémoire pour résoudre efficacement le problème. Représentation fonctionnelle des données : comment communiquer efficacement l’état du problème à la machine. Représentation sémantique des données : comment communiquer efficacement l’état du problème à l’humain. Quand tu forces tes entrées et tes sorties à être textuelles, tu es forcé de te poser ces questions, parce que tu es forcé d’écrire la conversion entre les différentes représentations et ce même si tu n’as pas idée de ces distinctions. Ça te donne quasiment-automatiquement un système aisément débuggable et aisément testable. À contrario, le binaire, en général, ça se passe comme ça : je code mon algorithme. À partir de mon algorithme, je décide comment sont représentées en mémoire les entrées et les sorties. Et de là, je définis mon protocole binaire : en entrée,
read(struct ProblemSpecification), en sortiewrite(struct Solution).Bien sûr, tu peux très bien faire cette analyse avec un format binaire (par exemple protobuf), et la foirer avec un format texte (pas mal de formats XML en sont un bon exemple effectivement, mais ce n’est pas étonnant si tu gardes en tête l’analyse précédente : beaucoup de formats XML sont juste une image de la structure interne du programme). Mais en pratique, si on accepte l’idée que faire l’analyse poussée des différentes représentations est une bonne idée, alors la spécification des entrées/sorties en format textuel est une bonne méthodologie, parce que les incitations naturelles derrière y tendent. Pour parler très abstraitement, il n’y a pas équivalence entre « protocole textuel » et « bien conçu », mais il y a certainement corrélation.
Ceci n’est qu’une raison parmi un certain nombre, mais mon message commence à être déjà assez long comme ça (et il faudrait que j’aille dormir ;)), et il y a des bouquins entiers qui analysent la « philosophie Unix » de cette manière. Pas en tant que révérence irrationnelle envers un passé idéalisé, mais en tant que leçons pragmatiques à tirer.
La philosophie Unix ce n’est pas un Dieu bienfaisant qui va te garantir le succès si tu répètes quelque mantras. La philosophie Unix ce n’est pas non plus un Dieu colérique qui va te punir si tu ne fais pas exactement comme écrit dans La Loi. Mais c’est la sagesse condensée de gens qui ont fait plus pour l’informatique que tout ce que tu pourras rêver de faire, et il est aussi bon d’avoir un peu d’humilité avant de mettre tout ça à la poubelle d’un revers de main.
Tu peux critiquer la philosophie Unix. Seulement, si tu veux la critiquer efficacement, il faut d’abord la comprendre. Quelqu’un qui dit « philosophie Unix : texte, par exemple
json_encode($internalStruct)» est bien plus éloigné de la philosophie Unix que quelqu’un qui dit « OK, mon programme va communiquer en protobuf (binaire), mais que ça ne me dispense pas de réfléchir aux différentes représentations de mon problème ». Mais le plus éloigné de tous, c’est celui qui dit « haha, utiliser du texte en 2015 juste parce que quelqu’un en 1970 a dit que c’était cool ? ridicule ! ». En fait, j’en envie de dire que c’est bel et bien ceux qui l’ont comprise qui sont le mieux placé pour violer les règles. Si je devais faire du 100% « strict philosophie Unix » à mon boulot, ça ferait longtemps que je serais à la porte (parce que bon, un programme en ligne de commande pour le service compta, ça va pas le faire :)) ; par contre, je suis bien placé pour savoir que mon efficacité sur l’analyse du problème et la recherche de solutions provient directement d’un état d’esprit qui découle de la philosophie Unix — et ce d’autant plus que je n’ai pas toujous été « Unixien », et que je vois clairement la différence entre « avant » et « après », en terme d’efficacité.[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par Samuel Thibault (site web personnel) . Évalué à -1.
Heu, le Hurd marche beaucoup mieux que Minix. Ce n'est même plus comparable en fait.
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par Moonz . Évalué à 2.
Si les éviter les bugs était important, on utiliserait aucun outil plus compliqué que
ed.# TU
Posté par Stibb . Évalué à 5.
J'y vois surtout la possiblité d'écrire des test unitaires qui renderaient le systeme plus robuste. Parce qu'écrire des test unitaires sur des scripts bash…
[^] # Re: TU
Posté par sifu . Évalué à 1.
Quand on veut on peut https://code.google.com/p/shunit2/ ;)
[^] # Re: TU
Posté par xcomcmdr . Évalué à -2.
Le dernier changement date de 2013…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: TU
Posté par Anthony Jaguenaud . Évalué à 2.
Et ? Deux solutions :
Il reste en fait 20 bugs : 1 critique, 4 demandes d’évolution, 1 low, 1 non catégorisé et 13 medium. Visiblement, rien de vraiment critique.
Merci, je garde cet outil en mémoire pour plus tard.
[^] # Re: TU
Posté par xcomcmdr . Évalué à -2. Dernière modification le 25 février 2015 à 11:32.
Mythe.
Il est compatible avec les différents shells ? il n'a pas le moindre bug ? Pas la moindre amélioration possible ? Il est PARFAIT ? Aucune faille de sécurité ? Aucun besoin de suivre l'évolution des shells et des pratiques ? Aucune faille de sécurité ? Aucun aspect critiquable ?
Ouais, j'en ai jamais vu des comme ça, hein.
Il est donc abandonné et à réparer. Génial.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: TU
Posté par hugoL . Évalué à 1.
Mythe?
http://ctan.mackichan.com/systems/knuth/dist/tex/tex.web
[^] # Re: TU
Posté par Misc (site web personnel) . Évalué à 2.
Dans mon souvenir, l'usage de l'UTF8 dans tex/latex est toujours un peu tendu, mais j'imagine qu ça compte pas comme bug, mais comme évolution.
Des gens vont te dire que tex est pas facile à utiliser, mais vu le mépris qu'on a pour les gens qui veulent rendre les choses plus simples, j'imagine que ça ne compte pas comme bug non plus.
[^] # Re: TU
Posté par sifu . Évalué à 2.
Oui, enfin c'était juste pour montrer que cela existait.
Il semble que le shunit premier du nom soit plus vivant.
Après, personnellement, je préfère passer à autre chose que bash quand cela dépasse un certains nombre de lignes.
[^] # Re: TU
Posté par Stibb . Évalué à 2.
evidement que je connais.
Et biensûr j'ai tenté de l'utiliser, je me suis tirer une balle et je suis retourner à python…
# Excellent article
Posté par ocroquette . Évalué à 1.
Merci!
# concours de titre... suiite
Posté par El Titi . Évalué à 4.
Arrêtez de nous taper sur le systemd!
… Next?
# LTS ? Systèmes embarqués nécessitant un vieu kernel ?
Posté par Astaoth . Évalué à 2.
Donc si je comprends bien, une distribution ne peut plus avoir un système d'init récent avec un ancien kernel. Et elle ne peut plus non plus avoir un udev à jour avec un "vieux" système d'init. Comment ca va se passer avec les versions LTS ? Elles ne seront maintenues que pendant 2 ans ?
De même, comment ca va se passer pour les outils ou drivers (en particulier quand on sort du monde des serveurs et des ordis de bureautique) qui ne sont plus maintenus et qui demandent une version spécifique du kernel ? Ca sera uniquement Gentoo ?
Emacs le fait depuis 30 ans.
[^] # Re: LTS ? Systèmes embarqués nécessitant un vieu kernel ?
Posté par Mildred (site web personnel) . Évalué à 5.
Ça fait un moment que systemd ne requiert plus le dernier kernel. Il nécessite d'activer certaines options, mais le kernel le plus vieux supporté est le 3.7 sorti il y a deux ans. Et je doute que cela va changer.
[^] # Re: LTS ? Systèmes embarqués nécessitant un vieu kernel ?
Posté par GnunuX (site web personnel) . Évalué à 10.
Tu connais beaucoup de distro qui mettent à jour leur système d'init en LTS ?
[^] # Re: LTS ? Systèmes embarqués nécessitant un vieu kernel ?
Posté par Misc (site web personnel) . Évalué à 2.
Je connais un ISV qui voulait avoir systemd sur une base EL6. Mais ensuite, c'est vouloir le beurre et l'argent du beurre, si tu dépends de quelqu'un d'autre pour ta base, tu dépends des choix de l'autre groupe.
# Svcadm vs systemd
Posté par root_rtfm . Évalué à -6.
Hello,
Merci pour cette dépêche qui permet de faire un point sur systemd.
Je suis plutôt contre cette outil, même s'il est vrai que l'init actuel avec des scripts spécifiques aux distributions (ex : function dans init.d) posent, comme évoqué, des problème de portage.
Néanmoins, d'autres UNIX ont modifiés leur init, dont Solaris qui est passé à svcadm…. il est quasiment impossible d'écrire simplement un script d'initialisation, finalement, c'est fréquemment l'utilisation des anciens /etc/init.d/xxx et /etc/rc?.d/S/K qui est préféré. Finalement, l'init est beaucoup moins claire à débugger qu'avec l'ancien système.
Enfin, les logs au format binaire … AIX les propose … sans commentaires.
Même si l'init des Linux doit évoluer, même s'améliorer, je ne pense pas que l'approche au forcing de systemd soit la bonne, nous allons devoir supporter de nombreuse galères (j'ai tester récemment Cent0S7 : il faut réécrire tout nos scripts d'installation …)
[^] # Re: Svcadm vs systemd
Posté par Anonyme . Évalué à 7.
En quoi est ce qu'il y a une approche au forcing de systemd ?
Il n'y a pas de forcing, aucune distribution n'a été forcée à adopter systemd. Ce sont les developeurs de ces distributions qui ont estimé que c'était le meilleur choix.
[^] # Re: Svcadm vs systemd
Posté par Zenitram (site web personnel) . Évalué à 0. Dernière modification le 25 février 2015 à 13:57.
Ca y est, les conneries des anti-sytemd repartent, ça avait pourtant réussi à tenir un petit moment.
Désolé, que les gens choisissent démocratiquement quelque chose qui ne te plait pas != forcing.
Pauvre petit.
Oui, c'est dur le changement, faut réapprendre.
Mais c'est normal, et et personne ne te force à passer à CentOS 7 : tu peux garder l'ancien pendant 1000 ans si tu veux. La seule problématique que tu as est que tu ne peux forcer personne à faire le travail pour toi.
Celui qui force en ce moment, ce n'est pas systemd mais plutôt root_rtfm, et pas de pot les autres n'acceptent pas le forcing et vivent leur vie malgré les pauvres petits râleurs qui "doivent" ré-écrire leurs scripts maison (sont-ils libres et diffusés au moins? systemd l'est) comme ça a toujours existé dans l'évolution de l'informatique.
root_rtfm ne devrait pas avoir à s'adapter aux autres, ce sont les autres qui doivent s'adapter à root_rtfm.
# Ouf !
Posté par Tonton Th (Mastodon) . Évalué à 5.
Mon Prumpleffer était enclenché
:)# Ne la laisse pas tomber elle est si fragile être une init libérée tu sais c'est pas si facile
Posté par walker17x . Évalué à -9.
l'évolution de systemd est bien plus rapide que toutes la concurrence , les performances aussi sont meilleurs , que demander de plus ?
depuis le temps que tout le monde pleurniche car chacun faisait sa propre route , maintenant qu'on a enfin une communauté soudé par son init c'est une bonne nouvelle !
Et dans quelques années on verra la même chose avec Mir qui dominera Wayland et tout le monde retournera sa veste pour Mir qui sera plus performant et plus flexible.
[^] # Re: Ne la laisse pas tomber elle est si fragile être une init libérée tu sais c'est pas si facile
Posté par reno . Évalué à 7.
Pas crédible ton troll "Mir qui dominera Wayland et tout le monde retournera sa veste pour Mir qui sera plus performant et plus flexible.", je n'ai vu aucun argument technique en faveur de Mir par rapport à Wayland.
Les performances des deux devraient être équivalentes (ça peut varier d'un compositeur à l'autre pour Wayland donc c'est difficile de parler de performance 'Wayland')..
[^] # Re: Ne la laisse pas tomber elle est si fragile être une init libérée tu sais c'est pas si facile
Posté par Albert_ . Évalué à 1.
Le probleme de wayland c'est que ca fait des annees que c'est cense arriver et que cela n'arrive pas, d'ou la creation de Mir qui, en faisant probablement pas les meilleurs choix theorique, a un truc en prod. Je ne sais pas si a la fin il gagnera mais wayland c'est pas demain que cela sera en prod.
[^] # Re: Ne la laisse pas tomber elle est si fragile être une init libérée tu sais c'est pas si facile
Posté par Aissen . Évalué à 9.
Le seul intérêt de Mir c’est de permettre à Canonical de contrôler la plateforme grâce à la GPLv3 + Copyright Assignement. Les fabricants de téléphone étant allergique à la GPLv3, ça permet à Canonical de leur vendre une license sans GPLv3.
Un argument technique pour Mir qui était présenté c’était de pouvoir utiliser les drivers Android, mais en fait ils ont fait ça en utilisant libhybris, à la base codé par Jolla pour utiliser des drivers Android avec… Wayland!
Au final aujourd’hui Wayland est dans plus de produits sur le marché que Mir, mais ce n’est qu’un détail ;-)
[^] # Re: Ne la laisse pas tomber elle est si fragile être une init libérée tu sais c'est pas si facile
Posté par rogo . Évalué à 7.
Source ? Parce que je lis les annonces Wayland, et je n'ai jamais vu la moindre promesse de livraison rapide. Même lors de l'annonce de la version 1.0, fin 2012, il y avait plutôt des mises en garde sur le sujet. Cf la dépêche LinuxFr de l'époque.
Idem pour l'intégration dans les toolkits graphiques, ça c'est toujours inscrit dans une perspective longue. Par exemple, Gnome, en 2012, ne prévoyait pas de compatibilité totale avant 2014.
Aujourd'hui, Wayland et Weston ne sont pas encore prêts pour la prod, mais c'est aussi parce que chacun préfère peaufiner plutôt que de se presser. Fedora 20 propose déjà Wayland, l'imminente Fedora 21 l'utilisera au moins pour la page de login, et peut-être que F22 ou 23 l'adoptera par défaut. Ça avance comme prévu, tranquillement.
[^] # Re: Ne la laisse pas tomber elle est si fragile être une init libérée tu sais c'est pas si facile
Posté par Kekun (site web personnel, Mastodon) . Évalué à 2.
Petit errata : la dernière c'est la 21, qui la propose, et la 22 à venir l'utilisera jusqu'à GDM inclus.
En gros, tout comme t'as dit en ajoutant 1 à chaque version de Fedora !
[^] # Re: Ne la laisse pas tomber elle est si fragile être une init libérée tu sais c'est pas si facile
Posté par GnunuX (site web personnel) . Évalué à 3.
Quelle distribution à Mir par défaut en "prod" ?
[^] # Re: Ne la laisse pas tomber elle est si fragile être une init libérée tu sais c'est pas si facile
Posté par lolop (site web personnel) . Évalué à 5.
Assez de dénigrement!
Elle a quand même été utilisée par la distribution RKA, avec un arrêt volontaire en 2001.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Ne la laisse pas tomber elle est si fragile être une init libérée tu sais c'est pas si facile
Posté par reno . Évalué à 9.
Pas sûr que tu sois bien renseigné: Wayland est en déjà en prod et l'a été avant Mir, d'autant plus que c'est XMir qui est utilisé en prod, ce qui n'est pas vraiment Mir (XWayland ce n'est pas vraiment Wayland non plus): je ne pense pas que XMir|XWayland fournissent des avantages en performance par rapport à X11(natif) puisqu'il y a une surcouche intermédiaire.
Wayland est considéré comme stable, le gros travail restant est le portage des logiciels (KDE, Gnome).
A mon avis Canonical a fait Mir pour des raisons de contrôle du projet, pas pour la date de livraison, en tout cas si c'était pour la date de livraison, ils se sont plantés en beauté car les deux vont arriver à maturité quasiment en même temps.
[^] # Re: Ne la laisse pas tomber elle est si fragile être une init libérée tu sais c'est pas si facile
Posté par Albert_ . Évalué à 5.
On se calme. Je ne dis pas que je suis pour Mir et que je suis pour la license de canonical (je suis contre) mais quand on regarde de facon pragmatique, wayland ca fait des annees que l'on en entend parler. Le dev de Mir a commence bien apres et il est la (ubuntu phone). En effet wayland est, enfin, en train d'arriver mais tant que les bureaux ne le supporte pas cela ne sert … a rien et je me demande a quel point Mir n'a pas ete le coup de pied au cul pour faire avancer les choses.
ps: parfois recevoir un coup de pied au cul lors d'un projet ca fait pas de mal.
[^] # Re: Ne la laisse pas tomber elle est si fragile être une init libérée tu sais c'est pas si facile
Posté par Renault (site web personnel) . Évalué à 9.
Mouais, je ne suis pas convaincu par la manière dont tu présentes tout cela.
Wayland est utilisé depuis 1 an et demi en production (le téléphone Jolla existait bien avant Ubuntu Touch). Wayland n'a pas eu besoin de Mir pour se bouger. Mir n'existe pour l'instant que sur le papier, le téléphone en question n'est pas encore vendu et utilisé au quotidien.
Les briques de bases sont là, Gnome-Shell est presque utilisable au quotidien en Wayland pur, il est probable que d'ici un an Fedora le mette par défaut. Actuellement EFL, GTK+ et Qt ont fini le portage, ou c'est en cours de finition. Et pour ceux qui ne se mettront aps à jour vis à vis de ces bibliothèques ça devra utiliser XWayland.
[^] # Re: Ne la laisse pas tomber elle est si fragile être une init libérée tu sais c'est pas si facile
Posté par Albert_ . Évalué à 5.
le téléphone en question n'est pas encore vendu et utilisé au quotidien.
Euh si, il est vendu (depuis la semaine derniere) apres pour l'utilisation au quotidien ca depend des acheteurs.
Tant mieux si wayland decolle, comme je l'ai dit je ne suis pas du tout d'accord avec la license de canonical mais je ne suis pas si optimiste que toi. Et je ne suis pas sur de voir mon desktop tourner dessus avant pas mal de temps (les telephones je dois avouer que je m'en moque un peu, je suis beaucoup plus a bosser sur mon pc. Mais bon vu le manque, par rapport a X11, de transparence reseau etc je ne suis pas si presse de le voir arriver par defaut.
[^] # Re: Ne la laisse pas tomber elle est si fragile être une init libérée tu sais c'est pas si facile
Posté par gorbal . Évalué à 8.
Mon téléphone (Jolla) utlise Wayland depuis plus d'un an. Donc Wayland est bien arrivé en production depuis avant Mir.
[^] # Re: Ne la laisse pas tomber elle est si fragile être une init libérée tu sais c'est pas si facile
Posté par ariasuni . Évalué à 3.
Forcément, quand on forke plein de trucs de ce qui a déjà été fait, ça avance plus vite.
XMir est un fork de XWayland par exemple, et je crois savoir qu'il y a plein de trucs qui sont similaire ce qui permet à Mir de réutiliser une bonne partie du travail effectué par et pour Wayland.
Écrit en Bépo selon l’orthographe de 1990
# Ne la laisse pas tomber elle est si fragile être une init libérée tu sais c'est pas si facile
Posté par walker17x . Évalué à -10.
l'évolution de systemd est bien plus rapide que toutes la concurrence , les performances aussi sont meilleurs , que demander de plus ?
depuis le temps que tout le monde pleurniche car chacun faisait sa propre route , maintenant qu'on a enfin une communauté soudé par son init c'est une bonne nouvelle !
Et dans quelques années on verra la même chose avec Mir qui dominera Wayland et tout le monde retournera sa veste pour Mir qui sera plus performant et plus flexible.
[^] # Re: Ne la laisse pas tomber elle est si fragile être une init libérée tu sais c'est pas si facile
Posté par xcomcmdr . Évalué à 1. Dernière modification le 25 février 2015 à 09:31.
"Ne la laisse pas tomber elle est si fragile être une femme libérée tu sais c'est pas si facile"
Je déteste cette chanson infantilisante, voire patriarcale.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Ne la laisse pas tomber elle est si fragile être une init libérée tu sais c'est pas si facile
Posté par gnx . Évalué à 10.
Oui, c'est la conclusion évidente qui ressort de tous les échanges sur systemd :-D
[^] # Re: Ne la laisse pas tomber elle est si fragile être une init libérée tu sais c'est pas si facile
Posté par xcomcmdr . Évalué à -7.
Les mainteneurs de distros sont à peu près tous mis d'accord sur un init/base userspace.
Après, les trollleurs anti-systemd font-ils partie de la communauté : non, sinon ça ferait longtemps que les mainteneurs les auraient écouté (heureusement ils ne l'ont pas fait).
Y'a une communauté, et puis y'a les parasites. ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# FUD
Posté par gnumdk (site web personnel) . Évalué à 10.
Pour ceux qui propagent le FUD en disant: "Oui, mais GNOME ne fonctionnera plus sans systemd, ça va tuer le choix"
http://blogs.gnome.org/ovitters/2015/02/24/consolekit-in-gnome-3-16-and-beyond/
Donc, oui, il faudra des interfaces pour les APIS systemd mais il existe déjà trois alternatives dans le cas de consolekit…
# Quelqu'un devrait modifier l'API de linux pour autre chose que POSIX...
Posté par Enj0lras . Évalué à 8.
… histoire qu'on parle enfin d'autre chose.
[^] # Re: Quelqu'un devrait modifier l'API de linux pour autre chose que POSIX...
Posté par Misc (site web personnel) . Évalué à 10.
Mais le fait est que de manière amusante, aucune distrib Linux moderne n'est certifié POSIX, et que le kernel ne le permet pas.
On a eu la discussion au travail, et les exemples cités sont assez obscures, mais montre bien le souci.
Par exemple, posix defini O_SEARCH
http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html
Et il semble que ça requiert un patch non trivial sur le kernel ( des histoires avec openat et chmod entre temps ) et que les discussions pour faire ça dans la glibc n'ont pas aboutit à un patch. Et que les gens de musl semblent pousser aussi pour le support kernel.
Un autre exemple est :
"mkdir a; ln -s a b; rmdir b/"
Sur linux, ça fait un message d'erreur.
D'après la norme POSIX, le / indique de s'appliquer à la cible du symlink :
http://cygwin.com/ml/cygwin/2005-04/msg00566.html
https://unix.stackexchange.com/questions/29769/trailing-slashes-on-symbolic-links-to-directories
Et sur OS X, qui est certifié Posix, ça passe.
Et il a donné que 2 exemples, mais je suis sur qu'on peut en trouver des tonnes.
Donc à partir du moment ou le monde Linux se fout globalement de la norme POSIX depuis des années, je trouve assez curieux les gens qui disent "il faut la respecter", et je crois que ton vœu est donc déjà réalisé
[^] # Re: Quelqu'un devrait modifier l'API de linux pour autre chose que POSIX...
Posté par Enj0lras . Évalué à 4.
Je sais bien, je parlais d'un hcangement radical…
Dans ce que je trouve bizarre, il y a aussi CLOCK_MONOTONIC qui n'est pas monotone. Ou ctime qui est changé à chaque fois que tu écris dans le fichier (POSIX n'est pas ultra clair sur ce point mais bon).
# intégrer Gnome ou KDE à systemd ?!!!
Posté par cveyoda (site web personnel) . Évalué à -6. Dernière modification le 25 février 2015 à 20:51.
Bonsoir,
je lis "intégrer Gnome ou KDE à systemd" ?
Mais c'est une bonne ou mauvaise chose, ce sénario, parce que l'on dit toujours qu'il faut un noyau léger ?!
Je vais lire les articles sur systemd, j'espère que je pourrais me faire une idée précise et qu'il sera bien documenté, parce que ça doit rester ouvert afin que Red Hat qui finance ne prenne pas le bouzin pour elle-même et fasse son "windows" (bien si tout est intégré) idem avec GNOME.
ouch
[^] # Re: intégrer Gnome ou KDE à systemd ?!!!
Posté par gouttegd . Évalué à 6.
C’est une blague…
Le vrai plan de Lennart Poettering, c’est d’intégrer LibreOffice à systemd. :D
[^] # Re: intégrer Gnome ou KDE à systemd ?!!!
Posté par Frank-N-Furter . Évalué à 9.
Normal, c'est le seul moyen d'avoir un bon pare-feu.
Depending on the time of day, the French go either way.
# Orthogonalité ?
Posté par Yves (site web personnel) . Évalué à 2.
Merci pour cet article qui a l’air prometteur ; je n’ai pas fini de le lire.
Pour m’aider dans ma lecture, quelqu’un pourrait-il m’expliquer l’« orthogonalité » des logiciels ?
Encore merci.
[^] # Re: Orthogonalité ?
Posté par Moonz . Évalué à 10. Dernière modification le 26 février 2015 à 12:19.
C’est la séparation d’un problème en sous-problèmes distincts.
Par exemple, pour le problème « je veux compter le nombre de commentaires dans un code python », je peux séparer mon problème en « extraire les commentaires d’un fichier python » (
grep '#' < script.py) et « compter le nombre de lignes extraites (| wc -l). Le premier outil se fiche de ce que je veux faire de mon extraction (je pourrai les supprimer, faire une traduction automatique avec Google translate, whatever), le second outil se fiche d’où viennent mes lignes : les deux sont orthogonaux.L’avantage c’est que je peux tester les outils indépendamment l’un de l’autre, et réutiliser l’un ou l’autre dans d’autres contextes.
[^] # Re: Orthogonalité ?
Posté par Thomas Douillard . Évalué à 10.
L'inconvénient évident, c'est que comme ça c'est compliqué de gérer les commentaires multilignes. Du coup ça limite l'intérêt de l'orthogonalité pour certains problèmes quand ils seraient résolus plus simplement par des étapes un poil plus intégrées.
[^] # Re: Orthogonalité ?
Posté par freem . Évalué à 8.
Pour du multiligne, grep n'est clairement pas le truc le plus efficace du monde. Par contre, rien n'empêche de les extraire avec awk, qui à l'avantage de pouvoir retenir des données.
Awk pouvant, comme grep, passer ensuite les données à wc ou whatever. Bon, après, awk c'est un «chouïa» plus évolué que grep, et sans mauvais jeu de mots, passer la sortie de awk à wc, c'est un peu à chier quand même (bon, ok, jeu de mot qui pue quand même finalement >.<)…
[^] # Re: Orthogonalité ?
Posté par flan (site web personnel) . Évalué à 8.
Pour moi, ce sont des maths à la base. Prends deux droites orthogonales, qui se coupent donc à angle droit.
Si tu te déplaces sur la droite verticale, tu ne bouges absolument pas horizontalement (par définition). Idem si tu te déplaces sur la droite horizontale. On peut donc dire que ces deux droite sont indépendantes l'une de l'autre.
Maintenant, imagine que la droite verticale est inclinée. Si tu te déplaces le long de la droite inclinée, tu vas également bouger vis-à-vis de la droite horizontale. Quelque part, ces deux droites sont donc « liées » (même si mathématiquement ce n'est pas le bon terme, « lié » a un sens précis en maths).
L'image, c'est que chaque droite correspond à un problème : travailler sur un problème (te déplacer sur la droite) n'a aucune influence sur le second problème quand les deux problème sont orthogonaux.
# 2 cents
Posté par romu . Évalué à 6.
Tout d'abord que je me joins à tout le monde pour remercier l'équipe qui a rédigé ce billet, c'est vraiment passionnant.
De l'extérieur d'un utilisateur, disons, avancé de Linux, je vois SystemD (suite à ce billet) comme une volonté d'avancer sur un OS totalement intégré comme peuvent l'être Windows et OSX. J'ai l'impression que le but est vraiment d'arrêter les bricolages et de faire un truc moderne sur lequel les environnements de bureau pourront s'appuyer pour avoir un meilleure intégration entre la couche graphiques et ses applications d'un côté et le noyau de l'autre. Du coup, lire que des gens râlent sur la liaison entre la gestion des matériels et l'init du système, je trouve ça assez incompréhensible, car ça va justement dans le sens d'une meilleure intégration.
Pour finir, je ne savais pas que cette philosophie de tout faire en texte est partie intégrante de Unix. Perso (je vais me faire taper dessus) je trouve ça un rien obsolète non ? Rien que parser la sortie de ifconfig pour choper l'adresse IP ne marche pas pareil entre Ubuntu et Fedora, le genre de truc que j'imaginais même pas. Et pour avoir travaillé depuis plusieurs années avec Powershell (où tout est sous forme d'instances d'objets), je me dis que Unix a un gros train de retard.
Parce que entre écrire un truc du genre NetInterface.IPAddress et le parsing de ifconfig, y a pas photo, le premier me semble carrément plus simple à comprendre, donc à maintenir, et je me chope pas d’arthrose aux doigts à écrire des expressions régulières obscures.
[^] # Re: 2 cents
Posté par xcomcmdr . Évalué à 6.
L’arthrose, c'est la vi.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.