Edouard Gomez a écrit 450 commentaires

Et oui 2000, mais c'est pas dur a obtenir non plus.

Pendant les 8h de sommeil où ma machine est eteinte, et 5h d'uptime, je me retrouve déjà avec 440 copies du worm.

La distribution journaliere ressemble a ca:
- 27/01 le soir vers 2h du matin: je me retrouve avec des dizaines de copies dans ma boite "utile"... le temps de faire un filtre correct publié sur linuxfr d'ailleur
- 27/01 la journéé: plusieurs centaines
- 28/01 la je fais peter les > 1200 copies (vala la barre des 2000 copies presque franchie)
- 29/01 (aujourd'hui): deja ~440

Bon mais depuis quand on repond a pierre tramo sur linuxfr ?

Reponse courte pour les impatients:
Non.

Pour les autres une petite histoire au coin du feu:
- Il etait une fois quake1. à l'epoque les moteurs de jeu faisait de la fausse 3D communement appelé 2D 1/2 car les niveaux etaient bidimensionnel (une carte planaire de secteurs) dont on pouvait juste specifier la position Z du sol et du plafond (doom1/2, duke3d). Quake1 lui c'etait de la vraie 3D pour les niveaux, des persos en 3D, des vraies ombres précalculées par radiosité, et aussi un des premiers jeu à profiter des cartes 3D de l'epoque.

- IdSoftware decide d'etendre un peu le moteur de quake1 en lui rajoutant des lumieres multicolores, des effets de transparence pour l'eau et quelques elements du monde 3d, un systeme de particule revu. Id affine un peu la création de ses BSP en retravaillant un peu la structuration de l'arbre binaire. Les modeles quand a eux n'evoluent que tres peu (on externalise les textures du modele, c'est tout)

- quake3 quand a lui se voit rajouter un systeme de shaders de texture, de petits scripts permettant de jouer sur les parametres de texturation afin de creer des effets dynamiques. Nouveau type de modeles qui gerent independemment les differentes parties du modele. Introduction de courbes de beziers dans les niveaux permettant d'obtenir des niveaux aux coins un poil plus doux (les portes arrondis et la grosse langue dans le premier niveau de quake3 par exemple). Mais rien de transcendant, ca reste une evolution (enfin les shaders permettent une grande liberté). La lumiere est toujours statique et precalculée come dans quake1. Ah j'oubliais le brouillard volumetrique <-- nouveau.

- Doom3 c'est un tout autre truc. Fini le monde aux lumieres precalculées. Et la mine de rien ca change TOUT. Car la gestion des lumieres est en fait ce qui rend un univers 3d credible pour nos petits cerveaux. Le modele d'illumination passe d'un mode de lightmap precalculées à un modèle d'illumination par pixel temps reel, c'est a dire que chaque pixel à l'ecran sera illuminé en temps reel et en fonction des lumieres de la piece. Doom3 c'est aussi l'utilisation massive de normal maps pour des effets de bump mapping qui augmente plus que considerablement le realisme des objets en leur ajoutant une sorte de "grain" de surface (lisse, strié, boiseux etc etc) bien que le modele reste plus ou moins polygonal.

Doom3 represente une vraie cassure en passant au tout "par pixel".

Donc, de plus comme l'ont montré les releases des sources de quake1 et quake2, non ca ne fait pas d'ombre au moteur suivant, car les concepteurs de jeux se doivent d'utiliser la derniere technologie dispo sous peine de passer pour des has been et saboter leur pouvoir marketing a priori. Et dans le monde du jeu, teaser les joueurs a coup de terme techniques innovants reste le meilleur moyen d'asseoir ses ventes futures.

Bon je resume,

D'un coté on a splash damage qui ne pouvant finir Enemy Territory decide de le refiler gratos. Ceci n'a pu etre rendu possible que parce que Id software avait donné son accord. Je rappelle en effet qu'Ennemy Territory se base sur le moteur de RTCW lui même directement basé sur le moteur de quake3, et que donc IdSoftware a surement un droit de regard quand a la distribution pour pas un rond d'une de leur technologie.

On peut résumer ces deux étapes par: IdSoftware n'accorde plus trop de valeur commerciale au moteur de quake3.

L'habitude d'IdSoftware dans ces cas là est de distribuer les sources sous license GPL... et mon petit doigt me dit que ca devrait plus tarder, surtout que doom3 arrive et que c'est dans leur interet de vouloir vendre leur nouveau moteur de jeu.

Ce qu'il y a de bien dans cette future release des sources de quake3, c'est que vu le nombre de total conversions dispo, je suis sur qu'on aura droit à un FPS quake3 powered totalement libre d'ici peu.

Enfin je dis ca mais je dis rien :-)

Bon j'ai fini par rendre la regle un poil plus efficace, a savoir que sous linux j'ai jamais besoin d'executables windows, et que les zip c gentil mais pas qd ca ressemble au MyDoom:

# Piege a worm con qui se fout sous la forme d'un exe win32
:0 BD:
  *   name=".*\.(scr|bat|pif|cmd|exe)"
  "${MAIL_DIR}/junk"

# le piege a MyDoom proprement dit
:0 BHD :
  * -700^0
  *  100^0 > 30000
  *  100^0 < 36000
  *  100^0 ^Subject: (Mail Delivery System|Hi|Hello|hello|Test|test|Status)
  *  100^0 ^X-Priority: 3
  *  100^0 ^X-MSMail-Priority: Normal
  *  100^0 Content-Type: text/plain;
  *  100^0 charset="Windows-1252"
  *  100^0 Content-Type: multipart/mixed;
  *  100^0 ^The message cannot be represented in 7-bit ASCII encoding and has been sent as a binary attachment\.
  *  100^0 ^The message contains Unicode characters and has been sent as a binary attachment\.
  *  100^0 ^Mail transaction failed. Partial message is available\.
# just test the zip extension as usual extensions get trapped by the
# "dumb worms" rule
  *  100^0 name=".*\.zip"
  "${MAIL_DIR}/junk"

Enjoy

Bon je m'etais couché dans l'espoir que mon filtre serait assez efficace aujourd'hui. Fetchmail se lance.... mauvais signe ca downloade plein pot pdt 1 minute. Resultat des courses:
- 117 worms interceptes
- 50 ont passé la règle (je compte aussi les reponses automatiques des gateways anti virus, qui sont tout autant une plaie que les worms)

AU SECOURS ! pourquoi tout le monde forge ses worms a partir de mon adresse email :\

Je viens de recevoir une variante sans titre... avec de l'aleatoire... bref cette saleté de worm est dure à caser dans une regle de filtrage :-(

>Un grand merci à toute l'équipe de dev, et tout particulièrement Edouard Gomez, fidèle lecteur de linuxfr.

Merci pour le merci.

L'intégrisme n'est en aucune facon une solution au probleme du spam. Les open relay sont bien souvent des linux mal configurés.

Sauf que ca change fondamentalement la topologie du réseau qui délivre les emails. D'après la news, c'est la machine finale qui impose un challenge à l'éxpediteur... sauf que manque de bol, l'email fonctionne sur une topologie bien différente, une topologie hiérarchique. Ainsi, leur solution, correspond bien mieux aux messageries instantannées.

Dans ce cas, les intermediaires seraient ils responsables du filtrage ? Car je vois mal comment tout ca s'accomoderait de vérifications intérmédiaires... et en bout de chaine, comment un utilisateur ne ferait au final pas confiance au serveur mail de son ISP.

Et puis l'idée timbre, ca défie toute legislation:
>Si le destinataire le trie comme courrier indésirable, l'expéditeur devra payer

Puisque seul le receveur décide ou non du sort du email, ca devient vite le far west ce système. C'est le règne de l'arbitraire. "Je t'aime pas, je te fais payer !"

Le spam ne peut etre soigné qu'à la source. Cad interdire la pratique, et poser un cadre legislatif qui permette de faire fermer la porte à ces sociétés qui en font leur fond de commerce et qui militent pour des hommes au sexe toujours plus grand :-) Pareil pour ceux qui maintiennent des relais ouverts, pratique stupide qui devrait être interdite. Je crois même qu'une loi est récemment passée, ou est cours d'élaboratation traitant du SPAM.

>Et dire que 82% des gens ont voté Chirac sans y réfléchir !

Oh si c'était plus que réfléchi, c'était Chirac ou un facho [mettre ici le qualitif le mieux adapté, de préférence péjoratif]...

Le problème ne venait pas d'un manque de réflection, mais plutot d'un véritable manque de choix parce que certains couillons ont voté FN au premier tour sans réfléchir aux conséquences de leur vote "protestataire" (ou juste qu'ils adhèrent aux idées gerbantes du FN). La démocratie est une épée à double tranchant, on en a payé le prix le 21 Avril 2002.

Oops petite erreur de copiage, faut rajouter un H sur la premiere ligne puisque Subject fait partie du header.

:0 BH :
  * -200^0
  *  100^0 Subject: Hi
  *  100^0 Test \=\)
  *  100^0 Test, yep\.
  "${MAIL_DIR}/junk"

Petit filtre procmail fait maison pour bagle:

:0 B :
  * -200^0
  *  100^0 Subject: Hi
  *  100^0 Test \=\)
  *  100^0 Test, yep\.
  "${MAIL_DIR}/junk"

