Anonyme a écrit 62292 commentaires

J'arrive pas à lire la vidéo. Il me demande d'installer Real Player, Windows Media Player, Quick time ou Flash.

Super. Avec un Moz 1.0 sous Linux:

"Unsupported Browser - We've detected that you are using a browser that IFILM does not fully support.

While IFILM can be viewed across all platforms, we strongly recommend the following browsers to utilize all of IFILM's extensive features:

Microsoft Internet Explorer versions 4.0 and above
Netscape Navigator 4.08 to 4.77.
Netscape 6.2

While you will still be able to enjoy IFILM with browsers such as Opera, Netscape 6.0/6.1, Konquerer or iCab, your experience may not be optimal. We also do not support WebTV at this time."

Hum hum. C'est quoi déjà l'histoire du film?

Servlets. Weblogic (beurk). Donc des jsp, transformés en servlets (comme tout les serveurs J2EE le font). Recherche BDD, ce genre de choses.

Je me doutais que tu allais répondre ça. Je pense que c'est totalement irréalisable dans le principe.

Par contre, le coup de la génération de l'HTML par la BDD ou un process extérieur au serveur Web l'est.

A la limite, même le coup des sémaphores le fichier ça pourrait marcher, mais faudrait pas que ton site ait beaucoup de posts a gérer en même temps.

Ben ici on a un site a très fort trafic (15M de hits/jours, 4000 utilisateurs simultanés répartis sur 8 serveurs), et on est pas sous Apache.

Les benchs faits étaient plus stressants que la réalité (2 à 3 fois), et Apache plantait lamentablement comme une grosse loutre bourrée à la bière, même customizé à donf les manettes.

J'aimerai bien voir 1 forum avec une page de consultation en statique, juste pour rigoler.

Tiens, comme ça, une question: comment tu évites qu'en cas de postage simultané, les 2 process qui gèrent ça écrivent en même temps la page de consultation?

75000€ par an? Merde, j'aurais dû faire ça comme boulot moi. C'est que ça fait quand même plus de 490000Frs/ans, soit à peu près 41000Frs brut par mois.

Je pourrais savoir pourquoi je me prends plein de [-]? Ce que je dis est vrai: Apache 1 et PHP n'ont JAMAIS été prévus pour tenir la charge et par conséquent ne la tienne pas.

Je parle de vrai charge en test, hein, des trucs du genre 4000 utilisateurs simultanés avec requêtes aux BDD, pas des tests avec ab quoi.

> Où est l'interaction des utilisateurs qui nécessitent vraiment un site 100% dynamique ?

Les forums. Sinon, il y a le cache. Tu vois, je finirais bien par te faire dire que tu es d'accord avec moi, tu y es presque là...

> Même un forum n'a pas d'interret à être 100 % dynamique.

Euh... si. Tu passerai pas un générateur de page HTML au moment du post? En PHP? Sur un serveur multiutilisateur comme un forum Web? Donc conccurent?

Et comment tu fais? Je vois pas comment faire pour servir des pages statiques à partir d'un moteur dynamique? Si ton url se termine par PHP, c'est que c'est du PHP, donc il faut le parser.

Avec le cache justement, énormément de requêtes sont servies en statique (enfin, elles ne repassent pas par le générateur, mais uniquement par quelques scripts PHP).

Niveau dépendance, oui, il y a dans la BDD.

AMHA, je trouve SPIP déjà assez compliqué comme ça pour ne pas le modifier sur ce niveau là. Le système fonctionne bien, il pourrait fonctionner mieux, mais peut-être au prix de développements qui ne sont pas nécessaires pour l'instant.

Ce qui est bien quand on discute avec toi, c'est que t'es pas compliqué comme gars ;-)

Et non, il n'y a pas de page de dépendances.

Faudrait plutôt le demander sur la ML SPIP alors. Cependant, c'est vrai, c'est idiot vu de la modification des articles. Mais il y a aussi la structure du site (les nouveaux articles, les brèves, les sections, etc.). Comment vois-tu le changement dans une page si ce changement est une nouvelle brève, une section créée?

Faut voir ça du point de vue d'une entreprise assez importante où les administrateurs des machines sont bien distincts des utilisateurs. La frontière n'est pas floue.

De toutes façons, ni PHP ni Apache (1) sont prévus pour tenir la charge. Comme SPIP et PHPNuke tournent sous PHP, ça règle le problème.

> Je ne crois pas qu'on puisse retoucher un article après l'avoir écrit, sous PhpNuke, alors qu'avec SPIP c'est possible : les articles appartiennent à des utilisateurs.

Perdu. Une fois l'article publié, seuls les administrateurs du site peuvent modifier l'article.

J'ai même pas compris la question. Décidemment, Oracle, ça use...

Le système de cache SPIP est expliqué dans la doc, mais je retrouve plus le lien. D'après ce que je me souviens, tu donnes une durée de vie à ta page avant regénération (une heure, une journée, une minute) selon ce que tu veux qu'elle fasse.

Si une modif intervient sur la page, le cache n'est pas invalidé et la modif sera donc effective à partir du délai.

Par contre, il y a des actions qui invalident le cache. Typiquement, un post dans le forum.

Ouais! Et puis faut héberger Templeet sur Savannah parceque Sourceforge çapu c'est pas libre!

J'avais proposé un [-42] à l'époque... Avec perte d'XP... Fabien ne m'a pas répondu :-(

c'est bien le problème... le ogg passe donc pour une merde qu'il n'est pas auprès de ceux que tu vas fournir en ogg...

Mode parano : et si c'est justement cette levée de boucliers qui avait provoqué cette réaction de Thomson quant à la gratuité de la licence pour les softs libres ... ?

D'après ce que j'ai compris, la license n'a pas changé depuis 1995...

Si j'ai bien tout suivi, ça ne change rien pour RedHat qui doit retirer les lecteurs mp3 de son "produit" ou payer à Thomson...

Ce qui est fort, c'est que même chez xiph, ils se sont faits avoir...
http://www.xiph.org/ogg/vorbis/openletter.html(...)

... qui veulent décrédibiliser ogg/vorbis.

Bah oui, tous les crétins qui veulent se débarasser de leurs mp3 amassés par P2P en faisant une conversion dégueulasse en vorbis pour à nouveau les partager en P2P.

Car oui, c'est d'une connerie incommensurable de convertir un mp3 en vorbis, on mélange les artefacts créés par les 2 formats de compression et on a un résultat de daube.

Rien de mieux pour faire de la bonne pub à vorbis...

cela dit, il me semble que c'est "l'intelligence" du jeu qui réside dans ce code lisp... c'est bien entendu à vérifier...

Oui, bon, dire que le jeu est en lisp est un peu abusé (huhu) mais quand même, doit pas y en avoir beaucoup d'autres avec des bouts de lisp dedans (sachant que dans le tas en c++, y a un interpreteur lisp...)

J'ai déjà vu une interface graphique réalisée en Lisp. Mais je te rassure, c'était laid, lent et buggé.

J'ai déjà vu un jeu réalisé en Lisp. Je te rassure, c'était beau, rapide (ça tournait très bien sur mon 486) et ça roxorisait. Même que ça roxor toujours, puisqu'il tourne toujours. Ce jeu, c'est Abuse http://abuse2.com/sshots.php3(...)