fredix a écrit 1945 commentaires

  • # Rails + AJAX

    Posté par  . En réponse au message Conseils pour le choix d'un language ?. Évalué à 3.

  • [^] # Re: attaquer

    Posté par  . En réponse au journal "'auteur de NVU tire à boulet rouge sur les auteurs de l'ammendement VU. Évalué à 10.

    Une redevance qui s'applique au nombre de CD vierge achetés j'appelle ça une taxe. Une redevance c'est payé une fois pour toute comme la télé.

    Sauf qu'une taxe va dans la poche de l'Etat, la redevance va dans celle de certains ayant droits.
    Ce qui fait que lorsque du grave tes photos personnelles ou un CD Linux tu donnes de l'argent à Universal.
  • [^] # Re: peercast

    Posté par  . En réponse au journal La Lamabox : lecteur/enregistreur de salon sous Linux à partir de réseaux P2P !!. Évalué à 3.

    Rien ne garanti que l'on ne puisse pas trouver de la contrefaçon sur Peercast également.
    Pour le reste je suis complètement d'accord avec toi.
  • [^] # Re: Extensions/themes et versions...

    Posté par  . En réponse au journal Firefox 1.5 out!. Évalué à 1.

    Je faisais de l'ironie.
  • [^] # Re: Extensions/themes et versions...

    Posté par  . En réponse au journal Firefox 1.5 out!. Évalué à 1.

    C'est comme l'ironie, il faut le préciser ...
  • [^] # Re: Borg résistant ?

    Posté par  . En réponse au journal Grand moment pour Gnome. Évalué à 2.

    All your base are belong to us.
  • [^] # Re: Pour que les choses soient claires

    Posté par  . En réponse au journal La liberté de vous l'enlever. Évalué à 6.

    Apparement certains estiment que le but de cette loi n'est pas d'interdire les logiciels libres mais "seulement" interdire les logiciels non équipés de mesures techniques comme tu l'as indiqué ici :
    http://eucd.info/index.php?2005/11/14/175-exclusif-amendement-vivendi-universal-sacem-bsa-interdisant-les-logiciels-non-equipes-de-mesures-techniques

    Il parait que la phrase "Pressions sur le gouvernement pour faire interdire le Logiciel Libre" fait gamin de 14 ans rebelle...

    Tout le monde a bien compris que cela sera une conséquence de cet amendement débile, autant que l'EUCD interdit la copie privé de fait en interdisant les détournements de mesure de protection.

    Alors effet de manche ou le but est-il vraiment d'interdire le LL ?

    Pour ma part je pense que quelque soit la réponse le danger est réel et qu'il y a lieu de se mobiliser tous.

    Bravo pour ton travail.
  • [^] # Re: petit calcul

    Posté par  . En réponse au journal 174 Mbits/s en download et 18Mbits/s en émission : le futur de FREE. Évalué à 10.

    Faudrait déjà que le serveur puisse uploader à cette vitesse :) .
  • [^] # Re: Présentations Libres

    Posté par  . En réponse à la dépêche Vidéos des JDLL 2005 et 2004 à Lyon. Évalué à 2.

    Je ne sais pas ce qui s'est passé mais j'ai bien la 2ème vidéo de l'après midi qui démarre à partir de Antoine Gallavardin - Le syndrome du Pingouin jusqu'aux lightning talks.
    Le OGM fait 747Mo, je peux faire un bittorrent ou l'uploader sur le serveur de l'Aldil...

    Pas d'inquiètude à avoir en tout cas on a tout.
  • [^] # Re: Le problème avec les bindings...

    Posté par  . En réponse au journal Langages pour desktop. Évalué à 2.

    Je peux en parler puisque je fais du RG2 (GtkRuby) et c'est plutôt vrai pour les binding sur autre chose que Linux.

    Mais quand on a fait du GTK+ en C et qu'on en fait en Ruby on se rend compte de l'énorme simplicité et donc rapidité de développement qu'apporte un langage script.
    Si le but est de faire du multiplateforme alors effectivement le binding complique les choses surtout si celui-ci est plus ou moins mal porté. Dans ce cas autant coder directement en GTK+ ou QT.

    Cependant, l'on parle de desktop ici où la portabilité n'est pas le but premier, même si des projets (stupides à mes yeux) de porter KDE ou GNOME sur Windows existent.
    En programmation desktop, l'intérêt d'utiliser un binding est énorme. Quel développeur linux utilisant pyQT ou RG2 voudrait faire du C ou du C++ pour son IHM ?
    Quant à faire des applications multiplateformes, à mon avis c'est vouloir sacrifier pas mal de possibilités du desktop sur l'autel de la portabilité ... et c'est une grosse erreur. Il suffit de voir l'énorme catalogue d'applis GTK+ multiplateforme exploitant mal GNOME au contraire des appli KDE, d'ailleurs on ne dit pratiquement pas appli QT puisqu'il n'en existe que très peu pour le bonheur de KDE...
  • [^] # Re: L'engouement pour les languages interprétés

    Posté par  . En réponse au journal Langages pour desktop. Évalué à 2.

    Il faut juste savoir écrire du C quand cà vaut le coup (décompression ogg/FLAC pour suivre mon exemple du lecteur de musique).

    Et encore c'est rarement nécessaire car bien souvent il existe déjà des modules python/ruby/perl la plupart en C pour ce genre de choses standards (pyogg, libvorbisfile-ruby, ...).
  • # avis

    Posté par  . En réponse au journal Langages pour desktop. Évalué à 8.

    Cet engouement pour les langages interprétés est-il :
    - Une critique du modèle monolithique de Gnome ou de KDE "tout en C" ou "tout en C++" ?


    Non, car il n'y aurait aucun intérêt à ce que GNOME et KDE soient codés en langage script, et la première raison est la réactivité du desktop.

    Je pense que c'est une grosse erreur de mettre face à face desktop et applications. Le desktop se doit d'être réactif donc codé avec des langages compilés bas niveaux, mais proposant un certain nombre de binding.
    L'intérêt des binding est de permettre aux développeurs de coder une application desktop très rapidement en utilisant un langage de plus haut niveau, comme les langages scripts.
    Ensuite tout dépend de l'application, et certaines sont codées en C ou C++. Mais pour la plupart un langage script suffit largement, avec au pire une extension C ou C++ ajoutée au langage script (swig aide bien pour cela) pour un fonctionnalité particulière.

    Certe, un desktop est composé d'applications, et l'on peut se dire que si celles-ci finissent par être toutes codées en script, cela reviendra à avoir un desktop lent.
    Cependant pour moi la base du desktop c'est tout d'abord les biblitohèques de base, GTK+, Glib, Gstreamer, QT, etc, et les lib GNOME et KDE. Ensuite tous les démons associés au desktop (gconf, session, etc...). Tout cela se doit de rester en C ou C++ pour des raisons de perf.
    Ensuite un Evolution codé en python ? Pourquoi pas, même s'ils utiliseront surement plus GTK# et mono.

    Donc non il n'y a pas de lutte entre les langages de niveaux différents, le C et le C++ trouveront leur place dans les bibliothèques, binding et les services desktop.

    Quant à définir un langage script dédié à un desktop je ne suis pas convaincu. Un développeur attaché à perl, python, ruby ... ne changera pas comme ça. Et je n'en vois pas l'intérêt tant qu'il existe un bon binding supportant toute l'API du desktop.

    Enfin, on peut espérer que le temps fera son affaire de la diversité des interpreteurs et fera emerger un standard "de fait".
    http://freedesktop.org

    Pour me répéter je ne vois pas l'intérêt d'avoir un standard au niveau langage, il faut laisser le choix aux développeurs, autant que l'on laisse le choix aux utilisateurs pour leur desktop. Il faut avoir un standard au niveau desktop et c'est le but de freedektop.
    Si les desktop finissent par utiliser les mêmes bibliothèques, comme Gstreamer par exemple, peu importe ensuite le langage utilisé.

    Au contraire je reste persuadé que si l'on veut attirer les développeurs VB, Windev, Delphi, etc, leur laisser le choix d'un langage haut niveau est important.
    Certe le prix à payer est la multicité des interpréteurs, mais ceux-ci se dirigent vers des VM. Et l'évolution du matériel compense pas mal.
  • [^] # Re: Ruby ?

    Posté par  . En réponse au journal Quel langage, pour cette utilisation ?. Évalué à 3.

    Encore un petit effort : Ruby : j'aimerais avoir des avis sur Ruby; On en entend parler avec Ruby on Rail pour les applis web, mais pour faire des "vraies" applis ?

    http://ruby-gnome2.sourceforge.jp/

    Ah oui c'est vrai que c'est interprété donc HS, mais finalement, je me demande si les languages compilés ne vont pas céder le pas aux languages interprétés...

    C'est certain dans le domaine des IHM graphiques sous forme interprété ou en bytecode.
    Mais ça m'étonnerait pour ce qui est des bibliothèques bas niveau, comme GTK+ ou QT.
  • [^] # Re: python

    Posté par  . En réponse au journal Quel langage, pour cette utilisation ?. Évalué à 10.

    Parce que Python a été pensé comme un langage objet ?

    Tu confonds avec Ruby
  • [^] # Re: Ruby ?

    Posté par  . En réponse au journal Quel langage, pour cette utilisation ?. Évalué à 4.

    Même si KDE et GNOME ne sont pas interprétés, c'est quoi l'intérêt de développer des applications KDE et GNOME en C ou C++ de nos jours ?

    Certe je verrais mal un Gimp en python mais la plupart des applications desktop pourraient être sans problème codé avec un langage script ... Il n'y en a finalement que peu qui ont besoin de la forte réactivité d'un langage compilé bas niveau.
  • [^] # Re: Pas possible

    Posté par  . En réponse au journal Téléphones portables et Linux. Évalué à 3.

    J'ai un K700i avec le bluetooth et quand tu as 400 photos, bin faut les transférer une par une .... Si c'est pas des boulets chez SonyEricsson.
  • [^] # Re: blaster

    Posté par  . En réponse au journal Windows 2000 avec Zone Alarme est un system attaquable.. Évalué à 3.

    Essaye avec IEs4linux :
    http://www.tatanka.com.br/ies4linux/
  • [^] # Re: et les éditeurs d'antivirus qui laggent

    Posté par  . En réponse à la dépêche Du code de VLC dans le rootkit de Sony. Évalué à 8.

    La trouille du DMCA ?
  • [^] # Re: serveur ?

    Posté par  . En réponse au message Question openwengo / skype. Évalué à 2.

    Le communication de skype passent par un réseau P2P, donc évidement pas de serveur, ormis l'annuaire sans doute.
    http://www.skype.com/products/explained.html
  • [^] # Re: plaxo

    Posté par  . En réponse au journal Synchronisation Bookmarks, Calendar et Address Book pour Firefox et Thunderbird. Évalué à 3.

    oui j'ai vu ensuite absync sur la news sunbird, c'est génial.
    Pour le bookmark perso je trouve plus intéressant d'utiliser delicious.
  • # plaxo

    Posté par  . En réponse au journal Synchronisation Bookmarks, Calendar et Address Book pour Firefox et Thunderbird. Évalué à 3.

    En non libre malheureusement mais gratuit il y a plaxo pour syncro le carnet d'adresse :
    http://www.plaxo.com/downloads/tbird

    Sinon webdav coté serveur marche très bien avec l'extension calendar, il suffit soit de s'installer un serveur, soit d'utiliser un service gratuit comme :
    http://www.icalx.com/

    A savoir que evolution n'est toujours pas foutu d'accéder à un compte webdav via login/pass ... Plutôt utile si l'on veut pas que n'importe qui accède en écriture à son calendrier ...

    Concernant le carnet, tbird peut accéder à un carnet d'adresse via ldap. Le problème c'est de trouver un fournisseur de service, or il semble que c'est plutot complexe à mettre en oeuvre (gestion des droits d'accès ...).
  • [^] # Re: c'est pareil

    Posté par  . En réponse au journal 30 SMS gratuits ... grace à un soft GPL. Évalué à 2.

    http://www.wengo.fr/assistance/forum/viewtopic.php?t=12713&a(...)

    D'après sa réponse à la question précédente ca va venir.
    wait & see ...
  • [^] # c'est pareil

    Posté par  . En réponse au journal 30 SMS gratuits ... grace à un soft GPL. Évalué à 2.

    http://www.wengo.fr/index.php?yawl[S]=wengo.public.homePage&yawl[K]=wengo.public.quickwin
  • [^] # Re: Ce que j'aime dans Google...

    Posté par  . En réponse au journal Google, the internet trust must go on.... Évalué à 7.

    C'est aussi parce qu'ils ont compris Internet et le respecte (innovation, sobriété, utilisation poussé des standards et des logiciels libres, ...) , et celui-ci le leur rend bien ...
    Pas comme une certaine entreprise aux comportements douteux, employant des méthodes pitoyables pour imposer et conserver son monopole.
    Le "monopole" de Google n'est dû qu'à son succès, chapeau.
  • # PHP

    Posté par  . En réponse au journal Virus!. Évalué à 9.

    C'est un virus exploitant une faille de :
    http://phpxmlrpc.sourceforge.net/

    Je veux bien que PHP soit en majorité utilisé sur des serveurs Linux, mais de la à généraliser à "virus anti-linux" ya des limites ...
    Il exploite pas une faille du kernel !