Krunch a écrit 3860 commentaires

J'aime bien aussi le « Although the Infrastructure Team had attempted to configure the sshd daemon to disable password-based logins, having UsePAM yes set meant that password-based logins were still possible. »

Toujours tester les modifications.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Je serais curieux de voir le contrat qui permettrait d'imposer un prix par machine pour du Logiciel Libre sans s'appuyer sur le modèle de souscription. Par ailleurs mon message précédent faisait l'hypothèse qu'il y a exactement un utilisateur par système (donc 10 systèmes vs 10 000 systèmes).

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

> Mais je vois mal RH racheter Novell en l'état, puisque 3 des 4 secteurs
> de cette dernière font du proprio (en fait, 1/2 secteur sur 2 depuis fin 2009).

Red Hat a déjà acheté des boîtes qui faisaient du proprio par le passé (SPICE de Qumranet par exemple) mais a ma connaissance, tout a toujours été libéré par la suite.

http://en.wikipedia.org/wiki/List_of_mergers_and_acquisition(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Si on te dit Tarif annuel par système, ça veut dire que c'est un tarif par système. L'entreprise à 10 000 utilisateurs va donc payer plus que celle à 10 utilisateurs. Si tu te demandes comment c'est possible de faire ça avec du Logiciel Libre, c'est que tu n'as pas compris le merveilleux modèle de souscriptions http://www.redhat.com/rhel/renew/faqs/#6

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

J'ai pas dit que ça rendait la chose impossible mais c'est sûrement un facteur au moins aussi important que de protéger sa propre « propriété intellectuelle ».

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Tu peux voir sur quoi ça attend avec sleepingBeauties.stp et/ou blktrace par exemple.

http://sourceware.org/systemtap/examples/keyword-index.html#(...)
http://git.kernel.dk/?p=blktrace.git;a=blob;f=README

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Même si nvidia avait les meilleures intentions du monde et voulaient contribuer significativement à un driver libre. ils sont certainement liés par des contrats de non divulgation, de licences et de brevets vis-à-vis d'autres sociétés. Les avocats sont pas seulement payés pour protéger la « propriété intellectuelle » de la boite, ils sont aussi là pour pas que la boite se fasse trainer en justice par d'autres boites.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

http://www.redhat.com/search?q=Metadata+file+does+not+match+(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Alors en pratique, si tu laisses faire le compilo, il va sans doute faire ça mieux que toi.
http://www.linux-kongress.org/2009/slides/compiler_survey_fe(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

gcc peut lire le programme à compiler sur son entrée standard.

$ echo "unsigned int endian = 'B' << 24 | 'I' << 16 | 'G' << 8 | 'E';" | gcc -x c -c -o end.o -

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Parser du HTML avec des expressions régulières s'apparente à de l'infanticide.
http://stackoverflow.com/questions/1732348/regex-match-open-(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

$ perl -F'"' -ape'$_=$F[5].(substr$F[1],0,1).$F[3]."\n"'

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Tu peux peut-être jeter un oeil à Minix. C'est du micro noyau (6000 lignes) en C : http://www.minix3.org/

Sinon pour Linux faut pas avoir peur mais faut pas essayer de tout comprendre d'un coup. Si tu veux faire des tests en remplaçant des sous-systèmes entiers, c'est effectivement pas fort adapté mais du coup Minix devrait pas mal convenir.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

