Bill Pearson from the Intel Software Network posted a declaration of a party on the occasion of the 2000th blog post on ISN.
One of the highlights he listed was the conversation which was engendered by a post I did about two years ago called "Why Linux people lust after DTrace." My intent was simply to write up the notes from a talk I had attended by Bryan Cantrill from Sun about DTrace, and some random musings based on my own shaggy dog history in the industry.
Frankly, I wasn't prepared for the resulting thunderstorm of comments on my blog, as well as the comments which popped up on other blogs which referenced my post. Suddenly I had a steady stream of comments and post views on a topic that, well to be honest, I wasn't prepared to address. Heck, it was just a random post, why was there so much response?
And better yet, how could I replicate this outpouring of passion?
Since I posted this, I have learned a lot more about DTrace. The community has extended DTrace probes into MySQL, JavaScript and Python, to name a few. Intel extended DTrace to support an OpenSolaris version of PowerTop. (And I believe there are other DTrace-based tools which are forthcoming). I also learned more about similar options in Linux, and the pros and cons vs. DTrace.
Here's a shout-out to Bill for mentioning my humble little post in his 2000th post party!
And, a little full-circle irony here: In the original post, I commented on how Oracle engineers in particular wished they had a version of DTrace for Linux. I guess with the coming acquisition of Sun by Oracle, they may be able to finally satisfy their lust for DTrace!
One of the highlights he listed was the conversation which was engendered by a post I did about two years ago called "Why Linux people lust after DTrace." My intent was simply to write up the notes from a talk I had attended by Bryan Cantrill from Sun about DTrace, and some random musings based on my own shaggy dog history in the industry.
Frankly, I wasn't prepared for the resulting thunderstorm of comments on my blog, as well as the comments which popped up on other blogs which referenced my post. Suddenly I had a steady stream of comments and post views on a topic that, well to be honest, I wasn't prepared to address. Heck, it was just a random post, why was there so much response?
And better yet, how could I replicate this outpouring of passion?
Since I posted this, I have learned a lot more about DTrace. The community has extended DTrace probes into MySQL, JavaScript and Python, to name a few. Intel extended DTrace to support an OpenSolaris version of PowerTop. (And I believe there are other DTrace-based tools which are forthcoming). I also learned more about similar options in Linux, and the pros and cons vs. DTrace.
Here's a shout-out to Bill for mentioning my humble little post in his 2000th post party!
And, a little full-circle irony here: In the original post, I commented on how Oracle engineers in particular wished they had a version of DTrace for Linux. I guess with the coming acquisition of Sun by Oracle, they may be able to finally satisfy their lust for DTrace!
Comments
What a coincidence! I'm just finishing slides for mine tomorrow presentation about DTrace for local Linux User Group. :)
Dtrace is awesome, but it's a big hurdle trying to learn how to actually use it if you're not already very knowledgeable about things like C, awk, system calls, scripting, Solaris internals, etc.
I think dtrace also very underrated for use as a security tool as it is very difficult to completely hide rootkits and other malware / spyware from the all seeing eye of dtrace. Compare this to burying "invisible" rootkits inside Linux and Microsoft Windows which is a trivial task that any 13 year old script kiddie can accomplish using pre-written turn-key applications available for free download on the internet (which I won't name here just in case any script kiddies are reading your blog).
For example, in a 2.6 Linux kernel all you have to do is to remove a malicious kernel module from the sysadmin's eyesight is to remove it from the module_list and you've disappeared off the lsmod radar. The internal structure of the OpenSolaris OS makes this kind of trickery much more difficult, as there is a linked list of modules and even if you remove the malicious module from the linked list, as soon as another module is loaded into the kernel, it's module ID in modinfo will be off by one, which is a pretty obvious indicator that something is wrong. Also, anyone who knows about process scheduling will know that you can't hide a process from the scheduler without inadvertently killing the process.