前沿
前沿
LJ索引,2006年7月
1. 1080p HDTV 所需的最低带宽(Mbps):30
2. 通过 56Kbps 拨号下载标准 7.8GB DVD 电影文件所需天数:13
3. 通过 160 公里链路发送的每秒太比特记录数:2.56
4. 每秒等效 DVD 数量:60
5. 旧金山市长 Gavin Newsome 希望免费 Wi-Fi 覆盖的百分比:100
6. 表示对播客感兴趣的在线消费者百分比:25
7. 北美定期下载和收听播客的在线家庭百分比:1
8. 在微软开源软件实验室运行的 UNIX 版本:15
9. 在微软开源软件实验室运行的 Linux 版本:50
10. 2005 年在北美销售的基于 PC 的销售点 (POS) 系统(数十亿美元):6
11. 2005 年 Linux 在北美 POS 系统销售额中所占的百分比:9
12. 2004 年 Linux 在北美 POS 系统销售额中所占的百分比:5
13. 2005 年 Linux 在中国的销售额(百万美元):11.8
14. 2004-2005 年 Linux 在中国的增长百分比:27.1
15. 未来四年 Linux 在中国的销售额预计复合年增长率:34
16. 预计未来四年末 Linux 在中国的销售额(百万美元):51.1
17. 到 2008 年,开源将在所有基础设施市场与闭源产品竞争的概率百分比:80
18. 75% 的主流 IT 组织将制定正式的开源采购和管理策略的概率百分比:80
19. 主流 IT 组织将在 80% 的基于基础设施的软件投资中考虑开源软件的概率百分比:70
20. 开源将被纳入全球 2000 强企业中 75% 的关键任务软件组合的概率百分比:90
1:Wayne Caswell
2–4:Gizmag
5:New Media Musings
6, 7:Forrester Research
8, 9:Microsoft Open Source Software Lab
10–12:LinuxDevices.com
11–16:Silicon.com,来源:International Data Corp. (IDC)
17–20:Gartner;
他们如是说
不用担心别人窃取创意。如果是原创,你必须强迫他们接受。
—Howard Aiken,来源:Marc Hedlund,radar.oreilly.com/archives/2006/03/entrepreneurial_proverbs.html
我过去的众多座右铭之一是“只向最优秀的人学习”。当你使用别人的想法时,这是最高的敬意。但重要的是要说明你从谁那里学习,因为他们是最棒的,对吗?
—Dave Winer,www.scripting.com/2006/03/31.html#When:7:12:08AM
这样想:如果管道输送到你家的水带有 DRM,并且只允许你用来淋浴,你如何洗衣服?如果你只被允许制作冰块,你如何制作冰茶?如果你每次想喝一杯水都必须支付 0.99 美元?
如果一个文明要继续迈向伟大,思想和希望需要像水一样流动。阻碍这种流动将阻碍增长。幸运的是,像溶剂一样,开源文化将继续扩展,将磨损这些障碍,以恢复社会资本、思想和希望的自然流动。那些首先认识到这一点的人将会崛起,并且迅速崛起。
—Chris Messina,factoryjoe.com/blog/2006/03/18/because-of-open-source
这很简单。互联网已经赢了。为什么要谈判投降条款?
—Bob Frankston,www.frankston.com/?name=GettingConnected
GhandiCon 4 的迹象
“起初他们无视你,然后他们嘲笑你,然后他们与你战斗,最后你赢了。”—Mahatma Gandhi
多年来,Linux 和开源在微软一直是“威胁”的代名词。尽管这种状态可能没有改变,但该公司一直在逐渐朝着更接受的方向发展,以对待包括其自身客户在内的市场竞争对手。
例如,我们在身份元系统中看到了接受,这是我 2005 年 10 月在 Linux Journal 专栏中的一个主题,以及该公司对博客的拥抱——这是一种在微软(或任何供应商)平台之外发展起来的开放标准和实践的产物。
但是,随着微软的开源软件实验室于 2005 年 8 月启动,接受度被提升到纯粹的事实层面之上。它成为一项政策。然后在 2006 年 4 月,微软通过一个名为 Port 25 的新网站开放了该实验室本身。该网站以用于出站电子邮件的路由器端口命名,是开放的、交互式的,旨在促进与使用开源软件的微软客户进行有益的沟通。
尽管这几乎不意味着微软很快会开发开源软件(尤其是针对 Linux),但它可能有助于缓解客户需要生产力而不仅仅是共存的异构环境中的紧张关系。
我向 Technorati 的创始人兼首席执行官 David Sifry(该公司在 Linux 上运行)询问了对此的看法。他说:“很高兴看到微软认识到开源软件的影响和重要性,我对其最近为理解和与世界各地庞大的非专有软件开发者社区合作所做的努力感到鼓舞。最终,这将对微软客户有利。”
www.forbes.com/home/enterprisetech/2006/03/22/ballmer-microsoft-linux-cz_df_0322microsoft.html
diff -u:内核开发的新变化
Paul Mundt 提交了补丁,以从内核中移除 RelayFS,并将其所有功能迁移到一个通用的 API 中,该 API 可以被任何文件系统使用。因此,最初作为一个高度专业的工具——一个仅用于用户空间和内核之间高速数据传输的文件系统——现在已经被概括为一个具有广泛适用性的服务。由于 RelayFS 已经在官方内核中存在一段时间,现在将其移除已经引发了一些争议。但是,显然,Andrew Morton 向 RelayFS 开发人员承诺,只要没有内核代码依赖于 RelayFS,他们就可以继续进行这些大规模的、全面的开发。用户应用程序不应该在这个不稳定的时期依赖 RelayFS。
Intel 宣布了一个新的开源项目,以支持其 PRO/Wireless 3945ABG Network Connection mini-PCI express adapter (IPW3945)。它不是完全开源的。有一个单独的纯二进制部分,其中包含这些适配器发货的所有国家/地区的法规执行逻辑。在公告中,James Ketrenos 表示,相对于之前的项目,英特尔改进了其许可。该项目的二进制部分使用与纯二进制固件相同的许可证,James 说它比以前的许可证更容易理解,并且对重新分发更宽松。正如人们可能预料到的那样,关于法规执行和二进制分发的整个问题是有争议的。二进制守护进程必须以 root 身份运行,这使得任何潜在的错误都成为一个重大的安全问题。此外,还有一个问题是 FCC 法规是否真的要求纯二进制分发,或者仅仅像 Alan Cox 所说的那样,“发射设备必须是合理防篡改的”。无论任何争议(肯定会持续存在),英特尔至少可以因释放其已释放的代码部分以及为改进其许可证所做的努力而受到赞誉。
Bernhard Rosenkraenzer 将 cdrtools 项目 分叉到他自己的 dvdrecord 项目 中,并发布了 0.3.1 版本,其中包含各种增强功能,例如支持 2.6 内核,支持使用纯自由软件写入 DVD-R 和 DVD-RW 光盘以及清理 make 系统。显然,已经发生了大规模的口水战,促使了这次分叉,并且一些内核人员表示,Bernhard 的工作代表了最近几天驱动程序方面的唯一进展。对话已转向他的 dvdrecord 是否将支持其他功能,例如 DVD RAM、DVD+R、DVD+RW 和 DVD+DL。目前尚不清楚该项目的长期方向,因为分叉总是存在争议,但至少目前似乎没有立即出现 Bernhard 不合理地分叉该项目的强烈抗议。然而,现在做出预测还为时过早。
Miklos Szeredi 创建了 mountlo 实用程序,这是一种支持用户空间环回挂载的工具。到目前为止,存储在磁盘上单个文件中的文件系统映像只能通过内核自身的环回支持进行挂载。Miklos 的实用程序依赖于 FUSE(用户空间文件系统)将整个功能移入用户空间并移出内核。Miklos 认为它更像是一个个人项目,而不是其他任何东西——一个玩 FUSE 并看看他可以创建哪些有用工具的机会。
一直保持警惕的 Christoph Hellwig 指出,gdth 驱动程序 似乎是 scsi_request 接口 的唯一用户,该接口预计将在 Linux 2.6.17 中消失。gdth 维护者尚未回复补丁提交,除非有人站出来确保 gdth 在接口更改中幸存下来,否则它将在 2.6.17 中被标记为“BROKEN”。Achim Leubner 已站出来进行一些测试,但这使得驱动程序维护的问题悬而未决。通常,在 Linux 中,无人维护的代码很快就会被弃用。
Greg Kroah-Hartman 已开始记录内核中 ABI(应用程序二进制接口)级别的稳定性。当二进制接口更改时,链接到该接口的用户空间二进制文件会中断。而且,由于给定的接口可能有无数个应用程序依赖于它,因此出于这个原因更改内核 ABI 被认为是几乎不可接受的。不幸的是,ABI 更改是生活中的事实。它们确实会改变,并且一直在改变,而正如 Greg 所看到的那样,问题是如何在用户空间的需求之间取得平衡。Greg 的想法是提供足够的关于给定接口未来的指示,以便应用程序开发人员有时间在更改发生之前重写他们的代码。正如人们可能预料到的那样,这是一个极具争议的问题。许多顶级内核人员认为 ABI 是神圣不可侵犯的,绝不应该被更改。但是,尽管 Linus Torvalds 对 Greg 努力的具体细节提出了批评,但他似乎普遍同意 ABI 更改是不可避免的,并且内核应该尽其所能减轻应用程序开发人员的负担。
Tabblo:Linux 在工作中的图片
如果您希望对您的数码照片做更多的事情,而不仅仅是通常的在线画廊,Tabblo 有办法做到这一点。除了您基本的 GIMP(或者,对于不太免费的 Photoshop)工具(裁剪、缩放、添加文本等)之外,Tabblo 还允许您布局、注释和共享照片集的“tabblos”(“tableaus”的双关语),或者通过离线服务以各种打印形式输出它们——所有这些都在浏览器内部完成。
正如 Tabblo 创始人兼首席执行官 Antonio Rodriguez 所说,“如果你有一个故事要用图片讲述,我们有办法让你在线和离线讲述它。”他还说,如果没有 Linux,Tabblo 自己的故事是不可能实现的。为了了解这个故事,我们进行了一次简短的采访
LJ:为什么选择这个行业,以及为什么是现在?
AR:这是市场长期以来一直需要的,但条件不成熟。Web 浏览器并非旨在进行严肃的多媒体处理,直到最近,在服务器上执行此操作还是不可能的——至少在经济上对任何试图以此建立业务的人来说是不可行的。例如,如果您想大规模地进行服务器端图像编辑,那么所涉及的软件和硬件成本简直是令人望而却步的。如果您想要一个包含元数据导航和无限撤消等功能的丰富数据库,那么批量购买 Oracle 许可证的成本可能会让您彻底无法通过免费提供任何有意义的功能来吸引客户。最重要的是,如果您想存储大量人们的照片,那么 NetApp 或 EMC 是唯一的选择——其经济性仅对投资银行和 NASA 有意义。我可以毫不怀疑地说,如果没有我们修改后的 LAMP 堆栈及其相关的开发实践,我们绝对 不可能 免费向用户提供启动时给出的应用程序级别。我对此特别敏感,因为过去有许多照片网站实际上试图赚钱,但最终因不断上涨的资本支出和对创收产品可能普及的错误假设而失败。
LJ:您的技术栈是什么?
AR:对于硬件,我们使用定制的 whitebox AMD64 盒子,每美元成本提供充足的性能,运行 Debian AMD64(这大大降低了我们的系统管理成本)。我们运行我们自己的集群文件系统,该文件系统主要构建在 Apache 2.0 堆栈之上(作为模块),并获得商业存储解决方案无法比拟的吞吐量,这主要是因为该软件是专门为我们的工作负载编写的。图像服务器还利用 Apache 运行时以及 ImageMagick。我们的数据库是 MySQL5,它非常适合以非常时髦的配置进行设置,让您可以根据自己的需要优化写入、读取或复制。最后,我们的 Web 应用程序是用 Python 编写的,Python 既可以快速开发,又可以作为动态类型语言非常简洁。
LJ:您计划如何发展这项服务?
AR:首先,我们将关注组合、布局和效果。接下来是打印和分发。我们还计划通过 metaweblog API 将所有内容发布到博客。
Tabblo 还充分利用了其他 Web 服务中“可混合”的内容,通过开放的 API。当 Antonio 在 2006 年 2 月的 O'Reilly eTech 大会上向我展示 Tabblo 的 beta 服务时,他通过从我在 Flickr 上的收藏中复制了 6,000 多张照片来填充我自己的 Tabblo 图库。他这样做也是为了展示 Flickr 作为网络公民的良好行为。Flickr 没有锁定客户数据,而是完全开放,允许其他服务上的用户访问和使用照片,包括各种照片元数据以及标签。他告诉我,Tabblo 也旨在对所谓的“开放市场”承担同样的责任。
因此,基于 Linux 的基础设施的开放性扩展到支持整个市场。
RubyGarden
访问 www.rubygarden.org 以满足您所有的 Ruby 需求,包括指向其他所有重要的 Ruby 网站的链接,例如 Pragmatic Programmers 和 RubyForge,以及指向 Ruby Webloggers 的链接。
RubyGarden 在 www.rubygarden.org/ruby?RubyUserGroups 提供了全球 Ruby 用户组的详尽列表。
RubyGarden 还推荐了其他 Ruby 用户组感兴趣的网站,包括 ruby.meetup.com,您可以在那里找到您附近的聚会小组,以及 www.rubyholic.com,Ruby 用户组可以在那里注册并发布会议信息。
您也可以加入 Google Ruby Brigade Group,网址为 groups.google.com/group/Ruby-Brigades 或发送电子邮件至 Ruby-Brigades-subscribe@googlegroups.com。