Comme d'habitude, a chaque fois que je lis des docs sur le Hurd, je reste sur une impression tres mitigee.
Ce truc a tres peu d'applications pratiques. Un des avantages de Linux, et ce qui l'a tres vite distingue de minix, c'est qu'il est utile concretement. A cote de ca, Hurd reste un exercice de style.
Le fait est qu'un noyau reste un truc pour gerer du materiel. Mon impression est que Hurd veut reussir a abstraire completement cette partie, et que ca donne des resultats sous-optimaux, comme les problemes qu'il decrit avec la gestion de la memoire. Autant je pense qu'on peut faire abstraction de beaucoup de choses au niveau langage de programmation, autant je ne suis pas persuade que ca s'applique aussi bien a un OS (meme si PDP11 faisait des merveilles avec sa macine lisp, il parait).
Deporter la gestion de la memoire du cote des applications. Super! J'essaie de reflechir a quelle application de nos jours aurait besoin de sa propre gestion memoire. Ce serait soi des applications avec des besoins de tres grosses quantites, soit des applications avec des besoins de beaucoup de petites quantite (ce qui pousse parfois a re-ecrire son gestionnaire de memoire, le modele classique etant plutot adapte a des allocations de gros blocs de facon non repetees). Je suis curieux de savoir si dans la pratique, c'est super lourd a gerer ou s'il suffit juste de linker avec libmemory et ca marche tout seul.
Je pense aussi aux remarque d'Alan Cox, sur l'obsolescence du modele Hurd en tant que station de travail. Hurd est oriente serveur avec plusieurs utilisateurs, ce qui etait l'environnement classique de travail de l'epoque ou il a ete concu. Aujourd'hui, avec des postes PC mono-utilisateurs tout puissants, qui a besoin de monter son systeme de fichier en mode utilisateur ?
Ca n'enleve rien a la qualite du travail effectue, c'est juste que un peu comme quake en ascii-art, ca reste un exercice de style.
# Mouai
Posté par Philippe F (site web personnel) . En réponse à la dépêche Interview de Marcus Brinkmann, développeur du Hurd. Évalué à 4.
Ce truc a tres peu d'applications pratiques. Un des avantages de Linux, et ce qui l'a tres vite distingue de minix, c'est qu'il est utile concretement. A cote de ca, Hurd reste un exercice de style.
Le fait est qu'un noyau reste un truc pour gerer du materiel. Mon impression est que Hurd veut reussir a abstraire completement cette partie, et que ca donne des resultats sous-optimaux, comme les problemes qu'il decrit avec la gestion de la memoire. Autant je pense qu'on peut faire abstraction de beaucoup de choses au niveau langage de programmation, autant je ne suis pas persuade que ca s'applique aussi bien a un OS (meme si PDP11 faisait des merveilles avec sa macine lisp, il parait).
Deporter la gestion de la memoire du cote des applications. Super! J'essaie de reflechir a quelle application de nos jours aurait besoin de sa propre gestion memoire. Ce serait soi des applications avec des besoins de tres grosses quantites, soit des applications avec des besoins de beaucoup de petites quantite (ce qui pousse parfois a re-ecrire son gestionnaire de memoire, le modele classique etant plutot adapte a des allocations de gros blocs de facon non repetees). Je suis curieux de savoir si dans la pratique, c'est super lourd a gerer ou s'il suffit juste de linker avec libmemory et ca marche tout seul.
Je pense aussi aux remarque d'Alan Cox, sur l'obsolescence du modele Hurd en tant que station de travail. Hurd est oriente serveur avec plusieurs utilisateurs, ce qui etait l'environnement classique de travail de l'epoque ou il a ete concu. Aujourd'hui, avec des postes PC mono-utilisateurs tout puissants, qui a besoin de monter son systeme de fichier en mode utilisateur ?
Ca n'enleve rien a la qualite du travail effectue, c'est juste que un peu comme quake en ascii-art, ca reste un exercice de style.