分类 观点 下的文章

了解如何使用 TODO Group 的成熟实践,使您的组织的开源软件目标与您的业务目标保持一致。

大多数使用开源的公司都了解其商业价值,但他们可能缺乏战略性地实施开源计划和获得全部回报的工具。根据 The New Stack 最近的一项调查,“开源计划的三大好处是 1)提高了对开源的认识,2)提高了开发周期的速度和灵活性,以及 3)更好的许可证合规性。”

运作一个开源计划办公室涉及到创建策略来帮助你定义和实施你的方法,并衡量你的进度。由 Linux 基金会与 TODO Group 合作开发的企业开源指南基于多年的经验和实践提供了专业开源知识。

最新的指南中,设置开源战略详细介绍了制定战略和确保成功之路的基本步骤。根据该指南,“你的开源战略将管理、参与和创建开源软件的计划与计划所服务的业务目标联系起来。这可以开辟许多机会并促进创新。”该指南涵盖以下主题:

  1. 为什么制定战略?
  2. 你的战略文件
  3. 战略方法
  4. 关键考虑因素
  5. 其他组成
  6. 确定投资回报率
  7. 投资目标

这里关键的第一步是创建和将你的开源策略形成文字,该策略将“帮助你最大限度地提高组织从开源中获得的利益。”同时,你详细的策略可以帮助你避免因错误而导致的困难,例如:选择错误的许可证或不正确地维护代码。根据指南,该文件还可以:

  • 让领导者感到兴奋并参与
  • 帮助在公司内获得支持
  • 促进分散的多部门组织的决策
  • 帮助建立一个健康的社区
  • 解释贵公司的开源方式和对其使用的支持
  • 明确贵公司在社区驱动的外部研发中投资的地方,以及贵公司将重点放在增值差异化的地方

Salesforce 的软件架构师兼本指南的撰稿人 Ian Varley 说:“在 Salesforce 内,我们有内部文件,我们将这些围绕开源战略指导和鼓励的文件分发给我们的工程团队。其中鼓励创建和使用开源,这让他们毫不含糊地知道公司的战略领导者完全支持它。此外,如果有某些我们不希望工程师使用的许可证或有其他开源指南,我们的内部文档需要明确。”

开源计划有助于促进企业文化,使企业更高效,并且根据指南,强有力的战略文档可以“帮助你的团队了解开源计划背后的业务目标,确保更好的决策,并最大限度地降低风险。”

了解如何使用设置开源策略新指南中的提示和经过验证的实践,将管理和创建开源软件的目标与组织的业务目标保持一致。然后,查看所有 12 个企业开源指南,了解有关使用开源获得成功的更多信息。

本文最初发表在 Linux基金会


via: https://www.linux.com/blog/2018/11/free-guide-setting-your-open-source-strategy

作者:Amber Ankerholz 选题:lujun9972 译者:geekpi 校对:wxy

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

知识共享为艺术家提供访问权限和原始素材。大公司也从中受益。

我毕业于电影学院,毕业后在一所电影学校教书,之后进入一家主流电影工作室,我一直在从事电影相关的工作。创意产业的方方面面面临着同一个问题:创作者需要原材料。有趣的是,自由文化运动提出了解决方案,具体来说是在自由文化运动中出现的 知识共享 Creative Commons 组织。

知识共享能够为我们提供展示片段和小样

和其他事情一样,创造力也需要反复练习。幸运的是,在我刚开始接触电脑时,就在一本关于渲染工场的专业杂志中接触到了开源这个存在。当时我并不理解所谓的“开源”是什么,但我知道只有开源工具能帮助我在领域内稳定发展。对我来说,知识共享也是如此。知识共享可以为艺术家们提供充满丰富艺术资源的工作室。

我在电影学院任教时,经常需要给学生们准备练习编辑、录音、拟音、分级、评分的示例录像。在 Jim Munroe 的独立作品 Infest Wisely 中和 Vimeo 上的知识共享内容里我总能找到我想要的。这些逼真的镜头覆盖内容十分广泛,从独立制作到昂贵的高品质的升降镜头(一般都会用无人机代替)都有。

