reno a écrit 3886 commentaires

Je pense que les deux sont liés d'ailleurs : Objective C peu connu --> GnuStep qui ne se développe que lentement..

Et vice versa d'ailleurs :-)

Bof, tu est sur de toi?
Si je me rappelle bien il y avait un débat sur cette 'clause d'exception' du temps ou Qt n'était pas GPL sur Linux et les developpeurs de KDE ne pensaient pas que cette clause d'exception était nécéssaire.

Je suis plutot de leur avis: je ne vois pas quelle clause de la GPL impose ce que tu dis..

Que je sache il existe des tas de soft GPL pour Windows, ils ont tous cette exception?

> OpenOffice c pas que Sun

Certes, mais à partir du moment ou OpenOffice a été crée par Sun en ouvrant une bonne partie des sources de StarOffice..

Donc sans Sun pas de OOo.

J'ai deux hypotheses:
1) tu considères qu'OpenOffice, c'est "pas grand chose"??
2) tu es trop tétu pour admettre que tu as dit une bétises..

Je penche pour 2 moi.

>> surtout si tu as un affichage déporté. (=>réseau)
> Bien au contraire si tu compares aux techniques comme VNC ou PC Anywhere qui sont utilisées sous Windows .

C'est peut-etre un probleme d'implementation? Difficile de savoir..

Si pour certaines widgets, le client envoit juste une description de haut niveau de la widget et le serveur ne retourne qu'un seul évenement au moment ou l'utilisateur selectionne pour de bon un élément (je pense à un menu déroulant par exemple), il y aura quand même beaucoup moins de traffic circulant sur le réseau: en nombre de paquets émis (X est incroyablement bavard!) et en taille aussi: une description de haut niveau est plus courte..

En local ou sur un LAN, la différence est négligeable, je suis d'accord. Maintenant par Internet, la solution d'avoir une partie des widget coté serveur me parait fort interessante!

Interressant, je ne suis pas un fana du SQL, mais quand on compare le SQL et le XPath, je prends le SQL tous les jours.

Franchement je trouve XSLT/XPath mal fichu.. et les schemas XML aussi d'ailleurs..

Certes, mais comme en général ce que tu investis, tu depense de l'argent a la hauteur de ce que tu pense avoir comme futur benefice, les deux sont franchement lié, au début au moins.

Je l'ai écouté au 4/5, bon je n'ai appris grand chose mais c'est une bonne conférence, j'ai juste 2 petites critiques:
1) il y a une confusion mineure entre le GIF et le JPEG par l'auteur de la conférence: le format PNG a été crée comme une alternative libre au format GIF, pas au format JPEG original, qui lui est libre.

2) la présentation de l'intéret d'avoir des formats structurés comme XML est un peu 'trop enthousiaste': on a l'impression que c'est magique le XML et qu'on pourrait toujours facilement retrouver des citations dans un document XML!

Hors tout depend de la façon de générer ce document: si on utilise OpenOffice comme n'importe quel traitement de texte, il n'y aura pas de balise particulière pour les citations et le fait qu'OpenOffice utilise XML pour décrire ses balises n'aidera *en rien* à retrouver les informations de l'utilisateur.

En résumé: XML permet de conserver la structure des documents *si*l'utilisateur fait l'effort d'organiser ses documents de façon structurée, *sinon* OpenOffice et XML ne seront d'aucune aide..

Cause toujours..
Je préfere de loin complétion: "le complétement automatique du shell", beurk!!

Il y a deux problemes:
- la precision des calculs flottants qui n'est que de 32bits au mieux sur les cartes NVidia (24 bits sur les Radeon actuels).

Il y a des rumeurs comme quoi les Radeon devraient passer bientot en mode 32bits, mais cela reste des calculs en simple précision alors que les calculs scientifiques se font généralement en mode double précision (au moins).

Les jeux vidéos n'utiliseront probablement pas le mode 32bits au départ, alors avoir des calculs flottant en 64 bits sur les GPU, cela n'est pas pres d'arriver..

- la recuperation des donnees: le bus AGP est asymetrique, tres rapide du CPU vers la carte video mais lent dans l'autre sens.
Ca peut etre tres genant pour les calculs scientifique, mais ce probleme devrait bientot disparaitre avec PCI Express..

