Come and help us maintain and enhance a fully open-source operating system and cloud stack that has been battle-tested in very large production environments.
There are plenty of interesting problems to solve, all the way from writing device drivers and debugging early boot issues, to writing new UIs in Rust.
I think we're a pretty friendly team to work alongside too ;)
Definitely adding that to my toolkit for next time. Was only after spending a number of hours code reading and writing manual probes to try and figure out where the EINVAL was bubbling up from.
Would be great if we had a repository somewhere of D scripts to cover a huge range of analysis areas, and help folks bootstrap themselves into writing their own.
For the first time I'm considering disabling SIP on macOS (probably only the DTrace functionality), but I'm curious: what magical new features will I achieve?
Does it turn off that "some features will not be available" message?
Can I trace system binaries?
Will I gain access to a syscall provider?
Will I also have to disable other SIP features to make it more useful?
It's a pity that Mastodon lacks quote tweets, but in addition to the post I boosted yesterday, I just wanted to say my own thanks for #DTrace reaching 20.
As part of my recent #pkgin work I came across another optimisation for "pkg_admin rebuild-tree" using #DTrace that makes it a further 12x faster on my test system.
Today I used #bpftrace on a #Linux system to investigate a performance issue. Really took me back to my days working on #Solaris at Sun Microsystems. I used #dtrace quite a bit at that time, and it's good to see the same good ideas thriving in Linux.
I worked in #AIX development at #IBM for many years, and I was always a little sad that people didn't use #probevue more. Perhaps this is because AIX has a good system trace infrastructure and the culture grew up using that. Hard to say.