正确配置 vc4-fkms-v3d 驱动,避免使用 llvmpipe

vc4-fkms-v3d 是树莓派的开源 GPU 驱动,支持 OpenGL 2.1。正确配置的情况下 mesa 应该使用 V3D 驱动而不是 llvmpipe,后者使用的是 CPU。树莓派本来就贫弱的 CPU 并不经得起桌面渲染的折腾。此外 Chrome 也应能打开大多数硬件加速。

首先需要切换到开源驱动。前往 raspi-config -> Advanced Options -> GL Driver -> GL (Fake KMS)。树莓派 4 是默认使用这个开源驱动的。

继续阅读 »

将树莓派用作 SD 读卡器

需求

  • 树莓派
  • SD 卡 2 张,其中一张可引导系统
  • USB 存储(可选)

不需要

  • SD 读卡器
  • 显示器
  • 键盘

最近买了第四代树莓派,但等到 SD 卡寄到了我才意识到我的读卡器忘记带在身边了。环顾四周,唯一有 SD 卡槽的居然只有那只老的树莓派 3B+。理论上我可以直接用 U 盘引导系统,但我不知为何一直无法成功。我更无法冒险将唯一可以引导系统的 SD 卡改为引导到 U 盘,因为万一失败了我在搞到读卡器之前都再也进不去系统了。

于是我就想到了一个骚操作:先用一张 SD 卡引导系统,ssh 进去,然后利用 pivot_root 将 root 转移到 SD 卡以外的地方(U 盘或者内存盘),这样我就能把引导系统的 SD 卡拔下来换新的上去了。全程都可以在 ssh 上完成。

继续阅读 »

在 MSYS2 中安装 Git for Windows 并自定义 PATH 中的 toolchain

背景

Git Bash 在 WSL 出现之前一直是 Windows 开发必不可少的工具。哪怕不使用 unix toolchain,git 也是免不了要用的。在 WSL 出现后它依然没有退出历史舞台——至少 VS Code 目前还需要 Git for Windows 来整合 git 功能。此外,Git bash 是基于 MSYS2 开发的,而 MSYS2 在一些从 *nix 移植到 Windows 的项目上不可或缺。

然而,Git for Windows 中的 MSYS2 环境是刻意缩减过的。最重要的是他没有 pacman 包管理系统。如果不想装两份 MSYS2(一份完整的,一份 Git for Windows),那么 Git for Windows 官方提供了两种方案:使用 Git for Windows SDK,或在已有的 MSYS2 中安装 Git for Windows SDK

注:Git for Windows 修改过 MSYS2 的运行环境。未经修改的运行环境不能很好的在 Windows 下互操作,例如 Powershell 中连 git status 都会无法执行。因此在 MSYS2 中安装 Git for Windows 会覆盖原版的 MSYS2 运行环境。

摆脱 SDK

Git for Windows SDK 是一套为了开发 Git for Windows 而存在的环境。把这套 SDK 当 MSYS2 使用会有诸多不便。我只是想把完整的 MSYS 和 Git for Windows 合二为一而已,但在已有的 MSYS2 中安装 Git for Windows SDK 教程中却把 SDK 一同装上了。不装 SDK 其实很简单,不安装 git-extra 包即可。也就是最后一步的命令改为: pacboy sync git:x git-doc-html:x git-doc-man:x curl:x

继续阅读 »

2018 Camry Hybrid 的一些体验

说起来 2018 款的混动凯美瑞我已经开了半年一万多公里了,也算可以发表一些车主感言了。我开过的车有限,这是我的第一辆车,我更称不上(也不想做)车评人,这只是一点车主感想,酌情阅读。

车型:2018 Camry Hybrid SE (加拿大款,相当于国内不存在的风尚版 + 混动)

动力系统:2.5 L 横置前驱直列四缸 + 双电机

变速系统:ECVT


TL;DR

这一代的凯美瑞外观变得可以接受了。混动系统带来的油耗优势只是顺带的(也就抵抵差价),舒适性上的提升才是需要重点关注的地方。总体而言混动款就是一辆整体体验更好的无极变速燃油车,不用在意电机的存在,买菜通勤的王者。然而这仍然是一辆有着特殊技术的燃油车,而不是电动车,不要做不合理的期待。

多媒体中控可以忽略不计,北美款连中文都无法显示,更别提 Apple CarPlay 这一类体验更优秀的投屏系统了(据说新款有了?)。


一些 FAQ – 混动部分

混动系统是什么原理?

