mark_undoio

I think one thing that helped git early on was that its concept of branches were just really convenient.

For me I'd say it's that git doesn't fit my mental model and Mercurial does - it's that mercurial gave me a smaller mental model that (at least back when I used it heavily) allowed me to do what I needed.

Even as a fairly experienced and advanced Git user, Git requires me to keep more state in the head and at, from my point of view, unpredictable times needs me to extend the model. The strange thing is that this is despite having a very simple model at the lowest levels of the system.

Sad to see another Mercurial holdout switch to Git.

The latter is ahead in network effects in a massive way - but I always preferred Mercurial. I'd have used it more but - network effects! - used git because of the projects I was working on.

The main thing was that the mental model of Mercurial fit in my head and the CLI was predictable and regular, whilst the tool still scaled to large codebases.

I find Git wants me to think about its implementation details and internal terminology at unpredictable moments during use. It still gets the job done but it feels like doing random CAPTCHAs in the midst of my work.

True! What seems a little unusual about Space 1999 was their lack of control over where they went. In Voyager they have some agency, in BSG they're searching for something, etc.

Stargate Universe seems a bit closer in the sense that (for large parts) they can't control their spaceship and just have to go explore and get back on board quickly.

I like to think that it's essentially Star Trek Voyager's situation but they've just got the entire moon instead of a spaceship.

In the Java world, we've developed record/replay across microservice boundaries, so it's effectively possible to step from a failure in one microservice and into the service that sent it bad data.

https://docs.undo.io/java/Microservices.html

