#include <humanity>

1. 无论从协议还是法律上，部署副本站都不违法、不违反协议
2. 从道德上，作者使用 MIT 协议开放授权，即应代表他接受大家任意使用他的劳动成果

但是！！！ 重点来了

3. 从协议本身来说，在镜像站放自己的群导流或收款码赞助等，不违反协议，但从法律上来说，这属于未经作者授权擅自对原作进行「演绎」/「修改」。如果法律不承认开源协议而只使用著作权法，那么给自己的群或站点导流的行为是可以构成侵权的。
4. MIT 规定了软件的文档属于软件的一部分，与源码有相同的开放性和授权，意即同时放弃文档和源码的 COPYRIGHT 独占性。但是！！ 大多数开源协议都是欧美法系下拟定的，描述的 COPYRIGHT 跟国内的著作权并不完全一回事。相比之下，CC 知识共享许可协议在各国法系下都有自己的本地化版本，在国内也有与国内著作权法相适配的版本，能更好的受法律保护。在 CC 中「演绎」（即修改）是单独的授权项目，相比于粗略的开放源代码协议，CC 用于开放文档的授权要准确且合适很多。为避免以上场景产生扯皮，请以后使用 CC 授权文档

…… wsl.

大胆一点，快进到产品包一个有后门的浏览器

如果要想学一些新语言，那必须要多接触一些不一样的范式。C 系语言无论生了几个孙子，跟它们的爷爷长得都差不多。

但是

Haskell

当真是开了一扇新世界大门，强烈推荐系统地学习一遍。或者 racket/Lisp 也可以。这些函数式语言一下拓宽了我对编程这件事一倍的视野，可以说又重新学了一遍编程，与那些脚本语言根本不可同日而语

@frankkly 杭州是阿里大本营，市政金融都有阿里分一腿。如果路上红灯堵得你不耐烦，很可能甚至都是阿里干的

啊……？ 我似乎知道有些番剧和电影评论区的上帝视角是怎么来的了

快进看完也叫看完……？那我何必看这要浪费我时间的东西呢


@NanJi
> 比图推荐好用的工具 25 个什么的那种

哈哈哈这种东西我一般直奔评论区，没有省流助手就直接不看了

如果你是消费者，开发商说他们的产品「轻量级」，意味着功能不全。

如果你是开发商，消费者说他想寻找「轻量级」产品，意味着他不想让你盈利

如果你是开发商，告诉消费者你做的产品「轻量级」，意味着你暂时服务不了其它人，得想办法让已有的用户掏钱

如果你是开发者，另一个开发者说他做的框架「轻量级」，意味着他造了个新轮子，木头的，不能装在汽车上

如果你是开发者，想做一个「轻量级」框架 —— 醒醒，你一个人本来也做不出重量级框架，这是安慰别人用的废话

@yezheyu 就是因为如果不限制分片 /分包的大小重传代价会很大所以才会限制最大单元。在最大范围内随便什么大小，超过范围强制拆分。

实现上需要对「频繁拆分导致包头冗余造成性能浪费」 vs 「 MTU 过大导致丢包重传压力过大使性能下降」之间进行权衡

@yezheyu 套用的协议层越多，「至少需要的」数据包大小就会越大。

但当一个 2 层套 3 层套 4 层“数据包” 超过「最大盒子大小」（ MTU/MSS ），就会在各协议层重组，分成更小的 fragment/frame，并给每个上层内容重新套一个本层的包头

比如 MTU 是 1K，你尝试发一个 1K 的网页，首先 HTTP 会套上 HTTP 头，写上 content-length: 1k，这样整个报文就超过 1k 了
轮到 TCP 层，它感觉一个分片发不完，分成了两个片，一片内容 1k，套上 TCP 头交给链路层，另一片内容比如 100b，套上另一个 TCP 头交给链路层。如果这两个片发出去顺序不对或者丢了一部分，TCP 负责重排重发保证接收完整
链路层，发现第一个片原本 1k 套上 TCP 头又超了 1k，于是划分帧的时候也劈两半，各自套上帧头，然后交给网卡

