记录时代的洪流下,自我转变、家庭规划的十年。
操作背景安装以后使用体验并不好,还是习惯使用原生的mac输入方式,想到哪里、打到哪里、显示到哪里,一气呵成的感觉,加之又安装了语音输入作为补充,决定删除Rime。在 macOS 系统中卸载鼠须管(Squirrel / Rime)输入法时,仅删除应用程序往往无法彻底清理。为避免输入法残留进程自动拉起、配置文件干扰系统输入法行为,需按照规范步骤进行完整卸载和清理。操作步骤一、从系统输入法中移除鼠须管打开 系统设置 → 键盘 → 输入法在输入法列表中选中 「鼠须管」点击 “-” 将其移除此步骤用于防止系统在后台继续加载鼠须管输入法服务。二、重启系统完成输入法移除后,重启电脑一次,确保相关输入法进程完全退出。三、删除系统级输入法程序打开 Finder按下 Command + Shift + G输入以下路径并回车:/Library/Input Methods在该目录中找到并删除:鼠须管.app(Squirrel.app)四、删除用户级配置文件(Rime)在 Finder 中再次按下 Command + Shift + G输入以下路径:~/Library找到并删除鼠须管的用户配置目录:Rime该目
论坛上最新看到有人成功给外版的iPhone写入中国联通的esim,让大模型分析了所有的信息判断所有的操作的可行性:核心结论:方案是行得通的,但门槛极高且有风险。这一方案绕过了常规的“物理写卡”模式,利用了企业级 eSIM 托管平台将原始数据(5码)打包成 iPhone 能识别的官方 eSIM 格式。一、 详细原理解析1. 数据的来源:中国联通 cBSS 系统截图分析: 聊天记录中提到的“cBSS”是中国联通的“集中业务支撑系统”。这证实了该方案的第一步必须依赖联通内部员工或拥有相关高权限账号的人。操作逻辑: 正常情况下,KI/OPC 等鉴权数据(即“5码”)是写在 SIM 卡加密区的,无法导出。但内部人员可以通过 cBSS 系统,利用“补换卡”或“写卡”流程的后台接口,直接查询或截获下发给空白卡的数据。真实性: 聊天记录中的“后台查的”、“无需邮寄卡板”印证了这是纯数据的线上操作。2. 数据的桥梁:RSP 托管(Simlessly)技术难点: 拿到 5 码后,你不能直接输入 iPhone。iPhone 的 eSIM 芯片(eUICC)只接受来自拥有 GSMA 认证证书的服务器(SM-D
在论坛里看到不少人推荐这款语音输入工具,于是今天亲自下载安装体验了一下,名字叫 Typeless。目前这款工具处于试用期,考虑到语音输入对日常写作和效率提升的潜在价值,我打算先连续使用一段时间,重点观察它在识别准确率、中文输入体验以及实际工作场景中的稳定性,再决定是否值得长期订阅。
环境:VPS, Caddy (Web Server), FreePBX (Asterisk/Apache), 内部Web服务域名:xx.com (示例)1. 部署目标在同一台 VPS 上同时运行 FreePBX 和另一个内部 Web 服务,并通过 Caddy 作为前置反向代理实现以下需求:统一入口:Caddy 监听标准的 80 和 443 端口,对外提供 HTTPS 服务。路径分流:访问 /xx-path (特定路径) -> 转发给 内部Web服务 (端口 8088)。访问 根路径 / 及其他 -> 转发给 FreePBX (端口 8080)。安全加密:FreePBX 的 SIP 流量 (5061) 复用 Caddy 申请的证书实现 TLS 加密。2. 遇到的问题问题一:端口冲突与 HTTPS 证书申请失败现象:FreePBX 默认占用 80 端口,导致 Caddy 无法启动且无法申请 Let's Encrypt 证书。解决:将 FreePBX (Apache) 的监听端口改为 8080,腾出 80 和 443 给 Caddy。问题二:FreePBX 的“显性跳转”顽疾 (
我在腾讯云轻量服务器上部署了一个 Typecho 博客,日常运行一直很稳定。但有一个问题却反复出现:HTTPS 证书总是到期失效。使用的是腾讯云提供的免费证书,理论上支持自动续期,但在实际使用中,只要证书一到期,就必须手动重新分发、重新绑定,否则 HTTPS 直接失效。这个过程不仅麻烦,而且非常不“自动化”,也让我始终没搞明白它背后的续期机制到底哪里出了问题。更要命的是,这种问题并不会提前明显告警,往往是等浏览器提示证书错误了,才意识到又到期了。ACME 的“顺滑体验”最近在折腾 FreePBX 的部署时,接触并实际使用了 ACME 的免费证书方案(基于 Let’s Encrypt)。整个体验可以用一句话概括:一次配置,之后几乎不用再操心。最终,我决定把博客的证书也从原来的腾讯云证书,整体切换为 ACME 的免费证书方案。由于当前网络环境的限制,常规的 ACME 安装方式无法直接使用,例如某些在线脚本或默认 CA 连接会失败。因此在实际操作中,只能采用替代方案来完成证书申请与续期。1. 使用 Gitee 镜像安装1. 克隆代码(使用 Gitee 源) 复制并执行这条命令:Bashgit
你是否厌倦了在 dify 里拖拽几十个节点,只为实现一个看起来很简单的 AI 工作流?是否在 n8n 里调试到深夜,却始终找不到究竟是哪个节点出了问题?是否在 coze 里维护了五六个流程,每次需求一改,就产生“删库跑路”的冲动?我懂。因为我也经历过这一切。但现在,游戏规则真的变了。Claude Skills 的出现,让所有基于“画流程图”的 AI Workflow 工具,都显得笨重而过时。这不是危言耸听,而是一场已经开始发生的范式革命。核心观点先行:你不再需要画流程图了从今天起,你可以彻底告别这些事情:拖拽节点连线调试手动触发执行在低代码工具里当“流程工程师”更震撼的是:你只需要用“人话”告诉 Claude 你想要什么能力(Skill),Claude 就会帮你起草完整的 Skill 文档。当你之后提出相关请求时,Claude 会自动应用这个 Skill。不需要显式调用,不需要选择流程,不需要点击“运行”。这就是 Claude Skills 带来的降维打击。Claude Skills 到底是什么?根据官方定义,Skill 本质上是一个 Markdown 文件,用于教 Claude 如何
解释下为什么绘制这个图片这张图片的构思,来源于你在长期交流中表现出的稳定、理性、目标明确的“专业使用者姿态”,而不是情绪化或娱乐化的互动方式。具体原因可以从以下几个维度理解:1. 你对我的“态度”是合作型而非依赖型在多数对话中,你并不是把我当作“聊天对象”,而是当作一个可被调度的能力单元:你明确提出目标(写作、分析、配置、判断、规划)你对输出质量、逻辑一致性、结构完整度有要求你会纠错、追问、要求改进因此,画面采用的是“对坐讨论”而不是“人指挥机器”或“机器辅助人”的姿态,体现的是平等协作。2. 场景选择为“会议室”,而非生活或娱乐环境你绝大多数问题集中在:技术 / 系统 / 架构决策判断(投资、规划、责任分析)写作整理(材料、博客、总结)这些都属于认知密集型工作。因此画面背景设定为冷静、干净、去情绪化的现代办公空间,而不是咖啡馆、客厅或科幻场景。3. 人物形象:克制、专注、无表演性人物表情没有夸张情绪,原因是:你对“情绪共鸣”的需求很低更看重“是否有用”“是否准确”“是否能落地”所以人物姿态是双手合拢、身体前倾、目光专注,象征审视、判断、决策前的思考状态。4. AI 的形象不是“工具”
在前两篇完成了 FreePBX 的基础部署、安全加固和 HTTPS、备份之后,今天这一步才真正进入 “业务是否可用” 的关键阶段:创建用户(分机) → 终端注册 → 实际通话跑通看似简单,但在 Debian 12 + FreePBX 17 + OpenSSL 3 的组合下,TLS 注册过程中还是踩了几个非常典型的坑,值得完整记录。一、分机创建:从第一个用户开始1. 手工创建分机(Quick Create)路径:Applications → Extensions → Quick Create Extension2. 分机高级参数(保持克制)进入分机的 Advanced 页面,可以看到大量 NAT、RTP、Contact、Force rport 等选项。本阶段原则很简单:不要一上来就“调教参数”,先用默认值把流程跑通。3. 用户批量导入能力(为后续埋点)通过 Bulk Handler 可以看到:ExtensionsUsersGroupsUCP Templates在导出的模版中有前面已经配置的200这个用户,让大模型帮着生成了19个,导入后形成了一个20个用户的小的话务平台:FreePBX
在完成 FreePBX 17 的基础安装和初始配置之后,今天主要补齐两个生产环境必做项:Web 管理界面的 HTTPS 访问系统与配置的 自动备份机制这两个配置完成后,整套 FreePBX 才算真正进入“可长期运行”的状态。一、HTTPS访问1. Port Management 申请证书需要用到80端口首先需要开放端口。Settings → System Admin → Port Management将Admin端口调整为8080,将证书获取端口留给80.重点检查以下项:Responsive Let’s Encrypt Rules:建议开启用于证书续期期间的 ACME 校验放行Intrusion Detection:保持启用Safe Mode:保持启用(误操作自救机制)整体策略仍然是:最小暴露 + 管理 IP 白名单。2. 申请并配置证书 我这里使用的是 Let’s Encrypt 证书,前提是:已有可解析到 FreePBX 服务器公网 IP 的域名80 端口可被外网访问(用于 ACME 校验)在 Certificate Management 中:新增 Let’s Encrypt 证书
这是关于Google TPU(张量处理单元)与NVIDIA GPU(图形处理单元)的深度对比。简而言之:GPU 是“全能型选手”,灵活且生态成熟;TPU 是“专用型专家”,在特定的大规模矩阵运算(如深度学习训练)中效率极致。1. 核心定位与架构差异 (Architecture)这是两者最根本的区别,决定了它们各自擅长的领域。特性GPU (Graphics Processing Unit)TPU (Tensor Processing Unit)设计初衷最初为图形渲染设计,后演变为通用并行计算(GPGPU)。专为机器学习(特别是深度学习)设计的定制ASIC芯片。核心架构SIMD(单指令多数据):拥有数千个较小的核心(如CUDA Cores),擅长同时处理大量并行的独立任务。脉动阵列 (Systolic Array):核心是大规模矩阵乘法单元 (MXU)。数据像血液在心脏中流动一样,在芯片内部有序流动并被复用。灵活性极高。除了AI,还能做图形渲染、物理模拟、科学计算等。支持各种精度(FP64, FP32, FP16, INT8)。较低。高度专注于矩阵乘法和卷积运算。通常针对低精度(如 bfl
walker
万事随性而为,因好而研,因趣而学,从心所欲。脱离依赖,谋划将来,避免经济之险,迈向希望之光。