andeus a écrit 312 commentaires

J'avais exactement le même problème chez wanadoo avec un bête routeur ethernet. Sauf qu'en me connectant sur le ssh de 1&1 (l'hébergeur qui offrait un hébergement de 3 ans gratuit, qui au passage est plutôt royal pour un hébergement mutualisé) j'ai remarqué que ma session pouvais rester ouverte plusieurs heures sans rien faire dessus. C'est donc un problème de configuration de serveur. Après avoir ajouté ceci dans sshd_config je n'ai plus de problème:

ClientAliveInterval 60
ClientAliveCountMax 1440

D'après tes chiffres, il donne 1% de sa fortune.
Je pense que peu de personne donne "autant", relativement à leur salaire/biens.

Entre les impôts et les charges sociales je donne au minimum 50% de ce que je gagne. Forcément c'est pas encourageant...

Celle là elle est pas mal aussi: http://video.google.fr/videoplay?docid=7419576217577969363&a(...)

Je ne comprend pas pourquoi ça ne serait pas envisageable de compiler le tout en static pour un hébergeur ?

Je sais pas, je me disais que ça prendrais sûrement plus de mémoire pour chaque process apache en ayant tous les modules en statique.

Donne moi des applications php

Squirrel mail par exemple ne fonctionne pas du tout sur php5. C'est un petit truc tout bête, mais quand tu ne sais pas faire, tu ne sais pas, et voila.
phpBB non plus ne fonctionnait pas sur php5 pendant assez longtemps. Il doit y avoir pas mal d'appli dans le même cas.

Et puis bon il est simple de tester une application php4 sous php5.

Oui mais comme je le disais beaucoup de sites sont faits par des gens qui ne programment pas du tout, qui utilisent des applis toutes faites comme phpBB, et qui seraient incapables de corriger ce genre de problème.

Oui mais compiler tous les modules en statique n'est pas forcément envisageable pour un hébergeur. En plus comme tu le dis c'est super galère car il faut faire du versioning des symboles, ça n'est pas supporté, etc.

Donc bon a part ce genre de soucis il n'y a pas vraiment de raisons de ne pas passer a php5...

Pour un hébergeur, si.

Si mon hébergeur passe à PHP5 alors que je n'ai pas rendu mon site compatible, je risque de ne pas être content.

De même si je n'utilise que des scripts tout faits, que je n'ai jamais codé en PHP et que je ne sais pas du tout ce qu'il faut faire pour rendre ces scripts compatibles. Il y a beaucoup de personnes dans ce cas.

Un hébergeur payant ne peut pas passer de PHP4 à PHP5 comme ça sans garder les deux.

Il y a plusieurs raisons à cela:

La base du problème est que les scripts écrits pour PHP4 ne fonctionneront pas forcément pareil avec PHP5. Donc un hébergeur doit garder PHP4 pour ne pas casser les sites hébergés, et éventuellement proposer PHP5 à côté.

Pour plus de performances beaucoup d'hébergeurs utilisent PHP en module Apache. Le problème c'est qu'on ne peut pas charger les modules PHP4 et PHP5 en même temps. La seule solution est d'en utiliser au moins un des deux en CGI, et certains hébergeurs ne le peuvent/veulent pas.

La deuxième raison, qui affecte cette fois les développeurs/webmasters est simplement que quand ça marche, ça marche et il qu'il n'y a pas forcément de raison de changer. Beaucoup d'applications, modules et classes pear ne sont toujours pas officiellement compatibles PHP5, voir pas dutout, donc ça limite déjà pas mal son utilisation.

En fait c'est surtout les applications/sites faits from scratch qui utilisent PHP5, ou ceux qui en ont vraiment besoin qui ont migrés.

On pourrait citer aussi le fait que les améliorations de PHP5 ne sont intéressantes que pour les utilisateurs avancés (model objet, streams, iconv, xml, pdo, etc).

Il y a quelque chose dans error_log de apache ?
Aucune erreur PHP dans le source de la page ? (ou dans error_log si tu as log_errors activé dans php.ini )

A mon avis c'est le système anti flood ou anti leeching du serveur qui n'aime pas trop ;)

Sinon il y a shuffle(), tout simplement :)

D'après la page d'accueil du site il tourne bel et bien sous Linux :)

- 6 Ne penser vous pas que le choix d'un linux va restreindre la possibilité d'exportation de votre produit , sur une echelle mondiale le choix d' une standardisation Microsoft Windows n'aurait il pas été plus judicieux ???

http://www.aldebaran-robotics.com/forum/viewtopic.php?p=142#(...) ...

C'est clair, depuis que je sais utiliser vi correctement j'ai de plus en plus de mal à retourner sur un éditeur classique. En fait il faudrait 3 mains ou 2 mains et un pied très agile pour utiliser en même temps un clavier et une souris ;)

Par contre d'après les screenshots cet IDE a quand même un vrai plus, c'est qu'il a la bonne idée d'afficher le support des différents navigateurs dans le menu d'autocomplétion, il inclut les références javascript/html/etc, et l'import automatique de quelques libs :)

Je pense que tout le monde est d'accord là dessus mais ça m'étonnerais que l'arrêt du projet change quelque chose dans cette histoire.

