25 |
26 | 你也可以通过扫描二维码在手机上观看
27 |
28 |
29 | 这个 Web Slides 开源在[我的 Github 上](https://github.com/Huxpro/js-module-7day)，欢迎你帮助我完善这个展示文稿，你可以给我提 issue，可以 fork & pull request。如果它能帮助到你了，希望你还能不吝啬 star 一下这个项目
30 |
31 |
32 | ### Catalog
33 |
34 | - 第一日 上古时期 ***Module?*** 从设计模式说起
35 | - 第二日 石器时代 ***Script Loader*** 只有封装性可不够，我们还需要加载
36 | - 第三日 蒸汽朋克 ***Module Loader*** 模块化架构的工业革命
37 | - 第四日 号角吹响 ***CommonJS*** 征服世界的第一步是跳出浏览器
38 | - 第五日 双塔奇兵 ***AMD/CMD*** 浏览器环境模块化方案
39 | - 第六日 精灵宝钻 ***Browserify/Webpack*** 大势所趋，去掉这层包裹！
40 | - 第七日 王者归来 ***ES6 Module*** 最后的战役
41 |
42 | ### Thanks
43 |
44 | [Reveal.js](http://lab.hakim.se/reveal-js)
45 |
--------------------------------------------------------------------------------
/source/_posts/js-module-loader.markdown:
--------------------------------------------------------------------------------
1 | ---
2 | layout: post
3 | title: "Example Post with Code Highlight"
4 | subtitle: "CommonJS，RequireJS，SeaJS 归纳笔记"
5 | date: 2013-05-25
6 | author: "Hux"
7 | catalog: true
8 | header-img: "post-bg-js-module.jpg"
9 | tags:
10 | - 前端开发
11 | - JavaScript
12 | ---
13 |
14 |
15 |
16 | ## Foreword
17 |
18 | > Here comes Module!
19 |
20 | 随着网站逐渐变成「互联网应用程序」，嵌入网页的 JavaScript 代码越来越庞大，越来越复杂。网页越来越像桌面程序，需要一个团队分工协作、进度管理、单元测试……我们不得不使用软件工程的方法，来管理网页的业务逻辑。
21 |
22 | 于是，JavaScript 的模块化成为迫切需求。在 ES6 Module 来临之前，JavaScript 社区提供了强大支持，尝试在现有的运行环境下，实现模块的效果。
23 |
24 |
25 | ---
26 |
27 | ## Catalog
28 |
29 |
30 | 1. [CommonJS & Node](#commonjs--node)
31 | 3. [History](#history)
32 | 4. [RequireJS & AMD](#requirejs--amd)
33 | 5. [SeaJS & CMD](#seajs--cmd)
34 | 6. [AMD vs CMD](#amd-vs-cmd)
35 | 7. [WebPack](#webpack)
36 |
37 |
38 |
39 | ```
40 | function autoDetect(){
41 | console.log('ye, it is written in JavaScript!')
42 | }
43 | ```
44 |
45 | ## CommonJS & Node
46 |
47 | > Javascript: not just for browsers any more! —— CommonJS Slogen
48 |
49 | 前端模块化的事实标准之一，2009 年 8 月，[CommonJS](http://wiki.commonjs.org/wiki/CommonJS) 诞生。
50 |
51 | CommonJS 本质上只是一套规范（API 定义），而 Node.js 采用并实现了部分规范，CommonJS Module 的写法也因此广泛流行。
52 |
53 |
54 | 让我们看看 Node 中的实现：
55 | {% codeblock lang:js %}
56 | // 由于 Node 原生支持模块的作用域，并不需要额外的 wrapper
57 | // "as though the module was wrapped in a function"
58 |
59 | var a = require('./a') // 加载模块（同步加载）
60 | a.doSomething() // 等上一句执行完才会执行
61 |
62 | exports.b = function(){ // 暴露 b 函数接口
63 | // do something
64 | }
65 | {% endcodeblock %}
66 |
67 |
68 | `exports`是一个内置对象，就像`require`是一个内置加载函数一样。如果你希望直接赋值一个完整的对象或者构造函数，覆写`module.exports`就可以了。
69 |
70 | CommonJS 前身叫 ServerJS ，**后来希望能更加 COMMON，成为通吃各种环境的模块规范，改名为 CommonJS** 。CommonJS 最初只专注于 Server-side 而非浏览器环境，因此它采用了同步加载的机制，这对服务器环境（硬盘 I/O 速度）不是问题，而对浏览器环境（网速）来说并不合适。
71 |
72 |
73 | 因此，各种适用于浏览器环境的模块框架与标准逐个诞生，他们的共同点是：
74 |
75 | * 采用异步加载（预先加载所有依赖的模块后回调执行，符合浏览器的网络环境）
76 | * 虽然代码风格不同，但其实都可以看作 CommonJS Modules 语法的变体。
77 | * 都在向着 **COMMON** 的方向进化：**兼容不同风格，兼容浏览器和服务器两种环境**
78 |
79 | 本文接下来要讨论的典例是：
80 |
81 | * RequireJS & AMD（异步加载，预执行，依赖前置。默认推荐 AMD 写法）
82 | * SeaJS & CMD（异步加载，懒执行，依赖就近，默认推荐 CommonJS 写法）
83 |
84 |
85 |
86 |
87 |
88 | ## History
89 |
90 |
91 |
92 | > 此段落参考自玉伯的 [前端模块化开发那点历史](https://github.com/seajs/seajs/issues/588)
93 |
94 | 09-10 年间，CommonJS（那时还叫 ServerJS） 社区推出 [Modules/1.0](http://wiki.commonjs.org/wiki/Modules) 规范，并且在 Node.js 等环境下取得了很不错的实践。
95 |
96 | 09年下半年这帮充满干劲的小伙子们想把 ServerJS 的成功经验进一步推广到浏览器端，于是将社区改名叫 CommonJS，同时激烈争论 Modules 的下一版规范。分歧和冲突由此诞生，逐步形成了三大流派：
97 |
98 |
99 | 1. **Modules/1.x** 流派。这个观点觉得 1.x 规范已经够用，只要移植到浏览器端就好。要做的是新增 [Modules/Transport](http://wiki.commonjs.org/wiki/Modules/Transport) 规范，即在浏览器上运行前，先通过转换工具将模块转换为符合 Transport 规范的代码。主流代表是服务端的开发人员。现在值得关注的有两个实现：越来越火的 component 和走在前沿的 es6 module transpiler。
100 | 2. **Modules/Async** 流派。这个观点觉得浏览器有自身的特征，不应该直接用 Modules/1.x 规范。这个观点下的典型代表是 [AMD](http://wiki.commonjs.org/wiki/Modules/AsynchronousDefinition) 规范及其实现 [RequireJS](http://requirejs.org/)。这个稍后再细说。
101 | 3. **Modules/2.0** 流派。这个观点觉得浏览器有自身的特征，不应该直接用 Modules/1.x 规范，但应该尽可能与 Modules/1.x 规范保持一致。这个观点下的典型代表是 BravoJS 和 FlyScript 的作者。BravoJS 作者对 CommonJS 的社区的贡献很大，这份 Modules/2.0-draft 规范花了很多心思。FlyScript 的作者提出了 Modules/Wrappings 规范，这规范是 CMD 规范的前身。可惜的是 BravoJS 太学院派，FlyScript 后来做了自我阉割，将整个网站（flyscript.org）下线了。这个观点在本文中的典型代表就是 SeaJS 和 CMD 了
102 |
103 |
104 | 补一嘴：阿里 KISSY 的 KMD 其实跟 AMD 非常类似，只是用 `add`和`use` 两个源自于 YUI Modules 的函数名替换了 `define` 和 `require` ，但其原理更接近 RequireJS ，与 YUI Modules 的 `Y` 沙箱 Attach 机制并不相同
105 |
106 |
107 | ## RequireJS & AMD
108 |
109 | [AMD (Async Module Definition)](http://wiki.commonjs.org/wiki/Modules/AsynchronousDefinition) 是 RequireJS 在推广过程中对模块定义的规范化产出。
110 |
111 | > RequireJS is a JavaScript file and module loader. It is optimized for in-browser use, but it can be used in other JavaScript environments
112 |
113 | RequireJS 主要解决的还是 CommonJS 同步加载脚本不适合浏览器 这个问题：
114 |
115 | {% gist 65481dbbf6d16e831a6cc89c3e37e6e5 display-emails-from-database.php %}
116 |
117 |
118 | > As the comment indicates above, if require() is async, this code will not work. However, loading scripts synchronously in the browser kills performance. So, what to do?
119 |
120 | 所以我们需要 **Function Wrapping** 来获取依赖并且提前通过 script tag 提前加载进来
121 |
122 |
123 | {% jsfiddle shorttag [tabs] [skin] [width] [height] %}
124 |
125 |
126 | 当依赖模块非常多时，这种**依赖前置**的写法会显得有点奇怪，所以 AMD 给了一个语法糖， **simplified CommonJS wrapping**，借鉴了 CommonJS 的 require 就近风格，也更方便对 CommonJS 模块的兼容：
127 |
128 | ```js
129 | define(function (require) {
130 | var dependency1 = require('dependency1'),
131 | dependency2 = require('dependency2');
132 |
133 | return function () {};
134 | });
135 | ```
136 | The AMD loader will parse out the `require('')` calls by using `Function.prototype.toString()`, then internally convert the above define call into this:
137 |
138 | ```js
139 | define(['require', 'dependency1', 'dependency2'], function (require) {
140 | var dependency1 = require('dependency1'),
141 | dependency2 = require('dependency2');
142 |
143 | return function () {};
144 | });
145 | ```
146 |
147 | 出于`Function.prototype.toString()`兼容性和性能的考虑，最好的做法还是做一次 **optimized build**
148 |
149 |
150 |
151 | AMD 和 CommonJS 的核心争议如下：
152 |
153 | ### 1. **执行时机**
154 |
155 | Modules/1.0:
156 |
157 | ```js
158 | var a = require("./a") // 执行到此时，a.js 才同步下载并执行
159 | ```
160 |
161 | AMD: （使用 require 的语法糖时）
162 |
163 | ```js
164 | define(["require"],function(require)){
165 | // 在这里，a.js 已经下载并且执行好了
166 | // 使用 require() 并不是 AMD 的推荐写法
167 | var a = require("./a") // 此处仅仅是取模块 a 的 exports
168 | })
169 | ```
170 |
171 | AMD 里提前下载 a.js 是出于对浏览器环境的考虑，只能采取异步下载，这个社区都认可（Sea.js 也是这么做的）
172 |
173 | 但是 AMD 的执行是 Early Executing，而 Modules/1.0 是第一次 require 时才执行。这个差异很多人不能接受，包括持 Modules/2.0 观点的人也不能接受。
174 |
175 | ### 2. **书写风格**
176 |
177 | AMD 推荐的风格并不使用`require`，而是通过参数传入，破坏了**依赖就近**：
178 |
179 | ```js
180 | define(["a", "b", "c"],function(a, b, c){
181 | // 提前申明了并初始化了所有模块
182 |
183 | true || b.foo(); //即便根本没用到模块 b，但 b 还是提前执行了。
184 | })
185 | ```
186 |
187 | 不过，在笔者看来，风格喜好因人而异，主要还是**预执行**和**懒执行**的差异。
188 |
189 | 另外，require 2.0 也开始思考异步处理**软依赖**（区别于一定需要的**硬依赖**）的问题，提出了这样的方案：
190 |
191 | ```js
192 | // 函数体内：
193 | if(status){
194 | async(['a'],function(a){
195 | a.doSomething()
196 | })
197 | }
198 | ```
199 |
200 | ## SeaJS & CMD
201 |
202 | CMD (Common Module Definition) 是 [SeaJS](http://seajs.org/docs/) 在推广过程中对模块定义的规范化产出，是 Modules/2.0 流派的支持者，因此 SeaJS 的模块写法尽可能与 Modules/1.x 规范保持一致。
203 |
204 | 不过目前国外的该流派都死得差不多了，RequireJS 目前成为浏览器端模块的事实标准，国内最有名气的就是玉伯的 Sea.js ，不过对国际的推广力度不够。
205 |
206 | * CMD Specification
207 | * [English (CMDJS-repo)](https://github.com/cmdjs/specification/blob/master/draft/module.md)
208 | * [Chinese (SeaJS-repo)](https://github.com/seajs/seajs/issues/242)
209 |
210 |
211 | CMD 主要有 define, factory, require, export 这么几个东西
212 |
213 | * define `define(id?, deps?, factory)`
214 | * factory `factory(require, exports, module)`
215 | * require `require(id)`
216 | * exports `Object`
217 |
218 |
219 | CMD 推荐的 Code Style 是使用 CommonJS 风格的 `require`：
220 |
221 | * 这个 require 实际上是一个全局函数，用于加载模块，这里实际就是传入而已
222 |
223 | ```js
224 | define(function(require, exports) {
225 |
226 | // 获取模块 a 的接口
227 | var a = require('./a');
228 | // 调用模块 a 的方法
229 | a.doSomething();
230 |
231 | // 对外提供 foo 属性
232 | exports.foo = 'bar';
233 | // 对外提供 doSomething 方法
234 | exports.doSomething = function() {};
235 |
236 | });
237 | ```
238 |
239 | 但是你也可以使用 AMD 风格，或者使用 return 来进行模块暴露
240 |
241 | ```js
242 | define('hello', ['jquery'], function(require, exports, module) {
243 |
244 | // 模块代码...
245 |
246 | // 直接通过 return 暴露接口
247 | return {
248 | foo: 'bar',
249 | doSomething: function() {}
250 | };
251 |
252 | });
253 | ```
254 |
255 |
256 |
257 | Sea.js 借鉴了 RequireJS 的不少东西，比如将 FlyScript 中的 module.declare 改名为 define 等。Sea.js 更多地来自 Modules/2.0 的观点，但尽可能去掉了学院派的东西，加入了不少实战派的理念。
258 |
259 |
260 |
261 | ## AMD vs CMD
262 |
263 | **虽然两者目前都兼容各种风格，但其底层原理并不相同，从其分别推荐的写法就可以看出两者背后原理的不同：**
264 |
265 | 1. 对于依赖的模块，AMD 是**提前执行**，CMD 是**懒执行**。（都是先加载）
266 | * CMD 推崇**依赖就近**，AMD 推崇**依赖前置**。
267 |
268 | 看代码：
269 |
270 | ```js
271 | // AMD 默认推荐
272 |
273 | define(['./a', './b'], function(a, b) { // 依赖前置，提前执行
274 |
275 | a.doSomething()
276 | b.doSomething()
277 |
278 | })
279 |
280 | ```
281 |
282 | ```js
283 | // CMD
284 |
285 | define(function(require, exports, module) {
286 |
287 | var a = require('./a')
288 | a.doSomething()
289 |
290 | var b = require('./b') // 依赖就近，延迟执行
291 | b.doSomething()
292 | })
293 | ```
294 |
295 |
296 |
297 |
298 |
299 |
300 | ## WebPack
301 |
302 | > working...
303 |
--------------------------------------------------------------------------------
/source/_posts/js-module-loader/post-bg-js-module.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Kaijun/hexo-theme-huxblog/34e1314a9cd397f497847be173750ee9305708d8/source/_posts/js-module-loader/post-bg-js-module.jpg
--------------------------------------------------------------------------------
/source/_posts/js-version.markdown:
--------------------------------------------------------------------------------
1 | ---
2 | layout: post
3 | title: "Example Post"
4 | date: 2014-09-22
5 | author: "Hux"
6 | header-img: "post-bg-js-version.jpg"
7 | tags:
8 | - 前端开发
9 | - JavaScript
10 | - 翻译
11 | ---
12 |
13 |
14 | JavaScript 有着很奇怪的命名史。
15 |
16 | 1995 年，它作为网景浏览器（Netscape Navigator）的一部分首次发布，网景给这个新语言命名为 LiveScript。一年后，为了搭上当时媒体热炒 Java 的顺风车，临时改名为了 JavaScript *（当然，Java 和 JavaScript 的关系，就和雷锋和雷锋塔一样 —— 并没有什么关系）*
17 |
18 | 
19 | 歪果仁的笑话怎么一点都不好笑
20 |
21 | > 译者注：[wikipedia 的 JavaScript 词条](https://en.wikipedia.org/wiki/JavaScript#History) 更详细的叙述了这段历史
22 |
23 | 1996 年，网景将 JavaScript 提交给 [ECMA International（欧洲计算机制造商协会）](http://www.ecma-international.org/) 进行标准化，并最终确定出新的语言标准，它就是 ECMAScript。自此，ECMAScript 成为所有 JavaScript 实现的基础，不过，由于 JavaScript 名字的历史原因和市场原因（很显然 ECMAScript 这个名字并不令人喜欢……），现实中我们只用 ECMAScript 称呼标准，平时都还是使用 JavaScript 来称呼这个语言。
24 |
25 |
26 | > 术语（译者注）：
27 | >
28 | > * *标准（Standard）*： 用于定义与其他事物区别的一套规则
29 | > * *实现（Implementation）*： 某个标准的具体实施/真实实践
30 |
31 |
32 | 不过，JavaScript 开发者们并不怎么在乎这些，因为在诞生之后的 15 年里，ECMAScript 并没有多少变化，而且现实中的很多实现都已经和标准大相径庭。其实在第一版的 ECMAScript 发布后，很快又跟进发布了两个版本，但是自从 1999 年 ECMAScript 3 发布后，十年内都没有任何改动被成功添加到官方规范里。取而代之的，是各大浏览器厂商们争先进行自己的语言拓展，web 开发者们别无选择只能去尝试并且支持这些 API。即使是在 2009 年 ECMAScript 5 发布之后，仍然用了数年这些新规范才得到了浏览器的广泛支持，可是大部分开发者还是写着 ECMAScript 3 风格的代码，并不觉得有必要去了解这些规范。
33 |
34 | > 译者注：[ECMAScript 第四版草案](https://en.wikipedia.org/wiki/ECMAScript#4th_Edition_.28abandoned.29)由于太过激进而被抛弃，Adobe 的 [ActionScript 3.0](https://en.wikipedia.org/wiki/ActionScript) 是 ECMAScript edition 4 的唯一实现（ Flash 差点就统一 Web 了）
35 |
36 | 到了 2012 年，事情突然开始有了转变。大家开始推动停止对旧版本 IE 浏览器的支持，用 ECMAScript 5 (ES5) 风格来编写代码也变得更加可行。与此同时，一个新的 ECMAScript 规范也开始启动。到了这时，大家开始逐渐习惯以对 ECMAScript 规范的版本支持程度来形容各种 JavaScript 实现。在正式被指名为 ECMAScript 第 6 版 (ES6) 之前，这个新的标准原本被称为 ES.Harmony（和谐）。2015 年，负责制定 ECMAScript 规范草案的委员会 TC39 决定将定义新标准的制度改为一年一次，这意味着每个新特性一旦被批准就可以添加，而不像以往一样，规范只有在整个草案完成，所有特性都没问题后才能被定稿。因此，ECMAScript 第 6 版在六月份公布之前，又被重命名为了 ECMAScript 2015（ES2015）
37 |
38 | 目前，仍然有很多新的 JavaScript 特性或语法正在提议中，包括 [decorators（装饰者）](https://github.com/wycats/javascript-decorators)，[async-await（async-await 异步编程模型）](https://github.com/lukehoban/ecmascript-asyncawait) 和 [static class properties（静态类属性）](https://github.com/jeffmo/es-class-properties)。它们通常被称为 ES7，ES2016 或者 ES.Next 的特性，不过实际上它们只能被称作提案或者说可能性，毕竟 ES2016 的规范还没有完成，有可能全部都会引入，也有可能一个都没有。TC39 把一个提案分为 4 个阶段，你可以在 [Babel 的官网](https://babeljs.io/docs/usage/experimental/) 上查看各个提案目前都在哪个阶段了。
39 |
40 | 所以，我们该如何使用这一大堆术语呢？下面的列表或许能帮助到你：
41 |
42 | * **ECMAScript**：一个由 ECMA International 进行标准化，TC39 委员会进行监督的语言。通常用于指代标准本身。
43 | * **JavaScript**：ECMAScript 标准的各种实现的最常用称呼。这个术语并不局限于某个特定版本的 ECMAScript 规范，并且可能被用于任何不同程度的任意版本的 ECMAScript 的实现。
44 | * **ECMAScript 5 (ES5)**：ECMAScript 的第五版修订，于 2009 年完成标准化。这个规范在所有现代浏览器中都相当完全的实现了。
45 | * **ECMAScript 6 (ES6) / ECMAScript 2015 (ES2015)**：ECMAScript 的第六版修订，于 2015 年完成标准化。这个标准被部分实现于大部分现代浏览器。可以查阅[这张兼容性表](http://kangax.github.io/compat-table/es6/)来查看不同浏览器和工具的实现情况。
46 | * **ECMAScript 2016**：预计的第七版 ECMAScript 修订，计划于明年夏季发布。这份规范具体将包含哪些特性还没有最终确定
47 | * **ECMAScript Proposals**：被考虑加入未来版本 ECMAScript 标准的特性与语法提案，他们需要经历五个阶段：Strawman（稻草人），Proposal（提议），Draft（草案），Candidate（候选）以及 Finished （完成）。
48 |
49 | 在这整个 Blog 中，我将把目前的 ECMAScript 版本称作 ES6（因为这是大部分开发者最习以为常的），把明年的规范称作 ES2016（因为，与 ES6/ES2015 不同，这个名字将在整个标准化过程中沿用）并且将那些还没有成为 ECMAScript 定稿或草案的未来语言概念称为 ECMAScript 提案或者 JavaScript 提案。我将尽我所能在任何可能引起困惑的场合沿用这篇文章。
50 |
51 | #### 一些资源
52 |
53 |
54 |
55 | * TC39 的 [Github 仓库](https://github.com/tc39/ecma262)上可以看到所有目前公开的提案
56 | * 如果你还不熟悉 ES6，Babel 有一个[很不错的特性概览](https://babeljs.io/docs/learn-es2015/)
57 | * 如果你希望深入 ES6，这里有两本很不错的书： Axel Rauschmayer 的 [Exploring ES6](http://exploringjs.com/)和 Nicholas Zakas 的 [Understanding ECMAScript 6](https://leanpub.com/understandinges6)。Axel 的博客 [2ality](http://www.2ality.com/) 也是很不错的 ES6 资源
58 |
59 | 
60 | 来学 JavaScript 吧！
61 |
62 | #### 著作权声明
63 |
64 | 本文译自 [ES5, ES6, ES2016, ES.Next: What's going on with JavaScript versioning?](http://benmccormick.org/2015/09/14/es5-es6-es2016-es-next-whats-going-on-with-javascript-versioning/)
65 | 译者 [黄玄](http://weibo.com/huxpro)，首次发布于 [Hux Blog](http://huangxuan.me)，转载请保留以上链接
66 |
--------------------------------------------------------------------------------
/source/_posts/js-version/javascript-java.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Kaijun/hexo-theme-huxblog/34e1314a9cd397f497847be173750ee9305708d8/source/_posts/js-version/javascript-java.jpg
--------------------------------------------------------------------------------
/source/_posts/js-version/keep-calm-and-learn-javascript.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Kaijun/hexo-theme-huxblog/34e1314a9cd397f497847be173750ee9305708d8/source/_posts/js-version/keep-calm-and-learn-javascript.png
--------------------------------------------------------------------------------
/source/_posts/js-version/post-bg-js-version.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Kaijun/hexo-theme-huxblog/34e1314a9cd397f497847be173750ee9305708d8/source/_posts/js-version/post-bg-js-version.jpg
--------------------------------------------------------------------------------
/source/_posts/unix-linux-note.markdown:
--------------------------------------------------------------------------------
1 | ---
2 | layout: post
3 | title: "Example Post With Default Header Image"
4 | subtitle: "不适合人类阅读，非常水的自我笔记"
5 | date: 2015-04-14
6 | author: "Hux"
7 | # header-img: "post-bg-unix-linux.jpg"
8 | tags:
9 | - OS
10 | - Unix
11 | - Linux
12 | ---
13 |
14 | > This document is not completed and will be updated anytime.
15 |
16 |
17 | ## Catagory
18 |
19 | 1. [Unix](#unix)
20 | 1. [Bell Labs](#bell-labs)
21 | 2. [Xenix](#xenix)
22 | 3. [BSD](#bsd)
23 | 4. [FreeBSD & Apple](#freebsd--apple)
24 | 5. [NeXTStep](#nextstep)
25 | 6. [Darwin](#darwin)
26 | 7. [POSIX](#posix)
27 | 2. [Unix-like](#unix-like)
28 | 1. [Single Unix Specification](#single-unix-specification)
29 | 2. [Apple iOS](#apple-ios)
30 | 3. [XNU Kernel](#xnu-kernel)
31 | 3. [Linux](#linux)
32 | 1. [Linux Kernel](#linux-kernel)
33 | 2. [GNU Project](#gnu-project)
34 | 3. [Android](#android)
35 | 4. [Android Kernel](#android-kernel)
36 | 5. [Android ROM](#android-rom)
37 | 6. [Chrome OS](#chrome-os)
38 | 7. [Chromium OS](#chromium-os)
39 |
40 | ---
41 |
42 | ## Unix
43 |
44 |
45 | > Unix is a **family** of multitasking, multiuser computer OS.
46 |
47 |
48 | Derive from the original **AT&T Unix**, Developed in the 1970s at **Bell Labs** (贝尔实验室), initially intended for use inside the **Bell System**.
49 |
50 | - #### Bell Labs
51 | Bell 和 AT&A 在那时已经是一家了，可以看到那时的通信公司真是一线 IT 公司呢。
52 | **C 语言也是 Bell Labs 的产物**，从一开始就是为了用于 Unix 而设计出来的。所以 Unix （在 73 年用 C 重写）在高校流行后，C 语言也获得了广泛支持。
53 |
54 |
55 |
56 | AT&T licensed Unix to outside parties(第三方) from the late 1970s, leading to a variety of both **academic** (最有有名的 BSD ) and **commercial** (Microsoft Xenix, IBM AIX, SunOS Solaris)
57 |
58 | - #### Xenix
59 | 微软 1979 年从 AT&A 授权来的 Unix OS，配合着 x86 成为当时最受欢迎的 Unix 发行版。后来 M$ 和 IBM 合作开发 OS/2 操作系统后放弃，后来最终转向 **Windows NT**。
60 |
61 | - #### BSD
62 | **Barkeley Software Distribution**, also called Berkeley Unix. Today the term "BSD" is used to refer to any of the BSD descendants(后代) which together form a branch of the family of Unix-like OS.(共同组成了一个分支)
63 | - **BSD 最大的贡献是在 BSD 中率先增加了虚拟存储器和 Internet 协议**，其 TCP/IP(IPv4 only) 代码仍然在现代 OS 上使用（ Microsoft Windows and most of the foundation of Apple's OS X and iOS ）
64 | - BSD 后来发展出了众多开源后代，包括 FreeBSD, OpenBSD, NetBSD 等等……很多闭源的 vendor Unix 也都从 BSD 衍生而来。
65 |
66 | - #### FreeBSD & Apple
67 | FreeBSD 不但是 Open Source BSD 中占有率最高的，还直接影响了 Apple Inc : NeXT Computer 的团队在 FreeBSD 上衍生出了 NeXTSTEP 操作系统，这货后来在 Apple 时期演化成了 **Darwin** ，这个“达尔文”居然还是个开源系统，而且是 the Core of **Mac OS X** and **iOS**.
68 |
69 | - #### NeXTSTEP
70 | An **object-oriented**, multitasking OS. Low-level C but High-level OC language and runtime the first time, combined with an **OO aplication layer** and including several "kits".
71 | 大家都知道 NeXT 是 Steve Jobs 被 forced out of Apple 后和 a few of his coworkers 创办的，所以 **NeXTSTEP 绝对是证明 Jobs 实力的作品。**
72 |
73 | - #### Darwin
74 | [Darwin](http://en.wikipedia.org/wiki/Darwin_(operating_system\)), the core set of components upon which Mac OS X and iOS based, mostly POSIX compatible, but has never, by itself, been certified as being compatible with any version of **POSIX**. (OS X, since Leopard, has been certified as compatible with the Single UNIX Specification version 3)
75 | **所以说 Mac OS X 算是很正统 Unix 的了**
76 |
77 | - #### POSIX
78 | 可移植操作系统接口, Portable Operating System Interface, is a family of standards specified by the IEEE from maintaining compatibility between OS, defines the API along with Command Line Shells and utility interfaces, for software comaptibility with variants of Unix and other OS.
79 | - Fully POSIX compliant:
80 | - OS X
81 | - QNX OS (BlackBerry)
82 | - Mostly complicant:
83 | - Linux
84 | - OpenBSD/FreeBSD
85 | - Darwin (Core of **iOS** & OS X)
86 | - **Android**
87 | - Complicant via compatibility feature （通过兼容功能实现兼容）
88 | - Windows NT Kernel
89 | - Windows Server 2000, 2003, 2008, 2008 R2, 2012
90 | - Symbian OS (with PIPS)
91 | - Symbian was a closed-source OS.
92 |
93 |
94 | ---
95 |
96 | ## Unix-like
97 |
98 | > A Unix-like (sometimes referred to as UN*X or *nix) operating system is one that behaves in a manner similar to a Unix system, while not necessarily conforming to or being certified to any version of the **Single UNIX Specification**.
99 |
100 | There is no standard for defining the term.
101 | 其实 Unix-like 是个相对模糊的概念：
102 |
103 | * 最狭义的 Unix 单指 Bell Labs's Unix
104 | * 稍广义的 Unix 指代所有 Licensed Unix, 即通过了 SUS 的 Unix-like ，比如 OS X
105 | * 最广义的 Unix 即所有 Unix-like 系统，无论它是否通过过任何 SUS，包括 Linux，BSD Family 等
106 |
107 | #### Single UNIX Specification
108 | The Single UNIX Specification (SUS) is the collective name of a family of standards for computer OS, compliance with which is required to **qualify for the name "Unix"**, like **POSIX**.
109 |
110 | #### Apple iOS
111 | iOS is a **Unix-like OS based on Darwin(BSD)** and OS X, which share some frameworks including Core Foundation, Founadtion and the Darwin foundation with OS X, but, Unix-like shell access is not avaliable for users and restricted for apps, **making iOS not fully Unix-compatible either.**
112 |
113 | The iOS kernal is **XNU**, the kernal of Darwin.
114 |
115 | #### XNU Kernel
116 | XNU, the acronym(首字母缩写) for ***X is Not Unix***, which is the **Computer OS Kernel** developed at Apple Inc since Dec 1996 for use in the Mac OS X and released as free open source software as part of Darwin.
117 |
118 |
119 | ---
120 |
121 | ## Linux
122 |
123 |
124 | > Linux is a Unix-like and mostly POSIX-compliant computer OS.
125 |
126 |
127 | 
128 |
129 |
130 | #### Linux Kernel
131 |
132 | 严格来讲，术语 Linux 只表示 [Linux Kernel](http://en.wikipedia.org/wiki/Linux_kernel) 操作系统内核本身，比如说 Android is Based on Linux (Kernel). Linus 编写的也只是这一部分，一个免费的 Unix-like Kernel，并不属于 GNU Project 的一部分。
133 |
134 | 但通常把 Linux 作为 Linux Kernel 与大量配合使用的 GNU Project Software Kit (包括 Bash, Lib, Compiler, 以及后期的 GUI etc) 所组合成的 OS 的统称。（包括各类 Distribution 发行版）
135 |
136 | 这类操作系统也被称为 **GNU/Linux**
137 |
138 |
139 | #### GNU Project
140 |
141 | The GNU Project is a **free software, mass collaboration** project, which based on the following freedom rights:
142 |
143 | * Users are free to run the software, share (copy, distribute), study and modify it.
144 | * GNU software guarantees these freedom-rights legally (via its license).
145 | * So it is not only FREE but, more important, FREEDOM.
146 |
147 | In order to ensure that the *entire* software of a computer grants its users all freedom rights (use, share, study, modify), even the most fundamental and important part, **the operating system**, needed to be written.
148 |
149 | This OS is decided to called **GNU (a recursive acronym meaning "GNU is not Unix")**. By 1992, the GNU Project had completed all of the major OS components except for their kernel, *GNU Hurd*.
150 |
151 | With the release of the third-party **Linux Kernel**, started independently by *Linus Torvalds* in 1991 and released under the GPLv0.12 in 1992, for the first time it was possible to run an OS **composed completely of free software**.
152 |
153 | Though the Linux kernel is not part of the GNU project, it was developed using GCC and other GNU programming tools and was released as free software under the GPL.
154 |
155 | Anyway, there eventually comes to the **GNU/Linux**
156 |
157 |
158 | * **GPL**: GNU General Public License
159 | * **GCC**: GNU Compiler Collection
160 |
161 | 其他与 GPL 相关的自由/开源软件公共许可证：
162 |
163 | * [Mozilla Public License](http://en.wikipedia.org/wiki/Mozilla_Public_License)
164 | * [MIT License](http://en.wikipedia.org/wiki/MIT_License)
165 | * [BSD Public License](http://en.wikipedia.org/wiki/BSD_licenses)
166 | * GPL 强制后续版本必须是自由软件，而 BSD 的后续可以选择继续开源或者封闭
167 | * [Apache License](http://en.wikipedia.org/wiki/Apache_License)
168 |
169 | 
170 |
171 | #### Android
172 |
173 | Android is a mobile OS based on **Linux Kernel**, so it's definitely **Unix-like**.
174 |
175 | **Linux is under GPL so Android has to be open source**.
176 | Android's source code is released by Google under open source licenses, although most Android devices ultimately ship with a combination of open source and proprietary software, including proprietary software developed and licensed by Google *(GMS are all proprietary)*
177 |
178 | #### Android Kernel
179 |
180 | Android's kernel is based on one of the Linux kernel's long-term support (LTS) branches.
181 |
182 | **Android's variant of the Linux kernel** has further architectural changes that are implemented by Google outside the typical Linux kernel development cycle, and, certain features that Google contributed back to the Linux kernel. Google maintains a public code repo that contains their experimental work to re-base Android off the latest stable Linux versions.
183 |
184 | Android Kernel 大概是 Linux Kernel 最得意的分支了，Android 也是 Linux 最流行的发行版。不过，也有一些 Google 工程师认为 Android is not Linux in the traditional Unix-like Linux distribution sense. 总之这类东西就算有各种协议也还是很难说清楚，在我理解里 Android Kernel 大概就是 fork Linux Kernel 之后改动和定制比较深的例子。
185 |
186 |
187 | #### Android ROM
188 |
189 | 既然提到 Android 就不得不提提 Android ROM
190 |
191 | ROM 的本义实际上是只读内存：
192 |
193 | **Read-only memory** (ROM) is a class of storage medium used in computers and other electronic devices. Data stored in ROM can only be modified slowly, with difficulty, or not at all, so it is **mainly used to distribute firmware (固件)** (software that is very closely tied to specific hardware, and unlikely to need frequent updates).
194 |
195 | ROM 在发展的过程中不断进化，从只读演变成了可编程可擦除，并最终演化成了 Flash
196 |
197 | * PROM (Programmable read-only memory)
198 | * EPROM (Erasable programmable read-only memory)
199 | * EEPROM (Electrically erasable programmable read-only memory)
200 | * Flash memory (闪存)
201 |
202 | Flash 的出现是历史性的，它不但可以作为 ROM 使用，又因其极高的读写速度和稳定性，先后发展成为U盘（USB flash drives）、移动设备主要内置存储，和虐机械硬盘几条街的固态硬盘（SSD），可以说这货基本统一了高端存储市场的技术规格。
203 |
204 | 所以我们平时习惯说的 ROM 其实还是来源于老单片机时代，那时的 ROM 真的是写了就很难（需要上电复位）、甚至无法修改，所以那时往 ROM 里烧下去的程序就被称作 firmware ，固件。久而久之，虽然技术发展了，固件仍然指代那些不常需要更新的软件，而 ROM 这个词也就这么沿用下来了。
205 |
206 | 所以在 wiki 里是没有 Android ROM 这个词条的，只有 [List of custom Android firmwares](http://en.wikipedia.org/wiki/List_of_custom_Android_firmwares)
207 |
208 | > A custom firmware, also known as a custom ROM, ROM, or custom OS, is an aftermarket distribution of the Android operating system. They are based on the Android Open Source Project (AOSP), hence most are open-sourced releases, unlike proprietary modifications by device manufacturers.
209 |
210 | 各类 Android ROM 在 Android 词类下也都是属于 **Forks and distributions** 一类的。
211 |
212 | 所以我说，其实各类 Android ROM 也好，fork Android 之流的 YunOS、FireOS 也好，改了多少东西，碰到多深的 codebase ……**其实 ROM 和 Distribution OS 的界限是很模糊的**，为什么 Android 就不可以是移动时代的 Linux ，为什么 Devlik/ART 就不能是移动时代的 GCC 呢？
213 |
214 | #### Chrome OS
215 |
216 | Chrome OS is an operating system based on the **Linux kernel** and designed by Google to work with web applications and installed applications.
217 |
218 | 虽然目前只是个 Web Thin Client OS ，但是 RoadMap 非常酷……
219 |
220 | * **Chrome Packaged Application** (Support working offline and installed)
221 | * **Android App Runtime** (run Android applications natively...fxxking awesome)
222 |
223 | 平复一下激动的心情，还是回到正题来：
224 |
225 | #### Chromium OS
226 |
227 | Chrome OS is based on Chromium OS, which is the open-source development version of Chrome OS, which is a **Linux distribution** designed by Google.
228 |
229 | For Detail, Chromium OS based on [Gentoo Linux](http://en.wikipedia.org/wiki/Gentoo_Linux), emm...
230 |
--------------------------------------------------------------------------------
/source/_posts/unix-linux-note/post-bg-unix-linux.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/Kaijun/hexo-theme-huxblog/34e1314a9cd397f497847be173750ee9305708d8/source/_posts/unix-linux-note/post-bg-unix-linux.jpg
--------------------------------------------------------------------------------
/source/about/index.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: "about"
3 | title: "About"
4 | date: 2016-04-21 04:48:33
5 | description: "Hey, this is Kaijun."
6 | header-img: "img/about-bg.jpg"
7 | comments: true
8 | ---
9 |
10 |
11 | >写写代码，做做设计，看看产品。
12 | >世界那么大，多玩玩看看。
13 |
14 | 9月21日上午，阳光明媚，鲜花斗艳。帕洛阿尔托苹果店里欢声笑语，人头攒动。苹果公司首席执行官蒂姆·库克先生在店长欧阳猛南陪同下，不远千米，深入到一线店面，为那里的员工带去节曰的问候和良好的祝愿。
51 |
156 |
52 |
53 |
54 |
155 |
58 |
59 | <%- page.content %>
60 |
61 |
62 | 63 | <% if(config['duoshuo_share'] && config['duoshuo_username']) { %> 64 | 65 | 66 |
122 |
123 |
124 |
125 |
153 |
154 | 62 | 63 | <% if(config['duoshuo_share'] && config['duoshuo_username']) { %> 64 | 65 | 66 |
"
72 | data-content="<%- truncate(strip_html(page.content), {length: 50, omission: '...'}) %> | <%= config.SEOTitle %> " >
73 |
83 |
84 |
85 |
86 | <% } %>
87 |
88 | 84 |
-
89 | <% if (page.prev){ %>
90 |
- 91 | ← Previous Post 92 | 93 | <% } %> 94 | <% if (page.next){ %> 95 |
- 96 | Next Post → 97 | 98 | <% } %> 99 |
104 |
110 |
111 | <% } %>
112 |
113 | <% if(config['disqus_username']) { %>
114 |
115 |
108 |
109 |
116 |
117 |
118 |
119 | <% } %>
120 |
121 | 
21 |
22 |
23 |
24 |
25 |
26 |
--------------------------------------------------------------------------------
/themes/huxblog/layout/page.ejs:
--------------------------------------------------------------------------------
1 | ---
2 | layout: layout
3 | ---
4 |
5 |