Jason Van Gumster 发布的文章

GitHub 被收购导致一些用户去寻找这个流行的代码仓库的替代品。这里有一些你可以考虑一下。

也许你是少数一些没有注意到的人之一,就在之前,微软收购了 GitHub。两家公司达成了共识。微软在近些年已经变成了开源的有力支持者,而 GitHub 从成立起,就已经成为了大量的开源项目的实际代码库。

然而,最近发生的这次收购可能会带给你一些苦恼。毕竟公司的收购让你意识到了你的开源代码放在了一个商业平台上。可能你现在还没准备好迁移到其他的平台上去,但是至少这可以给你提供一些可选项。让我们找找网上现在都有哪些可用的平台。

选择之一: GitHub

严格来说,这是一个合格的选项。GitHub 历史上没有什么失信的地方,而且微软后来也一直笑对开源。把你的项目继续放在 GitHub 上,保持观望没有什么不可以。它现在依然是最大的软件开发的网络社区,同时还有许多对于问题追踪、代码审查、持续集成、通用的代码管理等很有用的工具。而且它还是基于 Git 的,这是每个人都喜欢的开源版本控制系统。你的代码还是你的代码。如果没有出现什么问题,那保持原状是没错的。

选择之二: GitLab

GitLab 是考虑替代代码库平台时的主要竞争者。它是完全开源的。你可以像在 GitHub 一样把你的代码托管在 GitLab,但你也可以选择在你自己的服务器上自行托管自己的 GitLab 实例,并完全控制谁可以访问那里的所有内容以及如何访问和管理。GitLab 与 GitHub 功能几乎相同,有些人甚至可能会说它的持续集成和测试工具更优越。尽管 GitLab 上的开发者社区肯定比 GitHub 上的开发者社区要小,但这并没有什么。你可能会在那里的人群中找到更多志同道合的开发者。

选择之三: Bitbucket

Bitbucket 已经存在很多年了。在某些方面,它可以作为 GitHub 未来的一面镜子。Bitbucket 八年前被一家大公司(Atlassian)收购,并且已经经历了一些变化。它仍然是一个像 GitHub 这样的商业平台,但它远不是一个创业公司,而且从组织上说它的基础相当稳定。Bitbucket 具有 GitHub 和 GitLab 上的大部分功能,以及它自己的一些新功能,如对 Mercurial 仓库的原生支持。

选择之四: SourceForge

SourceForge 是开源代码库的鼻祖。如果你曾经有一个开源项目,Sourceforge 就是那个托管你的代码并向其他人分享你的发布版本的地方。它迁移到 Git 版本控制用了一段时间,它有一些商业收购和再次收购的历史,以及一些对某些开源项目糟糕的捆绑决策。也就是说,SourceForge 从那时起似乎已经恢复,该网站仍然是一个有着不少开源项目的地方。然而,很多人仍然感到有点受伤,而且有些人并不是很支持它的平台货币化的各种尝试,所以一定要睁大眼睛。

选择之五: 自己管理

如果你想自己掌握自己项目的命运(除了你自己没人可以指责你),那么一切都由自己来做可能对你来说是最佳的选择。无论对于大项目还是小项目,都是好的选择。Git 是开源的,所以自己托管也很容易。如果你想要问题追踪和代码审查功能,你可以运行一个 GitLab 或者 Phabricator 的实例。对于持续集成,你可以设置自己的 Jenkins 自动化服务实例。是的,你需要对自己的基础架构开销和相关的安全要求负责。但是,这个设置过程并不是很困难。所以如果你不想自己的代码被其他人的平台所吞没,这就是一种很好的方法。

选择之六:以上全部

以下是所有这些的美妙之处:尽管这些平台上有一些专有的选项,但它们仍然建立在坚实的开源技术之上。而且不仅仅是开源,而是明确设计为分布在大型网络(如互联网)上的多个节点上。你不需要只使用一个。你可以使用一对……或者全部。使用 GitLab 将你自己的设施作为保证的基础,并在 GitHub 和 Bitbucket 上安装克隆存储库,以进行问题跟踪和持续集成。将你的主代码库保留在 GitHub 上,但是出于你自己的考虑,可以在 GitLab 上安装“备份”克隆。

关键在于你可以选择。我们能有这么多选择,都是得益于那些非常有用而强大的项目之上的开源许可证。未来一片光明。

当然,在这个列表中我肯定忽略了一些开源平台。方便的话请补充给我们。你是否使用了多个平台?哪个是你最喜欢的?你都可以在这里说出来!


