tuXXX

C'est surtout que de toute façon y'a pas le droit de créer quoi que ce soit dans /sys/ (comme /proc/ en fait), ce sont des systèmes de fichiers "virtuels" qui sont gérés directement par le noyau.

Moi j'en ai un, sur un portable pas trop mobile (15"4) c'est pratique C'est pas vraiment pour utiliser pendant les déplacements, plutôt une fois rentré chez soi, pour un desktop replacement quoi. (Enfin là c'est un 17" donc c'est encore plus vrai, puisque c'est vraiment plus un transportable à cette taille)

Ben peut-être que windows garde un bout de la mémoire adressable pour le kernel (un peu comme sous linux avec plus de 1Go de RAM sans le HIGHMEM 4G), soit la carte mère n'accepte pas plus, ce qui est possible aussi.

Si la carte est pleine, essaye de la vider non?

À priori le multilib résout ça. Bon par contre je connais que gentoo qui supporte ça, mais bref, c'est pas un problème technique quoi. ( http://www.gentoo.org/doc/en/gentoo-amd64-faq.xml#multilib ) Aux dernières nouvelles, le créateur de Slackware a viré Gnome pour ne garder que KDE comme bureau, parce qu'il utilise KDE et que gérer à la fois KDE et Gnome c'est trop de paquets pour lui.

Et deux futurs joueurs de Duke Nukem Forever! (oui parce que Hurd sortira un peu après DNF)

