diff --git a/published/20190215 Make websites more readable with a shell script.md b/published/20190215 Make websites more readable with a shell script.md new file mode 100644 index 0000000000..a84cdfaa40 --- /dev/null +++ b/published/20190215 Make websites more readable with a shell script.md @@ -0,0 +1,261 @@ +[#]: collector: (lujun9972) +[#]: translator: (stevenzdg988) +[#]: reviewer: (wxy) +[#]: publisher: (wxy) +[#]: url: (https://linux.cn/article-13052-1.html) +[#]: subject: (Make websites more readable with a shell script) +[#]: via: (https://opensource.com/article/19/2/make-websites-more-readable-shell-script) +[#]: author: (Jim Hall https://opensource.com/users/jim-hall) + +利用 Shell 脚本让网站更具可读性 +====== + +> 测算网站的文本和背景之间的对比度，以确保站点易于阅读。 + +![](https://img.linux.net.cn/data/attachment/album/202101/25/231152ce5ufhjtufxj1eeu.jpg) + +如果希望人们发现你的网站实用，那么他们需要能够阅读它。为文本选择的颜色可能会影响网站的可读性。不幸的是，网页设计中的一种流行趋势是在打印输出文本时使用低对比度的颜色，就像在白色背景上的灰色文本。对于 Web 设计师来说，这也许看起来很酷，但对于许多阅读它的人来说确实很困难。 + +W3C 提供了《Web 内容可访问性指南Web Content Accessibility Guidelines》，其中包括帮助 Web 设计人员选择易于区分文本和背景色的指导。z这就是所谓的“对比度contrast ratio”。 W3C 定义的对比度需要进行一些计算：给定两种颜色，首先计算每种颜色的相对亮度，然后计算对比度。对比度在 1 到 21 的范围内（通常写为 1:1 到 21:1）。对比度越高，文本在背景下的突出程度就越高。例如，白色背景上的黑色文本非常醒目，对比度为 21:1。对比度为 1:1 的白色背景上的白色文本不可读。 + +[W3C 说，正文][1] 的对比度至少应为 4.5:1，标题至少应为 3:1。但这似乎是最低限度的要求。W3C 还建议正文至少 7:1，标题至少 4.5:1。 + +计算对比度可能比较麻烦，因此最好将其自动化。我已经用这个方便的 Bash 脚本做到了这一点。通常，脚本执行以下操作： + + 1. 获取文本颜色和背景颜色 + 2. 计算相对亮度 + 3. 计算对比度 + +### 获取颜色 + +你可能知道显示器上的每种颜色都可以用红色、绿色和蓝色（R、G 和 B）来表示。要计算颜色的相对亮度，脚本需要知道颜色的红、绿和蓝的各个分量。理想情况下，脚本会将这些信息读取为单独的 R、G 和 B 值。 Web 设计人员可能知道他们喜欢的颜色的特定 RGB 代码，但是大多数人不知道不同颜色的 RGB 值。作为一种替代的方法是，大多数人通过 “red” 或 “gold” 或 “maroon” 之类的名称来引用颜色。 + +幸运的是，GNOME 的 [Zenity][2] 工具有一个颜色选择器应用程序，可让你使用不同的方法选择颜色，然后用可预测的格式 `rgb(R,G,B)` 返回 RGB 值。使用 Zenity 可以轻松获得颜色值： + +``` +color=$( zenity --title 'Set text color' --color-selection --color='black' ) +``` + +如果用户（意外地）单击 “Cancel（取消）” 按钮，脚本将假定一种颜色： + +``` +if [ $? -ne 0 ] ; then +        echo '** color canceled .. assume black' +        color='rgb(0,0,0)' +fi +``` + +脚本对背景颜色值也执行了类似的操作，将其设置为 `$background`。 + +### 计算相对亮度 + +一旦你在 `$color` 中设置了前景色，并在 `$background` 中设置了背景色，下一步就是计算每种颜色的相对亮度。 [W3C 提供了一个算法][3] 用以计算颜色的相对亮度。 + +> 对于 sRGB 色彩空间，一种颜色的相对亮度定义为： +> +> L = 0.2126 * R + 0.7152 * G + 0.0722 * B +> +> R、G 和 B 定义为： +> +> if $R_{sRGB}$ <= 0.03928 then R = $R_{sRGB}$/12.92 +> +> else R = (($R_{sRGB}$+0.055)/1.055) $^{2.4}$ +> +> if $G_{sRGB}$ <= 0.03928 then G = $G_{sRGB}$/12.92 +> +> else G = (($G_{sRGB}$+0.055)/1.055) $^{2.4}$ +> +> if $B_{sRGB}$ <= 0.03928 then B = $B_{sRGB}$/12.92 +> +> else B = (($B_{sRGB}$+0.055)/1.055) $^{2.4}$ +> +> $R_{sRGB}$、$G_{sRGB}$ 和 $B_{sRGB}$ 定义为： +> +> $R_{sRGB}$ = $R_{8bit}$/255 +> +> $G_{sRGB}$ = $G_{8bit}$/255 +> +> $B_{sRGB}$ = $B_{8bit}$/255 + +由于 Zenity 以 `rgb(R,G,B)` 的格式返回颜色值，因此脚本可以轻松拉取分隔开的 R、B 和 G 的值以计算相对亮度。AWK 可以使用逗号作为字段分隔符（`-F,`），并使用 `substr()` 字符串函数从 `rgb(R,G,B)` 中提取所要的颜色值： + +``` +R=$( echo $color | awk -F, '{print substr($1,5)}' ) +G=$( echo $color | awk -F, '{print $2}' ) +B=$( echo $color | awk -F, '{n=length($3); print substr($3,1,n-1)}' ) +``` + +*有关使用 AWK 提取和显示数据的更多信息，[查看 AWK 备忘表][4]* + +最好使用 BC 计算器来计算最终的相对亮度。BC 支持计算中所需的简单 `if-then-else`，这使得这一过程变得简单。但是由于 BC 无法使用非整数指数直接计算乘幂，因此需要使用自然对数替代它做一些额外的数学运算： + +``` +echo "scale=4 +rsrgb=$R/255 +gsrgb=$G/255 +bsrgb=$B/255 +if ( rsrgb <= 0.03928 ) r = rsrgb/12.92 else r = e( 2.4 * l((rsrgb+0.055)/1.055) ) +if ( gsrgb <= 0.03928 ) g = gsrgb/12.92 else g = e( 2.4 * l((gsrgb+0.055)/1.055) ) +if ( bsrgb <= 0.03928 ) b = bsrgb/12.92 else b = e( 2.4 * l((bsrgb+0.055)/1.055) ) +0.2126 * r + 0.7152 * g + 0.0722 * b" | bc -l +``` + +这会将一些指令传递给 BC，包括作为相对亮度公式一部分的 `if-then-else` 语句。接下来 BC 打印出最终值。 + +### 计算对比度 + +利用文本颜色和背景颜色的相对亮度，脚本就可以计算对比度了。 [W3C 确定对比度][5] 是使用以下公式： + +> (L1 + 0.05) / (L2 + 0.05)，这里的 +> L1 是颜色较浅的相对亮度， +> L2 是颜色较深的相对亮度。 + +给定两个相对亮度值 `$r1` 和 `$r2`，使用 BC 计算器很容易计算对比度： + +``` +echo "scale=2 +if ( $r1 > $r2 ) { l1=$r1; l2=$r2 } else { l1=$r2; l2=$r1 } +(l1 + 0.05) / (l2 + 0.05)" | bc +``` + +使用 `if-then-else` 语句确定哪个值（`$r1` 或 `$r2`）是较浅还是较深的颜色。BC 执行结果计算并打印结果，脚本可以将其存储在变量中。 + +### 最终脚本 + +通过以上内容，我们可以将所有内容整合到一个最终脚本。 我使用 Zenity 在文本框中显示最终结果： + +``` +#!/bin/sh +# script to calculate contrast ratio of colors + +# read color and background color: +# zenity returns values like 'rgb(255,140,0)' and 'rgb(255,255,255)' + +color=$( zenity --title 'Set text color' --color-selection --color='black' ) +if [ $? -ne 0 ] ; then + echo '** color canceled .. assume black' + color='rgb(0,0,0)' +fi + +background=$( zenity --title 'Set background color' --color-selection --color='white' ) +if [ $? -ne 0 ] ; then + echo '** background canceled .. assume white' + background='rgb(255,255,255)' +fi + +# compute relative luminance: + +function luminance() +{ + R=$( echo $1 | awk -F, '{print substr($1,5)}' ) + G=$( echo $1 | awk -F, '{print $2}' ) + B=$( echo $1 | awk -F, '{n=length($3); print substr($3,1,n-1)}' ) + + echo "scale=4 +rsrgb=$R/255 +gsrgb=$G/255 +bsrgb=$B/255 +if ( rsrgb <= 0.03928 ) r = rsrgb/12.92 else r = e( 2.4 * l((rsrgb+0.055)/1.055) ) +if ( gsrgb <= 0.03928 ) g = gsrgb/12.92 else g = e( 2.4 * l((gsrgb+0.055)/1.055) ) +if ( bsrgb <= 0.03928 ) b = bsrgb/12.92 else b = e( 2.4 * l((bsrgb+0.055)/1.055) ) +0.2126 * r + 0.7152 * g + 0.0722 * b" | bc -l +} + +lum1=$( luminance $color ) +lum2=$( luminance $background ) + +# compute contrast + +function contrast() +{ + echo "scale=2 +if ( $1 > $2 ) { l1=$1; l2=$2 } else { l1=$2; l2=$1 } +(l1 + 0.05) / (l2 + 0.05)" | bc +} + +rel=$( contrast $lum1 $lum2 ) + +# print results + +( cat< A _namespace_ is a mapping from names to objects. +> +> — [Python.org][2] + +Modules are namespaces. This means that correctly predicting module semantics often just requires familiarity with how Python namespaces work. Classes are namespaces. Objects are namespaces. Functions have access to their local namespace, their parent namespace, and the global namespace. + +The simple model, where the **.** operator accesses an object, which in turn will usually, but not always, do some sort of dictionary lookup, makes Python hard to optimize, but easy to explain. + +Indeed, some third-party modules take this guideline and run with it. For example, the** [variants][3]** package turns functions into namespaces of "related functionality." It is a good example of how the [Zen of Python][4] can inspire new abstractions. + +### In conclusion + +Thank you for joining me on this Hanukkah-inspired exploration of [my favorite language][5]. Go forth and meditate on the Zen until you reach enlightenment. + +-------------------------------------------------------------------------------- + +via: https://opensource.com/article/19/12/zen-python-namespaces + +作者：[Moshe Zadka][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/moshez +[b]: https://github.com/lujun9972 +[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/computer_code_programming_laptop.jpg?itok=ormv35tV (Person programming on a laptop on a building) +[2]: https://docs.python.org/3/tutorial/classes.html +[3]: https://pypi.org/project/variants/ +[4]: https://www.python.org/dev/peps/pep-0020/ +[5]: https://opensource.com/article/19/10/why-love-python diff --git a/sources/tech/20201216 Understanding 52-bit virtual address support in the Arm64 kernel.md b/sources/tech/20201216 Understanding 52-bit virtual address support in the Arm64 kernel.md deleted file mode 100644 index 8051044255..0000000000 --- a/sources/tech/20201216 Understanding 52-bit virtual address support in the Arm64 kernel.md +++ /dev/null @@ -1,251 +0,0 @@ -[#]: collector: (lujun9972) -[#]: translator: () -[#]: reviewer: ( ) -[#]: publisher: ( ) -[#]: url: ( ) -[#]: subject: (Understanding 52-bit virtual address support in the Arm64 kernel) -[#]: via: (https://opensource.com/article/20/12/52-bit-arm64-kernel) -[#]: author: (Bhupesh Sharma https://opensource.com/users/bhsharma) - -Understanding 52-bit virtual address support in the Arm64 kernel -====== -The introduction of 64-bit hardware increased the need to handle larger -address spaces. -![Puzzle pieces coming together to form a computer screen][1] - -After 64-bit hardware became available, the need to handle larger address spaces (greater than 232 bytes) became obvious. With some vendors now offering servers with 64TiB (or more) of memory, x86_64 and arm64 now allow addressing adress spaces greater than 248 bytes (available with the default 48-bit address support). - -x86_64 addressed these use cases by enabling support for five-level page tables in both hardware and software. This enables addressing address spaces equal to 257 bytes (see [x86: 5-level paging enabling for v4.12][2] for details). It bumps the limits to 128PiB of virtual address space and 4PiB of physical address space. - -arm64 achieved the same thing by introducing two new architecture extensions—ARMv8.2 LVA (Large Virtual Addressing) and ARMv8.2 LPA (Large Physical Addressing). These allow 4PiB of virtual address space and 4 PiB of physical address space (i.e., 252 bits each, respectively). - -With ARMv8.2 architecture extensions available in new arm64 CPUs, the two new hardware extensions are now supported in open source software. - -Starting with Linux kernel version 5.4, the 52-bit (Large) Virtual Address (VA) and Physical Address (PA) support was introduced for arm64 architecture. Although the [kernel documentation][3] describes these features and how they impact the new kernels running on older CPUs (which don't support 52-bit VA extension in hardware) and newer CPUs (which support 52-bit VA extensions in hardware), it can be complex for average users to understand them and how they can "opt-in" to receiving VAs from a 52-bit space. - -Therefore, I will introduce these relatively new concepts in this article: - - 1. How the kernel memory layout got "flipped" for Arm64 after the support for these features was added - 2. The impact on userspace applications, especially the ones that provide debugging support (e.g., kexec-tools, makedumpfile, and crash-utility) - 3. How userspace applications can "opt-in" to receiving VAs from a 52-bit space by specifying an mmap hint parameter that is larger than 48 bits - - - -### ARMv8.2 architecture LVA and LPA extensions - -The ARMv8.2 architecture provides two important extensions: Large Virtual Addressing (LVA) and Large Physical Addressing (LPA). - -ARMv8.2-LVA supports a larger VA space for each translation table base register of up to 52 bits when using the 64KB translation granule. - -ARMv8.2-LPA allows: - - * A larger intermediate physical address (IPA) and PA space of up to 52 bits when using the 64KB translation granule - * A level 1 block size where the block covers a 4TB address range for the 64KB translation granule if the implementation supports 52 bits of PA - - - -_Note that these features are supported only in the AArch64 state._ - -Currently, the following Arm64 Cortex-A processors support ARMv8.2 extensions: - - * Cortex-A55 - * Cortex-A75 - * Cortex-A76 - - - -For more details, see the [Armv8 Architecture Reference Manual][4]. - -### Kernel memory layout on Arm64 - -With the ARMv8.2 extension adding support for LVA space (which is only available when running with a 64KB page size), the number of descriptors gets expanded in the first level of translation. - -User addresses have bits 63:48 set to 0, while the kernel addresses have the same bits set to 1. TTBRx selection is given by bit 63 of the virtual address. The `swapper_pg_dir` contains only kernel (global) mappings, while the user `pgd` contains only user (non-global) mappings. The `swapper_pg_dir` address is written to TTBR1 and never written to TTBR0. - -**AArch64 Linux memory layout with 64KB pages plus three levels (52-bit with hardware support):** - - -``` -  Start                 End                     Size            Use -  ----------------------------------------------------------------------- -  0000000000000000      000fffffffffffff           4PB          user -  fff0000000000000      fff7ffffffffffff           2PB          kernel logical memory map -  fff8000000000000      fffd9fffffffffff        1440TB          [gap] -  fffda00000000000      ffff9fffffffffff         512TB          kasan shadow region -  ffffa00000000000      ffffa00007ffffff         128MB          bpf jit region -  ffffa00008000000      ffffa0000fffffff         128MB          modules -  ffffa00010000000      fffff81ffffeffff         ~88TB          vmalloc -  fffff81fffff0000      fffffc1ffe58ffff          ~3TB          [guard region] -  fffffc1ffe590000      fffffc1ffe9fffff        4544KB          fixed mappings -  fffffc1ffea00000      fffffc1ffebfffff           2MB          [guard region] -  fffffc1ffec00000      fffffc1fffbfffff          16MB          PCI I/O space -  fffffc1fffc00000      fffffc1fffdfffff           2MB          [guard region] -  fffffc1fffe00000      ffffffffffdfffff        3968GB          vmemmap -  ffffffffffe00000      ffffffffffffffff           2MB          [guard region] -``` - -**Translation table lookup with 4KB pages:** - - -``` -  +--------+--------+--------+--------+--------+--------+--------+--------+ -  |63    56|55    48|47    40|39    32|31    24|23    16|15     8|7      0| -  +--------+--------+--------+--------+--------+--------+--------+--------+ -   |                 |         |         |         |         | -   |                 |         |         |         |         v -   |                 |         |         |         |   [11:0]  in-page offset -   |                 |         |         |         +-> [20:12] L3 index -   |                 |         |         +-----------> [29:21] L2 index -   |                 |         +---------------------> [38:30] L1 index -   |                 +-------------------------------> [47:39] L0 index -   +-------------------------------------------------> [63] TTBR0/1 -``` - -**Translation table lookup with 64KB pages:** - - -``` -  +--------+--------+--------+--------+--------+--------+--------+--------+ -  |63    56|55    48|47    40|39    32|31    24|23    16|15     8|7      0| -  +--------+--------+--------+--------+--------+--------+--------+--------+ -   |                 |    |               |              | -   |                 |    |               |              v -   |                 |    |               |            [15:0]  in-page offset -   |                 |    |               +----------> [28:16] L3 index -   |                 |    +--------------------------> [41:29] L2 index -   |                 +-------------------------------> [47:42] L1 index (48-bit) -   |                                                   [51:42] L1 index (52-bit) -   +-------------------------------------------------> [63] TTBR0/1 -``` - -  - -![][5] - -opensource.com - -### 52-bit VA support in the kernel - -Since the newer kernels with the LVA support should run well on older CPUs (which don't support LVA extension in hardware) and the newer CPUs (which support LVA extension in hardware), the chosen design approach is to have a single binary that supports 52 bit (and must be able to fall back to 48 bit at early boot time if the hardware feature is not present). That is, the VMEMMAP must be sized large enough for 52-bit VAs and also must be sized large enough to accommodate a fixed `PAGE_OFFSET`. - -This design approach requires the kernel to support the following variables for the new virtual address space: - - -``` -VA_BITS         constant        the *maximum* VA space size - -vabits_actual   variable        the *actual* VA space size -``` - -So, while `VA_BITS` denotes the maximum VA space size, the actual VA space supported (depending on the switch made at boot time) is indicated by `vabits_actual`. - -#### Flipping the kernel memory layout - -The design approach of keeping a single kernel binary requires the kernel .text to be in the higher addresses, such that they are invariant to 48/52-bit VAs. Due to the Kernel Address Sanitizer (KASAN) shadow being a fraction of the entire kernel VA space, the end of the KASAN shadow must also be in the higher half of the kernel VA space for both 48 and 52 bit. (Switching from 48 bit to 52 bit, the end of the KASAN shadow is invariant and dependent on `~0UL`, while the start address will "grow" towards the lower addresses). - -To optimize `phys_to_virt()` and `virt_to_phys()`, the `PAGE_OFFSET` is kept constant at `0xFFF0000000000000` (corresponding to 52 bit), this obviates the need for an extra variable read. The `physvirt` and `vmemmap` offsets are computed at early boot to enable this logic. - -Consider the following physical vs. virtual RAM address space conversion: - - -``` -/* - * The linear kernel range starts at the bottom of the virtual address - * space. Testing the top bit for the start of the region is a - * sufficient check and avoids having to worry about the tag. - */ - -#define virt_to_phys(addr) ({                                   \ -        if (!(((u64)addr) & BIT(vabits_actual - 1)))            \ -                (((addr) & ~PAGE_OFFSET) + PHYS_OFFSET) -}) - -#define phys_to_virt(addr) ((unsigned long)((addr) - PHYS_OFFSET) | PAGE_OFFSET) - -where: - PAGE_OFFSET - the virtual address of the start of the linear map, at the -                start of the TTBR1 address space, - PHYS_OFFSET - the physical address of the start of memory, and - vabits_actual - the *actual* VA space size -``` - -### Impact on userspace applications used to debug kernel - -Several userspace applications are used to debug running/live kernels or analyze the vmcore dump from a crashing system (e.g., to determine the root cause of the kernel crash): kexec-tools, makedumpfile, and crash-utility. - -When these are used for debugging the Arm64 kernel, there is also an impact on them because of the Arm64 kernel memory map getting "flipped." These applications also need to perform a translation table walk for determining a physical address corresponding to a virtual address (similar to how it is done in the kernel). - -Accordingly, userspace applications must be modified as they are broken upstream after the "flip" was introduced in the kernel memory map. - -I have proposed fixes in the three affected userspace applications; while some have been accepted upstream, others are still pending: - - * [Proposed makedumpfile upstream fix][6] - * [Proposed kexec-tools upstream fix][7] - * [Fix accepted in crash-utility][8] - - - -Unless these changes are made in userspace applications, they will remain broken for debugging running/live kernels or analyzing the vmcore dump from a crashing system. - -### 52-bit userspace VAs - -To maintain compatibility with userspace applications that rely on the ARMv8.0 VA space maximum size of 48 bits, the kernel will, by default, return virtual addresses to userspace from a 48-bit range. - -Userspace applications can "opt-in" to receiving VAs from a 52-bit space by specifying an mmap hint parameter larger than 48 bits. - -For example: - - -``` -.mmap_high_addr.c -\---- - -   maybe_high_address = mmap(~0UL, size, prot, flags,...); -``` - -It is also possible to build a debug kernel that returns addresses from a 52-bit space by enabling the following kernel config options: - - -``` -`   CONFIG_EXPERT=y && CONFIG_ARM64_FORCE_52BIT=y` -``` - -_Note that this option is only intended for debugging applications and should **not** be used in production._ - -### Conclusions - -To summarize: - - 1. Starting with Linux kernel version 5.14, the new Armv8.2 hardware extensions LVA and LPA are now well-supported in the Linux kernel. - 2. Userspace applications like kexec-tools and makedumpfile used for debugging the kernel are broken _right now_ and awaiting acceptance of upstream fixes. - 3. Legacy userspace applications that rely on Arm64 kernel providing it a 48-bit VA will continue working as-is, whereas newer userspace applications can "opt-in" to receiving VAs from a 52-bit space by specifying an mmap hint parameter that is larger than 48 bits. - - - -* * * - -_This article draws on [Memory Layout on AArch64 Linux][9] and [Linux kernel documentation v5.9.12][10]. Both are licensed under GPLv2.0._ - --------------------------------------------------------------------------------- - -via: https://opensource.com/article/20/12/52-bit-arm64-kernel - -作者：[Bhupesh Sharma][a] -选题：[lujun9972][b] -译者：[萌新阿岩](https://github.com/mengxinayan) -校对：[校对者ID](https://github.com/校对者ID) - -本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 - -[a]: https://opensource.com/users/bhsharma -[b]: https://github.com/lujun9972 -[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/puzzle_computer_solve_fix_tool.png?itok=U0pH1uwj (Puzzle pieces coming together to form a computer screen) -[2]: https://lwn.net/Articles/716916/ -[3]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm64/memory.rst -[4]: https://developer.arm.com/documentation/ddi0487/latest/ -[5]: https://opensource.com/sites/default/files/arm64-multi-level-translation_0.png (arm64 Multi-level Translation) -[6]: http://lists.infradead.org/pipermail/kexec/2020-September/021372.html -[7]: http://lists.infradead.org/pipermail/kexec/2020-September/021333.html -[8]: https://github.com/crash-utility/crash/commit/1c45cea02df7f947b4296c1dcaefa1024235ef10 -[9]: https://www.kernel.org/doc/html/latest/arm64/memory.html -[10]: https://elixir.bootlin.com/linux/latest/source/arch/arm64/include/asm/memory.h diff --git a/sources/tech/20210120 Why keeping a journal improves productivity.md b/sources/tech/20210120 Why keeping a journal improves productivity.md deleted file mode 100644 index 00704a40cf..0000000000 --- a/sources/tech/20210120 Why keeping a journal improves productivity.md +++ /dev/null @@ -1,69 +0,0 @@ -[#]: collector: (lujun9972) -[#]: translator: (geekpi) -[#]: reviewer: ( ) -[#]: publisher: ( ) -[#]: url: ( ) -[#]: subject: (Why keeping a journal improves productivity) -[#]: via: (https://opensource.com/article/21/1/open-source-journal) -[#]: author: (Kevin Sonney https://opensource.com/users/ksonney) - -Why keeping a journal improves productivity -====== -Journaling has a long history. Here are three open source tools to help -make your journaling life a little easier. -![Note taking hand writing][1] - -In previous years, this annual series covered individual apps. This year, we are looking at all-in-one solutions in addition to strategies to help in 2021. Welcome to day 10 of 21 Days of Productivity in 2021. - -When I was in primary school in the days before the commercial internet, teachers would often give my class an assignment to keep a journal. Sometimes it was targeted at something particular, like a specifically formatted list of bugs and descriptions or a weekly news article summary for a civics class. - -People have been keeping journals for centuries. They are a handy way of storing information. They come in many forms, like the Italian [Zibaldone][2], [Commonplace Books][3], or a diary of events that logs what got done today. - -![Notebook folders][4] - -(Kevin Sonney, [CC BY-SA 4.0][5]) - -Why should we keep a journal of some sort? The first reason is so that we aren't keeping everything in our heads. Not many of us have an [Eidetic memory][6], and maintaining a running log or set of notes makes it easier to reference something we did before. Journals are also easier to share since they can be copy/pasted in chat, email, and so on. "Knowledge is Power. Knowledge shared is Power Multiplied," as [Robert Boyce][7] famously said, and the sharing of knowledge is an intrinsic part of Open Source. - -![Today's journal][8] - -Today's journal (Kevin Sonney, [CC BY-SA 4.0][5]) - -One of the critical points when journaling events is to make it fast, simple, and easy. The easiest way is to open a document, add a line with the current date and the note, and save. - -Several programs or add-ons are available to make this easier. [The GNote Note of the Day Plugin][9] automatically creates a note titled with the date and can be used to store content for just that day. - -Emacs Org has a hotkey combination to "capture" things and put them into a document. Combined with the [org-journal][10] add-on, this will create entries in a document for the day it was created. - -The KNotes component of Kontact automatically adds the date and time to new notes. - -![Finding a note][11] - -Finding a note (Kevin Sonney, [CC BY-SA 4.0][5]) - -Keeping a journal or record of things is a handy way of keeping track of what and how something was done. And it can be useful for more than just "I did this" - it can also include a list of books read, foods eaten, places visited, and a whole host of information that is often useful in the future. - --------------------------------------------------------------------------------- - -via: https://opensource.com/article/21/1/open-source-journal - -作者：[Kevin Sonney][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/ksonney -[b]: https://github.com/lujun9972 -[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/note-taking.jpeg?itok=fiF5EBEb (Note taking hand writing) -[2]: https://en.wikipedia.org/wiki/Zibaldone -[3]: https://en.wikipedia.org/wiki/Commonplace_book -[4]: https://opensource.com/sites/default/files/pictures/day10-image1.png (Notebook folders) -[5]: https://creativecommons.org/licenses/by-sa/4.0/ -[6]: https://en.wikipedia.org/wiki/Eidetic_memory -[7]: https://en.wikipedia.org/wiki/Robert_Boyce -[8]: https://opensource.com/sites/default/files/pictures/day10-image2.png (Today's journal) -[9]: https://help.gnome.org/users/gnote/unstable/addin-noteoftheday.html.en -[10]: https://github.com/bastibe/org-journal -[11]: https://opensource.com/sites/default/files/pictures/day10-image3.png (Finding a note) diff --git a/sources/tech/20210121 How Nextcloud is the ultimate open source productivity suite.md b/sources/tech/20210121 How Nextcloud is the ultimate open source productivity suite.md index 923e8d513b..936901907e 100644 --- a/sources/tech/20210121 How Nextcloud is the ultimate open source productivity suite.md +++ b/sources/tech/20210121 How Nextcloud is the ultimate open source productivity suite.md @@ -1,5 +1,5 @@ [#]: collector: (lujun9972) -[#]: translator: ( ) +[#]: translator: (geekpi) [#]: reviewer: ( ) [#]: publisher: ( ) [#]: url: ( ) diff --git a/sources/tech/20210124 3 stress-free steps to tackling your task list.md b/sources/tech/20210124 3 stress-free steps to tackling your task list.md new file mode 100644 index 0000000000..04e65e4b06 --- /dev/null +++ b/sources/tech/20210124 3 stress-free steps to tackling your task list.md @@ -0,0 +1,70 @@ +[#]: collector: (lujun9972) +[#]: translator: ( ) +[#]: reviewer: ( ) +[#]: publisher: ( ) +[#]: url: ( ) +[#]: subject: (3 stress-free steps to tackling your task list) +[#]: via: (https://opensource.com/article/21/1/break-down-tasks) +[#]: author: (Kevin Sonney https://opensource.com/users/ksonney) + +3 stress-free steps to tackling your task list +====== +Break your larger tasks into small steps to keep from being overwhelmed. +![Team checklist][1] + +In prior years, this annual series covered individual apps. This year, we are looking at all-in-one solutions in addition to strategies to help in 2021. Welcome to day 14 of 21 Days of Productivity in 2021. + +At the start of the week, I like to review my schedule and look at the things I either need or would like to accomplish. And often, there are some items on that list that are relatively big. Whether it is an issue for work, a series of articles on productivity, or maybe an improvement to the chicken enclosures, the task can seem really daunting when taken as a single job. The odds are good that I will not be able to sit down and finish something like (just as an example, mind you) 21 articles in a single block of time, or even a single day. + +![21 Days of Productivity project screenshot][2] + +21 Days of Productivity (Kevin Sonney, [CC BY-SA 4.0][3]) + +So the first thing I do when I have something like this on my list is to break it down into smaller pieces. As Nobel laureate [William Faulkner][4] famously said, "The man who removes a mountain begins by carrying away small stones." We need to take our big tasks (the mountain) and find the individual steps (the small stones) that need to be done. + +I use the following steps to break down my big tasks into little ones: + + 1. I usually have a fair idea of what needs to be done to complete a task. If not, I do a little research to figure that out. + 2. I write down the steps I think it will take, in order. + 3. Finally, I sit down with my calendar and the list and start to spread the tasks out across several days (or weeks, or months) to get an idea of when I might finish it. + + + +Now I have not only a plan but an idea of how long it is going to take. As I complete each step, I can see that big task get not only a little smaller but closer to completion. + +There is an old military saying that goes, "No plan survives contact with the enemy." It is almost certain that there will be a point or two (or five) where I realize that something as simple as "take a screenshot" needs to be expanded into something _much_ more complex. In fact, taking the screenshots of [Easy!Appointments][5] turned out to be: + + 1. Install and configure Easy!Appointments. + 2. Install and configure the Easy!Appointments WordPress plugin. + 3. Generate the API keys needed to sync the calendar. + 4. Take screenshots. + + + +Even then, I had to break these tasks down into smaller pieces—download the software, configure NGINX, validate the installs…you get the idea. And that's OK. A plan, or set of tasks, is not set in stone and can be changed as needed. + +![project completion pie chart][6] + +About 2/3 done for this year! (Kevin Sonney, [CC BY-SA 4.0][3]) + +This is a learned skill and will take some effort the first few times. Learning how to break big tasks into smaller steps allows you to track progress towards a goal or completion of something big without getting overwhelmed in the process. + +-------------------------------------------------------------------------------- + +via: https://opensource.com/article/21/1/break-down-tasks + +作者：[Kevin Sonney][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/ksonney +[b]: https://github.com/lujun9972 +[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/checklist_todo_clock_time_team.png?itok=1z528Q0y (Team checklist) +[2]: https://opensource.com/sites/default/files/day14-image1.png +[3]: https://creativecommons.org/licenses/by-sa/4.0/ +[4]: https://en.wikipedia.org/wiki/William_Faulkner +[5]: https://opensource.com/article/21/1/open-source-scheduler +[6]: https://opensource.com/sites/default/files/day14-image2_1.png diff --git a/translated/tech/20190215 Make websites more readable with a shell script.md b/translated/tech/20190215 Make websites more readable with a shell script.md deleted file mode 100644 index 68a69cca65..0000000000 --- a/translated/tech/20190215 Make websites more readable with a shell script.md +++ /dev/null @@ -1,256 +0,0 @@ -[#]: collector: (lujun9972) -[#]: translator: (stevenzdg988) -[#]: reviewer: ( ) -[#]: publisher: ( ) -[#]: url: ( ) -[#]: subject: (Make websites more readable with a shell script) -[#]: via: (https://opensource.com/article/19/2/make-websites-more-readable-shell-script) -[#]: author: (Jim Hall https://opensource.com/users/jim-hall) - -利用 Shell 脚本让网站更具可读性 - -====== - -测算对比网站文本和背景之间的对比度，以确保站点易于阅读。 - -![](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/talk_chat_team_mobile_desktop.png?itok=d7sRtKfQ) - -如果希望人们发现你的网站实用，那么他们需要能够阅读它。为文本选择的颜色可能会影响网站的可读性。不幸的是，网页设计中的一种流行趋势是在打印输出文本时使用低对比度的颜色，就像在白色背景上的灰色文本。对于 Web 设计师来说，这也许看起来很酷，但对于许多阅读它的人来说确实很困难。 - -W3C 提供了 Web 内容可访问性指南，其中包括帮助 Web 设计人员选择易于区分文本和背景色的指南。称为“对比度”。 W3C 定义的对比度需要进行一些计算：给定两种颜色，首先计算每种颜色的相对亮度，然后计算对比度。对比度在 1 到 21 的范围内（通常写为1：1到21：1）。对比度越高，文本在背景下的突出程度就越高。例如，白色背景上的黑色文本非常醒目，对比度为 21：1。对比度为 1：1 的白色背景上的白色文本不可读。 - -[W3C 说文本显示][1] 的对比度至少应为 4.5：1，标题至少应为 3：1。但这似乎是最低要求。 W3C 还建议正文至少 7：1，标题至少 4.5：1。 - -计算对比度可能比较麻烦，因此最好将其自动化。我已经用这个方便的 Bash 脚本做到了这一点。通常，脚本执行以下操作： - - 1. 获取文本颜色和背景颜色 - 2. 计算相对亮度 - 3. 计算对比度 - - -### 获取颜色 - -你可能知道显示器上的每种颜色都可以用红色，绿色和蓝色（R，G 和 B）表示。要计算颜色的相对亮度，脚本需要知道颜色的红，绿和蓝的各个分量。理想情况下，脚本会将这些信息读取为单独的 R，G 和 B 值。 Web 设计人员可能知道他们喜欢的颜色的特定 RGB 代码，但是大多数人不知道不同颜色的 RGB 值。作为一种替代的方法是，大多数人通过 “红色” 或 “金色” 或 “栗色” 之类的名称来引用颜色。 - -幸运的是，GNOME [Zenity][2] 工具有一个颜色选择器应用程序，可让您使用不同的方法选择颜色，然后用可预测的格式“rgb（**R**，**G**，**B**）” 返回 RGB 值。使用 Zenity 可以轻松获得颜色值： - -``` -color=$( zenity --title 'Set text color' --color-selection --color='black' ) -``` - -如果用户（意外地）单击 “Cancel（取消）” 按钮，脚本将采用一种颜色： - -``` -if [ $? -ne 0 ] ; then -        echo '** color canceled .. assume black' -        color='rgb(0,0,0)' -fi -``` - -我的脚本执行了类似的操作，将背景颜色值设置为 **$background**。 -### 计算相对亮度 - -一旦您在 **$color** 中设置了前景色，并在 **$background** 中设置了背景色，下一步就是计算每种颜色的相对亮度。 [W3C 提供算法][3] 用以计算颜色的相对亮度。 - ->对于 sRGB 色彩空间，一种颜色的相对亮度定义为 -> -> **L = 0.2126 core.md Dict.md lctt2014.md lctt2016.md lctt2018.md LICENSE published README.md scripts sources translated R + 0.7152 core.md Dict.md lctt2014.md lctt2016.md lctt2018.md LICENSE published README.md scripts sources translated G + 0.0722 core.md Dict.md lctt2014.md lctt2016.md lctt2018.md LICENSE published README.md scripts sources translated B** R，G 和 B 定义为: -> -> if RsRGB <= 0.03928 then R = RsRGB/12.92 -> else R = ((RsRGB+0.055)/1.055) ^ 2.4 -> -> if GsRGB <= 0.03928 then G = GsRGB/12.92 -> else G = ((GsRGB+0.055)/1.055) ^ 2.4 -> -> if BsRGB <= 0.03928 then B = BsRGB/12.92 -> else B = ((BsRGB+0.055)/1.055) ^ 2.4 -> -> RsRGB, GsRGB, 和 BsRGB 定义为： -> -> RsRGB = R8bit/255 -> -> GsRGB = G8bit/255 -> -> BsRGB = B8bit/255 - -由于 Zenity 以 “rgb（**R**，**G**，**B**）”的格式返回颜色值，因此脚本可以轻松拉取分隔开的 R，B 和 G 的值以计算相对亮度。 AWK 使用逗号作为字段分隔符（**-F,**），并使用 **substr()** 字符串函数从 “rgb(**R**，**G**，**B**)中提取所要的颜色值： - -``` -R=$( echo $color | awk -F, '{print substr($1,5)}' ) -G=$( echo $color | awk -F, '{print $2}' ) -B=$( echo $color | awk -F, '{n=length($3); print substr($3,1,n-1)}' ) -``` - -**(有关使用 AWK 提取和显示数据的更多信息，[获取 AWK 备忘表][4].)** - -最好使用 BC 计算器来计算最终的相对亮度。 BC 支持计算中所需的简单 `if-then-else`，这使得这一过程变得简单。 但是由于 BC 无法使用非整数指数直接计算乘幂，因此需要使用自然对数替代它做一些额外的数学运算： - -``` -echo "scale=4 -rsrgb=$R/255 -gsrgb=$G/255 -bsrgb=$B/255 -if ( rsrgb <= 0.03928 ) r = rsrgb/12.92 else r = e( 2.4 core.md Dict.md lctt2014.md lctt2016.md lctt2018.md LICENSE published README.md scripts sources translated l((rsrgb+0.055)/1.055) ) -if ( gsrgb <= 0.03928 ) g = gsrgb/12.92 else g = e( 2.4 core.md Dict.md lctt2014.md lctt2016.md lctt2018.md LICENSE published README.md scripts sources translated l((gsrgb+0.055)/1.055) ) -if ( bsrgb <= 0.03928 ) b = bsrgb/12.92 else b = e( 2.4 core.md Dict.md lctt2014.md lctt2016.md lctt2018.md LICENSE published README.md scripts sources translated l((bsrgb+0.055)/1.055) ) -0.2126 core.md Dict.md lctt2014.md lctt2016.md lctt2018.md LICENSE published README.md scripts sources translated r + 0.7152 core.md Dict.md lctt2014.md lctt2016.md lctt2018.md LICENSE published README.md scripts sources translated g + 0.0722 core.md Dict.md lctt2014.md lctt2016.md lctt2018.md LICENSE published README.md scripts sources translated b" | bc -l -``` - -这会将一些指令传递给 BC，包括作为相对亮度公式一部分的 `if-then-else` 语句。接下来 BC 打印出最终值。 -### 计算对比度 - -利用文本颜色和背景颜色的相对亮度，脚本就可以计算对比度了。 [W3C 确定对比度][5] 使用以下公式： - -> (L1 + 0.05) / (L2 + 0.05), 这里的 -> L1是颜色较浅的相对亮度, -> L2是颜色较深的相对亮度 - -给定两个相对亮度值 **$r1** 和 **$r2**，使用 BC 计算器很容易计算对比度： - -``` -echo "scale=2 -if ( $r1 > $r2 ) { l1=$r1; l2=$r2 } else { l1=$r2; l2=$r1 } -(l1 + 0.05) / (l2 + 0.05)" | bc -``` - -使用 `if-then-else` 语句确定哪个值（**$r1** 或 **$r2**）是较浅还是较深的颜色。 BC 执行结果计算并打印结果，脚本可以将其存储在变量中。 - -### 最终脚本 - -通过以上内容，我们可以将所有内容整合到一个最终脚本。 我使用 Zenity 在文本框中显示最终结果： - -``` -#!/bin/sh -# script to calculate contrast ratio of colors - -# read color and background color: -# zenity returns values like 'rgb(255,140,0)' and 'rgb(255,255,255)' - -color=$( zenity --title 'Set text color' --color-selection --color='black' ) -if [ $? -ne 0 ] ; then -        echo '** color canceled .. assume black' -        color='rgb(0,0,0)' -fi - -background=$( zenity --title 'Set background color' --color-selection --color='white' ) -if [ $? -ne 0 ] ; then -        echo '** background canceled .. assume white' -        background='rgb(255,255,255)' -fi - -# compute relative luminance: - -function luminance() -{ -        R=$( echo $1 | awk -F, '{print substr($1,5)}' ) -        G=$( echo $1 | awk -F, '{print $2}' ) -        B=$( echo $1 | awk -F, '{n=length($3); print substr($3,1,n-1)}' ) - -        echo "scale=4 -rsrgb=$R/255 -gsrgb=$G/255 -bsrgb=$B/255 -if ( rsrgb <= 0.03928 ) r = rsrgb/12.92 else r = e( 2.4 core.md Dict.md lctt2014.md lctt2016.md lctt2018.md LICENSE published README.md scripts sources translated l((rsrgb+0.055)/1.055) ) -if ( gsrgb <= 0.03928 ) g = gsrgb/12.92 else g = e( 2.4 core.md Dict.md lctt2014.md lctt2016.md lctt2018.md LICENSE published README.md scripts sources translated l((gsrgb+0.055)/1.055) ) -if ( bsrgb <= 0.03928 ) b = bsrgb/12.92 else b = e( 2.4 core.md Dict.md lctt2014.md lctt2016.md lctt2018.md LICENSE published README.md scripts sources translated l((bsrgb+0.055)/1.055) ) -0.2126 core.md Dict.md lctt2014.md lctt2016.md lctt2018.md LICENSE published README.md scripts sources translated r + 0.7152 core.md Dict.md lctt2014.md lctt2016.md lctt2018.md LICENSE published README.md scripts sources translated g + 0.0722 core.md Dict.md lctt2014.md lctt2016.md lctt2018.md LICENSE published README.md scripts sources translated b" | bc -l -} - -lum1=$( luminance $color ) -lum2=$( luminance $background ) - -# compute contrast - -function contrast() -{ -        echo "scale=2 -if ( $1 > $2 ) { l1=$1; l2=$2 } else { l1=$2; l2=$1 } -(l1 + 0.05) / (l2 + 0.05)" | bc -} - -rel=$( contrast $lum1 $lum2 ) - -# print results - -( cat<