Éric a écrit 4850 commentaires

> Certes, l'abonnement a augementé, un peu plus que le cout de la vie, mais pas tant que ca.

C'est dommage que je n'ai pas les chiffres, si quelqu'un a les chiffres sur 5 ans j'aimerai bien qu'il les poste. De mon impression non, la hausse de l'abonnement est très loin d'être négligeable. Surtout pour des gens qui comme moi ont un portable et utilisent le téléphone surtout pour internet.

> le seul prix a avoir augmenté est le tarif "local", mais telephonais-tu beaucoup en local??? ca ratisse pas large tu sais ;-)

Marrant, j'aurai au contraire dit que la plupart des gens téléphonent plus en local ou région proche que sur du national.


> Conclusion : les seuls a avoir vu leur facture monter sont ceux qui ne passaient pas
> de com'

Ce qui est globalement étonnant vu que dans l'industrie de la comm les couts ont plutot tendance à baisser pour service et qualité égale.


Attention, je suis loin de cracher sur FT, au contraire : on a un des meilleurs réseaux téléphoniques (ceux qui ralent contre FT n'ont pas connu les US ou le Royaume Uni) mais oui, de puis que c'est ouvert à la concurrence les services où il y a des concurrents ont fortement baissés, les autres qui sont encore plus ou moins chasse gardée ont fortement augmentés.

"certains" serveurs ? c'est pas un peu l'opposé du principe décentralisé de jabber ?
Je doute qu'ils aillent certifier certains "petits" serveurs comme celui de l'apinc par exemple.

Ils avaient aussi parlé d'imap pour gmail, .. les boites parlent souvent de plein de trucs.
Il n'y a qu'un seul fait : ça ne marche pas et c'est fait exprès.

Quand à ouvrir graduellement, je vois mal ce que ça changera au spam

> Mais du coups, à part faire de la pub, elles servent à quoi ces invitations ?

Officieusement : à éviter les bots qui spamment à travers les services de mail gratuits. Quand on en repère un on peut le griller, mais on peut aussi griller celui qui a invité plusieurs bots, et remonter la branche jusqu'au coupable pour le griller aussi.
Le résultat c'est que la lutte contre l'utilisation abusive du service devrait être bien plus efficace.

calme, calme,
Faudrait pas oublier que le ruc de google utilise un protocole jabber en interne mais qu'il reste fermé aux autres réseaux. Tu ne peux communiquer qu'avec des gens avec un compte google.
Ce n'est pas un monde ou tout le monde peut être contacte par tout le monde justement, un monde ou les gens sous google ne peuvent être contactés que par des gens sous google.

Bref, moi ça me fait quasi autant plaisir que quand on m'annonce qu'une appli propriétaire utilise un cryptage RSA pour communiquer avec une autre. Certes c'est un protocole connu, mais ça n'en fait pas quelque chose d'ouvert.

> mon experience est que si un demon lis un fichier, et qu un autre le
> modifie,remone, deplace

sauf erreur de ma part, sous unix :
- si quelqu'un renomme, déplace, modifie les permissions : ça n'influe aucunemement sur les fichiers déjà ouverts (l'inode et le contenu ne bougent pas)
- si quelqu'un modifie le fichier, tu as potentiellement une modification de ce que tu lis (le contenu peut changer, ça dépend de la présence de flush, du temps d'écriture, de la quantité d'écriture, du cache ...)


> entre PHP3 et PHP5, Apache ou Caudium ... j imagine qu y a des differences.

Strictement aucune. Il ne s'agit que de l'appel de la fonction C flock. Elle dépend du système, pas de la version de PHP et encore moins du serveur Web. Ou plutot si : elle ne marchera pas sur les serveurs Web trheadés vu que le lock et "par process", mais tu n'en trouveras pas beaucoup des serveurs Web multithread sous Unix.

à ma connaissance c'est géré par l'OS (donc en mémoire). En fait je n'en sais rien mais je n'ai rien vu sur le disque qui puisse s'y rapporter et je me dis que si c'était géré au niveau disque ça aurait les mêmes défauts que les solutions étudiées plus haut qu'on peut faire nous même au niveau disque.
Aucun problème normalement en cas de coupure inopinée du programme (le verrou devrait partir). Ceci dit tu peux tester avec un script PHP et un gros "kill" au milieu, ça évitera que je te fasse faire des bêtises.

> Du coup, je ne vois pas trop ce qu'apporte flock par rapport à ma solution

Argh, et c'est en répondant que je vois potentiellement le problème de ta solution. En fait le problème ici n'intervient que si tu fais des lectures.

Le différence entre flock et ton système c'est que flock pose un verrou même pour la lecture. Le verrou est partagé pour pouvoir faire des lectures simultanées mais il existe, et empêche l'écriture de commencer.

Le problème survient dans le scénario suivant (je prend un FS unix comme base, sous win je ne sais pas quel serait la conséquence) :
A: commence la lecture
B: cherche à commencer l'écriture donc déplace le fichier
A: aucun pb sous unix, le fichier ouvert reste accessible, on utilise l'inode à partir de là donc le déplacement n'interfère pas
B: modifie le fichier
A: continue sa lecture, avec un fichier modifié, potentiellement dans un état intermédiaire (donc non valide) ou non compatible avec le début de la lecture

Bref, ton système risque de faire des corruptions si tu fais de la lecture. Si tu ne fais que de l'écriture ça doit aller (sous réserves, comme la première fois). Avec flock le verrou en écriture n'est pas obtenu tant que les lectures ne sont pas finies.

> La doc de la fonction flock sur php.net

Le flock() utilisé par PHP n'est qu'un wrapper vers le même que tu as en C. Tu peux trouver une doc sommaire dans le man, et probablement plein de trucs dans des bons bouquins de C.

> P.S. : j'ai oublié de te remercier pour tes renseignements et ta patience Eric. C'est chose faite !

[attention, pub inside] No pb, et si vous aimez y'a un bouquin complet avec plein d'explications du même genre sur la seconde édition de mon livre : http://www.eyrolles.com/Informatique/Livre/9782212116694/livre-php-(...) [/pub]

pour ce que j'en sais (donc sous réserve), sous unix, ça a l'air d'être bon.
Par contre ça veut dire que le fichier est inaccessible en lecture le temps de traitement

c'est mal, j'ai oublié de libérer mes verrous ;)
rajoutes donc un flock($fp,LOCK_UN); juste avant chaque fclose

1- en gros si tu ouvres ton fichier avec "a" ou "r" tu peux faire un flock() directement sur le fichier que tu veux manipuler. Si tu veux l'ouvrir avec "w" tu te met d'accord avec toi même sur un fichier annexe qui ne te sert qu'au verrouillage et tu l'utilise pour flock().
Ca ressemble à quelque chose du genre (bloquant exclusif):

$dest = 'monfichier' ;
$lock = $dest.'.lock' ;
$fl = fopen($lock, "w") ;
flock($fl, LOCK_EX) ;
// à partir de là je suis sûr d'être seul
$fp = fopen($dest, "w") ;
// manipulation sur $fp
fclose($fp) ;
flock($fl, LOCK_UN) ;
fclose($fl) ;


-3- http://fr2.php.net/manual/en/ref.sem.php(...)

Même problème.
A : !file_exists ("test.lock") => ok
B : !file_exists ("test.lock") => ok
A : $f=fopen ("test.lock", "w") => ok
B : $f=fopen ("test.lock", "w") => ok

et paf, ils sont tout les deux dans la boucle en même temps.

Le délai entre le test d'existance et l'ouverture est faible mais il existe. Si tu es sur un site Web en charge, rien ne te garantie que rien ne s'y insèrera.

Quoi que tu fasses, tu auras toujours un test suivi d'une prise de décision. Le problème c'est que rien ne te permet d'être sur qu'un process concurrent ne fera pas le même test après le tien mais avant ta prise de décision.
Quoi que tu veuilles faire, il te faudra un support de l'OS pour t'assurer un verouillage correct.


Maintenant tout dépend de ce que tu veux faire. Si c'est pour garantir que tu n'exécutes pas deux compil de kernel simultanément, un vérouillage avec un bête .lock en testant l'existance suffit largement. C'est ce qu'utilisent la plupart des appli pour éviter deux lancements simultanés. Maintenant si tu fais un forum Web assez chargé avec un backend fichier, là il te faudra quelque chose de plus sûr.

> y a moyen d avoir un jeton exclusif ?

L'exemple 1 de la doc fait justement ça. Il est exclusif (en gros ton process attend que l'autre ait finit pour jouer à son tour).


