@busterian 有没有可能，垃圾的是开个任务管理器就能上 100%CPU 的系统。
n100 这玩意一发布，才发现各种 xx pi arm 的板子是真的垃圾，又贵性能又烂。

非常老的 nvidia 显卡还是别折腾了，你可能连官方驱动都用不了，只能自己编译 EOL 的老版本驱动，并期望能够兼容新版的内核和图形栈。

@0o0O0o0O0o 如果仓库元数据带签名的话，那是没办法只保留一些有漏洞包的，不过确实可以整个暂停安全补丁仓库的同步。不过 Debian 这种要求安全补丁仓库使用官方源的做法，对几乎不能正常访问互联网的地区用户就很糟糕了。把元数据和实际数据分离，元数据只能从官方服务器获取，实际数据可以从任意渠道 trustless 地获取更合适一点。

你先搞清楚是分配了一个子网长度为/56 的单个地址，还是分配了一个/56 的段。

@CakewthinSUm
@Puteulanus
dns 污染不行，那就上 SNI 阻断，在不行 ip 黑洞路由。在国内多年上网的，这不用别人教吧。

这种实现要么是它内置了一个准确的屏蔽列表，微信得知某个地址被屏蔽后就自己隐藏了；要么是微信支持某种 canary domain 类的机制能够尊重网络管理员的配置。

linux 社区新增大量无法忍受 MS 各种喂💩的新用户，还得感谢这些“让中国创新走向世界”的中国团队。

@0o0O0o0O0o 没有必要啊，你都可以向客户端推送任意代码了，整个 xz 那样的后门，直接从下载日志拿到肉鸡 ip 连探针都不用。

@taoky 很多 repo 的签名是基于 web of trust 的，只要 compromise 任意一个 key 就等同 compromise 了全部的验证机制。或者你随便安装哪个软件带签名的 repo 需要信任对应开发者的 key 。也有一些包管理器根本就不支持镜像，使用镜像等于使用第三方 repo,root of trust 也是直接从镜像拉。
更理想的分发方式应该是 content addressed ，如 ipfs 。不过使用 p2p 网络那就不止镜像站了，任何 peer 都可以知道你下载了什么包什么版本，并可以以此进行 exploit 。

@dasenlin 你搞错了，这个不是反审查的项目，和 clash 一样认为自己尊重支持审查和法律，只是为看剧/查资料等正经用途设计，他们不认为自己违法，自然没有理由当作违法行为来做。
不过比起代理，这种通过分片等方式构造请求绕过过滤系统的行为（十年前就玩烂的技术），技术上更符合入侵计算机系统。

libreoffice
那些所谓预览插件大概率是调用的 MS office 的 dll,仍然需要你安装 MS office.

镜像应该是 trustless 的，不然就是严重的安全问题。
这甚至无关“不可抗力”，任何一个能接触到镜像服务器的人，或者任何能够 compromise 镜像服务器的人，随便给哪个服务或者库植入个后门顷刻间就能拥有一大堆肉鸡。

@ShadowPower https://www.qualcomm.com/developer/blog/2024/05/upstreaming-linux-kernel-support-for-the-snapdragon-x-elite
这个平台可以说很好，再等两个内核版本就可以买了。但你要想整个设备所有硬件都能驱动的话，还是买支持 linux 的型号比较好。

直接用 bottles https://usebottles.com/ 开箱即用不需要手动进行任何配置。

@tool2dx 分布式不是说你想随便横向扩容就能随便扩的。
多个核心/单元/节点之间的同步/协同/共享/通信都需要架构上的考虑。不是说你把 45 张 10W 的芯片堆到一起就能当 450W 的多核心计算单元了。多个节点之间的开销大于核心的算力的时候你越堆性能越差。
作为一个参考，记得几年前华为鲲鹏的 ARM 服务器几十上百个核心，单核主频也好几 G ，参数看起来非常强劲，然而实际跑起来编译个内核这种并行化非常高的场景，速度还没有 mbp 快。

要不你整 45 台 10W 的设备组集群，是不是就能当 4090 用了？

@EVANGELIONAir 现在正常版本的 Windows 好像不止是内置一些应用把，像什么联网帐号、新闻、copilot 等乱七八糟的垃圾一打开就到处都是。

@BeautifulSoap 所以你偏题了，这里讨论的不是不信任中间件，而是不信任服务端，中间件的攻击面只是服务端不被信任的原因之一。
后端不应该能够得知密码原文因为后端不需要得知密码原文也能实现完整的功能。而前端多进行一步加盐 hash ，也就是不让后端得知不需要的隐私信息的行为，你称之为“没有开发经验，连基本 it 知识和安全思维的没有的逆天”。

据我观察在 v 站发帖需要 NAS 的绝大多数需求都不是 NAS, 而是 seedbox.

你应该把标题改成“服务端能够得知密码原文”。
使用了 https ，其实就已经不是明文而是是加密传输了，在这之上再进行额外多少层的对称还是非对称加密，只要服务端有能力解密得知密码原文，那就都是一回事。
前端进行 hash 的目的只有一个：让后端对密码原文保持 zero knowledge ，其他的安全策略于此是正交的。