linux桌面环境组件下载,各种桌面环境内部的各组件的依赖性是否太高了？

该楼层疑似违规已被系统折叠 隐藏此楼查看此楼

回复 @EchoResonant :能力越大，责任越大。作为被依赖的上游项目，影响地位本来就是一种能力的体现。与之匹配的，应当是清楚的项目目标，和支持这个目标的合理设计。

不被项目目标需要的过度设计不是合理设计；但允许被非特定第三方复用的提供重量级公共基础设施的项目，因为不可避免地会争用有限的资源，总是隐含了一个项目宣传上以外的目标：减少不够成熟的竞争项目的必要和重新制造轮子的借口。

因此，不论发起项目的直接动机、重点和特色是什么，不便被复用的设计，就不可能是合理到哪去的设计。这根本上是作为 DE 这样的问题领域决定的。(另外的一个例子是通用语言的实现。)

须知，即便用户能更清楚自己的需求为何不能被满足，甚至有更强的技术实力完全替代上游设计和实现，因为已有的历史和习惯，实际利用上游项目和上游能做到的并不对等——至少本来依赖上游的其它分支项目会因此承受更大的风险。

从这个意义上来讲，越是影响力大的上游项目，道义上应该越支持模块化配置的复用。即便这种模块化对项目自身的维护和提供支持没有明确的帮助，减少增加本不必要的下游怎么都不容易做好的 fork ，已经是充分的理由。

清算起来，不够模块化可能归咎为能力和资源不足，但不应该以和项目目的矛盾作为借口。否则，一开始它就不应该获得资源来占据这个位置——挤占了其它本可能更好满足所有人需要的项目的资源。(特别地，靠支持特性和选择的自由来吸引用户，后来却整个砍掉支持，比一开始就不支持在结果上更加恶劣。)

结果是，光看项目影响的问题领域的影响地位，就总是蕴含足够明确的模块化的必要性——并且很大程度是客观上不可避免的，不因维护者多想把这个目的排除出去而转移。

真正要拒绝自认为不必要的模块，能做的就是提供更加可能被广泛复用的模块直至标准化接口，而排除没有其它明确技术优势的类似设计的必要性。

与这个做法相反，在没有可用标准方案的情况下，只是在项目边界内部逃避模块化，或者仅仅就是不自觉地使用不够模块化的设计，减少下游项目和最终用户的可用选择，却又没有能力在业界消灭 fork 自身的合理理由，都只会让整个所谓的生态更加糟糕。这是方向和方法论上的原则错误。