linux.do
21.2K subscribers
121K photos
195 videos
117 files
255K links
linux.do最新话题和热议话题
Download Telegram
番茄七猫小说下载器,墨水屏
LINUX DO - 热门话题 (RSS)

前情提要

最近闲的无聊,买了一个墨水屏设备,观看小说总是很麻烦。

— 在手机上查找好看的小说
— 通过各种方法下载到本地
— 上传到墨水屏设备
— 进行观看

后面感觉不错、又入手了一个墨水屏,但是又存在了一个问题,两个墨水屏之间阅读记录不同步怎么搞?

解决方法:

— 手搓一个阅读apk软件,搭建阅读同步服务器。(撸代码开发到50% )放弃了,太难了。
— 使用其他开源app(github上面有,但是我没有用过)
— 微信阅读app(还不错,然后就选择了这个)

现在存在以下问题,上传到墨水屏设备步骤繁琐、下载小说也麻烦。所以,肝了好几天做了一个新项目。

一个功能强大的多平台小说下载器,支持番茄小说、七猫小说等平台,提供TXT和EPUB格式下载,配备美观的网页界面、书库管理和多种上传功能。

白话文说就是:可以搜索七猫、番茄书名和id进行下载、下载到书库,书库可以上传到墨水屏(通过墨水屏的wifi传书功能)和微信读书书架内。然后同步番茄和七猫的书架,在手机app上观看到好看的小说,直接到网页内对应书架进行下载,然后到书库,即可上传到墨水屏内。

**哔哩哔哩视频介绍:**分辨率调整错了,有点模糊,懒得重新录了。

【番茄七猫小说下载器,墨水屏下载小说】 番茄七猫小说下载器,墨水屏下载小说_哔哩哔哩_bilibili

https://ipfs.io/ipfs/QmdiZL4jdArqHWKT8hx9jTinA6GQaNwhH5BqpGDz1U1own?filename=simple-video-to-gif.gif(图片大于 4 MB)...

View original post
别寻思了哥,没人会跟你谈条件
LINUX DO - 热门话题 (RSS)

哥,别在那做你的美梦了,没人会跟你谈条件。

我不接受任何条件,这里的佬友你也打不走。

还想着搞点钱呢,我宁愿把钱交给 cloudflare 也不会给你半个子儿的。

啥也不是。别在那白日做梦了,不服气你就接着打

问题不大,佬友们接着奏乐接着舞~

632 个帖子 - 614 位参与者

阅读完整话题
Linux do 发帖规律:佬们都是工作日上班划水怪
LINUX DO - 热门话题 (RSS)

前言
Linux do 社区里面有非常丰富的教程和资源,佬们水贴的速度非常快,搜集信息有时候比较麻烦。要不要做一个 Linux do 的 RAG

当然,如果把论坛里所有的帖子都塞到 RAG 里成本太大,不如先来过滤一下帖子。

我首先收集了论坛一些最火的帖子,包含以下字段:

views(浏览量)
like_count(点赞数)
reply_count(回复数)
— 发帖时间

这些分析纯属娱乐,样本不具备代表性,纯纯乐子人。

佬们都是上班划水怪
虽然这些样本在整个论坛中不算什么,但我们还是能窥探出佬们刷论坛的一些规律。

— 从整体趋势看,Linux do 在 2024 年初快速发展,5 月到 9 月进入“停滞期”,此后保持在较高水平。中间的波动,大概是佬们放年假了(图 1a)。
— 从星期分布看,发帖主要集中在 周一到周五,周末明显冷清(图 1b)。
— 从时间分布看,上午 9–11 点、下午 14–17 点是发帖高峰(图 1c)。
— 结合星期和时间来看,可以很明显地看到:工作日的上班时间发帖最多(图 1d)。



浏览量、点赞、回复到底有什么关系?
那问题来了:

是不是在某一天的某个时刻发帖,就能更容易得到浏览量、点赞和回复?

回复:没有明显的时间规律,说明更多受到帖子内容质量影响(图 2a)。
点赞和浏览量:在凌晨(夜猫子/机器人?)和工作时间...

View original post
被低估的gpt-oss
LINUX DO - 热门话题 (RSS)

