[Ygg2]

> But that's fine, because for the purpose of this thread that just means that Microsoft's theoretical Crater-like run for Windows compatibility just takes even less time and resources

Huh? I don't follow. There are more libs to test and they aren't standardized. How does that mean theoretical Crater will take less resources?

Did you mean excluding non-testable code? That doesn't prevent future glibc-EAC incompatibility.

[kibwen]

The manual labor would be greater, yes, and that's a problem. But the original point of this thread was about dismissing the idea of Crater at scale, which is unnecessary 1) because it's an embarrassingly parallel problem, and 2) because you're probably not going to have a testable corpus larger than crates.io anyway, so the hardware resources required are not exorbitant for a company of Microsoft's means. Even if they could only cobble together 10,000 C apps to test, that's a big improvement over having zero.

[Ygg2]

Thanks for that clarification.

I agree it's embarrassingly parallel, but the expenses scale almost linearly.

Overall I agree, for MSFT it's doable, but I doubt any Linux distro has enough money to continually provide this level of support.