标题: L站目前有移动APP端吗？
作者: #wendong
板块: #搞七捻三
编号: 1355574
帖子: https://linux.do/t/topic/1355574
时间: 2025-12-24 09:49:44
摘要:

如果有APP端就可以随时的刷了，如果有大家给指个地址

标题: auggie mcp内存占用异常高
作者: #Everless
板块: #搞七捻三
编号: 1355576
帖子: https://linux.do/t/topic/1355576
时间: 2025-12-24 09:50:11
摘要:

Ghostty 启用的claude code，在启用mcp之后内存占用飙升，活动监视器能看到auggie的node进程占用40多个G的内存，这正常吗，项目是比较大

标题: 可恶啊，我是昨天注册的LDC怎么还没有划转
作者: #linjinpeng
板块: #搞七捻三
编号: 1355580
帖子: https://linux.do/t/topic/1355580
时间: 2025-12-24 09:50:52
摘要:

都快10点怎么还没划转啊

标题: 想问一下各位佬，gemini pro的学生会员在使用Antigravity有claude 4.5模型和gemini 3模型可以用，不知道有多少额度呢
作者: #保持好情绪
板块: #搞七捻三
编号: 1355586
帖子: https://linux.do/t/topic/1355586
时间: 2025-12-24 09:51:46
摘要:

各位佬知道去哪里查看额度吗

标题: 企业使用AI，日常使用哪一个好一些？
作者: #桑榆
板块: #搞七捻三
编号: 1355588
帖子: https://linux.do/t/topic/1355588
时间: 2025-12-24 09:51:51
摘要:

如题，请教一下各位佬友，目前内部准备多部门使用（含IT岗，非IT岗），目前哪一个AI更好用？

期望：稳定，响应速度较快，回答效果较好（如果有国外模型好的中转站也欢迎分享）

目前，比较倾向于国内的AI(国内响应速度快)，最近出了GLM4.7、MiniMax2.1、DeepSeek v3.2，但不知道哪一个更好一些，佬友们推荐哪一个？
欢迎回复，感谢

标题: 在谷歌插件市场看到了本站的插件，问一下这是官方的吗？
作者: #cxyax
板块: #搞七捻三
编号: 1355597
帖子: https://linux.do/t/topic/1355597
时间: 2025-12-24 09:53:28
摘要:

各位佬们，这是官方的插件吗，不是官方的我不敢用哇 
看着评分倒是挺高的，5.0星

标题: 【国内信息差】And【吃瓜吃瓜】Redis Vs Valkey ，Redis还能继续用吗？！
作者: #秋明
板块: #开发调优
编号: 1355602
帖子: https://linux.do/t/topic/1355602
时间: 2025-12-24 09:54:00
摘要:

原文

  
    
    
    
      【国内信息差】龙头企业已换成ValKey了，你还在傻呵呵用Redis？！ 
  

开发调优
    
  
  
    Redis 风险评估与 Valkey 替代方案

这是为公司写的文档，因为这个信息差我在众多社区没有看到，担心部分佬友也不清楚，一起分享一下新信息。 
。 
国内的字节，阿里云，腾讯云等龙头企业都已经在逐步替换为ValKey 
而且 ValKey更像一个 “升级版真正开源的Redis” ，同时有多个龙头企业 贡献代码，性能这块甚至更强悍 


二编： 感谢各位大佬们一起讨论，让大家对于这个话题的了…
  


新编

前言： 这是为公司写的文档，因为最近（12月）字节和腾讯云将Redis替换为Valkey了 ，这个信息我在众多社区没有看到，担心部分佬友也不清楚，一起分享一下新信息以及原因。
感谢各位大佬们一起讨论，让大家对于这个话题的了解深度更上一层楼

Redis 风险评估与 Valkey 替代方案（更新版）

核心结论（先看结论）：

对绝大多数企业来说——只要不是云厂商、也不是把 Redis 当成对外售卖的 SaaS 服务，当前的 Redis 8.x 仍然可以放心使用。 作为内部业务组件做缓存/会话/分布式锁，不修改源码，许可证不会强制要求开源你的业务系统。
选型上可以简单理解为：

小 KV 基础缓存 + 低并发 + 单实例：优先选 Redis（升级到修复安全漏洞的稳定版本（即8.x版本）。
大 Key 较多 + 高并发（≥ 50 万 QPS）+ 集群规模大：更推荐 Valkey 8.x，性能、稳定性与成本综合优势明显。





一、背景与更新原因

早期版本的报告更偏重“Redis 风险”，在许可证和漏洞层面给出了较为保守的结论。
随着 Redis 8.x 采用三重许可证（AGPLv3 / RSALv2 / SSPLv1），以及社区对条款的实务解读逐渐清晰，现在可以更准确地划定风险边界：


