adonovan

Inferring pronunciation from spelling is very regular in French; the reverse, not so: there may be many ways to spell a sound like “o”, each with a different meaning.

This trend is far older than the AI era. The British magazine Private eye for many years in the 1990s had a running joke in which each issue displayed the new logos of old companies that had spent a fortune on rebranding. All of them were variations on circles.

Naomi Klein in her book No Logo interprets it as a form of abstraction away from the passé and less profitable business of whatever concrete task those industries used to do, and towards outsourcing, branding, and financialization as an end in itself.

How many parts is this skeleton disassembled into in transit? Each bone? Crazy project!

I agree. This is a most unexpected ray of hope.

Can someone with expertise explain what kinds of medical imaging are theoretically possible with this kind of sensor?

Understood. My point is that the job requirements are almost mutually exclusive: must be physically and mentally fit enough for arduous travel and harsh work, yet basically suicidal.

Like enjoying earthly pleasures? The terminally ill do not make good astronauts.

I'd be surprised if there's a single person alive who would volunteer for a suicide mission to a miserable cold dark planet and could travel there for nine months in a tin can through a harsh radiation/muscle atrophy/psychological environment and arrive in any condition to conduct useful scientific work.

It seems quite common for the infrastructure teams to put up a dashboard just to keep a sense of what is going on, but it is then misinterpreted as a “leaderboard” and encourages the most prolific users to find creative ways to squander more to stay the “winner”. Management is slightly disappointed by the waste but also happy that staff are engaging with their future replacements.

For a while we’ve been fixing telemetry-reported crash bugs in the project I maintain, and now hardware bugs are showing up with some frequency. I was amazed how common they are. Sometimes data values (e.g. SP register) are corrupted, but other times even infallible operations (e.g loads of rodata constants) crash, indicating that the instruction itself was corrupted. So, yeah, I believe you’ll eventually see UUID collisions, but not because the underlying cryptanalysis was wrong.

Does the ground source heat up (or cool down) over time, making it less effective? The deep ground is very well insulated, which is why after a century of operation the London Underground is 10 degrees warmer. I wonder whether GSHP users need to balance their load by (say) consuming more heating than they actually need in winter so that summer cooling remains effective.

This administration does love "force".

Another situation to avoid the XOR trick, even when registers are tight, is when swapping pointers in a garbage-collected language, since the intermediate bit patterns are invalid pointers: if a GC mark phase occurs at that moment, you might lose some objects, or spuriously mark others as live.

Quite. A burger that wears its hat at a jaunty angle for a rakish look.

I once wrote a contract document in PostScript that changed the wording based on the date. Two parties could cryptographically sign an agreement in the document, which would change when printed on a later date.

One of the reasons we don’t use PostScript so much any more.

It's not an illegal monopoly to be the sole entity capable of a technique. The problems come from manipulating the market to prevent competition.

The subject of this story is a single proton that you would definitely feel if it hit you: https://www.fourmilab.ch/documents/OhMyGodParticle/

Also weird phrasing: "a staggering 1.8 degrees" begs the reader to think of it as a large number (which in fact it is, as you point out) yet their intent seems to be, ironically and paradoxically, to diminish it.

Thanks, that's a bug. We should never inline a function that directly calls recover. I've filed https://go.dev/issue/78193.

The “will lead astray” part is concerning. If you already have a clear idea in mind, you probably don’t need to have the debate with coworkers.

Yeah, I certainly wouldn't trust it to run any distance unattended, and I started this project with strong ideas about the parameters of the design, so I know what I want and what won't fly. But as you say, it can help tease out unexpected pros and cons of certain choices along the way.

In summary: obviate experts, receive correct guidance, save time —- pick any two.

It's simpler than that: it can't do the first, nor reliably the second, but it has saved me time.

I’ve been an overt AI hater but have found very recently that, though I still hate a great many things about AI, it has become useful for coding.

In 10m Gemini correctly diagnosed and then fixed a bug in a fairly subtle body of code that I was expecting to have to spend a couple hours working on.

I spent much of the past week using Gemini to build a prototype of a clean new (green field) system involving RPCs, static analysis, and sandboxing. I give it very specific instructions, usually after rounds of critical design discussions, and it generates structurally correct code that passes essentially valid tests. Error handling is a notable weakness. I review the code by hand after each step and often make changes, and I expect to go over the over the whole thing very carefully at the end, but it has saved me many hours this week.

