Articles précédents : Code
- [29] Templeet certifié J2EE
- [92] Sortie du noyau 2.6.11
- [29] Délégation de pouvoirs avec un contrôleur de domaine Samba
- [96] Hurd : nouvelle version de Debian GNU/Hurd et avancée du port sur L4
- [107] SPT : Une alternative au système historique de partitionnement des PC
- [40] Sortie de OpenBGPd
- [60] « Autocompiler » son noyau au démarrage avec TCCBoot
- [11] Busybox 1.0
- [101] John Carmack victime des brevets logiciels
- [154] Le code de Java3D est disponible
Liens connexes
- KernelTrap : Next Stage of Hurd/L4 VMM Framework Completed (582 hits)
- KernelTrap : Device Driver Framework (410 hits)
- Journal LinuxFR sur le sujet (607 hits)
- DLFP : Interview de Marcus Brinkmann (390 hits)
- HurdFR (972 hits)
- L4Ka (414 hits)
Dépêche modérée par
Dépêche éditée par
Code : Nouvelle avancée du port du Hurd sur L4
Posté par Victor STINNER (page perso, ). Modéré le 19 mai 2005.
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.
![[en]](../../../images/en.png)
KernelTrap : Next Stage of Hurd/L4 VMM Framework Completed (582 hits)-
KernelTrap : Device Driver Framework (410 hits)
![[fr]](../../../images/fr.png)
Journal LinuxFR sur le sujet (607 hits)-
DLFP : Interview de Marcus Brinkmann (390 hits)
-
HurdFR (972 hits)
-
L4Ka (414 hits)
> Lire la dépêche (54 commentaires, moyenne: 3,8).
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
[+] La montre qui fait tout mais ne donne pas l'heure
Le pilote IDE qui se charge de votre disque secondaire a planté ? Pas grave, il suffit de le relancer dans la plupart des cas.Enfin, ça c'est pour dans quelques mois. Quand Hurd supporteras l'IDE.
Question de priorité je suppose -_^.
Au passage, vous avez déjà réussi à faire planter le pilote IDE vous ?
Respect à RMS.
-
[^]Re: La montre qui fait tout mais ne donne pas l'heure
Posté par Manuel Menal (page perso, ) le 19/05/2005 à 08:56. (lien). Évalué à 10.Est-ce que tu penses qu'on fait fonctionner Gnome sans pilote IDE (ni SCSI, chipottez pas !) ? :-) GNU/Hurd, lorsqu'il utilise GNU Mach, supporte très bien IDE et SCSI, et toute une variété d'HBA (bon, aucun U160 ou U320, mais je suis en train de backporter un driver).
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 Brice Arnould ( un_brice ) (page perso, ) le 19/05/2005 à 21:56. (lien). Évalué à 4.Est-ce que tu penses qu'on fait fonctionner Gnome sans pilote IDE (ni SCSI, chipottez pas !) ? :-) GNU/Hurd, lorsqu'il utilise GNU Mach, supporte très bien IDE et SCSI, et toute une variété d'HBA (bon, aucun U160 ou U320, mais je suis en train de backporter un driver).
En fait, c'était de l'humour... mais j'aurais dû être plus explicite.
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.--
Respect à RMS.-
[^]Re: La montre qui fait tout mais ne donne pas l'heure
Posté par Manuel Menal (page perso, ) le 19/05/2005 à 22:07. (lien). Évalué à 7.La branche actuelle ? Non, la branche actuelle utilise GNU Mach. GNU Mach est le seul noyau supporté par le Hurd actuellement, et le module 'hurd' dans le CVS ne contient que le support pour GNU Mach.
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 () le 20/05/2005 à 08:25. (lien). Évalué à 1.Pauvre Mmenal, contraint par sa nature à répondre un pavé à chaque blague débile... occupe-toi du driver IDE et laisse causer les gens. Moi, j'attends une Ubuntu sur L4 avec impatience. Malheureusement, je crois qu'il faudra attendre encore au moins 5 ans, mais ça devrait valoir le coup :)
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 () le 19/05/2005 à 10:01. (lien). Évalué à 3.j'ai deja eu a faire un hotswap d'un dd (oui je sais dangereux) qui n'etait pas mis au bios ; et c'etait plutot complique a faire.
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 ;)--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: La montre qui fait tout mais ne donne pas l'heure
Posté par Brice Arnould ( un_brice ) (page perso, ) le 19/05/2005 à 21:47. (lien). Évalué à 0.Tu l'avais préparé avec hdparm ton disque dur ? Si oui, c'est probablement un bug du chipset, recharger le pilote n'y aurais rien fait.
--
Respect à RMS.-
[^]Re: La montre qui fait tout mais ne donne pas l'heure
Posté par briaeros007 () le 20/05/2005 à 06:51. (lien). Évalué à 2.j'avais fait a peu pres tout ce qui etait possible. C'etait un dd qui provoquait des erreurs a cause d'un autre dd sur la nappe.
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)--
Subete ga wakatta toki…watashi ga anta wo korosu.
-
-
Avancement futur?
Pensez-vous qu'il est possible d'avoir une sorte de "planning" prévisionnel de l'avancée de Hurd? Par exemple, à quand les premiers hurds fonctionnels pour la vie de tous les jours sur un PC "compatible"? A quand une "MandrakeHurd"? Quand est-ce que Hurd fonctionnera sur mon portable, avec support du winmodem et de l'ACPI? Parce que pour l'instant, Hurd c'est bien, c'est rigolo, on peut faire des blagues dessus, mais les dev doivent bien avoir l'ambition de faire marcher ce truc un jour, non?
-
[^]Re: Avancement futur?
Posté par Chl (page perso, ) le 19/05/2005 à 07:51. (lien). Évalué à 3.Il ne faut pas confondre :
* 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 () le 19/05/2005 à 08:31. (lien). Évalué à 1.Dans la news, on y lit que Gnome fonctionne presque entièrement, moi, je ne sais pas ce que ça veut dire. Est-ce que tout fonctionne sauf quelques trucs complexes (le multimédia, quelque chose comme ça?). Ou alors est-ce que tout marche potentiellement quand il sera possible de compiler Gnome avec les options kivontbien? Désolé, mais ce genre de communication, ça fait vraiment geek. "Ca fonctionne presque bien", ça peut vouloir dire tout et n'importe quoi. Quid du serveur X? Quid des driver courants? Quid de l'accélération 3d? Du support de l'USB? Pourquoi Gnome marcherait et pas KDE?
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` () le 19/05/2005 à 09:25. (lien). Évalué à 8.- X : fonctionnel depuis longtemps
- 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 )--
\_o<~~~~-
[^]Re: Avancement futur?
Posté par Zakath (page perso, ) le 19/05/2005 à 09:36. (lien). Évalué à 8.drivers courants : hein ?! un clavier, une souris, un disque dur, un écran, ben oui tout ca fonctionne ...
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 (page perso, ) le 19/05/2005 à 15:19. (lien). Évalué à 5.Un grand nombre, c'est vite dit. Voici les drivers de cartes reseaux compiles en standard dans le paquet Debian de GNU Mach :
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 () le 20/05/2005 à 09:00. (lien). Évalué à 3.En fait, le intel-gige ne supporte que le premier iteration du e1000. Apparemment, tout les autres iterations sont très similaire entre eux, mais assez different au premier :-/
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?
-
-
[^]Re: Avancement futur?
Posté par Manuel Menal (page perso, ) le 19/05/2005 à 15:09. (lien). Évalué à 10.Je t'assure qu'il y a moyen de demander sans etre desagreable - d'autres le font. Je n'ai pas souhaite developper beaucoup plus dans la news parce que c'est une nouvelle, et il n'est pas forcement tres interessant de savoir dans le detail que ca marche sauf quand on utilise la fonctionnalite truc de machin etc. Ces informations la, tu les trouveras globalement sur les mailing lists, que tu consultes de toutes facons si tu souhaites aider au developpement - et c'est le seul cas ou le detail pourra t'interesser. Si tu veux vraiment le detail : gconfd ne se lance pas automatiquement (il segfaulte au lancement) : mais en le lancant a la main, ca marche ; nautilus a tendance a crasher parce que la GLib utilise pthread_attr_setstacksize incorrectement ; bref, des petits problemes qui ne manqueront pas d'etre corriges assez rapidement. L'idee est que Gnome fonctionne, mais si vous installez une K9, vous ne l'aurez pas en standard a cause de ces petites complications.
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 () le 19/05/2005 à 15:45. (lien). Évalué à 5.Je n'avais absolument pas l'intention d'être désagréable, je répondais simplement au post précédent qui me disait que je ne savais pas lire parce que c'était marqué dans la news, ce qui était faux.
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 () le 19/05/2005 à 16:08. (lien). Évalué à 5.Oui, si tu considére qu'il n'y a que des utilisateurs purs qui trainent sur ce site, ce qui est à mon avis loin d'être vrai. On peut apprécier d'avoir des nouvelles plus ou moins techniques sur un projet et son avancement sans forcément vouloir prendre le temps de lire les mailing liste.
-
[^]Re: Avancement futur?
Posté par Manuel Menal (page perso, ) le 19/05/2005 à 20:09. (lien). Évalué à 5.Bon, je l'ai peut-être mal pris. Faire ses commentaires au taf n'est ptêt pas le milieu idéal pour être relaxé.
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 () le 20/05/2005 à 09:08. (lien). Évalué à 4.A propos de gcondf: Le problème etait que le communication entre gconfd et gconf (fait avec ORBit) ne marche pas avec le standard (par socket), mais ca marche très bien en utilisant TCP/IP. Il faut seulement dire orbit d'utiliser TCP/IP dans ~/.orbitrc. Et en plus, Neal a fait quelques patch pour Hurd et glibc et ca doit marcher sans problèmes bientôt.
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 (Jabber id, page perso, ) le 19/05/2005 à 07:52. (lien). Évalué à 1.Relis le post : la Debian existe avec Hurd/Mach. Ici on parle de Hurd/L4.
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 ?-
[^]Re: Avancement futur? + perfs ?
Posté par Chl (page perso, ) le 19/05/2005 à 07:58. (lien). Évalué à 2.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 ?
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 (Jabber id, page perso, ) le 19/05/2005 à 09:43. (lien). Évalué à 2.Relis le post :) :
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 !-
[^]Re: Avancement futur? + perfs ? 4%
Posté par free2.org (page perso, ) le 19/05/2005 à 09:49. (lien). Évalué à 4.http://os.inf.tu-dresden.de/L4/LinuxOnL4/status.shtml(...)
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 (page perso, ) le 20/05/2005 à 05:28. (lien). Évalué à 8.Globalement, ça ne dépend pas beaucoup des applications. Ce sont les services systèmes qui sont plus lents dans un système multi-serveurs à base de micro-noyau. Je prends un exemple : lorsqu'on réalise une lecture de fichier, classiquement les données passeront par ces intermédiaires :
* 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 (Jabber id, ) le 19/05/2005 à 08:38. (lien). Évalué à 8.Le port de linux sur L4 semble avoir des performances très honorables : seulement 5% inférieures à celles d'un Linux normal, sachant que le noyau linux n'est pas "optimisé" pour les micro noyaux.
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 () le 19/05/2005 à 09:43. (lien). Évalué à 9.A noter que les performances d'un µ-kernel sont meilleures, si le système par dessus est pensé pour, que celles d'un kernel monolithique classique. Les vrais µ-kernels (seconde génération) ont vraiment étés conçus pour être très rapide, notamment au niveau des communications entre threads (la base des µ-kernels).
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 () le 21/05/2005 à 19:02. (lien). Évalué à 2.Les threads noyaux restent en mode utilisateurs pour commuter alors que les threads utilisateurs passent en mode noyau ? Va me falloir lire beaucoup de DOC pour bien capter :)
-
-
-
-
[^]Re: Avancement futur?
Posté par Sebastien Binet () le 19/05/2005 à 08:18. (lien). Évalué à 8.J'opine du chef.
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 (page perso, ) le 19/05/2005 à 09:29. (lien). Évalué à 7.Je suis d'accord, il y a définitivement une difficulté à communiquer sur le Hurd. Les développeurs le font assez régulièrement sur les mailing lists (cf. les longs mails explicatifs de Neal ou de Marcus sur ce qui est fait et ce qui reste à faire, ou l'interview de Marcus) et Michael fait régulièrement le relai avec Kerneltrap.
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 (page perso, ) le 19/05/2005 à 09:18. (lien). Évalué à 10.Les plannings, ça marche déjà difficilement dans les boîtes, où les gens sont payés pour un projet. Ca marche encore plus difficilement dans les gros projets tels que Gnome ou Linux, où un certain nombre de développeurs sont payés à plein temps, et où, en tout état de cause, il y a suffisamment de développeurs pour en avoir tout le temps un certain nombre. Pour un projet comme le Hurd, c'est inenvisageable. Trop peu de développeurs actifs, et trop aléatoire : les développeurs ont aussi une vie, qui peut les amener à ne pas pouvoir s'impliquer pendant des périodes de plusieurs mois.
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 Binet () le 19/05/2005 à 09:28. (lien). Évalué à 4.Je suis globalement d'accord, sauf qu'un planning ce n'est pas forcément mettre absolument des dates et des noms en face de ces dates avec des deadlines strictes.
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 (page perso, ) le 19/05/2005 à 09:35. (lien). Évalué à 2.C'est déjà fait en partie, en utilisant Savannah pour le projet Hurd en lui-même :
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 (page perso, ) le 19/05/2005 à 11:46. (lien). Évalué à 2.Tiens, j'avais lu quelque part que Savannah n'était plus utilisé par Hurd. J'ai mal compris ?
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 (page perso, ) le 19/05/2005 à 15:20. (lien). Évalué à 2.On garde effectivement un fichier TASKS et TODO dans les sources, mais le Hurd utilise egalement Savannah. Et la page en question n'est juste pas tres a jour (elle ne mentionne pas Savannah).
-
-
-
-
Question bète
Est-ce que la VM arrive à gérer les pages de tailles différentes ?
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)
-
[^]Re: Question bète
Posté par toto29 () le 19/05/2005 à 16:05. (lien). Évalué à 10.En fait, le Hurd sur L4 utilise les primitives fournies par L4, et la primitive correspondante est la notion de flexpage (fpage). Une flexpage est une region de memoire virtuelle, indivisible (c'est a dire qu'on ne peut pas mapper une fpage dans un espace d'adressage, puis unmapper une portion de cette fpage).
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 :)-
[^]Re: Question bète
Posté par Nicolas Boulay () le 20/05/2005 à 22:58. (lien). Évalué à 3.J'avais discuter avec Neil sur la stratégie d'allocation de mémoire du Hurd, il y a qq années au Fosdem.
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.
-
Debian Gnu tout court?
A quand le Hurd en option dans l'installeur de Debian?
Avec le choix Hurd et ou Linux?
Donc, Debian GNU.
-
[^]Re: Debian Gnu tout court?
Posté par Matthieu Moy (page perso, ) le 19/05/2005 à 11:17. (lien). Évalué à 2.Je crois pas qu'il y ai de compatibilité binaire entre les applies des deux noyaux, donc, ça ne me parait pas très possible.
-
[^]Re: Debian Gnu tout court?
Posté par Nicolas Boulay () le 19/05/2005 à 11:50. (lien). Évalué à 2.euh... hurd n'utilise pas la glibc ?
-
[^]Re: Debian Gnu tout court?
Posté par Manuel Menal (page perso, ) le 19/05/2005 à 15:26. (lien). Évalué à 2.GNU/Hurd utilise evidemment la GNU C Library. Mais elle n'exporte pas exactement la meme interface binaire selon les ports. Ce n'est d'ailleurs pas une priorite : ca apporte parfois des complications (des interfaces optionnelles qui n'ont pas de sens chez nous devraient etre implementes juste pour la compatibilite, et on devra les maintenir en faisant attention a chaque changement, ...) pour pas grand chose. Une parfaite compatibilite POSIX est un but bien plus intelligent - les applications incorrectes doivent etre corrigees (les rendant plus portables y compris sur d'autres architectures), et autrement la compatibilite source est parfaite.
-
-
-
[^]Re: Debian Gnu tout court?
Posté par Victor STINNER (page perso, ) le 19/05/2005 à 12:12. (lien). Évalué à 3.Hum ? « Debian GNU/Hurd » ? Je ne sais pas si c'est dans l'installeur par défaut, par contre, ça s'installe plutôt bien avec "crosshurd". Il permet d'installer GNU/Hurd, GNU/Linux, GNU/FreeBSD, et GNU/NetBSD.
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 (page perso, ) le 19/05/2005 à 15:52. (lien). Évalué à 1.Y a peut être pas compatibilité Binaire mais si ca peut tenir sur un CD du net installeur.
Ensuite avec un source.list different ça devrais le faire non?
-
[^]Re: Debian Gnu tout court?
Posté par Manuel Menal (page perso, ) le 19/05/2005 à 16:37. (lien). Évalué à 3.C'est pas si bizarre que ca. En fait, c'est lie a deux choses :
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.
-
screenshot
Comment faire une capture d'écran ??? J'ai pas trouvé de import etc.
Comment installer les bout de gnome qui marche partiellement ?
Et sinon, j'ai un GNU OS 0.3 qui traine sur une bonne bécane (à coté d'une ubuntu breezy et d'une kubuntu breezy), mais j'ai l'impression de ne pouvoir qu'attendre et regarder : je suis incompétent.
Que faire ?
Merci pour toute les réponses.
E Ultreïa !
-
[^]Re: screenshot
Posté par Étienne Bersac (Jabber id, page perso, ) le 19/05/2005 à 14:20. (lien). Évalué à 1.hop, une réponse :
deb http://people.debian.org/~mbanck/hurd-gnome/(...) ./
Au fait, sous hurd, j'utilise login root plutôt que su, qu'est-ce que cela change ? est-ce mieux ???--
E Ultreïa !
-
[^]Re: screenshot
Posté par Étienne Bersac (Jabber id, page perso, ) le 19/05/2005 à 14:26. (lien). Évalué à 1.à noter que le gus fait aussi tourner xfce (qui peut le plus peut le moins) : http://people.debian.org/~mbanck/xfce4-hurd.png(...)
Il y a aussi les répo pour mozilla, emacs etc.
deb http://people.debian.org/~mbanck/hurd-mozilla/(...) ./
deb http://people.debian.org/~mbanck/hurd/(...) ./--
E Ultreïa !-
[^]Re: screenshot
Posté par Manuel Menal (page perso, ) le 19/05/2005 à 15:29. (lien). Évalué à 2.Attention, Mozilla ne fonctionne pas pour l'instant (il faut lancer gconfd a la main, et ensuite on ne peut pas taper d'URL ;-). Ce sont juste des paquets contenant un Mozilla non strippe (avec symboles de debug) pour le corriger.
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/(...) ;-)-
[^]Re: screenshot
Posté par Étienne Bersac (Jabber id, page perso, ) le 19/05/2005 à 16:01. (lien). Évalué à 1.mouai, je m'en suis rendu compte :) le emacs22 marche bien en mode texte, mais pas en graphique (j'ai vu avec joie les deps gtk2 :D )
Bref, ça avance, mais je me sens toujours aussi impuissant pour aider :(--
E Ultreïa !-
[^]Re: screenshot
Posté par Manuel Menal (page perso, ) le 19/05/2005 à 16:48. (lien). Évalué à 1.N'hesite pas a passer sur le canal IRC (irc.freenode.net #hurdfr) ou a envoyer un mail sur la mailing list d'HurdFR pour dire ce qui t'interesse, ce que tu te sens capable de faire (temps, competences). Publier des taches de differents niveaux sur une mailing list est un des projets d'HurdFR, mais il faut le temps que ca se mette en place...
-
-
-
Hurd a un gros défaut congénital
Je vais me faire moinsser mais tant pis...
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é.
-
[^]Re: Hurd a un gros défaut congénital
Posté par Sébastien TeRMiToR (page perso, ) le 27/05/2005 à 20:36. (lien). Évalué à 1.Hum , comme les translators sont de simple programme utilisateur, tu peut les faire dans n'importe quelle language !
meme en python si tu veux !
donc hop dernier verous tomber
Cette page a été générée par Templeet en 0.1903s (dont 0.0194 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.