Manjarno
Manjaro 只是有着系统安装界面的 Arch 而已。
当然了，哪里不是呢？
声明
在 Manjaro 的资金问题方面我的描述出现了很大的偏差。你可以阅读 Phil 本人的说明。笔记本电脑并不是他买的，而他也不是最终批准这个决定的人。
前言
要人不犯错是不可能的，尤其是在软件行业里。虽然对着每一个错误都嘲笑一番还是蛮诱人的，但本页面的目的并不在此。 在这里记载的大多数事情能展示出某种出错模式，而一些只发生过一次的事件则由我（主观）判定它是否足够异于寻常来决定是否把它们放到这里。 如果你有任何反馈或疑问，或者想提议一些改动，请开一个 issue 或者是 pull request。
有一些人也维护着类似本页面的资源——你可能也想去看看下面的内容：
安全性
Manjaro 的安全性不太好是有着纪录的。
SSL 证书
四次了！这次稍微好一点，毕竟他们至少设置了 HSTS，但尽管如此，不是吧。
第五次。这次是他们的论坛归档。公道地说，他们把趋势坚持了下去——至少开启了 HSTS？根据这个帖子，看起来这个服务器是被遗弃了。
他们第一次证书过期时，他们让用户把自己的电脑时钟拨回去来解决问题。
https://web.archive.org/web/20150409040851/https://manjaro.github.io/expired_SSL_certificate/
看起来我们忘记及时更新我们的 SSL 证书了。 […] 在此期间，请使用下面的临时应对办法：
打开终端
输入这行代码：sudo date -s 2015-04-06 +09
这会把你的系统时间设置回 Mo 6. Apr 00:00:03 CEST 2015。
延迟软件更新
延迟两周再更新软件包也会导致安全问题，但这个问题大概在稳定性一节里讨论更好。
稳定性
Manjaro 和 Arch 两者我都用了好一会儿了，而讽刺的是我经历过的 Arch 的稳定性问题反而比 Manjaro 的要少。
你大概已经在他们的资源里得知了 Manjaro 比 Arch 的软件发布会慢两周。在其说明里这样做的原因是为了稳定性，但这没什么道理。
实际上，这意味着你将更晚获得软件的更新，尽管看起来没什么正当理由。这意味着要晚两周才能获得软件的更新——包括了新特性、安全补丁和漏洞修复。除了这些明显的缺点，它还带来了一个潜在的问题。
AUR
我敢肯定你偏向于 Manjaro 的原因之一就是 AUR。能运行一切东西的安装脚本听起来挺不错，不是吗？那你需要当心了，你不应该像信任你的发行版的软件库一样信赖 AUR，因为那里的脚本是由用户上传的。为了避免运行一些恶意代码，你应该在运行脚本之前浏览一下代码。
另外，大多数这些脚本都假设你运行的系统不会是实际上两周都没更新过的。这会导致部分的更新。最乐观的情况下，程序会无法安装或者不正常运作，而最差的情况下，程序会导致你系统出现各种没有明显解决办法的问题。
就是这样，Manjaro 其实并不支持 AUR。尽管他们传递出来与此相反的信息，Manjaro 还是把责任归到 pamac 的用户头上来遮掩。他们对于 AUR 和潜在风险的警告不足，却又通过 pamac 提供了安装 AUR 包的简化界面。这类似于让人未经培训就进入建筑工地。当然，挖掘机可能比用铲子更快，但用户仍然因为没有被告知所作行为的后果而把自己置于了险境。
澄清一点，我并不完全反对 Manjaro 使用 AUR。但是，这应该是需要仔细思考的东西。AUR 至少需要一定程度上的相关认识，尤其是在一个喜欢把软件包更新延迟并随意变更的发行版上。如果你能够接受这种反对的思想的话，那 pamac 至少应该在它对 AUR 的呈现上更谨慎一点。
pamac 以及扩展到 Manjaro，也对 AUR 不太礼貌。但你可以在后面再读到它们的 DDoS……
把 Asahi 赶出门外
在他们尝试把 Asahi Linux 尽早赶走的途中，他们最终没有和对面开发者沟通就把最新的 PKGBUILD 拉取了下来。这导致了他们把可能有问题的内核递送给了用户。
尽管如此，这还不是最主要的问题。这件事是在这段视频出现之后的仅约三天后发生的（视频内容是桌面环境第一次能够运作了）。这不仅仅离递送“黄金档”还远得很，而且结合上面的推特来看他们甚至都懒得尝试去和项目的开发者沟通一下了解一下项目的当前状况。
管理
资金
本节内容并不精确，只是为了透明度而放在这里。在这里了解更多。
Manjaro 和他们的一个财务管理有过一个冲突。Phillip Muller（Manjaro 的团队领头）用 2000 欧元买了一台笔记本电脑，而财务管理请求对购买作出解释。这最终导致了这个财务管理的免职。财务管理不就是为了保证捐赠资金的公平、有效使用而存在的吗？
QA 差
对 AUR 的 DDoS
Manjaro 的 AUR 工具程序 pamac 在 2020-04-26 递送了有漏洞的一个版本，意外地让每名用户分别向 AUR 发送了成千的请求。在几小时内，这让 AUR 直接对所有基于 Arch 的发行版的用户来说变得无法访问了。
- https://www.reddit.com/r/archlinux/comments/mz3biz/is_the_aur_down_for_everyone/
- https://gitlab.manjaro.org/applications/pamac/-/issues/1017
再次……
在 2021-10-14，Manjaro 又再次递送了 pamac 的有问题的一个版本，导致 pamac 再次被 AUR 屏蔽。这可能也可以解释当天更早的时候的 AUR 断线。
虽然这些事故肯定不是故意而为的，但这也足够显示 Manjaro 所展示出的较差的 QA（质量保证）了。这种事情在两年内发生了两次。
杂项
他们的系统更新脚本曾经对事务的锁文件使用了 rm 命令。锁文件是用来防止多个 pacman 同时尝试修改软件包数据库的。有些时候，pacman 被打断了的时候会残留一个锁文件。这种情况下，移除锁文件是很常见的检修步骤。但是，你应该再三确保没有其它的 pacman 在运行的时候才这样做。而 Manjaro 的脚本之前并没有检查有没有其它 pacman 而是直接进行。
作为替代，我应该用什么？
我并不隶属于这些项目。
- Arch 已经有一个系统安装器了。
- EndeavourOS看起来是 Manjaro 想要成为的样子——只是在我知道的范围内做得比 Manjaro 更对头一些。虽然这么说，在我看来，用 Arch 的衍生版系统还是有一些值得提起疑问的地方。这样做的主要理由（缺少自动化系统安装工具）已经不成立了，毕竟 Arch 已经递送了
archinstall。但是 EndeavourOS 有着对用户更友好一些的图形化的系统安装界面，也默认提供了比archinstall多很多的配置，任君选择。
但我还是想要再说一遍，Arch 已经有一个相对友好的系统安装器了。
简短说明
我知道我这里写的东西看起来有煽动性，但本页面的目的并不在此。这里的资源主要是为了下次在聊天室里有人问“我应该用 manjaro 吗？？”的时候你可以直接让人家读链接里的内容。
维护一个发行版令人钦佩，真的仅此都已经值得称道了。但是，我真的不希望你（以及别人，在 Manjaro 不可避免地坏掉然后你去找别人帮忙的时候）把时间浪费在 Manjaro 导致的各种奇怪问题上。