31–40 of 62 posts
So much time has been wasted by the open source community on pointless projects like this. >Reproducible builds allow people to "have more confidence that the binary you are using, which is actually executing on the computer, corresponds to the source code". The developer signing the build provides sufficient guarantees. Reproducible builds is another waste of time that the open source community has fallen for instea…
So much time has been wasted by the open source community on pointless projects like this. >Reproducible builds allow people to "have more confidence that the binary you are using, which is actually executing on the computer, corresponds to the source code". The developer signing the build provides sufficient guarantees. Reproducible builds is another waste of time that the open source community has fallen for instea…
It is their time to “waste” though.
Earlier quoted context omitted.
It is their time to “waste” though.
This thinking keeps open source behind competitors. Additionally this person is not just wasting his own time, but through both just this talk and the contents of it where he asks others for help it is causing other people to get involved with this waste of time.
No one commands open source developers to do the things they do, they do them because they have an itch to scratch and are kind enough to release that work for other people with the same itch.
Your view is very much "What I think they should do is more important than what they think they should do" and that's not how that works.
At best that comes off as a little entitled.
Earlier quoted context omitted.
Just for perspective, the people working on his are pursuing their hobbies and sharpening their programming skills. In contrast, you are using your time to whine about it on the internet.
People can still pursue their hobbies and sharpen their programming skills by working on more productive issues that exist. While you could call my comment whining, if it is able to change maybe even one person's opinion on the utility of this work it could help lead to a bigger reprioritization of people's time allowing for more important issues that affect real users to be addressed instead.
No, they can't. People pursue things that interest them, if it isn't interesting they wouldn't do it at all.
This is similar to "why donate to cause X when cause Y is much more important?" well if cause X didn't exist, those people likely wouldn't donate at all, so it's not really an opportunity cost.
Surely with AI it should be possible to go in the opposite direction, and use reverse engineering software to reconstruct something like the original source code, and automatically check for functionality differences. So then you only have to trust your RE software (and your system environment etc. I suppose). Would that be easier?
Earlier quoted context omitted.
People can still pursue their hobbies and sharpen their programming skills by working on more productive issues that exist. While you could call my comment whining, if it is able to change maybe even one person's opinion on the utility of this work it could help lead to a bigger reprioritization of people's time allowing for more important issues that affect real users to be addressed instead.
>People can still pursue their hobbies and sharpen their programming skills by working on more productive issues that exist. No, they can't. People pursue things that interest them, if it isn't interesting they wouldn't do it at all. This is similar to "why donate to cause X when cause Y is much more important?" well if cause X didn't exist, those people likely wouldn't donate at all, so it's not really an opportunit…
Earlier quoted context omitted.
People are doing that with lisps and schemes, but then the interpreter keeps growing. People start to want more expressivity, it needs optimizations so that you don't go mad trying to write a compiler with it and needing to wait 15min between test runs. That compound if your lisp interpreter is itself running as a bytecode for an extremely simple VM interpreter. I don't think it's a bad idea, but you will quickly end…
The more I think about it, the more I think that bootstrapping the build isn't actually the huge problem it first seemed to be. There are practical problems to solve, but they CAN be solved. In contrast, how can you make sure that the actual payload code hasn't been tampered with? It is written in a high-level language, but it gets stored and viewed on devices that have backdoors in their CPU microcode and huge OSes…
I think that depends how far you want to take the paranoia. In principle if you want that to be a secure signature that can't be forged, you're back to needing both hardware and software you trust to verify the signature. Hashing a large binary and verifying a signature on paper is wildly impractical.
If someone prints the code and claims they verified it, you could trust them. But if they give you a signed archive that you download and verify on your computer, you're back to square one. You would have to know your software and hardware isn't already backdoored, just to verify that the software you received isn't backdoored.
>A trusted actor can verify, or even build, a trusted system by hand on trusted hardware, sign it, and then you can use that (binary!) as long as you run it on your own trusted hardware and verify the signature first.
Your own trusted hardware AND software, because you're not going to be verifying that signature by hand, and you're not going to load the binary file in memory by hand, so either a kernel or system software (like UEFI) will be handling your trusted binary first.
But then you're back to needing a clean bootstrap again. Which is why the chain starts with a hex0 that you can type manually, not with a large signed binary that would require either an already trusted system, or cryptography that's realistically not possible to do by hand.
Would love to see someone try to automate the bootstrap chain from a working C89 compiler to Rust. At this point I think current LLMs are able help these incredible feats of bootstrapping as they can grind out the impossibly long built times over multiple days/weeks. I am very optimistic for deterministic builds in general.
I am working on this![0] But this is actually a herculean task, I've been chipping at it for weeks and even trying to cheat somewhat by translating mrustc from C++ to C89. If anyone has ideas/cheaper ways to run it I would like to know. In the meantime, months ago I achieved bootstrap of TCC (then GCC 4.6) via the same path as the live-bootstrap project but replacing the Scheme part with a C compiler in Ben Lynn's Ha…
GCC 4.7.4 was the last version of GCC fully written in C, with full C++98/03 support and a decent subset of C++11. As far as I know it is used by the bootstrap project presented in the article.
So much time has been wasted by the open source community on pointless projects like this. >Reproducible builds allow people to "have more confidence that the binary you are using, which is actually executing on the computer, corresponds to the source code". The developer signing the build provides sufficient guarantees. Reproducible builds is another waste of time that the open source community has fallen for instea…