On Mon, 14 Mar 2005 01:36:12 +0100 "Rakotomandimby (R12y) Mihamina" wrote:
Ben tiens: faq.fcolc.eu.org fait partie des 10. et le portlet des documents récents (sur la gauche) fait un requête des documents récents à chaque visite. là comme cest calme, ça bouffe pas grand chose et c'est mis en cache. mais sur ce même serveur il y a des sites qui ont ce portlet en perpétuelle activité donc pas possible de le mettre en cache...
Je pense que tu devrais revoir un peu ton code pour que cet « portlet » (?) ne soit pas généré directement à partir de la base, mais mis en cache au niveau du serveur. « Mettre en cache », c'est une expression ronflante pour dire par exemple « regénérer un fichier toutes les 30 minutes (à régler suivant l'activité) que le serveur web pourra aller lire avant de répondre aux requêtes ».
Il vaut mieux mettre en cache-disque un fichier de 100 Ko qui est valable une demi-heure qu'essayer de faire tenir une base de 50 Mo en mémoire dans le but de la parcourir (entièrement) plusieurs fois par seconde.
-- Jérémy JUST
On Mon, 14 Mar 2005 01:36:12 +0100
"Rakotomandimby (R12y) Mihamina" <mihamina@mail.rktmb.org> wrote:
Ben tiens: faq.fcolc.eu.org fait partie des 10. et le portlet des
documents récents (sur la gauche) fait un requête des
documents récents à chaque visite. là comme cest calme, ça bouffe pas
grand chose et c'est mis en cache. mais sur ce même serveur il y a des
sites qui ont ce portlet en perpétuelle activité donc pas possible de
le mettre en cache...
Je pense que tu devrais revoir un peu ton code pour que cet
« portlet » (?) ne soit pas généré directement à partir de la base, mais
mis en cache au niveau du serveur.
« Mettre en cache », c'est une expression ronflante pour dire par
exemple « regénérer un fichier toutes les 30 minutes (à régler suivant
l'activité) que le serveur web pourra aller lire avant de répondre aux
requêtes ».
Il vaut mieux mettre en cache-disque un fichier de 100 Ko qui est
valable une demi-heure qu'essayer de faire tenir une base de 50 Mo en
mémoire dans le but de la parcourir (entièrement) plusieurs fois par
seconde.
On Mon, 14 Mar 2005 01:36:12 +0100 "Rakotomandimby (R12y) Mihamina" wrote:
Ben tiens: faq.fcolc.eu.org fait partie des 10. et le portlet des documents récents (sur la gauche) fait un requête des documents récents à chaque visite. là comme cest calme, ça bouffe pas grand chose et c'est mis en cache. mais sur ce même serveur il y a des sites qui ont ce portlet en perpétuelle activité donc pas possible de le mettre en cache...
Je pense que tu devrais revoir un peu ton code pour que cet « portlet » (?) ne soit pas généré directement à partir de la base, mais mis en cache au niveau du serveur. « Mettre en cache », c'est une expression ronflante pour dire par exemple « regénérer un fichier toutes les 30 minutes (à régler suivant l'activité) que le serveur web pourra aller lire avant de répondre aux requêtes ».
Il vaut mieux mettre en cache-disque un fichier de 100 Ko qui est valable une demi-heure qu'essayer de faire tenir une base de 50 Mo en mémoire dans le but de la parcourir (entièrement) plusieurs fois par seconde.
-- Jérémy JUST
Nicolas George
Jérémy JUST wrote in message :
« Mettre en cache », c'est une expression ronflante pour dire par exemple « regénérer un fichier toutes les 30 minutes (à régler suivant l'activité) que le serveur web pourra aller lire avant de répondre aux requêtes ».
Le mieux serait de le regénérer quand c'est nécessaire, ce qui est assez facile si on maîtrise tout le conde : il suffit, quand les données dont le fichier dépend ont été modifiées, de mettre en queue l'ordre de regénérer. Il faut un petit peu de traitement pour fusionner les demandes redondantes et ne pas avoir cinquante processus en train de regénérer chacun une version différente du fichier, dont une seule ne sera pas jetée immédiatement à l'arrivée. Rien d'insurmontable.
D'une manière général, je suis très mécontent de tous les machins appelés pompeusement « Content Management System » qu'on trouve un peu partout, et qui servent comme pages dynamiques du contenu essentiellement statique (nouvelles, articles). Ne devraient être dynamiques que les pages qui dépendent réellement complètemenet de paramètres rapidement variables.
Jérémy JUST wrote in message
<20050314023412.26de415e@norbert.inapg.inra.fr>:
« Mettre en cache », c'est une expression ronflante pour dire par
exemple « regénérer un fichier toutes les 30 minutes (à régler suivant
l'activité) que le serveur web pourra aller lire avant de répondre aux
requêtes ».
Le mieux serait de le regénérer quand c'est nécessaire, ce qui est assez
facile si on maîtrise tout le conde : il suffit, quand les données dont le
fichier dépend ont été modifiées, de mettre en queue l'ordre de regénérer.
Il faut un petit peu de traitement pour fusionner les demandes redondantes
et ne pas avoir cinquante processus en train de regénérer chacun une version
différente du fichier, dont une seule ne sera pas jetée immédiatement à
l'arrivée. Rien d'insurmontable.
D'une manière général, je suis très mécontent de tous les machins appelés
pompeusement « Content Management System » qu'on trouve un peu partout, et
qui servent comme pages dynamiques du contenu essentiellement statique
(nouvelles, articles). Ne devraient être dynamiques que les pages qui
dépendent réellement complètemenet de paramètres rapidement variables.
« Mettre en cache », c'est une expression ronflante pour dire par exemple « regénérer un fichier toutes les 30 minutes (à régler suivant l'activité) que le serveur web pourra aller lire avant de répondre aux requêtes ».
Le mieux serait de le regénérer quand c'est nécessaire, ce qui est assez facile si on maîtrise tout le conde : il suffit, quand les données dont le fichier dépend ont été modifiées, de mettre en queue l'ordre de regénérer. Il faut un petit peu de traitement pour fusionner les demandes redondantes et ne pas avoir cinquante processus en train de regénérer chacun une version différente du fichier, dont une seule ne sera pas jetée immédiatement à l'arrivée. Rien d'insurmontable.
D'une manière général, je suis très mécontent de tous les machins appelés pompeusement « Content Management System » qu'on trouve un peu partout, et qui servent comme pages dynamiques du contenu essentiellement statique (nouvelles, articles). Ne devraient être dynamiques que les pages qui dépendent réellement complètemenet de paramètres rapidement variables.
John Mackerel
Webatou wrote:
La chose à faire lors de l'installation est de virer tout ce qui ne sert à rien, comme les serveurs web et compagnies.
Encore une belle croyance. En quoi virer un Apache inactif
va-t-il accelerer magiquement la machine ? Par effet placebo ?
Webatou wrote:
La chose à faire lors de l'installation est de virer tout ce qui ne sert à
rien, comme les serveurs web et compagnies.
Encore une belle croyance. En quoi virer un Apache inactif
va-t-il accelerer magiquement la machine ? Par effet placebo ?
Je souhaiterais débuter avec Linux Mandrake 10.1 mais mon pc est déjà ancien.
Config : Céléron 700 Mhz 128 Mo Ram HD 40 Go + HD 3.2 Go Est - ce un minimum suffisant ou faut il voir plus grand ?
C'est suffisant. Le HD de 3.2 Go pourrait quasiment suffire.
-- Kevin
Rakotomandimby (R12y) Mihamina
( Mon, 14 Mar 2005 02:34:12 +0100 ) Jérémy JUST :
Je pense que tu devrais revoir un peu ton code
j'ai rien codé, j'ai utilisé le code par defaut proposé avec le "content management system".
ma liste de priorités est encore longue. celle-là est ajoutée mais sera prise en compte dans longtemps :-)
-- L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance) Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
( Mon, 14 Mar 2005 02:34:12 +0100 ) Jérémy JUST :
Je pense que tu devrais revoir un peu ton code
j'ai rien codé, j'ai utilisé le code par defaut proposé avec le
"content management system".
ma liste de priorités est encore longue. celle-là est ajoutée mais sera
prise en compte dans longtemps :-)
--
L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses
activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance)
Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
j'ai rien codé, j'ai utilisé le code par defaut proposé avec le "content management system".
ma liste de priorités est encore longue. celle-là est ajoutée mais sera prise en compte dans longtemps :-)
-- L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance) Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
Rakotomandimby (R12y) Mihamina
( Mon, 14 Mar 2005 02:27:49 +0000 ) Nicolas George :
D'une manière général, je suis très mécontent de tous les machins appelés pompeusement « Content Management System » qu'on trouve un peu partout, et qui servent comme pages dynamiques du contenu essentiellement statique
- les CMS sont relativement récents, le consept n'est pas encore mûr. j'ai suivi de près Plone: il y a eu Plone 1, qui était un peu comme un "jeu" mais qui a vu sa popularité augmenter parcequ'il y avait une vraie demande. Ils ont recodé une bonne partie de Plone 1 quand ils ont vu que la scalabilité n'était pas au RDV. Maintenant on en est à Plone 2. C'est beaucoup mieux, mais comme on voit, peux mieux faire... ça murit à vue d'oeil. Mais comme tout projet open source, c'est au bon vouloir des developpeurs.
- les CMS sont censés convenir à des petits sites comme à des grands sites. Pour des petits sites comme faq.fcolc.eu.org effectivement c'est un peu tuer une mouche avec un tractopelle. Mais il se trouve qu'il faut que des petits site utilisent ces machins parceque les grands site eux se servent de Plone en Production et ne peuvent servir de plateforme de test. Au niveau des "ressources machine" c'est un beau gachis, mais je pense qu'il faut ce qu'il faut.
Nous sommes hors-charte. J'hésite à faire suivre sur fcal, parceque je sais que les intervenants d'ici ne sont pas tous abonnées la bas... et puis la modération tempère un peu les débats je trouve... donc je sais pas...fcold ? :-)
-- L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance) Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
( Mon, 14 Mar 2005 02:27:49 +0000 ) Nicolas George :
D'une manière général, je suis très mécontent de tous les machins appelés
pompeusement « Content Management System » qu'on trouve un peu partout, et
qui servent comme pages dynamiques du contenu essentiellement statique
- les CMS sont relativement récents, le consept n'est pas encore mûr.
j'ai suivi de près Plone: il y a eu Plone 1, qui était un peu comme un
"jeu" mais qui a vu sa popularité augmenter parcequ'il y avait une vraie
demande. Ils ont recodé une bonne partie de Plone 1 quand ils ont vu que
la scalabilité n'était pas au RDV. Maintenant on en est à Plone 2.
C'est beaucoup mieux, mais comme on voit, peux mieux faire... ça murit à
vue d'oeil. Mais comme tout projet open source, c'est au bon vouloir
des developpeurs.
- les CMS sont censés convenir à des petits sites comme à des grands
sites. Pour des petits sites comme faq.fcolc.eu.org effectivement c'est un
peu tuer une mouche avec un tractopelle. Mais il se trouve qu'il faut que
des petits site utilisent ces machins parceque les grands site eux se
servent de Plone en Production et ne peuvent servir de plateforme de test.
Au niveau des "ressources machine" c'est un beau gachis, mais je pense
qu'il faut ce qu'il faut.
Nous sommes hors-charte. J'hésite à faire suivre sur fcal, parceque je
sais que les intervenants d'ici ne sont pas tous abonnées la bas... et
puis la modération tempère un peu les débats je trouve... donc je
sais pas...fcold ? :-)
--
L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses
activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance)
Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
( Mon, 14 Mar 2005 02:27:49 +0000 ) Nicolas George :
D'une manière général, je suis très mécontent de tous les machins appelés pompeusement « Content Management System » qu'on trouve un peu partout, et qui servent comme pages dynamiques du contenu essentiellement statique
- les CMS sont relativement récents, le consept n'est pas encore mûr. j'ai suivi de près Plone: il y a eu Plone 1, qui était un peu comme un "jeu" mais qui a vu sa popularité augmenter parcequ'il y avait une vraie demande. Ils ont recodé une bonne partie de Plone 1 quand ils ont vu que la scalabilité n'était pas au RDV. Maintenant on en est à Plone 2. C'est beaucoup mieux, mais comme on voit, peux mieux faire... ça murit à vue d'oeil. Mais comme tout projet open source, c'est au bon vouloir des developpeurs.
- les CMS sont censés convenir à des petits sites comme à des grands sites. Pour des petits sites comme faq.fcolc.eu.org effectivement c'est un peu tuer une mouche avec un tractopelle. Mais il se trouve qu'il faut que des petits site utilisent ces machins parceque les grands site eux se servent de Plone en Production et ne peuvent servir de plateforme de test. Au niveau des "ressources machine" c'est un beau gachis, mais je pense qu'il faut ce qu'il faut.
Nous sommes hors-charte. J'hésite à faire suivre sur fcal, parceque je sais que les intervenants d'ici ne sont pas tous abonnées la bas... et puis la modération tempère un peu les débats je trouve... donc je sais pas...fcold ? :-)
-- L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance) Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
Webatou
John Mackerel a écrit:
Webatou wrote:
La chose à faire lors de l'installation est de virer tout ce qui ne sert à rien, comme les serveurs web et compagnies.
Encore une belle croyance. En quoi virer un Apache inactif
va-t-il accelerer magiquement la machine ? Par effet placebo ?
Parce que l'installation (ou la mise à jour) peut aussi automatiser le lancement de apache à chaque démarrage comme je viens d'en faire les frais avec un apt-get dist-upgrade.
Maintenant, c'est clair que Apache inactif, ça ne consomme pas plus de ressources, on est d'accord, mais si on ne compte pas s'en servir, autant le désinstaller, ça fera de la place ;-)
-- Usenet dans votre navigateur ! http://www.webatou.net/
John Mackerel a écrit:
Webatou wrote:
La chose à faire lors de l'installation est de virer tout ce qui ne sert
à rien, comme les serveurs web et compagnies.
Encore une belle croyance. En quoi virer un Apache inactif
va-t-il accelerer magiquement la machine ? Par effet placebo ?
Parce que l'installation (ou la mise à jour) peut aussi automatiser le
lancement de apache à chaque démarrage comme je viens d'en faire les frais
avec un apt-get dist-upgrade.
Maintenant, c'est clair que Apache inactif, ça ne consomme pas plus de
ressources, on est d'accord, mais si on ne compte pas s'en servir, autant
le désinstaller, ça fera de la place ;-)
--
Usenet dans votre navigateur !
http://www.webatou.net/
La chose à faire lors de l'installation est de virer tout ce qui ne sert à rien, comme les serveurs web et compagnies.
Encore une belle croyance. En quoi virer un Apache inactif
va-t-il accelerer magiquement la machine ? Par effet placebo ?
Parce que l'installation (ou la mise à jour) peut aussi automatiser le lancement de apache à chaque démarrage comme je viens d'en faire les frais avec un apt-get dist-upgrade.
Maintenant, c'est clair que Apache inactif, ça ne consomme pas plus de ressources, on est d'accord, mais si on ne compte pas s'en servir, autant le désinstaller, ça fera de la place ;-)
-- Usenet dans votre navigateur ! http://www.webatou.net/
Nicolas George
R12y wrote in message :
- les CMS sont censés convenir à des petits sites comme à des grands sites.
Ce n'est pas contradictoire avec les considération sur contenu statique vs. contenu dynamique dont je me plains.
Mais il se trouve qu'il faut que des petits site utilisent ces machins parceque les grands site eux se servent de Plone en Production et ne peuvent servir de plateforme de test.
Euh, « il faut » pour qui. Évidemment, c'est dans l'intérêt des gros sites, qui bénéficient de développement, de test, à l'oeil. Mais est-ce dans l'intérêt des petits sites ? Si ça ne l'est pas, c'est de la merde, contraire au principe des logiciels libres.
R12y wrote in message <pan.2005.03.14.09.31.42.391628@mail.rktmb.org>:
- les CMS sont censés convenir à des petits sites comme à des grands
sites.
Ce n'est pas contradictoire avec les considération sur contenu statique vs.
contenu dynamique dont je me plains.
Mais il se trouve qu'il faut que
des petits site utilisent ces machins parceque les grands site eux se
servent de Plone en Production et ne peuvent servir de plateforme de test.
Euh, « il faut » pour qui. Évidemment, c'est dans l'intérêt des gros sites,
qui bénéficient de développement, de test, à l'oeil. Mais est-ce dans
l'intérêt des petits sites ? Si ça ne l'est pas, c'est de la merde,
contraire au principe des logiciels libres.
- les CMS sont censés convenir à des petits sites comme à des grands sites.
Ce n'est pas contradictoire avec les considération sur contenu statique vs. contenu dynamique dont je me plains.
Mais il se trouve qu'il faut que des petits site utilisent ces machins parceque les grands site eux se servent de Plone en Production et ne peuvent servir de plateforme de test.
Euh, « il faut » pour qui. Évidemment, c'est dans l'intérêt des gros sites, qui bénéficient de développement, de test, à l'oeil. Mais est-ce dans l'intérêt des petits sites ? Si ça ne l'est pas, c'est de la merde, contraire au principe des logiciels libres.
l'indien
On Mon, 14 Mar 2005 13:21:48 +0100, Webatou wrote:
John Mackerel a écrit:
Webatou wrote:
La chose à faire lors de l'installation est de virer tout ce qui ne sert à rien, comme les serveurs web et compagnies.
Encore une belle croyance. En quoi virer un Apache inactif
va-t-il accelerer magiquement la machine ? Par effet placebo ?
Parce que l'installation (ou la mise à jour) peut aussi automatiser le lancement de apache à chaque démarrage comme je viens d'en faire les frais avec un apt-get dist-upgrade.
Maintenant, c'est clair que Apache inactif, ça ne consomme pas plus de ressources, on est d'accord, mais si on ne compte pas s'en servir, autant le désinstaller, ça fera de la place ;-)
Si il consome des ressources quand personne ne s'y connecte, c'est qu'il est mal fait. Un daemon sur lequel on ne se connecte pas devrait tout au plus utiliser une page mémoire de code (la boucle qui fait le select sur la socket de connection) et une page mémoire de donnée (qui contient le fd correspondant à cette même socket) et quasiment aucun CPU (en tout cas, de façon indétectable par l'utilisateur).
On Mon, 14 Mar 2005 13:21:48 +0100, Webatou wrote:
John Mackerel a écrit:
Webatou wrote:
La chose à faire lors de l'installation est de virer tout ce qui ne sert
à rien, comme les serveurs web et compagnies.
Encore une belle croyance. En quoi virer un Apache inactif
va-t-il accelerer magiquement la machine ? Par effet placebo ?
Parce que l'installation (ou la mise à jour) peut aussi automatiser le
lancement de apache à chaque démarrage comme je viens d'en faire les frais
avec un apt-get dist-upgrade.
Maintenant, c'est clair que Apache inactif, ça ne consomme pas plus de
ressources, on est d'accord, mais si on ne compte pas s'en servir, autant
le désinstaller, ça fera de la place ;-)
Si il consome des ressources quand personne ne s'y connecte, c'est qu'il
est mal fait.
Un daemon sur lequel on ne se connecte pas devrait tout au plus utiliser
une page mémoire de code (la boucle qui fait le select sur la socket de
connection) et une page mémoire de donnée (qui contient le fd
correspondant à cette même socket) et quasiment aucun CPU (en tout cas,
de façon indétectable par l'utilisateur).
On Mon, 14 Mar 2005 13:21:48 +0100, Webatou wrote:
John Mackerel a écrit:
Webatou wrote:
La chose à faire lors de l'installation est de virer tout ce qui ne sert à rien, comme les serveurs web et compagnies.
Encore une belle croyance. En quoi virer un Apache inactif
va-t-il accelerer magiquement la machine ? Par effet placebo ?
Parce que l'installation (ou la mise à jour) peut aussi automatiser le lancement de apache à chaque démarrage comme je viens d'en faire les frais avec un apt-get dist-upgrade.
Maintenant, c'est clair que Apache inactif, ça ne consomme pas plus de ressources, on est d'accord, mais si on ne compte pas s'en servir, autant le désinstaller, ça fera de la place ;-)
Si il consome des ressources quand personne ne s'y connecte, c'est qu'il est mal fait. Un daemon sur lequel on ne se connecte pas devrait tout au plus utiliser une page mémoire de code (la boucle qui fait le select sur la socket de connection) et une page mémoire de donnée (qui contient le fd correspondant à cette même socket) et quasiment aucun CPU (en tout cas, de façon indétectable par l'utilisateur).
Rakotomandimby (R12y) Mihamina
( Mon, 14 Mar 2005 13:56:49 +0000 ) Nicolas George :
Mais est-ce dans l'intérêt des petits sites ? Si ça ne l'est pas, c'est de la merde, contraire au principe des logiciels libres.
oui. les petits sites peuvent ainsi bénéficier de la technologie des grands. mais au prix de ressources surdimenssionnées (obligation de louer un serveur dédié ou semi-dédié alors que dans l'absolu, un serveur mutualisé suffit). c'est un maigre benefice, mais qui a le mérite d'exister.
par exemple, une amie économiste, qui ne voulait pas se prendre la tête avec le HTML a réussi à faire de son site un site d'envergure grace au CMS. Il a suffit que je lui prete une instance de plone sur mon serveur... elle a pu bénéficier de toute la panoplie des outils qu'il faut pour rediger "au kilomètre"...
mais de toutes façon, faut arreter de demander le beurre, l'argent du beurre, la crémière et la soeur de la crémière. On a des outils pour se passer de "coder en HTML" (c'est ce qui rebutent la plupart des littéraires qui veulent mettre de la doc en ligne) mais au prix de bouffage de ressources. Les developpeurs sont conscients de ce trop grznd besoin de ressources et travaillent dessus :-), ils le disent...
-- L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance) Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
( Mon, 14 Mar 2005 13:56:49 +0000 ) Nicolas George :
Mais est-ce dans
l'intérêt des petits sites ? Si ça ne l'est pas, c'est de la merde,
contraire au principe des logiciels libres.
oui. les petits sites peuvent ainsi bénéficier de la technologie des
grands. mais au prix de ressources surdimenssionnées (obligation de louer
un serveur dédié ou semi-dédié alors que dans l'absolu, un serveur
mutualisé suffit). c'est un maigre benefice, mais qui a le mérite
d'exister.
par exemple, une amie économiste, qui ne voulait pas se prendre la tête
avec le HTML a réussi à faire de son site un site d'envergure grace au
CMS. Il a suffit que je lui prete une instance de plone sur mon serveur...
elle a pu bénéficier de toute la panoplie des outils qu'il faut pour
rediger "au kilomètre"...
mais de toutes façon, faut arreter de demander le beurre, l'argent du
beurre, la crémière et la soeur de la crémière. On a des outils pour
se passer de "coder en HTML" (c'est ce qui rebutent la plupart des
littéraires qui veulent mettre de la doc en ligne) mais au prix de
bouffage de ressources. Les developpeurs sont conscients de ce trop grznd
besoin de ressources et travaillent dessus :-), ils le disent...
--
L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses
activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance)
Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
( Mon, 14 Mar 2005 13:56:49 +0000 ) Nicolas George :
Mais est-ce dans l'intérêt des petits sites ? Si ça ne l'est pas, c'est de la merde, contraire au principe des logiciels libres.
oui. les petits sites peuvent ainsi bénéficier de la technologie des grands. mais au prix de ressources surdimenssionnées (obligation de louer un serveur dédié ou semi-dédié alors que dans l'absolu, un serveur mutualisé suffit). c'est un maigre benefice, mais qui a le mérite d'exister.
par exemple, une amie économiste, qui ne voulait pas se prendre la tête avec le HTML a réussi à faire de son site un site d'envergure grace au CMS. Il a suffit que je lui prete une instance de plone sur mon serveur... elle a pu bénéficier de toute la panoplie des outils qu'il faut pour rediger "au kilomètre"...
mais de toutes façon, faut arreter de demander le beurre, l'argent du beurre, la crémière et la soeur de la crémière. On a des outils pour se passer de "coder en HTML" (c'est ce qui rebutent la plupart des littéraires qui veulent mettre de la doc en ligne) mais au prix de bouffage de ressources. Les developpeurs sont conscients de ce trop grznd besoin de ressources et travaillent dessus :-), ils le disent...
-- L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance) Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
