前言 前面我们 基于MDPC-my-dream-proxy-client 很容易实现了一个 hy2 翻墙客户端(壳) 再来试试 sing-box 和 anytls 协议 面向GPT开发 开发人员: Hermes 对接 mimo-v2.5 学习知识 把 G站/SagerNet/sing-box 按最新的 release tag clone一份本地代码. 不要放tmp, 未来要进一步分析. 是长期任务. 分析 sing-box 的使用方法, 配置文件用什么格式 用怎样的命令形式启动 sing-box 内核 有没有测试 配置文件 是否合法的 sing-box 命令? 这是 sing-box 的文档 https://sing-box.sagernet.org/ 对照 你的分析, 进行对比验证 把你的分析结论保存为 .md 文件 我要使用 sing-box 的 anytls 协议 你分析源码找到应该如何使用, 包括服务端 和 客户端 另存为一份 .md 文件 开发 - 基本功能 基于 /home/ubuntu/my-dream-proxy-client/ 这个项目进行开发 你先学习一下这个项目 现在要继续 开发支持 sing-box 内核 支持 anytls 协议 参考以下分析报告 ~/repos/sing-box/ANALYSIS.md — 项目分析（配置格式、启动命令等） ~/repos/sing-box/ANYTLS.md — AnyTLS 使用指南 先不要实施编码, 先和我讨论设计思路 sing-box 也是独立实例 API 端口 18280 sing-box 配置文件 多文件同目录 启动命令 sing-box run -C confdir/ 确定每个配置文件中只有一个json块, 比如, inbound.json 里面只有 inbound , outbound.json 里面只有 outbound 类似 xray 的处理方式, 对每个 json 配置文件, 都有一个HTML页面. 先只实现JSON文本编辑框, 表单以后再设计. 测试和调试 略 功能类的测试, 先让Agent自己搭环境测试, 遍历各种组合环境. 最后再由人上手. UI设计, 操作逻辑, 这些由人设计, 由人测试, 体验, 提改进要求. 开发 - outbound表单 之前 xray 的 outbound 只有 1个 proxy 和 1 个 direct 这次我加点功能, 最终的 outbound 页面是这样的 开发 - route 预设模板 route页面增加2个预设模板 一个是 “geosite-geolocation-!cn” 走 proxy, 默认 direct 一个是 “geosite-cn” “geoip-cn” “ip_is_private” 走 direct, 默认走 proxy 开发 - dns 预设模板 dns 页面增加2个预设模板 一个是 “rule_set”: “geosite-geolocation-!cn” 让 “google” 解析, 默认 “system” 解析 一个是 “rule_set”: “geosite-cn” 让 "system"解析, 默认 “google” 解析 Github G站/crazypeace/my-dream-proxy-client ======== 后记 连操作手册都是让Agent写的. 先让Agent以新用户的身份, 做一个完整的测试, 从 release 页面下载 zip 包开始. 然后让TA把刚才的测试过程总结成一份操作手册. G站/crazypeace/my-dream-proxy-client/blob/main/README.md#my-dream-proxy-client-使用手册-配合sing-box内核 1 个帖子 - 1 位参与者 阅读完整话题
前言 前面我们实现了一个 配合xray内核 reality协议 的 极简翻墙客户端(壳) MDPC-my-dream-proxy-client 如果我们想 配合 Hysteria 内核呢? (只为了简单演示, 所以只处理自签证书的情况) 分析 根据my-dream-proxy-client项目(下称MDPC)的设计, MDPC的配置文件参数为: listen: port: files-dir: core-start: core-test: log: 我们可以填上 hy2 对应的信息, 如: listen: "127.0.0.1" port: "18180" files-dir: "./bin/hy2/" core-start: "bin/hy2/hysteria client -c bin/hy2/config.yaml" core-test: "" log: "" 这样后端就好了. 是不是很简单! 接下来就是创造前端的HTML, 用来生成hy2客户端配置文件的yaml文本 可以先从简单的YAML文本编辑框作为基础功能. 然后再加表单. 开发过程 hermes 对接 mimo-v2.5-pro 基于 极简翻墙客户端(壳) 开发 配合 Hysteria 内核 支持Hysteria2协议 自签证书指定证书指纹pinSHA256 Github G站/crazypeace/my-dream-proxy-client 使用方法 见项目 README.md G站/crazypeace/my-dream-proxy-client/blob/main/README.md#my-dream-proxy-client-使用手册-配合hysteria内核 ======== 后记 本次开发由 hermes 对接 mimo-v2.5-pro 1 个帖子 - 1 位参与者 阅读完整话题
近日，编号为 CVE-2025-10263 的严重安全漏洞正式对外披露，被确认影响多款 Arm 架构 CPU 内核，涉及范围涵盖最新与多代早期产品。该漏洞被评为“严重”等级，攻击者可利用特定内存权限变更过程中的时序条件，在受影响系统上实现本地权限提升。 根据公开信息，问题根源在于：在执行 TLB 失效（TLBI）操作时，相关内存访问的完成情况并不能由 TLBI 的完成所严格保证。 在某些场景下，这一行为可能导致对本应由更高异常级别（如更高特权级）拥有的资源进行非法写入，从而成为攻击者提升权限的手段。 该漏洞虽然在 2025 年就已分配编号，但直到 2026 年 6 月才正式公开披露。 Arm 在其安全公告中给出了受影响内核清单，范围相当广泛。 其中包括最新的 C1-Ultra 和 C1-Premium，以及此前面向服务器和数据中心的 Neoverse V3、V3AE、V2、V1、N2、N1 等系列内核。 同时，大量面向高性能移动和客户端设备的 Cortex 系列也在影响范围之内，包括 Cortex-X925、Cortex-X4、Cortex-X3、Cortex-X2、Cortex-X1 与 X1C，以及 Cortex-A710、Cortex-A78、A78AE、A78C、Cortex-A77、Cortex-A76 与 A76AE 等型号。 针对该问题，Arm 给出的软件层面缓解建议是：任何执行适用于一级或一级加二级页表信息的 TLB 失效操作的软件，都必须额外执行一次 TLBI 操作并配合 DSB（Data Synchronization Barrier，数据同步屏障），以确保相关内存访问在权限变更前被正确完成。 相应的技术细节及推荐缓解方案已记录在 Arm 公布的安全公告中。 Linux 社区已经在第一时间响应，并为内核提供了补丁实现上述缓解措施。 来自 Arm 的开发者今日向 Linux 内核邮件列表提交了补丁系列，通过对相关代码路径进行调整，确保在执行受影响场景下的 TLB 失效时增加必要的 TLBI 与 DSB，从而降低漏洞被利用的风险。 该补丁目前已面向主线内核进行提交，后续预期将通过各大发行版更新向用户下发。 除了 Arm 官方列出的处理器外，NVIDIA 也确认其最新的 Olympus 内核同样受到 CVE-2025-10263 的影响。 NVIDIA 在另一份提交给 Linux 内核的补丁中指出，其新一代 NVIDIA Vera CPU 所采用的 Olympus 内核存在相同问题，并通过后续补丁引入对应的缓解措施，以与上游通用修复保持一致。 在实际风险层面，由于该漏洞可在特定条件下实现向高特权级资源的写入操作，理论上能够为攻击者提供本地权限提升途径，因此被评为“严重”级别并不意外。 不过，目前并未有大规模实战利用案例被公开报道，业界主要聚焦在尽快完成内核和系统软件层面的修复，以防止后续可能出现的攻击场景。 对于 Linux 用户和服务器运营方而言，当前最关键的行动是关注各大发行版即将提供的内核更新，并尽快完成升级部署。 在此之前，云服务提供商、大型数据中心以及基于受影响 Arm 平台的设备厂商，也需要评估自身硬件所使用的处理器型号与工作负载场景，及时跟进 Arm 与 Linux 社区发布的缓解建议。 查看评论
Brave 是一款基于 Chromium 内核的开源浏览器，以强大的隐私保护和广告拦截功能著称。它默认启用 Shields 功能，可有效阻挡广告、跟踪器和指纹识别，同时提供更快的浏览速度和更低的资源占用。 Brave 还长期支持 MC2（Manifest V2）扩展 ，为用户提供了更灵活的扩展兼容性。 2026 年 6 月初，Brave 正式发布了 Brave Origin 版本,（59.9$买断制）。该版本保留了 Brave 的 核心优势 的基础上， 移除或禁用的功能 （这些功能在普通版中默认可用）包括： Leo AI 助手 Brave News（新闻） Playlist（播放列表） Rewards 系统（同时禁用浏览器内 Brave 广告） Speedreader（速度阅读器） VPN Wallet（加密货币钱包，同时禁用 Web3 域名） Talk（通话功能） Tor 私有窗口 Wayback Machine 集成 Web Discovery Project 部分统计数据和遥测（如日常使用 ping、崩溃日志、P3A 隐私保护分析）等 Origin 因移除多余组件，启动更快、资源占用更低、界面更简洁，提供更纯粹的浏览器体验。 但是目前可以通过 macOS 系统级配置文件 （.mobileconfig）和 Windows JSON 策略 的方式达到近似的效果。 效果图如下： macOS 使用方法 将下方 XML 内容复制并保存为 Brave-Policies.mobileconfig 文件。 双击文件安装配置描述文件。 安装完成后重启 Brave 浏览器。 打开 brave://policy/ 确认策略生效。 XML <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>PayloadVersion</key> <integer>1</integer> <key>PayloadScope</key> <string>System</string> <key>PayloadType</key> <string>Configuration</string> <key>PayloadRemovalDisallowed</key> <false/> <key>PayloadUUID</key> <string>e143b891-3398-48f9-bee1-54d3b6db44b3</string> <key>PayloadDisplayName</key> <string>Brave Policies</string> <key>PayloadDescription</key> <string>Brave Browser system-level policies</string> <key>PayloadIdentifier</key> <string>com.brave.Browser</string> <key>PayloadContent</key> <array> <dict> <key>PayloadIdentifier</key> <string>com.brave.Browser</string> <key>PayloadType</key> <string>com.brave.Browser</string> <key>PayloadUUID</key> <string>88032831-5301-41ad-8231-10efa9d67ab3</string> <key>PayloadVersion</key> <integer>1</integer> <key>PayloadEnabled</key> <true/> <key>TabSearchActivated</key> <false/> <key>GlobalMediaControlsEnabled</key> <false/> <key>TorDisabled</key> <true/> <key>BraveRewardsDisabled</key> <true/> <key>BraveWalletDisabled</key> <true/> <key>BraveVPNDisabled</key> <true/> <key>BraveAIChatEnabled</key> <false/> <key>BraveSidebarAvailable</key> <false/> <key>BraveShoppingEnabled</key> <false/> <key>BraveSponsorshipsEnabled</key> <false/> <key>BraveTalkDisabled</key> <true/> <key>IPFSEnabled</key> <false/> <key>DefaultLocalFontsSetting</key> <integer>3</integer> <key>DefaultSensorsSetting</key> <integer>3</integer> <key>DefaultSerialGuardSetting</key> <integer>2</integer> <key>CloudReportingEnabled</key> <false/> <key>DriveDisabled</key> <true/> <key>PasswordSharingEnabled</key> <false/> <key>QuickAnswersEnabled</key> <false/> <key>SafeBrowsingExtendedReportingEnabled</key> <false/> <key>SafeBrowsingSurveysEnabled</key> <false/> <key>SafeBrowsingDeepScanningEnabled</key> <false/> <key>DeviceActivityHeartbeatEnabled</key> <false/> <key>DeviceMetricsReportingEnabled</key> <false/> <key>HeartbeatEnabled</key> <false/> <key>LogUploadEnabled</key> <false/> <key>ReportDeviceActivityTimes</key> <false/> <key>ReportDeviceAppInfo</key> <false/> <key>ReportDeviceSystemInfo</key> <false/> <key>ReportDeviceUsers</key> <false/> <key>AlternateErrorPagesEnabled</key> <false/> <key>AutofillCreditCardEnabled</key> <false/> <key>BackgroundModeEnabled</key> <false/> <key>BrowserGuestModeEnabled</key> <true/> <key>BrowserSignin</key> <integer>0</integer> <key>BuiltInDnsClientEnabled</key> <false/> <key>DefaultBrowserSettingEnabled</key> <false/> <key>DefaultBrowserSettingNotificationAllowed</key> <false/> <key>MetricsReportingEnabled</key> <false/> <key>ParcelTrackingEnabled</key> <false/> <key>RelatedWebsiteSetsEnabled</key> <false/> <key>ShoppingListEnabled</key> <false/> </dict> </array> </dict> </plist> Windows 使用方法（JSON 策略，与 macOS 配置一致） 创建文件夹路径（推荐使用以下路径之一）： C:\ProgramData\BraveSoftware\Brave-Browser\Policies\Managed\ 或 C:\Program Files\BraveSoftware\Brave-Browser\Application\Policies\Managed\ 在 Managed 目录下新建文件 brave_policy.json，复制下方完整 JSON 内容并保存。 重启 Brave 浏览器。 打开 brave://policy/ 页面确认所有策略已生效。 JSON { "policies": { "TabSearchActivated": false, "GlobalMediaControlsEnabled": false, "TorDisabled": true, "BraveRewardsDisabled": true, "BraveWalletDisabled": true, "BraveVPNDisabled": true, "BraveAIChatEnabled": false, "BraveSidebarAvailable": false, "BraveShoppingEnabled": false, "BraveSponsorshipsEnabled": false, "BraveTalkDisabled": true, "IPFSEnabled": false, "DefaultLocalFontsSetting": 3, "DefaultSensorsSetting": 3, "DefaultSerialGuardSetting": 2, "CloudReportingEnabled": false, "DriveDisabled": true, "PasswordSharingEnabled": false, "QuickAnswersEnabled": false, "SafeBrowsingExtendedReportingEnabled": false, "SafeBrowsingSurveysEnabled": false, "SafeBrowsingDeepScanningEnabled": false, "DeviceActivityHeartbeatEnabled": false, "DeviceMetricsReportingEnabled": false, "HeartbeatEnabled": false, "LogUploadEnabled": false, "ReportDeviceActivityTimes": false, "ReportDeviceAppInfo": false, "ReportDeviceSystemInfo": false, "ReportDeviceUsers": false, "AlternateErrorPagesEnabled": false, "AutofillCreditCardEnabled": false, "BackgroundModeEnabled": false, "BrowserGuestModeEnabled": true, "BrowserSignin": 0, "BuiltInDnsClientEnabled": false, "DefaultBrowserSettingEnabled": false, "DefaultBrowserSettingNotificationAllowed": false, "MetricsReportingEnabled": false, "ParcelTrackingEnabled": false, "RelatedWebsiteSetsEnabled": false, "ShoppingListEnabled": false } } 注意 ： 配置后若需移除，删除对应配置文件并重启浏览器即可。 Windows 用户也可使用 Group Policy 编辑器 + 官方 ADMX 模板进行管理。 Linux 用户可 免费 使用 Brave Origin 。 始终从官网下载最新版 Brave 浏览器。 欢迎大家测试并反馈效果。如果有其他平台需求或需要调整策略，欢迎留言。支持正版的朋友也可直接购买 Brave Origin（支持多设备激活），也可组团拼车。 AI 编写提示 ：本帖内容由 AI 辅助生成和优化，旨在提供准确、清晰的配置指导。所有配置文件均基于公开的 Brave 企业策略文档整理，使用前请自行验证，并在必要时备份重要数据。 1 个帖子 - 1 位参与者 阅读完整话题
前言 你可能在使用一个没有可用的翻墙客户端的平台. 你可能觉得目前能找到的翻墙客户端太大, 太笨重了, 你用不到那么多功能, 用不到那么多协议. 你可能看到了某个翻墙内核新出了一个协议, 而你手里的翻墙客户端还没有支持. 你可能就是手痒, 想自己搓轮子. 那么你可以做一个你自己的 翻墙客户端 思路 考虑到翻墙内核都是用go语言, 那么我们的翻墙客户端也用go. 这样, 内核能跑的平台, 客户端也能跑. 客户端的GUI界面部分, 考虑到覆盖尽量广的平台, 以及方便用户自己修改调整界面元素, 用HTML. 探索 以 xray 翻墙内核 + reality协议 为例 启动一个hermes, 对接 mimo-v2.5. 设计工作从这样的对话开启 我们来分析一个翻墙客户端(壳)的设计方案. 基于xray内核 考虑到覆盖尽可能广的平台, 翻墙客户端的后端基于 go 语言 考虑到方便用户自定义界面, 翻墙客户端的界面基于 HTML 你觉得如何? 很多细节和反复拉扯的部分在此省略. 只记录一些最终保留的重要设计思路 前后端功能设计 后端只负责替换配置文件 和 启/停翻墙内核 前端将配置文件的全量文本发给后端 前后端API设计 配置文件操作 — /api/files GET /api/files GET /api/files/{filename} PUT /api/files/{filename} DELETE /api/files/{filename} 进程操作 — /api/core GET /api/core/status POST /api/core/start POST /api/core/stop POST /api/core/test 设计前端时, 为了简化, 预设以下一些约束条件 后端的配置文件只会有这一些, 只会少, 不会多. 01-log.json # log 02-dns.json # dns 配置 03-router.json # routing rules 04-inbounds.json # 入站监听 05-outbounds.json # 出站代理 06-api.json # commander API 只实现最基本的核心功能作为演示, 只需要使用这些API GET /api/files/{filename} → { content } PUT /api/files/{filename} ← { content } (创建或替换) POST /api/xray/start POST /api/xray/stop 前端HTML的使用方式 后端不提供HTTP文件路由 前端HTML文件可以由单独的HTTP服务来支撑, 如 python -m http.server 前端HTML文件也可以直接用浏览器打开 前端HTML页面思路 前端为每个配置文件生成一个HTML页面文件 01-log.json 02-dns.json 03-router.json 04-inbounds.json 05-outbounds.json 06-api.json 前端的页面设计 对于不是 outbound 的页面, 只有直接编辑JSON 的功能, 没有表单 所以它们应该是几乎一样, 只有文件名不一样. 前端outbound页面的设计 转JSON • 行为: 表单 → 生成 JSON → 填入下方 JSON 编辑器（不保存） 直接保存 • 行为: 表单 → 生成 JSON → 填入下方 JSON 编辑器 → 发送给后端 保存 • 行为: JSON 编辑器的内容 → 发送给后端 后端设计1个yaml格式的配置文件 listen: 127.0.0.1 port: 18080 files-dir: ./bin/xray/ core-start: “./bin/xray/xray run -confdir ./bin/xray/” core-test: “./bin/xray/xray run -confdir ./bin/xray/ -test” log: “” 上传 Github G站/crazypeace/my-dream-proxy-client 对, 我取了一个特别的名字 my-dream-proxy-client 但其实功能特别简陋, 只是演示了最基本的工作原理. 哈哈! 使用方法 见 Github 项目 README.md G站/crazypeace/my-dream-proxy-client/blob/main/README.md#my-dream-proxy-client-使用手册-配合xray内核 具体开发过程 hermes 对接 mimo-v2.5 开发翻墙客户端(壳) 基于 xray 内核 reality 协议 1 个帖子 - 1 位参与者 阅读完整话题
Linux 内核 7.1-rc7 于美国东部时间 6 月 7 日晚间发布，尽管改动规模在发布周期后期依然偏大，但已较前一候选版本有所收敛，内核维护者林纳斯·托瓦兹表示当前进展让他有信心在下周正式发布 Linux 7.1 稳定版，如无突发问题，预计发布时间为 6 月 14 日。 与往常版本相比，7.1 整体补丁量偏高，主要原因在于近年来 AI/大模型编码代理使用增多，推高了补丁提交数量，不过最近几周的变更趋势正在逐步趋缓。 在本周合入 7.1-rc7 的更新中，较受关注的一项变更是出于持续的安全考量，禁用了 AMD 为 ROCm CRIU 开发的一项 DRM ioctl 接口，以降低相关安全风险。 此外，在 AMD 处理器支持方面，Linux 7.1-rc7 进一步补充了更多 Zen 6 处理器型号，用于完善新一代 CPU 的识别支持。 托瓦兹在当日发布的 7.1-rc7 公告中指出，本次候选版本“谈不上小”，但各个候选版本的规模确实在逐步缩小，其中 GPU 相关修复是当前最大的一块变更，网络子系统修复量也紧随其后。 除此之外，本次还包含了一些架构层面的修复（主要与 KVM 相关）、若干随机驱动修复、部分文件系统改动以及针对特殊配置的构建问题修复等，他表示目前并未发现会拖延整个发布周期的“可怕问题”。 托瓦兹同时提到，自己接下来会有一些时间安排上的出行因素，但并不足以影响 Linux 7.1 的正常发布节奏，因此暂不考虑调整发布时间表。 他表示，按照目前状况来看，rc7 应该会是该版本的最后一个候选版本，但仍提醒开发者和用户在接下来一周积极测试 rc7，以便及时发现可能影响正式版的潜在问题。 如果后续测试过程中没有重大问题暴露，Linux 7.1 最终稳定版预计将在下周正式发布。 对于这一即将到来的内核版本，其新增功能与重要改动可参考已有的 Linux 7.1 特性概览，其中涵盖了本次版本在多个子系统和硬件支持方面的主要更新亮点。 了解更多： https://lore.kernel.org/lkml/CAHk-=whAmWe+G5_jtrraOx0JAu4ZcpWvLAsFqH3N5wWkVrCbww@mail.gmail.com/T/#u 查看评论
环境 ：家宽（电信） + Windows 11 + Fclash (TUN 模式) + mihomo 内核 节点 ：Reality (vless + xtls-rprx-vision)，服务商给的入口 IP 185.218.x.x ，端口 45579 访问海外网站 几十分钟稳定 → 突然断几分钟 timeout → 不知道啥时候自动恢复的 → 继续外网 → 再断 。已经换了一个 IP 还是这样。。。同一个 IP 几分钟内能从 100% 通变 100% 丢（连续 ping 8 次看到的）；关掉 Fclash 几分钟再等个一段时间，就又好了。。。 目前手上有一个比较脏的订阅节点，倒是能一直连，没有断，现在拿来当中转了，勉强苟活着，另外就是开手机移动热点给电脑也是没问题的。有大佬能指点下方向吗🥲🥲🥲
环境 ：家宽（电信） + Windows 11 + Fclash (TUN 模式) + mihomo 内核 节点 ：Reality (vless + xtls-rprx-vision)，服务商给的入口 IP 185.218.x.x ，端口 45579 访问海外网站 几十分钟稳定 → 突然断几分钟 timeout → 不知道啥时候自动恢复的 → 继续外网 → 再断 。已经换了一个 IP 还是这样。。。同一个 IP 几分钟内能从 100% 通变 100% 丢（连续 ping 8 次看到的）；关掉 Fclash 几分钟再等个一段时间，就又好了。。。 目前手上有一个比较脏的订阅节点，倒是能一直连，没有断，现在拿来当中转了，勉强苟活着，另外就是开手机移动热点给电脑也是没问题的。有大佬能指点下方向吗🥲🥲🥲
环境 ：家宽（电信） + Windows 11 + Fclash (TUN 模式) + mihomo 内核 节点 ：Reality (vless + xtls-rprx-vision)，服务商给的入口 IP 185.218.x.x ，端口 45579 访问海外网站 几十分钟稳定 → 突然断几分钟 timeout → 不知道啥时候自动恢复的 → 继续外网 → 再断 。已经换了一个 IP 还是这样。。。同一个 IP 几分钟内能从 100% 通变 100% 丢（连续 ping 8 次看到的）；关掉 Fclash 几分钟再等个一段时间，就又好了。。。 目前手上有一个比较脏的订阅节点，倒是能一直连，没有断，现在拿来当中转了，勉强苟活着，另外就是开手机移动热点给电脑也是没问题的。有大佬能指点下方向吗🥲🥲🥲
NetProxy — Android 系统级透明代理 基于 sing-box 内核，简单高效的 Root 透明代理方案。 特性 TPROXY / REDIRECT 自动检测 支持 TCP / UDP / DNS 全覆盖 图形化配置 sing-box 全部能力 无需手写 JSON 配置 订阅管理 / 分应用代理 支持多订阅与应用级分流 热点共享支持 可共享代理网络 内置 Zashboard 面板 + CLI 命令行 同时支持图形界面与命令行管理 兼容 Magisk / KernelSU / APatch 集成 IPSET LKM 驱动 提升规则匹配与分流性能 获取方式 GitHub： https://github.com/Fanju6/NetProxy-Magisk Google Play： https://play.google.com/store/apps/details?id=com.fanjv.netproxy Telegram： https://t.me/NetProxy_Magisk 简介 NetProxy 是一个 Android 系统级透明代理方案，基于 sing-box 内核实现。 目标是提供开箱即用的代理能力，减少手动配置复杂度，同时保留完整可扩展性与高性能转发能力。
NetProxy — Android 系统级透明代理 基于 sing-box 内核，简单高效的 Root 透明代理方案。 特性 TPROXY / REDIRECT 自动检测 支持 TCP / UDP / DNS 全覆盖 图形化配置 sing-box 全部能力 无需手写 JSON 配置 订阅管理 / 分应用代理 支持多订阅与应用级分流 热点共享支持 可共享代理网络 内置 Zashboard 面板 + CLI 命令行 同时支持图形界面与命令行管理 兼容 Magisk / KernelSU / APatch 集成 IPSET LKM 驱动 提升规则匹配与分流性能 获取方式 GitHub： https://github.com/Fanju6/NetProxy-Magisk Google Play： https://play.google.com/store/apps/details?id=com.fanjv.netproxy Telegram： https://t.me/NetProxy_Magisk 简介 NetProxy 是一个 Android 系统级透明代理方案，基于 sing-box 内核实现。 目标是提供开箱即用的代理能力，减少手动配置复杂度，同时保留完整可扩展性与高性能转发能力。
NetProxy — Android 系统级透明代理 基于 sing-box 内核，简单高效的 Root 透明代理方案。 特性 TPROXY / REDIRECT 自动检测 支持 TCP / UDP / DNS 全覆盖 图形化配置 sing-box 全部能力 无需手写 JSON 配置 订阅管理 / 分应用代理 支持多订阅与应用级分流 热点共享支持 可共享代理网络 内置 Zashboard 面板 + CLI 命令行 同时支持图形界面与命令行管理 兼容 Magisk / KernelSU / APatch 集成 IPSET LKM 驱动 提升规则匹配与分流性能 获取方式 GitHub： https://github.com/Fanju6/NetProxy-Magisk Google Play： https://play.google.com/store/apps/details?id=com.fanjv.netproxy Telegram： https://t.me/NetProxy_Magisk 简介 NetProxy 是一个 Android 系统级透明代理方案，基于 sing-box 内核实现。 目标是提供开箱即用的代理能力，减少手动配置复杂度，同时保留完整可扩展性与高性能转发能力。
IT之家 6 月 5 日消息，科技媒体 phoronix 昨日（6 月 4 日）发布博文，报道称 Linux 7.2 主线内核将合并新补丁， 有望首次支持苹果 M3 系列设备启动，覆盖 iMac、MacBook Air 和 MacBook Pro 等机型。 报道称 Linux 7.2 内核合并窗口预估 6 月中旬启动，开发者 Sven Peter 昨日更新了针对该内核的 Apple SoC 设备树更新，其中一组补丁由 Janne Grunau 提供，用于建立 Apple M3 设备树文件。 按照补丁说明，这批设备树只提供最小化启动能力，现阶段足以把 Linux 内核引导到简单串口控制台，但还远不足以支撑终端用户日常使用。 IT之家援引博文介绍，当前列入支持范围的设备包括： iMac（24 英寸，M3，2023 年） MacBook Air（13 英寸，M3，2024 年） MacBook Air（15 英寸，M3，2024 年） MacBook Pro（14 英寸，M3，2023 年） 设备树覆盖的硬件模块主要有 CPU 核心、中断控制器、电源状态、看门狗、串口、引脚控制器、I2C 和启动帧缓冲。 笔记本机型额外加入键盘 LED 背光所需的 PWM 控制器，iMac 与 14 英寸 MacBook Pro 还补上基于 I2C 的 Apple cd321x USB Type-C 端口控制器。 该媒体也指出苹果 M3 芯片设备想要日常体验 Linux，仍有很长的路要走，Apple M2 到 M3 之间又存在较大的架构变化，尤其图形支持仍需大量工作。
虽然不理解但是体感就是比edge要快，不知道为啥，不都是使用的Chrome的内核吗？edge的要更旧一些的原因吗？ 2 个帖子 - 2 位参与者 阅读完整话题
啥浏览器都试了 都是卡在l站logo加载那里 感觉应该是代码不兼容低版本内核了 ios16.3 是不是没救了… 4 个帖子 - 4 位参与者 阅读完整话题
经历数周混乱之后，Linux内核开发终于趋于稳定。Linux创始人Linus Torvalds本周日确认，Linux 7.1第六个候选版本(RC6)的规模已经恢复正常，这意味着下周发布的版本可能成为正式版发布前的最后一个候选版本。过去几周，Linux内核开发社区经历了一段动荡时期，先是托瓦兹抱怨贡献者使用AI工具报告漏洞却不提供修复方案，紧接着又不得不呼吁开发者停止在开发周期后期提交不必要的修复代码。 Torvalds在本周的声明中表示，第六个候选版本的规模虽然小于RC5，但仍不算很小，这主要归因于AI工具的使用。不过由于更新规模已趋于正常，整个开发周期有望按照常规节奏完成。本次更新涵盖了大量驱动程序修改，涉及GPU、网络、USB、串口、音频和SCSI等多个领域，同时还包括核心网络功能、自测试更新、架构修复、文件系统修复以及其他零散的修正。 在具体硬件支持方面，此次候选版本改进了对华硕ROG RAIKIRI II游戏手柄、GameSir Nova 2 Lite手柄和联想Go设备的支持。此外还修复了联想X12平板电脑处理器中一个较大的过度读取问题。随着7.1版本开发重回正常轨道，最终的候选版本预计将于下周发布，之后便会向公众推送稳定版本。 不过Torvalds建议用户等待各自Linux发行版推送更新，因为自行安装可能导致系统不稳定，操作过程也更为复杂，Arch和Fedora用户将成为首批收到更新的群体。 查看评论
IT之家 5 月 31 日消息，据科技媒体 Phoronix 今天报道，一批输入子系统修复补丁已提交到 Linux 7.1-rc6 内核，增添多款手柄支持。 据报道，本次更新中的 XPad 通用控制器驱动将新增华硕 ROG 雷切 2（IT之家注：Raikiri II）手柄支持。该手柄定价 160 美元（现汇率约合 1086 元人民币），配备 TMR 摇杆、双模式扳机键、微动按键，支持 USB-C、蓝牙、2.4G 三模连。提供实体开关，可在 PC 和 Xbox 模式之间切换。 同时，本次 XPad 更新还新增了小鸡 Nova 2 Lite 支持，该产品是一款无线手柄，售价约 30-35 美元（现汇率约合 203.6 - 237.5 元人民币）。由于本次更新仅涉及新增设备 ID， 因此风险较低 ， 适合直接并入 Linux 7.1 开发周期 ，无需等到几周后的 7.2 合并窗口。 此外，今天提交的输入子系统更新还对 Synaptics 触控板驱动进行调整，使联想 ThinkPad E490 的触控板能够以 RMI（Register Mapping Interface）模式运行。
IT之家 5 月 31 日消息，联芸科技在接受调研时披露，公司自主研发的首款 UFS 3.1 嵌入式主控芯片已成功导入国内核心客户，并在多家主流终端手机厂商处完成测试，进展顺利，预计将于 2026 年起正式贡献量产营收，同时公司正积极拓展更多终端手机厂商客户。 联芸科技方面明确表示，公司将嵌入式 UFS 主控芯片定位为继 SSD 主控后数据存储主控领域的第二增长曲线，依托 SSD 主控的技术积累与客户渠道，打造独立第三方嵌入式存储主控的核心竞争力。 此前在 4 月底的机构调研中，公司即透露该款 UFS 3.1 嵌入式主控芯片已量产出货。与此同时，UFS 2.2 与 UFS 4.1 产品的研发也在稳步推进中。 在企业级存储主控产品方面，联芸科技的企业级 PCIe 5.0 固态硬盘主控芯片已经进入量产测试阶段。该公司介绍，企业级 SSD 主控产品相较消费级产品技术壁垒更高、认证周期更长，单颗价值量提升显著，毛利率也有望较消费级产品进一步提升。2026 年，基于数据中心等高端场景下海量数据存储与高效读写需求，公司将重点推进 PCIe 5.0 企业级 SSD 主控芯片的研发及量产。 在更长远的研发规划方面，联芸科技此前公告的向特定对象发行 A 股股票募集资金总额不超过 20.62 亿元，用于“面向数据中心与智能终端的新一代数据存储主控芯片系列产品研发项目”。 该项目建设期为 5 年，具体将围绕企业级 PCIe Gen6 SSD 主控芯片、企业级 PCIe Gen7 SSD 主控芯片、消费级 PCIe Gen6 SSD 主控芯片、UFS 5.0 嵌入式存储主控芯片等展开技术攻关，重点突破超高速接口设计、高效能闪存管理等关键技术难题。从募资用途来看，企业级 PCIe Gen6 SSD 主控芯片拟投入 44,403.40 万元，企业级 PCIe Gen7 SSD 主控芯片拟投入 89,820.06 万元，消费级 PCIe Gen6 SSD 主控芯片拟投入 46,135.32 万元，UFS 5.0 嵌入式存储主控芯片拟投入 34,142.19 万元。 联芸科技还于 2026 年 CFMS | MemoryS 存储峰会上发布了全球首款消费级 PCIe Gen6 主控芯片 MAP2001，支持 28GB/s 的顺序读取速率，并已推出针对企业级推理服务器场景的 PCIe Gen6 主控 MAP2011 及面向 AI 手机等终端设备的 MAU3802 UFS 5.0 主控。 在技术与研发投入方面，联芸科技 2026 年将继续保持高强度研发投入，围绕低功耗 SoC 芯片、车规功能安全、高速接口技术等方向持续攻关，完善自主芯片设计平台，提升产品迭代效率与核心技术壁垒。公司相关负责人表示，将灵活调整研发节奏，根据市场与技术迭代情况先行投入自有资金推进前期研发，确保产品迭代顺利衔接。2025 年联芸科技研发投入金额为 5.03 亿元，同比增长 18.25%，研发投入占营业收入比例达到 37.88%。 IT之家注意到，财务数据显示 2025 年联芸科技实现营业总收入 13.27 亿元，同比增长 13.06%；归母净利润 1.42 亿元，同比增长 20.41%；扣非净利润 1.02 亿元，同比增长 130.43%。
最近在用 Rust 写一个 AI Agent 操作系统内核，叫 Agent OS 。37 个 crate ，1232 个测试，用 craft agent 都写了十几天。 不止一个朋友问过我：你为什么不先用 Python 快速搭个原型？先验证需求，等跑通了再用 Rust 重写。 以前我会觉得这是个好建议。但这次我拒绝了。 原因很简单：我在用 AI 编程的过程中，逐渐意识到一件事——在 AI 时代，MVP 那套"先简后优"的逻辑，前提已经不存在了。 传统 MVP 的核心假设是：简易实现和高质量实现之间有显著的成本差，先用低成本验证，验证通过再投入。这个在人写代码的时代是成立的——用 Python 写个原型 2 天，用 Rust 写生产级实现 2 周，差 10 倍，所以先做简易版合理。而且代码是你自己写的，你理解每一行，以后重构只是时间问题。 但现在你对 Cursor 说"用 localStorage 存数据"和说"用 PostgreSQL 加连接池和事务管理"，生成时间差不了几分钟。既然成本一样，为什么要做简易版？ 更要命的是第二点：AI 生成的代码是黑箱，你大概率没法有效重构。 去年帮一个朋友用 Cursor 做了个小工具的 MVP ，需求很简单，AI 几分钟就生成了能跑的代码。两周后他想加个功能，打开代码，完全看不懂。不是因为代码乱，而是他不知道 AI 为什么这样写。最后他选择让 Cursor 重写一遍，而不是在原有代码上改。 这就是问题所在。你以为"以后再优化"，但你连哪里需要优化都不知道，因为你从未理解过这段代码。 所以我做 Agent OS 的时候，做了一个在很多人看来反直觉的决定：每一个架构决策都自己做，AI 只负责执行。 选语言的时候，用 Python 或 TypeScript 写个 Agent 框架，AI 几小时就能生成一个看起来很完整的 MVP 。但我选了 Rust ，理由很具体：Agent 系统需要长期运行、需要内存安全、需要跨平台——这些需求第一天就是确定的，不会因为用户量上来了才变成需求。 设计原则也是。我定了"事件溯源"——每一次操作都记录，可以回溯和重放。这在 MVP 阶段看起来是多余的，但当你的 Agent 在凌晨 2 点做了个错误决策，你需要知道它为什么做了这个决策。这不是"以后再加"的事，因为你以后根本不知道要加在哪里。 测试也一样。1232 个测试，每个模块合并前必须通过。AI 帮我写了很多测试，但测什么、怎么测、边界条件是什么——这些是我决定的。AI 很擅长为自己的代码生成"能通过"的测试，这就像自己出题自己答，当然满分。 Andrej Karpathy 自己也承认过："代码超出了我的理解范围。当 AI 修不了一个 bug 时，我就让它随机改，直到错误消失。"这是 OpenAI 联合创始人说的，不是什么新手的窘境。 我的选择是不让代码超出我的理解范围。哪怕前期慢一点。 有人会说这样不是更慢了吗？前期确实更慢。但到现在，每个模块都可以独立修改而不影响其他模块。我知道这个系统的每一块是怎么工作的。 而那些用 AI 快速搭 MVP 的项目呢？ 63% 的开发者说调试 AI 生成代码花的时间比自己写还多。470 个 GitHub PR 的分析显示，AI 生成代码出现重大逻辑错误的概率是人写的 1.7 倍，安全漏洞概率是 2.74 倍。 AI 编程还带来了一种新的技术债，和传统的不一样。传统技术债你知道它在哪——那个 hack 、那个 TODO 、那个硬编码。AI 编程的技术债是隐形的。 一种叫理解债：代码能跑，测试全过，但没人能解释它为什么这样工作。调试一段你不理解的代码比调试自己写的慢 3 到 5 倍，而 AI 大幅增加了你代码库里"不是你写的"代码的比例。 一种叫同质债：不同公司、不同产品、不同需求的团队，用 AI 解决同一个问题会得到几乎一样的代码。AI 给你的是互联网上最受欢迎的解法，不是最适合你系统的解法。农业里叫单一栽培——高产但脆弱，一场病全军覆没。 还有一种叫归属债：开发者从代码的作者变成了策展人。出问题时第一反应不是理解原因，而是让 AI 重新生成。一位资深工程师说得很直接："AI 为当下而建，不为将来而建。它对自己生成的东西没有维护的利害关系。" 这几种债有个共同特点：你的仪表盘全是绿色的。Sprint 速度在涨，PR 合并更快，测试覆盖率 94%。一切看起来很好。直到有一天你需要改一个功能，发现没有任何人知道该从哪里改起。 所以我的想法是：在 AI 编程时代，别再用 MVP 思维了。直接一步到位。 不是说花三个月做完美产品再上线。AI 已经把构建高质量实现的时间成本压到和简易版差不多了。关键是你的思维方式要从"先简后优"变成"一步到位"——对 AI 描述你要的终态而不是最简态，架构决策由人来做而不是交给 AI ，关键路径必须是人类彻底理解的。 真正的快不是写得快，是改得快、修得快、迭代得快。如果你连自己的代码都不理解，你根本快不起来。 AI 编程的本质是黑箱。你可以让黑箱帮你写代码，但你不能让黑箱帮你做决策。你没法重构一个你不理解的东西。
最近在用 Rust 写一个 AI Agent 操作系统内核，叫 Agent OS 。37 个 crate ，1232 个测试，用 craft agent 都写了十几天。 不止一个朋友问过我：你为什么不先用 Python 快速搭个原型？先验证需求，等跑通了再用 Rust 重写。 以前我会觉得这是个好建议。但这次我拒绝了。 原因很简单：我在用 AI 编程的过程中，逐渐意识到一件事——在 AI 时代，MVP 那套"先简后优"的逻辑，前提已经不存在了。 传统 MVP 的核心假设是：简易实现和高质量实现之间有显著的成本差，先用低成本验证，验证通过再投入。这个在人写代码的时代是成立的——用 Python 写个原型 2 天，用 Rust 写生产级实现 2 周，差 10 倍，所以先做简易版合理。而且代码是你自己写的，你理解每一行，以后重构只是时间问题。 但现在你对 Cursor 说"用 localStorage 存数据"和说"用 PostgreSQL 加连接池和事务管理"，生成时间差不了几分钟。既然成本一样，为什么要做简易版？ 更要命的是第二点：AI 生成的代码是黑箱，你大概率没法有效重构。 去年帮一个朋友用 Cursor 做了个小工具的 MVP ，需求很简单，AI 几分钟就生成了能跑的代码。两周后他想加个功能，打开代码，完全看不懂。不是因为代码乱，而是他不知道 AI 为什么这样写。最后他选择让 Cursor 重写一遍，而不是在原有代码上改。 这就是问题所在。你以为"以后再优化"，但你连哪里需要优化都不知道，因为你从未理解过这段代码。 所以我做 Agent OS 的时候，做了一个在很多人看来反直觉的决定：每一个架构决策都自己做，AI 只负责执行。 选语言的时候，用 Python 或 TypeScript 写个 Agent 框架，AI 几小时就能生成一个看起来很完整的 MVP 。但我选了 Rust ，理由很具体：Agent 系统需要长期运行、需要内存安全、需要跨平台——这些需求第一天就是确定的，不会因为用户量上来了才变成需求。 设计原则也是。我定了"事件溯源"——每一次操作都记录，可以回溯和重放。这在 MVP 阶段看起来是多余的，但当你的 Agent 在凌晨 2 点做了个错误决策，你需要知道它为什么做了这个决策。这不是"以后再加"的事，因为你以后根本不知道要加在哪里。 测试也一样。1232 个测试，每个模块合并前必须通过。AI 帮我写了很多测试，但测什么、怎么测、边界条件是什么——这些是我决定的。AI 很擅长为自己的代码生成"能通过"的测试，这就像自己出题自己答，当然满分。 Andrej Karpathy 自己也承认过："代码超出了我的理解范围。当 AI 修不了一个 bug 时，我就让它随机改，直到错误消失。"这是 OpenAI 联合创始人说的，不是什么新手的窘境。 我的选择是不让代码超出我的理解范围。哪怕前期慢一点。 有人会说这样不是更慢了吗？前期确实更慢。但到现在，每个模块都可以独立修改而不影响其他模块。我知道这个系统的每一块是怎么工作的。 而那些用 AI 快速搭 MVP 的项目呢？ 63% 的开发者说调试 AI 生成代码花的时间比自己写还多。470 个 GitHub PR 的分析显示，AI 生成代码出现重大逻辑错误的概率是人写的 1.7 倍，安全漏洞概率是 2.74 倍。 AI 编程还带来了一种新的技术债，和传统的不一样。传统技术债你知道它在哪——那个 hack 、那个 TODO 、那个硬编码。AI 编程的技术债是隐形的。 一种叫理解债：代码能跑，测试全过，但没人能解释它为什么这样工作。调试一段你不理解的代码比调试自己写的慢 3 到 5 倍，而 AI 大幅增加了你代码库里"不是你写的"代码的比例。 一种叫同质债：不同公司、不同产品、不同需求的团队，用 AI 解决同一个问题会得到几乎一样的代码。AI 给你的是互联网上最受欢迎的解法，不是最适合你系统的解法。农业里叫单一栽培——高产但脆弱，一场病全军覆没。 还有一种叫归属债：开发者从代码的作者变成了策展人。出问题时第一反应不是理解原因，而是让 AI 重新生成。一位资深工程师说得很直接："AI 为当下而建，不为将来而建。它对自己生成的东西没有维护的利害关系。" 这几种债有个共同特点：你的仪表盘全是绿色的。Sprint 速度在涨，PR 合并更快，测试覆盖率 94%。一切看起来很好。直到有一天你需要改一个功能，发现没有任何人知道该从哪里改起。 所以我的想法是：在 AI 编程时代，别再用 MVP 思维了。直接一步到位。 不是说花三个月做完美产品再上线。AI 已经把构建高质量实现的时间成本压到和简易版差不多了。关键是你的思维方式要从"先简后优"变成"一步到位"——对 AI 描述你要的终态而不是最简态，架构决策由人来做而不是交给 AI ，关键路径必须是人类彻底理解的。 真正的快不是写得快，是改得快、修得快、迭代得快。如果你连自己的代码都不理解，你根本快不起来。 AI 编程的本质是黑箱。你可以让黑箱帮你写代码，但你不能让黑箱帮你做决策。你没法重构一个你不理解的东西。