HoloAddict a écrit 177 commentaires

Et pour ceux qui ont fait attention à la comparaison avec Loco Roco, je préviens juste que je trouve ça assez différent. (personnellement Loco Roco m'a très vite saoulé...).

Juste pour dire que ce jeu, en plus d'être extrêmement original, est le plus fun et marrant que j'ai eu l'occasion de jouer depuis un bon moment ! Bien loin devant les éternels et ennuyants FPS ou autres classics.

On le finis relativement rapidement (le seul point noir), mais il en vaut franchement le coup ! N'hésitez vraiment pas !

J'avoue ne pas avoir payé la version Win (je pouvais pas savoir si ça allais marcher ou pas sous wine), mais je pense être prêt à payer 20euros pour la version Linux si la qualité est au rendez-vous !!

Bref, à tester absolument (et tant pis si c'est pas libre) ! Même un de mes amis a fond dans les derniers jeux aux graphismes époustouflant est tombé amoureux de ce jeu.

pour une liaison dynamique oui, il ne me semble pas que ça soit le cas pour une liaison statique.

De mémoire le démarrage à froid de la JVM, même pour un helloworld, est plus long que les résultats que tu obtiens avec Mono. Après effectivement j'ai pas refais le test depuis un bon moment (ptet même sur du Java5) et on à peut-être pas la même machine.

A retester dès que j'ai un peu de temps, mais j'ai pas l'impression que ça se soit beaucoup amélioré.

> Ce qu'il faut retenir, c'est que mon exemple t'as clairement montré que le temps de chargement du runtime est négligeable (j'ai refait le test après avoir redémarrer ma machine), et c'est bien le principal.

Ok, voila la réponse que j'attendais, il semblerait donc en effet que Mono soit plus efficace que Java sur ce point là, à savoir le temps de démarrage.

Tes arguments semblent convaincants, cependant je me souviens clairement avoir déjà lu que le premier démarrage de la JVM (a froid donc) est lent à cause du fait de devoir tout mettre en RAM (notamment en lisant un fichier de plus de 40Mo...). Le second lancement de la JVM n'ayant pas ce problème. Et que Sun bossait sur l'amélioration de ce lancement a froid de la JVM pour enlever quelques secondes.

Malheureusement je ne retrouve plus le lien.

Tout ça pour dire que, __dans le cas de Java__, le démarrage de la JVM en elle-même est conséquent (a cause de la grosse taille de la librairie standard). J'ai juste fais le même parallèle avec Mono (car il possède également une grosse librairie), sans vraiment pouvoir le prouver, n'ayant pas testé.

Après, je veux bien croire que le second lancement de l'appli est plus rapide (optimisations déjà faites), mais n'empêche que c'est également le cas pour la JVM elle-même, et je pense que c'est surtout ça qui a fait diminuer de moitié le lancement de mon prog.

Entre nous, si .net/mono arrive a faire en sorte que le lancement de la machine virtuelle et le chargement des libs ne se sentent pas sur le démarrage de l'appli, chapeau bas, je n'arrive pas à imaginer comment ils ont fait. J'espère cependant que c'est le cas, car je trouve personnellement Java un poil trop lourd (surtout Swing en fait).

Je n'ai jamais dis qu'il y avait la machine virtuelle qui tourne en tache de fond.

Par exemple avec un programme java (plus lent car pas un hello word hein...) :

> time java -jar wiihamster.jar

real 0m5.235s
user 0m0.524s
sys 0m0.084s

> time java -jar wiihamster.jar

real 0m2.042s
user 0m0.536s
sys 0m0.052s

Grande différence. La première fois je n'avais encore jamais lancé java sur cette machine. La deuxième fois si.
Et pourtant, pas de process 'java' en tache de fond.

N'as tu jamais démarré mono (pour une raison X ou Y) sur ta machine avant de faire ce test (et sans utiliser preload hein...) ? Si non, ce sont les résultats de mono a froid, et je m'excuse donc de ma suspicion : Mono est léger au démarrage.

Après, un "environnement d'exécution", pour moi ça veut tout et rien dire. Le vrai process qui se lancera sera "mono" (soit au final la machine virtuelle) qui se démerdera pour lire tous les fichiers et foutre tout ton "environnement d'éxécution" en RAM.

Ah si si, une machine virtuelle se démarre ! C'est un process comme les autres.

Je ne connais pas bien mono, mais par exemple pour java, le premier démarrage a froid de la machine virtuelle est non-négligeable (lecture DD, mis en place dans la ram). Sun veut d'ailleurs l'améliorer.

Après peut-être que Mono est mieux foutu de se côté là, mais franchement je pense que ton exemple à été pris "à chaud", avec un mono déjà démarré.

Après, j'ai la flemme d'installer mono juste pour un test hello word.

Bon, je vais être un peu hors sujet, car ce que je recherche avant tout dans un prog UML c'est la génération de code et le fait que le modèle soit toujours à jour (si je change le model ou le code l'autre se met à jour aussi).