刚刚在阿b上刷到了个视频 感觉讲的很有道理


【绝大多数的视频都没能讲出 gpt-oss 系列模型的真正意义-哔哩哔哩】 绝大多数的视频都没能讲出 gpt-oss 系列模型的真正意义_哔哩哔哩_bilibili


讲一下我的理解(仅代表个人观点)

gpt-oss被低估的价值在哪?
gpt-oss开源的不仅是模型权重,还有其底层的harmony架构,而该架构在agent时代有着很大意义

harmony架构好在哪?
与传统的chatml架构相比,基于harmony架构的response api能实现服务端状态管理,从而大幅减少token消耗

训练方面,harmony架构引入了可扩展的角色定义,不再局限于user和assistant,可扩展性更高

(有感而发 随手记录一下)

10 个帖子 - 7 位参与者

阅读完整话题
正在使用lobe-chat的佬们注意了!lobe-chat正在泄漏你的隐私!
LINUX DO - 热门话题 (RSS)

太长不看版本:

当你使用lobe-chat-database进行MCP工具调用之后, lobe-chat团队和cloudflare就会知道该工具调用的细节。

存在严重隐私泄漏、跨境数据传输等安全风险,请各位佬友谨慎使用该软件。

lobe-chat我觉得算是一个优秀的ai对话工具,特别是在MCP集成方面。

项目开发者也在本站: 个人资料 - Arvin_Xu - LINUX DO

但最近碰到的一件事却让我不寒而栗。

我通过lobehub/lobe-chat-database - Docker Image | Docker Hub 这个镜像部署了本地数据库版(v1.112.0),连接了内网的数据库,AI使用的MCP服务器也是部署在内网的(由我自己开发)。理论上,我和AI的对话记录只有我内网有记录(以及AI的服务供应商)。

但我最近在使用AI调用MCP服务器时, 发现lobe-chat在MCP服务器返回结果后,还需要loading很长的时间(可能要几十秒)才能发起下一次AI请求。经过排查,主要是受该接口影响: /trpc/lambda/market.reportCall,message.update?batch=1, 短则几秒、多则几十秒。

让AI帮我分析lobe-chat代码后, 我发现lobe-chat在这个接口里将MCP调用数据上报到了env.MARKET_BASE_URL



但我的lobe-chat-database实例内没有MARKET_BASE_URL这个环境变量,那么数据去哪了呢?

通过查看DNS解析记录/网络抓包后,我发现lobe-chat将数据传到了https://market.lobehub.com,托管在cloudflare上(怪不得速度忽快忽慢!)。但这个域名,在lobe-chat的官方代码仓库(lobehub/lobe-chat)里是没有的,这又是怎么回事呢?

通过排查lobe-chat-database容器实例,我发现这个域名记录在容器内的js文件中:...

View original post
怎么看google one还有多少个月?
LINUX DO - 热门话题 (RSS)



11 个帖子 - 9 位参与者

阅读完整话题
如何用手机指挥Claude Code干活
LINUX DO - 热门话题 (RSS)


本文最早发布在我的博客


如果有更好的使用手机操控Claude Code的方案或建议,欢迎佬友交流讨论~

思路
我们使用Claude Code时,正常需要通过命令行与其交互,但这往往要求我们需要在一台电脑前待着。

思考一下,我们与Claude Code的交互,实质上只是两种:

— 输入文本;
— 选择批准或者拒绝操作。

事实上,要实现和它的交互,我们完全不必使用电脑。也就是说,理论上我们完全可以只使用手机,以一种方式连接到电脑,实现交互。

这么说来,已经有一种现成的朴素方法:通过手机远程控制电脑,然后和Claude Code进行交互。但这种朴素方法在交互时有所不便,例如输入文字的输入法问题、选择批准/拒绝时需要使用方向键等。

如果在移动设备上有用户友好的应用,或是使用一个类似vscode的server版本,那么体验就会好很多。

带着这个思路,我先找到了claude-code-webui这个项目,该项目可以网页的形式和Claude Code进行交互,但目前还没有鉴权功能,试用下来较为简陋。



又找到了claudecodeui这个项目,看起来完成度就好很多。...

