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.
Aller plus loin
- KernelTrap : K8 Debian CDs Available (2 clics)
- ISOs K8 (1 clic)
- Debian GNU/Hurd : Manuel d'installation (13 clics)
- Portage de Hurd sur L4 (10 clics)
- KernelTrap : L4 Port Gets Inital Memory Management Framework Including Self-Paging Tasks (3 clics)
- KernelTrap : First Phase of L4 Port Completed (3 clics)
# warning : troll inside
Posté par Benjamin (site web personnel) . Évalué à -1.
une petite estimation du jour où je pourrais faire tourner kde + oOo.org dessus ?
(...)
[^] # Re: warning : troll inside
Posté par Pierre Tramo (site web personnel) . Évalué à -2.
[^] # Re: warning : troll inside
Posté par LLG . Évalué à -2.
Dans pile deux mois après banner!
[^] # sécurité des serveurs
Posté par free2.org . Évalué à 9.
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 . Évalué à 4.
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 . É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 ;-)
[^] # L4 pour applications simples sécurisées indépendantes d'une couche POSIX
Posté par free2.org . Évalué à 3.
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 Prosper . Évalué à 2.
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 . Évalué à 3.
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 . Évalué à 4.
[^] # solution actuelle pour OO.org et applis complexes: L4 Linux realtime
Posté par free2.org . Évalué à 4.
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
Posté par CoinKoin . Évalué à 9.
[^] # Re: Un mot
Posté par Veiovis . Évalué à 0.
# heeeuu
Posté par Pierre Tramo (site web personnel) . Évalué à -9.
mouahahahaha
</ commenaire constructif >
[^] # Re: heeeuu
Posté par bmc . Évalué à 10.
[^] # Re: heeeuu
Posté par Veiovis . Évalué à 4.
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 . É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: heeeuu
Posté par Veiovis . Évalué à -10.
:-) 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 . Évalué à -5.
[^] # Re: heeeuu
Posté par Manuel Menal . É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: heeeuu
Posté par gallenza . Évalué à 0.
[^] # Re: heeeuu
Posté par chl (site web personnel) . Évalué à 2.
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 . Évalué à 3.
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 . Évalué à 6.
- ç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 . Évalué à 10.
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 . Évalué à 4.
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 (site web personnel) . Évalué à 0.
[^] # Re: heeeuu
Posté par Marc (site web personnel) . Évalué à 4.
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
Posté par Thomas Petazzoni (site web personnel) . Évalué à 4.
Mea culpa.
[^] # Re: Erreur de langue
Posté par koxinga . Évalué à 2.
[^] # Re: Erreur de langue
Posté par Manuel Menal . Évalué à 4.
# Qemu
Posté par Zakath (site web personnel) . Évalué à 10.
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 . Évalué à 5.
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 . Évalué à 4.
# Screenshoot
Posté par LLG . Évalué à 1.
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 (site web personnel) . Évalué à 4.
[^] # Re: Screenshoot
Posté par dab . Évalué à 2.
[^] # Re: Screenshoot
Posté par ZeroHeure (site web personnel) . Évalué à 2.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Screenshoot
Posté par Cyril . Évalué à 3.
[^] # Re: Screenshoot
Posté par plagiats . Évalué à 2.
[^] # Re: Screenshoot
Posté par ramzez . Évalué à -1.
# Commentaire supprimé
Posté par Anonyme . Évalué à -8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Euh ...
Posté par Anonyme . Évalué à -1.
Si dans 20 ans j'ai encore un carte son SB16 Isa, je chercherai plus un collectionneur qu'un support sur hurd.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
# Hurd
Posté par fabb . Évalué à 9.
Mais autant de commentaires pour critiquer gratuitement HURD/L4 est navrant.
# combien, combien ??
Posté par Aurélien Bompard (site web personnel) . Évalué à 7.
[^] # Re: combien, combien ??
Posté par Larry Cow . Évalué à 6.
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 ZeroHeure (site web personnel) . Évalué à 10.
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
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: combien, combien ??
Posté par Sebastien Binet . Évalué à 7.
[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 WH (site web personnel) . Évalué à 5.
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 (site web personnel) . Évalué à 2.
(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 ??
Posté par tgl . Évalué à 4.
Un indice s'est glissé dans l'entête de cette niouze, sauras tu le retrouver ? :)
[^] # Re: combien, combien ??
Posté par fmaz fmaz . Évalué à 8.
- 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
Posté par Manuel Menal . É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: Compléments
Posté par Manuel Menal . É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(...) !
[^] # Re: Compléments
Posté par skeespin (site web personnel) . Évalué à 2.
Pas d'écran bleu svp ! :op
[^] # Re: Compléments
Posté par Temsa (site web personnel) . Évalué à 1.
-> ç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 (site web personnel) . Évalué à 3.
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 . É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 gallenza . Évalué à 1.
[^] # Re: Compléments
Posté par mdlh . Évalué à 5.
EPIC est un concept, IA64 est une architecture, Itanium et Itanium 2 sont deux implementations differentes de l'architecture IA64.
Je precise parce que sinon ta phrase peut porter a confusion
# live cd
Posté par M . Évalué à 2.
Ca serait un bon moyen de faire decouvrir ce systeme.
[^] # Re: live cd
Posté par Larry Cow . Évalué à 2.
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 . É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 . Évalué à 3.
# Le Hurd...
Posté par Phibrizo (site web personnel) . Évalué à 6.
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 ?
[^] # Re: Le Hurd...
Posté par Larry Cow . Évalué à 3.
Grâce à QEmu, tu devrais pouvoir tester le Hurd sans risquer d'abimer ton Linux, non?
[^] # Re: Le Hurd...
Posté par Phibrizo (site web personnel) . Évalué à 1.
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.
[^] # Re: Le Hurd...
Posté par Elly . Évalué à 2.
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 . É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: Le Hurd...
Posté par Bertrand Jacquin (site web personnel) . Évalué à 1.
http://hurd.rustedhalo.net/about.php
# Que m'apporte le hurd ?
Posté par Pinaraf . Évalué à 2.
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 . É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: Que m'apporte le hurd ?
Posté par Pinaraf . Évalué à 3.
[^] # Re: Que m'apporte le hurd ?
Posté par Manuel Menal . Évalué à 6.
Enfin, tout ça n'a peu d'intérêt dans une news DLFP ;-)
[^] # Re: Que m'apporte le hurd ?
Posté par Amaury . Évalué à -1.
On va essayer de se montrer un peu plus ouvert que ces connards de HurdFR ;-)
[^] # Re: Que m'apporte le hurd ?
Posté par TeXitoi (site web personnel) . Évalué à 2.
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 . É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 Mildred (site web personnel) . Évalué à 2.
je crois avoir lu qu'il vaut mieux mettre plein de swap pour éviter ce problème justement ...
[^] # Re: Que m'apporte le hurd ?
Posté par Pinaraf . Évalué à 3.
[^] # Re: Que m'apporte le hurd ?
Posté par Manuel Menal . Évalué à 3.
# Question bete!
Posté par stryge . Évalué à 4.
[^] # Re: Question bete!
Posté par Manuel Menal . Évalué à 4.
# Boutarde
Posté par Croweye . Évalué à 8.
de http://krunch.servebeer.com/~krunch/fortunes/computers
It is commonly acknoledged that when the HURD reaches 1.0 it will be
an artificially intelligent system that improves itself and will
spontaniously take over all the computers in the world
However it is also commonly acknoledged that when the HURD reaches 1.0
the sun will reach critical mass and go Nova, so we'll only have to
worry about the HURD dominating us for about 7 minutes
-- Drakon in a Slashdot comment
(CID#9903024 SID#117055)
[^] # Re: Boutarde
Posté par Miair Patreau . Évalué à -3.
Bref, c'est pas si rassurant.
# RoadMap ?
Posté par Sebastien Binet . Évalué à 3.
Pas necessairement un truc avec des dates ecrites dans le marbre, mais plus quelque chose comme une table temporelle avec les fonctionnalites prevues d'etre implementees.
D'ailleurs, je cherchais cette roadmap quand je suis tombe la-dessus[1,2] : les cours de l'universite de Karlsruhe sur les OS (et plus si affinites). Enjoy :)
[1] http://i30www.ira.uka.de/teaching/courses/index.php?lid=en(...)
[2] http://i30www.ira.uka.de/teaching/coursedocuments/100/week12.pdf(...)
[^] # Re: RoadMap ?
Posté par Sebastien Binet . Évalué à 4.
http://savannah.gnu.org/cgi-bin/viewcvs/hurd/hurd-l4/TODO#dirlist(...)
[^] # Re: RoadMap ?
Posté par Matthieu Lemerre (site web personnel) . Évalué à 4.
Il n'y a pas de roadmap ecrite precise, mais je pense que la liste precise des choses a faire est dans la tete de Marcus Brinkmann et de Neal Walfield.
La liste des choses a faire est assez longue, parmis elles se trouvent la conception du device driver framework, qui sont des drivers en user space independants du Hurd (pouvant etre utilises par n'importe quelle application tournant sur L4), l'ecriture d'un IDL pour faciliter le developpement des serveurs (ou la modification d'IDL4), completer les serveurs de bases (physmem, task et deva).
Au fur et a mesure la glibc pourra etre completee, et enfin le portage des premiers serveurs du Hurd sur Mach pourra commencer.
http://l-lang.org/ - Conception du langage L
# Et pour un petit lien de plus
Posté par Sebastien Binet . Évalué à 7.
Sans grande pretention, mais plutot informatif.
[1] http://portal.wikinerds.org/gnu-hurd-l4-first-program(...)
# Hurd c'est nul
Posté par blahhblahh . Évalué à -9.
Voila c'est tout...
[^] # Re: Hurd c'est nul
Posté par WH (site web personnel) . Évalué à 3.
# Question technique :
Posté par Calim' Héros (site web personnel) . Évalué à 3.
Je vois bien la difference entre GNU/Linux et GNU/Hurd : c'est pas le même noyau (Linux pour le premier, Hurd pour le deuxieme et de meme on pourrait faire GNU/openSolaris ou GNU/Darwin ) mais la difference entre Mach et L4 moi je m'y perd parce que si c'est Hurd le noyau c'est qui ces deux la?. C'est un noyau de noyau parce qu'on parle bien de Hurd/Mach et Hurd/L4 ou alors c'est juste parce que Hurd c'est le nom générique du noyau du projet GNU et Mach et L4 sont les noms des noyaus sur lesquel il repose et que si par exemple Linux devenait le noyau du projet GNU ca serait Hurd/Linux.
Bon, je sais ca doit etre marqué dans une faq toussa toussa mais la je vient de lire tout le thread et j'ai moyen le courrage de chercher.
Donc si vous avez envie de me venir en aide merci, sinon je verais ca plus tard.
[^] # Re: Question technique :
Posté par Victor STINNER (site web personnel) . Évalué à 4.
Gnumach : vieux micro-noyau qui pue du cul (architecture des années 70)
L4 : micro-noyau nouvelle génération
L4 est mieux car limite les copies inutiles (disons que ça va plus vite qu'avec Gnumach), permet d'avoir des pilotes dans l'espace utilisateur, etc.
Pour info, Gnumach est encore maintenu. J'ai vu récement une mise à jour pour des cartes réseaux. En même temps, L4 est inutilisable pour l'instant (on vient à peine d'incorporer le support de la mémoire virtuelle :-P).
Tu peux donc avoir un Hurd qui tourne sur Gnumach ou un Hurd qui tourne sur L4.
@+ Haypo
[^] # Re: Question technique :
Posté par Calim' Héros (site web personnel) . Évalué à 3.
donc en fait le "noyau" (je parle en noyau equivalant Linux) c'est Hurd + un des deux autre i.e. serveurs+nicronoyau. Voila, j'ai bon?
(sinon pour les diff de perf tout ca c'est bon, je pense avoir suivi ce qu'il y a comme diff entre L4 et Mach dans le thread)
[^] # Re: Question technique :
Posté par Victor STINNER (site web personnel) . Évalué à 4.
Justement, les développeurs de Hurd tentent d'extraire un maximum de choses de l'espace noyau (dans la langue Linuxienne) pour le mettre dans l'espace utilisateur. En français, ça veut dire que quand ton "serveur" NFS plante, tu peux le tuer sans problème ("démonter" le serveur, si tu préfères). Rien à voir avec Linux où lorsqu'une partie du noyau (noyau dur ou module, car en définitive, ça revient au même) plante, il faut rebooter.
L'intérêt est que chaque partie est indépendente de l'autre (souvenirs souvenirs : pas comme sous Windows 98 ou lorsqu'un programme faisait n'importe quoi, tout l'OS plantait). Tu peux aussi contrôler très finement les droits : la gestion des droits est beaucoup plus poussée sous Hurd, un processus peut être lancé sans aucun droit (et non pas avec l'utilisateur "nobody" :-)). Et bien sûr, plus un "serveur" est petit, plus il est facile de le maintenir et de vérifier son code.
Voilà voilà. Haypo
[^] # Re: Question technique :
Posté par Calim' Héros (site web personnel) . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.