2020年3月

对于软件定义的广域网(SD-WAN),“过去看起来困难的选择,知道了这些选择的结果后,现在看起来就很清晰了” 这一说法再合适不过了。总结过去的几年:云计算和数字化转型促使公司重新评估传统的 WAN 技术,该技术不再能够满足其不断增长的业务需求。从那时起,SD-WAN 成为一种有前途的新技术。

SD-WAN 旨在解决物理设备的流量管理问题,并支持从云进行基于软件的配置。许多最初的 SD-WAN 部署都因希望取代昂贵的多协议标签交换 (MPLS) 而得到推动。公司希望它可以神奇地解决他们所有的网络问题。但是在实践中,基本的 SD-WAN 解决方案远没有实现这一愿景。

快速发展到现在,围绕 SD-WAN 的炒作已经尘埃落定,并且早期的实施工作已经过去。现在是时候回顾一下我们在 2019 年学到的东西以及在 2020 年要改进的地方。所以,让我们开始吧。

1、这与节省成本无关

大多数公司选择 SD-WAN 作为 MPLS 的替代品,因为它可以降低 WAN 成本。但是,节省的成本会因 SD-WAN 的不同而异,因此不应将其用作部署该技术的主要驱动力。无论公司需要什么,公司都应该专注于提高网络敏捷性,例如实现更快的站点部署和减少配置时间。SD-WAN 的主要驱动力是使网络更高效。如果成功实现那么成本也会随之降低。

2、WAN 优化是必要的

说到效率,WAN 优化提高了应用程序和数据流量的性能。通过应用协议加速、重复数据消除、压缩和缓存等技术,WAN 优化可以增加带宽、减少延迟并减轻数据包丢失。最初的想法是 SD-WAN 可以完成对 WAN 优化的需求,但是我们现在知道某些应用程序需要更多的性能支持。这些技术相互补充,而不是相互替代。它们应该用来解决不同的问题。

3、安全性不应该事后考虑

SD-WAN 具有许多优点,其中之一就是使用宽带互联网快速发送企业应用程序流量。但是这种方法也带来了安全风险,因为它使用户及其本地网络暴露于不受信任的公共互联网中。从一开始,安全性就应该成为 SD-WAN 实施的一部分,而不是在事后。公司可以通过使用安全的云托管之类的服务,将安全性放在分支机构附近,从而实现所需的应用程序性能和保护。

4、可见性对于 SD-WAN 成功至关重要

在应用程序和数据流量中具有可见性,这使网络管理不再需要猜测。最好的起点是部署前阶段,在此阶段,公司可以在实施 SD-WAN 之前评估其现有功能以及缺少的功能。可见性以日常监控和警报的形式在部署后继续发挥重要作用。了解网络中正在发生的情况的公司会更好地准备应对性能问题,并可以利用这些知识来避免将来出现问题。

5、无线广域网尚未准备就绪

SD-WAN 可通过包括宽带和 4G/LTE 无线在内的任何传输将用户连接到应用程序。这就是移动互联越来越多地集成到 SD-WAN 解决方案中的原因。尽管公司渴望将 4G 用作潜在的传输替代方案(尤其是在偏远地区),但由此带来的按使用付费 4G 服务成本却很高。此外,由于延迟和带宽限制,4G 可能会出现问题。最好的方法是等待服务提供商部署具有更好的价格选择的 5G。今年我们将看到 5G 的推出,并更加关注无线 SD-WAN。

请务必观看以下 SD-WAN 视频系列:你应该知道的所有关于 SD-WAN 的知识


via: https://www.networkworld.com/article/3531315/2020-will-be-a-year-of-hindsight-for-sd-wan.html

作者:Zeus Kerravala 选题:lujun9972 译者:hkurj 校对:wxy

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

在本周的开源软件推荐中,我们将介绍一个基于 Firefox 的浏览器,该浏览器支持 Firefox 如今已不再支持的旧版扩展,同时尽可能地提供了快速的用户体验。

在 Web 浏览器方面,虽然谷歌浏览器已经占据了最大的市场份额,但 Mozilla Firefox 仍然是关切隐私的主流 Web 浏览器的一面大旗

Firefox 最近有了很多改进,这些改进的副作用之一是它删除了旧版 扩展附件 add-on 的支持。如果你最喜欢的扩展附件在最近几个月/几年内消失了,那么你可以以 Witerfox 的形式再次拥有它们。

