Bar Le Linux BAR - Discussion de tout et de rien

[mezcalbert]

Pour ça, "glxinfo|grep direct" est tout aussi efficace... et pas de risque de confondre avec un benchmark...

Malheureusement... non! Chez moi, ça renvoie une erreur de type dysplay not found et DRI missing....

Or, tout fonctionne au poil. Bref, en me fiant à ça, je ferais une grossière erreur.

[Compte_supprime_74291]

S'il ne va pas chercher le bon display par défaut, rien ne t'empêche de faire un "glxinfo --help"...

... et là, ô, miracle! On peut choisir le display (à trouver en faisant "echo $DISPLAY" sur l'écran qui t'intéresse), ce qui pourrait donner un :

"glxinfo -display $DISPLAY" (ou en en utilisant un autre)...

... et là, si ça ne marche pas, tu as sûrement un driver bougrement foireux qui fait sa tambouille dans son coin comme un crade...

"glxinfo|grep direct" est la meilleure manière de vérifier proprement qu'on a bien une accélération avec dri, et "glxinfo|grep vendor" de savoir ce qui permet de gérer l'OpenGL (software, hardware, blob, ...)... ça implique d'apprendre à s'en servir, mais ça évite de finir par écrire des inepties comme :

vous voyez glxgears ou Xorg en tête des processus avec plus de 10% d'utilisation du temps processeur, c'est que vous n'avez pas d'accélération 3D matérielle

... et ça, ça n'a pas de prix...

[lorinc]

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

[Compte_supprime_74291]

Flexible, oui... ce qui fait qu'il donne plus d'informations que le "|grep direct", mais qu'il n'est pas forcément plus facile à interpréter par un novice...

Ca m'est souvent arrivé de tomber sur le PC de gens qui me disaient, "si-si, j'ai dri et tout, mais c'est tout lent, pourquoi?", ou d'autres qui croyaient qu'ils avaient l'accélération matérielle juste parce qu'ils avaient un cpu assez puissant pour rendre glxgears "assez" fluide... et pourtant, dans ces cas, le "|grep direct" disait "no", et le diagnostic imparable: pas de dri... pour dépanner à distance, c'est quand même ce qu'il y a de plus pratique...

Modifié le 17 octobre 2007 par Aefron

[mezcalbert]

S'il ne va pas chercher le bon display par défaut, rien ne t'empêche de faire un "glxinfo --help"...

... et là, ô, miracle! On peut choisir le display (à trouver en faisant "echo $DISPLAY" sur l'écran qui t'intéresse), ce qui pourrait donner un :

"glxinfo -display $DISPLAY" (ou en en utilisant un autre)...

... et là, si ça ne marche pas, tu as sûrement un driver bougrement foireux qui fait sa tambouille dans son coin comme un crade...

En faisant echo $DISPLAY, je tombe sur le :1.0, celui-là même dont glxinfo|grep direct me renvoie:

Xlib: extension "Xfree86-DRI" missing on "display "1.0".
direct rendering: no (if you want to fond out why, blah blah...)

Or, quand je fais "glxinfo display :0.0", j'ai Yes à direct rendering, etc... Bref, tout fonctionne nickel, mais glxinfo ne va pas chercher automatiquement le bon display. Et ça, c'est assez pénible pour le débutant.

glxgears renvoie la même erreur, mais permet de s'assurer malgré tout, au nombre de FPS, et sans la moindre erreur possible (différences trop importantes si pas fglrx), que tout est malgré tout bien fonctionnel.

[Compte_supprime_74291]

