Inbox

pnpm - 高效的 Node.js 包管理器 pnpm 简介 pnpm (performant npm) 是一个快速、节省磁盘空间的 JavaScript 包管理器，作为 npm 和 yarn 的替代方案。它通过创建硬链接和符号链接的方式来共享依赖，避免重复安装相同的包。 核心特点 节省磁盘空间 所有版本的依赖都存储在硬盘上的单一位置（全局存储目录） 当安装包时，文件会从全局存储硬链接到项目的 node_modules 如果你有 100 个项目使用相同版本的某个依赖，磁盘上只会有这个依赖的一份文件 极快的安装速度 由于使用硬链接，安装过程比 npm 和 yarn 都快 多个项目共享依赖时，速度优势更加明显 严格的依赖解析算法避免了冗余操作 创建非扁平化的 node_modules 使用符号链接创建依赖的嵌套结构 只有 package.json 中声明的依赖才能访问 避免了"幽灵依赖"（phantom dependencies）问题 严格的依赖管理 防止访问未声明的依赖 确保项目的可重现性和安全性 pnpm 工作原理 全局存储 (~/.pnpm-store/) ├── package-a@1.0.0 ├── package-b@2.0.0 └── package-c@3.0.0 ↓ (硬链接) 项目 node_modules/ └── .pnpm/ └── package-a@1.0.0/ └── node_modules/ └── package-a (实际内容) ↓ (符号链接) └── package-a → .pnpm/package-a@1.0.0/node_modules/package-a 与 npm/yarn 的对比 特性 pnpm npm yarn 磁盘空间效率 ⭐⭐⭐⭐⭐ ⭐⭐ ⭐⭐ 安装速度 ⭐⭐⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐⭐ 依赖隔离 ⭐⭐⭐⭐⭐ ⭐⭐ ⭐⭐ Monorepo 支持 ⭐⭐⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐⭐ 严格性 ⭐⭐⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐ pnpm 安装 全局安装 pnpm # 使用 npm 安装 npm install -g pnpm # 使用 Homebrew (macOS/Linux) brew install pnpm # 使用独立脚本安装 curl -fsSL https://get.pnpm.io/install.sh | sh - # Windows (PowerShell) iwr https://get.pnpm.io/install.ps1 -useb | iex 查看版本 pnpm --version pnpm -v pnpm 基本命令 安装依赖 # 安装 package.json 中的所有依赖 pnpm install pnpm i # 安装指定包 pnpm add <package> pnpm add lodash # 安装指定版本 pnpm add lodash@4.17.21 # 安装到 devDependencies pnpm add -D <package> pnpm add --save-dev jest # 全局安装 pnpm add -g <package> pnpm add -g typescript # 安装指定 workspace 包 pnpm add <package> --filter <workspace> 更新依赖 # 更新所有依赖 pnpm update pnpm up # 更新指定包 pnpm update lodash pnpm up lodash # 更新到最新版本（忽略 package.json 中的版本范围） pnpm update --latest pnpm up -L # 交互式更新 pnpm update -i 删除依赖 # 删除指定包 pnpm remove <package> pnpm rm lodash # 删除全局包 pnpm remove -g <package> 查看依赖 # 列出所有依赖 pnpm list pnpm ls # 列出指定包的依赖树 pnpm list <package> # 查看过期的包 pnpm outdated # 查看包信息 pnpm view lodash pnpm info lodash 运行脚本 # 运行 package.json 中定义的脚本 pnpm run <script> pnpm run build pnpm run test # 简写（对于常用命令） pnpm start pnpm test pnpm t 清理缓存 # 清理未被引用的包 pnpm store prune # 查看 store 状态 pnpm store status # 查看 store 路径 pnpm store path 安全审计 # 检查依赖包的安全漏洞（对应 npm audit） pnpm audit # 自动修复漏洞（对应 npm audit fix） pnpm audit --fix # 仅生产环境依赖审计 pnpm audit --prod # 输出 JSON 格式 pnpm audit --json # 审计并显示详细信息 pnpm audit --audit-level=<severity> # severity 可选值: low, moderate, high, critical pnpm audit 与 npm audit 的差异： ...