> Systemtap veut être intégré dans Linux (j'entends par là utrace et uprobe) car
> maintenir des patchs kernel out-of-tree ça demande beaucoup de temps de
> maintenance, de gestion des versions, etc...

Effectivement, utrace et uprobe sont des candidats à l'intégration et ils sont loin d'être acceptés. Ce qui semble probable, c'est qu'à terme il y aura de quoi tracer l'userland dans la branche principale. Si un autre système que uprobe/utrace est intégré pour cela (possiblement une amélioration de ptrace), SystemTap sera sans aucun doute modifié pour utiliser ce mécanisme.

> Aussi, il y a du code userland dans Linux, comme le repertoire tools/ qui heberge les
> outils clients pour perf events. Ca permet d'avoir un developpement très synchronisé
> avec les évolutions de Linux. Là encore Systemtap aurait probablement interêt à avoir
> un repertoire tools/stap.

Je pense pas que ça soit un des buts du projet SystemTap pour le moment mais je peux me tromper (et dans ce cas, je suis intéressé par les threads correspondants). Si tu lis le thread que j'ai donné plus haut [0], il est dit que les changements requis dans SystemTap pour s'adapter au noyau sont de l'ordre de quelques uns par an. Je suis conscient que maintenir du code noyau hors de la branche principale est normalement un gros travail mais dans le cas de l'userland SystemTap, ça ne s'applique pas vraiment (mais pour uprobe/utrace bien).

[0] http://article.gmane.org/gmane.linux.kernel/942001

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

> Oui, mais SystemTap n'est pas intégré dans la branche principale.
> Et il semble être encore loin de l'être!

SystemTap n'a aucune raison d'être intégré à Linux. C'est que de l'userland. Par contre SystemTap utilise kprobe, utrace et uprobe. S'il n'y a que kprobe, il ne sait que tracer le kernel, ce qui est déjà pas mal.

Voir https://linuxfr.org/comments/1108519.html#1108519 et http://thread.gmane.org/gmane.linux.kernel.utrace/3258/

> Systemtap ne va pas jusqu'à pouvoir verrouiller des spinlocks aléatoires ou
> autres trucs du style.

stap -g permet d'injecter du code C arbitraire. Donc tu fais *vraiment* ce que tu veux (y compris n'importe quoi).

> Et puis heureusement d'ailleurs, ça dépasserait vraiment le cadre des tracepoints dynamiques.

On est d'accord que le cas que tu cites est plus adapté à un tracepoint statique. Mais si ce tracepoint n'existe pas et que tu ne peux pas te permettre de recompiler le noyau, stap -g permettrait de le faire aussi. Évidemment c'est pas forcément une bonne idée mais c'est faisable.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

>> stap -g peut déréférencer des pointeurs et faire ce que tu veux en
>> C dynamiquement sans que le développeur initial ait eu à placer un tracepoint statique.
> System tap en fait peut être une exploitation plus poussée oui.
> Mais dans la branche principale, c'est pas encore le cas.

Pour autant que je sache, stap -g fonctionne avec la branche principale sans soucis tant que tu ne veux instrumenter que du code noyau.

> Pour retrouver le nom de l'inode, on a besoin de le vérrouiller, d'appeler une fonction
> pour chercher le dentry correspondant, de faire des copies, de déverrouiller et enfin
> de décrémenter son compteur de référence.
>
> Impossible avec un tracepoint dynamique.

C'est tout à fait possible mais ça devient effectivement assez compliqué et si un tracepoint statique existe pour cela, c'est bien évidemment préférable.

> Il n'ont pas le même usage ni le même rôle, tout simplement.

On est d'accord.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

> Les dynamiques n'ont pas encore cette puissance. On peut leur demander d'afficher
> quelques variables, pourvu qu'il s'agisse de simples entiers ou adresses.
> Mais déréférencer des pointeurs, on y est pas encore.

stap -g peut déréférencer des pointeurs et faire ce que tu veux en C dynamiquement sans que le développeur initial ait eu à placer un tracepoint statique.

http://sourceware.org/systemtap/langref/Components_SystemTap(...)

