EnPissant

There are multiple factors at play:

- Among those who believe in intellectual differences among human groups, very few believe Europeans are the most intelligent group. The prevailing opinion you would find is that both Ashkenazi Jews and East Asians (your second example) are more intelligent on average.

- Northwest Europeans encountered intense selection over a Millennia starting around 300AD through a couple of mechanisms: The Church banning cousin marriage, and Biparte Manorialism. This resulted in the destruction of kinship networks, established the nuclear family, and selected for the high-trust peoples that enabled a kind of society you can still only find among those peoples.

> He characterized Stanford and MIT as “mainly political lobbying operations fighting American innovation at this point” and vowed that universities would “pay the price” after “they declared war on 70% of the country.”

Oh? He vowed what? To make them pay the price? Or did he just predict a cause and effect and The Nation (your source) is libeling him?

git sparse-checkout

If you really wanted, you could implement this on top of a snapshot based system by mixing in git blame information (or an algorithm that is similar). It's not hard to compute that text based dependency graph on the fly, though maybe expensive without caching.

> 1. Dependencies. While Darcs patches would inherently "depend" on the last patch which affected the same lines, the committer could specify other patches as dependencies, handling exactly the case you described.

I don't know who would want to put in the work of mapping out the semantic dependency graph because maybe some day someone might want to compose a slightly different set of patches. And even if everyone tried, it would surely still fail because that's so hard or impossible.

> There's a big difference between "conflicts shouldn't come back as long as everyone does what I want" and "conflicts don't come back". As long as you're using Git with other people, the rebase-lovers and their problems will be a perpetual issue. I've been on 3 teams in a row with this problem.

Just stop using rebase is much easier to socialize than let's all move to Pijul. It's also the correct thing to do.

> the benefit of snapshot VCS is that you don't just have the change, but you have the whole context in which the change happened.

I strongly agree with this and think it's the only tractable way to operate.

I think patching/cherry-picking is just inherently complicated and needs intelligence applied. I don't think Pijul is going to be any better here.

From their home page:

> Why?

> Commutation

> In Pijul, independent changes can be applied in any order without changing the result or the version's identifier. This makes Pijul significantly simpler than workflows using git rebase or hg transplant. Pijul has a branch-like feature called "channels", but these are not as important as in other systems. For example, so-called feature branches are often just changes in Pijul. Keeping your history clean is the default.

This is a useless property because the graph is only encoded at the patch layer. In the real world you have far more semantic dependencies than patch dependencies. ie, I have a patch that adds a function that calls a function added in another patch. Pijul doesn't know about that.

> Merge correctness

> Pijul guarantees a number of strong properties on merges. The most important one is that the order between lines is always preserved. This is unlike 3-way merge, which may sometimes shuffle lines around. When the order is unknown (for example in the case of concurrent edits), this is a conflict, which contrasts with systems with "automatic" or "no conflicts" merges.

I can't remember being bitten by this, and you don't need Pijul to solve this. A merge algorithm that leverages `git blame` information would work just as well. It's just nobody cares enough to use such a thing.

> First-class conflicts

> In Pijul, conflicts are not modelled as a "failure to merge", but rather as the standard case. Specifically, conflicts happen between two changes, and are solved by one change. The resolution change solves the conflict between the same two changes, no matter if other changes have been made concurrently. Once solved, conflicts never come back.

Conflicts coming back is not an issue in git. For some reason people think they need to use rebase when they should almost always be using merge.

> Partial clones

> Commutation makes it possible to clone only a small subset of a repository: indeed, one can only apply the changes related to that subset. Working on a partial clone produces changes that can readily be sent to the large repository.

Git and other snapshot-based SCMs do this far far better. Git can checkout only a set of files or directories, and the tree-structure encoded in git objects in its db makes this very efficient. You could even build a fuse layer to lazily fetch content. With Pijul you would have to extremely carefully maintain your history to allow this. ie, when you have a patch that modifies 2 other patches, then those are merged forever if you need the changes in the merger. Imagine a PR that reformatted all files in the repo or changes a top level interface and fixed all users in the same PR. Whoops, everything is now interdependent, no more partial clones.

You are a Star Wars Rebel fighting Darth Vader. Good job!

> Alright, good luck to you. I'm not really interested in talking to people who think they're lawyers for AI providers.

Codex is open source, you can inspect it yourself, but let's not let facts ruin your David vs Goliath fantasy.

