@dilidilid 你说的这个东西明显有便利性上的损失
我说的是在对应的便利性上，Chrome 的安全性上已经做到最好了。

不会，我觉得会提高。因为你会看到别人是怎么写这个的东西，或者给你其他的解决思路

@msg7086 你这个是工作流和提交的历史粒度的问题。

我没有把他当成史书来写，只是我觉得提交历史的整理不应以“模糊真实变更”为代价，过于简化的历史可能反而增加复杂性。

具体到你的场景，如果是我的话，我会创建一个中间分支，比如`dev`吧，将个人分支合并上去的时候用`merge --no-ff`，这样这个分支上看起来就只前进了一个提交。

当然具体选择什么样的工作流随你，你觉得什么样的工作流适合你都行。我只是说我比较喜欢`merge`。

至于什么时候提交：

我的观点是一个提交实现一个逻辑单元：

每次提交都应对应一个独立且完整的逻辑改动，例如：

- 实现一个功能。
- 修复一个 Bug 。
- 添加测试用例。
- 改善代码的性能或样式。

嵌入式 Windows 不是精简版 Windows ，是为了嵌入式场景优化，而不是为了游戏优化的。而且嵌入式 Windows 好像也不流行吧。所以如果拿 Windows 作主机的话，可能还是得标准版。标准版的就不便宜了。而且就算能用嵌入式 windows ，授权费也不会比 Linux 更便宜。

我觉得 V 社可能有以下几点的考量：
1 、成本控制，上文所说地授权费嘛。
2 、控制力，定制操作系统使其可以自由地设计功能、用户界面和系统更新流程。
3 、竞争关系。当初 2016 年微软商店刚出的时候，有不少人就担心其和 Steam 的竞争关系。
4 、性能。Windows 是通用操作系统，很重，性能优化不是关键。

V 社其实 2014 年就有做过主机了，那时候就是基于 Linux 。估计想和 win 脱离已经很久了。

有一种观点认为，仓库的提交历史即是 记录实际发生过什么。 它是针对历史的文档，本身就有价值，不能乱改。 从这个角度看来，改变提交历史是一种亵渎，你使用 谎言 掩盖了实际发生过的事情。 如果由合并产生的提交历史是一团糟怎么办？ 既然事实就是如此，那么这些痕迹就应该被保留下来，让后人能够查阅。

另一种观点则正好相反，他们认为提交历史是 项目过程中发生的事。 没人会出版一本书的第一版草稿，软件维护手册也是需要反复修订才能方便使用。 持这一观点的人会使用 rebase 及 filter-branch 等工具来编写故事，怎么方便后来的读者就怎么写。

总的原则是，只对尚未推送或分享给别人的本地修改执行变基操作清理历史， 从不对已推送至别处的提交执行变基操作，这样，你才能享受到两种方式带来的便利。

以上内容来自《 pro git 》，个人更赞同第一种观点。所以我比较讨厌 rebase 。

我比较喜欢用 git merge --no-ff --no-commit

直接存字符串，对运维最友好

WebStorm 不是现在非商用免费了么，那你可以都试试，又花不了你时间
反正我是从 VSCode 跳到了 WebStorm

要不你问问 ai

便利性和安全性你总要做个平衡，对我来说是安全性更重要一点，所以我不介意把密码设的长点。
你要是想更方便，那把密码设短点不就行了

忍了

如果跟 win7 比的话，确实是半成品。
跟 win10 比的话，其实都是半成品，我感觉 win11 还好点。

我的是日亚买的 quest 3 ，不是 3s 。

全程需要魔法环境，我试过旁路由，没成功，最后还是主路由上装了魔法插件（设置了只给机器走代理）。但设置好代理以后使用还是非常舒服的。
Quest 有自己的商店，不需要配合 Steam 。可以不依赖电脑直接玩游戏。但是用跟串流线（其实就是 USB 线）连电脑玩，或者无限串流，甚至好像还能玩 vr 版的 minecraft ，不过我都没试过。
长时间佩戴舒适感还可以，我上次玩《渔夫的故事》玩了 1 小时 45 分钟，直接玩到结尾。没感觉有不舒服的地方。
我买的是顶配版，但我感觉 128G 够了，没有那么多游戏要装。
3s 我不知道，但 3 对比 2 提升很明显。因为我租过 2 ，所以感觉提升挺明显的，就是那个彩色透视。

推荐的游戏的话呢：《渔夫的故事》重点推荐。《 Beat Saber 》不用说。《方块主义》挺不错的但有点难。《 The Climb 》还行。还有包括自带的游戏如 Quest2 的新手教程、Quest3 的《 First Encounter 》。

这个东西买来以后的大部分时间都是吃灰。但其实我不是很在意，因为这玩意儿也就几千块，还算便宜。而且我向来比较舍得在游戏上花钱，对我来说只要有一个游戏玩的舒服，就是值得的。（这个游戏就是《渔夫的故事》）

Windows 开启 Hyper-V ，然后里面装个 Debian ，上面再装个 WireGuard 。我是这么干的。

没啥吧。商场又不是图书馆，本来就是比较吵的，而且也不是外放抖音，只是通知音。

我投 js 一票。
Atwood 定律：“任何可以使用 JavaScript 来编写的应用，最终会由 JavaScript 编写。”
我觉得这句话有点夸大其实，但是还是有一点道理的。

你开发命令行应用，Node.js 能写。
你开发桌面应用，Electron 能写。
你开发 Web ，js 还用说吗？
移动端开发，React Native 和 uniapp 。
爬虫，js 有 puppetter 。

首先，Java 学习包括前端内容（后端会点前端很正常）和容器学习（后端会点运维也很正常）。
但你的内容可以缩减一点，jQuery 没必要学了，Linux 脚本意义也不大（但 Linux 命令得会）。
k8s 可以先不学。宝塔就算了吧。数据库只要学 MySQL 就行。Python 也可以不用学（但不少程序员都会）。

其次，Java 适合做的是 Web 后端。给泛前端提供 api 接口，所以是命令行的。图形化界面（ GUI ） Java 也能做。但是不好。
你想做的如果是微软的 exe 文件，那 C#是最合适的，WinForm 就可以拖动时生成控件。
不过不建议，一是 C#前景不怎么好，二是现在流行跨平台程序。

然后，我也不知道为什么，现在好像做 GUI 好像都是不流行拖拽式生成页面了，而是更倾向于 html 、qml 这种配上样式。

支持。有幸读过大佬的书。
我倒没有用 Redis 干什么特别的事，不过我在尝试写一个 Java 版的 Redis ，想用于测试环境使用
https://github.com/dcsuibian/jredis

KeePass

我本来也是在 docker 里面跑的 qb ，但是弄 ipv6 好像比较麻烦，所以决定下次直接用 windows server 跑了。不知道其他人 ipv6 怎么弄的