Pierre Tramo a écrit 675 commentaires

Wikipedia n'est pas un équivalent de cette encyclopédie. Il n'est pas disponible hors-ligne (pas de façon simple en tout cas) et reste assez léger niveau contenu multimédia (copyright oblige).
Tout à fait, et s'il est techniquement assez facile de mettre le contenu du site sur un support offline quelconque (pour les dev du site), enrichir le contenu multimedia sera une autre paire de manches.

Aujourd'hui en France, environ un livre sur deux est publié par une des maisons d'édition du groupe Lagardère.
Et environ autant (voire même plus, surtout dans le domaine scolaire) par une des maison d'éditions appartenant au baron de medef. Faut-il boycotter les livres pour autant ?

Et acheter un LinuxMag dans un magasin Relay à la gare, ou bien acheter un CD quelconque chez Virgin Megastore, ou bien écouter Europe {1,2}, etc., ça aussi c'est filer des sous à Lagardère et financer la guerre partout dans le monde.
Et encore, ça m'étonnerait que le transfert d'argent se passe dans ce sens, c'est plus EADS qui doit rapporter de l'argent à Lagardère, argent ensuite investi (partiellement) dans Hachette, à mon avis. Donc c'est la guerre partout dans le monde qui financerait tous ces media, contenus et circuits de distribution [:totoz]

ce sont surtout les encyclopédies qui sont en passe de mourir gentiment
C'est vrai que le web et en particulier des sites comme Wikipedia remettent en cause le modèle économique des encyclopédies commerciales à moyen terme.

Concernant la musique, c'est plus ou moins la même chose.
Pas tout à fait : on peut facilement échanger une encyclopédie contre une autre, par contre échanger le dernier Björk contre le best of de la starac, ben euh... moyen.

Personne n'est obligé d'acheter du contenu DRMisé.
Pas encore, mais les majors y veillent (et beaucoup d'autres acteurs de l'industrie de l'entertainment).

Il existe plein d'artistes qui distribuent leurs oeuvre (que ce soit de la musique ou autre) de façon libre et/ou gratuitement
Oui mais ce système ne peut pas être généralisé à tous les artistes : s'il convient bien à un amateur (qui a un boulot à côté pour se nourrir) ou à un artiste qui a besoin de se faire connaître (et là l'efficacité du système reste à démontrer), il n'assure pas à un à artiste qu'il pourra d'une part financer ses futurs créations et d'autre par gagner sa vie. Ce modèle alternatif doit encore être affiné.
Et après on verra si les artistes sont capables de faire le grand saut et de laisser tomber les majors, qui avec le temps sont devenues des intermédiaires très coûteux et de moins en moins utiles du système économique culturel.

Donc les softs qui permettront de lire des contenus protégés par DRM seront TOUJOURS PROPRIETAIRES.
Il y a aussi des techniques de DRM basées sur du matériel (et donc beaucoup moins faciles à violer) qui sont en préparation, elles devraient alors pouvoir être exploitées par des logiciels 100% libres. Mais je ne suis pas sûr que ce soit plus réjouissant :/

Sur le fond je pense perso qu'il a raison, acheter cette encyclopédie c'est financer la guerre partout dans le monde.
Tout comme consommer des substance illicites c'est financer le terrorisme ? Tu utilises les mêmes raisonnements bancals et infondés que certains ministres de droite.

Pourquoi ne pas dire au moins qu'il existe un équivalent libre, de qualité supérieur et qui fait de vous des acteurs et pas seulement des spectateurs ?
Et bien voilà, tu l'as dit.

on fait de la pub pour les marchands d'armes qui éditent des logiciels propriétaires
On passera sur les rapports entre Hachette et EADS qui sont très loin de ce que tu décris, pour préciser que Hachette n'est pas un éditeur de logiciels mais un éditeur et un distributeur de contenu. L'interface n'est là que pour servir le contenu (après, évidemment on peut critiquer le contenu, mais c'est une autre histoire).

logiciels propriétaires basés sans scrupule sur les logiciels libres, sans aucune contre-partie
Ah tu ne vois aucune contre-partie ? Moi j'en vois deux :
- la crédibilité de la plateforme Mozilla pour développer des produits multimedia multiplateforme
- la reconnaissance de GNU/Linux comme cible pour ces produits, c'est-à-dire comme OS grand public, par les éditeurs de contenus
Certes, mettre l'interface sous une licence libre serait appréciable, mais la contribution de cette encyclopédie n'en est pas moins très positive.
Je préfère voir ça que le même Hachette qui choisit la solution ultra-fermée Windows Media pour son site Virginmega...

