It's double edged: the co's that can afford to proactively seek better dev tools can also afford internal vanity projects to do them internally. So it becomes a political timing game for the project leads to move on etc. Not fun.
I found an easier path for dev tooling is focus on tools for non-traditional/non-fulltime coders, e.g., analysts, devops, secops, ... , for whom being able to code introduces a superpower, not an increment on status quo within a crowded space. It's a shame devs destroy our own potential.
That is a concern, but Pernosco is challenging to implement. We built on rr, which was already state of the art, and we've added a lot of secret sauce. Of course the smart big tech companies could duplicate it, but it is not simply a matter of putting a team together and grinding out the code.
About a dozen years ago my workplace built something like that in-house. I see you've made progress. You have the reverse dataflow. You can't debug an arbitrary firmware or bootloader or OS however, and you can't properly debug a bunch of interacting systems.
Simics also seems to have most of that. I last checked about half a dozen years ago, so the other features might now also be supported. It's not cheap, but you could model all the computers of a factory or aircraft all at once. You could then step forwards and backwards as desired, coherently examining the RAM and other hardware of all the computers as you please.
I wouldn't be surprised if dozens of similar tools have been built.
Out of those things, the one we do want is the ability to debug a collection of interacting distributed processes. Our goal would be a bit different though: splice together recordings from different nodes of a real system, rather than simulating all the nodes from the ground up. So our implementation approach will have to be different.
Fair, but that's not rr's target market. AFAIK Simics is not competitive with rr or Pernosco in recording overhead or scalability when you're debugging a Linux user-space application that executes, say, a trillion instructions.
I found an easier path for dev tooling is focus on tools for non-traditional/non-fulltime coders, e.g., analysts, devops, secops, ... , for whom being able to code introduces a superpower, not an increment on status quo within a crowded space. It's a shame devs destroy our own potential.