aseipp

You could also make the alternative argument: the internet as a truly decentralized network as imagined by nerds was never going to actually work due to its (now obvious) impact on the political economy of the world and its actors, and because fundamentally centralized economies of scale are how humans tend to organize society. So why are internet nerds on forums so narrow minded that they don't read understand this, because they don't read books? But both of these "arguments" are pointless posts designed to get head-pats, because everyone has made up their mind. Buy your DV certs from another ACME provider.

Oh, that's a good point I forgot about; I suppose DT interfaces aren't considered part of the stability contract for users... Really Device Tree is somewhat "Linux-specific"-enough and low level enough that issues like this aren't ideal. But if we could just get to the point that was a problem, I'd be happier than now, I suspect!

Someone from Qualcomm posted a "DT-ACPI Hybrid Mode" set of patches a while back that let you call ACPI table functions, etc even while booting with the device tree, allowing you to control some things like keyboard lightning/power management independently. That would be a good first step but I'm not sure it went anywhere in the meantime. In theory supporting Device Tree by including the blob in a ROM somewhere shouldn't be much more work (if any) than including working ACPI tables, but we all know how that works out in practice!

> only seems stable, but internally it changes

That's literally the definition of it being stable. Programs written against an interface keep working despite the implementation changing. The Linux kernel also constantly changes internally but programs written against syscalls keep working, so it is stable; that fact doesn't stop being a fact just because I dislike perf_event_open(2) or whatever. This is all very basic and easy to understand.

Because Martin was the lead maintainer and original author and worked at Google for over a decade until like a month ago, and so as a project it fell under their typical standards in the Google OSPO department and had a CLA applied. When it moved orgs, they had to own the org too, so they could keep CLA robot in. That's basically it. It's just a really successful project that has grown far beyond one company or person.

In theory there is now nothing stopping us (the community/project leaders) from just... Moving the repo somewhere else. We could do that. It would be a pretty sudden alienation of other Google contributors though and probably piss off their legal department -- 99% of them just submit regular fixes like any user, because they are ordinary users of JJ. They just happen to work at Google. It would just be stirring up shit for nothing. It isn't an unthinkable outcome, but it isn't one we're just going to "do" for no reason or because it would make people posting on forums happier.

Realistically a non-ownership-assigning CLA on a non-copyleft Apache 2.0 project like in this case doesn't actually mean anything or confer any power. It's all just paperwork that serves as a legal ass covering mechanism because big companies use lawyers. It's like checking the "Yes I am over 18 years old" box on a website. I say this as someone who hates the stupid CLA bot and am a contributor.

As far as actual leadership goes Google does not "own" anything in that regard, nor the day to day work, nor can it really force any of the community to do anything. There's 1 maintainer from Google out of 9 total and +95% of major contributions don't come from Googlers, ERSC, or even any particular company. They don't contribute most of the code, they don't lead most of the community, they are vastly dwarfed by the community in total size, contribution count, etc. What "ownership" or leverage do they have beyond a Github org in this setup? It's annoying but it isn't the same thing as being able to exercise meaningful levers of power, in my experience, and so most of us are just fine with it. Even if there was some stupid bullshit like a disagreement over implied trademark rights, the community could just rename and move on and Google would have nothing. That is where the real power lies.

Jujutsu also started out very small, just like Git did. The core concepts aren't too complex. But this is 2026, not 2005 or 2019. Most of the modern Git implementations are extremely large, highly optimized and featureful codebases that are difficult to replicate. Many of Git's performance and structural improvements over the last few years have nontrivial implementations and designs. Jujutsu is also a large, featureful codebase. You can't build a modern Git implementation with all of the highly optimized goodies (multipack indicies, partial clones, etc) and a good UX without a lot of code and work. Or any version control system, frankly. It's just how it is.

- Gitoxide is 80,000+ lines of code.

- Git itself is over 170,000 lines of code.

- Even "Game of Trees" or "got" by the OpenBSD developers, which is a wholly separate project that has its own porcelain, is +120,000 LOC.

