a.k.a. 《一个学生不带脑子刷 vBIOS，这是他的显卡发生的变化》
若 N 卡在刷 vBIOS 的过程中遭遇意外断电，随后主板自检反复重启，例如 DRAM - CPU - VGA 灯轮流亮，请寻找 能够亮机并且拥有 PCIe 槽的设备 ，例如使用核显、亮机卡或者雷电接口显卡坞，开机过程中按住 Esc + C 进入 Windows 安全模式（或任意恢复系统，至少要阻止 NVIDIA 驱动加载），确定设备管理器中列出了损坏的显卡，再使用 nVFlash 刷回 备份的原 vBIOS 。
如果没有核显，则可能需要将坏卡接在主板的副 PCIe x16 槽位上。我将亮机卡接在副槽上时，主槽上接坏卡则仍然会反复重启；交换后才能正常启动。
如果亮机卡也是 N 卡，在刷写原 vBIOS 时需要手动指定设备序号：首先执行 nvflash64.exe --list ，此时应当会出现一个列表，其中格式如下：
小众、多彩、塑料机身、Windows 内核、微软打造，在这些词条的加持下，我对 Lumia 的兴趣，早在《丧尸围城：瞭望塔》见到 Lumia 的身影，对 Lumia 1020 标志性的镜头模组印象深刻之前就已经产生。后来，Android 和 iOS 分庭抗礼，前者在一些方面越来越糟糕，这没能解决 Windows Phone 的颓势，却是我「润」到 Windows Phone 的首次冲动。直到前几天，在二手🐴看到一台崭崭新的 1020，我毫不犹豫果断下了单。
拿到手后才知道，这台设备没那么美好。它被排除在 Windows 10 更新列表外，
本文全长约 5000 字，阅读约需 12 分钟，内含少量插图和致死量吐槽，请谨慎食用。
昨天在 TG 上看到隔壁频道的点子：必须观看一定时间 Rickroll 后才允许连接，并且每次暂停会 +10s 的访客 Wi-Fi，顿时震惊：「原来还可以这么搞？？」仔细分析可行性后发现，这个访客 Wi-Fi 原理并不复杂，有折腾 OpenWrt 经验并且写过一丢丢 HTML 的话极其容易上手，于是将步骤记录如下。
ssh 的设备我自己使用的是红米 AX6 基于 LEDE 的自编译固件，因此能深入地自主精简、定制，如果没有自编译固件的条件或想法，可能会遇到一些奇妙的依赖问题。推荐选择闪存容量大或可扩展存储的路由器，防止折腾半天发现没有留给视频的空间。除此之外，如果想对这个访客网络进行限速（比如使用 SQM QoS），那么也许还需要较强的性能。
学期初，我终于攒出了人生第一台台机。R7 2700X (Zen+) 和 1060 的配置，时至今日最多中端水平，对于一个
| 台机 | Gram | |
|---|---|---|
| CPU | Ryzen 7 2700X | i7-1065G7 |
| GPU | GTX 1060 | Iris G7 |
| RAM | 8GB 3200 x2 | 16GB 2933 x2 |
| 屏幕 | 4K (ppi 183.58) | 1080p (ppi 157.35) |
如上所示，我并没有给自己攒出一台秒天秒地的
前几天终于用上了极为先进的 Moonlight，体验到了在移动端低延迟畅玩 3A 大作（主要是躺在床上推《魔夜》），却也遇到了一些不爽的地方，比如目前移动端设备千奇百怪，常规电脑渲染的 16:9 的画面，几乎不能在 2021 年的移动设备上铺满屏幕。怎么办呢？极客湾选择把用不上的输出接口与用不上的显示器接口连接起来，调整这个不存在的显示器的大小；市面上也有很多 HDMI 诱骗器，几十甚至十几块就能解决问题；我在看过蚊子大佬的博客后，选择动手折腾一个 Indirect Display，试试在不依赖外部设备的情况下，虚拟出第二个显示器用来串流。
因为不同设备的屏幕分辨率、刷新率不尽相同，使用 Indirect Display 还得信任签名时使用的证书，因此本文不会提供编译好的版本。不过编译并不复杂，具备计算机基础知识即可。
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 送至北京售后点维修的十天。这十天里，我碰不到 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。