via: https://opensource.com/article/18/8/github-alternatives

作者:Jason van Gumster 选题:lujun9972 译者:dianbanjiu 校对:wxy

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

这个网络附属文件服务提供了一系列可靠的功能,并且易于安装和配置。

面对许多可供选择的云存储方案,一些人可能会质疑一个家庭 NAS( 网络附属存储 network-attached storage )服务器的价值。毕竟,当所有你的文件存储在云上,你就不需要为你自己云服务的维护、更新和安全担忧。

但是,这不完全对,是不是?你有一个家庭网络,所以你已经要负责维护网络的健康和安全。假定你已经维护一个家庭网络,那么一个家庭 NAS并不会增加额外负担。反而你能从少量的工作中得到许多的好处。

你可以为你家里所有的计算机进行备份(你也可以备份到其它地方)。构架一个存储电影、音乐和照片的媒体服务器,无需担心互联网连接是否连通。在家里的多台计算机上处理大型文件,不需要等待从互联网某个其它计算机传输这些文件过来。另外,可以让 NAS 与其他服务配合工作,如托管本地邮件或者家庭 Wiki。也许最重要的是,构架家庭 NAS,数据完全是你的,它始终处于在控制下,随时可访问。

接下来的问题是如何选择 NAS 方案。当然,你可以购买预先搭建好的商品,并在一天内搞定,但是这会有什么乐趣呢?实际上,尽管拥有一个能为你搞定一切的设备很棒,但是有一个可以修复和升级的钻机平台更棒。这就我近期的需求,我选择安装和配置 openmediavault

为什么选择 openmediavault?

市面上有不少开源的 NAS 解决方案,其中有些肯定比 openmediavault 流行。当我询问周遭,例如 freeNAS 这样的最常被推荐给我。那么为什么我不采纳他们的建议呢?毕竟,用它的人更多。基于 FreeNAS 官网的一份对比数据,它包含了很多的功能,并且提供许多支持选项。这当然都对。但是 openmediavault 也不差。它实际上是基于 FreeNAS 早期版本的,虽然它在下载量和功能方面较少,但是对于我的需求而言,它已经相当足够了。

另外一个因素是它让我感到很舒适。openmediavault 的底层操作系统是 Debian,然而 FreeNAS 是 FreeBSD。由于我个人对 FreeBSD 不是很熟悉,因此如果我的 NAS 出现故障,必定难于在 FreeBSD 上修复故障。同样的,也会让我觉得难于优化或添加一些服务到这个机器上。当然,我可以学习 FreeBSD 以更熟悉它,但是我已经在家里构架了这个 NAS;我发现,如果完成它只需要较少的“学习机会”,那么构建 NAS 往往会更成功。

当然,每个人情况都不同,所以你要自己调研,然后作出最适合自己方案的决定。FreeNAS 对于许多人似乎都是不错的解决方案。openmediavault 正是适合我的解决方案。

安装与配置

openmediavault 文档里详细记录了安装步骤,所以我不在这里重述了。如果你曾经安装过任何一个 Linux 发行版,大部分安装步骤都是很类似的(虽然是在相对丑陋的 Ncurses 界面,而不像你或许在现代发行版里见到的)。我按照 专用的驱动器 的说明来安装它。这些说明不但很好,而且相当精炼的。当你搞定这些步骤,就安装好了一个基本的系统,但是你还需要做更多才能真正构建好 NAS 来存储各种文件。例如,专用驱动器方式需要在硬盘驱动器上安装 openmediavault,但那是指你的操作系统的驱动器,而不是和网络上其他计算机共享的驱动器。你需要自己把这些建立起来并且配置好。

你要做的第一件事是加载用来管理的网页界面,并修改默认密码。这个密码和之前你安装过程设置的 root 密码是不同的。这是网页界面的管理员账号,默认的账户和密码分别是 adminopenmediavault,当你登入后要马上修改。

设置你的驱动器

一旦你安装好 openmediavault,你需要它为你做一些工作。逻辑上的第一个步骤是设置好你即将用来作为存储的驱动器。在这里,我假定你已经物理上安装好它们了,所以接下来你要做的就是让 openmediavault 识别和配置它们。第一步是确保这些磁盘是可见的。侧边栏菜单有很多选项,而且被精心的归类了。选择“Storage -> Disks”。一旦你点击该菜单,你应该能够看到所有你已经安装到该服务器的驱动,包括那个你已经用来安装 openmediavault 的驱动器。如果你没有在那里看到所有驱动器,点击“Scan”按钮去看是否能够挂载它们。通常,这不会是一个问题。

