Pinaraf a écrit 3674 commentaires

Pour les performances de Looking Glass, ce n'est pas lié à Java mais plutôt à :
1- Nous et nos erreurs de programmation (je suis un contributeur du projet, je précise)... Exemple : on provoque de beaux memleak qui nous font garder en mémoire beaucoup de textures (c'est corrigé/en cours de correction dans le CVS là)
2- Java3D, mais ça s'améliore

Les différences de performances que l'on peut obtenir en corrigeant notre code montrent clairement que c'est pas la faute à Java...

Edgy n'accélère pas encore le boot. upstart n'a rien changé à la vitesse de démarrage pour l'instant.
Dans le futur ça changera, mais ça sera pour Edgy + 1.

Pour upstart, ça remplacerait cron/atd/anacron, inetd, l'init bien sûr, mais ça pourrait simplifier acpid, networkmanager... Par contre ça ne touche pas à udev.

Demande à Rasterman. Pour ma part, je pense qu'il parle du fait qu'il faille généralement des pilotes propriétaires, qui ont des problèmes de stabilité. Les pilotes libres en ont aussi d'ailleurs, il suffit de regarder un peu les mailing lists dri-devel.
Mais bon, je ne m'avancerai pas plus.

Xglx a un autre intérêt que tu ne mentionnes pas : il permet de tester la viabilité d'un serveur X qui fasse tout son rendu par l'OpenGL, et comme il partagera du code avec un éventuel Xegl, cela facilitera le développement de ce dernier. (Je suis assez pessimiste sur la possibilité de survie d'Xegl... Mais ce n'est pas le sujet).

Parce que bittorrent, c'est mieux :)

Tu n'as pas sorti le moindre argument. On met régulièrement le doigt sur la langue de bois des politiciens, mais apparemment celle de certains ici est bien chargée aussi.

Tu cliques sur Répondre pour dire un texte qui ne répond pas à mon commentaire. Quel est l'intérêt ?
De plus, relis moi : je n'apprécie guère Xgl. Ha oui, et aussi : les EFL c'est pas forcément de l'OpenGL parce que Rasterman préfère l'éviter. Mais c'est vrai, je connais pas.
J'attends de voir un Alt+Tab dans E17 qui affiche des miniatures mises à jour en live de fenêtres, incluant dans le tas une petite vidéo (dans un lecteur quelconque, qu'il s'agisse de Xine ou Mplayer, utilisant XVideo de préférence)

De même, tu tente de faire croire que X est propre et bien architecturé, ce qui est bien evidemment faux. Les EFL, si.
Démonstration ?

Tu confonds allègrement Xgl et X. C'est un piège facile qui s'est propagé avec le marketing de Novell.
Il est tout à fait possible de réaliser un composite manager utilisant l'openGl sans passer par la bidouille qu'est Xglx. Oui Xglx est une bidouille, je le sais et tout le monde devrait le savoir. Mais Xegl n'est pas une bidouille, et X.org avec aiglx non plus.
Pour info, un Composite manager utilisant l'OpenGL ça existe depuis au moins juin 2004, bien avant qu'on parle de Xgl. Et il gérait la vraie transparence, bien avant qu'on en parle dans E17 (vu qu'on n'en parle pas).

Au fait, les EFL c'est avant tout du rendu logiciel optimisé plutôt que du rendu OpenGL parce que Rasterman trouve l'OpenGL trop instable, ce en quoi il n'a pas forcément tord hélas...

Enfin, selon certains et des très sérieus tests de Rasterman.
Tests sérieux... Tu parles de son test avec son "wm torture" ?
Je l'ai testé. KWin 3.4 (je crois) contre Looking Glass l'été dernier. Sensiblement, l'utilisateur peut dire que Looking Glass consomme plus et est plus lourd que KWin. (Je l'affirme même... Il est particulièrement ardu de bosser sur ses performances. Bref passons).
Or avec le wm torture, Looking Glass est plus rapide que KWin. En effet, KWin dessine les fenêtres avant de les fermer alors que Looking Glass ne le fait pas... Les résultats sont donc faux, et je suis sûr que tous les résultats donnés par Rasterman ne prennent pas en compte ce paramètre.

De plus il n'a jamais présenté ça comme un benchmark (heureusement d'ailleurs)

Bien avant XGL, AIGLX, Compiz et tout les méchants hacks des codeurs X, les EFL était optimisé pour l'OpenGl et portait les ombres, les menus animées et la belle transparence.
Dis tu t'es renseigné un peu ?
Dire que le travail des développeurs de X c'est des hacks, c'est n'avoir rien compris au problème.
Les "ombres" dans E17, autour des fenêtres par exemple, c'est l'exemple parfait de la méthode "hack". Ces ombres sont dessinnées sur le bureau. Deux fenêtres se superposant n'auront pas d'ombres "d'une fenêtre à l'autre" (comme dit quelqu'un qui m'a posé la question... j'espère que sa formulation est claire, la mienne ne l'était pas).
La belle transparence, c'est aussi la même chose. Si tu déplaces un xterm sous un élément transparent dans E17, l'élément transparent n'affichera pas la fenêtre xterm. Ho si, il peut c'est vrai... la bonne vieille méthode des hacks avec les captures d'écran, super optimale. Essaye avec un contenu qui bouge comme une vidéo c'est mieux.
La seule méthode valable pour faire de la vraie transparence et des vraies ombres, elle passe par une extension dans X. Il n'y a pas d'autre solution. Il est irréaliste d'avoir chaque élément transparent du bureau qui fasse des captures d'écran de ce qu'il se passe derrière lui toutes les x millisecondes. Il doit être notifié des modifications, et modifier son affichage en fonction de ces modifications.

