Un article du site Newsforge fait le point sur la controverse. La version stable actuelle d'Openoffice.org (version 1.1.4) utilise déjà Java et elle requiert un JRE (Java Runtime Environment) pour pouvoir profiter de toutes ses fonctions. Néanmoins ce ne sont que des fonctionnalités annexes et quelque peu périphériques qui dépendent de Java (le driver JDBC pour les bases de données Java ; les filtres XSLT, etc.) à l'exception notable des outils d'accessibilité qui peuvent êtres cruciaux pour certaines personnes handicapées.
Le problème posé est qu'il n'existe pas de version libre de Java ou pire encore, qu'il n'existe même pas de version officielle propriétaire de Java pour certains systèmes d'exploitations (FreeBSD par exemple) ou certaines architectures (PowerPC par exemple).
En dépit de cette difficulté cette dépendance Java n'avait pas posé jusqu'à présent de problème particulier au monde du logiciel libre. Certaines distributions ont choisi de désactiver le support Java d'OO.o et de se passer des fonctions annexes. D'autres proposent au contraire un support complet pour leurs versions non-libres sur certaines architectures.
La version 2.0 d'OpenOffice.org (actuellement en béta) est une refonte majeure de la suite bureautique avec l'ajout de plusieurs nouvelles fonctions. Bien que très prometteuse cette nouvelle version suscite un large controverse auprès des utilisateurs de logiciels libres car elle renforce et élargit la dépendance envers Java.
Le nouveau module de base de donnée (Base) repose sur HSQLDB qui requiert Java. Le nouveau lecteur pour intégrer des vidéos et clips audio dans des documents dépend également de Java ainsi que tous les assistants de Writer (le module de traitement de texte).
Ce qui était jusqu'alors possible (utiliser OO.o sans Java) va devenir de moins en moins vrai et le caractère multi-plateforme de la suite bureautique va en pâtir.
Les réactions les plus virulentes accusent Sun (le principal contributeur d'OpenOffice.org) de machiavélisme afin de pousser sa technologie Java. D'autres utilisateurs déçus soulignent que plusieurs arguments de promotion d'OO.o par rapport à MicrosoftOffice deviennent caducs (la liberté ou le caractère multi-plateforme).
Du coté des distributions l'éventail des réactions est très large : des distributions commerciales comme Suse ou Mandrake fourniront une version non libre avec le JRE de Sun tandis que les versions librement téléchargeables ne comprendront pas ce support Java. RedHat (et donc Fedora) espère pouvoir utiliser une version libre de Java basée sur le compilateur libre GCJ et ainsi activer toutes les fonctions d'OpenOffice.org 2.0 (pour l'instant cela ne marche pas très bien et cela restera laborieux et difficile). Debian, Ubuntu ainsi que Gentoo n'ont pas d'autre option pour l'instant que de désactiver toutes les fonctions Java en attendant que GCJ avance.
En définitive cette affaire souligne le poids déterminant que Sun détient dans le développement d'OpenOffice.org et l'influence que cette firme exerce au moment des choix architecturaux des futures versions. La controverse actuelle est en tout cas extrêmement dommageable pour l'expansion d'OO.o qui semblait s'amplifier ces derniers temps.
Une divergence (fork) semblant improbable étant donné la taille et la complexité du projet la solution réside peut-être dans le soutien à apporter au projet GCJ ou aux suites libres communautaires (Koffice pour KDE et Abiword/Gnumeric pour Gnome).
Aller plus loin
- L'article de Newsforge (3 clics)
- Les réactions sur LWN (2 clics)
- La base de données HSQLDB (2 clics)
- Le compilateur GCJ (2 clics)
# Un peu hors sujet
Posté par Stéphane Traumat (site web personnel) . Évalué à -5.
J'avais bloggé la dessus il y a quelques temps suite à un entretien avec le mec de C-JDBC mais j'ai encore trouvé personne qui l'ait utilisé en production! (http://www.jroller.com/page/jonaslive/20041208#derby_seems_a_good_d(...)
http://about.me/straumat
[^] # Re: Un peu hors sujet
Posté par wismerhill . Évalué à 0.
# Abiword et Gnumeric
Posté par Antoine . Évalué à 8.
[^] # Re: Abiword et Gnumeric
Posté par Cook Captain . Évalué à 10.
[^] # Re: Abiword et Gnumeric
Posté par fabb . Évalué à 10.
Je le répète encore, mais on y est presque. C'est l'un des grands objectifs de FC4.
C'était déjà testable dans FC3 (non installé par défaut).
Sun fout un peu le "bordel" avec ses brevets, mais ce qu'il faut, c'est s'"imposer". Tant pis si gcj n'est pas compatible à 100 % avec Sun (problème de brevet que _Sun_ a introduit).
[^] # Re: Abiword et Gnumeric
Posté par Bouiaw . Évalué à 8.
[^] # Re: Abiword et Gnumeric
Posté par fabb . Évalué à 7.
[^] # Re: Abiword et Gnumeric
Posté par Nÿco (site web personnel) . Évalué à 8.
[^] # Re: Abiword et Gnumeric
Posté par fabb . Évalué à 0.
Que Sun n'attaque pas MS, je m'en fous un peu :-)
Par contre il ne faut pas que Sun puisse attaquer le libre. Donc il ne faut pas implémenter ses brevets.
[^] # Re: Abiword et Gnumeric
Posté par gloups . Évalué à -3.
On peut imaginer :
- attaque d'un fork libre
- attaque de développeurs sur des contribs à OOO
....
[^] # Re: Abiword et Gnumeric
Posté par fabb . Évalué à 1.
Quoi perdu ?
Nÿco dit que MS ne peut pas attaquer Sun. Il ne dit pas que MS ne peut pas attaquer le libre.
J'ajoute que Sun peut attaquer le libre (via ses brevets, comme MS).
Donc, l'accord MS/Sun ne change rien pour le libre.
[^] # Re: Abiword et Gnumeric
Posté par M . Évalué à 10.
bof, abiword met des plombes pour ouvrir de gros fichiers et j'ai eu de gros soucis pour imprimer des documents avec gnumeric (ca a finit en export excel, puis impression via openoffice.org).
Il me semble aussi que gnumeric n'a pas de correcteur othographique.
Ils sont prometteurs, mais manque de finition (je pense que c'est du au manque de contribueur/utilisateur)...
[^] # Re: Abiword et Gnumeric
Posté par GnunuX (site web personnel) . Évalué à -4.
Ca fait v'la le tps que aspell est intégré à abiword.
Concernant les gros fichiers, OOo à le même defaut (c bien le xml mais c plus long).
[^] # Re: Abiword et Gnumeric
Posté par M . Évalué à 3.
sinon OOo est quand meme plus rapide 5-10 secondes via 30-60 secondes
Tant que j'y suis c'est quoi les equivalents pour les presentations et le dessins ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Abiword et Gnumeric
Posté par iznogoud . Évalué à 4.
Pour les présentations j'avais croisé un truc permettant de faire des présentations en html, tu faisais ton texte et il ajoutait les boutons de navigation. Minimal, mais suffisant pour la plupart des présentations. J'ai par contre oublié le nom.
[^] # Re: Abiword et Gnumeric
Posté par TImaniac (site web personnel) . Évalué à 4.
DocBook je suppose. Je sais qu'il y a aussi des "diaporama" à base de SVG.
[^] # Re: Abiword et Gnumeric
Posté par tgl . Évalué à 4.
http://member.wide.ad.jp/wg/mgp/(...)
Il y a aussi S5 qui a l'air sympa, basé lui sur XHTML et CSS :
http://linuxfr.org/2004/10/14/17436.html(...)
http://www.meyerweb.com/eric/tools/s5/(...)
[^] # Re: Abiword et Gnumeric
Posté par gnumdk (site web personnel) . Évalué à 3.
avec kde, n'importe quel appli sait faire du pdf.
[^] # Re: Abiword et Gnumeric
Posté par fabb . Évalué à 0.
[^] # Re: Abiword et Gnumeric
Posté par anonimulo . Évalué à 2.
puis dans kprinter, choisi "Imprimer dans un fichier (PDF/Acrobat)"
</ troll >
[^] # Re: Abiword et Gnumeric
Posté par Tobu . Évalué à 2.
</ troll >
</t'as dit>
Même pas vrai, ça marche aussi sous gnome!
[^] # Re: Abiword et Gnumeric
Posté par wismerhill . Évalué à 2.
Puisque sur un système Unix l'impression est basée sur postscript, imprimer dans un fichier te donne un fichier postscript. Ensuite il n'y a plus qu'à faire un ps2pdf.
Et pour les programmes qui permettent de changer la comande d'impression (par exemple mozilla) tu peux remplacer le bon vieux lpr par kprinter.
[^] # Re: Abiword et Gnumeric
Posté par Sylvain Sauvage . Évalué à 2.
Le paquet debian s'appelle cups-pdf.
Sinon, il doit exister pour les autres :
http://cip.physik.uni-wuerzburg.de/~vrbehr/cups-pdf/(...)
[^] # Re: Abiword et Gnumeric
Posté par Prosper . Évalué à 2.
[^] # Re: Abiword et Gnumeric
Posté par fabb . Évalué à 0.
Le fait d'"imprimer vers un fichier pdf" est un détail.
[^] # Re: Abiword et Gnumeric
Posté par bertrand . Évalué à 1.
[^] # Re: Abiword et Gnumeric
Posté par M . Évalué à 2.
Et dans ce cas autant faire du Latex/Beamer et l'exporter en pdf pour la pres.
[^] # Re: Abiword et Gnumeric
Posté par R4f . Évalué à 9.
Justement, ils sont prometteurs, donc nécessitent des contributeurs et des utilisateurs (des patches, des bug reports, des manuels...).
Si tout le monde les laisse tomber, alors ils n'auront aucune raison de mûrir...
Ce serait une victoire pour le logiciel libre si de tels logiciels arrivaient au niveau d'OpenOffice.org car jusqu'ici j'entends bien des gens dire «le logiciel libre, c'est bien, mais les vrais logiciels libres qui marchent sont ceux qui ont été produits sur le modèle proriétaire...» et ça me fait toujours mal...
[^] # Re: Abiword et Gnumeric
Posté par salvaire . Évalué à -2.
Ah non. Heureusement qu'il existe un traitement de texte utilisable par madame michu sur Linux.
[^] # Re: Abiword et Gnumeric
Posté par fabb . Évalué à -2.
OpenOffice.org *est* un logiciel libre.
[^] # Re: Abiword et Gnumeric
Posté par wismerhill . Évalué à 2.
[^] # Re: Abiword et Gnumeric
Posté par gael s. . Évalué à 10.
Deja qu'on a du mal a faire passer les "profanes"
de la suite MS Office a OOo.
si en plus au bout de 6 mois on leur dit : non finalement
tu vas encore utiliser autre chose : on va migrer
parce que ya eu scission au sein du parti.
....
[^] # Re: Abiword et Gnumeric
Posté par Antoine . Évalué à 5.
Donc, oui, on paye le prix de cet enthousiasme un peu naïf et débridé, et de ce délaissement de deux projets prometteurs. Mais c'est de notre faute.
[^] # Re: Abiword et Gnumeric
Posté par Manwe . Évalué à 5.
La distance entre le double clic et la permière lettre reste impressionnante sous OpenOffice comparé à MS Office.
J'ai honte des fois quand je montre ca à mes "profanes".
[^] # Re: Abiword et Gnumeric
Posté par Croconux . Évalué à 4.
Sans oublier KOffice dont la version 4 utilisera nativement le format OOo. Pas besoin de Java. D'où l'utilité de porter les libs KDE sous d'autres plateformes (Windows).
Pour en revenir à l'utilisation de Java, j'ai un peu de mal à en voir la nécessité. Autant pour JDBC, ça se comprend. Pour XSLT, why not. Apache propose pas mal d'outils en Java, notament pour manipuler du SVG. Mais pourquoi ne pas utiliser LibXML2 qui est une lib native, multi-plateforme, et l'une des plus complètes et conformes aux standards ? Quand à Java pour les wizards de Writer, là c'est un peu portnawak. Le reste de l'interface vit très bien sans Java alors pourquoi quelques malheureuses boites de dialogue auraient-elles besoin de ça ? Pour faire des effets-3D-qui-font-bander-papy ?
[^] # Re: Abiword et Gnumeric
Posté par Cook Captain . Évalué à 6.
C'est con parfois la vie !
[^] # Re: Abiword et Gnumeric
Posté par Unixfix le Gaulois . Évalué à 0.
[^] # Re: Abiword et Gnumeric
Posté par ookaze . Évalué à 9.
Nan parce que ma femme, qui est comptable, n'utilise peut-être pas toutes les fonctionnalités d'Excel, mais ce qui est sûr, c'est qu'elle l'utilise toute la journée au boulot et intensément.
En bref : elle dit que Gnumeric est largement au-dessus de tout ce qu'elle a essayé sous Linux jusqu'à présent, dixit elle-même : "c'est mieux qu'Excel !!!", et elle utilise Excel de manière professionnelle. Alors bon, c'est qu'une anecdote, mais ça ne fait que corroborer tout ce que j'entends sur les fonctionnalités de Gnumeric, et va à l'encontre de ce que dit le post parent.
En plus long :
Ma femme utilise beaucoup les tableurs parce que ça doit être ce qu'elle connaît (et comprend) le mieux en informatique. Elle a utilisé le tableur d'OOo pour son boulot et pour elle. Elle m'a fait tout un tas de reproches sur le tableur d'OOo, bon OK, elle a connaissance de la doc (en français), et elle m'avait avoué qu'elle avait pas envie de changer tout ce qu'elle savait. Elle utilisait KSpread pour ses fichiers perso et disait que c'était suffisant, mais que tout marchait pas bien.
Récemment passé en KDE 3.4 et Gnome 2.10, les applis sont maintenant mélangées dans les menus des deux DE. Un matin de la semaine dernière, elle m'appelle tout excitée : "regarde ! J'ai trouvé un super tableur, ça fait tout comme Excel, c'est même mieux, y a pas tel bug !". Les yeux ébahis, je lui demande comment elle a trouvé ce programme. Elle me montre alors le menu Bureautique de KDE, avec Tableur Gnumeric (ou un truc comme ça) tout en bas du menu.
Au passage, vu qu'elle utilise aussi Galeon comme navigateur, ça finit de casser à mes yeux les deux arguments suivants anti-LL :
- Il est très difficile de trouver à quoi sert une appli dont on ne connaît pas le nom sous Linux (j'utilisais Gnumeric parce que je suis sous Gnome, mais je lui avais pas dit, maintenant, c'est terminé pour KSpread :( )
- Les applis Gnome s'intègrent très mal dans KDE et vice-versa. Moi je ne suis pas une référence quand je dis que je ne vois pas de différence en utilisant mp3Kult sous Gnome, mais ma femme qui a utilisé Gnumeric (et Galeon) sans souci, sans même se rendre compte qu'il y avait des choses différentes, ça en dit long. Ah si, elle a quand même bloqué sur l'enregistrement de fichier : elle cherchait comment enregistrer dans un sous-répertoire de son HOME (faut cliquer la petite flèche, le texte explicatif à côté est encore trop technique pour elle).
- Ma femme, utilisateur lambda typique qui n'y comprend rien à l'informatique, n'a jamais été aussi productive à la maison, que depuis Janvier 2001 où j'ai finit de basculer sous Linux, venant de Windows (moi aussi, mais on m'accuserait d'être fanatique).
- Gnumeric est très loin devant le tableur d'OOo et au moins égal à Excel pour la plupart des utilisateurs professionnels non programmeurs (ma femme fait des petites macros pas trop compliquées)
[^] # Re: Abiword et Gnumeric
Posté par Franck Routier (Mastodon) . Évalué à 3.
C'est très puissant, et c'est surtout en passe de devenir une des interfaces standard vers les bases OLAP (au passage, à part Mondrian, en java, pas d'OLAP libre à l'horizon).
A mon avis, les alternatives à OOo sont très très loin de faire le compte. Du coup, oui pour un énorme travail sur GNU Classpath !
[^] # Re: Abiword et Gnumeric
Posté par MuadDib (site web personnel) . Évalué à 1.
Ces deux applications sont très bien faite.
Le seul reproche, c'est qu'il n'existe pas (à ma connaissance) de format de fichier ne provenant pas de la suite MS Office compatible entre les applications de bureautique libre.
Voila :-)
[^] # Re: Abiword et Gnumeric
Posté par Jiel (site web personnel) . Évalué à 2.
http://www.koffice.org/(...)
# gcj
Posté par fabb . Évalué à 10.
Si c'est pour faire référence au mail gcj de l'article de Newsforge, il date des premiers essais OOo/gcj. Au début de FC4 OOo 2.0 n'était programmé (dépendance avec le planning de OOo).
Le planning de OOo 2.0 a été précisé, la décision d'avoir OOo 2.0 dans FC4 a été prise, la mise au point gcj avec OOo a débuté.
Actuellement ça marche (j'ignore si tout est fonctionnel) ; xsl ; odbc.
C'est configuré avec :
%configure --with-java=gij --disable-epm --enable-libart --enable-gtk --enable-gnome-vfs --enable-openldap --enable-cups --enable-libsn --enable-fontconfig --disable-fontooo --with-system-libs --with-system-python --with-system-mozilla --with-system-boost --without-system-mspack --without-system-sablot --without-system-nas --without-system-sndfile --without-system-portaudio --without-fonts %{withlang}
La version 1.9.88 devrait arriver demain dans RawHide (dans le tuyau du cvs).
Donc "laborieux et difficile" c'est à voir.
[^] # Re: gcj
Posté par patrick_g (site web personnel) . Évalué à 9.
oui effectivement je m'appuyais la-dessus pour faire cette remarque.
Maintenant même si GCJ avance bien et que OO.o 2.0 builde sans problème y'a quand même des questions à se poser : quid de futures fonctions basés sur Java et que GCJ ne pourra pas supporter immédiatement ? quid de la mainmise de fait de Sun ? quid des problèmes de mémoire et de vitesse induits par Java sur des configurations modestes ?
De façon générale les décisions sur le futur d'OO.o dépendent d'une grande multinationale qui n'aime pas trop Linux....sachant qu'OO.o est devenu un étendard du libre c'est génant.
[^] # Re: gcj
Posté par Stéphane Traumat (site web personnel) . Évalué à 8.
Il est dévenu un étendard du libre grâce à la bonne volonté de SUN.. faut pas l'oublirer non plus. Depuis le début, on sait que ca vient de chez sun...
http://about.me/straumat
[^] # Re: gcj
Posté par fabb . Évalué à 2.
Excellente question. Ça dépend de la bonne volontée de Sun. Au pire il y aura un mini-fork (java ne se révolutionne pas tous les jours).
> quid des problèmes de mémoire et de vitesse induits par Java sur des configurations modestes ?
Ici ça marche correctement avec gcj. Tu devrais faire un essai. Gcj a maintenant un niveau tout a fait respectable (même s'il reste encore du boulot). Avec Gcj (et classgnu) ont fait touner assez confortablement le gros et 100 % java eclipse en version native. De plus eclipse utilise gij pour java (si tout est bien configuré).
Franchement, tu devrais faire un essai. Enfin, gcj a une marge de progression (vitesse et mémoire) beaucoup plus importante que le java "classique".
[^] # Re: gcj
Posté par Anonyme . Évalué à 2.
- comportement bizarre,
- plus de 250Mo de mémoire résiduelle
- lenteur (à ma très grande suprise).
Ca marchait à peu près bien quand je lançais eclipse (buildé gij hein) avec la JVM de sun, mais avec gij, rien à faire, totalement inexploitable...
Mais si t'as des tuyaux je suis prenneur.
[^] # Re: gcj
Posté par fabb . Évalué à 1.
Non. Il est par défaut dans FC4T1 (va être probablement déplacé dans Fedora Extra).
> - comportement bizarre
Je ne suis pas un utilisateur régulier d'éclipse. D'ailleurs je ne connais pas bien java. Je commence à m'y intéresser car il y a enfin une solution libre, viable, supporté (dans le contexte d'une distribution) et sans prise de tête. Eclipse compilé avec gcj est fournit par Red Hat depuis RHEL 3. Donc, ça ne doit pas être trop pourri.
> - plus de 250Mo de mémoire résiduelle
Depuis un chroot (le chroot c'est pour passer sous FC4T1), avec eclipse-ecj et eclipse-jdt + évidemment toutes les dépendances :
[admin@one ~]$ free
total used free shared buffers cached
Mem: 517176 498396 18780 0 9180 334116
-/+ buffers/cache: 155100 362076
Swap: 1702392 163816 1538576
[admin@one ~]$ eclipse &
[1] 31151
[admin@one ~]$ free # après le chargement d'Eclipse
total used free shared buffers cached
Mem: 517176 469124 48052 0 7440 259868
-/+ buffers/cache: 201816 315360
Swap: 1702392 163812 1538580
Temps de chargement de 28 secondes si rien est en cache (relativement vieux disque de 20 Go), 10 secondes si c'est en cache. Athlon XP 1600 - 512 Mo.
Sûr que ça doit bouffer plus de mémoire avec un projet ouvert.
> - lenteur (à ma très grande suprise).
Pas un foudre de guerre. Mais ça roule.
> mais avec gij, rien à faire, totalement inexploitable...
Je n'ai pas connaissance que Red Hat n'ait jamais tenté d'utiliser gij. En fait, ils voulait eclipse avec un java libre. Après quelques tests (et selon mes souvenirs car c'est vieu) ils se sont orienté vers gcj (compilation en natif d'Eclipse).
> Mais si t'as des tuyaux je suis prenneur.
Si c'est pour évaluer le potentiel, le mieux est d'installer FC4T1. Néanmoins je te conseille d'attendre FC4T2 car la T1, comme toute T1 qui se respecte, est assez bugguée.
[^] # Re: gcj
Posté par Tobu . Évalué à 4.
OOo a beau être en C++, il est déjà hors de portée des configurations modestes (50Mo au lancement).
# Si çà peut booster GCJ
Posté par syj . Évalué à 10.
Java est la technologie qui embauche le plus et qui reçoit le plus d'investissement de la part des entreprises.
Il est temps que cette techno coupe son cordon ombilical avec Sun qui devient trop encombrant.
[^] # Re: Si çà peut booster GCJ
Posté par Stéphane Traumat (site web personnel) . Évalué à 8.
Des projets libres tels que Hibernate, C-JDBC, Spring, JOnAS, XDoclet, XMLBean, JUnit (et JUnitScenario;)), Ant, Eclipse... font de Java une plateforme de développement génial! Il manque plus qu'à libérer la jvm!
http://about.me/straumat
[^] # Re: Si çà peut booster GCJ
Posté par fabb . Évalué à 1.
???
Ici je fais :
- yum install java-1.4.2-gcj-compat
Certe, certains programmes qui utilisent les dernières trouvailles brevetés de Sun ne marcheront pas. C'est à gcj de s'"imposer".
[^] # Re: Si çà peut booster GCJ
Posté par Stéphane Traumat (site web personnel) . Évalué à 5.
Au passage, le serveur d'applications J2EE JOnAS fonctionne sous gcj ;) merci redhat
http://about.me/straumat
[^] # Re: Si çà peut booster GCJ
Posté par Prae . Évalué à 2.
Mais au final, ce sont les admins qui s'emm^Hbète à gérer ce truc afin que la machine de production ne plante pas pour la 10ème fois dans le mois.
[^] # Re: Si çà peut booster GCJ
Posté par Stéphane Traumat (site web personnel) . Évalué à 4.
http://about.me/straumat
[^] # Re: Si çà peut booster GCJ
Posté par Prae . Évalué à 6.
Et les devs Java disent toujours que c'est un problème du à la plateforme ...
Mais bon, je dois me tromper aussi ...
[^] # Re: Si çà peut booster GCJ
Posté par crusher . Évalué à 1.
Les problèmes de perf rencontrés étaient toujours soit de notre faute (algorithme , bug, ...) soit un problème d'optimisation de requete sql.
[^] # Re: Si çà peut booster GCJ
Posté par VACHOR (site web personnel) . Évalué à 4.
Avec des programmes "maison" qui n'utilisent pas de librairies de daube, je peux vous assurer que la mémoire est stable, et y'a pas besoin de redémarrer le prog, ou reboot, même sous charge correcte ;-)
[^] # Re: Si çà peut booster GCJ
Posté par Houbaa . Évalué à 3.
Stef, intéressé
[^] # Re: Si çà peut booster GCJ
Posté par VACHOR (site web personnel) . Évalué à 1.
http://www.szegedi.org/articles/memleak.html(...)
http://www.szegedi.org/articles/memleak2.html(...)
Intéressants ... voir même à lire AMHA
[^] # Re: Si çà peut booster GCJ
Posté par NOULARD Eric (site web personnel) . Évalué à 2.
mémoire avec log4j, vu que je m'apprête à l'utiliser copieusement
et que ça m'arrangerait que mon serveur ne soit pas
"a redemarrer" périodiquement à cause de ça.
[^] # Re: Si çà peut booster GCJ
Posté par TitiMoby (site web personnel) . Évalué à 2.
Log4J est utilisé massivement dans tous les projets de mon entreprise et aucun souci de perf n'est apparu.
Et on est pas les champions des configs qui tuent.
[^] # Re: Si çà peut booster GCJ
Posté par kesako . Évalué à 7.
comme les technos MS a la fin des annees 90 apres l'apparition de NT4. Ouais . Je connais le resultat...
[^] # Re: Si çà peut booster GCJ
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 9.
Bon, ça fait parti du métier.... mais quand je vois un pote carreleur qui tourne à 17kf net par mois, et les salaire du moment en informatique, je regrette d'avoir choisi l'info, parce que le carreleur, s'il doit se tenir au courrant, il ne doit pas tout réapprendre tous les 3 ans au risque de finir au RMI ...
[^] # Re: Si çà peut booster GCJ
Posté par kesako . Évalué à 3.
Discute un peu avec un laveur de carreaux ... oui oui le laveur de carreaux là en bas avec sa mob et sa petite echelle ...
Tu sera surpris de son salaire ...
[^] # Re: Si çà peut booster GCJ
Posté par erik_lallemand . Évalué à 3.
De facon générale, je crois que "artisan" est une classe de métier très intéresante pour qui a du courage, et même sans avoir étudié longtemps. Je sais que les électriciens et les plombiers ne sont pas en reste question salaire. Les plombiers par chez moi ont d'ailleurs souvent des listes d'attente de quelques mois!
[^] # Re: Si çà peut booster GCJ
Posté par Jean-Baptiste Mayer . Évalué à 10.
Les développeurs Java sont depuis longtemps au RMI....
http://java.sun.com/products/jdk/rmi/(...)
(/me --->[] )
# Mais bon sang !
Posté par kesako . Évalué à 7.
Il veulent faire du blé , un point c'est tout .
Et pour eux ca consiste à promouvoir java pour vendre leurs machines et leurs services.
Rien d'anormal a cela , mais c'est comme ca. On dirait que certains croient au pere noel !
Au fil du temps et des ameliorations successives de java et des outils java , le fait que ce ne soit pas libre est devenu la seule et unique raison de pourquoi je n'y touche pas (*) et pourtant cette raison suffit a elle seule ! C'est dire !
(*): en tout cas pas de mon propre chef ! faut bien vivre... mais heureusement c'est rare.
[^] # Re: Mais bon sang !
Posté par Romain Guy . Évalué à 4.
Et si cela peut te rassurer un peu : http://www.sunsource.net/(...)
[^] # Re: Mais bon sang !
Posté par Croconux . Évalué à 6.
Tu veux dire qu'on peut contribuer bénvolement à un produit d'une société commerciale dont les certifications sont payantes ? Quelle grandeur d'âme.
[^] # Re: Mais bon sang !
Posté par Romain Guy . Évalué à 3.
[^] # Re: Mais bon sang !
Posté par herodiade . Évalué à 7.
Donc effectivement, l'appel à contribution de Sun, c'est plutôt gonflé.
[^] # Re: Mais bon sang !
Posté par fabb . Évalué à 1.
[^] # Re: Mais bon sang !
Posté par Florent Bayle (site web personnel) . Évalué à 4.
[^] # Re: Mais bon sang !
Posté par Romain Guy . Évalué à 0.
[^] # Re: Mais bon sang !
Posté par gc (site web personnel) . Évalué à 3.
Dans leur état actuel (Sparc, Solaris...) je pense surtout qu'ils cherchent à survivre :) ils sont pas mal dans la merde les petits.
[^] # Re: Mais bon sang !
Posté par sobek . Évalué à 1.
Oui, enfin en même temps, quand on voit la (très) rapide dégradation de ces produits et des services associés, il faut bien admettre qu'il l'on un peu cherché...
Pour le Sparc, il suffit de le mettre face à un Sparc64 (Fujitsu) pour voir la différence. Pour le système, Solaris10 sur une v20z est à pleurer comparé à un linux sur la même machine.
Et pour le service, une journée ouvrée pour avoir un début de réponse suite au plantage d'une machine "critique"...
Faut pas s'étonner que beaucoup quittent le navire : à coté, c'est pas forcemment plus fiable, mais c'est plus performant pour bien moins cher...
[^] # Re: Mais bon sang !
Posté par Antoine . Évalué à 4.
# Sun a toujours le mauvais rôle
Posté par Romain Guy . Évalué à 10.
Concernant les remarques sur le fait que Sun semble contrôler le projet, je suis très embêté. Sun a tout de même racheté StarOffice pour ouvrir le code source. Sun paye tout de même des développeurs pour travailler sur ce projet. Et si je ne m'abuse, ils fournissent une quantité non négligeable du travail. Il est amusant de voir que l'on critique Sun pour cela tandis que bien souvent on reproche à Sun de ne rien faire pour l'Open Source et le libre.
Bien sûr cela ne change rien au problème de la disponibilité de Java sur certaines plateformes (quoique tu peux l'avoir sur PowerPC avec MacOS X ;-) mais j'ai un peu de mal à lire ce genre de choses sans me dire qu'il y a quand même beaucoup beaucoup de râleurs dans cet univers (oui je sais c'est comme ça qu'on fait avancer les choses, etc.).
Enfin, personnellement, je continuerai à utiliser et à recommander OpenOffice.org.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Sun a toujours le mauvais rôle
Posté par fabb . Évalué à 2.
Le plug-in java avec gcj est prévu. Ça marche déjà mais il y a des problèmes de sécurité (ça marche comme un programme java et non comme une applet niveau sécurité). Red Hat envisage de corriger ça avec SeLinux. Peut-être pour FC4, mais plus probablement pour FC5.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Sun a toujours le mauvais rôle
Posté par fabb . Évalué à -1.
Avec rpm, tu n'as pas besoin de chroot.
Le portage vers amd64 est en cours. Probablement après la sortie de OOo 2.0.
> idem avec OsX ou il faut passer absolument par X11
A part tout critiquer, tu fais quoi ? Tu veux que Sun fasse tout. Ils ne peuvent pas. Perso, je suis très content avec OOo. OOo 2.0 est une belle amélioration.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Sun a toujours le mauvais rôle
Posté par qdm . Évalué à 3.
Mais gag, ils utilisent du Java partout pour arriver à faire de OO une appli plus ou moins native.
[^] # Re: Sun a toujours le mauvais rôle
Posté par fabb . Évalué à 4.
Tu peux utiliser python avec OOo.
Si tu veux remplacer le code java par du code C ou python, je crois que personne ne sera contre.
[^] # Re: Sun a toujours le mauvais rôle
Posté par Seazor . Évalué à 7.
Sun a trouvé un moyen d'aimer l'oss et le libre par OOo : en les faisant venir à java et en se rendant incontournable ! Ca c'est un point qui sert leurs interets.
L'un des avantages de base du libre est de pouvoir s'affranchir de dépendances obligatoires propriétaires.
Dans l'idéal, ca doit se faire à tous les niveaux (pas seulement l'OS).
Pour OOo c'est de moins en moins le cas dirait-on. Sun s'est débrouillé pour qu'on dépende de lui pour certaines fonctionnalités.
Et en cas de problème majeur, c'est là qu'on est content d'avoir au moins un standard pour le format de données utilisable par d'autres softs au moins aussi libres que OOo (voire plus).
[^] # Re: Sun a toujours le mauvais rôle
Posté par Cook Captain . Évalué à 10.
De toute manière le libre cela se mérite, il ne suffit pas de le décréter. C'est à la communauté libre de prendre son avenir en main pour produire un environnement libre en Java de qualité (et non de chialer/crier sur Sun qui ne fait pas comme elle le souhaiterait). Si certain, ici et ailleurs codaient autant qu'ils gueulaient, il est probable que bcp de projets libres seraient plus avancés.
[^] # Re: Sun a toujours le mauvais rôle
Posté par patrick_g (site web personnel) . Évalué à 6.
Si encore c'était pour avoir des trucs révolutionnaires et impossible à trouver ailleurs....mais là c'est un peu grotesque. Pour le module Base de données et sachant qu'on a toujours la possiblité d'avoir une base MySQL ou PostgreSQL ils auraient pu choisir SQLite comme base embarquée(petit et léger). Pour les wizards (assistants) de Writer quel est la nécessité de réécrire tout en Java ?
Ca ressemble vraiment à du forcing sans justification solide.
[^] # Re: Sun a toujours le mauvais rôle
Posté par TImaniac (site web personnel) . Évalué à 2.
Je rappelle que Java n'est jamais indispensable, il ne va pas apporter de feature qui tue à OOo. Par contre il peut grandement améliorer la productivité des codeurs (syntaxe, gestion mémoire, portabilité, libs, etc.)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Sun a toujours le mauvais rôle
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
http://about.me/straumat
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Sun a toujours le mauvais rôle
Posté par herodiade . Évalué à 3.
Mais justement, c'est la portabilité qui pose problème avec java! (enfin, entre autres problèmes).
Je m'abstiendrai de faire une blague pour ce qui concerne la "gestion de la mémoire" ;)
[^] # Re: Sun a toujours le mauvais rôle
Posté par TImaniac (site web personnel) . Évalué à 5.
Pour la gestion mémoire, il y a 2 types de raisonnement :
- ceux qui disent que la gestion mémoire est tellement importante qu'il ne faut pas laisser la machine s'en occuper.
- ceux qui disent que la gestion mémoire est tellement importante qu'il ne faut pas laisser le programmeur s'en occuper.
Reste que c'est une grosse perte de temps et de bugs potentiels, alors il faut mieux s'en passer quand c'est possible.
Après c'est pas pour autant qu'il ne faut pas avoir une gestion "économe" de la mémoire, en recyclant par exemple les objets ou en aidant le GC quand c'est possible (et pertinent).
[^] # Re: Sun a toujours le mauvais rôle
Posté par Antoine . Évalué à 9.
Non, justement, tous les messages disent le contraire. Le problème c'est que la JVM et les libs officielles (celles qui implémentent toute la spec) sont disponibles pour beaucoup moins de plateformes que, par exemple, gcc et la glibc.
Donc, oui, le C/C++ il faut le recompiler, mais l'avantage c'est qu'on a des outils libres pour le faire sur la plupart des plateformes.
[^] # Re: Sun a toujours le mauvais rôle
Posté par TImaniac (site web personnel) . Évalué à 2.
Donc portable sur autant de plateforme qu'il y a de compilateur C/C++ non ?
Donc en l'état actuel c'est plutôt embêtant effectivement ce choix de Java sans avoir semble-t-il tenu compte des VM libres (surtout pour un projet libre, j'avoue ne pas vraiment capter sur ce coup là), mais si GCJ tient ses promesses... Wait & See FC4.
[^] # Re: Sun a toujours le mauvais rôle
Posté par Antoine . Évalué à 2.
Il y a quand même un certain nombre de personnes qui semblent dire que gcj et les bibliothèques libres n'implémentent pas la totalité des specs Java. Tu devrais peut-être argumenter sur ce point, si tu penses que c'est faux...
[^] # Re: Sun a toujours le mauvais rôle
Posté par TImaniac (site web personnel) . Évalué à 2.
Je voulais juste dire que niveau portabilité si gcj supporte correctement OOo, il suffit que gcj soit porté et le tour est joué.
[^] # Re: Sun a toujours le mauvais rôle
Posté par herodiade . Évalué à 8.
Quand je disait portable, je ne parlais pas du "langage Java" mais de de la seule implementation complete qui est accessoirement l'environement nécessaire pour faire tourner Ooo (les hacks red hats ne sont encore que des hacks), à savoir l'environement Java de Sun.
Exemples: Pas de JDK 1.5 sous OpenBSD (et je crois qu'il faut de l'émul linux pour les autres BSD). Pas de JDK 1.5 pour GNU/Linux sur mips (ou autre plateforme non x86/amd64). etc. Donc oui, ça n'est pas portable, du tout. N'en déplaise aux marketeux de chez Sun.
Sur ce point on peut râler, car Sun ne permet même pas aux devs de LL de faire ces portages.
Pour reprendre ta comparaison, on trouve des compilos C et C++ pour à peu pret toutes les plateformes existantes.
Et des interpreteurs python aussi (qui, au passage, est aussi incorporé dans Ooo via PyUNO), lequel aurait été un choix moins problématique, s'ils cherchent des outils de dev rapide (et une gestion de la mémoire automatique).
Pour le moment, gcj n'est pas lui même parfaitement "portable" (mais là, j'ai confiance, ça ne tardera pas).
Pour revenir au sujet, le problème (outre toute considération technique) c'est qu'ils ont choisis la plateforme java la moins libre et la moins portable qu'ils pouvaient. Il n'est pas inutile que leurs utilsateurs leur donne un feedback pour faire savoir que ces détails ont leur importance.
[^] # Re: Sun a toujours le mauvais rôle
Posté par fabb . Évalué à -1.
aussi fortement ?
Où tu vois ça ?
Ça ne conserne que des extensions. Libre a chaqu'un de les réécrire en autre chose que Java.
Sun a décidé d'utiliser Java (techniquement, il semble qu'ils n'ont pas tord). En plus de proposer OOo sous GPL, on ne va pas leur imposer les méthodes de développement. Si le libre n'est pas satisfait, c'est à lui de prendre l'initiative (par exemple maintenir une version qui réimplémente les fonctionnalités actuellement en java).
En te caricaturant, tu me fais passer à ceux qui gueulent car Linux n'est pas codé en C++. Fais le, c'est libre.
[^] # Re: Sun a toujours le mauvais rôle
Posté par TImaniac (site web personnel) . Évalué à 2.
Ben, ça c'est vite dit, tout dépend de ce qui va arriver aux brevets logiciels en Europe...
C'est d'ailleur ca que je trouve bizzare, MS et Sun passe des accords de brevets pour ne pas s'attaquer mutuellement concernant leurs suites Office, donc je suppose qu'il doit y avoir matière à négociation (et donc brevets)... Mais d'un autre côté Sun a mis OOo sous GPL, dois-je supposer que les brevets en question ne concerne que StarOffice ? (les brevets étant incompatible avec la GPL, et Sun doit avoir pleinement connaissance de l'existance de brevets, chez Sun ou MS, puisqu'ils les "échangent")
A vrai dire j'ai vraiment du mal à tout capter. En tout cas les brevets logiciel c'est vraiment dla merde :)
[^] # Re: Sun a toujours le mauvais rôle
Posté par fabb . Évalué à 1.
Par contre, la jvm de Sun n'est pas libre. Donc s'il y a des brevets dedans, gcj ne peut pas les utiliser.
OOo (GPL), ce n'est pas java. OOo utilise java. Donc OOo peut utiliser des brevets de Java. Le problème est là. Le jour venu, il y aura un fork (limité) pour ne pas utiliser les brevets de Java et pouvoir utiliser OOo avec gcj. Les sources java (fichiers .java) d'OpenOffice peuvent avoir des brevets. Le fait qu'ils soient sous GPL (sur décision de Sun) fait que le logiciel libre peut les utiliser (les fichiers .java d'OpenOffice).
[^] # Re: Sun a toujours le mauvais rôle
Posté par TImaniac (site web personnel) . Évalué à 2.
oué mais en supposant que ce soit des brevets MS ? (ce qui étant donné l'échange de brevets n'est pas impensable)
Et même en supposant que ca soit Sun, pourquoi ce serait les brevets qui tout à coup se retrouverait invalidés ? Pourquoi ne serais-ce pas plutôt la licence qui serait invalidée ? Franchement la seule solution que je vois c'est que Sun utilise dans StarOffice des brevets MS (ce qui étant donné les nombreux points communs avec MS Office n'est pas impensable), et qu'ils préfèrent ne rien dire et ne pas changer la licence concernant OOo (d'ailleur que deviendrait la légalité des licences passées ?)
Par contre, la jvm de Sun n'est pas libre. Donc s'il y a des brevets dedans, gcj ne peut pas les utiliser.
T'as des infos sur les brevets en question ? (genre la liste)
OOo (GPL), ce n'est pas java. OOo utilise java. Donc OOo peut utiliser des brevets de Java.
Tiens content de voir qu'il n'y a bien aucun lien juridique entre l'utilisation et l'implémentation (sauf contrat explicite entre l'implémenteur et l'inventeur) ;)
[^] # Re: Sun a toujours le mauvais rôle
Posté par fabb . Évalué à 1.
Alors Sun n'a plus le droit de diffuser OpenOffice (CF la licence GPL).
> Et même en supposant que ca soit Sun, pourquoi ce serait les brevets qui tout à coup se retrouverait invalidés ?
Il sont invalidé pour les sources que Sun a mis sous GPL. Je pensais avoir été clair. Relis.
> Pourquoi ne serais-ce pas plutôt la licence qui serait invalidée ?
Car Sun est le propriétaire des brevets *et* de la licence. C'est Sun via la licence qu'il a lui même choisi qui rend le code libre (du moins pour les éléments qu'il dispose ; c-à-d les brevets Sun qui seraient utilisé dans des sources GPL de Sun).
> T'as des infos sur les brevets en question ? (genre la liste)
Non. Je sais que c'est une préoccupation de gcj. RMS a aussi dit que certaines des dernières fonctionnalités de java ont des brevets. Que gcj n'implémentera pas ces brevets pour rester libre.
> Tiens content de voir qu'il n'y a bien aucun lien juridique entre l'utilisation et l'implémentation
Franchement, t'es lourd. Réfléchis un peu. Et j'aimerai que tu me dise où j'ai dit que l'utilisation et l'implémentation sont liés juridiquement ?
Bonne chance. Je ne l'ai jamais dit car ça dépend des conditions de "vente" de l'utilisation (payant, sous condition, libre, libre seulement pour l'implémentation, libre seulement pour la lecture, etc) du brevet.
J'ai dit, et je répète car t'es dure de la feuille :
- Libre utilisation implique libre implémentation
- Libre implémentation n'implique pas libre utilisation
L'implémentation n'est qu'une des utilisations.
[^] # Re: Sun a toujours le mauvais rôle
Posté par TImaniac (site web personnel) . Évalué à 1.
Nan mais tu as été très clair j'ai bien compris, mais d'un point de vue juridique je ne vois pas comment une licence peut prendre le dessus sur un brevet logiciel : la licence s'a s'annule facilement, alors que bon un brevet ca reste un truc déposé par un organisme et tout... Enfin je dis ça mais tu as peut être raison. Reste qu'il manque à mon goût encore trop de jurisprudence en matière de licence, notamment GPL, parcque bon, si on se cantonne par exemple au droit pénal français, cette licence n'est même pas valable :-/
RMS a aussi dit que certaines des dernières fonctionnalités de java ont des brevets.
Oué bah oué mais c'est rigolo, c'est comme pour un autre projet (dont j'ai pas besoin de te citer le nom), on parle de brevets mais on n'en voit pas la couleur... Ils doivent bien être publiés quelque part non ? Je suppose que la team gcj y a accès pour savoir quelles techniques ils n'ont pas le droit d'utiliser non ?
Et j'aimerai que tu me dise où j'ai dit que l'utilisation et l'implémentation sont liés juridiquement ?
Nan mais c'était juste pour la vanne, restons-en là et parlons de Java :)
[^] # Re: Sun a toujours le mauvais rôle
Posté par Gniarf . Évalué à 10.
http://software.newsforge.com/software/05/03/22/204244.shtml?tid=93(...)
ils sont parfaitement au courant des caractéristiques techniques et des avantages et contraintes relatives à C++ et Java, et du rôle complexe que Sun tient dans ce petit monde : mécène, bienfaiteur, dictateur bienveillant ou pas, croquemitaine.
mais pour certaines fonctionnalités, il s'est trouvé des développeurs Java pour se mettre au boulot, et pas de développeurs C++. tout simplement :
"And sometimes, Schönheit adds, "this simply means that there is a Java developer who can spend time on a project, and no C++ developer who can."
alors au lieu de râler aujourd'hui comme de bêtes utilisateurs finaux et autres consommateurs de logos & sonneries, il fallait répondre à l'appel quand ils ont eu besoin de vous. le Libre, c'est fait pour ça aussi.
NB : cet argument du manque de bras pourrait difficilement justifier l'ajout de nouveaux langages et dépendences sans vrais rapports avec la choucroute au projet existant, mais il y avait déjà des sales gros bouts en Java dedans. par ailleurs, j'ai une dent féroce contre les nombreuses faiblesses de Java, donc on pourra difficilement m'accuser de bienveillance à son égard. mais l'argument du monsieur se tient : à un moment il a fallu coder des trucs, et visiblement seul un développeur Java a bien voulu s'en occuper.
[^] # Re: Sun a toujours le mauvais rôle
Posté par patrick_g (site web personnel) . Évalué à 7.
A première vue cet argument semble solide.
Mais tout à coup on se demande en quoi cela s'applique à une réécriture complète des wizards de Writer ?
Autant pour developper de nouvelles fonctions on fait avec les compétences du mec qui est disponible mais la ce n'est pas du tout le cas : on réécrit un truc qui existe déja et qui ne pose pas de problèmes en en faisant un problème potentiel.
Pareil pour Base : SQlite existait déja et il sont allé chercher, comme par hasard, une base en Java.
Donc pour moi l'argumentation du simple hasard (oh y'avait juste un seul volontaire et il connaissait que Java) est eminement suspecte.
[^] # Re: Sun a toujours le mauvais rôle
Posté par fredix . Évalué à 4.
C'est pas compliqué à comprendre. Sun désire diffuser toujours plus leur technologie java. OOo est un superbe moyen de l'imposer petit à petit ...
Et à leur place je ferais pareil, mais à la place du Libre (en supposant qu'il ait une conscience unique) je me concentrerais sur abiword...
[^] # Re: Sun a toujours le mauvais rôle
Posté par patrick_g (site web personnel) . Évalué à 7.
Si toutes les suites bureautiques libres soutiennent OpenDocument alors le choix des utilisateurs sera vraiment libre (en fonction des qualités propres des softs).
[^] # Re: Sun a toujours le mauvais rôle
Posté par herodiade . Évalué à 3.
Personellement je suis très surpris qu'ils n'aient pas au moins testé leur code sur un environement java libre : il ne s'agit pas de webdesigners du dimanche (à qui on peut passer l'utilisation de features "ie-only"), mais de developpeurs expérimentés. Et dont je croyai qu'ils connaissaient les préocupations et problèmes des utilisateurs de LL.
Si nous passions ça sous licence, il est à peut près certain qu'aucun effort n'aurait été fait pour conserver la compatibilité gcj, si durement acquise, dans les versions ultérieures.
Et au passage le fait que ça marchouille avec le gcj de FC4 (et combien de patches ?) n'est pas satisfaisant: ça necessite nottament de disposer de la chaine gcj de gcc 4.0 (béta), du classpath récent (béta) etc.
En somme, la réaction des utilisateurs de LL est cohérente avec ce que recommande Stalman:
http://www.gnu.org/philosophy/java-trap.html(...)
[^] # Re: Sun a toujours le mauvais rôle
Posté par fabb . Évalué à 4.
J'ai une bonne nouvelle, ça marche déjà avec gcj (url déjà passé ici) :
http://www.spindazzle.org/green/index.php?p=43(...)
Je l'ai ici, et ça marche !
> Et au passage le fait que ça marchouille avec le gcj de FC4
Ça ne marchouille pas, ça marche !
Va sur les mailing Fedora pour connaitre les feedback ou vas faire un tour sur le bugzilla de Red Hat pour avoir un état des lieux :
http://bugzilla.redhat.com/(...)
> et combien de patches ?
Un patch ridicule.
[admin@one SOURCES]$ cat workspace-gcj4.patch | diffstat
bin/deliver.pl | 0
config_office/configure.in | 21 +++++++++++++++++++++
config_office/set_soenv.in | 8 +++++++-
inc/settings.mk | 0
solenv/bin/deliver.pl | 22 ++++++++++++++++++++++
solenv/inc/settings.mk | 5 ++---
6 files changed, 52 insertions(+), 4 deletions(-)
> ça necessite nottament de disposer de la chaine gcj de gcc 4.0 (béta), du classpath récent (béta) etc.
Et alors ? OOo 2.0, nécessite OOo 2.0 en version beta actuellement.
gcj 4.0 est utilisé depuis FC3. gcc 4.0 est en "open for regression fixes only".
> En somme, la réaction des utilisateurs de LL est cohérente avec ce que recommande Stalman:
La réaction des utilisateurs du LL serait de "sauter" sur gcj 4.0.
> http://www.gnu.org/philosophy/java-trap.html(...)
On peut se demander si tu as lu le lien :
gcj c'est bon, mangez en (au lieu de faire des critiques à deux balles).
PS : Avant de poster des commentaires, lisez les commentaires déjà postés.
[^] # Re: Sun a toujours le mauvais rôle
Posté par herodiade . Évalué à 2.
>
> J'ai une bonne nouvelle, ça marche déjà avec gcj (url déjà passé ici)
Ça marche _après_ patchage d'Ooo et ajustements de classpath etc. Donc je maintient, le code tel qu'ils l'ont fournis n'avait très certainement pas été testé sur des environements libres.
S'ils continuent sur cette voie, il faura repatcher tout son système à chaque mise à jour d'Ooo ? Tous passer à Fedora Core (c) et installer des versions bétas de la suite gcc ? Très forts les prosélytes de java et fedora.
> Un patch ridicule.
Je parlai de l'ensemble des modifications qu'il a fallu pour le faire tourner. Y compris les modifications de gcj et de classpath.
> On peut se demander si tu as lu le lien :
> "The reliable way to avoid the Java Trap is to have only a free implementation of Java on your system"
Citation tronquée et détournée. L'ensemble du document dit qu'il faut faire comprendre aux devs java qu'ils doivent _developper_ avec une implementation libre de java sur le systeme. La paragraphe que tu cite est:
"The reliable way to avoid the Java Trap is to have only a free implementation of Java on your system. Then if you use a Java feature or library that free software does not yet support, you will find out straightaway, and you can rewrite that code immediately."
Ce qui n'a pas été fait.
> Avant de poster des commentaires, lisez les commentaires déjà postés.
Le fait que je n'ai pas le même avis sur toi ne doit pas te faire déduire que je n'ai pas lu les commentaires ...
En lisant le reste de mon commentaire, tu a très bien compris que j'avait lu le tien.
[^] # Re: Sun a toujours le mauvais rôle
Posté par fabb . Évalué à 4.
> Ça marche _après_ patchage d'Ooo
Linux est patché, la libc est patché, etc... Ton argument c'est 0, surtout que OOo 2.0 est en phase beta/rc.
> ajustements de classpath etc.
gcc :
[admin@one SOURCES]$ cat gcc4-java-nomulti.patch | diffstat
configure | 3 +++
configure.ac | 4 ++++
2 files changed, 7 insertions(+)
Fichtre, aucun ajoutement de classpath spécifique à OOo.
> Donc je maintient, le code tel qu'ils l'ont fournis n'avait très certainement pas été testé sur des environements libres.
Et alors ?
Sun s'occupe de leur java, le libre s'occupe de son java. Le libre peut bien ce sortir les doigts du cul.
> Tous passer à Fedora Core (c) et installer des versions bétas de la suite gcc ?
Et pourquoi tu n'installes pas gcc3 en parallèle avec gcj 4.0 ? C'est fait les doigts dans le nez avec FC3. Possible que OOo 2.0 soit disponible pour FC3 car le fichier spec intègre gcc4 en compilateur par défaut (FC4) ou gcc3 en compilateur par défaut (FC3).
http://cvs.fedora.redhat.com/viewcvs/devel/openoffice.org/openoffic(...)
> Très forts les prosélytes de java et fedora.
M'enfin, tu me fais rire. On sait déjà comment ça va se terminer. T'as un troupeau d'anti-RH qui va gueuler (c'est leur façon de promouvoir leur distrib), puis 3 semaines après ça va être dans leur distribution et il vont fermer leur gueule. Ça se passe toujours comme ça.
Si tu ne veux pas utiliser gcj qui est libre, t'es libre. C'est ton choix. Mais inventes pas des trucs à la con.
> Je parlai de l'ensemble des modifications qu'il a fallu pour le faire tourner.
Quelles modifications ? Les modifications pour améliorer gcj ? Oui, il y en a des tonnes et c'est tant mieux. Tu veux quoi ? Que gcj reste figé et qu'on soit obligé d'utiliser un jvm proprio ?
Pas moi.
> Ce qui n'a pas été fait.
Ce qui a été fait par Red Hat. Donc l'OOo de Sun, modulo un patch rididule de 50 lignes respecte à la lettre la requête de RMS.
Je ne suis pas un dingue de Sun (parqu'ils sont pro-brevets). Mais j'en ai archi-marre des gens qui gueulent sur Sun pour des problèmes qui ne sont pas lié à Sun. Si gcj sucks, c'est un libre d'améliorer gcj. Si Sun veut y participer, tant mieux.
Les gens sont complètement incohérent. Si une boîte participe trop, ils gueulent. Si elle participe peu, ils gueulent encore. Faudrait savoir ce que vous voulez.
Deuxième truc qui me gave c'est le "ouais mais c'est patché". Qu'es-ce que c'est que cette argument à la con ?
Quand Ubuntu patch, qui se plaind ? Personne et c'est très bien.
Quand un noyau sort, des gens parlent du patch mm, du patch de mise à jour IDE ou USB, des patchs Red Hat ou Mandrake, du patch xen, du patch pour avoir reiser 4, etc...
Personne n'y trouve à redire car c'est ça le logiciel libre. Laisser à chaqu'un la liberté de bosser.
La communauté qui veut du java libre, bosse sur gcj. Parfois ça peut-être fait en upstream (c'est le cas pour 99,9% des améliorations de gcj), parfois ce n'est pas possible ou approprié.
[^] # Re: Sun a toujours le mauvais rôle
Posté par herodiade . Évalué à -3.
En upstream. Tu es débile ou tu fait semblant ?
[^] # Re: Sun a toujours le mauvais rôle
Posté par fabb . Évalué à 1.
Donc, selon toi, il ne faut pas améliorer gcj en upstream ni avec des patchs.
Ben on n'est pas sorti de l'auberge.
Tu connais des modifications de gcj/classpath qui sont spécifiquement faites pour supporter OOo 2.0 ?
Je ne suis pas débile et toi t'es très con. Tu veux que gcj n'évolue pas.
[^] # Re: Sun a toujours le mauvais rôle
Posté par herodiade . Évalué à 2.
De mémoire, on n'a jamais vu une telle réaction pour le choix d'un autre langage dans un LL.
Maintenant les choses sont plus claires.
[^] # Re: Sun a toujours le mauvais rôle
Posté par Cook Captain . Évalué à 2.
> De mémoire, on n'a jamais vu une telle réaction
> pour le choix d'un autre langage dans un LL.
J'aurais bien été tenté par ksh88...
# Commentaire supprimé
Posté par Anonyme . Évalué à -4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: arreter de contribuer et d'envoyer de rapport de bug pour OOo
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
Tu n'as pas eu le temps de lire la news et les commentaires ?
Néanmoins ce ne sont que des fonctionnalités annexes et quelque peu périphériques
et
Actuellement ça marche (j'ignore si tout est fonctionnel) ; xsl ; odbc.
C'est configuré avec :%configure --with-java=gij --
http://about.me/straumat
[^] # Re: arreter de contribuer et d'envoyer de rapport de bug pour OOo
Posté par fabb . Évalué à 2.
C'est principalement Sun qui bosse sur OOo. Donc, il font ce qu'ils veulent. Ce qui n'empêche pas qu'on peut ne pas aprécier certaines décisions.
> dans des composants essentielles
Lesquels puisque que OOo peut encore marcher sans java ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: arreter de contribuer et d'envoyer de rapport de bug pour OOo
Posté par fredix . Évalué à 3.
Tu peux le faire en utilisant par exemple la bibliothèque multimédia gstreamer ... Mais ce n'est évidement pas dans l'intérêt de Sun qui veut promouvoir Java -> "sans java point de salut".
# Le problème: c'est Java ou Sun?
Posté par salvaire . Évalué à 8.
Sur le papier l'idée est séduisante. Langage OO relativement propre exécuté par une machine virtuelle. Perl, Python, Ruby ou Ocaml n'ont pas les problèmes de Java tel que: API mammouthesque, lourdeur/lenteur, licence problématique. Sun et sa stratégie ne serait il pas le réel problème de Java? Et peut être le futur de Open Office?
J'ai programmé une seule fois en Java avec l'api Swing sur un athlon 1.3Ghz. La seule opinion qu'il m'en reste, c'est qu'il suffisait de bouger la souris rapidement pour se faire une idée des performances lamentables de Java Swing ... Depuis, Java me donne des frissons. Open Office 1 est déjà un mammouth, qu'est que ça va être avec Java ...
[^] # Re: Le problème: c'est Java ou Sun?
Posté par salvaire . Évalué à 2.
[^] # Re: Le problème: c'est Java ou Sun?
Posté par Romain Guy . Évalué à 3.
Java sur le desktop a encore du chemin à faire mais c'est viable.
[^] # Re: Le problème: c'est Java ou Sun?
Posté par Bouiaw . Évalué à 1.
[^] # Re: Le problème: c'est Java ou Sun?
Posté par Romain Guy . Évalué à 1.
[^] # Re: Le problème: c'est Java ou Sun?
Posté par Bouiaw . Évalué à 1.
Pour du développement multi-plateforme, moi je trouve que la plateforme Mozilla 2.0 + Python par exemple, ça promet bien plus que Swing.
[^] # Re: Le problème: c'est Java ou Sun?
Posté par Houbaa . Évalué à 2.
Ok, Swing c'est lent (et encore... ça dépend comme on code), mais au moins c'est rapide à coder. C'est dommage mais c'est la vie...
[^] # Re: Le problème: c'est Java ou Sun?
Posté par ndesmoul . Évalué à 3.
Netbeans (swing) est par exemple bien plus réactif que Eclipse (SWT/GTK) sous Linux.
De plus il semble que le support de Swing avec gcj/classpath avance assez rapidement grâce à RedHat. Le rendu utilisant GTK...
Il est d'ailleur possible d'utiliser directement GTK.
Du coup l'intérêt de SWT me semble de plus en plus limité. C'est une stratégie bizarre d'IBM qui semble pousser SWT alors qu'il a participé à l'élaboration de Swing.
Pour revenir à la discussion initiale, vu que bientôt on aura une implémentation correcte et libre de Java, je ne vois vraiment pas pourquoi on fait tout un fromage autour de l'utilisation de Java avec OpenOffice. Java permet un developpement plus rapide qu'en C et C++ sans sacrifier les performances (par contre la mémoire...). Si les développeurs considèrent que c'est un bon choix technique, je ne vois pas où est le problème.
Par contre les perfs de Gcj face aux JVM récentes de SUN ou d'IBM c'est pas encore ça... [! troll detected...!]
[^] # Re: Le problème: c'est Java ou Sun?
Posté par TImaniac (site web personnel) . Évalué à 3.
Moi y'a un seul truc qui me dérange : ok on aura tôt ou tard un OOo utilisable sous Linux avec gcj, mais sous quid sous Windows ? Y-a-t-il d'autres JVM libres qui seront supportés sous Windows ?
[^] # Re: Le problème: c'est Java ou Sun?
Posté par qdm . Évalué à 3.
[^] # Re: Le problème: c'est Java ou Sun?
Posté par Cook Captain . Évalué à 2.
[^] # Re: Le problème: c'est Java ou Sun?
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
quand à l'api, elle est énorme mais permet de tout faire
http://about.me/straumat
[^] # Re: Le problème: c'est Java ou Sun?
Posté par Yusei (Mastodon) . Évalué à 3.
[^] # Re: Le problème: c'est Java ou Sun?
Posté par fbilhaut . Évalué à 6.
Et donc tu te sens autorisé à faire des commentaires à l'emporte pièce sur ce langage, alors que de ton propre aveu tu ne le connais pas ou presque. Bien bien...
[^] # Re: Le problème: c'est Java ou Sun?
Posté par salvaire . Évalué à 1.
- Il y a 2 ans, si tu redimensionais très rapidement un hello word ou à peine plus compliquer, ça suivait pas.
- Et j'ai vue très récemment un crash magnifique de Maple 9.2. Vue le nombre de processus java, on dirait qu'il créé un thread par pixel!
J'ai rien contre Java. Je critique juste le fait de vendre des logiciels inutilisables.
[^] # Re: Le problème: c'est Java ou Sun?
Posté par Sebastien . Évalué à 0.
Quand le physicien des particules se fait choper par un informaticien sur une question d'informatique, le physicien des particules se tait humblement :P
Ou sinon, moi non plus j'ai rien contre Java, d'ailleurs je suis sur que si ROOT avait ete ecrit en Java, ce serait moins de la merde (et je pese mes mots) !
PS: DEA powa ;)
[^] # Re: Le problème: c'est Java ou Sun?
Posté par boubou (site web personnel) . Évalué à 3.
L'api de Perl est mammouthesque, comme tu dis, par qu'on peut tout faire avec Perl. C'est la même chose en Java. Je ne connais pas assez Python et Ruby pour comparer, mais je doute qu'on puisse faire autant de chose qu'en Java si l'API est significativement plus petite. Par contre, je suis certain qu'on peut faire moins de chose en OCaml. Attention, qu'on se comprenne bien, je ne parle pas ici de théorie, je parle d'API disponibles pour faire des choses évoluées (parler à un serveur SMTP, parser un mail, parser du XML, parler web services, etc.) sans avoir à se palucher tout à la main.
lourdeur/lenteur
Lourdeur, soit, Java demande beaucoup de mémoire. Lenteur, n'importe quoi. Documente toi, utilise une JVM moderne et une mémoire correctement dimensionnée, et tu verras que Java n'est pas lent.
licence problématique
Beaucoup plus que Perl/Python/etc., c'est vrai. Mais est-ce que tu sais de quoi tu parles ou est-ce que tu ne fais que répéter les trolls standards ?
[^] # Re: Le problème: c'est Java ou Sun?
Posté par Gniarf . Évalué à 5.
oserais-je émettre l'hypothèse que tu peux difficilement prétendre avoir appris à programmer correctement en Java et à utiliser correctement les JFC (autre nom de Swing) en "une seule fois" ?
# O1.net : Java s'ouvre encore plus à l'open source
Posté par pini . Évalué à 0.
http://fr.news.yahoo.com/050329/44/4c558.html(...)
[^] # Re: O1.net : Java s'ouvre encore plus à l'open source
Posté par Bruno Ethvignot (site web personnel) . Évalué à 0.
[^] # Re: O1.net : Java s'ouvre encore plus à l'open source
Posté par R4f . Évalué à 3.
C'est très étonnant car justement c'est souvent le contraire qui se produit : si un éditeur (propriétaire) fait un super produit, il finit souvent par copié par des développeurs du Libre...
Lire à ce sujet : Fear For Forking (la peur du fork) http://linuxmafia.com/faq/Licensing_and_Law/forking.html(...)
[^] # Re: O1.net : Java s'ouvre encore plus à l?open source
Posté par Pierre Jarillon (site web personnel) . Évalué à 7.
Excellent document écrit dans un anglais facile à lire.
Il serait urgent de le faire lire aux dirigeants de SUN (même par la contrainte;-).
Je pense que si SUN avait mis Solaris sous GPL il y a 10 ans, il aurait pu le sauver. Maintenant c'est trop tard, leur demi ouverture du code n'intéresse plus grand monde. J'ai bien l'impression qu'ils vont réaliser la même erreur avec java.
Les dirigeants des grandes sociétés n'ont pas encore compris que le monde était en train de changer profondément et que les raisonnements appris dans leurs manuels étaient obsolètes.
Il semble que seul IBM l'ait compris. Leur arrogance du début des années 1990 a failli leur faire mettre la clef sous la porte tellement ils étaient sûrs de leur business model. Ils ont aussi perdu sur OS/2 qui aurait pu être un sérieux concurent de Windows car il était bien meilleur. Pour en avoir baissé le prix tardivement (Warp fut un échec), et faute de l'avoir ouvert et ouvert à temps, il est maintenant moribond.
Allez Mr Sun, n'ayez pas peur, mettez le code java sous GPL. Il est peut être encore temps, mais chaque jour d'attente vous rapproche inexorablement du jour où vous direz "too late..." et il sera bien entendu trop tard.
[^] # Re: O1.net : Java s'ouvre encore plus à l'open source
Posté par skeespin (site web personnel) . Évalué à 2.
Voila un autre qui n'aime pas Java :op
[^] # Re: O1.net : Java s'ouvre encore plus à l'open source
Posté par Cook Captain . Évalué à 1.
# Inquetudes ... Peut etre que ...
Posté par Guillaume . Évalué à 5.
Peut etre que le plus inquetant dans tout cela ca n'est pas trop le fait que certains modules OpenOffice soient en Java , mais le fait que cela va peut etre conduire certains contributeurs à arreter leur collaboration.
Ce qui est inquetant , à mon sens, c'est plus la dillution de l'effort. Ok ca ne va plus comme on l'entend alors on bouge sur un autre pojet ? . Et pourquoi pas un autre projet parallele ? . C est un cas de figure qui se repete de plus en plus.
Je pense que si on veut avoir des produits capables de rivaliser (et aussi les depasser) avec des applications commerciales la solution est plus la cohesion autour d'un ou deux grands projets afin de pouvoir proposer une reelle alternative (cf dev Mozilla / Firefox).
Bien sur il ne s'agit la que d'un point de vue parmis tant d autres. ;) .
Merci de me lire.
Slts
Guillaume.
[^] # Re: Inquetudes ... Peut etre que ...
Posté par R4f . Évalué à 4.
On ne peut pas faire coder des gens qui ne veulent pas coder, donc il faut faire avec leurs compétences ET leur caractère. Certains vont s'en plaindre, mais ce sont généralement pas ceux qui sont les plus grands contributeurs du Libre, ni les plus grands bénévoles de tous les temps...
De plus, ce qu'il faut voir pour de grands projets comme OOo, c'est que de nombreux contributeurs contribuent en étant employés dans des entreprises. Si ces entreprises ne voient pas d'un bon oeil l'omniprésence de SUN (via Java), elles vont peut-être aussi accélérer ce mouvement de rejet.
[^] # Re: Inquetudes ... Peut etre que ...
Posté par Romain Guy . Évalué à 0.
# KDE et QT
Posté par Jeanuel (site web personnel) . Évalué à 10.
L'expérience à montré alors que intransigeance était la meilleure politique : l'industriel assoupli sa politique de peur de se voir exclure complètement et dépassé par un projet concurent.
# java suçe.
Posté par stork . Évalué à -10.
Il n'y aura jamais de JVM libre performante, baser un projet de grande envergure libre là dessus est une connerie en barre.
[^] # Re: java suçe.
Posté par Franck . Évalué à -1.
[^] # Re: java suçe.
Posté par stork . Évalué à -7.
[^] # Re: java suçe.
Posté par Stéphane Traumat (site web personnel) . Évalué à -1.
http://about.me/straumat
[^] # Re: java suçe.
Posté par collinm (site web personnel) . Évalué à 0.
j'espère que tu utilises un bios libre pour raconter autant de connerie
www.solutions-norenda.com
# Je me disais aussi...
Posté par Manwe . Évalué à 2.
Je comprend mieux maintenant.
Plus il y a de Java, plus c'est lourd à charger...
Je trouve Java performant essenciellement sur les serveurs, les applications clientes sont peu populaires, peut être à cause du temps de chargement du JRE.
Les performances du 1.5 sont-elle vraiment meilleures ? de beaucoup ? On a que la 1.4.2 nous en Prod.
L'idéal serait un XULOffice.
Un programme qui manipule du XML (qui est une technologie Web) serait facile et rapide à développer avec une technologie Web.
En plus, on pourrait l'utiliser à distance dans Firefox à terme peut être.
Une fois XULRunner terminé, l'occupation mémoire sera optimisée et on disposera d'une plateforme de développement qui méritera largement d'avoir sa suite Office..
[^] # Re: Je me disais aussi...
Posté par Romain Guy . Évalué à 3.
[^] # Re: Je me disais aussi...
Posté par Dring . Évalué à 2.
-Dsun.java2d.opengl=true
Plus d'infos : http://java.sun.com/j2se/1.5.0/docs/guide/2d/new_features.html#ogl(...)
[^] # Re: Je me disais aussi...
Posté par Bouiaw . Évalué à 1.
[^] # Re: Je me disais aussi...
Posté par spongurex . Évalué à 2.
Un nom ? Une URL ?
J'ai cherché un peu, je n'ai trouvé que mozOffice : http://mozoffice.sourceforge.net(...)
Mais le projet semble mort (dernière nouvelle : 06/11/2002)
[^] # Re: Je me disais aussi...
Posté par Manwe . Évalué à 0.
Par contre, une URL et je me prosterne... :)
[^] # Re: Je me disais aussi...
Posté par fabb . Évalué à 1.
T'es de mauvaise fois ou alors tu as déjà une JRE sur ta bécane. Actuellement il n'y a que Fedora qui a OOo/gcj (c'est en beta/test).
Pour avoir testé sous Fedora, OOo 2.0 est plus rapide que OOo 1.1.
[^] # Re: Je me disais aussi...
Posté par collinm (site web personnel) . Évalué à 2.
c'est le jours ou la nuit
www.solutions-norenda.com
[^] # Re: Je me disais aussi...
Posté par Manwe . Évalué à 2.
Oui mais on est passé d'un programme très lent à charger à un programme lent à charger.
Pour moi, ca devrait s'appeler 1.2 et pas 2.0
à moins que des fonctionnalités révolutionnaires n'aient été ajoutées (auquel cas je ne m'en servirai sans doute jamais).
Le probleme semble être le meme que pour Netscape : Un gros code bien inextriquable. Et comment Mozilla s'est sorti de ce pétrain ? En séparant UI, Comportement et traitement. Voire meme en séparant les fonctionnalités (mail, surf...). Je pense pas que OpenOffice opte pour cette voix...
[^] # Re: Je me disais aussi...
Posté par collinm (site web personnel) . Évalué à -1.
faudrait peut-être que tu arrêtes ton quake 3 en essayant OOo 2...
n'importe quel review le confirme, OOo 2 s'est grandement améliorer en temps de chargement, on est tout près de ce ms office arrive à obtenir...
si on veut démarrer plus rapidement faut lancer démarrage rapide
www.solutions-norenda.com
[^] # Re: Je me disais aussi...
Posté par Manwe . Évalué à 2.
J'ai un PC sous Windows (evidement, pour comparer...).
Pas de logiciel de lancé.
Pas de "démarrage rapide" (si tous les logiciels en avaient un ce serait la misèrre)
Je lance Office 2003, je ferme
Je lance OpenOffice 2
Je commente même pas la comparaison, je vous laisse juger.
Je vois pas la mauvaise foi. Pour moi, c'est être réaliste. Mon but est que mes amis utilisent OOo à la place d'Office en préparation d'une migration Linux. Tout se passe bien pour Firefox, Thunderbird, Psi (quoique), mais ca coince sur OOo : ils me disent "trop lent".
Je sens que quand QTWin permettra le port de KDE sous Windows, je vais leur faire gouter du KOffice qui me semble quand meme plus rapide.
[^] # Re: Je me disais aussi...
Posté par Maillequeule . Évalué à 4.
M
[^] # Re: Je me disais aussi...
Posté par collinm (site web personnel) . Évalué à 1.
pour des performances quelques bench
http://www.laboiteaprog.com/tutoriel72-5(...)
après faut voir ce que ça donne pour un programme complet...
www.solutions-norenda.com
[^] # Re: Je me disais aussi...
Posté par Prosper . Évalué à 2.
[^] # Re: Je me disais aussi...
Posté par collinm (site web personnel) . Évalué à 1.
www.solutions-norenda.com
[^] # Re: Je me disais aussi...
Posté par TImaniac (site web personnel) . Évalué à 2.
Sinon dans la même rubrique que ton bench : http://shootout.alioth.debian.org/benchmark.php?test=all&lang=a(...)
[^] # Re: Je me disais aussi...
Posté par collinm (site web personnel) . Évalué à 1.
http://www.laboiteaprog.com/prog/bench.tar.gz(...)
www.solutions-norenda.com
[^] # Re: Je me disais aussi...
Posté par fabb . Évalué à 1.
Oui. Mais ce n'est pas encore un objectif prioritaire de gcj. Par contre, le potentiel d'optimisation de gcj est beaucoup beaucoup plus important.
Gros avantage de gcj actuellement :
- consommation mémoire
- vitesse de chargement
Ceux qui ont testé Eclipse en natif peuvent le confirmer.
[^] # Re: Je me disais aussi...
Posté par cedric . Évalué à 2.
static const unsigned long optfib(const unsigned long n, const unsigned long sum) {
if (n < 2)
return 1 + sum;
else
return optfib(n-2, optfib(n-1, sum));
}
static inline const unsigned long fib (const unsigned long n)
{
return optfib (n, 0);
}
(Un "objdump -d" sur le binaire te montrera qu'il n'y a plus que un seul vrai appel de fonction, les autres ayant ete remplace par des sauts). Pour Ackermann, ce serait plutot comme ca :
const int Ack(const int M, const int N)
{
if (!M)
return N + 1;
else
if (!N)
return Ack (M - 1, 1);
else
return Ack (M - 1, Ack (M, N - 1));
}
Dans cette version de Ack, il ne restera aussi que un seul vrai call.
Sinon je ne connais pas le Java suffisament bien, mais j'avais cru comprendre qu'il y avait un garbage collector, donc tester l'allocation dans objinst ne me parait pas tres convaincant, car pour le C++, c'est un delete pour chaque new, tandis que pour Java, il va pouvoir mutualiser ce genre d'operation. Dans un gros programme en C ou C++ on gagne toujours enormement a gerer correctement sa memoire (sans directement utiliser malloc/free ou new/delete). Donc ce critere me parait au mieux biaise.
Enfin pour wc, le dico doit etre un peu petit parce que les temps sont tous tres proches et la moindre variation dans la charge de la machine pourrait avoir un effet sur les resultats.
[^] # Re: Je me disais aussi...
Posté par collinm (site web personnel) . Évalué à 1.
pour objinst, créer et détruire un objet à un coût que ça soit pour java ou c++... ta delete pour c++ et de l'autre côté tu auras rapidement le garbage collector
pour wc, tel que dit, le fichier a quelques millions de lignes
il y a t'il quelqu'un qui est capable d'optimiser le code java?
www.solutions-norenda.com
[^] # Repompage malhonnête
Posté par Antoine . Évalué à 1.
http://shootout.alioth.debian.org/(...)
J'encourage tout le monde à envoyer ses améliorations directement au Shootout sus-cité, ce sera plus utile.
[^] # Re: Repompage malhonnête
Posté par collinm (site web personnel) . Évalué à 0.
apprend à lire plutôt
c'est clairement indiqué:
Les tests réalisés ont été fait à partir des sources dipsonibles à JavaBench.
www.solutions-norenda.com
[^] # Re: Repompage malhonnête
Posté par Antoine . Évalué à 2.
Ma remarque reste quand même valable dans la mesure où tu maintiens ton propre sous-ensemble (probablement pas à jour) du Shootout alors que tu pourrais très bien apporter à celui-ci tes améliorations, afin que l'effort communautaire ne se disperse pas.
[^] # Re: Repompage malhonnête
Posté par collinm (site web personnel) . Évalué à -1.
pas vraiment le temps et surtout bon commencer à perdre du temps pour savoir celui qui a la plus grosse...
ces bench ne testes que des algos... ce n'est pas représentatif de la majorité des applications que les utilisateurs emploient.
qu'un langage soit x plus rapide que l'autre de nos jours pour la majorité des programmes, ça n'a pas une grosses importances
java est devenu si populaire car il réduit considérablement le temps de développement
www.solutions-norenda.com
# Et Mono ?
Posté par scls19fr (site web personnel) . Évalué à 3.
c'est marrant mais ça me fait penser à un rapport de bug (demande d'amélioration plutôt) que j'ai envoyé.
http://qa.openoffice.org/issues/show_bug.cgi?id=36417(...)
L'idée c'est de faire reposer OOo sur Mono plutôt que Java.
IKVM http://www.ikvm.net/(...) pourrait être envisagé.
L'intéret serait de proposer en plus d'autres langages de script pour piloter OOo.
Vous pouvez bien entendu voter pour cette proposition...
@+
PS : non ça n'est pas un n-ième troll Java vs Mono
[^] # Re: Et Mono ?
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
On a juste un tout une discution sur les "problèmes" de Mono et on a eu une conclusion qui était: "en gros, java et mono ont tous les deux des gros problèmes" :)
http://about.me/straumat
[^] # Re: Et Mono ?
Posté par fabb . Évalué à -1.
[^] # Re: Et Mono ?
Posté par François Becker (site web personnel) . Évalué à 2.
# traduire en python ?
Posté par ploum (site web personnel, Mastodon) . Évalué à 1.
Et chaque participant doit traduire en python un ou plusieurs fichiers.
Possible ?
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: traduire en python ?
Posté par nikitae . Évalué à 2.
autant donner un coup de main à d'autre projets qui apportent quelques choses..
open office n'a pas beaucoup innové...c'est surtout de star office d'où proviennent les fonctionnalités d'oOo..
autant travaillé sur des outils fonctionnels qui convertissent les formats propriétaires en formats libres..et vice versa..
open office est une usine à gaz..autant partir du bon pied et eviter les même erreurs
# Je ne vous jette pas la pierre, Pierre
Posté par Alex G. . Évalué à 5.
Je suis complêtement Stallman lorsqu'il rapelle que Java n'est pas encore libre, car il est important de le rappeller. Toutefois je salut aussi RedHat qui fait des efforts pour faire aboutir gcj et classpath.
En effet, la communauté Java est pleine de projets libres et de développeurs qui ont été attiré par les idées du libre. Or Java représente presque une communauté avec une certaine culture. Cette culture est composée d'idées partagées aussi par d'autres communautés et d'autres plus différentes, mais le fait est qu'il y a une forte marque identitaire. (parmis ces idées : Ejb, serveur d'appli, Junit, design pattern, forte présence de xml...)
Il ne faut donc pas "cracher" sur ces communautés (ou ce qu'elles produisent) mais bien comprendre comment les intégrer, comment se libérer de la dépendence au propriétaire.
Sûr qu'une libération de la jvm de Sun ou de IBM serait une super nouvelle. En attendant, je pense vraiment que classPath est une initiative a booster. En effet, si elle passe les tests de compatibilité de la jvm, elle aura le droit aux brevets.
Quoiqu'il en soit, Sun pour l'instant s'est montré tolérant envers gcj et je pense qu'il le resterons (je suis d'accord qu'il y a toujours un risque).
Bien sur pour ma part, beaucoup plus que Java, Python R0x0R à donf !
[^] # Re: Je ne vous jette pas la pierre, Pierre
Posté par Tobu . Évalué à 3.
Un développeur Classpath les a pris au mot, mais ça n'a pas vraiment bougé: http://svn.ghostscript.com/person/robilad/diary.html?start=64(...) .
En réalité, le développement de Classpath est déjà fortement basé sur des tests - cf japitools pour la couverture des API et surtout Mauve, pour la conformance des API - voir les résultats sur kaffe.org par exemple.
La seule différence, c'est que tant que sun n'aura pas permis d'utiliser leurs tests l'on n'a pas le droit (tm) d'utiliser le mot java pour des projets comme kaffe et gcj.
# OpenOffice a-t-il une alternative libre ?
Posté par Unixfix le Gaulois . Évalué à 6.
Avant qu'openoffice ne fut "libéré" par SUN, il n'y avait pas de suite bureatique convenable. Le libre avait pour les tenants de Gnome Abiword/Gnumeric et pour ceux de KDE KOffice. Ces deux solutions étaeint certe encensés sur certains forum mais la réalité était beaucoup moins rose.
Ils étaient prometteurs mais bon pour un usage professionnel franchement insuffisant ou incomplet.
Quand OpenOffice est apparu, l'usage de Linux comme desktop professionnel est devenu vraiment possible.
Il est certain que les 2 protagonistes Abiword/Gnumeric Koffice se sont bonifiés avec les années, mais ils n'ont pas encore atteints le niveau d' OpenOffice....
[^] # Re: OpenOffice a-t-il une alternative libre ?
Posté par Lionel Fournigault . Évalué à 3.
Koffice me semble plus interessant meme ça parait encore incomplet. Il ya la version 1.4 qui devrait sortir d'ici 1 ou 2 mois. A voir sans doute http://koffice.kde.org(...)
[^] # Re: OpenOffice a-t-il une alternative libre ?
Posté par Antoine . Évalué à 3.
Il y en a un en projet, avec un nom à coucher dehors... heu... attends... criamips... acrivips... Ah oui voilà : criawips.
http://www.nongnu.org/criawips/(...)
[^] # Re: OpenOffice a-t-il une alternative libre ?
Posté par qdm . Évalué à 1.
Kword ne sera pas réellement utilisable avant KOffice 2.0 puisqu'il n'est pas WYSIWYG à cause d'un bug qui sera corrigé dans Qt4
KSpread est plaisant à l'heure actuelle mais un peu léger au niveau des formules proposées
Les autres modules, j'ai pas testé intensivement
Mais j'attends énormément de Krita, un logiciel de retouche qui sera dispo pour la première fois dans Koffice 1.4. Son ergonomie est parail il excellente. Par contre question fonctionnalités, ils n'auront pas le temps d'implémenter une foule de choses du type calques d'ici la sortie. Donc bon là aussi, attendre Koffice 2.0
[^] # Re: OpenOffice a-t-il une alternative libre ?
Posté par David Douard . Évalué à 1.
Ca dépend pour quoi faire. Par exemple : je veux tracer une courbe représentant un cosinus bruité :
- une colonne A telle que A(0)=0; A(n+1)=A(n)+pi/256
- une colonne B tq B(n) = rand()
- une colonne C tq C(n) = cos(A(n)) + B(n)
Tracer C=f(A) pour 0 <= n <= 100, puis 1000, voire 10000
Fait le test avec OOo, koffice et gnumeric, et dis-moi ce que tu en penses...
Oui je sais, c'est pas flatteur pour OOo (testé avec 1.3 et 1.4), ni même kspread.
David
[^] # Re: OpenOffice a-t-il une alternative libre ?
Posté par Unixfix le Gaulois . Évalué à 2.
Ils n'ont toujours pas compris que gnumeric est un tableur certe reussi mais de loin pas une suite bureautique.
Deplus Gnumeric n'est pas indépendant. Il a besoin de libs de gnome pour fonctionner. Ce qui est pour ceux qui ne veulent pas de Gnome et ils sont nombreux un défaut certain !!!
[^] # Re: OpenOffice a-t-il une alternative libre ?
Posté par skeespin (site web personnel) . Évalué à 4.
[^] # Re: OpenOffice a-t-il une alternative libre ?
Posté par Guillaume Knispel . Évalué à 2.
[^] # Re: OpenOffice a-t-il une alternative libre ?
Posté par Sylvain Sauvage . Évalué à 3.
[^] # GNUMERIC WINDOWS
Posté par Juke (site web personnel) . Évalué à 1.
les libs de gnome sont libres, pas celles de java.
http://www.gnome.org/projects/gnumeric/downloads.shtml(...)
[^] # Re: OpenOffice a-t-il une alternative libre ?
Posté par Romain Guy . Évalué à 1.
[^] # Re: OpenOffice a-t-il une alternative libre ?
Posté par Sylvain Sauvage . Évalué à 2.
Du style :
--- gnuplot ---
set xrange [0:10000]
plot cos(x*pi/256)+rand(0)
---
Pour avoir un nuage de points, tu peux faire en deux temps :
--- shell ---
date +%s |
gawk '
{ srand($1); PI=2*atan2(1, 0) }
END { for (i = 0; i < 10000; i++) print cos(i*PI/256)+rand() } > data
--- gnuplot ---
plot 'data'
---
(On peut aussi générer un seul fichier avec les commandes gnuplot idoines au début et piper tout ça dans gnuplot pour en faire un .eps.)
Small is beautiful.
[^] # Re: OpenOffice a-t-il une alternative libre ?
Posté par Laurent Godard . Évalué à 1.
Quel est le problème ? OOo 1.1.4
Je viens de le faire pour n = 1000 et 5000 et ne vois rien de choquant à premiere vue.
Maintenant, je n'ai pas encore pris mon café ....
Si probleme il y a, a t il été remonté ? Numero d'issue ?
Laurent
[^] # Re: OpenOffice a-t-il une alternative libre ?
Posté par David Douard . Évalué à 2.
Sur ma machine au taf (Celeron 2.4GHz 512Mo), cela prend au moins 1 minute (n=1000 avec OOo 1.1.3), de même si je redimensionne le graphe généré. D'accord, je suis tous les jours stupéfait de voir à quel point cette machine est lente pour les caractéristiques affichées. Mais quand même.
Pour répondre au post précédant : bien sûr que j'utilise Gnupot (ou Python avec matplotlib, ou autres) pour faire ce genre de trucs.
Mon exemple n'est pas un cas réel de mes besoins, juste un exemple.
David
[^] # Re: OpenOffice a-t-il une alternative libre ?
Posté par Laurent Godard . Évalué à 1.
je ne vois de reele latence que lorsque je demande une recolorisation des points. Effectivement, il prend quelques secondes (2 à 3)
La machine est un centrino 1,7 GHz, 512 Mo ram sous debian
Aucun probleme particulier sur un redimensionnement
As tu regardé tes options de gestions d'objets graphiques ? peut etre que ca aiderait ? (outils > options > memoire vive) mais si tu as laissé les valeurs par defaut, ce devrait etre bon (c'est mon cas ...)
Laurent
[^] # Re: OpenOffice a-t-il une alternative libre ?
Posté par David Douard . Évalué à 1.
Je suis en train de rafaire le test : j'ai une colonne de 1000 chiffre, je la sélectionne, je demande un graphe (toutes options par défaut), données ofganisées par colonne.
Entre le moment où je clique sur 'Créer' et celui où apparait un graphe, le CPU est à 100%, la mémoire ne bouge pas, et il faut 1 à 2 mn pour avoir un résultat.
En plus, le résultat est inexploitable car l'axe des X est illisible et non paramétrable (quant aux valeurs min, max, et nombre d'étiquettes).
En fait, il semble bien que le problème est lié à l'affichage de cet axe des X (je vais explorer un peu cela).
David
[^] # Re: OpenOffice a-t-il une alternative libre ?
Posté par collinm (site web personnel) . Évalué à 0.
www.solutions-norenda.com
[^] # Re: OpenOffice a-t-il une alternative libre ?
Posté par Sylvain Sauvage . Évalué à 2.
Ben, c'était justement ce que je lui reprochais à ton exemple : tu te plains de la lenteur d'OOo et tu cites plusieurs tableurs à comparer avec lui à partir d'un exemple qui n'est pas (à mon avis) dans les besoins pour lesquels un tableur devrait être utilisé.
Je voulais donc signaler la présence d'outils spécialisés dans le tracé de courbes et demandais donc si :
- tu les connaissais ;
- tu les reconnaissais (comme « étudiés pour ») ;
- tu avais aussi comparé les performances de ces outils à celles des tableurs.
L'esprit était donc plutôt : on peut faire pas mal de choses avec un tableur mais est-ce une raison pour lui faire faire n'importe quoi, et, surtout, est-ce une raison pour s'en plaindre ?
Maintenant, c'est vrai que OOo est lourd ;o)
[^] # Re: OpenOffice a-t-il une alternative libre ?
Posté par David Douard . Évalué à 1.
Perso, je n'aime pas les tableurs. Quand je veux faire du traitement statistique, j'utilise R, ou Octave pour des maths, etc.
Mais si OOo est voué à être diffusé largement, à être utilisé en entreprise, ce genre de dysfonctionnement est grave, car c'est une fonctionalité de base d'un tableur, et cela nuit à l'ensemble de l'outil, car (comme c'est un truc de base), beaucoup de gens vont y être confrontés et finir par être obligés d'utiliser Microsoft Excel ou Gnumeric pour "finir" leur travail.
C'est dommage, car cela ternit l'ensemble de l'outil qui a de grandes qualités. C'est dommage que cela ne soit pas réglé pour la version qui pointe son nez (j'ai testé avec la version 1.9.69 sous Microsoft Windows et sous Linux).
David
[^] # Re: OpenOffice a-t-il une alternative libre ?
Posté par collinm (site web personnel) . Évalué à 1.
de plus plusieurs pourront tester
www.solutions-norenda.com
[^] # Re: OpenOffice a-t-il une alternative libre ?
Posté par Laurent Godard . Évalué à 1.
Pour ma part, le fichier que j'ai utilisé est ici
http://ooo.lab-project.net/~lgodard/calc_cos/(...)
Laurent
[^] # Re: OpenOffice a-t-il une alternative libre ?
Posté par David Douard . Évalué à 3.
Pour l'essentiel, la réponse à mon problème est : "je suis un âne".
En fait, je demandais un graphe de type "lignes" avec la première colonne comme étiquettes, et non un graphe de type "X-Y".
C'est ballo, et je suis un peu rouge de confusion. Cela dit, je pense ne pas avoir été le seul à me faire avoir (ce qui, si cela s'avère être le cas, peut être une source de mécontentement vis-à-vis de ce logiciel pour l'utilisateur occasionnel). J'ai pas testé sous MS Excel pour voir quel est son comportement pas défaut et donc quelle va être l'attitude a priori d'un utilisateur dans un cas similaire).
Cela prouve juste que je fais vraiment jamais de graphes avec un tableur, et que je ferais bien de mieux tester les fonctionnalités d'un soft avant de lancer de telles accusations.
David (qui va se coucher peut-être un peu moins bête ce soir, et peut-être bien proprio aussi, sait-on jamais, mais ca n'a rien à voir).
PS : je viens de tester avec MS Office 2000. Si je demande un graphe de base (lignes), et que j'affecte la première colonne à l'axe des X, il se comporte globalement de la même manière que si je demande un graphe type "nuage de points" (donc XY). Les possibilités de paramétrage de l'axe des X sont un peu différentes dans ces deux cas. Mais la tableur propriétaire s'en sort normalement (donc génère le graphe instantanément), contrairement à OOo. Du coup, je m'en va aller voir si un bug/wish existe, et en créer un sinon. Le problème de OOo est qu'il génrère un axe des X avec toutes les étiquettes, quand bien même un mauvais paramétrage du graphe implique une densité d'étiquettes (tics et labels de tics) ridicule (afficher 10000 tics sur un graphe de 10cm de large est ridicule). Et c'est cela qui le met dans les choux.
# Et OOo 1.1 ? Il n'est pas mort que je sache ?
Posté par Ellendhel (site web personnel) . Évalué à 2.
Il y avait plusieurs points qui me semblaient intéressants dans OOo 2.0 mais si le tout dépend de Java, c'est moins pratique et moins libre effectivement.
Ceci étant, la version actuelle d'OOo me convient parfaitement ou peu s'en faut et il n'y a pas de raison critique pour que j'en change.
Reste qu'il y a un débat de fond derrière tout cela... Là je ne vois pas réponse immédiate.
# kaffe ?
Posté par Beurt . Évalué à 2.
Je ne suis pas sûr d'avoir compris tous les tenants et les aboutissants de cette dépêche et des quelques commentaires que j'ai lu.
Est-il possible d'utiliser OOo 2.0 avec Kaffe ?
- Si oui: quels sont les problèmes de licence (puisque Kaffe est GPL)
- Si non... Ben heu... Pourquoi ? (c'est sans doute ça que je n'ai pas compris ! :o)
[^] # Re: kaffe ?
Posté par Maillequeule . Évalué à 2.
http://www.spindazzle.org/green/index.php?p=43(...)
En fait le gros interêt de ce débat va sans être de relancer les travaux sur ce sujet, et c'est déjà bien :)
M
[^] # Re: kaffe ?
Posté par M . Évalué à 2.
L'implem n'est pas complete, donc si OOo utilise ces parties ca plante...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.