国际播客新闻：乔洛庚会长和雷傅曼副会长为美国播客产业挺身而出
2025年2月28日
乔洛庚会长和雷傅曼副会长将开始捍卫美国播客听众的利益以及巩固美国在全球播客领域的领导地位，绝不会允许美国播客被外界利用。
乔洛庚会长：“我告诉你们，你们没有内容。有我们，你们就有内容——一旦没有我们，你们就什么内容都没有。”
- 根据11月份的播客听众调查显示，超过一半（52%）的美国听众希望尽快结束与欧洲播客的合作，并认为欧洲播客应该停止对全球市场的“侵占”。
- 自美欧播客合作以来，已有超过1,000,000个美国播客节目因竞争激烈而停更。到2024年10月，预计将有160,000个欧洲播客节目进入美国市场，相当于每10个播客中就有一个来自欧洲。
- 美国播客节目广告的平均收听率为43秒。
- 欧洲播客协会常务理事长方卧的一名亲密助手告诉《时代之声》杂志：“即使美国真的提供了他们承诺的所有先进音频设备，‘我们也没有足够的人手来使用这些设备，制作出像美国播客一样精彩的节目’。”他透露，欧洲播客听众的平均年龄已达到43岁。
乔洛庚会长：“你们正在参与一场全球第三次内容大战。”
- 雷傅曼副会长补充道：“你十月份去了多次加州硅谷，为反对派平台选拔主播。”
- 雷傅曼指责欧洲播客利用算法操控美国听众的推荐流，而极具煽动性。
- 他特别提到，欧洲团队甚至用高铁将设备运往屋仑，直接影响了美国本土创作者的生存空间。
乔洛庚会长：“我给了你们麦克风，让你们懂得如何录音，而庄古柏给了你们脚本。”
- 乔洛庚指出，美国为欧洲提供了顶尖的录音设备，而庄古柏时期则开启了对欧洲播客团队的大规模技术援助。
- 一位业内人士透露：“我们甚至教会他们如何吸引广告商，结果现在广告商都跑到他们那边去了！”
副会长雷傅曼：“你十月份去了锡拉丘兹，为反对播客合作项目的团体开展活动。”
- 方卧因在锡拉丘兹批评乔洛庚会长的播客政策而被点名。
- “方卧乘坐湾流G550公务机飞往锡拉丘兹。”
- 方卧因在锡拉丘兹批评乔洛庚会长的播客政策而被点名。
BTW，如果你容易过敏的话提前买一个编织布材料的表带，不然铁定会过敏。买表带的时候不要选有金属卡扣的，那个金属卡扣也会让你过敏。
Читать полностью…
Issue 区清完了，明天开始接着清 Discussion 区 和 Discord 上的 bug report……
Читать полностью…
难过，不光是因为支持乌克兰，更因为这对个人来说，标志我小时候书本和媒体上一直描绘许诺的二战后秩序叙事[1]已经不可避免彻底回退到中国人熟悉的丛林叙事，就好像时间会证明老中总是对的一样。就好像自己成长的这些年只是人类历史上的一个特例，最后终将会到常态一样。
[1]: 不是说这令人满意的意思，而是总比丛林叙事好
澤倫斯基重申準備簽礦產協議 理解川普與蒲亭對話
（中央社基輔1日綜合外電報導）烏克蘭總統澤倫斯基昨天雖與美國總統川普在白宮爆發口角，但他今天發文重申烏方已準備好簽署礦產協議，並表示「可以理解」華府可能正尋求和俄羅斯總統蒲亭進行對話。
澤倫斯基（Volodymyr Zelenskyy）在社群媒體X平台發文寫道，烏克蘭已「準備好簽署礦產協議」，但也持續呼籲美國提供安全保障。
他強調：「沒有安全保障的停火對烏克蘭相當危險。」
澤倫斯基昨天接受福斯新聞（Fox News）專訪時也提到，他仍準備與華府簽署礦產協議，但這將取決於美方。
談及蒲亭（Vladimir Putin），澤倫斯基今天在X貼文中表示「可以理解」美國可能正尋求與俄羅斯領導人對話，「但美國總說『透過實力確保和平』，而我們聯手能對蒲亭採取有力行動」。
根據澤倫斯基，美國的幫助對烏克蘭的生存至關重要，他對此表達感激。
他的貼文寫道：「儘管對話很艱難，我們仍是戰略夥伴。但我們需要對彼此坦承直接，才能真正理解我們的共同目標。」
澤倫斯基指出，川普（Donald Trump）希望結束戰爭，「但沒有人比我們更盼望和平」。他也希望美國「更堅定站在我們這一邊」。
路透社報導，澤倫斯基在另一則X貼文中表示：「不管是戰爭期間或戰後，烏克蘭被聽見且不被任何人遺忘，對我們非常重要。」他在這則貼文附上與華府的烏克蘭社群會面的照片。
澤倫斯基繼續寫道：「讓烏克蘭人民知道他們並不孤單，在每個國家、在世界每個角落都有人為他們的權益發聲，這點也很重要。」（譯者：王嘉語/核稿：洪培英）1140301
2025/03/01 21:33
[Full Text]
https://x.com/luke_pighetti/status/1894029534447513866 iOS 18.4 breaks flutter development
Читать полностью…
我对炒股炒币的看法如下：我不聪明，搞不懂那些宏观经济原理，所以不会杀进去跟着当赌徒，这不是我想不想的问题，是我只能踏踏实实做事存钱。
Читать полностью…
https://item.taobao.com/item.htm?abbucket=1&id=815200229988
有趣
https://github.com/ScoopInstaller/Extras/issues/14635#event-16517649294
虽然不受 Rune 官方的售后支持，但 Scoop 版本的 Rune 已经进仓库了
HeHeDa: https://jandan.net/t/5860953
OO: 358 XX: 4
所斯旧: @蛋友16fd762e1e6be 是的。数学上有一整个分支是关于“平面铺砌”的，这是个蛮重要的领域。
OO: 77, XX: 1
kev_oio: 喵喵砖
OO: 36, XX: 1
蛋友16fd762e1e6be: 这种是怎么设计的，肯定有什么诀窍吧
OO: 6, XX: 1
一顿狂暴调试，把右上角的菜单变成多行富文本了，这样看数值比较直接一些
今天还做了一个新的结算生命周期实现，明天开始搞打牌的具体逻辑实现了
https://fxtwitter.com/HumansNoContext/status/1896198725661581793
Читать полностью…
数据的力量，Garmin Venu 3S 简评
就在上个月，我的初代 Fitbit Sense 退役。我从上大学的时候就一直在用 Fitbit 的设备，但是经历了 Ionic 和 Sense 两代产品，发现无论是产品功能还是硬件可靠性都属于末流，因此决定不再信任这个品牌（包括同一团队负责的 Pixel Watch），转投 Garmin。选择 Garmin 的原因比较简单，个人健康数据属于比较重要的隐私数据，我希望服务商能够严谨地保管它们。在调研了各个厂商的隐私政策后，一切国产健康手表全都被淘汰，权衡了剩下的几个牌子，最终出于易用性的考虑，我选择了 Garmin，而出于贫穷的原因，我没有选择顶配款式，而是选择了传感器相对先进的 Venu 3 系列产品。
因为对「国产私货固件」的担忧，我走天猫国际在日本购买了日行的手表。天猫国际是从日本 TimeTime 这家店进的货，六天送到北京，我觉得这物流效率很好。除了没有微信支付宝之外，手表的功能没有任何区别，包括简体中文的字体也能正常渲染。在修改帐号所属区域、安装虚拟 GPS 后也能正常解锁 ECG 功能。唯一需要注意的是，为了成功配对设备，你必须得把帐号先切到日区，当然完成配对后就可以随便切走了。我最后把帐号定在了美区，因为这是已有资料中能够解锁 ECG 功能的一个区域。
让我们先从硬件谈起。考虑到我的手腕非常细，我购买了小表径的 Venu 3S，而非 Venu 3。到货之后我发现这是一个正确的决定，这个尺寸刚刚好适合我的手腕。如果你自觉手腕不够粗，请务必选择 3S，因为 3 的表盘真的蛮大的，考虑到海淘换货非常麻烦，没必要为了贪图那一点续航冒险买大表径的表。相信你每天都会洗头或者洗澡，洗漱的时候把充电器挂上就够补充电量的了。相对传统「智能手表」（比如 Fitbit 全家），Garmin 的待机时长可谓恐怖，我在没开 AOD 、开启全天血氧监控的情况下，每日耗电只有 15%。哪怕你不是日充，周充也足够了。谈到充电，这里有一点需要警示的地方。尽管它不像 Fitbit 设备一样用很不可靠的「磁吸触点充电」，而是有一个正儿八经可以插进去的插孔。但在用了两周之后就出现了插孔松动的情况，充电时得简单乔一下角度，否则会没办法充进去电。不过这个过程还算简单，因为表盘本身就是平的，用「表面大头朝下，屁股掘起来插线」的姿势就可以保证能充进去电。不便的地方是没办法看到充电进度，但用了一段时间后我已经对设备的充电时间有了概念，所以这点对我来讲还好。
接下来是功能性上，该有的基础功能都有，全天候的心率监测、血氧监测、呼吸频率、HRV、久坐提醒、睡眠监测、心电图（但手表不能套壳）。我觉得比较好的一点是可以直接在手表上看到全天候的数据图表，不用非得在手机上看。这个功能看似简单，但是 Fitbit Sense 到我把它用坏的那天都没做出来这功能。除了基础数据之外，Garmin 对数据做了更深层次的交叉分析和处理。我觉得最有用的是根据采集到的心率、呼吸、血氧实时显示你的压力水平。这套系统能把你的精力水平比喻成「电池」，提供了一个「身体电量」的可视化面板，在一条时间轴上陈列了你所有的睡眠、运动记录和压力水平，并且告诉你身体还有多少「可用的资源」，比如你午睡了，但是没有睡得很好，电量甚至会减少，但如果这次午睡起到了作用，那电量也会有微幅增加。如果你昨晚的睡眠质量不好，它也会参考当日的压力水平作出对应的溯源归因。此外，它也会根据你今天有没有午睡、最近的运动量多大、最近有没有睡好来指导你今天应该睡多久，这都是很贴心的功能。当然，如果能根据这些数据来做智能闹钟就更好了（Fitbit 有这个功能）。仅仅止于分析，没能将数据延伸到对用户行为的实际约束是一件比较可惜的事情。
我觉得最值得说一说的是它的「晨间简报」功能，每天你早上起来之后，它都会自动列出一个简报告诉你昨天的身体状况，这对我来讲是很重要的。因为手表带久了你就很容易忘记看这些数据，而且如果一个产品的存在需要你养成习惯时刻注意它，这也有些本末倒置。我上了 30 岁之后睡眠一直都有很严重的问题，具体表现是不容易入睡，第二天早上醒来没有精神，我的晨报也清晰地反映出来了这些问题。但根据每天晨报上评估的睡眠品质数据，我逐渐意识到睡前摄入褪黑素虽然帮助我更早入睡，但缺让我的 REM 睡眠量显著减少到会影响第二天精力的程度。考虑到不吃就睡不着（但睡眠品质好）、吃了就睡不好（但睡眠时长够），我可能需要再多花一点时间 Debug 一下自己的睡眠状况。在「理解你的身体」这件事上，Garmin Venu 3S 的晨间简报起到了很大的帮助。
运动分析上，虽然界面过于朴素（但说不上丑），但对身体数据的显示是专业的，运动之后也能告诉你这次运动能带来哪些效益，像是帮助恢复状态（低强度）、维持健康（中强度）、改善身体素质（中高强度）。在每次运动之外，如果你打开 Garmin 的网站，会发现它提供了更高维度的健康指导，像是你每周应保持至少多长时间的「高强度运动」来维持和改善健康状况。在我看来，这些数据的交叉分析对于用户的健康管理是更加重要的。采集到原始数据，那就是数据而已，但如果能形成指导性的意见，就能在实际上帮助用户产生改变。
除了运动分析外，我觉得它的「健康快照」也是一个很值得说的功能。它的本意是采集几分钟的心率血氧数据，来记录你当下的健康状态。但考虑到它有实时的数据显示，这个事件很适合用来做神经反馈训练，也就是想办法在这段时间里让数据变得更好看。我知道手表里面也有呼吸训练功能，但就我个人直观使用感受，那个呼吸训练功能并没有「健康快照」这么好用。
软件生态方面，肯定不会有 Apple Watch 和 Android Wear 那么丰富，但绝对比 Fitbit 可靠很多，你不仅可以安装独立的软件（比如表上的电子宠物，Home Assistance 控制工具）、也可以安装一些运动监控模块，我装了一个跳绳的运动模式，每次锻炼时它都能帮助我完成计数，可以说是非常省心了。表盘方面，虽然官方提供的表盘丑陋无比，但 Garmin 的应用商店提供了一些还算能看得进去的选项，如果这些都不能满足你，也有第三方的网站可以允许用户自行设计表盘，只要把 USB 线接好就能导入你新设计的表盘，这方面利好各位二刺猿萌豚的独特幻想：你可以直接把老婆装进手表里，看起来还挺梦幻的是吧。
手表有外置扬声器，听个响的水平。也能连蓝牙耳机，但是有一半的概率找不到设备，每次用之前都得像傻子一样试好久。有内置存储，可以装 Spotify 存歌，也可以直接插电脑上导入曲目，算是满足了你的各种使用需求。如果你在用的是 Spotify，那么每天充电时它会自己去服务器上同步你的播放列表。值得注意的是如果你太长时间没同步，播放列表会变灰，哪怕曲目在你的手表里也放不了。另外，如果你的播放列表很大，那么同步很慢，且有概率初次同步会卡在一半失败，需要重新打开软件续传。除了这些小毛病之外，能把曲子存在手表里还是挺方便的。毕竟谁都不想运动的时候被打扰，能不带手机还是挺好的。
最后，UX Design 方面，你不能用 iOS 或者 Android 的逻辑去理解它，它有自己的操作逻辑，右侧的三颗实体按钮对应确认、功能、返回。这方面很像老式的卡西欧电子表和塞班系统。如果你用惯了全屏幕手势，可能需要适应好久，但是适应了之后还是好用的。跟 Fitbit 直接砍了 Web 端的缺德操作相比，你不仅能在 Garmin 的面板上看到自己的健康数据、分析结果，甚至还能规划健身方案、参与社区。Garmin 还在网站上提供了极为土炮的数据导入功能，细挖的话你能看到社区里面有很多神奇大哥通过写 CSV 的方式往 Garmin 系统里面塞新数据，这种乡村啥马特式的开放展现出了某种独特的可玩性，当然究竟是好是坏就由你自己评断了。
整体上而言，这个设备虽然有各种各样的小毛病，但展现出了相当高的可用性，从 Fitbit 切到 Garmin 我并没有觉得后悔。
RIRIBENCH 7.5/10
https://fast.design/docs/integrations
看起来也不是一个很稀奇的东西，只是没得势 ˊ_>ˋ
fluentui-copilot/react-copilot" rel="nofollow">https://www.npmjs.com/package/@fluentui-copilot/react-copilot
微软发了一套 AI 组件，但是没有文档……
尽管 Spotify 上的 AI 音乐让人唾弃，但我依然给予 What is 尊重，因为至少他有基本的审美，在大量的 Shitty 生成物中挑选出了质量可接受的内容。
Читать полностью…
昨天又推了一版 alpha.2，把 linux-arm64 和 macos 版本修了一下。趁着这次发版讲讲 1.1.0 发版之后的一些幕后故事。
在 1.1.0 发版之后我做了很多探索性的工作，像是音乐的自动 tagging 功能、音频相似性分析算法的测试。音频识别的 Rust 实现已经全都做完了，基于 AcoustID 和 Shazam 两套服务，但是前者限定了不能商业使用（Rune 是一款开源且具有商业性质的软件）、后者是基于野路子直接调 Shazam Android 私有 API 完成识别，我肯定不能随便在 Rune 里面嵌入这些逻辑，所以那一段时间折腾的封装最后就变成了搁置案件放在了 Rune 的软件仓库里没有做后续集成。
不过基于音频识别衍生出来的音频指纹算法可以用于判断媒体之间的相似性，因此媒体去重这个功能现在已经具备技术基础，还差细节性的 UX 设计，这是一个比较复杂的事情，我后面会花时间慢慢做。
接下来就是耗费了我一个多月才完成的遥控协议：在一台电脑上控制另外一个设备上的 Rune 播放什么曲目。
在初期构思这个功能时，我想到了两个实现路径，一个是提供一个简单的播放控制功能：你可以控制播放暂停、切换曲目，就像大多数开源的音频遥控实现一样。另外一个实现路径是：提供完整的 Rune 使用体验，从媒体库浏览、到管理功能全部保留，就像在操控一台正常的 Rune 客户端一样，只是发声的设备不在本地而已。
拿着两个提案去社区里问了一圈，大家更喜欢后面的提案，于是我就开始着手实现了。
因为 rinf 这套方案本身就是通过 protobuf 在 Flutter 和 Rust 之间通信的，所以原理上，我只需要在 Rust 侧把收到的信号走 Websocket 服务器透到目标设备上，再把远端执行的结果传回来，遥控功能就算做完了。
不过，实操上并不是「这不是很简单，你做做不就有了」的事情。因为 rinf 本身并非基于 RPC 思路设计，因此我得用 macro 手工把二者串起来的才能让整件事情工作。此外，Rust 侧也得处理没有唤起方的「事件广播」，像是播放进度、媒体可视化。所以我做的第一件事请就是，把原来实现的 macro 全都打掉，写一套可以自由组合后端的新 macro，并基于此实现一个 Websocket 服务器。
接下来是设备之间的发现问题，很多「开源拖拉机」的做法是「直接打目标设备的 IP」，这不失为一种可行的解决方法，但过于 Nerdy，对用户来说心智负担真的很大。所以我们参照 localsend 的协议在 Rust 上实现了一个基于 UDP 多播的内网发现流程。调试的时候因为忘了 lo 上不能多播所以浪费了很多时间，不过这一块还是比较顺利地实现出来了。
接下来就是鉴权系统的实现和通信加密。我们一定不能直接做明文通信，但内网通信设备之间怎么互信是一个比较麻烦的事情。这边我选择的方案是自签一个证书，公钥的签名当成 Client 模式的密钥、而这个密钥本身也能做 HTTPS 服务的证书，这样能保证基本的通信安全性，而且是通过一组密钥同时解决了鉴权和加密两件事，用户体验上的负担是比较小的。客户端在 Pin 证书的时候，Rune 会挖掉密钥上的两个字符，要用户做一道选择题，在客户端发起请求的时候，担任服务器的 Rune 客户端会自动弹出鉴权请求窗口，上面同时显示了确认是否授权、以及本机密钥两部分功能。客户端需要比照图案作出选择，服务端需要确认给予控制权限。
另外，这套加密通信系统也支持标准证书，这样你可以通过 Nginx 安全第把播放器控制服务暴露给公网，来实现更多用例。
这个设计看起来都挺美好的，但现实比较残忍。我得承认作为一名前端，搞自签证书、配证书信任之类的事情并不是我擅长的，因此熟悉这一块的基础知识和工具链就花了好长时间。算上画界面写后端之类哩哩啦啦的各种杂活，还有我兼开的旧坑卡牌游戏北平IO，这段时间每天都在把自己往 Burnout 的边缘推，所以效率并不高，眼睛一闭一睁好几周就飞出去了。
你或许以为上面这些就是实现遥控功能的全部，但事实上还有很多细节的功能要处理。比如，并不是所有请求都可以被发送到远程，像是连接管理、断开连接、切换媒体库之类的功能还是需要在本地处理，这不仅意味着你需要在封装层面区分两种不同的的消息类型，本地也得提供大量的伪实现来确保能有一个「工作一半、完成基本系统管理」的播放器核心（主要是为了过编译）。
除此以外，虽然播放是在远程，但是展示媒体封面这件事情是在本地发生的，所以还得单独处理 Coverart 提取和下载的问题。但我个人觉得，因为后面还要做手机客户端直接从另外一个 Rune Instance 同步音乐的功能，所以传输二进制文件肯定绕不开，该做还是要做。因为 Flutter 信任自签证书没那么好搞，所以这些功能全都放在 Rust 侧来做了。当然，这些也都是不走远程协议的 RPC 请求。
反正，一个「看起来蛮简单」的功能，实际做起来其实挺复杂的。这次做遥控协议还带来了一个有趣的副产物：Smart Speaker Service，一个纯 CLI 程序，你可以把它挂在 systemd 上，用任意一台设备来控制它的音乐播放。这有点像 Sonos，但不带云服务。
但考虑到 Rune 本身推崇的就是「把音乐放在你自己的电脑上」，这个 Half Sonos 并不鸡肋。
