Posts

MIUI 系统会不定时的杀掉后台，罪魁祸首是 MiuiMemoryService。 杀后台的日志可以通过 logcat 查看： 1 logcat -b events | grep am_kill 通过 jadx-gui 反编译 service.jar framework.jar miui-service.jar miui-framework.jar 可以看到一些杀后台的逻辑，大部分可以通过 props 来控制。 添加下列 props mms 配置 mms 是 MiuiMemoryService 的缩写，这条是设置后台app数量上限，默认是100以下 1 persist.sys.mms.bg_apps_limit=1000 内存压力控制开关 1 2 3 persist.sys.spc.enabled=false persist.sys.spc.extra_free_enable=false persist.sys.spc.screenoff_kill_enable=false 禁用相机杀后台 修改 /system/system_ext/etc/camerabooster.json 字段 support.cam_boost_enable 设置为 false 如果没有的话看看 /odm/etc 下面没有 设置最大缓存进程数量 1 persist.device_config.activity_manager.max_cached_processes=1000 上述的 props 通过 magisk 模块修改即可。 也可以使用我制作好的模块: https://github.com/moonheart/moonheart.github.io/releases/download/miui-dont-kill-my-app/miui-dont-kill-my-app.1.2.zip

小米 12s 系列强制使用了新版控制中心。如果想要使用经典控制中心，可以按照如下方法修改。 用 MT 管理器找到 /system/product/overlay/DevicesOverlay.apk 并复制到内部存储如 Documents/DevicesOverlay.apk，通过 Arsc 编辑器打开 resources.arsc 文件。找到 com.miui.systemui.devices.overlay/integer/integer/force_use_control_panel，将值改为 0。 保存 apk。如果是 MIUI 14/Android 13，需要给 apk 签名才会被系统识别，使用 MT 管理器自带的签名工具即可。 最后通过 magisk 模块覆盖到系统。 下载地址：https://github.com/moonheart/NoControlPanel

下载 下载适用于您设备的 OpenWrt 固件 https://downloads.openwrt.org/releases/22.03.2/targets/x86/64/openwrt-22.03.2-x86-64-generic-ext4-combined-efi.img.gz 到 pve 主机执行，102 是 pve vm id 1 2 3 wget https://downloads.openwrt.org/releases/22.03.2/targets/x86/64/openwrt-22.03.2-x86-64-generic-ext4-combined.img.gz gunzip openwrt-22.03.2-x86-64-generic-ext4-combined.img.gz qm importdisk 102 openwrt-22.03.2-x86-64-generic-ext4-combined.img local-lvm 配置 网络配置 vim /etc/config/network 1 2 3 4 5 6 7 8 config interface 'lan' option device 'br-lan' option proto 'static' option ipaddr '192.168.50.64' option netmask '255.255.255.0' option ip6assign '60' option gateway '192.168.50.1' list dns '192.168.50.1' service network restart 扩容分区 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 opkg update opkg install block-mount e2fsprogs opkg update opkg install fdisk blkid vim # fdisk add partation sda3 mkfs....

一个月前，由于 docker 使用体验不佳，加上当时正好遇到一个项目需要使用 Linux 环境编译，但是 WSL/WSL2 有一些小问题一直没解决，就顺势从 Windows 11 切换到了 Linux。 选择哪个发行版？ 最开始我是准备用 ArchLinux 的，因为她的滚动更新策略我比较喜欢，以前使用过一个星期，由于一些电源管理的问题，本人太菜一直没修好，于是放弃了；公司服务器主要使用的是 Debian 9/10, 考虑到贴和工作环境，于是我选择了最新 的Debian 11。 遇到的问题 网卡不工作 安装 Debian 11 的时候，遇到一个哭笑不得的问题：Debian 11 的 ISO 自带的内核是 5.10, 当时安装的时候就发现不对劲，Wi-Fi 不工作；一番搜索之后才发现我的笔记本网卡是 MT7921，要从 5.15 内核才支持。又是搜索了一番，发现原来 Debian 也有滚动更新的版本，于是下载了 Debian sid 的镜像进行安装。 S3 睡眠失败 安装好用了一两天之后发现：睡眠了之后无法唤醒？点击睡眠之后无论是键盘鼠标还是电源键都无法唤醒，只能长按电源键断电。最开始以为是驱动问题，但是尝试各种方式无果，最后经过 TG 群的一位群友提醒，发现是因为设备太新，不支持 S3 睡眠，取而代之的是 Windows 的 新式待机：https://docs.microsoft.com/zh-cn/windows-hardware/design/device-experiences/modern-standby-vs-s3，经过一番搜索，找到了可用的方案：https://dev.to/epassaro/fix-suspend-issues-on-dell-7405-2-in-1-3l1b，通过修补 DSDT 来修复 S3 睡眠。 Windows 软件问题 在国内无法避免的要使用一些通讯软件，如 微信，钉钉，企业微信等等，根据我的经验，Wine 下运行的软件或多或少都会有些小问题，最后决定采用 VM 方案，在 VirtualBox 中安装了一个精简版的 Windows 7 来运行这些软件，分配了 2 GB 内存，平时使用基本够用。...

