scottlamb

> Or is this a building permitting issue where for some reason the bureaucracy surrounding a permanent structure is expected to drag on for years but somehow they got the tents permitted rapidly?

Good point; some permit loophole might make sense.

It occurs to me this also could still turn out to be a giant failure: these may all still be unpowered, empty tents. They might end up taking two to three years to turn on, might never get a critical permit at all, etc. I'm vaguely recalling some story from Google's past. They had an experimental datacenter (`pq` maybe?) built out of shipping containers. There was some way they had hoped this would be cheaper that (iirc) didn't work out at all because the local fire marshal declared each shipping container to be a full structure and thus an unexpected set of regulations applied. and/or each may also have been required to have an emergency power-off button for the entire facility, which were hit by accident more than one might hope. They never built a second datacenter with that design.

Also remembering that for a long while Google's Dalles, Oregon site had building 1, building 3, and an empty concrete slab between them called building 2. I suppose Meta could have done something similar and had the slabs ready to go long ago.

That makes sense. Although I have to pick on your example a bit: wouldn't they still need a concrete foundation for all that weight and thus still need bulldozers? Still unsure how much of the work they're actually avoiding.

Meta's first five buildings took between two and three years to build, but Williams is almost done building out 200 MW (additional) off-grid power plants in a year, and to match that they're putting their equipment in tents. That raises questions for me:

* Did they expect the next five buildings to also take between two and three years to build if done in the same manner? I'd hope it'd be significantly faster the second time because they've perfected the design, found good local contractors and suppliers, etc.

* How much of the time was the actual structure vs. all the stuff inside they still have to do with the tents?

* How long are they expecting to keep this? Are they anticipating extra problems like leaking roofs?

* What are the "off-grid power plants"? Is this basically a whole bunch of diesel or natural gas generators? [edit: oh, yes, "The site is also powered by 200 megawatts of modular gas turbines". I wonder if they're trucking in the fuel too.] If so, yuck.

I'm typing on a SoflePLUS2 right now. It's based on the Sofle v2 design, which is described as having a 5-key thumb arc per side. But I try to limit thumb use to the innermost 2 or 3 keys per side after experiencing fatigue. I use the outermost 2 or 3 as opposite-hand modifiers (ctrl, opt, cmd) and try to pull my whole arm in to use them with the same-column finger, instead of treating them as a thumb key that requires folding my thumb underneath my palm as I keep my hand in the home position.

It seems like many in the ergo keyboard crowd are trying to never move their hands from the home position, and I think that might be a mistake. Use a variety of muscles, avoid unnatural positions. More broadly, my understanding is that the research behind using a tented/splayed split keyboard is solid (better shoulder through wrist positioning) but there's nothing really but anecdotal experience supporting the idea that vastly reduced key counts (and associated need for complex layer setups) or column-staggered layouts reduce pain and plenty of confounders (going from unibody to split simultaneously, maybe switching from QWERTY at the same time too, reducing speed, often learning decent form for the first time, often regression to the mean because people switch when they are having problems).

My previous keyboard was a split with traditional row stagger (Goldtouch) that Google's ergo team advised me to try forever ago. I switched recently because I wasn't liking the mushy feel of the keys, that the two "space bars" weren't distinguishable, that it doesn't have an integrated pointing device, and that after such long use I'd worn down the homing indicator on the f/j keys and was struggling to orient my hands correctly. But row-staggered layout was fine IMHO. Made it easier to learn, to switch between it and other keyboards when I had to, and to hit keys further from the home position.

Here's something from Kinesis, who have been designing split ergonomic keyboards for a long time: https://kinesis-ergo.com/wp-content/uploads/Advantage360-ZMK... search for "If your thumbs are sensitive" and "Guidelines for using your thumbs". And note that while they have keys under z/x/c they do not describe them as thumb keys.

Totally agree. They even vibe-wrote the paragraph I quoted.

I'd go so far as to say people who prompt AI to do something they can't do themselves are essentially non-technical management. I'm not a fan of non-technical managers of humans and similarly not a fan of this approach to AI either when quality really matters. (IMHO it's actually great for prototyping.)

