Je réponds en vrac à des commentaires qui me semblent de toutes façons insensées.
Tout d'abord, je connais la distinction entre journaux publics et journaux privés, merci : je suis relecteur DLFP, et j'ai été modérateur depuis des années. Si j'ai choisi d'en faire un journal public, c'est volontairement. Est-ce que quelqu'un a vraiment lu le journal ? Vous vous rendez compte qu'il s'agit d'un démenti et d'un appel au calme afin que le MRAP puisse enfin répondre ? La nature même du journal en fait un journal public, puisqu'il veut toucher un maximum de gens.
Sur l'ampleur du phénomène : le responsable de la communication est totalement débordé depuis hier ; ils ont reçu une très grande quantité de mails. Je n'ai pas réagi immédiatement en recevant le spam - je suis proche du MRAP, et ce ne sera pas la première fois que je reçois des propos insultants sur le MRAP. J'ai réagi uniquement quand :
1) Pas moins de 8 personnes sur IRC ont réagi, en moins d'une heure. Extraits :
- "trop merci le spam du mrap qui te demande photocopie de la carte d'identité pour te désincrire"
- "put1 le spam que je viens de recevoir là, un mail du MRAP"
- "putain mais le MRAP qui spamme"
(...)
2) Une news a été proposée.
3) Le site a commencé à ne plus répondre.
Je pense que ça montre assez nettement que non, ça n'est pas franchement "trop gros". Je rappelle que les gens ne lisent généralement pas les spams qu'ils reçoivent attentivement, comme ceux qui ont lu le spam join l'ont forcément fait. En passant très rapidement dessus "ah, du spam" "ah, je m'en fous" "ah, c'est du MRAP" "ah, comment on se désinscrit" "arf mais carte d'identité", on ne réagit pas forcément. Qui plus est, je doute que seulement l'un d'entre vous aille vérifier sur hoaxbuster à chaque spam qu'il reçoit. Et tout le monde n'a pas cette culture, et ne connaît pas le MRAP : mais d'ores et déjà quand ils les verront, ils auront pour le moins un a priori négatif.
Je sais d'expérience que ce genre de choses plombe une association, déjà trop souvent controversée du fait de son fort engagement.
À propos de mettre le spam en lien : je ne crois pas qu'en taisant ce genre de propos, on les fasse reculer. J'ai hésité à fournir le lien ou à intégrer dans le journal, ou à n'en donner que des extraits. J'ai considéré qu'en le mettant en lien, les gens ne souhaitant pas voir de tels propos n'y seraient pas "forcés". Le nom de fichier est explicite, on ne peut pas s'y tromper. Et de toutes façons, le fichier sera supprimé dans quelques jours, quand l'affaire sera terminée.
Notez qu'après sondage dans mon entourage, pas moins de 16 personnes l'ont reçu. Et pas dans mon entourage lié à mon engagement syndical, politique ou associatif : mais principalement dans mon entourage lié à l'informatique. 16 personnes sur la trentaine que j'ai eu le temps de sonder entre hier soir et maintenant, ça me semble assez considérable. D'autant plus que les informaticiens ne connaissent pas forcément le MRAP et ne font pas forcément gaffe, les extraits ci-dessus le montrent.
Tout à fait exact. GNU Mach plante dès qu'il n'y a plus de mémoire. Il est donc agréable de mettre pas mal de swap. Bien entendu, il ne serait pas si difficile d'implémenter une des stratégies que j'évoquais plus haut - mais ça ne serait pas vraiment utile sachant qu'on ne gardera pas GNU Mach, et que le bug est uniquement de tester pour l'instant.
Non. C'est valide pour n'importe quel système de fichier dont les méta-données ne sont pas centralisées, c'est à dire tous les systèmes de fichiers modernes (j'exclue FAT*). Et je ne vois pas ce que ext2 a d'archaïque. Qu'aujourd'hui l'utilisateur de base préfère un système de fichiers journalisé, soit. Mais je ne vois pas en quoi ça rend ext2 archaïque, d'autant plus qu'un système de fichiers comme ext3 ne fait jamais que reprendre 95% de la conception d'ext2 en y ajoutant un journal (et modifiant quelques choses au passage, sans quoi ça ne peut pas bien marcher). Je te rappelle que Linux n'a pas supporté les systèmes de fichiers journalisés avant Linux 2.4, et les expériences avec ReiserFS avant 2.4.16 n'ont pas été concluantes (et ext3 n'a été inclu que dans Linux 2.4.15, et il était cassé). Ça ne fait pas si longtemps que ça.
Et je ne vois pas en quoi le fait que le Hurd ne dispose pour le moment que d'une implémentation d'ext2 (aboutie, s'entend) se retournerait contre mon propos. ext2 est un système de fichiers moderne, ce qui montre que le Hurd supporte très bien de tels systèmes de fichiers. Et je ne crois pas qu'il soit essentiel d'avoir une panoplie de systèmes de fichiers hype (JFS, XFS, ReiserFS, que sais-je ;-) dans un système qui n'est de façon évidente pas destinée à la production ou à une quelconque utilisation réclamant des performances particulières actuellement. Vu la lenteur de la couche IDE, et le peu d'intelligence des accès disques (qui subbisent de nombreuses copies en route), c'est loin d'être une priorité, à mon goût.
En revanche, les 2Go ne sont valables que pour l'architecture archaïque qu'est x86 (IA-64 tout pareil) : mais là, c'est pas exactement de notre ressort. ;-P
Je n'affirme pas que le Hurd apportera plus de performances que ne pourrait l'apporter Unix, ou Linux. D'abord parce que ça dépend de comment le Hurd avancera, et surtout de comment Linux évoluera avec les années. Mais reprenons en deux points, pourquoi je pense que les pertes de performances inhérents au système multi-serveurs à micro-noyau peuvent devenir négligeables, et ouvrir sur quelques optimisations non négligeables que le Hurd peut permettre.
Les problèmes de performances des systèmes multi-serveurs à micro-noyau (c'est à dire, implémentés avec un petit noyau et un grand nombre d'applications par dessus implémentant ce qu'habituellement le noyau implémente) sont liés à la nécessité qu'ont les serveurs de communiquer entre eux. Ces communications entraînent un surcoût, lié principalement à deux choses : elles s'accompagnent souvent de copies de données d'une part, et elles nécessitent des appels systèmes et context switches d'autre part :
1) Imaginons le cas où une tâche A, mettons le driver IDE, récupère des données d'un backing store quelconque (en l'occurrence probablement un disque dur). Elle doit les communiquer à une tâche B (le système de fichiers par exemple). Elle envoie donc un message avec ces données à B. Mais B est en train de faire autre chose : il est certes multithreadé, mais il peut pas aller plus vite que le scheduler ne lui permet. Le driver IDE, lui, a envoyé son message, et continue son boulot. Il récupère d'autres données, pour quelqu'un d'autre. Comme il va pas s'amuser à garder les anciennes en mémoire éternellement, il va réécrire celles d'avant. Et là, pouf : le noyau, qui pour l'instant n'avait rien copié, va être obligé de copier dans sa propre mémoire les premières données pour pouvoir les restituer juste ensuite à B. Copies bien inutiles, liées au caractère asynchrone des messages. Avec L4, l'ensemble des messages sont synchrones. De telles copies sont totalement évitées. Le COW (Copy on Write, cette technique qui permet de ne répliquer les données que quand elles sont modifiées, et de les faire apparaître virtuellement aux deux endroits tant que c'est en lecture seule) est bien plus efficace, l'objectif « zero copy » bien plus facile à réaliser.
2) Le sur-coût lié aux changements de tâches fréquents (tâche A -> noyau -> tâche B, et ce très rapidement et très souvent du fait des très nombreuses communications) est lié à ce qu'on appelle les "context switch". En effet, lorsqu'une tâche est en cours d'exécution, un certain nombre d'informations la concernant (son "contexte") sont chargés dans des registres. Si ce n'est que ça, à la vitesse où vont nos processeurs, aucun soucis, on peut assez rapidement charger/décharger sans voir grand chose. Mais à chaque changement de contexte, on effectue généralement ce qu'on appelle un "TLB flush", qui consiste à vider le Translation Look-Aside Buffer (TLB). Ce TLB est un cache qui garde en mémoire les correspondances "adresse virtuelle" <-> "adresse physique". Et cette étape de conversion "adresse virtuelle" -> "adresse physique" (ce qui arrive quand on a un "TLB miss") est lourde, très lourde. Or, à chaque changement de contexte, on perd tout ce qu'on avait déjà "traduit". Si on multiplie par 10 les changements de contexte, imaginez le temps perdu ! Le TLB deviendrait presque inutile.
Pour éviter cela, certaines architectures disposent d'un TLB taggé, c'est à dire qu'ils associent à chaque paire un identifiant représentant l'espace d'adressage auquel la traduction correspond. Ainsi, le TLB est partagé à beaucoup, mais au moins on ne perd pas son contenu. C'est notamment le cas de certains MIPS (le R6000, crois-je me souvenir). L'idée des développeurs de L4 est d'arriver à faire la même chose sur l'ensemble des architectures. Et il s'avère que celà est faisable sur x86, PowerPC, Sparc, Alpha, au moins. Sur x86, plus de 80% des changements de contexte ne nécessitent plus de TLB flush. Les pertes liées aux changements de contexte sont donc minimes. Et a fortiori encore plus sur les autres, où on a du 100%.
J'évoquais dans un autre journal que les pertes liées à l'exécution de Linux sur L4 plutôt qu'en natif étaient d'environ 5 à 10%. C'est la traduction de la volonté de l'équipe de L4Ka (et de TU-Dresden) de mettre les performances comme une des priorités du développement de L4.
Le titre du cinquième lien de la dépêche contient un terme tout à fait intéressant : « self-paging tasks ». Le concept est assez simple : sous Unix, toutes les tâches se partagent la mémoire physique, chacune en réclamant de la mémoire (par mmap, malloc, ...) à chaque fois qu'elle pense en avoir besoin. Le noyau lui en donne systématiquement, sauf quand il n'en a plus (ENOMEM), ou quand ses quotas sont dépassés, etc. Quand il n'y a plus de mémoire principale (RAM) disponible, le système décide de swapper selon ses envies du moment. La VM étant centralisée dans le noyau, c'est lui qui décidera unilatéralement qui reste et qui s'en va, selon ses propres critères, parfois intelligents, souvent moins. Quand il n'y a plus de mémoire disponible du tout (RAM + swap épuisées), le système tue généralement les prochaines tâches qui essayent d'allouer de la mémoire (il est vraisemblable qu'elles soient responsables du problème, et de toutes façons elles ne marcheraient probablement plus si on leur disait ENOMEM), ou une tâche ciblée (principe de l'OOM Killer sous Linux), ou le système crash (principe du zalloc panic sous GNU Mach. ;-))
Pour le port du Hurd sur L4, l'idée est d'allouer à chaque tâche une portion de mémoire physique au démarrage. Elle gère ensuite cette mémoire comme bon lui semble : elle décide de passer des pages en swap quand elle pense que c'est nécessaire (soit parce qu'il n'y a plus d'espace disponible, soit parce qu'elle a de bonnes raisons classées secret défense), d'aller rechercher telle ou telle page elle-même, etc., etc. Évidemment, par défaut, chaque tâche dispose d'un gestionnaire de mémoire (libhurd-mm) qui lui est "greffé" au démarrage. Mais chaque application peut avoir son propre gestionnaire de mémoires, plus intelligent, plus adapté à son cas. Et Dieu sait que dans le cas du multimédia, c'est quelque chose de fondamental, et un problème récurrent qui explique que beaucoup de matériel spécialisé utilise des systèmes d'exploitations particuliers (par exemple, http://www.cl.cam.ac.uk/Research/SRG/netos/old-projects/nemesis(...) : Nemesis).
La chose devient encore plus intéressante quand on observe le cas où une tâche estime avoir besoin de plus de mémoire physique qu'elle n'en a déjà, ou quand le système se retrouve en danger de manque de mémoire physique. L'idée là est qu'une opération de re-négociation est lancée. Cette négociation implique un gestionnaire de QoS (l'intendant du système) et la tâche elle-même (son thread gestionnaire de mémoire, bien entendu). Les deux se lancent dans une opération de négociation régie par les règles décidées par le système (qui n'ont pas été fixées). Un modèle simple et efficace est le modèle du marché : chaque tâche dispose d'une certaine somme au démarrage (somme calculée en fonction de la priorité (nice), des quotas, de ce que l'administrateur a décidé, et -surtout- de la mémoire déjà allouée et de l'utilisation CPU déjà faite). Pour cette somme, elle reçoit tant de temps CPU, et tant de mémoire physique. Selon la rareté des ressources (l'offre) et les demandes des tâches, les prix varient. Ainsi, une tâche qui sait n'avoir besoin que très peu de mémoire pendant quelques minutes peut décider au début de l'opération de vendre une partie de sa mémoire, et avec l'argent reçu, de racheter du temps CPU supplémentaire. Un tel modèle économique a déjà été implémenté : il a apporté plus de 40% de performances dans certains cas, pour des bases de données particulièrement (qui ont une utilisation très spécifique de la mémoire et du temps CPU - un SGDB, c'est un peu un cache géant qui s'emballe de temps en temps ;-)).
[NB: les économistes, en herbe ou non, remarqueront que si le marché marche aussi bien dans ce cas, c'est parce que tout passe par le commissaire-QoS manager. Le Hurd, dernier hériter du GOSPLAN ? ;-)]
Toutes ces choses, une gestion des ressources totalement centralisée (scheduler et VM uniques dans le noyau) ne le permet en aucun cas. Au mieux, elle permet de lui spécifier des "conseils" (hints) d'allocation mémoire, comme celà a existé sous Solaris ou VMS. Et je pense que c'est qu'un exemple de ce que le Hurd permet, et qu'avec les années et le développement, on se rendra compte plus clairement de la magie de la chose.
Ça fait un petit bout de temps que j'ai pas eu assez de temps pour y contribuer de façon sensible, pour des raisons personnelles (...). Mais j'y contribue, oui. Et maintenant que j'ai plus de temps, je suis sur quelques projets qui font partie intégrante du développement du Hurd. Accessoirement, je suis président d'HurdFR, que je vous invite à découvrir, que vous soyez curieux ou supra-motivés pour venir développer ;-)
Enfin, tout ça n'a peu d'intérêt dans une news DLFP ;-)
Je ne vais pas m'étaler tant que possible. On trouve, dans les commentaires passés des uns et des autres, dans le matos disponibles sur tous les sites qui ont été évoqués dans les dits commentaires, nombre d'exemples des spécificités du Hurd et de ce qu'il permet que ne permet pas déjà Unix.
Je ne crois pas que le Hurd tout seul puisse apporter beaucoup à l'utilisateur. Le Hurd se veut le coeur du projet GNU. Pas plus que dans Unix l'utilisateur n'est confronté au coeur du système. Il est confronté aux applications finales. J'évoquais sur http://linuxfr.org/comments/517501.html#517501(...) pas mal des possibilités qu'offre le Hurd à tous les niveaux.
Bien entendu, l'utilisateur de base se fiche des translators, des jetons, ou de tout le reste. Mais des droits bien utilisés lui serviront à lui apporter plus de sécurité. Je suis sûr qu'il serait tout à fait envisageable d'utiliser au mieux les jetons pour les utilisateurs, moyennant quelques réflexions sur l'interface. Ce dont je suis sûr également, c'est que les translators bien utilisés lui apporteront plus de stabilité, moins de limitations étranges ("MAIS! Pourquoi je peux accéder à mon répertoire en WebDAV dans Gedit et pas dans Rox ?" "Mais euh... Pourquoi c'est si compliqué pour avoir mon CD en utilisateur ?" "gnu... pourquoi je peux pas accéder à mon .zip comme sous Windows sous XY ?"), et probablement de nouvelles fonctionnalités que les programmeurs auront pu implémenter grâce aux translators. Mais globalement, le coeur de système d'exploitation n'offre pas de changement visible : il permet de nouvelles fonctionnalités, plus de sécurité, plus de fiabilité, plus de stabilité, et plus de performances. Je pense que le Hurd peut fournir tout ça.
(Le concept de translators est plus vaste que les systèmes de fichiers virtuels que tu envisages : en fait, sous GNU/Hurd, à chaque fichier est attaché un programme. Quand tu accèdes à ce fichier (le lit avec cat, y écrit avec sed), c'est le programme attaché qui reçoit les requêtes et y répond. Ce programme est un programme tout ce qu'il y a de plus classique, lancé quasiment normalement, avec les droits de l'utilisateur qui l'a lancé, toussa. On appelle translator tout programme qui est attaché à au moins un fichier. Que ce soit ftpfs, ou ext2fs.)
Quelques précisions au passage... Merci à Frédéric de répondre.
Mon système de rêve ? Ce serait bien sûr une Gentoo/Hurd. Il y a déjà un tel projet (http://hurd.rustedhalo.net(...(...))) mais il ne peut pas avancer plus vite que le Hurd lui même. Autant dire qu'il va falloir attendre un peu.
Il faut comprendre que le projet Hurd est de facto très lié à Debian GNU/Hurd. Si Debian GNU/Hurd n'est pas la distribution oficielle, ni quoi que ce soit, le développement du Hurd a repris avec la création de Debian GNU/Hurd par Marcus Brinkmann en 1998, et la plupart des développeurs actuels sont passés par le développement de la distribution. Aussi, Gentoo/Hurd aura probablement du mal à exister pour le moment. Je ne suis pas bien sûr d'ailleurs qu'on ait besoin de plusieurs distributions pour le moment : le boulot principal est de porter les applications, qui ont souvent de légères incompatibilités POSIX qui nécessitent quelques patchs. C'est un boulot très indépendant de la distribution, donc, et je pense que concentrer les efforts (et les sources de patchs, en plus) à ce moment du développement est la meilleure solution. Mais libre à chacun de faire sa distribution ;-)
Pour la swap, le comportement par défaut est historique, parce que pendant un temps, swapon(8) ne reconnaissait simplement pas les signatures de swap Linux. Il en est maintenant capable, et le patch pour faire qu'il ne swappe pas sur n'importe quelle partition non-signée par défaut devrait être bientôt intégré, probablement dans le prochain paquet 'hurd'.
Pour l'installation, si tu utilises Gentoo, tu utiliseras vraisemblablement les CDs. L'installation à proprement parler est très simple. C'est un installeur Debian de base. Le plus complexe est de ne pas oublier d'installer et de configurer correctement son Grub. Ensuite, la phase de post-installation est un peu fastidieuse... rien d'insurmontable ceci dit. Toute l'installation est décrit sur http://hurdfr.org/pages/doc/GuideInstall.pdf(...) ; il manque juste un apt-get install console-driver-xkb entre le configuration d'apt et le lancement de la console.
Pour l'AMD64, ne fournit-il pas une émulation IA-32 classique ? Alors, il ne devrait y avoir aucun problème... Il n'y a pas grand intérêt à exploiter le 64 bit dans la version actuelle du Hurd, qui utilise GNU Mach. C'est juste pour test et découverte que tu l'installeras.
- Puisque l'on parle de support, le Hurd pourra t-il faire tourner directement les binaires Linux (un peu comme FreeBSD, sauf erreur), ou est-ce une utopie ?
C'est théoriquement faisable. Ça n'est pas fait : il manque encore un petit nombre de choses à notre branche de la Glibc, un certain nombre de choses au Hurd pour que ce soit envisageable. Mais est-ce souhaitable ? C'est assez lourd à maintenir, ça nous contraint à supporter des spécificités sans que ce soit -réellement- nécessaire. Il suffit de recompiler l'ensemble des logiciels, chose que l'on fait déjà. Et ça se passe très bien. Effectivement, les BSD (Free et Net du moins) ont ce support. Qui ne sert que pour les logiciels propriétaires. Je ne crois pas que l'un de nous ait envie de passer son temps à ça. Vous êtes libres de faire ce que vous voulez ;-)
- La doc...Elle a fait des progrès, d'accord, mais il y encore du boulot... Les experts y trouvent sans aucun doute leur bonheur, mais c'est un peu dur de s'intéresser à ce système si on ne comprend pas vraiment comment l'utiliser.
HurdFR.org doit encore être réorganisé, c'est vrai. Mais un documentation comme le guide d'installation, assez souvent maintenu à jour devrait grandement aider. Avec l'arrivée du Wiki, nous espérons pouvoir maintenir pas mal d'informations à jour facilement accessible. En attendant, le Wiki du projet Hurd (http://hurd.gnufans.org(...) - il n'a rien d'officiel) contient pas mal d'infos.
Qu'on sursaute au premier abord en lisant 2Go, je veux bien. Qu'ensuite on se permette des commentaires, comme le tien d'ailleurs, sans s'être une seconde renseigné sur les tenants et les aboutissants de la chose, ainsi que sur le projet de façon plus générale, je trouve ça, pour le moins, extrêmement dommage.
On ne peut pas comparer l'avancée de deux projets en voyant "celui-là a supporté ça en X mois, celui-là en X années". Pas sur des projets dont la conception et les fondements sont totalement différents. Dans Unix, les systèmes de fichiers sont implémentés comme des objets à part, ayant juste à répondre à quelques appels définis par un VFS. Il est bien évident que dans ce contexte, il n'y a aucun problème pour supporter les systèmes de fichiers de plus de 2Go. Le Hurd fait le choix d'implémenter les systèmes de fichiers en tant que pagers associés à un "backing store" spécial (le système de fichiers sur disque). C'est une conception qui simplifie beaucoup de choses et permet une très grande flexibilité, à mon avis. Mais au moment de l'écriture concrète d'ext2fs, les auteurs font le choix d'avoir quelque chose qu'on sait limité, mais simple et stable : mapper tout le système de fichier en mémoire. Or sur IA-32, les espaces d'adressage font 4Go. On enlève la place réservée au noyau (comme sur tous les autres systèmes d'exploitation), on est autour de 2Go. La supprimer signifie reconcevoir un système permettant de mapper en mémoire juste ce qu'il faut, quand il le faut. C'est loin d'être trivial, et changer ext2fs c'est pendant un temps rendre extrêmement instable le système - et donc, ralentir le développement de toutes les autres parties.
Tout ça pour dire que ça n'est pas une "limitation à la con", parce qu'ext2fs serait une implémentation simplissime, le genre de trucs qu'on écrit à la va vite au début. Et en aucun cas ça ne permet de juger de l'avancée du projet. Au moment où ext2fs avait déjà cette limitation, le Hurd supportait déjà les sous-Hurd, c'est à dire l'exécution de plusieurs systèmes presque totalement indépendants, en parallèle, depuis plusieurs années. Chose que ni Linux avec chroot, ni FreeBSD avec jail, ni aucun autre système libre ne supporte. Le Hurd supporte effectivement le système de "jetons" dont j'ai maintes fois parlé. Je peux d'ores et déjà avoir un FTPd qui tourne sans -aucun- droit et qui les gagne en cours d'exécution, sans bidouille, sans problème. Je peux d'ores et déjà avoir mon ext2fs en utilisateur. Je peux d'ores et déjà lancer sans crainte mon ftpfs. Des choses que Linux n'est pas capable de faire, après quatorze ans de développement. Les projets n'évoluent pas forcément pareil, il faut s'y faire. Et les réactions ricanantes de certains me font désespérément penser à l'européano-centrisme d'autres face aux sociétés dites "primitives". Aussi inutile et biaisé.
On précisera par ailleurs que le patch pour ext2fs existe depuis plusieurs années. S'il n'a pas été intégré plus tôt, c'est par manque de testeurs. Il a été annoncé, y compris sur des sites francophones. C'est très vite de juger que de mettre en cause les développeurs du projet pour un tel "retard".
Effectivement, on peut penser faire tourner le Hurd en parallèle avec Linux sur L4, dans le cadre de L4Linux, comme TU-Dresden le fait avec DROPS. Maintenant, c'est loin d'être trivial, tout de même. Les projets qui l'utilisent actuellement font tourner des choses relativement haut niveau, et pas vraiment deux systèmes totalement en parallèle. Pour faire tourner les deux personnalités totalement différentes en parallèle, il faut que les serveurs de base puissent être communs, et sachent s'en sortir avec des contraintes très, très différentes (tâches auto-paginées d'un côté, mémoire bloquée de partout de l'autre, ...). Je crois qu'il est plus sain de vouloir d'un GNU/Hurd totalement autonome dans un premier temps, d'autant plus que dans l'état actuel des choses c'est loin d'être inenvisageable. La possibilité de faire tourner en parallèle plusieurs personnalités si différentes est à garder en tête, sans plus : la possibilité des co-Hurd et des sous-Hurd me semble bien plus importante au début.
Non, ça n'existe pas. Des gens s'y sont déjà consacrés, et des patchs ont été produits, sans pour autant qu'on en soit arrivé à la naissaance du dit Live CD : cependant, http://hurd.gnufans.org/bin/view/Hurd/LiveCD(...) récapitule brièvement ce qui a été fait et ce qui manque.
Euh, autant je suis d'accord sur la quantité de code à auditer, autant je ne le suis absolument pas sur la seconde phrase. Le risque d'une faille dans le noyau se situe à deux niveaux : d'une, sous Unix, ce qui est dans le noyau est tout ce qui est "commun à toutes les applications", et donc ce qui est globalement vital au système ; de deux, tout ce qui est dans le noyau tourne avec les privilèges spéciaux sur le matériel. Pour le premier, on est d'accord, ça ne change rien. Si il y a un DoS potentiel sur, disons, la couche de gestion de la mémoire physique, on entraîne tout le système. Pour le second, en revanche, ça change tout. Je peux certes entraîner le système, éventuellement gagner des droits root, mais je ne peux pas me hisser dans le kernel space comme ça se voit assez régulièrement.
De façon plus générale : en séparant les parties qui peuvent l'être, en définissant clairement quelles sont leurs relations et séparations, on permet plusieurs choses :
Tout ce qui n'est pas purement vital au système, s'il se retrouve attaqué, n'entraîne que lui. La pile TCP/IP n'est pas vitale au système. Le driver son l'est encore moins. Chacun étant des applications tournant dans leur propre espace d'adressage, utilisant leur propre mémoire, elles n'entraîneront qu'elles-mêmes dans leur chute. On l'a vu, d'ores et déjà, il y a quelques années, quand un serveur Web sous GNU/Hurd avait subi un /.age en règle : la pile TCP/IP s'était vautrée un nombre incalculable de fois, la machine pas.
On peut réellement réfléchir aux permissions nécessaires à telle ou telle application. Sous Unix, la tradition veut que la plupart des parties considérées comme "centrales" se retrouvent intégrées dans le noyau. Souvent par besoin, du fait de sa conception. Parfois par commodité. Certaines parties se trouvent avoir besoin de permissions spéciales, et en effet certains serveurs sont très privilégiés sous GNU/Hurd (ils tournent en root, et L4 ne leur restreint aucun appel système). Ces serveurs sont sensibles, et facilement identifiables comme tels. Mais un grand nombre d'autres (et je pense aux pilotes de périphérique, par exemple) ne nécessitent "que" de tourner en root (et encore, pas tous !). Ces parties deviennent de suite moins critiques. Il y a donc un double gain : un gain de clarté pour l'identification des parties centrales, sensibles ; un gain de sécurité lié aux privilèges donnés concrètement aux applications.
C'est une évidence, mais il est bien plus facile d'auditer un code entièrement organisé en composants indépendants qu'un code "monolithique". Les effets de bord sont bien moins complexes, d'une part. On a souvent vu des horreurs comme des off by one dans un bout de code aboutir à une erreur de calcul assez embêtante de la taille d'un tableau, qui avec l'arrondi nécessaire se retrouvait assez pour être exploitable, ou potentiellement exploitable. Inutile de dire qu'une telle erreur est quasiment indétectable, et qu'un audit qui irait jusqu'à les rechercher prendrait des années. D'autre part, la séparation claire et revendiquée amène à faire quelque chose que Linus Torvalds s'est toujours refusé à faire pour Linux : concevoir des interfaces, stables tant que possible. La série de failles locales récentes découvertes dans Linux étaient liées à des comportements erratiques lorsque telle option était à telle valeur, tel pointeur à telle autre, etc., etc. Avoir des interfaces en mouvement constant, tandis que le code les utilisant l'est pas forcément du tout, n'aide pas à prévenir ce genre de problèmes. Je sais d'expérience que je me rends compte du comportement lors des cas limites principalement lorsque je documente mes fonctions/interfaces attentivement. Chose qu'évidemment, je ne ferai pas si elles sont destinées à être modifiées dans deux mois. Et chose qui n'est pas faite avec Linux. Les interfaces du Hurd, elles, sont stables. Il n'y a eu globalement qu'un changement qui a tout cassé (cassé l'ABI) depuis la première stabilisation. Bien entendu, on ne peut pas exclure qu'il y en ait d'autres, mais elles seront très, très limitées. Plus de clarté, à mon sens, c'est plus de sécurité, et c'est aussi une meilleure utilisation de ces interfaces, donc moins prône aux erreurs.
Pour exemple, le coeur du système d'authentification du Hurd, représente 358 lignes de code (comptées par sloccount ;-). C'est LA partie du système qui nécessite de tourner en root, et qui nécessite d'être complètement et entièrement de confiance. 358 lignes, je pense que c'est faisable de l'auditer. Bon courage pour faire la même chose sur un Unix ;-)
En fait, le lien pointe ni vers la version française, ni la version anglaise. Selon la langue configurée dans votre navigateur, le site vous redirigera sur la version française ou anglaise. Le lien que tu as donné est le bon pour lier explicitement la version française.
En dehors des configs exotiques, cette variable d'environnement a le bon goût d'être nécessaire sous GNU/Hurd pour récupérer les sources du module 'hurd-l4' ;-) Donc, OUI, il faut la rajouter ! :-)
Je réponds au commentaire deux niveaux au dessus en reprenant celui-là. Désolé pour la confusion que cela entraîne ;-)
Concernant la place, à peu près équivalente à une Debian GNU/Linux. Le système de base tient sur 31Mo compressé (le mini-CD de K8 fait 33Mo). Évidemment, en général, quand on utilise GNU/Hurd c'est pour tester, et que ce soit pour du packaging ou du développement à tous niveaux, il faut compter de la place pour /src. ;-)
Comme je le disais, 71% de l'archive Debian fonctionne. Le reste nécessite généralement des patchs assez simples liés à des problèmes connus (MAXPATHLEN/PATH_MAX, MAXHOSTNAMELEN, NCARGS). En revanche, les gros morceaux que sont Gnome, KDE ou OpenOffice.Org ne fonctionnent pas, pour des raisons diverses : certaines parties dépendent inconditionnellement de la mémoire partagée SysV (shmget(2), mais c'est rare), certaines ont besoin des file locks (flockfile(3), c'est le cas notamment de GConf), etc. Bref, tout un tas de petits trucs qui manquent et qui empêchent le port de "grosses" applications où la probabilité qu'elles soient utilisées augmente. Il n'y a plus aucun problème avec les threads depuis que les pthreads sont parfaitement supportés, grâce à Neal H. Walfield. (enfin, parfois il y a une différence d'interprétation de POSIX entre NPTL/LinuxThreads et la libpthread du Hurd, mais c'est rare)
Lors de nos démonstrations, on utilise généralement WindowMaker, rxvt, gqview, mplayer en aalib. Ce genre de choses ne nous crée que rarement des surprises. Mais il ne faut pas rêver, d'abord c'est assez lent, et ça ne marche pas toujours. M'enfin, les visiteurs de Solutions Linux ont pu le voir marcher assez bien en général. ;-)
Concernant la portabilité, seul IA-32 est supporté pour GNU/Hurd sur Mach. Il faut bien comprendre que le but de cette branche actuellement est de faire qu'un max de gens testent et portent les paquets, etc., etc. IA-32 étant utilisé par le plus de gens, il est logique de la supporter en priorité - et nous n'avons pas les moyens de supporter hurd-ppc, hurd-ia64 ou que sais-je. Pour les courageux - voire téméraires -, le Hurd devrait tourner sur toutes les machines supportées par une implémentation de Mach respectant les interfaces de CMU Mach 3.0 (donc, compatible GNU Mach). Des implémentations existent sur Alpha, Sparc, Sparc64, PowerPC (oldworld seulement). Bon courage ;-)
Le Hurd sur L4 en revanche est développé avec la portabilité en tête, principalement sur PowerPC. L4Ka::Pistachio (l'implémentation de L4 qu'on utilise) lui-même tourne sur un grand nombre d'architectures (Alpha, AMD64, ARM, IA32, IA64, MIPS, PPC32, PPC64, cf. http://www.l4ka.org/projects/pistachio/(...) pour plus d'informations). Il est bien évident que GNU/Hurd a pour ambition d'être un système versatile, flexible, pouvant s'adapter du système "embarqué" relativement évolué (avec MMU, sans quoi ça n'a plus grand sens, donc on est sur de l'embarqué style ordinateur de bord, frigos ;-) aux grosses machines ayant besoin de virtualisation, de domaines, toussa. Et puis, la portabilité était un argument de vente majeur des micro-noyaux, montrons que tout n'était pas faux ;-)
... et on n'oubliera pas de préciser que la plupart des développeurs du Hurd seront présents au FOSDEM. S'il n'y aura pas de conférence officielle sur le Hurd, les plus motivés pourront se rendre au "symposium", où 7 conférences assez techniques se dérouleront.
Par ailleurs, et j'aurais aimé l'intégrer dans la news. HurdFR, suite à sa dernière assemblée générale, s'est dotée de pas mal de nouveaux outils : un Wiki en construction (http://wiki.hurdfr.org(...) pour l'instant en lecture seule - envoyez un mail à wiki at hurdfr dot org pour obtenir un compte), 4-5 machines disponibles aux membres (et quelques curieux) pour tests, un autobuilder pour Debian GNU/Hurd, et tout plein de nouveaux projets (qui se trouveront très bientôt sur le Wiki). N'hésitez pas à vous inscrire à la liste (https://lists.hurdfr.org(...) en donne une ... liste), à passer sur notre canal IRC (#hurdfr sur irc.freenode.net), et à vous inscrire sur http://hurdfr.org/index.php?page=pages/hurdfr.php(...) !
Bon, je fais quelques petits rajouts histoire de continuer à faire des points réguliers sur l'avancée du projet. Sur L4, tout est dit. banner(1) est un programme important parce que cela signifie qu'il y a désormait une entrée et une sortie standard, que le serveur qui constitue la base de tout le système des pilotes de périphériques (deva) est fonctionnel, et, évidemment, qu'on peut lancer un programme, de façon générale. Le port sur L4 attire de plus en plus de nouveaux développeurs, et de plus en plus de développeurs ont de nouveau le temps de retravailler dessus, le projet avance donc de plus en plus vite, même si les effectifs restent considérablement réduits. Pour rappel, Neal H. Walfield, celui qui avait entamé le port du Hurd sur L4 avait promis un shell (guère plus ;-) pour le 31 décembre 2004. On peut espérer que ça arrive pour, disons, mars. Je ne crois pas que ce soit un délai indigne en informatique ;-) (NB: Il serait très encourageant, par ailleurs, qu'un tel évènement arrive de façon assez rapprochée sur IA-32 et sur PowerPC. C'est bien sûr très lié à l'état d'avancement de Grub2 sur PowerPC, auquel il manque encore des éléments de base pour bien marcher. Mais le code spécifique à IA-32 a normalement été séparé du reste, il serait donc bien qu'il y ait des motivés pour s'en charger ;-)
Mais aussi excitant que soit le port sur L4, GNU/Hurd continue à exister sur GNU Mach, et comme le rappelle la news, cette partie aussi continue à subir de nombreux changements. Le support des partitions de 2Go intégré (le patch existe depuis longtemps, mais nécessitait des tests qui n'ont pas toujours été faciles à trouver), le support XKB de la nouvelle console definitivement stable (et facile a installer) sont des progres importants pour l'utilisabilite de tous les jours. On peut desormais avoir, en standard, une vraie console, avec support des terminaux virtuels, de differents encodings (jusqu'à UTF-32, testé et approuvé), de différents "maps" de clavier, et XFree86, l'utilisant, s'en trouve grandement amélioré (finis les problèmes récurrents avec les souris série, ou le XKB qui ne marche pas en utilisateur). Dans les nouveautés à venir : GNU Mach supporte dorénavant la plupart des cartes réseaux que vous possédez grâce au gnumach-nic-update dispo sur http://www.update.uu.se/~ams/patches/ (en fait, toutes celles supportées par les drivers de Donald Becker) ; après PPP, le support DHCP fonctionnel ; après ext2fs sans limites, une nouvelle version d'ext3fs ; et qui sait, PPPoE pourrait voir le jour, mmh. ;-)
Par ailleurs, le développement de Debian GNU/Hurd continue de plus belle. 71% de l'archive Debian est disponible. Des dépendances importantes, qui empêchent beaucoup de paquets de compiler, comme krb4, krb5 ou d'autres sont compilables. Mozilla a été compilé, même s'il ne fonctionne pas encore.
Qu'il y ait des développements dans les deux branches ne doit pas surprendre ou inquiéter. Tous les développements qui ont lieu sur la console, sur le support DHCP, sur ext3fs, ou tout ce que j'ai mentionné est parfaitement transférable de la version du Hurd actuelle vers celle portée sur L4. Ainsi, chacun peut contribuer à son niveau, selon son temps disponibles et ses envies, et, si tout va bien, les deux branchent sauront fusionner.
Non. Il faut voir http://www.coaster-burn.org/(...) ; le développement a plutôt repris au dernier trimestre, il y a eu plusieurs meetings de développeurs, et quelques versions. C'est encore loin d'être stable et loin de susciter l'intérêt qu'il devrait, mais c'est aussi loin d'être mort. Et puis, un projet libre n'est jamais mort, il suffit que la personne qui le dise le reprenne pour qu'il ne le soit pas ! :-)
Ca fait partie des ajouts très récents. Et ça sera très bientôt intégré dans les sources du Hurd. D'ici le FOSDEM, on trouvera quelques unes de ces améliorations (xkb en standard pour la console, nouvelle console par défaut, nouveau ext2fs >2G définitivement intégré). Parmi les nouveautés à venir, ext3fs avec ACL, attributs étendus, etc. No limit ! ;-)
Je l'ai dit. Pour le "sucre syntaxique", parce qu'ils ont trouvé que c'était moins chiant de pouvoir déclarer quelques classes, faire un peu d'héritage basique, que de faire la même chose en C. On peut ne pas être d'accord sur le choix - j'aurais sans doute pas fait le même, mais ça ne prête pas pour ainsi dire à conséquence, ni en terme de performances au runtime (aucune des fonctionnalités "dynamiques" de C++ n'étant utilisée), ni en terme de place (L4Ka::Pistachio occupe environ 12K de mémoire une fois booté. Je pense que ça devrait pas être beaucoup trop ;-). Éventuellement, cela rallonge le temps de compilation... Vu comme il est bas, pas grand chose à faire. :-)
... lance la nouvelle console du Hurd (qui supporte différents encoding, le son, les couleurs, différents VTs, tout ça) avec un clavier en français. On crée les liens qui vont bien avec :
Et le tour est joué ! Une console en français qui marche parfaitement, et un XFree86 par dessus. Attention, XFree86 est assez lent, du fait du manque de mémoire partagée SysV (shmem). Mais c'est plus que vivable, en fait c'est tout à fait décent. Par contre, plus tu fais tourner de choses sur ton système, plus tu auras des chances de rencontrer un plantage ;-) Pour une utilisation normale sans XFree86, j'ai pu tourner plus d'un mois sans aucun problème, avec une utilisation très "banale" (ouaibe, IRC, ssh, emacs, gcc, tout ça...).
Comme d'hab', du Linus, à prendre avec autant de recul qu'on peut en avoir en regardant Lhassa depuis le sommet du K2.
Concernant L4Ka::Pistachio, s'il est écrit en C++, il évite tout ce qu'on critique généralement sur le C++ : il n'utilise pas d'exceptions, pas de méthodes virtuelles, extrêmement peu d'héritage (quelques classes génériques avec de l'héritage pour les implémentations spécifiques à l'architecture), évidemment pas la STL, pas de templates, ...
Bref, du C avec le sucre syntaxique. Au lieu de faire des struct avec des pointeurs de fonction, il y a quelques class par ci par là. Même moi, qui pourtant ne supporte définitivement pas le C++ (allergie suite à une intoxication, un peu comme les fruits de mer vous voyez ?), je supporte très bien le source de L4Ka::Pistachio. C'est dire ;-)
Je complète les éléments postés par Frédéric plus haut (c'est ça HurdFR, tous prêts à s'épauler ;-).
Ensuite je suis tombé sur L4[6], Pistachio[7], Fiasco[8] et L4Linux[9].
Et c'est là que j'ai décroché... Quelles sont les différences ? Leur performances ? Leur (possible) avenir ?
Frédéric a plus ou moins répondu à ça. L4 est une famille de micro-noyaux. À l'origine, c'était le nom d'un micro-noyau que le très regretté Jochen Liedtke a écrit en assembleur pour x86 vers 1995. Jochen a écrit de nombreux papiers à son sujet, et il a également écrit une spécification pour ce noyau. De telle sorte que plusieurs implémentations ont vu le jour dans plusieurs laboratoires d'informatique, principalement en Allemagne (Karlsruhe et le projet L4Ka, Dresden et le projet Fiasco/DROPS) mais également chez nos amis Grands Bretons (Université de York, avec le premier port PowerPC), et même chez les Aussies (University of New South Wales, qui fournit beaucoup de documentations et de cours, et L4/MIPS).
Les spécifications ont évidemment évolué depuis, pour donner les spécifications X.0, puis X.2. L4Ka::Pistachio est l'implémentation de L4 choisie par le Hurd. Elle implémente la spécification X.2, la plus récente. La version précédente était L4Ka::Hazelnut, qui implémentait la spécification X.0. La voie choisie par Fiasco et l'Université de Dresde est différente, puisqu'ils continuent d'utiliser la spécification V2 (avec une compatibilité X.0), et se concentrent plus sur le développement de l'aspect "temps réel" (hard) de L4, dans le cadre de leur projet DROPS[0].
Quant à L4Linux, tout a presque déjà été dit. C'est un projet mené aussi bien par L4Ka que par TU-Dresden, qui vise à porter Linux sur L4. Les deux équipes ont des motivations similaires : pour TU-Dresden, c'est une partie importante de leur projet DROPS, parce que celà leur permet d'avoir la personnalité Linux classique, avec toutes les applications et fonctionnalités déjà existantes (prenez un binaire pour GNU/Linux, déposez le sur L4Linux, ça marche !) en parallèle avec leurs applications temps réel utilisant L4. C'est une façon assez simple de tester leur Fiasco, et surtout de fournir un environnement de développement efficace. Pour L4Ka, l'intérêt est d'avoir un environnement stable et complet pour que les développeurs puissent tester leurs applications pour L4, ou leurs changements dans L4, tout en disposant des fonctionnalités de Linux.
Qui plus est, L4Linux a servi de base aux tests[1] menés par L4Ka. Il est effectivement très intéressant de disposer d'une implémentation de Linux native pour x86 et de la même version, portée sur L4, pour mesurer l'overhead pur lié à l'utilisation d'un micro-noyau. Les tests ont donnés L4Linux 6 à 8% moins performant qu'un Linux natif. C'est extrêmement peu, considérant que Linux n'a jamais été conçu pour un tel usage, et donc pour tirer parti des avantages de L4 et des optimisations possibles. Considérez aussi que ces tests datent de 1997, et que L4 a énormément évolué depuis. Voilà qui ne laisse présager que du bon.
Pour l'auteur du journal, et pour les autres aussi. Cela fera bientôt l'objet d'une news DLFP, mais sachez que HurdFR existe bel et bien et est actif. N'hésitez pas à vous inscrire, posez vos questions, participer sur la liste d'HurdFR[2] (les archives ont été perdues récemment, ne cherchez pas... snif.), ou sur IRC[3]. N'hésitez pas non plus à adhérer ;-)
Je doute que l'interview d'un Linus ou d'un RMS soit la meilleure façon d'avoir un avis objectif, ou même seulement correct et précis sur le Hurd et son état actuel. Si RMS suit plus que Linus son développement, on ne peut pas dire que RMS soit impliqué ou comprenne vraiment ce qu'il s'y passe (et encore heureux). L'interview est ceci dit disponible sur http://kerneltrap.org/node/4484(...) ;
Concernant la prétendue "réécriture", c'est exactement le genre d'imprécisions qui arrivent quand on écoute l'un ou l'autre. C'est simplement faux. Les développeurs du Hurd ont décidé d'utiliser un autre micro-noyau (L4) que celui utilisé originellement (GNU Mach). Les raisons en sont multiples : d'abord, GNU Mach n'est plus maintenu depuis une dizaine d'années ou presque, et il contient un nombre de bugs impressionants qui ont été découvert avec le temps (le matériel et les besoins évoluant, un logiciel parfaitement stable en 1993 peut se retrouver inutilisable dix ans plus tard, on voit ce problème avec les jeux) ; ensuite, GNU Mach est dépassé techniquement, et il ne permet pas aux yeux des développeurs de créer un Hurd qui soit une alternative crédible aux autres systèmes, notamment pour des raisons de performance ; enfin, c'est un micro-noyau de première génération, très éloigné techniquement de ce qui se fait aujourd'hui dans ce domaine, et il serait insensé de sortir une version du Hurd ne tirant pas profit des micro-noyaux dits de "seconde génération" comme L4.
Les différences entre GNU Mach et L4 sont importantes : l'histoire de Mach remonte à 1975, et la version sur laquelle est basée GNU Mach remonte à 1989, et a évolué jusqu'en 1994 environ. Bien qu'il laisse à l'espace utilisateur un grand nombre de tâches (VFS et systèmes de fichiers, gestion des droits, des processus, une partie de la gestion de la mémoire virtuelle), il garde pas mal de tâches en son sein (la plus grosse partie de la VM, l'ordonnanceur, les pilotes de périphériques, il a un système évolué de communication entre les processus, intégrant des systèmes de sécurité, etc.). C'est ce qui en fait un micro-noyau de première génération.
L4, lui, voit les choses différemment (et il le peut car il hérite de quelques années de recherche de plus dans le domaine). Il n'implémente en son sein que des -mécanismes- de base qui nécessitent de toutes façons des droits privilégiés sur le matériel : mapper/démapper une page, changer le thread en cours d'exécution, envoyer un message d'un thread à un autre, accès basique au matériel, ce genre de choses. Ce ne sont plus des bouts entiers du système d'exploitation qui sont dans le micro-noyau, comme avec Mach, mais des outils. Tout ce qui définit la personnalité du système d'exploitation : gestion de la mémoire virtuelle, pilotes de périphérique, ordonnancement (L4 a un mini-ordonnanceur (RR à priorités strictes), mais la partie décisions d'ordonnancement se fait en espace utilisateur (détermination des priorités)), ou tout ce que vous pouvez voir dans un noyau actuel, se trouve en espace utilisateur.
C'est une différence fondamentale, effectivement. Mais ça ne veut certainement pas dire tout réécrire ! Imaginez le Hurd comme un ensemble de pièces de légo associées les une aux autres savamment, avec les parties "basses" elles-mêmes associées à une grosse pièce de légo, GNU Mach. On divise la hauteur de la pièce du bas par deux, et on enlève la partie supérieure. Il va vous falloir de fait recréer une partie supérieure différente, et qui fournisse tant que c'est possible les mêmes attaches avec les pièces situées plus haut. Évidemment, ça ne sera pas toujours possible et du coup, il faudra peut-être modifier quelques pièces basses de la partie supérieure (le Hurd), mais c'est mineur. Là, c'est exactement pareil. Tout ce qui était dans GNU Mach et qui n'est pas dans L4 doit être réécrit totalement différemment (en espace utilisateur, et c'est un avantage énorme). Mais le reste, ce qui existe déjà dans le Hurd, ne bouge pas ou peu.
[^] # Re: Encore un journal de merde en première page...
Posté par Manuel Menal . En réponse au journal Le MRAP victime d'une usurpation d'identité dans un spam. Évalué à 10.
Tout d'abord, je connais la distinction entre journaux publics et journaux privés, merci : je suis relecteur DLFP, et j'ai été modérateur depuis des années. Si j'ai choisi d'en faire un journal public, c'est volontairement. Est-ce que quelqu'un a vraiment lu le journal ? Vous vous rendez compte qu'il s'agit d'un démenti et d'un appel au calme afin que le MRAP puisse enfin répondre ? La nature même du journal en fait un journal public, puisqu'il veut toucher un maximum de gens.
Sur l'ampleur du phénomène : le responsable de la communication est totalement débordé depuis hier ; ils ont reçu une très grande quantité de mails. Je n'ai pas réagi immédiatement en recevant le spam - je suis proche du MRAP, et ce ne sera pas la première fois que je reçois des propos insultants sur le MRAP. J'ai réagi uniquement quand :
1) Pas moins de 8 personnes sur IRC ont réagi, en moins d'une heure. Extraits :
- "trop merci le spam du mrap qui te demande photocopie de la carte d'identité pour te désincrire"
- "put1 le spam que je viens de recevoir là, un mail du MRAP"
- "putain mais le MRAP qui spamme"
(...)
2) Une news a été proposée.
3) Le site a commencé à ne plus répondre.
Je pense que ça montre assez nettement que non, ça n'est pas franchement "trop gros". Je rappelle que les gens ne lisent généralement pas les spams qu'ils reçoivent attentivement, comme ceux qui ont lu le spam join l'ont forcément fait. En passant très rapidement dessus "ah, du spam" "ah, je m'en fous" "ah, c'est du MRAP" "ah, comment on se désinscrit" "arf mais carte d'identité", on ne réagit pas forcément. Qui plus est, je doute que seulement l'un d'entre vous aille vérifier sur hoaxbuster à chaque spam qu'il reçoit. Et tout le monde n'a pas cette culture, et ne connaît pas le MRAP : mais d'ores et déjà quand ils les verront, ils auront pour le moins un a priori négatif.
Je sais d'expérience que ce genre de choses plombe une association, déjà trop souvent controversée du fait de son fort engagement.
À propos de mettre le spam en lien : je ne crois pas qu'en taisant ce genre de propos, on les fasse reculer. J'ai hésité à fournir le lien ou à intégrer dans le journal, ou à n'en donner que des extraits. J'ai considéré qu'en le mettant en lien, les gens ne souhaitant pas voir de tels propos n'y seraient pas "forcés". Le nom de fichier est explicite, on ne peut pas s'y tromper. Et de toutes façons, le fichier sera supprimé dans quelques jours, quand l'affaire sera terminée.
Notez qu'après sondage dans mon entourage, pas moins de 16 personnes l'ont reçu. Et pas dans mon entourage lié à mon engagement syndical, politique ou associatif : mais principalement dans mon entourage lié à l'informatique. 16 personnes sur la trentaine que j'ai eu le temps de sonder entre hier soir et maintenant, ça me semble assez considérable. D'autant plus que les informaticiens ne connaissent pas forcément le MRAP et ne font pas forcément gaffe, les extraits ci-dessus le montrent.
[^] # Re: Que m'apporte le hurd ?
Posté par Manuel Menal . En réponse à la dépêche Hurd : nouvelle version de Debian GNU/Hurd et avancée du port sur L4. Évalué à 3.
[^] # Re: Question bete!
Posté par Manuel Menal . En réponse à la dépêche Hurd : nouvelle version de Debian GNU/Hurd et avancée du port sur L4. Évalué à 4.
[^] # Re: heeeuu
Posté par Manuel Menal . En réponse à la dépêche Hurd : nouvelle version de Debian GNU/Hurd et avancée du port sur L4. Évalué à 10.
Et je ne vois pas en quoi le fait que le Hurd ne dispose pour le moment que d'une implémentation d'ext2 (aboutie, s'entend) se retournerait contre mon propos. ext2 est un système de fichiers moderne, ce qui montre que le Hurd supporte très bien de tels systèmes de fichiers. Et je ne crois pas qu'il soit essentiel d'avoir une panoplie de systèmes de fichiers hype (JFS, XFS, ReiserFS, que sais-je ;-) dans un système qui n'est de façon évidente pas destinée à la production ou à une quelconque utilisation réclamant des performances particulières actuellement. Vu la lenteur de la couche IDE, et le peu d'intelligence des accès disques (qui subbisent de nombreuses copies en route), c'est loin d'être une priorité, à mon goût.
En revanche, les 2Go ne sont valables que pour l'architecture archaïque qu'est x86 (IA-64 tout pareil) : mais là, c'est pas exactement de notre ressort. ;-P
[^] # Re: Que m'apporte le hurd ?
Posté par Manuel Menal . En réponse à la dépêche Hurd : nouvelle version de Debian GNU/Hurd et avancée du port sur L4. Évalué à 10.
Les problèmes de performances des systèmes multi-serveurs à micro-noyau (c'est à dire, implémentés avec un petit noyau et un grand nombre d'applications par dessus implémentant ce qu'habituellement le noyau implémente) sont liés à la nécessité qu'ont les serveurs de communiquer entre eux. Ces communications entraînent un surcoût, lié principalement à deux choses : elles s'accompagnent souvent de copies de données d'une part, et elles nécessitent des appels systèmes et context switches d'autre part :
1) Imaginons le cas où une tâche A, mettons le driver IDE, récupère des données d'un backing store quelconque (en l'occurrence probablement un disque dur). Elle doit les communiquer à une tâche B (le système de fichiers par exemple). Elle envoie donc un message avec ces données à B. Mais B est en train de faire autre chose : il est certes multithreadé, mais il peut pas aller plus vite que le scheduler ne lui permet. Le driver IDE, lui, a envoyé son message, et continue son boulot. Il récupère d'autres données, pour quelqu'un d'autre. Comme il va pas s'amuser à garder les anciennes en mémoire éternellement, il va réécrire celles d'avant. Et là, pouf : le noyau, qui pour l'instant n'avait rien copié, va être obligé de copier dans sa propre mémoire les premières données pour pouvoir les restituer juste ensuite à B. Copies bien inutiles, liées au caractère asynchrone des messages. Avec L4, l'ensemble des messages sont synchrones. De telles copies sont totalement évitées. Le COW (Copy on Write, cette technique qui permet de ne répliquer les données que quand elles sont modifiées, et de les faire apparaître virtuellement aux deux endroits tant que c'est en lecture seule) est bien plus efficace, l'objectif « zero copy » bien plus facile à réaliser.
2) Le sur-coût lié aux changements de tâches fréquents (tâche A -> noyau -> tâche B, et ce très rapidement et très souvent du fait des très nombreuses communications) est lié à ce qu'on appelle les "context switch". En effet, lorsqu'une tâche est en cours d'exécution, un certain nombre d'informations la concernant (son "contexte") sont chargés dans des registres. Si ce n'est que ça, à la vitesse où vont nos processeurs, aucun soucis, on peut assez rapidement charger/décharger sans voir grand chose. Mais à chaque changement de contexte, on effectue généralement ce qu'on appelle un "TLB flush", qui consiste à vider le Translation Look-Aside Buffer (TLB). Ce TLB est un cache qui garde en mémoire les correspondances "adresse virtuelle" <-> "adresse physique". Et cette étape de conversion "adresse virtuelle" -> "adresse physique" (ce qui arrive quand on a un "TLB miss") est lourde, très lourde. Or, à chaque changement de contexte, on perd tout ce qu'on avait déjà "traduit". Si on multiplie par 10 les changements de contexte, imaginez le temps perdu ! Le TLB deviendrait presque inutile.
Pour éviter cela, certaines architectures disposent d'un TLB taggé, c'est à dire qu'ils associent à chaque paire un identifiant représentant l'espace d'adressage auquel la traduction correspond. Ainsi, le TLB est partagé à beaucoup, mais au moins on ne perd pas son contenu. C'est notamment le cas de certains MIPS (le R6000, crois-je me souvenir). L'idée des développeurs de L4 est d'arriver à faire la même chose sur l'ensemble des architectures. Et il s'avère que celà est faisable sur x86, PowerPC, Sparc, Alpha, au moins. Sur x86, plus de 80% des changements de contexte ne nécessitent plus de TLB flush. Les pertes liées aux changements de contexte sont donc minimes. Et a fortiori encore plus sur les autres, où on a du 100%.
J'évoquais dans un autre journal que les pertes liées à l'exécution de Linux sur L4 plutôt qu'en natif étaient d'environ 5 à 10%. C'est la traduction de la volonté de l'équipe de L4Ka (et de TU-Dresden) de mettre les performances comme une des priorités du développement de L4.
Le titre du cinquième lien de la dépêche contient un terme tout à fait intéressant : « self-paging tasks ». Le concept est assez simple : sous Unix, toutes les tâches se partagent la mémoire physique, chacune en réclamant de la mémoire (par mmap, malloc, ...) à chaque fois qu'elle pense en avoir besoin. Le noyau lui en donne systématiquement, sauf quand il n'en a plus (ENOMEM), ou quand ses quotas sont dépassés, etc. Quand il n'y a plus de mémoire principale (RAM) disponible, le système décide de swapper selon ses envies du moment. La VM étant centralisée dans le noyau, c'est lui qui décidera unilatéralement qui reste et qui s'en va, selon ses propres critères, parfois intelligents, souvent moins. Quand il n'y a plus de mémoire disponible du tout (RAM + swap épuisées), le système tue généralement les prochaines tâches qui essayent d'allouer de la mémoire (il est vraisemblable qu'elles soient responsables du problème, et de toutes façons elles ne marcheraient probablement plus si on leur disait ENOMEM), ou une tâche ciblée (principe de l'OOM Killer sous Linux), ou le système crash (principe du zalloc panic sous GNU Mach. ;-))
Pour le port du Hurd sur L4, l'idée est d'allouer à chaque tâche une portion de mémoire physique au démarrage. Elle gère ensuite cette mémoire comme bon lui semble : elle décide de passer des pages en swap quand elle pense que c'est nécessaire (soit parce qu'il n'y a plus d'espace disponible, soit parce qu'elle a de bonnes raisons classées secret défense), d'aller rechercher telle ou telle page elle-même, etc., etc. Évidemment, par défaut, chaque tâche dispose d'un gestionnaire de mémoire (libhurd-mm) qui lui est "greffé" au démarrage. Mais chaque application peut avoir son propre gestionnaire de mémoires, plus intelligent, plus adapté à son cas. Et Dieu sait que dans le cas du multimédia, c'est quelque chose de fondamental, et un problème récurrent qui explique que beaucoup de matériel spécialisé utilise des systèmes d'exploitations particuliers (par exemple, http://www.cl.cam.ac.uk/Research/SRG/netos/old-projects/nemesis(...) : Nemesis).
La chose devient encore plus intéressante quand on observe le cas où une tâche estime avoir besoin de plus de mémoire physique qu'elle n'en a déjà, ou quand le système se retrouve en danger de manque de mémoire physique. L'idée là est qu'une opération de re-négociation est lancée. Cette négociation implique un gestionnaire de QoS (l'intendant du système) et la tâche elle-même (son thread gestionnaire de mémoire, bien entendu). Les deux se lancent dans une opération de négociation régie par les règles décidées par le système (qui n'ont pas été fixées). Un modèle simple et efficace est le modèle du marché : chaque tâche dispose d'une certaine somme au démarrage (somme calculée en fonction de la priorité (nice), des quotas, de ce que l'administrateur a décidé, et -surtout- de la mémoire déjà allouée et de l'utilisation CPU déjà faite). Pour cette somme, elle reçoit tant de temps CPU, et tant de mémoire physique. Selon la rareté des ressources (l'offre) et les demandes des tâches, les prix varient. Ainsi, une tâche qui sait n'avoir besoin que très peu de mémoire pendant quelques minutes peut décider au début de l'opération de vendre une partie de sa mémoire, et avec l'argent reçu, de racheter du temps CPU supplémentaire. Un tel modèle économique a déjà été implémenté : il a apporté plus de 40% de performances dans certains cas, pour des bases de données particulièrement (qui ont une utilisation très spécifique de la mémoire et du temps CPU - un SGDB, c'est un peu un cache géant qui s'emballe de temps en temps ;-)).
[NB: les économistes, en herbe ou non, remarqueront que si le marché marche aussi bien dans ce cas, c'est parce que tout passe par le commissaire-QoS manager. Le Hurd, dernier hériter du GOSPLAN ? ;-)]
Toutes ces choses, une gestion des ressources totalement centralisée (scheduler et VM uniques dans le noyau) ne le permet en aucun cas. Au mieux, elle permet de lui spécifier des "conseils" (hints) d'allocation mémoire, comme celà a existé sous Solaris ou VMS. Et je pense que c'est qu'un exemple de ce que le Hurd permet, et qu'avec les années et le développement, on se rendra compte plus clairement de la magie de la chose.
[^] # Re: Que m'apporte le hurd ?
Posté par Manuel Menal . En réponse à la dépêche Hurd : nouvelle version de Debian GNU/Hurd et avancée du port sur L4. Évalué à 6.
Enfin, tout ça n'a peu d'intérêt dans une news DLFP ;-)
[^] # Re: Que m'apporte le hurd ?
Posté par Manuel Menal . En réponse à la dépêche Hurd : nouvelle version de Debian GNU/Hurd et avancée du port sur L4. Évalué à 6.
Je ne crois pas que le Hurd tout seul puisse apporter beaucoup à l'utilisateur. Le Hurd se veut le coeur du projet GNU. Pas plus que dans Unix l'utilisateur n'est confronté au coeur du système. Il est confronté aux applications finales. J'évoquais sur http://linuxfr.org/comments/517501.html#517501(...) pas mal des possibilités qu'offre le Hurd à tous les niveaux.
Bien entendu, l'utilisateur de base se fiche des translators, des jetons, ou de tout le reste. Mais des droits bien utilisés lui serviront à lui apporter plus de sécurité. Je suis sûr qu'il serait tout à fait envisageable d'utiliser au mieux les jetons pour les utilisateurs, moyennant quelques réflexions sur l'interface. Ce dont je suis sûr également, c'est que les translators bien utilisés lui apporteront plus de stabilité, moins de limitations étranges ("MAIS! Pourquoi je peux accéder à mon répertoire en WebDAV dans Gedit et pas dans Rox ?" "Mais euh... Pourquoi c'est si compliqué pour avoir mon CD en utilisateur ?" "gnu... pourquoi je peux pas accéder à mon .zip comme sous Windows sous XY ?"), et probablement de nouvelles fonctionnalités que les programmeurs auront pu implémenter grâce aux translators. Mais globalement, le coeur de système d'exploitation n'offre pas de changement visible : il permet de nouvelles fonctionnalités, plus de sécurité, plus de fiabilité, plus de stabilité, et plus de performances. Je pense que le Hurd peut fournir tout ça.
(Le concept de translators est plus vaste que les systèmes de fichiers virtuels que tu envisages : en fait, sous GNU/Hurd, à chaque fichier est attaché un programme. Quand tu accèdes à ce fichier (le lit avec cat, y écrit avec sed), c'est le programme attaché qui reçoit les requêtes et y répond. Ce programme est un programme tout ce qu'il y a de plus classique, lancé quasiment normalement, avec les droits de l'utilisateur qui l'a lancé, toussa. On appelle translator tout programme qui est attaché à au moins un fichier. Que ce soit ftpfs, ou ext2fs.)
[^] # Re: Le Hurd...
Posté par Manuel Menal . En réponse à la dépêche Hurd : nouvelle version de Debian GNU/Hurd et avancée du port sur L4. Évalué à 5.
Mon système de rêve ? Ce serait bien sûr une Gentoo/Hurd. Il y a déjà un tel projet (http://hurd.rustedhalo.net(...(...))) mais il ne peut pas avancer plus vite que le Hurd lui même. Autant dire qu'il va falloir attendre un peu.
Il faut comprendre que le projet Hurd est de facto très lié à Debian GNU/Hurd. Si Debian GNU/Hurd n'est pas la distribution oficielle, ni quoi que ce soit, le développement du Hurd a repris avec la création de Debian GNU/Hurd par Marcus Brinkmann en 1998, et la plupart des développeurs actuels sont passés par le développement de la distribution. Aussi, Gentoo/Hurd aura probablement du mal à exister pour le moment. Je ne suis pas bien sûr d'ailleurs qu'on ait besoin de plusieurs distributions pour le moment : le boulot principal est de porter les applications, qui ont souvent de légères incompatibilités POSIX qui nécessitent quelques patchs. C'est un boulot très indépendant de la distribution, donc, et je pense que concentrer les efforts (et les sources de patchs, en plus) à ce moment du développement est la meilleure solution. Mais libre à chacun de faire sa distribution ;-)
Pour la swap, le comportement par défaut est historique, parce que pendant un temps, swapon(8) ne reconnaissait simplement pas les signatures de swap Linux. Il en est maintenant capable, et le patch pour faire qu'il ne swappe pas sur n'importe quelle partition non-signée par défaut devrait être bientôt intégré, probablement dans le prochain paquet 'hurd'.
Pour l'installation, si tu utilises Gentoo, tu utiliseras vraisemblablement les CDs. L'installation à proprement parler est très simple. C'est un installeur Debian de base. Le plus complexe est de ne pas oublier d'installer et de configurer correctement son Grub. Ensuite, la phase de post-installation est un peu fastidieuse... rien d'insurmontable ceci dit. Toute l'installation est décrit sur http://hurdfr.org/pages/doc/GuideInstall.pdf(...) ; il manque juste un apt-get install console-driver-xkb entre le configuration d'apt et le lancement de la console.
Pour l'AMD64, ne fournit-il pas une émulation IA-32 classique ? Alors, il ne devrait y avoir aucun problème... Il n'y a pas grand intérêt à exploiter le 64 bit dans la version actuelle du Hurd, qui utilise GNU Mach. C'est juste pour test et découverte que tu l'installeras.
- Puisque l'on parle de support, le Hurd pourra t-il faire tourner directement les binaires Linux (un peu comme FreeBSD, sauf erreur), ou est-ce une utopie ?
C'est théoriquement faisable. Ça n'est pas fait : il manque encore un petit nombre de choses à notre branche de la Glibc, un certain nombre de choses au Hurd pour que ce soit envisageable. Mais est-ce souhaitable ? C'est assez lourd à maintenir, ça nous contraint à supporter des spécificités sans que ce soit -réellement- nécessaire. Il suffit de recompiler l'ensemble des logiciels, chose que l'on fait déjà. Et ça se passe très bien. Effectivement, les BSD (Free et Net du moins) ont ce support. Qui ne sert que pour les logiciels propriétaires. Je ne crois pas que l'un de nous ait envie de passer son temps à ça. Vous êtes libres de faire ce que vous voulez ;-)
- La doc...Elle a fait des progrès, d'accord, mais il y encore du boulot... Les experts y trouvent sans aucun doute leur bonheur, mais c'est un peu dur de s'intéresser à ce système si on ne comprend pas vraiment comment l'utiliser.
HurdFR.org doit encore être réorganisé, c'est vrai. Mais un documentation comme le guide d'installation, assez souvent maintenu à jour devrait grandement aider. Avec l'arrivée du Wiki, nous espérons pouvoir maintenir pas mal d'informations à jour facilement accessible. En attendant, le Wiki du projet Hurd (http://hurd.gnufans.org(...) - il n'a rien d'officiel) contient pas mal d'infos.
[^] # Re: heeeuu
Posté par Manuel Menal . En réponse à la dépêche Hurd : nouvelle version de Debian GNU/Hurd et avancée du port sur L4. Évalué à 10.
On ne peut pas comparer l'avancée de deux projets en voyant "celui-là a supporté ça en X mois, celui-là en X années". Pas sur des projets dont la conception et les fondements sont totalement différents. Dans Unix, les systèmes de fichiers sont implémentés comme des objets à part, ayant juste à répondre à quelques appels définis par un VFS. Il est bien évident que dans ce contexte, il n'y a aucun problème pour supporter les systèmes de fichiers de plus de 2Go. Le Hurd fait le choix d'implémenter les systèmes de fichiers en tant que pagers associés à un "backing store" spécial (le système de fichiers sur disque). C'est une conception qui simplifie beaucoup de choses et permet une très grande flexibilité, à mon avis. Mais au moment de l'écriture concrète d'ext2fs, les auteurs font le choix d'avoir quelque chose qu'on sait limité, mais simple et stable : mapper tout le système de fichier en mémoire. Or sur IA-32, les espaces d'adressage font 4Go. On enlève la place réservée au noyau (comme sur tous les autres systèmes d'exploitation), on est autour de 2Go. La supprimer signifie reconcevoir un système permettant de mapper en mémoire juste ce qu'il faut, quand il le faut. C'est loin d'être trivial, et changer ext2fs c'est pendant un temps rendre extrêmement instable le système - et donc, ralentir le développement de toutes les autres parties.
Tout ça pour dire que ça n'est pas une "limitation à la con", parce qu'ext2fs serait une implémentation simplissime, le genre de trucs qu'on écrit à la va vite au début. Et en aucun cas ça ne permet de juger de l'avancée du projet. Au moment où ext2fs avait déjà cette limitation, le Hurd supportait déjà les sous-Hurd, c'est à dire l'exécution de plusieurs systèmes presque totalement indépendants, en parallèle, depuis plusieurs années. Chose que ni Linux avec chroot, ni FreeBSD avec jail, ni aucun autre système libre ne supporte. Le Hurd supporte effectivement le système de "jetons" dont j'ai maintes fois parlé. Je peux d'ores et déjà avoir un FTPd qui tourne sans -aucun- droit et qui les gagne en cours d'exécution, sans bidouille, sans problème. Je peux d'ores et déjà avoir mon ext2fs en utilisateur. Je peux d'ores et déjà lancer sans crainte mon ftpfs. Des choses que Linux n'est pas capable de faire, après quatorze ans de développement. Les projets n'évoluent pas forcément pareil, il faut s'y faire. Et les réactions ricanantes de certains me font désespérément penser à l'européano-centrisme d'autres face aux sociétés dites "primitives". Aussi inutile et biaisé.
On précisera par ailleurs que le patch pour ext2fs existe depuis plusieurs années. S'il n'a pas été intégré plus tôt, c'est par manque de testeurs. Il a été annoncé, y compris sur des sites francophones. C'est très vite de juger que de mettre en cause les développeurs du projet pour un tel "retard".
[^] # Re: live cd
Posté par Manuel Menal . En réponse à la dépêche Hurd : nouvelle version de Debian GNU/Hurd et avancée du port sur L4. Évalué à 2.
Effectivement, on peut penser faire tourner le Hurd en parallèle avec Linux sur L4, dans le cadre de L4Linux, comme TU-Dresden le fait avec DROPS. Maintenant, c'est loin d'être trivial, tout de même. Les projets qui l'utilisent actuellement font tourner des choses relativement haut niveau, et pas vraiment deux systèmes totalement en parallèle. Pour faire tourner les deux personnalités totalement différentes en parallèle, il faut que les serveurs de base puissent être communs, et sachent s'en sortir avec des contraintes très, très différentes (tâches auto-paginées d'un côté, mémoire bloquée de partout de l'autre, ...). Je crois qu'il est plus sain de vouloir d'un GNU/Hurd totalement autonome dans un premier temps, d'autant plus que dans l'état actuel des choses c'est loin d'être inenvisageable. La possibilité de faire tourner en parallèle plusieurs personnalités si différentes est à garder en tête, sans plus : la possibilité des co-Hurd et des sous-Hurd me semble bien plus importante au début.
[^] # Re: live cd
Posté par Manuel Menal . En réponse à la dépêche Hurd : nouvelle version de Debian GNU/Hurd et avancée du port sur L4. Évalué à 3.
[^] # Re: sécurité des serveurs
Posté par Manuel Menal . En réponse à la dépêche Hurd : nouvelle version de Debian GNU/Hurd et avancée du port sur L4. Évalué à 10.
De façon plus générale : en séparant les parties qui peuvent l'être, en définissant clairement quelles sont leurs relations et séparations, on permet plusieurs choses :
Tout ce qui n'est pas purement vital au système, s'il se retrouve attaqué, n'entraîne que lui. La pile TCP/IP n'est pas vitale au système. Le driver son l'est encore moins. Chacun étant des applications tournant dans leur propre espace d'adressage, utilisant leur propre mémoire, elles n'entraîneront qu'elles-mêmes dans leur chute. On l'a vu, d'ores et déjà, il y a quelques années, quand un serveur Web sous GNU/Hurd avait subi un /.age en règle : la pile TCP/IP s'était vautrée un nombre incalculable de fois, la machine pas.
On peut réellement réfléchir aux permissions nécessaires à telle ou telle application. Sous Unix, la tradition veut que la plupart des parties considérées comme "centrales" se retrouvent intégrées dans le noyau. Souvent par besoin, du fait de sa conception. Parfois par commodité. Certaines parties se trouvent avoir besoin de permissions spéciales, et en effet certains serveurs sont très privilégiés sous GNU/Hurd (ils tournent en root, et L4 ne leur restreint aucun appel système). Ces serveurs sont sensibles, et facilement identifiables comme tels. Mais un grand nombre d'autres (et je pense aux pilotes de périphérique, par exemple) ne nécessitent "que" de tourner en root (et encore, pas tous !). Ces parties deviennent de suite moins critiques. Il y a donc un double gain : un gain de clarté pour l'identification des parties centrales, sensibles ; un gain de sécurité lié aux privilèges donnés concrètement aux applications.
C'est une évidence, mais il est bien plus facile d'auditer un code entièrement organisé en composants indépendants qu'un code "monolithique". Les effets de bord sont bien moins complexes, d'une part. On a souvent vu des horreurs comme des off by one dans un bout de code aboutir à une erreur de calcul assez embêtante de la taille d'un tableau, qui avec l'arrondi nécessaire se retrouvait assez pour être exploitable, ou potentiellement exploitable. Inutile de dire qu'une telle erreur est quasiment indétectable, et qu'un audit qui irait jusqu'à les rechercher prendrait des années. D'autre part, la séparation claire et revendiquée amène à faire quelque chose que Linus Torvalds s'est toujours refusé à faire pour Linux : concevoir des interfaces, stables tant que possible. La série de failles locales récentes découvertes dans Linux étaient liées à des comportements erratiques lorsque telle option était à telle valeur, tel pointeur à telle autre, etc., etc. Avoir des interfaces en mouvement constant, tandis que le code les utilisant l'est pas forcément du tout, n'aide pas à prévenir ce genre de problèmes. Je sais d'expérience que je me rends compte du comportement lors des cas limites principalement lorsque je documente mes fonctions/interfaces attentivement. Chose qu'évidemment, je ne ferai pas si elles sont destinées à être modifiées dans deux mois. Et chose qui n'est pas faite avec Linux. Les interfaces du Hurd, elles, sont stables. Il n'y a eu globalement qu'un changement qui a tout cassé (cassé l'ABI) depuis la première stabilisation. Bien entendu, on ne peut pas exclure qu'il y en ait d'autres, mais elles seront très, très limitées. Plus de clarté, à mon sens, c'est plus de sécurité, et c'est aussi une meilleure utilisation de ces interfaces, donc moins prône aux erreurs.
Pour exemple, le coeur du système d'authentification du Hurd, représente 358 lignes de code (comptées par sloccount ;-). C'est LA partie du système qui nécessite de tourner en root, et qui nécessite d'être complètement et entièrement de confiance. 358 lignes, je pense que c'est faisable de l'auditer. Bon courage pour faire la même chose sur un Unix ;-)
[^] # Re: Erreur de langue
Posté par Manuel Menal . En réponse à la dépêche Hurd : nouvelle version de Debian GNU/Hurd et avancée du port sur L4. Évalué à 4.
[^] # Re: Qemu
Posté par Manuel Menal . En réponse à la dépêche Hurd : nouvelle version de Debian GNU/Hurd et avancée du port sur L4. Évalué à 4.
[^] # Re: Compléments
Posté par Manuel Menal . En réponse à la dépêche Hurd : nouvelle version de Debian GNU/Hurd et avancée du port sur L4. Évalué à 10.
Concernant la place, à peu près équivalente à une Debian GNU/Linux. Le système de base tient sur 31Mo compressé (le mini-CD de K8 fait 33Mo). Évidemment, en général, quand on utilise GNU/Hurd c'est pour tester, et que ce soit pour du packaging ou du développement à tous niveaux, il faut compter de la place pour /src. ;-)
Comme je le disais, 71% de l'archive Debian fonctionne. Le reste nécessite généralement des patchs assez simples liés à des problèmes connus (MAXPATHLEN/PATH_MAX, MAXHOSTNAMELEN, NCARGS). En revanche, les gros morceaux que sont Gnome, KDE ou OpenOffice.Org ne fonctionnent pas, pour des raisons diverses : certaines parties dépendent inconditionnellement de la mémoire partagée SysV (shmget(2), mais c'est rare), certaines ont besoin des file locks (flockfile(3), c'est le cas notamment de GConf), etc. Bref, tout un tas de petits trucs qui manquent et qui empêchent le port de "grosses" applications où la probabilité qu'elles soient utilisées augmente. Il n'y a plus aucun problème avec les threads depuis que les pthreads sont parfaitement supportés, grâce à Neal H. Walfield. (enfin, parfois il y a une différence d'interprétation de POSIX entre NPTL/LinuxThreads et la libpthread du Hurd, mais c'est rare)
Lors de nos démonstrations, on utilise généralement WindowMaker, rxvt, gqview, mplayer en aalib. Ce genre de choses ne nous crée que rarement des surprises. Mais il ne faut pas rêver, d'abord c'est assez lent, et ça ne marche pas toujours. M'enfin, les visiteurs de Solutions Linux ont pu le voir marcher assez bien en général. ;-)
Concernant la portabilité, seul IA-32 est supporté pour GNU/Hurd sur Mach. Il faut bien comprendre que le but de cette branche actuellement est de faire qu'un max de gens testent et portent les paquets, etc., etc. IA-32 étant utilisé par le plus de gens, il est logique de la supporter en priorité - et nous n'avons pas les moyens de supporter hurd-ppc, hurd-ia64 ou que sais-je. Pour les courageux - voire téméraires -, le Hurd devrait tourner sur toutes les machines supportées par une implémentation de Mach respectant les interfaces de CMU Mach 3.0 (donc, compatible GNU Mach). Des implémentations existent sur Alpha, Sparc, Sparc64, PowerPC (oldworld seulement). Bon courage ;-)
Le Hurd sur L4 en revanche est développé avec la portabilité en tête, principalement sur PowerPC. L4Ka::Pistachio (l'implémentation de L4 qu'on utilise) lui-même tourne sur un grand nombre d'architectures (Alpha, AMD64, ARM, IA32, IA64, MIPS, PPC32, PPC64, cf. http://www.l4ka.org/projects/pistachio/(...) pour plus d'informations). Il est bien évident que GNU/Hurd a pour ambition d'être un système versatile, flexible, pouvant s'adapter du système "embarqué" relativement évolué (avec MMU, sans quoi ça n'a plus grand sens, donc on est sur de l'embarqué style ordinateur de bord, frigos ;-) aux grosses machines ayant besoin de virtualisation, de domaines, toussa. Et puis, la portabilité était un argument de vente majeur des micro-noyaux, montrons que tout n'était pas faux ;-)
[^] # Re: Compléments
Posté par Manuel Menal . En réponse à la dépêche Hurd : nouvelle version de Debian GNU/Hurd et avancée du port sur L4. Évalué à 10.
Par ailleurs, et j'aurais aimé l'intégrer dans la news. HurdFR, suite à sa dernière assemblée générale, s'est dotée de pas mal de nouveaux outils : un Wiki en construction (http://wiki.hurdfr.org(...) pour l'instant en lecture seule - envoyez un mail à wiki at hurdfr dot org pour obtenir un compte), 4-5 machines disponibles aux membres (et quelques curieux) pour tests, un autobuilder pour Debian GNU/Hurd, et tout plein de nouveaux projets (qui se trouveront très bientôt sur le Wiki). N'hésitez pas à vous inscrire à la liste (https://lists.hurdfr.org(...) en donne une ... liste), à passer sur notre canal IRC (#hurdfr sur irc.freenode.net), et à vous inscrire sur http://hurdfr.org/index.php?page=pages/hurdfr.php(...) !
# Compléments
Posté par Manuel Menal . En réponse à la dépêche Hurd : nouvelle version de Debian GNU/Hurd et avancée du port sur L4. Évalué à 10.
Mais aussi excitant que soit le port sur L4, GNU/Hurd continue à exister sur GNU Mach, et comme le rappelle la news, cette partie aussi continue à subir de nombreux changements. Le support des partitions de 2Go intégré (le patch existe depuis longtemps, mais nécessitait des tests qui n'ont pas toujours été faciles à trouver), le support XKB de la nouvelle console definitivement stable (et facile a installer) sont des progres importants pour l'utilisabilite de tous les jours. On peut desormais avoir, en standard, une vraie console, avec support des terminaux virtuels, de differents encodings (jusqu'à UTF-32, testé et approuvé), de différents "maps" de clavier, et XFree86, l'utilisant, s'en trouve grandement amélioré (finis les problèmes récurrents avec les souris série, ou le XKB qui ne marche pas en utilisateur). Dans les nouveautés à venir : GNU Mach supporte dorénavant la plupart des cartes réseaux que vous possédez grâce au gnumach-nic-update dispo sur http://www.update.uu.se/~ams/patches/ (en fait, toutes celles supportées par les drivers de Donald Becker) ; après PPP, le support DHCP fonctionnel ; après ext2fs sans limites, une nouvelle version d'ext3fs ; et qui sait, PPPoE pourrait voir le jour, mmh. ;-)
Par ailleurs, le développement de Debian GNU/Hurd continue de plus belle. 71% de l'archive Debian est disponible. Des dépendances importantes, qui empêchent beaucoup de paquets de compiler, comme krb4, krb5 ou d'autres sont compilables. Mozilla a été compilé, même s'il ne fonctionne pas encore.
Qu'il y ait des développements dans les deux branches ne doit pas surprendre ou inquiéter. Tous les développements qui ont lieu sur la console, sur le support DHCP, sur ext3fs, ou tout ce que j'ai mentionné est parfaitement transférable de la version du Hurd actuelle vers celle portée sur L4. Ainsi, chacun peut contribuer à son niveau, selon son temps disponibles et ses envies, et, si tout va bien, les deux branchent sauront fusionner.
[^] # Re: Sound Juicer et Goobox sont des rippeurs
Posté par Manuel Menal . En réponse à la dépêche Gnome 2.10 approche. Évalué à 3.
[^] # Re: bah un vaporware pardi !
Posté par Manuel Menal . En réponse au journal GNU/Hurd c'est quoi au fait ?. Évalué à 5.
[^] # Re: Pour le C++
Posté par Manuel Menal . En réponse au journal GNU/Hurd c'est quoi au fait ?. Évalué à 4.
[^] # Re: Impressions...
Posté par Manuel Menal . En réponse au journal GNU/Hurd c'est quoi au fait ?. Évalué à 7.
deb http://packages.hurdfr.org/unstable/binary-hurd-i386(...) ./
Tu peux retrouver ensuite la documentation sur http://www.hurdfr.org/pages/doc/GuideInstall.pdf(...) dont je ne poste que le bout te concernant :
# console -d vga -d xkb ??xkbdir=/etc/X11/xkb ??keymapfile=keymap/hurd \ ??keymap=fr ??repeat=kbd -d pc_mouse ??repeat=mouse -c \ /dev/cons /dev/vcs
... lance la nouvelle console du Hurd (qui supporte différents encoding, le son, les couleurs, différents VTs, tout ça) avec un clavier en français. On crée les liens qui vont bien avec :
# ln -s /dev/cons/kbd /dev/kbd && ln -s /dev/cons/mouse /dev/mouse
... et on configure XFree86 pour utiliser le support souris de la console :
Section "Pointer"
Protocol "osmouse"
Device "/dev/mouse"
EndSection
Et le tour est joué ! Une console en français qui marche parfaitement, et un XFree86 par dessus. Attention, XFree86 est assez lent, du fait du manque de mémoire partagée SysV (shmem). Mais c'est plus que vivable, en fait c'est tout à fait décent. Par contre, plus tu fais tourner de choses sur ton système, plus tu auras des chances de rencontrer un plantage ;-) Pour une utilisation normale sans XFree86, j'ai pu tourner plus d'un mois sans aucun problème, avec une utilisation très "banale" (ouaibe, IRC, ssh, emacs, gcc, tout ça...).
[^] # Re: Pour le C++
Posté par Manuel Menal . En réponse au journal GNU/Hurd c'est quoi au fait ?. Évalué à 7.
Concernant L4Ka::Pistachio, s'il est écrit en C++, il évite tout ce qu'on critique généralement sur le C++ : il n'utilise pas d'exceptions, pas de méthodes virtuelles, extrêmement peu d'héritage (quelques classes génériques avec de l'héritage pour les implémentations spécifiques à l'architecture), évidemment pas la STL, pas de templates, ...
Bref, du C avec le sucre syntaxique. Au lieu de faire des struct avec des pointeurs de fonction, il y a quelques class par ci par là. Même moi, qui pourtant ne supporte définitivement pas le C++ (allergie suite à une intoxication, un peu comme les fruits de mer vous voyez ?), je supporte très bien le source de L4Ka::Pistachio. C'est dire ;-)
# Des éléments de réponse plus détaillés
Posté par Manuel Menal . En réponse au journal GNU/Hurd c'est quoi au fait ?. Évalué à 7.
Ensuite je suis tombé sur L4[6], Pistachio[7], Fiasco[8] et L4Linux[9].
Et c'est là que j'ai décroché... Quelles sont les différences ? Leur performances ? Leur (possible) avenir ?
Frédéric a plus ou moins répondu à ça. L4 est une famille de micro-noyaux. À l'origine, c'était le nom d'un micro-noyau que le très regretté Jochen Liedtke a écrit en assembleur pour x86 vers 1995. Jochen a écrit de nombreux papiers à son sujet, et il a également écrit une spécification pour ce noyau. De telle sorte que plusieurs implémentations ont vu le jour dans plusieurs laboratoires d'informatique, principalement en Allemagne (Karlsruhe et le projet L4Ka, Dresden et le projet Fiasco/DROPS) mais également chez nos amis Grands Bretons (Université de York, avec le premier port PowerPC), et même chez les Aussies (University of New South Wales, qui fournit beaucoup de documentations et de cours, et L4/MIPS).
Les spécifications ont évidemment évolué depuis, pour donner les spécifications X.0, puis X.2. L4Ka::Pistachio est l'implémentation de L4 choisie par le Hurd. Elle implémente la spécification X.2, la plus récente. La version précédente était L4Ka::Hazelnut, qui implémentait la spécification X.0. La voie choisie par Fiasco et l'Université de Dresde est différente, puisqu'ils continuent d'utiliser la spécification V2 (avec une compatibilité X.0), et se concentrent plus sur le développement de l'aspect "temps réel" (hard) de L4, dans le cadre de leur projet DROPS[0].
Quant à L4Linux, tout a presque déjà été dit. C'est un projet mené aussi bien par L4Ka que par TU-Dresden, qui vise à porter Linux sur L4. Les deux équipes ont des motivations similaires : pour TU-Dresden, c'est une partie importante de leur projet DROPS, parce que celà leur permet d'avoir la personnalité Linux classique, avec toutes les applications et fonctionnalités déjà existantes (prenez un binaire pour GNU/Linux, déposez le sur L4Linux, ça marche !) en parallèle avec leurs applications temps réel utilisant L4. C'est une façon assez simple de tester leur Fiasco, et surtout de fournir un environnement de développement efficace. Pour L4Ka, l'intérêt est d'avoir un environnement stable et complet pour que les développeurs puissent tester leurs applications pour L4, ou leurs changements dans L4, tout en disposant des fonctionnalités de Linux.
Qui plus est, L4Linux a servi de base aux tests[1] menés par L4Ka. Il est effectivement très intéressant de disposer d'une implémentation de Linux native pour x86 et de la même version, portée sur L4, pour mesurer l'overhead pur lié à l'utilisation d'un micro-noyau. Les tests ont donnés L4Linux 6 à 8% moins performant qu'un Linux natif. C'est extrêmement peu, considérant que Linux n'a jamais été conçu pour un tel usage, et donc pour tirer parti des avantages de L4 et des optimisations possibles. Considérez aussi que ces tests datent de 1997, et que L4 a énormément évolué depuis. Voilà qui ne laisse présager que du bon.
Pour l'auteur du journal, et pour les autres aussi. Cela fera bientôt l'objet d'une news DLFP, mais sachez que HurdFR existe bel et bien et est actif. N'hésitez pas à vous inscrire, posez vos questions, participer sur la liste d'HurdFR[2] (les archives ont été perdues récemment, ne cherchez pas... snif.), ou sur IRC[3]. N'hésitez pas non plus à adhérer ;-)
[0]: http://os.inf.tu-dresden.de/drops/overview.html(...)
[1]: http://l4ka.org/publications/paper.php?docid=650(...)
[2]: https://lists.hurdfr.org/mailman/listinfo/hurdfr(...)
[3]: #hurdfr sur irc.freenode.net
[^] # Re: Impressions...
Posté par Manuel Menal . En réponse au journal GNU/Hurd c'est quoi au fait ?. Évalué à 2.
[^] # Re: ben
Posté par Manuel Menal . En réponse au journal GNU/Hurd c'est quoi au fait ?. Évalué à 10.
Concernant la prétendue "réécriture", c'est exactement le genre d'imprécisions qui arrivent quand on écoute l'un ou l'autre. C'est simplement faux. Les développeurs du Hurd ont décidé d'utiliser un autre micro-noyau (L4) que celui utilisé originellement (GNU Mach). Les raisons en sont multiples : d'abord, GNU Mach n'est plus maintenu depuis une dizaine d'années ou presque, et il contient un nombre de bugs impressionants qui ont été découvert avec le temps (le matériel et les besoins évoluant, un logiciel parfaitement stable en 1993 peut se retrouver inutilisable dix ans plus tard, on voit ce problème avec les jeux) ; ensuite, GNU Mach est dépassé techniquement, et il ne permet pas aux yeux des développeurs de créer un Hurd qui soit une alternative crédible aux autres systèmes, notamment pour des raisons de performance ; enfin, c'est un micro-noyau de première génération, très éloigné techniquement de ce qui se fait aujourd'hui dans ce domaine, et il serait insensé de sortir une version du Hurd ne tirant pas profit des micro-noyaux dits de "seconde génération" comme L4.
Les différences entre GNU Mach et L4 sont importantes : l'histoire de Mach remonte à 1975, et la version sur laquelle est basée GNU Mach remonte à 1989, et a évolué jusqu'en 1994 environ. Bien qu'il laisse à l'espace utilisateur un grand nombre de tâches (VFS et systèmes de fichiers, gestion des droits, des processus, une partie de la gestion de la mémoire virtuelle), il garde pas mal de tâches en son sein (la plus grosse partie de la VM, l'ordonnanceur, les pilotes de périphériques, il a un système évolué de communication entre les processus, intégrant des systèmes de sécurité, etc.). C'est ce qui en fait un micro-noyau de première génération.
L4, lui, voit les choses différemment (et il le peut car il hérite de quelques années de recherche de plus dans le domaine). Il n'implémente en son sein que des -mécanismes- de base qui nécessitent de toutes façons des droits privilégiés sur le matériel : mapper/démapper une page, changer le thread en cours d'exécution, envoyer un message d'un thread à un autre, accès basique au matériel, ce genre de choses. Ce ne sont plus des bouts entiers du système d'exploitation qui sont dans le micro-noyau, comme avec Mach, mais des outils. Tout ce qui définit la personnalité du système d'exploitation : gestion de la mémoire virtuelle, pilotes de périphérique, ordonnancement (L4 a un mini-ordonnanceur (RR à priorités strictes), mais la partie décisions d'ordonnancement se fait en espace utilisateur (détermination des priorités)), ou tout ce que vous pouvez voir dans un noyau actuel, se trouve en espace utilisateur.
C'est une différence fondamentale, effectivement. Mais ça ne veut certainement pas dire tout réécrire ! Imaginez le Hurd comme un ensemble de pièces de légo associées les une aux autres savamment, avec les parties "basses" elles-mêmes associées à une grosse pièce de légo, GNU Mach. On divise la hauteur de la pièce du bas par deux, et on enlève la partie supérieure. Il va vous falloir de fait recréer une partie supérieure différente, et qui fournisse tant que c'est possible les mêmes attaches avec les pièces situées plus haut. Évidemment, ça ne sera pas toujours possible et du coup, il faudra peut-être modifier quelques pièces basses de la partie supérieure (le Hurd), mais c'est mineur. Là, c'est exactement pareil. Tout ce qui était dans GNU Mach et qui n'est pas dans L4 doit être réécrit totalement différemment (en espace utilisateur, et c'est un avantage énorme). Mais le reste, ce qui existe déjà dans le Hurd, ne bouge pas ou peu.
Pas de réécriture à l'ordre du jour, donc.