官方提到下载安装密钥的指令是：

sudo wget -nc -O /usr/share/keyrings/winehq-archive.key https://dl.winehq.org/wine-builds/winehq.key

但是你apt update会得到这样的错误:

错误:5 https://dl.winehq.org/wine-builds/debian bookworm InRelease
由于没有公钥，无法验证下列签名： NO_PUBKEY 76F1A20FF987672F 正在读取软件包列表... 完成W: GPG
错误：https://dl.winehq.org/wine-builds/debian bookworm InRelease:
由于没有公钥，无法验证下列签名： NO_PUBKEY 76F1A20FF987672F E: 仓库“https://dl.winehq.org/wine-builds/debian bookworm InRelease”
没有数字签名。N: 无法安全地用该源进行更新，所以默认禁用该源。N: 参见 apt-secure(8)
手册以了解仓库创建和用户配置方面的细节。

最开始我没注意密钥路径不对，接着就习惯性

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 76F1A20FF987672F

但是问题依旧，倒着往上查操作，在查看/etc/apt/sources.list.d/winehq-bookworm.sources的时候发现
最后一行分明写的是：Signed-By: /etc/apt/keyrings/winehq-archive.key
那你密钥干嘛让我装到/usr/share/keyrings/winehq-archive.key ???
所以先手动移动过去。
mv /usr/share/keyrings/winehq-archive.key /etc/apt/keyrings/winehq-archive.key

这个问题也被一些国内的镜像站点给抄过去了。比如清华的镜像源，不过截至发稿时间，清华源还没有同步Debian12的wine-build，可能得等到第二季度 Debian12正式发布以后了。
给管理员发了邮件申请改改wiki，目前尚未回复。

2023年11月27日：
看了看发现WineHQ依旧没改中文Wiki，清华源的也依然没变化。
我查看了https://wiki.winehq.org/Download_zhcn上面存在的维护者名字，中文写的维护者是无，所以我再次发了一封邮件，这次发给了一位非中文的维护者Rosanne DiMesio。如果收到回复我会继续在文章后面更新，或者有必要的话我尝试去申请一下作为Wiki的中文维护者。（话说上次发给web-admin@winehq.org的邮件都是三月份的事情了，现在都11月了也没人回我，真够无语的）
2023年12月30日：
评论区有网友提醒WineHQ WIki中文页面已经在10 December 2023, at 14:57修正了这个问题。
感谢 jkfloris提供的帮助，事实证明在Wine论坛发帖子比发邮件管用多了😀

不过令人遗憾的是TUNA还没来得及改，也在邮件列表发了帖子，希望早点获得修正。
按照评论的提示，这个问题确实不会发生在清华的镜像站上。（前提是一开始就全程按照镜像站的提示操作）
我回忆了一下当初的操作，有相当多的人应该是先用了WineHQ官方的源发现下的很慢或者干脆直接被运营商阻断了连接再跑去用的镜像。但是镜像用的路径不是照着官方sources文件而是自己新建了个winehq.sources。
如果和我同样先用了官方的源再尝试用镜像，/etc/apt/sources.list.d路径下应该存在一个winehq-bookworm.sources

Types: deb
URIs: https://mirrors.tuna.tsinghua.edu.cn/wine-builds/debian/
Suites: bookworm
Components: main
Architectures: amd64 i386
Signed-By: /etc/apt/keyrings/winehq-archive.key

这里Signed-By的路径应当按照实际密钥下载的路径写，不管是/etc还是/usr下都无所谓，我个人倾向于下载到官方sources里的写的/etc/apt/keyrings/winehq-archive.key。
评论区说被清华坑了一道是不正确的，准确来说这是被WineHQ的中文旧文档坑了一道。

反复检查，代码无任何问题。
直接使用python解释器也能正常启动，但是在vsc里用code runner插件运行就报错。

PS E:\PythonDevelopFiles\GUI-n2n> python -u "e:\PythonDevelopFiles\GUI-n2n\app.py"
Traceback (most recent call last):
  File "e:\PythonDevelopFiles\GUI-n2n\app.py", line 3, in <module>
    from tkinter import *
  File "C:\ProgramData\chocolatey\lib\mingw\tools\install\mingw64\lib\python3.9\tkinter\__init__.py", line 37, in <module>
    import _tkinter # If this fails your Python may not be configured for Tk

Windows的Python安装包默认是会安装tkinter的，接着我发现我居然有两个可选解释器

