精选文章
从 Cloudflare 11.18 全局崩溃事件深度剖析:分布式系统中的容错哲学与配置管理实践
Vibe Coding 实战指南:与 AI 共创、保持流畅、持续成长
sandbox-exec Policy 编写指南:基本结构与规则
适用场景:sandbox-exec -f xxx.sb
一、Policy 基本结构
SBPL 基于 Scheme 语法(Lisp 变体),采用 S-Expression(S 表达式)。
1. 最小结构
一个最基础的策略文件通常包含版本声明和默认行为:
(version 1)
(allow default) ; 默认允许所有操作
(deny file-read* (subpath "/Users/lihu/.ssh")) ; 显式拒绝读取 .ssh 目录2. 语法组成
单条规则的基本格式如下:
OpenClaw 本地沙盒化运行(macOS)实施笔记
本文记录如何在 不创建新用户 的前提下,用
sandbox-exec(Seatbelt)对 OpenClaw(AI Agent)进行本地沙盒化运行。
一、背景与目标
运行 OpenClaw(AI Agent)存在潜在安全风险:
- 可能被 Prompt 注入执行危险命令
- 可能访问 SSH Key、Keychain 等私密数据
- 可能误删/篡改系统文件
- 可能污染 Homebrew 工具链
目标是在 不创建新用户 的前提下,把 OpenClaw 运行在一个 受限沙盒环境 中,实现:
macOS Tahoe 26.x SSH 安全加固笔记
最近 Claude Bot 比较火,搞了个 Mac mini 来玩玩。下面是把 Mac mini 当作服务器的一些安全设置,主要是 SSH 方面的配置。
适用版本:macOS Tahoe / Sonoma / Ventura 及以后
架构特点:launchd Socket Activation(不再由 sshd 直接监听端口)
加固目标:
- 仅允许 SSH 公钥登录
- 禁用密码/交互认证
- 使用自定义端口,关闭默认 22
- 最小化网络暴露面
- 可验证、可回滚
一、背景说明(重要)
从 Ventura 开始,macOS 的 SSH 端口由 launchd 监听:
WOL网络唤醒设置
BIOS/UEFI 层级配置
这是所有设置的前提。如果硬件层关闭,系统层做再多努力也无效。
- 进入 BIOS:通常是开机连续按
Del或F2。 - 电源管理设置 (Power Management):
- Wake On LAN 或 Resume By PCI-E Device:设为 Enabled。
- ErP Ready:设为 Disabled(这是关键!ErP 开启会将待机功耗降至 0.5W 以下,直接切断网卡电源)。
- Deep Sleep:设为 Disabled。
操作系统设置
、 Windows 操作系统配置
Windows 默认倾向于在关机时“彻底休眠”,这有时会干扰网卡状态。
Wake-on-LAN (WOL) 技术深度解析:从协议到驱动的完整实现
一、 核心原理:协议栈与硬件实现
WOL 是一种基于 OSI 模型第二层(数据链路层) 的硬件唤醒技术,由 AMD 和 HP 于 1997 年提出,并在 IEEE 802.3 标准中得到规范。
1. Magic Packet 数据结构
WOL 的核心载荷是一个 102 字节的特殊以太网帧,其结构定义如下:
+----------------+------------------+
| 6 bytes 0xFF | Synchronization |
+----------------+------------------+
| 96 bytes | Target MAC × 16 |
+----------------+------------------+- 同步流 (Sync Stream):6 个字节的
0xFF(FF:FF:FF:FF:FF:FF),作为魔术包识别标记。 - 目标载荷:目标 NIC 的 MAC 地址连续重复 16 次(16 × 6 = 96 字节)。
- 封装协议:
- 标准实现使用 UDP/7(Echo Protocol)或 UDP/9(Discard Protocol)
- 也可以使用 EtherType 0x0842 直接封装在以太网帧中
- 关键点:NIC 的物理层(PHY)芯片通过硬件模式匹配 MAC 序列,不依赖 IP 层解析
2. NIC 的待机监听机制
即使系统处于 ACPI S5 状态(Soft Off),主板的 ATX 电源仍会通过 +5V Standby(紫色线) 为 NIC 提供约 2-3W 的待机功耗。此时 NIC 进入 PCI Power State D3hot/D3cold,仅保留以下组件活跃:
Xcode 注释标签(Annotation Tags)与最佳实践指南
本指南适用于 Swift / SwiftUI / macOS/iOS 应用开发,帮助你在工程中正确、优雅、专业地使用 Xcode 支持的注释标签,提高代码可读性、可维护性和团队协作效率。
1. Xcode 支持的注解标签一览表
以下标签是 Xcode 原生支持 的,它们在导航栏、Issue Navigator 中具有特殊行为。
| 注解标签 | Xcode 行为 | 用途 | 官方支持 |
|---|---|---|---|
// MARK: |
在导航栏创建分组 Section | 组织代码结构 | ✔ 是 |
// MARK: - |
分组 + 分隔线 | 更强的视觉分割 | ✔ 是 |
// TODO: |
出现在 Issue Navigator → Todos | 待办事项 | ✔ 是 |
// FIXME: |
出现在 Issue Navigator → Todos | 待修复的问题 | ✔ 是 |
// WARNING: |
构建时出现黄色警告 ⚠️ | 强调重要问题 | ✔ 是 |
// ERROR: |
构建时报红色错误 ❌ | 阻止构建(调试用) | ✔ 是 |
// NOTE: |
普通注释,无特殊行为 | 补充说明 | ✔ 是 |
/// |
文档注释(Quick Help 支持) | 类型/方法/属性文档 | ✔ 是 |
/** ... */ |
多行文档注释 | 长段落说明 | ✔ 是 |
2. 注解标签详解
2.1 // MARK: —— 代码分区(最常用)
用于将大型 Swift 文件分块,让导航结构更清晰。
从编程哲学到微服务架构:控制与逻辑的分离之道
编程的本质,是对复杂度的驯服。 人类在构建系统时,总会在“秩序”与“自由”之间寻找平衡: 我们希望系统可控,却又希望它具备足够的灵活性。
而“控制与逻辑的分离”,正是这场平衡的核心哲学。
一、从程序语言看“控制”与“逻辑”的两极
在最原始的机器世界里,程序员手动控制一切:寄存器、内存、跳转指令。 那时没有“逻辑”,只有“控制”;系统完全依赖人的思维去维持秩序。
JPA 中的 FilterDef 与伪删除机制:从理念到实战
在企业级应用中,数据删除往往不是"真的删除"。在多数情况下,我们更倾向于**伪删除(Soft Delete)**通过标记字段的方式,将记录逻辑上设为删除状态,而非从数据库物理移除。
本文将从伪删除与真实删除的对比出发,带你深入理解 JPA 中的 @FilterDef
与 @Filter 注解如何优雅地实现伪删除逻辑,同时介绍 Hibernate 6.4+
引入的 @SoftDelete,帮助你构建更安全、可维护的数据层。