> je capte pas la difference entre shared et non blocking ... quelqu un pour aider ?

Tu as l'opposition exclusif / partagé (shared) et l'opposition bloquant / non bloquant (non blocking).


Exclusif c'est quand tu veux un accès unique (généralement pour de l'écriture) : personne d'autre n'a le droit de toucher au fichier quand tu as le verrou exclusif. Partagé c'est généralement pour de la lecture : tu veux bien que plusieurs process lisent le fichier en même temps (pas besoin qu'ils fassent la queue, tu peux obtenir un verrou partagé si quelqu'un en a déjà un) mais pas qu'ils lisent pendant qu'un autre écrit (donc tu ne peux pas obtenir un verrou partagé si quelqu'un en a demandé un exclusif).
En règle générale tu peux traduire exclusif par "écriture" et partagé par "lecture"

Bloquant ou non bloquant c'est pour savoir ce que tu fais quand tu ne peux pas avoir le verrou demandé. Le mode bloquant dit "je lis/ecris, j'attendrai le temps qu'il faudra pour ça mais je vais jusqu'au bout". Le mode non bloquant dit "je lis si dispo, sinon j'annule et je reprend la main pour autre chose".


- écriture non bloquant : j'écris si c'est dispo, j'annule sinon
$fp = fopen("monfichier", "a") ;
$libre = flock($fp, LOCK_EX|LOCK_NB) ;
if (!$libre) {
fclose($fp) ;
echo "pas de verrou, on annule et on fait autre chose" ;
} else {
fwrite($fp, "ok, j'écris") ;
fclose($fp) ;
echo "fichier modifié" ;
}

