Debian possède ENFIN un noyau entièrement libre...

Le Tue, 21 Dec 2010 17:43:11 +0100
crouic <lacigale@no-log.org> a écrit :

Le 21/12/2010 15:01, Yliur a écrit :
>
> Oui, il faudrait qu'ils finissent par se fixer un peu, pour se
> concentrer sur le reste :) . Ceci dit le reste avance quand même,
> malgré les changements de choix du micronoyau. Je ne sais pas lequel
> est utilisé dans les versions qui tournent actuellement d'ailleurs.
>

J'ai lu de la doc traduite ici:
http://hurdfr.org/

Mais je ne trouve pas d'infos sur leur communication avec
l'association officielle. Apparemment leur dépôt est différent, alors
quid de la méthode ?

Déjà il n'y a pas l'air d'avoir grand chose de postérieur à 2006.
Peut-être essayer de les contacter sur la page de contact du site ?
A moins qu'il faille remonter ça ailleurs, si plus personne n'y
travaille. Remarque qu'il se pourrait que quelqu'un ne soit pas tout à
fait mort derrière : il y a un bandeau de la Quadrature du net sur la
page principale :) . Tiens-moi au courant si tu arrives à contacter
quelqu'un (ou même si ça échoue).

Je ne comprend pas pourquoi la traduction (voire la version
originale) n'emploie pas le terme de driver/pilote pour les
translators/traducteurs, puisqu'ils sont des serveurs servant à ça.
Ou alors j'ai rien compris ^^

?
Là il faut faire appel à un plus grand spécialiste des
(micro-)noyaux, c'est encore légèrement flou :) . Demandons à JKB à
tout hasard...

Sinon les traducteurs ne sont pas forcément des pilotes pour le
matériel, ils servent à représenter quelque chose sous la forme d'un
système de fichier (si je ne dis pas de bêtises). Par exemple on peut
avoir un traducteur représentant l'arbre des discussions de ce groupe
sous forme d'un ensemble de fichiers/répertoire.

D'ailleurs je ne suis pas sûr que les pilotes du matériel soient
gérés par des traducteurs. Si j'ai bien compris ce sont des serveurs,
mais ils ne représentent pas forcément d'information sous forme de
fichiers/répertoires.

Il faudrait de beaux schémas pour avoir une vue globale, par exemple
avec l'interface kernel/hurd, les ports en forme de systèmes de
fichiers, tout ça :)

Oui :) .

Comme ça m'intéresse aussi, je veux bien participer ou au moins voir le
résultat. Tiens-moi au courant. Et si quelqu'un a des pistes pour
commencer, il est le bienvenu :) .

JKB <jkb@koenigsberg.invalid> wrote:

Qu'est-ce que tu as essayé sur Pistachio ? Si c'est un L4-Linux,

Oui, j'ai essayé des Linux sur micronoyau L4. Et de fait je te concède
que les vieux Linux sur micronoyau Mach étaient plus calamiteux.

Soit tu admets que Mach n'est pas un micronoyau, soit il faudrait

que tu admettes de FreeBSD en est un. Il y a comme quelque chose qui
coince dans le raisonnement.

Je pense que Mach n'est que de très loin un micronoyau, et Mac OS X
encore moins. Windows NT a été conçu au départ comme micronoyau, mais
cette conception s'est complètement diluée au cours du temps.
Simplement plus grand monde ne croit aux micronoyaux. FreeBSD n'a pris
de mach que le système de mémoire virtuelle.

> Pour ce qui est des
> fonctionnalités exotiques dont tu sembles être friand, tu devrais quand
> même finir de te rendre compte que personne d'autre que toi n'a ces
> problèmes, parceque tout le monde utilise les fonctionnalités les plus
> usuelles et *se démerde avec*.

Je suis au regret de te dire que l'absence de sémaphores anonymes
sous MacOS X pose un tas de problèmes vu le nom

Moi je pense qu'on a *toujours* intérêt à utiliser le plus petit
multiple commun et les choses les plus simples, et qu'il y a toujours
moyen de résoudre les problèmes dans cette philosophie, avec un minimum
d'ingéniosité. Dans le cas de Mac OS X, il est possible qu'il soit plus
intéressant d'utiliser des techniques "mach" pour communiquer entre
différents processus, telles que les files de messages. Je ne sais pas
comment ils font chez Apple mais le résultat actuel est assez
convaincant. Perso j'ai souvent vu des déboires à cause des sémaphores,
ne serait-ce que des sémaphores qui restent, polluant le système après
un crash du programme (firefox, postgres, etc.) et nécessitent un
nettoyage avec ipcrm. J'ai aussi eu des problèmes pour faire tourner
postgres dans une jail, à cause des sémaphores, bref ces objets
me débectent. En fait on se porte aussi bien d' utiliser un seul
programme multithreadé.


--

Michel TALON

Michel Talon a écrit :

En fait on se porte aussi bien d' utiliser un seul programme

multithreadé.

Et avec quoi tu synchronise tes threads ? Au hasard, des sémaphores
anonymes ?..

--
Toxico Nimbus