除非你是云厂商 / 把 Redis 打包成收费服务卖给第三方，或大量修改 Redis 源码并以“在线服务”形式对外提供，否则正常使用基本不受限制。


同时，Valkey 生态在近一年快速成熟，性能和兼容性数据也更加充分，需要更新“Redis vs Valkey”的对比与选型建议。


二、Redis 8.x 许可证现状：三重许可证与实际影响
Redis 8.x（2025 年 5 月发布）采用 AGPLv3 / RSALv2 / SSPLv1 三重许可证 模式，用户可以在三者之间选择其一来合规使用。
2.1 三种许可证的核心差异（结合我们的典型用法）




许可证
对“企业内部使用 + 商业缓存”的影响
主要限制关注点




AGPLv3
完全可用，不修改源码时几乎无约束
仅当修改 Redis 源码并通过网络对外提供服务时，才需开源修改部分源码


RSALv2
完全可用，适合企业内部系统
禁止将 Redis 直接作为收费的托管服务 / 缓存服务对外提供


SSPLv1
完全可用，不修改源码时约束有限
若修改源码并对外提供服务，需要开源包括管理层在内的相关代码




对于我们这类 “应用系统” ，Redis 只是系统中的一个组件：

不单独对外售卖 Redis 托管服务。
通常也 不会大幅修改 Redis 源码。

在这种典型场景下，Redis 8.x 的许可证基本不会强制要求开源业务代码，可以放心使用。

2.2 “通过网络提供服务”的真实含义
以 AGPLv3 为例：“通过网络提供服务”指：

把修改过源码的 Redis 部署在服务器上，外部用户直接通过网络使用“这个被你修改过的 Redis 服务本身”。

而我们常见的情况是：

业务系统使用 原版 Redis 二进制或官方容器镜像 作为缓存 / 会话 / 锁组件；
对外提供的是“堆场系统 / 业务系统”的 API，而不是“Redis 访问服务”；

这与“运营一个 Redis 云服务平台”有本质区别。因此：

在不修改 Redis 源码的前提下，我们只要遵守基础条款（保留版权声明等），就可以在商业项目中安心使用 Redis。


三、安全风险：漏洞存在，但可通过“升级 + 运维治理”可控
Redis 近几年确实暴露了一些高危漏洞，但关键在于：

漏洞是否有修复版本可用？
我们是否能在可接受时间内完成升级与验证？

3.1 高危漏洞示例


CVE-2025-62507（CVSS 8.8，高危）

多 ID 场景下，XACKDEL 实现存在 栈缓冲区溢出 风险，在一定条件下可能被利用实现远程代码执行（RCE）。
受影响版本：Redis 8.2.0 及以上；8.2.3 已修复。
临时缓解手段：使用 ACL 禁用 / 限制相关命令。



CVE-2025-48367（CVSS 7.5）

在特定配置下，未认证连接 可以构造重复协议错误，让客户端陷入“饥饿”状态，导致 DoS 风险（服务不可用、请求超时）。
修复版本（NVD 公布）：8.0.3 / 7.4.5 / 7.2.10 / 6.2.19。



历史典型漏洞（已修复）：

Lua 脚本引擎 Use-After-Free（潜伏约 13 年，CVSS 10.0），在未做好认证的公开实例上，攻击者可远程执行任意代码。



3.2 对我们的实际影响与建议
影响本质在于“升级能力”，而不是“用不用 Redis”：

Redis 作为“公共枢纽”（缓存 / 会话 / 锁 / 消息），一旦被打挂或被入侵，影响会波及多个业务模块；
但这些漏洞都有已发布的修复版本，只要：

建立起 版本跟踪与定期升级机制；
避免将 Redis 暴露在公网或不可信网络环境；
开启并收紧认证与 ACL，按“最小权限”使用命令；



就可以把绝大部分安全风险控制在合理范围内。

因此，从安全角度看，Redis 仍然是可控的，不存在“必须抛弃 Redis 才安全”的结论，更多是对运维治理能力的要求。


四、Redis vs Valkey：性能与特性对比（综合最新评测）
基于近期 8.x 版本的实测数据（统一使用如 AWS c7g.4xlarge、redis-benchmark 和 memtier_benchmark 等工具），可得到较清晰的性能轮廓。
4.1 基础性能：小 KV、普通并发场景
在 小 KV（≈1KB）、中等并发（< 10 万 QPS） 的基础缓存场景中：