对丰田这套混动系统(THS-II)最好的理解其实是将这两颗电机看作是变速箱的一部分,而不是独立的动力源。(自己会动的变速箱你见过吗……)这套系统没有真正意义上的变速箱,因而也没有传统变速箱的传动损耗。它的无极变速是由两颗电机和行星齿轮完成的,所以真正的变速传动损耗来自于这一部分。因为这套系统能做到无极变速,但又不采用钢带式无极变速器,所以一般数据上写的变速系统都是「ECVT」,以区别于更常见的钢带式 CVT。

大多数时候也并不存在所谓的油电切换,因为这套系统的工况并不是非油即电或者两边一起马力全开,而是一个线性的分配:发动机与电机的输出比例(电机的输出可以是负的也就是充电)占多少可以自由地分配。在中控屏上看到的油电切换,要么是从纯电行驶到发动机启动,要么是正好这一瞬间电机的输出从正到负或者从负到正。前者有时会有介入感,后者不会。

继续阅读 »

使用 XLaunch 一键启动 WSL 中的 Gnome 3

升级到 Windows 1803 后可以跑更多的桌面应用了。虽说 WSL 完全不是为此设计的,但我就是乐此不疲地看着热闹,一次次地试探 WSL 的最大潜力(误,只是好玩而已)。虽然还是存在一些问题,Gnome 3 也不意外地可以运行。这篇文章将讲述如何使用 XLaunch 一键启动 WSL 中的 Gnome 3。这篇文章便是在 WSL 上的 Gnome 中完成并发布的。

由于我未能可复现地安装 Gnome 3,暂时就不详细讲怎么安装了。首先需要升级 Ubuntu 至 18.04 LTS。需要安装的包有 ubuntu-desktop 和 mesa-utils,前者包含 Gnome 3 后者包含软件渲染器(因为 WSL 不支持直接硬件访问)。


手动启动

安装完成后可以先尝试手动启动 Gnome。方法是先启动 dbus 服务:(每次启动 Gnome 前都建议重启 dbus 服务,以防 dbus 挂了)

然后使用 XLaunch 打开一个 One large window 的 X Server 并前台启动 Gnome:(或其他 Windows 上的 X Server 实现,并请根据实际 X Server 的端口修改 DISPLAY 的值)

不像之前版本的 WSL,现在使用 dbus 不需要任何的修改,因为 Windows 1803 的 Win32 及 WSL 子系统已经全部支持 Unix Domain Socket 了。对于 Gnome 3,则需要指定其以 x11 的方式启动。效果大概如图:

继续阅读 »

解决 MacBook 双系统无法升级 High Sierra 的问题

我的 MacBook Air 跑的是 Windows 10 + macOS 双系统,但在升级 High Sierra 的时候出了问题. 症状是无论是原系统升级还是抹掉 macOS 全新安装,都会在安装到一半的时候提示 An error occurred while verifying firmware. 我本以为是 APFS 的问题,便尝试过先格式化成 APFS 再安装,以及打上不转换 APFS 的 flag 安装,但依然不行. 更可怕的是,第二次尝试更新的时候,更新失败后无法使用原系统了.

前几天终于有时间去了一趟苹果店,Genius Bar 的小哥分析说可能是因为 EFI 分区出于某种原因不能被 macOS 的安装程序写入,而 mac 的固件是存在 EFI 分区里的,因为 APFS 的原因需要新版的固件才能引导,所以升级 High Sierra 的时候就失败了. 所以最后我让他把整个硬盘抹掉了重装,果然就没问题了.

那现在的问题就在于,我已经全盘备份了整个硬盘,如何把最新的 firmware 导入到原来的系统. 我先备份了整盘抹掉重装 High Sierra 之后的 EFI 分区,然后把之前的全盘备份恢复到了硬盘上,接着把新的 EFI 分区覆盖原来的 EFI 分区,最后把 Windows 在 EFI 分区里的引导文件复制回来.

继续阅读 »

TypeScript on Electron 解决 Renderer 没有 exports 的问题

Electron 的 Renderer process 虽然和 main process 是不同的进程,但依然可以使用 node 的环境,比如 require(‘fs’) 之类. 但如果一个 js 脚本是在浏览器环境中用 <script> 标签加载的话,exports 变量是缺的,会报 exports is not defined.

而解决方法是不要使用 <script src=”./script.js”></script> 而是 <script>require(‘script’);</script>. 这样所有的脚本就是以 module 的方式加载而不是页面脚本了. 以 module 方式加载的脚本是有 exports 变量的.

继续阅读 »

使用 VSCode 运行 Task 并自动 Attach Debugger

