@securityCoding #49 这里讨论的问题是 merge 和 rebase，发生在打 tag 之前，似乎和 tag 关系不大。

@securityCoding #47 不是每个 feature 一个 tag 吧，总会有合并操作的，打 tag 也是在合并完的分支上打 tag 。

我只知道当需要撤回合并操作的时候，特别是公司项目上线计划临时调整的时候，直接 revert merge 提交很方便，不知道 rebase 怎么处理，懂的可以分享一下。

个人觉得版本控制系统的核心价值是体现整个版本变更历史，使用 rebase 仅会留下提交，无法区分是合并操作还是提交操作，所以“merge 产生无意义的提交”可能连 Linus 本人都不赞同。

整理分支是另一码事，希望整理得多么“干净”取决于能接受丢失多少历史信息，就好比服务器每周五备份，周三的时候你想恢复周二的数据，对不起没有，只能恢复到上周五。

你可以不在一个分支上体现任何 merge 记录，但也同时放弃了利用 merge 记录做审计或操作的能力，如果综合权衡是适合当前项目管理的方案的话，也是可以的。

回复没法格式化代码，你自己贴到编辑器里格式化一下吧。

```
const http = require('http');

const server = http.createServer((request, response) => {
console.log('收到浏览器请求流。');

// 构造发出请求的 URL
const url = new URL('http://httpbin.org/post');
// 添加 Search，也就是 Query string
url.search = new URLSearchParams({
'type': "1",
});

// 向 httpbin 发送请求流
const req = http.request(
url,
{
"method": "POST",
"headers": {
"Content-Type": "application/x-www-form-urlencoded;charset=UTF-8",
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36",
},
},
res => {
console.log('收到了 httpbin 返回流');

console.log('将 httpbin 返回流对接到浏览器的返回流。');
res.pipe(response);
},
);

// 结束 httpbin 请求流
req.end();
});

server.listen(3000);
```

题主这个需求有很多种方式可以实现，最简单的是流（ Stream ）。

浏览器向这个 node 服务发送请求的时候，node 服务会接收到一个来自浏览器的请求流，然后 node 服务向 httpbin 发送一个请求流，httpbin 返回一个返回流，然后像接水管管道一样把 httpbin 的返回流接在 node 服务即将返回给浏览器的返回流，浏览器最终收到了数据。

用流的好处就是不需要自己重建返回给浏览器的返回结构，直接复用上游的返回结构；另一方面 node 服务不需要缓存 httpbin 的整个返回数据，用 async/await 的方案通常会把 httpbin 返回的数据整个存在 node 服务的内存里，小量数据还好，如果是下载大文件的话有撑爆内存的风险。

http 模块的文档在这：
https://nodejs.org/api/http.html

http.createServer 里的回调函数的两个参数类型：
https://nodejs.org/api/http.html#http_class_http_incomingmessage
https://nodejs.org/api/http.html#http_class_http_serverresponse

你可以看到这两个类型都是“Extends: <Stream>”即继承自 Stream，Stream 的文档在这里：
https://nodejs.org/api/stream.html

node 服务返回给浏览器，以及 node 服务发请求给 httpbin，都是属于可写流（ Writable Stream ），可写流在写完之后必须调用 end 来结束流。
httpbin 返回给 node 服务的流是可读流（ Readable Stream ），你可以把可读流用管道方法（ pipe ）对接到一个可写流上。

type VS class

做软路由的话，我见到比较多的是用 NanoPi R2S 或 R4S，看油管上测评说做梯子性能挺好的。

进软路由的坑，里面都是你想要的东西。

游戏用的话也可以买加速器，有的路由器是内置一些加速器的客户端的，可以透明代理，比如华硕路由器内置 UU 加速，买个会员就能用了。

盲目从众的话，就确实是智商税。

我们拍婚纱照的时候就很明确目的，即拍一些真正好看的照片，留下这段时间的青春美好。
所以我们做了很多功课，选择影楼、选择套餐、拍摄、选片、最后选择成品方案。
相册有三本就可以了，双方家里一家一本，自己一本，相框什么的有需要就做，没需要就不要，跟影楼销售拉扯，争取换成精修额度，靠谱的影楼的精修水平还是很不错的，精修和无修照片都存电子底版，这些才是最终要买的东西。

