标题: 请问有什么自建的电子书阅读器吗
作者: #嗷小海
板块: #搞七捻三
编号: 1788163
帖子: https://linux.do/t/topic/1788163
时间: 2026-03-20 14:54:10
摘要:

最近用微信读书 不太方便。
想整个自建的电子书阅读器用下。
希望大佬推荐一下。
谢谢。

标题: Kubuntu桌面的窗口总是一团黑
作者: #Chenpeel
板块: #搞七捻三
编号: 1788167
帖子: https://linux.do/t/topic/1788167
时间: 2026-03-20 14:55:01
摘要:

如题
系统信息大致如下：
~ > neofetch                                                                                                                                                               py base 14:46:29
           `.:/ossyyyysso/:.               chenpeel@u 
        .:oyyyyyyyyyyyyyyyyyyo:`           ---------- 
      -oyyyyyyyodMMyyyyyyyysyyyyo-         OS: Kubuntu 24.04.4 LTS x86_64 
    -syyyyyyyyyydMMyoyyyydmMMyyyyys-       Host: B360 M AORUS PRO 
   oyyysdMysyyyydMMMMMMMMMMMMMyyyyyyyo     Kernel: 6.14.0-37-generic 
 `oyyyydMMMMysyysoooooodMMMMyyyyyyyyyo`    Uptime: 4 hours, 24 mins 
 oyyyyyydMMMMyyyyyyyyyyyysdMMysssssyyyo    Packages: 4111 (dpkg), 17 (snap) 
