DuckBurnIncense's Blog

在 KDE Dolphin 的右键菜单中增加选项

Mon, 30 Mar 2026 00:00:00 GMT

每次想在指定目录下打开 VS Code 都得用 Open Terminal Here 选项开一个终端, 再敲 code . 来在当前目录下打开 VS Code, 实在是太不方便了. 有没有方法直接往右键菜单塞东西呢?

有的兄弟有的, 根据 KDE Dolphin 文档, 我们可以往 ~/.local/share/kservices5/ServiceMenus/ 里面塞一个 desktop 文件, 按照文档中说明的格式写好后, 就能在右键菜单里新增一个选项了.

以下是教程:

(下面的方法仅在 Dolphin Version 23.08.5, KDE Plasma Version 5.27.12 测试过, 不保证通用性)

如果文件夹不存在 (默认不存在), 创建一下

$ mkdir -p ~/.local/share/kservices5/ServiceMenus/

新增一个 desktop 文件, 这里我就叫 open_in_vscode.desktop 了

$ vim ~/.local/share/kservices5/ServiceMenus/open_in_vscode.desktop

写入下列内容

[Desktop Entry]
Type=Service
ServiceTypes=KonqPopupMenu/Plugin
MimeType=inode/directory;
Actions=openinvscode
X-KDE-Priority=TopLevel

[Desktop Action openinvscode]
Name=Open in VS Code
Icon=code
Exec=code "%u"

完成, 就是这么简单, 现在在 Dolphin 里右键, 应该能看到一个叫做 Open in VS Code 的选项:

如果没看到的话, 可以在 Dolphin 设置里修改:

终于不用再敲 code . 了~

离线迁移 Ollama 中的特定模型：导出为解压即可使用的 tar.gz 文件

Mon, 19 Jan 2026 00:00:00 GMT

我们经常希望在断网情况下迁移 Ollama 的模型文件, 网上能找到的方法通常都是直接复制粘贴整个 OLLAMA_MODELS 文件夹, 这固然可以, 但是会迁移 Ollama 里的所有模型. 当我们仅希望迁移其中某一个模型时, 这个方法就非常的不友好了, 一是文件过大, 过多, 迁移过程非常缓慢; 二是里面有很多我们并不需要的模型, 在迁移过后我们还得把他们删掉, 且若目标磁盘空间不足以容纳所有模型, 还会导致迁移失败.

进一步地, 网上就出现了通过 ollama show --modelfile 查询模型文件位置, 再迁移修改时间相近的文件的方法, 但此方法仍存在问题: 当多个模型同时依赖一个文件时, 就会导致新的模型依赖旧的文件, 此时再根据修改时间判断, 就会导致迁移不完全.

那么, Ollama 是怎么判断需要哪些文件的呢?

技术论证 & 手动传输示例

通过查阅 Ollama 源代码可知, Ollama 将模型分别存储在 OLLAMA_MODELS 下的 blobs 和 manifests 下, 其中 manifests 下按照 registry/namespace/repo/tag 存储模型的 manifest; blobs 下存储模型 layer 的二进制文件.

以迁移 deepseek-r1:8b 为例

让我们看看它的 manifest 里写了啥:

$ sudo cat $OLLAMA_MODELS/manifests/registry.ollama.ai/library/deepseek-r1/8b | jq
{
  "schemaVersion": 2,
  "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
  "config": {
    "mediaType": "application/vnd.docker.container.image.v1+json",
    "digest": "sha256:f64cd5418e4b038ef90cf5fab6eb7ce6ae8f18909416822751d3b9fca827c2ab",
    "size": 487
  },
  "layers": [
    {
      "mediaType": "application/vnd.ollama.image.model",
      "digest": "sha256:e6a7edc1a4d7d9b2de136a221a57336b76316cfe53a252aeba814496c5ae439d",
      "size": 5225373760
    },
    {
      "mediaType": "application/vnd.ollama.image.template",
      "digest": "sha256:c5ad996bda6eed4df6e3b605a9869647624851ac248209d22fd5e2c0cc1121d3",
      "size": 556
    },
    {
      "mediaType": "application/vnd.ollama.image.license",
      "digest": "sha256:6e4c38e1172f42fdbff13edf9a7a017679fb82b0fde415a3e8b3c31c6ed4a4e4",
      "size": 1065
    },
    {
      "mediaType": "application/vnd.ollama.image.params",
      "digest": "sha256:ed8474dc73db8ca0d85c1958c91c3a444e13a469c2efb10cd777ca9baeaddcb7",
      "size": 179
    }
  ]
}

不难发现, JSON 中各digest 对应 $OLLAMA_MODELS/blobs 下各 sha256- 开头的文件. 不过其中 config.digest 最为可疑, 单独一个字段存着, 让我们看看里面是啥:

$ sudo cat /usr/share/ollama/.ollama/models/blobs/sha256-f64cd5418e4b038ef90cf5fab6eb7ce6ae8f18909416822751d3b9fca827c2ab | jq
{
  "model_format": "gguf",
  "model_family": "qwen3",
  "model_families": [
    "qwen3"
  ],
  "model_type": "8.2B",
  "file_type": "Q4_K_M",
  "architecture": "amd64",
  "os": "linux",
  "rootfs": {
    "type": "layers",
    "diff_ids": [
      "sha256:e6a7edc1a4d7d9b2de136a221a57336b76316cfe53a252aeba814496c5ae439d",
      "sha256:c5ad996bda6eed4df6e3b605a9869647624851ac248209d22fd5e2c0cc1121d3",
      "sha256:6e4c38e1172f42fdbff13edf9a7a017679fb82b0fde415a3e8b3c31c6ed4a4e4",
      "sha256:ed8474dc73db8ca0d85c1958c91c3a444e13a469c2efb10cd777ca9baeaddcb7"
    ]
  }
}

看起来像是描述模型用的, 且下面的 rootfs.diff_ids 内容与 layers[].digest 完全一致, 不需要额外处理.

那就好办了, 在当前 Ollama 的实现下, 只需要把 manifest 里有的 digest 全部迁移, 就能跑了:

scp $OLLAMA_MODELS/blobs/sha256-f64cd5418e4b038ef90cf5fab6eb7ce6ae8f18909416822751d3b9fca827c2ab root@another-server:/path/to/OLLAMA_MODELS/blobs/
scp $OLLAMA_MODELS/blobs/sha256-e6a7edc1a4d7d9b2de136a221a57336b76316cfe53a252aeba814496c5ae439d root@another-server:/path/to/OLLAMA_MODELS/blobs/
scp $OLLAMA_MODELS/blobs/sha256-c5ad996bda6eed4df6e3b605a9869647624851ac248209d22fd5e2c0cc1121d3 root@another-server:/path/to/OLLAMA_MODELS/blobs/
scp $OLLAMA_MODELS/blobs/sha256-6e4c38e1172f42fdbff13edf9a7a017679fb82b0fde415a3e8b3c31c6ed4a4e4 root@another-server:/path/to/OLLAMA_MODELS/blobs/
scp $OLLAMA_MODELS/blobs/sha256-ed8474dc73db8ca0d85c1958c91c3a444e13a469c2efb10cd777ca9baeaddcb7 root@another-server:/path/to/OLLAMA_MODELS/blobs/

别忘了还有 manifest 本身:

scp $OLLAMA_MODELS/manifests/registry.ollama.ai/library/deepseek-r1/8b root@another-server:/path/to/OLLAMA_MODELS/manifests/registry.ollama.ai/library/deepseek-r1/

接下来到目标服务器

确认一下传输是否成功:

$ ollama pull deepseek-r1:8b
pulling manifest 
pulling e6a7edc1a4d7: 100% ▕█████████████████████████████████▏ 5.2 GB                         
pulling c5ad996bda6e: 100% ▕█████████████████████████████████▏  556 B                         
pulling 6e4c38e1172f: 100% ▕█████████████████████████████████▏ 1.1 KB                         
pulling ed8474dc73db: 100% ▕█████████████████████████████████▏  179 B                         
pulling f64cd5418e4b: 100% ▕█████████████████████████████████▏  487 B                         
verifying sha256 digest 
writing manifest 
success

pull 应该瞬间完成, 虽然 CLI 仍会显示 pulling 进度, 但如果 blobs 已存在, 实际不会发生网络下载.

看看新模型, 应该已经在列表里了:

$ ollama list
NAME                                           ID              SIZE      MODIFIED      
deepseek-r1:8b                                 6995872bfe4c    5.2 GB    6 seconds ago

直接 run, 也能跑得起来, 证明迁移成功:

$ ollama run deepseek-r1:8b
>>> Send a message (/? for help)

但是你要是说: 主播主播, 一个个手动复制粘贴 sha256, 再 scp 还是太吃操作了, 有没有更简便一点的操作?

自动传输

有的兄弟有的, 我也嫌麻烦, 于是写了个脚本:

开源仓库链接： 👉 https://github.com/DuckBurnIncense/ollama-model-exporter.sh

这个脚本可以全自动帮你处理好上述过程，给你打包一个能够直接传过去、解压就能用的 tar.gz 文件。

使用方法:

1. 安装依赖

脚本依赖以下工具, 请确保已安装:

bash >= 4
curl
jq
tar

如果不会装, 请看开源仓库的 README

2. 下载脚本

$ curl -O https://raw.githubusercontent.com/DuckBurnIncense/ollama-model-exporter.sh/refs/heads/master/ollama-model-exporter.sh
$ chmod +x ollama-model-exporter.sh

3. 导出模型为 tar.gz

sudo ./ollama-model-exporter.sh deepseek-r1:8b ./deepseek-r1-8b.tar.gz

执行完成后, 会生成一个结构完全符合 Ollama 官方目录布局的压缩包.

如果你只是想看看脚本会打包哪些文件，可以使用 dry-run：

sudo ./ollama-model-exporter.sh --dry-run deepseek-r1:8b ./deepseek-r1-8b.tar.gz

4. 在目标服务器恢复模型

在目标服务器上, 确认 OLLAMA_MODELS 目录 (通常是下面两个之一):

/usr/share/ollama/.ollama/models
~/.ollama/models

如果不是, 那就自行确认吧, 一般在 ollama.service 文件的环境变量里会写

然后直接解压:

tar -xzf ./deepseek-r1-8b.tar.gz -C /usr/share/ollama/.ollama/models

注意: 一定要解压到 OLLAMA_MODELS 目录本身, 而不是它的父目录!

5. 验证模型是否可用

ollama pull deepseek-r1:8b

如果 blobs 已存在, 这一步会非常快, 主要是校验 manifest.

然后:

ollama list
ollama run deepseek-r1:8b

能正常跑起来, 就说明迁移成功

核心原理

这个脚本的核心思路其实非常简单, 本质就是把 Ollama 自己 "认为是一个模型的最小集合" 精确地打包出来.

总结下来就是 5 步:

调用 Ollama HTTP API

http://localhost:11434/api/show

判断模型是否存在, 并获取 modelfile

从 modelfile 中解析 FROM /path/to/blobs/sha256-*

由此反推出 OLLAMA_MODELS 根目录
不依赖硬编码路径, 适配系统安装与用户安装

定位模型 manifest

manifests/registry.ollama.ai/<namespace>/<repo>/<tag>

解析 manifest

读取 config.digest
读取 layers[].digest
得到模型真正依赖的全部 sha256

只打包必要文件

manifests/.../<tag>
blobs/sha256-*
使用 tar -C "$OLLAMA_MODELS" 压缩所有需要的文件

最终得到的 tar.gz：

不多
不少
不包含无关模型
不依赖修改时间
可直接解压复用

总结

如果你只是想整机备份, 直接复制整个 OLLAMA_MODELS 当然没问题; 但如果你像我一样, 只想精确迁移某一个模型, 尤其是在:

离线环境
带宽有限, 重新 pull 很慢
模型很多

的情况下，这种基于 manifest 精确依赖分析 的方式, 会靠谱得多

希望这篇文章能帮你少浪费点时间

(脚本有问题欢迎提 Issue, (我应该没写 bug 吧...?))

分析并解决新安全限制导致 Ubuntu 24.04 下运行 electron 的 AppImage 报错 The SUID sandbox helper binary was found, but is not configured correctly

Wed, 07 Jan 2026 00:00:00 GMT

复现方法

使用如下命令, 运行我刚构建好的 electron 程序:

$ chmod +x ./my-electron-app.AppImage
$ ./my-electron-app.AppImage

报错如下

[26568:0107/005131.867292:FATAL:sandbox/linux/suid/client/setuid_sandbox_host.cc:166] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /tmp/.mount_LyuKLU/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap (core dumped)

按照提示, 最佳的解决方案应该是:

$ sudo chown root:root /tmp/.mount_LyuKLU/chrome-sandbox
$ sudo chmod 4755 /tmp/.mount_LyuKLU/chrome-sandbox

然而, 显然 /tmp/.mount_LyuKLU 是一个临时目录, 在程序运行结束后就被销毁掉了, 我们无法卡时机, 在文件被创建后, 被执行前修改其权限, 因此需要一些变通方案.

报错原因

通过查询资料, 得知这是 Ubuntu 24.04 为了增加安全性所改进的限制, 在 Ubuntu 24.04 发行说明中有提及: Unprivileged user namespace restrictions. 文中提到: Ubuntu 内核现在限制了无特权用户命名空间的使用, 这影响系统上所有无特权和未限制的程序.

解决方案

对于此类问题, 解决方案基本有四种:

修复文件权限 (不适用上文场景)

$ sudo chown root:root /path/to/chrome-sandbox
$ sudo chmod 4755 /path/to/chrome-sandbox

使用 AppArmor 配置 (不适用上文场景)

根据Ubuntu 24.04 发行说明与 AppArmor 文档,

AppArmor 新增了一个 unconfined 配置模式 / 标志, 该模式将配置指定为基本上像 AppArmor 的无限制模式, 其中应用程序不受限制, 并允许添加额外的权限, 例如 userns, 权限.

例如: 对于 chrome, 编辑 /etc/apparmor.d/chrome 配置文件如下:

abi <abi/4.0>,

include <tunables/global>

/opt/google/chrome/chrome flags=(unconfined) {
  userns,

  # Site-specific additions and overrides. See local/README for details.
  include if exists <local/chrome>
}

使用 `--no-sandbox` 选项

最方便, 但不建议

直接使用 --no-sandbox 选项运行 AppImage:

$ ./my-electron-app.AppImage --no-sandbox

关闭安全限制

关闭后, 会存在无特权用户命名空间功能的内核漏洞, 不建议

临时关闭:

$ sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

永久关闭:

$ echo "kernel.apparmor_restrict_unprivileged_userns=0" | sudo tee /etc/sysctl.d/60-apparmor-namespace.conf
$ sudo sysctl -p /etc/sysctl.d/60-apparmor-namespace.conf

参考资料:

https://discourse.ubuntu.com/t/ubuntu-24-04-lts-noble-numbat-release-notes/39890#p-99950-unprivileged-user-namespace-restrictions

https://github.com/electron/electron/issues/42510#issuecomment-2171583086

https://github.com/arduino/arduino-ide/issues/2429#issuecomment-2099775010

必应搜索引擎收录使用 DNS CNAME 验证子域名一直无法检测到 CNAME 记录的解决方案

Mon, 08 Dec 2025 00:00:00 GMT

闲着没事想给本站搞个搜索引擎收录, 由于以前有过在 Bing Webmaster Tools 提交网站的经验, 于是首选了 bing.

这里因为要收录 blog.duckburnincense.com, 因此当然是直接填写:

然后来到验证页面, 三种验证方式, 因为我这是自动构建的静态网站, 若选择前两种验证方案, 我还得修改网站内容, 重新 push 到 GitHub, 再自动 build 才能用. 因此我选择了向 DNS 中添加 CNAME 记录来验证.

页面要求向 DNS 中添加一条名为 e6943c76455e2e78a7e06a7d2b4befc6e6943c76455e2e78a7e06a7d2b4befc6 的, 指向 verify.bing.com 的 CNAME 记录, 因此, 我理所应当地添加了 DNS 记录:

随后等待一段时间, 点击提交验证按钮, 提示未找到 CNAME 记录. 此时我还以为是 DNS 还未传播, 于是随后多次等待, 提交, 均无果:

然后我突然想起来, 我加的是 blog.duckburnincense.com 而不是 duckburnincense.com, 因此应该向 blog.duckburnincense.com 添加 CNAME 记录, 因此 DNS 管理器中的 name 中应该填写 e6943c76455e2e78a7e06a7d2b4befc6e6943c76455e2e78a7e06a7d2b4befc6.blog:

随后再次点击验证按钮, 验证成功.

导出 Microsoft Authenticator 中的 2FA 密钥

Wed, 19 Nov 2025 00:00:00 GMT

注意: 此方法需要你具有你的手机的 root 权限

我在电脑上一直用浏览器拓展 "Authenticator" 来管理 2FA 密钥, 然而前日我在新电脑上登了 Firefox 账号, 并删除了 Firefox 自动同步到新电脑上的 Authenticator 拓展 (因为我觉得我在这个电脑上并不需要 Authenticator), 然而 Firefox 又将 "删除 Authenticator 拓展" 这一行为同步到了旧电脑上, 于是我在电脑上的 2FA 就丢失了...

好在我手机上的 Microsoft Authenticator 还存在 2FA 的 TOTP 代码, 可是 MS Authenticator 官方似乎并没有提供导出密钥的方法, 不过还好, 我有 root 权限. 于是我们尝试直接读取其数据库获得密钥.

第一步: 连上手机, 获得 root shell:

在手机 root 管理器中启用 Shell 的 root 权限, 随后 adb 连接到手机:

$ adb shell
phone:/ $ su

第二步: 找到存储密钥的数据库

不难想到, 这么机密的东西, 肯定是存储在应用私有目录下的

phone:/ # cd /data/data/com.azure.authenticator/

可是这么多数据, 哪个里面才存了真实密钥呢?

不妨将页面上显示的账户名中的 DSM 作为关键词搜索:

phone:/data/data/com.azure.authenticator # grep -r "DSM" . | head -n 1
Binary file ./databases/PhoneFactor-wal matches

找到了 /data/data/com.azure.authenticator/databases/PhoneFactor-wal, 里面疑似存储着密钥

第三步: 打开数据库

猜测这是一个数据库文件, 于是试图直接打开该文件, 未果, 那么看看 ./databases/ 下还有啥:

phone:/data/data/com.azure.authenticator # ls ./databases/
AppIdDomainMapping             LabellingData-wal       VerifiableCredential-wallet-db                   experimentation_database           passkey_database_table-wal
AppIdDomainMapping-shm         MfaLibrary              VerifiableCredential-wallet-db-shm               experimentation_database-shm       payment_card_db
AppIdDomainMapping-wal         MfaLibrary-shm          VerifiableCredential-wallet-db-wal               experimentation_database-wal       payment_card_db-shm
AriaStorage.db                 MfaLibrary-wal          app_policy_database                              generator_history_db               payment_card_db-wal
AriaStorage.db-journal         PUDSSchemaDatabase      app_policy_database-shm                          generator_history_db-shm           shared_core_database
EnterpriseDenyListMapping      PUDSSchemaDatabase-shm  app_policy_database-wal                          generator_history_db-wal           shared_core_database-shm
EnterpriseDenyListMapping-shm  PUDSSchemaDatabase-wal  com.google.android.datatransport.events          google_app_measurement.db          shared_core_database-wal
EnterpriseDenyListMapping-wal  PhoneFactor             com.google.android.datatransport.events-journal  google_app_measurement.db-journal
LabellingData                  PhoneFactor-shm         com.microsoft.appcenter.persistence              passkey_database_table
LabellingData-shm              PhoneFactor-wal         com.microsoft.appcenter.persistence-journal      passkey_database_table-shm

注意到, 该目录下还有 PhoneFactor 文件, 并且通过十六进制编辑器查看, 很明显这是一个 Sqlite 3 数据库

于是单独将 PhoneFactor 复制到电脑并打开. accounts 表共有五条记录, 其他 2FA 密钥都在里面, 唯独没有 "DSM" 那条密钥

猜测其与 PhoneFactor-shm 和 PhoneFactor-wal 文件是一对, 需要同时打开. 前往 Sqlite 官网查找文档, 确认了猜测:

4.6. WAL-Index Format Conceptually, the wal-index is shared memory, though the current VFS implementations use a memory-mapped file for operating-system portability. The memory-mapped file is in the same directory as the database and has the same name as the database with a "-shm" suffix appended. Because the wal-index is shared memory, SQLite does not support journal_mode=WAL on a network filesystem when clients are on different machines, as all clients of the database must be able to share the same memory. ...

简而言之

-wal 文件‌: 保存未提交的写操作日志, 支持多线程并发写入, 避免传统日志锁定. 当数据库崩溃时, 可通过 WAL 文件恢复未提交的更改.
‌-shm 文件: 共享内存文件, 用于协调多线程对 WAL 文件的访问, 确保数据一致性.

于是将其都复制到电脑上

$ ls
PhoneFactor          PhoneFactor-shm          PhoneFactor-wal

打开数据库:

$ sqlite3 ./PhoneFactor
SQLite version 3.45.1 2024-01-30 16:01:20
Enter ".help" for usage hints.
sqlite>

第四步: 提取密钥

先来点格式操作: 开启标题行, 改变输出格式

sqlite> .headers on
sqlite> .mode column

看看都有哪些表:

sqlite> .tables
accounts           android_metadata   room_master_table

很明显有个 accounts 表, 查看其结构:

sqlite> .schema accounts
CREATE TABLE `accounts` (
  `_id` INTEGER PRIMARY KEY AUTOINCREMENT,
  `group_key` TEXT NOT NULL,
  `name` TEXT NOT NULL,
  `username` TEXT NOT NULL,
  `paws_url` TEXT NOT NULL,
  `oath_secret_key` TEXT NOT NULL,
  `oath_enabled` INTEGER NOT NULL,
  `cid` TEXT NOT NULL,
  `cached_pin` TEXT NOT NULL,
  `ngc_ski` TEXT NOT NULL,
  `aad_user_id` TEXT NOT NULL,
  `aad_tenant_id` TEXT NOT NULL,
  `account_type` INTEGER NOT NULL,
  `account_capability` INTEGER NOT NULL,
  `ux_position` INTEGER NOT NULL,
  `is_totp_code_shown` INTEGER NOT NULL,
  `encrypted_oath_secret_key` TEXT NOT NULL,
  `mfa_pin_encryption_key_alias` TEXT NOT NULL,
  `identity_provider` TEXT NOT NULL,
  `aad_ngc_totp_enabled` INTEGER NOT NULL,
  `aad_authority` TEXT NOT NULL,
  `restore_capability` INTEGER NOT NULL,
  `has_password` INTEGER NOT NULL,
  `aad_security_defaults_policy_enabled` INTEGER NOT NULL,
  `phone_app_detail_id` TEXT NOT NULL,
  `replication_scope` TEXT NOT NULL,
  `activated_device_token` TEXT NOT NULL,
  `routing_hint` TEXT NOT NULL,
  `tenant_country_code` TEXT NOT NULL,
  `data_boundary` TEXT NOT NULL,
  `puid` TEXT NOT NULL
);

编写 SQL, 查询所有显示名称, 用户名与密钥:

sqlite> SELECT name, username, oath_secret_key FROM accounts;
name             username                                         oath_secret_key                 
---------------  -----------------------------------------------  --------------------------------
Website1         duckburnincense1@duckburnincense.com             QlYxR0o0MTF4N2g3                
Website2         duckburnincense2@duckburnincense.com             QlYxR0o0MTF4N2g3                
Website3         duckburnincense3@duckburnincense.com             QlYxR0o0MTF4N2g3                
Website4         duckburnincense4@duckburnincense.com             QlYxR0o0MTF4N2g3                
Website5         duckburnincense5@duckburnincense.com             QlYxR0o0MTF4N2g3
Synology DSM     duckburnincense6@duckburnincense.com             QlYxR0o0MTF4N2g3

oath_secret_key 列即为 2FA 密钥.

至此, 折腾结束, 将 oath_secret_key 逐个导入新的 2FA 管理器即可 (Authenticator 拓展: 对, 就是我~)

在虚拟机中的 Docker 运行 FunASR 时加载模型时一直卡住不动的解决方案

Fri, 07 Nov 2025 00:00:00 GMT

在一个 KUbuntu 物理机上测试 FunASR 通过后, 在另一台 Windows 电脑的 VMware 中运行了一个全新 KUbuntu 24.04 LTS, 安装 docker 后依据官方文档运行, 最后卡在了

