从这里发布的

从知识解构、分镜脚本到最终成稿：一句话生成整篇科普漫画

Comment

　　AI 模型界的击鼓传花游戏速度实在太快，所谓世界最强模型，保质期可能还没家中冰箱里的牛奶长。不过11月20日刚刚发布的 Google Nano Banana Pro (Gemini 3 Pro Image Preview) 图像生成模型，确实抢走了一周前刚发布的 OpenAI GPT-5.1 甚至是自家 Gemini 3 Pro Preview 模型的风头，不仅被称作是文生图的“GPT-4“时刻，网友甚至喊出要满仓 Google 的股票。 　　也许你已经习惯了让模型生成可互动的 HTML 页面来快速预览一个新知识，但这个方式对于孩子们学习知识来说还是不够生动。今天在 Twitter 上看到高手用 Nano Banana Pro 生成知识学习的漫画，效果非常出色： https://x.com/goldengrape/status/1993393532418330784 。刚好最近儿子在看漫画七龙珠，前两天又问”地球为什么是圆的？”，于是拿着原文的 prompt 尝试了一下，效果很棒。只是其中知识点的讲解不太全面，我和 GPT-5.1 请教后对 prompt 稍作改进，让其对知识的解构更完善一些。 　　于是便有了这个悟空，布尔玛，龟仙人讲解 ”地球为什么是圆的？”短篇漫画——《七龙珠：突破天际的地理课——地球形状篇》（点此下载全文）。其中布尔玛的睿智和脾气火爆，悟空的天真，讲到引力时出现界王（界王拳和引力有关）都是恰到好处。 关键步骤 　　除了可以复用的 system prompt 外，用户只需做两件事情： 　　当然你也可以进一步将整个过程制作成全自动化的网页应用，或自动化平台中的工作流程。 　　上面输出的效果我是用 Gemini 3 Pro Preview + Nano Banana Pro (Gemini 3 Pro Image Preview) 完成的，现阶段其他图像生成模型可能暂时无法达到如此效果。类似的你还可以尝试： 免责声明 　　我知道这可能涉及版权问题，但这是AI技术演进中，模型厂商与知识产权方需要合作解决的深刻矛盾。我对原作者表示敬意，本文仅作为纯粹的技术探讨。 Prompt … Continue reading 从知识解构、分镜脚本到最终成稿：一句话生成整篇科普漫画 »

从这里发布的

在 NAS 上搭建自己的音乐流媒体服务

Comment

　　之所以选择在 NAS 上搭建自己的音乐库，不外乎下面几个原因： 　　而在积累了足够多的音乐专辑后，就会希望找到一种优雅，高效的方式来随时随地播放自己收集到的歌曲。具体来讲，需求是： 　　首先被排除的就是群晖（QNAP）自带的 Music Station，它的 web 端和移动端 app 在体验上都难以令人满意。除自带软件之外，提供音乐服务一般有两种方式：1. 专门的服务器端软件串流音乐文件 + 客户端播放；2. 将音乐文件当作普通文件，通过 SMB 或 WebDAV 等协议播放。因为需要外网访问，第二种方式对于体积比较大的无损音源来说不太友好。在尝试了一些软件组合后，找到了下面几个软件可以满足需求。 Navidrome 　　Navidrome 的简介是“开源的基于网页的音乐收藏服务器和流媒体服务。它让你可以在任何浏览器或移动设备上自由地听你的音乐收藏。它就像你的个人 Spotify！”，它既提供服务器端的音乐串流功能，也能当作 web 端的网页播放软件使用（也可通过 PWA 方式安装到移动设备上）。另外它支持 Subsonic 和 OpenSubsonic，所以有不少客户端可以直接使用。Docker compose 安装如下： 　　安装好后即可通过 http(s)://<ip>:4533 打开它的管理页面。但很快发现因为流媒体的设计理念，它无法通过传统的文件目录来浏览音乐，而只能通过歌曲的元数据（如专辑、艺术家等）来组织曲库。如果音乐文件的元数据不完整或不正确，整个曲库会混乱不堪。这时需要另一款能够补齐所有音乐元数据信息的软件。 Music Tag Web 　　Music Tag Web 是一款可以编辑歌曲的标题，专辑，艺术家，歌词，封面等信息的音乐标签编辑器程序（也就是“刮削”）， 支持FLAC, APE, WAV, AIFF, WV, TTA, MP3, M4A, OGG, MPC, OPUS, WMA, DSF, MP4等音频格式。最主要它可以直接在浏览器中整理 NAS 上的音乐文件，省去了通过 SMB 等协议挂载远程目录的繁琐步骤。 　　它的 docker compose 安装如下： 　　虽然操作逻辑需要熟悉一下，但提供的功能很方便，可以手动，自动，批量对音乐文件的元数据进行编辑。在此，也向该项目的作者表示感谢。 … Continue reading 在 NAS 上搭建自己的音乐流媒体服务 »