对实验主义艺术来说,确有无尽可能。知识共享提供了丰富的素材,这些材料可以用来整合、混剪等等,可以满足一位视觉先锋能够想到的任何用途。

在接触知识共享之前,如果我想要使用写实镜头,如果在大学,只能用之前的学生和老师拍摄的或者直接使用版权库里的镜头,或者使用有受限的版权保护的镜头。

坚守版权的底线很重要

知识共享同样能够创造经济效益。在某大型计算机公司的渲染工场工作时,我负责在某些硬件设施上测试渲染的运行情况,而这个测试时刻面临着被搁置的风险。做这些测试时,我用的都是大雄兔的资源,因为这个电影和它的组件都是可以免费使用和分享的。如果没有这个小短片,在接触写实资源之前我都没法完成我的实验,因为对于一个计算机公司来说,雇佣一只 3D 艺术家来按需布景是不太现实的。

令我震惊的是,与开源类似,知识共享已经用我们难以想象的方式支撑起了大公司。知识共享的使用可能会也可能不会影响公司的日常流程,但它填补了不足,让工作流程顺利进行。我没见到谁在他们的书中将流畅工作归功于知识共享的应用,但它确实无处不在。

我也见过一些开放版权的电影,比如辛特尔,在最近的电视节目中播放了它的短片,电视的分辨率已经超过了标准媒体。

知识共享可以提供大量原材料

艺术家需要原材料。画家需要颜料、画笔和画布。雕塑家需要陶土和工具。数字内容编辑师需要数字内容,无论它是剪贴画还是音效或者是电子游戏里的现成的精灵。

数字媒介赋予了人们超能力,让一个人就能完成需要一组人员才能完成的工作。事实上,我们大部分都好高骛远。我们想做高大上的项目,想让我们的成果不论是视觉上还是听觉上都无与伦比。我们想塑造的是宏大的世界,紧张的情节,能引起共鸣的作品,但我们所拥有的时间精力和技能与之都不匹配,达不到想要的效果。

是知识共享再一次拯救了我们,在 Freesound.orgOpenclipart.orgOpenGameArt.org 等等网站上都有大量的开放版权艺术材料。通过知识共享,艺术家可以使用各种他们自己没办法创造的原材料,来完成他们原本完不成的工作。

最神奇的是,不用自己投资,你放在网上给大家使用的原材料就能变成精美的作品,而这是你从没想过的。我在知识共享上面分享了很多音乐素材,它们现在用于无数的专辑和电子游戏里。有些人用了我的材料会通知我,有些是我自己发现的,所以这些材料的应用可能比我知道的还有多得多。有时我会偶然看到我亲手画的标志出现在我从没听说过的软件里。我见到过我为 Opensource.com 写的文章在别处发表,有的是论文的参考文献,白皮书或者参考资料中。

知识共享所代表的自由文化也是一种文化

“自由文化”这个说法过于累赘,文化,从概念上来说,是一个有机的整体。在这种文化中社会逐渐成长发展,从一个人到另一个。它是人与人之间的互动和思想交流。自由文化是自由缺失的现代世界里的特殊产物。

如果你也想对这样的局限进行反抗,想把你的思想、作品、你自己的文化分享给全世界的人,那么就来和我们一起,使用知识共享吧!


via: https://opensource.com/article/18/1/creative-commons-real-world

作者:Seth Kenlon 译者:Valoniakim 校对:wxy

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

透明和包容性的项目要求可以降低您的失败率。 以下是如何协作收集它们。

众所周知,明确、简洁和可衡量的需求会带来更多成功的项目。一项麦肯锡与牛津大学的关于大型项目的研究表明:“平均而言,大型 IT 项目超出预算 45%,时间每推移 7%,价值就比预期低 56% 。”该研究还表明,造成这种失败的一些原因是“模糊的业务目标,不同步的利益相关者以及过度的返工。”