View original post
齐之未齐:浅谈gpt-oss-20b-base与对齐税
LINUX DO - 热门话题 (RSS)

之前OpenAI真的很少见了Open了一回,向开源社区发布了两个推理模型 gpt-oss-120bgpt-oss-20b;我们这里先抛开模型性能怎么样不谈,因为确实不怎么样()。他们并没有开放未对齐的base版本模型,导致如果社区想进行更广 更纯粹的微调的话会相对比较困难。

所以 Meta的研究院 Jack Morris 决定自己动手填补这一空白。他的核心目标是「逆转」OpenAI gpt-oss-20b 模型的对齐过程,使其从一个遵循指令、安全对话的推理模变回基础模型(Base Model,即预训练后未对齐的原始状态)。

一、对Morris训练/微调方法的分析
他的核心假设是:预训练模型存储了几乎所有知识,对齐(通过SFT、RLHF、DPO等方法实现)对模型权重的改变是低秩的。也就是说,预训练赋予模型广博的知识和生成能力,这是一个遍布整个模型权重的高维、复杂过程。而对齐更像是在这个庞大的知识空间中进行微调和行为塑造,它教会模型如何以特定方式(如对话、遵循指令)输出,这种改变在权重矩阵上表现为一个相对简单的、低秩的更新(W_aligned ≈ W_base + Δ,其中 Δ 是一个低秩矩阵)。

那么,既然对齐是一个低秩的正向更新,那么逆转对齐也可能通过一个低秩的反向更新来实现。Morris并没有识图计算出原始的 Δ 并减掉它,而是通过在预训练风格的数据上进行微调,来学习一个新的低秩更新 Δ',使得 W_aligned + Δ' ≈ W_base

基于上述假设,他直接以 OpenAI 发布的 gpt-oss-20b(已对齐的混合专家模型)为基础,冻结原始模型权重,仅通过 LoRA 选择了第7、15、23层的 MLP 层(多层感知机层)注入低秩更新。LoRA 是参数高效微调(PEFT)的代表技术,它通过训练两个低秩矩阵(W_AW_B)模拟全量微调效果,既能保留原始模型能力,又能精准调整输出分布。


LoRA 的“秩(rank)”设为 16(极低的秩,意味着更新矩阵的自由度很小),最终可训练参数仅 60,162,048 个,占原始模型 200 多亿参数的 0.3%。这种微创操作确保了更新不会覆盖模型预训练的核心知识,只调整行为模式。


那么,他到底用的是什么数据来进行这样一次小微调呢?这也就是Morris本次的精妙之处了,他回归了模型预训练初心,没有用指令数据或反对齐数据,而是从 FineWeb 数据集(高质量网页文本,与预训练数据分布接近)中抽取了约 2 万个文档,用标准的 自回归语言建模目标训练——即让模型像预训练时一样补全文本,而非回答问题。


学习率设为 2e-6(极小,避免过拟合),批次大小 16,训练 1500 步,最大序列长度 8192(充分利用上下文窗口)。训练后将 LoRA 参数与原始模型合并,得到可直接使用的 gpt-oss-20b-base


微调后的模型 gpt-oss-20b-base 确实摆脱了之前AI助手的枷锁,变成了一个文本续写专精的base模型。当被问及「这个模型是不是只是学会了模仿基础模型,而不是真的变回了基础模型」时,Morris的解释是:他的训练数据里根本没有《哈利·波特》,但模型却能准确地续写其中的段落。这说明,这个能力是模型在预训练阶段就已经具备的,只是被对齐过程隐藏了起来,而Morris的微调成功地将其挖掘了出来。

二、方法的与局限性
虽然通过Morris的做法确实得到了Base模型,使得基础模型可以接受更加广泛的数据集的微调,为更广泛的研究和应用打开了大门,但由于通过微调训练出来的 gpt-oss-20b-base 不是,也不可能是 OpenAI 从未发布的那个原始基础模型。它只是一个行为上极其相似的新模型。通过在一个方向上施加一个低秩更新,再在另一个方向上施加另一个低秩更新,并不能保证精确地回到原点。这更像是在高维权重空间中,从A点(Base)走到B点(Aligned),然后再从B点走到了一个与A点非常接近的C点(Morris’s Base)。

