Out of curiosity, how much of the 138K LUTs (as well as other resources like BRAM) are in use here? I wonder if there's much room to add fancy peripherals, or perhaps "growing" the CPU to achieve better IPC.

It currently uses 44% of the LUTs and 59% of the BRAMs (out of 340 × 2 KB blocks). The chip itself is fairly large and inexpensive, though performance leans toward the lower side.

But that just raises more questions; why would Cognition be better positioned for B2B? Wouldn't Cursor have an advantage as they already have a foothold in the B2C market? Expanding from there seems a lot easier than coming for B2B directly: Cursor already has mindshare among developers.

The B2B dominance of Microsoft Office can, after all, not exist without B2C Microsoft Office.

> why would Cognition be better positioned for B2B?

They bought windsurf and they had b2b customers already?

That being said, they're also the "devin" people, so I'd probably avoid them, like I avoid anything langchain related.

What’s the best “agentic framework” options these days, besides langchain? (Other than “build your own” - In particular something that gives me observability/evals out of the box)

Is 86box period-accurate for Windows XP? It seems to go up to Socket 370 (Pentium III) which is very early for XP. Additionally, from my experience using PCem (which 86box is based on), you need pretty beefy hardware to emulate a Pentium II or K6, let alone to go beyond them. And those are period-accurate for Windows 98, not XP.

I would say "kei" does pretty specifically refer to vehicles adhering to those Japanese regulations. I think "minitruck" or "compact truck" would be a better, more general name.

I guess modern crash safety does require decent crumple zones, but I'm not sure in how far Europe is different than North America in this.

If anything, small vehicles aren't a thing in NA, but extremely popular still in Europe, even though SUVification is also happening here.

There's plenty of small cars left, like the Toyota Aygo X. Renault is also working on a new electric Twingo, and the new 5 isn't huge either.

I don't think you understood what a "copilot" and a "HUD" is. Confusingly, GitHub Copilot (the original one that suggests completions) is basically a HUD. On the other hand, agents that you give a task are clearly copilots that work via a natural language interface.

The article also mentions that agents are copilots:

> Here’s another personal example from AI coding. Let’s say you want to fix a bug. The obvious “copilot” way is to open an agent chat and ask it to do the fix.

Calling GC time "additional overhead" is not entirely correct, imo. Non-GC languages often spend plenty of time dealing with malloc/free, and I consider both GC and malloc/free to be "memory management". Both are non-trivial!

GC usually also comes in "copying" variants, which can have advantages like reducing memory fragmentation.

Granted, malloc/free isn't totally free. But malloc/free languages always seem to be faster than Java in benchmarks, at least the ones I've read and referenced already in the comments around this article. GC also, even if it were faster, comes at the expense of eating RAM like mad, at least if judged by the RAM Java likes to eat. Usually, Java software just consumes 50% of your RAM until the first GC pause. And even before that GC pause, it's dog slow.

Memory fragmentation can more easily be reduced by pooled allocators. For long-running server processes, it can also be possible to just kill the worker processes/threads from time to time. And I've never seen memory fragmentation in manually allocated languages lead to more memory consumption or worse performance than in Java.

I feel like a massive counterexample here is embedded. Hardware companies tend to laugh at maintenance (it's expensive and extends the life of their products, so you don't have to give them money as often). If Linux was not GPL, many embedded platforms like routers or smartphones would not have kernel code available.

That's a good counterexample! If you don't need to maintain the code, then a proprietary fork has no maintenance cost and will be preferred.

I guess, the atricle still stands where you need to maintain the code.

I disagree, because there is no 'easy' way to know what the most 'significant' changes are. I can think of a few heuristics (e.g. most changed, earliest changed, as well as prioritizing things like header files for C and friends), but nothing that would work universally or particularly well.

Yeah I prefer the review UI to give me alphabetical order just so I can easily navigate it, but I won't read it in that order.

I think the google review tool (critique) would sort C/C++ header files before implementation, even though ".h" comes after ".cc". That's a nice convenience but it's still easy to navigate.

Wouldn't it be feasible to add a tiny battery or capacitor? Assuming the radio doesn't need to transmit continuously it can be powered via those which are then powered by the "forever battery".