Michel Talon a écrit :

Je suis au regret de te dire que l'absence de sémaphores
anonymes sous MacOS X pose un tas de problèmes vu le nom

Perso j'ai souvent vu des déboires à cause des sémaphores,
ne serait-ce que des sémaphores qui restent, polluant le système après
un crash du programme (firefox, postgres, etc.) et nécessitent un
nettoyage avec ipcrm.

Bin forcément, comme les sémaphores anonymes ne sont pas gérés, tout le
monde est obligé de remplacer les sem_init() par des sem_open(), sauf
qu'il devient très difficile alors de refermer les sémaphores alors que
ce n'était pas forcément prévu dans le code original.

--
Toxico Nimbus

Toxico Nimbus <ToxN@free.fr> wrote:

Michel Talon a écrit :

En fait on se porte aussi bien d' utiliser un seul programme
> multithreadé.

Et avec quoi tu synchronise tes threads ? Au hasard, des sémaphores
anonymes ?..

Au hasard des mutex, des variables de condition, etc.



--

Michel TALON

Le Tue, 21 Dec 2010 21:30:22 +0000 (UTC),
Michel Talon <talon@lpthe.jussieu.fr> écrivait :

JKB <jkb@koenigsberg.invalid> wrote:

Qu'est-ce que tu as essayé sur Pistachio ? Si c'est un L4-Linux,

Oui, j'ai essayé des Linux sur micronoyau L4. Et de fait je te concède
que les vieux Linux sur micronoyau Mach étaient plus calamiteux.

Soit tu admets que Mach n'est pas un micronoyau, soit il faudrait

que tu admettes de FreeBSD en est un. Il y a comme quelque chose qui
coince dans le raisonnement.

Je pense que Mach n'est que de très loin un micronoyau, et Mac OS X
encore moins.

C'est bien, nous sommes au moins d'accord sur ce point.
Personnellement, j'ai des souvenirs émus du port de VMS sur i386, un
truc qui s'appelait VMS-O-Mach, qui fonctionnait, mais qui avait des
performances calamiteuses. Sans parler de MkLinux qui est sur ce
point définitivement hors concours.

Windows NT a été conçu au départ comme micronoyau, mais
cette conception s'est complètement diluée au cours du temps.
Simplement plus grand monde ne croit aux micronoyaux. FreeBSD n'a pris
de mach que le système de mémoire virtuelle.

J'étais assez opposé aux micronoyaux (et surtout aux noyaux hydrides
comme XNU et Mach) jusqu'à ce que je sois obligé de m'y mettre.
Aujourd'hui, l'un des seuls micronoyaux efficaces est L4 parce qu'il
est synchrone. Mach utilise des mécanismes asynchrones pour faire
ses communications interprocessus, ce qui pénalise lourdement les
performances finales.

En ce sens, utiliser un L4 avec un OS écrit par dessus pour ce
micronoyau plutôt que de porter un OS comme Linux sur un micronoyau
est une solution qui mérite d'être regardée de près.

> Pour ce qui est des
> fonctionnalités exotiques dont tu sembles être friand, tu devrais quand
> même finir de te rendre compte que personne d'autre que toi n'a ces
> problèmes, parceque tout le monde utilise les fonctionnalités les plus
> usuelles et *se démerde avec*.

Je suis au regret de te dire que l'absence de sémaphores anonymes
sous MacOS X pose un tas de problèmes vu le nom

Moi je pense qu'on a *toujours* intérêt à utiliser le plus petit
multiple commun et les choses les plus simples, et qu'il y a toujours
moyen de résoudre les problèmes dans cette philosophie, avec un minimum
d'ingéniosité.

Les sémaphores sont des choses de base.

Dans le cas de Mac OS X, il est possible qu'il soit plus
intéressant d'utiliser des techniques "mach" pour communiquer entre
différents processus, telles que les files de messages. Je ne sais pas
comment ils font chez Apple mais le résultat actuel est assez
convaincant. Perso j'ai souvent vu des déboires à cause des sémaphores,
ne serait-ce que des sémaphores qui restent, polluant le système après
un crash du programme (firefox, postgres, etc.) et nécessitent un
nettoyage avec ipcrm.