- lecture bloquant : je lis, j'attend le temps qu'il faudra mais je lis
$fp = fopen("monfichier", "r") ;
flock($fp, LOCK_SH) ;
if (!$libre) {
fclose($fp) ;
echo "pb d'accès au fichier" ;
} else {
$line = fgets($fp, 1024) ;
fclose($fp) ;
echo "j'ai lu : $line" ;
}

3 solutions pour gérer la concurrence coté fichiers :


1: tu utilises flock() qui est fait pour ça.
- Attention, ça ne bloque que les process qui vérifient la présence d'un lock avec flock, si quelqu'un accède directement au fichier il réussira.
- Attention aussi si tu utilises le mode "w" lors du fopen() parce que ça écrasera ton fichier *avant* l'appel à flock(), donc avant de savoir si tu as le droit de le manipuler. Si tu veux utiliser du "w" il faut faire le flock() sur un fichier témoin (genre un .lock vide) et pas sur le fichier cible.

2: si tes process ne sont pas coopératifs (tu ne peux pas garantir que tout le monde fasse appel à flock) tu peux te reposer sur l'atomicité du déplacement de fichier sous Unix. Tu travailles ton fichier dans un fichier temporaire puis une fois terminé tu le déplace à la destination finale (en écrasant le précédent).
L'avantage c'est que tu n'as jamais de fichier dans un état corrompu, dans un état intermédiaire, ou de fichier manquant : toute requête de lecture réussira sans défaut. Le désavantage c'est que tu peux avoir plusieurs requêtes d'écriture parallèles. Il y a trois conséquences :
- tu peux faire bosser ton cpu inutilement (tu lances plusieurs constructions du fichier alors que si tu avais attendu la fin de la construction en cours tu n'aurais pas eu besoin des deux autres). Notes que ce n'est pas gravissime dans pas mal de cas (genre pour une reconstruction de cache c'est souvent acceptable)
- si deux constructions/modifications se font en parallèles seule une "gagnera" au final. Tu ne peux pas t'en servir pour faire des ajouts à ton fichier (sinon un seul des deux ajouts se fera). Encore une fois, c'est une contrainte tout à fait acceptable si tu reconstruis entièrement le fichier à partir d'une source tierce à chaque fois (genre à partir d'une bdd).
- si deux constructions/modifications se font en parrallèle, tu n'es pas assuré de laquelle va "gagner" en remplacant le fichier destination en dernier. Il est possible que la construction lancée en premier finisse en dernier, et donc soit celle qui va décider du contenu du fichier destination. Ca par contre ça peut être handicapant, à toi de voir.

3: tu utilises un sémaphore (oui c'est bourrin, mais ça marche)

Sauf que tu ne résoud rien. Exemple concret :

A: je vérifie que le .lock existe => il n'existe pas
B: je vérifie que le .lock existe => il n'existe pas
A: j'ouvre le .lock en W pour création => ok
B: j'ouvre le .lock en W pour création => ok, le système écrase
A: je manipule en croyant être seul => ok
B: je manipule en croyant être seul => ARGHHH, ce n'est pas le cas

*hint* :
Un site fait avec XHTML ne peut pas être qualifié de site *web*. Parce qu'entre autre il n'est pas forcément interopérable avec ceux qui n'ont pas un navigateur xml/xhtml, qu'il n'y a pas de RFC pour xhtml, et pour beaucoup d'autres raisons.
Halte à la désinformation !!

Ben oui, ton argument marche aussi pour XML, RDF, RSS, PNG, XHTML, ....
Un format nécessite un lecteur adapté, que ce soit du HTML, du Flash ou autre chose. Je ne vois pas en quoi c'est un critère (enfin je le verrai si le lecteur était rare mais ce n'est pas le cas).
Et .... mis à part des vieilles versions HTML, quasi aucun format Web récent n'est sous RFC.

ah ? pour du SVG animé il y a quelque chose ? pour gérer les sons,animation et vidéo de manière synchrones ? désolé, si tu ne restreins pas flash à une image statique, il n'y a rien d'équivalent pour "utiliser" SVG (produire, mais aussi intégrer avec le script, et tout l'environnement web à coté).

> Hum, CSS c'est quand même super limité, quand tu commences à
> faire une mise en page un peu poussée, là où avec des tables c'est
> torché en 2 minutes.

Certaines choses sont moins simples en CSS, d'autres sont moins simples en tableau. Tous les outils ont leurs limites (et flash aussi), ce qui importe c'est comment tu composes avec ces limites. Dans l'ensemble CSS répond bien plus à la problématique de publication de doc que les autres outils qu'il y a à notre disposition (et par rapport à l'utilisation des tableaux c'est une énorme avancée tout de même).

> pas tellement mieux que chez Microsoft donc

Ah ? entre une spécification publique, accessible (même si non redistribuable), implémentable (et implémenté) ... et un format gardé secret ... pas tellement mieux ?


Pour le reste, s'il te faut un troll :

> Un vrais standard a ses spécifications accessibles sans contraintes par le public

Ah ? dans l'idéal je serai d'accord avec toi. Sauf que le W3C dont tu parles a bien failli autoriser les brevets sur ses propres spec. Sauf que certaines spec ISO sont tout ce qu'il y a de plus payantes si tu veux les détails. Certaines parties d'OpenGL sont sous brevet.
Faut croire que non, ta définition ne correspond pas vraiment à ce qu'il se passe en réalité à moins que tu me dises que ISO ou le W3C ne sont pas des organismes qui font des standards, ou qu'OpenGL n'en est pas un non plus

Flash a une licence, cette licence n'autorise pas la redistribution (d'où le nom de NDA) mais elle est bien publique (et gratuite).

> mais pour que ce soit un standard web, il faut que ce soit documenté,
> implémentable dans le développement de lecteurs tiers et que ça soit
> reconnu par le W3C ou un autre organisme officiel

C'est documenté, c'est implémentable (il y a des projets libres en cours). Reste que ce soit reconnu par un organisme ?
Qui définit la liste des organismes que tu acceptes ?

Oasis qui a standardisé le format open-document n'a rien de plus officiel qu'un autre, c'est juste un groupement d'entreprises.
Le W3C n'a pas énormément plus de légitimité quand on regarde de près uniquement le coté structure (personne ne l'a "officialisé").

