mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-25 23:11:02 +08:00
add file
This commit is contained in:
Morisun029
parent
04893309f2
commit
8c0e4f1669
@ -0,0 +1,57 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (Morisun029)
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: (wxy)
|
||||
[#]: url: (https://linux.cn/article-11875-1.html)
|
||||
[#]: subject: (Top CI/CD resources to set you up for success)
|
||||
[#]: via: (https://opensource.com/article/19/12/cicd-resources)
|
||||
[#]: author: (Jessica Cherry https://opensource.com/users/jrepka)
|
||||
|
||||
顶级 CI / CD 资源，助你成功
|
||||
======
|
||||
|
||||
> 随着企业期望实现无缝、灵活和可扩展的部署，持续集成和持续部署成为 2019 年的关键主题。
|
||||
|
||||
![Plumbing tubes in many directions][1]
|
||||
|
||||
对于 CI/CD 和 DevOps 来说，2019 年是非常棒的一年。Opensource.com 的作者分享了他们专注于无缝、灵活和可扩展部署时是如何朝着敏捷和 scrum 方向发展的。以下是我们 2019 年发布的 CI/CD 文章中的一些重要文章。
|
||||
|
||||
### 学习和提高你的 CI/CD 技能
|
||||
|
||||
我们最喜欢的一些文章集中在 CI/CD 的实操经验上，并涵盖了许多方面。通常以 [Jenkins][2] 管道开始，Bryant Son 的文章《[用 Jenkins 构建 CI/CD 管道][3]》将为你提供足够的经验，以开始构建你的第一个管道。Daniel Oh 在《[用 DevOps 管道进行自动验收测试][4]》一文中，提供了有关验收测试的重要信息，包括可用于自行测试的各种 CI/CD 应用程序。我写的《[安全扫描 DevOps 管道][5]》非常简短，其中简要介绍了如何使用 Jenkins 平台在管道中设置安全性。
|
||||
|
||||
### 交付工作流程
|
||||
|
||||
正如 Jithin Emmanuel 在《[Screwdriver：一个用于持续交付的可扩展构建平台][6]》中分享的，在学习如何使用和提高你的 CI/CD 技能方面，工作流程很重要，特别是当涉及到管道时。Emily Burns 在《[为什么 Spinnaker 对 CI/CD 很重要][7]》中解释了灵活地使用 CI/CD 工作流程准确构建所需内容的原因。Willy-Peter Schaub 还盛赞了为所有产品创建统一管道的想法，以便《[在一个 CI/CD 管道中一致地构建每个产品][8]》。这些文章将让你很好地了解在团队成员加入工作流程后会发生什么情况。
|
||||
|
||||
### CI/CD 如何影响企业
|
||||
|
||||
2019 年也是认识到 CI/CD 的业务影响以及它是如何影响日常运营的一年。Agnieszka Gancarczyk 分享了 Red Hat 《[小型 Scrum vs. 大型 Scrum][9]》的调查结果, 包括受访者对 Scrum、敏捷运动及对团队的影响的不同看法。Will Kelly 的《[持续部署如何影响整个组织][10]》，也提及了开放式沟通的重要性。Daniel Oh 也在《[DevOps 团队必备的 3 种指标仪表板][11]》中强调了指标和可观测性的重要性。最后是 Ann Marie Fred 的精彩文章《[不在生产环境中测试？要在生产环境中测试！][12]》详细说明了在验收测试前在生产环境中测试的重要性。
|
||||
|
||||
感谢许多贡献者在 2019 年与 Opensource 的读者分享他们的见解，我期望在 2020 年里从他们那里了解更多有关 CI/CD 发展的信息。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/19/12/cicd-resources
|
||||
|
||||
作者：[Jessica Cherry][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[Morisun029](https://github.com/Morisun029)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/jrepka
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/plumbing_pipes_tutorial_how_behind_scenes.png?itok=F2Z8OJV1 (Plumbing tubes in many directions)
|
||||
[2]: https://jenkins.io/
|
||||
[3]: https://linux.cn/article-11546-1.html
|
||||
[4]: https://opensource.com/article/19/4/devops-pipeline-acceptance-testing
|
||||
[5]: https://opensource.com/article/19/7/security-scanning-your-devops-pipeline
|
||||
[6]: https://opensource.com/article/19/3/screwdriver-cicd
|
||||
[7]: https://opensource.com/article/19/8/why-spinnaker-matters-cicd
|
||||
[8]: https://opensource.com/article/19/7/cicd-pipeline-rule-them-all
|
||||
[9]: https://opensource.com/article/19/3/small-scale-scrum-vs-large-scale-scrum
|
||||
[10]: https://opensource.com/article/19/7/organizational-impact-continuous-deployment
|
||||
[11]: https://linux.cn/article-11183-1.html
|
||||
[12]: https://opensource.com/article/19/5/dont-test-production
|
||||
@ -0,0 +1,72 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Open source vs. proprietary: What's the difference?)
|
||||
[#]: via: (https://opensource.com/article/20/2/open-source-vs-proprietary)
|
||||
[#]: author: (Seth Kenlon https://opensource.com/users/seth)
|
||||
|
||||
Open source vs. proprietary: What's the difference?
|
||||
======
|
||||
Need four good reasons to tell your friends to use open source? Here's
|
||||
how to make your case.
|
||||
![Doodles of the word open][1]
|
||||
|
||||
There's a lot to be learned from open source projects. After all, managing hundreds of disparate, asynchronous commits and bugs doesn't happen by accident. Someone or something has to coordinate releases, and keep all the code and project roadmaps organized. It's a lot like life. You have lots of tasks demanding your attention, and you have to tend to each in turn. To ensure everything gets done before its deadline, you try to stay organized and focused.
|
||||
|
||||
Fortunately, there are [applications out there][2] designed to help with that sort of thing, and many apply just as well to real life as they do to software.
|
||||
|
||||
Here are some reasons for choosing [open tools][3] when improving personal or project-based organization.
|
||||
|
||||
### Data ownership
|
||||
|
||||
It's rarely profitable for proprietary tools to provide you with [data][4] dumps. Some products, usually after a long battle with their users (and sometimes a lawsuit), provide ways to extract your data from them. But the real issue isn't whether a company lets you extract data; it's the fact that the capability to get to your data isn't guaranteed in the first place. It's your data, and when it's literally what you do each day, it is, in a way, your life. Nobody should have primary access to that but you, so why should you have to petition a company for a copy?
|
||||
|
||||
Using an open source tool ensures you have priority access to your own activities. When you need a copy of something, you already have it. When you need to export it from one application to another, you have complete control of how the data is exchanged. If you need to export your schedule from a calendar into your kanban board, you can manipulate and process the data to fit. You don't have to wait for functionality to be added to the app, because you own the data, the database, and the app.
|
||||
|
||||
### Working for yourself
|
||||
|
||||
When you use open source tools, you often end up improving them, sometimes whether you know it or not. You may not (or you may!) download the source and hack on code, but you probably fall into a way of using the tool that works best for you. You optimize your interaction with the tool. The unique way you interact with your tooling creates a kind of meta-tool: you haven't changed the software, but you've adapted it and yourself in ways that the project author and a dozen other users never imagined. Everyone does this with whatever software they rely upon, and it's why sitting at someone else's computer to use a familiar software (or even just looking over someone's shoulder) often feels foreign, like you're using a different version of the application than you're used to.
|
||||
|
||||
When you do this with proprietary software, you're either contributing to someone else's marketplace for free, or you're adjusting your own behavior based on forces outside your own control. When you optimize an open source tool, both the software and the interaction belong to you.
|
||||
|
||||
### The right to not upgrade
|
||||
|
||||
Tools change. It's the way of things.
|
||||
|
||||
Change can be frustrating, but it can be crippling when a service changes so severely that it breaks your workflow. A proprietary service has and maintains every right to change its product, and you explicitly accept this by using the product. If your favorite accounting software or scheduling web app changes its interface or its output options, you usually have no recourse but to adapt or stop using the service. Proprietary services reserve the right to remove features, arbitrarily and without warning, and it's not uncommon for companies to start out with an open API and strong compatibility with open source, only to drop these conveniences once its customer base has reached critical mass.
|
||||
|
||||
Open source changes, too. Changes in open source can be frustrating, too, and it can even drive users to alternative open source solutions. The difference is that when open source changes, you still own the unchanged code base. More importantly, lots of other people do too, and if there's enough desire for it, the project can be forked. There are several famous examples of this, but admittedly there are just as many examples where the demand was _not_ great enough, and users essentially had to adapt.
|
||||
|
||||
Even so, users are never truly forced to do anything in open source. If you want to hack together an old version of your mission-critical service on an old distro running ancient libraries in a virtual machine, you can do that because you own the code. When a proprietary service changes, you have no choice but to follow.
|
||||
|
||||
With open source, you can choose to forge your own path when necessary or follow the developers when convenient.
|
||||
|
||||
### Open for collaboration
|
||||
|
||||
Proprietary services can affect others in ways you may not realize. Closed source tools are accidentally insidious. If you use a proprietary product to manage your schedule or your recipes or your library, or you use a proprietary font in your graphic design or website, then the moment you need to coordinate with someone else, you are essentially forcing them to sign up for the same proprietary service because proprietary services usually require accounts. Of course, the same is sometimes true for an open source solution, but it's not common for open source products to collect and sell user data the way proprietary vendors do, so the stakes aren't quite the same.
|
||||
|
||||
### Independence
|
||||
|
||||
Ultimately, the open source advantage is one of independence for you and for those you want to collaborate with. Not everyone uses open source, and even if everyone did not everyone would use the exact same tool or the same assets, so there will always be some negotiation when sharing data. However, by keeping your data and projects open, you enable everyone (your future self included) to contribute.
|
||||
|
||||
What steps do you take to ensure your work is open and accessible? Tell us in the comments!
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/2/open-source-vs-proprietary
|
||||
|
||||
作者：[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/EDUCATION_doodles.png?itok=W_0DOMM4 (Doodles of the word open)
|
||||
[2]: https://opensource.com/article/20/1/open-source-productivity-tools
|
||||
[3]: https://opensource.com/tags/tools
|
||||
[4]: https://opensource.com/tags/analytics-and-metrics
|
||||
@ -0,0 +1,72 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Open source vs. proprietary: What's the difference?)
|
||||
[#]: via: (https://opensource.com/article/20/2/open-source-vs-proprietary)
|
||||
[#]: author: (Seth Kenlon https://opensource.com/users/seth)
|
||||
|
||||
Open source vs. proprietary: What's the difference?
|
||||
======
|
||||
Need four good reasons to tell your friends to use open source? Here's
|
||||
how to make your case.
|
||||
![Doodles of the word open][1]
|
||||
|
||||
There's a lot to be learned from open source projects. After all, managing hundreds of disparate, asynchronous commits and bugs doesn't happen by accident. Someone or something has to coordinate releases, and keep all the code and project roadmaps organized. It's a lot like life. You have lots of tasks demanding your attention, and you have to tend to each in turn. To ensure everything gets done before its deadline, you try to stay organized and focused.
|
||||
|
||||
Fortunately, there are [applications out there][2] designed to help with that sort of thing, and many apply just as well to real life as they do to software.
|
||||
|
||||
Here are some reasons for choosing [open tools][3] when improving personal or project-based organization.
|
||||
|
||||
### Data ownership
|
||||
|
||||
It's rarely profitable for proprietary tools to provide you with [data][4] dumps. Some products, usually after a long battle with their users (and sometimes a lawsuit), provide ways to extract your data from them. But the real issue isn't whether a company lets you extract data; it's the fact that the capability to get to your data isn't guaranteed in the first place. It's your data, and when it's literally what you do each day, it is, in a way, your life. Nobody should have primary access to that but you, so why should you have to petition a company for a copy?
|
||||
|
||||
Using an open source tool ensures you have priority access to your own activities. When you need a copy of something, you already have it. When you need to export it from one application to another, you have complete control of how the data is exchanged. If you need to export your schedule from a calendar into your kanban board, you can manipulate and process the data to fit. You don't have to wait for functionality to be added to the app, because you own the data, the database, and the app.
|
||||
|
||||
### Working for yourself
|
||||
|
||||
When you use open source tools, you often end up improving them, sometimes whether you know it or not. You may not (or you may!) download the source and hack on code, but you probably fall into a way of using the tool that works best for you. You optimize your interaction with the tool. The unique way you interact with your tooling creates a kind of meta-tool: you haven't changed the software, but you've adapted it and yourself in ways that the project author and a dozen other users never imagined. Everyone does this with whatever software they rely upon, and it's why sitting at someone else's computer to use a familiar software (or even just looking over someone's shoulder) often feels foreign, like you're using a different version of the application than you're used to.
|
||||
|
||||
When you do this with proprietary software, you're either contributing to someone else's marketplace for free, or you're adjusting your own behavior based on forces outside your own control. When you optimize an open source tool, both the software and the interaction belong to you.
|
||||
|
||||
### The right to not upgrade
|
||||
|
||||
Tools change. It's the way of things.
|
||||
|
||||
Change can be frustrating, but it can be crippling when a service changes so severely that it breaks your workflow. A proprietary service has and maintains every right to change its product, and you explicitly accept this by using the product. If your favorite accounting software or scheduling web app changes its interface or its output options, you usually have no recourse but to adapt or stop using the service. Proprietary services reserve the right to remove features, arbitrarily and without warning, and it's not uncommon for companies to start out with an open API and strong compatibility with open source, only to drop these conveniences once its customer base has reached critical mass.
|
||||
|
||||
Open source changes, too. Changes in open source can be frustrating, too, and it can even drive users to alternative open source solutions. The difference is that when open source changes, you still own the unchanged code base. More importantly, lots of other people do too, and if there's enough desire for it, the project can be forked. There are several famous examples of this, but admittedly there are just as many examples where the demand was _not_ great enough, and users essentially had to adapt.
|
||||
|
||||
Even so, users are never truly forced to do anything in open source. If you want to hack together an old version of your mission-critical service on an old distro running ancient libraries in a virtual machine, you can do that because you own the code. When a proprietary service changes, you have no choice but to follow.
|
||||
|
||||
With open source, you can choose to forge your own path when necessary or follow the developers when convenient.
|
||||
|
||||
### Open for collaboration
|
||||
|
||||
Proprietary services can affect others in ways you may not realize. Closed source tools are accidentally insidious. If you use a proprietary product to manage your schedule or your recipes or your library, or you use a proprietary font in your graphic design or website, then the moment you need to coordinate with someone else, you are essentially forcing them to sign up for the same proprietary service because proprietary services usually require accounts. Of course, the same is sometimes true for an open source solution, but it's not common for open source products to collect and sell user data the way proprietary vendors do, so the stakes aren't quite the same.
|
||||
|
||||
### Independence
|
||||
|
||||
Ultimately, the open source advantage is one of independence for you and for those you want to collaborate with. Not everyone uses open source, and even if everyone did not everyone would use the exact same tool or the same assets, so there will always be some negotiation when sharing data. However, by keeping your data and projects open, you enable everyone (your future self included) to contribute.
|
||||
|
||||
What steps do you take to ensure your work is open and accessible? Tell us in the comments!
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/2/open-source-vs-proprietary
|
||||
|
||||
作者：[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/EDUCATION_doodles.png?itok=W_0DOMM4 (Doodles of the word open)
|
||||
[2]: https://opensource.com/article/20/1/open-source-productivity-tools
|
||||
[3]: https://opensource.com/tags/tools
|
||||
[4]: https://opensource.com/tags/analytics-and-metrics
|
||||
@ -0,0 +1,118 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (chai-yuan)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Connect Fedora to your Android phone with GSConnect)
|
||||
[#]: via: (https://fedoramagazine.org/connect-fedora-to-your-android-phone-with-gsconnect/)
|
||||
[#]: author: (Lokesh Krishna https://fedoramagazine.org/author/lowkeyskywalker/)
|
||||
|
||||
使用GSConnect将Android手机连接到Fedora系统
|
||||
======
|
||||
|
||||
![][1]
|
||||
|
||||
苹果和微软公司都提供了集成好的与移动设备交互的应用。Fedora提供了类似的工具——**GSConnect**。它可以让你将你的安卓手机和你的Fedora桌面配对并使用。读下去，来了解更多关于它是什么以及它是如何工作的信息。
|
||||
|
||||
### GSConnect是什么?
|
||||
|
||||
GSConnect是基于KDE Connect项目而为GNOME桌面定制的程序。KDE Connect使你的设备相互之间能够进行通信。但是，在Fedora的默认GNOME桌面上安装它需要安装大量的KDE依赖。
|
||||
|
||||
GSConnect基于KDE Connect实现，作为GNOME shell的拓展应用。一旦安装，GSConnect允许您执行以下操作：
|
||||
|
||||
* 在电脑上接收电话通知并回复信息
|
||||
* 用手机操纵你的桌面
|
||||
* 在不同设备之间分享文件与链接
|
||||
* 在电脑上查看手机电量
|
||||
* 让手机响铃以便你能找到它
|
||||
|
||||
|
||||
|
||||
### 设置GSConnect扩展
|
||||
|
||||
设置GSConnect需要安装两款软件：电脑上的GSConnect扩展和Android设备上的KDE Connect应用。
|
||||
|
||||
首先，从GNOME Shell扩展网站[GSConnect][2]安装GSConnect扩展。（Fedora Magazine有一篇关于[如何安装GNOMEShell扩展名][3]的文章，可以帮助你完成这一步。）
|
||||
|
||||
KDE Connect应用程序可以在Google的[Play Store][4]上找到。它也可以在FOSS Android应用程序库[F-Droid][5]上找到。
|
||||
|
||||
一旦安装了这两个组件，就可以配对两个设备。安装扩展后再系统菜单中显示“移动设备(Mobile Devices)”。单击它会出现一个下拉菜单，你可以从中访问“移动设置(Mobile Settings)”。
|
||||
|
||||
![][6]
|
||||
|
||||
在这里，你可以用GSConnect查看并管理配对的设备。进入此界面后，需要在Android设备上启动应用程序。
|
||||
|
||||
配对的初始化可以再任意一台设备上进行，在这里我们从Android设备连接到电脑。点击应用程序上的刷新(refresh)，只要两个设备都在同一个无线网络环境中，你的Android设备便可以搜索到你的电脑。现在可以向桌面发送配对请求，并在桌面上接受配对请求以完成配对。
|
||||
|
||||
![][7]
|
||||
|
||||
### 使用 GSConnect
|
||||
|
||||
配对后，你将需要授予对Android设备的权限，才能使用GSConnect上提供的许多功能。单击设备列表中的配对设备，便可以查看所有可用功能，并根据你的偏好和需要启用或禁用它们。
|
||||
|
||||
![][8]
|
||||
|
||||
请记住，你还需要在Android应用程序中授予相应的权限才能使用这些功能。启用权限后，你现在可以访问桌面上的移动联系人，获得消息通知并回复消息，甚至同步桌面和Android设备剪贴板。
|
||||
|
||||
### 集成在文件系统与浏览器上
|
||||
|
||||
GSConnect允许你直接从桌面文件资源管理器向Android设备发送文件。
|
||||
|
||||
在Fedora的默认GNOME桌面上，你需要安装_nautilus-python_依赖包，以便在菜单中显示配对的设备。安装它只需要再终端中输入：
|
||||
|
||||
```
|
||||
$ sudo dnf install nautilus-python
|
||||
```
|
||||
|
||||
完成后，将在“文件(Files)”的菜单中显示“发送到移动设备(Send to Mobile Device)”选项。
|
||||
|
||||
![][9]
|
||||
|
||||
同样，为你的浏览器安装相应的WebExtension，无论是[Firefox][10]还是[Chrome][11]浏览器，都可以将链接发送到你的Android设备。你可以选择直接在浏览器中发送要启动的链接，或将其作为短信息发送。
|
||||
|
||||
### 运行命令
|
||||
|
||||
GSConnect允许你定义命令，然后可以从远程设备在电脑上运行这些命令。这使得你可以远程截屏，或者从你的Android设备锁定和解锁你的桌面。
|
||||
|
||||
![][12]
|
||||
|
||||
要使用此功能，可以使用标准shell命令和GSConnect公开的CLI。项目的GitHub存储库中提供了有关此操作的文档： _CLI Scripting_。
|
||||
|
||||
[KDE UserBase Wiki][13]有一个命令示例列表。这些例子包括控制桌面的亮度和音量，锁定鼠标和键盘，甚至更改桌面主题。其中一些命令是针对KDE Plasma设计的，需要进行修改才能在GNOME桌面上运行。
|
||||
|
||||
### 探索并享受乐趣
|
||||
|
||||
GSConnect使我们能够享受到极大的便利和舒适。深入研究首选项，查看你可以做的所有事情，灵活的使用这些命令功能。并在下面的评论中自由分享你解锁的新方式。
|
||||
|
||||
* * *
|
||||
|
||||
_Photo by [Pathum Danthanarayana][14] on [Unsplash][15]._
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://fedoramagazine.org/connect-fedora-to-your-android-phone-with-gsconnect/
|
||||
|
||||
作者：[Lokesh Krishna][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[chai-yuan](https://github.com/chai-yuan)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://fedoramagazine.org/author/lowkeyskywalker/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://fedoramagazine.org/wp-content/uploads/2019/12/gsconnect-816x345.jpg
|
||||
[2]: https://extensions.gnome.org/extension/1319/gsconnect/
|
||||
[3]: https://fedoramagazine.org/install-gnome-shell-extension/
|
||||
[4]: https://play.google.com/store/apps/details?id=org.kde.kdeconnect_tp
|
||||
[5]: https://f-droid.org/en/packages/org.kde.kdeconnect_tp/
|
||||
[6]: https://fedoramagazine.org/wp-content/uploads/2020/01/within-the-menu-1024x576.png
|
||||
[7]: https://fedoramagazine.org/wp-content/uploads/2020/01/pair-request-1024x576.png
|
||||
[8]: https://fedoramagazine.org/wp-content/uploads/2020/01/permissions-1024x576.png
|
||||
[9]: https://fedoramagazine.org/wp-content/uploads/2020/01/send-to-mobile-2-1024x576.png
|
||||
[10]: https://addons.mozilla.org/en-US/firefox/addon/gsconnect/
|
||||
[11]: https://chrome.google.com/webstore/detail/gsconnect/jfnifeihccihocjbfcfhicmmgpjicaec
|
||||
[12]: https://fedoramagazine.org/wp-content/uploads/2020/01/commands-1024x576.png
|
||||
[13]: https://userbase.kde.org/KDE_Connect/Tutorials/Useful_commands
|
||||
[14]: https://unsplash.com/@pathum_danthanarayana?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText
|
||||
[15]: https://unsplash.com/s/photos/android?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText
|
||||
Loading…
Reference in New Issue
Block a user