C'est pour l'instant plus une curiosité qu'un système utilisable, mais avec cette distribution, l'installation de Hurd devient (enfin!) relativement accessible.
Aller plus loin
- Debian GNU/Hurd (4 clics)
- G1, infos pour l'installation (3 clics)
- FTP principal (3 clics)
- FTP miroir (2 clics)
- Source : OSNews (2 clics)
# essai...
Posté par istyar . Évalué à -10.
[^] # Re: essai...
Posté par Anonyme . Évalué à -10.
[^] # Re: essai...
Posté par istyar . Évalué à -10.
[^] # Re: essai...
Posté par Anonyme . Évalué à -9.
[^] # Re: essai...
Posté par Anonyme . Évalué à -8.
ça devient de plus en plus rare...
[^] # Re: essai...
Posté par Ramón Perez (site web personnel) . Évalué à -7.
Ouais, t'as raison, c'est cool.
[^] # Re: essai...
Posté par Anonyme . Évalué à -8.
[^] # Re: essai...
Posté par Anonyme . Évalué à -6.
[^] # Re: essai...
Posté par Anonyme . Évalué à -1.
[^] # Re: essai...
Posté par Jean-Pierre Heraton . Évalué à 1.
Bon d'accord je n'y avais passé que quelques heures.
# La "Task List " est plustôt impressionnante
Posté par Wi][ish . Évalué à 10.
Je ne pensais pas qu'il manquait autant de choses : pas de character device (donc pas de X), pas de ppp, pas de POSIX Thread... la liste est bien longue.
Mais le moins qu'on puisse dire c'est que les développeurs semblent très bien organisés et méthodiques.
J'ai vraiment hâte que ce projet avance un peu pour voir ce que donne le noyau Gnu Mach en terme de performances.
[^] # Re: La "Task List " est plustôt impressionnante
Posté par Frédéric RISS . Évalué à 10.
[^] # Re: La "Task List " est plustôt impressionnante
Posté par zen . Évalué à 10.
Un support ppp est présent mais il est encore buggé. Le support des pthread est sans doute ce qui manque le plus sur le HURD pour porter plus d'appli.
[^] # Re: La "Task List " est plustôt impressionnante
Posté par Wi][ish . Évalué à 8.
Effectivement, il semble qu'il y ait un support "experimental" des characters device.
ftp://alpha.gnu.org/gnu/hurd/contrib/marcus/gnumach-char/(...)
Quelqu'un a-t-il essayé X sur Hurd ?
Est-ce du framebuffer ?
[^] # Re: La "Task List " est plustôt impressionnante
Posté par manu manu sauvage . Évalué à 10.
> n'est pas au point et donc pas question de faire
> tourner Gnome ou KDE.
Pour information, KDE n'utilise pas les threads,
mais est base sur une approche processus (donc
fork()). Pour Gnome je ne sais pas, donc je ne
me risque pas a dire de betise.
mms.
[^] # Re: La "Task List " est plustôt impressionnante
Posté par Nicolas Roard (site web personnel) . Évalué à 8.
si je me souviens bien, la politique de KDE
en ce moment c'est "utilisez les threads" pour
la prochaine version de KDE ...
[^] # Re: La "Task List " est plustôt impressionnante
Posté par Sebastien . Évalué à 2.
ps : compiler KDE 3 alpha1 avec QT 3, ça se fait pas tout seul, il faut bien bidouiller, mais c'est bon quand même :p
[^] # Re: La "Task List " est plustôt impressionnante
Posté par Wawet76 (site web personnel) . Évalué à 10.
En gros le but est de faire un noyau extrement modulable, avec la possibilité pour les utilisateurs de charger des "modules" (server) qui pourrons crouter sans embêter les autres.
Ce qui parrait très sympatique par contre, c'est la mécanique de "translator" qui doit permettre de très simplement monter un site ftp sur le filesystem ou bien crypter ou compresser des fichiers à la volée.
De la lecture sur le Hurd pour les transports en communs :
http://www.gnu.org/software/hurd/hurd-paper.html(...)
http://www.gnu.org/software/hurd/hurd-talk.html(...)
(le premier m'a fait rater une gare de RER il y a deux ans vers 1h30 du matin. Resultat : 2 heures d'attente dehors en hivers avant d'en avoir un autre dans l'autre sens. Heureusement que j'avais de la lecture)
[^] # Re: La "Task List " est plustôt impressionnante
Posté par Jerome Demeyer . Évalué à 9.
Ce qui m'étonne, c'est que des distrib comme mkLinux étaient basées sur un noyau Mach, mais bon c'était un noyau mach qui ne lance qu'un seul serveur : un noyau linux... mais MacOS-X lui-même n'est t'il pas basé sur un noyau Mach ? J'aimerais savoir : comment se fait t'il qu'il soit si peu avancé ? (le noyau Mach, pas MacOSX...)
Sinon, pour ceux qui veulent tester, les packages Debian sont juste à recompiler : apt-get source -b <pkg> à la place de apt-get install <pkg>.
*Translator : (fr. traducteur) un daemon qui permet d'avoir un interface type file-system est un translator. Les translators permettent d'accéder aux partitions, CD, nfs et meme de transformer une connexion ftp en partition locale, par exemple.
[^] # Re: La "Task List " est plustôt impressionnante
Posté par Wawet76 (site web personnel) . Évalué à 7.
The Hurd est passé sur un noyau GNUMach qui n'est pas forcement au même état d'avancement que ceux de MacOSX ou mkLinux.
[^] # Re: La "Task List " est plustôt impressionnante
Posté par Jerome Demeyer . Évalué à 10.
Hurd m'intrigue... j'ai l'impression que c'est un fantasme d'ingénieurs informaticiens (interdiction de rire, le terme à été pourri il y a peu) : Hurd propose une plateforme qui ne reboote jamais...un micronoyau ne s'occupant pas de grand chose, seuls les services sont à gerer ?
Si Hurd arrive à ses fins, il fera plus mal aux Unix que linux, mais bon ca sera d'ici 4 à 6 ans, le temps qu'il soit terminé, stabilisé, emancipé et surtout promu.
--
Vivement demain !
[^] # Re: La "Task List " est plustôt impressionnante
Posté par zen . Évalué à 9.
Des personnes veulent aussi porter le hurd sur L4 ( cf http://mail.gnu.org/mailman/listinfo/l4-hurd(...) et http://www.l4ka.org/(...) ).
Le noyau L4 aurait pour avantage d'être plus activement développer que mach. Et L4 est déjà porté sur plusieurs plateformes.
[^] # Re: La "Task List " est plustôt impressionnante
Posté par Yann Droneaud (site web personnel) . Évalué à 7.
il y a un projet, ou plutot une idee de porte Hurd sur d'autre micro noyaux et en particulier L4.
Mais Hurd a ete depuis le debut developper pour Mach, il n'est pas vraiment portable.
GNUmach, c'est Mach 4 du CMU (en gros) adopté par le projet GNU.
Le probleme de GNUmach c'est qu'il est out of date
depuis le debut. Il est uniquement utilisable sur plateforme x86 (bien que le noyau Mach original a été porté sur la pluparts des architectures). Il ne supporte quasiment aucun materiel recent
(bien qu'une implementation de GNUmach utilisant
l'oskit existe, ce n'est pas encore la panacé mais c'est une voie a suivre),
et ce qui me parait le plus grave pour un
micro noyau (pour ma definition personnelle, et je ne parle pas de sa taille mais des fonctionnalités) c'est qu'il embarque en dur tout
ses drivers, pas de kernel module, ni la possibilité d'avoir des drivers tournant comme une tache en mode pseudo utilisateur (comme les autres serveurs de Hurd).
Le principe du micro noyau est excellent (quoiqu'en pense Linus), associé au principe du multi serveurs (comme Hurd, pas comme les systemes qui utilisaient un unique serveur emulateur d'unix), ca me parait etre la solution la plus pertinente, souple, fiable, etc..., mais cette solution demande beaucoup de reflexion et une rigueur extreme.
Le seul projet presque de ce type est a ma connaissance Amoeba.
Si avec les ISOs de la Debian Hurd, le systeme GNU
peut gagner plus de developpeur ce seras parfait
mais il ne faut pas que ca devienne l'anarchie comme Linux ...
[^] # Re: La "Task List " est plustôt impressionnante
Posté par Yohann (site web personnel) . Évalué à 6.
AMHA aussi d'ailleurs, toutes c'est figures de style bouffe BEAUCOUP de CPU, c'est un peu le probleme. Mon noyeau j'aime k'il bosse, pas k'il fasse de politesse...
Je me trompe probablement mais perdre tout ce temps, pour les quelques fonctionnalite apportees c'est vraiment cher paye le mount -t FTP...
_mais il ne faut pas que ca devienne l'anarchie comme Linux_
peut tu detailler ce point parce que la, je ne te suis pas (sans mechancete aucune)
[^] # Re: La "Task List " est plustôt impressionnante
Posté par Étienne . Évalué à 2.
Il me semble que c'est http://sourceforge.net/projects/ftpfs/(...)
ca permet de faire un
$ mount -t ftpfs ...
[^] # Re: La "Task List " est plustôt impressionnante
Posté par Yann Droneaud (site web personnel) . Évalué à 7.
de continuité, de stabilité dans le developpement:
o changements d'api,
o tout les drivers integré dans la meme arboresence
o les differentes branches
Au niveau performance, c'est sur que l'on peu se poser des questions,
voici encore la mon point de vue:
- un kernel monolithique super optimiseé (voire meme ecrit en assembleur ;)
Il sera forcement rapide (le code), mais pas gerable a long terme, presque immodifiable
et a terme les performances seront diminué car
le systeme deviendra un gros melange de tache intercroise pour pouvoir assuer toutes les nouvelles fonction.
- micro noyau et des serveurs: lenteur du a la commutation des taches, mais les elements sont
mieux concus, mieux reparti, le systeme peut etre plus scalable. Il sera plus facilement evolutif
et meme plus simple a comprendre
De plus je pense que le parametre vitesse, est un peu obsolete, compte tenu des architectures modernes.
[^] # Re: La "Task List " est plustôt impressionnante
Posté par Anonyme . Évalué à 3.
Ah bah bravo la portabilité ;)
Bon, plus sérieusement, il y a quand même un avantage non négligeable au micro-noyau, c'est qu'on peut remplacer à chaud les serveurs qui tournent dessus. Ce qui fait qu'on peut patcher un OS sans avoir à rebooter... (tant que ce n'est pas le micro-noyau qu'il faut patcher)
Sur des gros serveurs qui peuvent mettre plusieurs dizaines de minutes pour booter (si, si, ça existe), ça peut être très pratique...
[^] # Re: La "Task List " est plustôt impressionnante
Posté par Anonyme . Évalué à 1.
de continuité, de stabilité dans le developpement:
ben ce n'est pas de l'anarchie ça, au contraire, c'est de la désorganisation...
[^] # Re: La "Task List " est plustôt impressionnante
Posté par Jak . Évalué à 1.
Non, plutôt orienté recherche universitaire.
[^] # Re: La "Task List " est plustôt impressionnante
Posté par Paerro Trime . Évalué à 1.
En gros (simplifions, simplifions, ...) MkLinux avait un seul serveur qui émulait un linux. MacOS X a un seul serveur qui émule un FreeBSD. Et Hurd a tout plein de serveurs qui font , euh, tient ça se complique là, je crois que je vais aller relire la doc...
# Une FAQ sur Hurd en fr
Posté par LynXX . Évalué à 10.
http://www.multimania.com/nek/os/hurd.htm(...)
-1 parce que ca fait pas avancer le schmilblik :)
[^] # Re: Une FAQ sur Hurd en fr
Posté par zen . Évalué à 10.
http://www.hurd-fr.org/docfr.php(...)
[^] # Re: Une FAQ sur Hurd en fr
Posté par Wi][ish . Évalué à 3.
Non, au contraire la page est très instructive.
La section 4 (le net est à vous) laisse rêveur :
"Les noeuds du reseau apparaissent comme des sous-repertoires dans votre arborescence..."
"Vous savez creer un lien sur un fichier? Vous pouvez creer de la meme maniere un lien sur le serveur du Centre National de Mycologie Appliquee du Djibouti."
[^] # Re: Une FAQ sur Hurd en fr
Posté par Yusei (Mastodon) . Évalué à 6.
Vous avez frissoné en regardant Emacs, vous trrrremblerrrez en essayant Stallman II, le Retour (dit The Hurd)
Euh, le vi des systèmes d'exploitation c'est quoi ?
(oui bon ok, -1)
[^] # Re: Une FAQ sur Hurd en fr
Posté par Anonyme . Évalué à -9.
C'est DOS ?
[^] # Re: Une FAQ sur Hurd en fr
Posté par Anonyme . Évalué à -5.
Tous à vos GNU, ca va guilder grave !
# C'EST PAS LA MANDRAKE
Posté par Anonyme . Évalué à -10.
alors que notre distrib nationale, c 18 distribs en un an
[^] # SI DEBIAN HURD== LINUX MANDRAKE
Posté par Anonyme . Évalué à -10.
[^] # Re: SI DEBIAN HURD== LINUX MANDRAKE
Posté par Yohann (site web personnel) . Évalué à -3.
# Et sinon?
Posté par Fabien (site web personnel) . Évalué à -4.
J'ai un 486 avec 200Mo de dd (ram ?, cpu ? ), est ce que ça passe?
Parce que c'est bien beau de vouloir le faire tester, mais a la fin je suis en panne de machines moi.
[^] # Re: Et sinon?
Posté par Anonyme . Évalué à -6.
[^] # Re: Et sinon?
Posté par Anonyme . Évalué à -2.
[^] # Re: Et sinon?
Posté par Anonyme . Évalué à -1.
[^] # Re: Et sinon?
Posté par Ramón Perez (site web personnel) . Évalué à -3.
[^] # Re: Et sinon?
Posté par Benjamin Drieu (site web personnel) . Évalué à 3.
Ceci-dit, ils cherchent des contributeurs pour porter celle de Linux. ;-)
# POO ?
Posté par Bruno Adele (site web personnel) . Évalué à 2.
Le C n'est pas orienté objet ? à moins que j'ai raté une étape ?
[^] # Re: POO ?
Posté par Wawet76 (site web personnel) . Évalué à 10.
Les langages dit "objets" ou "à objets" apportent une syntaxe et des mécaniques qui favorisent la conception objet.
Voili voilou.
[^] # Re: POO ?
Posté par Annah C. Hue (site web personnel) . Évalué à 7.
[^] # prem's
Posté par Wawet76 (site web personnel) . Évalué à -7.
Nananair-heu !
[^] # Re: prem's
Posté par Annah C. Hue (site web personnel) . Évalué à -2.
[^] # Re: POO ?
Posté par Bruno Adele (site web personnel) . Évalué à 2.
[^] # Re: POO ?
Posté par G. R. (site web personnel) . Évalué à 8.
http://ldeniau.home.cern.ch/ldeniau/html/oopc/oopc.html(...)
Il s'agit d'une bibliothèque qui permet de programmer OO en C.
L'intérêt est de le faire sur des plateformes qui ne peuvent supporter un compilateur C++
HTH
[^] # Re: POO ?
Posté par gui_ . Évalué à 2.
[^] # Re: POO ?
Posté par Gaël Le Mignot . Évalué à 5.
En gros, pour l'héritage, en Gtk/GObject c'est fait ainsi:
struct _bar_t
{
struct _foo_t foo;
...
}
Et tu as 'bar' qui hérite de 'foo'...
Et après tu peux utiliser les fonctions de plus bas niveau (par exemple en Gtk tu peux faire un
gtk_widget_show() sur tous les widget, que ce soit un GtkButton ou un GtkFileSelectionDialog)
[^] # Re: POO ?
Posté par Gnurou (site web personnel) . Évalué à 1.
Bien evidemment, il faut faire du forcage de type quand tu appelle les functions s'appliquant à _foo_t avec _bar_t. Et en cas d'héritage multiple, tu n'as pas d'autre choix que de faire un peu d'arithmétique de pointeur... Mais ça marche très bien. A moins que quelqu'un ne connaisse une autre solution?
[^] # Re: POO ?
Posté par Bruno Adele (site web personnel) . Évalué à 1.
struct Object2
{
struct Object1 // qui lui meme contient ObjectAbstract ?;
...
}
et
struct Object1
{
struct ObjectAbstract;
...
}
Ca veux donc dire que les structures peuvent avoir des fonctions ou procedures (Méthode) ? Si ce le cas, je ne le savais pas, d'autant plus qu'en C++ il conseille d'utiliser des Classes (Object) par raport aux structures.
Et par exemple si ObjectAbstract à une procedure (méthode) "Run", comment tu l'appelle depuis Object1 ?
[^] # Re: POO ?
Posté par Gnurou (site web personnel) . Évalué à 5.
En ce qui concerne les classes, elles n'existent bien sûr pas en C, mais on peut facilement contourner le problème. En fait ce qui suit n'est que la manière donc le code C++ est interprété par le compilateur.
Disons que tu as une classe A (de mercedes):
class A
{
public:
A();
~A();
Run (int n);
private:
int i;
};
Comment le compilo peut-il traduire cela en C? Tout d'abord on regroupe les données de la classe en une struct (dont le données privées ne sont bien sûr pas accessible, mais ça en C c'est dur à controller):
struct A_struct
{
int i;
}
Et ensuite on écrit l'interface de la classe avec des fonctions C, dont le premier paramètre sera TOUJOURS un pointeur vers la structure dont elles sont l'interface:
/* constructeur et destructeur */
void A_init (struct A_struct * a);
void A_cleanup (struct A_struct * a);
/* Méthodes */
void A_Run (struct A_struct * a, int n);
Evidemment tu dois toi même appeler le constructeur et destructeur manuellement, et toujours passer ta structure aux méthodes de l'interface. Mais j'insiste sur le fait que c'est ainsi que cela se passe en interne. Si tu lances gdb sur un programme C++, tu verras que ça se passe en fait comme cela.
Ensuite, l'héritage... Soit la classe B:
class B : public A
{
....
};
En C on traduira comme Kilobug l'a dit par:
struct B
{
struct A struct_a;
}
Et comme les données en mémoire au début du pointeur de B sont les données de A (car elle a été déclarée au début de B), tu peux appeler A_Run comme ceci:
struct B monB;
A_Run ((A*)&monB, 2);
En faisant un simple forcage de type. Pour l'héritage multiple, comme je l'ai dit plus haut tu peux t'en sortir avec un peu d'arithmétique de pointeurs. C'est bien sûr moins pratique qu'un compilo C++ qui fera le boulot à ta place, mais ca peut être grandement utile et c'est bon à savoir.
Voila, j'espère avoir été clair :)
[^] # Re: POO ?
Posté par Bruno Adele (site web personnel) . Évalué à 1.
>>A_Run ((A*)&monB, 2);
Pas mal cette finte, d'utiliser le meme emplacement pour les pointeurs, ca ressemble un peux au UNION en C++, je supose que c'est ca qu'il utilise d'ailleur.
gnurou, merci pour ton exemple, il me permet de mieux comprendre.
[^] # Re: POO ?
Posté par Pat _ . Évalué à 1.
et il n'y a pas de différence fondamentale entre object et struct, ce n'est qu'une différence de protection par défaut des proprietes et methodes.
[^] # Re: POO ?
Posté par Gnurou (site web personnel) . Évalué à 1.
[^] # Re: POO ?
Posté par Gaël Le Mignot . Évalué à 1.
Si je définis une méthode foo virtuelle dans la classe a, et deux méthodes réelles différentes dans les classes b et c (héritant toutes les deux de a) et une fonction du type:
void bar(class_a *a)
{
a->foo();
}
Le compilo est bien obligé d'avoir des pointers de fonctions pour savoir quelle méthode appeler.
Il y a aussi une autre solution (utilisée dans GObject je crois) qui consiste a avoir une structure 'classe' contenant les pointeurs de fonctions, de l'instancier une fois lors de la création du premier objet d'un type donné. On a ainsi un pointeur vers la classe (donc 4 octets) par objet et non par coupe (méthode, objet).
Cependant, il faut voir que le principal problème des pointeurs de fonctions n'est pas les 4 octets de mémoire, mais le coût CPU. En effet, pour la plupart des processeurs, un 'indirect call' (appel à un pointeur de fonction) est beaucoup plus lent qu'un 'call' avec une adresse constant.
[^] # Re: POO ?
Posté par Gnurou (site web personnel) . Évalué à 1.
Pour les appels à des pointeurs de fonction, je ne pense pas qu'il y ait le moindre surcoût. Après tout en assembleur x86, les fonctions sont appelés par leur adresse, non? Il ne s'agirait donc que du mécanisme naturel.
Ca devient Da Programmers French Page ici... ;)
[^] # Re: POO ?
Posté par Gaël Le Mignot . Évalué à 4.
* Pour les pointers de fonctions, si c'est beaucoup plus coûteux parce que les plupart des processeurs n'arrivent pas à prédire le branchement si l'adresse n'est pas constante, et donc il fait une 'misprediction' qui se solde par un flush du pipeline et un risque de cache-miss... Et tout ça ça coûte TRES cher en terme de perf.
Maintenant je n'ai plus fait d'assembleurs depuis les PII/K6 et donc je ne sais pas trop comment se comportent les processeurs + récents.
[^] # Re: POO ?
Posté par Gnurou (site web personnel) . Évalué à 0.
Pour le système de vtable en C, tu t'y prendrait comment? Ne faudrait-il pas rajouter des macros plein le code pour déterminer si une fonction est virtuelle ou non? Car comme durant la compilation le compilo C++ examine chaque appel de fonction pour savoir s'il doit être virtuel ou pas, il faut mettre un système similaire en place, et je ne vois pas trop comment faire sans noyauter chaque appel de fonction d'un objet avec une macro. Non pas que ce soit inefficace ou très lourd, mais je suis curieux de savoir s'il y a moyen de faire autrement.
[^] # Re: POO ?
Posté par Paerro Trime . Évalué à 2.
[^] # Re: POO ?
Posté par Hodj . Évalué à 4.
[^] # Re: POO ?
Posté par matiasf . Évalué à 3.
Il suffit de consulte la librarie Xt d'X11 pour en être persuadé.
[^] # Re: POO ?
Posté par bleh . Évalué à 2.
Personnellement, il me semble que le choix d'un langage comme le C++ ou le Java serait plus adapté pour faire de la POO. Qui essaierait de faire du café avec une machine à laver ? Pour moi c'est un peu l'équivalent de faire de l'objet en C.
Je ne comprend pas l'acharnement de certain à utiliser le C coute que coute. Chaque langage a ses spécifictés, ses avantages, ses domaines de prédilection autant les utiliser.
Faire du calcul mathématique en POO n'est, par exemple, pas une super bonne idée. A titre d'exemple je rapporte une discussion entre 2 objets.
Pas très efficace. Maintenant, je suppose qu'il y'a une raison au niveau du choix du C comme langage pour Hurd. Moi je la connais pas mais quelqu'un pourrait m'éclairer :-)
[^] # Re: POO ?
Posté par Anonyme . Évalué à 1.
enfin, surtout, le C est plus 'universel'. tu vas toujours tomber sur un compilateur C++ qui ne va pas supporter les namespace/template/RTTI, etc...
[^] # Re: POO ?
Posté par Anonyme . Évalué à 1.
Ca fait toujours plaisir de voir les gens qui melangent les torchons et les serviettes. Le Fortran est un langage pour faire de l'analyse numerique, et non pas pour ecrire un systeme d'exploitation.
[^] # Re: POO ?
Posté par Pat _ . Évalué à 2.
# HURD, successeur de linux?
Posté par Tom Sheldon . Évalué à 9.
Dans 6/8 ans, hurd remplacera peut étre linux...
[^] # Re: HURD, successeur de linux?
Posté par Frederic Logier . Évalué à 2.
La Fondation serait en marche ? :)
-1
[^] # Re: HURD, successeur de linux?
Posté par Anonyme . Évalué à 5.
Comme Seldon, RMS va réduire la période de développement de Hurd de 30000 ans à seulement 1000 ans.
[^] # Re: HURD, successeur de linux?
Posté par Anonyme . Évalué à 0.
Hurd, mais quelle arlésienne ! Hm depuis quand deja que ca frémit dans la soupière ? 8 ans ?
1000 ans c'est optimiste :)
# La G1 n'est pas la premiere...
Posté par Anonyme . Évalué à 5.
Les CDs de la serie F permettaient aussi d'installer Hurd et de l'utiliser. Et je n'ai pas vu d'annonce sur un changement si significatif entre la serie F et la serie G (me trompe-je ?) -
Ronan
[^] # Re: La G1 n'est pas la premiere...
Posté par Anonyme . Évalué à 0.
[^] # Re: La G1 n'est pas la premiere...
Posté par Anonyme . Évalué à 4.
Ca reste du développement, donc la première sera la 1.0, mais celle-ci est la première à "sortir" du cercle des développeurs et passionnés.
# Hurd
Posté par warSheep . Évalué à -1.
[^] # Re: Hurd
Posté par isydor . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.