分类 观点 下的文章

看看这两个你可以为你的家庭建造的开源的光伏支架设计。

你可能已经考虑过用太阳能为你的家供电。将太阳光直接转化为电能的太阳能光伏电池板的成本已大幅下降,因此在任何地方都具有经济意义。这就是为什么大公司投入大量太阳能,甚至电力公司也开始安装大型太阳能发电场的原因,因为它的成本低于过时的化石燃料。像大多数房主一样,你想省钱并节省电费,但你可能对前期费用有点畏缩。为了大致了解成本,一个 5 千瓦系统,以 3 美元/瓦的价格为普通家庭供电,成本约为 15,000 美元,而更大的家庭可能需要 10 千瓦才能满足所有电力购买,成本为 30,000 美元。如果你想要电池,成本加倍(你不需要电池,因为大多数太阳能电池阵列连接到电网,但如果电网瘫痪,你的太阳能电池阵列也会瘫痪,直到它重新开启)。支付你未来几十年所有的电费是一种投资,即使你存了很多钱。

有一些好消息。首先,美国和加拿大都对太阳能实行了 30% 的税收抵免。此项优惠将价格降至约 2 美元/瓦。其次,我们之前讨论 过你可以获得一本免费书籍 《捕捉阳光》,它会引导你完成如何设计自己的系统(你仍然需要一个合格的电工和检查来把它连接到电网)。如果你有一点手艺,你可以将剩余成本削减约 50%。这些成本主要用于材料,包括太阳能电池板、布线、电子设备和支架。令人惊讶的是,对于小型太阳能系统(比如你家的太阳能系统)来说,太阳能电池板的成本下降得如此之低,以至于支架(支撑太阳能电池板的机械结构)的成本可能比面板还高!

开源再次拯救

将开源开发范式应用于软件可以加快创新速度、改进产品并降低成本。开源硬件也是如此,甚至在光伏支架这个相对不为人知的领域也是如此。几乎所有的商业光伏支架都是由专有的奇特铝型材制成。它们会花很多钱。如果你有一些没有遮挡的后院,有一些开源的支架解决方案可以选择。

开源太阳能支架设计

第一个 DIY 太阳能支架设计符合以下标准:(1) 由当地可获得的可再生材料制成,(2) 25 年的使用寿命与太阳能保修相匹配,(3)能够由普通消费者制造,(4)能够符合加拿大结构建筑规范(如果你住在没有雪的地方,这有点矫枉过正,但是,嘿,你可能有其他极端天气需要应对,例如飓风),(5)低成本,(6)它是共享的,使用开源许可证。开源的木质固定倾斜地面安装双面光伏支架设计 在整个北美都适用。与商业专有支架相比,该支架系统可节省 49% 至 77%。然而,支架设计高度依赖于世界各地不同的木材成本。

在深入研究这个开源设计之前,请检查你当地的木材成本。

Non-tilting solar rack plans

如果你更喜欢冒险,你可能会考虑第二种允许改变倾斜角度的设计。第二项研究 的结果表明,具有最佳可变季节性倾斜角的支架系统具有最佳的终身能量产生,与固定倾斜系统相比,产生的能量多 5.2%(或者,如果最大倾斜角限制为 60°,能量多 4.8%)。固定和可变木制支架系统的电力成本相似,仅为专有商业金属货架的 29%。可变倾斜支架提供了最低成本的选择,即使包括适度的劳动力成本,也可能为 农业光伏 等应用提供特定优势(即,你可以在面板下面种菜,对于莴苣等耐阴作物来说,能惊人地增加产量)。此设计已通过 具有 CERN-OHL-S-2.0 许可证的 OSHWA 的认证。

Tilt-adjustable solar racks

所示的 2 个光伏模块架中的每一个大约有 1 千瓦。所以一所房子大约需要五个。这两篇论文都提供了完整的计算和分步建造说明。

正如拥有太阳能系统的任何人都会告诉你的那样,获得负电费是非常有益的。如果你的系统规模能满足你所有的负荷,并且住在该国的净计量地区,就会出现这种情况。请注意,电力公司不会向你付款;额度会一直延续到你在冬天使用它为止。

享受一点开源太阳能带来的乐趣!


via: https://opensource.com/article/22/12/open-source-solar-power-home

作者:Joshua Pearce 选题:lkxed 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

不想让文档成为事后的想法?或许你该尝试一下全新的写作方式。

很多工程师与手工艺者都对他们使用的工具有特别的要求。为了顺利的完成工作,你需要最好的工具和使用它们的技巧。软件开发中最好的工具在应用到其他的数字创作领域中也可以是很强大的。 文档即代码 Docs as Code 的方式就是很好的例子。“文档即代码”意味着使用与代码开发相同的工具和工作流来撰写文档。文档即代码的支持者认为,这样的方式可以在降低写作者的工作量的同时,也带来了更好的文档。

文本格式与源文件控制

从传统的写作平台切换到文档即代码方式时,最主要的调整是将写作内容保存在基于文本的标记格式中。这一转变使得基于纯文本的工具都适用于文档写作。无论你选择 DocBookMarkdown 或者其他的标记语言,从只使用一种工具到使用一种标准格式配合多种工具是一种巨大的转变。

找到支持你的工作流程的工具是非常重要的。很多开发者在文档即代码项目中使用他们的 代码编辑器。因为他们已经是这些工具的高阶用户,一切都很顺利。而找到适合团队里其他专业人员,比如技术撰稿、编辑、信息架构师和文档产品责任人的工具可能需要一番努力。这里有一些选项可供参考:

  • 各种 优秀的 Markdown 编辑器 之一
  • 附带良好的预览工具的代码编辑器可能更适合非程序员
  • 流行的 Git 托管服务的网页界面尤其适用于偶尔有需要的贡献者

一旦内容以标记语言的格式安全地保存,就可以使用 Git 这样的版本控制进行管理。Git 相比大多数文档平台具有更多的功能:

  • 清晰详细的文档版本历史:谁在什么时候改变了什么。如果你有良好的提交信息惯例,你甚至可以了解到为什么会有这样的变更。
  • 简明的并行修改过程。在 Git 中使用分支工作意味着任何人可以做出他们想要的任何改变,并在最后合并所做的变更。
  • 先进的协作与审查工具。所有的源代码管理平台都被设计成支持详细审查每一个变更,并根据需要进行讨论,使每个人都确信这个变更可以继续进行。
  • 自动质量检查,比如拼写检查和链接检查。这不仅节省了时间,而且可以发现可能遗漏的错误。

源代码管理有很多优点。但要记住,如果你准备入门源代码管理,它有一定的学习曲线。这是一些有助于撰写者入门的优秀的 学习资源文章。你也可以让具有好奇心的文档撰写者自行寻找对他们有用的学习材料,而不是请你的工程师来培训他们。(问我是怎么学会的? —— 当然是通过艰苦的方式!)

拉取请求和评审循环

