我看不懂。。

问了下 GPT："他想表达的意思可能是，现在的科技和社会发展很快，很多东西都在不断地创新和改变，就像蚊帐这样一个看似简单的东西，也有了自带支架的功能，可以方便地搭建和收纳。他认为，人们也要跟上时代的步伐，不断地学习和进步，否则就会被淘汰和落后。"

所以我才楼主是想说 "自己没见识过带支架的蚊帐"？

EXIF 就是干这个的，除了拍摄时间还有 GPS 信息、镜头光圈之类的各种数据，你总不至于都要加开关写到图片上吧？
说白了就是 "照片加时间戳水印" 这个是伪需求，而且对照片数据是破坏性、不可恢复的。
如果你的需求只是查看照片拍摄时间，那现在 iOS 看照片时，向上滑动半屏就有了。

@gauzung EXIF 你压缩或者裁剪调色同样不会丢失，除非你是刻意抹去 EXIF 信息。
但你要把时间写做水印放到图片上，那缩小或者裁剪照样也会丢失。

一次性付费 $99 ，上架，之后就一直可用了，即使一年后开发者过期也能用

长期观看短视频会影响注意力和短期记忆，以至于严重时对电影这种慢节奏长视频感到无趣。
可以搜一下 "TikTok brain"，有不少相关研究。

https://m.weibo.cn/status/4892506347014260
可以参考陶哲轩的思路。你知道你自己去搜内容也会出错，那当然也要明白 GPT 也会出错，所以你可以把它当作一个思维发散模式来用。就像福尔摩斯会和华生聊天，华生的话不一定是正确的，但能启发福尔摩斯发现真相。

这个新版搜索我极其不爽
Code 搜索时按时间排序的功能被去掉了
Issues 搜索按 Update 排序，结果一大就会挂掉

主要是历史原因，最初的 K&R 版本的 C 还不支持 enum 。
后来 ANSI C 也没明确 enum 的长度，而是可以由编译器决定。
另外如果常量是 flag ，需要用 or 来连接的话，用 enum 也不合适。

图灵奖得主 LeCun 也在质疑，然后提了个问题： https://twitter.com/ylecun/status/1639696127132835840
7 个齿轮连在一起，顺时针转动 3 个齿轮时，第 7 个齿轮怎么转。
这个有人问了 ChatGPT 结果正确答上来了。

然后 LeCun 怀疑，这可能是他的问题被 GPT 索引了，然后他又提出了一个全新的问题： https://twitter.com/ylecun/status/1639690596364308482
7 个齿轮首尾连成环，顺时针转动第 3 个时，第 7 个怎么转。
有人向 GPT-4 问这个问题，一开始答错了，但是告诉 GPT-4 要一步步思考，GPT-4 就能推断出齿轮是被卡住，不能被转动的。

这至少说明它能表现出一定的逻辑推理能力，并不是单纯所谓 "搜索引擎+语义理解"

https://github.com/opencv/opencv_contrib/pull/3480 这里有人修复了

https://ys.mihoyo.com/main/news/detail/545
米哈游的原话是 “学习先进技术，从而把更好的游戏体验，以更低的进入门槛，带给更多的玩家。这是米哈游做游戏的一贯宗旨。”

翻译一下，米哈游的宗旨就是去主机游戏之类的门槛高的地方，把好的东西抄过来，然后给手游玩家玩。
那这确实做到了。

https://github.com/othneildrew/Best-README-Template
https://github.com/matiassingers/awesome-readme
多看看，选一些自己喜欢的模仿一下，没内容就就让 GPT 帮一下

人人网，当年有社交有视频有 IM ，结果一地鸡毛

@Jack1230 #17 把 "项目" 换成 "哥哥"，这就是一个标准粉圈评论了。。。

iOS 动态图片实际上就是一张 jpg + 一个 mov ，没什么特殊的。
楼主可以发个小米的实际样张大家分析一下。

