icylogic

可惜 ff 这些年越来越没人去兼容了，有些网站在 ff 上用起来真的不如 chrome ，所以必须得有个备用 chrome/edge 。
但是 tree style tab 至今没找到 chrome 上的代替品，edge 那个 vertical tab 对于我来说也太凑合了。所以主要还是用 ff

都没说到点上，iOS 截图是压缩了的 png ，但是每个通道是 16bit 的，所以巨大，1668x2388 未压缩应该是几十 M ，压缩完才是十几 M 。
你可以试试，直接拿这图转 8bit 的 bmp 位图都能“压缩”到 12m

明日方舟玩家？

学生的时候糊出来的一个极简（极其简陋）的 hexo 主题 carbon ，应该没有比我这个简陋的了，现在 hexo 主题里还能搜到。不过早就不写博客了所以不整了。就不贴链接了，也不知道现在还能不能用，有没有人用（个人的开源项目，自己不用又没人用的话基本就没什么维护动力了）

后来还移植过一个其他人的 maupassant 到 hexo ，也早早是其他人维护了。我其实没干啥，接手的大佬认真做了好多，
这是他的 repo
https://github.com/tufu9441/maupassant-hexo

可以参考 cotire ，主要干的事就是
- precompiled header 预编译头，但是只能解决一部分
- single compilation unit （ cmake 的 unity build ）把 cpp 整合成一个巨大的编译单元

c 艹 加速编译还有一大堆可以做的事，比如 ccache ，distcc ，pimpl …

glibc 的兼容性，和 C++ 动态库的兼容性是两件事，而且这两点几乎都和 clang 没什么关系。你提到的这些问题，大部分锅是 glibc 的。

glibc 几乎很少有人需要最新版的特性，所以只要你去链最老的 glibc 就可以了，一般会推荐让你到所有目标平台中最老的那个去编译。glibc 就是唯一特殊的那个崽，不能静态链接。

c++ 你想用新的编译器、新的库（包括 std ）是完全可以的，既可以静态链接（如果你能搞到静态库），也可以自己打包动态库（比如 /usr/lib/myapp/libxxx.so ）然后设置 rpath 到 $ORIGIN 之类的，后者其实就是 Windows 那种一个 exe 带一堆 dll ( vcruntime140.dll, etc) 的风格。

这两点综合起来就是，比如你需要给 Ubuntu 18.04, 20.04, ... 这些平台提供支持，那你首先准备一台 Ubuntu18.04 的环境，然后通过 toolchain ppa 之类的东西安装或者编译一套新版的 g++/clang ，多新的都可以，只要你能在 18.04 上跑。最后用这套工具链去编译你的 app ，然后把所有依赖 (除了 glibc) 通过静态或者动态的东西打包带走。

这个你找台环境试一下就知道怎么回事了，比如尝试一下给一台默认 gcc 5.x 的环境编一个使用了 C++17 Filesystem 的应用。







你要是觉得麻烦就直接 docker 得了。

程序员自己用的小工具用 imgui 最爽。

确实备货比往年差多了，而且有些东西货其他平台都可以正常买，就 jd 价格高+预约+抢购+耍猴无限循环。作为一个电商平台，供货量可能都不如一些小店甚至个人。

rebase 是一个整理历史的工具，在*私人分支*里使用 rebase 去整理历史（不管是直接 rebase onto ，rebase -i ，还是 pull —rebase ）是非常合理而且甚至在多人合作中是应该被鼓励的。

因为这代表你最后能给别人贡献一个干净的、非常易于理解、以后也很方便追溯的 patch series/pr ，这代表了你想告诉别人（包括一个月后的你自己），我的每一个 commit 都是有意义、可以被 checkout 出来构建和测试、甚至是做 bisect 的阶段性工作成果，而不是草稿纸上的来回涂鸦，所谓的 graph 好看其实是最次要的

而且这没有听上去那么麻烦，大部分切分合理的快速小分支应该是直接 squash 成一个 commit 的，它就是这次全部的改动，删掉了你在某些地方反复调整的过程（几乎没有人包括你自己需要回顾这个过程），这也是一些团队会直接不管三七二十一把 pr 全都 squash merge 掉的情况（你去看主流的 git 服务器都会提供这个选项）；只有一些确实比较大的改动需要花点时间去认真整理一下。

但是 rebase 正常情况下只应该用于整理私人分支，而不能用于修改公开历史，公开历史包括别人的分支，以及你已经发布出去让别人 checkout 过的分支，这会严重影响协作。

https://www.mail-archive.com/[email protected]/msg39091.html
Linus on git rebase and merge (2009)