Perhaps more valuable than the code has been the critical design conversation, in which it mostly is fluent at the level of an experienced engineer and has been able explain, defend, and justify design choices quite coherently. This saved time I would otherwise have spent debating with coworkers. But it’s not always right and it is easily led astray (and will lead astray), so you need a clear idea in mind, a firm hand, and good judgment.

One annoying trope I keep seeing in Gemini output is the punchy invented concept name in a tripartite list:

- “The Pledge”:…

- “The Turn”:…

- “The Prestige”:…

(For this particular example I used real terms from the stage magic world, at least according to Christopher Nolan’s film, as it captures the same meaningless-to-the-uninitiated quality.)

Likewise! I often marvel at the patience of readers of earlier times. Of course, they had more time and fewer distractions, and I suspect that there was a dynamic at work in which both the writer and reader derived a certain satisfaction from long meandering sentences, the writer proving their skill, and the reader proving (to themselves) their stamina.

Nowadays we tend to write in a plainer style demanding a smaller “parser stack”. Some style manuals have excellent examples of sentences of equal length but very different “stack depth” and thus ease of comprehension.

Good question. We don't know the true figure, but we extrapolate the denominator from estimates of the total number of Go users and the fraction of Go users that run gopls.

Good point: I-cache is memory too. (Indeed it is SRAM, so its bits might be even more fragile than DRAM!)

"what is the role of humans in a scenario where work is no longer necessary?"

People have been fantasizing about this scenario throughout the industrial era--read William Morris' News from Nowhere (1890) for example--but it has failed to come to pass so many times, and the reasons are pretty obvious. The benefits of technology are spread unequally, and increasingly so over time, so only a wealthy few get the option of a post-labor existence. Also, our demands for the products of labor change as labor productivity increases; we prefer (or have been persuaded to act as if we prefer) material riches over lives with less stuff and more time.

We still haven't seen that AI actually replaces labor, as opposed to amplifying it, like a power saw or CNC mill used by a carpenter, so all these discussions about the end of labor seem like unwitting sales pitches for AI.

“what would be the role of humans in an AI-first society”

The real question is why would anyone want, or want to help build, such an obscenity.

It's true that in the very early days Google used cheap computers without ECC memory, and this explains the desire for checksums in older storage formats such as RecordIO and SSTable, but our production machines have used ECC RAM for a long time now.

Very interesting. The Go toolchain has an (off by default) telemetry system. For Go 1.23, I added the runtime.SetCrashOutput function and used it to gather field reports containing stack traces for crashes in any running goroutine. Since we enabled it over a year ago in gopls, our LSP server, we have discovered hundreds of bugs.

Even with only about 1 in 1000 users enabling telemetry, it has been an invaluable source of information about crashes. In most cases it is easy to reconstruct a test case that reproduces the problem, and the bug is fixed within an hour. We have fixed dozens of bugs this way. When the cause is not obvious, we "refine" the crash by adding if-statements and assertions so that after the next release we gain one additional bit of information from the stack trace about the state of execution.

However there was always a stubborn tail of field reports that couldn't be explained: corrupt stack pointers, corrupt g registers (the thread-local pointer to the current goroutine), or panics dereferencing a pointer that had just passed a nil check. All of these point to memory corruption.

In theory anything is possible if you abuse unsafe or have a data race, but I audited every use of unsafe in the executable and am convinced they are safe. Proving the absence of data races is harder, but nonetheless races usually exhibit some kind of locality in what variable gets clobbered, and that wasn't the case here.

In some cases we have even seen crashes in non-memory instructions (e.g. MOV ZR, R1), which implicates misexecution: a fault in the CPU (or a bug in the telemetry bookkeeping, I suppose).

As a programmer I've been burned too many times by prematurely blaming the compiler or runtime for mistakes in one's own code, so it took a long time to gain the confidence to suspect the foundations in this case. But I recently did some napkin math (see https://github.com/golang/go/issues/71425#issuecomment-39685...) and came to the conclusion that the surprising number of inexplicable field reports--about 10/week among our users--is well within the realm of faulty hardware, especially since our users are overwhelmingly using laptops, which don't have parity memory.

I would love to get definitive confirmation though. I wonder what test the Firefox team runs on memory in their crash reporting software.

Not sure why you were downvoted. I love the breathless enthusiasm of the article, but I still have no idea why (or if) this is important. What did you learn from Opus?

...you would have the same balance as before, because this is not an article about implicit boxing. ;-)