2013年1月31日星期四

阮一峰的网络日志

阮一峰的网络日志


代码的抽象三原则

Posted: 30 Jan 2013 10:03 PM PST

软件开发是"抽象化"原则(Abstraction)的一种体现。

所谓"抽象化",就是指从具体问题中,提取出具有共性的模式,再使用通用的解决方法加以处理。

开发软件的时候,一方面,我们总是希望使用别人已经写好的代码,另一方面,又希望自己写的代码尽可能重用,以求减少工作量。要做到这两个目标,这需要"抽象化"。

最近,我读到美国程序员Derick Bailey的一篇文章,谈到"抽象化"应该遵循的三个原则,觉得很有启发。

一、DRY原则

DRY是 Don't repeat yourself 的缩写,意思是"不要重复自己"。

软件工程名著《The Pragmatic Programmer》首先提出了这个原则。它的涵义是,系统的每一个功能都应该有唯一的实现。也就是说,如果多次遇到同样的问题,就应该抽象出一个共同的解决方法,不要重复开发同样的功能。

这个原则有时也称为"一次且仅一次"原则(Once and Only Once)。

二、YAGNI原则

YAGNI是 You aren't gonna need it 的缩写,意思是"你不会需要它"。

这是"极限编程"提倡的原则,指的是你自以为有用的功能,实际上都是用不到的。因此,除了最核心的功能,其他功能一概不要部署,这样可以大大加快开发。

它背后的指导思想,就是尽可能快、尽可能简单地让软件运行起来(do the simplest thing that could possibly work)。

但是,这里出现了一个问题。仔细推敲的话,你会发现DRY原则和YAGNI原则并非完全兼容。前者追求"抽象化",要求找到通用的解决方法;后者追求"快和省",意味着不要把精力放在抽象化上面,因为很可能"你不会需要它"。所以,就有了第三个原则。

三、Rule Of Three原则

Rule of three 称为"三次原则",指的是当某个功能第三次出现时,才进行"抽象化"。

这是软件开发大家Martin Fowler在《Refactoring》一书中提出的。

它的涵义是,第一次用到某个功能时,你写一个特定的解决方法;第二次又用到的时候,你拷贝上一次的代码;第三次出现的时候,你才着手"抽象化",写出通用的解决方法。

这样做有几个理由:

(1)省事。如果一种功能只有一到两个地方会用到,就不需要在"抽象化"上面耗费时间了。

(2)容易发现模式。"抽象化"需要找到问题的模式,问题出现的场合越多,就越容易看出模式,从而可以更准确地"抽象化"。

比如,对于一个数列来说,两个元素不足以判断出规律:

  1, 2, _, _, _, _,

第三个元素出现后,规律就变得较清晰了:

  1, 2, 4, _, _, _,

(3)防止过度冗余。如果一种功能同时有多个实现,管理起来非常麻烦,修改的时候需要修改多处。在实际工作中,重复实现最多可以容忍出现一次,再多就无法接受了。

综上所述,"三次原则"是DRY原则和YAGNI原则的折衷,是代码冗余和开发成本的平衡点,值得我们在"抽象化"时遵循。

==========================================================

附:

[广告]

图灵公司打算重新出版《Joel on Software》的中文版,正在寻找译者。如果你对此有兴趣,请与朱巍编辑联系(Email:zhuw(at)turingbook.com)试译。关于此书的更多情况,可参考我翻译的续集《More Joel on Software》。特别提醒:翻译是非常辛苦、但是报酬很低的工作,写信前请想清楚,你是真的想翻译这本书。

(完)

文档信息

2013年1月23日星期三

阮一峰的网络日志

阮一峰的网络日志


JavaScript Source Map 详解

Posted: 22 Jan 2013 10:30 PM PST

上周,jQuery 1.9发布。

这是2.0版之前的最后一个新版本,有很多新功能,其中一个就是支持Source Map。

访问 http://ajax.googleapis.com/ajax/libs/jquery/1.9.0/jquery.min.js,打开压缩后的版本,滚动到底部,你可以看到最后一行是这样的:

  //@ sourceMappingURL=jquery.min.map

这就是Source Map。它是一个独立的map文件,与源码在同一个目录下,你可以点击进去,看看它的样子。

这是一个很有用的功能,本文将详细讲解这个功能。

一、从源码转换讲起