“video, h.264, h.265, ffmpeg” H.265与H.264是ITU-T VCEG 制定的视频编码标准。H.265标准围绕着现有的视频编码标准H.264，保留原来的某些技术，同时对一些相关的技术加以改进。新技术使用先进的技术用以改善码流、编码质量、延时和算法复杂度之间的关系，达到最优化设置。具体的研究内容包括: 提高压缩效率、提高鲁棒性和错误恢复能力、减少实时的时延、减少信道获取时间和随机接入时延、降低复杂度等。H264由于算法优化，可以低于1Mbps的速度实现标清数字图像传送；H265则可以实现利用1~2Mbps的传输速度传送720P (分辨率1280*720) 普通高清音视频传送。 H.265旨在在有限带宽下传输更高质量的网络视频，仅需H.264的一半带宽即可播放相同质量的视频。H.265标准也同时支持4K(4096×2160)和8K(8192×4320)超高清视频。 H.264 H.264，同时也是MPEG-4第十部分，是由ITU-T视频编码专家组 (VCEG) 和ISO/IEC动态图像专家组 (MPEG) 联合组成的联合视频组 (JVT，Joint Video Team) 提出的高度压缩数字视频编解码器标准。这个标准通常被称之为H.264/AVC (或者AVC/H.264或者H.264/MPEG-4AVC或MPEG-4/H.264 AVC) 而明确的说明它两方面的开发者。 H.264最大的优势是具有很高的数据压缩比率，在同等图像质量的条件下，H.264的压缩比是MPEG-2的2倍以上，是MPEG-4的1.5～2倍。举个例子，原始文件的大小如果为88GB，采用MPEG-2压缩标准压缩后变成3.5GB，压缩比为25∶1，而采用H.264压缩标准压缩后变为879MB，从88GB到879MB，H.264的压缩比达到惊人的102∶1。低码率 (Low Bit Rate) 对H.264的高的压缩比起到了重要的作用，和MPEG-2和MPEG-4ASP等压缩技术相比，H.264压缩技术将大大节省用户的下载时间和数据流量收费。尤其值得一提的是，H.264在具有高压缩比的同时还拥有高质量流畅的图像，正因为如此，经过H.264压缩的视频数据，在网络传输过程中所需要的带宽更少，也更加经济。 H.265, HEVC(高效视频编码) H.265是ITU-TVCEG继H.264之后所制定的新的视频编码标准。H.265标准围绕着现有的视频编码标准H.264，保留原来的某些技术，同时对一些相关的技术加以改进。 新技术使用先进的技术用以改善码流、编码质量、延时和算法复杂度之间的关系，达到最优化设置。具体的研究内容包括: 提高压缩效率、提高鲁棒性和错误恢复能力、减少实时的时延、减少信道获取时间和随机接入时延、降低复杂度等。H264由于算法优化，可以低于1Mbps的速度实现标清数字图像传送；H265则可以实现利用1~2Mbps的传输速度传送720P (分辨率1280*720) 普通高清音视频传送。 H.265旨在在有限带宽下传输更高质量的网络视频，仅需原先的一半带宽即可播放相同质量的视频。这也意味着，我们的智能手机、平板机等移动设备将能够直接在线播放1080p的全高清视频。H.265标准也同时支持4K(4096×2160)和8K(8192×4320)超高清视频。可以说，H.265标准让网络视频跟上了显示屏"高分辨率化"的脚步。 H.265 与 H.264 有何不同 在讨论 H.265有哪些提升和优点之前，我们不妨先来了解一下H.264。H.264 也称作 MPEG-4AVC(Advanced Video Coding，高级视频编码)，是一种视频压缩标准，同时也是一种被广泛使用的高精度视频的录制、压缩和发布格式。H.264 因其是蓝光光盘的一种编解码标准而著名，所有蓝光播放器都必须能解码H.264。更重要的是，因为苹果公司当初毅然决然抛弃了Adobe 的VP6 编码，选择了 H.264，这个标准也就随着数亿台iPad和iPhone 走入了千家万户，成为了目前视频编码领域的绝对霸主，占有超过80%的份额。H.264 也被广泛用于网络流媒体数据、各种高清晰度电视广播以及卫星电视广播等领域。H.264相较于以前的编码标准有着一些新特性，如多参考帧的运动补偿、变块尺寸运动补偿、帧内预测编码等，通过利用这些新特性，H.264比其他编码标准有着更高的视频质量和更低的码率，也因此受到了人们的认可，而被广泛应用。 H.265/HEVC 的编码架构大致上和H.264/AVC的架构相似，也主要包含: 帧内预测(intra prediction)、帧间预测(inter prediction)、转换(transform)、量化(quantization)、去区块滤波器(deblocking filter)、熵编码(entropy coding)等模块。但在HEVC编码架构中，整体被分为了三个基本单位，分別是: 编码单位(coding unit，CU)、预测单位(predict unit，PU)和转换单位(transform unit，TU)。 H.265为 何优于H.264 比起H.264/AVC，H.265/HEVC提供了更多不同的工具来降低码率，以编码单位来说， 最小的8x8到最大的64x64。信息量不多的区域(颜色变化不明显，比如车体的红色部分和地面的灰色部分)划分的宏块较大，编码后的码字较少，而细节多的地方(轮胎)划分的宏块就相应的小和多一些，编码后的码字较多，这样就相当于对图像进行了有重点的编码，从而降低了整体的码率，编码效率就相应提高了。同时，H.265的帧内预测模式支持33种方向(H.264只支持8种)，并且提供了更好的运动补偿处理和矢量预测方法。 反复的质量比较测试已经表明，在相同的图象质量下，相比于H.264，通过H.265编码的视频码流大小比H.264减少大约39-44%。由于质量控制的测定方法不同，这个数据也会有相应的变化。通过主观视觉测试得出的数据显示，在码率减少51-74%的情况下，H.265编码视频的质量还能与H.264编码视频近似甚至更好，其本质上说是比预期的信噪比(PSNR)要好。这些主观视觉测试的评判标准覆盖了许多学科，包括心理学和人眼视觉特性等，视频样本非常广泛，虽然它们不能作为最终结论，但这也是非常鼓舞人心的结果。 目前的HEVC 标准共有三种模式: Main、Main10 和Main Still Picture。Main模式支持8bit色深(即红绿蓝三色各有256个色度，共1670万色)，Main10模式支持10bit色深，将会用于超高清电视(UHDTV)上。前两者都将色度采样格式限制为4: 2: 0。预期将在2014年对标准有所扩展，将会支持4: 2: 2和4: 4: 4采样格式(即提供了更高的色彩还原度)和多视图编码(例如3D立体视频编码)。 ...

“network manager” sudo pacman -S networkmanager sudo systemctl status NetworkManager.service sudo systemctl start NetworkManager.service sudo systemctl restart NetworkManager.service sudo pacman -S nm-connection-editor sudo pacman -S network-manager-applet nmcli device nmcli connection nmcli c delete System policy prevents control of network connections System policy prevents control of network connections System policy prevents modification of network settings for all users< vim /usr/share/polkit-1/actions/org.freedesktop.NetworkManager.policy Open /usr/share/polkit-1/actions/org.freedesktop.NetworkManager.policy with root/sudo privileges and search for the following line: ...

