Appimage的文件储存在哪里

我不饿：

有人知道怎么删除appimage的用户数据吗？

liolok | 李皓奇:

还是可以在用户的家目录下面乱写的吧

Lipis Apple:

不太讲武德：~/.local/share/(app)

算讲武德：~/.config/(app)

不讲武德：~/.(app)

via 竹林里有冰的博客 (author: 竹林里有冰 (zhullyb@outlook.com))

使用Chrome的同步api为chromium开启同步功能

via 竹林里有冰的博客 (author: 竹林里有冰 (zhullyb@outlook.com))

最近基本固定了在Archlinux上的常用软件，也供各位参考一下。

我是KDE用户，所以KDE家的软件会用得比较多。

浏览器：Firefox，Chromium备用（主要是使用chromium的网页翻译功能，还有就是打开一些对Firefox不太友好的网站）

下载器：curl，wget，motrix 根据不同使用场景更换下载器

终端：konsole

输入法：fcitx5-chinese-addons

即时通讯：telegram，deepin-wine-tim，deepin-wine-wechat，electron-qq，wechat-uos，linuxqq

播放器：vlc

编辑器：nano，kate，visual-studio-code-bin，typora，wps

图形类：pinta，drawio-desktop-bin，imagemagick

文件管理器：dolphin

文件传输：sftp（命令行里的），filezilla

系统、网络工具：latte-dock-git，v2raya，htop，gtop

via 竹林里有冰的博客 (author: 竹林里有冰 (zhullyb@outlook.com))

记一次在Gitlab部署Jekyll博客时遇到的jekyll-github-metadata报错问题

via 竹林里有冰的博客 (author: 竹林里有冰 (zhullyb@outlook.com))

禁止deepin-wine-tim使用simsun字体渲染

via 竹林里有冰的博客 (author: 竹林里有冰 (zhullyb@outlook.com))

使用vercel创建一个随机图片api

如果你的网络环境不算太差的话，你在访问我博客的时候应该可以看到顶部有一张背景图。假如你访问我的博客时留心观察，你或许会发现每次你访问我博客时的背景都是不一样的。如果你没玩够，或许你可以尝试点击这里，我总共搜集了20张壁纸供诸位赏玩。

是的，这是使用php实现的随机图片api，托管于vercel，你可以在aya的博客上找到我使用的代码。具体配置方式我不再赘述。

然而，我们还需要解决一个问题: php在哪里运行？

如果你拥有自己的服务器，在国内访问速度毫不逊色，那就好办了，直接扔自己服务器上即可。然而，我并没有。我需要找到一个在国内访问速度给力的地方来部署我的api，以确保访客在打开我的博客时可以在第一时间获取到图片的真实链接并开始加载。

起初，我将其部署在我的好朋友(你可以猜猜他是谁)的国内vps上，访问速度自然不用说。然而，他的服务器不支持https，这就导致使用chrome访问的时候chrome不会自动访问我的api，博客顶部一片惨蓝。。。

随后，我使用的是000webhost提供的虚拟主机，国内访问起来也还不错，大概正常运行了半个月左右的时间，然后莫名开始502了。我懂，作为不交钱的白嫖用户应该自觉滚蛋了，这点觉悟咱还是有。

随后，我找到了目前的方案——vercel

vercel是被我用来部署静态网页的，但我没想到他也能支持php。参考了vercel-php项目后，我大致了解了整个仓库结构。

project
├── api
│   └── index.php
└── vercel.json

php和附带的资源文件(如果有的话)一定要放到api文件夹下才能够正常被vercel识别。

以下附vercel.json

{
  "functions": {
    "api/index.php": {
      "runtime": "vercel-php@0.4.0"
    }
  }
}

via 竹林里有冰的博客 (author: 竹林里有冰 (zhullyb@outlook.com))

我为什么选择Archlinux？

对于我而言，我用Archlinux主要的原因就是实用主义。我可以很负责的说，Arch真的是在我所有用过的发行版当中最符合实用主义的一个了。

很多大佬一提到Archlinux就扯些什么kiss原则，在我看来则不然。

