Plus serieusement j'ai unzipé rapidos le truc et survolé les sources en 2 minutes. Bon déjà c'est clair, c'est du code sans nom mais passons. Autrement en parcourant rapidos le code j'ai pas vu à quel niveau se branchait l'application par ce que y'a quand même un truc qui m'intrigue. Comme tu empeches l'info de sortir ? Par ce que bon des infos qui represente ton numéro de telephone qui passent par ta carte reseau va y'en avoir un paquet... (c'est la techinque qui m'interesse la rien avoir avec le sujet).
Autrement il est très naif que de croire qu'une black list aussi basique pourrait empecher quelqu'un d'avoir les infos qu'il souhaite. Toute personne ayant pratiquer un peu le SE sait avec quelle facilité on peut obtenir ce qu'on souhaite du moment qu'on a du temps devant soi; et c'est encore plus facile avec des momes. Enfin si ca peut servir tant mieux.
Note: le pr0n c'est le coté soft du net hein, même sur caramail y'a 4 ans y'avait des pubs de cul alors que c'est peuplé de momes... Y'a beaucoup beaucoup pire.
Posté par ckyl .
En réponse au journal Logprotect.
Évalué à 1.
C'est sympa ces trucs, ca va faire toute une génération de bidouilleurs qui aura appris en cassant toutes ces protections :-)
Moi ce qui me fait rire c'est que c'est toujours le mot pédophilie qui ressort alors qu'il faut *VRAIMENT* bien le chercher pour tomber dessus. Par contre je conseil a tous de faire un bot irc qui se branche sur tout les principaux réseaux IRC et recupere les images des topics. Y'en a qui pourraient être suppris...
un exemple de tel robot, bien qu'un peu lent, est topico (je file pas l'url pour public averti on y trouve le meilleur comme le pire... c'est IRC).
Et ca tout les petits logiciels gentils qui protège le monde...
enfin bref. C'est totalement inutile le mino soit tu restes avec lui soit il tombera par hasard sur des trucs bien hardcore dans le mois au max.
D'ailleur images.google.com est pas mal dans son genre non plus. En plus même si on a pas d'imagination google en a beaucoup.
> je bosse sur un projet serieux ... il me faut des certitudes.
Quand on bosse sur un projet serieux et qu'on ne connait pas son affaire on évite de répondre ca a quelqu'un qui tente de t'aider même s'il te dit une connerie. Si t'es pas content tu te demerdes tout seul hein.
> je vois que tu as une grande experience de la chose
(Relis ce qu'il a écrit...)
Tu n'as pas l'air d'avoir une plus grande experience alors évite...
Tu vas chercher la norme, tu vas lire un paquet de code source et après tu reviens faire la lecon au reste du monde ok ?
Bref ici tu demandes aux autres de faire ton taff; les envoyer chier je trouve ca pas très top...
"Je ne désire pas utiliser les interface WebBased car je penses que si Linux veut s'intégrer dans les entreprise Windowzienne une interface web ne fait pas sérieux pour un soft de gestion."
En même temps si ton but c'est d'integrer Linux dans les entreprise la meilleure idée n'est peut être pas de reinventer pour les 2500330 ieme fois la même chose...
Enfin il faut savoir ce qu'on veut quoi :-)
Oui tu as le droit d'analyser le texte de l'auteur ! Mais publier son texte ca n'a rien a voir avec notre tambouille...
Le copier/coller sauvage n'entre strictement pas dans les conditions que tu as cité.
Autrement si un film est sorti je peux foutre le DVD sur un FTP en mettant "Et vous qu'en pensez vous ?" hop c'est une analyse donc légal ? Tu ne vois pas comme un défaut de raisonement la dedans ?!?!
De plus si la pseudo analyse c'est "bizarrement cette information n'est pas reprise" ca frise le ridicule... Je pense que tu ferais bien de reflechir a ce que dit la loi avec un peu de bon sens.
Danke pour le lien vers l'autre patch je n'etais même pas au courant !
- les -ck qui apportent SCHED_ISO et je crois pas grand chose (rien ?) pour l'ordonnanceur
Rien hormis staircase quand il sera fini. En plus ck a l'air d'etre occupé à autre chose et les patch contre le 2.6.4 commencent a rejetter de partout sur un 2.6.6 tout frais.
Enfin tu as aussi sched_domain mais on ne joue pas dans le même domaine (c'est pour la migration de tache entre les CPUs). http://lwn.net/Articles/80601/(...) pour un tour de vue rapide.
1/ dans le patchset d'-mm je ne vois pas les patchs de ck
2/ même s'ils y etaient SCHED_BATCH & SCHED_ISO ne sont clairement pas des ordonnanceurs. Juste des bidouille (ie. des patchs de 15 lignes) pour adapter le comportement bref rien de
le staircase est loin d'etre fini. Et des schedulers experimentaux, il y en a des plus connus que celui-là.
.
Staircase c'est pas un hack "a la va vite" mais un changement en profondeur de sched.c (d'ailleur il est domage que sous linux on ne puisse pas avoir proprement plusieurs ordonanceurs à la FreeBSD par exemple, mais je peux encore ne pas avoir suivit les tout dernier developements). Il remet en cause pas mal de principes apportés par le patch de molnar.
>Sinon, SCHED_BATCH ça se trouve en général dans les systèmes de calcul hautes performances ou l'ordonnancement est statique
heu ca peut quand même être très pratique sur des WS ou des serveurs.
> C'est encore pire
Hihi tu as clairement raison je me demande comment j'ai dit une connerie comme ca :-/
si tu regardes le patch pour le SCHED_ISO tu verras de quoi je parles :-)
> Sinon, à en juger par la partie qu j'ai mise en gras, ça répond à la question.
Non ca c'est le résumé de ck pour que ca soit compréhensible ce a quoi il faut que je refléchisse c'est sur ce que modifie effectivement le code (très très peu de choses) et toutes les implications que cela entraine. Et pourquoi cette modification fonctionne et répond à la question. Enfin bref
J'ai bien compris le principe du SCHED_ISO par contre je ne suis pas sur de voir toutes les implications dans le monde réel du deadline--. Faudra que j'y reflechisse un peu ! Mais il semble que ce soit la réponse élégante à la question. Faut juste que j'arrive a jauger jusqu'à quel point la réponse est pertinante par rapport à la question.
> Euh, tu es sur d'avoir suivi le développement du 2.6 ?
J'ai juste écrit un commentaire de code de l'ordo O(1) en francais y'a un peu plus d'un an... :-)
Mais je t'avoue que je n'ai plus tout les details en tête du O(1) j'ai fait quelques trucs depuis
> Essaye déjà les noyaux -mm.
Je suis pas du tout les noyaux -mm en ce moment. Hormis sched domains qui n'a rien a voir avec la tambouille tu peux me dire ce qu'il y d'interessant dans la tambouille ? Je viens de matter le patch-series du 2.6.6-mm4 et j'ai rien pu trouver avec un nom qui semble interessant.
> Ca dépend ce que tu apelles "passer devant A".
Dans le cas du 2.6 tu as en effet raison je viens de re-matter rapidos les sources.
Avec des nices a 0 et 19 et des taches bouffeuses de CPU un peu facilement prédire que les deux taches ne seront pas classées interactives. Donc ne seront jamais remise dans la queue courante. Vu qu'au minimum MIN_TIMESLICE est attribué a chaque tache lors de sa mise dans la seconde queue en effet les deux tâches s'executerons. Tiens c'est bizarre je suis paresseux aujourd'hui je te laisse faire le calcul grosso modo des timeslice allouées aux deux process :-)
Autrement en relisant le code je n'ai pas pu trouver de tracer de SCHED_BATCH qui me semble pourtant bien avoir existé. ie une classe d'ordonnancement ou les taches recoivent des timeslice de l'ordre de 10 * MAX_TIMESLICE mais ne peuvent préempter aucune autre tache et un simple round robin est fait entre les tâches. J'ai revé ou 1/ je devrais me raffraichir la mémoire 2/ ca a été viré depuis les premiers patchs ? Je me souviens même du .c donné par molnar pour passer une tache en SCHED_BATCH.
Pour ton log :
Grievre: another part of the problem is that the 2.6 scheduler punishes CPU hogs;
C'est une affirmation correcte mais pas complete. Tout les ordos generalistes que je connais (regarde decay par exemple, 2.4 en est une adaptation) punissent toujours les taches consomatrices de CPU donc a priori non interactives. Ce qui serait interessant c'est de voir exactement la différent au niveau de la punission et de la répartition de chaque ordonnancement selon les ordonanceurs.
La solution simple est toujours de passer la tache en temps réel (SCHED_FIFO/SCHED_RR) et la tu es sur qu'elle ne se fera pas massacrer par les autres autre mais toujours au risque de perdre la machine si le jeux se vautre.
Bon si j'ai du temps a perdre je ferais des stats tiens
- repasser au 2.4 (eh oui pour les jeux c'est pas plus mal)
Heu tu es au courant *tout* ordonnanceur pénalise certaines taches et en favorisent d'autre ? Ca tombe bien puisque c'est son job. L'ordo du 2.6 n'apporte rien de nouveau de ce côté grosso modo on regarde qui bouffe du CPU et on le puni pour favorisé les autres taches (je vais pas expliquer le pourquoi du comment ici).
Ce qu'apporte le 2.6 c'est surtout en reduction de la complexité des algos de gestion. Une passe des queues de priorité multiniveau en O(n) a des algos 0(1) car basé sur des evenements. Encore groso modo tu ne mets a jour que la structure de la tache qui vient de se terminer et tu la balances en queue d'une FIFO.
- essayer d'autres ordonnanceurs "experimentaux"
Le seul ordonnanceurs expérimentale qui existe et qui fonctionne a peu près a ma connaissance est staircase de ck. Pour l'avoir fait tourné pendant un mois il est pas au point (jolie famine par moment, et freeze de machine pour 1..10 secondes dans des cas pathologiques reproductible).
La solution ? Apprendre a se servir des primitives POSIX concernant l'ordonnancement ! Bin oui le bon vieux nice
nice A
nice +20 B
B ne passera *jamais* devant A par exemple.
les prioros vont de -20 à +19 à toi de jouer avec cela. Un algo d'ordonancement c'est stupide et il ne peut pas vraiment faire la différence entre un process a la con qui bouffe 100% de CPU et un jeux qui faut qu'il tourne qui bouffe 100% de CPU. On laisse donc l'utilisateur biaiser les choix de l'algo.
Autrement tu peux carrement tapper du cote des prio temps reel mais si ton jeux par en vrille tu es bon pour le reboot :-)
J'avais quelques idée bassée sur les attributs etendus des FS pour faire cela de manière plus souple et peut être qu'un jour je testerais mes idéees :-)
Ce sont ces mêmes UNIX proprio nuls qui ont inventé tout ce sur quoi tu travail maintenant... Quand tu regardes historiquement ce qui à été inventé par SYS V / 4BSD et ce que linux a apporté tu pleures... Rendons à césar blablabla
Heu c'est justement le 2 qui est interessant. Par contre il fait bien plus de 700 pages, 700 c'est a peu près son prix en francs (un peu plus).
Mais c'est un très très très bon bouqin.
Autrement mes deux livres de chevets depuis un bon moment les incontournables Conception et Implementation de 4.4BSD et le noyaux linux.
Les livres Perl sont très bien aussi. Telecoms 1 chez dunod est bien foutu et permet d'avoir ce qu'on veut rapidement sous la main.
1) on voit que t'as jamais fréquenté que des procfs sous X86
Bin dans ton journal tu ne parles que de lire stat des processsus. On ne peut pas deviner ce que tu veux en faire non plus.
Pour la taille maxi de procfs en effet c'est difficillement calculable.
3) et bien justement, ça commence à me gaver : j'ai 20 fonctions qui sont toutes au dessus de 12Ko d'usage de pile alors que l'exécution montre que 400o suffirait. je ne veux pas faire de gaspillage,
Tu viens de decouvrir la magie de linux et son tout /proc :-)
Le jour ou ils comprendront que /procfs c'est bien pour faire des scripts shell mais pas plus ils se mettront peut a fournir des fonction pour les vrais programmes... Voir les BSD par exemple...
Excuse moi si je me trompe mais procfs est spécifique à linux. La plupart des autres UNIX like n'en ont pas ou alors selon leur propre format. Donc la portabilité de la chose semble plutôt limitée ou j'ai loupé quelque chose.
Si tu n'a qu'a lire lles /proc/*/stat c'est sur que tu vas avoir a atteindre les 4096 mais en même temps j'ai relu deux fois et ou tu veux en venir n'est pas clair :-)
Pour les performances bin au pire tu gapsille un peu de mémoire.
"Only wimps use tape backup: real men just upload their important stuff on ftp,
and let the rest of the world mirror it."
C'était un trait d'humour du genre moi je sauvegarde pas y'a déjà 12 millions de gens qui sauvegarde mon archive chez eux. Si tu fais entrer l'admin en jeux ce n'est plus drôle :-)
Je connais pas le fonctionnement de l'usb/v4l dans linux mais le maintainer semble avoir une raison et avoir prevenu le gars de pwc. Donc le fait que le module vire n'est pas étonant. On ne peut pas vouloir un noyau de qualité et commencer a tolerer des leaks ou autres joyeusetés en même temps... Donc il semble plus que l'autheur de pwc (que je trouve plutôt leger pour d'autres raisons :) semble soit être de mauvaise fois soit ne pas a avoir compris le fonctionement du système puisqu'on lui a clairement répondu que ce n'était pas un patch d'une ligne qui était nécessaire.
> Alan Cox a dit que ça a été très pratique pour débugger le noyau (en quoi ? je ne sais pas).
En que ca a permis de tester des cas qui ne sont testables que sur SMP normalement.
Avec l'UP en preemptible tu peux faire jouer tout le monde aux beta testeur sur le locking et introduire plein de situations de concurence à la con qui ne se produiraient presque jamais autrement.
Autrement Alan cox l'a peu être dit mais ca serait plutôt andrew morton :-)
> L'intérêt de ketchup est qu'il permet de ne télécharger que le minimum.
Non l'interet c'est pour les gros paresseux car ca patch tout seul.
Autrement ketchup ne t'apporte rien la dessus puisque tu peux tres bien telecharger le patch à la main. Note que sur la page d'acceuil de kernel.org il te propose juste le patch x.y.z-1 => x.y.z
Bref pas tellement de quoi fouetter un chat comme appli... Ca permet de pas te prendre la tête si tu utilises un -bk ou -mm mais dès que tu as un noyau patché autrement je pense pas que ca soit utile bien au contraire. Y'a mel gorman qui avait fait un patch-o-matic sympa y'a quelques temps d'ailleur. http://www.skynet.ie/~mel/projects/patchset/(...)
[^] # Re: c00l
Posté par ckyl . En réponse au journal Logprotect. Évalué à 1.
La sortie c'est par où ? :-)
Plus serieusement j'ai unzipé rapidos le truc et survolé les sources en 2 minutes. Bon déjà c'est clair, c'est du code sans nom mais passons. Autrement en parcourant rapidos le code j'ai pas vu à quel niveau se branchait l'application par ce que y'a quand même un truc qui m'intrigue. Comme tu empeches l'info de sortir ? Par ce que bon des infos qui represente ton numéro de telephone qui passent par ta carte reseau va y'en avoir un paquet... (c'est la techinque qui m'interesse la rien avoir avec le sujet).
Autrement il est très naif que de croire qu'une black list aussi basique pourrait empecher quelqu'un d'avoir les infos qu'il souhaite. Toute personne ayant pratiquer un peu le SE sait avec quelle facilité on peut obtenir ce qu'on souhaite du moment qu'on a du temps devant soi; et c'est encore plus facile avec des momes. Enfin si ca peut servir tant mieux.
Note: le pr0n c'est le coté soft du net hein, même sur caramail y'a 4 ans y'avait des pubs de cul alors que c'est peuplé de momes... Y'a beaucoup beaucoup pire.
# c00l
Posté par ckyl . En réponse au journal Logprotect. Évalué à 1.
Moi ce qui me fait rire c'est que c'est toujours le mot pédophilie qui ressort alors qu'il faut *VRAIMENT* bien le chercher pour tomber dessus. Par contre je conseil a tous de faire un bot irc qui se branche sur tout les principaux réseaux IRC et recupere les images des topics. Y'en a qui pourraient être suppris...
un exemple de tel robot, bien qu'un peu lent, est topico (je file pas l'url pour public averti on y trouve le meilleur comme le pire... c'est IRC).
Et ca tout les petits logiciels gentils qui protège le monde...
enfin bref. C'est totalement inutile le mino soit tu restes avec lui soit il tombera par hasard sur des trucs bien hardcore dans le mois au max.
D'ailleur images.google.com est pas mal dans son genre non plus. En plus même si on a pas d'imagination google en a beaucoup.
[^] # Re: réponse d'un nom programmeur
Posté par ckyl . En réponse au journal Où geeker cet été ?. Évalué à 8.
Ca doit etre difficile a porter comme nom programmeur !
[^] # Re: stop la petite guerre
Posté par ckyl . En réponse à la dépêche La paternité de Linux discutée. Évalué à 1.
[^] # Re: la méthode géométrique
Posté par ckyl . En réponse au journal Comment savoir ou se trouve un fichier sur un CD ?. Évalué à 7.
Quand on bosse sur un projet serieux et qu'on ne connait pas son affaire on évite de répondre ca a quelqu'un qui tente de t'aider même s'il te dit une connerie. Si t'es pas content tu te demerdes tout seul hein.
> je vois que tu as une grande experience de la chose
(Relis ce qu'il a écrit...)
Tu n'as pas l'air d'avoir une plus grande experience alors évite...
Tu vas chercher la norme, tu vas lire un paquet de code source et après tu reviens faire la lecon au reste du monde ok ?
Bref ici tu demandes aux autres de faire ton taff; les envoyer chier je trouve ca pas très top...
[^] # Re: Yet another compta logiciel
Posté par ckyl . En réponse au journal Comptabilité d'entreprise. Évalué à 1.
En même temps si ton but c'est d'integrer Linux dans les entreprise la meilleure idée n'est peut être pas de reinventer pour les 2500330 ieme fois la même chose...
Enfin il faut savoir ce qu'on veut quoi :-)
[^] # Re: Hum
Posté par ckyl . En réponse au journal Train de vie: Sarkozy dans la lignée des Chirac, Tiberi.... Évalué à 2.
Le copier/coller sauvage n'entre strictement pas dans les conditions que tu as cité.
Autrement si un film est sorti je peux foutre le DVD sur un FTP en mettant "Et vous qu'en pensez vous ?" hop c'est une analyse donc légal ? Tu ne vois pas comme un défaut de raisonement la dedans ?!?!
De plus si la pseudo analyse c'est "bizarrement cette information n'est pas reprise" ca frise le ridicule... Je pense que tu ferais bien de reflechir a ce que dit la loi avec un peu de bon sens.
[^] # Re: C'est l'ordonnanceur...
Posté par ckyl . En réponse au journal Multitache bizarre. Évalué à 2.
- les -ck qui apportent SCHED_ISO et je crois pas grand chose (rien ?) pour l'ordonnanceur
Rien hormis staircase quand il sera fini. En plus ck a l'air d'etre occupé à autre chose et les patch contre le 2.6.4 commencent a rejetter de partout sur un 2.6.6 tout frais.
Enfin tu as aussi sched_domain mais on ne joue pas dans le même domaine (c'est pour la migration de tache entre les CPUs). http://lwn.net/Articles/80601/(...) pour un tour de vue rapide.
[^] # Re: C'est l'ordonnanceur...
Posté par ckyl . En réponse au journal Multitache bizarre. Évalué à 2.
> Je skip, tu y as répondu
heu non pour deux raisons
1/ dans le patchset d'-mm je ne vois pas les patchs de ck
2/ même s'ils y etaient SCHED_BATCH & SCHED_ISO ne sont clairement pas des ordonnanceurs. Juste des bidouille (ie. des patchs de 15 lignes) pour adapter le comportement bref rien de .
Staircase c'est pas un hack "a la va vite" mais un changement en profondeur de sched.c (d'ailleur il est domage que sous linux on ne puisse pas avoir proprement plusieurs ordonanceurs à la FreeBSD par exemple, mais je peux encore ne pas avoir suivit les tout dernier developements). Il remet en cause pas mal de principes apportés par le patch de molnar.
>Sinon, SCHED_BATCH ça se trouve en général dans les systèmes de calcul hautes performances ou l'ordonnancement est statique
heu ca peut quand même être très pratique sur des WS ou des serveurs.
> C'est encore pire
Hihi tu as clairement raison je me demande comment j'ai dit une connerie comme ca :-/
[^] # Re: C'est l'ordonnanceur...
Posté par ckyl . En réponse au journal Multitache bizarre. Évalué à 2.
si tu regardes le patch pour le SCHED_ISO tu verras de quoi je parles :-)
> Sinon, à en juger par la partie qu j'ai mise en gras, ça répond à la question.
Non ca c'est le résumé de ck pour que ca soit compréhensible ce a quoi il faut que je refléchisse c'est sur ce que modifie effectivement le code (très très peu de choses) et toutes les implications que cela entraine. Et pourquoi cette modification fonctionne et répond à la question. Enfin bref
[^] # Re: C'est l'ordonnanceur...
Posté par ckyl . En réponse au journal Multitache bizarre. Évalué à 2.
J'ai bien compris le principe du SCHED_ISO par contre je ne suis pas sur de voir toutes les implications dans le monde réel du deadline--. Faudra que j'y reflechisse un peu ! Mais il semble que ce soit la réponse élégante à la question. Faut juste que j'arrive a jauger jusqu'à quel point la réponse est pertinante par rapport à la question.
[^] # Re: C'est l'ordonnanceur...
Posté par ckyl . En réponse au journal Multitache bizarre. Évalué à 3.
J'ai juste écrit un commentaire de code de l'ordo O(1) en francais y'a un peu plus d'un an... :-)
Mais je t'avoue que je n'ai plus tout les details en tête du O(1) j'ai fait quelques trucs depuis
> Essaye déjà les noyaux -mm.
Je suis pas du tout les noyaux -mm en ce moment. Hormis sched domains qui n'a rien a voir avec la tambouille tu peux me dire ce qu'il y d'interessant dans la tambouille ? Je viens de matter le patch-series du 2.6.6-mm4 et j'ai rien pu trouver avec un nom qui semble interessant.
> Ca dépend ce que tu apelles "passer devant A".
Dans le cas du 2.6 tu as en effet raison je viens de re-matter rapidos les sources.
Avec des nices a 0 et 19 et des taches bouffeuses de CPU un peu facilement prédire que les deux taches ne seront pas classées interactives. Donc ne seront jamais remise dans la queue courante. Vu qu'au minimum MIN_TIMESLICE est attribué a chaque tache lors de sa mise dans la seconde queue en effet les deux tâches s'executerons. Tiens c'est bizarre je suis paresseux aujourd'hui je te laisse faire le calcul grosso modo des timeslice allouées aux deux process :-)
Autrement en relisant le code je n'ai pas pu trouver de tracer de SCHED_BATCH qui me semble pourtant bien avoir existé. ie une classe d'ordonnancement ou les taches recoivent des timeslice de l'ordre de 10 * MAX_TIMESLICE mais ne peuvent préempter aucune autre tache et un simple round robin est fait entre les tâches. J'ai revé ou 1/ je devrais me raffraichir la mémoire 2/ ca a été viré depuis les premiers patchs ? Je me souviens même du .c donné par molnar pour passer une tache en SCHED_BATCH.
Pour ton log :
Grievre: another part of the problem is that the 2.6 scheduler punishes CPU hogs;
C'est une affirmation correcte mais pas complete. Tout les ordos generalistes que je connais (regarde decay par exemple, 2.4 en est une adaptation) punissent toujours les taches consomatrices de CPU donc a priori non interactives. Ce qui serait interessant c'est de voir exactement la différent au niveau de la punission et de la répartition de chaque ordonnancement selon les ordonanceurs.
La solution simple est toujours de passer la tache en temps réel (SCHED_FIFO/SCHED_RR) et la tu es sur qu'elle ne se fera pas massacrer par les autres autre mais toujours au risque de perdre la machine si le jeux se vautre.
Bon si j'ai du temps a perdre je ferais des stats tiens
[^] # Re: C'est l'ordonnanceur...
Posté par ckyl . En réponse au journal Multitache bizarre. Évalué à 5.
Heu tu es au courant *tout* ordonnanceur pénalise certaines taches et en favorisent d'autre ? Ca tombe bien puisque c'est son job. L'ordo du 2.6 n'apporte rien de nouveau de ce côté grosso modo on regarde qui bouffe du CPU et on le puni pour favorisé les autres taches (je vais pas expliquer le pourquoi du comment ici).
Ce qu'apporte le 2.6 c'est surtout en reduction de la complexité des algos de gestion. Une passe des queues de priorité multiniveau en O(n) a des algos 0(1) car basé sur des evenements. Encore groso modo tu ne mets a jour que la structure de la tache qui vient de se terminer et tu la balances en queue d'une FIFO.
- essayer d'autres ordonnanceurs "experimentaux"
Le seul ordonnanceurs expérimentale qui existe et qui fonctionne a peu près a ma connaissance est staircase de ck. Pour l'avoir fait tourné pendant un mois il est pas au point (jolie famine par moment, et freeze de machine pour 1..10 secondes dans des cas pathologiques reproductible).
La solution ? Apprendre a se servir des primitives POSIX concernant l'ordonnancement ! Bin oui le bon vieux nice
nice A
nice +20 B
B ne passera *jamais* devant A par exemple.
les prioros vont de -20 à +19 à toi de jouer avec cela. Un algo d'ordonancement c'est stupide et il ne peut pas vraiment faire la différence entre un process a la con qui bouffe 100% de CPU et un jeux qui faut qu'il tourne qui bouffe 100% de CPU. On laisse donc l'utilisateur biaiser les choix de l'algo.
Autrement tu peux carrement tapper du cote des prio temps reel mais si ton jeux par en vrille tu es bon pour le reboot :-)
J'avais quelques idée bassée sur les attributs etendus des FS pour faire cela de manière plus souple et peut être qu'un jour je testerais mes idéees :-)
[^] # Re: Euh...
Posté par ckyl . En réponse au journal Test du téléviseur Thomson 21mx170s. Évalué à 2.
En gros ce n'est pas une interogation sur l'object physique mais sur l'apport du service "la tele".
Enfin juste mes 0.20
[^] # Re: The Unix haters handbook
Posté par ckyl . En réponse au journal Vos livres d'informatique préférés.... Évalué à 0.
Ce sont ces mêmes UNIX proprio nuls qui ont inventé tout ce sur quoi tu travail maintenant... Quand tu regardes historiquement ce qui à été inventé par SYS V / 4BSD et ce que linux a apporté tu pleures... Rendons à césar blablabla
[^] # Re: Ma réference réseau TCP/IP
Posté par ckyl . En réponse au journal Vos livres d'informatique préférés.... Évalué à 2.
Mais c'est un très très très bon bouqin.
Autrement mes deux livres de chevets depuis un bon moment les incontournables Conception et Implementation de 4.4BSD et le noyaux linux.
Les livres Perl sont très bien aussi. Telecoms 1 chez dunod est bien foutu et permet d'avoir ce qu'on veut rapidement sous la main.
[^] # Re: Portabilité ?
Posté par ckyl . En réponse au journal procfs, limitation du système de fichiers, PATH_MAX. Évalué à 2.
Bin dans ton journal tu ne parles que de lire stat des processsus. On ne peut pas deviner ce que tu veux en faire non plus.
Pour la taille maxi de procfs en effet c'est difficillement calculable.
3) et bien justement, ça commence à me gaver : j'ai 20 fonctions qui sont toutes au dessus de 12Ko d'usage de pile alors que l'exécution montre que 400o suffirait. je ne veux pas faire de gaspillage,
Tu viens de decouvrir la magie de linux et son tout /proc :-)
Le jour ou ils comprendront que /procfs c'est bien pour faire des scripts shell mais pas plus ils se mettront peut a fournir des fonction pour les vrais programmes... Voir les BSD par exemple...
# Portabilité ?
Posté par ckyl . En réponse au journal procfs, limitation du système de fichiers, PATH_MAX. Évalué à 1.
Excuse moi si je me trompe mais procfs est spécifique à linux. La plupart des autres UNIX like n'en ont pas ou alors selon leur propre format. Donc la portabilité de la chose semble plutôt limitée ou j'ai loupé quelque chose.
Si tu n'a qu'a lire lles /proc/*/stat c'est sur que tu vas avoir a atteindre les 4096 mais en même temps j'ai relu deux fois et ou tu veux en venir n'est pas clair :-)
Pour les performances bin au pire tu gapsille un peu de mémoire.
[^] # Re: Linus ne disait pas
Posté par ckyl . En réponse au journal Sauvegarde distribuée en P2P ?. Évalué à 1.
"Only wimps use tape backup: real men just upload their important stuff on ftp,
and let the rest of the world mirror it."
C'était un trait d'humour du genre moi je sauvegarde pas y'a déjà 12 millions de gens qui sauvegarde mon archive chez eux. Si tu fais entrer l'admin en jeux ce n'est plus drôle :-)
# Bien plus interessant
Posté par ckyl . En réponse au journal Bayes appliqué au code ?. Évalué à 1.
http://www.stanford.edu/~engler/(...)
http://coverity.com/main.html(...)
J'ai au moins vu passer des messages d'eux sur lkml et freebsd-hackers...
Par contre je ne sais pas si une partie du projet est libre...
# Thread
Posté par ckyl . En réponse au journal Bizarrerie avec PWC. Évalué à 2.
http://marc.theaimsgroup.com/?l=linux-usb-devel&m=1074017781203(...)
Je connais pas le fonctionnement de l'usb/v4l dans linux mais le maintainer semble avoir une raison et avoir prevenu le gars de pwc. Donc le fait que le module vire n'est pas étonant. On ne peut pas vouloir un noyau de qualité et commencer a tolerer des leaks ou autres joyeusetés en même temps... Donc il semble plus que l'autheur de pwc (que je trouve plutôt leger pour d'autres raisons :) semble soit être de mauvaise fois soit ne pas a avoir compris le fonctionement du système puisqu'on lui a clairement répondu que ce n'était pas un patch d'une ligne qui était nécessaire.
Ce thread date de mi janvier...
[^] # Re: pb au reboot
Posté par ckyl . En réponse à la dépêche Linux 2.6.6 est sorti. Évalué à 1.
Aucun BSD libre ne sait changer de noyau a chaud.
[^] # Re: Vos expériences avec le 2.6?
Posté par ckyl . En réponse à la dépêche Linux 2.6.6 est sorti. Évalué à 2.
En que ca a permis de tester des cas qui ne sont testables que sur SMP normalement.
Avec l'UP en preemptible tu peux faire jouer tout le monde aux beta testeur sur le locking et introduire plein de situations de concurence à la con qui ne se produiraient presque jamais autrement.
Autrement Alan cox l'a peu être dit mais ca serait plutôt andrew morton :-)
http://kerneltrap.org/node/view/2702?PHPSESSID=1d34a48c585608d20a63(...)
[^] # Re: Ketchup
Posté par ckyl . En réponse à la dépêche Linux 2.6.6 est sorti. Évalué à 3.
Non l'interet c'est pour les gros paresseux car ca patch tout seul.
Autrement ketchup ne t'apporte rien la dessus puisque tu peux tres bien telecharger le patch à la main. Note que sur la page d'acceuil de kernel.org il te propose juste le patch x.y.z-1 => x.y.z
Bref pas tellement de quoi fouetter un chat comme appli... Ca permet de pas te prendre la tête si tu utilises un -bk ou -mm mais dès que tu as un noyau patché autrement je pense pas que ca soit utile bien au contraire. Y'a mel gorman qui avait fait un patch-o-matic sympa y'a quelques temps d'ailleur. http://www.skynet.ie/~mel/projects/patchset/(...)
[^] # Re: pb au reboot
Posté par ckyl . En réponse à la dépêche Linux 2.6.6 est sorti. Évalué à -1.