-yyyyyyyydMysyyyyyyyyyyyyyysdMMMMMysyyy-   Shell: zsh 5.9 
oyyyysoodMyyyyyyyyyyyyyyyyyyydMMMMysyyyo   Resolution: 1920x1200 
yyysdMMMMMyyyyyyyyyyyyyyyyyyysosyyyyyyyy   DE: Plasma 5.27.12 
yyysdMMMMMyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy   WM: KWin 
oyyyyysosdyyyyyyyyyyyyyyyyyyydMMMMysyyyo   WM Theme: Breeze 微风 
-yyyyyyyydMysyyyyyyyyyyyyyysdMMMMMysyyy-   Theme: [Plasma], Breeze [GTK2/3] 
 oyyyyyydMMMysyyyyyyyyyyysdMMyoyyyoyyyo    Icons: [Plasma], breeze-dark [GTK2/3] 
 `oyyyydMMMysyyyoooooodMMMMyoyyyyyyyyo     Terminal: Tabby 
   oyyysyyoyyyysdMMMMMMMMMMMyyyyyyyyo      CPU: Intel i7-9700F (8) @ 4.700GHz 
    -syyyyyyyyydMMMysyyydMMMysyyyys-       GPU: NVIDIA GeForce GTX 1080 Ti 
      -oyyyyyyydMMyyyyyyysosyyyyo-         Memory: 8516MiB / 32027MiB 
        ./oyyyyyyyyyyyyyyyyyyo/.
           `.:/oosyyyysso/:.`                                      
                                                                   


工作的电脑，
大概三天左右回家的时候不关机（每次关机重开都要抚慰以下BIOS的电子）
或者内存占用稍微大一点（感知上，大概就是双开Codex 重构中型项目）
就会出现包括弹出的窗口、打开的程序会 50%左右的概率，窗口完全黑
大家有什么头绪吗，是我 ubuntu + KDE 的问题吗，还是什么原因呢

标题: 【新人报道】各位佬友好，多多关照
作者: #vankoa
板块: #搞七捻三
编号: 1788173
帖子: https://linux.do/t/topic/1788173
时间: 2026-03-20 14:56:10
摘要:

加入L站第一天，各位佬友下午好呀
【第一次发帖纪念一下】

标题: 我把 Superpowers 改造成了一个更适合做深度学习模型改进的版本
作者: #Lurume
板块: #开发调优
编号: 1788179
帖子: https://linux.do/t/topic/1788179
时间: 2026-03-20 14:57:30
摘要:

最近我基于原版 Superpowers，做了一个更偏深度学习研究场景的个性化版本：superpowers_DL。
原版项目本身很有启发，它更偏软件工程工作流，适合做需求拆解、实现推进、代码协作这类任务。
但我自己的主要场景其实不太一样。我更常做的是：

读论文
改模型
设计实验
debug 训练
分析结果
判断这次改动到底是不是真的有效

做久了以后我会越来越明显地感觉到一个问题：
很多时候，深度学习研发的瓶颈根本不是“代码写得慢”，而是实验流程太容易失控。
比如：

还没把假设想清楚，就先把模型改了
baseline 没有对齐，最后结果不好解释
训练一出 NaN、发散、OOM，就开始凭经验乱试
单次跑涨点就很兴奋，但 seed、配置、评测口径其实都没控好
失败实验没有沉淀记录，过两周又重复踩一遍同样的坑

所以我做这版 superpowers_DL，核心目标不是让 AI “帮我更快写代码”，而是让它更像一个围绕实验闭环工作的研究助手。
这版到底改了什么
简单说，我把原来偏软件工程的工作流，重构成了更贴近深度学习研究的工作流。
我保留下来的不是“通用开发能力”，而是这些更关键的研究节点：


paper-to-implementation
把论文里的贡献点拆出来，避免一上来把一整篇论文的所有技巧一起搬进工程里


experiment-design
在动代码之前，先把假设、baseline、指标、预算和判据说清楚


experiment-planning
把实验变成一份可以执行的计划，包括代码改动、sanity check、正式运行和产物保存


experiment-execution
按计划执行，尽量避免“本来只想试一个模块，最后顺手改了半套训练流程”


training-debugging
专门处理 NaN、发散、OOM、指标异常、训练停滞这类问题


result-analysis
实验跑完之后，不是直接下结论，而是先比较 baseline、ablation、rerun，判断证据到底支持什么


experiment-closeout
每次实验结束后，决定代码是保留、继续扩展，还是回滚，只保留实验记录


reproducibility-check
在对外汇报之前，检查命令、配置、seed、commit、数据版本、checkpoint、指标表是否完整


换句话说，这版更像是在给“深度学习实验”做流程设计，而不是给“软件开发任务”做流程设计。
我为什么觉得这件事值得做
因为深度学习研究里最贵的东西，很多时候不是算力，而是“无效试错”。
一旦实验过程不规范，就很容易出现几种情况：

改动有效，但你说不清到底是哪一部分有效
指标变好了，但比较不公平，结果没法服众
一个 bug 似乎修好了，但其实只是运气好的 rerun
结论看上去成立，但别人根本无法复现

这类问题只靠“更聪明的模型”其实解决不了。
它更需要一套明确的研究流程，把每一步都拉回到可验证、可比较、可复盘的轨道上。
这也是我想把 superpowers_DL 做成现在这个方向的原因。
如果用这套东西，一个完整工作流会是什么样
这一点我觉得是最值得讲清楚的。
因为 superpowers_DL 不是一组零散 prompt，它更像是一套面向深度学习实验的 SOP。
一个典型流程通常会是这样：
1. 从论文想法或者模型改动出发
如果一个点子来自论文，先不要急着直接开改。
先用 paper-to-implementation 把论文真正的核心贡献和隐藏前提拆出来。
这样做的好处是，你能更早知道：

论文的收益到底来自模型改动、loss、数据处理，还是训练策略
它依赖不依赖大规模预训练、特殊数据过滤或者更高算力
你在自己这套代码里，最小应该先复现哪一部分

2. 先定义实验，而不是先定义实现
接下来用 experiment-design 把这次实验定清楚：

你这次到底在验证什么假设
你和谁比，也就是 baseline 是谁
你最关心的主指标是什么
你愿意为这次尝试投入多少训练预算
什么结果算成功，什么结果说明这条路不值得继续

这一步看起来不炫，但其实很重要。
因为很多“做了一堆工作最后说不清结论”的问题，都是这一步没做扎实。
3. 把实验拆成可执行计划
有了设计之后，再交给 experiment-planning 去落计划。
这一步会把实验拆成几个明确阶段：

要改哪些代码和配置
先做哪些静态检查或单元检查
先跑什么小数据 / 少步数 sanity run
再跑什么正式实验
最后哪些配置、日志、checkpoint、metrics 表必须保存

这会让实验更像“按计划推进”，而不是“想到哪改到哪，跑到哪算哪”。
4. 正式执行时，尽量不要边跑边漂移
然后就是 experiment-execution。
这一层我很看重的一点是，它会提醒你尽量保持单变量变化。
比如你本来只想验证一个新模块，就不要在同一轮里顺手把数据增强、学习率策略、loss 权重一起全改了。
研究里最怕的不是没涨点，而是你根本不知道“为什么涨”或者“为什么没涨”。
5. 训练一旦出问题，按研究事故来处理
如果实验中出现了 NaN、发散、OOM、loss 异常、指标不稳定这些问题，就进入 training-debugging。
我专门保留这个模块，是因为训练问题特别容易被“经验主义修复”带偏。
很多人会下意识去改学习率、加 gradient clip、调 warmup，但如果根因没找到，这些操作往往只是把问题暂时压住。
training-debugging 更强调的是：

先缩小问题规模
先稳定复现
给最可能出错的边界加探针
找到好 run 和坏 run 第一次分叉的地方
一次只改一个变量

本质上，它是在把训练故障当成一个需要定位根因的研究事故来处理。
6. 实验跑完，不要急着“宣布胜利”
这时候轮到 result-analysis。
这一层的重点不是帮你“解释为什么你是对的”，而是帮你判断：现有证据到底支持什么。
它会逼着你去看：

baseline 和 ablation 是否真的可比
是单次好运，还是多次 rerun 也稳定
指标提升的同时，有没有带来更高显存、更长训练时间或者更多参数
评测口径、训练预算、数据切分有没有变化

很多时候，真正高质量的结论不是“这招涨了点”，而是“这招在当前约束下证据还不够，先别讲太满”。
7. 每次实验结束后，做一次明确收尾
我还加了 experiment-closeout，因为很多实验仓库最后会越来越乱，往往不是因为改得多，而是因为没有收尾机制。
一次实验结束后，其实应该明确回答一个问题：
这次改动，是继续保留，还是回滚掉，只留下记录？
失败实验本身并不可怕。
真正糟糕的是失败了，但没有留下足够信息，几周后团队里另一个人又重复做了一遍。
8. 对外说“提升了”之前，先过复现门槛
最后才是 reproducibility-check。
我在这版里很强调一点：
没有完整证据链的结果，最多算“观察到一个现象”，不应该直接包装成“已经证明提升”。
至少要能回答清楚这些问题：

命令是什么
配置是什么
seed 是什么
commit 是哪个
数据版本和切分是什么
checkpoint 在哪里
指标表能不能支撑这个结论

如果这些东西拿不出来，那这个结果最多只能算一个待确认信号。
所以这版最核心的变化是什么
如果要用一句话概括，我会这么说：
superpowers_DL 想解决的不是“AI 能不能更快写实验代码”，而是“AI 能不能让深度学习实验更有纪律、更有证据、更容易复盘”。`
我自己最看重的几个原则，也基本都落在这套工作流里了：