你可以独立的挂载和设置这些驱动器用于文件共享,但是对于一个文件服务器,你会想要一些冗余。你想要能够把很多驱动器当作一个单一卷,并能够在某一个驱动器出现故障时恢复你的数据,或者空间不足时安装新驱动器。这意味你将需要一个 RAID。你想要的什么特定类型的 RAID 的这个主题是一个大坑,值得另写一篇文章专门来讲述它(而且已经有很多关于该主题的文章了),但是简而言之是你将需要不止一个驱动器,最好的情况下,你所有的驱动都存储一样的容量。

openmediavault 支持所有标准的 RAID 级别,所以这里很简单。可以在“Storage -> RAID Management”里配置你的 RAID。配置是相当简单的:点击“Create”按钮,在你的 RAID 阵列里选择你想要的磁盘和你想要使用的 RAID 级别,并给这个阵列一个名字。openmediavault 为你处理剩下的工作。这里没有复杂的命令行,也不需要试图记住 mdadm 命令的一些选项参数。在我的例子,我有六个 2TB 驱动器,设置成了 RAID 10。

当你的 RAID 构建好了,基本上你已经有一个地方可以存储东西了。你仅仅需要设置一个文件系统。正如你的桌面系统,一个硬盘驱动器在没有格式化的情况下是没什么用处的。所以下一个你要去的地方的是位于 openmediavault 控制面板里的“Storage -> File Systems”。和配置你的 RAID 一样,点击“Create”按钮,然后跟着提示操作。如果你在你的服务器上只有一个 RAID ,你应该可以看到一个像 md0 的东西。你也需要选择文件系统的类别。如果你不能确定,选择标准的 ext4 类型即可。

定义你的共享

亲爱的!你有个地方可以存储文件了。现在你只需要让它在你的家庭网络中可见。可以从在 openmediavault 控制面板上的“Services”部分上配置。当谈到在网络上设置文件共享,主要有两个选择:NFS 或者 SMB/CIFS. 根据以往经验,如果你网络上的所有计算机都是 Linux 系统,那么你使用 NFS 会更好。然而,当你家庭网络是一个混合环境,是一个包含Linux、Windows、苹果系统和嵌入式设备的组合,那么 SMB/CIFS 可能会是你合适的选择。

这些选项不是互斥的。实际上,你可以在服务器上运行这两个服务,同时拥有这些服务的好处。或者你可以混合起来,如果你有一个特定的设备做特定的任务。不管你的使用场景是怎样,配置这些服务是相当简单。点击你想要的服务,从它配置中激活它,和在网络中设定你想要的共享文件夹为可见。在基于 SMB/CIFS 共享的情况下,相对于 NFS 多了一些可用的配置,但是一般用默认配置就挺好的,接着可以在默认基础上修改配置。最酷的事情是它很容易配置,同时也很容易在需要的时候修改配置。

用户配置

基本上已将完成了。你已经在 RAID 中配置了你的驱动器。你已经用一种文件系统格式化了 RAID,并且你已经在格式化的 RAID 上设定了共享文件夹。剩下来的一件事情是配置那些人可以访问这些共享和可以访问多少。这个可以在“Access Rights Management”配置里设置。使用“User”和“Group”选项来设定可以连接到你共享文件夹的用户,并设定这些共享文件的访问权限。

一旦你完成用户配置,就几乎准备好了。你需要从不同客户端机器访问你的共享,但是这是另外一个可以单独写个文章的话题了。

玩得开心!


via: https://opensource.com/article/18/9/openmediavault

作者:Jason van Gumster 选题:lujun9972 译者:jamelouis 校对:wxy

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

如果你正在建一个新的网站,静态页面生成器或许是个正确的选择。

 title=

除非你是像艾米莉·狄金森那样深居简出的人,否则,当做了点事情后,你就会想要与这个世界分享。分享你的作品意味着需要一个网站。当然,你可以只是享受数字时代的便利,使用任何不同的社交网站来将你的作品呈现在观众面前。还有很多选择,不仅仅是传统的社交网站,例如 Artstation、Flickr、Soundcloud、Wattpad,不管你的媒介是什么,总有一款属于你的网站。

实际上,你应该使用这些网站,毕竟,人们都在这些网站上。然而,没有一个地方是真正属于你的。没有一个网站是你能保证不管社交趋势如何,人们都能在该网站上找到你的作品的。

