分类 观点 下的文章

韩国一家开发了 Hancom Office 办公软件的公司在其字处理软件中集成了开源软件 Ghostscript,但是没有遵守 Ghostscript 的 GNU GPL 许可证而开源,也没有为该软件付费。近日,该韩国公司被美国联邦法院裁定其违约。

Ghostscript 是一个开源软件,由 Artifex 公司开发,其采用了两种许可证:

  • GNU GPL 许可证
  • 商业付费许可证

如果要免费使用 Ghostscript,Hancom 就需要遵循该软件的开源许可证,即 GNU GPL。该许可证要求,如果你的软件中使用了采用该许可协议的软件,并公开发布的话,就需要也采用同样的 GNU GPL 许可证开源。也就是说, Hancom 需要开源其整个办公软件套件。

否则,Hancom 就需要向 Ghostscript 的开发商 Artifex 公司支付商业许可证费用。Artifex 允许商业或其它闭源软件开发商绕开严格的开源许可证 GNU GPL,只要付费就行。

但是 Hancom 从 2013 年在其软件中使用了 Ghostscript 之后,却什么都没做:既没有开源其软件,也没有向 Artifex 公司付商业许可证的费用。

在 2016 年底,交涉无果的 Artifex 公司向美国加利福尼亚北部地区法院发起了诉讼。

“在发现 Hancom 违反了 GNU GPL 许可证,侵犯了 Artifex 的 Ghostscript 的宝贵版权之后,Artifex 要求 Hancom 停止其侵权行为,并为其多年无版权使用 Ghostscript 支付合理的版权费用,”该公司陈述到,“Hancom 拒绝了该要求,Artifex 转而寻求本法院责令 Hancom 停止进一步侵权并支付其滥用 Artifex 的开源许可证的费用。”

Artifex 还提到 Hancom 在 2015 年收入了 8630 万美元。

像 GUN GPL 这样的开源许可证的可执行性长期以来一直是一个悬而未决的法律问题。美国联邦巡回法庭在 2006 年的一个判例,雅各布森诉卡泽尔案中,对开源许可证的侵犯裁定可视作对版权申明的处理。但是在本案之前,这种侵犯开源许可证是否可以依法视作侵犯合约并未裁定。

Hancom 尝试发起动议以驳回该诉讼,其认为该公司并未签署任何东西,所以该许可证并不是真正的合约。

“并不是这样”,杰奎琳·斯科特·科里法官在 4 月 25 日的议案中说。她说 GNU GPL “规定了如果用户没有获取商业许可证,即表示同意其条款。原告称被告没有获取商业许可证,并公开表明其在 GNU GPL 下使用 Ghostscript。这些指控足以为合约的存在而辩护。”

科里法官驳回了 Hancom 的动议。按照这样的做法,就树立了像 GNU GPL 这样的开源许可证可以被视作法律合约的先例,在开发商违反了开源许可证时会被起诉。这对于开源社区来说是一个重大胜利。

当然,Artifex 是否可以最终赢得这一诉讼,还要看后继的上诉和裁定。

这种改变使得在 AWS 上实施甲骨文的软件的价格翻了一番,它已经安静地生效了,而几乎没有通知用户。

之前有消息传出,甲骨文使亚马逊云上的产品价格翻了一倍。它在如何计算 AWS 的虚拟 CPU 上耍了一些花招。它这么做也没有任何宣扬。该公司的新定价政策于 1 月 23 日生效,直到 1 月 28 日都几乎没有被人注意到, 甲骨文的关注者 Tim Hall 偶然发现 Big Red 公司的 甲骨文软件云计算环境许可文件并披露了出来。

乍一看,这一举动似乎并不太大,因为它仅将甲骨文的 AWS 定价与 Microsoft Azure 的价格相提并论。但是 Azure 只有市场领先的 AWS 体量的三分之一,所以如果你想在云中销售许可证,AWS 是合适的地方。虽然此举可能或可能不会影响已经在 AWS 上使用甲骨文产品的用户,但是尚不清楚新规则是否适用于已在使用产品的用户 - 它肯定会让一些考虑可能使用甲骨文的用户另寻它处。

这个举动的主要原因是显而易见的。甲骨文希望使自己的云更具吸引力 - 这让 The Register 观察到一点:“拉里·埃里森确实承诺过甲骨文的云将会更快更便宜”。更快和更便宜仍然有待看到。如果甲骨文的 SPARC 云计划启动,并且按照广告的形式执行,那么可能会更快,但是更便宜的可能性较小。甲骨文以对其价格的强硬态度而著称。