font, 字体 主流编程字体 等宽编程字体特性 编程字体需要具备以下特点： 等宽设计：每个字符宽度相同，便于代码对齐 字符区分度高：容易区分 0O（数字零和字母O）、1lI（数字一、小写L和大写I）等相似字符 连字支持（可选）：将 ->, =>, != 等组合显示为单个符号 编程符号优化：清晰的括号、引号、运算符显示 舒适的行高和字间距：长时间编码不易疲劳 开源免费字体 Cascadia Code 开发者：Microsoft 特点：Windows Terminal 默认字体，支持连字（Cascadia Code PL 变体），包含 Powerline 字形 适用场景：Windows 开发、终端、VS Code 安装：sudo apt install fonts-cascadia-code (Ubuntu/Debian) 官网：https://github.com/microsoft/cascadia-code JetBrains Mono 开发者：JetBrains 特点：专为开发者设计，字符高度区分，支持连字，行高适中 适用场景：IntelliJ IDEA、PyCharm 等 JetBrains IDE 推荐 官网：https://www.jetbrains.com/lp/mono/ Fira Code 开发者：Mozilla（基于 Fira Sans 和 Fira Mono） 特点：最流行的连字编程字体之一，支持 100+ 连字组合 适用场景：喜欢连字效果的开发者 安装：sudo apt install fonts-firacode 官网：https://github.com/tonsky/FiraCode Hack 特点：基于 Bitstream Vera 和 DejaVu，字符区分度极高 适用场景：注重代码可读性，不需要连字 安装：sudo apt install fonts-hack 官网：https://sourcefoundry.org/hack/ Source Code Pro 开发者：Adobe 特点：优雅的设计，6 种字重，清晰的字符 适用场景：喜欢 Adobe 设计风格 安装：sudo pacman -S adobe-source-code-pro-fonts (Arch) 官网：https://adobe-fonts.github.io/source-code-pro/ DejaVu Sans Mono 特点：基于 Vera Sans Mono，Unicode 覆盖广 适用场景：多语言编程，Linux 默认等宽字体 安装：大多数 Linux 发行版预装 Ubuntu Mono 开发者：Canonical 特点：Ubuntu 系统默认等宽字体，字符清晰 适用场景：Ubuntu 用户 Inconsolata 开发者：Raph Levien 特点：简洁紧凑，适合小屏幕 适用场景：小尺寸显示 官网：https://levien.com/type/myfonts/inconsolata.html IBM Plex Mono 开发者：IBM 特点：现代设计，IBM 企业级品质 适用场景：喜欢 IBM 设计语言 官网：https://www.ibm.com/plex/ Iosevka 特点：窄字符设计，同屏显示更多代码 适用场景：喜欢紧凑布局，小屏幕 官网：https://typeof.net/Iosevka/ 商业付费字体 SF Mono 开发者：Apple 特点：macOS 和 Xcode 默认等宽字体 适用场景：macOS 开发者 获取：随 macOS 系统或 Xcode 提供 Operator Mono 开发者：Hoefler & Co. 特点：优雅的意大利斜体，价格较贵（$199+） 适用场景：追求极致美观 官网：https://www.typography.com/fonts/operator/ MonoLisa 特点：专注可读性和长时间编码舒适度 价格：€139 起 官网：https://www.monolisa.dev/ Nerd Fonts 系列 Nerd Fonts 是在流行编程字体基础上打补丁，添加大量图标字形（Font Awesome、Devicons、Octicons 等）。 ...

macOS Basic # uninstal /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/uninstall.sh)" # install /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" brew install maven diskutil list 快捷键 截屏: Command + Shift + 3 显示隐藏文件: Command + Shift + . 将光标移动到行首：control + a 将光标移动到行尾：control + e 清除屏幕：control + l 搜索以前使用命令：control + r 清除当前行：control + u 清除至当前行尾：control + k 单词为单位移动：option + 方向键 terimnal 快捷键 Ctrl + d 删除一个字符，相当于通常的Delete键（命令行若无所有字符，则相当于exit；处理多行标准输入时也表示eof） Ctrl + h 退格删除一个字符，相当于通常的Backspace键 Ctrl + u 删除光标之前到行首的字符 Ctrl + k 删除光标之前到行尾的字符 Ctrl + c 取消当前行输入的命令，相当于Ctrl + Break Ctrl + a 光标移动到行首（Ahead of line），相当于通常的Home键 Ctrl + e 光标移动到行尾（End of line） Ctrl + f 光标向前(Forward)移动一个字符位置 Ctrl + b 光标往回(Backward)移动一个字符位置 Ctrl + l 清屏，相当于执行clear命令 Ctrl + p 调出命令历史中的前一条（Previous）命令，相当于通常的上箭头 Ctrl + n 调出命令历史中的下一条（Next）命令，相当于通常的上箭头 Ctrl + r 显示：号提示，根据用户输入查找相关历史命令（reverse-i-search） Ctrl + w 删除从光标位置前到当前所处单词（Word）的开头 Ctrl + y 粘贴最后一次被删除的单词 ...

spring basic Spring Shell Spring Shell 是一个用于构建交互式命令行应用程序的 Spring 框架，让开发者能够快速创建功能丰富的 CLI 工具。 核心特性： 注解驱动 - 使用 @ShellComponent 和 @ShellMethod 定义命令 自动补全 - Tab 键补全命令和参数 命令历史 - 支持历史命令记录和回溯 内置帮助 - 自动生成帮助文档 Spring Boot 集成 - 无缝集成 Spring Boot 生态 典型使用场景： 管理工具（部署、监控） 数据库客户端 DevOps 工具 微服务管理控制台 简单示例： @ShellComponent public class MyCommands { @ShellMethod("Say hello") public String hello(@ShellOption String name) { return "Hello " + name + "!"; } } 运行后可在交互式 shell 中执行： ...

nodejs basic version current v14.21.3 latest v21.6.2 Node.js 版本管理工具对比 nvm vs fnm 特性 nvm fnm 性能 较慢 (shell 脚本) 快速 (Rust 编写) 启动时间 明显延迟 (每次启动 shell) 几乎无延迟 自动切换 需手动配置 hook 内置支持 --use-on-cd 配置文件 .nvmrc .nvmrc 或 .node-version 跨平台 macOS/Linux macOS/Linux/Windows Windows 支持 需要 nvm-windows (独立项目) 原生支持 项目隔离 支持 (通过 .nvmrc) 支持 (自动检测) 安装速度 较慢 快速 内存占用 较高 较低 成熟度 非常成熟 (2010年) 较新 (2019年) 社区 庞大 增长中 推荐场景: 使用 nvm: 需要最成熟稳定的方案,或团队已在使用 使用 fnm: 追求性能,需要 Windows 支持,或新项目 nvm, Node Version Manager https://github.com/nvm-sh/nvm ...