Si je devais utiliser le critère "officiel" il n'y aurait pas beaucoup plus d'organismes que ISO et les trucs nationaux (les normes CE, NF, ...), même pas le W3C.


Bref, pas si simple de définir ce qui est "standard" et ce qui ne l'est pas, hein ?

il va falloir arrêter avec les standards. Non, pas la peine de me sortir l'argumentaire pro-standard, je suis plus qu'impliqué dans le milieu.
Mais il ne faut pas sortir ça à toutes les sauces non plus hein. Certains formats ont été standardisés par une entité qui a été créée pour ça, ça ne veut pas forcément dire que le reste n'a pas lieu d'exister ou n'a pas de légitimité, ça ne veut pas non plus dire que le reste n'est pas du Web.

> standards du web vu qu'il faut un soft propriétaire

Le fait que ce soit standardisé et qu'il faille un soft proprio sont deux choses tout à fait différentes. Rien n'empêche un standard de n'etre implémenté que dans du proprio.

> Autant faire ses pages en word et les sauver en .doc, d'un point de vue
> standard c'est pareil.

Autant dire des conneries.
Un standard c'est quoi ? juste une spécification fixée pour que tout le monde écrive et lise la même langue, rien de plus. Que cette langue soit inventée/créé/spécifiée par paul, pierre ou jacque n'influe en rien dans les objectifs.
Je ne pense pas qu'on puisse dire que flash est un standard vu qu'il n'est réellement implémenté que par lui même, mais il a tout de même une spécification publique, claire et complète sur comment écrire et lire le format. Ce n'est en rien comparable à un format fermé et obscur comme le .doc de MS Word.