从这里发布的

Google Pixel 5 手机通过 Magisk unroot 时报错 Stock backup does not exist

Comment

　　之前用 Magisk 对 Pixel 5 进行过 root，是通过命令 fastboot flash boot /path/to/magisk_patched_[random_strings].img 刷入 Magisk 打过 patch 的 boot.img 文件进行的。目前刷新操作系统前，最好先去除 root 权限（unroot）。但在 Magisk 应用中，选择 Uninstall -> Restore image 时，报错 Stock backup does not exist! ，看来是之前备份的原始镜像文件找不到了。 　　解决办法：参考这篇帖子 Fix magisk stock backup does not exist ，通过 adb 运行下面的所有命令。之后就可以从 Magisk 中 Restore image，重启，系统即可恢复到没有 root 的状态。

从这里发布的

西安电信宽带开启IPv6通过Kodi观看IPTV

Comment

　　书接上篇《解决电视上KODI播放IPTV时无法识别IPV6地址的问题》，在西安家中电视上安装Kodi软件后，发现使用IPv6地址的电视台都无法观看，而IPv4的地址电视台正常，电脑上IINA软件测试也是如此，说明可能是家里宽带的问题。通过 https://test-ipv6.com/ 测试，发现果然没有IPv6网络地址。 　　家里是电信宽带，光猫桥接，小米路由器直接拨号。首先到路由器里查看，“IPv6网络设置”并没有开启，于是开启后设置为“Native模式”（适用于路由器拨号；如果是光猫拨号，需选择“NAT6模式”），重新拨号，但还是没有IPv6的连接，问题可能在电信宽带的局端设置上。 　　目前运营商都在推广IPv6，所以西安电信本身可能是支持的。于是抱着试试看的心态先尝试修改光猫的设置。家里的光猫管理页面如下： 　　按照光猫背后印刷的普通用户登入发现并没有相关设置，可能需要光猫的管理员权限登陆才行。在网上找到一些电信光猫的“破解”教程，还没用到浏览器开发者工具或隐藏登录页的方法，发现用下面默认的用户名密码从默认页面就可以直接登陆了： 中国电信：telecomadmin / nE7jA%5m中国联通：CUAdmin / CUAdmin 或 CUadmin中国移动：CMCCAdmin / aDm8H%MdA 或 CMCCAdminWoTf6&$7 　　管理员用户登录后，可以看到更多设置选项。只需在网络->网络设置->网络连接中，将IP模式从IPv4改成IPv4&IPv6，保存之后可以在光猫的网络侧信息中看到IPv6的信息。 　　然后小米路由器重新拨号，看到路由器已经获取到了IPv6的网络地址，测试IPv6连通性也可以通过，电脑/电视上观看IPTV，所有IPv6地址的电视台也可以正常工作了。

从这里发布的

解决电视上KODI播放IPTV时无法识别IPV6地址的问题

1 Comment

　　前一段时间《广电总局出手整治电视直播乱象，提升用户体验 》，提升的结果就是电视上一直在用了几年的“电视家”和“火星直播”两个看电视的软件，再也看不了电视了。家里办的宽带虽然附带有IPTV，但需要多一个盒子，多一个遥控，占用一个电视HDMI接口，更无法忍受的是必须连接光猫自带的WiFi热点，整个流程上的所有环节都极不优雅。 　　为了在电视上不用IPTV的盒子观看IPTV，可以在KODI软件里安装IPTV插件，搜索关键字“kodi iptv设置”。大致步骤如下： 　　这里推荐两个我自己测试了一段时间的源，感谢维护的作者。包含央视，所有卫视，和一些国外的频道节目： 　　但在电视上KODI播放时，发现了一个问题：有些节目可以正常播放，有些则不能播放，报错“一个或多个项目播放失败。更多相关信息见日志。”，类似 https://www.right.com.cn/forum/thread-8265882-1-1.html 。测试macOS的IINA软件中打开同样的.m3u文件，所有频道可正常播放。查看.m3u内容，发现无法播放的频道全部是IPV6的地址。电脑可以播放说明网络环境是支持IPV6的，问题在KODI软件里。最终搜索到了网友x3669的提供的解决办法（链接1，链接2：在IPV6的源上，手动添加80端口。比如： 　　保存成.m3u文件放到NAS上，KODI中读取修改后的.m3u文件所有频道即可正常播放。为了自动更新在线的播放源到本地文件，请ChatGPT写了一个bash脚本，在家里另一个Linux机器上crontab每30分钟运行一次即可：