Si ça peut faire chier des entreprises étasuniennes et israéliennes qui font du pognons avec, tant mieux.

Heu oui enfin dans l'hébergement mutualisé tu as soit Linux/PHP, soit Windows/ASP. Si PHP disparaît je ne suis pas sûr que ça fasse du tord aux usa.

La société israèlienne il me semble que c'est Zend, qui produit un optimiseur et un éditeur PHP. Je ne pense pas qu'ils dépassent le chiffre des ssll françaises qui utilisent PHP.

Et vu le nombre de projets libres en PHP, je pense que non, la mort de PHP n'est vraiment pas une bonne chose.

Son utilité est surtout l'anti spoofing d'identité, et donc le phishing, en empêchant par exemple d'envoyer des mails avec l'adresse d'une banque dans le From:. Mais bon, ça a ses limites.

Et comme antispam c'est vrai qu'on fait beaucoup mieux, rien ne vaut un spamassassin au niveau efficacité, mais niveau vitesse/ressources c'est pas trop ça.

Sinon pour les mailing lists, il suffit de mettre l'adresse de la mailing list dans le From, et l'adresse de l'envoyeur dans le corp du message par exemple.

Non par vraiment, c'est un enregistrement DNS qui définit quels serveurs peuvent envoyer des mails de la part du domaine. Sauf que là au lieu de définir une liste de serveurs on autorise tout le monde, comme s'il n'y avait pas de sender id en fait.

Finalement une fois qu'on a ajouté ça dans le DNS, sender id ou pas ça change rien.

Je pense que ça empêche quand même les spameurs de spamer en spoofant les adresses mail qui ont une configuration sender id qui restreint un peu plus. Mais ils peuvent continuer à spamer avec leurs propres domaines.

Par contre pour les utilisateurs lambda ça change rien.

Pour boycotter le sender id sans se boycotter soit même:

@ IN TXT "v=spf1 +all"

Sans enregistrement vos mails se font rejeter par les serveurs qui l'utilisent pour filtrer le spam. Avec cet enregistrement vos mails ne sont plus rejetés et vous pouvez envoyer des mails avec n'importe quel serveur.

Et l'air qui est entre les deux couches agit comme un isolant, sur le même principe que le double vitrage.

laxatif

Quand tu as chaud les veines qui sont le plus proche de l'extérieur du corps se dilatent pour évacuer la chaleur. ça permet de garder les organes à bonne température, sinon ils ne fonctionnent pas bien.
Donc si tu bois quelque chose de froid, tes organes ont moins chaud et ton corps ressent moins le besoin de se refroidir => tu as plus chaud.
Et réciproquement. D'ailleurs au Maroc ils boivent du thé à la menthe, chaud, pour se rafraîchir. Et ça marche :)

Peut être que c'est pas un problème de sender id. Sur hotmail il te le dit quand un message a été bloqué à cause du sender id.

Désolé, en fait j'ai trouvé tout ce que je cherchais après avoir posté ce journal.

Donc d'après ce que j'ai compris le sender id n'est autre que le SPF (Sender Policy Framework [1]) , ou alors j'ai pas compris la différence entre les deux.

En fait il faut autoriser explicitement dans la zone DNS d'un domaine les serveurs autorisés à envoyer des mails avec un From correspondant à ce domaine. C'est finalement tout bête à mettre en place, même si le principe est discutable.

Par exemple si je veux que tous les enregistrements A de exemple.com soient autorisés à envoyer des mails avec un From *@exemple.com, il suffit d'ajouter ceci dans la zone:
exemple.com. IN TXT "v=spf1 a ~all"

Après si vous avez un formulaire sur votre site permettant aux utilisateurs de s'envoyer des mails il faut jongler avec le From, la partie nom du From, et le Reply-To.
Par exemple:
From: "Utilisateur" <noreply@monsite.com>
Reply-To: "Utilisateur" <utilisateur@utilisateur.com>


[1] OpendSPF
http://www.openspf.org/

Le wizard made in microsoft (il y en a un aussi sur [1])
http://www.microsoft.com/mscorp/safety/content/technologies/(...)

Une doc sur la syntaxe à utiliser
http://www.zytrax.com/books/dns/ch9/spf.html

Vérifier que tout est ok
http://www.dnsstuff.com/pages/spf.htm

Des exemples vivants
$ host -t TXT hotmail.com (ou gmail.com, aol.com, etc.)

Oui enfin ça fait pas tout à fait la même chose. D'après ce que j'ai compris ça ne fait que télécharger et afficher une rfc.
Pour faire ça, il suffit d'un navigateur, Konqueror par exemple, ajouter un raccourci vers "http://www.ietf.org/rfc/rfc\{@}.txt" avec le mot clé rfc. ça fonctionne aussi avec Firefox avec un bookmark "http://www.ietf.org/rfc/rfc%s.txt".
Ensuite "rfc 1" affiche la rfc 1.

clamdscan est une commande fournie avec le paquet clamav-daemon.

Et pour le cache des rfc, apparemment c'est dans le répertoire courant, ça serait pas mal de le faire dans ~/.qrfcview/cache ou autre, mais pas le répertoire courant. On sais jamais d'où on peut le lancer et ça peut mettre le basard un peu partout à force ;)