额外提一下,这么把架构撑起来是为了给接入第三方串流媒体留空间。第一步先做 Rune Private Cloud 是为了把 local first app 的 UI 架构层做起来,允许媒体文件和元信息从远端缓存。
这么做架构的另外一个好处是,移动端软件可以把电脑当成一个 Server 连过去,主动选择同步电脑上的哪些音乐,理线享用。你既可以从电脑上拿音乐,也可以从别的手机上拿音乐,也可以从你家 NAS 上拿音乐,这样的音乐流动架构是更加灵活的。
洗澡的时候思考了一下 Rune 的下一个版本,决定把自动 tagging 往后放,先做 Rune Private Cloud,不然 tagging service 的 license 问题绕不开……
Читать полностью…总结一下这个新架构,主要隔了一层,加两个东西:数据存哪、在哪播
这样能隔出来几个模式:
本地播放:数据存本地,在本地播
遥控:数据存远端,在远端播
串流:数据存远端,在本地播
推送:数据存本地,在远端播
Getty Images and Shutterstock to Merge https://newsroom.gettyimages.com/en/getty-images/getty-images-and-shutterstock-to-merge-creating-a-premier-visual-content-company
Читать полностью…Nvidia announces $3k personal AI supercomputer called Digits https://www.theverge.com/2025/1/6/24337530/nvidia-ces-digits-super-computer-ai
Читать полностью…因为要做遥控模式,所以得把整个事件系统重构一下,现在响应的格式也被集中处理了,这样可以在数据通信层做一次抽象,如果你在遥控其他设备的播放,就走 WebSocket 把结果返回操作机器上,否则直接返回到本地。
做这个设计是为了区分点对点的数据通信,还有广播式的数据通信。
你可以想象一下 Nexus Q 的场景,家里有一个 Rune based Smart Speaker,你家里所有的电脑和手机,只要装上软件就能控制它放什么歌。发起操作请求的设备需要针对特定操作获得响应,但是其他设备只需要知道播放状态的刷新就好,所以得区分两类消息。
Rune 的遥控模式就打算实现成这个样子(其实有点像不支持串流媒体的 Sonos)。
这种架构分离可以支持无头播放设备(Rune 智能音箱)和任何有屏播放器(装了 Rune 的智能设备和电脑)。
这一点做完之后,在架构上我们就有了一个类似 Server 的东西(或者说 Private Cloud),从这个 Server 上我打算再利用 MusicBrainz 和 Acoustic 的开放数据,搭建一个你自己的、有隐私保障的 Auto Tagging Server。
菩萨用户可以开公有云的 Tagging 服务器,你也可以自己搭服务器。
从这个架构开始继续向外延伸,Rune V3/4 应该就会(但我不一定会做) Self-hosted 音乐串流服务器,还有 Self-hosted Podcast Server,这样整个架构和演化路线就说得通了。
https://windiscover.com/posts/bing-web-provides-a-google-search-ui.html
微 软 你 在 干 什 么
以前一个高级工程师带两个中级再带四个初级来完成一个项目。一般初级就是来给中高级填时间的,现在ai 能直接填了。结果就是高级的位子还在,中级可能留一个,初级再留一两个。ai 提供了一种能力复制,让整个金字塔变瘦了,1-2-4变成 1-1-2。市场繁荣的时候岗位多,一年的工作经验用几年都行,现在很难了,毕业生翻倍岗位减半。我当初只会个jquery 就能找到工作。
产业升级总会有群体被牺牲。两轮电动车给了自行车厂和店灭顶之灾,四轮电动车影响的更广,灭的是更长的产业链,整个行业批量消失。
https://github.com/snapview/tokio-tungstenite
在构思,Rune 如果有一个 Smart Speaker 模式,我要怎么设计整个 API,现在的想法是,一个简单的 HTTP Server 用来传 Cover Art,剩下的一律走 Web Socket 做遥控和发信息
头有点痛——
2025 年,React 的 #10389 依然是一个没有被解决的 issue!太厉害啦!
https://github.com/facebook/react/issues/10389