mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
Merge remote-tracking branch 'LCTT/master'
This commit is contained in:
Xingyu Wang
commit
3b1bcb7ef8
@ -1,38 +1,38 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (robsean)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: (wxy)
|
||||
[#]: url: (https://linux.cn/article-12396-1.html)
|
||||
[#]: subject: (How to Create Curve Text in GIMP in 5 Simple Steps [GIMP Beginner’s Tutorial])
|
||||
[#]: via: (https://itsfoss.com/curve-text-gimp/)
|
||||
[#]: author: (Dimitrios Savvopoulos https://itsfoss.com/author/dimitrios/)
|
||||
|
||||
如何用5个简单的步骤来在 GIMP 中创建曲线文本 [GIMP 初学者教程]
|
||||
GIMP 教程：如何在 GIMP 中创建曲线文本
|
||||
======
|
||||
|
||||
当你在 GIMP 中制作一个徽章，海报或其它任何作品时，你需要弯曲一些文本。多功能的 [GIMP][1] 工具提供了一些创建弯曲文本的方法。取决于你将如何使用它和你想给予文本的曲率，有一些方法比其它的方法更好。
|
||||
当你在 GIMP 中制作一个徽章、海报或其它任何作品时，你需要扭曲或弯曲一些文本。多功能的 [GIMP][1] 工具提供了一些创建弯曲文本的方法。取决于你将如何使用它和你想给予文本的弧度，有一些适合不同情况的方法。
|
||||
|
||||
在招聘教程中，我将向你展示我最喜欢的创建曲线文本的方法。
|
||||
在本篇教程中，我将向你展示我最喜欢的创建曲线文本的方法。
|
||||
|
||||
### 如何在 GIMP 中创建曲线文本
|
||||
|
||||
![][2]
|
||||
|
||||
请确保你已经在你的系统上安装了 GIMP 。
|
||||
请确保你已经在你的系统上安装了 GIMP。
|
||||
|
||||
#### 步骤 1: 创建一个你想要的匹配曲线的路径
|
||||
|
||||
创建一个新的图像或打开一个现有的图像。选择 工具 -> 路径，然后大致考虑曲线文本的位置，通过分别单击路径点的开始点和结束点来创建路径。
|
||||
创建一个新的图像或打开一个现有的图像。选择 “工具 -> 路径”，然后大致考虑曲线文本的位置，通过分别单击路径点的开始点和结束点来创建路径。
|
||||
|
||||
![创建一个路径][3]
|
||||
|
||||
**然后给你的路径一个曲率。** 首先向上或向下拖动中间的直线，然后通过移动调整点进行微调。这将给予它一个拱形结构。
|
||||
**然后给你的路径一个曲率。**首先向上或向下拖动中间的直线，然后通过移动调整点进行微调。这将给予它一个拱形结构。
|
||||
|
||||
![弯曲路径][4]
|
||||
|
||||
#### 步骤 2: 创建你想弯曲的文本
|
||||
|
||||
当你对自己的曲线路径满意时，你可以移动到接下来的步骤，并 **创建你的文本**.
|
||||
当你对自己的曲线路径满意时，你可以移动到接下来的步骤，并 **创建你的文本**。
|
||||
|
||||
你可能想更改字体及其大小。我的选择只是为了演示用途。
|
||||
|
||||
@ -42,7 +42,7 @@
|
||||
|
||||
我强烈建议分割 GIMP 图像中的每个不同的元素到不同的图层中，以便很容易地控制它们，像移动，打开/关闭一个元素等等。
|
||||
|
||||
遵循这一规则，我们弯曲的文本将被放置到一个新的图层中。建议使用像“Curved Text”一样的名字来命名你的新的图层，或者一些类似的东西来很容易地识别它。
|
||||
遵循这一规则，我们要弯曲的文本将被放置到一个新的图层中。建议使用像 “Curved Text” 一样的名字来命名你的新的图层，或者一些类似的东西来很容易地识别它。
|
||||
|
||||
![为弯曲的文本创建一个新的图层][6]
|
||||
|
||||
@ -52,7 +52,7 @@
|
||||
|
||||
![文字对齐路径][7]
|
||||
|
||||
你只弯曲了文本!让我们使用颜色填充文本来使其更令人满意。
|
||||
你把文本弯曲了！让我们使用颜色填充文本来使其更令人满意。
|
||||
|
||||
### 步骤 5: 最后的修饰和导出
|
||||
|
||||
@ -60,7 +60,7 @@
|
||||
|
||||
![路径选择][8]
|
||||
|
||||
最后，选择油漆桶工具，一种你选择的颜色，并如下应用你的选择区。
|
||||
最后，选择油漆桶工具，选择一种颜色，并如下应用你的选择区。
|
||||
|
||||
![][9]
|
||||
|
||||
@ -70,34 +70,30 @@
|
||||
|
||||
#### 额外提示：创建阴影效果
|
||||
|
||||
我还有一个作为一次挑战的额外的步骤，如果你想更进一步的话。让我们在 [GIMP 中勾勒文本][11]以创建一个弯曲文本的阴影效果
|
||||
我还有一个作为一次挑战的额外的步骤，如果你想更进一步的话。让我们在 [GIMP 中勾勒文本][11]以创建一个弯曲文本的阴影效果。
|
||||
|
||||
我将给予你一些提示:
|
||||
|
||||
* 重新启用所有图层
|
||||
* 单击弯曲文本图层，并使用移动工具来到此移动文本
|
||||
* 单击弯曲文本图层，并使用移动工具来到处移动文本
|
||||
* 创建另一个图层，并使用黑色来重复油漆桶填充程序
|
||||
* 以一种模拟一种阴影位置的方式覆盖图层(你可能需要更改图层顺序)
|
||||
* 以一种模拟一种阴影位置的方式覆盖图层（你可能需要更改图层顺序）
|
||||
* 关闭辅助图层
|
||||
|
||||
|
||||
|
||||
**The final result!**
|
||||
最终结果：
|
||||
|
||||
![][12]
|
||||
|
||||
让我在评论区知道你们对这篇 GIMP 教程的想法，以及有多少人尝试了这一额外的步骤。
|
||||
|
||||
不要忘了 [订阅简讯][13] ，因为 FOSS 小组会在不久的将来给你更多的东西!
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://itsfoss.com/curve-text-gimp/
|
||||
|
||||
作者：[Dimitrios Savvopoulos][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
译者：[robsean](https://github.com/robsean)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -0,0 +1,52 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (How wireless networks can battle COVID-19)
|
||||
[#]: via: (https://www.networkworld.com/article/3565389/how-wireless-networks-can-battle-covid-19.html)
|
||||
[#]: author: (Patrick Nelson https://www.networkworld.com/author/Patrick-Nelson/)
|
||||
|
||||
How wireless networks can battle COVID-19
|
||||
======
|
||||
Wireless network devices maintain a connection by handing off from one cell tower to another. The data created should be used to fight coronavirus, say researchers.
|
||||
Sasha85ru / Getty Images
|
||||
|
||||
Routinely collected cellphone-location data could be used to alert health official about crowded areas where novel coronavirus could spread rapidly, which they could then use to disperse people in order to lower the risk, according to researchers at Colorado State University.
|
||||
|
||||
Mobile phones maintain connections as their users move around by continually handing off from one cell tower to another. Analyzing logs of these handoffs is a way to gauge how many people are in an area, the researchers say, and that information could flag potential virus-spreading hotspots. “Crowded regions with actively moving people are susceptible to spreading the disease,” the team say in [an abstract of their paper][1] in _IEEE Open Journal of Engineering in Medicine and Biology_.
|
||||
|
||||
[[Get regularly scheduled insights by signing up for Network World newsletters.]][2]
|
||||
|
||||
“Our findings could help risk managers with planning and mitigation,” says Edwin Chong, Professor of Electrical and Computer Engineering and interim department head at the school [in an article on the university’s website][3].
|
||||
|
||||
The data that would be used doesn’t identify individuals who own the phones, which should alleviate privacy concerns, he says. “All we have to do is perform the measurements using anonymous data that is already being collected for other reasons. We are not tracking individuals,” he says
|
||||
|
||||
Cellphone applications that have been developed to trace near encounters between individuals are different. They necessarily gather personal information so health officials can determine who might have come in proximity with an infected person. The goal is to alert those who have had such encounters so they can quarantine themselves for 14 days to prevent them from potentially spreading the virus further. But that is quite different from the information gathered by cell-tower engineering logs.
|
||||
|
||||
As mobile phones move from one cell to another, a process called handover and reselection keeps the phones constantly connected to the network. The logs of this activity reveal the volume of this activity and tracks the status of phones such as non-active standby, engaged in active calls or whether it’s making data connections.
|
||||
|
||||
The size of cells varies with those in densely populated areas being smaller and therefore able to deliver more granular data about where people are closer together. Indeed, future 5G deployments may have cell antennas in every municipal streetlight, making it possible to make very specific density estimates.
|
||||
|
||||
|
||||
|
||||
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/3565389/how-wireless-networks-can-battle-covid-19.html
|
||||
|
||||
作者：[Patrick Nelson][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/Patrick-Nelson/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://ieeexplore.ieee.org/document/9117073
|
||||
[2]: https://www.networkworld.com/newsletters/signup.html
|
||||
[3]: https://engr.source.colostate.edu/using-cellular-networks-to-detect-at-risk-areas-for-spread-of-covid-19/
|
||||
[4]: https://www.facebook.com/NetworkWorld/
|
||||
[5]: https://www.linkedin.com/company/network-world
|
||||
@ -1,5 +1,5 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
|
||||
@ -1,85 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Ex-Solus Dev is Now Creating a Truly Modern Linux Distribution Called Serpent Linux)
|
||||
[#]: via: (https://itsfoss.com/serpent-os-announcement/)
|
||||
[#]: author: (Abhishek Prakash https://itsfoss.com/author/abhishek/)
|
||||
|
||||
Ex-Solus Dev is Now Creating a Truly Modern Linux Distribution Called Serpent Linux
|
||||
======
|
||||
|
||||
[Ikey Doherty][1], the developer who once created the independent Linux distribution Solus has announced his new project: Serpent OS.
|
||||
|
||||
[Serpent OS][2] is a Linux distribution that DOES NOT want to be categorized as “lightweight, user-friendly, privacy-focused Linux desktop distribution”.
|
||||
|
||||
Instead, Serpent OS has “different goals from the mainstream offering”. How? Read on.
|
||||
|
||||
### Serpent OS: The making of a “truly modern” Linux distribution
|
||||
|
||||
![][3]
|
||||
|
||||
Serpent takes distro-first, compatibility-later approach. This lets them take some really bold decisions.
|
||||
|
||||
Ikey says that it this project will not tolerate for negative actors holding Linux back. For example, NVIDIA’s lack of support for accelerated Wayland support on their GPUs will not be tolerated and NVIDIA proprietary drivers will be blacklisted from the distribution.
|
||||
|
||||
Here’s a proposed plan for the Serpent Linux project (taken from [their website][4]):
|
||||
|
||||
* No more usrbin split
|
||||
* 100% clang-built throughout (including kernel)
|
||||
* musl as libc, relying on compiler optimisations instead of inline asm
|
||||
* libc++ instead of libstdc++
|
||||
* LLVM’s binutils variants (lld, as, etc.)
|
||||
* Mixed source/binary distribution
|
||||
* Moving away from x86_64-generic baseline to newer CPUs, including Intel and AMD specific optimisations
|
||||
* Capability based subscriptions in package manager (Hardware/ user choice / etc)
|
||||
* `UEFI` only. No more legacy boot.
|
||||
* Completely open source, down to the bootstrap / rebuild scripts
|
||||
* Seriously optimised for serious workloads.
|
||||
* Third party applications reliant on containers only. No compat-hacks
|
||||
* Wayland-only. X11 compatibility via containers will be investigated
|
||||
* Fully stateless with management tools and upstreaming of patches
|
||||
|
||||
|
||||
|
||||
Ikey boldly claims that Serpent Linux is not Serpent GNU/Linux because it is not going to be dependent on a GNU toolchain or runtime.
|
||||
|
||||
The development for Serpent OS project starts by the end of July. There is no definite timeline of the final stable release.
|
||||
|
||||
### Too high claims? But Ikey has done it in the past
|
||||
|
||||
You may doubt if Serpent OS will see the light of the day and if it would be able to keep all the promises it made.
|
||||
|
||||
But Ikey Doherty has done it in the past. If I remember correctly, he first created SolusOS based on Debian. He discontinued the [Debian-based SolusOS][5] in 2013 before it even reached the beta stage.
|
||||
|
||||
He then went out to create [evolve OS][6] from scratch instead of using another distribution as base. Due to some naming copyright issues, the project name was changed to Solus (yes, the same old name). [Ikey quit the Solus projec][7][t][7] [in 2018][7] and other devs now handle the project.
|
||||
|
||||
Solus is an independent Linux distribution that gave us the beautiful Budgie desktop environment.
|
||||
|
||||
Ikey has done it in the past (with the help of other developers, of course). He should be able to pull this one off as well.
|
||||
|
||||
**Yay or Nay?**
|
||||
|
||||
What do you think of this Serpent Linux? Do you think it is time for developers to take a bold stand and develop the operating system with the future in the mind rather than holding on to the past? Do share your views.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://itsfoss.com/serpent-os-announcement/
|
||||
|
||||
作者：[Abhishek Prakash][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://itsfoss.com/author/abhishek/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://itsfoss.com/ikey-doherty-serpent-interview/
|
||||
[2]: https://www.serpentos.com/
|
||||
[3]: https://i2.wp.com/itsfoss.com/wp-content/uploads/2020/07/serpent-linux.png?ssl=1
|
||||
[4]: https://www.serpentos.com/about/
|
||||
[5]: https://distrowatch.com/table.php?distribution=solusos
|
||||
[6]: https://itsfoss.com/beta-evolve-os-released/
|
||||
[7]: https://itsfoss.com/ikey-leaves-solus/
|
||||
130
sources/tech/20200708 6 best practices for teams using Git.md
Normal file
130
sources/tech/20200708 6 best practices for teams using Git.md
Normal file
@ -0,0 +1,130 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (6 best practices for teams using Git)
|
||||
[#]: via: (https://opensource.com/article/20/7/git-best-practices)
|
||||
[#]: author: (Ravi Chandran https://opensource.com/users/ravichandran)
|
||||
|
||||
6 best practices for teams using Git
|
||||
======
|
||||
Work more effectively by using these Git collaboration strategies.
|
||||
![Women in tech boardroom][1]
|
||||
|
||||
Git is very useful for helping small teams manage their software development processes, but there are ways you can make it even more effective. I've found a number of best practices that help my team, especially as new team members join with varying levels of Git expertise.
|
||||
|
||||
### Formalize Git conventions for your team
|
||||
|
||||
Everyone should follow standard conventions for branch naming, tagging, and coding. Every organization has standards or best practices, and many recommendations are freely available on the internet. What's important is to pick a suitable convention early on and follow it as a team.
|
||||
|
||||
Also, different team members will have different levels of expertise with Git. You should create and maintain a basic set of instructions for performing common Git operations that follow the project's conventions.
|
||||
|
||||
### Merge changes properly
|
||||
|
||||
Each team member should work on a separate feature branch. But even when separate branches are used, everyone eventually modifies some common files. When merging the changes back into the `master` branch, the merge typically will not be automatic. Human intervention may be needed to reconcile different changes made by two authors to the same file. This is where you have to learn to deal with Git merge techniques.
|
||||
|
||||
Modern editors have features to help with [Git merge conflicts][2]. They indicate various options for a merge in each part of a file, such as whether to keep your changes, the other branch's changes, or both. It may be time to pick a different code editor if yours doesn't support such capabilities.
|
||||
|
||||
### Rebase your feature branch often
|
||||
|
||||
As you continue to develop your feature branch, rebase it against `master` often. This means executing the following steps regularly:
|
||||
|
||||
|
||||
```
|
||||
git checkout master
|
||||
git pull
|
||||
git checkout feature-xyz # name of your hypothetical feature branch
|
||||
git rebase master # may need to fix merge conflicts in feature-xyz
|
||||
```
|
||||
|
||||
These steps [rewrite history][3] in your feature branch (and that's not a bad thing). First, it makes your feature branch look like `master` with all the updates made to `master` up to that point. Then all your commits to the feature branch are replayed on top, so they appear sequentially in the Git log. You may get merge conflicts that you'll need to resolve along the way, which can be a challenge. However, this is the best point to deal with merge conflicts because it only impacts your feature branch.
|
||||
|
||||
After you fix any conflicts and perform regression testing, if you're ready to merge your feature back into `master`, do the above rebase steps one more time, then perform the merge:
|
||||
|
||||
|
||||
```
|
||||
git checkout master
|
||||
git pull
|
||||
git merge feature-xyz
|
||||
```
|
||||
|
||||
In the interim, if someone else pushes changes to `master` that conflict with yours, the Git merge will have conflicts again. You'll need to resolve them and repeat the regression testing.
|
||||
|
||||
There are other merge philosophies (e.g., without rebasing and only using merge to avoid rewriting history), some of which may even be simpler to use. However, I've found the approach above to be a clean and reliable strategy. The commit history is stacked up as a meaningful sequence of features.
|
||||
|
||||
With "pure merge" strategies (without rebasing regularly, as suggested above), the history in the `master` branch will be interspersed with the commits from all the features being developed concurrently. Such a mixed-up history is harder to review. The exact commit times are usually not that important. It's better to have a history that's easier to review.
|
||||
|
||||
### Squash commits before merging
|
||||
|
||||
When working on your feature branch, it's fine to add a commit for even minor changes. However, if every feature branch produced 50 commits, the resulting number of commits in the `master` branch could grow unnecessarily large as features are added. In general, there should only be one or a few commits added to `master` from each feature branch. To achieve this, _squash_ multiple commits into one or a handful of commits with more elaborate messages for each one. This is typically done using a command such as:
|
||||
|
||||
|
||||
```
|
||||
`git rebase -i HEAD~20 # look at up to 20 commits to consider squashing`
|
||||
```
|
||||
|
||||
When this is executed, an editor pops up with a list of commits that you can act upon in several ways, including _pick_ or _squash_. Picking a commit means keeping that commit message. Squashing implies combining that commit's message into the previous commit. Using these and other options, you can combine commit messages into one and do some editing and cleanup. It's also an opportunity to get rid of the commit messages that aren't important (e.g., a commit message about fixing a typo).
|
||||
|
||||
In summary, keep all the actions associated with the commits, but combine and edit the associated message text for improved clarity before merging into `master`. Don't inadvertently drop a commit during the rebase process.
|
||||
|
||||
After performing such a rebase, I like to look at the `git log` one last time to make final edits:
|
||||
|
||||
|
||||
```
|
||||
`git commit --amend`
|
||||
```
|
||||
|
||||
Finally, forcing an update to your remote feature branch is necessary, since the Git commit history for the branch has been rewritten:
|
||||
|
||||
|
||||
```
|
||||
`git push -f`
|
||||
```
|
||||
|
||||
### Use tags
|
||||
|
||||
After you have finished testing and are ready to deploy the software from the `master` branch, or if you want to preserve the current state as a significant milestone for any other reason, create a Git tag. While a branch accumulates a history of changes corresponding to commits, a tag is a snapshot of the branch's state at that instant. A tag can be thought of as a history-less branch or as a named pointer to a specific commit immediately before the tag was created.
|
||||
|
||||
Configuration control is about preserving the state of code at various milestones. Being able to reproduce software source code for any milestone so that it can be rebuilt when necessary is a requirement in most projects. A Git tag provides a unique identifier for such a code milestone. Tagging is straightforward:
|
||||
|
||||
|
||||
```
|
||||
git tag milestone-id -m "short message saying what this milestone is about"
|
||||
git push --tags # don't forget to explicitly push the tag to the remote
|
||||
```
|
||||
|
||||
Consider a scenario where software corresponding to a given Git tag is distributed to a customer, and the customer reports an issue. While the code in the repository may continue to evolve, it's often necessary to go back to the state of the code corresponding to the Git tag to reproduce the customer issue precisely to create a bug fix. Sometimes newer code may have already fixed the issue but not always. Typically, you'd check out the specific tag and create a branch from that tag:
|
||||
|
||||
|
||||
```
|
||||
git checkout milestone-id # checkout the tag that was distributed to the customer
|
||||
git checkout -b new-branch-name # create new branch to reproduce the bug
|
||||
```
|
||||
|
||||
Beyond this, consider using annotated tags and signed tags if they may be beneficial to your project.
|
||||
|
||||
### Make the software executable print the tag
|
||||
|
||||
In most embedded projects, the resulting binary file created from a software build has a fixed name. The Git tag corresponding to the software binary file cannot be inferred from its filename. It is useful to "embed the tag" into the software at build time to correlate any future issues precisely to a given build. Embedding the tag can be automated within the build process. Typically, the tag string `git describe` generates is inserted into the code before code compilation so that the resulting executable will print the tag string while booting up. When a customer reports an issue, they can be guided to send you a copy of the boot output.
|
||||
|
||||
### Conclusion
|
||||
|
||||
Git is a sophisticated tool that takes time to master. Using these practices can help teams successfully collaborate using Git, regardless of their expertise level.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/7/git-best-practices
|
||||
|
||||
作者：[Ravi Chandran][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/ravichandran
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/christina-wocintechchat-com-rg1y72ekw6o-unsplash_1.jpg?itok=MoIv8HlK (Women in tech boardroom)
|
||||
[2]: https://opensource.com/article/20/4/git-merge-conflict
|
||||
[3]: https://opensource.com/article/20/4/git-rebase-i
|
||||
@ -0,0 +1,246 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (A visual guide to Lens: A new way to see Kubernetes)
|
||||
[#]: via: (https://opensource.com/article/20/7/kubernetes-lens)
|
||||
[#]: author: (Jessica Cherry https://opensource.com/users/cherrybomb)
|
||||
|
||||
A visual guide to Lens: A new way to see Kubernetes
|
||||
======
|
||||
Navigate advanced Kubernetes administration without the command line
|
||||
with Lens, the "Kubernetes IDE."
|
||||
![Cat wearing glasses][1]
|
||||
|
||||
There are many [Kubernetes][2] administration tools to choose from, whether you prefer a command-line utility or a graphical user interface. I recently covered [k9s][3], a text-based interface that many day-to-day Kubernetes administrators enjoy, but you have to navigate through many Kubernetes-specific terms to use it. A lot of people who use Kubernetes less often would rather have a colorful, clean visual guide. This is where [Lens][4], an open source integrated development environment (IDE) tool for administering Kubernetes clusters, comes in.
|
||||
|
||||
### Install Lens
|
||||
|
||||
You can download Lens for Linux, macOS, or Windows from either its [GitHub][5] page or its [website][4]. Linux installs are offered through AppImage, and [this tutorial][6] walks you through the installation process. After installation, Lens appeared in my applications list (the blue box with the L in the center).
|
||||
|
||||
![Lens app icon][7]
|
||||
|
||||
(Jess Cherry, [CC BY-SA 4.0][8])
|
||||
|
||||
### Add a cluster
|
||||
|
||||
Managing Kubernetes means keeping an eye on one or more clusters. To add a cluster to Lens, click the large **+** sign, choose your cluster from the drop-down list, and click **Add Cluster**. Environments are automatically picked up from your `~/.kube/config` file.
|
||||
|
||||
![Adding a cluster in Lens][9]
|
||||
|
||||
(Jess Cherry, [CC BY-SA 4.0][8])
|
||||
|
||||
### Explore Lens' menus
|
||||
|
||||
Lens gives you all the information you need about a cluster it manages. To help you get started, I'll explore the Lens menu sections with screenshots to show you what information and options they offer.
|
||||
|
||||
If you need a refresher on Kubernetes terminology, [_A beginner's guide to Kubernetes container orchestration_][10] is a good place to read about it.
|
||||
|
||||
#### Nodes menu
|
||||
|
||||
First, look at the **Nodes**. A node can be a virtual machine or physical (bare metal) machine depending on the cluster. Each node contains the services necessary to run Pods, managed by the control plane. We can start by checking if our nodes are up and running in a Ready state. If there were an issue, this page would provide details as to what is wrong with the node.
|
||||
|
||||
![Lens Nodes menu][11]
|
||||
|
||||
(Jess Cherry, [CC BY-SA 4.0][8])
|
||||
|
||||
#### Workloads menu
|
||||
|
||||
The **Workloads** section provides a lot of information about your cluster. You can access its subsections with either the menu on the left or at the top of the pane—both work the same way.
|
||||
|
||||
##### Overview
|
||||
|
||||
Click **Overview** to see the events happening in the cluster, as well as how many Pods, Deployments, StatefulSets, DaemonSets, Jobs, and CronJobs are running in it. You can select each Overview item to see details about it.
|
||||
|
||||
![Lens Workloads Overview menu][12]
|
||||
|
||||
(Jess Cherry, [CC BY-SA 4.0][8])
|
||||
|
||||
##### Pods
|
||||
|
||||
Click **Pods** to see a list of the pods in the cluster.
|
||||
|
||||
![Lens Workloads Pods menu][13]
|
||||
|
||||
(Jess Cherry, [CC BY-SA 4.0][8])
|
||||
|
||||
Click on a pod name in the **Pods** section of **Workloads**, and it will bring up a details pane on the right with a ton of things you can do really quickly.
|
||||
|
||||
![Lens Workloads Pod details][14]
|
||||
|
||||
(Jess Cherry, [CC BY-SA 4.0][8])
|
||||
|
||||
Open the pod's logs by clicking on the multi-line button (the second icon from the left) on the top-right of the pod detail window.
|
||||
|
||||
![Lens Workloads Pod logs][15]
|
||||
|
||||
(Jess Cherry, [CC BY-SA 4.0][8])
|
||||
|
||||
If you need to shell into a pod, Lens has a terminal built into it. Access it by clicking the terminal button (the left-most icon) above the pod detail.
|
||||
|
||||
![Shelling into a pod in Lens][16]
|
||||
|
||||
(Jess Cherry, [CC BY-SA 4.0][8])
|
||||
|
||||
A terminal will open.
|
||||
|
||||
![Shelling into a pod in Lens][17]
|
||||
|
||||
(Jess Cherry, [CC BY-SA 4.0][8])
|
||||
|
||||
##### Deployments
|
||||
|
||||
**Deployments** shows what Deployments are in the cluster.
|
||||
|
||||
![Lens Workloads Deployments menu][18]
|
||||
|
||||
(Jess Cherry, [CC BY-SA 4.0][8])
|
||||
|
||||
#### Configuration menu
|
||||
|
||||
**Configuration** shows ConfigMaps, Secrets, Resource Quotas, and Horizontal Pod Autoscalers (HPA).
|
||||
|
||||
![Lens ConfigMaps menu][19]
|
||||
|
||||
(Jess Cherry, [CC BY-SA 4.0][8])
|
||||
|
||||
#### Network menu
|
||||
|
||||
**Network** includes options for managing your network services, endpoints, ingresses, and network policies.
|
||||
|
||||
##### Network Services
|
||||
|
||||
![Lens Network Services menu][20]
|
||||
|
||||
(Jess Cherry, [CC BY-SA 4.0][8])
|
||||
|
||||
If you see a pencil icon (like the one in the top-right corner above), clicking it will open a terminal window where you can edit the configurations.
|
||||
|
||||
![Editing configurations in Lens][21]
|
||||
|
||||
(Jess Cherry, [CC BY-SA 4.0][8])
|
||||
|
||||
#### Storage menu
|
||||
|
||||
Storage options, including PersistentVolumes and StorageClasses, are also navigable.
|
||||
|
||||
![Lens StorageClasses menu][22]
|
||||
|
||||
(Jess Cherry, [CC BY-SA 4.0][8])
|
||||
|
||||
#### Namespaces menu
|
||||
|
||||
**Namespaces** shows a list of your namespaces.
|
||||
|
||||
![Lens Namespaces menu][23]
|
||||
|
||||
(Jess Cherry, [CC BY-SA 4.0][8])
|
||||
|
||||
#### Apps menu
|
||||
|
||||
Lens' crown jewel is its one-click (OK, more like three-click) process for installing apps with [Helm charts][24]. I would suggest using this only on your local cluster, but it's still a nice add-on in Lens.
|
||||
|
||||
To install a chart, click **Apps** in the left navigation and click **Charts**. A list of all the charts available through Helm (and its stable repository) appears.
|
||||
|
||||
![Helm charts in Lens' Apps menu][25]
|
||||
|
||||
(Jess Cherry, [CC BY-SA 4.0][8])
|
||||
|
||||
You can also find a chart using **Search**. Click on the chart you want, and a window will open on the right with a large **Install** button.
|
||||
|
||||
![Searching for Helm charts in Lens' Apps menu][26]
|
||||
|
||||
(Jess Cherry, [CC BY-SA 4.0][8])
|
||||
|
||||
Click **Install** and a terminal will open at the bottom with another **Install** button in the lower-right. Click it.
|
||||
|
||||
![Installing a Helm chart in Lens][27]
|
||||
|
||||
(Jess Cherry, [CC BY-SA 4.0][8])
|
||||
|
||||
It installs the Helm chart and tells you when it's finished.
|
||||
|
||||
![Installing a Helm chart in Lens][28]
|
||||
|
||||
(Jess Cherry, [CC BY-SA 4.0][8])
|
||||
|
||||
You can double-check that the Helm chart is installed in your cluster by looking in the **Pods** section under **Workloads**.
|
||||
|
||||
![Confirming Helm chart in Lens][29]
|
||||
|
||||
(Jess Cherry, [CC BY-SA 4.0][8])
|
||||
|
||||
The Helm install takes under a minute and, because Lens has an edit function in each detail window, you can manually configure the apps you install. In my opinion, this is the only downfall of this function—I prefer to use my own values because it's hard to track manual changes. Why do I consider this a problem? If you're working with a repo with versioned helm charts and need to run a manual change without checking in the changed values, you quickly run into code drift.
|
||||
|
||||
#### Access Control menu
|
||||
|
||||
The **Access Control** section includes Service Accounts, Roles, Role Bindings, and Pod Security Policies, so you can visualize and edit the security you have in place (as you can see in the following screenshots). Service Accounts are the equivalent of Linux user accounts, but they are intended for processes running in a cluster. Running applications are attached to Roles, which have Role Bindings to the cluster to allow pods to access certain administrative permissions. Pod Security Policies are a more glandular level of security for the pods to have access to resources like certain volume types or to set seccomp profiles used by containers.
|
||||
|
||||
##### Service Accounts
|
||||
|
||||
![Lens Access Control Service Accounts menu][30]
|
||||
|
||||
(Jess Cherry, [CC BY-SA 4.0][8])
|
||||
|
||||
##### Role Bindings
|
||||
|
||||
![Lens Access Control RoleBindings menu][31]
|
||||
|
||||
(Jess Cherry, [CC BY-SA 4.0][8])
|
||||
|
||||
##### Roles
|
||||
|
||||
![Lens Access Control Roles menu][32]
|
||||
|
||||
(Jess Cherry, [CC BY-SA 4.0][8])
|
||||
|
||||
#### Final notes
|
||||
|
||||
Lens is a beautiful and powerful alternative to managing Kubernetes from the command line. There are some times when you'll want to use the command line, mostly due to the drawbacks of manually editing charts before launching them or for tracking environmental changes. If you have good log-keeping practices in your cluster, this may not be a problem. If you are a visual person, Lens is a great way to explore your Kubernetes cluster and handle 95% of your administrative tasks.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/7/kubernetes-lens
|
||||
|
||||
作者：[Jessica Cherry][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/cherrybomb
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/cat-glasses-read.png?itok=BigdrxUU (Cat wearing glasses)
|
||||
[2]: https://opensource.com/resources/what-is-kubernetes
|
||||
[3]: https://opensource.com/article/20/5/kubernetes-administration
|
||||
[4]: https://k8slens.dev/
|
||||
[5]: https://github.com/lensapp/lens
|
||||
[6]: https://opensource.com/article/20/6/kubernetes-cluster-lens
|
||||
[7]: https://opensource.com/sites/default/files/uploads/lens_1_homescreen.png (Lens app icon)
|
||||
[8]: https://creativecommons.org/licenses/by-sa/4.0/
|
||||
[9]: https://opensource.com/sites/default/files/uploads/lens_2-addcluster.png (Adding a cluster in Lens)
|
||||
[10]: https://opensource.com/article/20/6/container-orchestration
|
||||
[11]: https://opensource.com/sites/default/files/uploads/lens_3-nodes.png (Lens Nodes menu)
|
||||
[12]: https://opensource.com/sites/default/files/uploads/lens_4-overview.png (Lens Workloads Overview menu)
|
||||
[13]: https://opensource.com/sites/default/files/uploads/lens_5-pods.png (Lens Workloads Pods menu)
|
||||
[14]: https://opensource.com/sites/default/files/uploads/lens_7-poddetails.png (Lens Workloads Pod details)
|
||||
[15]: https://opensource.com/sites/default/files/uploads/lens_8-podlogs.png (Lens Workloads Pod logs)
|
||||
[16]: https://opensource.com/sites/default/files/uploads/lens_9-podshelling1.png (Shelling into a pod in Lens)
|
||||
[17]: https://opensource.com/sites/default/files/uploads/lens_10-podshelling2.png (Shelling into a pod in Lens)
|
||||
[18]: https://opensource.com/sites/default/files/uploads/lens_6-deployments.png (Lens Workloads Deployments menu)
|
||||
[19]: https://opensource.com/sites/default/files/uploads/lens_12-configmaps.png (Lens ConfigMaps menu)
|
||||
[20]: https://opensource.com/sites/default/files/uploads/lens_14-networkservices2.png (Lens Network Services menu)
|
||||
[21]: https://opensource.com/sites/default/files/uploads/lens_15-editconfig.png (Editing configurations in Lens)
|
||||
[22]: https://opensource.com/sites/default/files/uploads/lens_18-storageclass3.png (Lens StorageClasses menu)
|
||||
[23]: https://opensource.com/sites/default/files/uploads/lens_11-namespaces.png (Lens Namespaces menu)
|
||||
[24]: https://opensource.com/article/20/5/helm-charts
|
||||
[25]: https://opensource.com/sites/default/files/uploads/lens_22_apps.png (Helm charts in Lens' Apps menu)
|
||||
[26]: https://opensource.com/sites/default/files/uploads/lens_23_searchapps.png (Searching for Helm charts in Lens' Apps menu)
|
||||
[27]: https://opensource.com/sites/default/files/uploads/lens_24_installapps.png (Installing a Helm chart in Lens)
|
||||
[28]: https://opensource.com/sites/default/files/uploads/lens_25_helminstall.png (Installing a Helm chart in Lens)
|
||||
[29]: https://opensource.com/sites/default/files/uploads/lens_26_confirminstall.png (Confirming Helm chart in Lens)
|
||||
[30]: https://opensource.com/sites/default/files/uploads/lens_19-accesscontrol.png (Lens Access Control Service Accounts menu)
|
||||
[31]: https://opensource.com/sites/default/files/uploads/lens_20_rolebindings.png (Lens Access Control RoleBindings menu)
|
||||
[32]: https://opensource.com/sites/default/files/uploads/lens_21_roles.png (Lens Access Control Roles menu)
|
||||
142
sources/tech/20200708 How to decipher Linux release info.md
Normal file
142
sources/tech/20200708 How to decipher Linux release info.md
Normal file
@ -0,0 +1,142 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (How to decipher Linux release info)
|
||||
[#]: via: (https://www.networkworld.com/article/3565432/how-to-decipher-linux-release-info.html)
|
||||
[#]: author: (Sandra Henry-Stocker https://www.networkworld.com/author/Sandra-Henry_Stocker/)
|
||||
|
||||
How to decipher Linux release info
|
||||
======
|
||||
Displaying and interpreting information about Linux releases is a bit more complicated than it might seem.
|
||||
[christin hume / Linux / Modified by IDG Comm.][1] [(CC0)][2]
|
||||
|
||||
There’s a lot more to identifying a Linux release than citing a simple version number. Even a quick look at the output from the **uname** command can tell you that. What is all of that information, and what does it tell you?
|
||||
|
||||
In this post, we’ll take a closer look at the output from the **uname** command along with release descriptions provided by some other commands and files.
|
||||
|
||||
### Using uname
|
||||
|
||||
A lot of information is displayed whenever you issue the command **uname -a** in a Linux system terminal window. That's because that little “a” tells the **man** command that you want to see _all_ of the output that the command is able to provide. The resultant display will tell you a lot of different things about the system. In fact, each chunk of information displayed tells you something different about the system.
|
||||
|
||||
As an example, the **uname -a** output might look like this:
|
||||
|
||||
```
|
||||
$ uname -a
|
||||
Linux dragonfly 5.4.0-37-generic #41-Ubuntu SMP Wed Jun 3 18:57:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
|
||||
```
|
||||
|
||||
While it's probably not much of a temptation, you could retrieve this very same information by using a command that includes all of the **uname** options in the proper order:
|
||||
|
||||
```
|
||||
$ uname -snmrvpio
|
||||
Linux dragonfly 5.4.0-37-generic #41-Ubuntu SMP Wed Jun 3 18:57:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
|
||||
```
|
||||
|
||||
To break this long string of information into separate chunks, you can use a **for** loop like this that runs through each of the options:
|
||||
|
||||
```
|
||||
$ for option in s n m r v p i o; do echo -n "$option: "; uname -$option; done
|
||||
s: Linux
|
||||
n: dragonfly
|
||||
m: x86_64
|
||||
r: 5.4.0-37-generic
|
||||
v: #41-Ubuntu SMP Wed Jun 3 18:57:02 UTC 2020
|
||||
p: x86_64
|
||||
i: x86_64
|
||||
o: GNU/Linux
|
||||
```
|
||||
|
||||
That loops shows what information is provided by which option. The **uname** man page provides descriptions for each option. Here's a list:
|
||||
|
||||
```
|
||||
Linux –- kernel name (option “s”)
|
||||
dragonfly –- nodename (option “n”)
|
||||
x86_64 –- machine hardware name (option “m”)
|
||||
5.4.0-37-generic –- kernel release (option “r”)
|
||||
#41-Ubuntu SMP Wed Jun 3 18:57:02 UTC 2020 -- kernel version (option “v”)
|
||||
x86_64 –- processor (option “p”)
|
||||
x86_64 –- hardware platform (option “i”)
|
||||
GNU/Linux –- operating system (option “o”)
|
||||
```
|
||||
|
||||
To delve a little more deeply into the information being displayed, take a closer look at the kernel release data shown. That **5.4.0-37** in the 4th line is not just a string of arbitrary numbers. Each numeric value is significant.
|
||||
|
||||
* **5** is the kernel version
|
||||
* **4** signifies the major revision
|
||||
* **0** indicates the minor revision
|
||||
* **37** represents the most recent patch
|
||||
|
||||
|
||||
|
||||
In addition, that **#41** in the 5th line of the loop output (kernel version) indicates that this release has been compiled 41 times.
|
||||
|
||||
Individual options can be useful when and if you want to display only one piece of all the available information. For example, the command **uname -n** can tell you just the name of the system and **uname -r** will show you just the kernel release. These and other options can be useful when you're taking inventory of your servers or building scripts.
|
||||
|
||||
The same variety of information will be provided by the **uname -a** command when working on Red Hat systems. Here’s an example:
|
||||
|
||||
```
|
||||
$ uname -a
|
||||
Linux fruitfly 4.18.0-107.el8.x86_64 #1 SMP Fri Jun 14 13:46:34 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
|
||||
```
|
||||
|
||||
### Distribution release information
|
||||
|
||||
If you need to know what version of a distribution you’re running, the **uname** output isn’t going to help you much. The kernel version is, after all, not the same as the distribution version. For that information, you can use the **lsb_release -r** command on Ubuntu and other Debian-based systems and display the contents of the **/etc/redhat-release** file for Red Hat.
|
||||
|
||||
For Debian systems:
|
||||
|
||||
```
|
||||
$ lsb_release -r
|
||||
Release: 20.04
|
||||
```
|
||||
|
||||
For Red Hat and related systems:
|
||||
|
||||
```
|
||||
$ cat /etc/redhat-release
|
||||
Red Hat Enterprise Linux release 8.1 Beta (Ootpa)
|
||||
```
|
||||
|
||||
### Using /proc/version
|
||||
|
||||
The **/proc/version** file can also provide information on your Linux release. The information provided in this file has a lot in common with the **uname -a** output. Here are some examples.
|
||||
|
||||
On Ubuntu**:**
|
||||
|
||||
```
|
||||
$ cat /proc/version
|
||||
Linux version 5.4.0-37-generic (buildd@lcy01-amd64-001) (gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)) #41-Ubuntu SMP Wed Jun 3 18:57:02 UTC 2020
|
||||
```
|
||||
|
||||
On RedHat:
|
||||
|
||||
```
|
||||
$ cat /proc/version
|
||||
Linux version 4.18.0-107.el8.x86_64 (mockbuild@x86-vm-09.build.eng.bos.redhat.com) (gcc version 8.3.1 20190507 (Red Hat 8.3.1-4) (GCC)) #1 SMP Fri Jun 14 13:46:34 UTC 2019
|
||||
```
|
||||
|
||||
### Wrap-Up
|
||||
|
||||
Linux systems provide a lot of information on the kernel and distributions installed. You just have to know where or how to look and make sense of what it means.
|
||||
|
||||
Join the Network World communities on [Facebook][3] and [LinkedIn][4] to comment on topics that are top of mind.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.networkworld.com/article/3565432/how-to-decipher-linux-release-info.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/mfB1B1s4sMc
|
||||
[2]: https://creativecommons.org/publicdomain/zero/1.0/
|
||||
[3]: https://www.facebook.com/NetworkWorld/
|
||||
[4]: https://www.linkedin.com/company/network-world
|
||||
@ -0,0 +1,168 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Program IoT systems using Python with this VSCode plugin for RTOS)
|
||||
[#]: via: (https://opensource.com/article/20/7/python-rt-thread)
|
||||
[#]: author: (Seth Kenlon https://opensource.com/users/seth)
|
||||
|
||||
Program IoT systems using Python with this VSCode plugin for RTOS
|
||||
======
|
||||
A real-time embedded OS like RTOS makes programming embedded systems
|
||||
easier.
|
||||
![Parts, modules, containers for software][1]
|
||||
|
||||
The pervasiveness of the Internet of Things (IoT) means nearly every product, from refrigerators to pocket watches, can connect to a network. For that to happen, all these products must have an embedded computer running a networking stack, and some of these products are almost impossibly small. That's where embedded software comes in: modern technology provides a tiny computer, hard-coded into a hardware chip, without any need for offboard CPU, RAM, or hard drive.
|
||||
|
||||
Traditionally, that meant there was no operating system (OS), but [for many reasons][2], developers find a real-time embedded OS like [RT-Thread][3] makes programming embedded systems much easier.
|
||||
|
||||
The RT-Thread embedded operating system aims to encourage new programmers to get into IoT, but not everyone can hard-code a microchip in C. Luckily, MicroPython is filling that niche by enabling developers to create software in Python that runs on embedded systems. To make it even easier, RT-Thread has a plugin for VSCode and [VSCodium][4] that provides a development environment developers can use to get started with IoT. Some of its features include:
|
||||
|
||||
* A convenient connection mode, so you can easily connect to your development board over a serial port, over the network, or over USB (if you've used an Arduino, you'll be familiar with the workflow)
|
||||
* Support for uploading files or folders to your development board
|
||||
* Support for MicroPython-based code, with intelligent code completion and linting (syntax checking)
|
||||
* Support for the MicroPython REPL interactive environment
|
||||
* Many code examples and demo programs
|
||||
* Full project synchronization
|
||||
* Fast-running code files stored in memory
|
||||
* Code snippets to run functions
|
||||
* Support for several major MicroPython development boards
|
||||
* Support for and tested on Linux and Windows
|
||||
|
||||
|
||||
|
||||
### Requirements
|
||||
|
||||
Before getting started, if you're using Windows, you must ensure that your default VSCode terminal is set to [PowerShell][5]. Launch VSCodium and start a terminal from the **Terminal** menu. In the terminal that appears at the bottom of your VSCodium window, select **PowerShell** from the drop-down menu in the top bar.
|
||||
|
||||
Whether you're [on Windows][6] or Linux, you must have Python 3 installed. (On Linux, it's probably already installed or available in your software repository.)
|
||||
|
||||
You should also install the general Python plugin for VSCode from Microsoft. To install it, click the **File** menu and find the **Preferences** submenu. Open the **Extensions** panel from the **Preferences** menu. In **Extensions**, search for Python, and install the Microsoft plugin.
|
||||
|
||||
![VSCodium Python plugin][7]
|
||||
|
||||
(Seth Kenlon, [CC BY-SA 4.0][8])
|
||||
|
||||
Finally, you must have [VSCodium][9] or [VSCode][10] installed.
|
||||
|
||||
### Install the plugin
|
||||
|
||||
Installing the MicroPython development plugin follows the same process as installing the Python plugin. Click the **File** menu, find the **Preferences** submenu, and select **Extensions**.
|
||||
|
||||
In **Extensions**, search for **MicroPython**, and install the RT-Thread plugin.
|
||||
|
||||
![MicroPython plugin for RT-Thread][11]
|
||||
|
||||
(Seth Kenlon, [CC BY-SA 4.0][8])
|
||||
|
||||
### Use the plugin
|
||||
|
||||
Your board must have access to a serial port, which it gets through your group permissions. You probably need to add yourself to this group, because it's not usually set by default. First, verify that you're not already a member of `dialout`:
|
||||
|
||||
|
||||
```
|
||||
$ groups
|
||||
tux users
|
||||
```
|
||||
|
||||
In this example, the user `tux` is only a member of `tux` and `users`, so it needs to be added to `dialout`:
|
||||
|
||||
|
||||
```
|
||||
`$ sudo usermod --append --groups dialout tux`
|
||||
```
|
||||
|
||||
Log out or reboot to load your new group permissions.
|
||||
|
||||
### Create a MicroPython project
|
||||
|
||||
The first step in MicroPython development is to create a MicroPython project to write and run your code. To create a MicroPython project using the plugin, click the **Create MicroPython project** button in the bottom bar (on the left).
|
||||
|
||||
![Create MicroPython project][12]
|
||||
|
||||
(Seth Kenlon, [CC BY-SA 4.0][8])
|
||||
|
||||
This leads you through a few prompts, letting you choose either an empty project structure or a project containing example code.
|
||||
|
||||
### Connect your dev board
|
||||
|
||||
You can connect from VSCodium to your physical development board by clicking the **Connection** button in the lower-left corner of VSCodium. Select the device you want to connect to in the pop-up list of devices.
|
||||
|
||||
### Review sample code
|
||||
|
||||
The MicroPython plugin offers a lot of sample code and library files you can use and learn from. These are available from new icons, visible when the MicroPython plugin is active, in VSCodium's left button bar. The **Document** icon lists example code files, and the **Folder** icon lists example libraries.
|
||||
|
||||
![MicroPython examples][13]
|
||||
|
||||
(Seth Kenlon, [CC BY-SA 4.0][8])
|
||||
|
||||
### Run MicroPython files directly on your development board
|
||||
|
||||
You can debug a single file quickly and easily by running code on your board within VSCodium. The shortcut **Alt**+**Q** triggers a special plugin function to upload your current Python file to the memory of your connected development board. Alternatively, you can right-click on your current Python file and select **Run the MicroPython file directly on the device**.
|
||||
|
||||
![Running code on your device][14]
|
||||
|
||||
(Seth Kenlon, [CC BY-SA 4.0][8])
|
||||
|
||||
If you want to debug a small amount of code without loading files to your board, you can use the code-snippet function. To run selected code in the MicroPython REPL environment, select the snippet you want to run in the editor, and select **Execute the selected MicroPython code on the device** option from the right-click menu (or just press **Alt**+**Q** on your keyboard).
|
||||
|
||||
### Load files and folders to your dev board
|
||||
|
||||
If you want to load individual files or folders to your development board, there's a handy function for that. First, select the file or folder you want to upload in the project. Next, right-click on one of your selections and choose **Download the file/folder to the device**.
|
||||
|
||||
Note that if there are files or folders with the same name on the development board, the download overwrites the existing ones.
|
||||
|
||||
By entering the command `os.listdir()` in REPL, you can check whether the corresponding file or folder has been downloaded successfully. Similarly, you can also use the corresponding command to delete the file or folder in REPL.
|
||||
|
||||
To remove a file:
|
||||
|
||||
|
||||
```
|
||||
`os.remove('file_to_delete')`
|
||||
```
|
||||
|
||||
To remove a folder:
|
||||
|
||||
|
||||
```
|
||||
`os.rmdir('folder_to_delete')`
|
||||
```
|
||||
|
||||
### Project synchronization
|
||||
|
||||
Click the **Synchronization** button in the lower-left corner to start the project synchronization function. This feature synchronizes all directory files in the local project to the development board's filesystem. This feature is recommended to be used after the code is debugged, without the need to synchronize the project frequently during debugging.
|
||||
|
||||
After the project synchronization completes, the list of files in the device can be seen in the **Device Files List** column.
|
||||
|
||||
### Try it yourself
|
||||
|
||||
RT-Thread released the MicroPython plugin as an open source extension in hopes that it will be useful for new and experienced coders alike. It has many features and leverages others (like code completion and linting) from open source plugins. If you're interested in coding for embedded and IoT devices, there's no easier way to get started.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/7/python-rt-thread
|
||||
|
||||
作者：[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/containers_modules_networking_hardware_parts.png?itok=rPpVj92- (Parts, modules, containers for software)
|
||||
[2]: https://opensource.com/article/20/6/open-source-rtos
|
||||
[3]: https://www.rt-thread.io/
|
||||
[4]: https://opensource.com/article/20/6/open-source-alternatives-vs-code
|
||||
[5]: https://opensource.com/article/18/2/powershell-people
|
||||
[6]: https://opensource.com/article/19/8/how-install-python-windows
|
||||
[7]: https://opensource.com/sites/default/files/uploads/vscodium-python-plugin.jpg (VSCodium Python plugin)
|
||||
[8]: https://creativecommons.org/licenses/by-sa/4.0/
|
||||
[9]: http://vscodium.com
|
||||
[10]: https://github.com/microsoft/vscode
|
||||
[11]: https://opensource.com/sites/default/files/uploads/vscodium-micropython.jpg (MicroPython plugin for RT-Thread)
|
||||
[12]: https://opensource.com/sites/default/files/uploads/vscodium-micropython-create.jpg (Create MicroPython project)
|
||||
[13]: https://opensource.com/sites/default/files/uploads/vscodium-micropython-examples.jpg (MicroPython examples)
|
||||
[14]: https://opensource.com/sites/default/files/uploads/vscodium-micropython-run.jpg (Running code on your device)
|
||||
@ -0,0 +1,95 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Btrfs to be the Default Filesystem on Fedora? Fedora 33 Starts Testing Btrfs Switch)
|
||||
[#]: via: (https://itsfoss.com/btrfs-default-fedora/)
|
||||
[#]: author: (Ankush Das https://itsfoss.com/author/ankush/)
|
||||
|
||||
Btrfs to be the Default Filesystem on Fedora? Fedora 33 Starts Testing Btrfs Switch
|
||||
======
|
||||
|
||||
While we’re months away from Fedora’s next stable release ([Fedora 33][1]), there are a few changes worth keeping tabs on.
|
||||
|
||||
Among all the other [accepted system-wide changes for Fedora 33][1], the proposal of having Btrfs as the default filesystem for desktop variants is the most interesting one.
|
||||
|
||||
Here’s what Fedora mentions for the proposal:
|
||||
|
||||
> For laptop and workstation installs of Fedora, we want to provide file system features to users in a transparent fashion. We want to add new features, while reducing the amount of expertise needed to deal with situations like running out of disk space. Btrfs is well adapted to this role by design philosophy, let’s make it the default.
|
||||
|
||||
It’s worth noting that this isn’t an accepted system-wide change as of now and is subject to tests made on the [Test Day][2] (**8th July 2020**).
|
||||
|
||||
So, why is Fedora proposing this change? Is it going to be useful in any way? Is it a bad move? How is it going to affect Fedora distributions? Let’s talk a few things about it here.
|
||||
|
||||
![][3]
|
||||
|
||||
### What Fedora Editions will it Affect?
|
||||
|
||||
As per the proposal, all the desktop editions of Fedora 33, spins, and labs will be subject to this change, if the tests are successful.
|
||||
|
||||
So, you should expect the [workstation editions][4] to get Btrfs as the default file system on Fedora 33.
|
||||
|
||||
### Potential Benefits of Implementing This Change
|
||||
|
||||
To improve Fedora for laptops and workstation use-cases, Btrfs file system offers some benefits.
|
||||
|
||||
Even though this change hasn’t been accepted for Fedora 33 yet – let me point out the advantages of having Btrfs as the default file system:
|
||||
|
||||
* Improves the lifespan of storage hardware
|
||||
* Providing an easy solution to resolve when a user runs out of free space on the root or home directory.
|
||||
* Less-prone to data corruption and easy to recover
|
||||
* Gives better file system re-size ability
|
||||
* Ensure desktop responsiveness under heavy memory pressure by enforcing I/O limit
|
||||
* Makes complex storage setups easy to manage
|
||||
|
||||
|
||||
|
||||
If you’re curious, you might want to dive in deeper to know about [Btrfs][5] and its benefits in general.
|
||||
|
||||
Not to forget, Btrf was already a supported option — it just wasn’t the default file system.
|
||||
|
||||
But, overall, it feels like the introducing of Btrfs as the default file system on Fedora 33 could be a useful change, if implemented properly.
|
||||
|
||||
### Will Red Hat Enterprise Linux Implement This?
|
||||
|
||||
It’s quite obvious that Fedora is considered as the cutting-edge version of [Red Hat Enterprise Linux][6].
|
||||
|
||||
So, if Fedora rejects the change, Red Hat won’t implement it. On the other hand, if you’d want RHEL to use Btrfs, Fedora should be the first to approve the change.
|
||||
|
||||
To give you more clarity on this, Fedora has mentioned it in detail:
|
||||
|
||||
> Red Hat supports Fedora well, in many ways. But Fedora already works closely with, and depends on, upstreams. And this will be one of them. That’s an important consideration for this proposal. The community has a stake in ensuring it is supported. Red Hat will never support Btrfs if Fedora rejects it. Fedora necessarily needs to be first, and make the persuasive case that it solves more problems than alternatives. Feature owners believe it does, hands down.
|
||||
|
||||
Also, it’s worth noting that if you’re someone who does not want btrfs in Fedora, you should be looking at [OpenSUSE][7] and [SUSE Linux Enterprise][8] instead.
|
||||
|
||||
### Wrapping Up
|
||||
|
||||
Even though it looks like the change should not affect any upgrades or compatibility, you can find more information on the changes with Btrfs by default in [Fedora Project’s wiki page][9].
|
||||
|
||||
What do you think about this change targeted for Fedora 33 release? Do you want btrfs file system as the default?
|
||||
|
||||
Feel free to let me know your thooughts in the comments below!
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://itsfoss.com/btrfs-default-fedora/
|
||||
|
||||
作者：[Ankush Das][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://itsfoss.com/author/ankush/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://fedoraproject.org/wiki/Releases/33/ChangeSet
|
||||
[2]: https://fedoraproject.org/wiki/Test_Day:2020-07-08_Btrfs_default?rd=Test_Day:F33_btrfs_by_default_2020-07-08
|
||||
[3]: https://i1.wp.com/itsfoss.com/wp-content/uploads/2020/07/btrfs-default-fedora.png?ssl=1
|
||||
[4]: https://getfedora.org/en/workstation/
|
||||
[5]: https://en.wikipedia.org/wiki/Btrfs
|
||||
[6]: https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux
|
||||
[7]: https://www.opensuse.org
|
||||
[8]: https://www.suse.com
|
||||
[9]: https://fedoraproject.org/wiki/Changes/BtrfsByDefault
|
||||
@ -0,0 +1,85 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Ex-Solus Dev is Now Creating a Truly Modern Linux Distribution Called Serpent Linux)
|
||||
[#]: via: (https://itsfoss.com/serpent-os-announcement/)
|
||||
[#]: author: (Abhishek Prakash https://itsfoss.com/author/abhishek/)
|
||||
|
||||
前 Solus 开发人员正创建一个名为 Serpent Linux 的真正现代的 Linux 发行版
|
||||
======
|
||||
|
||||
曾经创建独立 Linux 发行版 Solus 的开发人员 [Ikey Doherty][1] 宣布了他的新项目：Serpent OS。
|
||||
|
||||
[Serpent OS][2]是一个不想被归类为“轻便、用户友好、注重隐私的 Linux 桌面发行版”。
|
||||
|
||||
相反，Serpent OS 具有“与主流产品不同的目标”。具体怎么样？请继续阅读。
|
||||
|
||||
### Serpent OS：制作“真正现代的” Linux 发行版
|
||||
|
||||
![][3]
|
||||
|
||||
Serpent 采用发行优先，兼容靠后的方法。这使他们可以做出一些非常大胆的决定。
|
||||
|
||||
Ikey 表示，这个项目不会对阻碍 Linux 的负面角色容忍。例如，不会容忍 NVIDIA 在其 GPU 上缺乏对 Wayland 加速支持的支持，并且 NVIDIA 专有驱动将加入发行版黑名单。
|
||||
|
||||
这是 Serpent Linux 项目的拟议计划（摘自[其网站][4]）：
|
||||
|
||||
* 不再分割 usrbin
|
||||
* 100％ clang 构建（包括内核）
|
||||
* musl 作为 libc，依靠编译器优化而不是内联 asm
|
||||
* 使用 libc++ 而不是 libstdc++
|
||||
* LLVM的 binutils 变体（lld、as 等）
|
||||
* 混合源/二进制分发
|
||||
* 从 x86_64 通用基线转移到更新的 CPU，包括针对 Intel 和 AMD 的优化
|
||||
* 包管理器中基于功能的订阅（硬件/用户选择等）
|
||||
* 只支持 `UEFI`。不支持老式启动方式。
|
||||
* 完全开源，包括引导程序/重建脚本
|
||||
* 针对高工作负载进行了认真的优化。
|
||||
* 第三方应用仅依赖于容器。没有兼容性修改
|
||||
* 仅支持 Wayland。将调查通过容器的 X11 兼容性
|
||||
* 完全无状态的管理工具和上游补丁
|
||||
|
||||
|
||||
|
||||
Ikey 大胆地宣称 Serpent Linux 不是 Serpent GNU/Linux，因为它不再依赖于 GNU 工具链或运行时。
|
||||
|
||||
Serpent OS 项目的开发将于 7 月底开始。没有确定最终稳定版本的时间表。
|
||||
|
||||
### 要求过高？但是 Ikey 过去做过
|
||||
|
||||
你可能会怀疑 Serpent OS 是否会出现，是否能够兑现其所作的所有承诺。
|
||||
|
||||
但是 Ikey Doherty 过去已经做过。如果我没记错的话，他首先基于 Debian 创建了 SolusOS。他于 2013 年停止了基于 [Debian 的 SolusOS][5] 的开发，甚至它还没有进入 Beta 阶段。
|
||||
|
||||
然后，他从头开始创建 [evolve OS][6]，而不是使用其他发行版作为基础。由于某些命名版权问题，项目名称已更改为 Solus（是的，相同的旧名称）。[Ikey 在 2018 年退出了 Solus项目][7]，其他开发人员现在负责该项目。
|
||||
|
||||
Solus 是一个独立的 Linux 发行版，它为我们提供了漂亮的 Budgie 桌面环境。
|
||||
|
||||
Ikey 过去做到了（当然，在其他开发人员的帮助下）。他现在也应该能够做到。
|
||||
|
||||
**看好还是不看好？**
|
||||
|
||||
你如何看待这个 Serpent Linux？你是否认为是时候让开发人员采取大胆的立场，并着眼于未来开发操作系统，而不是坚持过去？请分享你的观点。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://itsfoss.com/serpent-os-announcement/
|
||||
|
||||
作者：[Abhishek Prakash][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://itsfoss.com/author/abhishek/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://itsfoss.com/ikey-doherty-serpent-interview/
|
||||
[2]: https://www.serpentos.com/
|
||||
[3]: https://i2.wp.com/itsfoss.com/wp-content/uploads/2020/07/serpent-linux.png?ssl=1
|
||||
[4]: https://www.serpentos.com/about/
|
||||
[5]: https://distrowatch.com/table.php?distribution=solusos
|
||||
[6]: https://itsfoss.com/beta-evolve-os-released/
|
||||
[7]: https://itsfoss.com/ikey-leaves-solus/
|
||||
Loading…
Reference in New Issue
Block a user