Subverting the secure boot/upgrade chain would require a SecureROM exploit and presumably a compromise of the Secure Enclave, so the answer is almost certainly "no" (even prior major exploits from recent memory like usbliter8 are tethered and don't exploit the enclave; the last true untethered Jailbreak was iOS 9 or something.) An upgrade would fix it. The internet reporting claims this break they are showing in this video is untethered though, which is extremely rare on its own.
Embedded Swift is honestly very cool. I never really used Swift itself before, but I think it's a good niche since embedded dev could stand for another tool and the language is pretty nice. It also doesn't really suffer from most of the issues people have historically brought up with Swift (cross platform, slow compiles) etc as it is so small, at least to me. :)
If you're starting from scratch I've found you can actually write ~everything in Swift quite easily (reset vectors, compiler emitted intrinsics, etc). But beyond that I think the best feature is that the C/C++ interop works really well and comes out of the box. Makes two-way adoption easy. I wrote a small boot firmware for a simulator and for fun decided to add signatures to the boot process (mldsa44+jq255). You can just copy the .c and .h files and import them into a modulemap file and you're off to the races. You can just get simple .o files and pass them to the linker. There are only 4-5 "freestanding" functions you have to implement. You can turn off heap allocation. Etc.
It would probably be pretty cool and quite easy for instance to write Zephyr or U-Boot drivers, etc in Swift using these techniques.
Can't you just keep using Mold2 for the initial toolchain bootstrap and then build mold3 with Rust as part of the "final" set of toolchains that are to be used to compile everything beyond that? It isn't perfect but it's congruent with how many other components in most open reproducible bootstrapping flows work; ie using GCC 4.4 or whatever just to bootstrap GCC 10. It's annoying but it only needs to be done once and then you just use it to bootstrap newer components forever. Doesn't help with compile times, though.
I would agree if not for the fact rust depends on almost the entire tree, so doing what you propose would increase our full tree verification time from 6ish hours to 12ish hours erasing any wins mold was giving us in the first place.
I may be misinterpreting the parents point, but you're not building E.g. tinycc for it to be a final artefact; why not continue to build mold2 in its current place in the build chain? It's not going anywhere, much like tinycc isn't.
We have to rebuild tinycc any time a dependency of tinycc changes. Likewise we would have to rebuild mold every time a dependency of mold changes, including rust and all dependencies of rust. It is a problem of almost full tree dependency recursion.
Yes. I'm saying that mold3 gets added to the end of the build tree, and mold2 remains where it is currently, which doesn't change how often you need to build those and let's you continue to use mold2 to speed up the builds (which I've now seen is what you'll likely do).
My point though was that you already build many end-of-life projects just so they can be used in the build, mold2 can now one of those rather than being built for its use in the final distro.
I indicated as much in my original comments. Pinning mold2 and backporting relevant fixes to it forever is our responsibility now that upstream has abandoned the linux-distro-bootstrapping use case. It is just unfortunate as that was supposed to be one of the goals.
That is what we do, and it takes several hours on most machines. Having to do that once to get mold and a second time to then build with the benefits of mold defeats any advantages for us.
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.
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!
> 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!
This is definitely a thing in some embedded systems I’ve used. There are some Marvell boards which do this. They all use U-boot though.
The problem is that the content of the device tree isn't really stable -- if a new kernel version has a driver with a new required parameter for instance, suddenly your ROM device tree is out of date and much less useful.
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!
In theory device trees are supposed to be a OS-neutral stable ABI. Being able to put a device tree into unchangeable mask ROM is an often mentioned design goal.
However, there is a fatal flaw in the process that makes this a pipe dream in reality. In Linux, these rules only apply to reviewed and merged drivers. And during review any new DT interface will almost certainly be bikeshedded in some way.
So unless your chip vendor has upstreamed ALL their drivers before a device is manufactured, the device's firmware-provided DT will very likely work only against a vendor kernel and requires updating.
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.
I'm trying to come from a place of help, truly, so bear with me.
You have to get out from under Google. This would be a red flag during due diligence for many investors.
I'm not saying Google is going to fuck you over but why not just get yourself into a place where you don't need to be writing replies like this, and we don't need to be having this conversation.
And also, I would strongly recommend acquiring trademark rights as soon as possible. If a foundation is formed later you can decide what to do with them, but having them protected is a huge deal.
There's nothing starting me from creating jjhub.com tomorrow and that is a real potential threat for you.
Since I posted previously, I realized I had forgotten trademark entirely, and Google does own the trademark for jj. (See my other comments about the Mozilla/Rust connection, it was the same back then too).
It's not an issue for investors, because again, Google does not own this, and we aren't even modifying jj at this point, and are unlikely to need to. The IP is very clear and not an issue.
> There's nothing starting me from creating jjhub.com tomorrow and that is a real potential threat for you.
That's fine! There's a lot of people already doing this, today. Competition is natural.
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:
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. :')
reply