LoongArch Slackware current bootstrap 项目启动 1. Slackware是什么？ Slackware历史悠久且优秀，它始于1992年，在1993年首次发布，是现存最古老的商业Linux发行版。Slackware致力于成为一个简单整洁的Linux发行版并尽可能的向UNIX靠拢，这使它非常适合想学习Linux或其他类UNIX系统的人。 Slackware的设计理念以简单性，软件纯度，而核心设计则强调上游资源应保持不变。Slackware 中的许多设计选择可以看作是继承了传统 Unix 系统的简单性和KISS 原则的示例。 2. LoongArch Slackware current bootstrap 项目建立的原因是什么？首先需要介绍下为什么选择 Slackware current ：Slackware 官方维护着一个开发版本（Slackware Current），并且不断有新的软件被加入到这个源，用户可以实现类似 Arch Linux 的滚动升级，等到一个开发版本足够稳定，便会发布一个稳定版。项目的建立原因有两个：（1）跟进 LoongArch 上游社区最新状态，让LoongArch开发者和使用者可以使用上游社区最新的技术成果。（2）丰富 LoongArch 平台发行版系统的种类，可以让大家在LoongArch平台上可以开心的玩耍Slackware（后面也希望可以推动上游Slackware支持LoongArch平台）。现在LoongArch 新世界里有： CLFS for LoongArch 、 gentoo 、 archlinux （ Archlinux loongarch64 bbs讨论帖子）、武老师制作的Archlinux 、 debian还在进行中 3. LoongArch Slackware current bootstrap 项目是做什么的，解决什么问题？ LoongArch Slackware current bootstrap 项目是把Slackware进行移植到LoongArch平台，项目的目标是在LoongArch平台使用Slackware可以和x86平台一样的用户体验。 4. LoongArch Slackware 的 ARCH 选择与思考： BBS讨论帖：此问题详细讨论地址个人见解是distro的ARCH讨论还需要继续，问题还可以深入讨论的必要，这个问题会影响后续上游LoongArch 发行版规范，但此项目需要继续前进，所以本人决定，先以"ARCH=loongarch64" 验证构建方法可靠性，后续会有变化，此ARCH非最终定论综合考虑，本项目移植LoongArch Slackware 选择ARCH=loong64 5. 项目源码地址： https://github.com/slackwarecn/slackware-loongarch64 6. 发布v0.1:LoongArch-slackware64-current-bootstrap-20220708：详细信息请看 Release v0.1 7. Slackware LoongArch 20220708桌面图形构建完成：基于v0.1:LoongArch-slackware64-current-bootstrap-20220708 状态，图形桌面截图展示 8. 发布 v0.3:slackware-current-bootstrap-2022.10.12-loong64 9. 发布slackware current mini install 镜像： slackware64-current-loong64-20221122-mini-install.iso 后面我会在此处，放上我从头移植LoongArch Slackware的成果和展示，欢迎大家来此处讨论 LoongArch Slackware ，此帖持续更新中最后感谢上游LA开发者们的讨论，让我对移植到新架构上发行版，有了更多的认识，过程中有很多注意事项，比如代码规范、各核心基础软件和发行版ARCH的选择、上游社区的沟通方式等，这些问题的思考让我对发行版的整体有了更深的认识。

4.LoongArch Slackware 的 ARCH 选择与思考：欢迎大家针对发行版ARCH的名字选择在此讨论: 最近看到LA开发者们对发行版ARCH的讨论，事后我对ARCH进行了思考。因为现在考虑64位，LoongArch Slackware 的 ARCH 有以下几个选择，我把当时讨论的几个ARCH列出来：（1）ARCH=loongarch64 ，我从开始就喜欢loongarch64，所以我之前移植好的 LoongArch archlinux 使用的是loongarch64，现在想想它的长度太长了，所以我需要再慎重考虑下ARCH的选择 loongarch64) export ARCH=loongarch64 （2）ARCH=loong64 上游社区LoongArch 的go、v8使用了ARCH=loong64，并且上游 LoongArch gentoo （WANG Xuerui (xen0n) 大佬推动维护的LoongArch gentoo）也是使用 loong64（首次使用）的发行版 loongarch64) export ARCH=loong64 （3）ARCH=la64 ，和ia64太像了 loongarch64) export ARCH=la64 （4）ARCH=l64 ，容易和数字“164”*（一六四）看混，增加了观看人的辨识难度 loongarch64) export ARCH=l64 下面是使用上面列举的 ARCH 打包后的表现： 0 root:~/binutils # ls -al /tmp/binutils-2.38-* -rw-r--r-- 1 root root 4347652 Jun 27 09:42 /tmp/binutils-2.38-l64-3.txz -rw-r--r-- 1 root root 4344636 Jun 27 09:36 /tmp/binutils-2.38-la64-3.txz -rw-r--r-- 1 root root 4304680 Jun 27 09:52 /tmp/binutils-2.38-loong64-3.txz -rw-r--r-- 1 root root 4304728 Jun 27 09:37 /tmp/binutils-2.38-loongarch64-3.txz 所以综合考虑，本项目移植LoongArch Slackware 选择ARCH=loong64 （待定）欢迎大家针对发行版ARCH的名字选择在此讨论