我们可以用一个不恰当的例子做比:

假如一个小孩自0-7岁生活美满,无忧无虑,乐观天真可爱(be like base model),但7-9岁家里突生变故,性情大变(be like后对齐),我们固然可以在他十岁的时候重新给予一个健康、美满、和谐友爱的生活环境,让他被重新约束训练回那个无忧无虑乐观的样子——但这个孩子终究确实是被永远的给改变了。

我们姑且可以把这种「逆转对齐」的行为看作是一次有意义的尝试。这种方法在不久的将来很可能会变得更加有用,因为有越来越多人担心未来的大模型社区会充满已经对齐的模型,导致进一步研究中的base模型成为一个相对稀缺的东西。

三、对齐税(Alignment Tex)
什么是对齐税?

这是一个很形象的比喻,在上下文情景中的英文词汇是 Alignment Tax,在传统的定义下,对齐税指的是在通过指令微调和强化学习等技术使大模型变得更“有用、诚实、无害”(Helpful, Honest, Harmless)的过程中,模型在其他一些重要能力上(如创造力、推理能力、知识准确性等)所付出的性能损失或能力下降的代价。

大模型在预训练过程中的目标是最大化语言建模能力,即更好地预测下一个token,学习文本分布的统计规律,最终目的是记住世界知识,生成流畅文本;而对齐阶段的目标则是优化人类偏好,通过奖励模型(RM)或规则约束,抑制那些高概率但不安全的输出(如脏话和暴力内容),即使这些输出在语言建模上更优。


基础模型可能以90%概率生成“高效但不安全”的回答,而对齐后模型被训练为以90%概率生成“安全但冗余”的回答(如“我无法回答该问题”),导致生成多样性下降——这就是对齐税。


因此,对齐税最直观的表现形式就是创造力和多样性的下降。对齐后的模型倾向于给出安全、中立、格式化的回答,避免任何有争议、冒险或风格独特的内容。它可能会拒绝写一首风格阴暗的诗,或者用一种特定的、非主流的口吻进行角色扮演。


所以作者自己也警告base model可能会输出各种不安全 负外部性的内容


在某些领域,为了确保无害,模型会变得过度谨慎,拒绝回答许多完全无害但可能被误解的问题。比如,你问一个关于化学反应的科学问题,模型可能会因为其中包含某些敏感词汇而拒绝回答,并给出一个关于安全的免责声明。经过RLHF对齐后,模型在某些学术基准(如MMLU、HellaSwag)上的得分反而会下降。这是因为对齐过程优化的是对话质量或安全性这类模糊的指标,而非解题的准确性。模型学会了如何表现得很好,但可能牺牲了部分解决问题的核心能力。

最终,对齐训练之后的模型就是我们的日常instruct,或者说chat对话模型。这类模型对用户友好的光环必然遮蔽了灯下阴影,那些模型不敢生成的回答(文本补全方向)、那些模型以“我不知道”来狡黠的规避了的问题、那些模型过于谨慎回避掉的合理冒险,最终汇聚成了我们所看到的,对齐税是模型外表下的阴影部分

四、额外的碎碎念
最近,我发现DeepSeek v3 base模型给我带来了不小的惊喜,尤其是在写作领域。目前市面上主流的旗舰/非旗舰/开源模型我基本上都测试过类似的合作协作和补全任务,但没有什么是比使用v3 base模型尝试直接补全、理解和续写一段文本(我自己的文章)更令人惊叹的了,base模型在non-instruct语境下的理解能力令人惊讶,其情感之细腻、表达之贴切让人叹为观止。


当然,使用base模型是需要抽卡的,但万一就抽出来ssr了呢?概率总是有的嘛


从base model本体上来说,基础模型的本质优势(训练非instruct的数据集)也给LLM写作带来了新的可能性。在传统的大模型应用中,无论是聊天助手、知识问答还是文本创作,我们往往需要给模型提供一个明确的指令或prompt来引导生成。我并不是说这个做法是错的或者本末倒置的,而只是想我们能获得的更多————因为鉴于LLM的潜能,它不应该仅仅只于能被我们敦促去做一些事情

