3 ms·
That is one big commit: https://github.com/opendtrace/opendtrace/commit/893932783d5ae969c8f851f17161e06695e711be https://github.com/opendtrace/opendtrace/commit
by Aissen 8y ago
That is one big commit:
https://github.com/opendtrace/opendtrace/commit/893932783d5ae969c8f851f17161e06695e711be https://github.com/opendtrace/opendtrace/commit/893932783d5a...
It seems to be on a project which has virtually no contributions since last august.
In addition, I'm not sure where Microsoft is going with this: your DTrace scripts probably won't be portable anyway. The only common point is the language. Is that sufficient ?
- jen20 8y agoDepending on what and where you are tracing, scripts likely already are not compatible between different operating systems which support Dtrace - FreeBSD, Solaris and Illumos, and MacOS all have different system calls (for example). That said, there are _many_ points of commonality which will apply to Windows too - USDT probes, function boundary tracing etc.
- bibyte 8y agoI wonder why they didn't split the commit.
- yjftsjthsd-h 8y agoDo they need to be portable/compatible? If MS wrote their own version/alternative, then it'd be incompatible with everything. This way they get a load of high-quality code for free, and even if it's not directly compatible with existing uses at least the general framework is known by existing users and there's existing documentation so they don't have to do the whole thing from scratch and train all the users themselves. API compatibility would help, but there's value without it.
- santoshalper 8y agoOnly time will tell, but it can't hurt to be language compatible. All the unix engineers out there who depend on dtrace will find it more comfortable to use. On the other hand, using a foreign syntax can hurt too, had they used something that looked more like powershell for example, it might have been easier for Windows admins to get accustomed to.