AI

AI工具比较

在AI技术加速发展的今天，我们面对着一系列性能優积、功能多样化的AI工具和平台。本文将深入测评目前流行皆与AI相关的六大平台：ChatGPT、Gemini、Claude、Microsoft Copilot、Poe 以及 Perplexity。 一、ChatGPT – 行业领头者的表现 由 OpenAI 打造的 ChatGPT 早在 2022 年末间间出亮。它操作界面简洁，最新的 GPT-4o 版本支持图片解析、互动形式多样。它对于文本生成、代码调试和备储知识有着极高的出版率。 优势： 不足： 二、Gemini – Google 的多模态应用性探索 前身为 Bard 的 Gemini 是 Google 打造的应用型 AI平台。Gemini 2.5 Pro 已于这些月日正式揭票，支持视频、图片、音频和文本同时分析，为使用者带来全新体验。 优势： 不足： 三、Claude – 远达性实力舍的智能对话者 Anthropic 发展的 Claude 系列 AI 模型对于“精细化体验”、“论证性思维”有着明显优势。Claude 3 系列在文本辅助、分析件任务中成绩亮眼，是很多创意人士的黑马选择。 优势： 不足： 四、Microsoft Copilot …

Wireless

Arch KDE开启热点

在使用 KDE Plasma 桌面环境创建无线热点的过程中，可能会遇到一系列复杂的问题。以下是一次完整的排查与解决过程，涵盖所有常见的故障点、错误理解以及最终有效的解决方案，供其他用户参考。 场景概述 用户在 Arch Linux + KDE Plasma 桌面环境中尝试通过图形界面开启无线热点（Hotspot）功能，但遇到以下主要问题： 遇到的问题与错误路径 1. 热点卡在 “Setting network address” 误区排查： 实际原因： 2. 切换为 IWD 后端仍无法创建热点 误区排查： 实际问题： 3. KDE 创建热点时默认名称始终为 “hp” 错误假设： 实际来源： 解决方法： 4. KDE Hotspot 按钮无法设置密码 误解： 真实情况： 正确的解决方案与推荐做法 ✅ 安装和启用 dnsmasq 确保 NetworkManager 可以在热点中启用 DHCP 功能。 ✅ 避免使用 …

IoT

NodeMCU 深度技术解析

NodeMCU 是一种低成本的开源物联网开发平台，包含运行于乐鑫 ESP8266/ESP32 Wi-Fi 芯片上的固件以及对应的开发板硬件。最初 NodeMCU 专指基于 ESP8266 的 Lua 脚本固件和配套开发板，后来也增加了对 ESP32 芯片的支持。NodeMCU 开发板延续了经典设计：以 ESP-12 模块为核心，板载 USB 转串口接口、电源管理、电路保护等，使开发者能方便地通过 USB 供电和下载程序，并将全部 I/O 引出到两侧排针。下面将从架构、编程、接口、通信、应用、功耗、安全等方面对 NodeMCU 进行全面解析，帮助有经验的开发者更高效地使用这一平台。 NodeMCU 硬件架构与芯片分析 ESP8266 vs ESP32 架构差异：NodeMCU 开发板核心可选择 ESP8266 或 ESP32 芯片，它们在架构上有明显区别。ESP8266 内部采用 32 位 Tensilica Xtensa L106 单核处理器（最高主频 80–160 MHz），集成了 802.11 b/g/n Wi-Fi射频模块。ESP32 则升级为 32 位 Tensilica Xtensa LX6 双核处理器，主频高达 …

Wireless

查看 Linux 无线网卡状态与连接情况

在 Linux 系统中，可以使用 iw 工具来查看无线网卡（Wi-Fi 接口）的详细状态。以下是一次典型的查看输出，并结合其含义进行解读。 无线网卡接口列表 使用 iw dev 命令查看无线设备信息时，系统中检测到了两个物理无线设备：phy#0 和 phy#1。每个物理设备上挂载有不同的接口： phy#1： phy#0： 无线连接状态查看 可以使用 iw dev <接口名> link 命令查看各个接口的连接状态。 小结 通过 iw dev 和 iw dev <接口名> link 可以有效了解 Linux 系统中无线网卡的状态、信道分布、带宽宽度以及实际连接信息。此次输出显示设备成功通过 ap0 接口连接到了一个 5GHz 网络，连接稳定且速率较高。而其他接口（如 wlan0）当前未连接。 这种信息对于网络故障排查、接口管理或性能优化具有重要意义。

