aseipp

This paper is great and I also really like one of its references [29] as it goes into some more subtle parts of scalable interfaces, including fork. It's a gem IMO: The Scalable Commutativity Rule: Designing Scalable Software for Multicore Processors https://people.csail.mit.edu/nickolai/papers/clements-sc.pdf

> That's my impression from that sentence, at least. Don't you agree?

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.

The GB10 itself is pretty good and I love using mine for broad Linux development. But it's too expensive for consumer level pricing, and even for the "prosumer" the price is pretty stiff. Even if they dropped the CX-7 and halfed the RAM and shipped a smaller hard drive, would it be below, say, $2500 USD? I guess we'll see, but this variant is coming out pretty late so maybe it's just best to wait for the 2nd generation.

Imagine something like writing a server with an /metrics HTTP endpoint that Prometheus can then scrape -- but you bind it on separate port only inside a tailnet, with an ephemeral tailnet key and name it "metrics-service-blahblah".

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.

Yes, almost all JJ users do this constantly. Just "track" the particular branch. JJ has an idea that only some commits are immutable, the set of "immutable heads", and the default logic is something like "The main branch is always immutable, remote branches are immutable, 'tracked' remote branches are mutable." In other words, tracking a remote branch removes it from the set of immutable heads.

So just run:

    jj bookmark track myname/somecoolfeature --remote origin

and the default settings will Do What You Want. This is intended as a kind of safeguard so that you do not accidentally update someone else's work.

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

Jujutsu is not "VC funded". But some of the developers, including me, work at East River Source Control (I worked on Jujutsu before that, too). The majority of the code in the project doesn't come from us -- or Google, for that matter. We don't allow people to approve patches when the author is from the same company, anyway.

jj is not "one guy who works at Google" and the vast majority of submitted code comes from non-Google developers. Even if Google were to stop developing jj (they won't) the project would be healthy and strong.

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.

Just to be clear: I think uv and the other Astral projects will probably be just fine! I don't really think this the end at all.

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.

Part of the reason Astral as a team is so well liked is precisely because they are not part of the main fold or related to "Core Python"; they are an independent vendor, one that delivered high quality code and listened directly to users and their own (extensive) experience to do so, and they succeeded at that repeatedly. Python packaging has {been seen as, actually been} miserable for years, and so by the same token the capacity to believe in/buy into solutions from the "core project" has dwindled. "If it took Astral to fix it, why would it be any different going forward?"

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.

Not quite, just the pixel/vertex shaders and the algorithm is public domain. Slug "the software package" is not open source (you can get a copy of it along with C4 Engine for $100 to take a peek if you want, though).

Yeah, I was more just trying to paint a broad picture. Nvidia in particular I think had fast and large-ish L1 on Tegra (X2?) despite being tied to 4k pages.

I feel like that was much more true in the past but the X925 was only spec'd 18 months ago(?) and you can buy it today (I'm using one since October). Intel and AMD also give lots of advance notice on new designs well ahead of anything you can buy. ARM is also moving towards providing completely integrated solutions, so customers like Samsung don't have to take only CPU core and fill in the blanks themselves. They'll probably only get better at shipping complete solutions faster.

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.

When you do a cache lookup, there is a "tag" which you use as an index during lookup. But once you do the lookup, you may need to walk a few entries in the corresponding "bucket" (identified by that tag) to find the matching cache line. The number of entries you walk is the associativity of the cache e.g. 8-way or 12-way associativity means there are 8 or 12 entries in that bucket. The larger the associativity, the larger the cache, but also it worsens latency, as you have to walk through the bucket. These are the two points you can trade off: do you want more total buckets, or do you want each bucket to have more entries?

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.

"PAYGO API access" vs "Monthly Tool Subscription" is just a matter of different unit economics; there's nothing particularly unusual or strange about the idea on its own, specific claims against Google notwithstanding.

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).

Knights Landing is a major outlier; the cores there were extremely small and had very few resources dedicated to them (e.g. 2-wide decode) relative to the vector units, so of course that will dominate. You aren't going to see 40% of the die dedicated to vector register files on anything looking like a modern, wide core. The entire vector unit (with SRAM) will be in the ballpark of like, cumulative L1/L2; a 512-bit register is only a single 64 byte cache line, after all.

FWIW I think the LLVM bitcode format has stronger compatibility guarantees than the text IR. But I agree it's a bit of a pain either way; plus, if you forgo linking to the library and just rely on whatever 'llc' the user has installed, figuring out bugs is not a fun time...

No, Windows has consistently been ahead of Linux for many years in terms of average-user desktop security, from binary hardening to designs like secure desktop, because average Windows users do not typically have curated software selections, so you assume the worst. (When I wrote the original "binary hardening via compiler flags" RFC for NixOS over 10 years ago, almost everything in it was already done on Windows and had been for years.) It's still not ideal; macOS takes it even further and actually allows things like "storing secrets on disk in a way that can't be read by random programs" because it can e.g. make policy decisions based on code signatures, which are widely deployed. None of this exists in pretty much any Linux distro; you can literally just impersonate password prompts, simply override 'sudo' in a user's shell to capture their password silently, copy every file in $HOME/.config to your evil server, setuid by its very definition is an absolute atrocity, etc. Linux distros make it easy for people to live in their own chosen curated software set, but the security calculus changes when people want to run arbitrary and non-curated software.

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.)

