Depuis, il n'a pas chômé car il vient de rajouter la pièce manquante à `physmem' : la copie logique de mémoire physique (copy-on-write et mémoire partagée). Comme ce sont les applications elles-mêmes qui s'occupent de la gestion de leur mémoire virtuelle (décider quelles parties vont en 'swap' et où), il a également amélioré la bibliothèque de gestion de mémoire par défaut, `libhurd-mm' pour permettre aux applications de spécifier de façon simple quelles parties doivent aller dans tel forme de swap (partitions de swap, réseau, mémoire externe dédiée, ...).
Ces avancées concluent le travail initial sur la gestion de la mémoire. Cela permet d'envisager le développement de pilotes de périphériques, qui utilisent intensivement la copie de mémoire : dans un premier temps, un pilote IDE d'un autre système pourrait être porté pour permettre d'avoir un système de fichiers, et dans un second il faudra se concentrer sur Fabrica, le framework de pilotes de périphérique.
Par ailleurs, la version K9 des CDs de Debian GNU/Hurd vient de sortir. Au programme, principalement des paquets mis à jour et quelques bugs embêtants corrigés (une résolution de noms défectueuse dans certains cas, par exemple). Debian GNU/Hurd remplit maintenant 9 CDs, mais seules les quatre premières ISOs sont proposées au téléchargement. Une image DVD sera disponible prochainement.
Toujours sur le front Debian GNU/Hurd, Michael Banck a réussi à faire fonctionner Gnome presque entièrement, témoignant du grand travail mené par l'équipe de Debian GNU/Hurd ces derniers temps.
NdM : Merci à Sebastien Binet d'avoir également proposé une dépêche sur le sujet. Pour rappel, L4 est un micro-noyau de "nouvelle" génération sur lequel le Hurd est en train d'être porté. L4 est plus léger et plus performant que son prédécesseur GNU Mach (dont les origines remontent aux années 1980), mais est vraiment minimal : il délègue tout ce qui est gestion à l'espace utilisateur (mémoire virtuelle, toute la partie "décisionnelle" de l'ordonnanceur, communications entre processus) et ne conserve que les mécanismes de base (map/unmap, création de tâches/threads, changement du thread en cours d'exécution). Le pilote IDE qui se charge de votre disque secondaire a planté ? Pas grave, il suffit de le relancer dans la plupart des cas.
L4 (dont le Hurd utilise l'implémentation Pistachio) promet de meilleures performances que GNU Mach, car il réduit considérablement les coûts liés à la communication entre processus et le nombre de copies nécessaire dans l'envoi de message (en rendant les communications nécessairement synchrones).
Le « Copy-on-Write » (CoW) est une fonctionnalité qui permet de partager des pages entre deux processus (par exemple lors d'un fork(2) ou d'un envoi de message sous Mach) sans pour autant les copier physiquement (on parle de copie logique). C'est seulement lors de la première écriture que la page est physiquement dupliquée. Ceci permet d'améliorer les performances (on évite souvent des copies) et d'économiser la mémoire.
L'originalité de la gestion de la mémoire du Hurd sur L4 est que les tâches sont auto-paginées, c'est à dire que ce sont elles-mêmes qui gèrent leur mémoire. Elles se voient attribuées un quantum initial de mémoire physique (renégociable par la suite) qu'elles peuvent gérer comme bon leur semble, ce qui permet aux applications ayant des besoins spécifiques comme les SGDB ou les applications multimédia de gagner beaucoup en performances. Les applications POSIX qui n'exploitent pas ce mécanisme utiliseront `libhurd-mm', ce qui rend le port transparent.
Enfin, vous pouvez télécharger la version K9 des CDs de Debian GNU/Hurd sur les miroirs suivants :
- GNUAB (miroir principal, Espagne, FTP actif seulement)
- HurdFR (France)
- Un autre miroir français
- Un autre miroir espagnol
Aller plus loin
- KernelTrap : Next Stage of Hurd/L4 VMM Framework Completed (1 clic)
- KernelTrap : Device Driver Framework (0 clic)
- Journal LinuxFR sur le sujet (3 clics)
- DLFP : Interview de Marcus Brinkmann (4 clics)
- HurdFR (3 clics)
- L4Ka (2 clics)
# La montre qui fait tout mais ne donne pas l'heure
Posté par un_brice (site web personnel) . Évalué à -5.
Question de priorité je suppose -_^.
Au passage, vous avez déjà réussi à faire planter le pilote IDE vous ?
[^] # Re: La montre qui fait tout mais ne donne pas l'heure
Posté par Manuel Menal . Évalué à 10.
Et oui, un pilote IDE, ça tombe. En fait, ça m'est arrivé y a encore quelques semaines, et c'est arrivé à une assoce de mon entourage aussi. Lorsqu'une machine dispose de pas mal de disques, et que le disque qui s'occupe d'une partition de données pas vitale au système (celle qui contient le pr0^W^Wles vieux logs) crashe, tu aimerais fortement qu'il n'y ait pas d'interruption totale de service. Or il est extrêmement rare que ton noyau résiste à ça : soit tu te prends des Oops et une machine qui lagge tellement qu'elle est inutilisable (cas le plus rare dans mon expérience), soit la machine panic()e vite. C'est quelque chose de très désagréable sous GNU/Linux (vécu sous NetBSD aussi).
Et pour les autres types de pilotes, c'est encore plus courant. Disons, au hasard : les pilotes complètement instables non officiels ou fournis par votre constructeur mais pas intégrés à Linux. Je me souviens par exemple d'un portable où le noyau panic() ait dès qu'on utilisait en même temps le modem et le son. J'aurais apprécié perdre soit la connexion, soit le son, mais pas devoir attendre le reboot à -chaque- fois. Je pense pas que ce soit un avantage si négligeable, donc, en particulier en production.
[^] # Re: La montre qui fait tout mais ne donne pas l'heure
Posté par un_brice (site web personnel) . Évalué à 4.
Reconnaît qu'entendre parler d'un OS dont la branche actuelle envisage le support de l'IDE peut faire sourire, même si ça ne reflète pas forcément le travail qui est accomplit.
[^] # Re: La montre qui fait tout mais ne donne pas l'heure
Posté par Manuel Menal . Évalué à 7.
Il y a en plus une branche expérimentale qui consiste à porter le Hurd sur un nouveau micro-noyau, qui est dans un module à part ('hurd-l4') et qui en est au début de son développement. Si demain MacOS X décide de remplacer xnu (leur Mach++) par autre chose, il faudra sans aucun doute réécrire une grande partie de leur système de pilotes de périphériques, IOKit. Donc quand ils auront fini d'écrire leur noyau, ils penseront au support IDE. Et pourtant, je pense que ça te fera moins sourire.
Donc, c'est de l'humour gratuit uniquement lié au Hurd et à ce qu'il t'évoque, pas à son état... sois en conscient, au moins :-P
Note que je joue pas le rôle du censeur, je supporte même l'humour. Mais je tiens à remettre au clair ce que ce genre d'ironie laisse souvent penser aux lecteurs. Je me ramasse trop souvent l'ironie de gens qui ont entendu et répètent ce genre de blagues, en la prenant pour argent comptant. (Ah oui, et au fait, j'avais compris que c'était de l'humour, sinon j'aurai pas mis de smiley dès la première phrase. J'aurai peut-être dû être plus explicite, moi aussi).
(Sinon, tu me files le fauve quand ? Tu as une cage pour le transporter ? :-P)
[^] # Re: La montre qui fait tout mais ne donne pas l'heure
Posté par bmc . Évalué à 1.
PS : j'ai à nouveau changé d'avis concernant une certaine question très à la mode actuellement ;)
[^] # Re: La montre qui fait tout mais ne donne pas l'heure
Posté par briaeros007 . Évalué à 3.
J'ai deja eu des "resets" sur mes disques secondaires; dont certains entrainaient un gel de tout le systeme (depuis j'ai change le dd :-D)
donc oui, meme si c'est pas forcement le pilote ide en soi qui se chie dessus, pouvoir faire un kill -hup dessus serait sympas ;)
[^] # Re: La montre qui fait tout mais ne donne pas l'heure
Posté par un_brice (site web personnel) . Évalué à 0.
[^] # Re: La montre qui fait tout mais ne donne pas l'heure
Posté par briaeros007 . Évalué à 2.
et il faisait des resets du disque ; le hic c'est que quelquefois lors du reset ; il geller le systeme. Recharger le pilote aurait peut etre servis a rien ; mais si ca travaillait en user space j'aurais pu essayer de le desactiver sans pour autant avoir rebooter (a moins que j'ai absolument rien compris a l'interet des translators)
# Avancement futur?
Posté par arnaudus . Évalué à 5.
[^] # Re: Avancement futur?
Posté par chl (site web personnel) . Évalué à 3.
* Debian GNU/Hurd c'est a dire Hurd sur Mach qui est deja fonctionnel (cf la remarque sur Gnome, et les 9 CD)
* Hurd sur L4 qui est encore en plein developpement.
Le premier fonctionne deja. Je ne connais pas le support du winmodem, ni pour l'ACPI, a toi d'essayer. Le second en est encore loin mais ca avance bien, dixit la news.
[^] # Re: Avancement futur?
Posté par arnaudus . Évalué à 1.
Je sais bien que la news ne concerne pas ce problème, mais si les dev du Hurd veulent que les gens s'intéressent à ce qu'ils font, il faudrait peut-etre mieux expliquer où ils en sont et où ils vont. Parce que si c'est pour avoir un linux qui marche moins bien, plus difficile à paramétrer, moins bien supporté par les machines existantes, ça existe déja, ça s'appelle Debian. toute ressemblance avec un troll existant ou ayant existé ne serait que pure coïncidence. Please do not feed the troll.
Quelles que soient les qualités intrinsèques d'un logiciel, tout passe par la com. Il n'y a qu'a voir Firefox. Si Hurd ça marche pas (pardon, ça marche "presque") et que la com se résume à "Ah oui GNU/Hurd ça marche presque mais on va tenter de faire un Hurd/L4 qui ne marche pas encore", il va falloir attendre 2040 pour voir plus de trois ou quatre barbus s'intéresser au projet...
[^] # Re: Avancement futur?
Posté par MsK` . Évalué à 8.
- drivers courants : hein ?! un clavier, une souris, un disque dur, un écran, ben oui tout ca fonctionne ...
- accélération 3D : non. Heu quoique ... enfin pour tout ce qui est driver de carte graphique, tous les drivers fournis avec X marchent, ca comprend l'accélération ?
- USB : non
- gnome et pas kde ? : ben parce qu'il faut modifier le code pour que ca marche et ils ont pas du bosser sur KDE et plutot sur gnome ( GNU toussa )
[^] # Re: Avancement futur?
Posté par Zakath (site web personnel) . Évalué à 8.
Malheureusement, un grand nombre de cartes réseaux (notamment les e1000) ne possèdent pas de drivers. Et il me semble qu'il s'agit d'un matériel courant et vital, de nos jours.
Pour le DRI, je ne crois pas qu'il fonctionne non plus.
[^] # Re: Avancement futur?
Posté par Manuel Menal . Évalué à 5.
de4x5 de425 de434 de435 de450 de500 eexpresspro100 epic100 hp100 ne2kpci pcnet32 rtl8139 rtl8129 viarhine sis900 elcp tulip yellowfin starfire sundance winbond-840 hamachi intel-gige natsemi myson803 ns820 ac3200 ul32 at1700 ul epic wd80x3 3c503 el2 hplan hplanplus seeq8005 e2100 ne2000 ne1000 at1500 ne2100 fmv18x eth16i eth32 el3 3c509 3c579 vortex 3c59x 3c90x 3c515 znet znote eexpress eexpresspro depca de100 de101 de200 de201 de202 de210 de422 ewrk3 de203 de204 de205 apricot el1 3c501 wavelan el16 3c507 elplus 3c505 de600 de620 skg16 ni52 ni65 lance tlan
Ca en fait deja quelques uns. Si je ne m'abuse, e1000 est le nouveau driver qui remplace intel-gige, donc certaines cartes devraient etre supportees par ce dernier - meme si ce n'est pas le cas de toutes.
[^] # Re: Avancement futur?
Posté par mbanck . Évalué à 3.
Il y a un backport du pilote e1000 à 2.2, mais c'est tout. J'ai essayer de le faire marcher sur GNU Mach 1.x pedant paques, mais comme je ne sais pas trop sur les pilotes, j'ai pas reussi.
Peut-être si qn fait oskit-mach marcher encore, c'est plus facile de les utiliser... Moi, j'en ai un e1000 dans mon ThinkPad aussi :(
Michael
[^] # Re: Avancement futur?
Posté par xsnipe . Évalué à 3.
[^] # Re: Avancement futur?
Posté par Manuel Menal . Évalué à 10.
XFree86 marche, sinon tu n'aurais pas Gnome. Pour le support materiel, tu trouveras la plupart des informations dans le lien donne dans la FAQ (question 3.3). Les drivers "courants", ca peut vouloir dire tout et n'importe quoi, comme tu dis. Il n'y a pas d'acceleration 3D, parce qu'elle depend du DRI, et que GNU Mach ne le supporte pas. Pas de support de l'USB, du PCMCIA, de l'ACPI : je l'expliquais juste avant, ca n'est clairement pas une priorite puisqu'il s'agit de travail a faire sur GNU Mach, et que le but est de passer a L4. Gnome marche parce que Michael a pris le temps de faire des patchs pour Gnome, et pas encore pour KDE. Chacun porte en premier ce qu'il utilise lui-meme, evidemment. Mais Michael termine son mail par : "I hope KDE are packages are done when I'm back ;)" : j'attends vos patchs. :-P
Quant au reste, c'est du troll sans interet. GNU/Hurd est un systeme pour l'instant experimental. Il n'est pas stable, il n'est pas aussi rapide que GNU/Linux, il n'a pas le meme support materiel, simplement parce qu'il n'en est pas encore au stade ou ce sont les priorites du moment. Si tu peux sortir de ton attitude hautaine et venir pour faire de la comm' ou pour combler les lacunes qui t'importent, tu seras le bienvenu.
[^] # Re: Avancement futur?
Posté par arnaudus . Évalué à 5.
J'ai le plus profond respect pour les dev du Hurd, qui bossent depuis des années décennies sur un projet donc beaucoup de gens se moquent, et dont le reste, à peu de choses près, pensent qu'il est peu utile (je ne peux pas dire, je ne devais pas être né à l'époque :-) ). C'est formidable et c'est comme ça que démarrent les grands projets, je pense que ceux qui se sont acharnés pourront être fiers d'eux quand on installera un Hurd comme ça, hop, comme une Ubuntu ajourd'hui.
Je fais partie de ces gens qui râlent tout le temps parce que "rien ne marche". Parce qu'il a fallu attendre des années avant que mon ventilateur arrête de faire un bruit de turbine quand mon cpu ne tourne pas, parce que je me connecte à la toile par un superbe modem 28.8 parce que je n'ai jamais réussi à configurer le winmodem de mon portable.
Je sais bien que c'est la faute à personne, et surtout pas aux dev des noyaux. Maintenant, je pense qu'encourager notre entourage personnel et professionnel à utiliser des logiciels libres, c'est aussi très important. Ce que j'essayais de dire, c'est que ça doit être pénible pour vous d'entendre à longueur de journée des petits cons râler ("gna gna ça marche pas", "gna gna mon modem il marche mieux sous Windows"), mais il faut comprendre aussi que dans l'autre sens, la communication n'est pas meilleure. Disons que les périphériques "supportés dans la dernière version du noyau", c'est pas souvent qu'ils fonctionnent. Et, bon, Gnome qui marche sauf gconfd et nautilus, c'est quand même un peu... rigolo.
Dire que Hurd est un jouet pour geek, comme d'ailleurs Linux l'a été pendant longtemps (même si cette réputation est un peu... collante), ce n'est pas vraiment péjoratif. Mais au moins, c'est clair, et par mon histoire de "planning", j'entendais un moyen de savoir dans combien d'années on pouvait s'attendre à avoir un serveur, un PC de bureau ou un laptop qui tourne correctement sous Debian/Hurd. L'"utilisateur" n'est pas un fauve bête et méchant qui mord tout ce qu'il trouve, c'est simplement un être humain qui s'en fout un peu de l'algorithme qui gère le mappage de la mémoire phyisque, du moment que ça marche. Si ça marche pas, c'est pas grave, il restera sous Linux jusqu'à temps que ça marche. Mais lui dire "t'as qu'à lire les mailing list" ou "t'as qu'à essayer, on va bien se marrer", c'est arroser d'essence l'étincelle naissante de la discorde sur le frêle fêtu de paille de la communauté du logiciel libre, ballotté par le souffle tempétueux des Dieux monopolistiques.
[^] # Re: Avancement futur?
Posté par Thomas Douillard . Évalué à 5.
[^] # Re: Avancement futur?
Posté par Manuel Menal . Évalué à 5.
Note que gconfd marche, il faut juste le lancer à la main. Nautilus segfaulte parfois, mais sur le screenshot, tu as un gconfd qui tourne (sinon t'aurais pas grand chose) et un nautilus.
Quant au planning prévisionnel, je t'ai déjà répondu : il est extrêmement difficile de faire des prévisions à long terme, sur des effectifs réduits et changeants. Et comme ces prévisions sont toujours fausses, je m'en garderai bien. Effectivement, pour l'instant, le port du Hurd sur L4 n'intéresse que les gens qui s'intéressent à savoir comment est gérée la mémoire physique - et note que ça concerne directement l'utilisateur final - notamment l'administrateur système qui, à défaut que l'application ait développé le sien, pourra choisir son gestionnaire de mémoire le plus adapté pour son application.
Et je n'ai jamais dit "t'as qu'à lire les mailing lists" : j'ai dit que les détails des problèmes restants n'étaient intéressants que pour ceux qui souhaitaient s'en charger, et ceux là vont sans aucun doute consulter les mailing lists et s'y abonner (en tous cas, ils le devraient).
[^] # Re: Avancement futur?
Posté par mbanck . Évalué à 4.
Il faut lancer gconfd à la main si on veut démarrer mozilla (je ne sais pas pourquoi), mais bon - mozilla ne fonctionne pas du tout (epiphany marche).
Michael
[^] # Re: Avancement futur? + perfs ?
Posté par Jean Parpaillon (site web personnel) . Évalué à 1.
Je me trompe ?
Sinon, il semblerait que les perfs soient un réel problème avec les micro-noyaux en général. J'imagine que ça dépend du type applications. Qu'en est-il de L4 ?
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
[^] # Re: Avancement futur? + perfs ?
Posté par chl (site web personnel) . Évalué à 2.
Relis le post :) :
L4 (dont le Hurd utilise l'implémentation Pistachio) promet de meilleures performances que GNU Mach, car il réduit considérablement les coûts liés à la communication entre processus et le nombre de copies nécessaire dans l'envoi de message (en rendant les communications nécessairement synchrones).
[^] # Re: Avancement futur? + perfs ?
Posté par Jean Parpaillon (site web personnel) . Évalué à 2.
J'ouïs bien :)
Le post dis que c'est plus rapide... Quelqu'un a-t-il des idées du type d'application qui profitent vraiment de L4, celles qui s'en foutent (j'imagine qu'un calcul qui sort même pas du cache ne vois pas la différence...) et celles qui pâtissent vraiment de l'architecture micro-noyau.
Un peu plus de détails, quoi !
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
[^] # Re: Avancement futur? + perfs ? 4%
Posté par free2.org . Évalué à 4.
Compared to monolithic Linux, there is a small performance tradeoff because of the µ-kernel architecture. However, the initial L4Linux has been somewhat optimized, and on L4/x86 it has a very acceptable slowdown of less than 4 % for any relevant load.
http://i30www.ira.uka.de/research/documents/l4ka/ukernel-performanc(...)
[^] # Re: Avancement futur? + perfs ?
Posté par Manuel Menal . Évalué à 8.
* le programme réalise un appel read() ; la GLibc contacte le translator chargé
du fichier et lui envoie une requête ;
* le système de fichier fait un appel à l'abstraction qui s'occupe de gérer son "backing store" (il y a généralement ce type d'abstraction, pour que le FS se lance de façon transparente sur une image, une partition, une image compressée/chiffrée, ...) ;
* cette abstraction va traduire la requête en une autre, selon le type de source ; disons qu'il s'agit d'une partition sur un disque IDE ;
* GNU Mach est donc appelé pour faire la lecture (les pilotes sont dans GNU Mach).
Dans l'autre sens, les données seront trimbalées dans toute la chaîne. On rajoute avec L4 une étape : le pilote IDE en espace utilisateur, qui fera lui-même vraisemblablement un appel système (à moins d'I/O port déjà mappé ou de DMA). Les IPCs dans GNU Mach sont asynchrones. Cela signifie que lorsqu'un thread fait un envoi de message à un autre thread, le noyau lui rend la main dès qu'il a enregistré la requête dans la queue des messages correspondant à ce thread (en fait, un thread n'est pas associé à une queue, mais passons). Bien sûr, il fait une copie logique, et même plus précisémen du copy-on-write, comme dit dans la news : mais comme les messages sont asynchrones, l'application continue à faire autre chose pendant le même temps, et si elle écrit là où les données étaient stockées, il faudra copier physiquement la mémoire dans la queue (dans le noyau! on sait comme les copies user space -> kernel sont extrêmement lourdes) en attendant que le destinataire vienne le chercher. Le temps que le message de retour soit passé dans toute la chaîne, il est bien probable qu'une application au moins ait modifié l'emplacement mémoire où elle avait stocké les données lues (disons, le pilote IDE). Du coup, au moins une copie physique lourde, si ce n'est deux. N'autoriser que des IPCs synchrones (et gérer le passage de mémoire intelligemment avec des containers comme le fait physmem) résout en grande partie le problème : c'est ce que fait L4.
L'autre problème est lié au simple fait que l'appel implique plusieurs services : outre le passage de message, le fait de passer d'une tâche à l'autre (changement de contexte) a lui aussi un coût associé. Une partie des coûts sont liés au TLB (Translation Lookaside Buffer). Ce TLB est un buffer où l'on met en cache les correspondances adresses virtuelles <-> adresses physiques. En effet, le fait de retrouver l'adresse physique à partir de l'adresse virtuelle est une opération assez pénible qui nécessite des parcours dans les pagetables de toutes façons assez longs (évidemment, les VM essayent de le rendre le moins long possible). Or, les adresses virtuelles sont dépendantes de l'espace d'adressage, donc a priori de la tâche en cours d'exécution. Comme on n'a pas moyen de préciser dans le TLB "cette association correspond à tel espace d'adressage" (tagger le TLB) sauf sur quelques architectures, il faut le vider à chaque changement de contexte. Et donc multiplier les parcours. Plus on multiplie les changements de tâche, plus on multiplie les parcours, plus on perd du temps. L4 se propose justement de résoudre ça (au moins en partie sur x86) sur au moins trois architectures (x86, PowerPC, Sparc), en utilisant des possibilités de chaque architecture. Du coup, on évite 4 fois sur 5 au moins les "vidages" de TLB.
Si vous voulez plus de détails sur les mécanismes, réferez vous aux publications de L4Ka ou aux anciens commentaires de Kilobug ou de moi. :-)
[^] # Re: Avancement futur? + perfs ?
Posté par Pinaraf . Évalué à 8.
Cf http://www.l4ka.org/projects/l4linux/(...) et http://i30www.ira.uka.de/research/documents/l4ka/ukernel-performanc(...)
[^] # Re: Avancement futur? + perfs ?
Posté par neil . Évalué à 9.
Les threads sont directement fournis dans par le système avec les noyaux L4, on peut donc imaginer des threads noyaux et grace aux SuperFast IPC et Lazy Switching, la communication et le switching (?) entre threads d'un même espace d'adressage ne nécessite même plus de passer en mode noyau (comme les threads en mode utilisateur actuels).
Le site de L4Linux : http://os.inf.tu-dresden.de/L4/LinuxOnL4/(...)
Lazy Switching : http://l4ka.org/publications/paper.php?docid=666,(...) et dans beaucoup d'autres doc sur L4 et les vrais µ-kernels, pas encore implementé dans L4Ka::Pistachio cependant, mais prévu par la norme.
Encore plein de docs sur L4 et les µ-kernels : http://l4ka.org/publications/(...)
Un site sur les systèmes L4 (avec des liens vers d'autres OS basé dessus) : http://l4hq.org/(...)
[^] # Re: Avancement futur? + perfs ?
Posté par Guillaume Knispel . Évalué à 2.
[^] # Re: Avancement futur?
Posté par Sebastien . Évalué à 8.
Ne serait-ce que pour soigner son image (sans jusqu'à aller écrire un bouquin sur comment et quand pouvoir utiliser la marque Hurd), il me semble qu'il serait utile d'avoir une page récapitulant ce que l'on peut faire (Hurd-Mach et Hurd-L4), ce que les devs sont en train de faire, ce qu'il reste à faire, etc...
Une opération de communication au sens le plus noble du terme.
C'est sûr qu'il y a déjà tout d'écrit dans les différents README et TODO éparpillés sur le CVS. Mais c'est pas super pratique pour avoir une vision globale de ce qui se passe dans le microcosme du Hurd. Et... non, éplucher toute la mailing-liste n'est pas non plus une solution super satisfaisante.
De plus, je suis sûr que ça faciliterait le travail d'intégration des nouveaux arrivants : un truc un peu plus user-friendly que le : read the sources, Luke.
Après ma thèse, j'aimerais bien m'y mettre, mais je sens déjà que ça va être coton (et ce que je veux dire par là c'est que je sens que ça va être plus coton qu'il me semble que cela devrait/pourrait être).
[^] # Re: Avancement futur?
Posté par Manuel Menal . Évalué à 7.
On ne peut pas demander aux développeurs de rédiger eux-mêmes les news /., Kerneltrap ou autres. Ca prend du temps, et c'est mieux s'il est passé à coder (ou documenter son code). Éplucher les mailing lists, relayer les informations, c'est justement ce qui se fait de mieux en mieux, je trouve : par exemple, je remercie Victor et toi-même d'avoir soumis des news sur le sujet, que j'ai pu compléter avec les dernières nouvelles du Hurd. On a eu pas mal de news régulières sur le Hurd, assez complètes et explicatives, de Thomas, de Matthieu, de vous deux. Comme quoi, les choses progressent !...
Toutefois, je pense aussi qu'il manquerait une petite équipe, de deux disons, qui se chargeraient de faire des espèces de HWN (Hurd Weekly News (peut-être pas weekly ceci dit), sur le modèle des Debian Weekly News). Ca veut dire suivre plus ou moins attentivement les mailing lists, passer sur le canal IRC et demander aux développeurs ce qu'ils pensent qu'on peut mettre, etc. C'est pas un boulot très difficile, mais c'est assez prenant. Avant, il y avait le Hurd Traffic (comme Kernel Traffic), qui épluchait les mailings lists et en faisait des compte-rendus réguliers. Mais par manque de temps, ça n'existe plus. Effectivement, ça manque. Après ta thèse, tu dis ? ;-)
[^] # Re: Avancement futur?
Posté par Manuel Menal . Évalué à 10.
Impossible également de prévoir si un ou deux développeurs ne vont pas nous rejoindre dans les mois à venir, qui feront avancer le projet considérablement plus vite (hé oui, 2 pour Linux c'est négligeable, pour le Hurd ça ne l'est pas du tout).
GNU/Hurd existe, est fonctionnel dans une certaine mesure. On peut l'installer, le tester, l'utiliser (même si personne ne voudrait l'utiliser dans son état actuel plutôt que GNU/Linux). Il faut, je pense, considérer GNU/Hurd sur Mach comme une plateforme temporaire qui permet de faire fonctionner le Hurd, et ainsi de l'essayer, de le débugger, de développer ses couches supérieures, et de créer Debian GNU/Hurd. Aussi, rajouter le support des winmodem, de l'ACPI, du son ou de l'USB, on peut pas dire que ce soit très utile (à moins, bien sûr, qu'on le fasse sans effort parce qu'on a trouvé un code simple à isoler et à gluecoder dans GNU Mach). On nous répète suffisamment qu'on perdrait notre temps avec le port sur L4 (ou à l'inverse, qu'on perdrait du temps avec Debian GNU/Hurd puisqu'il y a le port sur L4), on va pas nous demander en plus de perdre vraiment notre temps en développant GNU Mach plus qu'on en a besoin, uh ? :)
Et les développeurs ont l'intention de faire marcher ce "truc" un jour, merci pour eux. C'est justement parce qu'ils ont l'intention de le faire marcher, et bien, qu'ils ont entrepris le port sur L4, parce qu'ils pensent que c'est le meilleur moyen d'avoir un GNU/Hurd fonctionnel et optimal. Et si tu as bien lu la news, ça avance bien de ce côté là. Si tu veux imaginer ce qu'il reste à faire, prends un OS traditionnel, et divise le en deux parties : les couches basses du noyau (mémoire, scheduler, drivers, IPC, gestion des tâches, ...) et tout ce qui va au-dessus. Le port sur L4 représente le travail sur les couches basses du noyau : et vu que ça en est aux drivers, il y a déjà un certain état d'avancement. Le travail effectué sur Debian GNU/Hurd (en utilisant Mach) correspond au travail sur les couches supérieures : lui aussi avance bien, vu que GNU/Hurd sait faire tourner (partiellement) Gnome, remplit 9 CDs, etc. Lorsque le port sur L4 sera fonctionnel, il faudra évidemment faire un "sync", qui demandera un peu de boulot : mais c'est pas un si gros morceau. Concrètement, donc, c'est déjà bien avancé, et ça avance pas mal sur les deux fronts, compte tenu du nombre de développeurs.
[^] # Re: Avancement futur?
Posté par Sebastien . Évalué à 4.
Un planning ça peut aussi être juste une liste de tâches, avec accessoirement un nom en face et une estimation du temps que cela prendrait si un développeur à temps plein était dessus.
Ensuite, je suis complétement d'accord sur le fait que si même dans le LL on ne peut pas avoir une certaine flexibilité sur les dates... (Mais heureusement Debian est là pour montrer l'exemple :P )
[^] # Re: Avancement futur?
Posté par Manuel Menal . Évalué à 2.
http://savannah.gnu.org/task/?group=hurd(...)
Il y a aussi les rapports de bugs : http://savannah.gnu.org/bugs/?group=hurd(...)
Enfin, pour Debian GNU/Hurd il y a les tâches suivantes : http://alioth.debian.org/pm/?group_id=30628(...)
Évidemment, ça n'est jamais totalement à jour et il vaut mieux en discuter sur les mailing lists ou IRC quand on se met une tâche, parce que les développeurs ont souvent une idée de ce qui est urgent dans le moment, et parce qu'ils ont généralement déjà pensé à comment faire la plupart des tâches. HurdFR est aussi là pour répondre à ce genre de questions, sur la mailing list, sur IRC.
[^] # Re: Avancement futur? Savannah?
Posté par free2.org . Évalué à 2.
C'est ce que semble confirmer cette page officielle:
http://www.gnu.org/software/hurd/devel.html(...)
[^] # Re: Avancement futur? Savannah?
Posté par Manuel Menal . Évalué à 2.
# Question bète
Posté par Nicolas Boulay (site web personnel) . Évalué à 8.
A prioiris, hurd file un max de mémoire au processus et leur réclame ensuite si d'autre processus en ont besoin. J'image qu'il serait possible de filer de suite 3 pages de 4Mo par processus (à redeécouper ensuite) (1RO, 1RW, 1 Execute)
"La première sécurité est la liberté"
[^] # Re: Question bète
Posté par Matthieu Lemerre (site web personnel) . Évalué à 10.
Donc oui, on peut gerer des pages de taille difference, mais ce n'est pas le Hurd qui fait cela, c'est L4.
Pour rentrer dans le detail de ce qui se passe: physmem, le serveur de memoire physique du Hurd, "se debrouille" pour que son espace d'adressage virtuel corresponde exactement a celui de la memoire physique (i.e. l'adresse 10 000 vu de physmem aura l'adresse physique 10 000).
Ensuite, les differentes applications vont faire des demandes d'allocation a physmem, qui va mapper une region de la memoire virtuelle de l'application appellante dans une region de sa propre memoire virtuelle (qui est en correspondance 1:1 avec la memoire physique).
Ainsi au final, l'application appelante se retrouve bien avec une portion de sa memoire virtuelle mappee dans de la memoire physique, ce qui realise l'equivalent d'un appel systeme mmap sur de la memoire anonyme sous Linux.
Au fait: on ne peut pas vraiment a ce stade parler de processus, en tout cas au sens UNIX du terme, car un processus correspond a un espace d'adressage qui comprend plusieurs thread (ce qui s'appelle une tache dans la terminologie L4), mais aussi nombre d'autres choses comme un PID, un UID, un GID, la liste des descripteurs ouverts...
La question du nombre de ressource allouee a chaque tache n'est pas encore definie, mais il est probable que le modele adopte sera celui du "marketplace": en fonction de la rarete des ressources disponibles (memoire, temps processeurs, IO) et de ce dont les autres ont besoin, chaque application aura la possibilite de s'adapter en echangeant, par exemple, de la memoire contre du temps processeur.
Mais ceci fera sans doute l'objet d'une nouvelle news :)
PS: ta question n'etait pas bete du tout :)
http://l-lang.org/ - Conception du langage L
[^] # Re: Question bète
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
En gros, L4 fournis toutes la mémoire à un serveur centrail qui refile un maximum de mémoire à toutes les applications qui le demandent. Quand il est à court de mémoire, il en demande à des applications, celle-ci sont tué si elle ne refile pas la mémoire.
Comme le principe est de filer toutes la mémoire et de la réclamer ensuite, je me disais qu'il serai sans doute possible de filer directement des pages de 4Mo et de fragmenter ensuite, si besoin.
"La première sécurité est la liberté"
# Debian Gnu tout court?
Posté par Dalton joe . Évalué à 3.
Avec le choix Hurd et ou Linux?
Donc, Debian GNU.
[^] # Re: Debian Gnu tout court?
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
[^] # Re: Debian Gnu tout court?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Debian Gnu tout court?
Posté par Manuel Menal . Évalué à 2.
[^] # Re: Debian Gnu tout court?
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Pour Hurd, c'est bizzare, car il faut plusieurs reboot pour finir l'installation. Ca vient du fait que crosshurd utilise pas mal d'outils Linux pour installer du Hurd je pense.
@+ Haypo
[^] # Re: Debian Gnu tout court?
Posté par Dalton joe . Évalué à 1.
Ensuite avec un source.list different ça devrais le faire non?
[^] # Re: Debian Gnu tout court?
Posté par Manuel Menal . Évalué à 3.
a) Les translators passifs. GNU/Hurd, pour pouvoir fonctionner, a besoin d'un certain nombre de translators passifs installes. Par exemple, pflocal pour faire fonctionner tout ce qui est sockets Unix, pipes, etc, le translator exec, password (ca peut servir de pouvoir valider un couple (login,password) pour se logger ;-), etc. Or, on ne peut actuellement que positionner des translators passifs depuis GNU/Hurd (en utilisant la commande settrans).
b) L'installation se fait toujours actuellement depuis un GNU/Linux. Dans le cas de crosshurd, c'est normal, c'est fait pour. :-) Mais l'installer des CDs tourne lui aussi sous GNU/Linux, pour des raisons de stabilite, simplicite et parce qu'il manque encore quelques trucs pour porter l'installateur Debian sous GNU/Hurd. Donc on ne peut pas positionner les translators passifs pendant l'instant. Donc, on boote pour la premiere fois dans un systeme minimal (single, a peine un shell root ^^) et on lance un script (native-install) qui s'occupe de positionner les translators passifs. C'est la premiere passe de native-install. Ensuite, on reboote dans un systeme a peu pres bien en place, et on lance la configuration des paquets (vu que c'est installe depuis GNU/Linux, on a juste fait l'extraction et pas la configuration).
Les solutions existent : utiliser des attributs etendus POSIX pour les translators passifs (donc on pourra les changer et positionner depuis GNU/Linux) ; avoir un installer sous GNU/Hurd pour eviter la seconde passe. Pour le premier, ogi (celui qui a patche ext2fs pour supporter les FS de plus de 2G) travaille dessus dans le cadre de son boulot sur ext3fs. Dans le second cas, le LiveCD GNU/Hurd est deja un premier pas vers ca, ca viendra.
# Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: screenshot
Posté par Manuel Menal . Évalué à 2.
Le Emacs est un Emacs22 CVS - les patchs Debian pour le dernier Emacs 21.4 le font segfaulter sous GNU/Hurd, pour une raison encore inconnue.
On fait tourner aussi E17 sous GNU/Hurd : http://dindinx.net/e/(...) ;-)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: screenshot
Posté par Manuel Menal . Évalué à 1.
# Hurd a un gros défaut congénital
Posté par Ontologia (site web personnel) . Évalué à 0.
Je pense que Hurd est un OS conceptuellement très interessant sur plein de points, notamment la fin du noyau monolithique qui permet de modulariser a peu près tout et n'importe quoi.
La gestion des droits d'utilisateurs par exemple est très interessante, en ce qu'elle permet de se dépatouiller de n'importe quel situation en permettant de changer n'importes quels droits d'un processus.
Je ne liste pas les avancées conceptuels de Hurd, vous les connaissez mieux que moi.
Néanmoins, et pour rejoindre le titre provoquant que j'ai choisi, je pense AMHA que le Hurd a pour gros défaut d'être écrit en C.
Le C était un langage vraiment génial pour l'époque et l'est encore aujourd'hui. Mais son approche trop bas niveau, la nécessité de gérer les pointeurs, bref de tout faire à la main, implique que tous projet d'une certaine envergure atteint très vite ses limites et que l'on tombe très vite sur des bugs classique, stupide de surcroit.
Windows en est un bon exemple, et l'étude de ses sources (celle de Windows 2000 qui circulèrent sur le net) achève la preuve (ie. On se trouve devant un code très bien écrit, très bien commenté, où l'on se rend compte que c'est la complexité intrinsèque du projet qui est le problème majeur)
Je crois que les recherches récentes sur les compilateurs, et en particulier
http://smarteiffel.loria.fr/(...)
http://www.loria.fr/~zendra/publications/oopsla97.ps(...)
et surtout http://fr.wikipedia.org/wiki/Lisaac(...) (qui intègre des fonctionnalités étendues de programmation système) permettent maintenant de concevoir des systèmes d'exploitation objet écrit dans un langage de haut niveau, avec de très bonne performances.
L'absence de pointeurs dans ces langages, leurs librairies évoluées (collections, tables de hashages, types chaîne évolué, etc...), le multi héritage, etc... permettent de faciliter le développement et la maintenance.
Bref, Hurd bien que très intéressant et plus moderne que les OS installés est déjà dépassé.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Hurd a un gros défaut congénital
Posté par Sébastien TeRMiToR . Évalué à 1.
meme en python si tu veux !
donc hop dernier verous tomber
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.