选择chaos这个词是因为~~实在很难找到一个更合适的词来形容这儿了……
最近 Apple 的一系列更新中的一项新的安全特性是 iCloud 的 Advanced Data Protection， 大概看了一下还是挺有意思的。
Read more...上回用 beancount 来手工记账是 2018 年的事，当时想要这么做的原因是贵厂的 Waze Carpool 项目当时并没有提供非常方便理解的记账系统，因此结合每月的对账单和 Waze 记录的数据来统计一下相关的数据，同时也把手中的现金一类没有对账单的小额资金给管起来。 后来又逐渐加入了一些其他的类似 PayPal 之类的付款记录，但是随着疫情的发展，到 2020 年初的时候已经不再有新的记录，慢慢也就把记账的事情给搁置下来了。
今年出于计算个税的需要，我又重新开始了记账。最初的想法是只把工资单的自动导入做好， 但后来想到既然 #来都来了 索性就把相关的解析全都做了好了。
Read more...今天无意中看了一眼服务器日志，结果发现了一些奇怪的消息：
warning: unknown[122.168.199.151]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
warning: unknown[176.8.89.240]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
warning: unknown[185.232.21.42]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
warning: unknown[206.217.216.13]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
warning: unknown[220.196.249.145]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
warning: unknown[5.253.204.74]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
warning: unknown[70.45.212.49]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
warning: unknown[93.177.73.82]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
warning: unknown[93.177.75.66]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
这里的 UGFzc3dvcmQ6 是什么呢？从直觉上看似乎是个 base64 编码的字符串。解码试试看，果然：
echo "UGFzc3dvcmQ6" | base64 --decode
Password:
这是个 Postfix 特有的特性，为了防止不慎在日志中写下用户的密码，它记录的是 SASL 库发给客户端的消息而不是用户名。
Read more...qsort_r(3)First introduced in Research Unix V3 and eventually standardized as part of C Standard Library as of ANSI/ISO C89, qsort(3) provided an abstract interface where programmers can perform sort operation over an array of objects, by supplying a pointer to that array, the total number of the member objects, the size of individual member object, as well as a compare function. The compare function is expected to take two parameters, both pointers to a member object, and it shall return a negative number, 0, or a positive number, if the first object is considered smaller, equal, or greater respectively.
Read more...今天 Warner 改了一段注释，我于是学到了一些新的 犀利而无用的知识，在这记一笔。
当从 BIOS 引导时，假如是使用 FreeBSD 的 boot manager（写入VBR的boot0或boot0sio），
该 boot manager 实现了一个菜单，因为这个菜单的原因，实现串口异步通讯的代码就塞不下了，
于是 boot0sio 会调用 BIOS int 14h 去初始化串口。
然而 int 14h 提供的接口是1981年的设计（IBM 5150的BIOS是1981年4月24日发表的，
当时只有 8 kB），用来表达波特率的只有3个bit，这3 bit作为波特率除数表的索引值，
该表在1981年写死成了：1047, 768, 384, 192, 96, 48, 24, 12，因此最高的波特率就是
115200 / 12 = 9600。
由于 9600 还是比较慢（每秒只能传1200字节），因此现时的 BIOS / EFI 往往默认将串口波特率设为
115200，然而 FreeBSD 的 boot0sio 在引导时仍然会一上来就把串口波特率设为 9600，
解决方法是干脆不要用 boot0sio 而是使用 BIOS 提供的 Console Redirect 功能，
或是在编译时将 BOOT_COMCONSOLE_SPEED 设置为 0。
我们现在所说的 TCP 协议通常是指 1981 年 9 月 发表的 RFC 793 和一系列后续 RFC 定义的协议，其主体定义距今已经超过 40 年了（当然如果细究下去的话， 第一份正式的文档是 RFC 675， 而 RFC 793 本身也是针对一年前的 RFC 761 的修正，不过大部分实现者使用的基础依然是 RFC 793）。
于本月18日发布的 RFC 9293 把过去四十几年针对 TCP 协议的各种修补全部合订到了一起，一次性地替代了 RFC 879 The TCP Maximum Segment Size and Related Topics、 RFC 2873 TCP Processing of the IPv4 Precedence Field、 RFC 6093 On the Implementation of the TCP Urgent Mechanism、 RFC 6429 TCP Sender Clarification for Persist Condition、 RFC 6528 Defending against Sequence Number Attacks、 RFC 6691 TCP Options and Maximum Segment Size (MSS)、 和主体 RFC 793 TRANSMISSION CONTROL PROTOCOL， 此外它整体替换了 RFC 1122 Requirements for Internet Hosts – Communication Layers 中关于 TCP 的全部内容。
Read more...很久以前在 macOS 上配置了一次，然后具体怎么配给忘了一个干净，所以这次写一个作弊条。
Read more...Telegram 最近宣布了其订阅付费计划。 说起来我也不是特别信任其安全/隐私方面的特性(*)，不过作为一个跨平台即时通讯软件来说， 其在不同平台上的功能基本上做到了完全一致，并且在这个礼崩乐坏 的时代，能够在不同平台上都做到不狂吃CPU/内存，在不同平台上的界面行为上高度一致， 并且完全没有各种令人抓狂的智障设计（举例来说：随便干什么事情都弄个二维码还非让你扫描一下借此获得摄像头权限、 多机登录时以手机为主并且时不时就得再扫描一次二维码、完全无法回溯的会话引用、 没头没脑地给一条「有人@你」的通知，却无法迅速定位到消息等等），并且公开客户端源代码以便第三方进行代码审计， 确实是十分难得的。
Read more...有些环境中，SSH 服务器可能无法从 Internet 直接访问（例如，SSH 服务器可能使用的是一个私有 IP 地址，或是 Internet 服务提供商没有提供 IPv6 服务，而 SSH 服务器只提供 IPv6 服务）。
考虑到 SSH 已经进行了相互认证（连接时客户端会验证服务器的公钥是否与已知公钥，例如 ~/.ssh/known_hosts，
或是通过 DNSsec 发布的 SSHFP RR 匹配；服务器端则会验证用户是否能证明自己拥有与授权公钥对应的私钥），
因此比较常见的解决方法便是使用 VPN、在防火墙上穿孔，或是使用代理服务器。
由于 SSH 自身也提供了许多转发功能，因此如果中间的跳板服务器也提供 SSH 服务， 便可以使用这些跳转服务器直接作为代理服务器来用。与前面那些传统方法相比， 这样做的优点是避免了安装额外的软件，也不需要特别指定端口。
Read more...https://www.FreeBSD.org/ 10.0-RELEASE 起，系统提供了一个最早由 NetApp 开发的使用处理器提供的虚拟化硬件支持 (目前是 Intel VT 和 AMD-V；针对 ARM 平台的支持也在 https://reviews.freebsd.org/D26976) 的虚拟化环境 https://wiki.freebsd.org/bhyve，这套虚拟化环境可以运行支持 VirtIO 规范的各种操作系统，并提供了 UEFI 支持。
这套环境提供了 PCI 直通(passthrough) 能力。通俗地说，PCI 直通是直接把某个或某些原本应该由宿主(host) 管理的 PCI 总线上的硬件交给虚拟机(guest)， 而非以虚拟化的方式由宿主系统代为管理的方式。 这样做的本意是绕过一层抽象来获得更好的性能，但有时也可以用来实现一些其他的目的。
FreeBSD 的 802.11 支持是 2003 年左右由 Sam Leffler 在引入 Atheros （现已被高通收购） 无线网卡支持时实现的。此后基于这套支持和公开文档，人们开发了一系列 Wi-Fi 驱动。 由于无线网络设备厂商已经在 Linux 驱动开发上进行了大量投资，目前 Linux 的 Wi-Fi 驱动较 FreeBSD 来说更为丰富。由于大部分此类驱动采取了 GPL / BSD 双许可证的授权， 因此比较理想的做法是实现 Linux 内核接口从而直接利用这些驱动，而不是从头重新开发一遍。
考虑到已经有了虚拟化环境的支持，另一种可行的做法便是直接运行一个精简版的 Linux，用它来管理
Wi-Fi 硬件，然后通过 virtnet 来把网络接到 FreeBSD 上面来用。这样一来这个 Linux
虚拟机便实际上承担了驱动的角色。目前这种做法已经加入了 port (net/wifibox) 并可通过 pkg
直接安装。