业务分析师经常发现自己通过持续对话来构建这些需求。为此,他们必须吸引多个利益相关方,并确保参与者提供明确的业务目标。这样可以减少返工,提高更多项目的成功率。

他们可以用开放和包容的方式做到这一点。

成功的框架

提高项目成功率的一个工具是开放决策框架。开放决策框架是一种资源,可以帮助用户在拥抱开放原则的组织中做出更有效的决策。该框架强调三个主要原则:透明、包容、以客户为中心。

透明。很多时候,开发人员和产品设计人员都认为他们知道利益相关者如何使用特定工具或软件。但这些假设往往是不正确的,并导致对利益相关者实际需求的误解。开发人员和企业主讨论时实行透明势在必行。开发团队不仅需要了解一些好的情景,还需要了解利益相关方面对某些工具或流程所面临的挑战。提出诸如以下问题:“必须手动完成哪些步骤?”以及“这个工具是否按预期运行?”这提供了对问题的共同理解和讨论的基准。

包容。对于业务分析师来说,在收集需求时观察肢体语言和视觉暗示非常重要。如果有人双臂交叉或睁着眼睛坐着,那么这清楚地表明他们感觉没被聆听。业务分析师必须鼓励那些不被聆听的人公开交流,并给他们机会被聆听。在开始会议之前,制定基本规则,使所有人都能发表意见并分享他们的想法。聆听提供的反馈,并在收到反馈时礼貌地回复。多样化的意见和协作解决问题将为会议带来令人兴奋的想法。

以顾客为中心。以客户为中心的第一步是识别客户。谁从这种变化、更新或开发中受益?在项目早期,进行利益相关者映射,以帮助确定关键利益相关者,他们在项目中的角色以及他们适应大局的方式。让合适的客户参与并确保满足他们的需求将会确定更成功的要求,进行更现实(现实)的测试,并最终成功交付。

当你的需求会议透明、包容和以客户为中心时,你将收集更好的需求。当你使用开放决策框架来进行会议时,参与者会感觉有更多参与与授权,他们会提供更准确和完整的需求。换一种说法:

透明+包容+以客户为中心=更好的需求=成功的项目


via: https://opensource.com/open-organization/18/2/constructing-project-requirements

作者:Tracy Buckner 译者:geekpi 校对:wxy

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

以前我和我的一些亲戚争论过计算机科学的学位值不值得读。当时我正在上大学,并要决定是不是该主修计算机。我姨和我表姐觉得我不应该主修计算机。她们承认知道如何编程肯定是很有用且对自己有利的一件事,但是她们认为计算机科学现在发展的如此迅速以至于我学的东西几乎马上就过时了。建议我更好是把编程作为辅业,选择一个基础原理可以受用终身的领域主修,比如经济学或物理学。

我知道我姨和我表姐说的不对,并决定主修计算机科学。(对不住啊!)平常人可能会觉得像计算机科学领域和软件工程专业每隔几年就完全和之前不一样了。其原因很容易理解。我们有了个人电脑,然后有了互联网,有了手机,之后还有了机器学习…… 科技总是在更新,支撑科技发展的原理和技能当然也在改变。当然,最惊人的是其实原理的改变竟然如此之小。我敢肯定,大多数人在知道了他们电脑里一些重要的软件的历史是多么久远时他们一定会深感震惊。当然我不是说那些刷版本号的浮夸软件 —— 我电脑上的 Firefox 浏览器副本,可能是我用的最多的软件,可能两周前就更新过。如果你看了比如 grep 的手册页,你就会发现它在 2010 年后就没有过更新了(至少在 MacOS 上如此)。初版 grep 是在 1974 年写就的,那时可以算是计算机世界的侏罗纪了。直到现在,人们(还有程序)仍然依赖 grep 来完成日常工作。