假设先于实现
最小可证伪实验优先
baseline 必须公平
失败实验也要留痕
证据比直觉重要
可复现比故事完整更重要

这版更适合什么人
如果你平时主要做这些事情，我觉得这版会比原版更顺手：

论文复现
模型结构改进
loss / augmentation / training schedule 调整
训练故障排查
ablation 和 baseline 对比
对外汇报前的结果核查

也就是说，它更适合“研究型编码”，而不是泛软件工程。
目前支持的环境
现在这套仓库主要面向：

Codex
OpenCode
Gemini CLI

仓库里也保留了 Claude Code / Cursor 的相关元数据，方便本地接入。
仓库地址
GitHub: https://github.com/ShunyangLiu/superpowers_DL
如果你也在用 AI 辅助做深度学习实验，而不是只把它当成一个写代码工具，欢迎看看这版。
如果你也有类似需求，或者你觉得深度学习工作流里还有哪些环节特别值得被产品化，也欢迎交流。
最后也感谢原版 Superpowers 给我的启发。

标题: any报错403
作者: #lionp
板块: #搞七捻三
编号: 1788190
帖子: https://linux.do/t/topic/1788190
时间: 2026-03-20 14:59:04
摘要:

API Error: 403 status code (no body) · Please run /login
这个真的不知道怎么搞了。
大家还有推荐的配置或者可用opus的（可注册最好）的公益站推荐吗？

