Readit News logoReadit News
mark_undoio commented on Vetinari's Clock (2011)   waitingforfriday.com/?p=2... · Posted by u/Rygian
mark_undoio · 3 days ago
In Cambridge we've got a clock called the Chronophage which is intended to be a sinister "eater of time" - the designer has done a good job of making it feel uncomfortable to look at. There's some detail here: https://www.corpus.cam.ac.uk/articles/secrets-corpus-clock

My memories of what I've heard over time:

* The grasshopper escapement actually is the demonic insect that sits on the top, "walking" around the serrated ring.

* Although it's backlit electronically it's actually a fully mechanical design - including all of the weird things it does.

* The Chronophage itself blinks its eyes unnervingly.

* It sometimes pauses or ticks slightly backwards, then runs faster to catch up again.

* On certain special dates it does extra weird stuff.

* The "chime" is a metal chain dropping into a box.

There were three made in the series, this was the first one. I've always found it slightly unappealing aesthetically but also compelling - there's no arguing with the fact that there's always a crowd of fascinated observers looking at it.

mark_undoio commented on BBC Micro, ancestor to ARM   retrogamecoders.com/bbc-m... · Posted by u/ingve
cperciva · 22 days ago
The article... well, it doesn't bury the lede, but it does completely omit it outside of the headline. For anyone who doesn't know the context: The BBC Micro was built by Acorn Computers, which proceeded to design the Acorn RISC Machine -- later renamed to Advanced RISC Machine and thence to simply "arm".

In many ways, the tuple (BBC Micro, Acorn Computers, arm) is analogous to (IBM PC, Intel, x86).

mark_undoio · 21 days ago
Acorn was doing stuff in Cambridge UK until more recently than I'd realised - it effectively incubated a load of talent that went on to find other companies. Famously ARM span out of it but many others also went on to do cool things - my current company was founded by Acorn people.
mark_undoio commented on QNX: The Incredible 1.44M Demo   archive.org/details/QNX_i... · Posted by u/sugarpimpdorsey
mark_undoio · a month ago
This demo was so cool. There were lots of alternative OSes out there back then that felt very impressive.

Linux at the time was cool too but less polished than now. Lots of people were on the Win 9x series, which wasn't amazing - and Mac OS X was not yet fully baked.

These other OSes (QNX, BeOS) felt polished, amazingly fast - and slightly alien. The main sad thing from my perspective was that I couldn't get them online (my machine had a winmodem and nobody had open source drivers for those for ages).

mark_undoio commented on The History of Windows XP   abortretry.fail/p/the-his... · Posted by u/achairapart
lproven · a month ago
mark_undoio · a month ago
Encarta 95 had it - I remember thinking how cool it was that it looked like Win 95.
mark_undoio commented on Cursor CLI   cursor.com/cli... · Posted by u/gonzalovargas
Touche · a month ago
They don't have arbitrary access over your file system. They ask permission for doing most everything. Even reading files, they can't do that outside of the current working directory without permission.
mark_undoio · a month ago
I'm pretty comfortable with the agent scaffolding just restricting directory access but I can see places it might not be enough...

If you were being really paranoid then I guess they could write a script in the local directory that then runs and accesses other parts of the filesystem.

I've not seen any evidence an agent would just do that randomly (though I suppose they are nondeterministic). In principle maybe a malicious or unlucky prompt found somewhere in the permitted directory could trigger it?

mark_undoio commented on Claude Opus 4.1   anthropic.com/news/claude... · Posted by u/meetpateltech
rapind · a month ago
In this case I don't think the controller needs to be the smartest model. I use sonnet as the main driver and pass the heavy thinking (via zen mcp) onto Gemini pro for example, but I could use openai or opus or all of them via OpenRouter.

Subagents seem pretty similar to using zen mcp w/ OpenRouter but maybe better or at least more turnkey? I'll be checking them out.

mark_undoio · a month ago
Amp (ampcode.com) uses Sonnet as its main model and has GPT o3 as a special purpose tool / subagent. It can call into that when it needs particularly advanced reasoning.

Interestingly I found that prompting it to ask the o3 submodel (which they call The Oracle) to check Sonnet's working on a debugging solution was helpful. Extra interesting to me was the fact that Sonnet appeared to do a better job once I'd prompted that (like chain of thought prompting, perhaps asking it to put forward an explanation to be checked actually triggered more effective thinking).

mark_undoio commented on Comparing the Glove80 and Maltron Keyboards   tratt.net/laurie/blog/202... · Posted by u/ltratt
mark_undoio · 2 months ago
I've heard various online stories, over the years, about how nobody nails the ergonomics quite like Maltron does. Which is amazing given how long they've been about.

I have an old Maltron that I got cheap (many years ago and it was old then!) and it's remarkable how unlike a modern consumer product it was. Thin, vacuum formed plastic, point-to-point soldered wire keyboard matrix. But that classic shape, keys with full sized key caps and travel, etc are all present.

