Les cartes nvidia ne sont pas toutes pour les jeux. Je sais bien qu'ils poussent leurs geforce mais il y a aussi les quadro (d'ailleurs nvidia vient du marché professionnel, puisque ce sont des ex employés de SGI), qui sont bien des cartes professionnelles, on le sait rien qu'en regardant leur prix ;) (d'ailleurs on ne peut se baser que sur le prix, il y a sinon peu de différence entre une geforce 2 et une quadro 2 : http://www.geocities.com/tnaw_xtennis/G-Quadro-2.htm(...) , encore une boîte qui vend du matos bridé)
Un thread a été généré par la news de Guillaume Maillard sur osnews, voir http://xfree86.org/pipermail/render/2002-October/002041.html(...)
Où entre autres ils expliquent entre autres qu'il faut que les programmeurs d'applications X y mettent un peu du leur, notamment en utilisant le backing store ;)
J'ai essayé de prendre quelques fenêtres ee et j'en ai déplacé une devant les autres : ca va nettement plus vite qu'avec des fenêtres normales (pas vu de traînées) et ça bouffe nettement moins de cpu. C'est peut-être une bonne manière d'accélérer l'affichage sous X.
Là, ça m'interesse. Dans un wm que j'écris je reçois que des "expose" et du coup je redessine brutalement tout le cadre (je parle ici de wm car je pense que c'est vrai pour toute appli X, y compris les wm). Et je trouve ça très nul. Par exemple, quand j'ai mis une fonte freetype j'ai été obligé de la cacher dans un pixmap pour pas que ça lague de partout.
Je trouve que c'est quelque chose qui manque à l'open source : quelque part où les gens qui veulent faire un projet puisse se trouver. Ca éviterait d'avoir plein de projets sourceforget qui font la même chose et qui ne démarrent pas. J'ai pensé faire un site là-dessus mais personne n'irait dessus, ça ne règle donc pas le problème.
Evas va utiliser ce qu'il trouve pour accélérer le rendu, entre autres OpenGL. L'avantage est que si il n'y a pas d'opengl il y aura des solutions "moins accélérées" de secours.
Le problème est que evas est loin d'être écrit, pour l'instant je crois qu'il n'y a qu'un seul mode de rendu.
Alors si vous voulez que XFree soit plus perfomant, plus fonctionnel etc... engagez vous ! ;-))
Ca me donne une idée : pourquoi linuxfr ne pourrait-il pas aider à fédérer des projets ? Après tout c'est parfaitement dans l'esprit du logiciel libre et il y a plein de développeurs dans le coin.
Par exemple : news sur XFree, il y en a qui trouvent XFree trop lent, on pourrait alors décider de réimplémenter (je dis n'importe quoi là) les fonctions de copie de pixmap pour qu'elles utilisent des blit en hardware si elles sont exécutées en local. Il pourrait y avoir une petite boîte dans un coin avec la liste des volontaires pour faire ça et tout...
En plus, on augmente les chances d'aboutir d'un tel projet, si assez de monde y participe (et ça a l'avantage indéniable de motiver des glandeurs comme moi).
Ca peut se faire un truc comme ça ? Vous pensez que ça peut marcher ?
Mais il doit être tout à fait possible, d'optimiser le système, notament éviter que GTK/QT redessine toute la fénètre à chaque fois.
Malheureusement les concepteurs de X ont fait confiance à ceux qui écrivent les applis en se disant qu'ils n'allaient pas trop pousser sur le temps de rafraîchissment de la fenêtre. Ce n'est pas ce qui s'est passé.
En plus, la fenêtre ne peut recevoir qu'une demande pour tout redessiner. Donc si il y a un seul pixel à redessiner et même si le window manager peut s'en rendre compte il est obligé de demander à l'appli de redessiner tout. Peut-être qu'une extension pourrait faire ça ?
Sinon, ne touchez pas à notre X qui marche sur le résau, hein parce que moi j'en ai besoin tout le temps !
Si cela était à un prix abordable (c'est à dire en sorte que je puisse me payer ces CD sans me priver par ailleurs), j'aurais été content de moi aussi ^etre réglo et de jouir d'une belle pochette de CD.
Oui, surtout quand ils font des promos où leurs cds voient leurs prix divisé par 3. Là on voit vraiment qui fait des gros profits dessus : les revendeurs. Le prétexte de la rémunération des artistes est bien maigre tout à coup : si les maisons de disque voulaient vraiment rémunérer les artistes, elle pourraient largement le faire saus augmenter de manière visibe le prix des cds. Maintenant ils essayent de nous imposer leur nouveau format multicouche qui éloigne encore un peu de la culture celui qui ne peut pas se payer une chaine hifi dernier cri, et leurs cds protégés ( http://uk.eurorights.org/issues/cd/quick/(...) ), et bientôt sûrement les deux en même temps.
Je m'en fous j'ai pas de lecteur dvd. Et j'en aurai pas avant de pouvoir me permettre l'achat du graveur correspondant.
Ah j'oubliais.
Je crois avoir vu quelque part qu'avec les bons réglages le client donkey pouvait se comporter gentiment avec tout le monde. Mais je ne les connais pas. Quelqu'un les a ces réglages, ou sait-il si c'est possible ?
C'est plus qu'un patch.
Lugdunum ( http://lugdunum2k.free.fr/index.html(...) ) est le nom d'un des gros serveurs de donkey dixv français. Ils écrivent aussi des patchs pour le serveur donkey qui portent leur nom.
Le problème du réseau donkey est qu'il repose sur une confiance réciproque entre les utilisateurs : si un client demande plus souvent des sources au serveur, il aura une meilleure vitesse de d/l au détriment de tous les autres (po juste). Donc ce n'est plus vraiment du partage équitable (c'est aussi egoïste que d'interdire l'upload). C'est pour ça que certains clients donkey comme mldonkey mais aussi donkey bot ont étés plonkés (plus précisément, les utilisateurs se font plonker leur ip pour une certaine durée dès que leur client est détecté). Tous les gros serveurs francophones (ceux qui nous intéressent, quoi) utilisant ces patchs (qui accélèrent considérablement le serveur il faut le dire), ça veut dire que si lugdunum décide d'interdire l'accès à ces clients il ne reste pas des masses d'autres serveurs.
Là où c'est plus décevant, c'est que l'auteur de mldonkey était en discussion avec les adinistrateurs de ce serveur pour améliorer le comportement de mldonkey (et donc surtout que mldonkey soit déplonké), et apparement ça n'a pas abouti. A mon avis, la solution serait que mldonkey devienne un client "équitable". En attendant il est très dur de trouver de bons serveurs qui acceptent ses connections.
Sinon, la détection de mldonkey se fait sur le surnombre de requêtes qu'il envoie au serveur. Donc il n'y a pas moyen d'empêcher le plonkage des clients mldonkey à moins de les rendre "équitables".
Peut-être que si on evoie des mails gentils à l'auteur pour lui demander un client "standard" ça va le motiver ? Ou peut-être même que l'auteur lit ce commentaire, vu qu'il est français ?
urpmi est "cassé" parce qu'il est écrit en perl et que tu as cassé perl (et/ou un des nombreux modules perl). Donc réinstalle perl (avec rpm du coup) et ça va marcher. Je te jure que je m'en suis sorti comme ça en 5 min.
il y a rien eu d'installe sur cette machine en dehors des cd de 8.2 et depuis les states c'est pas simple de faire l'install CD... Bon je sens que l'on va la jouer subtile et faire la "mise a jour" aprtir des cds... (j'espere que cela va pas casser les trucs que j'avais fait, mise en place du son et du scanner par exemple...)
Euh, je crois que ton urpmi est cassé (il est en perl). Donc il faut d'abord remettre perl et tous se amis (les nombreux packages perl-*). Ensuite tu devrais pouvoir réutiliser urpmi. Il m'est arrivé le même truc et j'ai fait comme ça (ça m'apprendra à forcer l'install de n'importe quoi ;).
Arglll j'aime pas les rpm, tiens tant qu'il y a des specialistes rpm et urpmi pourquoi lorsque l'on fait l'installe d'un paquet avec urpmi (chais plus lequel mais cela devait etre vlc) il me dit libpng.so.2 not found et que lorsque je fais un petit "ls -l /usr/lib/libpng*" j'ai bien un lien vers la libpng.so.3!!! On peut m'expliquer sur le coup la!!!!
Bah justement il cherche libpng.so.2. C'est un problème connu de la mandrake 8.2. Un petit lien symbolique l'a résolu chez moi.
PS : les questions mandrake dans les commentaires d'une news debian, c'est quand même un peu provocateur ;)
les performances d'un tel système *conçu* pour les µk et tirant parti de L4 (notamment des LIPC, etc.) pourraient être excellentes.
Pour l'instant ce n'est pas le cas. Je surveillerai néanmoins tout ça de plus près maintenant ;)
2/ le DGA sous GNU/Linux, il faut avoir les droits roots. Avec un protocole bien conçu, il est possible de faire sur un multi-serveur sans avoir de droit root (juste un token "dga")
Ca peut se faire aussi sous linux, mais ça n'existe pas encore, c'est en développement :))
Fais-le, et on verra.
Voici la méthode que je propose :
le processus fait appel à une fonction write() sur une page
write() marque la page en question non writable(et on la locke en ram) (ou encore mieux, utiliser un genre de copy on write !)
...
l'appel d'écriture asynchrone se fait
on marque la page writable à nouveau (et on la delocke) (ou on la détruit si on a fait le pseudo copy on write et qu'on a fait une copie entre temps)
Si entre temps le processus a tenté une écriture sur cette page on peut
l'intercepter et l'endormir. Ou si on a fait le pseudo copy on write il peut continuer, et on ne procède à la copie que si c'est nécessaire.
T'en pense quoi ?? Ca m'a l'air pas mal, mais il doit y avoir un problème sinon tous les noyaux monolithiques feraient comme ça.
Là, j'aimerais bien savoir comment.
L'idée est d'utiliser les niveaux de privilèges non utilisés sur x86 de la manière suivante :
On rajoute un privilege level de 1 (et si on veut de 2 aussi) contenant les fonctions autorisées avec moins de droits (celles que pourront lancer un programme qui a besoin de droits mais qui ne devrait pas être root). Au lancement d'un proc on le marque en fonction de son "niveau de cpl sous-jacent" (hum, j'espère que tu vois ce que je veux dire, c'est mal expliqué). Lorsqu'on fait un appel système, il est opéré par le cpl sous jacent correspondant si le programme a le droit de le faire, sinon... Et les cpl de 1 et 2 ne touchent pas à 0, donc ce qu'on voulait faire est accompli.
Problème : toutes les architectures n'ont pas 4 niveaux de privilèges :(
Le reste du débat micro noyau/monolithique m'apparaît de plus en plus comme une question de point de vue personnel. J'attends toujours un bench complètement neutre sur la chose.
C'est bien ce que je craignais c'est tout cassé :(
Une solution serait que tu forces la reinstallation des packages de la 8.2 (avec rpm et pas urpmi) et ensuite refaire la manip.
D'abord :
> urpmi.update -a
(bourin)
ou
> urpmi.update [un miroir]
(plus fin)
puis
> urpmi --auto --auto-select
C'est prêt, vous pouvez déguster
Je l'ai fait sur 3 machines sans problème.
Sinon, si tu a cassés ta base de données rpm :
rpm --rebuilddb
T'as rien compris à l'article. Il compare L4Linux et Linux. Bien évidemment un port de Linux au-dessus de L4 à coup de glue-code est plus lent que Linux en natif. Le but de cet article n'est pas de comparer L4 et Linux (ce qui n'a pas de sens) mais de comparer L4 et Mach dans le cadre de L4Linux et de MkLinux.
J'attendais ce contre argument. Mais justement, au début de l'article, l'auteur mesure l'overhead de l4linux à 5%. Et la différence de perf linux/micro noyau est de plus de 5%. Donc...
Ça et le reste du paragraphe montre que tu n'as rien compris à la philosophie des micro-noyau. Dans un système à base de micro-noyau 'idéal', le serveur d'affichage 'mappe' la mémoire vidéo dans son espace d'addressage à lui; le client qui veut afficher des textures fait un IPC vers le serveur d'affichage en passant les données à placer via des flex-pages (pour prendre la sémantique L4). Le serveur d'affichage fait la copie et rend la main. Coût total: un RPC. Aucune copie superflue. Tu perds quoi, concrètement ?
J'ai besoin d'un appel au serveur d'affichage à chaque fois que j'affiche un truc. A comparer au dga, seule méthode qui me permet de jouer des divx sans saccades sur ma machine.
Prenons un autre exemple: une écriture sur le disque. Sur un noyau monolithique, tu appelles write(), qui copie les données dans le buffer du driver et ensuite les écrit. Sur un système à base de micro-noyau, tu passes tes flex-page contenant les données (donc, juste un IPC faisant un 'grant' sur les pages, aucune copie) au driver, qui 'pin' les pages en mémoire (pour éviter qu'elles ne soient swappées) et démarre le transfert DMA. Total: aucune copie n'a été réalisée.
Oui, mais qu'est-ce qui m'empêche d'implanter la même optimisation sur noyau monolithique ?
Tu peux comparer ça à ce qui est présenté dans http://l4ka.org/publications/files/os-protectio(...) ? On joue pas dans la même catégorie là... Avec tous tes ACLs et des patchs grsecurity, login, sshd et *ftpd tournent toujours en root sur ta machine, je te signale.
Effectivement, on a un avantage au niveau de la securité (que je n'ai pas nié). Mais je préfère la rapidité. Les mechanismes de sécurité de Linux me suffisent largement. Et pour l'instant ce genre de choses j'attends de le voir tourner.
Et il reste sur les processeurs x86 deux niveaux de privilège d'exécution non utilisés qui pourraient être utilisés pour ça.
Voila, merci de m'avoir fait me replonger dans les micro noyaux, ca fait un certain temps que j'y avais pas regardé et ça a l'air d'évoluer en bien.
Je te cite : Bref, tu n'as toujours pas compris qu'un serveur indépendant est infiniment plus facile à déboguer que la même portion de code dans Linux.
Je me cite (très narcissique comme truc) : Evidemment, un noyau monolithique est plus difficile à mettre au point (pas de droit à l'erreur, sinon on plante tout le noyau)
Pour tes problèmes de driver nvidia (que tu installes et utilise même si tu les trouves nuls), tu ne veux pas les résoudre, la preuve tu ne décris pas précisement tes problèmes/ton matos. Ou peut-être ces problèmes n'existent pas (et il s'agit d'un FUD aussi primaire que ceux de microsoft).
Je t'ai expliqué ce qu'était un serveur, mais tu ne veux pas apprendre. Exit donc la discussion avec toi.
Bref prends exemple sur Gaël Le mignot (plus bas) qui m'oppose des arguments valables au lieu d'insulter sans arguments.
Bon, tu as l'air de savoir ce qu'est un micro noyau.
Donc tu sais qu'il y a un noyau réduit au minimum.
Et que par dessus il y a des quelques "processus" qui tournent et qui effectuent des tâches que fait un noyau monolitique (gestion filesystem par exemple). Ces processus se nomment des serveurs (rien à voir avec un "serveur" dans le sens machine).
Donc quand je parle d'un "un serveur de filesystem qui plante toutes les 5 min" c'est un de ces serveurs-là.
Je n'ai jamais dit qu'un micro noyau n'etait pas stable (au contraire), j'ai dit qu'il n'était pas admissible de tolérer qu'un de ces serveurs plante, même si le reste tenait.
les plantages bihebdoadaires
Plantage de X ? De toute la machine ? T'es sûr que t'as pas un chipset via ?
fuites de mémoire à 500 Mo par jour
Qu'entends-tu par là ?
Si tu vois beaucoup de mémoire "utilisée" quand tu fais top, c'est l'"agp aperture size". C'est la partie de ram physique utilisée pour stocker les textures qui rentrent pas dans la carte video. Mais c'est pas utilisé vraiment ;)
l'affichage qui se déforme quand on change de résolution
Ca, ça dépend de la fréquence de rafraichissement. Les écrans ne sont capables pour la plupart que de mémoriser un réglage vidéo par fréquence de rafraichissement (exception notable : mon vieux targa 14' mais bon il est tout pourri). Donc on n'y peut rien, à moins d'utiliser des fréquences différentes pour chaque mode vidéo utilisé. Va donc bidouiller ton XF86Config-4 !
la mauvaise qualité de l'image en 2D
Ca, ca dépend du ramdac et non pas du chipset video. Donc c'est pas la faute de nvidia mais celle de l'intégrateur. Et au fait ça n'a rien à voir avec les drivers.
Non, dis moi où sont les problèmes. Je les ai installés chez moi et chez plusieurs potes et ils en sont tous très content. En plus ça m'interesse en tant que programmeur de savoir ce qui ne marche pas.
En gros, fais quelque chose de plus constructif que 'Pauvre naze" ;)
[^] # Re: Nouveaux pilotes Open Source et Linux rentre à la NASA
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche Nouveaux pilotes Open Source et Linux rentre à la NASA. Évalué à 3.
[^] # Re: XFree86 est-il assez rapide ?
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche XFree86 est-il assez rapide ?. Évalué à 1.
Ce dont on parle s'apelle le backing store. Voir comment ça marche sur http://tronche.com/gui/x/xlib/window/attributes/backing-store.html(...)
Un thread a été généré par la news de Guillaume Maillard sur osnews, voir http://xfree86.org/pipermail/render/2002-October/002041.html(...)
Où entre autres ils expliquent entre autres qu'il faut que les programmeurs d'applications X y mettent un peu du leur, notamment en utilisant le backing store ;)
[^] # Re: XFree86 est-il assez rapide ?
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche XFree86 est-il assez rapide ?. Évalué à 1.
[^] # Re: XFree86 est-il assez rapide ?
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche XFree86 est-il assez rapide ?. Évalué à 1.
Je vais me documenter sur comment récupérer cette liste de rectangles, j'ai des optimisations à implanter moi...
[^] # Re: XFree86 est-il assez rapide ?
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche XFree86 est-il assez rapide ?. Évalué à 1.
[^] # Re: XFree86 est-il assez rapide ?
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche XFree86 est-il assez rapide ?. Évalué à 1.
On commence par où ?
[^] # Re: XFree86 est-il assez rapide ?
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche XFree86 est-il assez rapide ?. Évalué à 1.
Je trouve que c'est quelque chose qui manque à l'open source : quelque part où les gens qui veulent faire un projet puisse se trouver. Ca éviterait d'avoir plein de projets sourceforget qui font la même chose et qui ne démarrent pas. J'ai pensé faire un site là-dessus mais personne n'irait dessus, ça ne règle donc pas le problème.
[^] # Re: E17 et Evas
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche XFree86 est-il assez rapide ?. Évalué à 1.
Le problème est que evas est loin d'être écrit, pour l'instant je crois qu'il n'y a qu'un seul mode de rendu.
[^] # Re: XFree86 est-il assez rapide ?
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche XFree86 est-il assez rapide ?. Évalué à 1.
Ca me donne une idée : pourquoi linuxfr ne pourrait-il pas aider à fédérer des projets ? Après tout c'est parfaitement dans l'esprit du logiciel libre et il y a plein de développeurs dans le coin.
Par exemple : news sur XFree, il y en a qui trouvent XFree trop lent, on pourrait alors décider de réimplémenter (je dis n'importe quoi là) les fonctions de copie de pixmap pour qu'elles utilisent des blit en hardware si elles sont exécutées en local. Il pourrait y avoir une petite boîte dans un coin avec la liste des volontaires pour faire ça et tout...
En plus, on augmente les chances d'aboutir d'un tel projet, si assez de monde y participe (et ça a l'avantage indéniable de motiver des glandeurs comme moi).
Ca peut se faire un truc comme ça ? Vous pensez que ça peut marcher ?
[^] # Re: XFree86 est-il assez rapide ?
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche XFree86 est-il assez rapide ?. Évalué à 1.
Malheureusement les concepteurs de X ont fait confiance à ceux qui écrivent les applis en se disant qu'ils n'allaient pas trop pousser sur le temps de rafraîchissment de la fenêtre. Ce n'est pas ce qui s'est passé.
En plus, la fenêtre ne peut recevoir qu'une demande pour tout redessiner. Donc si il y a un seul pixel à redessiner et même si le window manager peut s'en rendre compte il est obligé de demander à l'appli de redessiner tout. Peut-être qu'une extension pourrait faire ça ?
Sinon, ne touchez pas à notre X qui marche sur le résau, hein parce que moi j'en ai besoin tout le temps !
[^] # Re: mldonkey 2 est sorti !
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche mldonkey 2 est sorti !. Évalué à 1.
Oui, surtout quand ils font des promos où leurs cds voient leurs prix divisé par 3. Là on voit vraiment qui fait des gros profits dessus : les revendeurs. Le prétexte de la rémunération des artistes est bien maigre tout à coup : si les maisons de disque voulaient vraiment rémunérer les artistes, elle pourraient largement le faire saus augmenter de manière visibe le prix des cds. Maintenant ils essayent de nous imposer leur nouveau format multicouche qui éloigne encore un peu de la culture celui qui ne peut pas se payer une chaine hifi dernier cri, et leurs cds protégés ( http://uk.eurorights.org/issues/cd/quick/(...) ), et bientôt sûrement les deux en même temps.
Je m'en fous j'ai pas de lecteur dvd. Et j'en aurai pas avant de pouvoir me permettre l'achat du graveur correspondant.
[^] # Re: Mouai super bugué ...
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche mldonkey 2 est sorti !. Évalué à 1.
Je crois avoir vu quelque part qu'avec les bons réglages le client donkey pouvait se comporter gentiment avec tout le monde. Mais je ne les connais pas. Quelqu'un les a ces réglages, ou sait-il si c'est possible ?
[^] # Re: Mouai super bugué ...
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche mldonkey 2 est sorti !. Évalué à 1.
Lugdunum ( http://lugdunum2k.free.fr/index.html(...) ) est le nom d'un des gros serveurs de donkey dixv français. Ils écrivent aussi des patchs pour le serveur donkey qui portent leur nom.
Le problème du réseau donkey est qu'il repose sur une confiance réciproque entre les utilisateurs : si un client demande plus souvent des sources au serveur, il aura une meilleure vitesse de d/l au détriment de tous les autres (po juste). Donc ce n'est plus vraiment du partage équitable (c'est aussi egoïste que d'interdire l'upload). C'est pour ça que certains clients donkey comme mldonkey mais aussi donkey bot ont étés plonkés (plus précisément, les utilisateurs se font plonker leur ip pour une certaine durée dès que leur client est détecté). Tous les gros serveurs francophones (ceux qui nous intéressent, quoi) utilisant ces patchs (qui accélèrent considérablement le serveur il faut le dire), ça veut dire que si lugdunum décide d'interdire l'accès à ces clients il ne reste pas des masses d'autres serveurs.
Là où c'est plus décevant, c'est que l'auteur de mldonkey était en discussion avec les adinistrateurs de ce serveur pour améliorer le comportement de mldonkey (et donc surtout que mldonkey soit déplonké), et apparement ça n'a pas abouti. A mon avis, la solution serait que mldonkey devienne un client "équitable". En attendant il est très dur de trouver de bons serveurs qui acceptent ses connections.
Sinon, la détection de mldonkey se fait sur le surnombre de requêtes qu'il envoie au serveur. Donc il n'y a pas moyen d'empêcher le plonkage des clients mldonkey à moins de les rendre "équitables".
Peut-être que si on evoie des mails gentils à l'auteur pour lui demander un client "standard" ça va le motiver ? Ou peut-être même que l'auteur lit ce commentaire, vu qu'il est français ?
[^] # Re: Alors comme ça la Woody est difficile à installer ?
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche Alors comme ça la Woody est difficile à installer ?. Évalué à 1.
Pour la librairie libpng, ça devrait disparaître quand tu auras upgradé. Mais il y a pas mal de monde qui a eu le même problème :
http://mandrakeforum.com/print.php?lang=en&sid=1975(...)
[^] # Re: Alors comme ça la Woody est difficile à installer ?
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche Alors comme ça la Woody est difficile à installer ?. Évalué à 1.
Euh, je crois que ton urpmi est cassé (il est en perl). Donc il faut d'abord remettre perl et tous se amis (les nombreux packages perl-*). Ensuite tu devrais pouvoir réutiliser urpmi. Il m'est arrivé le même truc et j'ai fait comme ça (ça m'apprendra à forcer l'install de n'importe quoi ;).
Arglll j'aime pas les rpm, tiens tant qu'il y a des specialistes rpm et urpmi pourquoi lorsque l'on fait l'installe d'un paquet avec urpmi (chais plus lequel mais cela devait etre vlc) il me dit libpng.so.2 not found et que lorsque je fais un petit "ls -l /usr/lib/libpng*" j'ai bien un lien vers la libpng.so.3!!! On peut m'expliquer sur le coup la!!!!
Bah justement il cherche libpng.so.2. C'est un problème connu de la mandrake 8.2. Un petit lien symbolique l'a résolu chez moi.
PS : les questions mandrake dans les commentaires d'une news debian, c'est quand même un peu provocateur ;)
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche Bitkeeper, RMS et PLONK.. Évalué à 1.
Pour l'instant ce n'est pas le cas. Je surveillerai néanmoins tout ça de plus près maintenant ;)
2/ le DGA sous GNU/Linux, il faut avoir les droits roots. Avec un protocole bien conçu, il est possible de faire sur un multi-serveur sans avoir de droit root (juste un token "dga")
Ca peut se faire aussi sous linux, mais ça n'existe pas encore, c'est en développement :))
Fais-le, et on verra.
Voici la méthode que je propose :
le processus fait appel à une fonction write() sur une page
write() marque la page en question non writable(et on la locke en ram) (ou encore mieux, utiliser un genre de copy on write !)
...
l'appel d'écriture asynchrone se fait
on marque la page writable à nouveau (et on la delocke) (ou on la détruit si on a fait le pseudo copy on write et qu'on a fait une copie entre temps)
Si entre temps le processus a tenté une écriture sur cette page on peut
l'intercepter et l'endormir. Ou si on a fait le pseudo copy on write il peut continuer, et on ne procède à la copie que si c'est nécessaire.
T'en pense quoi ?? Ca m'a l'air pas mal, mais il doit y avoir un problème sinon tous les noyaux monolithiques feraient comme ça.
Là, j'aimerais bien savoir comment.
L'idée est d'utiliser les niveaux de privilèges non utilisés sur x86 de la manière suivante :
On rajoute un privilege level de 1 (et si on veut de 2 aussi) contenant les fonctions autorisées avec moins de droits (celles que pourront lancer un programme qui a besoin de droits mais qui ne devrait pas être root). Au lancement d'un proc on le marque en fonction de son "niveau de cpl sous-jacent" (hum, j'espère que tu vois ce que je veux dire, c'est mal expliqué). Lorsqu'on fait un appel système, il est opéré par le cpl sous jacent correspondant si le programme a le droit de le faire, sinon... Et les cpl de 1 et 2 ne touchent pas à 0, donc ce qu'on voulait faire est accompli.
Problème : toutes les architectures n'ont pas 4 niveaux de privilèges :(
Le reste du débat micro noyau/monolithique m'apparaît de plus en plus comme une question de point de vue personnel. J'attends toujours un bench complètement neutre sur la chose.
[^] # Re: Alors comme ça la Woody est difficile à installer ?
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche Alors comme ça la Woody est difficile à installer ?. Évalué à 1.
Une solution serait que tu forces la reinstallation des packages de la 8.2 (avec rpm et pas urpmi) et ensuite refaire la manip.
[^] # Re: Alors comme ça la Woody est difficile à installer ?
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche Alors comme ça la Woody est difficile à installer ?. Évalué à 1.
> urpmi.update -a
(bourin)
ou
> urpmi.update [un miroir]
(plus fin)
puis
> urpmi --auto --auto-select
C'est prêt, vous pouvez déguster
Je l'ai fait sur 3 machines sans problème.
Sinon, si tu a cassés ta base de données rpm :
rpm --rebuilddb
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche Bitkeeper, RMS et PLONK.. Évalué à 1.
J'attendais ce contre argument. Mais justement, au début de l'article, l'auteur mesure l'overhead de l4linux à 5%. Et la différence de perf linux/micro noyau est de plus de 5%. Donc...
Ça et le reste du paragraphe montre que tu n'as rien compris à la philosophie des micro-noyau. Dans un système à base de micro-noyau 'idéal', le serveur d'affichage 'mappe' la mémoire vidéo dans son espace d'addressage à lui; le client qui veut afficher des textures fait un IPC vers le serveur d'affichage en passant les données à placer via des flex-pages (pour prendre la sémantique L4). Le serveur d'affichage fait la copie et rend la main. Coût total: un RPC. Aucune copie superflue. Tu perds quoi, concrètement ?
J'ai besoin d'un appel au serveur d'affichage à chaque fois que j'affiche un truc. A comparer au dga, seule méthode qui me permet de jouer des divx sans saccades sur ma machine.
Prenons un autre exemple: une écriture sur le disque. Sur un noyau monolithique, tu appelles write(), qui copie les données dans le buffer du driver et ensuite les écrit. Sur un système à base de micro-noyau, tu passes tes flex-page contenant les données (donc, juste un IPC faisant un 'grant' sur les pages, aucune copie) au driver, qui 'pin' les pages en mémoire (pour éviter qu'elles ne soient swappées) et démarre le transfert DMA. Total: aucune copie n'a été réalisée.
Oui, mais qu'est-ce qui m'empêche d'implanter la même optimisation sur noyau monolithique ?
Tu peux comparer ça à ce qui est présenté dans http://l4ka.org/publications/files/os-protectio(...) ? On joue pas dans la même catégorie là... Avec tous tes ACLs et des patchs grsecurity, login, sshd et *ftpd tournent toujours en root sur ta machine, je te signale.
Effectivement, on a un avantage au niveau de la securité (que je n'ai pas nié). Mais je préfère la rapidité. Les mechanismes de sécurité de Linux me suffisent largement. Et pour l'instant ce genre de choses j'attends de le voir tourner.
Et il reste sur les processeurs x86 deux niveaux de privilège d'exécution non utilisés qui pourraient être utilisés pour ça.
Voila, merci de m'avoir fait me replonger dans les micro noyaux, ca fait un certain temps que j'y avais pas regardé et ça a l'air d'évoluer en bien.
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche Bitkeeper, RMS et PLONK.. Évalué à 1.
Bref, tu n'as toujours pas compris qu'un serveur indépendant est infiniment plus facile à déboguer que la même portion de code dans Linux.
Je me cite (très narcissique comme truc) :
Evidemment, un noyau monolithique est plus difficile à mettre au point (pas de droit à l'erreur, sinon on plante tout le noyau)
Sinon à propos de ça :
http://linuxfr.org/comments_reply,10074,142152,1.html(...)
moi tu m'as insulté du premier coup. Donc je trouve que tu te retiens très moyennement.
Pour tes problèmes de driver nvidia (que tu installes et utilise même si tu les trouves nuls), tu ne veux pas les résoudre, la preuve tu ne décris pas précisement tes problèmes/ton matos. Ou peut-être ces problèmes n'existent pas (et il s'agit d'un FUD aussi primaire que ceux de microsoft).
Je t'ai expliqué ce qu'était un serveur, mais tu ne veux pas apprendre. Exit donc la discussion avec toi.
Bref prends exemple sur Gaël Le mignot (plus bas) qui m'oppose des arguments valables au lieu d'insulter sans arguments.
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche Bitkeeper, RMS et PLONK.. Évalué à 1.
Donc tu sais qu'il y a un noyau réduit au minimum.
Et que par dessus il y a des quelques "processus" qui tournent et qui effectuent des tâches que fait un noyau monolitique (gestion filesystem par exemple). Ces processus se nomment des serveurs (rien à voir avec un "serveur" dans le sens machine).
Donc quand je parle d'un "un serveur de filesystem qui plante toutes les 5 min" c'est un de ces serveurs-là.
Je n'ai jamais dit qu'un micro noyau n'etait pas stable (au contraire), j'ai dit qu'il n'était pas admissible de tolérer qu'un de ces serveurs plante, même si le reste tenait.
Voila voila
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche Bitkeeper, RMS et PLONK.. Évalué à 1.
Tu m'en veux pourquoi ??
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche Bitkeeper, RMS et PLONK.. Évalué à 1.
[^] # Re: la légende urbaine de
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche Bitkeeper, RMS et PLONK.. Évalué à 1.
Plantage de X ? De toute la machine ? T'es sûr que t'as pas un chipset via ?
fuites de mémoire à 500 Mo par jour
Qu'entends-tu par là ?
Si tu vois beaucoup de mémoire "utilisée" quand tu fais top, c'est l'"agp aperture size". C'est la partie de ram physique utilisée pour stocker les textures qui rentrent pas dans la carte video. Mais c'est pas utilisé vraiment ;)
l'affichage qui se déforme quand on change de résolution
Ca, ça dépend de la fréquence de rafraichissement. Les écrans ne sont capables pour la plupart que de mémoriser un réglage vidéo par fréquence de rafraichissement (exception notable : mon vieux targa 14' mais bon il est tout pourri). Donc on n'y peut rien, à moins d'utiliser des fréquences différentes pour chaque mode vidéo utilisé. Va donc bidouiller ton XF86Config-4 !
la mauvaise qualité de l'image en 2D
Ca, ca dépend du ramdac et non pas du chipset video. Donc c'est pas la faute de nvidia mais celle de l'intégrateur. Et au fait ça n'a rien à voir avec les drivers.
[^] # Re: la légende urbaine de
Posté par Stephane Marchesin (site web personnel) . En réponse à la dépêche Bitkeeper, RMS et PLONK.. Évalué à 1.
En gros, fais quelque chose de plus constructif que 'Pauvre naze" ;)