第二个貌似是不久前为了编译n2n安装choco包管理器后使用choco安装的，打开控制面板\程序\程序和功能，发现确实还有个
Python Launcher 3.9.7686.0，大概是两个注册环境产生冲突了。所以手动运行了其中一个的安装工具进行配置选择修复，果不其然发现tk/tcl是扫描到的修复项目。
接着发现问题没有解决，并且在windows目录下手动找到了一些乱七八糟的pyhton文件残留。
索性重新安装python3.8 （为了兼容Windows7）
接着问题依旧，连从外部运行也出现报错：文件名、目录名或卷标语法不正确。

我人麻了，Windows真的不适合开发。。。。配置开发环境可用性还要用户手动去保证，商店下的py3.8还这个德行。我不想在微软阿三的粪坑上浪费时间了，直接重启到Debian11
sudo apt install python3-tk #Debian11已经预装Python3了，但是没有预装tk。

Linux下Python的tkinter库是单独打包的。（因为非开发者通常不需要下载tk即可运行常见的的各类应用，即使某些有需要，其打包时也会写明对python3-tk的依赖。

VSC启动.....

[Running] python -u "/tmp/tempCodeRunnerFile.python"
/bin/sh: 1: python: not found

[Done] exited with code=127 in 0.008 seconds

好吧，Code Runner 默认用的是python这个命令调用的，手动建立个软链接就好了。
或者...sudo apt install python-is-python3 #我更喜欢使用包管理器，而不是让自己手动制造哪些我可能在未来忘记或产生疑问的非常规因素。
VScode 启动，右键 Run Code
窗口出现，继续开发。

尾声：祝愿不可靠的MS Windows早点从中国广大用户的PC里滚蛋，哪怕使用不被看好的国产Linux发行版也比这种屎山生态的不可控专有软件更有利于国家发展。

PS：今天早上把应用商店的Python3.8卸载掉，果断choco install python3安装了最新版，功能一切正常，问题解决。

前言：我使用的主题是基于默认主题修改的，主体样式并没有太多变更，主要是增添需要的内容。这个功能算是刚需，之前用VOID的时候习惯了，后来自己改默认主题没把这个加进去，这次补上。

添加到index.php的合适位置即可，注意官方主题使用ul标签，你应该把li标签里的内容放在ul块里。

<li>
<?php if($this->user->hasLogin()):?>
<a href="<?php $this->options->adminUrl(); ?>write-post.php?cid=<?php echo $this->cid;?>" target="_blank">编辑</a>
<?php endif;?>
</li>

对于新手不管是使用DevEco 给HarmonyOS开发还是用用AS给Android开发应用，要完成窗口组件和一个网络请求得到数据的的绑定都异常的繁琐，有些问题没人教根本无法解决。但是同样的问题在Windows和Linux上几乎不存在，这似乎和JAVA这个怨种语言有分不开的关系。
很遗憾我现在嗐没办法用上eTS给手机开发，因为API6仅仅支持JS和JAVA，所以截至到现在，移动端应用开发的工具对于我就是浪费空间和多次尝试时间的电子垃圾。

RIME（中州韵输入法引擎）是由佛振开发的自由软件，以 BSD-3-Clause license开源。RIME存在多个平台分支，包括Windows、darwin和Linux，以及Android四个主要平台分支。

作为一款自由软件，RIME的主要分支大都支持导出词库配置快照，因此有机会实现备份。
预定方案：使用Python编写，对需要同步的文件使用Webdav协议连接自建或坚果云Webdav等服务商进行同步，UI方案使用Python自带的Tkinter。（暂时对安卓开发无能为力）

这是我写的DS18B20用户态驱动

Goodspeed最近好像比较清闲，所以这位有点闲的同学跑来远程我的OrangePi Zero2 完成了一份正经的单总线驱动。实现后效果如下：

root@orangepizero2:~# cd /sys/bus/w1/devices/28-0721c061a6ac/
root@orangepizero2:/sys/bus/w1/devices/28-0721c061a6ac# ls
alarms eeprom_cmd hwmon power temperature
conv_time ext_power id resolution uevent
driver features name subsystem w1_slave
root@orangepizero2:/sys/bus/w1/devices/28-0721c061a6ac# cat w1_slave
bb 01 4b 46 7f ff 0c 10 74 : crc=74 YES
bb 01 4b 46 7f ff 0c 10 74 t=27687

显而易见大约27摄氏度，详细过程会在他的博客写好后在下方公开。（人比人气死人:)

给香橙派 Zero 2 适配 1-wire 总线