我姨和我表姐认为计算机技术就像一系列日渐精致的沙堡,在潮水抹净沙滩后新的沙堡完全取代旧的。但事实上,在很多领域上,我们都是不断积累能够解决问题的程序。我们可能不得不偶尔修改这些程序以避免软件无法使用,但大多数情况下我们都可以不修改。grep 是一个简单的程序,可以解决一个仍然存在的需求,所以它能够存活下来。 大多数应用程序编程都是在非常高的级别上完成的,它们建立在解决了旧问题的旧程序的金字塔上。 30 年或 40 年前的思路和概念,远非过时,在很多情况下它们依然在您的笔记本电脑上软件中存在着。

我想追溯这样的老程序自第一次写就以来改变了多少回很有趣。 cat 可能是所有 Unix 实用程序中最简单的,因此我们以它为例。Ken Thompson 于 1969 年编写了 cat 的原始实现。如果我告诉别人我的电脑上安装了个来自 1969 年的程序,这准确吗?我们电脑上的程序多大了?

感谢这种这种仓库,我们可以完整的看到 cat 自 1969 年后是如何发展的。我会先聚焦于可以算得上是我的 MacBook 上的 cat 的祖先的 cat 实现。随着我们从 Unix 上的第一版 cat 追踪到现在 MacOS 上的 cat,你会发现,这个程序被重写的次数比你想的还要多 —— 但是直到现在它运行的方式和五十年前多少是完全一致的。

研究 Unix

Ken Thompson 和 Dennis Ritchie 在 PDP 7 上开始写 Unix。那还是 1969 年,C 还没被发明出来,因此所有早期的 Unix 软件都是用 PDP 7 汇编实现的。他们使用的汇编种类是 Unix 特有的,Ken Thompson 在 DEC(PDP 7 的厂商)提供的汇编器之上加了些特性,实现了自己的汇编器。Thompson 的更改在最初的 Unix 程序员手册as(也就是汇编器)条目下均有所记录。

因此,最初的 cat 也是使用 PDP 7 汇编实现的。 我添加了一些注释,试图解释每条指令的作用,但除非你理解 Thompson 在编写汇编器时加的特性,否则程序仍然很难理解。在那些特性中有两个很重要:其一是 ; 这个字符可以在一行中用来分隔多条语句,它多出现于在使用 sys 指令时将系统调用的多个参数放在同一行上。其二是, Thompson 的汇编器支持使用 0 到 9 作为“临时标签”,这是在程序内可以重用的标签。因此。就如 Unix 程序员手册中所说:“对程序员的想象力和汇编程序的符号空间的要求都降低了”。在任何给定的指令内,你都可以使用 nfnb 来引用下一个或最近的临时标签 n。 例如,如果存在标记为 1: 的代码块,你就可以使用指令 jmp 1b 从下游代码跳回该块。 (但是你不使用 jmp 1f 的话就没法从上面的代码跳到这里。)

初版 cat 最有趣的就是它包含着我们应该认识的符号。有一块指令块标记为 getc,还有一个标记为 putc,可以看到这两个符号比 C 标准还古老。第一版的 cat 函数实际上已经包含了这两个函数的实现。该实现做了输入缓存,这样它就不需要一次只读写一个字母。

cat 的第一个版本并没有持续多久。 Ken Thompson 和 Dennis Ritchie 说服贝尔实验室购买了 PDP 11,这样他们就能够继续扩展和改进 Unix。 PDP 11 的指令集和之前不一样,因此必须重写 cat。 我也注释了这个第二版 cat。 它为新的指令集使用新的汇编程序助记符,并利用了 PDP 11 的各种寻址模式。(如果你对源代码中的括号和美元符号感到困惑,那是因为这些符号用于指示不同的寻址模式。)但它也使用 ; 字符和临时标签,和 cat 的第一个版本一样,这意味着当把 as 移植到 PDP 11 上时,必须要保留这些功能。

cat 的第二个版本比第一个版本简单得多。 它也更有 Unix 味儿,它不只是依靠参数列表,一旦没给参数列表,它将从 stdin 读取数据,这也就是今天 cat 仍在做的事情。 你也可以在此版本的 cat 中以 - 为参数,以表示它应该从stdin读取。

