Fabien Penso a écrit 1947 commentaires

Bah c'était pour rire, mais on m'avait conseillé http://www.les7laux.com/ comme station pas chere pour le snowboard, et j'y suis allé 2 semaines pour 140E/semaine par personne forfait compris. Donc c'était plutôt un bon plan quand même.

T'es sur Tokyo ? C'est cool, je ne savais pas où dormir si je voulais visiter la ville. Sympa ! ;)

Et je ne te dis même pas le nombre qu'on en a corrigé...

Oui mais tu as parfois des programmes indépendants qui ont besoin du feeds, là on a somenews, les boites linuxfr, etc.

Euh : lftp fish://login@server/

J'ai vu aussi, je pense qu'il faudrait envoyer un mail en indiquant qu'il ne faudrait pas bloquer les IPs de linuxfr, qui doivent faire 2 ou 3 accès par heure sur le site.

Bah elle avait été approuvée et n'aurait pas dû l'être, donc )> trash.

Je me réponds.

Il semblerait que ce soit mieux si j'utilise un mtu de 1400. A voir...

Propre, l'objet, bof... Je trouve que le côté modulaire de Templeet est 100 fois plus propre que celui de daCode. Mébon...

Honnêtement avoir à générer plus de 10 connections secondes c'est bon pour un slashdot ou un linuxfr, mais pour 80% des cas c'est un peu inutile.

Raisonnement habituel, et pourtant très stupide, malheureusement. En effet pouvoir gérer 10 connections/secondes ça veut aussi dire que pour les 30 pelerins par jour qui viennent sur ton site, les pages s'afficheront beaucoup plus rapidement. Quoi de plus chiant qu'un site dont les pages sont lentes, alors qu'un site dont les pages sont instantannées, quel bonheur!

Pas exactement.

Le lancement du chrono ne consomme pratiquement rien, c'est juste une information qui permet de savoir si une page s'affiche plutôt rapidement, ou lentemenet, plus rapidement qu'avant, etc. Ce n'est pas le temps réel vu que le chargement de PHP dans Apache consomme déjà, par exemple, et n'est pas compris dans le chrono.

Ce que tu appelles l'argument, c'est en fait l'url demandé, tout simplement, s'il ne reconnait pas l'url, alors il affiche une erreur404, normal (mais templatisée quand même pour pouvoir la changer). S'il trouve le template, il l'évalue. Ensuite les fonctions dans les templates. Comme PHP est d'une lenteur incroyable pour lire son propre code, les modules ne sont chargés que lorsqu'une fonction s'y trouvant est appelée dans un template, on gagne réellement en rapidité comme cela. Tu n'as pas d'appel du module ou autre, c'est juste que le module est chargé la première fois qu'on en a besoin, ensuite il ne l'est plus vu qu'il est en mémoire, et la fonction marchera toujours.

Pour le cache, on peut toujours activer le cache des templates, d'ailleurs je pense qu'on va l'intégrer dans l'installeur. Ensuite le cache des pages, on peut aussi l'activer sans vraiment avoir de système de page 404, mais c'est plus lent vu qu'il faut quand même charger PHP, ce qu'il faut éviter vu que c'est une -biip- côté performance.

néanmoins SPIP assure deux millions de pages par mois pour le Monde Diplomatique, ce qui n'est pas rien non plus

Pour mon information, sur quelle machine, et avec quel type de charge ? C'est important quand même :)

même cvs que templeet, nom du package "linuxfr"

Bah les benchs ça vaut ce que ça vaut hein, mais bon ça montre un ordre de grandeur.

Il n'y a aucun visage invisible, t'as fait des commentaires à chier, t'as été noté négativement, et donc tu as perdu des XPs, c'est tout. Tu ne peux t'en prendre qu'à toi.

Mais quand tes XPs auront suffisamment remonté pour pouvoir poster, je ne doute pas que tu feras désormais attention à tes contributions.

Fais un traceroute sur linuxfr, tu comprendras pourquoi ça marche à peu près tout le temps, pour toi.

Au début de Templeet j'avais fait une version OO pour voir, les temps d'éxecution était environ 2 à 2.5 fois plus lent. Le OO en PHP, ça pue, et c'est lent.