Coches la case pour que la session soit permanente...
(leçon 5 au passage :p )
Justement, pourquoi ne pas avoir mis "connexion/session permanente" ? Le terme "automatique" laisse supposer qu'une nouvelle session est créée à chaque fois qu'on vient sur le site. Et les forums ne doivent pas pallier le choix de termes incorrects.

Et au passage, pourquoi avoir supprimer toutes les sessions se week end (en particulier toutes celles qui avaient une activité récente) ? Surtout que certains (c-à-d ceux qui l'ont utilisée ?) ont eu des problèmes avec la page de récupération des mots de passe.

Pour finir, quand un journal/forum est déplacé, ne serait-il pas possible d'être redirigé automatiquement, ou d'avoir un lien vers la nouvelle localisation ? Avec la page d'erreur qui nous indique (en anglais, pour une audience francophone) que the requested URL /forums/13/3717.html was not found on this server, on ne sait pas si la page a été supprimée, déplacée, ou s'il s'agit d'une erreur de frappe. Et vu que la page ne contient aucun lien (page de l'auteur, page des journaux, page des forums, ...) susceptible d'aiguiller le lecteur dans sa recherche de la nouvelle URL, il doit déjà bien connaître le site pour avoir une chance de s'y retrouver.
Et d'ailleurs, pourquoi les URL des journaux contiennent-elles le numéro de la section, puisque le numéro du journal n'en dépend pas ? Supprimer cette partie inutile permettrait déjà d'avoir des URL résistantes au changement de section.

J'ai pas trouvé de guide, mais en survolant la javadoc du package java.io on peut déjà se faire une idée.
L'important à savoir pour commencer, c'est qu'il y a quatre classes (abstraites) de base, selon qu'on manipule des flux d'octets (InputStream, OutputStream) ou des flux de caractères (Reader, Writer). Ensuite on choisit une implémentation selon le support du flux (fichier, String/StringBuffer, tableau d'octets) ou on obtient le flux en retour d'une méthode (sockets), il existe aussi des passerelles de flux d'octets vers flux de caractères. Enfin, il y a les classes (toujours abstraites) Filter* (et quelques autres) qui ajoutent des facilités pour la manipulation d'un flux (quel qu'en soit le support), selon l'implémentation qui correspond au besoin (Buffered*, Print*, ...).
Voilà, c'est un bref résumé. Après il y a aussi java.nio et ses Channels mais c'est une autre histoire ;)

Bon, ben les 40 secondes devaient venir d'autre part que de la recherche sur tout le contenu. J'ai utilisé ce code :

			Reader reader = new InputStreamReader(doc1.openStream());

			int nbChars;

			char[] chars = new char[1024];

			StringBuffer content = new StringBuffer();

			

			while ((nbChars = reader.read(chars)) != -1) {

				content.append(chars, 0, nbChars);

			}

			reader.close();

			

			m = p.matcher(content);

			

			while (m.find()) {

				buffy.append("Mediabarre : ").append(m.group(4)).append(" pour ").append(m.group(5)).append('\n');

			}

Et c'est quasi instantanné (et je n'ai pas une machine de guerre), du même ordre que la recherche ligne par ligne (modulo le temps consommé par le réseau et l'interface graphique).

PS : tu as lu http://java.sun.com/j2se/1.4.2/docs/api/java/net/URLEncoder.html#en(...) ?

Bon, on va prendre dans l'ordre :o

import java.util.*;

Moi j'évite d'importer des packages entiers. D'une part ça doit ralentir un chouille la résolution de noms au chargement de la classe (j'avais remarqué en désassemblant des .class que le compilo ne remplaçait pas les * par la bonne liste de packages), mais surtout ça rend la maintenance du code plus difficile : si tu reprends ton code quelques mois/années plus tard et que t'as pas un bon IDE sous la main, tu risque de passer du temps à retrouver dans quel package était telle ou telle classe.

v = new Vector();

Vector, c'était dans l'ancienne API des collections. Dans l'actuelle, il y a la classe ArrayList qui est équivalente et qu'il vaut mieux utiliser : si plusieurs threads ne risquent pas d'accéder simultanément à une liste, les accès seront plus rapides en utilisant un ArrayList qu'un Vector ; et surtout, la nouvelle API des collections est plus complète, plus souple,... donc autant oublier l'ancienne. Et pour faire propre, on peut découpler le type de structure et son implémentation : List i = new ArrayList();

jLabel1.setText("Bienvenue sur RLFind, votre meta-moteur de recherche pr\u00e9f\u00e9r\u00e9 !");

Hmmm pourquoi encoder les caractères accentués ?

String mediabarre = new String("...");

