把闰秒平均分到附近的一段时间内，这种做法叫做 Leap Smear
Leap Smear 对时间产生的偏差远小于一般计时误差要求，所以依赖时间戳的程序不会遇到问题。

不介意用命令行，推荐试试开源的 mutool 。

这篇文章还有一个问题，明明 AlpineLinux 官方 Community 仓库里提供了 py3-matplotlib 和 py3-pandas 之类常见的软件包，却偏偏还要用 pip 源代码编译。

如果是 mysql 新手的话，我觉得可以跳过 mysql，试试 xsv 这个工具，它能直接处理 csv 数据。
csv 体积大的话，可以用 xz/zstd 压缩一下。

漏洞？很多。
这个方案必须完全信任运营商：1 ）不会被动嗅探你的 http 流量； 2 ）不会伪造 IP 主动探测你的服务； 3 ）不会乱改接入端的 IP 地址。
否则：1 ）以违背用户协议之名，禁掉你的网络； 2 ）伪造你的身份，访问你的网络； 3 ）让你连不通自己的网络。

非常不推荐多个设备共用同一份密钥，一旦一个设备遗失或泄漏，所有服务器+客户端都要换密钥。
其实你需要的只是集中管理一份 authorized_keys 文件，然后写一个脚本来同步到所有服务器。

我没折腾过中文录入，因为没什么需求，所以一直用系统自带的中文输入法（ Android 除外）。但是因为写代码，学用了 dvorak 布局，这个学习的过程很痛苦。
不过我猜从五笔到仓颉的转换，估计比从 qwerty 到 dvorak 更痛苦。我大概用了一个多月的时间才能在用 dvorak 时不会错按 qwerty 的键，半年多才追上 qwerty 的速度。到现在 qwerty 已经完全生疏，录入速度已经降到不足 15 wpm 了。
英文比中文有一点方便的地方：即使操作系统不支持 dvorak，还可以用一个可编程键盘，在硬件层面做转换。
等哪天有兴趣了，我也想学一下仓颉之类的输入法。

没有。
如果楼主看了日志都没注意到音频在编码时被重采样了的话，只能麻烦楼主先自行学习一下数字音频和流媒体的基本概念，再和其他人继续讨论了。

[声音相对原视频无损] 的两种简单做法，1 ）使用无损压缩算法来二次编码，2 ）复制原有音频流。如果想用有损压缩二次编码的话，算一下 hash 看有没有信息损失，或者算一下 SNR 看损失了多少。

EOF

@WesleyNZ 你的第一张截图里只能看出 Input #0 的码率是 1102 kb/s，但是实际的音频需要看 Stream #0:1 和 Stream #0:2 的码率。

@WesleyNZ #4 很难确定两个不同算法的有损压缩之间转换，会损失多少信息。
题外话，44.1/48 kHz 16 bit 的音频，在有损压缩码率 240 kbps 以上时，就很难听出它与原始音频的差异了，更何况楼主用的是 24 kHz 的音频。如果真的在意这部分的差异的话，就应该全程使用无损压缩算法。

楼主是否正确判读了源音频的规格？
根据 vorbis (Xiph) 官方编码器的设定，最高质量 q10 的码率是 500kbit/s，但 OP 说源文件音频的码率是 1061 kbps，是不是在哪个地方搞错了？

当学校的学位论文只有 Word 模板时，还得自己造轮子改模板，这活比写公式插表格要复杂得多^2 。

GnuCash，但它没有同步功能。有空的话，我想造个轮子…

ssh+tmux，配置好自动登陆后，一点也不麻烦，也不用担心安全问题。

我觉得这个帖子的一个失败的地方，是它没有提到如何获取这个 app 。如果不是楼上有人说 iOS 没有中文的话，我不会想到去 app store 找。
PS: 以 Money Manger 365 目前的功能与完成度来看，我不太可能换记账软件。举些例子，功能上，它不支持资产类账户>资产类账户的转账（如：公交卡充值），账户没有层级关系；完成度上，界面设计有很多不符合逻辑的地方（特别是数字键盘），添加完第一笔交易后就看到数字精度不对的 bug 。

1 、目前为止没有严重的安全事故。是的，服务器的权限很高；
2 、根据新闻 "ZeroTier 2.0 Status" ，下一个大版本会实现 Root Server Decentralization，应该能做到不依赖它的服务器来组网。

分析系统卡顿：
✔ 任务管理器
✖ Windows Performance Recorder

你不小心开了 Language Bar 。
Settings > Devices > Typing > Advanced keyboard settings 里，取消 Use the desktop language bar when it's available

#2
你的设想是在密码管理工具的基础上，再提供一层保护，即使密码管理工具发生信息泄露，也能保护密码安全。
但是用 AES-CTR 模式加密是一个严重问题，如果不用随机的初始向量 /值，它加密的效果相当于给明文 xor 一个*固定*的随机数据。一旦多个密文泄露，就可以根据密文推算出明文的 xor 关系。如果还知道或推测出一个明文的话，所有的密文都能及其简单地算出对应的明文。

示例，用 password 为密码：
加密 123456 的结果是 0ef3e887bea1，明密文异或为 3fc1dbb38b97 ；
加密 m2DaUG 的结果是 52f39fd2ded0，明密文异或为 3fc1dbb38b97 ；
看出问题了吗？破译密文根本就不用算 AES 。

TL;DR: 这工具无法在密码管理软件发生泄露的前提下，保护密码的安全。