Cela est possible dès à présent avec le noyau de la branche principale (mais uniquement pour instrumenter le noyau lui même, pour observer l'userland il faut utrace/uprobe).

> Donc les statiques sont plus puissants et précis dans les données qu'ils peuvent
> remonter, tandis que les dynamiques sont plus puissants dans le fait qu'ils peuvent
> être placés un peu n'importe où.

Non, les statiques sont moins puissants parce qu'ils sont limités à ce que le développeur initial a prévu. Les dynamiques sont plus puissants parce qu'ils permettent d'observer tout et n'importe quoi mais ils sont potentiellement plus compliqués à utiliser puisqu'il faut se familiariser avec le code à tracer.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

nt

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

> SystemTap ne risque pas de ce faire concurrencer par le système
> perf qui gère de plus en plus de chose (hw-breakpoint, kprobe, syscall trace, ...) ?

Je sais pas trop pour les hw-breakpoint mais pour kprobe voir plus bas et pour autant que je sache, le traçage de syscalls se base pour le moment sur ptrace qui est plus limité que utrace.

Dans la dépêche on peut lire :
> SystemTap n'est pas dans la branche principale car je crois qu'il y a eu des
> désaccords fondamentaux sur son architecture entre les développeurs de la
> branche principale et ceux de systemtap.

Pour autant que je sache, SystemTap lui même est en userland, n'a donc aucune raison de faire partie de la branche principale du noyau et ses développeurs n'ont jamais tenté de l'intégrer. Par contre il s'appuie sur kprobe, utrace et uprobe. Comme indiqué, kprobe est dans la branche principale et SystemTap est donc parfaitement utilisable avec la branche principale pour tracer le noyau lui même.

Au final, si utrace et uprobe ne sont pas intégré mais qu'une alternative permettant de tracer le code userland est ajoutée au noyau, SystemTap sera sans doute modifié pour utiliser cela à la place.

Voir http://thread.gmane.org/gmane.linux.kernel.utrace/3258/

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

> Par contre je n'ai pas compris l'utilité du tracing : c'est juste à des fins de
> monitoring ou c'est plus poussé (ce dont je suppose, mais je ne vois pas en quoi).

Ça peut être utilisé pour du monitoring mais je vois plutôt ça comme un outil de debugging et d'aide au réglage de performances.

> De plus il y a point de traçage statique et dynamique, quel sont les
> avantages/inconvénients de chacun ?

Les points de traçage statiques sont définis par le développeur du code. Il va instrumenter explicitement ce qu'il pense pouvoir être intéressant. Les points de traçages dynamiques sont définis par l'utilisateur du code. Cela permet donc d'oberver des choses auxquelles on n'a pas pensé a priori mais ça nécessite une meilleure compréhension du système à observer.

D'un point de vu non développeur, en gros, pour utiliser les points de traçage dynamiques, tu fais des echo 1 > /proc/sys/whatever/debug alors que pour le dynamiques, il faut dire explicitement ce que tu veux observer au niveau du code.

> Sinon autre chose, à propos des "régressions" : est-ce que c'est une
> manière élégante de dire "bugs" ?

Une régression est un bug qui n'existait pas dans la version précédente (en admettant que la fonctionnalité concernée était déjà dans la version précédente). Quand l'utilisateur rencontre une régression, la nouvelle version marche moins bien que l'ancienne pour lui.

> Cela veut dire que même s'il reste des bugs, le kernel est déclaré comme
> stable, car Linus ne veut pas avoir plus de 8 RC pour une nouvelle version
> d'un kernel, et qu'en extrapolant les version 2.6.33.X ne sont que des versions
> 2.6.33 RC(8+X) ?

Je sais pas si c'est limité strictement à 8 rc pour Linux mais sortir une version sans bug connu n'est pas vraiment un but viable si tu veux espérer pouvoir ajouter des fonctionnalités.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

> On s’en accomode bien sur notre bureau (pilotes nvidia),

s/On/Tu/ merci. Il y a des gens qui font attention au matériel qu'ils achètent.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

while (<>) {
print and last if /$motclef/;
}

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

> (je déconseille testing suite à des déboires récents ;
> unstable est _plus_ utilisable que testing pour moi).

Le truc c'est qu'il y a moins de bugs qui passent dans testing mais qu'il prennent plus longtemps à être corrigés. Quand quelque chose est cassé dans testing, tu attends plusieurs jours/semaines avant que ça soit réparé. Dans unstable, ça sera sans doute corrigé dans les prochaines heures/jours mais ça va aussi te casser quelque chose d'autre.

En tout cas c'était comme ça du temps où je tournais sous testing. Avec apt-listbugs c'est assez utilisable je trouve.

Sinon en pratique j'utilise stable. Parce que c'est stable. Si je veux installer du bleeding edge, je me monte une sandbox dans laquelle je peux tout casser (qu'est-ce que j'en ai à foutre de Python 4.2 franchement ?).

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Et sinon pour les gens qui débarquent dans la matière, je suggère la lecture de la présentation « Unusual bugs » de Ilja van Sprundel.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Pour référence, on trouve des exploits basés sur les NULL pointer dereference datant de 1994 et ça m'étonnerait pas qu'il y ait plus ancien.
http://packetstorm.linuxsecurity.com/poisonpen/8lgm/ptchown.(...)

Voir aussi http://lists.immunitysec.com/pipermail/dailydave/2009-Octobe(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.