尤其是在一些上游代码使用loongarch来判断平台的时候，架构名称上的统一，不容易产生疑义

杜比哈哈，我理解你的顾虑，这个发行版里的ARCH涉及打包后缀的变化，和代码中的架构判断不相关，所以代码里的判断是loongarch ，现在也还是判断loongarch

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

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

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

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

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

LoongArch Slackware current bootstrap 项目启动: Page 2

LoongArch Slackware current bootstrap 项目启动

aa

并没有反对在特殊地方使用loong，只是担忧接下来统一的打包兼容格式和编程框架会不会也出现分支，比如 lmg 和img 太像之类的，请开发者们提前评估，作为普通爱好者就不参与这个讨论了，请多多包涵。

大道无形若水

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

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

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

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

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

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

杜比

大道无形若水关于“一定要迁就老的”，我觉得是对我的回复的一种误读

我举例发行版，新老世界都有提及，包括新世界的ArchLinux，arch上使用的也是loongarch

其实这个讨论，和新老没什么关系，也不存在新老世界发行版互相迁就的事情。

这其实只是个关于选择的讨论，但选择是要有出发点的！

同意你的一个观点，“不是为了做事情而做事情”

既然是为了LoongArch的生态，那么一些坚持和互相尊重也应该有所体现

龙芯中科

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

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

大道无形若水

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

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

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

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

杜比

大道无形若水

首先，上游社区对发行版的arch，是否有字符数限制，我了解到的，是没有！

如果某个上游，早已有字符限制，loongarch做为后进，遵守上游规范，做一些缩写上的折中，无可厚非。

其次，loongarch 这个字符串有点长，是现实，linux，binutils和gcc 接纳并使用了这个字符串，也是现实

起码说明，字符串的长度，不是上游社区的主要障碍。

最后，无论持哪种观点，属于哪个派别，关于ARCH的选择展开讨论，无疑对LoongArch的生态建设都是好事！

淡炒番茄

我喜欢这种讨论，比一言堂好太多了。

但讨论归讨论，最终还是要形成方案。

即已成事实的，就不要再追究当事人的责任，

形成方案的，对于没有接受的方案提案人也不要心生不满。

再者，毕竟不管开源社区如何开放，那也是别人的地盘，他们有强烈的倾向，不接受我们的提案，也就只能尊重他们了。

针对这些，就只能说，开源社区我们的人多多，或者我们有自己的根社区。

xen0n

再提一点吧。有人说“尊重龙芯的观点”，好像龙芯说这玩意叫 LoongArch 全世界软件就只能用这九个字母来称呼它了，那么两方面：

龙芯给了你多少钱，你就无条件帮他说话？
社区当然不是无脑反对。前面已经提到有很多项目是接纳 loongarch 九个字母来标识 LoongArch 的。对于那些希望标识符短一些的项目，你这时候说“尊重龙芯”，说得不客气一些，龙芯算老几？前些年 NVIDIA 因为驱动不开源，也被 Linus 竖过中指，这可都是西方人。也别把这事上纲上线，挑动民族主义情绪，如果有一个纯中国人成分的“根社区”，这个社区也想架构名字短一点，这时候两边都是中国人也不会放你 loongarch 进去的。龙芯如果想什么事情都称自己的意，即便吵起来了最终方案还一定按龙芯的来，那自己建社区，你看 Loongnix 是不是就很“自主”，里面可是有很多社区开发者们反对的代码哦 ;-)

本质上这个讨论已经和字符串长度没什么关系了，其实核心在于“对一个技术问题，A进了B项目的房间，说我想这么做；房间里其他人说这样可能不好，要不这样？A不同意”这个场景怎么解决。如果 A 说得本来就有道理，就不会起争端了。这里显然 A 初来乍到，不一定是对的，最终肯定是按事情本身的客观逻辑、“是非曲直”来解决的（显然也可能最后房间里的人发现 A 提出了一些新的有价值的东西，进而认同了，当然在架构名字这一方面龙芯并不能作出如此有说服力的辩论）。不能说因为 A 是龙芯公司，他的做法、做派就一定正确了。

杜比

xen0n

我和龙芯一毛钱关系没有，这是其一，能拿这个来质疑，我只能呵呵

第二，龙芯推出的这个指令集，它有名字，有中英文手册，而不是和社区说，“嗨，我弄了个指令集，名字大家随意叫”

第三，哪句话有民族情绪了？请指出，别乱扣帽子！

xen0n

杜比我和龙芯一毛钱关系没有，这是其一，能拿这个来质疑，我只能呵呵

