2016年7月

微软在 Linux 世界变得越来越活跃了,在它说将发布一个“让 Linux 用户激动的新闻”后,该公司又宣布了一个旨在增强其在云市场方面领导地位的另外一个合作关系。

今天,这个软件巨人宣布了和 SUSE Linux 的新的合作关系,以延续他们在公有云服务方面的合作,这是这两个公司在今年发布的首次公告。

新的合作关系更新了一些条款和承诺,但是暂时还未对外公布细节。

之前微软和 SUSE Linux 之间的合作签署于 2006 年,其时 SUSE Linux 这家德国公司还隶属于 Novell,而微软还被 Linux 世界视为凶猛的敌人。在 2001 年时,时任微软 CEO 的史蒂夫·鲍尔默因其将 Linux 称之为“附身于知识产权之上,感染其所接触到的一切的癌症”的言论,而挑起了微软和开源界之间的长久战争。

史蒂夫·鲍尔默现在爱 Linux!

但是时代改变了,现在微软投入数以百万计的美元来接近 Linux 世界,SUSE 的公有云全球联盟总监 Kristin Kinan 说,最近微软在Linux 方面的营收有了明显提升。

她说,“微软的公有云业务上为客户提供了 Linux 服务, Linux 的占比增长到了 22% 至 25%。他们在开源解决方案方面的投资、销售主动性和合作力度超出了我们的预期。”

此前,微软前 CEO 史蒂夫·鲍尔默收回了他之前称 Linux 是癌症的说法,说“现在我爱它”,并指出那时微软与开源世界斗争是正确的,这为微软带来了数以百万计的美金。

毫无疑问,新 CEO 萨提亚·纳德拉很热衷于微软的云业务,因此这种合作关系得以延续,显然,微软在 Linux 世界的投入还将继续增加。

沉默了九个月之后,自去年十月份的 Java One 大会之后一直没有对 Java EE 的发展停滞进行回应的甲骨文终于对外透露了该公司在 Java EE 方面的发展计划。

正如之前 arstechnica 的报道中所说,自去年秋天伊始,甲骨文在 Java EE 项目上的开发投入就已经几乎完全停止了,该公司不但将该项目上的工程师们投入到了其它项目当中,而且对社区的意见和请愿视若不闻,将 Java 社区进程 Java Community Process (JCP)执行委员会的成员们和 Java EE 的合作伙伴们丢在了深深绝望之中。

据 Java EE 守护者的观察,甲骨文在其自己的 JavaServer Faces 开发上的几个月前就陷入了完全停止,如下图:

甲骨文在其自己的 JSF 实现上的提交数变化

甲骨文在其自己的 JSF 实现上的解决问题数的变化

此事经由 arstechnica 报道之后,在整个技术世界引来了巨大反响。作为对这些质疑和请愿的回应,甲骨文的发言人 Mike Moeller 通过邮件发布了下述申明:

甲骨文致力于 Java 的发展,已经制定好了 Java EE 规范的下一个版本 Java EE 8 草案。 Java EE 8 将支持那些寻求在大规模分布式计算和基于容器的云环境中设计使用微服务来构建新应用的开发者们。甲骨文正在与 Java 社区中的关键合作伙伴们密切合作,以最终推出该草案,并将在九月份的 Java One 大会上与广大的 Java 社区分享该草案的完整细节。

按其说法,甲骨文将于今年九月份在旧金山召开的 Java One 大会上发布相关信息,并于 2017 年上半年发布 Java EE 8

当被问及“关键合作伙伴”是否是同时指 JCP、 Java EE 专家组 Java EE Expert Group 和特定的行业合作伙伴时,甲骨文的一位发言人回应道并不全是。该发言人说,该草案很显然需要在 Java 社区内进行讨论,这包括 Java EE 专家组以及 JCP 内的更多成员,甲骨文希望得到更多的反馈。

Java 社区的一些开发人员对此表示了惊喜和疑虑。不过总体来说该申明所带来的消息还是比较乐观的,这表示甲骨文最终对 Java 社区的意见进行了澄清。这也许是对 Java EE 守护者 Java EE Guardians 请愿投票的回应,截止至 7 月 7 日,该请愿已经得到了超过 2700 位开发者的支持。

