/dev/ttyS3 Blog

Fedora Linux CPU Frequency Scaling using cpupower

ttyS3 — Sat, 23 Mar 2024 04:10:56 GMT

命令行方式1 -- 不依赖外部工具

查看当前生效的 scaling_driver

cat /sys/devices/system/cpu/cpufreq/policy*/scaling_driver

查看当前生效的 scaling_governor

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

查看可用的 scaling_governor

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

设置为高性能模式

对于台式机来说，我觉得没有什么理由不设置为 performance 模式

echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

设置为节能模式

echo powersave | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

查看其它信息：

❯ /bin/ls -1 /sys/devices/system/cpu/cpu0/cpufreq/
affected_cpus
base_frequency
cpuinfo_max_freq
cpuinfo_min_freq
cpuinfo_transition_latency
energy_performance_available_preferences
energy_performance_preference
related_cpus
scaling_available_governors
scaling_cur_freq
scaling_driver
scaling_governor
scaling_max_freq
scaling_min_freq
scaling_setspeed

比如查看当前频率我们读取 scaling_cur_freq 这个文件即可:

watch cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq

Scaling governors 的具体含义

Scaling governors are power schemes determining the desired frequency for the CPU. Some request a constant frequency, while others implement algorithms to dynamically adjust according to the system load. The governors included in the kernel are:

Note: Each governor is compatible with any scaling driver, except for intel_pstate and amd_pstate in active mode. These provide pseudo-governors in the form of powersave and performance. See Autonomous frequency scaling.

Governor	Description
performance	Run the CPU at the maximum frequency, obtained from `/sys/devices/system/cpu/cpuX/cpufreq/scaling_max_freq`.
powersave	Run the CPU at the minimum frequency, obtained from `/sys/devices/system/cpu/cpuX/cpufreq/scaling_min_freq`.
userspace	Run the CPU at user-specified frequencies, configurable via `/sys/devices/system/cpu/cpuX/cpufreq/scaling_setspeed`.
ondemand	Scales the frequency dynamically according to current load. Jumps to the highest frequency and then possibly backs off as the idle time increases.
conservative	Scales the frequency dynamically according to current load. It does so more gradually than ondemand.
schedutil	Scheduler-driven CPU frequency selection source, [email protected]/">source.

命令行方式2 -- cpupower

cpupower 命令在 Fedora 里面由 kernel-tools 包提供，如果没有你需要安装一下：

sudo dnf install -y kernel-tools

查看当前状态:

sudo cpupower frequency-info

直接设置 CPU 工作在特定频率:

cpupower frequency-set -f clock_freq

设置为 performance 模式

cpupower frequency-set -g performance

目前 Fedora 不再提供 cpupower.service 了，这里从 Arch 抄一个：

[Unit]
Description=Apply cpupower configuration
ConditionVirtualization=!container

[Service]
Type=oneshot
EnvironmentFile=/etc/default/cpupower
ExecStart=/usr/bin/cpupower $CPUPOWER_ARGS
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

/etc/default/cpupower 内容如下：

CPUPOWER_ARGS="frequency-set -g performance"

sudo systemctl enable --now cpupower
sudo systemctl status cpupower
sudo cpupower frequency-info

命令行方式3 -- powerprofilesctl

powerprofilesctl 命令由 power-profiles-daemon 包提供。

https://gitlab.freedesktop.org/upower/power-profiles-daemon/-/blob/main/README.md

https://fedoraproject.org/wiki/Changes/Power_Profiles_Daemon

它主要是通过 DBus 与 power-profiles-daemon.service 起来的 power-profiles-daemon 进程通信.

❯ powerprofilesctl                 
* performance:
    CpuDriver:	intel_pstate
    Degraded:   no

  balanced:
    CpuDriver:	intel_pstate
    PlatformDriver:	placeholder

  power-saver:
    CpuDriver:	intel_pstate
    PlatformDriver:	placeholder

❯ powerprofilesctl get   
performance

misc

kernel-tools 里的其它命令

kernel-tools 这个包里除了cpupower 命令，还有一些其它实用工具：

❯ rpm -qlv kernel-tools | rg /usr/bin
-rwxr-xr-x    1 root     root     14696 Mar  6 08:00 /usr/bin/centrino-decode
-rwxr-xr-x    1 root     root     78592 Mar  6 08:00 /usr/bin/cpupower
-rwxr-xr-x    1 root     root     18792 Mar  6 08:00 /usr/bin/gpio-event-mon
-rwxr-xr-x    1 root     root     14696 Mar  6 08:00 /usr/bin/gpio-hammer
-rwxr-xr-x    1 root     root     14696 Mar  6 08:00 /usr/bin/gpio-watch
-rwxr-xr-x    1 root     root     31096 Mar  6 08:00 /usr/bin/iio_event_monitor
-rwxr-xr-x    1 root     root     35192 Mar  6 08:00 /usr/bin/iio_generic_buffer
-rwxr-xr-x    1 root     root    123792 Mar  6 08:00 /usr/bin/intel-speed-select
-rwxr-xr-x    1 root     root     64461 Mar  6 08:00 /usr/bin/kvm_stat
-rwxr-xr-x    1 root     root     14880 Mar  6 08:00 /usr/bin/lsgpio
-rwxr-xr-x    1 root     root     22904 Mar  6 08:00 /usr/bin/lsiio
-rwxr-xr-x    1 root     root     26984 Mar  6 08:00 /usr/bin/page_owner_sort
-rwxr-xr-x    1 root     root     14704 Mar  6 08:00 /usr/bin/powernow-k8-decode
-rwxr-xr-x    1 root     root     44224 Mar  6 08:00 /usr/bin/slabinfo
-rwxr-xr-x    1 root     root     43736 Mar  6 08:00 /usr/bin/tmon
-rwxr-xr-x    1 root     root    132920 Mar  6 08:00 /usr/bin/turbostat
-rwxr-xr-x    1 root     root     39896 Mar  6 08:00 /usr/bin/x86_energy_perf_policy

Fedora 这个包里并没有包含 cpupower.service

不过它带了一个 /usr/lib/systemd/system/kvm_stat.service

Service that logs KVM kernel module trace events

/usr/bin/kvm_stat -dtcz -s 10 -L /var/log/kvm_stat.csv

看上去是把 kvm 内核模块的状态信息输出到 csv 文件。并且还带了相应的 logrotate 配置文件 /etc/logrotate.d/kvm_stat

intel_pstate

The newer kernel version is using the intel_pstate as the default driver. which is only supported governor performance and powersave.

In order to use the governor ondemand, you need to disable the intel_pstate driver and using the acpi-cpufreq driver as default.

Edit the grub configuration.

sudo nvim /etc/default/grub

Add the following configuration.

GRUB_CMDLINE_LINUX_DEFAULT="intel_pstate=disable"

Regenerate your grub.

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Now the intel_pstate driver will be disabled, and the acpi_cpufreq will be enabled by default.

内核文档： https://docs.kernel.org/admin-guide/pm/intel_pstate.html

intel_pstate is not modular, so it cannot be unloaded, which means that the only way to pass early-configuration-time parameters to it is via the kernel command line. However, its configuration can be adjusted via sysfs to a great extent. In some configurations it even is possible to unregister it via sysfs which allows another CPUFreq scaling driver to be loaded and registered (see below).

不过，我应该大概率用不到 ondemand 模式。

refs

How to make a CPU governor change permanent?

How-to Increasing performance by changing CPU governor and reducing swappiness

ArchLinux WIKI: CPU frequency scaling

Note: Fedora CPU Frequency Scaling using cpupower

https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/pm/intel_pstate.rst

https://www.kernel.org/doc/Documentation/cpu-freq/intel-pstate.txt

https://www.kernel.org/doc/html/v6.8/admin-guide/pm/intel_pstate.html

https://events.static.linuxfound.org/sites/events/files/slides/LinuxConEurope_2015.pdf

Github is Leaking Your Commit Timezone

ttyS3 — Thu, 16 Nov 2023 16:52:40 GMT

之前有一用一个 Chrome 插件优化 Github UI 体验的，叫 refined-github

当然现在我已经没有使用了，主要是由于 Github UI 更新太快，有时候它追不太上。容易导致一些奇怪的 UI问题。

它有一个神奇的功能是，你访问他人的 github profile, 或者，鼠标悬浮在某人头像上时，它会显示出这个用户是在哪个时区，此时此刻他是几点。

后面我发现，它其实是通过 github restful api 去获取仓库的 commit log 信息，然后找到最近的一条是作者本人提交的 commit, 通过 git 本身记录的原 commit log 里的时区，就能知道作者的真正所在时区了。

时区信息是如何获取到的？

但是你如果直接通过 github ui 去访问一个commit , github 总是给你转换成了你当地的时区显示的，因此看不出来。比如 https://github.com/refined-github/refined-github/commit/d3e49584cd0f943d7ad1102290ae682f53ee4e97

比如通过这个 api: https://docs.github.com/en/rest/commits/commits?apiVersion=2022-11-28 是不行的。

通过这个 api 你拿到的还是github转换后的 UTC 时区的时间。

怎么样拿到本地时区呢？

我们看下这个插件是怎么做的。

它先访问用户的 events, 比如:

curl 'https://api.github.com/users/DerTimonius/events' \
  -H 'authority: api.github.com' \
  -H 'accept: application/vnd.github.v3+json' \
  -H 'accept-language: en-US' \
  -H 'cache-control: no-cache' \
  -H 'dnt: 1' \
  -H 'origin: https://github.com' \
  -H 'pragma: no-cache' \
  -H 'referer: https://github.com/refined-github/refined-github/commits/main' \
  -H 'user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36 Edg/119.0.0.0'

然后就能拿到最近的一些公开的提交事件，里面会有 commit url:

{
      "repository_id": 719513204,
      "push_id": 15847598750,
      "size": 1,
      "distinct_size": 1,
      "ref": "refs/heads/main",
      "head": "a27d4e5d855d446e942ce40d03082c2e9ba9964e",
      "before": "69eebb7556084c6e2f33d67b3bea599c80ffac08",
      "commits": [
        {
          "sha": "a27d4e5d855d446e942ce40d03082c2e9ba9964e",
          "author": {
            "email": "[email protected]",
            "name": "Timon Jurschitsch"
          },
          "message": "up to chapter 10",
          "distinct": true,
          "url": "https://api.github.com/repos/DerTimonius/next-14-learn/commits/a27d4e5d855d446e942ce40d03082c2e9ba9964e"
        }
      ]
    }

比如这里我们拿到了 https://api.github.com/repos/DerTimonius/next-14-learn/commits/a27d4e5d855d446e942ce40d03082c2e9ba9964e

然后再请求 commit 详情接口：

curl 'https://api.github.com/repos/DerTimonius/next-14-learn/commits/a27d4e5d855d446e942ce40d03082c2e9ba9964e' \
  -H 'authority: api.github.com' \
  -H 'accept: application/vnd.github.v3+json' \
  -H 'accept-language: en-US' \
  -H 'cache-control: no-cache' \
  -H 'dnt: 1' \
  -H 'origin: https://github.com' \
  -H 'pragma: no-cache' \
  -H 'referer: https://github.com/refined-github/refined-github/commits/main' \
  -H 'user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36 Edg/119.0.0.0'

然后这里其实还是格式化成了 UTC 时区。嗯， Github 还是比较讲究的。

但是接下来，这个插件又请求了：

curl 'https://api.github.com/repos/DerTimonius/next-14-learn/commits/a27d4e5d855d446e942ce40d03082c2e9ba9964e' \
  -H 'authority: api.github.com' \
  -H 'accept: application/vnd.github.v3.patch' \
  -H 'accept-language: en-US' \
  -H 'cache-control: no-cache' \
  -H 'dnt: 1' \
  -H 'origin: https://github.com' \
  -H 'pragma: no-cache' \
  -H 'referer: https://github.com/refined-github/refined-github/commits/main' \
  -H 'user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36 Edg/119.0.0.0'

没错，请求的 url 一样，但是 accept 头变成了 application/vnd.github.v3.patch

嗯，这应该是拿到原始时区的唯一方式了。

From a27d4e5d855d446e942ce40d03082c2e9ba9964e Mon Sep 17 00:00:00 2001
From: Timon Jurschitsch <[email protected]>
Date: Thu, 16 Nov 2023 12:29:39 +0100
Subject: [PATCH] up to chapter 10

---
 app/dashboard/(overview)/loading.tsx |  5 +++++
 app/dashboard/(overview)/page.tsx    | 33 ++++++++++++++++++++++++++++
 app/dashboard/page.tsx               |  3 ---
 app/lib/data.ts                      | 25 +++++++++++++++++----
 app/ui/dashboard/cards.tsx           | 15 +++++++++----
 app/ui/dashboard/latest-invoices.tsx | 18 +++++++--------
 app/ui/dashboard/revenue-chart.tsx   | 24 ++++++++++----------
 app/ui/invoices/table.tsx            | 10 +++++----
 package.json                         |  7 ++++--
 pnpm-lock.yaml                       |  2 +-
 10 files changed, 102 insertions(+), 40 deletions(-)
 create mode 100644 app/dashboard/(overview)/loading.tsx
 create mode 100644 app/dashboard/(overview)/page.tsx
 delete mode 100644 app/dashboard/page.tsx

然后我们看 Date: Thu, 16 Nov 2023 12:29:39 +0100 这里，原始的时区就出来了。

如何避免时区泄露?

已经存在的仓库，当然没得救了。后面的提交至少可以挽回一下吧。

方法就是使用 git alias, 原来你用 git commit 提交，现在只需要换成 git ci 即可（为什么喜欢叫 ci? 从 svn 时代就习惯了吧）

[alias]
	#ci = commit
	ci = "!f() { git commit --date=\"$(date --utc +%Y-%m-%dT%H:%M:%S%z)\" \"${@}\"; }; f"
	#cc = cz commit
	cc = "!f() { git cz commit -- --date=\"$(date --utc +%Y-%m-%dT%H:%M:%S%z)\" \"${@}\"; }; f"

Cross Compile Darwin Target Under Linux Troubleshooting

ttyS3 — Sat, 28 Oct 2023 12:04:58 GMT

之前为了方便解密客户端日志，我基于 https://github.com/Tencent/mars/tree/master/mars/xlog/crypt/decode_log_file_c_impl 写了个简单的命令行工具 xlog-decode。

这个工具很简单，就是支持递归地解密当前目录及其下所有的 xlog 文件（由于是公司项目，因此 xlog 文件的后缀是统一且固定的）。

如 foo/xxx.xlog 会自动解密在同级目录下，变成 foo/xxx.xlog.log

最近一次编译还是几年前，这不有童鞋需要我给他编译一个 Mac (Intel CPU版) 版的(ps: 我是 Linux 用户),于是有了这个文章。

原本，这应该也是一个一两分钟的活儿，不过最终折腾的结果是花了接近2个小时。

原来的 CMakeLists.txt 如下:

cmake_minimum_required (VERSION 3.0)
project (xlog-decode)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -O0 -ggdb")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -lz")

# for log
add_definitions(-DLOG_USE_COLOR)

add_definitions(-DBUILD_SHARED_LIBS=OFF)

# for zstd
# option(ZSTD_BUILD_STATIC "BUILD STATIC LIBRARIES" ON)
# option(ZSTD_BUILD_SHARED "BUILD SHARED LIBRARIES" OFF)

include(GNUInstallDirs)

add_executable(xlog-decode main.c log.c micro-ecc-master/uECC.c)
target_link_libraries(xlog-decode zstd z)

Makefile 主要是方便编译的脚本 (没错，当时我主力还是 ArchLinux, 还没怎么用 Fedora. paru! paru!):

build:
	cmake -B build .
	cd build && make

deps/arch:
	paru -S --needed zstd

deps/ubuntu:
	apt install -y make cmake g++ gcc zlib1g-dev zlib1g libzstd-dev libzstd1

install: build
	install -vD -m 755 build/xlog-decode /usr/local/bin/xlog-decode

clean:
	-rm -rf ./build

这两个文件都没啥问题。

然后我有一个 mac.sh 用于执行 Mac 交叉编译的：

mac.sh

#!/usr/bin/env bash

set -eou pipefail


# Don't forget to adjust this to your standalone toolchain path
export TOOLCHAIN_PATH=/usr/local/darwin-ndk-x86_64

# There should be no need to edit anything between this line and the next
# -----------------------------------------------------------------------
export CROSS_COMPILE=x86_64-apple-darwin22.2
export CROSS_PATH=${TOOLCHAIN_PATH}/bin
# Set the compiler and linker
export CPP=${CROSS_PATH}/${CROSS_COMPILE}-c++
export AR=${CROSS_PATH}/${CROSS_COMPILE}-ar
export AS=${CROSS_PATH}/${CROSS_COMPILE}-as
export NM=${CROSS_PATH}/${CROSS_COMPILE}-nm
export CC=${CROSS_PATH}/${CROSS_COMPILE}-cc
export CXX=${CROSS_PATH}/${CROSS_COMPILE}-c++
export LD=${CROSS_PATH}/${CROSS_COMPILE}-ld
export RANLIB=${CROSS_PATH}/${CROSS_COMPILE}-ranlib

export CFLAGS="-I/home/ttys3/repo/cpp/xlog-decode/zstd/lib"
export LDFLAGS="-L/usr/local/darwin-ndk-x86_64/lib -L/home/ttys3/repo/cpp/xlog-decode/zstd/lib"

export LD_LIBRARY_PATH=/usr/local/darwin-ndk-x86_64/lib:/home/ttys3/repo/cpp/xlog-decode/zstd/lib

make

toolchain 我也是已经安装好的，并且确定是工作的.

注: 这里有个 zstd 库是单独静态编译好的（因为要交叉编译，所以不能用动态链接，会很麻烦）

然后，其实这个脚本本身也是没啥问题的。

但是为什么编译报错了呢?

/usr/bin/ld: unknown option: -dynamic

为什么，明明已经指定了 export LD=${CROSS_PATH}/${CROSS_COMPILE}-ld, 但是 cmake 就是不用呢？

所以，编译失败的原因显然是， cmake 对于这个 LD env 的识别出现了破坏性的变更。不过都过了2年多了，咱也不常用 cmake 这玩意，也不知道它做了啥改变。

因此，足足折腾了近2个小时，才找到了一个朴素的修复方法:

ln -s /usr/local/darwin-ndk-x86_64/bin/x86_64-apple-darwin22.2-ld /usr/local/darwin-ndk-x86_64/bin/ld

没错，就是要把 x86_64-apple-darwin22.2-ld 链接为 ld, 这样， cmake 在生成 makefile 的时候，就自动用上了 apple toolchain 里的 ld 了。

结论:

if ld not exists, cmake will always try to use /usr/bin/ld, which will fuck you up

这个解决办法和思路来自： https://github.com/rust-lang/rust/issues/52657#issuecomment-407481607

另，由于当初图方便，在 main.c 里面内嵌了解密的密钥，因此这个仓库暂时是没有公开的。

如果有人有需要，后面有空我再整理开源吧。很多时候不开源，只是为了避免麻烦，因为涉及到安全和隐私，开源之前都是要再三检查所有 commit log, 这挺费时间的。

How to Send Desktop Notifications under Linux

ttyS3 — Thu, 19 Oct 2023 17:35:01 GMT

有这个文章是因为，曾经不小心看到了 Arch wiki 里有个神奇的页面，里面介绍了"回"字的X种写法

然后我在 C+ glib2 这种写法上面翻车了： https://wiki.archlinux.org/title/Desktop_notifications#C

完全按 wiki 来的：

Dependency: glib2 Build with:

gcc -o hello_world `pkg-config --cflags --libs gio-2.0` hello_world.c

hello_world.c

#include <gio/gio.h>
int main() {
	GApplication *application = g_application_new ("hello.world", G_APPLICATION_FLAGS_NONE);
	g_application_register (application, NULL, NULL);
	GNotification *notification = g_notification_new ("Hello world!");
	g_notification_set_body (notification, "This is an example notification.");
	GIcon *icon = g_themed_icon_new ("dialog-information");
	g_notification_set_icon (notification, icon);
	g_application_send_notification (application, NULL, notification);
	g_object_unref (icon);
	g_object_unref (notification);
	g_object_unref (application);
	return 0;
}

结果却非常意外，没有任何通知出现。

但是使用 notify-send hello 却是工作得很正常（后面发现使用 libnotify 或 dbus 的方式也都工作正常）。

当时也就放弃了。后面看到了文档：

Warning: gnome-shell uses desktop files to find extra information (app icon, name) about the sender of the notification. If you don't have a desktop file whose base name matches the application id, then your notification will not show up.

这个 GNOME 的旧文档，反而把事情说得比新文档明白通俗易懂一些。

新版本的文档是这样写的：

https://developer.gnome.org/documentation/tutorials/notifications.html#prerequisites

In order to use notifications in GNOME you will need to:

use GApplication or GtkApplication
provide a valid desktop file with the same name as your application id
ensure that your application can be activated via D-Bus

文档在第二点说明了这个问题。但是没有写得那么容易让人看懂。（如果不提供会发生什么？作为用户，完全不知道，如果这条不满足，通知会直接不显示）

好了，回到最开始的问题，由于新建 GNOME 应用的时候用的是 g_application_new ("hello.world", G_APPLICATION_FLAGS_NONE);, 因此, application id 为 hello.world, 所以，必须要存在一个名为 hello.world.desktop 的 desktop 文件, 里面至少要有 Name 和 Icon 等.

[Desktop Entry]
Name=GNotification Hello World
Exec=/usr/local/bin/hello.world %U
Icon=hello-world

然后你还要把 hello-world.png 的图标文件和 hello.world.desktop desktop 文件放在正确的位置.

这样这个通知才能发送出来.

refs

https://wiki.archlinux.org/title/Desktop_notifications

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5708

https://github.com/flatpak/xdg-desktop-portal-gtk/pull/394/files

关于 OpenZFS

ttyS3 — Thu, 05 Oct 2023 04:08:08 GMT

kernel modules

以 pve 8 (基于 debian 12) 为例，里面的 zfs 模块在 /lib/modules/$(uname -r)/zfs/ 目录。

root@pve:~# ls -lh /lib/modules/$(uname -r)/zfs/
total 4.1M
-rw-r--r-- 1 root root  569K Jun 17 13:58 icp.ko
-rw-r--r-- 1 root root  241K Jun 17 13:58 spl.ko
-rw-r--r-- 1 root root   29K Jun 17 13:58 zavl.ko
-rw-r--r-- 1 root root  215K Jun 17 13:58 zcommon.ko
-rw-r--r-- 1 root root  6.9M Jun 17 13:58 zfs.ko
-rw-r--r-- 1 root root  416K Jun 17 13:58 zlua.ko
-rw-r--r-- 1 root root  211K Jun 17 13:58 znvpair.ko
-rw-r--r-- 1 root root  373K Jun 17 13:58 zunicode.ko
-rw-r--r-- 1 root root 1007K Jun 17 13:58 zzstd.ko

root@pve:~# modinfo spl | grep -E 'author|description|license|filename'
filename:       /lib/modules/6.2.16-3-pve/zfs/spl.ko
license:        GPL
author:         OpenZFS
description:    Solaris Porting Layer

ls -1 /lib/modules/$(uname -r)/zfs/ | xargs -I'{}' basename '{}' .ko | xargs -I'{}' sh -c 'modinfo "{}" | grep -E "author|description|license|filename"; echo "-------------------------"'

filename:       /lib/modules/6.2.16-3-pve/zfs/icp.ko
license:        CDDL
author:         OpenZFS
-------------------------
filename:       /lib/modules/6.2.16-3-pve/zfs/spl.ko
license:        GPL
author:         OpenZFS
description:    Solaris Porting Layer
-------------------------
filename:       /lib/modules/6.2.16-3-pve/zfs/zavl.ko
license:        CDDL
author:         OpenZFS
description:    Generic AVL tree implementation
-------------------------
filename:       /lib/modules/6.2.16-3-pve/zfs/zcommon.ko
license:        CDDL
author:         OpenZFS
description:    Generic ZFS support
-------------------------
filename:       /lib/modules/6.2.16-3-pve/zfs/zfs.ko
license:        CDDL
author:         OpenZFS
description:    ZFS
-------------------------
filename:       /lib/modules/6.2.16-3-pve/zfs/zlua.ko
license:        Dual MIT/GPL
author:         Lua.org
description:    Lua Interpreter for ZFS
-------------------------
filename:       /lib/modules/6.2.16-3-pve/zfs/znvpair.ko
license:        CDDL
author:         OpenZFS
description:    Generic name/value pair implementation
-------------------------
filename:       /lib/modules/6.2.16-3-pve/zfs/zunicode.ko
license:        CDDL
author:         OpenZFS
description:    Unicode implementation
-------------------------
filename:       /lib/modules/6.2.16-3-pve/zfs/zzstd.ko
license:        Dual BSD/GPL
description:    ZSTD Compression for ZFS
-------------------------

OpenZFS 的 license 均为 CDDL

另外这个 zfs/spl.ko 模块引起了我的注意，描述为 Solaris Porting Layer ，似乎是个中间层的 porting 代码。

查看 https://openzfs.org/wiki/Reduce_code_differences 果然如此：

Reduce code differences Jump to navigationJump to search One of the technical goals of OpenZFS is to reduce code differences between the various platforms that support ZFS. To accomplish this, we will:
Create a "porting layer" to abstract out the platform-specific code. The "Solaris Porting Layer" (SPL) is a good start at this. We can improve it by moving illumos/Solaris-specific code out of the main files and into platform-specific files. Split the ZPL into platform-independent and platform-specific parts. Long-term, consider if we can create a common repository to use for platform-independent ZFS code, rather than treating illumos as the de facto upstream repository. Any code in this repo would need to be able to be tested in a platform-independent way (e.g. in userland using libzpool), so that changes tested on one platform can be expected to work on every platform. Code tested by ztest would be the first candidate for this. Userland ZFS ioctls would enable running /sbin/zfs and /sbin/zpool, and thus most of the TestRunner test suite against libzpool. See Platform code differences for specific information on areas of divergence.

由于 ZFS 是从 illumos/Solaris port 到 linux 的，而 ZFS 又不想因为 Linux 而改动其核心代码，因此就有了这个 "porting layer" 把 Linux 上没有的一些东西做兼容处理。

Flameshot troubleshooting

ttyS3 — Wed, 27 Sep 2023 18:13:18 GMT

使用 GNOME 自定义快捷键无法调起 flameshot gui

这个解决办法主要来自 https://github.com/flatpak/xdg-desktop-portal/issues/1070#issuecomment-1762884545

注意，这里比较奇怪的是，直接在 GNOME 自定义 key binding 里面的 command 写上 /usr/bin/env QT_QPA_PLATFORM=wayland flameshot gui 是不会工作的.

必须通过 shell 脚本执行。暂时不知道原因。

sudo tee /usr/local/bin/flameshot-gui-workaround > /dev/null <<'EOF'
#!/bin/bash
# workaround thanks to https://github.com/flatpak/xdg-desktop-portal/issues/1070#issuecomment-1762884545
env QT_QPA_PLATFORM=wayland flameshot gui

EOF

sudo chmod a+x /usr/local/bin/flameshot-gui-workaround

然后我们把原来配置的 GNOME 自定义 shortcut 的 command 从 flameshot gui 换成 /usr/local/bin/flameshot-gui-workaround :

点击 "Take Screenshot" 无法显示截图界面

如果观察系统日志，会发现类似：

xdg-desktop-por[848788]: Failed to show access dialog: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Only the focused app is allowed to show a system access dialog

解决办法是：

https://github.com/flameshot-org/flameshot/issues/2868#issuecomment-1312470098

Hi guys, I was going to add my 2 cents on how it doesn't work for me, but then I experimented a bit more and it started working.

OS: Fedora 37, Wayland, Gnome 43, Flameshot: 12.1.0 installed using dnf, xdg-desktop-portal-1.15.0-1.fc37

What I did to make it work:

Run flameshot Open flameshot's settings window(I also maximized the window to lower the chances of loosing focus of that window - probably not needed) Take a screenshot using flameshot - I clicked the tray icon that came from a gnome extension Permissions question should appear - grant it It should now work fine without asking for permissions next time you take a screenshot The same can be done for flameshot run from the terminal, or triggered by a keyboard shortcut. You need to run flameshot in the terminal instead of using gnome launcher, and repeat the above steps. In this case I don't know if it's the flameshot settings window that needs to be actively focused to trigger the permissions prompt. But it's one of those.

In summary, I can now run flameshot from the tray icon, from terminal, from the ALT+F2(gnome's run command tool) and it takes screenshots without asking for permissions.

点击 "Take Screenshot" 直接被拒绝

与前面说的 "GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Only the focused app is allowed to show a system access dialog" 错误不同，这次是直接被拒绝。出现这种情况，基本上是因为，在第一次弹出权限确认窗口的时候，你没有选择(直接按esc也相当于回答了no), 或者选择了 no, 后面就会直接拒绝了。

日志信息：

org.flameshot.Flameshot.desktop[887167]: flameshot: error: Unable to capture screen

这种情况下，我们已经没办法再让这个允许权限的窗口弹出来显示了。

好在万能的 github 用户也给出了解决办法： https://github.com/flameshot-org/flameshot/issues/2868#issuecomment-1384310540

先 dump 一下当前的配置：

import dbus
import json

bus = dbus.SessionBus()
perm = bus.get_object('org.freedesktop.impl.portal.PermissionStore', '/org/freedesktop/impl/portal/PermissionStore')
perm_iface = dbus.Interface(perm, dbus_interface='org.freedesktop.impl.portal.PermissionStore')

perm_iface.Lookup("screenshot", "screenshot")
print(json.dumps(perm_iface.Lookup("screenshot", "screenshot"), indent=4))

正常情况下，dump 成 json 后的结果应该类似：

[
    {
        "": [
            "yes"
        ],
        "kitty": [
            "yes"
        ],
        "org.flameshot.Flameshot": [
            "yes"
        ]
    },
    0
]

这里主要是检查是否存在 org.flameshot.Flameshot 并且值应该为 ["yes"].

比如这种情况就是之前拒绝过的情况（值为 no)：

>>> perm_iface.Lookup("screenshot", "screenshot")
(dbus.Dictionary({dbus.String(''): dbus.Array([dbus.String('yes')], signature=dbus.Signature('s')), dbus.String('org.flameshot.Flameshot'): dbus.Array([dbus.String('no')], signature=dbus.Signature('s'))}, signature=dbus.Signature('sas')), dbus.Byte(0, variant_level=1))

我们把它 set 回去成 yes:

perm_iface.Set("screenshot", dbus.Boolean(True), "screenshot", {"":["yes"], "org.flameshot.Flameshot": ["yes"]}, dbus.Byte(0x0))

>>> perm_iface.Lookup("screenshot", "screenshot")
(dbus.Dictionary({dbus.String(''): dbus.Array([dbus.String('yes')], signature=dbus.Signature('s')), dbus.String('org.flameshot.Flameshot'): dbus.Array([dbus.String('yes')], signature=dbus.Signature('s'))}, signature=dbus.Signature('sas')), dbus.Byte(0, variant_level=1))

"保存到文件" 无反应

不知道什么时候开始 flameshot 保存到文件的功能不工作了。也没报错。

今天抽空看了下。

找到了这个 issue https://github.com/flameshot-org/flameshot/issues/207

给了我灵感。

❯ cat ~/.config/flameshot/flameshot.ini
[General]
checkForUpdates=false
contrastOpacity=188
showStartupLaunchMessage=false

发现配置就这几行。但是明明 GUI 配置界面显示了保存路径是 /home/ttys3/Pictures/Screenshots 啊？

重新进入 general 配置，发现有一个 Prefered save file extension 没有值，于是随手选了一个 avif 格式，然后再看文件配置，发现已经有保存路径的配置了：

saveAsFileExtension=avif
savePath=/home/ttys3/Pictures/Screenshots
savePathFixed=true

然后再测试保存到文件的功能，也 OK 了. 看来就是 saveAsFileExtension 为空导致文本配置并没有保存成功。问题是它没取到 savePath 居然不报错。

refs

Taking screenshots with Java under Wayland https://adangel.org/2022/02/06/java-screenshot/

https://flameshot.org/docs/guide/wayland-help/#i-am-asked-to-share-my-screen-every-time

https://github.com/flameshot-org/flameshot/issues/2868#issuecomment-1384310540

https://github.com/flameshot-org/flameshot/issues/3326

https://github.com/flatpak/xdg-desktop-portal/issues/1070#issuecomment-1771302632

flameshot 官方文档里的 troubleshooting 也是不错的参考

https://flameshot.org/docs/guide/troubleshooting/

https://flameshot.org/docs/guide/troubleshooting/#flameshot-icon-is-visible-in-tray-area-but-when-i-click-on-it-nothing-happens

First try the using the command flameshot gui in terminal. This does exactly what clicking on the tray icon does. (make sure can you see Flameshot icon in the tray area)

If the above step didn't work:

Open 3 terminals

Kill Flameshot if it is already open using pkill flameshot

In the first terminal run dbus-monitor --session sender=org.flameshot.Flameshot

In the second terminal run flameshot

In the third terminal run flameshot gui

fix Cloudflare cache + Next.js “Text content does not match server-rendered HTML”

ttyS3 — Sun, 23 Jul 2023 05:53:23 GMT

background

recently I migrated my Blog from Hugo to timlrx/tailwind-nextjs-starter-blog

I deploy the blog via Netlify and serve it via Cloudflare proxy.

how to see the problem

open browser console, you'll see errros like this:

4f0b14e9-f6a6045a21104f01.js:1  Uncaught Error: Minified React error #425; visit https://reactjs.org/docs/error-decoder.html?invariant=425 for the full message or use the non-minified dev environment for full errors and additional helpful warnings.
    at si (4f0b14e9-f6a6045a21104f01.js:1:140010)
    at tJ (4f0b14e9-f6a6045a21104f01.js:1:23531)
    at 4f0b14e9-f6a6045a21104f01.js:1:94483
    at oR (4f0b14e9-f6a6045a21104f01.js:1:98923)
    at oM (4f0b14e9-f6a6045a21104f01.js:1:90251)
    at 4f0b14e9-f6a6045a21104f01.js:1:86358
    at 4f0b14e9-f6a6045a21104f01.js:1:86365
    at oy (4f0b14e9-f6a6045a21104f01.js:1:86470)
    at E (629-498c73b757a747b0.js:1:94713)
    at MessagePort.C (629-498c73b757a747b0.js:1:95266)

what is "Uncaught Error: Minified React error #425" ?

according https://reactjs.org/docs/error-decoder.html?invariant=425

Error Decoder In the minified production build of React, we avoid sending down full error messages in order to reduce the number of bytes sent over the wire.

We highly recommend using the development build locally when debugging your app since it tracks additional debug info and provides helpful warnings about potential problems in your apps, but if you encounter an exception while using the production build, this page will reassemble the original text of the error.

The full text of the error you just encountered is:

Text content does not match server-rendered HTML.

note: Netlify blog also post an article about the "Text content does not match server-rendered HTML" issue, but our's problem is not the same like that one.

how I got the solution?

local run next build && next serve everything is fine.

go to Cloudflare site config: Caching -- Configuration

enable "Development Mode", everything is fine.

so it is a Cloudflare caching problem with Next.js

the solution

go to Cloudflare site config: Speed -- Optimization

switch to "Content Optimization" tab, then scroll down to "Auto Minify" and uncheck "HTML" checkbox.

for fast the cache expire progress, we can go to Cloudflare site config:

Caching -- Configuration -- Purge Cache and click "Purge Everything" button and confirm.

How to Export All Your Evernote Notes to Markdown

ttyS3 — Thu, 13 Jul 2023 11:03:46 GMT

evernote-backup

Quickly sync all your notes into the SQLite database for backup. Export all backed up notes in *.enex format, as notebooks or single notes.

pip install --user evernote-backup

Step 1. Database initialization

By default, it will prompt you to enter your account credentials. You can provide them beforehand with --user and --password options.

If you log in to Evernote with Google or Apple accounts, you must use the --oauth option.

To connect to Yinxiang instead of Evernote, use --backend china option. Unfortunately, OAuth is not supported for Yinxiang yet.

evernote-backup init-db --oauth

Step 2. Downloading Evernote data

evernote-backup sync

Step 3. Exporting *.enex files

By default, evernote-backup will export notes by packing them into notebooks, one *.enex file each. If you want to extract notes as separate files, use the --single-notes flag.

evernote-backup export --single-notes evernote-enex-backup/

Step 4. Convert it into markdown

https://github.com/akosbalasko/yarle

useHashTags should set to false to avoid tags get hash prefix like #tagname

markdown template:

---
{title-block}title: {title}{end-title-block}
{created-at-block}date: {created-at}{end-created-at-block}
{updated-at-block}lastmod: {updated-at}{end-updated-at-block}
{source-url-block}sourceurl: {source-url}{end-source-url-block}
{tags-array-block}
tags: {tags-array}
{end-tags-array-block}
---


<TOCInline toc={props.toc} asDisclosure />

{content-block}{content}{end-content-block}

Step 5. Choose an alternative

noteapps.info 笔记应用程序百科全书

无广告。没有营销。只有流行笔记应用的截图、功能列表和价格。

https://noteapps.info/

https://github.com/toeverything/AFFiNE

https://obsidian.md/

Blog 从 Hugo 迁移到 Tailwind Next.js Blog

ttyS3 — Mon, 10 Jul 2023 13:08:12 GMT

https://github.com/timlrx/tailwind-nextjs-starter-blog

https://github.com/timlrx/pliny

migration repo

git checkout -b hugo
git push origin hugo

git branch -D main
git checkout --orphan main

rm -rf ./*
rm -rf .forestry .gitignore .gitmodules

 cp -rav ~/repo/blog/nextjs-ttys3.dev/* .

 cp -rav ~/repo/blog/nextjs-ttys3.dev/.* .


 meld . ~/repo/blog/nextjs-ttys3.dev
 bcompare . ~/repo/blog/nextjs-ttys3.dev

 git remote add origin [email protected]:ttys3/ttys3.dev.git

 git push origin main -f

Guide to MDX

https://kabartolo.github.io/chicago-docs-demo/docs/mdx-guide/

build Failed

plugin "@netlify/plugin-nextjs" failed

Error: The directory "/opt/build/repo/public" does not contain a Next.js production build. Perhaps the build command was not run, or you specified the wrong publish directory. However, a '.next' directory was found with a production build. Consider changing your 'publish' directory to '.next' If you are using "next export" then you should set the environment variable NETLIFY_NEXT_PLUGIN_SKIP to "true".

Build configuration

Runtime Next.js

Build command npm run build

fixup:

change Publish directory public => Publish directory .next

troubleshoot

1. `.md` to `.mdx` rename

rnr -r -f '.md' '.mdx' .
rnr -r -f '.mdxx' '.mdx' .

2. markdown link compitable with MDX

❯ rg '<http(s)?://.+?>' -l | wc -l
70

neither Rust or Golang Regex engine support look around (look ahead or look after)

we need use a tool support PCRE like https://github.com/adamreisnz/replace-in-file

npm i -g replace-in-file

debug the Regex : https://regex101.com/r/9UPYQr/1

config.js content:

//config.js
module.exports = {
  files: './**/*.mdx',
  from: /(?<!\])<http(s)?:\/\/([^[\]]+?)>(?!\])/g,
  to: ' http\$1://\$2 ',
};

replace-in-file --configFile=config.js

remove not used frontmatter fields:

# check
rg '^slug:\s+[a-zA-Z_-]+' 

# delete
sed -E -i '/^slug:\s+[a-zA-Z_-]+/d' `rg -l slug`

3. null-safe join of tags

commit baab006f840d07fe5a1ea27a6c586a118d21870c
Author: ttyS3 <[email protected]>
Date:   2023-07-10 20:31:17 +0800

    chore: null-safe join of tags

diff --git a/layouts/ListLayout.tsx b/layouts/ListLayout.tsx
index fb967f7..7c94a9d 100644
--- a/layouts/ListLayout.tsx
+++ b/layouts/ListLayout.tsx
@@ -66,7 +66,7 @@ export default function ListLayout({
 }: ListLayoutProps) {
   const [searchValue, setSearchValue] = useState('')
   const filteredBlogPosts = posts.filter((post) => {
-    const searchContent = post.title + post.summary + post.tags.join(' ')
+    const searchContent = post.title + post.summary + (post.tags ?? []).join(' ')
     return searchContent.toLowerCase().includes(searchValue.toLowerCase())
   })

@@ -129,7 +129,7 @@ export default function ListLayout({
                         </Link>
                       </h3>
                       <div className="flex flex-wrap">
-                        {tags.map((tag) => (
+                        {(tags ?? []).map((tag) => (
                           <Tag key={tag} text={tag} />
                         ))}
                       </div>
diff --git a/layouts/PostLayout.tsx b/layouts/PostLayout.tsx
index 0562fd9..c5b165c 100644
--- a/layouts/PostLayout.tsx
+++ b/layouts/PostLayout.tsx
@@ -123,7 +123,7 @@ export default function PostLayout({ content, authorDetails, next, prev, childre
                       Tags
                     </h2>
                     <div className="flex flex-wrap">
-                      {tags.map((tag) => (
+                      {(tags ?? []).map((tag) => (
                         <Tag key={tag} text={tag} />
                       ))}
                     </div>
diff --git a/pages/index.tsx b/pages/index.tsx
index f8fafeb..c084f88 100644
--- a/pages/index.tsx
+++ b/pages/index.tsx
@@ -57,7 +57,7 @@ export default function Home({ posts }: InferGetStaticPropsType<typeof getStatic
                             </Link>
                           </h2>
                           <div className="flex flex-wrap">
-                            {tags.map((tag) => (
+                            {(tags ?? []).map((tag) => (
                               <Tag key={tag} text={tag} />
                             ))}
                           </div>
diff --git a/pages/tags/[tag].tsx b/pages/tags/[tag].tsx
index f939fc6..4437f40 100644
--- a/pages/tags/[tag].tsx
+++ b/pages/tags/[tag].tsx
@@ -23,7 +23,7 @@ export const getStaticProps = async (context) => {
   const tag = context.params.tag as string
   const filteredPosts = allCoreContent(
     allBlogs.filter(
-      (post) => post.draft !== true && post.tags.map((t) => kebabCase(t)).includes(tag)
+      (post) => post.draft !== true && (post.tags ?? []).map((t) => kebabCase(t)).includes(tag)
     )
   )

3. build problem

 ❯ npm run build

Failed to compile.

./pages/404.tsx
9:36  Error: Replace `t-6·pb-8` with `b-8·pt-6`  prettier/prettier

solution:

❯ npm run lint

> [email protected] lint
> next lint --fix --dir pages --dir components --dir lib --dir layouts --dir scripts

the fixup like:

diff --git a/pages/404.tsx b/pages/404.tsx
index 2bdf448..873137d 100644
--- a/pages/404.tsx
+++ b/pages/404.tsx
@@ -6,7 +6,7 @@ export default function FourZeroFour() {
     <>
       <PageSEO title="Page Not Found" description="Sorry we couldn't find this page :(" />
       <div className="flex flex-col items-start justify-start md:mt-24 md:flex-row md:items-center md:justify-center md:space-x-6">
-        <div className="space-x-2 pt-6 pb-8 md:space-y-5">
+        <div className="space-x-2 pb-8 pt-6 md:space-y-5">
           <h1 className="text-6xl font-extrabold leading-9 tracking-tight text-gray-900 dark:text-gray-100 md:border-r-2 md:px-6 md:text-8xl md:leading-14">
             404
           </h1>

empty tags still cause problem:

λ  (Server)  server-side renders at runtime (uses getInitialProps or getServerSideProps)
○  (Static)  automatically rendered as static HTML (uses no initial props)
●  (SSG)     automatically generated as static HTML + JSON (uses getStaticProps)

(node:825002) ExperimentalWarning: Importing JSON modules is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
RSS feed generated...
Sitemap generated...
file:///home/user001/repo/blog/ttys3.dev/node_modules/pliny/utils/generate-rss.js:43
        (post) => post.tags.map((t) => GithubSlugger.slug(t)).includes(tag)
                            ^

TypeError: Cannot read properties of undefined (reading 'map')
    at file:///home/user001/repo/blog/ttys3.dev/node_modules/pliny/utils/generate-rss.js:43:29
    at Array.filter (<anonymous>)
    at generateRSS (file:///home/user001/repo/blog/ttys3.dev/node_modules/pliny/utils/generate-rss.js:42:38)

workaround:

edit contentlayer.config.ts set a default value for tags:

diff --git a/contentlayer.config.ts b/contentlayer.config.ts
index 3f6c2b8..929806e 100644
--- a/contentlayer.config.ts
+++ b/contentlayer.config.ts
@@ -44,7 +44,7 @@ export const Blog = defineDocumentType(() => ({
   fields: {
     title: { type: 'string', required: true },
     date: { type: 'date', required: true },
-    tags: { type: 'list', of: { type: 'string' } },
+    tags: { type: 'list', of: { type: 'string' }, default: [] },
     lastmod: { type: 'date' },
     draft: { type: 'boolean' },
     summary: { type: 'string' },

ref contentlayer list

page bundle image support

currently does not support page bundle images, see

https://github.com/timlrx/pliny/issues/106

npm install git+https://github.com/ttys3/remark-copy-linked-files.git

ref to https://unifiedjs.com/learn/guide/create-a-plugin/#plugin-basics

and https://mdxjs.com/docs/extending-mdx/#components--plugins

mainly hack:

dataDir is default to data

      // path is something like `/path-to-project-root/_mdx_bundler_entry_point-3e814d53-72fb-474b-8853-f64f1521e36a.mdx`
      // after contentlayer (which uses mdx-bundler)
      // `file.data.rawDocumentData.sourceFilePath` begin with `blog/xxx`, does not include the `data` dir
      const fullpath = resolve(
        cwd,
        dataDir,
        file?.data?.rawDocumentData?.sourceFilePath ? dirname(file.data.rawDocumentData.sourceFilePath) : '',
        platformNormalizedUrl,
      );

and edit contentlayer.config.ts, add to top:

import remarkCopyLinkedFiles from 'remark-copy-linked-files'

under remarkPlugins, add below before remarkGfm:

[remarkCopyLinkedFiles, {destinationDir: process.cwd() +"/public/static/images/blog/", staticPath: "/static/images/blog"}],

other ref:

https://github.com/timlrx/pliny/blob/1e82c4e45fb2ea8533aeb6c265822acf312e7067/packages/pliny/src/mdx-plugins/remark-img-to-jsx.ts#L13

https://github.com/facebook/docusaurus/blob/26ae4164d6f90c231c6687363a3907b5f9f172b8/packages/docusaurus-mdx-loader/src/remark/transformImage/index.ts#L160

Netlify

https://docs.netlify.com/configure-builds/manage-dependencies/#pnpm

Netlify supports pnpm for Node.js 16.9.0 and later.

If your site’s base directory includes a pnpm-lock.yaml file, we will run pnpm install to install the dependencies listed in your package.json.

To specify a pnpm version, you can edit your package.json file:

"packageManager": "[email protected]"

This tells Corepack to use and download your preferred pnpm version instead of the default version that Netlify sets.

In certain scenarios, you must pass additional flags to the pnpm install command. For example, some frameworks such as Nuxt 3 and Next.js require that you modify the pnpm install command. To avoid import issues with pnpm and these frameworks, use the PNPM_FLAGS environment variable and set it to --shamefully-hoist. Learn more in our Nuxt docs and Next.js docs.

https://docs.netlify.com/integrations/frameworks/next-js/overview/#pnpm-support

pnpm support If you’re planning to use pnpm with Next.js to manage dependencies, you must do one of the following:

Set a PNPM_FLAGS environment variable with a value of --shamefully-hoist. This appends a --shamefully-hoist argument to the pnpm install command that Netlify runs.

Enable public hoisting by adding an .npmrc file in the root of your project with this content:

public-hoist-pattern[]=*

Setup Chrome ExtensionInstallAllowlist Policies Under Linux

ttyS3 — Thu, 22 Dec 2022 15:29:48 GMT

主要是想从 crx 文件安装一个扩展

因为一些原因, 这个扩展可能在 Chrome Web Store 上架的并不是最新版本, 所以只能从 crx 文件安装最新的版本.

但是当前 Chrome 版本已经不再允许直接从 crx 文件安装扩展了 (这里只讨论正常的安装, 不考虑打开开发者模式从文件load的情况).

不过 Chrome 官方也并没有封死路, 只是需要在策略里面添加一个白名单, 才能允许从 crx 文件安装扩展.

wiki里面只介绍了 Windows 下载改注册表的方法.

Windows 下的方法

# Chrome
reg add HKLM\SOFTWARE\Policies\Google\Chrome\ExtensionInstallAllowlist /v 99999 /t reg_sz /d dmmjlmbkigbgpnjfiimhlnbnmppjhpea /f

# Edge
reg add HKLM\SOFTWARE\Policies\Microsoft\Edge\ExtensionInstallAllowlist /v 99999 /t reg_sz /d dmmjlmbkigbgpnjfiimhlnbnmppjhpea /f

或将以下内容保存为 addWhitelist.reg 文件，然后双击导入注册表：

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\ExtensionInstallAllowlist]
"99999"="dmmjlmbkigbgpnjfiimhlnbnmppjhpea"
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge\ExtensionInstallAllowlist]
"99999"="dmmjlmbkigbgpnjfiimhlnbnmppjhpea"

Linux 下的方法

以 ExtensionInstallAllowlist 为关键字, 找到了一个文档: https://chromeenterprise.google/policies/#ExtensionInstallAllowlist

不过这个文档也比较抽象. 这个配置文件完整的结构是什么样的呢? 也没有个 demo. 不过最终老灯还是研究出来了方法. 记录如下.

# 如果 /etc/opt/chrome/policies/managed 不存在, 则自己创建一下
sudo mkdir -p /etc/opt/chrome/policies/managed

# edge linux stable is:
sudo mkdir -p /etc/opt/edge/policies/managed

然后在 /etc/opt/chrome/policies/managed 下创建一个 extension_install_allowlist.json 文件 (文件名称随意), 内容如下:

{
  "ExtensionInstallAllowlist": [
    "dmmjlmbkigbgpnjfiimhlnbnmppjhpea"
  ]
}

这个规则, Chrome 是动态加载的. 也就是说, 你可以随时修改这个文件, 就会即时生效.

要查看生效的策略, 可以访问: chrome://policy/ , 如果看到 ExtensionInstallAllowlist 策略, 并且状态是 OK, 则说明策略配置正确且生效了.

for edge, access edge://policy/

dmmjlmbkigbgpnjfiimhlnbnmppjhpea 是 Chrome 扩展的 ID, 关于怎么获取这个 ID, 官方有文档

但是其实这个东西很简单都不用说了, 就是 Chrome store 后面那一串字符串.

Refs

Set Chrome app and extension policies (Linux) https://support.google.com/chrome/a/answer/7517525?hl=en

ExtensionInstallAllowlist Configure extension installation allow list https://chromeenterprise.google/policies/#ExtensionInstallAllowlist

修复 systemd resolved DNS 配置

ttyS3 — Mon, 07 Nov 2022 19:08:08 GMT

solution

其实是升级后 tailscale 提示我的.

❯ tailscale status
# Health check:
#     - dns-manager: systemd-resolved and NetworkManager are wired together incorrectly; MagicDNS will probably not work. For more info, see https://tailscale.com/s/resolved-nm
#     - dns-os: setLinkDNS: Could not activate remote peer.
#     - dns: setLinkDNS: Could not activate remote peer.

/etc/resolv.conf 的内容虽然是正常的 nameserver 127.0.0.53, 但是这个文件并不是指向 systemd-resolved stub 的一个符号链接.

tailscale 检测出了这一问题. 其实产生这个问题的原因是, 我这台机器的 systemd-resolved 这个服务没有被启用 (有可能是突然断电造成的问题).

参考它的方法 https://tailscale.com/kb/1188/linux-dns/ 还不够. 我们需要启用 systemd-resolved 这个服务:

# 以下操作均以 root 身份的执行

systemctl enable --now systemd-resolved

ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

systemctl restart systemd-resolved
systemctl restart NetworkManager
systemctl restart tailscaled

misc

MagicDNS 是 tailscale 推出的一个很方便的功能, 可以让你使用域名访问你的内网资源. 而不是 IP.

❯ resolvectl status tailscale0
Link 6 (tailscale0)
    Current Scopes: DNS
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 100.100.100.100
       DNS Servers: 100.100.100.100
        DNS Domain: xxxxxxxxxxxxxxxxxxxx (此处为敏感信息)

可以看到 tailscale0 的 DNS 在启用了 MagicDNS 后, 变成了 100.100.100.100 , 它会负责解析 tailscale 相关的域名 (比如 hostname.xxxx.ts.net)

How to Upgrade CentOS Stream 8 to Stream 9

ttyS3 — Mon, 07 Nov 2022 18:34:52 GMT

CS9 (CentOS Stream 9) 发布也挺久了.

一直没有升级, 主要是官方一直没有发布升级指南. 这一点 CentOS 比较坑 (当然, RHEL用户是可以从RHEL8 升级 RHEL9的).

reddit 上甚至有 RHEL 的员工回复:

Q: How to upgrade from Stream 8 to Stream 9? A:

rbowen2000 1 yr. ago Red Hat Employee No. There is not currently a way to do an in-place upgrade between C8S and C9S, nor do we expect for there to be one. This is one of the questions that gets asked at each of our CentOS Dojo AMA sessions, and the answer is typically along the lines of "Red Hat Engineering isn't interested in this feature for RHEL, and so it won't be worked on for CentOS. However, if someone from the community works on it, that would be awesome."
Related, the ELevate project - https://almalinux.org/elevate - may be the solution to this problem, but isn't yet. I think that Jack suggested that upgrades between various CentOS Stream versions was a long-term goal.

ref: https://www.reddit.com/r/CentOS/comments/ql5iek/how_to_upgrade_from_stream_8_to_stream_9/

其实这个回复具有很大的误导作用.

CS8 到 CS9 并不是不能升级, 而是, 从企业级的角度来看, 这个升级可能要花费很多时间去校验其可行性和稳定性, 以及各种包的兼容问题处理等.

当然, 对于个人用户来说, 这个升级完全是可行的.

我就一 NAS, 升挂了大不了我重装为 Fedora Server. (嗯,我之前是从 CentOS 8升级到 Stream 8 的, 如果早知道它会搞出 Stream, 我就直接装 Fedora Server了, 至少是发布的稳定版)

升级步骤

以下操作都是在 root 用户下进行的.

先升级 CS8 到最新版

dnf upgrade --refresh -y

移除非必要RPM包 (没有被任何其它包依赖的包) 和 orphans 包 (当前的repo中已经不存在了的包)

dnf remove -y $(dnf repoquery --unneeded)

dnf remove -y $(dnf repoquery --extras)

dnf autoremove -y

清理旧的内核 (可选操作)

我们先看下当前的内核版本(主要是方便翻车后选择从这个旧内核启动):

❯ uname -a
Linux homenas 4.18.0-408.el8.x86_64 #1 SMP Mon Jul 18 17:42:52 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

偷懒的清理方法是, 删除所有内核,然后再安装最新的内核:

rpm -e `rpm -q kernel` --nodeps
rpm -e `rpm -q kernel-devel` --nodeps
rpm -e `rpm -q kernel-core` --nodeps
rpm -e `rpm -q kernel-modules` --nodeps

dnf install -y kernel

下载 epel9 和 cs9 的 repo rpm 安装文件

mkdir -p /root/upgrade/epel9
cd /root/upgrade/epel9

curl -LO https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
curl -LO https://dl.fedoraproject.org/pub/epel/epel-next-release-latest-9.noarch.rpm

cd ../
# http://mirror.stream.centos.org/9-stream/BaseOS/x86_64/os/Packages/ 找到最新的 centos-stream-release 和 centos-stream-repos 包下载回来

curl -LO http://mirror.stream.centos.org/9-stream/BaseOS/x86_64/os/Packages/centos-stream-release-9.0-18.el9.noarch.rpm
curl -LO http://mirror.stream.centos.org/9-stream/BaseOS/x86_64/os/Packages/centos-stream-repos-9.0-18.el9.noarch.rpm
curl -LO http://mirror.stream.centos.org/9-stream/BaseOS/x86_64/os/Packages/centos-gpg-keys-9.0-18.el9.noarch.rpm

安装 epel9 和 cs9 的 repo rpm

先安装 cs 9 rpm:

dnf install -y *.rpm

再安装 epel9:

cd epel9
dnf install -y *.rpm

升级到 CS9

dnf -y --releasever=9 --allowerasing --setopt=deltarpm=false distro-sync

这里老灯遇到了个包冲突:

(1116/1116): isl-0.16.1-15.el9.x86_64.rpm                                  16 kB/s | 864 kB     00:53    
----------------------------------------------------------------------------------------------------------
Total                                                                      12 MB/s | 1.2 GB     01:46     
Extra Packages for Enterprise Linux 9 - x86_64                            1.6 MB/s | 1.6 kB     00:00    
Importing GPG key 0x3228467C:
 Userid     : "Fedora (epel9) <[email protected]>"
 Fingerprint: FF8A D134 4597 106E CE81 3B91 8A38 72BF 3228 467C
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-9
Key imported successfully
Running transaction check
Transaction check succeeded.
Running transaction test
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Transaction test error:
  file /usr/share/terminfo/r/rxvt-unicode-256color from install of ncurses-base-6.2-8.20210508.el9.noarch conflicts with file from package rxvt-unicode-terminfo-9.26-1.el8.noarch

解决方法是直接 dnf remove rxvt-unicode-terminfo-9.26-1.el8 -y 即可.

然后再重新执行上面的升级语句.

重建 rpm 数据库

这里需要重建的原因主要是: CS9 的 rpm 数据库格式从 bdb_ro 变成了 sqlite

ref https://fedoraproject.org/wiki/Changes/Sqlite_Rpmdb

rpmdb --rebuilddb

清理 dnf 缓存 (可选操作)

dnf clean packages

subscription-manager 这个包一般人也用不到订阅, 可以卸载: dnf remove -y subscription-manager

再升级一次

dnf upgrade --refresh -y

确保核心包已安装

dnf -y groupupdate "Core" "Minimal Install"

检查内核和 sshd 是否安装成功

检查默认启动内核:

❯ grubby --default-kernel
/boot/vmlinuz-5.14.0-183.el9.x86_64

检查内核和 sshd 是否安装成功

❯ dnf list --installed | rg ssh
libssh.x86_64                               0.10.4-3.el9                          @baseos                                        
libssh-config.noarch                        0.10.4-3.el9                          @baseos                                        
openssh.x86_64                              8.7p1-24.el9                          @baseos                                        
openssh-clients.x86_64                      8.7p1-24.el9                          @baseos                                        
openssh-server.x86_64                       8.7p1-24.el9                          @baseos      

❯ dnf list --installed | rg kernel
kernel.x86_64                               4.18.0-408.el8                        @baseos                                        
kernel.x86_64                               5.14.0-183.el9                        @baseos                                        
kernel-core.x86_64                          4.18.0-408.el8                        @baseos                                        
kernel-core.x86_64                          5.14.0-183.el9                        @baseos                                        
kernel-devel.x86_64                         4.18.0-408.el8                        @baseos                                        
kernel-devel.x86_64                         5.14.0-183.el9                        @appstream                                     
kernel-devel-matched.x86_64                 5.14.0-183.el9                        @appstream                                     
kernel-headers.x86_64                       5.14.0-183.el9                        @appstream                                     
kernel-modules.x86_64                       4.18.0-408.el8                        @baseos                                        
kernel-modules.x86_64                       5.14.0-183.el9                        @baseos                                        
kernel-srpm-macros.noarch                   1.0-11.el9                            @appstream                                     
kernel-tools.x86_64                         5.14.0-183.el9                        @baseos                                        
kernel-tools-libs.x86_64                    5.14.0-183.el9                        @baseos

重启

重启比较快, 整个升级还算是比较成功的.

检查当前的版本是不是已经升级到 CS9 了:

❯ cat /etc/os-release
NAME="CentOS Stream"
VERSION="9"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="9"
PLATFORM_ID="platform:el9"
PRETTY_NAME="CentOS Stream 9"
ANSI_COLOR="0;31"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:centos:centos:9"
HOME_URL="https://centos.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux 9"
REDHAT_SUPPORT_PRODUCT_VERSION="CentOS Stream"

检查内核版本:

❯ uname -a
Linux homenas 5.14.0-183.el9.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Oct 31 09:18:51 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

其它清理

确认启动工作正常后, 可以把旧的内核删除了.

❯ rpm -q kernel-core
kernel-core-4.18.0-408.el8.x86_64
kernel-core-5.14.0-183.el9.x86_64

dnf remove -y kernel-core-4.18.0-408.el8

列出当前还在的安装自 CentOS Stream 8 的包:

❯ dnf list --installed|grep el8
bind-export-libs.x86_64                     32:9.11.36-5.el8                      @baseos                                        
bpytop.noarch                               1:1.0.54-3.el8                        @epel                                          
cgdcbxd.x86_64                              1.0.2-9.el8                           @AppStream                                     
cri-o.x86_64                                1.22.5-2.2.el8                        @devel_kubic_libcontainers_stable_cri-o_1.22   
iptstate.x86_64                             2.2.6-6.el8                           @anaconda                                      
iwl6000-firmware.noarch                     9.221.4.1-110.el8.1                   @baseos                                        
javapackages-filesystem.noarch              5.3.0-1.module_el8.0.0+11+5b8c10bd    @AppStream                                     
kernel-devel.x86_64                         4.18.0-408.el8                        @baseos                                        
libXxf86misc.x86_64                         1.0.4-1.el8                           @AppStream                                     
libatomic_ops.x86_64                        7.6.2-3.el8                           @AppStream                                     
libcgroup.x86_64                            0.41-19.el8                           @anaconda                                      
libcroco.x86_64                             0.6.12-4.el8_2.1                      @anaconda                                      
libertas-usb8388-firmware.noarch            2:20220726-110.git150864a4.el8        @baseos                                        
libmcpp.x86_64                              2.7.2-20.el8                          @AppStream                                     
libmodman.x86_64                            2.0.1-17.el8                          @anaconda                                      
man-pages-overrides.noarch                  8.6.0.0-1.el8                         @appstream                                     
mcpp.x86_64                                 2.7.2-20.el8                          @AppStream                                     
mozjs60.x86_64                              60.9.0-4.el8                          @anaconda                                      
openwsman-client.x86_64                     2.6.5-9.el8                           @appstream                                     
python38-pip-wheel.noarch                   19.3.1-6.module_el8.7.0+1184+30eba247 @appstream                                     
python38-setuptools-wheel.noarch            41.6.0-5.module_el8.6.0+929+89303463  @appstream                                     
shim-x64.x86_64                             15-15.el8_2                           @anaconda                                      
terminus-fonts-console.noarch               4.48-1.el8                            @epel                                          
wireguard-dkms.noarch                       1:1.0.20220627-1.el8                  @copr:copr.fedorainfracloud.org:jdoss:wireguard
xorg-x11-font-utils.x86_64                  1:7.5-41.el8                          @appstream

注意, 这里有些包不能直接 dnf remove 卸载, 比如:

❯ dnf info kernel-devel
Last metadata expiration check: 1:58:17 ago on Tue 08 Nov 2022 01:35:37 AM CST.
Installed Packages
Name         : kernel-devel
Version      : 4.18.0
Release      : 408.el8
Architecture : x86_64
Size         : 52 M
Source       : kernel-4.18.0-408.el8.src.rpm
Repository   : @System
From repo    : baseos
Summary      : Development package for building kernel modules to match the kernel
URL          : http://www.kernel.org/
License      : GPLv2 and Redistributable, no modification permitted
Description  : This package provides kernel headers and makefiles sufficient to build modules
             : against the kernel package.

Name         : kernel-devel
Version      : 5.14.0
Release      : 183.el9
Architecture : x86_64
Size         : 61 M
Source       : kernel-5.14.0-183.el9.src.rpm
Repository   : @System
From repo    : appstream
Summary      : Development package for building kernel modules to match the kernel
URL          : https://www.kernel.org/
License      : GPLv2 and Redistributable, no modification permitted
Description  : This package provides kernel headers and makefiles sufficient to build modules
             : against the kernel package.

我们不是要卸载 kernel-devel, 而是只要卸载 kernel-devel-4.18.0-408.el8:

dnf remove kernel-devel-4.18.0-408.el8

terminus-fonts-console 不要卸载, epel9 里面没有了. 这个只是个字体包, 不影响系统.

https://packages.fedoraproject.org/pkgs/terminus-fonts/terminus-fonts-console/epel-8.html

不过没关系, 卸载了也可以安装回来:

dnf install -y https://download-ib01.fedoraproject.org/pub/epel/8/Everything/x86_64/Packages/t/terminus-fonts-console-4.48-1.el8.noarch.rpm

其它

升级过程中会有一些警告信息, 目前看来没有什么影响.

信息1:

/usr/sbin/ldconfig: /lib64/ld-linux-x86-64.so.2 is not a symbolic link

/sbin/ldconfig: /lib64/ld-linux-x86-64.so.2 is not a symbolic link

/sbin/ldconfig: /lib64/libslapi-2.4.so.2 is not a symbolic link

/sbin/ldconfig: /lib64/libldap_r-2.4.so.2 is not a symbolic link

/sbin/ldconfig: /lib64/libldap-2.4.so.2 is not a symbolic link

/sbin/ldconfig: /lib64/liblber-2.4.so.2 is not a symbolic link

/sbin/ldconfig: /lib64/ld-linux-x86-64.so.2 is not a symbolic link

信息2:

failed to link /usr/bin/python3 -> /etc/alternatives/python3: /usr/bin/python3 exists and it is either not a symlink or --keep-foreign was set and link points outside /etc/alternatives
failed to link /usr/bin/pip-3 -> /etc/alternatives/pip-3: /usr/bin/pip-3 exists and it is either not a symlink or --keep-foreign was set and link points outside /etc/alternatives
failed to link /usr/bin/pip3 -> /etc/alternatives/pip3: /usr/bin/pip3 exists and it is either not a symlink or --keep-foreign was set and link points outside /etc/alternatives
failed to link /usr/bin/pydoc3 -> /etc/alternatives/pydoc3: /usr/bin/pydoc3 exists and it is either not a symlink or --keep-foreign was set and link points outside /etc/alternatives
failed to link /usr/bin/python3-config -> /etc/alternatives/python3-config: /usr/bin/python3-config exists and it is either not a symlink or --keep-foreign was set and link points outside /etc/alternatives
failed to link /usr/share/man/man1/python3.1.gz -> /etc/alternatives/python3-man: /usr/share/man/man1/python3.1.gz exists and it is either not a symlink or --keep-foreign was set and link points outside /etc/alternatives

另外还有一些配置升级的信息:

只要软件没有破坏性变更, 这些配置不 migration 一般也没事.

warning: /etc/nsswitch.conf created as /etc/nsswitch.conf.rpmnew

warning: /etc/systemd/system.conf created as /etc/systemd/system.conf.rpmnew

warning: /etc/samba/smb.conf created as /etc/samba/smb.conf.rpmnew

warning: /etc/systemd/resolved.conf created as /etc/systemd/resolved.conf.rpmnew

warning: /etc/containers/registries.conf created as /etc/containers/registries.conf.rpmnew

warning: /etc/chrony.conf created as /etc/chrony.conf.rpmnew

/etc/yum.repos.d 残余的 cs8 repo 文件问题: 其实我是在升级之前备份, 然后手动删除了这些 xxx.repo 文件的, 但是升级完后会有这些警告信息.

❯ dnf module list       
Last metadata expiration check: 0:10:14 ago on Tue 08 Nov 2022 12:58:15 AM CST.
Modular dependency problems:

 Problem 1: conflicting requests
  - nothing provides module(platform:el8) needed by module nodejs:14:8070020220601142310:3b9f49c4.x86_64
 Problem 2: conflicting requests
  - nothing provides module(platform:el8) needed by module perl-DBD-SQLite:1.58:8030020200716174729:3a70019f.x86_64
  - nothing provides module(perl:5.26) needed by module perl-DBD-SQLite:1.58:8030020200716174729:3a70019f.x86_64
 Problem 3: conflicting requests
  - nothing provides module(platform:el8) needed by module perl-DBI:1.641:8030020200716150652:1e4bbb35.x86_64
  - nothing provides module(perl:5.26) needed by module perl-DBI:1.641:8030020200716150652:1e4bbb35.x86_64
 Problem 4: conflicting requests
  - nothing provides module(platform:el8) needed by module perl-IO-Socket-SSL:2.066:8040020200924212038:1aedcbfe.x86_64
  - nothing provides module(perl:5.26) needed by module perl-IO-Socket-SSL:2.066:8040020200924212038:1aedcbfe.x86_64
 Problem 5: conflicting requests
  - nothing provides module(platform:el8) needed by module perl-libwww-perl:6.34:8040020211102170116:bf75fe78.x86_64
  - nothing provides module(perl:5.26) needed by module perl-libwww-perl:6.34:8040020211102170116:bf75fe78.x86_64
 Problem 6: conflicting requests
  - nothing provides module(platform:el8) needed by module python36:3.6:8050020210825152031:982725ab.x86_64
 Problem 7: conflicting requests
  - nothing provides module(platform:el8) needed by module python38:3.8:8070020220920211024:bd194b04.x86_64
 Problem 8: conflicting requests
  - nothing provides module(platform:el8) needed by module virt:rhel:8070020220921151759:3b9f49c4.x86_64

解决办法:

dnf module reset nodejs perl-DBD-SQLite perl-DBI perl-IO-Socket-SSL perl-libwww-perl python36 python38 virt

然后再执行 dnf module list 就没有问题了:

❯ dnf module list                 
Last metadata expiration check: 0:10:51 ago on Tue 08 Nov 2022 12:58:15 AM CST.
@modulefailsafe
Name                                                  Stream                                      Profiles                                                               Summary     
javapackages-runtime                                  201801 [e]                                  common                                                                 Basic runtime utilities to support Java applications                                   

CentOS Stream 9 - AppStream
Name                                                  Stream                                      Profiles                                                               Summary     
maven                                                 3.8                                         common [d]                                                             Java project management and project comprehension tool                                 
nodejs                                                18                                          common [d], development, minimal, s2i                                  Javascript runtime                                                                     
php                                                   8.1                                         common [d], devel, minimal                                             PHP scripting language                                                                 
ruby                                                  3.1                                         common [d]                                                             An interpreter of object-oriented scripting language                                   

Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled

可以看到 CS9 的 module 比 CS8 少很多.

Refs

主要参考 https://ahelpme.com/linux/centos-stream-9/how-to-upgrade-to-centos-stream-9-from-centos-stream-8/

https://github.com/Ink-33/OhMyStream9

ACM 会员已无 O'Reilly Learning 羊毛可撸

ttyS3 — Sat, 24 Sep 2022 18:53:47 GMT

缘由

其实是 O'Reilly Learning 终止了和 ACM 合作.

毕竟 499刀的会员, 几十美元买个 ACM 会员就能白得. O'Reilly 估计觉得这已经影响到它自己卖 O'Reilly Learning 会员了.

这无疑是 ACM 的损失, 也是我们这些羊毛党的损失.

没有了免费 O'Reilly Learning 资料库的 ACM 会员对于我来说, 毫无用处.

https://web.archive.org/web/20220702061717/https://learning.acm.org/e-learning/oreilly

Use promo code ACM10022 to receive an introductory one-year subscription for $399 (plus VAT/Tax).

这里搞笑的是, 我是今天收到了 O'Reilly Learning 有 299刀的优惠价的时候才想起了要说一下这事.

为什么呢? O'Reilly Learning 终止了和 ACM 合作是今年(2022)年7月份的事. 当时给了 $399 刀一年的优惠价.

我现在庆幸当时没有买. 因为买了的话现在肯定会很郁闷. 给 ACM 的是便宜 100 刀, 现在自家在促销, 便宜 200刀.

因为白嫖没有了, pku bbs 也有人讨论这个 https://bbs.pku.edu.cn/v2/post-read.php?bid=25&threadid=18257725&page=a&postid=25437482

我是看到不少人吐槽ACM会员没法白嫖之后才知道这个数据库的😂有一说一这数据库确实很让我心动，如果不是这么贵我都考虑个人订阅了tokamako (1601213993) 在 ta 的帖子中提到：我猜大家都是因为 ACM 的会员没法白嫖 O'Reilly 的电子书了 XD

他们讨论, 也许是因为清华已经订阅了 O'Reilly for Higher Education 吧: https://ecollection.lib.tsinghua.edu.cn/databasenav/entrance/detail?mmsid=991021796739403966

资源简介收录了2013以来出版的43,000多种电子图书（至2020年6月）；7500多个视频，时长达到3万多个小时。资源类型包括电子书、视频、经典案例、在线教程（Tutorials）、学习路径等。资源数量持续增加。学习路径：来自基于多个主题的内容，包括分析、计算机网络、硬件、数据库、设计、数字媒体、教育等方面；在线教程（Oriole Online Tutorials）：Oriole是一种新媒体，将代码，数据，文本和培训视频融合到整个学习体验中。读者可在实际操作中学习，提供互动编码环境，并且可以按照自身安排与进度进行学习。O’Reilly独家出版的汇集了商业与技术领域，源自世界著名创新者与企业负责人的最新专业知识、独家会议资源等：包括前美国白宫数据科学家D.J. Patil、前通用电气公司董事长兼首席执行官Jeff Immelt 、哈佛商学院商业管理教授Clayton M. Christensen、对冲基金Two Sigma执行总监Camille Fournier，及美国著名硅谷企业家 Eric Ries等。O’Reilly Media公司于2017年底，发布了新学习平台，整合了全球200多家世界知名出版社，例如Wiley，Pearson，O'Reilly， Packt Publishing，Infinite Skills，Stone River eLearning等。

特别提示使用计算机可在线阅读，图书内容不能下载，但可以复制和单页打印。持续打印数量过大，会收到系统警告。

商家的套路

在 9-22 之前我收到的是这样的:

If you’ve been thinking about becoming an O’Reilly member, now’s the time to act. Join before September 22 and get a year of O’Reilly for just $299—a savings of $200.

 
Get Deal
Use promo code SALESEPT22. Expires 9/22/22.

This offer is nontransferable and expires on September 22, 2022, at 11:59pm PT. This offer is for individual memberships only. Team (multiuser) and enterprise accounts are not eligible. The US $299/year offer is valid for the first year of your membership. Memberships renew at the then-current price (currently US $499/year) unless you cancel in accordance with our Membership Agreement. Tax not included.

9-22 过后, 我收到的是这样的:

We talked to the lawyers and bought some more time to lock in your $299 O’Reilly membership. But soon it goes back up to $499.

 
Get Deal
Use promo code SALESEPT22.
Expires at midnight PT 9/27/22.


This offer is nontransferable and expires on September 27, 2022, at 11:59pm PT. This offer is for individual memberships only. Team (multiuser) and enterprise accounts are not eligible. The US $299/year offer is valid for the first year of your membership. Memberships renew at the then-current price (currently US $499/year) unless you cancel in accordance with our Membership Agreement. Tax not included.

说好了过了 9-22 就没有这优惠了呢? 套路

另外就是, 其实在 9-22 之前我就已经买了这个, 所以, 另一方面, 其实 O'Reilly 的运营推送, 并不会考虑用户是否已经购买会员.

new TOML crate

ttyS3 — Sat, 24 Sep 2022 18:01:49 GMT

今天检查邮箱发现 https://github.com/toml-rs/toml-rs/issues/392 这个 issue 有更新.

由于 toml 这个 crate 完成的时候, TOML 标准本身还没有达到 1.0.0 稳定版, 因此这个 crate 实际上只实现了 TOML 标准 0.5 版本的功能.

但是现在 TOML 标准已经到了 1.0.0 版本, 而 toml 这个 crate 的维护者却一直没有更新. 由于有了这个 issue, 讨论何时更新到1.0版本.

这是一个 2020 年的 issue. 一直没啥动静, 值得高兴的时候, 昨天终于有变动了:

https://github.com/toml-rs/toml-rs/issues/392#issuecomment-1256456721

Maintenance of this crate has moved to the toml-rs/toml repo. As a heads up, we plan to move toml to be on top of toml_edit, see toml-rs/toml#340.
Closing this out. If this is still a problem, feel free to recreate this issue in the new repo.

现在, 如果你打开 https://github.com/toml-rs/toml-rs, 会发现 readme 已经变成了:

Development of the toml crate has moved to https://github.com/toml-rs/toml/tree/master/crates/toml.
This repo is now archived.

其实还有一个 toml-rs/toml-rs 的作者为这个项目寻找新的维护者的issue, https://github.com/toml-rs/toml-rs/issues/460

I personally no longer have the time or energy to maintain this crate. I believe this is still pretty widely used as the default TOML implementation for Rust, however, so it'd be good to keep this maintained. I'm opening this to see if there is another who is willing to take over ownership and maintenance of this crate. In the meantime I will not be maintaining this crate other than if a security issue arises.

今年6月左右 https://github.com/toml-rs/toml-rs/issues/460#issuecomment-1163202480:

epage 写道:

@alexcrichton what if we moved toml_edit::easy into toml?
A task I've been meaning to get to is to restructure toml_edit so a subset can more easily show up in public APIs, like cargo_metadata including toml. One possible route for that is to split toml_edit::easy out into its own crate and not expose any toml_edit types.
The downside being that toml_edit::easy has a ceiling on how fast it can get due to the format-preserving core its built on, even if the performance right now is roughly on par with toml.

toml_edit 又是啥呢? 它现在已经被 cargo 使用了: https://github.com/rust-lang/cargo/pull/10086

根据这个 PR 的描述, 它是 A TOML 1.0 compliant parser

有个小问题就是, alexcrichton 将 toml-rs 的仓库转移到了 epage 的 toml-rs github 组织下面后(仓库从 alexcrichton/toml-rs 变成了 toml-rs/toml-rs ),

epage 关闭了旧仓库 (toml-rs/toml-rs) 的所有 issue, 并且这些 issue 似乎没有被转移到新的 repo (toml-rs/toml) 下面. 有一些用户对此感到不满, 主要在 https://github.com/toml-rs/toml/issues/340 里面, 被隐藏的一评论.

不管怎么说, toml 这个 crate 重新重新有人维护了. 要感谢 alexcrichton, 它不但允许 epage 接管后, 继续使用 toml 这个 crate 名字, 而且将原来的 toml-rs 仓库也转移给了他.

所以, 新的 toml 库能继续使用 toml crate 这个名字, 并且旧使用也可以继续升级.

根据 https://crates.io/crates/toml 这个 crate 每天的下载量大概在 10万左右.

toml_edit 使用的 parser 是 https://docs.rs/combine, 其实它早期使用的是 nom, 至于为什么迁移到了 combine, 见这个issue : https://github.com/toml-rs/toml/issues/16

nom is great for parsing binary formats, but no-so-great for parsing languages and reporting human readable errors. I'm considering combine, pest (procedural branch), peg, larlpop at the moment.

目前 toml_edit 有个问题还没解决就是编译很慢: toml_edit is pretty slow to compile https://github.com/toml-rs/toml/issues/327

对比 https://github.com/rosetta-rs/parse-rosetta-rs

Refs

combine vs nom 对比: https://github.com/Marwes/combine/issues/73

parser benchmark: https://github.com/rosetta-rs/parse-rosetta-rs

Migrate toml to be on toml_edit https://github.com/toml-rs/toml/issues/340

Linux Console HiDPI Font Config

ttyS3 — Wed, 24 Aug 2022 18:03:27 GMT

老灯用的是 Nvidia 显卡闭源驱动. 显示器是 4K 的.

这操作基本上是每次装机后必备的, 这里记录下.

Linux Console 字体太大了

默认情况下有个问题就是: console 下面的字体太大了. 字体太大了, 是因为 frame buffer 分辨率太低了, 最简单的做法就是把 console 字体调小一点.

纯 console 下的字体是点阵字体. 默认的字体有点丑, 装个 terminus 吧:

paru -S terminus-font

切到 console 看下效果:

setfont ter-d14b

我这里设置 14 号是因为默认的太大了, 14相对较小一些. 另外 12 的话点太明显了, 不够清晰. 而14以上的又太大了. b 是 bold, n 后缀的则是 normal. bold 的会显得清晰一些. normal 的话还是容易看到点阵, 感觉回到古代了.

OK 的话就把配置持久化:

编辑 /etc/vconsole.conf 添加:

FONT=ter-d14b

GRUB HiDPI 字体调整

参考 https://wiki.archlinux.org/title/HiDPI#GRUB

和 https://wiki.archlinux.org/title/GRUB/Tips_and_tricks#Setting_the_framebuffer_resolution

Refs

https://wiki.archlinux.org/title/Linux_console#Framebuffer_console

Switch From GDM to LightDM Due to GDM Wayland Session Issue

ttyS3 — Wed, 24 Aug 2022 17:38:04 GMT

工作电脑是双屏, 自动切换到 Wayland 之后, GDM 就没消停过.

经常性的从锁屏界面切回来后 GNOME 桌面会话退出了, 然后登录进去所有用户进程都结束了, 就跟重启后首次登录一样.

看 gdm 的日志也没看出啥. 家里的电脑同样是 Arch, 并且同样是 Nvidia 显卡, 唯一的不同时, 家里的是一个屏. 但是基本上家里的电脑就很少有放一段时间后再登录桌面会话消失的情况.

今天无意中在这 https://ask.fedoraproject.org/t/external-monitor-with-wayland-and-two-gpus-notebok/20387/3 看到一个解决方案: "I read from other forum that the problem actually are with GDM (Gnome login screen). You could try to switch to lightdm."

所以, 是 GDM 的 bug, 换一个 DM 就好了. LightDM 虽然有点丑和简陋, 不过好歹解决了基本的使用问题.

丑点就丑点吧, 又不是不能用. GDM 再漂亮, 解决不了实际问题.

paru -S lightdm lightdm-gtk-greeter

sudo systemctl disable gdm
sudo systemctl mask gdm
sudo systemctl enable lightdm

测试了一天, 基本上确定 LightDM 解决了使用 GDM 时 Wayland session 经常被搞丢的问题.

锁屏问题

dm-tool switch-to-greeter 或 dm-tool lock 区别是, switch-to-greeter 会锁定然后回到登录界面, lock 会锁定并关闭显示器.

去 Keyboard -> Custom Shortcuts 自己加个锁屏快捷键即可.

HiDPI 问题

编辑 /etc/lightdm/lightdm-gtk-greeter.conf

[greeter]
xft-dpi=192

SDDM: 折腾以失败告终, 最终退回 LightDM

SDDM 这个东西最近几个月基本上都没人提交代码, 并且对于 Wayland 的支持并不太好. 要用开发分支才有 Wayland 支持.

# 安装  archlinuxcn/sddm-git 0.19.0.141.ge67307e-1
# e67307e 是 https://github.com/sddm/sddm/commits/develop 的最新提交.
paru -S sddm-git

# 安装点主题啥的
paru -S sddm-sugar-dark sddm-nordic-theme-git archlinux-themes-sddm

The default configuration file for SDDM can be found at /usr/lib/sddm/sddm.conf.d/default.conf. For any changes, create configuration file(s) in /etc/sddm.conf.d/. See sddm.conf(5) for all options.

sudo mkdir /etc/sddm.conf.d/

预览主题效果:

sddm-greeter --test-mode --theme /usr/share/sddm/themes/archlinux-soft-grey

sddm-greeter --test-mode --theme /usr/share/sddm/themes/elarun

sddm-greeter --test-mode --theme /usr/share/sddm/themes/maldives

sddm-greeter --test-mode --theme /usr/share/sddm/themes/maya

然后就是按 https://wiki.archlinux.org/title/SDDM 配置了.

最终没能到达显示登录界面:

Auth: sddm-helper exited with 3 Greeter stopped. SDDM::Auth::HELPER_OTHER_ERROR

去 Github issue 看了下, 好像蛮多 Wayland 遇到这个问题的.

sddm[45447]: Initializing...
sddm[45447]: Starting...
sddm[45447]: Logind interface found
sddm[45447]: Adding new display...
sddm[45447]: Loading theme configuration from ""
sddm[45447]: Using VT 3
sddm[45447]: Display server started.
sddm[45447]: Socket server starting...
sddm[45447]: Socket server started.
sddm[45447]: Loading theme configuration from "/usr/share/sddm/themes/maldives/theme.conf"
sddm[45447]: Greeter starting...
sddm-helper[45449]: [PAM] Starting...
sddm-helper[45449]: [PAM] Authenticating...
sddm-helper[45449]: pam_unix(sddm-greeter:session): session opened for user sddm(uid=950) by root(uid=0)
sddm-helper[45449]: [PAM] returning.
sddm[45447]: Greeter session started successfully
sddm-helper[45449]: [PAM] Closing session
sddm-helper[45449]: pam_unix(sddm-greeter:session): session closed for user sddm
sddm-helper[45449]: [PAM] Ended.
sddm[45447]: Auth: sddm-helper exited with 3
sddm[45447]: Greeter stopped. SDDM::Auth::HELPER_OTHER_ERROR
sddm[45447]: Signal received: SIGTERM

有没有可能是 theme 的问题? 没去试了.

但我猜测, 可能是 Wayland Compositor 的问题. SDDM 自身也同样是运行在 Wayland 下的, 当桌面登录还没启动的时候, SDDM 需要一个 Wayland Compositor 来启动它的 greeter. 我用的是它默认的 weston, 我不是 KDE, 并没有 kwin.

Refs

https://wiki.archlinux.org/title/LightDM

https://wiki.archlinux.org/title/Display_manager#Graphical

https://wiki.archlinux.org/title/SDDM

https://github.com/sddm/sddm/issues/1537

给 Hugo 博客添加 PlantUML 支持

ttyS3 — Sun, 21 Aug 2022 20:25:00 GMT

PlantUML 是最近才了解到的, 实际上这个东西存在已经很多年了.

之前有用过 mermaid, 但是 mermaid 的 flowchart 写起来很蛋疼.

PlantUML 的 activity diagram 对多行文本和 note 支持更好, 同时不用写太多的箭头和 A, B, C 这种标记.

mermaid 要支持多行文本, 当前只能用 foo1<br/>foo2<br/>foo3 的方式.

另一方面, A, B, C 这种标记, 当你突然想在中间插入一个的时候, 就会很蛋疼.

添加到 Hugo 模板

这里我并没有采用 Front Matter 参数的方式来确定是否加载 plantuml-encoder js 文件, 因此老灯觉得这样太麻烦.

因此是通过判断内容是否包含 plantuml 代码块来实现动态加载.


  const loadScript = (url, onloadFunction) => {
    var newScript = document.createElement("script");
    newScript.onerror =  (oError) => {
      throw new URIError("The script " + oError.target.src + " didn't load correctly.");
    };
    if (onloadFunction) { newScript.onload = onloadFunction; }
    document.head.insertAdjacentElement('beforeend', newScript);
    newScript.src = url;
  }

    const loadPlantUMLOnNeed = () => {
    let plantumlPrefix = "language-plantuml";

    if (document.querySelectorAll("[class^=" + plantumlPrefix + "]").length > 0) {
      loadScript('https://cdn.jsdelivr.net/gh/jmnote/[email protected]/dist/plantuml-encoder.min.js', () => {
        (function(){
          Array.prototype.forEach.call(document.querySelectorAll("[class^=" + plantumlPrefix + "]"), function(code){
            let image = document.createElement("IMG");
            image.loading = 'lazy'; // Lazy loading
            image.src = 'http://www.plantuml.com/plantuml/svg/~1' + plantumlEncoder.encode(code.innerText);
            code.parentNode.insertBefore(image, code);
            code.style.display = 'none';
          });
        })();

        console.log("PlantUML init done");
      })
    }
  }

  window.addEventListener('load', function(event) {
    // load PlantUML
    loadPlantUMLOnNeed();
  })

流程图

注: activity diagram 实际上和 flowchart 不是一个东西. 但是用 activity diagram 完全可以表现 flowchart 所要表现的东西. 实际上 activity diagram 比传统意义上的 flowchart 更强大.

Activity diagrams can be regarded as a form of a structured flowchart combined with a traditional data flow diagram. Typical flowchart techniques lack constructs for expressing concurrency.[5] However, the join and split symbols in activity diagrams only resolve this for simple cases; the meaning of the model is not clear when they are arbitrarily combined with decisions or loops. (活动图可以视为是种结构化的流程图，并且结合了传统的数据流程图。典型的流程图技术中缺乏表示并发性。不过，活动中的分离和汇合符号只解决了在简单情形下的应用，若是配合决策或是循环，其意义较不清楚) https://en.wikipedia.org/wiki/Activity_diagram

以 mermaid 默认的 flowchart example 为例, 其代码如下:

graph TD
    A[Christmas] -->|Get money| B(Go shopping)
    B --> C{Let me think}
    C -->|One| D[Laptop]
    C -->|Two| E[iPhone]
    C -->|Three| F[fa:fa-car Car]

效果如下:

而 PlantUML 写起来就更简单了.

用 UML 的活动图表示:

@startuml
: Christmas;
-> Get money;
: Go shopping;
switch (Let me think)
    case (One)
    : Laptop;
    detach
    case (Two)
    : iPhone;
    detach
    case (Three)
    : Car;
    detach
@enduml

注意, PlantUML 默认是连接的, 这里为了实现上面 mermaid 一样的图样效果, 特意加上了额外的 detach (一般情况下都不需要手动加 detach), 同时也没有写 start 和 stop标记.

时序图

sequenceDiagram
    Alice->>+John: Hello John, how are you?
    Alice->>+John: John, can you hear me?
    John-->>-Alice: Hi Alice, I can hear you!
    John-->>-Alice: I feel great!

用 PlantUML 可以完全复现如下:

```plantuml
    Alice -> John: Hello John, how are you?
    activate John
    
    Alice -> John: John, can you hear me?
    activate John
    John--> Alice: Hi Alice, I can hear you!
    deactivate John
    
    John--> Alice: I feel great!
    deactivate John
```

refs

https://plantuml.com/activity-diagram-beta

https://plantuml.com/sequence-diagram

https://mogeko.me/posts/zh-cn/083/

Hugo vs Zola

ttyS3 — Sun, 21 Aug 2022 19:50:16 GMT

对比项	Hugo	Zola
实现语言	Golang	Rust
主题数量	丰富	较少
模板引擎	Go Template	Tera
CSS 支持	SASS / SCSS, PostCSS	SASS / SCSS
Page Bundle 支持	Yes	Yes
Front Matter 支持	TOML/YAML/JSON/ORG	TOML/YAML
子目录支持	自动	需要手动给每个子目录添加 `_index.md`
生成 URL 配置	支持	不支持

Zola uses the Tera template engine, which is very similar to Jinja2, Liquid and Twig.

关于 Front Matter, 刚开始 Zola 是极力不想添加 YAML 支持的, 后面添加了, 但是并没有在文档里面说明 (作者极力不提倡使用).

事实上我觉得写 markdown 用 TOML Front Matter 才是反人类.

Hugo 通通 pipeline 可以支持很多东西: https://gohugo.io/hugo-pipes/

而 Zola 则局限于 SASS 的 Rust 绑定, 今天无法支持 PostCSS : https://zola.discourse.group/t/add-postcss-support/556

子目录支持方面, Zola 也是很糟心.

需要给每个子目录添加 _index.md 文件, 否则不会索引到 pages.

+++
paginate_by = 4
sort_by = "date"
transparent = true
+++

注意这里的 transparent = true 一定要添加. 要不然你在模板里面无法看到子目录的内容. paginate_by 也一定要添加, 要不然不会有 paginator

这是一种很奇怪的设定, Zola 和 Hugo 这方面是反的. Hugo 是默认支持子目录, Zola 则是默认不支持. 维护众多子目录下的 _index.md 文件是很糟糕的, 从这方面来说, Hugo 更实用.

Zola 的作者似乎比较武断, 表示无意支持 URL 生成规则: https://github.com/getzola/zola/issues/635

而 Hugo 则支持灵活地模板规则. 比如配置为 /post/:filename/ 则 /posts/sub1/sub2/my-post-filename.md 可以生成 /post/my-post-filename/index.html

而 Zola 则只能按照目录结构生成 /posts/sub1/sub2/my-post-filename.html

目前看来, Zola 也已经不再是新项目了, 但是作者对于一些东西的接纳程度, 仍然是制约其发展的主要因素. 社区的力量应该还是比较强大的, 但是作者的接纳程度, 可能是一个问题.

而 Hugo 可能在朝着另一个极端在发展, 不断地在添加新功能.

综合起来, 除非你对 Zola 有特别偏爱, 否则不要使用 Zola. 大部分情况下, Hugo 能很好的满足需求, 而 Zola 则不一定.

Refs

https://jamstack.org/generators/

https://gohugo.io/content-management/front-matter/

https://www.getzola.org/documentation/templates/pagination/

https://www.getzola.org/documentation/templates/overview/

https://www.getzola.org/themes/

https://themes.gohugo.io/

Fixup Epiphany Segmentation Fault Under Wayland

ttyS3 — Sat, 30 Jul 2022 12:07:38 GMT

缘由

自从老灯切到了 Wayland, 好像 epiphany 就基本上打不开了. 由于这个浏览器平常也不怎么用, 因此也就一直没管. 今天周末, 刚好抽空简单看下.

排查

先用 gdb 看看:

 ❯ gdb epiphany
GNU gdb (GDB) 12.1
This GDB supports auto-downloading debuginfo from the following URLs:
https://debuginfod.archlinux.org
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.

(gdb) r
Starting program: /usr/bin/epiphany
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

...



Thread 1 "epiphany" received signal SIGSEGV, Segmentation fault.
wl_resource_get_destroy_listener (resource=0x0, notify=0x7ffff1003980 <(anonymous namespace)::ClientBundleEGL::bufferDestroyListenerCallback(wl_listener*, void*)>) at ../wayland-1.21.0/src/wayland-server.c:850
850		if (resource_is_deprecated(resource))


(gdb) bt
#0  wl_resource_get_destroy_listener
    (resource=0x0, notify=0x7ffff1003980 <(anonymous namespace)::ClientBundleEGL::bufferDestroyListenerCallback(wl_listener*, void*)>) at ../wayland-1.21.0/src/wayland-server.c:850
#1  0x00007ffff1005b4b in (anonymous namespace)::ClientBundleEGL::findImage (bufferResource=0x0, this=0x55555686c9c0)
    at ../WPEBackend-fdo/src/view-backend-exportable-fdo-egl.cpp:270
#2  (anonymous namespace)::ClientBundleEGL::exportBuffer(wl_resource*) (this=0x55555686c9c0, bufferResource=0x0)
    at ../WPEBackend-fdo/src/view-backend-exportable-fdo-egl.cpp:181
#3  0x00007ffff18cb536 in ffi_call_unix64 () at ../src/x86/unix64.S:105
#4  0x00007ffff18c8037 in ffi_call_int
    (cif=<optimized out>, fn=<optimized out>, rvalue=<optimized out>, avalue=<optimized out>, closure=<optimized out>)
    at ../src/x86/ffi64.c:672
#5  0x00007ffff0403ada in wl_closure_invoke (closure=closure@entry=0x555556cd4880, target=<optimized out>, 
    target@entry=0x555556c7ba20, opcode=opcode@entry=6, data=<optimized out>, data@entry=0x555556a18b40, flags=2)
    at ../wayland-1.21.0/src/connection.c:1025
#6  0x00007ffff0408010 in wl_client_connection_data (fd=<optimized out>, mask=<optimized out>, data=<optimized out>)
    at ../wayland-1.21.0/src/wayland-server.c:437
#7  0x00007ffff04069e2 in wl_event_loop_dispatch (loop=0x5555559b30a0, timeout=<optimized out>)
    at ../wayland-1.21.0/src/event-loop.c:1027
#8  0x00007ffff10068c5 in operator() (__closure=0x0, base=0x555555a5f670) at ../WPEBackend-fdo/src/ws.cpp:77
#9  _FUN(GSource*, GSourceFunc, gpointer) () at ../WPEBackend-fdo/src/ws.cpp:86
#10 0x00007ffff734cc6b in g_main_dispatch (context=0x5555559210e0) at ../glib/glib/gmain.c:3417
#11 g_main_context_dispatch (context=0x5555559210e0) at ../glib/glib/gmain.c:4135
#12 0x00007ffff73a3001 in g_main_context_iterate.constprop.0
    (context=context@entry=0x5555559210e0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
    at ../glib/glib/gmain.c:4211
--Type <RET> for more, q to quit, c to continue without paging--c
#13 0x00007ffff734a392 in g_main_context_iteration (context=context@entry=0x5555559210e0, may_block=may_block@entry=1) at ../glib/glib/gmain.c:4276
#14 0x00007ffff750730e in g_application_run (application=0x5555559601d0, argc=argc@entry=1, argv=argv@entry=0x7fffffffd3b8) at ../glib/gio/gapplication.c:2569
#15 0x0000555555558714 in main (argc=<optimized out>, argv=<optimized out>) at ../epiphany/src/ephy-main.c:428
(gdb)

其实后台的调用栈基本上也没啥用. 简单的 segment fault 信息已经告诉我们原因了:

Thread 1 "epiphany" received signal SIGSEGV, Segmentation fault.
wl_resource_get_destroy_listener (resource=0x0, notify=0x7ffff1003980 <(anonymous namespace)::ClientBundleEGL::bufferDestroyListenerCallback(wl_listener*, void*)>) at ../wayland-1.21.0/src/wayland-server.c:850
850		if (resource_is_deprecated(resource))

调用wl_resource_get_destroy_listener 时传入的第一个 resource 参数是一个 null 指针, 导致 850 行的 resource_is_deprecated(resource) 调用 SIGSEGV 了

到这里你是不是觉得我要操刀开始去看代码了?

no. 首先,我打算把这个bt 信息给提交到 GNOME issue. 结果 Gitlab 的 issue 管理还是挺智能的. 当我敲出 "Epiphany crash Under Wayland" 时, 下面自动弹出了一些它觉得可能是同一个问题的issue, 于是我点进去了 https://gitlab.gnome.org/GNOME/epiphany/-/issues/1832

这个 issue creator 比我多做了一步, 他还尝试X11方式启动, 发现完全正常. 我试一下, GDK_BACKEND=x11 epiphany, 结果也是完全正常的.

GNOME 那边的人回复了, Michael Catanzaro @mcatanzaro (严格上来说是在 Red Hat的人):

Hi, you'll need to report this on the wpebackend-fdo issue tracker, here. Good luck....

随即issue马上被关闭了, 并加上了 Not GNOME label.

嗯, GNOME 的人关 issue 速度都挺快的.

上游的问题, 关了.

看上去是个悲伤的故事.

不过, 3分钟后, the guy 又回复了:

Actually, looks like it is already fixed by https://github.com/Igalia/WPEBackend-fdo/pull/176/ which is awaiting review. (CC @aperezdc)

这个修复主要就是像我们上面说的, 在调用 wl_resource_get_destroy_listener 之前, 判断第一个参数确保它不是 null 指针.

不过除了这个提交, 他还做了第二个提交:

Only delete images in releaseImage Deleting images in bufferDestroyListenerCallback is incorrect, and caused a double free.

https://github.com/Igalia/WPEBackend-fdo/pull/176/commits/fcf330cc3036808b6fb83ee7a6cef4f5ff9e00c8

所以, 专业的东西,还是得专业的人去修, 如果是由我们自己动手, 可能只会有第一个commit, 也就是 null 判断.

自己动手

等上游的上游修复, 上游再修复, package packer 再更新, 这个周期可能相当长. 好在 Arch 里面要自己编译一个带 patch 的东西是非常简单的事情. 这可能也是 Arch 最大的魔力之一吧.

下载官方的 https://github.com/archlinux/svntogit-packages/blob/packages/wpebackend-fdo/trunk/PKGBUILD 然后加一行 patch 命令即可.

至于 patch 文件, Github 的 PR 都是直接 URL 后面加上 .patch即可取: https://github.com/Igalia/WPEBackend-fdo/pull/176.patch

From 3318283ffe62a536cfbff307c77505d848d7098f Mon Sep 17 00:00:00 2001
From: Jordy Vieira <[email protected]>
Date: Sat, 9 Jul 2022 17:17:14 -0300
Subject: [PATCH 1/2] Fix SIGSEGV

---
 src/view-backend-exportable-fdo-egl.cpp | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/src/view-backend-exportable-fdo-egl.cpp b/src/view-backend-exportable-fdo-egl.cpp
index 09bb2bf..1a73269 100644
--- a/src/view-backend-exportable-fdo-egl.cpp
+++ b/src/view-backend-exportable-fdo-egl.cpp
@@ -267,9 +267,11 @@ class ClientBundleEGL final : public ClientBundle {
 private:
     struct wpe_fdo_egl_exported_image* findImage(struct wl_resource* bufferResource)
     {
-        if (auto* listener = wl_resource_get_destroy_listener(bufferResource, bufferDestroyListenerCallback)) {
-            struct wpe_fdo_egl_exported_image* image;
-            return wl_container_of(listener, image, bufferDestroyListener);
+        if (bufferResource) {
+            if (auto* listener = wl_resource_get_destroy_listener(bufferResource, bufferDestroyListenerCallback)) {
+                struct wpe_fdo_egl_exported_image* image;
+                return wl_container_of(listener, image, bufferDestroyListener);
+            }
         }

         return nullptr;

From fcf330cc3036808b6fb83ee7a6cef4f5ff9e00c8 Mon Sep 17 00:00:00 2001
From: Jordy Vieira <[email protected]>
Date: Sat, 9 Jul 2022 19:16:03 -0300
Subject: [PATCH 2/2] Only delete images in releaseImage

Deleting images in bufferDestroyListenerCallback is incorrect, and
caused a double free.
---
 src/view-backend-exportable-fdo-egl.cpp | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/src/view-backend-exportable-fdo-egl.cpp b/src/view-backend-exportable-fdo-egl.cpp
index 1a73269..0031222 100644
--- a/src/view-backend-exportable-fdo-egl.cpp
+++ b/src/view-backend-exportable-fdo-egl.cpp
@@ -247,8 +247,6 @@ class ClientBundleEGL final : public ClientBundle {

     void releaseImage(struct wpe_fdo_egl_exported_image* image)
     {
-        image->exported = false;
-
         if (image->bufferResource)
             viewBackend->releaseBuffer(image->bufferResource);
         else
@@ -297,9 +295,6 @@ class ClientBundleEGL final : public ClientBundle {
         image = wl_container_of(listener, image, bufferDestroyListener);

         image->bufferResource = nullptr;
-
-        if (!image->exported)
-            deleteImage(image);
     }
 };

打包好的文件老灯放这:

https://github.com/ttys3/my-archlinux-pkgbuild/releases/tag/wpebackend-fdo-1.12.0-2

paru -U ./wpebackend-fdo-1.12.0-2-x86_64.pkg.tar.zst 安装即可.

测试下, 不再 crash 了.

Refs

https://wiki.archlinux.org/title/Debuginfod

https://github.com/archlinux/svntogit-packages/blob/packages/wpebackend-fdo/trunk/PKGBUILD

cobra 终于移除了 viper 依赖

ttyS3 — Wed, 27 Jul 2022 15:15:35 GMT

cobra 可能是 Golang 里面最好用的 cli 命令行类库了. 没有之一.

其它也有一些功能类似的, 但是做到像 cobra 这样功能强大又简单易用的, 着实不多.

但是长期以来, cobra 依赖重量级的 viper module, 这两个东西都是同一个作者开发的, 因此其实也可以理解.

老灯最近突然发现, 随着社区力量的参与, cobra 的 viper 依赖居然在 1.4.0 版本被移除了!

老灯不是唯一一个不喜欢 viper 这种全家桶依赖类型的包的.

甚至有人 fork 出一份专门移除了 viper 依赖: https://github.com/muesli/coral

这个作者专门在 readme 说明了缘由:

I love Cobra and I love Viper. They are great projects, incredibly useful and outstandingly important for the Go community. But sometimes, just sometimes, don't you wish you could use Cobra without the entire dependency chain Viper drags in?
This is what Coral is: a Cobra fork without any of the Viper dependencies and features. This will hopefully be a soft fork with only the minimal changes required to decouple Viper from Cobra. The aim is to follow upstream Cobra development as closely as possible.

事实上由于 viper 依赖了问题, 老灯已经取消了 cobra star, 最近也是从 coral 的 readme 看到的消息, 作者甚至还贴心地给出了迁移命令:

Recent Cobra versions, v1.4.0 and onward, removed the dependency on Viper as well. You might switch back to Cobra using gofmt:

gofmt -w -r '"github.com/muesli/coral" -> "github.com/spf13/cobra"' .
gofmt -w -r '"github.com/muesli/coral/doc" -> "github.com/spf13/cobra/doc"' .
gofmt -w -r 'coral -> cobra' .

go get -u github.com/spf13/cobra
go mod tidy

其实 cobra 的 viper 依赖主要是其 cli 工具引入的, 因此 1.4.0 版本将这个 cli 工具放到单独的包里了.

go install github.com/spf13/cobra-cli@latest

serde自定义序列化

ttyS3 — Sun, 24 Jul 2022 16:39:45 GMT

serde 几乎是目前 Rust 生态中最常用的序列化与反序列化库了.

Golang 实现

作为一个 Golang 程序员来说, 免不了要对比一下.

Golang 官方库直接实现了 json 的序列化和反序列化.

对于序列化和反序列化, Go 都是用一个简单的接口interface表示:

// https://pkg.go.dev/encoding/json#Marshaler
type Marshaler interface {
	MarshalJSON() ([]byte, error)
}

// https://pkg.go.dev/encoding/json#Unmarshaler
type Unmarshaler interface {
	UnmarshalJSON([]byte) error
}

注意这个接口只是针对 JSON 的, 接口名后缀JSON 是有意义的. 因为对于同一个数据类型, 它可能需要实现很多种格式的序列化, 比如 yaml, toml 等. 如果按这个命名来, 它可能是: MarshalYaml, MarshalToml

看上去很简单是吧? 嗯, 是挺简单的. 但是其实这里是有坑的, 或者说, 实现的时候一定要注意一些细节.

Marshaler 的实现一定要用普通的receiver, (即不要只实现 pointer receiver的), 因为pointer only 会导致如果是非指针形式的时候, 在序列化的时候无法调用到我们自己实现的方法.

Unmarshaler 的实现一定要用 pointer receiver, 因为是解析数据到自身, 因此一定要修改自身, 不可修改是没有意义的.

举个例子, 假设我们想要JSON序列化一个自定义的int类型(主要用于作为enum的功能来用)为某些特定的string(主要用于JSON结构化日志的时候, 阅读更友好):

type HideType int

const (
	HideTypeNone     HideType = 0
	HideTypeLocation HideType = 1 << 0
	HideTypeAge      HideType = 1 << 1
	HideTypeSex      HideType = 1 << 2
	HideTypeNation   HideType = 1 << 3
)

var _hideTypeValuesMap = map[HideType]string{
	HideTypeNone:     "none",
	HideTypeLocation: "location",
	HideTypeAge:      "age",
	HideTypeSex:      "sex",
	HideTypeNation:   "nation",
}

var _hideTypeValueToType = map[string]HideType{
	"none":     HideTypeNone,
	"location": HideTypeLocation,
	"age":      HideTypeAge,
	"sex":      HideTypeSex,
	"nation":   HideTypeNation,
}

func (ht HideType) String() string {
	if val, ok := _hideTypeValuesMap[ht]; ok {
		return val
	}
	return "unknown"
}

// MarshalJSON impl Marshaler interface https://pkg.go.dev/encoding/json#Marshaler
func (ht HideType) MarshalJSON() ([]byte, error) {
	return []byte(fmt.Sprintf(`"%v"`, ht.String())), nil
}

// UnmarshalJSON impl Unmarshaler interface
// https://pkg.go.dev/encoding/json#Unmarshaler
func (ht *HideType) UnmarshalJSON(rawJSON []byte) error {
	htStr := bytes.Trim(rawJSON, `"`)
	if htInt, ok := _hideTypeValueToType[string(htStr)]; ok {
		*ht = htInt
		return nil
	}
	return fmt.Errorf("parse into HideType failed, unknown HideType: %v", htStr)
}

没错, 整个实现非常简单, 对于 MarshalJSON() 我们只需要返回我们想要返回的 JSON string 即可. 注意这里一定要返回合法的JSON string类型. 这里使用了 "%v", 而没有使用 %q, 主要是因为在我们的使用场景(类似enum)下100%确定不会有需要再次转义, 如果不确定的场景, 最好还是要用 %q.

UnmarshalJSON 我们由于确定输入是合法并且格式一定是特定的, 因此处理上也非常简单.不需要考虑过多.

Rust 实现

当然, serde 本身就可以处理这种序列化, 我们只需要加上#[derive(Serialize, Deserialize, Debug)] 即可. 这里特意用的自定义方式实现, 主要是从学习的角度.

序列化实现比较简单, Rust 里面我们只需要实现 Serialize trait 即可:

pub trait Serialize {
    fn serialize<S>(&self, serializer: S) -> Result<S::Ok, S::Error>
    where
        S: Serializer;
}

反序列化相对来说麻烦一些. 不像 Go 里面简单粗暴, 实现细节交给用户来处理, serde 里面需要按照 serde data model 来交换数据.

单从 Deserialize trait 来看, 好像反序列化也差不多. 但是实际上它还需要一个 Vistor trait

pub trait Deserialize<'de>: Sized {
    fn deserialize<D>(deserializer: D) -> Result<Self, D::Error>
    where
        D: Deserializer<'de>;
}

从语法上来说, Visitor trait 只有一个 expecting 方法是必须实现的, 但是实际使用中我们要根据具体的JSON 数据类型选择实现其它方法. 比如在我们这个例子中, 我们可以明确的确定, 我们收到的 JSON 数据是一个字符串类型的, 因此只需要visit_str, 注意 visit_str 比起 Golang 里面要用户手动解析 JSON 数据, serde 里面已经默认把数据给我们解析出来了, 所以, 当输入是 "foo" 的时候, 在 serde 里面我们visit_str得到的是 foo, 而在 Go 里面我们由于得到的是 "foo", 因此还要自行处理外面的引号.

最后, 我们要将这个实现了 Visitor trait 的类型, 绑定到我们要反序列化的类型的Deserialize trait 上面: deserializer.deserialize_str(HideTypeVisitor)

pub trait Visitor<'de>: Sized {
    /// The value produced by this visitor.
    type Value;

    /// Format a message stating what data this Visitor expects to receive.

    fn expecting(&self, formatter: &mut fmt::Formatter) -> fmt::Result;
    /// ...
}

use std::collections::HashMap;
use std::fmt;
use serde::{Serialize, Deserialize, Serializer, Deserializer};

use serde::de::{Error, Unexpected, Visitor};

use once_cell::sync::Lazy;

[derive(Copy, Clone, PartialEq, Eq, Hash, Debug)]
enum HideType {
    HideTypeNone = 0,
    HideTypeLocation = 1 << 0,
    HideTypeAge = 1 << 1,
    HideTypeSex = 1 << 2,
    HideTypeNation = 1 << 3,
}

static FILTER_TYPE_TO_NAME: [(HideType, &str); 5] = [
    (HideType::HideTypeNone, "none"),
    (HideType::HideTypeLocation, "location"),
    (HideType::HideTypeAge, "age"),
    (HideType::HideTypeSex, "sex"),
    (HideType::HideTypeNation, "nation"),
];

static TYPE_STR_MAP: Lazy<HashMap<HideType, &str>> = Lazy::new(|| {
    let mut m = HashMap::new();
    for (k, v) in FILTER_TYPE_TO_NAME.iter() {
        m.insert(*k, *v);
    }
    m
});

static STR_TYPE_MAP: Lazy<HashMap<&str, HideType>> = Lazy::new(|| {
    let mut m = HashMap::new();
    for (k, v) in FILTER_TYPE_TO_NAME.iter() {
        m.insert(*v, *k);
    }
    m
});

impl Serialize for HideType {
    fn serialize<S>(&self, serializer: S) -> Result<S::Ok, S::Error>
        where
            S: Serializer,
    {
        return TYPE_STR_MAP.get(self).unwrap().serialize(serializer);
    }
}

struct HideTypeVisitor;

impl<'de> Visitor<'de> for HideTypeVisitor {
    type Value = HideType;

    fn expecting(&self, formatter: &mut fmt::Formatter) -> fmt::Result {
        formatter.write_str(r#"a string in one of: none, location, age, sex, nation"#)
    }

    fn visit_str<E>(self, v: &str) -> Result<Self::Value, E>
        where
            E: Error,
    {
        match STR_TYPE_MAP.get(v) {
            Some(t) => Ok(*t),
            None => Err(E::invalid_value(Unexpected::Str(v), &self)),
        }
    }
}

impl<'de> Deserialize<'de> for HideType {
    fn deserialize<D>(deserializer: D) -> Result<HideType, D::Error>
        where
            D: Deserializer<'de>,
    {
        deserializer.deserialize_str(HideTypeVisitor)
    }
}

当然, 这里也并不一定要用到 hashmap, 直接用 match 处理从类型到 string的转换也是可以的. 不过通过 hashmap 的方式会比较自然, 并且我们不再需要手动去维护一个正向和反向的 map 了.

总体来说, Golang 里面实现自定义序列化和反序列化, 比较直接和简单粗暴. 整个接口的定义也非常简单. 而 Rust 里的 serde 则有很多功能和功能. 首先你一定要了解的是 serde data model. 相比于 Golang 里面直接用 Go 的类型, 并且其默认实现直接将 Go 的类型, 比如 []byte 绑定到其实现上 ([]byte类型的数据在序列化后会被Golang转换成base64的表现形式). serde 里面是通过 serde data model 来实现数据映射的. 而 serde 本身是一个框架, 并不负责实现, 其实现由扩展提供, 如 serde_json, serde_yaml 等. 所以 serde 的好处是, trait 是统一的, 而 Go 里面则是各实现各的, 比如官方实现了 JSON, 第三方实现了 YAML 等.

比如 yaml:

UnmarshalYAML(value *Node) error

官方 JSON:

UnmarshalJSON([]byte) error

可以看到, 虽然命名和参数样子差不多, 但是实际上还是不一样, 当然, 官方也并没有任何规范说明要一样. 实际上也不能做成一样, 假设 json 和 yaml 的 Unmarshaler interface 都定义为 Unmarshal([]byte) error, 由于 Go 的 interface 是鸭子类型, 这会导致错误的断言.

另外一点就是, 由于 serde 是一个框架, 而我们的自定义序列化也是映射到框架的数据模型, 因此是跟语言(json, yaml, toml 等)无关的. 可以做到一次定义, 到处运行. 而 Golang 的自定义序列化一定是针对某个类型的(比如 JSON), 上面的示例, 如果换成 yaml, 还得重新实现一次, 而 serde 则不存在这个问题.

2022-07-27 补充:

还有一点就是序列化字段重命名, golang 是通过给 struct 打 tag 的方式, 不同的语言需要不同的tag, 如何解析这个 tag 是序列化mod所负责的工作, 比如 json 用的是 `json`, yaml 用的是 `yaml`, 而数据库相关的 gorm 用的是 `gorm`, 因此从这一点来说, golang 的 struct tag 并不是专门用于序列化. 还可以用在其它地方.

而 Rust 的字段重命名是在框架层面的, 也就是说, 指定了rename后, 无论是 json 还是 yaml 都会按照这个来, 优点是不必要重复地添加很多 tag. (对比: golang 一个 struct 要同时加上 json, yaml, toml 甚至 bson 的 tag, 就显得很没有可读性, 但是如果你不加, 有些字段可能序列化出来不是你要的结果, 比如 ID 在 mongodb 里面要用 `_id` )

Refs

https://pkg.go.dev/encoding/json#Marshaler

https://pkg.go.dev/encoding/json#Unmarshaler

https://serde.rs/data-model.html

https://serde.rs/impl-serialize.html

https://serde.rs/impl-deserialize.html

使用giscus作为评论系统

ttyS3 — Sun, 24 Jul 2022 16:24:07 GMT

giscus: A comments system powered by GitHub Discussions

老灯之前用的是 utteranc.es, 这个是基于 Github issue 功能实现的.

giscus 是基于 discussion, 简单试用了一下, 最明显的区别回复的功能吧. 可以直接在某个评论下面回复.

第二就是支持reaction.

新建一个专门的仓库用来做评论用即可. 具体做法很简单:

Choose the repository giscus will connect to. Make sure that:

The repository is public, otherwise visitors will not be able to view the discussion.
The giscus app is installed, otherwise visitors will not be able to comment and react.
The Discussions feature is turned on by enabling it for your repository.

comments.html

<!-- giscus https://giscus.vercel.app/ -->
{{ if and (.Params.comments) (ne "" $.Site.Params.giscus.dataRepo) }}
<script src="https://giscus.app/client.js"
        data-repo="{{ $.Site.Params.giscus.dataRepo }}"
        data-repo-id="{{ $.Site.Params.giscus.dataRepoID }}"
        data-category="{{ $.Site.Params.giscus.dataCategory }}"
        data-category-id="{{ $.Site.Params.giscus.dataCategoryID }}"
        data-mapping="pathname"
        data-strict="0"
        data-reactions-enabled="1"
        data-emit-metadata="0"
        data-input-position="bottom"
        data-theme="dark_protanopia"
        data-lang="en"
        data-loading="lazy"
        crossorigin="anonymous"
        async>
</script>
{{ end }}

配置:

params:
  giscus:
    dataRepo: ''
    dataRepoID: "R_xxxxxxxxxx"
    dataCategory: "General"
    dataCategoryID: "DIC_xxxxxxxxx"

注意, 这些配置参数都是 https://giscus.vercel.app/ 自动生成了.

简单修复 intellij-scheme

ttyS3 — Mon, 25 Apr 2022 16:04:58 GMT

tree-sitter 的 highlights.scm 是 S 表达式, 最近安装了 intellij-scheme, 主要是看个高亮.

然后发现它天天 panic, 这个插件当前的发布者也是 fork 了前人的, 看样子也没什么人维护.

于是决定简单地处理一下, 至少能看个高亮吧.

Dirty and quick fix up

关于 JDK 版本, 注意, https://plugins.jetbrains.com/docs/intellij/setting-up-environment.html#configuring-intellij-platform-sdk 有专门强调:

Set up a required Java SDK. See the IntelliJ Build Configuration section of Check Out And Build Community Edition for instructions about creating 1.8 (11 when targeting 2020.3 or later) Java SDK.

Do not use a more recent Java version than the one specified.

Arch 自带的默认已经是 JDK 18 了. 这里我们需要安装 JDK 11.

paru -S jdk11-openjdk

# 找到 jdk 的 JAVA_HOME 为 /usr/lib/jvm/java-11-openjdk/
paru -Qlv jdk11-openjdk | grep -i  /bin/java

update failed for AnAction(schemely.repl.toolwindow.actions.NewInProcessConsoleAction, id=schemely.repl.toolwindow.actions.NewInProcessConsoleAction) with text=Start In-Process Scheme Console

java.lang.NoClassDefFoundError: com/intellij/openapi/actionSystem/DataKeys
	at schemely.utils.Actions.getModule(Actions.java:16)
	at schemely.repl.toolwindow.actions.NewInProcessConsoleAction.update(NewInProcessConsoleAction.java:24)
	at com.intellij.openapi.actionSystem.ex.ActionUtil.lambda$performDumbAwareUpdate$0(ActionUtil.java:131)
	at com.intellij.openapi.actionSystem.ex.ActionUtil.performDumbAwareUpdate(ActionUtil.java:145)
	at com.intellij.openapi.actionSystem.impl.ActionUpdater.doUpdate(ActionUpdater.java:639)
	at com.intellij.openapi.actionSystem.impl.ActionUpdater.lambda$updateActionReal$4(ActionUpdater.java:125)
	at com.intellij.openapi.actionSystem.impl.ActionUpdater.lambda$computeOnEdt$6(ActionUpdater.java:209)
	at com.intellij.openapi.progress.ProgressManager.lambda$runProcess$0(ProgressManager.java:58)
	at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcess$2(CoreProgressManager.java:189)
	at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$executeProcessUnderProgress$12(CoreProgressManager.java:608)
	at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:683)
	at com.intellij.openapi.progress.impl.CoreProgressManager.computeUnderProgress(CoreProgressManager.java:639)
	at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:607)
	at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:60)
	at com.intellij.openapi.progress.impl.CoreProgressManager.runProcess(CoreProgressManager.java:176)
	at com.intellij.openapi.progress.ProgressManager.runProcess(ProgressManager.java:58)
	at com.intellij.openapi.actionSystem.impl.ActionUpdater.lambda$computeOnEdt$7(ActionUpdater.java:207)
	at com.intellij.openapi.actionSystem.impl.ActionUpdateEdtExecutor.lambda$computeOnEdt$0(ActionUpdateEdtExecutor.java:45)
	at com.intellij.openapi.application.TransactionGuardImpl$1.run(TransactionGuardImpl.java:200)
	at com.intellij.openapi.application.impl.ApplicationImpl.runIntendedWriteActionOnCurrentThread(ApplicationImpl.java:873)
	at com.intellij.openapi.application.impl.ApplicationImpl$3.run(ApplicationImpl.java:511)
	at com.intellij.openapi.application.impl.FlushQueue.doRun(FlushQueue.java:69)
	at com.intellij.openapi.application.impl.FlushQueue.runNextEvent(FlushQueue.java:112)
	at com.intellij.openapi.application.impl.FlushQueue.flushNow(FlushQueue.java:42)
	at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:313)
	at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:776)
	at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:727)
	at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
	at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:746)
	at com.intellij.ide.IdeEventQueue.defaultDispatchEvent(IdeEventQueue.java:898)
	at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:746)
	at com.intellij.ide.IdeEventQueue.lambda$dispatchEvent$6(IdeEventQueue.java:439)
	at com.intellij.openapi.progress.impl.CoreProgressManager.computePrioritized(CoreProgressManager.java:803)
	at com.intellij.ide.IdeEventQueue.lambda$dispatchEvent$7(IdeEventQueue.java:438)
	at com.intellij.openapi.application.TransactionGuardImpl.performActivity(TransactionGuardImpl.java:106)
	at com.intellij.ide.IdeEventQueue.performActivity(IdeEventQueue.java:604)
	at com.intellij.ide.IdeEventQueue.lambda$dispatchEvent$8(IdeEventQueue.java:436)
	at com.intellij.openapi.application.impl.ApplicationImpl.runIntendedWriteActionOnCurrentThread(ApplicationImpl.java:873)
	at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:484)
	at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:207)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:128)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:117)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:113)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:105)
	at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:92)
Caused by: java.lang.ClassNotFoundException: com.intellij.openapi.actionSystem.DataKeys PluginClassLoader(plugin=PluginDescriptor(name=Scheme, id=intellij-scheme, descriptorPath=plugin.xml, path=~/.local/share/JetBrains/Toolbox/apps/CLion/ch-0/221.5080.224.plugins/intellij-scheme, version=0.1.6, package=null, isBundled=false), packagePrefix=null, instanceId=15, state=active)
	at com.intellij.ide.plugins.cl.PluginClassLoader.loadClass(PluginClassLoader.java:215)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
	... 47 more

由于时间有限, 而且我只是要年高亮而已. 简单修复了下, 移除了 REPL 相关代码. 顺利通过编译.

https://github.com/ttys3/intellij-scheme/releases/tag/v0.1.7

Refs

https://plugins.jetbrains.com/docs/intellij/getting-started.html#using-devkit

https://plugins.jetbrains.com/docs/intellij/setting-up-environment.html#configuring-intellij-platform-sdk

https://plugins.jetbrains.com/docs/intellij/creating-plugin-project.html#adding-code-to-the-project

https://plugins.jetbrains.com/docs/intellij/deploying-plugin.html

Fedora 36 Installation

ttyS3 — Mon, 18 Apr 2022 14:25:30 GMT

F36 当前已经 Beta, 不出意外, 4月份应该会正式发布.

由于发现磁盘还有一点空闲空间, 想来可以装一个 F36 玩玩. 主要是想体验它的默认 btrfs 文件系统.

从 Fedora 33 起, btrfs 就已经是Fedora Linux 桌面版本的默认文件系统, 但是老灯当时是从 Fedora 31 升级的, 由于F33之前都是默认 ext4, 因此, 即使升级到 F33, 也还是用的 ext4.

安装配置

整个安装过程还是非常顺利的, 并且安装过程比较简单, 点两下鼠标就搞定了.

安装后第一次进系统会要求创建第一个用户, 然后是有个启用第三方源(主要是 rpmfusion) 的选项, 默认是蓝色启用的.

所以 rpmfusion 也不用单独安装了.

默认的分区方案是一个 btrfs root volume, 然后 / 用 /root subvolume, /home 用 /home subvolume, 同时 /boot 使用单独分区, 且保持使用 ext4:

[ttys3@fedora ~]$ mount | rg 'btrfs|ext4|vfat'
/dev/nvme0n1p5 on / type btrfs (rw,relatime,seclabel,compress=zstd:1,ssd,space_cache=v2,subvolid=257,subvol=/root)
/dev/nvme0n1p5 on /home type btrfs (rw,relatime,seclabel,compress=zstd:1,ssd,space_cache=v2,subvolid=256,subvol=/home)
/dev/nvme0n1p4 on /boot type ext4 (rw,relatime,seclabel)
/dev/nvme0n1p1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro)

第一件事, 我们要调整一下 dnf 配置 /etc/dnf/dnf.conf

增加 max_parallel_downloads=8 或 max_parallel_downloads=16 (主要看你网速)

第一次启动后, `sudo dnf upgrade -y` 更新系统到最新内核并重启 (主要是为了后面安装显卡驱动).

nvidia 专有驱动安装

重启后, 我们先把显卡驱动安装了. 默认启动时加载的是 nouveau 开源驱动. 4K 屏流畅度一般, 切成专有驱动丝滑.

sudo dnf install akmod-nvidia -y

成功安装 nvidia 驱动后再重启一次系统.

好了, 再次重启后, 我们 cat /proc/cmdline 验证下 n 卡驱动的内核参数是不是正常, 主要驱动就是添加了 rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1, 即屏蔽开源驱动nouveau, 并启用 nvidia_drm 内核模块的 modeset (即 KMS)

老灯还有个习惯就是, 编辑 /etc/default/grub, 并删除 rhgb, 修改 quiet 为 noquiet. (需要sudo grub2-mkconfig -o /etc/grub2-efi.cfg 然后重启的时候才能看到效果)

在老灯看来, rhgb 不利于排查问题. (当系统真出现问题的时候, 你两眼一摸黑, 不知道卡在哪一步了)

Google Chrome 的安装方法参考 https://docs.fedoraproject.org/en-US/quick-docs/installing-chromium-or-google-chrome-browsers/

# Install Third Party Repositories
sudo dnf install fedora-workstation-repositories

# Enable the Google Chrome repo
sudo dnf config-manager --set-enabled google-chrome

# Finally, install Chrome
sudo dnf install google-chrome-stable

安装 zsh 并设置为 login shell:

sudo dnf install -y zsh

# 给 root 改:
# 提示时输入 /usr/bin/zsh
sudo lchsh

# 给当自己的用户名改:
# 提示时输入 /usr/bin/zsh
sudo lchsh username

安装一些必要小工具:

dnf install -y ripgrep htop nload ncdu neovim xlsclients neofetch gedit gnome-tweaks

安装完整版的 java:

Fedora 有个坏毛病就是, 默认安装的是 headless 版的 openjdk (F36 是 java-17-openjdk-headless), 如果需要 GUI 支持, 还要安装另一个包. 如果不安装, 你在运行基于 JAVA 的 GUI 程序时可能会遇到 "Can’t load library libawt_xawt.so" 的错误

[root@fedora yum.repos.d]# dnf list --installed | rg java
abrt-java-connector.x86_64                           1.3.1-3.fc36                        @anaconda       
java-17-openjdk-headless.x86_64                      1:17.0.2.0.8-7.fc36                 @anaconda       
javapackages-filesystem.noarch                       6.0.0-7.fc36                        @anaconda       
tzdata-java.noarch                                   2022a-1.fc36                        @fedora

sudo dnf install -y java-17-openjdk

F33 起 Fedora 的默认编辑器就成了 nano 了, 如果你想恢复 vim 为默认编辑器, 下面的命令会安装vim为默认编辑器并卸载nano--default-editor 包.

sudo dnf install vim-default-editor --allowerasing

输入法安装, 我习惯五笔:

sudo dnf install -y ibus-rime ibus-table-chinese-wubi-jidian

git clone https://github.com/ttys3/rime-wubi $HOME/.config/ibus/rime

using ibus-setup and add Chinese - Rime and English - English Input Method

go to Gnome Keyboard add Chinese(Rime)

编辑 /etc/environment 加上:

GTK_IM_MODULE=ibus
QT_IM_MODULE=ibus
XMODIFIERS=@im=ibus
INPUT_METHOD=ibus
SDL_IM_MODULE=ibus
GLFW_IM_MODULE=ibus

编译安装 neovim 最新版 (注: 也可以使用 sudo dnf builddep neovim 安装构建依赖):

sudo dnf groupinstall "Development Tools" "Development Libraries"
sudo dnf install -y cmake ninja-build gcc-c++ libtool

git clone https://github.com/ttys3/nvim-config.git $HOME/.config/nvim
cd $HOME/.config/nvim && make nvim

安装 golang

sudo dnf install -y golang-bin

安装 rust (ref https://www.rust-lang.org/tools/install)

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

安装完成后, ~/.zshrc 加上:

export RUSTUP_DIST_SERVER="https://rsproxy.cn"
export RUSTUP_UPDATE_ROOT="https://rsproxy.cn/rustup"
source $HOME/.cargo/env

去 https://www.nerdfonts.com/font-downloads 下载 nerdfont 并安装:

老灯主要下载了 Iosevka 和 JetBrainsMono

mkdir -p ~/.local/share/fonts
cp -r JetBrainsMono ~/.local/share/fonts/
cp -r IosevkaNerd ~/.local/share/fonts/

打开 gnome-tweaks 调整默认的 monospace 字体为 JetBrainsMono 或 Iosevka

grub配置更新:

sudo grub2-mkconfig -o /etc/grub2-efi.cfg

这里有点问题, 默认 Fedora 的 grub 扫到了我的 Arch grub 配置, 但是添加的条目有问题:

Arch 正确的menu是:

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Arch Linux' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-dc941692-cb41-44bc-9bf0-f045fc1fd9f8' {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_gpt
	insmod ext2
	search --no-floppy --fs-uuid --set=root a79b862f-1a07-413f-9537-3922300b3436
	echo	'Loading Linux linux ...'
	linux	/vmlinuz-linux root=/dev/mapper/vgarch-lvroot rw  loglevel=3 noquiet nvidia-drm.modeset=1
	echo	'Loading initial ramdisk ...'
	initrd	/intel-ucode.img /initramfs-linux.img
}

Fedora 生成的 arch 启动menu 是这样的:

### BEGIN /etc/grub.d/30_os-prober ###
	menuentry 'Arch Linux (on /dev/mapper/vgarch-lvroot)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/vmlinuz-linux--dc941692-cb41-44bc-9bf0-f045fc1fd9f8' {
		insmod part_gpt
		insmod ext2
		search --no-floppy --fs-uuid --set=root a79b862f-1a07-413f-9537-3922300b3436
		linux /vmlinuz-linux root=/dev/mapper/vgarch-lvroot rw loglevel=3 noquiet nvidia-drm.modeset=1
		initrd /intel-ucode.img
	}

没错, 最后那一行 initrd /intel-ucode.img 错了. 正确的应该是 initrd /intel-ucode.img /initramfs-linux.img

其它Wayland 相关配置请参考 /post/upgrade-to-gnome-42-and-switch-to-wayland/

Refs

https://fedoraproject.org/wiki/Changes/BtrfsByDefault

https://fedoraproject.org/wiki/GRUB_2

https://github.com/neovim/neovim/wiki/Building-Neovim#building

https://ask.fedoraproject.org/t/java-cant-find-library/10128

Config mpv as a Better Player

ttyS3 — Sat, 09 Apr 2022 12:15:06 GMT

缘由

产生这篇文章的原因是, 最近老灯从 X11 切 Wayland 了, 而 SMPlayer 又不工作了.

GNOME 官方的 Video 播放器也能凑合用. 但是老灯还是习惯 mpv 系列.

但是直接用 mpv 感觉还是不太习惯, 比如外挂字幕选择加载 mpv 貌似没有快捷键, 播放列表管理功能貌似也没有.

很快在 Github 上面找到一个神级脚本: https://github.com/darsain/uosc

还有一个堪称播放器级别的配置: https://github.com/thisisshihan/mpv-player-config-snad

mpv 配置目录

首先, 老灯机器上面甚至没有一个 mpv 的配置.

所以, 先找文档看看配置文件在哪?

在 Arch 上, mpv 系统全局配置目录在 /etc/mpv/

老灯看了下, 这个目录下面只有一个 encoding-profiles.conf文件

然后, 一般情况下, 标准的用户配置目录在 ~/.config/mpv , 当然还有一些特例, 比如:

The standard configuration directory. This can be overridden by environment variables, in ascending order:
1: If $XDG_CONFIG_HOME is set, then the derived configuration directory will be $XDG_CONFIG_HOME/mpv. 2: If $MPV_HOME is set, then the derived configuration directory will be $MPV_HOME.
If this directory, nor the original configuration directory (see below) do not exist, mpv tries to create this directory automatically.

主要用户配置文件: ~/.config/mpv/mpv.conf

主要的 key bindings 配置: ~/.config/mpv/input.conf

字体配置: ~/.config/mpv/fonts.conf

Fontconfig fonts.conf that is customized for mpv. You should include system fonts.conf in this file or mpv would not know about fonts that you already have in the system.
Only available when libass is built with fontconfig.

字体目录: ~/.config/mpv/fonts/

Font files in this directory are used by mpv/libass for subtitles. Useful if you do not want to install fonts to your system. Note that files in this directory are loaded into memory before being used by mpv. If you have a lot of fonts, consider using fonts.conf (see above) to include additional fonts, which is more memory-efficient.

脚本目录: ~/.config/mpv/scripts/

osc配置: ~/.config/mpv/script-opts/osc.conf

This is loaded by the OSC script. See the ON SCREEN CONTROLLER docs for details.

Other files in this directory are specific to the corresponding scripts as well, and the mpv core doesn't touch them.

uosc 安装

安装后的目录结构:

  ~/.config/mpv 
❯ tree
.
├── input.conf
├── mpv.conf
├── script-opts
│   └── uosc.conf
└── scripts
    └── uosc.lua

2 directories, 4 files

uosc is a replacement for the built in osc, so that has to be disabled first.

由于 uosc 实际上是内置 osc 功能的替代品, 因此内置的必须先禁用掉:

编辑 ~/.config/mpv/mpv.conf 加上:

# required so that the 2 UIs don't fight each other
osc=no
# uosc provides its own seeking/volume indicators, so you also don't need this
osd-bar=no
# uosc will draw its own window controls if you disable window border
border=no

下载脚本和脚本配置

curl -sSf --create-dirs -o $HOME/.config/mpv/scripts/uosc.lua \
https://raw.githubusercontent.com/darsain/uosc/master/uosc.lua

curl -sSf --create-dirs -o $HOME/.config/mpv/script-opts/uosc.conf \
https://raw.githubusercontent.com/darsain/uosc/master/uosc.conf

Keybindings 配置

编辑 ~/.config/mpv/input.conf 加上:

menu        script-binding uosc/menu
mbtn_right  script-binding uosc/menu
o           script-binding uosc/open-file          #! Open file
alt+s       script-binding uosc/load-subtitles     #! Load subtitles
S           script-binding uosc/subtitles          #! Select subtitles
A           script-binding uosc/audio              #! Select audio
ctrl+s      async screenshot                       #! Utils > Screenshot
P           script-binding uosc/playlist           #! Utils > Playlist
C           script-binding uosc/chapters           #! Utils > Chapters
#           script-binding uosc/open-config-directory #! Utils > Open config directory
#           set video-aspect-override "-1"         #! Aspect ratio > Default
#           set video-aspect-override "16:9"       #! Aspect ratio > 16:9
#           set video-aspect-override "4:3"        #! Aspect ratio > 4:3
#           set video-aspect-override "2.35:1"     #! Aspect ratio > 2.35:1
O           script-binding uosc/show-in-directory  #! Show in directory
esc         quit #! Quit
q           quit #!

这个键绑定老灯稍做了修改:

主要改动为:

ctrl+o      script-binding uosc/open-file          #! Open file
alt+o       script-binding uosc/show-in-directory  #! Show in directory

打开文件这两个操作老灯认为没有显示 osd 频繁, 因此 o 留给 osd toggle.

效果展示

选择视频文件打开:

内置字幕选择(支持方向键和 vim hjkl 或游戏党的 wasd):

utils 功能:

播放列表功能 (相应的快捷键见 input.conf ):

其它 mpv 内置快捷键

F8 Show the playlist and the current position in it (useful only if a UI window is used, broken on the terminal).

F9 Show the list of audio and subtitle streams (useful only if a UI window is used, broken on the terminal).

i and I Show/toggle an overlay displaying statistics about the currently playing file such as codec, framerate, number of dropped frames and so on. See STATS for more information.

del Cycle OSC visibility between never / auto (mouse-move) / always

` Show the console. (ESC closes it again. See CONSOLE.)

o (also P) Show progression bar, elapsed time and total duration on the OSD.

O Toggle OSD states between normal and playback time/duration.

v Toggle subtitle visibility.

j and J Cycle through the available subtitles.

z and Z Adjust subtitle delay by +/- 0.1 seconds. The x key does the same as Z currently, but use is discouraged.

9 and 0 Decrease/increase volume.

m Mute sound.

_ Cycle through the available video tracks.

#

Cycle through the available audio tracks.

f Toggle fullscreen (see also --fs).

ESC Exit fullscreen mode.

T Toggle stay-on-top (see also --ontop).

最后, 老灯折腾完的配置在这: https://github.com/ttys3/my-mpv-config

Refs

https://github.com/darsain/uosc

https://mpv.io/manual/master/#files

https://mpv.io/manual/master/#configuration-files

https://mpv.io/manual/master/#input-conf

https://github.com/mpv-player/mpv/blob/master/etc/input.conf

https://iamscum.wordpress.com/guides/videoplayback-guide/mpv-conf/

https://github.com/thisisshihan/mpv-player-config-snad

其它资源:

资源获取:

https://github.com/mpv-player/mpv/wiki/User-Scripts

https://github.com/topics/mpv-script?o=desc&s=stars

https://github.com/topics/mpv-config

老灯看到觉得不错的:

windows https://github.com/422658476/MPV-EASY-Player

windows https://github.com/hooke007/MPV_lazy

https://github.com/jonniek/mpv-playlistmanager

https://github.com/CogentRedTester/mpv-file-browser

https://github.com/maoiscat/mpv-osc-morden

https://github.com/hl2guide/better-mpv-config/blob/master/mpv.conf

Upgrade to GNOME 42 and Switch To Wayland (updated)

ttyS3 — Sat, 09 Apr 2022 03:10:39 GMT

我能说我这么多年用 N 卡一直是在跑 X11 么?
今天终于能换 Wayland 了

OS: Arch Linux x86_64

Kernel: 5.17.1-arch1-1

Card: GeForce GTX 1060

Resolution: 3840x2160

DE: GNOME 42.0

WM: Mutter

背景

Wayland 的支持看上去已经较为完善了.

比如近期 Ubuntu 和 Fedora 都会在 4 月份发布的新版本中默认对于 Nvidia 510版本以上的驱动使用 Wayland:

Ubuntu 22.04 LTS Will Default To Wayland With NVIDIA For v510+ Driver

Fedora Linux 36 changed to Wayland By Default with NVIDIA proprietary Driver

注意: 之所以有"Nvidia 510版本以上的驱动"这个限制, 一是因为 510 之前这个驱动对于 Wayland 支持有问题. 二是因为, 对于其它驱动, 其实 Fedora 早在 Fedora 25 就已经是默认 Wayland 了.

see https://fedoraproject.org/wiki/Changes/WaylandByDefaultOnNVIDIA#Benefit_to_Fedora

Fedora has changed to Wayland by default since Fedora 22, but the NVIDIA proprietary driver has been an exception ever since (either because originally Wayland would be disabled with NVIDIA drivers, or more recently Xorg would be used by default).

另外还有 Fedora 吐槽 NVIDIA 专属驱动: Fedora Project Leader Calls Out NVIDIA Over Their Proprietary Linux Drivers

我们看下 Arch 上面的进度:

2个月前: 有第三方构建了 GNOME unstable

10天前: hitting Arch Linux gnome-unstable repo

5天前: GNOME 42 已经进入 Arch testing 仓库了

2天前: Gnome 42 is here! Check out Extra Repo

事实上我是2天之前得知消息的当天就升级到了 GNOME 42, 同时我的机器都是Nvidia显卡的, 因此同时也切换到了 Wayland.

升级到GNOME 42, 本身没有什么大问题. 主要的问题来自于当前一些应用对于 Wayland 的支持程度(部分需要添加额外的flags), 有一些甚至完全不支持(只能跑在xwayland下面).

本文主要分享一下踩过的坑及一些解决办法.

升级操作

升级本身没有什么特别要注意的. 直接 paru 就好了.

注意安装 wayland 支持

paru -S --needed glfw-wayland xorg-xwayland wayland-utils qt6-wayland qt5-wayland

锁屏解锁问题

注意升级后去 https://extensions.gnome.org/local/ 升级所有能升级的 extensions.

https://extensions.gnome.org/extension/2935/control-blur-effect-on-lock-screen/ 如果安装了这个插件要卸载掉. 会有一定概率导致锁屏后无法登录回原来的会话. 具体的问题是: 锁屏, 然后解锁, 在输入密码框你准备输入密码的时候, GNOME 把所有当前会话启动的进程杀死, 然后 GDM 重启, 退回到登录界面, 这个时候你再进去, 已经跟重启登录没两样了, 进程都被杀死了.

可以启用 gdm debug 看到更详细的过程, 编辑 /etc/gdm/custom.conf 启用 Enable=true:

[debug]
# Uncomment the line below to turn on debugging
Enable=true

重启 gdm 生效.

休眠问题

休眠功能是有问题的. 必须禁用.

检查一下界面展示的配置 ( Settings - Power ) 和实际的配置是不是一致:

❯ gsettings list-recursively org.gnome.settings-daemon.plugins.power
org.gnome.settings-daemon.plugins.power ambient-enabled true
org.gnome.settings-daemon.plugins.power idle-brightness 30
org.gnome.settings-daemon.plugins.power idle-dim true
org.gnome.settings-daemon.plugins.power power-button-action 'nothing'
org.gnome.settings-daemon.plugins.power power-saver-profile-on-low-battery true
org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 7200
org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing'
org.gnome.settings-daemon.plugins.power sleep-inactive-battery-timeout 1200
org.gnome.settings-daemon.plugins.power sleep-inactive-battery-type 'suspend'

重点关注 power-button-action 'nothing' 和 sleep-inactive-ac-type 'nothing', 由于我是台式机, 因此不需要关注 sleep-inactive-battery-type

可以通过 systemd 彻底禁用休眠:

编辑 /etc/systemd/sleep.conf 配置:

[Sleep]
AllowSuspend=no
AllowHibernation=no
AllowSuspendThenHibernate=no

这样以后, 再也不用担心在关机按钮那里误点 Suspend 或 Hibernate 了 (同时休眠相关的选项会从 Settings - Power 界面消失):

花屏的图我这里也放一个吧:

切换到 Wayland

确认当前的Nvidia显卡驱动版本已经大于 510

❯ paru -Qi nvidia | rg Version
Version         : 510.60.02-11

确认当前N卡驱动模块已经启用 KMS

KMS 默认是禁用的 (1 = enable, 0 = disable (default)) :

modinfo nvidia_drm | rg mode
depends:        nvidia-modeset
parm:           modeset:Enable atomic kernel modesetting (1 = enable, 0 = disable (default)) (bool)

我们检查下内核参数: cat /proc/cmdline , 如果没有 nvidia-drm.modeset=1 则要加上.

编辑 /etc/default/grub 加上即可, 如:

GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 noquiet nvidia-drm.modeset=1"

然后重新生成一下 grub2 配置:

sudo grub-mkconfig -o /boot/grub/grub.cfg

重启后检查 cmdline 确认 OK:

❯ cat /proc/cmdline    
BOOT_IMAGE=/vmlinuz-linux root=/dev/mapper/archlinux-root rw loglevel=3 noquiet nvidia-drm.modeset=1

其实也不用检查 cmdline, 重启后在 GDM 登录界面, 点击用户名, 别急着输入密码, 此时会看到右下角有一个齿轮图标,点击可以发现, 默认的 session 是 GNOME (这个其实就是wayland session), 然后剩下的依次是GNOME Classic, GNOME Classic on Xorg, GNOME on Xorg. 出现这些就表示 GDM 已经检测到 Wayland 支持了.

放张图 (使用 GNOME 42 自带的 screenshot 截图的: 右击窗口标题栏, 选择take screenshot):

如果不能切 Wayland 的, 可以尝试强制禁用 gdm udev 规则:

sudo ln -s /dev/null /etc/udev/rules.d/61-gdm.rules

Troubleshooting

没错, 这里到了最麻烦的部分了. 首先我们安装一下 Xorg 的一个小工具 paru -S xorg-xlsclients

这个工具的作用是 "List client applications running on a display"

因此, 凡是被 xlsclients 识别出是客户端的, 我们就知道这个程序是跑在 X11 兼容模式 (xwayland), 而不是跑在 Wayland 协议下.

flameshot

flameshot 当前是基于 qt5 编译的, qt5 当前对于 Wayland 的支持已经较好. 但是由于我之前是 X11 的桌面, 因此这里遇到了麻烦, flameshot 无法截图. 解决办法是安装 xdg-desktop-portal :

paru -S xdg-desktop-portal xdg-desktop-portal-gnome

如果我们观察 flameshot 的 dbus 调用:

dbus-monitor --session sender=org.flameshot.Flameshot

我们会发现它截图的时候实际上是调用的 org.freedesktop.portal.Screenshot 接口 (正是由 xdg-desktop-portal 提供):

method call time=1649470142.114187 sender=:1.281 -> destination=org.freedesktop.portal.Desktop serial=27 path=/org/freedesktop/portal/desktop; interface=org.freedesktop.DBus.Introspectable; member=Introspect
method call time=1649470142.114449 sender=:1.281 -> destination=org.freedesktop.DBus serial=28 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',sender='org.freedesktop.portal.Desktop',path='/org/freedesktop/portal/desktop/request/1_281/90f9e60a9e1f4e1bb80ec889f15e855f',interface='org.freedesktop.portal.Request',member='Response'"
method call time=1649470142.114597 sender=:1.281 -> destination=org.freedesktop.portal.Desktop serial=29 path=/org/freedesktop/portal/desktop; interface=org.freedesktop.portal.Screenshot; member=Screenshot
   string ""
   array \[
      dict entry(
         string "handle_token"
         variant             string "90f9e60a9e1f4e1bb80ec889f15e855f"
      )
      dict entry(
         string "interactive"
         variant             boolean false
      )
   ]

另一方面是, 其实 flameshot 包的依赖里面已经说明了这一点, 但是由于我新非新装, 因此不会太容易看到这个提示:

xdg-desktop-portal: for wayland support, you will need the implementation for your wayland desktop environment

Optional Deps   : gnome-shell-extension-appindicator: for system tray icon 
                  if you are using Gnome
                  grim: for wlroots wayland support
                  xdg-desktop-portal: for wayland support, you will need 
                  the implementation for your wayland desktop environment
                  [installed]
Required By     : None
Optional For    : None
Conflicts With  : None

在 Arch 文档有提到另外一点, 不过我貌似没有遇到这个问题:

Flameshot does not use currently visible windows You may encounter this issue if you have installed xf86-video-intel.
Simply remove the xf86-video-intel package and make sure there is no dangling X11 configuration for the package under /etc/X11/xorg.conf.d/.
Then reboot the system.
This was discussed in an issue on the Flameshot Github repository: https://github.com/flameshot-org/flameshot/issues/1677.

好了, 截图的功能能用了, 但是还有另外一个蛋疼的问题: "to take screenshot I need to click "Share" EVERY time"

即每次 flameshot 截屏, 会弹出一个 xdg portal 的界面, 你要点击这个 "Share" 按钮, 才会继续进入 flameshot 的截图和标注界面. (实际上是把整个屏幕先完全截取, 保存在 ~/Pictures/Screenshot.png 文件, 然后 flameshot 应该是拿这个文件在操作. 如果此时不在 flameshot 做接下来的操作, 那么这个文件会残留在这个位置, 否则, 这个中间文件会被删除)

flameshot 有人提出了这个问题: https://github.com/flameshot-org/flameshot/issues/2186

但是其实这个问题, flameshot 这边无能为力. xdg-desktop-portal 需要改进.

另外提一下, GNOME 自带的 gnome-screenshot 似乎有"特权", 可以不需要通过 xdg-desktop-portal 来截屏. 但是 flameshot 无法调用这种 private 接口.

Slack

Slack 当前只能跑在 XWayland 模式. 由于它用的 electron 版本太老了. 像下面这样添加 --enable-features=UseOzonePlatform --ozone-platform=wayland 参数是无法成功启动的:

env LIBVA_DRIVER_NAME="" /usr/bin/slack -s --enable-features=UseOzonePlatform --ozone-platform=wayland

XWayland 模式下的 Slack 有什么问题? 嗯, 问题就是, 输入中文的时候会卡顿. 这一点似乎在所有基于 electron 的 Linux 应用上面都有所表现. 比如 vs code 也有这个问题.

有个 aur 包, slack-electron , 测试了下貌似对于解决中文输入问题没有什么帮助.

结论: 先 XWayland 将就着用着吧, 或者直接使用 slack web 版.

2022-04-13 更新: 受到这个评论 https://github.com/swaywm/sway/issues/2508#issuecomment-438185459 的启发:

on slack the freezing seems to get better when you disable (or enable) hardware acceleration.

老灯发现禁用 HwAcceleration 后, 打字什么的都流畅多了, 界面也不卡顿了.

可以直接在 Slack prefs 配置的高级选项里禁用hw acc, 或者, 直接修改配置文件 ~/.config/Slack/local-settings.json 增加:

"useHwAcceleration":false

Discord

Discord 同样是跑在 XWayland 下, 但是我测试的时候发现, 一定要设置 LIBVA_DRIVER_NAME (猜测跟我安装了 libva Intel 硬件加速相关库有关)

当前 Intel 12 代 CPU 集显的硬件加速在 Linux 下面还不支持. 因此我这里用的是 vdpau driver.

env LIBVA_DRIVER_NAME=vdpau /usr/bin/discord 可以成功启动. 我们需要覆盖一下 discord.desktop 文件:

cp -v /usr/share/applications/discord.desktop ~/.local/share/applications/
sed -i 's|Exec=/usr/bin/discord|Exec=env LIBVA_DRIVER_NAME=vdpau /usr/bin/discord|g' ~/.local/share/applications/discord.desktop

Chrome, Chromium 和 Microsoft Edge

Chrome, Chromium 和 Microsoft Edge 可以跑在原生 Wayland 下面, 只是需要添加 flags.

对于 Chromium , 编辑 ~/.config/chromium-flags.conf 增加:

--enable-features=UseOzonePlatform
--ozone-platform=wayland
--gtk-version=4

对于 Chrome, 这个文件是 ~/.config/chrome-flags.conf, 对于 Microsoft Edge, 这个文件是 ~/.config/microsoft-edge-stable-flags.conf

注意这里老灯还多添加了一个 --gtk-version=4, 这个主要是为了修复 Wayland 下面的输入法支持问题, 要不然无法输入中文.

另外提一句, 你怎么知道这个文件的位置的? 除了看文档, 更靠谱的是, 通过其启动shell脚本判断:

❯ rg 'flags.conf' /usr/bin/microsoft-edge-stable
2:# Launches MS Edge with flags specified in $XDG_CONFIG_HOME/microsoft-edge-beta-flags.conf
11:if [ -r "${XDG_CONFIG_HOME}/microsoft-edge-stable-flags.conf" ]; then
12:  EDGE_USER_FLAGS="$(cat "$XDG_CONFIG_HOME/microsoft-edge-stable-flags.conf")"


❯ rg 'flags.conf' /usr/bin/google-chrome-stable 
6:if [[ -f $XDG_CONFIG_HOME/chrome-flags.conf ]]; then
7:   CHROME_USER_FLAGS="$(cat $XDG_CONFIG_HOME/chrome-flags.conf)"

Ulauncher

Ulauncher 的全局热键不再生效. 解决办法参考 https://github.com/Ulauncher/Ulauncher/wiki/Hotkey-In-Wayland

Fedora and Ubuntu (since 17.04) start Wayland session by default. Ulauncher in Wayland does not receive hotkey events when triggered from some windows (like terminal or OS Settings).
Please follow these steps to fix that:
Install package wmctrl (needed to activate app focus) Open Ulauncher Preferences and set Hotkey to something you'll never use Open Settings > Keyboard (may be named "Keyboard Shortcuts"), then scroll down to Customize Shortcuts > Custom Shortcuts > + In Command enter ulauncher-toggle, set name and shortcut, then click Add

官方这个文档已经把步骤描述得挺详细了, 这里我就不再说了. 最重要的是你要在 Ulauncher Preferences 设置 Hotkey 为一个超级复杂的组合键, 并且确保你在日常使用中 100% 都不会触发这个按键.

因为这个热键实际从 GNOME 的 custom shortcut 那里设置了. 并且触发启动的命令是 ulauncher-toggle

我们看下这个 ulauncher-toggle (位置 /usr/bin/ulauncher-toggle ) 做了啥.

#!/bin/sh

dbus-send \
    --session \
    --print-reply \
    --dest=net.launchpad.ulauncher \
    /net/launchpad/ulauncher \
    net.launchpad.ulauncher.toggle_window

# dbus-send is asynchronous and sometimes it takes a bit of time for Ulauncher window to be presented
sleep 0.03

wmctrl -a "Ulauncher - Application Launcher"

它首先给 ulauncher 的 dbus 接口发送了一个显示或隐藏窗口的命令 (net.launchpad.ulauncher.toggle_window). 同时, 由于 dbus-send 是异步执行的, 因此实际上脚本不知道 ulauncher 的操作是否已经完成. 不过通常显示一个窗口不算是耗时操作, 因此它这里拍脑袋设定了一个值, 这个值的响应时间对于人操作来说不会有明显的delay, 同时也满足大部分情况下的结果.

最后, 它需要调用 wmctrl 激活这个窗口, 并获取焦点. 看上去是个 tricks, 不过至少能工作了.

visual-studio-code

vs code 当前只能跑在 XWayland 模式, 并且跟 Slack 一样有中文输入卡顿问题.

当前主分支已经修复 Wayland 支持问题, 预计 1.67 会发布.

https://github.com/microsoft/vscode/commit/648b352b480c51d2a62092230348b54a1c830ec9

主要就是升级 electron到17.3.1

VSCodium 是跟随ms vscode 版本的, 因此不能解决问题.

ms 的 insider 版试了下, 窗口显示都有问题. 放弃.

反正平常也只用它当编辑器使用, 主力还是 Neovim 和 Jetbrains 全家桶.

2022-04-12 补充更新: vscode 卡顿解决

参考 https://code.visualstudio.com/updates/v1_40#_disable-gpu-acceleration

编辑 ~/.config/code-flags.conf 加上一行：

--disable-gpu

Jetbrains全家桶

目前 java 还没有 Wayland 原生方案, 因此 Jetbrains 全家桶是跑在 XWayland 下面, 经测试 fcitx 和 ibus rime 均可正常输入中文.

smplayer

smplayer 无法正常在Wayland 下工作. 虽然官方有特别给出说明: https://blog.smplayer.info/how-to-fix-the-video-problem-on-wayland/

flatpak 版本安装后直接跑不起来, 一运行就崩了.
Select a different video output in Preferences -> General -> Video, 切换成各各种方式都无法正常工作.

其中, 硬解选择 vdpau, Preferences -> General -> Video 选择 drm 可以播放, 但是 mpv 的窗口跑飞了 ("the video being on a separate window"), 其它组合都是 "a black window or a crash when trying to play a video"

mpv 本身播放正常. 只是 mpv 有些问题, 比如无法在 ui 层面选择外挂字幕等.

不过这里有一个解决办法: https://github.com/darsain/uosc

github 上面的安装方法写得并不详细, 我后续会单独写文章分享, 详细说一下.

结论: 视频播放器暂时只能用 GNOME 自带的 Video 播放器顶一下或者用 mpv + uosc (推荐)

其它应用

Kitty 中文输入正常, 自然 Neovim 中文输入正常.

feishu 只能跑在 XWayland 模式, 中文输入正常. 目前无法拖动传文件. 无法使用它内置的截屏功能(当然,我从来就用). 基本上算不太影响使用吧.

jetbrains-toolbox 也是跑在 XWayland 模式, 目前看来使用上没啥影响.

LibreOffice Wayland and HiDPI To work around issues with scaling UI elements in Wayland on HiDPI screens, use the gtk3 VCL UI interface. https://wiki.archlinux.org/title/LibreOffice#Wayland_and_HiDPI 这一点在 GNOME 42 下会默认检测用 gtk3, 因此默认就 OK

Refs

https://fedoraproject.org/wiki/Changes/WaylandByDefaultOnNVIDIA

https://wiki.archlinux.org/title/NVIDIA#DRM_kernel_mode_setting

https://wiki.archlinux.org/title/GDM#Wayland_and_the_proprietary_NVIDIA_driver

https://wiki.archlinux.org/title/Wayland#Display_managers

https://wiki.archlinux.org/title/GNOME#GNOME_applications_in_Wayland

https://fedoraproject.org/wiki/How_to_debug_Wayland_problems

https://cubethethird.wordpress.com/2017/06/07/mixed-feelings-about-wayland-on-gnome/

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/using_the_desktop_environment_in_rhel_8/customizing-gnome-desktop-features_using-the-desktop-environment-in-rhel-8#changing-behavior-when-pressing-the-powerbutton_customizing-gnome-desktop-features

https://www.reddit.com/r/Slack/comments/obgrac/slow_and_sluggish_typing_on_linux/

https://github.com/microsoft/vscode/issues/109176#event-6364443456

https://github.com/microsoft/vscode/commit/648b352b480c51d2a62092230348b54a1c830ec9

https://a-wing.top/linux/2022/01/03/translate_wayland.html

https://github.com/flameshot-org/flameshot/issues/2186

Are we Wayland yet? https://arewewaylandyet.com/

https://wiki.archlinux.org/title/Flameshot#Flameshot_does_not_use_currently_visible_windows

https://github.com/fcitx/fcitx5/issues/263

https://www.fosskers.ca/en/blog/wayland

How We Make Gitlab Golangci-lint Runs 50 Times Faster

ttyS3 — Sun, 20 Mar 2022 14:54:54 GMT

自从我们迁移到 k8s, 我们观察到 k8s 集群里的 gitlab CI runner 在跑 golangci-lint 的时候比本机跑慢很多.

本机一般几十秒就能搞定的事情, 在跑 CI 的时候, 基本上都要花上几分钟甚至几十分钟. (依项目代码量而异)

当然, 由于 CI 都是自动跑的, 大部分时间我们基本上不会花时间去刻意观察 CI 的执行. 因此慢一点其实也不会影响什么.

这个周末正好趁疫情居家哪也去不了, 研究了一下怎么想办法将速度优化.

起初我以为是因为普通云盘的 IO 性能低下导致的问题, 因为我们的节点的 CPU 和内核配置都还算不错, 不至于跑个 CI 都会因为这个影响到速度.

但是经过研究, 我发现其实大部分时间花在重复地一次又一次地加载go mod 和重复地进行代码静态分析.

没有优化之前的 CI lint stage 日志大概是这样的:

golangci-lint run  -v
level=info msg="[lintersdb] Active 33 linters: [bidichk bodyclose dogsled dupl durationcheck errorlint exhaustive exportloopref forbidigo gci gochecknoglobals gochecknoinits goconst gocritic gofmt gofumpt goimports gomodguard goprintffuncname gosimple importas ineffassign makezero misspell nilerr revive rowserrcheck sqlclosecheck staticcheck typecheck unconvert unused wastedassign]"
...
level=info msg="[loader] Go packages loading at mode 575 (compiled_files|exports_file|imports|types_sizes|deps|files|name) took 1m10.18730135s"
...
level=info msg="[runner] linters took 7m43.677383001s with stages: goanalysis_metalinter: 7m43.625988553s"
level=info msg="File cache stats: 148 entries of total size 521.9KiB"
level=info msg="Memory: 1015 samples, avg is 352.2MB, max is 1469.0MB"
level=info msg="Execution took 8m53.886795985s"

注意, goanalysis_metalinter 并不是一个具体的 linter 的名字, 而是指的最主要的 linter 执行阶段, 这里花了 7m43.625988553s. 另一个耗时比较小的stage 是 Go packages loading

所以, 其实最主要的原因还不是磁盘 io. 主要原因还是 golangci-lint 的每次分析结果都没有复用. 每次都要从0重新分析, 即使只修改了一行代码, 整个执行时间也无法减少.

于是查看 golangci-lint 文档, 看它有没有类似的缓存策略.

golangci-lint 缓存目录配置

文档对于 cache 的介绍, 只是一笔带过, 只有一句话描述, 放在配置页的最底部, 那么地不起眼, 以至于我多次看过这个文档而, 从来没引起过我的注意.

https://golangci-lint.run/usage/configuration/#cache

GolangCI-Lint stores its cache in the default user cache directory.
You can override the default cache directory with the environment variable GOLANGCI_LINT_CACHE; the path must be absolute.

这个文档确实比较含糊. 什么是用户默认缓存目录? 这里直接指向了 golang 标准库的文档:

On Unix systems, it returns $XDG_CACHE_HOME as specified by https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html if non-empty, else $HOME/.cache. On Darwin, it returns $HOME/Library/Caches. On Windows, it returns %LocalAppData%. On Plan 9, it returns $home/lib/cache.

我们的容器镜像都是 Linux 作为 base image 的, 因此自然是$HOME/.cache

但是实际上它的路径是: $HOME/.cache/golangci-lint

可以通过GOLANGCI_LINT_CACHE设置一个绝对路径覆盖这一默认行为. 文档特别强调要用绝对路径.

在 gitlab CI yaml 文件中, 我们可以这样设置:

variables:
  GOLANGCI_LINT_CACHE: /go/.cache/golangci-lint
  GOCACHE: /go/.cache/go-build
  GOMODCACHE: /go/pkg/mod
  GOPATH: /go

当然, 这里除了设置了 GOLANGCI_LINT_CACHE , 我们还设置了 GOCACHE, GOMODCACHE 和 GOPATH 这三个对于 go 构建速度提升非常重要的环境变量 (它们对于 golangci-lint 速度提升几乎没有帮助, 但是对于后面的 go build 阶段非常有用).

Gitlab CI 缓存配置

我们用的是兼容s3协议的MinIO作为Gitlab CI 缓存后端. 它足够简单.

由于我们有很多个 Gitlab runner, 默认情况下, 缓存在各个runner 之间是不共享的, Gitlab 的实现非常简单, 即在缓存 key 前面自动加上了 runner id. 而这明显跟我们的需求不太符合. 我们不希望在一个runner上面跑好的缓存, 当下次 CI 调度到不同的 runner 的时候, 这个缓存不能利用上. Gitlab 当然也考虑到了这种需求, 只需要设置 CACHE_SHARED 为 true 即可.

具体可参考 https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runnerscache-section

当然, Gitlab 启用了 cache 支持, 具体在 CI 的时候是否启用, 是通过 yaml 文件 cache 配置来实现的, demo 如下:

golangci-lint:
  stage: run-linter
  image: docker.io/golangci/golangci-lint:v1.45.0
  script:
    - golangci-lint version
    - golangci-lint run -v --color always --out-format colored-line-number
  cache:
    key: go-cache-${CI_PROJECT_PATH_SLUG}
    paths:
      - go

注意这里的 cache.key 配置, 为了避免不同的项目 CI 时缓存互相更新打架, 我们加上了项目路径 (CI_PROJECT_PATH_SLUG)后缀, 这样每个项目都拥有自己独立但多 runner 共享的 cache.

CI_PROJECT_PATH_SLUG 是专门做这种事情的, 它把 / 等替换成了 -, 方便用作 key name 或 file name.

回头看一下我们设置的环境变量, 其实这里涉及到一个缓存目录规划问题.

我们配置了一个顶级 cache 目录, 然后这个目录用来缓存 go mod (GOPATH: /go 和 GOMODCACHE: /go/pkg/mod), go build cache (GOCACHE: /go/.cache/go-build) 和 golangci-lint cache (GOLANGCI_LINT_CACHE: /go/.cache/golangci-lint). 所以这些环境变量名和路径都不是随意选的, 而是有规划的.

关于cache.path, 有一个约束, 它只能是相对路径

An array of paths relative to the project directory ($CI_PROJECT_DIR). You can use wildcards that use glob patterns:
In GitLab Runner 13.0 and later, [email protected]?tab=doc#Match">doublestar.Glob.
In GitLab Runner 12.10 and earlier, filepath.Match.

也许你发现问题了, 我们用的go mod 缓存目录是 GOMODCACHE: /go/pkg/mod

然后 Gitlab cache 只会把缓存内容释放到当前项目的CI目录. 那么我们为什么不用 $CI_PROJECT_DIR/pkg/mod ?

另外, 这个释放的缓存不在它应该在的位置, 我们怎么样利用上这个缓存?

答案就是: 因为 golangci-lint 不支持真正意义上的 skip-dirs

我们特意测试过, skip-dirs 并不像字面意思, skip-dirs 的工作方式是: 即使是在skip-dirs配置里的目录, 也同样进行静态分析, 但是如果有任何违反linter规则的问题, 不予以报告.

所以, 我们不能让 golangci-lint 去扫描这些 go mod, 我们就得想办法把项目 CI 目录下的缓存目录, 在执行 golangci-lint 之前移动到其它地方, 然后在 golangci-lint 执行完毕之后, 再移动回来 (因为这个时候Gitlab会将配置的cache.path目录全部打包push到MinIO, 如果不move回来, 就没机会push缓存了). 这个操作可以通过 Gitlab 的 before_script 和 after_script 来实现. 对于 build 阶段 ( go build 构建二进制以及容器镜像构建) 我们没有必要这样移动, 但是一定要记得将这个大于 1GB 的缓存目录(里面有 go mod 和 go build cache等, 体积基本上会超过1GB) 排除在 docker ignore, 要不然会拖慢 docker build. 最简单的办法就是, 我们不区分 lint 和 build 阶段, 统一做两次move (移走缓存是为了 golangci-lint, 移回来是为了Gitlab能push缓存).

.script_before: &go_with_cache_before |
  echo "---------------------------- begin before_script"

  if [[ -d go ]]; then
    echo "---------------------------- after cache get# move cwd go to ${GOPATH}"
    if [ "${DEBUG_GITLAB_CI_COMMAND}" = "true" ]; then
      du -sh go
    fi
    rm -rf "${GOPATH}" && mv go /
  else
    echo "no cache!!!"
  fi
  echo "---------------------------- end before_script"
  
.script_after: &go_with_cache_after |
  echo "---------------------------- begin after_script"

  if [[ -d "${GOPATH}" ]]; then
    echo "---------------------------- before cache put# move ${GOPATH} to cwd"
    mv "${GOPATH}" .
  else
    echo "no ${GOPATH} dir, this is OK if no cache defined"
  fi


  echo "---------------------------- end after_script"
  
before_script:
  - *init_git_credentials
  - *go_with_cache_before

after_script:
  - *go_with_cache_after

注意, 这里用了一个小技巧: yaml literal block + yaml anchors

literal block 可以使我们写多行shell脚本更加方便, Gitlab CI YAML 是支持 anchors 的, 这让我们写的多行shell脚本可以复用.

注意这里有一个 init_git_credentials anchor 引用, 我没有给出定义, 这个东西太简单, 就是 echo 然后 ssh-add 一下把 public key 加到 ssh-agent 而已. 并且跟当前我们要讨论的重点无关, 因此这里不写. 有兴趣的可以查看文档.

然后我们再对比看一下执行时间(同一个仓库, 同样的配置):

# before optimization
level=info msg="[runner] linters took 7m43.677383001s with stages: goanalysis_metalinter: 7m43.625988553s"
level=info msg="File cache stats: 148 entries of total size 521.9KiB"
level=info msg="Memory: 1015 samples, avg is 352.2MB, max is 1469.0MB"
level=info msg="Execution took 8m53.886795985s"


# after optimization
time="Mar 19 23:31:07.273" level=info msg="[runner] linters took 291.185017ms with stages: goanalysis_metalinter: 239.743075ms"
time="Mar 19 23:31:07.273" level=info msg="File cache stats: 0 entries of total size 0B"
time="Mar 19 23:31:07.273" level=info msg="Memory: 12 samples, avg is 58.9MB, max is 87.5MB"
time="Mar 19 23:31:07.273" level=info msg="Execution took 1.08783787s"

内存占用从平均 352M 下降到 60M 不到. 内存占用峰值从 1.5G 左右下降到 90M 不到.

lint 执行时间从接近9分钟下降到只需要1秒左右.

当然, 这是代码变化特别小的情况. 按这个算的话, 是快了 500多倍.

对于日常提交, 一般可以将 lint 执行时间控制在10s 以内, 按这个来算, (480+53)/10 = 53.3 差不多是原来的50多倍吧:

time="Mar 19 21:33:04.218" level=info msg="[runner] linters took 6.151722993s with stages: goanalysis_metalinter: 6.099292807s"
time="Mar 19 21:33:04.218" level=info msg="File cache stats: 90 entries of total size 417.9KiB"
time="Mar 19 21:33:04.218" level=info msg="Memory: 88 samples, avg is 335.2MB, max is 621.5MB"
time="Mar 19 21:33:04.218" level=info msg="Execution took 8.665056149s"

Refs

https://docs.gitlab.com/ee/ci/variables/predefined_variables.html

https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runnerscache-section

https://min.io/

https://docs.gitlab.com/ee/ci/caching/#how-archiving-and-extracting-works

https://docs.gitlab.com/ee/ci/yaml/script.html

https://stackoverflow.com/questions/42560083/multiline-yaml-string-for-gitlab-ci-gitlab-ci-yml/55347979#55347979

https://docs.gitlab.com/ee/ci/yaml/#cache

https://docs.gitlab.com/ee/ci/yaml/#cachepaths

https://docs.gitlab.com/ee/ci/yaml/yaml_optimization.html

https://docs.gitlab.com/ee/ci/yaml/yaml_optimization.html#anchors

https://docs.gitlab.com/ee/ci/ssh_keys/#ssh-keys-when-using-the-docker-executor

Telepresence实践及踩坑记

ttyS3 — Thu, 17 Mar 2022 15:34:46 GMT

Telepresence 是一个开源工具，可让您在本地运行单个服务，同时将该服务连接到远程 Kubernetes 集群

https://www.telepresence.io/about/

为什么需要 Telepresence

k8s pod IP 由 CNI 分配, 通信是走 overlay 网络, 容器之间的通信都是基于cluser IP.

cluser IP 并不像我们平常所用的 IP. 它只能在 k8s 集群内部使用.

虽然我们可以通过配置 overlay 网络的网段跟 k8s node 的网段在一个大的子网段, 然后通过 vpn 把对应网段的流量路由到overlay 网络, 我们完全可以通过 kubectl get po -o wide 获取到 pod IP, 然后访问服务.

也就是说, 如果我们在本机想运行一个服务, 不依赖 Telepresence 这种工具是完全可行的.

但是, 其实我们每个服务都有配置, 配置里面写的grpc 服务地址可能像这样: xxxx.svc.cluster.local:1234, 如果我们想要服务的配置不经过任何修改, 直接在本机运行.

有没有办法呢? 答案当然是有的, 设置 hosts 啊. kubectl get po -o wide 获取到 pod IP 和 pod name, (假设 pod name 和 service name 命名是一致的,即从 pod name 我们可以字面上得到 service name) 然后拼接成k8s里面的 DNS name xxxx.svc.cluster.local, 将这个域名映射到 pod IP 即可. 假设我们写了这样一个脚本, 但是当 pod 被调试到不同的node, 或者 pod 重建之后, 其 pod IP 必然会改变, 这个时候我们又要手动去重新生成这个 hosts 文件. 总体操作来说, 还是挺麻烦的.

另一个问题是, 团队内部有很多人, 要让所有人都都学会这一招操作, 可能会有些困难, 或者说, 这种方式, 对用户不太好友.

这个时候, Telepresence 横空出世.

在 k8s 官方文档中, "本地开发和调试服务" 一节, Telepresence 是唯一介绍的工具.

对于用户来说, Telepresence 提供了3个非常重要的功能:

cluster 域名解析
cluster 流量代理
cluster 流量拦截

域名解析 可以使我们在本地开发机器直接解析如 xxxx.svc.cluster.local 这种域名.

(注: mac 下面机制不太一样, 不可以使用dig测试,但是可以用curl)

你可以像查询其它域名一样使用命令行 dig 工具进行查询, 如 dig kubernetes.default

光有域名解析还不够, 我们还是没法连接集群内的其它服务, 因此 流量代理 功能的作用就体验出来了.

在 Linux 下面, Telepresence 会建立一个名叫 tel0 的 tun 设备. 然后通过 systemd-resolved 服务将集群命令空间的 cluster domain 添加到这个设备. 通过resolvectl status tel0可以查看到当前有哪些命令空间被添加进来了:

resolvectl status tel0
Link 66 (tel0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 10.0.165.145
       DNS Servers: 10.0.165.145
        DNS Domain: ~ambassador ~argocd ~cluster.local ~db ~default ~devops ~istio-system ~jaeger ~kube-public ~kube-system ~nacos ~observability

流量拦截 可以将集群里指定服务的流量拦截并转发到本地开发机器, 比如调试复杂的 app 业务接口时,非常方便.

这个非常有用, 但是老灯平常一般都不用这个. 因为我们的服务都有注入 istio side car. 而 Telepresence 的拦截原理其实也跟 istio 类似, 也是利用 side car 注入然后代理流量. 但是同一个 pod 的流量, 不能同时被 istio 接管, 然后又被 Telepresence 接管. 这一点我后面再详细说怎么解决.

日常使用

telepresence connect 连接

telepresence status 查看连接状态

curl -ik https://kubernetes.default 测试连接成功与否( 有任意响应就是成功)

telepresence quit -u -r 断开连接并退出user 和 root daemon

DNS 解析原理

这部分主要参考 https://www.telepresence.io/docs/latest/reference/routing/

Linux systemd-resolved resolver

以 Linux 上面的实现为例, 简单来说, Telepresence 就是新建一 tun 设备, 这个设备的流量会代理到 k8s 里的Telepresence traffic manager ( 负责流量转发等). tun 设备的 DNS 被设置成了 k8s 集群的 DNS (一般是 coredns 啦). Telepresence 会 watch 整个集群的所有命名空间, 因此, 当发生变量的时候, DNS link domain 会被自动更新.

然后, 设置哪此命令空间后缀要通过这个 DNS 查询是通过 systemd-resolved 的服务的 dbus 接口 SetLinkDomains 操作的. 设置 DNS 是通过 SetLinkDNS

这种操作, 其实就相当于在 /etc/systemd/resolved.conf.d 下面新建一 k8s.conf 文件, 内容类似于:

# https://learn.hashicorp.com/tutorials/consul/dns-forwarding#systemd-resolved-setup
[Resolve]
DNS=10.0.165.145:53
DNSSEC=false
Domains=~ambassador ~argocd ~cluster.local ~db ~default ~devops ~istio-system ~jaeger ~kube-public ~kube-system ~nacos ~observability

只不过, 通过 dbus 可以动态的修改, 更加方便.

Linux overriding resolver

Linux systems that aren't configured with systemd-resolved will use this resolver. A Typical case is when running Telepresence inside a docker container. During initialization, the resolver will first establish a fallback connection to the IP passed as --dns, the one configured as local-ip in the local DNS configuration, or the primary nameserver registered in /etc/resolv.conf. It will then use iptables to actually override that IP so that requests to it instead end up in the overriding resolver, which unless it succeeds on its own, will use the fallback.

即, 对于不支持 systemd-resolved 的 Linux 系统(一般是非常老的那种), Telepresence 会自己起一个 DNS 代理服务, 一般是监听随机端口, 然后再将系统 DNS 设置成 TelepresenceDNS 代理服务的地址. 即解析的时候会先查集群, 没有结果会 fallback 到本机原来的 DNS, 比如 Google public DNS 等解析其它域名.这个会影响其它应用的使用, 这种实现方式不太好, 以老灯的使用经验来看, 这种方式也不太稳定. 容易造成问题.

macOS resolver

在 macOS 下面是通过 resolver hooks 实现的.

This resolver hooks into the macOS DNS system by creating files under /etc/resolver. Those files correspond to some domain and contain the port number of the Telepresence resolver. Telepresence creates one such file for each of the currently mapped namespaces and include-suffixes option. The file telepresence.local contains a search path that is configured based on current intercepts so that single label names can be resolved correctly.

troubleshooting

1. 流量拦截不生效

测试过程中发现流量拦截与注入的 istio-proxy 容器存在冲突，即当 istio-proxy 存在时，流量全部被 istio-proxy 接管了，traffic-agent 没有成功拦截到流量。

目前我暂时的一个 hack 方法是取消 istio-proxy sidecar注入：

diff --git a/develop/overlays/my_app/deployment.yaml b/develop/overlays/my_app/deployment.yaml
index 1049d335..26ee38d4 100644
--- a/develop/overlays/my_app/deployment.yaml
+++ b/develop/overlays/my_app/deployment.yaml
@@ -4,6 +4,9 @@ metadata:
   name: ttys3
 spec:
   template:
+    metadata:
+      annotations:
+        sidecar.istio.io/inject: "false"
     spec:
       containers:
       - name : my-app

traffic-agent 日志查看： stern --tail 100 ttys3-my-app -c traffic-agent

如果是采用 argo cd rollout:

diff --git a/develop/overlays/my-app/rollout.yaml b/develop/overlays/my-app/rollout.yaml
index 263eab87c..bbc44c378 100644
--- a/develop/overlays/my-app/rollout.yaml
+++ b/develop/overlays/my-app/rollout.yaml
@@ -6,6 +6,9 @@ metadata:
 
 spec:
   template:
+    metadata:
+      annotations:
+        sidecar.istio.io/inject: "false"
     spec:
       securityContext:
         runAsUser: 1000

2. 连接不上

使用新版本的 telepresence v2.x.x 如果“重复” 出现（偶尔一次可能是意外）以下错误：

⁣telepresence: error: the port-forward connection to the traffic manager timed out. The current timeout 20s can be configured as timeouts.trafficManagerConnect

⁣ ⁣或 ⁣

⁣telepresence: error: the traffic manager gRPC API timed out. The current timeout 20s can be configured as timeouts.trafficManagerAPI in /Users/tomeee/Library/Application Support/telepresence/config.yml ⁣

⁣类似错误， ⁣说明同一集群里有多个人使用不同版本 v2 的客户端互相在打架。当 telepresence 连接的时候, 如果与当前版本匹配的 traffic manager不存在, 则会自动安装与当前版本匹配的 traffic manager. 当不同的人, 从不同的地方, 下载了不同的版本, 都在连接同一个集群的时候, 问题就发生了.

解决方案：同一集群所有人统一使用相同版本的客户端（版本号要完全相同，对于 nightly 版, 小版本号和commit hash 都要相同） sys op 对整个集群的 rbac 做更加安全地配置, 禁止除 devops 组之外的其它开发人员拥有可以 ambassador 命名空间下资源的更新权限, 这样就可以阻止开发人员在使用telepresence 连接的时候无意中错误地在不停地安装各种版本的 traffic manager. 但是为了保证开发人员可以正常使用, list resource "namespaces"权限一定要给, 然后就是 create resource "pods/portforward" in API group "" in the namespace "ambassador" 的权限. ⁣ Client / Root Daemon / User Daemon 3 个版本号一定要完全一致:

❯ telepresence version
Client: v2.5.4 (api v3)
Root Daemon: v2.5.4 (api v3)
User Daemon: v2.5.4 (api v3)

参考官方 issue: https://github.com/telepresenceio/telepresence/issues/1652

https://github.com/telepresenceio/telepresence/issues/1689

3. 如何彻底卸载

一般情况下可以直接 telepresence uninstall --everything 搞定.

如果需要手动卸载可以这样操作:

k delete deploy -n ambassador traffic-manager
k delete secrets sh.helm.release.v1.traffic-manager.v1 -n ambassador

注意它并不会真正检查 pod 是否存在, 如果检查到 sh.helm.release.v1.traffic-manager.v1 这个 secrets 就会直接跳过安装了. 所以你要是删除了 traffic manger 的 deployment, 但是忘记删除了这个 secrets, 会导致下次连接的时候, traffic manger 不会被安装.

4. 调试问题

k8s 端问题查看:

先检查 pod 是不是正常:

k get po -n ambassador

k get deploy -n ambassador

查看 pod 日志:

k logs -n ambassador -f traffic-manager

5. 编译和构建容器镜像

traffic manager 的版本一定要匹配客户端的版本.

对于 nightly 版本, 其形式如 v2.5.4-2-g8ccf3c9d

对于正式版, 其形式如 v2.5.3

不同版本不能连接, 会提示错误. 即使是客户端, 不同版本的 daemon 也是不兼容的, 如:

version mismatch. Client v2.5.3 != User Daemon v2.5.4-2-g8ccf3c9d, please run 'telepresence quit -u' and reconnect

计算当前 nightly 版本号: git describe --tags --match='v*'

build 的时候，必须通过 env 指定 TELEPRESENCE_VERSION，不然 Makefile 会自动运行 go run build/genversion.go 生成一个带 unix timestamp 的版本号，这样客户端和 agent docker image 的版本号便没办法对应上了。

同时还要指定 TELEPRESENCE_REGISTRY ，这个主要是在构建时打docker tag用的，主要用于 docker push, 真正程序运行的时候，取的还是 env:"TELEPRESENCE_REGISTRY,default=docker.io/datawire" 因此，如果要防止客户端安装官方镜像, 这一行硬编码的代码必须修改.

# 构建本地bin和容器镜像并 push:
make build image push-image TELEPRESENCE_VERSION=v2.5.4 TELEPRESENCE_REGISTRY=docker.io/ttys3

# 只构建本地bin
make build TELEPRESENCE_VERSION=v2.5.4 TELEPRESENCE_REGISTRY=docker.io/ttys3

6. 突然无法访问的Rust文档站点docs.rs

连接 telepresence后, 发现 https://docs.rs/ 怎么也打不开了. dig docs.rs 发现超时, 并没有解析成功.

然后我想到了原因, 有人在集群里创建了一个名为 rs 的命名空间, 连接 telepresence后, 导致所有 .rs 域名都无法解析了(除了 k8s 集群里面的 ).

经过查看源码, 老灯发现可以通过patch updateLinkDomains 这个方法搞定. 思路就是, 如果一个命名空间, 是ICANN 管理的通用 TLD 后缀, 则直接 skip 它, 不设置.

直接修改 telepresence 源码然后自己编译客户端即可:

diff --git a/pkg/client/rootd/dns/resolved_linux.go b/pkg/client/rootd/dns/resolved_linux.go
index b2e8897bbeb5405170359f5318a7ae40dfc6e949..d90c2735ef9d4d421738fea533f7bfb244172b61 100644
--- a/pkg/client/rootd/dns/resolved_linux.go
+++ b/pkg/client/rootd/dns/resolved_linux.go
@@ -13,6 +13,7 @@ import (
 	"github.com/datawire/dlib/dtime"
 	"github.com/telepresenceio/telepresence/v2/pkg/client/rootd/dbus"
 	"github.com/telepresenceio/telepresence/v2/pkg/vif"
+	"golang.org/x/net/publicsuffix"
 )
 
 func (s *Server) tryResolveD(c context.Context, dev *vif.Device, configureDNS func(net.IP, *net.UDPAddr)) error {
@@ -102,28 +103,36 @@ func (s *Server) tryResolveD(c context.Context, dev *vif.Device, configureDNS fu
 func (s *Server) updateLinkDomains(c context.Context, paths []string, dev *vif.Device) error {
 	namespaces := make(map[string]struct{})
 	search := make([]string, 0)
-	for i, path := range paths {
+	pathsFiltered := make([]string, 0)
+	for _, path := range paths {
 		if strings.ContainsRune(path, '.') {
 			search = append(search, path)
 		} else {
+			// skip namespace which conflict with eTLD like `im`, `rs` to avoid pollute client normal DNS query
+			if eTLD, icann := publicsuffix.PublicSuffix(path); icann && path == eTLD {
+				dlog.Infof(c, "Skip set Link domains on device %q for [%s] due to conflict with ICANN eTLD [%s]",
+					dev.Name(), path, eTLD)
+				continue
+			}
 			namespaces[path] = struct{}{}
 			// Turn namespace into a route
-			paths[i] = "~" + path
+			// paths[i] = "~" + path
+			pathsFiltered = append(pathsFiltered, "~"+path)
 		}
 	}
 	for _, sfx := range s.config.IncludeSuffixes {
-		paths = append(paths, "~"+strings.TrimPrefix(sfx, "."))
+		pathsFiltered = append(pathsFiltered, "~"+strings.TrimPrefix(sfx, "."))
 	}
-	paths = append(paths, "~"+s.clusterDomain)
+	pathsFiltered = append(pathsFiltered, "~"+s.clusterDomain)
 	namespaces[tel2SubDomain] = struct{}{}
 
 	s.domainsLock.Lock()
 	s.namespaces = namespaces
 	s.search = search
 	s.domainsLock.Unlock()
-	if err := dbus.SetLinkDomains(dcontext.HardContext(c), int(dev.Index()), paths...); err != nil {
+	if err := dbus.SetLinkDomains(dcontext.HardContext(c), int(dev.Index()), pathsFiltered...); err != nil {
 		return fmt.Errorf("failed to set link domains on %q: %w", dev.Name(), err)
 	}
-	dlog.Debugf(c, "Link domains on device %q set to [%s]", dev.Name(), strings.Join(paths, ","))
+	dlog.Debugf(c, "Link domains on device %q set to [%s]", dev.Name(), strings.Join(pathsFiltered, ","))
 	return nil
 }

注意: telepresence 的 exclude-suffixes 选项并不能解决我们这里的问题.

https://www.telepresence.io/docs/latest/reference/config/#dns

其默认值为 [".arpa", ".com", ".io", ".net", ".org", ".ru"]

exclude-suffixes Suffixes for which the DNS resolver will always fail (or fallback in case of the overriding resolver)

由于我们用的都是基于systemd-resolved 的 resover, 因此, 如果把 `.rs` 加入这个列表, 则会导致 `.rs` 域名总是解析失败(NXDomain)

所以其实这个默认列表也是有问题的, 为什么默认有 `.com`, 而 `google.com` 不会解析失败呢? 那是因为我们没有名为 `com` 的命名空间. 所以, 假设你有名为 `com` 的命名空间, 就要小心了.

7. DNS 解析特别慢或超时

我们同时在开发和测试环境部署了 telepresence (traffic manager).

使用中发现, 测试环境丝滑无比, 开发环境总是 DNS 解析超时.

通过查看log可发现类似日志:

LookupHost: lookup kubernetes.default on 10.0.165.145:53: dial udp 10.0.165.145:53: i/o timeout

暂时没排查出什么原因, 大概率是 coredns 出问题了.

干了 coredns pod 之后, 等 coredns pod 重新 ruuning 了, 再把 traffic manager 的 pod干了,

重新测试, 发现正常了.

8. 某些网段或IP的流量不想走 tel0 tun 出去

这个也是通过k8s 扩展配置实现的, 之所以放在这里, 我想 telepresence 是考虑到对于不同人集群, 可以方便支持不同的配置.

修改 ~/.kube/config 文件, 增加配置到 never-proxy 数组即可, 如要将 10.10.8.9 单个IP排除:

- cluster:
    certificate-authority-data: xxxxxx
    server: https://example.com
    extensions:
    - name: telepresence.io
      extension:
        never-proxy:
          - 10.10.8.9/32
  name: cluster-001

k8s 集群 api server 的 IP telepresence是会默认排除的(通过 telepresence status 你可以看到这一点), 除此之外 , 如果你有些外部服务, 因为网段跟 k8s cluster IP 段重合, 导致流量错误地走了 tel0 tun 设备, 就可以通过这个配置来修正.

Refs

在本地开发和调试服务 https://kubernetes.io/zh/docs/tasks/debug-application-cluster/local-debugging/

https://www.telepresence.io/docs/latest/reference/routing/

https://www.freedesktop.org/software/systemd/man/org.freedesktop.resolve1.html

https://www.telepresence.io/docs/latest/reference/config/#dns

https://www.getambassador.io/docs/telepresence/latest/howtos/intercepts/

https://github.com/telepresenceio/telepresence/tree/release/v2

https://www.getambassador.io/docs/telepresence/latest/quick-start/qs-go/

Golang编译器优化迷之操作

ttyS3 — Wed, 16 Mar 2022 19:14:43 GMT

简单的代码, 问题不简单

今天有人发了段代码给我, 然后问输出结果是什么?

这段代码看上去非常简单, 但是确是很有迷惑性.

// a.go
package main

import (
	"fmt"
	"time"
)

var x int64 = 0

func storeFunc() {
	for i := 0; ; i++ {
		if i%2 == 0 {
			x = 2
		} else {
			x = 1
		}
	}
}

func main() {
	go storeFunc()
	for {
		fmt.Printf("x=%v\n", x)
        // x=0
		time.Sleep(time.Millisecond * 10)
	}
}

答案是: 不断地输出 x=0

tested under Go 1.17 / Go 1.18

为什么是 0 ? 刚开始老灯也有疑问. 查看了汇编之后, 才确定是编译器优化在搞鬼.

假设文件名为 a.go, 我们直接执行 go run a.go 结果就是输出0

我们稍微改一下, 就在 for 里面加个小 sleep (sleep 多久不重要):

// b.go
package main

import (
	"fmt"
	"time"
)

var x int64 = 0

func storeFunc() {
	for i := 0; ; i++ {
		time.Sleep(time.Millisecond * 16)
		if i%2 == 0 {
			x = 2
		} else {
			x = 1
		}
	}
}

func main() {
	go storeFunc()
	for {
		fmt.Printf("x=%v\n", x)
        // x=0
        // x=2
        // x=1
		time.Sleep(time.Millisecond * 10)
	}
}

这个新加的 time.Sleep(time.Millisecond * 16) 会导致编译器不再将这个函数对 x 的赋值操作优化掉.

我们继续变一下, 这将主要是让这个函数有条件返回, 同样的, 编译器不会再优化掉对 x 的赋值操作:

// c.go
package main

import (
	"fmt"
	"time"
)

var x int64 = 0

func storeFunc() {
	for i := 0; i < 10000000001; i++ {
		if i%2 == 0 {
			x = 2
		} else {
			x = 1
		}
	}
}

func main() {
	go storeFunc()
	for {
		fmt.Printf("x=%v\n", x)
// x=0
// x=1
// x=1
// x=1
// x=2
// x=1
		time.Sleep(time.Millisecond * 10)
	}
}

接着, 我们再变一下, 没错, 我们把 for 移到后面了, 结果会是输出 2 吗?

// d.go
package main

import (
	"fmt"
	"time"
)

var x int64 = 0

func storeFunc() {
    var i int
    if i%2 == 0 {
		x = 2
	} else {
		x = 1
	}
	for i := 0; ; i++ {
	}
}

func main() {
	go storeFunc()
	for {
		fmt.Printf("x=%v\n", x)
        // x=0
		time.Sleep(time.Millisecond * 10)
	}
}

答案是: 不会, 结果还是输出 0

目前的测试结果看来, 只要这里是个死循环, 并且里面没有加 sleep 类的操作, 照样会被优化.

我们再来一个变种:

// e.go
package main

import (
	"fmt"
	"time"
)

var x int64 = 0

func storeFunc() {
	for i := 0; ; i++ {
		// time.Sleep(time.Millisecond * 10)
		if i%2 == 0 {
			x = 2
		} else {
			x = 1
		}
	}
}

func main() {
	go func() {
		for {
			fmt.Printf("x=%v\n", x)
            // x=0
			time.Sleep(time.Millisecond * 10)
		}
	}()
	storeFunc()
}

这个问题和多线程访问变量有关吗?

完全无关. 有人评论说, 你这个代码, 不用多线程你两个死循环完全跑不了.

所以, 我这里增加了这段, 用于测试验证, 和多线程无关. 本质上是编译器优化, 跟多线程不多线程没有任何关系.

我完全可以去掉多线程 go storeFunc() 修改成 storeFunc() 即可 (不要说你这第二个loop没机会运行, 这里只是为了说明, 与多线程没有关系), 生成的优化代码是完全一样的:

// a.go
package main

import (
	"fmt"
	"time"
)

var x int64 = 0

func storeFunc() {
	for i := 0; ; i++ {
		if i%2 == 0 {
			x = 2
		} else {
			x = 1
		}
	}
}

func main() {
	storeFunc()
	for {
		fmt.Printf("x=%v\n", x)
		// x=0
		time.Sleep(time.Millisecond * 10)
	}
}

生成的汇编是一模一样的:

"".storeFunc STEXT nosplit size=3 args=0x0 locals=0x0 funcid=0x0 align=0x0
	0x0000 00000 (a.go:11)	TEXT	"".storeFunc(SB), NOSPLIT|ABIInternal, $0-0
	0x0000 00000 (a.go:11)	FUNCDATA	$0, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
	0x0000 00000 (a.go:11)	FUNCDATA	$1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
	0x0000 00000 (a.go:12)	XCHGL	AX, AX
	0x0001 00001 (a.go:1)	JMP	0
	0x0000 90 eb fd

当然, 正常开发中没人会这样写代码.

同样, 正常开发的时候, 我们多线程读写同一个内存, 一般都会加锁, 为了避免 CPU 方面的优化, 我们还可能会采用原子操作 (go atomic pkg).

有没有办法禁止这种优化?

当然是有的, 编译的时候加 -gcflags '-N' 即可. (还有个 -l 表示 noinline , 由于这里我们的讨论不涉及inline优化, 因此这里不讨论这个参数). 禁止优化执行的结果是预期的:

go run -gcflags '-N' a.go

x=0
x=2
x=2
x=1
x=1
x=1
x=2
x=1
x=1
x=2
x=1
x=1

ps: 构建时用 go build -gcflags '-N'即可.

我们看下禁止优化(-N)后的Go 汇编代码( 我们这里只关注 func storeFunc() 这个函数的):

go tool compile -N -S a.go

        TEXT    "".storeFunc(SB), NOSPLIT|ABIInternal, $16-0
        SUBQ    $16, SP
        MOVQ    BP, 8(SP)
        LEAQ    8(SP), BP
        FUNCDATA        $0, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
        FUNCDATA        $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
        MOVQ    $0, "".i(SP)
        JMP     storeFunc_pc24
storeFunc_pc24:
        JMP     storeFunc_pc26
storeFunc_pc26:
        MOVQ    "".i(SP), AX
        BTL     $0, AX
        JCC     storeFunc_pc38
        JMP     storeFunc_pc51
storeFunc_pc38:
        MOVQ    $2, "".x(SB)
        JMP     storeFunc_pc66
storeFunc_pc51:
        MOVQ    $1, "".x(SB)
        NOP
        JMP     storeFunc_pc66
storeFunc_pc66:
        JMP     storeFunc_pc68
storeFunc_pc68:
        MOVQ    "".i(SP), AX
        INCQ    AX
        MOVQ    AX, "".i(SP)
        JMP     storeFunc_pc24

TEXT "".storeFunc(SB), NOSPLIT|ABIInternal, $16-0 表示 storeFunc 函数开始.

MOVQ $0, "".i(SP) 把 0 丢给 i

MOVQ "".i(SP), AX 把 i 丢给 AX

BTL $0, AX, BT 是 Bit Test 的意思, 位检测指令. 结果会影响 CF (carry flag), 因此后面用 JCC 判断. 取第0个 bit 丢给 CF

关于 BT:

Selects the bit in a bit string (specified with the first operand, called the bit base) at the bit-position designated by the bit offset (specified by the second operand) and stores the value of the bit in the CF flag. The bit base operand can be a register or a memory location; the bit offset operand can be a register or an immediate value.

CF ← Bit(BitBase, BitOffset);

注意, 这段描述是针对 Intel asm的, GCC 使用 AT&T 风格的 asm, 因此参数是反的. 另外, AT&T 语法 Immediate values prefixed with a $, registers prefixed with a % 比如 AT&T movl $5, %eax, Intel 则是 mov eax, 5, 我们教科书里面基本上介绍 Intel asm, 包括单片机那些. 老灯也是看不太习惯 AT&T 语法, 可能 Intel 先入为主了吧.

ref https://en.wikipedia.org/wiki/X86_assembly_language#Syntax

JCC storeFunc_pc38, AX 最低位是 0 则跳到 storeFunc_pc38, 这里怎么直接是 JCC ? 老灯觉得这里应该是 JNC 或 JAE ? 关于这个, 后面老灯再说.

MOVQ $2, "".x(SB) 即把 2 丢给 x 啦.

否则, JCC 没跳, 则 MOVQ $1, "".x(SB), 把 1 丢给 x

此即:

if i%2 == 0 {
	x = 2
} else {
	x = 1
}

最后 JMP storeFunc_pc24 又跳回去了. 无限循环.

好了, 我们再看一下被优化过的 storeFunc 函数长啥样:

go tool compile -S a.go

storeFunc_pc0:
        TEXT    "".storeFunc(SB), NOSPLIT|ABIInternal, $0-0
        FUNCDATA        $0, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
        FUNCDATA        $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
        XCHGL   AX, AX
        JMP     storeFunc_pc0

没错, 只有一个 XCHGL AX, AX 指令, 然后就是 JMP storeFunc_pc0 死循环. 整个指令完全把对 x 的赋值操作优化没了.

Go 汇编迷一样的条件跳转语句

Go 汇编里面的条件跳转语句, 对于熟悉 Intel x86 语法的人来说, 也是很迷的. 老灯在这找到了一个对应表: 实际上应该是结合 https://github.com/golang/go/blob/ed4db861182456a63b7d837780c146d4e58e63d8/src/cmd/asm/internal/arch/arch.go#L128 和 x86 指令总结的.

Go	x86
JCC	JAE
JCS	JB
JCXZL	JECXZ
JEQ	JE,JZ
JGE	JGE
JGT	JG
JHI	JA
JLE	JLE
JLS	JBE
JLT	JL
JMI	JS
JNE	JNE, JNZ
JOC	JNO
JOS	JO
JPC	JNP, JPO
JPL	JNS
JPS	JP, JPE

开启优化, 怎么确保 x 的值被设置?

答案当然是用 atomic 操作啦. https://pkg.go.dev/sync/atomic

可以用 LoadInt64 和 StoreInt64 读写.

Refs

https://dave.cheney.net/2020/04/25/inlining-optimisations-in-go

https://dave.cheney.net/2018/01/08/gos-hidden-pragmas

https://en.wikipedia.org/wiki/X86_assembly_language#Syntax

A Quick Guide to Go's Assembler https://go.dev/doc/asm

https://pkg.go.dev/sync/atomic#LoadInt64

https://godbolt.org/

https://github.com/teh-cmc/go-internals/blob/master/chapter1_assembly_primer/README.md

https://go.dev/doc/asm

ArchLinux 下 mpv: undefined symbol: vkCreateWaylandSurfaceKHR 问题解决

ttyS3 — Sun, 06 Mar 2022 05:39:05 GMT

问题现象

在Gnome Terminal 直接执行 mpv filename.mp4 报错:

mpv: symbol lookup error: mpv: undefined symbol: vkCreateWaylandSurfaceKHR

使用 smplayer 打开同样的文件, 也是同样的报错.

解决办法

这个解决办法很简单.

但是我要说的是, 这个问题其实我花了很长时间才解决, 并且不是我自己想到的.

产生这个问题的时候, 一般是更新了某些软件之后.

当时我想, 这个是视频相关的, 可能跟显卡驱动相关. 但是后面发现, 即使重启系统, 或者重新编译mpv, 这个问题还是不能解决. 但是有时候重启系统后又能成功打开文件.

报错是 undefined symbol: vkCreateWaylandSurfaceKHR , 但是其实这个问题跟 wayland 无关, 因为我用的是 N 卡 + X11.

搜索了一下, 得知 vkCreateWaylandSurfaceKHR 这个符号来自 libvulkan, 但是本机有正常安装 libvulkan.

❯ paru -Ss libvulkan | rg installed
extra/vulkan-icd-loader 1.2.203-1 [0B 481.45KiB] [Installed]


❯ ls -l /usr/lib/libvulkan* 
lrwxrwxrwx root root  14 B  Fri Jan 21 23:07:49 2022  /usr/lib/libvulkan.so ⇒ libvulkan.so.1
lrwxrwxrwx root root  20 B  Fri Jan 21 23:07:49 2022  /usr/lib/libvulkan.so.1 ⇒ libvulkan.so.1.2.203
.rwxr-xr-x root root 470 KB Fri Jan 21 23:07:49 2022  /usr/lib/libvulkan.so.1.2.203
.rwxr-xr-x root root  11 MB Sat Mar  5 08:14:57 2022  /usr/lib/libvulkan_intel.so


 ❯ strings /usr/lib/libvulkan.so.1 | rg vkCreateWaylandSurfaceKHR  
vkCreateWaylandSurfaceKHR
vkCreateWaylandSurfaceKHR
VK_KHR_wayland_surface extension not enabled. vkCreateWaylandSurfaceKHR not executed!
vkCreateWaylandSurfaceKHR: Invalid instance [VUID-vkCreateWaylandSurfaceKHR-instance-parameter]

重新编译 mpv 不能解决
问题只在有时候出现(条件不明确)
undefined symbol 这种错误按以往的经常是特别容易解决的, 安装好对应的lib就好了, 但是现在的情况是, 有正确的 lib 安装了, 依旧报错

所以, 一时间找不到思路了.

直到有一天, 通过搜索看到了reddit 上一个回答. 终于找到了正确的答案.

This is because chrome provides a broken copy of vulkan which is loaded while it tries to execute mpv. The fix is to make a little wrapper at /usr/local/bin/mpv that preloads the system version of vulkan:
#!/bin/sh
export LD_PRELOAD=/usr/lib/libvulkan.so.1
exec /usr/bin/mpv "$@"

简单来说就是, Google Chrome 自带了一个没有 vkCreateWaylandSurfaceKHR 符号的 libvulkan.so, 并且优先于系统的 libvulkan.so 加载了.

解决办法是通过一个脚本wrapper来启动mpv. 然后设置 smplayer 调用这个wrapper.

未解之迷

这个方法可以解决问题, 但是有一点老灯还没想明白.

为什么 Chrome 会影响整个系统的 LD_LIBRARY_PATH 环境变量 ? 一般来说, 通过一个 shell 脚本设置的变量, 不会影响其它 shell 的.

通过 kitty 执行 /usr/bin/env | rg LD_LIBRARY_PATH 无结果.

在 kitty 下面:

❯ ldd /usr/bin/mpv | rg libvulkan.so.1
	libvulkan.so.1 => /usr/lib/libvulkan.so.1 (0x00007fa58880a000)

唯独在 gnome terminal 下得到的结果是 LD_LIBRARY_PATH=/opt/google/chrome:/opt/google/chrome/lib

自然而然, 加载的是 Google 的 /opt/google/chrome/libvulkan.so.1

❯ /usr/bin/env | rg LD_LIBRARY_PATH
LD_LIBRARY_PATH=/opt/google/chrome:/opt/google/chrome/lib


❯ ldd /usr/bin/mpv | rg libvulkan.so.1
	libvulkan.so.1 => /opt/google/chrome/libvulkan.so.1 (0x00007fd41628b000)

所以, 现在的问题是, 为什么Chrome 启动脚本里的 LD_LIBRARY_PATH 会对 Gome Terminal 或者 smplayer 有效,

而在 kitty 等其它终端里面却获取不到?

尝试重启一次系统, 这次发现, 连 gnome terminal 下也没有 LD_LIBRARY_PATH 这个值了.

所以, 当gnome terminal 下能取到 LD_LIBRARY_PATH 这个值的时候, 发生了什么?

由于无法复现, 这里老灯也已经无法继续探索了.

/usr/lib/gnome-terminal-server (gnome terminal实际干活的进程) 和 smplayer 获取环境变量的方式, 和 kitty 有什么不同?

是否跟安装了 chrome-gnome-shell 有关系?

在 Linux 下面的 Google Chrome 启动实际上是通过 google-chrome 这个shell 脚本启动的 (edge 也一样, 只是重命名为了 microsoft-edge ), 在 ArchLinux 下这个路径是 /opt/google/chrome/google-chrome

其内容如下:

#!/bin/bash
#
# Copyright (c) 2011 The Chromium Authors. All rights reserved.
# Use of this source code is governed by a BSD-style license that can be
# found in the LICENSE file.

# Let the wrapped binary know that it has been run through the wrapper.
export CHROME_WRAPPER="`readlink -f "$0"`"

HERE="`dirname "$CHROME_WRAPPER"`"

# We include some xdg utilities next to the binary, and we want to prefer them
# over the system versions when we know the system versions are very old. We
# detect whether the system xdg utilities are sufficiently new to be likely to
# work for us by looking for xdg-settings. If we find it, we leave $PATH alone,
# so that the system xdg utilities (including any distro patches) will be used.
if ! command -v xdg-settings &> /dev/null; then
  # Old xdg utilities. Prepend $HERE to $PATH to use ours instead.
  export PATH="$HERE:$PATH"
else
  # Use system xdg utilities. But first create mimeapps.list if it doesn't
  # exist; some systems have bugs in xdg-mime that make it fail without it.
  xdg_app_dir="${XDG_DATA_HOME:-$HOME/.local/share/applications}"
  mkdir -p "$xdg_app_dir"
  [ -f "$xdg_app_dir/mimeapps.list" ] || touch "$xdg_app_dir/mimeapps.list"
fi

# Always use our versions of ffmpeg libs.
# This also makes RPMs find the compatibly-named library symlinks.
if [[ -n "$LD_LIBRARY_PATH" ]]; then
  LD_LIBRARY_PATH="$HERE:$HERE/lib:$LD_LIBRARY_PATH"
else
  LD_LIBRARY_PATH="$HERE:$HERE/lib"
fi
export LD_LIBRARY_PATH

export CHROME_VERSION_EXTRA="stable"

# We don't want bug-buddy intercepting our crashes. http://crbug.com/24120
export GNOME_DISABLE_CRASH_DIALOG=SET_BY_GOOGLE_CHROME


# Sanitize std{in,out,err} because they'll be shared with untrusted child
# processes (http://crbug.com/376567).
exec < /dev/null
exec > >(exec cat)
exec 2> >(exec cat >&2)

# Note: exec -a below is a bashism.
exec -a "$0" "$HERE/chrome" "$@"

搜索了系统其它地方(如 /etc/environment, /etc/profile.d 等), 也没有发现设置 LD_LIBRARY_PATH 的, 唯一的只有这个脚本有 export LD_LIBRARY_PATH, 而这个脚本只有在Chrome 启动的时候才会执行, 并且, 这样执行 export LD_LIBRARY_PATH 不应该影响到 gnome terminal 或 smplayer 的环境变量啊?

kitty -- 一个被严重忽视的生产力利器

ttyS3 — Thu, 03 Mar 2022 18:40:36 GMT

kitty 是一个 GPU based terminal, 这类terminal 并不少, 比如老灯目前在用的 Alacritty.

kitty 可以说是, 老灯无意中安装上的, 今天本来想卸载它的, 结果把玩了一下, 发现这玩意设计上和性能上都不错.并且文档齐全, 开发活跃.

Alacritty 出生就自带 Rust 光环, 当前 star 数量约 37.8K. kitty 当前 star 数量才接近 13.9K.

当然, 这个 star 数量并不能说明什么, 因为 Rust 拥有众多的 Rustaceans (老灯也是铁杆 Rustacean) , 以 Rust 光环, 加上 "the fastest terminal emulator" 的营销口号, 获取 star 数量确实不在话下.

当然, kitty 也不是什么 Hello Kitty, 而是实实在在的一个功能完备的终端. Alacritty 在我看来, 只是配合 tmux 使用的一个辅助工具. 离开了 tmux 的 Alacritty 对我来说, 毫无用处, 甚至不如 Gnome Terminal.

我想有必要写文章分享一下 kitty 这么优秀的软件. (鉴于 kitty 的作者是如此低调)

很多时候, 你喜欢一个语言, 自然而然的会希望你手里用的工具都是基于这个语言的. 老灯便是如此. 但是今日试用了 kitty, 老灯觉得, 语言是不是 Rust 已经不重要了. kitty 的魅力足够让我抛弃语言之类的偏见.

kitty 具备完整的功能, 而 Alacritty 别说支持分屏了, 连最基本的多 tab 都不支持. 所以, 应该没有人直接用 Alacritty, 基本上都是搭配 tmux 之类的终端复用器来使用.

关于 terminal multiplexers

terminal multiplexers 的典型代码当然是 tmux 了, 当然, 这里是泛指这一类程序.

作者认为, terminal multiplexers 是一个 bad idea.

First, terminal multiplexers are a bad idea, do not use them, if at all possible. kitty contains features that do all of what tmux does, but better, with the exception of remote persistence (#391).
In summary: multiplexers add unnecessary overhead, suffer from a complexity cascade, because they actually have to translate escape codes, modifying them in hackish ways to get them to work with their concepts of windows/sessions.
Energy/performance wise they are poison, every byte has to be parsed twice, once by the middleman and once by the terminal. And they act as a drag on the ecosystem as a whole, making it very hard to get any new features. Designing features becomes harder because you have to design for compatibility with a horrible hack and the diffusion into the ecosystem tends to get gated by basically a handful of individuals with, let's say, very limited vision.

机器翻译下吧:

首先，终端多路复用器是一个坏主意，如果可能的话，不要使用它们。kitty 包含的功能做了Tmux 所做的一切，但更好，除了远程持久化（#391）。
总结：多路复用器增加了不必要的开销，遭受了复杂的级联，因为它们实际上必须翻译转义代码，以黑客的方式修改它们，以使它们与它们的窗口/会话概念一起工作。
能源/性能方面，它们是毒药，每一个字节都要被解析两次，一次由中间人解析，一次由终端解析。而且它们是整个生态系统的拖累，使其很难获得任何新功能。设计功能变得更加困难，因为你必须为兼容一个可怕的黑客而设计，而且扩散到生态系统中往往会被一小撮具有非常有限的视野的人所阻止。

所以, 当你用着 tmux 还觉得它很高级的时候, 事实上它是一种很古老的东西, 从设计上来说, 它并不优雅, 只是解决了需求问题. 作为 tmux + Alacritty 用户, 其实一直也没深入了解 tmux 的实现, 今天读到 kitty 作者的这段话, 奇怪的知识又增加了.

性能

kitty 的核心部分采用 C 编写, UI 界面采用 python 以方便扩展.

这里老灯采用这个脚本进行一个简单的测试(from https://github.com/alacritty/alacritty/issues/289#issuecomment-340283908):

for i in {1..400000}; do
  echo -e '\r'
  echo -e '\033[0K\033[1mBold\033[0m \033[7mInvert\033[0m \033[4mUnderline\033[0m'
  echo -e '\033[0K\033[1m\033[7m\033[4mBold & Invert & Underline\033[0m'
  echo
  echo -e '\033[0K\033[31m Red \033[32m Green \033[33m Yellow \033[34m Blue \033[35m Magenta \033[36m Cyan \033[0m'
  echo -e '\033[0K\033[1m\033[4m\033[31m Red \033[32m Green \033[33m Yellow \033[34m Blue \033[35m Magenta \033[36m Cyan \033[0m'
  echo
  echo -e '\033[0K\033[41m Red \033[42m Green \033[43m Yellow \033[44m Blue \033[45m Magenta \033[46m Cyan \033[0m'
  echo -e '\033[0K\033[1m\033[4m\033[41m Red \033[42m Green \033[43m Yellow \033[44m Blue \033[45m Magenta \033[46m Cyan \033[0m'
  echo
  echo -e '\033[0K\033[30m\033[41m Red \033[42m Green \033[43m Yellow \033[44m Blue \033[45m Magenta \033[46m Cyan \033[0m'
  echo -e '\033[0K\033[30m\033[1m\033[4m\033[41m Red \033[42m Green \033[43m Yellow \033[44m Blue \033[45m Magenta \033[46m Cyan \033[0m'
done

机器环境为 X11 + Nvidia + ArchLinux

Intel i9-9900 (16) @ 4.000GHz

Resolution: 3840x2160

Alacritty 0.10.1 (2844606d) + tmux 3.2a 17s
kitty 0.24.324s
GNOME Terminal 3.42.2 using VTE 0.66.2 24s
Wez Terminal 20220101-133340-7edc5b5a 44s

Wez Terminal 是真的卡. 跟 Alacritty 一样同样是 Rust 写的东西, 怎么速度上差这么多呢? 所以, 语言并不能决定性能. 还得看你怎么写的.

关于 WezTerminal 的性能差的问题, reddit 上两年前就有人提了, 没想到两年后还是这样.

配置

kitty 基本上是开箱即用的.

但是由于我是一个 Alacritty + tmux 用户, 因此自然希望, 习惯上的很多快捷键能得以保留.

折腾好的配置在这: https://github.com/ttys3/my-kitty-config

默认的kitty_mod ctrl+shift 保留下来了.

注意不要试图将 kitty_mod 设置成 ctrl+a , 这是不会工作的. 因为 kitty_mod has to be modifiers not keys. see https://github.com/kovidgoyal/kitty/discussions/3457#discussioncomment-587511

You can download a sample kitty.conf file with all default settings and comments describing each setting by clicking: sample kitty.conf.

Kittens

kitten意为"幼猫", 而 kitty 是"猫咪" 的意思. 这个取名也相当有意思.

kittens 相当于 kitty 的插件. 内置的所有 kittens 可以在这里找到: https://sw.kovidgoyal.net/kitty/kittens_intro/

diff

老灯觉得这个 kitty-diff 显示的色彩效果是真的好, 咋一看以为打开了 gui 的 meld.

使用方法:

kitty +kitten diff file1 file2

甚至还可以集成到 git, 将以下配置添加到 ~/.gitconfig 中:

[diff]
    tool = kitty
    guitool = kitty.gui
[difftool]
    prompt = false
    trustExitCode = true
[difftool "kitty"]
    cmd = kitty +kitten diff $LOCAL $REMOTE
[difftool "kitty.gui"]
    cmd = kitty kitty +kitten diff $LOCAL $REMOTE

diff 功能老灯对比了一下同是 python 实现的 meld, 发现 meld 的 diff 能够区分同一行的不同字符的变动, 而 kitty 的并不能, 以下是对比图:

另一个问题是, 在 dark terminal colorscheme 下面, kitty 默认的白色背景的 diff 结果显得怪怪的, 这里有一个黑色版的, 不过老灯看着也不是很满意, 还不如直接用白色背景版的.

目前来说, delta 的 diff 效果和配色默认用着也挺舒服的. 所以在kitty diff 功能改进之前, 老灯还是继续用 delta.

icat

icat 可以直接在 kitty 里面显示图片, 老灯直接用 4k 图片测试过了, 显示效果相当好.

ImageMagick must be installed for icat to work.

alias icat="kitty +kitten icat"

themes

themes 可以让你即时预览主题效果, 并支持一键切换.

kitty +kitten themes

search

https://github.com/trygveaa/kitty-kitten-search

这是一个第三方的 kitten

Troubleshooting

1. zoom panel 功能

kitty 并没有像 tmux 一样自带这个功能, 但是其扩展能力极强, 实现这个非常轻松.

参考 https://sw.kovidgoyal.net/kitty/kittens/custom/#using-kittens-to-script-kitty-without-any-terminal-ui

在 kitty 配置目录下创建文件 ~/.config/kitty/zoom_toggle.py, 内容如下:

def main(args):
    pass

from kittens.tui.handler import result_handler
@result_handler(no_ui=True)
def handle_result(args, answer, target_window_id, boss):
    tab = boss.active_tab
    if tab is not None:
        if tab.current_layout.name == 'stack':
            tab.last_used_layout()
        else:
            tab.goto_layout('stack')

注意, stack layout 必须要被允许.

The first layout listed in enabled_layouts in kitty.conf will be the default.

ref https://github.com/kovidgoyal/kitty/issues/2258#issuecomment-571201141

老灯现在的配置是 enabled_layouts splits,stack

实现这一功能的 issue 在这 https://github.com/kovidgoyal/kitty/issues/870#issuecomment-429313856

通过提交记录发现, 作者实现这一功能的支持, 只改动了几行代码. 不得不佩服.

2. session 保存和加载

已经有讨论, 但是并无进展:

https://github.com/kovidgoyal/kitty/issues/1197#issuecomment-785435558

在 tmux 里面, 我们可以使用 tmux-plugins/tmux-resurrect 和 tmux-plugins/tmux-continuum 两个插件实现自动 dump 和加载 session

kitty 这边目前好像还没有这样直接就拿来能用的插件方案.

kitty 内置了 session 支持, 也就是说它支持 session restore, 但是 dump 这一方便好像没有比较官方的支持.

如果能在退出时自动 dump 出可以直接用于 restore 的 session 配置, 那么其实这个功能就会比较好实现了.

静态 session 配置比较简单: https://github.com/ttys3/my-kitty-config#session-restore

dump 功能目前有第三方实现可用: https://github.com/kovidgoyal/kitty/issues/1197#issuecomment-785435558

注意 kitty @ ls 需要开启 allow_remote_control yes (改这个需要重启kitty, reload 配置不会生效)

3. status line

老灯 tmux 下的 status line 大概长这样:

这个不是刚需, 而且, 可以采用 DE 顶部的 status line 解决

kitty 有 panel 貌似可以实现类似的功能: https://sw.kovidgoyal.net/kitty/kittens/panel/

不过我一直没能让它显示出来...

搞笑的是, 有人问这个作者, 文档里面的 demo 脚本, 作者回答这个涉及隐私信息不能给你 Orz

https://github.com/kovidgoyal/kitty/issues/2523

lol. wtf? A sensitive status command? this is a first.

4. terminfo 问题

如果你尝试ssh到远程机器, 可能会发现你本机的zsh报错:

/home/user007/.zsh_compatible:bindkey:2: cannot bind to an empty key sequence

这个问题其实不只存在于 kitty, 任何有自己独立的 terminfo 的 terminal (且其信息没有在ncurses中内置), 基本上都会有这个问题. 比如 Alacritty 也有这个问题.

这个问题官方faq文档里面也有说明: I get errors about the terminal being unknown or opening the terminal failing when SSHing into a different computer?

This happens because the kitty terminfo files are not available on the server. You can ssh in using the following command which will automatically copy the terminfo files to the server:
kitty +kitten ssh myserver
This ssh kitten takes all the same command line arguments as ssh, you can alias it to ssh in your shell’s rc files to avoid having to type it each time:
alias ssh="kitty +kitten ssh"

https://github.com/kovidgoyal/kitty/issues/879

有人建议提交 xterm-kitty terminfo 到 ncurses 数据库, 这样ssh到安装了较新的 ncurses 的系统上便不会有识别不了xterm-kitty 的问题.

不过这个作者说, ncurses 那边的人不喜欢他, 不给它集成进去. 2018年的issue, 现在2022年了, 确实是件难事哈.

https://github.com/kovidgoyal/kitty/issues/879#issuecomment-419686348

So to summarize the ncurses maintainer's response:
He does not like kitty's license (I'm happy to change the license of just the terminfo file to CC license, if needed)
He does not like kitty TERM variable. This is not going to change as it would break lots of programs that turn on various features when they see a TERM variable of the type xterm-whatever. A situation that was created by the ncurses maintainer refusing to add new capabilities for various things.
He does not like the fact that kitty has introduced new capabilities into the terminal ecosystem
About what I expected from my previous interactions with him. He excels at presenting excuses to maintain the status quo. I'm afraid I am not interested in tying kitty to this particular boat anchor. There's a reason the terminal ecosystem has stagnated for so long, and ncurses is a big part of that stagnation.

使用 kitty +kitten ssh 之类的方式连接也是挺蛋疼的. 老灯干脆让它标榜自己为 xterm-256color 算了, 就像我给 Alacritty 设置的一样. 另外, Gnome Terminal 也是用的 xterm-256color , 所以, 这个应该问题不大.

编辑 kitty.conf设置 term xterm-256color 即可.

ref: https://sw.kovidgoyal.net/kitty/conf/#opt-kitty.term

5. kitty 误变成 inode/directory 的默认打开程序

不知是我手抖误设置了还是 kitty 安装的时候设置的.

经过检查, 发现 /usr/share/applications/mimeinfo.cache 文件中 inode/directory 的值变成了 kitty-open.desktop 跑在了 org.gnome.Nautilus.desktop 的前面.

inode/directory=kitty-open.desktop;org.gnome.Nautilus.desktop;vifm.desktop;visual-studio-code.desktop;

当然, 我们不用动/usr/share/applications/mimeinfo.cache这个文件, 编辑 ~/.config/mimeapps.list 加上下面这一行即可修正:

inode/directory=org.gnome.Nautilus.desktop

目前缺少的功能

copy mode / vim mode

see https://github.com/kovidgoyal/kitty/issues/1698

Refs

kitty icon 来自 https://github.com/DinkDonk/kitty-icon

Unicode 7.0 text characters aren't displayed / too wide #3312

https://sw.kovidgoyal.net/kitty/overview/#design-philosophy

https://sw.kovidgoyal.net/kitty/kittens_intro/#kittens

https://sw.kovidgoyal.net/kitty/kittens/themes/#how-it-works

https://sw.kovidgoyal.net/kitty/overview/#other-keyboard-shortcuts

https://sw.kovidgoyal.net/kitty/conf.html#opt-kitty.enabled_layouts

https://github.com/dflock/kitty-save-session

https://github.com/trygveaa/kitty-kitten-search

rust-motd Setup

ttyS3 — Tue, 04 Jan 2022 18:36:01 GMT

2022-03-04 update:

gdm 用户最好不要启用 motd. 否则在登录界面会卡很久才进去.

有办法可以禁用这一行为, see https://bbs.archlinux.org/viewtopic.php?pid=1684018#p1684018

moving the following line:

session    optional   pam_motd.so          motd=/etc/motd

from /etc/pam.d/system-login to /etc/pam.d/sshd.

The result is that the motd is no longer displayed in gdm, but it's still displayed when logging in through ssh.

--------------------------------------------------------------------------------

https://github.com/rust-motd/rust-motd

Beautiful, useful, configurable MOTD generation with zero runtime dependencies

如果显示 hostname 时想使用 figlet 的话需要安装一下:

paru -S figlet

the oneshot service

cat <<EOF > /etc/systemd/system/rust-motd.service

[Unit]
Description=run rust-motd
Wants=network-online.target
After=network-online.target

[Service]
Restart=on-failure
TimeoutStopSec=5
StandardOutput=file:/etc/motd
ExecStart=rust-motd /root/.config/rust-motd/config.toml
Type=oneshot

[Install]
WantedBy=default.target

EOF

the timer:

cat <<EOF > /etc/systemd/system/rust-motd.timer

[Unit]
Description=Run rust-motd every 5 minutes and on boot

[Timer]
OnBootSec=30s
OnUnitActiveSec=5min 

[Install]
WantedBy=timers.target

EOF

the config:

注意替换配置中的 Your-Location-Here 为你的实际城市名(英文).

替换 user001 为你自己的用户名.

cat <<EOF > /root/.config/rust-motd/config.toml
[global]
 progress_full_character = "="
 progress_empty_character = "="
 progress_prefix = "["
 progress_suffix = "]"
 time_format = "%Y-%m-%d %H:%M:%S"

 [banner]
color = "red"
 command = "hostname | figlet -f slant"
# if you don't want a dependency on figlet, you can generate your
# banner however you want, put it in a file, and then use something like:
# command = "cat banner.txt"

 [weather]
 url = "https://wttr.in/Your-Location-Here?0"
 proxy = "http://127.0.0.1:7890"

# [service_status]
# Accounts = "accounts-daemon"
# Cron = "cron"

[docker_status]
# Local containers MUST start with a slash
# https://github.com/moby/moby/issues/6705
#"/nextcloud-nextcloud-mariadb-1" = "Nextcloud Database"

 [uptime]
 prefix = "Up"

 [user_service_status]
 clash = "clash"
 systemd-resolved = "systemd-resolved"
 gpg-agent = "gpg-agent"

# [ssl_certificates]
# sort_method = "manual"
#
#    [ssl_certificates.certs]
#    CertName1 = "/path/to/cert1.pem"
#    CertName2 = "/path/to/cert2.pem"

 [filesystems]
 root = "/"
 home = "/home"

 [memory]
 swap_pos = "beside" # or "below" or "none"

# [fail_2_ban]
# jails = ["sshd", "anotherjail"]

 [last_login]
 root = 2
 user001 = 1

[last_run]


EOF

enable:

sudo systemctl enable --now rust-motd.timer

Debugging Delta 0.10.x slowdown problem on Linux

ttyS3 — Mon, 20 Dec 2021 17:23:10 GMT

其实从 0.10.x 开始就觉得 delta 老慢了, 但是一直没怀疑到是 delta 自身的bug.

有一天, 正好在 github 上面看到有人提 issue, 说当系统进程较多时, delta 扫描所有进程, 这里花了大量时间导致变慢.

然后作者很快发布了一个新版本 0.11.2 , 说这个问题解决了扫进程时慢的问题.

但是我到手一测试, 发现依然可以肉眼感受到这个"慢".

flamegraph 分析: 定位问题

先上 flamegraph 分析一波.

完整的交互式svg flamegraph (需要用web浏览器打开):

找到tower top:

展开:

很快发现, 锅是 sysinfo::linux::processor::get_cpu_frequency 的, 它发起的系统调用(用来检测每个 cpu logic core 的频率)很慢.

delta::utils::process::determine_calling_process
|
V
sysinfo::linux::system::System::refresh_processors
|
v
sysinfo::linux::processor::get_cpu_frequency

最简单验证, 直接注释掉 determine_calling_process 对 sysinfo::linux::system::System::refresh_processors 的调用,

速度马上恢复了. 从原来的 300ms 降到了 50ms 左右了.

不过禁用这个调用, 并没有真正解决问题, 而只是屏蔽了这个问题.

为什么需要获取进程信息, delta 的作者特意详细解释了:

The downside of disabling that call is that delta will not be able to handle any of the following:

git diff --word-diff / git diff --color-words git grep and other grep's (but it will handle rg --json) git show $commit:$file git blame language detection So that would be a shame, and I'd like to find a solution whereby we can do the process inspection in a way that is fast for all users.

如果不能获取进程信息, 那么这些高级功能(0.10版本引入的, 0.9没有)全没了. 这显然是不可接受的.

delta src/utils/process.rs sysinfo::System::new():

impl ProcInfo {
    fn new() -> Self {
        ProcInfo {
            info: sysinfo::System::new(),
        }
    }
}

sysinfo::System::new() :

    fn new() -> Self {
        Self::new_with_specifics(RefreshKind::new())
    }

new_with_specifics will always try to refresh_processors:

by default, !refreshes.cpu() result in !false , so it is true:

fn new_with_specifics(refreshes: RefreshKind) -> System {
       // ...
        if !refreshes.cpu() {
            s.refresh_processors(None); // We need the processors to be filled.
        }
        s.refresh_specifics(refreshes);
 // ...
}

there seems no way to forbbide refresh_processors call.

if we change the new to sysinfo::System::new_with_specifics(sysinfo::RefreshKind::new().with_cpu())

the first s.refresh_processors(None); will not get called.

but in s.refresh_specifics(refreshes);, it get called again.

所以, 这种情况, 不修改上游代码无法解决问题.

模拟复现

简单写了个 demo (完整的demo代码见repo: https://github.com/ttys3/get-cpu-frequency-slow):

use std::fs::File;
use std::io::Read;
use std::time::Instant;
use std::env;

const DEFAULT_CPU_NUM: i32 = 16;

fn main() {
    let mut args = env::args();
    // skip self
    args.next();

    // your logic CPU core number
    let num_cpu = if let Some(num_cpu) = args.next() {
        num_cpu.parse::<i32>().unwrap_or(DEFAULT_CPU_NUM)
    } else {
        DEFAULT_CPU_NUM
    };

    // weather force read from /proc/cpuinfo, it is important because when
    // the system has NO /sys/devices/system/cpu/cpu{}/cpufreq/scaling_cur_freq
    // this program run rather fast
    let force_cpuinfo = if let Some(force_cpuinfo) = args.next() {
        force_cpuinfo.parse::<bool>().unwrap_or(false)
    } else {
        false
    };

    println!("num_cpu={} force_cpuinfo={}", num_cpu, force_cpuinfo);

    if force_cpuinfo {
        println!("skip readding cpu freq from sysfs, directly to /proc/cpuinfo");
    }

    let start = Instant::now();

    // this for loop simulate the logic in `refresh_processors()`
    // see https://github.com/GuillaumeGomez/sysinfo/blob/01218743c7e656b7f12f530713ba417d2c5940ad/src/linux/system.rs#L146
    for i in 0..num_cpu {
        get_cpu_frequency(force_cpuinfo, i as usize);
    }

    let duration = start.elapsed();
    println!("total time elapsed in get_cpu_frequency()x{} is: {:?}", num_cpu, duration);
}

// the func `get_cpu_frequency` took from https://docs.rs/crate/sysinfo/0.19.2/source/src/linux/processor.rs
// mainly for debugging and verify that delta 0.10.x slowdown problem is caused by `sysinfo` crate
// see https://github.com/dandavison/delta/issues/839
// added force_cpuinfo parameter
fn get_cpu_frequency(force_cpuinfo: bool, cpu_core_index: usize) -> u64 {
    let mut s = String::new();

    if !force_cpuinfo {
        if File::open(format!(
            "/sys/devices/system/cpu/cpu{}/cpufreq/scaling_cur_freq",
            cpu_core_index
        ))
            .and_then(|mut f| f.read_to_string(&mut s))
            .is_ok()
        {
            let freq_option = s.trim().split('\n').next();
            if let Some(freq_string) = freq_option {
                if let Ok(freq) = freq_string.parse::<u64>() {
                    return freq / 1000;
                }
            } else {
                println!("try get cpu freq from sysfs failed, fallback to /proc/cpuinfo");
            }
        }
        s.clear();
    }

    if File::open("/proc/cpuinfo")
        .and_then(|mut f| f.read_to_string(&mut s))
        .is_err()
    {
        return 0;
    }
    let find_cpu_mhz = s.split('\n').find(|line| {
        line.starts_with("cpu MHz\t")
            || line.starts_with("BogoMIPS")
            || line.starts_with("clock\t")
            || line.starts_with("bogomips per cpu")
    });
    find_cpu_mhz
        .and_then(|line| line.split(':').last())
        .and_then(|val| val.replace("MHz", "").trim().parse::<f64>().ok())
        .map(|speed| speed as u64)
        .unwrap_or_default()
}

验证结果:

当从 /sys/devices/system/cpu/cpu{}/cpufreq/scaling_cur_freq 读取时, 存在系统调用获取单个 cpu 频率, 非常慢, 如果是解析 /proc/cpuinfo 则非常快.

很明显, 我的情况是从/sys/devices/system/cpu/cpu{}/cpufreq/scaling_cur_freq 读取.

由于我的 CPU 是 8c16t的:

a single run will cost about 16ms, thus 16 core CPU result in about 256ms

所以, CPU 逻辑核越多, delta 越慢.

另一哥们就更惨了, 他是 32 thread 的 CPU, delta 每次执行差不多要花1秒多! (see https://github.com/dandavison/delta/issues/844)

国外开源氛围

我给 delta 提了个 issue, 然后发现上游有问题.

delta 作者 dandavison 当时提出了两个方案: 一是给上游提个issue尝试解决, 二是换别的库. 比如 https://docs.rs/heim/0.0.11/heim/process/struct.Process.html

最终 delta 作者去 upstream 提 issue了: https://github.com/GuillaumeGomez/sysinfo/issues/632

几经折腾, sysinfo 的作者终于将代码改成满足 delta 的需求场景了.

delta 的需求是: 只需要获取进程的父进程id, 而不需要执行进程的 cpu 执行时间.

目前 delta 0.11.3 已经发布, 解决了上述 Linux 下面慢的问题. https://github.com/dandavison/delta/releases/tag/0.11.3

所以, 国外的开源作者, 一般还都是挺友好的, 大家互相合作.

delta 作者并没有因为是我提的 issue 而要求我去 sysinfo 作者那里继续提 issue, 而是默默地自己去主动提 issue 解决了.

sysinfo 作者也并没有用任何借口拒绝重构代码,添加选项. 更没有以"这是你的小众需求, 我这个代码在90% 的情况下都不会有你说的性能问题的." 而关闭 issue, 而是三番五次的改进, 最终, 他还主动跑到 delta 的 PR 下面来确认工作 OK (see https://github.com/dandavison/delta/pull/845#issuecomment-991650195).

其它思考

这个问题跟Linux系统调用有关, 而且是跟硬件有关, CPU 逻辑核越多的电脑上越慢. 至少 CPU 逻辑核心数量 > 10 个以上, 人才可能容易感知到这种执行速度下降.

不能盲目相信 benchmark 工作的结果, 因为 benchmark 的时候调用存在缓存, 导致结果错误. 一个简单的 sleep 1 可以模拟真实场景.

using benchmark tool like hyperfine will NOT present the problem,

something like hyperfine -r 1000 'delta Cargo.toml Cargo.toml.bak' will give you wrong conclusion

the reason is caching affects the real world problem. although the benchmark tool is OK, and it also works as expected.

it shows the result like this (6 core machine):

❯ hyperfine -r 1000 'delta Cargo.toml Cargo.toml.bak'
Benchmark 1: delta Cargo.toml Cargo.toml.bak
  Time (mean ± σ):      55.3 ms ±   8.7 ms    [User: 47.1 ms, System: 5.8 ms]
  Range (min … max):    50.7 ms … 149.7 ms    1000 runs

but in real world, users will not always run git diff continuous. so the cacehing will not work. and every time the user may get the delay.

in real world, it is more like this:

I use a simple sleep 1 to make the caching not work any more.

for (( c=1; c<=10; c++ ))
do
   sleep 1
   time delta Cargo.toml Cargo.toml.bak > /dev/null
done

the result on a 6 core CPU, most of the execution cost >= 100ms :

# this test run under a 6 core CPU machine
❯ for (( c=1; c<=10; c++ ))
do
   sleep 1
   time delta Cargo.toml Cargo.toml.bak > /dev/null
done
delta Cargo.toml Cargo.toml.bak > /dev/null  0.05s user 0.00s system 62% cpu 0.091 total
delta Cargo.toml Cargo.toml.bak > /dev/null  0.05s user 0.00s system 45% cpu 0.122 total
delta Cargo.toml Cargo.toml.bak > /dev/null  0.05s user 0.00s system 41% cpu 0.136 total
delta Cargo.toml Cargo.toml.bak > /dev/null  0.04s user 0.01s system 52% cpu 0.110 total
delta Cargo.toml Cargo.toml.bak > /dev/null  0.05s user 0.01s system 39% cpu 0.142 total
delta Cargo.toml Cargo.toml.bak > /dev/null  0.05s user 0.01s system 45% cpu 0.122 total
delta Cargo.toml Cargo.toml.bak > /dev/null  0.05s user 0.00s system 39% cpu 0.143 total
delta Cargo.toml Cargo.toml.bak > /dev/null  0.05s user 0.01s system 46% cpu 0.121 total
delta Cargo.toml Cargo.toml.bak > /dev/null  0.05s user 0.01s system 101% cpu 0.055 total
delta Cargo.toml Cargo.toml.bak > /dev/null  0.05s user 0.00s system 40% cpu 0.141 total

in a benchmark situation, it is more like this (with out the sleep), yes, you may found that it is at low latency, about 50ms

# this test run under a 6 core CPU machine
❯ for (( c=1; c<=10; c++ ))
do
   time delta Cargo.toml Cargo.toml.bak > /dev/null
done
delta Cargo.toml Cargo.toml.bak > /dev/null  0.05s user 0.01s system 100% cpu 0.055 total
delta Cargo.toml Cargo.toml.bak > /dev/null  0.05s user 0.01s system 101% cpu 0.054 total
delta Cargo.toml Cargo.toml.bak > /dev/null  0.05s user 0.00s system 101% cpu 0.055 total
delta Cargo.toml Cargo.toml.bak > /dev/null  0.05s user 0.01s system 100% cpu 0.056 total
delta Cargo.toml Cargo.toml.bak > /dev/null  0.05s user 0.01s system 100% cpu 0.055 total
delta Cargo.toml Cargo.toml.bak > /dev/null  0.04s user 0.02s system 101% cpu 0.055 total
delta Cargo.toml Cargo.toml.bak > /dev/null  0.05s user 0.01s system 90% cpu 0.063 total
delta Cargo.toml Cargo.toml.bak > /dev/null  0.06s user 0.00s system 85% cpu 0.068 total
delta Cargo.toml Cargo.toml.bak > /dev/null  0.05s user 0.00s system 99% cpu 0.058 total
delta Cargo.toml Cargo.toml.bak > /dev/null  0.05s user 0.01s system 100% cpu 0.055 total

使用开源工具遇到问题, 不要把全部的问题抛出给原作者, 有能力的情况下, 可以协助解决, 很多作者还是会热心回答和采纳的. 解决问题的过程中, 自己也能学到新的东西.
留下一个问题: 为什么获取单个核心 CPU 频率的系统调用 (通过读取 sysfs 触发的) 那么慢 (每个调用大概耗时在 15ms 以上)? 暂时没空看了, 文章先写到这吧.

Refs

https://github.com/dandavison/delta/issues/839

https://github.com/dandavison/delta/issues/824

https://github.com/dandavison/delta/pull/845

https://github.com/GuillaumeGomez/sysinfo/issues/632

https://github.com/dandavison/delta/releases/tag/0.11.3

Rust Trait Lifetime Bounds

ttyS3 — Mon, 20 Dec 2021 16:19:13 GMT

提问的故事 -- 废话哥 vs 高效哥

起因我折腾的时候, 升级了 zero-to-production 这个仓库的 tracing-bunyan-formatter 版本,

它当前依赖的是 0.2 版的 tracing-bunyan-formatter 和 tracing-subscriber :

tracing-subscriber = { version = "0.2.12", features = ["registry", "env-filter"] }
tracing-bunyan-formatter = "0.2.2"

但是由于 0.3 版的 tracing-subscriber 的 MakeWriter trait 签名改变了, 所以 0.3 版的 tracing-bunyan-formatter 的 new 方法的定义也改变了, 导致我直接编译不过.

0.2 的定义是这样的:

pub fn get_subscriber(
    name: String,
    env_filter: String,
    sink: impl MakeWriter + Send + Sync + 'static,
) -> impl Subscriber + Sync + Send {
    let env_filter =
        EnvFilter::try_from_default_env().unwrap_or_else(|_| EnvFilter::new(env_filter));
    let formatting_layer = BunyanFormattingLayer::new(name, sink);
    Registry::default()
        .with(env_filter)
        .with(JsonStorageLayer)
        .with(formatting_layer)
}

重点是这里的 sink: impl MakeWriter + Send + Sync + 'static

升级到 0.3 后就直接报错了:

error[E0106]: missing lifetime specifier
  --> src/telemetry.rs:18:16
   |
18 |     sink: impl MakeWriter + Send + Sync + 'static,
   |                ^^^^^^^^^^ expected named lifetime parameter
   |
help: consider introducing a named lifetime parameter
   |
15 ~ pub fn get_subscriber<'a>(
16 |     name: String,
17 |     env_filter: String,
18 ~     sink: impl MakeWriter<'a> + Send + Sync + 'static,
   |

For more information about this error, try `rustc --explain E0106`.
error: could not compile `zero2prod` due to previous error

这里的问题在于, 你如果一直试图按编译器的错误提示(tips)去修正错误, 是不可能完成这个fix的.

比如我按它上面的提示加个lifetime param <'a> :

pub fn get_subscriber<'a>(
    name: String,
    env_filter: String,
    sink: impl MakeWriter<'a> + Send + Sync + 'static,
) -> impl Subscriber + Sync + Send {
    let env_filter =
        EnvFilter::try_from_default_env().unwrap_or_else(|_| EnvFilter::new(env_filter));
    let formatting_layer = BunyanFormattingLayer::new(name, sink);
    Registry::default()
        .with(env_filter)
        .with(JsonStorageLayer)
        .with(formatting_layer)
}

然后你会发现这个报错越来越复杂了:

❯ cargo check
    Checking zero2prod v0.1.0 (/home/ttys3/repo/rust/zero-to-production)
error[E0277]: expected a `Fn<()>` closure, found `impl MakeWriter<'a> + Send + Sync + 'static`
  --> src/telemetry.rs:22:61
   |
22 |     let formatting_layer = BunyanFormattingLayer::new(name, sink);
   |                            --------------------------       ^^^^ expected an `Fn<()>` closure, found `impl MakeWriter<'a> + Send + Sync + 'static`
   |                            |
   |                            required by a bound introduced by this call
   |
   = note: wrap the `impl MakeWriter<'a> + Send + Sync + 'static` in a closure with no arguments: `|| { /* code */ }`
   = note: required because of the requirements on the impl of `for<'a> MakeWriter<'a>` for `impl MakeWriter<'a> + Send + Sync + 'static`
note: required by `BunyanFormattingLayer::<W>::new`
  --> .../tracing-bunyan-formatter-0.3.1/src/formatting_layer.rs:71:5
   |
71 |     pub fn new(name: String, make_writer: W) -> Self {
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
help: consider further restricting this bound
   |
18 |     sink: impl MakeWriter<'a> + Send + Sync + 'static + std::ops::Fn<()>,
   |                                                       ++++++++++++++++++

error[E0277]: expected a `Fn<()>` closure, found `impl MakeWriter<'a> + Send + Sync + 'static`
  --> src/telemetry.rs:22:28
   |
22 |     let formatting_layer = BunyanFormattingLayer::new(name, sink);
   |                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected an `Fn<()>` closure, found `impl MakeWriter<'a> + Send + Sync + 'static`
   |
   = note: wrap the `impl MakeWriter<'a> + Send + Sync + 'static` in a closure with no arguments: `|| { /* code */ }`
   = note: required because of the requirements on the impl of `for<'a> MakeWriter<'a>` for `impl MakeWriter<'a> + Send + Sync + 'static`
note: required by a bound in `BunyanFormattingLayer`
  --> .../tracing-bunyan-formatter-0.3.1/src/formatting_layer.rs:43:37
   |
43 | pub struct BunyanFormattingLayer<W: for<'a> MakeWriter<'a> + 'static> {
   |                                     ^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `BunyanFormattingLayer`
help: consider further restricting this bound
   |
18 |     sink: impl MakeWriter<'a> + Send + Sync + 'static + std::ops::Fn<()>,
   |                                                       ++++++++++++++++++

error[E0277]: expected a `Fn<()>` closure, found `impl MakeWriter<'a> + Send + Sync + 'static`
  --> src/telemetry.rs:26:15
   |
26 |         .with(formatting_layer)
   |          ---- ^^^^^^^^^^^^^^^^ expected an `Fn<()>` closure, found `impl MakeWriter<'a> + Send + Sync + 'static`
   |          |
   |          required by a bound introduced by this call
   |
   = note: wrap the `impl MakeWriter<'a> + Send + Sync + 'static` in a closure with no arguments: `|| { /* code */ }`
   = note: required because of the requirements on the impl of `for<'a> MakeWriter<'a>` for `impl MakeWriter<'a> + Send + Sync + 'static`
   = note: required because of the requirements on the impl of `__tracing_subscriber_Layer<Layered<JsonStorageLayer, Layered<EnvFilter, Registry>>>` for `BunyanFormattingLayer<impl MakeWriter<'a> + Send + Sync + 'static>`
help: consider further restricting this bound
   |
18 |     sink: impl MakeWriter<'a> + Send + Sync + 'static + std::ops::Fn<()>,
   |                                                       ++++++++++++++++++

error[E0277]: expected a `Fn<()>` closure, found `impl MakeWriter<'a> + Send + Sync + 'static`
  --> src/telemetry.rs:19:6
   |
19 | ) -> impl Subscriber + Sync + Send {
   |      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected an `Fn<()>` closure, found `impl MakeWriter<'a> + Send + Sync + 'static`
   |
   = note: wrap the `impl MakeWriter<'a> + Send + Sync + 'static` in a closure with no arguments: `|| { /* code */ }`
   = note: required because of the requirements on the impl of `for<'a> MakeWriter<'a>` for `impl MakeWriter<'a> + Send + Sync + 'static`
   = note: required because of the requirements on the impl of `__tracing_subscriber_Layer<Layered<JsonStorageLayer, Layered<EnvFilter, Registry>>>` for `BunyanFormattingLayer<impl MakeWriter<'a> + Send + Sync + 'static>`
   = note: required because of the requirements on the impl of `tracing::Subscriber` for `Layered<BunyanFormattingLayer<impl MakeWriter<'a> + Send + Sync + 'static>, Layered<JsonStorageLayer, Layered<EnvFilter, Registry>>>`
help: consider further restricting this bound
   |
18 |     sink: impl MakeWriter<'a> + Send + Sync + 'static + std::ops::Fn<()>,
   |                                                       ++++++++++++++++++

For more information about this error, try `rustc --explain E0277`.
error: could not compile `zero2prod` due to 4 previous errors

不能继续这样下去了, 继续按它的提示 tips 修改, 永远也无法修复这个问题.

于是我去作者的这本书(我购买了他的电子书)的Discord群里问, 结果一周了还没人回答出我要的答案. 其中有一个回答了, 说了一堆废话最后的意思是: 你应该坚持使用 0.2 版的.

我就感觉这个人有点搞笑了... 纯浪费时间. 此为 "废话哥"

然后突然有一天, 来了另一个哥们 (此为"高效哥", "快手"-_-), 这哥们(不认识的 dude)二话不说直接把我拉进了一个 discoard thread, thread 标题也非常简单明了直接: "fixing get_subscriber"

这哥们直接说:

"MakeWriter现在需要一个lifetime我搞不定."
@asonix 好像上次更新这玩意是你弄的. 也许你可以帮我看下怎么搞定这个升级? 我无法弄明白怎么在这添加一个带lifetime的参数: https://github.com/LukeMathWalker/zero-to-production/blob/42d4f6a024fda2e7bc277679a595e3edfa2cb6c9/src/telemetry.rs#L18

然后 asonix 这哥们居然很快现身了. 回答道:

你可能需要放弃 impl MakeWriter 这种形式，转而使用泛型参数。你需要 for<'a> MakeWriter<'a> 约束所以你最终会得到

fn my_fn<M>(sink: M) -> impl Subscriber
where
    M: for<'a> MakeWriter<'a> + 'static,
{
  // ... 
}

dude: "Oh, wow, 多谢! 我还没在 Rust 里面用过这个 for 语法"
asonix: 是的，for 语法有点奇怪，但它用于表示“对于任何给定的生命周期都是如此”，而不是将约束限制为特定的生命周期，这很有用

最后, 这哥们 at 了一下我,

"来啦, 答案在这"

整个来回不超过6句话, 问题已经解决了.

于是我又回过头看 "提问的智慧"

发现里面真的有一句 "话不在多而在精".

所以, 其实这么多年了, 我还只掌握了这个文档的皮毛.

我在提问的时候, 提供了过多的无关信息(错误日志, 上下文等), 从而导致人们不想看, 因为没人想看一堆乱七八糟的东西. 大家都喜欢简单.
我没有以"最高效" 的方式提问.

这个哥们的提问为什么有如此高效的得到准确的答案? 原因是, 他是动过脑子的, 不是无脑地在群里直接提问. 而是有针对的 at 了相关作者.

比如这个例子里面, 使用到了 `tracing-bunyan-formatter 这个 crate, 通过一些基本的观察技能, 不难发现这个 commit 的作者正是 asonix:

https://github.com/LukeMathWalker/tracing-bunyan-formatter/commit/7acebe58a5ae3079e938a9a0a6dab1a7b5226692

一般人喜欢用相同的昵称, 根据这一点, 这哥们直接在 discord 群里 at 了 asonix, 并且以建立 thread 的方式, 相当于单独拉小黑屋讨论了.

为什么?

所以正确的参数是啥? 是这样:

pub fn get_subscriber<W>(
    name: String,
    env_filter: String,
    sink: W,
) -> impl Subscriber + Sync + Send
    where
        W: for<'a> MakeWriter<'a> + Sync + Send +  'static {
    let env_filter =
        EnvFilter::try_from_default_env().unwrap_or_else(|_| EnvFilter::new(env_filter));
    let formatting_layer = BunyanFormattingLayer::new(name, sink);
    Registry::default()
        .with(env_filter)
        .with(JsonStorageLayer)
        .with(formatting_layer)
}

impl MakeWriter + Send + Sync + 'static 要换成泛型参数, 然后给泛型参数增加约束.

所以 pub fn get_subscriber 变成 pub fn get_subscriber<W>

sink: impl MakeWriter + Send + Sync + 'static 变成 sink: W, 然后增加约束:

    where
        W: for<'a> MakeWriter<'a> + Sync + Send +  'static

我们看下 tracing-subscriber crate tracing_subscriber::fmt::MakeWriter 这个 trait 的变化, 其实也能找到模式.

0.2 版的时候是这样:

https://docs.rs/tracing-subscriber/0.2.25/tracing_subscriber/fmt/trait.MakeWriter.html

pub trait MakeWriter {
    type Writer: Write;
    fn make_writer(&self) -> Self::Writer;

    fn make_writer_for(&self, meta: &Metadata<'_>) -> Self::Writer { ... }
}

0.3 版就大变样了: https://docs.rs/tracing-subscriber/0.3.3/tracing_subscriber/fmt/trait.MakeWriter.html

pub trait MakeWriter<'a> {
    type Writer: Write;
    fn make_writer(&'a self) -> Self::Writer;

    fn make_writer_for(&'a self, meta: &Metadata<'_>) -> Self::Writer { ... }
}

那么, 原来的不是挺好的吗? 为什么要做这种改变?

我们去看一下 0.3.0 版的更新记录: https://github.com/tokio-rs/tracing/releases/tag/tracing-subscriber-0.3.0 果然发现这么一条:

fmt: Added a lifetime parameter to the MakeWriter trait, allowing it to return a borrowed writer. This enables implementations of MakeWriter for types such as Mutex<T: io::Write> and std::fs::File. (#781)

在 #781 https://github.com/tokio-rs/tracing/pull/781 这个 PR 里面, 作者详细地解释了做这种 breaking change 的必要性.

Motivation

Currently, the tracing-subscriber crate has the MakeWriter trait for customizing the io writer used by fmt. This trait is necessary (rather than simply using a Write instance) because the default implementation performs the IO on the thread where an event was recorded, meaning that a separate writer needs to be acquired by each thread (either by calling a function like io::stdout, by locking a shared Write instance, etc).

Right now there is a blanket impl for Fn() -> T where T: Write. This works fine with functions like io::stdout. However, the other common case for this trait is locking a shared writer.

Therefore, it makes sense to see an implementation like this:

impl<'a, W: io::Write> MakeWriter for Mutex<W>
where
    W: io::Write,
{
    type Writer = MutexWriter<'a, W>;
    fn make_writer(&self) -> Self::Writer {
        MutexWriter(self.lock().unwrap())
    }
}

pub struct MutexWriter<'a, W>(MutexGuard<'a, W>);

impl<W: io::Write> io::Write for MutexWriter<'_, W> {
    // write to the shared writer in the `MutexGuard`...
}

Unfortunately, it's impossible to write this. Since MakeWriter always takes an &self parameter and returns Self::Writer, the generic parameter is unbounded:

    Checking tracing-subscriber v0.2.4 (/home/eliza/code/tracing/tracing-subscriber)
error[E0207]: the lifetime parameter `'a` is not constrained by the impl trait, self type, or predicates
  --> tracing-subscriber/src/fmt/writer.rs:61:6
   |
61 | impl<'a, W: io::Write> MakeWriter for Mutex<W>
   |      ^^ unconstrained lifetime parameter

error: aborting due to previous error

This essentially precludes any MakeWriter impl where the writer is borrowed from the type implementing MakeWriter. This is a significant blow to the usefulness of the trait. For example, it prevented the use of MakeWriter in tracing-flame as suggested in #631 (comment).

Proposal

This PR changes MakeWriter to be generic over a lifetime 'a:

pub trait MakeWriter<'a> {
    type Writer: io::Write;

fn make_writer(&'a self) -> Self::Writer;

The self parameter is now borrowed for the &'a lifetime, so it is okay to return a writer borrowed from self, such as in the Mutex case.

I've also added an impl of MakeWriter for Mutex<T> where T: Writer.

Unfortunately, this is a breaking change and will need to wait until we release tracing-subscriber 0.3.

Signed-off-by: Eliza Weisman

所以, 做这种破坏性变更的动机是, 实际实现这个trait的时候,遇到了一些麻烦, 比如当实现里面需要lifetime, 而 trait 定义本身并没有这个 lifetime 时, 编译通不地这.

Refs

https://docs.rs/tracing-subscriber/0.2.25/tracing_subscriber/fmt/trait.MakeWriter.html

https://docs.rs/tracing-subscriber/0.3.3/tracing_subscriber/fmt/trait.MakeWriter.html

https://github.com/LukeMathWalker/tracing-bunyan-formatter/commit/7acebe58a5ae3079e938a9a0a6dab1a7b5226692

https://github.com/LukeMathWalker/zero-to-production/blob/42d4f6a024fda2e7bc277679a595e3edfa2cb6c9/Cargo.toml#L28

Advanced Lifetimes https://doc.rust-lang.org/1.30.0/book/2018-edition/ch19-02-advanced-lifetimes.html#lifetime-bounds-on-references-to-generic-types

https://doc.rust-lang.org/rust-by-example/scope/lifetime/lifetime_bounds.html

https://doc.rust-lang.org/reference/trait-bounds.html

The “Advanced Lifetimes” section in Chapter 19 was removed because compiler improvements have made the constructs in that section even rarer. https://doc.rust-lang.org/beta/book/title-page.html

--EOF

lua-socket imcompatbility with Lua 5.4.3 and the fixup

ttyS3 — Tue, 19 Oct 2021 20:54:26 GMT

the problem

报错:

socket/http.lua:54: bad argument #1 to 'receive' (string expected, got light userdata)

the solution

有人已经提交一个 PR 了: https://github.com/diegonehab/luasocket/pull/334

根据这个 PR 的 review comment 来看, 貌似是这个提交漏改了一处: https://github.com/diegonehab/luasocket/commit/f329aae724573b87bd2a814f4858d29ca894600b

luarocks 其实是变相地支持从 git 仓库安装 rocks 的.

不过我测试 luarocks install https://example.com/xxxx.spec 失败了, 报的是网络问题, 但是实际上我用 curl 请求是成功的, 不太清楚原因. 因此只好把 spec 文件下载回来再 install.

拿 https://github.com/diegonehab/luasocket/blob/master/rockspec/luasocket-scm-2.rockspec 修改一下:

ersion = "scm-3"
source = {
  url = "git://github.com/pkulchenko/luasocket.git"
  , branch="lua-543-aux-buffer-fix"
}

我把修改后的结果直接放 gist 了, 安装:

cd /tmp/ && curl -LO https://gist.github.com/ttys3/31dbf88ee7d708294d8ae5b0a4954424/raw/c74afc3edc1a48c0f7e1c2c9992750301bbb74ff/luasocket-scm-3.rockspec
luarocks install ./luasocket-scm-3.rockspec

这样安装成功后, 发现还是报同样的错. 然后发现是通过 pacman 安装了 lua-socket 包, 其优先级不知道为什么居然比我的 luarocks 的要高.

简单处理, 把系统的先卸载了吧, 看上去没啥其它东西依赖它:

❯ ls /usr/lib/lua/5.4/socket 
 core.so   serial.so   unix.so

 
❯ paru -R lua-socket
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: removing lua-socket breaks dependency 'lua-socket' required by lua-copas
:: removing lua-socket breaks dependency 'lua-socket' required by lua-sec
  ☸ homenas (tkn-demo) in ~/.luarocks via  v5.4.3 
🔴 1 ❯ paru -R lua-socket lua-sec lua-copas
checking dependencies...
:: luarocks optionally requires lua-sec: HTTPS support

Package (3)  Old Version  Net Change

lua-copas    2.0.2-3       -0.10 MiB
lua-sec      2:1.0.2-1     -0.19 MiB
lua-socket   20200329-1    -0.23 MiB

Total Removed Size:  0.52 MiB

暂时来说, 问题解决. 等 https://github.com/diegonehab/luasocket 发新版本修复.

what is Light Userdata ?

https://www.lua.org/pil/28.5.html

https://www.shouce.ren/api/lua/5/_161.htm

目前为止我们使用的userdata称为full userdata。Lua还提供了另一种userdata: light userdata。

一个light userdatum是一个表示C指针的值（也就是一个void *类型的值）。由于它是一个值，我们不能创建他们（同样的，我们也不能创建一个数字）。可以使用函数lua_pushlightuserdata将一个light userdatum入栈：

void lua_pushlightuserdata (lua_State *L, void *p);

尽管都是userdata，light userdata和full userdata有很大不同。Light userdata不是一个缓冲区，仅仅是一个指针，没有metatables。像数字一样，light userdata不需要垃圾收集器来管理她。

有些人把light userdata作为一个低代价的替代实现，来代替full userdata，但是这不是light userdata的典型应用。首先，使用light userdata你必须自己管理内存，因为他们和垃圾收集器无关。第二，尽管从名字上看有轻重之分，但full userdata实现的代价也并不大，比较而言，他只是在分配给定大小的内存时候，有一点点额外的代价。

Light userdata真正的用处在于可以表示不同类型的对象。当full userdata是一个对象的时候，它等于对象自身；另一方面，light userdata表示的是一个指向对象的指针，同样的，它等于指针指向的任何类型的userdata。所以，我们在Lua中使用light userdata表示C对象。

看一个典型的例子，假定我们要实现：Lua和窗口系统的绑定。这种情况下，我们使用full userdata表示窗口（每一个userdatum可以包含整个窗口结构或者一个有系统创建的指向单个窗口的指针）。当在窗口有一个事件发生（比如按下鼠标），系统会根据窗口的地址调用专门的回调函数。为了将这个回调函数传递给Lua，我们必须找到表示指定窗口的userdata。为了找到这个userdata,我们可以使用一个表：索引为表示窗口地址的light userdata，值为在Lua中表示窗口的full userdata。一旦我们有了窗口的地址，我们将窗口地址作为light userdata放到栈内，并且将userdata作为表的索引存到表内。（注意这个表应该有一个weak值，否则，这些full userdata永远不会被回收掉。）

Solution to openssh-8.8-p1 update: no matching host key type found. Their offer: ssh-rsa

ttyS3 — Mon, 27 Sep 2021 16:46:46 GMT

  ~/.ssh 
❯ paru -Ss openssh | rg install
core/openssh 8.8p1-1 [0B 5.90MiB] [Installed]

如果你最近升级到了 openssh 8.8-p1 版, 你会发现连接某些之前连接得好好的服务器突然无法连接:

Unable to negotiate with x.x.x.x port 2222: no matching host key type found. Their offer: ssh-rsa

解决办法

ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedKeyTypes=+ssh-rsa  user@myhost -p 2222

当然, 每次连接敲这么一长串也不太好.

编辑用户 ssh 配置 ~/.ssh/config, 对于无法成功连接的host, 增加配置项:

  HostKeyAlgorithms         +ssh-rsa
  PubkeyAcceptedKeyTypes    +ssh-rsa

完整的配置可能看起来像这样:

Host myhost
  Hostname 	1.1.1.1
  User user001
  IdentityFile     ~/.ssh/id_rsa
  # fixup for openssh 8.8
  HostKeyAlgorithms +ssh-rsa
  PubkeyAcceptedKeyTypes +ssh-rsa

或者，像我一样的懒人:

Host *
     ServerAliveInterval 10
      HostKeyAlgorithms +ssh-rsa
      PubkeyAcceptedKeyTypes +ssh-rsa

为什么会有这个错误

根据 OpenSSH Release Notes

Future deprecation notice

It is now possible[1] to perform chosen-prefix attacks against the SHA-1 algorithm for less than USD$50K.
In the SSH protocol, the "ssh-rsa" signature scheme uses the SHA-1 hash algorithm in conjunction with the RSA public key algorithm. OpenSSH will disable this signature scheme by default in the near future.
Note that the deactivation of "ssh-rsa" signatures does not necessarily require cessation of use for RSA keys. In the SSH protocol, keys may be capable of signing using multiple algorithms. In particular, "ssh-rsa" keys are capable of signing using "rsa-sha2-256" (RSA/SHA256), "rsa-sha2-512" (RSA/SHA512) and "ssh-rsa" (RSA/SHA1). Only the last of these is being turned off by default.

也就是说 8.8p1 版的 openssh 的 ssh 客户端默认禁用了 ssh-rsa 算法, 但是对方服务器只支持 ssh-rsa, 当你不能自己升级远程服务器的 openssh 版本或修改配置让它使用更安全的算法时, 在本地 ssh 针对这些旧的ssh server重新启用 ssh-rsa 也是一种权宜之法.

Refs

http://www.openssh.com/releasenotes.html

https://www.openssh.com/legacy.html

用 caddy 代替 nginx, 一行配置搞定 php-fpm 反向代理

ttyS3 — Mon, 20 Sep 2021 09:42:23 GMT

缘由

caddy 其实并不是一个新项目, 虽然早在 caddy 1.x 版本的时候老灯就关注这个项目了, 但是,老灯其实最近才开始去了解它和尝试使用它.

为什么之前一直没用 caddy 呢? 一是当时 nginx 还是非常坚挺, 可以说在 nginx + php-fpm 这一搭配方面, 基本上无敌手. 二是, 当时我试用过 Caddyfile 后,发现它太简洁了,简洁到我以配置 nginx 的思维, 完全无法适应配置 Caddyfile. 没错, 我当时觉得 , 配置 nginx 比 Caddyfile 简单多了 (因为 nginx 配置已经熟练多年).

从提交记录看, https://github.com/caddyserver/caddy/blob/v1/LICENSE.txt 最早可以追溯到2015年.

简单来说, Caddy 是一个使用 Golang 编写的 http 静态文件服务器和反向代理服务器.

大概一年前,作者重构了 caddy, 也就是现在的 caddy 2.x 版. HN 上面依然可以找到他宣布 caddy 2 出来的消息:

mholt on May 4, 2020 [–]
Hi HN -- this is what I've been working on for the last 14 months, with the help of many contributors and the backing of several sponsors. (Thank You!) Caddy 2 is a fresh new server experience. Some things might take getting used to, like having every site served over HTTPS unless you specify http:// explicitly in your config. But in general, it will feel familiar to v1 in a lot of ways. If you've used v1 before, I recommend going into v2 with a clean-slate using our Getting Started guide: https://caddyserver.com/docs/getting-started
I'm excited to finally get this out there. Let me know what questions you have!

via https://news.ycombinator.com/item?id=23070567

那么, 为什么现在对 Caddy 感兴趣了?

一. 云原生

单文件静态链接. 我在打包 PHP 应用的时候, 如果用 caddy, copy 一个文件即可. 不需要考虑各种动态链接和依赖.
自带 metrics ( https://caddyserver.com/docs/metrics)
自带 REST api (https://caddyserver.com/docs/api)

二. 作为 Golang 程序员, 对于基于 Go 实现的东西, 有一种天生的好感.

Caddyfile 结构

下图取自官方文档: https://caddyserver.com/docs/caddyfile/concepts#structure

整个配置文件按块划分.

第一个红色的大 block 是全局配置块, 如果存在,它必须放在第一个块的位置.

每个 option 的配置, 基本上是 key - value 或者 key - list 的形式.

每个 snippet 也是单独成为一个 block, snippet 可以方便相同的配置复用,避免手动 copy 配置使得同样的配置分布在多处而难以维护.

每个站点单独成为一个 block.

这个配置足够简洁, 对于新手也极其友好.

关于配置这一块, 想要进一步了解的,可以查看官方文档, 同时推荐读一下飞雪无情写的 Caddy实战（十一）| Caddyfile 设计之美

配置 php-fpm 反向代理

从官方文档点击 "Common Patterns", 然后其中就有关于 PHP 的说明.

配置一个 caddy + php-fpm 的博客, 全部指令如下:

example.com

root * /var/www
php_fastcgi /blog/* localhost:9000
file_server

example.com指定域名(默认监听https),

root * /var/www指定站点根目录.

php_fastcgi /blog/* localhost:9000 表示所有匹配 /blog/*的请求的 *.php 文件, 都被代理到 php-fpm 的监听地址 (localhost:9000)

如果要使用 unix socket 也是支持的, 将 localhost:9000替换成相应的 socket 地址即可, 如 unix//run/php/php8.0-fpm.sock

file_server 用于serve静态文件.

404问题

没错, 上面的配置, 在大部分情况下是工作的. 对于现在一些基于流行 PHP 框架的应用, 比如基于 Symfony / Laravel / CodeIgniter / CakePHP / Phalcon 等, 大多数是以单一入口来跑的. 对于单一入口的应用, 404 错误都是交给应用程序层面来处理的, 而不是 http 服务器.

对于非单一入口应用程序, 典型的是, 你手里有一个几年前的程序, 没有用任何框架, 这个时候, caddy 的默认配置, 404 的问题就出来了.

the problem

这个问题直接描述比较抽象, 所以我这里举例子说明. 假设配置如下:

# listen http and https both for example.com
{$SITE_ADDRESS:http://example.com, https://example.com} {
	root * /app/public

	# https://caddyserver.com/docs/caddyfile/directives/php_fastcgi
	php_fastcgi 127.0.0.1:9000

	file_server

	handle_errors {
        root * /etc/caddy/error
		rewrite * /error.html
		templates
		file_server
	}
}

本意是, 如果有 404 或 403 等错误, 由 /error.html来处理, 但是实际上访问不存在的 url, 如

/this-is-not-found.html
/blah-this-is-another-notfound/xxxxxx
/xxxxxxx
/sub/xxx/sub/xxxxx

404 错误并没有发送给 handle_errors 这个 handler 来处理, 而是直接被 php index.php 处理了. 由于这个程序并不是单一入口应用, 因此它的 index.php 完全不知道如何错误 404 错误请求的 uri.

尝试解决

然后我继续查看 Caddy 文档, 发现 php_fastcgi 有一个 Expanded form , 我尝试把其中的 try_files {path} {path}/index.php index.php 修改为 try_files {path} {path}/index.php 之后,大部分 404 错误解决了. 但是以 .php 结尾的文件的 404 错误还是无法处理.

经过修改的完整的配置如下:

# listen http and https both for example.com
{$SITE_ADDRESS:http://example.com, https://example.com} {
	root * /app/public

	# https://caddyserver.com/docs/caddyfile/directives/php_fastcgi
	# php_fastcgi 127.0.0.1:9000
	route {
		# Add trailing slash for directory requests
		@canonicalPath {
			file {path}/index.php
			not path */
		}
		redir @canonicalPath {path}/ 308

		# If the requested file does not exist, try index files
		@indexFiles file {
			# try_files {path} {path}/index.php index.php
			try_files {path} {path}/index.php
			split_path .php
		}
		rewrite @indexFiles {http.matchers.file.relative}

		# Proxy PHP files to the FastCGI responder
		@phpFiles path *.php
		reverse_proxy @phpFiles 127.0.0.1:9000 {
			transport fastcgi {
				split .php
			}
		}
	}

	file_server


	handle_errors {
        root * /etc/caddy/error
		rewrite * /error.html
		templates
		file_server
	}
}

目前这个配置还存在的问题, 无法处理 .php 结尾文件的 404 错误, 如

/this-is-no-fount.php
/sub1/sub2/sub3/xxxxx.php

这种并不存在的 php 文件, 还是会被代理到 php-fpm 进程处理, 然后触发 php-fpm 响应 " No input file specified. " 的错误, 这个错误并不友好, 也不是我们期望的处理方式.

为了避免 " No input file specified. " 错误, 在 nginx 里面我们一般只需要这样处理:

	# Pass the php scripts to fastcgi server specified in upstream declaration.
	location ~ \.php(/|$) {
		# avoid No input file specified
		try_files  $uri =404;
		
		include fastcgi_params;
		
		# the missing param in fastcgi_params copied from fastcgi.conf
		fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
		
		fastcgi_pass 127.0.0.1:9000;

		fastcgi_buffer_size   64k;
		fastcgi_buffers    8 256k;
		fastcgi_busy_buffers_size 256k;
	}

没错, 神奇的地方就在于 try_files $uri =404; 这一行配置.

由于我其实等于是刚看了5分钟文档, 之前并没有真正使用 caddy, 因此我也不知道如何处理这一情况. 于是我把这个问题发到 github 上面了.

然后其中一个热心开发者 Francis Lavoie 马上给出了解决方案:

Francis Lavoie 觉得这是一个好问题. 他建议用一个 error 指令来解决:

# Trigger error for non-existing PHP scripts
@phpNotFound {
    path *.php
    not file
}
error @phpNotFound 404

这样, 不存在的 php 文件就会触发 404 错误, 不会继续交给 php-fpm 处理.

更好的实现方案

使用 error 指令加 Expanded form 确实能解决问题. 但是这是一个典型的应用场景, 应该还可以使配置更简化.

由于我对于 caddy 的代码并不了解,我的想法是"解决问题", 所以我的理解是,简单地增加两个选项:

always_proxy_to_index ( try_files {path} {path}/index.php index.php , off 的时候去掉最后面的 index.php)
pass_to_error_handler (遇到404等错误时,抛给其它 handler, 如 handle_errors)

但是, Francis Lavoie 的理解显然更加透彻, 他认为增加两个狭义的选项(使用场景非常有限), 容易使配置越来越复杂(后面要的功能更多,情况越复杂,这样的选项会越来越多). 于是便有了这两个 PR

Add support for triggering errors from try_files #4346 https://github.com/caddyserver/caddy/pull/4346

Implement try_files override in Caddyfile directive #4347 https://github.com/caddyserver/caddy/pull/4347

大约一周过去了, 这两个 PR 都被 mholt (caddy 创始人和主要开发者) review 并合并进去了.

第一个 PR 其实就是给 try_files 实现了类似 nginx =404 这种功能.

第二个 PR 是允许对 try_files 进行 override. 这样 php_fastcgi 默认的try_files 就可以被自定义了.

这两个提交预计会在 caddy 2.5.0 版本发布.

到时候, 我的配置就可以简写为:

# listen http and https both for example.com
{$SITE_ADDRESS:http://example.com, https://example.com} {
	root * /app/public

	# https://caddyserver.com/docs/caddyfile/directives/php_fastcgi
	php_fastcgi localhost:9000 {
		try_files {path} {path}/index.php =404
	}

	file_server

	handle_errors {
        root * /etc/caddy/error
		rewrite * /error.html
		templates
		file_server
	}
}

不得不说, 这样实现, 使得整个配置变得更优雅. 功能增加了, 但是并没有增加新的配置指令和选项.

思考

使用开源产品时,遇到了问题,不要抱怨, 要有耐心,积极参与讨论.

如果一个东西不完善, 并且你发现了这一点, 积极地提出来, 说不定开发者就采纳了, 改进了. 不单是你, 其它有同样需求的人也会受益.

实现一个东西的时候, 不要只考虑解决当前问题而导致代码膨胀, 而是要看到问题的本质, 以更优雅地方式去解决.

最后, 提一下, caddy 与 php 集成的时候, 还有一些性能优化相关的问题没解决, https://github.com/caddyserver/caddy/issues/3803

#1467 - Failed to read auto-increment value from storage engine

ttyS3 — Sat, 04 Sep 2021 09:36:20 GMT

插入数据时自增id出错了

INSERT INTO `xxxx` (`id`, `name`, `url`, `info`) VALUES (NULL, 'blahblahblah', '/xxxx', '');

#1467 - Failed to read auto-increment value from storage engine

看看表的自增id现在是多少: ```SHOW CREATE TABLE xxxx`

CREATE TABLE `xxxx` (
  `id` tinyint(3) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(128) NOT NULL DEFAULT '',
  `url` varchar(255) NOT NULL DEFAULT '',
  `info` varchar(255) NOT NULL DEFAULT '',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=18446744073709551615 DEFAULT CHARSET=utf8mb4

WTF ? AUTO_INCREMENT=18446744073709551615? AUTO_INCREMENT 的值已经爆掉了.

至于为什么爆掉了,原因不明. 有可能是以前从 MyISAM 转 InnoDB 的时候出问题了? 不清楚.

修正下表的自增id:

ALTER TABLE `xxxx` AUTO_INCREMENT=(SELECT MAX(id) FROM xxxx);

然后再执行插入操作就行了.

Refs: https://stackoverflow.com/a/31557413/13267147

什么样的代码才算正确的?

ttyS3 — Sun, 11 Jul 2021 15:07:16 GMT

当然, 本来是不会有这篇文章的.

写这篇文章的原因, 非常复杂.

公司将团队沟通工具切换成了飞书 ->

飞书没有 Linux 客户端但是有网页版 ->

我下载了网上一个叫 electron-lark 的网页版飞书客户端然后发现使用有些问题(跑个一天或几天不关, 会把桌面窗口的 title 全搞没了, 具体发生了什么我也没细看, 不开这个app就没事, 如果开了出现问题 alt + f2 然后按 r 重启 GNOME SHELL 也能恢复正常. 我尝试去修复这个问题, 比如关闭 electronjs 的硬件加速. 但是问题一直没有得到解决 ->

我不得已自己开发了一个叫 lark-gtk 的同样是基于网页版飞书的客户端, webview 的主要实现基于 webkitgtk ->

经过多次改版,这个 lark-gtk 终于功能稳定了. 但是有一项日常使用非常频繁的功能,没有办法工作: 那就是 ctrl + v 发送图片 (这个操作在 electron-lark 是完全没有问题的)->

经过一番研究,我发现这个问题其实是 webkitgtk 的 ->

在某个夜黑风高的晚上, 我下载了当前使用版的 webkit 代码经过一番调试终于搞定了这个 ctrl + v 不工作的问题.

对于我来说, 其实问题就算解决了. 何不把它贡献给上游, 这样大家的问题都能得到解决? 提交给上游后,还有另一个好处, 你自己更新的时候再也不用自己编译了. 比如, 每次上游更新了代码, 你想要升级的时候, 你必须自己重新 patch 然后重新编译. 如果是普通的软件, 其实也无所谓, 但是 webkit 的代码, 编译一次大概是30分钟的样子, 确实还是有点费时间. (我的机器 CPU i9-9900 8c16t, RAM 32GB)

我知道我这个解决办法只能算是一个 workaround. but it works.

这么一个简单的 ctrl + v 的问题, 在 chromium 内核的所有浏览器里都不会存在的问题, 在 webkitgtk 存在多久了呢? 我也不清楚. 但是从 Can't paste images from clipboard 这个 issue 的创建时间 Mar 23, 2019 5:57pm GMT+0800 来看, 这个问题至少持久了两年以上了, 至今无人去解决.

所以, 我也真不知道这些开发大牛们都是去干嘛去了, 这么一个简单的功能, 但是又重要的功能, 没有给用户解决. 有人报告给了 GNOME (它家的 epiphany 浏览器是基于 webkitgtk 的), 然后 GNOME 那边的代表(来自 RedHat 的 Michael Catanzaro )说, 你应该报告给 webkit, 这是 webkit 的问题.

然后 Michael Catanzaro 指出一个链接 https://bugs.webkit.org/show_bug.cgi?id=177633 这个链接其实是 Carlos Garcia Campos 给 GTK 版的适配 new Pasteboard API 的 patch. 这个 patch 提交发生在什么时候呢? 2020-05-16 05:11 PDT, 也就是说, 即使没有 new Pasteboard API, 这个bug已经存在了. 在 Carlos Garcia Campos 适配 new Pasteboard API 后, 这个bug依旧存在. 到现在已经两年多了, 至今无人解决, 令我有点震惊, 开源项目现状就是这样? 还是 webkit 这样级别的开源项目?

我忐忑地将我这个蹩脚 patch 提交给了 webkit, 作为一个古老的项目, 提交 patch 的方式同样也相当古老.

首先我仔细阅读了两遍 https://webkit.org/contributing-code/ 这个页面.

简单来说, 就是要提交 patch , 首先你要有一个 bug, 好在我已经找到一个别人提交好的 bug 了, 那就是

https://bugs.webkit.org/show_bug.cgi?id=218519

提交 patch 后, GNOME 方面的 Michael Catanzaro (来自 RedHat) 回复了:

I have no doubt that it works, but that can't be the correct fix. readFilePathsFromClipboard should do what it says, not more. I haven't looked closely, but you might be one level too far down from the right place to fix this.

凭心而论, 他这回复也没什么毛病. 你这个 patch 虽然能修复问题, 能工作, 但是, 不应该这样来修.

毫无疑问, 这个 patch 肯定是会被 reject 的. 当然, 我并不是恼怒被拒, 而是有些失望, 一个简单的问题, 两年了还没人修. (为什么我能说是一个简单的问题? 因为我从来没看过 webkit 的代码, 加上几行 debug 日志, 编译两次之后, 也修复了这个问题. 只不过优雅的修复方法, 应该在其它地方加一些代码.)

我回复道:

Thanks for the quick reply. I think you are right, this is not a correct fix.
I'm not familiar with the WebKit code at all. And I'm just a normal user which wait the correct patch for about 8 months or maybe longer.
I can not do further investigation to finish the right patch.
And hope someone will continue the work.
Thank you all guys.

我的回复是完全实话实说的, 一来我确实没有多余的时间研究这个东西了, 我的要求很简单, 能稳定工作就行. 目前用自行patch后编译的版本已经能稳定工作了. 二来, 我确实不是浏览器引擎专家, 我对于 webkit 的了解完全建立在 Google 上. 这个问题应该交给专家们来修复.

我只是希望这些专家们能稍微加快一下进度 -_-

同时, 在专家们发布 "the correct fix" 之前, 我分享出我的 fixup, 其它有需要的人看到了, 也可以自取自用, 毕竟开源的东西还是有点好处, 你可以自己编译.

没错, 我只是一个普通的用户, just get me the fucking work done.

ctrl + v 是我每天要用的功能, 沟通的时候发图没有 ctrl + v 发送功能支持, 非常不方便.

发一个图的步骤变成了:

截图 -> 保存为文件 -> 打开文件 -> ctrl + v

如果 webkitgtk 没有这个 bug, 那么, 发一个图的步骤变成了正常操作:

截图 -> ctrl + v

然后我就思考了, 到底什么样的代码才算正确的?

显然, 对于开源项目来说, 需要维持代码的"优雅", 一个bug宁可存在, 也不可引入不优雅的修复.

也就是, 正确的定义, 已经只局限在代码了. 代码正确就行, 管你能不能正常工作?

缺少这个功能,这是不支持,这是特性, 不是 bug.

Leasing Routable IP Addresses with Podman Containers

ttyS3 — Sat, 10 Jul 2021 04:58:22 GMT

Leasing routable IP addresses with Podman containers

图 "Relic" by BFS Man is licensed under CC BY 2.0

Old Southern Pacific RR caboose sitting beside US 90 just east of Luling, TX. This was near another old railway car converted into a roadside diner, which had gone out of business. The 'FOR LEASE' sign is actually for the diner, but I suppose the caboose comes with it.

来自 https://www.flickr.com/photos/bfs_man/6265442738/in/photostream/

本文主要是受 RedHat "Leasing routable IP addresses with Podman containers" 一文启发而写的. 配图也采用了原文章的.

其实标题的意思就是使用 macvlan 网络.

在一些特定场景中，比如一些传统应用或者监控应用需要直接使用 HOST 的物理网络，则可以使用 kernel 提供的 macvlan 的方式，macvlan 是在 HOST 网卡上创建多个子网卡，并分配独立的 IP 地址和 MAC 地址，把子网卡分配给容器实例来实现实例与物理网络的直通，并同时保持容器实例的隔离性。Host 收到数据包后，则根据不同的 MAC 地址把数据包从转发给不同的子接口，在外界来看就相当于多台主机。macvlan 要求物理网卡支持混杂 promisc 模式并且要求 kernel 为 v3.9-3.19 和 4.0+，因为是直接通过子接口转发数据包，所以可想而知，性能比 bridge 要高，不需要经过 NAT。

创建 macvlan 类型的网络

在 podman 里面创建一个 macvlan 类型的网络, 可以使用如下命令:

sudo podman network create -d macvlan --macvlan enp0s31f6

/etc/cni/net.d/cni-podman1.conflist

enp0s31f6 是物理机的以太网口, 可以通过 ip addr show 找出来, 也可以通过 nmcli 比如:

❯ nmcli connect 
NAME                UUID                                  TYPE      DEVICE      
Wired connection 1  5b263355-a1ee-3aa5-b34d-c36eb142a04c  ethernet  enp0s31f6   
cni-podman0         bf710dcd-26b5-47ec-ac99-53673fef2c27  bridge    cni-podman0 
docker0             dff45e06-a6e5-4510-a636-255f3f00d55c  bridge    docker0     
virbr0              be3e2c28-1028-41f7-bfdc-1aed730a59e7  bridge    virbr0

可以看到, podman 实际上是使用的 CNI 配置.

什么是 CNI

Container Network Interface - networking for Linux containers

CNI 的仓库历史已经有 6 年之久了. 目前 CNI 是一个 CNCF 项目, 主要被 k8s 等应用.

同时, CNI 自己维护了一些核心插件,放在独立的仓库: https://github.com/containernetworking/plugins

CNI 核心插件主要包含:

Plugins supplied:

Main: interface-creating

bridge: Creates a bridge, adds the host and the container to it.
ipvlan: Adds an ipvlan interface in the container.
loopback: Set the state of loopback interface to up.
macvlan: Creates a new MAC address, forwards all traffic to that to the container.
ptp: Creates a veth pair.
vlan: Allocates a vlan device.
host-device: Move an already-existing device into a container.

Windows: Windows specific

win-bridge: Creates a bridge, adds the host and the container to it.
win-overlay: Creates an overlay interface to the container.

IPAM: IP address allocation

dhcp: Runs a daemon on the host to make DHCP requests on behalf of the container
host-local: Maintains a local database of allocated IPs
static: Allocate a static IPv4/IPv6 addresses to container and it's useful in debugging purpose.

Meta: other plugins

tuning: Tweaks sysctl parameters of an existing interface
portmap: An iptables-based portmapping plugin. Maps ports from the host's address space to the container.
bandwidth: Allows bandwidth-limiting through use of traffic control tbf (ingress/egress).
sbr: A plugin that configures source based routing for an interface (from which it is chained).
firewall: A firewall plugin which uses iptables or firewalld to add rules to allow traffic to/from the container.

Sample

The sample plugin provides an example for building your own plugin.

我们这里用到的主要是 macvlan (属于接口创建类的插件) 和 dhcp (属于 IPAM 类的插件).

IPAM 即 IP address allocation 的缩写, 即 IP 地址分配. 工作是分离的, 即接口创建和接口 IP 分配由不同的插件完成.

好了, 我们来看一下 podman 创建的 CNI 配置吧.

  ~
❯ bat /etc/cni/net.d/cni-podman1.conflist
{
   "cniVersion": "0.4.0",
   "name": "cni-podman1",
   "plugins": [
      {
         "type": "macvlan",
         "master": "enp0s31f6",
         "ipam": {
            "type": "dhcp"
         }
      }
   ]
}

没错, RedHat 的人写那个文章的时候, podman network 还没有创建 macvlan 的支持, 因此需要手动创建 CNI 配置. 老灯现在用的 podman 版本较新, 创建 macvlan 还是比较方便了:

  ~ 
❯ sudo podman version
Version:      3.2.2
API Version:  3.2.2
Go Version:   go1.16.5
Git Commit:   d577c44e359f9f8284b38cf984f939b3020badc3
Built:        Fri Jul  9 20:54:04 2021
OS/Arch:      linux/amd64

可以使用 inspect 查看一个网络的配置, 其实内容跟查看原生的 CNI 配置文件差不多:

  ~ 
❯ sudo podman network inspect cni-podman1
[
    {
        "cniVersion": "0.4.0",
        "name": "cni-podman1",
        "plugins": [
            {
                "ipam": {
                    "type": "dhcp"
                },
                "master": "enp0s31f6",
                "type": "macvlan"
            }
        ]
    }
]

首先, 这是一个 .conflist 的配置, 说明里面是有多个配置的 (plugins 里面是个数组). 但是这里其实只有一个配置([]里的第一层花括号), 这个配置有3个key: ipam, master 和 type. 所以主要的插件是 macvlan, 但是其实还依赖了 dhcp 插件.

使用 podman network ls 可以列出当前可用网络:

❯ sudo podman network ls
NETWORK ID    NAME         VERSION     PLUGINS
2f259bab93aa  podman       0.4.0       bridge,portmap,dnsname,firewall,tuning
95eef1959fbc  macvlan001   0.4.0       macvlan
b932778640d3  cni-podman1  0.4.0       macvlan

cni-podman1 是刚才通过命令创建的, macvlan001 是我之前手动编写 CNI 配置文件创建的.

使用 macvlan 创建容器

创建容器时指定网络为我们刚才创建的 cni-podman1 即可.

❯ sudo podman run -it --rm --network cni-podman1 docker.io/library/alpine sh
/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 5a:cf:de:c3:0a:27 brd ff:ff:ff:ff:ff:ff
    inet 192.168.8.51/24 brd 192.168.8.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::58cf:deff:fec3:a27/64 scope link 
       valid_lft forever preferred_lft forever
/ # ping -c4 192.168.8.123
PING 192.168.8.123 (192.168.8.123): 56 data bytes
64 bytes from 192.168.8.123: seq=0 ttl=42 time=0.186 ms
64 bytes from 192.168.8.123: seq=1 ttl=42 time=0.267 ms
64 bytes from 192.168.8.123: seq=2 ttl=42 time=0.323 ms
64 bytes from 192.168.8.123: seq=3 ttl=42 time=0.282 ms

--- 192.168.8.123 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.186/0.264/0.323 ms
/ #

然后我们可以发现这个容器被分配了一个 192.168.8.51 的 IP, 这个网段与 host 机处在同一个网段. 通过路由器的 dhcp server 可以看到这个地址被分配了.

我们可以直接 ping 通同一网段里的其它主机, 比如上面的 192.168.8.123,同时,从同一局域网的其它主机可以 ping 通这个地址:

//yangjunsss.github.io/2018-07-29/Docker-%E7%BD%91%E7%BB%9C-Host-Bridge-Macvlan-%E5%9F%BA%E6%9C%AC%E5%8E%9F%E7%90%86%E5%92%8C%E9%AA%8C%E8%AF%81/

❯ ssh [email protected]
Warning: Permanently added '192.168.8.123' (ED25519) to the list of known hosts.
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Fri Jul  9 21:07:11 2021 from 192.168.8.100
  root in homenas in ~ 
❯ ping 192.168.8.51
PING 192.168.8.51 (192.168.8.51) 56(84) bytes of data.
64 bytes from 192.168.8.51: icmp_seq=1 ttl=64 time=0.456 ms
64 bytes from 192.168.8.51: icmp_seq=2 ttl=64 time=0.227 ms
64 bytes from 192.168.8.51: icmp_seq=3 ttl=64 time=0.249 ms
64 bytes from 192.168.8.51: icmp_seq=4 ttl=64 time=0.180 ms
^C
--- 192.168.8.51 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3105ms
rtt min/avg/max/mdev = 0.180/0.278/0.456/0.105 ms

注意: 从本机是无法 ping 通这个地址的,这是 macvlan 的限制.

  ~ took 23s 
❯ ping 192.168.8.51
PING 192.168.8.51 (192.168.8.51) 56(84) bytes of data.
From 192.168.8.100 icmp_seq=1 Destination Host Unreachable
From 192.168.8.100 icmp_seq=2 Destination Host Unreachable
From 192.168.8.100 icmp_seq=3 Destination Host Unreachable
^C
--- 192.168.8.51 ping statistics ---
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4066ms
pipe 3

macvlan 的四种通信模式

有一个配置选项,刚才 podman 里面并没有展示出来, 那就是 macvlan 插件有一个可选的 mode 参数, 默认值是 bridge

mode (string, optional): one of “bridge”, “private”, “vepa”, “passthru”. Defaults to “bridge”. (https://www.cni.dev/plugins/current/main/macvlan/#network-configuration-reference)

macvlan 是一种网卡虚拟化技术，能够将一张网卡虚拟出多张网卡。

macvlan 的四种通信模式，常用模式是 bridge。

macvlan 支持四种模式：

private：子接口之间不允许通信，子接口能与物理网络通讯，所有数据包都经过父接口 eth0
vepa（Virtual Ethernet Port Aggregator)：子接口之间、子接口与物理网络允许通讯，数据包都经过 eth0 进出，要求交换机支持 IEEE 802.1Q。
bridge：子接口之间直接通讯，不经过父接口 eth0 ，性能较高，但是父接口 down 之后也同样丧失通讯能力。
passthru：Allows a single VM to be connected directly to the physical interface. The advantage of this mode is that VM is then able to change MAC address and other interface parameters.

所有模式都不能与父接口 eth0 通信，并且 macvlan 在公有云上的支持并不友好。

应用

macvlan 这种网络模式一般在云平台都会被限制, 因此大部分情况下应该是有直接操作物理 host 机权限的时候才可以使用这种模式.

由于 IP 是可路由的, 因此非常适合用来做一些路由器相关的事情. 比如跑一个 openwrt 容器等.

Refs

本文主要参考: https://www.redhat.com/sysadmin/leasing-ips-podman

https://github.com/containernetworking/cni

https://github.com/containernetworking/plugins

https://www.cni.dev/plugins/current/main/macvlan/

https://www.cni.dev/plugins/current/ipam/dhcp/

https://docs.docker.com/network/network-tutorial-macvlan/

http://yangjunsss.github.io/2018-07-29/Docker-%E7%BD%91%E7%BB%9C-Host-Bridge-Macvlan-%E5%9F%BA%E6%9C%AC%E5%8E%9F%E7%90%86%E5%92%8C%E9%AA%8C%E8%AF%81/

https://cloud.tencent.com/developer/article/1432601

https://cloud.tencent.com/developer/news/563351

Windows 10 添加程序到自启动的简单方法

ttyS3 — Tue, 29 Jun 2021 17:07:05 GMT

简单方法当然指的是点两下鼠标完事的。

方法当然是自来官方文档

Select the Start button and scroll to find the app you want to run at startup.
Right-click the app, select More, and then select Open file location. This opens the location where the shortcut to the app is saved. If there isn't an option for Open file location, it means the app can't run at startup.
With the file location open, press the Windows logo key + R, type shell:startup, then select OK. This opens the Startup folder.
Copy and paste the shortcut to the app from the file location to the Startup folder.

中文版：

选择“开始”按钮，然后滚动查找你希望在启动时运行的应用。
右键单击该应用，选择**“更多”，然后选择“打开文件位置”**。此操作会打开保存应用快捷方式的位置。如果没有“打开文件位置”选项，这意味着该应用无法在启动时运行。
文件位置打开后，按 Windows 徽标键 + R，键入“shell:startup”，然后选择“确定”。这将打开“启动”文件夹。
将该应用的快捷方式从文件位置复制并粘贴到**“启动”**文件夹中。

Windows WebView2 and Rust

ttyS3 — Sun, 27 Jun 2021 16:28:00 GMT

在 WebView2 出来之前，如果想要基于 webivew 技术开发桌面应用，在 Mac OSX 上面可以用 webkit, 在 Linux 上面可以用 GTK 版的 webkitgtk，但是在 Windows 上面只能用 MSHTML, 这个 MSHTML 使用起来各种不兼容。

现在，随着 m$ 的 edge 浏览器拥抱 Chromium 内核，WebView2 的出现，使得情况得到很大的改善。

这里的 WebView2 是专门指的微软的 WebView2

微软貌似比较喜欢 Rust, 还专门给 Rust 做了 windows 绑定：

https://docs.microsoft.com/en-us/windows/dev-environment/rust/rust-for-windows

https://crates.io/crates/windows

https://github.com/microsoft/windows-rs/

官方 crate 里面是有一个叫 WebView 的控件的，不过好像没有看到 example

当前 WebView2 支持的系统包括：

Windows 10
Windows 8.1
Windows 7
Windows Server 2019
Windows Server 2016
WindowsServer 2012
Windows Server 2012 R2
WindowsServer 2008 R2

连 Windows 7 都支持了，所以，其实系统方面不用担心了。这年头谁还用 XP ?

Distribution of apps using WebView2

基于 WebView2 的应用如何分发？

因为目前 WebView2 的运行时是需要单独安装的。

什么是 WebView2 运行时

WebView2 运行时是一个可再发行运行时，并用作 WebView2 应用的支持 Web 平台。此概念类似于 Visual C++/.NET 应用的 .NET 运行时。运行时包含经过修改Microsoft Edge (Chromium) 已针对应用进行优化和测试的二进制文件。运行时在安装时不会显示为用户可见的浏览器。
在生产环境中，在应用启动之前，必须确保运行时存在于用户设备上。 Microsoft Edge Stable 渠道不可用于 WebView2。该决定可防止应用在生产中依赖浏览器。

为什么 WebView2 运行时需要独立安装，微软也给出了详细的解释：

Microsoft Edge (Chromium) 不一定存在于所有用户设备上。例如，与 Windows Update 断开连接或不由 Microsoft 直接管理的设备 (大部分 Enterprise 和 EDU 市场) 可能没有浏览器。允许分发 WebView2 运行时可以避免依赖浏览器作为应用的先决条件。浏览器和应用具有不同的用例，因此依赖浏览器可能会对应用产生意外的负面影响。例如，IT 管理员可以对浏览器进行版本控制，以确保内部网站兼容性。 WebView2 运行时允许应用在主动管理浏览器更新时保持常青。与浏览器相反，运行时针对应用方案进行开发和测试，并且在某些情况下可能包括浏览器中尚未提供的 Bug 修复。

这也就是为什么 WebView2 的运行时是需要单独安装。微软特意为之的，将 WebView2 运行时与 Microsoft Edge 浏览器分开，还有另一个好处是，并不是所有人都愿意使用 Edge 浏览器，你总不能期望别人为了使用一个基于 WebView2 的 app 要安装整个 Edge 浏览器吧？所以，老灯也觉得，WebView2 运行时独立安装，虽然对于软件分布来说会增加一些困难，但是其实是优点多于缺点的。

分发模式

常青分发模式
固定版本分发模式

这两种方式各有好处和坏处吧，主要看具体需求。

常青分发模式

常青分发需要你的应用保持和较新版本的运行时兼容。

其中，常青分发模式部署的又分为：

联机部署
脱机部署

注：无论哪种部署，必要的操作包含：在应用安装程序或更新程序中包括运行时安装程序（Evergreen Bootstrapper 或 Evergreen Standalone Installer）

所谓“联机部署” 就是 app 在运行的时候，检测运行时是否已经安装，如果没有安装，则运行一个 2M 左右的运行时下载器（Evergreen Bootstrapper）

# 静默安装 Evergreen Bootstrapper
MicrosoftEdgeWebview2Setup.exe /silent /install

该方式具有以下优点：

仅在需要或不需要打包安装程序时安装运行时。
引导程序自动检测设备体系结构并安装匹配的运行时。
以静默方式安装运行时。
还可以选择将引导程序打包到你的应用中，而不是以编程方式按需下载它。

所谓“脱机部署” 就是 app 在运行的时候，检测运行时是否已经安装，如果没有安装，则执行独立安装程序

MicrosoftEdgeWebView2RuntimeInstaller{X64/X86/ARM64}.exe /silent /install

部署 Evergreen WebView2 运行时

设备上的所有 Evergreen 应用只需安装一次 Evergreen WebView2 运行时。 WebView2 运行时下载页上提供了许多工具。以下工具可帮助你部署常青运行时。

WebView2 运行时引导程序是一个小的 (大约 2 MB) 安装程序。 WebView2 运行时引导程序从与用户设备体系结构匹配的 Microsoft 服务器下载并安装 Evergreen Runtime。
使用链接以编程方式下载引导程序。
WebView2 运行时独立安装程序是在脱机环境中安装 Evergreen WebView2 运行时的完整安装程序。目前，引导程序和独立安装程序仅支持每台计算机安装，这需要提升。如果安装程序在未提升权限的情况下运行，系统将提示用户提升权限。

固定版本分发模式

固定版本分发模式以前称为自带发布。这种分发方式，其实就是你下载好了一个特定版本的运行时，解压出来，直接打包集成到你的应用程序里面。

对于具有严格兼容性要求的限制环境，请考虑使用固定版本分发模式。使用固定版本分发模式选择并打包特定版本的 WebView2 运行时。你可以为你的应用指定运行时更新的时间。固定版本分发模式不会接收任何自动更新。计划更新你的应用和运行时。

若要使用固定版本模式，请完成以下操作

下载固定版本程序包。
使用命令行或 WinRAR 等 expand {path to the package} -F:* {path to the destination folder} 工具解压缩包。避免通过文件资源管理器解压缩，因为它可能无法生成正确的文件夹结构。
在项目中包括解压缩的固定版本二进制文件。
指示创建 WebView2 环境时固定版本二进制文件的路径。
- 对于 Win32 C/C++，可以使用 CreateCoreWebView2EnvironmentWithOptions 函数创建环境。使用 browserExecutableFolder 参数指示包含的文件夹的路径 msedgewebview2.exe 。
- 对于 .NET，您可以执行以下任一选项来指定环境。
  备注
  必须指定环境，WebView2 Source 属性才能生效。
  - 在 CreationProperties / WebView2 (设置 ) WPFWinForms) 属性。使用 BrowserExecutableFolder CoreWebView2CreationProperties (WPF / WinForms) 类中的成员指示固定版本二进制文件的路径。
  - 使用 EnsureCoreWebView2Async (WPF / WinForms) 指定环境。使用 browserExecutableFolder CoreWebView2Environment.CreateAsync 中的参数指示固定版本二进制文件的路径。
将固定版本二进制文件打包并随你的应用一起提供。根据情况更新二进制文件。

看了下， ms 的 rust crate 里面并没有包含 CreateCoreWebView2EnvironmentWithOptions 相关的东西，github 上面有一个Rust 绑定 https://github.com/sopium/webview2

有提供这个方法：https://docs.rs/webview2/0.1.0/webview2/struct.EnvironmentBuilder.html

A builder for calling the CreateCoreWebView2EnvironmentWithOptions function.

Use Environment::builder() to create one.

Refs

使用 WebView2 分发应用： https://docs.microsoft.com/en-us/microsoft-edge/webview2/concepts/distribution

运行时下载： https://developer.microsoft.com/zh-cn/microsoft-edge/webview2/

WebView2 介绍： https://developer.microsoft.com/en-us/microsoft-edge/webview2/

管理用户数据文件夹 https://docs.microsoft.com/zh-cn/microsoft-edge/webview2/concepts/user-data-folder

开发安全 WebView2 应用的最佳方案 https://docs.microsoft.com/zh-cn/microsoft-edge/webview2/concepts/security

了解 WebView2 SDK 版本 https://docs.microsoft.com/zh-cn/microsoft-edge/webview2/concepts/versioning

如何调试 WebView2 应用 https://docs.microsoft.com/zh-cn/microsoft-edge/webview2/how-to/debug?tabs=devtools

gtk-rs 现已支持 GTK4 绑定

ttyS3 — Sat, 26 Jun 2021 05:39:45 GMT

6 月 22 日 gtk-rs 官方博客就发文了

距离上次发布已经过去很长时间了，正如您所猜测的，在这段时间内发生了很多事情。让我们从最重要的开始：

gtk-rs 现在为 GTK4 库提供绑定！

它们都可以在 gtk4-rs 仓库中找到。

甚至还写了一本介绍书来教用户如何使用 gtk4-rs。你可以在这里阅读它。接下来几天将发布有关 GTK4 的更详细的博客文章。

新网站和新logo

我们利用这个机会彻底重新设计了网站并制作了一个logo。既然你已经来了，不要犹豫，去看看吧！

GNOME 圈子

gtk-rs 现在是 “GNOME 圈子“ 的一部分！除了一些其他好处之外，它还允许我们的贡献者加入 GNOME 基金会。查看网站了解更多详情。

git 仓库更改

此版本还对 gtk-rs 仓库结构进行了更改。我们现在有三个主要仓库：

gtk-rs-core：它包含被认为是“核心”的 crate，因为它们同时被 GTK3 和 GTK4 使用，但也被其他项目如 gstreamer-rs 使用：

cairo
gdk-pixbuf
gio
glib
glib-macros
graphene
pango
pangocairo

gtk3-rs：包含属于 GTK3 生态系统的 crate：

atk
gdk
gdkx11
gtk3-macros

gtk4-rs：包含属于 GTK4 生态系统一部分的 crate：

gdk4
gdk4-wayland
gdk4-x11
gsk4
gtk4
gtk4-macros

关于这一点的另一个重点是：一个存储库中的所有 crate 现在共享相同的版本号。之前它有点乱，所以我们决定简化它。所以这里是每个存储库的版本号：

gtk-rs-core: 0.14
gtk3-rs: 0.14
gtk4-rs: 0.1

文档改进

gtk-rs crates 使用 C 文档，但是我们改进了它的渲染以使其对 Rust 开发人员更有用：

现在可以正确生成条目的链接。
如果代码示例不是用 Rust 编写的，我们现在添加警告以避免混淆。
我们添加了文档别名，因此您现在可以直接搜索信号名称甚至 C 函数名称。
现在还记录了全局函数、构建器模式、常量和静态。
不再呈现 C 特定的参数，因此不在 Rust 绑定中使用。

依赖项被重新导出

我们举个例子，而不是冗长的解释。您有一个 GTK 应用程序，并且还使用 Cairo 和 GDK。在此版本之前，您需要将所有 3 个依赖项添加到 Cargo.toml 文件中以便能够使用它们。现在，您只需要导入 GTK 即可：

use gtk::{cairo, gdk};

就是这样！它将使您对依赖项的管理更加简单。需要注意的是，它们也在前奏中，因此导入它将使您可以访问它们：

use gtk::prelude::*;

// ...
let x = cairo::something();
let y = gdk::something();

关于重新导出的最后一条说明： -sys crates 也以 ffi 的名称重新导出：

use gtk::ffi;

// You now have access to all raw C-functions of GTK.
// 您现在可以访问 GTK 的所有原始 C 函数。

重构 Value trait

主要的变化是对于不可为空的类型 Value::get() 永远不会返回 None，取代了之前令人困惑的 Value::get_some()。

此外，现在可以直接将 Value::get() 设为可空类型，而无需 Option 包装。如果该值实际上是 None 这将返回一个 Err。在值为 None 的情况下，这避免了一层展开。

还有一个新的通用的 ValueType trait，它由可在 Value 中使用的所有类型实现，并允许存储/检索此值的类型 into/from 一个Value （这里有点绕，觉得没翻译正确，原谅老灯吧 :( )。我贴出原文：There is also a new generic ValueType trait that is implemented by all types that can be used inside a Value and that allows storing/retrieving types of this value into/from a Value.

添加了 GTK 复合模板支持

要从 UI 文件构建小部件，您可以使用 gtk::Builder 或复合模板。对于前者，您必须保留一个 gtk::Builder 实例。使用复合模板时，您可以让您的自定义小部件（gtk::Widget 的子类）在内部使用该模板，区别在于能够通过定义在不同的 UI 文件中使用您的 CustomWidget：

<object class="CustomWidget">
  <property name="some-property">some-value</property>
</object>

您现在可以让您的 CustomWidget 使用 #[CompositeTemplate] 派生宏。这项工作最初是为 GTK4 Rust 绑定完成的，但也向后移植到 GTK3。有关示例，请参见此处或此处。

复合模板还允许您使用在 CustomWidget 上定义的方法作为直接来自 UI 文件的信号的回调，即使宏目前不支持 GTK3/GTK4 绑定......但别担心，我们正在努力解决！

新的和改进的宏

除了 glib::object_subclass 属性宏（请参阅有关子类化改进的段落的链接）之外，glib 现在还提供了一些其他宏，以使应用程序开发更容易并减少样板：

glib::clone!：这个宏允许自动克隆或创建弱引用加上闭包的升级，并大大简化了信号处理程序闭包的创建。该文档包含几个示例。虽然这个宏存在于

最后一个版本，它被完全重写并变得更强大，并获得了一个伴随的派生宏 glib::Downgrade，它使用所需的机制扩展自定义类型，用于克隆上下文中的弱引用！宏。 glib::GBoxed 和 glib::GSharedBoxed：这些派生宏允许在 glib::Values 中使用自定义 Rust 类型，这是 GObject 属性和信号参数/返回值或 GTK 树视图的内容所必需的。第一个宏总是在必要时克隆底层值，而第二个宏使用引用计数而不是正常克隆。 glib::gflags!和 glib::GEnum：这些宏允许在 glib::Values 中使用 Rust 枚举和位标志。有关示例，请参阅子subclassing docs。 glib::GErrorDomain：这个派生宏允许使用合适的 Rust 枚举作为 glib::Errors 的错误域。

有关 glib::GBoxed、glib::gflags 和 glib::GEnum 宏的更多示例，另请参阅子subclassing文档。

子类化(subclassing)的改进

由于引入了 glib::object_subclass derive 派生宏，因此实现 GObject 更加简单。此外，注册属性和信号现在需要更少的样板。请参阅此页面以获取完整示例，但最小示例现在如下所示：

mod imp {
    #[derive(Default)]
    pub struct MyObject;

    #[glib::object_subclass]
    impl ObjectSubclass for MyObject {
        const NAME: &'static str = "MyObject";

        type Type = super::MyObject;
        type ParentType = glib::Object;
    }

    impl ObjectImpl for MyObject {}
}

glib::wrapper! {
    pub struct MyObject(ObjectSubclass<imp::MyObject>);
}

impl MyObject {
    pub fn new() -> Self {
        glib::Object::new(&[]).unwrap()
    }
}

更好的cairo错误处理

使用 cairo 现在更符合人体工程学：fill() 或stroke() 等函数返回结果，而不需要手动检查Context::status()。此外，所有在 cairo 状态上对 expect() 的内部调用都被删除了，使调用者能够处理错误情况，而不是引起 panic.

Gir教程

gtk-rs crates 大多能自动生成，这要归功于 gir 项目。如果您还想生成自己的基于 GObject 的 crate 绑定，也可以使用它！为了帮助您，我们开始了一本教程书，可在此处获取。

命名改进

我们重命名了许多函数/方法，以使它们更符合 Rust 标准。具体来说，getter 函数从 get_something() 重命名为 something() 或 is_something()，而 setter 保持为 set_something()。此外，GObject 属性 getter/setter 失去了名称中的属性名称（即 set_property_something() 被 set_something() 取代）。

在此注意事项：

应用程序开发人员注意事项

应用程序开发人员应该使用 fix-getters-calls 来简化应用程序的迁移。如果您还希望 get 函数定义符合此版本中应用的 API 标准，请使用 fix-getters-def。

最低支持版本

gtk-rs 最低支持的 Rust 版本现在是 1.51

ATK: 2.18
Cairo: 1.14
GDK3: 3.18
GDK4: 4.0
GDK4-Wayland: 4.0
GDKX11: 3.18
GDK4-X11: 4.0
GDK-Pixbuf: 2.32
Gio: 2.48
GLib: 2.48
Graphene: 1.10
GSK4: 4.0
GTK3: 3.20
GTK4: 4.0
Pango: 1.38
PangoCairo: 1.38

迁移到 Rust 2018 版

gtk-rs crates 全部迁移到 Rust 2018 版本。正好因为 2021 年版越来越近了！

Refs

https://gtk-rs.org/gtk4-rs/stable/latest/book/

https://gtk-rs.org/blog/2021/06/22/new-release.html

Port Extensions to GNOME Shell 40

ttyS3 — Sat, 26 Jun 2021 04:39:03 GMT

2021年4月份新发布的 Fedora Workstation 34 率先引入 GNOME 40.

Arch 也紧随其后发布了 GNOME 40 相关 package .

Ubuntu 21.04 之前传言是会有 GNOME 40, 但是最后临阵退缩了。不过 Ubuntu 相关的开发人员弄了一个 ppa 可以安装测试（https://www.debugpoint.com/2021/04/gnome-40-ubuntu-21-04/）。

老灯使用 GNOME 40 已经有一段时间了。大部分必备的 extension 都已经升级支持 GNOME 40 了。如果有少量几个必须的不兼容 40 ，但是原作者又没更新怎么办？只能自己动手了。

官方 port guide

GNOME shell 扩展是基于 js 的，解析执行靠 gjs , 事实上 gjs 不只支持写扩展，它完全支持写任何 gtk 应用。流行的电子书阅读器 Foliate 就是基于 js 写的

metadata.json

如果代码层面没有不工作的地方，最简单的 port 就是一句话，修改 metadata.json shell-version 增加 40

{
    "name": "Extension Name",
    "description": "Extension Description",
    "shell-version": ["3.36", "40"],
    "url": "",
    "uuid": "example@example",
    "version": 1
}

检查 GNOME Shell 和 GTK 版本

const Config = imports.misc.config;
const [major] = Config.PACKAGE_VERSION.split('.');
const shellVersion = Number.parseInt(major);

if (shellVersion < 40)
    log('Shell 3.38 or lower');
else
    log('Shell 40 or higher');

const {Gtk} = imports.gi;
const gtkVersion = Gtk.get_major_version();

log(`GTK version is ${gtkVersion}`);

仅在存在时导入命名空间

在GNOME Shell 40 上有一些新命名空间，同时，有一些旧的命名空间已经被删除了。如果想要导入某个可能存在的命名空间时，则可以使用 try and catch block 语法：

try {
    const SearchController = imports.ui.searchController;
} catch(err) {
    log("SearchController doesn't exist");
}

你还可以检查GNOME shell版本，然后导入对应版本的命名空间：

const Config = imports.misc.config;
const [major] = Config.PACKAGE_VERSION.split('.');
const shellVersion = Number.parseInt(major);

const SearchController = (shellVersion >= 40) ? imports.ui.searchController : null;

if (!SearchController) {
    log("SearchController doesn't exist");
}

顶部面板

GNOME 40 从顶部面板中删除了弹出菜单箭头。虽然不推荐，但如果你想添加一个箭头图标，代码仍然存在

ui.popupMenu.arrowIcon() （https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/40e22eb524556e63efa4285c1a9d8f872a507499/js/ui/popupMenu.js#L34）

Overview (概览) Elements

GNOME Shell 40 中的大多数更改都与概览有关。如果您的扩展程序正在使用概览元素执行某些操作，您将需要适应这些更改。

这里有点多，直接贴官方链接吧： https://gjs.guide/extensions/upgrading/gnome-shell-40.html#overview-elements

Prefs 偏好设置

这部分改动应该是最大的。

GNOME Shell 40 现在使用 GTK4 作为扩展首选项。这意味着您需要将 prefs.js UI 升级到 GTK4。

强烈建议使用模板文件 (.ui) 创建 GTK UI。这种结构将后端和前端代码解耦，使您的工作更易于升级和更易于维护。

如果您当前没有使用模板文件，将您当前的 UI 移动到模板文件，然后将其移植到 GTK4 会更容易。如果您不熟悉模板文件，您可以使用 Glade 创建您的模板文件（Glade 不支持 GTK4，但您可以使用 Glade 创建您的文件，然后将它们移植到 GTK4。有关说明，请参阅转换和验证模板文件）。

转换 gtk3 模板到 gtk4: https://gjs.guide/extensions/upgrading/gnome-shell-40.html#convert-and-validate-template-files

To check whether the .ui template file is compatible with GTK4 you can do this:

gtk4-builder-tool validate path_to_ui_file

You can also convert your file to GTK4:

gtk4-builder-tool simplify --3to4 path_to_ui_file

If you want to replace the file with simplified version:

gtk4-builder-tool simplify --3to4 --replace path_to_ui_file

虽然构建器工具simple 可以帮助您将 gtk3 转换为 gtk4，但它无法转换所有内容。您需要手动更改某些部分。

show_all and destroy

在 GTK4 中，默认情况下所有小部件都是可见的（顶层窗口、弹出窗口和对话框除外）。

不再需要在您的小部件中使用 show_all() 和 destroy 信号：

function buildPrefsWidget ()
{
    let widget = new MyPrefsWidget();
    // widget.show_all();
    // widget.connect('destroy', Gtk.main_quit);
    return widget;
}

Provide css file for prefs

GTK4 上没有任何样式属性。您应该改用 css_classes 和 css。例如，如果您正在执行此操作

let label = new Gtk.Label({
    label: 'test',
    style: 'color: gold',
});

You can use the css_classes property:

let label = new Gtk.Label({
    label: 'test',
    css_classes: ['my-label'],
});

Now you need to create a css file (For example, pref.css) for your prefs window:

.my-label {
    color: gold;
}

And load it in your prefs.js file:

const Me = imports.misc.extensionUtils.getCurrentExtension();
const {Gtk, Gdk} = imports.gi;

let provider = new Gtk.CssProvider();

provider.load_from_path(Me.dir.get_path() + '/prefs.css');
Gtk.StyleContext.add_provider_for_display(
    Gdk.Display.get_default(),
    provider,
    Gtk.STYLE_PROVIDER_PRIORITY_APPLICATION);

No Packing

You don't need to use packing anymore. It means instead of:

<object class="GtkBox">
    <property name="visible">True</property>
    <property name="can-focus">False</property>
    <child>
        <placeholder/>
    </child>
</object>
<packing>
    <property name="expand">True</property>
    <property name="fill">True</property>
    <property name="position">0</property>
</packing>

You should use:

<object class="GtkBox">
    <property name="visible">True</property>
    <property name="can-focus">False</property>
    <property name="hexpand">1</property>
    <child>
        <placeholder/>
    </child>
</object>

For horizontal expand use hexpand.
For vertical expand use vexpand.
Don't need to use fill property since it will be true by default.

No margin-left and margin-right property

margin-left and margin-right property has been removed from GTK4.

You should use margin-start and margin-end instead.

关于这个改变，老灯感觉很奇怪。没有觉得 margin-start 会比 margin-left 直观。。。

shadow-type

shadow-type no longer exists in GTK4 for GtkFrame, GtkViewport and GtkScrolledWindow.

Just remove the shadow-type property

draw-value property on GtkScale

On GTK4, draw-value property for GtkScale is False by default. Set draw-value as True if you want to have draw value:

<object class="GtkScale">
    <property name="visible">True</property>
    <property name="can-focus">True</property>
    <property name="adjustment">scale_adjustment</property>
    <property name="round-digits">1</property>
    <property name="draw-value">True</property>
</object>

GtkScale 是什么呢？是一个用于从范围中选择值的滑块小部件（slider widget）。

“draw-value” 属性解释: Whether the current value is displayed as a string next to the slider.

can-focus property

GTK4 与 GTK3 不同的是，在 GTK4 里，当您将对象的 can-focus 属性设置为 False 时，所有后代都无法再聚焦。例如，这里 GtkToggleButton 不能被聚焦，因为 GtkBox 上的 can-focus 属性是 False：

<object class="GtkBox">
    <property name="visible">True</property>
    <property name="can-focus">False</property>
    <property name="hexpand">1</property>
    <child>
        <object class="GtkToggleButton">
            <property name="visible">True</property>
            <property name="can-focus">True</property>
        </object>
    </child>
</object>

要解决这个问题，您需要将 GtkToggleButton 的父元素 GtkBox 的 can-focus 属性设置为 True：

<object class="GtkBox">
    <property name="visible">True</property>
    <property name="can-focus">True</property>
    <property name="hexpand">1</property>
    <child>
        <object class="GtkToggleButton">
            <property name="visible">True</property>
            <property name="can-focus">True</property>
        </object>
    </child>
</object>

这里有非常非常多的改变，如果你需要查看全部的内容，请移步 https://gjs.guide/extensions/upgrading/gnome-shell-40.html#prefs

Refs

https://fedoraproject.org/wiki/Changes/Gnome40

https://blogs.gnome.org/shell-dev/2021/03/20/extensions-rebooted-porting-your-existing-extensions-to-gnome-40/

https://gjs.guide/extensions/upgrading/gnome-shell-40.html

https://developer.gnome.org/gtk4/stable/

https://gjs-docs.gnome.org/gtk40/

https://developer.gnome.org/gtk4/stable/gtk-migrating-3-to-4.html

优化 Hugo 模板里的 og:image meta 标签

ttyS3 — Sat, 26 Jun 2021 03:09:06 GMT

其实我用这个标签，主要是给分享到 twitter 的时候能够让 twitter 自动抓取时生成的 card 带有缩略图。

bookmarklet 也一并分享一下吧：

javascript:(function(){var D=640,A=480,C=screen.height,B=screen.width,H=Math.round((B/2)-(D/2)),G=0,F=document,url,text; if(C>A){G=Math.round((C/2)-(A/2))}; url=encodeURIComponent(window.location); text=encodeURIComponent(window.getSelection?window.getSelection().toString():(document.selection?document.selection.createRange().text:'')); if(text==''){ window.alert('Please, select text on the page first');}else{ window.open('http://twitter.com/share?url='+url+'&text='+text,'','left='+H+',top='+G+',width='+D+',height='+A+',personalbar=0,toolbar=0,scrollbars=1,resizable=1');}}());

模板

关键的 meta 标签主要是 <meta name="twitter:card" content="summary" />， twitter 官网有提供文档： https://developer.twitter.com/en/docs/twitter-for-websites/cards/guides/getting-started#started

og: 开头的几个 meta 是 Open Graph protocol 要求的东西，twitter 能理解它。然后 twitter 会根据 og:image 来自动抓取图片用于 card 显示。

其实也没啥好说的，我写这个文章的原因在于，原来我这个模板的 og:image 一直是不工作的。因为我其实主要是在用 Hugo 的 Page bunlde 来写东西，我认为这是最理想的写作方式，主要是你的文章图片会在文章自己的子目录，不会乱。

原来的模板代码是这样的：

<meta property="og:image" content="{{ .Param "cover" | absURL }}">

我改进之后，一个是修复了对于 Page bundle 的兼容性问题，另一个是，如果没有取到 cover 图，就自动取文章里的第一张图片。相关代码如下：


<!-- Twitter Card -->
<meta name="twitter:card" content="summary" />
{{ with $.Site.Params.Twitter.site }}
  <meta name="twitter:site" content="{{ $.Site.Params.Twitter.site }}" />
{{ end }}
{{ with $.Site.Params.Twitter.creator }}
  <meta name="twitter:creator" content="{{ if .IsHome }}{{ $.Site.Params.Twitter.creator }}{{ else if isset .Params "authortwitter" }}{{ .Params.authorTwitter }}{{ else }}{{ .Params.Author }}{{ end }}" />
{{ end }}
<!-- OG data -->
<!-- <meta property="og:locale" content="{{ $.Site.Language.Lang }}" /> -->
<meta property="og:type" content="{{ if .IsPage }}article{{ else }}website{{ end }}" />
<meta property="og:title" content="{{ if .IsHome }}{{ $.Site.Title }}{{ else }}{{ .Title }} :: {{ $.Site.Title }}{{ end }}">
<meta property="og:description" content="{{ if .IsHome }}{{ $.Site.Params.Subtitle }}{{ else if .Description}}{{ .Description | plainify }}{{ else }}{{ .Summary | plainify }}{{ end }}" />
<meta property="og:url" content="{{ .Permalink }}" />
<meta property="og:site_name" content="{{ $.Site.Title }}" />
{{ if not .IsHome }}

  {{ if isset .Params "cover" }}
      <!-- be aware that in this context, .RelPermalink is $.Page.RelPermalink -->
      {{ printf "<!-- .ResourceType=%#v .File.LogicalName=%#v .RelPermalink=%#v .Permalink=%#v .Params.cover=%#v -->" .ResourceType $.Page.File.LogicalName .RelPermalink .Permalink .Params.cover | safeHTML }}
      {{ if eq "index.md" $.Page.File.LogicalName }}
        <meta property="og:image" content="{{ printf "%s%s" .Permalink .Params.cover }}">
      {{ else }}
        <meta property="og:image" content="{{ .Param "cover" | absURL }}">
      {{ end }}
  {{ else }}
      <!-- get first image as featured image in post if no cover is set -->
      {{ with (index (.Resources.ByType "image") 0) }}
        <!-- be aware that in this context, .RelPermalink is resource.RelPermalink -->
        {{ printf "<!-- .ResourceType=%#v .File.LogicalName=%#v .Resources.ByType image .RelPermalink=%#v .Permalink=%#v -->" .ResourceType $.Page.File.LogicalName  .RelPermalink .Permalink | safeHTML }}
        <meta property="og:image" content="{{ .Permalink }}">
      {{ end }}
  {{ end }} 

{{ else }}

  {{ if isset $.Site.Params "favicon" }}
    <meta property="og:image" content="{{ $.Site.Params.favicon | absURL }}">
  {{ else }}
    <meta property="og:image" content="{{ printf "img/favicon/%s.png" $.Site.Params.ThemeColor | absURL }}">
  {{ end }}

{{ end }}
<meta property="og:image:width" content="2048">
<meta property="og:image:height" content="1024">

Refs

https://developer.twitter.com/en/docs/twitter-for-websites/cards/guides/getting-started#started

https://ogp.me/#metadata

https://blog.hubspot.com/marketing/open-graph-tags-facebook-twitter-linkedin

https://neilpatel.com/blog/open-graph-meta-tags/

rsproxy.cn - 字节跳动新的 Rust 镜像源

ttyS3 — Fri, 25 Jun 2021 13:58:13 GMT

刚从 Rust.cc 日报看到的。欢呼ing!

Crate.io Mirror

~/.cargo/config:

[source.crates-io]
replace-with = 'rsproxy'

[source.rsproxy]
registry = "https://rsproxy.cn/crates.io-index"

Rustup Mirror

~/.zshrc or ~/.bashrc:

export RUSTUP_DIST_SERVER="https://rsproxy.cn"
export RUSTUP_UPDATE_ROOT="https://rsproxy.cn/rustup"

官网： https://rsproxy.cn/

paru 不会在内核更新之后自动重建包含内核模块的包

ttyS3 — Sun, 20 Jun 2021 11:30:00 GMT

paru 和 yay 一样，是一个 aur helper.

最近用 paru 安装一个叫 ipt_ndpi 的包，里面包含了 iptables 扩展和内核模块。

当前内核是从 5.12.10 升级到 5.12.11 的：

❯ uname -a
Linux wudeng 5.12.11-arch1-1 #1 SMP PREEMPT Wed, 16 Jun 2021 15:25:28 +0000 x86_64 GNU/Linux

❯ paru -V
paru v1.7.2 +git - libalpm v13.0.0

尝试重新安装：

🔴 1 ❯ paru -S ipt_ndpi
:: Resolving dependencies...
:: Calculating conflicts...
:: Calculating inner conflicts...

Aur (1) ipt_ndpi-1.2_3.2.0.2224.8a19d7e3-1

:: Proceed to review? [Y/n]: y

:: Downloading PKGBUILDs...
 PKGBUILDs up to date
:: Proceed with installation? [Y/n]: y
fetching devel info...
==> Making package: ipt_ndpi 1.2_3.5.0.3243.640643d9-1 (Fri 18 Jun 2021 11:27:46 PM CST)
==> Retrieving sources...
  -> Updating ipt_ndpi git repo...
Fetching origin
==> Validating source files with sha256sums...
    ipt_ndpi ... Skipped
==> Making package: ipt_ndpi 1.2_3.5.0.3243.640643d9-1 (Fri 18 Jun 2021 11:27:50 PM CST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Updating ipt_ndpi git repo...
Fetching origin
==> Validating source files with sha256sums...
    ipt_ndpi ... Skipped
==> Removing existing $srcdir/ directory...
==> Extracting sources...
  -> Creating working copy of ipt_ndpi git repo...
Cloning into 'ipt_ndpi'...
done.
==> Starting prepare()...
Already on 'flow_info-3.2'
Your branch is up to date with 'origin/flow_info-3.2'.
autoreconf: export WARNINGS=
autoreconf: Entering directory '.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
autoreconf: configure.ac: not using Intltool
autoreconf: configure.ac: not using Gtkdoc
autoreconf: running: aclocal --force -I m4
autoreconf: running: /usr/bin/autoconf --force
configure.ac:41: warning: The macro `AC_PROG_CC_STDC' is obsolete.
configure.ac:41: You should run autoupdate.
./lib/autoconf/c.m4:1666: AC_PROG_CC_STDC is expanded from...
configure.ac:41: the top level
configure.ac:46: warning: The macro `AC_PROG_CC_STDC' is obsolete.
configure.ac:46: You should run autoupdate.
./lib/autoconf/c.m4:1666: AC_PROG_CC_STDC is expanded from...
configure.ac:46: the top level
configure.ac:49: warning: $as_echo is obsolete; use AS_ECHO(["message"]) instead
lib/m4sugar/m4sh.m4:692: _AS_IF_ELSE is expanded from...
lib/m4sugar/m4sh.m4:699: AS_IF is expanded from...
./lib/autoconf/general.m4:2249: AC_CACHE_VAL is expanded from...
./lib/autoconf/general.m4:2270: AC_CACHE_CHECK is expanded from...
m4/ax_pthread.m4:88: AX_PTHREAD is expanded from...
configure.ac:49: the top level
configure.ac:232: warning: The macro `AC_HAVE_HEADERS' is obsolete.
configure.ac:232: You should run autoupdate.
./lib/autoconf/oldnames.m4:35: AC_HAVE_HEADERS is expanded from...
configure.ac:232: the top level
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:34: installing './compile'
configure.ac:34: installing './config.guess'
configure.ac:34: installing './config.sub'
configure.ac:6: installing './install-sh'
configure.ac:6: installing './missing'
fuzz/Makefile.am: installing './depcomp'
parallel-tests: installing './test-driver'
autoreconf: './config.sub' is updated
autoreconf: './config.guess' is updated
autoreconf: Leaving directory '.'
./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking how to print strings... printf
checking whether make supports the include directive... yes (GNU style)
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-pc-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /usr/bin/dd
checking how to truncate binary pipes... /usr/bin/dd bs=4096 count=1
checking for mt... no
checking if : is a manifest tool... no
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for g++... g++
checking whether the compiler supports GNU C++... yes
checking whether g++ accepts -g... yes
checking for g++ option to enable C++11 features... none needed
checking dependency style of g++... gcc3
checking how to run the C preprocessor... gcc -E
checking whether gcc is Clang... no
checking whether pthreads work with -pthread... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking whether more special flags are required for pthreads... no
checking for PTHREAD_PRIO_INHERIT... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for JSONC... yes
checking for netinet/in.h... yes
checking for stdint.h... (cached) yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for unistd.h... (cached) yes
checking for json.h... yes
checking DPDK (used by ndpiReader)... no (missing /home/ttys3/DPDK)
checking for numa_available in -lnuma... yes
checking for pcap_open_live in -lpcap... yes
checking for pthread_setaffinity_np in -lpthread... yes
checking for gcry_cipher_checktag in -lgcrypt... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating example/Makefile
config.status: creating example/Makefile.dpdk
config.status: creating tests/Makefile
config.status: creating tests/unit/Makefile
config.status: creating tests/dga/Makefile
config.status: creating libndpi.pc
config.status: creating src/include/ndpi_define.h
config.status: creating src/lib/Makefile
config.status: creating python/Makefile
config.status: creating fuzz/Makefile
config.status: creating src/include/ndpi_api.h
config.status: creating tests/do.sh
config.status: creating tests/do_valgrind.sh
config.status: creating src/include/ndpi_config.h
config.status: executing depfiles commands
config.status: executing libtool commands
depbase=`echo ndpi_network_list_compile.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
gcc -DHAVE_CONFIG_H -I. -I../../src/include  -I../../src/include/  -I../../src/lib/third_party/include/   -g -O2 -I/usr/include/json-c  -fPIC -DPIC -DNDPI_LIB_COMPILATION  -MT ndpi_network_list_compile.o -MD -MP -MF $depbase.Tpo -c -o ndpi_network_list_compile.o ndpi_network_list_compile.c &&\
mv -f $depbase.Tpo $depbase.Po
/bin/sh ../../libtool  --tag=CC   --mode=link gcc  -g -O2 -I/usr/include/json-c  -fPIC -DPIC -DNDPI_LIB_COMPILATION    -o ndpi_network_list_compile ndpi_network_list_compile.o  -lgcrypt  -ljson-c
libtool: link: gcc -g -O2 -I/usr/include/json-c -fPIC -DPIC -DNDPI_LIB_COMPILATION -o ndpi_network_list_compile ndpi_network_list_compile.o  -lgcrypt -ljson-c
./ndpi_network_list_compile -o ndpi_network_list.c.inc ndpi_network_list_amazon.yaml ndpi_network_list_std.yaml ndpi_network_list_tor.yaml ndpi_network_list_whatsapp.yaml
Warning: line  814: '209.148.214.135/21' is not network (NETFLIX)
==> Starting pkgver()...
gawk: cmd. line:1: warning: regexp escape sequence `\"' is not a known regexp operator
gawk: cmd. line:1: warning: regexp escape sequence `\"' is not a known regexp operator
==> Sources are ready.
ipt_ndpi-1.2_3.2.0.2224.8a19d7e3-1: parsing pkg list...
:: ipt_ndpi-1.2_3.2.0.2224.8a19d7e3-1 is up to date -- skipping build
loading packages...
warning: ipt_ndpi-1.2_3.5.0.3243.640643d9-1 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...

Package (1)  Old Version                New Version                Net Change

ipt_ndpi     1.2_3.5.0.3243.640643d9-1  1.2_3.5.0.3243.640643d9-1    0.00 MiB

Total Installed Size:  3.18 MiB
Net Upgrade Size:      0.00 MiB

:: Proceed with installation? [Y/n]
(1/1) checking keys in keyring                                  [###################################] 100%
(1/1) checking package integrity                                [###################################] 100%
(1/1) loading package files                                     [###################################] 100%
(1/1) checking for file conflicts                               [###################################] 100%
(1/1) checking available disk space                             [###################################] 100%
warning: could not get file information for usr/lib/modules/5.12.10-arch1-1/
warning: could not get file information for usr/lib/modules/5.12.10-arch1-1/extra/
warning: could not get file information for usr/lib/modules/5.12.10-arch1-1/extra/xt_ndpi.ko.gz
:: Processing package changes...
(1/1) reinstalling ipt_ndpi                                     [###################################] 100%
:: Running post-transaction hooks...
(1/3) Arming ConditionNeedsUpdate...
(2/3) Updating module dependencies...
(3/3) Refreshing PackageKit...
  ~ took 26s

可以发现包还是被安装到了旧内核目录： 5.12.10-arch1-1

  /usr/lib/modules 
❯ ll
drwxr-xr-x root root 4.0 KB Fri Jun 18 23:28:01 2021  5.12.10-arch1-1
drwxr-xr-x root root 4.0 KB Fri Jun 18 02:12:44 2021  5.12.11-arch1-1


  /usr/lib/modules 
❯ tree 5.12.10-arch1-1
5.12.10-arch1-1
└── extra
    └── xt_ndpi.ko.gz

1 directory, 1 file

❯ tree -L 1 5.12.11-arch1-1
5.12.11-arch1-1
├── build
├── extramodules
├── kernel
├── modules.alias
├── modules.alias.bin
├── modules.builtin
├── modules.builtin.alias.bin
├── modules.builtin.bin
├── modules.builtin.modinfo
├── modules.dep
├── modules.dep.bin
├── modules.devname
├── modules.order
├── modules.softdep
├── modules.symbols
├── modules.symbols.bin
├── pkgbase
└── vmlinuz

3 directories, 15 files

然后我仔细观察了下 paru 输出的信息，里面有关键的：

:: ipt_ndpi-1.2_3.2.0.2224.8a19d7e3-1 is up to date -- skipping build
loading packages...
warning: ipt_ndpi-1.2_3.5.0.3243.640643d9-1 is up to date -- reinstalling

然后我仔细观察了下这个 PKGBUILD:

# Maintainer: Shalygin Konstantin <[email protected]>
# Contributor: Shalygin Konstantin <[email protected]>

pkgname='ipt_ndpi'
pkgver=1.2_3.2.0.2224.8a19d7e3
pkgrel=1
pkgdesc='nDPI as netfilter extension.'
arch=('any')
url='https://github.com/vel21ripn/nDPI'
license=('GPL')
depends=('iptables')
makedepends=('git')
source=("${pkgname}::git+${url}")
sha256sums=('SKIP')
# define '-lts' for linux-lts package
_linux_custom=""
_kernver="`pacman -Ql linux${_linux_custom} | awk '/(\/modules\/)([0-9.-])+-(.*)'${_linux_custom}'\/$/ {print $2}' | head -n1`"

pkgver() {
  cd "${srcdir}/${pkgname}"
  ndpi_version=`gawk 'match($0, /pr_info\("xt_ndpi\sv([0-9.]+)\sndpi\s%s\"$/, a) {print a[1]}' ndpi-netfilter/src/main.c`
  git_version=`gawk 'match($0, /^(#define)\s(NDPI_GIT_RELEASE)\s(\")([a-z0-9.-]+)(\")$/, a) {print a[4]}' src/include/ndpi_config.h | sed -e 's/-/./g'`
  echo -e "${ndpi_version}_${git_version}"
}

prepare() {
  cd "${srcdir}/${pkgname}"
  git checkout flow_info-3.2
  ./autogen.sh
  cd "src/lib"
  make ndpi_network_list.c.inc
}

build() {
  cd "${srcdir}/${pkgname}/ndpi-netfilter"
  make KERNEL_DIR="${_kernver}build"
}

check() {
  cd "${srcdir}/${pkgname}/ndpi-netfilter"
  gzip --best -c "src/xt_ndpi.ko" > "src/xt_ndpi.ko.gz"
}

package() {
  cd "${srcdir}/${pkgname}/ndpi-netfilter"
  install -Dm755 "ipt/libxt_ndpi.so" "${pkgdir}/usr/lib/xtables/libxt_ndpi.so"
  install -Dm644 "src/xt_ndpi.ko.gz" "${pkgdir}${_kernver}/extra/xt_ndpi.ko.gz"
  install -Dm644 "INSTALL" "${pkgdir}/usr/share/doc/${pkgname}/README"
}

原因出来了，这里面有：

_kernver="`pacman -Ql linux${_linux_custom} | awk '/(\/modules\/)([0-9.-])+-(.*)'${_linux_custom}'\/$/ {print $2}' | head -n1`"

install -Dm644 "src/xt_ndpi.ko.gz" "${pkgdir}${_kernver}/extra/xt_ndpi.ko.gz"

因此，在当时包构建的时候，它会取当前内核版本号，然后把 xt_ndpi.ko.gz install 到相应的目录，由于 paru 并没有重建包，因此导致在新内核上安装到了错误的位置。

因此 rebuild 就可以解决问题。

paru -S --rebuild ipt_ndpi

有没有办法从程序上检测这种变动呢？我觉得完全是可以的。简单地 list 一下这个包里面的内容，如果找到了位于 usr/lib/modules/ 下的文件，则说明这个包是有包含内核模块的，从目录名 5.12.11-arch1-1 里我们完全可以提取出内核版本是 5.12.11，然后再与当前运行的内核版本匹配，如果不匹配，则 paru 可以自动重建包。

🔴 2 ❯ tar -tvlf ipt_ndpi-1.2_3.5.0.3243.640643d9-1-any.pkg.tar.zst
-rw-r--r-- root/root     45891 2021-06-18 23:39 .BUILDINFO
-rw-r--r-- root/root       587 2021-06-18 23:39 .MTREE
-rw-r--r-- root/root       339 2021-06-18 23:39 .PKGINFO
drwxr-xr-x root/root         0 2021-06-18 23:39 usr/
drwxr-xr-x root/root         0 2021-06-18 23:39 usr/lib/
drwxr-xr-x root/root         0 2021-06-18 23:39 usr/lib/modules/
drwxr-xr-x root/root         0 2021-06-18 23:39 usr/lib/modules/5.12.11-arch1-1/
drwxr-xr-x root/root         0 2021-06-18 23:39 usr/lib/modules/5.12.11-arch1-1/extra/
-rw-r--r-- root/root   3289358 2021-06-18 23:39 usr/lib/modules/5.12.11-arch1-1/extra/xt_ndpi.ko.gz
drwxr-xr-x root/root         0 2021-06-18 23:39 usr/lib/xtables/
-rwxr-xr-x root/root     31408 2021-06-18 23:39 usr/lib/xtables/libxt_ndpi.so
drwxr-xr-x root/root         0 2021-06-18 23:39 usr/share/
drwxr-xr-x root/root         0 2021-06-18 23:39 usr/share/doc/
drwxr-xr-x root/root         0 2021-06-18 23:39 usr/share/doc/ipt_ndpi/
-rw-r--r-- root/root      9812 2021-06-18 23:39 usr/share/doc/ipt_ndpi/README

把这个解决方案向 paru 作者反馈了，作者直接拒绝了。

可能作者觉得这不是 paru 要处理的问题，而是使用者应该处理的问题吧？

但是，人的记忆是不如电脑的，很多事情是容易忘记的。如果 paru 能自动识别需要重建不是更好？

虽然这个功能有点像“白名单”，针对内核版本号检测了，那我是不是针对其它 lib 的版本号兼容性也要进行检测？我觉得不尽然，能处理内核版本号的问题，不是更好？为什么支持内核检测了就一定要支持其它lib?没有哪有这个规定啊。

所以，说白了就是，这个想法，跟作者的理念是不符合的。

开源的东西，很多时候都是这样吧。是作者意愿的一种表达。这就是为什么开源容易出现很多 fork, 因为，一言不合就 fork啊，你不愿意添加，那就我自己来干喽。

当然，我目前还没有闲到这种自己去维护另一个版本的 paru 的地步。因此，先这么着吧。说不定哪天有空了，我真的 fork 了。

Hugo 0.84.0 Now Support Deep Merge of Theme Params

ttyS3 — Sun, 20 Jun 2021 11:08:46 GMT

功能介绍

对于主题的 params 配置，之前版本的 Hugo 只支持浅合并（shallow merge），举例来说：假设主题有一个配置

[params]
[params.colours]
blue="#337DFF"
green="#68FF33"
red="#FF3358"

如果是之前版本的 Hugo, 你要调整其中一个配置，比如 red 的颜色，你需要 copy 整个 colours 配置，然后把 red 修改成你想要的值。

现在你可以在站点配置里这样简单地进行覆盖：

[params]
[params.colours]
red="#fc0f03"

默认合并策略

参考文档 https://gohugo.io/getting-started/configuration/#merge-configuration-from-themes

现在 _merge 的值可以是以下三种之一：

none 不合并
shallow 浅copy合并 Only add values for new keys.
deep 深度合并 Add values for new keys, merge existing.

当前的默认配置是：

build:
  _merge: none
caches:
  _merge: none
frontmatter:
  _merge: none
imaging:
  _merge: none
languages:
  _merge: none
  en:
    _merge: none
    menus:
      _merge: shallow
    params:
      _merge: deep
markup:
  _merge: none
mediatypes:
  _merge: shallow
menus:
  _merge: shallow
minify:
  _merge: none
module:
  _merge: none
outputformats:
  _merge: shallow
params:
  _merge: deep
permalinks:
  _merge: none
related:
  _merge: none
sitemap:
  _merge: none
taxonomies:
  _merge: none

其它重要改变

Themes now support the config directory

Now both the project and themes/modules can store its configuration in both the top level config file (e.g. config.toml) or in the config directory. See Configuration Directory.

HTTP headers in getJSON/getCSV

getJSON now supports custom HTTP headers. This has been a big limitation in Hugo, especially considering the Authorization header.

We have updated the internal Instagram shortcode to pass the access token in a header:

{{ $hideCaption := cond (eq (.Get 1) "hidecaption") "1" "0" }}
{{ $headers := dict "Authorization" (printf "Bearer %s" $accessToken) }}
{{ with getJSON "https://graph.facebook.com/v8.0/instagram_oembed/?url=https://instagram.com/p/" $id "/&hidecaption=" $hideCaption $headers }}
    {{ .html | safeHTML }}
{{ end }}

Also see the discussion this issue about the access token above.

New erroridf template func

Sometime, especially when creating themes, it is useful to be able to let the user decide if an error situation is critical enough to fail the build. The new erroridf produces ERROR log statements that can be toggled off:

{{ erroridf "some-custom-id" "Some error message." }}

Will log:

ERROR: Some error message.
If you feel that this should not be logged as an ERROR, you can ignore it by adding this to your site config:
ignoreErrors = ["some-custom-id"]

Refs

https://gohugo.io/news/0.84.0-relnotes/#deep-merge-of-theme-params

https://github.com/gohugoio/hugo/releases/tag/v0.84.0

Fuck 80 Chars Limit -- It is 2021 now

ttyS3 — Sun, 06 Jun 2021 16:27:35 GMT

关于限制代码最大列宽：

限制在 80 个字符合适吗？

我的观点是：都 TM 2021 年了， 80个锤子，直接来个 150 或 160 还差不多。

Linus 的观点貌似跟我一样哈？

In case of the Linux kernel, that’s of course Linus Torvalds, who has recently shaken up the community with a mailing list response declaring an overly common, often even unwritten rule of code formatting as essentially obsolete: the 80-character line limitation. Considering the notoriety of his rants and crudeness, his response, which was initiated by a line break change in the submitted patch, seems downright diplomatic this time.
Linus’ reasoning against a continuing enforcement of 80-char line limits is primarly the fact that screens are simply big enough today to comfortably fit longer lines, even with multiple terminals (or windows) next to each other. As he puts it, the only reason to stick to the limitation is using an actual VT100, which won’t serve much use in kernel development anyway.

via https://hackaday.com/2020/06/18/ask-hackaday-are-80-characters-per-line-still-reasonable-in-2020/

https://lkml.org/lkml/2020/5/28/1237

From	Linus Torvalds <>
Date	Thu, 28 May 2020 11:43:13 -0700
Subject	Re: [PATCH 09/14] fs: don't change the address limit for ->write_iter in __kernel_write
share 0
On Wed, May 27, 2020 at 10:41 PM Christoph Hellwig <hch@lst.de> wrote:
>
> -ssize_t __kernel_write(struct file *file, const void *buf, size_t count, loff_t *pos)
> +ssize_t __kernel_write(struct file *file, const void *buf, size_t count,
> +               loff_t *pos)

Please don't do these kinds of pointless whitespace changes.

If you have an actual 80x25 vt100 sitting in a corner, it's not really
conducive to kernel development any more.

Yes, yes, we'd like to have shorter lines for new code, but no, don't
do silly line breaks that just makes old code look and grep worse.

             Linus

https://lkml.org/lkml/2020/5/29/1038

From	Linus Torvalds <>
Date	Fri, 29 May 2020 12:19:02 -0700
Subject	Re: clean up kernel_{read,write} & friends v2
share 4k
On Fri, May 29, 2020 at 6:08 AM David Laight <David.Laight@aculab.com> wrote:
>
> A wide monitor is for looking at lots of files.

Not necessarily.
Excessive line breaks are BAD. They cause real and every-day problems.
They cause problems for things like "grep" both in the patterns and in the output, since grep (and a lot of other very basic unix utilities) is fundamentally line-based.
So the fact is, many of us have long long since skipped the whole "80-column terminal" model, for the same reason that we have many more lines than 25 lines visible at a time.
And honestly, I don't want to see patches that make the kernel reading experience worse for me and likely for the vast majority of people, based on the argument that some odd people have small terminal windows.
If you or Christoph have 80 character lines, you'll get possibly ugly wrapped output. Tough. That's your choice. Your hardware limitations shouldn't be a pain for the rest of us.
Longer lines are fundamentally useful. My monitor is not only a lot wider than it is tall, my fonts are universally narrower than they are tall. Long lines are natural.
When I tile my terminal windows on my display, I can have 6 terminals visible at one time, and that's because I have them three wide. And I could still fit 80% of a fourth one side-by-side.
And guess what? That's with my default "100x50" terminal window (go to your gnome terminal settings, you'll find that the 80x25 thing is just an initial default that you can change), not with some 80x25 one. And that's with a font that has anti-aliasing and isn't some pixelated mess.
And most of my terminals actually end up being dragged wider and taller than that. I checked, and my main one is 142x76 characters right now, because it turns out that wider (and taller) terminals are useful not just for source code.
Have you looked at "ps ax" output lately? Or used "top"? Or done "git diff --stat" or any number of things where it turns out that 80x25 is really really limiting, and is simply NO LONGER RELEVANT to most of us.
So no. I do not care about somebody with a 80x25 terminal window getting line wrapping.
For exactly the same reason I find it completely irrelevant if somebody says that their kernel compile takes 10 hours because they are doing kernel development on a Raspberry PI with 4GB of RAM.
People with restrictive hardware shouldn't make it more inconvenient for people who have better resources. Yes, we'll accommodate things to within reasonable limits. But no, 80-column terminals in 2020 isn't "reasonable" any more as far as I'm concerned. People commonly used 132-column terminals even back in the 80's, for chrissake, don't try to make 80 columns some immovable standard.
If you choose to use a 80-column terminal, you can live with the line wrapping. It's just that simple.
And longer lines are simply useful. Part of that is that we aren't programming in the 80's any more, and our source code is fundamentally wider as a result.
Yes, local iteration variables are still called 'i', because more context just isn't helpful for some anonymous counter. Being concise is still a good thing, and overly verbose names are not inherently better.
But still - it's entirely reasonable to have variable names that are 10-15 characters and it makes the code more legible. Writing things out instead of using abbreviations etc.
And yes, we do use wide tabs, because that makes indentation something you can visually see in the structure at a glance and on a whole-function basis, rather than something you have to try to visually "line up" things for or count spaces.
So we have lots of fairly fundamental issues that fairly easily make for longer lines in many circumstances.
And yes, we do line breaks at some point. But there really isn't any reason to make that point be 80 columns any more.

------------ Linus

staticcheck -- golangci-lint 中最令人困惑的一个 linter

ttyS3 — Sun, 06 Jun 2021 16:00:33 GMT

如果你不想看过程，那就直接跳到最后看一句话总结吧。

megacheck

megacheck 其实是一个 deprecated linter, 不过只是被原作者deprecated, 目前 golangci-lint 并没有 deprecated 它。原因主要是向后兼容性（see https://github.com/golangci/golangci-lint/issues/357 ）。

这可能是最令人费解的一个linter了，为什么呢？我这里简单总结一下：

megacheck 是 https://github.com/dominikh/go-tools 早期代码里的一个linter, 它包含了3个linter: gosimple staticcheck unused 而 go-tools 的 go module 名称为： honnef.co/go/tools，没错，并不是 github.com/dominikh/go-tools 到这里还没结束，嗯。新版本的go-tools 代码里已经没有 megacheck 这个 linter了。新版本取了一个新名字叫 Staticcheck , 自称 "The advanced Go linter", 自我描述为 "The best static analysis for Go that money can't buy" 代码仓库地址保持不变，还在 https://github.com/dominikh/go-tools 不单有自己的官网，而且把它所有的检测文档化了, 访问 https://staticcheck.io/docs/checks 可以查看所有检测.

早期的 go-tools (也就是现在的 staticcheck) 其实是包含一系列linter的， gosimple staticcheck unused 其中 staticcheck 里面包含了 stylecheck`.

而新版本的 staticcheck (这里指的是 cmd, 不是staticcheck package "honnef.co/go/tools/staticcheck")

包含了4种linter:

gosimple  "honnef.co/go/tools/simple"
staticcheck "honnef.co/go/tools/staticcheck"
stylecheck "honnef.co/go/tools/stylecheck"
unused "honnef.co/go/tools/unused"

see https://github.com/dominikh/go-tools/blob/master/cmd/staticcheck/staticcheck.go

而当前版本的 golangci-lint （现在最新是 v1.40.1 ) 里的 staticcheck 实际上指的是 "honnef.co/go/tools/staticcheck"，并不是指 https://github.com/dominikh/go-tools/blob/master/cmd/staticcheck/staticcheck.go

https://github.com/golangci/golangci-lint/issues/357 说的 staticcheck 是指 cmd/staticcheck，也就是真正的四合一版的 staticcheck

但是由于当前旧版本的 staticcheck 是在 golangci-lint 的 "Enabled By Default Linters" 里，基于 semver, 这个提议只能放在 v2.0.0 版的 golangci-lint, see https://github.com/golangci/golangci-lint/issues/357#issuecomment-841850534

staticcheck is up-to-date in golangci-lint, and we update the dependency automatically via dependabot.

The issue is still opened because the merge of the 4 linters is breaking, so it will be done in the next major version (v2).

再回到 staticcheck，为什么仓库名这么奇怪，还是叫 go-tools 呢？一来，可能是由于历史原因，作者保留了仓库名称没有变。二来，其实 go-tools 下确实不只 staticcheck 这个 linter, 还有另一个小工具 keyify 和 structlayout 三兄弟

注意， golangci-lint 虽然 fork 并保留了 go-tools 早期的代码，但是现在最新发布的 golangci-lint 其实是直接引用了最新的 go-tools 包代码.

如果我们将配置设置为禁用所有linter(主要是默认启用的那些), 再执行 golangci-lint run -v：

[linters]
disable-all = true
enable = [
    "megacheck",
]

会发现如下提示：

INFO [lintersdb] Active 3 linters: [gosimple staticcheck unused]

我们看看 golangci-lint 的代码就明白为什么启用 megacheck 后会提示我们启用了3个 linter:

// file: pkg/lint/lintersdb/manager.go

// https://github.com/golangci/golangci-lint/blob/fe0db3db215535884342b3b884ec0e637314921d/pkg/lint/lintersdb/manager.go#L144
const megacheckName = "megacheck"

// https://github.com/golangci/golangci-lint/blob/fe0db3db215535884342b3b884ec0e637314921d/pkg/lint/lintersdb/manager.go#L180

linter.NewConfig(golinters.NewStaticcheck(staticcheckCfg)).
	WithSince("v1.0.0").
	WithLoadForGoAnalysis().
	WithPresets(linter.PresetBugs, linter.PresetMetaLinter).
	WithAlternativeNames(megacheckName).
	WithURL("https://staticcheck.io/"),
linter.NewConfig(golinters.NewUnused(unusedCfg)).
	WithSince("v1.20.0").
	WithLoadForGoAnalysis().
	WithPresets(linter.PresetUnused).
	WithAlternativeNames(megacheckName).
	ConsiderSlow().
	WithChangeTypes().
	WithURL("https://github.com/dominikh/go-tools/tree/master/unused"),
linter.NewConfig(golinters.NewGosimple(gosimpleCfg)).
	WithSince("v1.20.0").
	WithLoadForGoAnalysis().
	WithPresets(linter.PresetStyle).
	WithAlternativeNames(megacheckName).
	WithURL("https://github.com/dominikh/go-tools/tree/master/simple"),

staticcheck

当然，如果你想安装原汁原味的 staticcheck, 也不是不可以：

go install honnef.co/go/tools/cmd/staticcheck@latest

staticcheck -list-checks 可以列出它当前支持的所有检测

当前最新稳定版为 v0.2.0

STATICCHECK 2021.1 RELEASE NOTES https://staticcheck.io/changes/2021.1

新增加了啥和改了啥，我这里就不说了，大家自己看文档，我挑两个个人比较关注的说一下：

Better integration with gopls

Several behind the scenes changes prepare this release for better integration with gopls. This will include more accurate severities for diagnostics as well as numerous new refactorings. These improvements will be part of a future gopls release.

https://github.com/golang/tools/blob/master/gopls/doc/settings.md#staticcheck-bool

Deletion of rdeps

The rdeps tool has been deleted. This was a GOPATH-centric tool that allowed finding all reverse dependencies of a Go package. Both the move to Go modules as well as the emergence of much better tooling for inspecting dependencies (such as goda) has made rdeps redundant.

不得不说一下，作者这里推荐的 goda 也是个好东西。配合 dot (来自Linux graphviz包) 可以画出漂亮的mod依赖图来:

git clone https://github.com/loov/goda && cd goda
goda graph github.com/loov/goda/... | dot -Tsvg -o graph.svg

我们看看 https://github.com/golangci/go-tools/blob/master/cmd/megacheck/megacheck.go 其导入的关键package为：

	"github.com/golangci/go-tools/simple"
	"github.com/golangci/go-tools/staticcheck"
	"github.com/golangci/go-tools/unused"

https://github.com/golangci/go-tools/blob/master/cmd/staticcheck/staticcheck.go 导入的

	"github.com/golangci/go-tools/simple"
	"github.com/golangci/go-tools/staticcheck"
	"github.com/golangci/go-tools/stylecheck"
	"github.com/golangci/go-tools/unused"

然后我们继续看 https://github.com/golangci/go-tools/tree/master/cmd 就发现，早期的go-tools(也就是现在的staticcheck) 其实包含一系列的linter:

errcheck-ng - errcheck-ng is the next generation of errcheck.
gosimple
keyify
megacheck
rdeps
staticcheck
structlayout-optimize
structlayout-pretty
structlayout
unused

在 golangci-lint 当前版本 (v1.40.1)里， megacheck = [gosimple staticcheck unused]

staticcheck 就只有 staticcheck

我们看看新版本的: https://github.com/dominikh/go-tools/tree/master/cmd 只剩下

keyify
staticcheck
structlayout-optimize
structlayout-pretty
structlayout

Keyify turns unkeyed struct literals (T{1, 2, 3}) into keyed ones (T{A: 1, B: 2, C: 3})

rdeps scans GOPATH for all reverse dependencies of a set of Go packages.

staticcheck offers extensive analysis of Go code, covering a myriad of categories. It will detect bugs, suggest code simplifications, point out dead code, and more.

由于 go module 的引入，已经不存在全局唯一的 GOPATH 了，因此 rdeps 也在最近被作者移除

cmd/rdeps: delete rdeps The move to Go modules has greatly diminished the usefulness of the rdeps tool, as there is no longer a universe of packages (GOPATH) to inspect, and because we've never updated the tool to work with modules in the first place.

On top of that, a much more powerful tool – goda – has emerged, which allows for far more advanced queries on dependency graphs in the scope of a module.

https://github.com/dominikh/go-tools/blob/master/cmd/structlayout/README.md

The structlayout utility prints the layout of a struct – that is the byte offset and size of each field, respecting alignment/padding.

The information is printed in human-readable form by default, but can be emitted as JSON with the -json flag. This makes it easy to consume this information in other tools.

A utility called structlayout-pretty takes this JSON and prints an ASCII graphic representing the memory layout.

structlayout-optimize is another tool. Inspired by maligned, it reads structlayout JSON on stdin and reorders fields to minimize the amount of padding. The tool can itself emit JSON and feed into e.g. structlayout-pretty.

structlayout-svg is a third-party tool that, similarly to structlayout-pretty, visualises struct layouts. It does so by generating a fancy-looking SVG graphic. You can install it via

go get github.com/ajstarks/svgo/structlayout-svg

那么，为什么我们默认没有启用 stylecheck 呢？因为这个 linter 实在是太难过了，尤其是对于历史悠久的代码。我这里随便跑一个开了 stylecheck 的，列举一些例子哈：

ST1003: var theSql should be theSQL (stylecheck)
ST1003: struct field UserId should be UserID (stylecheck)
ST1003: struct field HttpServer should be HTTPServer (stylecheck)
ST1003: struct field BaseUserApi should be BaseUserAPI (stylecheck)
ST1003: var searchDb should be searchDB (stylecheck)
ST1003: var infoJson should be infoJSON (stylecheck)
ST1003: method parameter userId should be userID (stylecheck)
ST1003: method parameter reqUid should be reqUID (stylecheck)
ST1003: should not use ALL_CAPS in Go names; use CamelCase instead (stylecheck) // const PROM_SUBSYSTEM = "user_search_updater"

但是，如果我们直接运行 staticcheck ./... 却不会有这个错误。这是为什么？

我们看看 golangci-lint 的代码：

// pkg/golinters/staticcheck_common.go


func staticCheckConfig(settings *config.StaticCheckSettings) *scconfig.Config {
	var cfg *scconfig.Config

	if settings == nil || !settings.HasConfiguration() {
		return &scconfig.Config{
			Checks:                  []string{"*"}, // override for compatibility reason. Must drop in the next major version.
			Initialisms:             scconfig.DefaultConfig.Initialisms,
			DotImportWhitelist:      scconfig.DefaultConfig.DotImportWhitelist,
			HTTPStatusCodeWhitelist: scconfig.DefaultConfig.HTTPStatusCodeWhitelist,
		}
	}

	cfg = &scconfig.Config{
		Checks:                  settings.Checks,
		Initialisms:             settings.Initialisms,
		DotImportWhitelist:      settings.DotImportWhitelist,
		HTTPStatusCodeWhitelist: settings.HTTPStatusCodeWhitelist,
	}

	if len(cfg.Checks) == 0 {
		cfg.Checks = append(cfg.Checks, "*") // override for compatibility reason. Must drop in the next major version.
	}

	if len(cfg.Initialisms) == 0 {
		cfg.Initialisms = append(cfg.Initialisms, scconfig.DefaultConfig.Initialisms...)
	}

	if len(cfg.DotImportWhitelist) == 0 {
		cfg.DotImportWhitelist = append(cfg.DotImportWhitelist, scconfig.DefaultConfig.DotImportWhitelist...)
	}

	if len(cfg.HTTPStatusCodeWhitelist) == 0 {
		cfg.HTTPStatusCodeWhitelist = append(cfg.HTTPStatusCodeWhitelist, scconfig.DefaultConfig.HTTPStatusCodeWhitelist...)
	}

	cfg.Checks = normalizeList(cfg.Checks)
	cfg.Initialisms = normalizeList(cfg.Initialisms)
	cfg.DotImportWhitelist = normalizeList(cfg.DotImportWhitelist)
	cfg.HTTPStatusCodeWhitelist = normalizeList(cfg.HTTPStatusCodeWhitelist)

	return cfg
}

由于当前版本的 golangci-lint 将 staticcheck 一分为四了，因此这个 staticCheckConfig 实际上是给四个 linter 共用的获取配置的方法.

在 golangci-lint 中，对于 staticcheck 4件套，默认情况下，我们没有做任何配置，因此是执行的：

	if settings == nil || !settings.HasConfiguration() {
		return &scconfig.Config{
			Checks:                  []string{"*"}, // override for compatibility reason. Must drop in the next major version.
			Initialisms:             scconfig.DefaultConfig.Initialisms,
			DotImportWhitelist:      scconfig.DefaultConfig.DotImportWhitelist,
			HTTPStatusCodeWhitelist: scconfig.DefaultConfig.HTTPStatusCodeWhitelist,
		}
	}

我们看一下 HasConfiguration() 方法：


// pkg/config/linters_settings.go

type StaticCheckSettings struct {
	GoVersion string `mapstructure:"go"`

	Checks                  []string `mapstructure:"checks"`
	Initialisms             []string `mapstructure:"initialisms"`                // only for stylecheck
	DotImportWhitelist      []string `mapstructure:"dot-import-whitelist"`       // only for stylecheck
	HTTPStatusCodeWhitelist []string `mapstructure:"http-status-code-whitelist"` // only for stylecheck
}

// pkg/config/linters_settings.go
func (s *StaticCheckSettings) HasConfiguration() bool {
	return len(s.Initialisms) > 0 || len(s.HTTPStatusCodeWhitelist) > 0 || len(s.DotImportWhitelist) > 0 || len(s.Checks) > 0
}

除了注意 HasConfiguration()，我们还需要注意这里的 only for stylecheck，即 initialisms dot-import-whitelist 和 http-status-code-whitelist 这3个配置都是仅对 stylecheck 生效的。

通过查看 HasConfiguration() 的代码，我们清楚了，只要 checks initialisms dot-import-whitelist http-status-code-whitelist 四个配置里的任何一个存在，就会先应用用户的配置。

另外， func staticCheckConfig 里面还有逻辑，即 initialisms dot-import-whitelist http-status-code-whitelist 任何一个为空，都会取 "honnef.co/go/tools/config" 的默认配置，也就是

// https://github.com/dominikh/go-tools/blob/e75722ce7c1c555645e84dc08b2b9e8d54624d98/config/config.go#L159
var DefaultConfig = Config{
	Checks: []string{"all", "-ST1000", "-ST1003", "-ST1016", "-ST1020", "-ST1021", "-ST1022", "-ST1023"},
	Initialisms: []string{
		"ACL", "API", "ASCII", "CPU", "CSS", "DNS",
		"EOF", "GUID", "HTML", "HTTP", "HTTPS", "ID",
		"IP", "JSON", "QPS", "RAM", "RPC", "SLA",
		"SMTP", "SQL", "SSH", "TCP", "TLS", "TTL",
		"UDP", "UI", "GID", "UID", "UUID", "URI",
		"URL", "UTF8", "VM", "XML", "XMPP", "XSRF",
		"XSS", "SIP", "RTP", "AMQP", "DB", "TS",
	},
	DotImportWhitelist:      []string{},
	HTTPStatusCodeWhitelist: []string{"200", "400", "404", "500"},
}

蛋疼的地方来了， golangci-lint 为了兼容性，只要发现 checks 为空，就会将 checks 设置成 * ，注意这个 *, 并不是新版本的 staticcheck （这里指的是cmd, 不是package）的默认值。

// pkg/golinters/staticcheck_common.go func staticCheckConfig
	if len(cfg.Checks) == 0 {
		cfg.Checks = append(cfg.Checks, "*") // override for compatibility reason. Must drop in the next major version.
	}

没错, staticcheck 的默认配置是符合大多数人习惯的，但是 golangci-lint 基于兼容性考虑，无法应用默认配置

override for compatibility reason. Must drop in the next major version.

所以，作为使用者，符合习惯的做法应该是，按 staticcheck 的默认配置，根据自己的需求自行调整。当然，如果不调整，最简单的就是取 staticcheck 的默认配置了。

[linters-settings.stylecheck]
checks = ["all", "-ST1000", "-ST1003", "-ST1016", "-ST1020", "-ST1021", "-ST1022", "-ST1023" ]
dot-import-whitelist = []
http-status-code-whitelist = []

但是，这个配置在最新稳定版的 1.40.1 golangci-lint 并不生效，原因是，我们看的代码是 master 分支的。

1.40.1 golangci-lint 引用的是 honnef.co/go/tools v0.1.4 实际上是已经支持 checks 选项的，但是 golangci-lint 的代码没有加。

最初 4 兄弟在 golangci-lint 只有一个 go 版本的配置项，还是这个 PR 引入的： https://github.com/golangci/golangci-lint/pull/1946/files

直到这个 PR https://github.com/golangci/golangci-lint/pull/2017

ldez committed 4 days ago （当前写作日期： 2021-06-01）

对应的提交 https://github.com/golangci/golangci-lint/commit/b916c9318bf31c6dca73e64c1751bd62a661e2bb

这个 PR 同时还用一句话讲清楚了 golangci-lint 官方一直不愿意讲的事情：

Staticcheck is split into 4 linters in golangci-lint staticcheck, gosimple, stylecheck and unused.

If do so, why it is there 4 times?

staticcheck is a binary and a set of rules, those rules are grouped in "category": staticcheck, gosimple, stylecheck and unused.

megacheck was the first name of staticcheck, the "categories" were binaries, and as you can understand there are historical reasons behind those "linters" inside golangci-lint.

More information about the 4 linters: https://github.com/golangci/golangci-lint/issues/357

And why actually the staticcheck config file staticcheck.conf is ignored when running with golangci-lint?

The file is partially ignored: you can use staticcheck.conf to define initialisms, dot_import_whitelist, http_status_code_whitelist but checks are ignored (instead you have to use issues.excludes in the golanci-lint configuration).

It is mainly related to the API of staticcheck: we don't have access to the element to handle the staticcheck configuration.

About the configuration, you can follow https://github.com/golangci/golangci-lint/issues/1275

新版本的 golangci-lint 里面有这么个方法(实际上基本上是copy自dominikh/go-tools的)：


// https://github.com/dominikh/go-tools/blob/9bf17c0388a65710524ba04c2d821469e639fdc2/lintcmd/lint.go#L437-L477
// nolint // Keep the original source code.
func filterAnalyzerNames(analyzers []string, checks []string) map[string]bool {
	allowedChecks := map[string]bool{}

	for _, check := range checks {
		b := true
		if len(check) > 1 && check[0] == '-' {
			b = false
			check = check[1:]
		}

		if check == "*" || check == "all" {
			// Match all
			for _, c := range analyzers {
				allowedChecks[c] = b
			}
		} else if strings.HasSuffix(check, "*") {
			// Glob
			prefix := check[:len(check)-1]
			isCat := strings.IndexFunc(prefix, func(r rune) bool { return unicode.IsNumber(r) }) == -1

			for _, a := range analyzers {
				idx := strings.IndexFunc(a, func(r rune) bool { return unicode.IsNumber(r) })
				if isCat {
					// Glob is S*, which should match S1000 but not SA1000
					cat := a[:idx]
					if prefix == cat {
						allowedChecks[a] = b
					}
				} else {
					// Glob is S1*
					if strings.HasPrefix(a, prefix) {
						allowedChecks[a] = b
					}
				}
			}
		} else {
			// Literal check name
			allowedChecks[check] = b
		}
	}
	return allowedChecks
}

filterAnalyzerNames() 实际上会被 setupStaticCheckAnalyzers() 调用, 其实只是在 filterAnalyzerNames 的基础上，针对被启用的 Analyzer 设置了一下go version (setAnalyzerGoVersion) ：

func setupStaticCheckAnalyzers(src []*lint.Analyzer, goVersion string, checks []string) []*analysis.Analyzer {
	var names []string
	for _, a := range src {
		names = append(names, a.Analyzer.Name)
	}

	filter := filterAnalyzerNames(names, checks)

	var ret []*analysis.Analyzer
	for _, a := range src {
		if filter[a.Analyzer.Name] {
			setAnalyzerGoVersion(a.Analyzer, goVersion)
			ret = append(ret, a.Analyzer)
		}
	}

	return ret
}

其后我们看下那几个 new 都差不多, 都会调用 setupStaticCheckAnalyzers():

func NewStaticcheck(settings *config.StaticCheckSettings) *goanalysis.Linter {
	cfg := staticCheckConfig(settings)

	analyzers := setupStaticCheckAnalyzers(staticcheck.Analyzers, getGoVersion(settings), cfg.Checks)

	return goanalysis.NewLinter(
		"staticcheck",
		"Staticcheck is a go vet on steroids, applying a ton of static analysis checks",
		analyzers,
		nil,
	).WithLoadMode(goanalysis.LoadModeTypesInfo)
}

func NewStylecheck(settings *config.StaticCheckSettings) *goanalysis.Linter {
	cfg := staticCheckConfig(settings)

	// `scconfig.Analyzer` is a singleton, then it's not possible to have more than one instance for all staticcheck "sub-linters".
	// When we will merge the 4 "sub-linters", the problem will disappear: https://github.com/golangci/golangci-lint/issues/357
	// Currently only stylecheck analyzer has a configuration in staticcheck.
	scconfig.Analyzer.Run = func(pass *analysis.Pass) (interface{}, error) {
		return cfg, nil
	}

	analyzers := setupStaticCheckAnalyzers(stylecheck.Analyzers, getGoVersion(settings), cfg.Checks)

	return goanalysis.NewLinter(
		"stylecheck",
		"Stylecheck is a replacement for golint",
		analyzers,
		nil,
	).WithLoadMode(goanalysis.LoadModeTypesInfo)
}

https://github.com/golangci/golangci-lint/commit/7705f82591bdc71500802ce1b0fee4ef6726bbcc

Update megacheck to the latest version Also do following improvements:

show proper sublinter name for megacheck sublinters
refactor and make more simple and robust megacheck merging/optimizing
improve handling of unknown linter names in //nolint directives
minimize diff of our megacheck version from the upstream, golang/go#29612 blocks usage of the upstream version
support the new stylecheck linter
improve tests coverage for megacheck and nolint related cases
update and use upstream versions of unparam and interfacer instead of forked ones
don't use golangci/tools repo anymore
fix newly found issues after updating linters

Also should be noted that megacheck works much faster and consumes less memory in the newest release, therefore golangci-lint works noticeably faster and consumes less memory for large repos.

Relates: #314 master (#352) v1.40.1 v1.40.0 v1.39.0 v1.38.0 v1.37.1 v1.37.0 v1.36.0 v1.35.2 v1.35.1 v1.35.0 v1.34.1 v1.34.0 v1.33.2 v1.33.1 v1.33.0 v1.32.2 v1.32.1 v1.32.0 v1.31.0 v1.30.0 v1.29.0 v1.28.3 v1.28.2 v1.28.1 v1.28.0 v1.27.0 v1.26.0 v1.25.1 v1.25.0 v1.24.0 v1.23.8 v1.23.7 v1.23.6 v1.23.5 v1.23.4 v1.23.3 v1.23.2 v1.23.1 v1.23.0 v1.22.2 v1.22.1 v1.22.0 v1.21.0 v1.20.1 v1.20.0 v1.19.1 v1.19.0 v1.18.0 v1.17.1 v1.17.0 v1.16.0 v1.15.0 v1.14.0 v1.13.2 v1.13.1 v1.13

总结

在 golangci-lint 当前版本 (v1.40.1)里， megacheck = [gosimple staticcheck unused]
staticcheck = staticcheck package (而不是四合一的当前真正的 staticcheck cmd的功能)
stylecheck 目前我们还没办法启用，因为当前无法给它配置需要禁用的一些规则. 只能等下一个 golangci-lint 版本（如果它把上面我说到的代码合并了)

如是当前 master 分支的代码被合并了，那么是可以使用以下配置的：

linters-settings:
  stylecheck:
    checks:
      - all
      - '-ST1000'
      - '-ST1003'
      - '-ST1016'
      - '-ST1020'
      - '-ST1021'
      - '-ST1022'
      - '-ST1023'
    dot-import-whitelist: []
    http-status-code-whitelist: []

我们期待 golangci-lint 新的 2.0 版本里将真正的四合一版本的 staticcheck 集成进来，这样就没有必要像现在这样，针对同一个 linter 的同样的配置要写四遍了。

Refs

https://staticcheck.io/

https://github.com/golangci/golangci-lint

https://golangci-lint.run/

分享几个基于Golang/Rust的图片处理开源项目

ttyS3 — Sun, 06 Jun 2021 03:57:59 GMT

1. imgproxy/imgproxy (golang, 4.6K star)

imgproxy 目前有 4.6K star

https://github.com/imgproxy/imgproxy

Fast and secure standalone server for resizing and converting remote images
imgproxy 是一个快速安全的独立服务器，用于调整远程图像的大小和转换远程图像。 imgproxy 的主要原则是简单，速度和安全性。
imgproxy 只做一件事 —— 调整远程图像的大小 —— 而且做得很好。当您需要动态调整多个图像的大小以使其与您的应用程序设计匹配时，它非常有用，而无需准备大量缓存的调整大小的图像或每次设计更改时都重新执行。
imgproxy是一个go应用程序，准备安装并在任何Unix环境中使用 - 也可以使用Docker容器化。

简单

"No code is better than no code."

这句话我保持原样不做翻译，任何翻译都会导致变味。简单来说，imgproxy 只会包含那些必须的功能，而一些补充性可有可无的功能就不会包含进来。

imgproxy 仅包括用于图像处理，微调和安全性的必须具有的功能。

它的简单体现在哪里呢？

能方很容易使用CSS3完成功能的，坚决不集成，比如 rotate, flip 和应用蒙板层这类操作。
不内置HTTP缓存功能，因为这个目的很容易通过 CDN 或者专门的缓存代理服务器来实现
不会试图内置实现所有功能，比如 https 支持，因为这个很容易就可以通过一些专业的 http 代理服务器来实现, 比如 nginx

拥有内置的所有内容 - 例如HTTPS支持可能是有用的 - 但是解决这一问题的简单方法是使用诸如nginx等代理HTTP服务器。

高效

高效处理图片的主要原因是，它的图片处理并不是通过原生golang来实现的，而是通过调用C库libvips，libvips号称是所有图片处理库里速度最快的。（没错，在缩放图片这种操作上， ImageMagick 或 GraphicsMagick 也 PK 不过 libvips）

官方甚至提供了一个 benchmark 可供参考：

Tool	Time taken for tests (sec)	Requests per second	Time per request (ms, mean)	Memory peak usage (MB)	Result file size (KB)
imgproxy	103.405	9.67	413.618	194	43.51
thumbor	160.505	6.23	642.021	461	45.10
imaginary	104.873	9.54	419.494	562	92.93
Pilbox	179.482	5.57	717.927	1060	95.64
picfit	1220.412	0.82	4881.646	1934	98.67
imageproxy	1209.361	0.83	4837.443	2392	98.74

安全

在安全方面，大量处理远程图像是一件潜在的危险事情。

* imgproxy 在下载时会检查图像类型和“真实”尺寸，因此如果图像格式未知或尺寸太大（有一个设置），则不会完全下载图像。这就是 imgproxy 如何保护您免受所谓的“图像炸弹”的侵害，例如在 https://www.bamsoftware.com/hacks/deflate.html 中描述的那些。

* imgproxy 使用签名保护图像 URL，因此攻击者无法通过请求多个图像调整大小来引发拒绝服务攻击。

* imgproxy 支持通过 HTTP header 进行授权。这可以防止攻击者直接使用 imgproxy，但允许通过 CDN 或缓存服务器使用它——只需向代理或 CDN 配置添加 header 即可。

--------------------------------------------------------------------------------------

2. imazen/imageflow (rust, 3.5K star)

https://docs.imageflow.io/

https://github.com/imazen/imageflow

https://docs.imageflow.io/querystring/introduction.html

高性能图片处理服务器，包含imageflow_server, imageflow_tool, and libimageflow

imageflow_tool is a command-line tool for experimenting, running batch jobs, or when you want process isolation. Up to 17x faster than ImageMagick. Also produces smaller files at higher quality.
imageflow_server can run JSON jobs or manipulate images in-flight (e.g./bucket/img.jpg?w=200) for direct use from HTML. Source images can reside in blob storage, on another server, or on the filesystem. However, for production use, we recommend using Imageflow.NET Server, which is far more feature-rich and doesn't need a reverse proxy in front for security.
libimageflow is for direct (in-process) use from your programming language. See our Node bindings, Go bindings, Scala bindings, Elixir bindings, or .NET bindings. If we don't already have bindings for your language, consider spending a day to add them. Imageflow has a simple C-compatible ABI, of which only 4 methods are needed to implement bindings.

3. h2non/imaginary (golang, 3.7K star)

https://github.com/h2non/imaginary

https://fly.io/launch/github/h2non/imaginary

Fast, simple, scalable, Docker-ready HTTP microservice for high-level image processing

imaginary 也是用的 libvips

容器化支持较好。

Supported image operations

Resize
Enlarge
Crop
SmartCrop (based on libvips built-in algorithm)
Rotate (with auto-rotate based on EXIF orientation)
AutoRotate with further image transformations (based on EXIF metadata orientation)
Flip (with auto-flip based on EXIF metadata)
Flop
Zoom
Thumbnail
Fit
Pipeline of multiple independent image transformations in a single HTTP request.
Configurable image area extraction
Embed/Extend image, supporting multiple modes (white, black, mirror, copy or custom background color)
Watermark (customizable by text)
Watermark image
Custom output color space (RGB, black/white...)
Format conversion (with additional quality/compression settings)
Info (image size, format, orientation, alpha...)
Reply with default or custom placeholder image in case of error.
Blur

4. thoas/picfit (golang, 1.5K star)

picfit is a reusable Go server to manipulate images (resize, thumbnail, etc.).

It will act as a proxy on your storage engine and will be served ideally behind an HTTP cache system like varnish.

It supports multiple storage backends and multiple key/value stores.

[KVSTORE] can be:

redis - generated keys stored in Redis, see below how you can customize connection parameters
cache - generated keys stored in an in-memory cache
redis-cluster - generated keys stored in Redis cluster

[STORAGE] can be:

fs - generated images stored in your File system
http+fs - generated images stored in your File system and loaded using HTTP protocol
s3 - generated images stored in Amazon S3
dos3 - generated images stored in DigitalOcean S3
gcs - generated images stored in Google Cloud Storage
http+s3 - generated images stored in Amazon S3 and loaded using HTTP protocol
http+dos3 - generated images stored in DigitalOcean S3 and loaded using HTTP protocol

5. pierrre/imageserver (golang, 1.9K star)

imageserver 并不是一个到手就能用的服务，而是一个golang module.

Features

HTTP server
Resize (GIFT, nfnt resize, Graphicsmagick)
Rotate
Crop
Convert (JPEG, GIF (animated), PNG , BMP, TIFF, ...)
Cache (groupcache, Redis, Memcache, in memory)
Gamma correction
Fully modular

不过集成使用它也比较简单：

// https://github.com/pierrre/imageserver/blob/master/examples/simple/simple.go
// Package simple provides a simple example.
package main

import (
	"net/http"https://github.com/imgproxy/imgproxy

	"github.com/pierrre/imageserver"
	imageserver_http "github.com/pierrre/imageserver/http"
	imageserver_http_gift "github.com/pierrre/imageserver/http/gift"
	imageserver_http_image "github.com/pierrre/imageserver/http/image"
	imageserver_image "github.com/pierrre/imageserver/image"
	_ "github.com/pierrre/imageserver/image/gif"
	imageserver_image_gift "github.com/pierrre/imageserver/image/gift"
	_ "github.com/pierrre/imageserver/image/jpeg"
	_ "github.com/pierrre/imageserver/image/png"
	imageserver_testdata "github.com/pierrre/imageserver/testdata"
)

func main() {
	http.Handle("/", &imageserver_http.Handler{
		Parser: imageserver_http.ListParser([]imageserver_http.Parser{
			&imageserver_http.SourceParser{},
			&imageserver_http_gift.ResizeParser{},
			&imageserver_http_image.FormatParser{},
			&imageserver_http_image.QualityParser{},
		}),
		Server: &imageserver.HandlerServer{
			Server: imageserver_testdata.Server,
			Handler: &imageserver_image.Handler{
				Processor: &imageserver_image_gift.ResizeProcessor{},
			},https://github.com/imgproxy/imgproxy
		},
	})
	err := http.ListenAndServe(":8080", nil)
	if err != nil {
		panic(err)
	}
}

Tool

ttyS3 — Sun, 06 Jun 2021 00:00:00 GMT

格式转换

toml to yaml: https://www.convertsimple.com/convert-toml-to-yaml/

yaml to toml: https://www.convertsimple.com/convert-yaml-to-toml/

json to toml: https://www.convertsimple.com/convert-json-to-toml/

json to yaml: https://transform.tools/json-to-yaml

https://transform.tools/json-schema-to-protobuf

https://transform.tools/js-object-to-json

transform is open source: https://github.com/ritz078/transform

https://transform.tools/json-to-go-bson

https://transform.tools/json-to-go

https://mholt.github.io/json-to-go/

https://mholt.github.io/curl-to-go/

json https://jsoneditoronline.org/

json 格式化神器 https://jsonformatter.org/

Protobuf decode https://protobuf-decoder.netlify.app/

markdown 画图 mermaid-live-editor https://mermaid-js.github.io/mermaid-live-editor

汇编分析 Godbolt Compiler Explorer https://godbolt.org/

数学神器 Wolframalpha https://www.wolframalpha.com/

在线ps 图片 https://pc.meitu.com/design/edit

包依赖分析 https://deps.dev/

Regex101 最好用的正则测试工具 https://regex101.com/

static site generator

https://jamstack.org/generators/

https://github.com/gohugoio/hugo

https://github.com/getzola/zola

静态博客托管

https://www.netlify.com/

Cloudflare Pages https://developers.cloudflare.com/pages/getting-started

https://pages.cloudflare.com/#pricing

https://developers.cloudflare.com/pages/framework-guides/deploy-a-zola-site#deploying-with-cloudflare-pages

https://developers.cloudflare.com/pages/platform/limits

bandwidth: Unlimited bandwidth Builds: deploy up to 500 times per month on the free plan Maximum file size: 25MB Custom domains: a maximum of ten (10) custom domains per project

https://vercel.com/

https://render.com/

https://help.github.com/articles/what-is-github-pages/

AWS Amplify https://aws.amazon.com/amplify/pricing/

-- EOF

给 Hugo 博客添加 mermaid 短代码支持

ttyS3 — Sat, 05 Jun 2021 16:27:41 GMT

首先，看下效果，就是下面这样（RSS 订阅用户可能看不到效果，请点击查看原文)：

{{< mermaid >}}
sequenceDiagram
    participant Alice
    participant Bob
    Alice->>John: Hello John, how are you?
    loop Healthcheck
        John->John: Fight against hypochondria
    end
    Note right of John: Rational thoughts prevail...
    John-->Alice: Great!
    John->Bob: How about you?
    Bob-->John: Jolly good!
{{< /mermaid >}}

源代码取自 https://learn.netlify.app/en/shortcodes/mermaid/ ，如下：

sequenceDiagram
    participant Alice
    participant Bob
    Alice->>John: Hello John, how are you?
    loop Healthcheck
        John->John: Fight against hypochondria
    end
    Note right of John: Rational thoughts prevail...
    John-->Alice: Great!
    John->Bob: How about you?
    Bob-->John: Jolly good!

短代码使用方法

{{</* mermaid */>}}
// 中间写mermaid
{{</* /mermaid */>}}

看上去好像不太直观啊，没错，官方也考虑到了这一点，给送上了 mermaid-live-editor

https://mermaid-js.github.io/mermaid-live-editor

使用 mermaid-live-editor，可以实时预览效果，如果不知道下手，里面还有快速demo供使用。

集成到 Hugo

目的：最简化集成，不需要增加 Hugo 配置，不需要在 markdown front matter 里增加任何选项.

增加 shortcode 模板

如果用 mermaid 官方的集成方法，会带来一个问题：官方集成方法会导致我们的每个文章页面都会加载 mermaid.js ，但是我们写博客的时候，并不是每个页面都需要加载 mermaid 这个 js, 只在文章里面包含 mermaid 代码时我们才需要加载。因此这里我们用 js 动态加载 mermaid.

首先，这个 js 我们也懒得放在主题里了，直接用 CDN 的：

去 https://www.jsdelivr.com/package/npm/mermaid 我们点开 dist 目录，然后找到完整版的js文件（注意不要看错了，选了 core 那个）：

https://cdn.jsdelivr.net/npm/[email protected]/dist/mermaid.min.js

新增加 shortcode, 目前我用的主题是 terminal，因此在 themes/terminal 下新建：

layouts/shortcodes/mermaid.html 文件，内容如下：

<!-- https://github.com/matcornic/hugo-theme-learn/blob/master/layouts/shortcodes/mermaid.html -->
<pre class="mermaid" align="{{ if .Get "align" }}{{ .Get "align" }}{{ else }}center{{ end }}">{{ safeHTML .Inner }}</pre>

这个 shortcode 代码基本上取自这里，但是老灯这里把外层的 div 改成了 pre

关于 .Inner 是啥，可以参考这个文档

{{ $_hugo_config := `{ "version": 1 }` }} 我也一并移除了，这个是 shortcodes-with-markdown 才需要的，而我们这里面的内容都是直接给 js 处理的，并不需要 markdown 处理。参考这里

加载 mermaid js

网上大部分的模板都不够自动，很多是需要在配置里选择是否加载 mermaid 的，这里老灯写了个根据文章内容动态加载的 js .

修改模板的 footer.html 文件，增加 js:

  const loadScript = (url, onloadFunction) => {
    var newScript = document.createElement("script");
    newScript.onerror =  (oError) => {
      throw new URIError("The script " + oError.target.src + " didn't load correctly.");
    };
    if (onloadFunction) { newScript.onload = onloadFunction; }
    document.head.insertAdjacentElement('beforeend', newScript);
    newScript.src = url;
  }

  // mermaid loader by ttys3.dev
  const loadMermaidOnNeed = () => {
    if (document.querySelectorAll('.mermaid').length > 0) {
      loadScript('https://cdn.jsdelivr.net/npm/[email protected]/dist/mermaid.min.js', () => {
        document.head.insertAdjacentHTML("beforeend", `<style>.mermaid svg { background-color: #dadcd8 !important; }</style>`);
        // default, dark, neutral, forest
        mermaid.initialize({ startOnLoad: false, securityLevel: "strict", theme: "neutral" });
        // https://github.com/mermaid-js/mermaid/blob/e6e94ad57ea06ef8627bf91ddfbd88f5082952bf/src/mermaid.js#L153
        // mermaid.contentLoaded();
        mermaid.init();
        console.log("mermaid init done");
      })
    }
  }

  window.addEventListener('load', function(event) {
    // load mermaid
    loadMermaidOnNeed();
  });

如果要调试问题，可以在配置里增加 logLevel: 1,

theme: "neutral" 是指定主题，可以从 default, dark, neutral, forest 四个里面选。如果不太满意默认的，也可以自行 DIY, 参考 https://mermaid-js.github.io/mermaid/#/theming

startOnLoad 选项其实在我们这里并没有什么用。如果调用 mermaid.contentLoaded() 渲染的话，需要设置 startOnLoad 为 true. 但是其实 contentLoaded 就是判断了一下 startOnLoad 然后调用了 mermaid.init()，因此这里老灯直接调用 mermaid.init() 渲染了。

最后，偷懒的可以直接用老灯这个修改版的terminal主题 https://github.com/ttys3/hugo-theme-terminal/tree/ttys3

Refs

https://code.luasoftware.com/tutorials/hugo/how-to-escape-shortcode-in-hugo/

https://github.com/mermaid-js/mermaid

https://github.com/mermaid-js/mermaid-live-editor

https://github.com/matcornic/hugo-theme-learn

https://github.com/matcornic/hugo-theme-learn/blob/master/layouts/shortcodes/mermaid.html

https://mermaid-js.github.io/mermaid/#/Setup?id=startonload

https://mermaid-js.github.io/mermaid/#/Setup?id=securitylevel

strict: (default) tags in text are encoded, click functionality is disabeled loose: tags in text are allowed, click functionality is enabled antiscript: html tags in text are allowed, (only script element is removed), click functionality is enabled

调整了下 Hugo 永久链接生成配置

ttyS3 — Thu, 03 Jun 2021 20:32:36 GMT

之前一直用的是 Hugo 默认的 permalink 配置.

如 content/post/linux/commandlinefu/how-to-start-tmux-as-systemd-user-service/index.md 将会生成
/post/linux/commandlinefu/how-to-start-tmux-as-systemd-user-service/ 的 URL path.

最近我越来越发现这样的链接过度复杂了，干脆直接调整成 /post/:filename/ 。

于是 /post/linux/commandlinefu/how-to-start-tmux-as-systemd-user-service/ 变成了 /post/how-to-start-tmux-as-systemd-user-service/ 。

这意味着，目录结构可能不单是我组织文件的方式，同时也被用来分类了 (父类/子类/文章slug)。

这给我带来了负担，导致我很久都没写博客。因为有时候想写点东西，又纠结，应该放在哪个分类下面。

因为有些东西是很难划分界线的，可能属于这个分类，但是你放在另一个分类里，也不是不可以。

从 URL 里去掉可以肉眼看出是分类的部分 path, 同时，彻底去掉分类这个东西。用 tags 来分类。一个文章可以有很多 tags , 手动写几个 tags 来给文章分类即可。

想想以前用 WordPress 的时候，我甚至用过4级分类，现在想来，那时候真是疯了。

调整配置之后，page bunlde 的图片无法显示了。于是修复了下，就不细说了，直接贴一下我的 commit log.

commit 4ddd32088bba8486b2aa72a29c0ac0f540de9bd4
Author: 荒野無燈
Date:   Wed Jun 2 23:26:08 2021 +0800

    fix(url): fixup rel page bundle image resource url for permalinks config set to /post/:filename/
    
    for example:
    for url `http://localhost:1313/post/tmux-24bit-true-color-support/`
    
    the real page bundle path is `content/post/linux/apps/tmux-24bit-true-color-support`
    
    since our permalink config is set to `:filename`, so the real image for the page bundle
    
    will copied to `public/post/tmux-24bit-true-color-support`
    
    so the `RelPermalink` (directory created according to permalinks config) decided the image's directory.
    
    even if we changed the permalinks config to /post/:slug or other format, the code will works fine

diff --git a/layouts/_default/_markup/render-image.html b/layouts/_default/_markup/render-image.html
index 26c4bc3..0c5036b 100644
--- a/layouts/_default/_markup/render-image.html
+++ b/layouts/_default/_markup/render-image.html
@@ -5,7 +5,7 @@
 {{/* process relative PATH URL in page bundle: no Scheme and not start with `/` */}}
 {{ if and (eq $theURL.Scheme "") (not (strings.HasPrefix .Destination "/")) }}
     {{ if eq "index.md" .Page.File.LogicalName }}
-        {{ $imgSrc = printf "%s/%s" .Page.File.Dir .Destination | absURL | safeURL }}
+        {{ $imgSrc = printf "%s/%s" .Page.RelPermalink .Destination | absURL | safeURL }}
     {{ end }}
 {{ end }}
 
diff --git a/layouts/_default/_markup/render-image.rss.xml b/layouts/_default/_markup/render-image.rss.xml
index 48846b9..3cffcd4 100644
--- a/layouts/_default/_markup/render-image.rss.xml
+++ b/layouts/_default/_markup/render-image.rss.xml
@@ -5,7 +5,7 @@
 {{/* process relative PATH URL in page bundle: no Scheme and not start with `/` */}}
 {{ if and (eq $theURL.Scheme "") (not (strings.HasPrefix .Destination "/")) }}
     {{ if eq "index.md" .Page.File.LogicalName }}
-        {{ $imgSrc = printf "%s/%s" .Page.File.Dir .Destination | absURL | safeURL }}
+        {{ $imgSrc = printf "%s/%s" .Page.RelPermalink .Destination | absURL | safeURL }}
     {{ end }}
 {{ end }}
 
diff --git a/layouts/_default/_markup/render-link.html b/layouts/_default/_markup/render-link.html
index a101673..ae92493 100644
--- a/layouts/_default/_markup/render-link.html
+++ b/layouts/_default/_markup/render-link.html
@@ -7,7 +7,7 @@
 {{/* process relative PATH URL in page bundle: no Scheme and not start with `/` */}}
 {{ if and (eq $theURL.Scheme "") (not (strings.HasPrefix .Destination "/")) }}
     {{ if eq "index.md" .Page.File.LogicalName }}
-        {{ $linkHref = printf "%s/%s" .Page.File.Dir .Destination | absURL | safeURL }}
+        {{ $linkHref = printf "%s/%s" .Page.RelPermalink .Destination | absURL | safeURL }}
     {{ end }}
 {{ end }}
 
diff --git a/layouts/_default/list.html b/layouts/_default/list.html
index cceef21..f2b89c0 100644
--- a/layouts/_default/list.html
+++ b/layouts/_default/list.html
@@ -41,7 +41,7 @@
 
     {{ if .Params.cover }}
       {{ if eq "index.md" .File.LogicalName }}
-        <img src="{{ printf "%s/%s" .File.Dir .Params.cover | absURL }}" class="post-cover" />
+        <img src="{{ printf "%s/%s" .RelPermalink .Params.cover | absURL }}" class="post-cover" />
       {{ else }}
         <img src="{{ .Params.cover | absURL }}" class="post-cover" />
       {{ end }}
diff --git a/layouts/_default/single.html b/layouts/_default/single.html
index a2ae357..72354bc 100644
--- a/layouts/_default/single.html
+++ b/layouts/_default/single.html
@@ -35,7 +35,7 @@
 
   {{ if .Params.cover }}
     {{ if eq "index.md" .File.LogicalName }}
-      <img src="{{ printf "%s/%s" .File.Dir .Params.cover | absURL }}" class="post-cover" />
+      <img src="{{ printf "%s/%s" .RelPermalink .Params.cover | absURL }}" class="post-cover" />
     {{ else }}
       <img src="{{ .Params.cover | absURL }}" class="post-cover" />
     {{ end }}

Hugo 博客如何更新 Algolia 索引

ttyS3 — Thu, 03 Jun 2021 19:48:36 GMT

集成 Algolia 后，最简单无脑的更新索引方式就是每次构建后由 Netlify 触发 webhook 通知 Algolia 自动抓取。这也就是 Algolia Crawler for Netlify 干的活。

但是老灯使用一段时间后发现存在一些问题：

每发一篇博客，甚至可能是只改动了一个字就要触发全量索引 (git push 触发了 Netlify CI CD -> webhook -> Algolia Crawler 干活 -> 抓取全站 URL 并索引)。一是浪费资源，二是低低效(速度慢）。
很多不需要索引的页面也被索引进去了，比如 tags 和 categories 的分页列表页面。我博客总共才70篇文章不到，索引后的页面居然有300多！

要个性化的索引，还得自己动手。毕竟你自己的内容，自己最清楚。

浏览了下 Github, star 数量多的相关项目几乎没有。

https://github.com/spotlightpa/algolia-indexer 0 star

https://github.com/duckpuppy/algolia-hugo 8 star 但是我稍看了下代码，觉得他把简单的事情搞复杂了，还用到了 viper 这个 go mod, 天啊，放弃吧。

继续找，找到一个 https://github.com/naah69/Hugo-Algolia-Chinese-Builder 但是，这个 repo 的命名首先就很不 golang style.

于是我 fork 出来新的 https://github.com/ttys3/hugo-algolia-updater 并整理了一下代码。

加上 golangci-lint 和 zap logger. 最终效果如图：

代码还有待优化，时间有限，先这样了。

Refs

https://www.algolia.com/doc/tools/crawler/netlify-plugin/quick-start/

https://www.netlify.com/blog/2017/10/10/replacing-our-search-with-algolia/

Pacman 6.0 发布

ttyS3 — Thu, 03 Jun 2021 19:36:18 GMT

最近升级到了 pacman 6.0 版本。主要的新功能是支持多线程下载了。

如果是从旧版本升级的，那么其实配置需要自己手动合并。简单来说就是添加一行

ParallelDownloads = 5

即可。

虽然将下载器配置成aria2 或 curl （新版本的curl 有多线程下载功能 -Z ) 也能实现多线程下载，但是终究还是不如官方直接支持香。

贴下我的完整配置 /etc/pacman.conf ：

#
# /etc/pacman.conf
#
# See the pacman.conf(5) manpage for option and repository directives

#
# GENERAL OPTIONS
#
[options]
# The following paths are commented out with their default values listed.
# If you wish to use different paths, uncomment and update the paths.
#RootDir     = /
#DBPath      = /var/lib/pacman/
#CacheDir    = /var/cache/pacman/pkg/
#LogFile     = /var/log/pacman.log
#GPGDir      = /etc/pacman.d/gnupg/
#HookDir     = /etc/pacman.d/hooks/
HoldPkg     = pacman glibc
#XferCommand = /usr/bin/curl -L -C - -f -o %o %u
#XferCommand = /usr/bin/wget --passive-ftp -c -O %o %u
#CleanMethod = KeepInstalled
Architecture = auto

# Pacman won't upgrade packages listed in IgnorePkg and members of IgnoreGroup
#IgnorePkg   = tree-sitter
#IgnoreGroup =

#NoUpgrade   =
#NoExtract   =

# Misc options
#UseSyslog
Color
#NoProgressBar
CheckSpace
VerbosePkgLists
ParallelDownloads = 5

# By default, pacman accepts packages signed by keys that its local keyring
# trusts (see pacman-key and its man page), as well as unsigned packages.
SigLevel    = Required DatabaseOptional
LocalFileSigLevel = Optional
#RemoteFileSigLevel = Required

# NOTE: You must run `pacman-key --init` before first using pacman; the local
# keyring can then be populated with the keys of all official Arch Linux
# packagers with `pacman-key --populate archlinux`.

#
# REPOSITORIES
#   - can be defined here or included from another file
#   - pacman will search repositories in the order defined here
#   - local/custom mirrors can be added here or in separate files
#   - repositories listed first will take precedence when packages
#     have identical names, regardless of version number
#   - URLs will have $repo replaced by the name of the current repo
#   - URLs will have $arch replaced by the name of the architecture
#
# Repository entries are of the format:
#       [repo-name]
#       Server = ServerName
#       Include = IncludePath
#
# The header [repo-name] is crucial - it must be present and
# uncommented to enable the repo.
#

# The testing repositories are disabled by default. To enable, uncomment the
# repo name header and Include lines. You can add preferred servers immediately
# after the header, and they will be used before the default mirrors.

#[testing]
#Include = /etc/pacman.d/mirrorlist

[core]
Include = /etc/pacman.d/mirrorlist

[extra]
Include = /etc/pacman.d/mirrorlist

#[community-testing]
#Include = /etc/pacman.d/mirrorlist

[community]
Include = /etc/pacman.d/mirrorlist

# If you want to run 32 bit applications on your x86_64 system,
# enable the multilib repositories as required here.

#[multilib-testing]
#Include = /etc/pacman.d/mirrorlist

#[multilib]
#Include = /etc/pacman.d/mirrorlist

# An example of a custom package repository.  See the pacman manpage for
# tips on creating your own repositories.
#[custom]
#SigLevel = Optional TrustAll
#Server = file:///home/custompkgs

## 中国科学技术大学 (安徽合肥) (ipv4, ipv6, http, https)
[archlinuxcn]
Server = https://mirrors.sjtug.sjtu.edu.cn/archlinux-cn/$arch

对应的, aur helper 工具 paru 最近也升级到 v1.7.1 了。

/etc/paru.conf 配置：

#
# $PARU_CONF
# /etc/paru.conf
# ~/.config/paru/paru.conf
#
# See the paru.conf(5) manpage for options

#
# GENERAL OPTIONS
#
[options]
PgpFetch
Devel
Provides
DevelSuffixes = -git -cvs -svn -bzr -darcs -always
#BottomUp
#RemoveMake
#SudoLoop
#UseAsk
#CombinedUpgrade
#CleanAfter
#UpgradeMenu
#NewsOnUpgrade

#LocalRepo
#Chroot
#MovePkgs

#
# Binary OPTIONS
#
[bin]
FileManager = vifm
#MFlags = --skippgpcheck
#Sudo = doas

gpg: signing failed: Inappropriate ioctl for device 解决办法

ttyS3 — Wed, 05 May 2021 14:05:12 GMT

最近换了系统， git commit 在gpg签名的时候出错了：

gpg: signing failed: Inappropriate ioctl for device

原因是 gpg 在当前终端无法弹出密码输入页面。

解决办法：

export GPG_TTY=$(tty)

重新执行，发现会弹出一个密码输入界面。

参考： https://www.jianshu.com/p/2ed292ae2365

但是老灯觉得这不是解决办法，因为在此之前，我从来没遇到过这个问题。产生这个问题是有原因的。

于是再去看了一下Arch的文档，果然，有说明“Invalid IPC response and Inappropriate ioctl for device” 这个问题。虽然报错语句不一样，但是其实是一个问题。

https://wiki.archlinux.org/title/GnuPG#Invalid_IPC_response_and_Inappropriate_ioctl_for_device

The default pinentry program is /usr/bin/pinentry-gtk-2. If gtk2 is unavailable, pinentry falls back to /usr/bin/pinentry-curses and causes signing to fail:

gpg: signing failed: Inappropriate ioctl for device gpg: [stdin]: clear-sign failed: Inappropriate ioctl for device You need to set the GPG_TTY environment variable for the pinentry programs /usr/bin/pinentry-tty and /usr/bin/pinentry-curses.

$export GPG_TTY=$ (tty)

如果我们看一下 /usr/bin/pinentry 这个shell脚本, 内容如下：

#!/bin/sh

# user-defined pre-exec hook
test -r "${XDG_CONFIG_HOME:-$HOME/.config}"/pinentry/preexec &&
    . "${XDG_CONFIG_HOME:-$HOME/.config}"/pinentry/preexec

# site-defined pre-exec hook
test -r /etc/pinentry/preexec &&
    . /etc/pinentry/preexec

test -e /usr/lib/libgtk-x11-2.0.so.0 &&
    exec /usr/bin/pinentry-gtk-2 "$@"

exec /usr/bin/pinentry-curses "$@"

然后我们看看 /etc/pinentry/preexec 的内容，发现 /usr/bin/pinentry-gnome3 和 /usr/bin/pinentry-qt 其实在我当前系统上都是存在的，所以，最简单的办法，其实我们注释掉pinentry-gnome3 那一行，或qt那一行都OK.

这样就没有必要再fallback 到 pinentry-gtk-2 或 pinentry-curses 了

#!/hint/sh

# Define additional functionality for pinentry. For example
#test -e /usr/lib/libgcr-base-3.so.1 && exec /usr/bin/pinentry-gnome3 "$@"
#test -e /usr/lib/libQt5Widgets.so.5 && exec /usr/bin/pinentry-qt     "$@"

根据 Arch 文档， “gpg-agent is mostly used as daemon to request and cache the password for the keychain. ”，我们使用ssh的时候，有ssh-agent 或类似 gnome seahorse 之类的工具充当agent, 那么 gpg 其实也有 agent的，这个 agent 一定是属于当前用户的，如果遇到问题，不防检查一下它是不是正确运行状态，当然，老灯这次遇到的并不是这个问题， gpg-agent 运行正常：

   ~ 
❯ systemctl --user status gpg-agent.socket
● gpg-agent.socket - GnuPG cryptographic agent and passphrase cache
     Loaded: loaded (/usr/lib/systemd/user/gpg-agent.socket; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2021-05-05 09:54:33 CST; 12h ago
   Triggers: ● gpg-agent.service
       Docs: man:gpg-agent(1)
     Listen: /run/user/1000/gnupg/S.gpg-agent (Stream)
     CGroup: /user.slice/user-1000.slice/[email protected]/app.slice/gpg-agent.socket

May 05 09:54:33 wudeng systemd[1297]: Listening on GnuPG cryptographic agent and passphrase cache.

Paru -- The New AUR Helper

ttyS3 — Mon, 05 Apr 2021 16:54:53 GMT

paru 是什么？

根据 paru 作者在 reddit 的描述

paru v1.0.0 and stepping away from yay
Last week I announced my new AUR helper paru.
Since then a lot of testing has gone in and a lot of bugs fixed by me and help from contributors.
So I am now announcing paru v1.0.0 and consider it stable.
I'd also like to mention I no longer plan to work on yay. I've been co-developing yay with jguer over the past 3 years. Most of the features and design being done by me.
I've had no motivation and no real involvement with the project for quite a while now. So I'm officially deciding to move on to something new.
Jguer is still there, so there's no need to panic and move away from yay. Just don't expect much new development on it.

所以， parau 的作者之前也是yay的共同开发者。yay 是采用 Golang 编写的 AUR helper, 而新的 paru 采用 Rust 实现。

changes from yay

paru 首个版本发布时，作者在release log 里描述了它与 yay 的区别。

Added

Added --nocheck
Added --develsuffixes
Added --installDebug
Added NoWarn
Added syntax highlighting to pkgbuild printing
Auto detection for pacman-git. Paru will build against pacman-git's API

Removed

Remove --timeupdate, --requestsplitn
Remove --save -Pg --Pd -Ps
Remove -Gf
Remove --cleanmenu
Remove -Y/--yay, stuff like --gendb still work even though they belonged to -Y

Changed

List based flags now append instead of overwriting existing settings
Packages are now cloned to ~/.cache/paru/clone by default
Use asp for repo pkgbuilds
Improve news printing
Formatting changes to be more pacman like
-Yc accounts for makedeps for aur packages
Devel info is now saved to devel.json
Devel info schema change
Sources are no longer downloaded in batch
Only treat packages matching develsuffixes as devel

如何安装paru

# archlinux cn repo users
sudo pacman -S paru

# other users
sudo pacman -S --needed base-devel
git clone https://aur.archlinux.org/paru.git
cd paru
makepkg -si

paru常用操作

paru : 相当于 paru -Syu （If no arguments are provided 'paru -Syu' will be performed）
paru <用户输入>：搜索并安装“用户输入”
paru -Sua：仅升级 AUR 包。
paru -Qua：打印可用的 AUR 更新
paru -Gc <用户输入>：显示“用户输入”的 AUR 评论

paru 配置

要在 paru 中启用颜色，你必须先在 pacman 中启用它。编辑 /etc/pacman.conf ，确保 Color 选项是打开的即可（老灯发现其实默认是打开的）。

paru的配置文件位于 /etc/paru.conf

paru 有个叫 BottomUp 的选项，打开之后，包的显示顺序会倒过来（比如原来排名第一的，会显示在最底部），这样做的理由是：优先级较高的包，通过倒序显示后，离 Prompt 最近了，也就是离我们视线的关注点最近了。

这个喜好与否，因人而异中以。

如果需要编辑 PKGBUILD，需要打开parau配置文件中的 FileManager 选项。安装 vifm ： sudo pacman -S vifm

然后配置：

[bin]
FileManager = vifm

老灯觉得这个配置项有点奇怪。

另外一点，与yay不同的是，对于 paru, 你所做的任何改变都将是永久性的，下次升级软件包时，你的改变将与上游软件包合并。

Refs

https://github.com/Morganamilo/paru

https://aur.archlinux.org/packages/paru/

https://github.com/Morganamilo/paru/releases/tag/v1.0.0

https://www.reddit.com/r/archlinux/comments/jjn1c1/paru_v100_and_stepping_away_from_yay/

https://www.reddit.com/r/archlinux/comments/jdyvyr/so_i_made_another_aur_helper_paru/

https://www.reddit.com/r/archlinux/comments/ju50j7/why_do_people_still_use_yay_instead_of_paru/

https://linux.cn/article-13122-1.html

https://itsfoss.com/paru-aur-helper/

Build Static Lib Package Under ArchLinux

ttyS3 — Mon, 05 Apr 2021 16:08:02 GMT

通常情况下，Arch 下的包不像 RHEL 系那样有单独的静态库 (RHEL系命名风格一般是 libXXX-static)，但并不是说Arch下面的包都没有静态库，这个得看情况。比如 /lib/libresolv.a， /lib/librt.a 属于 GNU libc （glibc包）, /lib/libstdc++.a 属于 gcc 包。

以 libgit2 包为例，ArchLinux 源里是没有提供静态库的。相对的, Ubuntu 有提供静态库的 package, 甚至连 ArlpineLinux 也有提供。 Fedora 下的 libgit2 好像没有静态lib。Ubuntu 是直接放在 libgit2-dev 包里（/usr/lib/x86_64-linux-gnu/libgit2.a）

由于Arch源里其实已经有libgit2了，因此我们对 PKGBUILD 文件作做修改即可编译相应的静态库。

首先我们安装 asp, 如果没有安装的话： sudo pacman -S --needed asp

然后获取Arch构建源码： asp checkout libgit2

修改之后执行 makepkg 即可。

如果不用asp, 也可以手动用git clone源码。

进入包页面 https://archlinux.org/packages/extra/x86_64/libgit2/ 然后点击 Source Files 即可查看源码。然后我们就跳到了 https://github.com/archlinux/svntogit-packages/tree/packages/libgit2/trunk

clone仓库然后 checkout 到 packages/libgit2/trunk 分支即可。（对于 Arch 这种用分支来存包源码的行为，老灯表示有点迷啊，可能跟它从svn转过来有关？）

原 PKGBUILD 文件如下：

# Maintainer: Lukas Fleischer <[email protected]>
# Contributor: David Runge <[email protected]>
# Contributor: Hilton Medeiros <[email protected]>
# Contributor: Dave Reisner <[email protected]>

pkgname=libgit2
pkgver=1.1.0
pkgrel=1
epoch=1
pkgdesc='A linkable library for Git'
arch=('x86_64')
url="https://libgit2.github.com/"
depends=('glibc' 'http-parser' 'openssl' 'pcre' 'zlib')
makedepends=('cmake' 'libssh2' 'python')
provides=('libgit2.so')
license=('GPL2')
source=("$pkgname-$pkgver.tar.gz::https://github.com/libgit2/libgit2/archive/v${pkgver}.tar.gz"
        "${pkgname}-0.99.0-remove_http-parse_incompatible_tests.patch")
sha512sums=('347bb68900181b44fa58a0417506c91383adb965607fce049a5b4c57ac9cc286e0a140d164c339b50fb6cd6951f47757c2917a2df44ba004bfaa4fb643946bb8'
            'e73072424c9c1870eaaf93b3451295ef7333b59f6cb8a6897dd690b69a20aaeb70f00d15a692c1d9e0745d5ef16bbbb912fbd570d8bc83ca0b7d57f32025bf94')
b2sums=('2a1c1f71d2a2e06448c78eb46028fdcfd59682dccf2365851c4bd059cdd78842320f9a5ba7345e761611a5b4eba634faf2e26cc669097da0ba2e1c832c23059f'
        'cdca2012f772afea99436faa02f80697dc9042a6eb5ae14f8ee8ba9e100a65b936cdfaf84ec0361543c70859375c823a25cfee52b0face40b8dea2ec2cf1de59')

prepare() {
  cd "$pkgname-$pkgver"
  # removing tests that are only compatible with the (modified) vendored
  # version of http-parser, but not with upstream http-parser
  patch -Np1 -i "../${pkgname}-0.99.0-remove_http-parse_incompatible_tests.patch"
}


build() {
  cd "$pkgname-$pkgver"
  cmake -DCMAKE_INSTALL_PREFIX=/usr \
        -DCMAKE_BUILD_TYPE='None' \
        -DUSE_HTTP_PARSER=system \
        -DTHREADSAFE=ON \
        -Wno-dev \
        -B build \
        -S .
  make -C build VERBOSE=1
}

check() {
  cd "$pkgname-$pkgver"
  make -C build test VERBOSE=1
}

package() {
  depends+=('libssh2.so')
  cd "$pkgname-$pkgver"
  make -C build DESTDIR="$pkgdir" install
  install -vDm 644 {AUTHORS,README.md} \
    -t "${pkgdir}/usr/share/doc/${pkgname}"
}

我们稍做修改：

diff --git a/trunk/PKGBUILD b/trunk/PKGBUILD
index 9192069..9eb6a7a 100644
--- a/trunk/PKGBUILD
+++ b/trunk/PKGBUILD
@@ -3,38 +3,41 @@
 # Contributor: Hilton Medeiros <[email protected]>
 # Contributor: Dave Reisner <[email protected]>
 
-pkgname=libgit2
+pkgname=libgit2-static
+srcname=libgit2
 pkgver=1.1.0
 pkgrel=1
 epoch=1
-pkgdesc='A linkable library for Git'
+pkgdesc='libgit2 static library for cross compile purpose'
 arch=('x86_64')
 url="https://libgit2.github.com/"
-depends=('glibc' 'http-parser' 'openssl' 'pcre' 'zlib')
-makedepends=('cmake' 'libssh2' 'python')
-provides=('libgit2.so')
+depends=('glibc' 'http-parser' 'pcre' 'zlib' 'libgit2')
+makedepends=('cmake' 'python')
+provides=('libgit2.a')
 license=('GPL2')
-source=("$pkgname-$pkgver.tar.gz::https://github.com/libgit2/libgit2/archive/v${pkgver}.tar.gz"
-        "${pkgname}-0.99.0-remove_http-parse_incompatible_tests.patch")
+source=("$srcname-$pkgver.tar.gz::https://github.com/libgit2/libgit2/archive/v${pkgver}.tar.gz"
+        "${srcname}-0.99.0-remove_http-parse_incompatible_tests.patch")
 sha512sums=('347bb68900181b44fa58a0417506c91383adb965607fce049a5b4c57ac9cc286e0a140d164c339b50fb6cd6951f47757c2917a2df44ba004bfaa4fb643946bb8'
             'e73072424c9c1870eaaf93b3451295ef7333b59f6cb8a6897dd690b69a20aaeb70f00d15a692c1d9e0745d5ef16bbbb912fbd570d8bc83ca0b7d57f32025bf94')
 b2sums=('2a1c1f71d2a2e06448c78eb46028fdcfd59682dccf2365851c4bd059cdd78842320f9a5ba7345e761611a5b4eba634faf2e26cc669097da0ba2e1c832c23059f'
         'cdca2012f772afea99436faa02f80697dc9042a6eb5ae14f8ee8ba9e100a65b936cdfaf84ec0361543c70859375c823a25cfee52b0face40b8dea2ec2cf1de59')
 
 prepare() {
-  cd "$pkgname-$pkgver"
+  cd "$srcname-$pkgver"
   # removing tests that are only compatible with the (modified) vendored
   # version of http-parser, but not with upstream http-parser
-  patch -Np1 -i "../${pkgname}-0.99.0-remove_http-parse_incompatible_tests.patch"
+  patch -Np1 -i "../${srcname}-0.99.0-remove_http-parse_incompatible_tests.patch"
 }
 
 
 build() {
-  cd "$pkgname-$pkgver"
+  cd "$srcname-$pkgver"
   cmake -DCMAKE_INSTALL_PREFIX=/usr \
         -DCMAKE_BUILD_TYPE='None' \
         -DUSE_HTTP_PARSER=system \
         -DTHREADSAFE=ON \
+        -DBUILD_SHARED_LIBS=OFF \
+        -DUSE_SSH=OFF \
         -Wno-dev \
         -B build \
         -S .
@@ -42,14 +45,11 @@ build() {
 }
 
 check() {
-  cd "$pkgname-$pkgver"
+  cd "$srcname-$pkgver"
   make -C build test VERBOSE=1
 }
 
 package() {
-  depends+=('libssh2.so')
-  cd "$pkgname-$pkgver"
-  make -C build DESTDIR="$pkgdir" install
-  install -vDm 644 {AUTHORS,README.md} \
-    -t "${pkgdir}/usr/share/doc/${pkgname}"
+  cd "$srcname-$pkgver"
+  install -vD -m755 ./build/libgit2.a $pkgdir/usr/lib/libgit2.a
 }

完整文件：

# Maintainer: Lukas Fleischer <[email protected]>
# Contributor: David Runge <[email protected]>
# Contributor: Hilton Medeiros <[email protected]>
# Contributor: Dave Reisner <[email protected]>

pkgname=libgit2-static
srcname=libgit2
pkgver=1.1.0
pkgrel=1
epoch=1
pkgdesc='libgit2 static library for cross compile purpose'
arch=('x86_64')
url="https://libgit2.github.com/"
depends=('glibc' 'http-parser' 'pcre' 'zlib' 'libgit2')
makedepends=('cmake' 'python')
provides=('libgit2.a')
license=('GPL2')
source=("$srcname-$pkgver.tar.gz::https://github.com/libgit2/libgit2/archive/v${pkgver}.tar.gz"
        "${srcname}-0.99.0-remove_http-parse_incompatible_tests.patch")
sha512sums=('347bb68900181b44fa58a0417506c91383adb965607fce049a5b4c57ac9cc286e0a140d164c339b50fb6cd6951f47757c2917a2df44ba004bfaa4fb643946bb8'
            'e73072424c9c1870eaaf93b3451295ef7333b59f6cb8a6897dd690b69a20aaeb70f00d15a692c1d9e0745d5ef16bbbb912fbd570d8bc83ca0b7d57f32025bf94')
b2sums=('2a1c1f71d2a2e06448c78eb46028fdcfd59682dccf2365851c4bd059cdd78842320f9a5ba7345e761611a5b4eba634faf2e26cc669097da0ba2e1c832c23059f'
        'cdca2012f772afea99436faa02f80697dc9042a6eb5ae14f8ee8ba9e100a65b936cdfaf84ec0361543c70859375c823a25cfee52b0face40b8dea2ec2cf1de59')

prepare() {
  cd "$srcname-$pkgver"
  # removing tests that are only compatible with the (modified) vendored
  # version of http-parser, but not with upstream http-parser
  patch -Np1 -i "../${srcname}-0.99.0-remove_http-parse_incompatible_tests.patch"
}


build() {
  cd "$srcname-$pkgver"
  cmake -DCMAKE_INSTALL_PREFIX=/usr \
        -DCMAKE_BUILD_TYPE='None' \
        -DUSE_HTTP_PARSER=system \
        -DTHREADSAFE=ON \
        -DBUILD_SHARED_LIBS=OFF \
        -DUSE_SSH=OFF \
        -Wno-dev \
        -B build \
        -S .
  make -C build VERBOSE=1
}

check() {
  cd "$srcname-$pkgver"
  make -C build test VERBOSE=1
}

package() {
  cd "$srcname-$pkgver"
  install -vD -m755 ./build/libgit2.a $pkgdir/usr/lib/libgit2.a
}

Refs

https://github.com/libgit2/libgit2

https://pkgs.alpinelinux.org/package/edge/community/x86_64/libgit2-static

https://packages.ubuntu.com/focal/amd64/libgit2-dev/filelist

https://wiki.archlinux.org/index.php/Arch_Build_System#Retrieve_PKGBUILD_source_using_Git

https://archlinux.org/packages/extra/x86_64/libgit2/

Neovim Vala Lsp Integration Tips

ttyS3 — Mon, 05 Apr 2021 15:03:31 GMT

The Issue

如果不是用到了一个叫 peek 的录屏软件，我可能没听过这个叫 vala 的语言，GNOME 搞出来的东西。

老灯日常用的 geary 邮件客户端和 peek 都是这个语言编写的。

老灯发现neovim 官方的 vala lang server 配置无法适用于 peek 这个项目。已经提交了 PR ( https://github.com/neovim/nvim-lspconfig/pull/789 ), 不过这个合并效率真是低，都两周了，还没动静，没给close 也没给merge.

neovim 官方的 vala lang server 配置甚至无法用于正常浏览 vala-language-server 的源码。

git clone https://github.com/benwaffle/vala-language-server
cd vala-language-server
nvim

然后我们在 neovim 中打开 src/server.vala，然后 neovim lsp 会在src目录下找到一个“假”的meson.build文件（真正的 meson.build 文件在项目根目录下），根据 vala lang server 的逻辑，它会在这个“project root"(假的）下面执行 meson build，很明显这个命令会失败，因为这个不是真正的 meson.build 文件，而只是一个被根目录下的 meson.build 文件包含进来的 include 文件 (姑且这么说吧，你 get 到意思就行)。然后 vala lang server 就报错了（实际上它输出的是 meson 的 stderr 错误信息）：

ERROR: First statement must be a call to project

The Solution

根据 meson 的报错信息，我们知道，meson.build 文件的第一行有效指令一定是 a call to project.

这里老灯用的有效指令，其实主要是指排除comment. a call to project 即调用 project()

在官方没合并老灯的 PR 前，只能手动在配置那里hack了：

-- https://github.com/neovim/nvim-lspconfig/blob/master/CONFIG.md#vala_ls
local meson_matcher = function (path)
  local pattern = "meson.build"
  local f = vim.fn.glob(util.path.join(path, pattern))
  if f == '' then
    return nil
  end
  for line in io.lines(f) do
    -- skip meson comments
    if not line:match('^%s*#.*') then
      local str = line:gsub('%s+', '')
      if str ~= '' then
        if str:match('^project%(') then
          return path
        else
          break
        end
      end
    end
  end
end

lsp.vala_ls.setup({
  on_attach = mix_attach,
  capabilities = lsp_status.capabilities,
  cmd = {'vala-language-server'},
  root_dir = function (fname)
    local root = util.search_ancestors(fname, meson_matcher)
    return root or util.find_git_ancestor(fname)
  end,
})

ps: 关于上面配置里的 mix_attach 和 lsp_status 请参考老灯之前写的《Neovim C Cpp Lsp Integration Tips》

这里主要是告诉 neovim lsp, 要怎么确定这个 project root, 所谓的 project root, neovim lsp config 的逻辑是，

先找到项目的 meson.build 文件, 该文件所在目录，即project root，否则，就尝试找 git 仓库.

这里我们简单地给查找 meson.build 文件的方法 hack 了一下，跳过评论并且去除行两端的空格后，我们简单地判断此行是否以project(开头，即可过滤掉那些假的 meson.build 文件

其实 neovim lsp config 这个判断方法也只是针对大部分情况。但是老灯觉得，对于大部分情况已经 OK 了，毕竟，作为一个公共配置，它无法兼顾所有情况。

根据 GNOME 官方说明：meson 是 Vala 主要的构建系统。

Meson - a front end to the Ninja build system with Vala support (The main build system for Vala)

因此，只判断meson.build 文件，对于大部分 Vala 项目来说应该是 OK 的

Refs

https://github.com/benwaffle/vala-language-server

https://wiki.gnome.org/Projects/Vala/Tools

https://mesonbuild.com/Syntax.html#comments

https://github.com/phw/peek

https://gitlab.gnome.org/GNOME/geary

https://github.com/benwaffle/vala-language-server

Neovim C Cpp Lsp Integration Tips

ttyS3 — Mon, 05 Apr 2021 13:40:34 GMT

本文主要按 neovim lsp 来讲的，但是其中关于 lang server 的很多东西，其实是通用的。简单在此记录，备忘。

common lsp config

一般除了跳转定义，老灯还启用了 completion 自动完成以及 lsp-status 用于状态显示。

这里定义了一个公用的 mix_attach 用于lsp on_attach 事件

local lsp_status = require('lsp-status')
lsp_status.register_progress()
lsp_status.config({
    indicator_errors = "❌",
    indicator_warnings = "⚠️ ",
    indicator_info = "ℹ️ ",
    -- https://emojipedia.org/tips/
    indicator_hint = "💡",
    indicator_ok = "✅",
})

local cmp = require'completion'

--@param client: (required, vim.lsp.client)
local mix_attach = function(client)
  lsp_status.on_attach(client)
  cmp.on_attach(client)
end

neovim clangd lsp setup

clangd 的配置，主要参考 nvim-lspconfig 文档

注意这里对 handlers 的配置参考了 lsp-status 的示例文档，

-- https://clangd.llvm.org/features.html
lsp.clangd.setup({
  handlers = lsp_status.extensions.clangd.setup(),
  init_options = {
    clangdFileStatus = true
  },
  on_attach = mix_attach,
  capabilities = lsp_status.capabilities
})

项目配置 -- 支持clangd

lsp 配置实际上比较简单，实际使用中，遇到问题的主要是关于如何让 lang server ( clangd 或 ccls ) 找到那些头文件。

To understand your source code, clangd needs to know your build flags. (This is just a fact of life in C++, source files are not self-contained).
By default, clangd will assume your code is built as clang some_file.cc, and you’ll probably get spurious errors about missing #included files, etc. There are a couple of ways to fix this.

主要原因在于，C 和 C++ 这俩语言比较古老，不像 Rust 或 Golang 那样自带包管理，因此需要外部工具来帮助 lang server 理解代码。对于 clangd 来说，主要有两种解决办法：

1. compile_commands.json 法

This file provides compile commands for every source file in a project. It is usually generated by tools. Clangd will look in the parent directories of the files you edit looking for it.

虽然 clangd 的文档里说 clangd 会在你所编辑的文件的父目录中查找 compile_commands.json，但实际使用中老灯发现能自动加载 build/compile_commands.json 文件，不知道是 neovim hack了还是 clangd 本身支持？

没时间细纠了，先这样吧。如果谁知道答案麻烦告知一下。

1.1 基于 CMake 的项目

这里又分两种情况，对于基于 CMake 的项目，只需要启用 CMAKE_EXPORT_COMPILE_COMMANDS 即可自动生成 compile_commands.json 文件。

启用 CMAKE_EXPORT_COMPILE_COMMANDS的方法主要有两种：

一是直接在命令行参数中指定，比如：

cmake -B build -DCMAKE_EXPORT_COMPILE_COMMANDS=1 .
# or
# cmake -S . -B build -DCMAKE_EXPORT_COMPILE_COMMANDS=1

二是在 CMakeLists.txt 中添加：

set(CMAKE_EXPORT_COMPILE_COMMANDS ON)

1.2 基于其它构建系统的项目

对于其它构建系统（主要是一些上古的 Makefile 类项目），要生成 compile_commands.json 需要用到一个叫 Bear 的工具。

Bear is a tool that generates a compilation database for clang tooling.
The JSON compilation database is used in the clang project to provide information on how a single compilation unit is processed. With this, it is easy to re-run the compilation with alternate programs.
One way to get a compilation database is to use cmake as the build tool. Passing -DCMAKE_EXPORT_COMPILE_COMMANDS=ON to cmake generates the compile_commands.json file into the current directory.
For non-cmake projects, Bear generates the JSON file during the build process.

Bear 的用法比较简单，直接在构建命令前面加bear 即可，如： bear make -j14

Bear 安装：

# fedora
sudo dnf install -y bear
# ubuntu
sudo apt-get install -y bear
# archlinux cn
sudo pacman -S bear
# archlinux aur
paru -S bear

除了 Bear, 还有其它工具也能生成 compile_commands.json：

ninja build 也支持生成，如：

# Format: ninja -t compdb rule_names... > compile_commands.json
ninja -C out/Release -t compdb cxx cc > compile_commands.json

meson会自动生成：

meson build # generates compile_commands.json in the `build` directory

https://github.com/nickdiego/compiledb (基于python)

https://github.com/rizsotto/scan-build (python版，基于libear, uses Bear as a backend)

2. compile_flags.txt 法

If all files in a project use the same build flags, you can put those flags one-per-line in compile_flags.txt in your source root.
Clangd will assume the compile command is clang $FLAGS some_file.cc.
Creating this file by hand is a reasonable place to start if your project is quite simple.

compile_flags.txt 法主要是针对于项目中的所有文件都使用相同的 build flags 的情况。这个时候，你可以手撸一个 compile_flags.txt 来帮助 clangd 理解你的代码。

For simple projects, Clang tools also recognize a compile_flags.txt file. This should contain one argument per line. The same flags will be used to compile any file.

需要注意的是，This should contain one argument per line.

例如：

-xc++
-I
libwidget/include/

这里 -I libwidget/include 是两个参数，因此要各放一行（ one argument per line ）。

如果是相对路径，则该路径相对于 compile_flags.txt 文件所在目录。

neovim ccls lsp setup

一般情况下使用clangd 即可了，没有必要配置两个lang server.

如果由于某些原因需要使用 ccls 的，老灯这里也说一下。

https://mesonbuild.com/配置部分比较简单，主要是参考 nvim-lspconfig 关于 ccls 的文档

-- https://github.com/neovim/nvim-lspconfig/blob/master/CONFIG.md#ccls
-- https://github.com/MaskRay/ccls/wiki
lsp.ccls.setup {
  init_options = {
	  compilationDatabaseDirectory = "build";
    index = {
      threads = 0;
    };
    clang = {
      excludeArgs = { "-frounding-math"} ;
    };
  }
}

项目配置 -- 支持ccls

根据ccls wiki:

ccls typically indexes an entire project. In order for this to work properly, ccls needs to be able to obtain the source file list and their compilation command lines.
There are two main ways this happens:
Provide compile_commands.json at the project root
Provide a .ccls file. It is a line-based text file describing compiler flags. Recursively listed source files (headers excluded) will be indexed. Use an empty .ccls to get started (if you don't need specific -I, -D, etc).
If neither exists, then when ccls starts it will not index anything: instead it will wait for LSP clients to open files and index only those files.

注意 ccls 只会在 project root 搜索 compile_commands.json文件。

If your compile_commands.json is not kept in the project root, set the initialization option compilationDatabaseDirectory to an alternative directory containing compile_commands.json.

因此前面我们的 neovim lsp 配置的时候，指定了 init_options.compilationDatabaseDirectory = "build"

第一种方法直接参考前面 clangd 部分。

第二种方法，参考ccls wiki: https://github.com/MaskRay/ccls/wiki/Project-Setup#ccls-file

Refs

https://github.com/neovim/nvim-lspconfig/blob/master/CONFIG.md#ccls

https://github.com/neovim/nvim-lspconfig/blob/master/CONFIG.md#clangd

https://github.com/nvim-lua/lsp-status.nvim#example-use

https://clangd.llvm.org/installation.html#project-setup

https://clangd.llvm.org/extensions.html#switch-between-sourceheader

https://github.com/MaskRay/ccls/wiki/Project-Setup

https://github.com/MaskRay/ccls/wiki

https://cmake.org/cmake/help/latest/variable/CMAKE_EXPORT_COMPILE_COMMANDS.html

https://clang.llvm.org/docs/JSONCompilationDatabase.html

https://github.com/rizsotto/Bear

http://ninja-build.org/

https://mesonbuild.com/

Rust 交叉编译 OSX 二进制失败原因分析

ttyS3 — Sat, 03 Apr 2021 15:05:06 GMT

缘由

起因还是在ArchLinux下交叉编译 git-cz OSX 二进制失败。

这个问题老灯折腾了很久，搞得几乎都要放弃了。

因为在 Linux 下交叉编译 darwin 平台的教程并不太多，能找到的资料也不尽是相同或相似的问题。

但老灯之前在 Fedora 33 及 Ubuntu 21.04 beta 下都能成功编译，因此，这个周末正好有时间，还是坚持分析了一下原因。

问题描述

git-cz 依赖 libgit2 的 rust 绑定库（ https://github.com/rust-lang/git2-rs ），C 绑定部分代码是里面的子包 libgit2-sys ( https://crates.io/crates/libgit2-sys ) , 因此最后链接阶段，在交叉编译时，肯定是要链接 libgit2 的静态库的（交叉编译时一般都是静态链接，如果动态链接会很麻烦。比如golang也是，且 golang 在交叉编译时甚至是直接默认关闭 cgo 的）

在编译完成最后的link阶段报错：

Compiling git2 v0.13.17 error: linking with /usr/local/darwin-ndk-x86_64/bin/x86_64-apple-darwin20.4-clang failed: exit code: 1

cargo 加上 --verbose 参数后，得到如下信息：

= note: ld: library not found for -lgit2 clang-11: error: linker command failed with exit code 1 (use -v to see invocation)

以老灯的经验判断，应该是链接的时候没有找到 libgit2 的静态库。

但是这个库应该跟 ArchLinux 系统的静态库没有关系。因为 Linux 的二进制文件是 ELF 格式的，而不是苹果的Mach-O 64-bit x86_64.

pkg-config-rs 和 cc-rs

于是老灯去查看了一下 libgit2-sys 的源码，发现其实它是会自动编译 libgit2 的，并且它的Build-Dependencies 依赖有 https://crates.io/crates/pkg-config 和 https://crates.io/crates/cc

关于 pkg-config-rs 和 cc-rs 支持的环境变量配置，这里老灯直接把官方文档里的摘抄过来，老灯觉得这里的描述几乎全部是重要的。

我们看下pkg-config-rs的介绍：

A simple library meant to be used as a build dependency with Cargo packages in order to use the system pkg-config tool (if available) to determine where a library is located.

External configuration via target-scoped environment variables

In cross-compilation context, it is useful to manage separately PKG_CONFIG_PATH and a few other variables for the host and the target platform.

The supported variables are: PKG_CONFIG_PATH, PKG_CONFIG_LIBDIR, and PKG_CONFIG_SYSROOT_DIR.

Each of these variables can also be supplied with certain prefixes and suffixes, in the following prioritized order:

<var>_<target> - for example, PKG_CONFIG_PATH_x86_64-unknown-linux-gnu
<var>_<target_with_underscores> - for example, PKG_CONFIG_PATH_x86_64_unknown_linux_gnu
<build-kind>_<var> - for example, HOST_PKG_CONFIG_PATH or TARGET_PKG_CONFIG_PATH
<var> - a plain PKG_CONFIG_PATH

This crate will allow pkg-config to be used in cross-compilation if PKG_CONFIG_SYSROOT_DIR or PKG_CONFIG is set. You can set PKG_CONFIG_ALLOW_CROSS=1 to bypass the compatibility check, but please note that enabling use of pkg-config in cross-compilation without appropriate sysroot and search paths set is likely to break builds.
Some Rust sys crates support building vendored libraries from source, which may be a work around for lack of cross-compilation support in pkg-config.

这里最关键的是后面那段话。

如果设置了PKG_CONFIG_SYSROOT_DIR或PKG_CONFIG，则此crate将允许pkg-config用于交叉编译。您可以设置PKG_CONFIG_ALLOW_CROSS=1 以绕过兼容性检查，但是请注意，在没有适当的sysroot和搜索路径设置的情况下，在交叉编译中启用pkg-config可能会破坏构建。

一些Rust sys crates支持从源码构建vendor库，这可能是由于pkg-config缺乏交叉编译支持而采用的变通方案。

libgit2-sys 就属于那种支持从源码构建vendor库的sys crate, 构建过程中它会自动 clone libgit2 的源码然后编译成静态lib.

cc-rs 的介绍是：

A build-time dependency for Cargo build scripts to assist in invoking the native C compiler to compile native C code into a static archive to be linked into Rust code.

External configuration via environment variables

To control the programs and flags used for building, the builder can set a number of different environment variables.

CFLAGS - a series of space separated flags passed to compilers. Note that individual flags cannot currently contain spaces, so doing something like: -L=foo\ bar is not possible.
CC - the actual C compiler used. Note that this is used as an exact executable name, so (for example) no extra flags can be passed inside this variable, and the builder must ensure that there aren't any trailing spaces. This compiler must understand the -c flag. For certain TARGETs, it also is assumed to know about other flags (most common is -fPIC).
AR - the ar (archiver) executable to use to build the static library.
CRATE_CC_NO_DEFAULTS - the default compiler flags may cause conflicts in some cross compiling scenarios. Setting this variable will disable the generation of default compiler flags.
CXX... - see C++ Support.

Each of these variables can also be supplied with certain prefixes and suffixes, in the following prioritized order:

<var>_<target> - for example, CC_x86_64-unknown-linux-gnu
<var>_<target_with_underscores> - for example, CC_x86_64_unknown_linux_gnu
<build-kind>_<var> - for example, HOST_CC or TARGET_CFLAGS
<var> - a plain CC, AR as above.

If none of these variables exist, cc-rs uses built-in defaults

In addition to the above optional environment variables, cc-rs has some functions with hard requirements on some variables supplied by cargo's build-script driver that it has the TARGET, OUT_DIR, OPT_LEVEL, and HOST variables.

在交叉编译时，为了让编译出来的目标文件是我们需要的，我们一定要设置 CC 和 CXX ，如果在全局设置，比如设置在 .zshrc 文件中的话，那么，直接用 CC 肯定是不行，因为大部分 Makefile 也用到这的环境变量，这会破坏整个系统的构建。关于这一点， cc-rs 早就想到了，允许以 <var>_<target> 或 <var>_<target_with_underscores> 的方式按 target 来设置。比如这里我们要的是 x86_64-apple-darwin，则设置 CC_x86_64-apple-darwin 就OK了，如果觉得下划线+连接符的方式别扭，也可以用 CC_x86_64_apple_darwin

ok, 文档了解得差不多了，我们再回过头来看问题。

问题解决过程

事实上我遇到这个问题的时候，并没有看这些文档，如果早看到上面这些文档，可能问题会得到更快的解决。

我采用的解决办法是，写一个最小化的 demo, 分别在能成功交叉编译出darwin二进制的机器和不能成功编译的机器执行，并记录详细的编译命令到日志，然后用对比工具对比二者在编译过程的命令差异。

这个方法确实有点笨，但是确实有效发现并解决了问题。

cargo new libgit2-demo

main.rs 内容如下：

use git2::Repository;

fn main() {
    let repo = match Repository::init("/tmp/hello.git") {
        Ok(repo) => repo,
        Err(e) => panic!("failed to init: {}", e),
    };

    println!("success init repo");
}

Cargo.toml 内容如下：

[package]
name = "libgit2-demo"
version = "0.1.0"
authors = ["荒野無燈 <*@ttys3.dev>"]
edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
git2 = { version = "0.13.17", default-features = false, features = [] }

Makefile 如下：

.PHONY: all clean darwin

all: darwin

darwin: export PKG_CONFIG_ALLOW_CROSS=1
darwin: export CC=o64-clang
darwin: export CXX=o64-clang++
darwin: export LIBZ_SYS_STATIC=1
darwin:
    PATH=/usr/local/darwin-ndk-x86_64/bin:$$PATH \
         cargo build --target=x86_64-apple-darwin --release --verbose 2>&1 | tee arch.log

clean:
    cargo clean

测试环境分别是 Ubuntu 21.04 beta 和 ArchLinux, 机器 CPU 分别是 9代 Intel 和 8代 Intel.

通过对比生成的日志文件 ok.log 和 arch.log, 发现在构建执行 rustc --crate-name libgit2_sys ... 时有个明显的差异。

ok.log

 Running `rustc --crate-name libgit2_sys --edition=2018 /home/ttys3/.cargo/registry/src/mirrors.sjtug.sjtu.edu.cn-4f7dbcce21e258a2/libgit2-sys-0.12.18+1.1.0/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no -C metadata=177d6c810f4d7b82 -C extra-filename=-177d6c810f4d7b82 --out-dir /home/ttys3/repo/rust/libgit2-demo/target/x86_64-apple-darwin/release/deps --target x86_64-apple-darwin -C linker=/usr/local/darwin-ndk-x86_64/bin/x86_64-apple-darwin20.4-clang -L dependency=/home/ttys3/repo/rust/libgit2-demo/target/x86_64-apple-darwin/release/deps -L dependency=/home/ttys3/repo/rust/libgit2-demo/target/release/deps --extern libc=/home/ttys3/repo/rust/libgit2-demo/target/x86_64-apple-darwin/release/deps/liblibc-d39c361e04f43fde.rmeta --extern libz_sys=/home/ttys3/repo/rust/libgit2-demo/target/x86_64-apple-darwin/release/deps/liblibz_sys-87e6342ea6338869.rmeta --cap-lints allow -L native=/home/ttys3/repo/rust/libgit2-demo/target/x86_64-apple-darwin/release/build/libgit2-sys-8d26052ab24e9383/out/build -l static=git2 -l iconv -l framework=Security -l framework=CoreFoundation -L native=/home/ttys3/repo/rust/libgit2-demo/target/x86_64-apple-darwin/release/build/libz-sys-cffd7e6d65b74042/out/build`

arch.log

Running `rustc --crate-name libgit2_sys --edition=2018 /home/ttys3/.cargo/registry/src/mirrors.sjtug.sjtu.edu.cn-4f7dbcce21e258a2/libgit2-sys-0.12.18+1.1.0/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no -C metadata=177d6c810f4d7b82 -C extra-filename=-177d6c810f4d7b82 --out-dir /home/ttys3/repo/rust/libgit2-demo/target/x86_64-apple-darwin/release/deps --target x86_64-apple-darwin -C linker=/usr/local/darwin-ndk-x86_64/bin/x86_64-apple-darwin20.4-clang -L dependency=/home/ttys3/repo/rust/libgit2-demo/target/x86_64-apple-darwin/release/deps -L dependency=/home/ttys3/repo/rust/libgit2-demo/target/release/deps --extern libc=/home/ttys3/repo/rust/libgit2-demo/target/x86_64-apple-darwin/release/deps/liblibc-d39c361e04f43fde.rmeta --extern libz_sys=/home/ttys3/repo/rust/libgit2-demo/target/x86_64-apple-darwin/release/deps/liblibz_sys-87e6342ea6338869.rmeta --cap-lints allow -L native=/usr/lib -l git2 -L native=/home/ttys3/repo/rust/libgit2-demo/target/x86_64-apple-darwin/release/build/libz-sys-cffd7e6d65b74042/out/build`

这一行太长，直接这样看肯定是很难一眼分辨的，因此借助 beyond compare:

可以很快发现关键区别：

arch.log:
-L native=/usr/lib -l git2

ok.log:
-L native=/home/ttys3/repo/rust/libgit2-demo/target/x86_64-apple-darwin/release/build/libgit2-sys-8d26052ab24e9383/out/build -l static=git2 -l iconv -l framework=Security -l framework=CoreFoundation

可以看到，链接出错的机器，native库的路径不是 libgit2-sys 通过 Darwin toolchain 生成的lib路径，而是使用了系统库的路径（-L native=/usr/lib），然后 libgit2 也没有使用静态链接，而是动态的（-l git2）。

而正常编译的机器，则是静态链接（-l static=git2）且静态库的路径指向正确（-L native=/home/ttys3/repo/rust/libgit2-demo/target/x86_64-apple-darwin/release/build/libgit2-sys-8d26052ab24e9383/out/build）

我们看下正常的目录结构：

❯ lsd --tree --depth=2 /home/ttys3/repo/rust/libgit2-demo/target/x86_64-apple-darwin/release/build/libgit2-sys-8d26052ab24e9383/out/build/
 build
├──  libgit2
│  ├──  deps
│  └──  src
└──  libgit2.a

如果再查看 /home/ttys3/repo/rust/libgit2-demo/target/x86_64-apple-darwin/release/build/libgit2-sys-8d26052ab24e9383/out/build/libgit2/deps 会发现，连依赖都是自带编译的：

 deps
├──  http-parser
└──  pcre

问题产生的真正原因

那么在 ArchLinux 下面为什么就编译失败了呢？难道是因为系统已经存在库了？

一查果然发现，老灯在通过pacman安装 starship 的时候自动安装了 libgit2 的动态库。

❯ pacman -Qo /usr/lib/libgit2.so
/usr/lib/libgit2.so is owned by libgit2 1:1.1.0-1
❯ sudo pacman -R libgit2
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: removing libgit2 breaks dependency 'libgit2.so=1.1-64' required by starship

然后一查 Ubuntu 21.04 beta那边，根本就没有安装这个库。

于是老灯直接卸载了 starship 和 libgit2，发现果然能成功通过编译了。

问题到这里，好像已经解决了？

不行，这只是work around, 不是solution.

注意到前面我们提到 pkg-config-rs 文档中说的 PKG_CONFIG_ALLOW_CROSS=1 在没有恰当地设置的情况下使用，会容易引出链接问题。没错，这次的问题其实就是Makefile中这一句 export PKG_CONFIG_ALLOW_CROSS=1引起的，移除这一行，问题成功解决。

也就是说，指定 PKG_CONFIG_ALLOW_CROSS=1 时，pkg-config-rs 会在交叉编译时也启用 pkg-config, 而在没有指定交叉编译的target的 pkg-config 路径时， rust 就使用直接了系统(host) 的 pkg-config path了，这个在ArchLinux下面是 /usr/lib/pkgconfig，那么凡是这里能找到的库，它都不会再进行编译了。因此这里出问题时，libgit2-sys实际上没有编译而是直接使用了系统的libgit2.so文件，而这个文件因为是Linux ELF格式的，并不能被交叉编译器所使用。

如果真的要在交叉编译时启用 pkg-config，则应该指定 /usr/local/darwin-ndk-x86_64/bin/x86_64-apple-darwin20.4-pkg-config，这个在pkg-config-rs中可以通过环境变量PKG_CONFIG来设置。PKG_CONFIG_PATH 倒是可以设置。

环境变量PKG_CONFIG_PATH是用来设置.pc文件的搜索路径的，pkg-config按照设置路径的先后顺序进行搜索，直到找到指定的.pc 文件为止。

用于指定 pkg-config可执行文件环境变量PKG_CONFIG相关代码：

let exe = self
            .env_var_os("PKG_CONFIG")
            .unwrap_or_else(|| OsString::from("pkg-config"));

PKG_CONFIG_ALLOW_CROSS 相关代码：

/// Represents all reasons `pkg-config` might not succeed or be run at all.
#[derive(Debug)]
pub enum Error {
    /// Aborted because of `*_NO_PKG_CONFIG` environment variable.
    ///
    /// Contains the name of the responsible environment variable.
    EnvNoPkgConfig(String),

    /// Detected cross compilation without a custom sysroot.
    ///
    /// Ignore the error with `PKG_CONFIG_ALLOW_CROSS=1`,
    /// which may let `pkg-config` select libraries
    /// for the host's architecture instead of the target's.
    CrossCompilation,

    /// Failed to run `pkg-config`.
    ///
    /// Contains the command and the cause.
    Command { command: String, cause: io::Error },

    /// `pkg-config` did not exit sucessfully.
    ///
    /// Contains the command and output.
    Failure { command: String, output: Output },

    #[doc(hidden)]
    // please don't match on this, we're likely to add more variants over time
    __Nonexhaustive,
}


/// Run `pkg-config` to find the library `name`.
    ///
    /// This will use all configuration previously set to specify how
    /// `pkg-config` is run.
    pub fn probe(&self, name: &str) -> Result<Library, Error> {
        let abort_var_name = format!("{}_NO_PKG_CONFIG", envify(name));
        if self.env_var_os(&abort_var_name).is_some() {
            return Err(Error::EnvNoPkgConfig(abort_var_name));
        } else if !self.target_supported() {
            return Err(Error::CrossCompilation);
        }

        let mut library = Library::new();

        let output = run(self.command(name, &["--libs", "--cflags"]))?;
        library.parse_libs_cflags(name, &output, self);

        let output = run(self.command(name, &["--modversion"]))?;
        library.parse_modversion(str::from_utf8(&output).unwrap());

        Ok(library)
    }

    pub fn target_supported(&self) -> bool {
        let target = env::var_os("TARGET").unwrap_or_default();
        let host = env::var_os("HOST").unwrap_or_default();

        // Only use pkg-config in host == target situations by default (allowing an
        // override).
        if host == target {
            return true;
        }

        // pkg-config may not be aware of cross-compilation, and require
        // a wrapper script that sets up platform-specific prefixes.
        match self.targetted_env_var("PKG_CONFIG_ALLOW_CROSS") {
            // don't use pkg-config if explicitly disabled
            Some(ref val) if val == "0" => false,
            Some(_) => true,
            None => {
                // if not disabled, and pkg-config is customized,
                // then assume it's prepared for cross-compilation
                self.targetted_env_var("PKG_CONFIG").is_some()
                    || self.targetted_env_var("PKG_CONFIG_SYSROOT_DIR").is_some()
            }
        }
    }

    fn targetted_env_var(&self, var_base: &str) -> Option<OsString> {
        match (env::var("TARGET"), env::var("HOST")) {
            (Ok(target), Ok(host)) => {
                let kind = if host == target { "HOST" } else { "TARGET" };
                let target_u = target.replace("-", "_");

                self.env_var_os(&format!("{}_{}", var_base, target))
                    .or_else(|| self.env_var_os(&format!("{}_{}", var_base, target_u)))
                    .or_else(|| self.env_var_os(&format!("{}_{}", kind, var_base)))
                    .or_else(|| self.env_var_os(var_base))
            }
            (Err(env::VarError::NotPresent), _) | (_, Err(env::VarError::NotPresent)) => {
                self.env_var_os(var_base)
            }
            (Err(env::VarError::NotUnicode(s)), _) | (_, Err(env::VarError::NotUnicode(s))) => {
                panic!(
                    "HOST or TARGET environment variable is not valid unicode: {:?}",
                    s
                )
            }
        }
    }

也就是说，如果你配置了 PKG_CONFIG_ALLOW_CROSS=1 则不管三七二十一，直接不其它加判断，给你使用pkg-config 来找库, 即使在交叉编译到Mac时找到的库是是Linux 格式的。

probe() 通过调用 pkg-config （pkg-config可执行文件路径可通过环境变量配置）来获取include 头包含路径信息和链接库路径信息。

对于我们的例子来说，如果设置了 LIBGIT2_NO_PKG_CONFIG=1 或 target被判断为不支持pkg-config (交叉编译的情况下，不做任何配置则默认是不支持）就直接不使用pkg-config了。否则就使用pkg-config去找头文件和库.

targetted_env_var() 用于支持带 target 的环境变量，同时会默认回退到不带 target 的环境变量。比如 target 是 x86_64-apple-darwin 时，会先后尝试：

PKG_CONFIG_ALLOW_CROSS_x86_64-apple-darwin
PKG_CONFIG_ALLOW_CROSS_x86_64_apple_darwin
TARGET_PKG_CONFIG_ALLOW_CROSS (非交叉编译时为 HOST_PKG_CONFIG_ALLOW_CROSS)
PKG_CONFIG_ALLOW_CROSS

关于是否使用静态链接

我们看下 libgit2-sys 的 build.rs 构建脚本

    let https = env::var("CARGO_FEATURE_HTTPS").is_ok();
    let ssh = env::var("CARGO_FEATURE_SSH").is_ok();
    let zlib_ng_compat = env::var("CARGO_FEATURE_ZLIB_NG_COMPAT").is_ok();

    // To use zlib-ng in zlib-compat mode, we have to build libgit2 ourselves.
    if !zlib_ng_compat {
        // 由于老灯并没有设置 CARGO_FEATURE_ZLIB_NG_COMPAT
        // 因此会执行到这里来
        let mut cfg = pkg_config::Config::new();
        // 老灯错误地启用了 PKG_CONFIG_ALLOW_CROSS=1 导致 pkg-config-rs 
        // 错误地返回了 Linux 系统的 libgit2 库
        if let Ok(lib) = cfg.atleast_version("1.1.0").probe("libgit2") {
            for include in &lib.include_paths {
                println!("cargo:root={}", include.display());
            }
            return;
        }
    }

可以看到 pkg_config::Config::new() 使用了 pkg-config-rs 的默认配置，我们看下默认配置是什么样的：

/// Creates a new set of configuration options which are all initially set
    /// to "blank".
    pub fn new() -> Config {
        Config {
            statik: None,
            min_version: Bound::Unbounded,
            max_version: Bound::Unbounded,
            extra_args: vec![],
            print_system_cflags: true,
            print_system_libs: true,
            cargo_metadata: true,
            env_metadata: true,
        }
    }

没错，默认是 statik: None 也就是默认是动态链接的。

那那些 static 连接参数是怎么生成的呢？

is_static() 先判断配置，如果配置是 false, 则会继续进行 infer 推断. 以libgit2 为例：

若 LIBGIT2_STATIC=1 则启用静态

若 LIBGIT2_DYNAMIC=1 则启用动态

若 PKG_CONFIG_ALL_STATIC=1 则启用静态

若 PKG_CONFIG_ALL_DYNAMIC=1 则启用动态

    fn is_static(&self, name: &str) -> bool {
        self.statik.unwrap_or_else(|| self.infer_static(name))
    }

    fn infer_static(&self, name: &str) -> bool {
        let name = envify(name);
        if self.env_var_os(&format!("{}_STATIC", name)).is_some() {
            true
        } else if self.env_var_os(&format!("{}_DYNAMIC", name)).is_some() {
            false
        } else if self.env_var_os("PKG_CONFIG_ALL_STATIC").is_some() {
            true
        } else if self.env_var_os("PKG_CONFIG_ALL_DYNAMIC").is_some() {
            false
        } else {
            false
        }
    }

执行pkg-config 的时候会根据 is_static() 的结果传递 --static 参数给pkg-config：

    fn command(&self, name: &str, args: &[&str]) -> Command {
        let exe = self
            .env_var_os("PKG_CONFIG")
            .unwrap_or_else(|| OsString::from("pkg-config"));
        let mut cmd = Command::new(exe);
        if self.is_static(name) {
            cmd.arg("--static");
        }
        cmd.args(args).args(&self.extra_args);
        // ... 
  }

最终生成的是 rustc-link-lib=static=xxxx ：

    fn parse_libs_cflags(&mut self, name: &str, output: &[u8], config: &Config) {
        let mut is_msvc = false;
        if let Ok(target) = env::var("TARGET") {
            if target.contains("msvc") {
                is_msvc = true;
            }
        }

        let system_roots = if cfg!(target_os = "macos") {
            vec![PathBuf::from("/Library"), PathBuf::from("/System")]
        } else {
            let sysroot = config
                .env_var_os("PKG_CONFIG_SYSROOT_DIR")
                .or_else(|| config.env_var_os("SYSROOT"))
                .map(PathBuf::from);

            if cfg!(target_os = "windows") {
                if let Some(sysroot) = sysroot {
                    vec![sysroot]
                } else {
                    vec![]
                }
            } else {
                vec![sysroot.unwrap_or_else(|| PathBuf::from("/usr"))]
            }
        };

        let mut dirs = Vec::new();
        let statik = config.is_static(name);

        let words = split_flags(output);

        // Handle single-character arguments like `-I/usr/include`
        let parts = words
            .iter()
            .filter(|l| l.len() > 2)
            .map(|arg| (&arg[0..2], &arg[2..]));
        for (flag, val) in parts {
            match flag {
                "-L" => {
                    let meta = format!("rustc-link-search=native={}", val);
                    config.print_metadata(&meta);
                    dirs.push(PathBuf::from(val));
                    self.link_paths.push(PathBuf::from(val));
                }
                "-F" => {
                    let meta = format!("rustc-link-search=framework={}", val);
                    config.print_metadata(&meta);
                    self.framework_paths.push(PathBuf::from(val));
                }
                "-I" => {
                    self.include_paths.push(PathBuf::from(val));
                }
                "-l" => {
                    // These are provided by the CRT with MSVC
                    if is_msvc && ["m", "c", "pthread"].contains(&val) {
                        continue;
                    }

                    if statik && is_static_available(val, &system_roots, &dirs) {
                        let meta = format!("rustc-link-lib=static={}", val);
                        config.print_metadata(&meta);
                    } else {
                        let meta = format!("rustc-link-lib={}", val);
                        config.print_metadata(&meta);
                    }

                    self.libs.push(val.to_string());
                }
                "-D" => {
                    let mut iter = val.split('=');
                    self.defines.insert(
                        iter.next().unwrap().to_owned(),
                        iter.next().map(|s| s.to_owned()),
                    );
                }
                _ => {}
            }
        }

        // Handle multi-character arguments with space-separated value like `-framework foo`
        let mut iter = words.iter().flat_map(|arg| {
            if arg.starts_with("-Wl,") {
                arg[4..].split(',').collect()
            } else {
                vec![arg.as_ref()]
            }
        });
        while let Some(part) = iter.next() {
            match part {
                "-framework" => {
                    if let Some(lib) = iter.next() {
                        let meta = format!("rustc-link-lib=framework={}", lib);
                        config.print_metadata(&meta);
                        self.frameworks.push(lib.to_string());
                    }
                }
                "-isystem" | "-iquote" | "-idirafter" => {
                    if let Some(inc) = iter.next() {
                        self.include_paths.push(PathBuf::from(inc));
                    }
                }
                _ => (),
            }
        }
    }

## Refs

https://doc.rust-lang.org/cargo/reference/build-scripts.html

https://github.com/rust-lang/git2-rs/blob/7912c90991444abb00f9d0476939d48bc368516b/libgit2-sys/build.rs#L13

https://doc.rust-lang.org/cargo/reference/config.html#target

https://wapl.es/rust/2019/02/17/rust-cross-compile-linux-to-macos.html

https://docs.rs/pkg-config/0.3.19/pkg_config/

https://github.com/rust-lang/git2-rs

How To Start Tmux as Systemd User Service

ttyS3 — Tue, 30 Mar 2021 19:27:29 GMT

tmux 启动一下能有多慢？答案是，挺快的。那为什么要有这种需求？原因是布局恢复。老灯目前使用的是一个tpm插件，名叫 tmux-resurrect， prefix + ctrl + r 即可自动恢复所有panel.

但是有个小问题，panel比较多，比如有10多个的情况下，启动tmux还是会小闪一下的，整个过程肉眼可见，

会造成操作上的停顿。比如你打开 Gnome terminal 马上就能执行命令了，但是你刚开机启动tmux,你得等几秒才能操作，就因为这个panel恢复。

怎么样加快这个过程？答案当然是，用户登录的时候就马上运行tmux呗。

这个比较简单，直接看 ArchLinux 的 wiki 整个 systemd unit 文件就好了。

不过 Arch 的 wiki 有个小错误。

/etc/systemd/system/[email protected]

[Unit]
Description=Start tmux in detached session

[Service]
Type=forking
User=%I
# 这里 Arch wiki 原来写的是 %u, 应该修正为 %i
ExecStart=/usr/bin/tmux new-session -s %i -d
ExecStop=/usr/bin/tmux kill-session -t %i

[Install]
WantedBy=multi-user.target

要使用 %i（表示 instance, 即 tmux@xxx.service 里的 xxx) 而不是%u

的原因是： %u 的值并不会被 User= 配置所影响，它表示的是 the name of the user running the service manager instance ， 由于 Arch wiki 里用的是system级的unit文件，因此实际上用户名是 root

Specifier	Meaning	Details
"`%u`"	User name	This is the name of the user running the service manager instance. In case of the system manager this resolves to "`root`". Note that this setting is not influenced by the `User=` setting configurable in the [Service] section of the service unit.
"`%i`"	Instance name	For instantiated units this is the string between the first "`@`" character and the type suffix. Empty for non-instantiated units.
"`%I`"	Unescaped instance name	Same as "`%i`", but with escaping undone.

老灯还是觉得 user service 在这种场景下更为合适，因此没有采用 system 级别的 service方案。

我的 mytmux.service 内容如下：

# put this file to ~/.config/systemd/user/mytmux.service
# enable the service: systemctl --user enable mytmux
# ref https://wiki.archlinux.org/index.php/Tmux#Autostart_with_systemd
[Unit]
Description=Start tmux in detached session

[Service]
Type=forking

# comment here, use zsh preexec instead
# below must changed per host/user
# Environment=DISPLAY=:1
# Environment=XAUTHORITY=/run/user/1000/gdm/Xauthority

ExecStart=/usr/bin/tmux new-session -s %u -d
ExecStop=/usr/bin/tmux kill-session -t %u

Restart=on-failure
RestartSec=3s

[Install]
WantedBy=default.target

为方便安装，整了个 Makefile:

install:
    -systemctl --user stop mytmux 2>/dev/null
    install -vD -m 755 ./mytmux.service ~/.config/systemd/user/mytmux.service
    systemctl --user daemon-reload
    systemctl --user enable --now mytmux
    systemctl --user status mytmux
    journalctl --user -a -f -u mytmux
.PHONY: install

troubleshooting

1. DISPLAY 环境变量没有被设置

这里指的是从 tmux-resurrect 自动恢复的panel里的zsh进程没有获取到 DISPLAY 环境变量，但是如果你在那个panel使用tmux showenv查看，却发现tmux本身是获取到了这个变量的，只是 zsh 没有获取到。

猜测应该是 user service 启动的时候，x11 其实并没有完成启动。而 tmux 自身之所以能获取到 DISPLAY 的值，是因为它会自动刷新。（如果不刷新，可以通过设置 set -g update-environment 'DISPLAY SSH_ASKPASS SSH_AGENT_PID SSH_CONNECTION WINDOWID XAUTHORITY TERM' 修复）

几经折腾后，在这里找到了答案。在.zshrc 中加上 preexec hook 即可：

if [ -n "$TMUX" ]; then
  function refresh_env_var_from_systemd_started_tmux {
    export $(tmux show-environment | grep "^DISPLAY")
    export $(tmux show-environment | grep "^XAUTHORITY")
  }
else
  function refresh_env_var_from_systemd_started_tmux { }
fi

function preexec {
  refresh_env_var_from_systemd_started_tmux
}

注意这里一定要用 preexec hook，直接执行 refresh_env_var_from_systemd_started_tmux 是没有效果的，

因为执行的时候，DISPLAY 还是空的呢。

另外有一点不要误解的就是，set-option -g update-environment 这里的update是针对 tmux 进程自身的，

而不是通过 tmux 启动的 shell (比如 zsh).

还有一种比较笨的方法就是直接在 systemd unit 文件中指定这些环境变量的值，比如：

Environment=DISPLAY=:1
Environment=XAUTHORITY=/run/user/1000/gdm/Xauthority

为什么需要这个？有些程序（一般是x11 client)的运行是要依赖DISPLAY这个环境变量的，比如 https://github.com/suxpert/vimcaps 这个vim插件, 里面有个c lib, 初始化的时候就会调用 XOpenDisplay

2. tmux.service user service 重启后被奇怪地禁用了

这个其实是老灯装了一个叫 tmux-continuum 的tpm插件的锅。这个问题确实坑了我很久。

我怎么想到这一点的？我刚开始并没想到，并且重启了n次，折腾了好久，被这货害惨了。

后面我把 tmux.service 改成了 mytmux.service 发现问题神奇的消失了。

症状就是: systemctl --user enable tmux 后，明明服务成功运行了，检查 ~/.config/systemd/user/default.target.wants/tmux.service 也是存在的，说明确实成功enable了。

一重启，发现~/.config/systemd/user/default.target.wants/tmux.service 已经消失了。服务自动是被禁用状态了。

tmux-continuum/scripts/variables.sh 中有定义： systemd_service_name="tmux.service"

然后这货在tmux启动时会执行 systemctl --user disable ${systemd_service_name}

见 tmux-continuum/scripts/handle_tmux_automatic_start.sh

is_tmux_automatic_start_enabled() {
        local auto_start_value="$(get_tmux_option "$auto_start_option" "$auto_start_default")"
        [ "$auto_start_value" == "on" ]
}
is_osx() {
        [ $(uname) == "Darwin" ]
}

is_systemd() {
        [ $(ps -o comm= -p1) == 'systemd' ]
}

main() {
        if is_tmux_automatic_start_enabled; then
                if is_osx; then
                        "$CURRENT_DIR/handle_tmux_automatic_start/osx_enable.sh"
                elif is_systemd; then
                        "$CURRENT_DIR/handle_tmux_automatic_start/systemd_enable.sh"
                fi
        else
                if is_osx; then
                        "$CURRENT_DIR/handle_tmux_automatic_start/osx_disable.sh"
                elif is_systemd; then
                        "$CURRENT_DIR/handle_tmux_automatic_start/systemd_disable.sh"
                fi
        fi
}
main

默认配置是这样的：

auto_start_option="@continuum-boot"
auto_start_default="off"

所以每次重启后就执行了"$CURRENT_DIR/handle_tmux_automatic_start/systemd_disable.sh"

即 systemctl --user disable tmux.service

Refs

https://github.com/tmux-plugins/tmux-resurrect

https://github.com/tmux-plugins/tmux-continuum

https://wiki.archlinux.org/index.php/tmux#Autostart_with_systemd

https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Specifiers

https://babushk.in/posts/renew-environment-tmux.html

https://goosebearingbashshell.github.io/2017/12/07/reset-display-variable-in-tmux.html

How To Switch Caps Lock with Escape in Linux

ttyS3 — Tue, 30 Mar 2021 18:52:37 GMT

Window: X11 DE: GNOME3 OS: ArchLinux

为什么会有这种需求？当然是 vim 用户才有这种需求。

setxkbmap大法

setxkbmap -option caps:swapescape

To make this work at startup, you can put it in ~/.profile as this will only run after the interactive login.

gnome-tweak大法

对于GNOME用户来说，最简单省事的方法当然是使用 gnome-tweak

通过gnome tweak设置，实际上相当于执行了：

gsettings set org.gnome.desktop.input-sources xkb-options "['caps:swapescape']"

当前值可通过get获取：

❯ gsettings get org.gnome.desktop.input-sources xkb-options
['lv3:ralt_switch', 'caps:swapescape']

xkb rules 大法

新建一 /etc/X11/xorg.conf.d/90-custom-kbd.conf

内容大致如下：

Section "InputClass"
        Identifier      "system-keyboard"
        MatchIsKeyboard     "on"
        Option          "XkbLayout" "us"
        Option          "XkbModel"  "pc104"
        Option          "XkbOptions" "caps:swapescape"
EndSection

xmodmap大法

最古老的方法应该是 xmodmap 大法吧，这也是最容易找到答案的。但是这应该是老灯最不推荐的方法了，因此放到最后。

~/.Xmodmap 内容如下：

clear Lock
keysym Caps_Lock = Escape
keysym Escape = Caps_Lock
add Lock = Caps_Lock

然后开机后执行: xmodmap ~/.Xmodmap

文档上说 GDM 会自动执行这个，不需要手动干预执行，但是老灯测试，实际上 GNOME3.38 并不会执行这个。

see https://bugzilla.redhat.com/show_bug.cgi?id=873656

这个文章也确认了这一点。也就是说差不多10年前这个就不会自动load了。

October 13, 2010 11:20 pm Sergey Udaltsov GNOME (gnome-settings-daemon) was supporting custom xmodmap files for ages – as a convenient way to tweak the kbd config. I heard several times about people using that feature – even though it was never important, used by minority. Yesterday that feature has gone from g-s-d.

troubleshooting

xkb-options 不工作？

可能你使用的是较老版本的有bug的GNOME, 比如 Ubuntu 20.04 with gnome-shell 3.36.4-1ubuntu1~20.04.2

fixed in 3.38 （see https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3299#note_977234 )

Refs

https://blogs.gnome.org/sudaltsov/2010/10/13/xmodmap-and-gnome/

https://bugzilla.redhat.com/show_bug.cgi?id=873656

https://gitlab.gnome.org/GNOME/gnome-tweaks/-/issues/50

https://askubuntu.com/questions/363346/how-to-permanently-switch-caps-lock-and-esc

https://wiki.archlinux.org/index.php/xmodmap#Custom_table

https://superuser.com/questions/566871/how-to-map-the-caps-lock-key-to-escape-key-in-arch-linux/1239550#1239550

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3299

https://wiki.archlinux.org/index.php/X_keyboard_extension#Using_rules

买了个APC UPS

ttyS3 — Thu, 25 Mar 2021 19:04:15 GMT

今天回到家已经很晚了，一到家发现 NAS 是关机的， PC 按电源也没反应。

然后发现山特 mt 1000 pro UPS 灯是灭的。

几经折腾还是不能开机，没有一个灯亮的。查了一下狗东订单，这款 mt1000 pro大概是2018年12月入的。

点击申请售后，提示已经过保。但是商品页面写着3年保修（但是狗东保修那里没填写任何东西），24小时客服热线啊（大晚上估计没客服，也不抱什么希望了）。

手里还有个山特 tg500，结果一试，发现也点不亮了。这下好了，俩 UPS 全挂。

当初买这款mt1000 pro，主要是看重它支持通过 rs232 串口来查询状态和控制断电自启选项。用 Golang 自己写了个程序，可以实现市电断了之后 NAS 自动关机（网上找的文档，协议和功能都非常简单）。

类型：后备式
品牌：山特（STK）
额定容量：600 瓦数 / 1000 VA
产品尺寸（mm）：84*430*220MM
输入电压：173~273VAC(标准模式)

比较窄，但是超级长（43cm)，我只能将它对角放在机柜，直接放会多出来10多厘米。

22cm 高是我这个机柜的极限了（随便买的一个放东西的架子，估且称作机柜吧，毕竟现在就是当机柜用）。

需求：带一台高性能的 PC + 8盘位 NAS, 因此群辉NAS好基友 -- APC BK650-CH 或它的新款 APC BK650M2-CH 这种 390W / 650 VA 的可能满足不了需求。

BR1000G-CN（价格1300￥左右）同样是600W/1000VA，支持 NAS 自动关机和来电自启，但是25cm的高度我这放不下（382mm100mm250mm）

BX1100CI-CN 带有AVR, 660W/1100VA, 没有通知功能。狗东最近活动价 700 左右。

BP1000CH（价格570￥左右）同样是600W/1000VA，性价比高啊。不过 320mm130mm182mm 的尺寸我这刚好可放下。另外还带 rs232 接口可以通知 PC 自动关机。

综合对比之下，BP1000CH 是个不错的选择，虽然机型可能有点老。但是 BP1000CH 跟其它型号有一个非常重大的区别，就是：它在电池模式输出的波形是 方波，而现在大部分流行的家用 UPS 都是 正弦波逐步逼近 s (step-approximated sinewave)

UPS 电源按其工作方式可分为后备式 UPS 和在线式 UPS 两大类；而按其输出波形又可分为方波输出 UPS 和正弦波输出 UPS 两种。

根据网上不知名的资料：

方波输出的 UPS 电源带负载能力差(负载量仅为额定负载的 40～ 60％)，不能带电感性负载。如所带的负载过大，方波输出电压中包含的三次谐波成份将使流入负载中的容性电流增大，严重时会损坏负载的电源滤波电容。正弦波输出的 UPS 电源的输出电压波形畸变度与负载量之间的关系没有方波输出 UPS 电源那样明显，带负载能力相对较强，并能带微电感性负载。

所以，老灯最终还是选择了 BX1100CI-CN

https://www.apc.com/shop/cn/zh/products/APC-Back-UPS-1000VA-/P-BP1000CH

https://www.apc.com/shop/cn/zh/products/Back-UPS-1100VA-AVR-230V/P-BX1100CI-CN

Golang RSA 如何私钥加密公钥解密

ttyS3 — Sun, 21 Mar 2021 16:14:38 GMT

一般来说，加密主要用于消息的传递，并且传递的消息只有持有私钥的那个人能解密。

因此，像 RSA 这种非对称密钥加密算法的常用场景是：

对于加密，公钥加密，私钥解密。

为什么不是私钥加密，公钥解密呢？因为使用场景是假定公钥都可以获取到，因而公钥解密这种操作也就与明文无异了。

有没有私钥加密的常用场景呢？当然是有，比如常见的签名操作。

明文消息 -> 进行 hash -> 对 hash 后的结果进行私钥加密，这个加密后的结果就是签名了。

对签名进行验证实际上就是用公钥解密，然后把解密后的hash与原始消息的hash进行对比。

客户端：明文消息 -> 进行 hash -> 对签名使用公钥进行解密，并对比 hash 结果。

the story

早期版本的 Go 标准库并不提供私钥加密和公钥解密功能。但是大家应该能猜想到，

其实要实现私钥加密，只需要在原来的签名函数上修改一个 hash 参数，使得这个 hash 啥也不做。

当然，由于明文并不能像 hash 一样是固定位数的，因此，这里自然免不了要 padding.

Go 的签名是采用的 PKCS #1 v1.5 padding 方式。

这个提交使得标准库直接支持私钥加密了：

https://github.com/golang/go/commit/78c16c9b16dc9c64d1ddad6db5afaab12e87e8f2#diff-fd7abb32dfad4ffb52bb17669ce4a8a4114917e7d4a055107a9f1fc9381f1c94R233

crypto/rsa: support unpadded signatures.
Usually when a message is signed it's first hashed because RSA has low limits on the size of messages that it can sign. However, some protocols sign short messages directly. This isn't a great idea because the messages that can be signed suddenly depend on the size of the RSA key, but several people on golang-nuts have requested support for this and it's very easy to do.
R=golang-codereviews, rsc CC=golang-codereviews golang.org/cl/44400043

the solution

Since go 1.3, you can easily do this using SignPKCS1v15

rsa.SignPKCS1v15(nil, priv, crypto.Hash(0), plainData)

refer: https://groups.google.com/forum/#!topic/Golang-Nuts/Vocj33WNhJQ

所以，现在的 SignPKCS1v15 方法是这样的：

// SignPKCS1v15 calculates the signature of hashed using
// RSASSA-PKCS1-V1_5-SIGN from RSA PKCS #1 v1.5.  Note that hashed must
// be the result of hashing the input message using the given hash
// function. If hash is zero, hashed is signed directly. This isn't
// advisable except for interoperability.
//
// If rand is not nil then RSA blinding will be used to avoid timing
// side-channel attacks.
//
// This function is deterministic. Thus, if the set of possible
// messages is small, an attacker may be able to build a map from
// messages to signatures and identify the signed messages. As ever,
// signatures provide authenticity, not confidentiality.
func SignPKCS1v15(rand io.Reader, priv *PrivateKey, hash crypto.Hash, hashed []byte) ([]byte, error) {
	hashLen, prefix, err := pkcs1v15HashInfo(hash, len(hashed))
	if err != nil {
		return nil, err
	}

	tLen := len(prefix) + hashLen
	k := priv.Size()
	if k < tLen+11 {
		return nil, ErrMessageTooLong
	}

	// EM = 0x00 || 0x01 || PS || 0x00 || T
	em := make([]byte, k)
	em[1] = 1
	for i := 2; i < k-tLen-1; i++ {
		em[i] = 0xff
	}
	copy(em[k-tLen:k-hashLen], prefix)
	copy(em[k-hashLen:k], hashed)

	m := new(big.Int).SetBytes(em)
	c, err := decryptAndCheck(rand, priv, m)
	if err != nil {
		return nil, err
	}

	return c.FillBytes(em), nil
}

如果给 rand 传 nil 则每次生成的加密结果都是一样的。

如果给 crypto.Hash() 传0, 则表示不进行任何 hash

因此，私钥加密实际上只是一个特殊参数的调用：

encrypted, err := rsa.SignPKCS1v15(nil, priv, crypto.Hash(0), []byte(message))

troubleshoot

Golang 加密后的消息给 node.js 解密时，node.js 报错：

rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01

不要被错误信息迷惑了。这种错误跟 block type (padding) 没有什么关系。

错误的根本原因是，要么是加密的人私钥用错了，要么是解密的人公钥用错了。（没错，我在写某知名软件的注册机时，因为这个错误提示浪费了很多时间，直到后面意识到了问题的真正原因。另外，我还要在这里吐槽一下某公司，你们的注册算法写得太烂了，有标准的签名算法不用，直接用的私钥加密/公钥解密这一套。还害我写这么一篇文章。另外，都2021年了，你们还在用 RSA 1024）

refs

https://golang.org/src/crypto/rsa/pkcs1v15.go?s=8774:8874#L221

https://gist.github.com/kkHAIKE/be3b8d7ff8886457c6fdac2714d56fe1

https://github.com/buf1024/golib/blob/master/crypt/rsa.go

https://topic.alibabacloud.com/a/golang-private-key-encrypt-public-key-decrypt_1_38_30920103.html

node.js 类似 https://www.geeksforgeeks.org/node-js-crypto-publicdecrypt-method/

https://github.com/nodejs/help/issues/1093

NeoVim CPU Stuck on 100% issue debug

ttyS3 — Sun, 21 Mar 2021 15:30:21 GMT

最近发现打开某些行数“超级多”的古老 go 代码时，自动完成和保存的时候都很卡，卡到什么程度呢？完全无法正常使用的程度。

保存文件时 CPU 100%

先说下文件保存的时候的卡顿问题吧。

这个问题经过排查主要是 Ale 插件引起的。

let g:ale_fixers = {
\   '*': ['remove_trailing_lines', 'trim_whitespace'],
\   'go': ['gofmt', 'goimports'],
\}

let g:ale_fix_on_save = 1

这个配置会使 ale 在 go 文件保存的时候自动执行 gofmt 和 goimports fixer

触发问题的go文件大概有1万行代码左右。

6 核心 4.0 GHz 9代 CPU, 卡顿时间大概是 60s.

问题点可以用vim自带的 profile 找出：

:profile start ale.log
:profile file *
:profile func *
:e foo.go
:q

profile 结果：

FUNCTIONS SORTED ON TOTAL TIME
count  total (s)   self (s)  function
    6  95.284024   0.000682  <SNR>131_NeoVimCallback()
    3  95.219276   0.001431  <SNR>128_ExitCallback()
    2  95.205686   0.051308  <SNR>149_HandleExit()
    3  95.158971   0.000787  <SNR>149_RunFixer()
    1  95.148690   0.003005  ale#fix#ApplyFixes()
    1  95.145444   0.008286  ale#fix#ApplyQueuedFixes()
    1  95.124312  95.124310  ale#util#SetBufferContents()
   11   0.628545   0.003539  scrollview#HandleMouse()
   11   0.618689   0.617861  <SNR>142_ReadInputStream()
  410   0.312603   0.005017  CapsStatusline()
  410   0.307586   0.037893  vimcaps#statusline()
  410   0.269693   0.266351  <SNR>110_lockstate()
    5   0.187795   0.000137  <SNR>142_RefreshBarsAsyncCallback()
    5   0.187657   0.000680  <SNR>142_RefreshBars()
    5   0.185126   0.062890  <SNR>142_ShowScrollbar()
    5   0.120451   0.002321  <SNR>142_CalculatePosition()
   10   0.116327             <SNR>142_VirtualLineCount()
    3   0.063975   0.047837  ale#util#JoinNeovimOutput()
  205   0.061899   0.005964  AleStatus()
    4   0.032224   0.000098  <SNR>79_on_refresh_event()
    


FUNCTIONS SORTED ON SELF TIME
count  total (s)   self (s)  function
    1  95.124312  95.124310  ale#util#SetBufferContents()
   11   0.618689   0.617861  <SNR>142_ReadInputStream()
  410   0.269693   0.266351  <SNR>110_lockstate()
   10              0.116327  <SNR>142_VirtualLineCount()
    5   0.185126   0.062890  <SNR>142_ShowScrollbar()
    2  95.205686   0.051308  <SNR>149_HandleExit()
    3   0.063975   0.047837  ale#util#JoinNeovimOutput()
  410   0.307586   0.037893  vimcaps#statusline()
    4   0.032126   0.031659  hexokinase#v2#scraper#on()
    7   0.020110   0.019948  <SNR>110_toggleoff()
10428              0.016139  <SNR>128_GatherOutput()
  410              0.014748  LspStatus()
  615              0.013326  LightlineFilename()
  410   0.013600   0.012902  ClapFilterImplStatusLine()
  812   0.019331   0.011470  <SNR>147_GetCounts()
    3   0.011297   0.011285  ale#job#Start()
 1032              0.009730  ale#engine#IsCheckingBuffer()
  205              0.008788  lightline#link()
  820   0.015992   0.008526  lightline#ale#linted()
    1  95.145444   0.008286  ale#fix#ApplyQueuedFixes()

提给官方了，作者很快回复了，真的是佩服作者这认真态度。

作者提示说，将 foldmethod=syntax 改成 foldmethod=indent 性能会好很多：

A fix for this was attempted in #3358, but caused #3504, so we reverted it in #3535. I'm interested in seeing a fix for this that doesn't cause the same cursor position jumping issue.
One thing you can try is not using syntax folding if you're using folding, or switching to folding based on indentation, because folds tend to ruin the performance of setting lines in Vim.

后来我修改 foldmethod=syntax 发现卡顿时间确实是少了很多，从原来 60s 左右降低到 15s 以下了。

但是问题还是存在，暂时来说这个 issue 还没有解决。

后面我禁用了ale 自动修复功能 ( let g:ale_fix_on_save = 0 ), 然后使用neovim 自带的 lsp format 和 codeAction 来执行自动 format 和 import 修复。

autocmd BufWritePre *.go lua vim.lsp.buf.formatting_sync(nil, 1000)

  function goimports(timeoutms)
    local context = { source = { organizeImports = true } }
    vim.validate { context = { context, "t", true } }

    local params = vim.lsp.util.make_range_params()
    params.context = context

    -- See the implementation of the textDocument/codeAction callback
    -- (lua/vim/lsp/handler.lua) for how to do this properly.
    local result = vim.lsp.buf_request_sync(0, "textDocument/codeAction", params, timeout_ms)
    if not result or next(result) == nil then return end
    local actions = result[1].result
    if not actions then return end
    local action = actions[1]

    -- textDocument/codeAction can return either Command[] or CodeAction[]. If it
    -- is a CodeAction, it can have either an edit, a command or both. Edits
    -- should be executed first.
    if action.edit or type(action.command) == "table" then
      if action.edit then
        vim.lsp.util.apply_workspace_edit(action.edit)
      end
      if type(action.command) == "table" then
        vim.lsp.buf.execute_command(action.command)
      end
    else
      vim.lsp.buf.execute_command(action)
    end
  end

vim.api.nvim_command('autocmd BufWritePre *.go lua goimports(1000)')

另外提一句: gopls 已经内置了 gofumpt 支持了, 配置 gofumpt = true 即可，老灯的配置如下：

--@param client: (required, vim.lsp.client)
local mix_attach = function(client)
  require('lsp-status').on_attach(client)
  require('completion').on_attach(client)
  require('illuminate').on_attach(client)
end

-- lsp.gopls.setup{}
-- https://github.com/neovim/nvim-lspconfig/blob/master/lua/lspconfig/gopls.lua
-- https://github.com/golang/tools/blob/master/gopls/doc/vim.md#neovim
-- https://github.com/neovim/nvim-lspconfig/blob/master/CONFIG.md#gopls
lsp.gopls.setup({
  on_attach = mix_attach,
  settings = {
    gopls = {
      usePlaceholders = true,
      completeUnimported = true,
      allowModfileModifications = true,
      allowImplicitNetworkAccess = true,
      usePlaceholders = true,
      -- https://github.com/golang/tools/blob/master/gopls/doc/settings.md#gofumpt-bool
      -- https://github.com/mvdan/gofumpt/commit/38fc491470bae6f44e2d38b06277dd95cf1bdf97
      -- https://go-review.googlesource.com/c/tools/+/241985/7/gopls/internal/hooks/hooks.go#22
      gofumpt = true,
    },
  },
  capabilities = lsp_status.capabilities,
})

自动完成或保存时 CPU 100%

这个问题排查了我很久，排查了很久的原因是，问题代码在 lua 调用 treesitter 的相关代码里。

直接用 vim 自带的 profile 没法找到影响性能的问题点。

另一个原因是，当时的 nvim lsp 也有 CPU 性能问题，大文件会导致 CPU 100%, 但是二者的情况不同。

nvim lsp 导致 CPU 100% 时 CPU 会很快恢复正常 Load, 而 p00f/nvim-ts-rainbow 引起的则不会。

当然，导致我排查了这很久，主要原因还是自己想当然，压根没有考虑到是 treesitter 相关的插件引起的。

因为这个 rainbow 配置成启用也就一行 rainbow = { enable = false, }, 而已。

用最小配置来测试，然后把怀疑有问题的插件加进来。当然，最后还是定位到原因了，那就是由p00f/nvim-ts-rainbow 引起的。当然，我不是第一个发现这个问题的。别人早就提了： https://github.com/p00f/nvim-ts-rainbow/issues/5

当然，我也在这个 issue 下面回复了一下。但是这个作者并不鸟我，倒是同样遇到这个问题的另一个用户还专门跑到我的另一个 issue 回复我了。

当初切到这个 ts 版的 raibow 是因为 luochen1990/rainbow 与 nvim ts 有兼容性问题需要 hack 处理。

当 nvim CPU 100% 时，很久都不能恢复（几十秒以上）。此时如果强行 kill 掉 nvim 会在终端看到一大堆类似如下错误：

Error executing vim.schedule lua callback: /usr/local/share/nvim/runtime/lua/vim/treesitter/query.lua:135: bad argument #1 to 'get_node_text' (string expected, got nil)

切回 vimL 版的 luochen1990/rainbow:

Plug 'luochen1990/rainbow'
let g:rainbow_active = 1


lua <<EOF


-- fixup nvim-treesitter cause luochen1990/rainbow not working problem
-- see https://github.com/nvim-treesitter/nvim-treesitter/issues/123#issuecomment-651162962
-- https://github.com/nvim-treesitter/nvim-treesitter/issues/654#issuecomment-727562988
-- https://github.com/luochen1990/rainbow/issues/151#issuecomment-677644891
require "nvim-treesitter.highlight"
-- vim.TSHighlighter is removed, please use vim.treesitter.highlighter
-- see https://github.com/neovim/neovim/pull/14145/commits/b5401418768af496ef23b790f700a44b61ad784d
-- deactivate highlight of TSPunctBracket
local hlmap =vim.treesitter.highlighter.hl_map
hlmap.error = nil
hlmap["punctuation.delimiter"] = "Delimiter"
hlmap["punctuation.bracket"] = nil

EOF

refs

https://github.com/golang/tools/blob/master/gopls/doc/vim.md#neovim-imports

https://github.com/golang/tools/blob/master/gopls/doc/settings.md#gofumpt-bool

https://github.com/mvdan/gofumpt/commit/38fc491470bae6f44e2d38b06277dd95cf1bdf97

https://go-review.googlesource.com/c/tools/+/241985/7/gopls/internal/hooks/hooks.go#22

https://github.com/p00f/nvim-ts-rainbow/issues/5

https://github.com/dense-analysis/ale/issues/3634

2021 年 PHP 界 Swoole 和 Fiber 的那些瓜

ttyS3 — Sun, 21 Mar 2021 14:43:52 GMT

我是在知乎上偶然看到这么个瓜。

rfc 投票地址： https://wiki.php.net/rfc/fibers

内部讨论记录： https://externals.io/message/113430

在 rfc 投票地址地址上老灯看到有 46 票通过， 13票反对。我们去 https://wiki.php.net/rfc/fibers 看看这 13 票反对的都是哪些人。

parallel的作者 krakjoe 反对是可以理解的，人家直言希望自己的扩展被合并成内核，而不是 Fiber.

至于rasmus （Rasmus Lerdorf，PHP 创始人）吧，我觉得现在版本的 PHP 开发应该跟他没什么关系了，他说啥都行，高兴就好。

所以，13反对票里，有3个是 Swoole 相关方面的人，有一个甚至还是 Swoole 的创始人。

doubaokun Swoole开发者
tianfenghan Swoole开发者, Rango（韩天峰）
twosee Swoole开发者,Twosee（陈曹奇昊）

老灯的观点与知乎上某些观点比较一致：

拒绝提案的理由是没有做到完善？我觉得这个站不住脚，不能说这个提案目前没有像 Swoole 一样弄一整套就不合并吧？（难道只有 Swoole 这种整套的才行？）
另一个理由是，普通开发者用不上，只有amphp 和 reactphp 这类项目用得上？这我觉得也站不住脚。你永远不知道用户能创造出什么框架出来。以 Go 语言为例， unsafe 代码普通人都用不上，那 Go 就不用支持 unsafe 了？感觉这些理由很“主观”和“自以为是”。

老灯就两个提问摘取一些回答围观：

《如何看待Swoole作者声称Fiber提案对非Amp以外的项目毫无价值？》

老外对于这个说法也是相当的不happy的，见 https://www.reddit.com/r/PHP/comments/m1w32y/maintainer_of_swoole_about_the_fibers_rfc_i_am/

作者：鲁严波
链接：https://www.zhihu.com/question/448805077/answer/1778652091\ 来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

看了一圈，大家都是在讨论PHP和Swoole，但在回答这个问题之前，我们需要了解一下背景。

1协程的出现

摩尔定律逐步失效，多线程编程开始流行。

然后多线程世界中的开发者（比如C++、Java开发者）发现了两件事情：

第一，多线程写代码还是很蛋疼，需要考虑互斥、同步，很容易出现海森堡bug。

第二，多线程也不是万灵药，在IO密集场景下，线程调度成为了多线程的瓶颈。

发现了这些问题后。开发人员（重新）捡起了协程这个概念。

协程对于不支持多线程的语言（比如PHP）或者多线程支持不太好的语言（嗯，Python的GIL）都是一个机会。

本来支持多线程要做很多改造，从内核到C扩展都需要配合改造。现在好了，一步到位，直接进入协程时代。

但是协程，也出现了两个流派：

1.1无栈协程

JS的ayncio、python官方的asyncio、这次PHP的generator都是此类代表。

特点就是，协程切换是手动触发，从而免除了大部分互斥的操作（没有yield就不会被切换，那就基本没有互斥了）

但是很显然，上面的方案中除了JS的async发展起来了，其他的都不是很流行。

这就要说到他们的缺点了，需要改代码。

一旦底层框架使用了无栈协程，上层都要跟着改造。比如底层一个协程yield一个generator/promise，那么上层就要yield这个generator/promise，一直到顶层的协程调度器来处理这个generator/promise。

站在广大程序员的角度，事情变得很复杂了：

我就把DB driver改成了异步的，你就要我把DAO层、业务逻辑层、Web渲染层都要改一遍？！

所以现有业务系统切换到无栈协程的成本非常高。

就个人经历来说，我写过amphp、写过JS/TS、很早之前也试过Python3的asyncio。

体验就是，作为开发者，需要严格注意返回的是generator还是一个普通的对象/value。

要是写错，那么线上就炸了…… 而且IDE的智能提示，在这儿也无能为力。

所以，一个技术，如果只能大师才能用得起来，那么它就无法大规模流行。无栈协程就处于这样尴尬的场景。

1.2有栈协程

代表有gevent的monky patch，golang，Java的loom，还有

@韩天峰

大佬的swoole（协程部分）和这次的Fiber，他们本质上都是有栈协程。

有栈协程的特点就是，协程的切换是Runtime控制的，不用手动一层一层yield。

比如一个函数，发起IO调用，那么Runtime就能把这个协程挂起，然后调度到别的协程，IO完成后，这个协程继续执行。

整个过程中，协程都“感知不到”发生了切换。

这时候，开发人员才能安全的使用协程。

底层切换到协程，上层不用做任何改造。

还是上面的例子，DB driver切换到协程版本，基本上业务代码不用动。

基本上Golang的并发模型就是这样子的，就像

@涛叔

之前说的“Golang就是高级的PHP”。

2 Fiber和Swoole

好，聊完了协程，我们再看下Fiber和Swoole：

个人认为，Fiber作为有栈协程的尝试，是PHP协程标准化的一个进步。虽然IO事件部分还是缺失的，但方向是对的，IO事件部分后面会逐步补上。

Swoole是一个非常好的先驱者，但Swoole在推进协程标准化上做得不多。标准化阵地就在这儿，Swoole不占领，Fiber就会来占领。

从生态角度、后续PHP协程的发展前景来看，还是希望

@韩天峰

大佬以及Swoole团队能够推进标准化。

Fiber现阶段对于Amp以外的项目价值很少，但是随着周边生态，比如IO事件系统、协程调度系统、协程同步语义逐步建立起来后，PHP开发者还是会逐步使用的，长远来看，还是需要注意这个提案的影响。

所以建议Swoole团队能够及时把自己的修改合并到上游，争取到更大的PHP内核发言权。

3 番外

3.1 CPU密集型

我们说了这么久的协程，但是协程要解决的是IO密集型的问题。那么CPU密集型的呢？目前看起来主要靠多进程来实现（至少对于众多脚本语言来说是这样）。

在这一块上，PHP还缺少一个多进程的管理器，目前PHP的parallel做了一些尝试，但是目前看起来不是很好用。

3.2 by-pass内核

让我们目前再放长远一点，现在计算机结构中，越来越多的by-pass kernel的方式出现：

内核处理不好线程调度，那么搞协程，用户自己来调度。（无栈协程改造成本太大，所以都采用有栈协程）

内核处理不好网络包，那么搞DPDK，用户自己来处理网络包。（用户自己要独占网卡，很容易出问题；所以需要一个好的共享网卡的by-pass网络栈，现在DPDK的KNI是一个不错的尝试，但是显然不够）

在by-pass kernel这一块，还有没有更加好玩的东西呢？这是一个值得思考的问题。

话说到这儿了，那就再多说两句。

3.3 计算机技术的价值

本科时候，计算机导论是乐嘉锦院长教的，他说过一句话，大意如下：

现在我们写程序，都是计算机结构都已经定好了，然后我们再往里面填代码。真正应该做的是：根据需求设计计算机，而不是被计算机结构框住。

当时觉得，这句话大而无当，没啥意思。现在想来，这句话契合了最近几年计算机的发展途径：

从上面内核不能满足需求，我们by-pass内核；再到CPU不能满足需求，我们开始设计AI芯片。

这后面的逻辑是啥呢？我觉得可以汇总成一句话：

计算机技术和其他技术一样，都要满足客户需求，把价值交付给客户。

发布于 03-14

作者：匿名用户
链接：https://www.zhihu.com/question/448805077/answer/1778546652\ 来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

跑题说一些我知道的。

swoole 团队曾经发邮件想表达希望合并到内核。得到的回复当然是你得写提案和有充足的单元测试，必须是 c 语言，并且只希望提供协程 API 部分。swoole 团队的人似乎认定内核组太保守，之后就不了了之了。其实内核组没错，php 社区是很公平的社区，提案起草要经过内部讨论和投票才能合并到内核。合并特性内容可控，通过率才会高。
swoole 团队基于积累经验开发了 swow，算是 swoole 的简化版，只实现了协程相关，事件驱动用了外部的。大概是去年(2020) 开始的项目，说是会努力合并到内核。作者 twosee 也努力开发，一边也参与内核的贡献积累影响力。
fiber 是去年九月左右开始起草的提案，12 月正式内部讨论，当时 swoole 相关的群有人分享了这一消息。然而，swoole 社区并没有太在意，觉得自己的 swoole 才是最强的。这个月月初 fiber 正式开始投票，开局就是11-2，投反对票的两人均来自 swoole 社区。
最引起社区注意的是，投票阶段 swoole 社区的同学突然邮件内部全员说不支持 fiber，理由主要是两个： fiber 进入内核最大的收益者是 amphp 社区；fiber 太简单，完整的协程支持需要考虑各种各样。
swow 作者看到 fiber 这么随便就提案合并，说今年也会尝试提案，不管 fiber 是否通过。

编辑于 03-13

viproot 程序员

希望swoole的作者能多考虑php的未来，而不是swoole的未来，swoole虽然扩展了php的能力，但是换句话说swoole对php语言发展并没有做出太大贡献

发布于 03-18

作者：涛叔
链接：https://www.zhihu.com/question/448805077/answer/1777527343\ 来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

我实名反对

@韩天峰

的回答。PHP开发者社区好久没有这样的瓜了。容我为大家细细道来。

我也是 PHP 出身，给 Swoole 贡献过代码。我甚至在2017年的时候也想给 PHP 添加 Fiber 性，参见这里。限于技术水平，我的方案有缺陷，没有得到认可。后来就不了了之了。再后来，我转用Go语言，不怎么关注PHP。

直到昨天我才知道又有开发者尝试给PHP添加 Fiber 特性了。我惊喜万分。于是看了一下它的RFC。他们甚至还在RFC中提到了我之前写的RFC，我之前写的RFC

The prior Fiber RFC did not support context switching within internal calls (array_map, preg_replace_callback, etc.) or opcode handlers (foreach, yield from, etc.). This could result in a crash if a function using fibers was used in any user code called from C code or in extensions that override zend_execute_ex such as Xdebug.

写的也很中肯。当时我只想处理纯PHP代码Fiber，不想管复杂的C函数栈问题。被拒绝也是预料之中的事。

好了，背景就这么多。我们说正题。

在吃瓜之前，我们得先看看瓜长什么样。不然大家会限入文化和意识形态之争。

第一个要澄清的是并行跟并发的概念。并行可以理解成同时执行，这个需要硬件支持。你如果你的CPU只有一核，那程序不可能并行。并发可以理解成共同执行，主要是一个软件概念。我们就是在单核CPU上也能同时写文档、听音乐。为什么，因为操作系统一般都支持按时间片调度，不同的程序可以交替执行一段时间（时间片）。因为切换的速度特别快，大家感觉不出来罢了。当然了，如果你的CPU有多核，那就可以并行执行，不用交替切换了。但CPU的核数是有限的，你想运行的程序却很多，所以现在的计算机都是同执行并行和并发操作。而并行就是并发的一种实现方式。

总之，并行跟迸发是操作系统的基本概念，学过的同学应该都清楚。我们今天说的Fiber是为了解决并发问题，而不是并行问题。大家在吃瓜之前务必要记住这一点。

回到Fiber。Fiber也叫纤程，其实跟协程是一个概念。

我们讲并发编程无非就是进程、线程、协程。无论是进程还是线程，都可以并发执行，都有自己的栈空间。所以不同线程调用同一函数基本是不会相互影响的（没有使用全局量）。同时，进程跟线程的调度是同操作系统完成的，调度消耗资源比较多、比较慢；而因为有独立的栈空间和其他相关信息，进程和线程也会占用很多系统资源。所以说，我们没法在系统里创建很多进程和线程。即便我们有足够多的内存，我们强行启动成千上万个进程和线程，操作系统在调度的时候也会非常吃力。

为了解决这个问题，人们决定不让操作系统调度，自己上。于是就有了「用户态」线程这样的概念，这就是所谓的协程。从某种成度上看，协程就是一种线程，一种需要用户自行调度的线程。因为不需要操作系统的介入，调度的效率会比较高，资源的消耗比较小。所以现在有些人一提起高并发编程就要用协程。

这里的用户自行调度是相对于操作系统来说的。这个用户可以是程序员，也可以是编译器或运行时。不同的语言处理手法也各不相同。像是Go语言，就是在运行时完成协程调度的。协程在执行的时候如果遇到阻塞（比如网络数据没收到等）就会自动暂停执行，等相关资源就绪之后运行时会按某种规则唤醒。像PHP的generator就需要yield来暂停，再通过resume来恢复。

PHP本身是多进程模式（不完全对）。从5.4开始，PHP支持所谓的generator。我个人认为PHP的generator最开始是为了解决大批量数据处理时的内存占用问题。看如下代码：

<?php
function xrange($start, $end, $step = 1) {
    for ($i = $start; $i <= $end; $i += $step) {
        yield $i;
    }
}

foreach (xrange(1, 1000000) as $num) {
    echo $num, "\n";
}

在 foreach 中，调用 xrange 会返回一个 generator 对象，而非直接分配一个有一百万元素的数组。foreach 在每次循环的时候都会调用 generator 对像的 send 方法来获取下一个元素。而这个 generator 会执行 xrange 方法，一直走到 yield。这个 yield 可以理解为临时的 return。xrange执行到 yield 会暂停，send 方法就会返回 yield 后面的 $i。当 foreach 再次调用 send 的时候，generator 会从上一次 yield 的地方继续向下执行。

所以说，generator 对象一不小心给 PHP 添加了暂停函数的特技。基于此，人们想给PHP添加协程功能。最基础的思路在这里，作者是nikic，本身就是 generator 的开发者。从那以后，PHP社区出现了好多基于 generator 的协程框架。最著名的要属https://amphp.org，而amphp社区正是本次php-fibers RFC的推动者。

有了 generator 为什么还要引入 fiber 呢？那是因为当前的 generator 不支持暂停子函数调用。

一般来说我们的代码都是分层的，比如是 api -> controller -> service -> model -> util。可能从 api 调 controller 一直调到 model 都没有阻塞操作，但 model 调 util 可能需要访问 db 连接，数据可能没有传回，在这种情况下，我们希望暂停从 api 到 util 的整个调用栈，等数据传回的时候再继续执行。很可惜，generator 不支持这样的操作。

如果要实现暂停从 api 到 util 的整个调用栈，我们就必需在调用 api 函数之前准备好一个独立的函数调用栈，用这个独立的栈保存各层函数调用的各种数据。这显然是非常复杂的。像 nodejs 等好多语言直接决定不支持这种暂停效果，不会为协程分配独立栈空间。这种叫 stackless coroutine。php了 generator 也采用这种策略。

这种策略的好处就是实现简单，性能高，对应的功能也简单。而且不能实现暂停从 api 到 util 的整个调用栈的效果。如果你要用，必须重写现有的代码。如果你用nodejs，你不得不处理各种async/await逻辑。用async/await写过业务逻辑的人肯定不会愉快。关于这个问题，有人专门写了这篇文章What Color is Your Function?

而我们要说的 fiber 就是为了解决 generator 不能暂停从 api 到 util 的整个调用栈这个问题的。

这个问题其实非常复杂。PHP本身有Zend虚拟机，Zend虚拟机有自己的栈。PHP还有好多功能是通过扩展实现的，而扩展都是用C开发的，所以会用到C运行时的栈。如果要实现Fiber，必须同时分配 C和Zend的栈，确实有难度。但amphp社区的开发者做到了。而且得到了PHP的认可。

我给大家举个使用 fiber 的例子，好让大家有个直观的感受

<?php
function hi(): int {
    echo Fiber::suspend(1);
    echo Fiber::suspend(2);
    echo Fiber::suspend(3);
}

$fiber = new Fiber(function (): void {
    hi();
    echo Fiber::suspend(4);
});

echo $fiber->start();
echo $fiber->resume('a');
echo $fiber->resume('b');
echo $fiber->resume('c');
echo $fiber->resume('d');

我们定义了一个Fiber，并在fiber中调用了hi函数。

当我们调用 start 函数的时候，fiber 开始执行，一直执行到 hi 函数的第一个 Fiber::suspend。这个 suspend 跟前面的 yield 是类拟的，他会把参数1返给 start 函数。从直观上看，我们调了 start 函数，得到了一个返回值1。跟普通的函数调用没什么两样。但请大家注意hi函数的第一行，调用suspend函数不会返回也就是说echo也不会执行。从直观上看，这一行是调了suspend函数，期待返回一个值并奖其输出。

前面的start()返回后echo会输出suspend返回的数字1整个fiber就进入了暂停状态。此时程序输出1.

如果我们调一下resume函数，传入参数'a'。fiber 就会恢复执行，而且是从上一次suspend的地方继续执行。从效果上看仿佛是之前的suspend函数调用结束了，并返回了一个'a'。这个时候hi第一行的echo就会输出'a'，然后继续执行到第二个supend。

总而言之，就是实现了之前所说的暂停从 api 到 util 的整个调用栈这个效果**。**

等等，这个事情跟

@韩天峰

有什么关系呀？为什么他要跳出来反对呢？

Fiber 本质上赋予了 PHP 在用户态临时暂停任意函数调用的特技。如果配合外部事件调度框架（可以完全用PHP实现），就可以实现 swoole 的大多数功能。而且，更关键的点在于，PHP社区现有庞在的类库几乎只做很少的改动就能适配到 fiber 上进而获得并发执行的能力。这跟swoole需要内置各种协程版类库形成了鲜明的对比。最后，因为 fiber 会合并到 php 内核，由官方背书。一旦投票通过，会得到整个社区的支持。届时，swoole 就会被逐步边缘化。

所以，swoole 相关的人就开始反对了。关于反对的内容，建议大家直接看原始讨论邮件，不要相信一家之言

就我观察，swoole是很难合并到 php 内核的。因为swoole太重了，更多是个框架，而不是语言特性。可以说swoole从一开始就没有想好怎么做才能合到php内核。swoole开源快十年了。一直不去解决如何合并到内核的问题。现在有人提供了相关方案，自己就坐不住了。

Fiber作为一个简单的特性，反而为大家提供了无限的想像空间。fiber框架提出一开始，大家基本都在讨论如何改进这个提案，如何让他快速合并到内核。唯有swoole相关的人，采用了完全对立的态度，基本上是为了反对而反对。

fiber本身跟swoole没有竞争关系。说到底fiber只是一个增强型的generator。但是，基于fiber，我们可以用纯php打造一套跟swoole竞争的框架，而且现有的php类库也可以很容易地完成适配，这可能是 swoole 社区最害怕的。

从目前投票来看，fiber 特性可能要被通过了。到时候看 swoole 社区如何应对吧。

编辑于 03-13

作者：匿名用户
链接：https://www.zhihu.com/question/448805077/answer/1777447935\ 来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

大家都是写异步协程框架，Swoole一言不合就AMP不行，ReactPHP不行。那你行你倒是提个提案？难怪国内无论知乎还是论坛Swoole人见人骂，Diss同行，恶心同行的方式真是一绝。

现在开始说为了PHP的发展了，你Swoole搞了那么多年，你咋不想着促进PHP协程的发展呢？你咋不想着提个提案？现在有人抛出来fiber，觉得影响你在国内的一亩三分地了，开始跳起来了？开始装圣人了？

目测fiber最终会通过。

-----------------------------------------------分割线-----------------------------------------

完整的邮件请查看

https://externals.io/message/113430externals.io

与

https://externals.io/message/113419externals.io

此外，不得不说一下，在邮件里，Dan Ackroyd询问

Please could you disclose the commercial interests of the Swoole
maintainers, and the ties to the for profit companies that provide
services implementing Swoole?

Having people vote on RFCs who have ties to companies that provide
services via commercial entities isn't unprecedented. For example
zend.com has had employees who are involved in voting on RFCs, but to
a large extent that was done openly, with all of them using zend.com
email addresses.

而rango回答声称：

We have no commercial purpose on the swoole open source project. This is a purely technical project.

编辑于 03-14

《如何看待Swoole作者声称Swoole没有商业目的，反对Fiber提案毫无私心？》

目测fiber最终会通过。

-----------------------------------------------分割线-----------------------------------------

完整的邮件请查看

https://externals.io/message/113430externals.io

与

https://externals.io/message/113419externals.io

此外，不得不说一下，在邮件里，Dan Ackroyd询问

Please could you disclose the commercial interests of the Swoole
maintainers, and the ties to the for profit companies that provide
services implementing Swoole?

而rango回答声称：

We have no commercial purpose on the swoole open source project. This is a purely technical project.

编辑于 03-14

作者：吃的
链接：https://www.zhihu.com/question/448978565/answer/1779597343\ 来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

有无私心只有他本人才知道，我们不恶意揣测，但swoole的总总做法，圈内早以是有所耳闻的。关于此次fiber提案，swoole作者的看法大致是

1、因为协程化困难、工作量大，希望把fiber推迟到php9。这显然不是社区要的，目前php处在这尴尬的局面，正是需要强有力技术栈来推动发展，一个协程最小化核心的实现你建议推迟到php9，再过个几年？等社区把一切都安排好了，大部分人都不用php了再上吗？这是何居心啊。

2、因为fiber只是协程最小化核心，普通开发用不上，大家要的是开箱即用、完整式的协程栈。话是没错，但协程需要的几个技术点目前php社区都有，基于进程的io 多路复用、event loop 、协程调度、非阻塞网络库，那一个没有？只是高效率低效率，最佳实践的问题罢了。至少amphp、reactphp 、symfony process都很明确需要这种最小化核心的，别忽悠大伙儿。

3、python、ruby等动态语言在加入fiber后并没有在并发编程上取得多大成绩。这个就仁者见仁智者见智了，但我们想说的是，“有总比没有好，我可以不用但php不能没有”，这是大家的心声，以后的事谁能预料呢？

总的来说，在协程化生态上目前swoole是走在最前面的，作为一名普通开发，希望swoole能提供你们的宝贵经验，让php能走点更远一点，而不是在这内耗。

发布于 03-14

我觉得加入好啊.

最小的,其它的实现可以慢慢来

swoole那套太复杂了,为了实现携程加入了太多的新东西

不如直接go
简单的东西也不如workerman之类的解决办法

发布于 03-15

vim 如何复制 message 命令的输出到系统剪切板

ttyS3 — Sun, 21 Mar 2021 14:16:08 GMT

vim 要支持复制到系统剪切板，首先要确保系统安装了 xclip 之类的剪切板工具。

主要的使用场景是复制一些错误信息。

要复制 :message 的输出，解决办法就是将输出重定向剪切板。

the clipboard register (@+) or primary register (@*)

比如：

:redir @+
:3message
:redir END

See :help :redir, :help :message

当然，每次都敲这么多命令也是挺麻烦的，直接定义一个名为 CpMsg command 好了：

command! -bang CpMsg redir @+ | 99message | redir END

refs

https://stackoverflow.com/questions/41663646/how-to-copy-to-clipboard-3-last-lines-from-messages/41664344#41664344

https://superuser.com/questions/167352/how-do-i-copy-command-output-in-vim/171105#171105

sysctl.d 未生效问题

ttyS3 — Sun, 21 Mar 2021 13:50:21 GMT

新装的 Arch , 发现 /etc/sysctl.d/01-sysrq.conf 里设置的 kernel.sysrq = 1 没有生效。

检测 /proc/sys/kernel/sysrq 的值发现是 16

先检查下 systemd 相关服务是否正常运行了, 结果是完全正常：

❯ systemctl status systemd-sysctl.service
● systemd-sysctl.service - Apply Kernel Variables
     Loaded: loaded (/usr/lib/systemd/system/systemd-sysctl.service; static)
     Active: active (exited) since Sun 2021-03-21 20:12:34 CST; 1h 45min ago
       Docs: man:systemd-sysctl.service(8)
             man:sysctl.d(5)
    Process: 324 ExecStart=/usr/lib/systemd/systemd-sysctl (code=exited, status=0/SUCCESS)
   Main PID: 324 (code=exited, status=0/SUCCESS)

测试sudo SYSTEMD_LOG_LEVEL=debug /usr/lib/systemd/systemd-sysctl 发现，sysrq 被默认的规则

/usr/lib/sysctl.d/50-default.conf 覆盖掉了。

❯ rg sysrq /usr/lib/sysctl.d/50-default.conf
16:# Use kernel.sysrq = 1 to allow all keys.
17:# See https://www.kernel.org/doc/html/latest/admin-guide/sysrq.html for a list
19:kernel.sysrq = 16

由于我们的文件名是 01-sysrq.conf ，在50之前执行，因此，我们需要系统默认配置执行完再覆盖，把文件名改成 99-sysrq.conf 即可：

❯ bat /etc/sysctl.d/99-sysrq.conf
# been set in 50-default.conf
# so we need override it later
kernel.sysrq = 1

refs

https://wiki.archlinux.org/index.php/sysctl#Configuration

https://wiki.archlinux.org/index.php/Keyboard_shortcuts#Kernel_(SysRq)

Linux Lark GTK

ttyS3 — Thu, 11 Mar 2021 17:16:18 GMT

飞书原名叫 Lark.

有Mac, Windows 和 Web 版。

不过打开很多 Tab 的浏览器里找飞书的 Tab, 确实不太方便。于 Github 找到一个用 Electron 包了一下飞书 Web 的客户端。

使用 electron builder 构建 AppImage / ArchLinux .pkg.tar.xz / rpm / deb 包等还是非常方便， electron builder 实际上采用的是一个基于 ruby 的打包工具，叫 fpm

不得不说Electron的工具还是蛮完善的。

有两个小问题：

隐藏到托盘后没法显示了。
点击消息里的链接，是用的 Electron 打开的，而不是调用的系统默认浏览器。

但是，老灯使用一段时间后发现了 node.js Electron 版的飞书最大的一个问题是，连续跑几天，会导致 GNOME 桌面的所有窗体的标题文字不见了。由于短时间无法重现，导致问题也很难排查。

最张，老灯没办法，自动操刀用学了几天的 Rust 写了一个 GTK 版的 lark-gtk

老灯已经上传新的 release 在这 https://github.com/ttys3/lark-for-linux/releases/tag/v0.5.1

refs

https://www.electron.build/configuration/linux

https://github.com/jordansissel/fpm/wiki#usage

https://gtk-rs.org/

MyRocks -- RocksDB based storage engine for MySQL

ttyS3 — Sun, 07 Mar 2021 16:40:50 GMT

底层存储引擎基于 LevelDB 或 RocksDB 的 Key-Value DB 挺多的，比如 SSDB , 360开源的 Pika 以及腾讯开源的 Tendis

但是基于 RocksDB 的关系型数据库，老灯最近才了解到, 原来 FaceBook 搞的 MySQL MyRocks 引擎已经存在好多年了。简单地浏览了一下文档，InnoDB 算是在写入和读取方面都比较好，而 MyRocks 引擎主要是写入性能强劲，对于读取来说相对弱一些。先 mark 一下吧。

MyRocks及其使用场景分析温正湖

The Road Story of a MyRocks/MariaDB Migration

http://myrocks.io/

MyRocks Engine: Things to Know Before You Start

MyRocks: A space- and write-optimized MySQL database

MariaDB binlog压缩

ttyS3 — Sun, 07 Mar 2021 16:36:08 GMT

先 mark 记录一下。

log_bin_compress——这个配置决定了是否可以压缩二进制日志。这个增强功能是 MariaDB 独有的，因此 MySQL 不支持。

https://www.infoq.cn/article/mariadb-vs-mysql

binlog压缩为了减小binlog的存储开销。在TenDB中,基于ZLIB算法实现了binlog压缩的功能。该功能可以在运行中开启和关闭，并且适用于statement，row，mixed格式。

压缩开启Binlog压缩：

```shell

set global log_bin_compress=ON ```

Binlog压缩阈值：

```shell

set global log_bin_compress_min_len=256 ```

在开启压缩功能的前提下，binlog字段长度大于256的event，符合压缩条件。

经过测试，在通常情况下，启用binlog压缩功能，可以达到7-9的压缩比。是以CPU为代价缓解了IO压力的良好实践。

解压有两种解压的方式可以选择：

让binlog在IO线程中解压：

```shell

set global relay_log_uncompress = ON ```

让binlog在sql线程中解压：

```shell

set global relay_log_uncompress = OFF ```

如果slave机器，relay-log空间够，可以set global relay_log_uncompress=ON(默认配置)，在binlog在IO线程中解压。如果slave机器，relay-log空间不够，可以set global relay_log_uncompress=OFF，让binlog在sql线程中解压，但是这样可能会导致sql线程变慢。但slave都有并行同步能力，所以在sql线程解压一般不会对运行速度有很大影响。

兼容性

新增了4种事件类型： QUERY_COMPRESSED_EVENT表示statement格式下压缩后的DML事件； WRITE_ROWS_COMPRESSED_EVENT，UPDATE_ROWS_COMPRESSED_EVENT和DELETE_ROWS_COMPRESSED_EVENT分别表示row格式下插入，更新和删除在压缩后的事件。

推荐使用TenDB的mysqlbinlog工具进行binlog操作。

https://tendbcluster.com/book-cn/Documentation/tendb/binlog-compress.html

log_bin_compress https://mariadb.com/kb/en/replication-and-binary-log-system-variables/#log_bin_compress

log_bin_compress_min_len https://mariadb.com/kb/en/replication-and-binary-log-system-variables/#log_bin_compress_min_len

https://mysql.wisborg.dk/2020/05/07/mysql-compressed-binary-logs/

https://mariadb.com/kb/en/authentication-plugins/

https://mariadb.com/kb/en/caching_sha2_password-authentication-plugin/

Setup MariaDB Replication With MariaBackup

ttyS3 — Sun, 07 Mar 2021 10:43:50 GMT

环境介绍

Server OS: CentOS 8.2 x64

MariaDB: 10.5.x （主、从均运行在 Docker / Podman 容器里）

操作目标：配置一台全新的从库

假设主库IP是 dbserver1

从库IP是 dbserver2

使用 MariaBackup 做全量或增量同步，更加方便。

安装MariaBackup

首先我们需要在 主 / 从 服务器上分别安装 MariaBackup.

这里比较简单，参考官方文档就好了。

# CentOS 8 / Stream
sudo dnf install MariaDB-backup

# Debian / Ubuntu
sudo apt-get install mariadb-backup

准备全量同步备份文件

这里假设，master 机已经开启 binlog 和 master 模式。我们需要给整个库做一个备份。

由于我们是针对整个 master 服务器备份，因此这里没有指定 --databases=数据名 参数。

mariabackup --verbose --rsync --backup \
   --target-dir=/home/user001/backup/mysql/ \
   --host=dbserver1 --port=3307 --protocol=tcp \
   --user=root --password=root密码在这

这里一定会出错。因为我们的 MariaDB 跑在容器里，host 机并不存在 /var/lib/mysql 目录。

解决办法是：

Create a symlink on your host so that Mariabackup thinks/var/lib/mysql exists. Then delete the symlink once you're done.

ln -s /home/user007/data/mysql /var/lib/mysql

然后再运行命令，就OK了。如果备份成功，最后一部分的日志输出大概如下：

[00] 2021-03-04 05:54:58 Writing xtrabackup_binlog_info
[00] 2021-03-04 05:54:58         ...done
[00] 2021-03-04 05:54:58 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...
[00] 2021-03-04 05:54:58 mariabackup: The latest check point (for incremental): '2611384153422'
mariabackup: Stopping log copying thread.[00] 2021-03-04 05:54:58 >> log scanned up to (2611437102980)

[00] 2021-03-04 05:54:58 >> log scanned up to (2611437103220)
[00] 2021-03-04 05:54:58 Executing BACKUP STAGE END
[00] 2021-03-04 05:54:58 All tables unlocked
[00] 2021-03-04 05:54:58 Backup created in directory '/home/user007/backup/mysql/'
[00] 2021-03-04 05:54:58 MySQL binlog position: filename 'master16-bin.003097', position '15736398', GTID of the last change '0-101-9088409195'
[00] 2021-03-04 05:54:58 Writing backup-my.cnf
[00] 2021-03-04 05:54:58         ...done
[00] 2021-03-04 05:54:58 Writing xtrabackup_info
[00] 2021-03-04 05:54:58         ...done
[00] 2021-03-04 05:54:58 Redo log (from LSN 2611376635865 to 2611437103220) was copied.
[00] 2021-03-04 05:54:59 completed OK!

这样还没完，因为现在copy出来的备份文件，不能直接用于 MariaDB 恢复备份。

原因在这里有解释：

Prepares an existing backup to restore to the MariaDB Server.
Files that Mariabackup generates during --backup operations in the target directory are not ready for use on the Server. Before you can restore the data to MariaDB, you first need to prepare the backup.
In the case of full backups, the files are not point in time consistent, since they were taken at different times. If you try to restore the database without first preparing the data, InnoDB rejects the new data as corrupt. Running Mariabackup with the --prepare command readies the data so you can restore it to MariaDB Server. When working with incremental backups, you need to use the --prepare command and the --incremental-dir option to update the base backup with the deltas from an incremental backup.

因此，对于增量备份的 prepare 操作，其实还需要加 --incremental-dir 选项。

mariabackup --prepare --verbose --rsync --target-dir=/home/user007/backup/mysql/
......
2021-03-04  6:02:53 0 [Note] InnoDB: apply 2611435179079: [page id: space=129, page number=2125]
2021-03-04  6:02:53 0 [Note] InnoDB: apply 2611436322402: [page id: space=129, page number=2177]
2021-03-04  6:02:53 0 [Note] InnoDB: apply 2611436322402: [page id: space=129, page number=2177]
2021-03-04  6:02:53 0 [Note] InnoDB: apply 2611436391525: [page id: space=129, page number=2177]
2021-03-04  6:02:53 0 [Note] InnoDB: apply 2611436391525: [page id: space=129, page number=2177]
2021-03-04  6:02:53 0 [Note] InnoDB: apply 2611435179079: [page id: space=129, page number=2125]
2021-03-04  6:02:53 0 [Note] InnoDB: apply 2611435368189: [page id: space=129, page number=2125]
2021-03-04  6:02:53 0 [Note] InnoDB: apply 2611435368189: [page id: space=129, page number=2125]
[00] 2021-03-04 06:02:53 Last binlog file , position 0
[00] 2021-03-04 06:02:53 completed OK!

复制备份文件到从库所在主机

# 首先 ssh 到从库机器, 准备好存放备份的目录
mkdir -p /home/user007/backup/mysql

# 其实我这里的机器并不是22端口
# 没错，当然是走内网地址
rsync -e 'ssh -p 2222' -avP /home/user007/backup/mysql root@dbserver2:/home/user007/backup/

准备好从库同步需要的账号

CREATE USER 'replication_user'@'dbserver2' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.*  TO 'replication_user'@'dbserver2';

在新的从库上恢复备份

首先 systemctl stop ctr-site007-mariadb 停止掉 MariaDB 服务器, 准备恢复备份。

为什么不是 docker stop 或 podman stop ? 因为这个容器是用 podman generate 生成了 systemd unit 启动服务的，如果从 podman 停止， systemd 又会自动重启容器。所以，下面看到 systemctl 操作 ctr 开头的 service 时，请自行替换成你自己的命令。

恢复其实就是 copy 准备好的备份文件到 MariaDB datadir (也就是/var/lib/mysql）。

由于从为这边我们也是使用容器跑的 MariaDB, 因此同样要给做软链：

ln -s /home/user007/data/mysql /var/lib/mysql

开始恢复备份文件：

mariabackup --copy-back --verbose --rsync \
   --target-dir=/home/user007/backup/mysql/
   
   
# 相关日志输出
[01] 2021-03-04 06:27:14 Copying ./xtrabackup_info to /var/lib/mysql/xtrabackup_info
[01] 2021-03-04 06:27:14         ...done
[00] 2021-03-04 06:27:14 completed OK!

# 检查下恢复的文件
[root@replica mysql]# ls /var/lib/mysql/
aria_log.00000001  aria_log_control  ib_buffer_pool  ibdata1  mysql  performance_schema  site007_prod  xtrabackup_info

注意，执行这个操作的前提是 /var/lib/mysql 目录是空的。也就是如果是我们新跑的服务器，里面没数据的，我们也要清空这个目录，不然 MariaBackup 不会执行恢复备份的操作（会有错误： Original data directory /var/lib/mysql is not empty!）。

根据情况的不同，可能还要恢复一下文件权限，比如 chown -R mysql:mysql /var/lib/mysql/

查看一下 xtrabackup_binlog_info 这个文件的内容，这里第三个值 0-101-9090487761 就是 GTID， copy出来先找个地方暂存一下，等会要用：

[root@replica mysql]# cat xtrabackup_binlog_info
master16-bin.003097     775477086       0-101-9090487761

开启从库同步

启动从服务器： systemctl start ctr-site007-mariadb

登录从库mysql -u root -h dbserver2 -P 3307 -p：

STOP SLAVE;
RESET SLAVE;

SET GLOBAL gtid_slave_pos = "0-101-9090487761";


CHANGE MASTER TO
  MASTER_HOST='dbserver1',
  MASTER_USER='replication_user',
  MASTER_PASSWORD='主库同步密码',
  MASTER_PORT=3307,
  MASTER_CONNECT_RETRY=10,
  MASTER_USE_GTID=slave_pos;
  
START SLAVE;

查看一下同步状态是否正常：

比较需要关注的几个选项：

Slave_IO_State: Queueing master event to the relay log

Master_Log_File: master16-bin.003097 Read_Master_Log_Pos: 842451034 Relay_Log_File: master94-relay-bin.000002 Relay_Log_Pos: 649307

Slave_IO_Running: Yes Slave_SQL_Running: Yes

Using_Gtid: Slave_Pos Gtid_IO_Pos: 0-101-9090669366

Seconds_Behind_Master: 301

Seconds_Behind_Master 是最重要的一个参数。300多秒的延时对于一般的同步来说算是问题比较大了，但是这里由于我们是刚刚启动复制，才开始第一次同步，因此这个情况是正常的。过一会这个值就会正常了(正常来说应该是接近0)。

MariaDB [(none)]> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
                Slave_IO_State: Queueing master event to the relay log
                   Master_Host: dbserver1
                   Master_User: replication_user
                   Master_Port: 3307
                 Connect_Retry: 10
               Master_Log_File: master16-bin.003097
           Read_Master_Log_Pos: 842451034
                Relay_Log_File: master94-relay-bin.000002
                 Relay_Log_Pos: 649307
         Relay_Master_Log_File: master16-bin.003097
              Slave_IO_Running: Yes
             Slave_SQL_Running: Yes
               Replicate_Do_DB: site007_prod
           Replicate_Ignore_DB:
            Replicate_Do_Table:
        Replicate_Ignore_Table:
       Replicate_Wild_Do_Table:
   Replicate_Wild_Ignore_Table:
                    Last_Errno: 0
                    Last_Error:
                  Skip_Counter: 0
           Exec_Master_Log_Pos: 776125657
               Relay_Log_Space: 66974795
               Until_Condition: None
                Until_Log_File:
                 Until_Log_Pos: 0
            Master_SSL_Allowed: No
            Master_SSL_CA_File:
            Master_SSL_CA_Path:
               Master_SSL_Cert:
             Master_SSL_Cipher:
                Master_SSL_Key:
         Seconds_Behind_Master: 301
 Master_SSL_Verify_Server_Cert: No
                 Last_IO_Errno: 0
                 Last_IO_Error:
                Last_SQL_Errno: 0
                Last_SQL_Error:
   Replicate_Ignore_Server_Ids:
              Master_Server_Id: 101
                Master_SSL_Crl:
            Master_SSL_Crlpath:
                    Using_Gtid: Slave_Pos
                   Gtid_IO_Pos: 0-101-9090669366
       Replicate_Do_Domain_Ids:
   Replicate_Ignore_Domain_Ids:
                 Parallel_Mode: optimistic
                     SQL_Delay: 0
           SQL_Remaining_Delay: NULL
       Slave_SQL_Running_State: init for update
              Slave_DDL_Groups: 0
Slave_Non_Transactional_Groups: 0
    Slave_Transactional_Groups: 1765
1 row in set (0.000 sec)

Misc

ERROR 1198

ERROR 1198 (HY000): This operation cannot be performed as you have a running slave ''; run STOP SLAVE '' first

这个错误一般出现在 CHANGE MASTER TO ... 配置slave时。原因是前面的 slave 配置还在，STOP SLAVE 然后 RESET SLAVE 再执行 CHANGE MASTER TO ... 就好了。

ERROR 1932

#1932 - Table 'site007_prod.users' doesn't exist in engine
Copy the ib_logfileXX and ibdata file from old mysql/data folder to the new mysql data folder and it will fix the issue

这个主要是没有使用 MariaBackup 恢复备份，而是采用 rsync 手动 copy 文件到 MairaDB datadir 下的。

并且，少复制了 ib_logfileXX 和 ibdata 等文件。所以，还是用 MariaBackup 恢复的好，除非你非常了解 MariaBackup 的工作原理。

如何安全地清理 binlog

这里主要是讲主库的binlog (从库一般不再作为别人的主，我们不开）

命令格式：

PURGE { BINARY | MASTER } LOGS { TO 'log_name' | BEFORE datetime_expr }

The PURGE BINARY LOGS statement deletes all the binary log files listed in the log index file prior to the specified log file name or date. BINARY and MASTER are synonyms.
Deleted log files also are removed from the list recorded in the index file, so that the given log file becomes the first in the list. The datetime expression is in the format 'YYYY-MM-DD hh:mm:ss'.

注意这里是 prior to (在…之前), 首先我们要检查从库最慢的那个节点（假设有多个从库的话）的同步情况，比如Slave status中的 Master_Log_File = master16-bin.003103

Relay_Log_File master94-relay-bin.000015

Relay_Master_Log_File master16-bin.003103

表示当前 slave 正在 replicate master 那边的 master16-bin.003103，因此， master 那边可以清空在 master16-bin.003103 之前的所有 binlog 文件：

PURGE BINARY LOGS TO 'master16-bin.003103'

如何使用 podman 生成 systemd unit 文件

cd /etc/systemd/system/

podman generate systemd --new -t 10 \
--container-prefix ctr -f -n site007-mariadb

# 启用并启动服务
systemctl enable --now ctr-site007-mariadb

refs

本文主要参考： https://mariadb.com/kb/en/setting-up-a-replication-slave-with-mariabackup/

expire_logs_days 配置： https://mariadb.com/kb/en/replication-and-binary-log-system-variables/#expire_logs_days

显示从服务器： https://mariadb.com/kb/en/show-replica-hosts/

关于使用 GTID: https://mariadb.com/kb/en/gtid/#using-global-transaction-ids

MySQL 复制常见误区： https://severalnines.com/blog/top-mistakes-avoid-mysql-replication

https://mariadb.com/kb/en/setting-up-replication/

https://alibaba-cloud.medium.com/how-to-setup-mariadb-master-and-slave-replication-on-ubuntu-16-04-850c155c5481

MariaBackup 相关文档：

安装： https://mariadb.com/kb/en/mariabackup-overview/#installing-with-a-package-manager

MariaBackup 选项： https://mariadb.com/kb/en/mariabackup-options/

MariaBackup 概览： https://mariadb.com/kb/en/mariabackup-overview/

MariaBackup 工作原理之初始化： https://mariadb.com/kb/en/how-mariabackup-works/#initialization-phase

解决 MariaBackup 针对 MariaDB 容器备份时遇到的问题 https://dba.stackexchange.com/questions/234586/mariabackup-of-database-running-in-docker

如何安全地清理binlog:

https://minervadb.com/index.php/2018/05/14/purging-binary-logs-from-mysql-master-safely/

https://mariadb.com/kb/en/purge-binary-logs/

innodb 如何只恢复特定的表：

首先使用 MariaBackup 在 prepare 的时候增加 --export 参数：

https://mariadb.com/kb/en/restoring-individual-tables-and-partitions-with-mariabackup/

然后 Importing Transportable Tablespaces for Non-partitioned Tables https://mariadb.com/kb/en/innodb-file-per-table-tablespaces/#importing-transportable-tablespaces-for-non-partitioned-tables

部分备份：

https://mariadb.com/kb/en/partial-backup-and-restore-with-mariabackup/

进一步了解Mariabackup:

Mariabackup备份的文件： https://mariadb.com/kb/en/files-backed-up-by-mariabackup/

Mariabackup创建的文件： https://mariadb.com/kb/en/files-created-by-mariabackup/

Apple Music Electron

ttyS3 — Sun, 07 Mar 2021 07:04:47 GMT

正如 Apple-Music-Electron repo 上简介里说的：

适用于Windows，Linux和macOS的非官方Apple Music应用程序，而无需安装iTunes或通过浏览器使用极其臃肿的Web应用程序。

这也是老灯在 Linux 下要这么一个 app 的原因。对于老灯来说，浏览器在大部分情况下都是用来浏览文档，调试代码。里面夹杂着一个在线音乐播放网站可不好找，特别是tab非常多的情况下。因此，有一个独立的 app 就非常重要的。哪怕只是拿 Electron 框架包裹一下 https://beta.music.apple.com/ , 老灯也觉得这类 app 非常有意义。Life changed.

功能简介

在 Github 上找到两个，分别只有30多和10多个star, 两个老灯都试用了一下。

安装就不说了哈，直接 Github release 里下载相应的 rpm 或 deb 包安装即可。

cryptofyre/Apple-Music-Electron

https://github.com/cryptofyre/Apple-Music-Electron 各方面都比较出色，黑色界面，唯一的缺点是没有竖直滚动条。顶部播放条的艺人名称和歌曲名称可点击。老灯选择的是这个。

17hoehbr/apple-music-electron

https://github.com/17hoehbr/apple-music-electron 直接套用了 https://beta.music.apple.com/ 的主题，有竖直滚动条。缺点是顶部播放条的艺人名称和歌曲名称无法点击。

troublesoot

点击播放时弹出`CONTENT_EQUIVALENT`错误

解决办法：重启 app 就好了。

原因是，Apple Music 使用了DRM加密， Electron wrapper 在首次启动的时候需要联网下载一个 Widevine DRM 解密模块。重启启动 app , 一般 libwidevinecdm.so 下载成功了，就可以正常播放了。

你可以通过查看 ~/.config/Apple Music/WidevineCDM 目录下的文件检测 DRM 模块是否下载成功。如：

❯ ls -lh ~/.config/Apple Music/WidevineCDM 
.rw-r--r-- ttys3 ttys3 8.9 MB Sun Mar  7 11:41:14 2021  libwidevinecdm.so
.rw-r--r-- ttys3 ttys3 479 B  Sun Mar  7 11:41:14 2021  LICENSE.txt
.rw-r--r-- ttys3 ttys3 375 B  Sun Mar  7 11:41:14 2021  manifest.json
❯ bat manifest.json
{
    "arch": "x64",
    "description": "Widevine Content Decryption Module",
    "manifest_version": 2,
    "name": "WidevineCdm",
    "os": "linux",
    "version": "4.10.1582.2",
    "x-cdm-codecs": "vp8,vp9.0,avc1,av01",
    "x-cdm-host-versions": "10",
    "x-cdm-interface-versions": "10",
    "x-cdm-module-versions": "4",
    "x-cdm-persistent-license-support": true
}
  ~/.config/Apple Music/WidevineCDM

Failed to install Widevine component, Error 400

一般是由于网络问题，导致 Electronjs 自动下载 Widevine DRM 组件失败。

在安装了 Chrome 的 Linux 机器上，直接Copy Chrome 自带的 Widevine 组件即可.

在 Ubuntu 上这个位置是：

/opt/google/chrome/WidevineCdm/_platform_specific/linux_x64/libwidevinecdm.so

# 先启动一次 app
# 然后创建目录 WidevineCDM
mkdir ~/.config/Apple\ Music/WidevineCDM/

❯ cp -v /opt/google/chrome/WidevineCdm/_platform_specific/linux_x64/libwidevinecdm.so ~/.config/Apple\ Music/WidevineCDM/
'/opt/google/chrome/WidevineCdm/_platform_specific/linux_x64/libwidevinecdm.so' -> '/home/ttys3/.config/Apple Music/WidevineCDM/libwidevinecdm.so

Chrome 打开 chrome://components/ 查看 “Widevine Content Decryption Module” 的版本号，老灯这里是“Version: 4.10.2209.0”

然后在 ~/.config/Apple Music/WidevineCDM 下新建 manifest.json 内容如下：

{
    "arch": "x64",
    "description": "Widevine Content Decryption Module",
    "manifest_version": 2,
    "name": "WidevineCdm",
    "os": "linux",
    "version": "4.10.2209.0",
    "x-cdm-codecs": "vp8,vp9.0,avc1,av01",
    "x-cdm-host-versions": "10",
    "x-cdm-interface-versions": "10",
    "x-cdm-module-versions": "4",
    "x-cdm-persistent-license-support": true
}

启动一次 app, 然后关闭，再启动就 OK 了。

已经播放过的歌曲缓存在哪里？

经过老灯的分析，这个目录是在 ~/.config/Apple Music/Cache

ncdu 1.15.1 ~ Use the arrow keys to navigate, press ? for help
--- /home/ttys3/.config/Apple Music ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  305.0 MiB [##########] /Cache
   28.9 MiB [          ] /Service Worker
    8.9 MiB [          ] /WidevineCDM
    2.2 MiB [          ] /Code Cache
  448.0 KiB [          ] /Dictionaries
  300.0 KiB [          ] /GPUCache
  120.0 KiB [          ] /File System
  108.0 KiB [          ] /IndexedDB
   52.0 KiB [          ]  QuotaManager
   40.0 KiB [          ] /Local Storage
   32.0 KiB [          ] /databases
   28.0 KiB [          ]  Cookies
   28.0 KiB [          ] /Session Storage
    8.0 KiB [          ] /blob_storage
    8.0 KiB [          ] /Downloads
    8.0 KiB [          ]  TransportSecurity
e   4.0 KiB [          ] /Crash Reports
    4.0 KiB [          ]  Network Persistent State
    4.0 KiB [          ]  Preferences
    0.0   B [          ]  QuotaManager-journal
    0.0   B [          ]  Cookies-journal

我的系统是英文界面的，如何强制 Apple Music 显示中文？

这其实是老灯的需求，系统语言习惯设置成英文。但是，对于一些奇怪的歌曲名称，尤其是中国传统民族乐器经典曲目，我相信没几个人看到英文名称能翻译成中文。

这个也简单，修改启动命令，添加 LANG=zh_CN.UTF-8 环境变量即可。

sudo sed -i 's|Exec="/opt|Exec=env LANG=zh_CN.UTF-8 "/opt|' /usr/share/applications/apple-music-electron.desktop


❯ bat /usr/share/applications/apple-music-electron.desktop
[Desktop Entry]
Name=Apple Music
Exec=env LANG=zh_CN.UTF-8 "/opt/Apple Music/apple-music-electron" %U
Terminal=false
Type=Application
Icon=apple-music-electron
StartupWMClass=Apple Music
Comment=Unofficial Electron wrapper for Apple Music created by @cryptofyre
Categories=AudioVideo;

refs

Widevine DRM 介绍 https://zh.wikipedia.org/wiki/Widevine

关于 DRM 音频转换成 mp3 或 flac, 好像工具挺多的，比如 TuneFab iTunes Audio Converter （收费）

The Good and The Bad of Fedora Linux

ttyS3 — Fri, 05 Mar 2021 14:27:14 GMT

The good

DeltaRPM 是个好东西，可以节省更新的流量和本地cache的package空间
Fedora Linux has supported binary delta updates by default using the yum presto plugin since June 2009. This is based on RPM Package Manager's deltarpm system (2004), which was in turn based on bsdiff.[[1]](https://en.wikipedia.org/wiki/Delta_update#cite_note-1)
https://en.wikipedia.org/wiki/Delta_update
然而Arch做了与这个相反的操作，把pacman的delta功能移除了。see Why delta support removed from pacman?
Because no one really used it pretty much ever.To an extent, yes. But the official repo maintainers decided it was not worth the effort, so they didn't do it.I've got to say - if you're living in a developing country with shitty internet, Arch might not be the best option for you anyway.
啥？发展中国家？哈哈，中招了。不过我们现在的网络，跑个Arch更新完全没问题了。 ps: 关于不使用 delta 更新的问题，我觉得 Arch 是对的。引入 delta 同时会引入其它问题，比如patch的时候会需要更多cpu算力，生成 delta 包时也需要更多的算力。
Overcomplicating pacman and package mirrors for minor bandwith gain kinda defeats the KISS principle of arch
软件包很新，可能没有ArchLinux新，但是肯定比Ubuntu/Debian这种喜欢用一些古董包的发行版要新（作为一个ArchLinux用户而方，by the way, 请原文我说Ubuntu/Debian用古董包）。
稳定的发布周期：每六个月定期发布
有官方博客，时不时会发一些有意思的教程。
背后有Redhat的支持
相比于Ubuntu完全受*Canonical的控制, Fedora是一个完完全全的社区支持的系统*
自带大型的软件包仓库,包数量众多（不像Ubuntu,全靠ppa撑场子）
得益于rpm包的流行程度，基本上大部分厂家或Github项目（如果有提供包），都会直接提供rpm包供用户下载
官方同时提供Workstation/Server/IoT版的iso安装镜像，同时还有Fedora CoreOS和Fedora Silverblue
多DE支持，官方除了支持GNOME3（默认选项），还有可以在Fedora Spins 下载到KDE，XFCE , LXQt, MATE Compiz, LXDE 和 Sugar on a stick (SOAS) 版。
自带SeLinux支持且默认开启，安全性没得说
对红帽系的很多东西天生支持就很好，比如FirewallD, Kvm-qemu, Cockpit
开发活跃，引领潮流。比如Fedora最先引入systemd的，后面又率先启用了EarlyOOM功能，默认启用fstrim.timer，用Geary替换了很多发行版中万年不变的Evolution邮件客户端，firewalld默认使用nftables后端, 让Python 2 彻底退休，用更安全的lchsh 代替了chsh, 默认启用 CGroup v2。rpm package压缩算法从xz level 2切换到zstd compression level 19了(从f31起）。当很多发行版还在用ext4时，f33已经将家用版的默认文件系统改成了btrfs。 f34据说要默认开启btrfs的zstd透明压缩功能
每一次新的版本发布之前，你都可以从官方wiki的 Change Set 看到完整的变更记录以及为什么要这样做的理由。相比于某些发行版一声不响就把东西改了，Fedora这种操作显得非常专业和规范。比如f34准备抛弃PulseAudio and JACK并切换到 PipeWire
基于图片界面的 Anaconda System installer 使用起来非常方便，尤其是磁盘分区功能非常好用。Anaconda 安装完后系统后会自动生成 kickstart 脚本，方便二次安装或批量自动化安装。
官方明确支持 Do What The Fuck You Want To Public License (WTFPL)
Fedora 上的 GNOME Software 是原版的，如果有需要，你可以自行添加添加flatpak源。（不会像 Ubuntu 一样用 Canonical 自家的软件中心强制用户只能安装snap app）

The bad

社区论坛需要使用Fedora官方的Fedora Account System (FAS) account进行登录。作为一个习惯了使用Github/Gitlab或Google账号一键登录的人，直接导致了我点击了浏览器的x按钮关闭页面，因为我不想浪费太多时间在注册账号这种事情上。
比如有个人问如何在Fedora上使用百度网盘（因为Fedora和Arch的openssl包都很新，百度那破玩意一跑就崩），我很想帮助他，因为我研究之后，成功地正常运行了。但是当我点击登录的时候，我被重定向到了Fedora Account System (FAS) account，没有使用其它社交账号登录的按钮。这其实也很正常，因为Fedora一直坚持FOSS的理念。使用一个商业公司的账号体系来登录，有违FOSS精神。
Fedora非常提倡FOSS，版权策略简直应用到了变态的地步。比如官方仓库里的p7zip包，因为p7zip官方源码里包含了未经授权的rar相关代码，Fedora直接用patch将rar相关代码全部移除了。
Fedora package note: non-Free unrar code have been removed from the sources (#190277)
7z的作者Igor Pavlov也针对这个回复了一些有疑问的人。 Igor Pavlov ( sourceforge.net/p/sevenzip/discussion/45798/thread/dc2d0438/#8f9f ):
fedora/centos have removed 7-zip's unrar code as non-free code. Maybe you can use p7zip compiled for another linux systems with 7-zip's unrar plugin: p7zip-full and p7zip-rar
RAR code is divided into two parts in p7zip:
1. free part of unrar (in p7zip-full)
2. non-free part of unrar (p7zip-rar)
But fedora have removed both parts of unrar code.
等于是别人家的7z命令都能解压rar,你Fedora家的不能。为此老灯专门写了一个rpm spec用于构建完整功能版的p7zip
不是开箱即用，对新手极略不友好：比如最基本的需求，安装Nvidia或AMD显卡驱动，或者Intel GPU vaapi 支持驱动，你得从一个叫rpmfusion的第三方仓库安装。
RPM Fusion项目是社区维护的软件存储库，提供了由于法律原因无法在Fedora中分发的其他软件包。软件专利适用于RPM Fusion中的某些软件包，因此，在某些国家/地区安装这些软件包可能不合法：例如，在美国或日本。
RPM Fusion还提供用于Red Hat Enterprise Linux的软件包
https://docs.fedoraproject.org/en-US/quick-docs/setup_rpmfusion/#con_the-purpose-of-rpm-fusion_enabling-the-rpmfusion-repositories
有些常见的包名没有采用通用名字，比如nodejs包管理工具yarn, 在Fedora里叫yarnpkg
Fedora的文档不是很多（尽管如此，它的文档依旧比Ubuntu的要好），虽然RHEL 的文档非常全面，但是基本上那些是跟Server相关的。一旦你要查找桌面环境相关的问题，你会发现Fedora的文档少得可怜。文档这方面ArchLinux可能是做得最好的（没有之一）。

refs

https://fedoramagazine.org/

Remove support for deltas from libalpm

https://www.reddit.com/r/archlinux/comments/b7zkg5/why_delta_support_removed_from_pacman/

https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Development_Schedule

https://en.wikipedia.org/wiki/List_of_Linux_distributions#Fedora-based

https://spins.fedoraproject.org/

https://ttys3.dev/post/linux/fedora/fedora31-upgrade-to-fedora32/

https://ttys3.dev/post/linux/fedora/fedora32-upgrade-to-fedora33/

https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zstd_compression

https://fedoraproject.org/wiki/Changes/BtrfsByDefault

https://fedoraproject.org/wiki/Changes/BtrfsTransparentCompression

https://fedoraproject.org/wiki/Changes

https://docs.fedoraproject.org/en-US/quick-docs/setup_rpmfusion/

https://codeghar.wordpress.com/2012/09/26/fedora-the-good-the-bad-and-the-ugly/ （很古老的文章，有一定的参考意义，但是其中很多问题已经不存在了）

https://en.wikipedia.org/wiki/Anaconda_(installer)

https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses

https://fedoraproject.org/wiki/Licensing:FAQ

https://fedoraproject.org/wiki/Third_party_repositories

Rename Hugo Blog Git Repo Branch From master To main

ttyS3 — Fri, 05 Mar 2021 06:34:37 GMT

最近编译了最新版的Git, 发现init repo的时候会提示配置全局默认branch （这事儿都是由black lives matter运动搞起的）。好吧，既然能少打一个字符，就改成 main 吧。

切换 Git 分支为 main

git checkout master

git branch -m main

# 删除本地分支
git branch -d master

# 删除远程分支
git push origin --delete master

# （并不是真正想push, 只是隐式地将远程分支设置为了跟踪main)
git push origin -u main

Github 配置

在 Github repo 设置 -> Branches 里, 将默认分支设置为 main

Netlify 配置

老灯还使用了netlify 和 netlify cms, 因此这两个的分支都要配置

Netlify Build 设置里将默认分支设置成 main

Netlify CMS admin/config.yml 默认分支设置成 main , 如果这里忘记设置了，你将无法登录 Netlify CMS 后台。

backend:
  name: git-gateway
  branch: main # Branch to update (optional; defaults to master)
  squash_merges: true # beta feature

会有如下错误：

Git Gateway Error: Please ask your site administrator to reissue the Git Gateway token.

如果你打开浏览器调试工具，你会发现它还在向 master 发送 token，这肯定是不行的。因此要修正。

另外，如果还是登录不进行，清除一下 Netlify CMS admin 的 cookies 信息和 local storage.

坑爹 -- Ubuntu 版的 Git 使用的 GnuTLS 而不是 OpenSSL 提供的 TLS 实现

ttyS3 — Wed, 03 Mar 2021 13:07:39 GMT

起因

为什么用的是Ubuntu? 老灯你不是喜欢ArchLinux的么？没错，这个Ubuntu只是老灯在工作环境使用的, 主要是团队要求。与大家保持一致。

当前我的neovim还是用的Vim Plug这个插件管理器（已经在着手准备迁移到init.lua + packer.nvim 了）。在更新neovim 插件时（:PlugUpdate ) 遇到了以下错误：

x vim-startify:
    fatal: unable to access 'https://github.com/mhinz/vim-startify.git/': gnutls_handshake() failed: The TLS connection was non-properly terminated.

gnutls_handshake() failed 非常吸睛，因为我之前在Arch和 Fedora 上使用Git 都从来不会遇到这个错误的。

再跑了下更新命令，抓取到了真正命令：

/usr/lib/git-core/git-remote-https origin https://github.com/mhinz/vim-startify.git

看来Ubuntu版的git-remote-https用的GnuTLS, 然后验证一下,果然中招了：

❯ ldd /usr/lib/git-core/git-remote-https | grep curl
        libcurl-gnutls.so.4 => /lib/x86_64-linux-gnu/libcurl-gnutls.so.4 (0x00007fc39a56b000)

编译启用 openssl 支持的 Git

当然了，这种事情，老灯不可能是第一个发现的，gist里有无数“修复”这个问题的shell脚本。 Github上也有。老灯找到一个不错了： https://github.com/paul-nelson-baker/git-openssl-shellscript fork 之，增加了多线程下载支持和多核心编译支持。毕竟，要速度嘛。

老灯的仓库在这： https://github.com/ttys3/git-openssl-shellscript

这个脚本会卸载Ubuntu自带的git (同时也会卸载git-flow), 在此之前我们先记录下原版git的样子吧：

❯ git --version
git version 2.27.0

❯ sudo apt info git
Package: git
Version: 1:2.27.0-1ubuntu1
Priority: optional
Section: vcs
Origin: Ubuntu
Maintainer: Ubuntu Developers <[email protected]>
Original-Maintainer: Jonathan Nieder <[email protected]>
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 39.2 MB
Provides: git-completion, git-core
Depends: libc6 (>= 2.28), libcurl3-gnutls (>= 7.56.1), libexpat1 (>= 2.0.1), libpcre2-8-0 (>= 10.22), zlib1g (>= 1:1.2.0), perl, liberror-perl, git-man (>> 1:2.27.0), git-man (<< 1:2.27.0-.)
Recommends: ca-certificates, patch, less, ssh-client
Suggests: gettext-base, git-daemon-run | git-daemon-sysvinit, git-doc, git-el, git-email, git-gui, gitk, gitweb, git-cvs, git-mediawiki, git-svn
Breaks: bash-completion (<< 1:1.90-1), cogito (<= 0.18.2+), dgit (<< 5.1~), git-buildpackage (<< 0.6.5), git-core (<< 1:1.7.0.4-1.), gitosis (<< 0.2+20090917-7), gitpkg (<< 0.15), gitweb (<< 1:1.7.4~rc1), guilt (<< 0.33), openssh-client (<< 1:6.8), stgit (<< 0.15), stgit-contrib (<< 0.15)
Replaces: git-core (<< 1:1.7.0.4-1.), gitweb (<< 1:1.7.4~rc1)
Homepage: https://git-scm.com/

git clone https://github.com/ttys3/git-openssl-shellscript.git
cd git-openssl-shellscript

./compile-git-with-openssl.sh --skip-tests

编译安装完，检查下：

❯ git --version
git version 2.31.0-rc1

没找到git-remote-https 在哪，随便clone个大仓库（为我们ps | grep 争取时间），然后找出来路径。

# 并不是真正要clone内核源码。。。
❯git clone https://github.com/torvalds/linux.git

# 新开另一个tab找路径
❯ ps aux | grep 'torvalds/linux'
ttys3    2887728  0.0  0.0  15060  3964 pts/18   S+   16:17   0:00 /usr/libexec/git-core/git remote-https origin https://github.com/torvalds/linux.git
ttys3    2887729  4.0  0.0 108636 14272 pts/18   R+   16:17   0:00 /usr/libexec/git-core/git-remote-https origin https://github.com/torvalds/linux.git

# 找到了，看看
❯ ldd /usr/libexec/git-core/git-remote-https | grep libcurl
        libcurl.so.4 => /lib/x86_64-linux-gnu/libcurl.so.4 (0x00007ff2e529d000)

这次我们依赖的是libcurl4-openssl-dev (而不是libcurl4-gnutls-dev）

❯ dpkg -L libcurl4-openssl-dev ... /usr/lib/x86_64-linux-gnu/libcurl.so ...


## troubleshoot

编译的时候，由于要查找原包的依赖，因此需要启动apt仓库的 `deb-src` 源。

ensure you have `deb-src` enabled in `/etc/apt/sources.list`

以下是老灯的配置（Ubuntu 20.10):

```shell
❯ cat /etc/apt/sources.list | grep -v '#'

deb https://mirrors.sjtug.sjtu.edu.cn/ubuntu groovy main restricted
deb-src https://mirrors.sjtug.sjtu.edu.cn/ubuntu groovy main restricted

deb https://mirrors.sjtug.sjtu.edu.cn/ubuntu groovy-updates main restricted
deb-src https://mirrors.sjtug.sjtu.edu.cn/ubuntu groovy-updates main restricted

deb https://mirrors.sjtug.sjtu.edu.cn/ubuntu groovy universe
deb-src https://mirrors.sjtug.sjtu.edu.cn/ubuntu groovy universe

deb https://mirrors.sjtug.sjtu.edu.cn/ubuntu groovy-updates universe
deb-src https://mirrors.sjtug.sjtu.edu.cn/ubuntu groovy-updates universe

deb https://mirrors.sjtug.sjtu.edu.cn/ubuntu groovy multiverse
deb-src https://mirrors.sjtug.sjtu.edu.cn/ubuntu groovy multiverse

deb https://mirrors.sjtug.sjtu.edu.cn/ubuntu groovy-updates multiverse
deb-src https://mirrors.sjtug.sjtu.edu.cn/ubuntu groovy-updates multiverse

deb https://mirrors.sjtug.sjtu.edu.cn/ubuntu groovy-backports main restricted universe multiverse
deb-src https://mirrors.sjtug.sjtu.edu.cn/ubuntu groovy-backports main restricted universe multiverse


deb https://mirrors.sjtug.sjtu.edu.cn/ubuntu groovy-security main restricted
deb-src https://mirrors.sjtug.sjtu.edu.cn/ubuntu groovy-security main restricted

deb https://mirrors.sjtug.sjtu.edu.cn/ubuntu groovy-security universe
deb-src https://mirrors.sjtug.sjtu.edu.cn/ubuntu groovy-security universe

deb https://mirrors.sjtug.sjtu.edu.cn/ubuntu groovy-security multiverse
deb-src https://mirrors.sjtug.sjtu.edu.cn/ubuntu groovy-security multiverse

新版本的Git 提升将默认的master 分支修改为 main （美国黑人运动的结果，影响无处不在啊，据说Mysql也要把主从同步里的相关术语里的master和slave改掉呢）

❯ git init .
hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint:
hint:   git config --global init.defaultBranch <name>
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint:   git branch -m <name>

得，那就配置一下吧， git config --global init.defaultBranch main

main 还能少打一个字节。

Time to say goodbye -- Chromium Google账号同步功能将于3月15日停止工作

ttyS3 — Tue, 02 Mar 2021 16:34:06 GMT

这个消息其实很早Google就放出了。

早在1月25号左右，Fedora打包的Chromium就已经移除了账号同步功能。

Fedora's Chromium maintainer suggests switching to Firefox as Google yanks features in favour of Chrome

'They're not closing a security hole, they're just requiring that everyone use Chrome'

FEDORA-2021-48866282e5 created by spot for Fedora 33

This is probably not the update you want.
Let me be clear, it does fix the security vulnerabilities in this list:
CVE-2020-16044 CVE-2021-21118 CVE-2021-21119 CVE-2021-21120 CVE-2021-21121 CVE-2021-21122 CVE-2021-21123 CVE-2021-21124 CVE-2021-21125 CVE-2021-21126 CVE-2021-21127 CVE-2021-21129 CVE-2021-21130 CVE-2021-21131 CVE-2021-21132 CVE-2021-21133 CVE-2021-21134 CVE-2021-21135 CVE-2021-21136 CVE-2021-21137 CVE-2021-21138 CVE-2021-21139 CVE-2021-21140 CVE-2021-21141 CVE-2021-21117 CVE-2021-21128
But it will not behave like Google Chrome does.
Google has announced that it is cutting off access to the Sync and "other Google Exclusive" APIs from all builds except Google Chrome. This will make the Fedora Chromium build significantly less functional (along with every other distro packaged Chromium). It is noteworthy that Google gave the builders of distribution Chromium packages these access rights back in 2013 via API keys, specifically so that we could have open source builds of Chromium with (near) feature parity to Chrome. And now they're taking it away. The reasoning given for this change? Google does not want users to be able to "access their personal Chrome Sync data (such as bookmarks) ... with a non-Google, Chromium-based browser." They're not closing a security hole, they're just requiring that everyone use Chrome.
Or to put it bluntly, they do not want you to access their Google API functionality without using proprietary software (Google Chrome). There is no good reason for Google to do this, other than to force people to use Chrome.
I gave a lot of thought to whether I wanted to continue to maintain the Chromium package in Fedora, given that many (most?) users will be confused/annoyed when API functionality like sync and geolocation stops working for no good reason. Ultimately, I decided to continue for now, because there were at least some users who didn't mind, and if I stopped, someone else would start over and run blindly into this problem.
I would say that you might want to reconsider whether you want to use Chromium or not. If you want the full "Google" experience, you can run the proprietary Chrome. If you want to use a FOSS browser that isn't hobbled, there is a Firefox package in Fedora.
Oh, last, but not least, Google isn't shutting off the API access until March 15, 2021, but I have gone ahead and disabled it starting with this update. I'd rather you read about it here (even though most users will never see this) than have it just happen.

根据 omg!ubuntu 的文章，主要被砍掉的功能包括：

Google account sync
Geolocation
Click to Call
Chrome spelling API
Contacts API
Chrome translate element

不用Chromium，选哪个？

Mozilla Firefox

开源产品里面，好像基本上没太多选择，大家一致推荐Mozilla Firefox.

老灯用Mozilla Firefox也比较多，但是，最近反而是这个Chromium浏览器事件，使得我重新思考，是不是要弃Firefox而转用其它了。

这么多年了，Firefox的渲染和网页打开速度还是PK不过Chrome(或Chromium系). 我4K 浏览器，每天打开Firefox 都要按 F11 最大化 Firefox, 然后再切回正常大小。而我这波操作完全只是为了让Firefox恢复正常的窗体大小，这么多年了，Firefox这点事都做不好。还有一个一直存在的“background-color 样式在 Linux 下不工作”的问题，见我之前的文章

不过Firefox也有很多地方做得不错的，比如浏览器项目一直坚做持下来了，还搞出来个Rust语言。

还有 Firefox开发者版开箱即用，对开发者比较友好。自带的 lockwise app (iOS/Android) 可以自动同步Firefox记录的密码，相当于一个比较简陋版的 1Password 之类的app了。lockwise 能够满足基本需求，我也用了蛮久的。

Chrome

习惯了Google系的，可以选择用闭源的 Chrome.

除了stable版，这个repo还有 google-chrome-beta 和 google-chrome-unstable

# Fedora 33
dnf install fedora-workstation-repositories
dnf config-manager --set-enabled google-chrome
sudo dnf install google-chrome-stable

# CentOS/RHEL 8.2/7.8
cat << EOF > /etc/yum.repos.d/google-chrome.repo
[google-chrome]
name=google-chrome
baseurl=http://dl.google.com/linux/chrome/rpm/stable/x86_64
enabled=1
gpgcheck=1
gpgkey=https://dl.google.com/linux/linux_signing_key.pub
EOF

# Ubuntu
wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | sudo apt-key add - 

sudo sh -c 'echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google.list'

sudo apt-get update 
sudo apt-get install google-chrome-stable

Microsoft Edge

喜欢巨硬全家桶的，可以选 Microsoft Edge , 老灯在Fedora 33 上安装了 Edge Linux 开发预览版，目前来说体验一般，打开页面速度也不快。另外，账号同步功能也还不可用。等吧。

安装：

# Fedora
## Setup
sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc
sudo dnf config-manager --add-repo https://packages.microsoft.com/yumrepos/edge
sudo mv /etc/yum.repos.d/packages.microsoft.com_yumrepos_edge.repo /etc/yum.repos.d/microsoft-edge-dev.repo
## Install
sudo dnf install microsoft-edge-dev


# Debian/Ubuntu
## Setup
curl https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > microsoft.gpg
sudo install -o root -g root -m 644 microsoft.gpg /etc/apt/trusted.gpg.d/
sudo sh -c 'echo "deb [arch=amd64] https://packages.microsoft.com/repos/edge stable main" > /etc/apt/sources.list.d/microsoft-edge-dev.list'
sudo rm microsoft.gpg
## Install
sudo apt update
sudo apt install microsoft-edge-dev

Vivaldi

这个是啥？根据ArchLinux的wiki:

Vivaldi is a new web browser from former Opera founder & team members, based on Chromium and focused on personalization aspects.

Vivaldi 自带广告过滤器+鼠标手势。tab和窗体背景能自动根据网页主色调变色。侧边栏。

主打隐私？（这个嘛，官方宣称zero tracking）。能安装Google Chrome插件。

官方没有提供 Arch 包，好在有热心的社区贡献者

官网：看看大众对 VIVALDI 的评价

对Vivaldi最新版本的第一印象 - 它比Firefox更快。-- Barry Collins via twitter

我看了有点想笑，哈哈哈哈哈哈哈哈

这么多年了，Firefox 还是这么慢。

it's faster than Firefox.
it's faster than Firefox.
it's faster than Firefox.
it's faster than Firefox.

安装指导 ->

# DNF (Fedora)
sudo dnf config-manager --add-repo https://repo.vivaldi.com/archive/vivaldi-fedora.repo
sudo dnf install vivaldi-stable

# APT (Utuntu/Debian)
# apt-key is deprecated
curl https://repo.vivaldi.com/archive/linux_signing_key.pub  | gpg --dearmor > vivaldi.gpg
sudo install -o root -g root -m 644 vivaldi.gpg /etc/apt/trusted.gpg.d/
sudo rm vivaldi.gpg
sudo add-apt-repository 'deb https://repo.vivaldi.com/archive/deb/ stable main'
sudo apt update && sudo apt install vivaldi-stable

# H.264 and AAC support
sudo apt-get install chromium-codecs-ffmpeg-extra


# Pacman see https://wiki.archlinux.org/index.php/Vivaldi
# for media codec installation guide
sudo pacman -S vivaldi

我要吐槽一下，Vivaldi repo 那个服务器是真的慢。。。基本上64KB/s的下载速度。

https://vivaldi.com/blog/troubleshoot-common-problems-vivaldi/

https://vivaldi.com/blog/browse-fast-with-mouse-gestures/

https://vivaldi.com/blog/vivaldi-browser-open-source/

Vivaldi 老灯试用了两天，有发现一些奇怪的问题，比如有些页面打不开或很慢（跟Firefox一样），但是换成Chrome就能打开或者打开很快。另外，在有些情况下，多打开一些页面会导致 Vivaldi 吃到 100% 的 CPU 从而导致Vivaldi浏览器自身假死或非常卡。

默认不支持H264和 AAC 解压，需要额外安装包，见 https://gist.github.com/BlackIkeEagle/5c00face3c7a0f98847a

或 https://gist.github.com/cega/258ca210e4cd3f02cdca5b721b9045ba

安装完记得打开 https://help.vivaldi.com/desktop/media/html5-proprietary-media-on-linux/ 测试一下 H.264 (video) and AAC (audio)支持。

这个页面有更多的测试面： https://html5test.com/index.html

refs

https://www.theregister.com/2021/01/25/use_firefox_fedora_chromium_maintainer/

https://bodhi.fedoraproject.org/updates/FEDORA-2021-48866282e5

https://www.omgubuntu.co.uk/2021/01/chromium-sync-google-api-removed

https://vivaldi.com/zh-hans/

https://help.vivaldi.com/desktop/install-update/manual-setup-vivaldi-linux-repositories/

https://www.microsoftedgeinsider.com/en-us/download?platform=linux-rpm

https://www.if-not-true-then-false.com/2010/install-google-chrome-with-yum-on-fedora-red-hat-rhel/

https://www.ubuntuupdates.org/ppa/google_chrome

部署基于 Rust 的第三方 Bitwarden 服务端容器

ttyS3 — Tue, 02 Mar 2021 14:58:32 GMT

更新

2021-06-30 更新：项目名称现在更改为 vaultwarden 了，详情见 https://github.com/dani-garcia/vaultwarden/discussions/1642

缘由

1password太贵, 关键是这类软件好像以前还有数据泄露事例。

在此之前老灯用的是Firefox Lockwise , 只能说基本上够用吧。管理密码功能在Firefox上操作。其实就是Firefox本身的功能。 Lockwise app 只是协助在手机端给你自动填充密码。

这次Google 停止Chromium账号同步功能事件，使得我重新花时间思考了一下，我要切换浏览器的事情。

这一年多以来，老灯重回Firefox, 刚开始真的很不适应，你们懂的。唯一不适应的就是：慢。打开网页超级慢。

（因为习惯了Chrome和Chromium的快）

然而一年过去了，Firefox打开页面的速度并不见得有什么提升。同时有一些在任何其它浏览器都没有的问题，

在Firefox会出现。fix: (native wayland和硬件加速的支持已经和 Chromium 一样可以试验性开启了。) , 最明显的可能是 4K 屏下打开Firefox 要按两次 F11 解决窗口大小问题吧（用过的就懂我在说什么）。

不过，一个Firefox进程打开4000多个tab不会炸机（没错，我真的有四千个tab没关），这一点 Firefox 确实比吃内存狂魔 Chrome 要好。

切换掉Firefox 对于我来说，等于要卸载 Firefox Lockwise . 因此得找个替代的app.

为什么是Bitwarden

综合考虑之下，选择了 Bitwarden.

全套开源(desktop, mobile, server)
官方同时提供付费服务（有商业支持，能确保开源项目持续）
其实官方的 free 版也足够大部分人使用，比如我。

唯一我不太喜欢的可能是，server端是基于C#实现了，同时要mssql 数据库的支持。

虽然官方有提供docker compose 文件，可以一键 up. 但是对于个人需求来说，为了一个server api, 起一堆的容器，我也不太喜欢。另外，起这么多容器，vps的配置也是要相应的跟得上的。

不过，翻看博客，找到了一个基于Rust 实现的all in one 的 Bitwarden server:

https://github.com/dani-garcia/vaultwarden

这个版本相对于官方的C#版有什么区别？

除了一些企业版的功能，其它的应该有的都有。可以说对于个人用户是没有影响的。
小巧啊，all in one 啊，只要跑一个容器。据说只需要10M左右的内存给它跑！

自己构建 Bitwarden 容器镜像

如果不想使用默认的镜像，可以自己构建，很简单。

# 构建 docker 镜像:
docker build -t bitwarden_rs .

# 要使用 MySQL 后端, 则
docker build -t bitwarden_rs --build-arg DB=mysql .

# 要使用 Postgresql 后端
docker build -t bitwarden_rs --build-arg DB=postgresql .

当然也可以直接用Rust toolchain编译二进制：

# 使用所有后端编译(二进制位于 target/release/bitwarden_rs)
cargo build --features sqlite,mysql,postgresql --release

#仅使用 sqlite 编译(二进制位于 target/release/bitwarden_rs)
cargo build --features sqlite --release

# 仅使用 mysql 编译(二进制位于 target/release/bitwarden_rs)
cargo build --features mysql --release

# 仅使用 postgresql 编译(二进制位于 target/release/bitwarden_rs)
cargo build --features postgresql --release

构建web ui (web-vault)

可以直接从 dani-garcia/bw_web_builds 下载web-vault的编译版本。

*注意：构建密码库需要约 1.5GB 的 RAM。在具有 1GB 或更小容量的 RaspberryPI 之类的系统上，请启用交换功能或在功能更强大的计算机上构建，然后从那里将文件复制过来。仅构建时需要大量内存，而运行带密码库的 bitwarden_rs 仅需要***约 10MB** 的 RAM。

1、克隆 bitwarden/web git 库，并检查最新的发行标签（例如 v2.18.2）：

# 克隆库
git clone https://github.com/bitwarden/web.git web-vault
cd web-vault
# 切换到最新的标签
git checkout "$(git tag --sort=v:refname | tail -n1)"

2、从 dani-garcia/bw_web_builds 下载补丁文件并将其复制到 web-vault 文件夹。选择要使用的补丁文件的版本（假设网页密码库版本为 vX.Y.Z）：

如果有版本为 vX.Y.Z 的补丁，则使用该版本
否则，选择小于 vX.Y.Z 的最大的那一个版本

3、应用补丁：

# 在'web-vault'目录中运行命令
git apply vX.Y.Z.patch

4、然后，构建

npm install
# Read the note below (we do use this for our docker builds).
# 运行 npm audit fix 以修复漏洞。这将自动尝试将软件包升级到较新的版本，
# 该版本可能不兼容并破坏web-vault功能。
# 如果知道自己在做什么，请自行承担风险。
# npm audit fix
npm run dist

5、最后将 build 文件夹的内容复制到目标文件夹中：

如果与 cargo run --release 一起运行，则目标文件夹为 bitwarden_rs/web-vault。
如果直接运行已编译的二进制，则它位于二进制旁，为 bitwarden_rs/target/release/web-vault

老灯构建完已经推到docker hub了：

https://hub.docker.com/r/80x86/vaultwarden

启动 Bitwarden 容器

# 删除旧的容器，如果有
docker stop bitwarden && docker rm bitwarden

# 准备数据目录，你也可以存别的地方, vps 没有额外的数据盘的可以直接这样
mkdir /bw-data/

# 先拉一下，方便run 顺利执行
docker pull 80x86/vaultwarden:latest

# 创建并启动容器
docker run -d --name bitwarden \
--restart unless-stopped \
-e WEBSOCKET_ENABLED=true \
-e ROCKET_WORKERS=20 \
-e SIGNUPS_ALLOWED=false \
-e INVITATIONS_ALLOWED=false \
-p 3012:3012 \
-p 2052:80 \
-v /bw-data/:/data/ \
80x86/vaultwarden:latest

# by the way, rs的是这个
#bitwardenrs/server:latest

# 启动后，可以用以下命令观察日志有没有错误 
docker logs -f bitwarden

解释： -e SIGNUPS_ALLOWED=false 禁用新用户注册，如果只准备给自己使用，则可以用这个选项禁止其它人注册。注意，容器第一次启动时，请将这个选项设置成 true 开启注册，等你注册完了自己的账号，就可以关闭注册了。当然，如果你开启了admin后台，也可以通过admin发起邀请注册。

-e INVITATIONS_ALLOWED=false 禁用（普通用户的）邀请权限

如果机器有开 firewalld 防火墙的，注意开放 443 端口，等会我们要用到。

# 防火墙配置
firewall-cmd --zone=public --permanent --add-port=443/tcp

# 看看现在开放的端口
firewall-cmd --zone=public --permanent --list-ports

# 重载配置（注意，如果有其它容器在跑，这个会影响nat转发规则）
# 对于podman 可以用 network reload 命令修复 iptables 规则。
firewall-cmd --reload

nginx反向代理+启用https

因为 Bitwarden web vault UI 使用的 Web Crypto API，大多数浏览器只有在 HTTPS 环境下才能正常工作。

（推荐）把 bitwarden_rs 放在一个反向代理后面。比如用nginx来处理 HTTPS 连接

（不推荐）启用 bitwarden_rs 内置的 HTTPS 功能（通过 Rocket 网络框架）。Rocket 的 HTTPS 实现相对不成熟且有限。此方式也不支持 WebSocket 通知。

有关这些选项的更多细节，请参考启用 HTTPS 部分。

这里老灯选择最简单的方案：

nginx反向代理 + Cloudflare 代理

Cloudflare 里面的tls 配置成 full 模式。然后nginx使用自签名的证书就OK了（cf的 full 模式不会校验 origin server之间的ca 证书, 因此可以放心地用自签名证书)

由于前置了cf, 真正的证书是cf自动分发的。因此 origin server (也就是我们的nginx反向代理）自签名证书完全不会给浏览器红色警告。

当然，也可以使用 ACME 客户端获取 Let's Encrypt 证书。一些反向代理（例如 Caddy）也内置支持使用 ACME 协议获取证书。

老灯这里用nginx,是因为服务器上已经有nginx在跑了，并且占用了80和443端口。

如果是全新的服务器，并且80和443没有被占用，我建议使用 Caddy 配置起来更简单。

启用 WebSocket 通知

要启用 WebSockets 通知，必须使用外部反向代理，并且必须执行以下配置操作：

将 /notifications/hub 端点路由到 WebSocket 服务器，默认在 3012 端口，确保传递 Connection 和 Upgrade 头。（提示：可以使用 WEBSOCKET_PORT 变量来更改端口）
将所有其他（包括 /notifications/hub/negotiate）路由到标准 Rocket 服务器，默认在 80 端口上。
如果使用 Docker，则可能还需要使用 -p 标识来映射两个端口。

tips: 由于 Rocket (荒野注：这个server api是基于Rust生态一个叫Rocket的框架开发的) 缺乏对 WebSockets 的支持（尽管这是计划的功能），因此要在单独的端口上启动ws服务器。

当 bitwarden_rs 运行时，默认它会产生 2 * <cpu 核心数> 个 worker 来处理请求。在某些系统上，这可能会由于 worker 数量太少，从而导致性能降低，因此在 docker 镜像中更改为默认产生 10 个线程。可以通过设置ROCKET_WORKERS变量来增加或减少 worker 数量以覆盖此默认设置。

最后，老灯的配置如下：

server {
        listen 443 ssl http2;
        server_name 你的域名填写在这里;

        # Allow large attachments
        client_max_body_size 128M;

        ssl_certificate    ssl/证书文件名.crt;
        ssl_certificate_key ssl/私钥文件名.key;

        limit_conn conn_limit_per_ip 4;
        limit_req zone=req_limit_per_ip burst=4 nodelay;
        limit_rate 256k;

        access_log  /var/log/nginx/bw.access.log;
        error_log  /var/log/nginx/bw.error.log;

        location / {
            proxy_pass http://127.0.0.1:2052;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }

        location /notifications/hub {
        proxy_pass http://127.0.0.1:3012;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        }

        location /notifications/hub/negotiate {
        proxy_pass http://127.0.0.1:2052;
        }
}

TLS 检测

TLS 检测工具：

可以使用 https://comodosslstore.com/ssltools/ssl-checker.php 网站来检查 SSL 证书是否包含证书链。缺少证书链，Android 设备将无法连接。

也可以使用 https://www.ssllabs.com/ssltest/analyze.html 网站进行检查，但是它不支持自定义端口。一定要记住选中“Do not show the results on the boards”复选框，不然你的网址就在“Recently Seen”列表中公开暴露了。

也可以使用 openssl 工具来验证

openssl s_client -showcerts -connect vault.domain.com:443

# 或者使用的其他端口，比如 7070
openssl s_client -showcerts -connect vault.domain.com:7070

# 输出的开头应类似于以下内容（使用 Let's Encrypt 证书）：
# 有 3 个不同depth（注意，它是从 0 开始的）级别的验证
CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = vault.domain.com
verify return:1

Web Vault Admin界面

这里主要是给管理人员用的，对于个人用户单用户来说，就没有必要打开这里了。

启动管理界面，需要在创建容器时指定环境变量： -e ADMIN_TOKEN=一个超级复杂的密码

有关这些选项的更多细节，请参考启用管理页面部分。

这个密码可以直接用命令生成： openssl rand -base64 48

测试一下禁止注册功能是否正常：

用户Web Vault界面

支持上游发展

最后，开源不易，有能力的大家尽量支持Bitwarden官方：8bit Solutions LLC 公司毕竟，开源项目要是脱离了商业支持，基本上活下去的都是奇迹。

bitwarden_rs 仅提供 API（服务器）端实现，用户仍依赖来自上游的客户端程序（移动应用程序、桌面应用程序和网页密码库），这些都是 8bit Solutions LLC 公司在上游完成的许多工作。

同时 bitwarden_rs 支持上游的某些付费功能并免费提供该功能。这就提出了一些有关维持和支持上游发展的问题。许多用户提出了这个问题，并咨询他们如何在使用 bitwarden_rs 的同时支持上游的发展。

您可以通过 PayPal 直接捐赠给上游以支持他们的发展。

https://github.com/dani-garcia/vaultwarden/wiki/Supporting-upstream

https://rs.bitwarden.in/other-information/supporting-upstream-development

refs

构建容器镜像--中文文档： https://rs.bitwarden.in/deployment/building-your-own-docker-image

构建容器镜像--英文文档 https://github.com/dani-garcia/vaultwarden/wiki/Building-your-own-docker-image

启用https https://rs.bitwarden.in/deployment/https/enabling-https

https://github.com/dani-garcia/vaultwarden/wiki/Enabling-WebSocket-notifications

https://github.com/dani-garcia/vaultwarden/wiki/Enabling-HTTPS

备份密码库 https://rs.bitwarden.in/other-information/backing-up-your-vault

反向代理教程： https://rs.bitwarden.in/deployment/proxy-examples

禁用新用户注册 https://rs.bitwarden.in/configuration/disable-registration-of-new-users

启用管理页面 https://rs.bitwarden.in/configuration/enabling-admin-page

Warning: Rocket's built-in TLS is not considered ready for production use. It is intended for development use only.

https://rocket.rs/v0.4/guide/configuration/#configuring-tls

https://github.com/dani-garcia/vaultwarden/wiki

https://github.com/dani-garcia/vaultwarden/wiki/Proxy-examples

https://bitwarden.com/help/article/import-from-firefox/

https://support.cloudflare.com/hc/en-us/articles/200170416-End-to-end-HTTPS-with-Cloudflare-Part-3-SSL-options#h_4e0d1a7c-eb71-4204-9e22-9d3ef9ef7fef

https://www.techempower.com/benchmarks/#section=data-r20

https://github.com/flosse/rust-web-framework-comparison#high-level-server-frameworks

对比：https://www.iamzs.top/archives/comparison-among-three-password-managers.html

为 Hugo 博客集成 Netlify CMS

ttyS3 — Tue, 02 Mar 2021 12:43:28 GMT

为什么需要 Netlify CMS

Netlify CMS 主要是解决了，随时随地打开浏览器写markdown博客的问题，同时它自动处理了图片上传等问题。

简单来说：

Netlify CMS = web 版的 markdown 文件管理器 + 自动图片上传并插入markdown代码 + 在web浏览器写markdown并自动推送到git仓库构建 ....

编辑器可以在富文本（所见即所得）和 Markdown 方式之间切换。 Markdown模式没有语法高亮显示，编辑起来略不方便。同时，切到 Markdown编辑模式后，编辑器的那些按钮都变灰不可用了。

Netlify CMS 只是附加功能，你完全可以在本地直接打开 NeoVim 或者 Emacs 写博客，然后用 Git push 发布文章。

代码编辑器可以自动折叠和伸展，支持选择语言，同时还支持选择是 emacs / sublime 还是 vim 编辑模式.

插入图片也非常方便，只是有一点，对于 Hugo Page Bundles 是不支持的，因此图片只能是集中上传到一个目录下(也就是配置文件中指定的 media_folder 路径)。

上传文件存相对目录和 page bundle 支持，官方正式文档里并没有说明有这个功能。后来老灯发现这些新功能在beta版已经可用了（beta 版的文档里有说明）。

beta 版的（最新版代码）可以去这里取： https://www.jsdelivr.com/package/npm/netlify-cms

由于是开源的，因此也可以在这查看changelog

部署方法

需要创建一个admin目录，里面放一个index.html 文件作为后台管理的入口。由于这个文件实际上也是要deploy到静态博客的，因此，我们要放在Hugo的 static 目录下。

static/admin/index.html 内容如下：

<!doctype html>
<html>
<head>
  <meta charset="utf-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <title>Blog Manager</title>
  <script src="https://identity.netlify.com/v1/netlify-identity-widget.js"></script>
</head>
<body>
  <!-- Include the script that builds the page and powers Netlify CMS -->
  <!-- https://www.jsdelivr.com/package/npm/netlify-cms -->
  <script src="https://cdn.jsdelivr.net/npm/[email protected]/dist/netlify-cms.min.js"></script>

</body>
</html>

static/admin/config.yml 内容如下：

# https://www.netlifycms.org/docs/add-to-your-site/
backend:
  name: git-gateway
  branch: main # Branch to update (optional; defaults to master)
  squash_merges: true # beta feature

 # when using the default proxy server port
 # Run npx netlify-cms-proxy-server from the root dir of the repo
local_backend: true

# 编辑工作流程
publish_mode: editorial_workflow


# 全局静态文件上传目录
media_folder: "static/img/uploads" # Media files will be stored in the repo under images/uploads
public_folder: "/img/uploads" # The src attribute for uploaded media will begin with /images/uploads

media_folder_relative: true


collections:
  - name: "post" # Used in routes, e.g., /admin/collections/blog
    label: "Post" # Used in the UI
    folder: "content/post" # The path to the folder where the documents are stored
    path: '{{slug}}/index' # beta feature
    media_folder: ''
    public_folder: ''
    # adding a nested object will show the collection folder structure
    nested:
      depth: 100 # max depth to show in the collection tree
      summary: '{{title}}' # optional summary for a tree node, defaults to the inferred title field
    # adding a meta object with a path property allows editing the path of entries
    # moving an existing entry will move the entire sub tree of the entry to the new location
    meta: { path: { widget: string, label: 'Path', index_file: 'index', hint: 'markdown文件路径, 对于page bundle, 如 "一级目录/二级目录/page-bundle目录/index.md", 只需要填写 "一级目录/二级目录/page-bundle目录",不
要忘记填写page-bundle目录' } }
    create: true # Allow users to create new documents in this collection
    slug: "{{year}}-{{month}}-{{day}}-{{slug}}" # Filename template, e.g., YYYY-MM-DD-title.md
    fields: # The fields for each document, usually in front matter
      - {label: "Title", name: "title", widget: "string", hint: "文章标题"}
      - {label: "Slug", name: "slug", widget: "string", required: false, hint: "Slug可以是目录,如 linux/archlinux, 此项会作为路径的功能可能会被 path meta 覆盖"}
      - {label: "Comments", name: "comments", widget: "boolean", default: true, hint: "true 允许评论, false 禁止评论"}
      - {label: "Draft", name: "draft", widget: "boolean", default: true, hint: "草稿不会 build"}
      - {label: "Publish Date", name: "date", widget: "datetime"}
      - {label: "Featured Image", name: "cover", widget: "image", required: false, hint: "封面图片"}
      - {label: "Tags", name: "tags", widget: "list", required: false, "文章标签，用半角逗号分隔"}
      - {label: "Body", name: "body", widget: "markdown", hint: "博客正文"}

注意，以上配置用于 Page bundle 模式写博客。如果设置了 slug , 则slug一定要与path` 的最后一部分（"一级目录/二级目录/page-bundle目录" 中的 "page-bundle目录"）相同，不然引入的图片路径就会不对。

这里的 comments 是老灯主题的自定义字段，表示文章是否允许评论。cover 字段也是主题里定义的，表示文章封面图。如果拿过去用，注意稍修改一下适配你自己的主题。

当前这个配置支持：

全局静态文件上传到 static/img/uploads
仅支持 page bundle 模式写文章（这也是老灯认为唯一适合的文件组织方式）
由于支持 page bundle，因此，文章图片上传也是上传到 page bundle 的目录。
支持 Netlify CMS 本地仓库模式

本地Git仓库模式

Working with a Local Git Repository https://www.netlifycms.org/docs/beta-features/#working-with-a-local-git-repository

简单启用，只需要在 config.yml 中添加 local_backend: true 即可。然后 npx netlify-cms-proxy-server 启动 proxy 即可，它默认监听 8081 端口。然后通过 hugo serve 启动，然后访问 http://localhost:1313/admin/ 即可。

如果要自定义端口，你需要在 Hugo 项目的根目录下新建一 .env 文件，内容如下：

PORT=8082

然后更新 config.yml 中的 local_backend 对象配置：

backend:
  name: git-gateway

local_backend:
  # when using a custom proxy server port
  url: http://localhost:8082/api/v1
  # when accessing the local site from a host other than 'localhost' or '127.0.0.1'
  # allowed_hosts: ['192.168.0.1']

如果需要允许局域网其它电脑访问，可以添加 allowed_hosts 配置。

toubleshoot

关于配置

Bool类型的一定要写true 和 false, 不要写成了字符串。不然后台会报错：

Error loading the CMS configuration Config Errors: 'collections[0].fields[4].required' should be boolean Check your config.yml file.

参考文档

https://zhuanlan.zhihu.com/p/56319868

https://www.netlifycms.org/docs/add-to-your-site/

https://www.netlifycms.org/docs/widgets/

https://www.netlifycms.org/docs/beta-features/#folder-collections-media-and-public-folder

https://www.netlifycms.org/docs/configuration-options/

其它

关于 Page Bundles 的支持问题，已经有人提issue了，见：

https://github.com/netlify/netlify-cms/issues/1697

https://github.com/netlify/netlify-cms/issues/513

Store Assets Relative to Content (Bundles) #1472

https://github.com/netlify/netlify-cms/issues/1472#issuecomment-557927885

Hi everyone ! Does anyone know if this feature is implemented? This is the only thing preventing us from using Netlify CMS in our project... and the documentation is not clear on what the option media_folder_relative: true allows to do. Thanks for the help :)

https://github.com/netlify/netlify-cms/issues/2696#issuecomment-614544868

Closing as media_folder_relative was removed in favour of https://www.netlifycms.org/docs/beta-features/#folder-collections-media-and-public-folder

https://github.com/netlify/netlify-cms/issues/3227

https://github.com/netlify/netlify-cms/issues/1472#issuecomment-559376878

Latest code on master branch (not published yet to beta) lets you do:

slug: 'index'
path: '{{title}}/{{slug}}'

to save a file under title/index.md for example.

Next step will be to store images with the content.

相关已经合并 PR： https://github.com/netlify/netlify-cms/pull/2958

Portainer CE 2.1.1 Initial Support Podman

ttyS3 — Tue, 16 Feb 2021 12:31:36 GMT

Portainer 是一个比较流行的Docker web ui, Docker 官方只针对Windows/Mac 有GUI支持，对于Linux则靠民间的UI了。

事实上，Portainer 应该是仅存的少数功能较完善且开发活跃的第三方 Docker UI之一.

另一个WEB UI 是RedHat 家的 cockpit (准确来说，应该叫Redhat赞助的, 不过老灯感觉区别不大), 除了管理docker容器，cockpit还支持 podman和虚拟机管理，磁盘管理等其它功能，因此它是一个dashboard, 而不是单纯的容器管理UI.

关于对podman的支持，Github早有讨论, 见 https://github.com/portainer/portainer/issues/2991

一开始, Podman 用了一个偏门的叫varlink的协议，后面还是考虑了民间的需求，推出了Docker compatible API for Podman

https://podman.io/blogs/2020/06/29/podman-v2-announce.html

In keeping with Podman’s history the restful API will work in both rootless and rootfull mode. If you run in rootfull mode, the podman service will listen on /run/podman/podman.sock and rootless is $XDG_RUNTIME_DIR/podman/podman.sock (for example: /run/user/1000/podman/podman.sock). If you install the podman-docker package, the package will set up a link between /run/docker/docker.sock and /run/podman/podman.sock.

根据Portainer作者的回答:

As Podman is Docker API 1.40 compliant, when we release Portainer CE 2.1, which will itself support the latest Docker API (currently we only support an older API ver), we are hopeful this will work.

作者的意思：当前 2.0 版本的Portainer 只支持比较老的Docker Restful API, 要 2.1 才会支持 Docker API 1.40

Portainer 不会支持 Podman, 只会支持兼容Docker API 的东西。

也就是说， Podman 的API 如果和 Docker 的不兼容，Portainer 就可能不能正常工作.

如今 2.1.1 版本的 Portainer 已经发布了，于是老灯尝试了一下Portainer 对于 Podman 的支持.

以下仅讨论Root模式，Rootless模式由于坑太多，不太建议尝试。

首先，启用Podman restful API daemon:

sudo systemctl enable --now podman.socket

测试一下：

$ sudo curl -H "Content-Type: application/json" --unix-socket /var/run/docker.sock http://localhost/_ping
OK

❯ sudo curl -H "Content-Type: application/json" --unix-socket /var/run/podman/podman.sock http://localhost/_ping
OK

部署Portainer

根据官方文档 https://documentation.portainer.io/v2.0/deploy/ceinstalldocker/ ：

sudo podman volume create portainer_data

# 注意，这里我映射到了9001端口，因为9000已经给Docker的Portainer使用了.
# 8000也是常用端口，不应该给Portainer占用了，因此这里我用的8041
sudo podman run -d -p 8041:8000 -p 9001:9000 --name=portainer \
-v /var/run/podman/podman.sock:/var/run/docker.sock \
-v portainer_data:/data portainer/portainer-ce

注意这里的sock路径我特意用的/var/run/podman/podman.sock.

执行成功后，打开 http://localhost:9001/, 然后发现有个错误： Failure: Unable to proxy the request via the Docker socket

打开浏览器控制台查看了下，以下为错误原因：

GET /api/endpoints/2/docker/networks

500 Internal Server Error

{
"message":"Unable to proxy the request via the Docker socket",
"details":"unable to find bridge plugin"
}

还有一个404错误：

GET /api/endpoints/2/docker/plugins

{"cause":"","message":"Path /plugins is not supported","response":0}

大概体验了一下，网络管理不可用，image, container 和 volume 列表显示OK. 删除功能OK.

无法查看container log, 无法进入console. 因此，目前来说，这个还达不到基本的可用标准。

很多基本功能不工作。

Podman 版本信息:

Version:      2.2.1
API Version:  2.1.0
Go Version:   go1.15.5
Git Commit:   a0d478edea7f775b7ce32f8eb1a01e75374486cb
Built:        Thu Dec 10 03:08:37 2020
OS/Arch:      linux/amd64

refs

https://documentation.portainer.io/v2.0/deploy/ceinstalldocker/

Podman Now Support Firewalld Rules Reload

ttyS3 — Tue, 16 Feb 2021 10:24:18 GMT

这个问题其实 docker 和 podman 都存在。

当前版本的 docker 采用 iptables 动态创建和销毁规则, 而 podman 则通过CNI 插件配置, 可以使用 firewalld 作为backend.

由于容器的特性-- 随时创建，随时销毁。这二者添加的 iptables 规则自然也都是动态的。这里有个问题是，如果一些其它服务执行了 flush 操作把iptables 规则清空了，则bridge网络的容器端口转发就会失效, 因为我们通过 -p 来映射端口，实际上是在 iptables 的 nat 表里创建了转发规则。

podman Github 有一个相关issue https://github.com/containers/podman/issues/5431 已经半年多了，不过最近一看，发现问题以另外一种方式解决了。

比如有人提到问题产生的场景：

Regarding the reload thing, on Fedora, NetworkManager has this postinstall line: test -f /usr/bin/firewall-cmd && firewall-cmd --reload --quiet || : Meaning when you upgrade the package, you lose rules created by podman.

解决方案就是给network命令新增加了一个reload 的子命令, 即 podman network reload.

这个命令的作用是，当你发现iptables 规则被flush掉后（对于Fedora是nft 规则), 可以用这个命令来修复缺失的规则. 而以前的做法是，只能销毁容器并重建, 有了这个reload命令，确实方便了许多。

Yes it was #8571. We now have the podman network reload command to recreate the iptables rules. This does not make the rules permanent but if they are deleted after a firewall reload you can run this command with the --all option to recreate the rules without having to restart containers.

PR 是在 Dec 8, 2020 merge的, 这个merge被包含在当前最新的 3.0.0版中.

A new command, podman network reload, has been added. This command will re-configure the network of all running containers, and can be used to recreate firewall rules lost when the system firewall was reloaded (e.g. via firewall-cmd --reload).

命令用法：

podman network reload [CONTAINER...]

# 针对所有容器用-a参数
podman network reload -a

关于podman cni firewall 插件配置

cni 默认有一些内置插件，放在单独的仓库 https://github.com/containernetworking/plugins , 这里我们用到的 firewall 插件就是其中之一。

编辑 /etc/cni/net.d/87-podman-bridge.conflist 修改firewall类型的backend 为 firewalld 即可启用firewalld作为防火墙规则后端：

    {
        "type": "firewall",
        "backend": "firewalld"
    },

取值来自 plugins/meta/firewall/firewall.go

// FirewallNetConf represents the firewall configuration.
type FirewallNetConf struct {
	types.NetConf

	// Backend is the firewall type to add rules to.  Allowed values are
	// 'iptables' and 'firewalld'.
    Backend string `json:"backend"`

    // ...
}

其实不配置也OK, 默认逻辑是：

Default to firewalld if it's running， Otherwise iptables

refs

https://github.com/containernetworking/cni

https://github.com/containernetworking/plugins

https://www.cni.dev/plugins/meta/firewall/

Rust Cross Compile for Windows target under Linux

ttyS3 — Sun, 24 Jan 2021 16:53:36 GMT

Environment

OS: Fedora 33 (Workstation Edition) x86_64
CPU: Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz x86_64
rustc: 1.49.0 (e1884a8e3 2020-12-2)
cargo: 1.49.0 (d00d64df9 2020-12-05)

Requirements

# Install build dependencies

sudo dnf install -y mingw64-gcc
sudo dnf install -y mingw64-winpthreads-static

# Add Windows Rust target
rustup target add x86_64-pc-windows-gnu
rustup toolchain install stable-x86_64-pc-windows-gnu

Building

cargo new hello
cd hello
cargo build --target x86_64-pc-windows-gnu

交叉编译默认的hello world, 需要链接 libpthread.a，如果上面我们没有安装 mingw64-winpthreads-static 包，则会在链接时产生一个错误:

❯ cargo build --target x86_64-pc-windows-gnu
   Compiling hello v0.1.0 (/tmp/hello/hello)
error: linking with `x86_64-w64-mingw32-gcc` failed: exit code: 1
...
  = note: /usr/lib/gcc/x86_64-w64-mingw32/10.2.1/../../../../x86_64-w64-mingw32/bin/ld: cannot find -l:libpthread.a
          collect2: error: ld returned 1 exit status


error: aborting due to previous error

error: could not compile `hello`

To learn more, run the command again with --verbose.

遇到这种问题解决一般也比较简单，以mingw64为关键字搜索，安装对应的静态库就好了，

❯ sudo dnf search mingw64 | rg pthread
Last metadata expiration check: 0:57:48 ago on Mon 25 Jan 2021 01:43:34 AM CST.
mingw64-winpthreads.noarch : MinGW pthread library for the win64 target
mingw64-winpthreads-static.noarch : Static version of the MinGW Windows pthreads library

❯ sudo dnf install mingw64-winpthreads-static

Misc

gnu vs msvc

Difference between the gnu and msvc toolchains?

The GNU toolchain uses the MinGW build tools (mostly the linker) and produces binaries that use the GNU ABI. The MSVC toolchain uses the Visual Studio build tools and produces binaries that use the Microsoft ABI, making them more compatible with most other Windows binaries/libraries.

参考文档

https://www.reddit.com/r/rust/comments/a63dlt/difference_between_the_gnu_and_msvc_toolchains/

https://rust-lang.github.io/rustup/installation/windows.html

Rust Cross Compile OSX target under Linux

ttyS3 — Sun, 24 Jan 2021 16:53:36 GMT

this article first post on 2021-01-25 updated on 2023-08-28

起因主要是想给我fork自convco的git-cz 项目 release 那里增加一个Mac二进制文件方便使用Mac的人下载。

这是一个方便使用约定式提交记录的git工具.

Environment

OS: Fedora 38 (Workstation Edition) x86_64
CPU: Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz x86_64
rustc 1.72.0 (5680fa18f 2023-08-23)
cargo 1.72.0 (103a7ff2e 2023-08-15)

Requirements

# Install build dependencies

# CentOS Stream / Fedora 38
dnf group install "Development Tools"

dnf install -y \
        clang-devel clang \
        gcc \
        gcc-c++ \
        zlib-devel \
        libmpc-devel \
        mpfr-devel \
        gmp-devel

# Ubuntu 23.04
apt install \
    clang \
    gcc \
    g++ \
    zlib1g-dev \
    libmpc-dev \
    libmpfr-dev \
    libgmp-dev

# Add macOS Rust target
rustup target add x86_64-apple-darwin

Building OSXCross Toolchain

OSXCross 是什么？是一个快速让你在Linux上安装Mac交叉编译toolchain的工具。

很多复杂或麻烦的事情都被它处理好了。

它甚至还带了一个包管理器：

OSXCross comes with a minimalistic MacPorts Packet Manager. See README.MACPORTS for more.

安装步骤：

1. 准备 SDK

这步骤主要参考： https://github.com/tpoechtrager/osxcross#packaging-the-sdk

-- Xcode up to 15 Beta 6 is known to work. -- Use Firefox if you have problems signing in.

osxcross now support the latest Xcode 15 Beta 6, that's good.

构建这个toolchain需要苹果的SDK，这个需要从Xcode提取。去 https://developer.apple.com/download/all/ 下载最新版的Xcode (需要Apple ID登录), beta版的不需要从app store下载，下载回来是一个xip后缀的文件.

我这里下载当前最新的最低可以支持到较旧版本的 macOS 12 的 Xcode 版本 Xcode_14.2.xip

according to https://xcodereleases.com/?scope=release

the latest Xcode we can use to support macOS 12 is: Xcode 14.2

Version	Released	Requires	SDKs
Xcode 15.0 Beta 7	22 Aug 2023	macOS 13.4+	macOS 14.0 (23A5326c)
Xcode 14.3	30 Mar 2023	macOS 13.0+	macOS 13.3 (22E245)
Xcode 14.2	13 Dec 2022	macOS 12.5+	macOS 13.1 (22C55)
Xcode 13.2.1	17 Dec 2021	macOS 11.3+	macOS 12.1 (21C46)

https://download.developer.apple.com/Developer_Tools/Xcode_14.2/Xcode_14.2.xip

ps: 老灯还发现了一个下载 xcode 的好地方： https://xcodereleases.com/

Packing the SDK on Linux - Method 1 (Xcode > 8.0):

确保已经安装了打包SDK过程中需要的clang, make, libssl-devel, lzma-devel and libxml2-devel


# 如果之前有下载过, 记得删除 rm -rf osxcross , 不然连接的旧的库可能会导致 pbzx 等无法执行
git clone https://github.com/tpoechtrager/osxcross
cd osxcross

# ubuntu lzma.h: sudo apt install -y liblzma-dev

# /home/ttys3/Downloads/Compressed/Xcode_14.2.xip 是下载好的 `Xcode_14.2.xip` 路径
# size almost 7.1 GB
./tools/gen_sdk_package_pbzx.sh /home/ttys3/Downloads/Compressed/Xcode_14.2.xip

这里需要解包 xip 文档，再用xz 打包, 要一小会。

took 9m25s max disk usage: 29 GB

打包成功会在 OSXCross 根目录下生成 MacOSX13.1.sdk.tar.xz and MacOSX13.sdk.tar.xz

将 MacOSX13.1.sdk.tar.xz 移动到tarballs 目录下：

mv MacOSX13.1.sdk.tar.xz ./tarballs

#  we do not need MacOSX13.sdk.tar.xz
rm MacOSX13.sdk.tar.xz

2. 构建toolchain

确保你的系统已经安装了必要的组件，如 Clang 3.9+, cmake, git, patch, Python, libssl-devel (openssl) lzma-devel, libxml2-devel and the bash shell

可选： Optional:

llvm-devel: For Link Time Optimization support llvm-devel: For ld64 -bitcode_bundle support uuid-devel: For ld64 -random_uuid support

In clang there is no difference between cross-compilation and native compilation, so OSXCross can use a normal clang install for both. You can use either a clang installation you already have, or build your own from source.

由于我们已经安装了系统clang了，因此不用手动再编译.

我们接下来直接使用clang 编译 cross toolchain, 执行 ./build.sh ：

  ~/repo/toolchain/osxcross on  master 
❯ ./build.sh
found SDK version 13.1 at tarballs/MacOSX13.1.sdk.tar.xz
verified at /home/ttys3/repo/rust/macos/osxcross/tarballs/MacOSX13.1.sdk.tar.xz

Building OSXCross toolchain, Version: 1.4

macOS SDK Version: 13.1, Target: darwin22.2
Minimum targeted macOS Version: 10.9
Tarball Directory: /home/ttys3/repo/rust/macos/osxcross/tarballs
Build Directory: /home/ttys3/repo/rust/macos/osxcross/build
Install Directory: /home/ttys3/repo/rust/macos/osxcross/target
SDK Install Directory: /home/ttys3/repo/rust/macos/osxcross/target/SDK

Press enter to start building

# 或使用UNATTENDED=1跳过问题直接构建
UNATTENDED=1 ./build.sh

构建成功后会有类似如下提示：

Do not forget to add

/home/ttys3/repo/rust/macos/osxcross/target/bin

to your PATH variable.

All done! Now you can use o32-clang(++) and o64-clang(++) like a normal compiler.

Example usage:

Example 1: CC=o32-clang ./configure --host=i386-apple-darwin22.2
Example 2: CC=i386-apple-darwin22.2-clang ./configure --host=i386-apple-darwin22.2
Example 3: o64-clang -Wall test.c -o test
Example 4: x86_64-apple-darwin22.2-strip -x test

!!! Use aarch64-apple-darwin22.2-* instead of arm64-* when dealing with Automake !!!
!!! CC=aarch64-apple-darwin22.2-clang ./configure --host=aarch64-apple-darwin22.2 !!!
!!! CC="aarch64-apple-darwin22.2-clang -arch arm64e" ./configure --host=aarch64-apple-darwin22.2 !!!

Your SDK does not support i386 anymore.
Use <= 10.13 SDK if you rely on i386 support.

Your SDK does not support libstdc++ anymore.
Use <= 10.13 SDK if you rely on libstdc++ support.

这里有关于32位支持和 libstdc++ 依赖的提示, 如果需要依赖这两个之一，就需要使用小于等于 10.13 的SDK

构建好的文件都在 target 目录下，直接放在这里显然不合适，我们把它移动到一个合适一点的地方, 比如 /usr/local/darwin-ndk-x86_64：

sudo mkdir /usr/local/darwin-ndk-x86_64

sudo mv target/* /usr/local/darwin-ndk-x86_64/

如果还需要使用gcc作为交叉编译器的话，还需要行 ./build_gcc.sh，不过这里我们是使用clang, 因此略过。

tips

链接错误问题:

x86_64-apple-darwin22.2-ld: error while loading shared libraries: libxar.so.1: cannot open shared object file: No such file or directory

❯ ls -l /usr/local/darwin-ndk-x86_64/lib
lrwxrwxrwx ttys3 ttys3  15 B  Wed Jan 27 10:46:58 2021  libtapi.so ⇒ libtapi.so.8svn
.rw-r--r-- ttys3 ttys3 3.2 MB Wed Jan 27 10:46:58 2021  libtapi.so.8svn
.rw-r--r-- ttys3 ttys3 205 KB Wed Jan 27 10:43:54 2021  libxar.a
.rw-r--r-- ttys3 ttys3 800 B  Wed Jan 27 10:43:54 2021  libxar.la
lrwxrwxrwx ttys3 ttys3  11 B  Wed Jan 27 10:43:54 2021  libxar.so ⇒ libxar.so.1
.rwxr-xr-x ttys3 ttys3 142 KB Wed Jan 27 10:43:54 2021  libxar.so.1

解决：

echo /usr/local/darwin-ndk-x86_64/lib | sudo tee /etc/ld.so.conf.d/darwin.conf
sudo ldconfig

ATTENTION:

OSXCross links libgcc and libstdc++ statically by default (this affects -foc-use-gcc-libstdc++ too). You can turn this behavior off with OSXCROSS_GCC_NO_STATIC_RUNTIME=1 (env).

The build also creates aliases *-g++-libc++ which link with the clang implementation of the C++ standard library instead of the GCC version. Don't use these variants unless you know what you're doing.

Configuring Cargo

编辑 .cargo/config, 增加

[target.x86_64-apple-darwin]
linker = "/usr/local/darwin-ndk-x86_64/bin/x86_64-apple-darwin22.2-clang"
ar = "/usr/local/darwin-ndk-x86_64/bin/x86_64-apple-darwin22.2-ar"

这里很重要，尤其是 linker, 如果没有配置， cargo 默认只会使用 cc, 而不会使用 clang, 即使你 export 了 CC=xxxxx, 在最后link的时候会报错( 报错类似于 https://gist.github.com/Edu4rdSHL/49b8b52bac916d88e32861a817d5f9a5 )

Building the project

PATH="/usr/local/darwin-ndk-x86_64/bin/:$PATH" \
CC=o64-clang \
CXX=o64-clang++ \
cargo build --target x86_64-apple-darwin

❯ file ./target/x86_64-apple-darwin/release/git-cz.darwin
./target/x86_64-apple-darwin/release/git-cz.darwin: Mach-O 64-bit x86_64 executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE|HAS_TLV_DESCRIPTORS>

OK, the binary: https://github.com/ttys3/git-cz/releases/download/v0.6.0/git-cz.darwin

Misc

o64-clang and x86_64-apple-darwin*-clang

link to the same wrapper: x86_64-apple-darwin22.2-wrapper

❯ ls -lh /usr/local/darwin-ndk-x86_64/bin/o64-clang
lrwxrwxrwx ttys3 ttys3 31 B Sun Jan 24 23:43:35 2021  /usr/local/darwin-ndk-x86_64/bin/o64-clang ⇒ x86_64-apple-darwin22.2-wrapper

❯ ls -lh /usr/local/darwin-ndk-x86_64/bin/x86_64-apple-darwin22.2-clang
lrwxrwxrwx ttys3 ttys3 31 B Sun Jan 24 23:43:35 2021  /usr/local/darwin-ndk-x86_64/bin/x86_64-apple-darwin22.2-clang ⇒ x86_64-apple-darwin22.2-wrapper

check all wrapper been linked to:

ls -l /usr/local/darwin-ndk-x86_64/bin/* | rg wrapper

Building *-sys crates

带C绑定的一些lib(一般命名为*-sys, 如 libz-sys )如果要交叉编译，你还得设置CC和CXX环境变量。这样能编译成功了，但是最后链接阶段可能失败，原因是链接了错误的库.

有些库提供了环境变量可以方便使用交叉编译工具重新编译，比如 https://github.com/rust-lang/libz-sys/blob/master/build.rs#L25

如果设定了LIBZ_SYS_STATIC=1, 则会编译一个静态版本的, 由于我们指定了 CC 和 CXX 都是Mac的，因此可以成功链接。

PATH="/usr/local/darwin-ndk-x86_64/bin/:$PATH" \
CC=o64-clang \
CXX=o64-clang++ \
LIBZ_SYS_STATIC=1 \
cargo build --target x86_64-apple-darwin

About xip files

Unpacking XIP files on Linux

Install xar from https://mackyle.github.io/xar/ (or my fork https://github.com/ttys3/xar )
Install pbzx from https://github.com/NiklasRosenstein/pbzx (or my fork https://github.com/ttys3/pbzx/ ) (use gcc -llzma -lxar -I /usr/local/include pbzx.c -o pbzx and copy the binary into your PATH)
use xar -xf XIP_FILE -C /path/to/extract/to
Change to the directory where you extracted the file.
Use pbzx -n Content | cpio -i to extract the contents.

ref: https://gist.github.com/phracker/1944ce190e01963c550566b749bd2b54

不过在这里，我们并不需要按上面的步骤手动提取，OSXCross 都已经有自动解包和打包脚本，很全.

xar 这个库, 原版已经很多年没人维护了, 所以,这里其实作者用了它自己的 fork 版: https://github.com/tpoechtrager/xar

老灯也 fork 了一个, 增加了 ArchLinux PKGBUILD https://github.com/ttys3/xar

参考文档

https://www.reddit.com/r/rust/comments/6rxoty/tutorial_cross_compiling_from_linux_for_osx/

https://wapl.es/rust/2019/02/17/rust-cross-compile-linux-to-macos.html

https://github.com/tpoechtrager/osxcross

https://github.com/rust-lang/backtrace-rs/issues/240

https://gist.github.com/Edu4rdSHL/49b8b52bac916d88e32861a817d5f9a5

https://john-millikin.com/notes-on-cross-compiling-rust

https://github.com/ttys3/xar/blob/master/xar.md

https://github.com/rust-embedded/cross

https://github.com/etrombly/gtk_osx_cross/blob/master/README.md

https://rust-lang.github.io/rustup-components-history/x86_64-apple-darwin.html

Tmux 24bit True Color Support

ttyS3 — Sun, 10 Jan 2021 10:43:52 GMT

如何检测24bit颜色支持

以前一直没怎么注意这个问题，直到这次我自己基于base16框架做了一个Jetbrains Gruvbox soft black 配色的 port ，发现同一个代码，在Gnome Terminal 和 tmux 下显示效果差异很大。

GNOME Terminal下显示正常:

tmux 下显示的颜色不对：

于是我突然想起来，256 color 的支持问题.

事实上tmux官方仓库里有两个很好的工具，用于检测256 color 是否被支持：

curl -sSfL https://github.com/tmux/tmux/raw/master/tools/24-bit-color.sh | sh

perl 脚本那个不太容易看看出来：

curl -sSfL https://github.com/tmux/tmux/raw/master/tools/256colors.pl | perl

这两个脚本我这里也存了一份:

24-bit-color.sh

256colors.pl

24bit color:

24-bit-color.sh 的识别度非常好，可以下载回来作为常规检测工具使用。

另外还有一段awk代码也不错：

awk 'BEGIN{
    s="/\\/\\/\\/\\/\\"; s=s s s s s s s s;
    for (colnum = 0; colnum<77; colnum++) {
        r = 255-(colnum*255/76);
        g = (colnum*510/76);
        b = (colnum*255/76);
        if (g>255) g = 510-g;
        printf "\033[48;2;%d;%d;%dm", r,g,b;
        printf "\033[38;2;%d;%d;%dm", 255-r,255-g,255-b;
        printf "%s\033[0m", substr(s,colnum+1,1);
    }
    printf "\n";
}'

tmux 配置

tmux must be told that the terminal outside supports RGB colour. This is done by specifying the RGB or Tc terminfo(5) flags. RGB is the official flag, Tc is a tmux extension. With tmux 3.2 and later this can be added with the terminal-features option: set -as terminal-features ",gnome*:RGB" Or for any tmux version the terminal-overrides option: set -as terminal-overrides ",gnome*:Tc"

编辑 .tmux.conf, 增加两行(注意下面，一个是适用于3.2的，一个是适用于3.1的):

set -g default-terminal "tmux-256color"

# tmux 3.2之后
set -as terminal-features ",xterm-256color:RGB"

# tmux 3.1
set -as terminal-overrides ",xterm-256color:RGB"

# 如果tmux只在gnome terminal里打开
# set -as terminal-features ",gnome*:RGB"

# 如果tmux只在alacritty里打开
# set -ag terminal-features ",alacritty:RGB"

# 兼容方案
# set -as terminal-overrides ",xterm-256color:RGB"

terminal-overrides applies to the outside $TERM. It basically says: When starting tmux in a shell that has$ TERM set to xterm-256color, add the Tc capability to tmux's internal image of tmux-256color to signalize it to use true colors.

oh my tmux 配置

oh my tmux 默认已经内置支持了，但是默认是关闭的。

只需要编辑 .tmux.conf.local, 将tmux_conf_theme_24b_colour=true修改为true

tmux_conf_theme_24b_colour=true

它最终会执行:


run 'cut -c3- ~/.tmux.conf | sh -s _apply_configuration'

# _apply_configuration -> _apply_overrides

_apply_overrides() {
  tmux_conf_theme_24b_colour=${tmux_conf_theme_24b_colour:-false}
  if _is_enabled "$tmux_conf_theme_24b_colour"; then
  case "$TERM" in
    screen-*|tmux-*)
      ;;
    *)
      tmux set-option -ga terminal-overrides ",*256col*:Tc"
      ;;
  esac
  fi
}

# 因此实际上它是执行的
# tmux set-option -ga terminal-overrides ",*256col*:Tc"

Alacritty 支持

除非我们在tmux配置了set -ag terminal-overrides ",alacritty:RGB" (tmux 3.1) 或set -ag terminal-features ",alacritty:RGB" (tmux 3.2), 否则，默认情况下，我们在Alacritty里运行tmux, tmux还是不能支持24bit color.

但是，如果设置set -ag terminal-overrides ",alacritty:RGB"，当tmux跑在 Gnome Terminal 下时，又失去24bit color了。

因此，为了兼容，我们需要修改Alacrity 的配置:

# Any items in the `env` entry below will be added as
# environment variables. Some entries may override variables
# set by alacritty itself.
env:
  # TERM variable
  #
  # This value is used to set the `$TERM` environment variable for
  # each instance of Alacritty. If it is not present, alacritty will
  # check the local terminfo database and use `alacritty` if it is
  # available, otherwise `xterm-256color` is used.
  # TERM: alacritty
  TERM: xterm-256color

它的TERM 默认值是 alacritty, 而当前tmux并不能识别它是不是支持256color, 因此，我们需要把它设置成兼容 xterm-256color

参考文档

https://github.com/tmux/tmux/issues/1246#issuecomment-493454336

https://jdhao.github.io/2018/10/19/tmux_nvim_true_color/

https://github.com/tmux/tmux/wiki/FAQ#how-do-i-use-rgb-colour

https://stackoverflow.com/q/15375992/6064933

Good explanation about what terminal-overrides does.

https://stackoverflow.com/q/41783367/6064933

https://www.reddit.com/r/neovim/comments/825dj7/the_endless_litany_of_tmux_and_nvim_color_problems/

Why you should not set TERM inside shell config file

You should not set TERM inside shell config file.

Nvim and Rime Esc Auto Switch

ttyS3 — Sun, 10 Jan 2021 07:58:02 GMT

前提

简单描述下自动切换的行为：

nvim记住最近一次插入模式时的输入法（可能是英文，也可能是中文) esc回到正常模式时，插件自动将系统输入法切换到英文状态重新回到插入模式时, nvim自动切回上次插入模式时的输入法.

环境： ibus + ibus-rime + neovim

当前我的rime配置是有自带ascii mode的，也就是配置了输入中文时简单地按下shift就会切换到英文输入模式。

然而这个ascii mode 外部是无法感知的，也就是只有rime 自己知道，ibus是不知道的。

之前用fcitx 是没有这个问题的，fcitx-remote 配合vim插件fcitx.vim可以非常方便地进行切换。

当前大部分对于ibus控制的插件实现都是无法直接控制到rime的。

因此，我当前的rime配置需要做一些调整。

如果使用的是mac或windows版的rime, 那么，其实前端这边是有支持vim_mode的，见 https://github.com/rime/squirrel/issues/124 和 https://github.com/rime/weasel/issues/12 但是这个只是在前端， librime是没有这个选项的。见 https://github.com/rime/librime/issues/295

由于我的主要使用场景是Linux, 因此rime自带的vim_mode方案不可用。

另外，通过配置rime使用esc来toggle ascii_mode的方案也不太好：

key_binder/bindings:
  - { when: always, accept: Escape, toggle: ascii_mode}

这样就可以使用 Esc 键切换为英文模式，但是这样有一个弊端，必须得先按一次 Esc 切换为英文后，再按一次 Esc 切换为普通模式

我当前的rime配置是：

# @see https://github.com/rime/home/wiki/CustomizationGuide
customization:
  generator: "Rime::SwitcherSettings"
  modified_time: "Sat Dec 31 12:11:20 2016"
patch:
  schema_list:
    - {schema: wubi86}
    - {schema: wubi_pinyin}
  "key_binder/bindings":
    - { when: composing, accept: Return, send: Escape }
    - { when: has_menu, accept: semicolon, send: 2 }
    - { when: has_menu, accept: apostrophe, send: 3 }
  "ascii_composer: good_old_caps_lock": true
  "ascii_composer/switch_key":
    Caps_Lock: commit_code
    Control_L: noop
    Control_R: noop
    Shift_L: commit_code
    Shift_R: commit_code
  "switcher/hotkeys":  # 這個列表裏每項定義一個快捷鍵，使哪個都中
    - "Control+grave"  # 你看寫法並不是 Ctrl+` 而是與 IBus 一致的表示法
    #- F4 # disable default F4 map, leave it for Neovim
  switches:
    - name: ascii_mode
      reset: 1
      states: [ 中文, 西文 ]

也就是，在输入时，随便输入左/右shift 或 caps lock键，都可以在中文输入模式和ascii 输入模式之间快速切换。这期间对于系统或ibus来说，是没有切换输入法的。

如果要在Vim里面控制这种切换，那么，只能控制到ibus层面，要做哪些改变呢？

切换rime的ascii switch 默认状态

reset 为1时的问题: 比如：vim插入模式：rime中文输入 -> vim普通模式（输入法从rime切成了en)-> 再切回插入模式，此时输入法还是英文，我们得再按一次shift切换成中文。

因此， ascii_mode reset 为1 时适合将rime作为默认输入法使用。

将reset从1 修改成0，即可让rime从别的输入法切回时，总是中文输入状态，而不是总是英文（ascii_mode)

同时，要从rime切换到英文输入法，我们要确保有一个英文输入法添加到ibus.

可以通过ibus-setup检查你的配置.

因此， ascii_mode reset 为0 时适合将rime作为第二输入法使用，首选输入法应该是英文。要记得在GNOME3系统配置里的Input Source 那里，将English(US)排到rime前面来。毕竟，我们敲代码比较多，英文在任何时候应该是首选的。

customization:
  generator: "Rime::SwitcherSettings"
  modified_time: "Sat Dec 31 12:11:20 2016"
patch:
  schema_list:
    - {schema: wubi86}
    - {schema: wubi_pinyin}
  "key_binder/bindings":
    - { when: composing, accept: Return, send: Escape }
    - { when: has_menu, accept: semicolon, send: 2 }
    - { when: has_menu, accept: apostrophe, send: 3 }
  "ascii_composer: good_old_caps_lock": true
  "ascii_composer/switch_key":
    Caps_Lock: commit_code
    Control_L: noop
    Control_R: noop
    Shift_L: commit_code
    Shift_R: commit_code
  "switcher/hotkeys":  # 這個列表裏每項定義一個快捷鍵，使哪個都中
    - "Control+grave"  # 你看寫法並不是 Ctrl+` 而是與 IBus 一致的表示法
    #- F4 # disable default F4 map, leave it for Neovim
  switches:
    - name: ascii_mode
      reset: 0
      states: [ 中文, 西文 ]

gnome3 默认的输入法切换快捷键是： super + space, 短按可快捷切换，长按还能在屏正中overlay显示切换的输入法。

安装配置合适的nvim支持插件

vim-xkbswitch

https://github.com/lyokha/vim-xkbswitch

好处：跨平台支持 Unix: http://github.com/ierton/xkb-switch https://github.com/lyokha/g3kb-switch) 原作者新项目 lyokha/g3kb-switch 解决了 Linux(GNOME) 下的切换

Win: http://github.com/DeXP/xkb-switch-win

OSX: http://github.com/myshov/xkbswitch-macosx ， http://github.com/vovkasm/input-source-switcher

vim-ibus

https://github.com/h-youhei/vim-ibus:

实际上它是直接使用的ibus engine来切换输入法，在 GNOME 3 上切换输入法后，右上角状态栏图标并不会自动更新， fork 版本 zhmars/vim-ibus简单修复了这个问题

使用ibus list-engine可以列出当前可用的engine, 但是实际上我们只会切到一个，那就是xkb:us::eng

vim-ibus-sw

https://github.com/kevinhwang91/vim-ibus-sw

这个其实和h-youhei/vim-ibus 类似，只是更加智能，在GNOME3环境下，它会自动使用dbus通知的方式，这样可以解决图片没有变的问题，在非GNOME3环境下，它同样会回退到 ibus engine 命令的方式。

由于老灯主要使用场景为Linux, 因此最终选择了 kevinhwang91/vim-ibus-sw

参考文档

vim可不可以实现在在normal模式或者visual模式下自动改输入法为英文呢 https://www.zhihu.com/question/25744174

vim 中使用 esc 切换英文输入

LuaRocks安装配置

ttyS3 — Tue, 05 Jan 2021 18:15:44 GMT

其实我安装 lua5.1 只是为了方便兼容 neovim 和 luajit, 这两货目前都只支持lua 5.1

其实根本原因还是在于 luajit 多年没更新(如果我没记错，现在已经2021年了，luajit最后一次发版还是2017年？)，没有兼容最新版本的lua 5.4 。

而 neovim 实际是因为依赖luajit 才导致依赖 lua 5.1的，也是没办法了.

初战翻车

环境说明：操作系统是 Fedora 33, 默认的 lua包是 lua 5.4版本的, luarocks 也是从包管理器dnf直接安装的.

luarocks install --local fzy 失败：

Error: Failed finding Lua header files. You may need to install them or configure LUA_INCDIR.

为了方式与luajit lua5.1 配合工作，同时避免包管理问题, 还是卸载系统的 luarocks, 自己编译安装吧.

sudo rpm -evh luarocks

然后，我们不要用Fedora 33系统自带的luarocks，它的默认luarocks system配置是 lua 5.4的.

Fedora安装lua5.1和luajit

# compat-lua is lua5.1
sudo dnf install compat-lua compat-lua-libs compat-lua-devel lua-filesystem-compat lua-socket-compat lua5.1-compat53 \
lua5.1-luv-devel lua5.1-http lua5.1-lpeg lua5.1-luaossl \
lua5.1-mmdb lua5.1-mpack lua5.1-psl lua5.1-sec lua5.1-basexx lua5.1-binaryheap lua5.1-bitop \
luajit

Ubuntu20.10安装lua5.1和luajit

sudo apt-get install -y libluajit-5.1-dev liblua5.1-0-dev

编译安装

当前最新版本的LuaRocks 版本为 3.5.0, 可以去 https://luarocks.github.io/luarocks/releases/ 查看。

Fedora 33 下可以用 --with-lua-include=/usr/include/lua-5.1/, 而这个路径在 Ubuntu 20.10 下面是 /usr/include/lua5.1, 因此还是不要加--with-lua-include 参数为好，让它自动查找，我们只需要指定 --lua-version=5.1 即可.

curl -LZO https://luarocks.org/releases/luarocks-3.5.0.tar.gz
tar xvzpf luarocks-3.5.0.tar.gz
cd luarocks-3.5.0

❯ ./configure --lua-version=5.1

Configuring LuaRocks version 3.5.0...

Lua version detected: 5.1
Lua interpreter found: /usr/bin/lua-5.1
lua.h found: /usr/include/lua-5.1/lua.h
unzip found in PATH: /usr/bin

Done configuring.

LuaRocks will be installed at......: /usr/local
LuaRocks will install rocks at.....: /usr/local
LuaRocks configuration directory...: /usr/local/etc/luarocks
Using Lua from.....................: /usr

* Type make and make install:
  to install to /usr/local as usual.
* Type make bootstrap:
  to install LuaRocks into /usr/local as a rock.

可以看到，配置完后luarocks提示我们，有两种安装方式. 到底用哪一种呢？

万能的stackoverflow 很快给了我们答案:

Should Icompile luarocks 'as usual' or as a 'rock'?

As you can see from the ChangeLog: make bootstrap is now an advertised option for installing LuaRocks itself as a rock on Unix systems That means that if you go this way you can upgrade luarocks via luarocks install:

Those of you who installed LuaRocks 2.1.0 or later by using make bootstrap on Unix may upgrade by simply running: luarocks install luarocks

from [ANN] LuaRocks 2.2.1.

因此， make bootstrap 是推荐方式, 这种方式安装后你甚至可以用luarocks install luarocks 来更新 luarocks自己。

❯ sudo make bootstrap
mkdir -p "build"
mkdir -p .luarocks
cp ./build/config-5.1.lua .luarocks/config-5.1.lua
rm -f src/luarocks/core/hardcoded.lua
echo "#!/bin/sh" > luarocks
echo "unset LUA_PATH LUA_PATH_5_2 LUA_PATH_5_3 LUA_PATH_5_4 LUA_CPATH LUA_CPATH_5_2 LUA_CPATH_5_3 LUA_CPATH_5_4" >> luarocks
echo 'LUAROCKS_SYSCONFDIR="/usr/local/etc/luarocks" LUA_PATH="/home/ttys3/build/luarocks-3.5.0/src/?.lua;;" exec "/usr/bin/lua-5.1" "/home/ttys3/build/luarocks-3.5.0/src/bin/luarocks" --project-tree="/home/ttys3/build/luarocks-3.5.0/lua_modules" "$@"' >> luarocks
chmod +rx ./luarocks
./luarocks init

Initializing project 'luarocks-3.5.0' for Lua 5.1 ...
-----------------------------------------------------

Checking your Lua installation ...
Adding entries to .gitignore ...
Preparing ./.luarocks/ ...
Wrote .luarocks/config-5.1.lua
Preparing ./lua_modules/ ...
./luarocks already exists. Not overwriting it!
Preparing ./lua for version 5.1...
mkdir -p "/usr/local/etc/luarocks"
install -m 644 "build/config-5.1.lua" "/usr/local/etc/luarocks/config-5.1.lua"
./luarocks make --tree="/usr/local"

No existing manifest. Attempting to rebuild...
luarocks 3.5.0-1 is now installed in /usr/local (license: MIT)

可以看到， luarocks 被安装在 /usr/local/share/lua/5.1/luarocks

用户级目录在：~/.luarocks

系统配置在 /usr/local/etc/luarocks 头文件在 /usr/include/lua-5.1

lua5.1 (dnf 安装的) 本身的lib在： /lib64/lua/5.1

❯ luarocks --version
/usr/local/bin/luarocks 3.5.0
LuaRocks main command-line interface

注：其实像 ArchLinux 和 Fedora 本身带的 luarocks 包是比较新的，是可以不用自己编译的。

小试牛刀

luarocks install --local fzy
Installing https://luarocks.org/fzy-0.4-1.rockspec
Cloning into 'fzy-lua'...
remote: Enumerating objects: 24, done.
remote: Counting objects: 100% (24/24), done.
remote: Compressing objects: 100% (20/20), done.
remote: Total 24 (delta 0), reused 12 (delta 0), pack-reused 0
Receiving objects: 100% (24/24), 22.69 KiB | 505.00 KiB/s, done.
Note: switching to 'a3f1dd75725b535e6b00af84048c7e066432f530'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false


fzy 0.4-1 depends on lua >= 5.1 (5.1-1 provided by VM)
gcc -O2 -fPIC -I/usr/include/lua-5.1 -c src/fzy_native.c -o src/fzy_native.o -DLUA_COMPAT_5_1
gcc -O2 -fPIC -I/usr/include/lua-5.1 -c src/match.c -o src/match.o -DLUA_COMPAT_5_1
gcc -shared -o fzy_native.so src/fzy_native.o src/match.o
No existing manifest. Attempting to rebuild...
fzy 0.4-1 is now installed in /home/ttys3/.luarocks (license: MIT)

OK, 安装成功，我们看下都写入了啥文件:

❯ tree ~/.luarocks
/home/ttys3/.luarocks
├── config-5.1.lua
├── lib
│   └── luarocks
│       └── rocks-5.1
│           ├── fzy
│           │   └── 0.4-1
│           │       ├── fzy-0.4-1.rockspec
│           │       ├── rock_manifest
│           │       └── test
│           │           ├── benchmark.lua
│           │           ├── files.txt
│           │           └── test.lua
│           └── manifest
├── lib64
│   └── lua
│       └── 5.1
│           └── fzy_native.so
└── share
    └── lua
        └── 5.1
            ├── fzy.lua
            └── fzy_lua.lua

12 directories, 10 files

~/.luarocks/lib/luarocks/rocks-5.1 相当于一个包管理数据库，里面记录了安装的rocks的元数据。

~/.luarocks/lib64/lua/5.1/ 下面是 so 文件

~/.luarocks/share/lua/5.1/ 下面是 *.lua文件

❯ luarocks config --scope user config_files
{
   nearest = "/home/ttys3/.luarocks/config-5.1.lua",
   system = {
      file = "/etc/luarocks/config-5.4.lua",
      found = true
   },
   user = {
      file = "/home/ttys3/.luarocks/config-5.1.lua",
      found = true
   }
}

配置文件可以用 LUAROCKS_CONFIG 指定

用户配置一般是 /home/ttys3/.luarocks/config-5.1.lua

❯ bat /usr/local/etc/luarocks/config-5.1.lua
-- LuaRocks configuration

rocks_trees = {
   { name = "user", root = home .. "/.luarocks" };
   { name = "system", root = "/usr/local" };
}
lua_interpreter = "lua-5.1";
variables = {
   LUA_DIR = "/usr";
   LUA_INCDIR = "/usr/include/lua-5.1";
   LUA_BINDIR = "/usr/bin";
}

注意这里的rocks_trees，分为user和system级别的，并不是一个直接的路径，实际上通过默认安装生成的文件可以发现，它是 rocks_trees.root .. "/share/lua/5.1/" .. "*.lua文件或目录" 如：

❯ tree -L 1 /usr/local/share/lua/5.1/
/usr/local/share/lua/5.1/
└── luarocks

1 directory, 0 files


❯ tree /home/ttys3/.luarocks/share/lua/5.1/
/home/ttys3/.luarocks/share/lua/5.1/
├── fzy.lua
└── fzy_lua.lua

0 directories, 2 files

默认配置lib_modules_path是错的, 这个值默认在Fedora和Ubuntu下面都是/lib/lua/5.1，然而这个路径在这两个系统上都是不存在的。 Fedora下通过dnf安装的lua 5.1 是/lib64/lua/5.1, 而Ubuntu 20.10 通过apt 安装的，则是在 /usr/share/lua/5.1

❯ luarocks config --scope user lib_modules_path
/lib/lua/5.1
❯ ls /lib/lua/5.1
ls: cannot access '/lib/lua/5.1': No such file or directory
# Fedora
❯ ls /lib64/lua/5.1
bit.so  compat53/  _cqueues.so  lfs.so  lpeg.so  lpeg.so.1.0.2  luv.so  mime/  mpack.so  _openssl.so  psl.so  socket/  ssl.so

# Ubuntu
❯ ls /usr/share/lua/5.1
basexx.lua  compat53/  cqueues.lua  http/  json.lua        ltn12.lua  mime.lua  openssl.lua  socket/     ssl/
cjson/      cqueues/   fifo.lua     json/  lpeg_patterns/  lxp/       openssl/  re.lua       socket.lua  ssl.lua

Fedora 33 下修正：

❯ luarocks config --scope user lib_modules_path /lib64/lua/5.1
Wrote
	lib_modules_path = "/lib64/lua/5.1"
to
	/home/ttys3/.luarocks/config-5.1.lua

Ubuntu 20.10 下修正：

❯ luarocks config --scope user lib_modules_path /usr/share/lua/5.1
Wrote
	lib_modules_path = "/usr/share/lua/5.1"
to
	/home/ttys3/.luarocks/config-5.1.lua

如果没有,这里luarocks会自动生成配置文件.

rocks 默认安装到用户目录下

https://github.com/luarocks/luarocks/issues/356

You mean --local?

You can also put local_by_default=true in the ~/.luarocks/config.lua file and this flag will be assumed by default. It's great for running LuaRocks as non-root.

最终的文件：

❯ bat /home/ttys3/.luarocks/config-5.1.lua
lib_modules_path = "/lib64/lua/5.1"
local_by_default = true

Troubleshoot

❯ luarocks config
/usr/bin/lua5.4: /usr/share/lua/5.4/luarocks/fs.lua:95: local 'each_platform' is not callable (a nil value)
stack traceback:
	/usr/share/lua/5.4/luarocks/fs.lua:95: in upvalue 'load_platform_fns'
	/usr/share/lua/5.4/luarocks/fs.lua:122: in function 'luarocks.fs.init'
	/usr/share/lua/5.4/luarocks/cmd.lua:500: in function 'luarocks.cmd.run_command'
	/usr/bin/luarocks:38: in main chunk
	[C]: in ?

错误看着很奇怪，同时安装了lua5.1 和 lua5.4, 但是 lua5.1 应该路径优先在前面的，为什么会报 lua5.4 的错误？后面发现是将配置改错了：

variables = {
    LUA = "/usr/bin/lua5.1";
    LUA_DIR = "/usr";
    LUA_BINDIR = "/usr/bin";
}

里面的 ; 被我删除了，因为写 Golang 的习惯是，末尾的 ; 是编译器自动加的，习惯性地就删除了。但是在这个 table 里，实际上是 lua 里的 ; 相当于 Golang 里面的 ,，修正配置，就 OK 了

My config

config-5.1.lua

-- ~/.luarocks/config-5.1.lua

-- default config see https://github.com/luarocks/luarocks/blob/d4e82aae9f411d5d2cac10f7e043a0c3c6180eb1/src/luarocks/core/cfg.lua#L167

--  http://lua-users.org/wiki/LuaRocksConfig
--  https://github.com/luarocks/luarocks/wiki/Dependencies
--  https://github.com/luarocks/luarocks/wiki/Documentation
 

lua_version = "5.1"

local_by_default = true

lua_interpreter = "lua" .. lua_version

-- do not prepend `/usr` to lua_modules_path or lib_modules_path
-- no need to change the default generally.
-- otherwise both `deploy_lib_dir` and `deploy_lua_dir` value will be wrong
----------------------------------------------------------------
-- remember: 
-- `home_tree = "/home/ttys3/.luarocks"`
-- `deploy_lua_dir = home_tree .. lua_modules_path`
-- `deploy_lib_dir = home_tree .. lib_modules_path`
----------------------------------------------------------------
-- lua_modules_path = "/share/lua/"..lua_version
-- lib_modules_path = "/lib/lua/"..lua_version

-- we need correct `lib_modules_path` here
lib_modules_path = "/lib64/lua/"..lua_version

-- for 5.1 ROCKS_TREE is `/home/ttys3/.luarocks/lib/luarocks/rocks-5.1`
-- so rocks_subdir is `lib/luarocks/rocks-5.1`, no need to change the default
-- set it to full absolute path is incorrect, it does not need the `~/.luarocks` part
-- otherwise both `variables.ROCKS_TREE` and `rocks_dir` value will be wrong
-- remember:  `rocks_dir = home_tree .. rocks_subdir`
-- system: /usr/lib/luarocks/rocks-5.1
-- user: /home/ttys3/.luarocks/lib/luarocks/rocks-5.1
-- rocks_subdir = "/lib/luarocks/rocks-"..lua_version

connection_timeout = 30  -- 0 = no timeout

variables = {
    LUA = "/usr/bin/lua" .. lua_version,
    LUA_DIR = "/usr",
    LUA_BINDIR = "/usr/bin",
}

参考文档

https://github.com/luarocks/luarocks/wiki/Installation-instructions-for-Unix

http://lua-users.org/wiki/LuaRocksConfig

https://github.com/luarocks/luarocks/wiki/config-file-format

https://stackoverflow.com/a/29340739/13267147

如何从 grub2 启动 Ubuntu Live CD iso

ttyS3 — Sat, 26 Dec 2020 15:07:46 GMT

上次写了《如何从 grub2 启动 Fedora32 Live CD iso》 , 这次顺便把 Ubuntu 的也补一下吧。

公司开发环境为了大家统一，全部采用的 Ubuntu.

这年头也很少随身带U盘了，因此，只靠硬盘，自己能求自己，还是能在关键时候有用的。

下载live cd iso并校验

curl -LZO https://mirrors.tuna.tsinghua.edu.cn/ubuntu-releases/groovy/ubuntu-20.10-desktop-amd64.iso
curl -LO https://mirrors.tuna.tsinghua.edu.cn/ubuntu-releases/groovy/SHA256SUMS
curl -LO https://mirrors.tuna.tsinghua.edu.cn/ubuntu-releases/groovy/SHA256SUMS.gpg

校验可参考官方文档 https://ubuntu.com/tutorials/how-to-verify-ubuntu#4-retrieve-the-correct-signature-key

gpg --keyid-format long --verify SHA256SUMS.gpg SHA256SUMS
sha256sum -c SHA256SUMS

增加grub2启动项

先准备下文件，由于Ubuntu默认划分的 /boot 分区较小，因此不能放下live cd iso.

直接放到 / 吧。准备下目录: sudo mkdir /opt/iso, 然后把 iso 文件 copy 到这个目录。

注意，这里的/ 分区我使用的是LVM, 因此，我们要使用 sudo blkid 找出 / 所在的 LV 的 UUID.

❯ sudo blkid
/dev/mapper/vgubuntu-swap_1: UUID="f63131c3-9d02-4813-9db9-d85571f09084" TYPE="swap"
/dev/mapper/vgubuntu-root: UUID="cb94816d-569d-4658-963c-eb675052fc98" BLOCK_SIZE="4096" TYPE="ext4"
/dev/sda1: UUID="ba87f398-f52b-420f-9d19-af30a320c8f5" BLOCK_SIZE="4096" TYPE="xfs" PARTLABEL="Linux filesystem" PARTUUID="e21fd454-dc9a-41cb-8c72-c9fb05cb5d41"
/dev/nvme0n1p1: UUID="97CB-9857" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="ca61970c-01"
/dev/nvme0n1p5: UUID="C7sb3l-laqt-gLDw-ji2s-yC3r-x5bw-Axa9yu" TYPE="LVM2_member" PARTUUID="ca61970c-05"

注意这里 /dev/mapper/vgubuntu-root: UUID="cb94816d-569d-4658-963c-eb675052fc98" BLOCK_SIZE="4096" TYPE="ext4" 就是 / 所在的LV了。在grub2里，我们只需要取这里的cb94816d-569d-4658-963c-eb675052fc98 即可。

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.

menuentry "Ubuntu 20.10 ISO" {
   set isofile="/opt/iso/ubuntu-20.10-desktop-amd64.iso"
   # or set isofile="/<username>/Downloads/ubuntu-20.04-desktop-amd64.iso"
   # if you use a single partition for your $HOME
   rmmod tpm
   search --no-floppy --fs-uuid --set=root cb94816d-569d-4658-963c-eb675052fc98
   loopback loop ($root)$isofile
   linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile noprompt noeject
   initrd (loop)/casper/initrd
}

grub2 配置调整

Fedora 和 Ubuntu 现在都默认不显示grub menu了 (要开机时按esc才显示），可以通过修改配置调整成总是显示：

修改 /etc/default/grub ：

#GRUB_TIMEOUT_STYLE=hidden
#GRUB_TIMEOUT_STYLE=countdown
GRUB_TIMEOUT_STYLE=menu

文档解释： GRUB_TIMEOUT_STYLE

If this option is unset or set to ‘menu’, then GRUB will display the menu and then wait for the timeout set by ‘GRUB_TIMEOUT’ to expire before booting the default entry. Pressing a key interrupts the timeout.
If this option is set to ‘countdown’ or ‘hidden’, then, before displaying the menu, GRUB will wait for the timeout set by ‘GRUB_TIMEOUT’ to expire. If ESC is pressed during that time, it will display the menu and wait for input. If a hotkey associated with a menu entry is pressed, it will boot the associated menu entry immediately. If the timeout expires before either of these happens, it will boot the default entry. In the ‘countdown’ case, it will show a one-line indication of the remaining time.

更新 grub2 配置文件

Ubuntu 下面有一个比较方便的 update-grub2 用来更新grub2配置, 该命令实际上是对 grub2-mkconfig 的便捷封装，你不用指定配置文件路径，直接跑就行了。

❯ sudo update-grub2
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/init-select.cfg'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.8.0-29-generic
Found initrd image: /boot/initrd.img-5.8.0-29-generic
Found linux image: /boot/vmlinuz-5.8.0-28-generic
Found initrd image: /boot/initrd.img-5.8.0-28-generic
Found linux image: /boot/vmlinuz-5.8.0-26-generic
Found initrd image: /boot/initrd.img-5.8.0-26-generic
Found memtest86+ image: /boot/memtest86+.elf
Found memtest86+ image: /boot/memtest86+.bin
done

参考文档

https://www.gnu.org/software/grub/manual/grub/html_node/Simple-configuration.html

https://unix.stackexchange.com/questions/516429/boot-iso-file-located-on-lvm-from-grub2

https://superuser.com/a/1289853/1162309

https://help.ubuntu.com/community/Grub2/ISOBoot#ISO_File_Location

如何在Fedora33/CentOS8上安装Charles根证书

ttyS3 — Sun, 20 Dec 2020 14:19:56 GMT

开发机上跑着Charles，同时本机又有程序想通过Charles来抓包, 需要tls证书被信任才行（依赖的库强制校验证书). 所以才有这个需求。

此方法通用，适用于安装任何root ca.

root ca installation

较新版本的 Charles 现在默认会同时生成 charles-proxy-ssl-proxying-certificate.cer, charles-proxy-ssl-proxying-certificate.pem 和 keystore 3个文件

cd ~/.charles/ca
sudo trust anchor --store ./charles-proxy-ssl-proxying-certificate.pem
# 证书会写到 /etc/pki/ca-trust/source 这个目录下

manual installation method

If you get "no configured writable location" or a similar error, import the CA manually:

Copy the certificate to the /etc/pki/ca-trust/source/anchors directory. Run update-ca-trust as root.

对于 ArchLinux, 它是安装到 /etc/ca-certificates/trust-source/ 目录。手动安装路径为 /etc/ca-certificates/trust-source/anchors

cd ~/.charles/ca

# 如果没有 pem 文件， 先将der格式的证书转换成pem格式
# openssl x509 -inform DER -in charles-proxy-ssl-proxying-certificate.cer -out charles-proxy-ssl-proxying-certificate.pem

# 复制转换好的ca到/etc/pki/ca-trust/source/anchors/
cp charles-proxy-ssl-proxying-certificate.pem /etc/pki/ca-trust/source/anchors/charles-ca.pem

# 执行
update-ca-trust extract

# verify
❯ openssl verify /etc/pki/ca-trust/source/anchors/charles-ca.pem
/etc/pki/ca-trust/source/anchors/charles-ca.crt: OK

refs

https://access.redhat.com/solutions/1519813

ubuntu: https://askubuntu.com/questions/73287/how-do-i-install-a-root-certificate

Adding a trusted CA certificate https://wiki.archlinux.org/title/User:Grawity/Adding_a_trusted_CA_certificate

Fedora 33 中使用百度网盘Linux版的艰难历程

ttyS3 — Sun, 20 Dec 2020 13:24:50 GMT

问题

百度网盘推出Linux客户端已经有一段时间了。期间，在Fedora32时我就已经给他们提过一个启动即crash的问题，后面一直也没修复.

这都 Fedora 33了，我又提了一次，而且还把gdb的backtrace发给了他们，显示已经处理。实际上几个月过去了都没见动静。只能自己动手，丰衣足食了。

解决

老灯注意到, 百度网盘链接的库都是比较老的，因此那个客户端在Ubuntu 18.04 上面肯定是可以正常运行。

那个 rpm 包压根不是对标最新的Fedora的，而是给那些基于RHEL的同样使用rpm包管理的古董国产操作系统使用的。

因此老灯下载 baidunetdisk_3.5.0_amd64.deb，并解压出实际的程序.

首先我们跑一下，看看bt 吧：

Thread 1 "baidunetdisk" received signal SIGSEGV, Segmentation fault.
0x00007ffff5096179 in EVP_MD_CTX_clear_flags () from /lib64/libcrypto.so.1.1

(gdb) bt
#0  0x00007ffff5096179 in EVP_MD_CTX_clear_flags () at /lib64/libcrypto.so.1.1
#1  0x00007ffff508b261 in EVP_DigestInit_ex () at /lib64/libcrypto.so.1.1
#2  0x00007ffff50ab1e8 in HMAC_Init_ex () at /lib64/libcrypto.so.1.1
#3  0x00007fffd1a92766 in sqlcipher_openssl_hmac
    (ctx=<optimized out>, hmac_key=0x227a99ce02d8 "\f>@)YUj\001\346\063vr\312\062\016\243\232\312\334\324\302\027\201-\330ƨ\213É<)", key_sz=32, in=0x227a9a00b548 "\250\235J_h1E\214\v\033u\266\342P.\240\063\244\337V\313\360T\rqu<c:\303E\234\061-\216\365\255\033ǲ\203\b\001\027\257\215\033\070{i9H\376\346H\223DB\244\001\314d\302\022\310\376\315\b\343\"\362e\227\252T\363\215\351\323\005\271\022ǎ\340 \205\a墭\240ZЯ\266\330 \335\334\314ё\255\262a+N\367\021\214\322\b\021)\356\362=\201\310\354\005\273o\250a)$\254z\226\371\322\003n\241\244Z\032\277\217\060\225\353.\276\001\206;\245Ȩ\245\211㓫\326\313\370V\360\327\t\310RX\362\026P\223\302\032\027\351\067\003|\034\024\r\021R\233\334R=\376&\022\b\235\033\313\315\361mW", <incomplete sequence \310>..., in_sz=976, in2=0x7fffffffa910 "\001", in2_sz=4, out=0x227a99f925e8 "")
    at /home/neokylinv7/桌面/SourceCode/mazu/source/sqlcipher/sqlite3.c:18404
#4  0x00007fffd1ab03aa in sqlcipher_page_hmac
    (out=0x227a99f925e8 "", in_sz=<optimized out>, in=0x227a9a00b548 "\250\235J_h1E\214\v\033u\266\342P.\240\063\244\337V\313\360T\rqu<c:\303E\234\061-\216\365\255\033ǲ\203\b\001\027\257\215\033\070{i9H\376\346H\223DB\244\001\314d\302\022\310\376\315\b\343\"\362e\227\252T\363\215\351\323\005\271\022ǎ\340 \205\a墭\240ZЯ\266\330 \335\334\314ё\255\262a+N\367\021\214\322\b\021)\356\362=\201\310\354\005\273o\250a)$\254z\226\371\322\003n\241\244Z\032\277\217\060\225\353.\276\001\206;\245Ȩ\245\211㓫\326\313\370V\360\327\t\310RX\362\026P\223\302\032\027\351\067\003|\034\024\r\021R\233\334R=\376&\022\b\235\033\313\315\361mW", <incomplete sequence \310>..., pgno=<optimized out>, ctx=0x227a99d3f078) at /home/neokylinv7/桌面/SourceCode/mazu/source/sqlcipher/sqlite3.c:17506
#5  sqlcipher_page_cipher
    (ctx=ctx@entry=0x227a99d095a8, for_ctx=for_ctx@entry=0, pgno=<optimized out>, mode=mode@entry=0, page_sz=1008, in=0x227a9a00b548 "\250\235J_h1E\214\v\033u\266\342P.\240\063\244\337V\313\360T\rqu<c:\303E\234\061-\216\365\255\033ǲ\203\b\001\027\257\215\033\070{i9H\376\346H\223DB\244\001\314d\302\022\310\376\315\b\343\"\362e\227\252T\363\215\351\323\005\271\022ǎ\340 \205\a墭\240ZЯ\266\330 \335\334\314ё\255\262a+N\367\021\214\322\b\021)\356\362=\201\310\354\005\273o\250a)$\254z\226\371\322\003n\241\244Z\032\277\217\060\225\353.\276\001\206;\245Ȩ\245\211㓫\326\313\370V\360\327\t\310RX\362\026P\223\302\032\027\351\067\003|\034\024\r\021R\233\334R=\376&\022\b\235\033\313\315\361mW", <incomplete sequence \310>..., out=0x227a99f92218 "") at /home/neokylinv7/桌面/SourceCode/mazu/source/sqlcipher/sqlite3.c:17556
#6  0x00007fffd1ac1a84 in sqlite3Codec (iCtx=0x227a99d095a8, data=0x227a9a00b538, pgno=1, mode=3) at /home/neokylinv7/桌面/SourceCode/mazu/source/sqlcipher/sqlite3.c:16249
#7  0x00007fffd1a93595 in readDbPage (pPg=pPg@entry=0x227a9a00b970, iFrame=<optimized out>) at /home/neokylinv7/桌面/SourceCode/mazu/source/sqlcipher/sqlite3.c:50416
#8  0x00007fffd1adf61e in sqlite3PagerGet (pPager=0x227a99f44008, pgno=pgno@entry=1, ppPage=ppPage@entry=0x7fffffffaa68, flags=flags@entry=0)
    at /home/neokylinv7/桌面/SourceCode/mazu/source/sqlcipher/sqlite3.c:52923
#9  0x00007fffd1ae1d08 in btreeGetPage (flags=0, ppPage=<synthetic pointer>, pgno=1, pBt=0x227a99fb3648) at /home/neokylinv7/桌面/SourceCode/mazu/source/sqlcipher/sqlite3.c:60539
#10 lockBtree (pBt=pBt@entry=0x227a99fb3648) at /home/neokylinv7/桌面/SourceCode/mazu/source/sqlcipher/sqlite3.c:61441
#11 0x00007fffd1ae5af0 in sqlite3BtreeBeginTrans (p=0x227a99d683c8, wrflag=0) at /home/neokylinv7/桌面/SourceCode/mazu/source/sqlcipher/sqlite3.c:61799
#12 0x00007fffd1b17fe8 in sqlite3InitOne (db=db@entry=0x227a99f67e08, iDb=iDb@entry=0, pzErrMsg=pzErrMsg@entry=0x227a99c81090) at /home/neokylinv7/桌面/SourceCode/mazu/source/sqlcipher/sqlite3.c:112652
#13 0x00007fffd1b1822c in sqlite3Init (db=db@entry=0x227a99f67e08, pzErrMsg=pzErrMsg@entry=0x227a99c81090) at /home/neokylinv7/桌面/SourceCode/mazu/source/sqlcipher/sqlite3.c:112831
#14 0x00007fffd1b1a098 in sqlite3ReadSchema (pParse=0x227a99c81088) at /home/neokylinv7/桌面/SourceCode/mazu/source/sqlcipher/sqlite3.c:112868
#15 sqlite3LocateTable (pParse=0x227a99c81088, isView=0, zName=0x227a99fea708 "sqlite_master", zDbase=0x0) at /home/neokylinv7/桌面/SourceCode/mazu/source/sqlcipher/sqlite3.c:32141
#16 0x00007fffd1b1a84a in selectExpander (pWalker=0x7fffffffadb0, p=0x227a99fea208) at /home/neokylinv7/桌面/SourceCode/mazu/source/sqlcipher/sqlite3.c:117593
#17 0x00007fffd1aa2e02 in sqlite3WalkSelect (pWalker=pWalker@entry=0x7fffffffadb0, p=p@entry=0x227a99fea208) at /home/neokylinv7/桌面/SourceCode/mazu/source/sqlcipher/sqlite3.c:87991
#18 0x00007fffd1aa327f in sqlite3WalkSelect (p=0x227a99fea208, pWalker=0x7fffffffadb0) at /home/neokylinv7/桌面/SourceCode/mazu/source/sqlcipher/sqlite3.c:87988
#19 sqlite3SelectExpand (pSelect=0x227a99fea208, pParse=0x227a99c81088) at /home/neokylinv7/桌面/SourceCode/mazu/source/sqlcipher/sqlite3.c:52306
#20 sqlite3SelectPrep (pParse=0x227a99c81088, p=0x227a99fea208, pOuterNC=0x0) at /home/neokylinv7/桌面/SourceCode/mazu/source/sqlcipher/sqlite3.c:52392
#21 0x00007fffd1af7762 in sqlite3Select (pParse=pParse@entry=0x227a99c81088, p=0x227a99fea208, pDest=pDest@entry=0x7fffffffb0e0) at /home/neokylinv7/桌面/SourceCode/mazu/source/sqlcipher/sqlite3.c:118172
#22 0x00007fffd1b1250d in yy_reduce (yyruleno=111, yypParser=0x227a99abe708) at /home/neokylinv7/桌面/SourceCode/mazu/source/sqlcipher/sqlite3.c:133385
#23 sqlite3Parser (yyp=yyp@entry=0x227a99abe708, yymajor=yymajor@entry=1, yyminor=..., pParse=pParse@entry=0x227a99c81088) at /home/neokylinv7/桌面/SourceCode/mazu/source/sqlcipher/sqlite3.c:3399
#24 0x00007fffd1b15fbe in sqlite3RunParser
    (pParse=pParse@entry=0x227a99c81088, zSql=zSql@entry=0x7fffd1b3c178 "SELECT name FROM sqlite_master WHERE type='table' AND name=:tbl_name", pzErrMsg=pzErrMsg@entry=0x7fffffffb1f8)
    at /home/neokylinv7/桌面/SourceCode/mazu/source/sqlcipher/sqlite3.c:135410
#25 0x00007fffd1b169a9 in sqlite3Prepare
    (db=db@entry=0x227a99f67e08, zSql=zSql@entry=0x7fffd1b3c178 "SELECT name FROM sqlite_master WHERE type='table' AND name=:tbl_name", nBytes=nBytes@entry=-1, saveSqlFlag=saveSqlFlag@entry=1, pReprepare=pReprepare@entry=0x0, ppStmt=ppStmt@entry=0x7fffffffb378, pzTail=0x0) at /home/neokylinv7/桌面/SourceCode/mazu/source/sqlcipher/sqlite3.c:113061
#26 0x00007fffd1b16ea0 in sqlite3LockAndPrepare
    (db=0x227a99f67e08, zSql=0x7fffd1b3c178 "SELECT name FROM sqlite_master WHERE type='table' AND name=:tbl_name", nBytes=-1, saveSqlFlag=1, pOld=0x0, ppStmt=0x7fffffffb378, pzTail=0x0)
    at /home/neokylinv7/桌面/SourceCode/mazu/source/sqlcipher/sqlite3.c:113153
#27 0x00007fffd1b173b6 in sqlite3_prepare_v2 (db=<optimized out>, zSql=<optimized out>, nBytes=<optimized out>, ppStmt=<optimized out>, pzTail=<optimized out>)
--Type <RET> for more, q to quit, c to continue without paging--c
    at /home/neokylinv7/桌面/SourceCode/mazu/source/sqlcipher/sqlite3.c:113229
#28 0x00007fffd185cf6d in baiduyun::minos::database::SqliteStatement::prepare(char const*) (this=this@entry=0x7fffffffb360, sql=sql@entry=0x7fffd1b3c178 "SELECT name FROM sqlite_master WHERE type='table' AND name=:tbl_name") at /home/neokylinv7/桌面/SourceCode/mazu/source/kernel/base/database_statement.cpp:34
#29 0x00007fffd185c3e5 in baiduyun::minos::database::SqliteConnection::table_existed(char const*) (this=<optimized out>, table_name=table_name@entry=0x7fffd1b983f2 "version") at /home/neokylinv7/桌面/SourceCode/mazu/source/kernel/base/database_connection.cpp:134
#30 0x00007fffd18b0bde in baiduyun::minos::database::TransmitDataInstance::initialize(char const*, baiduyun::minos::database::SqliteEncrytKeys const&) (this=0x227a999be900, path=0x227a99d3f0f8 "/home/ttys3/.config/baidunetdisk/AppData/at_trche", encrypt_keys=...) at /home/neokylinv7/桌面/SourceCode/mazu/source/kernel/persist/transmit_data_instance.cpp:74
#31 0x00007fffd185f431 in baiduyun::minos::log::LogController::initialize(char const*, baiduyun::minos::database::SqliteEncrytKeys const&) (this=0x227a99d4e3c0, config=config@entry=0x227a995bbe98 "{\"root\":\"\\/home\\/ttys3\\/.config\\/baidunetdisk\\/AppData\\/\",\"name\":\"at\",\"use_default_key\":\"1\"}\n", encrypt_keys=...) at /home/neokylinv7/桌面/SourceCode/mazu/source/kernel/log/log_controller.cpp:109
#32 0x00007fffd1848f79 in (anonymous namespace)::logcontroller_initialize (encrypt_keys=..., config=0x227a995bbe98 "{\"root\":\"\\/home\\/ttys3\\/.config\\/baidunetdisk\\/AppData\\/\",\"name\":\"at\",\"use_default_key\":\"1\"}\n") at /home/neokylinv7/桌面/SourceCode/mazu/source/kernel/minos-agent.cpp:47
#33 minos_agent_global_init(char const*, void const*, int, void const*, int) (config=0x227a995bbe98 "{\"root\":\"\\/home\\/ttys3\\/.config\\/baidunetdisk\\/AppData\\/\",\"name\":\"at\",\"use_default_key\":\"1\"}\n", encrypt_key=<optimized out>, key_len=<optimized out>, encrypt_newkey=0x0, newkey_len=<optimized out>) at /home/neokylinv7/桌面/SourceCode/mazu/source/kernel/minos-agent.cpp:141
#34 0x00007fffe08e5008 in baidu::netdisk::sdk::sdk_minos_init (newkey_len=0, encrypt_newkey=0x0, key_len=0, encrypt_key=0x0, config=0x227a995bbe98 "{\"root\":\"\\/home\\/ttys3\\/.config\\/baidunetdisk\\/AppData\\/\",\"name\":\"at\",\"use_default_key\":\"1\"}\n") at /home/common/桌面/project/browserengine/source/browserengine/sdk/minosagent/minos_wrapper.h:32
#35 baidu::netdisk::sdk::MinosConfigManager::init_minos(std::string const&) (this=this@entry=0x7fffffffbc5e, app_path="/home/ttys3/.config/baidunetdisk") at /home/common/桌面/project/browserengine/source/browserengine/sdk/minosagent/minos_config_manager.cpp:61
#36 0x00007fffe0731c87 in browser_engine_global_init(browser_engine_internal_log_callback, browser_engine_common_event_callback) (log_callback=<optimized out>, event_callback=<optimized out>) at /home/common/桌面/project/browserengine/source/browserengine/browser_engine.cpp:144
#37 0x00007ffff6159b10 in ffi_call_unix64 () at /lib64/libffi.so.6
#38 0x00007ffff61590a3 in ffi_call () at /lib64/libffi.so.6
#39 0x00007fffe0f927f9 in FFI::FFICall(Nan::FunctionCallbackInfo<v8::Value> const&) () at /tmp/.org.chromium.Chromium.gNqpPK
#40 0x00007fffe0f925a6 in Nan::imp::FunctionCallbackWrapper(v8::FunctionCallbackInfo<v8::Value> const&) () at /tmp/.org.chromium.Chromium.gNqpPK
#41 0x0000555557cdc6d7 in  ()

目测翻车在libcrypto.so.1.1, 而且是跟sqlite加密有关.

我们把baidunetdisk动态链接到相关的加密库都找出来:

❯ ldd baidunetdisk | grep -i -E 'ssl|crypt'
	libgcrypt.so.20 => /lib64/libgcrypt.so.20 (0x00007fa18d693000)
	libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007fa18d3cd000)
	libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007fa18d0c0000)

经验告诉我，这个baidunetdisk挂的原因是， Fedora 33上面的包都比较新，尤其是 openssl 库. 因此，解决办法是，去下载老版本的 Ubuntu 18.04 的包，然后把so文件取出来，强制baidunetdisk使用这些旧版本的库即可.

ldd 一下很容易找出依赖关系: libkrb5.so.3 -> libk5crypto.so.3 -> libcrypto.so.1.1

老灯下载了以下包:

https://ubuntu.pkgs.org/18.04/ubuntu-main-amd64/libkrb5support0_1.16-2build1_amd64.deb.html
https://ubuntu.pkgs.org/18.04/ubuntu-main-amd64/libk5crypto3_1.16-2build1_amd64.deb.html
https://ubuntu.pkgs.org/18.04/ubuntu-main-amd64/libkrb5-3_1.16-2build1_amd64.deb.html
https://ubuntu.pkgs.org/18.04/ubuntu-main-amd64/libgssapi-krb5-2_1.16-2build1_amd64.deb.html
http://archive.ubuntu.com/ubuntu/pool/main/o/openssl/libssl1.1_1.1.0g-2ubuntu4_amd64.deb

测试下， krb 的包已经成功加载:

❯ env LD_LIBRARY_PATH=$(pwd) ldd ./baidunetdisk | grep /opt/
	libffmpeg.so => /opt/baidunetdisk/./libffmpeg.so (0x00007f8fc36a8000)
	libgssapi_krb5.so.2 => /opt/baidunetdisk/./libgssapi_krb5.so.2 (0x00007f8fc1588000)
	libkrb5.so.3 => /opt/baidunetdisk/./libkrb5.so.3 (0x00007f8fc0bf4000)
	libk5crypto.so.3 => /opt/baidunetdisk/./libk5crypto.so.3 (0x00007f8fc09c2000)
	libkrb5support.so.0 => /opt/baidunetdisk/./libkrb5support.so.0 (0x00007f8fc07af000)

编辑 /usr/share/applications/baidunetdisk.desktop, 将Exec=/opt/baidunetdisk/baidunetdisk --no-sandbox %U 修改成：

Exec=/bin/env LD_LIBRARY_PATH=/home/ttys3/Apps/baidunetdisk /home/ttys3/Apps/baidunetdisk/baidunetdisk --no-sandbox %U

注意，这里老灯把baidu的目录放在/home/ttys3/Apps/baidunetdisk, 测试过程中发现放在默认的 /opt/baidunetdisk 无法成功运行(有可能跟selinux有关，暂时没空看了，解决了问题完事)。

Fedora 33 中的 systemd-resolved DNS resolver

ttyS3 — Sun, 20 Dec 2020 13:20:59 GMT

Fedora 33 中的 DNS resolver 已经由 nss-dns 默认切换成了 systemd-resolved 简单来说，这意味着 systemd-resolved 将作为daemon程序运行。所有想要将域名转换为网络地址的程序都将与之通信。这取代了当前默认的查找机制--每个程序单独与远程服务器交谈，并且没有共享缓存。

如有必要， systemd-resolved 将查询远程DNS服务器。 systemd-resolved 是一个“stub resolver” - 它本身不会解析任何域名（通过从根DNS开始并按标签一路径往下查询），而是将查询转发到远程DNS服务器。其实这种类型的程序我们经常用，比如我们通常用的路由器上一般会用 dnsmasq 做“stub resolver”，其下的局域网机器，通过DHCP自动获取到DNS后通常是这个路由器自己的LAN IP，比如常见的 192.168.1.1 等。dnsmasq 自带缓存功能，也就是说一个域名已经解析过了，它不会每次都需要通过与远程DNS服务器通信来解析，而是可以在命中缓存结果的情况下直接返回。 systemd-resolved 的引入，相当于每台 Linux 机器本身已经有了一个类似 dnsmasq 的东西在跑。同时，每台机器对于跑在上面的程序的DNS查询配置，可以更加灵活了（因为split DNS）。

单个daemon程序处理域名解析提供了显著的好处。由于daemon进程会缓存响应结果，因而可以快速响应高频请求的域名。守护进程记得哪些服务器是非响应的，而预先每个程序都必须在超时后自己弄清楚这一点。个别程序仅在本地传输上与守护程序交谈，并从网络中孤立。守护程序支持花哨的规则，该规则指定应使用哪些名称服务器用于哪些域名 - 事实上，本文的其余部分是关于这些规则。

Enable systemd-resolved by default. glibc will perform name resolution using 'nss-resolve' rather than 'nss-dns'.

systemd-resolved has been enabled by default in Ubuntu since Ubuntu 16.10, but please note we are doing this differently than Ubuntu has. Ubuntu does not use nss-resolve. Instead, Ubuntu uses the traditional nss-dns provided by glibc upstream, so glibc on Ubuntu continues to read /etc/resolv.conf, as is traditional. This extra step is not useful and not recommended by upstream. We want to follow upstream recommendations in using nss-resolve instead.

服务和命令行工具

查看服务状态:

❯ systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2020-12-20 10:08:05 CST; 11h ago
       Docs: man:systemd-resolved.service(8)
             https://www.freedesktop.org/wiki/Software/systemd/resolved
             https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
             https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
   Main PID: 2695 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 38311)
     Memory: 13.0M
        CPU: 8.384s
     CGroup: /system.slice/systemd-resolved.service
             └─2695 /usr/lib/systemd/systemd-resolved

查看当前状态：

❯ resolvectl status
Global
         Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub
Current DNS Server: 127.0.0.1:5354
       DNS Servers: 127.0.0.1:5354

DNS解析(老灯这里特意查询了两次，主要是通过二者的消耗时间对比cache的效果):

❯ resolvectl query 163.com
163.com: 123.58.180.7
         123.58.180.8

-- Information acquired via protocol DNS in 7.7ms.
-- Data is authenticated: no
❯ resolvectl query 163.com
163.com: 123.58.180.7
         123.58.180.8

-- Information acquired via protocol DNS in 624us.
-- Data is authenticated: no

resolvectl statistics 可查询统计信息,比如缓存命中率，缓存条目数量等

resolvectl flush-caches 可清除查询缓存

其它参数可通过resolvectl -h 查看.

特别注意

systemd-resolved 不能当作局域网DNS cache服务器使用，它只能用于本机，因为它监听的是lo (loopback网卡)

stackoverflow上已经有大佬回复了，甚至把相关的代码都贴出来了. https://unix.stackexchange.com/a/549315/405754

You can't. As cristian-rodríguez mentioned above, it was strictly designed to provide services to loopback only. Not even an alternative solution using net.ipv4.conf.all.route_localnet=1 + iptables NAT (such as https://serverfault.com/questions/211536/iptables-port-redirect-not-working-for-localhost), https://superuser.com/questions/594163/how-do-i-route-a-port-range-in-a-linux-host-to-a-guest-vm), and https://stackoverflow.com/questions/18580637/iptables-redirect-from-external-interface-to-loopbacks-port) will work, since systemd-resolve explicitly inspects if the destination is outside the loopback network. See the code below for static void dns_stub_process_query(Manager *m, DnsStream *s, DnsPacket *p)

    if (in_addr_is_localhost(p->family, &p->sender) <= 0 ||
        in_addr_is_localhost(p->family, &p->destination) <= 0) {
            log_error("Got packet on unexpected IP range, refusing.");
            dns_stub_send_failure(m, s, p, DNS_RCODE_SERVFAIL, false);
            goto fail;
    }

参考文档

https://fedoramagazine.org/systemd-resolved-introduction-to-split-dns/ https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html https://fedoraproject.org/wiki/Changes/systemd-resolved

Fedora 32 升级到 Fedora 33

ttyS3 — Wed, 28 Oct 2020 16:36:44 GMT

Fedora 33 在 10月27号准时发布。

官方公告见这儿: https://fedoramagazine.org/announcing-fedora-33/

从官方公告的HTML meta article:published_time 可看到，文章发布时间为 2020-10-27T14:00:14+00:00，也就是 CST 2020-10-27 22:00 左右。老灯现在写文章的时候为 Thu Oct 29 01:03:39 AM CST 2020, 因此距离 Fedora 33正式发布已经整整一天多时间了。

如何从F32升级到F33

步骤基本上是一样的，参考我之前的文章《Fedora 31 升级到 Fedora 32》

选择合适的镜像站

❯ date
Wed 28 Oct 2020 10:17:21 PM CST


--- mirrors.ustc.edu.cn ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99112ms
rtt min/avg/max/mdev = 33.822/46.199/287.057/43.688 ms


--- cdnmirrors.s.tuna.tsinghua.edu.cn ping statistics ---
100 packets transmitted, 86 received, 14% packet loss, time 100655ms
rtt min/avg/max/mdev = 54.097/65.754/270.979/35.645 ms


--- opentuna.cn ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99131ms
rtt min/avg/max/mdev = 7.345/17.239/266.296/38.896 ms

如果是看ping的结果的话，看上去 opentuna.cn 是最佳选项。但是 opentuna 没有 rpmfusion 源，作为一个 Fedora 用户rpmfusion 源几乎是必须的。因此，老灯这里直接pass掉opentuna 源。

其它源，同步不够及时或有其它问题，暂时还没法用于 Fedora 33:

比如上海交大的, 还没同步 F33 源。https://mirrors.sjtug.sjtu.edu.cn/fedora/linux/releases/33/ 直接404 ustc 的同步是有问题（或者不及时）的， https://mirrors.ustc.edu.cn/fedora/releases/33/Modular/x86_64/os/repodata/ 下面完全是空的。

最好老灯测试，只有 tuna 的源（https://mirrors.tuna.tsinghua.edu.cn/fedora）是同步OK的。

老灯把所有源（Fedora 和 rpmfusion）都换成 tuna 的 (因为截止到当前时间, ustc和sjtug的源还没法用于F33)：

cd /etc/yum.repos.d
sed -i 's|mirrors.ustc.edu.cn|mirrors.tuna.tsinghua.edu.cn|g' `rg -l mirrors.ustc.edu.cn`

升级系统到F33

升级过程还是非常顺利的，基本上参数官方文档： https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/

# 首先确保系统更新到F31当前最新版
sudo dnf upgrade --refresh

# 安装dnf system-upgrade 插件（如果没有安装过的话）
sudo dnf install dnf-plugin-system-upgrade
# 下载升级文件, 注意这里的--releasever=32, 下次如果要升级到33, 只需要改动这里 --releasever=33 即可
sudo dnf system-upgrade download --refresh --releasever=32

# 确认前面的操作都进行OK了，就可以执行以下命令开始升级
sudo dnf system-upgrade reboot

我在升级过程中还是遇到点小问题的，不过有惊无险：

/etc/yum.repos.d root@8700k 3m 40s
❯ dnf system-upgrade download --refresh --releasever=33
Ignoring repositories: copr:copr.fedorainfracloud.org:prince781:vala-language-server, scootersoftware
No match for group package "lsvpd"
No match for group package "xorg-x11-drv-armsoc"
No match for group package "k3b-extras-freeworld"
No match for group package "powerpc-utils"
No match for group package "gstreamer1-plugins-bad-nonfree"
No match for group package "cvsgraph"
...
No match for group package "fedora-user-agent-chrome"
No match for group package "google-croscore-cousine-fonts"
Error: 
 Problem: package gstreamer1-plugins-ugly-free-devel-1.16.2-2.fc32.x86_64 requires gstreamer1-plugins-ugly-free = 1.16.2-2.fc32, but none of the providers can be installed
  - gstreamer1-plugins-ugly-free-1.16.2-2.fc32.x86_64 does not belong to a distupgrade repository
  - problem with installed package gstreamer1-plugins-ugly-free-devel-1.16.2-2.fc32.x86_64
(try to add '--skip-broken' to skip uninstallable packages)

前面的 No match 其实可以通过--skip-broken参数解决，但是这个Error是要人工介入处理的。错误信息已经提示我们了，因此直接移除掉gstreamer1-plugins-ugly-free-devel就好了：

dnf remove gstreamer1-plugins-ugly-free-devel

然后继续接着下载：

dnf system-upgrade download --refresh --releasever=33 --skip-broken

输出大概如下：

/etc/yum.repos.d root@8700k
❯ dnf system-upgrade download --refresh --releasever=33 --skip-broken
Before you continue ensure that your system is fully upgraded by running "dnf --refresh upgrade". Do you want to continue [y/N]: y
...
Ignoring repositories: copr:copr.fedorainfracloud.org:prince781:vala-language-server
No match for group package "lsvpd"
No match for group package "k3b-extras-freeworld"
No match for group package "xorg-x11-drv-armsoc"
No match for group package "powerpc-utils"
...
No match for group package "tharlon-fonts"
No match for group package "oflb-icelandic-fonts"
Dependencies resolved.
==============================================================================================================================================================================================================================================
 Package                                                                  Architecture                        Version                                                                Repository                                          Size
==============================================================================================================================================================================================================================================
Installing:
 kernel                                                                   x86_64                              5.8.16-300.fc33                                                        updates                                            6.9 k
 kernel-core                                                              x86_64                              5.8.16-300.fc33                                                        updates                                             33 M
 kernel-devel                                                             x86_64                              5.8.16-300.fc33                                                        updates                                             13 M
 kernel-modules                                                           x86_64                              5.8.16-300.fc33                                                        updates                                             30 M
 kernel-modules-extra                                                     x86_64                              5.8.16-300.fc33                                                        updates                                            2.0 M
Upgrading:
 GConf2                                                                   x86_64                              3.2.6-29.fc33                                                          fedora                                             1.0 M
 GeoIP                                                                    x86_64                              1.6.12-8.fc33                                                          fedora                                             121 k
 GeoIP-GeoLite-data                                                       noarch                              2018.06-6.fc33                                                         fedora                                             681 k
 GeoIP-devel                                                              x86_64                              1.6.12-8.fc33                                                          fedora                                              12 k
 GraphicsMagick                                                           x86_64                              1.3.35-3.fc33                                                          fedora                                             1.5 M
 GraphicsMagick-devel                                                     x86_64                              1.3.35-3.fc33                                                          fedora                                              71 k
 ...
 python3-libdnf                                                           x86_64                              0.54.2-2.fc33                                                          updates                                            775 k
 qbittorrent                                                              x86_64                              1:4.2.5-4.fc33                                                         fedora                                             5.7 M
 yum                                                                      noarch                              4.4.0-2.fc33                                                           updates                                             43 k
Upgrading Groups:
 Anaconda tools                                                                                                                                                                                                                              
 base-x                                                                                                                                                                                                                                      
 C Development Tools and Libraries                                                                                                                                                                                                           
 Container Management                                                                                                                                                                                                                        
 Development Tools                                                                                                                                                                                                                           
 Firefox Web Browser                                                                                                                                                                                                                         
 Guest Desktop Agents                                                                                                                                                                                                                        
 LibreOffice                                                                                                                                                                                                                                 
 Common NetworkManager Submodules                                                                                                                                                                                                            
 Printing Support                                                                                                                                                                                                                            
 Fedora Workstation product core                                                                                                                                                                                                             
 x86 Baremetal Tools                                                                                                                                                                                                                         
 GNOME Desktop Environment                                                                                                                                                                                                                   
 Multimedia                                                                                                                                                                                                                                  
 Core                                                                                                                                                                                                                                        
 Fonts                                                                                                                                                                                                                                       
 Hardware Support                                                                                                                                                                                                                            
 Sound and Video                                                                                                                                                                                                                             

Transaction Summary
==============================================================================================================================================================================================================================================
Install     187 Packages
Upgrade    2537 Packages
Remove        8 Packages
Downgrade    24 Packages

Total download size: 3.0 G
DNF will only download packages, install gpg keys, and check the transaction.
Is this ok [y/N]:

y 回车后就开始下载. 大概下载了 3GB 的文件：

(2748/2748): xorg-x11-drv-nvidia-libs-455.28-1.fc33.x86_64.rpm                                                                                                                                                6.2 MB/s |  78 MB     00:12    
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total                                                                                                                                                                                                         3.3 MB/s | 3.0 GB     15:18     
warning: /var/lib/dnf/system-upgrade/updates-236f50538cae036d/packages/cpp-10.2.1-5.fc33.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID 9570ff31: NOKEY
Fedora 33 - x86_64 - Updates                                                                                                                                                                                  1.6 MB/s | 1.6 kB     00:00    
Importing GPG key 0x9570FF31:
 Userid     : "Fedora (33) <[email protected]>"
 Fingerprint: 963A 2BEB 0200 9608 FE67 EA42 49FD 7749 9570 FF31
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-x86_64
Is this ok [y/N]: y
Key imported successfully
warning: /var/lib/dnf/system-upgrade/rpmfusion-free-83022c35002eaaf4/packages/svt-hevc-libs-1.5.0-2.fc33.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID d651ff2e: NOKEY
RPM Fusion for Fedora 33 - Free                                                                                                                                                                               1.6 MB/s | 1.7 kB     00:00    
Importing GPG key 0xD651FF2E:
 Userid     : "RPM Fusion free repository for Fedora (2020) <[email protected]>"
 Fingerprint: E9A4 91A3 DE24 7814 E7E0 67EA E06F 8ECD D651 FF2E
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-free-fedora-33
Is this ok [y/N]: y
Key imported successfully
warning: /var/lib/dnf/system-upgrade/rpmfusion-nonfree-09983ab4040af696/packages/akmod-nvidia-455.28-1.fc33.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID 94843c65: NOKEY
RPM Fusion for Fedora 33 - Nonfree                                                                                                                                                                            1.6 MB/s | 1.7 kB     00:00    
Importing GPG key 0x94843C65:
 Userid     : "RPM Fusion nonfree repository for Fedora (2020) <[email protected]>"
 Fingerprint: 79BD B88F 9BBF 7391 0FD4 095B 6A2A F961 9484 3C65
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-nonfree-fedora-33
Is this ok [y/N]: y
Key imported successfully
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Complete!
Download complete! Use 'dnf system-upgrade reboot' to start the upgrade.
To remove cached metadata and transaction use 'dnf system-upgrade clean'
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.

执行 dnf system-upgrade reboot 后，系统卡了1分钟左右（黑屏状态）才显示console, 然后成功重启。

重启成功后，GRUB 菜单还是 F32 的选项的，因为更新还没安装嘛。进入之后，整个屏是黑的，有个光标在闪，怀疑是N卡显卡驱动问题。不过实际上是在进行升级安装过程的，我怎么知道的？我是后面才知道的。黑屏了，我并没有马上强制按电源键关机再启动。而是出去抽了根烟，然后等了个几分钟再回来看。发现还是黑屏。于是我按电源键强制关机了，再启动的时候，发现熟悉的 Fedora 33 Grub启动项。

本次升级，没有翻车。

但是有点后怕，这种情况黑屏的时候，还应该等待久一些（比如给它20分钟或30分钟的时间）再关机会更保险，毕竟看不到console不好判断系统升级是否正常结束。

安装完之后，需要进入 https://extensions.gnome.org/local/ 升级一下 GNOME 扩展。升级完GNOME扩展有些会默认显示ERROR不工作，要退出登录再登录一下。

F33 的改变

不得不说， Fedora 每次发版本都会带来新鲜玩意，改动大刀阔斧，有时甚至能带来惊喜。

内核版本基本上和 F32 一样:

Linux 8700k.localhost 5.8.16-200.fc32.x86_64 #1 SMP Mon Oct 19 14:17:16 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Linux 8700k.localhost 5.8.16-300.fc33.x86_64 #1 SMP Mon Oct 19 13:18:33 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

官方默认是 GNOME3，其它 DE 的可从 spins https://spins.fedoraproject.org/en/ 下载到。

GNOME 升级到 3.38 https://www.gnome.org/news/2020/09/gnome-3-38-released/

btrfs 作为默认的文件系统 https://fedoramagazine.org/btrfs-coming-to-fedora-33/

Network Time Security (NTS) 支持，但是要注意： The default NTP client in Fedora is chrony. Chrony added NTS support in version 4.0. The default configuration hasn’t changed. Chrony still uses public servers from the pool.ntp.org project and NTS is not enabled by default.

参考 https://fedoramagazine.org/secure-ntp-with-nts/

除了 x86_64 架构的，alternate architectures: ARM AArch64, Power, and S390x 也可在 https://alt.fedoraproject.org/alt/ 下载到。改进了对 Pine64，NVidia Jetson 64， Rockchip SoC(如Rock960, RockPro64, and Rock64等)的支持。

提供专门的 IoT 版本下载，采用OSTree技术, 目前支持的架构有 aarch64， armhfp 和 x86_64

系统底层库升级，如 Binutils 2.34， GNU C Library 2.32， Update the system JDK in Fedora from java-1.8.0-openjdk to java-11-openjdk， LLVM 11， GNU make 4.3，RPM 4.16， Sqlite RpmDB（Change format of the RPM database from Berkeley DB to a new Sqlite format.）， swap on zram， systemd-resolved， Enable systemd-resolved by default. glibc will perform name resolution using nss-resolve rather than nss-dns.

编程语言库升级，包括 Python 3.9, Node.js 14.x， Ruby on Rails 6.0, and Perl 5.32， Golang 1.15 等

EarlyOOM 服务 (earlyoom.service) 默认开启可改善内存不足时的用户体验。

nano 被设置成了系统默认的编辑器，这一点老灯承认，明智之举。因为会Vim的人会自己配置 EDITOR=vim, 不会Vim的人才会用默认的 nano.

完整的列表请见官方文档： https://fedoraproject.org/wiki/Releases/33/ChangeSet

其它参考资料

https://fedoraproject.org/wiki/Releases/33/ChangeSet

https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/

https://www.fosslinux.com/43968/fedora-33-whats-new-and-how-to-upgrade.htm

https://www.cyberciti.biz/faq/upgrade-fedora-31-to-fedora-32-using-the-cli/

https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html

/dev/ttyS3 Blog

Fedora Linux CPU Frequency Scaling using cpupower

命令行方式1 -- 不依赖外部工具

Scaling governors 的具体含义

命令行方式2 -- cpupower

命令行方式3 -- powerprofilesctl

misc

kernel-tools 里的其它命令

intel_pstate

refs

Github is Leaking Your Commit Timezone

时区信息是如何获取到的？

如何避免时区泄露?

Cross Compile Darwin Target Under Linux Troubleshooting

How to Send Desktop Notifications under Linux

refs

关于 OpenZFS

kernel modules

Flameshot troubleshooting

使用 GNOME 自定义快捷键无法调起 flameshot gui

点击 "Take Screenshot" 无法显示截图界面

点击 "Take Screenshot" 直接被拒绝

"保存到文件" 无反应

refs

fix Cloudflare cache + Next.js “Text content does not match server-rendered HTML”

background

how to see the problem

how I got the solution?

the solution

How to Export All Your Evernote Notes to Markdown

Step 1. Database initialization

Step 2. Downloading Evernote data

Step 3. Exporting *.enex files

Step 4. Convert it into markdown

Step 5. Choose an alternative

Blog 从 Hugo 迁移到 Tailwind Next.js Blog

migration repo

Guide to MDX

netlify related

build Failed

Next.js integrations

Node.js environment

Next.js on Netlify

Troubleshooting Next.js on Netlify

troubleshoot

1. .md to .mdx rename

2. markdown link compitable with MDX

3. null-safe join of tags

3. build problem

page bundle image support

Netlify

Setup Chrome ExtensionInstallAllowlist Policies Under Linux

Windows 下的方法

Linux 下的方法

Refs

修复 systemd resolved DNS 配置

solution

misc

How to Upgrade CentOS Stream 8 to Stream 9

升级步骤

其它清理

其它

Refs

ACM 会员已无 O'Reilly Learning 羊毛可撸

缘由

商家的套路

new TOML crate

Refs

Linux Console HiDPI Font Config

Linux Console 字体太大了

GRUB HiDPI 字体调整

Refs

Switch From GDM to LightDM Due to GDM Wayland Session Issue

锁屏问题

HiDPI 问题

SDDM: 折腾以失败告终, 最终退回 LightDM

Refs

给 Hugo 博客添加 PlantUML 支持

添加到 Hugo 模板

流程图

1. `.md` to `.mdx` rename