ubuntu basic 显示器分辨率问题 详细的显示器分辨率问题修复指南已移至专门文档： Ubuntu 显示器分辨率问题修复：手动加载 EDID 固件 该文档包含完整的诊断、修复步骤和故障排除方法。 apt-select # https://pypi.org/project/apt-select/ pip install apt-select apt-select -C JP sudo cp /etc/apt/sources.list /etc/apt/sources.list.backup && sudo mv sources.list /etc/apt/ mirrors http://mirrors.ubuntu.com/ deb, deb-src 不是要看代码或者自己编译的话 deb-src 可以注释掉或者删除 backports proposed security updates 简单的解释： 基础：由于ubuntu是每6个月发行一个新版，当发行后，所有软件包的版本在这六个月内将保持不变，即使是有新版都不更新。除开重要的安全补丁外，所有新功能和非安全性补丁将不会提供给用户更新。 security：仅修复漏洞，并且尽可能少的改变软件包的行为。低风险。 backports：backports 的团队则认为最好的更新策略是 security 策略加上新版本的软件（包括候选版本的）。但不会由Ubuntu security team审查和更新。 update：修复严重但不影响系统安全运行的漏洞，这类补丁在经过QA人员记录和验证后才提供，和security那类一样低风险。 proposed：update类的测试部分，仅建议提供测试和反馈的人进行安装。 个人认为： 1.重要的服务器：用发行版默认的、security 2.当有要较新软件包才行能运作的服务器：用发行版默认的、 security、（backports 还是不适合） 3.一般个人桌面：用发行版默认的、 security、backports、update 4.追求最新、能提供建议和反馈大虾：发行版默认的、 security、backports、update、proposed 全部用上！ Ubuntu 22.04 LTS (Jammy Jellyfish) ubuntu mirror aliyun deb http://mirrors.aliyun.com/ubuntu/ jammy main restricted universe multiverse deb-src http://mirrors.aliyun.com/ubuntu/ jammy main restricted universe multiverse deb http://mirrors.aliyun.com/ubuntu/ jammy-security main restricted universe multiverse deb-src http://mirrors.aliyun.com/ubuntu/ jammy-security main restricted universe multiverse deb http://mirrors.aliyun.com/ubuntu/ jammy-updates main restricted universe multiverse deb-src http://mirrors.aliyun.com/ubuntu/ jammy-updates main restricted universe multiverse deb http://mirrors.aliyun.com/ubuntu/ jammy-proposed main restricted universe multiverse deb-src http://mirrors.aliyun.com/ubuntu/ jammy-proposed main restricted universe multiverse deb http://mirrors.aliyun.com/ubuntu/ jammy-backports main restricted universe multiverse deb-src http://mirrors.aliyun.com/ubuntu/ jammy-backports main restricted universe multiverse 163 deb http://mirrors.163.com/ubuntu/ jammy main restricted universe multiverse deb http://mirrors.163.com/ubuntu/ jammy-security main restricted universe multiverse deb http://mirrors.163.com/ubuntu/ jammy-updates main restricted universe multiverse deb http://mirrors.163.com/ubuntu/ jammy-proposed main restricted universe multiverse deb http://mirrors.163.com/ubuntu/ jammy-backports main restricted universe multiverse vim /etc/apt/sources.list %s/archive.ubuntu.com/mirrors.163.com/g tsinghua deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ jammy main restricted universe multiverse deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ jammy-updates main restricted universe multiverse deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ jammy-backports main restricted universe multiverse deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ jammy-security main restricted universe multiverse # wsl export DISPLAY=172.18.80.1:0 # windows 里ipconfig看到的连接wsl的ip apt install git-svn apt install openjdk-8-jdk apt install maven # config ~/.m2/settings.xml apt install nautilus sudo apt-get install ttf-wqy-microhei #文泉驿-微米黑 sudo apt-get install ttf-wqy-zenhei #文泉驿-正黑 sudo apt-get install xfonts-wqy #文泉驿-点阵宋体 sudo apt install keepassxc 中文乱码问题 # 安装中文支持包language-pack-zh-hans sudo apt-get install language-pack-zh-hans # 设置语言 vim /etc/environment ## 中文语言环境, 设置后 vim 进入编辑状态屏幕下方会显示中文"插入"的那种 LANG="zh_CN.UTF-8" LANGUAGE="zh_CN:zh:en_US:en" ## 英文环境 LANG="en_US.UTF-8" LANGUAGE="en_US:en" vim /var/lib/locales/supported.d/local en_US.UTF-8 UTF-8 zh_CN.UTF-8 UTF-8 zh_CN.GBK GBK zh_CN GB2312 sudo locale-gen # 中文乱码是空格的情况，安装中文字体解决 sudo apt-get install fonts-droid-fallback ttf-wqy-zenhei ttf-wqy-microhei fonts-arphic-ukai fonts-arphic-uming https://blog.csdn.net/weixin_39792252/article/details/80415550 ...

Linux 桌面环境 Linux 桌面环境（Desktop Environment，简称 DE）是运行在 Linux 操作系统上的图形用户界面，提供窗口管理、文件管理、系统设置等功能。 流行的 Linux 桌面环境 GNOME 官网：https://www.gnome.org/ 特点：现代化设计，简洁优雅，注重工作流程 默认用于：Fedora、Ubuntu（自 17.10 起）、Debian 技术栈：GTK KDE Plasma 官网：https://kde.org/plasma-desktop/ 特点：高度可定制，功能丰富，类似 Windows 的操作体验 默认用于：Kubuntu、openSUSE、KDE neon 技术栈：Qt Xfce 官网：https://xfce.org/ 特点：轻量级，资源占用低，适合老旧硬件 默认用于：Xubuntu、Manjaro Xfce 技术栈：GTK 桌面环境对比 桌面环境 资源占用 可定制性 适合人群 GNOME 中高 中 追求现代化体验的用户 KDE Plasma 中 高 喜欢定制的高级用户 Xfce 低 中 老旧硬件用户 GTK 与 Qt 技术栈 Linux 桌面应用主要基于两种 GUI 工具包： 技术栈 使用的桌面环境 代表应用 GTK GNOME、Xfce、Cinnamon、MATE Firefox、GIMP、Thunar Qt KDE Plasma Dolphin、Konsole、VLC 跨技术栈运行 GTK 应用可以在 Qt 桌面（如 KDE）运行，反之亦然。应用程序只需安装一次，所有桌面环境共享。 ...