随着其招牌数据库和业务栈销售的下滑,并且对 Sun 公司的 74 亿美元的投资并未能按照如期那样,甲骨文将其未来赌在云计算上。但是甲骨文来晚了,迄今为止,它的努力似乎还没有结果, 一些金融预测者并没有看到甲骨文云的光明前景。他们说,云是一个拥挤的市场,而四大公司 - 亚马逊、微软、IBM 和谷歌 - 已经有了领先优势。

确实如此。但是甲骨文面临的最大的障碍是,好吧,就是甲骨文。它的声誉在它之前。

保守地说这个公司并不是因为明星客户服务而闻名。事实上,各种新闻报道将甲骨文描绘成一个恶霸和操纵者。

例如,早在 2015 年,甲骨文就因为它的云并不像预期那样快速增长而越来越沮丧,开始激活业内人士称之为的“核特权”。它会审核客户的数据中心,如果客户不符合规定,将发出“违规通知” - 它通常只适用于大规模滥用情况,并命令客户在 30 天内退出使用其软件。

或许你能想到,大量投入在甲骨文软件平台上的大公司们绝对不能在短时间内迁移到另一个解决方案。甲骨文的违规通知将会引发灾难。

商业内幕人士 Julie Bort 解释到:“为了使违规通知消失 - 或者减少高额的违规罚款 - 甲骨文销售代表通常希望客户向合同中添加云额度”。

换句话说,甲骨文正在使用审计来扭转客户去购买它的云,而无论他们是否有需要。这种策略与最近 AWS 价格翻倍之间也可能存在联系。Hall 的文章的评论者指出,围绕价格提升的秘密背后的目的可能是触发软件审计。

使用这些策略的麻烦迟早会出来。消息一旦传播开来,你的客户就开始寻找其他选项。对 Big Red 而言或许是时候参考微软的做法,开始建立一个更好和更温和的甲骨文,将客户的需求放在第一位。

