lorinc

c'est pas sexy, linux ? Si c'est à sworder, c'est à sworder, hein

ça doit être une histoire de répertoire d'installation. cherche dans le configure si tu n'as pas une option du style --with-gtkgl=/path/to/gtkgl auquel cas il faut lui donner le repertoire dans lequel gtkgl a été installé

le navigateur de fichier 3D existe bel et bien et à été développé par Sgi pour Irix ! http://en.wikipedia.org/wiki/Fsn

pfff, y a plein de trous de sécu là-dedans. http://seclists.org/fulldisclosure/2004/May/0347.html

T'as raison ! Deux futurs utilisateurs de hurd sur PCI !!!

ouais, deux futurs linuxiens de plus sur pci

un peu comme gnome

l'idée n'est pas mauvaise, mais il y a intérêt à ce que le plugin pour alsa soit plus que fonctionnel...

genre, y a surtout moyen de faire des redirections totally random : tu tapes google.fr, et tu tombes sur un site de fabrique de cornichon malossol...

J'aurais ma réponse tu veux pas faire un topic, ezt nous dire où ça plante exactement ?

y a randr 1.3 en cvs ? je me demande dans quelle mesure le dev du pilote radeon évolu encore. sinon, bravo pour le poste d'ater, j'espère que tu trouveras un poste après-ça (même si vu la conjecture gouvernementale actuelle, c'est pas gagné)

en parlant de 2D, il y a un test très récent de phoronix sur le comparo r300 vs fglrx, et le pilote libre sort vainqueur question affichage de fenêtre. Par contre, c'est vrai qu'il se prend une raclée sur la 3D... http://www.phoronix.com/scan.php?page=arti...m=903&num=1

whouuuu theo ça faisait longtemps

c'est pas hyper gruiiiiiik de le relancer comme ça, sans lui passer l'option -reload ?

une petite quote des forums de gentoo sur le dernier fglrx : http://forums.gentoo.org/viewtopic-t-60424...c-start-50.html

les nouveau fglrx ? y a plein de types qui reportent un paquets de problème avec les cartes non hd2k... En plus je suis pas sûr qu'il y ait un gain de perfs pour les vieilles cartes avec ces drivers... EDIT : je me permets de quoter un message du forum de phoronix : http://www.phoronix.com/forums/showpost.ph...p;postcount=206

hum. Ce qui fait gagner en réactivité au lancement d'un appli, c'est le fait que toutes les lib partagées soit déjà en RAM (et pas swapé out). Sachant que linux ne vire de la RAM (que ce soit en swap ou bien à la poubelle) que quand c'est nécéssaire, tu peux peut-être te faire un scripte qui lance pleins d'applis au démarrage et les kill peu après, ça devrait suffire (ça c'est pour le côté gruiiiiik), sinon une autre façon moins gruik : monter /usr/lib en RAM et copier dedans ce qui va bien. attention, y a moyen de casser des trucs en faisant ça (notament quand tu upgrade des packages, à voir si le prélink n'est pas dans les choux, etc...) La solution la plus mieux serait de regarder comment knoppix fait my 2 cents

c'est juste que dans "ubuntu" y a plein de u et qu'on sait jamais où les placer, alors rand() fait parfaitement l'affaire tuXXX, tes imagettes de signatures sont toutes cassées...

pour la consomation cpu, chaque cpu/core est compté jusqu'à 100% et ce depuis l'hyperthreading. Je vois quotidiennement les bi-xeon hyperthreadés et les quad-opteron du labo tourner entre 300% et 400%. Ce qui peut sembler bizarre au premier abord, mais reste parfaitement logique. Autre chose sur le sujet, avec le changement des library de threads, les applis multi-threadées peuvent être répartient sur plusieurs cores. Exemple, j'ai une appli (un process) java multithreadée (java utilise les threads de l'OS) qui top souvent à 150% de cpu. Faudra que je me documente mieux là-dessus, parce que je pensais que les threads au sein d'un LWP ne pouvait pas migrer sur un autre cpu/core et qu'un LWP était nécéssairement attaché à un cpu/core... Concernant la légalité des blobs, elle est clair et nette : tout ce qui est compilé/linké avec un morceau de code GPL doit être GPL ce qui est le cas des blobs puisqu'ils incluent des références au noyau (rien qu'un include d'un header GPL et tout le code doit être GPL). Pour étayer mes dire, tu veux vérifier sur les noyaux de certaines séries critiques (comme ceux avec le patch RT, peut-être même -mm), kmod refuse de compiler un module non GPL sur ces noyaux là à cause du symbole GPL_ONLY (pourquoi diable exporter ce symbole si ça n'a aucun fondement juridique...). La page de la fsf explique quelques cas de violation, et les similitudes avec les blobs du noyau sont flagrantes : http://www.fsf.org/licensing/licenses/gpl-violation.html Pour éviter ce problème de compilation/linkage, il y a la LGPL, mais le noyau n'est pas en LGPL. EDIT : une autre note de la FSF sur la différence entre GPL et LGPL : http://www.fsf.org/licensing/licenses/why-not-lgpl.html Je trouve que ça explique parfaitement les raisons pour lesquels Linus a probablement choisi la GPL pour le noyau et pas la LGPL, même si maintenant il préfère fermer les yeux sur les blobs. Enfin de compte, Linus faire de la mauvaise foi, c'est presque un pléonasme... EDIT 2 : le passage en question de la GPLv2 Quand tu fais un #include, le préprocesseur fait un copier/coller du texte contenu dans le fichier inclu dans ton fichier de code. Ton fichier de code contient donc une portion du code utilisé. Si jamais le header est GPL, ton code doit par conséquent être GPL. Or les headers du noyau sont GPL...

heu... Tu tournerait pas dans un Xgl tout pourri, par hasard ? genre le $DISPLAY est bon, mais effectivement ne pointe que vers un X virtuel qui ne peut pas avoir le DRI en tant que tel ? (je sais pas si je suis clair...) sinon ça arrive avec plein de blobs dégueux (plein, j'exagère) de ne pas avoir l'extension Xfree86-DRI, ça ne les empêche pas de faire fonctionner en hard un paquet de chose (illégalement).

le grep vendor est quand même le plus flexible dans cette histoire

la 9600 est bien supportée par le drivers libre, par contre, ça dépend de la version du package, il y en a certains où certaines fonctionalités sont cassées (genre la sortie vga auxilière sur les portables - pratique pour faire des présentations... )

Oui, mais ça, ça va: c'est pas cher

Tu ferais mieux de dormir pendant qu'il en est encore temps Va falloir recompiler le Sandeman pour architecture smp, sinon il ne tiendra pas la charge avec deux démons en parallèle

le serveur de DLFP à sauté...