Marcus Brinkmann revient sur la conception du Hurd et son port sur L4, les problèmes rencontrés, l'avenir et le passé de ceux deux projets. Il donne également son opinion sur des sujets aussi divers que les brevets logiciels, le logiciel libre, la façon de devenir un bon hacker. On y découvre également l'itinéraire, à travers l'informatique et le libre, d'un hacker de talent et engagé.
L'interview est assez longue, mais particulièrement intéressante. Manuel Menal et l'équipe de HurdFR ont traduit cette interview, et l'ont mise à disposition sur le Wiki de l'association, avec l'aimable permission de l'intervieweur et de l'interviewé.
Dans le cadre du FOSDEM a eu lieu un mini-symposium sur le Hurd, où de nombreux développeurs ont pu présenter leurs projets au grand public. Si vous n'avez pas eu la chance d'être présent, la plupart des présentations sont maintenant disponibles sur le Web ! Par ailleurs, dans le cadre du Libr'east, HurdFR tiendra une conférence de présentation au Hurd le samedi 23 avril prochain. Nous tiendrons également un stand pendant tout le week-end : n'hésitez pas à venir découvrir le Hurd et nous rejoindre !
NdMeR : le site Wikinerds est actuellement /.é.
Aller plus loin
- L'interview traduite (11 clics)
- L'interview originale (7 clics)
- HurdFR (5 clics)
- Le Hurd (2 clics)
- Conférences sur le Hurd (2 clics)
- Le site de Marcus Brinkmann (5 clics)
# Ca ne peut pas faire de mal...
Posté par Gyro Gearllose . Évalué à 3.
En tout cas, ça montre que quand même quelques personnes s'intéressent au Hurd.
De mon côté, je serais ravi d'y contribuer, mais je n'ai ni le temps ni les compétences requises. Ceci étant, je testerai avec joie ce noyeau en lieu et place de mon 2.6.11 actuel dès qu'il sera possible de faire cohabiter les deux sans tout péter, et, dans la mesure du possible d'utiliser les applis existantes sans les ré-installer (mais là, ça frise peut-être l'utopie, je n'en sais absolument rien !).
[^] # Re: Ca ne peut pas faire de mal...
Posté par Manuel Menal . Évalué à 10.
GNU/Hurd cohabite même très bien avec GNU/Linux, puisqu'il sait très bien monter les partitions de style ext2 (et ext3). Je partage, pour ma part, des partitions assez importantes comme /src et mon /home (je garde un /home séparé pour GNU/Hurd pour tester mes translators). Je n'ai pas vu de corruption de données depuis des années.
Quant à les faire cohabiter dans un seul et même système, c'est effectivement plus complexe, et pas actuellement faisable. GNU/Hurd n'offre pas de compatibilité binaire avec GNU/Linux - et vu la gymnastique que cela peut obliger, et le peu d'utilité que nous y voyons, ça risque de rester le cas. On ne peut donc pas passer de GNU/Hurd à GNU/Linux sur la même partition simplement en redémarrant : de toutes façons, ça n'est pas souhaitable, puisque l'intérêt du Hurd c'est d'utiliser des applications et systèmes qui utilisent ses particularités (par exemple un système de paquets à base de translators, etc., etc.).
Restent deux pistes :
1. Les techniques de virtualisation classiques a la Xen pourraient bien marcher - en fait, Ognyan, l'auteur du patch ext2, compte y travailler durant l'été. Cela voudrait dire avoir en parallèle GNU/Linux et GNU/Hurd, mais chacun sur leurs partitions.
2. Les techniques de virtualisation liées aux micro-noyaux ; il pourrait être envisageable de faire tourner L4Linux en parallèle avec GNU/Hurd, "a la Xen". Mais ça, c'est pour dans plus longtemps, et ça veut dire une version de Linux modifiée (portée sur L4).
En attendant, installer Debian GNU/Hurd n'est vraiment pas difficile, il suffit d'un peu d'espace en fin de disque et d'un peu de motivation ;-)
[^] # Re: Ca ne peut pas faire de mal...
Posté par Gyro Gearllose . Évalué à 1.
Si il faut ré-installer toutes les applis, y compris l'environnement graphique, KDE, et tout le toutim', c'est clair, pour l'instant, je n'ai pas la place.
Faut pas y voir de la mauvaise volonté de ma part, ni de la critique gratuite, mais ce qui compte, pour moi, c'est d'avoir un PC qui me "sert" à quelque chose, qui me permet de faire des choses utiles pour moi (rédiger mes courriers, faire mes comptes, surfer sur le web et utiliser ma messagerie, entre autres), et installer un OS juste pour voir si ça boot et peut lancer quelques applis, ben non, désolé, je n'ai ni la place, ni le temps.
Je le répète, faut pas mal prendre ce qui est écrit ci-dessus, y'a vraiment aucune offence à prendre.
Par ailleurs, et là, c'est une vraie question de quelqu'un de curieux : le support du matériel est-il le même entre le Hurd et Linux ? Je n'en ai pas la moindre idée, et c'est pour cela que je voudrais bien que quelqu'un éclaire ma lanterne.
Au moment où j'écris ces lignes, tout mon matériel est supporté, fonctionnel et utilisé sous Linux, et ça me ferait mal de faire un retour en arrière sur ce point particulier si jamais un jour proche je trouvais un peu de temps et d'espace disque pour tester (je n'ai jamais dit ci-dessus que je ne voulais pas tester, quand même...)
[^] # Re: Ca ne peut pas faire de mal...
Posté par Zakath (site web personnel) . Évalué à 1.
Je l'ai installé la semaine dernière et mon contrôleur réseau (un bête e1000 pourtant) n'était pas reconnu...
[^] # Re: Ca ne peut pas faire de mal...
Posté par Manuel Menal . Évalué à 4.
Quant au driver e1000, Debian GNU/Hurd inclut le driver intel-gige depuis K8. C'est le driver de Donald Becker (cf. http://www.scyld.com/network.html#gigabit(...) : c'est celui qui a écrit 99% des drivers de cartes réseaux aux débuts de Linux). Si ta carte est supportée, ça -doit- marcher. Sinon, le backport du driver d'Intel est souvent envisageable, mais pas une opération plaisante, c'est sûr.
[^] # Re: Ca ne peut pas faire de mal...
Posté par bmc . Évalué à 2.
Une question (pas forcément adressée à toi mais je sais que tu te feras un plaisir d'y répondre ;) : le GNU/Hurd, que ce soit sur Mach ou sur L4 (plus sur L4 a priori) a-t-il une ambition de supporter les drivers de style I2O, qui à ce que j'en ai compris permettent de développer des drivers en deux parties : une partie générique à tous les systèmes d'exploitation et une partie spécifique à chacun ?
Bien entendu, la question du nombre de périphériques dont les pilotes I2O existent se pose (ça doit être proche du zéro absolu à ma connaissance)...
[^] # Re: Ca ne peut pas faire de mal...
Posté par Manuel Menal . Évalué à 4.
A ma connaissance, ca n'a pas ete evoque. Et la raison en est assez simple : nous n'en sommes pas encore a ce point. Voila pour la version courte.
En un peu plus detaille : comme le dit Marcus dans l'interview, les pilotes de peripheriques seront un element a part dans le port du Hurd sur L4. Le but est de permettre une certaine genericite du serveur d'acces aux peripheriques (deva) pour qu'on puisse integrer des infrastructures de pilotes differentes : il y a un projet dans le CVS du Hurd, nomme fabrica, qui n'a pas beaucoup avance recemment. C'est un travail de recherche, dans la meme optique que le Hurd, ou l'on souhaite decouvrir de nouveaux moyens, simples et efficaces, de concevoir et d'ecrire des pilotes de peripheriques. Il est vraisemblable qu'un DDF (Device Driver Framework) sera ecrit dans le but de permettre l'execution de pilotes Linux via un glue code plus ou moins horrible (c'est largement faisable, ca a ete fait dans de nombreux systemes, mais moyennant des horreurs concernant par exemple la gestion de la memoire - les pilotes de Linux presupposent que la memoire est 'pinnee' (elle ne sera pas swappee)). Un DDF I2O est conceptuellement tres simple : le framework est la partie dependante du systeme, and voila. Mais ca ne me semble pas souhaitable pour fabrica : il y a des choses a etudier et tester concernant les pilotes de peripheriques en espace utilisateur (notamment la resistance aux fortes charges par l'utilisation de memoire paginable (et non 'pinnee')), et se limiter a I2O l'empecherait.
[^] # Re: Ca ne peut pas faire de mal...
Posté par imalip . Évalué à 3.
Juste pour preciser que le driver est un peu (tres) vieux et ne contient le support que pour une poignee de vieilles cartes, toutes en fibre. Les cartes e1000 cuivre ne marchent pas, meme si on ajoute la PCI id et qu'on recompile (en tout cas la mienne ne marche pas).
Allez, un de ces jours je vais etre motive et je vais vraiment me lancer dans le portage de ce foutu driver. Marre d'avoir 2 cartes reseaux dans le PC...
[^] # Re: Ca ne peut pas faire de mal...
Posté par domak . Évalué à 1.
Pas sûr que l'on partage le même sens de l'humour...
[^] # Re: Ca ne peut pas faire de mal...
Posté par Wawet76 . Évalué à 1.
login/pass
killall firefox (ou "killall mozilla-firefox" ptet)
Voila, pour la prochaine fois.
[^] # Re: Ca ne peut pas faire de mal...
Posté par François Becker (site web personnel) . Évalué à 2.
...en même temps c'est un peu un pb du genre "DoS utilisateur" pour Firefox qu'ils devront patcher un jour...
et effectivement c'est pas nécessaire de restarter sa session...
# Hurd et Plan 9
Posté par Sebastien . Évalué à 9.
D'apres ce que j'ai compris, pour Hurd/L4, tout est translator alors que pour Plan9, tout est systeme de fichier. Quels avantages/inconvenients ?
Bon, meme si j'ai commence une petite biblio, c'est encore assez flou...
[1] http://www.ffii.org/~zoobab/bh.udev.org/filez/lightning/2005/19-pla(...)
[2] http://www.cs.bell-labs.com/plan9dist/(...)
[3] http://www.cs.bell-labs.com/wiki/plan9/plan_9_wiki/(...)
[4] http://en.wikipedia.org/wiki/Plan9(...)
[^] # Re: Hurd et Plan 9
Posté par Thomas Petazzoni (site web personnel) . Évalué à 3.
[^] # Re: Hurd et Plan 9
Posté par Gaël Le Mignot . Évalué à 1.
Sinon les confs ont l'air intéressantes, bien =)
[^] # Re: Hurd et Plan 9
Posté par Thomas Petazzoni (site web personnel) . Évalué à 1.
[^] # Re: Hurd et Plan 9
Posté par free2.org . Évalué à 5.
Je pense qu'il faut distinguer:
1. les APIs standards offertes par un OS (Posix, Plan9FS,win32) qui sont en général toujours obtensibles, quitte à ajouter une couche de compatibilité (cf Wine/win32 pour Linux, posix pour win32 et hurd, et plan9FS pour linux et unix )
C'est donc à ce niveau qu'intervient l'API tout-fichier de plan9, plan9FS.
http://v9fs.sourceforge.net/(...)
2. l'architecture interne de l'OS (taille du noyau, quantité de services en userspace ou kernelspace,...). C'est à ce niveau qu'intervient l'architecture de Hurd, avec ses serveurs en userspace qui ne compromettent pas le reste du système en cas de bug.
Maintenant c'est vrai que pour faire une application très fiable, il est tentant de s'appuyer directement sur l'interface de bas niveau d'un micronoyau simple (comme L4) et éventuellement sur un petit nombre de serveurs dont on aura audité le code.
Si un bug compromet un des autres serveurs qu'on a pas audité, on s'en fout.
# coyotos proven OS, inspiré de EROS
Posté par free2.org . Évalué à 10.
Le projet Coyotos (inspiré d'anciens noyaux similaires comme EROS) se propose d'en faire un très petit (atomique), qui aura une couche de compatibilité Linux, à l'aide d'un langage facilitant les preuves formelles (BitC):
http://coyotos.org/(...)
http://www.eros-os.org/(...)
[^] # Re: coyotos proven OS, inspiré de EROS
Posté par Thomas Petazzoni (site web personnel) . Évalué à 3.
Le résumé de ces conférences et le programme complet du thème est disponible sur : http://www.rencontresmondiales.org/sections/conference/noyau_et_sys(...)
Vous verrez que Marcus Brinkmann y fait aussi une conférence. Neal Walfield, un autre développeur important du Hurd pourrait aussi faire une prestation.
# Graine de geek !
Posté par Obsidian . Évalué à 4.
Tout le monde a donc suivi le même chemin ?
[^] # Re: Graine de geek !
Posté par Antoine J. . Évalué à 10.
Non.
J'ai moi aussi écrit ce genre de programme, mais je n'ai jamais dépassé ce niveau.
[^] # Re: Graine de geek !
Posté par Nicolas Schoonbroodt . Évalué à 3.
Mais par contre, il n'y avait pas d'animation. Mais ca permettait d'enregistrer ses résultats et de visualiser ses progrès sur un graphique. Mais après, je ne suis pas devenu un des contributeurs principal du (de GNU/) Hurd. Rendez-vous dans dix ans? (je ne pense pas, en fait)
[^] # Re: Graine de geek !
Posté par Ontologia (site web personnel) . Évalué à 2.
Belle prise de tête à 11 ans :)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Graine de geek !
Posté par Obsidian . Évalué à 2.
# Mouai
Posté par Philippe F (site web personnel) . Évalué à 4.
Ce truc a tres peu d'applications pratiques. Un des avantages de Linux, et ce qui l'a tres vite distingue de minix, c'est qu'il est utile concretement. A cote de ca, Hurd reste un exercice de style.
Le fait est qu'un noyau reste un truc pour gerer du materiel. Mon impression est que Hurd veut reussir a abstraire completement cette partie, et que ca donne des resultats sous-optimaux, comme les problemes qu'il decrit avec la gestion de la memoire. Autant je pense qu'on peut faire abstraction de beaucoup de choses au niveau langage de programmation, autant je ne suis pas persuade que ca s'applique aussi bien a un OS (meme si PDP11 faisait des merveilles avec sa macine lisp, il parait).
Deporter la gestion de la memoire du cote des applications. Super! J'essaie de reflechir a quelle application de nos jours aurait besoin de sa propre gestion memoire. Ce serait soi des applications avec des besoins de tres grosses quantites, soit des applications avec des besoins de beaucoup de petites quantite (ce qui pousse parfois a re-ecrire son gestionnaire de memoire, le modele classique etant plutot adapte a des allocations de gros blocs de facon non repetees). Je suis curieux de savoir si dans la pratique, c'est super lourd a gerer ou s'il suffit juste de linker avec libmemory et ca marche tout seul.
Je pense aussi aux remarque d'Alan Cox, sur l'obsolescence du modele Hurd en tant que station de travail. Hurd est oriente serveur avec plusieurs utilisateurs, ce qui etait l'environnement classique de travail de l'epoque ou il a ete concu. Aujourd'hui, avec des postes PC mono-utilisateurs tout puissants, qui a besoin de monter son systeme de fichier en mode utilisateur ?
Ca n'enleve rien a la qualite du travail effectue, c'est juste que un peu comme quake en ascii-art, ca reste un exercice de style.
[^] # Re: Mouai
Posté par Sebastien . Évalué à 2.
Humm...
Pour la premiere partie de la phrase je dirais quand meme que historiquement, on oscille toujours entre (gros serveurs + clients legers) et (petits serveurs+PC puissants), aux gres de la bande passante et du rapport qualite/prix/puissance des postes clients.
Un exemple est justement le truc de Bell (Plan9) qui se redirige vers l'integration d'une multitude de petits/gros clients dans un "truc" plus gros.
Ensuite je suis d'accord que pour Mme Michu, hein... Mais en meme temps, comme on lui promet la Grille a Mme Michu, autant qu'elle ait quelque chose qui s'integre bien dedans.
Ayant plus ou moins invalide la premiere partie de la phrase (ou en tout cas l'ayant nuancee), je mets sous le tapis la seconde partie :)
[^] # Re: Mouai
Posté par Manuel Menal . Évalué à 10.
PieD posait la même question sur : http://linuxfr.org/comments/532262.html#532262(...)
patrick_g posait la même question sur : http://linuxfr.org/comments/517501.html#517501(...)
des liens vers des commentaires plus vieux : http://linuxfr.org/comments/309640.html#309640(...)
Quant à la gestion de la mémoire, je n'imagine pas que quelqu'un avec une grande d'expérience de la programmation puisse penser que ça ne sert à rien. D'abord, pour ta curiosité : en pratique, il y a la bibliothèque libhurd-mm qui est automatiquement injectée dans l'espace d'adressage de ton application. De la même façon que dans beaucoup de systèmes une bibliothèque de compatibilité est injectée au démarrage. Pour changer de gestionnaire, il suffit en effet de fournir sa propre implémentation ou de lier avec une implémentation toute faite. Transparent pour les applications traditionnelles, et très simple pour les applications spécialisées. Je pense que Marcus a donné un excellent exemple de ce qu'une gestion des ressources décentralisée et contractualisée peut permettre (son + gravure).
Premier exemple plus important sur l'auto-pagination : les applications multimédia. Pour les applications multimédia assez spécifiques - mais grandement utilisées, j'en utilise moi-même -, les systèmes conventionnels sont très mal adaptés : en particulier, la gestion du swap amène à des catastrophes telle l'interruption d'un stream, ce qui va casser tout ton montage ou tout ton calcul. Pour ça, beaucoup utilisent des systèmes "vertically structured", ce qui se rapproche grandement des exo-noyaux (sauf qu'en général les premiers sont dans un seul espace d'adressage, et que ça n'est pas toujours le cas des seconds). C'est par exemple le cas de Nemesis. Je t'invite à lire le papier qui présente ce système et sa raison d'être. Si tu as le temps, travaille également le papier de thèse sur son implémentation : tout ce qui lui manque, c'est le fait qu'on le laisse tranquille pour gérer sa mémoire, et si possible, son temps CPU. C'est d'ailleurs la principale motivation des exo-noyaux : laisser les applications faire ce qu'elles veulent dans leur coin. La gestion de la mémoire décentralisée, c'est reprendre l'approche "exo-noyau" pour un point simple, qu'on sait marcher sans compromettre la sécurité le moins du monde. Et ça permet une scalabilité (oooh que c'est joli !) que Linux n'a pas, et qu'il n'aura probablement jamais. Avoir un seul système pour toutes les utilisations (dans un certain rang : tout système qui a une MMU par exemple) devrait être notre but, parce que ça permet de démocratiser beaucoup de domaines, et parce que ça simplifie énormément d'avoir les mêmes outils, les mêmes interfaces qu'on soit en train de faire du montage ou en train de jouer ou en train de faire de l'IRC.
Pour un autre exemple : on sait très bien qu'un SGDB, ça n'est qu'un énorme cache. C'est à dire qu'il a besoin d'une quantité de temps CPU relativement importante à des moments très précis, mais que dans la majorité du cas, il peut facilement donner du temps CPU pour gagner du temps. L'auto-pagination s'accompagne forcément d'un mécanisme de négociation des ressources. C'est à dire que plutôt que malloc() aille taper dans la mémoire du système jusqu'à ce que les quotas soient épuisés ou que simplement il n'y ait plus de mémoire virtuelle (et là, OOM killer!), quand on a plus assez de mémoire physique pour son utilisation, on va essayer d'en négocier avec un gestionnaire de ressources. Ce gestionnaire de ressources connaît ce qui est disponible, ce qui est rare, ce qui ne l'est pas. Il distribue aussi bien de la mémoire physique que du temps CPU. Il va de soi que notre SGDB va donc immédiatement échanger son temps CPU contre sa mémoire, et tenter l'opération inverse quand il en a besoin - ou alors se réserver juste un quota de temps CPU suffisant aux opérations classiques, dont il a relativement facilement connaissance. Un tel principe de contrat a été implémenté et testé en utilisant comme base le modèle du marché (chaque tâche dispose de X EUR au démarrage avec lesquels elle achète tant de mémoire, tant de temps CPU, ... ; avec le temps, il y a inflation ou déflation pour chacune des ressources ; ainsi, les applications pourront racheter de la mémoire contre peu de temps CPU quand elle sera peu chère (beaucoup de mémoire disponible), et beaucoup dans le cas inverse) : les améliorations sur un SGDBR étaient d'environ 40, 45%. Et je pense que personne qui s'est déjà penché sur un SGDBR ne contestera les chiffres : ils reflètent très bien la réalité de ces applications.
That's all, folks.
[^] # Re: Mouai
Posté par Matthieu Lemerre (site web personnel) . Évalué à 5.
Et que le nombre de schedulers et schedulers IO du noyau Linux, chacun optimises pour des usages typiques differents (anticipatory, Deadline...) , laisse presager que permettre aux applications de decider par elles meme de leurs besoin accroitrait grandement les performances.
Enfin, pour citer Alan Cox au FOSDEM 2005 :
"'Once you fix the VM for one use case, it breaks for another' part".
Le choix du Hurd de supporter tous les cas d'utilisation, et pas seulement LRU, est donc le meilleur possible.
http://l-lang.org/ - Conception du langage L
[^] # Re: Mouai
Posté par fabb . Évalué à -1.
> "'Once you fix the VM for one use case, it breaks for another' part".
> Le choix du Hurd de supporter tous les cas d'utilisation
Je crois que Alan Cox veut dire qu'il n'y a pas de solution miracle. Pour Hurd ça veut dire que hurd n'arrivera jamais à supporter tous les cas d'utilisation.
[^] # Re: Mouai
Posté par fabb . Évalué à 2.
Hmmm.
Actuellement sous Linux si tu veux faire quelque chose de fin, tu alloues un gros bloque mémoire et tu fais ton taf dedans.
Cette grosse allocation mémoire ne bouffera pas de mémoire tant que tu n'écris pas dedans. Tu peux utiliser alloc pour que la mémoire soit réellement allouée.
> D'abord, pour ta curiosité : en pratique, il y a la bibliothèque libhurd-mm
Quoiqu'il en soit, le programme est toujours dépendant de la gestion mémoire de hurd est c'est incontournable. Je ne vois pas par quel miracle un programme pourrait imposer sa gestion mémoire à l'OS. Hurd gère le swap, je ne comprend pas comment plusieur applis à la fois pourrait gérer le swap sans tout faire exploser.
> Je pense que Marcus a donné un excellent exemple de ce qu'une gestion des ressources décentralisée et contractualisée peut permettre (son + gravure).
Mouaiff. Pour le son et la gravure, des posibilités d'autoriser un quota pour locker la mémoire sont possibles depuis Linux 2.6.8. La quantité disponible est paramétrable avec ulimit. C'est actuellement peut utilisé car peu critique. gnupg l'utilise pour éviter que les mots de passe soit en swap (par défaut une appli peut locker 8k).
Si on veut plus de souplesse, on peut passer par pam et utiliser un système type console-helper pour fixer le "ulimit" qui va bien.
> Pour les applications multimédia assez spécifiques - mais grandement utilisées, j'en utilise moi-même -, les systèmes conventionnels sont très mal adaptés : en particulier, la gestion du swap amène à des catastrophes telle l'interruption d'un stream, ce qui va casser tout ton montage ou tout ton calcul.
J'enregistre la TV avec mon PC tout en fesant d'autres choses. Avant de lancer mencoder, je change le scheduler et ulimit (pour mlockall). mencoder n'a pas de droit root (seul le programme qui change le scheduler et ulimit l'a et il est ridiculement petit).
Ainsi, je fais ce que je veux et ça enregistre sans accro.
Ceci a des limites et Hurd a aussi cette limite. J'ai un athlon 1700 et ça passe. Mais si j'avais deux cartes TV et voulais enregistrer deux chaines en même temps, ça ne peut pas passer et mon système serait inutilisable (tout le temps cpu serait affecté à mencoder).
Enfin pour des raisons de sécurité on ne peut pas laisser n'importe quel programme demander un scheduler temps réel ou de locker la mémoire. C'est valable pour tous les OS.
> Avoir un seul système pour toutes les utilisations (dans un certain rang : tout système qui a une MMU par exemple) devrait être notre but,
Jusqu'à maintenant Linux y réussi très bien.
> on sait très bien qu'un SGDB ... il n'y ait plus de mémoire virtuelle (et là, OOM killer!)
Bof. Avec Linux, si ton système héberge un SGDB ou des applis critiquent, tu peux configurer la vm pour qu'un malloc soit "garanti". C'est à dire que si le malloc ne retourne pas NULL, la mémoire sera utilisable (pas de segfault ni de OOM killer). Le problème c'est que ça bouffe beaucoup de mémoire et en général c'est désactivé.
Un bon SGDB comme PostgreSQL ne fait pas de malloc() côté serveur. Donc il n'a pas ce problème de "OOM killer"). Fais un strace sur postgresql si tu en doutes.
L'arrivée de Xen peut fournir encore plus de souplesse sans perte de performance.
> ou alors se réserver juste un quota de temps CPU suffisant aux opérations classiques
Si chaque appli peut se réserver un quota de temps CPU, on va assurément à un clash. C'est pour celà que pour demander les scheduler temps réel de Linux il faut être root.
> les améliorations sur un SGDBR étaient d'environ 40, 45%.
Tu as la source ?
Ce qui me gène beaucoup avec ton type de commentaire c'est :
1- on ne comprend pas tout (je suis peut-être trop con)
2- il y a des omissions lourdes
Dire que n'importe quelle applis peut choisir sa gestion vm ou son scheduler est garantir un énorme de sécurité (DOS).
Puisque les resources sont limitées, c'est à l'OS (un élément central) de distributer, d'arbitrer les demandes de ressources et non aux applis. Sinon n'importe quelle application peut tout faire exploser.
[^] # Re: Mouai
Posté par galactikboulay . Évalué à 3.
L'argument qui tue. malloc() n'est pas un appel système, strace ne le voit donc pas.
Les appels systèmes qui montrent une activité au niveau de la gestion mémoire, c'est mmap(), brk() et sbrk().
[^] # Re: Mouai
Posté par galactikboulay . Évalué à 2.
[^] # Re: Mouai
Posté par fabb . Évalué à 1.
L'argument qui tue... j'ai dit malloc() pour tout ce qui est lié aux demandes mémoires.
De tout manière, tu veux aussi vérifier que PostgreSQL (côté serveur) ne fait pas de malloc(3) avec ltrace.
[^] # Re: Mouai
Posté par galactikboulay . Évalué à 1.
Ouais, rattrapage aux branches detected.
Oui, là ça marche vu que ltrace(), en plus d'afficher les appels systèmes effectués comme strace, enregistre les appels aux fonctions des librairies chargées dynamiquement.
Quoiqu'il en soit, pour ta gouverne, il est possible d'allouer de la mémoire en utilisant mmap() avec le flag MAP_ANONYMOUS (pour les OS qui le supportent, ça va de soi). malloc() est loin d'être la seule méthode d'allocation.
[^] # Re: Mouai
Posté par fabb . Évalué à -2.
> Quoiqu'il en soit, pour ta gouverne, il est possible d'allouer de la mémoire en utilisant mmap() avec le flag MAP_ANONYMOUS (pour les OS qui le supportent, ça va de soi). malloc() est loin d'être la seule méthode d'allocation.
Et ?
Tu vas nous passer en revu tous les moyens et tous les flags pour faire des allocations mémoire ?
Et pour ton info, un mmap avec un descripteur de fichier est aussi une allocation mémoire. C'est une projection en mémoire et donc il faut de la mémoire.
[^] # Re: Mouai
Posté par galactikboulay . Évalué à 5.
Déjà j'avais pas prétendu quoi que ce soit sur le comportement de Postgres, mais si tu y tiens:
Exemple:
[...]
memcpy(0x82eb36c, "", 4) = 0x82eb36c
memcpy(0x82eb370, "", 4) = 0x82eb370
memcpy(0x82eb374, "", 4) = 0x82eb374
memcpy(0x821fa27, "B\377\267\377\377\376", 368) = 0x821fa27
snprintf("FETCH 2", 64, "%s %u", "FETCH", 2) = 7
strlen("DeferredTriggerTupleContext") = 27
strcpy(0x8299748, "DeferredTriggerTupleContext") = 0x8299748
malloc(8192) = 0x82c5f98
free(0x82c5f98) =
strlen("FETCH 2") = 7
memcpy(0x821fb97, "C", 1) = 0x821fb97
memcpy(0x821fb98, "FETCH 2", 8) = 0x821fb98
memcpy(0x821fba0, "Z", 1) = 0x821fba0
sigemptyset(0xbfffe584) = 0
[...]
[^] # Re: Mouai
Posté par fabb . Évalué à -4.
Si c'est sur le fork, c'est "normal". Il supporte les plantages (entre autre à cause des triggers, fonctions utilisateur écrites en C, etc), dans ce cas une nouvelle connection le relance. Aucune donnée n'est perdue, les transactions en cours sont annulées (en fait elles ne sont pas réalisées, elles seront annulées plus tard). Un système IPC assure la communication entre ces frontend du moteur et postmaster gère les conflits, accès concurrents, etc.
C'est postmaster (non ces fork) qui ne doit pas tomber. S'il tombe, c'est la merde.
[^] # Re: Mouai
Posté par galactikboulay . Évalué à 7.
Sinon sur le postmaster (donc le process principal), un ltrace me donne:
sigprocmask(2, 0x8256920, NULL) = 0
select(5, 0xbfffeb80, 0xbfffeb00, 0, 0xbfffeae8) = 1
sigprocmask(2, 0x82569c0, NULL) = 0
calloc(1, 620) = 0x826edc8
accept(3, 0x826ee3c, 0xbfffea78, 28127, 0x826edc8) = 8
getsockname(8, 0x826edcc, 0xbfffea78, 28127, 0x826edc8) = 0
setsockopt(8, 6, 1, 0xbfffea74, 4) = 0
setsockopt(8, 1, 9, 0xbfffea74, 4) = 0
Il y a aussi quelques petits malloc() qui trainent à droite à gauche.
Si c'est sur le fork, c'est "normal".
Faudrait savoir. En tout cas dans ma logique à moi, c'est incompatible avec une assertion du type "La partie serveur de Postgres ne fait pas de malloc()".
[^] # Re: Mouai
Posté par Gaël Le Mignot . Évalué à 10.
Ce n'est pas la même chose dont manuel parlait. Là, tu parles de comment un processus va gérer son espace d'addressage virtuel, et là, bien sûr, il peut faire ce qu'il veut que ce soit sous GNU/Linux ou GNU/Hurd.
Ce dont manuel parlait, c'est de la gestion de la mémoire physique. L'exemple le plus simple, c'est "quelle page swapper". Sans même aller chercher loin (les méchanismes de négociation de ressources), considérons juste un système qui au lieu de swapper une page en essayant de déterminer comme il peut (LRU, aging, ...) laquelle est la moins utilisée, va demander à l'application "désigne une page, et elle sera swappée". Pas de compromission de sécurité là-dedans, le système choisi toujours dans quelle application la page est prise, mais l'application choisi laquelle, avec les connaissances qu'elle a sur les données, et que le système ne peut pas avoir. Variante: l'application dit au système "ces pages là je veux pas les swapper, si jamais t'as envie d'en swapper une, je t'offre ces pages là à la place" (ce que l'on nomme pages de compensation). Ce genre de méchanisme peuvent grandement améliorer l'efficacité dans certaines conditions.
On peut aussi, sous GNU/Hurd (et même sous Mach, pour ça), parfaitement envisager différents niveaux de swap: compressé en mémoire (on se contente de compresser les pages sans les envoyer sur le disque), sur le disque, sur le réseau, compressées sur le disque, compressées sur le réseau, ... l'application pouvant choisir, suivant le type de données (bon taux de compression ou non, est-ce qu'on risque d'en avoir besoin ou non, ...), quel "swap" utiliser pour quelle page.
Je t'ai donné deux exemples simples de possibilités de gestion évoluée de la mémoire, si tu veux des exemples plus poussés, tu peux lire http://l4ka.org/publications/paper.php?docid=659(...) par exemple.
La question n'est pas là, la question un SGBDR qui va s'adapter, en troquant temps CPU (lookup) contre mémoire (cache) suivant les disponibilités des deux dans le système. Ce dont tu parles, c'est d'éviter les OOM-kill lorsque la swap est pleine, mais ça n'empêche en rien que le système va "trasher" (faire énormément de swap-in/swap-out) dans certaines situations. Ou qu'un programme va faire un abort() vu que son malloc a renvoyé NULL et qu'il ne peut plus s'en sortir.
malloc n'est pas un appel système, malloc repose sur brk/sbrk et mmap. PostgreSQL utilise au moins l'un des deux (probablement mmap, peut-être les deux) et est donc tout autant vulnérable au OOM-kill que n'importe quelle autre application.
J'ai donné deux exemples simples pour le mémoire, qui n'ouvrent la porte à un aucun DoS.
Pour le CPU, on peut par exemple concevoir un système où le temps CPU est réparti non entre processus, mais entre utilisateurs (avec des règles données par l'administrateur système), et où chaque utilisateur peut lui gérer comme il le souhaite le temps CPU pour ses propres applications (par exemple, son xmms sera prioritaire sur ses gcc et son firefox, de la manière qu'un processus RT l'est sous Linux, mais uniquement vis à vis du temps de l'utilisateur). Après, on peut concevoir des systèmes encore plus poussés, à base de contrats par exemple: le système "vend" à xmms un contrat valable 5 minutes pour avoir, de manière sûre, 10ms de temps CPU toutes les secondes. Le prix de cette "vente" dépendra de la charge de la machine. Au bout de 5 minutes, xmms devra renégocier le contrat. Si la charge de la machine est plus élevée, il ne pourra peut-être pas le payer, mais en général accorder un temps garanti d'1% à une application est parfaitement possible, même quand le système est chargé (grosse compilation, ...). Les possibilités offertes sont nombreuses, et l'un des avantages majeurs des systèmes à base de micronoyau est que l'on peut facilement développer une solution adaptée à la situation exacte (ou modifier une solution existante).
Pour finir, une petite ouverture du sujet: c'est ça aussi, rendre la liberté aux utilisateurs (le but du projet GNU). Comme en politique d'ailleurs. Il y a la liberté légale (la licence l'autorise), qui ne peut être que théorique non praticable, et la liberté garantie (la licence l'autorise et le système le rend possible). C'est toute la différence entre "droit de chercher un emploi" (et sa variante "droit de travailler") et "droit d'obtenir un emploi" (et sa variante "droit au travail") par exemple, mais c'est un autre débat ;)
[^] # Re: Mouai
Posté par fabb . Évalué à 4.
OK, je comprend l'idée et elle est intéressante. Sans aucun doute elle mérite une étude approfondie.
Pour désigner les pages à swapper prioritairement, l'architecture de Linux ne me semble pas pénalisante pour le faire par rapport à Hurd. On peut déjà verrouiller des pages spécifiques en mémoire. Ici l'idée est de dire à l'OS : "s'il te plait, évites de swapper cette page".
> La question n'est pas là, la question un SGBDR qui va s'adapter, en troquant temps CPU (lookup) contre mémoire (cache) suivant les disponibilités des deux dans le système.
Là aussi j'ai compris l'intérêt :-)
> PostgreSQL utilise au moins l'un des deux (probablement mmap, peut-être les deux)
Oui et non. Mais l'architecture est faite pour que le SGDB (côté serveur) ne plante pas à cause d'un manque de mémoire. Au pire quelques transactions en cours sont abandonnées et les clients doivent refaire une connection. Tous les clients n'ont pas à se reconnecter. Seulement ceux dont le processus côté serveur a planté. L'architecture est différente de MySQL.
Mais je confirme que postmaster (le père des postgres côté serveur) n'a pas de mmap(), etc... Évidement qu'il utilise mmap() etc à son initialisation. Mais une fois qu'il est lancé il n'en fait plus.
> Pour le CPU, on peut par exemple concevoir un système où le temps CPU est réparti non entre processus, mais entre utilisateurs
> ...
> et où chaque utilisateur peut lui gérer comme il le souhaite le temps CPU pour ses propres applications
Dans la limite des quotas qu'on lui a donné. Sous Linux on peut toujours diminuer les privilèges, jamais les augmenter (sauf root).
> par exemple, son xmms sera prioritaire sur ses gcc et son firefox, de la manière qu'un processus RT l'est sous Linux, mais uniquement vis à vis du temps de l'utilisateur
Linux a trois classes d'ordonnanceur. Deux classe temps réel (très contraignantes et assez dangereuses à utiliser) avec plusieurs niveaux de priorité et une classe "sans privilège". Ici tu parles d'avoir une indirection supplémentaire (l'utilisateur) pour la classe "sans privilèges" et de partager le cpu en premier par utilisateur. J'aime l'idée et j'aimerai la voir réaliser (surtout dans le cas d'un type qui compile avec "make -j 20" :-) afin de ne pas emmerder les autres).
Mais Hurd ne me semble pas "nécessaire" pour ça comme il n'est pas nécessaire d'implémenter la vm côté utilisateur. Il ne semble pas plus difficile de le faire sous Linux que sous Hurd.
> le système "vend" à xmms un contrat valable 5 minutes pour avoir, de manière sûre, 10ms de temps CPU toutes les secondes. Le prix de cette "vente" dépendra de la charge de la machine. Au bout de 5 minutes, xmms devra renégocier le contrat.
Mouaif... Et si xmms n'a pas ce contrat ? Il arrête le lecture ou il continu est se disant que ça va peut-être passer ?
Je pense qu'il va prendre la seconde voie. Si finalement il n'a pas assez de cpu, il faut afficher une message. Donc tel que je le vois, ce n'est pas très intéressant.
De plus, pour xmms tu parles plus d'un problème de latence que d'un problème d'allocation de temps cpu. Pour la latence, Linux 2.6 est assez remarquable "natuellement". Pour mencoder, j'ai un problème de disponibilité de cpu et pas de latence (sauf forte charge ou pages swapées).
> Pour finir, une petite ouverture du sujet: c'est ça aussi, rendre la liberté aux utilisateurs (le but du projet GNU).
Mouaif... Qui donne le plus de liberté actuellement : Linux ou Hurd ?
Actuellement c'est Linux car il permet plus de chose. Que ça n'empêche pas Hurd de continuer avec cet objectif.
> C'est toute la différence entre "droit de chercher un emploi" (et sa variante "droit de travailler") et "droit d'obtenir un emploi" (et sa variante "droit au travail") par exemple, mais c'est un autre débat ;)
L'analogie n'est pas bonne.
Si Hurd c'est "droit d'avoir 1 Gflops par processus", ça ne marchera pas si la bécane n'est pas assez dimensionnée par rapport aux nombres de processus.
Linux c'est "vous avez droit à ce que je peux vous accorder ; inutile de faire des réclamation mais sachez que je fais de mon mieux".
Merci pour ces excellentes précisions.
[^] # Re: Mouai
Posté par Gaël Le Mignot . Évalué à 6.
Je vais répondre d'un bloc à la série d'arguments du même genre. Si, pour un truc bien précis (choisir la page, offrir des pages de compensation, choisir le type de swap, rajouter une indirection utilisateur, ...) c'est faisable sous Linux, ce que Hurd donne, c'est une flexibilité à ce niveau là, qui permet d'implémenter beaucoup de ces politiques sans toucher au noyau lui-même, et pour beaucoup d'entre elles, sans être root. Si le root a choisi de diviser le temps CPU par utilisateur, après, moi je peux implémenter et lancer mon propre scheduler, qui répond à mes besoins, pour scheduler mes process, sans avoir à passer par le root, et encore moins à rebooter la machine.
Idem pour le pager, une application très particulière (par exemple, un logiciel de traitement qui utilise des grandes quantités de données très facilement compressables par un algorithme bien spécifique) va être "livré" avec un pager spécifique, qui va gérer ça sans avoir besoin de patch noyau, de module noyau, de droits roots, ...
Oui, il va continuer quand même, et ça risque de sauter un peu... dans le pire cas, on revient au même.
Pas suffisante, même avec preempt, si je torture un peu ma machine (genre quelques bonnes grosses compilations et qu'en même temps j'embête le serveur X par exemple, xmms saute un peu (sur mon athlon xp2400+). L'idée là c'est que même si tu as 30 process qui chacun veulent 100% du CPU, donner 1% garanti à intervalles réguliers (et c'est là la clef) à un processus n'est pas du tout impossible, et ne constitue pas un réel privilège pour le xmms.
On ne peut pas comparer un système en cours de développement intensif avec un qui est en version en "stable" depuis longtemps... c'est un peu comme si tu disais qu'un concorde vole moins vite qu'un biplan parce que le dit concorde n'est pas encore complètement assemblé...
Si si, totalement. Linux dit "la licence vous permet de changer le scheduler, la VM, ... et d'en faire ce que vous voulez", mais n'en donne pas vraiment la possibilité pratique, soit à cause des effets de bord (on se rappellera tous l'épisode du noyau 2.4, où on avait le choix entre plusieurs VMs, mais où certains filesystems ne marchaient qu'avec certaines VMs, ...), soit parce que changer le noyau est une tache difficile, qui nécessite d'être root, et souvent de rebooter la machine (lorsqu'on touche au scheduler ou à la VM). Donc c'est bien le même genre de différences.
[^] # Re: Mouai
Posté par fabb . Évalué à -3.
J'ai bien compris ce gain "théorique". J'ai simplement constaté que pour les cas pratiques que tu indiques, les solutions "pratiques" sont implémentables sous Linux.
> Pas suffisante, même avec preempt
Preempt il ne sert à rien actuellement. D'ailleur je ne l'ai jamais utilisé :-)
> L'idée là c'est que même si tu as 30 process qui chacun veulent 100% du CPU, donner 1% garanti à intervalles réguliers (et c'est là la clef) à un processus n'est pas du tout impossible, et ne constitue pas un réel privilège pour le xmms.
Tu parle encore de latence. Il n'y a pas de difficulté majeur pour faire tourner un process qui utilise 1 % de cpu avec une charge à 30.
Pour xmms, le vrai problème n'est pas le noyau mais l'intéraction avec X11.
> qu'en même temps j'embête le serveur X par exemple, xmms saute un peu
Le problème c'est X11. X11 traite des donnés puis s'occupe des données envoyés par xmms. X11 traite les données de façon séquenciel.
J'ai la change d'avoir une carte graphique mga et j'ai installé le driver mga_vid. Avec ce driver (et mplayer), j'affiche des videos sans occuper X11 (l'affichage est toujours fait sous X11, c'est une sorte d'overlay). Si une vidéo bouffe en gros 20 % du cpu, je peux monter à 4 ou 5 de charge sans le moindre accro. Si j'écoute un ogg/vorbis avec un programme qui n'intéragit pas avec X11 je peux monter à une charge de 20 ou 30 sans le moindre accro.
Les deux gros points durs sous Linux sont :
- l'intéraction avec X11 lorsque plusieurs applis envoient des données à X11.
- les pages qui passent en swap alors qu'elles vont être utilisées dans la milli-seconde qui suit.
Pour les pages qui passent en swap, Linux propose déjà une solution (à déployer mais je ne suis pas convaincu que beaucoup d'appli le fasse car ce n'est pas très critique).
Pour X11, je ne suis pas convaincu que Hurd puisse améliorer la situation.
Exemple, avant d'avoir la carte mga et le driver mga_vid, je passais par l'extension XV de X11. J'avais beau mettre mplayer et/ou X11 en temps réel, il y avait toujours des accro :
- X11 reçoit une requête d'un programme lambda, la traite, ça prend 100 ms.
- mplayer prends la main, mais déjà 100 ms sont passés et t'as perdu au moins une image
Tu peux activer mplayer avant que X11 finisse la requête du programme lambda, ça ne change rien. L'affichage de mplayer sera fait lorsque la requête du programme lambda sera terminée. A moins de changer l'architecture d'X11, on ne peut échapper à ce problème.
> Si si, totalement. Linux dit "la licence vous permet de changer le scheduler, la VM
Ce n'est pas comme ça que j'entendai les choses. J'ai pris le point de vu de utilisateur. L'utilisateur a plus de posibilité/liberté avec Linux qu'avec Hurd actuellement.
[^] # Re: Mouai
Posté par patrick_g (site web personnel) . Évalué à 5.
Quelle mauvaise foi ;-)
Alors que je m'étais fendu d'une quasi-capitulation en rase campagne !
Après ta longue réponse j'avais notamment écrit :
oummffff......je deteste dire ça mais la je crois que j'ai pas le choix : ton plaidoyer est très convaincant et je suis pas loin d'avoir changé d'avis !
c'est vrai qu'il y a beaucoup d'avantages auxquels je n'avais absolument pas pensé.
# Hurd Live CD
Posté par fabb . Évalué à 1.
[^] # Re: Hurd Live CD
Posté par Sylvain Briole (site web personnel) . Évalué à 2.
http://www.osnews.com/comment.php?news_id=10045#350748(...)
[^] # Re: Hurd Live CD
Posté par fabb . Évalué à 1.
Le site semble osnewser. Mais sur la page il me semble qu'il était clairement indiqué que ce n'était pas à mettre entre toutes les mains.
# L'interview de Marcus Brinkmann
Posté par dick_tracy . Évalué à 0.
Dans l'interview, Marcus Brinkmann nous explique une grosse erreur trouvée dans sur le soft d'un PDA... Il nous explique aussi le manque de compétence de la plupart des informaticiens dans ce domaine. Je suis d'accord avec lui. Mais es-ce bien la réalité ? Sur 100 développeurs, combien sont des vrais coder?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.