分类 观点 下的文章

貌似每个人都听说过 Slack,它是一款跨平台的,可以使你时刻保持与他人同步的团队沟通应用。它革新了用户讨论和规划项目的方式,显而易见,它升级了 email 的沟通功能。

我在一个非常小的写作团队工作,不管是通过手机还是电脑,我从未在使用 Slack 过程中遇到过沟通问题。若想与任何规模的团队保持同步,继续使用 Slack 仍然不失为不错的方式。

既然如此,为什么我们还要讨论今天的话题?Ryver 被人们认为是下一个热点,相比 Slack,Ryver 提供了升级版的服务。Ryver 完全免费,它的团队正在奋力争取更大的市场份额。

是否 Ryver 已经强大到可以扮演 Slack 杀手的角色?这两种旗鼓相当的消息应用究竟有何不同?

欲知详情,请阅读下文。

为什么用 Ryver ?

既然 Slack 能用为什么还要折腾呢?Ryver 的开发者对 Slack 的功能滚瓜烂熟,他们希望 Ryver 改进的服务足以让你移情别恋。他们承诺 Ryver 提供完全免费的团队沟通服务,并且不会在任何一个环节隐形收费。

谢天谢地,他们用高质量产品兑现了自己的承诺。

额外的内容是关键所在,他们承诺去掉一些你在 Slack 免费账号上面遇到的限制。无限的存储空间是一个加分点,除此之外,在许多其他方面 Ryver 也更加开放。如果存储空间限制对你来说是个痛点,不防试试 Ryver。

这是一个简单易用的系统,所有的功能都可以一键搞定。这种设计哲学使 Apple 大获成功。当你开始使用它之后,也不会遭遇成长的烦恼。

会话分为私聊和公示,这意味着团队平台和私人用途有明确的界限。它应该有助于避免将任何尴尬的广而告之给你的同事,这些问题我在使用 Slack 期间都遇到过。

Ryver 支持与大量现成的 App 的集成,并在大多数平台上有原生应用程序。

在需要时,你可以添加访客而无需增加费用,如果你经常和外部客户打交道,这将是一个非常有用的功能。访客可以增加更多的访客,这种流动性的元素是无法从其他更流行的消息应用中看到的。

考虑到 Ryver 是一个为迎合不同需求而产生的完全不同的服务。如果你需要一个账户来处理几个客户,Ryver 值得一试。

问题是它是如何做到免费的呢? 简单的答案是高级用户将为你的使用付了费。 就像 Spotify 和其他应用一样,有一小部分人为我们其他人支付了费用。 这里有一个直接链接到他们的下载页面的地址,如果有兴趣就去试一试吧。

你应该切换到 Ryver 吗?

像我一样在小团队使用 Slack 的体验还是非常棒,但是 Ryver 可以给予的更多。一个完全免费的团队沟通应用的想法不可谓不宏伟,更何况它工作的十分完美。

同时使用这两种消息应用也无可厚非,但是如果你不愿意为一个白金 Slack 账户付费,一定要尝试一下竞争对手的服务。你可能会发现,两者各擅胜场,这取决于你需要什么。

最重要的是,Ryver 是一个极棒的免费替代品,它不仅仅是一个 Slack 克隆。他们清楚地知道他们想要实现什么,他们有一个可以在拥挤不堪的市场提供不同的东西的不错的产品。

但是,如果将来持续缺乏资金,Ryver 有可能消失。 它可能会让你的团队和讨论陷入混乱。 目前一切还好,但是如果你计划把更大的业务委托给这个新贵还是需要三思而行。

如果你厌倦了 Slack 对免费帐户的限制,你会对 Ryver 印象深刻。 要了解更多,请访问其网站以获取有关服务的信息。


via: https://www.maketecheasier.com/why-use-ryver-instead-of-slack/

作者:James Milin-Ashmore 译者:firstadream 校对:wxy

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

如果你在开源项目中花费了很多时间的话,你可能会看到使用的术语 “copyleft”(GNU 官方网站上的释义:中文英文)。虽然这个术语使用比较普遍,但是很多人却不理解它。软件许可是一个至少不亚于文件编辑器和打包格式的激烈辩论的主题。专家们对 copyleft 的理解可能会充斥在好多书中,但是这篇文章可以作为你理解 copyleft 启蒙之路的起点。

