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 would guess the real problem is contractors are bottle-necked in good times, but not stupid enough to expand - knowing that bad times will come and they have to pay for all the expansion. (humans can be laid off, but you still need to make the payment on the bulldozer)
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.
It's funny because at first I thought it made sense but the more I think about your question the more I'm skeptical. You still need the rack. Power distribution. Data lines. Cooling lines and whatever those connect back to. All the stuff that would have been embedded under the floor has to go somewhere (labor) and still has to be assembled (more labor). So they're saving time on what, the cement and steel shell?
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?
> 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.
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).
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.
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.
Gosh, that seems like a conclusion someone came to using AI lol.
I agree that intuition is important, and that it's sometimes easier to develop correct intuition without a conflicting bias/habit, BUT... I don't think traditional engineering skills conflict with using AI tools. If anything it's more important, but maybe that's just the recently sprouted gay hair on my head talking
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.
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.
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.
> 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.
You don't really have to guess. The guy told us the AI didn't suggest this specific change:
> The change to zero memory was my idea and my change. It was a reaction to a security report I got which caused use of an element past the end of an array. By zeroing the allocation I could ensure that misuse of that memory if a similar bug came up in the future could only cause a null ptr deref, which is better than the chance of a valid pointer.
It got a claude co-authored tag on it as I got it to do some tidy ups of a series of commits, and that is just what it does when it makes any modification. It doesn't mean the change was written by claude. It was written by me.
How does that prevent reading past the end of the buffer? Or change how bytes outside the buffer are used? Are these arrays of pointers so that the “null ptr deref” comment makes sense?
Or am I the bozo and don’t know what’s happening here?
It doesn’t. It’s just that dereferencing a zeroed pointer reliably crashes the program (unless you specifically do funky things with mmap) but dereferencing garbage memory as a pointer could do a lot more insidious damage.
Haven't looked at the code, but the allocated memory could be larger than necessary to make "off-by-one" or "off-by-a-few" errors less deadly. Then zeroing it out makes it even less so. Defense in depth.
Or it's an allocation for an arena? The zeroing might help trigger 0 derefs earlier if the overrun happens for the object that are then allocated in the arena (and not by allocating more objects than the arena can provide)
The code is part of a function called expand item list. It looks like it over allocates memory and uses a bump pointer for internal allocation, only expanding the allocation when necessary. Thus OOB writes to the list would hit the allocated memory.
You’re not a bozo but it is helpful to read the code.
okay I had not read this or any discussions there (except the one linked in the post), but this looks weirder. the comment you linked is a dev responding to what is very clearly a bot comment. I am sure they have good intentions and I have no reason to believe otherwise as I have no connection to the project whatsoever, but the original commit being 4-5 lines long (what did claude do then?) and the revert description is almost certainly written by an LLM makes in my mind the slop argument stronger.
I hope if this doesn't come across as unkind towards the dev who gives their time and energy to the project. Grateful for that.
> 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.
...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.
Reminds me of the old #bash IRC channel. Asking things found in the tutorials got you either a cold shoulder, or more often, triggered by criptic "32" or "5" from admins - a bot answering your question shallowly and then sending you to a specific site in the tutorial.
You got very good answers to any original questions, though you should start by showing where you searched for answers already.
They hated "do it for me" kind of requests that usually looked like somebody asking you to do their homework assignment. I even got called out on it once, but could happily reply that I'm actually just messing with my system as a hobby.
One time I had a "do it for me" request.
I've run a sed command which appended sth.bak to every file of some type on, but accidently made it execute on all files on the system. They quickly gave me a one liner to fix my machine (a VM, but it took long to set up).
However, when after fixing the system, I asked for explanation of the xargs command that was used there, I instantly got sent off to the FAQ with a number.
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.
People rag on StackOverflow for being mean, but it was a good training ground for developing habits that satisfy the social contract of professional spaces.
A USB4 40Gbps cable consists of two 20G tx/rx pairs. The in-kernel networking implementation is single-stream and just uses one pair, and won't e.g. stripe across both pairs or across multiple cables, which was the main bandwidth unlock in TFA. Doing so would be a much more complicated undertaking, since now you've re-introduced out-of-order delivery which complicates re-assembly of large packets, retries, handling loss etc. The verbs interface is a lot simpler than that of a full IP stack, so although was possible to get this working across rails, may not be so simple for something pretending to be ethernet.
> 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.
Yeah, thunderbolt-net is IP on top and it does work as you say, with a few caveats:
- On a single cable with two rails available, the thunderbolt-net grabs one and uses that. Without patching the kernel, there's no way to make it present a second interface using the remaining pair.
- If you had a second cable between the machines (for 4 total rails), thunderbolt-net will still only grab one rail, because the abstraction across which it's making the links sees an identical peer at the end of both links and so falls into the same trap as above. There is no LRO/GRO anyway (or it's buggy- I forget) on the linux version.
- Why you only get 10G rather than 20G on single pair- actually, this might be something specific to the Strix Halo SoC that I was testing on- on a different (still AMD) chipset and an Apple TB5 Mac I did see closer to 22G in one direction, but still 8 in the other. The Strix Halo NHI seems to be 'stripped down' (as expected, for mobile) in ways I don't really understand.
- 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?
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.
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.
* 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.
reply