>>Les micros noyau, ca pue
>Ca c'est de l'argumentation ! Chapeau !
L'argumentation vient après. On t'a pas appris quand tu étais petit qu'il fallait commencer les paragraphes avec l'idée principale est l'argumenter après.
Le développement Hurd a été (presque)
complètement stoppé pendant des a
nnées, c'est 1999 que Marcus l'a relancé.
Justement ca montre bien que les micros noyaux rendent la conception plus difficile. Je ne pense pas que les développeurs HURD soient des brels, alors s'ils se sont découragés c'est bien que ca devait etre difficile.
Et crois-moi, je ne dis pas ça pour être méchant, vu que ce genre d'arguments je les sortais il y a quelques mois avant que je ne me renseigne vraiment sur la question (j'ai un peu honte de moi maintenant mais bon... errare humanum est)
Et oh, faut pas etre gentil comme ca, une réputation de trolleur ca ce travail ;)
Le Hurd n'est pas optimisé pour l'instant. Les développeurs savent où sont les principales lacunes, savent comment y remédier, mais ce n'est pas la priorité
La performance n'est pas une priorité, je crois réver. La performance devrait toujours etre une priorité.
Tu as lu tout ce que Manuel Menal et moi (entre autres) avons dit sur les possibilités du Hurd ? Comment tu fais le translator FTP + Hostmux sous Linux ? Ou le générateur de fortune ? Ou le serveur Apache qui n'a jamais besoin des droits root pou binder le port 80 ? Ou le serveur FTP non anonyme qui n'est pas suidé root ? Et le fait qu'un bug dans un module fasse cracher la totalité du système ? Alors relis tout ce qu'on a dit sur cette page avant de sortir des phrases toutes faites comme ça.
Ces fonctionnalités sont interessantes au niveau de la sécurité et du développement, mais bon je préfère un système ou l'on prend plus de risque et on l'on favorise avant tout les performances. De la même facon je préfère coder en C qu'en Java. Certes en java il y a un demi milliards de mécanismes pour prendre des précautions qui n'existe pas en C. Un code C a ainsi beaucoup plus de chance de planter à l'exécution qu'un code Java. Mais il est aussi beaucoup plus rapide (Je sais je n'aurais pas du prendre l'exemple de Java car la lenteur est principalement du à la vm, mais j'ai assez peu d'expérience avec le C++). Et les tests ca existent. La communauté Linux jouent sur la rapidité de développement et le feed back rapide des problèmes pour avoir un système sur et sécurisé. Je préfère cette approche que l'approche : on prend énormément de précaution et on optient une chute de performances.
Quand à la personnalité de RMS, déjà je ne suis pas du tout d'accord avec ton jugement sur lui, et en plus je ne vois pas ce qu'il a à voir que le Hurd.
Tu ne vois pas ce qu'il a avoir avec le Hurd !!!????!!?!. Le système GNU ca te dit qqchose ? Le Hurd est le noyau officiel du système, pas Linux. Et Stallman est bien verreux que Linux (ou Linus si tu préfère) lui ait piqué la chandelle : les messieurs tout le monde dans la rue connaissent moins stallman que Linus.
[^] # Re: RMS est mort, vive Linus
Posté par Cyril Chevrot . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à -1.
>>Les micros noyau, ca pue
>Ca c'est de l'argumentation ! Chapeau !
L'argumentation vient après. On t'a pas appris quand tu étais petit qu'il fallait commencer les paragraphes avec l'idée principale est l'argumenter après.
Le développement Hurd a été (presque)
complètement stoppé pendant des a
nnées, c'est 1999 que Marcus l'a relancé.
Justement ca montre bien que les micros noyaux rendent la conception plus difficile. Je ne pense pas que les développeurs HURD soient des brels, alors s'ils se sont découragés c'est bien que ca devait etre difficile.
Et crois-moi, je ne dis pas ça pour être méchant, vu que ce genre d'arguments je les sortais il y a quelques mois avant que je ne me renseigne vraiment sur la question (j'ai un peu honte de moi maintenant mais bon... errare humanum est)
Et oh, faut pas etre gentil comme ca, une réputation de trolleur ca ce travail ;)
Le Hurd n'est pas optimisé pour l'instant. Les développeurs savent où sont les principales lacunes, savent comment y remédier, mais ce n'est pas la priorité
La performance n'est pas une priorité, je crois réver. La performance devrait toujours etre une priorité.
Tu as lu tout ce que Manuel Menal et moi (entre autres) avons dit sur les possibilités du Hurd ? Comment tu fais le translator FTP + Hostmux sous Linux ? Ou le générateur de fortune ? Ou le serveur Apache qui n'a jamais besoin des droits root pou binder le port 80 ? Ou le serveur FTP non anonyme qui n'est pas suidé root ? Et le fait qu'un bug dans un module fasse cracher la totalité du système ? Alors relis tout ce qu'on a dit sur cette page avant de sortir des phrases toutes faites comme ça.
Ces fonctionnalités sont interessantes au niveau de la sécurité et du développement, mais bon je préfère un système ou l'on prend plus de risque et on l'on favorise avant tout les performances. De la même facon je préfère coder en C qu'en Java. Certes en java il y a un demi milliards de mécanismes pour prendre des précautions qui n'existe pas en C. Un code C a ainsi beaucoup plus de chance de planter à l'exécution qu'un code Java. Mais il est aussi beaucoup plus rapide (Je sais je n'aurais pas du prendre l'exemple de Java car la lenteur est principalement du à la vm, mais j'ai assez peu d'expérience avec le C++). Et les tests ca existent. La communauté Linux jouent sur la rapidité de développement et le feed back rapide des problèmes pour avoir un système sur et sécurisé. Je préfère cette approche que l'approche : on prend énormément de précaution et on optient une chute de performances.
Quand à la personnalité de RMS, déjà je ne suis pas du tout d'accord avec ton jugement sur lui, et en plus je ne vois pas ce qu'il a à voir que le Hurd.
Tu ne vois pas ce qu'il a avoir avec le Hurd !!!????!!?!. Le système GNU ca te dit qqchose ? Le Hurd est le noyau officiel du système, pas Linux. Et Stallman est bien verreux que Linux (ou Linus si tu préfère) lui ait piqué la chandelle : les messieurs tout le monde dans la rue connaissent moins stallman que Linus.