曾用过 Floccus ，最终还是放弃了。跨浏览器同步书签坑不是一般多，数据冲突的情况太常见了。最终的解决方案是自己搭建了个人导航页用于管理需要同步的链接，浏览器的书签仅用于随手记。

话说，自建 bitwarden 用 vaultwarden 这个第三方开源实现更多些吧？这个就没有楼主吐槽的问题了……

@walkbox 没接显示器引起的显示问题，建议接一个显卡欺骗器之类的玩意。系统识别不到显示器自然无法决定输出分辨率。

个人经验：mstsc 综合最好用； parsec 画质一流带宽但要求高，功能差点； TeamViewer （仅局域网模式）功能齐全画质稍差没办法用 mstsc 时（比如 Win11 家庭版）可以用这个。

@mrzx 那我就放心了……我也看了些资料，说现在 OpenZFS 都是优先开发 Linux 版本，然后再往 FreeBSD 上合并。

个人的经验，Proxmox 上使用 ZFS 作为存储还是很顺畅的。OpenMediavault 上的 ZFS 其实也是安装了 Proxmox 提供的内核。两个系统到目前为止都在正常运作中。如果不折腾 TrueNAS 可以试试 OpenMediavault ，这个就是相当纯粹的 debian 环境了……

@mrzx 比较好奇 OpenZFS 的性能差这一说法的来源。主要是本人在 Proxmox/OpenMediavault 上部署了 ZFS 使用中，虽然强度没多高就是了……

月经贴……然后我也回过几次类似的回复：为什么不全都要呢 :doge

状态码和响应体一起用并不冲突。Http 状态码用来区分正常响应和错误响应，响应体中给出具体的错误码。当然，200 状态就没有错误码这一封装了。
也许这有点多余的认知成本，但实际上用得最多的就三状态：200 （这个甚至不用写），400 （用户输入错误），500 （服务端错误）。这不比各种业务面条来得复杂吧……

再进一步说，新的 Spring6 开始支持 RFC 7807 规范： https://www.rfc-editor.org/rfc/rfc7807 ，规定了异常信息如何返回。可参考： https://www.51cto.com/article/721281.html 。基本思路就是异常产生时的响应特殊 header 和 json body 。

当然以 Java17 的实际普及程度来看广泛要升级到 Spring6 还有相当长的时间，但我已开始期待，观望等 Spring6 普及了这一月经贴的内容是否会有所变化😀

Proxmox 使用 ZFS 可以配置最大内存限制。TrueNAS 下应该也有对应配置吧……

还可以看看这个 https://github.com/woodpecker-ci/woodpecker ，drone 的开源 fork

社区版+1 。个人付费购买了 WebStorm ，Java 开发一直用的社区版，没觉得哪不舒服……

https://www.hipparchus.org/

Hipparchus: a mathematics Library
Hipparchus is a library of lightweight, self-contained mathematics and statistics components addressing the most common problems not available in the Java programming language.

我选 webpack + swc 。swc 的插件个人感觉还是略复杂，不如 webpack 的开箱即用。合起来用慢就慢点吧……

自从开始用 ventoy 后，就再也没灌过 U 盘了，直接通过 ventoy 引导 PE/Linuex 的 ISO 了事。

看上去不错，关注了……
但我服役 N 年的 D2550 工控机目前就已经是性能过剩状态（除了功耗略高），感觉还能再战 5 年 :doge

基本可以参考冗余校验的机制（也叫纠删码什么的），比如 ZFS 的 raidz 或者 snapraid ，这俩都提供了 scrub 命令用来验证磁盘上数据是否损坏。

当然这个也不是万能的，如果损坏的数据操过了冗余数据的比例，该丢的还得丢。

可以用 Content-Type 区分。POST application/json 为创建，POST application/x-www-form-urlencoded 为查询

如果是要在 单页面多次请求异步渲染 与 单页面聚合请求一次渲染 间比较性能优劣，我觉得还是要看具体业务场景。在服务端调用多个低响应时间的接口还是有一定性能优势的。

个人觉得 remix loader 的效果，比较接近于使用 api gateway 或者 graphql ，但写起来更加清晰一些。

也曾遇到了类似的问题，解决方案和上面某些楼层差不多，自己造了一个书签管理服务的轮子。且贴出来吧：

https://github.com/zongwei007/firefly

参考了 https://github.com/pawelmalak/flame 和 https://github.com/soulteary/flare

估计与 ext4 的 inode 有关。如果对这类占用比较敏感，可以使用 mkfs.ext4 -T largefile 重新格式化看看。

apcupsd 值支持 apc 的 UPS ，山特的要用 nut ，自带的那套 ViewPower 什么的太垃圾。