Alors je reviens là dessus : on ne fait jamais String s = new String("plop"); (ça crée un fait deux objets String, inutilement), mais String s = "plop" (un seul objet String créé, implicitement).

StringBuffer buffy=new StringBuffer("");

Pas besoin de créer une chaîne vide pour initialiser le StringBuffer, new StringBuffer() donnera le même résultat.

            Pattern p;

            Matcher m;

            p = Pattern.compile("...");

Vu que le pattern est immuable, il est préférable de le compiler une fois pour toute et non à chaque appel de la méthode jButton1ActionPerformed, en le déclarant comme attribut de classe contstant (static final). Pour les chaînes constantes, c'est aussi plus propre de faire comme ça.

p = Pattern.compile("dvd");

C'est une coquille, non ? Ça ne devrait pas être là ?

Bon, maintenant on va pouvoir commencer à regarder en détail :o

Enfin, j'ai mis un peu de temps à te répondre à cause du déplacement de ton journal dans les forums (ce qui est quand même plus sa place).
Oui, c'est peut-être plus la place, mais ça serait bien que les modéros n'utilisent pas la fonction de déplacement avant de l'avoir débuggée : y a pas longtemps, le nombre de commentaires affiché ne prenait pas en compte les commentaires postés quand c'était encore un journal, et maintenant le changement efface les informations sur les commentaires lus/non lus, et du coup, la navigation avec la barre ne sert plus à grand chose :/

C'est <pre> qui est utilisé, mais comme chaque retour chariot est doublé d'un <br/> (enfin j'ai pas vérifié mais ça y ressemble), bah y a une ligne sautée inutilement à chaque fois.
On peut les désactiver, mais ça devient pas pratique pour le texte qui entoure le code...
Faudrait ptet désactiver les retours chariot spécifiquement dans les <pre></pre> (ou utiliser une mise en syntaxe style wiki), mais je tiens trop à ce qu'il me reste de santé mentale pour me plonger dans le code templite et faire un patch :°)

Ah oui, 40 secondes, quand même ! Tu peux poster ton code final ?

Là ça vient clairement de ton code, y a pas photo :p
Et si tu veux faire un bench, fais bien attention de ne pas inclure le coût de la récupération du document par réseau, et aussi celui de l'interface graphique.

Moi aussi, le passage

    BufferedReader plop = new BufferedReader(new InputStreamReader(doc1.openStream()));

    while((tmp=plop.readLine())!=null)

    {

        html = html + tmp;                

    }

    plop.close();   

me parait très sous-optimal, une boucle de lecture sur le InputStreamReader avec écriture vers un StringWriter, ça serait déjà moins violent. Bon, après , l'expression matchée tiens sur une ligne (ce qui a l'air d'être le cas), tester sur chaque ligne du BufferedReader, c'est effectivement encore mieux, ça évite de stocker tout le doc.

            String mediabarre = new String("http://mediabarre.2xmoinscher.com/DVD/liste.asp?strRech=(...(...))");

            String keywords=new String("robin des bois");

            keywords=URLEncoder.encode(jTextField1.getText());

            mediabarre = mediabarre + keywords;

Déjà, ça faut pas le laisser passer [:totoz]. Un String mediabarre = "http://mediabarre.2xmoinscher.com/DVD/liste.asp?strRech=(...(...))" + URLEncoder.encode(jTextField1.getText()); sera bien plus efficace. En particulier, les String truc = new String("bidule") sont à proscrire, String truc = "bidule" marchera aussi bien.

           while (m.find())

           {

               txt_resultat.setText(txt_resultat.getText().concat("Mediabarre : " + m.group(4) + " pour " + m.group(5) + "\n"));

           }

Ça aussi, il faut le revoir. La concaténation de chaînes était très coûteuse, les concaténations en boucle sont catastrophiques pour les perf :

           StringBuffer buffy = new StringBuffer();

           // ou StringBuffer buffy = new StringBuffer(txt_resultat.getText());

           while (m.find())

           {

               buffy.append("Mediabarre : ").append(m.group(4)).append(" pour ").append(m.group(5)).append('\n'));

           }

           txt_resultat.setText(buffy.toString());