注意!

我们注意到,Waterfox 已被 System1 收购。该公司还收购了注重隐私的搜索引擎 Startpage。尽管 System1 声称他们提供注重隐私的产品,因为“这是刚需”,但我们不能对此担保。换句话说,这要取决于你是否信任 System1 和 Waterfox。

Waterfox:一个基于 Firefox 的浏览器

Waterfox Classic

Waterfox 是基于 Firefox 构建的一个好用的开源浏览器,它注重隐私并支持旧版扩展。它没有将自己定位为偏执于隐私的浏览器,但确实尊重这个基本的认知。

你可以得到两个单独的 Waterfox 浏览器版本。当前版旨在提供现代体验,而经典版则旨在支持 NPAPI 插件bootstrap 扩展

Waterfox Classic

如果你不需要使用 bootstrap 扩展程序,而是需要 WebExtensions,则应该选择 Waterfox 当前版。

而如果你需要设置一个需要大量 NPAPI 插件或 Bootstrap 扩展的浏览器,则 Waterfox 经典版将非常适合你。

因此,如果你喜欢 Firefox,但想在同一阵营内尝试一些不同的体验,那么这个 Firefox 替代选择就是为此而生的。

Waterfox 的功能

Waterfox Current

当然,从技术上讲,你应该能够做 Mozilla Firefox 支持的许多操作。

因此,我将在此处的列表中突出显示 Waterfox 的所有重要功能。

  • 支持 NPAPI 插件
  • 支持 Bootstrap 扩展
  • 分别提供了支持旧版本扩展和现代的 WebExtension 两个版本。
  • 跨平台支持(Windows、Linux 和 macOS)
  • 主题定制
  • 支持已经归档的扩展

在 Ubuntu/Linux 上安装 Waterfox

与其他流行的浏览器不同,它没有可以安装的软件包。因此,你将必须从其官方下载页面下载归档包。

根据你想要的版本(当前版/经典版),只需下载该文件,它是以 .tar.bz2 为扩展名的文件。

下载后,只需解压缩文件即可。

接下来,转到解压缩的文件夹并查找 Waterfox 文件。你只需双击它即可运行以启动浏览器。

如果这不起作用,则可以使用终端并导航到提取的 Waterfox 文件夹。到达那里后,你只需使用一个命令即可运行它。看起来如下:

cd waterfox-classic
./waterfox

无论是哪种情况,你都可以访问其 GitHub 页面以了解将其安装在系统上的更多方式。

总结

我在我的 Pop!\_OS 19.10 系统中启动了它,在我这里工作的很好。尽管我不准备从 Firefox 切换到 Waterfox,因为我没有使用任何旧版扩展附件。但对于某些用户来说,它可能是一个重要选择。

你可以尝试一下,在下面的评论中让我知道你的想法。


via: https://itsfoss.com/waterfox-browser/

作者:Ankush Das 选题:lujun9972 译者:wxy 校对:wxy

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

今天看到一篇文章《开源项目在闲鱼、b 站上被倒卖?这是什么骚操作?》,我突然想起了之前两个类似的案例,发现群众的开源知识普及依然不足,借这个机会再聊聊开源,从开源著作权人的角度做一次讨论。

案例 1:倒卖开源代码

本案例中,作者十三发现自己开源的代码被贩卖,一脸郁闷。先不讨论这些倒卖者的行为,笔者从作者提供的代码托管官网上看到其开源许可证是 MIT。

MIT 作为一个宽松型开源许可证,授予使用者几乎无限制的权限。也就是说倒卖者的行为固然让人讨厌,但其确实是可以这么做的。当然,作者十三除了困惑于开源的东西为何还有人拿去卖钱以及竟然还有人买之外,整体上是淡定、大度的。而倒卖者利用的正是大众的这种专业知识的缺失和信息的不对称性,严格意义上这是存在经济正当性的。

案例 2:王垠闭源

这个案例是 2017 年的旧闻,但很具代表性。BSD 许可证开源的软件被商业公司商业使用,还聘请了原开发者,最后闹的鸡飞狗跳。

注:原博文《为什么我的代码进入闭源状态》地址已经 404 无法访问,大家可以搜索相关转载。

