Articles précédents : Code
- [107] SPT : Une alternative au système historique de partitionnement des PC
- [40] Sortie de OpenBGPd
- [60] « Autocompiler » son noyau au démarrage avec TCCBoot
- [11] Busybox 1.0
- [101] John Carmack victime des brevets logiciels
- [154] Le code de Java3D est disponible
- [26] GFS à nouveau en GPL et résultats financiers de Red Hat
- [79] Linux VServer, pour ceux qui ne connaissent pas...
- [34] XFS inclus dans le noyau 2.4
- [48] Alsa-Project : Tout va très vite....
Liens connexes
- KernelTrap : K8 Debian CDs Available (544 hits)
- ISOs K8 (416 hits)
- Debian GNU/Hurd : Manuel d'installation (1535 hits)
- Portage de Hurd sur L4 (643 hits)
- KernelTrap : L4 Port Gets Inital Memory Management Framework Including Self-Paging Tasks (282 hits)
- KernelTrap : First Phase of L4 Port Completed (326 hits)
Dépêche modérée par
Dépêche éditée par
Code : Hurd : nouvelle version de Debian GNU/Hurd et avancée du port sur L4
Posté par Thomas Petazzoni (page perso, ). Modéré le 05 février 2005.
Une des améliorations majeures qu'apporte cette version de Debian est le fameux support des partitions de plus de 2 Go. Globalement, Philip Charles considère K8 au moins d'aussi bonne qualité que K7, la meilleure version jamais produite. Bien entendu, en plus de ce support des grandes partitions, K8 apporte de nouvelles versions de tous les logiciels de la Debian.
La version du Hurd utilisée pour l'instant dans Debian GNU/Hurd est basée sur le micro-noyau Mach. Les développeurs de Hurd travaillent actuellement au portage de Hurd sur un autre micro-noyau, L4. Celui-ci, plus petit et plus efficace, doit permettre à terme d'améliorer la conception du Hurd et ses performances.
Le 11 janvier, Neal Walfield ajoutait au port Hurd sur L4 la gestion de la mémoire physique et virtuelle. Le 1er février, Marcus Brinkmann parvenait à exécuter la première application utilisateur sous Hurd/L4 : banner. Cette étape constitue une avancée majeure dans le développement.
![[en]](../../../images/en.png)
KernelTrap : K8 Debian CDs Available (544 hits)-
ISOs K8 (416 hits)
![[fr]](../../../images/fr.png)
Debian GNU/Hurd : Manuel d'installation (1535 hits)-
Portage de Hurd sur L4 (643 hits)
-
KernelTrap : L4 Port Gets Inital Memory Management Framework Including Self-Paging Tasks (282 hits)
-
KernelTrap : First Phase of L4 Port Completed (326 hits)
> Lire la dépêche (96 commentaires, moyenne: 3,4).
[+] warning : troll inside
Bon, bon travail les gars ?
une petite estimation du jour où je pourrais faire tourner kde + oOo.org dessus ?
(...)
-
[+] [^]Re: warning : troll inside
Posté par Pierre Tramo (page perso, ) le 05/02/2005 à 16:10. (lien). Évalué à -2.10ans ? le temps d'implémenter le support des partitions de plus de 2 Go avec L4
-
[^]sécurité des serveurs
Posté par free2.org (page perso, ) le 05/02/2005 à 21:05. (lien). Évalué à 9.Je pense que la petite taille du noyau et le petit nombre d'appels systèmes (environ 10 pour l4 je crois) seront aussi très utiles pour la sécurité des serveurs: c'est plus facile d'auditer un petit noyau qu'un gros !
L4 est si petit qu'on peut même envisager d'en faire une preuve formelle (ou au moins démontrer qu'il n'y a pas de faille de sécurité dedans).-
[^]Re: sécurité des serveurs
Posté par reno () le 05/02/2005 à 23:18. (lien). Évalué à 4.Ahem, pas d'accord: ce qui n'est plus implémenté dans le nano-noyeau mais au dessus doit quand même être audité.
Ca te fait une belle jambe si la faille vient d'une surcouche plutot que du noyau..-
[^]Re: sécurité des serveurs
Posté par Manuel Menal (page perso, ) le 06/02/2005 à 00:11. (lien). Évalué à 10.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 ;-)-
[^]L4 pour applications simples sécurisées indépendantes d'une couche POSIX
Posté par free2.org (page perso, ) le 06/02/2005 à 12:41. (lien). Évalué à 3.En effet, les applications les plus simples (et donc les plus faciles à auditer) n'ont pas besoin des nombreux appels systèmes définis par la norme ISO POSIX qui sont fournis par les nombreux serveurs de HURD.
Par exemple un programme demandant une passphrase à l'utilisateur lors du boot et utilisant ensuite cette passphrase pour décrypter une quantité limitée de fichiers ou de clés privées (on lui fournit des données cryptées en entrée, il les fournit décryptées en sortie). Ce programme peut s'appuyer directement sur les appels systèmes de L4 (et/ou sur un nombre restreint de serveurs du HURD choisis parmis les plus simples et les plus faciles à auditer).
Une fois L4 bien audité, on aura la garantie que la passphrase ne sera jamais accessible à aucun autre programme. Et que seuls un nombre limité de fichiers ou de clés seront accessibles en clair à un éventuel intrus ayant réussi à compromettre un des serveurs du HURD.
-
[^]Re: sécurité des serveurs
Posté par PasChauve PasOunet () le 08/02/2005 à 16:55. (lien). Évalué à 2.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.
Quel est l'interêt vu au final ca revient au même , la page web ne s'affiche pas.-
[^]Re: sécurité des serveurs
Posté par free2.org (page perso, ) le 08/02/2005 à 17:28. (lien). Évalué à 3.L'intéret est ici dans un nombre incalculable de fois !
C'est à dire qu'on peut relancer indéfiniment la pile TCP/IP sans dommage pour le reste du noyau, et bien plus rapidement que si on doit rebooter une machine à la main (et même les reboot automatiques, quand ils sont possibles, ne sont pas très rapides non plus)-
[^]Re: sécurité des serveurs
Posté par Manuel Menal (page perso, ) le 08/02/2005 à 19:48. (lien). Évalué à 4.Et qu'elle se relance automatiquement, qui plus est, translators passifs obligent. Sans aucun dommage pour les systèmes de fichiers, pour les autres services en cours, etc., etc.
-
[^]solution actuelle pour OO.org et applis complexes: L4 Linux realtime
Posté par free2.org (page perso, ) le 11/02/2005 à 15:36. (lien). Évalué à 4.Pour ceux qui veulent faire cohabiter dès aujourd'hui des applications Linux complexes (OO.org) avec de petites applications sécurisées pour L4/Hurd, ils peuvent essayer la cohabitation de Hurd avec le port de Linux pour L4:
http://os.inf.tu-dresden.de/L4/LinuxOnL4/(...)
PS: si je me souviens bien, la plupart des versions vraiment realtime de Linux sont en fait des ports de linux sur un micronoyau temps réel. Et L4 est temps réel.
-
-
-
-
-
-
Un mot
je n'aurai qu'un mot :
##### ##### ## # # #### # # # # # # # # # # ##### # # # # # # # # # # ##### ###### # # # # # # # # # # # # # # ##### # # # # ## ####
-
[^]Re: Un mot
[+] heeeuu
30 décembre 2004 : support des partitions de plus de 2 Go
mouahahahaha
</ commenaire constructif >
-
[^]Re: heeeuu
Posté par bmc () le 05/02/2005 à 16:36. (lien). Évalué à 10.Heureusement que tu es là pour les encourager et les aider, parce que je ne sais pas comment ils auraient fait sans des personnes comme toi. Parfois, ils doivent en avoir marre, et je suis certain qu'ils se motivent en disant qu'ils vont faire taire les blaireaux dans ton genre. Merci, car grâce à toi on devrait avoir d'ici quelques mois un Hurd utilisable sur L4.
-
[^]Re: heeeuu
Posté par Veiovis () le 06/02/2005 à 14:29. (lien). Évalué à 4.C'est facile de défendre les faibles et les opprimés par un message candide. En pratique, il faut bien constater l'avancement du projet et je suis sûr que beaucoup ont sursauté en lisant 2Go et puis ont souri de... nostalgie!
Bravo pour leur persévérance: c'est une belle leçon; mais on ne peut pas applaudir le résultat. La démarche tout au plus. Mais on attendrait des efforts plus importants, notamment de ceux qui se drapent de l'admiration la plus criarde.-
[^]Re: heeeuu
Posté par Manuel Menal (page perso, ) le 06/02/2005 à 15:23. (lien). Évalué à 10.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".-
[+] [^]Re: heeeuu
Posté par Veiovis () le 06/02/2005 à 16:40. (lien). Évalué à -10.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
:-) On se connaît?
Et en aucun cas ça ne permet de juger de l'avancée du projet.
Bien d'accord. Et alors?
Les projets n'évoluent pas forcément pareil, il faut s'y faire.
Alors, tu accepteras peut-être des appréciations différentes des résultats.
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".
C'est vrai que j'avais oublié les Droits de l'Homme poussés à leur extrême, là où tout le monde devient égal au point d'être identique et imperméable à la critique (eh oui, cette dernière discrimine, quelle horreur!). C'est vrai que ce site en est une très bonne illustration (et j'ai du mal à m'y faire). Et dire que la société va devenir aussi aveugle que lui. :-/
-
[+] [^]Re: heeeuu
Posté par gallenza () le 06/02/2005 à 21:38. (lien). Évalué à -5.Donc ces 2 Go ce ne seraient valables que pour cet archaique systeme de fichier qu'est ext2??? et bien là je suis désolé mais je pense que ton propos s'auto-contre sur la réalité de la valeur technologique du hurd...
-
[^]Re: heeeuu
Posté par Manuel Menal (page perso, ) le 06/02/2005 à 22:20. (lien). Évalué à 10.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-
[^]Re: heeeuu
Posté par gallenza () le 07/02/2005 à 01:43. (lien). Évalué à 0.Je suis tout à fait d'accord sur le fait que le fait de supporter un nombre important de systèmes de fichiers n'est pas la priorité que doit avoir Hurd à l'heure actuelle, cependant j'utilise depuis que j''utilise Linux (2001), des systèmes de fichiers journalisés ET évolués (!=ext2or3) c'est à dire utilisant les algo de dernière génération pour l'organisation et la recherhce des données comme les arbres B+, donc je répète que pour moi ext2or3 et UFS sont archaiques, même si ils le sont moins que FAT32 qui ne ressemble vraiment à rien.
-
-
-
[^]Re: heeeuu
Posté par Chl (page perso, ) le 07/02/2005 à 12:23. (lien). Évalué à 2.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.
ftpfs, c'est ce qu'on appelle un translator, qui permet de monter une arborescence ftp distance, sur son systeme de fichier local pour pouvoir effectuer des ls, cp, mkdir de facon transparante ?
Sous linux pour faire cela il suffit d'utiliser :
http://lufs.sourceforge.net/lufs/(...)
Voici une description rapide :
LUFS is enabling you to mount into your file hierarchy a remote computer's file system, which is accessible by various means (ftp, ssh, etc.). Then, the access to the remote files will be completely network transparent. In other words, you'll be able to read/modify remote files as if they were local, watch movies/listen to MP3s from FTP/SSH/Gnutella servers without copying them locally. Sheer magic. Now skip to the next section.
LUFS is a hybrid userspace file system framework supporting an indefinite number of file systems transparently for any application. It consists of a kernel module and an userspace daemon. Basically it delegates most of the VFS calls to a specialized daemon which handles them.-
[^]Re: heeeuu
Posté par Pinaraf (Jabber id, ) le 07/02/2005 à 12:49. (lien). Évalué à 3.Oui, certes :)
Mais c'est pas intégré au système, donc si l'api utilisée par lufs est cassée lors d'une mise à jour du noyau, y'aura un pb.
De plus, est-ce-que ça marche sans root ?-
[^]Re: heeeuu
Posté par karteum59 () le 07/02/2005 à 18:32. (lien). Évalué à 6.Concernant LUFS :
- ça ne risque pas d'être intégré un jour ou l'autre au noyau, l'API est très différente et en C++ (comme l'implémentation d'ailleurs).
- c'est pas vraiment trivial d'implémenter un nouveau fs dedans (nécessité de recompiler le tout... en tout cas à l'époque où j'avais voulu faire un truc dessus)
- La dernière version date du 30 octobre 2003. Je considère le projet comme abandonné devant un autre plus prometteur nommé fuse.
Alors, fuse
- est en C
- semble plus clean (en tout cas pour ce que j'en ai fait) et est à coup sûr plus actif
- pourrait être bientôt intégré au noyau Linux (en tout cas c'est ce que j'ai lu...).
- a depuis peu un tout nouveau site tout beau : http://fuse.sourceforge.net/
On peut se demander pourquoi Linux n'utilise pas ce genre de truc depuis 14 ans, ça permet de décharger _énormément_ le noyau et donc les efforts du programmeur puisqu'on peut désormais utiliser les bibliothèques partagées (un exemple : la libsmbclient permet de faire un fs smb/CIFS stable et complet en quelques lignes de code plutôt que d'utiliser l'immonde smbfs du noyau !). Des gros fs comme coda/intermezzo gagneraient également énormément à être implémentés de cette manière...
Petite question hors-sujet pour ceux qui connaissent bien les arcanes du hurd ou de la conception d'OS : pourquoi vouloir absolument scinder l'OS en de multiples processus serveurs ayant chacuns leur espaces d'adressages distincts ? OK pour la sécurité/sûreté mais ce que je veux dire c'est que ça pénalise tout de même pas mal les performances (changements de contextes, cache invalidé...) et il y a peut-être d'autres moyens de virer du code hors du noyau sans en passer par là. N'y aurait-il pas par ex. moyen de faire que (si l'utilisateur le configure ainsi) le hurd puisse utiliser davantage le concept de bibliothèques partagées (i.e. des bouts de code mappés dans l'espace d'adressage de l'appli en cours) plutôt que de "serveurs" ? Par exemple, on pourrait à mon avis fort bien imaginer que toute la pile IP, le firewalling, etc soit implémenté dans une (ou des) DLLs, idem pour les pilotes de périphériques, etc. Il me semble (mais je ne suis pas sûr, qqun peut confirmer ?) que c'est un peu l'idée des exokernels, et qu'apparemment ça booste bien les perfs et ça rassemble le meilleur des deux mondes (système rapide, modulaire et tout petit noyau).-
[^]Re: heeeuu
Posté par Manuel Menal (page perso, ) le 08/02/2005 à 20:33. (lien). Évalué à 10.Que ce soit pour FUSE ou pour LUFS, vous songez sérieusement ajouter au VFS central de votre système, dans le noyau, un système de fichiers du style WebDAVfs, FTPfs ? Vous tenez à votre vie ou ? :-)
Plus sérieusement : LUFS comme FUSE agissent comme "proxy", c'est à dire qu'ils ajoutent une entrée pour chaque système de fichiers "virtuels" montés par ces systèmes, et qu'ils transmettent les requêtes que le VFS leur transmet au processus en espace utilisateur qui va bien.
Je pense que le problème fondamental qui devrait empêcher tout administrateur Unix censé d'autoriser ses utilisateurs non privilégiés à monter leurs propres volumes (qu'ils soient virtuels ou physiques) est qu'en aucun cas le VFS n'est fait pour être résistant lors de cas problématiques, comme des "backing store" (le FTP distant, le CDROM, ...) défectueux. Et Dieu sait qu'un CDROM défectueux sait faire planter un système, je vous en file un tout petit qui le fait à coup sur un 2.6.10.
FUSE n'est pas particulièrement résistant face à ce genre de problèmes. Il se veut juste un proxy favorisant la communication entre user space et kernel space pour ces cas particuliers. Et quand bien même il serait étudié pour être plus ou moins résistant, le problème fondamental resterait le même : un VFS centralisé n'est pas adapté à des systèmes de fichiers aussi susceptibles de provoquer des erreurs (error-prone, bordel, pas de jolie traduction en tête).
Le Hurd est conçu autour de cette idée que la sécurité passe par le fait de donner plus de pouvoirs aux utilisateurs. Un noyau de type Unix, avec un VFS centralisé, ne pourra pas fournir ces services que le Hurd fournit.
Concernant le reste de la question, à propos des bibliothèques partagées notamment. Sache d'abord que c'est le cas. Le Hurd est un ensemble de serveurs et de bibliothèques. Une grande partie du code des translators est assuré par netfs/diskfs/trivfs, qui se trouve être une bibliothèque. Mais même en dehors de ça, quand on parle de serveurs, on ne précise pas s'ils seront implémentés comme des processus à part ou comme des bibliothèques. C'est un choix d'implémentation qui dépend des caractéristiques du serveur, des nécessités de performances, et d'autres critères : je prends l'exemple du port du Hurd sur L4, où autant il y a bien un serveur "physmem" ou "task" indépendant, autant l'ensemble du système des "capabilities" - qui détermine toute la sécurité de l'IPC - est assuré par une bibliothèque répliquée dans chaque espace d'adressage. Pour remonter plus loin, Mach OS, un OS qui implémentait un serveur monolithique de compatibilité BSD (UX) par dessus un micro-noyau, Mach, greffait à tous ses espaces d'adressage un certains nombres de choses qui facilitaient grandement la vie de UX - et ses performances.
Les préoccupations du Hurd sont : sécurité, flexibilité, performances. Évidemment, le jeu de la conception est d'effectuer un éternel compromis entre ces trois là, tout en respectant nos priorités. Le choix de bibliothèque ou serveur à part tient compte des trois aspects. Il en va de même lorsqu'il s'agit de décider quels serveurs résideront ou non dans le même espace d'adressage. Il a par exemple été suggéré que 'proc' et 'task', bien qu'implémentés séparément, feraient bien de partager le même espace d'adressage : nul besoin de les réécrire, les IPCs sont alors ce qu'on appelle des LIPC (Local IPC), des communications entre threads d'une même "tâche", ce qui dans L4 ne passe jamais en espace noyau, et équivaut à à peine plus qu'un appel de fonction, en terme de temps. Selon l'expérience, les avis, les discussions, ces choix seront faits. En bref et en résumé, Le Hurd n'exige pas que tout soit séparé autant que possible : il le permet.
L'idée que tu évoques est effectivement l'idée des exonoyaux, ou systèmes d'exploitations "vertically structured" (je trouve le second terme beaucoup plus clair et précis) : c'est le cas de Nemesis que je citais dans un précédent commentaire sur cette même dépêche. C'est réellement un concept intéressant, que beaucoup de développeurs du Hurd apprécient. La question évidemment, c'est : comment assurer la sécurité d'un tel système ? Et les réponses à ça ne sont pas encore très claires. Les exonoyaux en sont là où les micro-noyaux en étaient il y a, disons, 20 ans. Je crois que le Hurd s'en inspire notamment avec le système de "capability" ou avec le gestionnaire de mémoire virtuelle que j'évoquais plus bas - chaque tâche dispose de son implémentation mais peut la changer en volonté -, mais essayer de s'aventurer totalement dans ce domaine serait complètement hasardeux, et inconsidéré. Je considère que le Hurd est déjà arrivé trop tôt, par rapport à la maturation des micro-noyaux : ne refaisons pas la même erreur.-
[^]Re: heeeuu
Posté par Pinaraf (Jabber id, ) le 14/02/2005 à 12:03. (lien). Évalué à 4.Je me permet de rajouter une couche concernant fuse (j'espère que des gens lisent encore cette news).
J'ai essayé de coder un FS utilisant sqlite afin de faire des recherches très rapides, avoir des métadatas... Ça a marché à peu près... Jusqu'au moment où suite à une erreur de ma part le FS a "planté" : arrêt de l'interpréteur python (oui je l'écris en python, y'a des bindings pour fuse). Je corrige le problème, tente de remonter le FS : il dit que c'est monté.
Et c'était _strictement_ impossible de le démonter ! Il a fallu un reboot...-
[^]Re: heeeuu
Posté par Mildred (Jabber id, page perso, ) le 14/02/2005 à 15:07. (lien). Évalué à 0.Moi, je lis encore ...
-
-
-
-
-
[^]Re: heeeuu
Posté par Marc (Jabber id, page perso, ) le 08/02/2005 à 08:47. (lien). Évalué à 4.et LUFS marche en tant que simple utilisateur (sans aucun suid ou autre)? Je doute.
Et si moi, simple utilisateur, je veux utiliser ça, je dois recompiler un module... je pourrais jamais le charger :/ Et si je veux utiliser plusieurs version différentes en même temps? Je peux pas non plus...
Donc même si ça semble être pareil, ça ne l'est pas
-
-
-
-
Erreur de langue
Pour le lien Debian GNU/Hurd : manuel d'installation, la documentation est en français contrairement à ce qu'indique le petit drapeau du lien.
Mea culpa.
-
[^]Re: Erreur de langue
Posté par koxinga () le 05/02/2005 à 21:38. (lien). Évalué à 2.justement, le lien pointe vers la version anglaise, la version française est ici : http://www.debian.org/ports/hurd/hurd-cd.fr.html(...)
-
[^]Re: Erreur de langue
Posté par Manuel Menal (page perso, ) le 05/02/2005 à 22:03. (lien). Évalué à 4.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.
-
Qemu
Depuis peu de temps, Hurd/L4 est bootable.
Si vous voulez l'essayer avec qemu, j'ai fait un petit how-to : http://hurd.gnufans.org/bin/view/Hurd/QemuImageForL4(...)
-
[^]Re: Qemu
Posté par Sebastien Binet () le 05/02/2005 à 17:54. (lien). Évalué à 5.Parfait !!
Vraiment ideal pour s'y mettre en douceur.
Juste une remarque, pour recuperer les sources de hurd-l4, il vaudrait peut-etre rajouter de mettre CVS_RSH = "ssh" (enfin moi ca quand meme grandement aide a rapatrier les sources ;) mais faut dire que j'ai une config un peu exotique au labo)
A quand une iso Debian (GNU/)HurdL4 ?-
[^]Re: Qemu
Posté par Manuel Menal (page perso, ) le 05/02/2005 à 21:03. (lien). Évalué à 4.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 ! :-)
-
Screenshoot
En exclusivité premier sur linuxfr, la premiére capture d'écran de la premiére application qui à tourner sur Hurd/L4, j'ai nommé banner:
http://www.marcus-brinkmann.org/banner.jpg(...)
Ça a planté au début ou quoi? Elle fait quoi cette appli?
-
[^]Re: Screenshoot
Posté par Zakath (page perso, ) le 05/02/2005 à 16:17. (lien). Évalué à 4.Ca sert à faire des jolis dessins en ASCII Art. Et ca n'a pas planté, c'est juste qu'il y a beaucoup de messages de debuggage autour.
-
[^]Re: Screenshoot
-
[^]Re: Screenshoot
Posté par zero heure (Jabber id, page perso, ) le 05/02/2005 à 17:27. (lien). Évalué à 2.Même en tournant la tête j'ai pas compris le dessin. Mais merci quand même, ça m'a fait des exercices, utiles quand on reste trop longtemps devant un écran ;-)
--
J'ai vu bien des choses dans ma petite vie, et je mesure amèrement l'impuissance à les dire. (JP Rosnay, Le 13ème apôtre) http://www.poesie.net/apotre2.htm-
[^]Re: Screenshoot
Posté par Cyril (page perso, ) le 05/02/2005 à 17:59. (lien). Évalué à 3.en faite c'est un point d'exclamation :)
-
[^]Re: Screenshoot
Posté par plagiats (page perso, ) le 05/02/2005 à 19:26. (lien). Évalué à 2.multimédia double face ! ca peut même faire un " i " !!
-
-
-
-
[+] Euh ...
> Les développeurs de Hurd travaillent actuellement au portage de Hurd sur un autre micro-noyau, L4. Celui-ci, plus petit et plus efficace, doit permettre à terme d'améliorer la conception du Hurd et ses performances.
<lol>Cool, et très bonne nouvelle : c'est reparti pour 10 ans et d'ici 20 ans, on pourra espérer que la première carte son sera supportée (ce sera probablement une Sound Blaster 16 ISA</lol>
-
[+] [^]Re: Euh ...
Posté par √λιi () le 05/02/2005 à 17:05. (lien). Évalué à -1.première carte son sera supportée (ce sera probablement une Sound Blaster 16 ISA
Si dans 20 ans j'ai encore un carte son SB16 Isa, je chercherai plus un collectionneur qu'un support sur hurd.-
[^]Re: Euh ...
Posté par L (page perso, ) le 06/02/2005 à 06:43. (lien). Évalué à 10.Et un collectionneur du Hurd ça t'intéresse ? Dans 20 ans, ils seront passé au noyau conceptuellement à la mode et l'actuel sera obsolète, même s'il supporte la carte SB16 ISA :)
Ceci dit, je critique mais ça reste bon enfant : j'ai même installé le Hurd il y a un an ou deux, c'est dire comme, malgré mes médisances, j'espère qu'il sera un jour une bonne alternative à Linux pour voir ce que ces années de développement ont donné. Et je reste persuadé que le jour ou le premier noyau Hurd 1.0 sortira, malgré les trolls/critiques/autres, tout le monde se précipitera pour installer un système d'exploitation à base de Hurd, moi le premier :)
-
combien, combien ??
Petite question, ce n'est pas un troll (et bien sournois celui qui en trouvera un) : ils sont combien à bosser sur le Hurd ? Juste pour avoir une idée, un ordre de grandeur ou une fourchette me va très bien.
-
[^]Re: combien, combien ??
Posté par Larry Cow () le 05/02/2005 à 17:33. (lien). Évalué à 6.Sur le "noyau"? A part les deux de l'article (Neal et Markus), je vois pas.
En tous cas, chapeau bas à ces deux-là, ça redonne un peu d'intérêt à la chose, je trouve. Parce que bosser sur Hurd/Mach tout en sachant pertinemment qu'il faudra peut-être tout reprendre une fois Hurd/L4 fonctionnel, c'est pas très encourageant.
-
[^]Re: combien, combien ??
Posté par zero heure (Jabber id, page perso, ) le 05/02/2005 à 17:45. (lien). Évalué à 10.Il y avait une dépêche le 4 janvier sur une interview de Richard Stallman: http://linuxfr.org/2005/01/04/18002.html(...)
Dans les messages qui ont suivi, il y a cette petite explication de Manuel Menal sur les développeurs: http://linuxfr.org/comments/517713.html#517713(...)
on a un noyau de développeurs d'environ 5 à 10 personnes actives dit-il. Mais ailleurs il précise que les très nombreux développeurs de L4 sont très intéresses par le Hurd.
J'en ai profité pour fouiller alentour dans la page, c'est passionnant:
Message de Manuel Menal sur le port vers L4 et les réactions de Stallman: http://linuxfr.org/comments/517098.html#517098(...)
Suite à une question sur l'intéret de bosser sur le Hurd (M Menal bosse dessus!), réponse de GaGadget: http://linuxfr.org/comments/517373.html#517373(...)
et celle de Manuel Menal, magnifique plaidoyer:
http://linuxfr.org/comments/517501.html#517501(...)
Mais autant lire tout le fil--
J'ai vu bien des choses dans ma petite vie, et je mesure amèrement l'impuissance à les dire. (JP Rosnay, Le 13ème apôtre) http://www.poesie.net/apotre2.htm-
[^]Re: combien, combien ??
Posté par Sebastien Binet () le 05/02/2005 à 17:59. (lien). Évalué à 7.Auto-citation : il y avait aussi ce journal[1] ou mossieur Menal[2] nous gratifiait d'un joli etat des lieux tres clair et a haute teneur pedagogique et informative (j'en fais trop ?)
[1] http://linuxfr.org/~bins/16744.html(...)
[2] http://linuxfr.org/comments/521936.html#521936(...)
PS: c'est fou, c'est un vrai aimant a XP ce mossieur :P-
[^]Re: combien, combien ??
Posté par Will Hunting (page perso, ) le 08/02/2005 à 11:46. (lien). Évalué à 5.PS: c'est fou, c'est un vrai aimant a XP ce mossieur :P
Manuel Menal : parce qu'il les vaut bien !
A mon avis, il pourrait poster des news sur le thème "Windows 3.1 c'est bon, mangez-en" pendant 3 semaines et avoir encore de la marge.
Merci en tout cas à Manuel pour la qualité de ses interventions et aussi à Thomas qui poste pas mal de choses intéressantes en ce moment je trouve.-
[^]Re: combien, combien ??
Posté par Wawet76 (page perso, ) le 08/02/2005 à 23:28. (lien). Évalué à 2.Quel Thomas ?
(surement pas moi, je ne fais que des sales posts bassement consensuels pour me gargariser ensuite avec les notes qu'ils atteingnent)-
[^]Re: combien, combien ??
-
-
-
[^]Re: combien, combien ??
Posté par fmaz fmaz () le 08/02/2005 à 21:35. (lien). Évalué à 8.Moi, je connais sa recette:
- savoir de quoi on parle;
- argumenter;
- écrire proprement et rester respectueux même des ¹~#{'&é qui répondent: le hurd, si c'était bien, ça s'sorait!
Ceci dit, si tout le monde faisait ça, le trafic sur linuxfr serait divisé par beaucoup.
-
-
Compléments
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.
-
[^]Re: Compléments
Posté par Manuel Menal (page perso, ) le 05/02/2005 à 19:14. (lien). Évalué à 10.... 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(...) !-
[^]Re: Compléments
Posté par skeespin (page perso, ) le 05/02/2005 à 19:21. (lien). Évalué à 2.Ca va faire encore plus de boulots pour les admins systèmes ! Merci
Pas d'écran bleu svp ! :op
-
[^]Re: Compléments
Posté par Temsa (Jabber id, page perso, ) le 05/02/2005 à 19:34. (lien). Évalué à 1.Après avoir passé quelques heures a me documenter sur le hurd en janvier (merci, entre autre, hurdfr) et ayant déjà eut ouïe dire que que le portage sur L4 avançait bien et devrait apporter une nouvelle dynamique (ce qui semble bien être le cas) a Hurd, je me suis dit que j'installerais bien une debian hurd sur un petit coin de disque dure, pour voir (et pourquoi pas bidouiller dedans!) :)
-> ça prends combien de place a peu pres?
-> qu'y a-t-il d'a peu près fonctionnel, que l'on peut utiliser tous les jours (j'ai horreur de redemarrer ma machine)?
-> est-ce qu'on peut déjà le faire tourner en 64 bit sur de l'athlon64 ?-
[^]Re: Compléments
Posté par Zakath (page perso, ) le 05/02/2005 à 20:11. (lien). Évalué à 3.Ca ne prend pas des masses de place (les mauvaises langues te diront que ça tenait largement sur 2Go)
Il y a pas mal de trucs fonctionnels (WindowMaker entre autres) mais pas les applis qui ont besoin des threads (dont OOo et plusieurs autres gros trucs)
La plus grande partie du développement se fait pour ia32, même s'il y a des ia64 qui trainent dans les sources. Je ne sais pas du tout où ils en sont...-
[^]Re: Compléments
Posté par Manuel Menal (page perso, ) le 05/02/2005 à 21:00. (lien). Évalué à 10.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 ;-)
-
-
-
live cd
Existe t il ou y a til un projet de live cd pour gnu/hurd (je crois qu'il y a un live cd pour l4linux)?
Ca serait un bon moyen de faire decouvrir ce systeme.
-
[^]Re: live cd
Posté par Larry Cow () le 06/02/2005 à 11:37. (lien). Évalué à 2.Mieux que le Live CD (quoique plus laborieux à mettre en place): il n'y aurait pas, par hasard, une implémentation de L4 tournant sous Linux (comme UML tourne sous Linux ou coLinux sous Windows)?
Parce qu'auquel cas, il y aurait peut-être moyen de faire tourner un Hurd/L4 sur un Linux, avec de bien meilleures performances qu'un QEmu (même si ce dernier est déjà pas mal). Et ça, pour tester/jouer avec, ça serait le panard.
(bon, ok, je me calme et je prends mes pilules)-
[^]Re: live cd
Posté par Manuel Menal (page perso, ) le 06/02/2005 à 15:03. (lien). Évalué à 2.Dans l'autre sens. Comme le disait Matthieu, il existe un projet (en fait, deux) nommé L4Linux, qui consiste à faire tourner Linux sur L4. J'en parlais dans http://linuxfr.org/comments/521936.html#521936(...) ainsi que Frédéric dans http://linuxfr.org/comments/521743.html#521743(...) ;
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 (page perso, ) le 06/02/2005 à 12:09. (lien). Évalué à 3.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.
Le Hurd...
Ah, le Hurd...
Cela doit maintenant faire dix ans que j'ai entendu parler de Linux pour la première fois. Comme le temps passe!
C'est un système que j'adore. Je ne suis pas informaticien, mais j'adore mettre la main dans le cambouis. Avec le temps, j'ai fini par obtenir un système qui n'a plus grand chose à envier à windows (à part les jeux bien sûr). Musique, vidéos, internet... Tout y est. Mon système est une gentoo, configurée aux petits oignons, effilée comme une lame de rasoir (enfin, j'exagère peut être un peu, mais c'est l'image que je m'en fait). Autant dire que j'aime mon système, et que je ne vois vraiment rien qui puisse m'inciter à m'en passer.
A part le hurd, peut être...
Bien sûr, il n'est pas très utilisable pour le moment et, même s'il le devenait, il serait moins rapide que Linux. Et pourtant, je doit bien admettre que le concept même de ce système m'attire énormément, et que tous les avantages qu'il nous promet valent très largement une légère diminution des performances. Surtout avec les processeurs d'aujourd'hui!! Rien que d'imaginer qu'il serait possible de faire tourner sur *ma* machine un système quasiment impossible à crasher, j'en salive d'avance (oui, ça ne m'est pas arrivé depuis un bon bout de temps, mais il m'est arrivé de planter complètement mon Linux).
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. En attendant, je réserverait bien une petite place sur mon disque dur pour m'amuser avec, mais il y a plusieurs points qui me retiennent encore :
- J'ai cru voir dans la doc que le Hurd swappait sur toutes les partitions qu'il ne reconnaissait pas. Est-ce vrai ? Je n'ai pas très envie de le tester pour le voir swapper directement sur mes partitions reiserfs... (si c'est sur ma partition ntfs, je survivrai ;-)
- Le "système d'installation" m'a l'air assez compliqué. D'accord, si j'ai installé une Gentoo depuis le stage 1 je devrais être capable d'installer le Hurd, mais quand même...
- Le support pour l'amd64. L4 le supporte peut être, mais qu'en est-il du reste du système? (Pour tout ce qui est support matériel, carte 3D ou Wifi, ce sera sans doute pour ma prochaine vie...)
- 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 ?
- 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.
Bref, ce ne sont que des détails, mais j'aimerais bien connaître les réponses avant de repartitionner mon disque. Une âme charitable pourrait-elle me répondre ?
La fin du pétrole approche
-
[^]Re: Le Hurd...
Posté par Larry Cow () le 06/02/2005 à 13:40. (lien). Évalué à 3.Bref, ce ne sont que des détails, mais j'aimerais bien connaître les réponses avant de repartitionner mon disque. Une âme charitable pourrait-elle me répondre ?
Grâce à QEmu, tu devrais pouvoir tester le Hurd sans risquer d'abimer ton Linux, non?-
[^]Re: Le Hurd...
Posté par Phibrizo (page perso, ) le 06/02/2005 à 13:59. (lien). Évalué à 1.qemu est masqué sur amd64, du moins pour la version stable. Je sais qu'il est possible de l'installer quand même, mais je préfèrerais booter le Hurd de façon native. De cette façon, si j'ai un problème, je saurais avec certitude qu'il vient du système. Je n'aurais pas à me creuser la tête pour savoir si tel ou tel bug est dû au hurd où à l'émulateur.
Enfin, si je n'obtiens pas de réponse à mes questions, c'est certainement ce que je finirais par faire, mais je pense que le Hurd est déjà suffisament expérimental comme ça, et que ce n'est pas la peine d'en rajouter une couche. Ce serait sans doute suffisant pour booter l'OS, mais j'aimerais quand même aller un peu plus loin.--
La fin du pétrole approche
-
-
[^]Re: Le Hurd...
Posté par Elly (page perso, ) le 06/02/2005 à 15:58. (lien). Évalué à 2.« J'ai cru voir dans la doc que le Hurd swappait sur toutes les partitions qu'il ne reconnaissait pas. Est-ce vrai ? »
Euh, oui, mais non. Il swappera sur n'importe quel type de partition, mais seulement sur celles sur lesquelles tu lui demandes de swapper... donc il *peut* démolir ta partition reiserfs si tu lui demandes de swapper dessus, mais il va pas faire le sociopathe et dire "bon, y'a deux partitions ext2fs, le reste je sais pas ce que c'est, bon ben c'est cool ça me fera 40GO de swap" :)
Faut juste vérifier que tu lui passes bien la partition de swap, quoi.
«Le "système d'installation" m'a l'air assez compliqué.»
Si tu suis le guide (l'url a été passé avant il me semble, vais pas la remetter :p), c'est assez simple en fait. Par contre c'est pénible quand t'as du matériel qui est pas supporté :/
«Le support pour l'amd64. L4 le supporte peut être, mais qu'en est-il du reste du système?»
Euh, pour l'instant, le Hurd (enfin, la version utilisable) tourne encore sous Mach, et c'est (il me semble) limité au 32 bits actuellement.
«Puisque l'on parle de support, le Hurd pourra t-il faire tourner directement les binaires Linux»
Actuellement, non. Un jour, oui, peut-être, ça doit être faisable, mais c'est absolument pas une priorité vu qu'il suffit de recompiler les programmes...-
[^]Re: Le Hurd...
Posté par Manuel Menal (page perso, ) le 06/02/2005 à 18:28. (lien). Évalué à 5.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.
-
-
[^]Re: Le Hurd...
Posté par Bertrand Jacquin (Jabber id, page perso, ) le 06/02/2005 à 22:25. (lien). Évalué à 1.Il y a un projet Non officiel de version de portage pour Hurd, je n'ai pas testé, mais je crois que je vais le faire quand j'aurais un peu de temps.
http://hurd.rustedhalo.net/about.php
Que m'apporte le hurd ?
Qu'apporte le hurd à un utilisateur de linux (et surtout de KDE ;)
J'ai vu des supers features comme les translators (c'est bien le nom pour les trucs qui font des systèmes de fichiers virtuels à peu près ?) : ça a l'air génial dites donc... Mais pour les non-geek ça fait quoi ? (Moi ça m'intéresse pas mal surtout celui pour les fichiers xml :)
Qu'y a-t-il d'autre qui pourrait s'avérer intéressant pour un utilisateur de base ? et pour un réseau ?
Merci d'avance !
(Surtout, n'y voyez pas de troll... Je m'informe, je testerai peut être si j'ai le temps)
-
[^]Re: Que m'apporte le hurd ?
Posté par Manuel Menal (page perso, ) le 06/02/2005 à 20:15. (lien). Évalué à 6.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.)-
[^]Re: Que m'apporte le hurd ?
Posté par Pinaraf (Jabber id, ) le 06/02/2005 à 20:23. (lien). Évalué à 3.Simple question (peut être indiscrète) : quel est ton rôle pour hurd ? T'es développeur ? Parce que t'as l'air d'en savoir un rayon sur lui !
-
[^]Re: Que m'apporte le hurd ?
Posté par Manuel Menal (page perso, ) le 06/02/2005 à 20:30. (lien). Évalué à 6.Ç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 ;-)
-
-
[^]Re: Que m'apporte le hurd ?
Posté par TeXitoi (Jabber id, page perso, ) le 06/02/2005 à 20:38. (lien). Évalué à 2.il permet de nouvelles fonctionnalités, plus de sécurité, plus de fiabilité, plus de stabilité, et plus de performances.
Pour le reste, je veux bien, mais pour le plus de performance, j'ai du mal : le fait que ce soit un micro noyau ne force pas hurd à avoir un handicap niveau performance à cause du prix à payer pour avoir la modularité?-
[^]Re: Que m'apporte le hurd ?
Posté par Manuel Menal (page perso, ) le 06/02/2005 à 22:08. (lien). Évalué à 10.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,
-
-
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.