Il reste le probleme de precision des calculs flottant, tu as raison..

Je pense qu'une des raisons pour laquelle pas grand monde s'interesse a OCaml, c'est la difficulté d'apprentissage (personnellement j'ai renoncé).

Et la lisibilité d'OCaml est à mon avis inférieure à celle de Python ou Ruby..

Les performances d'OCaml sont nettement supérieur certes, mais c'est aussi le cas pour le C..

Si je me souviens bien Ruby ne gere pas l'unicode, non?

Je ne suis pas sur non plus que le support des thread soit "fini"..

C'est un peu génant pour un projet comme Gnome, non?

Je ne vois pas pourquoi tu fais la différence entre les deux!
La barre des fenetres d'Opera peut tout a fait être utilisé comme les tabulations sous Mozilla, personne ne te force a minimiser les fenetres avec Opera.

Bref, il faut être honnete: Mozilla a pompé le concept d'Opera, qui l'avait pris ailleurs..

Soit dit en passant j'aimerais bien que Mozilla pompe un peu plus sur Opera par exemple pour mémoriser les fenetres ouvertes en cas de crash, je crois qu'il y a une extension pour le faire, mais cela mérite d'être intégré par défaut..

Sauf peut-etre si ton disque contient ta partition root :-)

Bon arrete d'embrouiller tout le monde :-)

Serveur == serveur d'affichage: la machine qui affiche ce que tu as sous les yeux (enfin en général! Tu peux exporter sur un autre écran que le tiens, mais c'est rare).

Client: la machine qui envoit les demandes d'affichage, donc soit ta machine, soit la machine sur laquelle tu es rlogué.

Ca va mieux, là? ;-)

Bah, meme entre 2 Sun, il peut y avoir des problemes..

J'étais ahuri quand j'ai découvert que dtpad et dtbrowse ne marche pas correctement en export DISPLAY..

Quel m@@@@ CDE..

Bah, le probleme c'est qu'il y a plein de possibilitées differente pour implementer l'equivalent de X, alors forcément cela génere plusieurs projets différents..

D'autant plus que le but de ces projets est différent: le but du Berlin|Fresco actuel est de faire les choses bien en pensant au futur: par exemple ils utilisent les flottants pour les coordonnées..

Le but initial de PicoGUI était les PDA, les petits environnement, comme son nom l'indique, alors forcément dans ces environnements ou souvent le CPU n'a même pas de FPU, on utilise des entiers pour les coordonnées..

Lequel est le mieux? Entier, Flottant?
Et bien ça dépend du contexte --> plusieurs projets..

Note: ça fait un certain temps que je me suis intéréssé a Berlin|Fresco donc je peux dire des bétises..

Je me demande comment marche l'interaction entre les widgets coté serveur et coté client?

Je m'explique: seule les widgets "simples" peuvent être mis cotés serveur. Pour définir le formattage d'une page web, d'un document texte, c'est forcément le client qui va le faire, pas le serveur..

Je crois que Berlin|Fresco essayait de faire executer du code du client sur le serveur pour faire ça, ce qui me parait compliqué|dangeureux, la seule alternative viable que je vois c'est une composition coté serveux de pixmap envoyé par le client..

Soit dit en passant sur la FAQ, j'adore:
Should it be referred to as "Y", "The Y Window System", or "Y Windows" ..?
I don't care.

Ca, c'est un réel progrés par rapport à X !!
:-)

Je suis curieux de voir la comparaison avec PicoGUI qui m'a l'air d'être aussi bien pensé..

Bon aller, lecture de PDF.

> Ok, le système n'est pas parfait, mais quand il le sera ce sera très agréable pour l'utilisateur (en tout cas pour moi)

Personellement, moi je suis pour les magicdev, supermount etc, mais le probleme, c'est que comme tu dis le systeme n'est pas parfait, et ça fait des *années* que ça pose des problèmes..

> Ce qui faisait la specificite de BeOs, c'est son coeur et mettre ce coeur sur du
> Linux, ca veut dire perdre les specificites de BeOs et le mettre au meme niveau
> que Window Maker ou KDE.

