M a écrit 2996 commentaires

  • [^] # Re: ...

    Posté par  . En réponse au journal Wikipedia met l'Ogg sur le devant de la scène. Évalué à 8.

    Un lecteur VLC "viole" la loi en difusant un binaire pouvant lire du MPEG-4 sans payer de royalties...
    Ha bon. Il est ou le passage dans la loi qui indique qu'on n'a pas de droit de distribuer un binaire/du code qui implémentent des normes (qui sont au passage librement accessible pour l'ITU (h264, ...)).

    On me souffle dans l'oreille qu'une partie repose sur les brevets logiciel qui n'ont pas officielemnt cours en Europe...
  • # ...

    Posté par  . En réponse au journal Wikipedia met l'Ogg sur le devant de la scène. Évalué à 2.

    La très bonne nouvelle, c'est que ce sera fait dans le but d'être lisible par les logiciels libres !
    [...]
    Ogg (theora pour l'image, vorbis pour le son)

    je vois mal pourquoi les formats xiph seraient des logiciels libres. Ils sont librement implementable.

    Quand à Kaltura, si ça repose sur flash, ca repose quand meme sur une techno proprio.


    Je ne parle même pas des perfs...
    Deja que flash c'est super long, mais la on parle de supporter un format non supporter d'origine par flash. Ils ont implementer en les décodeurs en flash ???
  • [^] # Re: Appel protège ses logiciels

    Posté par  . En réponse au journal Mac OS X et Dtrace. Évalué à 3.

    Sauf que dtrace est un logiciel libre et que rien ne t'empêche de prendre le code source est de le recompiler en virant les 3 lignes qui ne serveur à rien.

    T'es sur qu'il y a pas une protection aussi de l'autre coté ?
    Et que ce bout de cote est juste pour éviter que Dtrace plante/affiche de warning quand on essaye de l'attacher a ce type de processus ?
  • [^] # Re: langage de haut niveau?

    Posté par  . En réponse à la dépêche Sortie de Vala 0.1.6. Évalué à 3.

    Mon petit projet à moi en Vala:
    [http://code.google.com/p/vala-benchmarks/]
    Implémentation de quelques benchs du shootout benchmark en Vala et comparaison avec Mono et C.


    Juste une question à la con :
    Je crois que vala était destiné à faire des appli gnome, c'est à dire des appli qui font soit de l'IHM soit de l'accès aux ressources (accès fichier, configuration wifi, ...).
    Et qu'est ce que l'on trouve dans les bench ? Des trucs purement algorithmique...

    PS : d'ailleurs la comparaison de partialsums est intéressante http://vala-benchmarks.googlecode.com/svn/trunk/partialSums/(...)
    C'est quasiment le même code.
  • # compilo

    Posté par  . En réponse à la dépêche Sortie de Vala 0.1.6. Évalué à 4.


    Vala est un langage de programmation avec une syntaxe fortement inspirée du C# conçu pour l'environnement GNOME.

    Y aurait il la grammaire du langage quelque part ? L'API ?
    J'ai rien vu de précis sur le site de vala.

    Bien qu'il s'agisse d'un langage de haut niveau, possédant par exemple des patrons de classe, de l'inférence de type ou des fonctions anonymes, il est compilé en C et utilise la bibliothèque GObject de façon standard.
    Et qu'est ce que ça change ?
    A part que ça sent un peu l'usine à gaz derrière.
    J'espère qu'ils ont prévu des surcouche à gcc, gdb, ... pour retranslater le C généré en un truc débugable.

    Je trouve dommage qu'ils ne sont pas parti d'un langage existant. Créer un langage propre et qui marche est loin d'être trivial...

    Et pour la fin un petit troll tirer de http://live.gnome.org/Vala
    There won't be a vala runtime library and applications can distribute the generated C code with their tarballs, so there are no additional run- or build-time dependencies for users.
    miam, ca va être du bonheur s'il y a des erreurs de compil.
  • [^] # Re: Why? \o/

    Posté par  . En réponse à la dépêche Nouvelle version d'Extreme Tux Racer !. Évalué à 5.

    oui mais que sont devenu les autres forks libre ?
    Parce que la ca fait combien de fork de tux racer ? 3 ou 4 ?
  • [^] # Re: Erreur a la compilation

    Posté par  . En réponse à la dépêche Le code source de SimCity libéré. Évalué à 2.

    J'ai eu le meme pb avec la version d'origine.
    Par contre http://www.getdeb.net/app.php?name=Micropolis marche chez moi.
  • [^] # Re: Erreur a la compilation

    Posté par  . En réponse à la dépêche Le code source de SimCity libéré. Évalué à 4.

    Faut desactiver le num lock
  • # clone libre

    Posté par  . En réponse à la dépêche Le code source de SimCity libéré. Évalué à 10.

    N'oublions pas qu'il existe aussi d'excellents clones libres de simcity :
    lincity : http://www.floot.demon.co.uk/lincity.html (et la version ng http://lincity-ng.berlios.de/wiki/index.php/Main_Page )
    opencity : http://www.opencity.info/
  • [^] # Re: relativiser...

    Posté par  . En réponse à la dépêche Sortie de Syllable 0.6.5. Évalué à 2.

    L'objectif est très simple : c'est de créer un système "desktop" par rapport à Linux qui est un peu trop "server". (puisque l'on s'est même longtemps demandé si Linux allait réussir à percer sur le "desktop" :-).
    J'ai pas trouvé l'interface graphique très intuitive alléchante (je dis pas que sous linux c'est mieux). Par exemple la validation se fait parfois par bouton, d'autre fois par fermeture de la fenetre

    Ce que je trouve qu'il manque c'est une interface pour neuneu : simple, intuitive, ...
  • [^] # Re: FreeRunner et vitesse CPU

    Posté par  . En réponse à la dépêche LiPS 1.0, Bazaar 1.0 et OpenMoko Neo FreeRunner. Évalué à 2.

    En fait le cpu peut aller jusqu'à 500mhz
    Oui tu peux toujours l'overclocker d'une valeur raisonnable (ici 25 %)...

    D'ailleurs vu que les sources/doc sont dispo il sera toujours possible de le faire chez toi à tes risques et périls.
  • [^] # Re: FreeRunner et vitesse CPU

    Posté par  . En réponse à la dépêche LiPS 1.0, Bazaar 1.0 et OpenMoko Neo FreeRunner. Évalué à 3.

    Sauf que si tu regarde les info sur le S3C2442 [1], tu veras qu'il tourne dans les 300/400Mhz.

    [1] http://www.samsung.com/global/business/semiconductor/product(...)

    PS : a une epoque samsung publiait toutes leur datasheet de CPU, mais c'est désormais finit...
  • # ...

    Posté par  . En réponse au journal Linux et le Ctrl T. Évalué à 3.

    Sinon sous Linux en mode console, il y a Syst + T pour voir l'état des tâches.
  • [^] # Re: Navigo

    Posté par  . En réponse au journal Bye bye les tags mifare. Évalué à 2.

    c'est pas prêt d'arriver :
    De quoi les guichet qui disparaissent ?

    Et ben si c'est la triste réalité. Si t'es pas convaincu va faire un tour dans certaines gare de banlieue.
    D'ailleurs c'est très pratique si t'as un renseignement (ou un plan) à demander....
    Sans parler du fait que t'es plus ou moins obliger de payer par CB.
  • # .

    Posté par  . En réponse à la dépêche IPv6 à la racine des DNS. Évalué à 2.

    Actuellement, seules les adresses IPv4 sont présentes dans la zone racine et ce à cause d'une limitation historique de la taille des requêtes DNS (en UDP).
    Et ils ont resolu le pb comment ?
  • [^] # Re: ...

    Posté par  . En réponse au journal deezer c'est le mal. Évalué à 2.

    Sauf que la on passe quand même par la carte son, ce qui peut faire perdre de la qualité.

    L'idée est de rajouter une couche (plugin) entre l'appli et de driver de la carte son, qui dump je flux audio. Ceci est faisable sous alsa avec des plugins : http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_external_p(...)
  • [^] # Re: ...

    Posté par  . En réponse au journal deezer c'est le mal. Évalué à 2.

    il envoi surtout une requête avec une clé facile à casser, il charge ensuite le fichier mp3, et envoi à nouveau la même requête. C'est une sorte de simple verrou.
    Mais avec le client flash officiel c'est qui qui gère ça ?
    Le player en flash charger de loader le flux mp3.

    Donc downloadhelper, essaye de telecharger un peu à l'arrache les fichiers streamés.

    Dans ce cas là, une solution définitive serait de hacker un client flash libre pour qu'il dump le stream au lieu de le jouer.
    On pourrait aussi imaginer pour le son, de jouer avec les plugins alsa, pour dumper ce qui est lu sur la carte audio.
  • # ...

    Posté par  . En réponse au journal deezer c'est le mal. Évalué à 2.

    En dehors de la partie technique (je me demande comment ils font pour identifier les requêtes illégitimes)
    Je sais pas ce que fait downloadhelper, mais je suppose qu'il télécharge le fichier flash via http ?

    Sûrement qu'au niveau des entête http, il n'envoie pas la même chose que le client flash.
  • # ...

    Posté par  . En réponse au journal Bye bye les tags mifare. Évalué à 2.

    Pour casser une clé mifare avec une attaque par la force brute, il faudrait:
    - une semaine sur un FPGA à 100$
    - une journée sur un FPGA à 700$

    Et sur un pc classique ?


    La plupart des cartes déployées au niveau institutionnel
    (Vitale, Carte Bleue, ...) utilisent de la vraie sécurité.

    Qu'en est il des pb de secu de la CB qui avait été présent à une époque (affaire Humpich) ?
    Ils ont modifié leur algo ?
  • [^] # Re: Attention !

    Posté par  . En réponse au journal Ebook Reader.. Évalué à 3.

    Les fichiers numériques étant immatériel, tu les dupliques très facilement. Et puis y a des livres que tu lis qu'une seule fois.

    Pour en revenir au problème de place, les bibliothèques se débarrassent des vieux livres car il n'ont plus de place pour les stocker. S'ils étaient sous forme numérique, vu que pour un même volume on peut mettre de plus en plus d'info, ils ne seraient pas obliger de les jetter et même 20/30 ans après on pourrait trouver les bouquins qui existait à l'époque.

    Après chaque support a son utilisation.
  • [^] # Re: Attention !

    Posté par  . En réponse au journal Ebook Reader.. Évalué à 1.

    Oui mais le papier ça brule, c'est encombrant, ça se fait bouffer par des rongeurs, ça moisi, ...

    Je pense qu'il faut mieux opter pour la gravure sur pierre : c'est quelque chose de durable, l'histoire nous l'a prouvé.

    PS : quel est la probabilité que dans 1 siècle quelqu'un retrouve ton livre ? Quel est celle d'une oeuvre numérique qui à été diffusé sur plusieurs réseaux électroniques.
  • [^] # Re: ok pour le contenant, mais le contenu ?

    Posté par  . En réponse au journal Ebook Reader.. Évalué à 2.

    Sur http://www.ebooksgratuits.com/ il y en a pas mal de français.
  • # ...

    Posté par  . En réponse au journal Soekris sous linux. Évalué à 2.

    Les cartes soekris peuvent booter par le réseau, mais je préfère encore utiliser la carte flash.
    Pourquoi faire simple quand on peut se taper des heures de galères.
  • [^] # Re: Energie

    Posté par  . En réponse au journal De la qualité des lecteurs de DVD Vidéo économiques. Évalué à 2.

    Une simple directive obligeant tous les manufacturiers à concevoir leurs appareils électriques de telle sorte que leur consommation à l'arrêt (via télécommande, où en stand-by) soit la plus faible possible.

    Plus faible possible par rapport à quoi ?

    Le pb, c'est surement que leur proc principal à bas cout ne gère pas les modes basses consommations.


    Le mieux serait de faire comme sur les frigos : afficher une échelle sur laquel on mettrait la conso du produit à l'utilisation/en veille.

    PS : Chose courante: il manque sur la carte une vingtaine de composants (des options ?).
    Ben c'est plus facile sur un circuit éléctronique de prévoir plus ( composant optionnel, composant de debug, ...), que d'être comme un con et devoir tout refaire s'il y a un truc qui marche pas comme prévu.
  • [^] # Re: soixante-quatre bites powaaaa !

    Posté par  . En réponse au journal x86_64. Évalué à 2.

    Juste une question aux développeur ici présent. Quel genre d'optimisation logiciel il est possible de faire pour tirer partie du 64bits ? Parce que personnellement, je développe toujours de la même façon sur cette plateforme.
    Aucune : les perfs sur x86_64 par rapport à i386 sont surtout du aux différences d'architectures (plus de registre en 64bits qu'en 32 bits, ...).

    Sur les autres bi-architectures 32/64 bits (sparc, ppc) les perfs sont meilleures avec des appli 32 bits qu'en 64 bits.
    Pourquoi ? Parce que dans ce cas l'archi est quasiment la même, seul la taille du bus change. Et comme la plupart des appli n'utilisent pas de données 64 bits le 32 bits leur suffit (et elles n'ont pas à ce trimballer du code plus gros, des datas plus grosses (pointeurs 2 fois plus gros, ...), ...).

    Si on osait caser la compatibilité i386, je pense que l'on pourrait aussi avoir un mode 32 bits plus rapide que le 64 bits sur x86_64.