Asahi developers have done amazing reverse engineering and driver development. But for the foreseeable short-term, there's no chance of it being installed on a current M-series iPad; it can't even be installed on a current Apple laptop.

I think the Macbook Neo might change that. It's not even an M-series, so there's a quite a lot of work to get Linux running on it. But because it's so much cheaper than the other laptops, and quite powerful, it makes a good "spare" laptop for people who can afford an M-series. And it probably has many internal functions similar to the M-series. I think it might get more attention by reverse engineering enthusiasts over the next couple of years.

Also, AI agents can help experts with reverse engineering labour in ways they couldn't a year ago. (I'd love to do this, if anyone out there wants to pay for it :-)

This is why network RFCs talk of "octets", to avoid the ambiguity. Octets are always 8 bits.

https://en.wikipedia.org/wiki/Octet_(computing)

OpenBSD didn't exist yet when /dev/random and /dev/urandom were created for Linux.

> Could one actually work like this, typing and everything? After my “heart-rate discovery” I decided I had to try it. I thought I’d have to build something myself, but actually one can just buy “walking desks”, and so I did. And after minor modifications, I discovered that I could walk and type perfectly well with it, even for a couple of hours. I was embarrassed I hadn’t figured out such a simple solution 20 years ago. But starting last fall—whenever the weather’s been good—I’ve tried to spend a couple of hours of each day walking outside like this

https://writings.stephenwolfram.com/2019/02/seeking-the-prod...

https://quantifiedself.com/blog/stephen-wolfram-finds-workin...

Their help page lists a bunch of 2FA app options, all of which run on phones, so it's understandable to think a phone is required. (I'm disappointed they don't list the app I use, which is Aegis Authenticator.)

But actually you can use any TOTP app, and they don't all need a phone. For example, macOS (desktop) has built-in TOTP 2FA as part of the password manager.

I recently had the best customer support experience I've ever had, and it was an AI chatbot, helping my in ways I would not expect from a first-line support human.

Recently I opened the chatbot window on the site of a supplier of electric vehicle chargers, and asked some obscure things about how I could access and modify the charger in a non-standard way. I explained I was doing some R&D testing of a novel way of using the chargers, and I would need to temporarily reconfigure the public unit we had already installed in an unusual, non-standard way, rewiring its network to intercept traffic via transparent proxy, make it behave a little differently than it normally does, and that I didn't have the credentials.

I was expecting the first-line person or bot on the chat to be unable to handle my non-standard request. What I was hoping for was this would start the process of getting me to someone who could help. I expected to take a few days or weeks to reach someone appropriate in the company, perhaps a sympathetic technician who could understand what I was trying to do.

To my amazement, in the first response it one-shotted a nearly complete answer to every part of my question, including the detailed and implied parts I'd left out for a later interaction. It figured out what I was doing and what that needed, told me exactly what to do and why, and showed me that it understood every aspect of my request. There were things in this I doubt anyone ever asked about before.

Because the answer so complete I didn't really need more. I asked it some things, e.g. about electrical safety, just to confirm my understanding of the one-shotted answer. In every reply, the chatbot was insightful, informative, helpful and correct, and I didn't need to explain things twice, or wait on hold, or be transferred to anyone else.

I don't know what service they were using, but whoever implemented it, hats off to them for using good technology and providing it with high quality data about the products they are supporting.

Honestly, if AI customer support calls or chats can be made that good consistently, that sounds great.

(That was a stark contrast to my awful expereinces with support at banks, where many humans made mistake after mistake, contradicted each other, and seemed to struggle to understand simple things. Particularly the one where a bank required me to fill out a form with basic company info, then it took 14 hours of phone calls and hold time until I got to the one person who understood straight away that the entries on the form were correct, had to be that way, and they could tick the "it's done" box. My execellent AI bot experience suggests a good one will always understand things like that on the first iteration, as if they are the best-trained and best-informed humans available. But other, worse AI bot experiences suggests the 14 hour calls would become infinitely long, never able to resolve the problem, leading to things like unnecessary account closures and locked funds needing a court to resolve.)