Mais dans ce domaine, le seul qui m'a vraiment convaincu c'est eclipse + eUML2 (gratuit mais pas libre, et java only je crois).

Peut etre pourrait-il te convenir également aussi, je n'en sais trop rien...

Révélation! Je savais que Fedora et OpenSuse possédait un outils de génération de live cd auto, mais pas debian (et pourtant je l'utilise depuis un bon moment...). Aimant les live-usb (et utilisant Slax pour l'instant), j'aurais bien aimé avoir un ptit lenny dessus.

Je lance live-magic, tout ce passe bien. Je fait un dd if=binary.img of=/dev/sdb tout ce passe bien (BIEN). Ma clé usb est lisible avec tout plein de fichiers (BIEN).

Je boot dessus: "boot error" (PAS BIEN)

Snif... J'ai loupé quelque chose?

En fait, je ne peux pas vraiment répondre à tes questions, mais je peux juste te dire que Okular permet de ne pas écouter les DRM et d'annoter tout document PDF, quel qu'il soit.

En plus c'est libre et mieux foutu qu'acrobat (mais moins performant pour les gros fichiers PDF).

J'ai moi aussi du coder un systeme expert (avec moteur d'inférence en chainage arrière si mes souvenirs sont bon) en Common LISP.

Mais je ne peux pas vraiment dire que ce fut un plaisir...

> Le truc qu'il faut changer à chaque fois que tu change l'emplacement du binaire? Super pratique... Et surtout, pas du tout convivial!

Autant je suis d'accord sur plusieurs points avec toi, je trouve qu'il est plus facile de développer et distribuer un binaire sous windows, et par exemple je pense que les autotools sont une hérésie tellement c'est chiant et compliqué, autant je ne comprend pas cette phrase :

#! /bin/sh

LD_LIBRARY_PATH=`dirname $0`
export LD_LIBRARY_PATH
Prog=$LD_LIBRARY_PATH/mon_binaire
$Prog ${1+"$@"}


Clique sur ce script et il lancera ton binaire qui regardera a coté de lui pour les so, et ce à tous les coups, sur n'importe quelle configuration.

Après, je suis d'accord, j'aurais également préféré qu'il le fasse de lui-même.

De plus, une bon paquet deb se fait a partir des sources. Donc le mieux est sans doute d'attendre que le code soit libre, et donc qu'il dépasse la version PR.

D'ailleurs quelqu'un sait où on peut rapporter les bugs pour QtCreator ? J'aurais bien rapporté celui de l'autocomplétion avec fichier à l'appui.

Je pense qu'ils n'acceptent pas encore les bugs pour Qt Creator puisque ce nom n'apparaît pas dans le task tracker mais je suis pas sûr.

Ce que j'ai compris : durant les années 90, beaucoup de window-manager sont né et que c'est le même cas actuellement avec les IDE Qt.