给香橙派 Zero 2 适配 1-wire 总线————William Goodspeed
在向Goodspeed抱怨此事之前，香橙派官方4群里邹明燊先生也曾经写过一个dts文件，也是根据其他已经支持1-wire的设备简单改写的（如下），但是我通过orangepi-add-overlay xxx.dts 添加后会在日志中看到错误信息，即我上一篇文章里写被占用的哪些错误信息，并且经过测试dts生成的dtb文件没有正常工作。而Goodspeed提供的截图中可以看到，这个dts文件并没有写错，只是设置的GPIO不同。

/dts-v1/;
/plugin/;

/ {
    compatible = "allwinner,sun50i-h616";

    fragment@0 {
        target = <&pio>;
        __overlay__ {
            w1_pins: w1_pins {
                pins = "PC9";
                function = "gpio_in";
            };
        };
    };

    fragment@1 {
        target-path = "/";
        __overlay__ {
            onewire@0 {
                compatible = "w1-gpio";
                pinctrl-names = "default";
                pinctrl-0 = <&w1_pins>;
                gpios = <&pio 2 9 0>; /* PC9 */
                status = "okay";
            };
        };
    };
};

二者的主要不同在于Goodspeed是在 arch/arm64/boot/dts/allwinner/overlay/Makefile 中加入一行 sun50i-h616-w1-gpio.dtbo，make dtbs让构建系统编译新的 overlay，而邹明燊先生试图让我直接通过orangepi-add-overlay将改写好的单总线支持dts文件编译并自动添加到overlay路径。
这两者方法不太一样，Goodspeed的方法是从orange-pi-5.16-sunxi64 linux分支源码中自动编译生成dtbo文件，而邹明燊先生是自己写dts从写好的dts去编译得到dtbo文件。但是不知道为什么后者无法生效，从内核日志里的报错看是和pinctl冲突了，也就是说比pinctl抢先占用了pin，但是理论上应该先由pinctl统一管理，驱动应该基于pinctl运行。从这点看，由linux分支源码去自动编译可能会得以避开这一问题，但是具体避开抢占问题的原理就不得而知了，我也不打算深究。

Goodspeed编译好的单总线设备树overlay文件

prebuilt-dtbs.tar

关于linux设备树，请参考如下内容深入浅出理解Linux设备树(DTS)
Dts：DTS即Device Tree Source，是一个文本形式的文件，用于描述硬件信息。一般都是固定信息，无法变更，无法overlay。
Dtsi：可以理解为dts的公共部分，添加、变更非常灵活。Dtsi包含在dts中。
Dtb：Dtb编译出来的二进制
Dtbo：Overlay编译出来的二进制
dtbo-base：指定overlay是以哪个dtb为base来覆盖的。
Node：树的节点
Property：属性

这是个很危险的决定，但是我还是坚持更新到了v1.2.0-rc.2 0b021e5 ，总有人要去试错提交issue
这是一个预发行版本，Typecho的作者出于某种原因在30 Oct 2017 1.1(17.10.30)后没有再发布稳定发行版，但是强大的开源社区还是不断地对Typecho进行了相当活跃的迭代。
感谢开源社区，替换admin和var目录后我顺利完成了整个程序的更新。

设计目的是方便在H&G里打狙。顺带一提，我忘了怎么制作外挂了(也许写的出挂我就用不上这个了)。

功能要素

1. 一个小准星，几个像素点聚集在一个点的就可以。
2. 按键调整是否显示
3. 按键调整准星位置
4. 保持准星在游戏画面内稳定显示不过渡遮挡按钮

预期实现方法

python3 tkinter 像素级超小带色无边框窗口

具体实现：

from contextlib import suppress
from tkinter import *
from keyboard import *
root=Tk()
root.title("crosshair")
x = round(root.winfo_screenwidth()/2-2)
y = round(root.winfo_screenheight()/2-2)
root.geometry("4x4+{}+{}".format(x,y))
root.resizable(0,0)
root.overrideredirect(True)
root.config(bg="#7cfc00")
root.lift()
root.attributes("-topmost", True) #保持准星窗口在顶层
root.wm_attributes('-topmost', 1)
hook_key("end", root.destroy)
def autoadjust():
    x = round(root.winfo_screenwidth()/2-2)
    y = round(root.winfo_screenheight()/2-2)
    root.geometry("4x4+{}+{}".format(x, y))

hook_key("home",autoadjust)

root.mainloop()
print("hello")
unhook_all()