devrait légèrement accélérer les choses (le compilo remplace String s = a + b par String s = new StringBuffer(a).append(b).toString();, il faut toujours l'avoir en tête), d'autant plus que l'interface n'aura pas à être raffraichie à chaque fois.

Voilà, c'est ce qui me saute aux yeux en première lecture.

Non, je ne retrouve plus mes sources :(
Il audrait voir dans les articles de quand Intel a dévoilé le jeu d'instructions.

Les DVD, le succes des DVD c'est le p0rn aussi :p

Et aussi du Minitel, de Canal+, ...
C'est le cul qui mène le monde.

Cette version est juste un candidat à la Preview Release
Une Preview Release Candidate ? Pfiouuu ça devient dur de s'y retrouver dans toutes ses versions...
Et on connait le nom de la version finale ? FireDog ? Phallus ?

EMT64
Ceci est la réponse d'Intel à son concurrent direct puisqu'il s’agit de faire cohabiter 32 et 64 bits dans un même processeur (il me semble même que cette technologie a été rachetée à AMD, mais cette information est à prendre avec des pincettes).

Intel et AMD ont passé il y a quelques années un accord de licences croisées sur leurs technologies de l'époque et à venir. Ceci mettait fin à la tentative d'Intel d'empêcher AMD d'être compatible avec ses extensions multimédia SSE, contrée par AMD avec une plainte pour violation de brevets, si ma mémoire est bonne.
Donc Intel n'a rien à reverser à AMD pour cette techno (et d'ailleurs lors de sa présentation, il n'a même pas mis en avant la compatibilité (à une instruction près, qui ressemble à un oubli d'AMD) de sa techno avec celle d'AMD).

Intel annonce la virtualisation comme une avancée majeur dans le monde informatique.
Pour la microinformatique, peut-être :o

Outre ces avancées technologiques certaines, le site hardware.fr s’interroge sur les problèmes que peuvent engendrer ces évolutions
Ouais, on va les laisser avec leurs interrogations sans grand fondement.

C'est vrai qu'il se donne du mal :o
Moi j'arriverai jamais à avoir autant de mauvaise foi, même en mettant beaucoup de c½ur à l'ouvrage. Il trolle sans répit, c'est qu'il en faut de l'endurance.
Par contre, il fait pas trop dans la dentelle, il trolle toujours comme un goray, on le voit venir à des kilomètres. Toujours le même style, reconnaissable entre mille, même quand il change de multi.
Donc à moins qu'il ne fasse de sérieux efforts pour troller plus subtilement (vu que c'est la rentrée, y a pas une école qui propose des cours ? l'Epita, peut-être ? :°), alors non, définitivement non, il ne sera jamais trolleur du mois ni de quoi que ce soit.

- rien ne les obligent, la freebox est toujours à eux, même si tu paie 400 euros
Certes, mais dans l'hypothèse (qui reste à vérifier) selon laquelle ils auraient modifié du code GPL sans partager leurs modifs, je ne suis pas sûr que ce code ne soit considéré comme diffusé vis-à-vis de la GPL

- divulger les sources, c'est anéantir tout leur travaille face à la concurrence
Bof, il doit y avoir beaucoup de choses liées au matériel, donc difficiles à réutiliser, et aussi beaucoup de choses qu'on trouve facilement ailleurs.

- divulger les sources, c'est rendre possible la diffusion du flux MPEG2 vidéo vers le PC, c'est permettre la copie numérique
Alors là rien n'est moins sûr que ce soit techniquement faisable, vu que le décodage est matériel. Et quand bien même quelqu'un modifierait le code pour balancer un flux MPEG vers un PC, il faudrait encore réussir à installer ce code sur la Freebox, et matériellement, ça me semble délicat.

c'est trahir la confiance que les fournisseurs de flux ont mis en eux (bah oui c'est pas pour rien si le flux vidéo ne sort qu'en péritel)
Euh oui, enfin il faut regarder aussi la liste des chaînes qui acceptent d'être diffusées (par rapport à celles accessibles sur le cable, le sat et les tv/adsl concurrents), et se demander pourquoi les équipements VOD que Free a achetés ne sont pas utilisés, pour avoir une idée de la confiance des producteurs de contenu envers Free ^^

Ça c'est des équipements en amont du DSLAM, pas dans la Freebox.
La liste des produits Anevia en atteste : http://www.anevia.com/products.en.php(...)

En même temps, c'est un macounet, rien d'étonnant à ce qu'il fasse preuve d'un goût plus que douteux.
Bon d'accord, là ça dépasse les limites du soutenable...

Peut-être que tu n'as pas assez d'XP qui n'existent plus pour avoir le droit, pardon le privilège, de recevoir des messages et de les lire via ta page personnelle.
J'espère que ça va te motiver à participer à l'amélioration de la qualité du site en postant quelques commentaires consensuels.

ET SI C'EST EFFICACE, ON SERA DISPENSÉ DE SHIFT< ?

En même temps, on sait qu'ils lisent linuxfr (peut-être pas tous mais une bonne partie), un journal de doléances commun permettra donc de mettre l'accent sur l'unanimité des avis ;)