所有的源代码管理平台都围绕 拉取请求 Pull Request 这一概念设计的,这有时也称为 合并请求Merge Request:有时候,某个人或某个团队先将一系列改变整合到一起,然后请求把这些修改拉到主项目中。不过从许多方面来说,在文档中一次处理多个变更比在代码中更容易。改变一篇文章中的某个地方,比更改代码并发现有其它几个地方依赖它,副作用更小。

最强大的协作工具是 diff,它可以通过一个易于理解的方式展示旧版本与新版本之间的差异。该工具有许多不同的版本,可以使比较视图更易于查看:双栏模式、行内模式,甚至是渲染过的 Markdown 模式。团队中的每一个成员都可以选择最适合他们的工具。举例而言,网页视图通常用于查看细微变更,而对于更大的变更,我习惯于使用 vimdiffMeld 在本地浏览。

评审意见可以被添加到整个修改中,也可以添加到拟议的变更的个别行中。一些项目限制了行的最大长度,即硬换行,或者一行一句,以使得向文本的特定的部分添加注释更加容易。可以添加进一步的修改与评论,直到审查过程结束,修改被接受。由于拉取请求在项目仓库以队列形式展示,这是一种很好的方式,可以展示目前正在进行的任务以及需要进行检查操作的任务。diff 工具使得评审人员更方便地添加他们的思考。尤其是你在与技术受众工作时,你可以通过他们日常使用的工具获得来自他们的评论。

持续集成与部署

以纯文本形式提供你的文档的源代码有很多益处,你可以轻易找到每一个需要修改的位置,你可以使用现有的诸如 wcgreptree 之类的工具,来处理潜在的大型文档集。当你将这些与源代码管理平台结合起来之后,你可能获得更多的可用工具,并且它们都是开源的。

另一个工作流程上的巨大提升是持续部署的能力。简单来说,这意味着,每当一个拉取请求被合并到主项目中,项目可以直接自动化部署到位。如果这个变更足够好,就可以放进项目中,它也足够好到可以在放到文档网站上帮助你的读者。典型情况下,持续部署是配置在一台单独的自动化服务器上的,比如 Jenkins 或者 Git 钩子。不论哪种方式,基于文本的标记语言与文档即代码平台(通常是静态网页生成器,比如 HugoSphinx)结合来生成文档网站,然后自动部署。

在部署之前,同样的自动化流程可以被用于对将要合并的拉取请求进行检查。在一个编程项目中,通过计算机自行进行代码检查、代码测试和其他的质量检查已经习以为常。通过类似 Vale 之类的工具可以对文本进行检查,文档项目也可以同样对待。你也可以添加其他的工具,比如添加一个链接检查器来确保文中所有的链接都是有效的。

用于文档流程的代码工具

被工程师们熟知并喜爱的工具都是非常好的工具,它们同时也可以用于其他类型的项目中。对于文档而言,它们提升了宝贵的效率,尤其是当你希望你的文档与你的团队同步推进的时候。上面讨论到的所有工具都是开源的,你可以亲自尝试,也可以为大型全球团队,亦或者介于两者之间的团队,部署它们。愿你的成文过程和编程过程一样顺畅。


via: https://opensource.com/article/22/10/docs-as-code

作者:Lorna Mitchell 选题:lkxed 译者:CanYellow 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

以下是开源项目 ToolJet 是如何在一年的时间里取得 13000 颗星标和 200 个贡献者的故事。

ToolJet 是一款开源的低代码框架,用于快速构建和部署内部工具。它的代码库完全由 JavaScript 和 TypeScript 组成。

2021 年 4 月,一名开发者独自开始了 ToolJet 的开发,并于 2021 年 6 月推出公测版本,一炮而红。此后,ToolJet 成立了基金会。目前,我们已经有一个 20 人的开发团队。

为什么选择开源

在开发 ToolJet 之前,我曾担任一些企业客户的顾问。这些客户中的许多都庞大到足以维护构建几十个内部工具。尽管来自销售人员、支持人员以及运营人员不断要求对内部工具添加更多功能和修复错误,但开发团队却很难有精力来开发内部工具。

我尝试使用过多个平台来构建和维护内部工具。这些工具大多非常昂贵,而且经常不符合要求。我们需要进行修改,而且大多数工具不支持内部托管。

作为一名 Ruby 开发者,我最初使用 ActiveAdmin 和 RailsAdmin 来构建内部工具。这两款工具都是极好的,只是将它们应用在使用多个数据源的任务上比较困难。于是我意识到市场上需要一种可以构建用户界面,并能够连接多个数据源的框架。我相信任何为开发者制作的工具都应当是开源的。开发者日常使用的大部分工具与框架都源自世界各地人们的公开协作。

第一次提交

制作像 ToolJet 这样的工具需要全身心的投入,通过出售我的一个业余项目,我获得了五六个月的空闲,于是我立即着手将在我脑海里酝酿了两年的想法付诸现实。

2021 年 4 月 1 日,我完成了 ToolJet 的第一次提交(使用 rails new 命令)。

稍等!我刚刚说 ToolJet 的代码是完全基于 JavaScript 的?请接着往下看。

构建完成并推销给投资者

4、5 月间,我一直坐在电脑屏幕前编写代码和向种子轮的投资者推销我的工具。

我的工作还包括创建拖放式应用程序构建器,撰写所有的文档以保证有在主流平台上设置 ToolJet 的文档,创建项目网站,制作发布时所需的海报以及博客文章等等。这一过程进展顺利,没有遇到大的挑战。当时,ToolJet 的前端使用的是 React ,而后端则用的是 Ruby on Rails 。

编程工作进行得很顺利,然而向投资者推广的工作进行得并不顺利。我向专注于初创时期投资的风投和天使投资人发送了大约 40 封电子邮件,都石沉大海。大部分邮件都被忽略了,不过也有一些公司向我说明了拒绝的原因,另外一些则给我回了电话。

大部分的电话内容都是一样的:我无法说服他们接受开源商业模式。

工具发布

6 月 7 日是发布日。我们首先在 ProductHunt(LCTT 译注:ProductHunt 是一个新品发布平台)上发布。六个小时后,只有 70 名用户注册。但是我们有成为当天第一名产品的趋势(最终在那一周的产品中排名第三)。这里是原始的 发布帖

下午 6 点左右,我又在 HackerNews 上发帖,一个小时内,这个帖子便升至榜首。大量的访问者注册并给我的版本库点亮星标,我对此很高兴。许多访问者和用户报告了软件和文档中的错误。距离在 HackNews 上发帖八个小时之后,超过 1000 名 GitHub 用户给 ToolJet 的 GitHub 版本库点亮了星标,并且有数百人注册了 ToolJet 云。上升趋势一直持续到三天后,ToolJet 版本库总计得到了 2400 个星标。

ToolJet repo stats on GitHub

获得资助

ToolJet 项目在 GitHub 上的吸引力足以被风投(VC)世界注意到。发布之后的日子被各种来电挤满了。我们也有其他的选择,但从没有认真考虑过这些它们。这些选择包括:

  • 引导性融资:在项目初期,难以获得付费用户,而我此前也没有足够的储蓄来支撑整个项目。
  • 作为业余项目:在开发小型项目上这是可以的,但我不认为这在 ToolJet 的开发上行得通,毕竟在 ToolJet 平台能够为客户所用之前,我们需要创建大量的集成和 UI 控件。作为一个业余项目,要实现这些可能需要花费数月甚至数年时间。