幼儿园防拐骗专题安全演练 背景说明 我家孩子所在的幼儿园小班需要进行一次防拐骗专题安全演练活动，邀请我扮演"坏叔叔"。因为我家孩子在小三班，为了避免被认出来，我要去小一班或者小二班进行演练。 目标群体：幼儿园小班（3-4 岁儿童） 演练目标：骗几个小朋友到幼儿园一楼大厅就算骗成功，然后老师会进行劝说和教育。 现有道具：一些气球 3-4 岁儿童特点： 认知能力：对陌生人概念模糊，容易被玩具、食物吸引 语言理解：能听懂简单指令，但逻辑思维能力弱 情感特征：好奇心强，容易相信成人，缺乏危险意识 社交行为：喜欢模仿同伴，从众心理明显 自我保护：基本没有防范意识，需要通过反复练习建立 演练剧本 场景一：物质诱惑法（气球诱惑） 时间：上午活动时间 地点：小一班教室外走廊或教室内 方案对比： 方式 优点 缺点 成功率预估 门口经过 更真实（模拟陌生人在公共区域）孩子需要主动走出教室教室内老师可能看不清门口情况 吸引力较弱孩子可能不敢离开教室 30-50% 走进教室 直接接触，吸引力强更容易建立互动近距离诱惑效果好 不够真实（陌生人不会随意进教室）老师可能会提前干预 60-80% 推荐方案：分阶段进行 阶段 1：门口经过（先测试警觉性） 在门口来回走动 2-3 次，故意让气球很显眼 观察孩子反应，看有没有人主动围过来 如果有孩子凑到门口，就在门口互动 测试目标：看孩子是否会主动靠近陌生人 阶段 2：走进教室（如果门口效果不好） 如果门口没人理你，或孩子不敢出来，就走进教室 假装找老师：“老师在吗？哎呀，老师不在呀” 然后开始与孩子互动：“哇，你们在玩什么呀？” 测试目标：看孩子对进入教室的陌生人是否警觉 剧本流程： ...

Ubuntu 24.04 音频问题修复记录 日期: 2025-11-04 系统: Ubuntu 24.04 硬件: Beelink SER8 音频芯片: Realtek ALC897 问题描述 在系统设置中测试音频时,音箱接入耳机接口(3.5mm)没有声音输出。 排查过程 1. 检查音频设备状态 # 查看可用的音频输出设备 pactl list sinks short 结果: 发现主板音频设备: alsa_output.pci-0000_65_00.6.analog-stereo (Family 17h/19h HD Audio Controller) HDMI音频设备也存在 2. 检查混音器配置 # 查看声卡列表 cat /proc/asound/cards # 检查混音器设置 amixer -c 1 scontents 发现: 音频设备被正确识别 Master, Headphone, Line Out 通道配置正常 Speaker 通道初始被关闭(音量0%, 状态off) 3. 检查系统日志 journalctl -b | grep -i 'audio\|sound\|alsa' | tail -50 发现: ALSA控制器初始化时有多个 “failed to obtain info for control” 警告 PipeWire和PulseAudio服务正常启动 硬件被正确识别: Realtek ALC897 4. 分析硬件Pin配置 cat /proc/asound/card1/codec#0 | grep -A 10 "Node 0x1b\|Node 0x14\|Node 0x15" 关键发现: ...

tcp_syn_retries http://www.chengweiyang.cn/2017/02/18/linux-connect-timeout/ tcp_syn_retries tcp_synack_retries # ubuntu 24.04 ➜ ~ sysctl net.ipv4.tcp_syn_retries net.ipv4.tcp_syn_retries = 6 ➜ ~ sysctl net.ipv4.tcp_synack_retries net.ipv4.tcp_synack_retries = 5 ➜ ~ # 对于主动连接（客户端主动发起连接），每次SYN重试的间隔会逐步递增（不是固定值），由内核写死，不能通过 sysctl 直接调整。 t0 第一次请求 超时时间 1s t1 第一次重试 超时时间 2s t2 第二次重试 超时时间 4s t3 第三次重试 超时时间 8s t4 第四次重试 超时时间 16s t5 第五次重试 超时时间 32s t6 第六次重试 超时时间 64s 总计 1+2+4+8+16+32+64 = 127s http://www.cnitblog.com/Scripts/archive/2009/05/20/57350.html tcp_syn_retries等参数详解(转帖) tcp_syn_retries : INTEGER 默认值是5 对于一个新建连接,内核要发送多少个 SYN 连接请求才决定放弃。不应该大于255,默认值是5,对应于180秒左右时间。(对于大负载而物理通信良好的网络而言,这个值偏高,可修改为2.这个值仅仅是针对对外的连接,对进来的连接,是由tcp_retries1 决定的) tcp_synack_retries : INTEGER ...

BNF 巴科斯范式 BNF & Augmented BNF 巴科斯范式 巴科斯范式(BNF: Backus-Naur Form 的缩写) 是由 John Backus 和 Peter Naur 首次引入一种形式化符号来描述给定语言的语法 (最早用于描述ALGOL 60 编程语言) 。 确切地说，早在UNESCO (联合国教科文组织) 关于ALGOL 58的会议上提出的一篇报告中，Backus就引入了大部分BNF符号。 虽然没有什么人读过这篇报告，但是在Peter Naur读这篇报告时，他发现Backus对ALGOL 58的解释方式和他的解释方式有一些不同之处，这使他感到很惊奇。 首次设计ALGOL的所有参与者都开始发现了他的解释方式的一些弱点，所以他决定对于以后版本的ALGOL应该以一种类似的形式进行描述，以让所有参与者明白他们在对什么达成一致意见。 他做了少量修改，使其几乎可以通用，在设计ALGOL 60的会议上他为ALGOL 60草拟了自己的BNF。 看你如何看待是谁发明了BNF了，或者认为是Backus在1959年发明的，或者认为是Naur在1960年中发明。 (关于那个时期编程语言历史的更多细节，参见1978年8月，《Communications of the ACM (美国计算机学会通讯) 》， 第21卷，第8期中介绍Backus获图灵奖的文章。这个注释是由来自Los Alamos Natl.实验室的William B. Clodius建议的) 。 现在，几乎每一位新编程语言书籍的作者都使用巴科斯范式来定义编程语言的语法规则。 巴科斯范式的内容 在双引号中的字(“word”)代表着这些字符本身。而double_quote用来代表双引号。 在双引号外的字 (有可能有下划线) 代表着语法部分。 尖括号 <> 内包含的为必选项。 方括号 [] 内包含的为可选项。 大括号 {} 内包含的为可重复 0 至无数次的项。 竖线 | 表示在其左右两边任选一项，相当于"OR"的意思。 ::= 是"被定义为"的意思。 巴科斯范式示例 这是用BNF来定义的Java语言中的For语句的实例: FOR_STATEMENT ::= ...

