使用 Indirect Display 虚拟显示器,全屏 Moonlight 串流

前几天终于用上了极为先进的 Moonlight,体验到了在移动端低延迟畅玩 3A 大作(主要是躺在床上推《魔夜》),却也遇到了一些不爽的地方,比如目前移动端设备千奇百怪,常规电脑渲染的 16:9 的画面,几乎不能在 2021 年的移动设备上铺满屏幕。怎么办呢?极客湾选择把用不上的输出接口与用不上的显示器接口连接起来,调整这个不存在的显示器的大小;市面上也有很多 HDMI 诱骗器,几十甚至十几块就能解决问题;我在看过蚊子大佬的博客后,选择动手折腾一个 Indirect Display,试试在不依赖外部设备的情况下,虚拟出第二个显示器用来串流。

因为不同设备的屏幕分辨率、刷新率不尽相同,使用 Indirect Display 还得信任签名时使用的证书,因此本文不会提供编译好的版本。不过编译并不复杂,具备计算机基础知识即可。

STFW.info 现已正式迁移至 RachelT.one!

Rachel 建站以来的第一次域名迁移已完成!从原来一时兴起注册的 Search The F**king Web 到 Rachel T / Tone,希望能够使网站更独一无二!

STFW.info 将在 2022/04/22 过期,在这期间,对原域名已迁移部分的访问将被重定向至 RachelT.one 对应的子域名,无需迁移部分保持不变;过期后,对 STFW.info 的访问将不再由我控制。若您收藏了过往文章或订阅了我博客的 RSS,建议在旧域名到期前尽快更新。我对域名迁移导致的不便深表歉意,欢迎您随时通过 RachelT.one 中的联系方式向我反馈迁移后出现的问题。

迎接又一次意难平

在我从面试教室出来的时候,我从来没有想过,第二天迎接我的是拒绝。就像我也从来没有想过,原来生活真的是一盒巧克力,昨天吃到的还夹着牛奶的香味,今天就变成了 100% 的黑巧,甚至连可可香味都没有。

和我经历过的那么多重要节点一样,在结果揭晓的那一瞬间,我的内心平静似水。和我经历过的那么多重要节点一样,它留下了又一次深刻的意难平。我释然了吗?我不知道。

从本地到云端,我的数据备份方案

本文是一篇小短文,以电脑故障为契机,我探索了常见的、无需自备独立服务端的备份方案,并将权衡利弊后我最终采取的方案及部分思考记录在此。

我主力电脑在 2021 年初发生了数次故障,失去唯一的工作、娱乐中枢令人十分难受,更何况中枢内还保存着许多对我而言独一无二的珍贵数据。自那之后我才知道,我们往往过度相信我们依赖的设备,往往在失去数据后才意识到它们的重要性。

事实上,任何设备都有寿命周期。我们身边电子设备搭载的、用于存储数据的闪存,只能完好无缺地活过数百或数千次完全写入,往上就会慢慢入土。这很长,大部分用户很难让它报废,可是总有万一。更何况,大部分时候影响数据读写的,不一定是数据存储本身。举个例子,电池过放。只要让锂离子电池吃灰一年半载,再次翻出来时它就可能因为电压过低拒绝充电,甚至彻底告别人世。

不管哪方面出问题,一旦危及到数据,那都不是小问题。有谁希望自己珍贵的个人文件,比如写到一半的策划书、没来得及剪辑的视频、旧手机上存着的照片等等在某一天突然离自己而去呢?云端备份、存储是个不错的选择,但完善的数据备份绝不能只有云端。本文大致介绍了一些我使用的工具,主要面向 Windows / Linux 与 Android,也可能包含面向 Apple 大家族的内容。总之,从云端备份开始吧。

为什么我不推荐 LG Gram

这篇文章基本成形于我 LG Gram 送至北京售后点维修的十天。这十天里,我碰不到 Steam,写不了大型工程,没有 Typora 甚至连 Markdown 都用得糟心,唯一能让我重温代码的居然是跑在 Termux 上的 code-server

但这次硬件故障本身却并不是我不推荐 Gram 的原因。倒不如说,这次硬件故障让我更加坚定了我对轻薄本的执着,以至于刚出故障时我就已经决定,下一台电脑就算不是 Gram 也得是同类竞品(真的有吗)。

