Guillaume POIRIER a écrit 243 commentaires

Y'a un document intéressant de Felix von Leitner sur les points permettant à un serveur de résister à un slashdotage (en français: linuxfrisage?):
http://bulk.fefe.de/scalable-networking.pdf(...)
C'est le même lien que celui donné sur /. mais comme il n'est pas présent sur la dépèche, je me permet de le suggérer

Chose intéressante: il s'agit un bench totalement en IPv6 à ce que j'ai vu.
Ce qui est rigolo, c'est que bien que les *BSD partagent de gros pants de code, OpenBSD a posé des prbl à l'auteur du bench car la core team d'openBSD refuse de suivre les white wapers sur l'IPv6 pour des questions de sécurité.
L'avenir nous dira s'ils ont eu raison.

Tout cela est bien intéressant... mais pour quelqu'un qui est habitué à Linux, existe-t-il un projet qui implémenterait ce genre de features?
Je connais les parchs (GRSecurity ou OpenWall si ma mémoire est bonne) qui rendent la pile non exécutable, par contre, je ne connais pas de projet réduisant de façon aussi poussée la présence de daemons suid.

> As tu installés le paquet xbase-client?
Mon problème est résolu (cf plus haut)

Merci, c'était toutafé ça... pourtant, XkbVariant était activé d'office par debconf... pour une distrib qui est testée autant avant sa mise en disponibilité, ça fait moyen-moyen ;o) !

Ça me fait que moyennement rigoler vos remarques. Certes, la ligne de commande, c'est vraiment de la balle.... mais pensez un peux à ceux qui n'y comprennent rien!!!
Ainsi, ce script tout pourri permet simplement de redimentionner une ou plusieurs images depuis konqueror!!! Moi je trouve ça quand même très cool d'installer ce script chez un newbie pour qu'il lui soit simple de redimetionner une / des images sans avoir à se prendre la tête!!!

De plus, je sais bien qu'il y a pas besoin de perl pour faire ça, mais vous m'accorderez que le meilleur outil, c'est surtout celui que l'on maîtrise bien...

J'ai pas testé, mais je pense que tout ce que fait le système d'upgrade, c'est qu'il met à jour les paquets rpm que tu as installé avec des plus récents, donc théoriquement y'a pas de raison que ça marche pas si tu transite depuis la rc1 vers finale (ne pas oublier qu'avant la finale y'aura la rc2!).
Par contre, ce qui est sûr, c'est que le passage de la rc2/rc1 vers finale sera bien moins testé et sera légèrement moins fiable.
D'habitude, je profite qu'une nouvelle distrib sorte pour tout réinstaller sur ma bécane: ça me permet de me faire la main quand je vais l'installer chez des gens chez qui c'est la première fois qu'ils installent linux... Accessoirement, ça permet d'avoir un système plus propre (tous les paquets dans la même version), mais bon....

En fait, j'ai commencé Linux il y a maintenant 7-8 ans avec une slack encore plus vieille.
J'ai déjà "essayé" debian avec une woody, mais j'ai été rapidement rebuté par le fait qu'il fallait toujours être à coté de la machine pour configurer les packets. J'ai pas dit que c'était mal, mais comme je voulais juste essayer la debian, j'ai laissé tomber, et je suis resté sous redhat ou mdk (en plus c'est français).
Maintenant, j'ai un besoin différent en installant un linux sur un vieil ordi, et en ne voulant pas avoir de problème pour la maintenir à jour.
Donc, en résumé, tant que ça tourne sur mon p166+ et 32mo de ram, je suis ouvert à tout!!
Guillaume

Il est proposé de base sur MDK depuis la 8.2 au moins, et ça ne me pose pas de problème... depuis que je ne m'amuse plus à recompiler mon noyau à chaque fois qu'un nouveau noyau 2.4 sortait.
J'avait essayé devfs sur une redhat 7.2 et 7.3, mais franchement, j'ai pas vu ce que j'y gagnait...
Voilà!

Le site du projet du support de l'ACPI sous linux:
http://acpi.sourceforge.net/(...)
Tout y est bien expliqué, en anglais! ;-)

Ça doit quand même être utile pour le rendering et les filtres du style désentrelacement, zoom...
C'est sans doute pas le genre de choses qui bouffent énormément de CPU, mais si ça marche encore mieux avec les intructions multimedia, pourquoi s'en priver?

