mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-02-25 00:50:15 +08:00
Merge remote-tracking branch 'LCTT/master'
This commit is contained in:
Xingyu Wang
commit
f13ed888ce
@ -0,0 +1,66 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (NFC vs. Bluetooth LE: When to use which)
|
||||
[#]: via: (https://www.networkworld.com/article/3574932/nfc-vs-bluetooth-le-when-to-use-which.html)
|
||||
[#]: author: (Jon Gold https://www.networkworld.com/author/Jon-Gold/)
|
||||
|
||||
NFC vs. Bluetooth LE: When to use which
|
||||
======
|
||||
Near-field communications and Bluetooth LE are low-power wireless technologies suited for different uses in enterprises.
|
||||
Metamorworks / Getty Images
|
||||
|
||||
Among many options for low-power, relatively short-ranged connectivity, two technologies stand out – near-field communication and Bluetooth low energy. Both have relatively low deployment costs and are simple to use.
|
||||
|
||||
NFC is best known for being the technology behind many modern smart cards. NFC chips need to be very close – within a few centimeters – to a reader for a connection to be made, but that’s an upside in its primary enterprise use case, which is security and access control.
|
||||
|
||||
[[Get regularly scheduled insights by signing up for Network World newsletters.]][1]
|
||||
|
||||
Bluetooth LE is a low-power derivative of the main Bluetooth standard, offsetting lower potential throughput with substantially reduced energy consumption and the consequent ability to fit into a wider range of potential use cases.
|
||||
|
||||
Next, we’ll delve into more in-depth descriptions of each technology and their primary use cases.
|
||||
|
||||
### NFC features
|
||||
|
||||
NFC operates at near-contact ranges – devices must be within several centimeters of each other in order to make contact. A readable passive NFC “tag” requires no independent power source at all, drawing energy from the initiator’s signal, which operates at around 13.5MHz and requires between 100 and 700 µA of power when actively reading a tag.
|
||||
|
||||
“The short range is actually an advantage,” said Gartner research senior director and analyst Bill Ray. “The big thing about NFC is that it’s not just the radio, there’s a massive security protocol built-in.” That is, a potential bad actor would have to be very close – within a few meters, using specialized equipment – to even be able to detect an NFC connection taking place. NFC implementations can also layer on SSL technology for additional safety.
|
||||
|
||||
That’s not a surprise, given NFC’s origins as a contactless payment technology. Its roots in that area create an appeal for retailers, which could use NFC to let customers get additional information about items before they buy, get coupons or ask for assistance from a clerk simply by touching their phones to an NFC hotspot.
|
||||
|
||||
While the short range involved has limited the number of use cases that make sense for NFC technology, it’s not solely about opening doors and buying lattes. NFC can be used to bootstrap connections for quick and easy pairing between devices, so a user could simply tap their phone on a properly equipped projector in a conference room to create an NFC connection, validate that the smartphone is an approved device to connect to, and give a presentation. The presentation or video data itself wouldn’t be transferred via NFC, but the NFC handshake acts as a validation for a different wireless protocol, eliminating the need to sign into, for example, a Wi-Fi network, or any other higher-bandwidth network that could stream that data.
|
||||
|
||||
### Bluetooth LE characteristics
|
||||
|
||||
Bluetooth LE, by contrast, operates over substantially longer distances – anywhere up to several dozen meters – and has about twice the maximum bandwidth of an NFC connection at 1 Mbit/second. It’s an outgrowth of the well-known Bluetooth technology, optimized for machine-to-machine connectivity, thanks to its lower power usage than the main-line standard. It uses less than 15 mA of power at either end of a connection, and has a practical range of about 10 meters, securing connections with AES encryption.
|
||||
|
||||
Yet it’s far from a drop-in replacement for NFC, according to Forrester principal analyst Andre Kindness.
|
||||
|
||||
“From an information transfer perspective [NFC is] a lot quicker than BLE,” he said. BLE usually takes an appreciable fraction of a second or longer to identify and secure a connection, while that process is more or less instantaneous with NFC.
|
||||
|
||||
Bluetooth LE, however, is considerably more versatile than NFC, thanks to its greater range, according to IDC senior research analyst Patrick Filkins.
|
||||
|
||||
“I think Bluetooth [LE] is a little better suited for enterprise,” he said. Use cases like asset tracking, indoor navigation, and targeted advertisements are just the tip of the iceberg.
|
||||
|
||||
For enterprises, then, the upshot is fairly straightforward – NFC use cases are mostly separate from those for which a company would use Bluetooth, but, for the rare overlap where a choice can be made, the relative advantages and disadvantages are clear. NFC is very short-ranged, cheap, connects instantly and has a lower data transfer rate. Bluetooth LE works over much longer distances and at higher speeds, costs somewhat more and takes a moment to “handshake” its connections.
|
||||
|
||||
Join the Network World communities on [Facebook][2] and [LinkedIn][3] to comment on topics that are top of mind.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.networkworld.com/article/3574932/nfc-vs-bluetooth-le-when-to-use-which.html
|
||||
|
||||
作者：[Jon Gold][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/Jon-Gold/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://www.networkworld.com/newsletters/signup.html
|
||||
[2]: https://www.facebook.com/NetworkWorld/
|
||||
[3]: https://www.linkedin.com/company/network-world
|
||||
@ -1,130 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (LazyWolfLin)
|
||||
[#]: 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
|
||||
@ -1,138 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Using the Linux stat command to create flexible file listings)
|
||||
[#]: via: (https://www.networkworld.com/article/3573802/using-the-linux-stat-command-to-create-flexible-file-listings.html)
|
||||
[#]: author: (Sandra Henry-Stocker https://www.networkworld.com/author/Sandra-Henry_Stocker/)
|
||||
|
||||
Using the Linux stat command to create flexible file listings
|
||||
======
|
||||
|
||||
D3Damon / Getty Images
|
||||
|
||||
The **stat** command supplies a lot of detailed information on files.
|
||||
|
||||
It provides not just the date/time of the most recent file changes, but also shows when files were most recently accessed and permissions changed. It tells you the file size in both bytes and blocks. It displays the inode being used by the file along with the file type. It includes the file owner and the associated user group both by name and UID/GID. It displays file permissions in both the “rwx” (referred to as the “human-readable” format) and numerically. On some systems, it might even include the date and time that a file was created (called its “birth”).
|
||||
|
||||
[[Get regularly scheduled insights by signing up for Network World newsletters.]][1]
|
||||
|
||||
In addition to providing all this information, the **stat** command can also be used to create file listings. These listings are extremely flexible in that you can choose to include any or all of the information described above.
|
||||
|
||||
To generate a custom listing, you just need to use the **stat** command’s **-c** (or --**format**) option and specify the fields you want included. For example, to create a listing that shows file permissions in both of the available formats, use this command:
|
||||
|
||||
```
|
||||
$ stat -c '%n %a %A' my*
|
||||
my.banner 664 -rw-rw-r--
|
||||
mydir 775 drwxrwxr-x
|
||||
myfile 664 -rw-rw-r--
|
||||
myjunk 777 lrwxrwxrwx
|
||||
mykey 664 -rw-rw-r--
|
||||
mylog 664 -rw-rw-r--
|
||||
myscript 755 -rwxr-xr-x
|
||||
mytext 664 -rw-rw-r--
|
||||
mytext.bak 664 -rw-rw-r--
|
||||
mytwin 50 -rw-r-----
|
||||
mywords 664 -rw-rw-r--
|
||||
```
|
||||
|
||||
As you can see in the example above, **%n** represents the file name, **%a** the permissions in octal and **%A** the permissions in the **rwx** form. A complete list is shown below.
|
||||
|
||||
To create an alias for this command, type this or add this definition to your **.bashrc** file:
|
||||
|
||||
```
|
||||
$ alias ls_perms="stat -c '%n %a %A'"
|
||||
```
|
||||
|
||||
To create a listing that is very close to the long listing provided by **ls -l**, do this:
|
||||
|
||||
```
|
||||
$ stat -c '%A %h %U %G %s %y %n' my*
|
||||
-rw-rw-r-- 1 shs shs 255 2020-04-01 16:20:00.899374215 -0400 my.banner
|
||||
drwxrwxr-x 2 shs shs 4096 2020-09-07 12:50:20.224470760 -0400 mydir
|
||||
-rw-rw-r-- 1 shs shs 6 2020-05-16 11:12:00.460355387 -0400 myfile
|
||||
lrwxrwxrwx 1 shs shs 11 2020-05-28 18:49:21.666792608 -0400 myjunk
|
||||
-rw-rw-r-- 1 shs shs 655 2020-01-14 15:56:08.540540488 -0500 mykey
|
||||
-rw-rw-r-- 1 shs shs 8 2020-03-04 17:13:21.406874246 -0500 mylog
|
||||
-rwxr-xr-x 1 shs shs 201 2020-09-07 12:50:41.316745867 -0400 myscript
|
||||
-rw-rw-r-- 1 shs shs 40 2019-06-06 08:54:09.538663323 -0400 mytext
|
||||
-rw-rw-r-- 1 shs shs 24 2019-06-06 08:48:59.652712578 -0400 mytext.bak
|
||||
-rw-r----- 2 shs shs 228 2019-04-12 19:37:12.790284604 -0400 mytwin
|
||||
-rw-rw-r-- 1 shs shs 1983 2020-08-10 14:39:57.164842370 -0400 mywords
|
||||
```
|
||||
|
||||
The differences include: 1) no attempt to line up the fields in discernible columns, 2) the date in a _**yyyy-mm-dd**_ format, 3) considerably more precision in the time field and 4) the addition of the time zone (-0400 is EDT).
|
||||
|
||||
If you want to see files listed according to the date they were most last accessed (e.g., displayed with the **cat** command), use a command like this:
|
||||
|
||||
```
|
||||
$ stat -c '%n %x' my* | sort -k2
|
||||
mytwin 2019-04-22 11:25:20.656828964 -0400
|
||||
mykey 2020-08-20 16:10:34.479324431 -0400
|
||||
mylog 2020-08-20 16:10:34.527325066 -0400
|
||||
myfile 2020-08-20 16:10:57.815632794 -0400
|
||||
mytext.bak 2020-08-20 16:10:57.935634379 -0400
|
||||
mytext 2020-08-20 16:15:42.323391985 -0400
|
||||
mywords 2020-08-20 16:15:43.479407259 -0400
|
||||
myjunk 2020-09-07 10:04:26.543980300 -0400
|
||||
myscript 2020-09-07 12:50:41.312745815 -0400
|
||||
my.banner 2020-09-07 13:22:38.105826116 -0400
|
||||
mydir 2020-09-07 14:53:10.171867194 -0400
|
||||
```
|
||||
|
||||
The field options available for listing file details with **stat** include:
|
||||
|
||||
* %a – access rights in octal (note '#' and '0' printf flags)
|
||||
* %A – access rights in human readable form
|
||||
* %b – number of blocks allocated (see %B)
|
||||
* %B – the size in bytes of each block reported by %b
|
||||
* %C – SELinux security context string
|
||||
* %d – device number in decimal
|
||||
* %D – device number in hex
|
||||
* %f – raw mode in hex
|
||||
* %F – file type
|
||||
* %g – group ID of owner
|
||||
* %G – group name of owner
|
||||
* %h – number of hard links
|
||||
* %i – inode number
|
||||
* %m – mount point
|
||||
* %n – file name
|
||||
* %N – quoted file name with dereference if symbolic link
|
||||
* %o – optimal I/O transfer size hint
|
||||
* %s – total size, in bytes
|
||||
* %t – major device type in hex, for character/block device special files
|
||||
* %T – minor device type in hex, for character/block device special files
|
||||
* %u – user ID of owner
|
||||
* %U – user name of owner
|
||||
* %w – time of file birth, human-readable; - if unknown
|
||||
* %W – time of file birth, seconds since Epoch; 0 if unknown
|
||||
* %x – time of last access, human-readable
|
||||
* %X – time of last access, seconds since Epoch
|
||||
* %y – time of last data modification, human-readable
|
||||
* %Y – time of last data modification, seconds since Epoch
|
||||
* %z – time of last status change, human-readable
|
||||
* %Z – time of last status change, seconds since Epoch
|
||||
|
||||
|
||||
|
||||
These field choices are all listed in the man page and you can choose any, though creating a few aliases with your preferred details should save you a lot of trouble. Some options, like the SELinux security context string, will not be available unless that option is in use on the system. File birth is only available if your system retains that information.
|
||||
|
||||
Join the Network World communities on [Facebook][2] and [LinkedIn][3] to comment on topics that are top of mind.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.networkworld.com/article/3573802/using-the-linux-stat-command-to-create-flexible-file-listings.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://www.networkworld.com/newsletters/signup.html
|
||||
[2]: https://www.facebook.com/NetworkWorld/
|
||||
[3]: https://www.linkedin.com/company/network-world
|
||||
@ -1,5 +1,5 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
|
||||
@ -0,0 +1,125 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (How Nextcloud simplified the signup process for decentralization)
|
||||
[#]: via: (https://opensource.com/article/20/9/decentralization-signup)
|
||||
[#]: author: (Jan C. Borchardt https://opensource.com/users/jancborchardt)
|
||||
|
||||
How Nextcloud simplified the signup process for decentralization
|
||||
======
|
||||
Nextcloud is open source software and we don’t provide a hosted service,
|
||||
yet we managed to radically simplify the signup experience.
|
||||
![clouds in the sky with blue pattern][1]
|
||||
|
||||
We always had a nice list of dozens of Nextcloud providers, yet the most common question I heard, even from technically apt friends of mine, was:
|
||||
|
||||
> "Hi, Jan, umm…so, which Nextcloud provider do you recommend?"
|
||||
|
||||
Which is, of course, understandable. If you have a long list of providers, how do you choose? Hosted nearby? Cute name? Biggest logo?
|
||||
|
||||
Every decentralized open source solution using servers struggles with this:
|
||||
|
||||
* Mastodon has [joinmastodon.org][2] for choosing a community, but clearly a main instance with mastodon.social.
|
||||
* Diaspora has [joindiaspora.com][3], which is also the main instance.
|
||||
* Matrix has [matrix.to][4] and an app (for multiple platforms) at [Element.io][5].
|
||||
* WordPress has [wordpress.com][6]—and I'm not sure any provider comes close to its popularity.
|
||||
* PeerTube has a bunch of instances, all with different technical details.
|
||||
* Pixelfed has an early version of an instance picker at [beta.joinpixelfed.org][7], as well as a large instance at [pixelfed.social][8]
|
||||
* … lots more examples of decentralized open source apps, which list how you can access it via the terminal, set up the Rust implementation, or make it run on your networked printer.
|
||||
|
||||
|
||||
|
||||
This leads to problems:
|
||||
|
||||
* 🔮 People don't know which one to pick, have FOMO (Fear Of Missing Out), and then don't pick at all. It's the paradox of choice!
|
||||
* 🕸 The network is not really decentralized because the majority of people are on a handful of servers, or mainly just a single one.
|
||||
|
||||
|
||||
|
||||
Nextcloud does not have any of these problems.
|
||||
|
||||
### Our solution: Simple Signup
|
||||
|
||||
How it works:
|
||||
|
||||
When you download the mobile or desktop app, the first thing you see is a choice for "Log in" or "Sign up with a provider." This is what any proprietary app does:
|
||||
|
||||
![Android client][9]
|
||||
|
||||
Choosing "Sign up" opens [the Simple Signup page][10] in the app.
|
||||
|
||||
![Web client][11]
|
||||
|
||||
You put in your email address and click "sign up."
|
||||
|
||||
Enter a password, and you're done! 🎉
|
||||
|
||||
> "Wait a second; how is this so simple?"
|
||||
|
||||
I know, right? ✨
|
||||
|
||||
In fact, it's even simpler than lots of centralized apps where you need to put in your full name and phone number and then click on pictures of fire hydrants for Google.
|
||||
|
||||
It basically boils down to this:
|
||||
|
||||
### We choose for you
|
||||
|
||||
Instead of being faced with a list of providers where you could not possibly judge what works for you, we only show you one option. It's as if I'm your friend, and I answer that question about which provider I recommend.
|
||||
|
||||
Neat! 😊
|
||||
|
||||
Just to clarify: You do have the ability to change the provider, but the default should suit you fine. For now, it's simply the provider geographically closest to you.
|
||||
|
||||
On top of that, we have some requirements for the providers which are listed through Simple Signup to ensure a good user experience no matter which one you get:
|
||||
|
||||
* 🎁 2 GB of free storage minimum, and not only for a trial period.
|
||||
* 🍱 A core set of apps: Files, Calendar, Contacts, Mail, Talk, Tasks, Notes. Some providers offer even more.
|
||||
* 🛡 The latest version, so you are always up to date with the latest features, fixes, and security updates.
|
||||
|
||||
|
||||
|
||||
Beyond that, we came up with a privacy respecting process. When you click "sign up," your email is not sent to us but directly to the provider you chose, which seamlessly transitions you to their setup step where you choose a password. This means no data leaks to us at Nextcloud—we don't even know which provider you picked!
|
||||
|
||||
So, while we offer this service, and while it is super easy to use, we only do the absolute minimum in terms of data handling to connect you with your ideal provider.
|
||||
|
||||
### Decentralized projects need simple signup
|
||||
|
||||
A lot of open source software projects could benefit from an onboarding experience like Simple Signup. We [wrote about it when we initially released it][12], and we hope this post clarifies the design decisions that make it successful so it can be adopted by more projects.
|
||||
|
||||
Decentralization is empowering, but only truly revolutionary when people can simply sign up even if they don't know what a server is.
|
||||
|
||||
Of course, it's not perfect just yet, either. For example, if you already have an account on a Nextcloud instance, the login process in any of the apps asks you to put in a server address, and a lot of people have no idea what that even is. In lots of email apps, for example, there is a list of the most popular providers at this step, with a "custom server" entry on the bottom. This could be a possibility as well, but again brings the risk of centralizing the system too much or leaving people confused as to what to pick.
|
||||
|
||||
So, we constantly try to improve this for any of the Nextcloud desktop and mobile apps, like Nextcloud Talk or all of the great community-developed apps. On Android, we have tight integration with DAVx5 (Calendar and Contact sync on Android), and, for other Android apps, there is a [single sign-on library][13]. On iOS, it is, unfortunately, not so easy, since apps have to be from the same developer to share credentials.
|
||||
|
||||
If you want to collaborate on solving interesting challenges like these, [come join our Nextcloud design team][14]!
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/9/decentralization-signup
|
||||
|
||||
作者：[Jan C. Borchardt][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/jancborchardt
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/rh_003601_05_mech_osyearbook2016_cloud_cc.png?itok=XSV7yR9e (clouds in the sky with blue pattern)
|
||||
[2]: https://joinmastodon.org/
|
||||
[3]: https://joindiaspora.com
|
||||
[4]: https://matrix.to
|
||||
[5]: http://Element.io
|
||||
[6]: https://wordpress.com
|
||||
[7]: http://beta.joinpixelfed.org
|
||||
[8]: http://pixelfed.social
|
||||
[9]: https://opensource.com/sites/default/files/nextcloud-android-small.png (Android client)
|
||||
[10]: https://nextcloud.com/signup
|
||||
[11]: https://opensource.com/sites/default/files/nextcloud-web-small.png (Web client)
|
||||
[12]: https://nextcloud.com/blog/introducing-simple-signup-you-can-now-get-started-with-nextcloud-in-2-steps/
|
||||
[13]: https://github.com/nextcloud/Android-SingleSignOn
|
||||
[14]: https://nextcloud.com/design
|
||||
@ -0,0 +1,93 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Incremental backups with Btrfs snapshots)
|
||||
[#]: via: (https://fedoramagazine.org/btrfs-snapshots-backup-incremental/)
|
||||
[#]: author: (Alessio https://fedoramagazine.org/author/alciregi/)
|
||||
|
||||
Incremental backups with Btrfs snapshots
|
||||
======
|
||||
|
||||
![][1]
|
||||
|
||||
Snapshots are an interesting feature of Btrfs. A snapshot is a copy of a subvolume. Taking a snapshot is immediate. However, taking a snapshot is not like performing a _rsync_ or a _cp_, and a snapshot doesn’t occupy space as soon as it is created.
|
||||
|
||||
Editors note: From the [BTRFS Wiki][2] – A snapshot is simply a subvolume that shares its data (and metadata) with some other subvolume, using Btrfs’s COW capabilities.
|
||||
|
||||
Occupied space will increase alongside the data changes in the original subvolume or in the snapshot itself, if it is writeable. Added/modified files, and deleted files in the subvolume still reside in the snapshots. This is a convenient way to perform backups.
|
||||
|
||||
### Using snapshots for backups
|
||||
|
||||
A snapshot resides on the same disk where the subvolume is located. You can browse it like a regular directory and recover a copy of a file as it was when the snapshot was performed. By the way, a snapshot on the same disk of the snapshotted subvolume is not an ideal backup strategy: if the hard disk broke, snapshots will be lost as well. An interesting feature of snapshots is the ability to send them to another location. The snapshot can be sent to an external hard drive or to a remote system via SSH (the destination filesystems need to be formatted as Btrfs as well). To do this, the commands _btrfs send_ and _btrfs receive_ are used.
|
||||
|
||||
### Taking a snapshot
|
||||
|
||||
In order to use the _send_ and the _receive_ commands, it is important to create the snapshot as read-only, and snapshots are writeable by default.
|
||||
|
||||
The following command will take a snapshot of the _/home_ subvolume. Note the _-r_ flag for readonly.
|
||||
|
||||
sudo btrfs subvolume snapshot -r /home /.snapshots/home-day1
|
||||
|
||||
Instead of day1, the snapshot name can be the current date, like _home-$(date +%Y%m%d)_. Snapshots look like regular subdirectories. You can place them wherever you like. The directory _/.snapshots_ could be a good choice to keep them neat and to avoid confusion.
|
||||
|
||||
Editors note: Snapshots will not take recursive snapshots of themselves. If you create a snapshot of a subvolume, every subvolume or snapshot that the subvolume contains is mapped to an empty directory of the same name inside the snapshot.
|
||||
|
||||
### Backup using btrfs send
|
||||
|
||||
In this example the destination Btrfs volume in the USB drive is mounted as _/run/media/user/mydisk/bk_ . The command to send the snapshot to the destination is:
|
||||
|
||||
sudo btrfs send /.snapshots/home-day1 | sudo btrfs receive /run/media/user/mydisk/bk
|
||||
|
||||
This is called initial bootstrapping, and it corresponds to a full backup. This task will take some time, depending on the size of the _/home_ directory. Obviously, subsequent incremental sends will take a shorter time.
|
||||
|
||||
### Incremental backup
|
||||
|
||||
Another useful feature of snapshots is the ability to perform the send task in an incremental way. Let’s take another snapshot.
|
||||
|
||||
sudo btrfs subvolume snapshot -r /home /.snapshots/home-day2
|
||||
|
||||
In order to perform the send task incrementally, you need to specify the previous snapshot as a base and this snapshot has to exist in the source and in the destination. Please note the _-p_ option.
|
||||
|
||||
sudo btrfs send -p /.snapshot/home-day1 /.snapshot/home-day2 | sudo btrfs receive /run/media/user/mydisk/bk
|
||||
|
||||
And again (the day after):
|
||||
|
||||
sudo btrfs subvolume snapshot -r /home /.snapshots/home-day3
|
||||
|
||||
sudo btrfs send -p /.snapshot/home-day2 /.snapshot/home-day3 | sudo btrfs receive /run/media/user/mydisk/bk
|
||||
|
||||
### Cleanup
|
||||
|
||||
Once the operation is complete, you can keep the snapshot. But if you perform these operations on a daily basis, you could end up with a lot of them. This could lead to confusion and potentially a lot of used space on your disks. So it is a good advice to delete some snapshots if you think you don’t need them anymore.
|
||||
|
||||
Keep in mind that in order to perform an incremental send you need at least the last snapshot. This snapshot must be present in the source and in the destination.
|
||||
|
||||
sudo btrfs subvolume delete /.snapshot/home-day1
|
||||
|
||||
sudo btrfs subvolume delete /.snapshot/home-day2
|
||||
|
||||
sudo btrfs subvolume delete /run/media/user/mydisk/bk/home-day1
|
||||
|
||||
sudo btrfs subvolume delete /run/media/user/mydisk/bk/home-day2
|
||||
|
||||
Note: the day 3 snapshot was preserved in the source and in the destination. In this way, tomorrow (day 4), you can perform a new incremental _btrfs send_.
|
||||
|
||||
As some final advice, if the USB drive has a bunch of space, you could consider maintaining multiple snapshots in the destination, while in the source disk you would keep only the last one.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://fedoramagazine.org/btrfs-snapshots-backup-incremental/
|
||||
|
||||
作者：[Alessio][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/alciregi/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://fedoramagazine.org/wp-content/uploads/2020/08/butterfs-816x346.png
|
||||
[2]: https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Snapshots
|
||||
@ -1,104 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Linux Jargon Buster: What is a Long Term Support (LTS) Release? What is Ubuntu LTS?)
|
||||
[#]: via: (https://itsfoss.com/long-term-support-lts/)
|
||||
[#]: author: (Ankush Das https://itsfoss.com/author/ankush/)
|
||||
|
||||
Linux Jargon Buster: What is a Long Term Support (LTS) Release? What is Ubuntu LTS?
|
||||
======
|
||||
|
||||
In Linux world, specially when it comes to [Ubuntu][1], you’ll come across the term LTS (long term support).
|
||||
|
||||
If you’re an experienced Linux user, you probably know the various aspects of a Linux distribution like an LTS release. But, new users or less tech-savvy users may not know about it.
|
||||
|
||||
In this chapter of Linux Jargon Buster, you’ll learn about what is an LTS release for Linux distributions.
|
||||
|
||||
### What is a Long Term Support (LTS) Release?
|
||||
|
||||
Long-Term Support (LTS) release is normally associated with an application or an operating system for which you will get security, maintenance and (sometimes) feature updates for a longer duration of time.
|
||||
|
||||
The LTS versions are considered to be the most stable releases which undergoes extensive testing and mostly includes years of improvements along the way.
|
||||
|
||||
It is important to note that an LTS version of software does not necessarily involve feature updates unless there’s a newer LTS release. But, you will get the necessary bug fixes and security fixes in the updates of a Long Term Support version.
|
||||
|
||||
An LTS release is recommended for production-ready consumers, businesses, and enterprises because you get years of software support and no system-breaking changes with software updates.
|
||||
|
||||
If you notice a non-LTS release for any software, it is usually the bleeding-edge version of it with new features and a short span of support (say 6-9 months) when compared to 3-5 years of support on an LTS release.
|
||||
|
||||
![][2]
|
||||
|
||||
To give you more clarity on LTS and non-LTS releases, let’s take a look at some pros and cons of choosing an LTS release.
|
||||
|
||||
#### Pros of LTS releases
|
||||
|
||||
* Software updates with security and maintenance fixes for a long time (5 year support for Ubuntu).
|
||||
* Extensive testing
|
||||
* No system-breaking changes with software updates
|
||||
* You get plenty of time to prep your system for the next LTS release
|
||||
|
||||
|
||||
|
||||
#### Cons of LTS releases
|
||||
|
||||
* Does not offer the latest and greatest features
|
||||
* You may miss out on the latest hardware support
|
||||
* You may also miss out on the latest application upgrades
|
||||
|
||||
|
||||
|
||||
Now, that you know what is an LTS release and its pros and cons it’s time to know about Ubuntu’s LTS release. Ubuntu is one of the most popular Linux distribution and one of the few distributions that has both LTS and non-LTS releases.
|
||||
|
||||
This is why I decided to dedicate an entire section to it.
|
||||
|
||||
### What is Ubuntu LTS?
|
||||
|
||||
Ubuntu has a non-LTS release every six months and a LTS release every 2 years since 2006 and that’s not going to change.
|
||||
|
||||
The latest LTS release is — [Ubuntu 20.04][3] and it will be supported until **April 2025**. In other words, Ubuntu 20.04 will receive software updates till then. The non-LTS releases are supported for nine months only.
|
||||
|
||||
You will always find an Ubuntu LTS release to be labelled as “**LTS**“. At least, when it comes to the [official Ubuntu website][4] to explore the latest Ubuntu releases.
|
||||
|
||||
To give you some clarity, if you notice Ubuntu 16.04 LTS, that means — it was **released back in April 2016 and is supported until 2021** (considering **5 years of software updates**).
|
||||
|
||||
Similarly, you can guess the update support for each Ubuntu LTS release by considering the next **5 years** of its release date for software support.
|
||||
|
||||
### Ubuntu LTS software updates: What does it include?
|
||||
|
||||
![][5]
|
||||
|
||||
Ubuntu LTS versions receive security and maintenance updates for the lifecycle of their release. Unless the release reaches the [End of Life][6], you will get all the necessary security and bug fixes.
|
||||
|
||||
You will not notice any functional upgrades in an LTS release. So, if you want to try the latest experimental technologies, you may want to upgrade your Ubuntu release to a non-LTS release.
|
||||
|
||||
I’d suggest you to refer our latest [Ubuntu upgrade guide][7] to know more about upgrading Ubuntu.
|
||||
|
||||
I would also recommend you to read our article on [which Ubuntu version to install][8] to clear your confusion on different Ubuntu flavours available like [Xubuntu][9] or [Kubuntu][10] and how are they different.
|
||||
|
||||
I hope you have a better understanding of the term LTS now specially when it comes to Ubuntu LTS. Stay tuned for more Linux jargon explainers in the future.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://itsfoss.com/long-term-support-lts/
|
||||
|
||||
作者：[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://ubuntu.com/
|
||||
[2]: https://i0.wp.com/itsfoss.com/wp-content/uploads/2020/09/display-server-linux.png?resize=800%2C450&ssl=1
|
||||
[3]: https://itsfoss.com/download-ubuntu-20-04/
|
||||
[4]: https://ubuntu.com
|
||||
[5]: https://i1.wp.com/itsfoss.com/wp-content/uploads/2020/09/ubuntu-lts-release.png?resize=800%2C397&ssl=1
|
||||
[6]: https://itsfoss.com/end-of-life-ubuntu/
|
||||
[7]: https://itsfoss.com/upgrade-ubuntu-version/
|
||||
[8]: https://itsfoss.com/which-ubuntu-install/
|
||||
[9]: https://xubuntu.org/
|
||||
[10]: https://kubuntu.org/
|
||||
@ -0,0 +1,69 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (The future of virtual conferences, service mesh, and more industry trends)
|
||||
[#]: via: (https://opensource.com/article/20/9/virtual-conferences-service-mesh-industry-trends)
|
||||
[#]: author: (Tim Hildred https://opensource.com/users/thildred)
|
||||
|
||||
The future of virtual conferences, service mesh, and more industry trends
|
||||
======
|
||||
A weekly look at open source community and industry trends.
|
||||
![Computer laptop in space][1]
|
||||
|
||||
As part of my role as a principal communication strategist at an enterprise software company with an open source development model, I publish a regular update about open source community, market, and industry trends. Here are some of my and their favorite articles from that update.
|
||||
|
||||
## [Enough with the Linux security FUD][2]
|
||||
|
||||
> Whether you're running Windows Server, Linux, NetBSD, whatever on your mission-critical systems, if you utterly fail at security, it doesn't matter how "secure" your operating system is. It's like leaving your car keys in an unlocked car, your system will be hacked, your car will be stolen.
|
||||
|
||||
**The impact**: I worry a bit about the organizations at the size that comes before "can afford fulltime expert IT" where you might find someone who likes computers taking on that responsibility by default. If that sounds like you or your organization, get that person some training!
|
||||
|
||||
## [A look back at our FIRST KubeCon + CloudNativeCon virtual conference][3]
|
||||
|
||||
> The first virtual KubeCon + CloudNativeCon just wrapped up and it was a huge success thanks to our amazing community of doers – builders, operators and advocates. We are so thrilled that the cloud native community came together with hope and positivity to make this a truly community-driven event we will remember for a long time. We may not have been able to meet in person this year but we are indomitable!
|
||||
|
||||
**The impact**: These virtual experiences keep getting better and adding to the state of the art; running them requires important muscles that have until this point gone underused. Whatever else happens as the pandemic progresses, I hope we get a sense of "if we really think hard about it, we can build powerful bonds within our communities without airfares and hotel rooms." It doesn't have to be the same as sharing a beer to be impactful.
|
||||
|
||||
## [Istio 1.7: Security improvements take centre stage as users continue to speculate about the service mesh’s future][4]
|
||||
|
||||
> Lately, Istio has been anything but boring, especially after originator Google came into some criticism for handing the project’s trademarks over to its recently founded [Open Usage Commons][5]. The step led to some turmoil, raising questions about how neutral OUC really was as well as basically smothering the hopes of those who had wished for Istio to become a CNCF project one day. [According to IBM][6], a founding member of the project, there had actually been an “agreement” to do so with Google, which only seems sensible, given that the Envoy proxy, which is central to Istio, has found a vendor-neutral home at the organisation.
|
||||
|
||||
**The impact**: My guess is that the project has enough adoption and functionality leading over competitive projects that it would take some truly dastardly governance to blow it.
|
||||
|
||||
## [Z is for Zowe–the open path to mainframe DevOps][7]
|
||||
|
||||
> This article describes the framework’s ability to onboard the mainframe to enterprise DevOps, so developers, systems programmers and others who work with the mainframe can now do so the same way their peers do with other IT platforms (i.e., cloud, mobile, distributed). These shared experiences close the gap between mainframers and others while preserving the core advantages of the platform. Common tools fuel a common language that benefits all, especially when deploying hybrid applications (e.g., web front-end with mainframe back-end).
|
||||
|
||||
**The impact**: The point about common tools fueling a common language is subtle but important. Tools for tools' sake won't get you very far; bringing more minds to bear on a problem will.
|
||||
|
||||
## [Tiering self-service by user competence][8]
|
||||
|
||||
> The degree to which each team can reasonably create its own configurations is related to the team’s competence with cloud solution architecture, cloud engineering, and cloud security. Not every person on the team may have a high level of competence; in fact, that will generally not be the case. However, the very least, for full self-service there needs to be at least one person with strong competencies in each of those areas, who has oversight responsibilities, acts an expert (provides assistance/mentorship within the team), and does any necessary code review.
|
||||
|
||||
**The impact**: We do it for driving cars and learning to ski; so why shouldn't we do it when it comes to letting people deploy sometimes critical applications?
|
||||
|
||||
_I hope you enjoyed this list and come back next week for more open source community, market, and industry trends._
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/9/virtual-conferences-service-mesh-industry-trends
|
||||
|
||||
作者：[Tim Hildred][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/thildred
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/computer_space_graphic_cosmic.png?itok=wu493YbB (Computer laptop in space)
|
||||
[2]: https://www.zdnet.com/article/enough-with-the-linux-security-fud/#ftag=RSSbaffb68
|
||||
[3]: https://www.cncf.io/blog/2020/08/26/a-look-back-at-our-first-kubecon-cloudnativecon-virtual-conference/
|
||||
[4]: https://devclass.com/2020/08/24/istio-service-mesh-1_7/
|
||||
[5]: https://istio.io/latest/blog/2020/open-usage/
|
||||
[6]: https://developer.ibm.com/blogs/istio-google-open-usage-commons/
|
||||
[7]: https://devops.com/z-is-for-zowe-the-open-path-to-mainframe-devops/
|
||||
[8]: https://cloudpundit.com/2020/08/10/tiering-self-service-by-user-competence/
|
||||
@ -0,0 +1,215 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Use Python to solve a charity's business problem)
|
||||
[#]: via: (https://opensource.com/article/20/9/solve-problem-python)
|
||||
[#]: author: (Chris Hermansen https://opensource.com/users/clhermansen)
|
||||
|
||||
Use Python to solve a charity's business problem
|
||||
======
|
||||
Comparing how different programming languages solve the same problem is
|
||||
fun and instructive. Next up, Python.
|
||||
![Python programming language logo with question marks][1]
|
||||
|
||||
In my [first article][2] in this series, I described a problem of dividing bulk supplies into hampers of similar value to distribute to struggling neighbors in your community. I also wrote about how I enjoy solving small problems like this with small programs in various languages and comparing how they do it.
|
||||
|
||||
In the first article, I solved this problem with the [Groovy][3] programming language. Groovy is like [Python][4] in many ways, but syntactically it's more like C and Java. Therefore, it should be interesting and instructive to create the same solution in Python.
|
||||
|
||||
### The Python solution
|
||||
|
||||
In Java, I declare utility classes to hold tuples of data (the new record feature is going to be great for that). In Groovy, I use the language support for maps, and I follow the same approach in Python.
|
||||
|
||||
Use a list of dictionaries to hold the bulk items picked up from the wholesaler:
|
||||
|
||||
|
||||
```
|
||||
packs = [
|
||||
{'item':'Rice','brand':'Best Family','units':10,'price':5650,'quantity':1},
|
||||
{'item':'Spaghetti','brand':'Best Family','units':1,'price':327,'quantity':10},
|
||||
{'item':'Sardines','brand':'Fresh Caught','units':3,'price':2727,'quantity':3},
|
||||
{'item':'Chickpeas','brand':'Southern Style','units':2,'price':2600,'quantity':5},
|
||||
{'item':'Lentils','brand':'Southern Style','units':2,'price':2378,'quantity':5},
|
||||
{'item':'Vegetable oil','brand':'Crafco','units':12,'price':10020,'quantity':1},
|
||||
{'item':'UHT milk','brand':'Atlantic','units':6,'price':4560,'quantity':2},
|
||||
{'item':'Flour','brand':'Neighbor Mills','units':10,'price':5200,'quantity':1},
|
||||
{'item':'Tomato sauce','brand':'Best Family','units':1,'price':190,'quantity':10},
|
||||
{'item':'Sugar','brand':'Good Price','units':1,'price':565,'quantity':10},
|
||||
{'item':'Tea','brand':'Superior','units':5,'price':2720,'quantity':2},
|
||||
{'item':'Coffee','brand':'Colombia Select','units':2,'price':4180,'quantity':5},
|
||||
{'item':'Tofu','brand':'Gourmet Choice','units':1,'price':1580,'quantity':10},
|
||||
{'item':'Bleach','brand':'Blanchite','units':5,'price':3550,'quantity':2},
|
||||
{'item':'Soap','brand':'Sunny Day','units':6,'price':1794,'quantity':2}]
|
||||
```
|
||||
|
||||
There is one bulk pack of 10 bags of rice and 10 bulk packs with one bag each of spaghetti. In the above, the variable `packs` is set to a Python list of dictionaries. This turns out to be very similar to the Groovy approach. A few points worth noting about the difference between Groovy and Python:
|
||||
|
||||
1. In Python, there is no keyword used to define the variable `packs`; Python expects the first use to set a value.
|
||||
2. Python dictionary keys (e.g., `item`, `brand`, `units`, `price`, `quantity`) require quotes to indicate they are strings; Groovy assumes these are strings, but accepts quotes as well.
|
||||
3. In Python, the notation `{ … }` indicates a dictionary declaration; Groovy uses the same square brackets as a list, but the structure in both cases must have key-value pairs.
|
||||
|
||||
|
||||
|
||||
And, yes, those prices aren't in US dollars.
|
||||
|
||||
Next, unpack the bulk packages. Unpacking the single bulk package of rice, for example, will yield 10 units of rice; that is, the total number of units yielded is `units * quantity`. The Groovy script uses a handy function called `collectMany` that can be used to flatten out lists of lists. As far as I know, Python doesn't have anything similar, so use two list comprehensions to produce the same result:
|
||||
|
||||
|
||||
```
|
||||
units = [[{'item':pack['item'],'brand':pack['brand'],
|
||||
'price':(pack['price'] / pack['units'])}] *
|
||||
(pack['units'] * pack['quantity']) for pack in packs]
|
||||
units = [x for sublist in units for x in sublist]
|
||||
```
|
||||
|
||||
The first list comprehension (assignment to units) builds the list of lists of dictionaries. The second "flattens" that into just a list of dictionaries. Note that both Python and Groovy provide an `*` operator that takes a list on the left and a number `N` on the right and replicates the list `N` times.
|
||||
|
||||
The final step is to repack the units into the hampers for distribution. As in the Groovy version, you need to get a bit more specific about the ideal hamper value, and you might as well not be overly restrictive when you get down to just a few units left:
|
||||
|
||||
|
||||
```
|
||||
valueIdeal = 5000
|
||||
valueMax = valueIdeal * 1.1
|
||||
```
|
||||
|
||||
OK! Repack the hampers:
|
||||
|
||||
|
||||
```
|
||||
import random
|
||||
hamperNumber = 0 # [1]
|
||||
while len(units) > 0: # [2]
|
||||
hamperNumber += 1
|
||||
hamper = []
|
||||
value = 0
|
||||
canAdd = True # [2.1]
|
||||
while canAdd: # [2.2]
|
||||
u = random.randint(0,len(units)-1) # [2.2.1]
|
||||
canAdd = False # [2.2.2]
|
||||
o = 0 # [2.2.3]
|
||||
while o < len(units): # [2.2.4]
|
||||
uo = (u + o) % len(units)
|
||||
unit = units[uo]
|
||||
unitPrice = unit['price'] # [2.2.4.1]
|
||||
if len(units) < 3 or not (unit in hamper) and (value + unitPrice) < valueMax:
|
||||
# [2.2.4.2]
|
||||
hamper.append(unit)
|
||||
value += unitPrice
|
||||
units.pop(u) # [2.2.4.3]
|
||||
canAdd = len(units) > 0
|
||||
break # [2.2.4.4]
|
||||
o += 1 # [2.2.4.5]
|
||||
# [2.2.5]
|
||||
print('')
|
||||
print('Hamper',hamperNumber,'value',value)
|
||||
for item in hamper:
|
||||
print('%-25s%-25s%7.2f' % (item['item'],item['brand'],item['price'])) # [2.3]
|
||||
print('Remaining units',len(units)) # [2.4]
|
||||
```
|
||||
|
||||
Some clarification, with numbers in brackets in the comments above (e.g., _[1]_) corresponding to the clarifications below:
|
||||
|
||||
* 1\. Import Python's random number generator facilities and initialize the hamper number.
|
||||
* 2\. This `while` loop will redistribute units into hampers as long as there are more available:
|
||||
* 2.1 Increment the hamper number, get a new empty hamper (a list of units), and set its value to 0; start off assuming you can add more items to the hamper.
|
||||
* 2.2 This `while` loop will add as many units to the hamper as possible (the Groovy code used a `for` loop, but Python's `for` loops expect to iterate over something, while Groovy has the more traditional C form of `for` loop):
|
||||
* 2.2.1 Get a random number between zero and the number of remaining units minus 1.
|
||||
* 2.2.2 Assume you can't find more units to add.
|
||||
* 2.2.3 Create a variable to be used for the offset from the starting point where you're looking for items to put in the hamper.
|
||||
* 2.2.4 Starting at the randomly chosen index, this `while` loop will try to find a unit that can be added to the hamper (once again, note that the Python `for` loop probably isn't suitable here since the length of the list will change during processing).
|
||||
* 2.2.4.1. Figure out which unit to look at (random starting point + offset) and get its price.
|
||||
* 2.2.4.2 You can add this unit to the hamper if there are only a few left or if the value of the hamper isn't too high once the unit is added.
|
||||
* 2.2.4.3 Add the unit to the hamper, increment the hamper value by the unit price, remove the unit from the available units list.
|
||||
* 2.2.4.4 As long as there are units left, you can add more, so break out of this loop to keep looking.
|
||||
* 2.2.4.5 Increment the offset.
|
||||
* 2.2.5 On exit from this `while` loop, if you inspected every remaining unit and could not find one to add to the hamper, the hamper is complete; otherwise, you found one and can continue looking for more.
|
||||
* 2.3 Print out the contents of the hamper.
|
||||
* 2.4 Print out the remaining units info.
|
||||
|
||||
|
||||
|
||||
When you run this code, the output looks quite similar to the output from the Groovy program:
|
||||
|
||||
|
||||
```
|
||||
Hamper 1 value 5304.0
|
||||
UHT milk Atlantic 760.00
|
||||
Tomato sauce Best Family 190.00
|
||||
Rice Best Family 565.00
|
||||
Coffee Colombia Select 2090.00
|
||||
Sugar Good Price 565.00
|
||||
Vegetable oil Crafco 835.00
|
||||
Soap Sunny Day 299.00
|
||||
Remaining units 148
|
||||
|
||||
Hamper 2 value 5428.0
|
||||
Tea Superior 544.00
|
||||
Lentils Southern Style 1189.00
|
||||
Flour Neighbor Mills 520.00
|
||||
Tofu Gourmet Choice 1580.00
|
||||
Vegetable oil Crafco 835.00
|
||||
UHT milk Atlantic 760.00
|
||||
Remaining units 142
|
||||
|
||||
Hamper 3 value 5424.0
|
||||
Soap Sunny Day 299.00
|
||||
Chickpeas Southern Style 1300.00
|
||||
Sardines Fresh Caught 909.00
|
||||
Rice Best Family 565.00
|
||||
Vegetable oil Crafco 835.00
|
||||
Spaghetti Best Family 327.00
|
||||
Lentils Southern Style 1189.00
|
||||
Remaining units 135
|
||||
|
||||
…
|
||||
|
||||
Hamper 21 value 5145.0
|
||||
Tomato sauce Best Family 190.00
|
||||
Tea Superior 544.00
|
||||
Chickpeas Southern Style 1300.00
|
||||
Spaghetti Best Family 327.00
|
||||
UHT milk Atlantic 760.00
|
||||
Vegetable oil Crafco 835.00
|
||||
Lentils Southern Style 1189.00
|
||||
Remaining units 4
|
||||
|
||||
Hamper 22 value 2874.0
|
||||
Sardines Fresh Caught 909.00
|
||||
Vegetable oil Crafco 835.00
|
||||
Rice Best Family 565.00
|
||||
Rice Best Family 565.00
|
||||
Remaining units 0
|
||||
```
|
||||
|
||||
The last hamper is abbreviated in contents and value.
|
||||
|
||||
### Closing thoughts
|
||||
|
||||
At a glance, there isn't a whole lot of difference between the Python and Groovy versions of this program. Both have a similar set of constructs that make handling lists and dictionaries very straightforward. Neither requires a lot of "boilerplate code" or other "ceremonial" actions.
|
||||
|
||||
Also, as in the Groovy example, there is some fiddly business about being able to add units to the hamper. Basically, you pick a random position in the list of units and, starting at that position, iterate through the list until you either find a unit whose price allows it to be included or until you exhaust the list. Also, when there are only a few items left, you just toss them into the last hamper.
|
||||
|
||||
Another issue worth mentioning: This isn't a particularly efficient approach. Removing elements from lists, being careless about repeated expressions, and a few other things make this less suitable for a huge redistribution problem. Still, it runs in a blink on my old machine.
|
||||
|
||||
If you are shuddering at my use of `while` loops and mutating the data in this code, you probably wish I made it more functional. I couldn't think of a way to use map and reduce features in Python in conjunction with a random selection of units for repackaging. Can you?
|
||||
|
||||
In the next article, I'll re-do this in Java just to see how much less effort Groovy and Python are, and future articles will cover Julia and Go.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/9/solve-problem-python
|
||||
|
||||
作者：[Chris Hermansen][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/clhermansen
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/python_programming_question.png?itok=cOeJW-8r (Python programming language logo with question marks)
|
||||
[2]: https://opensource.com/article/20/8/solving-problem-groovy
|
||||
[3]: https://groovy-lang.org/
|
||||
[4]: https://www.python.org/
|
||||
@ -0,0 +1,107 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (KeePassXC is An Amazing Community Driven Open Source Password Manager [Not Cloud Based])
|
||||
[#]: via: (https://itsfoss.com/keepassxc/)
|
||||
[#]: author: (Ankush Das https://itsfoss.com/author/ankush/)
|
||||
|
||||
KeePassXC is An Amazing Community Driven Open Source Password Manager [Not Cloud Based]
|
||||
======
|
||||
|
||||
_**Brief: KeePassXC is a useful open-source cross-platform password manager that doesn’t compromise on features even if it’s not a cloud-based tool. Here, we take a quick look at it.**_
|
||||
|
||||
### KeePassXC: A Cross-Platform Open Source Password Manager
|
||||
|
||||
![][1]
|
||||
|
||||
KeePassXC is a community fork of [KeePassX][2] which aims to be a cross-platform port for [KeePass Password Safe][3] (available for Windows). It is completely free to use and cross-platform as well (Windows, Linux, and macOS)
|
||||
|
||||
In fact, it is one of the [best password managers for Linux][4] out there. It features options for both newbies and power users who want advanced controls to secure their password database on their system.
|
||||
|
||||
Yes, unlike my [favorite Bitwarden password manager][5], KeePassXC is not cloud-based and the passwords never leave the system. Some users do prefer to not save their passwords and secrets in cloud servers.
|
||||
|
||||
You should find all the essential features you will ever need on a password manager when you start using it. But, here, to give you a head start, I’ll highlight some features offered.
|
||||
|
||||
### Features of KeePassXC
|
||||
|
||||
![][6]
|
||||
|
||||
It is worth noting that the features might prove to be a little overwhelming for a newbie. But, considering that you want to make the most out of it, I think you should actually know what it offers:
|
||||
|
||||
* Password Generator
|
||||
* Ability to import passwords from 1Password, KeePass 1, and any CSV files
|
||||
* Easily share databases by exporting and synchronizing with SSL certificate support
|
||||
* Database Encryption supported (256 bit AES)
|
||||
* Browser Integration Available (optional)
|
||||
* Ability to search for your credentials
|
||||
* Auto-type passwords into applications
|
||||
* Database reports to check password health and other stats
|
||||
* Supports exporting to CSV and HTML
|
||||
* 2-factor authentication token support
|
||||
* Attach files to passwords
|
||||
* YubiKey support
|
||||
* Command line option available
|
||||
* SSH Agent integration available
|
||||
* Change encryption algorithms if required
|
||||
* Ability to use DuckDuckGO to download the website icons
|
||||
* Database auto-lock timeout
|
||||
* Ability to clear the clipboard and the search query
|
||||
* Auto-file save
|
||||
* Folder/Nested Folder support
|
||||
* Set expiration of a credential
|
||||
* Dark theme available
|
||||
* Cross-platform support
|
||||
|
||||
|
||||
|
||||
As you can observe, it is a feature-rich password manager indeed. So, I’d advise you to properly explore it if you want to utilize every option present.
|
||||
|
||||
![][7]
|
||||
|
||||
### Installing KeePassXC on Linux
|
||||
|
||||
You should find it listed in your software center of the distribution you’ve installed.
|
||||
|
||||
You can also get the AppImage file from the official website. I’d suggest you to check out our guide on [using AppImage files in Linux][8] if you didn’t know already.
|
||||
|
||||
In either case, you will also find a snap available for it. In addition to that, you also get an Ubuntu PPA, Debian package, Fedora package, and Arch package.
|
||||
|
||||
If you’re curious, you can just explore the [official download page][9] for the available packages and check out their [GitHub page][10] for the source code as well.
|
||||
|
||||
[Get KeePassXC][11]
|
||||
|
||||
### Wrapping Up
|
||||
|
||||
If you’re not a fan of cloud-based open-source password managers like [Bitwarden][5], KeePassXC should be an excellent choice for you.
|
||||
|
||||
The number of options that you get here lets you keep your password secure and easy to maintain across multiple platforms. Even though you don’t have an “official” mobile app from the developer team, you may try some of their [recommended apps][12] which are compatible with the database and offer the same functionalities.
|
||||
|
||||
Have you tried KeePassXC yet? What do you prefer using as your password manager? Let me know your thoughts in the comments below.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://itsfoss.com/keepassxc/
|
||||
|
||||
作者：[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://i1.wp.com/itsfoss.com/wp-content/uploads/2020/09/keepassxc-screenshot.jpg?resize=800%2C580&ssl=1
|
||||
[2]: https://www.keepassx.org/
|
||||
[3]: https://keepass.info
|
||||
[4]: https://itsfoss.com/password-managers-linux/
|
||||
[5]: https://itsfoss.com/bitwarden/
|
||||
[6]: https://i2.wp.com/itsfoss.com/wp-content/uploads/2020/09/keepassxc-screenshot-1.jpg?resize=800%2C579&ssl=1
|
||||
[7]: https://i1.wp.com/itsfoss.com/wp-content/uploads/2020/09/keepassxc-settings.png?resize=800%2C587&ssl=1
|
||||
[8]: https://itsfoss.com/use-appimage-linux/
|
||||
[9]: https://keepassxc.org/download/
|
||||
[10]: https://github.com/keepassxreboot/keepassxc
|
||||
[11]: https://keepassxc.org
|
||||
[12]: https://keepassxc.org/docs/#faq-platform-mobile
|
||||
125
translated/tech/20200708 6 best practices for teams using Git.md
Normal file
125
translated/tech/20200708 6 best practices for teams using Git.md
Normal file
@ -0,0 +1,125 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (LazyWolfLin)
|
||||
[#]: 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)
|
||||
|
||||
团队中使用 Git 的 6 个最佳实践
|
||||
======
|
||||
|
||||
> 采用这些 Git 协作策略，让团队工作更高效。
|
||||
|
||||
![技术会议上得女性们][1]
|
||||
|
||||
Git 非常有助于小团队管理自身的软件开发进度，但有些方法能让你把它变得更高效。我发现了许多有助于我的团队的最佳实践，尤其是当不同 Git 水平的新人加入时。
|
||||
|
||||
### 在你的团队中正式确立 Git 约定
|
||||
|
||||
每个人都应当遵循对于分支命名，标记和编码的规范。每个组织都有自己的规范或者最佳实践，并且很多建议都可以从网上免费获取。而重要的是尽早选择合适的规范并在团队中遵循。
|
||||
|
||||
同时，不同的团队成员的 Git 水平参差不齐。你需要创建并维护一组符合团队规范的基础指令，用于执行通用 Git 操作。
|
||||
|
||||
### 正确地合并变更
|
||||
|
||||
每个团队成员都需要在独立的功能分支上开发。但是尽管使用了独立的分支，每个人最终都会修改到一些通用文件。当把更改合并回 `master` 分支时，合并通常无法自动进行。可能需要手动解决不同作者对同一文件不同变更的冲突。这就是你必须学会如何处理 Git 合并技术的原因。
|
||||
|
||||
现代编辑器具有协助解决 [Git 合并冲突][2]的功能。它们对同一文件合并的每一个部分提供多种选择，例如，是否保留你的更改，或者是保留另一分支的更改，亦或者是全部保留。如果你的编辑器不支持这些功能，那么可能是时候换一个代码编辑器了。
|
||||
|
||||
### 经常重整你的功能分支
|
||||
|
||||
当你持续地开发你的功能分支时，请经常对它做 `rebase master`。这意味着要经常执行以下步骤：
|
||||
|
||||
```
|
||||
git checkout master
|
||||
git pull
|
||||
git checkout feature-xyz # 假设的功能分支名称
|
||||
git rebase master # 可能需要解决 feature-xyz 上的合并冲突
|
||||
```
|
||||
|
||||
这些步骤会在你的功能分支上[重写历史][3]（这并不是件坏事）。首先，它会使你的功能分支获得 `master` 分支上当前的所有更新。其次，你在功能分支上的所有提交都会在分支历史的顶部重写，因此它们会顺序地出现在日志中。你可能需要一路解决遇到地合并冲突，这也许是个挑战。但是，这是解决冲突最好的时间，因为它只影响你的功能分支。
|
||||
|
||||
在解决完所有冲突并进行回归测试后，如果你准备好将功能分支合并回 `master`，那么就可以在再次执行上述的 `rebase` 步骤后进行合并：
|
||||
|
||||
```
|
||||
git checkout master
|
||||
git pull
|
||||
git merge feature-xyz
|
||||
```
|
||||
|
||||
在次期间，如果其他人也将和你有冲突的更改推送到 `master`，那么 Git 合并将再次发生冲突。你需要解决它们并重新进行回归测试。
|
||||
|
||||
还有一些其他的合并哲学（例如，只使用合并不使用 rebase 以防止重写历史），其中一些甚至可能更简单易用。但是，我发现上述方法是一个干净可靠的策略。提交历史日志将以有意义的功能序列进行排列。
|
||||
|
||||
如果使用“纯合并”策略（上面所说的，不定期 rebase），那么 `master` 分支的历史将穿插着所有同时开发的功能的提交。这样混乱的历史很难回顾。确切的提交时间通常并不是那么重要。最好是有一个易于查看的历史日志。
|
||||
|
||||
### 在合并前压缩提交
|
||||
|
||||
当你在功能分支上开发时，即使再小的修改也可以作为一个 commit。但是，如果每个个功能分支都要产生五十个 commit，那么随着不断地增添新功能，`master` 分支的 commit 数终将无谓地膨胀。通常来说，每个功能分支只应该往 `master` 中增加一个或几个 commit。为此，你需要将多个 commit 压缩成一个或者几个带有更详细信息的提交中。通常使用以下命令来完成：
|
||||
|
||||
```
|
||||
git rebase -i HEAD~20 # 查看可进行压缩的二十个 commit
|
||||
```
|
||||
|
||||
当这条命令执行后，将弹出一个 commit 列表的编辑器，你可以通过包括 _pick_ 或 _squash_ 内的数种方式编辑它。_pick_ 一个 commit 即保留这个 commit。_squash_ 一个 commit 则是将这个 commit 合并到前一个中。使用这些方法，你就可以将多个 commit 合并到一个并做编辑和清理。这也是一个清理不重要的 commit 信息的机会（例如，带错字的提交）。
|
||||
|
||||
总之，保留所有与 commit 相关的操作，但在合并到 `master` 分支前，合并并编辑相关信息以明确意图。注意，不要在 rebase 的过程中不小心删掉 commit。
|
||||
|
||||
在执行完诸如 rebase 之类的操作后，我会再次看看 `git log` 并做最终的修改：
|
||||
|
||||
```
|
||||
git commit --amend
|
||||
```
|
||||
|
||||
最后，由于重写了分支的 Git 提交历史，必需强制更新远程分支：
|
||||
|
||||
```
|
||||
git push -f
|
||||
```
|
||||
|
||||
### 使用标签
|
||||
|
||||
当你完成测试并准备从 `master` 分支部署软件到线上时，又或者当你出于某种原因想要保留当前状态作为一个里程碑时，那么可以创建一个 Git 的标签。对于一个积累了一些变更和相应提交的分支而言，标签就是该分支在那一时刻的快照。一个标签可以看作是没有历史记录的分支，也可以看作是直接指向标签创建前那个提交的命名指针。
|
||||
|
||||
配置控制是关于保留各个里程碑上代码的状态。大多数项目都有一个需求，允许重现任一里程碑上的软件源码，以便在需要时重新构建。Git 标签为每个代码的里程碑提供了一个唯一标识。打标签非常简单：
|
||||
|
||||
```
|
||||
git tag milestone-id -m "short message saying what this milestone is about"
|
||||
git push --tags # 不要忘记将标签显式推送到远程
|
||||
```
|
||||
|
||||
考虑一种情况，Git 标签对应的软件版本已经分发给客户，而且客户提了个问题。尽管代码库中的代码可能已经继续在开发，但通常情况下为了准确地重现客户问题以便做出修复，必须回退到 Git 标签对应的代码状态。偶尔，新代码已经修复了那个问题，但并非一直如此。通常你需要切换到特定的标签并从那个标签创建一个分支：
|
||||
|
||||
```
|
||||
git checkout milestone-id # 切换到分发给客户的标签
|
||||
git checkout -b new-branch-name # 创建新的分支用于重现 bug
|
||||
```
|
||||
|
||||
此外，如果带注释的标记和带符号的标记有助于你的项目，可以考虑使用它们。
|
||||
|
||||
### 让软件运行时打印标签
|
||||
|
||||
在大多数嵌入式项目中，从代码版本构建出二进制文件有固定的名称。但无法从它的名称推断出对应的 Git 标签。在构建时“嵌入标签”有助于将未来的问题精准地关联到特定的构建。在构建过程中可以自动地嵌入标签。通常，`git describe` 生成地标签代码会在代码编译前插入到代码中，以便生成的可执行文件能够在启时输出标签代码。当客户报告问题时，可以指导他们给你发送启动时输出的数据。
|
||||
|
||||
### 总结
|
||||
|
||||
Git 是一个需要花时间去掌握的复杂工具。使用这些实践可以帮助团队成功地使用 Git 协作，无论他们的知识水平。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/7/git-best-practices
|
||||
|
||||
作者：[Ravi Chandran][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[LazyWolfLin](https://github.com/LazyWolfLin)
|
||||
校对：[校对者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,133 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Using the Linux stat command to create flexible file listings)
|
||||
[#]: via: (https://www.networkworld.com/article/3573802/using-the-linux-stat-command-to-create-flexible-file-listings.html)
|
||||
[#]: author: (Sandra Henry-Stocker https://www.networkworld.com/author/Sandra-Henry_Stocker/)
|
||||
|
||||
使用 Linux stat 命令创建灵活的文件列表
|
||||
======
|
||||
|
||||
**stat** 命令提供了很多关于文件的详细信息。
|
||||
|
||||
它不仅提供了文件最近变化的日期/时间，还显示了最近访问文件的时间和权限变化。它可以同时告诉你文件的字节大小和块的数量。它显示文件使用的 inode 以及文件类型。它包括文件所有者和相关用户组的名称和 UID/GID。它以 “rwx”（被称为 "人类可读 "格式）和数字方式显示文件权限。在某些系统中，它甚至可能包括文件创建的日期和时间（称为"出生"）。
|
||||
|
||||
除了提供所有这些信息外，**stat** 命令还可以用来创建文件列表。这些列表非常灵活，你可以选择包含上述任何或全部信息。
|
||||
|
||||
要生成一个自定义列表，你只需要使用 **stat** 命令的 **-c**（或 --**format**）选项，并指定你想要包含的字段。例如，要创建一个以两种格式显示文件权限的列表，使用这个命令：
|
||||
|
||||
```
|
||||
$ stat -c '%n %a %A' my*
|
||||
my.banner 664 -rw-rw-r--
|
||||
mydir 775 drwxrwxr-x
|
||||
myfile 664 -rw-rw-r--
|
||||
myjunk 777 lrwxrwxrwx
|
||||
mykey 664 -rw-rw-r--
|
||||
mylog 664 -rw-rw-r--
|
||||
myscript 755 -rwxr-xr-x
|
||||
mytext 664 -rw-rw-r--
|
||||
mytext.bak 664 -rw-rw-r--
|
||||
mytwin 50 -rw-r-----
|
||||
mywords 664 -rw-rw-r--
|
||||
```
|
||||
|
||||
如上例所示，**%n** 代表文件名，**%a** 代表八进制的权限，**%A** 代表 **rwx** 形式的权限。完整的列表如下所示。
|
||||
|
||||
要为这个命令创建一个别名，输入这个，或在 **.bashrc** 文件中添加这个定义。
|
||||
|
||||
```
|
||||
$ alias ls_perms="stat -c '%n %a %A'"
|
||||
```
|
||||
|
||||
要创建一个非常接近 **ls -l** 提供的长列表，可以这样做：
|
||||
|
||||
```
|
||||
$ stat -c '%A %h %U %G %s %y %n' my*
|
||||
-rw-rw-r-- 1 shs shs 255 2020-04-01 16:20:00.899374215 -0400 my.banner
|
||||
drwxrwxr-x 2 shs shs 4096 2020-09-07 12:50:20.224470760 -0400 mydir
|
||||
-rw-rw-r-- 1 shs shs 6 2020-05-16 11:12:00.460355387 -0400 myfile
|
||||
lrwxrwxrwx 1 shs shs 11 2020-05-28 18:49:21.666792608 -0400 myjunk
|
||||
-rw-rw-r-- 1 shs shs 655 2020-01-14 15:56:08.540540488 -0500 mykey
|
||||
-rw-rw-r-- 1 shs shs 8 2020-03-04 17:13:21.406874246 -0500 mylog
|
||||
-rwxr-xr-x 1 shs shs 201 2020-09-07 12:50:41.316745867 -0400 myscript
|
||||
-rw-rw-r-- 1 shs shs 40 2019-06-06 08:54:09.538663323 -0400 mytext
|
||||
-rw-rw-r-- 1 shs shs 24 2019-06-06 08:48:59.652712578 -0400 mytext.bak
|
||||
-rw-r----- 2 shs shs 228 2019-04-12 19:37:12.790284604 -0400 mytwin
|
||||
-rw-rw-r-- 1 shs shs 1983 2020-08-10 14:39:57.164842370 -0400 mywords
|
||||
```
|
||||
|
||||
不同之处包括： 1) 不试图将字段排成可辨认的一列，2) 日期是 _**yy-mm-dd**_ 格式，3) 时间字段更精确，4) 增加了时区（-0400 是 EDT）。
|
||||
|
||||
如果你想根据最后一次访问的日期来列出文件(例如，用 **cat** 命令来显示)，使用这样的命令：
|
||||
|
||||
```
|
||||
$ stat -c '%n %x' my* | sort -k2
|
||||
mytwin 2019-04-22 11:25:20.656828964 -0400
|
||||
mykey 2020-08-20 16:10:34.479324431 -0400
|
||||
mylog 2020-08-20 16:10:34.527325066 -0400
|
||||
myfile 2020-08-20 16:10:57.815632794 -0400
|
||||
mytext.bak 2020-08-20 16:10:57.935634379 -0400
|
||||
mytext 2020-08-20 16:15:42.323391985 -0400
|
||||
mywords 2020-08-20 16:15:43.479407259 -0400
|
||||
myjunk 2020-09-07 10:04:26.543980300 -0400
|
||||
myscript 2020-09-07 12:50:41.312745815 -0400
|
||||
my.banner 2020-09-07 13:22:38.105826116 -0400
|
||||
mydir 2020-09-07 14:53:10.171867194 -0400
|
||||
```
|
||||
|
||||
用 **stat** 列出文件细节时，可用的选项包括：
|
||||
|
||||
* %a - 八进制的访问权限（注意 “#”和 “0” printf标志）。
|
||||
* %A – 人类可读的访问权限；
|
||||
* %b – 分配的块数（见 %B）。
|
||||
* %B – %b 报告的每个块的字节数。
|
||||
* %C – SELinux 安全上下文字符串。
|
||||
* %d – 十进制的设备编号
|
||||
* %D – 十六进制的设备编号
|
||||
* %f – 十六进制的原始模式
|
||||
* %F – 文件类型
|
||||
* %g – 所有者的组 ID
|
||||
* %G – 所有者的组名
|
||||
* %h – 硬链接的数量
|
||||
* %i – inode 编号
|
||||
* %m – 挂载点
|
||||
* %n – 文件名
|
||||
* %N – 如果是符号链接，则引用的文件名会解引用。
|
||||
* %o – 最佳 I/O 传输大小提示
|
||||
* %s – 以字节为单位的总大小。
|
||||
* %t – 十六进制的主要设备类型，用于字符/块设备特殊文件。
|
||||
* %T – 十六进制的次要设备类型，用于字符/块设备特殊文件。
|
||||
* %u – 所有者的用户 ID
|
||||
* %U – 所有者的用户名
|
||||
* %w – 文件创建时间，以人类可读形式； 如果未知，则为 -。
|
||||
* %W – 文件创建时间，以纪元以来的秒数形式；如果未知，则为 0。
|
||||
* %x – 上次访问时间，以人类可读形式。
|
||||
* %X – 上次访问时间，以纪元以来的秒数形式。
|
||||
* %y – 上次数据修改时间，以人类可读形式。
|
||||
* %Y – 上次数据修改时间，以纪元以来的秒数形式。
|
||||
* %z – 上次状态改变的时间，以人类可读形式。
|
||||
* %Z – 上次状态改变的时间，以纪元以来的秒数形式。
|
||||
|
||||
|
||||
|
||||
这些字段的选择都列在手册页中，你可以选择任何一个，不过用你喜欢的选项创建一些别名应该可以省去很多麻烦。有些选项，如 SELinux 安全上下文字符串，除非在系统中有使用，它将无法使用。文件创建只有在你的系统保留该信息的情况下才能使用。
|
||||
|
||||
加入 [Facebook][2] 和 [LinkedIn][3] 上的 Network World 社区，评论热门主题。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.networkworld.com/article/3573802/using-the-linux-stat-command-to-create-flexible-file-listings.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
|
||||
[2]: https://www.facebook.com/NetworkWorld/
|
||||
[3]: https://www.linkedin.com/company/network-world
|
||||
@ -0,0 +1,100 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (wxy)
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Linux Jargon Buster: What is a Long Term Support \(LTS\) Release? What is Ubuntu LTS?)
|
||||
[#]: via: (https://itsfoss.com/long-term-support-lts/)
|
||||
[#]: author: (Ankush Das https://itsfoss.com/author/ankush/)
|
||||
|
||||
Linux 黑话解释：什么是长期支持（LTS）版本？什么是 Ubuntu LTS？
|
||||
======
|
||||
|
||||
在 Linux 的世界里，特别是谈到 [Ubuntu][1] 的时候，你会遇到 LTS（<ruby>长期支持<rt>Long Term Support</rt></ruby>）这个词。
|
||||
|
||||
如果你是一个经验丰富的 Linux 用户，你可能知道 Linux 发行版的各个方面，比如 LTS 版本。但是，新用户或不太懂技术的用户可能不知道。
|
||||
|
||||
在这一章 Linux 黑话解释中，你将了解什么是 Linux 发行版的 LTS 版本。
|
||||
|
||||
### 什么是长期支持（LTS）版本？
|
||||
|
||||
长期支持（LTS）版本通常与应用程序或操作系统有关，你会在较长的时间内获得安全、维护和（有时有）功能的更新。
|
||||
|
||||
LTS 版本被认为是最稳定的版本，它经历了广泛的测试，并且大多包含了多年积累的改进。
|
||||
|
||||
需要注意的是，LTS 版本的软件不一定涉及功能更新，除非有一个更新的 LTS 版本。但是，你会在 LTS 版本的更新中得到必要的错误修复和安全修复。
|
||||
|
||||
LTS 版本被推荐给生产级的消费者、企业和商家，因为你可以获得多年的软件支持，而且软件更新不会破坏系统。
|
||||
|
||||
如果你注意到任何软件的非 LTS 版本，它通常是具有新功能和较短支持时间跨度（例如 6-9 个月）的前沿版本，而 LTS 版本的支持时间为3-5年。
|
||||
|
||||
![][2]
|
||||
|
||||
为了让大家更清楚的了解 LTS 和非 LTS 版本的区别，我们来看看选择 LTS 版本的一些优缺点。
|
||||
|
||||
#### LTS 版本的优点
|
||||
|
||||
* 软件更新与安全和维护修复的时间很长（Ubuntu 有 5 年支持）
|
||||
* 广泛的测试
|
||||
* 软件更新不会带来破坏系统的变化
|
||||
* 你有足够的时间为下一个 LTS 版本准备系统
|
||||
|
||||
#### LTS 版本的缺点
|
||||
|
||||
* 不提供最新和最强的功能
|
||||
* 你可能会错过最新的硬件支持
|
||||
* 你也可能会错过最新的应用程序升级
|
||||
|
||||
现在，你知道了什么是 LTS 版本及其优缺点，是时候了解一下 Ubuntu 的 LTS 版本了。Ubuntu 是最流行的 Linux 发行版之一，也是少数同时拥有 LTS 和非 LTS 版本的发行版之一。
|
||||
|
||||
这就是为什么我决定用一整个章节来介绍它。
|
||||
|
||||
### 什么是 Ubuntu LTS？
|
||||
|
||||
自 2006 年以来，Ubuntu 每六个月发布一个非 LTS 版本，每两年发布一个 LTS 版本，这一点一直如此。
|
||||
|
||||
最新的 LTS 版本是 [Ubuntu 20.04][3]，它将被支持到 2025 年 4 月。换句话说，Ubuntu 20.04 在那之前都会收到软件更新。非 LTS 版本只支持九个月。
|
||||
|
||||
你会发现 Ubuntu LTS 版本总是被标为 “LTS”。至少，在 [Ubuntu 官方网站][4]上浏览最新的 Ubuntu 版本时是这样的。
|
||||
|
||||
为了让你更清楚，如果你见过 Ubuntu 16.04 LTS，那就意味着：**它早在 2016 年 4 月就已经发布，并且支持到 2021 年**（想想**5 年的软件更新**）。
|
||||
|
||||
同样，你也可以通过计算每个 Ubuntu LTS 版本发布日期接下来的**5 年**软件支持期来估计其更新支持情况。
|
||||
|
||||
### Ubuntu LTS 软件更新包括什么？
|
||||
|
||||
![][5]
|
||||
|
||||
Ubuntu LTS 版本在其发布的生命周期内都会收到安全和维护更新。除非该版本达到[生命末期（EOL）][6]，否则你将获得所有必要的安全和错误修复。
|
||||
|
||||
在 LTS 版本中你不会注意到任何功能升级。所以，如果你想尝试最新的实验性技术，你可能需要将你的 Ubuntu 版本升级到一个非 LTS 版本。
|
||||
|
||||
我建议你参考我们最新的 [Ubuntu 升级指南][7]来了解更多关于升级 Ubuntu 的信息。
|
||||
|
||||
我也建议你阅读我们的文章[安装哪个 Ubuntu 版本][8]，以消除你对不同 Ubuntu 版本的困惑，比如 [Xubuntu][9] 或 [Kubuntu][10]，它们有什么不同。
|
||||
|
||||
我希望你现在对 LTS 这个术语有了更好的理解，尤其是在 Ubuntu LTS 方面。敬请关注未来更多的 Linux 黑话解释。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://itsfoss.com/long-term-support-lts/
|
||||
|
||||
作者：[Ankush Das][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[wxy](https://github.com/wxy)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://itsfoss.com/author/ankush/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://ubuntu.com/
|
||||
[2]: https://i0.wp.com/itsfoss.com/wp-content/uploads/2020/09/display-server-linux.png?resize=800%2C450&ssl=1
|
||||
[3]: https://itsfoss.com/download-ubuntu-20-04/
|
||||
[4]: https://ubuntu.com
|
||||
[5]: https://i1.wp.com/itsfoss.com/wp-content/uploads/2020/09/ubuntu-lts-release.png?resize=800%2C397&ssl=1
|
||||
[6]: https://itsfoss.com/end-of-life-ubuntu/
|
||||
[7]: https://itsfoss.com/upgrade-ubuntu-version/
|
||||
[8]: https://itsfoss.com/which-ubuntu-install/
|
||||
[9]: https://xubuntu.org/
|
||||
[10]: https://kubuntu.org/
|
||||
Loading…
Reference in New Issue
Block a user