> Pour info, Flash utilise le codec H.263.

Ca c'est intéressant comme info. Ca sous entend qu'avec un peu de bidouille on peut peut être récupérer les flux video de flash avec un lecteur vidéo classique. Me trompe-je ?

Mais effectivement, c'est un peu désespérant de se dire que pour diffuser une vidéo le mieux actuellement reste encore d'utiliser un plugin fait pour l'animation vectorielle. Vivement que mplayer ou vlc diffusent des plugin bien faits pour firefox et msie (ceux que j'ai pu tester je ne les considère pas comme bien faits, le plus souvent il n'y a même pas les contrôles pour arrêter la vidéo, je ne parle même pas de la sortir du navigateur pour la mettre en plein écran) de façons à avoir un support vidéo correct sur la plupart des formats

scriptable oui, mais fais donc un morphing en flash à partir de formes complexes ou avec des chemins, et tentes la même chose avec ton SVG scriptable. Pour peu que tu arrives à faire un script qui fasse ton morphing, ça va faire ramer la meilleure bécane.

rajoutes ensuite la vidéo (flash est de plus en plus utilisé car il est répandu et constitue la meilleure base pour diffuser une vidéo actuellement, les autres plugins étant trop différents), le son, un truc pour faire la timeline qui marche (oui, je sais, il y a smil, mais pas beaucoup d'implémentations libres qui peuvent passer dans le navigateur à ma connaissance) ...

Bref, non, ça n'a rien à voir. Tu es en train de comparer un format d'image manipulé par script avec une archive qui contient aussi du script et de l'image vectorielle mais aussi de l'animation, de la vidéo, du bitmap, de la synchro pour tout ça, des gestions de séquences/sous-séquences ....
Désolé, autant je n'aime pas vraiment flash autant SVG n'est pas un concurrent de flash, c'est juste une toute petite brique de l'ensemble.

Un des problèmes c'est par exemples dans les distribs, vu qu'ils recompilent ils se tapent des icones non officielles.
Ca te semblerait bien toi de ne pas pouvoir utiliser les icones d'OOo, filrefox, xchat, evolution, gaim [complète avec les softs que tu utilises] et donc perdre tous les repères visuels entre l'icone et les visuels des sites, et surtout avoir des icones différentes partout ou tu vas ?

Il n'a pas dit que la protection des icones et marques était une mauvaise chose en soit, mais là elle est trop stricte car elle met une croix sur trop de choses "légitimes" sur notre système

inutile ?

mais les chiffres sont justes ! il y a plus d'ip qui ont montré être affectées, c'est un fait si on croit l'étude sérieuse (et sans preuves du contraire ça doit être le cas).

par contre l'interprétation qui en a été faite ici et qui est contredite est elle sans fondements (baser la proportion de machines infectées sur le nombre d'IP, entre autres).

Ca ne te plait pas ? c'est la même chose. Par contre penser que ceux qui critiquent l'analyse le font parce qu'ils sont chez FT et qu'ils sont succeptibles (ta première phrase) c'est vraiment pas se montrer ouvert et c'est le "j'ai raison, s'ils affirment le contraire c'est orcément qu'ils sont concernés ou intéressés".

> d'ailleurs c'est assez marrant de voir que ce genre de service
> préhistorique puissent être retourné pour devenir un argument
> pro-wanadoo...

Je comprend mieux :
FT c'est mal, faut pas dire des choses qui pourraient éviter de faire passer FT pour un boulet, c'est ça ? navrant

ça veut dire aussi que à cause du RTC il y a encore beaucoup plus d'IP dynamique chez Wanadoo que chez Free. Et il suffit d'une machine infectée connectée régulièrement pour avoir des attaques depuis une cinquantaine d'IP. Ca fausse pas mal les résultats s'ils sont fait à partir d'ip attaquantes. Bref, comme d'hab, impossible de comparer des choux et des carottes.