Azure 一切正常

@shijingshijing 这个比喻显然不对，你买了山寨的「哇哈哈」是因为以为他是「娃哈哈」才买的，结果买来一看不对啊这是山寨的；你买「小米 8 」显然不是因为把它当成了「 iPhone 」买的。

@alwayshere 「独特且强悍的 JavaScript 算法」这是网站上写的，不是我编的。HTML 5 缩放一张图片就两行代码的事情，拿到 Image 改个长宽两行赋值语句就行了，这也能拿来另外说？莫非出了钱的同学是看中了它具有两行代码可以实现的图片缩放功能而不是「其压缩表现要远好于常规的压缩软件如：jpegoptim，jpegtran，jpegrescan 和 jpegmini 」的压缩？

@Reign emscripten 是对编译后的文件进行变换使得它可以运行在 JavaScript 虚拟机上，属于再发布，因此需要在发布出来的文档、版权声明或发布出来的源代码中包含原 BSD 协议。老老实实写明基于 mozjpeg 实现压缩，自己就是封装了个界面和接口，有些人懒得花时间配 mozjpeg 作者收收钱也不算差，偏要宣传得像是自己掌握了核心科技贩卖算法，利用信息不对称尽可能多地收税，看不下去一定要指出。

@Reign 请作者先解释一下自己直接使用 MozJPEG （使用 emscripten 转编译到 JavaScript ），违反 BSD 协议不写 Copyright、声称「独特且强悍的 JavaScript 算法」并拿来收费的行为？

证据 1，mozjpeg 包含 debug 参数，作者连改改都懒，于是 picdiet.js 也可以直接输出 mozjpeg 的 debug 信息

> picdiet([], { debug: 1 })

Error: No output: mozjpeg version 3.1 (build 20160620)Copyright (C) 1991-2012 Thomas G. Lane, Guido VollbedingCopyright (C) 1999-2006 MIYASAKA MasaruCopyright (C) 2009 Pierre Ossman for Cendio ABCopyright (C) 2009-2014 D. R. CommanderCopyright (C) 2009-2011 Nokia Corporation and/or its subsidiary(-ies)Copyright (C) 2014 Mozilla CorporationCopyright (C) 2013-2014 MIPS Technologies, Inc.Copyright (C) 2013 Linaro LimitedEmulating The Independent JPEG Group's software, version 6b 27-Mar-1998./this.program: only one input fileusage: ./this.program [switches] [inputfile]Switches (names may be abbreviated): -quality N[,...] Compression quality (0..100; 5-95 is useful range) -grayscale Create monochrome JPEG file -rgb Create RGB JPEG file -optimize Optimize Huffman table (smaller file, but slow compression, enabled by default) -progressive .......

证据 2，代码中入口函数「 var cjpeg = ……」这是使用 emscripten 对 https://github.com/mozilla/mozjpeg/blob/master/cjpeg.c 转化的痕迹，作者同样也是懒得修改…

证据 3，可以直接对比 picdiet.js 代码与其他人用 emscripten 编译 mozjpeg 产生文件的结果，例如这个项目 https://github.com/as-com/mozjpeg-js 可以发现几乎所有的浮点 magic number 都是一致的，以及一致的 magic number 所处的函数结构和流程也都是一模一样（ ps：后者使用了较新的编译工具链有循环展开，因此代码结构不完全一致）

https://imgur.com/pQd6OSz

https://imgur.com/TC6Bcql

https://imgur.com/jGiA41L

@miniyao 首先你要知道 mp4 只是一个容器，容器内视频编码算法才是核心。视频编码算法一般是 h264, h265, vp8, vp9 这些。所以首先需要基于编码速度的考虑？解码速度的考虑？解码兼容性的考虑？等因素选择一个视频编码算法。一般来说 h264 是最常见的，移动设备支持很完备，而近几年来最新的算法是 h265，效果比 h264 更好，但编码时间、兼容性也会更差一些。vp8、vp9 类似。这个选完之后，才是选择什么库的问题。如果选 h264 算法的话，最好的编码器是 x264，也就是上一条说的。h265、vp8、vp9 也有对应的比较好的编码器。但要知道，对于同一个算法，所谓编码器的好坏，基本就是支持不同 profile 的层次以及实现出来的性能区别而已了，算法既然是同一个那么编码出来的结果应当是近似的。

最好的 c 库是 x264，然后 ffmpeg 支持 x264，这个方向找 python binding 就行

RocksDB 自己有 WAL，不使用这个 WAL 而是自己实现一个 SegmentedLog 有什么优势吗？

浏览器端底层的 socket 是不暴露的，例如你不能使用 http 或 websocket 以外的协议。至于为啥这样做……至少安全性上有这样的要求。

@est 如果业务是 py 写的，不想再单独起一个 nodejs renderer server 做个 proxy，而是直接在服务端集成的话，用 py 跑 js 就挺合理的。还可以参见 react 官方的 asp.net server renderer，也是跑了个 js engine

谷歌做了多少放卫星的事情作为谷粉还不清楚吗？

楼上要求公开身份证的逻辑也是厉害，一个行为是留下永久的公开的可复制的电子档案一个行为是一个人看一眼，根本不是一个性质的行为；还有对待不同人的信任级别当然也是不一样的。

是个正常人都知道需要证明自己是自己的时候使用身份证证明是合理的，在不需要证明自己是自己的时候需要避免身份证明泄露被别人冒用。

楼主这不典型的喷吗？请先列举一下你觉得不好的地方。

@mritd 系统有了 py3 还需要下个 py2 的原因心里还不清楚吗 :) 这两货又不通用。当然，blame node-gyp 没有升级到 py3。

off-cpu 火焰图看一下

还不如知乎上直接私信 MS Office 员工

@bao3 更正一下，50 个上海还差不多

先把证书发出来

goland 也只能跳到内置函数的声明吧。。看不到实现的