Guillaume Laurent a écrit 1148 commentaires

Sur ma bécane...

C'est marrant, y a pas abiword dans ta liste. Tu ne l'as pas installé ? Ou bien c'est pas une appli gnome non plus ?

Si tu veux un autre exemple, cherche combien d'applis Gnome utilisent bonobo, comparent avec le nombre d'applis KDE utilisant dcop.

Tu vas pas me faire croire que TOUTES les applis KDE utilise TOUTES les facilité KDE.

Non, mais par exemple toutes celles qui impriment utilisent KDE pour ça. alors que ni Gimp ni Open Office n'utilisent GnomePrint. C'est juste un exemple, il y en a plein d'autres.

Tu vas pas me faire croire qu'il n'y a que des applis KDE et aucun applis qui n'utilisent que Qt.

Dans KDE, oui. Dans Gnome, il y a plein d'applis qui n'utilisent que GTK+ (ou même pas, ex. Open Office).

Mais bon, tu es un peu trop "fan" pour avoir un raisonnement cohérent sur la question.

J'adore les techno utilisé dans gnome mais je trouve très dommage que leurs technos soient si peu utilisé

La bonne question c'est "pourquoi sont-elles si peu utilisées", alors que celles de KDE le sont tout le temps :-).

(facon Qt et C++ STL).

Ce sont les mêmes, les APIs sont quasi identiques. Franchement, si tu as un pb pour apprendre QTL + STL, il vaut mieux que tu n'utilises ni l'un ni l'autre.

ligsigc++ est la preuve que l'on peut implementer les signaux avec du vrai C++ standard

moc fait beaucoup plus de choses que ligsigc++, et libsigc++ n'a pas que des avantages non plus (par exemple c'est sympa de ne pas avoir un type-checking trop fort sur la connection d'un signal, ça évite souvent des includes inutiles).

Au lieu d'utiliser l'existant on re-invente

Non. La QTL est là si tu n'as pas la STL (ce qui arrive encore très souvent), et si tu as la STL, tu peux mélanger les deux sans problème. Les APIs sont très proches.

Si je me souviens bien, Emacs est justement l'exemple d'un logiciel "cathedrale" pris par ESR au debut de son papier.

orthographe. :-)

Je ne vois pas le rapport. Tous les projets libres auquels je participe ou j'ai participé le sont à titre personnel, rien à voir avec mon employeur (qui est un éditeur de softs propriétaires).

Tout ce que je dis c'est que si ton expérience avec automake & Co. se limite aux projets que je vois sur savannah, je peux comprendre que tu en sois satisfait. De mon coté, avec rosegarden le constat est très négatif, et tu n'as qu'a regarder les archives des mailing lists KDE pour voir qu'on est pas vraiment une exception. Je ne crois pas que du coté Gnome on soit très enthousiaste non plus.

mais apres, tu ne peux pas savoir combien j'en ai gagnees ensuite.

Pour des projets très simples dans ce genre là :

http://savannah.nongnu.org/users/ymettier/(...)

oui, c'est sur, une fois que tu as une config qui marche tu la reproduis telle quelle.

Es-tu developpeur pour affirmer de telles choses ?

Si tu jette un oeil à ma homepage tu aura la réponse à cette question.

C'est ce qu'il y a de mieux

Hélas oui, faute de concurrence.

C'est brillant comme raisonnement.

Ce n'est pas un raisonnement mais l'établissement d'un fait. autoconf/automake et libtool sont pathétiquement lents, beaucoup trop difficiles à utiliser, génèrent un gros tas de fichiers impossible à débugger, et surtout, le pire, cassent très souvent la compatibilité d'une version à l'autre.

Je pense que ces trois projets sont la cause d'une nombre effarant d'heures perdues par les développeurs du Libre, et que ceux qui les maintiennent sont irresponsables. Il est regrettable qu'on ne puisse pas les virer, pour ça il va falloir qu'une alternative crédible s'impose. Le plus tôt sera le mieux.

Make-like en Ruby. Pas encore très développé, mais très prometteur :

http://raa.ruby-lang.org/list.rhtml?name=rake(...)

Et c'est pour ça qu'Apache utilise auto* libtool depuis apache 2.

