Alors après, l'existant c'est un paquet de spaghetti hétéroclite immonde, mais avec des années et des années de polissage derrière. On sait très bien que quand un mec arrive en disant qu'il va tout régler d'un coup, on va se prendre des systèmes cassés pendant des lustres. Peut-être qu'il était tant, mais bon, non, ça n'a pas été fait de manière « modulaire » itérative, comme on aurait pu remplacer petit à petit les outils.
Ah, tu veux dire rester compatible avec les scripts SysV par exemple? Oh wait…
Je ne vois pas ce qu’il y a de mal, systemd est en quelque sortes une couche d’abstraction du noyau;
Ah ouai, carrément ?
Bah pour une partie de l’espace utilisateur.
normal qu’il empêche les autres programmes de mettre le bazar et qu’il donne des API pour les programmes externes. Et la hiérarchie a l’air plutôt propre comme ça.
Heu… Lennart ne trouvait pas ça « normal » à priori avant, vu que c'est comme ça que c'était depuis un bout de temps. Et donc maintenant, les cgroup ça doit appartenir à systemd et c'est tout point ; voilà un système coopératif…
Bah ils ont trouvé que c’était mieux, donc ils ont changé.
Alors après, ils ont étudié les solutions et c'est à priori la meilleure, mais alors qu'on ne se targue pas de se la jouer « à la UNIX » : non, tu fais différemment ; et bien assume-le.
Je ne vois pas ce qui est fondamentalement «pas Unix». D’ailleurs tout ne tourne pas autour d’Unix. Le but est de savoir si ça fonctionne bien, si c’est utile, si c’est flexible, si c’est efficace, pas de respecter les principes Unix sans réfléchir.
Et bien maintenant tu as un mainteneur tête de nœuds pour la base d'une partie énorme de ton système. Pour caricaturer UNIX, les « haters » disaient que l'auteur de "head" n'était pas le même que celui de "tail" (et c'est vrai !) ; c'est un peu extrême, mais ça a toujours été comme ça que ça se passe. Les projets avec un mono-maniaque qui décide d'une partie énorme de ton système, ça craint. Torvalds est visé du coup, mais disons que lui fait plus « consensus », si on peut dire.
Non seulement en citant Linus tu viens de contrer ton premier argument (genre Linus n’a jamais déclenché de polémiques, et parmi les développeurs de distributions il semble plutôt faire consensus).
D’autre part, pour réagir à ton «ça a toujours été comme ça», je te conseille de lire ceci. «ça a toujours été comme ça» est un des pires arguments qui existent.
Non c’est pas hypocrite, c’est les autres projets qui sont venus se greffer à systemd, pas le contraire.
Heu… ça fait un peu « parain de la mafia » comme remarque…
Est-ce que c’est un argument? systemd n’a pas forcé GNOME à utiliser exclusivement les API systemd. systemd n’a pas forcé les développeurs udev à les rejoindre.
Il n’y a jamais eu de XML dans systemd, et même s’il y en avait le XML c’est pas un truc maléfique hein.
Je parlais des communications par dbus. Choses que l'utilisateur ne voit pas, mais quand tu écris un soft et que tu veux communiquer avec le démon « système » maintenant, tu dois te palucher du XML.
Dbus c’est pas des commandes? Qu’est-ce que ça peut te faire que derrière dbus utilise du XML?
Et genre les «petits bénévoles» avant ils modifiaient SysV ou Upstart? Non. De la même façon, les «petits bénévoles» ne vont pas faire de grosses modifications au cœur de Firefox.
Nan mais tu as pris la grosse tête comme Lennart ? Moi j'ai écrit des scripts SysV pour des softs, oui, et je me permet d'aller voir dans le code que je veux, quand il est pas trop mal fait.
Pourquoi dis-tu que Lennart a la grosse tête? Par ailleurs je parlais de modifier le système d’init pas de créer un script SysV/une unité systemd; c’est plus facile de créer une unité systemd pour quelqu’un qui ne connait pas la programmation, qu’un script Bash…
En pratique c’est plus compliqué que ça, mais les développeurs d’udev n’ont pas été forcé de travailler avec les gens de systemd hein… Et je trouve ça plutôt bien qu’il y ait de la collaboration (même si du coup c’est dommage que ça soit plus compliqué de faire tourner udev sans systemd).
Par ailleurs, je remercie les Belges et les Suisses pour septante, octante et nonante qui sont quand même plus logiques que leurs contreparties made in France.
Ça marche quand même vachement les dérivés en français pour les français.
vêtement: vestimentaire;
forêt: forestier;
fête: festif;
bête: bestial;
hôpital: hospitalier;
hôtel: ah bah non pour celui-ci ça marche pas. Et en fait hôtel pour devenir hotel et hôte pourrait devenir hote — à moins que l’on veuille conserver la proximité entre hôtel, hôte et hôpital qui ont tous la même racine.
more 10-mount.rules
polkit.addRule (function (a,s) {
if (a.id.indexOf ('org.freedesktop.udisks2.') == 0 && s.isInGroup(plugdev))
return polkit.Result.YES;
});
less is more. Utilise plutôt:
less 10-mount.rules
En effet, dans le manuel de less, on peut lire:
Less is a program similar to more (1), but which allows backward movement in the file as well as forward movement. Also, less does not have to read the entire input file before starting, so with large input files it starts up faster than text editors like vi (1).
Ou alors tu peux aussi utiliser most, parce que most is more than less. :p Plus d’infos
Avant (il y a très très très longtemps hein) on disait couster, hospital, forest. On a cessé de le prononcer de cette façon, mais on a quand même mis un accent pour la prononciation et pour dire que quand même il y avait un s avant.
D’ailleurs si vous pouviez éviter de supposer que tout le monde est sur Debian en citant un nom de méta-paquet hors contexte ça serait quand même vachement sympa pour ceux qui lisent. Je dis ça sans méchanceté hein, ça arrive à tout le monde.
Je sais pas ce qu’ils font chez Debian, KDE peut fonctionner sans Network-manager (et sans systemd). Par contre c’est marrant je viens de voir que le paquet Arch qt5-base dépend de systemd, étrange.
systemd est constitué de plus de 70 binaires (NdT : 72 sur ma machine !) clairement séparés.
Qui ont leur propres standards d'options et ne réutilisent pas l'existant. Être modulaire, c'est une chose, mais généralement quand on dit ça c'est qu'on interagit bien avec le reste de l'écosystème. Ça va dans le sens du « il faut tout réapprendre », qui peut parfois être nécessaire, certes, mais là c'est vraiment « on refait tout sans utiliser l'existant ». > Pourquoi pas, mais de là à se vanter de séparer ses modules et de se dire modulaire au sens d'UNIX… Busybox fait ça, de manière un peu moins « je remplace tout » puisqu'il remplace tout, mais avec des commandes qui respectent scrupuleusement la syntaxe de celles d'origine.
Quel existant? Plein de commandes de systemd n’existaient pas avant. En plus avec ces commandes peuvent facilement être utilisées dans des scripts par exemple.
Ou alors tu parles de SysV ou de l’init à la BSD d’Arch, et à ce moment-là c’est un peu con parce que justement un des buts de systemd c’était d’éliminer le code Bash exécuté au démarrage; à moins que tu ne parles d’Upstart qui a une conception très différente de systemd.
Du coup je ne comprends pas trop ce que tu reproches à systemd, est-ce que tu pourrais être plus précis?
Par exemple, l’idée d’UNIX du « tout est fichier » trouve son jumeau dans systemd où tous les services sont exposés au lancement dans un système de fichiers du noyau, le cgroupfs.
Dommage, cette idée vient d'être foutue en l'air pour les prochaines version de systemd, cf http://lists.freedesktop.org/archives/systemd-devel/2013-June/011521.html : tout devra passer par l'API dbus désormais. On pourra éventuellement, pour la lecture, passer par cgroupfs, mais je vous laisse déguster la syntaxe de la nouvelle hiérarchie (la compatibilité ascendante c'est pour les nuls), par exemple ici présentée dans le projet libvirt : http://libvirt.org/cgroups.html
Je ne vois pas ce qu’il y a de mal, systemd est en quelque sortes une couche d’abstraction du noyau; normal qu’il empêche les autres programmes de mettre le bazar et qu’il donne des API pour les programmes externes. Et la hiérarchie a l’air plutôt propre comme ça.
Ensuite, la façon dont notre projet est géré (c'est-à-dire maintenir la majeure partie du cœur de l’OS dans un unique dépôt git) est plus proche du modèle BSD (qui est un vrai UNIX, pas comme Linux) dans la façon de faire (où la plus grande partie du cœur de l’OS est conservé dans un seul répertoire CVS/SVN) que de la façon de faire de Linux.
Ça, effectivement, c'est quelque chose de vraiment embêtant je trouve.
En quoi?
systemd n’est pas la mafia. C’est un logiciel libre, vous pouvez en faire ce que vous voulez, ce qui inclut ne pas l’utiliser. C’est plutôt l’opposé de « forcer ».
C'est tellement hypocrite… les devs du kernel ont même fait des rustines spéciales pour udev, c'est dire s'ils n'ont pas été « forcés ».
Non c’est pas hypocrite, c’est les autres projets qui sont venus se greffer à systemd, pas le contraire.
Un but de systemd est d’unifier un peu le paysage dispersé de Linux. Nous essayons de nous débarrasser de beaucoup des différences inutiles entre distributions dans différents domaines du cœur de l’OS.
Voilà, ça c'est plus honnête. J'aimerais bien que les devs avouent juste ça : on veut essayer de faire une nouvelle « API » de l'OS, devenir la nouvelle couche d'abstraction des services (voire plus), et ça sera forcément moins UNIX que l'était System V (franchement, du XML c'est pas très UNIX…).
Il n’y a jamais eu de XML dans systemd, et même s’il y en avait le XML c’est pas un truc maléfique hein.
Encore une fois, pourquoi pas, mais il faut arrêter de jouer les vierges effarouchées quand on vous le renvoie dans la figure.
Bah systemd propose de nouvelles API et les gens les utilisent, c’est tout.
Faux, vous pouvez désactiver et remplacer à peu près n’importe quel bout de systemd, à de très rares exceptions près.
Sauf que systemd couvre tellement de choses qu'il est impossible pour des libristes bénévoles d'espérer rattraper ça.
Avant ils faisaient comment avec SysV et tout?
Après, c'est peut-être ça l'avenir du Libre : ça devient plus professionnel, et les petits bénévoles ne pourront plus suivre le développement des composants au cœur du système. Je ne sais pas si c'est un bien ou un mal.
Et genre les «petits bénévoles» avant ils modifiaient SysV ou Upstart? Non. De la même façon, les «petits bénévoles» ne vont pas faire de grosses modifications au cœur de Firefox.
Mais il reste beaucoup de petits projets qui manquent de bras aussi.
L’architecture de systemd ne change pas tous les quatre matins (et j’ai ajouté une note quand une donnée chiffrée avait changé, ou alors c’est précisé que c’était à la date de la publication de l’article).
complètement objectifs, sans parti pris,
Au moins on sait de quoi ça vient, et je pense qu’un développeur de systemd, de surcroit son développeur originel et principal payé pour bosser dessus sait à peu près comment il fonctionne.
et dans certains cas, notamment celui-ci, c'est hideux.
Et si je te dis que je trouve que coûter c’est hideux, on fait quoi?
Si j’écris de cette façon, c’est parce que je trouve ça plus logique et plus simple: si on peut justement l’accent circonflexe dans forêt ou hôpital parce qu’on dit forestier et hospitalier, quelle justification peut-on trouver pour coûter?
Et tout ce qu’on me répond c’est «c’est moche». Nan mais à ce moment-là la prochaine fois qu’on me parle de GNOME Shell je n’argumenterais pas, je dirais juste «c’est moche».
C'est plus subtile. C'est dans le pid 1 pour les fichiers de root, et dans le pid du gestionnaire de session pour les fichiers accessibles par l'utilisateur ( ie, sous l'uid de l'utilisateur ). Donc je pense que si tu peux écrire le fichier, alors c'est déjà trop tard, pas besoin d'exploiter une erreur dans le parser. Non pas que ça veuille dire "on s'en fout de la sécurité", mais que le fait de faire l'analyse du fichier dans un process à part avec un canal de communication avec le pid 1 est une complication qui n'a pas jugé valoir la chandelle pour le moment.
En plus, utiliser un format simple et standard, ça permet de limiter fortement les anomalies.
J'ai cherché justement après avoir posté ça, apparament ça n'a pas été mergé, mais il y avait un début de code. J'espère juste simplement qu'ils vont ajouter cette fonctionnalité (parce que c'est une bonne idée) mais qu'ils vont se baser sur l'existant, notament kmscon.
kmscon n’a rien à voir avec systemd à la base, c’est pour remplacer les tty tout moisi. C’est une console virtuelle qui utilise KMS, XKB donc les dispositions de claviers de X.org, UTF-8 et tout, prise en charge du multi-siège et plein de trucs cool comme ça. Donc en gros ça sera plus moderne et ça uniformisera le fonctionnement de certains trucs avec X.org/Wayland (notamment KMS et le fonctionnement du clavier).
Sinon utilise un shell Python, c’est vachement pratique, on a accès à des trucs genre oct() et bin(), des variables, et à peu près tout ce dont on peut avoir besoin.
Bof, Mousepad n’a même pas de coloration syntaxique, or à l’heure actuelle je ne vois pas l’intérêt d’un éditeur de texte sans cette fonctionnalité (je prend mes notes en Markdown ou en reStructuredText).
Et donc on aurait plus d’applications multiplateformes… Et les applications Qt se fondent mieux dans GNOME (enfin un peu moins depuis GNOME 3) et Xfce sans rien faire que les applications GTK en appliquant un thème spécifique que les développeurs sont obligés de refaire tous les trois jours parce qu’un développeur GTK 3 a cassé la comptabilité des thèmes.
Bien que je n'irais pas jusqu'à dire que systemd est monolithique (je pense que ça s'apparente de plus en plus à un OS à la BSD, ce qui n'est pas une critique), je pense que ça va un peu loin.
En effet, je dirais que systemd n'est pas moins sécurisé qu'autre chose, mais de là à dire qu'il a été concu selon le modèle séparation des privilèges, il y a un pas (énorme). Exemple : le code qui parse les units s'execute en root, et il est privilégié. Ce qui augmente énormément la surface d'attaque;
Sans vouloir remettre ta parole en doute, source? De plus, les scripts SysV étaient exécutés par root non? (vrai question)
Je ne suis pas sûr de ça du tout. En tout cas, la courbe d'apprentissage est très élevée. > Je pense qu'un logiciel simple c'est un logiciel qui fournit un petit nombre d'objets simples qui peuvent être composés simplement pour obtenir des choses complexes. C'est le cas de vi, c'est le cas du shell.
CE qui n'est pas le cas de systemd du tout. Je prendrais un exemple simple, d'une option aléatoire :
IgnoreOnIsolate= AllowIsolate= IgnoreOnSnapshot=
L'utilisateur doit retenir plusieurs options. Un langage plus user friendly ne fournirait les commandes Ignore et allow qui seraient composable avec les événements Isolate et snaphots.
Ce qui rendrait le langage bien plus compliqué pour un gain à peu près nul, alors que là c’est TRÈS facile à analyser, en plus c’est un format standard de fait pour la configuration des logiciels. En plus il est facile de savoir si un script est faux, alors que si on commence à faire de la composition c’est déjà bien plus difficile. Là on a un nombre déterminé de champs que l’on maitrise parfaitement.
Quelle mauvaise foi ! Recode une bibliothèque dhcp alors qu'il en existe des 10aines ? Recoder un émulateur de terminal alors qu'il en existe des dizaines ? Si ce n'est pas du NIH, je ne sais pas comment ils appellent ça.
Pour la bibliothèque DHCP je ne sais pas, mais depuis quand systemd contient un émulateur de terminal?
Je ne rentrerais pas sur la polémique "les gens qui affirment ça sont des intégristes religieux", mais je ne reprendrais ce que j'ai dit un peu plus haut. Unix on dit souvent que c'est "tout est fichier". Ce qui est bien à cela c'est que l'OS fournit des commandes basiques pour s'occuper de fichiers. Et ils fournit un outil formidable pour composer ces commandes et obtenir des operations complexes. Le shell. Alors après, le shell est vieilli, je ne suis pas un fanatique du shell, je suis totatlement ouvert à autre chose. Mais encore une fois, "composer des operations simples" c'est ça unix. Le pipe a été une invention majeure dans la création d'unix. Et je trouve que systemd ne respecte pas vraiment ce principe.
Pourtant, les multiples unités de systemd qui peuvent être chacune activées ou désactivées indépendamment des autres (sauf dépendance entre deux unités bien sûr), il est beaucoup plus facile de désactiver certaines opérations qui auparavant faisaient partie du cœur du système d’init. Et grâce aux outils en ligne de commande on peut récupérer plus d’infos qu’avant, plus facilement et les traiter via la ligne de commande, les tubes tout ça. :)
Comme BSD ne veut pas d'un système non portable et qui reinvente pleins de bibliothèques présentes dans le systeme de base, on peut faire un tel systeme et dire que de toute façon il ne le veulent pas.
Admettons. Il y a une certaine logique à cela :). personnellement je pense que certains BSD n'auraient pas craché sur un nouvel init simple qui fait du monitoring et du démarage parallele.
Ils ne sont pas et n’ont jamais été intéressé par systemd, et ne le serait pas s’il était portable d’après tout ce que j’ai pu lire.
Quant au NIH, encore une fois, j’attends une preuve un peu plus convaincante qu’en affirmation en l’air.
[^] # Re: Correction
Posté par ariasuni . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 1.
Ah d’accord je viens de comprendre.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: À mon tour
Posté par ariasuni . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 5.
C’est normal que les textes que tu cites soient coupés à à peu près 80 caractères?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: À mon tour
Posté par ariasuni . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 5.
Ah, tu veux dire rester compatible avec les scripts SysV par exemple? Oh wait…
Bah pour une partie de l’espace utilisateur.
Bah ils ont trouvé que c’était mieux, donc ils ont changé.
Je ne vois pas ce qui est fondamentalement «pas Unix». D’ailleurs tout ne tourne pas autour d’Unix. Le but est de savoir si ça fonctionne bien, si c’est utile, si c’est flexible, si c’est efficace, pas de respecter les principes Unix sans réfléchir.
Non seulement en citant Linus tu viens de contrer ton premier argument (genre Linus n’a jamais déclenché de polémiques, et parmi les développeurs de distributions il semble plutôt faire consensus).
D’autre part, pour réagir à ton «ça a toujours été comme ça», je te conseille de lire ceci. «ça a toujours été comme ça» est un des pires arguments qui existent.
Est-ce que c’est un argument? systemd n’a pas forcé GNOME à utiliser exclusivement les API systemd. systemd n’a pas forcé les développeurs udev à les rejoindre.
Dbus c’est pas des commandes? Qu’est-ce que ça peut te faire que derrière dbus utilise du XML?
Pourquoi dis-tu que Lennart a la grosse tête? Par ailleurs je parlais de modifier le système d’init pas de créer un script SysV/une unité systemd; c’est plus facile de créer une unité systemd pour quelqu’un qui ne connait pas la programmation, qu’un script Bash…
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par ariasuni . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 0.
Bah l’un n’exclue pas l’autre.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Portabilité et forçage
Posté par ariasuni . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 6.
Nan mais sérieusement, vous pouvez pas discuter deux secondes sans chier sur la gueule de systemd?
Et donc, ça tue des bébés chatons?
Pourquoi cette limitation arbitraire? Est-ce que ça a causé un problème jusque là? Parce que là ça ressemble un peu à du pinaillage quand même.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Portabilité et forçage
Posté par ariasuni . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 1.
En pratique c’est plus compliqué que ça, mais les développeurs d’udev n’ont pas été forcé de travailler avec les gens de systemd hein… Et je trouve ça plutôt bien qu’il y ait de la collaboration (même si du coup c’est dommage que ça soit plus compliqué de faire tourner udev sans systemd).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Portabilité et forçage
Posté par ariasuni . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 3.
Pourquoi tant de haine envers Red Hat?
Argumentaire d’un développeur d’Arch Linux.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par ariasuni . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 3.
Je ne peux que plussoyer.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par ariasuni . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 2.
Ça marche quand même vachement les dérivés en français pour les français.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Petit retour d'expérience
Posté par ariasuni . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 4.
less is more. Utilise plutôt:
En effet, dans le manuel de less, on peut lire:
Ou alors tu peux aussi utiliser most, parce que most is more than less. :p Plus d’infos
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Calcul
Posté par ariasuni . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 0.
Ça a sûrement dû évoluer depuis. Mais je ne sais absolument pas comment récupérer l’information (je pourrais demander à Lennart lui-même).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Petit retour d'expérience
Posté par ariasuni . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 4.
Je n’ai plus le problème depuis un moment, mais si ça persiste tu peux éditer
/etc/systemd/logind.confet y ajouter la ligneHandleLidSwitch=no.À part ça, je n’ai jamais eu de problèmes de ce type avec systemd, pourtant j’utilise systemd depuis que c’est dispo sur Arch en gros.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par ariasuni . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 2.
Avant (il y a très très très longtemps hein) on disait couster, hospital, forest. On a cessé de le prononcer de cette façon, mais on a quand même mis un accent pour la prononciation et pour dire que quand même il y avait un s avant.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Portabilité et forçage
Posté par ariasuni . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 7. Dernière modification le 13 juin 2014 à 16:27.
D’ailleurs si vous pouviez éviter de supposer que tout le monde est sur Debian en citant un nom de méta-paquet hors contexte ça serait quand même vachement sympa pour ceux qui lisent. Je dis ça sans méchanceté hein, ça arrive à tout le monde.
Je sais pas ce qu’ils font chez Debian, KDE peut fonctionner sans Network-manager (et sans systemd). Par contre c’est marrant je viens de voir que le paquet Arch
qt5-basedépend de systemd, étrange.Écrit en Bépo selon l’orthographe de 1990
[^] # Re: À mon tour
Posté par ariasuni . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 0.
Quel existant? Plein de commandes de systemd n’existaient pas avant. En plus avec ces commandes peuvent facilement être utilisées dans des scripts par exemple.
Ou alors tu parles de SysV ou de l’init à la BSD d’Arch, et à ce moment-là c’est un peu con parce que justement un des buts de systemd c’était d’éliminer le code Bash exécuté au démarrage; à moins que tu ne parles d’Upstart qui a une conception très différente de systemd.
Du coup je ne comprends pas trop ce que tu reproches à systemd, est-ce que tu pourrais être plus précis?
Je ne vois pas ce qu’il y a de mal, systemd est en quelque sortes une couche d’abstraction du noyau; normal qu’il empêche les autres programmes de mettre le bazar et qu’il donne des API pour les programmes externes. Et la hiérarchie a l’air plutôt propre comme ça.
En quoi?
Non c’est pas hypocrite, c’est les autres projets qui sont venus se greffer à systemd, pas le contraire.
Il n’y a jamais eu de XML dans systemd, et même s’il y en avait le XML c’est pas un truc maléfique hein.
Bah systemd propose de nouvelles API et les gens les utilisent, c’est tout.
Avant ils faisaient comment avec SysV et tout?
Et genre les «petits bénévoles» avant ils modifiaient SysV ou Upstart? Non. De la même façon, les «petits bénévoles» ne vont pas faire de grosses modifications au cœur de Firefox.
Mais il reste beaucoup de petits projets qui manquent de bras aussi.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: OK, merci pour la traduction
Posté par ariasuni . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 7.
L’architecture de systemd ne change pas tous les quatre matins (et j’ai ajouté une note quand une donnée chiffrée avait changé, ou alors c’est précisé que c’était à la date de la publication de l’article).
Au moins on sait de quoi ça vient, et je pense qu’un développeur de systemd, de surcroit son développeur originel et principal payé pour bosser dessus sait à peu près comment il fonctionne.
On est trolldi sur trollfr après tout.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Quel joli troll !
Posté par ariasuni . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 2.
Donc seulement sous Debian/Ubuntu et c’est un peu de la bidouille quand même non?
Ok j’ai peut-être exagéré, mais ça a l’air vachement bien. :)
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Portabilité et forçage
Posté par ariasuni . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 4.
Pas KDE en tout cas. Et je pense qu’Enlightment peut s’en passer et fonctionner très bien sans mais à confirmer.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par ariasuni . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 3.
Donc c’est une orthographe valide.
Et si je te dis que je trouve que coûter c’est hideux, on fait quoi?
Si j’écris de cette façon, c’est parce que je trouve ça plus logique et plus simple: si on peut justement l’accent circonflexe dans forêt ou hôpital parce qu’on dit forestier et hospitalier, quelle justification peut-on trouver pour coûter?
Et tout ce qu’on me répond c’est «c’est moche». Nan mais à ce moment-là la prochaine fois qu’on me parle de GNOME Shell je n’argumenterais pas, je dirais juste «c’est moche».
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Quel joli troll !
Posté par ariasuni . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 5.
En plus, utiliser un format simple et standard, ça permet de limiter fortement les anomalies.
kmscon n’a rien à voir avec systemd à la base, c’est pour remplacer les tty tout moisi. C’est une console virtuelle qui utilise KMS, XKB donc les dispositions de claviers de X.org, UTF-8 et tout, prise en charge du multi-siège et plein de trucs cool comme ça. Donc en gros ça sera plus moderne et ça uniformisera le fonctionnement de certains trucs avec X.org/Wayland (notamment KMS et le fonctionnement du clavier).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par ariasuni . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 2.
couter. (cf. ma signature :P)
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Un truc que j'aime bien avec KDE
Posté par ariasuni . En réponse au journal De Xfce à KDE, merci Gnome.... Évalué à 4.
Sinon utilise un shell Python, c’est vachement pratique, on a accès à des trucs genre
oct()etbin(), des variables, et à peu près tout ce dont on peut avoir besoin.Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Je souscris
Posté par ariasuni . En réponse au journal De Xfce à KDE, merci Gnome.... Évalué à 2.
Bof, Mousepad n’a même pas de coloration syntaxique, or à l’heure actuelle je ne vois pas l’intérêt d’un éditeur de texte sans cette fonctionnalité (je prend mes notes en Markdown ou en reStructuredText).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: GNOME et le gestionnaire de fenêtre
Posté par ariasuni . En réponse au journal De Xfce à KDE, merci Gnome.... Évalué à 3.
Et donc on aurait plus d’applications multiplateformes… Et les applications Qt se fondent mieux dans GNOME (enfin un peu moins depuis GNOME 3) et Xfce sans rien faire que les applications GTK en appliquant un thème spécifique que les développeurs sont obligés de refaire tous les trois jours parce qu’un développeur GTK 3 a cassé la comptabilité des thèmes.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Quel joli troll !
Posté par ariasuni . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 5.
Sans vouloir remettre ta parole en doute, source? De plus, les scripts SysV étaient exécutés par root non? (vrai question)
Ce qui rendrait le langage bien plus compliqué pour un gain à peu près nul, alors que là c’est TRÈS facile à analyser, en plus c’est un format standard de fait pour la configuration des logiciels. En plus il est facile de savoir si un script est faux, alors que si on commence à faire de la composition c’est déjà bien plus difficile. Là on a un nombre déterminé de champs que l’on maitrise parfaitement.
Pour la bibliothèque DHCP je ne sais pas, mais depuis quand systemd contient un émulateur de terminal?
Pourtant, les multiples unités de systemd qui peuvent être chacune activées ou désactivées indépendamment des autres (sauf dépendance entre deux unités bien sûr), il est beaucoup plus facile de désactiver certaines opérations qui auparavant faisaient partie du cœur du système d’init. Et grâce aux outils en ligne de commande on peut récupérer plus d’infos qu’avant, plus facilement et les traiter via la ligne de commande, les tubes tout ça. :)
Ils ne sont pas et n’ont jamais été intéressé par systemd, et ne le serait pas s’il était portable d’après tout ce que j’ai pu lire.
Quant au NIH, encore une fois, j’attends une preuve un peu plus convaincante qu’en affirmation en l’air.
Écrit en Bépo selon l’orthographe de 1990