Krunch a écrit 4071 commentaires

Le problème c'est plutôt la confusion avec FSUGAr je trouve.

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

adduser(8)
pam_limits(8)
limits.conf(5)

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

(II) AIGLX error: dlopen of /usr/lib/dri/nouveau_dri.so failed (/usr/lib/dri/nouveau_dri.so: cannot open shared object file: No such file or directory)

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

Si on veut garder du RHEL sans inscrire sur RHN, il est aussi possible de monter son propre repo sur base du DVD par exemple : http://kbase.redhat.com/faq/docs/DOC-9744
Ou bien d'utiliser RHN Satellite / Spacewalk (mais ça peut être un peu overkill selon ce qu'on veut faire).

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

Il y a aussi DAVIX qui est une compilation d'outils d'analyse et de visualisation de données. Le manuel contient une liste détaillée avec des exemples pour chaque outil :
http://82.197.185.121/davix/release/davix-manual-1.0.1.pdf
http://davix.secviz.org

Une utilisation de Graphviz que j'apprécie beaucoup est la visualisation de graphes d'appels statiques générés avec egypt qui se base sur gcc -dr : http://www.gson.org/egypt/

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

Le consensus tend vers « immonde ».

http://www.peereboom.us/assl/html/openssl.html
http://corte.si/posts/code/reading-code.html

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

Use --key-file=-, Luk(e|s).

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

Pour les gens qui connaissent pas, il y a ça aussi : http://people.redhat.com/mbooth/virt-v2v/
C'est tout pas stable et en développement actif mais c'est fait pour ce genre de migration.

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

N'oublions pas http://www.bonjourlesenfants.fr/

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

> Et le fuzzing, ca ne depend pas de l'acces au code source.

Le fuzzing de base, non. Mais si on a les sources, on peut fuzzer encore plus efficacement (non pas qu'il y ait grand monde qui le fasse en pratique).

http://code.google.com/p/bunny-the-fuzzer/
http://research.microsoft.com/en-us/um/people/pg/public_psfi(...)

OK, strictement parlant ya sans doute pas besoin des sources pour ça, mais ça rend l'instrumentation quand même vachement plus pratique.

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

Je ne connais aucun fournisseur de logiciel qui peut se permettre de garantir le bon fonctionnement. Ce qui est garanti c'est qu'on va t'aider quand ça va casser (tant que t'as pas outrepassé les limites qui sont écrites sur la boite). À ma connaissance, les fournisseurs de matériel informatique ne garantissent pas plus que ça va fonctionner. Ils t'assurent juste de remplacer quand ça marche pas.

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

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.