GeneralZod a écrit 2316 commentaires

  • [^] # Re: Encore un troll qui meurt !

    Posté par  . En réponse à la dépêche Launchpad libéré !. Évalué à 10.

    Africain n'est pas une nationalité.
    Patrick Baudry est né et a vécu au Cameroun (à l'époque colonie Française) donc on peut légitimement considérer que c'est le premier natif africain a être allé dans l'espace.
    En revanche, Mark Shuttleworth est le premier citoyen d'un état africain et premier sud-africain dans l'espace, ce qui en soi est déjà pas si mal.
    On peut également noter que Mark S. vivait régulièrement en Grande Bretagne depuis quelques années et possédait déjà la citoyenneté britannique.
  • [^] # Re: Fix

    Posté par  . En réponse à la dépêche Launchpad libéré !. Évalué à 6.

    > Blueprint, dans le contexte de Launchpad, désigne un item de suivi d'une fonctionnalité (de l'étape wishlist jusqu'à l'implémentation). Rien à voir avec le tirage d'épreuve ;)
    Exact, mais je n'ai pas trouvé de traduction plus appropriée. :(

    > Par ailleurs, le fait que Launchpad n'était pas sous licence libre ne signifiait pas pour autant qu'il était sous une licence propriétaire (...)
    Un peu comme les web services de Google, mais bizarrement, je n'ai jamais rencontré personne contestant leur caractère privateur. :)
    Dans le cas des applications web, le débat effectivement ne se place dans le cadre classique libre/privateur (d'où l'arrivée des licence Affero), mais dans le cadre de confier ses données à une plateforme obscure. Ça implique le code, mais également les conditions d'utilisations etc ...
    La libération du code donne une garantie supplémentaire aux utilisateurs, si demain le service de Canonical flanche pour une raison où une autre, on pourra ouvrir très rapidement une autre instance de Launchpad voire créer des scripts automatisant la migration vers d'autres services/outils.
    On ne va pas cacher notre joie, c'est probablement pour Canonical un grand pas en avant avec une certaine appréhension, Launchpad étant un de leur atout maitre. On ne peut que les encourager à continuer dans ce sens.
  • # "Et cie" t'emmerde !

    Posté par  . En réponse au journal Launchpad est libre. Évalué à 10.

    Je viens d'envoyer une dépêche à ce sujet.

    C'est une grande victoire pour les libristes, et ça n'aurait pas été possible sans les "râleurs", en tout cas, c'est pas grâce à tout les fanboys qui prétendaient que "non, Launchpad n'est pas vraiment propriétaire, il est pas distribué gnagna", ou bien "osef, Launchpad c'est trop bien".
    Tu devrais plutôt remercier les "iznotgood et cie" pour avoir poussé Mark Shuttleworth à se sortir les doigts du cul.

    Vu le nombre de projets libres hébergés par Launchpad, c'est avec un grand soulagement qu'on apprend sa libération. Hein, c'est pas parce qu'on tape sur Launchpad/Canonical/Ubuntu que c'est gratuit, c'est justifié derrière.
  • [^] # Re: définition de l'open-source

    Posté par  . En réponse au journal Bill Gates offre au monde une leçon de physique. Évalué à 10.

    > Quand aux sources de l'OS, ayant vu le cote LL et le cote MS, j'ai choisi mon camp...
    Tu as finalement démissionné de Microsoft ?
  • [^] # Re: Gtk+ et l'accessibilité

    Posté par  . En réponse au journal Gtk+ client side windows merge. Évalué à 8.

    En même temps, y a 10 fois plus de développeurs payés pour bosser à temps plein sur Qt que sur Gtk+.
  • [^] # Re: python2

    Posté par  . En réponse à la dépêche Python arrive en version 3.1. Évalué à 5.

    Des dizaines d'années, faut pas exagérer mais Python ne va effectivement pas disparaitre tout de suite. :o)

    > le seul truc chiant finalement, c'est de trjs taper "print blah" au lieu de "print (blah)" par habitude... ;)

    Pour te débarrasser de cette habitude, rajoute la ligne suivante dans tes scripts et ton PYTHONSTARTUP pour l'interpréteur interactif.

    from __future__ import print_function


    Désormais l'interpréteur râlera quand tu n'utiliseras pas la notation fonctionnelle. C'est radical.
  • [^] # Re: Rapidité du C ... et ramasse-miettes ?

    Posté par  . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. Évalué à 2.

    Pour clarifier un peu les choses (Pour ceux qui n'ont pas suivi), unladen-swallow c'est l'implémentation Python de Google basé sur LLVM.
    Effectivement, scarcity devrait être utilisé comme GC pour unladen-swallow mais étant écrit en C++, il est improbable qu'il soit inclut dans CPython.

    PS: d'après Google, unladen-swallow est plus un fork "temporaire" de CPython qu'une implémentation distincte, en outre, unladen-swallow vise la compatibilité source avec CPython et ses extensions.
    http://code.google.com/p/unladen-swallow/wiki/ProjectPlan
  • [^] # Re: Fedora

    Posté par  . En réponse au message Changer de distribution mais laquelle ?. Évalué à 2.

    Avant de t'exciter, tu noteras qu'à aucun moment, je n'ai fait de comparaison avec Mandriva ou quelques autres distributions. Et non, ce n'était pas spécialement mon intention.

    > > Google m'a donné en quelques secondes une preuve que tu ment
    En 5 ans, j'ai jamais rencontré de soucis de mise en veille sous Fedora, et j'en ai vu défiler des portables.
    À aucun moment, tu ne t'es dit que j'étais de bonne foi ?

    > Tu sais, le suspend to ram et to disk marchent au moins depuis que je les utilises tous les jours
    Si j'étais de mauvaise foi, je pourrais dire que tu mens toi aussi. https://qa.mandriva.com/show_bug.cgi?id=50337 (thanks Google)

    Je te laisse le choix: on est tout deux des menteurs, soit on peut s'être trompé de bonne foi.
  • [^] # Re: Tomboy ?

    Posté par  . En réponse au journal Mono: C’est un grave danger et seuls les imbéciles l’ignoreront, jusqu’au jour où il sera trop tard.. Évalué à 2.

    F-spot ne fait pas partie de GNOME.
  • # Fedora

    Posté par  . En réponse au message Changer de distribution mais laquelle ?. Évalué à 2.

    * rapide à charger avec un joli boot graphique (Plymouth). Très rapide pour un système desktop.
    * mise en veille qui fonctionne.
    * gestion des paquets RPM, efficace avec yum et packageKit.
    * installation sympa et graphique. Via le livecd, c'est ultra rapide, à peine le temps d'aller aux chiottes que c'est finie.
    * une collection de paquets énorme et en constante augmentation.
    * communauté sympa et une bonne doc.
  • [^] # Re: DotGNU Portable.Net

    Posté par  . En réponse au journal Mono: C’est un grave danger et seuls les imbéciles l’ignoreront, jusqu’au jour où il sera trop tard.. Évalué à 3.

    > Linux, le noyau, n'a certes jamais fait partie de GNU.
    Je vois pas le rapport ...
    À la base le projet GNU, c'est réimplémenter Unix un OS propriétaire comme Mono est une implémentation libre de .Net.
  • # DotGNU Portable.Net

    Posté par  . En réponse au journal Mono: C’est un grave danger et seuls les imbéciles l’ignoreront, jusqu’au jour où il sera trop tard.. Évalué à 10.

    > "Si nous perdons un jour le droit d’utiliser C#, nous perdrons également ces applications."
    Foutaises, le langage lui-même est standardisé, donc rien à craindre de ce côté-là.
    En revanche, la partie non-standardisée du framework (Winforms, ASP.Net etc ...) pourrait du jour au lendemain disparaitre.
    Mais c'est oublier que Mono offre son propre framework (Gtk#, Cocoa#, MonoTorrent, etc ...) , dans le pire des cas, on s'en passera sans problème.
    De plus, comme Linux et bon nombre de projets libres Mono est protégé par l'Open Invention Network qui constitue un énorme portefeuille de brevet (IBM, Novell et ses brevets sur les web services, RedHat, etc ...) suffisant pour dissuader quiconque d'attaquer un des membres de l'OIN y compris MS.
    D'ailleurs, l'accord Novell-MS prouve bien l'impuissance de MS, d'un côté ils peuvent dire "regardez, DotNet c'est multiplateforme", de l'autre "Utiliser Mono comporte des risques légaux, faut une licence mais sinon utiliser .Net sur Windows". C'est du FUD pur et simple.

    RedHat n'a permis l'inclusion de Mono qu'à partir du moment où ses avocats ont jugés que le risque légal était faible. Légalement, Mono n'a plus à craindre que le noyaux linux ou d'autres projets libres.


    > les distributions Linux ne devraient donc pas mettre en place Mono ou Portable.NET
    Portable.Net l'implémentation de .Net par la FSF ?
    À croire que ce réveil tardif de RMS est dû à la jalousie. C'est vrai Mono avance très bien contrairement à Portable.Net, il a un énorme succès notamment sur console contrairement à Portable.Net. Difficile à croire que les deux implémentations libres se couraient encore derrière il y a quelques années.
    Certes Mono traine un peu derrière .Net, mais Mono tourne sur plus de plateformes, Mono innove. Finalement le singe s'est trouvé une niche très confortable.
    Mono est l'implémentation d'une technologie privatrice comme l'était GNU. Comme GNU, Mono a sa vie propre vis à vis de son "modèle" privateur.
  • [^] # Re: Rapidité du C ... et ramasse-miettes ?

    Posté par  . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. Évalué à 4.

    > Ahahaha la bonne blague. Ca garantie juste qu'il est utilisé, ni plus, ni moins.
    Si il est très utilisé, statistiquement plus de bogues sont corrigés, et vu que Mono/GCJ/Mozilla/LLVM sont pas des branquignols, ils ont faits des rapports de bogues et même fait le patch qui va avec.

    Quant au côté multiplateforme, prenons le cas de Mono. Mono compile sur de multiples plateformes matérielles x86, ppc (wii, ps3 y compris), sparc, alpha, arm (iPhone), et autant d'OS: linux, BSD, Solaris, HP-UX, OS X, merdows et partout, ils utilisent Boehm GC. Si ce n'est pas une belle preuve de portabilité, etc ...

    > tu prend boehm gc, tu t'amuse a créer n threads, chacun créant m objets.
    Boehm GC par défaut n'est pas thread-safe, tu ne nous apprends rien de nouveau.

    http://www.hpl.hp.com/personal/Hans_Boehm/gc/scale.html
  • [^] # Re: Rapidité du C ... et ramasse-miettes ?

    Posté par  . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. Évalué à 4.

    Ce n'est que mon avis mais c'est pas un peu tôt pour se lancer dans le développement d'un nouveau ramasse-miette ?
    Boehm GC est utilisé par bon nombre de projets (GCJ, Mono, Mozilla, LLVM etc ...) qui garantit que le code a été intensivement testé et déverminé et sur un nombre important de plateformes.
    Un nouveau ramasse-miette signifierait moins de temps pour faire avancer un langage encore très jeune, essuyer pas mal de platre. Un ramasse-miette à la fois portable, performant et bien déverminé, ça demande du temps. Plus encore, si il doit être plus complexe.
    Laissons le projet avancer à son rythme, si le Boehm GC pose problème à l'évolution du langage, ce sera toujours le moment de se poser la question.
  • [^] # Re: Crées ton propre Fedora spin

    Posté par  . En réponse au message Faire sa distrib avec nvidia. Évalué à 2.

    1. Oui, tu as la possibilité d'ajouter des scripts bash (ou autre langage de script) qui peuvent être exécuté avant et après installation.
    http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/(...)
    2. À priori si tu utilises les paquets fournis par rpmfusion, tu ne devrais pas avoir de problèmes. J'éviterais d'utiliser le tarball de nvidia qui se prête très mal à cet exercice et ne bénéficie pas des améliorations de RPMFusion.
    Le akmod permet également de recompiler le paquet en cas de mise à jour du noyau si celui-ci n'est pas encore disponible dans le dépôt rpmfusion. C'est intéressant à inclure dans un média d'installation.
    http://rpmfusion.org/Howto/nVidia
    http://rpmfusion.org/Package/xorg-x11-drv-nvidia#head-bf681e(...)
  • # Crées ton propre Fedora spin

    Posté par  . En réponse au message Faire sa distrib avec nvidia. Évalué à 3.

    Fedora se prête très bien pour la création de distributions personnalisés pour une variétés de médias (CD/DVD d'installation, CD/USB live -possibilité d'installation-, machine virtuelle etc ...).
    En gros, faut éditer un fichier kickstart qui te permettra de configurer la distribution (locale, selinux, services, ajout de dépôts etc ...) et les paquets à incorporer.
    Tu peux utiliser comme base un des fichiers kickstarts fournis par les paquets spins-kickstarts et rpmfusion-{free, nonfree}-remix-kickstarts. Tu peux éditer le fichier kickstart à l'aide de ton éditeur préféré ou bien utiliser la GUI system-config-kickstart.
    Ensuite, faut générer ton média, si c'est un CD/DVD d'installation, faut utiliser pungi, si c'est un média live, la commande livecd-creator.
    Là aussi, tu disposes d'une GUI avec Revisor.

    Ce sont les mêmes outils qui sont utilisé pour générer la distribution principales et ses dérivées. Rien de bien compliqué, si tu as besoin d'aide, passe sur le forum de Fedora-FR ou le chan #fedora-fr (freenode).


    Quelques documentations :
    * la doc de fedora-fr très complète
    http://doc.fedora-fr.org/wiki/Cr%C3%A9ation_de_Live_CD/DVD_e(...)
    * doc de fedoraproject
    http://fedoraproject.org/wiki/FedoraLiveCD/LiveCDHowTo
    * tutoriel d'utilisation de revisor
    http://www.techotopia.com/index.php/Create_Your_Own_Fedora_D(...)
  • [^] # Re: Rapidité du C ... et ramasse-miettes ?

    Posté par  . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. Évalué à 2.

    > Sur un test réalisé par curiosité, la création de 1'000'000+ petits objets dans une boucle est environ 2x plus rapide en ooc qu'en C++

    ça montre surtout que l'allocateur mémoire par défaut de ton implémentation de C++ est une bouse pour allouer des petits objets. C'est normal, l'allocateur par défaut doit répondre à diverses problèmatiques sans (trop) sacrifier au niveau des performances.
    Le ramasse-miette, la plupart du temps, alloue un pool mémoire au démarrage, il ne rend pas toujours la mémoire libéré par le programme, il peut utiliser différentes politiques, etc.
    Certes, ça abaisse le niveau d'entrée pour les développeurs : c'est plus simple, plus efficace et surtout plus sûr que si ils géraient manuellement la mémoire mais ça a un surcoût parfois non négligeable (ie: machine limitée en mémoire)


    Après, rien n'empêche le développeur C++ de programmer son propre allocateur mémoire (ce qui arrive très souvent en embarqué ou en programmation temps réel) pour améliorer les performances d'allocation mémoire. Mais pour le côté sûreté et simplicité des garbages collector, les dialectes C++ modernes offre des alternatives tout aussi bien sans surcoût: RAII, pointeurs intelligents avec ou sans comptage de référence, conteneurs etc ...
    On n'est pas obligé de choisir entre la gestion manuelle ou automatique de la mémoire, on peut s'orienter vers une gestion semi-automatique comme en C++ ou en Objective-C qui constitue un excellent compromis.


    Intrinsèquement, un ramasse miette n'est ni plus lent ni plus rapide qu'une gestion manuelle de la mémoire, ça dépends de la configuration (bcp d'allocations, petits/gros objets, ressources disponibles), ça dépends du développeur (niveau, envie de gérer la mémoire ou pas), du temps alloué au projet, du public visé etc ...
  • [^] # Re: Pas d'importance

    Posté par  . En réponse au message quelle base de données choisir ave Qt. Évalué à 1.

    Au niveau des requêtes, tu peux utiliser le sous ensemble SQL commun à SQLite ou MySQL sans problème. Quant au code C++/Qt, t'as juste la partie connexion qui change un peu.
    Rien de bien méchant, voilà ce que ça donne:


    QSqlDatabase db = QSqlDatabase::addDatabase( "QMYSQL" );
    db.setHostName( "zorglub" );
    db.setDatabaseName( "ma_base_mysql" );
    db.setUserName( "mon_utilisateur" );
    db.setPassword( "mon_password" );
    if( !db.open() )
    {
    qDebug() << "Erreur : "<< db.lastError();
    qFatal( "La connexion a échouée." );
    }



    QSqlDatabase db = QSqlDatabase::addDatabase( "QSQLITE" );
    db.setDatabaseName( "ma_base_sqlite.db" );
    if( !db.open() )
    {
    qDebug() << "Erreur : " << db.lastError();
    qFatal( "La connexion a échouée." );
    }
  • [^] # Re: Pas d'importance

    Posté par  . En réponse au message quelle base de données choisir ave Qt. Évalué à 1.

    À première vue, tes tables vont dépasser la dizaine de mégaoctets (voire la centaine pour celle des consultations) donc même avec une table = une base sqlite, ça va être juste.
    Dès que tu commences à titiller le gigaoctet, tu peux oublier sqlite.

    Dans ton cas, je réserverais SQLite pour la phase de développement et les fonctionnalités annexes (sauvegarde, configuration, base temporaire etc ...) et en production, j'utiliserais une base de données plus costaud comme MySQL ou Postgres.
  • [^] # Re: Pas d'importance

    Posté par  . En réponse au message quelle base de données choisir ave Qt. Évalué à 2.

    Avec la version libre de Qt, seuls les pilotes SQLite (2 et 3), MySQL, Postgres et ODBC sont présents. Pour les autres pilotes, il faut une licence obligatoirement Qt.

    > tu pourras migrer vers une autre base sans difficulté (juste changé de backend).
    Pas tout à fait, QtSql offre une abstraction par rapport aux APIs natives des diverses bases de données mais en aucun cas n'offre une abstraction vis à vis des dialectes SQL des bases.
    Soit on utilise le dénominateur commun de chacun des dialectes SQL des bases de données supportés, soit il faudra gérer les différences manuellement.

    Mais dans un premier temps, on peut se contenter effectivement d'une base SQLite qui est incluse par défaut dans Qt, mais pour un accès réseau ou concurrentiels et à partir d'un certain volume, mieux vaut passer à Postgres ou MySQL.
  • [^] # Re: Mingw ain't dead

    Posté par  . En réponse au journal Qt Creator 1.2 & Qt 4.5.2. Évalué à 2.

    Effectivement, les plateformes 64 bits sont le talon d'achille de Mingw et le peu de popularité de Windows 64 n'aide pas.
    Néanmoins, le projet mingw-w64 offre déjà une chaine de compilation minimale, reste à améliorer le port (notamment la partie WinAPI/DDK) et les paquets externes.
    D'après le mainteneur de Mingw dans Fedora, il y a encore pas mal de trucs à régler pour que Mingw64 soit utilisable en production, même si le minimum syndical est déjà présent.


    http://mingw-w64.sourceforge.net/
  • # Mingw ain't dead

    Posté par  . En réponse au journal Qt Creator 1.2 & Qt 4.5.2. Évalué à 10.

    L'équipe Mingw a sorti une version de sa chaine de compilation basé sur GCC 4.4.0 il y a 2 jours. Et il y a toujours eu des builds non-officiels de basé sur GCC 4.x et qui marchaient très bien.
    http://sourceforge.net/forum/forum.php?forum_id=969885
  • [^] # Re: Précisions

    Posté par  . En réponse au message mise a jour. Évalué à 1.

    Ubuntu, pardi !
    Que veut qu'il utilise d'autres ? [1] Pour la version, je dirais Jaunty.
    Pour solutionner ça, j'essaierais un apt-get dist-upgrade


    [1] Avant, on aurait dit il utilise Linux 7 mais les temps ont changés, et il ne connaît probablement pas l'existence d'autres distributions.
  • [^] # Re: Frédéric Lefebvre

    Posté par  . En réponse au journal Albanel is out. Évalué à 3.

    Le porte-parole d'un parti politique n'a pas a être élu par le peuple, néanmoins une tradition jacobine accorde une certaine légitimité aux hommes et femmes politiques qui ont affrontés le suffrage universel.
    C'est un rite de passage républicain, un Lefèbvre qui n'a jamais été élu (du moins directement) a moins de légitimité qu'un Lefèbvre élu, c'est comme ça. Tout ceux qui ont occupé une responsabilité politique sans avoir été élu se sont toujours fait descendre par les autres politiques, les médias etc ...

    Certes le porte-parole n'a pas à être élu, mais il est curieux que les dirigeants d'un parti "démocratique" ne le soient pas par les militants mais désigné par le président de la République (qui dans la Vème République est supposé être au-dessus des partis).
  • [^] # Re: Frédéric Lefebvre

    Posté par  . En réponse au journal Albanel is out. Évalué à 2.

    Malheureusement, il reste toujours porte-parole de l'UMP.