Okay, there&#x27;s many problems with this post.<p>First, most people do not need to use dtrace. Especially on system processes. They claim that this is bad for security researchers because they can&#x27;t monitor the system anymore and they showed a screenshot of dtrace not working even with SIP &quot;disabled&quot;. However, from the screenshot, we see that SIP is, in fact not disabled because of this line<p>&gt; System Integrity Protection status: enabled.<p>You can see here <a href="http:&#x2F;&#x2F;internals.exposed&#x2F;blog&#x2F;dtrace-vs-sip.html" rel="nofollow">http:&#x2F;&#x2F;internals.exposed&#x2F;blog&#x2F;dtrace-vs-sip.html</a> that with SIP properly disabled, you can run dtrace on system processes. Yes, it&#x27;s confusing that it says &quot;DTrace restrictions: disabled&quot;, when it should say &quot;some dtrace restrictions&quot;.<p>Also, no security researcher worth their salt would be stopped by this (and no &quot;bad guy&quot; would be stopped from debugging either). In fact, dtrace is only a convenience and one tool in a toolbox; you have VMs with kernel level debuggers. You have object code analysis. You have wireshark and so on. If Apple can&#x27;t stop people from jailbreaking their iphones (where hardware enforces the lockdown), they won&#x27;t stop people from debugging their PC&#x27;s kernel.<p>Basically, SIP is good for users (the &quot;Ultimately this means that Apple has replaced the &#x27;be all and end all&#x27; security barrier of the root password, with the &#x27;be all and end all&#x27; SIP protection mechanism.&quot; argument is the same as &quot;we shouldn&#x27;t outlaw guns because people will find other ways of killing each other&quot;) since it makes compromising a system all that harder. If it hinders ANY security research, I question the skills of that researcher.