Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)
1–10 of 34 posts
Re: Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)
#2hacker news is shadow banning ? how low can hn go ?
Re: Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)
#3But the pty bug still hasn't been found?
Re: Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)
#4> Naturally I wanted to get my hands on this stuff to try it out for myself. Is it really as good as they say? Normally I stick to Linux, but it (generally) doesn’t have these Sun technologies.
Since then, bpftrace[0] has been released, supposedly it's actually better than dtrace, in the sense that it's even more capable[1].
See https://www.joyfulbikeshedding.com/blog/2019-01-31-full-syst... for a recent basic ebpf/bpftrace tutorial. Brendan Gregg also has a primer on eBPF: http://www.brendangregg.com/blog/2019-01-01/learn-ebpf-traci...
[0] http://www.brendangregg.com/blog/2018-10-08/dtrace-for-linux...
[1] that's Brendan Gregg saying it: http://www.brendangregg.com/blog/2018-10-08/dtrace-for-linux... — having contributed to it and being one of the leading dtrace experts
Re: Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)
#5> Linux has a reputation for Not Invented Here (NIH) syndrome, and these licensing issues certainly contribute to that
I don't think the author understands with NIH means in practise, and this completely misplaces the blame. It's not as though the kernel team was completely unwilling to consider porting ZFS or DTrace, it's that for legal reasons they were unable.
Re: Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)
#6But the pty bug still hasn't been found?
That’s certainly how I read it.
Re: Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)
#7I'm a big fan of dtrace and I use it daily. However, the system call tracing that the author did here could easily have been done without dtrace. Eg, via strace on the curl process (or truss, ktrace, or whatever your OSe's system call tracer is).
Re: Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)
#8> Linux has a reputation for Not Invented Here (NIH) syndrome, and these licensing issues certainly contribute to that I don't think the author understands with NIH means in practise, and this completely misplaces the blame. It's not as though the kernel team was completely unwilling to consider porting ZFS or DTrace, it's that for legal reasons they were unable.
No (unfortunately) it's NIH and nothing more.
Re: Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)
#9> Naturally I wanted to get my hands on this stuff to try it out for myself. Is it really as good as they say? Normally I stick to Linux, but it (generally) doesn’t have these Sun technologies. Since then, bpftrace[0] has been released, supposedly it's actually better than dtrace, in the sense that it's even more capable[1]. See https://www.joyfulbikeshedding.com/blog/2019-01-31-full-syst... for a recent basic ebpf/b…
> * in the sense that it's even more capable*
Examples? I don't see how it's more capable. Catching up with dtrace, maybe.
Re: Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)
#10> Naturally I wanted to get my hands on this stuff to try it out for myself. Is it really as good as they say? Normally I stick to Linux, but it (generally) doesn’t have these Sun technologies. Since then, bpftrace[0] has been released, supposedly it's actually better than dtrace, in the sense that it's even more capable[1]. See https://www.joyfulbikeshedding.com/blog/2019-01-31-full-syst... for a recent basic ebpf/b…
The extra capabilities Linux added made it insecure (arrays), so that eBPF needs to be disabled in production SMP systems.
There's also no existing userland support. Everyone provides DTrace probes, no one systemtap probes.