En gros ca score les mails entrants, si le sujet est Hi, et que y'a les deux parties fixes du virus dans le corps du email... le score passe dans le positif et zou dans ta boite junk...

pour le <li>, il faut annuler le padding-left du conteneur il me semble, cad la plupart du temps le padding-left de la balise <ul>

Le deuxieme je sais pas.

Pour repondre a ton interrogation finale... non ;-)

Ca fait bien 1an que thomas ostreich ne maintient plus transcode. Il a laissé sa place à Tilmann Bitterberg qui fait du très bon boulot. Le site original maintenu par Thomas n'est plus mis à jour, sauf à de très rare occasions et le site à consulter est donc devenu celui de Tilmann:
http://transcoding.org/(...)

Voila, en plus le site http://transcoding.org/(...) a subi un lifting xhtml 1.1 + CSS qui le rend beau (tout en restant simple) et respectueux des dernieres recommandations du w3c. Donc mangez en, c'est bon (et rempli de docs croustillantes).

Sur marmiton.org:
http://www.marmiton.org/recettes/recette2.cfm?num_recette=11807&(...)

Le temps de cuisson indiqué est largement sous estimé et sujet a forte variation en fonction de la taille du moule, sinon tu te tappes un fondant au chocolat et noix :-)

D'abord je dis:
>Lorsqu'il est éxécuté par root