Wireless

Arch KDE 无法连接 5GHz WiFi 的一个解决案例

在 Arch Linux（KDE 桌面环境）中，使用绿联 AX900 无线蓝牙一体网卡时，出现了无法连接 5GHz WiFi 的问题，而 2.4GHz WiFi 则可以正常连接。连接 5GHz 网络时，NetworkManager 报错： 该错误意味着系统在尝试连接 WiFi 时，没有可用的认证代理（agent）来提供密码或授权信息。 问题分析 尽管系统已重启，但 NetworkManager 并未正常识别或连接到认证代理，导致连接 5GHz WiFi 时失败。重启 NetworkManager 后，连接立即恢复正常，表明问题并不在驱动或硬件层面，而是出在认证组件的初始化顺序或加载状态。 解决方法 执行以下命令后，问题解决： 该命令重启了网络管理器服务，使其重新连接到 KDE 的 polkit 认证代理，从而能够完成 WiFi 密码认证过程。 补充排查信息 使用 iw 工具检查无线连接状态： 输出信息如下（部分脱敏）： 表示无线网卡已成功连接到 5GHz 信道，且使用 80 MHz 的信道宽度，处于高速传输状态。 进一步查看连接详情： 可以获得信号强度、连接速率、数据传输情况等详细信息。 总结 …

Troubleshooting

处理错误 0x80070091：无法删除空文件夹的解决方案（VHDX 虚拟磁盘环境下）

在使用 Windows 系统时，遇到错误代码 0x80070091 的情况并不少见。该错误通常出现在尝试删除某个看似空文件夹时，系统却提示“目录非空”。这一问题尤其常见于运行在 VHDX 虚拟磁盘中的系统环境中。 以下是一种经过验证的解决流程，适用于这种特定场景，且成功删除了无法正常移除的文件夹。 问题背景 在一个基于 VHDX 虚拟磁盘运行的 Windows 系统中，某路径下的文件夹（示例路径：C:\…\WinSxS\Temp\InFlight\{GUID}）显示为空，但无法删除。系统提示如下错误信息： 即使在安全模式下或使用管理员权限，也无法正常移除该目录。 处理步骤 1. 使用 WinPE 启动 通过一个含有 Windows PE 的 U 盘启动设备，进入轻量级的系统维护环境。 2. 挂载 VHDX 系统镜像 3. 进入目标路径 4. 创建临时文件 5. 尝试删除文件夹 技术原理简析 此类问题的根本原因在于 NTFS 元数据损坏或残留信息异常，使系统误判目录状态。 通过在目标目录中执行一次写入操作（如创建文件），可强制系统刷新该目录的结构信息，从而将其状态更新为“真正空”，进而允许删除。 结语 该方法简单有效，特别适用于运行在 VHDX 虚拟磁盘中的 Windows 系统环境。当常规删除手段失效且提示目录非空时，可尝试此方案解决问题。

Drivers

Windows 系统中的 PortableOperatingSystem 注册表项与便携系统识别逻辑

在某些使用 WinToUSB 或 Windows To Go 部署的系统中，注册表中会出现一个名为 PortableOperatingSystem 的键项。这个键值长期以来被用于标识系统是否运行在 USB 或其他便携式存储设备上，其设置会直接影响 Windows 对当前系统环境的判断与处理逻辑。 键项位置与含义 注册表路径如下： 键名： 可选值： 该值由 Windows To Go 安装程序或第三方工具（如 WinToUSB）设置，用于控制系统行为。 系统行为影响 当此项被设置为 1 时，系统将启用一系列与便携系统相关的限制或适配逻辑，例如： 而当设置为 0 时，系统将被完全视为运行在本地硬盘上，功能完整，不受便携系统限制。 现代环境中的兼容性考量 虽然 Windows To Go 功能在新版本系统中已被弃用，但系统组件（如安装器、升级助手）仍会保留对 PortableOperatingSystem 的判断逻辑。因此： 此逻辑未随功能废弃而移除，仍影响升级与部署体验。 关于安全性与实际建议 对于运行在 USB 固态设备上的系统，为防止误触发 BitLocker 自动加密（尤其是在家庭版 Windows 中默认启用 BitLocker 的情况），保留 PortableOperatingSystem …

Arch

系统更新后的一次日志解读：从软件包到内核重启