Et il n'a pas tord : QDevelop, MonkeyStudio, Edyuk, HaiQ sont tous des IDE fait en C++/Qt pour Qt et je n'ai jamais vu un seul d'eux chercher à travailler avec les autres (et je sais que trois des leaders de ces IDEs sont français). Après, il y a peut-être de bonnes raisons à ça, mais ça reste un peu dommage.

Après on peut en plus rajouter les IDE pyQt comme eric4 ou eggy, mais ils n'ont pas exactement le même but.

Bref, je suis quand même content de voir arriver QtCreator. Il est vraiment léger et marche bien. Pour l'instant, je lui préfère encore KDevelop3 mais si Trolltech (maintenant Qt Software) rajoute des fonctionnalités à cet IDE je pense que je vais finir par switcher.

J'ai pour l'instant 3 reproches à faire à QtCreator :
- j'ai une classe template de pointeur intelligent, et il ne veut pas autocompléter cette sorte de pointeur, alors que ça passe très bien avec KDevelop par exemple.
- autoriser l'édition de fichier .pro à la main est très bien, mais j'aimerai quand même avoir un dialog d'édition de projet comme dans tous les autres IDE Qt. Je sais pas s'il ont envie de le faire.
- il semble vouloir un dossier Qt ordinaire pour trouver tous les outils. Sur la majorité des distros, ce dossier est éclaté dans /usr/bin, /usr/local, /usr/lib ... Donc il faut avoir déjà compilé soi-même un Qt pour pouvoir l'utiliser.

Moi aussi... que j'aime ou pas les couleurs, ou encore le sujet, c'est une chose, mais que j'ai du mal à lire sur l'écran plus de 10min en est une autre.

J'ai jamais eu une vue excellente, je ne le cache pas et ceci joue peut-être, mais franchement ça me détruit la rétine...

Il parait en effet que ça devient utilisable (pas testé les nouvelles versions). M'enfin sous KDE ça fait une éternité que j'utilise le SSH, FTP, SMB (voir la vue MP3 et OGG de mon CD audio) sans le moindre problème dans mon navigateur de fichier...

Gnome est juste à la traîne depuis des années la dessus et commence enfin à avoir un truc qui ressemble à quelque chose (et je ne pense pas que tous les protocoles soient bien finalisés...)

Moi je ne comprend pas pourquoi c'est une hérésie... Ce permet de gagner de la place sans perdre quoi que ce soit (du moins pour ma vision des choses).

Après, c'est moins consistant avec d'autre dialogue qu'on peut trouver, mais les icones sont la pour s'y retrouver rapidement au premier coup d'oeil. Sincèrement, cet agencement ne me dérange pas le moins du monde.

Bon, il faut préciser de quoi on parle en fait et surtout de ce qu'on compare.

Je parlait plus de KDE/Gnome (comparons ce qui est comparable).
Toi tu me parle de Qt/Gnome.

Par exemple, voici le dialogue d'ouverture de KDE4. Je le trouve extrêmement simple, complet et beau à la fois:
http://pbs01.files.wordpress.com/2007/11/13opendialog.png

C'est ce que j'entendais par "semble plus simple tout en étant plus complet". Dedans tu peux facilement faire tout ce que j'ai cité ci-dessus, tout en paressant "épuré".

Après, si tu prend le dialog d'ouverture de Qt, je suis d'accord pour dire qu'il est moins bien que celui de KDE (et que Gnome), et dans ce cas je te pris d'accepter mes plates excuses pour le quiproquo.