王垠此人我不甚了解,据说曾经国内人气非常高,知乎、v2ex、csdn 博客上到处都有对他的评价和争论。但至少从这篇帖子可以看出,其对开源的理解很浅、也很狭隘(在 2017 年时,不代表现在)。其对开源抱有不该有的幻想,期待过高。

案例3:swoole 修改开源协议

这个案例也是 2017 年的,以 Apache 许可证开源的软件 swoole(撰文时经核实 swoole 依然是 Apache 许可证),与其复刻分支版本之间纷争。

这个案例更像各种 Android 发布版与 Google Android OS 之间的关系,以宽松型许可协议开源的软件被各种修改版骚扰、蹭热度的现象很普遍。

开源知识普及之路漫长

以上三个案例都可以称之为开发者的控诉,暂不评论其控诉是否合理。仅以这些事件本身以及在网上引起的纷争,都说明距离开源在国内普及,还有很长的路要走。但值得欣慰的是,从 2017 年到 2020 年我们看到了这种进步,案例 1 中的作者对开源的理解上虽有偏颇,但并没有出现知识或法律方面的硬伤。

从开源软件概念引入中国,到近几年开源运动如火如荼的开展,已有几个年头。但据笔者与企业及业内人士的接触发现,公众对开源的认知和理解程度依旧参差不齐。究其原因有以下几点:

  1. 大部分关注开源的人,更多的是关注技术,不会关注其背后的许可证问题;
  2. 开源许可证更偏向法律,真正做技术的不关注、也不懂;
  3. 开源许可证法律条文晦涩难懂,不容易理解;
  4. 懂技术、会看代码的专利、著作权、商标等领域的律师甚少,没有技术背景的律师纵使法律水平再高,在理解涉及开源软件相关问题时也力不从心;
  5. 开源领域国内诉讼不多,没有充分引起大部分企业、学界等人员的重视;
  6. 也因为诉讼少,经济驱动力有限,很难吸引律师深入研究这一领域。重赏之下必有勇夫,若有足够的利益驱动,修个计算机学位又何妨,或者报个代码速成班也不是不可能吧。

笔者有缘在多年前接触开源治理、合规问题,时不时看到网上爆出浅层次开源“事故”,说明大众的开源知识有限。今天蹭个热乎劲,再探讨一下开源基础知识(开源科普的知识网上并不少,没人关注归根结底还是这个领域内生动力不足所致)。既然内生动力不足,就靠外部热点的外部动力吧。

开源“事故”,你是否理解开源?

开源是什么?

开源就是奉献,无私或有私的奉献。此处不接受反驳。

开源运动起源于自由软件运动,自由软件运动的发起人 理查德·马修·斯托曼 Richard Matthew Stallman 是自由软件运动精神领袖。自由软件运动所要反对的就是后来以比尔盖茨(曾经)为代表的软件私有化运动。所以说,自由软件是旗帜鲜明的追求奉献、共享和软件自由的。

开源运动的兴起是自由软件运动向商业化的妥协(可以这么说,毕竟经济基础决定上层建筑),所以说开源软件运动虽然有别于曾经的自由软件运动,奉献和协作依然深深的烙在其血液里。如果你无法理解这一点,就再看 10 遍开源软件的定义(直到看懂为止)。

开源运动淡化了自由软件运动乌托邦式的理想主义,穿上了实用主义的外衣,毕竟空洞的理想是填不饱肚子的。

开源“事故”,背后的起因

网上时不时爆出的开源“事故”大都归于两类:

类型一:批判拿来主义者坐收渔利、不劳而获、贩卖别人劳动成果……。这一类主角,多是软件开发者自己,站在自己的立场上看待开源软件的使用者(合法使用者、不合法使用者)。

该类“事故”的原因有:

  1. 软件的开发者没有充分理解开源的要义;
  2. 对开源许可证不理解,开源自己软件时没能正确选择许可证,导致自己有被白piao的感觉;
  3. 想借助大众或社区的力量优化自己的软件,获得免费劳动力;
  4. 想借助开源扩大自己影响力(自我营销),却没考虑为此要付出的代价;
  5. 看到其他人利用自己的开源软件获利,心理上有些许不平衡。