The idea you can only learn to prompt well if you learned prompting before learning how to do the work yourself is strange, maybe even completely backwards. I've never heard teachers say to learn how to do math with a calculator then memorize multiplication facts later. Or anyone say the best managers are ones who first started in management and then developed technical expertise. Why are they so committed to the idea that this skill is so different than all the others?

It's probably a very convenient fantasy though for management types to think these expensive later-career people are useless or even harmful. And maybe said managers are non-technical themselves and don't understand the problems this creates.

I think the distinction __s is making is between layer toggles (layer is active between layer key presses, described as stateful) vs layer modifiers (layer is active while layer key is held).

And there are definitely reasons to minimize keyboard state. I've been playing around with programmable keyboards (running RMK in my case) with several thumb keys. My thumb was getting fatigued, so I tried using a layer toggle to avoid having to hold it while using the nav layer. I would hit it by accident and then get confused about why my keyboard isn't doing what I expect ("mode confusion"). That gets awkward, unproductive, and embarrassing real fast. You can display the mode via per-key LEDs and/or an OLED display, but those only help if you actually look down at the keyboard, which is not my habit. (I have thought about using a companion app to display an overlay on my computer's screen when in a non-default layer.)

fwiw, I think most of my thumb fatigue was from using my thumb on modifier keys beneath z/x/c and equivalent on the right, which required folding my thumb underneath my palm. Bad idea.

These keyboard designs have some really interesting ideas, but the ideas aren't all unambiguously good. Some of what are described as thumb keys really shouldn't be used with the thumb. I'm still on the fence about column stagger. I think a lot of the reason people avoid the number row on these keyboards is because the purely vertical reach on a column-staggered keyboard is more awkward than the diagonal movement you make on a row-staggered keyboard. And the idea that column stagger is better because it forces you to use e.g. the ring finger for "c" is based on an idea that it's bad to use the index finger for "c" even with a row-staggered keyboard, and I disagree with that. I also think they're undervaluing muscle memory (or maybe were made for people who never learned to type well on a row-staggered keyboard and are really committed to always using the column-staggered keyboard).

In an earlier thread, I wondered [1] if "concentrating around AI-native talent" in a round of layoffs was code for "we're firing all the old people", if "AI-native talent" meant people who had never learned how to do things without AI. Many folks said no, of course not. Well, in this case digital ocean has removed all doubt; "AI-native" means exactly that:

> Most of the engineers in this cohort are early in their careers. That was intentional. ... Engineers entering the field today don’t think of AI as a tool they’ve had to adopt. It’s simply how they build. That fluency isn’t something you retrofit into someone; it’s something you hire for directly.

Ugh.

[1] https://news.ycombinator.com/item?id=48029631

Hmm. I don't do game development myself, so take this with a healthy dose of salt. But...not necessarily. I think game development might be one of the more varied of the domains I mentioned. If you want to actually focus on the game, rather than learn about engine development, you might want to start with the choice of engine (e.g. Godot or Unity) and learn a language they recommend for integration (e.g. C#) rather than the language the engine itself is written in, as the code you write won't necessarily be as resource-intensive as the engine code itself. Though you certainly could start by picking e.g. Rust and then looking at popular engine/framework options there (e.g. Bevy or Macroquad). It might also vary a lot based on the type of game you're interested in.

Is there a particular domain you'd like to get into? It sounds like you're wanting to build expertise in something other than CRUD app assembly, but my language recommendations might change based on whether that's embedded, game development, distributed systems, system administration, etc.

I don't think in your shoes I'd prioritize learning Zig for any of these domains, though, for a few reasons:

* It's not a pre-req for understanding some existing corpus of important software (which is a big reason for C and C++ in 2026) or the language of choice for some current hot domain (as Python is for AI).

* It's not memory-safe, which (whether via GC or Rust's borrow checker) is increasingly viewed as a critical security attribute.

* It's not stable yet, so I'd expect a certain amount of running to keep in place both in your learning and in avoiding bitrot in anything you write in it.

* From the outside, the community seems strangely hostile as well as elitist.

