大致还记得可以写个字典猜
纯暴力几乎不可能

持续审核配合可复现构建, 审核完毕才会进入核心系统仓库
需要快速迭代的用户程序用 SELinux 等技术套沙箱, 尽可能缩小受击面

其实这个需求你找 AI 就行了

#!/bin/sh
STRING="$1"
FILE="$2"
if [ -n $STRING ] && [ -e $FILE ]; then
sed "s/apple/$STRING/" "$FILE" > new"$FILE"
else
echo "Usage: $0 \$STRING \$FILE"
fi

#!/bin/bash
STRING="$1"
FILE="$2"
REPLACEMENT="$3"
if [ -n $STRING ] && [ -e $FILE ]; then
sed "s/$STRING/$REPLACEMENT/" "$FILE" > new"$FILE"
else
echo "Usage: $0 \$STRING \$FILE \$REPLACEMENT"
fi

#!/bin/bash
STRING="$1"
FILE="$2"
if [ -n $STRING ] && [ -e $FILE ]; then
sed "s/apple/newapple/" "$FILE" > new"$FILE"
else
echo "Usage: $0 \$STRING \$FILE"
fi

国内不可能平替

主要压力在服务器后端, 能用厂商提供的设施就不要自己做

心跳包的发送频率应当根据网络环境自动调整

设备向服务端发起一个连接, 并定时发送心跳包维持这个连接
通知到达后服务器通过这个连接向设备推送, 如果设备不在线就放进缓冲区等待设备上线

一般操作系统会提供一个统一的服务处理所有通知, 例如 Android 的谷歌 FCM 和 iOS 的苹果 APNS

FCM 在国内可以直连, 但没有优化线路所以效果一般, 没有其他谷歌服务使用也麻烦, 所以国产都做了自己的推送服务, 但也因此出现了碎片化, App 需要给不同厂商单独接入

APNS 要求 App 把推送信息交给苹果, 苹果直接把通知推到手机, FCM 则支持让推送唤醒 App, App 去获取实际内容并生成通知; 前者更省电, 但功能有限, 例如 Signal 这种端到端加密聊天因为服务端无法解密而无法通过 APNS 推送消息内容

---

客户端轮询也可以, 但想消除延迟就需要快速唤醒所以很耗电, 一般不建议使用

微信在国内会自己挂一个推送服务并将 FCM 作为备用推送渠道, 国外则会直接用 FCM

可以给 WG 出站包打标签, 然后再按标签走不同的路由表

@BaymaxK #2 苹果没有提供驱动, Asahi 是逆向出来的

目前什么都装不了, Asahi 只支持 M1 和 M2

打洞除了要建立 NAT 连接以外还要在防火墙上开洞, 在 IPv6 环境下 UPnP 的作用是实现后者
一般建议手动开洞, UPnP 很容易被滥用

reddit 为了快速盈利大幅降低了用户体验, 高质量用户都开始逃离了, 能成功才是怪事

@whenov #7 你动的地方被改了才会出问题, userChrome 不是直接替换

国产滥堆配置其实是便宜了软件商, 最后的结果是用户厂商双输

如果说的是手机那他想的应该是会像国产那样开始堆配置满足 App
实际应该是不会的, 苹果的占有率摆在那里, iPhone 都卡那就算小白也多半会认为是 App 的问题, 根本没有压力