花了不少钱，但出来效果真的很让我们满意，估计以后也基本没什么机会拍这种东西了。

火狐从来都是用国际版，安卓比较方便，iOS 可能就得换区了吧。

火狐 Nightly 可以用扩展，现在 bug 也没那么多了。

可以看一下 Linux 的权限机制 https://wiki.archlinux.org/title/Users_and_groups_(%E7%AE%80%E4%BD%93%E4%B8%AD%E6%96%87)

用户基本分为三类，root 、普通用户、nobody，分别对应所有权限、有限的权限、无权限。

按照我个人的习惯来说，判断应该使用哪个用户：
root：尽量不用，基本只有我需要在服务器上调整配置和安装系统软件的时候会用到；
nobody：如果只需要让程序或脚本访问服务器上所有人（ all ）都能访问的资源，或者当所有资源都受权限管控的时候不想让程序或脚本访问任何本地资源，那么就用 nobody ；
普通用户：除了上面需要用 root 和可以用 nobody 的场景以外，基本全都用普通用户。

每个文件和目录本身会有：
1. 归属于的用户和归属于的用户组；
2. 权限标识，按照身份分为自己（ user ）、群组（ group ）、所有人（ all ），按操作分为读、写、运行权限。
root 不受权限标识的限制，nobody 只能访问所有人都能访问的资源，普通用户可以访问归属于自己的文件和目录，初次之外具体看权限标识的设定。

回到题主的情境，签证书可能可以用普通用户和 nobody 来做，所以可以不用 root ；证书文件又属于需要保密的，不能让所有人都能访问，所以不用 nobody，那么最好用普通用户来做。
即你可以创建一个普通用户，如名叫 signer，同时创建一个存放证书的目录，比如叫 ca ；
ca 目录和 acme.sh 文件归属于 signer 所有，设定为所有人不能访问、自己可以读、写、运行；
同时 acme.sh 脚本不需要被群组访问，所以把这个文件单独设定为群组不可访问；
执行签证书的任务的时候使用 signer 用户来执行 acme.sh 脚本，在 ca 目录下生成证书文件。

然后确保 ca 下的证书文件和 ca 目录所有者、权限标识一致。

接下来就是需要用证书的程序了，它们只需要对证书的读权限，所以可以让 signer 和需要读取证书的用户在同一个用户组里，比如叫 ca_ro，并让 ca 目录及其中的证书文件属于 ca_ro 组，且权限标识设定为群组可读、不可写、不可运行。

至此，就能确保：
0. 除了 root 以外；
1. 只有 signer 用户能读写运行 acme.sh 脚本；
2. 只有 signer 用户能写 ca 目录及其子文件；
3. 除了 signer 用户以外，所有加入到 ca_ro 群组的用户都能读取 ca 目录及其子文件。

这个社会越来越缺少江湖气息了。很多事情，道义上做足了，有难处大多数人也都是能理解的。

但很多服务从业人员社会经验太少，不会处理人情世故，最终以错误的方式处理问题，引得客户不满。

我个人就不怎么纠结这些事情，凡是都有规矩，按规矩该怎么办就得怎么办，做得好了应该表扬，做错了还不找补就得受到惩罚，自己的问题导致麻烦别人就得道歉，别人满足了自己额外的要求就得道谢。对人对己都是这样。

在过去，如何做好服务行业是门学问，从业人员都是个顶个的人精，不这样就肯定会饿死。

国外很多游戏会一定程度上复刻一些城市，比如纽约、芝加哥就曾经被高度复刻到游戏中。

国内政策风险很高，就连 LBS 的游戏都没有，更别说建模了，所以大概率不会出现，除非 ZF 牵头搞。

只要不要求跟现实一致的话，很多游戏都可以看风景，特别是开放性地图的游戏，虽然很多游戏有主线，但你不做任务也是可以到处逛的，像塞尔达就有一个梗就是国王说：“别整天瞎逛旅游、捡蘑菇炸鱼烧菜、砍树放火了，救救我的女儿好不好？！”我玩的时候反正经常是啥任务都不做，就到处旅游看风景。

