Hypercube's Channel

我在 AWS Lightsail 上有一个一直在记录数据的数据库，不希望有 downtime，但最近系统盘快要装不下了，我决定把旧的数据备份到别的地方，这台机器上只保留最近一段时间的数据。 但剩余的硬盘空间不够把旧数据打包成备份，AWS Lightsail 又不能扩容硬盘。为了没有 downtime，具体执行的时候，我创建了一个另外的 block storage，暂时挂到机器上，把备份打包到里面并传输走，然后再把这个 block storage 删掉就好了，只用一小会几乎不产生费用的。 （是的，我知道我可以一边打包备份一边串流到别的机器，没必要全存储在硬盘上的。但反正用一小会 block storage 几乎不花钱，这样方便一点。） 现在我全都搞好了，打算删掉这个 block storage，才发现虽然当初不用关机就能 attach，但现在必须关机才能 detach，必须 detach 才能删除，必须删除才能停止计费。 傻逼 AWS。

阿里云：硬盘可以在线扩容，然后需要手工执行命令扩容分区和文件系统，全程 0 downtime。 DigitalOcean：关机时可以扩容硬盘和升级配置，会帮你扩容分区和文件系统。 AWS Lightsail 和 Azure VM：完全不能扩容，自己打个快照然后去删除重建机器吧。 我来用云不就是为了能灵活地 scale？？

https://xdgbasedirectoryspecification.com/ 如今很多人主张程序不应该创建 ~/.steam~/.ssh~/.bashrc 这样的文件或目录，而应该按照 XDG Base Directory Specification，把它们都挪到 ~/.cache~/.config~/.local 里面。 我一直认为这种主张是奇怪和讨厌的。参见 https://lists.debian.org/debian-user/2014/11/msg01817.html ，XDG 标准是在解决 desktop 场景下，不同的程序需要共用配置文件的这个需求，例如每个图形界面实现都要从同一个目录中读取用户安装的应用程序列表。XDG 规定了这类共享的路径的位置，而 XDG Base Directory Specification 只是 XDG 规定的一个组成部分，它的效力并不应当延伸到 XDG 解决的问题范围之外。~/.steam~/.ssh~/.bashrc 这类情况都只和一个特定软件相关，并不需要多个软件共享路径，是遵守 Filesystem Hierarchy Standard 的，和 XDG 无关。 这个网页上举的“clean and tidy”的例子中，家目录竟然还有 ~/.bashrc 和 ~/.profile。如果 bash 的 rc 文件可以破例留在家目录中，~/.bash_history~/.vimrc~/.ssh/id_ed25519 不能也留在家目录吗？这些都是非 desktop 场景下常用的文件，没理由因为 XDG 这个规定就挪走。 有人会说家目录里面太乱了，看着不整洁。把这些东西挪到别处就不乱了？这只是把乱藏起来了而已，想藏起来的话，ls 不要加 -a，文件管理器设置成不显示隐藏项目，不就行了？这些人可能觉得自己永远不需要和这些文件打交道，所以不在意他们的主张会让别人使用这些文件时变麻烦。 这些人跑去给各种项目提 issue，很多时候开发者没时间好好研究这里面是怎么回事，就按要求修改程序的行为来“遵守规范”了，这让我觉得很坑，我又没有精力去盯着各种项目的 issues 一个一个反驳。不过说不定再这样下去，这样做的程序越来越多，就真的成为新的惯例/规范了🤪

https://github.blog/2023-03-23-we-updated-our-rsa-ssh-host-key/ 推荐使用 HTTPS 而非 SSH 的 git remote，有若干好处，包括不需要在 remote 换 host key 的时候手工信任新的 key，以及不需要确保手工信任的 key 真的是正确的。 使用 HTTPS 时，会询问用户名和密码，如果开启了 2FA 的话，密码这里不能输 GitHub 账号的密码，要输入在 https://github.com/settings/tokens 创建的 token（创建时设置合适的权限）。 设置 git config --global credential.helper store 可以做到只输入一次用户名和密码，之后会自动使用之前保存的。

因为以前很久没有好好刷牙，牙结石和牙龈发炎比较严重，最近开始关注这个问题。 目前做了洗牙，但改善有限，医生认为有必要做龈下刮治，是需要麻醉进行的操作，可怕😨自己研究了一番，感觉结论也是应该做，不做的话继续发展下去会导致损害牙根和牙床，过早掉牙。另外即使做了这样的治疗，仍然要坚持良好的卫生习惯才能有效。 牙龈和牙齿之间出现缝隙（“牙周袋”）是不好的，刷牙的一个主要目的就是破坏这样的缝隙中的牙菌斑。如果牙菌斑连续 12～24 小时没被扰乱，就会形成无法靠刷牙去除的牙结石，导致牙龈发炎并加深缝隙。所以正确的刷牙方式要求将刷毛指向这些缝隙，稍微伸进其中振动来破坏牙菌斑。每天应当刷两次牙以保证及时破坏，还应当用牙线处理刷牙时不容易触及的牙缝。 牙龈发炎时，用上述正确的方法刷牙非常容易导致出血。打算试试使用超声波电动牙刷，或许可以避免大幅运动伤害牙龈，还能更方便有效地破坏牙菌斑。 网上很多人提到冲牙器，我的调研结论是好像不必要，使用不当的话还有一些坏处。每天刷牙和使用牙线应该就合适了。

真是太过奖了

馒头的 real world haskell in 2023，充满了 Learn You a Haskell for Great Good 等书学不到的现代 Haskell 工业界的最佳实践: https://notes.0x01.me/

https://humanbenchmark.com/users/63df251ed6060e00087176bf 玩了这么久 CS:GO reaction time 还是好差 感觉几个关于 memory 的测试不是很有参考价值，结果很大程度上受运气影响——随机生成的内容是否恰好比较容易记住 对触控屏的支持有 bug