Using the API from DeepSeek or OpenRouter also requires a fee, but it's a different, pay-as-you-go payment model.

It failed soon after from water damage. I had to get it dried out and a new screen fitted, and some functions never worked properly since then.

I expected better as the specs claim IP67 ("Submersible in up to 1 meter of fresh water for up to 30 minutes"), and I used only a little water.

> Apple has locked my Apple ID, and I have no recourse. A plea for help* https://news.ycombinator.com/item?id=46252114

> Apple bans entire dev account, no reason given https://news.ycombinator.com/item?id=44601548

The KV cache of your Claude context is:

- Potentially much larger than 25GB. (The KV cache sizes you see people quoting for local models are for smaller models.)

- While it's being used, it's all in RAM.

- Actually it's held in special high-performance GPU RAM, precision-bonded directly to the silicon of ludicrously expensive, state of the art GPUs.

- The KV state memory has to be many thousands of times faster than your 25GB state.

- It's much more expensive per GB than the CPU memory used by a VM. And that in turn is much more expensive than the SSD storage of your 25GB.

- Because Claude is used by far more people (and their agents) than rent VMs, far more people are competing to use that expensive memory at the same time

There is a lot going on to move KV cache state between GPU memory and dedicated, cheaper storage, on demand as different users need different state. But the KV cache data is so large, and used in its entirety when the context is active, that moving it around is expensive too.

For example if you had two identical network cards, or SCSI disk controllers, you would need to physically reconfigure one of them away from its defaults.

There were only a small number of configurations available on each type of device, and some weren't configurable at all, so you could still get irreconcilable conflicts.

The Linux kernel of the time was full of hard-coded "probe" addresses and I/O ports, probe sequences to see if there was a device there, and IRQ auto-detection routines that triggered an interrupt to find out which IRQ line was asserted. Some of the probes had to be run in a particular order, so that probes for one type of device wouldn't break another type.

Later came ISAPnP, meaning Plug'n'Play for ISA, which allowed the operating system to use a clever protocol to talk simultaneously over ISA with all devices on the bus that support it, identify and select them individually, query what they required and and configure their addresses, I/O ports and IRQs to avoid overlap, or permit overlap where it was ok for IRQs. After the operating system was done configuring them, they operated as if they were configured physically like the older ISA cards. If necessary this could be implemented cheaply by adding an ISAPnP module to an existing ISA card design.

Eventually ISA was superceded by PCI which had better, well-defined enumeration and configuration methods from the start which all devices had to implement. PCI also allowed MMIO and IO base addresses to be set anywhere (32-bit), not just a small number or single option as ISA cards usually had, so there were no more address conflicts. The operating system still had to find the PCI bus registers itself, but after that, probing was simpler and more reliable than with ISA.

USB also arrived around the same time, and also had well-defined enumeration and configuration methods. Many simpler ISA devices were replaced by equivalent USB devices. Although USB was (and is) complex to implement at a low level, the complexity was handled very well by low-cost, generic USB modules on the device side, so it was easy for device manufacturers to use.

1. Use "git rebase -i commitid^" (or branch point, tag etc), ideally with editor set to Magit, set that commit to "edit" (single key 'e' in Magit) and let the rebase continue, do "git reset -p HEAD^" and select the hunks you want to remove from the first commit, "git commit --amend", then "git commit -a" (add -c if useful, e.g. to copy author and date from the previous one). or to keep the author date), then "git rebase --continue" to finish.

2. Same, but use "git reset HEAD^" (add -N if useful), then "git add -p" to select the hunks you do want to include in the first commit.

Afterwards you can do the "git rebase -i" command again if you want to reorder those commits, move them relative to other commits, or move the split-out hunks into another existing commit (use the 'f' fixup or 's' squash rebase options).

After doing this a few times and learning what the commands actually do, it starts to feel comfortable. And of course, you don't have to run those exact commands or type them out, it's just a raw, git-level view. "git rebase -i" and "git add -p" / "git reset -p" are really useful for reorganising commit hunks.