14 ms·

Yes, you do misunderstand. The D language is terrible, it has no loops, no functions, it is not a usable language beyond basic scripts. The _good_ part of the w

Yes, you do misunderstand. The D language is terrible, it has no loops, no functions, it is not a usable language beyond basic scripts. The _good_ part of the windows implementation is the kernel interfaces, which is what my design uses. The entire point of this research was to discard the D language. My implementation(s) allow you to use C++ 17, or Web Assembly instead. These are significantly more powerful languages. The Web Assembly scripts are a demonstration of using the same 'safe' architecture as DTrace. While the C++17 DLL system is a demonstration of an 'unsafe' but more powerful design. If you think DTrace can't crash the system, you are mistaken.

adamrezich 4y ago
to clarify for the uninitiated like myself: this "D" is not the Walter Bright "D", but a language specifically for DTrace.
- runnerup 4y ago
  Wow thank you I was so confused about the “lack of loops” thing and thought I must have utterly misunderstood the paradigm of Walter Bright’s D.
bcantrill 4y ago
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.

adamrezich 4y ago

to clarify for the uninitiated like myself: this "D" is not the Walter Bright "D", but a language specifically for DTrace.

runnerup 4y ago
Wow thank you I was so confused about the “lack of loops” thing and thought I must have utterly misunderstood the paradigm of Walter Bright’s D.

bcantrill 4y ago

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.