https://gwern.net/Turing-complete 这个博客里面超链接的机制真不错，虽然有点疯狂😂我也希望能给我写的东西加上这样的超链接，各种术语不懂的话都能一下子就看到是什么意思。 虽然复制粘贴 Google 一下也行，但更简单的操作确实会让我更多查一些东西，原本我可能只有特别想知道含义的术语才会去 Google。另外，每个链接按作者的意图，有的展示 Wikipedia，有的展示一篇论文，有的展示作者的另一篇文章，有的展示当前页面的某个段落（真的跳过去的话也会有点烦），确实比读者自己 Google 要好。

我怎么解决 Linux + 高分辨率屏幕的缩放问题（MATE 桌面环境，不考虑多显示器缩放比例不一致的需求）： 先确认屏幕的真实 PPI（每英寸像素数，可以用尺子量），我的屏幕是 213。 在 /etc/lightdm/lightdm.conf 中设定真实 DPI： [Seat:*] xserver-command=X -dpi 213 确认 Appearance - Fonts - Details 中 DPI 设置为 142。确认 MATE Tweak - Windows 中 HiDPI 设置为 Regular。这两处改了的话很多程序会出现文字尺寸、图标尺寸、控件尺寸之间不匹配的问题。 在 Appearance - Fonts 中设置自己喜欢的字号，对于我来说，默认值（10、10、10、10、11）就不错。 2024-03-02 edit：这里提到了总共 4 个旋钮：X 的 -dpi 参数，Fonts 里面的 DPI 参数，HiDPI 开关，Fonts 里面的字号。我当时就是都试了试各种组合，发现只有说的这一套组合能产生我觉得理想的结果。其他组合具体有什么问题忘了，但无非是这几类： - 文字大小不合适 - 文字和图标、控件的尺寸不匹配，例如所有图标都比文字小很多 - 我常用的 PDF 阅读器等软件无法正确知道 1cm 是多长。按上面的方案设定后，打开一个 PDF，选缩放比例 100%，屏幕上显示的大小和纸张的物理大小是精确一致的

一般的 Linux 包管理器都做不到这两件事： 1. 一个软件包的多个版本共存。当两个软件包都依赖第三个软件包时，只能选一个版本装，不能装两个版本分别给两个软件包用。 2. 非 root 用户方便地安装喜欢的软件版本和所有依赖。如果系统装了 vim 8.2，非 root 用户想用 vim 9.0 就只能自己找来所有依赖，编译安装，没有包管理器这样方便的方案。 为什么一个软件在整个系统中只能装一个版本呢？存储不同版本的软件以及依赖，让它们各用各的依赖，听起来并没有本质上的困难。我最近研究了一番 Nix，它看似可以解决这种需求，但实际上它使我意识到了这里实际的困难。 各种软件里面都有写死的其他软件的名字或路径（一般不带精确版本），Nix 打包时改写了这些内容，为它们加上了精确版本。这样一来，两个软件可以分别调用自己的依赖，互不干扰，这些依赖也都不会暴露给最终用户。最终用户如果也想用这个依赖，要自己指定想用哪个版本（可以是和这两个软件用的都不同的第三个版本）。 但是 Nix 并没有改掉一切，例如 git commit 会自动调用 vi 来编辑提交信息，git diff 会自动调用 less 来分页，Nix 并没有将 vi 或 less 视为 git 的依赖并锁定版本。我想这是比较合理的，因为用户会希望用自己喜欢的 vi/vim 或 less 版本，而不是 git 这个软件打包时锁定的某个版本。虽然 git 提供了配置选项来自定义使用的命令，但默认值也是很重要的。如果每个软件都必须自定义一番才能用上自己在全局安装的 vim 或 less，体验应该会很差。 还有一个小问题是家目录中的配置文件和数据，如果系统中装了多个版本的 vim，却共用一个家目录下面的 .vimrc 和 .viminfo，很可能会出现问题。如果试图让它们用不同的家目录，恐怕不仅不会解决问题，反而可能会更混乱。 所以这里存在本质上的矛盾：所有软件的所有依赖都被锁定和相互隔离的话，好处是省心，依赖都是开发者预期的版本，自己写的程序随便起名也不会被意外调用，坏处是用不上自己喜欢和熟悉的版本，家目录中的数据文件可能不支持不同版本的程序读写，以 daemon 形式存在的服务可能无法工作（因为 client 和 server 版本不一致，例如 git clone 时 git 自己的 ssh 版本可能无法连上 control master）。更高层的应用程序可能还好，对于底层的各种基础工具（git vim curl less ssh 等），看来想实现不同版本共存确实有难度。

GitHub 发布了 fine-grained personal access tokens。以前这个问题很难解决：你和别人在一台服务器上合作，你们希望这台机器有权限读写某几个 GitHub 私有仓库。 1. 某个人在这台机器上创建一个 SSH key 并添加到自己的 GitHub 账号，坏处是合作者可以访问他的所有私有仓库了。 2. 某个人创建一个 personal access token 并放在这台机器上，坏处同上，因为 personal access token 不能按 repo 设置权限，只能允许读写所有私有仓库。 3. 为每个仓库创建一个 deploy key，坏处是要管理很多个不同的 deploy key，执行各种 git 命令时都要选择正确的那个 key，很不方便。（GitHub 不允许任何 deploy key 相同） 这个新功能就是给 2 加上了细粒度权限设置，一个 personal access token 最多可以拥有 50 个仓库的权限。可惜不能为每个仓库分别设置不同的权限，目前只支持指定一堆仓库，再指定对所有这些仓库都拥有什么权限。 https://github.blog/2022-10-18-introducing-fine-grained-personal-access-tokens-for-github/