“这真是一件令人惊喜的好消息。我们非常高兴甲骨文听到了社区的声音,并努力去寻求解决方案。“前甲骨文雇员、Java 专家,也是现在 Java EE 守护者的发言人 Reza Rahman 对甲骨文的回应表示了感谢,他说,”我们希望甲骨文可以将 Java EE 当成一个标准而不是一个产品,从而取得进一步的发展。……社区应当将此视为继续建设性地伴随甲骨文前进的一个机会,我们需要彼此密切配合以造福 Java 和 Java EE 生态,希望 Java EE 8 的发展计划可以在包括 Java 社区在内的广泛的合作中完整达成。”

一位 Java EE 的开发者及作者 Josh Juneau 说,“这是正确的一步,甲骨文最终就 Java EE 发布了申明。”,但是他又说,“我们需要谨慎从事,通过 Java EE 守护者继续推进,以帮助社区紧密参与到 Java EE 的发展当中。”

Josh Juneau 也有些担心甲骨文申明中提及的新方向可能会影响到 Java EE 8 已经取得的一些进展,“我们需要继续发出声音,推进 Java EE 8 的每个 JSR (Java 规范请求)的发展,让甲骨文知道它们每个都很重要。我们不希望看到甲骨文缩减范围,丢掉一些 JSR。”

甲骨文在 Java EE 8 中重点提到微服务和其它针对云的应用并不令人惊奇,甲骨文日益将其重点放在了云方面的架构、平台和应用服务方面。在过去九个月里 Java EE 8 方面的停摆表明,在最近的财年报告中甲骨文在传统软件许可销售方面的收入首次下降后,它正在努力加大其在云方面的投入。

参考信息来源:arstechnicatheregisterjavaee-guardians

XStreamOS 是一个由 Sonicle 创建的 Solaris 的一个版本。XStream 桌面将 Solaris 的强大带给了桌面用户,同时新手用户很可能有兴趣体验一下。DistroWatch 对于 XStream 桌面 153 版本做了一个很全面的评估,并且发现它运行相当好。

Jesse Smith 在 DistroWatch 报道:

我认为 XStream 桌面做好了很多事情。诚然,当操作系统无法在我的硬件上启动,同时当运行在 VirtualBox 中时我无法使得桌面使用我显示器的完整分辨率,我的开端并不很成功。不过,除此之外,XStream 表现的很好。安装器工作的很好,该系统自动设置和使用了 引导环境 boot environments ,这让我们可以在发生错误时恢复该系统。包管理器有工作的不错, XStream 带了一套有用的软件。

我确实在播放多媒体文件时遇见一些问题,特别是使声卡工作。我不确定这是不是又一个硬件兼容问题,或者是该操作系统自带的多媒体软件的问题。另一方面,像 Web 浏览器,电子邮件,生产工具套件以及配置工具这样的工作的很好。

我最欣赏 XStream 的地方是这个操作系统是 OpenSolaris 家族的一个使用保持最新的分支。OpenSolaris 的其他衍生系统有落后的倾向,但是至少在桌面软件上,XStream 搭载最新版本的火狐和 LibreOffice。

对我个人来说,XStream 缺少一些组件,比如打印机管理器,多媒体支持和我的特定硬件的驱动。这个操作系统的其他方面也是相当吸引人的。我喜欢开发者搭配了 LXDE,也喜欢它的默认软件集,以及我最喜欢文件系统快照和启动环境开箱即用的方式。大多数的 Linux 发行版,openSUSE 除外,并没有利用好 引导环境 boot environments 的用处。我希望它是一个被更多项目采用的技术。

更多见 DistroWatch

Git 和 Github 在 Linux 开发者中有很高的知名度。但是开发者如何看待它们呢?另外,Github 是不是真的和 Git 是一个意思?一个 Linux reddit 用户最近问到了这个问题,并且得到了很有意思的答案。

Dontwakemeup46 提问:

我正在学习 Git 和 Github。我感兴趣社区如何看待两者?据我所知,Git 和 Github 应用十分广泛。但是 Git 或 Github 有没有严重的不足?社区喜欢去改变些什么呢?更多见 Reddit

与他志同道合的 Linux reddit 用户回答了他们对于 Git 和 Github的观点:

Derenir:

“Github 并不附属于 Git。

Git 是由 Linus Torvalds 开发的。

Github 几乎不支持 Linux。

Github 是一家企图借助 Git 赚钱的公司。

https://desktop.github.com/ 并没有支持 Linux。”

Bilog78:

“一个小的补充: Linus Torvalds 已经不再维护 Git了。维护者是 Junio C Hamano,以及 在他之后的主要贡献者是 Jeff King 和 Shawn O. Pearce。”

Fearthefuture:

“我喜欢 Git,但是不明白人们为什么还要使用 Github。从我的角度,Github 比 Bitbucket 好的一点是用户统计和更大的用户基础。Bitbucket 有无限的免费私有库,更好的 UI,以及更好地集成了其他服务,比如说 Jenkins。”

Thunger:

“Gitlab.com 也很不错,特别是你可以在自己的服务器上架设自己的实例。”

Takluyver:

“很多人熟悉 Github 的 UI 以及相关联的服务,比如说 Travis 。并且很多人都有 Github 账号,所以它是存储项目的一个很好的地方。人们也使用他们的 Github 个人信息页作为一种求职用的作品选辑,所以他们很积极地将更多的项目放在这里。Github 是一个存放开源项目的事实标准。”

Tdammers:

“Git 严重问题在于 UI,它有些违反直觉,以至于很多用户只能达到使用一些容易记住的咒语的程度。

Github:最严重的问题在于它是商业托管的解决方案;你买了方便,但是代价是你的代码在别人的服务器上面,已经不在你的掌控范围之内了。另一个对于 Github 的普遍批判是它的工作流和 Git 本身的精神不符,特别是 pull requests 工作的方式。最后, Github 垄断了代码的托管环境,同时对于多样性是很不好的,这反过来对于旺盛的免费软件社区很重要。”

Dies:

“更重要的是,如果一旦是这样,按照现状来说,我猜我们会被 Github 所困,因为它们控制如此多的项目。”

Tdammers:

“代码托管在别人的服务器上,这里"别人"指的是 Github。这对于开源项目来说,并不是什么太大的问题,但是尽管如此,你无法控制它。如果你在 Github 上有私有项目,“它将保持私有”的唯一的保险只是 Github 的承诺而已。如果你决定删除东西,你不能确定东西是否被删除了,或者只是隐藏了。

Github 并不自己控制这些项目(你总是可以拿走你的代码,然后托管到别的地方,声明新位置是“官方”的),它只是有比开发者本身有更深的使用权。”

Drelos:

“我已经读了大量的关于 Github 的赞美与批评。(这里有一个例子),但是我的幼稚问题是为什么不向一个免费开源的版本努力呢?”

Twizmwazin:

“Gitlab 的源码就存在这里。”

更多见 Reddit

存储 SSH 的加密秘钥和记住密码一直是一个让人头疼的问题。但是不幸的是,在当前这个充满了恶意黑客和攻击的世界中,基本的安全预防是必不可少的。对于许多普通用户来说,大多数人只能是记住密码,也可能寻找到一个好程序去存储密码,正如我们提醒这些用户不要在每个网站采用相同的密码。但是对于在各个 IT 领域的人们,我们需要将这个事情提高一个层面。我们需要使用像 SSH 密钥这样的加密秘钥,而不只是密码。

设想一个场景:我有一个运行在云上的服务器,用作我的主 git 库。我有很多台工作电脑,所有这些电脑都需要登录到这个中央服务器去做 push 与 pull 操作。这里我设置 git 使用 SSH。当 git 使用 SSH 时,git 实际上是以 SSH 的方式登录到服务器,就好像你通过 SSH 命令打开一个服务器的命令行一样。为了把这些配置好,我在我的 .ssh 目录下创建一个配置文件,其中包含一个有服务器名字、主机名、登录用户、密钥文件路径等信息的主机项。之后我可以通过输入如下命令来测试这个配置是否正确。