Bof, tu as des preuves?

Pour moi, ce qui faisait sa spécificité, c'était son API qui poussait les applications à utiliser beaucoup les thread ce qui faisait un système très réactif..

Certaines fonctionnalités étaient liés au noyeau certe, mais pour le reste Linux gère bien les thread aussi maintenant..

Voir plus haut mais:
- un boot tres rapide, je ne me souviens plus exactement du temps, mais c'était moins de 20s pour charger l'equivalent du noyeau+KDE jusqu'au desktop sur mon Celeron 333, et le systeme etait immediatement utilisable pas comme WindowsXP qui triche en te rendant la main sans que le boot soit fini.

C'est un peu gadget le boot rapide, mais c'est quand meme agreable!

- et surtout un systeme tres *reactif*, jamais de fenetre totalement figée, tout était fluide, et ça pour le confort d'utilisation, c'est énorme!

> Il y a un truc que j'aimais sur cette OS : le temps de boot ridiculement court. Est-ce que c'est pareil pour les BeOS basé sur le noyaux linux ?

Ca m'etonnerait..

Moi, personellement ce que j'aimais biendans BeOS c'était la réactivité du système, tout réagissait de manière trés rapide, et on n'était jamais vraiment bloqué.

Je pense que c'était due a une bonne utilisation des thread dans les applications..

Je me fiche un peu de BeOS, mais j'aimerais bien que sous Unix les applications deviennent moins "monolithique" dans Mozilla parfois quand une tab fait quelque-chose, la fenetre entière ne répond plus, bof!

Bah la situation d'Apple est tres differente..

Mais pour OpenGL, il y a quand même deux gros problèmes:
- la spécification d'OpenGL n'est PAS précise au pixel près: c'est fait expres pour autoriser les constructeurs à prendre des raccourcis.
Génant quand on veut faire de la 2D, non?

Si tu choisis un modele de carte 3D, ca doit aller mais quand tu essaye de supporte le plus grand nombre de cartes 3D possible..


- toutes les cartes que tu as cités sont des vieux clous, tous les drivers 3D des cartes récentes sont propriétaires.
La qualité des drivers OpenSource pour l'accélération 3D n'est pas glorieuse.

Ce n'est pas trop génant pour le moment car X n'utilise que des drivers 2D qui eux sont libres, si X devient une application 3D, tu fais quoi en cas de plantage de l'OS?
Les developpeurs du kernel ignoreront le rapport d'erreur pour cause de driver propriétaire..
--> moins de rapport d'erreur utilisable pour le kernel.
--> un OS moins stable, super!

Certes, il devrait toujours être possible d'utiliser OpenGL soft, mais bonjour les performances--> peu de gens le feront..

Bref, pour moi transformer X en client OpenGL n'est *pas* une bonne idée tant que les drivers 3D resteront propriétaire, ce qui risque de durer longtemps..

Sun mets des ANNEES pour corriger des bugs, spécialement sur Swing et compagnie donc en "années Sun", 99 ça ne fait pas si longtemps..

Et pour ton info, à cette époque là, le marketing de Sun poussait Java pour faire des interface graphique, sauf que Java n'était pas près du tout..

Un conseil pour ceux qui veulent faire sérieusement du Java: regarder d'abord la "bugparade", c'est amusant: il y a des problèmes importants qui sont toujours ouvert depuis des années: à étudier avant de se mettre à Java..

> - gestion en standard du multi-cpu

Le terme est multi-threading.

> - plein d'api gratuites

Certes, il y a des librairies pour faire tout même le café, mais il y en a pas mal qui sont buggés: Swing..

J'ai utilisé Java a l'époque du JDK 1.1.8 / 1.2.x, je me souviens de l'horreur pour imprimer..

Ok, j'aurais du preciser ce que j'entendais par gros gain, mais 20% en ajoutant un switch sur le compilateur moi je trouve ça plus que correcte!

Pour ce qui est des benchmarks, désolé, mais ce sont les seuls que j'ai trouvé, je pense qu'il y en aura d'autres le jour ou Windows sortira en version 64bit..