最近一次系统更新完成后，系统输出了一系列日志内容。记录显示，共有 265 个软件包进行了更新，包括 VLC 播放器、图形相关组件（如 vulkan、webkit2gtk）、Zoom、yt-dlp、Zotero 等常用软件。其中，VLC 增加了一些新的可选插件支持，如字幕渲染（vlc-plugin-freetype）、系统通知（vlc-plugin-notify）以及对 .srt 字幕文件的支持（vlc-plugin-srt）。 除了软件包升级之外，系统还自动执行了一系列 “post-transaction hooks”（事务后处理脚本），确保更新后的系统稳定运行。这些操作包括： 其中一个关键步骤是 DKMS（动态内核模块支持）模块的安装。日志中显示，安装了两个模块： 这两个模块都针对内核版本 6.15.9-arch1-1 进行了编译，随后使用 depmod 更新模块依赖信息。 接下来的步骤是构建内核启动镜像（initramfs）： 完成所有任务后，系统显示当前内核版本为 6.15.7-arch1-1，而不是新安装的 6.15.9-arch1-1。 这表明虽然新内核和所有更新已经完成，但系统还没有重启。因此，新的内核和驱动模块尚未生效。 建议操作 执行以下命令以启用新内核并使驱动生效： 重启完成后，可以通过以下命令验证当前使用的内核： 预期输出应为： 这代表系统已经成功切换到新内核，并启用了最新的驱动和更新配置。

Storage

观察 Timeshift 清理快照的系统行为

在 Linux 系统中，Timeshift 常用于系统快照的备份与恢复。某些环境下，Timeshift 被配置为每小时执行一次快照清理任务。为了更好地了解该过程的具体行为，对其中一个自动执行的删除操作进行了系统调用级别的追踪，以下是相关分析与记录。 系统环境概述 通过以下命令观察当前运行的 Timeshift 相关进程： 输出内容显示，Timeshift 正在执行 –check –scripted，并调用 rm -rfv 删除某一旧快照目录，例如： -v 参数指明删除过程中应输出详细信息，但由于进程在后台运行，终端中无法直接查看这些输出。 使用 strace 实时追踪删除行为 为了监控实际被删除的文件，使用 strace 对目标 rm 进程进行追踪： 执行后，会实时输出每个文件或目录的删除调用。例如： 这些系统调用清楚表明了： 整个追踪过程涵盖了多个 Python 包构建文件、配置文件、用户目录内容等。 删除任务完成的标志 追踪结束时，可以观察到如下信息： 表示整个快照目录已被删除，进程以退出码 0 正常结束。 应用建议 示例追踪脚本 该脚本自动查找正在运行的 Timeshift 删除任务并将其行为保存至日志。 总结 通过系统调用追踪工具如 strace，可以清晰地掌握 Timeshift 删除快照的全过程，包括具体文件、删除顺序及执行结果。这种方式为系统维护提供了更高的可见性，也有助于后期审计和排障。

Storage

删除 Timeshift 异常快照的一次实践

在日常使用 Timeshift 管理 Linux 系统备份的过程中，可能会遇到某次快照因中断或系统异常而未能正常完成，导致该快照在软件界面中无法显示，但在文件系统中依然占据空间。这种情况下，如何安全地手动删除该快照，并确认不会影响其他快照，是很多用户关心的问题。 Timeshift 快照原理简介 Timeshift 的 RSYNC 模式使用硬链接机制来存储多个快照之间相同的文件。这意味着： 硬链接的一个核心特点是：没有“原始文件”和“链接文件”的区分，所有链接对等。因此，删除某个快照中的文件，不会影响其他快照中的相同文件。 删除未完成快照的实际操作 通过命令行查看 Timeshift 快照目录： 若发现某些目录未出现在 Timeshift GUI 中，如： 可以判断这些为未完成或异常的快照。此时，可以安全地使用以下命令手动删除它们： 虽然其中大部分是硬链接文件，系统仍需处理所有目录项，因此删除过程可能较慢。尤其在文件数量极多（如含 Flatpak 或 Python 包）时，即使数据不大，系统也要逐个清理路径与 inode 引用，导致删除过程可能持续几分钟。 删除过程中断的情况分析 若删除过程中重启了系统，有可能终端未显示删除完成，但重启后快照目录已经消失。这种情况通常有两个可能： 此时，只需检查 /timeshift/snapshots/ 目录，确认目标目录是否确实已消失。若目录不在，说明已删除干净，无需额外操作。 小结 如需进一步优化批量清理或自动化处理，可以编写简单脚本实现更高效的快照管理。