mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-02-03 23:40:14 +08:00
Merge branch 'master' of github.com:LCTT/TranslateProject
This commit is contained in:
cposture
commit
6040c13e78
@ -0,0 +1,110 @@
|
||||
Linux 开发者如何看待 Git 和 Github？
|
||||
=====================================================
|
||||
|
||||
### Linux 开发者如何看待 Git 和 Github？
|
||||
|
||||
Git 和 Github 在 Linux 开发者中有很高的知名度。但是开发者如何看待它们呢？另外，Github 是不是真的和 Git 是一个意思？一个 Linux reddit 用户最近问到了这个问题，并且得到了很有意思的答案。
|
||||
|
||||
Dontwakemeup46 提问：
|
||||
|
||||
> 我正在学习 Git 和 Github。我感兴趣社区如何看待两者？据我所知，Git 和 Github 应用十分广泛。但是 Git 或 Github 有没有严重的不足？社区喜欢去改变些什么呢？
|
||||
|
||||
[更多见 Reddit](https://www.reddit.com/r/linux/comments/45jy59/the_popularity_of_git_and_github/)
|
||||
|
||||
与他志同道合的 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 的赞美与批评。（这里有一个[例子](http://www.wired.com/2015/06/problem-putting-worlds-code-github/)），但是我的幼稚问题是为什么不向一个免费开源的版本努力呢？”
|
||||
|
||||
---
|
||||
|
||||
>**Twizmwazin**: “Gitlab 的源码就存在这里”
|
||||
|
||||
---
|
||||
|
||||
[更多见 Reddit](https://www.reddit.com/r/linux/comments/45jy59/the_popularity_of_git_and_github/)
|
||||
|
||||
### DistroWatch 评估 XStream 桌面 153 版本
|
||||
|
||||
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](http://distrowatch.com/weekly.php?issue=20160215#xstreamos)
|
||||
|
||||
### 街头霸王 V 和 SteamOS
|
||||
|
||||
街头霸王是最出名的游戏之一，并且 [Capcom 已经宣布](http://steamcommunity.com/games/310950/announcements/detail/857177755595160250) 街头霸王 V 将会在这个春天进入 Linux 和 StreamOS。这对于 Linux 游戏者是非常好的消息。
|
||||
|
||||
Joe Parlock 为 Destructoid 报道：
|
||||
|
||||
> 你是不足 1% 的那些在 Linux 系统上玩游戏的 Stream 用户吗？你是更少数的那些在 Linux 平台上玩游戏，同时也很喜欢街头霸王 V 的人之一吗？是的话，我有一些好消息要告诉你。
|
||||
|
||||
> Capcom 已经宣布，这个春天街头霸王 V 通过 Stream 进入 StreamOS 以及其他 Linux 发行版。它无需任何额外的花费，所以那些已经在自己的个人电脑上安装了该游戏的人可以很容易在 Linux 上安装它并玩了。
|
||||
|
||||
[更多 Destructoid](https://www.destructoid.com/street-fighter-v-is-coming-to-linux-and-steamos-this-spring-341531.phtml)
|
||||
|
||||
你是否错过了摘要？检查 [开源之眼的主页](http://www.infoworld.com/blog/eye-on-open/) 来获得关于 Linux 和开源的最新的新闻。
|
||||
|
||||
------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.infoworld.com/article/3033059/linux/what-do-linux-developers-think-of-git-and-github.html
|
||||
|
||||
作者：[Jim Lynch][a]
|
||||
译者：[mudongliang](https://github.com/mudongliang)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://www.infoworld.com/author/Jim-Lynch/
|
||||
|
||||
@ -1,23 +1,23 @@
|
||||
在 Ubuntu Mate 16.04("Xenial Xerus") 上通过 PPA 安装 Mate 1.14
|
||||
在 Ubuntu Mate 16.04 上通过 PPA 升级 Mate 1.14
|
||||
=================================================================
|
||||
|
||||
Mate 桌面环境 1.14 现在可以在 Ubuntu Mate 16.04("Xenial Xerus") 上使用了。根据这个[发布版本][1]的描述, 为了全面测试 Mate 1.14，所以在 PPA 上发布 Mate 桌面环境 1.14大概了用2个月的时间。因此，你不太可能遇到安装的问题。
|
||||
Mate 桌面环境 1.14 现在可以在 Ubuntu Mate 16.04 ("Xenial Xerus") 上使用了。根据这个[发布版本][1]的描述，为了全面测试 Mate 1.14，所以 Mate 桌面环境 1.14 已经在 PPA 上发布 2 个月了。因此，你不太可能遇到安装的问题。
|
||||
|
||||
|
||||
|
||||
**现在 PPA 提供 Mate 1.14.1 包含如下改变(Ubuntu Mate 16.04 默认安装的是 Mate 1.12.x):**
|
||||
**现在 PPA 提供 Mate 1.14.1 包含如下改变（Ubuntu Mate 16.04 默认安装的是 Mate 1.12.x）：**
|
||||
|
||||
- 客户端的装饰应用现在可以正确的在所有主题中渲染;
|
||||
- 触摸板配置现在支持边缘操作和双指的滚动;
|
||||
- 在 Caja 中的 Python 扩展可以被单独管理;
|
||||
- 所有三个窗口焦点模式都是是可选的;
|
||||
- Mate Panel 中的所有菜单栏图标和菜单图标可以改变大小;
|
||||
- 音量和亮度 OSD 目前可以启用和禁用;
|
||||
- 更多的改进和 bug 修改;
|
||||
- 客户端的装饰应用现在可以正确的在所有主题中渲染；
|
||||
- 触摸板配置现在支持边缘操作和双指滚动；
|
||||
- 在 Caja 中的 Python 扩展可以被单独管理；
|
||||
- 所有三个窗口焦点模式都是可选的；
|
||||
- Mate Panel 中的所有菜单栏图标和菜单图标可以改变大小；
|
||||
- 音量和亮度 OSD 目前可以启用和禁用；
|
||||
- 更多的改进和 bug 修改；
|
||||
|
||||
Mate 1.14 同时改进了整个桌面环境中对 GTK+3 的支持，包括各种各项的 GTK+3 小应用。但是，Ubuntu MATE 的博客中提到：PPA 的发行包使用 GTK+2编译"为了确保对 Ubuntu MATE 16.05还有各种各样的第三方 MATE 应用，插件，扩展的支持"。
|
||||
Mate 1.14 同时改进了整个桌面环境中对 GTK+ 3 的支持，包括各种 GTK+3 小应用。但是，Ubuntu MATE 的博客中提到：PPA 的发行包使用 GTK+ 2 编译是“为了确保对 Ubuntu MATE 16.04 还有各种各样的第三方 MATE 应用、插件、扩展的支持"。
|
||||
|
||||
MATE 1.14 的完成修改列表[点击此处][2]阅读。
|
||||
MATE 1.14 的完整修改列表[点击此处][2]阅读。
|
||||
|
||||
### 在 Ubuntu MATE 16.04 中升级 MATE 1.14.x
|
||||
|
||||
@ -29,7 +29,7 @@ sudo apt update
|
||||
sudo apt dist-upgrade
|
||||
```
|
||||
|
||||
**注意**: mate-netspeed 应用将会在升级中删除。因为该应用现在已经是 mate-applets 应用报的一部分，所以他依旧是可以获得的。
|
||||
**注意**: mate-netspeed 应用将会在升级中删除。因为该应用现在已经是 mate-applets 应用报的一部分，所以它依旧是可以使用的。
|
||||
|
||||
一旦升级完成，请重启你的系统，享受全新的 MATE!
|
||||
|
||||
@ -51,8 +51,8 @@ via [Ubuntu MATE blog][3]
|
||||
via: http://www.webupd8.org/2016/06/install-mate-114-in-ubuntu-mate-1604.html
|
||||
|
||||
作者：[Andrew][a]
|
||||
译者：[译者ID](https://github.com/MikeCoder)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
译者：[MikeCoder](https://github.com/MikeCoder)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -1,80 +0,0 @@
|
||||
Achieving Enterprise-Ready Container Tools With Wercker’s Open Source CLI
|
||||
===========================================
|
||||
|
||||
For enterprises, containers offer more efficient build environments, cloud-native applications and migration from legacy systems to the cloud. But enterprise adoption of the technology -- Docker specifically -- has been hampered by, among other issues, [a lack of mature developer tools][1].
|
||||
|
||||
Amsterdam-based [Wercker][2] is one of many early-stage companies looking to meet the need for better tools with its cloud platform for automating microservices and application development, based on Docker.
|
||||
|
||||
The company [announced a $4.5 million Series A][3] funding round this month, which will help it ramp up development on an upcoming on-premise enterprise product. Key to its success, however, will be building a community around its newly [open-sourced CLI][4] tool. Wercker must quickly integrate with myriad other container technologies -- open source Kubernetes and Mesos among them -- to remain competitive in the evolving container space.
|
||||
|
||||
“By open sourcing our CLI technology, we hope to get to dev-prod parity faster and turn “build once, ship anywhere” into an automated reality,” said Wercker CEO and founder Micha Hernández van Leuffen.
|
||||
|
||||
I reached out to van Leuffen to learn more about the company, its CLI tool, and how it’s planning to help grow the pool of enterprise customers actually using containers in production. Below is an edited version of the interview.
|
||||
|
||||
### Linux.com: Can you briefly tell us about Wercker?
|
||||
|
||||
van Leuffen: Wercker is a container-centric platform for automating the development of microservices and applications.
|
||||
|
||||
With Wercker’s Docker-based infrastructure, teams can increase developer velocity with custom automation pipelines using steps that produce containers as artifacts. Once the build passes, users can continue to deploy the steps as specified in the wercker.yml. Continuously repeating these steps allows teams to work in small increments, making it easy to debug and ship faster.
|
||||
|
||||
|
||||
|
||||
### Linux.com: How does it help developers?
|
||||
|
||||
van Leuffen: The Wercker CLI helps developers attain greater dev-prod parity. They’re able to release faster and more often because they are developing, building and testing in an environment very similar to that in production. We’ve open sourced the exact same program that we execute in the Wercker cloud platform to run your pipelines.
|
||||
|
||||
### Linux.com: Can you point out some of the features and advantages of your tool as compared to competitors?
|
||||
|
||||
van Leuffen: Unlike some of our competitors, we’re not just offering Docker support. With Wercker, the Docker container is the unit of work. All jobs run inside containers, and each build artifact can be a Docker container.
|
||||
|
||||
Wercker’s Docker container pipeline is completely customizable. A ‘pipeline’ refers to any automated workflow, for instance, a build or deploy pipeline. In those workflows, you want to execute tasks: install dependencies, test your code, push your container, or create a slack notification when something fails, for example. We call these tasks ‘steps,’ and there is no limit to the types of steps created. In fact, we have a marketplace of steps built by the Wercker community. So if you’ve built a step that fits my workflow, I can use that in my pipeline.
|
||||
|
||||
Our Docker container pipelines adapt to any developer workflow. Users can use any Docker container out there — not just those made by or for Wercker. Whether the container is on Docker Hub or a private registry such as CoreOS’s Quay, it works with Wercker.
|
||||
|
||||
Our competitors range from the classic CI/CD tools to larger-scale DevOps solutions like CloudBees.
|
||||
|
||||
### Linux.com: How does it integrate with other cloud technologies?
|
||||
|
||||
van Leuffen: Wercker is vendor-agnostic and can automate development with any cloud platform or service. We work closely with ecosystem partners like Mesosphere, Kubernetes and CoreOS to make integrations as seamless as possible. We also recently partnered with Atlassian to integrate the Wercker platform with Bitbucket. More than 3 million Bitbucket users can install the Wercker Pipeline Viewer and view build status directly from their dashboard.
|
||||
|
||||
### Linux.com: Why did you open source the Wercker CLI tool?
|
||||
|
||||
van Leuffen: Open sourcing the Wercker CLI will help us stay ahead of the curve and strengthen the developer community. The market landscape is changing fast; developers are expected to release more frequently, using infrastructure of increasing complexity. While Docker has solved a lot of infrastructure problems, developer teams are still looking for the perfect tools to test, build and deploy rapidly.
|
||||
|
||||
The Wercker community is already experimenting with these new tools: Kubernetes, Mesosphere, CoreOS. It makes sense to tap that community to create integrations that work with our technology – and make that process as frictionless as possible. By open sourcing our CLI technology, we hope to get to dev-prod parity faster and turn “build once, ship anywhere” into an automated reality.
|
||||
|
||||
### Linux.com: You recently raised over $4.5 million, so how is this fund being used for product development?
|
||||
|
||||
van Leuffen: We’re focused on building out our commercial team and bringing an enterprise product to market. We’ve had a lot of inbound interest from the enterprise looking for VPC and on-premise solutions. While the enterprise is still largely in the discovery stage, we can see the market shifting toward containers. Enterprise software devs need to release often, just like the small, agile teams with whom they are increasingly competing. We need to prove containers can scale, and that Wercker has the organizational permissions and the automation suite to make that process as efficient as possible.
|
||||
|
||||
In addition to continuing to invest in our product, we’ll be focusing our resources on market education and developer evangelism. Developer teams are still looking for the right mix of tools to test, build and deploy rapidly (including Kubernetes, Mesosphere, CoreOS, etc.). As an ecosystem, we need to do more to educate and provide the tutorials and resources to help developers succeed in this changing landscape.
|
||||
|
||||
### Linux.com: What products do you offer and who is your target audience?
|
||||
|
||||
van Leuffen: We currently offer one service level of our product Wercker; however, we’re developing an enterprise offering. Current organizations using Wercker range from startups, such as Open Listings, to larger companies and big agencies, like Pivotal Labs.
|
||||
|
||||
|
||||
### Linux.com: What does this recently open-sourced CLI do?
|
||||
|
||||
van Leuffen: Using the Wercker Command Line Interface (CLI), developers can spin up Docker containers on their desktop, automate their build and deploy processes and then deploy them to various cloud providers, like AWS, and scheduler and orchestration platforms, such as Mesosphere and Kubernetes.
|
||||
|
||||
The Wercker Command Line Interface is available as an open source project on GitHub and runs on both OSX and Linux machines.
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.linux.com/news/enterprise/systems-management/887177-achieving-enterprise-ready-container-tools-with-werckers-open-source-cli
|
||||
|
||||
作者：[Swapnil Bhartiya][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.linux.com/community/forums/person/61003
|
||||
[1]:http://thenewstack.io/adopting-containers-enterprise/
|
||||
[2]:http://wercker.com/
|
||||
[3]:http://venturebeat.com/2016/01/28/wercker-raises-4-5-million-open-sources-its-command-line-tool/
|
||||
[4]:https://github.com/wercker/wercker
|
||||
|
||||
|
||||
@ -1,79 +0,0 @@
|
||||
15 podcasts for FOSS fans
|
||||
=============================
|
||||
|
||||
keyword : FOSS , podcast
|
||||
|
||||
|
||||
|
||||
I listen to a lot of podcasts. A lot. On my phone's podcatcher, I am subscribed to around 60 podcasts... and I think that only eight of those have podfaded (died). Unsurprisingly, a fairly sizeable proportion of those remaining alive-and-well subscriptions are shows with a specific interest or relevance to open source software. As I seek to resurrect my own comatose podcast from the nebulous realm of podfadery, I thought it would be great for us as a community to share what we're listening to.
|
||||
|
||||
>Quick digression: I understand that there are a lot of "pod"-prefixed words in that first paragraph. Furthermore, I also know that the term itself is related to a proprietary device that, by most accounts, isn't even used for listening to these web-based audio broadcasts. However, the term 'webcast' died in the nineties and 'oggcast' never gathered a substantial foothold among the listening public. As such, in order to ensure that the most people actually know what I'm referring to, I'm essentially forced to use the web-anachronistic, but publicly recognized term, podcast.
|
||||
|
||||
I should also mention that a number of these shows involve grown-ups using grown-up language (i.e. swearing). I've tried to indicate which shows these are by putting a red E next to their names, but please do your own due diligence if you're concerned about listening to these shows at work or with children around.
|
||||
|
||||
The following lists are podcasts that I keep in heavy rotation (each sublist is listed in alphabetical order). In the first list are the ones I think of as my "general coverage" shows. They tend to either discuss general topics related to free and open source software, or they give a survey of multiple open source projects from one episode to the next.
|
||||
|
||||
- [Bad Voltage][1] E — Regular contributor and community moderator here on Opensource.com, Jono Bacon, shares hosting dutes on this podcast with Jeremy Garcia, Stuart Langridge, and Bryan Lunduke, four friends with a variety of digressing and intersecting opinions. That's the most interesting part of the show for me. Of course, they also do product reviews and cover timely news relevant to free and open source software, but it's the banter that I stick around for.
|
||||
|
||||
- [FLOSS Weekly][2] — The Twit network of podcasts is a long-time standby in technology broadcasts. Hosted by Randal Schwartz, FLOSS Weekly focuses on covering one open source project each week, typically by interviewing someone relevant in the development of that project. It's a really good show for getting exposed to new open source tools... or learning more about the programs you're already familiar with.
|
||||
|
||||
- [Free as in Freedom][3] — Hosted by Bradley Kuhn and Karen Sandler, this show has a specific focus on legal and policy matters as it relates to both specific free and open source projects, as well as open culture in general. The show seems to have gone on a bit of a hiatus since its last episode in November of 2015, but I for one am immensely hopeful that Free as in Freedom emerges victoriously from its battle with being podfaded and returns to its regular bi-weekly schedule.
|
||||
|
||||
- [GNU World Order][4] — I think that this show can be best descrbed as a free and open source variety show. Solo host, Klaatu, spends the majority of each show going in-depth at nearly tutorial level with a whole range of specific software tools and workflows. It's a really friendly way to get an open source neophyte up to speed with everything from understanding SSH to playing with digital painting and video. And there's a video component to the show, too, which certainly helps make some of these topics easier to follow.
|
||||
|
||||
- [Hacker Public Radio][5] — This is just a well-executed version of a fantastic concept. Hacker Public Radio (HPR) is a community-run daily (well, working-week daily) podcast with a focus on "anything of interest to hackers." Sure there are wide swings in audio quality from show to show, but it's an open platform where anyone can share what they know (or what they think) in that topic space. Show topics include 3D printing, hardware hacking, conference interviews, and more. There are even long-running tutorial series and an audio book club. The monthly recap episodes are particularly useful if you're having trouble picking a place to start. And best of all, you can record your own episode and add it to the schedule. In fact, they actively encourage it.
|
||||
|
||||
My next list of open source podcasts are a bit more specific to particular topics or software packages in the free and open source ecosystem.
|
||||
|
||||
- [Blender Podcast][6] — Although this podcast is very specific to one particular application—Blender, in case you couldn't guess—many of the topics are relevant to issues faced by users and developers of open source other softrware programs. Hosts Thomas Dinges and Campbell Barton—both on the core development team for Blender—discuss the latest happenings in the Blender community, sometimes with a guest. The release schedule is a bit sporadic, but one of the things I really like about this particular show is the fact that they talk about both user issues and developer issues... and the various intersections of the two. It's a great way for each part of the community to gain insight from the other.
|
||||
|
||||
- [Sunday Morning Linux Review][7] — As it's name indicates, SMLR offers a weekly review of topics relevant to Linux. Since around the end of last year, the show has seen a bit of a restructuring. However, that has not detracted from its quality. Tony Bemus, Mary Tomich, and Tom Lawrence deliver a lot of good information, and you can catch them recording their shows live through their website (if you happen to have free time on your Sundays).
|
||||
|
||||
- [LinuxLUGcast][8] — The LinuxLUGcast is a community podcast that's really a recording of an online Linux Users Group (LUG) that meets on the first and third Friday of each month. The group meets (and records) via Mumble and discussions range from home builds with single-board computers like the Raspberry Pi to getting help with trying out a new distro. The LUG is open to everyone, but there is a rotating cast of regulars who've made themselves (and their IRC handles) recognizable fixtures on the show. (Full disclosure: I'm a regular on this one)
|
||||
|
||||
- [The Open EdTech Podcast][9] — Thaj Sara's Open EdTech Podcast is a fairly new show that so far only has three episodes. However, since there's a really sizeable community of open source users in the field of education (both in teaching and in IT), this show serves an important and underserved segment of our community. I've spoken with Thaj via email and he assures me that new episodes are in the pipe. He just needs to set aside the time to edit them.
|
||||
|
||||
- [The Linux Action Show][10] — It would be remiss of me to make a list of open source podcasts and not mention one of the stallwart fixtures in the space: The Linux Action Show. Chris Fisher and Noah Chelliah discuss current news as it pertains to Linux and open source topics while at the same time giving feature attention to specific projects or their own experiences using various open source tools.
|
||||
|
||||
This next section is what I'm going to term my "honorable mention" section. These shows are either new or have a more tangential focus on open source software and culture. In any case, I still think readers of Opensource.com would enjoy listening to these shows.
|
||||
|
||||
- [Blender Institute Podcast][11] — The Blender Institute—the more commercial creative production spin-off from the Blender Foundation—started hosting their own weekly podcast a few months ago. In the show, artists (and now a developer!) working at the Institute discuss the open content projects they're working on, answer questions about using Blender, and give great insight into how things go (or occasionally don't go) in their day-to-day work.
|
||||
|
||||
- [Geek News Radio][12] E — There was a tangible sense of loss about a year ago when the hosts of Linux Outlaws hung up their mics. Well good news! A new show has sprung from its ashes. In episodes of Geek News Radio, Fab Scherschel and Dave Nicholas have a wider focus than Linux Outlaws did. Rather than being an actual news podcast, it's more akin to an informal discussion among friends about video games, movies, technology, and open source (of course).
|
||||
|
||||
- [Geekrant][13] — Formerly known as the Everyday Linux Podcast, this show was rebranded at the start of the year to reflect kind of content that the hosts Mark Cockrell, Seth Anderson, and Chris Neves were already discussing. They do discuss open source software and culture, but they also give their own spin and opinions on topics of interest in general geek culture. Topics have a range that includes everything from popular media to network security. (P.S. Opensource.com content manager Jen Wike Huger was a guest on Episode 164.)
|
||||
|
||||
- [Open Source Creative][14] E — In case you haven't read my little bio blurb, I also have my own podcast. In this show, I talk about news and topics that are [hopefully] of interest to artists and creatives who use free and open source tools. I record it during my work commute so episode length varies with traffic, and I haven't quite figured out a good way to do interviews safely, but if you listen while you're on your way to work, it'll be like we're carpooling. The show has been on a bit of hiatus for almost a year, but I've commited to making sure it comes back... and soon.
|
||||
|
||||
- [Still Untitled][15] E — As you may have noticed from most of the selections on this list, I tend to lean toward the indie side of the spectrum, preferring to listen to shows by people with less of a "name." That said, this show really hits a good place for me. Hosts Adam Savage, Norman Chan, and Will Smith talk about all manner of interesting and geeky things. From Adam's adventures with Mythbusters to maker builds and book reviews, there's rarely ever a show that hasn't been fun for me to listen to.
|
||||
|
||||
So there you go! I'm always looking for more interesting shows to listen to on my commute (as I'm sure many others are). What suggestions or recommendations do you have?
|
||||
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/life/16/3/open-source-podcasts
|
||||
|
||||
作者：[Jason van Gumster][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/jason-van-gumster
|
||||
[1]: http://badvoltage.org/
|
||||
[2]: https://twit.tv/shows/floss-weekly
|
||||
[3]: http://faif.us/
|
||||
[4]: http://gnuworldorder.info/
|
||||
[5]: http://hackerpublicradio.org/
|
||||
[6]: https://blender-podcast.org/
|
||||
[7]: http://smlr.us/
|
||||
[8]: http://linuxlugcast.com/
|
||||
[9]: http://openedtechpodcast.com/
|
||||
[10]: http://www.jupiterbroadcasting.com/tag/linux-action-show/
|
||||
[11]: http://podcast.blender.institute/
|
||||
[12]: http://sixgun.org/geeknewsradio
|
||||
[13]: http://elementopie.com/geekrant-episodes
|
||||
[14]: http://monsterjavaguns.com/podcast
|
||||
[15]: http://www.tested.com/still-untitled-the-adam-savage-project/
|
||||
@ -1,212 +0,0 @@
|
||||
Healthy Open Source
|
||||
============================
|
||||
|
||||
keyword: Node.js , opensource , project management , software
|
||||
|
||||
*A walkthrough of the Node.js Foundation’s base contribution policy*.
|
||||
|
||||
A lot has changed since io.js and Node.js merged under the Node.js Foundation. The most impressive change, and probably the change that is most relevant to the rest of the community and to open source in general, is the growth in contributors and committers to the project.
|
||||
|
||||
A few years ago, Node.js had just a few committers (contributors with write access to the repository in order to merge code and triage bugs). The maintenance overhead for the few committers on Node.js Core was overwhelming and the project began to see a decline in both committers and outside contribution. This resulted in a corresponding decline in releases.
|
||||
|
||||
Today, the Node.js project is divided into many components with a full org size of well over 400 members. Node.js Core now has over 50 committers and over 100 contributors per month.
|
||||
|
||||
Through this growth we’ve found many tools that help scale the human infrastructure around an Open Source project. We also identified a few core values we believe are fundamental to modern Open Source: transparency, participation, and efficacy. As we continue to scale the way we do Open Source we try to find a balance of these values and adapt the practices we find help to fit the needs of each component of the Node.js project.
|
||||
|
||||
Now that Node.js is in a good place, the foundation is looking to promote this kind of sustainability in the ecosystem. Part of this is a new umbrella for additional projects to enter the foundation, of which [Express was recently admitted][1], and the creation of this new contribution policy.
|
||||
|
||||
This contribution policy is not universal. It’s meant as a starting point. Additions and alterations to this policy are encouraged so that the process used by each project fits its needs and can continue to change shape as the project grows and faces new challenges.
|
||||
|
||||
The [current version][2] is hosted in the Node.js Foundation. We expect to iterate on this over time and encourage people to [log issues][3] with questions and feedback regarding the policy for future iterations.
|
||||
|
||||
This document describes a very simple process suitable for most projects in the Node.js ecosystem. Projects are encouraged to adopt this whether they are hosted in the Node.js Foundation or not.
|
||||
|
||||
The Node.js project is organized into over a hundred repositories and a few dozen Working Groups. There are large variations in contribution policy between many of these components because each one has different constraints. This document is a minimalist version of the processes and philosophy we’ve found works best everywhere.
|
||||
|
||||
We believe that contributors should own their projects, and that includes contribution policies like this. While new foundation projects start with this policy we expect many of them to alter it or possibly diverge from it entirely to suite their own specific needs.
|
||||
|
||||
The goal of this document is to create a contribution process that:
|
||||
|
||||
* Encourages new contributions.
|
||||
|
||||
* Encourages contributors to remain involved.
|
||||
|
||||
* Avoids unnecessary processes and bureaucracy whenever possible.
|
||||
|
||||
* Creates a transparent decision making process which makes it clear how contributors can be involved in decision making.
|
||||
|
||||
Most contribution processes are created by maintainers who feel overwhelmed by outside contributions. These documents have traditionally been about processes that make life easier for a small group of maintainers, often at the cost of attracting new contributors.
|
||||
|
||||
We’ve gone the opposite direction. The purpose of this policy is to gain contributors, to retain them as much as possible, and to use a much larger and growing contributor base to manage the corresponding influx of contributions.
|
||||
|
||||
As projects mature, there’s a tendency to become top heavy and overly hierarchical as a means of quality control and this is enforced through process. We use process to add transparency that encourages participation which grows the code review pool which leads to better quality control.
|
||||
|
||||
This document is based on much prior art in the Node.js community, io.js, and the Node.js project.
|
||||
|
||||
This document is based on what we’ve learned growing the Node.js project. Not just the core project, which has been a massive undertaking, but also much smaller sub-projects like the website which have very different needs and, as a result, very different processes.
|
||||
|
||||
When we began these reforms in the Node.js project, we were taking a lot of inspiration from the broader Node.js ecosystem. In particular, Rod Vagg’s [OPEN Open Source policy][4]. Rod’s work in levelup and nan is the basis for what we now call “liberal contribution policies.”
|
||||
|
||||
### Vocabulary
|
||||
|
||||
* A **Contributor** is any individual creating or commenting on an issue or pull request.
|
||||
|
||||
* A **Committer** is a subset of contributors who have been given write access to the repository.
|
||||
|
||||
* A **TC (Technical Committee)** is a group of committers representing the required technical expertise to resolve rare disputes.
|
||||
|
||||
Every person who shows up to comment on an issue or submit code is a member of a project’s community. Just being able to see them means that they have crossed the line from being a user to being a contributor.
|
||||
|
||||
Typically open source projects have had a single distinction for those that have write access to the repository and those empowered with decision making. We’ve found this to be inadequate and have separated this into two distinctions which we’ll dive into more a bit later.
|
||||
|
||||
|
||||
|
||||
healthy 1Looking at the community in and around a project as a bunch of concentric circles helps to visualize this.
|
||||
|
||||
In the outermost circle are users, a subset of those users are contributors, a subset of contributors become committers who can merge code and triage issues. Finally, a smaller group of trusted experts who only get pulled in to the hard problems and can act as a tie-breaker in disputes.
|
||||
|
||||
This is what a healthy project should look like. As the demands on the project from increased users rise, so do the contributors, and as contributors increase more are converted into committers. As the committer base grows, more of them rise to the level of expertise where they should be involved in higher level decision making.
|
||||
|
||||
|
||||
|
||||
If these groups don’t grow in proportion to each other they can’t carry the load imposed on them by outward growth. A project’s ability to convert people from each of these groups is the only way it can stay healthy if its user base is growing.
|
||||
|
||||
This is what unhealthy projects look like in their earliest stages of dysfunction, but imagine that the committers bubble is so small you can’t actually read the word “committers” in it, and imagine this is a logarithmic scale.
|
||||
|
||||
healthy-2A massive user base is pushing a lot of contributions onto a very small number of maintainers.
|
||||
|
||||
This is when maintainers build processes and barriers to new contributions as a means to manage the workload. Often the problems the project is facing will be attributed to the tools the project is using, especially GitHub.
|
||||
|
||||
In Node.js we had all the same problems, resolved them without a change in tooling, and today manage a growing workload much larger than most projects, and GitHub has not been a bottleneck.
|
||||
|
||||
We know what happens to unhealthy projects over a long enough time period, more maintainers leave, contributions eventually fall, and **if we’re lucky** users leave it. When we aren’t so lucky adoption continues and years later we’re plagued with security and stability issues in widely adopt software that can’t be effectively maintained.
|
||||
|
||||
The number of users a project has is a poor indicator of the health of the project, often it is the most used software that suffers the biggest contribution crisis.
|
||||
|
||||
### Logging
|
||||
|
||||
Log an issue for any question or problem you might have. When in doubt, log an issue, any additional policies about what to include will be provided in the responses. The only exception is security disclosures which should be sent privately.
|
||||
|
||||
The first sentence is surprisingly controversial. A lot of maintainers complain that there isn’t a more heavy handed way of forcing people to read a document before they log an issue on GitHub. We have documents all over projects in the Node.js Foundation about writing good bug reports but, first and foremost, we encourage people to log something and try to avoid putting barriers in the way of that.
|
||||
|
||||
Sure, we get bad bugs, but we have a ton of contributors who can immediately work with people who log them to educate them on better practices and treat it as an opportunity to educate. This is why we have documentation on writing good bugs, in order to educate contributors, not as a barrier to entry.
|
||||
|
||||
Creating barriers to entry just reduces the number of people there’s a chance to identify, educate and potentially grow into greater contributors.
|
||||
|
||||
Of course, never log a public issue about a security disclosure, ever. This is a bit vague about the best private venue because we can’t determine that for every project that adopts this policy, but we’re working on a responsible disclosure mechanism for the broader community (stay tuned).
|
||||
|
||||
Committers may direct you to another repository, ask for additional clarifications, and add appropriate metadata before the issue is addressed.
|
||||
|
||||
For smaller projects this isn’t a big deal but in Node.js we’ve had to continually break off work into other, more specific, repositories just to keep the volume on a single repo manageable. But all anyone has to do when someone puts something in the wrong place is direct them to the right one.
|
||||
|
||||
Another benefit of growing the committer base is that there’s more people to deal with little things, like redirecting issues to other repos, or adding metadata to issues and PRs. This allows developers who are more specialized to focus on just a narrow subset of work rather than triaging issues.
|
||||
|
||||
Please be courteous, respectful, and every participant is expected to follow the project’s Code of Conduct.
|
||||
|
||||
One thing that can burn out a project is when people show up with a lot of hostility and entitlement. Most of the time this sentiment comes from a feeling that their input isn’t valued. No matter what, a few people will show up who are used to more hostile environments and it’s good to have these kinds of expectations explicit and written down.
|
||||
|
||||
And each project should have a Code of Conduct, which is an extension of these expectations that makes people feel safe and respected.
|
||||
|
||||
### Contributions
|
||||
|
||||
Any change to resources in this repository must be through pull requests. This applies to all changes to documentation, code, binary files, etc. Even long term committers and TC members must use pull requests.
|
||||
|
||||
No pull request can be merged without being reviewed.
|
||||
|
||||
Every change needs to be a pull request.
|
||||
|
||||
A Pull Request captures the entire discussion and review of a change. Allowing some subset of committers to slip things in without a Pull Request gives the impression to potential contributors that they they can’t be involved in the project because they don’t have access to a behind the scenes process or culture.
|
||||
|
||||
This isn’t just a good practice, it’s a necessity in order to be transparent enough to attract new contributors.
|
||||
|
||||
For non-trivial contributions, pull requests should sit for at least 36 hours to ensure that contributors in other timezones have time to review. Consideration should also be given to weekends and other holiday periods to ensure active committers all have reasonable time to become involved in the discussion and review process if they wish.
|
||||
|
||||
Part of being open and inviting to more contributors is making the process accessible to people in timezones all over the world. We don’t want to add an artificial delay in small doc changes but for any change that needs a bit of consideration needs to give people in different parts of the world time to consider it.
|
||||
|
||||
In Node.js we actually have an even longer timeline than this, 48 hours on weekdays and 72 on weekends. That might be too much for smaller projects so it is shorter in this base policy but as a project grows it may want to increase this as well.
|
||||
|
||||
The default for each contribution is that it is accepted once no committer has an objection. During review committers may also request that a specific contributor who is most versed in a particular area gives a “LGTM” before the PR can be merged. There is no additional “sign off” process for contributions to land. Once all issues brought by committers are addressed it can be landed by any committer.
|
||||
|
||||
A key part of the liberal contribution policies we’ve been building is an inversion of the typical code review process. Rather than the default mode for a change to be rejected until enough people sign off, we make the default for every change to land. This puts the onus on reviewers to note exactly what adjustments need to be made in order for it to land.
|
||||
|
||||
For new contributors it’s a big leap just to get that initial code up and sent. Viewing the code review process as a series of small adjustments and education, rather than a quality control hierarchy, does a lot to encourage and retain these new contributors.
|
||||
|
||||
It’s important not to build processes that encourage a project to be too top heavy, with a few people needing to sign off on every change. Instead, we just mention any committer than we think should weigh in on a specific review. In Node.js we have people who are the experts on OpenSSL, any change to crypto is going to need a LGTM from them. This kind of expertise forms naturally as a project grows and this is a good way to work with it without burning people out.
|
||||
|
||||
In the case of an objection being raised in a pull request by another committer, all involved committers should seek to arrive at a consensus by way of addressing concerns being expressed by discussion, compromise on the proposed change, or withdrawal of the proposed change.
|
||||
|
||||
This is what we call a lazy consensus seeking process. Most review comments and adjustments are uncontroversial and the process should optimize for getting them in without unnecessary process. When there is disagreement, try to reach an easy consensus among the committers. More than 90% of the time this is simple, easy and obvious.
|
||||
|
||||
If a contribution is controversial and committers cannot agree about how to get it to land or if it should land then it should be escalated to the TC. TC members should regularly discuss pending contributions in order to find a resolution. It is expected that only a small minority of issues be brought to the TC for resolution and that discussion and compromise among committers be the default resolution mechanism.
|
||||
|
||||
For the minority of changes that are controversial and don’t reach an easy consensus we escalate that to the TC. These are rare but when they do happen it’s good to reach a resolution quickly rather than letting things fester. Contentious issues tend to get a lot of attention, especially by those more casually involved in the project or even entirely outside of it, but they account for a relatively small amount of what the project does every day.
|
||||
|
||||
### Becoming a Committer
|
||||
|
||||
All contributors who land a non-trivial contribution should be on-boarded in a timely manner, and added as a committer, and be given write access to the repository.
|
||||
|
||||
This is where we diverge sharply from open source tradition.
|
||||
|
||||
Projects have historically guarded commit rights to their version control system. This made a lot of sense when we were using version control systems like subversion. A single contributor can inadvertently mess up a project pretty badly in older version control systems, but not so much in git. In git, there isn’t a lot that can’t be fixed and so most of the quality controls we put on guarding access are no longer necessary.
|
||||
|
||||
Not every committer has the rights to release or make high level decisions, so we can be much more liberal about giving out commit rights. That increases the committer base for code review and bug triage. As a wider range of expertise in the committer pool smaller changes are reviewed and adjusted without the intervention of the more technical contributors, who can spend their time on reviews only they can do.
|
||||
|
||||
This is they key to scaling contribution growth: committer growth.
|
||||
|
||||
Committers are expected to follow this policy and continue to send pull requests, go through proper review, and have other committers merge their pull requests.
|
||||
|
||||
This part is entirely redundant, but on purpose. Just a reminder even once someone is a committer their changes still flow through the same process they followed before.
|
||||
|
||||
### TC Process
|
||||
|
||||
The TC uses a “consensus seeking” process for issues that are escalated to the TC. The group tries to find a resolution that has no open objections among TC members. If a consensus cannot be reached that has no objections then a majority wins vote is called. It is also expected that the majority of decisions made by the TC are via a consensus seeking process and that voting is only used as a last-resort.
|
||||
|
||||
The best solution tends to be the one everyone can agree to so you would think that consensus systems would be the norm. However, **pure consensus** systems incentivize obstructionism which we need to avoid.
|
||||
|
||||
In pure consensus everyone essentially has a veto. So, if I don’t want something to happen I’m in a strong position of power over everyone that wants something to happen. They have to convince me, and I don’t have to convince anyone else of anything.
|
||||
|
||||
To avoid this we use a system called “consensus seeking” which has a long history outside of open source. It’s quite simple, just attempt to reach a consensus, if a consensus can’t be reached then call for a majority wins vote.
|
||||
|
||||
Just the fact that a vote **is a possibility** means that people can’t be obstructionists, whether someone favor a change or not, they have to convince their peers and if they aren’t willing to put in the work to convince their peers then they probably don’t involve themselves in that decision at all.
|
||||
|
||||
The way these incentives play out is pretty impressive. We started using this process in io.js and adopted it in Node.js when we merged into the foundation. In that entire time we’ve never actually had to call for a vote, just the fact that we could is enough to keep everyone working together to find a solution and move forward.
|
||||
|
||||
Resolution may involve returning the issue to committers with suggestions on how to move forward towards a consensus. It is not expected that a meeting of the TC will resolve all issues on its agenda during that meeting and may prefer to continue the discussion happening among the committers.
|
||||
|
||||
A TC tries to resolve things in a timely manner so that people can make progress but often it’s better to provide some additional guidance that pushes the greater contributorship towards resolution without being heavy handed.
|
||||
|
||||
Avoid creating big decision hierarchies. Instead, invest in a broad, growing and empowered contributorship that can make progress without intervention. We need to view a constant need for intervention by a few people to make any and every tough decision as the biggest obstacle to healthy Open Source.
|
||||
|
||||
Members can be added to the TC at any time. Any committer can nominate another committer to the TC and the TC uses its standard consensus seeking process to evaluate whether or not to add this new member. Members who do not participate consistently at the level of a majority of the other members are expected to resign.
|
||||
|
||||
The TC just uses the same consensus seeking process for adding new members as it uses for everything else.
|
||||
|
||||
It’s a good idea to encourage committers to nominate people to the TC and not just wait around for TC members to notice the impact some people are having. Listening to the broader committers about who they see as having a big impact keeps the TC’s perspective inline with the rest of the project.
|
||||
|
||||
As a project grows it’s important to add people from a variety of skill sets. If people are doing a lot of docs work, or test work, treat the investment they are making as equally valuable as the hard technical stuff.
|
||||
|
||||
Projects should have the same ladder, user -> contributor -> commiters -> TC member, for every skill set they want to build into the project to keep it healthy.
|
||||
|
||||
I often see long time maintainers worry about adding people who don’t understand every part of the project, as if they have to be involved in every decision. The reality is that people do know their limitations and want to defer hard decisions to people they know have more experience.
|
||||
|
||||
Thanks to Greg [Wallace][5] and ashley [williams][6].
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.linux.com/news/biz-os/governance/892141-healthy-open-source
|
||||
|
||||
作者：[Mikeal Rogers][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.linux.com/community/forums/person/66928
|
||||
|
||||
|
||||
[1]: https://medium.com/@nodejs/node-js-foundation-to-add-express-as-an-incubator-project-225fa3008f70#.mc30mvj4m
|
||||
[2]: https://github.com/nodejs/TSC/blob/master/BasePolicies/CONTRIBUTING.md
|
||||
[3]: https://github.com/nodejs/TSC/issues
|
||||
[4]: https://github.com/Level/community/blob/master/CONTRIBUTING.md
|
||||
[5]: https://medium.com/@gtewallaceLF
|
||||
[6]: https://medium.com/@ag_dubs
|
||||
@ -1,93 +0,0 @@
|
||||
Linux 开发者如何看待 Git 和 Github？
|
||||
=====================================================
|
||||
|
||||
**同样在今日的开源摘要： DistroWatch 评估 XStream 桌面 153 版本，街头霸王 V 即将在这个春天进入 Linux 和 SteamOS**
|
||||
|
||||
## Linux 开发者如何看待 Git 和 Github？
|
||||
|
||||
Git 和 Github 在 Linux 开发者中有很高的知名度。但是开发者如何看待它们呢？另外，Github 是不是真的和 Git 是一个意思？一个 Linux reddit 用户最近问到了这个问题，并且得到了很有意思的答案。
|
||||
|
||||
Dontwakemeup46 提问：
|
||||
|
||||
> 我正在学习 Git 和 Github。我感兴趣的是社区如何看待两者？据我所知，Git 和 Github 应用十分广泛。但是 Git 或 Github 有没有严重的，社区喜欢去修改的问题呢？
|
||||
|
||||
[更多见 Reddit](http://api.viglink.com/api/click?format=go&jsonp=vglnk_145580413015211&key=0a7039c08493c7c51b759e3d13019dbe&libId=iksc5hc8010113at000DL3yrsuvp7&loc=http%3A%2F%2Fwww.infoworld.com%2Farticle%2F3033059%2Flinux%2Fwhat-do-linux-developers-think-of-git-and-github.html&v=1&out=https%3A%2F%2Fwww.reddit.com%2Fr%2Flinux%2Fcomments%2F45jy59%2Fthe_popularity_of_git_and_github%2F&ref=http%3A%2F%2Fwww.linux.com%2Fnews%2Fsoftware%2Fapplications%2F886008-what-do-linux-developers-think-of-git-and-github&title=What%20do%20Linux%20developers%20think%20of%20Git%20and%20GitHub%3F%20%7C%20InfoWorld&txt=More%20at%20Reddit)
|
||||
|
||||
与他志同道合的 Linux reddit 用户回答了他们对于 Git 和 Github的想法：
|
||||
|
||||
>Derenir: “Github 并不隶属于 Git。
|
||||
|
||||
>Git 是由 Linus Torvalds 开发的。
|
||||
|
||||
>Github 几乎不支持 Linux。
|
||||
|
||||
>Github 是一家唯利是图的，企图借助 Git 赚钱的公司。
|
||||
|
||||
>[https://desktop.github.com/](http://api.viglink.com/api/click?format=go&jsonp=vglnk_145580415025712&key=0a7039c08493c7c51b759e3d13019dbe&libId=iksc5hc8010113at000DL3yrsuvp7&loc=http%3A%2F%2Fwww.infoworld.com%2Farticle%2F3033059%2Flinux%2Fwhat-do-linux-developers-think-of-git-and-github.html&v=1&type=U&out=https%3A%2F%2Fdesktop.github.com%2F&ref=http%3A%2F%2Fwww.linux.com%2Fnews%2Fsoftware%2Fapplications%2F886008-what-do-linux-developers-think-of-git-and-github&title=What%20do%20Linux%20developers%20think%20of%20Git%20and%20GitHub%3F%20%7C%20InfoWorld&txt=https%3A%2F%2Fdesktop.github.com%2F) 并没有支持 Linux。”
|
||||
|
||||
>**Bilog78**: “一个简单的更新： Linus Torvalds 已经不再维护 Git了。维护者是 Junio C Hamano，以及 Linus 之后的主要贡献者是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 的赞美与批评。（这里有一个[例子](http://api.viglink.com/api/click?format=go&jsonp=vglnk_145580428524613&key=0a7039c08493c7c51b759e3d13019dbe&libId=iksc5hc8010113at000DL3yrsuvp7&loc=http%3A%2F%2Fwww.infoworld.com%2Farticle%2F3033059%2Flinux%2Fwhat-do-linux-developers-think-of-git-and-github.html&v=1&out=http%3A%2F%2Fwww.wired.com%2F2015%2F06%2Fproblem-putting-worlds-code-github%2F&ref=http%3A%2F%2Fwww.linux.com%2Fnews%2Fsoftware%2Fapplications%2F886008-what-do-linux-developers-think-of-git-and-github&title=What%20do%20Linux%20developers%20think%20of%20Git%20and%20GitHub%3F%20%7C%20InfoWorld&txt=here%27s%20an%20example)）,但是我的新手问题是为什么不向一个免费开源的版本努力呢？”
|
||||
|
||||
>**Twizmwazin**: “Gitlab 的源码就存在这里”
|
||||
|
||||
[更多见 Reddit](http://api.viglink.com/api/click?format=go&jsonp=vglnk_145580429720714&key=0a7039c08493c7c51b759e3d13019dbe&libId=iksc5hc8010113at000DL3yrsuvp7&loc=http%3A%2F%2Fwww.infoworld.com%2Farticle%2F3033059%2Flinux%2Fwhat-do-linux-developers-think-of-git-and-github.html&v=1&out=https%3A%2F%2Fwww.reddit.com%2Fr%2Flinux%2Fcomments%2F45jy59%2Fthe_popularity_of_git_and_github%2F&ref=http%3A%2F%2Fwww.linux.com%2Fnews%2Fsoftware%2Fapplications%2F886008-what-do-linux-developers-think-of-git-and-github&title=What%20do%20Linux%20developers%20think%20of%20Git%20and%20GitHub%3F%20%7C%20InfoWorld&txt=More%20at%20Reddit)
|
||||
|
||||
## DistroWatch 评估 XStream 桌面 153 版本
|
||||
|
||||
XStreamOS 是一个由 Sonicle 创建的 Solaris 的一个版本。XStream 桌面将 Solaris 的强大带给了桌面用户，同时新手用户很可能有兴趣体验一下。DistroWatch 对于 XStream 桌面 153 版本做了一个很全面的评估，并且发现它运行相当好。
|
||||
|
||||
Jesse Smith 为 DistroWatch 报道:
|
||||
|
||||
> 我认为 XStream 桌面做好了很多事情。无可否认地，我的实验陷入了头晕目眩的状态当操作系统无法在我的硬件上启动。同时，当运行在 VirtualBox 中我无法使得桌面使用我显示器的完整分辨率。
|
||||
|
||||
> 我确实在播放多媒体文件时遇见一些问题，特别是使声卡工作。我不确定是不是另外一个硬件兼容问题，或者一个关于操作系统自带的多媒体软件的问题。另一方面，像 Web 浏览器，电子邮件，生产工具套件以及配置工具这样的工作都工作的很好。
|
||||
|
||||
> 我最欣赏 XStream 的地方是这个操作系统是 OpenSolaris 家族的一个使用保持最新的分支。OpenSolaris 的其他衍生系统有落后的倾向，至少在桌面软件上，但是 XStream 仍然搭载最新版本的火狐和 LibreOffice。
|
||||
|
||||
>对我个人来说，XStream 缺少一些组件，比如打印机管理器，多媒体支持和我特定硬件的驱动。这个操作系统的其他方面也是相当吸引人的。我喜欢开发者搭建 LXDE 的方式，软件的默认组合，以及我最喜欢文件系统快照和启动环境开箱即用的方式。大多数的 Linux 发行版，openSUSE 除外，并没有使得启动环境的有用性流行起来。我希望它是一个被更多项目采用的技术。
|
||||
|
||||
[更多见 DistroWatch](http://api.viglink.com/api/click?format=go&jsonp=vglnk_145580434172315&key=0a7039c08493c7c51b759e3d13019dbe&libId=iksc5hc8010113at000DL3yrsuvp7&loc=http%3A%2F%2Fwww.infoworld.com%2Farticle%2F3033059%2Flinux%2Fwhat-do-linux-developers-think-of-git-and-github.html&v=1&out=http%3A%2F%2Fdistrowatch.com%2Fweekly.php%3Fissue%3D20160215%23xstreamos&ref=http%3A%2F%2Fwww.linux.com%2Fnews%2Fsoftware%2Fapplications%2F886008-what-do-linux-developers-think-of-git-and-github&title=What%20do%20Linux%20developers%20think%20of%20Git%20and%20GitHub%3F%20%7C%20InfoWorld&txt=More%20at%20DistroWatch)
|
||||
|
||||
## 街头霸王 V 和 SteamOS
|
||||
|
||||
街头霸王是最出名的游戏之一，并且 [Capcom 已经宣布](http://api.viglink.com/api/click?format=go&jsonp=vglnk_145580435418216&key=0a7039c08493c7c51b759e3d13019dbe&libId=iksc5hc8010113at000DL3yrsuvp7&loc=http%3A%2F%2Fwww.infoworld.com%2Farticle%2F3033059%2Flinux%2Fwhat-do-linux-developers-think-of-git-and-github.html&v=1&out=http%3A%2F%2Fsteamcommunity.com%2Fgames%2F310950%2Fannouncements%2Fdetail%2F857177755595160250&ref=http%3A%2F%2Fwww.linux.com%2Fnews%2Fsoftware%2Fapplications%2F886008-what-do-linux-developers-think-of-git-and-github&title=What%20do%20Linux%20developers%20think%20of%20Git%20and%20GitHub%3F%20%7C%20InfoWorld&txt=Capcom%20has%20announced) 街头霸王 V 将会在这个春天进入 Linux 和 StreamOS。这对于 Linux 游戏者是非常好的消息。
|
||||
|
||||
Joe Parlock 为 Destructoid 报道：
|
||||
|
||||
>你是少于 1% 的，在 Linux 系统上玩游戏的 Stream 用户吗？你是更少百分比的，在 Linux 平台上玩游戏，同时很喜欢街头霸王 V 的人之一吗？是的话，我有一些好消息要告诉你。
|
||||
|
||||
>Capcom 已经宣布，这个春天街头霸王 V 通过 Stream 进入 StreamOS 以及其他 Linux 发行版。它无需任何额外的成本，所以那些已经个人电脑建立的游戏的人可以很容易在 Linux 上安装它，并且运行良好。
|
||||
|
||||
[更多 Destructoid](http://api.viglink.com/api/click?format=go&jsonp=vglnk_145580435418216&key=0a7039c08493c7c51b759e3d13019dbe&libId=iksc5hc8010113at000DL3yrsuvp7&loc=http%3A%2F%2Fwww.infoworld.com%2Farticle%2F3033059%2Flinux%2Fwhat-do-linux-developers-think-of-git-and-github.html&v=1&out=http%3A%2F%2Fsteamcommunity.com%2Fgames%2F310950%2Fannouncements%2Fdetail%2F857177755595160250&ref=http%3A%2F%2Fwww.linux.com%2Fnews%2Fsoftware%2Fapplications%2F886008-what-do-linux-developers-think-of-git-and-github&title=What%20do%20Linux%20developers%20think%20of%20Git%20and%20GitHub%3F%20%7C%20InfoWorld&txt=Capcom%20has%20announced)
|
||||
|
||||
你是否错过了摘要？检查 [Eye On Open home page](http://www.infoworld.com/blog/eye-on-open/) 来获得关于 Linux 和开源的最新的新闻。
|
||||
|
||||
------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.infoworld.com/article/3033059/linux/what-do-linux-developers-think-of-git-and-github.html
|
||||
|
||||
作者：[Jim Lynch][a]
|
||||
译者：[mudongliang](https://github.com/mudongliang)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://www.infoworld.com/author/Jim-Lynch/
|
||||
|
||||
@ -1,19 +1,19 @@
|
||||
Using Vagrant to control your DigitalOcean cloud instances
|
||||
使用 Vagrant 控制你的 DigitalOcean 云主机
|
||||
=========================================================
|
||||
|
||||
|
||||
|
||||
[Vagrant][1] is an application to create and support virtual development environments using virtual machines. Fedora has [official support for Vagrant][2] with libvirt on your local system. [DigitalOcean][3] is a cloud provider that provides a one-click deployment of a Fedora Cloud instance to an all-SSD server in under a minute. During the [recent Cloud FAD][4] in Raleigh, the Fedora Cloud team packaged a new plugin for Vagrant which enables Fedora users to keep up cloud instances in DigitalOcean using local Vagrantfiles.
|
||||
[Vagrant][1] 是一个创建和管理支持虚拟机开发环境的应用。Fedora 已经[官方支持 Vagrant][2]。[DigitalOcean][3]是一个提供一键部署的云计算服务提供商(主要是 Fedora 的服务实例)。在[最近的 Raleigh 举办的云计算 FAD][4]中，Fedora 云计算队伍已经打包了一个 Vagrant 的新的插件。它能够帮助用户通过使用本地的 Vagrantfile 来管理 DigitalOcean 实例。
|
||||
|
||||
### How to use this plugin
|
||||
### 如何使用 Vagrant DigitalOcean 插件
|
||||
|
||||
First step is to install the package in the command line.
|
||||
第一步是安装 vagrant DigitalOcean 的插件软件包。
|
||||
|
||||
```
|
||||
$ sudo dnf install -y vagrant-digitalocean
|
||||
```
|
||||
|
||||
After installing the plugin, the next task is to create the local Vagrantfile. An example is provided below.
|
||||
安装 结束之后，下一个任务是创建本地的 Vagrantfile 文件。下面是一个例子。
|
||||
|
||||
```
|
||||
$ mkdir digitalocean
|
||||
@ -37,17 +37,17 @@ Vagrant.configure('2') do |config|
|
||||
end
|
||||
```
|
||||
|
||||
### Notes about Vagrant DigitalOcean plugin
|
||||
### Vagrant DigitalOcean 插件
|
||||
|
||||
A few points to remember about the SSH key naming scheme: if you already have the key uploaded to DigitalOcean, make sure that the provider.ssh_key_name matches the name of the existing key in their server. The provider.image details are found at the [DigitalOcean documentation][5]. The AUTH token is created on the control panel within the Apps & API section.
|
||||
一定要记住几个 SSH 命令规范:如果你已经在 DigitalOcean 上传了秘钥，请确保 provider.ssh_key_name 和已经在服务器中的名字吻合。provider.image 具体的文档可以在[DigitalOcean documentation][5]找到。认证 Token 可以在控制管理器的 Apps & API 区域找到。
|
||||
|
||||
You can then get the instance up with the following command.
|
||||
你可以通过以下命令来实例化一台主机。
|
||||
|
||||
```
|
||||
$ vagrant up --provider=digital_ocean
|
||||
```
|
||||
|
||||
This command will fire up the instance in the DigitalOcean server. You can then SSH into the box by using vagrant ssh command. Run vagrant destroy to destroy the instance.
|
||||
这个命令会启动一台 DigitalOcean 的服务器实例。你可以使用 vagrant ssh 命令来 ssh 登陆进入这个实例。执行 vagrant destroy 来废弃这个实例。
|
||||
|
||||
|
||||
|
||||
@ -57,7 +57,7 @@ This command will fire up the instance in the DigitalOcean server. You can then
|
||||
via: https://fedoramagazine.org/using-vagrant-digitalocean-cloud/
|
||||
|
||||
作者：[Kushal Das][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
译者：[译者ID](https://github.com/MikeCoder)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
Loading…
Reference in New Issue
Block a user