A few I might suggest instead: Rust (both as a language I personally like and as the most different from the ones you've already touched), Go (which is a good choice for employability), SQL (maybe you already know this one if you're doing CRUD stuff but you didn't list it), bash, and more Python and/or TypeScript.

There are folks who have added them to external keyboard builds: https://kbd.news/How-to-integrate-a-trackpoint-into-your-key...

> the original commit being 4-5 lines long (what did claude do then?)

I've said "rebase onto <newbase>" and let it handle all the merge conflicts. I wouldn't expect this particular commit to conflict with anything, but it could have been part of a big series where it'd be worth doing that instead of running the rebase command yourself. It wouldn't surprise me if I picked up some Co-Authored-By:s along the way.

> This is a good example of what slips through LLM attention. It forces all allocations to be calloc as if it is a strict upgrade.

I wouldn't assume Claude made that decision; it's not as if that was some incidental thing that it snuck into a large commit. The commit message starts with "zero all new memory from allocations", and that's exactly what the commit does. What do you imagine the prompt was?

It seems totally plausible to me that a human initially thought this was an improvement, then rethought after discovering the RSS regression. And it's not a law of nature anyway that this change has to increase RSS; calloc could special-case the case in which memory was freshly returned from the OS, knowing fresh memory mappings are zeroed anyway.

I blame AI for these regressions mostly in the sense that it caused a flurry of vulnerability reports. Those led to a flurry of quick fixes. Sometimes quick fixes cause other problems.

Ugh, yeah, gross for `thunderbolt-net` only support one link in total, though presumably fixable.

> - Intuition on why- I can't point you to the line number, but I think it has to do with a fixed 4kb page size when communicating with the NHI that ends up becoming a bottleneck, perhaps 16kb pages on aarch64 apple help here?

I'm used to page size making a difference (due to TLB pressure) but not a factor of 2. I'm not familiar with DMA, so maybe there's some reason it'd be that dramatic there, but I'm unsure.

If the total size vs the latency of draining is just so small that it frequently fills and stalls, or if the sender and receiver can't be accessing it at once (but I don't think should be true?), it might make more sense. I think if I were wanting to make this thing go more smoothly, I'd probably start by measuring fractions of the time the tx/rx buffers are completely empty and completely full.

Actually, I'm not sure I'm understanding the text "we only have a single DMA ring for tx and rx" either. Does that mean one for tx and one for rx? or really one ring in total? if the latter, does it have to say drain fully before switching modes? that would seem pretty crippling.

> https://github.com/y3owk1n/neru

...which supports Vimium-style hints mode as well as the grid-based approach shown in this "Mouseless (app) explained in 80 seconds" video. It also has a very responsive maintainer.

Personally I like vimium's approach much better than the grid. Unfortunately not everything has a good accessibility tree (Zed sadly doesn't), but I just realized loading neru's page that I'm behind in versions. I haven't tried the "Native Vision OCR" addition to hints mode yet.

