007 a écrit 2187 commentaires

> Quand à la compilation native avec GCJ ou autre, les tests que j'ai pu voir/faire montrent que c'est soit moins performants (GCJ) soit équivalent.

Je pense que beaucoup d'optimisation peuvent encore être faite ici. Il doit y avoir encore beaucoup de marge (genre un rapport 2 ou 3 sans problème). L'optimisation de gcj n'a pas vraiment commencée. Puis ça permet des "fantaisies" comme ne plus contrôler les débordements si l'appli marche sans problème (comme lorsqu'on compile un programme avec ou sans dmalloc).

> Un os en java : http://jnode.sourceforge.net/portal/(...)

Et il faut voir les performances :
http://jnode.sourceforge.net/portal/node/view/51(...)

La comparaison n'est pas par rapport à un Linux/libc mais par rapport à Sun J2SDK (une machine virtuelle qui tourne sur un OS bien réel) et c'est plus lent...

Donc java plus rapide que le langage C : dans 400 ans et c'est vraiment pas sûre.

> Mais non !!! puisqu'on te dis que quand la JVM le peut

Et le JVM n'interprète pas le bytecode ? Elle envoie le bytecode au cpu sans rien faire ?
Mais oui....

> le bytecode est compilé par anticipation !!!!

D'ailleur la prochaine JVM donnera le résultat par anticipation. Avant même d'exécuter le code. Formidable !
Le marketing SUN a bien bossé.

> Oulala la bonne idée ;)

Tu fais tes tests avec dmalloc (c'est lent mais il contrôle les débordements comme java (ou presque)). Et quand ça marche tu vires dmalloc pour ne conserver que les contrôles nécessaires. C'est une pratique très courrante...

> Alors ca, je trouve que c'est une très mauvaise idée !!!!

Je ne parle QUE de vitesse !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Je ne dis pas si c'est intelligent ou non d'utiliser un langage qui contrôle les débordements. C'est claire !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

> Je pense que de toute façon, comme toi, que les benchs, ca vaut rien du tout :)

C'est la conclusion de CERTAINS benchs qui m'énerve.
Voir par exemple :
http://www.osnews.com/story.php?news_id=7372(...)
Here is a comparison of a C and Java speech librarywhere the Java version is 2-3 times faster, with server VM configuration. And here are some more C++ and java comparisons, with various algorithms. Elsewhere, Java 1.5 is 20% faster than C says JavaLobby. And some of our tests.

C'est du foutage gueule.

Pour les fines bouches :
http://www.kano.net/javabench/(...)

Si tu es développeur java, peux-tu honnètement dire que mplayer serait plus rapide s'il était écrit en java et non en C ?

> Je te prierais de rester poli
J'ai dit "ou je cause le chinois"

> m'expliquer ce que la libc vient foutre dans le bordel ?

Relis depuis ici :
http://linuxfr.org/comments/439150.html#439150(...)

En quoi GnomeMeeting ne fait pas ton bonheur ?
Et s'il ne fait pas ton bonheur, es-ce suffisant pour préférer un programme 100 % proprio à une solution 100 % libre ?

> qui me permet de défendre linux

Tu défends une solution proprio alors qu'il y a une solution libre !
Si tu veux du proprio, installes Windows ou Mac ou Solaris (d'ailleur il y a une version download)...

> Java n'est pas un langage interprété.
Même si c'est du bytecode, le bytecode doit être interprété avant de donner quelque chose à manger au CPU. C'est un fait.

> Par exemple, on peut déterminer si les bornes d'un tableau sont respectées dans une boucle avant de l'exécuter, ce qui permet de supprimer les tests de débordement au moment de la compilation effective en code machine.

Et le développeur en C peut utiliser son cerveau et voir qu'il n'y a pas de débordement et ne jamais faire de teste.

> D'autre part, je ne vois vraiment pas le problème d'avoir un mélange de C et de Java

Relis le thread depuis ici :
http://linuxfr.org/comments/439150.html#439150(...)
J'ai aucun problème avec le mélange de C/pascal/basic/lisp/java. Je parle des conclusions de bench.
J'ai aussi aucun problème avec Java. Je répète encore une fois :
- Java c'est bien

J'arrête, les gens ne savent pas lire ici.

> Pourquoi veux-tu

Ben tu ne sais pas lire ou t'as un problème de cerveau ou je cause le chinois ou...
Mais t'as rien compris.

Bon, je vais faire plaisir à tout le monde :
- Java est plus rapide que le C++, le C, l'assembleur et le concorde.

Sous RedHat/Fedora la majorité des services accédés via xinetd est désactivée par défaut.
Donc il faut éditer /etc/xinetd.d/swat et relancer xinetd ("service xinetd restart").
Normalement system-config-service doit permettre de faire ça. Je n'ai pas vérifié.

Et google ? :
http://www.google.fr/linux?hl=fr&ie=UTF-8&q=suse+netmod&(...)

Le cross-posting c'est mal(TM) :
http://linuxfr.org/~Hid3o/14273.html(...)

J'utilise pas (sisi) mais il semble que xmule est un peu mort et remplacé par amule.
Sur http://www.fedora.us/(...) tu trouveras amule.
Avant de l'installer, vire tas versions de wxGTK et utilises la version de fedora.us .
Si ça marche chez eux, y a pas de raison que ça ne marche pas chez toi :-)