(题图:windowsitpro


via: http://windowsitpro.com/cloud/oracle-policy-change-raises-prices-aws

作者:Christine Hall 译者:geekpi 校对:wxy

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

一些令人振奋的消息引发了我对今年 DockerCon 的兴趣,在这次会议中,无可争议的容器巨头公司 Docker 发布了一个新的操作系统:LinuxKit。

这家容器巨头宣布的是一个灵活的、可扩展的操作系统,而为了可移植性,系统服务也是运行在容器之中。甚至,令人惊讶的是,就连 Docker 运行时环境也是运行在容器内!

在本文中,我们将简要介绍一下 LinuxKit 中所承诺的内容,以及如何自己尝试一下这个不断精简、优化的容器。

少即是多

不可否认的是,用户一直在寻找一个可以运行他们的微服务的精简版本的 Linux 。通过容器化,你会尽可能地最小化每个应用程序,使其成为一个适合于运行在其自身容器内的独立进程。但是,由于你需要对那些驻留容器的宿主机出现的问题进行修补,因此你不断地在宿主机间移动容器。实际上,如果没有像 Kubernetes 或 Docker Swarm 这样的编排系统,容器编排几乎总是会导致停机。

不用说,这只是让你保持操作系统尽可能小的原因之一。

我曾多次在不同场合重复过的最喜爱的名言,来自荷兰的天才程序员 Wietse Zweitze,他为我们提供了重要的 Email 软件 Postfix 和 TCP Wrappers 等知名软件。

Postfix 网站 指出,即使你编码和 Wietse 一样小心,“每 1000 行[你]就会在 Postfix 中引入一个额外的 bug”。从我的专业的 DevSecOps 角度看,这里提到的“bug” 可以将其大致看做安全问题。

从安全的角度来看,正是由于这个原因,代码世界中“少即是多”。简单地说,使用较少的代码行有很多好处,即安全性、管理时间和性能。对于初学者来说,这意味着安全漏洞较少,更新软件包的时间更短,启动时间更快。

深入观察

考虑下在容器内部运行你的程序。

一个好的起点是 Alpine Linux,它是一个苗条、精简的操作系统,通常比那些笨重的系统更受喜欢,如 Ubuntu 或 CentOS 等。Alpine 还提供了一个 miniroot 文件系统(用于容器内),最近我看到的大小是惊人的 1.8M。事实上,这个完整的 Linux 操作系统下载后有 80M。

如果你决定使用 Alpine Linux 作为 Docker 基础镜像,那么你可以在 Docker Hub 上找到一个, 它将其描述为:“一个基于 Alpine Linux 的最小 Docker 镜像,具有完整的包索引,大小只有5 MB!”

据说无处不在的 “Window 开始菜单” 文件也是大致相同的大小!我没有验证过,也不会进一步评论。

讲真,希望你去了解一下这个创新的类 Unix 操作系统(如 Alpine Linux)的强大功能。

锁定一切

再说一点,Alpine Linux 是(并不惊人)基于 BusyBox,这是一套著名的打包了 Linux 命令的集合,许多人不会意识到他们的宽带路由器、智能电视,当然还有他们家庭中的物联网设备就有它。

Alpine Linux 站点的“关于”页面的评论中指出:

“Alpine Linux 的设计考虑到安全性。内核使用 grsecurity/PaX 的非官方移植进行了修补,所有用户态二进制文件都编译为具有堆栈保护的地址无关可执行文件(PIE)。 这些主动安全特性可以防止所有类别的零日漏洞和其它漏洞利用。”

换句话说,这些捆绑在 Alpine Linux 中的精简二进制文件提供的功能通过了那些行业级安全工具筛选,以缓解缓冲区溢出攻击所带来的危害。

多只袜子

你可能会问,为什么当我们谈及 Docker 的新操作系统时,容器的内部结构很重要?

那么,你可能已经猜到,当涉及容器时,他们的目标是精简。除非绝对必要,否则不包括任何东西。所以你可以放心地清理橱柜、花园棚子、车库和袜子抽屉了。

Docker 的确因为它们的先见而获得声望。据报道,2 月初,Docker 聘请了 Alpine Linux 的主要推动者 Nathaniel Copa,他帮助将默认的官方镜像库从 Ubuntu 切换到 Alpine。Docker Hub 从新近精简镜像节省的带宽受到了赞誉。

并且最新的情况是,这项工作将与最新的基于容器的操作系统相结合:Docker 的 LinuxKit。

要说清楚的是 LinuxKit 注定不会代替 Alpine,而是位于容器下层,并作为一个完整的操作系统出现,你可以高兴地启动你的运行时守护程序(在这种情况下,是生成你的容器的Docker 守护程序 )。

原子计划

经过精心调试的宿主机绝对不是一件新事物(以前提到过嵌入式 Linux 的家用设备)。在过去几十年中一直在优化 Linux 的天才在某个时候意识到底层的操作系统才是快速生产含有大量容器主机的关键。

例如,强大的红帽长期以来一直在出售已经贡献给 Project Atomic红帽 Atomic 。后者继续解释:

“基于 Red Hat Enterprise Linux 或 CentOS 和 Fedora 项目的成熟技术,Atomic Host 是一个轻量级的、不可变的平台,其设计目的仅在于运行容器化应用程序。”

将底层的、不可变的 Atomic OS 作为红帽的 OpenShift PaaS(平台即服务)产品推荐有一个很好理由:它最小化、高性能、尖端。

特性强大

在 Docker 关于 LinuxKit 的公告中,“少即是多”的口号是显而易见的。实现 LinuxKit 愿景的项目显然是不小的事业,它由 Docker 老将和 Unikernel 的主管 Justin Cormack 指导,并与 HPE、Intel、ARM、IBM 和 Microsoft LinuxKit 合作,可以运行在从大型机到基于物联网的冰柜之中。

LinuxKit 的可配置性、可插拔性和可扩展性将吸引许多寻求建立其服务基准的项目。通过开源项目,Docker 明智地邀请每个人全身心地投入其功能开发,随着时间的推移,它会像好的奶酪那样成熟。

布丁作证

按照该发布消息中所承诺的,那些急于使用新系统的人不用再等待了。如果你准备着手 LinuxKit,你可以从 GitHub 中开始:LinuxKit

在 GitHub 页面上有关于如何启动和运行一些功能的指导。

时间允许的话我准备更加深入研究 LinuxKit。对有争议的 Kubernetes 与 Docker Swarm 编排功能对比会是有趣的尝试。此外,我还想看到内存占用、启动时间和磁盘空间使用率的基准测试。

如果该承诺可靠,则作为容器运行的可插拔系统服务是构建操作系统的迷人方式。Docker 在博客)中提到:“因为 LinuxKit 是原生容器,它有一个非常小的尺寸 - 35MB,引导时间非常小。所有系统服务都是容器,这意味着可以删除或替换所有的内容。”

我不知道你觉得怎么样,但这非常符合我的胃口。

呼叫警察

除了我站在 DevSecOps 角度看到的功能,我会看看其对安全的承诺。

Docker 在他们的博客上引用来自 NIST(国家标准与技术研究所)的话:

“安全性是最高目标,这与 NIST 在其《应用程序容器安全指南》草案中说明的保持一致:‘使用容器专用操作系统而不是通用操作系统来减少攻击面。当使用专用容器操作系统时,攻击面通常比通用操作系统小得多,因此攻击和危及专用容器操作系统的机会较少。’”