J'ai jamais dit que tu as dit que c'était la solution non plus, merci de ne pas me faire dire ce que je n'ai pas dit que tu as dit. :)

Avec les pilotes alsa 1.0.13rc1 c'est pas mieux hélas...

acpi=off c'est une solution pour un portable ?
L'un des objectifs après c'est d'avoir une veille fonctionnelle, donc en acpi=off c'est filochon...
Merci pour l'info sur alsa, on va essayer dès que possible.

Avec Edgy c'est pas mieux... Et vu les difficultés rencontrées avec Edgy (maintenant qu'il y a eu le freeze ça devrait aller mieux), on a changé pour debian.

(Je sais c'est pas moi l'auteur du post mais en fait c'est un pote... et je pense que c'est plus pratique pour lui qu'il suive son problème)

Comme dit l'autre, t'as pas du tester.
Voici un exemple simple : http://bugs.kde.org/show_bug.cgi?id=122803

Dans OpenOffice Impress, créer une présentation vierge. La première page est en mode plan. Tu supprimes les puces, et tu enregistres. Tu ouvres dans KPresenter : les puces sont présentes.
Les développeurs de KOffice ne peuvent rien faire : OpenOffice ne respecte même pas la DTD du format OpenDocument sur le coup.

Désolé, ça a en effet disparu des accords. Peut être lors du s/MSN/Live/..
(J'ai autre chose à foutre que vérifier toutes les semaines les éventuels changements dans un accord que je refuse)

Facile comme tout ça, tuer MSN...
Suffit de demander à Microsoft qu'ils fassent respecter le contrat de licence. Hop, épuration de tous les moins de 18 ans (premières lignes de l'un des contrats à lire et accepter). Le reste devient presque du détail :)

Pourquoi Jabber n'existe pas pour téléphone mobile ?
Jabber est un protocole. Ça change quoi le fait que ça soit mis sur un téléphone ?
Sinon pour info, les messages différés c'est sur Jabber depuis le départ.

La machine Java de sun est dispo pour AMD64 depuis plus de deux ans.
Par contre j'avais entendu parler de problèmes de plugin. Ça marcherait donc sous Konqueror mais pas sous Firefox. À voir.

Désolé, pour moi c'était sous entendu.

Le problème est "simple". Les pilotes propriétaires ont apparemment un planning de développement fixé.
Par exemple, pour ATI apparemment quand le pilote de juin 2006 sort, il a été terminé en mai 2006. Délai d'un mois.
Pour nVidia je suppose que c'est pareil. Ils doivent dire : on sort un nouveau pilote à telle date. Problème : quand un nouveau X.org sort, ils ont le choix :
1- Perturber leur calendrier
2- Faire patienter les gens

Je cherche pas à défendre leur erreur hein. Un tel modèle n'est clairement pas adapté au libre. L'idéal c'est des pilotes développés en même temps que X.org. Ainsi quand une mise à jour casse l'API voire l'ABI, pas besoin d'attendre...

Faut pas déconner, la carte ATI marche nickel sous Linux.
La preuve : je l'utilise.
Avec le pilote propriétaire : performances correctes, support de nombreuses fonctionnalités intéressantes pour un portable (activation à chaud d'un écran externe ou économie d'énergie par exemple), la veille marche out of the box...
Avec le pilote libre : la 3D marche, mais y'a pas toutes les fonctions d'économie d'énergie et ça chauffe plus, donc je peux pas encore l'utiliser. Mais ça devient bon.

Franchement, refuser ATI et accepter nVidia, y'a un ou deux ans, ok, mais la donne est en train de changer maintenant.

Oui, sauf que c'est exactement ce qui est dit : "D-Bus is a bit more complex than DCOP".

Par exemple, copier un gros fichier (genre une iso) est non seulement plus lent sous Linux, mais en plus ça me fait tout ramer (le curseur de la souris saccade, les autres applications mettent 3 plombes à réagir, et ne parlons pas d'ouvrir un programme à ce moment là !), et j'ai pu vérifier cela avec différentes distributions (Mandriva, Debian, Ubuntu, etc.).
Ça c'est fréquent quand le DMA n'est pas activé. T'as quoi comme chipset ?
Pour ma part, j'ai jamais vu de tels problèmes sur mes machines, par contre je l'ai déjà vu sur la machine de quelqu'un d'autre où la carte mère était en train de mourir... (et sous windows ça merdait tout autant)