分类 编程语言 下的文章

对多项色彩和样式大小进行了微调，背景色改为象牙白，纯净但不显憔悴。
过去默认主题长期使用蓝色作为a链接的强调色，这次更换了薄荷绿，意蕴勃勃生机。
不管环境如何恶劣，你总能在山脚岩缝中寻到那一抹清凉的绿意。
篱间薄荷堪谋醉，何必区区慕细鳞。

之前一直都没解决这个问题，导致B站点播放器大小很小什么都看不清。凌晨发文章引用B站视频的时候就忍不了了，加了几行CSS把PC端大小调整的稍微正常了点。但是刚才又看见这个东西，想起来移动端这么写死的调整太“方”了，现学现卖用了一下Media终于调整舒服了。
方法简单粗暴。

@media screen and (min-width: 35rem ){
iframe {
    position: relative;
    width: 100%;
    height: 22rem;
    padding-bottom: 5%; 
}}
@media screen and (max-width: 30rem){
iframe {
    position: relative;
    width: 100%;
    height: 15rem;
    padding-bottom: 5%; 
}}

我真的很高兴Typecho社区在过去数年长期停止发布正式更新之后依然保持着极高的活跃度，原开发者也腾出手来加入了开发进程，现在一切正在步入正轨。

安全方面

1.这个更新修复了多个XSS漏洞。（包括我之前遇到的评论者信息框的mail和URL的两个XXS以及后台的一个XXS）

其他主要惊喜总结

1.对PHP8的更多支持
2.添加admin/footer.php开始插件的支持
详见：Release v1.2.1

以前也有很多无聊的小鬼喜欢对着我的站点舞弄他胯下的那根牙签，最无聊的那些还在我的站点日志里刷针对thinkphp或者/backup.zip之类搞笑的请求，难得有个比较务实一些所以记录下来。
相关的漏洞，稍微限制下字符串长度就能临时缓解，不过我的博客数据是自动备份的，丢不了所以懒得搭理这些无聊的小鬼。各位看戏就行。

- 阅读剩余部分 -

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

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月了也没人回我，真够无语的）

反复检查，代码无任何问题。
直接使用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的，接着我发现我居然有两个可选解释器

2023-01-27T19:39:36.png
第二个貌似是不久前为了编译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安装了最新版，功能一切正常，问题解决。

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5