文章批评crates.io强制要求GitHub账号登录才能发布Rust包，认为GitHub不应成为语言生态的隐性依赖。评论者进一步指出，单一中央仓库模式糟糕，应允许跨平台依赖，且当前由微软中介的托管方式令人担忧。

Taggart 认为 crates[.]io 仍要求使用 GitHub 账户登录才能发布 Rust 包，这很不合理，因为 GitHub 不应成为语言生态系统的隐性依赖。Hugo 雨果批评单一中央仓库的设计糟糕，认为包应能依赖任何地方托管的包，而“无法依赖其他平台”与“平台由微软控制”的组合尤其糟糕。Chris Denton 反驳说，包可以托管在任何地方，不一定要发布到 crates.io，且 GitHub 仅用于身份验证，只需替换这一环节即可解决问题。Taggart 回应称，问题不仅限于身份验证，并指出默认注册表作为生态系统的核心组件存在此依赖才是关键。他还提到，尽管最近有进展，但撤销这些决定很困难，而相关人员是有薪水的。

根据评论内容，主要观点和论据总结如下：

1. 对GitHub依赖的担忧（认可度较高） - 评论1指出："Sadly, that's probably correct. No outside single point of failure that can cancel users at will can be allowed to gatekeep open source projects."（可悲的是，这可能是正确的。不能允许任何可以随意取消用户的外部单点故障来把关开源项目。） - 评论11强调："My take: publishing Rust crates shouldn't depend on any single internet property, including crates.io."（我的看法：发布Rust crate不应依赖任何单一互联网属性，包括crates.io。）

2. 项目进展与挑战（认可度中等） - 评论3提到官方问题："They want to fix this, it's a lot of work that no one's being paid to do, there's a roadmap with specific tasks that need doing, volunteer contributions are welcome."（他们想解决这个问题，但工作量很大且无人付费，有具体任务路线图，欢迎志愿者贡献。） - 评论5补充："Rust is mostly driven by volunteers working on what they find interesting. Boring/uninteresting tasks depend on funding, a warm body to accept the funding, and a reviewer."（Rust主要由志愿者驱动，他们只做感兴趣的事。无聊的任务需要资金、接受资金的人以及审查者。） - 评论9比喻："Crates is widely used so it's a rebuilding the track while the train is driving kind of problem."（Crates广泛使用，所以这是边开车边修路的问题。）

3. 与其他语言的对比（认可度较低） - 评论4表示："Aka one of the many Rust reasons why I chose to learn C."（这也是我选择学习C语言的众多Rust原因之一。） - 评论6赞赏PHP的Packagist："forcing you to package from a source repository, so that you can't upload a different artifact from what you keep in source control."（强制从源码仓库打包，确保上传的制品与源码一致。） - 评论8和10提到Go语言的处理方式，但认为其并非完美解决方案。

4. 潜在解决方案（认可度中等） - 评论7建议："this feels like a great place where atproto / bluesky support would slot in well."（这似乎是atproto/Bluesky支持可以很好切入的地方。） - 评论5提到已合并的RFC和开始实施的方案，但强调需要更多志愿者和资金支持。

平衡性总结：多数评论认同减少对GitHub依赖的必要性，但承认实现难度大、优先级低。部分用户因此转向其他语言，而项目方表示正在推进但依赖志愿者贡献。解决方案包括自托管、使用去中心化协议等，但均需大量工作。