整洁规范的系统

规范代码为的不是为了什么Art of Code，而是可读性的提升；遵循kiss原则亦是如此。

配置文件的路径写好了，符合规范，我们就能一下子找到，我们是为了实用主义而遵守kiss原则。

同样的，我同样可以为了实用主义而破坏kiss原则。比如在我的archiso-zhullyb中，我添加了一个pacman的hook将我的定制内核重命名为linux以确保其能够正确被ventoy所识别，这也是为了实用主义。

那么，什么时候我会破坏kiss原则呢？当我认为破坏kiss原则所带来的利大于弊时，我就会考虑以一个并不规范但却有效的方法来处理问题。

但很有趣的是，由于Archlinux的官方总是将kiss奉为圣旨，这就给我们提供了一个非常nice的环境了——在一个非常规范的系统内，破坏kiss原则所带来的代价并不会很大，这就好比在一个布线整齐的机房内临时私拉两三根线并不会给维护带来多大的困难。

Archlinux对上游软件包的发行策略

不同于apt在源内提供了统一软件的多个版本供用户选择，pacman剑走偏锋，默认用户系统内所有软件都是最新的。

由此带来了一个好处——不会出现由于版本过高/过低导致的依赖问题。只要我保证系统内的所有软件都是最新的，就不会出问题，非常的简单粗暴。

此外，不考虑依赖版本这一特点对于打包人来说也是一种解脱。

pacman简单的打包方式

不同于deb以及rpm，pacman的软件包应该是所有发行版中最省事儿的。

打包软件时，我们只需要写（改）一份PKGBUILD，就可以仅仅通过在PKGBUILD所在的路径执行makepkg命令来完成一次打包，这相比起deb而言可谓是天差地别。如此简单有效的打包方式注定其将被实用主义者所青睐。

超低的社区贡献成本

很多发行版社区开发与贡献其实并不容易参与进去，我拿Ubuntu来做个比较。

附: Archwiki是先斩后奏类型的文档，在你按下保存按钮的那一刻，wiki将立即被更新，所有访客都将看到你改动后的内容。wiki文档拥有变更记录，不担心有人恶意搞破坏，向wiki管理员提出举报后破坏者的账号会被及时封禁，wiki可以非常简单地回滚到之前的状态。

AUR同样也是，你可以随意上传自己的PKGBUILD，可以被别的用户及时看到。如果上传恶意脚本，在别的用户举报后你将迅速被封号。

Wiki方面

Ubuntu其实是我第一个上手的Linux发行版，在为期半年的Ubuntu体验中，我对于社区做出的贡献为0。这倒也不是我不热衷于参与社区贡献，而是对Ubuntu社区的贡献成本太高了。去贡献文档翻译，需要等待漫长的审核过程，在第一篇汉化文章正式展现在别的用户眼前后，我一定会被激发出继续翻译第二篇的热情。然而，面对太长的审核周期，再高涨的热情恐怕也会被浇灭。

Arch的社区则不一样，他并不像别的社区那样严谨——只要注册个wiki的账号便可以开始贡献文档。你可以随意地编辑一篇文章或者是新增一篇自己的文章，编辑后的文章将能够立即被别的用户所阅读到，没有任何审核过程，有了这份热情，我便继续翻译别的文档，我想，这应该就是archwiki为何涵盖面如此之广的原因。

AUR方面

同样也是拿Ubuntu对比。

在Archlinux下，我只需要简单的写一个PKGBUILD即可轻松构建一个软件包，同时，我也可以将这份有我攥写的PKGBUILD上传到AUR供别的用户使用。AUR作为一个公开的储存库，任何Arch用户都可以通过AUR Helper轻松得从AUR中获取我写的PKGBUILD并在本地打成自己的包。与此同时，我也可以创建一个私人源，直接发行我构建的二进制包。