在 1973 年,为了准备发布第四版 Unix,大部分代码都用 C 语言重写了。但是 cat 似乎在之后一段时间内并没有使用 C 重写。 cat 的第一个 C 语言实现出现在第七版 Unix 中。 这个实现非常有趣,因为它很简单。 在所有以后的实现中,这个实现和在 K&R 的 C 语言教科书中用作教学示范的理想化 cat 最相似。这个程序的核心就是经典的两行:

while ((c = getc(fi)) != EOF)
 putchar(c);

当然实际代码要比这多一些,额外的代码主要是为了确保你没有在读/写同一个文件。另一个有趣的事情是,cat 的这一版实现只识别一个标志位 -u-u 标志可用于避免缓冲输入和输出,否则 cat 将以 512 字节为块进行输入输出。

BSD

在第七版 Unix 之后,Unix 出现了各种衍生品和分支。 MacOS 建立于 Darwin 之上,而 Darwin 又源自 伯克利软件分发版 Berkeley Software Distribution (BSD),因此 BSD 是我们最感兴趣的 Unix 分支。 BSD 最初只是 Unix 中的实用程序和附加组件的集合,但它最终成为了一个完整的操作系统。直到第四版 BSD,人称 4BSD,为一大堆新标志添加了支持之前,BSD 似乎还是依赖于最初的 cat 实现的。cat4BSD 实现 显然是从原始实现中衍生出来的,尽管它添加了一个新函数来实现由新标志触发的行为。已经在文件中使用的 fflg 变量(用于标记输入是从 stdin 还是文件读取的)的命名约定,被新添加的 nflgbflgvflgsflgeflgtflg 沿袭了下来,这些变量记录了在调用程序时是否使用了这些新标志。这些是最后一批添加到 cat 的命令行标志。如今 cat 的手册页列出了这些标志,没有其他的标志了,至少在 Mac OS 上是如此。 4BSD 于 1980 年发布,因此这套标志已有 38 年历史。

cat 最后一次被完全重写是在 BSD NET/2 上,其目的是通过替换 AT&T 发布的全部 Unix 源代码来规避许可证问题。BSD Net/2 在 1991 年发布。这一版本的 cat 是由 Kevin Fall 重写的。 Kevin Fall 于 1988 年毕业于加州大学伯克利分校并在下一年成为 计算机系统研究组 Computer Systems Research Group (CSRG)的组员,Fall 和我说当时使用 AT&T 代码的 Unix 工具被列在了 CSRG 的墙上,组员需要从中选出他们想要重写的工具; Fall 选了 cat 以及 mknod。 MacOS 系统内自带的 cat 实现源码的最上面还有着他的名字。他的这一版 cat,尽管平淡无奇,在今天还是被无数人使用着。

Fall 的原始 cat 实现 比我们迄今为止看到的版本都要长。 除了支持 -? 帮助标志外,它没有增加任何新功能。 从概念上讲,它与 4BSD 的实现非常相似。 它长是因为 Fall 将实现分为 “原始” 模式和 “加工” 模式。 “原始” 模式是 cat 的经典实现;它一个字符一个字符的打印文件。 “加工” 模式是带有所有 4BSD 命令行选项的 cat。 如此区别不无道理,但这么办也扩充了实现规模,因此乍一看其源码似乎比实际上更复杂。文件末尾还有一个奇特的错误处理函数,进一步地增加了实现的长度。

MacOS

在 2001 年,苹果发布了 MacOS X。这一发布对苹果意义重大。因为苹果用了多年的时间尝试以取代其现有的老旧操作系统(经典的 Mac OS),但是都失败了。 在 Mac OS X 之前苹果两次尝试在内部创建一个新的操作系统,但两者都无疾而终。 最后,苹果收购了史蒂夫·乔布斯的 NeXT 公司,后者开发了一个名为 NeXTSTEP 的操作系统和面向对象编程框架。 苹果将 NeXTSTEP 作为 Mac OS X 的基础。因为 NeXTSTEP 部分基于 BSD,使以 NeXTSTEP 为基础的 Mac OS X 的自然就把 BSD 系的代码直接带入苹果宇宙的中心。