从这里发布的

威联通 NAS 中使用 Nginx Proxy Manager 反向代理多个 docker 应用

Comment

　　前一阵在威联通 QNAP 的 NAS 中通过 docker 安装了 ChatGPT-Next-Web 这个项目，给朋友分享ChatGPT使用，但这个 web 项目本身不涉及SSL证书的配置，于是应用一直跑在未加密的 HTTP 协议下；加上之前的另一个 docker 媒体播放应用 Jellyfin，目前已经在路由器上设置了多个端口转发，需要通过记忆特定端口来打开对应的应用。有没有什么办法能同时解决这两个问题呢？显然 Nginx 来做反向代理再合适不过了。但这次跳过手写配置文件，我们使用 Nginx Proxy Manager 来达到目的。 目的 　　现状： 　　要实现的目的： 具体步骤 1. docker 安装 Nginx Proxy Manager 。我这里使用 docker compose 方式如下： 2. 通过 http://<nasIP>:9081 登陆 Nginx Proxy Mananger，SSL Certificates 页面给想要分配给应用的域名申请 SSL 证书。 3. 将你的域名 DNS 记录解析至家里 NAS 的 DDNS 地址。比如我在 CloudFlare 对应域名的 DNS 设置中，添加了两个子域名 chat.mydomain.com 和 jellyfin.mydomain.com，都通过 CNAME 记录指向我的 DDNS 地址 https://mydns.myqnapcloud.com 。之后通过这些域名和特定端口的请求会被运行的 Nginx Proxy Manager 接管。 4. Nginx … Continue reading 威联通 NAS 中使用 Nginx Proxy Manager 反向代理多个 docker 应用 »

从这里发布的

自动更新 AWS Lightsail 实例的公网 IP 地址并同步到 Cloudflare 的域名 DNS 记录

Comment

　　近几个月来科学上网的环境持续不稳定，即使方式从 v2ray 的 websocket+tls 换成了 xray 的 vless+xtls-rprx-direct 配置，印象中去年底开始，刚刚更新好的上网环境，包括自建和订阅，用一阵以后（几天时间不等）也会断流继而彻底失效。 　　经过观察发现，如果是自己搭建的环境，刚开始ping域名是可以返回背后的 IP 地址，但断流失效后，ping域名就没有响应了；此时 VPS 里的相关服务是持续稳定的，所以可能是 VPS 的 IP 地址被加入了“黑名单”。这时如果更换 VPS 的 IP 地址，并重新绑定到先前的域名，上网环境又重新可用，如此往复。这篇文章针对自建环境的情况，分享一种解决目前问题的方法。对于订阅的情况，只要更新一次订阅的服务器节点即可。 　　根据上面的思路，只需要定期自动更新 VPS 的外网 IP 地址，然后同步到自己域名的 DNS 解析记录即可。我目前使用的是 AWS Lightsail 和 Cloudflare，在 Linux 环境里解决问题的具体步骤如下。如果你使用其它服务商，需要查询一下相关的 API。 1. 安装和配置 AWS CLI 　　AWS Lightsail可以看作是廉价的EC2服务，因此其实例同样可以用AWS CLI来进行操作。安装只需要依次执行以下命令： 　　完成之后需要使用 aws configure 命令配置安全认证以便能够和你的 Lightsail 交互。这里需要提前创建好 IAM 用户和 access key。参考步骤和文章： 2. 用 AWS CLI 更新 Lightsail 实例的 IP 地址 　　在 Lightsail 控制台界面上操作时只需要删除掉目前的静态公网 … Continue reading 自动更新 AWS Lightsail 实例的公网 IP 地址并同步到 Cloudflare 的域名 DNS 记录 »

从这里发布的

OpenWrt中通过自定义脚本为Cloudflare域名更新DDNS

1 Comment

