Matthieu Moy a écrit 3249 commentaires

> pourquoi le fait de fonctionner sur des tas de plateformes l'empêche
> de faire correctement son boulot principal.

L'architecture d'un compilo comme GCC, c'est: Plusieurs front-ends, une représentation intermédiaire commune à la fois à tous les languages et à toutes les plateformes (Ca s'appelle RTL dans GCC), une passe d'optimisation commune à tout le monde sur cette représentation, la génération de code, puis des optimisations spécifiques éventuelles après.

Le truc, c'est que sur la passe d'optimisation du milieu, il y a des trucs qui vont arranger certaines plateformes cibles, d'autres pas. Idéalement, ça serait possible d'avoir un optimiseur taillé sur mesure pour chaque plateforme (Disons que le ./configure choisirait les bons morceaux), mais c'est un boulot énorme.

Donc, faire un compilo multiplateformes et efficace, c'est possible, c'est juste plus dur que pour un compilo mono-plateforme.

Autre critère : Quand c'est intel qui fait à la fois la puce et le compilo par exemple, ils ont déjà une idée de la manière dont ils vont compiler le code quand ils font la puce, et réciproquement. Ca aide aussi pas mal.

> Bien au contraire

Au contraire de quoi ? Je n'ai pas compris ta phrase (Faut dire que j'utilise pas VNC ni PC anywhere alors ça aide pas)

> Il y a eu des tas de benchs sur ce sujet.

Ben on va en faire un de bench. Tu prends un Mplayer, si possible sur une machine un peu limite pour que ça se voit bien, et tu compares les différents protocoles. En X11 pur et dur, ça râââââme, alors qu'avec les extensions qui font de la mémoire partagée, ça redevient fluide. (En particulier quand tu redimensionnes l'image.)


Une question : Ca te viendrait à l'idée d'avoir un rendu des polices entièrement coté client aujourd'hui ? Ben je crois que ça sera pareil avec les widgets et les formes vectorielles de base d'ici quelques années.

> il y a quand encore un parc important de machines sous propriétaire.

Et si tu leur demandes pourquoi ils ne migrent pas, ils te disent "Parce que les gens sont formés à Windows, alors c'est plus simple".

Sacré navet, mais c'est un des seuls films que j'ai vu ou il y a un mec qui tappes des vraies commandes unix. voui monsieur, il fait un ls -l pour de vrai et tout !!!

> et n'a AUCUN rapport avec vitesse ou lenteur

Ben si : La communication inter-processus, surtout si tu as un affichage déporté. (=>réseau)

> lui il parle de fondre gtk (ou qt) dans le serveur X

Moi aussi. Enfin, ça peut être gtk, qt, ou n'importe quoi, un truc qui ai un moteur de rendu, quoi.

Bien sur que ça ne se limiterai pas à un couper-coller de code depuis la lib Gtk vers X, hein !

C'est ce que propose Y.

Pour l'instant, si tu veux afficher un joli bouton à l'écran, le client X calcule la tête du bouton et donne toutes les instructions de dessin au serveur (=> bouffe de la bande passante, pas optimisé pour une configuration particulière du serveur vu qu'on fait tout sur le client).

La solution widgets coté serveur, c'est le contraire. Le client dit : "Je veux tracer un bouton, démerdes-toi", qui bouffe bcp moins de bande passante. Ensuite, le serveur fait ce qu'il veut avec l'instruction. Si il veut vaire un bouton en 3D avec OpenGL, il le fait, si il veut un carré blanc, il peut aussi.

Un autre intérêt du widget coté serveur, c'est qu'il y a forcément une unité visuelle entre les applications. (C'est le même serveur qui s'occupe du rendu de chaque application.)

> Encore des raisons "politiques"[*] qui font perdre une énergie incroyable à bon nombre de gens...
> de XFree on passe à XFree, Y, Xorg et fd.o

Tu mélanges plusieurs choses.

Il y a des forks pour raisons politiques (XFree et X.org), mais Y est un truc totalement nouveau, et n'existe que pour des raisons techniques. (par exemple, des widgets coté serveur, ça économise la bande passante ...)

> Les deux boites sont "réconciliées"

Oui, avec des gros guillements, ...

Quand une boite (MS) donne de l'order du milliard de dollars à une autre (SUN) pour qu'elle obéisse, c'est prèsque un rachat !

Le "xterm de la dernière chance", je suppose que c'est simplement la "failsafe session" de gdm. Regardes quel type de session est choisie dans le menu avant de valider le mot de passe.

[ J'utilise que GCC, alors j'y connais rien ]

D'après les benchs que j'ai vu, l'optimiseur de GCC rattrape celui de ses concurents depuis les versions 3.x, mais les 2.x étaient à la rue.

Niveau temps de compilation, GCC est une tortue.

Et pour ceux qui sont allés voir le code source, ils ne me contrediront surement pas si je dis que GCC est ... hmm, assez obscure !

Par contre, en terme de portabilité, GCC, c'est 6 front-ends officiels, 36 back-ends, et un bon paquet d'architectures hotes supportées. Et là dessus, je crois bien qu'aucun autre compilateur ne peut rivaliser.

M-x gdb RET

dans Emacs.

Tu tappes les mêmes commandes, sauf que Emacs t'affiche le source avec un curseur qui suit l'execution. Et quand tu as trouvé le bug, tu es au bon endroit pour le corriger !

> il est de toute facon moins contraignant d'utiliser la GPL

Entre utiliser une bibliothèque sous GPL ou utiliser les API windows, ce n'est pas celui qu'on croit qui impose le plus de contraintes légales au développeur ...

> ca permet d'eviter que des boites utilisent nos travaux a fins purement
> financiere avec tout la machine marketing qui va avec...

Non. Si tu veux éviter qu'une entreprise ne fasse une utilisation commerciale de ton logiciel, n'utilises pas une licence libre.

RedHat fait du pognon, "avec tout la machine marketing qui va avec", sur du soft GPL.

C'est bien ce que je dis.

Les logiciels libres sous licence incompatible avec la GPL subissent le même traitement que les logiciels propriétaire quand ils veulent se lier avec du code GPL, i.e. « Non, pas possible »

Donc, la GPL pousse à ce que tout soit GPL compatible.

> elle pousse à ce que tout soit libre.

s/libre/compatible GPL/

D'ailleurs, si tu veux faire un logiciel GPL[1] qui puisse se linker avec OpenSSL, tu peux rajouter une exception dans la licence de la portion de code sous GPL pour permettre la liaison. (et non l'inverse)