calibre, 电子书管理 calibre-web k8s calibre-dp.yaml apiVersion: apps/v1 kind: Deployment metadata: name: calibre-web namespace: default spec: replicas: 1 selector: matchLabels: name: calibre-web template: metadata: labels: name: calibre-web spec: containers: - name: calibre-web-container image: lscr.io/linuxserver/calibre-web:0.6.25 imagePullPolicy: IfNotPresent env: - name: PUID value: "1000" - name: PGID value: "1000" - name: TZ value: "Asia/Shanghai" - name: DOCKER_MODS value: "linuxserver/calibre-web:calibre" - name: OAUTHLIB_RELAX_TOKEN_SCOPE value: "1" ports: - containerPort: 8083 volumeMounts: - name: calibre-data mountPath: /config subPath: calibre-data volumes: - name: calibre-data persistentVolumeClaim: claimName: pvc0 --- apiVersion: v1 kind: Service metadata: name: calibre-web-service namespace: default spec: type: NodePort ports: - name: http port: 18083 targetPort: 8083 nodePort: 31083 selector: name: calibre-web web podman run -d \ --name=calibre-web \ -e PUID=1000 \ -e PGID=1000 \ -e TZ=Asia/Shanghai \ -e DOCKER_MODS=linuxserver/calibre-web:calibre \ -e OAUTHLIB_RELAX_TOKEN_SCOPE=1 \ -p 8083:8083 \ -v calibre-data:/config \ -v calibre-library:/books \ --restart unless-stopped \ lscr.io/linuxserver/calibre-web:latest GUI podman run -d \ --name=calibre \ -e PUID=1000 \ -e PGID=1000 \ -e TZ=Asia/Shanghai \ -p 8080:8080 \ -p 8081:8081 \ -v calibre-data-tmp:/config \ --restart unless-stopped \ lscr.io/linuxserver/calibre:latest mail server setup https://github.com/janeczku/calibre-web/wiki/Setup-Mailserver

DataGrip console 中使用变量 select * from public.actor where actor.actor_id < ${a} 导出建表语句 打开DataGrip、找到目标表 选中之后右键点击SQL Scripts→SQL Generator. 就可以看到建表语句了

android 自动充电 Chanify 消息推送工具 https://github.com/chanify/chanify-ios/blob/main/README-zh_CN.md # sample podman run -it \ -v /my/data:/root/.chanify \ wizjin/chanify:latest \ serve --name=<node name> --endpoint=http://<address>:<port> # podman podman run -it \ -d --name chanify \ -p 30080:80 \ -v chanify-data:/root/.chanify \ wizjin/chanify:latest \ serve --name=chanify0 --endpoint=https://chanify.wiloon.com # docker docker run -it -d \ --name chanify \ --restart=always \ -p 30080:80 \ -v chanify-data:/root/.chanify \ wizjin/chanify:latest \ serve --name=chanify0 --endpoint=https://chanify.wiloon.com 启动服务配置好 nginx 之后, 在浏览器访问 https://chanify.wiloon.com, 能看到 endpoint 的二维码, 用 iOS chanify 客户端扫二维码添加节点. 切换到频道, 在频道上左滑查看 token 用自建的服务器发消息 curl --form-string "text=hello" "http://chanify.wiloon.com/v1/sender/<token>" curl "http://chanify.wiloon.com/v1/sender/<token>/msg0" 礼信通4芯数据传输 USB 定时开关遥控制器延长线智能 WIFI 电源数据 https://item.taobao.com/item.htm?spm=a1z09.2.0.0.3b462e8dwgAuy1&id=675291964059&_u=m2lc6g03a41 ...