C'est pas pour ça qu'ils n'aimeraient pas utiliser autre chose si il y avait mieux. Va leur demander si ils sont contents de les utiliser, je veux bien prendre les paris sur la réponse.

autoconf/automake et libtool sont des grosses merdes mal documentées, c'est difficilement discutable. Malheureusement c'est tout ce qu'on a pour le moment, mais heureusement on commence à avoir des alternatives plus sympathiques.

Lorsqu'un protocole est mal pensé

Et toi, tu as pensé beaucoup de protocoles ? Sérieusement, ces jeux génèrent une économie croissante, le problème de la tricherie est déjà dans certains cas plus qu'une simple question de netiquette mais de fric. Crois-tu vraiment que tous les codeurs et designers chez tous les éditeurs de jeux en réseaux soit des neuneux complets au point de n'avoir jamais pensé au problème ?

La seule différence, c'est que l'opération est plus longue, pas plus difficile

C'est bien vrai. D'ailleurs dès demain j'arrête de coder en Java ou C++, je tape directement le code hexa. Ça sera plus long, mais pas plus difficile.

Bref, il n'y a aucun gain à avoir son code fermé, sauf qu'il y a une perte, tu perds les contributions de tous ceux qui trouveraient les failles de ton programme et te les signaleraient sans les exploiter.

Ça ne loupe jamais, quand on trouve un cas ou l'Open Source n'est pas approprié, il y en a toujours deux ou trois pour faire des loopings cérébraux et arriver à dire que "Nooooon, l'open source c'est *toujours* bien, whaaaaaaaaa".

juste a une bonne conception du jeu et son serveur. c'est tout

Justement, comme on vient de te l'expliquer, la "bonne conception" c'est de limiter autant que possible les données passant sur le réseau, et donc de déférer un maximum de truc au client. Donc chaque client doit avoir un max d'info, y compris celles auxquelles le joueur lui-même ne devrait pas avoir accès (genre, qu'est-ce qu'il y a derrière le mur).

Maintenant comme tu as l'air d'être un super-codeur, tu as surement une solution géniale pour regler le problème ?

Là par contre, tu me perds. Pourquoi ?

A quelques rares exceptions près, ils considère que l'Open Source est le meilleur mode de développement possible, que les developpeurs Open Source sont plus compétents que ceux qui bossent dans l'industrie, ou, lorsque ce sont les mêmes, qu'un dev travaille mieux lorsqu'il fait du libre que du proprio chez son employeur.

mais bon, leurs actions sont pas mals.

Pour RMS je suis assez d'accord, pour ESR le personnage me dégoute vraiment trop (déclarer juste après les attentats du 11 sept. que cela ne serait pas arrivé les les passagers avait eu le droit de porter une arme, c'était immonde, et en plus complètement stupide).

Sinon oui, ils sont influents. Parfois pour le pire plus que pour le meilleur :-).

Pour ESR, je ne parlais pas du point de vue technique, mais philo.

Même. Sa vision du logiciel libre est beaucoup trop idéaliste et ne colle pas du tout avec la réalité.

Au final, Je maintiens que les écrits de RMS et ESR sont les meilleurs pour cerner la communauté du libre à travers l'Histoire.

Non. Ça fait 10 ans que je la fréquente, 8 ans que j'y participe activement, et je n'ai jamais rencontré de bon developpeurs libres qui n'aient pas une opinion très mitigée de RMS ou ESR. Dans 99% des cas, ceux qui les placent sur un piedestal sont des gamins qui rèvent d'être hackers mais n'ont jamais rien codé d'autre qu'un wrapper autour de 'tail' en GTK+.

Par contre pour cerner la communauté de linuxfr, les écrits de RMS et ESR sont très bien :-).

"Selected Essays" :-)

Le plus extrémiste de tous est justement le fondateur de la communauté du logiciel libre...

Et ? Il n'en est pas le seul représentant.

C'est lui qui a créé la communauté,

Discutable. La "communauté" existait avant lui, il te le dirait lui-même.

qui a écrit les GPL,

LA GPL.

qui a écrit Emacs,

Ouhla, la génèse d'Emacs c'est un tout petit peu plus compliqué que ça :-).

http://www.wikipedia.org/wiki/Emacs(...)

