viruscamp

@BeautifulSoap 至少半年前就支持直接导出 vhdx 了

wsl --help
--export <Distro> <FileName> [选项]
将分发版导出到 tar 文件。
文件名可以是 - for stdout 。

选项:
--vhd
指定应将分发版导出为 .vhdx 文件。

--import <Distro> <InstallLocation> <FileName> [选项]
将指定的 tar 文件作为新分发版导入。
文件名可以是 - for stdin 。

选项:
--version <Version>
指定要用于新分发的版本。

--vhd
指定所提供的文件是 .vhdx 文件，而不是 tar 文件。
此操作在指定的安装位置创建 .vhdx 文件的副本。

--import-in-place <Distro> <FileName>
将指定的 .vhdx 文件作为新分发版导入。
必须使用 ext4 文件系统类型设置此虚拟硬盘的格式。

我认为的优先级
1. 网站全站 https
2. 网站后端采用 bcrypt 或更安全的验证算法
3. 用户一站一码
4. 网站后端 log 脱密记录
5. 网站 OTP 登录
...
100. 用户自己写个插件，把输入的密码转换后再发送
101. 用户对网站源码进行安全分析
102. 网站前端加密

我觉得 OP 有点迫害妄想症了，用户不相信网站，网站前端部门不相信后端，后端部门也怕开发人员假装无心 log 打出来了。

那 OP 也应该怕前端加密的 js 的代码里藏了记录原始密码的后门。

我建议别用担心的网站，非要用的话，一定要一站一码。

OP 信任密码管理器吗？操作系统或浏览器自带的密码管理器呢？再关掉密码同步功能呢？都不信的话，用个小本子记吧。

我见过几种 https 基础上用户侧密码加密的几种方案
1. 前端密码用固定的 hash 算法固定的 salt ，算出哈希后传给后端。如 @cmdOptionKana 所说：那么密码就是这个哈希值啊
2. 前后端协商出一个临时密码（包括前端随机一个给后端，后端随机一个给前端，某种基于时间的算法前后端同时算出），前端加密密码传给后端，后端解密。我的评价是，脱裤子放屁，发明了一个很不安全的 https
3. 更聪明一点，前端有后端给的公钥，时间+密码，加密后给后端，后端解密，验证时间(30 秒内)，得到密码。抓包得到的加密字串每次都不同，而且有效时间很短，如果后端短期内记录使用过的密码，有效期内的重放攻击也可以基本解决。这个思路，必须再往下走，前后端交互公钥，所有传输公钥加密，那么这离真的 https 基本就差安全的公钥验证了。

如果你能推进网站前端采用密码哈希方案了，你就不能推进网站后端采用 bcrypt 或更安全的验证算法，推进网站后端 log 脱密记录？后面两件事的优先级怎么都比前端 hash 要高的吧？如果网站后面两件都做了，前端 hash 就没意义。如果网站后面两件都不做，他会听你的意见采用前端加密吗？

关于“密码(口令)明文是隐私, 不应该让服务端知道的隐私”，不可能所有网站都采取前端密码 hash ，只有一视同仁，每个网站都用随机生成长密码，记录的事交给密码管理器(windows 自身，linux 的 kwallet ，keepass)，你记忆的密码只有密码管理器的。

勘误:
1. 同时发起 join!(hello_cat(), hello_dog()); // 相当于 js 的 Promise.all

其实异步这里最好用 js 来理解 async 和 await ，js 还是一个典型的单线程 executor , 而你现在用的 futures::executor::block_on 也是单线程 executor .

想达到你要的效果，要改两点:
1. 同时发起 hello_cat().join(hello_dog()).await; // 相当于 js 的 Promise.all
2. sleep 改异步的，比如这个 https://docs.rs/futures-time/latest/futures_time/task/fn.sleep.html

如果是常用的多线程 executor 的话, thread::sleep 是可以达到你的效果的，但是错误用法。

你检测下看看, 你的根分区是哪个
$ df -h
/dev/nvme0n1p2 1007G 11G 945G 2% /

几个分区
$ sudo fdisk -l /dev/nvme0n1

我看是 os-prober 找的，它只能从 /etc/os-release 里面读到信息