 |  |
人物：乔布斯
时间：2010年
话语：7英寸的平板电脑将是一种处在中间状态的产品：其尺寸过大，难以与智能手机展开竞争；但同时其尺寸又过小，难以与iPad展开竞争。
结果：小于8英寸的iPad Mini已呼之欲出
严格意义上讲，已过世的乔布斯的判断，和今天的苹果之间，关系稍有点远。但如果就"苹果"而言，对7寸平板的判断，的确是有些反复的。正如这个专栏一贯并不想说大佬们"出尔反尔"而只是进行商业复盘，苹果在7寸平板上的反复，也值得关注。
先来看一个很早期的产品：MP3播放器。04年乔布斯对低端的闪存类播放器（iPod是硬盘类）公开表示不会去做。在彼时，市场上大致6成份额属于闪存类播放器。一年后，iPod的份额则超过了6成——看上去硬盘类的iPod大获全胜，闪存类可以彻底淘汰了。不过，乔布斯依然没有放过这3成市场。06年闪存类播放器iPod Shuffle出世，随后iPod Nano又发布，基本上一统了北美的播放器市场。
苹果对音乐播放器本身的利润追求是可以想见的，但背后我的判断是有更深层次的原因：它寻求的是一统数字音乐市场。iTunes是相当成功的产品，它上线的第一天准备了20万支单曲mp3，当天就获得25万次的下载（这些可都是收费的），这让苹果意识到硬件带软件是可行的。数字式的虚拟产品到了一定的规模，毛利率一定比造硬件来得高。把非自家公司的音乐播放器统统排挤出去，将更有利于iTunes形成更大的规模。苹果的硬件开道，软件为王是核心思路，虽然乔布斯表述为"制造软件的公司应该为自家设计硬件"。
现在来看看iPad。一个名为UBM Tech Insights的市场调研公司声称，Nexus7的成本为184美元，kindle fire则为153美元，而iPad是278美元。但是，前面两款平板的售价都只有199美元，基本上可以说是微利。而售价499美元的iPad显然有37%的利润率。iPad的硬件本身就在赚大钱。10英寸的iPad在同规格平板上没有任何敌手，为什么还要出mini版本与android系竞争呢？
关键还是在"应用商店"。这个相当核心的软件可不在乎平板是10寸还是7寸。由于售价比较低，可以预期7英寸平板会迅速打开局面，占据一定的市场。而7寸平板里都是安卓商店或亚马逊商店，就会导致开发者围聚在android系上，假以时日，苹果的app store将面临严重的威胁。
苹果的应用商店是一项革命性的发明。与前期微软的windows系列不同，苹果iOS系统借助应用商店，深入到了应用（软件）的分发和变现过程，并从中谋利。Win系统从来不过问一款软件用户是怎么取得的，更不会插手软件的销售。苹果将之颠覆，这个颠覆的成功，以至于让微软都虚心学习，在win8中植入了应用商店。
有理由相信应用商店本身的利润可能还低于硬件销售所获取的利润（苹果并不是拿足了三成的份额，它需要给通道商和信用卡商一部分收入），但它对整个苹果生态的稳定和扩张起了决定性的作用。当开发者离app store而去之时，便是苹果没落之日，因为用户并不是买一个iPad拿回去当数字相框的。
当下如日中天的苹果也有足够的危机意识，它要把它一手打造的"平板电脑"市场牢牢掌控在手中，任何一个有撼动app store王者地位的企图都必须将之扼杀在摇篮里——事实上，可能由于乔布斯的坚持，7寸平板市场已经不再是一片蛮荒之地了。无论是安卓平板还是亚马逊平板，市场的表现让苹果意识到7寸会成其为一个市场，先行者的探路也坚定了继任者库克的决心。还好，app store的应用数量依然很多，开发者依然很喜欢在苹果上开发应用，占据7寸市场，苹果依然不算太迟。
最后一个有趣的问题，苹果会不会做大号的iPhone（也就是5寸机）？委实很难讲。大屏手机目前也就主要是三星在探路（甚至很夸张地做了7寸手机），如果市场表现到有足够的用户能接受这种尺寸，苹果不会不出手的。
对于苹果而言，从iPod到iPad这些硬件都不是最关键的，哪一种硬件能捍卫iOS、iTunes和app store，苹果就会去做。这是它最根本的商业逻辑。
—— 结束的分割线 ——
本文为《21世纪商业评论》的专栏文章。这个专栏的名字叫《大佬与大话》，专门收集TMT圈子商业领袖的一些 "大话"。但本专栏的目的并非是指责这些大佬说话不算话，或者是开空头支票。我们都知道，所谓此一时彼一时，时间点变了，自然计划要变。本专栏的目的就是 "复盘"，来分析一下这个时间点究竟怎么变了导致大佬们的话变成了大话。
| 无觅猜您也喜欢： | |||
 电子阅读器 vs. 平板电脑 | iPad的逻辑 | 平板上的新闻客户端 | 大佬与大话 之 乔布斯：我们不会做平板 |
| 无觅 | |||
diff是Unix系统的一个很重要的工具程序。
它用来比较两个文本文件的差异，是代码版本管理的基石之一。你在命令行下，输入：
$ diff <变动前的文件> <变动后的文件>
diff就会告诉你，这两个文件有何差异。它的显示结果不太好懂，下面我就来说明，如何读懂diff。
一、diff的三种格式
由于历史原因，diff有三种格式：
* 正常格式（normal diff）
* 上下文格式（context diff）
* 合并格式（unified diff）
我们依次来看。
二、示例文件
为了便于讲解，先新建两个示例文件。
第一个文件叫做f1，内容是每行一个a，一共7行。
a
a
a
a
a
a
a
第二个文件叫做f2，修改f1而成，第4行变成b，其他不变。
a
a
a
b
a
a
a
三、正常格式的diff
现在对f1和f2进行比较：
$ diff f1 f2
这时，diff就会显示正常格式的结果：
4c4
< a
---
> b
第一行是一个提示，用来说明变动位置。
4c4
它分成三个部分：前面的"4"，表示f1的第4行有变化；中间的"c"表示变动的模式是内容改变（change），其他模式还有"增加"（a，代表addition）和"删除"（d，代表deletion）；后面的"4"，表示变动后变成f2的第4行。
第二行分成两个部分。
< a
前面的小于号，表示要从f1当中去除该行（也就是第4行），后面的"a"表示该行的内容。
第三行用来分割f1和f2。
---
第四行，类似于第二行。
> b
前面的大于号表示f2增加了该行，后面的"b"表示该行的内容。
最早的Unix（即AT&T版本的Unix），使用的就是这种格式的diff。
四、上下文格式的diff
上个世纪80年代初，加州大学伯克利分校推出BSD版本的Unix时，觉得diff的显示结果太简单，最好加入上下文，便于了解发生的变动。因此，推出了上下文格式的diff。
它的使用方法是加入c参数（代表context）。
$ diff -c f1 f2
显示结果如下：
*** f1 2012-08-29 16:45:41.000000000 +0800
--- f2 2012-08-29 16:45:51.000000000 +0800
***************
*** 1,7 ****
a
a
a
!a
a
a
a
--- 1,7 ----
a
a
a
!b
a
a
a
这个结果分成四个部分。
第一部分的两行，显示两个文件的基本情况：文件名和时间信息。
*** f1 2012-08-29 16:45:41.000000000 +0800
--- f2 2012-08-29 16:45:51.000000000 +0800
"***"表示变动前的文件，"---"表示变动后的文件。
第二部分是15个星号，将文件的基本情况与变动内容分割开。
***************
第三部分显示变动前的文件，即f1。
*** 1,7 ****
a
a
a
!a
a
a
a
这时不仅显示发生变化的第4行，还显示第4行的前面三行和后面三行，因此一共显示7行。所以，前面的"*** 1,7 ****"就表示，从第1行开始连续7行。
另外，文件内容的每一行最前面，还有一个标记位。如果为空，表示该行无变化；如果是感叹号（!），表示该行有改动；如果是减号（-），表示该行被删除；如果是加号（+），表示该行为新增。
第四部分显示变动后的文件，即f2。
--- 1,7 ----
a
a
a
!b
a
a
a
除了变动行（第4行）以外，也是上下文各显示三行，总共显示7行。
五、合并格式的diff
如果两个文件相似度很高，那么上下文格式的diff，将显示大量重复的内容，很浪费空间。1990年，GNU diff率先推出了"合并格式"的diff，将f1和f2的上下文合并在一起显示。
它的使用方法是加入u参数（代表unified）。
$ diff -u f1 f2
显示结果如下：
--- f1 2012-08-29 16:45:41.000000000 +0800
+++ f2 2012-08-29 16:45:51.000000000 +0800
@@ -1,7 +1,7 @@
a
a
a
-a
+b
a
a
a
它的第一部分，也是文件的基本信息。
--- f1 2012-08-29 16:45:41.000000000 +0800
+++ f2 2012-08-29 16:45:51.000000000 +0800
"---"表示变动前的文件，"+++"表示变动后的文件。
第二部分，变动的位置用两个@作为起首和结束。
@@ -1,7 +1,7 @@
前面的"-1,7"分成三个部分：减号表示第一个文件（即f1），"1"表示第1行，"7"表示连续7行。合在一起，就表示下面是第一个文件从第1行开始的连续7行。同样的，"+1,7"表示变动后，成为第二个文件从第1行开始的连续7行。
第三部分是变动的具体内容。
a
a
a
-a
+b
a
a
a
除了有变动的那些行以外，也是上下文各显示3行。它将两个文件的上下文，合并显示在一起，所以叫做"合并格式"。每一行最前面的标志位，空表示无变动，减号表示第一个文件删除的行，加号表示第二个文件新增的行。
六、git格式的diff
版本管理系统git，使用的是合并格式diff的变体。
$ git diff
显示结果如下：
diff --git a/f1 b/f1
index 6f8a38c..449b072 100644
--- a/f1
+++ b/f1
@@ -1,7 +1,7 @@
a
a
a
-a
+b
a
a
a
第一行表示结果为git格式的diff。
diff --git a/f1 b/f1
进行比较的是，a版本的f1（即变动前）和b版本的f1（即变动后）。
第二行表示两个版本的git哈希值（index区域的6f8a38c对象，与工作目录区域的449b072对象进行比较），最后的六位数字是对象的模式（普通文件，644权限）。
index 6f8a38c..449b072 100644
第三行表示进行比较的两个文件。
--- a/f1
+++ b/f1
"---"表示变动前的版本，"+++"表示变动后的版本。
后面的行都与官方的合并格式diff相同。
@@ -1,7 +1,7 @@
a
a
a
-a
+b
a
a
a
七、阅读材料
* How to work with diff representation in git
（完）
| 
十个月前，本站首次报道 Mozilla B2G 系统。现在它已经成长为 Firefox OS，是时候去看看的它的架构了。
本文脱胎自 B2G 官方 Wiki 页面，略过了其中代码示例的部分。为了方便理解，在部分描述时会跟当下流行的 Android 操作系统进行比较。
女神、壁虎和娃娃
Firefox OS 从架构上来讲具有了三个层面：
Gaia（盖亚，大地女神）：Firefox OS 的用户界面，包含了在开机之后所有用户能看到部分，比如锁屏、主屏幕、应用程序启动器、拨号器、短信、相机等等作为智能手机必须具备的。Gaia 完全使用 HTML、CSS 和 JavaScript 编写，使用成为标准的 Web API 的接口和底层设备关联。因此，Gaia 可以在任何实现了 Web API 的设备上运行，比如桌面浏览器。Firefox OS 上的第三方程序也是以类似的方式运行并与 Gaia 共存的。
Gecko（壁虎）：Firefox OS 的应用程序运行时环境，用 C++（不知道后期是否会转用 Rust ）实现了 Web API，供包括 Gaia 在内的应用程序使用，同时保证 Web API 可以在 Firefox OS 的目标硬件平台上运行。于是乎 Gecko 包含了必要的网络层，图像层、布局管理和 JavaScript 虚拟机以及移植层。
Gonk（蛋形娃娃）：Firefox OS 的操作系统底层，也是 Gecko 的一个目标移植平台，包含 Linux 内核和用户态的硬件抽象层，这一部分和 Android 以及嵌入式 Linux 共享了很多组件和驱动，比如 bluez, libusb 等。说是一个目标移植平台，是由于 Gecko 抽象层在理论上也可以运行在 Android 或者桌面操作系统上，不过由于 Firefox OS 项目主导了 Gonk 开发，可以提供一些其他系统上不具备的接口给 Gecko 使用，比如完整的电话通讯层。
光、信号和起源
和绝大多数 Android 手机一样，预装 Firefox OS 的手机在开机后也会首先由极小化的 bootloader 实现最初的引导操作，然后链式引导更高级别更复杂的引导器，最终实现内核的加载。这个过程具体如何与设备制造商有关，相应的 bootloader 操作很有可能重用现在各个厂商在 Android 设备上所用的私有 fastboot 协议实现。意味着只要适当调整 Firefox OS 所用的引导器，在 Android 手机上使用现有刷机工具刷入 Firefox OS 在技术上没有障碍。
由于嵌入式领域还比较封闭，这个过程也会加载很可能是设备相关的私有调制解调器固件。于是乎在这个层面上 Firefox OS 和 Android 一样不是开放的。
紧接的故事就是 Linux 内核的载入和 PID 1 号 init 进程的产生了，和一般嵌入式 Linux 的初始化没有太大差别。这里使用的 Linux 内核会紧随上游，不过也会吸纳厂商通过 Android Open Source Project 提交的一些尚未合并的设备相关代码。内核载入之后的大多数设备访问将通过 sysfs 的方式供用户态程序访问。
爬行动物时代
在这里，b2g 以主系统进程的形态被 init 进程激活，并通过 RPC 或者 Socket 的方式实现和其他负责诸如网络、无线电等功能的进程通讯。除此之外，b2g 还会通过 dbus-daemon 和 IPDL 这两种特殊的方式实现用户态进程间通讯。
dbus 不用赘述，用过任意一个现代桌面 Linux 发行版的用户对其都不陌生，最近合并入了 systemd 成为其一部分，不过依然可以单独运行。IPDL 则是 Mozilla 特有的进程间通讯协议定义语言，允许在 C++ 进程间安全且有组织的传递消息。运行着 libxul.so 的b2g 进程将使用 IPDL 启动一系列内容子进程，上层的网页程序和其他网页内容将在独立的内容子进程中运行，在技术上和现在 Firefox 浏览器的标签页处理类似。
面对多媒体文件， Gecko 对于 OGG Vorbis 音频, OGG Theora 视频和 WebM 视频这些开放格式将提供原生支持，以后正式发布时为了 WebRTC 引入对 Opus 的支持也是完全有可能的。而对于私有格式将通过 libstagefright 的方式访问私有解码器和实现硬件加速。
感触、表现和尾巴
Gecko 负责将来自 Gonk 的各种输入事件解析成可供标准网页程序使用的 DOM 事件，包括按键、触屏操作等等，源自标准 Linux 输入设备 input-device。这些来自 Gecko 的 DOM API 由在 C++ 和 JavaScript 之间的外部函数接口和对象模型组成，使用普遍的 XPIDL 规定。
网络通讯则分别交由 wpasupplicant 和 RIL(Radio Interface Layer) 完成。和桌面 Linux 发行版一样，wpasupplicant 负责 WiFi 环境下的接入，Gecko 为其开发了附属的 WifiWorker.js 供网页程序了解 WiFi 连接状态。RIL 则负责广域网络的通讯，其中负责跟调制解调部分沟通的 rild 很可能是来自制造商的私有代码，rildproxy 则是一个为了安全考虑而设置的中间代理，起到连结 rild 和 b2g 的作用。同样，也有 ril_worker.js 暴露状态和操作接口供上层程序使用。
和 Android 4.0+ 类似，Gecko 完全使用 OpenGL ES 2.0 实现混合。Gecko 会将页面的各个区域绘制入内存缓冲，然后调用 OpenGL 命令将内容混合并渲染于屏幕上。和 Android 早期借助 skia 实现的软件混合相比，Firebox OS 从一开始就依赖于 GPU 的渲染能力，其效果值得期待。
在 Gecko 的最底层则是负责和目标系统交互的移植层。在这一部分包含针对不同目标系统的平台相关代码(Gonk，Android，OS X 等)，并将其统一化为可供 Gecko 上层子系统使用的 C++ API。
更多内容敬请期待
分类: Embedded, Featured, Reviews | 永久链接 | 收藏到 del.icio.us | Email 给好友 | 1 评论 | 捐助本站
| |
对于 API 设计，这个演示稿讲得实存是太赞了，等不及的同学马上了解一下《RESTful API Design, Second Edition》的这 107 页吧。如果希望先听我讲讲 10 分钟收获的同学，可以先看下面的描述。
以为需要买本书，看完整本才能明白什么是好的接口。没想到，利用 HTTP Verbs 和 URL，可以这样做非常简洁的 API。"对牛弹琴"被用以描述做无效劳动，可见弹琴者几乎做的都是无用功，而作者以深入浅出的方式让牛听懂琴变成了 — 甚至像我这样的牛 — 在 10 分钟之内立马理解。其主要需要注意的点可以归纳为以下几句：
保持 RESTful。只需 2 种 URL。不使用动词。使用复数名词。具体优于抽象。提供 JSON 的原则是支持 JS 调用。把复杂的参数放于 ? 号后面。借鉴优秀的 API。提供异常描述。提供库或者 SDK。
这里面值得强调，或者说可能需要一点解析的是这几点：
结合 HTTP Verbs，我们通常只需要 2 种 URL，一种用于集合的调用，一种用于单个实例的调用：
所有 API 都一样。其实我想你想到的可能是这样的形式，因为毕竟会需要有四种动作：创建 / 查看 / 修改 / 删除
看起来不错。或者还可以变成 /dogCreate 之类的来减少一层，但还是不能实质上减少数目。这时太多接口总是导致记错，并且还需要记得 HTTP Verbs 与 URL 的对应。代码层面上也比较难做（或者应该对比下后面的实现）。何不考虑与 HTTP Verbs 结合：
这个时候我们只需要 2 种 URL，与 HTTP Verbs 充分结合：
| POST | GET | PUT | DELETE | |
|---|---|---|---|---|
| /dogs | 创建 | 查看列表 | 批量修改 | 删除所有 |
| /dogs/1234 | error | 查看单个实例 | 修改单个实例 | 删除单个实例 |
这点似乎一点难理解，先让我们来看一下几个设计吧：
// twitter "created_at": "Thu Nov 03 05:19:38 +0000 2011" //bing "DateTime": "2011-10-29T09:35:00Z" //Foursquare "createdAt": 1320296464
这里假设我们有两种需要，一种是直接放入页面显示，一种是做计时器用，那么当我们拥有的两个变量，在 bing 和 4sq 上是这样的：
var obj = JSON.parse(response); // bing var stamp = obj.DateTime; // 返回 2011-10-29T09:35:00Z // 显示出来也看得出是一个日期 // 但不能做计数器用，需要转换，这种格式 JS 还不好转 // 4sq var stamp = obj.createdAt; // 返回 // 显示出来需要用 JS 转 1320296464，因为是秒数，可以方便转成各种格式 // 可直接用于计数
显然，这种方式更灵活。API 最好支持 JS 直接调用/使用。
这个如上面第一点所提到的，层级导致代码的难度增大，不如放成参数；这样还可以保证 API 接口的简洁和少量，而实现同样多的功能。
然后，或者你会像我一样，再一次阅读。然后去迭代/优化你的 API。
| |
| |
近日有媒体报道，大名鼎鼎的《纽约时报》本季财报中有一个非常值得注意的亮点：它的广告营收降至2.2亿美元，而订户收入则上涨至2.33亿美元。这说明，收费阅读所创造的进项超过了免费阅读所创造的进项。这件事引起了很多媒体的兴奋：原来内容真是可以卖出钱来的。
不过我觉得这个兴奋早了点，一个季度的财务情况并不能说明太多的问题。就《纽约时报》整体而言，它的毛利比去年同期基本持平，净利润亏损1.2亿美元（去年同期还有3200万美元的进账）。连续数个季度以来，《纽约时报》的净利润不断下降，终于到了本季出现巨额亏损的地步。以这个趋势来衡量，说《纽约时报》就此数字脱困，未免过于乐观了。
经济学再怎么厚重，其根本就是两个字"稀缺"，所有的利益都来自于稀缺性。媒体借助两样稀缺的东西来建立它的商业模式。其一、内容；其二、说话的渠道。媒体依靠专业的采编制作队伍向大众提供他们自己无法取得的内容，由此进行交换，是为收费阅读（观看）。另外，媒体由于有大众传播力，可以让企业或政府向大众发布信息，由此换来收入，是为广告公关。但在数字互联网时代，这两样稀缺性都遭受到了严峻的考验。
先是web1.0，也就是以门户为代表的免费信息超市出现，让媒体的第一个稀缺摇摇欲坠，然后是web2.0，内容加剧了爆炸性的供应，9成9以上的媒体受到了切肤之痛，更重要的是，web2.0不仅让用户贡献内容，也让企业可以贡献内容。最近闹得沸沸扬扬的电商价格战，它的先后逻辑是这样的：企业在微博上免费喊话，媒体跟进报道。在我看来，第二个稀缺性的失去，对主要以广告为商业模式的媒体，才是致命的打击。
于是媒体开始反思自己的商业模式，重新定位自己的稀缺性。第二个稀缺性是这样解决的：媒体充分投入到社交网络中，在web2.0的世界里树立自己的广播渠道。并不是所有的企业或其掌门人都有6位数以上的粉丝的，"说话的渠道"看来还是有点价值，特别是对中小企业而言。不过需要注意的是，中小企业对细分相当敏感，媒体在社交网络上所吸引到的跟随者，以及向他们推送的商业信息，还是要多多考虑"细分"的问题。
第一个稀缺性，媒体的手法是两个：提高内容质量外加收费墙。对于《纽约时报》而言，内容质量有一定的保证，所以它的收费墙建设更受人关注。不过，我不得不说一句的是，《纽约时报》的这一手——即便不考虑它只是一个单季的数字——大多数媒体学不来。同样被很多媒体人挂在嘴上的《经济学人》，同理。要知道，前者是160年历史，后者是170年。时间，是不可能速成的。
媒体所报的信息大致是两种：某名人参观了某地——这属于简单事实，纯新闻报道，或者说，短讯。但信息消费者光光消费这点是不够的，他们需要知道，这个名人如何参观的？为什么要参观？参观后有什么后果？这我称之为"解释性信息"。就简单事实而言，所有的媒体都应该是一样的，但"解释性信息"，就八仙过海各显神通了。
一个在市场上有足够威望的媒体，容易用更小的成本去获得更具分量的解释，比如记者出去采访相对容易接受一些，邀请专业人士撰写评论也相对容易一些。这反过来又使得这类媒体的威望更甚——会有更多的人愿意阅读它们。但这个良性循环，没有时间的铺垫几乎是不可能的，这也正是《纽约时报》和《经济学人》成为数字时代的一个传统媒体榜样的根本道理：我的解释是稀缺的。
但大多数媒体并没有它们的本钱，我很难想像它们建立收费墙后会是什么后果——它们自己都难以想象，故而跟进者并不多，特别是国内的媒体。在总体上信息供大于求的数字时代，我承认还是有非常少量的优质内容，但如果仅仅靠这个，用直接收费的方式就想数字脱困，未免太简单了点。
媒体人士在考虑媒体的未来时，更多的目光应该投向这个范本：位于杭州的都市快报旗下的19楼这个本地化生活社区。这个目前已经坐拥上千万用户，估值上亿的网络公司，才是不折不扣的传统媒体数字脱困的样本，而绝不是什么大搞内容收费阅读。
—— 刊发于《东方早报》 ——
后注：我手上最新的《经济学人》的经营数字是这样的：2009－2010财政年度的税后利润增长1%，达到3800万英镑，近4亿元人民币。不晓得有无读者能提供一个最新的数字？能有出处更好，在此拜谢
| 无觅猜您也喜欢： | |||
 数字时代阅读报告第二期发布 |  《数字时代阅读报告》第五期发布 |  《数字时代阅读报告》第四期发布 |  《数字时代阅读报告》第九期发布 |
| 无觅 | |||
