mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-03-24 02:20:09 +08:00
Merge remote-tracking branch 'LCTT/master'
This commit is contained in:
Xingyu Wang
commit
bb1fd07bec
@ -1,8 +1,8 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: (wxy)
|
||||
[#]: url: (https://linux.cn/article-12198-1.html)
|
||||
[#]: subject: (Using Files and Folders on Desktop Screen in Ubuntu)
|
||||
[#]: via: (https://itsfoss.com/add-files-on-desktop-ubuntu/)
|
||||
[#]: author: (Abhishek Prakash https://itsfoss.com/author/abhishek/)
|
||||
@ -10,7 +10,9 @@
|
||||
在 Ubuntu 桌面中使用文件和文件夹
|
||||
======
|
||||
|
||||
_**此初学者教程讨论了 在Ubuntu 桌面上添加文件和文件夹时可能遇到的一些困难。**_
|
||||
|
||||
|
||||
> 此初学者教程讨论了 在Ubuntu 桌面上添加文件和文件夹时可能遇到的一些困难。
|
||||
|
||||
我认识一些习惯将所有重要/常用文件放在桌面上以便快速访问的人。
|
||||
|
||||
@ -20,9 +22,9 @@ _**此初学者教程讨论了 在Ubuntu 桌面上添加文件和文件夹时可
|
||||
|
||||
在过去的几个版本中，很难在 Ubuntu 的默认 GNOME 桌面上添加文件。这并不是 Ubuntu 的错。
|
||||
|
||||
[GNOME][2] 的开发者认为，桌面上没有图标和文件的位置。当你可以在菜单中轻松搜索文件时，无需将文件放在桌面上。这部分是事实。
|
||||
[GNOME][2] 的开发者认为，桌面上没有图标和文件的存身之地。当你可以在菜单中轻松搜索文件时，无需将文件放在桌面上。这在部分情况下是事实。
|
||||
|
||||
这就是为什么 [GNOME 的文件管理器 Nautilus][3]的较新版本不能很好地支持桌面上的图标和文件的原因。
|
||||
这就是为什么 [GNOME 的文件管理器 Nautilus][3] 的较新版本不能很好地支持桌面上的图标和文件的原因。
|
||||
|
||||
也就是说，在桌面上添加文件和文件夹并非没有可能。让我告诉你如何做。
|
||||
|
||||
@ -38,7 +40,7 @@ _**此初学者教程讨论了 在Ubuntu 桌面上添加文件和文件夹时可
|
||||
|
||||
![Desktop folder can be used to add files to the desktop screen][5]
|
||||
|
||||
你添加到此文件夹的所有内容都会反应在桌面上。
|
||||
你添加到此文件夹的所有内容都会反映在桌面上。
|
||||
|
||||
![Anything added to the Desktop folder will be reflected on the desktop screen][6]
|
||||
|
||||
@ -46,7 +48,7 @@ _**此初学者教程讨论了 在Ubuntu 桌面上添加文件和文件夹时可
|
||||
|
||||
#### 将文件拖放到桌面不起作用
|
||||
|
||||
现在，如果你尝试在桌面上从文件管理器拖放文件，它会不起使用。这不是一个 bug，它是一个使很多人恼火的功能。
|
||||
现在，如果你尝试从文件管理器往桌面上拖放文件，它会不起使用。这不是一个 bug，它是一个使很多人恼火的功能。
|
||||
|
||||
一种临时方案是打开两个文件管理器。在其中一个打开“桌面”文件夹，然后将文件拖放到该文件夹中，它们将被添加到桌面上。
|
||||
|
||||
@ -54,7 +56,7 @@ _**此初学者教程讨论了 在Ubuntu 桌面上添加文件和文件夹时可
|
||||
|
||||
#### 你不能使用 Ctrl+C 和 Ctrl+V 在桌面上复制粘贴，请使用右键单击菜单
|
||||
|
||||
更恼人的是，你不能使用 Ctrl+V（著名的键盘快捷键）将文件粘贴到桌面上。
|
||||
更恼人的是，你不能使用 `Ctrl+V`（著名的键盘快捷键）将文件粘贴到桌面上。
|
||||
|
||||
但是，你仍然可以使用右键单击，然后选择“粘贴”，将文件复制到桌面上。你甚至可以通过这种方式创建新文件夹。
|
||||
|
||||
@ -64,13 +66,13 @@ _**此初学者教程讨论了 在Ubuntu 桌面上添加文件和文件夹时可
|
||||
|
||||
#### 你无法使用 Delete 键删除文件和文件夹，请再次使用右键菜单
|
||||
|
||||
更糟糕的是，你无法使用 Delete 键或 Shift+Delete 键从桌面上删除文件。但是你仍然可以右键单击文件或文件夹，然后选择“移至回收站”来删除文件。
|
||||
更糟糕的是，你无法使用 `Delete` 键或 `Shift+Delete` 键从桌面上删除文件。但是你仍然可以右键单击文件或文件夹，然后选择“移至回收站”来删除文件。
|
||||
|
||||
![Delete files from desktop using right click][8]
|
||||
|
||||
好了，你现在知道至少有一种方法可以在桌面上添加文件，但有一些限制。不幸的是，这还没有结束。
|
||||
|
||||
你无法在桌面上用名称搜索文件。通常，如果你开始输入 “abc”，那么以 “abc” 开头的文件会高亮显示。你并不明白。
|
||||
你无法在桌面上用名称搜索文件。通常，如果你开始输入 “abc”，那么以 “abc” 开头的文件会高亮显示。但是在这里不行。
|
||||
|
||||
我不知道为什么在桌面上添加文件受到了如此多的限制。值得庆幸的是，我不会经常使用它，否则我会感到非常沮丧。
|
||||
|
||||
@ -83,7 +85,7 @@ via: https://itsfoss.com/add-files-on-desktop-ubuntu/
|
||||
作者：[Abhishek Prakash][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: translator: (lxbwolf)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
|
||||
169
sources/tech/20200508 5 ways to split your Linux terminal.md
Normal file
169
sources/tech/20200508 5 ways to split your Linux terminal.md
Normal file
@ -0,0 +1,169 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (5 ways to split your Linux terminal)
|
||||
[#]: via: (https://opensource.com/article/20/5/split-terminal)
|
||||
[#]: author: (Seth Kenlon https://opensource.com/users/seth)
|
||||
|
||||
5 ways to split your Linux terminal
|
||||
======
|
||||
What's your favorite terminal multiplexer? Take our poll. Then read
|
||||
about how Linux offers plenty of ways for you to split your terminal so
|
||||
you can multitask.
|
||||
![4 different color terminal windows with code][1]
|
||||
|
||||
Is there anything better than a warmly flickering Linux terminal?
|
||||
|
||||
Sure there is: two warmly flickering Linux terminals. In fact, the more, the better.
|
||||
|
||||
Long ago, [terminals were physical devices][2], but of course, today, they're just emulated as an application on your computer. If you prefer the terminal as your interface, you probably know that one terminal is rarely enough. Inevitably, you're going to open a new terminal or a new tab so you can work in it while your first is busy compiling or converting or otherwise processing data.
|
||||
|
||||
If you're a sysadmin, then you know you're going to need at least four open windows while you work on several systems at the same time.
|
||||
|
||||
Terminal applications with tabs have existed on Linux for a long time, and luckily, that trend seems to have caught on such that it's an expected feature of a modern terminal. And yet, sometimes it's distracting or inconvenient to flip back and forth between tabs.
|
||||
|
||||
The only answer is a split screen so that two or more terminals can exist at the same time within just one application window. There are many tools in your Linux kit to help you slice and dice your consoles.
|
||||
|
||||
### Shells, terminals, and consoles
|
||||
|
||||
Before you slice and dice screens, you should know the difference between a terminal, a shell, and a "console." To get the full picture, read my article on the subject over on the [Enable Sysadmin][2] blog.
|
||||
|
||||
The short version:
|
||||
|
||||
* A shell is an input and output screen with a prompt. There's technically a shell running somewhere underneath your [POSIX][3] desktop, even when it's not visible (because it's a shell that launched your user session).
|
||||
* A terminal is an application running within a graphics server (such as X11 or Wayland) with a shell loaded into it. A terminal is only running when you have a terminal window launched. It's more or less a "portal" into your shell.
|
||||
* "Console" or "virtual console" is a term usually used to imply a shell running outside of your desktop. You can get to a virtual console by pressing **Alt-Ctrl-F2** (more are usually available from **F3** up to **F7**, with **F1** or **F7** representing your desktop, depending on your distribution).
|
||||
|
||||
|
||||
|
||||
Some applications let you split your shell or console, while others let you split your terminal.
|
||||
|
||||
### tmux
|
||||
|
||||
![tmux terminal][4]
|
||||
|
||||
Arguably the most flexible and capable of screen splitters, [tmux][5] is a keyboard-centric terminal multiplexer, meaning that you can "layer" one console on top of another and then switch between the two. You can also split a console view in half (or thirds or fourths, and so on) so you can see other consoles next to it.
|
||||
|
||||
All controls center around the keyboard, which means you never have to take your hand off the keys in search of a mouse, but also that you must learn some new keyboard combos.
|
||||
|
||||
If you're using tmux primarily for screen splitting, then the only commands you really need are these:
|
||||
|
||||
* **Ctrl-B %** for a vertical split (one shell on the left, one shell on the right)
|
||||
* **Ctrl-B"** for a horizontal split (one shell at the top, one shell at the bottom)
|
||||
* **Ctrl-B O** to make the other shell active
|
||||
* **Ctrl-B ?** for help
|
||||
* **Ctrl-B d** detach from Tmux, leaving it running in the background (use **tmux attach** to reenter)
|
||||
|
||||
|
||||
|
||||
There are many benefits to tmux, including the ability to start a tmux session on one computer, and then join that same session from another computer remotely. It essentially daemonizes your shell.
|
||||
|
||||
It's with tmux running on a Pi, for example, that I can stay logged into IRC on a permanent basis—I start tmux on the Pi, and then log in from whatever computer I happen to be on. When I log out, tmux continues to run, patiently waiting for me to reattach to the session from a different computer.
|
||||
|
||||
### GNU Screen
|
||||
|
||||
![GNU Screen terminal][6]
|
||||
|
||||
Similar to tmux, [GNU Screen][7] is a shell multiplexer. You can detach and reattach from a running session, and you can split the screen both horizontally and vertically.
|
||||
|
||||
Screen is a little clunkier than tmux. Its default key binding is **Ctrl-A**, which also happens to be Bash's keyboard shortcut to go to the beginning of a line. This means that if you have Screen running, you must press **Ctrl-A** twice instead of just once to go to the beginning of the line. Personally, I redefine the trigger key to **Ctrl-J** with this line in **$HOME/.screenrc**:
|
||||
|
||||
|
||||
```
|
||||
`escape ^jJ`
|
||||
```
|
||||
|
||||
Screen's split function works well, but it leaves out a few pleasantries that tmux lacks. For instance, when you split your shell, a new shell does not start in the other panel. You have to navigate to the other space with **Ctrl-A Tab** (or **Ctrl-J** if you redefine your keyboard shortcut as I do) and create a new shell manually with **Ctrl-A C**.
|
||||
|
||||
Unlike tmux, a split doesn't go away when you exit a shell, which is a design feature that's quite nice in some instances but can also sometimes be cumbersome because it forces you to manage your splits manually.
|
||||
|
||||
Still, Screen is a reliable and flexible application that you can run should you find that **tmux** is unavailable to you.
|
||||
|
||||
Here are the basic split commands, using the default keyboard shortcuts:
|
||||
|
||||
* **Ctrl-A |** for a vertical split (one shell on the left, one shell on the right)
|
||||
* **Ctrl-A S** for a horizontal split (one shell at the top, one shell at the bottom)
|
||||
* **Ctrl-A Tab** to make the other shell active
|
||||
* **Ctrl-A ?** for help
|
||||
* **Ctrl-A d** detach from Screen, leaving it running in the background (use **screen -r** to reenter)
|
||||
|
||||
|
||||
|
||||
### Konsole
|
||||
|
||||
![Konsole screen][8]
|
||||
|
||||
[Konsole][9] is the terminal bundled along with the KDE Plasma desktop. Like KDE itself, Konsole is famous for being highly customizable and powerful.
|
||||
|
||||
Among its many features is the ability to split its window, similar to both tmux and GNU Screen. Because Konsole is a graphical terminal, you can control its split-screen feature with your mouse instead of your keyboard.
|
||||
|
||||
Splitting is found in the **View** menu of Konsole. You can split your window horizontally or vertically. To change which panel is active, just click on it. Each panel is a unique terminal, so it can have its own theme and tabs.
|
||||
|
||||
Unlike tmux and GNU Screen, you can't detach and reattach from Konsole. Like most graphical applications, you use Konsole while you're physically in front of it, and you lose access to it when you're away (unless you use remote desktop software).
|
||||
|
||||
### Emacs
|
||||
|
||||
![Emacs rpg][10]
|
||||
|
||||
Emacs isn't exactly a terminal multiplexer, but its interface supports splitting and resizing, and it has a built-in terminal.
|
||||
|
||||
If you're in Emacs on a daily basis anyway, the ability to split your window between essentially different applications means you never have to leave the familiarity and comfort of your favorite text editor. Furthermore, because the Emacs **eshell** module is implemented in eLISP, you can interact with it using the same commands you use in Emacs itself, making it trivial to copy and yank long file paths or command output.
|
||||
|
||||
If you're using Emacs in a graphical window, you can perform some actions with your mouse. It's faster to use keyboard shortcuts, and some are more or less required. For instance, you can change which panel is the active one by clicking into it, and you can resize the proportions of your split screen with your mouse.
|
||||
|
||||
These are the important keyboard shortcuts:
|
||||
|
||||
* **Ctrl-X 3** for a vertical split (one shell on the left, one shell on the right)
|
||||
* **Ctrl-X 2** for a horizontal split (one shell at the top, one shell at the bottom)
|
||||
* **Ctrl-X O** to make the other shell active (you can also do this with the mouse)
|
||||
* **Ctrl-X 0** (that’s a zero) close the current panel
|
||||
|
||||
|
||||
|
||||
Similar to tmux and GNU Screen, you can detach and reattach from Emacs as long as you run **emacs-client**.
|
||||
|
||||
### Window manager
|
||||
|
||||
![Ratpoison split screen][11]
|
||||
|
||||
Should you think a text editor that can split its screen and load a terminal is amazing, imagine your desktop serving the same purpose. There are Linux desktops, like [Ratpoison][12], [Herbsluftwm][13], i3, Awesome, and even the KDE Plasma desktop with specific settings enabled, that present each application window to you as a fixed tile in a desktop grid.
|
||||
|
||||
Instead of windows floating "above" your desktop, they remain in a predictable place so you can change from one to the other. You can open any number of terminals within your grid, emulating a terminal multiplexer. In fact, you could even load a terminal multiplexer in your desktop multiplexer.
|
||||
|
||||
And there's nothing stopping you from loading Emacs with split buffers inside of that. No one knows what happens if you take it further than that, and most Linux users agree it's best not to find out.
|
||||
|
||||
Unlike tmux and GNU Screen, you can't detach and reattach from your desktop unless you count using remote desktop software.
|
||||
|
||||
### Other options
|
||||
|
||||
Believe it or not, these aren't the only options you have to split your screen on Linux. There are other terminal emulators, like [Tilix][14] and Terminator before it, that can split into sections, and applications with embedded terminal components, and much more. Tell us your favorite way of splitting up your workspace in the comments.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/5/split-terminal
|
||||
|
||||
作者：[Seth Kenlon][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/seth
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/freedos.png?itok=aOBLy7Ky (4 different color terminal windows with code)
|
||||
[2]: https://www.redhat.com/sysadmin/terminals-shells-consoles
|
||||
[3]: https://opensource.com/article/19/7/what-posix-richard-stallman-explains
|
||||
[4]: https://opensource.com/sites/default/files/uploads/terminal-split-tmux2.png (tmux terminal)
|
||||
[5]: https://github.com/tmux/tmux
|
||||
[6]: https://opensource.com/sites/default/files/uploads/terminal-split-screen.png (GNU Screen terminal)
|
||||
[7]: https://www.gnu.org/software/screen/
|
||||
[8]: https://opensource.com/sites/default/files/uploads/konsole.jpg (Konsole screen)
|
||||
[9]: https://konsole.kde.org
|
||||
[10]: https://opensource.com/sites/default/files/uploads/emacs-rpg_0.jpg (Emacs rpg)
|
||||
[11]: https://opensource.com/sites/default/files/uploads/advent-ratpoison-split_0.jpg (Ratpoison split screen)
|
||||
[12]: https://opensource.com/article/19/12/ratpoison-linux-desktop
|
||||
[13]: https://opensource.com/article/19/12/herbstluftwm-linux-desktop
|
||||
[14]: https://gnunn1.github.io/tilix-web/
|
||||
@ -0,0 +1,193 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (A guide to setting up your Open Source Program Office (OSPO) for success)
|
||||
[#]: via: (https://opensource.com/article/20/5/open-source-program-office)
|
||||
[#]: author: (J. Manrique Lopez de la Fuente https://opensource.com/users/jsmanrique)
|
||||
|
||||
A guide to setting up your Open Source Program Office (OSPO) for success
|
||||
======
|
||||
Learn how to best grow and maintain your open source communities and
|
||||
allies.
|
||||
![community team brainstorming ideas][1]
|
||||
|
||||
Companies create Open Source Program Offices (OSPO) to manage their relationship with the open source ecosystems they depend on. By understanding the company's open source ecosystem, an OSPO is able to maximize the company's return on investment and reduce the risks of consuming, contributing to, and releasing open source software. Additionally, since the company depends on its open source ecosystem, ensuring its health and sustainability shall ensure the company's health, sustainable growth, and evolution.
|
||||
|
||||
### How has OSPO become vital to companies and their open source ecosystem?
|
||||
|
||||
Marc Andreessen has said that "software is eating the world," and more recently, it could be said that open source is eating the software world. But how is that process happening?
|
||||
|
||||
Companies get involved with open source projects in several ways. These projects comprise the company's open source ecosystem, and their relationships and interactions can be seen through Open Source Software's (OSS) inbound and outbound processes.
|
||||
|
||||
From the OSS inbound point of view, companies use it to build their own solutions and their own infrastructure. OSS gets introduced because it's part of the code their technology providers use, or because their own developers add open source components to the company's information technology (IT) infrastructure.
|
||||
|
||||
From the OSS outbound point of view, some companies contribute to OSS projects. That contribution could be part of the company's requirements for their solutions that need certain fixes in upstream projects. For example, Samsung contributes to certain graphics-related projects to ensure its hardware has software support once it gets into the market. In some other cases, contributing to OSS is a mechanism to retain talent by allowing the people to contribute to projects different from their daily work.
|
||||
|
||||
Some companies release their own open source projects as an outbound OSS process. For companies like Red Hat or GitLab, it would be expected. But, there are increasingly more non-software companies releasing a lot of OSS, like Lyft.
|
||||
|
||||
![OSS inbound and outbound processes][2]
|
||||
|
||||
OSS inbound and outbound processes
|
||||
|
||||
Ultimately, all of these projects involved in the inbound and outbound OSS flow are the company's OSS ecosystem. And like any living being, the company's health and sustainability depend on the ecosystem that surrounds it.
|
||||
|
||||
### OSPO responsibilities
|
||||
|
||||
Following the species and their ecosystem, people working in the OSPO team could be seen as the rangers in the organization's OSS ecosystem. They take care of the ecosystem and its relationship with the company, to keep everything healthy and sustainable.
|
||||
|
||||
When the company consumes open source software projects, they need to be aware of licenses and compliance, to check the project's health, to ensure there are no security flaws, and, in some cases, to identify talented community members for potential hiring processes.
|
||||
|
||||
When the company contributes to open source software projects, they need to be sure there are no Intellectual Property (IP) issues, to ensure the company contributions' footprint and its leadership in the projects, and sometimes, also to help talented people stay engaged with the company through their contributions.
|
||||
|
||||
And when the company releases and maintains open source projects, they are responsible for ensuring community engagement and growth, for checking there are no IP issues, that the company maintains its footprint and leadership, and perhaps, to attract new talent to the company.
|
||||
|
||||
Have you realized the whole set of skills required in an OSPO team? When I've asked people working in OSPO about the size of their teams, the number is around 1 to 5 people per 1,000 developers in the company. That's a small team to monitor a lot of people and their potential OSS related activity.
|
||||
|
||||
### How to manage an OSPO
|
||||
|
||||
With all these activities in OSPO people's minds and all the resources they need to worry about, how are they able to manage all of this?
|
||||
|
||||
There are at least a couple of open source communities with valuable knowledge and resources available for them:
|
||||
|
||||
* The [TODO Group][3] is "an open group of companies who want to collaborate on practices, tools, and other ways to run successful and effective open source projects and programs." For example, they have a complete set of [guides][4] with best practices for and from companies running OSPOS.
|
||||
* The [CHAOSS (Community Health Analytics for Open Source Software)][5] community develops metrics, methodologies, and software for managing open source project health and sustainability. (See more on CHAOSS' active communities and working groups below).
|
||||
|
||||
|
||||
|
||||
OSPO managers need to report a lot of information to the rest of the company to answer many questions related to their OSS inbound and outbound processes, i.e., Which projects are we using in our organization? What's the health of those projects? Who are the key people in those projects? Which projects are we contributing to? Which projects are we releasing? How are we dealing with community contributions? Who are the key contributors?
|
||||
|
||||
### Data-driven OSPO
|
||||
|
||||
As William Edwards Deming said, "Without data, you are just a person with an opinion."
|
||||
|
||||
Having opinions is not a bad thing, but having opinions based on data certainly makes it easier to understand, discuss, and determine the processes best suited to your company and its goals. CHAOSS is the recommended community to look to for guidance about metrics strategies and tools.
|
||||
|
||||
Recently, the CHAOSS community has released [a new set of metric definitions][6]. These metrics are only subsets of all the ones being discussed in the focus areas of each working group (WG):
|
||||
|
||||
* [Common WG][7]: Defines the metrics that are used by both working groups or are important for community health, but that do not cleanly fit into one of the other existing working groups. Areas of interest include organizational affiliation, responsiveness, and geographic coverage.
|
||||
* [Diversity and Inclusion WG][8]: Gathers experiences regarding diversity and inclusion in open source projects with the goal of understanding, from a qualitative and quantitative point of view, how diversity and inclusion can be measured.
|
||||
* [Evolution WG][9]: Refines the metrics that inform evolution and works with software implementations.
|
||||
* [Risk WG][10]: Refines the metrics that inform risk and works with software implementations.
|
||||
* [Value WG][11]: Focuses on industry-standard metrics for economic value in open source. Their main goal is to publish trusted industry-standard value metrics—a kind of S&P for software development and an authoritative source for metrics significance and industry norms.
|
||||
|
||||
|
||||
|
||||
On the tooling side, projects like [Augur][12], [Cregit][13], and [GrimoireLab][14] are the reference tools that report these metrics, but also many others related to OSPO activities. They are also the seed for new tools and solutions provided by the OSS community like [Cauldron.io][15], a SaaS open source solution to ease OSS ecosystem analysis.
|
||||
|
||||
![CHAOSS Metrics for 15 years of Unity OSS activity. Source: cauldron.io][16]
|
||||
|
||||
CHAOSS Metrics for 15 years of Unity OSS activity. Source: cauldron.io
|
||||
|
||||
All these metrics and data are useless without a metrics strategy. Usually, the first approach is to try to measure as much as possible, producing overwhelming reports and dashboards full of charts and data. What is the value of that?
|
||||
|
||||
Experience has shown that a very valid approach is the [Goal, Questions, Metrics (GQM)][17] strategy. But how do we put that in practice in an OSPO?
|
||||
|
||||
First of all, we need to understand the company's goals when using, consuming, contributing to, or releasing and maintaining OSS projects. The usual goals are related to market positioning, required upstream features development, and talent attraction or retention. Based on these goals, we should write down related questions that can be answered with numbers, like the following:
|
||||
|
||||
#### Who/how many are the core maintainers of my OSS ecosystem projects?
|
||||
|
||||
![Uber OSS code core, regular, and casual contributors evolution. Source: uber.biterg.io][18]
|
||||
|
||||
Uber OSS code core, regular, and casual contributors evolution. Source: uber.biterg.io
|
||||
|
||||
People contribute through different mechanisms or tools (code, issues, comments, tests, etc.). Measuring the core contributors (those that have done 80% of the contributions), the regular ones (those that have done 15% of the contributions), and the casual ones (those have made 5% of the contributions) can answer questions related to participation over time, but also how people move between the different buckets. Adding affiliation information helps to identify external core contributors.
|
||||
|
||||
#### Where are the contributions happening?
|
||||
|
||||
![Uber OSS activity based on location. Source: uber.biterg.io][19]
|
||||
|
||||
Uber OSS activity based on location. Source: uber.biterg.io
|
||||
|
||||
The growth of OSS ecosystems is also related to OSS projects spread across the world. Understanding that spread helps OSPO, and the company, to manage actions that improve support for people from different countries and regions.
|
||||
|
||||
#### What is the company's OSS network?
|
||||
|
||||
![Uber OSS network. Source: uber.biterg.io][20]
|
||||
|
||||
Uber OSS network. Source: uber.biterg.io
|
||||
|
||||
The company's OSS ecosystem includes those projects that the company's people contribute to. Understanding which projects they contribute to offers insight into which technologies or OSS components are interesting to people, and which companies or organizations the company collaborates with.
|
||||
|
||||
#### How is the company dealing with contributions?
|
||||
|
||||
![Github Pull Requests backlog management index and time to close analysis. Source: uber.biterg.io][21]
|
||||
|
||||
Github Pull Requests backlog management index and time to close analysis. Source: uber.biterg.io
|
||||
|
||||
One of the goals when releasing OSS projects is to grow the community around them. Measuring how the company handles contributions to its projects from outside its boundaries helps to understand how "welcoming" it is and identifies mentors (or bottlenecks) and opportunities to lower the barrier to contribute.
|
||||
|
||||
#### Consumers vs. maintainers
|
||||
|
||||
Over the last months, we have been hearing that corporations are taking OSS for free without contributing back. The typical arguments are that these corporations are making millions of dollars thanks to free work, plus the issue of OSS project maintainer burnout due to users' complaints and requests for free support.
|
||||
|
||||
The system is unbalanced; usually, the number of users exceeds the number of maintainers. Is that good or bad? Having users for our software is (or should be) good. But we need to manage expectations on both sides.
|
||||
|
||||
From the corporation's point of view, consuming OSS without care is very, very risky.
|
||||
|
||||
OSPO can play an important role in educating the company about the risks they are facing, and how to reduce them by contributing back to their OSS ecosystem. Remember, a company's overall sustainability could rely heavily on its ecosystem sustainability.
|
||||
|
||||
A good strategy is to start shifting your company from being pure OSS consumers to becoming contributors to their OSS inbound projects. From just submitting issues and asking questions to help solve issues, answering questions, and even sending patches, contributing helps grow and maintain the project while giving back to the community. It doesn't happen immediately, but over time, the company will be perceived as an OSS ecosystem citizen. Eventually, some people from the company could end up helping to maintain those projects too.
|
||||
|
||||
And what about money? There are plenty of ways to support the OSS ecosystem financially. Some examples:
|
||||
|
||||
* Business initiatives like [Tidelift][22], or [OpenCollective][23]
|
||||
* Foundations and their supporting mechanisms, like [Software Freedom Conservancy][24], or [CommunityBridge][25] from the Linux Foundation
|
||||
* Self-funding programs (like [Indeed][26] and [Salesforce][27] have done)
|
||||
* Emerging gig development approaches like [Github Sponsors][28] or [Patreon][29]
|
||||
|
||||
|
||||
|
||||
Last but not least, companies need to avoid the "not invented here" syndrome. For some OSS projects, there might be companies providing consulting, customization, maintenance, and/or support services. Instead of taking OSS and spending time and people to self-host, self-customize, or try to bring those kinds of services in-house, it might be smarter and more efficient to hire some of those companies to do the thought work.
|
||||
|
||||
As a final remark, I would like to emphasize the importance of an OSPO for a company to succeed and grow in the current market. As shepherds of the company's OSS ecosystem, they are the best people in the organization to understand how the ecosystem works and flows, and they should be empowered to manage, monitor, and make recommendations and decisions to ensure sustainability and growth.
|
||||
|
||||
Does your organization have an OSPO yet?
|
||||
|
||||
Six common traits of successful open source programs, and a look back at how the open source...
|
||||
|
||||
Why would a company not in the business of software development create an open source program...
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/5/open-source-program-office
|
||||
|
||||
作者：[J. Manrique Lopez de la Fuente][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/jsmanrique
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/meeting_discussion_brainstorm.png?itok=7_m4CC8S (community team brainstorming ideas)
|
||||
[2]: https://opensource.com/sites/default/files/uploads/ospo_1.png (OSS inbound and outbound processes)
|
||||
[3]: https://todogroup.org/
|
||||
[4]: https://todogroup.org/guides/
|
||||
[5]: https://chaoss.community/
|
||||
[6]: https://chaoss.community/metrics/
|
||||
[7]: https://github.com/chaoss/wg-common
|
||||
[8]: https://github.com/chaoss/wg-diversity-inclusion
|
||||
[9]: https://github.com/chaoss/wg-evolution
|
||||
[10]: https://github.com/chaoss/wg-risk
|
||||
[11]: https://github.com/chaoss/wg-value
|
||||
[12]: https://github.com/chaoss/augur
|
||||
[13]: https://github.com/cregit
|
||||
[14]: https://chaoss.github.io/grimoirelab/
|
||||
[15]: https://cauldron.io/
|
||||
[16]: https://opensource.com/sites/default/files/uploads/ospo_2.png (CHAOSS Metrics for 15 years of Unity OSS activity. Source: cauldron.io)
|
||||
[17]: https://en.wikipedia.org/wiki/GQM
|
||||
[18]: https://opensource.com/sites/default/files/uploads/ospo_3.png (Uber OSS code core, regular, and casual contributors evolution. Source: uber.biterg.io)
|
||||
[19]: https://opensource.com/sites/default/files/uploads/ospo_4.png (Uber OSS activity based on location. Source: uber.biterg.io)
|
||||
[20]: https://opensource.com/sites/default/files/uploads/ospo_5_0.png (Uber OSS network. Source: uber.biterg.io)
|
||||
[21]: https://opensource.com/sites/default/files/uploads/ospo_6.png (Github Pull Requests backlog management index and time to close analysis. Source: uber.biterg.io)
|
||||
[22]: https://tidelift.com/
|
||||
[23]: https://opencollective.com/
|
||||
[24]: https://sfconservancy.org/
|
||||
[25]: https://funding.communitybridge.org/
|
||||
[26]: https://engineering.indeedblog.com/blog/2019/02/sponsoring-osi/
|
||||
[27]: https://sustain.codefund.fm/23
|
||||
[28]: https://help.github.com/en/github/supporting-the-open-source-community-with-github-sponsors
|
||||
[29]: https://www.patreon.com/
|
||||
@ -0,0 +1,70 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Getting started with FreeBSD as a desktop operating system)
|
||||
[#]: via: (https://opensource.com/article/20/5/furybsd-linux)
|
||||
[#]: author: (Joshua Allen Holm https://opensource.com/users/holmja)
|
||||
|
||||
Getting started with FreeBSD as a desktop operating system
|
||||
======
|
||||
FuryBSD's live desktop environment lets you try it before committing to
|
||||
it.
|
||||
![web development and design, desktop and browser][1]
|
||||
|
||||
[FreeBSD][2] is a great operating system, but, by design, it does not come with a desktop environment. Without installing additional software from FreeBSD's [ports and packages collection][3], FreeBSD is a command-line only experience. The screenshot below shows what logging into FreeBSD 12.1 looks like when every one of the "optional system components" is selected during installation.
|
||||
|
||||
![FreeBSD][4]
|
||||
|
||||
FreeBSD can be turned into a desktop operating system with any of a wide selection of desktop environments, but it takes time, effort, and [following a lot of written instructions][5]. Using the **desktop-installer** package, which provides the user with options in a text-based menu and helps automate much of the process, is still time-consuming. The biggest problem with either of these methods is that users might find out that their system is not fully compatible with FreeBSD after they have taken all the time to set things up.
|
||||
|
||||
[FuryBSD][6] solves that problem by providing a live desktop image that users can evaluate before installing. Currently, FuryBSD provides an Xfce image and a KDE image. Each of these images provides an installation of FreeBSD that has a desktop environment pre-installed. If users try out the image and find that their hardware works, they can install FuryBSD and have a ready-to-go desktop operating system powered by FreeBSD. For the purposes of this article, I will be using the Xfce image, but the KDE image works the exact same way.
|
||||
|
||||
Getting started with FuryBSD should be a familiar process to anyone who has installed a Linux distribution, any of the BSDs, or any other Unix-like open source operating system. Download the ISO from the FuryBSD website, copy it to a flash drive, and boot a computer from the flash drive. If booting from the flash drive fails, make sure Secure Boot is disabled.
|
||||
|
||||
![FuryBSD Live XFCE Desktop][7]
|
||||
|
||||
After booting from the flash drive, the desktop environment loads automatically. In addition to the Home, File System, and Trash icons, the live desktop has icons for a tool to configure Xorg, getting started instructions, the FuryBSD installer, and a system information utility. Other than these extras and some custom Xfce settings and wallpaper, the desktop environment does not come with much beyond the basic Xfce applications and Firefox.
|
||||
|
||||
![FuryBSD Xorg Tool][8]
|
||||
|
||||
Only basic graphics drivers are loaded at this point, but it is enough to check to see if the system's wired and wireless network interfaces are supported by FuryBSD. If none of the network interfaces is working automatically, the **Getting Started.txt** file contains instructions for attempting to configure network interfaces and other configuration tasks. If at least one of the network interfaces works, the **Configure Xorg** application can be used to install Intel, NVidia, or VirtualBox graphics drivers. The drivers will be downloaded and installed, and Xorg will need to be restarted. If the system does not automatically re-login to the live image user, the password is **furybsd**. Once they are configured, the graphics drivers will carry over to an installed system.
|
||||
|
||||
![FuryBSD Installer - ZFS Configuration][9]
|
||||
|
||||
If everything works well in the live environment, the FuryBSD installer can configure and install FuryBSD onto the computer. This installer runs in a terminal, but it provides the same options found in most other BSD and Linux installers. The user will be asked to set the system's hostname, configure ZFS storage, set the root password, add at least one non-root user, and configure the time and date settings. Once the process is complete, the system can be rebooted into a pre-configured FreeBSD with an Xfce (or KDE) desktop. FuryBSD did all the hard work and even took the extra effort to make the desktop look nice.
|
||||
|
||||
![FuryBSD Post-Install XFCE Desktop][10]
|
||||
|
||||
As noted above, the desktop environment does not come with a lot of pre-installed software, so installing additional packages is almost certainly necessary. The quickest way to do this is by using the **pkg** command in the terminal. This command behaves much like **dnf** and **apt**, so users coming from a Linux distribution that uses one of those should feel right at home when it comes to finding and installing packages. FreeBSD's package collection is large, so most of the big-name open source software packages are available.
|
||||
|
||||
Users trying out FuryBSD without having much FreeBSD experience should consult the [FreeBSD Handbook][11] to learn more about how to do things the FreeBSD way. Users with experience using any Linux distribution or one of the other BSDs should be able to figure out a lot of things, but there are differences that the handbook can help clarify. Another great resource for learning more about the FreeBSD way of doing things is _[Absolute FreeBSD, 3rd Edition][12],_ by Michael W. Lucas.
|
||||
|
||||
A brief overview of PC-BSD and thoughts about the distribution.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/5/furybsd-linux
|
||||
|
||||
作者：[Joshua Allen Holm][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/holmja
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/web_browser_desktop_devlopment_design_system_computer.jpg?itok=pfqRrJgh (web development and design, desktop and browser)
|
||||
[2]: https://www.freebsd.org
|
||||
[3]: https://www.freebsd.org/ports/
|
||||
[4]: https://opensource.com/sites/default/files/uploads/freebsd.png (FreeBSD)
|
||||
[5]: https://www.freebsdfoundation.org/freebsd/how-to-guides/installing-a-desktop-environment-on-freebsd/
|
||||
[6]: https://www.furybsd.org
|
||||
[7]: https://opensource.com/sites/default/files/uploads/furybsd_live_xfce_desktop.png (FuryBSD Live XFCE Desktop)
|
||||
[8]: https://opensource.com/sites/default/files/uploads/furybsd_xorg_tool.png (FuryBSD Xorg Tool)
|
||||
[9]: https://opensource.com/sites/default/files/uploads/furybsd_installer_-_zfs_configuration.png (FuryBSD Installer - ZFS Configuration)
|
||||
[10]: https://opensource.com/sites/default/files/uploads/furybsd_post-install_xfce_desktop.png (FuryBSD Post-Install XFCE Desktop)
|
||||
[11]: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/
|
||||
[12]: https://nostarch.com/absfreebsd3
|
||||
Loading…
Reference in New Issue
Block a user