En tous cas, il semble que l'accent ne soit pas mis sur Mencoder, le "convertisseur de vidéos".
Pourtant, Mencoder aurait bien besoin aussi de profiter d'un grand coup de balais quand on voit le temps qui a été nécessaire pour incorposer les extensions avancées de Xvid.
Même si je préfère utiliser ffmpeg, nombreux sont les utilisateur de windows connaissant Xvid et désirant migrer vers une solution Linux sans trop perdre leurs habitudes.
À ce propos, y'a un script génial qui existe pour faire du rip de DVD, tuxrip: http://tuxrip.free.fr/(...)

En plus, le Camel Book est co-écrit par Larry Wall, le créateur de Perl...
ça veut pas dire forcément que c'est le bouquin le plus pédagogique, mais au moins, le style tres "pro-perl" fait qu'on a vite envie d'en apprendre plus pour faire partie de la communaute... chacun sa motivation...

Chez moi mon CMD-Z7, ça marche très bien, mais ça donne pas formément envie de passer du temps dessus... le wap, c'est lennnnttt!!

T'avais vraiment envie de paraphraser ma news? Quand j'ai écris: enfin la 0.90, considérée comme stable pour un usage de tous les jours je ne pense pas avoir commis d'erreur de traduction.
Dans un tout autre registre je lance un grand appel pour touver le moyen de virer le bug concernant la lecture des fichiers DV car avec la même librairie, je n'ai pas de problème pour encorer avec Transcode, alors que Mplayer s'arrête après 9min55sec de lecture, et croit avoir tout lu le film.
Si quelqu'un a eu le même problème, ça serait cool de faire un patch. Ce problème est d'autant plus difficile à résoudre que Mplayer de plante pas (pas de core dump et d'analyse post-mortem de possible, donc!)

Les dossiers de Login sont souvent plus tape à l'oeil que vraiment informatif. Qu'en est-il de celui "Créez votre propre langage"?

En effet, je parle bien de Xvid + mencoder... J'utilise mplayer [presque] tous les jours, aussi il m'es bcp plus naturel d'utiliser mencoder.
Mais comme j'ai comme un problème pour encoder une certain film qui comporte énormément de scènes en lumière basse (Panic Room) pour ne pas le nommer, je voulais voir ce que ça donnerais avec un autre codec.
Donc, vu que le support avec mencoder est assez pauvre (il me FAUT activer le dark_mask), je suis pas content avec xvid...
Mais bon, vu que globalement je suis content avec lavc... je vais pas en chier une pendule!

Nota: j'utilise turip depuis presque le début, mais la dernière version 0.71 ne fonctionne pas chez moi... mais je m'en fous puisque j'utilise un tuxrip 0.6x modifié à ma sauce...

J'utilise lavc depuis un moment déjà, et j'ai voulu essayer xvid... je suis un pas mal déçu: il ne semble pas permettre d'aussi bon résultats que lavc couplé avec mencoder: pas de lumi mask, pas de gestion des crédits... bien sûr, c'est une limitation de mencoder, (car j'ai déjà vu ces options accessibles sous windows), mais c'est quand même dommage qu'il n'y ai pas une communauté plus active autour de xvid+mencoder. Quequ'un pour me contredire?

... et quid de MacOSX... ? C'est assez dommage qu'il n'y ait pas de version précompilée pour ce système, car ses utilisateurs méritent mieux que Internet Explorer (même si Mozilla existe...)

> Regardez Mozilla, grâce au développement libre il est
> devenu beaucoup plus stable que Netscape à l'époque.
Je suis d'accord, mais je trouve toutefois dommage qu'il faille qu'un logiciel soit débarrassé des impératifs des "strass et paillettes" pour redevenir vraiment utilisable.
Ce n'est donc pas pour rien que RMS martèle depuis si longtemps qu'il n'y a de logiciel viable que des logiciels libres.

C'est un peu facile de faire gonfler artificiellement le nombre de failles / bogues sous Linux et les systèmes libre: vu que l'on n'a pas peur de tenir au courant les utilisateurs / admins des éventuels problèmes, le moindre problème mineur viens grossir les rangs des "failles" dont parle l'article.
De son côté, le monde propiétaire cache le plus possibles ses problèmes autant au niveau failles que bugs, donc forcément, au final, c'est pas dur de faire croire que les logiciels proprios sont plus stables.

l semble clair que le nouveau noyau 2.6 (à propos duquel j'arrête pas de poster des dépêches) vise les gros systèmes. En effet, la plupart des hackers du noyau sont embauchés dans des boîtes qui font leur beurre là-dedans, comme Connectiva pour Andrea, ou RedHat pour Alan Cox. Sur ce point, je suis tout à fait d'accord.
Cela dit, je ne peux pas empêcher de penser que si le noyau tourne super bien sur un gros système chargé, logiquement, il devrait aussi très bien tourner sur ton P133 "hors d'âge". Après tout, qu'est-ce qui les différencie dans les configurations où tous deux sont à pédaler dans la choucroute?
Bon, maintenant, il est évident que les nouveaux algos déployés, ainsi que les nouvelles structures de données du noyau doivent tout de même avoir un "coût forfaitaire" plus important. Un exemple pourrait être de classer certaines structures de données du noyau dans un arbre là où il n'y avait qu'une liste chaînée (que les experts me pardonnent si je dis une grosse connerie, je n'ai encore pas en de cours algorithmique).
Tout ça pour dire, que tu devrais tout de même essayer le nouveau noyau quand il sera plus stable, car tu risquerais bien d'être agréablement surpris (c'est pas pour les euros que ça coûte!!!).

C'est l'occasion de citer ce comparatif: first NPT vs. NGPT vs. LinuxThreads benchmark results : https://listman.redhat.com/pipermail/phil-list/2002-September/000009.html

Flûte, moi qui est essayé de ne mettre que des termes français dans la dépèche pour le pas me faire taper sur les doigts encore une fois... Est-ce que à l'avenir je devrais mettre les deux termes (français et anglais à la fois?) En tous cas, Aurélien, je te conseille de lire "Le Noyau Linux" qux éditions O'Reilly, tu apprendras plein de choses sur le fonctionnement d'un système multitâche en ayant en plus la possibilité de voir les algorithmes associés. Comme c'est une bouquin très cher, cherche d'abbord s'il existe pas à ta B.U. !

Non, c'est bien les 100 000 qui tournent en meme temps, d'apres Ingo. C'est pas parce que c'est Linus qui pose la question qu'il faut pas lire la réponse ! Bah, tu sais, je suis comme toi, et je lis les documents cités en lien avant de poster une dépèche, et j'ai bien vu que dans paragraphe 19 écrit pas Ingo, il indique:

On an old IA-32 dual 450MHz PII Xeon system 100,000 threads can be created and destroyed in 2.3 secs (with up to 50 threads running at any one time).

En ce qui concerne le post de Linus, qui justement pointe du doigt que tous les threads ne sont pas actifs en même temps, Ingo déclare:

On Fri, 20 Sep 2002, Linus Torvalds wrote: > Basically, the benchmark was how _fast_ thread creation is, not now many > you can run at the same time. 100k threads at once is crazy, but you can > do it now on 64-bit architectures if you really want to. we did both, and on the dual-P4 testbox i have started and stopped 100,000 *parallel* threads in less than 2 seconds. Ie. starting up 100,000 threads without any throttling, waiting for all of them to start up, then killing them all. It needs roughly 1 GB of RAM to do this test on the default x86 kernel, it need roughly 500 MB of RAM to do this test with the IRQ-stacks patch applied.

Je suis donc complètement d'accord avec toi, sauf que dans ma dépèche, je parle du test sur le PII Xeon, pas du P4. De toutes façons, comme le dit si bien Ingo:

Obviously with 100,000 threads running at once there's some shortage in CPU power :-) [ I will perhaps try that once, at SCHED_BATCH priority, just for kicks. Not that it makes much sense - they will get a 3 seconds worth of timeslice every 3 days. ]

Ce qui veut grosso-modo dire que c'est débile avec les processeurs que l'on a maintenant d'espérer avoir autant de tâches en parallèles et obtenir un service utilisable, vu que chaque thread ne serait ordonnancé que tous les 36 du mois.... ;-) Le test était donc plus de voir quel était le <b>coût<b/> de l'ordonnancement et de la création/destruction de processus, plus que de pouvoir crâner dans la cours de récré demain matin devant les potes Windowsiens en prétendant que "mon Linux à moi il peut ripper 100 000 OGGs en même temps, nananère". J'adore ma Linuxette, mais perso je pense que c'est pas une raison de se ridiculiser en disant n'importe quoi quand même!