ssh gitserver

很快我就可以访问到服务器的 bash shell。现在我可以配置 git 使用相同配置项以及存储的密钥来登录服务器。这很简单,只是有一个问题:对于每一个我要用它登录服务器的电脑,我都需要有一个密钥文件,那意味着需要密钥文件会放在很多地方。我会在当前这台电脑上存储这些密钥文件,我的其他电脑也都需要存储这些。就像那些有特别多的密码的用户一样,我们这些 IT 人员也被这些特别多的密钥文件淹没。怎么办呢?

清理

在我们开始帮助你管理密钥之前,你需要有一些密钥应该怎么使用的基础知识,以及明白我们下面的提问的意义所在。同时,有个前提,也是最重要的,你应该知道你的公钥和私钥该放在哪里。然后假设你应该知道:

  1. 公钥和私钥之间的差异;
  2. 为什么你不可以从公钥生成私钥,但是反之则可以?
  3. authorized_keys 文件的目的以及里面包含什么内容;
  4. 如何使用私钥去登录一个你的对应公钥存储在其上的 authorized_keys 文件中的服务器。

这里有一个例子。当你在亚马逊的网络服务上创建一个云服务器,你必须提供一个用于连接你的服务器的 SSH 密钥。每个密钥都有一个公开的部分(公钥)和私密的部分(私钥)。你要想让你的服务器安全,乍看之下你可能应该将你的私钥放到服务器上,同时你自己带着公钥。毕竟,你不想你的服务器被公开访问,对吗?但是实际上的做法正好是相反的。

你应该把自己的公钥放到 AWS 服务器,同时你持有用于登录服务器的私钥。你需要保护好私钥,并让它处于你的控制之中,而不是放在一些远程服务器上,正如上图中所示。

原因如下:如果公钥被其他人知道了,它们不能用于登录服务器,因为他们没有私钥。进一步说,如果有人成功攻入你的服务器,他们所能找到的只是公钥,他们不可以从公钥生成私钥。同时,如果你在其他的服务器上使用了相同的公钥,他们不可以使用它去登录别的电脑。

这就是为什么你要把你自己的公钥放到你的服务器上以便通过 SSH 登录这些服务器。你持有这些私钥,不要让这些私钥脱离你的控制。

但是还有一点麻烦。试想一下我 git 服务器的例子。我需要做一些抉择。有时我登录架设在别的地方的开发服务器,而在开发服务器上,我需要连接我的 git 服务器。如何使我的开发服务器连接 git 服务器?显然是通过使用私钥,但这样就会有问题。在该场景中,需要我把私钥放置到一个架设在别的地方的服务器上,这相当危险。

一个进一步的场景:如果我要使用一个密钥去登录许多的服务器,怎么办?如果一个入侵者得到这个私钥,这个人就能用这个私钥得到整个服务器网络的权限,这可能带来一些严重的破坏,这非常糟糕。

同时,这也带来了另外一个问题,我真的应该在这些其他服务器上使用相同的密钥吗?因为我刚才描述的,那会非常危险的。

最后,这听起来有些混乱,但是确实有一些简单的解决方案。让我们有条理地组织一下。

(注意,除了登录服务器,还有很多地方需要私钥密钥,但是我提出的这个场景可以向你展示当你使用密钥时你所面对的问题。)

常规口令

当你创建你的密钥时,你可以选择是否包含一个密钥使用时的口令。有了这个口令,私钥文件本身就会被口令所加密。例如,如果你有一个公钥存储在服务器上,同时你使用私钥去登录服务器的时候,你会被提示输入该口令。没有口令,这个密钥是无法使用的。或者你也可以配置你的密钥不需要口令,然后只需要密钥文件就可以登录服务器了。

一般来说,不使用口令对于用户来说是更方便的,但是在很多情况下我强烈建议使用口令,原因是,如果私钥文件被偷了,偷密钥的人仍然不可以使用它,除非他或者她可以找到口令。在理论上,这个将节省你很多时间,因为你可以在攻击者发现口令之前,从服务器上删除公钥文件,从而保护你的系统。当然还有一些使用口令的其它原因,但是在很多场合这个原因对我来说更有价值。(举一个例子,我的 Android 平板上有 VNC 软件。平板上有我的密钥。如果我的平板被偷了之后,我会马上从服务器上删除公钥,使得它的私钥没有作用,无论有没有口令。)但是在一些情况下我不使用口令,是因为我正在登录的服务器上没有什么有价值的数据,这取决于情境。

服务器基础设施

你如何设计自己服务器的基础设施将会影响到你如何管理你的密钥。例如,如果你有很多用户登录,你将需要决定每个用户是否需要一个单独的密钥。(一般来说,应该如此;你不会想在用户之间共享私钥。那样当一个用户离开组织或者失去信任时,你可以删除那个用户的公钥,而不需要必须给其他人生成新的密钥。相似地,通过共享密钥,他们能以其他人的身份登录,这就更糟糕了。)但是另外一个问题是你如何配置你的服务器。举例来说,你是否使用像 Puppet 这样工具配置大量的服务器?你是否基于你自己的镜像创建大量的服务器?当你复制你的服务器,是否每一个的密钥都一样?不同的云服务器软件允许你配置如何选择;你可以让这些服务器使用相同的密钥,也可以给每一个服务器生成一个新的密钥。

如果你在操作这些复制的服务器,如果用户需要使用不同的密钥登录两个不同但是大部分都一样的系统,它可能导致混淆。但是另一方面,服务器共享相同的密钥会有安全风险。或者,第三,如果你的密钥有除了登录之外的需要(比如挂载加密的驱动),那么你会在很多地方需要相同的密钥。正如你所看到的,你是否需要在不同的服务器上使用相同的密钥不是我能为你做的决定;这其中有权衡,你需要自己去决定什么是最好的。

最终,你可能会有:

  • 需要登录的多个服务器
  • 多个用户登录到不同的服务器,每个都有自己的密钥
  • 每个用户使用多个密钥登录到不同的服务器

(如果你正在别的情况下使用密钥,这个同样的普适理论也能应用于如何使用密钥,需要多少密钥,它们是否共享,你如何处理公私钥等方面。)

安全方法

了解你的基础设施和特有的情况,你需要组合一个密钥管理方案,它会指导你如何去分发和存储你的密钥。比如,正如我之前提到的,如果我的平板被偷了,我会从我服务器上删除公钥,我希望这在平板在用于访问服务器之前完成。同样的,我会在我的整体计划中考虑以下内容:

  1. 私钥可以放在移动设备上,但是必须包含口令;
  2. 必须有一个可以快速地从服务器上删除公钥的方法。

在你的情况中,你可能决定你不想在自己经常登录的系统上使用口令;比如,这个系统可能是一个开发者一天登录多次的测试机器。这没有问题,但是你需要调整一点你的规则。你可以添加一条规则:不可以通过移动设备登录该机器。换句话说,你需要根据自己的状况构建你的准则,不要假设某个方案放之四海而皆准。

软件

至于软件,令人吃惊的是,现实世界中并没有很多好的、可靠的存储和管理私钥的软件解决方案。但是应该有吗?考虑下这个,如果你有一个程序存储你所有服务器的全部密钥,并且这个程序被一个快捷的密钥锁住,那么你的密钥就真的安全了吗?或者类似的,如果你的密钥被放置在你的硬盘上,用于 SSH 程序快速访问,密钥管理软件是否真正提供了任何保护吗?

但是对于整体基础设施和创建/管理公钥来说,有许多的解决方案。我已经提到了 Puppet,在 Puppet 的世界中,你可以创建模块以不同的方式管理你的服务器。这个想法是服务器是动态的,而且不需要精确地复制彼此。这里有一个聪明的方法,在不同的服务器上使用相同的密钥,但是对于每一个用户使用不同的 Puppet 模块。这个方案可能适合你,也可能不适合你。

或者,另一个选择就是完全换个不同的档位。在 Docker 的世界中,你可以采取一个不同的方式,正如关于 SSH 和 Docker 博客所描述的那样。

但是怎么样管理私钥?如果你搜索过的话,你无法找到很多可以选择的软件,原因我之前提到过;私钥存放在你的硬盘上,一个管理软件可能无法提到更多额外的安全。但是我使用这种方法来管理我的密钥:

首先,我的 .ssh/config 文件中有很多的主机项。我要登录的都有一个主机项,但是有时我对于一个单独的主机有不止一项。如果我有很多登录方式,就会出现这种情况。对于放置我的 git 库的服务器来说,我有两个不同的登录项;一个限制于 git,另一个用于一般用途的 bash 访问。这个为 git 设置的登录选项在机器上有极大的限制。还记得我之前说的我存储在远程开发机器上的 git 密钥吗?好了。虽然这些密钥可以登录到我其中一个服务器,但是使用的账号是被严格限制的。

其次,大部分的私钥都包含口令。(对于需要多次输入口令的情况,考虑使用 ssh-agent。)

再次,我有一些我想要更加小心地保护的服务器,我不会把这些主机项放在我的 host 文件中。这更加接近于社会工程方面,密钥文件还在,但是可能需要攻击者花费更长的时间去找到这个密钥文件,分析出来它们对应的机器。在这种情况下,我就需要手动打出来一条长长的 SSH 命令。(没那么可怕。)

同时你可以看出来我没有使用任何特别的软件去管理这些私钥。

无放之四海而皆准的方案

我们偶尔会在 linux.com 收到一些问题,询问管理密钥的好软件的建议。但是退一步看,这个问题事实上需要重新思考,因为没有一个普适的解决方案。你问的问题应该基于你自己的情景。你是否简单地尝试找到一个位置去存储你的密钥文件?你是否寻找一个方法去管理多用户问题,其中每个人都需要将他们自己的公钥插入到 authorized_keys 文件中?

通过这篇文章,我已经囊括了这方面的基础知识,希望到此你明白如何管理你的密钥,并且,只有当你问出了正确的问题,无论你寻找任何软件(甚至你需要另外的软件),它都会出现。


via: http://www.linux.com/learn/tutorials/838235-how-to-best-manage-encryption-keys-on-linux

作者:Jeff Cogswell 译者:mudongliang 校对:wxy

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

有很多 Linux 初学者经常问起的问题,“Linux 有任务管理器吗?”,“怎样在 Linux 上打开任务管理器呢?

来自 Windows 的用户都知道任务管理器非常有用。你可以在 Windows 中按下 Ctrl+Alt+Del 打开任务管理器。这个任务管理器向你展示了所有的正在运行的进程和它们消耗的内存,你可以从任务管理器程序中选择并杀死一个进程。

当你刚使用 Linux 的时候,你也会寻找一个在 Linux 相当于任务管理器的一个东西。一个 Linux 使用专家更喜欢使用命令行的方式查找进程和消耗的内存等等,但是你不用必须使用这种方式,至少在你初学 Linux 的时候。

所有主流的 Linux 发行版都有一个类似于任务管理器的东西。大部分情况下,它叫 系统监视器 System Monitor ,不过实际上它依赖于你的 Linux 的发行版及其使用的桌面环境

在这篇文章中,我们将会看到如何在以 GNOME 为桌面环境的 Linux 上找到并使用任务管理器。

在使用 GNOME 桌面环境的 Linux 上的任务管理器等价物

使用 GNOME 时,按下 super 键(Windows 键)来查找任务管理器:

当你启动系统监视器的时候,它会向你展示所有正在运行的进程及其消耗的内存。

你可以选择一个进程并且点击“ 终止进程 End Process ”来杀掉它。

你也可以在“ 资源 Resources ”标签里面看到关于一些统计数据,例如 CPU 的每个核心的占用,内存用量、网络用量等。

这是图形化的方式。如果你想使用命令行,在终端里运行“top”命令然后你就可以看到所有运行的进程及其消耗的内存。你也可以很容易地使用命令行杀死进程

这就是关于在 Fedora Linux 上任务管理器的知识。我希望这个教程帮你学到了知识,如果你有什么问题,请尽管问。


via: https://itsfoss.com/task-manager-linux/

作者:Abhishek Prakash 译者:xinglianfly 校对:wxy

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