[1] abus de language volontaire pour simplifier : Justemement, si on rajoute l'exception, ce n'est plus la GPL, mais une GPL modifiée, plus ou moins incompatible avec la GPL originale.

man split

man cat

;-)

> C'est la LGPL qui est la plus utilisée pour les bibliothèques de code et non la GPL

Regardes bien la licence de Qt, readline, ... et relis bien ça :

http://www.gnu.org/licenses/why-not-lgpl.html(...)

"Why you shouldn't use the Library GPL for your next library"

Et sur ce point, je trouve que MS a plutôt raison de dire que c'est très dommage ...

Ben moi, c'est dans la GPL que je vois des restrictions sur les logiciels auxquels tu as le droit de te lier.

> c'est bien quand même vu que ça arrange l'utilisateur.

Ah bon.

Moi, l'autre jour, j'ai voulu utiliser le support HTTPS dans tla, ben en temps qu'utilisateur, tu vois, j'étais super content de voir que ça n'était pas légal à cause de la GPL.

Une autre fois, je me suis demandé pourquoi les listes de mots ne pouvaient pas être distribuées avec OpenOffice.org pour le dictionnaire. Réponse : C'est sous licence GPL, ça ne peut pas être intégré dans OOo. Il était super content, l'utilisateur, de devoir utiliser un installeur séparé, de devoir utiliser de sa bande passante pour installer le dictionnaire alors qu'il avait un OpenOffice.org sur CD.

Je veux aussi utiliser des bouts de GCC dans un projet libre qui utilise aussi du code sous une autre licence, également libre (SystemC). Ben je ne sais même pas si j'aurais le droit de diffuser mon projet. Il est content l'utilisateur, il avait tellement peur de perdre des libertés qu'il ne pourra même pas utiliser ce projet si ça se trouve.

Il y a combien de cas ou ça a bénéficié à l'utilisateur d'avoir choisi la GPL plutôt que la LGPL ?

Tu as un exemple à citer ou ça l'a été ?

Moi, le seul exemple que je connais, c'est les cas comme Qt ou MySQL, pour lesquels la GPL est tellement libre que les clients préfèrent payer une licence commerciale. On avait dit libre ?

En même temps, ça fait un moment que j'en ai une, de sidebar linuxfr ...

http://linuxfr.org/2003/01/18/10874.html(...)

;-)

D'ailleurs, dans la version Debian, c'est le logo Debian à la place.

Ce qui était un peu moyen de la part de SUN, c'est qu'ils ont rajouté leur logo au moment de la dernière RC de la 1.1, ca fait un peu politique du fait accompli : "Vous voulez qu'on l'enlève. OK d'acc ! Oh, zut, la finale est déjà sortie, c'est trop tard, pas de chance, hein ?" ;-)

> KOffice partage au moins les formats de fichiers avec OO.

s/koffice/la prochaine version de koffice/

Et effectivement, c'est à ce moment là que Koffice va devenir vraiment intéressant (parce qu'une suite bureautique qui produit des fichiers illisibles sur les 95% d'ordinateurs de la planète qui sont sous windows, c'est un peu génant)

Abiword est quand même très limité. En particulier, pas de gestion des dessins. C'est un critère éliminatoire quand on t'envoie un fichier word avec des dessins dedans ;-)

Mais c'est très bien qu'il existe et très prometteur, vu que c'est bien concu à la base (le multiplateforme est vraiment bien géré)

Et pour toi, le fait qu'on puisse mettre GNU et Darwin sur le même CD implique que Darwin fasse partie de GNU ?

Bon, alors, on va faire un rappel pour ceux qui ne suivent pas :

GNU est un système d'exploitation complet, qui contient un certain nombre d'outils indispensables pour faire tourner un ordinateur dans une utilisation classique (libc, shell interactif, ...). En particulier, GNU contient un noyau, qui s'appelle HURD.

Seulement, le noyau en question encore instable, supporte très peu de matériel, ... Donc, pour être utilisable, GNU doit utiliser un autre noyau. Aujourd'hui, le plus utilisé est dans doute Linux, on peut aussi utiliser Darwin.

De la même manière, si je suis sous Windows, et que notepad ne me plait pas, je peux le remplacer par Emacs ou vim. Ca ne veut pas dire qu'Emacs et vim font partie de Windows, que je sache ?