其它诸如 NixPkgs、AUR、Guix、Alpine 都是直接下载软件包官网的源码包,所以不要指望方便的找回老版本了,只能可劲的升级升级再升级永不回头。
nixpkgs 和 guix 自己的 substitute server 上保存了所有构建过的版本以及其源代码。
nixpkgs 和 guix 看起来包比较多,是因为 guix 包含了很多 cratesio, pypi, elpa, 等其他包管理器的包。Nixpkgs 包含的更多,甚至包含 Hackage 上所有的包。
至于 Repology,这个只能说看看就好,不太懂 Repology 的更新机制,单看的话很容易推导出不正确的结论。
比如 GNU Guix repository information - Repology
还有, 对于 GNU Guix 的一些包,Repology 不记录最新版本(滚动更新)上的包。如
我的龙芯笔记本上使用的是Debian 8,确实不错
我主要用Ubuntu,无非就是方便稳定,使用人多。
哪个型号的CPU?
guix 编译过的源码包存起来,这个怎么看到?是永久保存,还是暂时缓存,定期删除?
我在 guix 官网没找到类似 debian, arch archive那样的访问入口。
可以看我在那篇知乎文章下面的回复
早期型号2f
看过了,这最多算内部实现的缓存机制,没有文档说明,没有不依赖 guix 的下载方式,没有 file list页面看存放的源码列表,不清楚其清除策略。
这个状态,我认为谈不上保存了软件包历史版本,包括二进制包、源码包,它就是个没有SLA也不公开访问方式的 guix 专用缓存。
你可以理解为 content addressable mirror,类似我提到的 softwareheritage 或者 IPFS 之类的东西。目前这东西还是中心化的,所以有人在研究 IPFS 或者 bittorrent 来交换 binary cache
这俩东西要分开来看。Guix 的元信息保存在 git channel 上,substitute server 只是按 hash 保存内容,所以元信息要从 git channel 获取,又要用到其他 guix 的 API(比如 search
)
落实到具体使用上,Guix 对于不同版本的包处理我认为是比 Debian 这些好的。比如像 LLVM 和 GCC 这些工具,Guix 会同时保存多个版本(比如 LLVM 9-14, GCC 4-11),而且装起来也不会冲突,没有 Debian 那种 /etc/alternatives
。普通的包,可能只会保存一个版本,这种情况用 time-machine 可以直接 build 也可以用 time-machine 从 substiute 下载源码。
我现在就用的Ubuntu给你回复的
那篇文章探讨的只是历史软件包包括源码包的归档方式以及可用性,并不是说 nix 不如 apt。nix 的设计从技术上讲,是优于所有其它包管理工具的,但从社会合作上讲,传统的包管理工具更容易复现问题,更具一个OS的整体感。
回到软件包归档的问题,如果回头 guix 有简单直白的软件包版本搜索、下载、列表,并且明确缓存的文件长时间不删除,那么我可以把它跟 Debian, Redhat, Slackware一族并列到一起,虽然我觉得软件包归档这种事没必要去中心化,觉得一个 apache file list页面就挺美了。
我主要反驳他的这一点,不知为什么最后给他带到软件包源码可用性上去了
Ubuntu 也很不错,老版本都归档的很规整,有点遗憾的是 14.04之前只有光盘,没有散装的 repo 了。
今天发现 FreeBSD, NetBSD, OpenBSD 归档也做的很好,我之前没找到而已,老版本井井有条的在 archive server上,包括最老的 1.0 版。
源码包存放时间不定,除了依赖 guix、nix 就不能看了,其它的软件源都可以在 web 浏览器里很方便的按目录查看、下载。
Guix,Nix 也比较对我胃口,但要说推荐一个 Linux 服务端发行版,我还是毫不迟疑首推 Debian。
Slackware 的归档做的也很好,甚至可以说令人感动,一个基本上单枪匹马做的发行版,坚挺三十年,归档井井有条,朴实无华,极具传统黑客感。只是鉴于其维护力量、文档等,并不推荐。
我感觉就个人用而言,其实没那么多讲究,可能随便选了一个,用起来过得去就一直用下去
我感觉对于新手来说,用一个最容易上手的就可以,对于老手来说,用什么都差不多。
Fedora is the best
选了个 suse,跟着他家版本卖来卖去,选了个 redhat也是变来变去最后 centos 打脸了😄
还是有的选的,不只眼前能用。