在此期间,我也想过要把 Gram 安利给身边的所有人,包括正在阅读本文的你。尽管如此,细细思索后我最终还是觉得,Gram 有它的目标人群,而它不一定是你。因此,不管我有多爱 Gram,我还是要讲讲,为什么我不推荐 LG Gram。

我个人使用的 LG Gram 型号为 14Z90N,i7-1065G7,8 GB DDR4 3200 MHz(后加同型号内存扩至 16 GB 双通道),512 GB PM981a,Intel AX201 网卡,14 英寸 LG 自家屏幕,72 Wh 自家电池,实测重 980 g。

站在普通人的角度,谈谈教育、兴趣、Linux 与编程

从迈入 2021 年以来,我就一直想写点关于这个话题的东西,但这毕竟输出的是自己的价值观,不可能要求所有人都能理解,更何况我还只是个涉世未深、从未迈出过象牙塔的本科生,又有什么资格对这个话题评头论足?

尽管如此,在身边多了很多对我擅长的领域感兴趣的人后,我觉得也差不多是时间好好想想很多事情的本质了。

本文基本为作者深夜自嗨时挥笔写就,可能部分语句没有道理没有逻辑甚至没有基本的语句流畅度,可能包含妄加论断和大放厥词,还请谅解。此外,作者本人对思想交流持开放态度,欢迎参与讨论或留下反馈,感谢。

「分区存储」是个啥?

书接上回。

前文 我们说到,Android 10 引入的「分区存储」成为了不少媒体、用户、开发者关注的焦点。关于这一特性的文章层出不穷,但很可惜,这些文章要么只是概览,要么和官方一样说得一套一套的让人丈二和尚摸不着头脑,还有些搞错了分区存储的定位和原理。加上 iOS 和 Sandboxie 等前辈在应用隔离方面的成功实践,大部分人一看到「分区存储」这几个字,首先想到的就是这些前辈,进而理所当然地以为 Android 的分区存储 = 给应用挂载独立的存储空间,不管应用怎么造作都不会影响到用户和其他应用。

理想很美好,可惜事实并非如此。我们慢慢讲。

本文大部分论断囿于作者的能力、阅历和经验,仅代表作者的理解与推断,还请广纳思想,避免偏听偏信。

写给所有人的 Android 文件访问行为变更

Android 初代发布至今已有 12 年,这些年间,Android 一直因系统版本碎片化而饱受诟病。据 Google 数据,在统计范围内仍有 26.3% 的设备运行着 Android Marshmallow 及以下版本的系统,而升级到 Pie 及以上的设备更是只占了 39.5%。面对如此繁杂的系统版本,应用的兼容性是个大问题,尤其是文件访问方面的资料太杂乱分散,带来麻烦又浪费时间。本文以 Poweramp LRC Plugin 的开发为契机写就,希望能帮助此后跳进存储这个大坑里的开发者,以及想了解不同系统版本差异的用户。

使用 OBS 和 Virtual Cable 私人直播

明天就能玩到心心念念的原神了,作为从漫画发布起就一直关注的云旅行者,在因为时间和年龄错过了内测之后,终于有机会到提瓦特大陆一睹期待已久的美景。欢喜之余,自然想让亲近的人与自己分享这份激动。

这就带来了问题。鉴于隐私、年龄等因素,在 B 站直播并不是个好主意。最好的平台当然是 QQ,它不需要双方再额外装上其它令人生畏的国产软件。然而,我所用的 TIM PC 端 2.3.2 版内建的「屏幕分享」并不包括系统音频,也无法捕捉 OBS 混音处理后的音频。OBS 强大,可面对 QQ 这种私有协议+客户端也无计可施。VB-Audio Virtual Cable 能够设置为实体麦克风的侦听输出,但若要将系统音频全部塞进去(考虑到大部分游戏并不支持设置音频输出设备),就只能将默认音频输出设置为 Virtual Cable,带来了对面说话 -> 通过 Virtual Cable 播放给对面的套娃场景,更别说在各种各样的地方指定输出设备得有多复杂了。

还好,OBS 论坛里的 这篇帖子 的博主和我有一样的疑惑,并且帖子里给出了可以用的回答。本文以中文将其记录,并改造成了 QQ 可用的版本,同时提供了其它场景可能可行的解决方案。

not found!