FunASR  | I20251107 00:52:19.264511    56 funasr-wss-server-2pass.cpp:555] SSL is closed!
FunASR  | I20251107 00:52:19.325332    56 fsmn-vad.cpp:58] Successfully load model from /workspace/models/damo/speech_fsmn_vad_zh-cn-16k-common-onnx/model_quant.onnx
FunASR  | I20251107 00:52:20.740871    56 paraformer.cpp:77] Successfully load model from /workspace/models/damo/speech_paraformer-large_asr_nat-zh-cn-16k-common-vocab8404-online-onnx/model_quant.onnx
FunASR  | I20251107 00:52:21.095985    56 paraformer.cpp:85] Successfully load model from /workspace/models/damo/speech_paraformer-large_asr_nat-zh-cn-16k-common-vocab8404-online-onnx/decoder_quant.onnx
FunASR  | I20251107 00:52:23.210389    56 paraformer.cpp:142] Successfully load model from /workspace/models/damo/speech_paraformer-large-vad-punc_asr_nat-zh-cn-16k-common-vocab8404-onnx/model_quant.onnx

这里. 通过打开 VMware 的处理器虚拟化, 成功继续往下跑了一行:

FunASR  | I20251107 00:52:28.818928    56 paraformer.cpp:160] Successfully load lm file /workspace/models/damo/speech_ngram_lm_zh-cn-ai-wesp-fst/TLG.fst

随后又卡住了. 通过将虚拟机的内存从 4G 调整到 8G, 成功继续运行下去了:

FunASR  | I20251107 00:52:29.558418    56 ct-transformer-online.cpp:21] Successfully load model from /workspace/models/damo/punc_ct-transformer_zh-cn-common-vad_realtime-vocab272727-onnx/model_quant.onnx
FunASR  | I20251107 00:52:29.671496    56 itn-processor.cpp:33] Successfully load model from /workspace/models/thuduj12/fst_itn_zh/zh_itn_tagger.fst
FunASR  | I20251107 00:52:29.672539    56 itn-processor.cpp:35] Successfully load model from /workspace/models/thuduj12/fst_itn_zh/zh_itn_verbalizer.fst
FunASR  | I20251107 00:52:29.672549    56 websocket-server-2pass.cpp:596] initAsr run check_and_clean_connection
FunASR  | I20251107 00:52:29.672608    56 websocket-server-2pass.cpp:599] initAsr run check_and_clean_connection finished
FunASR  | I20251107 00:52:29.672616    56 funasr-wss-server-2pass.cpp:571] decoder-thread-num: 12
FunASR  | I20251107 00:52:29.672619    56 funasr-wss-server-2pass.cpp:572] io-thread-num: 1
FunASR  | I20251107 00:52:29.672623    56 funasr-wss-server-2pass.cpp:573] model-thread-num: 1
FunASR  | I20251107 00:52:29.672626    56 funasr-wss-server-2pass.cpp:574] asr model init finished. listen on port:10095

因此, 故障原因就是内存不足. 增加虚拟机的内存即可解决.

GitHub 上有关于此问题的 issue, 但处于 open 状态: modelscope/FunASR#2649

(当时还以为是什么玄学问题, 物理机上能跑起来, 虚拟机里就不行 —— docker 可是以稳定著称的啊, 排查了一下午)

Docker import, load, export, save 的区别

Fri, 07 Nov 2025 00:00:00 GMT

我知道你知道这些命令不一样, 但你还记得哪里不一样吗?

docker import / docker export: 导入导出 container's filesystem (容器的文件系统), 容器文件系统不包括原始镜像的任何元数据或配置信息.
- 例如: docker import /path/to/filesystem.tar your/filesystem: 导入 /path/to/filesystem.tar 中的镜像到 docker 的 your/filesystem
- 例如: docker export -o /path/to/filesystem.tar your/filesystem: 将 docker 中的 your/filesystem 导出到 /path/to/filesystem.tar
docker load / docker save: 导入导出 images (镜像)
- 例如: docker load -i /path/to/image.tar: 导入 /path/to/image.tar 中的镜像到 docker
- 例如: docker save -o /path/to/image.tar your/image:s: 将 docker 中的 your/image:s 镜像导出到 /path/to/image.tar

下面给出 help

docker import --help

Usage:  docker import [OPTIONS] file|URL|- [REPOSITORY[:TAG]]

Import the contents from a tarball to create a filesystem image

Aliases:
  docker image import, docker import

Options:
  -c, --change list       Apply Dockerfile instruction to the created image
  -m, --message string    Set commit message for imported image
      --platform string   Set platform if server is multi-platform capable

docker export --help

Usage:  docker export [OPTIONS] CONTAINER

Export a container's filesystem as a tar archive

Aliases:
  docker container export, docker export

Options:
  -o, --output string   Write to a file, instead of STDOUT

docker load --help

Usage:  docker load [OPTIONS]

Load an image from a tar archive or STDIN

Aliases:
  docker image load, docker load

Options:
  -i, --input string   Read from tar archive file, instead of STDIN
  -q, --quiet          Suppress the load output

docker save --help

Usage:  docker save [OPTIONS] IMAGE [IMAGE...]

Save one or more images to a tar archive (streamed to STDOUT by default)

Aliases:
  docker image save, docker save

Options:
  -o, --output string   Write to a file, instead of STDOUT

我为啥突然要写这个文章? 因为我通过 docker save 导出了我制作的一个镜像, 然后拿到另一台机器上下意识地通过 docker import 导入, 然后镜像死活开不起来, 一直报错 error response from daemon no command specified. 于是我尝试 docker run -it image /bin/bash, 结果 bash 也没有, 随后试了 sh 等也不存在, 遂怀疑镜像传输过程中损坏, 但校验 sha256 发现并没有. 折腾了一晚上, 最后 docker inspect image 发现空荡荡的 (尤其是 entrypoint 也没有, 对应报错中的 no command specified), 才意识到可能是导入镜像做错了...

二次打包 FunASR 官方镜像使其可一键运行

Fri, 07 Nov 2025 00:00:00 GMT

根据官方文档, FunASR 启动方式如下:

sudo docker pull registry.cn-hangzhou.aliyuncs.com/funasr_repo/funasr:funasr-runtime-sdk-online-cpu-0.1.13
mkdir -p ./funasr-runtime-resources/models
sudo docker run -p 10096:10095 -it --privileged=true \
  -v $PWD/funasr-runtime-resources/models:/workspace/models \
  registry.cn-hangzhou.aliyuncs.com/funasr_repo/funasr:funasr-runtime-sdk-online-cpu-0.1.13

运行后会进入容器的 bash, 需要再输入下面的命令:

cd FunASR/runtime
nohup bash run_server_2pass.sh \
  --download-model-dir /workspace/models \
  --vad-dir damo/speech_fsmn_vad_zh-cn-16k-common-onnx \
  --model-dir damo/speech_paraformer-large-vad-punc_asr_nat-zh-cn-16k-common-vocab8404-onnx  \
  --online-model-dir damo/speech_paraformer-large_asr_nat-zh-cn-16k-common-vocab8404-online-onnx  \
  --punc-dir damo/punc_ct-transformer_zh-cn-common-vad_realtime-vocab272727-onnx \
  --lm-dir damo/speech_ngram_lm_zh-cn-ai-wesp-fst \
  --itn-dir thuduj12/fst_itn_zh \
  --hotword /workspace/models/hotwords.txt > log.txt 2>&1 &

才能运行.

所以, 目标: 使其可通过 docker compose up 命令一键启动.

编写 run.sh 如下, 用于启动服务器:

#!/bin/bash

# 进入工作目录
cd /workspace/FunASR/runtime

# 后台运行服务 (自行调整你需要的参数)
nohup bash run_server_2pass.sh \
  --download-model-dir /workspace/models \
  --vad-dir damo/speech_fsmn_vad_zh-cn-16k-common-onnx \
  --model-dir damo/speech_paraformer-large-vad-punc_asr_nat-zh-cn-16k-common-vocab8404-onnx  \
  --online-model-dir damo/speech_paraformer-large_asr_nat-zh-cn-16k-common-vocab8404-online-onnx  \
  --punc-dir damo/punc_ct-transformer_zh-cn-common-vad_realtime-vocab272727-onnx \
  --lm-dir damo/speech_ngram_lm_zh-cn-ai-wesp-fst \
  --itn-dir thuduj12/fst_itn_zh \
  --hotword /workspace/models/hotwords.txt > log.txt 2>&1 &

# 输出日志
tail -f log.txt

编写 Dockerfile 如下:

# 引用基础镜像
FROM registry.cn-hangzhou.aliyuncs.com/funasr_repo/funasr:funasr-runtime-sdk-online-cpu-0.1.13
# 设置时区
ENV TZ=Asia/Shanghai
# 声明端口
EXPOSE 10095/tcp
# 复制刚才创建的用于启动服务器的文件
COPY run.sh /run.sh
# 给予执行权限
RUN chmod +x /run.sh
# 设置入口点
ENTRYPOINT ["/run.sh"]

构建镜像:

$ docker build . -t myfunasr:v1

编写 docker-compose.yaml:

services:
  funasr:
    image: myfunasr:v1
    container_name: funasr
    restart: unless-stopped
    # 我也不知道为什么官方文档要 --privileged=true,
    # 我觉得过于不安全, 没加, 但也能跑. 因此加不加取决于你
    privileged: true
    ports:
      - 10096:10095
    volumes:
      - "./funasr-runtime-resources/models:/workspace/models"

docker compose up -d, enjoy it~

参考文章: https://www.cnblogs.com/shizidushu/p/18381237

表情包收集

Sat, 04 Oct 2025 00:00:00 GMT

注: 除非注明为原创, 否则本页面所有图片 (表情包) 均由网络收集而来. 原创表情包遵循 CC BY 4.0 许可协议.

HTTP 5xx 喜报 (原创):

JS 报错喜报 (原创):

Java 喜报:

胡言乱语 - USB 插 RJ45 (原创):

胡言乱语 I2C UART

牛头不对马嘴 - USB 插 RJ45 (原创):

前端查数据库

IQ Boost Pro Max+

Python: raise

没日志也没截图, 只能帮你算一卦

PCL 报错提示弹窗

提问价格表 1

提问价格表 2

死神微软

HyperOS: 不流畅, 巨卡

Deepseek: 人类的怪问题怎么那么多

Data Cloud & Serverless

Appdata dir

今天是 520, 我没有配耦

520 过了, 我还是没有配耦

买 Mac 打游戏

Trump 报纸

补湿哥们

不要让学生毕业后成为电子文盲

