CSDN 2014 开源技术大会实录
昨天受科大 LUG 之邀参加了 CSDN 主办的 2014 开源技术大会(OSTC),结合会上记的笔记和不靠谱的记忆,与诸位分享,如有错漏之处请回复指出。本文部分图片来自 CSDN 官方的图文直播,演讲者的 slides 我显然没有,据说 CSDN 官方随后几天会发布。
早上见到了又高又帅的 Thomas Yao 和 Deepin 的王勇(没拍下来)。
会场外 Deepin 和 Microsoft 的展板(不止这两家哦)
会场全景和开幕前播放的开源电影《Big Buck Bunny》
Keynote 1: 腾讯开源战略
腾讯社交网络事业群副总裁陈磊分享了腾讯的开源战略。腾讯实现了代码公司内部共享。之前腾讯把代码视为核心机密,QQ 的代码千万不能泄露。但 Google 只有 1% 与搜索引擎等核心技术相关的代码是不开放的,绝大部分代码都是全公司共享的。
为什么腾讯现在有底气把代码在公司内部共享,还在逐步以开源的形式与全社会共享呢?因为代码不再是软件公司的核心价值,现在即使把 QQ、微信的代码开放出来,也很难出现第二个与 QQ、微信抗衡的产品。公司文化现在是软件公司的核心价值,开源正是推广公司文化的一种方式。
腾讯的开源分为三个阶段:开放接口、开放能力、开放代码。开放接口是指开放一些 API 供开发者调用。开放能力是指将网络基础设施、服务质量等开放给公司外使用。开放代码就是开源。3Q 大战之后腾讯开始走开放战略,但 3Q 大战刚结束后的开放是浅层次的,现在正在往深层次发展。例如,关于监控运维体系的开放,原来腾讯计划以 SaaS(软件即服务)的方式做开放,但现在已经有很多成熟的监控运维开源框架,这时候开放几个 API 意义不大,因此腾讯现在计划将 SDN 之类核心技术开放给其他企业,获得社区支持。
接下来分享的是腾讯的“海量之道”,包括小步快跑、先扛住再优化、大系统小做等。例如腾讯搜索当年花两年从头开始做了个新架构,但从未上线,结果第一天上线就发现很多问题,8天后被迫下线。现在腾讯有个不成文的规矩,新项目必须在两个月内上线,在线上根据实际运营情况逐步改进。
腾讯正在分期开放若干核心系统的源码,第一期 6 个,第二期 30 多个。
Keynote 2: Accidentally On Purpose: the Early Story of Open Source
这场演讲的主讲是 Perl 语言创始人和开源软件运动的早期倡导者 Larry Wall,早在大会开始之前就有很多人拿着“骆驼书”求签名。Larry Wall 的演讲很幽默,slides 也颇有黑客范,还夹杂着一些中文。
Larry Wall 说他自己是“Crazy on purpose”(故意的疯狂)。开源的历史与计算机的历史一样长。早在 PDP-11 的时代,大学里的研究者们就把程序代码用 Email 互相传递。
开源软件需要用户来测试他们的程序。在大公司里,软件有专门的测试团队,但在开源软件的世界里用户就是测试团队。
这场演讲的主题是 “Accidentally On Purpose”,也就是在做软件的时候你并不知道你真的在做什么。有时软件是有意(on purpose)做的,但更多的时候是偶然(by accident)做出来的。运行在 PDP-11 上的 Warp 星际战争游戏是第一个开源软件,这就是偶然做出来的。
Larry Wall 说他自己的人生就是一个巧合。第一个巧合是他出生在一个程序员家庭。他的家人 1950 年代供职于兰德(RAND)公司,那时的计算机还在使用磁鼓内存(drum memory),那时他才 3 岁。第二个巧合是他有食物过敏,很多好吃的都无缘享用,只好宅起来搞计算机。
在 Internet 的史前时代,Larry Wall 他们都在使用 Usenet。当时用的是 UUDP 协议,带宽只有 100~200 bit/second。那个年代,他写了 rn 这个 Usenet 客户端。新闻用广播(flooding)的方式传播,而 Email 用路由的方式传递。当时的 Email 地址没有全局命名(也就是没有 @ 及后面的域名部分)。
接下来 Larry Wall 开发了 Warp,一个星际战争游戏。它是第一个开源软件,没有版权说明(license),运行在 BSD 操作系统上,现在已经不能在 Linux 上编译。
当年代码的补丁是通过邮件发送的,手工合并这些补丁成为了程序员的梦魇。因此 Larry Wall 写了 patch 实用工具。第一版只有他一个开发者,只有一个选项:补不补(patch or not patch,slides 上分别用中英文写了出来)。随后有了更多的开发者,patch 程序也有了自我防护的能力。
为了方便编写模板代码,Larry Wall 还创造了 metaconfigure,通过写 Manifest 文件的方式自动生成程序。metaconfigure 是现在 autoconf 思想上的前身。
Larry Wall 很大程度上以 Perl 语言的创始人闻名。Perl 最早是在 NSA 项目中偶然(by accident)诞生的,但后来倒闭了(倒闭的是项目但不是 NSA),之后 NASA 有意(on purpose)接手了 Perl 项目,Perl 得以继续发展下去。Perl 3 是以 GPL 版权协议发布的,Perl 4 是以 GPL + Artist 双协议发布的。
Perl 得以流行是因为它是 WWW(World Wide Web)的第一代脚本语言,Perl 偶然地帮助了 WWW。这可能是因为 Perl 是胶水语言,能嵌入在 HTML 里很好地一起工作。Perl 6 是 Perl 5 有意的一个分支(fork),不过偶然的成了一个更大的分支(注:把主线给吃掉了,跟 GCC 一样)。
软件开发有大有小,有快有慢。当出现 bug 时,及早修复和推迟修复都需要勇气。要考虑到用户的痛点。只修复挂掉的地方,而不要动其他地方。
用户需要一样东西的时候,事实上他们需要的可能是另一样东西。我们不应该只去满足那些容易满足的用户,而要去满足那些应当被满足的用户(目标用户)。
参与其他人的项目时,看起来我们没有任何控制权,但事实上有更多的控制权,因为我们可以从不同的任务中选择。发起自己的项目时,看起来有很多控制权,想干什么就干什么,但事实上控制权并不多,因为我们必须考虑项目全局而不能仅靠个人喜好。
软件项目里有的人像乌龟,慢而持久;有的人像兔子,快但不久就跑没影了。这两种人都要各取所长。对项目发起人来说,一定不能让自己像灯泡一样被烧坏,要持久地坚持下去。项目刚开始的时候莫谈宏图大略,从一个小点开始,不要急于邀请他人加入。
Keynote 3: 豆瓣 Code 开源历程
豆瓣技术总监清风分享了搭建豆瓣内部代码管理系统 Code 的心路历程。Code 的名字是随便起的,后来老板要求改名,但要改名就要对源代码大动干戈,因此说成是 CODE 四个字母分别代表一个意思,总算蒙混过关了。
豆瓣花了一年时间从 SVN 迁移到到 git。当年豆瓣的所有代码都在一个 SVN 仓库里。大家的工作流程是,先开一个分支,做若干次 commit,merge to trunk。Code review 的办法也很粗糙:把相关人召集起来开会,把代码打到投影上,在纸上记下意见,回去修改,改好后重复上述过程。这是非常低效的,提出的意见一般也没有什么深度,更重要的是 code review 意见没有积累,新人来了又得重蹈一遍覆辙。
Code 项目的初衷主要是两个:一是希望各组共享一些通用的代码和库,不要重复造轮子。二是需要一个平台完成 code review。在 code review 的事情上这体现了豆瓣文化:能用工具解决的就不用规章制度。能否使用开源项目的工作流程?开源项目里 pull request 的做法能否用在公司内部?
最早试用了 Github,但发生过丢数据的情况。Gitlab 当时版本比较低,只支持单项目。Github 私有项目要收费,成本比较高;为了保证代码安全,不论用 Github 还是用 Gitlab,都需要配一个 SA,这也是成本。老板说,你用一个星期自己写一个试试,要是不行就用现成的产品。幸运的是一个星期后原型搭建出来了,还能用。
Code 系统的开发流程是渐进式的,“先做滑板,发现要有把手,做成了自行车,最后做成了汽车”。比如在 diff 页面展开上下代码、预览 CSS 里的颜色,都是工程师对 code 项目自发做的功能。至今,公司半数以上的工程师参与了 code 系统的改进,移动开发者还做了 iOS App 便于在路上刷动态。
公司内部的代码管理系统最重要的是与 CI(持续集成)系统集成。Code review 基本上是代码风格,驼峰命名不符合 Python 规范之类的。CI 系统是检查程序逻辑的手段。对于一个 pull request,只要 CI 是红的(有测试没有通过),就一定不 merge,哪怕是 hot fix。CI 还能促进写单元测试,之前口头上鼓励写单元测试都被当成耳旁风,给现金奖励对程序员来说又不合适,现在有了与代码管理系统集成的 CI 系统,如果不写单元测试,就会被大家骂。
在 git 的使用方面,清风提了几点建议:
- commit message 要有意义。
- 不允许上千行的大 pull request。不鼓励闷头写完一个大功能,要一步步往后做,每做完一步就发个 pull request,一点点 review,最后再合并成一个大的 pull request(不需要再 review)。
- 鼓励使用commit -p,自我review,不要提交无关代码。
- git merge 会导致 git log 顺序比较乱,鼓励使用 git rebase 来与上游 merge。
豆瓣的产品上线频繁(每天 8~10 次),每个上线点都会标明这次上线的代码是哪些工程师写的,还会附上 commit log 和代码片段,这会给工程师带来荣誉感。工程师在 Code 系统中还可以得到勋章,这是 Github 没有的。工程师每完成一定的任务(如写单元测试、给别人的 commit 写评论)就能得到一定的积分,积分会以颜色深浅的形式显示在工程师的主页上,这使得即使是 VP 级别的工程师也不好意思让自己的时间线一片空白。
豆瓣 Code 系统内有 5000 多个项目,之所以有这么多项目,是因为豆瓣鼓励把代码写成库或者服务。开源不是简单的 git push,要有 license,要整理代码,要写成库或者服务的形式方便他人使用。豆瓣内没有私有项目,所有项目都是公司内公开的。
在 timeline 上可以看到全公司的代码动态,还有 iOS App 可以随时随地刷动态。Code 系统还支持表情(emoji),用得最多的是 LGTM。
目前 Code 系统已经开源。
圆桌论坛:开源社区在中国的运营和发展
这场圆桌论坛上各位嘉宾对开源社区的理解有一些分歧。一些嘉宾认为,在开源的同时需要有商业模式。每个大开源项目背后都有强大的公司支持。另一些嘉宾认为,大多数开源社区还是在自娱自乐,没有商业化的倾向,正如 Python 中文社区 Zoom.Quiet 的口头禅 “但行好事,莫问前程”。(事实上开源社区的商业化是这次圆桌原定的主题)
对于创业者来说,开源有利于提高声望,便于招人。在开源社区活跃的大学生不需要写简历,而且到社会上跟比自己大五六岁的人组建技术社区需要团队协作能力,比社团更有挑战。学生做 TedX 之类的活动,要勇敢,不要怕丢人。Google I/O 有个演讲《天才程序员的奥秘》,所谓的天才程序员也有痛苦和小白的时候,也需要 10000 小时的努力。做开源最重要的是在社区内坚持,邮件列表是公开的,要维护一致的形象,不能今天支持微软明天支持 Oracle。
社区不是一两个人撑起来的,有元老级的也有小白,每个人精力有限,开源社区最好的生态是稍微一号召所有人都愿意进来。但现状是大多数开源社区没有新的领导人,全靠创始人死撑到底。这主要是因为中国技术社区的参与者有“后来者” “创始人下属”的感觉,这种思路源于从小听指挥的教育,事实上在开源社区里没有领导与下属之分,只是有一些大家共同遵守的基本规则,不要不敢干。中国的开源社区需要营造所有人都是主人的文化。
台下提问,为什么技术社区不能像天涯猫扑这样搞成娱乐化的?Thomas Yao 曾经运营百度 Linux 吧,吧里经常挑起与 Windows 之类的宗教战争,而且还有“爆吧”,Thomas 希望吧里静下心来做一些技术讨论。事实上,每个人可以有多种身份多个圈子,但每个圈子要有自己的文化,娱乐圈与技术圈不同。
台下提问,有人把我们的开源软件改头换面,打上自己的旗号,怎么办?开源要做好心理准备,肯定会有人这么做的,开源需要包容的心态。
台下提问,开源项目开发者需要花大量时间去应对小白问题,时间不够用怎么办?“LAMP 人”社区创始人认为,确实需要与这样的人打交道,这些都是潜在的用户和客户。事实上有很多开源社区参与者都不是计算机专业,要做好文档和用户界面,不能用对技术人员的要求来要求用户。此外,开源项目需要找到包括公司、人力等方面的资源支持。
Python 开源异步并发框架的未来
这是 Archlinux 社区的王川在分会场1做的演讲。并行与并发的区别用“办护照”来类比:并行是指窗口的数量,并发是指大厅里等待的人数。并发是把服务器看成一个黑箱,从用户的角度考虑,而不关心有多少个核之类并行计算常关心的硬件能力。现代互联网应用更关注的是并发。
实现并发最简单的范式是多进程/多线程,但 Python 语言的多线程表现并不理想。另一种范式是事件驱动的并发编程,用 select、epoll、kqueue 之类的系统调用实现。
Python 较为流行的开源异步并发框架,首先介绍的是 Tornado。使用类似 node.js 的 callback 范式,在 I/O 结束后调用指定的回调函数。当程序逻辑复杂时,容易发生混乱。
Twisted 是目前最流行的异步并发框架,包含多种编程范式。
- protocol/transport:protocol 是一个类,在发生特定的事件(如 HTTP 请求)时调用指定的方法,在方法内调用 transport 来做 I/O 操作(如发送 HTTP 响应)。
- deferred:callback 范式。
- inline callback:用 Python 的 generator 实现看似同步实则异步,I/O 操作以匿名函数作为回调,I/O 完成后会调用匿名函数中的 yield,“回到”同步的主调函数。
另外一种异步并发范式是利用 greenlet 库,把 generator 中显式的 yield 变成隐式。eventlet 和 gevent 是这种框架的代表,可以比较小的代价把已有的同步代码(如 django)变成异步。
代表着 Python 异步并发框架未来的是 AsyncIO,由 Python 作者编写,已经加入到 Python 3.4。AsyncIO 设计上类似 twisted 框架,而且是模块化的。每个模块可以用原厂发动机,也可以换组件。可以为不同的框架写适配器(adapter),通过 AsyncIO 实现不同框架的互操作性,将结束框架之间互相适配的乱象,也方便把使用其他框架的遗留代码迁移到 AsyncIO。AsyncIO 本来就是个完整的异步并发框架,允许换组件一方面是考虑到遗留代码,另一方面是各种框架各有所长。
像黑客一样使用命令行
这是 LinuxToy 站长 toy 在分会场1做的演讲。命令行管道的强大之处在于可以把互不相关的命令组合起来。例如找三月份的照片,用图形界面需要鼠标点进照片文件夹,选择详细信息模式显示,按照文件修改时间排序,再人肉找到三月份的那些。但在命令行里,只要 “cd photo; ls -l | grep Mar” 两条命令就行了。(注:我觉得这也体现了 UNIX 管道只是文本流而没有类型的弱点,如果照片名里包含 Mar 就也被选出来了)
Toy 让有过输错命令经历的举手,全场都举手了,并陷入一片笑声。如果输错命令了,不需要重新输一遍或者移动光标到出错的位置,可以用 ^suffix 删掉末尾多余的字符,^match^replacement 做替换,!:gs 做全局替换。口诀是“一删二换三全变”。
命令替换的工作原理是记录历史,“忘记历史,就是背叛”。可以用 !prefix 执行历史中匹配开头的命令,!?substr 执行包含子串的历史命令,!-n 执行第 n 条历史命令。
可以用 x=$(command) 来保存命令的执行结果到 shell 变量,然后在后面的命令中用 $x 引用;可以用 for loopvar in … 来遍历列表,对列表里的每个元素做特定的事。Toy 还讲了很多类似的 shell 小技巧,不再一一列出(我会说是因为我全忘了吗)。
演讲结束后台下有个问题,管道连起来的两个命令是并发还是阻塞?Toy 回答 “前一命令的输出作为后一命令的输入,因此是阻塞”,依我愚见,这个简单的回答有可能会被误解成 “左侧的命令执行完后再执行右侧的命令”。事实上管道两侧的命令是几乎同时开始运行的,只是右侧的命令在等待左侧命令的输出,左侧命令有一行输出(或者达到 buffer 长度)就会唤醒右侧的命令来读入这一行。如果右侧的命令在做计算而没有等待输入,则左右两侧的命令就是并发的。
台下还有人提问,你喜欢用 vi 还是 emacs?全场爆笑……
从开源软件到开放服务
这场在分会场1的演讲由七牛云存储的李道兵所作。李道兵还是中国为数不多的 Debian Developer 之一。
七牛云存储采用 GitHub 托管代码,为什么不自己搭建 git 服务器呢?这体现了传统软件与 SaaS(Software as a Service)的区别。他们的感觉是,一旦开始用云服务就很难回头。
近来网上流传一个段子 “就差一个写代码的了”,事实上这一个写代码的需要做线上、开发、运维、前端等一系列工作,一个人能完成吗?
- 线上的部分:L,A,M,P,缓存,存储,全文检索,消息队列
- 开发的部分:软件仓库,Bug 管理,持续集成,部署
- 运维的部分:监控,日志,数据分析,日常升级
- 前端的部分:抱歉我不懂前端
上述工作现在都有成熟的开源软件,其中一些已经有云服务。云服务节约了开源软件搭建、配置、运维的成本,使工程师能更专注于代码。在监控领域,监控宝是一个云服务的例子,监控也是云服务最早入驻的领域。云存储则是第二个云服务正在快速推广的领域。存储并不是把数据存到硬盘上这么简单。如何让用户的数据快速到服务器,服务器的数据快速到用户?首先需要在全国布 CDN,还需要把后端服务器产生的数据快速推送到 CDN 服务器,这些都要有很多经验积累才能做好,这种专业领域是最需要云服务的地方。
不仅是存储,其他领域也可以有云服务。例如操作系统,Linux 安全补丁谁来打?数据库,一般的 DBA 把 MySQL 优化到 2000 QPS(query per second)就不错了,但专业的优化团队能做到上万甚至十万 QPS。视频转码 ffmpeg 谁都会用,但参数呢?不同设备和分辨率的适配呢?全文检索更是专业领域。
云服务以什么形式存在呢?
- PaaS(Platform as a Service):没有操作系统,意味着无法分析现有系统的瓶颈,定位线上 bug 能力大大降低,只能靠日志。而且无法开发有状态的服务,有些业务逻辑必须用 dirty 的方法实现,PaaS 就做不了。
- 公有云:能解决部分问题,但对性能要求高的应用,如数据库,仍然无法保证响应时间(例如把数据库服务器和应用服务器部署到了不同的机房)。
李道兵认为,应该把云服务部署到机房。现在一些 IDC 确实在自己做这件事,不过专业的事情应该交给专业的团队去做。例如前面提到的数据库性能问题、视频转码问题。
云服务另一个很重要的问题是公平性。目前的开源软件一般都没有考虑公平性的问题,例如 MySQL 有 50 个用户,其中1个用户滥用,是否会影响到其他 49 个用户?这需要开源项目开发者与云服务提供商做很多工作。
我们是否该信任云服务呢?对开发者来说,既要信任,又要不信任。信任是指主动拥抱云服务。不信任是指:
- 要检查服务返回数据的完整性
- 要求服务提供商提供完整的异常日志
- 最好请求中包含 request ID 以便在出问题时交给服务商联调
- 无状态服务找两家云服务提供商做热备
开源无线电与 GNU Radio
这场在在分会场1的演讲是曾任清华大学电脑协会会长的王康所作,制作了支持 HackRF 开源软件无线电平台的板卡。
首先演示的是用声卡和 GNU Radio 软件解析电话拨号的 DTMF(双音多频)信号。王康和清华大学电子系的一位教授一起用口哨吹出了双音多频的 7,赢得阵阵掌声。支付宝的 “咻咻咻支付” 也是用的类似技术。把声卡的左声道接示波器 X,右声道接 Y,按 hold,就能在示波器上打出字来。甚至有人开发出了用声卡跑的 IP 协议栈,这下拔掉网线都不安全了,要拔掉声卡才行。
在上述演示中,软件无线电(Software Defined Radio)外设就是麦克风+喇叭,而 GNU Radio 是开源的信号处理框架,其中性能敏感部分用 C++ 编写,上层应用用 Python 编写。有了基于 Qt 的图形化前端,软件工程师只需半天时间就能学会,不再需要信号处理方面的基础知识了。
如果我们是想发送真正的无线电波,比如做个 “人大附中校门遥控器”(物联网设备制造商由于认为大家没有无线电设备而往往不考虑安全问题),怎么办呢?无线电常被戏称为“无限垫”,无线电收发机就不便宜;支持 GNU Radio 的 USRP 母板价格上万,每支持一个频段还要买特定的子板;要测量信号还要买价格数十万的 Agilent 等公司的仪表。开源软件无线电将为无线电爱好者提供一个能承受得起的实验平台,学生在学习相关课程时也不用“脑补”了。
开源软件无线电平台 HackRF 在 kickstarter 上融资,本来打算融 8 万美元,结果融了 60 万美元。HackRF 的基频覆盖 30 MHz 至 6 GHz,带宽 20 MHz,用来传输数据的话能够达到 20MB/s,跑满 USB 2.0 的接口。不过 HackRF 由于制造工艺问题不断跳票,因此星天科技就在国内自己做了一版。现场演示了无线电发清华校歌(93.4 MHz)、遥控小车,其中遥控小车演示出了 bug,还现场调试。
这个产品目前比较贵(2000+ RMB),主要是因为把 30M 至 6G 通用变频到 2.6G 的芯片要 600 大洋,这些零部件成本暂时降不下来。
在法律允许的范围内,软件无线电平台可以有很多用途,比如音质接近 CD 水平的 DAB 数字广播、GPS 信号回放、监控全球民航飞机和船舶的位置、无线控制四环路上的电子显示屏、干扰汽车锁车信号使得锁车无效等等。
Fedora 大使项目 & FUDCon
这场在分会场1的演讲是 Fedora 中文社区的赵涛所作,赵涛是清华大学网管会(TUNA)的一员。
Fedora 是一个 Linux 发行版,它有 “四项基本原则”:Freedom, Features, Friends, First。在 10 年间,Fedora 共有 20 个发布版本,最近发布的是 Fedora 20。
Fedora 项目是社区驱动、由 Red Hat 赞助的,分工为若干子项目。赵涛介绍了他所在的 Fedora 大使组。Fedora 大使代表了 Fedora 的形象,在全球范围内分为几个大区,分大区讨论决策。Fedora 大使组的交流方式包括会议、邮件列表、IRC 和 trac。
Fedora 大使组举办的活动包括 Fedora Release Party,Fedora Activity Day(分会场1的活动又名 Fedora Activity Day),FUDCon(亚太地区最大的 Fedora 盛会),Flock(欧美地区新兴的取代 FUDCon 的活动形式)。举办活动的预算都在 trac 中讨论,申请的预算越多,就要到越高级别的会议上讨论通过,会后凭 PDF 格式的发票通过 PayPal 报销。要加入 Fedora 大使组,需要选择一位 mentor 来带领。
今年的 FUDCon 于5月23日至25日在北航举行,不需要门票自由参加,这是 FUDCon 第一次来到中国。5月23日晚上首先会举行 FUDpub,之后两天的活动包括 Keynote(请开源界知名人士)、标准演讲、闪电演讲、workshop(培训讲座)、HackFest(交换 PGP 签名、打包等)。其中的标准演讲是公开征集(call for papers),大约 50% 的录用率。
用 Node.js 和 HTML5 开发本地应用
这场在分会场2的演讲是 Intel 开源技术中心的王文睿所作。2011 年,他在公司的 10% 业余时间里创作了 node-webkit 开源项目,node-webkit 现在已经成为 GitHub 最火的 C++ 项目,并且被 Intel 的一个内部项目采用,王文睿也因此全职维护 node-webkit 项目。
node-webkit 既利用了 Webkit 与 HTML5 天然结合的优势,又利用了广泛使用的 Node.js。Node.js 与 Webkit 间的函数调用是直接的,不用 IPC(进程间通信)。Node.js 采用异步的编程范式,一方面是为了支持高并发,另一方面是因为 JavaScript 历史上运行在浏览器里,不能长时间阻塞浏览器的 UI 线程,JavaScript 程序员习惯了异步编程。
node-webkit 支持 Windows、Mac 和 Linux 三大平台。它有跨平台的 UI 库,支持菜单、系统托盘和 shell 命令调用。node-webkit 还可以把 JS 编译成机器代码,保护源代码。从架构上说,Node.js 中有个 V8(JavaScript 引擎),Webkit 中也有个 V8,它们在 node-webkit 中被合并成一个实例,共享相同的上下文。
node-webkit 面临的挑战是浏览器与本地应用不同的安全模型。本地应用是受信的,而 Web 应用默认不受信,访问特定设置时要用户许可。node-webkit 要能编写本地应用,C++ 能做的事它都要能做。因此在浏览器原有的 frame、iframe 基础上,引入了新的框架类型 node-frame,其中可以调用 node-webkit 库的专有函数,修改浏览器设置,跨域访问,访问持久化存储,去掉窗口边框等。
node-webkit 现在已经“孵化”出一些成功的开源项目:
- Light Table:所见即所得的 IDE,由微软前 Visual Studio 项目经理所作。选用原因:HTML5 是业界持续投入的 UI 技术。
- Sqwiggle:在线协作软件。
- Leap Motion:可以使用 node-webkit 写控制器应用,官方应用商店也是用 node-webkit 写的。
- Popcorn Time:P2P 电影播放器(很火,不过侵犯版权)
在项目维护方面,node-webkit 作者认为,不应该只为了要 patch 而做开源项目,我们更关注的应该是项目有多少用户。开源软件需要投入时间和爱,他已经把用户与父母、另一半和孩子并列了。
SHLUG 的运营与管理
这是整个大会唯一一个不用 slides 的演讲,是 Thomas Yao 在分会场1所作。Thomas 发现,台湾很多人在用传统的即时通讯工具比如 IRC,但大陆很少有用。IRC 上有很多对 geek 来说好玩的东西,比如调戏 bot。至于发图片,有开放的 paste 服务,类似现在 GitHub 搞的 gist。
SHLUG(上海 Linux 用户组)诞生于 1997 年的 IRC,还举行了“一大” “二大”。1999 年,由于是否盈利的发展方向发生内部矛盾,结果社区停运两三年,最后支持不盈利的一方认为这个开源社区应该继续做下去。于是就有了国内最早的开源软件镜像 Geekbone,不过后来有了 163 源和高校源就完成了历史使命。
Thomas 曾经运营百度 Linux 吧,把鱼龙混杂的贴吧变成了技术讨论的地方。技术社区不需要规则和条例,如果有不合适的行为就告知,再有违反赶走就是了。Thomas 的规则是不允许在技术交流社区里讨论商业项目,包括自己的创业项目。开源社区的管理最好不要超过 3 个人。
台湾的雨苍加入 SHLUG 后,带来了新的气息,开始办 Hacking Thursday 活动,大家坐在咖啡馆里交流技术。这个活动最初办起来并不容易,有时只有一两个人来参加,但雨苍仍然坚持每周都办。现在每次 Hacking Thursday 都有二三十人,去哪个咖啡馆哪里就爆棚。有趣的是,曾有一个咖啡馆嫌他们人太多就把他们赶走了,结果这家咖啡馆现在倒闭了。
另外一个有趣的活动是 Rails Girls,两天内教女生用 Ruby 写网站。这个活动没想到很受女生欢迎,现在女生太多,每次来四五十个,男生(mentor)都不够用了。
Thomas 还讲了个有趣的典故:Canonical 的诞生。有人在 Debian 邮件列表里问,我有 2 亿美金,想不想做个发行版?列表里的很多人都认为这是 spam,但看口气不像 spam,于是就有人回复追问。Ubuntu 就从这里走来。
圆桌讨论:中国开源操作系统的回顾与未来
红旗 Linux 的贺唯佳、Ubuntu Kylin 的余杰、Linux Deepin 的王勇等参加圆桌讨论,Thomas Yao 主持。在自我介绍环节,Linux Deepin 的王勇要在场的 Vim 和 Emacs 党举手,公然挑起“圣战”。下面摘取各位嘉宾的一些观点(请勿对号入座,你要是全猜对了我只能膜拜了)。
是否看好 Linux 在桌面方面的发展?
- 我在 2000 年开始做红旗。Linux 不仅包括 PC,还包括移动计算。现在是想把超级计算机里用的高端 Linux 技术简单化,轻量化到普通用户。
- 开发者始终在个人 PC 上开发,3分钟开发,30分钟折腾 Emacs,对Linux桌面有很深的情感。在 Linux 桌面方面,政府政策导向起到很大的作用,例如 2004~2005 年迎来高峰,最近的棱镜门反映出安全问题。现在是 Linux 桌面发展的好机会,原因包括:Android、iOS 的普及让用户认识到了操作系统多样性;浏览器多样化和 Web 标准化结束了浏览器倒过来适应网站的时代;越来越多的商业公司在为 Linux 发展贡献力量。
- 桌面 Linux 用户包括终端消费类用户和办公类用户。桌面 Linux 应该首先在办公领域推广。只要搞定 OA 系统的兼容性,公司内的办公电脑也不太需要其他应用。随着云的发展,像 iCloud 一样的应用使得各种设备的数据自动同步,操作系统已经不重要。
- 反问主持人,为什么 Linux 桌面有开发能力,有社区,但无法占领市场?我们应该反思是否 Linux 桌面真正解决了普通用户的问题。不论输入输出设备如何更新换代,Apple 能理解在 QQ 群里买装备的人的真正需求,而很多 Linux 桌面的开发者并不理解。
你们各家将如何合作?
- 应该百花齐放,兰州拉面、北京炸酱面都有人爱吃。开源不应该闭门造车,做出来的东西应该共享。当年我们模仿 XP,社会上各种质疑,但公司毕竟需要商业。
- 国内的 Linux 发行版不可能统一,也没有达到百花齐放的时候。DistroWatch 上上百个发行版,有几个是中国的?要保持危机感。
- 不同发行版的差异性主要在 UI(用户界面),UI 事实上是软件中很重要的一部分,不同发行版适合不同的行业。
开源社区如何吸引留住和培养人才?
- 姜太公钓鱼,愿者上钩,所有 Deepin 开发者都不是搞计算机的。Deepin 使用 Tower 项目管理工具,给开发者创造一种宽松的环境。
- 我们公司一部分是 Geek,另一部分是按照软件公司的模式。由于 Linux 桌面盈利模式的问题,对有能力的开发者来说事实上是“得不偿失”的,还是要靠热爱支撑下去。
- 公司的员工分为生存型、投资型和个人实现型,要区分对待。
- 只有公而忘私,没有大公无私,雷锋回到军营还是有吃有喝,个人对生存的需求是必须满足的。作为开源项目的领导者,手下走过几百人是正常的,要有好的团队才能留住人。现在的社会现实,不是靠几个英雄撑起来的,还是要在商言商。
- 理想不是空口,而是社会上五年十年磨砺后的结果,一定要想好是不是真正喜欢做的。
希望社会上其他资源如何帮助?
- Thomas 曾经为王勇帮忙联系音乐人,另外校园学生有比较多的空余时间,如何利用?
- 很多开源英才不是出自计算机科班,是因为我们的教育没有培养开源的博大精神。中学本来有思想的、另类的,高考可能考不上名牌大学。但现在的开源体系让他们有机会展示成就。
- 我内心对科班的培养过程心存敬畏,因此回头又读了个科班硕士。Linux 在国内最初以论坛形式发展,但健康状况不好。红旗不是不想开放,而是思想和渠道停留在那个时代。
- 我们这里 90% 是计算机科班出身,团队同质化严重,这是个大问题。产品设计、QA(质量保证)需要其他领域的人提供一些新的视角。
- 我的英语课程倒数第一,但今天能与 Larry Wall 流畅地交流。课本上的东西都是过时的,要来我们这里先把书烧掉。
- 有一本书《教育工厂》(?) 值得一读,工业革命之后,资本家需要一批一批的螺丝钉,要听话。但这种螺丝钉不再适合互联网行业。
- 我认可科班课程,但现在的课程没有把为什么要学这件事情讲清楚。操作系统原理三四十年从未变过,现在的数据库基本上就是个完整的操作系统,这些理论基础是很有用的。计算机课程应该学得更有成就感,而不是输出几个菱形、计算斐波那契数列。不要过多看重编程语言,编程语言只是工具,否则 40 岁会失业,当年我跟王勇做 Haskell,后来都用不上。
- 应该跟学校合作,让学生在学校里更多了解现实和产业,知道外面的世界是什么样的。