(Warning: contains me trying to play Doom :)

Our customers are top tier tech companies and our users are among the smartest engineers on the planet. I'm proud of our marketing, but no-one is going to spend a bunch of money with us just because of that.

So there must be something else in it I guess ;-)

Undo is mostly used by companies whose world is complex enough that rr doesn't work for them, and they understand how powerful time travel debugging is.

There has now been a LOT of engineering invested by a lot of very smart people into Undo, so it does also have a lot of polish and nice features.

But honestly, if rr is working for you, that's great. I'm just glad you're not doing printf debugging the whole time :)

Why do people pay for Undo when they can get rr -- which is also really good -- for free? Those whose code or environment is big enough and complex enough that rr doesn't work for them, and they understand how powerful time travel debugging is. If rr works for you, you should use it. This includes most independent developers.

If rr can work for you and you're still not using any kind of time travel debugging, you have effective tied one hand behind your own back! If you're independent (incl student or academic) and rr doesn't work for you, get in touch -- we give free licenses for academic and certain other use cases.

There is a wider thing here about software companies paying for dev tooling. So many companies over the years who made really cool things who couldn't make their business work.

e.g. it now has decent multi-process support.

I agree MI is kinda horrid, but no need for it these days, you can do everything via the Python API, and the modern equivalent is Debug Adapter Protocol which GDB claims to support now (although I haven't tried).

There a million frontends, including both Visual Studio (via ssh) and VSCode, if you like those.

The perfect developer tool does not exist, but I believe that if you're debugging native code on Linux more than a few times per year then you should really know how to drive GDB. It won't always be the best tool for the job, but it often will be.

Sure, there will always be some races/timing issues that just won't repro under recording (Heisenberg principal and all that), but in fact most races are _more likely_ to occur under recording. Part of this is because you slow down the process being recorded, which is equivalent to speeding up the outside world.

And of course, when you do have your gnarly timing issue captured in a recording, it's usually trivial to root-cause exactly what happened. Our customers tell us that races and timing issues are a major use-case.

I think the UI is much maligned unfairly. It has a few quirks, but ever used git? For the most part it's fairly consistent and well thought through.

By terrible API you mean the Python? I admit it can be a bit verbose, but gives me what I find I need.

What features do you most miss? My experience is that most people use like 1% of the features, so not sure adding more will make a big difference to most people.

For this to work all the regression tests must be fast, and 100% reliable. It's worth it though. If the mistake was made once, unless there's a regression test to catch it, it'll be made again at some point.

I think every commit that gets merged to main should be an atomic believed-to-work thing. Not only does this make bisect way more effective, but it's a much better narrative for others to read. You should write code to be as readable by others as possible, and your git history likewise.

This also works well in conjunction with debug tooling -- the tooling gives you the raw information, writing down that information helps join the dots.

As someone who has been working on a debugging tool (https://undo.io) for close to two decades now, I totally agree that it's just weird how little attention debugging as a whole gets. I'm somewhat encouraged to see this topic staying near the top of hacker news for as long as it has.

https://undo.io/

https://rr-project.org/

https://learn.microsoft.com/en-us/windows-hardware/drivers/d...

It doesn't completely defeat the Heisenberg principle of course, but you can in practice add a decent amount of logging without affecting timing in a meaningful way.

Enjoy!

Comments URL: https://news.ycombinator.com/item?id=39621464

Points: 2

# Comments: 1