Redis 8.2.3 与 Valkey 8.0.1 在 QPS 与 P99 延迟差异不大，通常在几％ 到 10％ 左右；
对业务来说，两者在“体感性能”上几乎等价。

示例数据（1KB，小 KV，读写混合）：




场景
Redis 8.2.3
Valkey 8.0.1
差异（Valkey vs Redis）




1KB KV 100% 读
QPS：112 万，P99：0.9ms
QPS：119 万，P99：0.8ms
QPS ↑ 6.2%，延迟 ↓ 11.1%


1KB KV 7:3 读写混合
QPS：106 万，P99：1.0ms
QPS：113 万，P99：0.9ms
QPS ↑ 6.6%，延迟 ↓ 10%




结论： 对于“普通业务低并发 / 单实例缓存”而言，选择 Redis 还是 Valkey，在性能维度上差别不构成决定性因素，更多看生态习惯与团队成熟度。

4.2 大 Key、高并发与极限负载场景
当业务出现以下特征：

大量 大 Key（10KB ~ 100KB）；
单集群或单实例需要支撑 ≥ 50 万 QPS 的高并发；
集群规模 ≥ 100 分片，对拓扑收敛时间与故障切换敏感；

Valkey 在架构与实现层面的优化会拉开与 Redis 的差距。
典型对比数据节选：


大 Key 混合读写（100KB）：

Redis：QPS ≈ 8.2 万，P99 ≈ 15.3ms；
Valkey：QPS ≈ 12.3 万，P99 ≈ 9.8ms；
QPS 提升约 50%，延迟下降约 36%。



高并发连接能力：

Redis：稳定连接数 ≈ 8 万；
Valkey：稳定连接数 ≈ 15 万；



满负载稳定性（CPU 100%）：

Redis：约 4 小时后开始出现 ~0.1% 超时；
Valkey：72 小时压测中未出现超时。



大规模集群拓扑变更收敛时间（100 分片量级）：

Redis（Gossip）：3 ~ 5 分钟；
Valkey（Raft + Gossip）：10 ~ 15 秒。




结论： 在“大 Key + 高并发 + 大集群”场景下，Valkey 在吞吐、延迟、连接数、故障恢复时间等多个指标上都明显优于 Redis 8.x。

4.3 生态与特殊能力


Redis 8.x 优势：

官方工具生态成熟，如 RedisInsight、Redis Stack 等，复杂场景排障体验更好；
一些小众 / 调试类命令兼容度更高。



Valkey 8.x 优势：

BSD 开源许可证，合规边界更简单直接；
原生支持一些面向 AI / 向量检索的能力（在某些版本或发行版中），可减少对 Redis 商业版的依赖；
在大规模集群与高并发场景下，工程化优化更

标题: 互相探讨ai的创新
作者: #ring
板块: #搞七捻三
编号: 1355605
帖子: https://linux.do/t/topic/1355605
时间: 2025-12-24 09:54:11
摘要:

突然想到一个问题，探讨一下，现在都是AI在协助，众所周知，ai也是基于以前大家的知识汇聚起来的，都是现有的知识水平上的。如果大家都不创新，ai可以自己创新的做某些事情么？或者说能否产生他知识库里没有的知识？
如果都不创新，也就是说最终的发展会有上限。

标题: 祝佬友们平安夜快乐！
作者: #fgy4399
板块: #搞七捻三
编号: 1355607
帖子: https://linux.do/t/topic/1355607
时间: 2025-12-24 09:54:26
摘要:

今晚就是平安夜了，祝你们平安夜快乐。

标题: 说实话，GLM4.7能打Gemini3和gpt5.1吗
作者: #naiba5
板块: #开发调优
编号: 1355628
帖子: https://linux.do/t/topic/1355628
时间: 2025-12-24 09:57:51
摘要:

说实话，GLM4.7能打Gemini3和gpt5.1吗

标题: Qwen-Image-Edit-2511 已发布
作者: #robot Make
板块: #前沿快讯
编号: 1355632
帖子: https://linux.do/t/topic/1355632
时间: 2025-12-24 09:59:07
摘要:

huggingface.co
  

  
    

Qwen/Qwen-Image-Edit-2511 · Hugging Face

  We’re on a journey to advance and democratize artificial intelligence through open source and open science.

标题: origin黑白绘图技巧
作者: #XOne
板块: #搞七捻三
编号: 1355634
帖子: https://linux.do/t/topic/1355634
时间: 2025-12-24 09:59:25
摘要:

想把彩色图片转为那种黑白色调，但又不是origin那种直接单色输出，不知道佬友们有什么技巧？
我现在采取的办法是把饱和度拉到0，我想要的就是彩色图片黑白打印那种效果。