访问 Maven 的下载页面：https://maven.apache.org/download.cgi （可能需要梯子）
点击 Link 下载 Binary 版本即可。此处我们下载的文件中包含了可执行文件。完成下载之后我们需要将这些文件放到一个较为固定的位置，然后设置环境变量以便于我们在命令行环境能够正常访问这些脚本。
Maven 具有包管理器的作用，这类应用在国内都面 GFW 的问题，因此需要需要将 Maven 接入代理以便其能够正常下载以来资源。设置方式是在当前用户目录下 .m2/settings.xml 文件（如果没有此文件需要手动创建），并在此文件中添加以下内容：
1 | <settings> |
注意将其中的地址和端口设置替换成你自己的 HTTP 代理的地址和端口。
最近开发 C++ 的程序在链接阶段发生了一个 LTO 相关的错误。链接时优化（Link Time Optimization, LTO） 是一种编译优化技术，旨在通过在链接阶段执行全程序优化来提升代码性能和减少二进制文件大小。其主要原理是在链接阶段而不是在编译阶段进行更高级的优化，允许跨文件的全局优化。LTO 的基本原理和过程是：
我遇到的错误信息中的管件一句是:
1 | attempt to add bitcode file after LTO (htons) |
可以看到错误信息提示我们链接系统试图在 LTO 优化之后添加 bitcode。并且在后面的括号中链接器提到了一个符号 htons，这是来自 libc 库的一个符号。基于的 https://github.com/emscripten-core/emscripten/issues/16836 这个链接中的启发，我发现了一个 LTO 优化可能面临的普遍性问题。这个问题是 LTO 会尝试移除一些它认为不需要的符号从而减少编译出来的程序的体积，但是这个判断可能会不准确。它可能将一些实际会被使用的符号删除。为了解决这个问题，我们可以为链接器指定链接输入，强制保留指定的符号以避免错误的移除。针对我遇到的情况，为链接器加上 -Wl,-u,htons 的配置即可解决问题。
Login
-Wl: 这个标志告诉编译器将接下来的选项传递给链接器（ld）。-Wl,option 是传递给链接器的标准方法。-u,symbol: 这个选项告诉链接器强制包含指定的符号 symbol。在这个情况下，-u,htons 和 -u,htonl 告诉链接器强制包含 htons 和 htonl 函数最近在 Unraid 升级 6.12.x 版本以后会偶发性的产生一个 Bug，其表现为 Unraid 网页无法打开（这里是指访问 Unraid IP 地址无法访问 Web 管理界面）。这个问题实际上是由于 Unraid 上的 Nginx 服务失去响应导致的。这种情况下我们只需要干掉 Nginx 进程并重启就可以了。
首先通过 ps -aux | grep nginx 找到 Nginx 主进程的 PID，然后通过 kill -9 <PID> 干掉进程。要再次启动 Nginx，可以运行
1 | cd /etc/rc.d/ |
注意通过 ./rc.nginx restart 在正常情况下可以重启 Nginx 服务，但是在 Nginx 处于无法响应的状态时，这个脚本无法杀死 Nginx 进程，必须要手动终止。
在 Ubuntu 中彻底删除一个用户涉及到几个步骤，不仅仅是删除用户，还可能包括删除与用户相关的数据。以下是步骤指南：
确保用户未登录: 在删除用户之前，最好确保该用户未登录。你可以使用 who 命令来检查哪些用户当前已登录。
1 | who |
删除用户: 使用 userdel 命令删除用户。如果你还希望删除用户的主目录和邮件池，可以使用 -r 选项。
1 | sudo userdel -r username |
其中，username 是你想删除的用户的用户名。
注意：-r 选项会删除用户的主目录（通常是 /home/username）。确保你已经备份了所有重要的数据！
检查文件系统: 即使删除了用户和其主目录，可能仍然在文件系统上遗留一些属于该用户的文件。你可以使用 find 命令来搜索这些文件：
1 | sudo find / -user username |
这将列出所有属于 username 的文件。根据你的需要，你可以手动删除这些文件或更改它们的所有权。
删除用户的 cron 作业: 如果用户配置了任何 cron 作业，你还需要手动删除它们。检查 /var/spool/cron/crontabs/username 是否存在，如果存在，删除它。
1 | sudo rm /var/spool/cron/crontabs/username |
其他服务或配置: 如果该用户有其他特定的配置，例如在 /etc/sudoers 中的条目或在其他服务中的特殊访问权限，你需要手动检查并删除它们。
请在进行任何删除操作之前确保备份所有重要数据。确保你明确知道正在执行的操作，避免意外删除重要文件或配置。
遇到这样一个蛋疼的问题，我有一台服务器，上面部署了一个 web 服务，同时我也想把这个服务器作为客户端连入一个 OpenVPN 虚拟网络，并且我希望服务器上的程序能够通过 OpenVPN 的网关来访问外部网络，这主要是为了隐藏服务器的身份。但是在 OpenVPN 连接之后，原有的 Web 服务将无法访问。通过调试分析可以法线，造成这一现象的原因是 Web 服务的响应包也被路由配置路由到 OpenVPN 的 tun0 接口中。这导致响应无法返回给原来的请求服务器。如何解决这个问题呢？
如果你在网络上搜索这类问题你会发现各种文章给出的方案一般都是为 OpenVPN 的配置文件添加 route-nopull 选项来阻止 OpenVPN 设置客户端路由，但是这会导致客户端的对外访问无法通过 VPN 进行。事实上，从 IP 路由的角度来看，如果我的服务器是 A，而某个访问 Web 服务的 IP 是 B，同时 B 也可能是 A 试图访问的外部的目标服务提供者。对传输层路由而言，A 给 B 的 Web 服务响应和 A 主动发往 B 的请求是无法区分的。从这个角度来看，要达成 inbound 和 outbound 流量分别路由似乎是不可能的。
但是其实我们有一个突破点：那就是 Web 服务总是在本机使用固定的端口和请求者通信，我们可以通过端口来区分 inbound 和 outbound 流量。首先我们输入下面的命令：
1 | iptables -t mangle -A OUTPUT -p tcp -m multiport --sports 80,443 -j MARK --set-mark 1 |
在这个命令中，我们会让路由表观察从本地的 80 和 443 端口发出的包，并给这些包打上一个特定的标签（--set-mark 1 的作用）。然后输入下面的命令：
1 | ip route add default via [gateway addr of eth0] dev eth0 table 100 |
这个命令会创建一个新的路由表 table 100，然后在这个表中加入一个默认路由，将流量送往原有的网关。然后再运行下面的命令：
1 | ip rule add fwmark 1 table 100 |
这个命令会让带有标记 1 的包使用 table 100 路由表进行路由。运行完上面的配置后，web 服务就可以正常访问呢了。
以上方法是在 ChatGPT 的协助下摸索出来的，我的提问是：
如何通过 iptables 或者 route 命令，让访问 80 与 443 端口的包使用 tun0 接口，而访问其他端口的包使用 eth0 接口？
GPT 的回答是
可以使用iptables和route命令结合起来实现此目的。具体操作如下：
首先需要添加一条规则，将访问80和443端口的包标记为一个特定的标记值（比如"1"），使用tun0接口发送出去。iptables规则如下：
1 | iptables -t mangle -A OUTPUT -p tcp -m multiport --dports 80,443 -j MARK --set-mark 1 |
接着需要添加一条规则，将标记为"1"的包使用tun0接口发送出去。route命令如下：
1 | ip route add default dev tun0 table 100 |
最后需要添加一条规则，将所有未被标记的包使用eth0接口发送出去。route命令如下：
1 | ip route add default dev eth0 |
以上三个步骤分别实现了：将访问80和443端口的包标记，并使用tun0接口发送出去；将标记为"1"的包使用tun0接口发送出去；将所有未被标记的包使用eth0接口发送出去。这样就实现了访问80和443端口的包使用tun0接口，访问其他端口的包使用eth0接口的效果。
在之前的文章SSH隧道:访问翻墙服务器的临时性手段 的时候介绍了一种使用 SSH 隧道进行端口映射，进而进行手动的流量混淆的技术。就稳定性来说这个方案是经受了考验的。在过去几年里，无论任何时候 SSH 隧道都是能够提供稳定可靠的链接的。不过，SSH 隧道的性能是一个问题。根据 Stackoverflow 上的 这个问题下的回答 来说：“当你通过TCP隧道传输TCP时，性能问题就会出现，因为您有两个层执行自适应纠正”。在这篇文章里面我介绍一个较新的方案。
新的方案设计一个新的工具：spiped(github)。spiped是一种安全的、轻量级的加密通信工具，可用于在不安全的网络中传输敏感数据。它的设计目标是提供简单、易于配置和使用的加密通信，而不需要复杂的密钥管理或公钥基础设施。spiped使用对称密钥加密算法，可以在客户端和服务器之间建立加密通道。它可以用于保护各种类型的数据流，包括SSH、Telnet、HTTP和SMTP等协议。spiped的另一个优点是它可以在不同的平台上使用，包括Linux、FreeBSD、OpenBSD和Windows等操作系统。
spiped 的使用非常简单。在 Ubuntu 上可以通过 apt 来安装。也可以自行编译。在完成安装以后，我们首先进入服务端，运行下面的命令生成一个秘钥：
1 | dd if=/dev/urandom bs=32 count=1 of=keyfile |
其中 keyfile 是生成的秘钥文件，注意将其保管到合适的位置。然后用下面的服务启动 spiped 服务端服务：
1 | spiped -d -s '[0.0.0.0]:8025' -t '[127.0.0.1]:25' -k /path/to/keyfile |
注意，不同于 ssh 使用同一个 TCP 链接来走所有的隧道流量，spiped 会为每个流创建一个独立的 TCP 链接。因此在做代理中介使用时，spiped 可能会需要创建数量较多的 TCP 链接。spiped 的 -n 配置可以指定最大链接数量，这个数值默认是 100，对于代理应用来说这是不够的。你可以将其设置为 10000。
其中 -s 后的地址是服务端的监听地址，-t 的转发的目标地址，-d 表示将加密的流量从 -s 后的地址解密后发往 -t 后面的地址。这里我们可以填写 Shadowsocks 服务监听的地址。注意 Host 可以保持成 127.0.0.1 的形式。这样，我们可以在防火墙中把 Shadowssocks 的公网监听端口关闭，仅允许从加密隧道访问，这样可以提升安全性。
上面的命令在输入后会自动进入 Daemon 模式运行。
然后我们来到客户端（一般是跳板机），将服务端生成的秘钥文件下载到客户端，运行
1 | spiped -e -s '[127.0.0.1]:25' -t $SERVERNAME:8025 -k /path/to/keyfile |
其中 $SERVERNAME 是服务端的 IP 地址。注意用 [] 包裹的形式来填写。如果这里说的客户端也是 Shadowsocks 的机器，那么这里的源地址（-s 后的地址）可以写 127.0.0.1，但是如果是跳板机，那么应该写成 0.0.0.0。
在上面的设置中，方括号内可以写入 IPv6 地址，但是注意 IPv6 的全网段监听地址就不能写 [0.0.0.0] 了，而是要写 [::]。
客户端的程序也是会自动进入 Daemon 模式运行。
完成设置之后，访问客户端（跳板机）的 25 端口就相当于直接访问服务器的 25 端口。
请注意，spiped：
dd if=/dev/urandom bs=32 count=1是你的好朋友。）/dev/urandom的强熵。（确保您的内核的随机数生成器在引导时被种子化！）Proxifier 是一款网络工具软件，可以帮助用户通过代理服务器进行网络访问，实现匿名化、翻墙、加速等功能。支持多种代理协议，规则管理，流量监控和日志记录等功能，提高网络连接的灵活性和智能化。注意 Proxifier 本身并不是一个代理软件，也不是一个 VPN 软件，其作用是控制其他其他软件访问代理的方式。
上一篇文章我提到了可以试用 Proxifier 来解决通过 Shadowsocks 代理访问呢 ChatGPT 频繁出现 Something Went Wrong 的问题，在本文中我们来展开讲一下具体的做法。
Proxifier 的官方网站是 https://www.proxifier.com/，其正版价格较贵，约 40 美元。不过，较早的 2.x 版本存在破解版。读者可以根据自己的经济状况来选择。
如同开头提到，Proxifer 本身不是一个代理程序，读者应该自己提前准备好代理。这些代理中，无论是 Shadowsocks、V2Ray 还是其他常见的代理程序，都会在客户端本地重建一个 Socks5 代理，这一般都可以在代理客户端程序的配置或者服务器设置中看到。下图给出的是 Shadowsocks-NG 客户端在 macOS 中的系统配置，可以看到程序在本地 (localhost) 的 1086 端口创建了一个 Socks5 代理。
这个代理会被进一步转成 http 代理，从而被浏览器使用，这个转换过程是导致 ChatGPT 链接不稳定的元凶。接下来我们要使用 Proxifier 让 ChatGPT 直接使用 Socks5 代理。
我们以知乎上这篇文章为范本简要讲一下设置过程。首先我们需要将现有代理软件提供的 Socks5 服务告知 Proxifier，这通过添加代理服务器实现。
注意一般各种代理软件在本地创建的代理都是无需验证的，我们可以取消验证启用。输入设置之后，可以点击检查确认设置是否正确。
为了让 ChatGPT 的访问能够通过 Proxifier 访问代理，我们需要配置 Proxifier 的代理规则。
添加代理规则的页面如下：
我们有两种方法引导 ChatGPT 的网络访问：
chat.openai.com; challenges.cloudflare.com; *.openai.com; 即可。事实上，因为 Proxifier 能够全局性地处理所有网络访问，因此，第二种方法对于使用 ChatGPT Desktop 的用户来说同样有效。下图是完整代理规则。
至此我们就完成了设置，你可能需要重启浏览器才能能让 Proxifier 成功地引导 ChatGPT 的流量。
update at 2023.4.27：
Github 上有人做了一个开源的油猴脚本 KeepChatGPT 可以解决这个问题。在浏览器上这个脚本可以正常使用，但是注入到客户端时（尽管内部仍然是一个浏览器）会出现错误。
update at 2023.4.12：
在 Windows 上这套方法存在一定的问题。可能的原因是 Proxifier 的代理权限有时候会被 Shadowsocks 客户端，也就是 Privoxy 争抢。
由于国情原因我们使用使用 ChatGPT 需要使用各种形式的代理，这时我们肯能会发现在与 ChatGPT 对话的过程中可能会出现下面的错误：
这种错误一般在我们再让网页空闲一段时间（通常是一分钟）后再次提问时出现。当然，去 OpenAI 的帮助中心是不会搜到什么有用的信息的。如果你去检索这个问题，你能得到的最好答案是在出现这个页面之后刷新页面，然后回到对话窗口继续对话即可。但是刷新后如果再次出现空闲窗口的情况，这个问题会反复出现，因此你在对话中就不得不反复地刷新页面，再加上每次页面重载你都需要去勾选 Cloudflare 的机器人验证框，这就会极大程度上拖慢我们的速度，影响产品体验。
这个问题是否可能是由于我翻墙访问导致的呢？我使用的翻墙软件是 Shadowsocks，经过一番搜索，一个 Github Issue 的讨论给了我灵感。
尽管讨论的题目和 ChatGPT 没有直接关系，但是这个回复提到，Shadowsocks 在构建代理管道时，会在客户端使用 Privoxy 来讲 Socks5 代理转换成 http 代理，进而被浏览器使用。Privoxy 的配置中包含了 Socket 连接时长方面的控制。于是我查看了我本地的 Shadowsocks 使用的 Privoxy 的配置文件，这个文件在 MacOS 中位于 /Users/lena/Library/Application Support/ShadowsocksX-NG/privoxy.config 文件。
1 | toggle 1 |
可以看到 keep-alive-timeout 和 socket-timeout 这两个选项设定的超时时间都比较低。我做了下面两个尝试：
至此，我也不想和 Privoxy 纠缠下去，既然问题出在 Socks5 代理转 Http 代理的环节，我们可以使用 Proxifier 这个软件直接使用 Shadowsocks 提供的 Socks5 代理，就可以很好地解决这个问题。
Proxifier 的教程网上非常多，我就不在这篇文章里赘述了。
Proxifier 的使用参加我的文章：如何使用 Proxifier 来进行流量代理控制
若想进阶 Power User，一款趁手的自动化工具必不可少，在移动设备上，iOS 快捷指令和 Android 平台的 Tasker 是个中翘楚，少数派已有数不清的文章介绍。对三星用户来说，其实还有另一个选择：Bixby 日常程序。它最初亮相于 2019 年的 Galaxy S10 系列发布会上，经过两年的迭代，易用性和功能性都有长足进步，覆盖了大部分日常情景。
四月底，三星旗下的另一款系统级增强工具 Good Lock 迎来家族新成员 Routine +，为 Bixby 日常程序添加了多项新特性，玩法更丰富的同时，也让它在生产力方面迈出一大步。这结论缘何而来，是否略显夸张，读罢本文，你应该会有答案。
鉴于 Bixby 日常程序的默认入口较深，也鲜有文章介绍，切入新功能前，我们不妨先熟悉下本体。如果你还不知道这是什么，请前往「设置 → 高级功能」启用「Bixby 日常程序」选项。为了方便日后查找和使用，我建议同时将其图标添加至应用程序屏幕。下拉通知栏，编辑按钮，还可以将开关添加至快捷面板，随时启用或停用。
打开 Bixby 日常程序，三星已经为我们准备了数款预设的自动化流程，如在家时更改声音模式和快捷方式，连接耳机时读出特定应用的通知，运动时播放音乐并启用定位服务……点击即可预览具体操作，快速编辑或保存。滑至主界面底部，我们还能通过清晨、驾驶、睡前等推荐的生活情景，按提示一步步创建最适合自己的日常程序，掌握它的基础用法。
与可编程能力更强的 Tasker 相比，我更愿意将 Bixby 日常程序称为本地版 IFTTT：图形化用户界面，没有高昂的学习成本，逻辑也是最直观的「如果满足触发条件则执行指定操作」。作为一款预置应用，Bixby 日常程序主要覆盖 Android 系统功能，操作的分类和图标与「设置」一致，支持 Samsung DeX 等独占特性，还能与三星自家设备联动，控制智能家居，开启无线耳机的主动式降噪等。
最简单的日常程序，也可能为我们省下不少时间。拿基础的「打开特定应用程序」触发条件来说，观影时启用杜比全景声、阅读时进入护眼模式、办公时解除屏幕方向锁定等常用操作，都可以交给 Bixby 日常程序处理。如果你始终开启眼睛舒适度保护，也可以设置为打开设计工具时还原屏幕色彩；在启用自适应旋转的平板电脑上，改成打开部分未适配手机应用时保持纵向显示更合适。最关键的是找准手机使用过程中的痛点，因地制宜。
将多种操作组合，较为复杂的工作流程也不在话下，如：
当然，触发条件也不局限于一个，给我们更多施展空间。检测到睡眠状态且处于夜间，则开启免打扰模式并降低屏幕亮度；若是还忘记充电，再采取其它措施节省电量，以防关键时刻手机掉线。这种情况下，当日常程序结束时，就不必撤销所做的改动了。上课时段，若在教学区连接至校园 Wi-Fi，调整手机为静音，启动专注模式；想对自己更狠一点，「如果工作日打开摸鱼 App，则关闭摸鱼 App」的日常程序或许会有奇效。
Bixby 日常程序的最大软肋，是仅支持预设动作。坐拥自定义 Bixby 快捷命令、读取 NFC 标签、过滤信息关键词等潜力巨大的触发条件，却不支持变量传递；「进入网站」操作离跳转 URL Scheme 只差一步，却必须以 http:// 开头，扩展性远不足以满足进阶用户的需求。
入门以上而专业未满，让 Bixby 日常程序的定位略显尴尬。即将介绍的 Routine +，则在维持易用性的前提下，一定程度上弥补了这个缺陷，我们不妨在下文见识一番。
Good Lock 是三星官方推出的系统定制工具，由功能各异的模块组成。从诞生初期的系统界面美化，到逐步添加的诸多实用特性，现已成为集定制主题、导航手势、通知过滤、多任务处理于一身的全能选手，是所有三星用户都值得安装的利器。如果你未曾听说，不妨阅读少数派的这两篇文章：
近期上线的 Routine + 模块，顾名思义，是 Bixby 日常程序专精，目前支持基于 Android 11 的 One UI 3.1。具体来说，它提供三种新触发条件和三种新操作，配合原有功能，实现更强大且精准的自动化流程。
安装 Routine + 后，再次打开 Bixby 日常程序，你会发现触发条件最底部多出了相应分类，可以覆写指纹、按钮和 S Pen 的硬件设置。如遇熊孩子抢手机，兰花指一伸，直接进入与主系统隔离的儿童空间；S Pen 顺时针画个圈，设备便开始播放音乐，顺便启动番茄计时。按钮操作不妨与其它条件结合，例如上文提到的乘车码，改成在地铁站双击侧面按钮时打开，既方便又不用担心误触发。
Bixby 日常程序的操作中，同样新增了 Routine + 类别，分别为触摸宏、模拟方向键和读出文字。后两者的应用面似乎较窄，需要方向键辅助的触屏应用本就少见，文字转语音也算不上高频操作。我暂时能想到的，只有用 S Pen 隔空玩贪吃蛇比较方便，以及收到催稿信息时能知会一声 TACTICAL NUKE INCOMING 了。触摸宏的画风则大不相同，有必要另起几段详细说明。
触摸宏的作用，是记录我们的点击、滑动等操作的时间、位置和次序，保存后随时调用，有点类似 Windows 平台的按键精灵。创建触摸宏时，需要先抵达目标界面，然后点击浮动工具栏的录制按钮，执行希望模拟的流程，测试成功后，点击保存即可。为规避 App 响应速度等因素带来的影响，我建议留出一定的容错空间；如果途中不慎误操作，可以回溯历史，依次删除上一步。
不用说，Bixby 日常程序自然能与 Bixby 快捷命令配合使用，触摸宏的出现，得以了却我长久以来的夙愿：用 Bixby 控制米家设备。提前录制好动作，创建相应的日常程序，指定一则合适的口令，就可以指挥 Bixby 替我们跑腿了。当然，不设置快捷命令，直接对 Bixby 说「启动 XX 日常程序」就行，Android 11 的电源菜单也远比这高效，但生活还是需要一点仪式感的，不是么？
触摸宏的真正价值在于重复的机械化行为，打开应用时点击跳过广告、接近公司时钉钉打卡、快速擦亮闲鱼宝贝、商城抢购热门商品、手机游戏挂机等高频操作，都可以用它轻松搞定。另一方面，导航手势也在触控操作范围内，进入其它 App 不影响触摸宏的录制。因此，只要图标的相对位置不变，一键签到多款 App 的日常程序并无理论障碍。实际运用中，需要保证 App 不会更新改版，可行性不高。
纵有诸多限制，我仍将触摸宏视为能引发质变的新功能，跳出有限的预设命令，模拟脚本也难以完成的繁琐操作，极大地拓宽了 Bixby 日常程序的应用边界。由于以「录制」而非「编写」的形式呈现，使用门槛维持在较低水平，缺乏编程知识的普通用户也能掌握。如果在后续更新中，能引入简单的变量传递和识别文字点击特性，Bixby 日常程序将真正踏入专业范畴。
最后，有必要在这里提醒各位读者，借助触摸宏自动化抢券、挂机等行为有几率被判定为使用作弊脚本，导致账户遭到限制甚至封禁，还请谨慎设置，不要滥用。
可能是由于此前的操作都比较简单，Bixby 日常程序并不支持同步，在设备间迁移数据成了麻烦事。新操作之余，Routine + 也带来了日常程序的导入与导出功能，分为二维码和 JSON 两种形式，与朋友分享自己的得意之作或者备份到云端都很方便。不过，导出的日常程序会丢失自定义图标信息，触摸宏也无法完整保留，必须在新设备上重新录制，期待进一步完善。
目前来说，如果你有足够的动手能力和编程知识，Tasker 无疑更加强大，指纹解锁和 S Pen 手势等硬件触发条件也能通过 Logcat Entry 功能实现，可以说是 Bixby 日常程序的上位替代。
但对大多数普通三星用户来说，系统自带的 Bixby 日常程序无需另行付费，上手简单，直观易懂，功能也足以满足日常所需，是自动化工具入门的不二之选。
Routine + 和触摸宏的出现，赋予了 Bixby 日常程序更多可能，让它有能力满足一部分生产力需求。同时，得益于友好的录制方式以及对三星自家特性的充分利用，Bixby 日常程序实现了相较于 Tasker 的差异化亮点。两年间的多次改版与更新，证明了三星对它的重视程度，期待 Bixby 日常程序能维持现有的低门槛，加入更多专业功能，成为 One UI 不可不知的「必备应用」。
