GTX690战术核显卡导弹 - 2025年
type: channel
link: https://www.nekopara.uk/2025/
description: GTX690战术核显卡导弹的猫窝
items: 2025年度回顾，2026未来展望
items: 断网自动重连！用Go实现广西大学校园网断网自动登录
items: 阿里云 ESA 回源 IP 段分享，可用于源站保护
items: 调用API实现Typecho博客VisitorLoggerPro插件IP信息更新
items: 解决PyTorch CUDA报错：no kernel image is available for execution on the device
items: V100 GPU 初体验：AlmaLinux 8.10 快速部署 ComfyUI
items: 用 Python 破解网易云 iframe 反爬，全自动构建本地音乐库
items: 自制二次元主题显卡：猫娘乐园巧克力 RTX 2080 Ti
items: 思考•锐评：手机——新时代的电子牢笼
items: 个性化Typecho VisitorLoggerPro插件，二次元浓度拉满！

2025年度回顾，2026未来展望
type: item
date: 2025-12-24T14:59:00+08:00
description: 时间好快，2025年转瞬即逝我感觉上一次写2024年度总结，好像还是前不久的事情，不得不说时间还是太快了。2025年发生了很多很多事情，也算是对我人生影响的关键一年，现在，在这一年即将结束之际，来回顾一下这一年的种种事情。接下来，请看我写流水账（）网站运营方面今年仍然保持了较高强度的更新，虽然我的更新态度是，没事就不更新，更新一般都是事件驱动的，但是因为喜欢各种折腾不知不觉就更新了不少文章。主要的文章还是围绕了解决各种遇到的技术问题，以及分享和记录一些自己感觉有意思的事情。我觉得整个写作过程还是比较有意思的，毕竟博客属于是个人是私人领地，你就是这里的主角。你可以自由的发表你的观点和看法，想骂就骂，想喷就喷，不用在意别人的看法。当然，难免会有人不爽你，不服的话就技术互撕咯，DDoS，CC攻击什么的，一般也都是脚本小子。撕完就又有写文章的素材了，多是一件美事（bushi）发布文章数量在发这篇总结之前，今年一共发了56篇文章（其实是57篇，有一篇因为某些原因隐藏了），算是很高产了平均每个月发4-5篇文章，已经遥遥领先绝大部分友链博客了。这其中，技术类文章的占比仍然是主流，毕竟我当时创立这个博客的想法，就是打算当作一个个人技术笔记来使用，并穿插一部分其他内容。网站被打次数小的攻击，上不了台面的，就算了，这里就统计对我网站造成实际影响的被攻击次数——7次！而且集中在今年下半年9-10月其中，DDoS攻击6次，最高攻击流量达到了惊人的79Gbps！被DDoS UDP流量狠狠灌注的感觉真是太爽了，特别是让对面发现使劲打了还打不死，更乐了。虽然云服务器被黑洞，但是仍然可以保证网站访问，我估计对面已经红温了。具体的配置方法，可以去看看这篇文章：绕过黑洞！利用VPC内网互通低成本实现DDoS攻击下网站高可用另外，在最后一次DDoS攻击之后，有一次大规模CC攻击，通过随机URL请求绕过了我的缓存策略，打在我服务器上拳拳到肉，直接把网站拖垮了。事后我也复盘了，搞了更优的限流防御策略，虽然仍然存在被打垮的可能，但是极大提高了攻击者的攻击代价。想看更详细的信息，可以看一下这篇文章：个人博客低成本CC防护：抵御85%+常见CC攻击就在这次CC后，我网站到目前为止，没有被打垮过了，也没再有过DDoS。在这里要感谢脚本小子的陪练。尝试开设新网站：猫娘答案屋因为之前觉得nekowork.org这个域名挺好的，就盘下来了，之前是作为个人信息聚合页面，感觉还是太浪费了，正巧我有路子可以获得一些网课答案，于是就想拿来搞一个用于分享大学网课答案的网站。但是看了一下搜索引擎的流量表现，好像确实不怎么样，基本上没什么权重，有点可惜。其实三月份的时候就尝试整理了几个网课的答案，然后发现太累太花时间，就没能坚持下来。所以中间断更了半年多，也没再怎么管过这个网站。然后最近手又痒痒了，想尝试一下自动化爬虫抓取答案，当作是爬虫练习去尝试。你别说，配合现在的大语言模型，写一些基础的代码还是相当轻松的，特别是当你有了程序实现逻辑的想法，直接让AI来帮你实现具体的代码就好了。经过几天的测试迭代，我也是成功写出了一套针对那个网课网站的自动化爬虫程序，可以实现自动获取章节作业的标题，随机选择答案，提交答案，保存题目和正确答案的过程，行云流水。但是这只是半自动爬虫，仍需要我手动进入课程，点开作业章节。不过，相对于手动提交答案后复制整理正确答案，速度确实快多了，而且不折磨人。如果网课作业量不算多，作业的章节10个左右的话，基本上一个网课10分钟能整理好，章节里面的题目越多，效率越高。我相信有这套工具加持，我应该是可以持续更新那个答案站的，只要我有时间有精力。白嫖华为云那些事2025年是华为云大撒币的最后一年了，大概10月份的时候，就是最后一次活动了。整个活动持续了大约一年，2024年9月开始有这类白嫖活动，高强度大撒币到2025年9月，后面就调整政策不撒了。有点可惜的是我8月份因为忙保研那些事情，没心思参加，缺席了一次活动，痛失1k代金券。估计后面华为云也不会再搞这类活动了，毕竟一次活动，一千多号人，一人一千这样发，虽然是云资源代金券，但是也是烧钱的。目前我的白嫖战果是：主服务器实例到 2035年6月1日过期 累计白嫖了十余年使用权（2024年9月20日-2035年6月1日）备用服务器实例到 2031年1月18日过期 累计白嫖五年多使用权（2025年9月28日-2031年1月18日）这两个服务器将是我未来网站运行的中流砥柱，关键力量，坚实根基，核心支撑，稳定基石，动力源泉，保障中坚，运转中枢，可靠依托，发展支柱，存续命脉，效能核心，运行保障，长远依托，根基所在，关键支撑，不可或缺，至关重要。它们既是网站平稳运行的固本之基，也是长远发展的赋能之要，更是持续服务的立命之本，为平台建设提供坚实保障，为功…

