Pierre Tramal a écrit 529 commentaires

à l'heure qu'il est, pBpG doit se cacher dans son misérable trou, comme un cafard qui voit de la lumière...

La règle empeche le virus d'arriver sur le poste client (souvent sous Windows), ce qui empeche le neuneu (comprendre débutant/e) d'ouvrir la piece jointe et de continuer à transmettre le virus. Si tous les serveurs SMTP du monde mett(ai)ent cette regle, le virus sera(it) stoppé très rapidement...

Pour ceux qui comme moi utilisent sendmail (no trolls, please !), voici la règle procmail pour filtrer le ver: (à placer dans /etc/procmailrc):


:0 B
*Hi! How are you ?
*I send you this file in order to have your advice
*See you later. Thanks
/dev/null

:0 B
*Hola como estas ?
*Te mando este archivo para que me des tu punto de vista
*Nos vemos pronto, gracias.
/dev/null

Pour ceux que ca intéresse....

marchand de farces et attrapes

(nul, -1)

- php est un langage procédurale avec possibilité de faire de l'objet
jsp (donc java) est un langage full objet avec tous les avantages que cela
comporte en terme de rapidité de développement + de nombreux IDE
PHP peut etre utilisé en tant que langage objet et hériter de toutes les fonctionnalités d'un langage de ce type (cf: dacode).

- en terme de système d'information, java possède beaucoup plus d'api que
php pour tous types de connexions à d'autres applicatifs ou protocoles :
cela permet de se greffer plus facilement à tout système d'information :
CICS, MQSeries, SNMP, tivoli, bases de données, corba, RMI, XMLRPC, FTP...
PHP supporte le FTP en natif depuis la version 4.0.x, peut se connecter aux bases de données MySQL, PostgreSQL, Oracle, Interbase, DB2,... (la liste pourrait faire des pages et des pages)

- Les serveurs applicatif java peuvent se greffer sur tous les serveurs WEB
du marche, php ne doit (a vérifier) que fonctionner avec Apache et IIS
PHP peut fonctionner en tant que CGI, ce qui lui ouvre les portes de tous les serveurs du marché

- les serveurs applicatifs java peuvent fonctionner "in process" ou "out
process" : c'est a dire dans le même processus que le serveur web ou dans un
processus sépare, ce qui permet (dans le cas du out-process) de placer le
serveur web et le serveur applicatif sur des machines différentes : cela
permet d'avoir un système complet N-Tiers qui assure notamment du load
balancing et de la haute disponibilité a tous les niveaux.
PHP ne permet pas cette souplesse d'architecture, car il tourne
"in-process", (je crois que php possède maintenant un module lui permettant
de faire de l'out-process aussi, mais lorsqu'on l'utilise, je crois que
certaines fonctionnalités (par exemple la gestion des sessions) ne
fonctionnent pas <--- à vérifier quand même)
parlons-en, de la performance de Java....

- comme son nom l'indique (php = Personnal Home Page) permet le
développement plus rapide de petites applications web, mais en aucun cas de
vrai applications web scalable et fortement connectées. Des lors que le
projet commence a devenir gros, le PHP devient complexe a mettre en oeuvre.

1. PHP a été renommé en Php Html Preprocessor.
2. On ne développe pas des grosses applis web en php: moui, c'est pour ca que c'est le language de script serveur le plus utilisé sur le Web....

En terme de rapidité d'exécution, les temps de réponses de JAVA sont
aujourd'hui équivalent a ceux de PHP

Avec un octo-Pentium III Xeon @ 1.2 ghz chacun et 64gb de RAM ?

- enfin, mais ça a son importance, JAVA est soutenu par un grand nombre de
TRES grand noms de l'informatique : SUN, IBM, ORACLE...

Windows est soutenu par un GEANT de l'informatique: Microsoft. Ce n'est pas pour ca que c'est bien...

>> microsoftfr.org : host not found

bah alors ?

(ok, ok, -1)

nul n'est éternel (tm)


bon, -1

