mhandley

Coming back from the pub? At least when I'm on a train at 12:41am, that's usually the reason.

Thinking about it some more, it really is about consistency regarding the cursor. On my trackpad, not in "natural scrolling" mode, I get this:

  - One finger down moves the cursor down through the text.
  - Two fingers down moves the cursor down through the text (moving the text up)
  - Thumb-click plus one finger down moves the cursor down through the text (and selects).

  - One finger down moves the cursor down through the text.
  - Two fingers down moves the cursor up through the text (moving the text down)
  - Thumb-click plus one finger down moves the cursor down through the text and selects.

It's not just the ergonomics - in my head I'm moving the cursor (and with it my view) down through the document, not moving the document up. Which is mentally different from a touchscreen, though I expect people who grew up with touchscreens never built that mental association that we're moving the cursor. Fortunately Apple allows be to change it. <end old-man-mode>

If you want more details, there's the protocol spec from OCP [0] and a paper [1]

[0] https://opencompute.org/documents/ocp-mrc-1-0-pdf

[1] https://cdn.openai.com/pdf/resilient-ai-supercomputer-networ...

[I work on this]

Back when replaceable batteries were the norm, I had two Blackberries that survived going through the washer and dryer.

Agree about the watch - I wear a Casio LCW-M100TSE, which is also very robust (titanium case, saphire glass), never needs the battery changing and never needs setting (except for travel). But most importantly, it does what it does really well and never bugs me about anything. Downtime is important.

It seems like trucks are a use case where battery swapping would make a lot of sense. Unlike with cars, the battery doesn't need to be a structural element, and there's much less need for it to be a strange shape, as in some cars.

I don't see her later on in the news article - just in the video. Did Apple remove the picture after you pointed it out?

Neutrino mass is another anomaly, which is at least slightly easier to probe than quantum gravity: https://cerncourier.com/a/the-neutrino-mass-puzzle/

One interesting gap in the standard model is why neutrinos have mass: https://cerncourier.com/a/the-neutrino-mass-puzzle/

I'm British, but when submitting papers for blind review, always use American spelling for obvious reasons. I suppose I could change it after acceptance, but that would just be pretentious.

I've used bubblesort when simulating LEO satellite constellations, calculating which satellite is closest to a location. I used one single backwards pass of bubblesort, so O(n) every k timesteps to bring the closest to the head of the array, then every timestep just do one backwards bubblesort pass over the first few in the array. Given satellites move smoothly, if you initialize right (a few full passes at the start to get the closest few at the front) and get the constants right so a satellite outside the front few in the array can't have moved far enough to become closest without being promoted to the front few by a periodic full pass, then you always maintain the closest at the front of the array very cheaply. And this has the advantage of also being very simple to code.

And if you do get one somehow, it's really hard to spend. Many places won't accept them.

It's definitely possible to break the rules. In fact, to give a truly outstanding talk that everyone remembers, you probably have to break the rules (speaking as someone who coded an entire Sigcomm presentation in a 3d game engine). But most early career researchers, for whom this advice is presumably intended, are not good enough at giving talks for that to be a good idea. In fact most tenured professors aren't too. If you do break the rules, you need to have a very clear idea in your head as to how you're going to pull it off, and a good idea of who your audience is and how they'll perceive it, and those are both hard to achieve without a lot of experience.

If you have two pipes of the same height, one filled with fresh water and one with salt water, the pressure will be greater at the bottom of the salt-water pipe because salt-water is denser. Connect them at the bottom with a pipe and water will flow from salt to fresh until the pressures equalize. But connect them with a membrane, and this is countered by the osmotic pressure of fresh water trying to get to salt water, so you don't get any magic flow for free. You have however got a pressure gradient for free - just not enough to desalinate.

If you put this in the ocean, you can remove the salt pipe and get the same effect. But if you want continuous fresh water, you need to further increase the pressure difference across the membrane by continuously lowering the height of the fresh-water column by pumping water up and out of the top. That takes energy, but not as much as it would take if we had to raise the pressure on the salt-water side.

The listing mentions a 30,000 gallon reservior, so I imagine rainwater collecion from the "parade ground".

If we had 9-bit bytes and 36-bit words, then for the same hardware budget, we'd have 12.5% fewer bytes/words of memory. It seems likely that despite the examples in the article, in most cases we'd very likely not make use of the extra range as 8/32 is enough for most common cases. And so in all those cases where 8/32 is enough, the tradeoff isn't actually an advantage but instead is a disadvantage - 9/36 gives less addressable memory, with the upper bits generally unused.

I also started using Jove back when 30 of us shared one PDP 11/44 running BSD Unix, and it was antisocial to use something as heavyweight as Emacs. 40 years later, I'm still using UNIX and Emacs.

I've spent the last few weeks writing a non-trivial distributed system using Codex (OpenAI's agentic coding system). I started by writing a design brief, and iterated with o3 to refine it so it was more complete and less ambiguous. Then I asked it to write a spec of all the messages - didn't like its first attempt, but iterated on it til I did like it. Then got it to write a project plan, and iterated on that. Only then did I start on the code. The purpose of all this is to provide it some context.

