document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-03-21 02:10:11 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'LCTT/master'

Browse Source
This commit is contained in:
Xingyu Wang 2020-06-17 08:11:14 +08:00
commit 8bd29f5867
8 changed files with 690 additions and 143 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

55
published/20190218 Talk, then code.md Normal file
View File

@ -0,0 +1,55 @@
[#]: collector: (lujun9972)
[#]: translator: (wxy)
[#]: reviewer: (wxy)
[#]: publisher: (wxy)
[#]: url: (https://linux.cn/article-12319-1.html)
[#]: subject: (Talk, then code)
[#]: via: (https://dave.cheney.net/2019/02/18/talk-then-code)
[#]: author: (Dave Cheney https://dave.cheney.net/author/davecheney)
给开源项目贡献代码时：先讨论，再编码
======
我所参与的开源项目遵循的是一种这样的理念，我把它描述为 “先讨论，再编码”。我认为一般来说这是开发软件的好方法，我想花一点时间来谈谈这种方法的好处。
### 避免伤害感情
先讨论你想做的改变最重要的原因是避免伤害感情。我经常看到一个贡献者闭门造车地提交了一个 PR，却发现他的努力工作被拒绝了。这可能有一堆原因：PR 太大了，PR 没有遵循本地风格，PR 修复了一个对项目不重要的问题或者最近间接修复了的问题，等等。
这些问题的根本原因都是缺乏沟通。“先讨论，再编码” 理念的目标不是阻碍你或给你带来挫折，而是确保一个功能第一次就能正确落地，而不至于产生大量的维护债务。无论是改动的作者，还是审查者，当一个改动突然出现时，并暗示说 “好吧，我已经做完了，你要做的就是合并它，对吧？”，先讨论可以让他们不必背负伤害感情的情绪负担。
### 讨论应该如何进行？
每一个新功能或错误修复都应该在工作开始前与项目的维护者讨论。私下试验是可以的，但不要在没有讨论之前就发送修改。
对于简单的改动，“讨论” 的定义可以只是 GitHub 议题中的一个设计草图。如果你的 PR 修复了一个 bug，你应该链接到它修复的 bug。如果没有，你应该先提出一个 bug，等待维护者确认后再发送 PR。这可能看起来有点落后 —— 谁不希望一个 bug 被修复呢 —— 但考虑到这个 bug 可能是对软件工作方式的误解，也可能是一个更大问题的症状，这需要进一步调查。
对于比较复杂的改动，尤其是功能请求，我建议在发送代码之前，先分发一份设计文档并达成一致。这不一定是一个完整的文档，发一个议题，带个草图可能就足够了，但关键是在用代码搞定之前，先用文字达成一致。
在任何情况下，你都不应该继续发送你的代码，直到维护者同意你的方法是他们所满意的。拉取请求是日常生活，而不仅仅是为了赶着过节。
### 代码审查，而不是由委员会设计
代码审查不是争论设计的地方。这有两个原因。首先，大多数代码审查工具都不适合长长的评论会话，GitHub 的 PR 界面在这方面非常糟糕，Gerrit 比较好，但很少有管理员团队会维护 Gerrit 实例。更重要的是，在代码审查阶段就出现了分歧，说明大家对如何实现这个变化并没有达成一致。
* * *
讨论你想写的代码，然后再写你所讨论的代码。请不要反其道而行之。
--------------------------------------------------------------------------------
via: https://dave.cheney.net/2019/02/18/talk-then-code
作者：[Dave Cheney][a]
选题：[lujun9972][b]
译者：[wxy](https://github.com/wxy)
校对：[wxy](https://github.com/wxy)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://dave.cheney.net/author/davecheney
[b]: https://github.com/lujun9972
[1]: https://dave.cheney.net/2013/09/07/how-to-include-c-code-in-your-go-package (How to include C code in your Go package)
[2]: https://dave.cheney.net/2015/11/05/lets-talk-about-logging (Let’s talk about logging)
[3]: https://dave.cheney.net/2016/04/11/the-value-of-tdd (The value of TDD)
[4]: https://dave.cheney.net/2016/03/12/suggestions-for-contributing-to-an-open-source-project (Suggestions for contributing to an Open Source project)

89
published/20200607 5 ways to boost your Kubernetes knowledge.md Normal file
View File

@ -0,0 +1,89 @@
[#]: collector: "lujun9972"
[#]: translator: "lxbwolf"
[#]: reviewer: "wxy"
[#]: publisher: "wxy"
[#]: url: "https://linux.cn/article-12320-1.html"
[#]: subject: "5 ways to boost your Kubernetes knowledge"
[#]: via: "https://opensource.com/article/20/6/kubernetes-anniversary"
[#]: author: "Seth Kenlon https://opensource.com/users/seth"
提升你 Kubernetes 技能的 5 种方式
======
> 值此周年纪念之际，来通过这些深度文章和实践项目了解下 Kubernetes。
![](https://img.linux.net.cn/data/attachment/album/202006/16/191023lqq0d5zv5vggr2vg.png)
在云原生的成长期，开发者们发现在一个小型的、原子化的、精简的 Linux 镜像里编写应用程序很方便，这些镜像与它们所运行的服务器共享资源。从技术上讲，这些基于内核命名空间的小环境定义被称为[容器][2]。随着容器的激增，系统管理员们很快意识到，开发一个不仅能帮助他们管理容器，还能帮助他们管理下面的虚拟化基础设施的工具变得至关重要。于是，[Kubernetes][3] 应运而生。
Kubernetes 是一个可扩展开源平台，用于管理容器。它可以帮助管理员和开发者们围绕容器管理工作负载、服务和进程。它促进了声明式配置，更容易实现自动化。在它相对较短的生命周期中，它已经催生了一个迅速成长的生态系统，其中包括来自大量公司和项目的服务、支持和工具。
如果你想对这项重要的云技术有更多的了解，这里有一些能帮忙你更深入学习的文章。还有 5 个项目可以帮你把学到的东西付诸实践。
### 遏制容器乱象
2016 年，我们发布了《[使用 Kubernetes 遏制容器乱象][4]》，这是一篇由 Terry Ryan 写的关于 Kubernetes 的介绍性文章，讲述了 Kubernetes 如何帮助管理员和架构师们努力应对容器。如果你想找一篇从底层介绍容器是做什么的以及 Kubernetes 是如何实现容器管理的，那么你应该先读下本文。本文适合零基础的读者，解释了所有重要的概念，因此你能迅速了解相关技术。
如果想进阶了解内核层面发生的一些神奇的事情，请阅读 Jessica Cherry 对 [Kubernetes 命名空间][5]的解释。
延伸阅读：
- [一文了解 Kubernetes 是什么？](https://linux.cn/article-8800-1.html)
- [Kubernetes 是什么？](https://linux.cn/article-8858-1.html)
### Kubernetes：为什么它很重要？
Kubernetes 提供了<ruby>基础设施即服务<rt>Infrastructure-as-a-Service</rt></ruby>（IaaS）解决方案（类似 OpenStack）的便利和一个完整的<ruby>平台即服务<rt>Platform as a Service</rt></ruby>（PaaS）。它为你提供了管理基础设施的抽象能力，以及在裸金属基础层面进行故障排除所需的工具。如果你执着于使用单一的裸金属服务器，你可能需要阅读下 Tim Potter 写的《[你为什么需要 Kubernetes][6]》。他的文章对比了 IaaS 和 PaaS，解释了为什么 Kubernetes 如此广泛地被使用。你可能并不是一定需要 Kubernetes 或容器，但是重要的是知道什么情况下需要。
延伸阅读：
- [使用 Kubernetes 的 5 个理由](https://linux.cn/article-10973-1.html)
- [你（多半）不需要 Kubernetes](https://linux.cn/article-10469-1.html)
### 在树莓派上运行 Kubernetes
熟悉 Kubernetes 的最好方法莫过于自己运行它。不幸的是，不是每个人都有一个云服务基层设施（或者有足够的钱来租用一个）可供其支配。而幸运的是，Chris Collins 提供了《[在树莓派上运行 Kubernetes][7]》的教程。结合他的另外几篇关于《[Cloud-init][8]》和《[Cloud-init 服务][9]》的教程（也是在树莓派上运行），你可以搭建任何你想要的家庭实验室，这样你就可以学习如何管理属于自己的开放混合云。
### Kubernetes 命令
一旦你运行起 Kubernetes 后，可以看看 Jessica Cherry 的文章和附带的备忘清单，这个清单列出了所有的[基本的 Kubernetes 命令][10]。在她的文章中，她解释了 `kubectl` 命令的语法，简单讲述了每个命令和子命令是用来做什么的。
### 有趣的 Kubernetes 项目
没有什么比拥有技术却不知道该怎么用它更令人沮丧的了。例如，在你的办公桌上有一个树莓派是一回事，但是决定它的 CPU 应该用来做什么工作却完全是另一回事。我们发布了很多教程，来指导你完成你的 Kubernetes 之路的探索：
* [Helm][11] 是一个 Kubernetes 的包管理器。你可以在它的帮助下，很快熟悉 Kubernetes 环境。
* 学习下 [Operator SDK][12] 的所有内容，来熟悉 Kubernetes 的对象和操作器。
* [在 Kubernetes 之上搭建网络文件系统（NFS）][13]
* 学习如何使用 [Skipper][14] 或 [Traefik][15] 进行流量调度。
最重要的，花点时间来熟悉容器和 Kubernetes。不论你先把容器化的应用放到服务器、云上还是桌面，它们都是能帮助你理解的重要的范例，因为它们是一个强大的构造，可以让 Linux 的应用变得更好、更健壮、鲁棒性更好、更简单。一定要投入精力去学习它们，你不会后悔的。
--------------------------------------------------------------------------------
via: https://opensource.com/article/20/6/kubernetes-anniversary
作者：[Seth Kenlon][a]
选题：[lujun9972][b]
译者：[lxbwolf](https://github.com/lxbwolf)
校对：[wxy](https://github.com/wxy)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/seth
[b]: https://github.com/lujun9972
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/ship_captain_devops_kubernetes_steer.png?itok=LAHfIpek "Ship captain sailing the Kubernetes seas"
[2]: https://opensource.com/article/18/11/behind-scenes-linux-containers
[3]: https://opensource.com/resources/what-is-kubernetes
[4]: https://opensource.com/life/16/9/containing-container-chaos-kubernetes
[5]: https://linux.cn/article-11749-1.html
[6]: https://linux.cn/article-8902-1.html
[7]: https://linux.cn/article-8499-1.html
[8]: https://opensource.com/article/20/5/cloud-init-raspberry-pi-homelab
[9]: https://opensource.com/article/20/5/create-simple-cloud-init-service-your-homelab
[10]: https://opensource.com/article/20/5/kubectl-cheat-sheet
[11]: https://linux.cn/article-12007-1.html
[12]: https://opensource.com/article/20/3/kubernetes-operator-sdk
[13]: https://opensource.com/article/20/6/kubernetes-nfs-client-provisioning
[14]: https://opensource.com/article/20/4/http-kubernetes-skipper
[15]: https://opensource.com/article/20/3/kubernetes-traefik

164
sources/talk/20200616 Changing the world with open source- GNOME president shares her story.md Normal file
View File

@ -0,0 +1,164 @@
[#]: collector: (lujun9972)
[#]: translator: ( )
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (Changing the world with open source: GNOME president shares her story)
[#]: via: (https://opensource.com/article/20/6/nuritzi-sanchez-interview)
[#]: author: (Don Watkins https://opensource.com/users/don-watkins)
Changing the world with open source: GNOME president shares her story
======
GitLab's new senior open source program manager and founding team member
of Endless OS shares her vision for using open source to improve
society.
![Globe up in the clouds][1]
Growing up in Silicon Valley, [Nuritzi Sanchez][2] saw the powerful impact software can make on the world. Yet, unlike many others who were also steeped in the tech industry, her journey has taken her into the world of open source, where she is contributing to that impact.
After graduating from Stanford University with a degree in International Relations, she ****became a founding team member of open source computing company [Endless OS][3], served three terms as president and chair of GNOME's board of directors, and in February 2020 was hired as the senior open source program manager (OSPM) at GitLab.
I am impressed by this talented woman, and I reached out to her to learn more about her and her work. I believe you will also be fascinated with her journey after reading our interview, which has been lightly edited for clarity.
**Don Watkins:** How did you get started with open source?
**Nuritzi Sanchez**: My first experience with open source software was using an Ubuntu-based computer at an immigration law clinic when I was interning there as an undergrad. I remember being really surprised that something other than Macs and Windows existed. I had a good experience using the Ubuntu machine.
Later, in 2012, I helped start a company called [Endless][4] that aimed to make computing universally accessible. By leveraging the power of open source software, we wanted to create computers that were great for users that had little to no access to the internet or were new to computers.
As I deep-dived into that world, I was amazed by how vast the open source application ecosystem is. In my college years, I had become an Apple fangirl, and I immediately noticed the difference in user experience and design. Thanks to the CEO and founder's strong interest in great design, Endless was created from the beginning to delight users. Our team hoped to bring more user-centered design to the Linux desktop world.
![GUADEC 2015 newcomers' event][5]
GUADEC 2015 newcomers' event (Nuritzi Sanchez, [CC BY-SA 4.0][6])
In 2015, I gave my first talk at [GUADEC][7] (the GNOME community's largest conference) about [adapting GNOME for the developing world][8]. I didn't know what to expect going into the conference since that was the first time I'd attended an open source software event, and I was incredibly impressed with how friendly and welcoming the GNOME community was. The newcomers' and social events helped me bond with the existing community, and when I attended a Birds of a Feather (BoF) session, I noticed that my project management and leadership skillset was immediately useful. Even though I was new to the community and was not an engineer, I felt like I could immediately contribute. I wished I had known about GNOME and the open source world years before!
**DW:** What is the power of open source for you?
**NS**: Open source software helps democratize the world and enables us to solve the challenges we know best. You can build on top of the work that others have done in order to solve unique challenges around you instead of having to recreate something completely from scratch. It thus spurs innovation.
Since a lot of open source software is not only free as in philosophy but also free as in price, it also gives people who may not otherwise be able to afford it access to tools that are essential to be part of the modern workforce.
**DW:** How did your family background drive your interest in open source?
**NS**: My parents are from Mexico, and when we visited family there, I was struck by the differences between where I was growing up, in the Silicon Valley, and where my parents were from. Sometimes we would visit towns where people had cardboard instead of windows, elderly people were sitting in the heat trying to sell artisanal goods they made, and poverty was visible in every corner. I heard heartbreaking stories about the struggles that people were facing, and as an empathetic kid, that all greatly impacted me. I wanted to do something to help.
During my undergraduate years at Stanford, I really struggled to find just one thing that I was interested in. I was drawn to social impact initiatives, but I wanted to help people be healthier, have access to great education, find jobs, and feel fulfilled. I basically wanted to do _all the things_. This led me to explore many potential career paths through internships.
Unsurprisingly for someone who grew up in the Valley, I ended up believing that getting involved with software was the best way for me to make a huge impact. I saw how just a small team could create software that was used by millions of people and could impact their lives. It seemed like a superpower. I then became enamored with open source software because of all the reasons I've mentioned above. As a bonus, open source software usually already has an international community, and as I've gotten more involved, I've been keen on helping to expand its reach.
**DW: How has your involvement with Endless shaped your vision and direction?**
**NS:** One of the things that I loved about Endless is how much the team valued getting to know its users. Every employee was able to go to one of Endless' target markets and do in-field research. We were able to meet people whose lives we were actually being impacted by our work.
My time at Endless allowed me to travel and become immersed in different cultures to an extent that I wouldn't have had otherwise. I sometimes spent several months in a target market when I was helping with special initiatives. I met people from the international open source community who are extremely dedicated to the open source philosophy—and I also learned more about the challenges they face when contributing.
![Endless OS user testing in Guatemala][9]
Endless OS user testing in Guatemala (Nuritzi Sanchez, [CC BY-SA 4.0][6])
The other theme is the importance of user-centered design. I'm very grateful to have been part of a team with extremely talented designers and executives that believed that great design was essential. Our COO attended the [Stanford d.school][10] and helped infuse the company with an appreciation for design thinking. Similarly, our CEO had a sharp eye for things being pixel-perfect and always challenged our designers to create beautiful software. I developed a certain aesthetic and a deep appreciation of the design process. My time at Endless helped me appreciate some of the unique challenges that designers face when trying to contribute to open source software.
**DW:** Diversity and inclusion are really important to you. How does diversity improve products and communities?
**NS**: Diversity of thought is something incredibly important when solving any kind of challenge. In order to do that, you need to bring in people from diverse backgrounds. New perspectives often bring new insights or new ideas into the mix.
One of the tangible examples I have from my time at Endless is when we were working in Indonesia and wanted to do user research there to better understand the market. One of our Endless Ambassadors, Siska, belonged to a group of housewives that met regularly, and she introduced Endless at one of their meetings. Many of the housewives who attended got really excited about Endless and told their partners and children about it. Being great networkers, some of them helped us find people for our user research studies and became evangelists of our product in their communities. It was something that, at least to me, wasn't a normal path to take, and it was something that was hugely beneficial.
![Meeting with open source community members in Indonesia][11]
Meeting with open source community members in Indonesia (Nuritzi Sanchez, [CC BY-SA 4.0][6])
**DW:** What led you to leave Endless and move to GNOME?
**NS**: Endless did a lot of things right, and it still faced a lot of the challenges that all open source desktops face in a world that is [dominated][12] by Microsoft. Endless had to make some hard choices about how to evolve its strategy and also started to explore some new ideas—like how to make Endless a great platform to teach children how to code. It was during this time that we parted ways, but I continue to be a huge fan and still use Endless OS on my personal computer.
I ended up taking some time off after Endless to travel and to continue my third term as the president and chairperson of the board of directors at GNOME.
![Women Who Code Taipei event][13]
Meeting with Women Who Code Taipei (Nuritzi Sanchez, [CC BY-SA 4.0][6])
**DW:** GNOME experienced tremendous growth during your tenure. What do you attribute that to?
**NS**: There were many things that factored into the growth we saw during my tenure. Here are the most important ones:
* **Improving the newcomer's story:** Carlos Soriano, Bastian Ilso, and Christian Hergert, in particular, really helped set GNOME's momentum in motion by working on a newcomer's guide for code contributors. They developed the workflows and tools that made an immediate impact on our community's growth. Later, Carlos led an evaluation of tooling and helped GNOME find GitLab as the solution to further simplifying the contribution process.
* **Broadcasting our story and promoting our brand:** As part of the Engagement team, I helped to amplify our work on the newcomers initiatives and helped to build our brand and online presence. GNOME's work on improving the newcomers' story gained a lot of interest within the wider community and brought about new interest in the GNOME project, and we used that to help build the sense that GNOME was in forward momentum. Marketing, brand, and dedicated community-building are really important for open source organizations.
* [**Flatpak**][14]**,** [**Flathub**][15]**, and** [**Builder**][16]**!** There were several technological innovations that helped propel GNOME forward. For example, Flatpak and Builder helped to make creating a GNOME app easier than ever, and users were able to find and install apps directly from Flathub. These innovations were _huge_ because they made it possible for anyone to create and enjoy great Linux desktops. Furthermore, it helped unify the Linux desktop community a bit since any distribution that enabled Flatpak apps could benefit from easier distribution and management of apps.
* **Hiring an** **executive** **director (ED):** GNOME had been without an ED for several years before I joined. With the help of a hiring committee, the board soon interviewed several highly qualified candidates for the ED position. Leveraging my startup experience in hiring, I worked with our vice president at the time to figure out all the logistics behind hiring our first-ever non-US employee and closing the loop. We soon announced that Neil McGovern would join as the GNOME executive director. This was an important step for us since the board had absorbed the ED's responsibilities while the position was unfilled. Since the board was elected annually, that meant that planning long-term, strategic initiatives was rather difficult because of turnover.
* **Dreaming new dreams:** While I'm biased, I do think that Endless' new perspective helped the GNOME community to dream a new dream and start creating GNOME for a user beyond the "typical Linux desktop user." This meant working on features that enabled a less tech-savvy, more design-sensitive, and less-connected user. Since Endless worked heavily upstream, GNOME experienced an influx of contributors from Endless' employees and Endless' ecosystem. This, combined with the newcomers' story, helped propel GNOME into an era of being more accessible to more people around the world. This also helped attract donations from organizations, including a $1 million pledge that helped GNOME dream new dreams. As part of that, the board decided that expanding the GNOME Foundation would help sustain GNOME's momentum and that employees would be hired for the first time ever to work directly on aspects of the project, like on GTK and event planning.
* **Restructuring the** **GNOME** **Foundation:** One of my short-term goals upon hiring our executive director was leading the board of directors to be more of a strategic entity and allowing the day-to-day work to be handled by employees. I proposed having a board hackathon so that we could set aside time to do some strategic planning, reassess how we did budgeting, and also work on important initiatives that often got pushed to the side. The first hackathon was a success, and it's now an annually recurring event. Once the employees had been hired, we worked on transferring responsibilities to them and helping to integrate them into the larger community. There were some challenges we faced along the way, but overall, this went smoothly, and the community was excited about seeing the Foundation grow to support its needs.
* ![Linux App Summit 2019][17]
Linux App Summit 2019 (Nuritzi Sanchez, [CC BY-SA 4.0][6])
**New policies to enable growth:** While on the board, I helped with some initiatives that also helped us build momentum. Two such policies were our [Code of Conduct][18] and our [Travel Policy][19]. These two helped make the GNOME community more inclusive and helped show that GNOME cares about continuing to build a great and diverse community.
* **Linux App Summit:** Finally, another thing I think helped was the work we did around creating a new conference, the [Linux App Summit][20]. While the conference started in 2016, in 2019, we joined forces with KDE. This doubled attendance and showed the world that KDE and GNOME could work together towards a greater purpose. As part of the founding team of that conference, I'm very proud of our work there.
**DW:** You've recently moved to GitLab as senior open source program manager (OPSM). What are you doing there? What are your short-term and long-term goals there?
**NS**: I am thrilled to be at GitLab! My main focus right now is on the [GitLab for Open Source][21] program, which offers our top tiers for free to qualifying open source projects. As part of that program, we also help large open source organizations with their migrations (GNOME, KDE, Drupal, etc.). I'm working on formalizing aspects of the program and streamlining processes that will allow us to scale the program.
![GitLab's community relations team][22]
GitLab's community relations team (Nuritzi Sanchez, [CC BY-SA 4.0][6])
As I work on this program, I'm being exposed to new open source communities, and I'm learning more about the DevOps world. It's been incredibly rewarding already! My hope is to help make GitLab the best place for open source organizations to thrive at scale, and in order to do so, there are many pieces involved. I see myself advocating for features that are important to open source projects, facilitating communication between our community and our internal team, and working with the community relations team to help make it a great experience to be part of our community. Apart from that, one thing that I've been interested in is how to help make open source more sustainable, so I'm keen on continuing to learn about and explore that topic. Last but not least, I’m also very excited about the work that the CHAOSS community is doing on creating metrics to measure the health of open source communities. I recently joined a new working group there to create a set of metrics that foundations like GNOME and KDE can use to measure their community’s health.
**DW:** Would you recommend other open source companies have OSPMs? What about non-open source companies?
**NS**: Since software is eating the world, and open source software is eating the software world, I absolutely would encourage companies to devote more resources into understanding their dependency on and growing their involvement in open source software.
If a company is just starting off or isn't able to have an open source program office (OSPO) right away, having an open source program manager is a great entry point. These early hires can help lay down some initial structure and work on high-priority initiatives relating to the open source work that the company is doing or wants to participate in. This can later turn into a larger program office if and when the company is ready for that.
* * *
I appreciate the time Nuritizi took to share her journey with me and the work she's doing to support open source and the communities that build up around open source projects. If you'd like to learn more about her, I recommend you join me in following her on [Twitter][2].
--------------------------------------------------------------------------------
via: https://opensource.com/article/20/6/nuritzi-sanchez-interview
作者：[Don Watkins][a]
选题：[lujun9972][b]
译者：[译者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/don-watkins
[b]: https://github.com/lujun9972
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/cloud-globe.png?itok=_drXt4Tn (Globe up in the clouds)
[2]: https://twitter.com/1nuritzi
[3]: https://opensource.com/article/18/2/meet-endless-os-lightweight-linux
[4]: https://endlessos.com/home/
[5]: https://opensource.com/sites/default/files/uploads/guadec_2015.jpg (GUADEC 2015 newcomers' event)
[6]: https://creativecommons.org/licenses/by-sa/4.0/
[7]: https://events.gnome.org/event/1/
[8]: https://www.youtube.com/watch?v=qs5J_IWSmiE
[9]: https://opensource.com/sites/default/files/uploads/endless_usertestingguatemala.jpg (Endless OS user testing in Guatemala)
[10]: https://dschool.stanford.edu/
[11]: https://opensource.com/sites/default/files/uploads/indonesiacommunitygathering.jpg (Meeting with open source community members in Indonesia)
[12]: https://en.wikipedia.org/wiki/Usage_share_of_operating_systems
[13]: https://opensource.com/sites/default/files/uploads/womenwhocodetaipei.jpg (Women Who Code Taipei event)
[14]: https://flatpak.org/
[15]: https://flathub.org/home
[16]: https://wiki.gnome.org/Apps/Builder
[17]: https://opensource.com/sites/default/files/uploads/linuxappsummit2019.jpg (Linux App Summit 2019)
[18]: https://wiki.gnome.org/Foundation/CodeOfConduct
[19]: https://wiki.gnome.org/Travel
[20]: https://linuxappsummit.org/
[21]: https://about.gitlab.com/solutions/open-source/
[22]: https://opensource.com/sites/default/files/uploads/gitlab_cr-team.jpg (GitLab's community relations team)

147
sources/talk/20200616 How to know if you-re ready to switch from Mac to Linux.md Normal file
View File

@ -0,0 +1,147 @@
[#]: collector: (lujun9972)
[#]: translator: ( )
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (How to know if you're ready to switch from Mac to Linux)
[#]: via: (https://opensource.com/article/20/6/mac-to-linux)
[#]: author: (Marko Saric https://opensource.com/users/markosaric)
How to know if you're ready to switch from Mac to Linux
======
You can do nearly anything on Linux that you can do on a Mac—with the
freedom of an open source operating system.
![Digital images of a computer desktop][1]
It's been almost two years since I switched [from Mac to Linux][2]. I used Apple for about 15 years before my move and was a complete Linux newbie when I installed my first distribution in summer 2018.
These days, I run Linux exclusively. I can do anything I want on it. Regular internet browsing and watching Netflix, writing and editing content for my [WordPress blog][3], and even running my [open source web analytics][4] startup.
And I'm not even a developer! Long gone are the days when Linux was considered not ready for everyday usage nor friendly enough for non-technical people.
There's been a lot of discussions lately about the current state of Macs, with an increasing number of people considering making the switch to Linux. I'll share some of my Mac-to-Linux transition tips, so other newbies can make a more comfortable move.
### Should you switch?
Before you switch from Mac to Linux, it's helpful to think about when Linux won't work for you. If your main concerns about switching to Linux are how to pair your Apple Watch, make calls on FaceTime, or use iMovie, this move may not be right for you. These are all proprietary products that Apple keeps under lock and key in its walled garden. If you love Apple's ecosystem, Linux is probably not the right solution for you.
I wasn't very locked into the Apple ecosystem. I didn't have an iPhone, so phone integration was not necessary. I didn't use iCloud, FaceTime, or Siri, either. I was already "open source curious," but I hadn't made the leap.
### Check your favorite apps
I started exploring open source software when I was still on macOS, and I discovered most of the applications I use will run in both environments.
Familiar with Firefox for web browsing? It runs on Linux, too. Use VLC to play media? It's on Linux, too. Use Audacity for audio recording and editing? It's waiting for you on Linux. Live-streaming using OBS Studio? There's a Linux app. Keeping in touch with your family and friends on Telegram messenger? It's also available on Linux.
Also, Linux is not only about open source software. Most (perhaps all) of your favorite non-Apple proprietary apps can be found on Linux, too. Spotify, Slack, Zoom, Steam, Discord, Skype, Chrome, and many other closed source apps are available. In addition, pretty much anything you can run in your browser on macOS can run in your browser on Linux.
It's a good idea to double-check if your must-have apps are available on Linux or if there are adequate or even better Linux alternatives. Do some research using your favorite search engine. Search for "your favorite app + Linux" or "your favorite app + Linux alternatives," and look at [Flathub][5] for proprietary applications you can install on Linux using Flatpak.
### Remember Linux is not Mac
If you want to be comfortable with your move from Mac to Linux, I believe it's important to be open-minded and willing to learn a new operating system. Linux is not macOS, and you need to give yourself some time to get to know it.
If you want Linux to look and work the same way you're used to on macOS, Linux may not be the right solution. Even though there are ways to create a Linux desktop environment with a similar look and feel as macOS, I believe that the best way to have a successful transition to Linux is to start by embracing Linux.
Give its workflow a chance, and use it as it is intended. Do not try to turn Linux into something that it isn't. You may find that you enjoy it as much (or more) than your Mac, as I did.
Remember the first time you used a Mac; you needed some time to get used to the workflow. Give Linux the same time and care.
### Choose a Linux distribution
Unlike Windows and macOS, Linux doesn't have just one, single OS. The different Linux operating systems are called distributions, and I've used and tested several since I've been on Linux. I've also used multiple desktop environments, or graphical user interfaces, too. They differ a lot in terms of aesthetics, usability, workflow, and integrated apps.
While [ElementaryOS][6] and [Pop!_OS][7] come up quite often as Mac alternatives, I recommend starting with [Fedora Workstation][8] for the following reasons:
* It is simple to install to a USB using [Fedora Media Writer][9].
* It is likely to support all of your hardware out of the box.
* It supports the latest Linux software.
* It runs the GNOME desktop environment without any additional customization.
* It has a big community and a large development team behind it.
In my opinion, [GNOME][10] is the best Linux desktop environment in terms of usability, consistency, fluidity, and user experience for newbies coming from macOS. It has the most development resources and the most users in the Linux world, so your chances are good that everything will work great.
Fedora can open the doors of Linux for you, and as you get more comfortable, you can start exploring the world of distributions, desktop environments, and even window managers further.
### Get familiar with GNOME
GNOME is the default window manager for Fedora and many other Linux distributions. Its recent [update to GNOME 3.36][11] brings a modern aesthetic that Mac users will appreciate.
Be prepared that Linux, Fedora Workstation, and GNOME are not Apple and macOS. GNOME is very clean, minimal, modern, and original. There are no distractions. There are no desktop icons. There's no visible dock. There are not even minimize and maximize buttons on your windows. But don't panic. If you give it a chance, it may prove to be the best and most productive operating system you've ever used.
GNOME gets out of your way. When you start it up, the only things you see are the top panel and the background image. The top panel consists of **Activities** on the left, the time and date in the center (which also serves as your notifications center), and tray icons for the network, Bluetooth, VPN, sound, brightness, battery, and such on the right-hand side.
#### How GNOME is like Mac
You'll notice some similarities with macOS, such as window snapping and seeing previews of documents by hitting the **Spacebar** (it works exactly like Quick Look).
If you drag your mouse icon to the top-left, click on **Activities** in the top panel, or press the **Super** key (i.e., the Apple key) on your keyboard, you will get the **Activities Overview**. Activities Overview is kind of like the macOS Mission Control and Spotlight Search in one. It gives you an overview of all the open applications and windows in the center. On the left-hand side, you see the dock, which features all your favorite and open applications. There's an indicator under all the open applications, and on the right-hand side, you can see the different workspaces.
In the top-center, there is a search box. As soon as you start typing, the focus is on that search box. It searches your installed applications and file contents, finds specific apps in the software center, does calculations, gives you the time and weather, and does so much more. It acts pretty much like Spotlight. Simply start typing whatever you're looking for, and press **Enter** to open an application or file.
You can also see a list of all your installed applications (much like Launchpad on Mac). Click on the **Show Applications** icon in the dock or press **Super + A**.
In general, Linux is very lightweight, runs fast even on older hardware, and takes very little disk space compared to macOS. And unlike macOS, you can delete any of the preinstalled apps that you don't want or need.
#### Customize your GNOME settings
Go through GNOME Settings to get more familiar with its options and make changes that may make it more comfortable for you. Here are some of the things I do as soon as I install GNOME:
* In **Mouse &amp; Touchpad**, I disable natural scrolling and enable tap-to-click.
* In **Displays**, I enable night light, which makes the screen color warmer in the evenings to help prevent eye strain.
* I also install [**GNOME Tweaks**][12] to get access to additional settings.
* In Tweaks, I enable **Over-Amplification**, so I can raise the volume above 100%.
* In Tweaks, I enable the **Adwaita Dark** theme, which I prefer to the default, light theme.
#### Get used to working with the keyboard
GNOME is a very keyboard-centric OS, so try to use your keyboard more. In the **Keyboard Shortcut** section of GNOME Settings, you can find a list of the different keyboard shortcuts.
You can also set your keyboard shortcuts to fit your ideal workflow. I set my most-used apps to open using the **Super** key. For example, **Super + B** for my browser, **Super + F** for files, **Super + T** for the terminal, and so on. I also set **Ctrl + Q** to close windows.
I switch between open applications using **Super + Tab**. I use **Super + H** to hide a window. I press **F11** to open an app in full screen. **Super + Left arrow** to snap the current application to the left side of the screen. **Super + Right arrow** to snap it to the right side of the screen. And so on.
### Try Linux on your Mac before committing
You can try Fedora out on your Mac before doing a full installation. Simply download the ISO image file from [Fedora's website][9]. Flash the ISO image file on a USB drive using [Etcher][13], and boot from that drive by pressing the **Option** key when the computer starts so that you can try it live.
Now you can explore the live Fedora Workstation without having to install anything on your Mac. Test different things to see if they work: Can you connect to WiFi? Does your touchpad work? How about audio? And so on.
Spend some time exploring GNOME, too. Test the different features I discussed above. Open some of the installed applications. If everything seems fine, if you like the look and feel of Fedora Workstation and GNOME, and if you are sure that this is what you want, then you can install it on your Mac.
Have fun exploring the world of Linux!
* * *
_This article is an update of [How I switched from macOS to Linux after 15 years of Apple][2] originally published on Marko Saric's website._
--------------------------------------------------------------------------------
via: https://opensource.com/article/20/6/mac-to-linux
作者：[Marko Saric][a]
选题：[lujun9972][b]
译者：[译者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/markosaric
[b]: https://github.com/lujun9972
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/computer_browser_web_desktop.png?itok=Bw8ykZMA (Digital images of a computer desktop)
[2]: https://markosaric.com/linux/
[3]: https://markosaric.com/how-start-blog/
[4]: https://plausible.io/open-source-website-analytics
[5]: https://flathub.org/apps
[6]: https://opensource.com/article/20/2/macbook-linux-elementary
[7]: https://support.system76.com/articles/pop-basics/
[8]: https://getfedora.org/
[9]: https://getfedora.org/en/workstation/download/
[10]: https://www.gnome.org/
[11]: https://www.gnome.org/news/2020/03/gnome-3-36-released/
[12]: https://wiki.gnome.org/Apps/Tweaks
[13]: https://www.balena.io/etcher/

64
sources/tech/20190218 Talk, then code.md
View File

@ -1,64 +0,0 @@
[#]: collector: (lujun9972)
[#]: translator: ( )
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (Talk, then code)
[#]: via: (https://dave.cheney.net/2019/02/18/talk-then-code)
[#]: author: (Dave Cheney https://dave.cheney.net/author/davecheney)
Talk, then code
======
The open source projects that I contribute to follow a philosophy which I describe as _talk, then code_. I think this is generally a good way to develop software and I want to spend a little time talking about the benefits of this methodology.
### Avoiding hurt feelings
The most important reason for discussing the change you want to make is it avoids hurt feelings. Often I see a contributor work hard in isolation on a pull request only to find their work is rejected. This can be for a bunch of reasons; the PR is too large, the PR doesn’t follow the local style, the PR fixes an issue which wasn’t important to the project or was recently fixed indirectly, and many more.
The underlying cause of all these issues is a lack of communication. The goal of the _talk, then code_ philosophy is not to impede or frustrate, but to ensure that a feature lands correctly the first time, without incurring significant maintenance debt, and neither the author of the change, or the reviewer, has to carry the emotional burden of dealing with hurt feelings when a change appears out of the blue with an implicit “well, I’ve done the work, all you have to do is merge it, right?”
### What does discussion look like?
Every new feature or bug fix should be discussed with the maintainer(s) of the project before work commences. It’s fine to experiment privately, but do not send a change without discussing it first.
The definition of _talk_ for simple changes can be as little as a design sketch in a GitHub issue. If your PR fixes a bug, you should link to the bug it fixes. If there isn’t one, you should raise a bug and wait for the maintainers to acknowledge it before sending a PR. This might seem a little backward–who wouldn’t want a bug fixed–but consider the bug could be a misunderstanding in how the software works or it could be a symptom of a larger problem that needs further investigation.
For more complicated changes, especially feature requests, I recommend that a design document be circulated and agreed upon before sending code. This doesn’t have to be a full blown document, a sketch in an issue may be sufficient, but the key is to reach agreement using words, before locking it in stone with code.
In all cases you shouldn’t proceed to send code until there is a positive agreement from the maintainer that the approach is one they are happy with. A pull request is for life, not just for Christmas.
### Code review, not design by committee
A code review is not the place for arguments about design. This is for two reasons. First, most code review tools are not suitable for long comment threads, GitHub’s PR interface is very bad at this, Gerrit is better, but few have a team of admins to maintain a Gerrit instance. More importantly, disagreements at the code review stage suggests there wasn’t agreement on how the change should be implemented.
* * *
Talk about what you want to code, then code what you talked about. Please don’t do it the other way around.
### Related posts:
1. [How to include C code in your Go package][1]
2. [Let’s talk about logging][2]
3. [The value of TDD][3]
4. [Suggestions for contributing to an Open Source project][4]
--------------------------------------------------------------------------------
via: https://dave.cheney.net/2019/02/18/talk-then-code
作者：[Dave Cheney][a]
选题：[lujun9972][b]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://dave.cheney.net/author/davecheney
[b]: https://github.com/lujun9972
[1]: https://dave.cheney.net/2013/09/07/how-to-include-c-code-in-your-go-package (How to include C code in your Go package)
[2]: https://dave.cheney.net/2015/11/05/lets-talk-about-logging (Let’s talk about logging)
[3]: https://dave.cheney.net/2016/04/11/the-value-of-tdd (The value of TDD)
[4]: https://dave.cheney.net/2016/03/12/suggestions-for-contributing-to-an-open-source-project (Suggestions for contributing to an Open Source project)

88
sources/tech/20200616 Hard lessons learned about Kubernetes garbage collection.md Normal file
View File

@ -0,0 +1,88 @@
[#]: collector: (lujun9972)
[#]: translator: ( )
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (Hard lessons learned about Kubernetes garbage collection)
[#]: via: (https://opensource.com/article/20/6/kubernetes-garbage-collection)
[#]: author: (Oleg Matskiv https://opensource.com/users/oleg-matskiv)
Hard lessons learned about Kubernetes garbage collection
======
Why I'll never skim Kubernetes documentation again.
![Ship captain sailing the Kubernetes seas][1]
Some time ago, I learned an important Kubernetes lesson the hard way. The story begins with [Kubernetes Operators][2], which is a method of packaging, deploying, and managing a Kubernetes application. The thing I tripped up on was [garbage collection][3] in the cluster, which cleans up objects that no longer have an owner object (but more on that later).
### The task
Last year, the team I work on was assigned to develop a Kubernetes Operator. For most people on the team, this was their first experience with the [Operator SDK][4] (software development kit) and [Kubernetes controllers][5], which are the control loops that power Kubernetes. We all read some basic introductory information about Operator SDK and followed the [quickstart guide][6] for building an Operator in the Go programming language. We learned some basic principles and a few handy tricks, and we were eager to apply them.
Our task was to develop an Operator that would install, configure, and ensure production readiness for a number of projects. The goal was to have automation for managing a fleet of instances with minimal manual work for our [site reliability engineering (SRE)][7] team. Not an easy task, but we liked the challenge and the technologies we could use, so we were moving fast and breaking some things along the way.
### The bug
Initially, we were chasing a proof of concept implementation, so we logged bugs with a plan to fix them later.
![Decision-making matrix][8]
([Davidjcmorris][9], [CC-BY-SA-4.0][10])
The bug I will describe fits perfectly into Quadrant II of this [Eisenhower Matrix][11] (as Stephen Covey espoused)—not urgent, but important. Very important actually—all the namespaces that our Operator created would sometimes terminate without any request from a user. It didn't happen very often, so we decided to fix it later.
Eventually, I picked up this bug from our backlog and started looking for a root cause. The Operator definitely couldn't terminate the namespace, as we didn't have any Delete API calls written in the code at that point, which, in hindsight, was the first clue. I started my detective work by dialing up the logging on the [Kubernetes API server][12] and making sure the logs were being safely saved. Then I waited for the issue to happen again.
Once the issue occurred in an environment I set up, I searched the logs for this combination of strings: `"requestURI":"/api/v1/namespaces/my-namespace"` \+ `"verb":"delete"`_._
From my search results, I found what was executing the namespace deletion: `"user":{"username":"system:serviceaccount:kube-system:generic-garbage-collector"`.
Now I knew _how_ the namespaces were removed, but I didn't know _why_. I opened the Kubernetes [garbage collection documentation][3], but since I am not a patient man, I just skimmed through the basic information about the `ownerReference` field and continued thinking about why this was happening.
We were using the `ownerReference` metadata field on the namespaces that we created. The owner was our own resource defined by the [custom resource API][13]. And when our custom resource was deleted, the associated namespaces that it owned through the `ownerReference` were deleted as well. This deletion of associated objects made the uninstallation step a breeze.
I didn't see any problem with this, so I continued reading the logs for more clues. I noticed that the namespace would be removed when the `kube-controller-manager` pod restarted. The reason for the restart made sense to me: the `kube-controller-manager` pod runs on the master node, we only had one master node in our development cluster, and the load on that node was very high for the instance size we used.
So I tried to reproduce the issue myself. I deleted the `kube-controller-manager` pod, a new one spun up, and I checked its logs. Once I saw some logs about garbage collection, I finally put two and two together and went back to the garbage collection docs. And there it was:
> "**Note:** Cross-namespace owner references are disallowed by design. This means: 1) Namespace-scoped dependents can only specify owners in the same namespace, and owners that are cluster-scoped. 2) Cluster-scoped dependents can only specify cluster-scoped owners, but not namespace-scoped owners."
Our custom resource was namespace-scoped, but the namespaces are cluster-scoped. And the Kubernetes API server creates namespaces even if the owner reference we use is disallowed by design. So the namespaces were created with the owner references, and then they had to be deleted since garbage collection follows the documented rules. 
### The lessons learned
The technical lesson I learned is simple: Don't use owner references in which a namespace-scoped resource owns a cluster-scoped resource or a resource in a different namespace. When you use these "disallowed by design" owner references, your Kubernetes resources will be deleted by the garbage-collection routine whenever the `kube-controller-manager pod` starts up.
But the more important lesson I learned is _not to underestimate the documentation_. If I was more patient when I read the documentation the first time, I would have definitely saved myself some time.
You might also think that we could have avoided this if we followed my advice back when the invalid owner reference was added to the codebase. But it turns out it was not documented yet. A [pull request][14] in February 2019 added this important note, long after Kubernetes was a well-established technology.
I think this highlights the fact that there is always room for improvement in documentation. Let's do it together, starting with reading the guide to [contributing to Kubernetes docs][15].
--------------------------------------------------------------------------------
via: https://opensource.com/article/20/6/kubernetes-garbage-collection
作者：[Oleg Matskiv][a]
选题：[lujun9972][b]
译者：[译者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/oleg-matskiv
[b]: https://github.com/lujun9972
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/ship_captain_devops_kubernetes_steer.png?itok=LAHfIpek (Ship captain sailing the Kubernetes seas)
[2]: https://kubernetes.io/docs/concepts/extend-kubernetes/operator/
[3]: https://kubernetes.io/docs/concepts/workloads/controllers/garbage-collection/
[4]: https://sdk.operatorframework.io/
[5]: https://kubernetes.io/docs/concepts/architecture/controller/
[6]: https://sdk.operatorframework.io/docs/golang/quickstart/
[7]: https://www.redhat.com/en/topics/devops/what-is-sre
[8]: https://opensource.com/sites/default/files/uploads/512px-7_habits_decision-making_matrix.png (Decision-making matrix)
[9]: https://commons.wikimedia.org/wiki/File:7_habits_decision-making_matrix.png
[10]: https://creativecommons.org/licenses/by-sa/4.0/
[11]: https://en.wikipedia.org/wiki/Time_management#The_Eisenhower_Method
[12]: https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/
[13]: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/
[14]: https://github.com/kubernetes/website/pull/12543
[15]: https://kubernetes.io/docs/contribute/

147
sources/tech/20200616 How to loop forever in bash on Linux.md Normal file
View File

@ -0,0 +1,147 @@
[#]: collector: (lujun9972)
[#]: translator: ( )
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (How to loop forever in bash on Linux)
[#]: via: (https://www.networkworld.com/article/3562576/how-to-loop-forever-in-bash-on-linux.html)
[#]: author: (Sandra Henry-Stocker https://www.networkworld.com/author/Sandra-Henry_Stocker/)
How to loop forever in bash on Linux
======
[tine ivanic][1] [(CC0)][2]
There are a number of ways to loop forever (or until you decide to stop) on Linux and you can do this on the command line or within scripts.
The **for** and **while** commands make the job quite easy. There are only a few things to keep in mind with respect to syntax and tactics.
**[ Also see [Invaluable tips and tricks for troubleshooting Linux][3]. ]**
### Using while
One of the easiest forever-loops involves using the **while** command followed by the condition "true". You don’t have to bother with logic like **while [ 1 -eq 1 ]** or similar tests. The **while true** test means the loop will run until you stop it with **CTRL-C**, close the terminal window or log out. Here's an example:
```
$ while true
> do
> echo Keep running
> sleep 3
> done
Keep running
Keep running
Keep running
^C
```
You can also do the same thing with **while :**. The key here is that the **:** always yields success so, like **while true**, this test doesn’t ever fail and the loop just keeps running.
```
$ while :
> do
> echo Keep running
> sleep 3
> done
Keep running
Keep running
^C
```
If you’ve inserted an infinite loop into a script and want to remind the person who is using it how to exit the script, you can always add a hint using the **echo** command:
```
while :
do
echo Keep running
echo "Press CTRL+C to exit"
sleep 1
done
```
### Using for
The **for** command also provides an easy way to loop forever. While not quite as obvious as **while true**, the syntax is reasonably straightforward. You just replace the parameters in a bounded loop that would generally look something like this "start with c equal to 1 and increment it until reaches 5" specification:
```
$ for (( c=1; c<=5; c++ ))
```
with one that doesn’t specify any parameters:
```
$ for (( ; ; ))
```
With no start value, increment or exit test, this loop will run forever or until it is forcibly stopped.
```
$ for (( ; ; ))
> do
> echo Keep running
> echo “Press CTRL+C to exit”
> sleep 2
> done
Keep your spirits up
Keep your spirits up
Keep your spirits up
```
### Why loop forever?
In real life, you’re not ever going to want to loop forever, but running until it’s time to go home, the work is done or you run into a problem is not at all unusual. Any loop that is constructed as an infinite loop can also be set up to be exited depending on various circumstances.
This script would keep processing data until 5 p.m. or the first time it checks the time after 5 p.m.:
```
#!/bin/bash
while true
do
if [ `date +%H` -ge 17 ]; then
exit # exit script
fi
echo keep running
~/bin/process_data # do some work
done
```
If you want to exit the loop instead of exiting the script, use a **break** command instead of an **exit**.
```
#!/bin/bash
while true
do
if [ `date +%H` -ge 17 ]; then
break # exit loop
fi
echo keep running
~/bin/process_data
done
… run other commands here …
```
#### Wrap-Up
Looping forever is easy. Specifying the conditions under which you want to stop looping takes a little extra effort.
Join the Network World communities on [Facebook][4] and [LinkedIn][5] to comment on topics that are top of mind.
--------------------------------------------------------------------------------
via: https://www.networkworld.com/article/3562576/how-to-loop-forever-in-bash-on-linux.html
作者：[Sandra Henry-Stocker][a]
选题：[lujun9972][b]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://www.networkworld.com/author/Sandra-Henry_Stocker/
[b]: https://github.com/lujun9972
[1]: https://unsplash.com/photos/u2d0BPZFXOY
[2]: https://creativecommons.org/publicdomain/zero/1.0/
[3]: https://www.networkworld.com/article/3242170/linux/invaluable-tips-and-tricks-for-troubleshooting-linux.html
[4]: https://www.facebook.com/NetworkWorld/
[5]: https://www.linkedin.com/company/network-world

79
translated/tech/20200607 5 ways to boost your Kubernetes knowledge.md
View File

@ -1,79 +0,0 @@
[#]: collector: "lujun9972"
[#]: translator: "lxbwolf"
[#]: reviewer: " "
[#]: publisher: " "
[#]: url: " "
[#]: subject: "5 ways to boost your Kubernetes knowledge"
[#]: via: "https://opensource.com/article/20/6/kubernetes-anniversary"
[#]: author: "Seth Kenlon https://opensource.com/users/seth"
提升你 Kubernetes 技能的 5 种方式
======
值此周年纪念之际，来通过这些深耕的上手项目了解下 Kubernetes。
![Ship captain sailing the Kubernetes seas][1]
在云原生的成长期，开发者们发现把应用程序封装到一个微小的、原子的、最小粒度的 Linux 镜像里很方便，服务器可以与运行其上的镜像共享资源。这些小环境的定义被称为[容器][2]，专门基于内核的命名空间。随着容器技术的发展，系统管理员们很快意识到，有必要开发一套工具来帮助他们管理容器及其底层的虚拟基础设施。[Kubernetes][3] 应运而生。
Kubernetes 是一个用来管理容器的可扩展开源平台。它可以帮助管理员和开发者们管理工作负载、服务和容器间的处理。它促进了声明式配置，更容易实现自动化。在它相当短的生命周期中，它催生了大量公司和项目的涉及服务、支持和工具的迅速成长的生态系统。
如果你想对这项重要的云技术有更多的了解，这里有一些能帮忙你更深入学习的文章。下面的 5 个项目可以帮忙你把学到的东西付诸实践。
### 管理各个容器
2016 年，我们发布了[使用 Kubernetes 管理各个容器][4]，一篇由 Terry Ryan 写的关于 Kubernetes 如何帮助管理员和架构师们合理地管理容器的介绍性文章。如果你想找一篇从底层介绍容器是做什么的以及 Kubernetes 是如何实现容器管理的，那么你应该先读下本文。本文适合零基础的读者，解释了所有重要的概念，因此你能迅速了解相关技术。
阅读下 Jessica Cherry 写的 [Kubernetes 命令空间][5]，来从内核级别了解下发生了什么了。
### Kubernetes：你为什么需要它？
Kubernetes 提供了<ruby>基础设施即服务<rt>Infrastructure-as-a-Service</rt></ruby>（IaaS）解决方案（类似 OpenStack）和完全的<ruby>平台即服务<rt>Platform as a Service</rt></ruby>带来的便利。它能提供给你管理基础设施的抽象能力和用来在裸金属的最底层进行问题追踪的工具。如果你想使用单一的裸金属服务，你可能需要阅读下 Tim Potter 写的[你为什么需要 Kubernetes][6]。他的文章对比了 IaaS 和 PaaS，解释了为什么 Kubernetes 如此广泛地被使用。你可能并不是一定需要 Kubernetes 或容器，但是知道什么情况下需要它们是很重要的。
### 在树莓派上运行
自己动手去运行它，这样才是了解 Kubernetes 最好的方式。不幸的是，不是每个人都有自己能支配的云服务器（也没有足够的钱来租服务器）。而幸运的是，Chris Collins 提供了[在树莓派上运行 Kubernetes][7] 的教程。结合他的另外几篇关于 [Cloud-init][8] 和 [Cloud-init 服务][9]的教程（也是在树莓派上运行），你可以搭建喜欢的任何种类的家庭实验室，这样你就可以学习如何管理属于自己的开放混合云。
### Kubernetes 命令
当你运行起 Kubernetes 后，可以查阅下 Jessica Cherry 的文章，跟随着她的备忘清单来做，这个清单列出了所有的[基本的 Kubernetes 命令][10]。在她的文章中，她解释了 `kubectl` 命令的语法，简单讲述了每个命令和子命令是用来做什么的。
### 有趣的 Kubernetes 项目
掌握了某项技术但是不知道用来做什么是最令人沮丧的。例如，把你的树莓派放到桌面上是一回事，但是它的 CPU 应该用来做什么工作却完全是另一回事。我们发布了很多教程，来指导你完成你的 Kubernetes 之路的探索：
* [Helm][11] 是一个 Kubernetes 的包管理器。你可以在它的帮助下，很快熟悉 Kubernetes 环境。
* 学习下 [Operator SDK][12] 的所有内容，来熟悉 Kubernetes 的 object 和 operator。
* [在 Kubernetes 之上搭建网络文件系统（NFS）][13]
* 学习如何使用 [Skipper][14] 或 [Traefik.][15] 进行流量调度。
Most importantly, take the time to get comfortable with containers and Kubernetes. Whether you first embrace containerized apps on the server, cloud, or desktop, they're an important paradigm to understand, because they're a powerful construct that's made applications on Linux better, stronger, more robust, and easier. Invest time to learn more about them. You'll be glad you did.最重要的，花点时间来熟悉容器和 Kubernetes。不论你先把容器化的应用放到服务器、云上还是桌面，它们都是能帮助你理解的重要的范例，因为它们是让 Linux 的应用变得更好、更强壮、鲁棒性更好、更简单的一次强大的构建过程。一定要投入精力去学习它们，你不会后悔的。
--------------------------------------------------------------------------------
via: https://opensource.com/article/20/6/kubernetes-anniversary
作者：[Seth Kenlon][a]
选题：[lujun9972][b]
译者：[lxbwolf](https://github.com/lxbwolf)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/seth
[b]: https://github.com/lujun9972
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/ship_captain_devops_kubernetes_steer.png?itok=LAHfIpek "Ship captain sailing the Kubernetes seas"
[2]: https://opensource.com/article/18/11/behind-scenes-linux-containers
[3]: https://opensource.com/resources/what-is-kubernetes
[4]: https://opensource.com/life/16/9/containing-container-chaos-kubernetes
[5]: https://opensource.com/article/19/12/kubernetes-namespaces
[6]: https://opensource.com/article/17/6/introducing-kubernetes
[7]: https://opensource.com/article/20/6/kubernetes-raspberry-pi
[8]: https://opensource.com/article/20/5/cloud-init-raspberry-pi-homelab
[9]: https://opensource.com/article/20/5/create-simple-cloud-init-service-your-homelab
[10]: https://opensource.com/article/20/5/kubectl-cheat-sheet
[11]: https://opensource.com/article/20/2/kubectl-helm-commands
[12]: https://opensource.com/article/20/3/kubernetes-operator-sdk
[13]: https://opensource.com/article/20/6/kubernetes-nfs-client-provisioning
[14]: https://opensource.com/article/20/4/http-kubernetes-skipper
[15]: https://opensource.com/article/20/3/kubernetes-traefik