重复造轮子严重。snowpack 和 vite 功能特性几乎完全相同，前者 svelte 、react 支持较好，vue 支持一般，后者 vue 支持较好，其他支持一般。
就不能统合一下吗？

虚拟机不是不行，对于低性能要求的游戏，或者 vGPU 、PCI 直通等方案照样可以。
但这没意义，游戏的反作弊模块禁止你在虚拟机中运行同样是“合情合理且有必要的”。
你非要玩，那被 qj 就是活该。当初爆出某游戏扫 ss 配置的时候，可是被“玩家”们喷惨了。

@no1xsyzy 至少能避免 buffer overflow

去中心化要的就是不被任何人 /实体 “可控”。

这种涉及安全的重要工具是不是应该用 rust 重写？

你可以理解为瓶子里装水，参数越高代表瓶子越大，“能够”装下更多地水。但实际装的水有多少，没有任何参数能够直接反映出。

@ryd994 不是所有项目都有一套“内部库”，开发者选择简单、省事、现有的低效实现是很常见的状况。
不否认你说的的 C 的所有优点，简单、直接、可控。理论上的效能 C 也确实拥有最高的上限。但语言的标准、库、生态实实在在地影响实际上的软件性能。比如 ripgrep 和 fd 的性能明显的好于 GNU 的 grep 和 find 。

这很好，干嘛要主动把自己的隐私送给 Google 呢。
如果致使其他人开发出可自建的替代后端就更好了。

你这个包管理的理念，有点太“绿色”了。
不过你源里的自制的 wsudo 好像不错，看起来能当个轻量的 sanbox 用。

@wms #108 你这样做就把原字符串 mutate 了，其他语言(fat pointer 实现)可以直接取 slice 。

加密后上 s3/oss

@ryd994 难用就会导致你实际中写出的程序变慢。c 最快应该说是理论上最快，实际中影响因素很多。就像我上面说的那个字符串的例子，确实理论上可以自己实现，但因为没有统一的标准，你和其他库交互时还是得转回来，一来一去还是快不起来。

慢可能是因为二进制数据先被解析成 string 了，并且对无效字符可能进行替换。你会发现最终产生出来的文件已经面目全非。

敲个 gal 或 Get-Alias 你就明白了。

@wms 取子串需要添加 null byte，取后缀需要先 count 。
语言的标准实现、库、生态当然会影响你写出程序的性能。就算你强行替换成最优实现，也只是理论上可行。比如标准的 null terminated 字符串性能慢，你改成 fat pointer 的实现，那你调用别人的库 /别人调用你的库都需要额外转换，性能还是不行。

@wms 取子串、取后缀。
再就是由于其糟糕的依赖管理，某些算法 /数据类型在其他语言你可以轻易导入其他人很好的实现，在 c 里你可能就懒得用了。
当然我不是说 c 不行，我只是说 c 并不是**永远**最快的（尤其是 real world c programs ）。

@wms 你这样说就过于绝对了，且不说工程上的复杂度导致 c 难以一直使用最优化的实现。一个最简单的例子，c 的 null terminated 字符串。