　　在上一篇文章中，威联通NAS上myQNAPcloud DDNS获取外网地址不准确的问题，提到使用myQNAPcloud服务来设置DDNS。这次尝试不依赖QNAP的服务，在OpenWrt里定时运行自定义脚本来直接更新域名的DNS地址。 　　我的域名托管在Cloudflare上，所以主要思路是定时在OpenWrt里运行脚本检测公网IP地址是否有变化，如果有就用Cloudflare的token和API来更新相关DNS设置。 　　记录具体步骤如下： 　　其实同样的工作也可以在OpenWrt的web管理页面上完成，如果你可以在“服务->动态DNS->DDNS 服务提供商 [IPv4]”的设置中找到Cloudflare选项的话。我用的OpenWrt编译了动态DNS的应用（luci-app-ddns， ddns-scripts），但没有Cloudflare的入口点。尝试安装ddns-scripts-cloudflare或更早的ddns-scripts_cloudflare.com-v4_2.7.8-3_all.zip，不仅依然找不到Cloudflare入口点，还有可能破坏掉OpenWrt：实际后台依然运行，可以上网，但web页面（LuCI web interface）报错Bad Gateway The process did not produce any response.，只能借助ESXI里的快照恢复或重新安装OpenWrt。所以才有了这篇博客。

从这里发布的

威联通NAS上myQNAPcloud DDNS获取外网地址不准确的问题

1 Comment

　　威联通（QNAP）NAS上自带的myQNAPcloud服务可以识别到NAS所在网络的外网地址，从而和你注册的QNAP域名（*.myqnapcloud.com）绑定，方便从外网通过该域名访问NAS服务。 　　问题：最近发现家里的两台NAS中，一台的myQNAPcloud服务可以识别正确外网地址，而另一台NAS识别出的外网地址不对，实际上是软路由里科学上网的代理地址。猜测有问题的这个NAS不知为什么通过代理访问了myQNAPcloud的服务器。 　　解决办法：在软路由的代理设置中，将访问myQNAPcloud服务器的地址 edge.api.myqnapcloud.com 设置成不走代理即可。 参考文章：

从这里发布的

关于给黑洞拍照背后的故事

Comment