C'est bien le problème. Tu aurais des sémaphores anonymes voire
simplement POSIX, tu n'aurais pas les problèmes des sémaphores SysV
et le coup des ipcrm. C'est parce que des systèmes comme MacOS X
(mais ce n'est pas le seul) sont infoutus d'implanter des choses de
bases que tu te retrouves avec un plus petit multiple commun comme
tu l'as appelé et que ça pose des problèmes. D'ailleurs, rien ne
garantit l'unicité des IPC SysV, ce qui est assez amusant.

J'ai aussi eu des problèmes pour faire tourner
postgres dans une jail, à cause des sémaphores, bref ces objets
me débectent. En fait on se porte aussi bien d' utiliser un seul
programme multithreadé.

Je suppose qu'il fallait lire : on se porte aussi bien en
n'utilisant pas un seul programme multithreadé. Très bien, on ne
doit pas utiliser les mêmes volumes de données. En programmant
subtilement, on peut économiser beaucoup de mémoire. Et ça passe
plutôt par des pthread_create() que par des fork(). Le sémaphore est
un système de base. Le fait que la sémantique SysV est moisie n'en
fait pas une mauvaise chose.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

Le Wed, 22 Dec 2010 13:11:56 +0000 (UTC),
Michel Talon <talon@lpthe.jussieu.fr> écrivait :

Toxico Nimbus <ToxN@free.fr> wrote:

Michel Talon a écrit :

En fait on se porte aussi bien d' utiliser un seul programme
> multithreadé.

Et avec quoi tu synchronise tes threads ? Au hasard, des sémaphores
anonymes ?..

Au hasard des mutex, des variables de condition, etc.

Avec deux threads, ça peut encore passer. Mais lorsque tu as
plusieurs centaines de threads de calculs, il faut quelque chose de
plus subtil que des mutexes sous peine de sous utilisation de tes
processeurs.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

Toxico Nimbus <ToxN@free.fr> wrote:

Michel Talon a écrit :

>> Je suis au regret de te dire que l'absence de sémaphores
>> anonymes sous MacOS X pose un tas de problèmes vu le nom
>
> Perso j'ai souvent vu des déboires à cause des sémaphores,
> ne serait-ce que des sémaphores qui restent, polluant le système après
> un crash du programme (firefox, postgres, etc.) et nécessitent un
> nettoyage avec ipcrm.

Bin forcément, comme les sémaphores anonymes ne sont pas gérés, tout le
monde est obligé de remplacer les sem_init() par des sem_open(), sauf
qu'il devient très difficile alors de refermer les sémaphores alors que
ce n'était pas forcément prévu dans le code original.

Je viens de vérifier, les sémaphores anonymes partagés entre plusieurs
processus n'existent pas sous FreeBSD 8.1 il faut aller à 9-CURRENT pour
les trouver. Autant dire que voilà une fonctionnalité qui est largement
répandue (et donc nécessaire!) parmi les systèmes Unix.




--

Michel TALON

Le 22 Dec 2010 12:00:52 GMT,
Toxico Nimbus <ToxN@free.fr> écrivait :

Michel Talon a écrit :

Je suis au regret de te dire que l'absence de sémaphores
anonymes sous MacOS X pose un tas de problèmes vu le nom

Perso j'ai souvent vu des déboires à cause des sémaphores,
ne serait-ce que des sémaphores qui restent, polluant le système après
un crash du programme (firefox, postgres, etc.) et nécessitent un
nettoyage avec ipcrm.

Bin forcément, comme les sémaphores anonymes ne sont pas gérés, tout le
monde est obligé de remplacer les sem_init() par des sem_open(), sauf
qu'il devient très difficile alors de refermer les sémaphores alors que
ce n'était pas forcément prévu dans le code original.

Ce n'est pas grave. Un sémaphore ouvert par sem_open() est nommé et
sa gestion est claire. Il apparaît dans le système de fichier.
Le problème vient des saletés générées par shmget().

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

Le Wed, 22 Dec 2010 13:34:05 +0000 (UTC),
Michel Talon <talon@lpthe.jussieu.fr> écrivait :

Toxico Nimbus <ToxN@free.fr> wrote:

Michel Talon a écrit :

>> Je suis au regret de te dire que l'absence de sémaphores
>> anonymes sous MacOS X pose un tas de problèmes vu le nom
>
> Perso j'ai souvent vu des déboires à cause des sémaphores,
> ne serait-ce que des sémaphores qui restent, polluant le système après
> un crash du programme (firefox, postgres, etc.) et nécessitent un
> nettoyage avec ipcrm.

Bin forcément, comme les sémaphores anonymes ne sont pas gérés, tout le
monde est obligé de remplacer les sem_init() par des sem_open(), sauf
qu'il devient très difficile alors de refermer les sémaphores alors que
ce n'était pas forcément prévu dans le code original.

Je viens de vérifier, les sémaphores anonymes partagés entre plusieurs
processus n'existent pas sous FreeBSD 8.1 il faut aller à 9-CURRENT pour
les trouver.

Et simplement partagé en threads d'un _même_ processus ? Tous les
codes multithreadés en sont plein (et c'est dans FreeBSD au moins
depuis la version 7.0 parce que j'ai commencé à toucher à FreeBSD à
cette version et que ça fonctionnait).

Autant dire que voilà une fonctionnalité qui est largement
répandue (et donc nécessaire!) parmi les systèmes Unix.

Ben oui, c'est répandu, utile et nécessaire. Quant à FreeBSD, il a
aussi fallu attendre 8.1 pour avoir un siginfo_t qui soit rempli
avec un truc cohérent. Pourtant, je peux te dire que c'est utilisé.
C'est même tellement utilisé que les ports pour FreeBSD sont plein
de patches pour contourner le problème dans tous les softs qui
utilisent cette fonctionnalité de base. Ce n'est pas parce que tu ne
vois pas l'utilité d'une fonction ou d'une autre que ce n'est pas
utile.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr