惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

GbyAI
GbyAI
人人都是产品经理
人人都是产品经理
Hugging Face - Blog
Hugging Face - Blog
罗磊的独立博客
博客园 - 【当耐特】
D
Docker
Y
Y Combinator Blog
L
LangChain Blog
博客园 - 三生石上(FineUI控件)
I
InfoQ
阮一峰的网络日志
阮一峰的网络日志
F
Fortinet All Blogs
J
Java Code Geeks
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
V
V2EX
B
Blog
The GitHub Blog
The GitHub Blog
腾讯CDC
MongoDB | Blog
MongoDB | Blog
博客园 - Franky
爱范儿
爱范儿
A
About on SuperTechFans
量子位
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC

酷 壳 – CoolShell

感染新冠的经历 | 酷 壳 - CoolShell 从一次经历谈 TIME_WAIT 的那些事 | 酷 壳 - CoolShell 网络数字身份认证术 | 酷 壳 - CoolShell 我做系统架构的一些原则 | 酷 壳 - CoolShell 源代码特洛伊木马攻击 | 酷 壳 - CoolShell Go编程模式 : 泛型编程 | 酷 壳 - CoolShell 如何做一个有质量的技术分享 | 酷 壳 - CoolShell Go 编程模式:k8s Visitor 模式 | 酷 壳 - CoolShell Go编程模式:Pipeline | 酷 壳 - CoolShell Go编程模式:委托和反转控制 | 酷 壳 - CoolShell Go 编程模式:Go Generation | 酷 壳 - CoolShell Go编程模式:Map-Reduce | 酷 壳 - CoolShell Go 编程模式:错误处理 | 酷 壳 - CoolShell Go编程模式:切片,接口,时间和性能 | 酷 壳 - CoolShell 百度为什么掉队了 | 酷 壳 - CoolShell 程序员如何把控自己的职业 | 酷 壳 - CoolShell 计时攻击 Timing Attacks | 酷 壳 - CoolShell Rust语言的编程范式 | 酷 壳 - CoolShell HTTP的前世今生 | 酷 壳 - CoolShell 记一次Kubernetes/Docker网络排障 | 酷 壳 - CoolShell 可视化编程 | 酷 壳 - CoolShell 程序的本质复杂性和元语言抽象 | 酷 壳 - CoolShell 伙伴分配器的一个极简实现 | 酷 壳 - CoolShell C++11的Lambda使用一例:华容道求解 | 酷 壳 - CoolShell C++面试中string类的一种正确写法 | 酷 壳 - CoolShell C++模板”>>”编译问题与词法消歧设计 | 酷 壳 - CoolShell 数据即代码:元驱动编程 | 酷 壳 - CoolShell 数据的游戏:冰与火 | 酷 壳 - CoolShell 7个示例科普CPU Cache | 酷 壳 - CoolShell 加班与效率 | 酷 壳 - CoolShell
纯文本配置还是注册表 | 酷 壳 - CoolShell
陈皓 · 2011-03-28 · via 酷 壳 – CoolShell

我们知道Unix/Linux下的程序配置文件从来都是纯文本的,你可以自由地修改和查看,他们也没有什么什么XML之类的玩意(参看XML的这两篇文章:),这个最重要的Unix文化(参看Unix传奇下篇)40多年来就这么沿续下来了。我很佩服Microsoft的创新能力,一会儿用INI,一会儿用注册表,一会又是用XML,这就是Windows的编程中那“强大”的创新。在网上又看到有人在争论为什么用注册表而不是纯文本,所以,写下这篇文章。

引入注册表所谓的原因

首先,让我们来看一下为什么微软觉得要使用注册表而不是ini文件,下面是一些其列出来的ini方面的毛病:

  • ini文件不支持Unicode
  • ini文件的安全权限不够
  • ini文件在多进程下存取会有问题
  • 如果一个进程锁上了这个文件,另一个进程就无法获得,只能出错。
  • ini文件只能包含字符串,无法使用二进制
  • 解析ini文件相对来说性能比较慢,第一次读写都需要把整个文件读入内存,然后再写回去。
  • ini文件最大只有32K
  • ini文件的默认目录在Windows系统目录下,只能这个目录只能Windows管理员才能访问
  • ini只能包含了两层,对于多层不支持。
  • 把ini文件放在中央服务器上管理很困难。

而微软说,注册表可以完美地解决这些问题。居然微软只说到了ini文件,但我觉得不单单是ini,所有的以纯文本方式保存配置文件的方法都会出现上述这样的问题。

我的观点

那么,当你在看到这些言论时,你是怎么想的?你有没有经过自己的独立思考?还是你觉得注册表完美地解决了所有的一切?下面是我的一些观点:

  • 首先,我们要知道没有任何一件事是完美的,凡事必然有好的一面,也有不好的一面。
  • 其次,当我们在改进一个东西时,不单单要解决其不好的东西,还要把其好的东西给传承下来。

所以,当你看到一些只说好或是只说坏的东西时,这往往意味着“宗教”或“洗脑”,这正是需要你独立思考的时候。

纯文本配置文件的好处

下面,是我觉得纯文本配置文件的好处(我用Unix下的纯文本配置文件来举例):

  • 很容易进行版本管理(配置文件和程序代码一样都需要版本控制)
  • 很容易移植到别的平台
  • 很容易自定义文本文件的格式和语法,已也有相关的库支持(ini只支持ANSI字符,只有32K,只支持两级,那是ini的问题,解决这些问题不需要引入注册表)
  • 可以在配置文本中写注释信息
  • 你要很容易的使用grep,awk,sed等等以及来和脚本集成。
  • 你可以很容易地拆分配置文件把其放到conf.d中,这样一来,你就非常灵活
    • 你就不用整个文件都读入内存,
    • 你也可以分别设置上不同的存取权限,
    • 同样可以减小多个进程同时存取的问题
    • 同样可以引用别的二进制配置的文件
  • 你可以很容易地产生备份或是在不同的配置中来回地切换配置文件以进行调试。
  • 你可以很容易地使用rsync来向中央服务器同步你的配置文件。或者使用NFS/NIS直接就把配置放在中央服务器上。

真正的原因

可见,Windows 的注册表并没有把纯文本配置文件的这些好处都带过来,所以,经过这样的独立思考,我们可以知道,微软引入注册表的真正原因是——

  • 让你的程序不具移植性,让你的软件永远运行在Windows上。
  • 增加你编程的复杂度和你维护配置文件的复杂度,让你在痛苦之后,苦苦哀求微软再发布下一个“创新”。

各位程序员——Windows是很危险的,你们还是回火星去吧。

全文完,转载时请注明作者和出处

Loading...