断网自动重连！用Go实现广西大学校园网断网自动登录
type: item
date: 2025-12-20T15:56:00+08:00
description: 广西大学校园网断网自动重连程序因为广西某211高校校园网有时候会不稳定波动，导致设备掉线。而如果在需要挂机进行一些工作的场合出现这个问题，将会相当蛋疼。再加上在宿舍每天晚上断网后，第二天都要手动重新登录着实有点麻烦，于是乎我就用我入门级中的入门级Go编程能力写了这个程序。程序实现登录方法查找因为学校推荐是使用浏览器打开认真网页进行登录，而经过抓包后，我发现相比于大一的时候，校园网的网页传输数据进行了加密。也就是，如果我要通过逆向网页JavaScript脚本获得登录请求发送逻辑，代价有点大。不过好在你西还是关照到了无GUI Linux服务器使用校园网的问题，在官网挂出了登录方法：linux系统宽带客户端-2024.12.30日后使用这就好办了嘛，只需要构造这个URL请求：http://172.17.0.2:801/eportal/portal/login?callback=dr1003&login_method=1&user_account=账号@cmcc&user_password=密码&wlan_user_ip=终端IP&wlan_user_ipv6=&wlan_user_mac=000000000000&wlan_ac_ip=&wlan_ac_name=&jsVersion=4.2.1&terminal_type=1&lang=zh-cn&v=5574&lang=zh发送给认证服务器就可以登录校园网了。不过我注意到了这个请求URL里面，MAC填写了000000000000，按理来说这部分应该填写设备的MAC，用于保持登录状态和后续无感知登录。这样填写无效的MAC后面大概率会因为校园网波动或者短暂断联掉登录，所以在我的程序逻辑上，这部分应该补上。现在需要发送的校园网认证信息就理清楚了：账号密码线路类型设备IP设备MAC我只需要写一个程序获取到以上信息，然后持续不断判断网络通断状态，当检测到断网后构造认证的URL并发送，就可以实现校园网断网自动重连了。用Go实现校园网自动登录其实之前我就用Python写过一版校园网自动登录程序，但是因为Python的效率和占用确实有点感人了，所以我觉得还是选择编译型语言来进行构建吧。好巧不巧之前学了一些Golang，要不就拿这个试试看？实现思路因为Go是编译型语言，登录的配置就不能像Python那样让用户打开源代码写在对应的变量里面了，得写一个配置文件机制。也就是首次运行创建一个文本的配置文件，然后用户填写了相关的信息，再运行程序，程序从配置文件读取信息并且执行校园网认证和断网自动重连工作。那这样看，实现思路就很清晰了：程序首次运行，输出配置文件模板，提示用户填写用户填写好后，读取配置文件并进行基础的校验，确保参数填写无误实现校园网登录认证的函数，网络通断检测函数，以及上网时段判断函数避免在非上网时段反复尝试重连对于配置文件的部分，我想采用类似ini配置文件的格式，这是模板：# 校园网登录脚本信息设置：（注意请不要改变格式） # 用户名：（填写示例：User=1807210721） User= # 密码：（填写示例：Password=www.nekopara.uk） Password= # 运营商选择，留空选择校园网，如果需要选择运营商，电信填写telecom，联通填写unicom，移动填写cmcc Net_Type= # 是否开启学生上网时段模式？1为开启，0为关闭，开启后周一到周五0:00-6:00将不会尝试重连 Student_Mode=0 # 开启路由器登录模式： # 如果填写以下两个参数（均非空），则使用指定的路由器IP和MAC进行认证。 # 否则使用本机IP和MAC。 # 示例： # Router_IP=172.16.6.6 # Router_MAC=36:88:8A:99:A4:CC Router_IP= Router_MAC=考虑到为了便于小白使用，我输出的是.txt文件，可以直接记事本打开。以及，添加一个命令行启动参数支持，可以让程序作为服务运行和部署，例如：./GXU_Net_AutoLogin -user 1807210721 -passwd mypassword -nettype telecom -studentmode -ip 172.16.6.6 -mac 36:88:8A:99:A4:CC现在技术架构想清楚了，开始编程吧！实现代码package main import ( "bufio" "fmt" "os" "strings" "net/http" "net" "net/url" "time" "io" "flag" ) const configFileName = "config.txt" // Config 结构体保存配置 type Config struc…

阿里云 ESA 回源 IP 段分享，可用于源站保护
type: item
date: 2025-12-18T17:04:00+08:00
description: 分享阿里云 ESA 回源 IP 段因为阿里云的源站防护功能，在免费版用不了，而我需要在源站设置访问白名单，于是就需要找一份阿里云 ESA 回源 IP 段列表。Cloudflare和EdgeOne都是公开回源IP段的，同样是属于CDN的ESA居然不公开，有点离谱，不过看样子应该是想作为增值服务，付费才能开源站保护（）好巧不巧，这段时间基础版ESA都可以免费领取一个月，而基础版ESA是可以开启源站保护的，所以自然也就拿到了回源的IP段列表。虽然文档说这是收敛后的IP段列表，但是得到的回源IP估摸着大概有1700+个，而且我和群友交叉验证过，得到的IP段是一模一样的。应该是收敛之前的完整IP段。估计可能的原因是我没有添加任何要加速的子域名，直接先开源站保护，导致返回了全量的IP段——这是好事啊！连统计和汇总都省了。（后记补充：打脸了，后面进一步测试后发现，免费版和基础版回源IP段是分开的，不用白费力气了）现在我就分享出来，给需要的站长参考。IP段可以用来设置源服务器的访问白名单，避免源服务器被扫描。具体如何使用，懂得人自然会懂，如果不知道的话，可以看一下这篇文章：绕过黑洞！利用VPC内网互通低成本实现DDoS攻击下网站高可用中的代理服务器安全组设置（可选）这一小节。请注意，文中获取到的IP段很有可能是有时效性的，不保证未来可用！获取的时间为2025年12月18日，如果时间过去的太久，需要使用请先验证！测试后补充：免费版和基础版回源IP段是分开的，所以想白嫖源站保护是不太可能的，后续也不要白费力气了。这篇文章就当作教训挂在这里了。全部 IPv4 回源 IP 段39.96.151.128/25 111.13.222.128/25 111.206.190.0/25 49.7.41.128/25 111.7.71.0/25 117.49.24.96/27 183.131.47.64/26 117.49.26.96/27 27.128.150.128/25 222.138.192.0/25 111.63.174.128/25 123.149.174.0/25 39.173.24.0/26 117.49.24.128/26 117.49.173.192/26 117.49.26.128/26 101.69.215.128/26 163.181.67.128/25 175.4.42.0/25 183.215.56.0/25 116.163.14.128/25 157.255.137.128/25 117.49.181.0/25 183.60.170.128/25 120.241.64.0/25 8.147.217.48/29 8.147.217.32/28 114.250.55.64/26 106.38.245.128/26 221.179.212.0/26 8.147.217.0/27 163.181.122.128/25 36.156.79.0/25 183.136.179.64/26 120.222.205.128/25 60.188.139.0/26 163.181.15.128/25 120.241.14.64/26 112.90.140.64/26 120.241.13.128/26 163.181.89.128/25 61.241.9.128/25 124.95.162.128/25 222.141.35.128/25 42.96.222.128/25 117.49.152.64/26 106.38.189.128/25 117.49.153.0/25 39.156.171.128/25 111.7.83.128/25 219.144.87.0/25 117.49.3.128/26 8.152.80.0/25 114.232.93.0/25 150.139.146.128/25 123.126.111.128/25 140.249.255.128/25 39.173.42.128/25 59.36.91.0/26 120.222.200.128/25 111.19.142.0/25 113.201.176.0/25 122.193.247.0/25 183.36.45.64/26 139.129.78.0/25 183.240.195.128/25 117.49.179.0/25 36.99.21.0/25 27.221.6.128/25 42.248.141.128/25 124.160.142.128/26 112.17.15.224/27 115.238.4.128/25 8.147.211.128/25 101.67.60.128/25 58.251.89.64/26 120.201.61.128/25 112.13.103…

