LA UOSC

大道无形若水 go 使用 loong64 有其不得已而为之，但就发行版系统架构而言，和内核高度统一总是好的！

杜比 感觉需要@xen0n 白老师给我们普及下发行版ARCH的选择与思考 😀

在我看来，这不需要选择，除非不得已

大众认知都是loongarch ,极少数使用loong ,我选择loongarch64(除非能统一到loong64)

loongarch64或者la64

论相似，loong我觉得跟long也挺像的。

个人建议，简写loong64，完整写loongarch64 。

建议统一loongarch64

在 arch 标识符这种地方使用 loongarch 的主要坏处是——长。

以 Gentoo 为例：

Gentoo 的 eshowkw 工具，keywords 是纵列渲染的：

packages.gentoo.org 的 keywords 表格，横向空间很宝贵：

GLEP 53 明确提到：

Note that no limit on the length of both fields in the keyword are imposed. However, we cannot overemphasize our preference to keep keywords small and sensible.

“keyword 两个字段的长度没有限制。尽管如此，我们保持 keywords 短而靠谱的倾向性再怎么强调也不过分。”

因为我们一般称呼放置 Gentoo keyword 的配置项叫 ARCH，已经有 arch 四个字母了，那么叫 loongarch 就很冗长。事实上，最早的 Gentoo port 确实使用了 ARCH=loongarch，是上游讨论下来要改 loong 的。当时的讨论串在这里（从 In-Reply-To 字段可以链接到先前的邮件，一小串讨论）。

Go 项目采用 GOARCH=loong64 而非 GOARCH=loongarch64，也是相同原因。在 Go 上游的 porting issue 提出伊始，就有 Go 官方维护者指出：

I think "loong64" is good; a GOARCH value that itself contains the substring "arch" is redundant, we don't do that for any other.

“我觉得‘loong64’不错；一个自己就包含‘arch’子串的 GOARCH 取值显得冗余，我们在别的架构从未这么做。”

因此，出于尊重上游项目既有规范、秩序的考虑，对于那些有需求使用较短的架构标识符的场合，使用 loong、loong64 是比较好的选择。

（肯定有人会提议 la64。绝大多数地方不使用 la64 是因为我们这些认识 ia64 的老家伙还没入土。某种程度上这也是尊重不同群体。）

还有一个头疼loongarch太长的原因是，slackware在各mirror中，会在目录上进行区分架构，比如：“slackware”（默认是x86）、“slackwarearm”（里面是arm的slackware，里面会进一步区分区分是arm还是aarch64）

下面是截图清华mirror的截图，

假如LoongArch Slackware的架构宏选择和在mirror中目录的体现是：

# 选择 loongarch64
slackware          # 这是 x86
slackwarearm       # 这是 arm
slackwareloongarch # 这是 LoongArch,长度就很震惊，心惊胆颤。。。

# 为啥不选择 la64 的原因是因为和ia64太像了

# 选择 loong64
slackware       # 这是 x86
slackwarearm    # 这是 arm
slackwareloong  # 这是 LoongArch，长度也还是长但也还能接收,
                # 但选择loong的话，会让爱好者搞混(开发者大概率会懂)记错loong和loongarch，引起分裂。。。           

我现在很纠结，咱们继续再讨论讨论吧，感觉这个问题会影响后续上游LoongArch 发行版规范。。。

我现在已经整好了个slackware current loongarch64的基础系统了(在跑通流程，后面确定好 ARCH，可以很快 bootstrap 出 LoongArch Slackware)

下面我放一下“ARCH=loongarch64 ”（现在为了先验证构建方法可靠性，后续会有变化，此ARCH非最终定论）slackware current loongarch64 的图片，请大家欣赏：

大道无形若水 “LoongArch 发行版规范”，这说到了点子上，上游的约定成俗确实要考虑，但同时也是要尊重龙芯的规范，目前新老世界几个发行版，loongnix，uos，kylin，archlinux ，大多使用的都是loongarch，linux上游提交使用的也是loongarch，难道这还不够明显么。

个人或者一些群体做发行版，对loongarch生态是好事，但是在一些关键字的选择上，有规范的用词不用，岂不是舍近求远，至于字长排版上的考虑，简直是丢了西瓜拣芝麻，削足适履！

长度根本不是主要问题，主要是取名字带了arch，让老外有了简写的机会，造成规范不统一。打包格式应该统一，因为面向新手和用户。在mirror长度也有好处，在众多架构中能直接选最长就完。

aa

我理解你说的这种更利于新手使用，但我们不能为了做事情而做事情，

我们需要做的东西符合slackware哲学，这样更有利于更多的人认可和使用LoongArch，要不然就只能自娱自乐

就像LA基础软件，为什么要提交到上游？为什么他们会改版多次上游才接受部分patch？我们不光要自己玩好，还有带着大家一起玩，所以我们需要考虑的更全面些

我近期发现很多人不认为 ARCH=loongarch 冗长，是否这和思维方式不同有关？因为按照英语语感，这很冗余，并不像汉语思维中“架构=龙架构”似乎不太显得冗余。但我觉得尊重各个上游的现存实践是有价值的。