类型二:批判开源软件收费、许可证不人性,批判严格型许可证的传染性像病毒、吸血鬼、耍流氓,对别人行使著作权或协议约定的行为愤愤不平。这一类人,基本是拿来主义者,同样站在自己的立场上看待开源软件的开发者(仁慈的开发者、邪恶的开发者)。

该类“事故”的原因有:就是想白 piao 而已,因为你完全有选择用与不用的权力。

这两类“事故”的产生都源于没能深入理解开源运动的精髓和要义,纯粹的从利己主义出发思考问题,没有做到换位思考。忽略了开源的初衷:奉献和共享。

现实中,经常发生这样的事情:对同一个人,作为开源的使用者时他们常常讨厌 GPL 许可证,因为限制太多;作为开源软件开发者时又喜欢 GPL 的安全感,讨厌 MIT、BSD 等许可证让自己被白 piao 了却投诉无门。

开发者和使用者的权利义务

开源软件首先是开发者的劳动成果,是拥有著作权的。开源一定意义上就是奉献,每一个开源软件使用者都是开源的受益者。面对这种奉献,你需要做的就是尊重。但开源的使用者并不必然要求是高尚的、无私的,这种尊重基于开发者选择的开源许可证在合规的前提下行使权利,在尊重权利人的同时实现共赢和自身利益最大化。

而作为开源软件的开发者,也不必然要求是高尚的、无私的,开发者可以基于自己的目的来选择适当的开源协议。选择开源,就要审视自己内心深处的想法,开源的动机和目的是什么?后果是什么?……慎重的思考了这些问题后,还需要清楚的知道选择宽松型的许可证可能要面对的各种问题。

开源使用者是纯粹的受益者,即便是抱怨无非是对严格型许可证发发牢骚而已。而开源的开发者往往显得更值得同情,一般是从道义上(如案例 3)以及经济利益上(如案例 1、2)体现。但这就是开源运动运行的机制,它肯定不完美,但被证明是行之有效的。针对开源开发者,你需要做的就是当别人违法的时候拿起法律的武器捍卫自己的权利,当别人没有违法的时候,你心里再不爽也要保持淡定。

当然,诸如前述案例让人糟心的事情肯定很多,开发者也不是束手无策:

比如案例 1 中新蜂商城的作者,选择了 MIT 这个非常宽松的许可证。就意味着,其他人几乎可以拿来做任何事情,包括卖钱。但你依然有以下权利:

  1. 不准拿你的大名做推广,或者类似名字这种具有身份意义、独特标识作用的符号;
  2. 如果作品真的好且有市场,作者完全可以自己经营,将自己的品牌做大;
  3. 别人卖的了你的源码卖不了你的实力,你可以不断迭代升级,源码和服务提供一站式解决方案。其实,现实中我们熟悉的开源软件大都如此,比如 Android、Linux 等;
  4. 乐见其成,毕竟开源就是奉献自己的劳动成果让人使用,二手贩子们所做的事与开源者的目标是一致的。当然如果贩子们声称是自主源码云云(国内拿开源的东西声称自主开发的太多了),那必然是违法的,开源者可以大胆的拿起法律的武器。

主动开源,你真的准备好了吗?

基于国内的现实状况,笔者以往更多的是将精力放在帮助企业和开发者合规的使用和利用开源。因为我们曾经都是开源的受益者,需要基于合法、合规的前提汲取营养、学习知识。

目前,国内越来越多企业或个人开始思考反哺开源社区,这是非常好的开始,说明我们从受益者开始变为奉献者。但现实中这些才华横溢的开发者在开源中难免遇到案例中的问题,一旦遇到将严重挫伤其开源的积极性。

因此,开源开发者在主动开源之前,更需要深刻理解开源,明确自己开源的目的以及可能面对的潜在问题等。在慎重思考自己开源的目的和对开源后各种问题的考量后,选择适合自己的许可证。