The Kinesis I also have is much more mainstream - it feels more solid and looks more like a consumer product. But I understand it's just not quite as good, ergonomically.

mark_undoio commented on Roman Roads Research Association (UK)   romanroads.org/index.html... · Posted by u/countrymile
mark_undoio · 2 months ago
It's quite weird having local footpaths and paved roads that turn out to have been constructed by the Romans originally - around here that also applies to canals, drainage ditches, etc. It just blends into modern reality.

I imagine some of the Roman stuff was built on even older roads and channels.

mark_undoio commented on Mercury: Ultra-fast language models based on diffusion   arxiv.org/abs/2506.17298... · Posted by u/PaulHoule
kccqzy · 2 months ago
> Maybe I've just got unlucky in the past, but in most projects I worked on a lot of developer time was wasted on waiting for PRs to go green.

I don't understand this. Developer time is so much more expensive than machine time. Do companies not just double their CI workers after hearing people complain? It's just a throw-more-resources problem. When I was at Google, it was somewhat common for me to debug non-deterministic bugs such as a missing synchronization or fence causing flakiness; and it was common to just launch 10000 copies of the same test on 10000 machines to find perhaps a single digit number of failures. My current employer has a clunkier implementation of the same thing (no UI), but there's also a single command to launch 1000 test workers to run all tests from your own checkout. The goal is to finish testing a 1M loc codebase in no more than five minutes so that you get quick feedback on your changes.

> make builds fully hermetic (so no inter-run caching)

These are orthogonal. You want maximum deterministic CI steps so that you make builds fully hermetic and cache every single thing.

mark_undoio · 2 months ago
> I don't understand this. Developer time is so much more expensive than machine time. Do companies not just double their CI workers after hearing people complain? It's just a throw-more-resources problem.

I'd personally agree. But this sounds like the kind of thing that, at many companies, could be a real challenge.

Ultimately, you can measure dollars spent on CI workers. It's much harder and less direct to quantify the cost of not having them (until, for instance, people start taking shortcuts with testing and a regression escapes to production).

That kind of asymmetry tends, unless somebody has a strong overriding vision of where the value really comes from, to result in penny pinching on the wrong things.

mark_undoio commented on Building the Rust Compiler with GCC   fractalfir.github.io/gene... · Posted by u/todsacerdoti
saagarjha · 2 months ago
> Normally, debuing the compiler is fairly straightforward: it is more or less a run of the mill executable.

> In the bootstrap process, the entire thing becomes way more complex. You see, rustc is not invoked directly. The bootstrap script calls a wrapper around the compiler.

> Running that wrapped rustc is not easy to run either: it requires a whole lot of complex, environment flags to be set.

> All that is to say: I don’t know how to debug the Rust compiler. I am 99.9 % sure there is an easy way to do this, documented somewhere I did not think to look. After I post this, somebody will tell me "oh, you just need to do X".

> Still, at the time of writing, I did not know how to do this.

> So, can we attach gdb to the running process? Nope, it crashes way to quickly for that.

It's kind of funny how often this problem crops up and the variety of tricks I have in my back to deal with it. Sometimes I patch the script to invoke gdb --args [the original command] instead, but this is only really worthwhile if it's a simple shell script and also I can track where stdin/stdout are going. Otherwise I might patch the code to sleep a bit before actually running anything to give me a chance to attach GDB. On some platforms you can get notified of process execs and sometimes even intercept that (e.g. as an EDR solution) and sometimes I will use that to suspend the process before it gets a chance to launch. But I kind of wish there was a better way to do this in general…LLDB has a "wait for launch" flag but it just spins in a loop waiting for new processes and it can't catch anything that dies too early.

mark_undoio · 2 months ago
Process recording by time travel debug seems like a good fit for this problem - then you can capture 100% of process execution and then go back and investigate further.

We (Undo.io) came up with a technique for following a tree of processes and initiating process recording based on a glob of program name. It's the `--record-on` flag in https://docs.undo.io/UsingTheLiveRecorderTool.html. You can grab a free trial from our website.

For open source, with rr (https://rr-project.org/) I think you'd just `rr record` the initial process and you'll end up capturing the whole process tree - then you can look at the one you're interested in.

As others have said you could also do some smart things with GDB's follow-fork settings but I think process recording is ideal for capturing complicated situations like this as you can go and review what happened later on.

u/mark_undoio

KarmaCake day644January 28, 2022
About
I'm the CTO at Undo - https://undo.io

We make software that can record/replay other software (including running it backwards). It's cool, please try it.

Sometimes I share things on Twitter - https://twitter.com/mark_undoio Sometimes I write articles (along with my colleages) about GDB - https://undo.io/resources/gdb-watchpoint/

View Original