5 ms·

I appreciate that you feel you are solving a problem, but you are in fact solving a different problem than DTrace was designed to solve -- and what you perceive

I appreciate that you feel you are solving a problem, but you are in fact solving a different problem than DTrace was designed to solve -- and what you perceive to be "terrible" aspects of D are in fact deliberate design decisions to abide by DTrace's safety constraint.[0] [0] http://dtrace.org/blogs/bmc/2005/07/19/dtrace-safety/ http://dtrace.org/blogs/bmc/2005/07/19/dtrace-safety/

stevemk14ebr 4y ago
I am aware of the differences. My goal was not to recreate dtrace 1 to 1, it was to extend it with trade-offs. I've heard the argument made many times, my system is not meant to be deployed on end point user systems. A recreation obeying the same constraints of dtrace could be constructed, it would simply involve swapping the scripting system for another. If your argument is that loops are unsafe, please go look at ebpf, which has loops. If you think user defined functions are unsafe, go look at ebpf again - it's nearly C. If your argument is shipping code from user to kernel is unsafe, go look at ebpf byte code, I could easily implement signing to validate only trusted plugins can load. Your argument is close minded. These are trade-offs, and can be easily changed to obey different constraints. My system open sources previously undocumented kernel interfaces. If you dislike the constraints I chose, fork it and go rebuild dtrace exactly, it's not that I'm not solving a real problem - I'm just solving one you fail to understand.
- bcantrill 4y ago
  I think your response speaks for itself -- and agreed that you (and other systems) have made very different decisions with respect to safety.
  - stevemk14ebr 4y ago
    We agree! I'm not calling dtrace bad for the record, it's awesome. My issue is just with the language users are forced to write in not being expressive enough (specifically on windows at that). If fixed length loops and user defined functions were added, it would be quite a lot easier to implement advanced scripts.
stevemk14ebr 4y ago
Example from the doc. Probes not being allowed to call other system routines to avoid reentrancy. Dtrace avoids this architecturally, as your link says. I disliked this, so I chose the alternative, which so happens to be mentioned in the same document. My system detects reentrancy and avoided calling probes when it's determined the caller was itself a probe. I simply chose different constraints. It 'not being secure' is a facade. It's not meant to be, I could make it so though, if I wanted to. I bothered with the entire rust + wasm implementation specifically to show that this argument of not being secure' because I didn't use the D language was untrue. Browsers themselves execute untrusted code via wasm. If the concern is the halting problem, then just use wasm with bounded loops.

stevemk14ebr 4y ago

I am aware of the differences. My goal was not to recreate dtrace 1 to 1, it was to extend it with trade-offs. I've heard the argument made many times, my system is not meant to be deployed on end point user systems. A recreation obeying the same constraints of dtrace could be constructed, it would simply involve swapping the scripting system for another. If your argument is that loops are unsafe, please go look at ebpf, which has loops. If you think user defined functions are unsafe, go look at ebpf again - it's nearly C. If your argument is shipping code from user to kernel is unsafe, go look at ebpf byte code, I could easily implement signing to validate only trusted plugins can load. Your argument is close minded. These are trade-offs, and can be easily changed to obey different constraints. My system open sources previously undocumented kernel interfaces. If you dislike the constraints I chose, fork it and go rebuild dtrace exactly, it's not that I'm not solving a real problem - I'm just solving one you fail to understand.

bcantrill 4y ago
I think your response speaks for itself -- and agreed that you (and other systems) have made very different decisions with respect to safety.
- stevemk14ebr 4y ago
  We agree! I'm not calling dtrace bad for the record, it's awesome. My issue is just with the language users are forced to write in not being expressive enough (specifically on windows at that). If fixed length loops and user defined functions were added, it would be quite a lot easier to implement advanced scripts.

stevemk14ebr 4y ago

Example from the doc. Probes not being allowed to call other system routines to avoid reentrancy. Dtrace avoids this architecturally, as your link says. I disliked this, so I chose the alternative, which so happens to be mentioned in the same document. My system detects reentrancy and avoided calling probes when it's determined the caller was itself a probe. I simply chose different constraints. It 'not being secure' is a facade. It's not meant to be, I could make it so though, if I wanted to. I bothered with the entire rust + wasm implementation specifically to show that this argument of not being secure' because I didn't use the D language was untrue. Browsers themselves execute untrusted code via wasm. If the concern is the halting problem, then just use wasm with bounded loops.