以下是几个典型的开源动机面临的潜在风险:

  1. 想借助大众或社区的力量优化自己的软件,获得免费劳动力
    开源软件千千万,真正取得成功或大众认可的软件凤毛麟角,不能说这种目的动机不纯,至少实现的可能性甚微。更多的可能是根本没有人看得上你的项目。
  2. 想借助开源扩大自己影响力(自我营销)
    这可能是开源开发者,包括大企业做开源的一个非常重要的目的。具体能否实现,就看你的水平有多高,实力是否匹配自己的梦想。
  3. 基于自己牛逼的软件,打造生态。
    这也是大部分企业的终极梦想,就像第一条所述,大部分的开源软件都归于路人甲,能否实现自己的生态梦取决于你的软件到底如何,能否支撑一个生态、够吸引外围群落。
    即便这些都满足了,还要思考一点,你自己的实力能否持续主导这个生态的发展。因为,开源社区的主导力是由实力说话的,如果你无法保持持续的创造力,别人fork一下就可能成为新的盟主而把你晾在一边坐冷板凳。Google 的 Android 生态就是道理,Google 对 Android 生态的领导力是建立在其持续的创造力之上的。
  4. Just for fun
    最纯粹的开源。如果你开源软件的目的很单纯,就是因为喜欢而开源。那单纯的你需要知道不同开源许可证开源的后果。若别人拿你的开源软件去卖钱你也不要太上头,因为这是允许的,当然更不能看到别人赚了一大笔钱心里就不平衡了。就像大把的企业靠着 林纳斯·本纳第克特·托瓦兹 Linus Benedict Torvalds Just for fun 的软件 Linux 和 Git 赚了大笔的钱,你能做的就是乐见其成。

开源不仅仅是代码,更是人品和实力,也是策略和格局。希望每一个奉献和使用开源的你,都能感受到这个世界的善意。以上是基于本次热点,针对使用开源以及主动开源分享的点滴思考和建议。有兴趣可以找我讨论沟通。


付钦伟,集慧智佳高级咨询师、专利代理人,擅长专利分析布局、FTO调查与风险应对、专利信息应用、开源软件风险与合规指导。

两者之间的区别在于开发完毕之后发生的事情。

早期,软件开发并没有特定的管理流程。随后出现了 瀑布开发流程 Waterfall ,它提出软件开发活动可以用开发和构建应用所耗费的时间来定义。

那时候,由于在开发流程中没有审查环节和权衡考虑,常常需要花费很长的时间来开发、测试和部署软件。交付的软件也是带有缺陷和 Bug 的质量较差的软件,而且交付时间也不满足要求。那时候软件项目管理的重点是长期而拖沓的计划。

瀑布流程与 三重约束模型 triple constraint model 相关,三重约束模型也称为 项目管理三角形 project management triangle 。三角形的每一个边代表项目管理三要素的一个要素: 范围、时间和成本。正如 Angelo Baretta 写到,三重约束模型“认为成本是时间和范围的函数,这三个约束以一种确定的、可预测的方式相互作用。……如果我们想缩短时间表(时间),就必须增加成本。如果我们想增加范围,就必须增加成本或时间。”

从瀑布流程过渡到敏捷开发

瀑布流程来源于生产和工程领域,这些领域适合线性化的流程:正如房屋封顶之前需要先盖好支撑墙。相似地,软件开发问题被认为可以通过提前做好计划来解决。从头到尾,开发流程均由路线图清晰地定义,沿着路线图就可以得到最终交付的产品。

最终,瀑布模型被认为对软件开发是不利的而且违反人的直觉,因为通常直到开发流程的最后才能体现出项目的价值,这导致许多项目最终都以失败告终。而且,在项目结束前客户看不到任何可以工作的软件。

敏捷 Agile 采用了一种不同的方法,它抛弃了规划整个项目,承诺估计的时间点,简单的遵循计划。与瀑布流程相反,它假设和拥抱不确定性。它的理念是以响应变化代替讨论过去,它认为变更是客户需求的一部分。

敏捷价值观

敏捷由 敏捷宣言 Agile Manifesto 代言,敏捷宣言定义了 12 条原则(LCTT 译注:此处没有采用本文原本的简略句式,而是摘录了来自敏捷软件开发宣言官方的中文译本):

  1. 我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。
  2. 欣然面对需求变化,即使在开发后期也一样。
  3. 经常交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。
  4. 业务人员和开发人员必须相互合作,项目中的每一天都不例外。
  5. 激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。
  6. 面对面沟通是传递信息的最佳的也是效率最高的方法。
  7. 可工作的软件是进度的首要度量标准。
  8. 敏捷流程倡导可持续的开发,责任人、开发人员和用户要能够共同维持其步调稳定延续。
  9. 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
  10. 以简洁为本,它是极力减少不必要工作量的艺术。
  11. 最好的架构,需求和设计出自自组织团队
  12. 团队定期地反思如何能提高成效,并依此调整自身的举止表现。