“微服务注册中心” 微服务注册中心, ZooKeeper, Eureka, Consul, Nacos 服务注册中心本质上是为了解耦服务提供者和服务消费者。对于任何一个微服务，原则上都应存在或者支持多个提供者，这是由微服务的分布式属性决定的。更进一步，为了支持弹性扩缩容特性，一个微服务的提供者的数量和分布往往是动态变化的，也是无法预先确定的。因此，原本在单体应用阶段常用的静态LB机制就不再适用了，需要引入额外的组件来管理微服务提供者的注册与发现，而这个组件就是服务注册中心。 CAP理论 CAP理论是分布式架构中重要理论 一致性(Consistency) (所有节点在同一时间具有相同的数据) 可用性(Availability) (保证每个请求不管成功或者失败都有响应) 分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作) P的理解，我觉得是在整个系统中某个部分，挂掉了，或者宕机了，并不影响整个系统的运作或者说使用， 而可用性是，某个系统的某个节点挂了，但是并不影响系统的接受或者发出请求，CAP 不可能都取，只能取其中2个 原因是 如果C是第一需求的话，那么会影响A的性能，因为要数据同步，不然请求结果会有差异，但是数据同步会消耗时间，期间可用性就会降低。 如果A是第一需求，那么只要有一个服务在，就能正常接受请求，但是对与返回结果变不能保证，原因是，在分布式部署的时候，数据一致的过程不可能想切线路那么快。 再如果，同事满足一致性和可用性，那么分区容错就很难保证了，也就是单点，也是分布式的基本核心，好了，明白这些理论，就可以在相应的场景选取服务注册与发现了 Zookeeper -> CP 与 Eureka 有所不同，Apache Zookeeper 在设计时就紧遵CP原则，即任何时候对 Zookeeper 的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性，但是 Zookeeper 不能保证每次服务请求都是可达的。 从 Zookeeper 的实际应用情况来看，在使用 Zookeeper 获取服务列表时，如果此时的 Zookeeper 集群中的 Leader 宕机了，该集群就要进行 Leader 的选举，又或者 Zookeeper 集群中半数以上服务器节点不可用 (例如有三个节点，如果节点一检测到节点三挂了 ，节点二也检测到节点三挂了，那这个节点才算是真的挂了) ，那么将无法处理该请求。所以说，Zookeeper 不能保证服务可用性。 当然，在大多数分布式环境中，尤其是涉及到数据存储的场景，数据一致性应该是首先被保证的，这也是 Zookeeper 设计紧遵CP原则的另一个原因。 但是对于服务发现来说，情况就不太一样了，针对同一个服务，即使注册中心的不同节点保存的服务提供者信息不尽相同，也并不会造成灾难性的后果。 因为对于服务消费者来说，能消费才是最重要的，消费者虽然拿到可能不正确的服务实例信息后尝试消费一下，也要胜过因为无法获取实例信息而不去消费，导致系统异常要好 (淘宝的双十一，京东的618就是紧遵AP的最好参照) 。 当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30~120s，而且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。 在云部署环境下， 因为网络问题使得zk集群失去master节点是大概率事件，虽然服务能最终恢复，但是漫长的选举事件导致注册长期不可用是不能容忍的。 zookeeper 的 CP 模型不适合注册中心 zookeeper 是一个非常优秀的项目，非常成熟，被大量的团队使用，但对于服务发现来讲，zookeeper 真的是一个错误的方案。 在 CAP 模型中，zookeeper 是 CP，意味着面对网络分区时，为了保持一致性，他是不可用的。 ...

Chubby 分布式锁管理系统,也可理解为一个小型强一致性文件系统 http://www.cnblogs.com/linhaohong/archive/2012/11/26/2789394.html 随着云计算的推广,云平台的设计和实现越来越复杂,很多系统属性如一致性和可靠性往往是在系统迭代开发时才被考虑到。如果在原生的系统上重复的实现复杂的一致性算法,这样不仅会破坏原有设计的结构,而且还带来很多开发上的负担。因此很多系统开发人员和架构师努力地进行系统划分,将系统分割成很多组件,分层设计,模块调用,从而最大限度地提高软件复用能力,降低系统设计和开发的难度。 Google在系统的可靠性方面提出了中心化的组件Chubby—粗粒度锁服务,通过锁原语为其他系统实现更高级的服务,比如组成员、域名服务和leader选举等等。Chubby本身也是一个小型的cell (通常由5个chubby结点组成) ,cell内部采用类似于状态机副本形式实现可靠容错。Google的Chubby论文在OSDI上发表后引起了很大的反响,原因很多,主要有两个: 第一,chubby很好的解决了分布式开发的一致性问题； 第二,Google Chubby采用Leslie Lamport提出的paxos算法来实现可靠容错,这是业界关于paxos第一个完整可行的实现。正因为Google Chubby,paxos这个一直沉淀在学术研究的协议,终于曝光在工业界中,之后很快地推广开去。 然而, Google Chubby 并不是开源的, 我们只能通过其论文和其他相关的文档中了解具体的细节。值得庆幸的是,Yahoo！借鉴 Chubby 的设计思想开发了 Zookeeper, 并将其开源。 和 Chubby 相比, Zookeeper 做了很多突破。不像 Chubby 的单点服务的结构, zookeeper 采用多个 server 同时处理客户端的请求, 异步读同步写, 通过 primary 节点来同步数据的 update, 这一点大大改善了读服务的性能, 当然弱化了客户端与服务器之间的一致性。另外, zookeeper 采用 block free 的服务接口, 采用 watch 机制的方式异步处理请求结果和指定数据的变更。Zookeeper 对外提供了更加低级的原语 primitive, 基于此可以实现更多更加复杂的分布式算法, 如 queue、barrier 和 lock 等等。 如今很多云计算系统或者平台都使用 Zookeeper 来做可靠容错, 进行订阅分发服务, 或者其他应用。 和Chubby一样,zookeeper采用paxos的变种来实现消息传输的一致性。Zookeeper开发了原子多播协议 Zab 来实现数据的一致性传输。Zookeeper采用的是primary-backup的结构,primary节点产生non- commutative 事务,通过协议按序的广播到其他backup节点上。在节点无错的情况下,这是非常简单的事情,然而,面对复杂的网络环境,多变的软硬件条件,节点挂掉,重启,数据重复发送,这些异常很常见。Zookeeper如何做到即便是系统出现异常,也能够保证整个系统状态是一致？paxos的变种,Zookeeper的Zab协议很好的保证了这一点。 Zab 协议以epoch的方式执行 (相当与序列号) ,在每个epoch最多只有一个进程多播数据。如果某个进程执行了协议的的第一阶段,那么进程将不再接受之前还没确定提交的epoch的数据。这样一来就保证了在进程在recovery阶段不会出现丢失已提交的数据的情况。在某个epoch下,所有参加这个epoch的进程必须此epoch之前所有已经提交的数据镜像。为了保证一致性,进程在完全恢复之前必须不能广播新的事务。Zab协议的这几个特点处理了primary异常、新旧primary以及backup节点异常的情况,的确保证了primary进程原子多播的order特性。 整个Zab协议的内容分成三个阶段: Discovery、Synchronization和Broadcast阶段。 ...

