In many ways, the tuple (BBC Micro, Acorn Computers, arm) is analogous to (IBM PC, Intel, x86).
In many ways, the tuple (BBC Micro, Acorn Computers, arm) is analogous to (IBM PC, Intel, x86).
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).
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?
Subagents seem pretty similar to using zen mcp w/ OpenRouter but maybe better or at least more turnkey? I'll be checking them out.
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).
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.
I imagine some of the Roman stuff was built on even older roads and channels.
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.
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.
> 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.
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.
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.