比较模拟生活的有个游戏叫 Second Life，但我没玩过，题主可以了解一下。

@blessingsi #18

上一个回复主要是想表达 Wayland/XWayland 在集成度高的发行版上被调教得体验还不错，而且也用了很多年了，所以个人感受是 Wayland 已经比较成熟了，可以去看看其他发行版是否已经有现成的解决方案了，再看是否可以借鉴于调配自己的环境；当然很多软件成熟应用之后也会有那么几个问题常年得不到解决，这算是 FOSS 界常见的情况了吧。

主流 Linux 发行版底层都是那些东西，比如 wayland 都是那个 wayland，只不过可能版本、配置不一样，以及个别可能打了定制 patch，你只要吃透了不管什么发行版上的问题都很容易解决。

下面有点跑题了：

另一方面来看，不同发行版解决问题的方式是不一样的，一种是在上游发行版维护的时候就由维护团队做好解决和避免问题的工作了，另一种是在下游实际使用的时候由用户自行解决和避免问题。Arch 属于后者，集成度很低，维护团队只在 Kernel 上维护一个最基础的系统环境，用户会按照自己的意愿搭建应用环境，自然也就只能自行解决和避免问题。

不同人的感受可能有区别，我曾经用 Arch 五六年的时间，依照我自己的体验来说由于 Arch 不同用户的规划和调配会有区别，每隔一段时间就可能会“滚挂”，一个升级不可能在所有可能性上测试，所以“滚挂”是一直存在的风险，只是可能频率不会太高，比如不管大问题还是小问题，我一年可能就会遇到一两次需要去解决。
现在做生产工具的话，其实有些疲于被更新带来的新问题而打断工作，不更新又会使未来滚挂的概率更高，所以索性去找一些维护团队调配好的、集成度高的发行版用了。

如果不用做生产工具，我还是会首选 Arch 。

@yezheyu #25 总体数据量会变多，但是有些协议可以分割数据包，使得单个包的大小维持在一个尺寸，但包的数量增多了；也有的协议会有一些压缩方案，使得整体传输的数据量不会多出太多。

分割数据包可以不考虑数据包的结构，可以简单粗暴把整个数据包的数据切成几份，然后新加一层给每一份重新包一个数据包，到目的地后拆包直接拼起来就是原来那个数据包了。

当然实际上各种协议有自己的奇淫技巧来解决各种问题。

网络协议的本质就包的嵌套，一层包套一层包，每一层都有自己的元数据和载荷数据。

TCP 这一层，有 TCP 自己的元数据，告诉你这是个 TCP 包，来源和目标的 IP 、端口，以及长度之类的信息，对这一层来说，载荷就只是一坨数据而已，没有特殊意义；
TLS 这一层，就是 TCP 的那坨载荷，有 TLS 自己的元数据，告诉你这是个 TLS 包，还有协议版本、目的地域、加密算法名称啥的，对于这一层来说，载荷就只是一坨数据而已，没有特殊意义；
HTTP 这一层，就是 TLS 的那坨载荷，有 HTTP 自己的元数据（ header ），载荷就是你实际传输的 body 之类的。

不要混着看，因为比如路由器在处理 TCP 数据包的时候压根不会关心载荷里是啥东西，它只关心元数据，并把载荷原样传给目的地设备；
浏览器的 TLS 程序也只关心 TLS 本身的元数据，顶多会对载荷进行解密，然后把解密后的数据给浏览器的 HTTP 程序。

这个问题不应该是 XX 语言要不要写 DAO，而是当前的项目情况上来评估加一层 DAO 是否有收益。

Java 的开发者群体是极其庞大的，也同时是良莠不齐的，很多水平不高的 Java 工程师习惯在各种项目上套用相同的架构，真正的架构师回去评估系统特点以及架构设计上的收益和成本。

架构上的思想都是工具，能在特定场景解决特定问题，所以不管用什么语言、框架，只要觉得某个架构思想适合用来解决问题，就可以拿来用。但同时，工具不是用来制造问题的，所以如果用起来会徒增成本，那么就没必要硬上。

基础学习得上课。

主要是实战，可以试试在 VRChat （没有 VR 也可以玩）上跟老外吹水。