- Jujutsu itself is about 100,000 LOC.

- JGit for Java is around 200,000 LOC.

These are all roughly approximate and include things like testing code (but I think that's fair because tests are part of the project). All of these projects started small years ago, and are now large.

> If jj is not too complex to have multiple implementations, why have new implementations not sprung up by now?

"Make multiple implementations" is not, in and of itself, particularly valuable without some underlying justification to do so. It also is not how (AFAIK) any other version control system has ever worked; Git's "identity" as an on disk format is a particular design choice (with pros and cons), so yes you can get multiple tools with varying levels of features that agree on the basic disk format and poke at it. But most projects just don't work this way, much less other VCSs; there also aren't really many "Linux re-implementations" beyond toys because it is easier to just collectively contribute with each other, because Linux is not a "standard" written in stone, but a living and breathing thing.

The CLA is Google's in this case. It gives them the right to distribute your copyrighted work. It also has some terms that say Google could sublicense and redistribute the jj codebase under another license -- which means they could for example release a copy of the jj code that was under MIT, or GPL2, MIT-Apache, etc. Or proprietary, even.

But the thing is, Jujutsu is under the Apache 2.0 license right now. You are within your rights to use Apache 2.0 in proprietary products. Literally anyone, at this exact moment, could clone the repo and integrate it into a proprietary product, or share proprietary binaries built on the code (rename it Gugutsu VCS) without giving up the source, as long as they obey the ASL 2.0 terms. The CLA really has nothing to do with this fact.

If you are personally worried about your personal copyrighted patches going into proprietary products -- or if that's your only worry -- you basically need to avoid contributing to all projects that are not using a copyleft license; just avoiding CLAs or whatever isn't enough. This has been true for a while.

If you are worried about a "rug pull" the next question is whether the developers can actually do that. That is a matter of social configuration of the project, not licenses. The thing with "rug pull OSS projects" is mostly about ownership and labor. Licenses and CLAs really don't matter much if 99.8% of development comes from one group of unified engineers. Such a setup is risky even with a 0% chance of any license changes. Their company might fail or they might all get fired. You didn't get rug pulled, but the project might die, which is basically just as bad.

But for Jujutsu, there is no majority of developers from any one company, and significant amount of code comes from the community, so the answer is more or less "no, we can't do that even if we wanted." The best we could do is start a whole fork and lose a significant chunk of the community and contributors. There isn't any one group of people with enough of an iron grip to do that without sustaining massive losses.

I think people sort of get "Can this become proprietary", with "Is some <bad outcome> possible" -- in this case Jujutsu's code can absolutely "become" proprietary already in a real way. You can just go do that now. But a lot of "rug pull" things are prevented, I think, simply due to the fact we have a robust and strong community outside the (paid) developers

Ultimately, for a non-copyleft project, non-assigning CLAs like the one Jujutsu has are basically just annoying, legal ass covering mechanisms for Google's sake. I also do not like the CLA, it's just basically an irrelevant piece of paper as far as my principles on the matter are concerned. The Linux kernel DCO is basically just a CLA with fewer words, motivated by similar concerns to not get backstabbed due to the business logic of suing people.

If we got rid of the CLA for Jujutsu, I personally think it would probably still be nice to ask people to respect the DCO.

reflog can't quite catch every change that might happen because not everything is stored directly as a ref (ie a "head" that git tracks, like a branch pointer).

For instance, if you are interactively using `git bisect` and you mark commits as good or bad, and you accidentally mark a commit incorrectly, you have to do something like:

    git bisect log > /path/to/file.txt
    git bisect reset
    # modify file.txt to "look correct"
    git bisect replay /path/to/file.txt

The reflog can't really capture this kind of thing, hence why you have a bisect log -- now a wholly separate concept that exists independently of the reflog.[1]

Another example is when you do something like screw up an interactive rebase. Let's say you rebase 20 commits and then you get a conflict on commit 8. You fix the file conflicts, and continue. You accidentally solve the merge incorrectly, continue and get another conflict -- but only realize your mistake after you start solving it. The reflog can't save you here. You have to completely abandon the rebase and start over. (This specific example might be handled better these days).

I think the biggest thing about `jj undo` is that it works everywhere. You can undo rebases, merges, conflict resolutions, copies, deletions, whatever. The secret behind it all is that internally, jj is architected in a way where implementing a feature looks like you are working with a transactional database. You actually have `begin_transaction()` and `commit()` methods in the codebase that will make changes to the commit graph visible in an atomic way. When a command like `jj rebase` happens, all of the changes it makes are inside a transaction and committed at once. Every operation in the repo is a transaction, and it all goes into a log, which records the effects of a transaction -- very much like a database system!

So "undo" just means "undo the effects recorded in a transaction" and that is about all. And so it works for everything! And this design is very easy to intuitively understand and program against, as a maintainer, along with our other high level internal APIs. Any developer can easily write code that Just Does The Right Thing and the user can undo it and it's no big deal. When I develop and work on Jujutsu myself -- like I'm actively developing new features or prototyping ideas -- I almost always _use my own jj repository_ as a test repo while testing my builds.

In contrast, Git does not have one unified "transactional" layer for things like this. But not all is lost, there has been work on 'git undo' and it was implemented by... Someone who is now a Jujutsu maintainer[2]. :)

