mark_undoio

I love that this is here!

Let's Compute was a brilliant magazine and I loved it. I still feel sad when I remember getting the letter refunding my subscription because it was discontinued.

Unlike other home microcomputer magazines at the time (e.g. Your Sinclair, which I also liked) it was squarely focused on learning to program and it was very wholesome. All kid-friendly but plenty of humour and opportunities to write nice games.

The phrase

> Sometimes the type-ins would specific only to certain platforms, other times they would provide you with the lines to change in order to make it work for your platform.

takes me back, though! The different microcomputers with similar-but-different dialects of BASIC (plus, obviously, you couldn't look up what another micro's BASIC was because you wouldn't have the manual.

It felt like a shame MD Data [1] didn't catch on - but with existing MO formats out there maybe there was no point.

I was also reminded today of Floptical [2] drives, which I vaguely remember hearing about (but didn't catch on either).

Finally, there is my personal niche favourite, DataPlay [3], which were just so small and cute.

[1] https://en.wikipedia.org/wiki/MD_Data [2] https://en.wikipedia.org/wiki/Floptical [3] https://en.wikipedia.org/wiki/DataPlay

I was excited about the LS-120 but I never quite convinced myself to stump up the money to pay for it.

My recollection was that it was: - Slightly larger than the contemporary Zip disks. - Cheaper than a Zip drive. - Could just replace your existing floppy drive, since it was backwards-compatible.

I don't know if it was as fast or robust as a Zip disk - it definitely didn't have the same mind share, though.

In the early days of my Linux use I was on Mandrake 7.2 and loved it. All the "just in case" random packages were very entertaining and educational to me, although they were probably a distraction from whatever I was meant to be doing!

Still, the experience seems to have served me well in the end. I do miss that feeling of discovering all the weird themes and window managers they packaged by default, I don't get the same vibes of "any UI is possible" these days (even though the UX is probably much better by conventional criteria).

On GCC , as far as I know, pointers will always cast to long and back ok. I'd expect the same from clang.

No, that's not a portable behaviour but I can see that it's valid if you're targeting Linux.

uintptr_t is more polite, though.

I once worked on an Optical Image Stabilisation system for mobile phones. I'd updated the stock Android camera app to show some icons from marketing for when the shake compensation was on / off.

The icon for when compensation was on was a shaky camera. When it was off, it was a shaky camera with a line through it...

Except, we asked, wouldn't the other way round make more sense? Doesn't line through shaky camera suggest we're removing the shake?

We ended up using the icons and just colouring them green for "on" and red for "off" and hoping people would figure out what we meant. And, yes, that would still be unhelpful for colour blind users!

User interfaces are hard.

I'm a big fan of Turn the Ship Around! By L. David Marquet as fun read that shows what some good leadership can do by pushing responsibility to the lowest appropriate level in an organisation.

https://davidmarquet.com/turn-the-ship-around-book/

The anecdotes are good fun. I've not used it specifically as a model but I like the general principles it represents.

Yes - plus the original win of UML was also being able to run virtual instances on a kernel without proper virtualization capabilities.

In the early 2000s people used to use UMLs as a hosting platform - they didn't have the same security isolation as a proper VM (or even, necessarily, of a container) though.

I guess it insulates you against bugs in the VM implementation, plus against (transient) failures of the host system.

Our time travel debugger at undo.io also uses a similar approach.

But the world is different for time travel debug, in that you can replay the whole history of the recorded execution (my understanding is that this is not required for Durable Execution) but you cannot resume the real process.

In fact, since it's used for capturing faults, you wouldn't generally want to resume execution - it's going to fail the same way (whereas a higher level restart framework might allow you to throw away some bad state and continue the computation - at the cost of not being able to precisely duplicate the bug).

My guess is that this is useful when interacting with memory-mapped IO devices - individual accesses can have meaning at the device level, so you don't want the caches getting in the way (and e.g. removing / combining accesses or providing stale data).

> Remember: great is just good, but repeatable.

Great advice. I wish it was listened to more in tech - there's a lot of effort spent trying to jump up to the next big level in commercial performance, at the cost of not just improving things continuously and benefiting from compounding returns.

This is cool - time travel debugging is potentially really helpful in these flaky situations. Having tests fail unpredictably basically means you're not controlling the thing they test, which can be scary.

But I find the most annoying failures in CI are the ones I can't reproduce any other way and somehow always happen when I'm not trying.

Run locally? Fine. Run on a cloud machine that's identical to the CI system. Fine. Run multiple instances of the test on the cloud machine to generate more load. Fine. Run in the overnight tests - blam.

This doesn't always make sense, even once I've found the bug - sometimes the timing just shakes out that way.

Sometimes we record stubborn tests that are acting weird, so we're ready when they next fail.

I had a very tiring Christmas day (mostly tiring for my dad, though) putting together boot floppies for various games.

Eventually I got really good at it - selecting what drivers were required and packing them efficiently into base and extended (I think that was it...) memory.

Sometimes IIRC I'd swap boot disks around and discover extra features in games that only appeared with even more base memory.

@chris-tsang My debugging anecdotes usually involve analysing subtle failures in C code.

Those are typically days or weeks of staring and trying out different things, followed (eventually) by enlightenment. It's usually been kernel-level code (or equivalent) for me, so there are minimal conveniences / safety features available.

C makes it easy to get crazy stories because of all the ways threading or memory access can go horribly wrong. These are notorious for creating "impossible bugs". Is there an equivalent "argggh, no!" in Rust, where things are better controlled?

re the visualisation in FireDBG:

Your visualisation is really cool. I just saw it shared by some of my colleagues - we also do time travel but quite differently to you.

Debuggers are usually like looking at your program through a microscope, plus some commands for moving the microscope to different places. But that's not always what's wanted (and certainly not always what makes sense to newcomers).

Using people's spatial reasoning to help understand what's happened is quite exciting. I'd argue one of the reason that printf-debugging is so popular is because you get a clear, visual idea of roughly what happened in what order.

> I was particularly impressed this year by a demonstration of debugging stack smashing

I'm glad you liked it - and that's useful feedback for other demos we give!

> I'm still waiting on the keyserver to be able to run in Kubernetes though

I believe support for that is on the way. If you're already in touch then I imagine you'll get an announcement soon.

At lower optimisation levels there's a register allocated by the JVM to refer back to the bytecode, which makes things easy. In principle they could change that with a JVM revision - but in practice they don't, so it's an easy cheat.

We have some ability to walk data structures and the re-compute the program's behaviour by other means, which I probably shouldn't get into here. I think we could fall back on that more-or-less completely if we couldn't retrieve the bytecode pointer directly.

The fact the JVM introduces Safe Points to help it transition between optimisation levels is quite helpful!

Our original intention was to always fork a copy of the JVM back in time to handle Java debug protocol requests but that turned out to be painful and, thankfully, also unnecessary.

Oh, and regarding how long - it depends how long it takes to fill the circular buffer of non deterministic behaviour.

Serious compute bound workloads can run days with a gigabyte of non deterministic event log. Serious IO bound workloads burn it much faster.

For a rule of thumb, think of it consuming a few MB per second, so the length of the time travel is limited by how much of that you can store.

(the result is that it's quite feasible to update to new JVMs and to support multiple at once)

The short answer is yes - but not as tightly as you'd think. We don't need a deep awareness of what the JVM is doing, e.g. its internal data structures are largely opaque to us.

When we need to reconstruct state we always have the option of time travelling the process and re-executing to drill down on the details, though that's only required when you're replaying a recording.

Conceptually similar in that you can decide after-the-fact what state you want to see.

But Time Travel Debugging applies that to everything in the program, not just log statements - all function calls, variables, memory locations, etc can be reconstructed after the fact without having to log them explicitly.

As byefruit says above - we (undo.io) sell a Java Time Travel Debugger.

If anybody wants to try it, they should get in touch with us.

Our Java tech is based on an underlying record/replay engine that works at the level of machine instructions / syscalls to record the entire process. On top of that we've added the necessary cleverness to show what that means at Java level (so normal source-level debugging works).

That's different to e.g. Chronon, which I think was a pure Java solution: https://blog.jetbrains.com/idea/2014/03/try-chronon-debugger... It had some flexibility (e.g. only record certain classes) but at the cost of quite considerable slowdown and very large storage requirements.

At undo.io we're interested in using our time travel capability beyond conventional time travel debugging - a recording file contains everything the program did, without any advance knowledge of what you need to sample, so there's a lot of potential to get other data out of it.

I just read your post and don't think it would take much to integrate with some of the visualisations you posted about, as a first step.

We've played around in the past with a sampling profiler (code here, requires a copy of our product to be useful though it could easily port to rr): https://github.com/undoio/addons/tree/master/sample_function... which can output in a format understood by Brendan Gregg's flame frames (https://www.brendangregg.com/flamegraphs.html)

But that's not quite the kind of tracing you're talking about. We also built a printf-style interface to our recording files, which seems closer: https://docs.undo.io/PostFailureLogging.html

Something like that but outputting trace events that can be consumed by Perfetto (say) would not be so hard to add. If we considered modifying the core record/replay engine then even more powerful things become possible.

I worked in a room in the new Computer Laboratory building, in which "can we throw out this random old coffee machine, or is it history?" was a real question.

It definitely wasn't the first Trojan Room coffee machine but whether it was one of the family was an open question.

I always thought it would be a good fit for the EEE - maybe I should dig mine out again!

I've not quite got my brain past the idea that C99 is a new standard tbh - getting codebases I work with onto C99 has always been A Thing.

On Twitter: https://x.com/__phantomderp/status/1724279421320806411?s=20

There's also quite a nice story on Libreboot running on them e.g. https://minifree.org/

I've not tried that myself yet, though!

We used to use refurbed Thinkpad X220s for all engineers in the business - cheap, widely available, capable enough and with a docking station to use as a desktop. They'd take 16GB of RAM, though the official spec said the maximum was 8GB.

We moved onto L390 Yogas afterwards, which takes up to 32GB of RAM - I've been very happy with mine.

Both have been pretty solid for me, though I think the X220 probably had a lot more rough treatment overall.

Thanks - that looks interesting. It's especially appealing because it seems to add value beyond just being a neater wrapper to the same operations, it looks like it'll enable new ways of working with the tool.