Frédéric COIFFIER a écrit 703 commentaires

Oui, je doute qu'NVidia libère un jour les pilote du Tegra 2.
C'est déjà difficile pour la gamme grand public et c'est d'autant plus difficile pour le monde de l'embarqué (à l'exception de Broadcom qui libère ses pilotes "qui donnent le cancer des yeux" aux développeurs Linux).

Et Gambas, c'est le Visual Basic du Linuxien !

Enfin, je pensais pas que l'on pouvait superviser un parc avec un outil écrit en Visual Basic...

A ce propos, est-ce que Tulip peut-être comparé au dot de Graphviz ? Est-il possible d'importer dans Tulip des scripts Graphviz ?

Je pense aussi que le portage vers KDE4 a peut-être refroidi beaucoup de développeurs : devoir passer du temps pour retrouver les mêmes fonctionnalités que 3 ans auparavant, ce n'est pas très motivant. De plus, qu'il a fallu repasser toute la phase de maturation qui est assez ingrate.

Pour ce qui concerne KOffice, je doute que ce projet attire plus de monde que Amarok ou K3b... D'ailleurs, KOffice n'a toujours pas de version "utilisable" pour KDE 4 : "Version 2.2 has received many enhancements to the layout engine, the libraries and the filters. There are still areas in the user interface that we want to work on before stating that KOffice is fit for the general public."

Mais je pense que le plus gros du travail pour KDE4 a été effectué : les développeurs vont de nouveau pouvoir apporter de nouvelles fonctionnalités n'existant pas sur KDE3 en profitant des bénéfices de l'architecture de KDE4.

Moi qui me plaignais déjà de la lenteur de Trac...

Il y a qu'un script de ~50 lignes, développé en 1 semaine, il y a 1 an et c'est basé essentiellement sur pyPdf qui n'a pas eu de release depuis septembre 2008. Je doute que ça bouge encore...

Tu aurais un tutoriel détaillé, simple, expliquant comment mettre ça en place pour un utilisateur de base ?

Suite à un vieux rapport de bug, j'ai été surpris d'apprendre que Krita n'avait plus pour but de remplacer Gimp/Photoshop.

Il semble en effet que Krita a pour but de devenir un logiciel de dessin (tel que MyPaint pour ceux qui connaissent) :
"Krita is a KDE program for sketching and painting, offering an end-to-end solution for creating digital painting files from scratch by masters."
https://bugs.kde.org/show_bug.cgi?id=124033#c4

Entièrement d'accord avec ta remarque concernant l'appréciation ext4 vs ext3 de Phoronix.

Sinon, une différence importante pour Meego est qu'elle utilise Btrfs (qui est toujours considéré comme expérimental même si Linus l'utilise sur son PC perso).

Concernant ce plugin, j'ai vu sur le forum de Piwigo que certaines personnes rencontraient des problèmes avec lui.

Donc, si vous constatez un bug, n'hésitez pas à faire à retour sur le Bugzilla KDE pour kipi-plugins ( http://bugs.kde.org/ ) ou si l'anglais vous effraie, sur le forum Piwigo.
J'avais donné des instructions pour obtenir une trace utilisable ici :
http://fr.piwigo.org/forum/viewtopic.php?pid=141194#p141194

Il manque encore beaucoup, beaucoup de choses (support de l'Ipod, de musicbrainz, etc.)

Mais je crois qu'il manque également ces choses dans Amarok 2 ! (Si quelqu'un sait comment on peu tagger avec MusicBrainz dans Amarok 2, je suis preneur)

Je confirme que cela fonctionne très bien malgré l'alerte (ce n'est qu'un avertissement contrairement au signe "stop" lorsqu'il y a un problème Java).

Il faut tout de même noter un temps de boot 3 fois plus rapide d'après Phoronix (passant d'environ 60s à moins de 20s).