[1] Technically we do not yet have "step by step" bisect with good/bad yet (only "automatic" bisect that is one-shot), so that is something Git can do we can't do at all right now, but bear with me. :')

[2] https://blog.waleedkhan.name/git-undo/

You can speak the git protocol over the network only, but one advantage of using the same storage on disk as Git and exposing it in the same way (in a manner that keeps jj/git in sync) is that git-based tools still work. So, people still get diff markers in the gutter of their editor buffers, random scripts that do `git rev-parse` or whatnot still work out of the box, etc. This makes the experience more seamless and imposes less friction on non JJ users, eg you do not have to write a patch and add a special case for JJ because `git rev-parse` failed to run and then ask pretty please to merge it (and then keep doing that forever as you are the only user).

It doesn't sound like much, but before I started contributing to Jujutsu I was a user of https://sapling-scm.com/ -- Sapling is fantastic. It stores data on disk in git format, but back then it was not exposed to the user by default -- the .git directory is hidden away. It actually ended up causing a lot of friction that random `git` commands would not work, or tools had other various git-based behaviors. These days, sapling has a "dotgit" mode (partially inspired by jj I assume) that puts the .git directory in the root dir, so `git` commands still work.

Beyond that though, speaking Git over the network only has other complications on the client side. In particular Git clients and servers negotiate what objects each side has (given what the client requests), and from that negotiation derives a list of needed objects to give the client, and then sends a packfile for it. This is all relatively expensive to do on demand, actually, so it would make the interactivity for network operations much worse if you need to wholly translate your storage into packed objects, etc. And doing it efficiently would require you keeping a cache around that is basically a git database anyway, so you might as well just go ahead and use it. Not the end of the world in terms of downsides, but a trade-off that adds some baggage.

We (East River Source Control) don't run Jujutsu, it does not "belong" to us -- it is a community project! Nothing has or is changed. Most of the contributors have nothing to do with us/Google/whoever. We get tons of great contributions from highly experienced and talented individuals. It's healthy, check it out: https://github.com/jj-vcs/jj/commits/main/

Most of the maintainer stuff is also overhyped in a way (OSS maintainer-heads know this). The maintainer group is largely structured to just keep things moving; not really a privilege but a responsibility -- making sure things get merged, doing technical reviews, ensure builds are unstuck, and hitting the green approval button. Our own community members also do code review, find bugs, triage things, answer questions, design features, help get users unstuck, etc. We are very much not alone, and I have great confidence in the constitution and strength of the community itself as someone who has been around the block a few times.