“VarHandle” VarHandle 的出现替代了java.util.concurrent.atomic和sun.misc.Unsafe的部分操作。并且提供了一系列标准的内存屏障操作，用于更加细粒度的控制内存排序。在安全性、可用性、性能上都要优于现有的API。VarHandle 可以与任何字段、数组元素或静态变量关联，支持在不同访问模型下对这些类型变量的访问，包括简单的 read/write 访问，volatile 类型的 read/write 访问，和 CAS(compare-and-swap)等。 Unsafe 是不建议开发者直接使用的，因为 Unsafe 所操作的并不属于Java标准，会容易带来一些安全性的问题。JDK9 之后，官方推荐使用 java.lang.invoke.Varhandle 来替代 Unsafe 大部分功能，对比 Unsafe ，Varhandle 有着相似的功能，但会更加安全，并且，在并发方面也提高了不少性能。 Varhandle是对变量或参数定义的变量系列的动态强类型引用，包括静态字段，非静态字段，数组元素或堆外数据结构的组件。 在各种访问模式下都支持访问这些变量，包括简单的读/写访问，volatile 的读/写访问以及 CAS (compare-and-set)访问。简单来说 Variable 就是对这些变量进行绑定，通过 Varhandle 直接对这些变量进行操作。 import java.lang.invoke.MethodHandles; import java.lang.invoke.VarHandle; import java.util.Arrays; public class VarHandleX { public int publicVar = 1; protected int protectedVar = 2; @SuppressWarnings("FieldMayBeFinal") private int privateVar = 3; public int[] arrayData = new int[]{1, 2, 3}; @Override public String toString() { return "VarHandleX{" + "publicVar=" + publicVar + ", protectedVar=" + protectedVar + ", privateVar=" + privateVar + ", arrayData=" + Arrays.toString(arrayData) + '}'; } public static void main(String[] args) { try { VarHandleX instance = new VarHandleX(); VarHandle varHandle = MethodHandles.privateLookupIn(VarHandleX.class, MethodHandles.lookup()) .findVarHandle(VarHandleX.class, "privateVar", int.class); varHandle.set(instance, 33); System.out.println(instance); protectedDemo(); protectedDemo2(); publicDemo(); arrayDemo(); } catch (NoSuchFieldException | IllegalAccessException e) { e.printStackTrace(); } } private static void protectedDemo() throws NoSuchFieldException, IllegalAccessException { VarHandleX instance = new VarHandleX(); VarHandle varHandle = MethodHandles.privateLookupIn(VarHandleX.class, MethodHandles.lookup()) .findVarHandle(VarHandleX.class, "protectedVar", int.class); varHandle.set(instance, 22); System.out.println("protected: " + instance); } private static void protectedDemo2() throws NoSuchFieldException, IllegalAccessException { VarHandleX instance = new VarHandleX(); VarHandle varHandle = MethodHandles.lookup() .in(VarHandleX.class) .findVarHandle(VarHandleX.class, "protectedVar", int.class); varHandle.set(instance, 22); System.out.println("protected 2: " + instance); } private static void publicDemo() throws NoSuchFieldException, IllegalAccessException { VarHandleX instance = new VarHandleX(); VarHandle varHandle = MethodHandles.lookup() .in(VarHandleX.class) .findVarHandle(VarHandleX.class, "publicVar", int.class); varHandle.set(instance, 11); System.out.println("public: " + instance); } private static void arrayDemo() throws NoSuchFieldException, IllegalAccessException { VarHandleX instance = new VarHandleX(); VarHandle arrayVarHandle = MethodHandles.arrayElementVarHandle(int[].class); arrayVarHandle.compareAndSet(instance.arrayData, 0, 1, 11); arrayVarHandle.compareAndSet(instance.arrayData, 1, 2, 22); arrayVarHandle.compareAndSet(instance.arrayData, 2, 3, 33); System.out.println("array: " + instance); } } 获取Varhandle方式汇总 MethodHandles.privateLookupIn(class, MethodHandles.lookup())获取访问私有变量的Lookup MethodHandles.lookup() 获取访问protected、public的Lookup findVarHandle: 用于创建对象中非静态字段的VarHandle。接收参数有三个，第一个为接收者的class对象，第二个是字段名称，第三个是字段类型。 findStaticVarHandle: 用于创建对象中静态字段的VarHandle，接收参数与findVarHandle一致。 unreflectVarHandle: 通过反射字段Field创建VarHandle。 MethodHandles.arrayElementVarHandle(int[].class) 获取管理数组的 Varhandle 功能 VarHandle来使用plain、opaque、release/acquire和volatile四种共享内存的访问模式，根据这四种共享内存的访问模式又分为写入访问模式、读取访问模式、原子更新访问模式、数值更新访问模式、按位原子更新访问模式。 ...

“Spring Cloud” Eureka [jʊ’ri:kə] Ribbon [ˈrɪbən] Feign [fen] Hystrix [hɪst’rɪks] Zuul [zulu] Sleuth [sluθ] Turbine [ˈtɜ:rbaɪn] Spring Cloud Netflix (Eureka、Hystrix、Zuul、Archaius) 、Spring Cloud Config、Spring Cloud Bus、Spring Cloud Cluster、Spring Cloud Consul、Spring Cloud Security、Spring Cloud Sleuth、Spring Cloud Data Flow、Spring Cloud Stream、Spring Cloud Task、Spring Cloud Zookeeper、Spring Cloud Connectors、Spring Cloud Starters、Spring Cloud CLI Eureka: 服务注册中心，一个基于REST的服务，用于定位服务，以实现微服务架构中服务发现和故障转移。 Hystrix: 熔断器，容错管理工具，旨在通过熔断机制控制服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力。 l Turbine: Turbine是聚合服务器发送事件流数据的一个工具，用来监控集群下Hystrix的Metrics情况。 l Zuul: API网关，Zuul是在微服务中提供动态路由、监控、弹性、安全等边缘服务的框架。 l Ribbon: 提供微服务中的负载均衡功能，有多种负载均衡策略可供选择，可配合服务发现和断路器使用。 l Feign: Feign是一种声明式、模板化的HTTP客户端。 l Spring Cloud Config: 配置管理工具包，让你可以把配置放到远程服务器，集中化管理集群配置，目前支持本地存储、Git以及Subversion。 l Spring Cloud Security: 基于Spring Security的安全工具包，为微服务的应用程序添加安全控制。 ...