Ubutnu则不然，他的打包方式则要麻烦得多，同时也没有类似PKGBUILD一样的东西便于用户分享自己的打包脚本。唯一能够分享自己的劳动成果的方式无非就是直接分享自己打出来的deb包，最多也不过是建立自己的ppa，这对于用户来说是极为麻烦的。用户需要处心积虑地寻找自己所需要的deb包或是含有目标包的ppa地址并手动添加，不像Archlinux有AUR这种东西能够让我们知道在哪里能够找到我们所需要的包。

via 竹林里有冰的博客 (author: 竹林里有冰 (zhullyb@outlook.com))

请给 tuna/ustc 镜像站减压

via 竹林里有冰的博客 (author: 竹林里有冰 (zhullyb@outlook.com))

选择最新的Archlinux镜像源

找到最新的Archlinux镜像源

我是testing+kde-unstable用户，平均每天更新4次，对于我而言，选择最新的Archlinux镜像是非常重要的。

Archlinux的主源并不开放给个人用户使用，仅开放给一级镜像站进行同步，因此我们需要手动寻找国内较新的镜像站。（理论上来说一级镜像站应该比二级镜像站更新，但是有些一级镜像站的同步频率并不高，同步延迟可能会比某些二级镜像站还要高）

一个archlinux的镜像目录大概是长下面这个样子

archlinux/
├── community
├── community-staging
├── community-testing
├── core
├── extra
├── gnome-unstable
├── images
├── iso
├── kde-unstable
├── lastsync
├── lastupdate
├── multilib
├── multilib-staging
├── multilib-testing
├── pool
├── staging
└── testing

其中的lastsync和lastupdate用unix时间戳记录着上一次同步时间和镜像的上一次变更时间。

因此，我们只需要对比各个镜像站的lastsync谁比较新就行了，我写了如下的辣鸡脚本

#!/bin/bash