JavaScript脚本正变得越来越复杂。大部分源码(尤其是各种函数库和框架)都要经过转换,才能投入生产环境。

常见的源码转换,主要是以下三种情况:

  (1)压缩,减小体积。比如jQuery 1.9的源码,压缩前是252KB,压缩后是32KB。

  (2)多个文件合并,减少HTTP请求数。

  (3)其他语言编译成JavaScript。最常见的例子就是CoffeeScript。

这三种情况,都使得实际运行的代码不同于开发代码,除错(debug)变得困难重重。

通常,JavaScript的解释器会告诉你,第几行第几列代码出错。但是,这对于转换后的代码毫无用处。举例来说,jQuery 1.9压缩后只有3行,每行3万个字符,所有内部变量都改了名字。你看着报错信息,感到毫无头绪,根本不知道它所对应的原始位置。

这就是Source map想要解决的问题。

二、什么是Source map

简单说,Source map就是一个信息文件,里面储存着位置信息。也就是说,转换后的代码的每一个位置,所对应的转换前的位置。

有了它,出错的时候,除错工具将直接显示原始代码,而不是转换后的代码。这无疑给开发者带来了很大方便。

目前,暂时只有Chrome浏览器支持这个功能。在Developer Tools的Setting设置中,确认选中"Enable source maps"。

三、如何启用Source map

正如前文所提到的,只要在转换后的代码尾部,加上一行就可以了。

  //@ sourceMappingURL=/path/to/file.js.map

map文件可以放在网络上,也可以放在本地文件系统。

四、如何生成Source map

最常用的方法是使用Google的Closure编译器

生成命令的格式如下:

  java -jar compiler.jar \
    --js script.js \
    --create_source_map ./script-min.js.map \
    --source_map_format=V3 \
    --js_output_file script-min.js

各个参数的意义如下:

  - js: 转换前的代码文件
  - create_source_map: 生成的source map文件
  - source_map_format:source map的版本,目前一律采用V3。
  - js_output_file: 转换后的代码文件。

其他的生成方法可以参考这篇文章

五、Source map的格式

打开Source map文件,它大概是这个样子:

  {
    version : 3,
    file: "out.js",
    sourceRoot : "",
    sources: ["foo.js", "bar.js"],
    names: ["src", "maps", "are", "fun"],
    mappings: "AAgBC,SAAQ,CAAEA"
  }

整个文件就是一个JavaScript对象,可以被解释器读取。它主要有以下几个属性:

  - version:Source map的版本,目前为3。

  - file:转换后的文件名。

  - sourceRoot:转换前的文件所在的目录。如果与转换前的文件在同一目录,该项为空。

  - sources:转换前的文件。该项是一个数组,表示可能存在多个文件合并。

  - names:转换前的所有变量名和属性名。

  - mappings:记录位置信息的字符串,下文详细介绍。

六、mappings属性

下面才是真正有趣的部分:两个文件的各个位置是如何一一对应的。

关键就是map文件的mappings属性。这是一个很长的字符串,它分成三层。

  第一层是行对应,以分号(;)表示,每个分号对应转换后源码的一行。所以,第一个分号前的内容,就对应源码的第一行,以此类推。

  第二层是位置对应,以逗号(,)表示,每个逗号对应转换后源码的一个位置。所以,第一个逗号前的内容,就对应该行源码的第一个位置,以此类推。

  第三层是位置转换,以VLQ编码表示,代表该位置对应的转换前的源码位置。

举例来说,假定mappings属性的内容如下:

  mappings:"AAAAA,BBBBB;CCCCC"

就表示,转换后的源码分成两行,第一行有两个位置,第二行有一个位置。

七、位置对应的原理

每个位置使用五位,表示五个字段。

从左边算起,

  - 第一位,表示这个位置在(转换后的代码的)的第几列。

  - 第二位,表示这个位置属于sources属性中的哪一个文件。

  - 第三位,表示这个位置属于转换前代码的第几行。

  - 第四位,表示这个位置属于转换前代码的第几列。

  - 第五位,表示这个位置属于names属性中的哪一个变量。

有几点需要说明。首先,所有的值都是以0作为基数的。其次,第五位不是必需的,如果该位置没有对应names属性中的变量,可以省略第五位。再次,每一位都采用VLQ编码表示;由于VLQ编码是变长的,所以每一位可以由多个字符构成。