I also like having a trackpad right on the keyboard (using a SoflePLUS2 right now though I'm not totally sold on column stagger). Then I can use a real pointing device with only a slight movement of one hand. In the Mouseless video, the creator has tried to minimize the distance by putting the mouse between the halves of his keyboard, but I think he's both compromised the keyboard position to ease using the mouse (arms wide and parallel with wrists turned inward rather than arms converging toward a more splayed keyboard with somewhat closer halves, untented to minimize vertical separation compared to the mouse) and might have an uncomfortably small mousepad to avoid doing this even more. Not a compromise I'd want to make.

When I get that, I just repeat the question "where did you look in the docs?", or just "go look at the docs now" if they're really dense. I can't help them until they have a better answer.

It takes a few tries before they internalize that they need to have a doc link before expecting my help. Once they do, I might take the next step to saying "here's the answer; can you update the docs so the next person doesn't have to ask?" And it might take a few tries before that sticks too. My goal is to eventually turn them into someone who evangelizes the docs themselves.

When I write peer reviews for my colleagues, I describe their attitude toward documentation. If that's "they refuse to open the docs, frequently wasting their colleagues' time", it's not gonna go well. If it's "they make nice doc edits after I ask them", a little better. If it's "they proactively maintain the documentation", better still.

Of course all this is for stuff that one could reasonably expect to be documented. Help thinking through a design problem or debugging their in-progress PR is generally a different situation.

When someone asks me a question that is or should be documented, I like to ask where they looked for it (link or search query).

* Sometimes, this prompt is enough for them to find the answer.

* Sometimes, they tell me a spot that makes sense to them, and I make it have the answer. (Maybe just by adding a cross-reference.)

* If they refuse to look at the docs, I can't help them.

> now you've re-introduced out-of-order delivery which complicates re-assembly of large packets, retries, handling loss etc.

Still confused though. For a standard TCP/IP networking stack, that support is all there anyway, as it's not meant for point-to-point links, and out-of-order delivery is a thing that happens on the Internet. I haven't tried thunderbolt-net, but it says it implements Apple's ThunderboltIP, so I'd expect it's IP-based networking on top, and so it'd all work? Is it that out-of-order delivery is far more common than usual, and this path is so much slower (by impairing LRO/GRO) that it's not worth aggregating at all?

I'd understand if each pair is logically represented as a separate networking device, and then you have to set up link aggregation on top of that. (And iirc at least with some forms of aggregation a particular flow is bound to one link, so you'd have to have a bunch of streams to actually get bandwidth benefits.) So caveats for sure but I'd expect something to be possible. But does it just not support using both pairs at all?

Even with using one pair I still don't understand why you'd only get about 10G rather than 20G on a pair. I do see chapter 4 of the (your?) article talks about the single DMA ring maybe imposing the 10 Gbps limit but I don't have any good intuition for why. I don't know say how large the rings are or what latencies to expect on their operations or what packet sizes are supported which might help me understand.

> traditional Thunderbolt networking protocol ... performance may be as low as that of a 10 Gb/s Ethernet interface.

Ouch. Why so much lower than the physical bandwidth (or what they've achieved here)?

I admit I might roll my eyes a bit if the first thing I ever learned about KDE were its mascot's pronouns. But...

* That's not what's happening. The pronouns are mentioned in a social media post (presumably targeted at people already way into KDE) during pride month. This kind of wink to the LGBT community was in not that long ago even for the stodgiest corporate brands. You can easily ignore it if you don't care. In contrast, the website's landing page is primarily about the software. There's a (presumably temporary) banner at the top about the anniversary with the mascot; if you click through, it still doesn't mention pronouns AFAICT. It's not as if you have to go through a whole pronoun discovery cosplay to download the software.

* Open source projects' priority is often building a community of contributors over seeking (often small by comparison) financial donations. I commend efforts to establish a welcoming community. To me this seems like a very gentle way of saying this is a community where LGBT folks are welcome and homophobic/transphobic behavior is not. And I'm a believer in the "paradox of tolerance"—you can't tolerate intolerant behavior and expect a tolerant (much less welcoming) community.

* To the folks this is appealing to, and who perhaps are behind this decision, the current (US) political climate of intolerance feels almost inescapable. Even looking at this at in the most Machiavellian "how do I maximize the contributions I get without actually caring about humans" way, aligning with this community of folks who don't feel welcome in many other places, including a lot of excellent software developers, makes a lot of sense.

I can think of two reasons.

The first is what they describe here: as an attack. It's like why would anyone ever overflow a buffer with shellcode.

The second is that they are implementing a spec that requires appending a varint length-prefixed field to a buffer but don't really care about the space optimization, don't know the field's length when they start appending it, and don't want to put the field into a second, temporary buffer or slide it down into place. https://github.com/FFmpeg/FFmpeg/blob/468a743af1653a08f47081... vs say my own code which does the slide: https://github.com/scottlamb/retina/blob/6972ac4261ce7bf5b58...

Oh, no, I remembered the actual exploits because they were comically trivial. I searched for them and found the ids to paste here. I don't in general follow security vulnerabilities closely enough to be the one to ask about CVE visualizations and the like.

    $ login -n root
    Login incorrect
    login: backdoor
    No home directory specified in password file!
    Logging in with home=/
    #

I think this is supposed to be something like CVE-1999-0113 (or its very recently discovered/disclosed friend CVE-2026-24061). It's the sort of thing you might just know off the top of your head that would be handy for getting into a computer that hasn't been updated in 20 years.

> I think [`git log -n1 -- <path>`] is the fastest way to get the most recent commit time on a single file?

In terms of machine time? I'd guess so, but I'd also guess calling it for each of `git ls-files` is not the fastest way to get the most recent commit of all the files in a typical scenario (large repo, recent time of interest, most files not changed that recently). And especially if you're okay assuming the most recent commit by parentage is the one you want (even if parentage doesn't match chronological order); then filtering with `git log --name-only --since` (no path argument) seems better. A `git log` post-processing script could also stop early if it's seen a commit for each the files of interest (again, assuming you don't want to return a later date that is attached to an ancestor commit).

