Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais

Posté par Ignatz Ledebur le 30 novembre 2014 à 11:52. Édité par ZeroHeure, Davy Defaud et Benoît Sibaud. Modéré par ZeroHeure. Licence CC By‑SA.

Étiquettes :

nov.

2014

Ce qui suit est la traduction d'un texte écrit par l'auteur de uselessd que j'ai trouvé particulièrement intéressant en ce qu'il ne cherche pas tant à déterminer qui des zélateurs ou des détracteurs de systemd a raison qu'à exposer pourquoi une telle question ne sera jamais tranchée.

Résumé pour le lecteur pressé ou saturé :

Nous assistons-là à une guerre culturelle, dans laquelle certains soutiennent que les baguettes c'est beaucoup mieux tandis que d'autres ne jurent que par couteaux et fourchettes, mais où personne ne parle en fait de la même cuisine. À la fin, ce sont ceux qui contrôlent la cantine qui vont gagner.

Sommaire

Préface express du traducteur
Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais

Préface express du traducteur

On a encore vu récemment qu'il suffisait de mentionner systemd (sans même risquer un avis dessus) pour relancer un petit Verdun. Ceci n'aura donc pas la naïve prétention de faire asseoir le lion à côté de l'agneau, mais juste de donner à méditer à ceux qui sont las de tous ces pseudo-débats, éternellement reconduits à l'identique (dont, si on se pose la question, le traducteur lui-même se fout bien, étant depuis une décennie sous Slackware – comprendra qui lira).

Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais

L'écriture de ceci m'a été inspirée par les annonces récentes réclamant publiquement un fork de Debian, une idée que je trouve idiote et qui ne débouchera probablement pas sur énormément de travail technique.

Néanmoins, j'ai vu se dérouler le même débat sur systemd une fois encore. Je l'ai déjà vu un nombre incalculable de fois, et il n'y a eu virtuellement aucune variation par rapport à la formule type. Vous avez deux côtés ardents et bruyants, disposés grossièrement selon une dichotomie zélateurs/détracteurs, dont aucun n'a à dire quoi que ce soit d'éclairant avec cependant pour chacun son propre ensemble unique d'incompréhensions, qui ont mémétiquement muté en idées indépendantes empoisonnant virtuellement tout débat de cette nature.

J'évite largement les « débats » autour de systemd à présent. Ils me dépriment à cause de tous les raisonnements erronés et des détournements émergeant partout, mais j'ai senti que peut-être ce petit texte pourrait essayer d'expliquer le contexte et les causes amenant juste systemd à susciter autant de vitriol et de guerres de clochers.

Les erreurs habituelles faites par les zélateurs et les détracteurs

Les sophismes que font les détracteurs de systemd ont été mis en évidence tellement de fois qu'il n'est pas la peine d'en faire une revue exhaustive. Pour ce qui est de l'objet de cet exposé, nous relaterons en y répondant les arguments habituels pour et contre systemd, tels qu'ils se rencontrent dans presque toutes les « discussions policées et nuancées » à son sujet. Le but ici est de montrer que, contrairement à la croyance populaire, ce ne sont pas seulement les détracteurs, avec leurs agaçantes tirades sur la « philosophie Unix » et leur incrédulité technique, qui ont tort, mais qu'à peu près tous ceux impliqués dans cette dispute sont ignorants d'une manière ou d'une autre.

Les arguments idiots donnés par les supporters de systemd ont été largement laissés sans correction et libres de se propager de manière égale aux arguments idiots de leurs opposants, même si moins de monde le reconnaîtra. Cela a été le cas jusqu'à ce que, le 26 septembre 2014, Judec Nelson écrive un billet de blog exhaustif appelé « Systemd : les plus gros sophismes », qui est devenu énorme sur /r/linux et n'a reçu en comparaison que peu de réponses sur HN (NdT : Hacker News).

Jetons un œil à sa réception sur /r/linux.

Les commentaires les mieux évalués comprennent quelqu'un hurlant en retour « sophisme, sophisme », une réfutation partielle des arguments qui comporte des erreurs clés dans son raisonnement (comme échouer à distinguer le system d'init de ses scripts rc), et qui répond largement aux accroches des paragraphes mais pas aux élucidations plus profondes cachées à l'interieur, une personne qui fait une incohérence logique en répondant à une seule remarque d'une manière sans rapport avec son sens réel, un argument bidon sur la façon dont les gens devraient arrêter de crier au sujet des logiciels qu'ils préfèrent, et un peu de discussion positive ou nuancée mélangée partout dans tout ça. Très discutable est le vitriol rance jeté par un utilisateur qui qualifie l'auteur de « sale putain de troll manipulateur ».

Pour l'essentiel, nous voyons que presque tout le monde fait du mieux qu'il peut pour éviter de corriger quoi que ce soit, se mettant immédiatement sur la défensive.

Cela ne cherche pas à mettre en accusation les zélateurs de systemd, mais plutôt à montrer une chose : le débat autour de systemd est rarement une dispute technique quel que soit le côté, au lieu de cela, c'est une guerre idéologique et culturelle engagée entre deux populations opposées qui habitent la même sphère générale de Linux et du Libre. Ça n'est pas une question de qualités techniques, c'est une question de politique. Peu l'admettront, mais les gens qui se disputent ne sont pas réellement soucieux d'améliorer l'état des systèmes de gestion de processus. Ils sont impliqués dans un schisme philosophique sans précédent dans le logiciel libre, qui aura probablement quelques implications notables dans le futur. Les identités et les egos sont à l'œuvre ici.

En avant.

Architecture monolithique

« systemd est monolithique ! Il implémente tout dans PID 1 ! », dit le détracteur de systemd, en ayant tout faux.

« systemd n'est pas monolithique ! Songez aux 69 binaires ! », répond le zélateur de systemd, en ayant également tout faux.

Les disputes autour de l'architecture de systemd ont tendance à être des bouillies de jargon avec différentes interprétations, souvent avec des gens considérant que le caractère modulaire d'une chose la rend automatiquement non-monolithique. Le problème est que cela est en réalité correct selon certaines définitions. De l'autre côté, quelque chose étant et modulaire (à un degré au moins) et monolithique simultanément est également absolument possible et considéré comme une interprétation correcte pour divers logiciels tels X.Org, Busybox et le noyau Linux.

Cette espèce de guerre linguistique est typiquement ce qui détourne les esprits de certaines des décisions techniques les plus profondes prises par systemd, et conduit a des manques de compréhension mutuels auto-imposés. Les détracteurs refuseront souvent de lâcher le mensonge d'un énorme blob collé dans PID 1, mais les zélateurs refuseront pareillement d'admettre que la modularité de systemd n'est pas aussi étendue qu'elle pourrait l'être et que son PID 1 demeure quoi qu'il en soit plus gros que dans la plupart des autres systèmes.

Ce sale diable de Lennart

Souvent à l'initiative des détracteurs, qui vont se lamenter des horreurs de PulseAudio et mettre en évidence leur mépris pour Lennart Poettering. Cela est après coup devenu un faux prétexte habituel à l'usage des zélateurs pour balayer les critiques comme relevant d'attaques personnelles contre Lennart. Il est futile de même en discuter, mais c'est un élément important.

La personnalité de Lennart est en réalité, de temps en temps, un sujet pertinent. Essayer d'avoir une grande discussion autour de systemd sans l'invoquer est comme discuter du détail de la glibc sans jamais mentionner Ulrich Drepper. La plupart des gens prennent ça trop passionnément, de toute façon.

L'hypothèse d'un monde juste

Beaucoup des détracteurs de systemd vont s'exprimer au sujet d'une supposée prise de contrôle sur l'écosystème de Linux de la part de systemd, dans la mesure où ses auxiliaires (nécessitant tous d'être pilotés par l'init de systemd) exposent des APIs qui sont ensuite utilisées par d'autres logiciels de la pile bureautique, créant ainsi des liens de dépendance entre ceux-ci et systemd que les détracteurs jugent injustifiés. Ils vont aussi pointer du doigt la débâcle d'udev et citeront Lennart à l'occasion. Les détracteurs voient ça comme un comportement anti-compétitif et le compare à une pratique de type « adopter, étendre, étouffer ». Ils exagèrent souvent cependant et se laissent complètement emporter par leur vitriol à mesure qu'ils commencent sérieusement à envisager d'obscures conspirations chez Red Hat (il faut admettre que c'est plutôt drôle de prétendre que quiconque défend un logiciel est un homme de paille travaillant secrètement dessus, mais je digresse), laissant beaucoup de leurs sujets de préoccupation être ignorés et jugés ridicules par la même.

La modération est rarement de mise. La plupart des zélateurs essaient de convaincre en niant carrément toute interférence politique et en insistant sur le fait que systemd est adopté sur la seule base de ses qualités techniques et qu'un aussi large consensus parmi les distributions étant impossible à fabriquer, il doit y avoir derrière des raisons techniques valables qui montrent clairement la supériorité de systemd.

Aucun de ces points de vue n'est la stricte vérité. Il est très probable qu'il n'y a pas de conspiration de la part de Red Hat s'enracinant dans les bureaucraties de toutes les distributions (aussi amusant que cela sonne), mais dire que l'adoption de systemd est purement technique et pas du tout politique est également faux. Cela est particulièrement évident du fait qu'à peu près toutes les distributions (surtout Debian, cependant) ont une structure de gouvernement élaborée. Les décisions techniques et politiques s'entrecroisent très fréquemment (demandez juste à Microsoft ou à Oracle), et les logiciels libres ne sont pas nécessairement immunisés contre cela.

De plus, la communauté Linux est connue pour réinventer la roue carrée encore et plus encore. Le chaos est en même temps la plus grande force et la plus grande faiblesse de Linux. Vous vous souvenez de HAL ? L'adoption par les distros n'est pas tant l'indice que quelque chose est bon que du fait qu'il a suffisamment de publicité.

Cela dit, ce qui se passe n'est pas que les gens nient que des interférences politiques se produisent en matière de logiciel, mais plutôt qu'ils nient que cela arrive dans leur camp. Les détracteurs s'en rendent également coupables (comme lorsque Ian Jackson réouvre la résolution Debian sur systemd, ce qui était par nature brûlant, quelles qu'aient été ses intentions), même s'ils ne sont pas aussi influents.

S'attendre à ce que les débats autour de systemd n'impliquent rien de politique, en tant que tel, est plutôt auto-contradictoire. systemd est déjà le sujet le plus chargé politiquement dans l'histoire du logiciel libre, et ce n'est pas si arbitraire. Néanmoins, les deux côtés sont regrettablement obtus et nous analyserons plus tard leurs milieux types, pour comprendre pourquoi.

Portabilité

La portabilité des systèmes d'init est rare, principalement parce que les phases 1 (immédiatement après le lancement d'init(8) par le noyau) et 3 (extinction) sont intrinsèquement spécifiques au système. Ceci est également la cause pour laquelle il y a une forte prégnance philosophique dans la conception des inits, même si ce n'est que rarement exposé aussi explicitement.

Les zélateurs soutiennent avec raison que la non-portabilité de systemd est quelque chose de courant et que ce n'est pas un bon argument contre lui, mais les détracteurs mettent généralement en évidence les décisions politiques et la ramification des dépendances, en soutenant que systemd n'a pas besoin d'être un init et devrait juste être un superviseur de processus tournant au-dessus d'un init existant. Il y a des arguments à donner en faveur des deux options, même si l'architecture de systemd tend en général à en faire un init. Il fournit une plus grande sécurité contre les erreurs critiques au prix d'une surface plus large, contrairement à l'approche des daemontools où vous avez une séparation stricte entre la gestion du système et la gestion des services.

Pour autant que l'argument de la portabilité soit normalement un sophisme, l'exposition des APIs de systemd à l'usage d'autres paquets lui donne une pertinence. Bien sûr, « l'hypothèse d'un monde juste » joue un grand rôle ici, car du fait que cet argument est intrinsèquement politique, il est en conséquence souvent directement rejeté, générant encore un surplus de situations à se cogner la tête contre le mur (« Ce que nous avons ici est… une incapacité, à communiquer. Certains hommes, vous ne pouvez simplement pas les atteindre. » ) durant les débats.

C'est une question de choix

Généralement, un fier utilisateur de Gentoo, qui saisit l'importance de dérouler toutes les boucles lors de la compilation d'un paquet, va se lever et proclamer « Linux est une question de choix ! systemd s'immisce dans tous mes logiciels et confisque ma liberté de choix ! »

Il sera la plupart du temps immédiatement réfuté par quelqu'un l'envoyant sur islinuxaboutchoice.com, et allant même parfois jusqu'à lui expliquer pourquoi, en fait, le choix est une mauvaise chose et conduit au malheur. Si seulement nous avions tous voté pour le même parti politique, le monde serait meilleur.

Excusez les caricatures, mais le fond de tout cela est que ces deux approches sont fausses et ne conduisent nulle-part. Les zélateurs ont bon en ce que Linux n'est pas intrinsèquement une question de choix, mais ils ne parviennent également souvent pas à réaliser que la tradition Linux consistant à construire des systèmes en mélangeant et en ajustant des composants ouverts (du fait que Linux est seulement un noyau) a en fait joué un grand rôle dans la formation de sa culture, et est sans doute une raison pour laquelle beaucoup d'entreprises basent leurs infrastructures sur Linux, quand bien même il est couvert par une licence plus restrictive comparé aux BSDs.

Dans les faits, rien de cela n'a à voir avec le choix. Ce qu'on cherche réellement à dire est « ça casse les procédures de travail ».

Du cyanure dans la sémantique, ou la manipulation du langage

Il apparaît que beaucoup de gens ne savent même pas ce qu'est systemd. Je développe uselessd, et je ne sais pas non plus — sérieusement. Tout du moins, je ne peux penser à aucune explication concise qui décrirait proprement le champ d'application de systemd.

Lorsqu'ils se lamentent à propos de toutes les critiques (entendre : la haine sans limite) à propos de systemd, les zélateurs vont souvent demander « Pourquoi tant de gens se soucient-ils de l'init de leur système ? Je m'en moque, du moment que ça marche ! »

Les détracteurs feront alors entendre leurs préoccupations en disant quelque chose dans la veine de « Je n'aime pas la manière dont systemd gère tant de choses, telles que la connexion, les conteneurs, la locale, les comptes, les points de montage et d'auto-montage… »

Arrivé à ce point, une autre personne va crier « Mais systemd n'est pas qu'un système d'init, c'est un ensemble de démons et de services pour un système d'exploitation basé sur Linux ! »

En fait, nous verrons systemd compris tour à tour comme étant :

un démon init ;
un système d'init ;
un gestionnaire de processus ;
un gestionnaire de services ;
une brique de base de l'espace utilisateur avec laquelle bâtir un système d'exploitation ;
un réseau de dépendances entre objets pouvant être propagées, combiné à un puissant moteur d'exécution ;
etc.

Habituellement, quand ses zélateurs essaieront de défendre systemd, ils vont insister sur le fait que c'est « juste un système d'init », mais quand ils seront contredits ils mentionneront à la place une des définitions plus larges.

Toutes les définitions ci-dessus sont techniquement correctes. Aucune d'entre elles n'est complète.

C'est ainsi que les débats sont condamnés à ne mener nulle part, dans la mesure où personne ne peut s'entendre sur une unique définition de systemd, et les développeurs n'ont aidé vraiment en rien en la matière. Être vague peut être une force, en ce que cela permet aux gens de diviser pour régner, mais c'est également improductif et conduit à des carnages inutiles. En sus, être vague donne carte blanche pour balayer les réserves et consolider les fonctionnalités, tout en entraînant aussi beaucoup d'ignorance chez les détracteurs comme chez les zélateurs.

Les temps de démarrage en toute justice

Les détracteurs de systemd partent fréquemment du principe que la seule raison pour laquelle les gens l'aiment tient dans ses temps de démarrage plus courts. C'est faux, même si le fait que ses fans vantent beaucoup cet aspect n'aide certainement pas, et ce bien que les développeurs de systemd eux-mêmes découragent l'utilisation de cet argument, insistant à la place sur la « bonne conception » à laquelle cela est dû (et ainsi le cycle des guerres ouvertes se poursuit).

Les développeurs reconnaissent que les temps de démarrages ne sont par défaut pas aussi fulgurants qu'ils pourraient l'être, et avec les années la plupart des distros Linux ont accumulé beaucoup d'expédients comme insserv et startpar, qui ont amélioré les performances de SysV en accélérant son exécution sérielle par des expédients de parallèlisation passant par le démarrage des services en tâches de fond.

La philosophie Unix

La philosophie Unix est elle-même un gigantesque champ de bataille. Elle est remarquablement chargée d'un point de vue politique. Beaucoup de gens seront d'accord avec une grande partie de ses principes si vous les présentez individuellement, et de fait une partie d'entre eux est devenu synonyme de « bonne conception », mais si vous les mentionnez derrière le paravent « philosophie Unix », les ennuis vont commencer.

La plupart des détracteurs de systemd essaient de convaincre en hurlant aveuglément « Phylozofie Hunixe » comme si cela signifiait quoi que ce soit sans élaborer un peu le sujet, mais beaucoup de zélateurs sont par ailleurs inhabituellement hostiles à son égard et la mécomprennent eux aussi. Une réfutation habituelle comme « Linux n'est pas Unix » est correcte uniquement du point de vue de la licence en ce que, en effet, Linux n'est pas une licence d'Unix. Cela n'invalide pas le fait que son architecture a intrinsèquement à voir avec celle d'un Unix.

Un courriel de réponse de la part de Lennart Poettering, que nous avons reçu à la suite d'une enquête de l'un des membres de notre forum, disait ce qui suit :

