@caihp 这个就是在终端使用的吧。或者你从 https://github.com/anomalyco/opencode/releases 下载后传过去也行啊。

OpenCode 有 deb 版本，下载之后自行安装就好了： https://opencode.ai/zh/download

你每编译一次都重下一遍 SDK 、重装所有依赖也花不到 200G 啊。系统配置问题吧

esp32 也能跑 arduino 环境吧。我现在手头全是 esp32 了

借个楼，我最近也在看垂直鼠标，之前道听途说对垂直/人体工学鼠标的一些批评：

1. 本质就是换了个关节部位压迫，并不能做到减轻劳损
2. 对手大小和形状要求苛刻，容易不适配，用起来更难受
3. 鼠标定位操作别扭，很难精确指向屏幕上特定位置
4. 高价低配现象严重

想请教一下各位 V 友，这里面有哪些是真实的吗？

@just1 @ztm0929 为什么 OSS 比 NFS 更便宜，仅仅是因为 API 更简单吗？

@jacketma 感觉 OSS 在这个意义下其实是在替代传统的分布式文件系统？像 Ceph 、GlusterFS 这些

@Kumo31 有道理。我的理解是 OSS 之于文件系统的关系就像 MongoDB 之于关系数据库，99% 的业务场景不需要这么复杂的语义，所以选择更简单的设计

@w568w 最后一句没说清楚，补充一下：

1. zju-connect 是整个 VPN 协议的完全重实现，不依赖 docker ，资源占用极低且稳定得多；
2. zju-connect 已经能成功连接 EasyConnect VPN 了，不过这个项目是针对浙大的 EasyConnect 版本开发的，实际可能要微调代码才能用于其他场景；
3. aTrust 的协议，zju-connect 还在逆向适配中。

我司用的 aTrust 开了单点登录，尝试各种 Docker 方案无果，目前的方案是 Windows 11 VM 装 EasyConnect 登录，然后 Gost 来暴露 socks5 代理。

VMware 在后台占用还好，4GB 内存，CPU 几乎不会占用。

目前比较有希望的方案可能是 zju-connect 的逆向，他们之前已经成功实现 EasyConnect 协议的 Go 重实现。见： https://github.com/Mythologyli/zju-connect

我还没看春晚的回放。如果今年的魔术真是这样的话，在魔术里加入电子仪器的把戏总感觉怪怪的，毕竟电子仪器是可编程、且观众难以肉眼检查的。

从性能和安全性来说 SFTP 是更好的，处理小文件速度快很多，而且搭建起来更容易。

但是从兼容性来说，WebDAV 对移动端 app 兼容性更好。

我的个人建议是两个都开。另外密码不用搞这么麻烦吧，网络安全重在意识，你这个有点过度保护了，容易把自己锁外面

@Cnming 你在说啥？回复错人了？

Rust + Flutter 的混合开发范式挺常见啊，基本思想是 Rust 写共享代码或核心逻辑层，Dart (Flutter) 写 UI 层，也需要 dart:ffi 做中间组件，你想表达什么

铁锈战争很多年前玩过，感觉在手机小屏上操作挺累的。RTS 经常需要地图精确定位的操作，触屏也不是很方便，不过确实耐玩

耐玩的基本都是程序生成内容的游戏吧，比如沙盒类（泰拉瑞亚、星露谷物语、饥荒、Minecraft 、西奥小镇），Rougelike 类（杀戮尖塔、元气骑士、小丑牌）、吸血鬼幸存者类（游戏如其名）、跑酷类（神庙逃亡、滑雪大冒险）、传统益智类（数独、扫雷、魔塔、棋牌游戏）

不过我感觉也不用非得玩一款单机游戏哈，几款换着玩体验最佳

1. Android 开发技术和规范的碎片化。「原生套 H5 套 Flutter 套 React Native 套小程序框架」在很多应用已经是常态了，混合带来灾难性的体积膨胀和性能下降。典型例子：闲鱼。

2. 太多的产品需求造成的工程能力崩溃。

3. 说一个比较有争议的：我了解过的一些中小企业的 UI/UX 设计基本都秉持着「 Apple 设计本位主义」，日用的设备是 MacBook / iPhone 、使用的原型设计软件只支持 iOS 控件和动画逻辑、看的视频在分析苹果设计、听的播客讲的是苹果的设计哲学，造成了一种「 iOS 是本位，Android 只是顺带设计下」的边缘化思维。

我看到的这些企业的 UI Draft 里九成九都是按照苹果设备的思路来设计的（例如，要有返回按钮、要支持 iOS 的手势、要 Liquid Glass 、要大圆角 [注：我知道 Android 现在也搞大圆角了] 、要 iOS 风格的对话框和动画效果）。

这些设计想法在 Apple 生态里实现可能很自然，但到 Android 生态中就会有各种技术上的阻力，最后各种全手写控件叠起来就变成四不像，没有「 Android 味」。

但国外的应用设计通常比较注重系统一致性，要么会选择中性的设计风格（例如 Telegram ），要么完全单独遵循 Android 的设计规范（通常是独占应用，例如 Urbandroid 的产品）。

@aalivexy Impeller 的性能优于 Skia ，增加了预编译着色器和 Vulkan / Metal 支持。我从 Flutter 1.22 开始使用，当时还是 Skia ，并没有感觉到和原生有显著的渲染性能差距（当然，当时 60fps / 120fps 的差距还是有的）。

把我原来回复中的 Skia 替换成 Impeller ，也不改变结论，反而更说明 Flutter 的渲染性能应当是和原生相当的。

@tanszhe

> Flutter 的性能肯定是小于原生性能的

为啥啊，Android 原生的图形渲染框架是 Skia [1]，Flutter 使用的图形渲染框架也是 Skia [2]。Android 原生的运行时是 ART ，Flutter 是 Dart Runtime [3]。

难道 Android 通过 Java -> C++ 调用的 Skia 比 Flutter 通过 Dart -> C++ 调用的 Skia 更高级吗 🤔

[1] https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/libs/hwui/pipeline/skia/SkiaPipeline.cpp
[2] https://docs.flutter.dev/resources/architectural-overview#flutters-rendering-model
[3] https://dart.dev/overview#native-platform