Puis j'enfonce le clou avec:
> Finement exploité, on peut injecter un shell script et le faire s'éxécuter pour gagner les droits roots.

Ra personne n'a vu la finesse de mon post... on gagne quoi a devenir root en étant déjà root ? ;-)

L'est pas secure ton programme...

                              -------- SECURITY BUG ALERT --------

Lorsqu'il est éxécuté par root (hein y a des gens qui font ca ?!), la fonction rev() chargée
de renverser la chaine passée en argument ne vérifie pas la longueur de cette dernière, 
pouvant entrainer un buffer overflow. Finement exploité, on peut injecter un shell script et
le faire s'éxécuter pour gagner les droits roots. Ceci est d'autant plus facile, que la chaine 
est passée en argument !

           -------- SECURITY BUG ALERT ternimée, circulez y a rien à voir --------

C'est encore du logiciel codé par un stagiaire ! ;-) Bon je ==>[]

Bizzare Bizzare, je le vois pas sur la gateway BitKeeper apres le 2.6.1-rc1. D'ou le lien proposé vers le patch 2.4. Enfin c'est pas bien grave :-)

Pour ceux qui conaitraient pas, on peut suivre ce que linus applique comme patchs ici:
http://linux.bkbits.net:8080/linux-2.5(...)

J'ai regardé le code du noyau 2.6 vs 2.4, cette fonction n'a pas changé pour la portion concerné... donc en attendant un nouveau 2.6, on peut toujours appliquer un patch a la main (2 lignes utiles):
http://linux.bkbits.net:8080/linux-2.4/diffs/mm/mremap.c@1.7?nav=in(...)