Félicitations! (en photos c'est tout mignon )

Le plugin alsa marche bien, le seul problème ça reste les applis qui hardcodent "hw:0,0" (ça reste quand même plus simple de faire marcher des applis alsa avec pulseaudio que des applis oss avec alsa )

Ça date ce truc là En plus, y'a moyen de modifier plus les pages (mettre des conneries en plein milieu, etc.)

Déplacé ici dans le bar

"Direct 3D" ?

Je crois que les drivers libres ne supportent pas les r600 (radeons X1xxx et X2xxx) (donc toutes les cartes depuis octobre 2005). Je ne parle pas de la taille virtuelle (qui effectivement peut être très grosse puisque gérée par X directement), mais de la résolution réelle que la carte peut afficher (sur une/chaque sortie). Même aujourd'hui y'a pas beaucoup d'écrans qui peuvent faire du 2048x1536, et sur une radeon 7000/VE, qui est presque le truc le plus bas de gamme possible, c'est déjà très bien.

Ben en 2D je dis pas, mais c'est plutôt le reste : Xv, 3D, compiz, dual head. Les fonctionnalités des cartes graphiques ne sont pas juste la résolution maximale atteignable (j'ai une radeon 7000/VE qui est capable d'après les specs d'aller jusqu'en 2048 x 1536 @ 85Hz).

Merci, j'essairais de les réparer si je trouve le temps.

Pour la copilation il n'y a aucun problème : tout ce qui est compilé avec le noyau est libre avec le driver nvidia : il y a un .c qui fait le wrapper entre la partie binaire et la partie module noyau, et on a le code source, donc par rapport à ça la GPL est respectée. Ce qu'il y a après, c'est le concept de "derived work", et là c'est très contreversé. Par exemple pour Linus, quelque chose comme le driver binaire nvidia n'est pas un "derived work", et donc ne pose pas de problème par rapport à la GPLv2 : http://lkml.org/lkml/2007/6/15/284 http://kerneltrap.org/node/1735

C'est un wiki, pas une documentation officielle, donc pas à prendre comme une quelconque vérité absolue. Et ils parlent quand même plusieurs fois de glxgears qui n'est pas un benchmark, etc... Donc c'est pas si mal que ça quand même. Pour le nombre de FPS qui est "n'importe quoi", pour moi c'est leur interprétation qui peut être n'importe quoi, les chiffres eux-même sont juste un fait. Ce site n'a de rapport avec ubuntu que de nom, la vrai documentation concernant l'accélération 3D sur ubuntu c'est : http://doc.ubuntu.com/ubuntu/desktopguide/C/hardware.html . Ben tu dis que ce qui est marqué est stupide, c'est vraiment pas loin. Tu pouvais pas simplement dire que tu n'étais pas d'accord? Ça dépend comment c'est dit. Ceci est quelque chose dont on ne peut à mon avis pas déterminer pour l'instant de vérité formelle, le concept de "travail dérivé" étant une définition très floue. Pour certains, prendre un driver qui marche sur plein d'OS et le faire marcher sur le noyau linux n'est pas un travail dérivé (Linus par exemple).

... c'est : "mais n'importe quoi!!!" J'ai déjà vu glxgears me pondre un 90% d'utilisation proc sur un X2 ou un C2D, alors que la carte fonctionnait parfaitement fluidement avec UT2003, sans mettre le proc à genoux (glxgears était fluide aussi, note bien... juste qu'il me plombait le CPU va savoir pourquoi)... Tu cites : on parle de Xorg qui prend plus de 10%, ce qui signifie qu'il fait quelque chose au niveau de la 3D, et donc que c'est de la 3D logicielle, toi tu parles de l'utilisation totale, ce qui n'a rien à voir. (Si tu parles réellement d'utilisation X à 90% sur un ordinateur qui fait tourner UT2003 fluidement, je veux bien voir) Ensuite tu dis qu'un PC capable de faire tourner UT2003 sans problème (donc avec l'accélération 3D matérielle) utilise 90% de CPU sur un processeur dual-core... Alors de 2 choses l'une : soit tu utilises un dual-core avec un noyau non-SMP, et dans ce cas là tu utilise ton dual-core comme un simple processeur de base. Soit tu dis quelque chose qui n'est pas possible puisque glxgears ne peux pas utiliser plus d'un seul processeur (étant mono-processus), et donc pas plus de 50% CPU sur un dual-core. glxgears n'est pas sensé être "optimisé", c'est une application qui permet juste de tester glx en faisant tourner 3 roues en OpenGL... Il ne renvoie pas n'importe quoi, il affiche juste le nombre d'images qu'il peut afficher par seconde. Ça dépend de plusieurs paramètres et n'est pas du tout représentatif d'un quelconque jeu vidéo ou autre application, mais c'est pas "n'importe quoi". Si tu pars de glxgears, que tu augmente la résolution en 1280x1024, ajoute de la texture, quelques polygones, et tu as un jeu vidéo. Quelques shaders en plus et tu as un jeu vidéo récent. Pour moi, glxgears n'est pas si loin que ça d'un jeu vidéo, fonctionnellement, et n'affiche pas un nombre de fps aléatoire. Après effectivement, le fait qu'il soit simpliste n'en fait pas un bon benchmark, mais c'est une autre histoire. C'est un programme très simple qui (comme la plupart des jeux vidéos), contient une boucle du style : while(true) { drawWheels(); } Donc ça utilise le CPU au maximum, et c'est fait exprès. Non pour ça il faudrait balancer des shaders 3.0 + FSAA + Aniso sur des modèles 3D à plusieurs millions de polygones avec des textures multicouches de très grosse taille. Non, glxgears n'est pas un benchmark, et personne n'a dit ça. La méthode de regarder le "direct rendering = " dans le glxinfo n'est pas bonne non plus puisqu'on peut avoir de l'indirect rendering accéléré. En général, les gens veulent faire marcher une certaine application, sinon ils ne se soucient pas de la 3D. glxgears est parfois un bon outil de diagnostic. Personnellement, je n'ai jamais dit que glxgears était précis. Et de toute façon, quelqu'un qui utiliserait mal un outil comme glxgears aurait un problème tôt ou tard, donc ça n'est pas trop grave. Pour faire des benchmarks il y a de nombreux jeux libres (OpenArena, Nexuiz, Warsow, ...) qui font très bien l'affaire. Les joueurs le savent bien, les sites de tests informatiques le savent bien (phoronix par exemple). ... et ça, ça n'a pas de prix... Tu peux ne pas être d'accord, mais essayer de faire passer quelqu'un pour un idiot, 2 fois de suite, c'est totalement inacceptable pour moi. Le respect est à mon avis quelque chose de primordial. Aucune loi ne dit "Xfree86-DRI est obligatoire pour pouvoir accélérer des applications". Donc ce n'est pas "illégal"! Les différents drivers proprio utilisent leur propre chemin dans le driver, sans utiliser dri, et ça ne pose aucun problème juridique (au contraire, utiliser DRI avec des drivers non-libre, je ne sais pas si c'est autorisé par la license).

Tu as 11 jours de retard

Pour les specs de AD y'a pas trop besoin, Y'a samba4 qui est sorti en alpha et qui gère AD.

Je dirais d'essayer un autre logiciel, comme gqview par exemple.

Et virtualbox?

Pareil : j'ai téléchargé, double cliqué... ça m'a donné un "Impossible d'afficher « debian.exe ».", et c'est même pas du mono

http://bugs.gentoo.org/show_bug.cgi?id=183626 Et pour info, les drivers nvidia que j'ai actuellement (100.14.11) supportent OpenGL 2.1.1.

Pour l'afficher dans un tableau de bord, c'est bouton droit -> ajouter -> corbeille Et pour enlever celle du bureau c'est dans gconf : /apps/nautilus/desktop/trash_icon_visible (en gros dans /apps/nautilus/desktop y'a tout ce qu'on peut afficher sur le bureau)

Ben globalement, tu peux déjà installer tout ce qui est dans l'arbre portage de base de la distribution, ça ok. Et après on peut ajouter des "overlays" qui rajoutent des paquets supplémentaires, ces overlays soit tu utilise un outil layman (overlay manager) pour les récupérer, soit tu les prend directement toi-même sur des sites internet, soit fais ton propre overlay en copiant individuellement les paquets qui te plaisent. Au final c'est vraiment très permissif, ce qui je pense donne une bonne liberté (l'utilisateur fait ce qu'il veut)