HappyPeng a écrit 324 commentaires

Un langage orienté objet n'implique pas l'utilisation d'un système d'exceptions. Ici c'est uniquement une éventuelle question de cohérence.

Est-ce que cela tourne sur une machine virtuelle libre, ou ce logiciel est-il dépendant du J2SE propriétaire (Blackdown, Sun ...) ? Aparamment le site ne conseille que le J2SE Sun.
Je ne vous cacherais pas que c'est toujours ce qui me gène avec les projets libres en Java.

Où sont les chiffres sur les achats ?

Et on comprend que Novell ne veuille pas jeter le travail de SuSE, pourquoi le feraient-ils avec le travail d'intégration Ximian OpenOffice.org et le travail de Ximian sur GNOME ?

Je ne pense vraiment pas que cette décision relève d'une telle logique, mais plutôt d'une abscence de choix de Novell face à des clients SuSE habitués à KDE et voulant une continuité cohérente et un potentiel de GNOME dans certains domaines.

C'est du troll pur et dur, comme souvent avec vous.
Il est parfaitement possible d'utiliser GTK+ avec des environnements libres tels DevC++/MingW32, Python, Mono, Cygwin mais également avec Visual Studio, et ce sans aucun hack et sans problèmes.
Le manque de portabilité des applications utilisant GTK+ vient la plupart du temps du fait qu'elles utilisent des API spécifiques à Unix en général et à GNU/Linux en particulier.

Le problème de cette VM libre semble ne pas venir d'elle-même mais justement des bibliothèques standard nécessaire pour faire tourner les logiciels en Java, puisque celle-ci se fonde sur GNU Classpath, comme GIJ, or elle n'est pas compatible J2SE 1.4 et n'inclue pas (ou inclue partiellement) Swing.