至于“在众多架构中能直接选最长”，这完全就是因为（1）不完全懂英语，一串英文不想看具体意思，只看长度；（2）不打字，等你需要在各种地方不断重复 LoongArch loongarch loongarch64 loongarch64-unknown-linux-gnu ARCH=loongarch GOARCH=loongarch64 的时候就疯掉了。你可以说自己是最终用户你有理，但不把开发者观点当回事也是很令人震惊的。

那就la64呗。

在众多架构中能直接选最长，是指能一眼分辩出来，至于打字一般用补全的，选loongarch是想着官方用的时 loongarch64-unknown-linux-gnu，能统一尽量统一，并没有不把开发者观点当回事，最终决定哪个的是你们，最后有什么说错的，请多多包涵。

aa 在众多架构中能直接选最长，是指能一眼分辩出来

这个论据有些弱：名字长，以至于能一眼分辨出来，好像并不是一个值得夸耀的点（这里可能有个人好恶的区别）。至少对我个人而言，三个字母（arm）、五个字母（loong、riscv）、九个字母（loongarch）并没太大区别；字母多了还要仔细看看确认没拼错。

aa 打字一般用补全的

没有补全的地方也有很多。不是所有打这种字的时候都在命令行。。当你在写代码的时候经常要打这九个字母，甚至经常要调整周围一些行的纵向缩进来适应 XXX_LOONGARCH64_XXX 的时候，可能就不会觉得名字长很方便了

aa 选loongarch是想着官方用的时 loongarch64-unknown-linux-gnu，能统一尽量统一

实际上大家基本还是能用全称就用全称的。例如 linux、systemd、qemu，你不会看到我或者任何其他社区人士在阻挠。你仔细看我前面回复也会发现，所有改 loong 的地方都是为了遵循相应上游现有的取名风格。

费劲解释这些当然不是为了单纯争论个是非对错，搞得脸红脖子粗。但作为不直接参加开发、沟通、协调等上游工作的最终用户，既然都决定在这个架构的襁褓时期就入坑使用了，应该做好面对施工现场的心理准备。在这个阶段就加入讨论的话，大家会预期你要了解许多事情的来龙去脉的，至少要对讨论内容的上下文有所了解。一面墙的英文是你不想看也得看完的。

叫什么都无所谓了，反正已经错失了统一的机会，谁做的项目根据自己的喜好来吧，反正也没几个人用

杜比 “LoongArch 发行版规范”，这说到了点子上，上游的约定成俗确实要考虑，但同时也是要尊重龙芯的规范，目前新老世界几个发行版，loongnix，uos，kylin，archlinux ，大多使用的都是loongarch，linux上游提交使用的也是loongarch，难道这还不够明显么。

感觉杜比你没有抓住讨论的重点，我们要做的loongArch Slackware项目是要扩大LoongArch架构使用范围，而不是一定要要迁就老的(但也不是完全抛弃，我们所做的一切都只是为了让上游社区接纳LoongArch)，就像为什么会有新旧世界的区分一样，

既然做新世界了，我们要有促进loongArch Slackware(其他项目也是一样)符合上游规范，扩大LoongArch影响

个人或者一些群体做发行版，对loongarch生态是好事，但是在一些关键字的选择上，有规范的用词不用，岂不是舍近求远，至于字长排版上的考虑，简直是丢了西瓜拣芝麻，削足适履！

你这个想法我就很不理解了，我在昨天的帖子回复中说过了，我们不能为了做事情而做事情！

假如我们只想自己玩耍，那么ok我们选择什么都可以，只要小圈子里玩的开心就行，但你要想清楚我们的出发点是什么！发起这个项目是为了增加LoongArch发行版，扩大LoongArch影响范围，可以让Slackware社区把LoongArch作为支持的架构。

杜比 有些人一味地强调上游其他的开发者怎么样怎么样，一切以上游人员的意见为准，因为他骨子里就认为自己的意见或者国人的意见并不重要，只想到要一定要尊重老外

涉及到技术的比如irq那些另当别论，能协调的地方不协调反而找一堆理由

更何况，内核和基础工具，已普遍采用loongarch，这不正说明loongarch接受度的普遍性么，这也是一种约定成俗，我个人希望开发者也要尊重这一点！

杜比 更何况，内核和基础工具，已普遍采用loongarch，这不正说明loongarch接受度的普遍性么，这也是一种约定成俗，我个人希望开发者也要尊重这一点！

假如真的存在“普遍性”，那么上游社区就用会直接用loongarch了，而不是上游开发者们讨论后最后决定loong了

其实讨论到这里，大家估计也发现了，slackware ARCH选择的问题大家都知道，“长”这个问题是客观存在的，我们自己都能感觉到，同理来说上游社区的开发者也是能感受到。

其实LoongArch发行版的ARCH选择的问题很好，讨论中，其中有坚持loongarch64坚定者派、中立派(都还行，理解双方的坚持原因)、也有上游社区开发者派，但不管如何我们都是为了LoongArch生态做贡献，LoongArch加油！

其实我觉得都行，就看是方便开发者还是方便新人理解了

我倾向于loong64，因为loongarch64多四个字母确实敲着累一些（