Pinaraf a écrit 3682 commentaires

C'est faux, tout simplement.

http://www.quebecos.com/modules/news2/article.php?storyid=57

On peut tout de même remarquer quelques restrictions, notamment :
Vous vous engagez à utiliser les logiciels Microsoft dans un but exclusivement non commercial, et notamment à ne pas monnayer le produit du travail réalisé grâce aux logiciels téléchargés, ou à faire fructifier de quelque manière que ce soit l'utilisation de ces logiciels.

Bref, un étudiant qui programme en "free lance" (en langue IT) ne pourra pas avoir vista gratuitement.

On peut être geek et faire du Java non ?

Le fait est que c'est devenu péjoratif, synonyme de no-life devant son écran
Aïe
d'asocial un peu taré qui se nourrit de pizzas,
Houla
vit dans un bordel innommable dans une piaule d'étudiant remplie de vieux ordinateurs poussiéreux.

Bon bon bon
J'en déduis que je peux utiliser le terme "ingénieur informaticien" pour me décrire.

Le problème c'est que les geeks sont pas forcément sociables, fréquentables pour des personnes normales. Il se crée une sorte d'univers parallèle, où les geeks parlent aux geeks, et font peur aux autres. Le problème pour beaucoup d'entre nous, c'est que les autres nous font peur.
Moi personnellement j'ai déjà du mal à parler à des mecs, mais alors parler à des femmes c'est vraiment dur (je suis timide puissance 10). Surtout que j'en vois pas souvent, y'en a 3 sur les 70 élèves de ma promotion

Et puis j'ai tendance à pas emmerder les gens sauf si ils me posent des questions. Donc il faudrait qu'une fille me voit en train de coder ou un truc comme ça et lance la conversation. Or je code principalement dans ma piaule, et la présence d'une fille dans ma piaule est peu probable pour les 10 prochaines années (parti comme je suis en tout cas)

Une extension pour la redirection d'évènements dans X.org existe depuis au moins 2 ans (Xevie).

Où est le problème, concrètement, dans la "méthode" utilisée par Looking Glass ? Elle est plus chiante à implémenter certes, et dans le cas de Looking Glass on y perdait beaucoup en performances jusqu'à un changement récent (on a supprimé des conversions YUV/RGB notamment). Il n'est plus sûr que l'utilisation de texture_from_pixmap améliorerait les performances, et il n'y a pas d'une technique plus "bidouille" que l'autre. Dans un cas, la conversion est réalisée par un appel GLX, dans l'autre cas elle est réalisée dans l'application directement.

Le problème avec Fuse, c'est que, contrairement aux translators du Hurd par exemple, tout n'est pas en espace utilisateur. Tu gardes un genre de "proxy" en espace noyau. J'avais déjà essayé de coder un FS Fuse, et j'avais fait une erreur de programmation qui avait planté mon FS. Fuse n'a pas voulu le démonter, umount non plus... Obligation de redémarrer la machine.
Avec un système vraiment conçu pour ça, un tel problème n'existe pas.

Les KIO et gnome vfs ne souffrent pas de ce problème en implémentant tout en espace utilisateur, mais ça pose le problème de la compatibilité avec les applications.
De plus FUSE n'est pas forcément plus rapide que les KIO ou gnome vfs. En effet, avec FUSE, il y a des promenades entre l'espace noyau et l'espace utilisateur, qui sont très "lentes" par rapport à des communications entre processus dans l'espace utilisateur.
On ne peut pas tout avoir :/

Pour info, il existe un FS fuse qui sert de miroir pour les KIO.
http://kde.ground.cz/tiki-index.php?page=KIO+Fuse+Gateway

Les KIO gèrent correctement les droits, y'a pas de problèmes pour sauvegarder sur un FTP et surtout y'en a déjà une floppée de disponibles (http, https, ftp, sftp, fish, smb...)

Je cite : Performance sucks right now, but should improve before 0.4.0 final, when a multi-threaded event loop and kernel caching support are working (both of these should be easy to implement, FUSE provides the kernel caching).
Traduction approximative :
Les performances sont lamentables actuellement, mais devraient s'améliorer avant la version 0.4.0 finale, quand une boucle d'évènements multi-threads et le support du cache seront fonctionnels (ils devraient être simples à implémenter, FUSE fournissant le cache)

Qt4.2 a un thème très proche de clearlooks par défaut quand on l'utilise avec gnome. Il est aussi capable de replacer les boutons des fenêtres dans l'ordre classique de gnome...
Alors que wx, sous KDE, c'est look Gtk et c'est tout. Avec gtk-qt, c'est moins pire, mais pas vraiment mieux non plus.

Actuellement, c'est plutôt utilisé comme ça, pour des démos de technologies de présentation aussi...
Mais je ne sais pas dans quelle direction ça va aller pour le "marketing".

C'est dommage, l'auteur de l'article dit ... le contraire
Like the current open-source ATI display drivers, once completed these open-source NVIDIA drivers will likely perform significantly lower than the closed-source NVIDIA drivers, but should be suffice for desktop usage.