This is going to sound silly and "guy approves of himself" adjacent, but I've been doing OSS maintainer stuff for like 2 decades at this point, and jj is truly a gem as a project. It is vibrant, and the community is generally speaking insanely talented (huge number of git powerusers), and we have a weird dogfood advantage where people use the tool to contribute right back to it. Martin did an awesome job setting the tone of the project just through his behavior before many of us joined years ago. He's a naturally good project lead.

As I said elsewhere: I work for ERSC and I am a Jujutsu maintainer. This is just me speaking candidly on my own behalf.

> git can do everything jujutsu can do (otherwise, jujutsu couldn't work with git).

FWIW I think it's a bit more nuanced than that. As a trivial counter example Git does not currently have a way to store conflicts inside commits[1], which is one of our major features. The way this works is that we basically store the sides of the conflicting trees in the Git object database (and another conflicted tree pointing to all of them), but the actual data structure representing the conflict as Jujutsu understands it is stored elsewhere. Git will be very confused looking at a conflicted tree object created by Jujutsu -- it shouldn't break but it doesn't understand what it's seeing. So, if a object can be stored in the database that is correct but Git can't really "view" it properly, does "git" (or capital-G Git) support it or not? Depends on who you ask, I guess. The storage layout being intimately tied to Git "as a thing", part of its identity, is one of the most interesting properties it has.

The way I see it is this. Jujutsu uses the Git storage layout on disk. But basically all of the algorithms and UX between the two are completely different. That is where most of the real differences are. To the extent we integrate with lots of fiddly Git details (eg tracking branches, remote integration etc) so that `git` commands work -- that's more necessity to make the UX nice. We could absolutely use the on disk Git format but in a way that was inscrutible to the `git` CLI, it just obviously would not be very nice.

As a disclosure I work at ERSC but I am also one of the maintainers of Jujutsu; this post is written with my maintainer hat on.

[1] At Git Merge last year, Elijah Newren prototyped and demo'd a really early and cool example of storing first class conflicts in Git, based on his work on ort-merge. So this might not be true forever :)

macOS absolutely has sandboxing, what are you talking about? But the reality is that you need custom sandboxing tools less when you don't have basic problems like "anything that runs ever can read my ~/.ssh directory without problem" or "you can hijack my password by interposing sudo and thus do anything". This does not matter because macOS will see a program signed by Corp XYZ is trying to read data not owned by that cryptographic signature, and it can't escape the code signature check, and it will flag it. A program cannot simply read your password from stdin and elevate privileges silently, because granting new privileges requires communicating with a higher privilege program so it can delegate to you, and that program has a non spoofable prompt. And so on.

You can use Linux's sandboxing functionality to make a pretty hardened server. If you take in mind the physical deployment and go the extra mile, it can be very secure. The Linux desktop is not and will never be secure in its current form from things like extremely basic local malware. You would have to redesign much of the desktop stack from the init system downward so you could easily do things signature-based identity, proper per-identity secure storage and key management, securitizing elevation of privileges, getting rid of setuid, etc.

    > Every default malloc implementation worked this way about 12 years ago.

Yes, it is now 12 years later, and memory allocators are better. The memory allocators of that time were also better than the ones 12 years their prior. That's the point.

    > Making lots of small allocations, even from multiple threads then blaming the allocator is a losing strategy. An allocator is only going to be able to mitigate the damage to speed and interactivity.

It's just a reality that musl is measurably worse at multiple threads allocating even in very polite conditions, because it causes lots of contention. If your program allocates in multiple threads, it is probably going to get slower with musl. If you don't want that, other memory allocators will do great even at high allocation rates with more threads. You could write many other data structures that had equally poor behavior under multi-threaded contention by just throwing a lock around everything and calling it a day, and those bad data structures would also cause "damage to speed and interactivity" or whatever. This isn't very hard to understand.

    > The compiler should be able to take something with good access patterns and make something fast, especially out of the basic C functions.

I agree, modern compilers are good. But these are extremely common specified functions, they are called everywhere all the time in every C codebase (and that's partially why compilers even recognize these patterns specifically so they can insert optimized routines). Mature implementations that are hand optimized still pay off and also tend to be tuned for various edge cases or quirks that aren't going to come for free from the C compiler either, so it's still work even if you aren't writing assembly for everything or whatever (e.g. uarch dependent codepaths, or optimizations for short strings or whatever).

glibc's AVX2 based memcpy functions have a non-negligible performance impact in at least 1 application I maintain on the order of like 8-ish% vs musl (wall clock). It just has to memcpy/memmove a whole lot. Whether or not that's tolerable is up to debate, but a spade is a spade.

    > Performance wise it's unlikely C string functions are actually the bottleneck in a program. Maybe for specific programs a naive memory copy function could benefit from AVX instructions.

I said "backbone", not "bottleneck". They are common functions sprinkled in everywhere throughout every application in every codepath on something like a modern Linux desktop. An inverted callstack flamegraph can show you stuff like this. It is basically no different than compiling your application at -O1 and -O2 with GCC. Does the fact your program get 20% faster from -O2 mean that there were "bottlenecks" the compiler solved? No, there was just performance left on the table by emitting better code.

    > "Have to" and "often" are debatable.

Not really. I have to spell it out apparently: actual programs written by normal human programmers do those things, all the time, they exist in and are common in the world, they depend on other code that does that and is common in the world, they run on your desktop and phone and all servers, and they benefit quite a lot from optimized components like memory allocators and string routines and -O2 making their programs faster. This is pretty easy to observe and the means of doing so should be quite obvious, so there's no real debate.

Now whether this fact holds -- whether these programs "have to" do these things or not -- in the imaginary fantasy land people have in their heads where they make up arguments to themselves about how, if every program was written how they liked it, it would be better? That I'm not so sure about, I will admit.

No, musl's allocator is just bad even in completely normal programs, and it is especially awful if you are using even two threads much less a lot of them. It has no TLABs or arenas. It has a single global mutex over alloc/free paths. It does syscalls underneath that lock (mmap) meaning the few fast paths it has are rarely taken under contention and have to fall back to futex wakes, so even 2 threads with minor contention and allocation rate will have visible wait points in profiles, stuck waiting for the allocator. It returns mapped memory to the OS very eagerly when a size class is empty, so even single allocs followed by a single free can cause thrashing as it mmaps/unmmaps things repeatedly for a size class over and over. Etc. You quite literally have to limit your thread count when using musl, because it will tank the performance of actually highly threaded programs that can scale with core count, even at very modest allocation rates and small working set sizes.

Its string routines and memory copy routines are also similarly bad, as the article alludes to. They are just naive loops with nearly no optimization. These are not small insignificant functions where using them is "doing it wrong", they are the backbone of vast amounts of code and can be made multiple times faster. You can similarly see string routines pop up in profiles all the time in musl builds in my experience. And unlike the memory allocator these cannot be "fixed" systematically across the application at link time, so you are stuck with it.

Real programs have to often do things like allocate memory and use multiple threads and process strings. People have been optimizing these things for decades, there is vast amounts of prior art, the musl developers simply did not do so because they prioritize simplicity over nearly everything else (from what I can tell) including performance.

Yeah, but there's already plenty written on that topic elsewhere; the OP is making a distinctly different point and everything else in it still applies, I think. Even if you are using a memory safe language -- if you are developing security sensitive software, you need to understand that exploits can now be researched, developed, and deployed in hours (or for stupid bugs, minutes!) instead of days or weeks or months. And this process can now just be massively scaled up with money and compute. It was not like this even 24 months ago.

Their revenue mostly comes from enterprise deals which are very profitable, and they are in a hot industry with loads of enterprise customers paying them. Storage is also extremely profitable with very fat margins at a large scale like what HF is operating at.

Most of HF's revenue comes from their enterprise customers; you essentially get direct access to their MLEs (Slack) as well as their software stack, hence the per-seat cost and annual minimum contract price. In that sense they are not particularly "compute-heavy" in terms of what they "really" sell.

Just yesterday I was complaining that I wanted to SSH back to my homenet while at the office, on my office (not home) tailnet. I wrote something based on Iroh to do this, but it's one shot (ie not particularly generalized). Might be able to throw it away or redesign it with some inspiration from this! Thanks.

The WSE is very expensive to build, and they have a waiting list of customers who are already willing to pay a lot of money for the available supply.

DX12 was over 2 years old by the time Vulkan was released. People in the industry also use DirectX extensively and have for decades (Vulkan is fairly marginal in comparison); many modern graphics API features (mesh shaders, ray tracing) were designed and developed in DirectX, as Microsoft worked with closely with ISVs on these features before they spread to wider audiences and published specifications.

Honestly if you are creating games, with the rise of Proton and vkd3d, there is seemingly less need to target Vulkan today than ever before. Just target x86_64 Windows with DirectX11 or DirectX12 and you will even get Linux support (and some day, probably macOS) "for free". That's just for games, though.

The relevant kernel code isn't written by Claude though. According to git blame, 95% of the code in inductive.cpp is 5+ years old, with only ~3 hunks (totaling less than 30 lines) coming within the last 12 months including this fix. The Lean kernel in general does not seem to change very much, e.g. the last two years are very sparse in terms of activity with relatively contained changes when I examine the history (especially so when contrasted with the pace of the rest of the project).

Beyond that it looks like a pretty simple oversight. Coq and Isabelle have also had 'prove False' bugs, it isn't the end of the world. Stuff like this happens.

"Does the hardware physically work" isn't ever really the question under consideration, though, for better or worse. For Macs specifically, it is going to get increasingly difficult to even test things in the coming years. Mac x86 builds are by far the flakiest on GitHub in my experience, there's no expanding capacity, only refurbished machines 6 years out, and the number of users is dwindling, not to mention the enormous performance gap. So what do you do? When we last asked about it in a project I work on a few users expressed interest, so we kept it, but that isn't forever. The JDK as a project probably has a different risk profile than most other projects too so the cost of keeping around that code can be relatively high.

Not saying it is always good, in fact I would say there is rarely a "good" happy outcome in these cases, just trying to give the alternative perspective when you have to make these calls.

Point well taken.

They've been upstreaming drivers for the X2 platform for months at this point, since at least late 2025 (just search "glymur" or "kaanapali" on LKML).

The patch referenced in the Phoronix article is just a device tree file. That is the easiest part of the whole thing. As usual he's just farming every random LKML patch he can for clicks.

Not having a free toolchain that can actually handle the real language has probably been pretty bad on the downstream public knowledgebase. Hopefully Verilator can eventually close that hole, and there can be more high-quality designs and codebases incorporated into future models. Claude is at least good enough to write SV that triggered a compiler crash or two. :)

Despite the name seemingly implying otherwise, F3 is an alternative to columnar storage formats like Parquet; the goal is not to support every conceivable encoding of every file type such as a PDF. Think of the use cases being more like "What if you used a specialized compressor and need a custom block decompression algorithm" or "Decode internal format into Arrow output" or something like that.

They almost certainly already make a fuckload more money off API pricing than they do subscriptions, even if there might be more total subscription users. So offering subscriptions even at some loss is probably going to continue. Honestly, I'd be surprised if they even lost money on most subs; there are definitely Token Whales out there who mess up all the accounting up, though.

Realistically I think Anthropic just has insane demand but finite capacity to run models, and Fable will just make them more money if they dedicate it to API pricing. I suspect the goal here is something like: get individual engineers/PMs on their personal plans to taste Fable and then go to their meetings and say "Yes doubling the price of every single input/output token is a good idea, boss".

I suspect it's a long tail sort of thing; it mostly doesn't matter except when it really matters. It's interesting that the stated motivation for the patch is in the context of agentic tools spawning subcommands. There's some related prior art in this area where the payoffs could be much greater, like fuzzing: https://gts3.org/assets/papers/2017/xu:os-fuzz.pdf is an example. It would be very interesting to see this patch applied to e.g. AFL++

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.