lorinc

De mémoire (jai la mémoire qui flanche pas mal en ce moment), c'est comme ça que fonctionne Hurd et pas mal de micronoyaux. C'est effectivement plus lourd en IPC, mais d'un autre côté, ça évite d'avoir plein de code générique mal (ou pas du tout) optimisé. Finalement, je ne sais pas si c'est si lent que ça. Et puis il faut voir qu'une fois que le processus a un accès sur une zone, toutes ses I/O sur cette zone se font directement en userspace et possiblement sans passer par un mode noyau, ce qui serait le plus coûteux. Bref, l'idée n'est pas si folle. Pour le reste du paquet de conneries évoquées ici, vous m'excuserez, j'ai autre chose à faire de mon temps

Gibert ?

oui

Test non valide ! Si le moteur de php est bien foutu, il parse une seule fois la chaîne puis la bufferise, donc absolument aucune différence entre "" et ' '. Pour faire un vrai test, il faudrait générer une chaîne aléatoire et l'afficher, le tout dans la boucle de 100.000.

Le reste je dis pas mais ça ça va pas être possible J'ai pensé la même chose Théo, tu en demandes trop, là...

\o/ Bon annif Bilou Theo :tchintchin:

Salut, rem Et salut aux autres aussi. J'ai pas trop le temps de faire un tour dans le coin en ce moment, but I'll be back soon

C'est à dire "use Flash with ActionScript code to load (persistently) a malicious URL into a target clipboard." ? Si le process de flash est tué, le clipboard est denouveau disponible, non ? C'est un peu bidon comme "attaque", si je te fais lancer un programme qui fait du while(1) setClipBoard("urlalacon"); (genre un document OOo avec une macro débile, ou n'importe quoi du style), c'est la même. C'est plus un défaut sur le principe même du clipboard qui peut être modifié par n'imporet quel process à n'importe quel moment...

amusant, mais ça manque de détail...

Tu passes le WE (12/13/14) en région parisienne ? J'ai pas des masses de temps, mais je serais ravi de boire une mousse un de ces 4

oui, soit tu désinstalles X et tout ce qui en dépend (attention y a du monde), soit tu supprime [g|k|x]dm du démarrage à grands coups de rc-update petite question, quelqu'un a déjà réussi à faire fonctionner initng, j'arrive pas à avoir le scripte réseau qui fonctionne correctement (et la doc est pour le moins inexistante) ?

Hum. oui et non. J'aurais tendance à dire que je ne vois pas en quoi avoir une préemption plus souple augmente le nombre de section critiques. Les sections critiques le sont par essence (un variable partagée, un problème de réentrance, ...), et ceci indépendamment de quand précisément l'ordonnanceur décide de tourner. En fait, la majeure partie du temps utilisé l'est en espace utilisateur, ce qui rend totalement imprédictible le moment où ce situera le prochain ordonancement (dans le sens que l'on ne sait pas si cela arrive durant un code en mode noyau et si oui lequel). L'INpact sur les deadlocks il vient surtout du nombre de sections critiques et du SMP. Après, j'aurais tendance à dire, peu importe le schéma de préemption. mais je suis ouvert à d'autres explications

des copies à corriger ???

Moi, j'aime bien toutes ces petites particularités. La langue, c'est de l'art, et l'art, c'est quelque part l'expression de quelque chose de très personnel. Quelque chose qui ne devrait pas s'attarder sur des choses aussi futiles que l'efficace. L'efficace est l'antithèse de l'art, car c'est tout le contraire d'une décision prise arbitrairement, pour des raisons qui n'ont pas de quantificateur, ni de critère d'optimalité. Or c'est justement ce qu'est l'expression de soi, une décision arbitraire. C'est l'art, unique, personnel, et pourtant tout entier.

quand j'ai vu ça http://monochromementality.com/data/phoo/2...30/t9-input.png j'avoue, j'ai bavé d'envie... :crever: :love:

C'est là qu'on voit bien que Linus n'utilise pas debian, ce noob. Un vrai debian user aurait mis 10 minutes à corriger le problème du big kernel lock dans l'ensemble du noyau : foreach (@kernel_files) { open KERNEL_FILE, "+>$_"; foreach (<KERNEL_FILE>) { s=^=//= if (m/(un)?lock_kernel/); } close KERNEL_FILE; } c'est pas dit qu'il ait fallu deux ans avant que quelqu'un n'eût ralé pour celle-là, par contre

j'ai pas dit *BSD. Les perfs de linux sont largement au dessus de NetBSD et OpenBSD, et sont pareilles à FreeBSD. Mais dans un contexte SMP, DragonflyBSD est par desing mieux foutu que tous les autres.

oui, mais ce serait bien de pas rester à la bourre par rapport à dragonfly bsd, pour le coup.

c'est la guerre en ce moment sur la lkml pour chaque patch tentant de virer du code lié au BKL, c'est fun. Tout le monde ce prend la tête pour essayer de ne pas faire de deadlock dans le noyau, ce qui est plutôt compliqué. Y a une news sur dlfp là dessus.

punaise, quand il se fache, il se fache vraiment tout rouge le Linus...

Je dirais surtout que 75% des gens qui ont des problèmes sont ceux qui ont installé linux pour la première fois il y a moins de quelques heures. Et que ceux qui ont installer linux depuis quelques heures ont installé boubountou. Les autres distribs ne sont largement pas aussi populaires pour ce qui est d'attirer le windowsien qui veut voir un nouveau jeu (et non pas un nouvel OS).

en même temps, les impôts ne sont pas vraiment un achat...

ben oui, c'est celui-là, et édition 2004 (le splash est marqué 2004.1) s'il vous plaît. Plus n'aurait servit à rien. C'est marrant, ça fait quatre ans que j'ai gravé ce CD, et rien n'y fait, c'est toujours lui que je ressors à la fin et qui me tire d'affaire...

ben je m'étais pas fait chier : j'ai fait suivant-suivant-suivant dans l'installeur de debian, en spécifiant juste que je voulait un lvm. C'est à eux qu'ils faut en vouloir si c'est cracra...

etch, le CD à 6 3-4 mois, peut-être. Mais la carte mère est vieille, l'usb doit pas être super bien géré