[Edit: for which, by the way, any feedback is welcome - it's technically quite promising but real world experience is worth a lot!]

A weird (at first sight) thing about signal handlers - the kernel doesn't really know, or care, if you're running in one.

Which makes sense because signal handlers can nest, so ideally the kernel wouldn't have to maintain some state for each enter/exit of signal handlers to be tracked.

Instead, the kernel sets up the necessary conditions for things to act like a signal handler expects and puts some state on your the stack representing your registers, active signal mask, etc, plus some state to ensure a sigreturn syscall will run.

If you return from your handler, that'll take effect and your state is restored to where you were before. If you go into a nested signal handler, the kernel pushes another pile of state on the stack to return to where you are now.

You're free to change that saved state before returning - or just siglongjmp out of there and discard it, if you know what you're doing.

Libc is a lot more tricky about signals, since not all libc functions can be safely called from handlers. From the kernel's point of view, there's nothing magic about them at all but usually we're stuck with libc restrictions into the bargain.

I think the key thing with OSM is that the data is open.

It would be nice if this app had more open code and it's nice if people contribute back to the data set too.

But the database is the open source artifact here, not the software - as long as they're respecting that then it feels ok, even if more would be desirable.

Near where I live we've got a guided busway (a track system that modified buses can travel down, tram-style).

On the railway bridge before it's entrance there's a height barrier in advance consisting of a whole load of bells that dangle down from a metal bar and will hit over-height vehicles without making a really solid collision.

They still haven't figured out a way to stop cars driving up the bus tracks, though (where they inevitably get stuck).

That certainly makes sense - and that tight loop is very compelling.

What if you have to solve a bug outside of the development loop though? E.g. a bug somewhere in the whole system after you've done your development, where you don't have a root cause yet?

Not exactly but for shared libraries in general it's possible to ship some accompanying Python that will get installed and automatically loaded by GDB.

You can even embed that Python script within the shared object using some scary ELF tricks - I was surprised, to say the least, to discover this is supported.

You're quite right, it's very possible.

The product I work on does pretty much exactly this - we need it because our debugger time travels and we can't allow history to be altered!

I wrote some words here: https://medium.com/time-travel-debugging/calling-functions-i...

But it's basically exactly what you propose. We didn't sandbox the syscalls but you could do that too.

Have you tried using a debugger at all? I see people who've resisted for years become mega fans when they finally try one.

I also see people who use them all the time but reluctantly - I'd love to know what the difference is.

If you use GDB, I recommend checking out the official documentation: https://sourceware.org/gdb/current/onlinedocs/gdb.html/

It's quite hard work sometimes - there's a lot in there - but the capabilities available are amazing and it's well worth nosing around.

I also recommend just hitting TAB a lot and seeing what commands are suggested. Then use the "help"command to find out more.

My employer also hosts some articles that digest some knowledge we've gained into a more palatable form: https://undo.io/resources/gdb-watchpoint/

I'm not sure they'd do so automatically but, given the ability to call functions (which it sounds like, for Rust, GDB lacks) it should be possible to plumb together.

But debuggers like GDB have built in infrastructure for expressing how to display structured, potentially nested data structures - it's built for the purpose and powerful, so it's nice to bring it to bear if you've not already got something equivalent in they program.

The other important thing is that the debugger's pretty printers work on a core file, without needing a live process.

I've been experimenting with Go recently, with Rust still on my to-do list. I really like the simplicity of Go, with a fairly small language of constructs that combine powerfully.

Having learned SML / Haskell in the past I've got a bit of a soft spot for languages that are utterly cruel to you with their compilation errors but lead you straight to bug-free code. What I've heard about Rust puts it in this camp.

One thing that does concern me about Rust: when I (now and then) look at what's changing in C++ it feels like a lot of new mechanisms and abstractions are required to address problems created by previous design decisions. I sometimes read about Rust and worry that I might need to embark on a similar journey.

I'm a debugger specialist, not a Rust specialist - but I'm surprised the experience of viewing data structures is not better for you.

What platform / debugger are you on? I'd expect the GDB pretty-printers (which from the article it looks like Rust has been shipping by default for the standard library) to be taking care of this relatively well - e.g. looking at https://github.com/rust-lang/rust/pull/72357 it appears that `HashMap` and `HashSet` have printers.

(Raw C++ data structures without some form of pretty printing are also incomprehensible for normal development - and I'd be surprised if third party libraries were particularly good at shipping pretty printers, though I may be wrong!)

It takes some strong organisational discipline to really maintain that throw away mindset - I suppose that's where it helps to make an explicit goal to throw the initial version away.

Another aspect is that (in my experience / opinion) if you're doing an MVP then it really needs to be as minimal as possible - big enough to give you evidence for your future plans but not comparable to what you eventually hope to build. Otherwise it's hard to adapt or to throw away.

The biggest thing I've found to help in any design work is making sure the engineers really understand the problem they're solving, so they can judge independently if plans they're making are complimentary to it.

> Say 1. Open database connection 2. Commit data 3. Close database connection > > How would you rewind right before #2 if you've already completed step #3? You'd need the socket/connection you already closed

The key thing is that you're really rewinding the world, as visible by the program

The program doesn't actually know what the network transaction with the database was, it just knows what syscalls it made and what results they returned. If, whenever it gets to talking with the database, you provide the same result as last time then it can't tell the database is gone.

This is self-supporting: if you do this consistently with external sources of information then the program will never go down any new code paths, guaranteeing that you'll always have a ready answer recorded when it needs it.

Hallo, I'm an Undo developer wave

Indeed, using GDB's version of tracepoints (dprintf - https://doc.ecoscentric.com/gnutools/doc/gdb/Dynamic-Printf....) is really powerful and replaying a trace with these installed is to generate "logs I wish I'd had" is exciting.

It also has potential use if:

* you'd like to diff two executions (e.g. one successful, one failing) - you probably can't just compare raw execution as there'll be uninteresting variation but comparing extended logs could be useful

* you are debugging something at a customer site - they might not let you debug directly but you could iterate on plain text logs by shipping them additional tracepoints to run on a recording

We thought this was useful enough that we implemented a tool with its own DSL for simply specifying post factor logging "probes": https://docs.undo.io/PostFailureLogging.html

I helped implement fast conditional breakpoints in UDB (time travel debugger for Linux) - https://www.youtube.com/watch?v=gcHcGeeJHSA

We used GDB's conditional breakpoint bytecode https://sourceware.org/gdb/onlinedocs/gdb/General-Bytecode-D... to get a speedup in the thousands of times vs plain conditional breakpoints.

That works for us because we've got in-process agent code that can evaluate the breakpoint condition without trapping. It should be possible to do this in other debuggers with a bit of work, though we have the advantage of in-process virtualisation to help hide this computation from the process.

Have you tried using a Time Travel Debugger to record the process and then just debug the recording outside?

You can use rr or LiveRecorder (commercial product, which I work on) to generate the recording non-interactively then debug it "locally". Avoids the need to set up a client/server configuration, so long as you don't need to modify variable values at runtime, etc.

For time travel debugging in Go:

The Delve debugger for Go supports debugging rr traces: https://github.com/go-delve/delve/blob/master/Documentation/...

Undo (who I work for) maintain a fork that debugs our LiveRecorder recordings: https://docs.undo.io/GoDelve.html

Either rr (https://rr-project.org/) or our UDB debugger (https://undo.io/solutions/products/udb/) can do some time travel debugging of Go programs via GDB's built-in support for Go. I believe its weakness is in support for goroutines, since they don't map well onto its idea of how programs run.

> Disclaimer (which I feel appropriate given the old school playground wars about which was the best platform): I had a CPC464 which I loved and still run emulated, but also often went round to mate's houses for Speccy gaming too.

Ahhhh. I had a friend with weird a BBC setup and an EEPROM programmer. I had a friend with a Commodore 64 (which, graphically, was on another level from anything else I'd seen with a keyboard).

And, yes, I had a friend with an Amstrad CPC (and one with their weird hybrid PC / Megadrive).

Only a few years later my school was burgled and the BBC Micros were stolen. They got Acorns as replacements but, if anything, we were probably allowed less time on them than the Beebs shrug

GDB has the "skip" command to help with this but it has limitations.

It stops you stepping into namespaces you don't want to see but doesn't do anything when you step out into them.

It also doesn't handle when code you don't want to see calls back into code you do - and, yes, I've recommended formatting lambdas to allow breakpoints before.

I believe DWARF does support columnar information these days so it actually should be possible to solve the one line lambda given code in GDB.

For looking at any data in C++ it's also very important to have GDB's pretty printers set up (and, likely, write some of your own).

https://sourceware.org/gdb/onlinedocs/gdb/Pretty_002dPrinter...

https://undo.io/resources/gdb-watchpoint/here-quick-way-pret... (this one is from my boss)

I'm not sure I understand why devices weren't coming with plugs back then but I remember it - and in the 90s was taught to wire a plug in school.

At some stage devices had to start coming with plugs attached, I think with legal force.

The UK did still have quite a few installations of the old round pin plugs in use, so maybe those had to go out of circulation first.

Glad to hear this take. I had a Spectrum and my friend had an Amstrad.

Whilst they had some stuff in common due to Amstrad buying Sinclair research, the graphics capabilities on the Amstrad seemed more advanced.

Yes, I didn't exactly think it was bad!

It's a bit forceful but it tells you clearly exactly what you need to do to have a good experience. Given the setup was presumably a bit fiddly this seems much better than having customers get frustrated before resorting to the manual.

They're still making COBOL compilers, as far as I know - targeting Linux and with some modern style Dev tools too.

I guess it's a migration path for people getting rid of big iron but unable or uninterested in getting rid of the code they ran.

Oh and, also: Raspberry Pi https://www.raspberrypi.org/

Definitely deserves a mention as it at least has quite big mind share.

And Frontier: https://www.frontier.co.uk/ Who develop various games including, possibly most famously in these circles, Elite Dangerous.

I don't think there are many big UK computer companies that haven't been absorbed by something else.

There was Microfocus: https://www.microfocus.com/en-us/home They owned SuSE at one time. But MicroFocus now have owners outside the UK.

And there was Autonomy: https://en.wikipedia.org/wiki/HP_Autonomy Bought by HP, leading to lots of controversy and legal wrangling when they did get what they had expected.