因此,Mac OS X 的非常早期的第一个版本包含了从 NetBSD 项目中提取的 cat实现。如今仍保持开发的 NetBSD 最初是 386BSD 的分支,而后者又直接基于 BSD Net/2。所以 Mac OS X 里面的第一个 cat 的实现就是 Kevin Fall 的 cat。唯一改变的是,Fall 的错误处理函数 err()err.h 提供的 err() 函数取代了。 err.h 是 C 标准库的 BSD 扩展。

之后不久,这里的 cat 的 NetBSD 实现被换成了 FreeBSD 中的 cat 实现。 根据维基百科),苹果在 Mac OS X 10.3(Panther)中开始使用 FreeBSD 的实现而不是 NetBSD 的实现。但根据苹果自己开源的版本,cat 的 Mac OS X 实现在 2007 年发布的 Mac OS X 10.5(Leopard)之前没有被替换。苹果为 Leopard 替换的的 FreeBSD 实现与今天苹果计算机上的实现相同。截至 2018 年,2007 年以来的这个实现仍未被更新或修改。

所以 Mac OS 上的 cat 已经很老了。实际上,这一实现在 2007 年在 MacOS X 上露面两年前就被发布了。 这个 2005 年的修改 在 FreeBSD 的 Github 镜像中可见,是在苹果将其合并入 Mac OS X 前对 FreeBSD 的 cat 实现进行的最后一次更改。所以 Mac OS X 中的实现没有与 FreeBSD 的 cat 实现保持同步,它如今已经 13 岁了。对于软件修改了多少代码才能仍是算是同一软件这一话题有着旷日持久的争论。不过,在这种情况下,源文件自 2005 年以来根本没有变化。

现在 Mac OS 使用的 cat 实现与 Fall 1991 年为 BSD Net/2 版本编写的实现没有什么不同。最大的区别是添加了一个全新的功能来提供 Unix 域套接字支持。FreeBSD 开发人员似乎将 Fall 的 raw_args() 函数和 cook_args() 函数组合成一个名为scanfiles() 的函数。否则,程序的核心就仍是 Fall 的代码。

我问过 Fall 对编写了如今被数以百万计的苹果用户(直接或者间接通过依赖 cat 的某些程序)使用的 cat 实现有何感想。Fall,如今是一位顾问,也是最新版《TCP/IP 详解》的合著者,他说,当人们从了解他对 cat 所做的工作中收获颇丰时,他感到很惊讶。 Fall 在计算机领域有着悠久的职业生涯,曾参与许多备受瞩目的项目,但似乎很多人仍对他在 1989 年重写 cat 的那六个月的工作感到最为兴奋。

百年老程序

在宏伟的发明史中,计算机并不是一项古老的发明。我们已经习惯了百年的照片甚至是百年的视频短片。但是计算机程序不一样 —— 它们代表着高科技和新技术。至少,他们是现代的技术造出来的。随着计算行业的成熟,我们有朝一日会发现自己正在使用有着接近百年历史的程序吗?

计算机硬件可能会发生较大的变化,使得我们也许无法让现在编译的可执行文件在一个世纪后的硬件上运行。也许编程语言设计的进步让未来没有人能理解 C 语言,cat 将来也可能也被别的语言重写很久了。 (尽管 C 已经存在了五十年了,而且它似乎不会很快就被替换掉。)但除此之外,为什么不永远使用我们现在的 cat

我认为 cat 的历史表明,计算机科学中的一些想法确实非常持久。事实上,对于 cat,这个想法和程序本身都很古老。不准确地说,我的电脑上的 cat 来自 1969 年。但我也可以说我的计算机上的 cat 来自1989 年,当时 Fall 写了他的 cat 实现。许多其他软件也同样古老。因此,也许我们不应该把计算机科学和软件开发视为不断破坏现状和发明新事物的领域。我们的计算机系统是由诸多历史文物构建的。有时,我们可能会花费更多时间在理解和维护这些历史文物上,而不是花在编写新代码上。

