smallnamespace

No, but Google already has internal tools that can identify use sites and email affected teams.

Note that teams generally manage their own deployments, so even a repo wide code change doesn’t force the update of an older deployed binary.

> the compiler will flag all pattern matches that you need to update

At Google, the bottleneck is that a team changing a commonly used enum will not know how to update all the broken use sites, since it can be affecting dozens or hundreds of teams.

It is better to decouple the enum change from the use site change and let consuming teams update on their own schedule.

Everything that you say can be true, and yet Asahi project may want to avoid needing to prove what you say in a courtroom.

> attempt to reduce wealth inequality is a sign itself that it's a very wealthy country

Poor countries also reduce wealth inequality. In fact, China went through a Communist revolution where all private landowners’ wealth was taken from them. This happened from the 1930s through the 1950s and was a fairly bloody, violent process, involving lots of revolutionaries inciting peasants to forcibly occupy land and buildings and killing landlords if they didn’t cooperate.

> The problem with the filesystem could have been solved by optimizing the Windows kernel

Over time this would tie the Windows kernel’s requirements so that they matched the Linux kernel’s due to expectations from WSL1 users. This of course is a bad idea for any engineering organization - you will have requirements imposed on you that don’t mesh well with your other non-WSL users and you also have no real sway over Linux governance. This would lead to the Windows kernel either becoming a clone of Linux or serving at least one set of users poorly.

AI revenue has been going up while the cost per token has been rapidly falling. The Jevons paradox applies here. The cheaper software is, the more software is written. There is not a finite demand for software.

It’s not useless, because you can, for example, ask multiple frontier models to do the formalization and see if they agree. And if they have surface-level differences in formalization, you can also ask them whether apparently-different definitions are equivalent.

This isn’t perfect of course - perhaps every single model is wrong. But you are too quick to declare that something isn’t useful for arriving at an answer. Reducing the surface area of what needs to be checked is good regardless.

Yes, and the child comment’s point is that formalizing the problem is likely easier than having the LLM verify that each step of a long deduction is correct, which is why Lean might be helpful.

T-bills are highly liquid. You can sell them before they mature for very low transaction cost and get back their true market value, including the accrued interest, meaning there’s not much monetary benefit to staggering them week by week. You could just as well only roll them once a month and dip in freely if you need the cash.

It’s architecturally not a good approach. System RAM is much slower so you should put data that doesn’t need to be used often on it. That knowledge is at the application layer. Adding a CUDA shim makes system RAM appear like VRAM, which gets things to run, but it will never run very well.

The benchmarks at the bottom mention memory tiering and manually controlling where things go, but if your application already does that, then you probably don’t also need a CUDA shim. The application should control the VRAM to system memory transfers with boring normal code.

The market cap is unambiguous, a more correct estimate of "how much to buy all the shares?" is situational and would just distract from getting the point across.

> According to the researchers, an unpatched Windows PC connected to the Internet will last for only about 20 minutes before it's compromised by malware, on average. That figure is down from around 40 minutes, the group's estimate in 2003.

This was from two decades ago, and cursory searching suggests the average lifetime of an unpatched system is even lower now.

https://www.cnet.com/news/privacy/study-unpatched-pcs-compro...

Three facts to consider:

1. CLAUDE.md is not part of the system prompt

2. The Claude Code system prompt almost certainly gives directions about how to deal with MCP tools, and may also include the list of tools

3. Instruction adherence is higher when the instructions are placed in the system prompt

If you put these three facts together then it’s quite likely that Claude Code usage of a particular tool (in the generic sense) is higher as an MCP server than as a CLI command.

But why let this be a limitation? Make an MCP server that calls your bash commands. Claude Code will happily vibe code this for you, if you don’t switch to a coding tool that gives better direct control of your system prompt.

I didn't think of it ;)

Now that you bring it up, the M3 ultra Mac Studio goes up to 512GB for about a $10k config with around 850 GB/s bandwidth, for those who "need" a near frontier large model. I think 4x the RAM is not quite worth more than doubling the price, especially if MoE support gets better, but it's interesting that you can get a Deepseek R1 quant running on prosumer hardware.

An 14-inch M4 Max Macbook Pro with 128GB of RAM has a list price of $4700 or so and twice the memory bandwidth.

For inference decode the bandwidth is the main limitation so if running LLMs is your use case you should probably get a Mac instead.

The platter is a circle so using the uniform distribution [0, 1] is incorrect, you should use the unit circular distribution of [0, 2pi] and also since the platter also spins in a single direction the distance is only computed going one way around (if target is right before current, it's one full spin).

But you can simplify this problem down and ask: with no loss of generality, if your starting point is always 0 degrees, how many degrees clockwise is a random point on average, if the target is uniformly distributed?

Since 0-180 has the same arc length as 180-360 then the average distance is 180 degrees. So average half-platter seek is half of the full-platter seek.

> If you're copying and pasting something, there probably isn't a good reason for that.

I would embrace copying and pasting for functionality that I want to be identical in two places right now, but I’m not sure ought to be identical in the future.

If you're going to be using USB drives anyway, then using them to move files into the country would be faster.

Typescript ecosystem calls these "branded types" (branded like cattle, presumably) which I found to be a good evocative name.

It's unjust in the same sense that some people complain about capitalism being unjust: some people are wealthy who didn't cosmically deserve it, but just got lucky. There is disagreement over in which way they were lucky (random luck, or lucky to have the right parents, education, genes, etc.)

> Being in contact with reality can be actively harmful to reproductive fitness if it leads you to, say, decide not to have kids because you are pessimistic about the future.

The fact that you can write this sentence, consider it to be true, and yet still hold in your head the idea that the future might be bad but it's still important to have children suggests that "contact with reality" is not a curse.

If you can define your problem well then you can write tests up front. An ML person would call tests a "verifier". Verifiers let you pump compute into finding solutions.

> by the time I write an exact detailed step-by-step prompt for them, I could have written the code by hand

The improved prompt or project documentation guides every future line of code written, whether by a human or an AI. It pays dividends for any long term project.

> Like there is a reason we are not using fuzzy human language in math/coding

Math proofs are mostly in English.

Vibe code an eval harness with a web dashboard

Those other models lack native mechanical sympathy with the hardware.

Let's be practical about it: the reason you might want to say map_tree is so it could potentially be optimized to run more quickly, e.g. via automatic parallelization.

But to even parallelize a tree read operation we'd have to pull in other threads, split work, we'd want metadata on each node (child counts), and at the end of the day within each worker you'd still have a serial execution order.

For map_tree to have practical benefit your language would need to make a ton of opinionated choices about trees and parallel programming. Feasible? Yes. Worth making it a basic primitive? Well, even LISPs don't offer map_tree, despite building the whole language on top of car/cdr.

Because your code is actual running serially so no matter what there is an iteration order, and the order matters for performance even if your code does not care.

For example if you literally don’t care about the order then your code can map over a default iterator that is efficient (DFS).

All the AI tools end up converging on a similar workflow: type what you want and interrupt if you're not getting what you want.

Advances in AI are bringing down the cost of processing audio by perhaps 5x a year, and has been doing so for several years now.

The risk is that it becomes worthwhile for someone to record everything now and process it later at their own leisure.

People go to Tokyo and Osaka because that's where it's easier to find good-paying jobs.

> I don't think anyone today would seriously argue that Hanja is preferable

It's necessary to use Hanja today in educated contexts because Hangul has too many homophones, and most educated (technical, literary, scientific) vocabulary has a Sinitic origin and therefore are more homophonic than typical Korean words.