Mais Hurd ne me semble pas "nécessaire" pour ça comme il n'est pas nécessaire d'implémenter la vm côté utilisateur.
Je vais répondre d'un bloc à la série d'arguments du même genre. Si, pour un truc bien précis (choisir la page, offrir des pages de compensation, choisir le type de swap, rajouter une indirection utilisateur, ...) c'est faisable sous Linux, ce que Hurd donne, c'est une flexibilité à ce niveau là, qui permet d'implémenter beaucoup de ces politiques sans toucher au noyau lui-même, et pour beaucoup d'entre elles, sans être root. Si le root a choisi de diviser le temps CPU par utilisateur, après, moi je peux implémenter et lancer mon propre scheduler, qui répond à mes besoins, pour scheduler mes process, sans avoir à passer par le root, et encore moins à rebooter la machine.
Idem pour le pager, une application très particulière (par exemple, un logiciel de traitement qui utilise des grandes quantités de données très facilement compressables par un algorithme bien spécifique) va être "livré" avec un pager spécifique, qui va gérer ça sans avoir besoin de patch noyau, de module noyau, de droits roots, ...
Mouaif... Et si xmms n'a pas ce contrat ? Il arrête le lecture ou il continu est se disant que ça va peut-être passer ?
Je pense qu'il va prendre la seconde voie.
Oui, il va continuer quand même, et ça risque de sauter un peu... dans le pire cas, on revient au même.
De plus, pour xmms tu parles plus d'un problème de latence que d'un problème d'allocation de temps cpu. Pour la latence, Linux 2.6 est assez remarquable "natuellement".
Pas suffisante, même avec preempt, si je torture un peu ma machine (genre quelques bonnes grosses compilations et qu'en même temps j'embête le serveur X par exemple, xmms saute un peu (sur mon athlon xp2400+). L'idée là c'est que même si tu as 30 process qui chacun veulent 100% du CPU, donner 1% garanti à intervalles réguliers (et c'est là la clef) à un processus n'est pas du tout impossible, et ne constitue pas un réel privilège pour le xmms.
Mouaif... Qui donne le plus de liberté actuellement : Linux ou Hurd ?
On ne peut pas comparer un système en cours de développement intensif avec un qui est en version en "stable" depuis longtemps... c'est un peu comme si tu disais qu'un concorde vole moins vite qu'un biplan parce que le dit concorde n'est pas encore complètement assemblé...
> C'est toute la différence entre "droit de chercher un emploi" (et sa variante "droit de travailler") et "droit d'obtenir un emploi" (et sa variante "droit au travail") par exemple, mais c'est un autre débat ;)
L'analogie n'est pas bonne.
Si si, totalement. Linux dit "la licence vous permet de changer le scheduler, la VM, ... et d'en faire ce que vous voulez", mais n'en donne pas vraiment la possibilité pratique, soit à cause des effets de bord (on se rappellera tous l'épisode du noyau 2.4, où on avait le choix entre plusieurs VMs, mais où certains filesystems ne marchaient qu'avec certaines VMs, ...), soit parce que changer le noyau est une tache difficile, qui nécessite d'être root, et souvent de rebooter la machine (lorsqu'on touche au scheduler ou à la VM). Donc c'est bien le même genre de différences.
[^] # Re: Mouai
Posté par Gaël Le Mignot . En réponse à la dépêche Interview de Marcus Brinkmann, développeur du Hurd. Évalué à 6.
Je vais répondre d'un bloc à la série d'arguments du même genre. Si, pour un truc bien précis (choisir la page, offrir des pages de compensation, choisir le type de swap, rajouter une indirection utilisateur, ...) c'est faisable sous Linux, ce que Hurd donne, c'est une flexibilité à ce niveau là, qui permet d'implémenter beaucoup de ces politiques sans toucher au noyau lui-même, et pour beaucoup d'entre elles, sans être root. Si le root a choisi de diviser le temps CPU par utilisateur, après, moi je peux implémenter et lancer mon propre scheduler, qui répond à mes besoins, pour scheduler mes process, sans avoir à passer par le root, et encore moins à rebooter la machine.
Idem pour le pager, une application très particulière (par exemple, un logiciel de traitement qui utilise des grandes quantités de données très facilement compressables par un algorithme bien spécifique) va être "livré" avec un pager spécifique, qui va gérer ça sans avoir besoin de patch noyau, de module noyau, de droits roots, ...
Oui, il va continuer quand même, et ça risque de sauter un peu... dans le pire cas, on revient au même.
Pas suffisante, même avec preempt, si je torture un peu ma machine (genre quelques bonnes grosses compilations et qu'en même temps j'embête le serveur X par exemple, xmms saute un peu (sur mon athlon xp2400+). L'idée là c'est que même si tu as 30 process qui chacun veulent 100% du CPU, donner 1% garanti à intervalles réguliers (et c'est là la clef) à un processus n'est pas du tout impossible, et ne constitue pas un réel privilège pour le xmms.
On ne peut pas comparer un système en cours de développement intensif avec un qui est en version en "stable" depuis longtemps... c'est un peu comme si tu disais qu'un concorde vole moins vite qu'un biplan parce que le dit concorde n'est pas encore complètement assemblé...
Si si, totalement. Linux dit "la licence vous permet de changer le scheduler, la VM, ... et d'en faire ce que vous voulez", mais n'en donne pas vraiment la possibilité pratique, soit à cause des effets de bord (on se rappellera tous l'épisode du noyau 2.4, où on avait le choix entre plusieurs VMs, mais où certains filesystems ne marchaient qu'avec certaines VMs, ...), soit parce que changer le noyau est une tache difficile, qui nécessite d'être root, et souvent de rebooter la machine (lorsqu'on touche au scheduler ou à la VM). Donc c'est bien le même genre de différences.