It generated around 13K lines of Go for me in just over two weeks. I didn't previously speak Go, but its not hard to skimread to get the gist of its approach. I probably wrote about 100 lines, though I added and removed a lot of logging at various times to understand what was actually happening. I got it to write a lot of unit tests, so that coverage testing is very good. But I didn't actually pay a lot of attention to most of those tests on the first pass, because it generally got all the fine detail stuff exactly right on the first pass. So why all the tests? First, if something seems off, I have a place to start a deep dive. Second, it pins down the architecture so that functionality can't creep without me noticing that it is needing to change the unit tests.

Some observations.

- Coding this way is very effective - the new models almost never make fine detail mistakes. But I want to step it through chunks of new functionality at a size that I can at least skim and understand. So that 13K LoC is about 300 PRs. Otherwise I lose track of the big picture, and in this world, the big picture is my task.

- Normally the big design decisions are separated by days of fine detail coding. Using codex means I get to make all those decisions nearly back-to-back. This is both good and bad. The experience is quite intense - mostly I found the fine-detail coding to be "therapeutic", but I don't get that anymore. But not needing to pay attention to the fine detail (at least most of the time), means I think I have a better picture in my head of the overall code structure. We only have so much attention at any time, and if I don't have to hold the details, I can pay attention to the more important things.

- It's very good at writing integration tests quickly, so I write a lot more of them. These I do pay a lot of attention to. Its these tests that tell me if I got the design right, and if not, these are the place I start digging to understand what I need to change.

- Because it takes 10-30m to come back with a response, I try to keep it working on around three tasks at a time. That takes some effort, as it does require come context switching, and effort to give it tasks that won't result in large merge conflicts. If it was faster, I would not bother to set multiple tasks in parallel.

- Codex allows you to ask for multiple solutions. For simpler stuff, I've found asking for one is fine. For slightly more open questions, it's good to ask for multiple solutions, review them and decide which you prefer.

- Just prompting it with "find a bug and suggest a fix" every now and then often shows up real bugs. Mostly they tend to be some form if internal inconsistency, where I'd changed my mind about part of the code, and the something elsewhere needed to be changed to be consistent.

- I learned a lot about Go from it. If I'd been writing myself, my Go would have looked more like C++ which I'm very familiar with. But it wrote more idiomatic Go from the start, and I've learned along the way.

- Any stock algorithm stuff it will one-shot. "Load this set of network links, build a graph from them, run dijkstra over the graph from this node, and tell me the histogram of how many equal-cost shortest paths there are to every other node." That sort of stuff it will one-shot.

- It's much better than me about reasoning about concurrency. Though of course this is also one of Go's strengths.

Now I don't have any experience of how good it would be for maintaining a much larger codebase, but for this sort of scale of utility, I'm very impressed with how effective it has been.

Disclaimer: I work at OpenAI, but on networks, not AI.

That sounds reasonable for access to actual content, but it produces a huge new incentive to constantly produce vast amounts of AI-generated slop served via Cloudflare. Is there a way to disincentivize this?

The ones in towns will mostly disappear. There will be enough chargers at supermarkets, malls, restaurants, anywhere people actually want to go, and most people will charge at home or work. The remaining business won't be enough to keep in-town gas stations in business. Range anxiety will become more of an issue for gas cars.

On highways, it will be a different situation. There will be plenty of gas and diesel still available, as the remaining business from towns becomes more concentrated. You won't find a gas station without a restaurant attached though. Fast chargers will be common, but ultra-fast ones won't be as common as we'd like, as they will want to keep you just long enough to buy a meal, etc.

I came of age in the 8-bit era of the early 80s, rode the Internet wave of the 90s and early 2000s, kind of missed the mobile wave but spent that time developing ideas that would eventually turn out to be useful for AI, and now I'm having great fun on the AI wave. I'm happy to have grown up and lived when I did, but I feel that each era of my life has had its own unique opportunities, excitement and really interesting technical problems to work on. And perhaps most importantly, great people to work with.

If it's really just 1m behind, it doesn't need to respond individually to anything except pedestrians. And you can solve that with some extensible tapes that actually do connect the vehicles to prevent pedestrians walking between them.

With computerized control and a comms link between the vehicles, you could probably have one vehicle follow 1m behind another, so they are effectively a train. If you still have a driver at all, you only need one in the front vehicle.

It's only there for a month.

When I used to do gliding (sailplane, not hang gliding or paragliding) many years ago, it was not classed as a dangerous sport for insurance purposes. Don't know about the other fields of gliding. General aviation was classed as riskier - I guess glider pilots are more used to the fact that they don't have a working engine!

With a high fraction of renewables, the reverse is probably better in the long run. The larger geographic area you connect, the less you're affected by weather systems, and the wider area you can draw dependable dispatchable power such as hydro from. But that depends on having enough grid capacity to move enough power around, which is currently a problem.

But I wonder from a reliability (or lack of cascading failures) point of view whether synchronous islands interconnected with DC interconnects is more robust than a large synchronous network?

Beck, meaning stream (small river), is one I remember from growing up in the north east.

The micromouse would have been spring 1983 I think. If there were any pictures, they'd probably be in my parents huge pile of unindexed old 35mm slides!

I agree completely about that sense of discovery. No-one around me knew anything about computers and the information available was limited, but somehow figuring things out for myself was a key part of the attraction for me. And it served me very well as the foundation for a lifetime of research too. If you're passing through London and fancy a beer, look me up, and we can reminisce!