标签：GPT

共 3 篇相关文章

IT 累计浏览 49

从 Sublime Text 到 Zed

作者长期使用 Sublime Text，因其快速启动和丰富插件生态而满意，但随着 AI 辅助编码成为常态，Sublime Text 的 AI 集成体验不足，促使其迁移到 Zed。Zed 由 Atom 和 Tree-sitter 原团队开发，采用 Rust 编写，以极致性能和原生 AI 协作为核心优势，启动速度与文件响应优于 VS Code，并内置 Claude、GPT 等模型支持，无需额外插件。其极简界面与 Sublime Text 相似，降低了迁移成本。安装 Zed CLI 是首要步骤：在 Zed 中通过命令面板执行安装，将 CLI 工具置于 ~/.local/bin/zed，之后可在终端使用如 `zed .` 打开目录或 `zed --diff` 比较文件等命令。为提升效率，作者进一步将 Zed 集成到 macOS Finder 右键菜单，利用 Automator 快速操作机制：首先通过一键脚本生成 OpenInZed.workflow 文件，其中包含 Shell 脚本调用 Zed 打开选中路径；双击安装 workflow 并刷新服务缓存（执行 `/System/Library/CoreServices/pbs -flush`），最后在系统设置中启用该服务。配置后，右键文件夹或文件即可选择“在 Zed 中打开”，脚本自动处理路径。技术细节上，脚本采用三重兜底逻辑以兼容不同安装方式（如 CLI 路径检测、PATH 变量、应用程序直接调用），并添加 `-n`

IT 累计浏览 2,329

GUID分区表的学习

这篇文章梳理了磁盘分区方案的演进脉络，从最传统的MBR方案讲起。作者详细拆解了MBR的结构：它将全部分区信息挤在磁盘首个扇区的64个字节里，每个分区项仅占16字节，从而导致了根本性的限制——最多只能定义4个主分区。为解决此问题，后来引入了扩展分区与逻辑分区，但每个分区项的存储空间并未改变。文章的核心在于对比，它解释了传统MBR方案为何逐渐力不从心。通过剖析其固定的、受限的数据结构，自然引出了后续GUID分区表（GPT）方案所要解决的背景问题：如何突破4个分区的枷锁，并支持远超2TB的大容量硬盘。虽然提供的片段未展开GPT的细节，但文章的主线清晰，即通过理解旧方案的局限，来认识新方案的设计必要性与优势，例如GPT通常支持多达128个主分区并提供了更健壮的数据结构。这对于需要理解现代磁盘管理基础的读者很有帮助，文章从具体技术点出发，清晰地对比了新旧方案的差异，能帮助读者在面对实际配置（如安装系统时选择分区表类型）时做出更合适的判断。

IT 累计浏览 3,722

linux大于2T的磁盘使用GPT分区

这篇讲的是Linux系统处理大容量存储时的一个关键痛点。作者从日常运维中常见的困惑出发——当硬盘容量突破2TB这个临界点后，经典的Fdisk工具为何突然“失灵”？文章直接点明了问题的核心：传统的MBR分区表存在2TB的寻址上限，而Fdisk默认正是使用MBR格式。解决思路清晰明了：必须转向支持更大容量的GPT分区表。文章没有停留在概念，而是详细说明了具体如何操作，例如推荐使用功能更强大的parted工具来创建GPT分区。这对于管理现代大容量存储设备（如多TB的数据盘、RAID阵列）的管理员来说，是一条必经之路。整体而言，这是一篇非常实用的“避坑指南”。它将一个特定技术限制、背后的原理以及标准解决方案串联起来，帮助读者在面对类似场景时，能迅速定位问题并选择正确的工具与方法。