标题: 速领，元宝派发第一波现金红包了，已领6块7
作者: #武则天
板块: #福利羊毛
编号: 1550377
帖子: https://linux.do/t/topic/1550377
时间: 2026-02-01 00:51:48
摘要:

APP升级一下就有，直接抽大概5块左右，可以直接提现到微信
有个红包口令，是不是可以话题帖子回复里传递一下

标题: 你们有人用Linux的xorg桌面一边训练一边干别的事吗
作者: #scvxzf
板块: #开发调优
编号: 1550378
帖子: https://linux.do/t/topic/1550378
时间: 2026-02-01 00:53:14
摘要:

我就一个独显
训练时候GPU差不多是吃满的但是我还想写点代码，xorg的桌面会因为GPU核心被吃满就Failed to start nginx.service - A m server and a reverse proxy server直接爆掉，尝试修复和限制也没搞好，（显存还没吃满）
只能切回wayland用，wayland虽然不会爆桌面，但是有别的bug，有些ui的界面会一闪一闪的整的我眼睛疼

标题: 腾讯元宝发红包了，这里10x4，每个两瓶可乐
作者: #EndView
板块: #福利羊毛
编号: 1550383
帖子: https://linux.do/t/topic/1550383
时间: 2026-02-01 00:55:20
摘要:

标题: 腾讯元宝发红包了！！（无aff)
作者: #和宇宙的温柔并联
板块: #福利羊毛
编号: 1550385
帖子: https://linux.do/t/topic/1550385
时间: 2026-02-01 00:58:17
摘要:

一个人的红包一天只能领取一次，这是我两个号的：来元宝分10亿 抽万元小马卡
这是另一个号的： 来元宝分10亿 抽万元小马卡

标题: 88元收一模一样的手机支架
作者: #panda8023
板块: #福利羊毛
编号: 1550388
帖子: https://linux.do/t/topic/1550388
时间: 2026-02-01 01:01:11
摘要:

88元收一模一样的手机支架,要5个
不骗人真的要找了好久都找不到.
如真的有可咸鱼交易
强迫症的世界不知道有没有人懂

标题: Google Workspace 每周更新回顾
作者: #Muse
板块: #前沿快讯
编号: 1550394
帖子: https://linux.do/t/topic/1550394
时间: 2026-02-01 01:03:56
摘要:

来源：Google Workspace Updates: Google Workspace Updates Weekly Recap - January 30, 2026

标题: python fastapi的性能到底能不能达到或者接近nodejs的档次？
作者: #gobert
板块: #搞七捻三
编号: 1550407
帖子: https://linux.do/t/topic/1550407
时间: 2026-02-01 01:10:53
摘要:

我问gemini和gpt，都回复说fastapi框架已经非常接近nodejs
但是今天去参加活动，问了几个AI从业者，都说高并发场景下，python自己就拉爆了，除非你有钱无限扩计算资源
搜了个reddit帖子，测试说是这样：
Basic test: Nodejs:50k Golang:65k  Fastapi:11k
DB/Redis: Nodejs:9k  Golang:18k Fastapi:2.5k
看这个测试，fastapi距离nodejs差距巨大，和golang差距更大

标题: 我的GeminiPro好像没死，有办法安排到ClaudeCode使用吗？
作者: #Logos
板块: #开发调优
编号: 1550409
帖子: https://linux.do/t/topic/1550409
时间: 2026-02-01 01:12:39
摘要:

Claude太贵了，第三方也很贵

标题: 调整推荐算法了吗
作者: #摇摆熊
板块: #搞七捻三
编号: 1550411
帖子: https://linux.do/t/topic/1550411
时间: 2026-02-01 01:13:08
摘要:

怎么这两天逛论坛奇奇怪怪的

标题: z-image-base-lora训练结果
作者: #scvxzf
板块: #开发调优
编号: 1550429
帖子: https://linux.do/t/topic/1550429
时间: 2026-02-01 01:18:02
摘要:

前情提要：
训练7炉炸6.5炉
结论是：
“一坨”
首先“turbo和base训练出来的lora可以互通”
优势：
1.base说起来拟合速度是比turbo更快的。
2.提示词也可以打触发词+全标了，不会和turbo一样后期不打全标就没效果了。
优势说完了说缺点：
1.首先训练出来的lora效果无论是在base上面使用还是放在turbo上面使用，都没有turbo的lora效果好。（一样的参数和数据集）
2.就拿我没炸的那0.5炉来说，base层于层之间的界限非常模糊，分层几乎是分不出来的，想要lora生效作为前提，效果还想不炸裂就得开全部层。
最后：
阿里大骗子能不能把我这三天电费给我补一下