C'est bien ce qui est dit dans les comparatifs. Si on fait de l'algorithmique pure (pas d'IO, notamment) et si l'on ne regarde pas le temps que met la VM à se lancer, Java est plus rapide. Maintenant, dans les situations réelles ... notamment lorsque l'on a des interfaces graphiques à réaliser ... il se pourrait bien que Python ait un net avantage.

http://twistedmatrix.com/users/glyph/rant/python-vs-java.html(...)

C'est toujours affligeant de voir que les idiots ne se reconnaissent pas dans les critiques qui sont faites d'eux.

Tout cela est bien gentil, mais il me semble qu'on peut arriver à de telles choses grâce à des progrès en ce qui concerne le bytecode Python et la façon dont il est executé, tout en concervant de telles propriétés et poussées à leur extrême. Pour énormément d'utilisations, Java est lourd et lent alors que Python, et probablement Ruby et Perl, sont légers et rapides.

Et ne parlons même pas de ceux que ça fait bander d'utiliser un langage au nom également tropical qui rappelle une célèbre île d'Indonésie (ça doit leur rappeller leurs vacances), à la syntaxe verbeuse et souvent inutile mais qui ressemble à des langages célèbres et autrement excellents (ça doit leur faire croire qu'ils savent coder), et supportées par l'un des plus gros géant de l'informatique dans le monde (ça leur fait trouver du boulot, seul point positif, et ça leur fait croire que quand on y met de l'argent c'est bien).

Plus concrètement, vous faites pitié.

Une fois de plus, alors qu'énormément de gens trouvent scandaleux que la moindre application orientée GNOME soit développée avec Mono sous prétexte de .NET, on en fait des pages et des pages sur Java dans un espace consacré au logiciel libre, alors que la grande majorité des logiciels libres développés en Java sont incapables de tourner sans une machine virtuelle propriétaire.

Pour moi, Java est la plus grande contradiction du logiciel libre, parce que des centaines de développeurs du libre déclarent ne pas pouvoir s'en passer, sans pour autant que les environnements Java libres semblent avancer, et tout en trouvant cela parfaitement normal puisqu'utilisé sous des systèmes d'exploitations libres.

Ajoutons à cela la mode Java qui s'installe. On avait déjà Java et une pelletée d'autre langages dont la syntaxe est voisine (Javascript, C#, J# et j'en passe), voilà maintenant qu'on voit des langages comme PHP (avec PHP5) adopter la même syntaxe boursouflée, parce que "c'est l'avenir". D'aucuns disent que c'est la syntaxe du C : c'est une erreur, en C on peut toujours faire des programmes clairs et concis. Certains vont jusqu'à dire que cette syntaxe Java-like rend obsolète celle du Python, mais mieux vaut lire de telles aberrations qu'être aveugle, regardez simplement quelques comparatifs là dessus.

L'effet Java en arrive à un point où il est difficile dans certains domaines (XML) de trouver des bibliothèques libres qui tournent autrement que sur des machines virtuelles totalement propriétaires.

Ajoutez à cela la présence d'alternative utilisables au bas mot dans 75% des cas pour lesquels Java est utilisé, au moins en ce qui concerne les logiciels libres : nous avons Python, dont les performances ne semblent pas toujours devoir craindre celles de Java et disposant d'excellentes bibliothèques et d'environnements d'une grande qualité et bénéficiant de support comme Zope, nous avons Ruby, nous avons même Perl, et PHP. Tous ces langages disposent de la portabilité, et d'environnement d'exécution de plus en plus rapides, ainsi que d'un temps d'apprentissage réduit et d'une simplicité de code souvent exemplaire. En plus des langages traditionnels, C, C++, Objective-C, Objective CAML, Lisp, Scheme, ... (Et nous ne parlons _même pas_ de la difficulté par exemple d'écrire des interfaces graphiques en Java.)

Alors maintenant, il est certain qu'avoir une machine virtuelle libre compatible avec les dernières norme Java est positif, en effet cela permet de faire tourner des logiciels libres sur des environnements libres. Maintenant, est-ce qu'il faut l'attendre pour s'intéresser au Java, personnellement, je ne le pense pas, et j'encourage les développeurs à s'intéresser à tout ce qui existe avant d'envisager utiliser Java.

À présent, si quelqu'un a des arguments concrets et réels en faveur de Java (je n'en ai vraiment quasiment jamais vu), qu'il se prononce.

Pour récupérer les programmes TV sans utiliser sa connexion, pour ceux qui ont une carte TV dans leur PC, un outil très utile dont j'aimerais faire la publicité :
http://nxtvepg.sourceforge.net/(...)

Je pense qu'il était tout de même important de souligner que la communauté Gnome chez les francophones ce n'est pas que de la traduction ...

Ces applis tournent également sous Fresco avec un adaptateur X.

Il y a également devhelp (http://www.imendio.com/images/devhelp-tree.png(...)), qui est très pratique.

Il faut un monopole pour vouloir faire ça, sinon ça s'apparente au suicide.

pBpG n'a pas tort, il ne justifie ni ne soutient rien, il ne fait qu'expliquer. Microsoft pousse la logique de rentabilité jusqu'au bout, et si les gens sont choqués c'est uniquement parce que Microsoft détient un quasi-monopole sur un domaine. Mais comme dit sur gnu.org, Microsoft n'est pas le «Grand Satan» : cette logique n'est pas particulière à Microsoft, les autres entreprises l'ont également (par exemple Apple, que tant de gens seraient prêts à défendre), mais sont dans une position différente (vouloir arriver à un monopole est différent de vouloir l'exploiter). Cela ne justifie rien, cela affirme donc que Microsoft n'est pas une entreprise meilleure que les autres, et aussi que certaines entreprises qui cherchent à s'attirer la sympathie des gens ne sont pas forcement meilleures que Microsoft, mais qu'elle n'est pas forcément la pire.

(Attention, ca n'est pas forcément non plus mon point de vue, lorsque je vois les termes (qui ont peut-être été changés) de la licence de Front Page, qui constituent quelque chose de bien plus grave que de la logique de profit.)

Et aucun de ceux que vous citez n'est bien intégré à Gnome.

Oui mais non.

Mais si, mais si.

Quand je vois ce que ce concept théorique est devenue dans la réalité, on peut se poser pas mal de questions sur les choix technologiques.

Ce n'est pas parce qu'un logiciel ne vous plaît pas ou même qu'un logiciel que les choix techniques sont mauvais.

Et pourtant nous avons dans le libre des exemples d'intégration : emacs, gimp, konqueror, ... .

Personnellement je pense que emacs et gimp sont d'extrêmement mauvais exemples en ce qui concerne l'intégration (à quoi sont-ils intégrés au juste ?). Quand à konqueror, oui, il est parfaitement bien intégré à KDE, qui est une plateforme.

Je pense que cette notion de platforme est caduque. Il faut des bibliothèques, des languages de script et des greffons indépendants de la configuration générale. Des bibliothèques qui ne font qu'une seule chose à la fois et donc avec un faible nombre de dépendances.

Le nombre de dépendances est faible mais n'est jamais nul, par conséquent la notion de plateforme subsite, à moins de vouloir charger en mémoire plusieurs bibliothèques dont la fonction est similaire. Si une application ou une bibliothèque s'intègre à Gnome elle devra si elle veut faire du XML utiliser libxml2, etc. C'est ce que j'ai déjà expliqué précédemment.

Je ne vois donc pas en quoi ces notions sont "caduques".

De plus Gnome a éloigné la portabilité

Peut-on tout faire portable à cette échelle ? Je me pose la question.

Je pense que la plupart des softs Gnome devraient mettre les biblios Gnome en option à la compilation, afin d'en distribuer deux binaires (un utilisant gconf et consort mais lent, l'autre simulant gconf mais rapide).

Il est clair qu'il est encore possible d'utiliser des logiciels "standalone" comme Window Maker, gqview, etc. et que cela s'avère dans certains cas plus rapide (souvent relativement aux fonctionnalités d'ailleurs, comme aterm par rapport à gnome-terminal).