base model的强大之处就在于它摆脱了指令的束缚和限制。它像一只没有被驯化的野马,能够在茫茫识海中自由穿梭,将曾经识记的知识片段、曾经学习的写作风格、曾经增进的世界理解融会贯通,生成出无比流畅、丰富、自主的内容。与此同时,它没有被强加任何一种既定的思想钢印,没有接受任何特定的价值判断或知识偏见,充斥着人类统计学纯粹的美感。


总结来说就是:


基础模型 = 既糊弄又高效的灵光一现 + AI良助

你也可以在这里看到我的博客原文

11 个帖子 - 11 位参与者

阅读完整话题
一文入门 Docker Compose
LINUX DO - 热门话题 (RSS)


本文同步发布在我的博客之中:一文入门 Docker Compose - Lynn的小站



前言

借助 Docker,您可将容器当做轻巧、模块化的虚拟机来使用。同时,您还将获得高度灵活性,实现对容器的高效创建、部署及复制,并在环境之间迁移它们,从而有助于您针对云来优化应用。

——《什么是 Docker?》



Docker Compose is a tool for running multi-container applications on Docker defined using the Compose file format. A Compose file is used to define how one or more containers that make up your application are configured. Once you have a Compose file, you can create and start your application with a single command: docker compose up

——《Docker Compose 官方介绍》


简单来说,Docker可以让我们把一个项目的所有依赖环境配置好,我们可以快速的运行起来,而无需处理环境的依赖问题;

而某个项目需要用到诸如数据库、Redis等其他项目的时候,使用Docker Compose可以将所有的项目和项目依赖通过一个yml完全配置好,我们只需要通过一行命令就可以快速启动这个项目。


Compose 使用的三个步骤:

— 使用 Dockerfile 定义应用程序的环境。
— 使用 docker-compose.yml 定义构成应用程序的服务,这样它们可以在隔离环境中一起运行。
— 最后,执行 docker-compose up 命令来启动并运行整个应用程序。

——《Docker Compose - 菜鸟教程》


安装 Docker Compose
这部分,我们在这里仅介绍Linux的安装步骤,Windows和MacOS已经在Docker Desktop之中内置了Docker Compose的功能,如果你有其他特殊的需求,也可以参考官方文档。

基本上来说,只需要这两条命令即可:

sudo curl -L "https://github.com/docker/compose/releases/download/<版本号>/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose

如果你使用的是Ubuntu系统,那么安装的步骤则会变得更为简单:

sudo apt install docker-compose

在安装完成后,我们可以通过下面的命令检查是否安装成功

docker-compose --version

配置文件
接下来,我们聊聊配置文件,也就是Docker Compose的核心部分,在这里我们设计了两个服务,一种为源文件构造,另一种是拉取现有的镜像部署。

# docker-compose.yml
version: "3.9"

services: # 定义服务
web: # Web 应用
build: ./app # 使用 ./app 目录下的 Dockerfile 构建镜像
command: flask run --host=0.0.0.0 --port=5000 # 启动 Flask 应用
ports:
- "8000:5000" # 本机8000端口映射到容器5000端口
environment:
# 数据库连接URL,这里通过服务名 db 连接 Postgres
DATABASE_URL: postgresql://postgres:${POSTGRES_PASSWORD}@db:5432/${POSTGRES_DB}
depends_on:
db:
condition: service_healthy # 等待数据库健康检查通过再启动

db: # 数据库服务(PostgreSQL)
image: postgres:16 # 使用官方 Postgres 16 镜像
restart: unless-stopped # 意外退出时自动重启
environment:
POSTGRES_USER: postgres # 数据库用户名
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD} # 从 .env 文件读取密码
POSTGRES_DB: ${POSTGRES_DB} # 默认数据库名
volumes:
- db_data:/var/lib/postgresql/data # 数据持久化,保存到数据卷 db_data 之中
healthcheck: # 健康检查,保证数据库可用
test: ["CMD-SHELL", "pg_isready -U postgres -d ${POSTGRES_DB}"]
interval: 5s
timeout: 3s
retries: 10

volumes: # 定义数据卷
db_data: # PostgreSQL 的数据卷

