Oracle annonce une version bêta d'un port de DTrace sous Unbreakable Linux, la distribution d'Oracle dérivée de Red Hat.
Les questions habituelles subsistent:
- quel est l'intérêt par rapport à l'existant (Systemtap ?)
- la licence sera-t-elle compatible avec notre bon vieux Linux des familles ?
- les modules seront-ils intégrés au noyau ?
La suite au prochain épisode!
# preview
Posté par bubar🦥 (site web personnel) . Évalué à 3. Dernière modification le 23 février 2012 à 10:08.
C'est peut être dû à la preview, mais en tout les cas la licence spécifiée dans/pour le spec est : License: Redistributable, no modification permitted Tandisque dans les sources de ce port de dtrace on trouve toujours MODULE_LICENSE("CDDL");
En l'état actuel de la licence, ça m'étonnerait :p Mais ce n'est peut être qu'un premier pas ?
[^] # Re: preview
Posté par vida18 . Évalué à 2.
Peut-être qu'Oracle va utiliser une double licence CDDl/GPL ou changer la licence comme la nouvelle MPL 2.0 compatible avec la GPLv2 et v3.
# Petite question
Posté par barmic . Évalué à 3.
Je trouve sacrément intéressant c'est technologies de traces qui remontent en espace utilisateur (moi qui me limite à strace le plus souvent). D'après ce que j'ai compris DTrace est capable de présenter une stack complète pour Java et systemtap de même pour python.
Je présume qu'il faut que la machine virtuelle soit adaptée en conséquence, non ?
Si c'est le cas, je présume que pour Oracle il était plus simple/préférable d'ajouter un module à linux plutôt que de toucher à la JVM.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Petite question
Posté par Krunch (site web personnel) . Évalué à 2.
Pour pouvoir instrumenter correctement des applications Java ou Python en utilisant SystemTap ou DTrace il faut le support à la fois dans le noyau et dans le runtime du langage. Les tracepoints du runtime (JVM, machine virtuelle Python,...) peuvent être utilisés aussi bien par DTrace que SystemTap mais il peut être nécessaire de recompiler le dit runtime avec des options différentes.
Ça a été fait par Sun il y a belle lurette. Il faut juste compiler la JVM avec les options qui vont bien.
Il faut faire les deux et intégrer le module me semble plus compliqué que recompiler la JVM (tant techniquement qu'organisationellement).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Petite question
Posté par Antoine . Évalué à 2.
Tout à fait, d'ailleurs un bug est ouvert à ce sujet :
http://bugs.python.org/issue13405
# DTrace vs SystemTap
Posté par Krunch (site web personnel) . Évalué à 5.
L'incontournable tableau comparatif : http://sourceware.org/systemtap/wiki/SystemtapDtraceComparison
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: DTrace vs SystemTap
Posté par claudex . Évalué à 2.
Étant donné qu'il est dans le wiki de Systemtap, ce comparatif est-il vraiment neutre? Par exemple, ne manque-t'il pas des lignes défavorables à Systemtap? (je ne sais pas, je me pose simplement la question)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: DTrace vs SystemTap
Posté par Krunch (site web personnel) . Évalué à 3.
Je n'ai jamais utilisé DTrace donc je ne suis sans doute pas très neutre non plus mais il paraitrait que des développeurs DTrace, LTTng et perf contribuent également à cette page du wiki (ce qui semble se vérifier quand on examine l'historique). Après si quelqu'un a un comparatif plus complet ou correct, je suis intéressé (et le wiki peut être mis à jour).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.