llama.cpp is giving me ~35tok/sec with the unsloth quants (UD-Q4_K_XL, elsewhere in this thread) on my Spark. FWIW my understanding and experience is that llama.cpp seems to give slight better performance for "single user" workloads, but I'm not sure why.

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...

There are ongoing projects like Granule[1] that are exploring more precise resource usage to be captured in types, in this case by way of graded modalities. There is of course still a tension in exposing too much of the implementation details via intensional types. But it's definitely an ongoing avenue of research.

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

Mesa already has initial support for Adreno 8xx[1] and the DRM side was already merged into the kernel back in November.[2]

[1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38... [2] https://github.com/torvalds/linux/commit/01ff3bf272156615d6c...

No AVX512, client SKUs are just going to go straight to APX/AVX10, and they are confirmed for Nova Lake which is 2H 2026 (it will probably be "Core Ultra Series 4" or whatever I guess).

There was a good tweet after election day where someone wrote that a Chinese classmate was talking about their religious father in Beijing, who thought that Trump was chosen by God to win the election -- but only as part of a larger divine plan to destroy America. Pretty funny, to be honest.

MikroTik is one of the few public organizations who can still get chips from Annapurna Labs after their acquisition by AWS, it seems. Many of their offerings are still using Annapurna parts, and Annapurna still appears as a distinct brand in AWS marketing for its custom silicon, even. I wonder what the specifics of that relationship are.

(Side note but the original Graviton1 was just 16x Cortex-A72 cores, nothing particularly special about it. Actually, all of the Graviton series are just standard ARM cores. But beyond that the SKU they use is indeed the same one AWS uses.)

War in the Pocket is also pretty good, if you haven't seen it. A bit dated now but I always thought of it as a "Business as usual" war story when I was young.

It's probably just for IP and talent acquisition, if I had to guess. People who can design high performance server-class CPU microarchitectures are rare.

Frankly, Ventana seemed like an interesting entry in the space, but I have no idea who would have actually bought their servers at the end of the day. They taped out multiple designs, but none actually seem to exist outside their labs. I don't really see any path to meaningful RISC-V server adoption for at least several more years and by that time Qualcomm could design something on their own, assuming they are serious about re-entering the market. Grabbing the talent and any useful IP/core design components makes the most sense to me, anyway.

I think the biggest benefits of colocation are, in rough approximation of the order I encounter them:

1) Various read-only editor features, like diff gutters, work as they usually do. Our editor support still just isn't there yet, I'm afraid.

2) Various automation that tends to rely on things like running `git` -- again, often read-only -- still work. That means you don't have to go and do a bunch of bullshit or write a patch your coworker has to review in order to make your ./run-all-tests.sh scripts work locally, or whatever.

3) Sometimes you can do some kind of nice things like run `git fetch $SOME_URL` and then `git checkout FETCH_HEAD` and it works and jj handles it fine. But I find this rare; I sometimes use this to checkout GitHub PRs locally though. This could be replaced 99% for me by having a `jj github` command or something.

The last one is very marginal, admittedly. Claude I haven't had a problem with; it tends to use jj quite easily with a little instruction.

To be technical, it's more that it can read and write the on-disk Git format directly, like many other tools can.

I think the easiest way to conceptualize it is to think of Git and jj as being broken down into three broad "layers": data storage, algorithms, user interface. Jujutsu uses the same data storage format as Git -- but each of them have their own algorithms and user interface built atop that storage.

The Macbook M2 Air running Asahi Linux is easily my favorite Linux laptop ever, far superior to any Thinkpad or Dell XPS I've owned, imo. I think things like Thunderbolt and some DisplayPort features are missing, but I have never needed this as it is purely a laptop for me. But it has everything else I could want: suspend/sleep, proper frequency scaling, great GPU drivers, USB/wifi/bluetooth, speakers, brightness/keyboard settings, etc. The webcam works I think but I haven't tried it. The battery life is great, though macOS is still quite a ways ahead in that department.

The CIX CP8180 uses UEFI (it is intended to boot Windows which requires it) but the boot flow can, I believe, use either ACPI or device trees, based on a boot setting. The ACPI boot flow has the advantage that any normal Linux distro should work, while the device tree variant I think has more hardware enablement.

The upstream story due to this is kind of a mixed bag, though. I think they also still use out-of-tree NPU drivers, etc. Device trees and other updates are still flowing upstream. I think the next Mesa release will support the Immortalis GPU series though, so that'll hopefully polish off a big remaining problem with ordinary distros.

Oryon v3 is designed for actual PC usage, not phones. But they aren't shipping until H1 next year. This is just a heads-up memo about Linux support, in that regard. Which is nice, I guess?