标题: vibe了一个新的侧边栏插件
作者: #zd1737
板块: #开发调优
编号: 1788197
帖子: https://linux.do/t/topic/1788197
时间: 2026-03-20 14:59:53
摘要:

本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：

我的帖子已经打上 开源推广 标签： 是
我的开源项目完整开源，无未开源部分： 是
我的开源项目已链接认可 LINUX DO 社区： 是
我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
以上选择我承诺是永久有效的，接受社区和佬友监督： 是

以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出

昨天linuxdo更新了新的horizon主题，看到帖子

https://linux.do/t/topic/1782308


https://linux.do/t/topic/1704799

试了一下侧边栏插件，发现侧边栏的字体有点小，和主页内容有点不协调，就想着自己用iframe嵌套的方式打开帖子，这样两边的内容就协调一致了。
然后就开始使用codex和gemini开发一个浏览器插件，codex开发初版，gemini负责修bug，其实基本可用vibe起来特别快，但是中间处理两个bug花了今天一上午。
在侧边栏里点击边栏的展开和关闭不会影响到主页面刷新后的状态，可以设置分栏比例并记住，可以主动关闭，效果如下

开源地址： zd1737/linux-do-side-view
下载地址： Releases · zd1737/linux-do-side-view
最后，感谢公益站的支持，没有公益站就没有这个插件

标题: 分享一个配色网站-中国色
作者: #huxiaofei
板块: #资源荟萃
编号: 1788210
帖子: https://linux.do/t/topic/1788210
时间: 2026-03-20 15:02:34
摘要:

zhongguose.com
  

  
    

中国色 － 中国传统颜色

  中国传统颜色网站，提供各种中国传统颜色的名称，CMYK值，RGB值，16进制表示。


  

  
    
    
  

  


可以很直观的看到色卡、也有配色条，适合做各类设计材料、汇报PPT等

标题: opencode 1.3.0 将不再自动加载 claude max 插件
作者: #钟阮
板块: #前沿快讯
编号: 1788215
帖子: https://linux.do/t/topic/1788215
时间: 2026-03-20 15:04:17
摘要:

标题: 佬，这种视频一般是用什么生成的
作者: #moghn
板块: #开发调优
编号: 1788216
帖子: https://linux.do/t/topic/1788216
时间: 2026-03-20 15:04:26
摘要:

用 sora gemini  即梦 可灵 都达不到这种效果          
            
              
              https://cf.moghn.eu.org/music/e6790092ac30a81dfa0d0039b3e61482.mp4

标题: 终于进入L站了，向各位佬友问好！
作者: #Little_D
板块: #搞七捻三
编号: 1788217
帖子: https://linux.do/t/topic/1788217
时间: 2026-03-20 15:04:32
摘要:

各位佬，头像要几级才能换呢，  我点进connect 只有飞升之路啊