@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 ，其他的安全策略于此是正交的。

@BeautifulSoap 你的论点完全偏题了。无论是密码也好，还是其他信息也罢，只要服务器知道的信息，那就都是一样的，没人关心你要怎么 secure 你的中间件。
They can do whatever they want with your data, and you have no way to know what they did. What else do you expect ?

至于“xxx 所以和明文没区别”这纯属滑坡谬误，假设我在 V2EX 的密码是`mypasswordforv2ex.com`，看到明文之后你能不能猜到我在其他网站的密码？更不用说很多人的密码文本本身就包含个人信息，如姓名拼音/生日等。

@BeautifulSoap 是的，当你提交姓名/住址/银行卡号等个人信息给某个网站的时候，你应该知道你的信息会被任何包括员工在内有权限的人，以任意方式访问/传输/存储/使用/共享，并且你全都无法验证。
这就是为什么要在前端对密码加盐 hash ，使服务端对密码原文保持 zero knowledge 的原因。

@BeautifulSoap 有没有一种可能，我只是一个负责中间件/负载均衡或者其他什么根本不需要接触数据库的组件的开发，我发现某个组件有 bug ，于是就加了几条 log 把部分请求打到日志里。回头我把这些日志收集清洗一下，我就掌握了大量用户的密码了。

或者你认为任何公司的任何员工都做不到/不会做这样的事情？

有没有一种可能，那一万种变相搞到你明文密码的方式，其实都是一种：以后端能够得知原文的方式传输密码。

你如果要只有目的地址为 10.10.10.10 的流量转发给 10.10.10.20 ，那你可以在写规则的时候匹配目的地址。网卡和 ip 没什么关系，从 eth0 进来的目的地址为 10.10.10.10 的包也会被接受，但匹配不到你的规则。

如果你的需求是由 B 向 C 发起请求但是要经过 A ，那你直接在 B 添加静态路由，ip route add <dest_C> via <ip_of_A>，然后在 A 上配置规则决定谁能发给谁。

@FTLIKON
@tsanie
@BeautifulSoap
是的，后端能够得知密码原文是合理的需求，前端加盐 hash 都是逆天。因为这样我可以在哪天倒闭跑路之后把用户的用户名和密码 dump 出来卖给黑客拿去撞库。哦，如果哪个用户跟我 dispute ，我可以直接拿他的用户名密码去其他网站登陆他的帐号给他开盒。

或者你相信任何人都不会做这样的事情？

> 为什么密码要明文传输？
因为太多人认为密码明文传输不是问题。如果你不为这些人开发的服务使用密码管理器生成全随机的专用密码，那你就是受害者。

@AoEiuV020JP 你理解错了，bl 锁是让设备只能运行具有可信签名的系统镜像，有些设备只信任厂商的签名，而另一些设备允许信任用户导入的签名。

@kuanat 是的，kotlin 只能用 jb 自家的 ide 是最大的缺点，被迫用多个 IDE ，每个都有不同的配置/插件/快捷键是很糟糕的体验。

@kuanat kotlin 就别想 LSP 了，jb 为了卖自家的 IDE 不可能提供支持。

花钱买这个不如给 rustanalyzer 捐点钱。