　　黑洞——人类当前认知中最神秘的宇宙天体。100多年前爱因斯坦的广义相对论就预测到它的存在，但直到2019年4月人类才获得了第一张黑洞照片。能够给黑洞拍照无疑是解锁了人类科技树上的新技能，如果你也和我一样好奇的话，本文就和大家分享一些给黑洞拍照背后的故事。 1. 当我们给黑洞拍照时，我们在拍什么？ 　　黑洞本身并不发光，也不会向外发出任何电磁辐射（除了还未被证实的霍金辐射），即使以宇宙中最快的光速运动也无法逃脱它的引力束缚。那对着它拍照岂不是什么也看不到？黑洞照片上那朦胧的橘色轮廓又是什么？要想知道给黑洞拍照的真相，我们先回顾一下黑洞的结构。 　　根据上面这张欧洲南方天文台（The European Southern Observatory，简称ESO）给出的假想图可以看出，一个典型黑洞是由奇点，事件视界，光子球，相对论性喷流，最内侧稳定轨道，吸积盘等组成。简单来说，黑洞有两个最基本的部分。第一个是奇点（singularity），即黑洞的中心点，也是落入黑洞物质命运的终点。这是一个体积无限小，密度无限大的引力异常点，此处的空间和时间已经被扭曲到所有的已知物理定律，包括预言它存在的广义相对论都不再适用；第二个是事件视界（event horizon），可以把它理解成一个无形的边界，在这个边界上逃逸速度正好等于宇宙中最快的光速，所以一旦进入这个边界内部，就再也无法逃出黑洞。在万有引力常数不变的情况下，逃逸速度只和物体的质量还有半径（体积）有关。地球的逃逸速度即第二宇宙速度是11.2千米/秒。如果把地球压缩到半径9毫米以下的体积，那么它的逃逸速度就会大于光速，也就变成了一个黑洞。这个临界值可以简单理解为是任何物体自身的事件视界到奇点的距离即史瓦西半径，如果把一个物体压缩成球体的话，只要半径小于史瓦西半径，它就可以变成一个黑洞。太阳的史瓦西半径是3千米，一个人的史瓦西半径大概是10-26米（比电子还要小一亿倍）。 　　黑洞在“吞噬”其周围物质时会形成高速旋转的吸积盘（accretion disc）。它是黑洞周围的气体或尘埃受到黑洞引力影响跟着一起旋转，当其角动量足够大即旋转足够快时，在一些特定的位置，产生的离心力能够和黑洞的引力相抗衡，从而形成的一种盘状结构。吸积盘内的气体因为高速旋转会产生超高温，从而向外辐射大量能量，也就是人类观察到黑洞发出的电磁波的主要来源。当黑洞吸积物质过快时，吸积盘的磁场会沿着黑洞自转方向扭曲，一些粒子就会以极高的动量（甚至接近光速）喷射出去，形成相对论性喷流（relativistic jets）。 　　因此，给黑洞拍照主要是在不可见光波段，观测黑洞的吸积盘及喷流产生的电磁辐射。 2. 人类迄今为止拍摄到唯二的黑洞照片 　　截至目前，人类只拍到过两张黑洞照片，都是由事件视界望远镜（Event Horizon Telescope，简称EHT）组织拍摄、整理、发布。EHT成立于2009年，专门以观测拍摄黑洞为使命，目前由超过20个国家和地区，60个科研机构的300多名科学家组成。 　　这两张照片分别是2019年4月10日发布的Messier 87（室女A）星系中心超大质量黑洞（简称M87*）照片，以及2022年5月12日发布的我们银河系中心人马座A（Sagittarius A）方向的超大质量黑洞（简称Sgr A*或银心黑洞）照片。这里的星号借鉴了原子物理中激发态（excited state）的概念，表示该天体处于非常活跃的状态。 　　两图中心黑色阴影部分并不是事件视界的范围，而是大约黑洞史瓦西半径的2.6倍大小，橘色亮斑代表吸积盘上的气体向着接近我们的方向旋转，暗部则反之（多普勒效应）。至于为什么银心黑洞上有三个亮斑，目前还未能确认其产生原因。 　　下面是这两个黑洞的一些基本情况：   M87* Sgr A* 银心黑洞 质量（与太阳相比） 65 亿 倍 410 万 倍 与地球的距离 5300 万 光年 26600 光年 　　再看看两个黑洞的大小。下图中右侧中心的小白点是太阳，银心黑洞外围（吸积盘）的面积，与水星轨道面积相当；左侧是M87*，图中白色小圆圈是冥王星的轨道面积，白色小点是1977年发射的旅行者1号，目前距离地球最远的人造探测器的位置。 　　如果上面的表格中数字太大或黑洞体积还是不直观的话，我们把太阳放大看看可能会容易理解一些。 　　实际上这两张黑洞照片的“拍摄”时间都是在2017年4月，持续近10天。第一张M87*照片在两年后公布，第二张银心黑洞的照片又等了3年才公布。 3. 给黑洞拍照很难吗？ 　　现在你可能会问，这两个黑洞那么大，怎么还拍得这么不清楚？和《星际穿越》里黑洞的样子相比怎么这么难看？给它们拍照片很难吗？答案是：难，非常难。可谓是拍照10天，修图5年（银心黑洞）。 挑战一：角分辨率 　　从距离上来说，M87*黑洞虽然距地球比银心黑洞远2000倍，但却比后者要大1000倍。所以从地球望去，视觉效果上两者是差不多大小的。加之一个是我们已知的最大黑洞之一，一个是我们自己星系中心的黑洞，因此EHT选择它俩作为观测目标。它们在天空占据多大的位置（角分辨率）呢？答案是52微角秒（1微角秒=1″ / 1000 / 1000 ），相当从地球观察月球表面一个甜甜圈????。经计算，望远镜的尺寸需要和地球一样大，才可以达到如此的拍摄分辨率。 挑战二：超大数据量 　　对黑洞的观测每天每个观测点产生的数据量可达350TB，科学家们需要足够的耐心和时间来处理这些数据。 银心黑洞附加题一：尘埃带遮挡 　　由于太阳系位于银河系的盘面上，向银河系中心望去时，存在很多遮挡物，这是由星际尘埃和气体组成的尘埃带，使得银心处的可见光，紫外线和部分X射线都无法到达地球。尘埃带一般常见于漩涡星系或棒旋星系（比如银河系）。而M87星系是椭圆星系，完全不受银河系尘埃带遮挡，加上观测路线上也比较通透，所以后期数据处理要容易很多。 银心黑洞附加题二：延时摄影 　　虽然两个黑洞的吸积盘旋转都非常快速（甚至接近光速），但因为M87*体积足够大，因此吸积盘旋转一圈需要数天时间，而银心黑洞吸积盘旋转一圈的时间只需要数分钟。这就导致给银心黑洞拍照类似延时摄影，或在光线不好的地方给一条欢乐的小狗拍照，很难得到一张清楚的照片。 4. 如何给黑洞拍照？ 　　好在人类拥有足够的好奇心和智慧的科学家们。在EHT … Continue reading 关于给黑洞拍照背后的故事 »