我知道如果将 ToolJet 作为一个业余项目来开发,我可能需要花几个月的时间才能达到我期望的程度。而我希望通过扩大团队加速项目的成熟。鉴于该项目的吸引力,引入风险投资(VC)的资助是显而易见的选择。

好消息是在 HackNews 上发布之后的两周内我们成功募集了 155 万美元的资金

在开源中积累很重要

发布后不久,我们发现许多人希望为 ToolJet 项目做贡献,但是他们几乎都是 JavaScript 开发者。我们也意识到像 ToolJet 这样的项目在未来会有成百上千的数据接口,只有基于插件的架构才行得通。我们于 2021 年 8 月决定从 Ruby 迁移到 TypeScript 上来。即使这花费了一个月的时间和巨大的努力,这仍然是我们在 ToolJet 项目上作出的最正确的决定。今天,我们有一个由我们的 插件开发套件 支持的可扩展的基于插件的架构。我们获得了来自超过 200 名开发者的贡献。关于这次迁移的文章参见 这篇博客另一篇博客

发布 v1.0 版本

自 8 月份以后,很多用户已经在生产环境中使用 ToolJet ,该平台并没有出现过任何稳定性或扩展性的问题。我们准备在发布 v1.0 版本之前完成开发人员平台的功能。开发人员平台允许任何 JavaScript 开发者构建和发布 ToolJet 插件。这样开发人员就可以为 ToolJet 开发数据接口。把集成测试的时间算上,创建一个 ToolJet 接口的时间也只需要30分钟。

创建持续成长的社区

ToolJet star history

我们没有在销售上投入资金,我们的大部分精力都放在了传播 ToolJet 的消息、撰写我们的经验教训以及维持开发社区的活跃上。我们有一个关注社区里问题的三人团队。

商业模式

如果没有 商业产品 来支付账单,ToolJet 就无法成为一项可持续的业务。我们构建了 ToolJet 的客户付费的企业版本。ToolJet 的免费的社区版本没有任何使用限制,企业版中的额外功能都只与大型团队有关。我们现在的客户已经有超大型公司。我们有足够的银行存款来打造更好的 ToolJet ,因此我们目前正聚焦于产品提升上。

接下来做什么

我们在开源社区的不断反馈和贡献的帮助下,我们可以经常性发布更好的 ToolJet 版本。很多主要的优化、大量的数据接口以及 UI 组件正在开发进程中。我们正以前所未有的速度朝着我们的最初目标前进,即成为一个可以连接到数百个数据源和构建最复杂的用户界面的开源框架。


via: https://opensource.com/article/22/10/tooljet-open-source-journey

作者:Navaneeth PK 选题:lkxed 译者:CanYellow 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

将文档写作加入到 DevOps 的生命周期中。

 title=

DevOps 正在挑战技术文档的规范,这在 IT 历史上是前所未有的。从自动化到提高交付速度,再到拆除瀑布式软件开发生命周期模型,这意味着业务和技术文档写作的理念需要做出巨大改变。

以下是 DevOps 对技术文档写作不同方面的影响。

技术写手的角色变化

技术写手必须适应 DevOps。好消息是,许多技术写手已经加入到开发团队中,并且拥有合作关系和不断增长的产品知识的技术写手很具优势。

但是如果一个技术写手习惯于独立工作,并依赖于领域专家的草稿作为文档的基础,那么就需要做一些调整。

进行一些投资,以确保文档和其他与项目有关的内容开发工作获得所需的工具、结构和支持。从改变 技术写手聘用方式 开始。以 DevOps 的速度 编写文档需要重新思考内容规划,并打破 DevOps 团队和支持项目的技术写手之间长期存在的隔阂。

DevOps 使开发团队摆脱了传统文档实践的束缚。首先,文档 完成的定义 必须改变。一些企业的文化使技术写手成为软件开发的被动参与者。DevOps 提出了新的要求:随着 DevOps 文化的转变,技术写手的角色也应发生变化。技术写手需要(且必须适应)DevOps 提供的透明度。他们必须融入 DevOps 团队。取决于组织如何塑造这个角色,将技术写手带入团队可能会带来技能上的挑战。

文档标准、方法和规格

虽然 DevOps 还没有影响到技术文档本身,但开源社区已经加强了对应用编程接口(API)文档的帮助,已经有不同规模的企业的 DevOps 团队正在使用这些文档。

用于记录 API 的开源规范和工具是个非常值得关注的领域。我想这是由于 谷歌文档季 的影响,它使开源软件项目能够获得专业的技术写作人才来解决他们最关键的文档项目。

开源 API 属于 DevOps 文档讨论的一部分。云原生应用集成需求的重要性正在上升。OpenAPI 规范(一个定义和记录 API 的开放标准)是在 DevOps 环境下 API 文档的良好资源。然而,该规范会导致文档的创建和更新过程变得很费时,这使其饱受批评。

曾经也有短暂尝试过创建 持续文档 Continuous Documentation ,并且还有一个来自 CA(现在的 Broadcom)的创建 DocOps 框架的运动。然而,DocOps 从来没有作为一个行业运动流行起来。

DevOps 文档标准的现状意味着 DevOps 团队(包括技术写手)需要在项目的最初阶段就开始创建文档。要做到这一点,你需要把文档作为一个敏捷故事和(同样重要的)管理期望,并且把它与年度绩效评估放在一起执行。

文档工具

文档的编写应该以一种所有团队成员都可以使用的格式或平台在线进行。MediaWiki、DokuWiki、TikiWiki 和其他 开源维基 为 DevOps 团队提供了一个编写和维护文档的中央仓库。

让团队选择他们的维基平台,就像让他们选择他们的其他持续集成/持续开发(CI/CD)工具链一样。开源维基强大之处在于其可扩展性。例如,DokuWiki 包括一系列的扩展,你可以通过安装这些扩展来创建一个符合你的 DevOps 团队的创作要求的平台。

如果你有足够的野心来加强你的团队的编写和协作能力,Nextcloud(一个开源的云协作套件)是一个让你的 DevOps 团队上网并给他们提供编写文档所需工具的选择。

DevOps 最佳实践

文档在 DevOps 转型中也发挥着作用。例如,你会想要记录组织从 DevOps 实现效率和流程增益的最佳实践,这些信息太重要了,不能靠着 DevOps 团中之间口耳相传。如果你所在的组织有多个 DevOps 团队,那么文档就是统一的力量,它可以促进最佳实践的标准化,并设置了衡量代码质量的基准指标。

