Ce serveur serait-il peu ou pas utilisé du fait :
- du manque de curiosité des Informaticiens,
- du manque d'information le concernant,
- ou y aurait il une autre raison ?
Sinon pourquoi personne n'en parle, et y en a t'il parmi vous qui l'utilisent, et si oui qu'en pensez-vous ?
Aller plus loin
- le site de caudium (4 clics)
- vu sur linuxFrench.net (7 clics)
- le site d'apache (2 clics)
# manque de popularité
Posté par Anonyme . Évalué à 0.
[^] # Re: manque de popularité
Posté par Anonyme . Évalué à 0.
>(comme apache ou
>IIS par exemple)
^^^^^
tu est sur de ce que tu avances ?
[^] # Re: manque de popularité
Posté par Babou . Évalué à 1.
C'est **entre-autres** le fait qu'il ait été éprouvé par la communauté, testé, attaqué, que ses
bugs aient été corrigés ...
Ce serveur WWW est peut-être très bien, mais il pour savoir s'il est intéressant de l'utiliser, il faut d'abord déterminer si:
- il intègre ce dont on a besoin (PHP/un langage de script, authentification, SSL, logs, etc ...)
- il est sûr (overflow & Co)
- il est efficace (tenue de charge, tps de réponse ...)
- il est pas trop chiant à configurer (je fais ici allusion à sendmail/postfix ;-)
- autre chose ? (on pense pas à tout hein)
[^] # Re: manque de popularité
Posté par Anonyme . Évalué à -1.
Sinon y'a aussi sendmailconfig qui est pas mal.
[^] # Re: manque de popularité
Posté par Anonyme . Évalué à -1.
Rien que le jargonnage M4 prete a fuire...
Bouquin sendmail chez O'Reilly : tres bien fait et detaille mais 1200 pages...
Ce qui a motive les alternatives a sendmail : l'usine a gaz monolythique qu'il est avec tous les problemes qu'il a connu jusqu'aux versions 8.9.2 a fait que les alternatives sont modulaires. Il s'en suit une lecture du code plus simple (modules moins gros) et des risques de trous de securite moins graves au sens ou ca n'est qu'un module qui est touche le cas echeant, pas l'usine a gaz qui tourne avec des droits eleves.
Ceci dit, qu'on ne se meprenne pas, ca n'est pas un troll anti-sendmail. J'explique, enfin j'essaie, la motivation qui a mene et fait que les alternatives a sendmail sont la et utilisees :-)
Il est certain que je prefere utiliser sendmail a un autre serveur de mail tout neuf qui sort de travail d'un developpeur qui vient de le terminer la nuit derniere, pour les raisons deja evoquees plus haut : tests et "approbations" securite non encore effectues par la communaute ;-)
[^] # Re: manque de popularité
Posté par Manuel Menal . Évalué à 1.
grace (tiens le circonflexe marche pas sur Skipstone...) à de nombreux outils comme
ceux que tu cites... Cependant, un des gros problèmes justement est que les sysadmins
de grosses boites configurent ça comme ça, et là ça provoque de gros trous de sécurité,
qui ont en grande partie fait la réputation d'insécurité de Sendmail (je ne nie pas qu'il
a de gros défauts, loin de là...). Mais un Sendmail bien configuré est vraiment très sécure...
(<troll>bon on ne comparera avec Qmail bien sur ;-) </troll>)
Ouais ben conclusion taper un texte sous Skipstone c'est la merde...
[^] # Re: manque de popularité
Posté par Anonyme . Évalué à 0.
Il faudrait vraiment qu'un autre serveur web qu'apache aie de rééls avantages pour justifier le passage. Sinon apache, en ayant 60% de part des sites internet à une très grande image de fiabilité et de sécurité. D'ailleur depuis 2 ans que je l'utilise, je crois n'avoir jamais du faire un update lié à des problèmes de sécurité lié directement à ce deamon et non à sa configuration. Ceci ne veut pas dire pour autant que caudium soit à jeter.
[^] # Re: manque de popularité
Posté par Anonyme . Évalué à 0.
Dans ces conditions, on peut prendre une config Apache+Servlet+Cocoon, ou bien s'orienter vers des solutions comme le RXML de Roxen.
Avantage du premier: ca met a genou les bi-PIII. Mais ca marche. Et c tres en vogue (donc bcp de dev et de feedback de la part de la communaute).
Avantage du second: c propre, c joli. Mais la base d'utilisateurs est nettement plus restreinte.
[^] # Re: manque de popularité
Posté par Anonyme . Évalué à 0.
De plus, il n'y a pas que java qui sache parser du xml, donc tu peux obtenir la même abstraction grâce à perl ou php. Le probléme, c'est que Personal Home Page ça en jéte moins que Java Server Page et autres. Chez nous, quand un client trés in se raméne, on lui sert du xml/jsp/ejb/oracle pour racler le fond de son porte-monnaie. Quand le client est prés de ses sous et un peu au courant, on lui fait ça en php en 2 temps 3 mouvements et on en parle plus.
Je rebondis sur le débat Caudium/Apache où les 2 sont des produits de la communauté. Si Caudium est si bon que certains semblent le penser, il s'imposera de lui-même au fur et à mesure. Contrairement à d'autres confrontations où les dés sont pipés par le côté marketing de la chose (>ca met a genou les bi-PIII. Mais ca marche (et tout le monde il est content surtout dell, ibm, sun), ici ce sont les qualités réelles qui vont primer.
Bon match en perspective!! Je m'en vais l'installer illico!
[^] # Re: manque de popularité
Posté par Anonyme . Évalué à 0.
[^] # Re: manque de popularité
Posté par Anonyme . Évalué à 0.
Pour l'instant, j'ai installé caudium grâce à l'entrés source.list qui va bien ( deb ftp://ftp.oav.net/caudium/debian/(...) unstable main ).
Ca prend 15.2M mais j'avais pas pike7.
Debconf pose quelques questions sur les ports à utiliser pour accéder à l'interface d'administration et écouter les requétes http.
Je fait pointer mon browser vers le port précédemment spécifié et j'ai accés à une belle interface d'administration. Heureusement parce que les fichiers de config donnent plutôt envie de se réfugier vers quelque chose de plus parlant.
Et effectivement, l'interface est claire et compléte, surtout la partie concernant les modules.
Donc, trés bonne premiére impression. Je recompile php4 avec le support de caudium et je vous en dit plus.
# Caudium, Roxen...
Posté par Anonyme . Évalué à 0.
C'est un programme tout a fait genial, puisqu'il s'agit en fait d'un meta-serveur, apte a repondre a des requetes Web aussi bien que des requetes FTP ou autres.
L'interface de configuration est vraiment tres au point.
Je reproche au soft (Roxen ou son equivalent totalement libre Caudium) un manque de finition dans les modules. Ceci etant du au manque de feedback de la part des utilisateurs.
Il faut etre conscient que les gens qui utilisent Roxen ne font pas du PHP+MySQL. Ca c'est une habitude typiquement "Apache".
Roxen utilise son propre langage dynamique et ses propres modules d'acces aux bases de donnees.
Consequence pratique, les modules PHP pour Roxen sont pas tiptop.
Pour resumer, je dirais que Roxen et Apache n'ont pas la meme philosophie. Et que si Caudium/Roxen emerge, ca va troller sec avec les Apacheux.
Moi, je serai dans le camp de Roxen :-)
[^] # Re: Caudium, Roxen...
Posté par Anonyme . Évalué à 1.
Je dirais seulement pour avoir vu il y a quelques annees, grace a un pote, un Roxen tourner qu'effectivement Pike allie a Roxen permet de faire de superbes choses !
Roxen est multithreads depuis un moment, ce qui n'est pas negligeable... Apache, ca vient avec la 2.0.
Autre chose qui peut etre interessante en environnement de production : Roxen propose toute une suite commerciale de gestion de site, qui semble s'approcher de ce que les gens de Zend proposent aujourd'hui, donc pour PHP. Interessant mais je n'ai aucun echo de ce que ca vaut (fonctionnalites, etc...) tant du cote Roxen que Zend.
Si qqu'un avait des echos, feedback welcomed !
[^] # Re: Caudium, Roxen...
Posté par daniel . Évalué à 1.
# Un exemple d'une utilisation de caudium.
Posté par ghent . Évalué à 2.
# Oui, mais...
Posté par Anonyme . Évalué à 1.
D'autant plus que PHP, CGI et biens d'autres sont parfaitement supportés par Apache.
Et puis PHP il est le plus utilisé aux monde.
Donc si Caudium ne le supporte pas, a quoi ça sert ?
[^] # Re: Oui, mais...
Posté par falbala . Évalué à 1.
T'as oublié ASP mon gars.
Donc à quoi sert PHP, si on suit ton raisonnement ?
[^] # Re: Oui, mais...
Posté par Euclide (site web personnel) . Évalué à 1.
Apache supporte donc ASP également.
Et que je saches, un des buts de gbasic est d'avoir une compatibilité complète avec les scripts ASP en VB.
<troll>Mais de toute façon à ce niveau la IIS est en tête : on peut faire tourner les ASP et php dessus, ainsi que les CGI perl</troll>
[^] # Re: Oui, mais...
Posté par mister popo ポポ (site web personnel) . Évalué à 1.
caudium a la bonne idée d'integrer une interface pour le configurer, et ça, ça fait jamais de mal.
> D'autant plus que PHP, CGI et biens d'autres sont parfaitement supportés par Apache.
Argumentation pourrite, IIS aussi sait faire du CGI et du PHP. Faut juste savoir ce que l'on demande à un serveur http.
> Et puis PHP il est le plus utilisé aux monde.
juste la syntaxe de cette phrase me plait.
Et puis si j'ai pas envie de faire de PHP, je peux quand même utiisé un serveur http? moi, j'aime bien le serveur de Jakarta pour sa simplicité de mise en place pour faire du JSP, si je veux faire du PHP, beinh j'utilise Apache.
> Donc si Caudium ne le supporte pas, a quoi ça sert ?
Un serveur http peut aussi etre un bete serveur statique, pour les probleme de forte charge et de clusterfarm, il est pratique d'utiliser un serveur d'images (c'est ce que fait Yahoo par exemple), et des petits serveurs costaud font parfaitement l'affaire pour ça.
Pour finir, Mr Anonyme, je croyais que la base de l'informatique libre, c'est le choix.
-- there's more than one way to do it
[^] # Re: Oui, mais... non pas de mais ! grumpf
Posté par Guyzmo . Évalué à 1.
As-tu déjà installé autre chose que du apache ?
> D'autant plus que PHP, CGI et biens d'autres sont parfaitement supportés par Apache.
heureusement que Apache supporte bien les CGI... et qu'il n'est pas le seul.... même IIS supporte bien les CGI..... vas relire ton livre 'comment devenir webadmin en 48h' au chapitre 'keksé donc un CGI'
> Et puis PHP il est le plus utilisé aux monde.
Je ne vois pas de quels monde tu parles ? Sur Mars, Venus ou Pluton ? En tout cas je suis pas du tout convaincu que cette m****e de php est ce qu'il y a de plus utilisé sur terre.
> Donc si Caudium ne le supporte pas, a quoi ça sert ?
C'est clair que PHP ne servira plus a rien.
Par contre, tu peux regarder de plus près le Rxml et le pike, qui sont des languages très interressants.
[^] # Re: Oui, mais... non pas de mais ! grumpf
Posté par Anonyme . Évalué à -1.
Bon, j'utilise Apache qui n'est franchement pas compliqué (d'ailleurs c'est tout dire je le maitrise) mais bon, si vous preferez caudium ou IIS c'est votre choix.
C'est comme moi : Je pense vraiment que le C c'est un langage de mémé facile a comprendre, d'autres diront que c'est compliqué. Par contre je trouve Perl vachement fumeux alors que d'autres en boivent comme du petit lait. Malheureusement pour gerer des script CGI rien ne vaut le couple Perl/MySQL. Et MySQL/Apache vont de paire.
D'ailleurs, je ne me sent pas un as de la prog. et de l'administration. Apprendre par coeur un langage je trouve ça bete. On utilise et on apprend ce qui est utile pour nous. D'ailleurs bcp pensent que ACCESS est la base de donnée la plus simple a utiliser, mais j'ai jamais reussit a le configurer pour le faire tourner sous Apache (pourtant j'ai essayé). Je trouve qu'ACCESS est trop difficile pour ce que je lui demande.
Bon voila, a+
[^] # Re: Oui, mais... non pas de mais ! grumpf
Posté par Anonyme . Évalué à -1.
De plus, MS Access n'est PAS un SGBD ! (même s'il donne l'impression d'accepter le SQL).
[^] # Re: Oui, mais... non pas de mais ! grumpf
Posté par Anonyme . Évalué à -1.
D'ailleurs je vais remplacer tout de suite mysql par sqlserver histoire de rire, non meme pas encore mieux je vais installer le gros bousin d'oracle ...
Bon serieusement ca t'arrive de dire autre chose que des conneries ?
[^] # Re: Oui, mais... non pas de mais ! grumpf
Posté par Anonyme . Évalué à -1.
Dire que la nasa utilise MySql c'est une super argumentation, l'armée francaise utilise Access, donc on en deduit que c'est super?
MaLaM
[^] # Re: Oui, mais... non pas de mais ! grumpf
Posté par Guyzmo . Évalué à 1.
Oui, c'est une mode, et c'est pour ça que roxen supporte le php.
C'est comme moi : Je pense[...gouts...]Perl vachement fumeux[...couleur...]Malheureusement pour gerer des script CGI rien ne vaut le couple Perl/MySQL. Et MySQL/Apache vont de paire.
Tout d'abord, il existe le Pike qui est un language pouvant remplacer le Perl et qui a une syntaxe très proche du C, ensuite, il existe PostgreSQL qui est largement plus puissant et plus stable que MySQL, enfin PostgreSQL/Apache va autant de paire que MySQL/Apache, ou que MySQL/Caudium et PostgreSQL/Caudium, Par ailleurs, Pike/Postgres vaut largement Perl/MySQL.
Je vais éviter de partir en troll sur MySQL, mais ce programme là est _très_ limité (y'a qu'a voir toutes les merdes qu'il y a eu sur freshmeat1.... oups... j'ai trollé)
Par ailleur, je pense que Perl ou Pike ne remplace pas le C, mais est un complément au C.... mais il est vrai aussi que beaucoup ne sont pas de mon avis.
d'après ce que tu dis, tu es le mouton qui suit le mouvement, et qui utilise Apache/Perl/MySQL/php parce que tout le monde l'utilise. Aies le courage d'essayer autre chose, comme Caudium, mais aussi, d'autres serveurs qui pourraient etre aussi evolués que apache, pour te forger une opinion, et utiliser ce que tu trouves être le mieux, et pas ce qui est le mieux, par manque de connaissance du reste.
*couic*exemple ACCESS*couic*
ton exemple sur access nous montre que tu as de la
volonté.... donc essaye Pike et donnes tes impressions après ;)
--
Enfin, aies le courage de tes opinions en signant tes messages
[^] # PostgreSQL meilleur que MySQL ?
Posté par Anonyme . Évalué à 1.
Encore une fois tout dépend de l'utilisation que l'on en fait, et ne vois pas de défauts à MySQL là où il ne te manques que des compétences en SQL :).
C'est vrai, MySQL ne supporte entre autres pas les vues (tu parles bien de ça ?), mais son grand avantage, c'est sa rapidité !
Quant au fait que certains désirent rester anonymes, ça ne regarde que eux (nous) !
[^] # Re: PostgreSQL meilleur que MySQL ?
Posté par Melkor . Évalué à 1.
[^] # Re: Oui, mais... non pas de mais ! grumpf
Posté par Anonyme . Évalué à 0.
J'aime bien ces mecs qui se la joue :MOI JE SAIS!
Va jeter un coup d'oeil sur ces stats effectuées uniquement sur les serveurs terriens ( http://linuxfr.org/2001/04/18/3213,0,1,0.html(...) ). Désolé pour toi mais php est effectivement le module le plus utilisé. Mais c'est vrai que pour certains, la vérité est ailleurs...
Caudium est certainement intéressant mais vu ta façon d'agicher le client, y'a de quoi fuir!
Sinon, quelqu'un pourrait m'expliquer les différences entre caudium et roxen? C'est quoi la petite histoire derrière ça?
[^] # Re: Split Roxen/Caudium
Posté par Anonyme . Évalué à 0.
En passant a la version 2.x, ils ont change pas mal de choses qui rendent les sites 1.x obsoletes et incompatibles.
Caudium, c'est le code de Roxen 1 maintenu et mis a jour pas un groupe de chevelus barbus (les pires :-)
Le but est que Caudium continue a supporter les sites de style 1.x, tout en profitant des ameliorations notables que Roxen 2.x
Je crois egalement que la licence de Roxen 2.x est un peu plus restrictive que celle de Roxen 1.x. Et ca les barbus, ca leur a pas plu non plus.
Personnellement, des sites en 1.x, j'en ai pas. Donc je me tournerai vers Roxen 2.x directement (qui est integre dans la Debian, ca donne quand meme une idee sur la liberte de la licence).
[^] # Re: Split Roxen/Caudium
Posté par Anonyme . Évalué à 1.
Personnellement, des sites en 1.x, j'en ai pas. Donc je me tournerai vers Roxen 2.x directement (qui est integre dans la Debian, ca donne quand meme une idee sur la liberte de la licence). »
http://freshmeat.net/projects/roxenwebserver/(...)
2.1.135 21-Sep-2000 GNU General Public License (GPL)
hum hum..
[^] # Re: Split Roxen/Caudium
Posté par Anonyme . Évalué à -1.
[^] # Re: Split Roxen/Caudium
Posté par drac . Évalué à 1.
[^] # Re: Oui, mais... non pas de mais ! grumpf
Posté par Melkor . Évalué à 1.
# Je préfère Apache
Posté par Pierre Tramal (site web personnel) . Évalué à 1.
- il est plus utilisé, donc il y a un plus grand retour de la part des utilisateurs et donc une plus grande contribution, donc plus de corrections de bugs de sécurité et autres.
- le multi-thread est à mon avis un truc à la mode (comme le XML), et je ne pense pas que le fait d'être multi-threadé pour un serveur apporte quelque-chose.
- j'ai fait un benchmark (avec ab) d'Apache et de Caudium sur un celeron533 128mb et je peux vous dire qu'Apache est sorti gagnant en termes de nombre de requêtes par secondes, quelque soit le type de fichier servi (statique/cgi)
- apache est bien plus simple à mettre en place que Caudium (installation de pike et de toutes les dépendances (ex: gtk pour un serveur :))
- l'interface de configuration de caudium est assez ergonomique, mais rien ne remplace vi httpd.conf
bref, faites ce que vous voulez, mais je reste sous apache :))
[^] # Re: Je préfère Apache
Posté par Anonyme . Évalué à 1.
T'es sur d'avoir bien compris ce qu'est le xml ?
[^] # Re: Je préfère Apache - Pas moi
Posté par Franck Nouyrigat . Évalué à 1.
> Oui c'est ce que l'on doit pensez de Windows aussi ? :)
"le multi-thread est à mon avis un truc à la mode (comme le XML), et je ne pense pas que le fait d'être multi-threadé pour un serveur apporte quelque-chose"
>C'est pas une mode le multi-thread, ou alors fork aussi c'est de la mode ! , cela permet de ne pas
recopier toute le contexte d'un processus, mais seulement une partie et de plus de partager des Variables Global ... Mais concernant Caudium, Le multithread est plus interressant sous BSD car mieux supporté que sous Linux...
"j'ai fait un benchmark (avec ab) d'Apache et de Caudium sur un celeron533 128mb et je peux vous dire qu'Apache est sorti gagnant en termes de nombre de requêtes par secondes, quelque soit le type de fichier servi (statique/cgi) "
>On à pas vu les memes alors, par contre je suis d'accord qu'apache est bien meilleur en ce qui concerne PHP, mais d'après les Core programmeur de Caudium, c'est PHP qui à un problème pas caudium..
"apache est bien plus simple à mettre en place que Caudium (installation de pike et de toutes les dépendances (ex: gtk pour un serveur :))"
>C'est faut, premièrement GTK n'est pas une obligation et deuxièmement t'as déja regarder comment faire un certificat SSL avec caudium, 34 sec pas plus et pour le reste c pareil pratique sans chichi...
>Sinon petit rappelle RXML n'a rien à voir avec XML, c'est un language de prog (Roxen Macro Language) au meme titre que PHP, (voir site de Roxen), il à été fait en pike
sinon pour plus de rensaignement voir Le Linux Mag 27 ...
re bref : Essayer vous verez mais ne vous arreté pas sur des préjugé du genre l'est pas connu, l'est chiant à compiler ...
[^] # Re: Je préfère Apache - Pas moi
Posté par Pierre Tramal (site web personnel) . Évalué à 1.
* ensuite (et je suis _sur_ de bien savoir ce que c'est), je persiste à penser que le XML est une mode: on nous ressort le concept de base de données à la sauce businness: grâce à xml on fera ceci, grâce à xml on fera cela, etc. alors que c'est un simple fichier texte qui contient des données.
* le bench a été fait par moi même, et donc j'ai parfaitement confiance en lui
* le concept de multithreading a été ressorti par java (tiens, encore une autre mode, alors que c'est une simple émulation de processeur et d'OS) et je ne vois pas en quoi cela pourrait être intéressant pour un serveur (pour une interface graphique à la limite, cela permet au programme de travailler sans que l'utilisateur ressente de "blocage" de l'interface) mais pour un serveur...
[^] # Re: Je préfère Apache - Pas moi
Posté par daniel . Évalué à 1.
- un fichier XML est, d'une certaine manière, un fichier texte qui contient des données. Je pense quand même que c'est bien plus qu'un mode : XML est une norme d'inscription des données dans des fichiers textes, donc lisible par n'importe quel programme.
Si tu ne comprend pas l'intérêt qu'il y a à établir un norme pour enregistrer et recueillir des données indépendemment de leur origine ( c'est précisémment pour ça qu'ils ont séparés le fond de la forme), je vais pas pouvoir te l'expliquer en cinq minutes.
- du côté du multithreading, tu n'a pas tort en ce qui concerne les unix en tout cas. mais en lisant les nouvelles sur le développement d'Apache 2, tu remarquera quelque chose : Apache devient multithreadé. d'aprés ce que j'ai compris, ça n'est pas pour obéir à un effet de mode, mais à cause de windows (pas taper svp c'est pas un troll). Windows ne supporte pas aussi bien le multi-processing que linux ou bsd. le résultat était qu'Apache sous win était à la fois plus lent et moins stable que sous un Unix.
- sans vouloir t'offenser, essaye d'avoir l'esprit plus ouvert et d'être un peu moins aggressif dans tes posts.
[^] # Re: Je préfère Apache - Pas moi
Posté par Pierre Tramal (site web personnel) . Évalué à 1.
-> mais ce qui m'intéresse, ce sont les perfs d'apache sous _unix_ et plus particulièrement _linux_ ou _*bsd_. donc je ne vois toujours pas l'intérêt de multithreader un serveur (apache forke et donc il se voit réparti sur plusieurs cpu si plusieurs cpu il y a)
- pour le xml, vous admettrez qu'on est en plein dans le modèle php/mysql où les scripts php accèdent aux données contenues dans la base mysql... le tout en moins optimisé (pas de compression ni d'optimisation) et en moins puissant (pas de queries complètes en sql). d'autant plus que l'universalité et le partage réseau est possible avec sql.
j'espère ne pas avoir été agressif ! :))
[^] # Re: Je préfère Apache - Pas moi
Posté par - - . Évalué à 1.
le multithread devrait permettre a apache de mieux s adapter a la charge et a la machine, vu qu il peut fonctionner en mode process et/ou thread .
le multithreading peut permettre une plus grande vitesse et moins d occupation memoire (du au fait que les threads se partagent le meme environnement )
bref, c'est une souplesse de plus pour apache. accessoirement ce n'est pas une "mode", ca n'as jamais ete une mode le multithreading, juste une maniere de penser son soft.
le XML
alors la, le XML c'est BIEN plus qu un bete fichier texte pour envoyer une requete a une base de donnée
effectivement si on considre QUE le fichier .xml alors c'est inutile, ca sert presque a rien
mais si on pense a XSLT , au probleme de normalisation des accées de bases de données, a XML-RPC, a SOAP etc...
se degage en fait un ensemble d outils _normalisés_ (si tout le monde joue le jeu.. on verra) pour distribuer du CONTENU (le fond) indépendamment de la _FORME_ (ce que ne fait _pas_ le html , )
finalement, quand on parle de XML , on parle en fait de beaucoup plus que simplement la syntaxe XML, on parle surtout d 'une utilisation de multiples outils.
le but révé et que via XML (et toute la clique derriere) on normalise les echanges de données et appels de fonctions via reseau , le tout normalisé au niveau du net, et que le fond (les informations reelles) soient independantes de leur forme (genre, si le document est lu sur un telephone portable, il est renvoyé avec un look et une mise en page epurée dans un langage adapté au portable , pareil si c sur une télévision )
peut etre que les mots xml ,dom , sax , etc... surtout a cause du battage microsoft autour de .NET sont une mode, mais l'esprit derriere tout ca, le but voulu , n est pas une mode, c'est un probleme de partage de documents qui est ancien et qu il faut corriger. XML est une solution aux soucis actuels de gestion documentaire (et divers autre chose).
c'est trés vaste et j'ai a peine dégrossi la
[^] # Re: Je préfère Apache - Pas moi
Posté par Anonyme . Évalué à 0.
- Pour XML, je crois que tout a déjà été dit (cf post précédent)... Il est vrai qu'il n'y a rien de miraculeux dans XML, et que ça devrait exister depuis bien longtemps... Mais maintenant que ça existe, sachons en tirer parti (et surtout de ses multiples normes "'satellites" comme XSLt, XSchema, XPath, etc...)
- Pour le multithreading, cela ne sert pas seulement à rafraichir une interface tout en faisant un calcul!!! (LOL;) Si tu les considère comme inutiles, alors quel intérêt trouves-tu aux processus parallèles? Pourquoi ne pas faire une bonne boucle en assembleur, après tout ?? Il faut que tu comprennes que (comme l'apporche objet par exemple), les threads sont un modèle de programmation qui permet de développer des choses complexes assez facilement. Par exemple, elles offrent des moyens de synchronisation évolués (conditions, sémaphores, etc.), ce que l'on n'a pas facilement avec des fork(). Mais c'est vrai que l'on peut toujours faire sans, comme on peut aussi tout faire sans le C ou tout autre langage de + ou - haut niveau...
- Pour Java qui serait une mode, je préfère en rire... Certes ça tourne plus lentement que du C ou du C++, mais au cas où tu ne l'aurais pas remarqué, ce qui compte maintenant c'est plutôt la conception, la maintenabilité, etc... Qques petits exemples parmis une foule :
- API consistante, ouverte, cohérente...
- Conception / Designs patterns (sais-tu ce que c'est, au moins?)
- J2EE...
Mais c'est vrai que l'on peut toujours tout faire en assembleur et en ligne de commande, sans conception, ... Ca fait plus "geek", plus "hacker", etc...
[^] # Re: Je préfère Apache - Pas moi
Posté par Pierre Tramal (site web personnel) . Évalué à 1.
Moi, je trouve au contraire que Java et XML font beaucoup plus "geek", beaucoup plus "startup bien comme il faut". Par contre l'assembleur fait effectivement plus hacker, mais il faut savoir que les failles de sécurité sont beaucoup plus visibles en assembleur :)
Quant à XML, ce n'est vraiment pas nouveau... Le format CSV permet tout aussi bien d'échanger des données qui seront également lisibles par tous les programmes....
[^] # Re: Je préfère Apache - Pas moi
Posté par Anonyme . Évalué à 0.
C'est l'histoire d'un mec qui fait le site de sa grand-mére en EJB, XML, JSP, Oracle pour prouver qu'il en a dans le pentalon.
Mamie lui dit: "fiston, ça fait 6 mois que t'a commencé et c'est pas encore fini? C'est qu'ils font du bruit les 12 serveurs que tu as installés. La fille de la voisine lui a fait son site sur le macramé en péachepé en une semaine et des américains sont déjà venus la voire!".
Je travaille dans une startup et me coltine du java à longueur de journée. Comme le décrit alex14, si tu n'es pas à fond dans la mouvance java, les investisseurs qui n'y connaissent rien n'aboulent pas le pognon. Donc, on a du java à tous les étages et sa rame grave (DELL nous adore!). Notre CTO (le maître des geeks) qui nous imposait des changements technologiques au rythme des sorties du O1 et autres journaux à baratins, veux faire un pont java/C pour accélérer les choses!
Moralité, nous avons la chance d'avoir le choix des outils que nous utilisons. Nous devrions avoir du recul par rapport au baratin marketing et autres effets de mode.
Si un jour j'utilise caudium, ce ne sera pas parce qu'il est à la mode ou même le plus utilisé mais parce qu'il convient à mes besoins.
[^] # Re: Je préfère Apache - Pas moi
Posté par Pierre Tramal (site web personnel) . Évalué à 1.
de toute facon:
- moins c'est commercial
- moins ca attire les investisseurs comme des mouches sur une m?rde
- moins c'est portable
- moins c'est à la mode
plus c'est libre, plus c'est rapide et plus j'aime.
[^] # Re: Je préfère Apache - Pas moi
Posté par Anonyme . Évalué à 0.
On croit rever...
Apache fork son processus, copie le contexte et toute la memoire, c'est lent, gourmant en ressource et en mémoire, etc.
Le multi-threading ça crée une sorte de processus qui partage la mémoire et le contexte. Donc tres rapide, peu gourmant, facile à utiliser, etc...
Donc oui le multi-threading c'est bien. Et ça existait bien avant java, c'est pas une mode, c'est utilisé partout sans que tu t'en appercoive...
Mais à te lire tu ne sais pas ce que c'est...
Donc quand on ne sait pas, on ne parle pas...
Le Xml on en parle partout parce que ça repond à un besoin....Tu ne dois pas non plus savoir ce que c'est Xml de toute façon...
MaLaM
[^] # Re: Je préfère Apache - Pas moi
Posté par Anonyme . Évalué à 0.
est ce que html est une mode??????
# Je l'utilise depuis plus de deux ans sans problème
Posté par Anonyme . Évalué à 0.
J'utilise Roxen 1.3.x (Caudium est le nouveau nom de Roxen 1.3, Roxen 2 est autre chose) depuis plus de deux ans sans problème majeur. Il est stable, complet, il permet de simplifier énormément certains tâches (créations de bouton et consorts), a une interface d'administration via le web très agréable, etc.
Pour ce qui est de P.H.P., Caudium semble le gérer actuellement (pas encore testé) mais, pour ça, j'ai installé Apache sur un autre port (pour l'instant).
Je vais bientôt passer l'autre serveur web que je gère sous Caudium. Actuellement, Roxen 1.3-Caudium me permet de gérer le courrier par le web (module IMHO), de créer des boutons et autres gâteries graphiques à la volée (gtext), de pouvoir identifier les gens de plusieurs manières (/etc/passwd, base de données MySQL, .htaccess, etc.) simplement en ajoutant des modules via l'interface web, etc.
Sinon, pour les tests de rapidité et autres benchmarks, s'il s'agit de mesurer la vitesse pure de service des pages, il est peut-être derrière. Mais il n'y a pas que la vitesse qui compte dans un serveur web : évolutivité, robustesse, sécurité, etc.
--
Gilles, gpl@mac.com
[^] # PHP
Posté par Anonyme . Évalué à 0.
Pour revenir aux Barbus dans un des posts precedents. les gens autour du projets Caudium sont tres friendly...
mued@dev-edge
# Le pb n'est pas qu'il soit connu mais que ca tienne en charge
Posté par Anonyme . Évalué à 0.
L'histoire de ce soft débute en 1993 (apache n'existait pas et le seul et unique serveur web potable était celui du NSCA d'ou est dérivé Apache FYI). Ce soft avait été fait uniquement par ce qu'il n'existait pas de solution satisfaisante aux serveurs web existants (et a mon avis c'est toujours le cas), pour le reste http://fr.caudium.net/history/(...) résume pas mal l'histoire de Spider, Spinner, Roxen et Caudium.
Par contre, on peut aimer, pas aimer Caudium/Roxen ca je suis d'accord, mais il faut voir objectivement les différences d'architectures notable de Caudium :
o il est thredé depuis 1994
o il ne fork pas
o il a le meme temps de réponse quel que soit le
nombre de connections simulatanés, j'en ai fait
l'essai moi meme avec des pages perso ou
chaucunes des machines avaient entre 4000 et
6000 connections TCP par serveur fronteaux.
o la fait que Caudium soit threadé stress
beaucoup moins la machine, 5000 connections TCP
sur un BiPIII 550 = load average à 2.0
Maintenant les arguments techniques :
o PHP est le plus utilisé au monde: oui et alors?
M$ est le plus utilisé dans le monde dans la
bureautique mais est-ce une solution viable ?
Pour ma part, j'ai toujours détesté le PHP...
o le multi-thread est à mon avis un truc à la
mode ? Okay bah reste dans les limbes de la
technique... (tiens je te files les disquettes
de MS-DOS, ca te va ?)
o Les bench avec une machine serveur, et une
machine cliente, ne sont pas du tout
représentatifs de la capacité d'un serveur web
a servir des pages. Si tu peux le faire avec
un /8 (une classe A pour ceux qui ne savent pas
ce que la notation CIDR veut dire) qui accéde
a un serveur web, on pourra dire que ton bench
est représentatif.
o Le support GTK de pike... Il n'est PAS
NESSAIRE. Je rappelle pour ceux qui n'ont pas
compris que Pike est un langage général. Il
très bien utilisé pour faire tourner Caudium,
mais il peut être utilisé pour faire des applis
locale et standalone...
o Si tu veux modifier ta conf vi ~caudium/configurations/*
En conclusion : Essayez Caudium ou Roxen, poussez-les a fond tous les deux, si vous préférez rester sous apache, c'est bien, vous faite comme tout le monde, si vous utilisez Caudium, vous verrez, un fois le cap du changement de technologie passé (qui je sais difficile), que vous ne regretterez pas la stabilité de Caudium.
Pour info: http://www.bsdfr.org/(...) tourne sous Caudium 1.1.1 (ainsi que son serveur FTP... Tiens... Apache fait pas serveur FTP? bouargl!). Bon et pour ne pas citer http://gcu-squad.org/(...) =)
Aller hop : ftp://ftp.oav.net/caudium/(...) pour passer rapidement à caudium =)
/Kiwi
[^] # Re: Le pb n'est pas qu'il soit connu mais que ca tienne en charge
Posté par Anonyme . Évalué à 0.
Tout real.com tourne sous Roxen et Caudium depuis leur creation... C'est pas un gage de qualité et de stabilité ?
$ telnet www.fr.real.com 80
Trying 213.128.136.66...
Connected to www.fr.real.com.
Escape character is '^]'.
HEAD / HTTP/1.0
HTTP/1.0 200 OK
Content-Length: 35826
X-Got-Fish: Yes
Connection: close
Accept-Ranges: bytes
MIME-Version: 1.0
Last-Modified: Sun, 22 Apr 2001 17:40:31 GMT
Date: Sun, 22 Apr 2001 17:40:32 GMT
Content-type: text/html
Cache-Control: no-cache
Expires: Sun, 22 Apr 2001 17:40:37 GMT
Server: Caudium
Connection closed by foreign host.
D'ailleurs voici les stats de lassie.real.com :
http://david.hedbor.org/tmp/stats.gif(...)
/kiwi@caudium.net
# threads/process
Posté par Anonyme . Évalué à 0.
Le mieux serait autant de process que de processeur et 2-3 thread, pas plus. Il n'y a pas de mise a jour de la MMU mais il y a toujours le changement de context !
nicO
[^] # Re: threads/process
Posté par Anonyme . Évalué à 0.
Pour ce qui est du multi-proc, je sais pas.
[^] # Re: threads/process
Posté par Dugland Bob . Évalué à 1.
Sous Linux, la différence est faible (voir clone(2))
"Les variables sont les même" : avec la portée, tu t'en sort
le multi proc, les nouvelles (pas très fraîches) que j'en ai c'est :
le coût de migration d'un thread sur un autre proc n'est pas toujours inférieur au fait de le garder sur place (à cause des caches, entre autres)
le 2ème proc peut servir au noyeau ou aux autres démons.
[^] # Re: threads/process
Posté par Stephane Pion . Évalué à 1.
Utilisons les threads pour améliorer les performances.
Le partage de donnée entre threads coûte cher en terme de synchronisation (prise de verrou, switch du contexte ...) et cela, contrairement à ce qui a été dit plus haut stresse pas mal la mémoire.
La gestion des E/S bloquantes via des threads, est je pense, quand on commence à avoir un nombre conséquent de socket, une hérésie. J'imagine d'ailleurs que apache ne fait pas ce genre de chose.
Sur linux les threads utilisent le modèle 1x1 ( http://pauillac.inria.fr/~xleroy/linuxthreads/faq.html#K(...) ) et béneficient de la répartition de charge sur plusieurs µpro. Je crois d'ailleurs qu'il n'y a aucun moyen sur linux d'attacher un thread à un µpro ce qui peut être problématique.
En plus, dans le cadre d'une utilisation en C++, on a eu de gros soucis avec les exceptions.
Pis, les gourous unix, ben, ils aiment pas les threads. D'ailleurs, John Ousterhout a publié il y a quelques années un manifeste anti thread ( http://www.softpanorama.org/People/Ousterhout/Threads/tsld001.htm(...) ).
Stéphane
# Merci pour les réponses
Posté par Anonyme . Évalué à -1.
le succès d'apache et de tout ces produits , mise a par la qualité de ces derniers , ne tiendrait il pas aussi dans la liberté de la license Apache Software License ? face au restriction connue de la GPL.
L'intérêt du soutien d'un projet tel que caudium par la communauté, face au serveur apache est t'il réellement utile ?
je précise le fonds de ma pensée : une license comme apache est sans conteste libre, soit mais peut on dire sans paraitre manichéen que caudium est plus économique et surtout moins polluant parce que tournant au GPL !!
(en bref peut t'on résumer la license Apache comme plus pratique,mais apportant moins a la communauté que la GPL ? ... )
[^] # Re: Merci pour les réponses
Posté par oliv . Évalué à 1.
Je pense que tu as tout à fait raison... c'est pour cette raison que les *BSD ont beaucoup plus de succès que Linux :-P
Ceci dit, c'était bien essayé, le troll sur les licenses.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.