敏捷的四个核心价值观是(LCTT 译注:此处译文同样来自敏捷软件开发宣言官方):

  • 个体和互动 高于流程和工具
  • 工作的软件 高于详尽的文档
  • 客户合作 高于合同谈判
  • 响应变化 高于遵循计划

这与瀑布流程死板的计划风格相反。在敏捷流程中,客户是开发团队的一员,而不仅仅是在项目开始时参与项目需求的定义,在项目结束时验收最终的产品。客户帮忙团队完成验收标准,并在整个过程中保持投入。另外,敏捷需要整个组织的变化和持续的改进。开发团队和其他团队一起合作,包括项目管理团队和测试团队。做什么和计划什么时候做由指定的角色领导,并由整个团队同意。

敏捷软件开发

敏捷软件开发需要自适应的规划、演进式的开发和交付。许多软件开发方法、框架和实践遵从敏捷的理念,包括:

  • Scrum
  • 看板 Kanban (可视化工作流)
  • 极限编程 Xtreme Programming (XP)
  • 精益方法 Lean
  • DevOps
  • 特性驱动开发 Feature-Driven Development (FDD)
  • 测试驱动开发 Test-Driven Development (TDD)
  • 水晶方法 Crystal
  • 动态系统开发方法 Dynamic Systems Development Method (DSDM)
  • 自适应软件开发 Adaptive Software Development (ASD)

所有这些已经被单独用于或一起用于开发和部署软件。最常用的是 Scrum、看板(或 Scrumban)和 DevOps。

Scrum 是一个框架,采用该框架的团队通常由一个 Scrum 教练、产品经理和开发人员组成,该团队以跨职能、自主的工作方式运作,能够加快软件交付速度从而给客户带来巨大的商业价值。其关注点是较小增量的快速迭代。

看板 是一个敏捷框架,有时也叫工作流管理系统,它能帮助团队可视化他们的工作从而最大化效率(因而变得敏捷)。看板通常由数字或物理展示板来呈现。团队的工作在展示板上随着进度而移动,例如从未启动到进行中,一直到测试中、已完成。看板使得每个团队成员可以随时查看到所有工作的状态。

DevOps 价值观

DevOps 是一种文化,是一种思维状态,是一种软件开发的方式或者基础设施的方式,也是一种构建和部署软件和应用的方式。它假设开发和运维之间没有隔阂,他们一起合作,没有矛盾。

DevOps 基于其它两个领域的实践: 精益和敏捷。DevOps 不是一个公司内的岗位或角色;它是一个组织或团队对持续交付、持续部署和持续集成的坚持不懈的追求。Gene Kim(Phoenix 项目和 Unicorn 项目的作者)认为,有三种方式定义 DevOps 的理念:

  • 第一种: 流程原则
  • 第二种: 反馈原则
  • 第三种: 持续学习原则

DevOps 软件开发

DevOps 不会凭空产生;它是一种灵活的实践,它的本质是一种关于软件开发和 IT 或基础设施实施的共享文化和思维方式。

当你想到自动化、云、微服务时,你会想到 DevOps。在一次访谈中,《加速构建和扩张高性能技术组织》的作者 Nicol Forsgren、Jez Humble 和 Gene Kim 这样解释到:

  • 软件交付能力很重要,它极大地影响到组织的成果,例如利润、市场份额、质量、客户满意度以及组织战略目标的达成。
  • 优秀的团队能达到很高的交付量、稳定性和质量;他们并没有为了获得这些属性而进行取舍。
  • 你可以通过实施精益、敏捷和 DevOps 中的实践来提升能力。
  • 实施这些实践和能力也会影响你的组织文化,并且会进一步对你的软件交付能力和组织能力产生有益的提升。
  • 懂得怎样改进能力需要做很多工作。

DevOps 和敏捷的对比

DevOps 和敏捷有相似性,但是它们不完全相同,一些人认为 DevOps 比敏捷更好。为了避免造成混淆,深入地了解它们是很重要的。