如果某个位置是AAAAA,由于A在VLQ编码中表示0,因此这个位置的五个位实际上都是0。它的意思是,该位置在转换后代码的第0列,对应sources属性中第0个文件,属于转换前代码的第0行第0列,对应names属性中的第0个变量。

八、VLQ编码

最后,谈谈如何用VLQ编码表示数值。

这种编码最早用于MIDI文件,后来被多种格式采用。它的特点就是可以非常精简地表示很大的数值。

VLQ编码是变长的。如果(整)数值在-15到+15之间(含两个端点),用一个字符表示;超出这个范围,就需要用多个字符表示。它规定,每个字符使用6个两进制位,正好可以借用Base 64编码的字符表。

在这6个位中,左边的第一位(最高位)表示是否"连续"(continuation)。如果是1,代表这6个位后面的6个位也属于同一个数;如果是0,表示该数值到这6个位结束。

  Continuation
  |     Sign
  |     |
  V     V
  101011

这6个位中的右边最后一位(最低位)的含义,取决于这6个位是否是某个数值的VLQ编码的第一个字符。如果是的,这个位代表"符号"(sign),0为正,1为负(Source map的符号固定为0);如果不是,这个位没有特殊含义,被算作数值的一部分。

九、VLQ编码:实例

下面看一个例子,如何对数值16进行VLQ编码。

  第一步,将16改写成二进制形式10000。

  第二步,在最右边补充符号位。因为16大于0,所以符号位为0,整个数变成100000。

  第三步,从右边的最低位开始,将整个数每隔5位,进行分段,即变成1和00000两段。如果最高位所在的段不足5位,则前面补0,因此两段变成00001和00000。

  第四步,将两段的顺序倒过来,即00000和00001。

  第五步,在每一段的最前面添加一个"连续位",除了最后一段为0,其他都为1,即变成100000和000001。

  第六步,将每一段转成Base 64编码。

查表可知,100000为g,000001为B。因此,数值16的VLQ编码为gB。上面的过程,看上去好像很复杂,做起来其实很简单,具体的实现请看官方的base64-vlq.js文件,里面有详细的注释。

十、参考链接

  - Introduction To JavaScript Source Maps
  - Source Map Revision 3 Proposal

(完)

文档信息

2013年1月14日星期一

阮一峰的网络日志

阮一峰的网络日志


Javascript 严格模式详解

Posted: 13 Jan 2013 09:42 PM PST

一、概述

除了正常运行模式,ECMAscript 5添加了第二种运行模式:"严格模式"(strict mode)。顾名思义,这种模式使得Javascript在更严格的条件下运行。

设立"严格模式"的目的,主要有以下几个:

  - 消除Javascript语法的一些不合理、不严谨之处,减少一些怪异行为;

  - 消除代码运行的一些不安全之处,保证代码运行的安全;

  - 提高编译器效率,增加运行速度;

  - 为未来新版本的Javascript做好铺垫。

"严格模式"体现了Javascript更合理、更安全、更严谨的发展方向,包括IE 10在内的主流浏览器,都已经支持它,许多大项目已经开始全面拥抱它。

另一方面,同样的代码,在"严格模式"中,可能会有不一样的运行结果;一些在"正常模式"下可以运行的语句,在"严格模式"下将不能运行。掌握这些内容,有助于更细致深入地理解Javascript,让你变成一个更好的程序员。

本文将对"严格模式"做详细介绍。

二、进入标志

进入"严格模式"的标志,是下面这行语句:

  "use strict";

老版本的浏览器会把它当作一行普通字符串,加以忽略。

三、如何调用

"严格模式"有两种调用方法,适用于不同的场合。

3.1 针对整个脚本文件

将"use strict"放在脚本文件的第一行,则整个脚本都将以"严格模式"运行。如果这行语句不在第一行,则无效,整个脚本以"正常模式"运行。如果不同模式的代码文件合并成一个文件,这一点需要特别注意。

  <script>
    "use strict";
    console.log("这是严格模式。");
  </script>

  <script>
    console.log("这是正常模式。");
  </script>

上面的代码表示,一个网页中依次有两段Javascript代码。前一个script标签是严格模式,后一个不是。

3.2 针对单个函数

将"use strict"放在函数体的第一行,则整个函数以"严格模式"运行。

  function strict(){
    "use strict";
    return "这是严格模式。";
  }

  function notStrict() {
    return "这是正常模式。";
  }

3.3 脚本文件的变通写法

因为第一种调用方法不利于文件合并,所以更好的做法是,借用第二种方法,将整个脚本文件放在一个立即执行的匿名函数之中。

  (function (){

    "use strict";

    // some code here

   })();

四、语法和行为改变

严格模式对Javascript的语法和行为,都做了一些改变。

4.1 全局变量显式声明

在正常模式中,如果一个变量没有声明就赋值,默认是全局变量。严格模式禁止这种用法,全局变量必须显式声明。

"use strict";

  v = 1; // 报错,v未声明

  for(i = 0; i < 2; i++) { // 报错,i未声明
  }

因此,严格模式下,变量都必须先用var命令声明,然后再使用。

4.2 静态绑定

Javascript语言的一个特点,就是允许"动态绑定",即某些属性和方法到底属于哪一个对象,不是在编译时确定的,而是在运行时(runtime)确定的。

严格模式不允许动态绑定,只允许静态绑定。也就是说,属性和方法到底归属哪个对象,必须在编译阶段就确定。这样做有利于编译效率的提高,也使得代码更容易阅读,更少出现意外。

具体来说,涉及以下几个方面。

(1)禁止使用with语句

因为with语句无法在编译时就确定,属性到底归属哪个对象。

  "use strict";

  var v = 1;

  with (o){ // 语法错误
    v = 2;
  }

(2)创设eval作用域

正常模式下,Javascript语言有两种变量作用域(scope):全局作用域和函数作用域。严格模式创设了第三种作用域:eval作用域。

正常模式下,eval语句的作用域,取决于它处于全局作用域,还是函数作用域。严格模式下,eval语句本身就是一个作用域,不再能够生成全局变量了,它所生成的变量只能用于eval内部。

  "use strict";

  var x = 2;

  console.info(eval("var x = 5; x")); // 5

  console.info(x); // 2

4.3 增强的安全措施

(1)禁止this关键字指向全局对象

  function f(){
    return !this;
  }
  // 返回false,因为"this"指向全局对象,"!this"就是false

  function f(){
    "use strict";
    return !this;
  }
  // 返回true,因为严格模式下,this的值为undefined,所以"!this"为true。

因此,使用构造函数时,如果忘了加new,this不再指向全局对象,而是报错。

  function f(){

    "use strict";

    this.a = 1;

  };

  f();// 报错,this未定义

(2)禁止在函数内部遍历调用栈

  function f1(){

    "use strict";

    f1.caller; // 报错

    f1.arguments; // 报错

  }

  f1();

4.4 禁止删除变量

严格模式下无法删除变量。只有configurable设置为true的对象属性,才能被删除。

  "use strict";

  var x;

  delete x; // 语法错误

  var o = Object.create(null, 'x', {
      value: 1,
      configurable: true
  });

  delete o.x; // 删除成功

4.5 显式报错

正常模式下,对一个对象的只读属性进行赋值,不会报错,只会默默地失败。严格模式下,将报错。

  "use strict";

  var o = {};

  Object.defineProperty(o, "v", { value: 1, writable: false });

  o.v = 2; // 报错

严格模式下,对一个使用getter方法读取的属性进行赋值,会报错。

  "use strict";

  var o = {

    get v() { return 1; }

  };

  o.v = 2; // 报错

严格模式下,对禁止扩展的对象添加新属性,会报错。

  "use strict";

  var o = {};

  Object.preventExtensions(o);

  o.v = 1; // 报错

严格模式下,删除一个不可删除的属性,会报错。

  "use strict";

  delete Object.prototype; // 报错

4.6 重名错误

严格模式新增了一些语法错误。

(1)对象不能有重名的属性

正常模式下,如果对象有多个重名属性,最后赋值的那个属性会覆盖前面的值。严格模式下,这属于语法错误。

  "use strict";

  var o = {
    p: 1,
    p: 2
  }; // 语法错误

(2)函数不能有重名的参数

正常模式下,如果函数有多个重名的参数,可以用arguments[i]读取。严格模式下,这属于语法错误。

  "use strict";

  function f(a, a, b) { // 语法错误

    return ;

  }

4.7 禁止八进制表示法

正常模式下,整数的第一位如果是0,表示这是八进制数,比如0100等于十进制的64。严格模式禁止这种表示法,整数第一位为0,将报错。

  "use strict";

  var n = 0100; // 语法错误

4.8 arguments对象的限制

arguments是函数的参数对象,严格模式对它的使用做了限制。

(1)不允许对arguments赋值

  "use strict";

  arguments++; // 语法错误

  var obj = { set p(arguments) { } }; // 语法错误

  try { } catch (arguments) { } // 语法错误

  function arguments() { } // 语法错误

  var f = new Function("arguments", "'use strict'; return 17;"); // 语法错误

(2)arguments不再追踪参数的变化

  function f(a) {

    a = 2;

    return [a, arguments[0]];

  }

  f(1); // 正常模式为[2,2]

  function f(a) {

    "use strict";

    a = 2;

    return [a, arguments[0]];

  }

  f(1); // 严格模式为[2,1]

(3)禁止使用arguments.callee

这意味着,你无法在匿名函数内部调用自身了。

  "use strict";

  var f = function() { return arguments.callee; };

  f(); // 报错

4.9 函数必须声明在顶层

将来Javascript的新版本会引入"块级作用域"。为了与新版本接轨,严格模式只允许在全局作用域或函数作用域的顶层声明函数。也就是说,不允许在非函数的代码块内声明函数。

  "use strict";

  if (true) {

    function f() { } // 语法错误

  }

  for (var i = 0; i < 5; i++) {

    function f2() { } // 语法错误

  }

4.10 保留字

为了向将来Javascript的新版本过渡,严格模式新增了一些保留字:implements, interface, let, package, private, protected, public, static, yield。

使用这些词作为变量名将会报错。

  function package(protected) { // 语法错误

    "use strict";

    var implements; // 语法错误

  }

此外,ECMAscript第五版本身还规定了另一些保留字:class, enum, export, extends, import, super。它们也是不能使用的。

五、参考链接

- MDN, Strict mode
- Dr. Axel Rauschmayer,JavaScript's strict mode: a summary
- Douglas Crockford, Strict Mode Is Coming To Town

(完)

文档信息

2013年1月9日星期三

阮一峰的网络日志

阮一峰的网络日志


泊松分布与美国枪击案

Posted: 08 Jan 2013 05:49 AM PST

去年12月,美国康涅狄格州发生校园枪击案,造成28人死亡。

资料显示,1982年至2012年,美国共发生62起(大规模)枪击案。其中,2012年发生了7起,是次数最多的一年。

去年有这么多枪击案,这是巧合,还是表明美国治安恶化了?

前几天,我看到一篇很有趣的文章,使用"泊松分布"(Poisson distribution),判断同一年发生7起枪击案是否巧合。

让我们先通过一个例子,了解什么是"泊松分布"。

已知某家小杂货店,平均每周售出2个水果罐头。请问该店水果罐头的最佳库存量是多少?

假定不存在季节因素,可以近似认为,这个问题满足以下三个条件:

(1)顾客购买水果罐头是小概率事件。

(2)购买水果罐头的顾客是独立的,不会互相影响。

(3)顾客购买水果罐头的概率是稳定的。

在统计学上,只要某类事件满足上面三个条件,它就服从"泊松分布"。

泊松分布的公式如下:

P(X=k)=\frac{e^{-\lambda}\lambda^k}{k!}

各个参数的含义:

  P:每周销售k个罐头的概率。

  X:水果罐头的销售变量。

  k:X的取值(0,1,2,3...)。

  λ:每周水果罐头的平均销售量,是一个常数,本题为2。

根据公式,计算得到每周销量的分布:

从上表可见,如果存货4个罐头,95%的概率不会缺货(平均每19周发生一次);如果存货5个罐头,98%的概率不会缺货(平均59周发生一次)。

现在,我们再回过头,来看美国枪击案。

假定它们满足"泊松分布"的三个条件:

  (1)枪击案是小概率事件。

  (2)枪击案是独立的,不会互相影响。

  (3)枪击案的发生概率是稳定的。

显然,第三个条件是关键。如果成立,就说明美国的治安没有恶化;如果不成立,就说明枪击案的发生概率不稳定,正在提高,美国治安恶化。

根据资料,1982--2012年枪击案的分布情况如下:

计算得到,平均每年发生2起枪击案,所以 λ = 2 。

上图中,蓝色的条形柱是实际的观察值,红色的虚线是理论的预期值。可以看到,观察值与期望值还是相当接近的。