不过呢，TCP 协议栈在不同 OS 甚至硬件的实现上是有差异的，按照上面的假设一个 1k 内容的东西被劈成了 3 份显然不太科学。所以比如 linux 的协议栈就不像上面说的每层都自己处理一次，而是 23 层在同一块内存处理，一次性分拆好。4 层应用层一般内核就不会越界去管了，但并没有不准在内核实现 HTTP 协议做一个 234 层一起分片的协议栈。

> 本质就是重新规划 tcp 数据报中有效数据载体部分空间是吗

你概念中的那个「载体空间」，是不固定大小的，并不是往一个固定盒子里填更复杂的数据，而是把复杂的数据拿一个更大的盒子装，并且套上更多层

我寻思，一段时间内识别涨跌横，难道不是起点数据和终点数据一拿就完事了吗？

> 手机号 B 日常会用于和公司同事联系。


你们 HR 给猎头的

不提 RAII 的回复其实都可以不用看了

是的大量带 GC 的语言都无法 RAII，他们都必须手动管理资源释放。虽然 golang 之类的语言有 defer，但逻辑跟 RAII 完全不同，是两套思维方式。

他们这些“脚本语言”的做法：



池化（本质上是由分派器管理资源）

依赖注入（本质上是剥离资源申请释放的依赖，放到第三方）

使用 promise/future （本质上是模仿 RAII ）

完全抛弃状态，使用函数式



是不是很熟悉，「设计模式」跟语言特性是有很大相关性的

………… CPU 渲染器是什么鬼提案

他们都被 opengl 吸引了，忘记了这是个 XY Problem
而且 2D 游戏怎么还能扯到 PBR 的


其实游戏引擎（尤其是 2D ）跟图形 API 关系没那么紧密
2D 引擎不知道你考虑的功能有哪些，切图、变换、物理、对象管理？
如果你想写的真的是 2D 引擎，那么考虑问题的顺序应该是 top-down 的，先计划最终能达到什么效果，然后再把每一层的抽象定好，然后在往抽象出来的框架里塞代码。

比如假设我的目标是，没有引擎 UI，用代码来创建对象，没有 UI 系统，没有预设物理，那么我可能至少需要下面这些东西：

- 事件循环（渲染和计算至少要异步化对吧）
- 输入管理器（「游戏操作」和「物理输入」的映射，比如组合键）
- sprite （对象）管理器（切图、对象关系和变换、shader 或材质、包围盒、碰撞检测……）
- 动画管理器（图片组、动画混合）
- 渲染器

每个组件都有很多工作要做，因此强烈建议参考成熟引擎的代码结构，你能一目了然地从文件名就看出需要做什么：
https://github.com/cocos2d/cocos2d-x/tree/v4/cocos/2d

具体到你提到的 opengl/图形 API 上，如果你是自顶而下考虑的，自然会想在渲染器和图形 API 之间抽多一个虚拟层，让引擎本身诸如创建 texture，应用 shader 这些事与具体 API 隔离开。所以具体到图形 API 这一层要考虑的就是

- 怎么（分别用 opengl/dx/vulkan ）画图片
- 怎么（……）正确混合半透明的图片
- 怎么（ ）画文字
- 怎么变换摄像机
- ……

那方向就清晰了，先搞清楚怎么用 opengl 把图画出来，然后就可以开始撸了。如果怕 opengl 要凉，那就用 dx 呗，反正到这一层无论用什么 api 要干的活都是同样的那些而已

很多年前有个问题调查：「忽略所有现实因素最想从事的 3 个职业」

我写的是小提琴家、猎人、纪录片摄影师。

鉴于乐器可以自学，所以我现在最想学的是枪械技能（维修保养、射击）、越野技能（制作绳索工具陷阱、辨识天气、方向、植物、追踪等等）、砍树造房子之类的

仅 gcc 支持捕获列表后的 attribute，
void f(...){[](...)[[,,,]]{[[,,,]];}();}
上面这行去掉了捕获列表后的[[]]，可以在其它编译器中通过

这些[[]]都是 attributes 吗

原来有这么多能放的位置……