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.
[1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38... [2] https://github.com/torvalds/linux/commit/01ff3bf272156615d6c...
reply