相似之处

  • 毫无疑问,两者都是软件开发技术。
  • 敏捷已经存在了 20 多年,DevOps 是最近才出现的。
  • 两者都追求软件的快速开发,它们的理念都基于怎样在不伤害客户或运维利益的情况下快速开发出软件。

不同之处

  • 两者的差异在于软件开发完成后发生的事情。

    • 在 DevOps 和敏捷中,都有软件开发、测试和部署的阶段。然而,敏捷流程在这三个阶段之后会终止。相反,DevOps 包括后续持续的运维。因此,DevOps 会持续的监控软件运行情况和进行持续的开发。
  • 敏捷中,不同的人负责软件的开发、测试和部署。而 DevOps 工程角色负责所有活动,开发即运维,运维即开发。
  • DevOps 更关注于削减成本,而敏捷则是精益和减少浪费的代名词,侧重于像敏捷项目会计和最小可行产品的概念。
  • 敏捷专注于并体现了经验主义(适应、透明和检查),而不是预测性措施。
敏捷DevOps
从客户得到反馈从自己得到反馈
较小的发布周期较小的发布周期,立即反馈
聚焦于速度聚焦于速度和自动化
对业务不是最好对业务最好

总结

敏捷和 DevOps 是截然不同的,尽管它们的相似之处使人们认为它们是相同的。这对敏捷和 DevOps 都是一种伤害。

根据我作为一名敏捷专家的经验,我发现对于组织和团队从高层次上了解敏捷和 DevOps 是什么,以及它们如何帮助团队更高效地工作,更快地交付高质量产品从而提高客户满意度非常有价值。

敏捷和 DevOps 绝不是对抗性的(或至少没有这个意图)。在敏捷革命中,它们更像是盟友而不是敌人。敏捷和 DevOps 可以相互协作一致对外,因此可以在相同的场合共存。


via: https://opensource.com/article/20/2/devops-vs-agile

作者:Taz Brown 选题:lujun9972 译者:messon007 校对:wxy

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

GNOME 3.34 发布 6 个月后,最新版本的 GNOME 3.36 代号为 “Gresik” 也最终发布了。不仅是添加了功能,GNOME 3.36 还改进了许多我们需要的功能。

在本文中,我将重点介绍 GNOME 新版本的主要更改。

GNOME 3.36 的关键改进

如果你想快速了解发生了什么变化,可以看以下官方视频:

现在,让我分别重点介绍最新版本中的更改:

GNOME Shell 扩展应用

你可以通过专门的“扩展”程序轻松管理 GNOME Shell 的扩展。

因此,你可以使用该程序更新、配置、删除或禁用现有扩展。

切换到请勿打扰(DND)

你可能已经在 Pop!\_OS 或其他 Linux 发行版中注意到了它。

但是,GNOME 3.36 现在在通知弹出区域中实现了 DND 切换。除非你将其关闭,否则不会收到任何通知。

锁屏改进

在新版本中,锁定屏幕在输入凭据之前没有额外的动画。取而代之会在登录屏幕直接打招呼。

另外,为了提升一致性,锁屏背景将是墙纸的模糊版本。

总的来说,对锁屏的改进旨在使之更易于访问,同时改善其外观/感觉。

视觉变化

包含了一些明显的新增,这些设计更改改善了 GNOME 3.36 的总体外观。

从图标的重新设计到文件夹和系统对话框,进行了许多小的改进以增强 GNOME 3.36 的用户体验。

此外,设置应用已进行了调整,通过微小的界面重新设计,使得选项访问更加容易。

主要性能改进

GNOME 声称,此更新还提升了 GNOME 桌面的性能。

当使用装有 GNOME 3.36 的发行版时,你会注意到在性能上有明显的不同。无论是动画、重新设计还是微小的调整,对于 GNOME 3.36 所做的一切都会对用户的性能产生积极影响。

其他更改

除了上述关键更改之外,还有很多其他改进,例如:

  • 时钟重新设计
  • 用户文档更新
  • GNOME 安装助手改进

还有许多其他更改。你可以查看官方发布说明了解更多信息。

如何获取 GNOME 3.36?

即使 GNOME 3.36 已正式发布。Linux 发行版可能需要一段时间才能让你轻松升级 GNOME 体验。

Ubuntu 20.04 LTS 将提供最新版本 GNOME。你可以等待。