可能最重要的容器到主机和主机到容器的安全创新是将系统容器(系统服务)完全地沙箱化到自己的非特权空间中,而只给它们需要的外部访问。

通过 内核自我保护项目 Kernel Self Protection Project KSPP)的协作来实现这一功能,我很满意 Docker 开始专注于一些非常值得的东西上。对于那些不熟悉的 KSPP 的人而言,它存在理由如下:

“启动这个项目的的假设是内核 bug 的存在时间很长,内核必须设计成可以防止这些缺陷的危害。”

KSPP 网站进一步表态:

“这些努力非常重要并还在进行,但如果我们要保护我们的十亿 Android 手机、我们的汽车、国际空间站,还有其他运行 Linux 的产品,我们必须在上游的 Linux 内核中建立积极的防御性技术。我们需要内核安全地出错,而不只是安全地运行。”

而且,如果 Docker 最初只是在 LinuxKit 前进了一小步,那么随着时间的推移,成熟度带来的好处可能会在容器领域中取得长足的进步。

终点还远

像 Docker 这样不断发展壮大的巨头无论在哪个方向上取得巨大的飞跃都将会用户和其他软件带来益处。

我鼓励所有对 Linux 感兴趣的人密切关注这个领域。


via: http://www.devsecops.cc/devsecops/containers.html

作者:Chris Binnie 译者:geekpi 校对:wxy

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

你想成为开源项目中得意满满、功成名就的那个人吗,那就要遵守下面的“潜规则”。

正如体育界不成文的规定一样,这些规则基本上不会出现在官方文档和正式记录上。比如说,在棒球运动中,从比分领先时不要盗垒,到跑垒员跑了第一时也不要放弃四坏球保送。对于圈外人来讲,这些东西很难懂,甚至觉得没什么意义。但是对于那些想成为 MVP 的队员来说,这些都是理所当然的。

软件开发,特别是开源软件开发中,也有一套不成文的规定。和其它的团队运动一样,这些规定很大程度上决定了开源社区如何看待一名开发者,特别是新加入社区的开发者。

按部就班,循序渐进

在参与社区之前,比如开放源代码或者其它什么的,你需要做一些基本工作。对于有眼界的开源贡献者,这意味这你需要理解社区的目标,并学习应该从哪里起步。人人都想贡献源代码,但是只有少量的人做过准备,并且乐意、同时也有能力完成这项艰苦卓绝的工作:测试补丁、复审代码、撰写文档、修正错误。所有的这些不受待见的任务在一个健康的社区中都是必要的。

为什么要在优雅地写代码前做这些呢?这是一种信任,更重要的是,不要只关注自己开发的功能,而是要关注整个社区的动向。

博闻强识,敦善不怠

当你在某个社区中建立起自己的声望,那么很有必要全面了解该项目和代码。不要停留于任务状态上,而是要去钻研项目本身,理解那些超出你擅长范围之外的知识。不要只把自己的理解局限于开发者,这样会让你着眼于让你的代码有更大的影响,而不只是你那一亩三分地。

打个比方,你已经完成了一个网络模块的测试版本。你测试了一下,觉得不错。然后你把它开放到社区,想要更多的人测试。结果发现,当它以特定的方式部署时,有可能会破坏安全设置,还可能导致主存储泄露。如果你将代码视为一个整体时问题就可以迎刃而解,而不是孤立地看待问题。这表明,你要对项目各个部分如何与其他人协作交互有比较深入的理解。让你的补丁填坑而不是挖坑。这样你朝成为社区精英的目标上又前进了一大步。

粗枝大叶,自寻烦恼

代码提交完毕后你的工作还没结束。如果代码被接受,还会有一些关于这些更改的讨论和常见的问答,还要做测试。你要确保你可以准时提交,努力去理解如何在不影响社区其他成员的情况下,改进代码和补丁。

和谐相处,助人助己

开源社区不是自相残杀的丛林世界,我们更看重项目的价值而非个体的贡献和成功。如果你想给自己加分,让自己成为更重要的社区成员、让社区接纳你的代码,那就努力帮助别人。如果你熟悉网络部分,那就去复审网络部分,用你的专业技能让整个代码更加优雅。道理很简单,顶级的审查者经常和顶级的贡献者打交道。你帮助的人越多,你就越有价值。

八面玲珑,面面俱到