Je suis solidaire avec ton coup de gueule et propose un post de plus au moinsage pour que tu trinques un peu moins.

SKYPEÇAPUCESTPASLIBRE. C'est même vraiment pas libre (pas de source).

Marre de toute cette pub pour un truc proprio dont on peut se passer.

Tu as raison, j'ai mal lu :-(

> Et puis c'est quoi ton trip avec la libc ?? Pourquoi la reecrire en Java ??

Tu sais lire ? SI java est plus rapide que le C, tu ne vois pas l'intérêt d'avoir une libjava.

> Je ne suis pas spécialiste, mais quelle serait l'utilité de rédévelopper la libc ?

Pour moi aucune.
Mais si on prétend que Java est plus rapide que le C, il est logique de proposer la réécriture de la libc en java (au moins pour les programmes java) pour des raisons de performance. Or c'est bien pour des raisons de performance (et de portabilité) que la libc est écrite en C (comme le noyau) et ne sera jamais écrite en java.

> Mon point de vue est que ce qu'il se passe dans la JVM n'est absolument pas du resort des dévelopeuurs Java

Je ne parle pas de ça. Lors de l'exécution d'un programme en java, il y a aussi du C/assembleur qui est aussi utilisé. Or ça n'empêche pas des benchs démago de conclurent que java est plus rapide que le C.
Si on fait un bench qui compare le langage java au langage C, il faut vérifier qu'uniquement du java est utilisé pour java (par exemple pas de librairie écrite en C utilisée (ou uniquement la libc)).

Je parle dans ce thread, uniquement de vitesse ! Je ne parle pas de l'intérêt d'utiliser Java (portabilité, api de haut-niveau, etc...).

> Le compilateur pourrait etre en delphi ca serait pareil.

J'en rigole encore.
Et pourquoi ils le font pas en Java alors ? Absolument rien n'empêche de faire un compilateur en java (Il n'y a aucun accès matériel).

> Java d'ailleurs n'accède pas aux ressources matérielles

Il n'y a que le noyau qui accède au matérielle. Mais hors noyau, il n'y a rien qui empêche de faire tout le reste en java (dont un équivalent de la libc). Si java est si rapide (même plus rapide de C selon "certains" benchs) alors pourquoi ne pas faire d'équivalent de la libc en java ?
La réponse est simple => trop lent trop gros. C'est valable pour tous les langages interprétés.
Puis notes que dans un noyau il n'y a qu'une petite partie qui est dépendante du matériel. La vm, les FS, le réseau, etc... sont généralement faites pour être indépendantes du matériel (heureusement).

> Si tu pousses ton raisonnement, "les compilateurs C++, c'est nul car en fait, ca transforme tout en assembleur" !!!!!

Relis bien, je dis qu'un langage interprété est forcément plus lent que la version compilée en native.
D'ailleur il y a aussi du langage C interprété. Et il est fort logiciquement plus lent. L'interprétation (même si c'est du bytecode) bouffera toujours du temps. C'est un fait indiscutable. De plus tu ne peux pas aller très loin dans l'optimisation à la volée car ça bouffe aussi du temps. Il faut forcément faire un compromis.

Lorsqu'il y a un bench Java qui prétend que java est plus rapide que le C ou le C++ il faudrait toujours donner le temps passé dans des librairie écrite en C ou assembleur et optimisé au petit oignon.

Je peux utiliser mplayer pour lire des DVD. Fais l'équivalent de mplayer en java (c-à-d réécrit tout mplayer et n'utilise pas de librairies C fournis par mplayer) et tu auras des performances lamentables.