Si ton nom de display ($DISPLAY) est mal configuré, c'est la faute de ta distrib qui fait n'importe quoi, voire de la tienne si tu as trifouillé des trucs sans le savoir (ça peut venir d'une configuration inadéquate du xorg.conf, ou de la redéfinition de cette variable, voire de plusieurs cartes graphiques utilisées en même temps, sans redéfinir le $DISPLAY sur chaque screen X.org, ce qui est peu probable, vu que tu n'aurais vraissemblablement pas le dri sur ne serait-ce que l'un d'eux et qu'il y ait de fortes chances pour que X.org l'ait fait de lui-même pour en arriver au multiple GPU... mais vu que tu te dis débutant, je mets ça franco sur le dos de ta distrib, où on fait manifestement les choses comme des sagouins... tu balances le nom, par curiosité?)... sûrement pas de celle de glxgears... ce n'est pas à lui "d'aller chercher le display", mais à l'environnement de lui dire lequel c'est...

... si chaque appli doit vérifier si ce que l'environnement lui dit n'est pas n'importe quoi, à quoi servent les variables d'environnement? Réponse: à rien...

... en outre, j'aurais tendance à dire que là, tu as le devoir de bugreporter... d'autant plus vu le nombre d'applis qui s'attendent à tomber sur un $DISPLAY adéquat... si c'est un bug, m'est avis que c'en est un grave et bête (ça arrive... mais c'est le genre de choses qui doivent absolument être corrigées, d'où que ça vienne, fût-ce même des scripts crados qui permettent d'installer les drivers proprios comme un crado sur une certaine distro crado de chez crado dès qu'on gratte un tantinet la surface...)...

Modifié le 17 octobre 2007 par Aefron

[lorinc]

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).

[Compte_supprime_74291]

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).

C'est très tristement exact... et c'est encore quelque chose qui montre que les drivers proprios qui font leur tambouille de gorets sont ingérables... va diagnostiquer sans les outils classiques...

