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
9223a1a8e8
@ -1,30 +1,32 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (silentdawn-zz)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: (wxy)
|
||||
[#]: url: (https://linux.cn/article-12518-1.html)
|
||||
[#]: subject: (Code your hardware using this open source RTOS)
|
||||
[#]: via: (https://opensource.com/article/20/6/open-source-rtos)
|
||||
[#]: author: (Zhu Tianlong https://opensource.com/users/zhu-tianlong)
|
||||
|
||||
使用 RT-Thread 实时操作系统驱动你的硬件
|
||||
======
|
||||
编程驱动一个微处理器芯片是相当有难度的，但在嵌入式系统开发上，实时操作系统可以为你解决很多此类的困难。
|
||||
![Puzzle pieces coming together to form a computer screen][1]
|
||||
|
||||
> 编程驱动一个微处理器芯片是相当有难度的，但在嵌入式系统开发上，实时操作系统可以为你解决很多此类的困难。
|
||||
|
||||
|
||||
|
||||
从通用计算的角度，操作系统是提供计算机基本功能的一组软件。操作系统保证了计算机硬件可以探测并响应外围器件（如键盘、屏幕、移动设备、打印机等），并管理内存空间和外部存储空间。
|
||||
|
||||
虽然一个 CPU 核心同一时间只能运行单个线程，但现代操作系统可以使多个程序表现的像是在同时运行。每一个任务执行的如此之短，一系列任务切换的如此之快，以至于看起来多个任务像是在并行进行。这一切都是由 _调度器_ 的子进程来控制的。
|
||||
虽然一个 CPU 核心同一时间只能运行单个线程，但现代操作系统可以使多个程序表现的像是在同时运行。每一个任务执行的如此之短，一系列任务切换的如此之快，以至于看起来多个任务像是在并行进行。这一切都是由一个叫做 *调度器* 的子进程来控制的。
|
||||
|
||||
操作系统通常是为计算机准备的，安装在硬盘上，管理计算机所要执行的任务。
|
||||
|
||||
### 为什么实时操作系统对嵌入式系统而言不可或缺
|
||||
|
||||
我曾经在 2008 年接触过嵌入式软件，那时候我还是一名学生，正在学习 [MCS-51][2] 微处理器编程。因为我的主修专业是计算机科学，我在其它课程中的所有程序都是在 PC 上执行的。为微处理器芯片编程是完全不同的体验。人生中第一次，我看到我的程序在裸板上运行，即使到现在我仍然记得，在我看到自己人生中第一个循环点灯程序成功运行时的那种兴奋和激动。
|
||||
我曾经在 2008 年接触过嵌入式软件，那时候我还是一名学生，正在学习 [MCS-51][2] 微处理器编程。因为我的主修专业是计算机科学，我在其它课程中的所有程序都是在 PC 上执行的。为微处理器芯片编程是完全不同的体验。人生中第一次，我看到我的程序在裸板上运行，即使到现在我仍然记得，在我看到自己人生中第一个走马灯程序成功运行时的那种兴奋和激动。
|
||||
|
||||
但那种兴奋转瞬即逝。随着为裸板写出越来越多的程序，我遇到了越来越多的问题。这种沮丧并不是我独有的。直接为芯片写程序很困难，这也是 PC 要运行操作系统的很重要的原因。不幸的是，微处理器芯片（或嵌入式系统）通常是没有操作系统的，它们只能采用”硬编码“的方式编程，没有操作系统帮助你管理代码的运行。
|
||||
但那种兴奋转瞬即逝。随着为裸板写出越来越多的程序，我遇到了越来越多的问题。这种沮丧并不是我独有的。直接为芯片写程序很困难，这也是 PC 要运行操作系统的很重要的原因。不幸的是，微处理器芯片（或嵌入式系统）通常是没有操作系统的，它们只能采用“硬编码”的方式编程，没有操作系统帮助你管理代码的运行。
|
||||
|
||||
在以”硬编码“的方式为处理芯片编写代码的时候，可能会遇到下列问题：
|
||||
在以“硬编码”的方式为处理芯片编写代码的时候，可能会遇到下列问题：
|
||||
|
||||
#### 并发
|
||||
|
||||
@ -34,11 +36,11 @@
|
||||
|
||||
从软件工程的角度，高內聚低耦合原则在软件开发过程中被不厌其烦的频频强调，但是嵌入式软件的不同模块之间常常是重度耦合的，很多功能都集中在一个巨大的 `while (1)` 循环中，很难切分为模块。设计低耦合软件在编程上只是繁琐一些，但在嵌入式系统上，要低耦合就难以编写比较大型的软件。
|
||||
|
||||
与此同时，如果使用了看门狗定时器，程序员还得在调用延时函数时倍加小心。如果延时时间太长，主程序没有得到及时”喂狗“的时机，那么看门狗将在程序运行过程中被触发。嵌入式系统软件开发过程中，需要考虑的东西太多了，即便是个简单的延时函数，都不能掉以轻心。软件越复杂，就越需要细心，越需要想方设法将一系列具有精细时间关系的交互功能拆分为模块。
|
||||
与此同时，如果使用了看门狗定时器，程序员还得在调用延时函数时倍加小心。如果延时时间太长，主程序没有得到及时“喂狗”的时机，那么看门狗将在程序运行过程中被触发。嵌入式系统软件开发过程中，需要考虑的东西太多了，即便是个简单的延时函数，都不能掉以轻心。软件越复杂，就越需要细心。想象一下，试图将这一系列具有精细时间关系的交互功能拆分为模块会怎么样。
|
||||
|
||||
#### 软件生态
|
||||
|
||||
很多厉害的软件组件依赖于其所基于的底层操作系统的实现。举个自身的例子，我曾开发过一个基于 [FreeModbus][3] 的开源项目，原计划将它移植到多种平台上，包括裸板。相对于在各种操作系统上的移植，有些函数在裸板上实现的话实在是太复杂了，以至于无法完成。更糟糕的是，很多硬件平台因为缺乏一致性，只能各自从头做起。
|
||||
很多高级的软件组件依赖于其所基于的底层操作系统的实现。举个自身的例子，我曾开发过一个基于 [FreeModbus][3] 的开源项目，原计划将它移植到多种平台上，包括裸板。但与适应不同操作系统的便利性相比，有些功能过于复杂，无法在所有裸机板上实现。更糟糕的是，很多硬件平台因为缺乏一致性，只能各自从头做起。
|
||||
|
||||
直至现在，我的 Modbus 栈仍然不支持在裸板上运行。
|
||||
|
||||
@ -50,13 +52,14 @@
|
||||
|
||||
#### 重用性
|
||||
|
||||
重用性依赖于模块化。没谁愿意翻来覆去做一成不变的事，对程序员而言更是如此。这不单单是浪费时间，更要命的是这使得代码的维护异常复杂。尤其是，因为功能的实现依赖于底层的硬件，使用了不同芯片的不同种硬件平台上，同样的功能不得不针对每个硬件平台进行适配。这种情况下，重新发明轮子是无法避免的。
|
||||
重用性依赖于模块化。没谁愿意翻来覆去做一成不变的事，对程序员而言更是如此。这不单单是浪费时间，更要命的是这使得代码的维护异常复杂。尤其是，因为功能的实现依赖于底层的硬件，使用了不同芯片的不同硬件平台上，同样的功能必须适配不同的硬件平台。这种情况下，重新发明轮子是无法避免的。
|
||||
|
||||
### 实时操作系统的优势
|
||||
|
||||
幸运的是，现在有针对各种微处理器芯片的操作系统可用，它们被称为实时操作系统（RTOS），和大多数操作系统一样，它们拥有调度器，保证代码以可预见的顺序运行。
|
||||
幸运的是，现在有针对各种微处理器芯片的操作系统，它们被称为实时操作系统（RTOS），和大多数操作系统一样，它们拥有调度器，保证代码以可预见的顺序运行。
|
||||
|
||||
我是在 2010 年初次在裸板上使用实时操作系统。那时候，[STM32][4] 系列微处理器（MCU）开始流行，因为这种微处理器性能强大、功能丰富，很多人在上面跑操作系统。我使用的是 [RT-Thread][5] 操作系统，有很多基于它的现成组件可用。它使用的是 Apache 2.0 许可，和其它操作系统相比，我觉得这个很舒心。我已经基于它作为平台从事开发工作 10 年了。
|
||||
|
||||
我是在 2010 年初次在裸板上使用实时操作系统。那时候，[STM32][4] 系列微处理器（MCU）开始普及，因为这种微处理器性能强大、功能丰富，很多人在上面跑操作系统。我使用的是 [RT-Thread][5] 操作系统，有很多基于它的现成组件可用。它使用的是 Apache 2.0 许可，和其它操作系统的许可相比，我觉得这个很舒心。我已经基于它作为平台从事开发工作 10 年了。
|
||||
使用实时操作系统为裸板编程，操作系统为我们解决了需要处理的大部分问题。
|
||||
|
||||
#### 模块化
|
||||
@ -69,7 +72,7 @@
|
||||
|
||||
#### 实时性
|
||||
|
||||
实时操作系统从设计上就具备实时性。每个线程都被指定了特定的优先级，重要的线程设置为更高的优先级，不重要的线程优先级也低。正是以这种方式，软件整体的实时性得到了保证。
|
||||
实时操作系统从设计上就具备实时性。每个线程都被指定了特定的优先级，比较重要的线程设置为更高的优先级，不重要的线程优先级也低。正是以这种方式，软件整体的实时性得到了保证。
|
||||
|
||||
#### 开发效率
|
||||
|
||||
@ -87,11 +90,11 @@ RT-Thread 丰富的软件生态为大量的从业者带来了巨大的改变。
|
||||
|
||||
![LkdGui][6]
|
||||
|
||||
使用像 LkdGui 这样兼具扩展性和健壮性的功能库，程序员们可以在伙伴已有工作成果的基础上充分施展自己的才能。而这一切，没有实时操作系统这样一个统一的基础，是根本不可能的。
|
||||
使用像 LkdGui 这样兼具扩展性和健壮性的功能库，程序员们可以在同行已有工作成果的基础上充分施展自己的才能。而这一切，没有实时操作系统这样一个统一的基础，是根本不可能的。
|
||||
|
||||
### 试用 RT-Thread
|
||||
|
||||
作为开源极客，我已經在 GitHub 上开源了一些嵌入式软件。在发布开源软件之前，我很少对他人谈及自己曾经的项目，因为不同的人在使用各种不同的微处理器芯片和硬件平台，我的代码极可能无法在他人的板子上运行。 类似于 RT-Thread 的操作系统极大的提升了软件的可重用性，所以全世界的不同领域的专家得以就同一个项目展开探讨。这鼓励着越来越多的人分享和交流各自的项目。如果你在做裸板的软件开发，下次可以试试 TR-Thread。
|
||||
作为开源极客，我已经在 GitHub 上开源了一些嵌入式软件。在发布开源软件之前，我很少对他人谈及自己曾经的项目，因为不同的人在使用各种不同的微处理器芯片和硬件平台，我的代码极可能无法在他人的板子上运行。类似于 RT-Thread 这样的实时操作系统极大的提升了软件的可重用性，所以全世界的不同领域的专家得以就同一个项目展开探讨。这鼓励着越来越多的人分享和交流各自的项目。如果你在做裸板的软件开发，下次可以试试 TR-Thread。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
@ -99,8 +102,8 @@ via: https://opensource.com/article/20/6/open-source-rtos
|
||||
|
||||
作者：[Zhu Tianlong][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[silentdawn-zz](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
译者：[silentdawn-zz](https://github.com/silentdawn-zz)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
181
published/20200716 Summarizing your command usage on Linux.md
Normal file
181
published/20200716 Summarizing your command usage on Linux.md
Normal file
@ -0,0 +1,181 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: (wxy)
|
||||
[#]: url: (https://linux.cn/article-12517-1.html)
|
||||
[#]: subject: (Summarizing your command usage on Linux)
|
||||
[#]: via: (https://www.networkworld.com/article/3567050/summarizing-your-command-usage-on-linux.html)
|
||||
[#]: author: (Sandra Henry-Stocker https://www.networkworld.com/author/Sandra-Henry_Stocker/)
|
||||
|
||||
汇总你在 Linux 上的命令使用情况
|
||||
======
|
||||
|
||||
> 使用合适的命令，你可以快速了解 Linux 系统上使用的命令以及执行的频率。
|
||||
|
||||
|
||||
|
||||
汇总 Linux 系统上使用的命令只需一串相对简单的命令以及几条管道将它们绑定在一起。当你的历史记录缓冲区保留了最近的 1,000 或 2,000 条命令时，总结你的命令活动可能会变得很乏味。这篇文章提供了一种方便的方法来汇总命令的使用情况，并高亮显示最常用的命令。
|
||||
|
||||
首先，请记住，典型的命令历史记录可能看起来像这样。请注意，命令是显示在命令序列号之后，并紧跟其参数。
|
||||
|
||||
```
|
||||
91 sudo apt-get install ccrypt
|
||||
^
|
||||
+-- command
|
||||
```
|
||||
|
||||
请注意，`history` 命令遵循 `HISTSIZE` 的设置，这会决定保留多少条命令。可能是 500、1,000 或更多。如果你不喜欢它的设置，那么可以在 `.bashrc` 或其他启动文件中添加或更改 `HISTSIZE` 设置。
|
||||
|
||||
```
|
||||
$ echo $HISTSIZE
|
||||
1000
|
||||
$ history | wc -l
|
||||
1000
|
||||
$ grep HISTSIZE ~/.bashrc
|
||||
# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)
|
||||
HISTSIZE=1000
|
||||
```
|
||||
|
||||
记下大量命令的主要好处之一是，它可以让你轻松地重新运行过去使用的命令，而不必重新输入或记住它们。它还能让你轻松地查看你在一个任务中已经做了多少工作。单独使用 `history` 命令时，你会看到类似下面这样，最早的在最前面：
|
||||
|
||||
```
|
||||
$ history
|
||||
7 vi tasks
|
||||
8 alias
|
||||
9 echo $HISTTIMEFORMAT
|
||||
10 history
|
||||
11 date
|
||||
…
|
||||
```
|
||||
|
||||
查看最新使用命令需要查看记录的命令的尾部：
|
||||
|
||||
```
|
||||
$ history | tail -4
|
||||
1007 echo $HISTSIZE
|
||||
1008 history | wc -l
|
||||
1009 history
|
||||
1010 history | tail -4
|
||||
```
|
||||
|
||||
另外，你可以使用 `tail` 命令查看 `.bash_history` 文件的尾部，但是 `history` 命令显示的数字可以让你输入如 `!1010` 这样的数字重新运行命令，这点通常更有用。
|
||||
|
||||
要提供已使用命令的汇总（例如 `vi` 和 `echo`），你可以首先使用 `awk` 将命令与 `history` 中保存的其他信息分隔开来：
|
||||
|
||||
```
|
||||
$ history | awk '{print $2}'
|
||||
vi
|
||||
alias
|
||||
echo
|
||||
history
|
||||
date
|
||||
…
|
||||
```
|
||||
|
||||
如果你将历史记录中的命令列表传递给 `sort` 命令以按字母顺序对命令进行分组，那么会得到以下内容：
|
||||
|
||||
```
|
||||
$ history | awk '{print $2}' | sort
|
||||
7z
|
||||
7z
|
||||
alias
|
||||
apropos
|
||||
cd
|
||||
cd
|
||||
…
|
||||
```
|
||||
|
||||
接下来，将 `sort` 命令的输出传递给 `uniq -c` ，这将计算每个命令使用了多少次：
|
||||
|
||||
```
|
||||
$ history | awk '{print $2}' | sort | uniq -c
|
||||
2 7z
|
||||
1 alias
|
||||
2 apropos
|
||||
38 cd
|
||||
21 chmod
|
||||
…
|
||||
```
|
||||
|
||||
最后，添加第二个 `sort` 命令按倒序对命令组计数进行排序，这将先列出最常用的命令：
|
||||
|
||||
```
|
||||
$ history | awk '{print $2}' | sort | uniq -c | sort -nr
|
||||
178 ls
|
||||
95 vi
|
||||
63 cd
|
||||
53 sudo
|
||||
41 more
|
||||
…
|
||||
```
|
||||
|
||||
这样可以让你了解使用最多的命令，但不会包括任何你可能故意从历史记录文件中删除的命令，例如：
|
||||
|
||||
```
|
||||
HISTIGNORE="pwd:clear:man:history"
|
||||
```
|
||||
|
||||
### 当修改了历史记录格式时
|
||||
|
||||
对于默认的历史记录格式，`history` 命令输出中的第一个字段将是每个命令的序号，第二个字段是使用的命令。因此，上面所有 `awk` 命令都设置成显示 `$2`。
|
||||
|
||||
```
|
||||
$ alias cmds='history | awk '\''{print $2}'\'' | sort | uniq -c | sort -nr'
|
||||
```
|
||||
|
||||
如果你像下面那样将日期和时间添加了到 `history` 命令中，那么你还必须修改所设置的别名：
|
||||
|
||||
```
|
||||
$ echo $HISTTIMEFORMAT
|
||||
%d/%m/%y %T
|
||||
```
|
||||
|
||||
这个日期/时间信息有时会很有帮助，但是这意味着你必须在选择 `history` 命令的第 4 个字段而不是第 2 个字段来汇总命令，因为你的历史记录条目将如下所示：
|
||||
|
||||
```
|
||||
91 05/07/20 16:37:39 sudo apt-get install ccrypt
|
||||
^
|
||||
+-- command
|
||||
```
|
||||
|
||||
因此，在将 `$2` 变为 `$4` 之后，用于检查 `history` 命令的别名将改为这样：
|
||||
|
||||
```
|
||||
$ alias cmds='history | awk '\''{print $4}'\'' | sort | uniq -c | sort -nr'
|
||||
```
|
||||
|
||||
可将别名保存在 `.bashrc` 或其他启动文件中，请确保在 `$` 符号前面插入反斜杠，以便 bash 不会尝试解释 `$4`。
|
||||
|
||||
```
|
||||
alias cmds='history | awk '\''{print \$2}'\'' | uniq -c | sort -nr'
|
||||
alias cmds='history | awk '\''{print \$4}'\'' | uniq -c | sort -nr'
|
||||
```
|
||||
|
||||
请注意，日期和时间信息与命令本身保存在历史记录文件的不同行中。因此，添加此信息后，bash 历史记录文件的行数将增加一倍，尽管在 `history` 命令输出时不会：
|
||||
|
||||
```
|
||||
$ wc -l .bash_history
|
||||
2000 .bash_history
|
||||
$ history | wc -l
|
||||
1000
|
||||
```
|
||||
|
||||
### 总结
|
||||
|
||||
你可以随时决定要保留多少命令历史记录，哪些命令不值得记录，以使你的命令摘要最有用。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.networkworld.com/article/3567050/summarizing-your-command-usage-on-linux.html
|
||||
|
||||
作者：[Sandra Henry-Stocker][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [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://www.facebook.com/NetworkWorld/
|
||||
[2]: https://www.linkedin.com/company/network-world
|
||||
@ -0,0 +1,107 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (What Does Mozilla Firing 25% of its Workforce Tells us About its Future)
|
||||
[#]: via: (https://itsfoss.com/mozilla-struggle/)
|
||||
[#]: author: (Abhishek Prakash https://itsfoss.com/author/abhishek/)
|
||||
|
||||
What Does Mozilla Firing 25% of its Workforce Tells us About its Future
|
||||
======
|
||||
|
||||
Mozilla is in news again but not for good reasons.
|
||||
|
||||
[Mozilla has suddenly fired around 250 employees][1], 25% of its workforce. It also closed operations in Taipei, Taiwan. The Taiwanese team was working on Firefox Lite.
|
||||
|
||||
This is not the first layoff from Mozilla this year. At the beginning of the year, [Mozilla had laid off 70 employees][2].
|
||||
|
||||
So, what’s going on with Mozilla? Whatever it is, it’s certainly not positive.
|
||||
|
||||
Mozilla has fired entire (or most of) teams working on [DevTools][3], [MDN][4], developer relation, [Servo][5] (browser engine written in Rust) and incident threat management.
|
||||
|
||||
Why did it do that? What lies ahead for Mozilla? Here’s my opinion on the Mozilla crisis.
|
||||
|
||||
### The gradual decline of Mozilla: Ignoring its flagship Firefox browser project
|
||||
|
||||
Mozilla Firefox once had a good user base. It was seen as a superior browser and it looked like it would dethrone Internet Explorer as the most popular web browser.
|
||||
|
||||
That would have happened if it was not for Google Chrome. The tech giant Google and its ‘thinking ahead’ leadership launched Google Chrome in 2008.
|
||||
|
||||
Their aim was to get more and more people to use their search engine. How does a user access search engine? Through a web browser.
|
||||
|
||||
So, instead of being dependent on other web browsers, Google created its own browser and integrated its products with this new browser. Google hired several Mozilla engineers to work on its browser. The current Google CEO, Sundar Pichai, led the team developing the Chrome browser.
|
||||
|
||||
But Google didn’t just stop after creating Chrome in 2008. Google with all its technical might and intelligence, kept on improving the Chrome browser.
|
||||
|
||||
Soon Google Chrome overtook Firefox and later Internet Explorer to become the most popular web browser.
|
||||
|
||||
> The rise and fall of [#opensource][6] web browser Mozilla Firefox. [pic.twitter.com/Co5Xj3dKIQ][7]
|
||||
>
|
||||
> — Abhishek Prakash (@abhishek_foss) [March 22, 2017][8]
|
||||
|
||||
But what happened to Mozilla Firefox? It is my opinion that Mozilla lost focus on the Firefox browser. They put time and energy in creating [Firefox mobile OS][9], Rust programming language, Hello video chat application and more.
|
||||
|
||||
It’s not that it didn’t add new features to it, it’s just that Firefox started losing charm.
|
||||
|
||||
Chrome had a faster experience while Firefox felt sluggish and heavy. Google’s evil practice of [deliberately slowing down Google products like YouTube on Firefox][10] also made users dump Firefox.
|
||||
|
||||
Whatever it is. The truth is that Google Chrome is a superior product otherwise people won’t go installing it on their own. Microsoft couldn’t keep Windows users on Internet Explorer/Edge after all.
|
||||
|
||||
### Google holds Mozilla by its neck and can squeeze it at will
|
||||
|
||||
![][11]
|
||||
|
||||
If you didn’t know, Mozilla relies heavily on Google with around 90% of its revenue coming from Google. [Google pays Mozilla a few hundred million US dollars each year][12] to be the default search engine on Firefox.
|
||||
|
||||
The deal was helpful to Google when Firefox had good user base. With Google Chrome’s advent, Firefox has seen steep decline and it now stands at the third position with hardly 8% of the market share. Google Chrome dominates the market.
|
||||
|
||||
Google doesn’t need Firefox’s help to get traffic to its search engine but Mozilla does need Google’s money to stay alive.
|
||||
|
||||
A day after the layoffs, [Google extended the Firefox search deal with Mozilla][13]. Had Google not renewed its deal with Mozilla, it would have been real difficult for Mozilla to go beyond 2020.
|
||||
|
||||
### Mozilla’s renewed focus on products that could make it money
|
||||
|
||||
Mozilla Foundation is a not-for-profit organization but it also has taxable subsidiary in the form of Mozilla Corporation. Firefox browser is developed under Mozilla Foundation. The profit earned by the Mozilla Corporation is reinvested into Mozilla projects.
|
||||
|
||||
Lately, Mozilla is trying hard to create new revenue channels to end its reliance on Google. Its [acquisition of Pocket app][14] and the launch of [Mozilla VPN][15] is part of this strategy.
|
||||
|
||||
The recent layoffs are also part of Mozilla’s new strategy to focus on profitable products and reducing the workforce aimed at reducing the expense.
|
||||
|
||||
But amidst all this, Mozilla must not ignore Firefox. People need a functioning browser and Mozilla should work on improving user experience. If the users have trouble [running Netflix][16] or YouTube or using other streaming services in this age, they will definitely switch.
|
||||
|
||||
Not only it is the flagship project from Mozilla, it is also the biggest hope for people who don’t want Google. Microsoft’s Edge, Opera, Vivaldi, Brave and most of the other popular browsers have switched to Google’s Chromium project. Firefox is one of the rare browsers that doesn’t rely on Chromium.
|
||||
|
||||
I hope that Mozilla rises from the ashes like a Phoenix.
|
||||
|
||||
Those were my views on the Mozilla situation. I welcome yours in the comment section.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://itsfoss.com/mozilla-struggle/
|
||||
|
||||
作者：[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://thenextweb.com/insights/2020/08/11/mozilla-firefox-layoffs-250-employees/
|
||||
[2]: https://www.bizjournals.com/sanjose/c/mountain-view-based-mozilla-laysoff-around-70.html
|
||||
[3]: https://developer.mozilla.org/en-US/docs/Tools
|
||||
[4]: https://developer.mozilla.org/en-US/
|
||||
[5]: https://servo.org/
|
||||
[6]: https://twitter.com/hashtag/opensource?src=hash&ref_src=twsrc%5Etfw
|
||||
[7]: https://t.co/Co5Xj3dKIQ
|
||||
[8]: https://twitter.com/abhishek_foss/status/844666818665025537?ref_src=twsrc%5Etfw
|
||||
[9]: https://en.wikipedia.org/wiki/Firefox_OS
|
||||
[10]: https://fortune.com/2018/07/25/youtube-slow-mozilla-firefox-chrome/
|
||||
[11]: https://i1.wp.com/itsfoss.com/wp-content/uploads/2020/08/mozilla-struggle.jpg?resize=800%2C450&ssl=1
|
||||
[12]: https://www.zdnet.com/article/firefox-hits-the-jackpot-with-almost-billion-dollar-google-deal/
|
||||
[13]: https://www.theregister.com/2020/08/14/mozilla_google_search/
|
||||
[14]: https://blog.mozilla.org/blog/2017/02/27/mozilla-acquires-pocket/
|
||||
[15]: https://vpn.mozilla.org/
|
||||
[16]: https://itsfoss.com/netflix-firefox-linux/
|
||||
@ -0,0 +1,135 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (7 tips for giving and receiving better feedback)
|
||||
[#]: via: (https://opensource.com/article/20/8/better-feedback)
|
||||
[#]: author: (Dawn Parzych https://opensource.com/users/dawnparzych)
|
||||
|
||||
7 tips for giving and receiving better feedback
|
||||
======
|
||||
Good feedback is important for growing, learning, and improving.
|
||||
![Pair programming][1]
|
||||
|
||||
Getting feedback isn't always easy to handle, but we need to hear it to grow and learn. Feedback can take many forms—from formalized feedback in performance reviews to more informal feedback such as:
|
||||
|
||||
* Code reviews
|
||||
* Peer reviews of writing
|
||||
* Comments for a speaker
|
||||
* Recommending revisions to a resume
|
||||
|
||||
|
||||
|
||||
There is an art to giving, asking for, and receiving feedback in a way that is actionable and helps people improve. To narrow down this topic, I'll focus on feedback related to writing (as that is one of my specialties), but many of these lessons apply to any type of feedback you need to give or receive.
|
||||
|
||||
### Tips for giving feedback
|
||||
|
||||
If you've been asked to give feedback, first, confirm you understand what type of feedback is being requested. The person asking for feedback should provide guidelines for what you should focus on. If you don't know what type of feedback to give, ask. Also, make sure to ask when they need the feedback. If you can't meet their deadline, let them know. Maybe the timeline is flexible. If not, they have the opportunity to find somebody else to help.
|
||||
|
||||
It's OK to say no—a short message declining the request and explaining why is much better than ignoring it and potentially making the person miss their deadline.
|
||||
|
||||
#### Content vs. style
|
||||
|
||||
There are many different ways to write a sentence, and everybody has their own style. Focus on the content of what was said rather than how it was said. Unless you've been explicitly asked to help rewrite an article, don't worry if you would have said something differently. If the correct meaning is conveyed, that is what matters.
|
||||
|
||||
For example, these sentences all say roughly the same thing.
|
||||
|
||||
> A large part of building and operating software is learning what works and what doesn't.
|
||||
>
|
||||
> Software engineers spend a great deal of time determining what works and what does not work when building and operating software.
|
||||
>
|
||||
> Software engineers expend a considerable amount of time ascertaining the effectiveness and interoperability of software and hardware.
|
||||
|
||||
The "right" version has everything to do with the writer's and the audience's preferred style.
|
||||
|
||||
#### Clarity
|
||||
|
||||
This doesn't mean you shouldn't be concerned about clarity. If something is unclear, speak up. It helps when you provide context about why you found something confusing or vague (again, clarity matters). The writer might not know where you are getting hung up.
|
||||
|
||||
This is unclear feedback:
|
||||
|
||||
* "This is confusing."
|
||||
* "What do you mean here?"
|
||||
|
||||
|
||||
|
||||
Better feedback (this is all real feedback I've either given or received recently):
|
||||
|
||||
* "I think this could use a little clarification on what you mean by 'we.'"
|
||||
* "Do you mean a team with a single project, or do you mean to choose a single team?"
|
||||
|
||||
|
||||
|
||||
If you have time and it's possible, provide suggestions on how it can be made clearer for you, such as:
|
||||
|
||||
* "On a hasty reading, I initially misinterpreted this as claiming x (whereas obviously, you meant the opposite)."
|
||||
|
||||
|
||||
|
||||
#### Twice as nice
|
||||
|
||||
Read the entire content at least twice. The first time you read it, don't leave any comments or make any suggestions; just read to see what information is covered. Otherwise, you might suggest that a specific topic should be included—then see it two paragraphs later.
|
||||
|
||||
#### Leave positive feedback
|
||||
|
||||
Often when we give feedback, we focus only on the areas that need improvement. If there is something you like, share that feedback as well. Writers want to know what resonates, as well as what didn't quite hit the mark. What made you laugh or cringe? What did you learn?
|
||||
|
||||
### Tips for getting feedback
|
||||
|
||||
A great way to receive feedback is by asking for it. Here are some suggestions that will help you get feedback that's most useful to you.
|
||||
|
||||
#### Be specific
|
||||
|
||||
When you request feedback, tell your reviewers exactly what you are looking for, including what specific areas you want people to focus on and what not to worry about.
|
||||
|
||||
This request is vague:
|
||||
|
||||
> "Can you please read this and let me know what you think?"
|
||||
|
||||
The reviewer doesn't know if you're asking them to review for technical accuracy, grammar, or something else. I sometimes forget to do this when I ask for feedback, and thankfully, I have a colleague who will follow-up and ask for more context by asking, "What level and depth of review are you looking for?"
|
||||
|
||||
Since I'm trying to get better at giving specifics when asking for feedback, I often leave comments in my articles for my reviewers with questions I have, things I'm struggling with, or areas I think are weak and need improvement.
|
||||
|
||||
Here's a good example from one of my colleagues on asking for specific feedback:
|
||||
|
||||
> "I'd hugely appreciate any comments on this, especially things I have wrong, or over/understate, or other things to include (some of which may be punted to the next version, but hearing them now would still be very useful)."
|
||||
|
||||
#### State your deadline
|
||||
|
||||
Make sure to include a timeframe when you need their feedback. You don't want review cycles dragging on and blocking your progress while you're waiting for feedback. Give reasonable deadlines, and if there is a need for urgency, explain why. You might say:
|
||||
|
||||
> "Can you review this for technical accuracy and readability by the end of the week? Don't worry about grammar. I'll make those edits later."
|
||||
|
||||
Or
|
||||
|
||||
> "Can you provide copy-editing by the end of the day? This needs to be published tomorrow to coincide with our launch."
|
||||
|
||||
#### Decide what to include
|
||||
|
||||
You may not agree with all the feedback you hear. It is up to you as the writer whether to incorporate it or not. I highly encourage you to incorporate feedback that points out blatant errors. The feedback that can be more challenging is differences of opinion, stylistic changes, etc. I often schedule meetings to review the feedback if there are differing viewpoints. Talking can often clarify things faster than writing comments back and forth.
|
||||
|
||||
### Conclusion
|
||||
|
||||
Asking for feedback can trigger [imposter syndrome][2]. That won't necessarily go away, but giving good feedback (even if it is negative feedback) can help a writer overcome that feeling.
|
||||
|
||||
If you're interested in ways to become a better writer, I've previously written about my [writing process][3], which includes multiple feedback loops.
|
||||
|
||||
As a writer, your job is to write content that people enjoy, resonates with your readers, and serves a purpose. As a reviewer, your job is to share what you learned and what was confusing. These tips can help you give and receive better feedback.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/8/better-feedback
|
||||
|
||||
作者：[Dawn Parzych][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/dawnparzych
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/collab-team-pair-programming-code-keyboard.png?itok=kBeRTFL1 (Pair programming)
|
||||
[2]: https://opensource.com/article/19/11/my-first-open-source-contribution-impostor-syndrome
|
||||
[3]: https://opensource.com/article/20/5/write-about-open-source-software
|
||||
@ -0,0 +1,109 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Come test a new release of pipenv, the Python development tool)
|
||||
[#]: via: (https://fedoramagazine.org/come-test-a-new-release-of-pipenv-the-python-development-tool/)
|
||||
[#]: author: (torsava https://fedoramagazine.org/author/torsava/)
|
||||
|
||||
Come test a new release of pipenv, the Python development tool
|
||||
======
|
||||
|
||||
![][1]
|
||||
|
||||
**[Pipenv][2]** is a tool that helps Python developers maintain isolated virtual environments with specifacally defined set of dependencies to achieve reproducible development and deployment environments. It is similar to tools for different programming languages, such as bundler, composer, npm, cargo, yarn, etc.
|
||||
|
||||
A new version of pipenv, 2020.6.2, has been recently released. It is now available in Fedora 33 and rawhide. For older Fedoras, the maintainers decided to package it in [COPR][3] to be tested first. So come try it out, before they push it into stable Fedora versions. The new version doesn’t bring any fancy new features, but after two years of development it fixes a lot of problems and does many things differently under the hood. What worked for you previously should continue to work, but might behave slightly differently.
|
||||
|
||||
### How to get it
|
||||
|
||||
If you are already running Fedora 33 or rawhide, run _$ sudo dnf upgrade pipenv_ or _$ sudo dnf install pipenv_ and you’ll get the new version.
|
||||
|
||||
On Fedora 31 or Fedora 32, you’ll need to use a [copr repository][3] until such time comes that the tested package will be updated in the official place. To enable the repository, run:
|
||||
|
||||
```
|
||||
$ sudo dnf copr enable @python/pipenv
|
||||
```
|
||||
|
||||
Then to upgrade pipenv to the new version, run:
|
||||
|
||||
```
|
||||
$ sudo dnf upgrade pipenv
|
||||
```
|
||||
|
||||
Or, if you haven’t installed it yet, install it via:
|
||||
|
||||
```
|
||||
$ sudo dnf install pipenv
|
||||
```
|
||||
|
||||
In case you ever need to roll back to the officially maintained version, you can run:
|
||||
|
||||
```
|
||||
$ sudo dnf copr disable @python/pipenv
|
||||
$ sudo dnf distro-sync pipenv
|
||||
```
|
||||
|
||||
_COPR is not officially supported by Fedora infrastructure. Use packages at your own risk._
|
||||
|
||||
### How to use it
|
||||
|
||||
If you already have projects managed by the older version of pipenv, you should be able to use the new version in its place without issues. Let us know if something breaks.
|
||||
|
||||
If you are not yet familiar with pipenv or want to start a new project, here is a quick guide:
|
||||
|
||||
Create a working directory:
|
||||
|
||||
```
|
||||
$ mkdir new-project && cd new-project
|
||||
```
|
||||
|
||||
Initialize pipenv with Python 3:
|
||||
|
||||
```
|
||||
$ pipenv --three
|
||||
```
|
||||
|
||||
Install the packages you want, e.g.:
|
||||
|
||||
```
|
||||
$ pipenv install six
|
||||
```
|
||||
|
||||
Generate a Pipfile.lock file:
|
||||
|
||||
```
|
||||
$ pipenv lock
|
||||
```
|
||||
|
||||
Now you can commit the created Pipfile and Pipfile.lock files into your version control system (e.g. git) and others can use this command in the cloned repository to get the same environment:
|
||||
|
||||
```
|
||||
$ pipenv install
|
||||
```
|
||||
|
||||
See [pipenv’s documentation][4] for more examples.
|
||||
|
||||
### How to report problems
|
||||
|
||||
If you encounter any problems with the new pipenv version, please [report any issues in Fedora’s Bugzilla][5]. The maintainers of the pipenv package in official Fedora repositories and in the copr repository are the same. Please indicate in the text that the report is regarding this new version.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://fedoramagazine.org/come-test-a-new-release-of-pipenv-the-python-development-tool/
|
||||
|
||||
作者：[torsava][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://fedoramagazine.org/author/torsava/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://fedoramagazine.org/wp-content/uploads/2018/06/pipenv-install-816x345.jpg
|
||||
[2]: https://github.com/pypa/pipenv
|
||||
[3]: https://copr.fedorainfracloud.org/coprs/g/python/pipenv/
|
||||
[4]: https://pipenv.pypa.io/en/latest/install/
|
||||
[5]: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=pipenv
|
||||
@ -1,180 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Summarizing your command usage on Linux)
|
||||
[#]: via: (https://www.networkworld.com/article/3567050/summarizing-your-command-usage-on-linux.html)
|
||||
[#]: author: (Sandra Henry-Stocker https://www.networkworld.com/author/Sandra-Henry_Stocker/)
|
||||
|
||||
汇总 Linux 上命令的使用率
|
||||
======
|
||||
使用合适的命令，你可以快速了解 Linux 系统上使用的命令以及执行的频率。
|
||||
|
||||
汇总 Linux 系统上使用的命令只需相对简单的命令串以及几条管道将它们绑定在一起。当你的历史记录缓冲区保留了最近的 1,000 或 2,000 条命令时，汇总命令活动可能会变得很乏味。这篇文章提供了一种方便的方法来汇总命令并高亮显示最常用的命令。
|
||||
|
||||
首先，请记住，典型的历史命令记录可能看起来像这样。请注意，命令显示在命令序列号之后，并紧跟其参数。
|
||||
|
||||
```
|
||||
91 sudo apt-get install ccrypt
|
||||
^
|
||||
+-- command
|
||||
```
|
||||
|
||||
请注意，history 命令遵循 HISTSIZE 的设置，这会决定保留多少条命令。可能是 500、1,000 或更多。如果你不喜欢它的设置，那么可以在 .bashrc 或其他启动文件中添加或更改 HISTSIZE 设置。
|
||||
|
||||
```
|
||||
$ echo $HISTSIZE
|
||||
1000
|
||||
$ history | wc -l
|
||||
1000
|
||||
$ grep HISTSIZE ~/.bashrc
|
||||
# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)
|
||||
HISTSIZE=1000
|
||||
```
|
||||
|
||||
记住大量命令的主要好处之一是，它可以让你轻松地重新运行过去使用的命令，而不必重新输入或记住它们。它还能让你轻松地查看你在一个任务中已经做了多少工作。单独使用 **history** 命令时，你会看到类似下面这样，最早的在最前面：
|
||||
|
||||
```
|
||||
$ history
|
||||
7 vi tasks
|
||||
8 alias
|
||||
9 echo $HISTTIMEFORMAT
|
||||
10 history
|
||||
11 date
|
||||
…
|
||||
```
|
||||
|
||||
查看最新使用命令需要查看命令的底部：
|
||||
|
||||
```
|
||||
$ history | tail -4
|
||||
1007 echo $HISTSIZE
|
||||
1008 history | wc -l
|
||||
1009 history
|
||||
1010 history | tail -4
|
||||
```
|
||||
|
||||
另外，你可以使用 ** tail **命令查看 **.bash_history** 文件的底部，但是 **history** 命令显示的数字可以让你输入如 **!1010** 这样的数字重新运行命令，这点通常更有用。
|
||||
|
||||
要准备已使用命令的汇总（例如 **vi** 和 **echo**），你可以首先使用 **awk** 将命令与 history 中保存的其他信息分隔开来：
|
||||
|
||||
```
|
||||
$ history | awk '{print $2}'
|
||||
vi
|
||||
alias
|
||||
echo
|
||||
history
|
||||
date
|
||||
…
|
||||
```
|
||||
|
||||
如果你将历史记录中的命令列表传递给 **sort** 命令以按字母顺序对命令进行分组，那么会得到以下内容：
|
||||
|
||||
```
|
||||
$ history | awk '{print $2}' | sort
|
||||
7z
|
||||
7z
|
||||
alias
|
||||
apropos
|
||||
cd
|
||||
cd
|
||||
…
|
||||
```
|
||||
|
||||
接下来，将 **sort** 命令的输出传递给 **uniq -c** ，这将计算每个命令使用了多少次。
|
||||
|
||||
```
|
||||
$ history | awk '{print $2}' | sort | uniq -c
|
||||
2 7z
|
||||
1 alias
|
||||
2 apropos
|
||||
38 cd
|
||||
21 chmod
|
||||
…
|
||||
```
|
||||
|
||||
最后，添加第二个 **sort** 命令按倒序对命令组计数进行排序，这将先列出最常用的命令。
|
||||
|
||||
```
|
||||
$ history | awk '{print $2}' | sort | uniq -c | sort -nr
|
||||
178 ls
|
||||
95 vi
|
||||
63 cd
|
||||
53 sudo
|
||||
41 more
|
||||
…
|
||||
```
|
||||
|
||||
这样可以让你了解使用最多的命令，但不会包括任何你可能故意从历史记录文件中删除的命令，例如：
|
||||
|
||||
```
|
||||
HISTIGNORE="pwd:clear:man:history"
|
||||
```
|
||||
|
||||
### 当历史变更时
|
||||
|
||||
对于默认的历史记录格式，**history** 命令输出中的第一个字段将是每个命令的序号，第二个字段是使用的命令。因此，上面所有 **awk** 命令都设置成显示 **$2**。
|
||||
|
||||
```
|
||||
$ alias cmds='history | awk '\''{print $2}'\'' | sort | uniq -c | sort -nr'
|
||||
```
|
||||
|
||||
如果你像下面那样将日期和时间添加了到 history 命令中，那么你还必须修改所设置的别名。
|
||||
|
||||
```
|
||||
$ echo $HISTTIMEFORMAT
|
||||
%d/%m/%y %T
|
||||
```
|
||||
|
||||
这个日期/时间信息有时会很有帮助，但是这意味着你必须在选择 history 命令的第 4 个字段而不是第 2 个字段来汇总命令，因为你的历史记录条目将如下所示：
|
||||
|
||||
```
|
||||
91 05/07/20 16:37:39 sudo apt-get install ccrypt
|
||||
^
|
||||
+-- command
|
||||
```
|
||||
|
||||
因此，在将 $2 变为 $4 之后，用于检查 history 命令的别名将改为这样。
|
||||
|
||||
```
|
||||
$ alias cmds='history | awk '\''{print $4}'\'' | sort | uniq -c | sort -nr'
|
||||
```
|
||||
|
||||
可将别名保存在 **.bashrc** 或其他启动文件中，请确保在 **$** 符号前面插入反斜杠，以便 bash 不会尝试解释 **$4**。
|
||||
|
||||
```
|
||||
alias cmds='history | awk '\''{print \$2}'\'' | uniq -c | sort -nr'
|
||||
alias cmds='history | awk '\''{print \$4}'\'' | uniq -c | sort -nr'
|
||||
```
|
||||
|
||||
请注意，日期和时间信息与命令本身保存在历史记录文件的不同行中。因此，添加此信息后，bash 历史记录文件的行数将增加一倍，尽管在输出 history 命令时不会：
|
||||
|
||||
```
|
||||
$ wc -l .bash_history
|
||||
2000 .bash_history
|
||||
$ history | wc -l
|
||||
1000
|
||||
```
|
||||
|
||||
### 总结
|
||||
|
||||
你始终可以决定要保留多少命令历史记录以及哪些记录不需要，以使命令汇总最有用。
|
||||
|
||||
加入 [Facebook][1] 和 [LinkedIn][2] 上的 Network World 社区，评论热门主题。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.networkworld.com/article/3567050/summarizing-your-command-usage-on-linux.html
|
||||
|
||||
作者：[Sandra Henry-Stocker][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://www.networkworld.com/author/Sandra-Henry_Stocker/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://www.facebook.com/NetworkWorld/
|
||||
[2]: https://www.linkedin.com/company/network-world
|
||||
Loading…
Reference in New Issue
Block a user