本文将讲述如何在 VSCode 中使用 Attach 模式 Debug 的时候,也能像 Launch 模式一样一键启动 Debuggee. 具体原理是使用 preLaunchTask 并将此 Task 的 isBackground 属性设置为 true.

VS Code Debug Protocol 描述了两种不同的 Debug 方式:Launch 以及 Attach. 他们分别对应了 VSCode 负责启动程序并 Debug,以及 VSCode 去 Debug 一个正在运行的程序,包括非本地的程序.

其中,Launch 模式的潜在含义是,VSCode 将负责管理 Debuggee 的生命周期,也就是说 VSCode 负责启动及停止,而这些操作对于用户而言就是按一下按钮. 反观 Attach 则是另一种设计:用户必须自行启动 Debuggee,可以在本地可以在远程,只要 Debugger 能够与之通信,而 VSCode 只负责将 Debugger 与 Debuggee 对接.

在本地开发本地运行本地调试的情况下,Launch 无疑是最好的选择,因为一旦配置完毕,今后 Debug 只需要一键启动及一键停止. 这种开发环境十分的理想化,尽管可以满足大多数需求,但当环境变得复杂时,Attach 模式将是无法避免的. 例如执行代码的机器一定是在远程,这常见于跨平台开发,包括在 Windows 上使用 WSL 做 Linux 开发,以及使用 QEMU + GDB 做内核开发. 尽管微软在近期对一些官方插件就 WSL 进行了优化,即可以使用 Launch 模式在 WSL 中运行程序,但第三方插件仍然不可避免地需要使用 Attach.

继续阅读 »

在 WSL 中使用 ssh-agent

在阅读前请注意,ssh-add 在没有 keychain 的情况下只能临时保存 SSH key. 也就是说重启 ssh-agent 后需要重新 ssh-add. 若要永久添加某个 SSH key,最快捷的方法是在 ~/.ssh/config 中添加 IdentityFile. 但如果要使用 SSH agent forwarding,就需要 ssh-agent 了.

在 WSL 中自动启用 ssh-agent 并不是那么直接,因为 WSL 的入口 bash.exe 并不能继承来自父进程关于 ssh-agent 的环境变量,毕竟父进程是个 Windows 进程. 此外另一点特殊的地方在于,当所有 bash.exe 进程结束的时候,所有的 WSL 进程会被杀掉,包括 ssh-agent.

ssh-agent 的启动比较特殊. 手动启动的方式是:

这是因为 ssh-agent 默认执行两件事:1. 后台运行 ssh-agent;2. 输出一段 shell script 以供执行. 这段 shell script 中包含着与这次启动的 ssh-agent 通信所需的环境变量.

一般情况下,例如在 Linux 桌面环境里,在桌面环境启动前 ssh-agent 就被启动并且环境变量也被设置了. 之后启动的桌面环境,以及桌面环境启动的 Terminal 都会自动继承这个环境变量.

继续阅读 »

用六面不均匀的骰子模拟一只六面均匀的骰子

最近被问到了这么一个问题,蛮有意思的. 这里可以做一个额外的限定:在有限的步骤内精确地将发生的事件分割成六个概率为 1/6 的部分,而不是随着操作次数的次数增多趋近 1/6.

经过了一段时间的探索之后,我发现想要通过重复掷固定次数的骰子来达成这一目标,在知道六面各自的概率后,是不存在一个策略可以把所有发生的事件精确地分割成六份的.

我将借助超越数,使用反证法来证明这一点.

为了证明这一点,首先可以做一些化简. 六面的骰子过于复杂,可以先尝试减少到两面,也就是把骰子简化成硬币. 假设这样的策略是存在的,也就是给定一个六面概率不一的骰子及其各面概率后,就可以得到一个正整数 n,然后掷这个骰子 n 次,根据每次掷的结果将结果分为等概率的六份. 然后假设存在一种只有两面的各面概率不一的骰子.

首先,这个两面骰子可以做到六面骰子的效果. 方法是掷三次两面骰子,可以得到八种不同的结果,将这八种结果分为六份(不能有任何一份是空的),就可以得到六个概率不一的事件集. 而根据刚才的假设,知道了六种结果的概率后,把它当作一个六面的骰子,重复 n 次掷骰子的操作,然后就可以得到均匀概率的六组结果. 最后,将这六种结果的其中三种分为一组,另三组分为一组,这样就得到了均匀概率的两组结果. 也就是说,当六面骰子的策略存在的时候,两面骰子的策略也同样存在.

继续阅读 »