... perso, irl (oui, je sais, on s'en fouts) quand je tombe sur une machine qui en a et qu'on me demande de l'aide, je propose de réinstaller tout en repartant sur le driver libre, ou s'il n'existe pas d'équivalent libre, vesa (parce que vu la merde que foutent des trucs comme fglrx, en écrasant parfois certaines libs comme une truie, empêchant de passer au driver libre sans réinstaller X.org, je ne prends pas la responsabilité de mettre les mains dans ces choses... d'autant que les machines actuelles sont largement assez puissantes pour se contenter de vesa tant qu'on ne joue pas l'exigence des kikoololeries pyrotechniques à la compiz... d'autant qu'une bonne carte à drivers libres comme une X800XL vaut moins de 100¤), ou je réponds la même chose qu'aux ouineurs qui viennent vers moi en pleurant que leur os proprio cracké de partout déconne: "si tu ne veux pas écouter ce que je te conseille, ça ne me regarde plus, débrouille-toi avec tes cochonneries: tu es assez grand(e) pour bousiller ton OS en toute connaissance de cause"...

Edit: et au fur et à mesure, en général, on finit par m'écouter, et étrangement, il y a après beaucoup moins de problèmes qu'avant, avec les saloperies du genre envy et cie...

Modifié le 17 octobre 2007 par Aefron

[mezcalbert]

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...

xserver-xgl + compiz yep, et ça tourne farpaitement bien!

[Compte_supprime_74291]

ça tourne farpaitement bien!

... la preuve... le $DISPLAY est couillé

[mezcalbert]

ça tourne farpaitement bien!

... la preuve... le $DISPLAY est couillé

Bah, en dehors de ça, tout tourne. Par contre, si j'enlève les drivers proprios, ça perd méchamment en réactivité. Et bon, perso, la philosophie libre, j'adhère moyennement.

Donc, tant que je m'y retrouve dans mes activités habituelles, ça m'en secoue une sans toucher l'autre.

[Compte_supprime_74291]

Et bon, perso, la philosophie libre, j'adhère moyennement.

En passant outre l'illégalité des drivers proprios, ce n'est pas une question de philosophie... fait est que les drivers proprios font toujours leurs tambouilles comme des gorets et/ou que les gens qui veulent les inclure partout le font aussi (passer par un script hors-gestionnaire de paquet pour installer un module noyau est une habitude de master-goret, d'autant plus quand on n'est pas l'auteur du script)...

... ça débouche sur des inepties comme les reproches que tu fais à glxgears alors qu'il n'est en rien en cause... et qui te font conseiller une méthode hautement douteuse pour vérifier si on a l'accélération graphique ou pas...

... si c'est ça le progrès...

[tuXXX]

La seule chose que j'ai à dire là-dessus :

vous voyez glxgears ou Xorg en tête des processus avec plus de 10% d'utilisation du temps processeur, c'est que vous n'avez pas d'accélération 3D matérielle

... 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 absolument pas, mais alors, absolument pas, optimisé pour quoi que ce soit...

glxgears n'est pas sensé être "optimisé", c'est une application qui permet juste de tester glx en faisant tourner 3 roues en OpenGL...

et en général, il renvoie n'importe quoi en fps

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.

et utilise le proc n'importe comment...

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.

c'est d'ailleurs ce dernier point qui l'empêche en premier lieu d'être considérable comme un benchmark... il peut tellement tirer des resources bizarrement qu'on ne peut pas décemment classer les résultats qu'il renvoie, pas plus qu'il n'est optimisé que pour tirer sur le GPU en touchant le moins possible au CPU...

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é.

... après, la création d'un benchmark 3D libre, pertinent, et efficace serait une très bonne idée... malheureusement, il n'y en a pas vraiment... mais ce serait bien: ça éviterait d'avoir à se traîner cette cochonnerie de glxgears, complètement sous acides, que tellement de gens utilisent n'importe comment (en partant du postulat qu'il est utilisable pour quelque chose de précis)...

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).

mais ça évite de finir par écrire des inepties comme :

vous voyez glxgears ou Xorg en tête des processus avec plus de 10% d'utilisation du temps processeur, c'est que vous n'avez pas d'accélération 3D matérielle

... 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.

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).

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).

[Compte_supprime_74291]

Pour glxgears, j'aurais dû préciser que c'était un seul core qui était bouffé à 90%... ça tombait sous le sens pour moi, mais c'est vrai, j'aurais pu préciser...

J'ai relu mes propos sur le 90% d'un core que je dis explicitement bouffé par glxgears, ce que tu dis logique de cette manière :

Donc ça utilise le CPU au maximum, et c'est fait exprès

Je relis le texte extrait de la doc ubntubntu; pour eux, explicitement, ce n'est pas uniquement quand xorg dépasse les 10% d'occupation CPU, mais aussi quand glxgears le fait... la phrase est claire... et tu es le premier à être d'accord (cf ma quote de ton post juste au-dessus)... je ne vois pas ce que tu me reproches sur ce point... où as-tu vu que c'était X.org qui me bouffait 90% de CPU?

Ce pourquoi, d'ailleurs, j'estime qu'il renvoie n'importe quoi, c'est justement que ces chiffres n'ont pas une grande signification, et que se baser uniquement sur eux est extrêmement douteux... rien de plus, rien de moins...

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.

J'ai conspué une doc qui raconte, je persiste et signe, des inepties. Je n'ai fait passé personne pour un idiot. Ca me choque juste que le wiki d'une distro raconte des choses pareilles... surtout quand les gens finissent par les croire et par considérer les bonnes méthodes comme mauvaises...

... que ça ne te plaise pas, c'est une chose... mais je ne vois pas en quoi j'ai manqué de respect à qui que ce soit en taxant, à raison, un (et même des, c'est vrai) propos d'ineptie(s)... j'aurais dit que le gars qui a écrit ça était un con, soit, j'aurais abusé, mais permet-moi justement espérer ne pas être assez con pour en arriver là... là, je n'ai manqué de respect (à la limite, d'un peu de déférence, ce à quoi le respect ne se limite, heureusement, pas... comme j'ai pu le vérifier, avec soulagement) à aucune personne... on dit tous des conneries, moi le premier... ça ne fait pas de nous, définitivement, ni même vraiment ponctuellement, des cons...

Merci de ne pas déformer mes propos, en montant sur tes grands chevaux... pour le coup, le premier qui manque de respect, c'est toi. Venant d'un modo, je te laisse deviser à loisir sur l'inacceptabilité de la chose.

Quant à l'illégalité évoquée par Lorinc, j'imagine qu'il ne parlait pas bien sûr d'un hypothétique fait de devoir utiliser DRI... je le prends comme une allusion au caractère violateur de la GPL des drivers proprios, travaux dérivés du kernel, s'il en est, sous une licence incompatible avec lui... ils ne sont rien de plus que tolérés, ce qui ne les rend pas légaux pour autant.

Modifié le 18 octobre 2007 par Aefron

[tuXXX]

Je relis le texte extrait de la doc ubntubntu; pour eux, explicitement, ce n'est pas uniquement quand xorg dépasse les 10% d'occupation CPU, mais aussi quand glxgears le fait... la phrase est claire... et tu es le premier à être d'accord (cf ma quote de ton post juste au-dessus)... je ne vois pas ce que tu me reproches sur ce point... où as-tu vu que c'était X.org qui me bouffait 90% de CPU?

Ce pourquoi, d'ailleurs, j'estime qu'il renvoie n'importe quoi, c'est justement que ces chiffres n'ont pas une grande signification, et que se baser uniquement sur eux est extrêmement douteux... rien de plus, rien de moins...

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.

J'ai conspué une doc qui raconte, je persiste et signe, des inepties. Je n'ai fait passé personne pour un idiot. Ca me choque juste que le wiki d'une distro raconte des choses pareilles... surtout quand les gens finissent par les croire et par considérer les bonnes méthodes comme mauvaises...

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 .

... que ça ne te plaise pas, c'est une chose... mais je ne vois pas en quoi j'ai manqué de respect à qui que ce soit en taxant, à raison, un (et même des, c'est vrai) propos d'ineptie(s)... j'aurais dit que le gars qui a écrit ça était un con, soit, j'aurais abusé, mais permet-moi justement espérer ne pas être assez con pour en arriver là...

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?

là, je n'ai manqué de respect (à la limite, d'un peu de déférence, ce à quoi le respect ne se limite, heureusement, pas... comme j'ai pu le vérifier, avec soulagement) à aucune personne... on dit tous des conneries, moi le premier... ça ne fait pas de nous, définitivement, ni même vraiment ponctuellement, des cons...

Ça dépend comment c'est dit.

Quant à l'illégalité évoquée par Lorinc, j'imagine qu'il ne parlait pas bien sûr d'un hypothétique fait de devoir utiliser DRI... je le prends comme une allusion au caractère violateur de la GPL des drivers proprios, travaux dérivés du kernel, s'il en est, sous une licence incompatible avec lui... ils ne sont rien de plus que tolérés, ce qui ne les rend pas légaux pour autant.

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).

[lorinc]

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

The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language.

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...

Modifié le 18 octobre 2007 par lorinc

[tuXXX]

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

[Arofarn]

Bonne nouvelles !

Les Rencontres Mondiales du Logiciel Libres auront lieu à Mont-de-Marsan en 2008 !!!

Un petit coup dans le sud pour une fois

=> Site des RMLL

Il y avait un doute sur le déroulement ou non de RMLL en 2008 jusqu'à il y a peu. Normalement, ça aurait dû être décidé pendant celles d'Amiens et annoncé à la cérémonie de clôture.

[mezcalbert]

ubntubntu

[tyrann27]

J'ai remarqué que c'était devenu une mode ici...

On va faire une pétition pour préserver le nom "ubuntu"

Sinon on va y aller à coups de genetout et on trouvera bien pour debian

[lorinc]

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...

[Arofarn]

J'ai testé il y a peu une Knoppix et en mode "toram" et j'ai trouvé ça très très réactif: firefox quasi-instantannée, OpenOffice en 1 ou 2 secondes et le reste à l'avenant. Avec 2Go de RAM et un C2D ça pétais vraiment le feux par rapport à ma gentoo installée sur le dur.

J'ai vu aussi les prix de la RAM: moins de 70¤ pour 2Go....

Du coup, ça a fait tilt, pourquoi pas 2Go de plus et faire en sorte qu'une grosse partie des éléments exécutables soit copier en RAM au boot et resynchronisé à l'arrêt.

Je perdrais sûrement beaucoup de temps au démarrage et extinction, mais je ne redémarre pas souvent.

J'ai aussi calculé avoir besoin d'environ 2~2.5Go de RAM avec mon installation actuel (KDE, OOo, Firefox, Claws Mail + plein de petit truc)

Au niveau sécurité des données, j'ai un onduleur et des sauvegardes incrémentales journalières.

Quelqu'un à déjà fait ce genre de chose ? des suggestions ou des pistes pour ?

[ouragan]

20070209:

AFFECTS: users of x11/nvidia-driver

AUTHOR: danfe@FreeBSD.org

nVidia continues to drop support for old ("legacy") GPUs. To deal with

this fact, the port now allows to specify correct NVVERSION in order to

build driver that supports your graphics card. Currently, supported

"legacy" values are 7184 and 9631. Consult nVidia's README (Appendix A)

to find out whether you need to use legacy driver version, and exactly

which one. Alternatively, you can install one of the corresponding

`x11/nvidia-driver-XXXX' slave ports, where XXXX == needed NVVERSION.

ça c'est un ras le bol des dev freeBSD dans le fichier /usr/ports/UPDATING au sujet des drivers nvidia.

franchement, faut qu'ils libèrent tous leurs spec. ( et vite ! )

[lorinc]

J'ai testé il y a peu une Knoppix et en mode "toram" et j'ai trouvé ça très très réactif: firefox quasi-instantannée, OpenOffice en 1 ou 2 secondes et le reste à l'avenant. Avec 2Go de RAM et un C2D ça pétais vraiment le feux par rapport à ma gentoo installée sur le dur.

J'ai vu aussi les prix de la RAM: moins de 70¤ pour 2Go....

Du coup, ça a fait tilt, pourquoi pas 2Go de plus et faire en sorte qu'une grosse partie des éléments exécutables soit copier en RAM au boot et resynchronisé à l'arrêt.

Je perdrais sûrement beaucoup de temps au démarrage et extinction, mais je ne redémarre pas souvent.

J'ai aussi calculé avoir besoin d'environ 2~2.5Go de RAM avec mon installation actuel (KDE, OOo, Firefox, Claws Mail + plein de petit truc)

Au niveau sécurité des données, j'ai un onduleur et des sauvegardes incrémentales journalières.

Quelqu'un à déjà fait ce genre de chose ? des suggestions ou des pistes pour ?

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

[zoto]

20070209:

AFFECTS: users of x11/nvidia-driver

AUTHOR: danfe@FreeBSD.org

nVidia continues to drop support for old ("legacy") GPUs. To deal with

this fact, the port now allows to specify correct NVVERSION in order to

build driver that supports your graphics card. Currently, supported

"legacy" values are 7184 and 9631. Consult nVidia's README (Appendix A)

to find out whether you need to use legacy driver version, and exactly

which one. Alternatively, you can install one of the corresponding

`x11/nvidia-driver-XXXX' slave ports, where XXXX == needed NVVERSION.

ça c'est un ras le bol des dev freeBSD dans le fichier /usr/ports/UPDATING au sujet des drivers nvidia.

franchement, faut qu'ils libèrent tous leurs spec. ( et vite ! )

salut

Cela fait que certaine carte legacy n'ont pas de driver pour des kernel recent .

J'ai une Geforce4, c'est vieux je sais, mais si je veux un kernel recent sur ma debian je ne peux pas avoir de 3D avec les drivers nvidia .

Car je suis en legacy et ça compil pas .

a+