如果你喜欢本文,你可能更喜欢两周来一篇更新!在推特上关注 @TwoBitHistory 或者订阅这个 RSS 源 以保证接受到新的文章。


via: https://twobithistory.org/2018/11/12/cat.html

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

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

以及,对于 无服务器 Serverless 架构,什么时候该用,什么时候不该用呢?

如果将如今互联网体验中最方便实用的那一部分去掉,那么留下来的基本就是 客户端-服务端 client-server 模式了。这一个模式在互联网建立初期就已经在使用了,直到目前都没有太大的变化,也就是说,这个模式仍然在为我们服务。

那么,当人们谈论 无服务器 Serverless 架构的时候,到底是指什么呢?其实,无服务器架构并不是说不使用服务器了。恰恰相反,客户端-服务端模式仍然在其中发挥着重要的作用。

无服务器架构实际上指的是能够让开发者在不需要关心服务器上架、为操作系统打补丁、创建容器镜像这些工作的情况下,就能够完成编码、部署和创建应用这一整套流程的架构。

无服务器架构的三个重要意义

  1. 一些缺乏开发经验的人员现在要参与到开发工作中来了。无服务器架构能够让他们尽量只学习必要的工作内容,把更多的时间放在更具创造性的开发工作中。
  2. 开发者不再需要重复造轮子。运行和维护服务器、为操作系统打补丁、创建容器等这一系列工作,都可以由更专业的无服务器架构提供商来完成。
  3. 最现实的一点是,如果不使用无服务器架构,那么在服务器管理方面,总需要有一个作最终决策的人。当服务器发生崩溃时,或是需要在服务器上执行某些操作时,总是需要这样一个统领全局的人来作出决策。因此最佳的方案是使用无服务器架构。

什么时候该用或者不该用无服务器架构?

听起来无服务器架构是个好东西。但事实上,无服务器架构并不是万能的,在使用之前还需要考虑以下这些因素:

  1. 成本
  2. 使用范围
  3. 时间
  4. 控制方式

其中值得注意的是控制方式。现在已经有一些项目为开发者提供了操作和控制无服务器架构计算环境的工具了,Apache OpenWhisk 就是其中之一。

为什么要将无服务器架构开源?

关于这方面的更多内容,可以观看无服务器架构方面的专家 Saron Yitbarek 在 Command Line Heroes 节目中的访谈。


via: https://opensource.com/article/18/12/serverless-podcast-command-line-heros

作者:Jen Wike Huger 选题:lujun9972 译者:HankChow 校对:wxy

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

如何表达你的感激之情。

每天,我使用的那些高质量的软件 —— 开发和维护这些软件的人不需要我为之付款,他们尊重我的自由,并且慷慨地付出时间和精力。

在这个感恩的季节,我鼓励那些也使用和欣赏开源和自由软件维护者工作的人表达你的感激之情。以下是十种方法:

容易做到的

1、发送电子邮件感谢开发人员。具体点说,告诉他们你使用他们的什么软件以及它是如何帮助了你。

2、使用你最喜爱的社交媒体平台宣传它。

3、写一篇关于你最喜欢的软件的博客文章。

捐款

4、如果你最喜欢的开源项目接受捐款,请汇款。

5、如果你受雇于使用开源软件的公司,看你是否可以说服管理层赞助某些项目。

6、尽你所能地捐款。社交动机能做的不可思议!

花费时间

7、帮助审查补丁。

8、帮助分类 bug。

9、回答 IRC、邮件列表或 Stack Overflow 中的问题。

10、额外的:如果你像我一样,你在某个时候对开源社区的其他人说了一些严厉的话。承诺做得更好:用善良和开放沟通。感谢的最好方式是让开源社区成为人们能舒适沟通的地方。


via: https://opensource.com/article/18/11/ways-give-thanks-open-source

作者:Moshe Zadka 选题:lujun9972 译者:geekpi 校对:wxy

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