sudo rm -rf /* 符

以前的各种接口 vs 现在的各种 Type-C 接口

JS 隐式类型转换

Steam 超级管家

向土豆服务器祈祷

Choose one

全员禁言

Stack pop

滑稽 CAD

滑稽 104 电容

西数红盘: 祝您在新的一年红红火火

聊天开始 I2C

聊天停止 I2C

Go 语言 return

网络爬虫路由器

谷歌验证码: 找出所有 bugs

如何百度

在线解压

电车难题: 重构屎山

千与千寻: 汤婆婆 SQL 注入

进度: 我自己做

进度: 正在做了

进度: 快快去做

如何截图: 别拍屏幕

CPU: 听说你低血压

给酒精灯加热

STC 金鼎

窃格瓦拉: MySQL 从删库到跑路

Explorer: 脑子未响应

89C51 滑稽跑马灯

VSCode: 上号

VSCode: 我在线上了

VSCode: 敲你妈不敲了

VSCode: 写你妈不写了

淘宝精选: 电容手雷

Carpet 通过命令获取 MC 服务器 MSPT 及 TPS 数据

Fri, 03 Oct 2025 00:00:00 GMT

先定义两个函数

/script run mspt()->(for(last_tick_times(),tot_mspt+=_);tot_mspt/100);
/script run tps()->return(1000/mspt());

然后就可以获取数据了:

获取 MSPT:

/script run mspt()

获取 TPS:

/script run mspt()

说明: 此处的 TPS 为当前 MSPT 可承载的最大 TPS 数, 如当前 MSPT 为 1, 无 tick 加速. 此时获取的 TPS 并非 20, 而是 1000 / 1 = 1000.

参考资料:

fabric-carpet#433

对于给定网络地址划分指定数量子网及计算子网的详细信息的保姆级教程

Thu, 18 Sep 2025 00:00:00 GMT

来看下面这道题目：

IP 地址 192.168.10.0/24
划分 4 个子网
分别写出第一个、第二个、第三个、第四个子网的掩码、网络地址、广播地址、可用地址范围、可用地址数量

先把 IP 地址转换成二进制：

1100 0000.1010 1000.0000 1010.0000 0000

上面二进制里的空格只是为了方便阅读

删掉小数点，这东西只会影响你计算

1100 0000 1010 1000 0000 1010 0000 0000

接下来看子网掩码：

题中 “24” 是网络前缀，同样也是在描述子网掩码，只是方法不一样：

24 是指从前往后有 24 个二进制的 1

IP（IPv4）地址和子网掩码都是 32 位（二进制数）的长度

因此，“24” 写出来也就是：

1111 1111 1111 1111 1111 1111 0000 0000

如果你想看 255.255.255.0 这种形式，可以把上面的二进制每八位加一个小数点

1111 1111.1111 1111.1111 1111.0000 0000

再每段分别转成十进制

255.255.255.0

这样就能互相转换了

接下来回到正题：

IP 地址：1100 0000 1010 1000 0000 1010 0000 0000
子网掩码：1111 1111 1111 1111 1111 1111 0000 0000

根据题目，我们需要在这个 /24 里划分 4 个子网，因此借用一点主机位。

主机位是啥：

看子网掩码：

1111 1111 1111 1111 1111 1111 0000 0000
++++ ++++ ++++ ++++ ++++ ++++ ==== ====

其中，1（也就是下面有“+”的位）代表网络位，0 代表主机位（也就是下面有“=”的位）

如何在 IP 地址中体现出来？

将 IP 地址和子网掩码两者逐位进行与运算。与运算是啥？

A AND B = C

若 A 和 B 都是 1，则 C 为 1

否则（A 或 B 任意一个为 0），C 为 0

例如：

1 AND 1 = 1
0 AND 1 = 0
1 AND 0 = 0
0 AND 0 = 0

那么，我们把 IP 和掩码列出来，逐位进行与运算

（第一行为 IP，第二行为掩码，第四行是与运算的结果）

1100 0000 1010 1000 0000 1010 0000 0000
1111 1111 1111 1111 1111 1111 0000 0000
==== ==== ==== ==== ==== ==== ==== ====
1100 0000 1010 1000 0000 1010 0000 0000

不要关心结果，自己算一下，注意过程。不难发现，只要子网掩码里有 0，结果就一定是 0；子网掩码里是 1，结果就取决于 IP。这样子网掩码就成功地“掩”上了主机位，只剩下了网络位

也就是无论主机位怎么变化，都能被“掩”上，不会影响网络位

如果你还是没注意到，看这（这个例子的 IP 是我随便写的，不用关心）：

这些（%）下面的数字，
全部都是原样搬到结果里面 ↓        ↓ 这里无论是什么，都不会在结果里
%%%% %%%% %%%% %%%% %%%% %%%% ↓↓↓↓ ↓↓↓↓
1100 0000 1010 1000 0000 1010 1010 0101
1111 1111 1111 1111 1111 1111 0000 0000 ← 这里是 0
==== ==== ==== ==== ==== ==== ==== ====
1100 0000 1010 1000 0000 1010 0000 0000
#### #### #### #### #### #### ↑↑↑↑ ↑↑↑↑
这些（#）上面的数字，            ↑ 结果永远是 0
全部都是原样来自于 IP 里面

那主机位是啥？

就是被掩上的部分，比如最开始的题目里，被掩上的就是 0000 0000；上一个例子里，是 1010 0101

我知道你现在很想把它们都写成点分十进制，但你别写，用二进制算。

回到最开始的题目：

我们需要在这个 /24 里划分 4 个子网，因此需要借用一点主机位来划分子网。

如何确定要借用多少位？

先来看：如果借用 1 位（二进制位），则只有：

0
1

那么只有两个子网，显然不够，继续：

借用 2 位：

有四个子网了，够了

假设我们要划 7 个子网，还不够咋办？接着划。此时借用 3 位：

现在有 8 个子网，够了。

可以注意到，借用 n 位得到的可用子网数量就是 2 的 n 次方

比如借用 1 位，数量是 2 的 1 次方，就是 2；

借用 2 位，2 的 2 次方，就是 4；

借用 3 位，2 的 3 次方，就是 8。以此类推

回到借用 2 位：

那么我们的子网掩码就由

1111 1111 1111 1111 1111 1111 0000 0000

变成了

1111 1111 1111 1111 1111 1111 1100 0000
                              ↑↑

因此借用完成后的子网掩码转换成点分十进制就是

255.255.255.192

好了，忘掉这个点分十进制吧，用二进制

可以注意到，我们借用了两位主机位，用来划分子网：

1111 1111 1111 1111 1111 1111 1100 0000
                              ↑↑

那么放到 IP 地址里看就是这样：

                              ↓ 这两位
                              ↓↓
1100 0000 1010 1000 0000 1010 0000 0000

两个空位，0 和 1 排列组合：

也套到 IP 地址里：

                              ↓ 这两位
                              ↓↓
1100 0000 1010 1000 0000 1010 0000 0000
1100 0000 1010 1000 0000 1010 0100 0000
1100 0000 1010 1000 0000 1010 1000 0000
1100 0000 1010 1000 0000 1010 1100 0000

这就是我们划分出的四个子网了。

如果你就是想看点分十进制，它们依次是：

192.168.10.0
192.168.10.64
192.168.10.128
192.168.10.192

接下来来看网络地址、广播地址、可用地址范围

首先，网络地址就是主机位全是 0 的地址：

                                ↓ 这六位是主机位
                                ↓↓ ↓↓↓↓
1100 0000 1010 1000 0000 1010 0000 0000
1100 0000 1010 1000 0000 1010 0100 0000
1100 0000 1010 1000 0000 1010 1000 0000
1100 0000 1010 1000 0000 1010 1100 0000
                              ↑↑
                              ↑ 这两位是刚才借走拿去划子网的主机位，
                                现在它们不属于主机位了，叫做子网位

如上，“这六位是主机位” 的箭头所指向的就是主机位，下面的箭头是我们借用了原来的 2 位主机位，这两位现在不再代表主机，而是用来标识子网，我们称之为"子网位"

因此，新的网络前缀是 24（原网络位） + 2（子网位） = 26 位。剩下的 6 位才是新的主机位

主机位全 0 就是网络地址，因此，它们的网络地址就是

1100 0000 1010 1000 0000 1010 0000 0000
1100 0000 1010 1000 0000 1010 0100 0000
1100 0000 1010 1000 0000 1010 1000 0000
1100 0000 1010 1000 0000 1010 1100 0000

点分十进制：

192.168.10.0
192.168.10.64
192.168.10.128
192.168.10.192

请注意，第一个子网的网络地址（192.168.10.0）和原始网络的网络地址是相同的，这是正常现象

广播地址是主机位全是 1 的 IP 地址：

                                ↓ 这六位是主机位
                                ↓↓ ↓↓↓↓
1100 0000 1010 1000 0000 1010 0011 1111
1100 0000 1010 1000 0000 1010 0111 1111
1100 0000 1010 1000 0000 1010 1011 1111
1100 0000 1010 1000 0000 1010 1111 1111
                              ↑↑
                              ↑ 这两位是刚才借走拿去划子网的主机位，
                                现在它们不属于主机位了

因此，它们的广播地址写成点分十进制就是：

192.168.10.63
192.168.10.127
192.168.10.191
192.168.10.255

接下来来看可用地址范围。一个网段除了全 0（网络地址）和全 1（广播地址），其余均可使用

因此，以

1100 0000 1010 1000 0000 1010 0000 0000

（192.168.10.0）为例，它的可用范围就是

                                ↓ 注意这里
                                ↓↓ ↓↓↓↓
1100 0000 1010 1000 0000 1010 0000 0000 ← 这个主机位全 0，是网络地址，用不了
1100 0000 1010 1000 0000 1010 0000 0001 ← (注意看主机位：000001) 从这开始
1100 0000 1010 1000 0000 1010 0000 0010
太多了列不完省略部分...
1100 0000 1010 1000 0000 1010 0011 1101
1100 0000 1010 1000 0000 1010 0011 1110 ← (注意看主机位：111110) 一直到这，都可以用 
1100 0000 1010 1000 0000 1010 0011 1111 ← 这个主机位全 1，是广播地址，用不了

因此，可用地址数量就是 6 位二进制数不重复的情况下能排列组合出的所有数字减掉 2（全 0 和全 1），也就是 2 的六次方减 2 = 64 - 2 = 62

可用地址范围（转成点分十进制）就是

192.168.10.1 ~ 192.168.10.62

以此类推，四个子网的可用地址范围就是

192.168.10.1 ~ 192.168.10.62
192.168.10.65 ~ 192.168.10.126
192.168.10.129 ~ 192.168.10.190
192.168.10.193 ~ 192.168.10.254

所以题目最终的答案就是：

子网	子网掩码	网络地址	广播地址	可用地址范围	可用地址数量
子网 1	255.255.255.192	192.168.10.0	192.168.10.63	192.168.10.1 ~ 192.168.10.62	62
子网 2	255.255.255.192	192.168.10.64	192.168.10.127	192.168.10.65 ~ 192.168.10.126	62
子网 3	255.255.255.192	192.168.10.128	192.168.10.191	192.168.10.129 ~ 192.168.10.190	62
子网 4	255.255.255.192	192.168.10.192	192.168.10.255	192.168.10.193 ~ 192.168.10.254	62

<!-- <br><br><br>

Author: DuckBurnIncense

Last edit: 2025-09-18 20:30

This work is licensed under Creative Commons Attribution-NonCommercial 4.0 International. To view a copy of this license, visit https://creativecommons.org/licenses/by-nc/4.0/

(End) -->

常用空间搜索引擎备忘录

Tue, 18 Feb 2025 00:00:00 GMT

Censys: Censys 联网设备信息搜索引擎

FOFA.so: FOFA.so 网络空间搜索引擎, Query Credits 300/month, 3k Results/month

ZoomEye: 每月最大查询结果数 3,000, 最大可查看页数 5

360 网络空间资产测绘: 360 QUAKE 网络空间资产测绘

Spyse: Spyse - 互联网资产搜索引擎

Shodan: Shodan 网络空间设备搜索引擎

ONYPHE: ONYPHE - Cyber Defense Search Engine

DNSDB: DNSDB - 全球 DNS 搜索引擎

鹰图: 鹰图平台 (hunter) - 奇安信网络空间测绘系统

FullHunt: FullHunt | Expose Your Attack Surface

Hunter: Full Port Coverage, Up to 10,000 API Results per 30 Days, Daily Query Limit 100

DuckBurnIncense's Blog

在 KDE Dolphin 的右键菜单中增加选项

离线迁移 Ollama 中的特定模型：导出为解压即可使用的 tar.gz 文件

技术论证 & 手动传输示例

自动传输

使用方法:

1. 安装依赖

2. 下载脚本

3. 导出模型为 tar.gz

4. 在目标服务器恢复模型

5. 验证模型是否可用

核心原理

总结

分析并解决新安全限制导致 Ubuntu 24.04 下运行 electron 的 AppImage 报错 The SUID sandbox helper binary was found, but is not configured correctly

复现方法

报错原因

解决方案

修复文件权限 (不适用上文场景)

使用 AppArmor 配置 (不适用上文场景)

使用 --no-sandbox 选项

关闭安全限制

必应搜索引擎收录使用 DNS CNAME 验证子域名一直无法检测到 CNAME 记录的解决方案

导出 Microsoft Authenticator 中的 2FA 密钥

第一步: 连上手机, 获得 root shell:

第二步: 找到存储密钥的数据库

第三步: 打开数据库

第四步: 提取密钥

在虚拟机中的 Docker 运行 FunASR 时加载模型时一直卡住不动的解决方案

Docker import, load, export, save 的区别

二次打包 FunASR 官方镜像使其可一键运行

表情包收集

HTTP 5xx 喜报 (原创):

JS 报错喜报 (原创):

Java 喜报:

胡言乱语 - USB 插 RJ45 (原创):

胡言乱语 I2C UART

牛头不对马嘴 - USB 插 RJ45 (原创):

前端查数据库

IQ Boost Pro Max+

Python: raise

没日志也没截图, 只能帮你算一卦

PCL 报错提示弹窗

提问价格表 1

提问价格表 2

死神微软

HyperOS: 不流畅, 巨卡

Deepseek: 人类的怪问题怎么那么多

Data Cloud & Serverless

Appdata dir

今天是 520, 我没有配耦

520 过了, 我还是没有配耦

买 Mac 打游戏

Trump 报纸

补湿哥们

不要让学生毕业后成为电子文盲

sudo rm -rf /* 符

以前的各种接口 vs 现在的各种 Type-C 接口

JS 隐式类型转换

Steam 超级管家

向土豆服务器祈祷

Choose one

全员禁言

Stack pop

滑稽 CAD

滑稽 104 电容

西数红盘: 祝您在新的一年红红火火

聊天开始 I2C

聊天停止 I2C

Go 语言 return

网络爬虫路由器

谷歌验证码: 找出所有 bugs

如何百度

在线解压

电车难题: 重构屎山

千与千寻: 汤婆婆 SQL 注入

进度: 我自己做

进度: 正在做了

进度: 快快去做

如何截图: 别拍屏幕

CPU: 听说你低血压

使用 `--no-sandbox` 选项