Et encore, elle est stockée sur 32 bits pour les architectures 32 bits (x86, PPC). Sur les Alpha ou les Itanium (d'ailleurs il existe une version de la TRES PROFESSIONNELLE (ironique) SuSE pour itanium), la taille d'un entier est de 64 bits.

Il n'y a pas de raison qu'il y ait un bug...
L'époque doit être stockée (AMHA) sur un entier 32 bits.

2^32=4 294 967 296 secondes... il n'y a donc pas de quoi s'inquiéter (pour l'instant)...

look @ my signature....

(NOTE: I think CO(1)N CO(1)N uses KDE & Mandrake...)

Bonjour,

Je suis administrateur de 1785 systèmes dans une boite d'informatique (spécialiste des tapis de souris et des tapis tout court, son nom c'est TapTaMouSe) et j'utilise KDE partout.
En effet, je trouve que c'est le plus professionnel, et en plus il permet de regarder LofTsToRy (des souris de laboratoire) au lieu de fabriquer des tapis de souris.

Ce projet d'origine allemande m'a tellement plu que j'ai décidé d'acheter tous les trucs de theKompany.com (attention, aux frais de ma boite, hein !), je leur ai dit que ca allait augmenter la productivité des souris, et ils m'ont cru ;) !
En plus, je me suis mis à apprendre l'allemand (Ja !!) et j'ai repeint tous mes murs avec des K sur un engrenage (c'est très beau, ca fait un peu KK (caca))... Et cette conne de femme, qui vient mettre des traces de doigts (de pieds, pardon) partout...

{ au cas où vous ne l'auriez pas remarqué, je tiens à vous signaler que tout cela est de l'ironie } - trolls WELCOME.

ben oui, t'as tout compris...

Je suis désolé mais on assiste également à la livraison exclusive de binaires, ce qui produit des problèmes encore pires. Ex: Lucent qui livre un module binaire (compilé pour le 2.2.12-20 made in redhat) et du coup tout ceux qui ont recompilé leur kernel, changé de distrib (je ne te parles même pas de ceux qui sont passé au kernel 2.4) obtiennent des pages et des pages de "unresolved symbol:".... Et là le problème est _vraiment_ incorrigeable, alors qu'avec un tout petit peu de bidouille sur les sources (zcat /vmlinuz | nm -- | grep printk, tu obtiens alors le nom de ton symbole printk, et après tu édites les sources en replacant les occurences de printk par celle adaptée au noyau (un script peut même le faire automatiquement). si la compil rate, tu n'as qu'à créer un fichier d'entête bidon avec 'extern print_k25665ggg))...
tu vois bien que chaque problème a ses solutions...

tout à fait d'accord avec toi.
de toute facon:
- moins c'est commercial
- moins ca attire les investisseurs comme des mouches sur une m?rde
- moins c'est portable
- moins c'est à la mode
plus c'est libre, plus c'est rapide et plus j'aime.

Quel est le principal (et le seul) avantage de Java par rapport au C++ ? La portabilité. Java est une plateforme (et non pas un langage), une sorte de processeur émulé par le JDK (ou plutot, le JRE). La preuve est que l'on peut faire de l'assembleur en Java ! Donc on peut très bien installer VMware (ou plex86, ou bochs) sur un Mac par exemple, et obtenir le même niveau de performance (c'est pas dur) que Java, tout en conservant la portabilité exemplaire de Java. L'avantage de ce système c'est qu'au moins les utilisateurs de PC auront de bonnes performances, alors qu'avec Java, tout le monde a des perfs dégueulasses. Remarquez que cela contente Sun et ses partenaires (ibm, etc.), car ca les fait vendre du matos.... faut bien qu'ils vivent eux aussi, après tout.
Moi, je trouve au contraire que Java et XML font beaucoup plus "geek", beaucoup plus "startup bien comme il faut". Par contre l'assembleur fait effectivement plus hacker, mais il faut savoir que les failles de sécurité sont beaucoup plus visibles en assembleur :)
Quant à XML, ce n'est vraiment pas nouveau... Le format CSV permet tout aussi bien d'échanger des données qui seront également lisibles par tous les programmes....

- oui, j'ai personnellement testé apache win32 (en tant que proxy) et je peux vous dire que c'est pas la joie...
-> mais ce qui m'intéresse, ce sont les perfs d'apache sous _unix_ et plus particulièrement _linux_ ou _*bsd_. donc je ne vois toujours pas l'intérêt de multithreader un serveur (apache forke et donc il se voit réparti sur plusieurs cpu si plusieurs cpu il y a)
- pour le xml, vous admettrez qu'on est en plein dans le modèle php/mysql où les scripts php accèdent aux données contenues dans la base mysql... le tout en moins optimisé (pas de compression ni d'optimisation) et en moins puissant (pas de queries complètes en sql). d'autant plus que l'universalité et le partage réseau est possible avec sql.

j'espère ne pas avoir été agressif ! :))

* déjà, je remarque kil y a pâ malle deux fôtes d'ortograffes.
* ensuite (et je suis _sur_ de bien savoir ce que c'est), je persiste à penser que le XML est une mode: on nous ressort le concept de base de données à la sauce businness: grâce à xml on fera ceci, grâce à xml on fera cela, etc. alors que c'est un simple fichier texte qui contient des données.
* le bench a été fait par moi même, et donc j'ai parfaitement confiance en lui
* le concept de multithreading a été ressorti par java (tiens, encore une autre mode, alors que c'est une simple émulation de processeur et d'OS) et je ne vois pas en quoi cela pourrait être intéressant pour un serveur (pour une interface graphique à la limite, cela permet au programme de travailler sans que l'utilisateur ressente de "blocage" de l'interface) mais pour un serveur...

Moi je préfère apache car:
- il est plus utilisé, donc il y a un plus grand retour de la part des utilisateurs et donc une plus grande contribution, donc plus de corrections de bugs de sécurité et autres.
- le multi-thread est à mon avis un truc à la mode (comme le XML), et je ne pense pas que le fait d'être multi-threadé pour un serveur apporte quelque-chose.
- j'ai fait un benchmark (avec ab) d'Apache et de Caudium sur un celeron533 128mb et je peux vous dire qu'Apache est sorti gagnant en termes de nombre de requêtes par secondes, quelque soit le type de fichier servi (statique/cgi)
- apache est bien plus simple à mettre en place que Caudium (installation de pike et de toutes les dépendances (ex: gtk pour un serveur :))
- l'interface de configuration de caudium est assez ergonomique, mais rien ne remplace vi httpd.conf

bref, faites ce que vous voulez, mais je reste sous apache :))

c'est bien possible... c'est même exactement ca. l'inconvénient c'est qui faut changer de pseudo chaque année :)

il me semble que st isidore est un BSDiste pur sang.... :))

c'est sur qu'avec la redhat 7, y'a de quoi passer à freebsd :) mais pas avec debian :))

j'ai été comment ? la deuxième solution, non ? :)

sur gimp-print.sourceforge.net il y a d'excellents drivers pour cups. je les utilise personnellement à travers un réseau smb et je peux vous dire que ca égale la qualité du driver windows.

man patch, ca te dit quelque chose ?

allez, va... sans rancune...

C'est ridicule de la part de RedHat...

On n'avait déjà la 7.0 bourrée de trucs en version bêta, alpha, pre...

mais alors maintenant, on est obligé de payer pour mettre à jour tous ces trucs instables.

c'est comme si bill gates décidait de faire payer windows update....

<troll>
heureusement qu'il reste Debian !
</troll>