« Tout cela étant dit, je suis presque sûr que systemd amène Linux beaucoup plus près d’UNIX que Linux ne l’a jamais été. Tous les vrais UNIX actuels (comme FreeBSD, Solaris…) sont maintenus dans un lieu centralisé, en partageant l’infrastructure des dépôts de code, les cycles de vie et les schèmes de publication pour tous leurs composants, peu importe que ce soit le noyau, la libc, ou le reste de l’espace utilisateur. Sur les vrais UNIX, il est beaucoup plus facile de patcher le long de la pile entière depuis le noyau à jusqu’à l’espace utilisateur, parce que tout provient de la même source, et suit les mêmes cycles. Les vrais UNIX ont tendance à paraître plus uniformes car les mêmes gens travaillent sur toute la pile, les choses sont faites d’une même main. Linux a toujours été différent, nos composants sont maintenus indépendamment, dans des dépôts différents, avec des styles de code différents, par des gens différents, suivant des cycles de publication différents. Ils sont maintenus plus ou moins bien, une bonne partie de notre pile est en réalité traditionnellement très mal maintenue, voire pas du tout.

Avec systemd nous essayons de trouver une sorte d’entre-deux, aller vers un schème plus proche d’UNIX sans tout coller dans le même dépôt comme le fait UNIX, mais seulement les éléments essentiels de l’espace utilisateur. Mais même au-delà des éléments de procédure, il y a beaucoup de domaines où systemd est plus proche des UNIX traditionnels que Linux ne l’a été. Par exemple, un des mantras d’UNIX est “tout est fichier” (ce qui, au passage, est plutôt faux, car mon imprimante n’est pas un fichier, pas du tout), et on pourrait dire que systemd donne à voir l’un des concepts les plus fondamentaux d’un système UNIX, à savoir les services/démons en tant que fichiers via la logique des cgroups. Donc ouais, si vous prétendez que nous ne somme pas UNIX, je vous dirais que nous sommes en réalité sous bien des aspects beaucoup plus proches d’UNIX que nous ne l’avons jamais été.

Je suis presque sûr que la plupart des gens qui répètent constamment comme des perroquets que systemd n’est pas proche d’UNIX n’ont en réalité aucune idée de ce qu’est vraiment UNIX… »

Apparemment, ce que Lennart a retenu d'Unix est qu'il est « développé au sein d'un unique dépôt » (bien que cela n'ait jamais été un pré-requis strict, c'est juste que les noyaux individuels des systèmes d'exploitation n'ont auparavant jamais vraiment décollé à la manière de Linux) et que systemd est plus unixifié que n'importe quoi avant lui parce qu'il utilise les cgroups… même si on doit la conception de cgroupsfs aux développeurs du noyau et pas à systemd (à eux et au système de fichiers à contrats de Solaris, qui a probablement été une source d'inspiration majeure pour les cgroups). De plus, il nous éclaire sur le fait que son imprimante n'est pas un fichier. À l'évidence, Lennart n'a jamais entendu parler de 9P (NdT : Plan 9 Filesystem Protocol), qui est un exemple de protocole simple ayant été mis en application avec succès pour exposer à peu près tous les ressources et services du système en tant que systèmes de fichiers virtuels, les rendant pilotables avec les appels système les plus basiques manipulant les descripteurs de fichiers.

Écrire une alternative

Après beaucoup d'arguties quelqu'un va tout simplement finir par lâcher que si les détracteurs n'aiment pas systemd, ils devraient lui écrire une alternative.

Bien entendu, au minimum plus au moins une douzaine de celles‐ci existent déjà. Que signifie en réalité « écrire une alternative » ?

systemd est vraiment au sein de l'espace utilisateur la couche intermédiaire qui prend place entre GNU et Linux. J'ai aussi entendu systemd comparé aux serveurs d'un micro-noyau, d'une manière très proche du Hurd. Cela a en fait plus de sens qu'il n'y paraît au premier regard, et avec les anciens composants du noyau comme la console Linux qui sont en train d'être déportés vers l'espace utilisateur (d'abord en tant que kmscon, puis en tant que systemd-consoled — ce qui n'implique pas que ce soit mauvais, au passage), cela donne quelque crédit à l'idée. Les composants de systemd implémentent souvent d'anciens outils indépendants en tant que démons auxiliaires, programmables.

En tant que tel, pour que quelqu'un écrive une alternative à systemd, un second systemd doit pour l'essentiel être écrit.

Ceci est déjà un dilemme insoluble, car c'est précisément ce que les détracteurs ne veulent pas. Beaucoup des anti-systemd techniquement compétents souscrivent à des philosophies entièrement différentes, comme l'approche des daemontools ou autre chose.

Plus encore, beaucoup ignorent qu’écrire un second systemd serait un risque énorme. Faire de la programmation système de bas niveau et de la plomberie en espace utilisateur n’est pas comme programmer des applications pour l’utilisateur final. Un superviseur de processus et un traitement de texte sont complètement différents. Le dernier peut-être remplacé très facilement s’il ne convient pas, le premier requiert une intégration et a des ramifications fondamentales dans la manière dont on interagit avec un système d’exploitation donné. La tâche n’est pas aisée et risque fort d’être entièrement vaine. Beaucoup de gens coderaient plus volontiers des projets personnels plutôt que faire l’effort d’écrire de tels systèmes qu’ils pensent être largement compensés par des outils séparés et discrets (sans doute en ont‐ils écrit certains).

De ce ce point de vue, l'argument « implémenter une alternative » conduit seulement à empoisonner les débats avec l'assomption implicite que la philosophie de systemd est bonne, rendant ainsi les choses encore largement plus politiques.

sysvinit : l'éternelle muleta

Il semble que par une sorte de destinée divine, tout débat autour de systemd se mue en dispute stérile autour des avantages de systemd sur sysvinit. Les zélateurs vont joyeusement parler des fonctionnalités géniales de systemd qui ont remplacé la base des affreux scripts shell, alors que les détracteurs vont proclamer la supériorité de sysvinit dûe à son minimalisme et à sa flexibilité infinie du fait qu'il délègue les services à un langage de commande interprété et Turing-complet.

Tous ont faux et manquent totalement l'essentiel.

Le constat que SysVinit est idiot et défectueux avec ses abstractions vieillotes comme son inittab et ses niveaux d’exécution n’est absolument pas nouveau. Richard Gooch a écrit un article dès 2002 intitulé Les scripts de démarrage Linux, qui critiquait les approches de SysV et de BSD, en se basant sur son précédent travail sur simpleinit(8). Cela dit, sa solution restait fermement ancrée dans les philosophies de SysV et de BSD, mais il rendait ça plus élégant en fournissant des bases de modularité et en exprimant les dépendances.

Même avant cela, DJB (N. D. T. : Daniel J. Bernstein) a écrit la fameuse suite des daemontools, qui a eu beaucoup de successeurs influencés par son approche, notamment s6, perp, runit et daemontools-encore. Les deux premiers sont des implémentations complètement indépendantes mais basées sur des principes similaires, avec, il est vrai, des améliorations significatives. Un article daté de 2007, intitulé Les scripts d’init considérés comme néfastes, encourage cette approche et critique les scripts d’init.

Aux alentours de 2002, Richard Lightman a écrit depinit(8), qui a introduit le démarrage parallèle des services, un système de dépendances baptisé « groupes de services » au lieu de « niveaux d'exécution » (similaires aux « cibles » de systemd), sa propre logique de démontage des périphériques à l'extinction, des redirections arbitraires entre démons à des fins de journalisation, et plus encore. Il n'a pas réussi à se populariser et c'est maintenant une relique historique.

D'autres systèmes comme initng et eINIT sont venus après cela, lesquels étaient basés sur des architectures hautement modulaires à base de plugins, et implémentaient une grosse partie de leur logique en tant que plugins, pour une large palette d'actions que des logiciels comme systemd implémentent comme parties inamovibles de leurs socles. Quelqu'un pour parler d'Initmacs ?

Même Fefe, activiste anti-bloat phénoménal a écrit auparavant son propre système appelé minit, qui pouvait gérer les dépendances et le démarrage automatique. Comme d'habitude avec les logiciels de Fefe, c'est très douloureux à lire, vous donnant envie de vous faire seppuku avec une roulette à pizza.

Et tout ça juste pour Linux. Une liste partielle, évidemment.

En tout et pour tout, la comparaison avec sysvinit ne fait que montrer que vous avez vécu dans une grotte pendant des années. Qui plus est, il n'est un secret pour personne que la manière dont les distros ont pendant des années rédigé les scripts d'init a été une hérésie vis à vis des pratiques de base du développement, comme la modularisation et la réutilisation des fonctions communes. Cela parmi d'autres problèmes tels l'usage inadéquat d'abstractions déjà trouées comme start-stop-daemon(8). Même si sysvinit encourage jusqu'à un certain point un mauvais travail comme celui-là, ce sont les mainteneurs des distros qui portent le gros de la faute pour le désordre. Regardez les BSDs pour un bon exemple d'écriture de scripts d'init. OpenRC a été directement inspiré de l'exemple des BSDs. Astuce : c'est dans le nom – « RC ».