什么是 copyright?

在我们可以理解 copyleft 之前,我们必须先介绍一下 copyright 的概念。copyleft 并不是一个脱离于 copyright 的法律框架,copyleft 存在于 copyright 规则中。那么,什么是 copyright?

它的准确定义随着司法权的不同而不同,但是其本质就是:作品的作者对于作品的 复制 copying (因此这个术语称之为 “copyright”:copy 's right)、表现等有一定的垄断性。在美国,其宪法明确地阐述了美国国会的任务就是制定版权法律来“促进科学和实用艺术的进步”。

不同于以往,版权会立刻附加到作品上——而且不需要注册。默认情况下,所有的权力都是保留的。也就是说,没有经过作者的允许,没有人可以重新出版、表现或者修改作品。这种“允许”就是一种许可,可能还会附加有一定的条件。

如果希望得到对于 copyright 更彻底的介绍,Coursera 上的教育工作者和图书管理员的著作权是一个非常优秀的课程。

什么是 copyleft?

先不要着急,在我们讨论 copyleft 是什么之前,还有一步。首先,让我们解释一下 开源 open source 意味着什么。所有的开源许可协议,按照 开源倡议的定义 Open Source Inititative's definition (规定),除其他形式外,必须以源码的形式发放。获得开源软件的任何人都有权利查看并修改源码。

copyleft 许可和所谓的 “ 自由 permissive ” 许可不同的地方在于,其衍生的作品中,也需要相同的 copyleft 许可。我倾向于通过这种方式来区分两者不同: 自由 permissive 许可向直接下游的开发者提供了最大的自由(包括能够在闭源项目中使用开源代码的权力),而 copyleft 许可则向最终用户提供最大的自由。

GNU 项目为 copyleft 提供了这个简单的定义(中文英文):“ 规则就是当重新分发该程序时,你不可以添加限制来否认其他人对于[自由软件]的自由。 the rule that when redistributing the program, you cannot add restrictions to deny other people the central freedoms [of free software]. ”这可以被认为权威的定义,因为 GNU 通用许可证 GNU General Public License,GPL 的各种版本的依然是最广泛使用的 copyleft 许可。

软件中的 copyleft

GPL 家族是最出名的 copyleft 许可,但是它们并不是唯一的。 Mozilla 公共许可协议 Mozilla Public License,MPL Eclipse 公共许可协议 Eclipse Public License,EPL 也很出名。很多其它的 copyleft 许可 也有较少的采用。

就像之前章节介绍的那样,一个 copyleft 许可意味着下游的项目不可以在软件的使用上添加额外的限制。这最好用一个例子来说明。如果我写了一个名为 MyCoolProgram 的程序,并且使用 copyleft 许可来发布,你将有使用和修改它的自由。你可以发布你修改后的版本,但是你必须让你的用户拥有我给你的同样的自由。(但)如果我使用 “ 自由 permissive ” 许可,你将可以将它自由地合并到一个不提供源码的闭源软件中。

对于我的 MyCoolProgram 程序,和你必须能做什么同样重要的是你必须不能做什么。你不必用和我完全一样的许可协议,只要它们相互兼容就行(但一般的为了简单起见,下游的项目也使用相同的许可)。你不必向我贡献出你的修改,但是你这么做的话,通常被认为一个很好的形式,尤其是这些修改是 bug 修复的话。

非软件中的 copyleft

虽然,copyleft 的概念起始于软件世界,但是它也存在于之外的世界。“做你想做的,只要你保留其他人也有做同样的事的权力”的概念是应用于文字创作、视觉艺术等方面的知识共享署名许可(中文英文)的一个显著的特点(CC BY-SA 4.0 是贡献于 Opensource.com 默认的许可,也是很多开源网站,包括 Linux.cn 在内所采用的内容许可协议)。GNU 自由文档许可证是另一个非软件协议中 copyleft 的例子。在非软件中使用软件协议通常不被建议。

我是否需要选择一种 copyleft 许可?

关于项目应该使用哪一种许可,可以用(已经有了)成篇累牍的文章在阐述。我的建议是首先将许可列表缩小,以满足你的哲学信条和项目目标。GitHub 的 choosealicense.com 是一种查找满足你的需求的许可协议的好方法。tl;drLegal 使用平实的语言来解释了许多常见和不常见的软件许可。而且也要考虑你的项目所在的生态系统,围绕一种特定语言和技术的项目经常使用相同或者相似的许可。如果你希望你的项目可以运行的更出色,你可能需要确保你选择的许可是兼容的。

关于更多 copyleft 的信息,请查看 copyleft 指南

(题图来自:behance.net


via: https://opensource.com/resources/what-is-copyleft

作者:Ben Cotton 译者:yangmingming 校对:wxy

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

从各方面来看,互联网向 IPv6 的过渡是件很缓慢的事情。不过在最近几年,可能是由于 IPv4 地址资源的枯竭,IPv6 的使用处于上升态势。相应的,开发者也有兴趣确保软件能在 IPv4 和 IPv6 下工作。但是,正如近期 OpenBSD 邮件列表中的讨论所关注的,一个使得向 IPv6 转换更加轻松的机制设计同时也可能导致网络更不安全——并且 Linux 发行版们的默认配置可能并不安全。

地址映射

IPv6 在很多方面看起来可能很像 IPv4,但它是一个不同地址空间的不同的协议。服务器程序想要接受使用二者之中任意一个协议的连接,必须给两个不同的地址族分别打开一个套接字——IPv4 的 AF_INET 和 IPv6 的 AF_INET6。特别是一个程序希望在主机上的使用两种地址协议的任意接口都接受连接的话,需要创建一个绑定到全零通配符地址(0.0.0.0)的 AF_INET 套接字和一个绑定到 IPv6 等效地址(写作 ::)的 AF_INET6 套接字。它必须在两个套接字上都监听连接——或者有人会这么认为。

多年前,在 RFC 3493,IETF 指定了一个机制,程序可以使用一个单独的 IPv6 套接字工作在两个协议之上。有了一个启用这个行为的套接字,程序只需要绑定到 :: 地址从而在所有接口上接受使用这两个协议的连接。当创建了一个 IPv4 连接到该绑定端口,源地址会像 RFC 2373 中描述的那样映射到 IPv6。所以,举个例子,一个使用了这个模式的程序会将一个 192.168.1.1 的传入连接看作来自 ::ffff:192.168.1.1(这个混合的写法就是这种地址的通常写法)。程序也能通过相同的映射方法打开一个到 IPv4 地址的连接。

RFC 要求默认实现这个行为,所以大多数系统这么做了。不过也有些例外,OpenBSD 就是其中之一;在那里,希望在两种协议下工作的程序能做的只能是创建两个独立的套接字。但一个在 Linux 中打开两个套接字的程序会遇到麻烦:IPv4 和 IPv6 套接字都会尝试绑定到 IPv4 地址,所以不论是哪个,后者都会失败。换句话说,一个绑定到 :: 指定端口的套接字的程序会同时绑定到那个端口上的 IPv6 的 :: 和 IPv4 的 0.0.0.0 地址。如果程序之后尝试绑定一个 IPv4 套接字到 0.0.0.0 的相同端口上时,这个操作会失败,因为这个端口已经被绑定了。

当然有个办法可以解决这个问题;程序可以调用 setsockopt() 来打开 IPV6_V6ONLY 选项。一个打开两个套接字并且设置了 IPV6_V6ONLY 的程序应该可以在所有的系统间移植。

读者们可能对不是每个程序都能正确处理这一问题没那么震惊。事实证明,这些程序的其中之一是 网络时间协议 Network Time Protocol OpenNTPD 实现。Brent Cook 最近给上游 OpenNTPD 源码提交了一个小补丁,添加了必要的 setsockopt() 调用,它也被提交到了 OpenBSD 中了。不过那个补丁看起来不大可能被接受,最可能的原因是因为 OpenBSD 式的理由(LCTT 译注:如前文提到的,OpenBSD 并不受这个问题的影响)。

安全担忧

正如上文所提到,OpenBSD 根本不支持 IPv4 映射的 IPv6 套接字。即使一个程序试着通过将 IPV6_V6ONLY 选项设置为 0 来显式地启用地址映射,它的作者也会感到沮丧,因为这个设置在 OpenBSD 系统中无效。这个决定背后的原因是这个映射带来了一些安全隐忧。攻击打开的接口的攻击类型有很多种,但它们最后都会回到规定的两个途径到达相同的端口,每个端口都有它自己的控制规则。

任何给定的服务器系统可能都设置了防火墙规则,描述端口的允许访问权限。也许还会有适当的机制,比如 TCP wrappers 或一个基于 BPF 的过滤器,或一个网络上的路由器可以做连接状态协议过滤。结果可能是导致防火墙保护和潜在的所有类型的混乱连接之间的缺口造成同一 IPv4 地址可以通过两个不同的协议到达。如果地址映射是在网络边界完成的,情况甚至会变得更加复杂;参看这个 2003 年的 RFC 草案,它描述了如果映射地址在主机之间传播,一些随之而来的其它攻击场景。

改变系统和软件正确地处理 IPv4 映射的 IPv6 地址当然可以实现。但那增加了系统的整体复杂度,并且可以确定这个改动没有实际地完整实现到它应该实现的范围内。如同 Theo de Raadt 说的

有时候人们将一个糟糕的想法放进了 RFC。之后他们发现这个想法是不可能的就将它丢回垃圾箱了。结果就是概念变得如此复杂,每个人都得在管理和编码方面是个全职专家。

我们也根本不清楚这些全职专家有多少在实际配置使用 IPv4 映射的 IPv6 地址的系统和网络。

有人可能会说,尽管 IPv4 映射的 IPv6 地址造成了安全危险,更改一下程序让它在实现了地址映射的系统上关闭地址映射应该没什么危害。但 Theo 认为不应该这么做,有两个理由。第一个是有许多破旧的程序,它们永远不会被修复。而实际的原因是给发行版们施加了压力去默认关闭地址映射。正如他说的:“最终有人会理解这个危害是系统性的,并更改系统默认行为使之‘secure by default’。”

Linux 上的地址映射

在 Linux 系统,地址映射由一个叫做 net.ipv6.bindv6only 的 sysctl 开关控制;它默认设置为 0(启用地址映射)。管理员(或发行版们)可以通过将它设置为 1 来关闭地址映射,但在部署这样一个系统到生产环境之前最好确认软件都能正常工作。一个快速调查显示没有哪个主要发行版改变这个默认值;Debian 在 2009 年的 “squeeze” 中改变了这个默认值,但这个改动破坏了很多的软件包(比如任何包含 Java 的程序),在经过了几次的 Debian 式的讨论之后,它恢复到了原来的设置。看上去不少程序依赖于默认启用地址映射。

OpenBSD 有以“secure by default”的名义打破其核心系统之外的东西的传统;而 Linux 发行版们则更倾向于难以作出这样的改变。所以那些一般不愿意收到他们用户的不满的发行版们,不太可能很快对 bindv6only 的默认设置作出改变。好消息是这个功能作为默认已经很多年了,但很难找到被利用的例子。但是,正如我们都知道的,谁都无法保证这样的利用不可能发生。


via: https://lwn.net/Articles/688462/

作者:Jonathan Corbet 译者:alim0x 校对:wxy

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

Tianhui Michael Li 和 Ariel M’ndange-Pfupfu 将在今年 10 月 10、12 和 14 号组织一个在线经验分享课程:Spark 分布式计算入门。该课程的内容包括创建端到端的运行应用程序和精通 Spark 关键工具。

毋庸置疑,云计算将会在未来数据科学领域扮演至关重要的角色。弹性,可扩展性和按需分配的计算能力作为云计算的重要资源,直接导致云服务提供商集体火拼。其中最大的两股势力正是亚马逊网络服务(AWS)谷歌云平台(GCP)

本文依据构建时间和运营成本对 AWS 和 GCP 的 Spark 工作负载作一个简短比较。实验由我们的学生在 数据孵化器 The Data Incubator 进行, 数据孵化器 The Data Incubator 是一个大数据培训组织,专门为公司招聘顶尖数据科学家并为公司职员培训最新的大数据科学技能。尽管 Spark 效率惊人,分布式工作负载的时间和成本亦然可以大到不能忽略不计。因此我们一直努力寻求更高效的技术,以便我们的学生能够学习到最好和最快的工具。

提交 Spark 任务到云

Spark 是一个类 MapReduce 但是比 MapReduce 更灵活、更抽象的并行计算框架。Spark 提供 Python 和 Java 编程接口,但它更愿意用户使用原生的 Scala 语言进行应用程序开发。Scala 可以把应用程序和依赖文件打包在一个 JAR 文件从而使 Spark 任务提交变得简单。

通常情况下,Sprark 结合 HDFS 应用于分布式数据存储,而与 YARN 协同工作则应用于集群管理;这种堪称完美的配合使得 Spark 非常适用于 AWS 的弹性 MapReduce (EMR)集群和 GCP 的 Dataproc 集群。这两种集群都已有 HDFS 和 YARN 预配置,不需要额外进行配置。

配置云服务

通过命令行比通过网页界面管理数据、集群和任务具有更高的可扩展性。对 AWS 而言,这意味着客户需要安装 CLI。客户必须获得证书并为每个 EC2 实例创建独立的密钥对。除此之外,客户还需要为 EMR 用户和 EMR 本身创建角色(基本权限),主要是准入许可规则,从而使 EMR 用户获得足够多的权限(通常在 CLI 运行 aws emr create-default-roles 就可以)。

相比而言,GCP 的处理流程更加直接。如果客户选择安装 Google Cloud SDK 并且使用其 Google 账号登录,那么客户即刻可以使用 GCP 的几乎所有功能而无需其他任何配置。唯一需要提醒的是不要忘记通过 API 管理器启用计算引擎、Dataproc 和云存储 JSON 的 API。

当你安装你的喜好设置好之后,有趣的事情就发生了!比如可以通过aws s3 cp或者gsutil cp命令拷贝客户的数据到云端。再比如客户可以创建自己的输入、输出或者任何其他需要的 bucket,如此,运行一个应用就像创建一个集群或者提交 JAR 文件一样简单。请确定日志存放的地方,毕竟在云环境下跟踪问题或者调试 bug 有点诡异。

一分钱一分货

谈及成本,Google 的服务在以下几个方面更有优势。首先,购买计算能力的原始成本更低。4 个 vCPU 和 15G RAM 的 Google 计算引擎服务(GCE)每小时只需 0.20 美元,如果运行 Dataproc,每小时也只需区区 0.24 美元。相比之下,同等的云配置,AWS EMR 则需要每小时 0.336 美元。

其次,计费方式。AWS 按小时计费,即使客户只使用 15 分钟也要付足 1 小时的费用。GCP 按分钟计费,最低计费 10 分钟。在诸多用户案例中,资费方式的不同直接导致成本的巨大差异。

两种云服务都有其他多种定价机制。客户可以使用 AWS 的 Sport Instance 或 GCP 的 Preemptible Instance 来竞价它们的空闲云计算能力。这些服务比专有的、按需服务便宜,缺点是不能保证随时有可用的云资源提供服务。在 GCP 上,如果客户长时间(每月的 25% 至 100%)使用服务,可以获取更多折扣。在 AWS 上预付费或者一次购买大批量服务可以节省不少费用。底线是,如果你是一个超级用户,并且使用云计算已经成为一种常态,那么最好深入研究云计算,自己算计好成本。

最后,新手在 GCP 上体验云服务的费用较低。新手只需 300 美元信用担保,就可以免费试用 60 天 GCP 提供的全部云服务。AWS 只免费提供特定服务的特定试用层级,如果运行 Spark 任务,需要付费。这意味着初次体验 Spark,GCP 具有更多选择,也少了精打细算和讨价还价的烦恼。

性能比拼

我们通过实验检测一个典型 Spark 工作负载的性能与开销。实验分别选择 AWS 的 m3.xlarg 和 GCP 的 n1-standard-4,它们都是由一个 Master 和 5 个核心实例组成的集群。除了规格略有差别,虚拟核心和费用都相同。实际上它们在 Spark 任务的执行时间上也表现的惊人相似。

测试 Spark 任务包括对数据的解析、过滤、合并和聚合,这些数据来自公开的 堆栈交换数据转储 Stack Exchange Data Dump 。通过运行相同的 JAR,我们首先对大约 50M 的数据子集进行交叉验证,然后将验证扩大到大约 9.5G 的数据集。

Figure 1. Credit: Michael Li and Ariel M'ndange-Pfupfu.

Figure 2. Credit: Michael Li and Ariel M'ndange-Pfupfu.

结果表明,短任务在 GCP 上具有明显的成本优势,这是因为 GCP 以分钟计费,并最终扣除了 10 分钟的费用,而 AWS 则收取了 1 小时的费用。但是即使长任务,因为计费方式占优,GPS 仍然具有相当优势。同样值得注意的是存储成本并不包括在此次比较当中。

结论

AWS 是云计算的先驱,这甚至体现在 API 中。AWS 拥有巨大的生态系统,但其许可模型已略显陈旧,配置管理也有些晦涩难解。相比之下,Google 是云计算领域的新星并且将云计算服务打造得更加圆润自如。但是 GCP 缺少一些便捷的功能,比如通过简单方法自动结束集群和详细的任务计费信息分解。另外,其 Python 编程接口也不像 AWS 的 Boto 那么全面。

如果你初次使用云计算,GCP 因其简单易用,别具魅力。即使你已在使用 AWS,你也许会发现迁移到 GCP 可能更划算,尽管真正从 AWS 迁移到 GCP 的代价可能得不偿失。

当然,现在对两种云服务作一个全面的总结还非常困难,因为它们都不是单一的实体,而是由多个实体整合而成的完整生态系统,并且各有利弊。真正的赢家是用户。一个例证就是在 数据孵化器 The Data Incubator ,我们的博士数据科学研究员在学习分布式负载的过程中真正体会到成本的下降。虽然我们的大数据企业培训客户可能对价格不那么敏感,他们更在意能够更快速地处理企业数据,同时保持价格不增加。数据科学家现在可以享受大量的可选服务,这些都是从竞争激烈的云计算市场得到的实惠。


via: https://www.oreilly.com/ideas/spark-comparison-aws-vs-gcp

作者:Michael Li Ariel M'Ndange-Pfupfu 译者:firstadream 校对:wxy

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

多数的的桌面 Linux 用户都会选择三种发行版本:Debian/Ubuntu、Fedora 或者 Arch Linux。但是今天,我将给出你需要使用 openSUSE 的五大理由。

相比其他的 Linux 发行版,我总能在 openSUSE 上看到一些令人耳目一新的东西。我说不太好,但它总是如此的闪亮和个性鲜明。这绿色的大蜥蜴是看起来如此的令人惊叹!但这并不是 openSUSE 即便不是最好也是要比其它发行版更好的原因!

请别误解我。我在各种场合用过许多不同的 Linux 发行版,同时也很敬佩在这些发行版背后默默工作的开发者,是他们让计算变成一件快乐的事情。但是 openSUSE 一直让人感觉,嗯,令人崇敬——你是不是也这样觉得?

openSUSE 比其他 Linux 发行版要好的五大理由

你是不是认为我在说 openSUSE 是最好的 Linux 发行版?不,我并不是要表达这个意思。其实没有任何一个 Linux 发行版是最好的。它真的可以满足你寻找 “灵魂伴侣” 的需求。

但在这里,我准备给大家说说,openSUSE 比其他发行版做得要好的五件事。如下:

1 社区规则

openSUSE 是一个典型的社区驱动型项目。我经常看到很多用户在升级后抱怨开发人员改变了他们喜欢的发行版。但在 openSUSE 不是这样,openSUSE 是纯社区驱动的项目,并且任何时候都朝着用户所希望的方向发展。

2 系统的健壮性

另外一个是操作系统的集成程度。我可以在同一个 openSUSE 系统上安装所有的最好的 Linux 桌面环境,而在 Ubuntu 上则因为系统的稳定性,坚决不允许用户这样做。而这恰好体现了一个系统的健壮程度。因此,对于那些喜欢自己动手完成每一件事的用户,openSUSE 还是很诱人的。

3 易于安装软件

在 Linux 的世界里有很多非常好用的包管理工具。从 Debian 的 apt-get 到 Fedora 的 DNF,它们无不吸引着用户,而且在这些发行版成为流行版本的过程中扮演着重要角色。

openSUSE 同样有一个将软件传递到桌面的好方法。software.opensuse.org 是一个 Web 界面,你可以用它从仓库中获取安装软件。你所需要做的就是打开这个链接 (当然,是在 openSUSE 系统上),在搜索框中输入你想要的软件,点击“直接安装”即可。就是这么简单,不是吗?

听起来就像是在使用 Google 商店一样,是吗?

4 YAST

毫不夸张的说,YaST (LCTT 译注: YaST 是 openSUSE 和 SUSE Linux 企业版的安装和配置工具) 绝对是世界上有史以来操作系统上最好的控制中心。并且毫无疑问地,你可以使用它来操控系统上的一切:网络、软件升级以及所有的基础设置等。无论是 openSUSE 的个人版或是 SUSE Linux 企业版,你都能在 YaST 的强力支撑下,轻松的完成安装。总之,一个工具,方便而无所不能。

5 开箱即用的极致体验

SUSE 的团队是 Linux 内核中最大的贡献者团体之一。他们辛勤的努力也意味着,他们有足够的经验来应付不同的硬件条件。

有着良好的硬件支持,一定会有很棒的开箱即用的体验。

6 他们做了一些搞笑视频

等等,不是说好了是五个理由吗?怎么多了一个!

但因为 Abhishek 逼着我加进来,因为他们做的 Linux 的搞笑视频才使 openSUSE 成为了最好的发行版。

开了个玩笑,不过还是看看 Uptime Funk,你将会知道为什么 SUSE 是最酷的 Linux

LEAP 还是 TUMBLEWEED?该用哪一个!

如果你现在想要使用 openSUSE 了,让我来告诉你,这两个 openSUSE 版本:LEAP 和 TUMBLEWEED。哪一个更合适你一点。

尽管两者都提供了相似的体验和相似的环境,但还是需要你自行决定安装那个版本到你硬盘上。

OPENSUSE : LEAP

openSUSE Leap 是一个普通的大众版本,基本上每八个月更新一次。目前最新的版本是 openSUSE 42.1。它所有的软件都是稳定版,给用户提供最顺畅的体验。

对于家庭用户、办公和商业用户,是再合适不过的了。它合适那些想要一个稳定系统,而不必事事亲为,可以让他们安心工作的用户。只要进行正确的设置之后,你就不必担心其他事情,然后专心投入工作就好。同时,我也强烈建议图书馆和学校使用 Leap。

OPENSUSE: TUMBLEWEED

Tumbleweed version of openSUSE 是滚动式更新的版本。它定期更新系统中所使用的软件集的最新版本。对于想要使用最新软件以及想向 openSUSE 做出贡献的开发者和高级用户来说,这个版本绝对值得一试。

需要指出的是,Tumbleweed 并不是 Leap 的 beta 和 测试版本 。它是最新锐的 Linux 稳定发行版。

Tumbleweed 给了你最快的更新,但是仅在开发者确定某个包的稳定性之后才行。

说说你的想法?

请在下方评论说出你对 openSUSE 的想法。如果你已经在考虑使用 openSUSE,你更想用 Leap 和 Tumbleweed 哪一个版本呢?

来,让我们开干!


via: https://itsfoss.com/why-use-opensuse/

作者:Aquil Roshan 译者:GHLandy 校对:wxy

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

先说下 OpenOffice。可能你已经无数次地看到说 Apache OpenOffice 即将结束。上一个稳定版本是 4.1.2 (发布于 2015 年 10 月),而最近的一个严重安全漏洞用了一个月才打上补丁。编码人员的缺乏使得开发如爬行前进一般。然后,可能是最糟糕的消息了:这个项目建议用户切换到 MS Office(或 LibreOffice)。

丧钟为谁而鸣?丧钟为你而鸣,OpenOffice。

我想说些可能会惹恼一些人的话。你准备好了吗?

OpenOffice 的终止对开源和用户来说都将是件好事。

让我解释一下。

一个分支统治所有

当 LibreOffice 从 OpenOffice 分支出来后,我们看到了另一个情况:分支不只在原始基础上进行改进,而且大幅超越了它。LibreOffice 一举成功。所有之前预装 OpenOffice 的 Linux 发行版都迁移到了这个新项目。LibreOffice 从起跑线突然冲出,并迅速迈出了一大步。更新以极快的速度发布,改善内容丰富而重要。

不久后,OpenOffice 就被开源社区丢在了脑后。当 2011 年 Oracle 决定终止这个项目并把代码捐赠给 Apache 项目时,这种情况自然更加恶化了。从此 OpenOffice 艰难前进,然后把我们就看到了现在这种局面:一个生机勃勃的 LibreOffice 和一个艰难的、缓慢的 OpenOffice。

但我认为在这个相当昏暗的隧道末尾有一丝曙光。

合并他们

这听起来可能很疯狂,但我认为是时候把 LibreOffice 和 OpenOffice 合二为一了。是的,我知道很可能有政治考虑和自尊意识,但我认为合并成一个会更好。合并的好处很多。我首先能想到的是:

  • 把 MS Office 过滤器整合起来:OpenOffice 在更好地导入某些 MS Office 文件上功能很强(而众所周知 LibreOffice 正在改进,但时好时坏)
  • LibreOffice 有更多开发者:尽管 OpenOffice 的开发者数量不多,但也无疑会增加到合并后的项目。
  • 结束混乱:很多用户以为 OpenOffice 和 LibreOffice 是同一个东西。有些甚至不知道 LibreOffice 存在。这将终结那些混乱。
  • 合并他们的用户量:OpenOffice 和 LibreOffice 各自拥有大量用户。联合后,他们将是个巨大的力量。

宝贵机遇

OpenOffice 的终止实际上会成为整个开源办公套件行业的一个宝贵机遇。为什么?我想表明有些东西我认为已经需要很久了。如果 OpenOffice 和 LibreOffice 集中他们的力量,比较他们的代码并合并,他们之后就可以做一些更必要的改进工作,不仅是整体的内部工作,也包括界面。

我们得面对现实,LibreOffice 和(相关的) OpenOffice 的用户界面都是过时的。当我安装 LibreOffice 5.2.1.2 时,工具栏绝对是个灾难(见下图)。

LibreOffice 默认工具栏显示

尽管我支持和关心(并且日常使用)LibreOffice,但事实已经再清楚不过了,界面需要完全重写。我们正在使用的是 90 年代末/ 2000 年初的复古界面,它必须得改变了。当新用户第一次打开 LibreOffice 时,他们会被淹没在大量按钮、图标和工具栏中。Ubuntu Unity 的平视显示(Head up Display,简称 HUD)帮助解决了这个问题,但那并不适用于其它桌面和发行版。当然,有经验的用户知道在哪里找什么(甚至定制工具栏以满足特殊的需要),但对新用户或普通用户,那种界面是个噩梦。现在是做出改变的一个好时机。引入 OpenOffice 最后残留的开发者并让他们加入到改善界面的战斗中。借助于整合 OpenOffice 额外的导入过滤器和现代化的界面,LibreOffice 终能在家庭和办公桌面上都引起一些轰动。

这会真的发生吗?

这需要发生。但是会发生吗?我不知道。但即使掌权者决定用户界面并不需要重组(这会是个失误),合并 OpenOffice 仍是前进的一大步。合并两者将带来开发的更专注,更好的推广,公众更少的困惑。

我知道这可能看起来有悖于开源的核心精神,但合并 LibreOffice 和 OpenOffice 将能联合两者的力量,而且可能会摆脱弱点。

在我看来,这是双赢的。


via: http://www.techrepublic.com/article/its-time-to-make-libreoffice-and-openoffice-one-again/

作者:Jack Wallen 译者:bianjp 校对:wxy

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