Nan franchement le travail de HIG de gnome est pourri comparer à KDE (sur cet exemple là, ce qui n'est tout de même pas toujours le cas). Passera? passera pas? ;)

Petite rectification:

- lors d'un "enregistrer sous", il y a en fait la possibilité de créer un dossier. Une différence de moins.
- par contre je déteste le "Parcourir d'autre dossiers" qui parfois est replié par défaut (je ne sais pas pourquoi). C'est vraiment inutile ce truc... (sachant il y a les icones des dossiers importants a gauche)

Effectivement, cette fonctionnalité de glisser déposer est bel et bien moins utilisé, mais ce n'est pas grave car de toute façon, avec la boite de dialog de KDE, on peut naviguer sans problème dans son filesystem... contrairement à celle de GTK/GNOME:

- on ne peut changer la vue/tri/preview dans celui de GTK
- avec KDE4 notamment, la barre d'adresse est vraiment super et permet de combiner les deux modes (bouton ou adresse texte). Par de raccourci clavier tordu style Ctrl+L a deviner...
- l'affichage est, du moins chez moi, bien plus rapide (genre pour /usr/bin)
- KDE gère correctement et depuis longtemps les KIOs
- quand ça s'ouvre ça prend pas les 3/4 de l'écran par défaut (bon ça c'est plutôt estétique je l'avoue)
- on peut créer des nouveaux dossier dedans (utile pour l'enregistrer sous)
- on peut voir et modifier les infos et droits d'un fichier
- d'un point de vue général, le sélecteur KDE semble plus simple tout en étant plus complet

après, le système de filtrage par nom est pour moi mieux dans le sélecteur GTK, mais c'est bien maigre par rapport aux inconvénients (et encore, j'en ai peut-être oublié)... Pourquoi proposer un navigateur si c'est pour qu'il soit inutilisable? Autant ne permettre que le glisser-déposer dans ce cas...

Bin si ça peut te faire plaisir, tu n'as qu'à essayer de déplacer un fichier dans la zone "nom de fichier" de la fenêtre d'ouverture sous KDE. Tu verras bien que ça permet la même chose (même si, je te l'accorde, la zone de drag est du coup forcément moins grande).

Nan franchement, pour avoir déjà utiliser gnome, le dialog d'ouverture GTK/GNOME est immonde. A la limite ils ferraient mieux de mettre un carré blanc avec écrit "Droper un fichier ici", ça irait plus vite...

Et je précise que je ne suis pas un fanboy KDE, j'apprécie un bon nombre d'aspects de Gnome (je l'ai même installé à ma soeur). Je trouve cependant KDE globalement meilleur (et encore plus d'un point de vue technique, en partie grâce à Qt).

PS: D'ailleurs, le Gnome de ma soeur refuse de fonctionner maintenant (je ne sais pas pourquoi, je n'ai pas encore vu le PC), alors qu'elle est restée longtemps avec un KDE sans problème... La faute vient peut-être d'autre part, mais je sens qu'elle va retourner à KDE tout compte fait.

Pas la mort ?

Franchement, si pour toi installer un logiciel est synonyme d'installer manuellement les dépendances (voir de les recompiler à leurs tours, ainsi que leurs dépendances...) et gérer les multiples problèmes de compilation qui peuvent arriver (pas la bonne version de telle ou telle lib, erreurs étranges...), je pense que tu aime être sadique.

Et puis parfois, justement, c'est pas un "./configure && make && make install". Il y a plusieurs façon de faire (scons, qmake, cmake, programme python sans compil, avec, programme java, etc...). Même si, je suis d'accord, le système autotool est (a tord?) le plus répandu. Autant je trouve le système de paquet vraiment plus simple que le système "installateur windows", autant là ça n'a rien de simple en soi et devrait rester l'apanage des informaticiens.

Moi même, étant développeur (et normalement futur ingénieur), donc plus qu'un "power user" windosien, je ne fait ça que quand vraiment je n'ai pas le choix.

Il faut vraiment arrêter avec cette mentalité élitiste... Un système d'exploitation est fait pour être utilisé, et la simplification du système informatique (extrêmement complexe en soi) à toujours été un but.

Je t'envie, moi, en 5 ans, j'ai même pas réussi à retenir mon propre numéro de téléphone portable...