作为一个开发者,你很可能希望为开源项目解决一个特定的痛点。或许你想要运行在一个目前还不支持的系统上,抑或你很希望改革社区目前使用的安全技术。想要引进新技术,特别是比较有争议的技术,最好的办法就是让人无法拒绝它。你需要透彻地了解底层代码,考虑每个极端情况。在不影响已实现功能的前提下增加新功能。不仅仅是完成就行,还要在特性的完善上下功夫。

糜不有初,鲜克有终

开源社区也有许多玩玩就算的人,但是承诺了就不要轻易失信。不要就因为提交被拒就离开社区。找出原因,修正错误,然后再试一试。当你开发时候,要和整个代码库保持一致,确保即使项目发生变化而你的补丁仍然可用。不要把你的代码留给别人修复,要自己修复。这样可以在社区形成良好的风气,每个人都自己改。


这些“潜规则”看上去很简单,但是还是有许多开源项目的贡献者并没有遵守。这样做的开发者不仅可以为成功地推动他们自己的项目,而且也有助于开源社区。

作者简介:

Matt Hicks 是 Red Hat 软件工程的副主席,也是 Red Hat 开源合作团队的奠基成员之一。他历时十五年,在软件工程中担任多种职务:开发,运行,架构,管理。


via: http://www.infoworld.com/article/3156776/open-source-tools/the-6-unwritten-rules-of-open-source-development.html

作者:Matt Hicks 译者:Taylor1024 校对:wxymartin2011qi

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

现有的技术无法对微芯片进行有效的冷却,这正快速成为摩尔定律消亡的第一原因。

随着对数字计算速度的需求,科学家和工程师正努力地将更多的晶体管和支撑电路放在已经很拥挤的硅片上。的确,它非常地复杂,然而,和复杂性相比,热量聚积引起的问题更严重。

洛克希德马丁公司首席研究员 John Ditri 在新闻稿中说到:当前,我们可以放入微芯片的功能是有限的,最主要的原因之一是发热的管理。如果你能管理好发热,你可以用较少的芯片,也就是说较少的材料,那样就可以节约成本,并能减少系统的大小和重量。如果你能管理好发热,用相同数量的芯片将能获得更好的系统性能。

硅对电子流动的阻力产生了热量,在如此小的空间封装如此多的晶体管累积了足以毁坏元器件的热量。一种消除热累积的方法是在芯片层用光子学技术减少电子的流动,然而光子学技术有它的一系列问题。

参见: 2015 年硅光子将引起数据中心的革命

微流冷却技术可能是问题的解决之道

为了寻找其他解决办法,美国国防高级研究计划局 DARPA 发起了一个关于 ICECool 应用 (片内/片间增强冷却技术)的项目。 GSA 的网站 FedBizOpps.gov 报道:ICECool 正在探索革命性的热技术,其将减轻热耗对军用电子系统的限制,同时能显著减小军用电子系统的尺寸,重量和功耗。

微流冷却方法的独特之处在于组合使用片内和(或)片间微流冷却技术和片上热互连技术。

MicroCooling 1 Image: DARPA

DARPA ICECool 应用发布的公告 指出,这种微型片内和(或)片间通道可采用轴向微通道、径向通道和(或)横流通道,采用微孔和歧管结构及局部液体喷射形式来疏散和重新引导微流,从而以最有利的方式来满足指定的散热指标。

通过上面的技术,洛克希德马丁的工程师已经实验性地证明了片上冷却是如何得到显著改善的。洛克希德马丁新闻报道:ICECool 项目的第一阶段发现,当冷却具有多个局部 30kW/cm2 热点,发热为 1kw/cm2 的芯片时热阻减少了 4 倍,进而验证了洛克希德的嵌入式微流冷却方法的有效性。

第二阶段,洛克希德马丁的工程师聚焦于 RF 放大器。通过 ICECool 的技术,团队演示了 RF 的输出功率可以得到 6 倍的增长,而放大器仍然比其常规冷却的更凉。

投产

出于对技术的信心,洛克希德马丁已经在设计和制造实用的微流冷却发射天线。 洛克希德马丁还与 Qorvo 合作,将其热解决方案与 Qorvo 的高性能 GaN 工艺 相集成。

研究论文 DARPA 的片间/片内增强冷却技术(ICECool)流程 的作者认为 ICECool 将使电子系统的热管理模式发生改变。ICECool 应用的执行者将根据应用来定制片内和片间的热管理方法,这个方法需要兼顾应用的材料,制造工艺和工作环境。

如果微流冷却能像科学家和工程师所说的成功的话,似乎摩尔定律会起死回生。

(题图:iStock/agsandrew)


via: http://www.techrepublic.com/article/microfluidic-cooling-may-prevent-the-demise-of-moores-law/

作者:Michael Kassner 译者:messon007 校对:wxy

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