Le projet n'a pas été abandonné et son développement a au contraire été très actif. Aujourd'hui vient de sortir TUX 2.0. Encore plus rapide que son prédécesseur (avec encore moins de recopies de mémoire), il ajoute des fonctionnalités pour le moins intéressantes : meilleure stabilité, support pour un nombre infini de domaines virtuels et les CGI peuvent être individuellement assignés à tel ou tel processeur sur les systèmes SMP.
Une solution idéale pour les hébergeurs et ceux qui veulent réduire considérablement la charge de leur machine.
Note du modérateur: Et l'url ? :-)
Aller plus loin
- Téléchargement de TUX 2.0 (67 clics)
# url
Posté par ghent . Évalué à 1.
http://www.redhat.com/products/software/ecommerce/tux/(...)
Pas grand chose sur le site.
# url --->Redhat
Posté par Anonyme . Évalué à -1.
Ils sont ou les tar.gz ???
[^] # Re: url --->Redhat
Posté par Pierre Tramo (site web personnel) . Évalué à 1.
# URL
Posté par j . Évalué à 1.
Enfin, la voici :
ftp://ftp.redhat.com/pub/redhat/tux/tux-2.0/(...)
# Bonne approche ?
Posté par pasBill pasGates . Évalué à 1.
On avait le micro-kernel, puis le kernel monolithique, comment on va appeler celui-la ? macrokernel ?
Je me demandes comment ils vont faire pour suivre l'evolution du kernel avec ca dedans car je doutes que Torvalds apprecie d'avoir un serveur web dans le kernel.
A quand Quake3 dans le kernel ? Je suis sur qu'on pourrait gagner un certain nombre de frames de cette maniere.
[^] # Re: Bonne approche ?
Posté par Anonyme . Évalué à 0.
pour une machine qui ne sert que de serveur web, ça ne parait pas idiot.
aucun machine ne sert qu'à jouer à quake, non ? Si c'est le cas, une intégration dans le noyau ne serait pas idiote.
[^] # Re: Bonne approche ?
Posté par pasBill pasGates . Évalué à 1.
Par contre pour les developpeurs, ca revient a avoir un fork du noyau, il faut maintenir les 2 versions en parralele, quand une modif arrive dans le kernel officiel il faut voir si ca n'impacte pas Tux, et si oui, ben il faut modifier Tux pour gerer ca,... c'est vachement dur a maintenir un truc pareil.
Pour moi c'est comme si les roues d'une voiture etaient partie integrante du vehicule, ca permet des optimisations mais tu y perds en flexibilite et maintenance.
[^] # Re: Bonne approche ?
Posté par Pierre Tramo (site web personnel) . Évalué à 1.
Tu vois vraiment le mal partout, essaie de faire un compliment. Regarde, je fait en faire des SINCERES : Windows a une belle interface graphique, il a l'avantage d'avoir beaucoup plus de jeux que Linux. C'est tout, je ne trouves plus.
> On avait le micro-kernel, puis le kernel monolithique, comment on va appeler celui-la ? macrokernel ?
Si je me souviens bien, au démarrage, le noyau de win2000 fait 17mo, je suis d'accord que l'on appelle linux un macro kernel quand il sera aussi boulimique. Petite astuce, tu peut recompiler le noyau.
> A quand Quake3 dans le kernel ?
Il n'est pas libre. :-)
Plus je te lis et plus j'ai l'impression de voir un gosse qui poste, dés qu'il y a un domaine dans lequel vous n'étes plus leader(a cause de linux ou pas), tu arrrives et tu dit sans en avoir l'air que c'est de la merde pour une raison ou pour une autre. T'es vraiment un bon lanceur de troll, bravo.
[^] # Re: Bonne approche ?
Posté par pasBill pasGates . Évalué à 1.
Et je cause d'un point de vue conceptuel pas pratique.
Ca n'a rien a voir avec une concurrence MS<->Linux, simplement qu'a mon avis un kernel ca sert a remplir les fonctions de BASE d'un OS, il faut pas tout mettre dedans, ca veut pas dire que ca marchera moins bien, mais d'un point de vue conceptuel c'est pas beau. Pour moi c'est comme ecrire un soft au kilometre plutot que faire des modules separes, c'est conceptuellement pas beau, mais ca peut tout a fait marcher aussi bien voire mieux que la version modulaire.
Sinon, kernel32.dll fait 715Ko, c'est dans C:\winnt\system32\
[^] # Re: Bonne approche ?
Posté par pasBill pasGates . Évalué à 1.
J'ai melange kernel32.dll et ntoskrnl.exe :+)
ntoskrnl.exe fait 674Ko.
Ben oui les dev MS sont tellement betes qu'ils melangent le kernel avec une lib :+)
[^] # Re: Bonne approche ?
Posté par Wawet76 . Évalué à 1.
(Enfin... Je suppose que les fichiers que tu cite correspondent au micro-noyau de NT)
[^] # Re: Bonne approche ?
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: Bonne approche ?
Posté par Pierre Tramo (site web personnel) . Évalué à 1.
[^] # Re: Bonne approche ?
Posté par Anonyme . Évalué à 0.
L'OS en entier occupe plus de 17Mo, mais le kernel tient dans quasiment rien.
[^] # Re: Bonne approche ?
Posté par Pierre Tramo (site web personnel) . Évalué à 1.
[^] # Re: Bonne approche ?
Posté par Anonyme . Évalué à 0.
[^] # Re: Bonne approche ?
Posté par Pierre Tramo (site web personnel) . Évalué à 1.
http://daique.nexen.net/Image1.png(...)
[^] # Re: Bonne approche ?
Posté par bmc . Évalué à 1.
[^] # Re: Bonne approche ?
Posté par Anonyme . Évalué à 0.
[^] # Re: Bonne approche ?
Posté par ghent . Évalué à 1.
[^] # Re: vive les micro noyaux
Posté par Schneider Dark . Évalué à 1.
Il faut savoir s'arrêter. En cela HURD et QNX sont vraiment bien, car il y a modularité et souplesse.
[^] # Re: vive les micro noyaux
Posté par bad sheep (site web personnel) . Évalué à 1.
Je te signale au passage que le 2.4 occupe plutôt moins de mémoire et est plus rapide que le 2.2.
Quel OS peut en dire autant ?
Il y a le choix c'est tout : si on veut de la perf, on compile dans le noyau le serveur ouaib, sinon, on se garde un chtit noyau de derrière les fagots :)
Quel OS peut en dire autant ? :)
Désolé pour la redite ;)
[^] # Re: Bonne approche ?
Posté par Anonyme . Évalué à 0.
Linus a toujours dit qu'apache ne fonctionnait pas correctement et qu'il serait nécessaire d'intégrer des fonctions de serveur Web au noyau pour permettre des temps de réponse plus important pour les sites statiques, apache prendrait le relais pour les sites plus complexes.
Source : Tribune du Libre 1999
PS : je ne suis pas informaticien mais fait un métier que vous détestez le marketing ;-)
[^] # Re: Bonne approche ?
Posté par Anonyme . Évalué à 0.
Tu ne t'interesse pas vraiment au noyau.
Deja dans le noyau 2.4 se trouve khttp, qui lui meme sera remplacé par Tux. Docn tu vois Torvald n'a rien contre.
Conceptuellement c'est nullement une erreur, une app qui tourne dans l'user space tout en diminant les acces de temps de recopie memoire dans le kernel space ne peut etre que bon.
Et puis Quake 3 sans DRI tu fait combien de FPS
[^] # Re: Bonne approche ?
Posté par pasBill pasGates . Évalué à 1.
C'est comme integrer completement XFree dans le kernel, ca accelererait les perfs mais tout mettre dans le kernel n'est pas la bonne chose a faire.
Pour moi tout ce qui a trait a la gestion de l'OS doit se trouver dans le kernel et rien d'autre, les applications n'ont rien a faire dans le kernel space.
[^] # Re: Bonne approche ?
Posté par Anonyme . Évalué à 0.
Il me semble bien que dans la série des NT 3.x il ny était pas mais qu'en l'incorporant dans le noyau, le système gagnait en performance .
[^] # Re: Bonne approche ?
Posté par Anonyme . Évalué à 0.
Je confirme. Ca a d'ailleurs fait tout un foin. Et c'est une des raisons de l'instabilité du bazar !
[^] # Re: Bonne approche ?
Posté par Anonyme . Évalué à 0.
150
[^] # Re: Bonne approche ?
Posté par Anonyme . Évalué à 0.
Pourquoi croyez vous que quand word plante, windows plante aussi une fois sur deux????
[^] # Re: Bonne approche ?
Posté par Anonyme . Évalué à 0.
# perfs
Posté par Anonyme . Évalué à 0.
Mais je me trompe peut-être...
Qui est-ce qui nous fait un petit résumé des messages de la LKML sur le sujet ? :D
Au passage je crois bien que Linus est un des premiers supporters de ce truc-là.
Mais c'est vrai qu'après les serveur NFS et Web, pourquoi pas une BD-noyau :)
[^] # Re: perfs
Posté par j . Évalué à 1.
Un patch (en fait deux, le premier n'était pas bon) pour gérer le keepalive a été posté, et du coup le khttpd se révélait plus rapide, mais avec un temps de latence plus long.
Deux remarques cependant :
- BOA est vraiment destiné aux pages statiques et aux simples scripts CGI, il ne sait pas s'interfacer avec PHP par exemple, sans passer par l'interface CGI.
- Utiliser khttpd en combinaison avec un autre serveur (apache, roxen, thttpd, zeus...) n'est pas idiot, et contribue à réduire un peu la charge de la machine et l'occupation de la mémoire. On lance le serveur web sur un port alternative, comme 8080, et ktthpd sur le port 80. Quand il ne sait pas faire (ex: CGI, PHP, Perl...) il agit comme un petit proxy et passe la requete à l'autre serveur web.
Cela dit TUX est nettement plus performant et configurable, que ce soit pour les CGI ou les pages statiques.
[^] # Re: perfs
Posté par j . Évalué à 1.
Un patch (en fait deux, le premier n'était pas bon) pour gérer le keepalive a été posté, et du coup le khttpd se révélait plus rapide, mais avec un temps de latence plus long.
Deux remarques cependant :
- BOA est vraiment destiné aux pages statiques et aux simples scripts CGI, il ne sait pas s'interfacer avec PHP par exemple, sans passer par l'interface CGI.
- Utiliser khttpd en combinaison avec un autre serveur (apache, roxen, thttpd, zeus...) n'est pas idiot, et contribue à réduire un peu la charge de la machine et l'occupation de la mémoire. On lance le serveur web sur un port alternative, comme 8080, et ktthpd sur le port 80. Quand il ne sait pas faire (ex: CGI, PHP, Perl...) il agit comme un petit proxy et passe la requete à l'autre serveur web.
Cela dit TUX est nettement plus performant et configurable, que ce soit pour les CGI ou les pages statiques.
# Question ???
Posté par Vincent Zeus . Évalué à 1.
[^] # Re: Question ???
Posté par bmc . Évalué à -1.
--
bmc qui avait envie de troller
[^] # Re: Question ???
Posté par PinG . Évalué à 1.
[^] # Re: Question ???
Posté par j . Évalué à 1.
[^] # Re: Question ???
Posté par PinG . Évalué à 1.
# OK, mais à quoi ça sert ?
Posté par Anonyme . Évalué à 0.
Donc, on en revient toujours au problème des pages dynamiques. Le pire étant certainement les cgi en perl, modperl améliore ensuite les choses, php4 doit encore être meilleur, avec des solutions de cache c'est encore mieux.
Et pour finir, une solution adoptée par slashdot à l'époque ou ses scripts cgi ne suivaient plus: des scripts perls lancés quand la charge de la machine n'est pas trop élevée, placé dans des cron, et qui génèrent des pages html (comme ça apache délivre des pages statiques). Inconvénient: on a plus tout à fait du temps réél pour les pages, donc certains services d'un site ne peuvent pas se baser la dessus, mais une partie présentant des news (et générant en général la même page pour des milliers de visiteurs différents) y gagne beaucoup. Et rien n'interdit de mélanger les systèmes. Et si ça ne suffit toujours pas, on peut encore y gagner en écrivant les scripts en C, mais là il faudrait peut-être envisager la multiplication des serveurs avec un répartiteur de charge.
En conclusion, l'utilité réélle de ce genre de chose est douteuse, il faudrait faire attention à ne pas trop développer dans l'intégration des softs dans le noyau (car sur cette base, on peut facilement envisager des tas de services dont les performances pourraient être augmentées, au hasard, serveur ftp, dns, ...).
[^] # Re: OK, mais à quoi ça sert ?
Posté par Anonyme . Évalué à 0.
Tux intègre un cache générique pour toutes les requêtes vers des pages dynamiques, à la difference de BOA et kHttpd.
Les tests ou TUX explose la concurence intègrent la génération de pages dynamiques.
Tux est en réalité un framework pour des applications kernel-land -> kernel-land (eg servir un fichier vers le reseau par http, smb, ftp)... des plugins pour faire du SMB ont été annoncés.
Plutot que de vociferer sur RedHat, interessez-vous aux developpeurs qui sont derriere tout ca et qui eux ont de réels arguments à défendre.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.