调用API实现Typecho博客VisitorLoggerPro插件IP信息更新
type: item
date: 2025-12-17T23:30:06+08:00
description: 利用B站IP查询API更新访客记录IP地理信息偶然的一次机会，在群里面聊天的时候，群友指出纯真数据库的数据并不准确，并且说有一个可以免费调用的IP地理信息库——B站的IP查询API。据说还是用的ipip.net的企业版，这下得狠狠白嫖了。前置任务：修复VisitorLoggerPro插件BUG如果使用过这个插件一段时间，你就应该发现了，在国家统计图表这项，非常的混乱，似乎是只要记录的字符不一致，就会被当作不同的国家处理，例如美国加利福尼亚洛杉矶和美国纽约就被当作不同的国家列在上面。经过深挖代码斗智斗勇，我发现这个问题我无法从根本解决，因为整个代码太奇怪了，而且用的本地IP数据库也都是乱七八糟的，根本没有做好国家的细分地区分类，一股脑返回，导致所有的信息被集中在一起写进了国家字段。于是，我放弃治疗，直接在后面的调用代码中，增加分类逻辑进行分类：这是原来的代码，单独处理和提取了国内省份： foreach ($countryCountsResult as $row) { $countryName = $row['country'] ?: '未知'; $count = $row['count']; if (!isset($countryData[$countryName])) { $countryData[$countryName] = 0; $totalCountries++; } $countryData[$countryName] += $count; if (strpos($countryName, '中国') !== false) { foreach ($provinces as $province) { if (strpos($countryName, $province) !== false) { if (!isset($provinceData[$province])) { $provinceData[$province] = 0; } $provinceData[$province] += $count; break; } } } }我决定在返回国家信息的时候，进行提取合并并返回： foreach ($countryCountsResult as $row) { $rawCountry = $row['country'] ?? ''; $count = (int)($row['count'] ?? 0); if ($rawCountry === '') { $stdCountry = '未知'; } elseif (strpos($rawCountry, '中国') !== false) { // 所有含“中国”的都归为“中国” $stdCountry = '中国'; // 同时尝试提取省份 foreach ($provinces as $province) { if (strpos($rawCountry, $province) !== false) { if (!isset($provinceData[$province])) { $provinceData[$province] = 0; } $provinceData[$province] += $count; break; // 匹配到第一个即停止 } } } else { // 非中国：尝试匹配标准国家名（用于归一化，如“美国加州”→“美国”） $stdCountry = $rawCountry; // 默认保留原值 foreach ($countries as $country) { if (strpos($rawCountry, $country) !== false) { $stdCountry = $country; break; // 匹配到即停止（因列表已按长优先排序） } } } // 累计国家统计 if (!isset($countryData[$stdCountry])) { $countryData[$stdCountry] = 0; $totalCountries++; } $countryData[$stdCountry] += $count; }当然了，需要补上完整的国家地区列表： $countries = [ // 长名称国家（必须放前面） '波斯尼亚和黑塞哥维那', '赤道几内亚', '圣文森特和格林纳丁斯', '特立尼达和多巴哥', '圣多美和普林西比', '阿拉伯联合酋长国', '沙特阿拉伯', '巴布亚新几内亚', '所罗门群岛', '马绍尔群岛', '密克罗尼西亚联邦', '帕劳共和国', '瓦努阿图共和国', '基里巴斯共和国', '瑙鲁共和国', '图瓦卢', '美属萨摩亚', '英属维尔京群岛', '美属维尔京群…

解决PyTorch CUDA报错：no kernel image is available for execution on the device
type: item
date: 2025-12-06T20:22:00+08:00
description: 修复GTX 10系显卡no kernel image报错今天想试试看P104-100玩AI画图怎么样，结果遇到了PyTorch相关的报错，解决后感觉也挺有代表性的，写篇文章简单记录一下。问题复现尝试使用P104-100跑ComfyUI玩，结果收到了报错：torch.AcceleratorError: CUDA error: no kernel image is available for execution on the device Search for `cudaErrorNoKernelImageForDevice' in https://docs.nvidia.com/cuda/cuda-runtime-api/group__CUDART__TYPES.html for more information. CUDA kernel errors might be asynchronously reported at some other API call, so the stacktrace below might be incorrect. For debugging consider passing CUDA_LAUNCH_BLOCKING=1 Compile with `TORCH_USE_CUDA_DSA` to enable device-side assertions.我就觉得纳闷，为什么同样的驱动版本，都是580版本的驱动，V100不报错，但是P104-100报错了。然后我运行了检查GPU compute capability的代码，得到结果如下：print(torch.cuda.get_device_properties(0)) /home/rin/.local/lib/python3.12/site-packages/torch/cuda/__init__.py:283: UserWarning: Found GPU0 NVIDIA P104-100 which is of cuda capability 6.1. Minimum and Maximum cuda capability supported by this version of PyTorch is (7.0) - (12.0) warnings.warn( /home/rin/.local/lib/python3.12/site-packages/torch/cuda/__init__.py:304: UserWarning: Please install PyTorch with a following CUDA configurations: 12.6 following instructions at https://pytorch.org/get-started/locally/ warnings.warn(matched_cuda_warn.format(matched_arches)) /home/rin/.local/lib/python3.12/site-packages/torch/cuda/__init__.py:283: UserWarning: Found GPU1 NVIDIA P104-100 which is of cuda capability 6.1. Minimum and Maximum cuda capability supported by this version of PyTorch is (7.0) - (12.0) warnings.warn( /home/rin/.local/lib/python3.12/site-packages/torch/cuda/__init__.py:326: UserWarning: NVIDIA P104-100 with CUDA capability sm_61 is not compatible with the current PyTorch installation. The current PyTorch install supports CUDA capabilities sm_70 sm_75 sm_80 sm_86 sm_90 sm_100 sm_120. If you want to use the NVIDIA P104-100 GPU with PyTorch, please check the instructions at https://pytorch.org/get-started/locally/ warnings.warn( _CudaDeviceProperties(name='NVIDIA P104-100', m…

V100 GPU 初体验：AlmaLinux 8.10 快速部署 ComfyUI
type: item
date: 2025-12-05T23:21:00+08:00
description: 在 AlmaLinux 8.10 上部署 ComfyUI最近买了一张 V100，为了爽玩 AI 绘图，我单独组装了一台 X99 平台主机来运行 ComfyUI。操作系统方面，我选择了 AlmaLinux 8.10，看中的是其稳定性以及对多版本 Python 的良好支持。硬件介绍显卡本体Tesla V100 显卡展示（和RTX2080Ti同框）：安装到转接板上：转接板是200买的，虽然比最便宜的99元转接板贵了一倍，但用的是原装座子，原装座子的转接板就算是10X10CM的小板子都170+了。我加多30，买个带温控的，尺寸大一点的板，还自带螺栓孔位固定，完美安装，他不香吗？装上散热器后的样子：我为了尽可能降低温度，延长使用寿命，买了最大的散热器，到手发现确实巨大无比，比想象中的要大得多。但是其实现在看，买小一号的9CM高度的可能更合适，因为更好安装8CM风扇，不会浪费散热面积。我最后还是选择了8CM的风扇来散热，放弃了之前使用12CM风扇的想法——因为没办法彻底吹透散热器，温度还高。装上风扇Be Like:因为两边会漏风，导致无法彻底吹透散热器，所以搞了一张纸包了一下，迫使气流贯穿散热器。配套硬件平台开头我先说一下我踩到的坑，首先平台选择就先栽了一头：一开始我想用我闲置的H61平台来带这个玩意，而且也确认看过那个主板有Above 4G Decoding选项，也打开了，但是就是死活没办法驱动这个显卡，系统识别到了这个设备，但是NVIDIA驱动无法初始化设备，导致无法使用。这个问题折磨了我很久，检查日志具体表现是：[root@Neko-P104 ~]# dmesg | tail -100 | grep -i -E 'nvidia|nvrm|gpu|bar' [ 3.121900] NVRM: This PCI I/O region assigned to your NVIDIA device is invalid: NVRM: BAR4 is 0M @ 0x0 (PCI:0000:01:00.0) [ 3.121902] NVRM: This PCI I/O region assigned to your NVIDIA device is invalid: NVRM: BAR5 is 0M @ 0x0 (PCI:0000:01:00.0) [ 3.322080] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 580.105.08 Tue Apr 8 12:41:17 UTC 2025 [ 3.369648] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 580.105.08 Tue Apr 8 12:09:34 UTC 2025 [ 3.376189] [drm] [nvidia-drm] [GPU ID 0x00000100] Loading driver [ 3.376192] [drm] Initialized nvidia-drm 0.0.0 20160202 for 0000:01:00.0 on minor 0 [ 112.149308] caller _nv041720rm+0x3a/0xb0 [nvidia] mapping multiple BARs [ 112.163383] NVRM: GPU 0000:01:00.0: RmInitAdapter failed! (0x24:0x72:1568) [ 112.163415] NVRM: GPU 0000:01:00.0: rm_init_adapter failed, device minor number 0 [ 112.285687] nvidia-uvm: Loaded the UVM driver, major device number 237. [ 379.801748] caller _nv041720rm+0x3a/0xb0 [nvidia] mapping multiple BARs [ 379.815873] NVRM: GPU 0000:01:00.0: RmInitAdapter failed! (0x24:0x72:1568) [ 379.815912] NVRM: GPU 0000:01:00.0: rm_init_adapter failed, device minor number 0这表明：BAR 分配失败：GPU 的某些地址空间没有正确映射到系统内存中。RmInitAdapter 失败：驱动尝试初始化 GPU 时遇到了错误，无法完成初始化。所以这是平台限制，必须换平台了。后…

用 Python 破解网易云 iframe 反爬，全自动构建本地音乐库
type: item
date: 2025-11-23T17:21:00+08:00
description: Python实现网易云音乐自动抓取整理事情的缘起很简单，我的jellyfin音乐库听腻的差不多了，想抓点新歌。虽然说之前已经抓取过1000多首歌曲，但是很多是我因为强迫症，为了媒体库的完整性，把整个专辑都抓下来了，实际上常听的就是两三百首。正因如此，我就想给我的媒体库补充点库存，于是开始折腾，有了这篇文章。媒体库的具体搭建教程可以去看这篇文章：自建Jellyfin私人媒体服务器，告别屌毛网易云！实现思路上次因为没能自动化搞下载，且因为心急，所以几乎是半自动半手动收集的，费时费力，花费了差不多一个星期。而这次，我决定使用Python自动化完成，下面是工作流实现思路：当遇到喜欢的音乐后，我就保存其网易云的URL到文本文件，例如https://music.163.com/#/song?id=1499823984你可以点开看看是什么曲子（，每个曲子放一行，随听随收集。读取这个歌曲列表文件，逐行解析，获取专辑的ID，例如https://music.163.com/#/album?id=99010037，取出99010037，以及歌手KOTOKO。然后去解析专辑的页面，获取其中所有歌曲的song?id，例如1499823984，1499826814，1499823975和1499826811。调用第三方API进行歌曲解析，获取音频文件，歌词和封面。例如这次我用的就是https://jx.chksz.top/按照jellyfin要求的格式保存歌曲文件，也就是歌手/专辑/01.歌曲.flac，如：[chocola@Neko-Server KOTOKO]$ tree . └── ネコぱら vol.4 OP ⁄ ED ├── 01.SWEET×SWEET.flac ├── 01.SWEET×SWEET.lrc ├── 02.NEGAIGOTO.flac ├── 02.NEGAIGOTO.lrc ├── 03.SWEET×SWEET (Instrumental).flac ├── 03.SWEET×SWEET (Instrumental).lrc ├── 04.NEGAIGOTO (Instrumental).flac ├── 04.NEGAIGOTO (Instrumental).lrc └── cover.jpg最后还要打上艺术家，专辑，歌曲名的标签既然确定了思路和方法，接下来开始逐个攻破吧！观察网页布局打开音乐网页，开启F12大法，检查元素，迅速就定位到了目标：其实，后面发现在页面的meta标签其实也有信息：对于专辑部分，抓取列表就好了：看起来并不难，使用Python的requests模块获取html，然后解析内容就好了。尝试实现爬虫逻辑和LLM友好交流后，得出了每一部分的代码逻辑函数，例如解析歌曲页面信息的：def extract_music_info(url): # 模拟浏览器请求头 headers = { 'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36' } try: # 获取HTML内容 response = requests.get(url, headers=headers) response.raise_for_status() html = response.text print(html) # 提取艺术家（og:music:artist） artist_match = re.search(r'<meta property="og:music:artist" content="([^"]+)"', html) artist = artist_match.group(1) if artist_match else None # 提取专辑名称（og:music:album） album_name_match = re.search(r'<meta property="og:music:album" content="([^"]+)"', html) album_name = album_name_match.group(1) if album_name_match else None # 提取专辑ID（从music:album的URL中解析） album_url_match = re.search(r'<meta property="music:album" content="([^"]+)"', html) album_id = None if album_url_match: url_content = album_u…

自制二次元主题显卡：猫娘乐园巧克力 RTX 2080 Ti
type: item
date: 2025-11-18T22:39:00+08:00
description: 给显卡换上自己最爱的猫娘乐园巧克力主题说实话，这件事我老早就想做了——因为我的显卡是RTX 2080 Ti，正巧因为是涡轮卡，所以可以覆盖贴纸的面积很大。正巧咸鱼看到了便宜的背板——25包邮的映众RTX2080Ti背板：关键还是全新！于是，一拍即合，我拿下了背板，开始设计显卡皮肤。测量显卡尺寸背板到货后，我先用A3纸放在显卡背板下面，然后用针管笔描出背板的轮廓，并点出螺丝的孔位。然后再拆开显卡的导风罩（因为我是涡轮卡），将导风罩放在A3纸上面，固定好位置依次描边，描了三个面，描出了它的展开图。然后使用扫描仪进行扫描得出准确的设计参考轮廓图，扫描时设置的分辨率为300PPI。下面是扫描原稿：当然了，因为是用要贴贴纸的目标面按在纸上面描的，所以和贴纸的设计轮廓是完全相反的，所以要进行镜像处理，把描边的线稿翻转过来，才是正确的。寻找风格参考图因为我并没有设计过显卡皮肤贴纸，所以我决定从案例借鉴作为切入点，去找适合我的参考风格。在咸鱼高强度刷显卡个性化贴纸相关的页面，看了几十个案例后，有一个案例我觉得是可以参考和借鉴的，就是这个：为什么这么说呢，因为总体比较简单，画面不复杂，意味着我的设计的工作量会比较少。虽然我肯定是喜欢更华丽的画面，有一些别的显卡皮肤也非常的好看，我也想做出来，但是奈何技术水平和设计能力也就那样了，这种简单好看的设计对我来说更有可操作性——用简单的画面换取还不错的设计效果。解构这个设计稿，组成非常简单：角色立绘+配色色块+角色名字艺术字+作品LOGO所以，照着葫芦画瓢，我要做一个猫娘乐园巧克力主题的显卡，只需要搞到这几个要素，将其根据实际的设计尺寸组合起来，确保符合自己的审美和尺寸构图，让角色尽可能避开一些螺丝孔的位置，就可以了。开始设计我打算先从背板开始设计。背板贴纸设计万事开头难，这个设计工作一开始就犯难了——找不到特别合适的立绘图：因为猫娘乐园好看的同人图本来就很少，基本上要好看的只能解包游戏拿CG图，但是游戏的CG图始终是有限的，并没有多少。找来找去，我还是觉得用这张图比较合适：算是游戏CG里面很好看的一张图了，然后交给AI抠图，把角色扣出来：这样子，立绘就有了。本来我像在另一边把香草也放上的，但是放上后感觉构图混乱，也难以驾驭，最终还是践行了建筑大师路德维希·密斯·凡德罗的观点：“Less is more”——“少即是多”，只保留了巧克力，把香草去掉了（呜呜呜我的香草）。然而，接着往下设计，我发现这样子反而更好驾驭，因为就可以直接使用巧克力的主题色——粉色，然后使用整个粉色系装饰显卡：和参考的案例一样。调好缩放大小，只保留了角色上半身，避开螺丝孔后，得到了初步设计的方案：画面的粉色是直接从角色的衣服上提取的颜色，确保了整体的协调，有一说一，粉色配白色还挺搭配的。但是感觉画面空空的，好像少了点什么。然后继续观察参考图，发现是一些小细节元素没有没有，导致整个画面看起来很空，于是，我加上了系列名称的艺术字，再加上猫爪和星星等可爱风格元素，并且针对性的减淡调色，确保只是作为装饰，而不抢占视觉注意力。另外，我看到很多二次元风的排版都喜欢用角色立绘做成半透明减淡后叠在背景增强效果，我也试了一下，感觉这个方法还是挺好用的，这是最终的画面效果：就算是放当作背景的半透明减淡立绘，我也尽可能避免角色的脸落到螺丝孔的位置，不然看着自己喜欢的角色脸上被打个洞确实不爽。导风罩贴纸设计一开始其实我也想再弄一个立绘，但是翻遍了解包的CG图，似乎没有合适的了。正巧有一大堆Q版立绘，不如拿去试试。结果发现意外的合适，而且背板是角色立绘，正面散热器上是Q版立绘，也能形成差别和对比，效果还是不错的。再设计的时候，我特地把背板的设计稿放在对应位置的上面，确保能让整体设计协调，先设计个初版看看效果：细心的读者应该发现了，颜色分割线是延续了下来的，这就是我保证整体设计协调的手段之一。另外，粉色色块区域正好位于涡轮进风口，能削弱一下与内部黑色涡轮扇的颜色对比。后面考虑到粉色块太大可能有点单调，做了一下切分，最右边又露出来白色。最后像背板那样如法炮制，加上一点细节，导风罩的设计稿就完工了：哦，忘了说了，作为自由软件运动的拥护者，这个设计稿是使用GIMP制作的。如果你碰巧有顶部供电的涡轮卡RTX2080Ti，并且喜欢Chocola的话，我的设计稿你可以拿去直接用：RTX2080Ti_Dseign.7z解压密码是：www.nekopara.uk打印贴纸不得不说，这种小量打印订单是真的贵！问了一下群里面做广告相关行业的群友，他说最适合的材料是车贴，基本上耐受显卡六七十度的高温没什么问题。但是，问题来了，去淘宝定制车贴，居然一张A3大小的车贴要收我40块钱？！怎么不去抢？！而且找了四五个店铺，都差不多这个价……关键是，贵就算了，找了一家店铺，客服谈好后下单就没…

思考•锐评：手机——新时代的电子牢笼
type: item
date: 2025-11-16T14:05:38+08:00
description: 当手机“反客为主”：是工具，还是牢笼？文章开头先叠甲：文章仅代表个人观点，如果你有不同的思考也欢迎评论区讨论。近日听闻国内手机厂商计划进一步限制系统级 VPN 功能，不禁感慨：我们手中的智能手机，究竟是解放我们的工具，还是精心设计的牢笼？作为一个见证过开放互联网余晖和亲历过安卓手机开放时代的人，我想记录下对这一“日常必需品”的深层思考——你的手机，真的属于你吗？你的手机真的属于你吗？如果是普通不太了解手机技术细节的读者，或许看到这个标题会纳闷：我自己购买的手机，我自己使用，为什么不属于我？但是，很遗憾，对于绝大部分读者而言，你的手机就是不属于你。除非……你解锁了手机的Bootloader。Bootloader：手机的第0道枷锁首先，既然提到了Bootloader这个词，那就先解释一下这是什么东西：手机 Bootloader 是固化在 ROM 中的开机引导程序，开机后优先运行。核心功能是初始化手机硬件（如处理器、内存），验证系统完整性，随后引导操作系统启动。默认通常锁定，防止未授权修改；解锁后可刷机、安装第三方系统，但可能影响设备保修与安全性，是手机启动和系统定制的关键环节。正如介绍那样，默认Bootloader是锁定状态，也就是无法更改手机的操作系统。虽然手机厂商美名其曰提高系统安全性，防止未授权修改；但是，如果手机厂商做的手机操作系统本身就是一坨狗屎，那你也会因为这个锁定的Bootloader被套牢——无法自行更换其他的操作系统。这是正是手机厂商胆敢其在用户头上拉屎的一个重要原因，尤其是国内厂商，因为这坨屎你吃定了，除非你能解锁Bootloader，要么就换手机。而所谓的未授权修改，如果我是机主本人，希望修改呢？我的设备连修改的权利都没有了吗？对于相当一部分不支持用户解锁Bootloader的厂商而言，就是没有——例如华为。更加雪上加霜的是，近年来曾经允许用户自由解锁Bootloader进行折腾的手机厂商也在收紧——例如小米。当然了，如果是苹果用户，那就是地牢，没有任何硬件和操作系统层面的自由，基本上没办法解锁，甚至不能自己安装软件。这些Bootloader限制，完完全全就是厂商故意干的，因为原本的安卓系统，只需要在设置里面进入开发者选项打开OEM解锁选项，重启进fastboot，连接电脑后执行fastboot oem unlock就可以解锁手机的Bootloader并开始愉快的玩耍了。所谓什么未授权修改完全不成立，因为这是手机用户自己的行为，他们完全有对自己设备的处置权。而很多手机厂商，特别是国内手机厂商，把这个最基本的用户权利给剥夺了。他们打着保护用户数据和隐私，优化用户体验等名号，故意限制用户拥有设备的完整控制权，将用户圈养和绑死在自家煞费苦心搞出来的广告ROM里面使劲割韭菜，属实龌龊！题外话：有一说一，户晨风在贬低安卓吹捧苹果，说什么安卓人，苹果人，也不完全是空穴来风；因为对于普通不会折腾的用户而言，同样是绑死生态和系统，苹果手机的使用体验确实吊打了安卓几条街。但是，如果你真会折腾和优化安卓，那将爆杀苹果。ARM 生态：手机的第1道枷锁或许你会觉得，只要解锁了 Bootloader，就能像装电脑系统一样自由更换操作系统了吧？很遗憾，手机的硬件通用性一坨狗屎，这几乎是个奢望。 手机的硬件生态高度碎片化，系统专机专用——每个型号都必须刷对应的定制 ROM，稍有不慎就是黑砖。你根本没法像在 PC 上那样，想装什么系统就装什么系统，Windows，GNU/Linux，Unix，甚至MacOS，想换就换。 所以，就算你费尽千辛万苦解锁了 Bootloader，如果没有开发者为你这台设备专门适配系统包，你依然只能被迫继续吃厂商预制的狗屎 ROM。当然，既然都解锁了，root 是必须的——把那些藏在系统深处的云控组件、后台监控、性能限制统统扬了，体验才能好一大截。那么，为什么手机就不能像电脑一样通用？ 问题不在 ARM 架构本身，而在围绕 ARM 构建的整个封闭生态。 ARM 作为一种指令集架构，本质上只是定义了 CPU 如何执行指令，它本身并不阻止系统通用。真正的问题在于：手机厂商使用高度定制化的 SoC（系统级芯片），集成自家或供应商的基带、GPU、ISP、电源管理模块等；这些关键组件的驱动程序几乎全部闭源，且只提供给特定 Android 版本；没有统一的固件标准（比如 PC 上的 UEFI/ACPI），导致操作系统无法跨设备识别和调用硬件；厂商有意为之：一个机型一个 ROM，既能控制用户体验，又能制造“升级换代”的刚需。于是，明明是同一套 Android 底层，每家厂商、每款机型都要单独维护一套系统镜像，用户则被牢牢绑死在厂商的更新节奏和功能取舍上。这不是技术限制，这是人为制造的割裂。反观 x86 PC 生态，尽管也有驱动兼…

个性化Typecho VisitorLoggerPro插件，二次元浓度拉满！
type: item
date: 2025-11-04T20:08:00+08:00
description: 二次开发萌化VisitorLoggerPro插件其实之前我一直在用VisitorLoggerPro这个插件，但是由于之前的版本不够完善，也没想着进一步提升改造。前几天偶然翻了翻这个项目的GitHub仓库，发现基本上更新完善了，上一次更改已经是三个月之前，遂下了最新版回来尝试一下，发现功能非常满意。但是，美中不足的是，插件从jsdelivr.net下载相关的静态文件容易卡半天加载不出来。虽然插件写有智能回退使用网站的服务器进行加载，但是我发现它缺失了文件且返回路径不对，导致如果jsdelivr.net无法访问，页面会加载异常。于是，就萌生了修复这个插件的问题并且改造进行个性化的想法。打开了后台页面观摩了一下，并用浏览器的开发者工具随手调了一下CSS样式，最终明确了个性化的路径：设置一个全局背景图看板卡片进行半透明化于是说干就干，我先Fork了原项目，想了想要不就取名VisitorLoggerPro-Enhanced吧！然后开始了我的折腾和修改之旅。Github项目地址：VisitorLoggerPro-Enhanced可以去直接下载使用。修复静态文件回退到本地失败这肯定是最先需要解决的问题。如果不解决这个问题，该插件在我这里就处于不可用状态。补回缺失的本地文件这一步对于有网站搭建经验的人很简单，F12打开浏览器开发者工具，然后刷新页面观察网页都发送了那些外链请求，一下子就抓出来了：本地缺失的js：https://cdn.jsdelivr.net/npm/flatpickr本地缺失的css：https://cdn.jsdelivr.net/npm/flatpickr/dist/flatpickr.min.css其中，flatpickr抓取回来是没有后缀的，得加上个.js后缀变成flatpickr.js。然后对号入座，flatpickr.js放到js/目录，新建一个css/目录放置flatpickr.min.css。补回文件后的插件目录文件树应该是这样的：tree . ├── action │ └── visitor-stats.php ├── Action.php ├── adapter.php ├── css │ └── flatpickr.min.css ├── getTrendData.php ├── getVisitStatistic.php ├── ip2region │ └── src │ ├── ip2region.xdb │ └── XdbSearcher.php ├── ipdata │ └── src │ ├── ipdbv6.func.php │ ├── IpLocation.php │ ├── ipv6wry-country.db │ ├── ipv6wrys.db │ ├── qqwry.dat │ ├── qqwrye.dat │ └── zxipv6wry.db ├── js │ ├── echarts.min.js │ ├── flatpickr.js │ └── README.md ├── panel.php ├── Plugin.php ├── README.md ├── trend.php └── visitor-stats.php 8 directories, 23 files修复完善静态文件获取逻辑原本插件本地静态文件的相对链接写法是：localScript.src = './js/echarts.min.js';这会导致获取文件时发生404错误，因为在插件页面上下文中，该相对路径会被解析为https://www.nekopara.uk/admin/js/echarts.min.js，那包404的。正确的URL连接位置应该是https://www.nekopara.uk/usr/plugins/VisitorLoggerPro/js/echarts.min.js，所以，这个相对链接应该改成../usr/plugins/VisitorLoggerPro/js/echarts.min.js。而且，原插件仅实现了echarts.min.js的本地回退逻辑，未处理另外两个静态文件（flatpickr.js和flatpickr.min.css），因此即使修复了路径，还是会卡加载。还有一个致命的缺陷是，原本的回退本地源的逻辑是等待失败，但是一等就是大几十秒，非常影响体验。于是我就设置了超时时间，一旦第三方的静态文件加载时间超过2秒，立即回退到本地，避免长时间等待。以下是完善后的逻辑代码：对于panel.php内嵌js部分的修改，在原文件64行的地方开始修改： 对于visitor-stats.php内嵌js部分的修改，在原文件90行的地方开始修改： 对于trend.php内嵌js部分的修改，在原文件12…