其他流行的 Linux 发行版,如 Fedora、OpenSuse、Pop!\_OS,应该会很快包含 GNOME 3.36。Arch Linux 已升级到 GNOME 3.36。

我建议你耐心等待,直到获得发行版本的更新。不过,你可以查看源代码或尝试即将发布的流行发行版的开发版本,这些发行版可能有 GNOME 3.36。

你如何看待 GNOME 3.36?在下面的评论中让我知道你的想法。


via: https://itsfoss.com/gnome-3-36-release/

作者:Ankush Das 选题:lujun9972 译者:geekpi 校对:wxy

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

在冠状病毒爆发期间,我们中的许多人都在室内自我隔离。ZDNet 特此与 Linus Torvalds 进行了专题采访,讨论了他对冠状病毒禁足期间在家工作的看法或想法。

如果你还不知道(怎么可能不知道),Linus Torvalds 是 Linux 的创建者,也是 Git 的创建者,而所有这一切都是他在家里工作时做的。这是 2016 年的视频,Torvalds 展示了他的家庭办公室:

因此,在本文中,我将分享我关注的一些主要要点,以及来自 Linus Torvalds 接受 ZDNet Steven J. Vaughan-Nichols 采访互动时的回应。

消除对人际交往缺失的恐惧

Linus 提到,几年前刚开始在家工作时,他担心过缺少人与人之间的互动,包括去办公室、与人互动或哪怕只是出去吃个午餐。

有趣的是,他似乎并没有错过任何东西,他更喜欢在家中没有人际交往的时间。

当然,将自己与人际互动隔离开并不是最好的事情 ,但在目前看来,这是一件好事。

利用在家工作的优势

就像我们是完全远程操作一样,你可以做很多事情,而无需实际在办公室。

不要忘记,你可以随心所欲地养猫,我有 6 只猫,我知道这很困难(哈哈)。

而且,正如 Linus 所提到的,远程工作的真正优势在于“灵活性”。你不一定需要朝九晚五甚至更长的时间坐在办公桌前。从技术上讲,你可以在工作中自由休息,并在家中做你想做的任何事情。

换句话说,Linus 建议不要在你的家中重新搞一个办公室,这比去办公室还差。

高效沟通是关键

虽然你可以在一天之中召开几次会议(视频会议或音频呼叫),但这真的有必要吗?

对于某些人来说,这可能很重要,但是你应该通过简化和整理内容来尽量减少会议花费的时间。

或者,按照 Linus 的建议,最好有个电子邮件列表来记录事情,以确保一切各司其职,这就是 Linux 内核 的运行方式。

James Bottomley 是 IBM 研究院的杰出工程师,也是资深 Linux 内核开发人员,他也建议你重新阅读你的文字以确保发送的准确信息不会被人不小心跳过。

就个人而言,出于同样的原因,我更喜欢文本而不是语音。实际上,它可以节省你的时间。

但是,请记住,你需要只以适当的方式传达必要的信息,而不要使通过文本/电子邮件发送的信息过载。

追踪你的时间

灵活性并不一定意味着你可以减少工作量并泡在社交媒体平台上,除非那就是你的工作。

因此,你需要确保充分利用自己的时间。为此,你可以使用多种工具来跟踪你的时间用在什么地方,以及在计算机上花费的时间。

你甚至可以将其记录在便签上,以确保你可以将时间高效地分配于工作上。你可以选择使用 RescueTimeActivityWatch 来跟踪你在计算机或智能手机上花费的时间。

和猫(宠物)一起玩

不歧视其他宠物,但这就是 Linus Torvalds 提到的。

正因为你在家中,你在安排工作或尝试有效利用时间时要做的事情有很多。

Linus 坚持认为,每当你感到无聊时,可以在必要时出门获取必需品,也可以与猫(或你的其它宠物)一起玩。

结语

虽然 Linus 还提到了当你在家时没人会评判你,但他的建议似乎是正确的,对于那些在家工作的人来说可能很有用。

不仅是因为冠状病毒的爆发,而且如果你打算一直在家工作,应该牢记这些。

你如何看待 Linus 的看法呢?你同意他的观点吗?


via: https://itsfoss.com/torvalds-remote-work-advice/

作者:Ankush Das 选题:lujun9972 译者:wxy 校对:wxy

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