Sans parler de difficultés financières, il est tout de même paru un certain nombre d'appels à contribution durant ces 7 dernières années.
Ensuite, regardes la tête de la charge machine: http://linuxfr.org/images/load/load.png un dimanche soir, ça tourne en gros à près de 2 sur la journée. Je veux bien que le noyal soit un 2.6.2x dernier patch de l'ordonanceur faisant des miracles. mais même avec plusieurs processeurs, la charge ne tient que grâce à l'optimisation de templeet. Vérifie voir en semaine http://linuxfr.org/images/load/load-week.png comme la charge monte durablement.
Templeet est un outils démoniaque d'efficacité. Le répertoire par défaut d'Apache est le dossier de cache de Templeet. En cas d'échec (page introuvable) la requête est analyée par templeet, qui trouve un template adéquat, et génère une page. vu que la pluspart des lecteurs de linuxfr sont non loggés, le système sert un nombre colossal de pages statiques avec une puissance processeur très basse.
Cependant, la lucidité requiert de poser les défauts suivants:
1. Templeet, c'est bien, mais c'est difficile à lire. Je n'ai pas dit illisible, mais juste pénible. les ~trala(~spoutnik(~bidule(~chose(~truc())))) ne sont envisageables qu'avec de la nécessité et une bonne coloration syntaxique. Les fonctions qui facilitent la gestion des accès base de données sont prolifiques d'optimisation, mais exigent une bonne dose de caféine (et du silence) pour être productif.
2. Templeet, enfin ses templates, sont, disons, comme furieusement intriqués _dans_ la page web. On pourrait même dire que c'est difficile de mélanger plus.
Partant de là, le modèle vue controleur, la séparation entre l'habillage et l'intelligence, toussa, c'est un peu loin.
On vit à l'heure où un 1Go de Ram coute peu. on trouve des procs biCore presques froids et d'une puissance diabolique. il serait triste que le site souffre d'un manque d'évolution parce que la moindre modification d'un template risque de tout faire s'écrouler. Templeet est une solution économe en ressources processeur, ultra optimisée, mais au prix d'une pénibilité de développement assez considérable. J'ai cru lire que le nombre d'admin maitrisant ~templeet n'est pas justement pas considérable.
je ne dit pas de tout casser pour le plaisir. Non. Je pense qu'il a été mis au point depuis des solutions séparant mieux les données de leur présentation, sans pour autant sélectionner les développeurs sur l'association QI>160 ET masochisme
il y a parfois des liens qui ne fonctionnent plus sur linuxfr. Regarde http://linuxfr.org/poll/send,128.html par exemple, c'était un sondage qui traitait de pub ou non. La page n'a bien voulu se régénérer qu'en y accédant en https. En http 80, il doit y avoir une couille dans le regexp.
J'ai opéré des sites en templeet. Et puis un jour, j'ai envisagé autre chose, parce que la moindre modif peut tout écrouler. J'avais du mal à me relire au bout de quelques semaines. Depuis, j'ai découvert des solutions plus lisibles, plus scalables/
La communauté linuxfr ne mériterait-elle pas que linuxfr évolue vers une plateforme plus objet, plus XUL sexy, plus scalable, sans pour autant obliger les admins à se torturer l'esprit pour apporter une modif ? C'est possible, mais pas sur ce serveur qui vit des heures de plus en plus chargée. http://linuxfr.org/images/load/load-yearly.png
Avec le traffic drainé par linuxfr, on pourrait avoir, nous, utilisateurs de linuxfr, un outil plus au gout du jour de la geekerie du 21 eme siècle, plus plaisant à développer pour nos admins. Je ne parle pas de pub en popup flash à contenu non contrôlé, non, je parle d'ads google qui paient du matos neuf pour notre usage.
Voilà.
Halte à la pensée qui force linuxfr à tourner sur du matos vétuste avec un moteur hyper optimisé à bout de souffle.
[^] # Re: [x] Le wiki (avec un poil de pub)
Posté par Rafael (site web personnel) . En réponse au sondage Hormis les dépêches, quel type de contenu appréciez-vous le plus sur le site ?. Évalué à 1.
Ensuite, regardes la tête de la charge machine: http://linuxfr.org/images/load/load.png un dimanche soir, ça tourne en gros à près de 2 sur la journée. Je veux bien que le noyal soit un 2.6.2x dernier patch de l'ordonanceur faisant des miracles. mais même avec plusieurs processeurs, la charge ne tient que grâce à l'optimisation de templeet. Vérifie voir en semaine http://linuxfr.org/images/load/load-week.png comme la charge monte durablement.
Tiens, voici un appel à contribution: http://linuxfr.org/2005/11/03/19843.html
Templeet est un outils démoniaque d'efficacité. Le répertoire par défaut d'Apache est le dossier de cache de Templeet. En cas d'échec (page introuvable) la requête est analyée par templeet, qui trouve un template adéquat, et génère une page. vu que la pluspart des lecteurs de linuxfr sont non loggés, le système sert un nombre colossal de pages statiques avec une puissance processeur très basse.
Cependant, la lucidité requiert de poser les défauts suivants:
1. Templeet, c'est bien, mais c'est difficile à lire. Je n'ai pas dit illisible, mais juste pénible. les ~trala(~spoutnik(~bidule(~chose(~truc())))) ne sont envisageables qu'avec de la nécessité et une bonne coloration syntaxique. Les fonctions qui facilitent la gestion des accès base de données sont prolifiques d'optimisation, mais exigent une bonne dose de caféine (et du silence) pour être productif.
2. Templeet, enfin ses templates, sont, disons, comme furieusement intriqués _dans_ la page web. On pourrait même dire que c'est difficile de mélanger plus.
Partant de là, le modèle vue controleur, la séparation entre l'habillage et l'intelligence, toussa, c'est un peu loin.
On vit à l'heure où un 1Go de Ram coute peu. on trouve des procs biCore presques froids et d'une puissance diabolique. il serait triste que le site souffre d'un manque d'évolution parce que la moindre modification d'un template risque de tout faire s'écrouler. Templeet est une solution économe en ressources processeur, ultra optimisée, mais au prix d'une pénibilité de développement assez considérable. J'ai cru lire que le nombre d'admin maitrisant ~templeet n'est pas justement pas considérable.
je ne dit pas de tout casser pour le plaisir. Non. Je pense qu'il a été mis au point depuis des solutions séparant mieux les données de leur présentation, sans pour autant sélectionner les développeurs sur l'association QI>160 ET masochisme
Etant donné qu'il y a déjà de la pub sur linuxfr (He oui, regardez sur la page de recherche http://www.google.fr/custom?cof=AH%3Acenter%3BLP%3A1%3BLW%3A(...) ) Il faudrait réfléchir à nouveau sur la question.
il y a parfois des liens qui ne fonctionnent plus sur linuxfr. Regarde http://linuxfr.org/poll/send,128.html par exemple, c'était un sondage qui traitait de pub ou non. La page n'a bien voulu se régénérer qu'en y accédant en https. En http 80, il doit y avoir une couille dans le regexp.
J'ai opéré des sites en templeet. Et puis un jour, j'ai envisagé autre chose, parce que la moindre modif peut tout écrouler. J'avais du mal à me relire au bout de quelques semaines. Depuis, j'ai découvert des solutions plus lisibles, plus scalables/
La communauté linuxfr ne mériterait-elle pas que linuxfr évolue vers une plateforme plus objet, plus XUL sexy, plus scalable, sans pour autant obliger les admins à se torturer l'esprit pour apporter une modif ? C'est possible, mais pas sur ce serveur qui vit des heures de plus en plus chargée. http://linuxfr.org/images/load/load-yearly.png
Avec le traffic drainé par linuxfr, on pourrait avoir, nous, utilisateurs de linuxfr, un outil plus au gout du jour de la geekerie du 21 eme siècle, plus plaisant à développer pour nos admins. Je ne parle pas de pub en popup flash à contenu non contrôlé, non, je parle d'ads google qui paient du matos neuf pour notre usage.
Voilà.
Halte à la pensée qui force linuxfr à tourner sur du matos vétuste avec un moteur hyper optimisé à bout de souffle.
Rafael (oui, un peu motive, ce soir)