diff options
| -rw-r--r-- | posts/rust-2020/comment_1_922dfd4b3ea454cac19a2ff57d1e9369._comment | 40 |
1 files changed, 0 insertions, 40 deletions
diff --git a/posts/rust-2020/comment_1_922dfd4b3ea454cac19a2ff57d1e9369._comment b/posts/rust-2020/comment_1_922dfd4b3ea454cac19a2ff57d1e9369._comment deleted file mode 100644 index 2f9000e..0000000 --- a/posts/rust-2020/comment_1_922dfd4b3ea454cac19a2ff57d1e9369._comment +++ /dev/null @@ -1,40 +0,0 @@ -[[!comment format=mdwn - username="https://launchpad.net/~lifeless" - nickname="lifeless" - avatar="http://cdn.libravatar.org/avatar/722ad06feba2807112d3543a822bf6fe17d851c400ac22d3a10fa0e3368bae9c" - subject="Some thoughts" - date="2019-11-29T21:50:30Z" - content=""" -Its a nice goal to raise, I have some thoughts/quibbles/what have you. But first I want to acknowledge and agree with you on the rust community, its so very nice, and you're doing a great thing as rustup lead; I wish I had more time to put in, I have more things I want to contribute to rustup. I'll try to get back to the meetings soon. - -##On trust - - completely agree about the need for the crates index improvements. - -##On curlsh though - - it isn't the worst possible thing, for all that its \"untrusted bootstrapping\", the actual thing downloaded is https secured etc, and so is the rustup binary itself. Put another way, I think the horror is more perceptual than analyzed risk. Someone that trusts verisign etc enough to download the Debian installer enough over it, has exactly the same risk as someone trusting verisign enough to download rustup. - -Cross signing curlsh that with per-distro keys or something seems pretty ridiculous to me, since the root of trust is still that first download; unless you're wandering up to someone who has bootstrapped their compiler by hand (to avoid reflections-on-trust attacks), to get an installer, to build a system, to then do reproducible builds, to check that other systems are actually safe... aieeee. - -I think its easier to package the curl|sh shell script in Debian itself perhaps? apt install get-rustup - -## On duplication of dependencies. - -I think Debian needs to become more inclusive here, not Rustup. Debian has spent; pauses, counts, yes, DECADES, rejecting multiple entire ecosystems because of a prejuidiced view about what the Right Way to manage dependencies is. And they are not right in a universal sense. They were right in an engineering sense: given constraints (builds are expensive, bandwidth is expensive, disk is expensive), they are right. But those are not universal constraints, and seeking to impose those constraints on Java, and Ruby, and Node - its been an unmitigated disaster. It hasn't made those upstreams better, or more secure, or fixed problems for users. I have other blog posts on this so rather than repeating I'm going to stop here :). - -I think rust has - like those languages - made the crucial, maintainer and engineering efficiency important choice to embrace incremental change across libraries, with the consequence that dependencies don't shift atomically, and sure, this is basically incompatible with Debians world view. - -Debian can: - - ship static-but-for-system-libs builds - - not include things written in rust - - ask things written in rust to converge their dependencies again and again and again - - modernise their infrastructure to cope, which would make Java and Node and Ruby so very much better - -I have a horrible suspicion about which Debian will choose to do :(. The blinkers are so very strong in that community. - -## For Windows - - we got to parity with Linux for IO for non-McAfee users, but I guess there are a lot of them out there; we probably need to keep pushing on tweaking it until it work better for them too; perhaps autodetect mcafee and switch to minimal? I agree that making Windows users - like me - feel tier one, would be nice :). - - -## Shared libraries - - perhaps generating versioned symbols automatically and building many versions of the crate and then munging them together? But I'd also like to point here again that the whole focus on shared libraries is a bit of a distribution blind spot, and looking at the vast amount of distribution of software occuring in app stores and *their* model, suggests different ways of dealing with these things. -"""]] |