标题: 你相信 AI 能独立完成一个从 0 到 1 的产品吗？
作者: #YougLin
板块: #开发调优
编号: 1550431
帖子: https://linux.do/t/topic/1550431
时间: 2026-02-01 01:18:09
摘要:

Click to view the poll.

引用我未来一份稿件中的两句话。

也许未来，我们每个人都能拥有一个 AI 团队：有人负责编码、有人负责研究、有人负责监督——而你，只需要告诉它们你的愿景。


这一天，只会比你我想象的更近。

尽请期待，Aha
1w+字数稿件已经准备就绪，筹备开源中~

标题: 【木子狸的指北指南】02 CLIProxyAPI
作者: #木子不是木子狸
板块: #搞七捻三
编号: 1550449
帖子: https://linux.do/t/topic/1550449
时间: 2026-02-01 01:22:48
摘要:

起因
起因是我发了一篇 【木子狸的指北指南】01 Octopus 的部署与使用 - #5，来自 Muzilee
然后和 @apparition 这位佬讨论了一下。



【木子狸的指北指南】01 Octopus 的部署与使用

Antigravity 反代出来给 amp 或 cc 比原生 IDE 好用
所以会需要 CLIProxyAPI (CPA)，或另一个 antigravity manager 项目
kiro 也是如此，可以用 kiro.rs 或 CPA-Plus 用来反代
而 codex 只是为了切号方便，也挂在 CPA 下面
我现在用 CPA(逆向) + GPT-Load (正规订阅) 来处理 API 聚合
更大的聚合站我不想再搞了，太浪费时间
有时候一个错误弄个几个小时
都够我把我的 MCP 项目推进一小节了 


打算试一试看。
由于社区已经有很好的帖子了，所以在这里我就只按照我使用的方式，来简单的讲解下在 Zeabur 上的安装和使用

  
    
    
    
      手把手带你用上AI神器 - CLIProxyAPI（零：配置详细解说） 
  

资源荟萃
    
  
  
    由于该系列教程篇幅较长，因此我按主题拆分，大家可以点击目录快速跳转到感兴趣的篇章 

手把手带你用上AI神器 - CLIProxyAPI（零：配置详细解说）
手把手带你用上AI神器 - CLIProxyAPI（壹：项目介绍+Qwen实战）
手把手带你用上AI神器 - CLIProxyAPI（贰：Gemini CLI+Codex实战）
手把手带你用上AI神器 - CLIProxyAPI（叁：Nan…
  


欸 突然发现已经有佬友写了 那我还是偷个懒hhh
https://linux.do/t/topic/1348585

标题: OIDC/Oauth2 统一认证中心下 Access Token 选型求建议：JWT vs opaque token
作者: #Toint
板块: #开发调优
编号: 1550484
帖子: https://linux.do/t/topic/1550484
时间: 2026-02-01 01:30:37
摘要:

场景背景
我们正在构建统一认证中心，业务系统作为资源服务器接入。

架构约束：前后端分离（业务侧不依赖 Cookie），无 API 网关层。
网络隔离：资源服务器无法直连或共享认证中心的 Redis/DB，只能通过标准 HTTP 接口交互。

核心需求

写/敏感接口（如改密、封禁、踢下线）：要求状态变更 秒级生效。
普通读接口：允许存在短暂的数据滞后。

现有方案的权衡
方案 A：Opaque Access Token + Introspection (RFC 7662)

优点：语义接近中心化 Session，撤销和踢人控制天然精准。
缺点：业务侧需请求认证中心验证 Token（虽可做几秒缓存），但认证中心仍是链路上的性能瓶颈。一旦网络抖动或 OP 挂掉，影响面巨大；且缓存时长与“生效延迟”之间存在难以两全的取舍。

方案 B：JWT Access Token (短时效)

优点：资源端离线验签，性能极佳，完全无状态。
缺点：若要实现秒级生效，必须引入额外的在线控制机制（如敏感接口二次查询，或引入版本/会话策略），这本质上又退化回了中心化 Session，感觉失去了 JWT 的最大优势。

我的折中思路
目前倾向采用 混合校验策略：

读接口：只进行 JWT 离线验签，不回查认证中心，确保性能。
写/敏感接口：在离线验签通过后，再调用认证中心进行二次校验（结果短暂缓存）。

想请教各位对此怎么看? 有没有更好的架构模式推荐?