控制权,这是拥有一个在网上属于自己的地方的意义。

但是这篇文章不打算介绍注册域名和托管你的网站。要介绍的是后续的步骤,真正地制作网页。对于很多人来说,典型的选择是使用像 WordPress 那一类的软件。在大多数主机托管商上,只需一次点击即可安装,然后就会有海量的插件和主题可供选择。插件和主题的选择取决于你想要制作的网页的类型。但是 WordPress 不仅对于大部分网站来说有点过犹不及,还给了你一个有许多活动部件的动态页面。如果你没有保持这些部件最新,这些部件可能造成重大安全隐患,你的页面因此被劫持。

替代方法是拥有一个静态网页,在服务端没有任何动态内容生成。只有一些原先的 HTML 和 CSS (或许还有点 Javascript 也挺好)。这种选择的不好的一面是以后你要亲自动手编写所有的代码。虽然可行,但你只是想要个地方来展示你的作品而已,你并不想知道底层网页设计的特性(和重要的但却令人头疼的跨浏览器兼容性)。

使用静态页面生成器。你得到了静态 HTML 页面的速度与安全,但是是以有着接近于动态页面的便利性的工作流程完成的。在静态页面生成器世界的两大先驱是 HugoJekyll ,(顺道说下,Paolo Bonzini 的文章 《Jekyll 起步》 写得不错)但是哪一个才是你的正确选择?希望阅读完这篇文章,你会更加了解。我们将基于易上手性、主题可用性、编辑方式和拓展性这几点评估这两个静态页面生成器。

开始

公平地提醒一下,这两个都需要你在命令行下使用他们。大部分命令都很直接和易于记忆,但是让我们相应地调整下我们的期望吧,这不是点击几下鼠标就能做事的界面。

Jekyll 和 Hugo 的安装都相当的简单。 Jekyll 以 RubyGem 的方式安装,Hugo 提供了一个方便的集成的二进制文件让你迅速上手。因为安装包单一,Hugo 以微弱优势领先。虽然 Jekyll 的 RubyGems 安装方式本身就很简单,但是它确实需要你已经在你的电脑上正确安装并且配置好 Ruby 环境。除了社区设计者和网页开发者,大部分的使用者并没有提前安装好。

虽说是这样,但是一旦安装好,Hugo 和 Jekyll 都很好用。它们都有良好的文档和快速开始指南。你用一个简单命令新建一个页面(在 Jekyll 里是 jekyll new <your_site> ,在 Hugo 里是 hugo new site <your_site>,译者注:<your_site> 指代你网页的名称)。这一步新建了一个通用目录结构和你网站的大致内容。目录结构和基本的配置都十分相似。Jekyll 使用一个 _config.yml 文件,Hugo 使用 config.toml(虽然你在 Hugo 的配置里使用 YMAL 或者 JSON 语法,如果觉得其中一个使用起来更舒服的话)。每个内容文件的 前置配置 front matter 元数据使用相同的配置语法。然后,所有的内容都是用 Markdown 写的。

我想说就帮助你开始第一个静态网页这一点来说,Jekyll 稍微领先于 Hugo ,因为它能以一些基本的内容和一个默认主题开始着手使用。当在建设网页时,你能使用这些内容作为一个样板。Hugo 没有样例内容,甚至没有一个默认主题。即便如此,样例内容和默认主题是我在用任何工具建设网站时第一个删除的内容,因此 Hugo 事实上帮我节省了这一步。

主题

正如我所提到的,Hugo 根本没有默认主题,所以主题可能是你打算最先设置的。Jekyll 有一个得体的默认主题,虽然它只是个骨架。你或许也会想去为你的 Jekyll 页面找一个主题。

Hugo 和 Jekyll 都有多种多样的各类主题,网页样式从单页面的主题到带有博客和评论的完善的多页面主题都有,一应俱全。尽管如此,想找到满足你需求的主题事实上并不简单。无论使用哪个,主题网站——Hugo 的 themes.gohugo.io 和 Jekyll 的 jekyllthemes.org ,基本上都是一个充满主题截图的巨大页面。一旦你点击主题,你能得到关于该主题的一些十分详细的信息,但是对于初步搜索相当困难。Hugo 的主题站有一些基本的标签分类,但是大体上在我看来,主题搜索和展示都是这两个项目需要继续努力的。