Comme les pilotes ATI open source, une fois terminés ces pilotes nVidia open source devraient être significativement moins performants que les pilotes propriétaires, mais cela devrait suffire pour une utilisation "de bureau".

Honteux... "ou peux-tu t'en charger" bien sûr

Merci pour cette réponse.

Serait-il possible de se contacter par mail (j'ai activé l'adresse DLFP sur mon profil) pour que je puisse envoyer une version résumée ou au contraire complétée de cette critique sur la mailing list du projet, où peux-tu t'en charger ?

Je suis d'accord, ça manque franchement d'applications.
Le problème étant que les gens préfèrent passer leur temps à se plaindre sur des forums quelconques plutôt qu'à tenter de contribuer ou soumettre ne serait-ce que des idées.

Pour info, Looking Glass n'est pas un WM. Le but premier du projet n'est pas à ma connaissance l'intégration d'applications 2D sur un environnement 3D, mais le développement d'un environnement entièrement en 3D, applications comprises.

Par exemple, les applis QT/KDE donnent l'impression d'être lentes car elles n'attendent pas que toute la fenêtre soit "dessinée" avant l'afficher, ce qui provoque l'apparition de l'appli comme des briques de légo qui s'emboîtent.
Ha... Jamais ressenti ni vu ça... (pourtant j'utilise que des applis Qt/KDE)

Pour moi, les performances, c'est un WM qui ne consomme pas les ressources du CPU et RAM comme un 4x4 qui pompe de l'essence.
Néanmoins, si c'est le seul critère qui compte, tu vas utiliser un WM comme ion ou fvwm... Les fonctionnalités sont aussi à prendre en compte.

Les parties non portables sont isolées. Elles sont juste spécifiques à X11, pas à Linux.

Les différences sont importantes entre les deux environnements :
1- sous Linux, il y a deux parties supplémentaires : le toolkit AWT, et l'intégration X11
2- Java3D : je sais pas ce qu'il vaut sous windows, je sais pas si c'est DirectX ou OpenGL...

Sous windows XP...
Après je sais pas du tout ce que ça vaut sous windows, sous Linux ça devrait pas poser de problème (sauf éventuellement le pilote)

La machine virtuelle de Java 7 est libre, le compilateur est libre, la bibliothèque de classes est en libération "progressive" : en effet, il y a encore des morceaux de code n'appartenant pas à Sun (exemple : des classes liées au rendu des polices). Donc la libération complète de l'environnement Java va avoir lieu progressivement, et d'ici quelques mois tout ce qui est libérable sera libéré, et les "blobs binaires" (appelons les comme ça) seront progressivement remplacés par des composants libres si la communauté participe. La communauté doit aider au remplacement de ces composants, c'est la condition sine qua none pour l'obtention d'un environnement Java 100% libre.

Je n'ai pas de chiffres exacts sur les performances. De toute façon, les performances d'un WM se basent uniquement sur un sentiment, pas sur des données chiffrables, mesurables.
On peut bien sûr s'intéresser aux performances d'applications clé :
- Outils bureautiques divers
- Navigateur web
- Lecteur de vidéo
- Jeux

Les deux premiers cas ne devraient plus poser le moindre problème. Les lecteurs de vidéo posaient encore un problème lors de mon dernier test car X.org 7.1 n'était pas dispo à l'époque, et donc il n'était pas possible d'utiliser XVideo avec un composite manager (il faudrait que je reteste). Pour les jeux utilisant OpenGL, même problème. Les performances avec les pilotes nVidia, lors de la sortie de la première bêta des pilotes permettant la redirection d'affichage d'applis OpenGL, étaient assez faibles.
Maintenant, de très nombreux problèmes étaient liés, à l'époque, à l'utilisation des composantes RGB pour les textures des fenêtres à la place de YUV actuellement. Le passage à YUV a augmenté les performances a priori (m'en demandez pas plus, c'est pas mon domaine).

Donc à tester.

Sinon, niveau ressources demandées : le site est franchement à côté de la plaque. Le problème, c'est qu'on ne sait pas trop. Il semblerait que la config minimale tourne autour de :
- processeur à 1 Ghz
- 512 Mo de mémoire vive (sachant que l'environnement n'en bouffait pas plus de 80 il y a un an)
- une carte style Geforce 4 Mx avec 64 Mo de mémoire vidéo

C'est une réponse rapide vu que je suis, comme qui dirait, en cours.

1- J'allais rédiger une dépêche demain ou samedi
2- Je suis toujours contributeur
3- Tout le code de Looking Glass est sous licence GPL, je vois pas le lien avec la licence de la JVM (au passage, Looking Glass nécessite désormais Java6)

Oui, et donc je pige pas d'où tu sors tes chiffres abracadabrantesques, pour reprendre quelqu'un.
Pypy traduit en C et compilé, c'est plus lent que CPython (plus de 3 fois plus lent avec le SVN actuel). Le binaire généré est de plus très lourd, et toute la librairie standard n'est pas implémentée.