Qu'est ce que AssHoleDaemon (c'est le premier truc auquel j'ai pensé en voyant l'acronyme Ashd) apporte de plus par rapport aux Nginx, Cherokee et consorts (à part la page web digne d'une bonne vieille manpage) ? Il y'a une multitude de projets de serveurs web simples et modulaires.
Je ne m'y connais pas des masses en serveurs web, mais j'avais idée de m'amuser un peu avec nginx, qu'est-ce que ce ashd aurait de mieux à vendre (la page web n'est pas très explicite. Ok il y'a plusieurs process qui communiquent entre eux 'over a simple protocol', donc ok on peut faire tourner certains de ces process sous des comptes différents, mais à part ça ? C'est juste un gain de sécurité (j'ai pas dit que c'était négligeable, mais je pense pas que l'architecture des autres serveurs sus-cités soit forcément moins bonne en terme de sécu...) ?
Je veux dire par là que les autres arguments sont un peu marketing (ce qui n'est pas le cas de la page web), je ne crois pas que nginx (oui je reprend celui-là en exemple) soit "mal conçu" ou que sa configuration soit très compliquée. Pour la persistance des process, là je n'en pense rien, à voir les bénéfices/inconvénients que cela peut apporter.
Par contre, comme ça garde la philosophie unix en découpant tout ça en programme sachant chacun faire une chose, le gros avantage doit être de pouvoir réutiliser un/plusieurs composants pour des scripts/projets, c'est ce qui me plait le plus dans le design actuel du bébé...
En tout cas bonne chance à lui pour la suite !
Christophe si tu as suivi un peu le développement du truc peut-être pourrais tu m'éclairer à ce sujet (quel cadre d'utilisation envisager aussi, plutot pour du fastcgi par la suite, plutot pour servir du contenu statique en backend (genre les images/css/js), etc, ? )!
# Désolé
Posté par Guillaume Chanaud (site web personnel) . En réponse à la dépêche Un nouveau serveur httpd : Ashd, A Sane HTTP Daemon. Évalué à 5.
Je ne m'y connais pas des masses en serveurs web, mais j'avais idée de m'amuser un peu avec nginx, qu'est-ce que ce ashd aurait de mieux à vendre (la page web n'est pas très explicite. Ok il y'a plusieurs process qui communiquent entre eux 'over a simple protocol', donc ok on peut faire tourner certains de ces process sous des comptes différents, mais à part ça ? C'est juste un gain de sécurité (j'ai pas dit que c'était négligeable, mais je pense pas que l'architecture des autres serveurs sus-cités soit forcément moins bonne en terme de sécu...) ?
Je veux dire par là que les autres arguments sont un peu marketing (ce qui n'est pas le cas de la page web), je ne crois pas que nginx (oui je reprend celui-là en exemple) soit "mal conçu" ou que sa configuration soit très compliquée. Pour la persistance des process, là je n'en pense rien, à voir les bénéfices/inconvénients que cela peut apporter.
Par contre, comme ça garde la philosophie unix en découpant tout ça en programme sachant chacun faire une chose, le gros avantage doit être de pouvoir réutiliser un/plusieurs composants pour des scripts/projets, c'est ce qui me plait le plus dans le design actuel du bébé...
En tout cas bonne chance à lui pour la suite !
Christophe si tu as suivi un peu le développement du truc peut-être pourrais tu m'éclairer à ce sujet (quel cadre d'utilisation envisager aussi, plutot pour du fastcgi par la suite, plutot pour servir du contenu statique en backend (genre les images/css/js), etc, ? )!