You could use https://github.com/thepowersgang/mrustc to get relatively modern Rust compiler (1.90 currently apparently, but every now and then that is updated). Then build newer rustc from there to reach the current 1.99.
But I don't get why some people are obsessed with bootstrapping. Yes it is good to be able to do it, but it isn't something you need to do regularly.
Especially since rust had a much better cross compilation story than C or C++ (not as good as go or zig though), so you don't need to bootstrap on a new architecture, just cross compile to it. Furthermore, new architectures for hosting a compiler (as opposed to just a target, like microcontrollers) is a rare event. Just something that happens every few years.
> But I don't get why some people are obsessed with bootstrapping.
It only matters if you have supply chain attacks in your threat model. Given they are up 400x since 2019, they should probably be in almost every threat model. Most distros operate on the honor system and that is not going to survive the post AI world.
That's why you have signed packages that everyone can rebuild and verify from the very early stages of bootstrapping to speed up the process and get back to a synchronization point that is reasonable.
Distros that are not fully hermetic and don't have reproducible packages (and there are many layers of reproducibility) will certainly have issues, but that's not a huge problem as long as you have a documented path to getting back to the current state. It doesn't need to be the fastest path, just a verifiable chain of trust.
We do sign our packages, but the threat model is to minimize the time it takes for users to not have to trust us.
It is critical to encourage many independent verifications that it be as fast as possible that someone can go from a clone of our tree of pure source code to the exact release hashes we publish.
Adding any binaries to that means someone that distrusts us must now go build those past releases as well, and if they rely on binaries, they must build those past past releases as well. This approach would make verification time go up dramatically every release.
You don't need to verify the chain of trust all the time, you can remember up to where you had trusted everything when you adopt your solution.
Also, while you can use the latest prebuilt as a stage0, you could also use any other prebuilt from earlier down the chain as a stage0 and still get the same stage2 binaries. This is the next trust checkpoint you have, and it should be fine to have multiple ways to get there too, one for quick iterative releases and one that is reusing the minimal amount of bootstrapped packages.
Or you just try to only upgrade your stage0 once in a while when extremely necessary and it would build your new stage2.
So many ways to optimize the system, it's a choice to refuse to reuse what was trusted yesterday in order to build the next stage.
>it's a choice to refuse to reuse what was trusted yesterday in order to build the next stage.
If the point is to let independent people verify the full build chain, then there is no "trust from yesterday" to reuse.
Even worse, if every release N depends on trusting release N-1, then you need to do a full rebuild of everything in the whole history, instead of just building the current release. This doesn't sound reasonable, or at least sounds incompatible with the project goals.
The readme is too busy, but the video showcase is impressive [0].
I agree the framing is too arrogant though, about replacing blender etc, except if it's delegating the computing to those, because it is very complicated.
> It sounds like people around me are throwing themselves at the machine, volunteering to make themselves obsolete
As a programmer, I cannot let myself be sad for that. Because making other people jobs’ obsolete has been our bread and butter since the beginning of the field.
As a human being, I cannot watch myself in the mirror loathing about the consequences of stuff I have happily inflicted to so many others, without feeling cynical and egoistic.
I don’t know the answer regarding what to do, besides investing and hoping for policies that would make people standard of living mostly independent from their job *if* we all become redundant.
a) scale matters, b) we don’t think up justifications for actions that don’t violate our principles— we do it to absolve ourselves from doing it anyway.
That doesn't mean you need a TUI! Juggler runs in headless terminals and VMs - you run it as a headless server process, and it serves the exact same desktop GUI via HTTP to any number of clients
It does seem like devs are splitting into the TUI and GUI tribes. Like tabs and spaces. We will probably never reconcile our differences or learn to empathise with the other side.
Does it mean that when switching trop sha1 to sha256 you need to forcepush and rewrite all history? Wouldn’t that be a massive source of potential vulnerabilities?
Yes, you do need to do that. However, there is also much more work after that.
Git will not intermingle SHA-256 and SHA-1 enabled repositories, even in things like submodules, so anything used in that manner will need to keep both versions into the indefinite future. If you rely on a submodule that has not yet converted, you will have to convert it yourself and try to keep it up to date, or the forge will have to automatically keep a bidirectional mirror (if you have submodules in various forges, you'll have to wait for all of them to do it), etc.
This means that every SHA referenced anywhere on the internet, in commit messages, in issues, in code comments is now invalid and needs a mapping to find the rewritten one for forever.
It also means that every commit signature ever made is now invalid and will probably have to be stripped from the rewritten new 256 history because it's impossible to resign everything.
Companies like Google and GitHub are working on keeping two versions of each repository so that there can be long stages of ecosystem migrations, but no matter what, it's going to be a huge pain for millions of developers for years to come.
i guess that for now only the default will change for new repositories. support for sha1 is not going to be dropped, so most existing repositories won't switch any time soon. if you want to switch then yes, it sounds like a force push might be needed, although it could also be that simply switching is not possible, but that instead you have to create a new repo and import the history from the old repo, forcing everyone to clone the new repo intentionally.
It is a giant format change, but in the current documentation [0] sounds more like a repack than a force-push. git keeps a lookup table of the SHA1 object ids similar to an index file and some interop is allowed between SHA1 repositories and SHA256. (Primarily if you still needed to use GitHub as an SHA1 server because of some support hiccup, but needed your local repo to be SHA256 for security or other reasons, that's partially/mostly supposted.) Objects need to be resigned with their SHA256 id, but for different reasons than rebase/force-push and with a subtly different developer experience. In theory using that compatibility index of SHA1 hashes a good UI could show both signatures.
Couldn't you write something that checks every commit's content and message is byte equal to the old tree? One scan through the history to verify it should be relatively simple if not cheap. Should be built into git.
The contents of the files don’t change, only the Merkle tree. You can verify that the content blobs all have the same sha1 by literally rehashing. Then you can verify that the contents of the clone are the same. That doesn’t stop history corruption, but it does prevent malicious injection into the current state of the tree before the migration.
Is there any software that can take raw footage from 360deg cameras that are now sprolling, identify businesses without websites, opening hours etc, and pre-fill them? With the user only having to validate.
You can actually add a "streetview" level to the editor by adding the mapillary plugin and you can add material for others on the free and independent version: https://panoramax.fr/
https://alltheplaces.xyz/ is a better version of this idea - grabs snapshots of structured data where the business has made an effort to publish it.
Street view imagery is better for attributes on the actual street - mapillary did it first, with automated feature extraction for street signs etc, others have followed.
That is why I find the prospect of spoiling the plot without warning to be bad taste and didn’t finish the article.
reply