qui a lancé et qui anime le mouvement GNU.

Lancé oui, anime... il est loin d'être seul, et loin d'être sans contestation.

Tu viens juste de te rendre ridicule en montrant ta méconnaissance de l'histoire informatique ansi que du mouvement du logiciel libre.

C'est rien à coté de la tienne.

Conseil si tu veux apprendre deux/trois trucs sur le domaine informatique : lis les bouquins de Richard M. Stallman et de Eric S. Raymond

Stallman n'a jamais écrit de bouquin. Ceux d'Eric Raymond sont très contestables, vu que son expérience en développement logiciel est très limitée (sérieusement, n'importe quel ingé pas trop neuneu avec 3 ans de bouteille en SSII en saura plus long que lui, il en est toujours au C/Unix de papa) et que son ego trouble assez souvent son jugement. Une page rigolote à son propos :

http://esr.1accesshost.com/(...)

c'est loin d'être objectif, mais pas totalement faux non plus.

Par ailleurs entre ses opinions politiques oscillant entre racisme et fascime (http://armedndangerous.blogspot.com/(...)) et, dernièrement, sa façon de s'approprier et de politiser le Jargon File (http://slashdot.org/article.pl?sid=03/06/08/1534249&mode=nested(...)), je comprend vraiment mal qu'on continue de vénérer ce type.

Amazon.com... Mais aucun magasin US n'envoie de produits de ce type (en général, tout ce qui est electronique) à l'étranger (à part éventuellement le Canada).

Suivant les cas, oui.

A part les cas où c'est nécéssaire pour des raisons de performances, à quels cas penses-tu ?

La création d'un objet nécessite une allocation mémoire, c'est une opération coûteuse dans tous les langages.

Non. En C++, si tu crée un "petit" objet sur la stack, ça n'est pas très couteux...

Tous les langages et toutes les méthodes de programmation nécessitent un apprentissage...

Tu n'as pas compris : si tu apprends la programmation objet, en général la réutilisation des objets ne sera pas présenté comme un concept de base, bien au contraire. Ça sera plutôt dans la section "trucs et astuces si votre programme rame vraiment trop".

Ah ? Tous les langages dans lesquels le premier venu peut coder comme un goret sont des langages mal conçus ? Il ne doit pas y avoir des masses de langages bien conçus alors...

Je ne parle pas du "premier venu". Ceci dit, oui, il n'y a pas beaucoup de langages bien conçus sur ce plan là (je ne connais que Python et Ruby qui s'en sortent).

Après, si le développeur ne sait pas réutiliser des objets, ... (en gros qu'il ne sait pas faire de prog objet correctement)

Ah, parce que réutiliser des objets c'est de la programmation objet "correcte" ? Il me semble au contraire que c'est parce qu'il est toujours trop couteux en Java de créer des objets qu'on est obligé de les réutiliser.

C'est clairement un des points ou Java a totalement échoué : la façon "instinctive" d'utiliser le langage fait écrire du code pas performant. Il faut apprendre des techniques pas du tout triviales pour éviter ça, et ça complexifie d'autant l'écriture des programmes. C++ a le même problème mais pas sur la création d'objet (plutôt sur les affectations, la manière "instinctive" de faire induit des plantages ou des fuites de mémoire).

Après, évidemment les "experts" disent "ah mais oui si tu fais comme ça c'est que tu sais pas coder". Non, c'est faux. C'est le langage qui est mal conçu.

Et puis on m'a montré ECLIPSE et quelques fonctionalités pratique, et paf en 10min j'étais tombé amoureux

As-tu essayé Intellij Idea ?

En gros, oui, ça arrive, et plus souvent qu'on ne croit.

Je ne vois pas comment ça peut causer un pb de perfs. Pour chaque listener il y a un objet derrière (disons un bouton), donc bien avant que la création des listeners eux-mêmes puisse poser un pb, la création de ces objets va en poser un bien plus immédiat.

Ça reflete bien la faible (mais pas inexistante) percée de Java dans le domaine des applis bureautiques.

Java a plus percé dans le monde des serveurs et de l'embarqué, c'est vrai. Mais aussi pas mal en bureautique, simplement pas sous Linux (Java tourne beaucoup mieux sous Windows), et pas dans des applis grand-public.