No. Given a choice between doing laundry and driving Lamborghinis, I would probably choose the latter. But I still have to do my laundry. I might use a washing machine to do so. It's just a responsibility among many responsibilities. It isn't that deep, really.

The reality few people want to admit is that maintaining open-source software is often closer for many people to "doing laundry" than like, being the software equivalent of Atticus Finch.

> Or did Claude just gave some basically retired programmer, who doesn't even want to work on his project anymore,

The only thing Claude has "done" apparently is give a bunch of annoying people online a license to engage in armchair psychoanalysis of someone they don't know at all, from what I can tell.

Now you can simply write a script that uses the tailscale API to find all "metrics-service-*" nodes in your tailnet, and then adds their IP/DNS to your prometheus scraping list. Run it every 60 seconds. Done, now you can just deploy your app anywhere on any cloud and it will get scraped and that route will never be exposed to the outer internet.

This will basically just let you attach bespoke applications and not just "computers" to your network. I suspect I will get a lot of use from it.

So just run:

    jj bookmark track myname/somecoolfeature --remote origin

Some people configure the set of immutable heads to be the empty set so they can go wild.

There's some legal annoyances around e.g. CLA which was a result of being a side project of Google originally. Hopefully we'll move through that in due time. But realistically it's a much larger project at this point and has grown up a lot, it's not Martin's side project anymore.

I was just trying to explain why people are so upset by the perceived change of hands; that perception isn't perfect of course, it's a mixture of fear, honesty, skepticism, truth etc. I think some people here are just being absurd (e.g. the idea that community projects are magically more sustainable by the fact they are community projects is literally just wishcasting with a mix of Red-Dots-On-Plane syndrome). But I can definitely understand the source of it.

So that's all it really comes down to; uv isn't loved just because it's great but because it is in good hands. This real/perceived change of hands pretty much explains all the downstream responses to the news that you see in this thread. Regardless of who bought them, any fork is going to have very, very big shoes to fill, and filling those shoes appropriately is the big worry.

Honestly, Apple is the strange one because they never discuss CPUs until they are available to buy in a product; they don't need to bother.

To do this lookup in the first place, you pull a number of bits from the virtual/physical address you're looking up, which tells you what bucket to start at. The minimum page size determines how many bits you can use from these addresses to refer to unique buckets. If you don't have a lot of bits, then you can't count very high (6 bits = 2^6 = 64 buckets) -- so to increase the size of the cache, you need to instead increase the associativity, which makes latency worse. For L1 cache, you basically never want to make latency worse, so you are practically capped here.

Platforms like Apple Silicon instead set the minimum page size to 16k, so you get more bits to count buckets (8 bits = 256 buckets). Thus you can increase the size of the cache while keeping associativity low; L1 cache on Apple Silicon is something crazy like 192kb, and L2 (for the same reasons) is +16MB. x86 machines and software, for legacy reasons, are very much tied to 4k page size, which puts something of a practical limit on the size of their downstream caches.

Look up "Virtually Indexed, Physically Tagged" (VIPT) caches for more info if you want it.

Of course, Google is still in the wrong here for instantly nuking the account instead of just billing them for API usage instead (largely because an autoban or whatever easier, I'm sure).

You can make a pretty reasonably secure Linux server by doing your homework, it's nowhere close to impossible. An extremely secure server also requires a bit of hardware homework. The Linux desktop, however, is woefully behind macOS and Windows in terms of security by a pretty large margin, and most of it is by design.

(In theory you can probably bolt a macOS-like system onto Linux using tools like SCM_RIGHTS/pidfds/code signatures, along with delegated privilege escalation, no setuid, signature-based policy mechanisms, etc. But there are a lot of cultural and software challenges to overcome to make it all widely usable.)

I'm asking it to do some analysis/explain some Rust code in a rather large open source project and it's working nicely. I agree this is a model I could possibly, maybe use locally...

[1] http://granule-project.github.io/granule.html