La liste d'exemple de site qui utilisent templeet sur http://templeet.org/ (NdM: remplacé en 2021 par un lien archive.org prouve que justement les sites n'ont rien à voir, et on ne devinerait pas qu'ils utilisent templeet.

C'est justement ce que je ne souhaite pas faire, c'est un bon contre exemple. SPIP s'apparente à un daCode, phpnuke, etc. La seule chose supplémentaire (que je n'aime pas) c'est qu'il y a des balises quand on tape un article. Je ne vois rien de différent (les balises on peut les faire en HTML aussi avec les autres CMS).

Ce que je vois c'est quelque chose de simple qui permette de publier de l'information quellle qu'elle soit, c'est tout, et de la lier entre elle. Exemple, je décide de publier un article, puis après coup je décide d'y associer une gallerie d'images, un vote, et un commentaire. Puis le lendemain je publie une photo seule, puis après-coup je souhaite y rajouter un commentaire car elle a suscité dans les forums des réactions d'incompréhension, par exemple.

Je ne vois pas quel outil permet d'effectuer cela.

Pour information je réfléchis avec Pascal coauteur de templeet sur un package de gestion de contenu assez innovant. Ce sera un gestionnaire de contenu générique avec lequel on pourra publier de l'information, quelque soit le type d'information (photos, vote, commentaires, forum, articles, etc, on peut tout imaginer), le tout relié par sujet.

Je ne veux pas trop en parler pour le moment, mais je n'ai point vu de tel système encore. En gros ça permettra d'éviter de se dire "tiens je veux faire un weblog, j'installe ci, je veux une galerie, j'installe ça, etc". En gros on veut publier de l'information, pour un site perso ou un gros site, on installe ce système, et tout le reste se fait tout seul. On pourra linker des informations entres elles, etc.

Plus d'informations ultérieurement :=)

Bah si, il y a certainement plusieurs milliers de sites qui l'utilise.

On se demande bien pourquoi d'ailleurs... Vu qu'il existe des forks qui semblent bien mieux codé. Même avec les pieds, phpnuke ne pourrait pas être plus mal écrit. Et la lecture des articles du développeur confirme son ignorance du web.

Cependant il y a des choses qui m'étonnent toujours.

C'est le sendmail des sites de news. Qu'il devienne closed source, créve devant les forks et la concurence et voila.

Euh, franchement, comparer sendmail qui a demandé des années de développement, qui implémente le protocol SMTP, avec phpnuke qui est une sombre bouse dont personne ne voudrait, c'est fort.

Sendmail a sans doute eu des soucis de sécurité par le passé, comme beaucoup d'autres applications (nis, samba, etc), mais il est à ma connaissance devenu relativement ok de ce côté là.

phpnuke c'est un bout de php mal pensé, bugué au plus haut point, et l'exemple type du truc qu'on veut pas dans la communauté du libre. Tant mieux qu'il passe propriétaire… Puis quand on trouvera le premier bug de la version proprio, je rigolerai doucement… :)

LinuxFr, http://templeet.org/ (NdM: remplacé en 2021 par un lien archive.org) powered :)

Mouais, bof. Avec free tu as l'adsl à 30E par mois, si tu es en dégroupé tu n'as pas les 512 initiaux prévus, mais 1024 comme ce que tu as. Et si tu as la freebox, ça dépend des quartiers, etc, tu as 3M jusqu'au jour ou la télé arrive, et c'est pas pour de suite. Donc en fait on a les mêmes trucs que toi. Tout le problème en france c'est le dégroupage qui met du temps à arriver, à cause de FT, mais on n'est pas loin quand même. fab, qui attend sa freebox :)

Oui, la photo, les voyages, rencontrer des gens, tout ça quoi. Bah c'est bien, bienvenue dans la cure de désintox, et c'est mieux comme ça. Restez aussi loin de votre PC que possible, et ne vous laissez pas bouffer, c'est tout :) La vie est courte de toute manière, alors faut gérer les priorités.

Ce n'est pas le soucis, le apache/php se vautre, donc bon ...

Mais je te confirme qu'il y est, il faut en général le mettre < 5sec d'ailleurs je pense, si le script dure plus longtemps il y a vraiment un problème ailleurs. Mais bon PHP n'est pas super rapide non plus...