唐僧 retweeted
Gemini app (包括 web) 很神奇的一点是，如果你在回答（推理思考）过程中彻底杀掉应用，这轮回复（连同提示词）会整个丢失。再次回到会话时，完全看不到这一轮发生过的痕迹。
深度怀疑这个 app 就是 AI Studio 团队做的，沿袭了从客户端发起 API 请求的传统。🫠
前面说的 ext-transient-seat ext-transient-output 就是把创建、销毁虚拟显示器和 seat 这个流程协议化了，之前要手动写脚本来自动化。
这套逻辑并不局限于远程桌面，如果换成 sunshine 那就可以当作串流用，平板接上外设打游戏也没问题。
传统上的远程桌面都是镜像主机的屏幕，这个方案体验很差的一点是分辨率跟着主机走，到了平板客户端上就变形错位。
我在用 sway 的时候直接用它的内置协议功能，创建与目标平板分辨率和缩放一致的虚拟显示器，然后把这个虚拟显示器作为 rdp 的桌面。之后把要展示的内容放到这个桌面就可以了。
另一个场景是我会偶尔会带个大平板做近距离的项目演示，或者是非投屏的会议。平板比什么便携显示屏可靠谱多了，只需要临时手机热点搭个网络，运行平板上的 vnc/rdp 软件就行。
对面的人可以拿着平板观看操作，我这边可以实时做修改调整。
用上这个 seat 功能，我就很少用桌面显示器，而是手边有什么平板就用什么。
当然用平板当显示器没什么稀奇的，但如果这个平板有独立的输入焦点呢？
很多时候我用副屏是放个浏览器窗口做参考，偶尔就需要滑动或者翻个页，有 seat 的时候可以直接操作，主机该打字就打字一点不会受到焦点切换的影响。
wlroots/sway 那边又出了一个新提案 ext-transient-output，算是对 ext-transient-seat 的补充。
这个 seat 是我一直坚持 wlroots/sway 的原因。说白了就是对输入输出设备进行分组，每个 seat 都有自己的焦点。
估计大多数人别说用过，可能这个概念都没听说过。它的主要应用场景是远程桌面。
所以实际上我对业务规模的划分大概是这样的：第一档最小是看能不能单体嵌入式解决，第二档大概是 100GB 内存单个节点能抗住，真上到第三档要拆分做高可用了另说。
当然单 kv 数据库有很多不好解决的问题，我更倾向于要么链路上把流量镜像出去旁路处理，要么在业务层解决。
之前聊数据库选型的时候，我说我喜欢直接把 redis/valkey 当数据库和消息队列用，但没说清楚关键点。
具体来说这个设计就是让整个系统只有数据库一个共享状态，只要读写压力和数据量压不倒，剩下的业务逻辑都可以避免大部分与状态相关的工作。而且业务模块可以非常方便地拆成免维护的微服务模块。
歧视这个事可以大大方方说，别搞得好像嘴上不说歧视就不存在了一样。
商家要是都像 A 厂一样硬气明牌歧视，我要是觍着脸非要用那是我贱。
反过来厂家要是说欢迎八方来客，实力不行误伤我了还怪我出身不好，那我肯定往死里骂。
说到底不还是歧视，觉得封了你天经地义么？我最看不起这种双标了。
很不幸，按照 IP 封杀中国流量是一件特别符合逻辑的事情……
在还没有大模型的十年前，Facebook 用机器学习来训练模型鉴别机器人，我们即使不看训练结果只看训练数据，都能预测中国用户会被大规模误封。
从训练数据上来看，来自中国 IP（包括 VPN）的新用户有一半是机器人。这意味着 100 个来自中国的新用户，系统期望值是封杀 50 个。最终这 50 个能否挑选对，那是另外一个问题，但不封杀 50 个是不符合逻辑的。
你就想象一下这个场景：你跟 99 个陌生人在一起，你知道这里面有 50 个罪犯，你也知道系统会砍杀 50 个人，你对自己的生存概率有多乐观？
这最终就变成了跟一部分中国人「理性歧视」黑人一样——你可以是好人，但因为你所属于的群体，你必须被当做大概率是坏人对待。中国 IP 就是这样的存在，你可以是好人，但作为一个 feature 面对 classifier 时就大概率会被判作坏人。
有些中国人还对黑人被歧视有个观点，「怎么你们不先搞好自己社区，降低黑人出暴力罪犯的比例呢？」那反过来问也是一样的，「怎么你们中国人不减少黑产出海呢？」这个问题没有意义，其他中国人做黑产有多猖狂，你根本管不了。
我是觉得纯本地的块编辑器没什么用。
飞书搞块编辑器是为了降低协作冲突，而且大家都在云上用什么底层格式无所谓。
私有格式的代价就是低交换效率。而且 md 高性能渲染可以用增量语法树，要说 md 表达能力不行，不还有 doc/pdf 么。
不如直接说是个私有格式的笔记应用定位。
唐僧 retweeted
Yes! I think the key point is the Confidence Level
The hardest thing in an SRE's daily job is the noise; we need to judge how bad it is and whether it's worth following up on.
So the decision-model pipeline can make that easier. Doesn't need to be very powerful model; I think this will cut off enough noise.
The problem is not the model; I think everybody can RL a tiny model on some low-cost hardware like a 4090. The hardest problem is that you need to prepare enough clean data. Observability again lol(
But I think we already have enough pre-requirement. We just need to test more in the production environment and more patience.
Orz. Such a burst of great ideas! Thank you, @Manjusaka_Lee !
On formal methods. Yes! I truly believe fast, lightweight formal methods would help agents greatly. See the TLA+ skills in @poteto 's pstack and the experience from @bcherny. It's not going to be end-to-end iron proofs, but it helps agents produce better code.
On decision models. I love decision models. I've heard people have customized #Specula using decision models to achieve cheap and fast TLA+ MC, though I haven't found time to figure that out.
The students have tried Jev and decision models on #SREGym and shared their experience in a few blog posts (sregym.com/blog). I know the benchmark isn't close to real SRE, but some ideas might apply. I love the idea of using decision models for proactive techniques and the idea of RLCD for SRE! @SaadMRP @YukunHeZS @Yiming_Su3 @HacksonClark
唐僧 retweeted
我宣布 inua.one 已经比 gnome 好用了。
距离 Cassidy James 的逆天言论过去一个月。
唐僧 retweeted
笑死，我原推有说 Claude Desktop 在用 WebRTC 查 IP 封号了吗，一些迫真 KOL 不要上来就搞个大新闻，连图都偷的我的，Too Young Too Simple，Sometimes Naive。
xitter.cf/HiFrey/status/21139624…
