icylogic

79% 我一天也够用啊。。就算换全新的不还是一天一充，体验有区别吗。。。
而且这么多代一点换的欲望都没有。。

Only apple users can do

Is Parallel Programming Hard, And, If So, What Can You Do About It?

可惜 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 得了。