我们用"卡方检验"(chi-square test),检验观察值与期望值之间是否存在显著差异。

  卡方统计量 = Σ [ ( 观察值 - 期望值 ) ^ 2 / 期望值 ]

计算得到,卡方统计量等于9.82。查表后得到,置信水平0.90、自由度7的卡方分布临界值为12.017。因此,卡方统计量小于临界值,这表明枪击案的观察值与期望值之间没有显著差异。所以,可以接受"发生枪击案的概率是稳定的"假设,也就是说,从统计学上无法得到美国治安正在恶化的结论。

但是,也必须看到,卡方统计量9.82离临界值很接近,p-value只有0.18。也就是说,对于"美国治安没有恶化"的结论,我们只有82%的把握,还有18%的可能是我们错了,美国治安实际上正在恶化。因此,这就需要看今后两年中,是否还有大量枪击案发生。如果确实发生了,泊松分布就不成立了。

[参考阅读]

  * 泊松分布,by 曹亮吉

  * 卡方分布(PDF文件)

(完)

文档信息

2013年1月3日星期四

阮一峰的网络日志

阮一峰的网络日志


反Secure Boot垄断:兼谈如何在Windows 8电脑上安装Linux

Posted: 02 Jan 2013 06:47 AM PST

一、自由软件基金会的呼吁

上周,2012年将近结束的时候,自由软件基金会(FSF)发出呼吁,要求人们继续支持反Secure Boot垄断,希望签名者能达到5万人(目前是4万)。

我觉得,这个呼吁很重要。如果我们不支持,未来就无法自由地使用硬件、安装自己想要的软件。

这绝非危言耸听。而且,由于这个事件直接与Windows 8操作系统有关,因此意味着一切已经迫在眉睫了。

下面,我根据自己的理解,谈谈这到底怎么回事。如果你是一个Linux爱好者,或者喜欢自己安装操作系统,下面的内容与你直接相关。

二、BIOS和UEFI

所有电脑启动的时候,都会运行BIOS程序,用于初始化硬件。

自从个人电脑诞生后,就一直如此。过去30年我们都在使用类似上图的画面,设置硬件参数。不用说,BIOS已经变得日益不适用了。

1998年,Intel牵头,联合AMD、AMI、Apple、Dell、HP、IBM、Lenovo、Microsoft和Phoenix等业界主要厂商,开始制定新一代BIOS。这个项目叫做"统一的可扩展固定接口"(Unified Extensible Firmware Interface),简称UEFI。2005年推出1.1版,目前是2.3版。

将来一开机,电脑运行的将不是BIOS,而是UEFI BIOS。等它运行结束,再载入操作系统。

三、微软的态度

UEFI是一个很先进的、面向未来的规格。但是很长时间内无法推广,原因就是微软公司不积极。

Windows操作系统是桌面市场的主流系统,如果它不推广UEFI,就没有硬件厂商会跟进。所以,普通消费者对这个新规格所知甚少。

意想不到的变化,出现在2011年9月,微软毫无预兆地突然宣布,Windows 8将启用UEFI。

这本来是一件好事。但是,问题是微软感兴趣的不是整个UEFI,而是UEFI的一个子规格Secure Boot。它要强行部署Secure Boot。

四、Secure Boot

Secure Boot只是UEFI的一个部分。两者的关系是局部与整体的关系。

Secure Boot的目的,是防止恶意软件侵入。它的做法就是采用密钥。UEFI规定,主板出厂的时候,可以内置一些可靠的公钥。然后,任何想要在这块主板上加载的操作系统或者硬件驱动程序,都必须通过这些公钥的认证。也就是说,这些软件必须用对应的私钥签署过,否则主板拒绝加载。由于恶意软件不可能通过认证,因此就没有办法感染Boot。

这个设想是好的。但是,UEFI没规定哪些公钥是可靠的,也没规定谁负责颁发这些公钥,都留给硬件厂商自己决定。

现在,微软就是要求,主板厂商内置Windows 8的公钥。

五、Windows 8

首先明确,在不打开Secure Boot的情况下,Windows 8可以安装。这与安装以前版本的Windows没有差别。

但是,微软规定,所有预装Windows 8的厂商(即OEM厂商)都必须打开Secure Boot。因此,消费者购买一台预装Windows 8的台式机或笔记本,想要在上面再安装其他操作系统(包括以前版本的Windows)是不可能的,除非关闭Secure Boot,或者其他操作系统能够通过Windows 8公钥的认证。

