go compiler, kubernetes, and Qt/X11 https://ivzhh.github.io/ 对应的问题. 先去看看 @醉卧沙场 的回答， 特别是文中提到的那个链接。 一般方案很保守，替换LVM到btrfs，/boot保持原样，这样grub启动的问题都不会太大。Ubuntu的zsys方案里面， /boot做成了bpool,更加激进一点。opensuse的btrfs的子卷方案更加复杂 安装一个Fedora的时候，假设只有一个盘，那么如何划分这个盘是安装程序需要考虑的问题。 Linux下一般有两层划分，第一次是传统意义上的分区（partitions），Windows里面的C:盘之类的说的就是分区。 但是一直以来有个问题就是一旦设定了分区，在想修改分区就比较困难（并非不可能）。特别是老BIOS分区， 分为主分区和逻辑分区，这个调整起来更麻烦。为了解决这个问题，大部分服务器的操作系统（windows的非系统盘也支持） 都提供一种“存储卷”，也就是抽象出一个逻辑上的存储池，整个存储的地址空间不再是一维的。 基于存储卷的设计，Fedora首先把你的盘设置为一个pv（物理卷，实际的存储提供者）， 然后再创建一个vg（卷组，逻辑上的存储池），然后在这个vg上面创建/和/home这样的逻辑卷lv,最后再将lv格式化为xfs或者ext4。 主要问题是，系统依然需要在lv依然是一个文件系统的，有自己确定的大小。如果用户不满意这个大小比例， 然后又给较大的分区（数据可能不太多）使用了优秀但是不能缩小的xfs系统，那么以后后悔了也很难改（只能再给vg加pv了）。 btrfs的设计不一样，它有一个子卷的概念（深入的探讨需要阅读fc大大的文章)。 子卷是个完整的文件系统（有自己独立的inode）。如果Fedora采用btrfs作为/系统，那么/home之类的目录，可以变成一个子卷。 这个子卷是个独立的文件系统，但是不再需要一开始就确定大小，这些子卷共享一个存储池的同时，每个都有自己独立的文件系统。 这个基本上是最直观的好处。 当然，说到btrfs必须要提到bugs,这个是最让人诟病的。官方的wiki有个详尽的表格， 除了RAID56是明确不稳定的，一般都还好。当然另一个值得一看的wiki是Debian wiki的btrfs页面，里面提到了一些 5.x内核里的bug,不过总体来说可控。 我的nas用的Fedora 32，选择btrfs之后，系统盘就是这样的方案，目前一切都ok。另外nas上跑的虚拟机是debian 10，用btrfs RAID 1跑/和/var， 目前也一切正常。数据问题是大问题，一个是要多备份，二是如果觉得不安全，就不要用。Fedora是新技术试验场，风险一直都是存在的。 Wed, 09 Sep 2020 00:00:00 -0700 https://ivzhh.github.io/2020-09-09-zhihu-fedora-33-default-btrfs/ https://ivzhh.github.io/2020-09-09-zhihu-fedora-33-default-btrfs/ Background Q: what platform are you referring to? A: Both Pi 4 4G (ARM64) and Intel i7-8xxx laptop. General Discussion ZFS Q: Did you experience data loss? A: Yes. I use an old USB (250G) HDD attached on Pi 4. Disk dies after four months. The main problem is too... Mon, 07 Sep 2020 00:00:00 -0700 https://ivzhh.github.io/2020-09-07-four-months-of-zfs-btrfs-lvm/ https://ivzhh.github.io/2020-09-07-four-months-of-zfs-btrfs-lvm/ Well, silly me. I forgot to backup the postgres for miniflux, and the miniflux is gone for me. On the good side, I backup the feeds.opml every day, so I just need to migrate to something else. Now that I move to thunderbird as my default mail/nntp reader, why not... Thu, 30 Jul 2020 00:00:00 -0700 https://ivzhh.github.io/2020-07-30-OPML-for-thunderbird/ https://ivzhh.github.io/2020-07-30-OPML-for-thunderbird/ I run a Windows and a Ubuntu in Hyper-V on daily basis. All X11 apps are run by VcXsrv. Okular, VS Code, etc. are all as good as local apps. Firefox works on 99% of websites I visit, but not on Medium main page. I read Medium a lot as... Tue, 23 Jun 2020 00:00:00 -0700 https://ivzhh.github.io/2020-06-23-firefox-vcxsrv/ https://ivzhh.github.io/2020-06-23-firefox-vcxsrv/ I would like to recommend two blogs. The authors maintain high standard of writing contents. They pick up not-easy topics and deliver them well. For those who are interested in go and docker/k8s, I recommend you to have a quick read. The first one is Quasilyte blog. The author’s topic... Sat, 20 Jun 2020 00:00:00 -0700 https://ivzhh.github.io/2020-06-20-recommend-two-blogs/ https://ivzhh.github.io/2020-06-20-recommend-two-blogs/ 编译器在过去的几十年里层出不穷，一个重要的变革就是基于 SSA 的优化器。 其中最出名的自然是 LLVM 提供的 LLVM IR。一款工业级的编译器更加有助于 Go 编译器相关的文章不少了，有的关注整体编译流程1，有的关注 Plan9 汇编2， 有的对SSA这些内容进行了涉猎3。特别是这篇3对SSA的话题有一定的覆盖， Go 在2016年将后端转向了SSA 小米大佬讲解 Go 之编译器原理 ↩ Go 系列文章3 ：plan9 汇编入门 ↩ Go 语言设计与实现 ↩ ↩2 Thu, 26 Dec 2019 00:00:00 -0800 https://ivzhh.github.io/2019-12-26-go-compiler-1/ https://ivzhh.github.io/2019-12-26-go-compiler-1/ Intro When I tried to play with firecracker from Amazon, I met problem at step 1. Step 1 is to run a containerd with firecracker’s plugin, a naive snapshotter and ctr pull. ctr pull is responsible to download a debian latest docker image, and use unpigz to un-gz it (ignore... Fri, 18 Oct 2019 00:00:00 -0700 https://ivzhh.github.io/2019-10-18-debug-firecracker/ https://ivzhh.github.io/2019-10-18-debug-firecracker/ 2019年python、golang、java、c++，rust如何选择？ 如果是面向工资编程，那以下主要默认题主要去互联网企业。 开源时代一种新语言的诞生，往往是以下几个步骤： 推出一个很酷的新模型或者新理念：比如Python的ML，Golang的静态编译/工具链等 一些先锋程序员就会投入进去开发，这些程序员就是天使轮拿到的资金 要早别人抄走这些优势之前构造一个基本可用的工具链（调试器，IDE，包管理，优化）/框架库（主要是Web，SQL等） 如果成功，就会有后续公司进入然后他们出钱养程序员投入这个领域，相当于语言融资了ABC轮 直到某一天市场大规模采用了，大量贡献了程序员/库/教程/stackoverflow的踩坑，相当于语言上市了，一个正循环就培养好了 再然后就是用得越多，岗位越多；岗位越多，新鲜血液越多（相当于资金） 一个大金主，也就是现在喜欢说的“XX的爹”，可以长期稳健的提供大量人员和技术，比如Google把go和kubernetes结合的很好，于是go的市场就非常好，因为一个语言那么多细节，那么多场景都需要人去编码，去测试，去验证，没有人去踩坑的话就是用户自己踩，自然也就没人愿意跟随。和房价一样，追涨杀跌，“信心比黄金和货币更重要”。 所以验证市场的方式就是观察走势和交易量： 去看看招聘的岗位数量 去看看采用某个技术栈的公司的业绩如何，特别是其市场地位 看看某个领域新出的库，都是用什么语言写的。比如在k8s里面，出了一堆新东西，你看是go，或者C++还是别的什么写的。说明这个领域的基本定式方式已经变了。 讲讲反面例子： Github一家不太容易支撑起Ruby/Rails，所以Ruby的热度下去了。这也跟Ruby在推出RoR之后，Python快速学习了这套打法。但是后续的库，Python却多于Ruby，所以一下子战局变了。这就是所谓的先手没有变成优势。 总结以下： java肯定没问题，生态完善完美，大公司在用，人力和技术储备和流动性都不错 go肯定没问题，云生态完美，k8s基本上统治 rust还属于A轮阶段，看看你自己是不是先锋开发者。未来Rust我觉得不错，但是时间点无法预测。 C++老牌，但是最近新库似乎就是Envoy用C++写的。 python我觉得主要是ML领域 Mon, 30 Sep 2019 00:00:00 -0700 https://ivzhh.github.io/2019-09-30-RE-language-trends/ https://ivzhh.github.io/2019-09-30-RE-language-trends/ 背景 Kubernetes 的强项是部署无状态的项目（ stateless ），比如网页服务器。 但是很多软件是有状态的，比如需要访问磁盘，或者只能有一个实例，或者要有主从架构， 甚至是有备份方案等等。 Kubernetes 提供给用户的界面是声明式的，当年 SCIP 刚开始流行的时候， 声明式的“告诉我要什么，不要告诉我怎么做”是非常一种很冲击的观念。 函数式语言把这个功能交给了编译器去把“要什么”转换为“怎么做”， Kubernetes 则把用户提交的 YAML SPEC 转换为调度的方案。 虽然 Kubernetes 提供了 StatefulSet 来表达“至多一个”保证的强一致单例1， 但是这个方案的上限就是 Kubernetes 提供给 StatefulSet 的调度逻辑， 超过了这个范围， Kubernetes 就无所适从了。 Kubernetes Operator 2（以下简称 operator ）很聪明的提供了一种模式（ pattern ）， 这个方式其实也是把 Kubernetes 内部调度器的工作方式暴露给应用开发者， 应用开发者可以定制自己的部署逻辑。当然，对于很多人来说，了解 Operator 的实现细节不是必须的， 但是对于涉及到存储（Storage）的应用，开发者很有必要去了解 Operator 的工作方式了。 Operator 是一种模式，实现这种模式有好几种方法。目前来说有三种， 徒手写一个... Thu, 26 Sep 2019 00:00:00 -0700 https://ivzhh.github.io/2019-09-26-bottom-up-kubernetes-operator/ https://ivzhh.github.io/2019-09-26-bottom-up-kubernetes-operator/