NB : Je trouve que Java est un bon langage et rapide. Je m'énerve sur les benchs à la con et/ou leurs conclusions.

> http://www.osnews.com/story.php?news_id=7372(...)

J'ai pas lu le détail mais ça me fait toujours rire ce genre de trucs.
Java est fourni avec des librairies CODÉES EN C/ASSEMBLEUR (java utilise aussi la libc (pourquoi il ne font pas un équivalent de la libc mais en java seulement ?)) mais on en profite pour dire que Java est plus rapide que le C.

C'est comme si je fesais un GUI en python pour libxine et après je disais :
- python c'est super rapide ça affiche les videos aussi vite que mplayer écrit en C.

N'importe quoi.
Une langage interprété (même si c'est du bytecode) est et restera pour toujours plus lent que du compilé spécifiquement pour le CPU. Peut-être qu'un jour gcj sera aussi rapide que du C mais java interprété, JAMAIS (ou alors l'équivalent C a été écrit par un porc).

Si Java roxe à ce point, pourquoi Sun n'écrit pas le noyau de Solaris en Java ?

> Comme Redhat, qui pose des brevets défensifs.

Pour info :
http://www.redhat.com/legal/patent_policy.html(...)

Les brevets Appel gènent le libre. C'est une grosse différence.

> Apple utilise beaucoup de technologies libres et oh, surprise, y contribue en retour (de nombreuses améliorations d'origine Apple sont intégrées à Khtml, gcc, ...)

Ouais, mais ils y sont forcés par la GPL. Pour ce qui est/était sous BSD... c'est une autre histoire.
De plus il me semble qu'ils ont une licence "libre" un peu tordue.
Encore de plus, Appel est passé à du libre car ils y sont plus ou moins obligé. Ils n'ont pas le ressource de développer gcc, etc...
Ce ne sont pas des saints. Leur démarche est bien différente de RedHat et mettre Appel sur le même plan que RedHat est une "connerie".

> Leur interface graphique est propriétaire, oui, et ?

Ben c'est comme pour les brevets, c'est pas bien. Même si les brevets sont plus ou moins obligatoires, ça n'empêche pas qu'il faut faire de son mieux pour les éviter. C'est ce qui fait que je préfère Vorbis à mp3 et que j'attends avec impatience que theora soit plus difusé/disponible.
Tu voudrais des brevets dans w3c ?

> Si Mac OS X était libre, les gens n'auraient plus de raison d'acheter un Mac.

Les gens ont de bonnes raisons de s'inscrire à MandrakeClub, d'acheter du SuSE ou du RHEL etc...
Le libre marche financièrement. C'est maintenant un fait incontestable.
Appel a fait le chois du proprio + libre (car ils sont obligés). Appel peut aussi faire le chois du 100 % comme le fait Red Hat, SuSE, etc.
On ne peut pas mêtre sur le même plan les technos proprios et libres.

> Bref, tes arguments sont fallacieux.

Les tiens ne sont pas mieux.

Lis la doc de l'imprimante et regardes s'il y a un moyen de faire reset.

Il est hors-sujets dans la rubrique "hors-sujets".
Je ne vois pas le problème.

> Je croyais justement que ces formats avaient été rendus publics par Real ?

Un format peu être public mais pas libre. Le bon exemple, c'est les brevets. C'est public mais pas librement utilisable (typiquement mp3 dans les pays où les brevets sont reconnus).
RealPlayer c'est comme HelixPlayer mais avec supports les formats proprios.

C'était une invitation à plonger son nez dans rpm. Ça rend définitivement de grands services.
Mais j'ai vu qu'il a trouvé son sauveur :-)

> C'est une mauvaise idée, ca a peu de chances de marcher

Je suis d'accord

> tu n'auras pas de menus, si ca se lance ca risque de marcher moins bien quand même.

Si tu parts du src.rpm il y a peu de problème. J'ai regardé le .spec de inkscape. Il n'y a pas de patch, le .spec est simple et fait une centaine de ligne. C'est pas un gros deal pour porter ça sous Mandrake si on a un petit peu de connaissance.

J'ai plusieurs fois porté (adapté, restons modeste) des paquets Mandrake vers RedHat/Fedora sans grande difficulté.

Mais j'affirme ton propos : ce n'est pas une bonne idée d'installer un binaire Fedora sous Mandrake (et vice versa).