Anyway, cool tool, and it's rare that I would actually care about the machine efficiency of this pipeline enough to bother with the approach I just described.

On the other hand, the RP2350 actually is a microcontroller, and IMO a nice one for many purposes. PIO, high-quality datasheet, nice ecosystem, etc. And the Pi Zero 2(W) can do most things the Pi/Pi 2 could, with a smaller footprint and less power consumption. Variety is nice.

> It is missing the Italian, Japanese, Greek and Mexican cooking - that are incredibly popular worldwide and it is incomplete without them, and nothing from Africa at all or Middle East.

That's overstating it. There are certainly English-language sources describing Italian, Japanese, Greek, Mexican, African, and Middle Eastern recipes. They're likely not the most authoritative sources, but it's not as if I'd expect these cuisines to be completely absent.

The actual corpuses they used are listed in the supplement: https://arxiv.org/src/2605.22391v1/anc/supplement.pdf

edit: that document also breaks it out by region, including 33,923 Japanese recipes which seems respectable. 324 from Sub_Saharan_African which is tiny but still more than 0. Italian and Greek are likely a fair chunk of Mediterranean (164,107). I don't see a breakout for Middle Eastern. Some might be lumped into Mediterranean as well.

But I'm talking about general day-to-day security as well as off-boarding. What stops a single disgruntled employee from doing this before being fired? And if you have a good story there, why do you need the most extreme approach to "off-boarding"?

It makes sense to terminate someone's high-risk credentials immediately when they're fired. But it's extremely worrying if every credential held by every employee is considered high-risk. It suggests a bigger failure. "Unilateral access to a database filled with plain-text passwords" shouldn't ever exist. "Email account filled with dangerous stuff" should at least be unusual.

> Too complicated and subjective, stinks of more risk.

I actually think there's less risk, because it's not as narrowly focused on what a just-fired employee can do. That's not the only scenario of concern.

> Also, I don't think it's dehumanizing it all (having been on the receiving end of it way back when during a layoff, and involved in the process more times than I care to count).

Interesting. Thanks for the perspective. I've been fortunate enough to not be on the receiving end of a lay-off, knock on wood. It's happened to my teammates/reports though. Wasn't my decision. :-(

You always have to be careful about overfitting to a specific scenario like "this but if they had also forgotten to lock out the other evil twin". I'd prefer a system that is robust to a malicious employee (more likely: compromise of an employee's credentials) but has a slight gap in the "evil twins" scenario over one that prevents all post-firing malicious access from twins but doesn't consider at all what happens if a current employee's credentials are compromised.

> Just think of all the info you have in your inbox.

Meh? Sure, stuff that would help assemble a credible phishing attack, but not customer SPII or huge amounts of intellectual property or anything. If the assumption is that employees' inboxes are full of dangerous things, I would focus on fixing that.

> When you are talking about access like they had "make firings as abrupt as possible including terminating all access immediately" not doing this is incompetence.

You're proving my point—employers take the most extreme lesson and it's considered expected practice. They absolutely should have immediately terminated the credentials that granted unilateral access to sensitive databases. (Ideally those would never exist in the first place—there are two-person schemes. A pair of bad actors...well apparently happens according to this article...but is far more unusual.) But employers regularly (but shouldn't) terminate all access including credentials that allow last email to colleagues exchanging personal contact info or something.