Personnellement (et je ne pense pas être le seul), j'utilise très fréquemment Calc comme grapheur (comme GNUplot ou MatPlotlib mais en plus interactif pour la mise en forme). Ça permet aussi de rapidement faire des calculs sur des valeurs mesurées.
Et puis, un copier/coller et on a la courbe dans un document texte.
Ces valeurs mesurées proviennent bien souvent de fichiers .csv générés par divers outils, scripts, oscilloscope numérique... et ces fichiers dépassent très facilement les 65000 lignes.

Alors, si vous avez quelque chose de simple à me proposer pour avoir une courbe en ~30 secondes à partir d'un fichier texte ou .csv, je suis preneur.

Moi, ce que je ne supporte pas dans les équipement sans fil, ce sont les piles (ou batteries) qui sont très polluantes (métaux lourds...) et coûteuses. Même si leur durée de vie sont assez longues, elle doivent malgré tout être changées plusieurs fois durant la vie du clavier. Et quand ça ne marche plus très bien, on ne sait jamais d'où vient le problème.
Et tout ça pour gagner le confort de retirer 2 malheureux fils ?

Arf ! Zut... Effectivement, je n'arrive plus qu'à 149 Mo (ce qui fait tout de même 102 Mo de plus que Gnuplot)

Sous Debian (sur un serveur en fait) :

# apt-get install python-matplotlib
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Les paquets supplémentaires suivants seront installés :
blt dvipdfmx dvipng fontconfig ghostscript gs-common gsfonts hicolor-icon-theme lacheck latex-beamer latex-xcolor libatk1.0-0 libatk1.0-data libcairo2 libcups2 libcupsimage2
libdatrie0 libdirectfb-1.0-0 libdrm2 libffi5 libfontenc1 libgl1-mesa-glx libglade2-0 libglib2.0-0 libglib2.0-data libgs8 libgtk2.0-0 libgtk2.0-bin libgtk2.0-common libice6
libkpathsea4 libpango1.0-0 libpango1.0-common libpaper-utils libpaper1 libpixman-1-0 libpoppler3 libsm6 libsysfs2 libthai-data libthai0 libtiff4 libts-0.0-0 libxaw7
libxcb-render-util0 libxcb-render0 libxcomposite1 libxcursor1 libxdamage1 libxfixes3 libxfont1 libxft2 libxi6 libxinerama1 libxmu6 libxrandr2 libxrender1 libxt6 libxtst6 libxv1
libxxf86dga1 libxxf86vm1 lmodern pgf prosper ps2eps psfontmgr python-antlr python-cairo python-configobj python-dateutil python-enthought-traits python-excelerator python-gd
python-glade2 python-gobject python-gtk2 python-matplotlib-data python-numeric python-pyparsing python-tk tcl8.4 tetex-bin tex-common texlive texlive-base texlive-base-bin
texlive-base-bin-doc texlive-common texlive-doc-base texlive-extra-utils texlive-fonts-recommended texlive-fonts-recommended-doc texlive-generic-recommended texlive-latex-base
texlive-latex-base-doc texlive-latex-recommended texlive-latex-recommended-doc texlive-pstricks texlive-pstricks-doc tipa tk8.4 x-ttcidfont-conf x11-utils xbitmaps
xfonts-encodings xfonts-utils xterm
Paquets suggérés :
blt-demo ghostscript-x hpijs auctex cups-common librsvg2-common ttf-kochi-gothic ttf-kochi-mincho ttf-thryomanes ttf-baekmuk ttf-arphic-gbsn00lp ttf-arphic-bsmi00lp
ttf-arphic-gkai00mp ttf-arphic-bkai00mp pdf-viewer postscript-viewer python-enthought-traits-ui python-gtk2-doc python-gobject-dbg ipython python-matplotlib-doc
texlive-latex-extra python-numeric-tutorial python-numeric-ext python-numeric-dbg python-tk-dbg tix tclreadline debhelper texlive-doc-en perl-tk dvi2tty dvidvi mesa-utils
xfonts-cyrillic
Les NOUVEAUX paquets suivants seront installés :
blt dvipdfmx dvipng fontconfig ghostscript gs-common gsfonts hicolor-icon-theme lacheck latex-beamer latex-xcolor libatk1.0-0 libatk1.0-data libcairo2 libcups2 libcupsimage2
libdatrie0 libdirectfb-1.0-0 libdrm2 libffi5 libfontenc1 libgl1-mesa-glx libglade2-0 libglib2.0-0 libglib2.0-data libgs8 libgtk2.0-0 libgtk2.0-bin libgtk2.0-common libice6
libkpathsea4 libpango1.0-0 libpango1.0-common libpaper-utils libpaper1 libpixman-1-0 libpoppler3 libsm6 libsysfs2 libthai-data libthai0 libtiff4 libts-0.0-0 libxaw7
libxcb-render-util0 libxcb-render0 libxcomposite1 libxcursor1 libxdamage1 libxfixes3 libxfont1 libxft2 libxi6 libxinerama1 libxmu6 libxrandr2 libxrender1 libxt6 libxtst6 libxv1
libxxf86dga1 libxxf86vm1 lmodern pgf prosper ps2eps psfontmgr python-antlr python-cairo python-configobj python-dateutil python-enthought-traits python-excelerator python-gd
python-glade2 python-gobject python-gtk2 python-matplotlib python-matplotlib-data python-numeric python-pyparsing python-tk tcl8.4 tetex-bin tex-common texlive texlive-base
texlive-base-bin texlive-base-bin-doc texlive-common texlive-doc-base texlive-extra-utils texlive-fonts-recommended texlive-fonts-recommended-doc texlive-generic-recommended
texlive-latex-base texlive-latex-base-doc texlive-latex-recommended texlive-latex-recommended-doc texlive-pstricks texlive-pstricks-doc tipa tk8.4 x-ttcidfont-conf x11-utils
xbitmaps xfonts-encodings xfonts-utils xterm
0 mis à jour, 109 nouvellement installés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de prendre 163Mo dans les archives.
Après cette opération, 358Mo d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer [O/n] ?