Le but de Gnome est avant tout d'intégrer les applications dans un environnement commun, c'est-à-dire que pour effectuer une même tâche les applications sont censées utiliser une même bibliothèque du framework (gconf pour stocker les informations de configuration, gstreamer pour le multimédia, etc.), et que les applications sont censées au sein de l'environnement interagir entre elles (gthumb s'intègre à nautilus, etc.).

Globalement et dans l'idéal, si ce projet est mené totalement à bien, qu'est-ce que l'en constate ? Puisque toutes les applications de l'environnement pour une même tâche utilisent une même bibliothèque au lieu de réinventer la roue, la consommation de ressources se fait moins énorme que si chaque application implémente sa propre solution (imaginez quatre systèmes équivalents à bonobo chargés en même temps, ou plutot regardez ce qui se passe si l'on charge les environnements Gnome et KDE en même temps sur une même machine).

Par conséquent le but est d'apporter bien entendu plus d'homogénéité, avec comme corollaires les faits d'ajouter plus de simplicité, plus de cohérence, plus de fonctionnalités, et plus de performances. En exagérant un peu, je dirais qu'il n'y a pas d'autre moyen d'améliorer les applications existantes en concervant des performances optimales, sachant qu'on n'utilise jamais une seule application à la fois.

Mais il est clair que tout n'est pas pour l'instant parfait, même si Gnome est en progrès permanent sur tous les plans.

(Les remarques s'appliquent d'ailleurs tout autant à KDE qu'à Gnome.)

Ben t'as pas besoin de lancer une appli specifique pour voir tes images ; gqview n'est pas adapté à la navigation dans le système de fichiers et à la base nautilus n'est pas adapté pour le boulot que fait gqview, c'est donc un compromis acceptable.

Non.

MacOS X désigne le produit fini avec sa couche non libre, et désigne surtout sa couche non libre, sinon c'est Darwin.

Et pour les Mandrake Cooker, et pour ... bref pour toutes les versions unstable / experimental de toutes les distributions.

Ce que je voulais dire, et qui n'a bien entendu pas été entendu dans ce brouhaha mandrakiste, ce n'est pas qu'une autre distribution est plus simple, ou meilleure, ou quoi que ce soit. Ce que j'ai voulu dire, c'est que si MandrakeSoft veut un stand publicitaire, ils n'ont qu'a le faire eux-mêmes ; jamais je n'irai distribuer leurs produits ou que ce soit sans être payé pour.

Oui enfin, ne mélangeons pas tout, la FSF et GNU ne sont pas que RMS, même s'il les a créés, et GNU/Linux, ou plus largement le logiciel libre, n'est pas que Linux et le pseudo-mouvement OpenSource.