No. Your data or any derivative of it does not leave RAM unless you are detected as doing something that qualifies as abuse, then it is retained for 30 days.

Yes. That's the rational position.

Codex just talks to the responses API with store=false. So unless the model detects you are doing something that qualifies as abuse, nothing is retained.

Not true.

https://developers.openai.com/api/docs/guides/your-data

Do you use macOS? That's exactly how I feel on macOS because it is so so bad at this.

Dual 4k 27" monitors on Linux with KDE Plasma near perfect.

Mate itself has not had a release since February of 2024. Sad to say, I think it's probably mostly dead. IMO, Mate held the crown for most usable Linux desktop during most of its existence, but development has slowed down to the point it is missing important features like fractional scaling. The good news is now KDE Plasma has gotten good enough that you can configure it to have the Mate layout and it is nearly strictly superior. If anyone is looking for an alternative, I would encourage you to try it.

> 4. persisting context across compactions

> LLMs forget things as their context grows. When a conversation gets long, the context window fills up, and Claude Code starts compacting older messages. To prevent the agent from forgetting the skill’s instructions during a long thread, Claude Code registers the invoked skill in a dedicated session state.

> When the conversation history undergoes compaction, Claude Code references this registry and explicitly re-injects the skill’s instructions: you never lose the skill guardrails to context bloat.

If true, this means that over time a session can grow to contain all or most skills, negating the benefit of progressive disclosure. I would expect it would be better to let compaction do its thing with the possibility of an agent re-fetching a skill if needed.

I don't trust the article though. It looks like someone just pointed a LLM at the codebase and asked it to write an article.

It's very workload dependent. It certainly does more than 2% on many workloads.

See https://www.phoronix.com/review/amd-ryzen-9-9950x3d-linux/10

> Here is the side-by-side of the Ryzen 9 9950X vs. 9950X3D for showing the areas where 3D V-Cache really is helpful:

Coincidentally, it looks they filtered to all benchmarks with differences greater than 2%. The biggest speedup is 58.1%, and that's just 3d vcache on half the chip.

That assumes you have significant work to do between fetches (so you can prefetch while using the current data). With LLM decode you don't.

You do not provide any comparison to llama.cpp with mmap.

You do not explain how any kind of predictor can work for MoE experts.

You do not explain how prediction can even be useful. I can predict the layers used in a dense model (all of them are used in order), but that doesn't help me much. It's still bottlenecked on bandwidth (hint: MoE doesn't change this).

That's the same reason I don't like Opencode, but Codex doesn't use the alternate screen. I remember it did when it was very very new, but now it doesn't.

Forget the 80s-90s - Even California passed prop 8 in 2008.

I really like KDE plasma, it's the best DE out there once configured to mimick Gnome 2 / Mate, but I agree with you on screenshots! Also, Konsole required much configuration to be not way too busy.

Other than that I don't have too many complaints.

He also went on to say that Lionel Messi asked him for tips on corner kicks.

Unlike offloading weights from VRAM to system RAM, I just can't see a situation where you would want to offload to an SSD. The difference is just too large, and any model so large you can't run it in system RAM, is going to be so large it is probably unusable except in VRAM.

Europe used to be a lot like other places a millennia ago (I typo'd century above): low-trust, dominated by extended kinship networks, different marriage patterns, etc. The transformation largely happened between the years 300-1500, before colonialism existed. The Church was responsible for much of this transformation. I guess you think Europe just robbed the world and suddenly they had liberal democracies?

The ability to stream weights from disk has nothing to do with MoE or not. You can always do this. It will be unusable either way.

I have a Macbook pro and a Linux machine attached to my dual 4k monitors.

Fonts on Linux (KDE Plasma on Wayland) look noticeably sharper than the Mac. I don't use subpixel rendering either. I hate that I have to use the Mac for work.

More like a century of no cousin marriage / late marriage / nuclear families via bipartite manorialism has produced a high trust people. Everything you attribute to magic dirt or oppression is really this.

>> most people in the world don’t and have never lived like Europeans

> Yeah, but, as it turns out with modern migration trends, the revealed preference is that they would want to, given an opportunity. Being European, I would also prefer to live like a European.

The revealed preference is that they want to continue to live the same way, but to do it in European countries as they are nicer places to live.

The problem is that they are nicer places to live because "living like a European" is what produces these nicer places to live.

True. You can self-host.