Cela autorise surtout les tiers à développer de véritables drivers en userland sans avoir à se soucier de la GPL.

Pour moi, Google a réellement fait un fork sans le dire et on vient juste de le découvrir.
Je ne vois pas l'intérêt qu'aurait Google à s'aligner sur le kernel. La plupart des drivers pour les téléphones Google utilisent déjà l'API développée par Google. Dans toutes les évolutions kernel, je ne vois pas quel serait l'intérêt pour Google: un nouveau système de fichiers 64-bits réparti, la gestion de plus de 1024 cores, le support de bus de données exotiques, des cartes réseaux 10 Gigabits, un nouveau scheduler qui pourrait entraîner des différences de comportement du player H.264 (cf un bug récent en compression) ?
Bref, à part des modifications renforçant la sécurité ou les performances, la grande majorité des évolutions du kernel est inutile pour Google. Et plutôt que de mettre des développeurs à travailler sur l'alignement kernel Google vs Linux, ils peuvent justement travailler sur les aspects sécurité/performance de leur version sans que cela gêne tous les tiers qui travaillent avec la plateforme Android.

Je pense que le kernel Linux a fait gagner énormément de temps à Google en fournissant un OS fiable, performant et open-source.
Désormais, ils sont capable de faire vivre leur version seul (et ils y ont finalement plus d'intérêt que nous).

Pour en avoir le coeur net, j'ai fait un checkout du dépôt SVN du projet et voici ce que l'on trouve à l'intérieur:

./libs/darwin/libCDraw.a
./libs/x86/libCDraw.a
./libs/x86_64/libCDraw.a
./libs/ppc/libCDraw.a


CDraw est le fameux moteur 2D propriétaire contenu dans XaraLX.

Maintenant, je veux bien connaître la méthode magique pour recompiler ces librairies...

Pour le rachat, je doute que ce soit possible du fait que la société Xara se porte (très ?) bien grâce à ces produits sous Windows et que c'est justement l'implémentation de ce moteur 2D qui fait la force de leurs produits.
Je pense qu'une bonne partie de l'implémentation doit être commune au logiciel Windows et Linux (ce qui expliquerait pourquoi ils ne l'ont pas ouvert) et qu'ils auraient trop peur que la concurrence "s'inspire" de ce code (ils étaient assez fiers de leur benchmark face à d'autres produits X).

Autant essayer de racheter le code source d'Adobe Illustrator...

Pourquoi faire un livre sur un logiciel qui n'est ni vraiment libre, ni maintenu ?

En effet, tout le code de XaraLX n'a jamais été libéré: le code du moteur vectoriel 2D qui fait la forme de Xara n'a jamais été ouvert. Il y a bien eu quelques tentatives de portage vers Cairo qui ont été abandonnées vu que Xara a complètement lâché le développement de XaraLX depuis plusieurs années (version la plus récente datant de Novembre 2007) !

Même si XaraLX fonctionnait il y a encore quelques temps (peut-être même encore aujourd'hui), rien ne dit qu'il continuera de fonctionner avec les évolutions des systèmes GNU/Linux ! Dans ce cas, adieu à tous nos fichiers (vu que l'export SVG n'a jamais été implémenté !).

Bref, j'ai peut-être perdu en facilité d'utilisation, en souplesse et en possibilités mais je suis passé à Inkscape (qui lui a vu son développement accéléré au cours des dernières années) !

Je confirme pour le thème graphique.

Étant la plupart du temps connecté à distance (avec NXClient http://nomachine.com/ ), l'utilisation du mode raster est inenvisageable (pour les raisons décrites dans le journal).

La première fois que je suis passé sous KDE4, j'ai ressenti une très grosse lenteur par rapport à KDE 3.5 en connexion à distance.
Puis, je me suis aperçu qu'en choisissant le style "Cleanlooks" à la place "d'Oxygen", je retrouvais quasiment la vitesse de KDE3 (mais aussi le look).

Pour compléter le journal, j'ajoute que Qt 4.6 a pas mal amélioré les performances du Qt (à priori, parce que Nokia a fait un gros effort d'optimisation pour l'embarqué).

Donc, si vous ne souhaitez rien recompiler, patientez pour KDE 4.4 (qui lui améliore la vitesse de démarrage) qui arrivera avec Qt 4.6 dans les distributions et changez le style pour "Cleanlooks".

A ce propos, sous Fedora, il faut installer wireshark-gnome sinon, l'interface graphique n'est pas installée:
$ yum install wireshark-gnome

Si j'ai bien compris, cette version de Lightning fonctionne juste pour Thunderbird 2.

Pour Thunderbird 3 qui vient de sortir, il existe une version bêta de Lightning 1.0 :
http://www.mozilla.org/projects/calendar/lightning/

Pour rappel, Lightning est le plugin de gestion d'agenda indispensable à Thunderbird pour se rapprocher des fonctionnalités de MS Outlook.

Je confirme que Nepomuk a été jusqu'à présent inutilisable : dans les premières version de KDE 4, j'avais l'impression qu'il consommait énormément de ressources (CPU, accès disque et espace disque pour le stockage) et dans les dernières, il faisait planter d'autres applications qui l'utilisaient.

Par contre, plutôt que de le killer, il faut mieux le désactiver dans "Configuration du Système -> Avancé -> Recherche sur le Bureau".

Par rapport à l'article, j'ai l'impression de lire la même chose depuis des années (enfin, depuis l'annonce [en 2006] de la création du composant Akonadi avant la sortie de KDE4).