tuna=$(curl -s https://mirrors.tuna.tsinghua.edu.cn/archlinux/lastsync)
bfsu=$(curl -s https://mirrors.bfsu.edu.cn/archlinux/lastsync)
sjtug=$(curl -s https://mirror.sjtu.edu.cn/archlinux/lastsync)
aliyun=$(curl -s https://mirrors.aliyun.com/archlinux/lastsync)
ustc=$(curl -s https://mirrors.ustc.edu.cn/archlinux/lastsync)
zju=$(curl -s https://mirrors.zju.edu.cn/archlinux/lastsync)
cqu=$(curl -s https://mirrors.cqu.edu.cn/archlinux/lastsync)
lzu=$(curl -s https://mirror.lzu.edu.cn/archlinux/lastsync)
neusoft=$(curl -s https://mirrors.neusoft.edu.cn/archlinux/lastsync)
dgut=$(curl -s https://mirrors.dgut.edu.cn/archlinux/lastsync)
netease=$(curl -s https://mirrors.163.com/archlinux/lastsync)
tencent=$(curl -s https://mirrors.tencent.com/archlinux/lastsync)
hit=$(curl -s https://mirrors.hit.edu.cn/archlinux/lastsync)
huaweicloud=$(curl -s https://mirrors.huaweicloud.com/archlinux/lastsync)
sohu=$(curl -s https://mirrors.sohu.com/archlinux/lastsync)
opentuna=$(curl -s https://opentuna.cn/archlinux/lastsync)
pku=$(curl -s https://mirrors.pku.edu.cn/archlinux/lastsync)
nju=$(curl -s https://mirrors.nju.edu.cn/archlinux/lastsync)
njupt=$(curl -s https://mirrors.nju.edu.cn/archlinux/lastsync)

echo """
$tuna        #tuna
$bfsu        #bfsu
$sjtug       #sjtug
$aliyun      #aliyun
$ustc        #ustc
$zju         #zju
$cqu         #cqu
$lzu         #lzu
$neusoft     #neusoft
$dgut        #dgut
$netease     #netease
$tencent     #tencent
$hit         #hit
$huaweicloud #huaweicloud
$sohu        #sohu
$opentuna    #opentuna
$pku         #pku
$nju         #nju
$njupt       #njupt
"""  | sort -r

其运行结果如下

1622248120     #neusoft
1622247879        #dgut
1622247698         #hit
1622246042         #zju
1622246042        #tuna
1622246042        #bfsu
1622242426       #sjtug
1622242426       #njupt
1622242426         #nju
1622240702        #ustc
1622240522         #cqu
1622238783     #netease
1622235120         #lzu
1622232241 #huaweicloud
1622230871     #tencent
1622217845      #aliyun
1622217001         #pku
1622203750        #sohu
1622166379    #opentuna

通过不同时刻的多次测试可以看出，国内同步频率最高的是东软（neusoft）的镜像。顺手一查，没错，是个一级镜像站。通过unix时间戳得知，东软的archlinux镜像几乎是每分钟同步一次，恐怖如斯。。。

获得更好的下载速度

我们已经得知东软是国内同步频率最高的Archlinux镜像站了，但是我用东软镜像站的下载速度并不太好看。此时，我们就要搬出依云大佬的神器——pacsync

在root用户下使用如下命令装载pacysnc后

echo '#!/bin/bash -e

unshare -m bash <<'EOF'
mount --make-rprivate /
for f in /etc/pacman.d/*.sync; do
  filename="${f%.*}"
  mount --bind "$f" "$filename"
done
pacman -Sy
EOF' > /usr/bin/pacsync

创建/etc/pacman.d/mirrorlist.sync指定我们用来同步pacman数据库（比如东软）

/etc/pacman.d/mirrorlist中存放其他国内镜像源地址（按照同步速度从上到下）

以后的同步命令为 sudo pacsync && yay -Su

觉得命令过长的话设置alias可以是个不错的选择。

via 竹林里有冰的博客 (author: 竹林里有冰 (zhullyb@outlook.com))

在Windows与Linux双系统下共享蓝牙鼠标

via 竹林里有冰的博客 (author: 竹林里有冰 (zhullyb@outlook.com))

下载一份openharmony的源码

via 竹林里有冰的博客 (author: 竹林里有冰 (zhullyb@outlook.com))

来，从AUR给Fedora偷个包

via 竹林里有冰的博客 (author: 竹林里有冰 (zhullyb@outlook.com))

使用fakehome方案暂时解决跑在KDE暗色主题下的程序使用亮色字体的问题

9月6日更新：AUR的wemeet-bin维护者sukanka已经将咱的运行指令直接打进了包内，故本文已经基本失去原本的应用意义，但仍可以作为一个案例来解决类似问题。

在使用腾讯最近推出的Linux原生腾讯会议的时候，咱遇到了个十分影响体验的问题。

我在使用KDE的暗色主题，腾讯回忆自作主张将字体颜色调成了白色。然而，字体背景是白色的没，因此导致对比度下降，字体难以辨认。效果大概是这个鬼样子:

然而我一时半会儿却找不到合适的变量在运行腾讯会议之前unset，无法指定它使用一个正确的字体颜色。

此时，我想到了fakehome的解决方案——bwrap。

关于bwrap，依云在ta的博客里讲过运行原理，我在这里直接摘一小段过来

bwrap 的原理是，把 / 放到一个 tmpfs 上，然后需要允许访问的目录通过 bind mount 弄进来。所以没弄进来的部分就是不存在，写数据的话就存在内存里，用完就扔掉了。

而我们要做的，就是开一个tmpfs作为$HOME/.config，让腾讯会议读取不到KDE的主题配置文件。

使用如下命令

bwrap --dev-bind / / --tmpfs $HOME/.config wemeet

软件启动确认没有问题后，我们可以更改腾讯会议desktop中的启动命令

sudo $EDITOR /usr/share/applications/wemeetapp.desktop

将Exec=后面的命令改成我们刚刚启动所使用的命令即可。

关键词: bwrap, linux, 暗色模式, 深色模式, 夜间模式, 白色字体, 亮色字体

via 竹林里有冰的博客 (author: 竹林里有冰 (zhullyb@outlook.com))

使用AUR(Helper)安装软件时究竟发生了什么？对于常见的构建错误如何解决？

via 竹林里有冰的博客 (author: 竹林里有冰 (zhullyb@outlook.com))