Shared publicly  - 
Okay, I know that this isn't novel, or surprising or even interesting -- especially coming from me -- but holy crap is SystemTap ever garbage. After all these years, it's still this easy to panic the system:

# stap -e 'global a; probe kernel.function("*") { a[0] <<< 1 } probe begin { print("SystemTap is still garbage.\n"); }'
WARNING: could not open /tmp/stap7CGygc/stapconf_20423d9794ca0c31976730fa91ed90ad_487.h: Invalid argument
SystemTap is still garbage.
[ System panics ]

Actually, the term "panic" is generous here, as the system appears to be triple faulting. And, of course, it actually took quite some time (tens of seconds) just to compile and load that enabling, so there's that. And then there's the nonsensical error message. And all of this is after @brendangregg went through great pains just to get it to work at all (see his recent tweets for details).

I don't want to put too sharp a point on it, but SystemTap is five years old; by this time in its life, DTrace was (essentially) no different than what it is today and was being used the world over in production systems. Is the world ready to acknowledge that SystemTap is not on a trajectory to ever catch up?
Rennie Allen's profile photoBryan Cantrill's profile photo
Yup systemtap is garbage. I am giving an internal talk to our company on dtrace this Friday, can I quote you on the "systemtap is garbage" statement? :-)
Rennie, yes I think you can safely quote me. ;) For whatever it's worth, I have always maintained that SystemTap was doomed by its architecture -- in particular, that they compile to .c files (!) that are then compiled into .ko files (!!) and loaded into the kernel. It would be incorrect to say that we considered this and dismissed it for DTrace, because never for a moment would we have considered something so obviously asinine. I elaborated on our thinking in; while that post never mentions SystemTap by name, it is very much aimed at what I perceived to be the reckless design decisions that they had made. The odd bit: here we are six years later, with SystemTap exactly the toxic waste dump that I knew it would be, and yet I strangely find myself more disheartened than vindicated...
Yeah, certainly because systemtap is such nonsense, it damages the overall perception of this type of tool in general and that is disheartening. It baffles me that someone could look at dtrace's implementation and then propose something like systemtap as a response.

I looked at systemtap back around 2006, and whilst I don't really swear much, my reaction was largely along the lines of your reaction to the software defibrillator.

I would very much like to see dtrace as an integrally supported tool on linux, but I really don't like linux that much anyway so it isn't killing me that it isn't fully integrated.

Btw: I have used dtrace quite a lot, and I have only rendered my system unusuable one time, and that was by turning on destructive mode and putting a stop() in the action for a probe on execv (doh!). Nothing in dtrace has ever malfunctioned for me (the stop in exec did exactly what it was supposed to do :-) 
Rennie, glad that DTrace has been so reliable for you! And yes, the stop() action is a very sharp knife. ;) Don't know if you saw this in the "Advanced DTrace: Tips, Tricks & Gotchas" presentation, but if you do end up in that state again and you happen to have the kernel debugger present, you can break into the debugger and set dtrace_destructive_disallow to 1.
Add a comment...