我承认，这是辩论话术，因为你显得非常为龙芯辩护，尽管他在这一方面并不很受待见。并且似乎我和楼主从上游角度的解释仍然并不为你和你观点的支持者所认同，因此我觉得辩论不容易进行下去。

杜比第二，龙芯推出的这个指令集，它有名字，有中英文手册，而不是和社区说，“嗨，我弄了个指令集，名字大家随意叫”

前面应该已经提到至少两三遍了，默认大家也都是叫全称的。本身目前现状也是只有在上游已有命名规范的时候，才不叫 loongarch。目前所有不叫全称的地方都是因为上游有明确观点不支持长名字。没喷点

杜比第三，哪句话有民族情绪了？请指出，别乱扣帽子！

这是针对 @龙芯中科的，不是针对你。放轻松。

杜比

回到主题，关于ARCH的选择，我依然是这样的一个观点：

尊重龙芯，尊重上游，求同存异！

既然龙芯有手册，有官方的中英文名称，那么要做基于loongarch的发行版，就尽量到上游去争取使用这个名字。

开源社区本身就是在不断的争执和竞争中发展起来的，有理有据争取也是对技术的尊重。

所以，期望参与讨论的开源爱好者们，别带情绪，据理力争，有事说事，共建社区交流氛围

毕竟，沟通，是求同存异，消弭误解的有效桥梁！

xen0n

杜比赞同了。

再次重复一遍，目前据我所知，即使利益无关的第三方开发者对 LoongArch 的移植行动，就架构命名而言，也以 loongarch / LoongArch / LOONGARCH 为优先，但上游明确表示需要较短名称的情况除外，此时会一致选择尊重上游现存代码风格。

至于龙芯员工向上游提交代码的情况，先前确实存在有不尊重上游现状，甚至明显错误（例如认为所有 MIPS 都是龙芯，抄 MIPS 做 LoongArch 移植，认为只要 LoongArch 就是 64 位，等等）的情况存在，这些只要被发现，无一例外都会被以相同标准，一视同仁地被要求修改，当然最后谁有道理听谁的。不要对这个情况有微词，社区开发者往龙芯的库提交代码被无理由驳回甚至直接晾一边的情况也不少，彼此彼此而已。

最后，吵起来可比一声不吭、闭门造车、自绝于群众（不光国际群众，中国群众之前他们也绝）好太多了。珍惜现状并基于此再向前进才是好的。

Yuno

很喜欢最后大家的意见。有争吵比没争吵绝对要好很多。一定要放下傲慢的态度，也不要用国产情怀当盾牌，关起门自己玩。技术的事情最后一定要归技术。

lingfengzhe

其实我不明白为什么不学习arm，使用LArch这种名称呢

REDEAST

lingfengzhe 看完整个帖子，你就会发现，有些东西xen0n已经说得很清楚了。有些东西就是中英文习惯的问题。就像表头是架构名（类型），里面其他是ARM，X86，MIPS，Loong，这样就感觉很正常。你叫Loongarch就显得冗长。所以我个人的建议，能完整用的时候就Loongarch，需要缩写的时候就Loong。

PS：感觉大家对完整写法没有意见，现在成了讨论缩写规范了。

xen0n

lingfengzhe 其实我不明白为什么不学习arm，使用LArch这种名称呢

曾经就是 larch，有的地方现在还是：例如工具链里的重定位类型。（没错，龙芯中科自己就搞不一致，一边 loongarch 一边又 LARCH。之前跟他们提过要不要改 LOONGARCH 或者 LOONG 被明确拒绝了，而且没实质理由。说法大致是“工具链项目统一使用 larch”但没有给出其他原因。）

至于曾经使用过 larch 的证据，在极早期的一些龙芯工具链 fork 项目中可以窥见端倪：例如龙芯的 Go 1.15.6 fork，第一个 fork 提交使用的名字就是 GOARCH=larch64。

后边直到提交上游前夕，才批量替换成 loongarch64。再后来的事情大家也都知道了，他们批量替换了第三次。。

按说，龙芯注册了 LArch 的商标，应该用起来，或者至少早些时候就开始宣传以此作为 LoongArch 的简称才对。结果他们并没有。。LArch 也基本被世人遗忘。现在已经没有机会回去了，较短名称已经到处都在用 loong 了。从推广中国龙文化（Loong != Dragon）的角度，倒也是一件好事。。

xen0n

REDEAST 感觉大家对完整写法没有意见，现在成了讨论缩写规范了。

这个也是没办法的事情，他们工具链上提前占位了 loongarch64-unknown-linux-gnu 了，unknown 的部分大家都一样（历史原因），后边大家也一样，就是前面太 tm 长了。可能是搞 mips64el 多了不觉得 loongarch64 长了，毕竟 MIPS R6 更长：mipsisa64r6el 表示 MIPS64r6 小端。除此之外，差不多长的架构也就 microblaze 这种了，LA 绝对是可预见的未来“常见”架构里名字最长的了。