Le champ d'application plutôt énorme de systemd et son caractère intransigeant conduisent des gens à regretter l'époque de sysvinit. Une bonne part de cela tient à leur ignorance des bons principes de conception, mais pour beaucoup c'est aussi motivé par l'inaptitude à communiquer leur désir pour des systèmes simples et transparents. De la sorte, zélateurs et détracteurs sont pris dans des boucles de rétroaction consistant à ne déboucher sans cesse nulle part en partant en guerre ouverte autour d'une implémentation d'initd (qui s'est trouvée dominante) tout en ignorant complètement toutes les recherches précédentes sur l'amélioration des inits, dans la mesure où celles-ci ont toutes été au final abandonnées au sol. Plus encore, la plupart des gens n'arrivent pas à distinguer l'init des scripts rc et tiennent en quelque sorte sysvinit pour un équivalent des pauvres scripts que les distros ont écrits, et de tous les trucs qu'elles ont bricolés par dessus comme les en-têtes LSB ou startpar(2). C'est une mécompréhension majeure qui entraîne la perte de beaucoup d'énergie.

Ne discutez pas de sysvinit. Discutez de systemd à partir de ses propres qualités et des avantages ou désavantages de sa manière de résoudre les problèmes, ce en le mettant potentiellement en contraste avec d'autres systèmes d'init. Mais ne commencez pas immédiatement avec « les scripts d'init de SysV étaient une approche meilleure et bien plus configurable, je ne vois pas ce que systemd contribue à résoudre au-delà de temps de démarrage plus courts », ou de l'autre côté « systemd est une meilleure approche que sysvinit, regardez comme les unités sont propres comparées à ce script épouvantablement écrit que j'ai glané ! Pourquoi ne changeriez-vous pas ? »

Les milieux culturels et techniques des zélateurs/détracteurs

Maintenant que nous avons mis en évidence comment les débats autour de systemd se déroulaient en pratique et pourquoi y prendre part est habituellement une colossale perte de temps, faisons un grossier survol des personnalités qui rendent ce bordel possible.

Les parties techniquement compétentes tendent largement à tomber dans ces deux larges catégories :

les zélateurs sont généralement montés dans le train du Bureau Linux moderne. Ils tournent avec les distributions dominantes contemporaines et les derniers logiciels, utilisant en y contribuant les initiatives des gros environnements de bureau et de leurs standards associés comme les *kits. Ils ne sont pas nécessairement focalisés sur le bureau Linux. Ils travaillent souvent sur des fonctionnalités destinées à la gestion des serveurs d'entreprise, à l'informatique dans les nuages, aux systèmes embarqués, et à d'autres besoins, mais la rhétorique selon laquelle on a besoin d'un meilleur bureau et qu'il faut suivre les exemples de Windows et d'OSX est largement répandue dans leurs rangs. Ils vont dénoncer ce qu'ils considèrent comme des « échecs d'intégration », de la « fragmentation », et sont généralement hostiles à l'égard des projets de recherche et de tout ce qu'ils perçoivent comme des « projets gadgets ». Ce sont des hackeurs, mais leur tournure d'esprit est largement orientée vers la réduction de la complexité des interfaces au lieu de celle des implémentations, et ils argumenteront souvent contre les prétendus dangers de trop de configurabilité, tout en regardant les ordinateurs comme des applications plutôt que des outils.
les détracteurs sortent de milieux un peu plus variés, mais viennent typiquement de distributions plus de niche comme Slackware, Gentoo, CRUX, et autres. Ils sont largement peu intéressés par les « avancées » du bureau Linux, apprécient la configuration, le minimalisme, et se soucient plus de la malléabilité que de la convivialité. Ils sont souvent familiarisés avec beaucoup d'autres environnements apparentés à Unix en plus de Linux, bien que ce dernier garde leur faveur. Ils ont leurs propres projets fétiches et sont enclins à utiliser, à contribuer, ou au moins à suivre plein de petits projets dans le domaine de la plomberie système de bas niveau. Ils peuvent aller jusqu'à nommer au moins une douzaine d'alternatives aux GNU coreutils (je peux en nommer à peu près 7, je pense), approuvent généralement les principes Unix traditionnels et regardent les ordinateurs comme des outils. Ils sont les personnes les plus enclines à avoir de la sympathie pour des choses comme la philosophie suckless.

Il ne devrait être une surprise pour personne que le premier groupe est dominant. Ce sont eux qui façonnent largement l'expérience de l'utilisateur final. Par contraste, le second groupe est plutôt insensible à cet égard, voire critique. Qui plus est, le premier groupe a beaucoup plus de ressources humaines placées aux bons endroits. 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.

Conclusion

« L'année du bureau Linux » est devenu un mème à présent, utilisé le plus souvent sarcastiquement. Cependant il demeure des gens qui y tiennent profondément et pensent que si seulement Linux avait un bon moteur d'abstraction pour les soubassements des gestionnaires de paquets, tous ces utilisateurs Windows tourneraient sous Fedora en un rien de temps.

Ce à quoi nous assistons est certainement un choc culturel entre deux pôles opposés qui coexistent dans la communauté Linux. Nous pouvons le voir en œuvre à travers le vitriol jeté sur les développeurs de Red Hat, et inversement dans la dérision envers les utilisateurs de Gentoo de la part de Lennart Poettering, Greg KH. et autres. Même s'il apparaît dans ce cas que « utilisateurs de Gentoo » est utilisé comme une métonymie pour les utilisateurs de Linux dont les besoins sortent de la palette des applications dominantes. Theo de Raadt a autrefois fielleusement ironisé sur le fait que Linux était pour « les gens qui détestent Microsoft », mais cette citation commence à présent à dater.

Beaucoup des gens les plus techniquement compétents avec des opinions critiques sur systemd sont restés plutôt silencieux en public, pour quelque raison. Probablement qu'ils réalisent que la direction prise par le Bureau Linux est inévitable et qu'en conséquence la critiquer est une entreprise futile. Il y a des gens qui pensent toujours que l'abandon de Sawfish par GNOME a été une erreur, donc oui.

Les gens qui ne se sentent pas concernés par le bureau ont encore leur propre espace, mais se sentent menacés par systemd à un degré ou à un autre. Reste que, personnellement, je ne vois pas leur nombre décroître. Ce que je crois qu’il va se passer, c’est qu’ils vont devenir encore plus ségrégués qu’ils ne le sont déjà par le Linux dominant et qu’utiliser leurs logiciels va avoir l’air de plus en plus décalé à mesure que le temps passera.

Beaucoup prédisent une grande renaissance de BSD dans le sillage de systemd, mais je suis sceptique à ce sujet. Il y aura sans doute un gain d'intérêt, mais au total il semble que la majorité de la population anti-systemd s'investit encore profondément à rester sous Linux.

En tout dernier lieu, la cruelle ironie est que systemd, dans sa tentative de supposément unifier les distributions, a créé comme aucun autre un immense fossé et a exacerbé à des degrés absolument anormaux les hostilités latentes entre le camp du bureau Linux et celui du Linux minimaliste. Ce qui va advenir de systemd demeure inconnu. Étant donné l'inclination de Linux au chaos, il pourrait devenir le nouveau HAL, avec cependant des conséquences significativement plus pénibles, ou il pourrait poursuivre son gai bonhomme de chemin et devenir un standard Linux gravé dans la pierre, auquel cas la communauté Linux connaîtra une division idéologique intense. Ou peut-être pas. Peut-être que les choses vont continuer comme d'habitude suivant une spirale infinie de réinventions sans climax. Peut-être serons-nous condamnés à nous déchirer sur systemd pour toute l'éternité. Peut-être finalement nous en dégoûterons-nous et poursuivrons-nous nos propres chemins dans des directions différentes.

En tous les cas, je deviens de moins en moins adepte de politique concernant uselessd et je vois métaphoriquement les débats autour de systemd comme les accidents de voiture. Je n'y apporte probablement rien mais j'y participe de temps en temps, bien que je destine uselessd à tracer son propre chemin avec le temps.

Redistribution and use in source (SGML DocBook) and 'compiled' forms (SGML, HTML, PDF, PostScript, RTF and so forth) with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code (SGML DocBook) must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified.
1. Redistributions in compiled form (transformed to other DTDs, converted to PDF, PostScript, RTF and other formats) must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

THIS DOCUMENTATION IS PROVIDED BY THE AUTHOR "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Aller plus loin

Journal à l'origine de la dépêche (327 clics)
Article originel (253 clics)

# Hmm

Posté par haleth le 30 novembre 2014 à 12:57. Évalué à -10.

Mouais, y'a aussi des vrais arguments.

Prenons un exemple (et oui, je compare systemd à sysvinit, puisque je compare le nouveau avec l'existant).

Comment debug un daemon ?
- systemd: SYSTEMD_LOG_LEVEL ? Est-ce suffisant et exhaustif ?
- sysvinit : bash -x /etc/init.d/blabla start

Un script bash est plus facile à debug qu'un binaire, de même que n'importe quel langage de script, au fait : il est plus simple d'y debug des erreurs de programmation

Bon, je passe sur le fait qu'il est tout à fait possible d'utiliser des binaires avec sysvinit .. qu'importe.

Je concluerai sur deux points :
- utiliser un truc en dev pour de la prod est typiquement une mauvaise idée.
- je me fiche de savoir que systemd fait des trucs "cool" quand il fonctionne. Ce qui m'intéresse, c'est ce qu'il se passe lorsqu'il ne fonctionne pas. Penser qu'un système fonctionne toujours est un échec intellectuel : les bons systèmes sont les résiliants aux pannes
- [^] # Re: Hmm
  
  Posté par Sacha Trémoureux (site web personnel) le 30 novembre 2014 à 13:17. Évalué à 10.
  
  On a une dépêche qui tente de prendre de la hauteur sur les débats pour/contre et toi tu trouves rien de mieux que de replonger dans le bassin…
  - [^] # Re: Hmm
    
    Posté par haleth le 30 novembre 2014 à 13:19. Évalué à -10.
    
    Je clame mon désaccord avec certains points de ce papier;
    
    Et oui, j'adore me baigner dans la fange;
- [^] # Re: Hmm
  
  Posté par Misc (site web personnel) le 30 novembre 2014 à 15:37. Évalué à 10.
  
  Comment debug un daemon ?
  
  Alors si tu lances bash -x /etc/init.d/blabla start , c'est pas le daemon que tu examine, mais son script d'init. Le daemon va pas forcement t'afficher grand chose en plus par magie. Et faire ça va avoir des effets de bords comme importer l'environnement de root dans celui du daemon, en fonction du script, ce qui va perturber le debuggage.
  
  utiliser un truc en dev pour de la prod est typiquement une
  mauvaise idée.
  
  Systemd a maintenant 4 ans. Y a une branche stable v208 qui est largement stabilisé depuis longtemps. Tu peux me dire quel soft n'est pas en dev dans le libre ?
  
  Et c'est pas aussi à ça que sert le freeze de Debian, à trouver les bugs pour avoir un logiciel utilisable en prod ?
  
  Ce qui m'intéresse, c'est ce qu'il se passe lorsqu'il ne
  fonctionne pas.
  
  Il rajoute un message d'erreur dans les logs, comme à peut prêt tout les logiciels du monde. Et il y a assez de résultats sur "debug systemd" pour que la doc ne soit pas un souci. Est ce que tu peux détailler par exemple ce qui t'a manqué quand tu as eu un souci, à part le temps de lire avant ( chose que tu peux faire dès maintenant au lieu de poster sur linuxfr, par exemple )
  - [^] # Re: Hmm
    
    Posté par feth le 30 novembre 2014 à 22:09. Évalué à 1.
    
    Tu peux me dire quel soft n'est pas en dev dans le libre ?
    
    $\TeX$ ?
    
    (en fait non : Stable release 3.14159265 / January 2014)
- [^] # Re: Hmm
  
  Posté par Sébastien Douche le 30 novembre 2014 à 17:55. Évalué à 10.
  
  Comment debug un daemon ?
  - systemd: SYSTEMD_LOG_LEVEL ? Est-ce suffisant et exhaustif ?
  - sysvinit : bash -x /etc/init.d/blabla start
  
  Marrant cette remarque car quand un service ne se lance pas, la 1ere chose que je fais (si je ne vois rien de concret dans les logs) est de farfouiller dans les dizaines de lignes de shell pour sortir la ligne d'appel effective et de lancer moi même la commande pour avoir la sortie std / err : J'ai encore en mémoire un debug de lancement foireux de PostgreSQL, qui était un script shell qui appelle un script shell qui appelle un script Perl (simplicité Debian), ce dernier ayant un bug sur la transmission des options se trouvant dans le fichier de configuration.
  
  Si je ne suis pas spécialement pro-Systemd, mais il a au moins le mérite de remettre sur la table des points douloureux que personne ne voulait régler. Que des gens veulent fonctionner à l'ancienne est compréhensible (pour plein de raisons, bonnes ou mauvaises), mais perso je ne peux plus voir en peinture cet amas de shell.
# Fonctionnalités clées.

Posté par Enj0lras le 30 novembre 2014 à 13:05. Évalué à 7. Dernière modification le 30 novembre 2014 à 13:09.

J'admets ne plus avoir suivi les débats sur systemd depuis au moins 1an et ne l'utiliser que très rarement. Mais cette dépêche est intéressante, je trouve notament le paragraphe sur la modularité très juste. Je dis souvent que la modularité n'a rien à voir avec la séparation en processus. La modularité c'est la séparations en "modules" de codes ayant un rôle particulier qui fonctionnent chacun avec des dépendances minimales et possédant des API stables et documentées, ainsi que, c'est mieux, un système de build permettant de compiler les briques séparéments. Je pense que c'est selon cette définition qu'on accuse souvent systemd d'être monolithique.

Pour revenir au sujet de ce commentaire, certaines personnes réfléchissent à ce que d'autres systemes d'inits, comme le vieux init BSD, peuvent apprendre de systemd. Non pas techniquement, mais sur le plan des fonctionnalités. Ainsi, ayant plutôt tendance à voir la partie négative des choses j'aimerais poser la question suivante :

Qu'est ce que selon vous systemd a apporté à votre expérience utilisateur ?
- [^] # Re: Fonctionnalités clées.
  
  Posté par Zenitram (site web personnel) le 30 novembre 2014 à 13:20. Évalué à -10. Dernière modification le 30 novembre 2014 à 13:23.
  
  Qu'est ce que selon vous systemd a apporté à votre expérience utilisateur ?
  
  La façon de poser la question montre déjà le biais : tu veux que ça te/nous apporte quelque chose. En "oubliant" que ça peut apporter des choses à d'autres (par exemple aux mainteneurs de ta distro, mainteneurs que tu ne rémunères pas).
  Sérieux, est-ce que je demande si KDE apporte quelque chose à l'expérience utilisateur des utilisateurs de Gnome?
  
  La question devrait plutôt être : en quoi systemd vous a négativement impacté, et est-ce assez pour que vous vous bougiez le cul à maintenir vous-même ou payer une équipe de maintenance pour ce que les mainteneurs de votre distro ne veulent plus maintenir gratuitement pour vous?
  Et oui, la question est plus personnelle, et sous-entendant un engagement de votre part plutôt que de cracher sur les mainteneurs de votre distro (ce sont eux qui ont choisi, pas Lennart, c'est donc sur eux que vous crachez indirectement)…
  
  Le problème est montré dès la façon de parler : impossible de cohabiter, impossible de dire que les "salauds qui imposent systemd" sont ceux qui se font chier à vous maintenir une distro, il faut absolument que ça apporte quelque chose de personnel rien à foutre que ça apporte quelque choseà d'autres en mutualisant (égoïsme : pas d'acceptation d'un petit dérangement pour que les autres aient une utilisation différente sur une base commune) etc…
  
  vivre ensemble au petit prix d'accepter quelques dérangements (pire : pour 99% des gens, en pratique, c'est transparent), c'est trop demander, triste.
  - [^] # Re: Fonctionnalités clées.
    
    Posté par Enj0lras le 30 novembre 2014 à 13:29. Évalué à 10.
    
    Je vois que le vivre ensemble c'est pas ton fort. Je pose une question dont la réponse m'intéresse et je me fais agresser. Je m'intéresse aux fonctionnalités intéressantes pour un utilisateur, un point c'est tout. J'ai pas envie de rentrer dans ton troll ou dans un grand débat sur la vie l'univers et le reste.
  - [^] # Re: Fonctionnalités clées.
    
    Posté par karteum59 le 01 décembre 2014 à 02:28. Évalué à 10. Dernière modification le 01 décembre 2014 à 02:32.
    
    en quoi systemd vous a négativement impacté
    
    En divisant la communauté, en méprisant tout ce qui s'écarte de sa cible immédiate (Linux+GLibc), le projet a introduit une ambiance assez malsaine alors que ça aurait pu être plus consensuel et progressif (une première étape "à la uselessd" ou "à la Pardus". Je pense que beaucoup de monde s'accordait à dire que sysvinit était très imparfait. L'approche Pardus était fort sympathique AMHA : garder init car ce n'était pas le composant qui posait problème, mais refondre l'infrastructure de scripts rc derrière… Certaines expérimentations chez IBM étaient sympathiques aussi).
    
    Créer des dépendances fortes entre composants est selon moi préjudiciable sur le long terme. Le souci de portabilité ne concerne pas que les BSD => un exemple qui m'agace : musl-libc semble très prometteuse, et certaines distributions comme Alpine l'ont déjà adopté. Mais systemd ne marche qu'avec la glibc et Lennard a clairement dit qu'il refusait de résoudre le problème ("we will rely on good APIs exposed in the generally accepted Linux API which is the one glibc exposes". Dit autrement: l'API de référence est pour lui la glibc avec toutes ses extensions et GNUisms et non juste POSIX, les autres libc n'ont qu'à réimplémenter le bloat…). Or pour autre chose que de l'embarqué (au hasard, pour une machine desktop avec Gnome), les dépendances élargies du type Gnome->systemd->glibc compliquent le passage à autre chose que systemd et par voie de conséquence empêchent durablement toute distro majeure de proposer autre chose que la glibc. La compatibilité avec musl et uclibc est pour moi un argument majeur pour toutes les alternatives à systemd — notamment uselessd !
    - [^] # Re: Fonctionnalités clées.
      
      Posté par Zenitram (site web personnel) le 01 décembre 2014 à 07:47. Évalué à -9. Dernière modification le 01 décembre 2014 à 07:52.
      
      La bonne excuse pour justifier le conservatisme : cet "impact" permet de tout figer, jamais tu ne peux modifier un seul truc, tu auras toujorus un râleur qui te parlera de division comme tu le fais.
      C'est d'ailleurs rigolo d'accuser de diviser quand justement elle a unifié quasi toutes les distros.
      
      Bref, super, le côté négatif est "ça change mes habitudes de vieux", bizarrement on peut l'appliquer à Gnome (ces salauds on fait de la division, KDE existait déjà), les xBSD (ces salauds ont divisé plusieurs fois pour des broutilles), LibreOffice (bizarre hein que cette division pas vieille n'ai pas été critiqué de la même manière…) mais il faut l'utiliser que pour systemd qui a unifié, lui (KDE est toujours la, les BSD aussi, OpenOffice aussi, tandis que toutes les distros majeures sont passées à systemd).
      
      Mais bon, tant que tu y crois que c'est la faute à systemd cette "division" (qui unifie, à par les trolls) et que systemd n'est pas qu'une excuse (""Devuan developers look at this project as a fresh new start for a community of interested people and do not intend to enforce the vexation hierarchy and bureaucracy beyond real cases of emergency", ça fait très attaque contre systemd… Ou contre autre chose, par hasard la division c'est "chez Debian ils puent profitons de ces couillons d'anti-systemd pour diviser et tirer la couverture vers nous" plutôt non?)
      
      Le tout, c'est d'y croire. Mais ça reste triste que des gens gobent cette histoire de division pour un des projets Linux qui a le plus unifié.
      
      par voie de conséquence empêchent durablement toute distro majeure de proposer autre chose que la glibc
      
      Non, ils peuvent implémenter l'interface si ils veulent utiliser systemd, que ça te plaise ou pas. Et personne ne les force à utiliser systemd, que ça te plaise ou pas. Saloperie de liberté, ou des mainteneurs choisissent la meilleure solution de leur point de vue mais elle ne te plait pas donc tu craches sur systemd mais pas les mainteneurs qui ont choisi… Ha oui, pardon, il faut que les autres se fassent chier à réimplémenter dans systemd les trucs, et comme ça on pourra se faire plaisir à dire qu'ils implémentent carrément encore x (pratique les accusations de ce type, dans tous les cas l'autre perd, on trouve toujorus une critique)
      
      La liberté, que de la liberté : systemd n'a rien d'obligatoire, mais ça c'est "oublié" par ceux qui parlent de division mais "oublient" de bosser (beaucoup d'annonces, et… rien d'autre pour le moment, 3 ans que ça dure) pour que tout cohabite…
      
      Au fait, on attend toujours des nouvelles de tous les forks de Gnome "c'est horrible ça dépend de systemd" (ce qui est faux, ça dépend d'une API qu'on peut réimplementer, et ça a été fait, mais bon la vérité on s'en fout un peu…) depuis le temps des annonces.
      - [^] # Re: Fonctionnalités clées.
        
        Posté par Moonz le 01 décembre 2014 à 10:36. Évalué à 8.
        
        La bonne excuse pour justifier le conservatisme : cet "impact" permet de tout figer, jamais tu ne peux modifier un seul truc, tu auras toujorus un râleur qui te parlera de division comme tu le fais.
        
        C’est stupide. Si la raison c’était le « conservatisme » on aurait observé les mêmes levées de bouclier sur d’autres changements passés (udev, hal, upstart) et à venir (wayland, llvm). Or ce n’es pas le cas. Donc ton explication est foireuse.
        
        Mais bon, comme tu le dis si bien :
        
        Le tout, c'est d'y croire
      - [^] # Re: Fonctionnalités clées.
        
        Posté par karteum59 le 01 décembre 2014 à 12:29. Évalué à 4. Dernière modification le 01 décembre 2014 à 12:31.
        
        @zenitram: Je crois que tu n'as pas lu mon commentaire (ou que tu mets les gens dans des cases…)
        Je n'ai dit nulle part qu'il fallait rester sur sysvinit et que "c'était mieux avant" (il y avait clairement des problèmes à résoudre). J'ai simplement dit que j'étais agacé par une attitude qui consiste à mépriser tout ce qui sort de la cible de Lennard (tu utilises *BSD, tu utilises musl: démerde toi ! Note qu'on reproche la même chose aux éditeurs de logiciels lorsqu'ils nous opposent la PdM de Linux pour justifier la non-existence de drivers potables…) et je pense que le gros du problème aurait pu être résolu en restant davantage consensuel ("à la uselessd", comme je disais). Mais Lennard semble avoir une personnalité un peu à la Ulrich Drepper…
        Moi ce que j'observe, c'est que mes distros basées sur Musl (et les BSD) ont de moins en moins de chances de pouvoir intégrer Gnome… (et non: musl n'a pas vocation à intégrer tous les GNUisms et les bloats de la glibc, tout comme les *BSD). Encore une fois: personne n'a demandé à Lennard de faire lui-même le boulot de portabilité (lennard code ce qu'il souhaite. Il a le droit de ne pas s'intéresser aux BSD ou à musl). Mais par contre il a clairement une responsabilité en refusant les patches qui lui sont envoyés pour permettre cette portabilité !
        
        systemd n'a rien d'obligatoire
        
        Précisément si, de plus en plus à mesure que des dépendances fortes se créent. C'est bien là le problème…
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par Zenitram (site web personnel) le 01 décembre 2014 à 12:40. Évalué à -9.
        
        systemd n'a rien d'obligatoire
        
        Précisément si, de plus en plus à mesure que des dépendances fortes se créent. C'est bien là le problème…
        
        C'est du libre. Lennart n'a aucun pouvoir. Ni sur Debian, ni sur Gnome (la "raison" classique de la haine)
        Les dépendances sont la faute des maiteneurs de ta distro. des developpeurs des tes logiciels.
        Le problème est la parce qu'on veut qu'il soit la…
        Saloperie de liberté, où les gens sont libres de choisir une techno.
        
        @zenitram: Je crois que tu n'as pas lu mon commentaire
        
        Idem : tu "oublies" la partie où on voit que systemd n'est qu'une excuse à un différent : ce qui pose problème est le côté démocratique de Debian, et des gens refusent simplement cette démocratie (autant que la méritocratie : bouge les fesses pour proposer un code qui va bien sans systemd).
        
        Liberté des uns != obligation des uns de faire le boulot à ta place.
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par karteum59 le 01 décembre 2014 à 19:19. Évalué à 1.
        
        Lennart n'a aucun pouvoir
        
        Bah si, Lennard a le pouvoir de refuser les patches qui visent à rendre systemd compatible avec musl…
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par Misc (site web personnel) le 02 décembre 2014 à 02:11. Évalué à 6.
        
        Il t’empêche pas de l'appliquer sur ton build.
        
        Ceci dit, dans le cas de musl, c'est simplement que systemd utilise du code de la glibc, et les gens de musl veulent pas rajouter le code dans leur libc ( pour rester minimaliste ) , et les gens de systemd veulent pas dupliquer le code de la glibc dans leur projet ( car la copie de code, c'est mal ).
        
        Je comprends le point de vue des 2, mais dans une optique de factorisation du code, je donnerais raison aux gens de systemd. Une solution serait peut être de faire un 3eme projet "compat-libc" qui rajoute les fonctions que musl refuse d'ajouter, quitte à linker différemment.
        
        Mais bon, les gens préfèrent troller plutôt que de faire du code.
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par karteum59 le 02 décembre 2014 à 13:59. Évalué à 0.
        
        Une solution serait peut être de faire un 3eme projet "compat-libc"
        
        Soit, mais ça signifie un effort très significatif pour répliquer la totalité des extensions non-standard de la glibc (au lieu de n'implémenter que les fonctions utilisés par systemd)
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par Jean-Philippe Garcia Ballester (site web personnel) le 02 décembre 2014 à 15:39. Évalué à 5.
        
        Rien ne t'empêche d'écrire une bibliothèque avec juste les fonctions utilisées par systemd et de patcher systemd pour se lier à ta bibliothèque.
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par gnumdk (site web personnel) le 01 décembre 2014 à 12:41. Évalué à 3.
        
        Précisément si, de plus en plus à mesure que des dépendances fortes se créent. C'est bien là le
        problème…
        
        Lesquelles?
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par karteum59 le 01 décembre 2014 à 19:20. Évalué à 5.
        
        Au hasard : Gnome -> systemd -> glibc.
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par xcomcmdr le 01 décembre 2014 à 13:00. Évalué à 3. Dernière modification le 01 décembre 2014 à 13:04.
        
        Moi ce que j'observe, c'est que mes distros basées sur Musl (et les BSD) ont de moins en moins de chances de pouvoir intégrer Gnome… (et non: musl n'a pas vocation à intégrer tous les GNUisms et les bloats de la glibc, tout comme les *BSD). Encore une fois: personne n'a demandé à Lennard de faire lui-même le boulot de portabilité (lennard code ce qu'il souhaite. Il a le droit de ne pas s'intéresser aux BSD ou à musl). Mais par contre il a clairement une responsabilité en refusant les patches qui lui sont envoyés pour permettre cette portabilité !
        
        Alors déjà :
        - refuser un patch en soit ça peut se comprendre, hein. Qui va le maintenir ? Est-il vraiment utile ? Le coût en termes de complexité de code vaut-il le jeu ? Est-il conforme aux normes de codage du projet ? etc…
        - et puis systemd est fortement dépendant des APIs de Linux (control groups, fanotify, capabilities, inotify, …) pour remplir sa mission (contrôler les services), tellement que ne plus en dépendre ce n'est plus faire systemd, c'est faire autre chose, pour un autre public.
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par Enj0lras le 01 décembre 2014 à 14:29. Évalué à 4.
        
        Je suis très loin de penser que systemd devrait être portable mais je ne suis pas d'accord avec ta remarque qui dit que c'est impossible. Ces fonctionnalités ont des équivalents sous d'autres OS, et il serait parfaitement possible d'écrire du code portable avec des implémentations spécifiques pour chaque API. C'est une volonté "politique", pas une volonté technique.
        
        Encore une fois, je ne dis pas que le fait que systemd soit linux only soit un problème, personnellement j'utiliser BSD sur mon laptop et j'en ai strictement rien à faire que systemd ne compile pas sur mon OS. Par contre se cacher derrière des raisons techniques c'est un peu de la mauvaise foi à mon avis.
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par xcomcmdr le 01 décembre 2014 à 14:54. Évalué à 4.
        
        Ces fonctionnalités ont des équivalents sous d'autres OS
        
        Vraiment ? (mythe 15 et 16) Même les control groups ?
        
        Et est-ce vraiment utile de rendre systemd portable, avec toute la complexité associée, quand ça n'intéresse personne (par exemple, chez *BSD) ?
        
        Myth: systemd could be ported to other kernels if its maintainers just wanted to.
        
        That is simply not true. Porting systemd to other kernel is not feasible. We just use too many Linux-specific interfaces. For a few one might find replacements on other kernels, some features one might want to turn off, but for most this is nor really possible. Here's a small, very incomprehensive list: cgroups, fanotify, umount2(), /proc/self/mountinfo (including notification), /dev/swaps (same), udev, netlink, the structure of /sys, /proc/$PID/comm, /proc/$PID/cmdline, /proc/$PID/loginuid, /proc/$PID/stat, /proc/$PID/session, /proc/$PID/exe, /proc/$PID/fd, tmpfs, devtmpfs, capabilities, namespaces of all kinds, various prctl()s, numerous ioctls, the mount() system call and its semantics, selinux, audit, inotify, statfs, O_DIRECTORY, O_NOATIME, /proc/$PID/root, waitid(), SCM_CREDENTIALS, SCM_RIGHTS, mkostemp(), /dev/input, …
        
        And no, if you look at this list and pick out the few where you can think of obvious counterparts on other kernels, then think again, and look at the others you didn't pick, and the complexity of replacing them.
        
        Myth: systemd is not portable for no reason.
        
        Non-sense! We use the Linux-specific functionality because we need it to implement what we want. Linux has so many features that UNIX/POSIX didn't have, and we want to empower the user with them. These features are incredibly useful, but only if they are actually exposed in a friendly way to the user, and that's what we do with systemd.
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par Enj0lras le 01 décembre 2014 à 21:12. Évalué à -3.
        
        les jails sont des cgroups.
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par xcomcmdr le 01 décembre 2014 à 21:27. Évalué à 4.
        
        J'ai un doute, mais si tu le dis.
        
        Tu as les cgroups… Et tout le reste ?
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par GnunuX (site web personnel) le 01 décembre 2014 à 22:09. Évalué à 6.
        
        les jails sont des cgroups
        
        Tu es bien sûr de savoir ce qu'est des "cgroups" ? Tu ne confonds pas avec les namespaces/chroot ?
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par Enj0lras le 02 décembre 2014 à 01:20. Évalué à 0.
        
        Absolument. Les jails ne sont pas des namespaces. Seule la pile réseau peut être virtualisée.
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par GnunuX (site web personnel) le 02 décembre 2014 à 09:27. Évalué à 4.
        
        Je ne connais pas spécialement les jails, mais pour moi cela permet d'isoler des services non ?
        
        Les cgroups servent à (d'après http://fr.wikipedia.org/wiki/Cgroups ) :
        
        la limitation des Ressources ;
        
        la Priorisation ;
        
        la comptabilité ;
        
        le contrôle.
        
        L'isolation se fait via les namespaces.
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par karteum59 le 01 décembre 2014 à 19:24. Évalué à 1.
        
        Sauf qu'on ne parle pas du refus de un patch pour des raisons telles que le coding style, mais bien du refus (de principe) du moindre code additionnel pour être compatible avec autre chose que Linux/glibc ("we will rely on good APIs exposed in the generally accepted Linux API which is the one glibc exposes")
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par Zenitram (site web personnel) le 01 décembre 2014 à 19:34. Évalué à -6. Dernière modification le 01 décembre 2014 à 19:35.
        
        Rigolo quand même : tu te plains du refus d'une personne d'ajouter du code additionel sous excuse qu'une autre personne refuserait d'ajouter du code additionel. Dans ces deux personnes, une seule est en tort, pas l'autre, pas du tout…
        
        rigolo que des fois les gens se plaignent qu'il y ai du NIH, et d'autres fois ils se plaignent du refus de NIH.
        
        si ce n'est pas du foutage de gueule ça… C'est triste d'arriver à un tel degré de mauvaise foi, ça en dit très long sur le degré de maturité des gens qui critiquent systemd.
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par xcomcmdr le 01 décembre 2014 à 20:09. Évalué à 5. Dernière modification le 01 décembre 2014 à 20:13.
        
        Parce que les APIs spécifiques n'existent pas ailleurs, ou du moins pas de manière équivalente !
        
        Si on lit uniquement ce que tu cites, Lennart est le Malin.
        
        Si on lit tout le mail, c'est beaucoup plus nuancé : quand c'est "portable" au prix de rajouter énormément de code à systemd (qui existe déjà dans la glibc), est-ce vraiment sain ?
        
        La réponse de Lennart est non.
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
    - [^] # Re: Fonctionnalités clées.
      
      Posté par tao popus le 03 décembre 2014 à 01:37. Évalué à 2.
      
      tiens, j'ai suivi le lien et je note ça que j'avais loupé dans l'histoire des libc :
      
      Note that previous versions of this comparison included eglibc rather than glibc, mainly since Debian-based distributions were using the eglibc fork during the time in which glibc was essentially unmaintained. Since most of eglibc has been merged back into glibc and eglibc is being discontinued, the comparison has been updated based on glibc.
      
      Au passage, on remarque que (e)glibc est bien plus gourmande en mémoire dans la comparaison des auteurs de musl, mais est environ 2 fois plus rapide (à ~30% près) sur une bonne partie des fonctions importantes (allocation/libération mémoire, création/suppression des threads, etc…) à quelques exceptions près.
      
      J'aime bien le côté tout UTF-8 par défaut et du coup une gestion plus performante ce cet encodage par musl, mais vu le nombre d'incompatibilité avec les applis utilisant (malheureusement) les anciens encodages, je me dit que pas mal ne doivent plus tourner (l'occasion de se pousser le cul pour tout remettre tout ces beaux codes tous libres en UTF ?).
      
      Elle a des côtés plus résistant au crash qui semblent prometteur dans certains cas d'après ce tableau. Vu les incompatibilité et les problèmes encore présents d'une part et d'autre, il vaudra mieux dans beaucoup de cas attendre les évolutions à venir avant de déterminer si un changement serait une bonne idée ? Intéressant de savoir que ça existe en tout cas.
  - [^] # Re: Fonctionnalités clées.
    
    Posté par Moonz le 01 décembre 2014 à 10:33. Évalué à 8.
    
    La question devrait plutôt être : en quoi systemd vous a négativement impacté
    
    Des commandes qui me renvoient « Permission denied » en root grâce à la magie de policykit/consolekit/logind. Ça fait toujours plaisir quand ta machine te dis « va te faire foutre ». C’est pas toi normalement l’ayattolah de « c’est la machine qui doit être au service de l’homme et pas l’inverse » ? :)
    
    Un hard reboot sur un serveur de prod à cause d’un crash du pid 1 (raison inconnue à ce jour) qui a empêché complètement l’utilisation à la fois de systemctl, et, plus « rigolo », journalctl et reboot (c’est pratique de débugger et corriger l’erreur dans ces conditions). Alors je suis d’accord qu’un crash d’un process n’est pas choquant pour un logiciel aussi jeune, par contre le fait qu’un crash rende inopérant des choses aussi fondamentales c’est juste ridicule et assez révélateur des problèmes que les anti-systemd pointent du doigt depuis le début, relativement aux couplages forts de ses composants.
    
    J’ai pas mal poussé pour l’adoption assez rapide (via les backports debian) de systemd en interne grâce à certaines de ses fonctionnalités qui sont extrêmement adaptées à notre workflow (et globalement ça reste positif), mais j’avoue que ces deux points m’ont assez refroidis… Si jamais notre workflow n’avait pas été aussi adapté à systemd, le bilan aurait été extrêmement négatif.
    - [^] # Re: Fonctionnalités clées.
      
      Posté par gnumdk (site web personnel) le 01 décembre 2014 à 11:00. Évalué à -4.
      
      Debian, systemd, production, serveur?
      
      T'es sérieux?
    - [^] # Re: Fonctionnalités clées.
      
      Posté par Misc (site web personnel) le 02 décembre 2014 à 10:12. Évalué à 2.
      
      je suis assez surpris que ça bloque journalctl. Sur ma RHEL 7, un strace montre que ça ouvre directement le fichier journal, donc je voit pas vraiment comment un crash de systemd va impacter ça.
      
      Je vois bien d'autres façons dont ça peut faire chier ( exemple, le démarrage à la demande de sshd qui marcherais sans doute plus ), mais ça n'a pas l'air d'être ce que tu décris.
      
      Quand a bloquer reboot, je pourrais imaginer un fallback qui fait un echo 'b' dans /proc, mais ça peut être bloqué aussi. Ou juste l'appel reboot en direct.
- [^] # Re: Fonctionnalités clées.
  
  Posté par Anonyme le 30 novembre 2014 à 13:23. Évalué à 0. Dernière modification le 30 novembre 2014 à 13:24.
  
  La question ne serait-elle pas encore, une fois de plus, sujette à lancer de merveilleux trolls ?
  - [^] # Re: Fonctionnalités clées.
    
    Posté par Enj0lras le 30 novembre 2014 à 13:31. Évalué à 4.
    
    Non, la question a un but bien précis. Identifier les fonctionnalités clées de systemd qui plaisent aux utilisateurs et essayer de les implémenter autre part.
    - [^] # Re: Fonctionnalités clées.
      
      Posté par mackwic le 30 novembre 2014 à 14:56. Évalué à 2.
      
      Excellente idée. Je te conseille de lire ces blocs de texte qui gènent le scroll vers la partie commentaire. ;-) En particulier la partie Écrire une alternative.
      - [^] # Re: Fonctionnalités clées.
        
        Posté par Enj0lras le 30 novembre 2014 à 15:14. Évalué à 3.
        
        Je ne parle pas d'écrire une alternative mais d'améliorer l'existant en important des choses qui manquent (comme le monitoring des daemons).
- [^] # Re: Fonctionnalités clées.
  
  Posté par mackwic le 30 novembre 2014 à 13:24. Évalué à 10.
  Qu'est ce que selon vous systemd a apporté à votre expérience utilisateur ?
  1. Ça juste marche
  2. Ça juste marche bien
  3. Ça juste marche vite
  4. C'est plus pratique pour gérer les services. Un peu plus, pas beaucoup.
  5. J'ai des options de log sympa, variées, utiles. Ça me facilite la vie, un peu.
  En tant qu'utilisateur, ça n'est pas une révolution. Ça passe pour une amélioration incrémentielle de stabilité, vitesse et cohérence. Ce qui est bienvenu.
  - [^] # Re: Fonctionnalités clées.
    
    Posté par Enj0lras le 30 novembre 2014 à 13:30. Évalué à 2.
    
    Passons sur les 3 premiers points, qui sont en effet importants mais sont des évidences. Pourrais tu préciser les points 4 et 5 ?
    - [^] # Re: Fonctionnalités clées.
      
      Posté par Astaoth le 30 novembre 2014 à 13:55. Évalué à 4.
      
      Honnêtement, je dirais que le point 3 dépend vraiment de la config et n'est pas évident pour tous. Chez moi, systemd est aussi lent que SysVInit, sauf que les tty sont moins réactif au démarrage de l'ordi, et de temps en temps systemd se plante en voulant lancer networkd.
      
      Emacs le fait depuis 30 ans.
    - [^] # Re: Fonctionnalités clées.
      
      Posté par mackwic le 30 novembre 2014 à 14:42. Évalué à 8.
      
      Passons sur les 3 premiers points, qui sont en effet importants mais sont des évidences.
      
      Je ne suis pas d'accord, bien au contraire. Le fait que ça marche n'est pas une évidence, ni pour l'utilisateur linuxien habitué, ni pour le développeur. C'est une grosse dépense de temps et d'énergie pour que ça juste marche vite et bien, qui doit être saluée haut et fort.
      
      De plus, si systemd diminue l'effort nécessaire à faire marcher le bouzin, on est gagnant. Et, coup de bol, c'est le cas.
      
      La question qui sera à l'ordre du jour dans les prochaines années est: est-ce que systemd est le meilleur middleware bas niveau disponible parmi ceux proposés par la communauté.
      D'autres alternatives proposaient des éléments intéressants, mais ont été balayés par la résistance au changement des distros existantes.
      
      Pour ce qui est plus pratique:
      - interface unifiée de gestion des services
      - le reboot automatique des services défaillants de façon propre
      - des logs de service unifiés
      - les queries journalctl sont puissantes, c'est très satisfaisant
      - la configuration de la gestion des logs (roations, upload, archive, etc.) est plus simple que ce qui existait déjà (cad: syslog ou rsyslog ou logrotate ou crontab ou….) et uniformément robuste (récupération des logs en cas de panique, upload résistant aux déconnexion intermittentes, système binaire sympa pour diminuer le remplissage de /var/log, etc.).
      
      Surement que j'ai pu profiter d'autres fonctionnalités sans m'en rendre compte. Comme je disais, ça juste marche bien, et c'est ce qui compte.
      - [^] # Re: Fonctionnalités clées.
        
        Posté par neil le 01 décembre 2014 à 00:04. Évalué à 8.
        
        Pareil, je suis passé à systemd sans en avoir besoin parce que les distributions que j’utilise l’on fait mais les trois premiers points me semblent faux : sur un vieux netbook, au moins une fois sur 10 le démarrage bloque sans atteindre le login graphique ; sur un laptop que j’utilise souvent, systemd faisait ramer tout le système lors des crash et j’ai du désactiver les coredumps, ça semble une “feature” connue d’après les wikis des distributions, sur la même machine systemd utilise de temps à autre 100% du CPU (rarement, mais pourquoi ?) ; ça fait des années que j’utilise des SSD, et sur des os qui bootent en quelques secondes, ou qui attendent une clé de chiffrement, je n’ai pas d’amélioration perceptuellement significative.
        
        Systemd me fait quand même gagner pas mal de temps avec la centralisation des logs, la recherche par des dates spécifiques, et tout le reste.
        
        Pour la rapidité je reste vraiment déçu. Ça aurait été pas mal d’avoir un système qui démarre quasiment instantanément après appui sur le bouton marche, avec directement l’écran de connexion. Je ne comprends pas pourquoi les OS, noyaux et le matériel se contentent toujours de ces déplorables secondes qui rendent la mise en veille si intéressante.
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par gnumdk (site web personnel) le 01 décembre 2014 à 08:25. Évalué à 3.
        
        Euh, sur mon XPS 13, le boot entre GRUB et Xorg c'est 1 seconde…
        
        Par contre, c'est sur ArchLinux, avec Debian qui n'exploite pas encore vraiment systemd, c'est 4 secondes…
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par tao popus le 03 décembre 2014 à 02:00. Évalué à 2.
        
        Sur mon compatible IBM-PC (core i7) avec SSD, la plus grosse perte de temps c'est le BIOS (30s~1min de american trends, ok il y a le HD et des bus PIC inutil(isé)es en plus à lancer), ma carte mère n'est pas listée dans les compatibles dans coreboot, mais les composants semblent OK, ça me donne envie de m'investir dans ce domaine pour me débarrasser de cette croute, mais il faudrait une véritable volonté. Après sous ubuntu et antergos (archlinux, donc systemd), on sent plus de rapidité sur le second, mais c'est pas super flagrant non plus.
        
        Sur ARM (32 bits, il n'y a pas d'americantrends à la con, mais uboot), la partie 'bios' (en fait c'est différent puisque le bios est à la fois uboot (en gros grub compact) et l'os lui même, soit est quasi-instantanée (j'ai laissé un délai de 2s pour les options). J'ai de l'ArchlinuxARM avec (systemd) ça boot bien 2 ou 3 fois plus vite qu'un ubuntu il y a 1 an, il faudrait re-comparer aujourd'hui. Sur une carte microSD, ça permet d'avoir l'espace d'un SSD en plus compact, plutôt que les 4Go de la flash, c'est un tout petit peu plus lent, environ 10~20 secondes au total, mais toujours plus rapide que le PC (systemd ou pas). Idéalement, il faudrait utiliser la flash comme partition réservée à l'hibernation, afin de booter plus rapidement, on devrait pouvoir atteindre 2 ou 3 secondes de boot, départ sans courant avec ce principe.
        
        Je me demande si les ARM 64bits (tous ACPI compliant avec les mêmes bus PCI et SATA que les PC x86), vont aussi avoir du american trends bouseux dans le bios par défaut ???
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par Ph Husson (site web personnel) le 04 décembre 2014 à 00:22. Évalué à 3.
        
        Pour l'instant j'ai pas vu d'ARM64 avec pci ni sata ni acpi, alors que j'ai du en voir trois architectures.
        À l'heure actuelle, les ARM64, c'est juste que ils ont remplacé un Cortex-AX/-A1X en A53 ou A57 sans rien changer d'autre (enfin les mises à jours habituelles)
        Je suis intéressé par cette info, t'as vu ça où ?
        Je vois guère que pour les serveurs qu'ils feraient ce genre de choses (AMD ? nvidia peut-être ?)
- [^] # Re: Fonctionnalités clées.
  
  Posté par GeneralZod le 30 novembre 2014 à 13:35. Évalué à 8.
  
  Qu'est ce que selon vous systemd a apporté à votre expérience utilisateur ?
  
  systemd a permis de supprimer pleins de bugs liés à des composants bogués/non maintenus et à leurs interactions complexes.
  - [^] # Re: Fonctionnalités clées.
    
    Posté par haleth le 30 novembre 2014 à 13:39. Évalué à -2.
    
    Précise.
    - [^] # Re: Fonctionnalités clées.
      
      Posté par mackwic le 30 novembre 2014 à 14:47. Évalué à 6. Dernière modification le 30 novembre 2014 à 14:48.
      
      Systemd est un middleware userspace bas niveau. Il ne s'occupe pas seulement de l'init ordonné et parallélisé des services, mais aussi de créer et maintenir les pipes/socket de communication inter-services.
      
      Avant systemd, c'était le bordel et très hacky. Donc error prone. Tout une catégorie d'erreurs système ont maintenant disparu.
      - [^] # Re: Fonctionnalités clées.
        
        Posté par haleth le 30 novembre 2014 à 15:35. Évalué à -4.
        
        Ouais, donne des exemples concrêts s'il te plait
        J'ai besoin que tu me montres les erreurs systèmes que je subis chaque jour, afin de me permettre de sortir de ce carcan qu'est le syndrome de stockholmes.
        Je t'en supplie, aide moi !
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par mackwic le 30 novembre 2014 à 15:42. Évalué à 2.
        
        Petit troll, va. Tu m'as eu, bien joué.
    - [^] # Re: Fonctionnalités clées.
      
      Posté par Misc (site web personnel) le 30 novembre 2014 à 15:56. Évalué à 6.
      
      Alors je peux, avec une suffisance gonflant mon eog, me citer moi même, quand j'ai pourri Kadalka :
      
      https://linuxfr.org/nodes/97210/comments/1426891
      
      C'est un gros pâté, mais les exemples que je donnent sont vers 75% du texte. l'exemple de bind est facile à piger, mais il arrive sans doute peu en pratique sur une petite installation.
      
      Tu as aussi mon exemple de apache et de sympa ( qui arrive plus souvent ). Ensuite, peut être que tu as accepté le fait que les bugs arrivent, ou que ça marche pas de temps en temps sans savoir pourquoi. D'autres non.
      - [^] # Re: Fonctionnalités clées.
        
        Posté par haleth le 30 novembre 2014 à 16:24. Évalué à 2.
        
        Intéressant !
        
        Je n'aurais qu'une question.
        Est-ce que systemd est requit pour utiliser les cgroups ?
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par Misc (site web personnel) le 30 novembre 2014 à 17:48. Évalué à 8.
        
        Ça dépend comment tu veux les utiliser. Pour limiter les processus en terme de ressources, non, tu as déjà des logiciels existants, tu peux le faire à la main. Systemd automatise cette partie et l'unifie au niveau de la configuration.
        
        Pour ce qui est d'utiliser le tracking des processus, tu peux le faire à la main, mais c'est vite chiant. Donc openrc et systemd peuvent le faire pour toi.
        
        Ensuite, dans le futur, le kernel s'oriente vers une architecture avec un seul processus autorisé à gerer les cgroups. Lennart parle sur la liste de systemd de l'impact qu'il y a eu ( http://lwn.net/Articles/555922/ ) et Linux.com explique pourquoi les devs kernels veulent changer ça :
        http://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign
        
        Il y a aussi pas mal d'info sur http://lwn.net/Articles/575672/
        
        Et le fait que les devs de cgmanager et de systemd se sont réunis pour trouver une solution il y a 2 mois à Dusseldorf pour discutter interopérabilité ( une info qu'on ne relaye pas assez, bien sur, ç'est moins vendeur pour un journal )
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par haleth le 30 novembre 2014 à 18:25. Évalué à -1.
        
        Intéressant, une nouvelle fois !
        
        J'aime quand deux parties ""opposés"" (avec plein de guillemets) sont du même avis !
        
        En fait, le message que j'essaie de faire passer, ce qu'il est tout à fait possible d'utiliser les cgroups avec sysvinit.
        
        Par exemple, wrapper les fonctions do_start() et do_stop() de start-stop-daemon
        Bref, ça fait partie des fonctionnalités cools de systemd
        Mais cela ne justifie pas, à mes yeux, un changement aussi global (au lieu d'une simple mise à jour de l'existant)
        
        Bref
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par Thomas Debesse (site web personnel) le 30 novembre 2014 à 18:50. Évalué à -2.
        
        Par exemple, wrapper les fonctions do_start() et do_stop() de start-stop-daemon
        Bref, ça fait partie des fonctionnalités cools de systemd
        Mais cela ne justifie pas, à mes yeux, un changement aussi global (au lieu d'une simple mise à jour de l'existant)
        
        Certes, on peut envelopper l’enveloppe de l’enveloppe de l’enveloppe de l’enveloppe, mais peut-être que certains se sont dit qu’une couche de plus sur l’existant était la couche de trop ?
        
        Je crois qu’on peut comparer le système d’init avec l’administration publique. 1/4 des actifs du pays sont fonctionnaire, c’est lourd mais ça marche encore, et quand on a besoin de faire évoluer le bouzin, on rajoute encore une couche avec des gestionnaires pour gérer les gestionnaires, et l’on fait des réunions pour organiser des réunions, et on crée des commissions pour assister les commissions. Tout le monde râle parce que c’est lourd et que ça coûte cher et que c’est pas efficace, mais quand on veut réformer en profondeur, le pays tout entier est en grève. Il faut dire qu’1/4 du pays vit grâce à ce montage donc la force de frappe en faveur de l’immobilisme est conséquente.
        
        ce commentaire est sous licence cc by 4 et précédentes
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par Misc (site web personnel) le 01 décembre 2014 à 00:28. Évalué à 6.
        
        La mise à jour est global parce que Debian a tardé. Sur Fedora, Arch, Mageia, ça s'est traduit par des mises à jours successives.
        
        C'est bien joli de vouloir attendre pendant 3 ans que le projet se mette en place, mais voila, faut du coup aussi se prendre 3 ans de changements au lieu d'un.
        
        Et la question est pas de "on peut utiliser les cgroups", mais d'une part, est ce que quelqu'un les utilise ( car globalement, y a que openrc et openrc l'a fait après que systemd est commencé ).
        
        Et surtout, est ce qu'on peut tout faire ce que systemd fait via le shell. Et la réponse est "pour la plupart, peut être avec beaucoup de complexité et tout n'est pas possible", cf encore un gros pâté de ma part : https://linuxfr.org/nodes/103677/comments/1569313 ). En gros, il y a des trucs impossibles à faire en pur shell, et comme je conclue mon pâté, tu va te retrouver à faire un bout de systemd dans un start-stop-daemon magique qui fait tout. Autant faire des unités systemd.
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par Thomas Debesse (site web personnel) le 01 décembre 2014 à 02:44. Évalué à 5.
        
        En gros, il y a des trucs impossibles à faire en pur shell, et comme je conclue mon pâté, tu va te retrouver à faire un bout de systemd dans un start-stop-daemon magique qui fait tout. Autant faire des unités systemd.
        
        Ben c’est un peu ce que je dis, à force de rajouter des pansements à start-stop-daemon, on invente un systemd en plus lourd.
        
        ce commentaire est sous licence cc by 4 et précédentes
- [^] # Re: Fonctionnalités clées.
  
  Posté par Astaoth le 30 novembre 2014 à 14:06. Évalué à 9.
  
  Qu'est ce que selon vous systemd a apporté à votre expérience utilisateur ?
  
  Y a du pour et du contre, mais rien de révolutionnaire pour mon usage quotidien.
  
  Pour :
  - la création et la gestion des services est beaucoup plus simple
  - du coup, pour lancer un programme au démarrage de l'ordi, je ne me prends plus la tête avec les fichiers rc avec lesquels j'ai toujours eu du mal (cela dit, avec SysVInit, j'utilisais crontab avec "@reboot")
  
  Contre (généralité)
  - faut tout réapprendre, ca demande du temps
  - je trouve que le côté fichier était un poil plus accessible, mais c'est une question d'habitude
  - les tty sont beaucoup moins réactifs au démarrage de l'ordi (je n'utilise pas de gestionnaire de session)
  
  Contre (chez moi (tm))
  - systemd a une facheuse tendance à se planter en lancant networkd au démarrage de l'ordi : du coup, reboot obligatoire
  
  Au final, en tant qu'utilisateur d'un ordi de bureau sous GNU/Linux, ca m'apporte des petites frustrations quotidiennes, pour un avantage très ponctuel et pour lequel j'avais trouvé un workaround très simple.
  
  Emacs le fait depuis 30 ans.
  - [^] # Re: Fonctionnalités clées.
    
    Posté par benoar le 01 décembre 2014 à 10:41. Évalué à 3.
    systemd a une facheuse tendance à se planter en lancant networkd au démarrage de l'ordi : du coup, reboot obligatoire
    Tu peux préciser comment ça se passe quand tu as un tel problème ? Pour moi, c'est un des problèmes majeurs que j'ai avec systemd : je n'ai pas envie de faire beta-testeur de fonctionnalités qui font revenir plus de 10 ans en arrière (devoir rebooter parce qu'un soft est buggé ?!…).
    
    Ça plus le fait que networkd, par exemple, ne va sûrement pas gérer mes confs réseau « exotiques » (à l'époque, j'avais fait un patch pour ignorer les bridge dans network-manager, version 0.8 ; j'ai vu que la version « courante » à ce moment-là était un cran au-dessus, et que l'API avait complètement changé, ce qui faisait que mon travail était inutile : ça m'a bien calmé, j'ai laissé tomber).
    - [^] # Re: Fonctionnalités clées.
      
      Posté par Astaoth le 01 décembre 2014 à 11:23. Évalué à 4.
      
      Tu peux préciser comment ça se passe quand tu as un tel problème ?
      
      Je lance le système, je vois défiler la liste des services qui démarre, puis je le vois prendre son temps pour démarrer networkd, et finalement plus rien ne se passe, il ne charge plus rien. Je suis obligé d'éteindre brutalement l'ordi puis de le rallumer. Pratique, hein ?
      
      Emacs le fait depuis 30 ans.
      - [^] # Re: Fonctionnalités clées.
        
        Posté par xcomcmdr le 01 décembre 2014 à 11:40. Évalué à 0.
        
        J'utilise NetworkManager sans souci, d'autant que networkd est optionnel.
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
      - [^] # Re: Fonctionnalités clées.
        
        Posté par benoar le 01 décembre 2014 à 11:50. Évalué à 4.
        
        Pratique, hein ?
        
        Effectivement. Même pas un ^C pour arrêter le machin qui foire ? Ça fait peur.
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par gnumdk (site web personnel) le 01 décembre 2014 à 12:42. Évalué à -3. Dernière modification le 01 décembre 2014 à 12:42.
        
        Parce que ^C avec sysvinit ça fonctionne peut être?
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par Moonz le 01 décembre 2014 à 12:50. Évalué à 6. Dernière modification le 01 décembre 2014 à 12:51.
        
        Heu… oui, en tout cas sur Arch pré-systemd. À peu près certain que ça marche sur sysresccd (base Gentoo) aussi.
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par shbrol le 01 décembre 2014 à 15:25. Évalué à 4.
        
        Quand le machin te dit "ca fait 30 démarrages que le disque a pas été vérifié, je lance fsck", avec sysvinit tu peux faire un ^C pour continuer le boot et mouler tout de suite sur linuxfr, puis lancer à la main fsck sur le gros disque de 2To sur lequel ça dure une éternité.
        
        Avec systemd, tu peux pas, tu dois attendre…
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par moi1392 le 01 décembre 2014 à 16:59. Évalué à 1.
        
        avec systemd, le disque de 2To qui n'a pas besoin d'être monté au boot n'est pas monté, et si tu le forces à être monter, comme personne n'en a besoin, rien n'est bloqué pendant le fsck du disque, sauf si tu forces une dépendance d'une service sur le fait que ce disque soit monté !
        
        Donc pareil, sauf que ça le fait pour toi, tu ne perds pas ton temps à te logguer en root dans une console pour faire ton fsck à la main, aller vérifier de temps en temps qu'il a fini pour ensuite monter ton fs…
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par shbrol le 01 décembre 2014 à 18:46. Évalué à 4.
        
        Intéressant. Si je comprends bien, je dois laisser systemd monter les disques à la demande, et alors je n'aurais plus le problème au boot, puisque le disque ne sera pas monté automatiquement.
        Mais le problème reviendra lorsque je voudrais accéder au disque plus tard, il sera monté à la volée, avec fsck, donc attente d'une éternité moins une minute, alors que j'en ai besoin là tout de suite…
        
        C'est un peu mieux, je peux mouler immédiatement après le démarrage de la machine, mais quand je vais vouloir me mettre à bosser, ça ne sera pas possible tout de suite, donc je vais devoir retourner mouler, tout énervé en plus. Bof.
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par moi1392 le 02 décembre 2014 à 15:31. Évalué à 3. Dernière modification le 02 décembre 2014 à 15:33.
        
        "et si tu le forces à être monter, comme personne n'en a besoin, rien n'est bloqué pendant le fsck du disque"
        
        cf moi
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par shbrol le 02 décembre 2014 à 19:10. Évalué à 2.
        
        Oui, tu l'as déja dit comme cela, mais il faudrait que tu détailles un peu, parce que je constate que ca ne marche pas comme tu le décris.
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par xcomcmdr le 01 décembre 2014 à 20:41. Évalué à 3. Dernière modification le 01 décembre 2014 à 20:43.
        
        tu en es sûr ?
        http://www.rdeeson.com/weblog/125/how-to-cancel-an-fsck-disk-check-during-boot-on-arch-linux.html
        
        Tiens, c'est dans la TODO-list de systemd on dirait :
        http://cgit.freedesktop.org/systemd/systemd/tree/TODO?id=HEAD#n562
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par xcomcmdr le 01 décembre 2014 à 20:47. Évalué à 2.
        
        Sinon, sur ext4 fsck est extrêmement rapide.
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par Astaoth le 01 décembre 2014 à 16:28. Évalué à 1.
        
        À tiens j'y avais pas pensé, je testerai la prochaine fois. Merci de l'idée.
        
        Emacs le fait depuis 30 ans.
- [^] # Re: Fonctionnalités clées.
  
  Posté par Misc (site web personnel) le 30 novembre 2014 à 15:21. Évalué à 9.
  
  Alors moi, j'apprécie déjà d'avoir des trucs plus facile à écrire que les scripts d'init. J'ai par exemple fait mon script pour lancer un serveur irc en perl en 5 minutes juste en le lancant en premier plan. J'ai pas mis très longtemps non plus pour lancer prosody dans docker, bien moins que de faire marcher docker en premier lieu.
  
  J'aime aussi beaucoup journalctl -u, au point que je me perde un peu quand je me retrouve sur des Centos 6 ( on s'habitue vite à la completion et au rangement )
  
  Et j'ai surtout bien aimé de pouvoir mettre un bout de config via /etc/systemd/monservice.d/foo.conf, ça me parait plus perenne pour contourner un bug que l'ancienne façon, ou je devait copier et refaire le script.
  - [^] # Re: Fonctionnalités clées.
    
    Posté par haleth le 30 novembre 2014 à 15:33. Évalué à 0.
    
    Tu parles de /etc/default/foo ?
    - [^] # Re: Fonctionnalités clées.
      
      Posté par Misc (site web personnel) le 30 novembre 2014 à 15:49. Évalué à 5.
      
      Non, sinon j'aurais dit "je trouve tel truc mieux que /etc/default".
      
      Déjà, /etc/default est pourri car ça reste du shell. Ce qui veut dire que soit tu te limites à la syntaxe FOO="truc" et c'est plus du shell, soit tu mets du vrai shell (genre $() pour lire un truc dynamiquement) et la, ça devient difficile à parser par des outils automatisés (genre ansible/puppet, etc). Ensuite, la flexibilité d'un coté implique la lourdeur de l'autre, je peux comprendre que certains préfèrent la syntaxe de /etc/default pour divers raisons.
      
      Ensuite, avec /etc/default, tu es quand même dépendant de ce que la personne qui a écrit le script a choisi d'utiliser. Par exemple, tu peux souvent pas surcharger proprement la ligne de commande complète du service que tu veux lancer, il te faut lire et trouver la version spécifique du paramètre que tu va utiliser. Paramètres non documentés upstream, bien sur, au contraire des options de démarrage. Parfois, c'est le contraire, tu as juste les options et tu peux faire presque ce que tu veux, sauf si ce que tu veux, c'est d'utiliser un programme avant (chroot foo, nsenter foo, runcon foo).
      
      Donc non, je parle pas de /etc/default. C'est un mécanisme vite limité par rapport à ce que systemd propose et ce que j'utilise. Mais si tu as pas de souci avec et que tu penses que c'est suffisant, pas de souci pour moi.
      - [^] # Re: Fonctionnalités clées.
        
        Posté par haleth le 30 novembre 2014 à 18:20. Évalué à 2.
        
        Tu veux dire que /etc/systemd/monservice.d/foo.conf te permet de spécifier plus de chose que ce que le concepteur du logiciel a défini ?
        
        Les fichiers de conf clef = valeur sont les plus simples et les plus pratiques
        Si tu as trop de variables, il faut considérer l'utilisation de plusieurs fichiers
        
        Enfin bref, pourquoi pas (même si je n'ai pas, du coup, compris la différence entre /etc/systemd/monservice.d/foo.conf et /etc/default/foo)
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par Misc (site web personnel) le 01 décembre 2014 à 00:11. Évalué à 7.
        
        Le fichier foo.conf permet de surcharger complétement le fichier monservice.service. Si je veux faire lancer un autre soft, je peux, je donne juste la valeur ExecStart= . Donc oui, ça spécifie plus que l'initscript (pas le logiciel, car le concepteur du logiciel et la personne qui fait l'initscript, c'est en général 2 personnes différentes, l'initscript venant de la distribution en général).
        
        Et Ce que je veut dire, c'est que l'usage des drop-in configuration files (c'est le nom de la chose) permet une gestion plus propre.
        
        Si je rajoute User=toto dans le fichier, ça va agir comme j'avais mis ça dans le fichier de base via une concaténation de tout les fichiers, avec une priorité défini pour savoir qui s'applique en dernier ( en l’occurrence, le fichier dans /etc prends le pas sur celui dans /usr donc la distro qui a /use sous son contrôle mets le défaut et l'admin a le dernier mot, sans interférence du gestionnaire de paquet qui va écraser le fichier ). Et comme c'est juste un fichier à déposer, ça se fait super facilement via ansible ou autre ( ou via un paquet qui dépose le fichier ). A contrario, va faire un modification propre et perenne d'un fichier shell.
        
        Maintenant, peut être que tu fait encore tes configurations à la mano sans passer par puppet/ansible/etc, et que tu as du temps à perdre à vérifier à chaque upgrade que rien n'a changé dans le fichier pour faire une fusion de la modification à la main. Moi non.
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par Enj0lras le 01 décembre 2014 à 12:20. Évalué à 2. Dernière modification le 01 décembre 2014 à 12:21.
        
        C'est quand même le taff de /etc/conf.d et/ou de rc.conf ça non ?
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par Misc (site web personnel) le 01 décembre 2014 à 13:19. Évalué à 2.
        
        Qu'est ce qui serait le taf, et le taf dans quel logiciel ou quel os ?
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par Enj0lras le 01 décembre 2014 à 14:34. Évalué à 3.
        
        je parle de l'init bsd, tel qu'il était présent aussi sous archlinux. En effet, c'est du shell, mais du shell sous forme clé/valeur. Et si tu génères ça avec des trucs comme ansible, tu as pas besoin de te préoccuper de la syntaxe du shell du moment que c'est bien quoté. Après, c'est moins spécifié que les units systemd, et les variables dépendent souvent du service (par exemple pgsql_user, pgsql_datadir, etc) mais tu peux en général configurer pas mal de chose sans toucher au rc script.
        
        [^] # Re: Fonctionnalités clées.
        
        Posté par Misc (site web personnel) le 02 décembre 2014 à 11:04. Évalué à 3.
        
        Je crois que c'est ce que je dit, c'est que tu peux te limiter, mais c'est plus du shell. Et surtout, tu peux pas forcer les gens à se limiter sauf à prendre autre chose qu'un shell pour parser.
        
        Par exemple, export foo=bar va marcher avec un init en shell qui fait un source ou une execution, mais pas avec systemd ou un autre outil. L'interpolation de variable avec () va pas l'être. Ou tu as les exemple de foo=bar bar2 avec ou sans quotes. Dans du clé/valeur pur, ça peut marcher. Il y a la question des chaines multilignes aussi.
      - [^] # Re: Fonctionnalités clés.
        
        Posté par rpnpif le 30 novembre 2014 à 22:30. Évalué à 0.
        
        Non, dans /etc/default, tu peux mettre des commandes shell autres que des affectations de variables. Je l'ai déjà fait sans problèmes.
        
        [^] # Re: Fonctionnalités clés.
        
        Posté par Misc (site web personnel) le 01 décembre 2014 à 00:04. Évalué à 5.
        
        Oui, c'est ce que je dit, et du coup, ça devient impossible à lire par un outil automatisé, car il ne va pas comprendre la syntaxe ( exemple augeas, etc ). Alors ensuite, y a plein de gens que ça dérange pas, mais y a des gens chez qui ça pose souci. C'est ce que j'ai dit au passage.
# Délation d'une faute de frappe

Posté par rpnpif le 30 novembre 2014 à 14:18. Évalué à 4.

2 les délateurs sortent de milieux un peu plus variés,

Vu le titre du chapitre, il s'agit plutôt des détracteurs et pas des délateurs.
- [^] # Re: Délation d'une faute de frappe
  
  Posté par Ignatz Ledebur le 30 novembre 2014 à 16:48. Évalué à 1.
  
  Ma faute en plus… décidément.
- [^] # Re: Délation d'une faute de frappe
  
  Posté par Benoît Sibaud (site web personnel) le 30 novembre 2014 à 20:16. Évalué à 3.
  
  Corrigé, merci.
# Un peu plus près des étoiles

Posté par blobmaster le 30 novembre 2014 à 14:19. Évalué à 2.

J'ai l'impression de lire un commentaire sur le débat "comment choisir son DVCS ?".

J'adore.

Toi aussi, soit joueur, fait le parallèle entre ce sujet et un que tu connais mieux.
# Les milieux culturels et techniques des zélateurs/détracteurs

Posté par xcomcmdr le 30 novembre 2014 à 14:44. Évalué à 10.

Euh, je suis le seul qui est dérangé par ce passage ?

En gros, les zélateurs ils utilisent Ubuntu (mythe que systemd est pour le destkop derrière ?) et courent après le mythe de l'année du bureau Linux, et n'aiment pas la bidouille.
Et les détracteurs, c'est des barbus, des vrais, avec un vrai bagage technique, qui utilise Slackware, Gentoo, & co, et adorent hacker.

Bref, ce sont deux gros clichés auxquels j'ai du mal à croire.

D'abord j'aimerais bien avoir des sources/stats/études avant d'affirmer des généralités sur une population.

De deux, c'est oublier qu'Archlinux a été l'une des premières distribs à intégrer systemd. L'année du bureau Linux, les mainteneurs d'Archlinux s'en contrefichent.

De trois, ce n'est pas parce que systemd qu'on a un bagage technique limité. C'est même l'inverse, vu la complexité de systemd face à SysV.

Et quatrièmement, systemd n'empêche en rien les hacks (du genre je vais bidouiller mon fstab, faire des règles udev bien barrées, et faire un script de 2k LOC que je vais lancer au démarrage parce que j'en ai besoin)

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
- [^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
  
  Posté par Misc (site web personnel) le 30 novembre 2014 à 15:25. Évalué à 6.
  
  Non, j'ai trouvé ça aussi comme une grosse simplification, surtout parce que je me retrouve plus dans le barbu hacker avec du bagage technique, et pourtant, je rentre pas dans la case "defend sysvinit".
  
  Ensuite, c'est un essai, le mec a quand même eu une réflexion avec laquelle je suis d'accord sur certains points, même si je pense qu'une autre approche est nécessaire pour comprendre le débat. ( genre, je penche de plus en plus à des problématiques d'ordre social et communautaires plus profondes vis à vis du web, d'educations des gens, et de mythologie du libre ).
  - [^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
    
    Posté par YBoy360 (site web personnel) le 30 novembre 2014 à 19:03. Évalué à -1.
    
    Le sous entendu que les avantages de systemd se limite au desktop est gonflant aussi. Quite a étaler la confiture sur tout les systèmes d'init, il en manque des gros.
    
    Apple, Solaris et autres n'utilise plus l'init depuis un baille.
    - [^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
      
      Posté par Bapt (site web personnel) le 30 novembre 2014 à 19:32. Évalué à 9.
      
      Solaris utilise toujours init: https://github.com/illumos/illumos-gate/tree/master/usr/src/cmd/init ce n'est pas parce que la gestion de processus ce fait via SMF que init a besoin d'être remplacé
      - [^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
        
        Posté par Misc (site web personnel) le 01 décembre 2014 à 00:37. Évalué à 1.
        
        C'est une bonne remarque, mais ça devient du coup plus compliqué, car la logique de surveillance d'un process est présente 2 fois. une fois dans init et une fois dans smf.
        
        Et comme quelqu'un l'a fait remarquer sur lwn ( http://lwn.net/Articles/623527/ ), le pid 1 pourrait très bien ne rien avoir de spécial, et ne pas planter le kernel en cas de crash ( ou se faire relancer par le kernel ).
        
        Car c'est quand même la plus grande peur des gens "si ça plante, mon système plante", alors qu'en pratique, c'est pas le fait d'être PID1 qui nous mets dans la merde. C'est le fait de planter, PID1 ou PID50, à partir du moment ou il gère l'état des processus.
        
        Donc faire 2 trucs, ça sert à juste à rajouter de la complexité. Si SMF se vautre, je suis spas sur d'imaginer l'état du système après ( sauf à avoir l'info poussé dans le kernel sous une forme quelquconque, genre l'équivalent des cgroupes avec des metadonnés , et à ce que smf reprenne l'info du kernel quand ile st relancé, mais on arrive à un truc encore moins portable et poussé dans un truc plus critique depuis l'userspace dans le kernel, alors qu'on essaye surtout l'inverse ).
        
        [^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
        
        Posté par Bapt (site web personnel) le 01 décembre 2014 à 00:42. Évalué à 2.
        
        Ça ne marche pas du tout comme tu le penses SMF :)
        
        [^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
        
        Posté par Misc (site web personnel) le 01 décembre 2014 à 08:58. Évalué à 3.
        
        Possible, mais si tu peux préciser un peu plus ?
        
        [^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
        
        Posté par Enj0lras le 01 décembre 2014 à 01:05. Évalué à 3.
        
        Je connais pas bien SMF, même si on m'en a parlé plusieurs fois, mais l'idée qui est en train de faire son bonhomme de chemin pour rcNG (impulsée par bapt d'ailleurs) c'est d'avoir un processus de contrôle pour chaque daemon. Si le processus se vautre, seul ce daemon serait impacté.
        
        [^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
        
        Posté par Misc (site web personnel) le 01 décembre 2014 à 11:37. Évalué à 1.
        
        Donc, suite à ça,j'ai regardé à gauche à droite, mais j'ai pas la prétention de tout piger d'un coup, donc si je dit une connerie, faut le dire :).
        
        Donc l'idée, est d'avoir un processus lancé par init, et ce processus, via un appel système, devient un "init local". Comme ça veut rien dire, j'explique. par init local, j'entends un processus en charge de recevoir les signaux des orphans, tout comme init, et qui chope les zombies pour les tuer, ce qui semble éviter les cgroups pour suivre les process, et ce qui permet de pousser le code en dehors du pid 1.
        
        C'est une approche intéressante, mais ça veut pas dire une occupation doublé dans la table des processus ?
        
        Genre si je lance 10 000 containers, je vais avoir 10 000 processus de supervision. C'est pas un souci en temps normal et pas un souci pour tout de suite ( voir même un souci pour jamais peut être ), mais si tu imagines 100 Mo par containers, ça va te faire 1T de ram pour 1000 ( ce qui est faisable ), donc on est pas loin du stade ou ça va AMHA poser souci ( genre vers les 10000/20000 ). Bien sur, avec un systéme comme ksm, et avec des containers plus petits, ça peut arriver vite.
        
        Ensuite, peut être que c'est le cpu et les I/O qui vont tomber en premier donc je me fait des idées.
        
        [^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
        
        Posté par Enj0lras le 01 décembre 2014 à 12:16. Évalué à 6.
        
        je pense que c'est très fortement négligeable. Un processus aussi léger que ça, ça serait 500ko de ram. Dont une bonne partie qui sera partagée entre toutes les instances s'ils sont lancés habilement ou si le système mémoire est habile. C'est à dire, 200ko de ram, à tout casser. Donc 10000 services, ça fait 2Go de ram. C'est à dire une goutte d'eau sur une machine ou tu es en mesure de lancer 10000 services, qui en aura probablement au moins 500Go. Même si tes services consomment en moyenne 10Mo de ram, ce qui est pas beaucoup, tu n'as que 2% d'overhead.
        
        Quant à la table des processus, c'est vraiment le dernier des soucis. Le code a été optimisé pour gérer des grande quantités de processus, c'est capacable de scaler très loin et tu auras d'autres problèmes bien avant ça.
        
        [^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
        
        Posté par Misc (site web personnel) le 01 décembre 2014 à 13:24. Évalué à 1.
        
        J'ai du mal m'exprimer, ce que je veux dire, c'est que la table des processus est limité à 65000 et des poussières entrées, non ? (en tout cas pid_t est un int sous la glibc, donc 32 bits, donc 2**32 entrées)
        
        Ensuite, que ça soit le dernier truc à tomber, c'est une chose, et encore une fois, je ne doute pas que d'autres trucs tombent avant. J'ai pas fait de remarques sur la taille du process, mais du containers complets, ie avec le reste des process dedans pour estimer à la louche le nombre qu'on peut imaginer lancer avec la ram disponible. Mais encore une fois, c'est de l'estimation, j'ai pas réussi à trouver grand chose.
        
        Et je présuppose aussi d'une archi ou chaque container est lancé par un service séparé, ce qui est pas forcément le cas (docker n'a pas l'air de faire ça, par exemple).
        
        Mais bon, en effet, "64k of process is enough for everybody" :)
        
        [^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
        
        Posté par claudex le 01 décembre 2014 à 14:21. Évalué à 4.
        
        Si c'est un int, c'est signé, donc c'est 2³¹. Mais sous Linux, c'est configurable, c'est lisible dans /proc/sys/kernel/pid_max (32768 chez moi). Le maximum est à 4 millions http://lxr.free-electrons.com/source/include/linux/threads.h#L27
        
        « 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: Les milieux culturels et techniques des zélateurs/détracteurs
        
        Posté par YBoy360 (site web personnel) le 01 décembre 2014 à 02:06. Évalué à 3.
        
        Merci pour cette précision, du coup je vois pas bien où s'interpose SMF. Pour moi il remplissait le rôle de l'init.
        
        Sinon Android, busybox ont aussi des init alternatifs, il s'appelle aussi init (de même que pour systemd si ma mémoire est bonne) mais sont plus simple, donc le nom de la commande n'est pas suffisant. Il y a aussi pinit, mais comme c'est français les américains le siteront jamais.
- [^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
  
  Posté par Ignatz Ledebur le 30 novembre 2014 à 16:46. Évalué à 3.
  
  Ils travaillent souvent sur des fonctionnalités destinées à la gestion des serveurs d'entreprise, à l'informatique dans les nuages, aux systèmes embarqués […] Ce sont des hackeurs, […]
  
  Ça ne me paraît pas vraiment être le profil du ubuntero de base. Je pense que l'idée c'est qu'au sein du Libre s'affrontent deux tendances, celle qui veut une autre manière d'interagir avec les ordinateurs par rapport à ce qui ce fait chez Windows/OSX et celle qui pense que le Libre peut les concurrencer et les battre sur leur propre terrain. Quelle que soit l'option qu'on préfère, il y a besoin de développeurs compétents dans les trucs poilus.
  - [^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
    
    Posté par Misc (site web personnel) le 30 novembre 2014 à 18:09. Évalué à 2.
    
    Ça me parait pas très concluant non plus comme division. Je pense qu'il y a une grande part des gens qui font de l'informatique pour leur métier, mais qui voient surtout que ça apporte des emmerdes, qu'on leur crie dessus quand ça ne marche pas, qu'on leur dit à longueur de temps qu'ils sont un cout financier, de façon direct ou indirect. La passion est peut être parti depuis longtemps, ou le temps. Et depuis quelques temps, j'ai le sentiment que l'informatique bouge de plus en plus vite, ne serais que parce qu'il y a un influx d'ingénieurs, une accélération de l'échange d'idée, et des moyens en plus.
    
    Donc il y a peut être des gens qui ont peur de pas réussir à suivre, peur de ce que ça va apporter, et le changement par nature fait peur aux gens, c'est un mécanisme ancré dans notre subconscient. Il suffit de voir que beaucoup de choses ont commencé quand un journaliste a lancé l'idée d'une apocalypse qui vient, ce qui est quand même le summum du fear mongering. De voir que ça a provoqué des réactions disproportionnés pour un sujet technique comme celui la. Et que les gens relaient des informations sans vérifier si c'est vrai ou pas ( l'exemple de systemd et des logs binaires par exemple ). Les gens répètent ce qui confortent leurs peurs pour la propager, car c'est plus rassurant de pas être seul à paniquer.
    
    Un autre exemple, le blog de iguru, totalement non fondé et basé sur des affirmations péremptoires non vérifiables, mais qui alimentent la paranoia.
    
    Ensuite, encore une fois, tout le monde rentre pas dans ce cadre, et y a plein de gens avec un avis plus mesuré, mais masqué par les autres.
    - [^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
      
      Posté par Ignatz Ledebur le 30 novembre 2014 à 18:49. Évalué à 5.
      
      Perso, je pense que la division (en très grossier) « Windows libre » vs « informatique inspirée depuis la console » est pertinente, et tiraille depuis longtemps la communauté (je l'ai toujours sentie, mais c'est toujours plus facile de sentir les choses d'un point de vue minoritaire – ce qui au passage n'implique pas que l'autre côté soit incompétent en shell, c'est juste qu'on ne l'y envisage pas comme l'interface principale du système), même si c'est seulement maintenant que ça se mue en bataille rangée.
      
      Maintenant, il est évident que l'informatique n'a plus grand chose à voir avec ce qu'elle était il y a dix ans, c'est aujourd'hui un truc vraiment énorme (il y en a vraiment partout, et ça ne va pas s'arrêter), probablement bien trop massif pour qu'il y ait quoi que ce soit de rationnel dans son évolution (probablement qu'il y a une part de simple résistance au changement, mais aussi de l'autre côté du changer pour coller au troupeau, ce qui est tout aussi humain et guère plus digne d'éloges).
      - [^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
        
        Posté par xcomcmdr le 30 novembre 2014 à 19:04. Évalué à 8.
        
        L'ensemble de l'usage et de l'administration de systemd se fait depuis la ligne de commandes, et systemd est écrit en c.
        Donc bon j'ai du mal à voir le lien entre systemd et pro Windows/desktop.
        
        C'est surtout encore à mon avis la rumeur tenace que systemd c'est pour le desktop (alors que sur desktop des trucs comme la réplication du journal ailleurs ou la détection de la virtualisation je m'en fiche un peu)
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
        
        Posté par Ignatz Ledebur le 30 novembre 2014 à 19:36. Évalué à 5.
        
        De ce que je sais, systemd vire toute la couche shell pour la remplacer par des fichiers de config, c'est un gros changement dans l'interaction avec le système.
        
        Le lien entre systemd et Windows, c'est beaucoup dû au fait qu'on ne sait pas s'il va finir par y avoir intégration au niveau des environnements de bureau. On voit déjà (cf. courriel de Lennart) que le but est d'avoir à terme une pile noyau/systemd/GNU comme base standard Linux (gérer Linux presque comme un BSD en fait), et il est encore bien difficile de savoir où ça va s'arrêter (on peut voir ça comme un problème de force de gravité, plus systemd deviendra massif dans la galaxie Linux, plus il sera pratique de se laisser reposer dessus).
        
        Et puis il ne faut pas prendre les choses à l'envers : si tu veux un Linux « Windows Libre » alors tu es favorable à systemd qui est un pas vers la bonne direction (d'où la pertinence de la division autour du desktop), mais on peut être pour systemd sans que ce soit le cas, personne ne dit le contraire (le développeur de uselessd n'est probablement pas un pro-desktop, pourtant il part sur la base de systemd).
        
        [^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
        
        Posté par xcomcmdr le 30 novembre 2014 à 19:48. Évalué à 5.
        
        Bah j'ai systemd, et j'ai toujours /etc/rc.init, mon zsh, mes coreutils gnu et mes scripts utilisateur.
        
        systemd vire uniquement la plupart des scripts de démarrage existants, mais il ne vire pas le shell (il lance même un shell de secours en cas de crash).
        
        Quand aux DEs utilisant des composants tels que systemd-logind, ça existe déjà (gnome, xfce) et c'est plus sain que d'utiliser consolekit qui n'est plus maintenue depuis des années.
        
        On est loin de Windows pourtant car dans ce dernier on ne peut pas remplacer la moindre brique.
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
        
        Posté par Anonyme le 01 décembre 2014 à 00:23. Évalué à 6.
        
        Et puis il ne faut pas prendre les choses à l'envers : si tu veux un Linux « Windows Libre » alors tu es favorable à systemd qui est un pas vers la bonne direction (d'où la pertinence de la division autour du desktop)
        
        C'est quoi un "Linux « Windows Libre »" ? Et pourquoi quelqu'un qui veut un Windows Libre serait favorable à systemd plus que quelqu'un d'autre ?
        
        Je doute que le systeme de boot utilisé par Windows ressemble à systemd. Donc j'ai vraiment du mal à voir le rapport entre Windows et systemd.
- [^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
  
  Posté par Joris Dedieu (site web personnel) le 01 décembre 2014 à 00:01. Évalué à 6.
  
  En gros, les zélateurs ils utilisent Ubuntu (mythe que systemd est pour le destkop derrière ?) et courent >après le mythe de l'année du bureau Linux, et n'aiment pas la bidouille.
  Et les détracteurs, c'est des barbus, des vrais, avec un vrai bagage technique, qui utilise Slackware, > >Gentoo, & co, et adorent hacker.
  
  C'est pas ce que je comprend. Il s'agit plutôt de différencier les anciens qui sont bien content depuis bien longtemps avec linux tel qu'il est, des modernes qui ont une vision différente et plus exigeante de ce que doit être un desktop.
  
  Il y a des gens dont je fais partie pour lesquels le montage automatique d'un volume USB n'est pas une feature nécessaire. Je trouve même ça bien gonflant. Pour d'autre gérer ses fichiers en console ou ses mails avec Mutt est juste un Moyen-Age duquel il faut sortir.
  
  De la a dire que les uns sont les détracteurs et que les autres sont les zélateurs … le débat reste ouvert
  - [^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
    
    Posté par gnumdk (site web personnel) le 01 décembre 2014 à 08:31. Évalué à 3.
    
    Et on peut aussi utiliser GNU/Linux depuis longtemps et vouloir des disques qui "s'automount"…
    - [^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
      
      Posté par Joris Dedieu (site web personnel) le 01 décembre 2014 à 09:27. Évalué à 5.
      
      Et on peut aussi utiliser GNU/Linux depuis longtemps et vouloir des disques qui "s'automount"…
      
      Oui absolument. On peut vouloir des tas de choses différentes. Et c'est justement je pense l'une des raisons profonde du débat.
      
      Pour info, je faisais référence à la querelle des anciens et des modernes.
- [^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
  
  Posté par Moonz le 01 décembre 2014 à 10:46. Évalué à 2.
  
  C’est toi qui a mal lu, il n’a pas dit que l’opposition était entre techos/desktop, mais entre deux communautés techniques. Si on devait résumer grossièrement en une phrase comme tu essaies de le faire, ce serait plutôt « pro-cathédrale » vs « pro-bazar ».
  - [^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
    
    Posté par kna le 01 décembre 2014 à 13:08. Évalué à 8.
    
    Je vois plutôt d'un côté le principe « un programme pour une tache » contre de l'autre côté une bonne intégration.
    
    Par exemple, j'ai un screen avec un mutt, un vim et un irssi. Je pourrais avoir aussi simplement un emacs qui ferait la même chose.
    Dans le premier cas, j'ai bien un programme pour une tache, mais ils ne sont pas bien intégrés ensemble. En revanche, si je préfère weechat à irssi, ou tmux à screen, je peux le remplacer et garder le reste comme tel.
    Dans le second cas, si je n'aime pas comment emacs gère l'IRC ben je ne peux pas le changer sans perdre cette intégration, mais j'ai une meilleure intégration du tout, avec mêmes couleurs et mêmes raccourcis claviers sans avoir à bidouiller les confs de X softs.
    
    On peut facilement faire un parrallèle avec d'un côté SysV+scripts+monit+inetd+cron et de l'autre Systemd. Le premier permet de remplacer n'importe qu'elle brique par une que l'on préfère, le second permet d'avoir un tout mieux intégré, avec une configuration homogène.
    
    Personnellement, je suis plutôt « un programme pour une tâche », mais je dois reconnaitre que le deuxième choix est très appréciable aussi. Alors, pour arriver à mettre tout le monde d'accord là-dessus…
    - [^] # Re: Les milieux culturels et techniques des zélateurs/détracteurs
      
      Posté par Thomas Debesse (site web personnel) le 07 décembre 2014 à 01:07. Évalué à 4.
      
      Je vois plutôt d'un côté le principe « un programme pour une tache » contre de l'autre côté une bonne intégration.
      
      Les deux ne s’opposent pas. Surtout que pour que le schéma « un programme pour une tâche » fonctionne, il faut que l’ensemble soit bien intégré.
      
      On peut facilement faire un parrallèle avec d'un côté SysV+scripts+monit+inetd+cron et de l'autre Systemd. Le premier permet de remplacer n'importe qu'elle brique par une que l'on préfère.
      
      Voilà le point important, actuellement, systemd est une suite de « un programmes pour une tâche » façon un+deux+trois+quatre mais actuellement aucun de ces programmes n’ont d’alternative.
      
      le second permet d'avoir un tout mieux intégré, avec une configuration homogène.
      
      Avoir des briques remplaçables et séparées n’empêche pas d’avoir un ensemble intégré et une configuration homogène.
      
      Avoir des briques remplaçables et séparées n’implique pas d’avoir un ensemble non-intégré et une configuration hétérogène.
      
      Par contre on pourrait écrire « le second contraint à avoir un tout correctement intégré, avec une configuration homogène », et cette contrainte coince, forcément.
      
      Personnellement, je suis plutôt « un programme pour une tâche », mais je dois reconnaitre que le deuxième choix est très appréciable aussi. Alors, pour arriver à mettre tout le monde d'accord là-dessus…
      
      Les deux ne s’opposent pas donc avec des raisonnements aussi faux, c’est sûr qu’on ne mettra personne d’accord.
      
      ce commentaire est sous licence cc by 4 et précédentes
# Merci pour les éclaircissements

Posté par rupteur le 30 novembre 2014 à 14:56. Évalué à 10.

Sacrée dépêche.
j'ai tout lu, pas tout compris (et maintenant j'ai mal à la tête).

je suis un administrateur linux que je qualifierai de "basique" et certainement pas du niveau de tous ces barbus.
j'espère juste que ces "disputes" ne déstructurerons pas cet outil fabuleux qu'est Debian (entre autre).
- [^] # Re: Merci pour les éclaircissements
  
  Posté par Pazns le 01 décembre 2014 à 00:07. Évalué à 4.
  
  Je crains qu'un dysfonctionnement de clavier a malheureusement écorché le mot "CentOS" dans ce message.
# et openrc alors ?

Posté par Neo Futur (site web personnel) le 30 novembre 2014 à 22:34. Évalué à 1.

Je m etonne que personne ne regarde les autres alternatives disponibles, et tout particulierement openRC

Un peu de lecture pour essayer d elargir le debat :
http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems

"You have enemies? Good. That means you've stood up for something in your life." Winston Churchill
- [^] # Re: et openrc alors ?
  
  Posté par Neo Futur (site web personnel) le 01 décembre 2014 à 00:38. Évalué à 1.
  
  voire aussi http://www.infoworld.com/article/2608870/linux/you-have-your-windows-in-my-linux.html
  
  "You have enemies? Good. That means you've stood up for something in your life." Winston Churchill
# La Cathédrale et le Bazar

Posté par Pazns le 01 décembre 2014 à 00:01. Évalué à 5.

Est-ce ici une manifestation de La Cathédrale et Le Bazar, en quelque sorte ?

Est-ce que systemd ne se comporterait pas sur certains aspects "contre" le chaos qui apprécie régir le monde linuxien ?
- [^] # Re: La Cathédrale et le Bazar
  
  Posté par Neo Futur (site web personnel) le 01 décembre 2014 à 00:42. Évalué à 3.
  
  Tout a fait !
  J hesitai aussi a citer
  https://fr.wikipedia.org/wiki/La_Cath%C3%A9drale_et_le_Bazar
  
  Je pense qu on est clairement dans ce schema d opposition entre deux modeles, deux philosophies, et que la question est beaucoup plus d ordre philosophique, politique, moral, que technique.
  
  "You have enemies? Good. That means you've stood up for something in your life." Winston Churchill
# tout a fait

Posté par Neo Futur (site web personnel) le 01 décembre 2014 à 00:41. Évalué à 0. Dernière modification le 01 décembre 2014 à 00:44.

Tout a fait !
J hesitai aussi a citer
https://fr.wikipedia.org/wiki/La_Cath%C3%A9drale_et_le_Bazar

Je pense qu on est clairement dans ce schema d opposition entre deux modeles, deux philosophies, et que la question est beaucoup plus d ordre philosophique, politique, moral, que technique.

( oups, desole pour le double post , j ai reposte en reponse a "la cathedrale et le bazaar", veuillez ignorer ce double post que je n arrive pas a supprimer )

"You have enemies? Good. That means you've stood up for something in your life." Winston Churchill
# Unification

Posté par patrick_g (site web personnel) le 01 décembre 2014 à 09:54. Évalué à 10. Dernière modification le 01 décembre 2014 à 09:55.

En tout dernier lieu, la cruelle ironie est que systemd, dans sa tentative de supposément unifier les distributions, a créé comme aucun autre un immense fossé

Il me semble que cette phrase est complètement fausse.
Depuis plusieurs années il y a de multiples alternatives à sysvinit qui sont apparues mais aucune d'elles n'a pu rallier les suffrages et s'imposer largement. C'est ça le vrai succès de systemd : être arrivé à rallier toutes les distros qui comptent (Fedora+RHEL+CentOS, OpenSUSE+SLES, Arch, Ubuntu, Debian, Mageia, etc). Maintenant on partage les services entre les distros au lieu de faire du boulot redondant chacun dans son coin.

Compte tenu de cette adoption généralisée, dire que systemd a échoué à unifier le monde des distros Linux et a créé un "immense fossé" est vraiment absurde.
Ce qui est vrai c'est que l'adoption de systemd par la plupart des distributions Linux a suscité des débats passionnés. Mais ce sont la plupart du temps des débats entre utilisateurs. Si on regarde du côté des mainteneurs des distros alors le succès unificateur de systemd est indéniable.
- [^] # Re: Unification
  
  Posté par wolowizard le 01 décembre 2014 à 10:55. Évalué à 2.
  
  Je suis un gros noob en systemd
  
  Maintenant on partage les services entre les distros au lieu de faire du boulot redondant chacun dans son coin.
  
  Est-ce vrai ? Je veux dire par là, même si la logique de systemd cherche unifier les services
  ( http://0pointer.de/blog/projects/on-etc-sysinit.html ), est-ce le cas en pratique à l'heure actuelle? Peut-on faire un "copy-paste" des units entre Fedora et Gentoo par exemple pour un service donné?
  - [^] # Re: Unification
    
    Posté par gnumdk (site web personnel) le 01 décembre 2014 à 11:02. Évalué à 5.
    
    C'est mieux que ça, les fichiers d'init sont de plus en plus distribués directement avec le logiciel donc ce sont déjà les mêmes entre distribs…
# Les raisons du fork

Posté par cluxter le 01 décembre 2014 à 10:57. Évalué à -2.

L'écriture de ceci m'a été inspirée par les annonces récentes réclamant publiquement un fork de Debian, une idée que je trouve idiote et qui ne débouchera probablement pas sur énormément de travail technique.

Par pitié, arrêtez avec ça. Ce fork n'est pas à cause de 'systemd'. Tout comme le départ de plusieurs développeurs Debian ces dernières semaines.

Cette volonté de forker vient du fait que les leaders de Debian ont voté contre l'obligation de maintenir les paquets comme 'gnome' ou 'kde' compatibles avec 'sysvinit'. Cela implique que 'gnome' ne pourra plus être utilisé sans 'systemd', ce qui impose donc de fait un système de démarrage, au détriment de tous ceux qui ont besoin pour une raison ou pour une autre d'utiliser 'sysvinit' (utiliser un noyau UNIX par exemple, et ça me semble être une très bonne raison).

Que 'systemd' soit dans les dépôts de Debian malgré sa philosophie anti UNIX et son code discutable, c'est une chose. Et à vrai dire c'est supportable du moment qu'on nous laisse la liberté de choisir un autre système de démarrage dans les dépôts.

Or c'est précisément cette liberté qui a été refusée aux administrateurs systèmes du monde entier, en dépit de leurs (nombreux) appels de détresse, mais surtout à l'encontre du pacte social qui a fait de Debian sa réputation.

Voilà pourquoi il a été décidé de forker Debian. C'est un problème de liberté et de confiance rompue. Pas de code.
- [^] # Re: Les raisons du fork
  
  Posté par gnumdk (site web personnel) le 01 décembre 2014 à 11:04. Évalué à 1.
  
  sa philosophie anti UNIX
  
  précisément cette liberté qui a été refusée
  
  La liberté qui ne t'es pas refusée, c'est de lire la doc, de réfléchir et d'arrêter de ressortir les phrase idiote que tu as lu sur le web sans brancher le cerveau…
  
  Philosophie anti UNIX, de mieux en mieux…
  - [^] # Re: Les raisons du fork
    
    Posté par cluxter le 01 décembre 2014 à 11:07. Évalué à 1.
    
    Ce qui ne change absolument rien aux raisons du fork. Ma phrase n'est pas plus idiote que celle que j'ai citée.
    - [^] # Re: Les raisons du fork
      
      Posté par Pazns le 01 décembre 2014 à 11:42. Évalué à 2. Dernière modification le 01 décembre 2014 à 11:45.
      
      Elle ne l'est pas moins non plus.
      
      En passant, je trouve ça curieux de dire qu'on a refusé une liberté aux débianistes ou je ne sais quoi, alors même que j'entends régulièrement des échos sur la relative autocratie qui règne dans la tête de certains patrons de cette communauté.
      Des impressions injustifiées, peut-être, je n'en sais rien, en tout cas je m'interroge sérieusement…
- [^] # Re: Les raisons du fork
  
  Posté par patrick_g (site web personnel) le 01 décembre 2014 à 11:27. Évalué à 10.
  
  Cette volonté de forker vient du fait que les leaders de Debian ont voté
  
  Ce ne sont pas les "leaders" de Debian qui ont voté (comme si la décision venait "d'en haut"). Ce sont tous les développeurs Debian, ceux qui "font" la distro, qui ont pu participer au vote.
  
  ont voté contre l'obligation de maintenir les paquets comme 'gnome' ou 'kde' compatibles avec 'sysvinit'.
  
  Autrement dit contre l'obligation, imposé à d'autres, de faire un travail de maintien de compatibilité ad vitam aeternam.
  Si tu souhaites que cette compatibilité perdure ce sera à toi de proposer des patchs et à t'investir dans ce travail. Les autres développeurs ne sont pas à tes ordres et ne sont pas tenus à fournir un travail afin de répondre à tes besoins particuliers.
  En revanche ils ont déjà signalé qu'ils accepteraient volontiers les patchs de ceux qui veulent continuer à utiliser exclusivement sysvinit.
- [^] # Re: Les raisons du fork
  
  Posté par claudex le 01 décembre 2014 à 11:28. Évalué à 10.
  
  Cela implique que 'gnome' ne pourra plus être utilisé sans 'systemd',
  
  Pas du tout, ça veut dire que si personne ne fait le boulot, gnome ne pourra pas être utilisé sans systemd. Si l'obligation avait été faite, gnome aurait été retirée de la prochaine version de Debian (l'alternative est que quelqu'un aurait bosser à retirer la dépendance à systemd mais vu que personne n'est motivé, je doute qu'il y aurait eu assez de main d'œuvre).
  
  Mais si le but était d'avoir gnome sans systemd, il fallait se mettre à bosser il y a des mois, quand cette dépendance est arrivée dans Gnome, pas vouloir forcer les mainteneurs à bosser gratuitement pour soi des mois après la nouvelle.
  
  « 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: Les raisons du fork
  
  Posté par Misc (site web personnel) le 01 décembre 2014 à 11:49. Évalué à 10.
  
  Que 'systemd' soit dans les dépôts de Debian malgré sa
  philosophie anti UNIX et son code discutable,
  
  Tu peux détailler ce que tu veux dire par "code discutable" ? Car à chaque fois que les gens disent ça, j'ai le sentiment que c'est juste pour trainer dans la boue le projet. Pour une raison inconnue, les gens estiment que pour systemd, la barre doit être plus haute que pour tout le reste, y compris le noyau.
  
  Exemple, les devs refusent des patchs, c'est des gros dictateurs. Linus le fait, c'est un génie qui défend sa vision sans la moindre erreur. Les critiques sont systématiquement sur Lennart, même quand c'est GKH qui pousse kdbus. Le design est examiné en détail, alors que tout le monde se fout du reste.
  
  Donc j'ai quand même le sentiment que les gens répètent des trucs sans se justifier, juste pour convaincre d'autre personnes qui n'ont pas les compétences pour juger.
  
  En général, quand je dit ça, les gens sortent le bugzilla de freedesktop, sans prendre la peine de donner des chiffres pour comparer le nombre de bugs par rapport à d'autres projets, ou donne les CVE, pareil sans donner de chiffres moyens.
  
  Et pour cause, car si on regarde la mise à jour d'un paquet du kernel, on voit que les CVE et les bugs sont la et sont corrigé, donc donner des chiffres ne serait pas vraiment productif, sauf à dire "le kernel aussi est buggué", ce qui entrainerais un blocage. Donc plutôt que de parler de chiffres en bon ingénieur, on utilise un argument d'autorité, et on ressasse sans arrêt sans se remettre en cause.
- [^] # Re: Les raisons du fork
  
  Posté par Zenitram (site web personnel) le 01 décembre 2014 à 12:21. Évalué à 0. Dernière modification le 01 décembre 2014 à 12:22.
  
  Cette volonté de forker vient du fait que les leaders de Debian ont voté contre l'obligation de maintenir les paquets comme 'gnome' ou 'kde' compatibles avec 'sysvinit'.
  
  obligation != possibilité.
  Merci, tu viens de démontrer en un mot toute la partie faux-cul de ceux qui veulent forker. Sérieux, si ils ne sont pas prêt à faire le nécessaire pour proposer la possiblité dans Debian, tu crois vraiment qu'ils vont passer du temps à maintenir une distro complète?
  
  J'attend la démonstration de l'interdiction que Debian ferait à des gens qui proposent un paquet alternatif non dépendant de systemd. J'ai eu l'impression de l'opposé (qu'ils acceptaient si quelqu'un se bougeait le cul à la place de dire, et juste dire, qu'il vont forker).
  
  Zut alors, les gens ont la liberté de refuser de s'obliger à faire un truc dont ils n'ont pas besoin eux et demandent à ceux qui en ont besoin de le faire. Comme quoi, on n'a pas la même notion de liberté, ta liberté à toi est comment dire… Pas très libre.
  
  philosophie anti UNIX
  
  Conneries.
# Ou bien ?

Posté par reynum (site web personnel) le 01 décembre 2014 à 14:48. Évalué à 4.

Ou peut-être pas. Peut-être que les choses vont continuer comme d'habitude suivant une spirale infinie de réinventions sans climax. Peut-être serons-nous condamnés à nous déchirer sur systemd pour toute l'éternité. Peut-être finalement nous en dégoûterons-nous et poursuivrons-nous nos propres chemins dans des directions différentes.

Ou bien les développeurs de systemd tiendront compte des remarques techniquement sensées des détracteurs et améliorerons l'architecture pour faire (encore plus) consensus dans la communauté ?
L'espoir fait vivre ;-)

kentoc'h mervel eget bezan saotred
- [^] # Re: Ou bien ?
  
  Posté par Prosper le 01 décembre 2014 à 15:08. Évalué à 2.
  
  des remarques techniquement sensées
  
  Encore faudrait-il qu'il y en ai :)
  - [^] # Re: Ou bien ?
    
    Posté par reynum (site web personnel) le 01 décembre 2014 à 15:51. Évalué à 3.
    
    D'après ce que j'en ai retenu il y aurait deux choses :
    Réduire l'empreinte mémoire du pid 1 ainsi que le caractère intrusif (omniprésent).
    
    la modularité de systemd n'est pas aussi étendue qu'elle pourrait l'être et que son PID 1 demeure quoi qu'il en soit plus gros que dans la plupart des autres systèmes.
    
    systemd s'immisce dans tous mes logiciels
    
    kentoc'h mervel eget bezan saotred
  - [^] # Re: Ou bien ?
    
    Posté par Misc (site web personnel) le 01 décembre 2014 à 15:53. Évalué à 3.
    
    Y en a parfois, c'est juste que c'est masqué sous le FUD et les commentaires sans remarques, et du peu que j'ai réussi à trouver, ce sont pas tant des améliorations que des tradeoffs différents.
    
    En pratique, ils prennent déjà en compte la communauté, sinon, ça serait pas adopté et il n'y aurait pas des patchs. Ensuite quand la remarque ça deviens "je pense qu'il faut tout refaire le logiciel parce que j'accorde plus d'importance à ce point qu'à ce point la", tu peux pas satisfaire tout le monde.
  - [^] # Re: Ou bien ?
    
    Posté par Christophe le 01 décembre 2014 à 16:34. Évalué à 3.
    
    La "dépendance" sur dbus en est une, actuellement en cours de résolution avec kdbus.
    Le lien fort avec la glibc est quand même réductrice, à mon avis.
    Les frontières floues du projet n'aident pas à rassurer (certes ce n'est pas un point technique).
    Une complexification de l'outil d'init toujours grandissante: à chaque option rajoutée dans un .conf, c'est un potentiel bug dans l'outil gérant cette option. Ce problème a son pendant dans les autres inits bien sûr, mais le bug était dans les scripts (donc décentralisé, donc potentiellement moins fatal à l'init).
    
    Ce sont des remarques techniquement sensées, pointant des choix conscients faits par le projet systemd. Pour certains, ce sont des inconvénients, pour d'autres des atouts. Il n'y a pas grand chose à dire là-dessus: soit on l'accepte, soit on revient 4 ans en arrière…
- [^] # Re: Ou bien ?
  
  Posté par Enj0lras le 01 décembre 2014 à 16:52. Évalué à 6.
  
  Le problème c'est que « remarque sensée » c'est profondément sujectif.
  Je connais des développeurs si tu leur parles de format binaire pour conserver des logs, ils vont te regarder comme si tu avais proposé de fixer un réacteur à un panier de légumes rempli de carottes et monté sur roulettes que tu placerait devant un âne attelé à ton vélo, pour le faire avancer.
  - [^] # Re: Ou bien ?
    
    Posté par GnunuX (site web personnel) le 01 décembre 2014 à 19:26. Évalué à 5.
    
    Je connais des développeurs si tu leur parles de format binaire pour conserver des logs
    
    Sérieux ?
    
    J'ai l'impression que c'est souvent l'inverse qu'on voit de nos jours. Je ne compte plus les projets des gestions de logs utilisant elasticsearch, xapian ou autres.
    
    Sans parlait du fait que la plupart des logs sont conservés sous forme compressé (donc binaire).
# Une résistance, mais pas de combat.

Posté par Pseudo007 le 01 décembre 2014 à 16:51. Évalué à 2.

De toute manière c'est trop tard. Depuis le début de systemd c'est trop tard.
Systemd (ou un équivalent qui tient la route) est nécessaire.
- [^] # Re: Une résistance, mais pas de combat.
  
  Posté par anaseto le 01 décembre 2014 à 17:54. Évalué à 4.
  
  Les arguments techniques à teneur subjective d'un côté comme d'un autre, c'est déjà amusant, mais les phrases fatalistes de ce genre… ça tient presque de la prophétie et du destin ;)
- [^] # Re: Une résistance, mais pas de combat.
  
  Posté par Neo Futur (site web personnel) le 01 décembre 2014 à 18:53. Évalué à 0.
  
  il n est en aucun cas trop tard, comme le dit http://www.infoworld.com/article/2608870/linux/you-have-your-windows-in-my-linux.html
  
  "The rest of us who run big Linux-based services and application stacks on CentOS and RHEL were possibly derelict in not speaking out about our disdain for systemd before these developments came to pass. But it's not too late to speak out."
  
  de nombreuses pointures ont encore a s exprimer sur le sujet et le debianfork nonsystemd est tres actif.
  
  pour ne parler que de l irc 355 personnes sur #debianfork et presque autant sur #devuan
  
  si une evolution de sysvinit est plus ou moins necessaire, d autres solutions que systemd sont envisageable, dont openrc qui fonctionne deja tres bien en prod sur gentoo et qui est maintenu meme dans debian https://qa.debian.org/developer.php?login=openrc-devel@lists.alioth.debian.org
  
  les vieux barbus, gardiens de la philosophie unix ou chaque brique fait correctement son boutot, n ont en aucun cas dit leur dernier mot.
  
  "You have enemies? Good. That means you've stood up for something in your life." Winston Churchill
  - [^] # Re: Une résistance, mais pas de combat.
    
    Posté par HanX (site web personnel) le 01 décembre 2014 à 23:20. Évalué à -4.
    
    Les alternatives stables sont là… Un des gros soucis avec systemd c'est qu'il remplace petit à petit des composants essentiels entre autre crons, logind, timedated, localed, hostnamed… Ceci est imposé notamment par gnome, il va falloir recoder des choses qui fonctionnaient très bien jusqu'à maintenant. Quelle tristesse.
    - [^] # Re: Une résistance, mais pas de combat.
      
      Posté par Zenitram (site web personnel) le 02 décembre 2014 à 00:03. Évalué à 0. Dernière modification le 02 décembre 2014 à 00:04.
      
      C'est surtout triste que des "libristes" puissent parler de choses imposées, peut-être n'ont-ils pas compris ce qu'est le libre (non, le libre n'est pas de cracher sur les autres qui se bougent, mais de se bouger si la direction ne plait pas et montrer qu'on a une meilleure vision. pour le moment la vision est "ne rien changer et regarder les autres évoluer", super sexy…).
      
      PERSONNE n'impose rien à personne, tout le monde est LIBRE de choisir. Mais dommage, cette liberté est aussi données aux autres.
      
      Dur la liberté… Qu'on insulte on disant que c'est imposé quand les gens usent de leurs libertés et ne font pas ce qu'on veut du coup. Pauvre libre (et liberté en général, ça marche pour plein d'autres cas où les gens n'aiment pas la liberté quand ce n'est pas la leur)
      - [^] # Re: Une résistance, mais pas de combat.
        
        Posté par HanX (site web personnel) le 02 décembre 2014 à 09:56. Évalué à 1.
        
        "PERSONNE n'impose rien à personne, tout le monde est LIBRE de choisir. Mais dommage, cette liberté est aussi données aux autres."
        
        Je ne suis pas d'accord avec toi. Systemd impose de lourds changements chez tout le monde… à commencer par ceux qui n'ont rien demandé : les BSD. Est-ce normal pour toi qu'ils doivent rajouter des API de compatibilité ? Alors qu'ils n'ont strictement rien à voir. Il y a des modifs dans le kernels, système d'authentification (gnome)… etc.
        
        Qu'est-ce qu'a apporté de bien systemd ? Du troll, des forks, du temps perdu pour tout le monde… Tous ces soucis montrent bien un réel problème (qu'on soit pour ou contre). Ma seule opinion (partagée par 90% de ceux qui ne veulent pas de systemd) : "laissez nous le choix de l'utiliser ou non". Il est techniquement possible de se passer de systemd dans Debian Jessie, mais on est vite limité…
        
        [^] # Re: Une résistance, mais pas de combat.
        
        Posté par Spyhawk le 02 décembre 2014 à 10:19. Évalué à 5. Dernière modification le 02 décembre 2014 à 10:21.
        
        Qu'est-ce qu'a apporté de bien systemd ? Du troll, des forks, du temps perdu pour tout le monde…
        
        Avant tout chez Debian, hein. Pour ceux qui y sont déjà passé, c'est du temps de gagné, du code à maintenir en moins, des utilisateurs déjà formés/déjà habitués (parce que y'a que Debian qui trainnasse pendant 3 ans). Et parmi les utilisateurs qui râlaient, y'en aucun qui s'est sorti les pouces du c*l pour travailler à maintenir l'alternative sysv, preuve que c'est pas si indispensable que ça, surtout quand on doit mettre la main à la pâte.
        
        Pour les BSD, tu te trompes de cible: crache plutôt ton venin sur Gnome et consort, ce sont eux les responsables.
        
        [^] # Re: Une résistance, mais pas de combat.
        
        Posté par Moonz le 02 décembre 2014 à 10:39. Évalué à 1.
        
        Et parmi les utilisateurs qui râlaient, y'en aucun qui s'est sorti les pouces du c*l pour travailler à maintenir l'alternative sysv
        
        https://linuxfr.org/news/pourquoi-les-zelateurs-et-detracteurs-de-systemd-ne-s-entendront-jamais#%C3%89crire-une-alternative
        
        [^] # Re: Une résistance, mais pas de combat.
        
        Posté par Spyhawk le 02 décembre 2014 à 10:52. Évalué à 4.
        
        Note que je ne parle même pas d'écrire une alternative, mais de se bouger les fesses pour maintenir les codes existants, comme proposé par debian qui accepte toutes contributions pour garder sysvinit fonctionnel.
        
        [^] # Re: Une résistance, mais pas de combat.
        
        Posté par Moonz le 02 décembre 2014 à 15:35. Évalué à 1.
        
        Exactement les mêmes arguments s’appliquent, que l’alternative s’appelle sysvinit ou openrc.
        
        [^] # Re: Une résistance, mais pas de combat.
        
        Posté par Spyhawk le 02 décembre 2014 à 16:40. Évalué à 4.
        
        Je ne vois pas où tu veux en venir. Il n'y a rien à écrire, il n'y a qu'à maintenir l'existant parce que les mainteneurs qui faisaient un certain boulot décident de ne plus s'emmerder à le faire, et que si ceux qui en profitaient avant veulent toujours profiter de ce même travail, ben ils n'ont qu'à le faire eux-même.
        
        Le problème chez Debian, c'est qu'elle se revendique plus ou moins comme une "démocratie au service de l'utilisateur", ou qu'elle est vue en tant que telle par une partie de ses utilisateurs. Y'a effectivement une recherche de consensus sur différents sujets, mais tant que les mainteneurs ne seront pas des esclaves, Debian est et restera une do-ocratie comme toutes les autres distrib communautaires.
        
        [^] # Re: Une résistance, mais pas de combat.
        
        Posté par whity le 02 décembre 2014 à 10:44. Évalué à 8.
        
        Je ne suis pas d'accord avec toi. Systemd impose de lourds changements chez tout le monde… à commencer par ceux qui n'ont rien demandé : les BSD. Est-ce normal pour toi qu'ils doivent rajouter des API de compatibilité ? Alors qu'ils n'ont strictement rien à voir. Il y a des modifs dans le kernels, système d'authentification (gnome)… etc.
        
        Raté, c’est pas systemd qui impose quoique ce soit, c’est gnome (et d’autres).
        
        Les dev de gnome ont estimé que c’était plus simple pour eux d’utiliser les APIs de systemd plutôt que de se carrer la gestion de n systèmes différents, que ça réduisait leur quantité de code à maintenir, et qu’en plus, c’était plus modulaire car ça permettait à tous les systèmes d’être compatibles (du moins, dès qu’ils peuvent faire tourner dbus, ce qui est le cas de tous les systèmes sur lesquels gnome tourne), via des APIs de compatibilité, et pas seulement ceux que eux (gnome) maintenaient.
        
        Au final, grâce à systemd, gnome devient théoriquement portable sur plus de systèmes :trollface:
        
        Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
    - [^] # Re: Une résistance, mais pas de combat.
      
      Posté par Neo Futur (site web personnel) le 02 décembre 2014 à 00:47. Évalué à 1.
      
      c est tout a fait ca, bien au dela su simple syteme d init, probablement au coeur du probleme, un detail tres bien resume par cette image : http://gw.gd/sdmonster
      
      par contre "il va falloir recoder des choses qui fonctionnaient très bien" . . . ou juste les maintenir, tout comme trinity maintient le fork de kde3 ou comme je maintiens toujours mon fork personnel de punbb 1.2.* ?
      
      "You have enemies? Good. That means you've stood up for something in your life." Winston Churchill
  - [^] # Re: Une résistance, mais pas de combat.
    
    Posté par Thomas Debesse (site web personnel) le 07 décembre 2014 à 01:33. Évalué à 2.
    
    pour ne parler que de l irc 355 personnes sur #debianfork et presque autant sur #devuan
    
    Et les dépôts dorment. Bref, beaucoup de gens qui parlent beaucoup, mais qui ne font rien. Actuellement, seules 5 personnes ont commité quelque chose dans les dépôts devuan (Denis “Jaromil” Roio (Dyne), Franco “nextime” Lanza, “max2344”, “hellekin” (Dyne), rt Matteo “rfc1459” Panella).
    
    les vieux barbus, gardiens de la philosophie unix ou chaque brique fait correctement son boutot
    
    Le mythe de la philosophie unix est des briques a été démonté depuis bien longtemps.
    
    Seule nouveauté dans tes paroles : le “correctement” qui est à prouver.
    
    ce commentaire est sous licence cc by 4 et précédentes
# D'où l'importance de n'en avoir rien à faire

Posté par omer666 le 02 décembre 2014 à 18:21. Évalué à 9.

Je pense qu'au point où on en est, systemd est tout à fait utilisable au quotidien, et les alternatives à systemd comme OpenRC ou upstart (si toutefois quelqu'un veut bien encore s'en occuper) sont tout à fait au point, et ce depuis un bon moment déjà.

Il me paraît donc logique de dire qu'il est urgent de ne plus en avoir quoi que ce soit à faire de tout ce tintamarre qui nous divise et crée plus de frustrations et d'insultes gratuites que de véritable avancées techniques ou philosophiques. Hors, c'est bien ce qu'est censé nous apporter tout débat constructif qui se respecte. Je pense que s'il y a plusieurs systèmes d'init pour permettre plusieurs expériences utilisateur ou administrateur, eh bien nous ne nous en porterons que mieux. Mais arrêtons de créer de faux problèmes en imposant des points de vue, autant dans un sens que dans l'autre, et encourageons autant le développement de systemd que celui des autres inits. S'il y a des alternatives intéressantes, alors il y aura des distributions pour les adopter, il n'y a donc aucune raison de continuer de crier au loup.

Suivre le flux des commentaires

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