主题管理也是一个有趣的主题。在两个项目中,几乎每一个主题都是一个 Git 仓库(经常是托管在 Github 上),你需要 克隆 clone 下来到你的网页建设地。在 Jekyll 里,有额外的使用 RubyGems 的 bundle 的步骤来确保主题是由网站管理的。大部分主题都有一个 Gemfile,使得这一步骤轻松不少。如果主题没有一个 Gemfile,添加也相当简单。在 Hugo 里没有捆绑这一操作,只要在 config.toml 指向你的主题即可。

我发现我偏爱 Hugo 的主题处理。你可以 克隆 clone (或者新建)主题到 themes 里它们自己的子文件夹里。这不仅使得当你开始时能轻松地切换主题,而且也能让你用自己的文件替换主题里的任何组件。这意味着你能根据自己的品味自定义主题,而不用弄乱原始主题,使得这主题也可以通用于其他人。当然如果有一个你觉得其他用户会觉得值得的改变,你仍然可以编辑源文件,提交一个 PR( 拉取请求 pull request )给主题维护者。

工作流程

一旦你设置好初始的配置,Jekyll 和 Hugo 的网站建设流程都很相似。两者都有一个实时的 serve 命令,能在你的电脑上运行一个小型、轻量级的网页服务器,所以你能在在本地测试你的网站而不用上传到哪里。很棒的是无论你是运行着 jekyll serve 还是 hugo serve,都默认配置为当你为之开发时,监视你对网站的任何修改。当你在浏览器里看本地版的网站时,它会根据你的修改自动更新,不管你改的是内容、配置、主题、还仅仅是一张图片。这确实很方便和节约时间。

在两个系统中都是用 Markdown 写你的网站内容。如果碰巧你不熟悉 Markdown,(我来解释下,)它是种很简单的纯文本编写方式,还能有一些很好用的格式化符号。它很容易使用而且可阅读。而且因为是纯文本,你的内容(其实是你的网站)很容易进行版本控制。这是我最近写几乎所有东西的主要方式。

新内容能通过在正确的地方手动创建文件添加到网站里。新的文件只需要是有恰当的 前置配置 front matter 元数据的 Markdown 文件即可。至于配置文件,Jekyll 对于前置配置使用 YAML 语法,Hugo 接受 TOML、YAML 或者 JSON(默认是 TOML)。新文件需要放置在正确的文件夹内,在 Jekyll 里你需要把你编写中的文件和已经完成了的内容页分别放在 _drafts_posts 目录中。在 Hugo 中只有单独一个 content 目录。你可以根据文件的前置配置判断这是否是一个草稿。

现在,虽然可以手动完成所有这些事情,但是 Hugo 提供了一些方便的功能确保你的新文件创建在正确的文件里,那些文件也用恰当的前置配置预先配置好了。简单地在终端中进入你网站的目录,输入 hugo new content/<page.md><page.md> 代表着你想新建的新页面。你甚至可以设置些包含为不同页面自定义的前置配置、叫原型的模版(例如在你的网页上同时有博客和播客)。

当你的网页弄好后,你能关闭你的预览服务器,并用一个命令来建立你网站的真正页面。在 Jekyll 里是 jekyll build,Hugo 就仅仅是 hugo,Jekyll 把完成好的页面放在 _site 的子目录中。然而 Hugo 把这些文件放在名为 public 的子目录中。不管哪种情况,一旦你完成后,你就有了一个完整的静态网站,你能上传并把它托管在几乎任何地方。

可拓展性

Hugo 和 Jekyll 都能让你自定义你自己的网站上哪怕最小的一个点。然而就可拓展性而言,现在 Jekyll 因其插件 API 而远远领先。因为这种插件结构,很容易为你用 Jekyll 生成的网站添加功能,通过 Jekyll 社区或者你自己写的相当短的代码片段就能完成。

Hugo 现在根本没有插件 API,所以添加功能有点难。希望以后支持编写并包含插件。但是现在看不出有人在做这一点。

结论

大体上讲,Hugo 和 Jekyll 十分相似。归根结底由你工作体验和你的网站需求决定。如果你已经设置好了 RubyGems 环境而且你需要插件的可拓展性,Jekyll 是你的选择。然而,如果你看重一个简单的工作流程,一个直接自定义网站的方式,那你首选 Hugo。

我发现我更喜欢 Hugo 的方法,而且在建设一个小型网站,我不需要任何插件。当然,每个人的需求都不同。你会为你的网站选择哪一个静态页面生成器?

(题图:opensource.com)


via: https://opensource.com/article/17/5/hugo-vs-jekyll

作者:Jason van Gumster 译者:ypingcn 校对:wxy

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