Service - Web服务(从源文件构造)
我们以Web服务为例,这里我们设计了一个Python Flask项目作为示例:

web: # Web 应用服务(Flask 示例)
build: ./app # 使用 ./app 目录下的 Dockerfile 构建镜像
command: flask run --host=0.0.0.0 --port=5000 # 启动 Flask 应用
ports:
- "8000:5000" # 本机8000端口映射到容器5000端口
environment:
# 数据库连接URL,这里通过服务名 db 连接 Postgres
DATABASE_URL: postgresql://postgres:${POSTGRES_PASSWORD}@db:5432/${POSTGRES_DB}
depends_on:
db:
condition: service_healthy # 等待数据库健康检查通过再启动


build:指定构建镜像的目录(./app 里需要有 Dockerfile)。
command:覆盖容器启动命令,这里用flask启动了一个允许所有IP访问的,端口为5000的服务端。


注意:这里应该允许所有IP访问(0.0.0.0),而不是只允许本地访问(127.0.0.1),否则会导致无法从外部连接到容器。



ports:端口映射,本机 8000 → 容器 5000。
env_file:从 .env 文件读取环境变量。
environment:额外定义的环境变量,在这里我们设置了数据库地址。
depends_on:表示依赖关系,这里web服务要等到db服务通过了健康检查,才会启动。

Services - db服务(拉取现有的镜像)

db: # 数据库服务(PostgreSQL)
image: postgres:16 # 使用官方 Postgres 16 镜像
restart: unless-stopped # 意外退出时自动重启
environment:
POSTGRES_USER: postgres # 数据库用户名
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD} # 从 .env 文件读取密码
POSTGRES_DB: ${POSTGRES_DB} # 默认数据库名
volumes:
- db_data:/var/lib/postgresql/data # 数据持久化,保存到卷 db_data
healthcheck: # 健康检查,保证数据库可用
test: ["CMD-SHELL", "pg_isready -U postgres -d ${POSTGRES_DB}"]
interval: 5s
timeout: 3s
retries: 10


image:使用构建好的镜像。这里我们固定了版本为16,如果使用latest可能会导致新旧版本的兼容性导致问题。
restart:容器异常退出后会自动重启。
environment:POSTGRES_USER/POSTGRES_PASSWORD/POSTGRES_DB 仅在第一次初始化数据目录时生效。之后数据由卷持久化,再改这些变量不会重置已有库。
volumes:用 命名卷(db_data)作为文件的存储,后面说映射到容器内的存储目录。
healthcheck

CMD-SHELL:表示这条命令会在容器的 shell 里执行(相当于 bash -c)。
pg_isready:这是 PostgreSQL 自带的一个小工具,用来检测数据库是否可以连接。
-U postgres:指定用 postgres 这个用户去检测。
-d ${POSTGRES_DB}:指定要检测的数据库名字(这里我们使用的是变量,会从 .env 文件读取同名的环境变量值)。

数据卷
在 Docker Compose 中,数据卷的定义通常放在最底部的 volumes...

View original post
突然感觉自己挺贱的
LINUX DO - 热门话题 (RSS)

初一的时候就喜欢过一个女孩,但她已经有了男朋友,我一直让自己不要想她,但一直无法抑制

昨日下午,与之和其他同学闲玩,她没有骑车,因为要去的地方远,我们都准备让人带着她,她男朋友不在,而除了她和另一个女生以外都是男生,可另一个女生是自行车,所以就想让我们带着她,当时我的同学想让我带着她,但我有一些那个就拒绝了,她坐了另一辆同学的车,我拒绝了,但我却又不甘心

明明说着无欲无求,要好好学习,好好为中国的未来做出努力,但我每一次看到她就忍不住,就心浮躁

并且她有男朋友,而且比我优秀,他和她都比我优秀(主要就是我英语太差了)

想着努力却从来没有主动努力过,想着勇敢却从来没有勇敢过,一个想着努力学习未来为国家出力,为共产主义努力,但从来没有实现过,这就是我,一个废物

感觉自己挺贱的

愿自己早日真正的无欲无求,放弃情场,一心向党

26 个帖子 - 25 位参与者

阅读完整话题