@lesismal 先回复几个问题：

我提 UTF-8 校验说的是 string 类型的值，内部编码是 UTF-8 ，如果为了安全考虑是要做校验的。json 可以预先整个输入都校验一遍，而二进制格式需要解析出来每个 string 值之后再一一校验，不是说二进制就不考虑校验了。

simd 的支持现在都是动态派发的，就是运行时检测一次 cpuid 判断指令集，avx512 进几代 CPU 都是不降频的，不降频时才会用 avx512 ，否则还是 avx256 或继续降级，所以这个不用担心。没有 UB 的代码一般 O3 没问题，即使 O2 也相差不大。但这些都是细节，不重要。json/msgspec 性能对比其实也只能这样简单搞搞，实际应用里如果要转为用户定义的结构或者对象，耗时大头其实是在对象创建上。真要是自己用的服务又在乎性能，在 C/C++ 应用里 flatbuffer 和 capnproto 更合适，至少比自己 struct 序列化要靠谱，现在很多游戏也在用。

我认同你的后面的观点，这是市场占有率的问题。一个标准即使性能上烂，但流行到这种地步就会有越来越多的高手投入到这里来，做性能优化、做生态支持。但是一个标准用的人少，即使设计优秀，也很难吸引足够人才投入其中。

@duke807
我没看出你对 simd 或者其他数据传输格式有了解。你非要数据那我就跑一下。
以最常见的 twitter.json 作为测试数据 https://github.com/simdjson/simdjson/tree/master/jsonexamples

体积：相差并不大
json: 467KB
msgpack: 402KB

在手头 M1 上跑 simdjson 和 msgpack-c 来解析，循环 16 次
simd:dom: 759MB/s
simd:ondemand: 1604MB/s
msgpack-c: 948MB/s
msgpack 并没有明显优势，而且也没验证 UTF-8 编码。
另外如果 simdjson 在现代 x86 上跑的更快。

json 缺点一大堆，唯一最大的优点就是人类可读写，msgpack 并没有继承这个优点。

之前有段时间在 solidot 上看到过好几次凹语言的推荐，每次都要强调凹读 wa ，但我每次看到还是会下意识读成 ao 。

@duke807 看来你不明白 simd 是怎么工作的。。simd 在处理较长数据时才会优势显著，如果你把字符串拆分出来，再用 simd 校验每个字符串，就会因为需要额外对齐或者数据过短无法向量化导致性能甚至会下降的。

回头再来看看我们讨论的适用场景：如果你是对外的服务提供者，无论是为前后端还是客户端，那明智的选择是尽可能为`更多人`服务，用 json 是毫无疑问的。所谓小众格式说的并非是没人用，而是 json 已经是事实标准、占据统治地位，其他格式的支持程序、系统生态根本不在一个量级上。

如果你是给自己的系统选择数据传输格式，追修更高读写性能和更小流量，那还有 flatbuffer 和 capn proto 等所谓 0 解码耗时的 zero-copy 方案。选择 msgpack 更多的是那些过去 json 带来的惯性，并不是什么追新。

@duke807 接口方面，你不可能要求后端同学花费力气去专门为小众需求单独开发一个接口。而且即使对齐到 json 格式的话，支持多种格式也需要后端单独做开发和测试，这和运维同学改改 nginx 配置完全不是一个工作量。

我觉得性能方面你想当然了。simdjson 能用 simd 快速教研整个 json 的 UTF-8 编码，实际上现在解析速度也能达到 3GB/s ，甚至还能按需解析性能还会更高。msgpack 里面的字符串也是 UTF-8 的，但我没见有什么库愿意去写 simd 加速或者按需解析的。

如果你把应用范围限定在嵌入式，那和上面我们讨论的完全不是一回事儿了，性能又不是主要考虑的东西。如果你说没有 malloc ，那就算用 JSON 库也有很多允许自定义 allocator 或者自带 fixed memory allocation 功能的库，这完全没问题。