软解速度很慢，有时比播放速度都慢
一些设备不少格式是不支持的，比如 chrome 就是，我们经常有用户跑来问为什么手机拍的视频浏览器播放不了

油甜辣都不要吃。
去专业皮肤科看看

v2raya
用很久了，没啥问题

对我来说是学习成本太高了，任何配置调整我都要去谷歌一下才知道怎么弄，而且记不住。比如我想改个启动参数，居然要去改配置文件......

不会
我之前看 spring boot 官方的视频教程就是 controller 直接调用 repository

报备两个月，连公司全称的签名都经常被拦截（提示没实名制报备），本来就是残废还继续折腾

我申请水星的时候被要求提供公司的地址证明，而中介不提供这个。
后来用申请 EIN 的文件（上面有地址）才通过了。（美国人效率是真的低，等 EIN 花了将近四个月）

来晚了，不行了已经

* 坑主要与 EC 有关，其中一部分功能提交 pr 给官方了。我们是从去年这个时候 fork 出来做的二次开发，期间经历了多次集群突然崩溃、突然选举导致服务中断等问题，直到现在才勉强稳定运行。后来我们试图合并官方的代码，发现创建新 volume 的功能疑似被其他人负优化了，就没继续合并了。

* EC 后文件被删除了空间无法释放的问题，我们目前是简单的做了判断——判断 volume 里所有文件都被删除后再删除该 volume 的文件

* Java 版的 EC 我们目前暂时没有精力单独开源出来，等集群稳定后再考虑。

* 一个集群的 master 节点数量设置成 3 个，5 个会增加超时概率，超时了就会触发选举。我们是搭建了两个完全独立的集群，一个无法提供服务的时候会自动切换到另一个

* weed 有预创建 volume 的，但是当 collection 数量过多+高并发的时候，由于它创建 volume 是串行处理、且每创建一个 volume 耗时在百毫秒左右，会导致一部分请求超时（ 10 秒超时）。业务应用需要做重试。

* 副本复制可以，如果空间足够的话建议不要做 EC 。

=========
就在刚刚，我们又发现了一个极端情况下返回上传成功实际文件上传失败的 BUG （与 EC 有关），造成一集群近几个月约 10%共上百 TB 的文件丢失了，这个 BUG 仍然存在于官方的最新版里。

@niz

@niz
我们用 seaweedfs 的一些坑：
1. seaweedfs 的 EC 坑很多——比如不支持 ttl （提了 pr 现在支持了），并且如果用机械盘的话，EC 速度是赶不上文件上传的速度的。我们后来参考 go 源码另外开发了 java 的 ec 任务。还有诸如 EC 后文件删除无法释放空间等问题。
2. 内部大量用到了锁，有几个地方有性能问题，还有并发读写 map 导致 panic 崩溃的问题。
3. 在大量文件写入的情况下，master 节点会突然触发选举，且其选举非常慢——超过 30 秒，且保证可用性的话需要准备两个集群
4. 有大量文件写入、新 volume 生成频繁的时候，创建 volume 的速度赶不上文件写入的速度。

seaweedfs 适合大量小文件，性能是 minio 的几十倍。
minio 适合大文件。它是个黑盒，一旦量大了就懵逼，没任何流量的情况下都能给你磁盘 io 打满。

@chocotan
23 问题解决了，要装 gnome-keyring

刚下载试用
1. 打开文件夹的逻辑太怪了，很不习惯
2. 没法用 deepseek：输入 deepseek 密钥后，按回车不生效，重新打开密钥还要再填
3. github copilot 登录没反应

@niubilewodev 我的账号不是 china 也用不了 junie 。后来得挂 vpn 才能用，但对话发消息直接卡死。

长续航日常也是充到 80%，只有长途才充满
而且我电池健康度也只剩 89%了

在虚拟机里用 windows 一样卡。

我以前桌面是用 openbox ，后来一直用 awesome wm 到现在十多年
优点大概有：
* 完全的自定义，从快捷键到桌面主题样式，都能够自己调整
* archwiki 很完善，大部分问题都能参考 wiki 解决

不过我不可能推荐别人用 linux 桌面，因为门槛较高。也有不少缺点：
* 开源的图片编辑、音视频编辑等工具很难用，教程也少。最终还是要用 windows 去修图、做视频。
* 一些硬件驱动没有，比如零刻的某些型号缺少网卡驱动
* 显示输出、休眠睡眠、电源管理等，不同机器表现不一样，换个新机器就可能冒出来新的问题。而 windows 这些问题相对较少（只是相对较少，我自从升到 win11 后之后 hdmi 输出就没稳定过）

说个曾经遇到的。
apache httpclient 库发起 GET 请求，query 如果使用 GBK 编码，部分生僻字使用同为 apache 家的 tomcat 可以正常接收，使用 spring-cloud-gateway 接收就会变成乱码。
实际原因也是一样——GBK 的一些生僻字复用了 ASCII ，不同的解码逻辑会导致不同的结果。
后来把 tomcat 的解码逻辑复制到 gateway 中了。至于为什么要用 GBK ，是历史遗留问题。

ai 有时候调试半天都不生效，可以让 ai 加日志，然后把输出的日志再发给 ai
@SGL