原文：https://github.com/proxy-wasm/spec/blob/master/docs/WebAssembly-in-Envoy.md 背景 截至 2019 年初，Envoy 是一个静态编译的二进制文件，其所有扩展都编译在构建时。这意味着提供自定义扩展的项目（例如 Istio）必须维护和分发自己的二进制文件，而不是使用官方和未修改的 Envoy 二进制文件。 对于无法控制其部署的项目，这甚至更成问题，因为任何更新和/或对扩展的错误修复需要构建新的二进制文件，生成版本，分发它，以及更重要的是，在生产中重新部署它。 这也意味着在部署的扩展和配置它们的控制平面之间经常存在版本差异。 解决方案 虽然部分问题可以使用动态可加载的 C++ 扩展来解决，但这在目前还不是一个可行的解决方案，因为，由于 Envoy 开发的速度很快，没有针对于扩展的稳定 ABI，甚至是 API，而且更新 Envoy 往往需要代码更改，这使得更新成为一个手动过程。 相反，我们决定通过使用带有稳定 ABI 的 WebAssembly 编写和交付 Envoy 扩展来解决这个问题，因为它带来了许多额外的好处(如下所述)。 什么是 WebAssembly？ WebAssembly (Wasm)是一种新兴的可执行代码的可移植二进制格式。代码在内存安全(针对主机)的沙箱中以接近本机的速度执行，具有明确定义的资源约束，以及用于与嵌入的主机环境(如代理)通信的 API。 优点 敏捷。 扩展可以在运行时直接从控制平面传递和重新加载。这意味着不仅每个人都可以使用正式版本和未经修改的代理版本来加载自定义扩展，而且任何错误修复和/或更新都可以在运行时推送和/或测试，而无需更新和/或重新部署新的二进制文件。 可靠性和隔离性。由于扩展部署在有资源约束的沙箱中，因此它们可能会崩溃和/或泄漏内存，而不会导致整个代理关闭。此外，可以限制 CPU 和内存的使用。 安全。由于扩展被部署在一个沙箱中，沙箱中有明确定义的用于与代理进行通信的 API，因此它们具有访问权限，并且只能修改有限数量的连接和/或请求属性。此外，由于代理协调这种交互，它可以隐藏或清理扩展中的敏感信息(例如 “Authorization” 和 “Cookie” HTTP 头，或客户端的 IP 地址)。 多样性。超过30种编程语言可以编译成 WebAssembly 模块，允许所有背景的开发人员(c，Go，Rust，Java，TypeScript 等)用自己选择的语言编写 Proxy-Wasm 扩展。 可维护性。 由于扩展是使用标准库编写的，独立于代理的代码库，我们可以提供一个稳定的 ABI。 便携性。 由于主机环境和扩展之间的接口是与代理无关的，因此使用 Proxy-Wasm 编写的扩展可以在各种代理中执行，例如 Envoy、NGINX、ATS，甚至可以在 gRPC 库中执行(假设它们都实现了标准)。 缺点 由于需要启动许多虚拟机，每个虚拟机都有自己的内存块，因此内存使用率较高 由于需要在沙箱内外复制大量数据，扩展转码负载的性能较低。 与 cpu 相关的扩展的性能较低。与本机代码相比，预计放慢速度小于2倍。...