L’annonce est passée inaperçue, mais udev est intégré depuis avril 2012 dans les sources de systemd. Les deux projets sont amenés à fusionner. Désormais, c’est systemd qui fournit le logiciel udev. Ce dernier est toujours utilisable indépendamment, mais son avenir est fixé. Les récentes déclarations de Lennart Poettering ont provoqué une salve de critique et même un fork de udev.
D’après Wikipédia, udev est « un gestionnaire de périphériques remplaçant devfs sur les noyaux Linux de la série 2.6. Sa fonction principale est de gérer les périphériques dans le répertoire /dev. udev s’exécute en mode utilisateur et dialogue avec hotplug qui, lui, s’exécute en mode noyau. »
Toujours d’après Wikipédia, systemd est « un remplaçant du démon init system V pour Linux. Il a pour but d’offrir une meilleure infrastructure pour la gestion des dépendances entre services, de permettre le chargement en parallèle des services au démarrage, et de réduire la surcharge du shell. systemd est un projet initié par Lennart Poettering en 2010 et publié sous licence GNU LGPL en version 2.1. Le nom de ce programme vient de « system daemon » : le daemon du système et fait aussi référence au “système D”. »
Sommaire
- Objectifs de systemd
- Les événements, tous les événements
- La position des distributions
- Pourquoi intégrer udev ?
- Situation de udev et systemd
- Le fork de udev
- Conclusion
L’intégration de udev surprend beaucoup, car il est un élément central et quasi universel des distributions GNU/Linux. Vue l’importance de l’affect dans les discussions sur systemd, cela vaut la peine de présenter systemd tel qu’il se présente lui‐même. La partie suivante est tirée des différents articles de vulgarisation rédigés par Lennart Poettering.
Objectifs de systemd
systemd est le PID 1. C’est‐à‐dire le premier processus lancé par le noyau, dont l’objectif est de « démarrer l’espace utilisateur ». Historiquement, le PID 1 est init de Système V qui se contente de lancer séquentiellement une liste déterminée de programmes. Contrairement à upstart, systemd n’a pas été pensé comme un remplaçant d’init, mais plutôt comme une solution à une problématique renouvelée par l’état actuel de l’informatique.
Dès les débuts de systemd, le cadre posé est : comment démarrer l’espace utilisateur de manière rapide et efficace dans un système changeant ?
Les événements, tous les événements
La question n’est plus tellement lancer des scripts au démarrage, mais : lancer, arrêter, relancer des logiciels pour répondre à des événements logiciels ou matériels, depuis le démarrage jusqu’à l’arrêt du système.
Ces événements ce sont : le démarrage lui‐même, le montage d’un volume, la connexion à un port ou une socket, l’heure actuelle, l’interrogation d’une interface D-Bus, la connexion/déconnexion d’un utilisateur, mais aussi l’ajout ou le retrait d’un périphérique à chaud ou à froid.
Par exemple, au lieu d’attendre que tous les volumes de /etc/fstab soient montés (et contrôlés avec fsck si besoin), on monte le système de fichiers uniquement lorsqu’un service y accède. À l’instar d’autofs, systemd intercepte les appels à open pour déclencher le montage d’un volume à la demande. Ou encore, systemd écoute lui‐même sur le socket, pour ne lancer le service réel qu’à la première requête client. C’est ce que fait déjà inetd.
En somme, systemd factorise une mécanique de lancement d’un service suite à un événement. Cette mécanique était souvent déjà implémentée dans divers logiciels existants : (x)inetd, upstart, autofs, cron, udev, mais aussi supervisord et d’autres. systemd unifie une problématique commune autour d’une seule solution.
La position des distributions
Outre Fedora qui adopte la solution de son poulain depuis Fedora 15, systemd semble bien accueilli par les distributions. Mandriva, Mageia, OpenSUSE, FrugalWare et Arch Linux sont également passées à systemd.
La question est plutôt : « Qui n’est pas passé à systemd ? » En premier lieu, Debian, qui se pose sérieusement la question, mais avec calme. Mais surtout LFS et Gentoo, qui affichent plutôt un refus de systemd.
Pourquoi intégrer udev ?
systemd est un init « hotplug ». Pour cela, il réutilise le code de udev gérant l’interaction avec hotplug. La logique de gestion du cycle de vie d’un périphérique est intégrée dans systemd. Or, udev est un service lancé par systemd. Cela créait des problèmes de dépendances circulaires à la compilation et des allers‐retours incessants entre les deux services à l’exécution.
Situation de udev et systemd
systemd poursuit la numérotation de version de udev, en passant de la version 45 à la version 184. udev est toujours utilisable indépendamment de systemd, mais son développement est minimal. D’où la fameuse phrase de Lennart :
Yes, udev on non-systemd systems is in our eyes a dead end, in case you haven’t noticed it yet. I am looking forward to the day when we can drop that support entirely.
Ce qui signifie, dans la langue de Molière :
Oui, udev sur les systèmes non systemd est à nos yeux une impasse, au cas où vous ne l’auriez pas encore remarqué. J’attends le jour où nous pourrons complètement abandonner cette prise en charge.
De quoi échauder plus d’un utilisateur attaché à udev. Comme certains l’étaient sans doute du vénérable devfs.
Le fork de udev
LFS n’est pas satisfait de l’intégration de udev dans systemd. En effet, pour compiler uniquement udev, on doit télécharger tout systemd et ses dépendances. Un problème de système de compilation résolu par LFS avec un patch ajoutant une option UDEV_ONLY.
Finalement, un fork complet de udev a été réalisé à partir de la version 189 de systemd. L’objectif est uniquement de sortir udev des sources de systemd. On peut le voir sur la page GitHub de braindamaged.
Conclusion
Ce fork a peu d’importance en soi. Il montre une certaine exaspération devant le manque d’intérêt des développeurs de systemd à faciliter la vie des utilisateurs conservateurs.
Aller plus loin
- Annonce sur de l’intégration de udev dans systemd linux-hotplug (125 clics)
- Journal de Sygne sur LFS et systemd (150 clics)
- Journal de neil sur le fork de udev (181 clics)
- Dépôt du fork de udev (79 clics)
- Évolutions techniques de systemd (dépêche de novembre 2011 sur LinuxFr) (108 clics)
# Refus de systemd chez Gentoo ?
Posté par navaati . Évalué à 10.
Pas si sûr : bien sûr que les devs ne veulent pas de systemd comme init par défaut, puisqu'ils ont développé avec amour leur propre init : OpenRC.
Par contre systemd a été très tôt disponible sur gentoo, et un certain nombre de gentooïstes y sont passés avec joie.
# rc
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
systemd n'est pas un remplaçant à init, mais à init et rc. Traditionnellement, c'est init qui est le premier processus, et qui lance ce qu'il faut selon l'inittab. Parmi ce qu'il doit lancer : rc, qui sert à démarrer la plupart des processus. init ne lance lui-même que peu de processus, en somme, et contrairement à rc, il les gère entièrement et peut les relancer s'ils s'arrêtent.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: rc
Posté par Yth (Mastodon) . Évalué à 9.
Ben non, systemd n'est pas un remplaçant de udev, il utilise udev, et il l'utilise tellement qu'ils ont décidés de mettre les sources de udev dans celles de systemd…
Ou alors j'ai rien compris ?
Parce que si ils ont mis les sources de udev dans celles de systemd, mais qu'ils remplacent udev, en intégrant le code directement dans systemd, on va très rapidement voir disparaître udev en tant que tel. Ce qui d'ailleurs risque fort de se produire, présenté comme ça, ça paraît l'évolution logique.
Et donc le fork de udev deviendrait une nécessité - la branche source ayant alors disparue - puisque c'est un outil foncièrement utile en dehors de systemd…
Yth.
# Le lancement des tty (les terminaux virtuels)
Posté par Sylvain Blandel . Évalué à 10.
Un exemple de ce mécanisme, que j'ai constaté sous Archlinux : le lancement des tty (les terminaux virtuels).
Lors du démarrage du système, le tty1 est lancé. En revanche, les tty[2-6] ne sont pas lancés. Le tty2 ne sera lancé que lorsque l'utilisateur appuiera sur les touches
Ctrl+Alt+F2. De même, Le tty3 ne sera lancé que lorsque l'utilisateur appuiera sur les touchesCtrl+Alt+F3. Et pareil pour les autres.C'est le comportement par défaut, du moins sous Archlinux. Je n'ai pas cherché, mais j'imagine que c'est configurable.
[^] # Re: Le lancement des tty (les terminaux virtuels)
Posté par Sylvain Blandel . Évalué à 5.
Effectivement, c'est configurable. Voir le site de systemd :
# La conclusion
Posté par Jar Jar Binks (site web personnel) . Évalué à 10.
C’est quoi un “utilisateur conservateur” ? C’est donc assumé, il y a des gens dont le seul but dans la vie c’est de changer le moins de choses possible ?
Pourquoi ne pourrait-on pas se poser sereinement la question de la meilleure architecture pour un système Linux ? Le fait qu’un outil soit proposé par un gros con (restons objectifs) n’en fait pas une mauvaise idée, loin de là. Et le fait qu’udev, qui est le cœur de l’interface entre userland et kernel, ne soit pas dans le PID 1, c’est un problème conceptuel en soi.
[^] # Re: La conclusion
Posté par reno . Évalué à 10.
Euh je dirais même que c'est la majorité des gens.
Ça te plairait qu'on te change le format des prises électriques? Utiliser un volant différent? Etc..
La plupart des gens préfèrent conserver l'existant à moins que la nouveauté apporte un intérêt.
Je n'ai jamais vu de discussion sereine sur ce sujet malheureusement, rien que quand je remarque que PowerShell me paraît une évolution intéressante du shell ça part en vrille
;-)
Ça c'est de l'argument! Tu ne peux pas faire plus clair parce que là je ne vois pas..
[^] # Re: La conclusion
Posté par gnumdk (site web personnel) . Évalué à 10.
Arrête, Linuxfr c'est le repère des gens qui savent mieux que les devs de projets upstream comment architecturer un logiciel et qui sont tellement fort qu'ils préfèrent garder leur science pour eux plutôt que de contribuer.
[^] # Re: La conclusion
Posté par Argon . Évalué à 10.
Pour moi la seule conclusion qui s'impose est que l'un ne remplace pas l'autre et qu'il est imbécile de vouloir le faire.
Init répond à une problématique simple, permettre de lancer des services simplement, les uns à la suite des autres en faisant appel à de petites applications multiples mais efficace, en outre les scripts sont simples à modifier.
Systemd répond à une autre problématique, comment gérer les multiples services qui sont ammenés à être démarrer, stoper, redémarrer avec toutes les dépendances que ça implique.
On ne doit pas mettre en concurrence les deux logiciels parce que les systèmes informatiques équipés d'une distribution Linux sont tous différent et que l'utilisation de l'un ou de l'autre se fera en fonction des besoins. Je pense que toutes les distributions devraient continuer à maintenir les deux systèmes. Et je dirais même plus les distributions devraient proposer l'un ou l'autre à l'installation comme certaines le font pour grub/syslinux/lilo ou encore gnome/kde/fce, etc…
de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité
[^] # Re: La conclusion
Posté par navaati . Évalué à 6.
Ben gars, j'en ai lu des trolls sur systemd, des tonnes, et tu viens de pondre un des trucs les plus pertinents que j'ai jamais vu.
[^] # Re: La conclusion
Posté par Argon . Évalué à 7.
Merci ! Mais t'inquiètes, je réserve aussi une autre intervention pour pulseaudio la prochaine fois :D
de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité
[^] # Re: La conclusion
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Tu ne parles pas d'init mais de rc.
[^] # Re: La conclusion
Posté par Argon . Évalué à 2.
Oui pardon je fais parfois des raccourci un peu facile !
de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité
[^] # Re: La conclusion
Posté par coïn . Évalué à 6.
Bof, je pense que c'est hors de portée de 99% des distro vu la somme de travail que ca représente, et avec un intérêt aussi faible.
[^] # Re: La conclusion
Posté par Misc (site web personnel) . Évalué à 10.
C'est surtout qu'il y a toujours du monde pour dire "faudrait faire" et plus personne pour dire "j'ai fait ça".
[^] # Re: La conclusion
Posté par Thom (site web personnel) . Évalué à 4.
Il y a quand même des conditions assez importantes pour ça.
- Savoir le faire du point de vu programmation
- Savoir bien le faire
- Savoir le maintenir
Bref, ce n'est pas donné à tous les utilisateurs. Et tous les utilisateurs n'ont pas à savoir le faire.
Sur une voiture c'est pareil, pour ajouter un porte bagage, un autoradio, ça va.
Mais si tu veux changer ton pot… tu vas chez le garagiste.
Personnellement, je me sers de linux pour mon quotidien car je fais pas mal d'analyses numériques… mais je suis bien incapable de faire un truc comme ça… et, je dis truc, car je ne saurais même pas par où commencer.
La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick
[^] # Re: La conclusion
Posté par cosmocat . Évalué à 5.
Les utilisateurs que tu décris (tout le monde lorsqu'il est pas dans son domaine de prédilection,donc…), ben, justement, je pense pas que leur avis ait une chance d'être pertinent!
Si tu ne sais pas changer ton pot de voiture, tu ne vas pas dire au garagiste de quelle manière il faudrait le faire, non!?!
[^] # Re: La conclusion
Posté par liberforce (site web personnel) . Évalué à 2.
Transposition au suffrage universel, toussa…
[^] # Re: La conclusion
Posté par oao . Évalué à 4.
Oui, transposons : je suis heureux que l'on ne vote pas la façon dont un pot d'échappement doit être changé !
[^] # Re: La conclusion
Posté par modr123 . Évalué à -3.
si tu fais pas certains truc sur ta voitures c'est que tu n'as pas le materiel qui faut mais changer un pot ça doit etre facile……
[^] # Re: La conclusion
Posté par moi1392 . Évalué à 5.
Si je n'ai pas d'autre choix que d'aller chez mon garagiste pour changer mon pot de voiture, c'est qu'il y a un problème de conception de ma voiture.
Par contre, je peux décider d'aller chez mon garagiste changer mon pot car c'est plus pratique, simple, je trouve préfère payer le prix que de m'embêter à le faire moi même, …
Mais quand je transpose ça au problème systemd, ce que j'en pense c'est qu'il doit être possible de faire ce que l'on veut (c'est une des choses que j'aime le moins dans les logiciels et systèmes non libres), et que c'est mieux si c'est simple à faire, et c'est ce dernier point qu'il est important de discuter.
[^] # Re: La conclusion
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 9.
Bah, ne vous en faites pas, ce boulot sera fait pour Debian. Du moins, si systemd y reste, c'est à dire s'il y a quelqu'un pour le maintenir, ce qui est le cas actuellement. SysV init restera forcément, c'est le seul à tourner sur Debian GNU/kFreeBSD.
[^] # Re: La conclusion
Posté par Argon . Évalué à 1.
Pour quelle raison ? Il me semble que le but de systemd est d'avoir un système de démarrage identique sur toutes les distributions. Quand à SystemVinit il est déjà là et je ne pense pas que les scripts changent tous les 4 matins. Mais je me fais peut-être des films sur la maintenance de systemd/SystemVinit.
de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité
[^] # Re: La conclusion
Posté par Patrick Lamaizière (site web personnel) . Évalué à 2. Dernière modification le 06 septembre 2012 à 18:06.
distributions linux, on parle de Debian avec un noyau FreeBSD là.
(edit: mea culpa,je me suis gourré dans les fils)
les pixels au peuple !
[^] # Re: La conclusion
Posté par coïn . Évalué à 5.
Vrai question.
A part pour la "preuve de concept", Debian/FreeBSD c'est vraiment utilisé dans la vrai vie ?
Parce que debian a su à un moment faire le tri dans les archis pour gagner en rapidité, alors virer cet abomination qu'est Debian/FreeBSD me parait une pas mauvaise idée.
[^] # Re: La conclusion
Posté par gnumdk (site web personnel) . Évalué à 3.
Wai par les linuxiens à qui FreeBSD fait peur…
[^] # Re: La conclusion
Posté par Etienne Bagnoud (site web personnel) . Évalué à 6.
Ceux qui veulent Packet Filter ou ZFS et préfèrent la gestion des paquets Debian au système de port de FreeBSD. Je n'aime pas le système de port de FreeBSD et j'utilise FreeBSD, Debian GNU/kFreeBSD est la réponse (bien que je n'ai pas encore passé mes FreeBSD à Debian GNU/kFreeBSD, c'est dans mes projets).
De plus l'équivalent à ZFS sous Linux est BTRFS, mais il n'est pas encore en version stable.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: La conclusion
Posté par Prosper . Évalué à 3.
Et puis surtout il est loin d'avoir les fonctionnalités de ZFS :/
[^] # Re: La conclusion
Posté par Zenitram (site web personnel) . Évalué à 0.
C'est sympa de te dévouer à la tâche, ta candidature est acceptée sur les centaines de distros à maintenir.
[^] # Re: La conclusion
Posté par Argon . Évalué à 2.
Je ne comprend pas ta remarque. Systemd est un logiciel qui est conçu pour être identique sur chaque système installé, quand il est dispo dans une distribution il est packagé par les mainteneurs de la distribution comme n'importe quel logiciel. Pour les scripts rc ils sont souvent spécifique pour chaque distribution. Je ne vois pas vraiment la difficulté de maintenance ? Mais si tu as un début de réponse je veux bien que tu m'expliques.
de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité
[^] # Re: La conclusion
Posté par gnumdk (site web personnel) . Évalué à 3.
Ben, si les distribs passent à systemd, c'est pour ne plus avoir à se prendre la tête avec cela dans l'avenir… Après, je pense pas que sysvinit va disparaître de ArchLinux par exemple, il sera dans Community au mieux, dans Aur au pire…
Il y'aura juste un paquet sysvinit-rcs avec tous les scripts de la distrib à l'arrache comme c'était le cas pour systemd avant que Arch commence la migration.
Bon bien sur, c'est dans le cas ou y'a vraiment des gens que ca motive de le maintenir.
[^] # Re: La conclusion
Posté par Argon . Évalué à 2.
En fait ma question c'est plutôt : Est-ce difficile à maintenir pour un développeur ? Comme je l'ai dit je ne pense pas que les scripts rc soient modifier tous les 4 matins. Je n'ai pas souvenir sur Debian ou sur Archlinux par exemple voir passer des modifications importantes des script rc.
Voilà c'est vraiment un question que je me pose, après tout je me fait peut-être des idées sur la fréquence de maintenance.
de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité
[^] # Re: La conclusion
Posté par DerekSagan . Évalué à 4.
En fait la spécificité de choisir init+rc ou systemd par rapport à un logiciel ordinaire et qu'il faut modifier tous les packages de tous les démons de la distrib parce que ça change la façon de les configurer pour qu'il démarre tout seuls (j'allais dire selon le runlevel, mais parlant de systemd c'est à la limite du troll).
Et pire, comme justement le modèle diffère un peu (runlevel contre événements, pour faire simple) c'est hyper chiant de gérer en double.
[^] # Re: La conclusion
Posté par liberforce (site web personnel) . Évalué à 6.
Et après on se demande pourquoi systemd c'est bien… Peut être pour lancer lesdits service en parallèle, sans avoir à gérer les dépendances dans les scripts ? Gérer du chargement à la demande, ce qui permet d'économiser des ressources ? Ne pas lancer n instances de shell ? Les seuls à avoir une bonne raison de gueuler, c'est les admins dont les habitudes changent, et les *BSD qui de toute façon queulaient déjà parce que udev était spécifique à Linux. Mais qu'on ne vienne pas me dire que techniquement, systemd est juste différent de ce qui se faisait. C'est pas juste différent, c'est surtout plus performant !
Cool. C'est toi qui files un coup de main pour la maintenance ?
[^] # Re: La conclusion
Posté par Argon . Évalué à 2.
Je n'ai pas mentionné performant parce que je n'ai pas suffisamment d'expertise la dedans pour dire si il l'est. Et donc je me garde bien de l'écrire.
Tout le monde me dit ça mais pourquoi les distributions continuent à packager lilo, BURG, par exemple ? Pourtant ils exigent de la maintenance aussi.
de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité
[^] # Re: La conclusion
Posté par gnumdk (site web personnel) . Évalué à 3.
Parce qu'il y'a un mainteneur ?
La le truc, c'est que quand Arch sera passé à systemd, le mainteneur de sshd par exemple, si il a pas envie, il va virer le /etc/rc.d/sshd et donc il faudra trouver quelqu'un pour maintenir le script sysv.
[^] # Re: La conclusion
Posté par modr123 . Évalué à -10.
mais on s'en fout que le boot mette 1mn ou 5mn…..
economise quoi avec le daemon qui attends si tu va mettre une clef usb ou un cd quand tu n'en met jamais ?
tu as raison economisons , virons dbus avahi akonamachin etc…………….
[^] # Re: La conclusion
Posté par xcomcmdr . Évalué à 1.
Économiser, c'est bon pour les batteries et les perfs. :)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: La conclusion
Posté par Misc (site web personnel) . Évalué à 10.
Une personne dont le login est E316 serait un utilisateur conservateur
[^] # Re: La conclusion
Posté par Raoul Volfoni (site web personnel) . Évalué à 4.
Et moi qui cherchait une blague en rapport avec E17 avant de comprendre… ;)
[^] # Re: La conclusion
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
Le fait d'être d'accord ou non avec les choix techniques ou les propos exprimés d'une personne ne justifie pas d'être injurieux (sous prétexte d'une pseudo-objectivité). D'autant qu'il existe du vocabulaire plus explicite et descriptif que le terme générique et galvaudé évoqué. Comme contesté, polémique, controversé, arrogant, égocentrique, etc. (j'ignore ce que tu souhaites caractériser ici justement).
# esprit Unix
Posté par Greg (site web personnel) . Évalué à 5.
Serait-ce le début de l'évolution de l'esprit Unix ?
On est en train de regrouper les 2 points de cette esprit:
- "Tout est fichier"
- "Un programme fait une chose unique et le fait bien."
par un truc du genre: "Tout est évènement" ?
[^] # Re: esprit Unix
Posté par gnumdk (site web personnel) . Évalué à 10.
Wai, enfin ca fait des années que cet argument est faux, tu veux une listes de programmes Unix qui ne respecte pas ce principe ?
Dans les gros softs, il faudrait plutot chercher les logiciels qui le respecte encore, genre postfix…
Un programme fait une chose unique et le fait bien, c'était surtout pour les utilitaires de la ligne de commande que ca avait un sens: "Ne cherche pas à tout faire dans un seul programme quand tu peux faire discuter ces derniers via des |"
Je suis pas sur que ce soit très pertinent pour un system d'init.
[^] # Re: esprit Unix
Posté par reno . Évalué à 3.
On parle d'un systeme d'init là, pas d'un gros soft.
[^] # Re: esprit Unix
Posté par gnumdk (site web personnel) . Évalué à 6.
Et ?
C'est vrai que c'était tellement mieux ces scripts shell à rallonge…
[^] # Re: esprit Unix
Posté par modr123 . Évalué à 5.
bash-4.1# wc -l /etc/rc.sysinit
wc: /etc/rc.sysinit: No such file or directory
[^] # Re: esprit Unix
Posté par gnumdk (site web personnel) . Évalué à 1. Dernière modification le 06 septembre 2012 à 22:21.
Oui, j'ai pris le cas extreme de RedHat même si celui de Suse doit être pas mal dans le genre.
ps: merde, je t'ai [-] alors que je voulais te [+], souris de merde!
[^] # Re: esprit Unix
Posté par modr123 . Évalué à 4.
le plus drole c'est que j'ai oublié que j'ai pas d'init sysv vu que j'utilises slackware
si un pour la compatibilite cache dans /etc/rc.d/ qui fait 58 lignes
[^] # Re: esprit Unix
Posté par Misc (site web personnel) . Évalué à 9.
On pourrait aussi noter que c'est pas pertinent sur le noyau, mais personne ne vient défendre le bien fondé de hurd dans ce genre de discussion ( car oui, un soft qui fait du routage et filtrage réseau, tout en gérant la carte son, la video, le chiffrement du filesystéme, des acls, la gestion de l'energie avec une pile wifi et des dizaines d'autres, ça fait plus que "juste une chose" )
[^] # Re: esprit Unix
Posté par pikapika . Évalué à 5.
le nouveau mot d'ordre c'est plutot "tout est bloat", des surcouches plus imbitables les unes que les autres, des systemes qui font tout, et quand ca merde, c'est indebuggable, et qui sera remplacé apres par une autre merde encore plus absconse et illisible
[^] # Re: esprit Unix
Posté par omer666 . Évalué à 3.
T'as déjà touché à un système victime de "bloat" toi ? Bein fais-le vite parce que ta définition du mot "bloat" est quelque peu erronée, dans ce contexte en particulier.
systemd propose simplement une autre gestion des services et autres demons. C'est tout. Il ne vient en surcouche de rien. Le fait qu'il attende que tu branches une clé usb n'a rien à voir avec ça, d'ailleurs c'est udev qui gère ça, et avant c'était hal. Et en matière de soft mal gaulé, hal est plutôt bien classé.
Il faut cesser de voir des régressions partout !
N.B. : j'ai bien noté qu'il s'agissait d'une référence à pulseaudio et par extension, à son créateur.
[^] # Re: esprit Unix
Posté par neil . Évalué à 1.
Tu confonds avec Plan9. Sous UNIX il y a des sockets et autres ioctl.
[^] # Re: esprit Unix
Posté par navaati . Évalué à 1.
Tout est file descriptor alors ;)
(C'est presque vrai ça par contre)
Et les ioctl ça s'effectue sur… des fichiers.
[^] # Re: esprit Unix
Posté par Buf (Mastodon) . Évalué à 1.
Oui, mais à mon avis, l'existence des ioctl est bien une preuve que le modèle "tout est fichier" n'est pas toujours suffisant.
# Monitoring des services
Posté par Raoul Volfoni (site web personnel) . Évalué à 10.
Je n'ai encore aucun avis à formuler sur systemd même si je trouve que le bon vieil init sysV commence à avoir fait son temps, mais le monitoring des services lui manque cruellement de mon point de vue (et puis les dépendances, les groupes tout ça c'est un peu le boxon d'une distrib à l'autre). Après une petite recherche je vois que systemd le fait: http://0pointer.de/blog/projects/watchdog.html
C'est un bon point pour lui.
En attendant, je continue de lire la doc pour me faire une opinion et vous laisse troller en paix.
# Montage à la demande
Posté par Lizzie Crowdagger (site web personnel) . Évalué à 2.
«Par exemple, au lieu d’attendre que tous les volumes de /etc/fstab soient montés (et contrôlés avec fsck si besoin), on monte le système de fichiers uniquement lorsqu’un service y accède.»
Dans l'idée c'est pas mal, mais ça se passe comment en pratique s'il y a besoin de faire un fsck, de demander une passphrase ?
Perso, autant je trouve ça supportable de rentrer une passphrase au démarrage pour décrypter la partoche /home et d'aller me fumer une clope si c'est un jour de Fsck (sur mon vieux tromblon en tout cas), autant si j'ai l'impression que l'ordi est lancé mais que je dois me taper un fsck au moment où je lance ma session, ou encore si je pense avoir débloqué l'ordi pour le prêter à quelqu'un mais que telle partition cryptée n'était pas montée, ça peut vite être pénible, non ?
[^] # Re: Montage à la demande
Posté par gnumdk (site web personnel) . Évalué à 3. Dernière modification le 06 septembre 2012 à 16:02.
Ce qu'il décrit n'est pas le comportement par défaut de systemd mais c'est faisable… J'ai pas encore bien fouillé la question :)
[^] # Re: Montage à la demande
Posté par Lizzie Crowdagger (site web personnel) . Évalué à 1.
Ok, du coup effectivement pour des partitions qui ne servent que tous les 36 du mois ça peut peut-être valoir le coup…
[^] # Re: Montage à la demande
Posté par FantastIX . Évalué à 3.
Voilà. Genre les clés USB, les disques externes, tous les périphériques qu'on branche en sachant très bien qu'on va s'en servir tout de suite…
[^] # Re: Montage à la demande
Posté par Maclag . Évalué à 5.
Et voilà: systemd va relancer la cigarette.
Ah vraiment bravo hein!!
-------------------> [ ]
# Tant que ça reste coté Desktop...
Posté par dcp . Évalué à 10.
Salut,
J'espère juste qu'il n'est pas prévu pas de remplacer le très éprouvé, très fiable et très facile à gérer init SysV coté serveur. J'en frissonne d'avance…
Pour info, le BIOS de nos récents Dell R410 met facilement 2/3 minutes avant de donner la main à GRUB. Nous ne sommes pas à 30 secondes près pour le boot proprement dit d'un serveur qui de plus ne redémarre que très rarement.
Plus généralement, l'essence d'UNIX c'est
- KISS,
- "Tout est fichier",
- "Tout est éditable" (pas de binaires hormis les exécutables/librairies/images…),
- Un outil s’acquitte d'une tâche et d'une seule etc …
Les choix de Lennart me semblent de plus en plus éloignés de ces préceptes …
Mes deux centimes.
[^] # Re: Tant que ça reste coté Desktop...
Posté par stopspam . Évalué à 5. Dernière modification le 06 septembre 2012 à 19:38.
Pour moi, il y a 2 événements déclencheurs :
A partir de là, 2 énormités sont sorties :
Pour résumer : on est passé d'un monde ou les logiciels étaient optimisés pour les serveurs et hackés vers les desktops a exactement l'inverse.
[^] # Re: Tant que ça reste coté Desktop...
Posté par gnumdk (site web personnel) . Évalué à 8.
Moi, les deux énormités, ce sont stopspam et dcp qui n'ont toujours pas compris que systemd n'existe pas pour booter plus vite, c'est juste une conséquence de son architecture…
[^] # Re: Tant que ça reste coté Desktop...
Posté par stopspam . Évalué à 4.
Sans déc', c'est que j'ai marqué plus haut ? Pas du tout. Le sujet n'est nullement le gain ou la perte de perf mais les choix techniques qui sont fait pour répondre à un problème.
Stupide. La conséquence peut très bien être la cause. Rien ne contredit le fait que son architecture a été pensée pour booter plus rapidement.
[^] # Re: Tant que ça reste coté Desktop...
Posté par dcp . Évalué à -3.
Ha ok, ils ont fait de la parallélisation agressive juste pour le fun. Pas du tout pour accélerer le boot. Effectivement, j'avais rien compris.
D'autre part, question "architecture", ils se sont fait plaisir sans imaginer qu'aucun admin system digne de ce nom ne va mettre en place un système qui n'est pas pris en compte par des produits proprio (type NetBackup au pif) et qui n'est pas rétro-compatible avec l'existant.
Cf mon poste plus bas sur la non-préservation des API-ABI "a la mode" chez Gnome et qui font hurler de rire les devs du noyau.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tant que ça reste coté Desktop...
Posté par dcp . Évalué à 4.
Pour les VMs Linux para-virtualisées (sous Xen), le temps de boot est très largement en dessous des 30s (du moins pour avoir sshd démarré)
Ce qui prend du temps c'est le lancement de la "charge utile" (En gros un Tomcat ou un MySQL/PostgreSQL/Oracle) et là, systemd ne peut rien améliorer.
Je me permets d'ajouter une petite remarque. Systemd est un développement "from scratch" qui n'a pas cherché à préserver la rétro-compatibilité avec l'existant. Ça ne vous rappelle pas un échange récent et vigoureux entre Alan Cox/Linus Torvald d'un coté et Miguel de Icaza de l'autre a propos de la stabilité des API/ABI ?
[^] # Re: Tant que ça reste coté Desktop...
Posté par gnumdk (site web personnel) . Évalué à 2.
Eux, systemd est tout à fait capable de lancer les scripts de sysv… C'est juste que si tu l'utilise comme ça, autant ne pas l'utiliser.
[^] # Re: Tant que ça reste coté Desktop...
Posté par dcp . Évalué à -2.
On s'est bien compris tous les deux gnumdk ? Je ne veux pas de systemd sur mes serveurs Par contre coté Linux/Desktop, je m'en fous complètement :).
[^] # Re: Tant que ça reste coté Desktop...
Posté par GnunuX (site web personnel) . Évalué à 9.
Savoir qu'un service s'arrête VRAIMENT quand on lui demande, qu'il le redémarre s'il plante, qu'on puisse l'isolé, gérer les ressources utilisées, …
Effectivement c'est fonctionnalité ne sont pas du tout utile sur un serveur.
[^] # Re: Tant que ça reste coté Desktop...
Posté par Alex . Évalué à 1.
la question est "est il pertinent que ce soit le système d'init qui gère tout ça plutôt qu'un outil spécialisé dans chaque tache ?"
que le système d'init devienne un vrai bloat m'embête
avoir une seule interface pour effectuer toutes ses opérations me plait
[^] # Re: Tant que ça reste coté Desktop...
Posté par gnumdk (site web personnel) . Évalué à 1.
Non, la question est: « est il possible de faire tout cela ailleurs que dans le système d'init » …
[^] # Re: Tant que ça reste coté Desktop...
Posté par Alex . Évalué à 4.
pour 90% des features, oui
donc je reformule, "est il nécessaire que le système d'init fasse des choses qui ne sont pas lié à l'init, et que d'autres outils font très bien (modularité) au prix d'une compléxité un peu plus élevé (n interfaces à maitriser)"
[^] # Re: Tant que ça reste coté Desktop...
Posté par YBoy360 (site web personnel) . Évalué à 3.
non, c'est même pas ça pour moi, c'est "faire ça hors d'init, ça oblige à refaire ce que fait init ailleurs".
Inet, xinet, cron et autres, c'est le même type de problématiques, ce sont des outils redondants, en plus chacun à sa propre sémantique pour la configuration.
Maintenir plusieurs outils qui font la même chose en parallèle, c'est super KISS.
[^] # Re: Tant que ça reste coté Desktop...
Posté par dcp . Évalué à 2.
Relancer automatiquement un service est généralement une mauvaise idée (à quoi bon relancer MySQL si la partition data est montée sur un lien iSCSI qui vient de tomber). Un des points de contrôle de Nagios nous remonte une alerte, on détermine le problème, on le fixe au besoin, et on relance le service. On ne rajoute pas du bazar avec des procédures de relance automatique qui risqueraient d'empirer la situation.
Dans quel sens ?
- chroot ou openvz sont là pour ça.
- au niveau session, tous les services dignes de ce nom double fork() pour être leader de leur groupe de session.
Pour la gestion des ressources, les serveurs (Apache/MySQL/Postgres etc …) le font très bien tout seul.
systemd est il né pour combler les lacunes de services mal écrits ?
Mes 2 centimes :)
[^] # Re: Tant que ça reste coté Desktop...
Posté par coïn . Évalué à 10.
Moi, je le répare. Chacun son truc.
[^] # Re: Tant que ça reste coté Desktop...
Posté par navaati . Évalué à 5.
Eh bien entre autre il est né pour factoriser tout ce code qui était présent à l'identique dans chacun de ces services. Mais peut-être que tu devrait lire la doc avant de bitcher.
[^] # Re: Tant que ça reste coté Desktop...
Posté par crazy69 . Évalué à -3.
Il faut faire un bloat pour factoriser du code en plusieurs exécutables ???
Au boulot on fait une librairie pour faire ça…
[^] # Re: Tant que ça reste coté Desktop...
Posté par navaati . Évalué à 5.
Alors on veut faire de la gestion des ressources, des sessions, du tracking de process fils, éventuellement du logging, dans un certain nombre de deamons qui ont rien d'autre en commun que… d'être des services.
Donc pour factoriser ce genre de trucs (mais attention, on veut aussi unifier le format de conf de tout ça hein, si c'est au daemon de décider si y veut activer tel truc ou propager le paramètre dans sa propre conf, ya aucun intérêt), on a deux solutions :
Et yen a encore pour venir dire que wep, systemd c'est pas dans un style UNIX ? WTF ? Ya difficilement plus UNIXy que ce truc !
[^] # Re: Tant que ça reste coté Desktop...
Posté par pasBill pasGates . Évalué à 3.
Plus généralement, l'essence d'UNIX c'est
- KISS,
- "Tout est fichier",
- "Tout est éditable" (pas de binaires hormis les exécutables/librairies/images…),
- Un outil s’acquitte d'une tâche et d'une seule etc …
Voila ce que je pense des dogmes :
Non pas que la philosophie est totalement stupide hein, mais faudrait penser a evoluer un peu, l'informatique des annees 60 n'a plus rien a voir avec celle du 21eme siecle.
[^] # Re: Tant que ça reste coté Desktop...
Posté par Miguel Moquillon (site web personnel) . Évalué à 3.
Non effectivement … Au 21 siècle, les principes architecturaux ont heureusement évoluées et devines quoi ? Ben ce sont justement celles que l'on retrouve dans Unix dès les années 70 et qui ont fait grandement son succès : modularité de l'espace utilisateur avec communication inter module, tout est fichier (de nos jours : objets, fonctions, ressources WEB, bref il y en a pour tous les goûts), etc. Marrant non ?
Ho bien sûr, ces principes n'ont pas toujours été respecté par les programmes utilisateurs (X, Netscape, StarOffice, …) et ont traînés avec eux maintes problèmes et désagréments aussi bien pour les utilisateurs que pour les développeurs mêmes.
Mais grâce à systemd, retour à 20 ans en arrière, à l'ère du monolithique et du bloatware. L'expérience de X n'a, apparemment, pas suffit comme leçon.
[^] # Re: Tant que ça reste coté Desktop...
Posté par xcomcmdr . Évalué à 1.
T'as testé systemd avant de cracher dessus ?
Ça fait longtemps que les principes UNIX ne sont pas respectés sous GNU/Linux, systemd est très loin d'être le pire.
Pour ma part, je suis passé entièrement à systemd sous Archlinux. Outre le temps de boot largement réduit, j'ai aussi de multiples fichiers de configuration qui ont chacun une seule responsabilité (configurer la locale, configurer l'horloge, …) plutôt qu'un /etc/rc.conf monolithique qui fait tout.
Bref, j'étais contre systemd, mais finalement il est pas si mal…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Tant que ça reste coté Desktop...
Posté par Miguel Moquillon (site web personnel) . Évalué à 2.
Oui … Et là n'est pas la question. Ici, on parlait de principes architecturaux, pas d'utilisation.
Je prend un autre exemple dans un contexte bien différent : maven. Un système de gestion de build qui apporte une solution élégante aux problèmes de build et de gestion de dépendances dans les projets Java. Pourtant, son implémentation est pourrie. La différence ici, est qu'il ne s'inscrit pas dans un existant architectural.
Ho la bonne excuse à deux francs six sous !
[^] # Re: Tant que ça reste coté Desktop...
Posté par cedric . Évalué à 2.
Il va falloir que tu demontres a des developpeurs experimentes que ton principe KISS va fournir un meilleur resultat… Le principe KISS est souvent sorti dans deux situations :
- quand on affronte une horreur sans queue ni tete et qu'on ne peut pas faire autrement que tout jeter.
- quand une personne qui n'a pas assez d'experience ne comprend pas ce qu'elle a en face d'elle.
Le probleme, c'est de faire la difference entre l'un et l'autre.
Sinon il y a plein de cas ou le fais de separer entre process pose des problemes. Perte d'information, de cache, difficulte de detecter finement les erreurs, efficacite generale and so on. Donc le principe KISS, c'est comme les designs patterns, faut pas en abuser betement. Ceux ne sont pas des religions !
[^] # Re: Tant que ça reste coté Desktop...
Posté par Miguel Moquillon (site web personnel) . Évalué à -1.
Je suis un développeur expérimenté et quand je lis ton commentaire je hurle parce que je vois ici qu'une justification de continuer à faire de la bouse.
Il est bien plus facile de faire compliquer et bien plus compliquer de faire simple. Et il est encore plus compliquer de faire évoluer la simplicité initiale. Mais il est encore plus difficile de faire simple sur un existant complexe. Et tous les jours nous en faisons les frais de ces maximes.
[^] # Re: Tant que ça reste coté Desktop...
Posté par gnumdk (site web personnel) . Évalué à 1.
J'aime ce genre d'affirmation qui dans l'absolue ne veulent absolument rien dire…
Développeur expérimenté, c'est pas coder trois conneries dans son coin et pondre du code pourri pour son patron… (sans vouloir faire de généralités).
Sinon, t'as bossé sur quoi ?
[^] # Re: Tant que ça reste coté Desktop...
Posté par Antoine . Évalué à 3.
Je suis d'accord, ç'aurait été mieux avec « je suis Senior J2EE Architect ».
[^] # Re: Tant que ça reste coté Desktop...
Posté par Anonyme . Évalué à 4.
Il manque "lead", c'est important. « J2EE Lead Architect ».
[^] # Re: Tant que ça reste coté Desktop...
Posté par cedric . Évalué à 2.
Approcher le developpement avec des dogmes, c'est pas une bonne idee. Il faut voir la situation et s'adapter au contexte. Pour le coup ne pas montrer de souplesse dans l'analyse et la solution d'un probleme technique n'est pas un bon signe…
[^] # Re: Tant que ça reste coté Desktop...
Posté par Miguel Moquillon (site web personnel) . Évalué à 1.
Oui je suis d'accord, mais confondre des approches qui t'aident, qui t'orientent à architecturer à peu près correctement du code (KISS par exemple) avec des dogmes me laissent perplexe. Une approche définie un cadre générale, et laisse à chacun de le décliner en fonction de son contexte. Un dogme c'est une route bien concrète à suivre quoiqu'il arrive.
Bon après, ce n'est pas parce que tu suis une certaine approche que tu ne vas pas non plus produire un code pourrave.
[^] # Re: Tant que ça reste coté Desktop...
Posté par YBoy360 (site web personnel) . Évalué à 4.
bah sur le plan de l'architecture il est "simplement stupide" :
-> de garder des outils qui font la même chose séparé (cron, xinet, init ..) avec des config qui leur sont propre,
-> de placer hors d'init des outils censé monitorer/gérer des services.
[^] # Re: Tant que ça reste coté Desktop...
Posté par Anthony Jaguenaud . Évalué à 0.
Il faut que je revois mes cours et ma compréhension. Mais tu as l’air doué. Alors tu vas m’expliquer en quoi cron, xinet et init font la même chose ? Certe, ils lancent tous des soft. mais dans ce cas, ajoute udev, bash, thunderbird, firefox… Parce que à part lancer un soft. je ne vois pas d’autre dénominateur commun.
Instruit moi STP.
[^] # Re: Tant que ça reste coté Desktop...
Posté par claudex . Évalué à 5.
Ils doivent lancer un exécutable (cron lance rarement des daemons mais init lance aussi des programmes qui ne sont pas des démons), doivent vérifier qu'il s'est bien lancé, qu'il s'est terminé sans erreur, et logguer tout ça. La seule différence entre cron et init, c'est que le premier fait ça en fonction de l'heure et le second quand on change de runlevel.
« 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: Tant que ça reste coté Desktop...
Posté par Anthony Jaguenaud . Évalué à -2.
Donc thunderbird lance un exécutable (firefox) à chaque fois que je clique sur un lien. Donc il a le bon dénominateur commun, donc il doit être intégré à systemd. En même temps c’est logique, pourquoi avoir plusieurs implémentation de imap…
Moi je vois d’autres différences :
[^] # Re: Tant que ça reste coté Desktop...
Posté par claudex . Évalué à 7.
Si tu pouvais lire mes phrases jusqu'au bout, ce serait sympa et te pemettrait de comprendre la différence avec Thunderbird. Un indice, la suite de la phrase contient : * doivent vérifier qu'il s'est bien lancé, qu'il s'est terminé sans erreur, et logguer tout ça.*
Est-ce forcément une bonne idée ? Pourquoi l'utilisateur ne pourrait pas avoir de système d'init pour lui ?
Si tu veux chipoter, init lance rc qui lui lance les service, donc aucun des deux (rc et cron) n'est démarré par le noyau.
« 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: Tant que ça reste coté Desktop...
Posté par Didier (site web personnel) . Évalué à 1.
C'est déjà le cas. Les gestionnaires de session de Gnome ou KDE font exactement la même chose. D'où la proposition de Lennart d'utiliser systemd pour Gnome…
[^] # Re: Tant que ça reste coté Desktop...
Posté par xcomcmdr . Évalué à 2. Dernière modification le 07 septembre 2012 à 13:25.
Ouais, et les principes architecturaux si tu en abuse, ça fait de la merde.
Quand un principe est constamment remis en question, tu ne te demandes pas pourquoi ?
Ça prouve que tu as des œillères assez énorme.
M'enfin bon, allez on va appliquer les dogmes UNIX "parce que c'est comme ça et puis c'est tout" à l'existant, à commencer par le noyau Linux (qui fait beaucoup de choses : violation des principes UNIX ! BOUH !), c'est Linus qui va être content quand on va lui expliquer son métier.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Tant que ça reste coté Desktop...
Posté par Alex . Évalué à 2.
c'est fait, c'est ptet même le premier troll de l'histoire du libre
l'archi monolithique de linux est tout de même souvent critiqué
et ce n’est pas parce que quelque chose est fait d'une manière qu'il faut continuer dans cette voie
et à l'inverse ce n’est pas parce que c'était fait de telle manière qu'il faut obligatoirement continuer dans cette voie
(tout ça pour dire que je ne trouve aucun intérêt à ce genre de comparaison)
[^] # Re: Tant que ça reste coté Desktop...
Posté par Albert_ . Évalué à 2.
l'archi monolithique de linux est tout de même souvent critiqué
Euh tu parles encore de linux 1? Parceque ca fait longtemps que linux est modulaire.
On ne va meme pas parler des critiques qui sont encore avec Hurd (la premiere fois que j'ai entendu parler de ca et que j'ai vu des CD de ce systeme c'etait en 91, 21 plus tard et malgre des tas d'affirmation que c'etait genial et presque pres c'est toujours un enorme vaporware qui eclate de tres loins DNF et E17, Minix est essentiellement un systeme d'apprentissage.
[^] # Re: Tant que ça reste coté Desktop...
Posté par Alex . Évalué à 2.
ça n'en fait pas moin un noyau monolithique
quand on troll avec hurd, minix, L4, etc… il est évident qu'on troll sur les archis
linux étant le seul noyau libre utilisable (ou presque, mais c'est un autre troll)
[^] # Re: Tant que ça reste coté Desktop...
Posté par Antoine . Évalué à 2.
Inventons un nouveau mot : modulithique.
[^] # Re: Tant que ça reste coté Desktop...
Posté par Alex . Évalué à 3.
ou simplement comme on les appelle déjà: monolithique modulaire
[^] # Re: Tant que ça reste coté Desktop...
Posté par groumly . Évalué à 0.
Et les bsd, ils puent?
Et darwin, c'est pour les cochons?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Tant que ça reste coté Desktop...
Posté par Alex . Évalué à 2.
ils étaient dans le presque ;)
mais c'était volontairement trollesque, pour rester dans le ton
[^] # Re: Tant que ça reste coté Desktop...
Posté par cedric . Évalué à 2.
Ah la belle critique universitaire. Mais bon, elle resiste malheureusement pas au code sur le terrain. Va savoir pourquoi…
[^] # Re: Tant que ça reste coté Desktop...
Posté par Alex . Évalué à 1.
???
c'est vrai qu'on ne trouve plus de micro noyau "pur", mais bon, qnx, macos, win, … s'en sortent plutôt bien sur le terrain
[^] # Re: Tant que ça reste coté Desktop...
Posté par gnumdk (site web personnel) . Évalué à 5.
Wai, enfin si on parle micro noyau pire, tu peux ne garder que qnx par contre ;)
[^] # Re: Tant que ça reste coté Desktop...
Posté par cedric . Évalué à 4.
Joli de prendre X comme exemple ! Le probleme de X, identifie aujourd'hui, c'est que justement, il devrait inclure le Window Manager et le Composite Manager… Une belle demonstration par l'absurde que de faire une seule tache et la faire bien, n'est pas forcement en terme de design la meilleur solution. C'est un dogme, tout comme le principe KISS qui n'est pas forcement une bonne idee dans tous les cas.
[^] # Re: Tant que ça reste coté Desktop...
Posté par Miguel Moquillon (site web personnel) . Évalué à 0.
Non justement et wayland le démontre.
Le problème de X est que tout est dedans … excepté le Window Manager, heureusement. Et c'est pourquoi on a de grand mal à le faire évoluer avec les attentes et le matériel d'aujourd'hui.
Et pourtant, il existait des outils dans les années 80 qui étaient bien mieux pensés : je pense en particulier à Blit
[^] # Re: Tant que ça reste coté Desktop...
Posté par claudex . Évalué à 5.
Et le compositeur.
« 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: Tant que ça reste coté Desktop...
Posté par Miguel Moquillon (site web personnel) . Évalué à 0.
Oui finalement, ce qui aurait du être dans X et qui ne l'a pas été, c'était bien le compositeur. J'irais même plus loin : X aurait du être juste un framework doté d'un compositeur.
[^] # Re: Tant que ça reste coté Desktop...
Posté par cedric . Évalué à 7.
Wayland, c'est le merge du composite manager, du window manager et de X. Je ne comprend donc pas ton "heureusement"…
De plus la conception de X lui a permit de tenir 20 ans sans etre reecrit. En informatique, je connais peu d'exemple qui ont tenu aussi longtemps en etant aussi centrale (Et X n'est pas encore remplace, Wayland est a encore bien deux ans de dev de pouvoir le remplacer). Surtout que X a ete cree du temps ou la majorite du probleme etait d'acceder graphiquement a des main frame. Alors que aujourd'hui, la majorite des usages sont dans l'embarque et la mobilite… Des trucs qui n'avaient meme pas ete envisage lors de la conception.
Je n'ai pas lu d'article detaille sur comment fonctionnait Blit, et l'histoire ne l'a pas retenu, donc je ne peux me prononcer dessus. Mais clairement critiquer X… J'attend de voir ou sera le soft que tu ecris dans 20 ans et comment il aura evoluer, si il survit jusque la ! :-D
[^] # Re: Tant que ça reste coté Desktop...
Posté par Miguel Moquillon (site web personnel) . Évalué à 0. Dernière modification le 07 septembre 2012 à 12:42.
Heu non. Wayland est un protocole et une API C pour la communication entre des clients et un composite manager.
Actuellement, une implémentation simple d'un composite manager est proposée et pour des raisons de compatibilités avec l'existant, un client wayland a été écrit pour prendre en charge X, mais ce n'est qu'un client.
Oui, 20 ans d'emmerdes sous GNU/Linux et *BSD.
Alors ok, X était peut être pertinent avec les main frames, mais il a été à contre courant des principes même d'Unix à l'époque, ce qui fait, à mon avis, qu'il a vraiment eu du mal à évoluer et à s'adapter avec les changements au fur et à mesure du temps.
[^] # Re: Tant que ça reste coté Desktop...
Posté par reno . Évalué à 4.
Il s'est mal exprimé mais il a raison: dans "Wayland", Weston ou son équivalent intègre plusieurs choses qui sont fait séparément (donc de manière plus modulaire) dans X: le composite manager, l'affichage et (une partie)du gestionnaire de fenêtre.
Amusant que tu ne reconnaisse pas ça, toi qui semble défendre les principes d'Unix.
[^] # Re: Tant que ça reste coté Desktop...
Posté par Miguel Moquillon (site web personnel) . Évalué à 1.
Non, j'aurais écris tout simplement : "tu oublis ça".
Effectivement, mais il ne faut pas oublier qu'à l'origine, Weston était là pour valider le concept. Après maintenant …
L'architecture de wayland permet de séparer le tout et avec Weston on a un code de référence de l'implémentation d'un composite manager.
Sinon, pour avoir un bousin qui respecte les principes Unix, il aurait fallu avoir une archi semblable mappée sur le système de fichier qui aurait alors servi peut être de moyen de communication entre les différents agents graphiques. (Mais de nos jours, on préfère apparemment s'éloigner le plus du système de fichiers).
[^] # Re: Tant que ça reste coté Desktop...
Posté par reno . Évalué à 3.
Tout comme l'architecture d'X ne t’empêche pas de regrouper le gestionnaire de fenêtre, le composite manager et le server d'affichage dans un seul processus comme ce que fait Weston.
Maintenant entre ce que les architectures permettent et ce qui est fait en pratique, il y a un gouffre..
Ce que fait Plan9 effectivement.
[^] # Re: Tant que ça reste coté Desktop...
Posté par cedric . Évalué à 3.
C'est d'ailleur un tres bon point que tu releves. Wayland aurait pu etre prototype quasiment completement dans X. Mais l'avantage majeur, pour les developpeurs de X, c'est de repartir d'une base de code propre. Et il faut pas oublier que pour l'instant Wayland est code par les developpeurs de X principalement (ca explique les incongruites qu'ils font dans le cote window manager…).
[^] # Re: Tant que ça reste coté Desktop...
Posté par cedric . Évalué à 4.
Non, l'architecture de Wayland ne permet absolument pas de separer le tout. C'est juste impossible. Et c'est aussi pourquoi Wayland est fait de cette maniere pour corriger deux problemes majeurs de X : les inputs et la securite. Si ton composite manager commence a faire tourner ta fenetre, tu fais comment pour modifier les inputs sans que tout le flux d'input passe aussi par le composite manager pour subir la bonne deformation ? Meme question pour lutter contre le phishing et les keylogger, tu fais comment sans une cooperation fine entre le composite manager, le window manager et le systeme d'input ? Tu peux pas. Toutes les implementations sures, efficaces et fonctionnelle de Wayland seront monolytique.
[^] # Re: Tant que ça reste coté Desktop...
Posté par Miguel Moquillon (site web personnel) . Évalué à 0.
Ben si justement. Quand tu regardes l'architecture de Wayland, tu peux justement séparer les différentes briques : Window Manager, Display Manager, Composite Manager, Events Manager, etc. (Bon en fait je ne vois pas trop l'intérêt de séparer le Display Manager et le Composite Manager et ne suis même pas sûr que c'est faisable dans Wayland). En fait, la pièce centrale est le Composite Manager et le protocole définie dans Wayland est pour justement la communication avec le compositeur ; tout le reste peut être réalisé sous forme de clients Wayland.
Oui probablement. C'est pourquoi, malgré son architecture qui permet le découplage l'implémentation qui sera faite, au-dessus de Wayland, sera monolithique ; seul le code sera structuré.
[^] # Re: Tant que ça reste coté Desktop...
Posté par cedric . Évalué à 2.
Non, tu ne peux pas. L'event manager ne peut pas savoir ou envoyer un event, car seul le composite manager sait ce qu'il y a l'ecran a cette endroit la et a qui envoyer l'information. De la meme maniere d'un point de vue securite quand tu auras une fenetre demandans un mot de passe, il faudra une cooperation sans man in the middle entre le window manager, l'event manager et le composite manager. Techniquement tu ne pourras pas les separer. Et ca n'a jamais ete l'objectif.
Tres grand innovation technique de Wayland d'ailleur :-D Non, franchement, c'est juste pour avoir raison que tu dis une telle generalite ou tu avais une vrai idee derriere la tete ?
[^] # Re: Tant que ça reste coté Desktop...
Posté par Miguel Moquillon (site web personnel) . Évalué à 0.
De nos jours, on rencontre encore bon nombre de projets au code spaghetti correctement structuré, voir strucuté tout court ; ce n'est pas parce que tu utilises un langage modulaire, à classes, fonctionnel, … que le code est nécessairement (bien) structuré, il te le facilite, c'est tout. Et ce n'est pas la panacée des projets privatifs, on en rencontre aussi dans les projets Open Source aussi : je prend l'exemple de l'implémentation des portlets de java.net (Open Portal), une grosse bouze ce truc que j'ai du me tapper !
Donc, quand je dis que le code sera structuré, c'est en ayant ça à l'esprit : c'est déjà pas mal parce que même si le resultat soit monolithique, le fait que le code le soit (s'il est correctement c'est encore mieux), c'est déjà un grand pas pour son évolution. Alors, bien sûr, on est loin là de l'esprit d'Unix.
Avec le temps, avec l'évolution des machines, nos techniques de programmation ont évolué vers une meilleur modularité et ceci se reporte aussi sur les architectures logicielles. Malgré tout, la modularité effective du code ou de l'architecture dépend grandement des développeurs.
[^] # Re: Tant que ça reste coté Desktop...
Posté par omer666 . Évalué à 0.
Mais justement ne peut-on pas apprendre des applications utilisateurs et garder le meilleur des deux ? Si un problème ne trouve pas de solution sous prétexte que la solution n'est pas dogmatique, on n'est pas plus avancé…
[^] # Re: Tant que ça reste coté Desktop...
Posté par pasBill pasGates . Évalué à 2.
Ben ce sont justement celles que l'on retrouve dans Unix dès les années 70 et qui ont fait grandement son succès : modularité de l'espace utilisateur avec communication inter module, tout est fichier (de nos jours : objets, fonctions, ressources WEB, bref il y en a pour tous les goûts), etc. Marrant non ?
Ah oui, tres marrant.
Combien de softs importants sont composes de petits executables communiquant par pipe avec du texte comme mode de transport ? FireFox ? OpenOffice ? Apache ? Eclipse ? KDE ? Gnome ? Ah ouais, on voit combien cette architecture est suivie de nos jours…
Les softs d'aujourd'hui sont modulaires, mais en tant que dll charges(= plugins) plutot que differents executables, les configurations sont de moins en moins shell / texte pour etre plus structurees, etc…
Le web tu trouves que c'est KISS ? Avec SVG, la 3D, javascript, XML, CSS, SSL etc… dedans ? On dirait un mini-OS a la Emacs.
etc…
[^] # Re: Tant que ça reste coté Desktop...
Posté par gnumdk (site web personnel) . Évalué à 2.
Sous les OS libres ? Je dirais "très" beaucoup :) En tout cas, la ligne de commande est bien fournis.
Mais après, sortie de ce contexte là, ce principe des années 70 n'a pas de sens.
[^] # Re: Tant que ça reste coté Desktop...
Posté par Miguel Moquillon (site web personnel) . Évalué à 2.
Comme apparemment beaucoup de monde, tu confonds principes et architectures avec implémentation.
J'ai écris modularité avec communication inter-module. Je n'ai pas parlé de processus et de pipe ou autre IPC qui a été l'implémentation d'Unix a son époque et qui a évolué avec le temps. Et à son époque, Unix était l'un des rares systèmes dans lequel l'espace utilisateur (et non le noyau comme beaucoup semble croire ici) reposait sur ces principes qui sont en vigueur de nos jours.
Donc oui aujourd'hui de très nombreux outils libres sont construits sur ce modèle avec leur propre implémentation de la modularité et de la communication inter-module.
Quant aux technologies dédiés au WEB, il y a à boire et à manger comme dans tout environnement de dév et d'exécution distribué. Et là on peut en discuter à l'infini …
[^] # Re: Tant que ça reste coté Desktop...
Posté par dcp . Évalué à 1.
Une image caricaturale ne masque que difficilement un vide argumentaire (Ksss ksss ksss !!)
La seule question qu'il faut se poser (et tu seras d'accord avec moi) c'est si une abstraction informatique permet d'appréhender un problème de manière fiable, simple et efficace. Le "dogme" UNIX tel que tu le qualifies s'applique toujours extrêmement bien coté serveur (d'ou mon message "tant que ça reste sur le Desktop"). Pas plus, pas moins :)
[^] # Re: Tant que ça reste coté Desktop...
Posté par jbbourgoin (site web personnel) . Évalué à 4.
Il y a ici une confusion entre la tradition et la coutume. Mais c'est devenu courant dans le monde moderne qui par nature méprise tout ce qui ne lui est pas contemporain.
La tradition relève de la transmission d'un savoir, d'une connaissance. La tradition est donc par nature "vivante" puisque ce qui est transmis passe sous la responsabilité des nouvelles générations.
La coutume est simplement une manière de faire, d'agir, de parler etc. propre à un groupe, qui s'installe non par l'autorité (au sens noble), mais par l'habitude.
La tradition est "consciente", là où la coutume est plus ou moins "inconsciente".
Là où la confusion est compréhensible c'est qu'il n'est pas rare qu'une tradition soir pour beaucoup de personnes une "simple" coutume. Mais l'inverse n'est pas vrai, une coutume n'est jamais une tradition (nature de la transmission).
[^] # Re: Tant que ça reste coté Desktop...
Posté par claudex . Évalué à 2.
Tradition pouvant aussi signifier coutume, je ne comprend pas de quoi tu te plains.
« 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: Tant que ça reste coté Desktop...
Posté par omer666 . Évalué à 3.
Il se plaint de la perte du sens des mots. Et il n'est pas le seul.
[^] # Re: Tant que ça reste coté Desktop...
Posté par claudex . Évalué à 2.
Se plaindre de la perte du sens des mots anglais en français sur un site francophone, ce n'est pas banale.
« 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: Tant que ça reste coté Desktop...
Posté par omer666 . Évalué à 0. Dernière modification le 08 septembre 2012 à 14:09.
Oui, tu as raison ! o_O j'ai zappé que le panneau était écrit en Anglais, ce qui change tout. Pour un Angliciste franchement, ça fait bien…
[^] # Re: Tant que ça reste coté Desktop...
Posté par modr123 . Évalué à -1.
tu te rends compte que si jesus etait né 20 ans plus tard on serait toujours au 20 ieme siecle …
[^] # Re: Tant que ça reste coté Desktop...
Posté par modr123 . Évalué à 1.
si les gens n'evoluent ils gardent leur vieilles versions donc pas de sous pour MSFT.
# Bientôt vendredi
Posté par Buf (Mastodon) . Évalué à -4.
Un truc qu'on ne dit pas assez au sujet de systemd, c'est que c'est très largement inspiré de launchd, créé par Apple et inclus avec Mac OS X dès la version 10.4 (Tiger, le système d'exploitation le plus avancé au monde au moment de sa sortie, rattrapé depuis par Leopard, Snow Leopard, Lion et Mountain Lion) C'est également utilisé par les versions serveur de ces OS, ainsi que par iOS, ce qui démontre que le principe est suffisamment bon pour être utilisable dans de nombreux contextes différents.
Au passage, launchd est proposé sous une licence libre (du vrai libre, pas du GPL), à tel point qu'on se demande quel besoin les Linuxiens avaient encore à vouloir réinventer la roue au lieu d'améliorer un truc qui existe déjà.
Bref, une fois de plus, Apple a ouvert la voie et le reste du monde tente tant bien que mal de suivre.
PS : une différence avec systemd, c'est que les fichiers de configuration sont en XML, format standard et universel par excellence, ce qui est une preuve de plus qu'Apple a vu tout juste.
[^] # Re: Bientôt vendredi
Posté par Alex . Évalué à 2.
le format plist peut aussi bien être du json (pour le barbu), binaire (pour ceux qui trouve que le fichier texte ca fait trop barbu), ou du xml (pour les autres). C'est effectivement le format idéal
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Bientôt vendredi
Posté par flan (site web personnel) . Évalué à 1.
Je trouve tout de même l'argument vraiment très faible. Ils n'aiment pas le XML ? Pas grave, soit ils utilisent du JSON (correctement indenté, ça passe sans problème), soient ils forkent simplement plistlib pour qu'elle accepte du YAML en plus du XML, du JSON et du binaire. C'est quand même beaucoup moins compliqué que de tout recoder uniquement parce qu'ils trouvent que le plist en XML n'est pas assez lisible…
Sur OS X, tous les fichiers de données des applications (sauf évidemment les outils UNIX historiques) sont soit en plist, soit en sqlite. Ça concerne aussi bien les fichiers de configuration que les fichiers de préférences ou que les fichiers de description d'une application (l'équivalent du .desktop linuxien). À l'usage, c'est très confortable.
Aucun parseur à écrire, une bibliothèque existe dans à peu près tous les langages (c'est même de base dans Python), un programme peut lire les fichiers de configuration et de données de n'Importe quelle application, il y a quelques éditeurs graphiques pour les modifier (XCode en propose un, par exemple), …
Actuellement, faire un programme qui va lire et modifier les configuration de trucs comme Apache ou OpenLDAP est plutôt galère, il faut réécrire un parseur sans savoir si on a pensé à tous les cas… Rajouter et supprimer via un script une entrée dans le crontab est assez périlleux à mes yeux. Avec des fichiers en plist, ces opérations seraient extrêmement simples.
Après, le côté XML peut rebuter un peu (même si à l'usage, ce n'est pas si gênant). Mais comme déjà dit, il suffirait de rajouter un autre format plus humain à plistlib, et ce n'est vraiment pas compliqué…
[^] # Re: Bientôt vendredi
Posté par Tit . Évalué à 1.
En quoi JSON est-il plus pour les barbus que XML?
[^] # Re: Bientôt vendredi
Posté par Alex . Évalué à 2.
moins verbeux, mais c'est une interpretation perso
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # C'est vendredi !
Posté par Buf (Mastodon) . Évalué à 4. Dernière modification le 07 septembre 2012 à 08:25.
Pas vraiment. launchd est devenu une pièce centrale de l'os, et tout comme systemd, ça a commencé à remplacer les services traditionnels Unix comme (x)inetd ou cron. launchd est aussi utilisé pour la gestion des sessions utilisateurs, l'exécution de code à l'insertion d'un média amovible ou le lancement de "helpers" utilisés en interne par une application (c'est devenu particulièrement utile maintenant que le sandboxing devient imposé)
launchd n'offre peut-être tout ce que propose systemd, mais ça va quand même beaucoup plus loin qu'un simple système d'init.
[^] # Re: Bientôt vendredi
Posté par Raoul Volfoni (site web personnel) . Évalué à 8.
Faut vraiment que j'attende encore 20 min ou je peux exploser de rire tout de suite ?
[^] # Re: Bientôt vendredi
Posté par Buf (Mastodon) . Évalué à -2.
Pourquoi ? Il y a quoi de drôle dans cette phrase ?
[^] # Re: Bientôt vendredi
Posté par cedric . Évalué à 3.
Fallait pas t'arreter de lire. Tu as manque :
Si avec tout ca, tu n'es pas entrain de te rouler par terre, tu as vraiment des nerfs d'acier ! Moi pas :-D
# systemd = le nouveau X.Org
Posté par antistress (site web personnel) . Évalué à 2.
De ce que je lis, systemd me fait penser à un nouveau X.Org dans lequel on rajoute plein de trucs au fur et à mesure pour qu'il puisse s'occuper de tout.
Et puis un jour on s'apercevra qu'on a créé un monstre et on essaiera de lui retirer tout ce qu'il gère en trop, et qui pourrait être mieux géré ailleurs.
Mais je dis ça sans aucune compétence, hein. Juste un point de vue distant.
[^] # Re: systemd = le nouveau X.Org
Posté par Anonyme . Évalué à 5.
"Je sais pas de quoi je parle, mais je donne mon avis quand meme".
[^] # Re: systemd = le nouveau X.Org
Posté par Antoine . Évalué à 5.
Bienvenue sur Internet.
[^] # Re: systemd = le nouveau X.Org
Posté par Zylabon . Évalué à 3.
On peut dire ça de tout les gros softs. Si ils sont bien faits ils peuvent rester tout à fait cohérents et grossir encore et encore, comme gcc, au départ c'était juste un compilo C, puis c'est devenu "un monstre" capable de compiler une demi douzaines de langages, sur grosso modo toutes les architectures existantes. Et parfois la technologie évolue ou il y a des avancées théoriques qui rendent les logiciels obsolètes. C'est la vie.
Please do not feed the trolls
[^] # Re: systemd = le nouveau X.Org
Posté par Domi . Évalué à 2.
Avec udev, les nouveaux développeurs (Lennart/Kai) ont déjà réussi à casser le kernel et ils se sont avérés incapable, de fixer leur erreur même après plusieurs mois. Voir udev breakages sur la liste d'email du kernel.
Ce qu'en pense Linus est simple et plein de bon sens:
"Stop this crazy. FIX UDEV ALREADY, DAMMIT."
"What kind of insane udev maintainership do we have? And can we fix it?
Greg, I think you need to step up here too. You were the one who let
udev go. If the new maintainers are causing problems, they need to be
fixed some way.
"Quelle sorte de management débile avons-nous avec udev? Et pouvons-nous le fixer?
Greg, je pense que tu dois intervenir aussi ici. Tu étais celui qui a laissé udev aller. Si les nouveaux responsables créent des problèmes, ils ont besoin d'être fixés d'une façon ou d'une autre."
Et plus loin:
"Je me méfie du fait que les responsables d'udev
semble avoir disparu dans quelque mode "fou", où ils ont fait des changements qui ont été connues pour être problématiques, et sont d'une stupidité pure et absolue.
Ayoir le chemin d'initialisation du module qui charge le firmware est la CHOSE à faire CENSÉE ET ÉVIDENTE dans de nombreux cas. Le fait que les gens d'udev aient apparemment décidé unilatéralement que c'est quelque chose de mauvais est effrayant."
Et encore:
"Arrêtes cette idiotie.
Le noyau n'a pas de problème de blocage. udev a.
En même toi l'avoue, C'est udev qui est responsable de l'entier du problème de sérialisation, et fait une sérialisation excessive (et erronée) entre événements. Le résultat est que le noyau rejète un événement udev qui prend trop de temps.
Le fait que vous ayez ensuite continué à essayer de faire de ceci une «question du noyau" est tout simplement dégoûtant. Parler que le noyau résolve «convenablement» ceci est assez malhonnête, lorsque le noyau n'était pas le problème à la première place. Le noyau non seulement fait bien les choses, mais tout cela avait l'habitude de
fonctionner très bien."
Heureusement que Linus Torvalds est là pour essayer de mettre un peu d'ordre dans une dérive qui pourrait transformer un des meilleurs OS actuel en une suite de bugs et de contre-mesures.
Bref, le futur de systèmed n'est pas encore assuré, et même s'il devient incontournable, il risque de bien changer. Perso, je suis bien content d'être sous gentoo car j'ai le choix de l'installer ou pas, et je suis pas allé plus loin qu'une recherche sur bugzilla. C'est bien joli de vouloir changer des briques de base du système, mais avant de prétendre vouloir les rendre incontournables, il faudrait peut-être commencer par les stabiliser, les déboguer et surtout s'assurer que cela ne cause pas de régression.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.