This is the heart of the conflict: Rust (and many other modern, safe languages) use LLVM for its relative simplicity, but LLVM does not support either native or cross-compilation to many less popular (read: niche) architectures. Package managers are increasingly finding that one of their oldest assumptions can be easily violated, and they’re not happy about that.
But here’s the problem: it’s a bad assumption. The fact that it’s the default represents an unmitigated security, reliability, and reproducibility disaster.
I’m sure this will go down well.
I skimmed through and wrote a quick response then browsed the footnotes and had another think about the overall essay. It’s a good and through and thought provoking essay. I would say it might benefit from a review after discussion because some (a lot) of the negatives are in a lots of ways opportunities if you take the right approach.=.
Yes there is no such thing as a secure system.
That’s a rabbit hole and becomes a swamp as you read on.
To do portability well it helps to do this from the beginning. This needs a portability approach which accomodates different compilers and build environments, different quirks and features, tool and OS versioning, and sometimes substitution code. Abstract early and abstract often. The quicker you abstract the quicker you will avoid snags and adding new or maintaining existing platforms is a lot easier. You can also make use of warnings so if a vital element changes you can be alerted to this. Version numbers and other portabiliity relevant flags are your friend.
This can be a difficult one as different people support or finance support for different parts of the overall software system. What looks like a cost supporting an obscure piece of hardware may be relevant to someone who is paying for your kernel development so be careful which branch you are sawing off.
When doing high performance graphics development my view of Direct3D was uprintable yet all the abstractions were there to drop in Direct3D even if I never used it in practice, or 3DFX Glide (restricted to full screen uses) or any future graphics API. Ditto all the other code which needed abstracting. This was mostly interface stuff but also memory and file handling. I’m sure if there was anything else which needed abstracting I would have done this too. I tended to avoid anything which would create lock-in and would either code around it or have graceful fallbacks or substitutions.
I created my own simple memory and file serialising code which was abstracted and used all over the place. It’s very easy to get wrong. One slip in the wrong place and you are in trouble which is another mark in favour of simple code. It did what it did and nothing else.
I think it’s worth seperating the security and reliability issues. To some degree the general angst the author has was replicated with the Windows XP codebase hence Service Pack 3 and Microsoft putting effort into making Visual Studio safer. Then there is the refactoring with Vista which became Windows 7 then more work on improving reliability. It’s a crude comparison but there is likely some useful dialogue to be had.
As the author notes maintainer turnover rate and/or unmanaged code ratio is a symptom which can indicate problems with your entire portability/coding/build/support approach so it is worth dealing with issues.