一般情况下,开发人员承担了记录 DevOps 实践的工作。即使他们的组织有技术写手,他们也可能跨开发团队工作。因此,开发人员和系统管理员能够捕捉、记录和交流他们的最佳实践是很重要的。这里有一些朝正确的方向发展的提示:

  • 提前花时间为 DevOps 最佳实践创建标准模板。不要陷入复制在线模板的陷阱。采访利益相关者和团队来创建一个符合团队需求的模板。
  • 寻找一些创造性的信息收集的方法,例如记录团队会议和使用聊天系统日志来作为文档的基础。
  • 建立一个用于发布最佳实践的维基。使用维基可以跟踪编辑和更新。这样的平台可以帮助团队在最佳实践发生变化时进行更新和维护。

当在构建 CI/CD 工具链时记录依赖关系是非常明智的。尤其是当加入新的团队成员时,你会发现这些记录非常有用,另外当团队成员忘记一些事情时,这也是一种保险。

最后,自动化对 DevOps 利益相关者和从业者都很有吸引力。在自动化中断之前,一切都很有趣。拥有自动化运行手册、管理指南和其他内容的文档(并且是最新的)意味着无论何时发生故障,员工都可以让自动化重新工作。

最后一些想法

DevOps 对于技术文档来说是一个积极的因素。它将内容开发纳入 DevOps 生命周期,并打破组织文化中开发人员和技术作者之间的隔阂。在没有技术写手的情况下,团队就可以使用工具来加快文档创作的速度,以与 DevOps 的速度相匹配。

你的组织将如何把文档加入到 DevOps 生命周期?请在评论区分享你的经验。


via: https://opensource.com/article/21/3/devops-documentation

作者:Will Kelly 选题:lujun9972 译者:Veryzzj 校对:校对者ID

本文由 LCTT 原创编译,Linux中国 荣誉推出

林纳斯定律 Linus's Law 即“ 只要有足够多的眼睛关注,任何漏洞都无处隐藏 given enough eyeballs, all bugs are shallow ”。那么林纳斯定律是如何应用于开源软件安全的呢?

这篇文章讨论 Linux 对开源软件安全的影响。

开源软件的一个常被赞扬的优点是它的代码能够被任何人审查(安全专家通常称之为“代码审计”)。然而,如果你真的去问很多开源软件用户他们上一次检查代码是什么时候。你大概只能收获他们茫然的眼神或者是喃喃的低语。此外,对于一些相当大型的开源应用,有效地审查每一行代码也是困难的。

根据上述这些稍显不安的事实,我们不得不思考:如果没有人察看这些代码,它是开源还是闭源真的有关系吗?

你应该相信开源吗?

计算机爱好者倾向于作出认为开源软件比其他软件更加安全的传统假设。我们通常不会讨论这意味者什么:比较的基础是什么(比什么“更”安全?),或者上述结论是如何得到的。这是一个危险的陈述,因为它表明只要你将一些东西称之为“开源”,它就自动如魔法般地继承了更高的安全性。这不是开源,事实上,这正是开源安全非常反对的。

除非你已经亲自审计并理解了软件代码,否则就不应该假定一个应用程序是安全的。一但你做到了这一点,就可以给予它 终极信任 ultimate trust 终极信任 不是对计算机而言的,而是对你本人而言的,至少在这一应用程序被渗透攻击之前,你信任它是因为你选择了相信它是安全的。

使用者本人是唯一可以对软件代码给予终极信任的人,因此任何人想要获得这样的享受都必须亲自审查代码。相信其他人的话是不管用的。

在你已经亲自审计并理解了软件代码之前,你对一个应用程序给予的最大信任度是一个范围,可以是从 根本不信任相当信任 之间。然而我们并没有一个关于信任程度的标准对照表,这是一个你必须亲自做出的个人选择。如果你已经从非常信任的人那里听说了一款应用程序是安全的,那么你可能会更信任这个软件,而不是信任那些你没有得到信任建议的东西。

然而,因为无法审计专有(闭源)软件代码,你不可能给予它 终极信任

林纳斯定律

现实很骨感,并不是每个人都是程序员,同时也不是每个程序员都有时间检查数以万计的代码行。因此如果你没有亲自审查代码,你就只能选择(一定程度上)相信那些 亲自 审查了代码的人。

那么,有哪些人会审查代码呢?

林纳斯定律声称 只要有足够的眼睛关注,任何漏洞都无处隐藏,然而我们并不知道多少双眼睛是“足够”的。请不要低估这一数量,应用程序往往经过了远超你想象数量的人员审查。原始开发人员以及后续开发人员显然清楚他们自己写下的代码,不过开源软件往往都是团队成果,开源时间越长,阅读了代码的开发人员越多。新加入的开发人员也必须回顾项目代码的核心部分,因为他们必须学习基础代码以加入新的功能。

同时,为了使开源软件能够在 Linux 发行版上可用,负责开源软件打包分发的开发人员会加入多个项目。有时一个应用程序可能会在不熟悉项目代码的情况下打包,但是大多数时候,开源软件打包人员都是熟悉所打包的项目代码的。这不仅仅是因为他们不想在他们不信任的软件上签名,还由于他们可能不得不修改代码来使得程序能够正确编译。漏洞报告人员和漏洞修复人员一般也是熟悉代码库的,因为他们需要尝试解决小到运行异常,大到程序崩溃的问题。当然,一些漏洞报告人员不是通过亲自审查项目代码,而是通过关注明显未按预期工作的现象,无意中揭示了代码漏洞。系统管理员通常都是通晓用户依赖的重要应用软件的代码的。最后,还有一些安全研究人员,他们专门深入代码内部以揭露潜在的漏洞。

信任与透明

很多人先入为主的认为大型软件的审计是基本不可能的,因为它由数以万计的代码行组成。不要被软件运行所需的代码量欺骗了。我们不需要真的阅读数以万计的代码行。代码是高度结构化的,可被利用的代码漏洞仅仅只是其中的一行,不过它通常影响软件的全部功能。

当然,也有例外。有时仅仅一个系统调用或者链接一个有缺陷的库文件就可能引入一系列漏洞。幸运的是,多亏安全研究人员以及漏洞数据库所扮演的积极角色,这些错误相对而言是容易发现的。

一些人指着错误追踪系统,比如 通用漏洞披露 Common Vulnerabilities and Exposures (CVE)网站,并推断开源软件显而易见是不安全的。毕竟已经向公众公开了大量的安全风险,涉及许多开源项目。但是不要被数据欺骗了。只是因为我们看不到现闭源软件的漏洞,并不意味着闭源软件中不存在漏洞。事实上,已经有很多针对闭源软件的漏洞攻击提出了,闭源软件也是存在漏洞的。区别在于开发者(以及用户)可以查看开源软件的 所有的漏洞 从而降低漏洞的影响。这是扩大对开源软件信任的系统机制的一部分,却正是闭源软件软件所缺少的。

对于任何代码而言,可能永远没有“足够的眼睛”来发现漏洞,但是开发社区越壮大、越多样化,越有机会发现和修复代码中的缺陷。

信任与人

在开源社区中,参与同一项目的众多开发者已经发现“不安全”的漏洞,却保持沉默的的可能性是微乎其微的,因为人们很少同意以这样的方式合谋。我们已经看到了在应对 COVID-19 的过程中,人类的行为是如何不一致了,在这里也一样:

  • 我们都发现了漏洞(病毒)。
  • 我们知晓如何避免它传播(待在家里)。
  • 然而病毒还是在持续传播,因为总是有一个或者多个人偏离了消减疫情的计划。

开源软件中的漏洞也一样,如果有人发现了漏洞总会公之于众(当然,我们说的是“假如”能够发现)。

然而就专有软件而言,有很大可能参与项目的众多开发者即使注意到不安全的漏洞却仍然保持沉默,因为专有模式依赖于薪水。如果一个开发者将漏洞泄漏出来,他可能只是伤害了该专有软件的声誉,进而降低软件的销售额;或者,在更糟糕的情况下,他可能因此而丢了工作。开发人员拿着薪水秘密地研究软件,往往不会谈论其缺陷。如果你曾经是一名开发者,你可能曾经签署过 NDA (LCTT 译注: 保密协议 Non-Disclosure Agreement ),也被培训过商业秘密的重要性,等等不一而足。专有软件鼓励在面对严重的秘密缺陷时保持沉默,更多时候甚至是强制要求沉默。

信任与软件

不要信任未经你审计的软件。

如果你必须相信未经你审计的软件,那么选择相信已经面向那些更有可能将软件缺陷公之于众的开发者公开代码的软件。

开源软件并没有比专有软件继承更高的安全性,但是修复它的系统得到了更好的规划、实施和人员配置。


via: https://opensource.com/article/21/2/open-source-security

作者:Seth Kenlon 选题:lujun9972 译者:CanYellow 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

我把自己的社交网络写进 FOAF 文件,这就是变革之始。—— 互联网之父蒂姆·伯纳斯·李(2007)

FOAF 标准( 朋友的朋友 Friend of a Friend ),是一个可以追溯到本世纪初的网络标准,目前它基本上已经不再使用了,或者说被人们忘记了,亦或者说已经被取代了 [1] 。它暗示了,假如 Facebook 没有征服世界的话,FOAF 将会定义我们今天所用的社交网络。不过在开始探讨这一网络标准之前,我想先来谈一谈纽约地铁。

目前,纽约地铁的唯一管理机构是 大都会运输署 Metropolitan Transportation Agency (简称 MTA)。MTA 垄断了纽约市的地铁交通。在纽约乘地铁必须先从 MTA 购买车票,否则属于非法行为。也就是说,MTA 在地铁行业没有任何竞争对手。

不过,以前可不是这样。说起来可能有些让人吃惊,纽约市的地铁交通曾由两家企业相互竞争,共同运营。 跨区捷运公司 Inter-borough Rapid Transit Company (IRT)的势力范围是穿过曼哈顿的线路, 布鲁克林-曼哈顿运输股份有限公司 Brooklyn-Manhattan Transit Corporation (BMT)管理的则是布鲁克林区内的线路,其中也有部分线路延伸到了曼哈顿。1932 年,纽约市开通使用了自己的服务,称为独立地铁系统,与 IRT 和 BMT 展开竞争,所以当时纽约共有三家不同公司控制着市内地铁交通。

可能会有人觉得这样的地铁运营效率不高。事实上也确是如此。由于 IRT 和 BMT 投入使用的列车宽度不同,所以在不同的运营系统之间建造换乘站十分困难。此外,乘客换乘时还需向不同的运营商支付费用,这就意味着在换乘站至少要设置两个不同的检票区域。后来,纽约市于 1940 年接管了 IRT 和 BMT,将整个纽约市的地铁交通置于一家运营商的管理之下,不过由于此前分而治之而造成的效率低下问题时至今日依然存在:能在 BMT 的线路上(如 A、C、E 号线)运行的列车无法在 IRT 的线路上(如 1、2、3 号线)运行,因为 IRT 的线路隧道比较窄。因此,MTA 不得不同时管理这两种互不兼容的列车系统,由此带来的支出可能远比世界上其他单一隧道宽度的地铁系统要多得多。

IRT 和 BMT 之间的竞争所造成的历史遗留问题告诉我们,地铁系统本身就趋向于垄断经营。相比较于两家运营商相互竞争,只有一家运营商更能解决问题。乘客们虽然失去了选择的余地,但再也不用担心带了一张地铁卡却忘记了另一张的问题。

那么,地铁和社交网络又有什么关系呢?我在想,Facebook 是否和 MTA 一样都有自然垄断的属性呢?事实上,无论是自然垄断还是非自然垄断,Facebook 貌似确有垄断能力。当然它垄断的不是社交媒体本身(我在 Twitter 上面花的时间更多),而是垄断了与现实中认识的人之间的线上联系。Facebook 能够垄断所谓的“社交图谱”;如果我不用担心会失去与别人的联系方式,那我明天就会卸载 Facebook。我对 Facebook 对我身上的这种垄断权力感到非常气愤。不过,我却不会生 MTA 的气,即便从字面上和隐喻上来讲,纽约市地铁都是一堆焚烧着的、火舌乱窜的垃圾。说到底,我愤怒是因为我觉得不同于 MTA 的自然垄断,Facebook 的垄断属于非自然垄断。

我的意思是,如今 Facebook 之所以能拥有所有人的社交数据,因为它碰巧是第一个做大做强、确立巨头地位的社交平台,而不是因为其他社交平台难以或者无法与之竞争。不过,难道真是因为这样吗?许多事实告诉我们,原因并非如此。Facebook 仅仅是先入为主,还是它提供的服务真的比其他社交平台要好?如果你想联系老朋友,只有 Facebook 这一个平台的话,不会方便许多吗?在一个有几个 “Facebook” 相互竞争的情况下,如果你和你男朋友 Facebook 上面的感情状态都显示“交往中”,但是他始终没来得及更新他在 VisageBook 上的感情状态,那上面现在还显示着他和他大学前任的关系,那么这种情况意味着什么呢?人们信任的又是哪个社交网站呢?如果社交网站有很多,难道在填写信息上面不会很耗时间吗?

过去几年,由于中心化社交网络的缺陷暴露出来,许多人尝试构建去中心化的平台。基于开放标准,去中心化平台有望建立互通的社交网络生态(比如 Fediverse)。可惜的是,其中没有一个平台能够取代主流社交网络。一个比较明显的原因是 网络效应 network effects 的力量:既然每个人都在用 Facebook,那么任何想要放弃 Facebook 的人都将会付出巨大的代价。有人会说,这一点恰恰证明了社交网络属于自然垄断行业。但我想说,Facebook、Twitter 等平台是自己选择封闭起来的。此外,鉴于人们已经设想出社交网络的互通性,并且付诸实践,那么封闭的社交平台引发的网络效应就无法证明社交网络具有自然垄断属性。

因此,在我看来,真正的问题是:之所以 Facebook 等平台到现在仍是主流社交网络,仅仅是因为网络效应,还是说与只有一家运营商的地铁系统一样,单一的主流社交网络效率更高?

最后,这些问题让我想起了 FOAF。尽管人们似乎已经忘记了 FOAF 标准,但是早在 Facebook 出现之前,人们就尝试使用 FOAF 建立开放的、去中心化的社交网络。如果过去有哪个去中心化社交网络有机会早于 Facebook 占领如今它驻守的阵地,那只可能是 FOAF。考虑到世界上大部分人都有 Facebook 账号,而且了解 FOAF 的人相对较少,我们是否可以得到如下结论:同地铁一样,社交网络也有中心化和自然垄断的性质;亦或者,FOAF 项目说明,尽管去中心化社交网络可行,但由于其他原因,无法获得人们的广泛支持。

早期社交媒体的未来

FOAF 项目诞生于 2000 年,旨在建立一套表示个人身份以及人与人之间关系的通用标准。在今天看来,这一雄心勃勃的项目可能会让人感到惊讶,但是在上世纪末本世纪初,这样的想法再寻常不过了。当时 网络 Web (当时人们仍然这样称呼它)刚刚击败了 美国在线 America Online Prodigy) 等封闭系统。这让人很自然地想到,计算机领域的创新发展必须要保持开放、基于标准,而且这也正是网络的特点。

许多人认为,网络下一场重头戏会是 语义网 Semantic Web 。我有篇文章介绍了关于语义网概念与运行原理的设想,所以这里不再赘述。但是我会简单谈谈推动人们研究语义网技术的愿景,因为 FOAF 标准正是这一愿景在社交网络方面的应用。

一篇题为 《 谷歌如何击败亚马逊和易贝,朝着语义网进军 How Google beat Amazon and Ebay to the Semantic Web 》 的文章很好地描绘了语义网这一崇高理想。文章写于 2002 年,作者是 Paul Ford。这篇文章设想了 2002 年至 2009 年的情景:通过使用语义网,谷歌取代了亚马逊和易贝,成为电商平台主导者。文章指出,在未来,如果你想买东西,比如说一把二手的马丁吉他,可以在谷歌中输入 buy:martin guitar。根据你的邮编,谷歌会告诉你附近哪些人在卖马丁吉他。谷歌之所以可以获取卖家及其吉他的信息,是因为它可以读取资源描述框架标记语言(RDF),该语言是语义网的核心技术,用于描述资源之间的关系。人们可以将 RDF 内容嵌入网页,能实现很多用途,比如给要卖的东西打广告。Ford 预测,随着使用这种方式搜索和售卖商品的人数增加,亚马逊和易贝将失去它们在电商领域近乎垄断的地位。如果可以搜索全网,又有谁会执着于某个封闭的数据库呢?Ford 写道,即便是谷歌,最终也会失势。因为理论上,任何一个人都可以检索网络,查阅 RDF,提供类似于谷歌的搜索功能。起码,如果谷歌打算对语义网上的每笔交易按一定比例收取费用,以此盈利,那么以后随着相关竞争越来越激烈,谷歌的抽成比例很有可能会被迫降低。

Ford 所设想的未来是将 RDF 应用于电商领域,不过 RDF 更振奋人心的地方在于,它或许可以应用于各个领域。RDF 标准以及一系列相关标准,一旦得到广泛应用,被认为可以掀开基于数据库的软件服务的发展,如同 HTML 为文档出版带来新的发展契机一般。

RDF 以及其他语义网技术似乎准备立刻接管的另一个领域是社交网络。FOAF 项目最初的名字是“ RDF 网络环 RDF Web Ring ”,是语义网发展的产物,旨在实现语义网的设想。FOAF 自诞生之初就被人们看好,有人甚至认为,FOAF 必定会淘汰掉其他社交网站。2004 年《卫报》的一篇文章这样介绍该项目:

最初是 1996 年,SixDegrees 开始运营;接着是去年,出现了 Friendster;上周是 Orkut;下周 Flickr 也会登上舞台。这些网站不胜枚举,都是为了建立社交网络。如今,它们处在互联网发展的最前沿。但是,如果它们无法提供更实质性的好处,在 FOAF 标准得到广泛应用之后,它们就会很难存活下去。 [2]

文章继续指出,社交网络面临的最大问题就是社交网站数量过多。这就需要一种能够将所有这些网站连接起来的手段。可行方案就是 FOAF ,它终将变革整个社交网络。

根据该文章,FOAF 可将不同的社交网站紧密连接起来,实现途径有三个要点:

  • FOAF 将创建机器可读的社交数据格式,可为各个社交网站识别读取,避免让用户在不同的网站上重复输入信息。
  • FOAF 标准下, 联系人 Contacts (个人信息管理程序)可生成上述格式的文件,供用户在各社交网站使用。
  • FOAF 标准下,这种机器可读的文件可寄放在个人主页上,可为各社交网站读取。这样一来,用户只需将修改过的信息推到自己的主页,其他平台就会同步更新。

在今天可能难以想象,但在 2004 年,至少在熟悉技术的网民和技术专栏记者看来,当时社交网络并不算少,但是每个网络的用户群体都很小。考虑到这个问题,虽然对现在的我们来说很陌生,我们就会明白为什么需要建立单一标准是有意义的,这个标准可以使网络的激增不再是一个负担。

FOAF 规范

根据 FOAF 项目官网现有的介绍,FOAF 是“一种计算机语言,用于生成与人相关的各种条目的字典,条目以结构化数据的形式储存”。2000 年,FOAF 的创始人 Dan Brickley 和 Libby Miller 发表了一份关于该项目目标的文件,给出了不同的解释,强调了 FOAF 的最终目标:作为工具,FOAF 可让计算机像人类一样读取用户主页的个人信息 [3] 。FOAF 将会“帮助网络提供当前只有中心化平台才能提供的服务” [4] 。通过为个人以及人际关系定义一个标准词汇,FOAF 可以理解用户输入的内容,比如“找找今天推荐的医院医疗人员”,或者“找找曾与我合作撰写过文件的人最近发表的文章”。

由于 FOAF 是标准化的词汇表,所以该项目最重要的成果莫过于 FOAF 规范。FOAF 规范规定了 RDF 类 和 RDF 属性(这里我不再解释什么是 RDF,如果感兴趣可查阅 我关于语义网的文章)。RDF 的类由 FOAF 规范规定,表示要描述的对象,比如人(Person 类)和组织(Organization 类)。RDF 属性由 FOAF 规范规定,表示针对不同对象所做的逻辑声明。例如,一个人可以有一个名字(givenName 属性)、一个姓氏(familyName 属性),可能还有人格类型(myersBriggs 属性)以及与他人的距离或者位置信息(based_near 属性)。FOAF 规范的思想是,这些类和属性要足以表示人们在个人主页上显示的身份信息和朋友信息。(LCTT 译注:Myers–Briggs 即迈尔斯布里格斯类型指标,是一种人格类型理论模型。)

FOAF 规范给出了一份 FOAF 文档的范例。该实例的格式是 XML,不过也可以使用 JSON 等格式进行编写:

<foaf:Person rdf:about="#danbri" xmlns:foaf="http://xmlns.com/foaf/0.1/">
  <foaf:name>Dan Brickley</foaf:name>
  <foaf:homepage rdf:resource="http://danbri.org/" />
  <foaf:openid rdf:resource="http://danbri.org/" />
  <foaf:img rdf:resource="/images/me.jpg" />
</foaf:Person>

这份 FOAF 文件对一个人进行了描述,他的名字叫做 Dan Brickley(该规范的作者之一),他的主页在 http://danbri.org,他还有个叫做“open ID”的东西,还有一张图片在 /images/me.jpg —— 估计是 Brickley 的主页地址的相对链接。FOAF 的元素名称都会有 foaf: 前缀,表示它们是 FOAF 命名空间的一部分。相应地,RDF 的元素名称前面也都会有 rdf:

为了说明 FOAF 不限于 XML 格式,这里从维基百科摘取了一个相似的例子,格式为 JSON-LD [5]

{
  "@context": {
    "name": "http://xmlns.com/foaf/0.1/name",
    "homepage": {
      "@id": "http://xmlns.com/foaf/0.1/workplaceHomepage",
      "@type": "@id"
    },
    "Person": "http://xmlns.com/foaf/0.1/Person"
  },
  "@id": "https://me.example.com",
  "@type": "Person",
  "name": "John Smith",
  "homepage": "https://www.example.com/"
}

上面这份 FOAF 文件也描述了一个人,他的名字叫 John Smith,他的主页在 www.example.com

理解 FOAF 原理的最好方法可能就是体验一下 FOAF-a-matic,一个在线生成 FOAF 文档的工具。你可以在工具页面的表单里输入自己的相关信息,创建表示自己的 FOAF 文档(XML 格式)。FOAF-a-matic 说明了 FOAF 是如何避免在注册不同社交网站账号时重复输入社交信息的麻烦:如果每个社交网站都可以读取 FOAF,你只需要在没有注册过帐号的网站上引用你在 FOAF-a-matic 生成的 FOAF 文档,就可以注册一个新帐号了。

下面这个实例是我用 FOAF-a-matic 生成的稍微复杂一些的例子,表示我自己:

<rdf:RDF
      xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
      xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
      xmlns:foaf="http://xmlns.com/foaf/0.1/"
      xmlns:admin="http://webns.net/mvcb/">
  <foaf:PersonalProfileDocument rdf:about="">
    <foaf:maker rdf:resource="#me"/>
    <foaf:primaryTopic rdf:resource="#me"/>
    <admin:generatorAgent rdf:resource="http://www.ldodds.com/foaf/foaf-a-matic"/>
    <admin:errorReportsTo rdf:resource="mailto:[email protected]"/>
  </foaf:PersonalProfileDocument>
  <foaf:Person rdf:ID="me">
    <foaf:name>Sinclair Target</foaf:name>
    <foaf:givenname>Sinclair</foaf:givenname>
    <foaf:family_name>Target</foaf:family_name>
    <foaf:mbox rdf:resource="mailto:[email protected]"/>
    <foaf:homepage rdf:resource="sinclairtarget.com"/>
    <foaf:knows>
      <foaf:Person>
        <foaf:name>John Smith</foaf:name>
        <foaf:mbox rdf:resource="mailto:[email protected]"/>
        <rdfs:seeAlso rdf:resource="www.example.com/foaf.rdf"/>
      </foaf:Person>
    </foaf:knows>
  </foaf:Person>
</rdf:RDF>

本例中,主要信息之前有很多其他内容,用于设置文档使用的各种 XML 命名空间。其中就有文档生成工具的信息,这样用户就能明白出了问题要向谁进行反馈。foaf:Person 元素给出了我的名字、电子邮箱和主页。其中嵌套了 foaf:knows 元素,说明我有个叫 John Smith 的朋友。

该例还体现了 FOAF 文档的另外一个重要功能:相互关联。还记得之前 John Smith 的例子吗?他的主页在 www.example.com。在我的这个例子中,我将 John Smith 列在了 foaf:person 元素里,上一级元素是 foaf:knows,表示我认识的人。此外,我还加入了 rdfs:seeAlso 元素,放了 John Smith 主页的 FOAF 文档链接。由于加入了这一链接,程序在读取我的 FOAF 文档时,就能根据该链接读取他的 FOAF 文档,查找到更多关于 John Smith 的信息。在之前 John Smith 的 FOAF 文档里,John 并没有提供任何有关朋友的信息(包括我在内),这意味着程序无法确定我们两人之间的朋友关系。但如果他加入了朋友信息,程序在读取我的文档之后,不仅会发现我,也会发现 John、他的朋友、他的朋友的朋友,以此类推,直到程序穷尽我和 John 各自的社交图谱。

对于使用过 Facebook 的人来说这似乎很熟悉,也就是说,这个功能对你来说也应该很熟悉。FOAF 没有 foaf:wall 属性和 foaf:poke 属性,无法完美复制 Facebook 的功能。很明显,FOAF 也没有漂亮的蓝色界面,无法为用户提供可视化的 FOAF 社交网络,它只是一个词汇表。不过,Facebook 的核心功能(我认为这正是 Facebook 垄断能力的关键)在这里是以分布式的方式提供的。在 FOAF 标准下,好友可以将 FOAF 文档上传至个人主页,数字化展示他们真实的社交图谱,用户无需将个人数据的控制权交给 Facebook 这样一个中心化的数据库。要知道,由于对用户个人数据管理不当,扎克伯格大多数时间都在国会委员会前在向公众道歉。

暂时搁置的 FOAF

浏览 FOAF 项目主页,你会发现在页面的右上角,有一张喜剧动画《 飞出个未来 Futurama 》主角弗莱躺在休眠舱内的图片。这张图片是《飞出个未来》试播剧集的剧照,讲的是弗莱在 1999 年不小心跌进了低温休眠舱,直到 2999 年才再次苏醒过来的故事。我曾和 Brickley 在 Twitter 上简短地聊了一下,他告诉我,挂这张图片是为了告诉人们,未来 FOAF 项目目前“处于停滞状态”,尽管他希望将来有机会恢复这个项目,继续探索 21 世纪初关于网络运作方式的设想。

FOAF 从未像《卫报》期望的那般彻底改变社交网络。一些社交网站选择支持 FOAF 标准,比如 LiveJournal 和 MyOpera [6] 。FOAF 甚至还在 2004 年 霍华德·迪恩 Howard Dean 竞选总统时发挥了一定作用:一群博主和程序员合力搭建起了一个将网站连接起来的网络,称其为“ 迪恩空间 DeanSpace ”,帮助迪恩竞选,并在网站上使用 FOAF 记录迪恩的支持者和帮助迪恩竞选的志愿者 [7] 。不过,今天人们了解到 FOAF 主要还是因为它是 RDF 应用最为广泛的词汇表之一,而 RDF 正是现代网络的一个重要标准。如果在今天还能用到 FOAF 的话,可能就是谷歌“ 知识面板 knowledge panels ”所用技术的原型。知识面板是在用谷歌搜索时,出现在搜索结果右侧的一小块内容,会提供搜索关键词的基本信息。谷歌为推行其知识面板,使用了语义网项目的“后继者” schema.org 项目发布的词汇表 [8] schema.org 用来描述人物的词汇表似乎有着 FOAF 的影子,两者的目的大多也是相同的。

那么,为什么 FOAF 还是失败了呢?为什么人们都在用 Facebook 呢?且不提 FOAF 只是一个简单的标准,没有 Facebook 那么丰富的功能,如果 FOAF 发展势头保持下去,很有可能就会出现相关软件和应用,带来像 Facebook 那样的体验。问题是,在 Facebook 还未发展到能与之分庭抗礼之时,FOAF 这股分布式社交网络的新生力量为什么没能得到广泛应用呢?

恐怕这个问题可能没有唯一的答案,不过非要我说的话,我觉得最关键的一点是,只有在每个人都有个人网站的情况下,FOAF 才有意义。在上世纪末本世纪初,人们理所当然地觉得网络最终会出现这种情况,因为就我所知,互联网的早期用户多是高产的博客写手、参政的技术专家,他们都希望能有个自己的平台。但是,现实情况却是,普通用户并不愿意学习怎么搭建和运营网站。FOAF 允许你掌控自己的社交信息并将其推送到各类社交网络上,省去了到处注册账号的麻烦。如果你已经有了储存社交信息的个人网站,那么这个想法应该很诱人。但实际上,相比较于买域名、折腾 XML 文档,大多数人觉得填写信息、注册 Facebook 账号来得更容易些。

那么,这与我最初的问题(Facebook 是否属于自然垄断)有什么相关呢?我不得不承认,FOAF 的案例说明,社交网络 的确 拥有自然垄断属性。

其实,关于用户不愿管理自己的数据这一问题,本身并没有那么重要,因为通过让普通用户在熟悉技术的用户所设置的节点上储存个人信息,Mastodon) 等现代分布式社交网络已经解决了这个问题。这也表明,人们多么不愿意折腾复杂的东西。对去中心化社交网络来说,这无疑是个坏消息,因为相较于中心化网络,去中心化网络更为复杂,用户对此再清楚不过了。

对于 FOAF:如果我要写一个能读取个人网站上 FOAF 数据的程序,假设 Sally 的 FOAF 文档提到了 John Smith,说他的主页是 example.com;Sue 的 FOAF 文档也提到了 John Smith,说他的主页是 example.net。在这种情况下,我应该怎么办呢?到底是只有一个 John Smith 而他正好有两个主页呢,还是这两个 John Smith 是不同的人呢?如果两个 FOAF 文档中 John Smith 的邮箱都是 [email protected],又该怎么办呢?这种身份问题是 FOAF 的软肋。在一封 2003 年的邮件里,Brickley 写道,由于不存在而且可能也不应该存在一个“全球性的身份识别系统”,FOAF 采取的方法只能是“多元的” [9] 。FOAF 用户的邮件地址和主页地址等部分属性具有特殊性,因为邮件地址和主页地址都是独一无二的。因此,这些内容不可能相同的属性可以将人们的多个 FOAF 文档合并起来(用 Libby Miller 的话来说,“挤”在一起)。不过这些特殊属性不存在所谓优先级的说法,所以前面 John Smith 的问题还是不好解决。换句话说,是该相信主页,判定他们不是同一个人呢?还是要相信邮件地址,判定他们是同一个人呢?我真的能够在不干扰到用户的前提下,写出一个程序,解决这类问题吗?

Facebook 拥有单一的数据库,不用顾虑政治性问题,有条件创建“全球性的身份识别系统”,给每个人发行独一无二的身份 ID,于是问题就迎刃而解了。

如果人们真的在乎对自己数据的持有权和掌控权,单是因为复杂难解应该不足以导致分布式社交网络的失败。但是 FOAF 的失败表明,人们从未重视过对自己数据的掌控权。正如一位博主所说,“所谓‘用户想要拥有自己的数据’只不过是一个想法,和实际应用没有关系” [10] 。如果用户对控制的重视程度不足以承受额外的复杂性,如果中心化系统比去中心化系统更为简单易用,如果中心化系统有发展为封闭系统的趋向,借此取得成功,从而享受网络效应带来的巨大效益,那么社交网络确实属于自然垄断。

即便如此,我认为地铁系统的案例和社交网络的案例仍存在不同之处。我可以欣然接受 MTA 对地铁交通的垄断,因为我希望地铁系统本身就应该是长期垄断行业。如果纽约地铁只有一家运营商,那么它只能是政府,至少在名义上,政府比没有竞争对手的私企更加负责。但是我却不希望社交网络属于自然垄断。地铁建好了基本上就是一成不变的,但数字世界却在不断演变发展。在今天,分布式社交网络也许比中心化网络更加复杂,就好比带两张地铁卡总是比只带一张要麻烦的多。不过,在未来,互联网会发生根本性变革,那时分布式技术将会更易于使用。

如果未来果真如此,FOAF 可能会作为建立分布式社交网络的第一次尝试为人们记住。在企业大型数据库所驱动的中心化网络时代结束之后,分布式网络将会得到人们的长期青睐。

如果你喜欢这篇文章,欢迎关注推特 @TwoBitHistory,也可通过 RSS 馈送 订阅,获取更多最新文章。


  1. 请注意,这里我没有用“消亡”一词。 ↩︎
  2. Jack Schofield, “Let’s be Friendsters,” The Guardian, February 19, 2004, accessed January 5, 2020, https://www.theguardian.com/technology/2004/feb/19/newmedia.media. ↩︎
  3. Dan Brickley and Libby Miller, “Introducing FOAF,” FOAF Project, 2008, accessed January 5, 2020, https://web.archive.org/web/20140331104046/http://www.foaf-project.org/original-intro. ↩︎
  4. 同上。 ↩︎
  5. Wikipedia contributors, “JSON-LD,” Wikipedia: The Free Encyclopedia, December 13, 2019, accessed January 5, 2020, https://en.wikipedia.org/wiki/JSON-LD. ↩︎
  6. “Data Sources,” FOAF Project Wiki, December 11 2009, accessed January 5, 2020, https://web.archive.org/web/20100226072731/http://wiki.foaf-project.org/w/DataSources. ↩︎
  7. Aldon Hynes, “What is Dean Space?”, Extreme Democracy, accessed January 5, 2020, http://www.extremedemocracy.com/chapters/Chapter18-Hynes.pdf. ↩︎
  8. “Understand how structured data works,” Google Developer Portal, accessed January 5, 2020, https://developers.google.com/search/docs/guides/intro-structured-data. ↩︎
  9. tef, “Why your distributed network will not work,” Progamming is Terrible, January 2, 2013, https://programmingisterrible.com/post/39438834308/distributed-social-network. ↩︎
  10. Dan Brickley, “Identifying things in FOAF,” rdfweb-dev Mailing List, July 10, 2003, accessed on January 5, 2020, http://lists.foaf-project.org/pipermail/foaf-dev/2003-July/005463.html. ↩︎

via: https://twobithistory.org/2020/01/05/foaf.html

作者:Two-Bit History 选题:lujun9972 译者:aREversez 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出