41–50 of 103 posts
I really prefer icecream to distcc: it handles toolchain distribution, scheduling, and discovery.
> But unlike distcc, Icecream uses a central server that dynamically schedules the compile jobs to the fastest free server.
I'm curious about the security implications with using distcc. Doesn't this mean that if one computer gets compromised, the attacker can run code on all other computers using distcc, or secretly inject malicious code in the build result. So using distcc means that all computers using it must be trusted. And that means that using it on "all developers computers to share the load" is good for performance but bad for se…
Everything on the same LAN should generally be treated as "compromised/not compromised" together. There's rarely just a compromise of one machine in the same way there's never just one cockroach. I'm not sure whether distcc affects reproducible builds? You could, in any case, have tighter controls on the release builds, which would be done on a CI machine before signing. (Back when I used distcc we didn't distribute…
I would not generalise so quickly. Is every computer compromised in the internet if one is compromised?
No. It highly depends on the trust between those machines and whether they share similar services with critical vulnerabilities. Only then, they might be compromised together.
But the world has evolved and not everyone anymore bases their total trust and security thinking for "no outside internet connection, we are fine".
Even without distributed builds, clearmake could re-use .o files built by other people if the input dependencies were identical. On a large multi-person project this meant that you would typically only need to build a very small percentage of the code base and the rest would be "winked in".
If you wanted to force a full build, you could farm it out across a dozen machines and get circa 10x speedup.
Clearcase lost the edge with the arrival of cheaper disk and multi-core CPUs. I'd say set the gold standard for version control and dependency tracking and nothing today comes close to it.
Earlier quoted context omitted.
Everything on the same LAN should generally be treated as "compromised/not compromised" together. There's rarely just a compromise of one machine in the same way there's never just one cockroach. I'm not sure whether distcc affects reproducible builds? You could, in any case, have tighter controls on the release builds, which would be done on a CI machine before signing. (Back when I used distcc we didn't distribute…
> Everything on the same LAN should generally be treated as "compromised/not compromised" together. There's rarely just a compromise of one machine in the same way there's never just one cockroach. I would not generalise so quickly. Is every computer compromised in the internet if one is compromised? No. It highly depends on the trust between those machines and whether they share similar services with critical vulner…
Internet is no lan (local area, L2) where computers do indeed typically have more generous policy regarding access between each other.
Think about the windows firewall asking whether you just connected to a work/public/home network
https://github.com/icecc/icecream - another option that does what distcc does, but aimed at a somewhat different use case.
https://ccache.dev/ - a similar idea but provides caching of build outputs instead of distributing builds. You can use it together with distcc to achieve even better performance.
25+ years ago, our company used Clearcase for version control and it's clearmake had distributed build capability. Clearcase used a multi version file system (MVFS) and had build auditing so clearmake knew exactly what versions of source files were used in each build step. It could distribute build requests to any machine that could render the same "view" of the FS. Even without distributed builds, clearmake could re…
To this day, I find Clearcase's way of doing things is the better way to do version control. Git, in comparison, kind of feels alien and I could never really get the same type of comfort on it.
Related: https://github.com/icecc/icecream - another option that does what distcc does, but aimed at a somewhat different use case. https://ccache.dev/ - a similar idea but provides caching of build outputs instead of distributing builds. You can use it together with distcc to achieve even better performance.
25+ years ago, our company used Clearcase for version control and it's clearmake had distributed build capability. Clearcase used a multi version file system (MVFS) and had build auditing so clearmake knew exactly what versions of source files were used in each build step. It could distribute build requests to any machine that could render the same "view" of the FS. Even without distributed builds, clearmake could re…
Nowadays most of it has been ported into Java, if the ongoing efforts when I left, finally managed to migrate everything away from C++, Perl and CORBA.
A problem not shared by icecc.
Fastbuild https://www.fastbuild.org/docs/home.html is the free distributed compilation system many game companies use. The combination of automatic unity builds (simply appending many .cpp source files together into very large combined files), caching and distributed compilation together gives you extremely fast C++ builds. Also supports creating project files that are compatible with XCode and Visual Studio so you c…