如果选择关闭Secure Root,那么预装的Windows 8将无法使用,需要重新安装。

六、实例:微星主板

ITwire的记者Sam Varghese,做了一个实验,想了解在打开Secure Boot的主板上,如何安装操作系统。

实验对象是微星公司Z77A-G41主板。它带有Secure Boot功能,默认是关闭的。

第一步,开机后按Delete键,进入BIOS,选择Windows 8 Configration选项。

第二步,选择最后一个Secure Boot选项。

第三步,打开(Enabled)Secure Boot功能,然后选择最后一个Key Management(密钥管理)选项。

第四步,输入厂商提供的公钥,也就是Windows 8的公钥(目前,任何其他操作系统都没有这类公钥。)

第五类,安装Windows 8之后,在命令行界面输入confirm-securebootuefi命令,结果为true,表示secureboot功能打开。

根据Sam Varghese测试,打开Secure Boot之后,再安装其他操作系统(包括以前版本的Windows),全部被主板拒绝。

七、对Linux的影响

Secure Boot规格的本意是,让操作系统厂商自行选择公钥,通过认证。但是实际上,只有微软公司才有能力,让主板厂商内置它的公钥,其他公司都不具备这种能力。

因此,如果要在打开Secure Boot的主板上安装Linux系统,这个系统就必须通过Windows 8的认证。

目前,微软公司把Windows 8的数字签名外包给了Verisign。操作系统厂商想要通过认证,就必须花99美元,向Verisign买一张数字证书,嵌入自家的操作系统。

最新动态是,Linux的各个发行版之中,Ubuntu已经购买了数字证书,Fedora和SUSE计划购买,其他发行版还没做出决定。

因此,在预装Windows 8的电脑上安装Linux(或其他操作系统)的最佳做法,就是进入BIOS,关闭Secure Boot。但是,这意味着你花钱买来的Windows 8将无法使用。

八、为什么Windows 8的公钥不可接受?

目前看上去,Linux购买Windows 8的数字证书,是眼下唯一可行的相对容易的解决方法。但是,这种做法不可接受。

首先,系统的公钥被微软控制,后果难以预料。如果微软决定更换和废除这个公钥,Linux就要被迫跟进。

其次,Linux的启动管理器Grub是GPL许可证,该许可证(第三版)明文禁止软件使用密钥配合硬件阻止一部分用户的使用,因此要改用非GPL许可证的启动管理器。

再次,只有几个较大的Linux发行版才有能力购买数字证书,较小的发行版和用户自己定制的版本最终还是需要有自己的公钥。

九、关于移动设备

Secure Boot对移动设备的影响,比PC还要严重。

微软明确规定,所有PC主板必须带有关闭Secure Boot的选项。这不是因为微软的善意,而是因为如果不这样做,它一定会遭到反垄断起诉。

但是,在移动设备领域,微软不占优势,所以它就没有顾虑,规定所有安装Windows的移动设备的Secure Boot必须打开,而且没有关闭选项。

微软的平板电脑Surface RT就是一个最好的例子。它的Secure Boot是打开的,没法关闭,而且微软用了一个不同于桌面电脑Windows 8操作系统的公钥,且不提供获得数字证书的途径。因此理论上,用户不可能在Surface RT上安装其他操作系统。

还有报道称,使用Windows Phone 8操作系统的智能手机也将采用这种做法。那么,用户也就不可能在Windows Phone上安装其他操作系统了。

十、结束语

Secure Boot的本来用意是保证系统安全,但现在似乎成了厂商保护市场垄断、阻碍竞争一种手段。

除了微软公司,苹果公司也有这种倾向。在新一代的iPhone和iPad上面安装其他操作系统,似乎是不可能的。

自由软件基金会呼吁反Secure Boot垄断,就是基于这种考虑:用户应该拥有硬件和软件的使用自由,操作系统应该是开放的,而不是封闭的。

作为一种规格,自由软件基金会并不反对Secure Boot,它只是要求硬件厂商提供便利,使得用户可以更容易地安装和管理公钥,从而使用硬件平台对所有操作系统(以及设备驱动)保持开放。

我认为,这是完全合理的要求,对于保证用户的自由和业界的健康生态极为重要。让我们一起支持这个行动(签名捐助),密切关注事态下一步的发展。

(完)

文档信息