Mon vieux compte de 1998 est passé à la trappe avec la récente(?) politique de conservation des comptes... sniff, mais peu importe je me suis reinscrit ^_^

Je suis #341294. D'ailleurs je remarque que comme dans le temps le macaron perso est toujours au format GIF, vilaine habitude :-)

>et pour ce qui est des resolutions, pour savoir si la carte supporte, tu fais :
>2048*1536*32 = 96M

Et non, 32bits == 4octets :-)

2048*1536*32/8 ~= 12MiB

Tout de suite ca fait plus realiste.

3 fois rien

Pas besoin, c'est qu'une beta... je posterai une news pour la 1.0.0 final.

>quelques pointeurs vers des documentations techniques sur le MPEG-4

Hmm, désolé j'ai pas çà sous le coude. Mais bon si tu veux LES détails, le standard est ton ami pour quelques brouzoufs suisses sur iso.org. Sinon, sur le web toute doc sur MPEG1/MPEG2 et MPEG4 sont bonnes à étudier car la vulgarisation masque les différences majeures entre ces standard. Les principes, eux, restent les mêmes.

>Aussi, je voulais savoir si tu étais en charge juste de la couche d'interface avec mencoder et trancode

Oui, enfin je bosse sur xvidcore avant tout, je ne fais pas que les frontends ;-).

>mais que tu ne décidais pas de l'intégration de telle ou telle nouvelle fonctionnalité (trellis ou psnr, ...) à mencoder?

Pour transcode, je suis en bon terme avec le mainteneur donc je fais ce que bon me semble...

Par contre pour mplayer, disons que je préfère pas m'embêter avec à envoyer les patchs directement. Cela est principalement dû au fait que:
- mplayer-dev est fichtrement plus chiant quant à leur acceptation des patchs. Autant laisser qq un d'autre jouer le proxy. Y'a aussi une ambiance que j'apprécie pas des masses (entre l'elitisme affiché de certains, et les grandes gueules...)
- ca donne l'occasion à d'autres de reviewer/tester car XviD attire peu de codeurs, donc je souhaite pas tout monopoliser.

>quelques pointeurs vers des documentations techniques sur le MPEG-4

Nos tests n'ont rien montrés de tel. Ceci est dû au fait que notre seconde passe prend des décisions un peu grossières et donc une première passe moins précise (mais bcp plus rapide) n'impacte pas au final sur la qualité.

Il coupe la ou il est bon pour les codecs de couper. Tes splitpoints ne sont en fait en que les intra frames des codecs MPEG1/2/4 (pour certains codec le nom diffère mais leur principe est le même, voir ce qui suit...). Les intra frames sont en fait les seules frames dans le stream qui ne dependent de rien pour leur décodage, c'est à partir d'elles qu'on compresse les autres frames. Voila pourquoi on ne peut couper qu'à certains points bien précis. Les codecs sont le plus souvent responsables du bon usage des keyframes car elles consomment beaucoup de bits. En général les codecs détectent avec plus ou moins de succes les chgts de plan, et y insèrent une intra frame (pour diverses raisons).

Alors que se passerait il si tu coupais ailleurs ?
-Pour la premiere partie, pas grand chose, tu pourra la lire eventuellement jusqu'aux 2-3 dernieres frames.
-Pour la deuxieme partie, le debut sera indécodable car il lui manque les frames de références qui dérivent au fur et a mesure de la derniere Intra Frame (je simplifie) et desquelles dépendent son décodage.

Voila, je ne te donne pas de solution a ton probleme, mais au moins tu peux maintenant comprendre pourquoi "c'est comme çà et pas autrement"(tm).

Tchuss