Ben non. C'est explicitement inscrit que je n'ai pas le droit de les mettre sur mon site, sans autre information.
Je ne nie pas que la personne l'ait fait par erreur, mais elle a bien interdit tout ça.
La phrase est "Toute rediffusion de nos fichiers est également interdite, même avec la mention de leur provenance."
Ca couvre autant l'envoi par mail à mon frère, la diffusion de mes travaux d'annotations par mon université, la traduction ou la critique "dans le texte".
Plus explicite et interdit que ça je ne vois pas. La seule chose qui aurait pu être interdite en plus ça aurait été de les lire ;)
> on te demande de ne pas utiliser les fichiers pour remplir ton site, faut
> pas chercher plus loin.
Ben voilà, et les deux exemples que j'ai donné nécessitent de les mettre sur mon site.
Mais si, ça va plus loin. Ce qui est interdit c'est "toute redifusion", qu'elle qu'elle soit (fichier originaux, fichiers modifiés, travaux basés sur ...) , à n'importe quel titre (universitaire, particulier, professionel), pour quelque but que ce soit (partager avec le copain qui n'a pas internet, montrer mes travaux, traduire, diffuser un fichier particulier, ...)
Ca pourrait même difficilement aller plus loin puisque le seul espace de liberté outre ce que garanti la loi c'est la première lecture du doc.
> Si tu te poses des question sur les intention de cette personne, lis
> bien l'interview, et tu comprendras que la "renomé" est vraiment le
> cadet de ses soucis..
Moi je veux bien le croire, mais dans ce cas l'erreur est monstrueuse et il faut changer tout ça au plus vite, et radicalement.
D'ailleurs quand j'y pense je n'ai pas le droit non plus de les utiliser dans des travaux de recherche universitaires car ils seront (les thèses et compte rendus complets des labos sont souvent payants) et les conditions interdisent les redistributions commerciales.
Bref, étrange pour un projet hébergé par une université.
Tout de même. Empecher de se proclamer miroir (donc de profiter du nom) ça je comprendrai. Ca me semble même logique et il n'y a pas besoin d'une interdiction spécifique sur l'utilisation du contenu (c'est déjà géré en France par le droit sur les bases de données, je serai étonné qu'il n'y ait pas un équivalent au Canada).
Mais non. Là ce qui est interdit c'est toute mise en téléchargement (public ou pas d'ailleurs). C'est nettement différent du "interdire les miroirs".
Je cite (à partir du nouveau site) : "CE QUE NOUS INTERDISONS, c'est que vous rediffusiez les fichiers des Classiques à partir de votre site, par exemple, un de nos textes au format Word qui serait hébergé et disponible sur votre serveur. "
Il n'y a aucune modération sur cette phrase, rien ne parle de miroir, je vois juste que je n'ai pas le droit de diffuser en mettant en téléchargement.
Si vraiment le but est uniquement d'empecher des miroirs détériorés, alors il faut vite retirer cette phrase pour interdire les miroirs (et pas la mise à disposition du contenu).
> Rien n'interdit de copier les fichier, de les envoyer a des
> personnes, surnoté, annoté etc..
- Je n'ai pas le droit de monter une page Web à propos de mon travail ou de ma thèse et proposer une version anotée.
- Je n'ai pas le droit de laisser un fichier en téléchargement sur mon site pour que ma soeur le récupère (par mail ça pourrait être un peu gros parfois), ça même si l'accès du site est privé et protégé par mot de passe.
On dépasse largement l'interdiction des miroirs et on rentre dans des interdictions de choses qui sont à priori légitimes et que, si je comprend bien, ne sont pas la cible des interdictions.
Si c'est le cas il faut vite revoir les conditions d'utilisation parce que là elles ne reflettent pas du tout ce qu'il faut.
La plus libre des bibliothèques ? sûrs ?
D'après les conditions d'utilisation je n'ai pas le droit de télécharger un fichier et de l'envoyer à mon frère par email. Ben non, alors que jamais la bibliothèque de mon quartier ne me l'a interdit.
Vous savez aussi ce que ça veut dire ? ça veut dire que je ne peux pas me servir de ces fichiers pour les annoter/surligner et les diffuser avec mes annotations.
L'excuse du contrôle de l'intégrité de l'oeuvre est franchement ridicule. Le fait que je diffuse à mon voisin une oeuvre n'a jamais pu changer l'intégrité de celles qui sont sur le serveur. Si quelqu'un veut s'assurer de la qualité ou de l'intégrité il va sur le serveur officiel, mais je ne vois pas en quoi ça empêche de laisser la libre circulation des copies. Au moins des copies non modifiées.
Ils ont choisi la logique de l'enfermement, d'utiliser du contenu sous domaine public pour en faire du contenu non libre. Ils en ont le droit (ils font un gros boulot avec ces fichiers) mais qu'ils assument bordel ! qu'ils disent qu'ils refusent les redistribution pour garder la main sur le noeud central, pour obliger les gens à passer par eux et pour garder la renommée et les retombées. Pas besoin de ces excuses sur l'intégrité des oeuvres.
Mais surtout ... que du coup il ne surfe pas sur les "c'est du domaine public et le PUF cherche à m'empecher de redistribuer, nous on est une bibliothèque libre pour tous". Ils font ni plus ni moins que ce que font les autres : du gratuit avec des clauses serrées pour enfermer l'utilisateur et s'assurer qu'il repassera par eux. Sauf qu'en plus ici ils ne créent pas le contenu qu'ils enferment, ils prennent ce qui existe déjà ailleurs.
En changeant les paquets de serveurs les problèmes de copyright disparaissent ?
En quoi passer vers PLF résoud t-il quoi que ce soit ?
Il y a probablement une bonne réponse à ces questions mais je ne l'ai pas trouvée sur PLF ou dans les liens. Et sans cette réponse ça fait un peu "bon, je sais que je n'ai pas le droit alors je vais le faire sous un autre nom comme ça si je me fais chopper je vais dire que c'est pas moi et que moi (Ubuntu/Mandriva/cequevousvoulez) je suis clean", et ce n'est pas top comme idée je trouve.
Tout à fait, le public visé est plus une réunion pour professionnels et décideurs, pas une réunion de geeks de la communautés. Pas que j'y vois un inconvénient, au contraire (moi je suis plus intéressé par les réunions type comunauté), mais les apéro AFUP & apéro PHP sont alors plus adaptés. Il y en a fréquement sur toute la France.
Coté professionnel, 150e pour deux jours ce n'est vraiment pas grand chose (moins de 100e ça pourrait même être trop peu pour faire sérieux à certains endroits)
> Certes, mais ça ne joue pas en faveur de la simplicité.
Pourquoi ? ça n'a d'influence que si tu t'en sers. Il y a un type de table par défaut, tu peux très bien ignorer le fait qu'il y a plusieurs moteurs de table et mettre innodb par défaut si ça t'amuse
héhé, sisi.
On ne copie pas la loi européenne (sinon il n'y aurait pas besoin de le faire), on transpose et on adapte.
Ca laisse largement assez d'espace pour rajouter des phrases pour limiter l'EUCD afin qu'il ne bloque pas l'interop, mettre une exception pour tout contournement "légitime", et ainsi de suite.
Le concept même de la loi est pourri mais on peut très facilement en limiter le désastre avec deux ou trois exceptions ou formulations bien placées.
C'est d'autant plus vrai que à mon souvenir l'EUCD est une directive à tiroirs, les pays sont autorisés à piocher dans une liste de passages optionnels.
Autre raison : il est clair que cette loi devra être revue au niveau européen. En la gardant non transposée on pourra avoir direct la nouvelle version. En la transposant on vivra quelques années avec la pourrie le temps qu'on nous transpose la nouvelle.
Oui, transposer l'actuelle est une obligation, mais ça ne serait pas la première fois que cette obligation n'est pas respectés
> je rapelle que la démocratie tel que nous la connaissons est fondé sur une revolution.
Mouais, c'est largement contestable et c'est la jolie vision idilique qu'on apprend à l'école mais bon ...
Disons que la révolution a plus été en France la fin officielle du système des classes et de la royauté. Après la révolution on a eu la fameuse époque de la terreur, des monarchies constitutionnelles, un empire ... et tout ça en très peu de temps finalement. Ca a plus été la fin de ce qu'il y avait avant que le début de ce qu'on a maintenant.
Notre système démocratique il est plus récent que notre révolution. Et la démocratie (pas forcément la notre) elle même est bien plus vieille que notre révolution.
En fait le problème c'est que ça revient à déporter la loi vers l'industriel. A partir du moment où on culpabilise le contournement d'une protection, ce n'est plus le législateur qui dit ce qui est interdit (droit d'auteur, tout ça), mais l'industriel (j'ai mis une protection, le contournement est interdit => paf, j'ai interdit ce que je voulais).
Et par effet de bord on peut interdire ce qu'on veut. Le très bon exemple c'est Lexmark avec ces cartouches d'encre. Il a utilisé le DMCA pour empêcher quelqu'un de faire des cartouches compatibles (il y avait de du copyright dans ses cartouches, il a mis un système bidon d'authentification de cartouche, pour faire une cartouche compatible il faut que je simule l'auth, donc viole la protection qui est mise en place pour le copyright => c'est inerdit, même si je ne viole pas le copyright en lui même). Bon, pour la petite histoire Lexmark a perdu en appel (ils avaient gagné en première instance) mais la problématique est bien là.
> En effet, le vol a beau être interdit, ça m'empêchera pas de mettre un
> antivol sur mon vélo. Et il y a je suppose des lois qui m'y autorisent.
Oui, mais imagines que la loi interdise le contournement d'un dispositif de protection contre le vol.
Tu accroches ton vélo au poteau. Un gars passe après toi pour mettre aussi son vélo au poteau et coince le tiens.
Tout ce que tu feras pour retirer le cadenas ou faire en sorte de le contourner sera illégal. C'est marrant, quelqu'un vient de rendre illégal le fait de récupérer ton vélo.
Ben c'est exactement ce qu'il se passe avec le DMCA.
> Ben la caméra, elle filme et elle permet éventuellement d'identifier les agresseurs
> ou le taré
Je veux bien croire qu'on soit tous fichés mais de là à savoir automatiquement le nom et l'adresse de quelqu'un qu'on voit à moitié sur une caméra ... j'ai comme un doute.
Les quais du métro ça fait longtemps qu'ils sont sous caméra, ça n'empêche pas d'avoir régulièrement des messages sur les pickpocket tout ça ... ils ne les ont toujours pas arrêtés avec leurs belles caméra ?
On a aussi des caméras devant tous les distributeurs de banque. Pourtant on a encore des gens démasqués qui piquent des billet, qui font semblant d'aider les vieilles dames ou meme qui posent des faux claviers pour récupérer carte+code. Ben oui, la caméra faut encore la regarder et même quand on la regarde ça permet juste de dire "ah ben oui, y'a eu vol, bon, maintenant on fait quoi ?"
Avant c'était une solution, ça faisait peur, ça prévenait les problèmes. Maintenant c'est tellement banalisé que ça ne fait plus peur à personne et n'a quasiment plus que les effets négatifs. Tout au plus ça déplace les problèmes (ce n'est pas que la caméra fasse peur mais si elle n'est pas là c'est toujours ça de moins)
Attention, je ne dis pas que ça ne sert à rien, je dis que les moyens mis en oeuvre, les possibilités de dérapage ou d'utilisation à des fins non prévues sont laaaargement supérieurs aux gains potentiels qu'amènent ce surplus de caméra.
Ou alors faut faire comme les radars routiers et obliger chacun à porter sa carte d'identité sur le front, là les caméra seront plus utiles.
> Sauf que si on compare le budget de l'UMP et du PCF on va trouver de sacrées
> différences. Il faudra un paquet de prolo pour cotiser autant qu'un Dassault.
Tu peux pas savoir ce qu'on gagne en vendant du muguet ...
commentaire de quelqu'un qui n'a jamais fait du C que dans ses études (et vraiment pas beaucoup) :
On est encore obligé de jouer de l'assembleur dès qu'on veut utiliser des choses multimédia efficacement ? de faire de l'assembleur pour utiliser mmx/sse ?
Personne n'a encore fait de compilo assez intelligent pour utiliser mmx/sse tout seul ? de bibliothèque assez bien foutue pour lancer des fonction multimédia sans tomber dans de l'assembleur ?
C'est surtout ça moi qui m'étonne.
Tiens ça c'est marrant que la discussion ne soit pas sortie.
S'ils ont des problèmes de portage, s'ils leur manque des compétence et s'ils ont la volonté d'être dispo sous Linux & BSD avec plusieurs architectures ... pourquoi ne libèrent-ils pas le player ?
Leur business est sur l'appli qui créé les flash, pas sur la lecture. Ca ne les empeche pas d'avoir un player "officiel" qui fait référence, mais au moins peut être le boulot à faire sur le player sera fait (ce n'est pas garanti mais vu qu'il existe des projets libres concurrents, ce n'est pas impossible)
Ca reste surtout une news qui décrit en détail les problèmes de portage et le pourquoi certaines boites ne portent pas leur soft.
Le portage d'une application est une réelle problématique, si tu nous avais fait la même news pour un soft libre il est probable qu'elle serait passée, malheureusement tu ne l'as pas faite.
Et libre ou pas Flash concerne encore beaucoup de monde, y compris parmi les gens d'ici. On a bien des news sur MS alors une news qui parle d'un portage flash sous linux ça me semble pertinent.
Oui oui. En même temps :
- si c'est du close source y'a pas besoin de changer le soft pour faire ça, suffit que la fonctionnalité soit déjà présente et qu'elle ne soit qu'activée par la suite (par rapport à une date par exemple). Le hash n'a pas changé, le soft n'a pas changé, pas besoin de collision md5.
- si c'est de l'open source on verra des trucs bizarres dans les sources
- dans tous les cas annexer la taille au md5 (chose qu'on vérifie souvent) montrera le problème.
oui mais si j'ai bien compris l'article il ne s'agit pas de trouver une collision avec un fichier existant mais à partir d'un fichier en trouver deux autres qui sont en collision.
Tu as au départ une source S1, tu as à l'arrivée une source S2 et une collision C. S1 et S2 n'ont pas la même taille ni le même hash.
La conséquence :
- ça ne permet pas de pervertir un fichier qui a déjà été distribué par un tiers (puisque S1 != S2 et avec des hash différents)
- ça n'est pas extensible à tous les formats ou toutes les données (dans un exe il est facile de rajouter des bits morts, dans d'autres formats c'est impossible ou limité)
- ca ne permet pas de fausser les mots de passe gérés avec un algo basé sur md5
Ce que ça permet c'est par contre préparer un code méchant et un code gentil, diffuser le gentil, puis plus tard, l'air de rien, diffuser le méchant pendant un ou deux jours sans changer le md5. Ca demande quand même une mauvaise foi sur le distributeur initial dès le départ (ce qui n'empeche pas que ce soit gênant, on est d'accord).
Reste aussi que même dans les formats où c'est possible de rajouter des bits morts pour générer la collision, il n'est pas impossible que ce soit visible (pour ceux qui savent comment est fait un binaire, je pense qu'il doit être visible qu'un gros flot d'octet est inutilisé à la fin).
Je ne nie pas l'importance du bonhomme ou ce qu'il a fait. Par contre juger le ... européen de l'année à partir des brevets logiciels n'est-ce pas un peu réducteur ?
L'europe c'est quand même bien plus vaste non ? Certains penseront au TCE mais je suis sur qu'il y a d'autres sujets.
Si rien n'a eu de dimension plus globale c'est bien malheureux pour notre europe.
> Pour revenir sur la question des mysql_connect, il y a des gens qui
> travaillent avec plusieurs bases de données différentes et qui ont
> donc des connections DIFFERENTES et donc, qui ne veulent/peuvent
> pas réutiliser par défault la dernière connection automatique.
Ce n'est pas de ça que je te parle.
Je te dis simplement que quand tu fais plusieurs ouvertures de connexion avec les mêmes paramètres, tu récupères un identifiant vers la même connexion. Ca n'a rien à voir avec le principe de réutilisation de la dernière connexion ouoverte (ce qui effectivement est une mauvaise idée parce que ça va peter dès qu'on a besoin de plusieurs sources différentes).
> Donc avant je faisait, en gros un connect() à chaque accès,
> maintenant je 'trie' les connections pour n'ouvrir que des connexions
> nécessaires. Dans tes scripts tu ne donnes pas un identifiant de
> connexion ? tu laisses php prendre par défault le dernièr utilisé ?
> arggg
J'ai dit ça ?
Non, j'utilise tout comme toi les identifiants de connexion. Je reprend ton exemple :
> fait une connection host1 - base1 -> print id : Ressourceid#4 (par
> ex)
> ensuite encore host1 - base1 -> print id : Ressourceid#4 (normal,
> suivant ta théorie car php réutilise la dernière connection)
Oui. D'ailleurs si jamais tu ne me crois pas, tu peux lire la doc :
""" Si un deuxième appel est fait à mysql_connect() avec les mêmes arguments, aucune nouvelle connexion ne sera établie, mais plutôt, l'identifiant de la connexion de la connexion déjà ouverte sera retourné."""
> MAIS host1 - base 2 -> print id : Ressourceid#4 (je ne comprend
> pas !!!, ce n'est pas le même connexion, et tu n'a pas assez aux
> mêmes tables.)
Ben oui, mais regardes ce que tu fais avec ton code :
$link1 = mysql_connect('host1') ;
mysql_select_db('base1', $link1) ;
$link2 = mysql_connect('host1') ;
// là $link2 est bien le meme que le précédent $link1,
// d'ailleurs tu l'as vu toi même
mysql_select_db('base2', $link2) ;
// tu as toujours la meme connexion
// mais tu viens de lui demander de changer de base
// donc forcément tu ne vois pas les memes tables
// maintenant essayes de lister les tables sur $link1
// tu verras qu'elles ont changes aussi.
Si tu veux avoir deux connexions distinctes, tu as un paramètre spécifique sur mysql_connect() qui dit explicitement "j'ai déjà une connexion avec ces paramètres mais j'en veux une nouvelle, pas la meme"
> Donc avant je faisait, en gros un connect() à chaque accès,
> maintenant je 'trie' les connections pour n'ouvrir que des
> connexions nécessaires.
On s'est bien compris, et moi (ainsi que la doc) je te dis que même auparavant, tu n'ouvrais que les connexions nécessaires et que tu ne faisais jamais de doublon (sauf si tu fermais la connexion explicitement ou que tu forcais le doublon avecle paramètre adéquat, mais là ça devient volontaire)
> Je ne sais pas, comment cela ce fait-il que en c
Peut être parce que le PHP n'est pas identique au C ? qu'un langage compilé n'a pas les mêmes avantages et inconvénients qu'un langage interprété ? que avec la lenteur globale de PHP le changement de contexte d'une fonction est négligeable ou en tout cas l'argement réduit par rapport à ton chiffre de x1/x10 ?
Pour un simple exemple, en PHP passer un argument explicitement par référence est plus lent que le passer par copie. Et *paf* pour les idées reçues et le "oui mais en C ...."
Autre exemple ? en PHP l'accès à une constante est plus lent que l'accès à une variable, et re-*paf* pour les idées reçues et le "oui mais en C ..."
Bref, se méfier beaucoup des légendes urbaines sur les performances. Et principalement dans PHP qui a ses propres logiques et peu de gens qui connaissent vraiment le fonctionnement interne.
Le fait que tu gagnes parfois des perf sur certains inline en C ne veut pas dire qu'il faut faire la même opération en PHP, ou que tu vas y gagner assez (comprendre: assez pour que l'effet positif des performances contrebalance l'effet nagatif de la duplication de code et de la relecture)
> Oui, oui allons dans les " blabla $var bliobli..." oui c'est cool, même
> avec un "select * from base where id= $_POST['login'] "cela va
> plus vite à coder et plus vite à analyser et... un peu goret qd même.
Ah ?
entre les deux codes suivant, lequel est le plus clair, le plus goret, et pourquoi ? enfin en retirant ton exemple biaisé qui utilise directement une entrée utilisateur sans filtrage et sans echappement bien entendu.
V1 :
$id = calcule_filtre_et_recupere_id() ;
$date = calcule_filtre_et_recupere_date() ;
$sql = "SELECT * FROM base WHERE id=$id AND date<'$date'" ;
V2:
$id = calcule__filtre_et_recupere_id() ;
$date = calcule_filtre_et_recupere_date() ;
$sql = 'SELECT * FROM base WHERE id='.$id.' AND date<\''.$date.'\''" ;
Niveau clarté c'est sans appel je choisis la V1
Niveau performances c'est kifkif mais si tu tiens à calculer les demi-microsecondes la V1 est plus rapide
Niveau goret ... tu m'expliques en quoi la V1 est goret ?
> Réutiliser du code existant ? cela voudrait dire le passer en revue
> pour qu'il devienne 'trusted' pour moi et mon employeur (autant de
> temps que de le réécrire), si je suis employé et que je fournis du
> code 'emprunté' à d'autres, demain, mon travail sera 'donné' à
> d'autre.
Si ta valeur ajoutée c'est de refaire depuis zéro ce qui existe ailleurs et qui marche je conçois que tu te fasses du souci pour ton travail.
Moi ma valeur ajoutée c'est justement de faire ce qui n'existe pas, de réutiliser pour adapter ou étendre.
D'ailleurs, ça mis à part, je suis étonné que sur un site proche du libre et de la communauté, on ne voit pas l'intérêt à mutualiser les codes et à réutiliser plutot que tout refaire dans son coin.
Pour reprendre ton exemple, si j'ai l'assurance qu'un CMS, un outil de blog, un DHAL, une classe de manipulation Excel ou je ne sais quoi d'autre correspond à mon besoin et à ma licence et à mes critères qualités, je ne me priverai pas de le réutiliser/modifier pour reproter mon travail sur ma valeur ajouté.
Si c'est pour refaire quelque chose qui existe déjà ils n'ont justement pas besoin de moi.
> Alors Non, ce ne sont pas des applis à 200 euros, mais bien plus,
> si tu veux travailler pour pas chèr avec de la réintégration du travail
> d'autres, c'est un choix/obligation du marché. A ce niveau là, les
> pays de l'est vont ceuillir ce marché très facilement.
Je préfère faire des applications complètes, chères, de qualité, avec de la réutilisation ;)
Le fait de réutiliser (là où c'est pertinent) me permet justement de faire des applis plus complètes et de meilleure qualité, pas forcément de dire "j'en fais moins".
Si tu fais des applications à 200ke qui ne font qu'à peine plus qu'e ce que font les briques dispo en LL parce que tu perd ton temps à tout réécrire, c'est plutot toi qui va avoir du mal à te reveiller. Parce que ton marché de l'est lui il va justement te proposer la même chose pour 1000 fois moins cher puisqu'il ne fera que les ajouts/modifs à partir de l'existant, pas tout le développement.
Quoi que dans ma boite l'externalisation elle est au Maroc, mais la problématique est la même. Ici on coute plus cher, c'est pour faire ce qu'on ne peut pas faire ailleurs : l'adaptation et la spécialisation des applicatifs (où il faut être proche du client), recoder des briques le Maroc peut le faire, ils ont des gens largement aussi compétents qu'ici (contrairement aux idées reçues du type "moi je fais du bon code d'expert, je ne suis pas en concurrence").
> Je ne rentre même pas dans la réthorique de la course à la
> puissance, pourquoi me faire chier à optimiser, y des proc bi-core
> qui arrivent.
Il s'agit juste de faire de efforts utiles. Quand on gagne millisecondes par jour après avoir faire une revue/modification complète de code (donc probablement plus d'une semaine) et avec tous les risques d'erreur que ça entraine (donc les temps de test, recette, etc.) je connais très peu d'entreprises qui trouvent utile de faire le pas (en fait je n'en connais aucune).
Le pire c'est quand, à force de vouloir optimiser tout et n'importe quoi sans connaitre le langage on fini par faire un travail inutile, type ce que tu fais avec les mysql_connect().
Non, sérieux, ton code et ton architecture sont si parfaits que tu en es à optimiser ce genre de chose pour des gains si modestes ? tu es sûr de ne pas avoir assez de travail ailleurs plus utile/pressé pour laisser ça de coté ?
> J'avais lu, de mémoire qu' un code éxécuté dans une fonction est 10
> fois plus lent que le code exécuté inliné (pour le php).
C'est une stat qui ne veut rien dire. Ca a du être fait en faisant 10000 fois 1+1 dans une boucle et en comparant avec autant d'appels de fonction qui font chacune 1+1.
Dans un cas réel on est très loin de ces chiffres, et non, si tu fais une fonction qui appelle une fonctiton qui appelle une fonction, ton code n'est pas magiquement 1OOx plus lent, heureusement.
> pour remplacer les "" par des '' (pour gagner un peu de performance),
> réutiliser les même liens aux bases plutôt que de les recréer (je
> n'utilise pas les p_connect pour alléger la charge de la base de
> donnée) car même 1 seconde seulement de gagné (tout confondu:
> accès sql + traitement sql + php + transmissions html) est 1 seconde
> de gagné pour l'expérience utilisateur
Ou comment perdre du temps pour rien.
L'histoire du " => ' c'est vrai, mais globalement ça fait gagner des dizièmes de millisecondes au mieux. Si tu gagnes 15s de proc à la fin de la journée tu peux estimé avoir eu une chance extraordinaire. Si tu regardes le temps passé, le smic horaire, tu auras plus vite fait de changer de proc ou rajouter un serveur en load balancing que t'amuser à reprendre tous tes délimiteurs de chaine. Je ne parle meme pas du fait que le " => ' est vrai pour des chaines statiques. Si tu as des remplacements de variables, un "xxx $var xxx" n'est pas plus lent que 'xxx '.$var.' xxx', au contraire. Bref, du temps de perdu pour rien, et autant de possibilités de bugs et régressions si tu fais des erreurs.
L'idée de mutualiser les connect() pour le pas faire plusieurs connexions est encore pire. Mysql réutilise déjà les liens vers la base. Fais 150 mysql_connect() dans le même script avec les mêmes paramètres, PHP n'ouvrira qu'une seule connexion et te renverra toujours le même identifiant. Tu viens donc de repasser tout ton code pour refaire coté utilisateur ce que mysql fait déjà en interne tout aussi bien et probablement plus rapidement, heureux ? Peut être que si ton code était mal organisé tu faisais un peu trop d'accès aux fonctions de connexion là où un attribut de classe aurait été avantageux, mais aller faire la chasse aux connect() n'a aucun sens, ça ne changera rien aux ressources utilisées.
Et tu as quoi comme application pour que ça nécessite d'aller faire des revues de code pour gagner les quelques microsecondes de " => ' ou pour considérer que tu ne peux te permettre de réutiliser des codes existants ?
Heureusement cette mode des performances par les performances est passée. Je ne dis pas qu'il est bon d'ignorer les perfs, ni que les perfs ne servent à personne, mais ce genre de bidouilles qui font gagner 3ms/jour pour 3h de travail ça n'est efficace pour personne, même pour des boites comme yahoo.
> Je crois que tu exagères, tu parles du cas où tu vas utiliser les ajouts
> fonctionnels spécfiques des DBAL (gestion des erreurs, transformation de
> ResultSet, etc.)
Non non, je n'exagère pas, et je parle de quand on n'utilise vraiment rien ou presque du DBAL (select classiques)
Pour crédibiliser ce que je dis et donner des chiffres concrets :
Ce sont des chiffres donnés/faits par les dev d'ADOdb eux-mêmes. On peut donc facilement penser qu'ils ont plutot tendance à gonfler leurs perf qu'à les diminuer. Ca laisse quand même 14% pour l'extension C d'ADOdb, et quasi 30% pour la version PHP que tout le monde utilise. Si on s'intéresse à PEAR::DB ça fait du x2 par rapport au mysql direct.
A mon avis et d'après mon expérience ils exagèrent un peu pour PEAR::DB mais dans l'ensemble l'ordre de grandeur correspond à ce qui est trouvé/publié un peu partout et ce que je vois de coté aussi.
14% ça reste largement acceptable, mais on parle de l'extension C que quasi aucun hébergeur n'a et que beaucoup d'entreprises vont hésiter à mettre puisque non offocielle. 30% à 150% par contre ça devient moins rigolo.
Donc oui, c'est intéressant, mais ça a bien un cout non nul.
> Maintenant, avec l'arrivée prochaine de PDO, je pense que la lenteur va encore
> diminuer du fait du codage de la couche en C.
Sauf que PDO n'est *pas* uen abstraction de base de données. C'est bien dommage d'ailleurs parce que l'idée de base est plutot bonne. Il manque très peu pour pouvoir au moins s'en servir comme DBAL pour des besoins simples, mais ça ne supporte même pas de clause offset/limit, ça ne gère même pas les séquences/autoincrement, etc.
Du coup DBO ça te permet juste de garder les mêmes noms de fonction. Malheureusement c'est vraiment la partie la plus simple et automatique dans un portage. Ce qui prend du temps c'est tout le reste ... que ne fait pas DBO.
PDO l'unique but c'est de n'avoir à apprendre/gérer qu'une seule API unifiée. Par contre l'exploitation de l'API reste dépendante du SGBD (et malheureusement les spécificités des SGBD ne sont pas encore implémentées dans PDO donc la migration vers PDO n'est pas réalisable pour pas mal de gens)
Tu peux retrancher facile 10% pour ADODB, facile 30% pour PEAR::DB, et je suis gentil ... Et plus l'appli est basique avec un machine poussive (coté disque), plus ça va se sentir.
On n'en est pas au niveau des optimisations là, on est vraiment du coté du "oulà c'est lent".
AMHA les avantages compensent les inconvénients, mais ça a un cout, ça c'est certain.
Tu veux dire que si ils changent le format du content.rdf qui décrit ce que contiennent les extension xpi en vue d'une installation ça mérite un changement de numéro majeur ?
Note: à partir de firefox 1.5 les extensions utilisent un fichier texte avec un autre format à la place de ce content.rdf. Maintenant je dis ça je dis rien (et j'avoue qu'il n'est pas impossible qu'ils aient gardé compatibilité en doublant l'algo, je n'ai pas testé).
[^] # Re: 120 euros sans 3D ?
Posté par Éric (site web personnel) . En réponse à la dépêche Projet Open Graphic : les premières cartes de test avant la fin de l'année !. Évalué à 10.
[^] # Re: libre ?
Posté par Éric (site web personnel) . En réponse à la dépêche La bibliothèque Classiques Sciences Sociales fête son 5ème anniversaire. Évalué à 3.
> Bien sur que si aussi...
Ben non. C'est explicitement inscrit que je n'ai pas le droit de les mettre sur mon site, sans autre information.
Je ne nie pas que la personne l'ait fait par erreur, mais elle a bien interdit tout ça.
La phrase est "Toute rediffusion de nos fichiers est également interdite, même avec la mention de leur provenance."
Ca couvre autant l'envoi par mail à mon frère, la diffusion de mes travaux d'annotations par mon université, la traduction ou la critique "dans le texte".
Plus explicite et interdit que ça je ne vois pas. La seule chose qui aurait pu être interdite en plus ça aurait été de les lire ;)
> on te demande de ne pas utiliser les fichiers pour remplir ton site, faut
> pas chercher plus loin.
Ben voilà, et les deux exemples que j'ai donné nécessitent de les mettre sur mon site.
Mais si, ça va plus loin. Ce qui est interdit c'est "toute redifusion", qu'elle qu'elle soit (fichier originaux, fichiers modifiés, travaux basés sur ...) , à n'importe quel titre (universitaire, particulier, professionel), pour quelque but que ce soit (partager avec le copain qui n'a pas internet, montrer mes travaux, traduire, diffuser un fichier particulier, ...)
Ca pourrait même difficilement aller plus loin puisque le seul espace de liberté outre ce que garanti la loi c'est la première lecture du doc.
> Si tu te poses des question sur les intention de cette personne, lis
> bien l'interview, et tu comprendras que la "renomé" est vraiment le
> cadet de ses soucis..
Moi je veux bien le croire, mais dans ce cas l'erreur est monstrueuse et il faut changer tout ça au plus vite, et radicalement.
D'ailleurs quand j'y pense je n'ai pas le droit non plus de les utiliser dans des travaux de recherche universitaires car ils seront (les thèses et compte rendus complets des labos sont souvent payants) et les conditions interdisent les redistributions commerciales.
Bref, étrange pour un projet hébergé par une université.
[^] # Re: libre ?
Posté par Éric (site web personnel) . En réponse à la dépêche La bibliothèque Classiques Sciences Sociales fête son 5ème anniversaire. Évalué à 3.
http://www.uqac.ca/class/inter/info_poli.html(...)
Tout de même. Empecher de se proclamer miroir (donc de profiter du nom) ça je comprendrai. Ca me semble même logique et il n'y a pas besoin d'une interdiction spécifique sur l'utilisation du contenu (c'est déjà géré en France par le droit sur les bases de données, je serai étonné qu'il n'y ait pas un équivalent au Canada).
Mais non. Là ce qui est interdit c'est toute mise en téléchargement (public ou pas d'ailleurs). C'est nettement différent du "interdire les miroirs".
Je cite (à partir du nouveau site) : "CE QUE NOUS INTERDISONS, c'est que vous rediffusiez les fichiers des Classiques à partir de votre site, par exemple, un de nos textes au format Word qui serait hébergé et disponible sur votre serveur. "
Il n'y a aucune modération sur cette phrase, rien ne parle de miroir, je vois juste que je n'ai pas le droit de diffuser en mettant en téléchargement.
Si vraiment le but est uniquement d'empecher des miroirs détériorés, alors il faut vite retirer cette phrase pour interdire les miroirs (et pas la mise à disposition du contenu).
> Rien n'interdit de copier les fichier, de les envoyer a des
> personnes, surnoté, annoté etc..
- Je n'ai pas le droit de monter une page Web à propos de mon travail ou de ma thèse et proposer une version anotée.
- Je n'ai pas le droit de laisser un fichier en téléchargement sur mon site pour que ma soeur le récupère (par mail ça pourrait être un peu gros parfois), ça même si l'accès du site est privé et protégé par mot de passe.
On dépasse largement l'interdiction des miroirs et on rentre dans des interdictions de choses qui sont à priori légitimes et que, si je comprend bien, ne sont pas la cible des interdictions.
Si c'est le cas il faut vite revoir les conditions d'utilisation parce que là elles ne reflettent pas du tout ce qu'il faut.
# libre ?
Posté par Éric (site web personnel) . En réponse à la dépêche La bibliothèque Classiques Sciences Sociales fête son 5ème anniversaire. Évalué à 9.
D'après les conditions d'utilisation je n'ai pas le droit de télécharger un fichier et de l'envoyer à mon frère par email. Ben non, alors que jamais la bibliothèque de mon quartier ne me l'a interdit.
Vous savez aussi ce que ça veut dire ? ça veut dire que je ne peux pas me servir de ces fichiers pour les annoter/surligner et les diffuser avec mes annotations.
L'excuse du contrôle de l'intégrité de l'oeuvre est franchement ridicule. Le fait que je diffuse à mon voisin une oeuvre n'a jamais pu changer l'intégrité de celles qui sont sur le serveur. Si quelqu'un veut s'assurer de la qualité ou de l'intégrité il va sur le serveur officiel, mais je ne vois pas en quoi ça empêche de laisser la libre circulation des copies. Au moins des copies non modifiées.
Ils ont choisi la logique de l'enfermement, d'utiliser du contenu sous domaine public pour en faire du contenu non libre. Ils en ont le droit (ils font un gros boulot avec ces fichiers) mais qu'ils assument bordel ! qu'ils disent qu'ils refusent les redistribution pour garder la main sur le noeud central, pour obliger les gens à passer par eux et pour garder la renommée et les retombées. Pas besoin de ces excuses sur l'intégrité des oeuvres.
Mais surtout ... que du coup il ne surfe pas sur les "c'est du domaine public et le PUF cherche à m'empecher de redistribuer, nous on est une bibliothèque libre pour tous". Ils font ni plus ni moins que ce que font les autres : du gratuit avec des clauses serrées pour enfermer l'utilisateur et s'assurer qu'il repassera par eux. Sauf qu'en plus ici ils ne créent pas le contenu qu'ils enferment, ils prennent ce qui existe déjà ailleurs.
# Comprend pas
Posté par Éric (site web personnel) . En réponse au journal Création d'un dépôt PLF pour Ubuntu! Réunion préparatrice dimanche 9 octobre a 21h.. Évalué à 4.
En changeant les paquets de serveurs les problèmes de copyright disparaissent ?
En quoi passer vers PLF résoud t-il quoi que ce soit ?
Il y a probablement une bonne réponse à ces questions mais je ne l'ai pas trouvée sur PLF ou dans les liens. Et sans cette réponse ça fait un peu "bon, je sais que je n'ai pas le droit alors je vais le faire sous un autre nom comme ça si je me fais chopper je vais dire que c'est pas moi et que moi (Ubuntu/Mandriva/cequevousvoulez) je suis clean", et ce n'est pas top comme idée je trouve.
[^] # Re: Inscription
Posté par Éric (site web personnel) . En réponse à la dépêche PHP fête ses 10 ans lors de la 5ème édition du Forum PHP. Évalué à 4.
Coté professionnel, 150e pour deux jours ce n'est vraiment pas grand chose (moins de 100e ça pourrait même être trop peu pour faire sérieux à certains endroits)
[^] # Re: Oracle est loin
Posté par Éric (site web personnel) . En réponse à la dépêche MySQL 5.0 : Release Candidate 1. Évalué à 4.
Pourquoi ? ça n'a d'influence que si tu t'en sers. Il y a un type de table par défaut, tu peux très bien ignorer le fait qu'il y a plusieurs moteurs de table et mettre innodb par défaut si ça t'amuse
[^] # Re: La directive EUCD
Posté par Éric (site web personnel) . En réponse à la dépêche DMCA français : le gouvernement va tenter de passer en force. Évalué à 9.
On ne copie pas la loi européenne (sinon il n'y aurait pas besoin de le faire), on transpose et on adapte.
Ca laisse largement assez d'espace pour rajouter des phrases pour limiter l'EUCD afin qu'il ne bloque pas l'interop, mettre une exception pour tout contournement "légitime", et ainsi de suite.
Le concept même de la loi est pourri mais on peut très facilement en limiter le désastre avec deux ou trois exceptions ou formulations bien placées.
C'est d'autant plus vrai que à mon souvenir l'EUCD est une directive à tiroirs, les pays sont autorisés à piocher dans une liste de passages optionnels.
Autre raison : il est clair que cette loi devra être revue au niveau européen. En la gardant non transposée on pourra avoir direct la nouvelle version. En la transposant on vivra quelques années avec la pourrie le temps qu'on nous transpose la nouvelle.
Oui, transposer l'actuelle est une obligation, mais ça ne serait pas la première fois que cette obligation n'est pas respectés
[^] # Re: Grand tournant
Posté par Éric (site web personnel) . En réponse à la dépêche DMCA français : le gouvernement va tenter de passer en force. Évalué à 8.
Mouais, c'est largement contestable et c'est la jolie vision idilique qu'on apprend à l'école mais bon ...
Disons que la révolution a plus été en France la fin officielle du système des classes et de la royauté. Après la révolution on a eu la fameuse époque de la terreur, des monarchies constitutionnelles, un empire ... et tout ça en très peu de temps finalement. Ca a plus été la fin de ce qu'il y avait avant que le début de ce qu'on a maintenant.
Notre système démocratique il est plus récent que notre révolution. Et la démocratie (pas forcément la notre) elle même est bien plus vieille que notre révolution.
[^] # Re: Je peux aider mais j'ai besoin de vous
Posté par Éric (site web personnel) . En réponse à la dépêche DMCA français : le gouvernement va tenter de passer en force. Évalué à 9.
Et par effet de bord on peut interdire ce qu'on veut. Le très bon exemple c'est Lexmark avec ces cartouches d'encre. Il a utilisé le DMCA pour empêcher quelqu'un de faire des cartouches compatibles (il y avait de du copyright dans ses cartouches, il a mis un système bidon d'authentification de cartouche, pour faire une cartouche compatible il faut que je simule l'auth, donc viole la protection qui est mise en place pour le copyright => c'est inerdit, même si je ne viole pas le copyright en lui même). Bon, pour la petite histoire Lexmark a perdu en appel (ils avaient gagné en première instance) mais la problématique est bien là.
> En effet, le vol a beau être interdit, ça m'empêchera pas de mettre un
> antivol sur mon vélo. Et il y a je suppose des lois qui m'y autorisent.
Oui, mais imagines que la loi interdise le contournement d'un dispositif de protection contre le vol.
Tu accroches ton vélo au poteau. Un gars passe après toi pour mettre aussi son vélo au poteau et coince le tiens.
Tout ce que tu feras pour retirer le cadenas ou faire en sorte de le contourner sera illégal. C'est marrant, quelqu'un vient de rendre illégal le fait de récupérer ton vélo.
Ben c'est exactement ce qu'il se passe avec le DMCA.
[^] # Re: Intérêt de la vidéo surveillance?
Posté par Éric (site web personnel) . En réponse au journal Sarkocratie et Niconet. Évalué à 8.
> ou le taré
Je veux bien croire qu'on soit tous fichés mais de là à savoir automatiquement le nom et l'adresse de quelqu'un qu'on voit à moitié sur une caméra ... j'ai comme un doute.
Les quais du métro ça fait longtemps qu'ils sont sous caméra, ça n'empêche pas d'avoir régulièrement des messages sur les pickpocket tout ça ... ils ne les ont toujours pas arrêtés avec leurs belles caméra ?
On a aussi des caméras devant tous les distributeurs de banque. Pourtant on a encore des gens démasqués qui piquent des billet, qui font semblant d'aider les vieilles dames ou meme qui posent des faux claviers pour récupérer carte+code. Ben oui, la caméra faut encore la regarder et même quand on la regarde ça permet juste de dire "ah ben oui, y'a eu vol, bon, maintenant on fait quoi ?"
Avant c'était une solution, ça faisait peur, ça prévenait les problèmes. Maintenant c'est tellement banalisé que ça ne fait plus peur à personne et n'a quasiment plus que les effets négatifs. Tout au plus ça déplace les problèmes (ce n'est pas que la caméra fasse peur mais si elle n'est pas là c'est toujours ça de moins)
Attention, je ne dis pas que ça ne sert à rien, je dis que les moyens mis en oeuvre, les possibilités de dérapage ou d'utilisation à des fins non prévues sont laaaargement supérieurs aux gains potentiels qu'amènent ce surplus de caméra.
Ou alors faut faire comme les radars routiers et obliger chacun à porter sa carte d'identité sur le front, là les caméra seront plus utiles.
[^] # Re: le même Sarkozy qui spamme ?
Posté par Éric (site web personnel) . En réponse au journal Sarkocratie et Niconet. Évalué à 4.
> différences. Il faudra un paquet de prolo pour cotiser autant qu'un Dassault.
Tu peux pas savoir ce qu'on gagne en vendant du muguet ...
[^] # Re: troll ?
Posté par Éric (site web personnel) . En réponse à la dépêche Flash player 8 recherche son ingénieur linux. Évalué à 1.
> algos si on le porte sur une autre plateforme.
Sauf que là ça concerne majoritairement un changement d'OS et de compilo, pas de plateforme, justement
# dites
Posté par Éric (site web personnel) . En réponse à la dépêche Flash player 8 recherche son ingénieur linux. Évalué à 4.
On est encore obligé de jouer de l'assembleur dès qu'on veut utiliser des choses multimédia efficacement ? de faire de l'assembleur pour utiliser mmx/sse ?
Personne n'a encore fait de compilo assez intelligent pour utiliser mmx/sse tout seul ? de bibliothèque assez bien foutue pour lancer des fonction multimédia sans tomber dans de l'assembleur ?
C'est surtout ça moi qui m'étonne.
[^] # Re: Le matériau ou le Matériel?
Posté par Éric (site web personnel) . En réponse à la dépêche Flash player 8 recherche son ingénieur linux. Évalué à 9.
S'ils ont des problèmes de portage, s'ils leur manque des compétence et s'ils ont la volonté d'être dispo sous Linux & BSD avec plusieurs architectures ... pourquoi ne libèrent-ils pas le player ?
Leur business est sur l'appli qui créé les flash, pas sur la lecture. Ca ne les empeche pas d'avoir un player "officiel" qui fait référence, mais au moins peut être le boulot à faire sur le player sera fait (ce n'est pas garanti mais vu qu'il existe des projets libres concurrents, ce n'est pas impossible)
[^] # Re: pouah !
Posté par Éric (site web personnel) . En réponse à la dépêche Flash player 8 recherche son ingénieur linux. Évalué à 10.
Le portage d'une application est une réelle problématique, si tu nous avais fait la même news pour un soft libre il est probable qu'elle serait passée, malheureusement tu ne l'as pas faite.
Et libre ou pas Flash concerne encore beaucoup de monde, y compris parmi les gens d'ici. On a bien des news sur MS alors une news qui parle d'un portage flash sous linux ça me semble pertinent.
[^] # Re: oui mais
Posté par Éric (site web personnel) . En réponse au journal md5 (encore) mis à mal. Évalué à 2.
- si c'est du close source y'a pas besoin de changer le soft pour faire ça, suffit que la fonctionnalité soit déjà présente et qu'elle ne soit qu'activée par la suite (par rapport à une date par exemple). Le hash n'a pas changé, le soft n'a pas changé, pas besoin de collision md5.
- si c'est de l'open source on verra des trucs bizarres dans les sources
- dans tous les cas annexer la taille au md5 (chose qu'on vérifie souvent) montrera le problème.
Ceci dit oui, c'est inquiétant.
[^] # Re: slashdot
Posté par Éric (site web personnel) . En réponse au journal md5 (encore) mis à mal. Évalué à 2.
# oui mais
Posté par Éric (site web personnel) . En réponse au journal md5 (encore) mis à mal. Évalué à 10.
Tu as au départ une source S1, tu as à l'arrivée une source S2 et une collision C. S1 et S2 n'ont pas la même taille ni le même hash.
La conséquence :
- ça ne permet pas de pervertir un fichier qui a déjà été distribué par un tiers (puisque S1 != S2 et avec des hash différents)
- ça n'est pas extensible à tous les formats ou toutes les données (dans un exe il est facile de rajouter des bits morts, dans d'autres formats c'est impossible ou limité)
- ca ne permet pas de fausser les mots de passe gérés avec un algo basé sur md5
Ce que ça permet c'est par contre préparer un code méchant et un code gentil, diffuser le gentil, puis plus tard, l'air de rien, diffuser le méchant pendant un ou deux jours sans changer le md5. Ca demande quand même une mauvaise foi sur le distributeur initial dès le départ (ce qui n'empeche pas que ce soit gênant, on est d'accord).
Reste aussi que même dans les formats où c'est possible de rajouter des bits morts pour générer la collision, il n'est pas impossible que ce soit visible (pour ceux qui savent comment est fait un binaire, je pense qu'il doit être visible qu'un gros flot d'octet est inutilisé à la fin).
# oui mais
Posté par Éric (site web personnel) . En réponse au journal Le militant anti-brevets logiciels, Florian Mueller, nommé pour le prix des « Européens de l'année ». Évalué à 3.
L'europe c'est quand même bien plus vaste non ? Certains penseront au TCE mais je suis sur qu'il y a d'autres sujets.
Si rien n'a eu de dimension plus globale c'est bien malheureux pour notre europe.
[^] # Re: contre
Posté par Éric (site web personnel) . En réponse au journal Petition MYSQL chez Nerim. Évalué à 3.
> travaillent avec plusieurs bases de données différentes et qui ont
> donc des connections DIFFERENTES et donc, qui ne veulent/peuvent
> pas réutiliser par défault la dernière connection automatique.
Ce n'est pas de ça que je te parle.
Je te dis simplement que quand tu fais plusieurs ouvertures de connexion avec les mêmes paramètres, tu récupères un identifiant vers la même connexion. Ca n'a rien à voir avec le principe de réutilisation de la dernière connexion ouoverte (ce qui effectivement est une mauvaise idée parce que ça va peter dès qu'on a besoin de plusieurs sources différentes).
> Donc avant je faisait, en gros un connect() à chaque accès,
> maintenant je 'trie' les connections pour n'ouvrir que des connexions
> nécessaires. Dans tes scripts tu ne donnes pas un identifiant de
> connexion ? tu laisses php prendre par défault le dernièr utilisé ?
> arggg
J'ai dit ça ?
Non, j'utilise tout comme toi les identifiants de connexion. Je reprend ton exemple :
> fait une connection host1 - base1 -> print id : Ressourceid#4 (par
> ex)
> ensuite encore host1 - base1 -> print id : Ressourceid#4 (normal,
> suivant ta théorie car php réutilise la dernière connection)
Oui. D'ailleurs si jamais tu ne me crois pas, tu peux lire la doc :
""" Si un deuxième appel est fait à mysql_connect() avec les mêmes arguments, aucune nouvelle connexion ne sera établie, mais plutôt, l'identifiant de la connexion de la connexion déjà ouverte sera retourné."""
> MAIS host1 - base 2 -> print id : Ressourceid#4 (je ne comprend
> pas !!!, ce n'est pas le même connexion, et tu n'a pas assez aux
> mêmes tables.)
Ben oui, mais regardes ce que tu fais avec ton code :
$link1 = mysql_connect('host1') ;
mysql_select_db('base1', $link1) ;
$link2 = mysql_connect('host1') ;
// là $link2 est bien le meme que le précédent $link1,
// d'ailleurs tu l'as vu toi même
mysql_select_db('base2', $link2) ;
// tu as toujours la meme connexion
// mais tu viens de lui demander de changer de base
// donc forcément tu ne vois pas les memes tables
// maintenant essayes de lister les tables sur $link1
// tu verras qu'elles ont changes aussi.
Si tu veux avoir deux connexions distinctes, tu as un paramètre spécifique sur mysql_connect() qui dit explicitement "j'ai déjà une connexion avec ces paramètres mais j'en veux une nouvelle, pas la meme"
> Donc avant je faisait, en gros un connect() à chaque accès,
> maintenant je 'trie' les connections pour n'ouvrir que des
> connexions nécessaires.
On s'est bien compris, et moi (ainsi que la doc) je te dis que même auparavant, tu n'ouvrais que les connexions nécessaires et que tu ne faisais jamais de doublon (sauf si tu fermais la connexion explicitement ou que tu forcais le doublon avecle paramètre adéquat, mais là ça devient volontaire)
> Je ne sais pas, comment cela ce fait-il que en c
Peut être parce que le PHP n'est pas identique au C ? qu'un langage compilé n'a pas les mêmes avantages et inconvénients qu'un langage interprété ? que avec la lenteur globale de PHP le changement de contexte d'une fonction est négligeable ou en tout cas l'argement réduit par rapport à ton chiffre de x1/x10 ?
Pour un simple exemple, en PHP passer un argument explicitement par référence est plus lent que le passer par copie. Et *paf* pour les idées reçues et le "oui mais en C ...."
Autre exemple ? en PHP l'accès à une constante est plus lent que l'accès à une variable, et re-*paf* pour les idées reçues et le "oui mais en C ..."
Bref, se méfier beaucoup des légendes urbaines sur les performances. Et principalement dans PHP qui a ses propres logiques et peu de gens qui connaissent vraiment le fonctionnement interne.
Le fait que tu gagnes parfois des perf sur certains inline en C ne veut pas dire qu'il faut faire la même opération en PHP, ou que tu vas y gagner assez (comprendre: assez pour que l'effet positif des performances contrebalance l'effet nagatif de la duplication de code et de la relecture)
> Oui, oui allons dans les " blabla $var bliobli..." oui c'est cool, même
> avec un "select * from base where id= $_POST['login'] "cela va
> plus vite à coder et plus vite à analyser et... un peu goret qd même.
Ah ?
entre les deux codes suivant, lequel est le plus clair, le plus goret, et pourquoi ? enfin en retirant ton exemple biaisé qui utilise directement une entrée utilisateur sans filtrage et sans echappement bien entendu.
V1 :
$id = calcule_filtre_et_recupere_id() ;
$date = calcule_filtre_et_recupere_date() ;
$sql = "SELECT * FROM base WHERE id=$id AND date<'$date'" ;
V2:
$id = calcule__filtre_et_recupere_id() ;
$date = calcule_filtre_et_recupere_date() ;
$sql = 'SELECT * FROM base WHERE id='.$id.' AND date<\''.$date.'\''" ;
Niveau clarté c'est sans appel je choisis la V1
Niveau performances c'est kifkif mais si tu tiens à calculer les demi-microsecondes la V1 est plus rapide
Niveau goret ... tu m'expliques en quoi la V1 est goret ?
> Réutiliser du code existant ? cela voudrait dire le passer en revue
> pour qu'il devienne 'trusted' pour moi et mon employeur (autant de
> temps que de le réécrire), si je suis employé et que je fournis du
> code 'emprunté' à d'autres, demain, mon travail sera 'donné' à
> d'autre.
Si ta valeur ajoutée c'est de refaire depuis zéro ce qui existe ailleurs et qui marche je conçois que tu te fasses du souci pour ton travail.
Moi ma valeur ajoutée c'est justement de faire ce qui n'existe pas, de réutiliser pour adapter ou étendre.
D'ailleurs, ça mis à part, je suis étonné que sur un site proche du libre et de la communauté, on ne voit pas l'intérêt à mutualiser les codes et à réutiliser plutot que tout refaire dans son coin.
Pour reprendre ton exemple, si j'ai l'assurance qu'un CMS, un outil de blog, un DHAL, une classe de manipulation Excel ou je ne sais quoi d'autre correspond à mon besoin et à ma licence et à mes critères qualités, je ne me priverai pas de le réutiliser/modifier pour reproter mon travail sur ma valeur ajouté.
Si c'est pour refaire quelque chose qui existe déjà ils n'ont justement pas besoin de moi.
> Alors Non, ce ne sont pas des applis à 200 euros, mais bien plus,
> si tu veux travailler pour pas chèr avec de la réintégration du travail
> d'autres, c'est un choix/obligation du marché. A ce niveau là, les
> pays de l'est vont ceuillir ce marché très facilement.
Je préfère faire des applications complètes, chères, de qualité, avec de la réutilisation ;)
Le fait de réutiliser (là où c'est pertinent) me permet justement de faire des applis plus complètes et de meilleure qualité, pas forcément de dire "j'en fais moins".
Si tu fais des applications à 200ke qui ne font qu'à peine plus qu'e ce que font les briques dispo en LL parce que tu perd ton temps à tout réécrire, c'est plutot toi qui va avoir du mal à te reveiller. Parce que ton marché de l'est lui il va justement te proposer la même chose pour 1000 fois moins cher puisqu'il ne fera que les ajouts/modifs à partir de l'existant, pas tout le développement.
Quoi que dans ma boite l'externalisation elle est au Maroc, mais la problématique est la même. Ici on coute plus cher, c'est pour faire ce qu'on ne peut pas faire ailleurs : l'adaptation et la spécialisation des applicatifs (où il faut être proche du client), recoder des briques le Maroc peut le faire, ils ont des gens largement aussi compétents qu'ici (contrairement aux idées reçues du type "moi je fais du bon code d'expert, je ne suis pas en concurrence").
> Je ne rentre même pas dans la réthorique de la course à la
> puissance, pourquoi me faire chier à optimiser, y des proc bi-core
> qui arrivent.
Il s'agit juste de faire de efforts utiles. Quand on gagne millisecondes par jour après avoir faire une revue/modification complète de code (donc probablement plus d'une semaine) et avec tous les risques d'erreur que ça entraine (donc les temps de test, recette, etc.) je connais très peu d'entreprises qui trouvent utile de faire le pas (en fait je n'en connais aucune).
Le pire c'est quand, à force de vouloir optimiser tout et n'importe quoi sans connaitre le langage on fini par faire un travail inutile, type ce que tu fais avec les mysql_connect().
Non, sérieux, ton code et ton architecture sont si parfaits que tu en es à optimiser ce genre de chose pour des gains si modestes ? tu es sûr de ne pas avoir assez de travail ailleurs plus utile/pressé pour laisser ça de coté ?
[^] # Re: contre
Posté par Éric (site web personnel) . En réponse au journal Petition MYSQL chez Nerim. Évalué à 1.
> fois plus lent que le code exécuté inliné (pour le php).
C'est une stat qui ne veut rien dire. Ca a du être fait en faisant 10000 fois 1+1 dans une boucle et en comparant avec autant d'appels de fonction qui font chacune 1+1.
Dans un cas réel on est très loin de ces chiffres, et non, si tu fais une fonction qui appelle une fonctiton qui appelle une fonction, ton code n'est pas magiquement 1OOx plus lent, heureusement.
> pour remplacer les "" par des '' (pour gagner un peu de performance),
> réutiliser les même liens aux bases plutôt que de les recréer (je
> n'utilise pas les p_connect pour alléger la charge de la base de
> donnée) car même 1 seconde seulement de gagné (tout confondu:
> accès sql + traitement sql + php + transmissions html) est 1 seconde
> de gagné pour l'expérience utilisateur
Ou comment perdre du temps pour rien.
L'histoire du " => ' c'est vrai, mais globalement ça fait gagner des dizièmes de millisecondes au mieux. Si tu gagnes 15s de proc à la fin de la journée tu peux estimé avoir eu une chance extraordinaire. Si tu regardes le temps passé, le smic horaire, tu auras plus vite fait de changer de proc ou rajouter un serveur en load balancing que t'amuser à reprendre tous tes délimiteurs de chaine. Je ne parle meme pas du fait que le " => ' est vrai pour des chaines statiques. Si tu as des remplacements de variables, un "xxx $var xxx" n'est pas plus lent que 'xxx '.$var.' xxx', au contraire. Bref, du temps de perdu pour rien, et autant de possibilités de bugs et régressions si tu fais des erreurs.
L'idée de mutualiser les connect() pour le pas faire plusieurs connexions est encore pire. Mysql réutilise déjà les liens vers la base. Fais 150 mysql_connect() dans le même script avec les mêmes paramètres, PHP n'ouvrira qu'une seule connexion et te renverra toujours le même identifiant. Tu viens donc de repasser tout ton code pour refaire coté utilisateur ce que mysql fait déjà en interne tout aussi bien et probablement plus rapidement, heureux ? Peut être que si ton code était mal organisé tu faisais un peu trop d'accès aux fonctions de connexion là où un attribut de classe aurait été avantageux, mais aller faire la chasse aux connect() n'a aucun sens, ça ne changera rien aux ressources utilisées.
Et tu as quoi comme application pour que ça nécessite d'aller faire des revues de code pour gagner les quelques microsecondes de " => ' ou pour considérer que tu ne peux te permettre de réutiliser des codes existants ?
Heureusement cette mode des performances par les performances est passée. Je ne dis pas qu'il est bon d'ignorer les perfs, ni que les perfs ne servent à personne, mais ce genre de bidouilles qui font gagner 3ms/jour pour 3h de travail ça n'est efficace pour personne, même pour des boites comme yahoo.
[^] # Re: contre
Posté par Éric (site web personnel) . En réponse au journal Petition MYSQL chez Nerim. Évalué à 3.
> fonctionnels spécfiques des DBAL (gestion des erreurs, transformation de
> ResultSet, etc.)
Non non, je n'exagère pas, et je parle de quand on n'utilise vraiment rien ou presque du DBAL (select classiques)
Pour crédibiliser ce que je dis et donner des chiffres concrets :
MySQL 1.14 -
ADOdbext 1.30 14%
dbx 1.37 20% (index only)
ADOdb 1.45 27%
dbx 1.53 34% (index/assoc/info)
PhpLib 1.60 40%
MDB 1.75 54%
PEAR DB 2.87 152% (fetchInto)
PEAR DB 3.15 176% (fetchRow)
M'base 2.52 296% (numeric cols)
M'base 4.77 318% (assoc cols)
Ce sont des chiffres donnés/faits par les dev d'ADOdb eux-mêmes. On peut donc facilement penser qu'ils ont plutot tendance à gonfler leurs perf qu'à les diminuer. Ca laisse quand même 14% pour l'extension C d'ADOdb, et quasi 30% pour la version PHP que tout le monde utilise. Si on s'intéresse à PEAR::DB ça fait du x2 par rapport au mysql direct.
A mon avis et d'après mon expérience ils exagèrent un peu pour PEAR::DB mais dans l'ensemble l'ordre de grandeur correspond à ce qui est trouvé/publié un peu partout et ce que je vois de coté aussi.
14% ça reste largement acceptable, mais on parle de l'extension C que quasi aucun hébergeur n'a et que beaucoup d'entreprises vont hésiter à mettre puisque non offocielle. 30% à 150% par contre ça devient moins rigolo.
Donc oui, c'est intéressant, mais ça a bien un cout non nul.
> Maintenant, avec l'arrivée prochaine de PDO, je pense que la lenteur va encore
> diminuer du fait du codage de la couche en C.
Sauf que PDO n'est *pas* uen abstraction de base de données. C'est bien dommage d'ailleurs parce que l'idée de base est plutot bonne. Il manque très peu pour pouvoir au moins s'en servir comme DBAL pour des besoins simples, mais ça ne supporte même pas de clause offset/limit, ça ne gère même pas les séquences/autoincrement, etc.
Du coup DBO ça te permet juste de garder les mêmes noms de fonction. Malheureusement c'est vraiment la partie la plus simple et automatique dans un portage. Ce qui prend du temps c'est tout le reste ... que ne fait pas DBO.
PDO l'unique but c'est de n'avoir à apprendre/gérer qu'une seule API unifiée. Par contre l'exploitation de l'API reste dépendante du SGBD (et malheureusement les spécificités des SGBD ne sont pas encore implémentées dans PDO donc la migration vers PDO n'est pas réalisable pour pas mal de gens)
[^] # Re: contre
Posté par Éric (site web personnel) . En réponse au journal Petition MYSQL chez Nerim. Évalué à 3.
Tu peux retrancher facile 10% pour ADODB, facile 30% pour PEAR::DB, et je suis gentil ... Et plus l'appli est basique avec un machine poussive (coté disque), plus ça va se sentir.
On n'en est pas au niveau des optimisations là, on est vraiment du coté du "oulà c'est lent".
AMHA les avantages compensent les inconvénients, mais ça a un cout, ça c'est certain.
[^] # Re: numéros de version
Posté par Éric (site web personnel) . En réponse à la dépêche Actualités Firefox, Thunderbird, Mozilla et SeaMonkey. Évalué à 4.
Note: à partir de firefox 1.5 les extensions utilisent un fichier texte avec un autre format à la place de ce content.rdf. Maintenant je dis ça je dis rien (et j'avoue qu'il n'est pas impossible qu'ils aient gardé compatibilité en doublant l'algo, je n'ai pas testé).