牛，还挺准。应该是通过扫描 LICENCE 这样的文件来实现的。

@zhangfan
你的论据是错的。

首先我上面说的是一个问题，而不是反问。其次，即使是一个反问，我也是在下定义，而不是进行评价。

你看，就这件事（当然你看网络上的舆论，很多都是这样，何止这一件）来说，“观众”收到的信息是被限制的：你只看到了一方的信息，另一方却没有。

在这种前提下，提供给你信息的一方有足够的机会去愚弄你，让你进入一个预设。而你呢，因为收到的消息不是“无知的”的，而是“经过仔细筛选的”，很容易会被愚弄。

你可以看一下这文章的宣传其实是反“无知之幕”的，所以你从那个文章中得到的信息越多，离“正义”的结论越远。
https://zh.wikipedia.org/wiki/%E6%97%A0%E7%9F%A5%E4%B9%8B%E5%B9%95

我当然不是在挺某一方，我对 Fenng 之前喷的那些微博观点是一样的。

其实就这件事情最好的方案是他们双方能和解，有错改之，无错加勉。这样其实两方都有良性收获。不过闹剧闹成这样估计难。

作为看客，看看就好了，把这当作是警示甚至是谈资，而不是争论的话题，否则到最后发现你错了，这感受并不是很好（当然，可能有人并不觉得这有什么）。

@cuebyte

If you don't know me, don't judge me. -- Tupac Shakur

@linffang

If you don't know me, don't judge me. -- Tupac Shakur

我不认识 Fenng ，所以我不能评价他。

同时我觉得如果一个人随随便便的在不了解具体事实的前提下就肆意评判他人，这种行为跟一个 Loser 的区别在什么地方？况且很多人的心理只是墙倒众人推，看笑话凑个嘴；又或者是之前自己被他喷，现在有机会报复。这两种心理都是幼稚可笑。

所以还是不要加入这种 Low gut 的街边争议，那么多有意义的事情不去做，非要降低自己的水准掀起大妈口水战何苦呢？

@lincanbin

不要这样说。很多代码之类是非公开的，因此当然看不到。

其实我倒是建议不但要看这个人的技术如何，还要看喷它的人技术如何。比如图上的这几个：
https://github.com/LeoWoooo
https://github.com/dongxu （这个我不确定是不是）

假定这些人跟他级别一样，那么其实他们“技术能力”差的也不远啊。

有些人借机喷只是为了上位，甚至于有一些你无法猜测的、在台面下的原因。不要加入喷，否则跟喷子有什么区别？

互联网用户有两大权利：
1 、能够决定自己能看什么；
2 、能够决定自己能说什么。

很多人没办法达成第 2 条，现在他们要准备放弃第 1 条了。

@Livid

我觉得是因为目前的机制还是不够智能，用一个词来说的话， naive ，非它莫属了。

主要的问题是，现在的程序没办法识别中文符号，所以上文 naive 的周围加了空格，即使是在有逗号的情况下。

我写过一个 PHP 版本的盘古化器，可以配置一些字符让解析器不在指定的文段后加入空格：
https://github.com/raincious/Pangulize

但是上面这个项目写出来之后最大的感受，是这种东西很难满足所有情况，所以要想完美解决真的太难，不太适合强制做。

@programcat 其实正确的回复是这样的：
QQ 当然能被监控，楼主下班前来我办公室一趟。

See:
https://www.v2ex.com/t/244671

Fedora 24 用户来砸场……

@timi Deepin 和 elementary OS 应该是 Linux 界的两个奇葩，因为它们的设计都太好看了，好看到根本不像 Linux 哈哈哈……

不知道为什么 Gnome 啊 KDE 啊那些大厂不改进一下自己的设计，让默认的 Theme 更加有吸引力。 Linux Desktop 现在看起来就像是 5 年前生产出来的 :(

下班前来我办公室一趟。

@chzyer
故事是这样的：楼主原先写了个 1 allocs/op, 16 B/op 的函数。

缺点你也看到了，一个 1 allocs ，同时需要建立很多的[]byte{}来 append ，之后 mallocgc 耗时会比较高。

然后那个函数的执行速度是 190 ns/op 。然后热爱性能的楼主决定优化一下那个函数，让它更快。这个帖子发生在优化后……

@yangff
仍然在消化这些知识。先感谢。

@yangff
棒极了！
BenchmarkCopy-2 5000000 278 ns/op 0 B/op 0 allocs/op
PASS
ok _/home/rain/Develpment/Meta/golang_copy_test 1.682s

不过这就意味着如果我直接去用这样的方法，得手动每 8 个 byte 合并成一个 uint64 ，这也就不见得快了。

但，也奇怪啊，这两个数据尺寸是一样大的，为什么 copy 速度会不一样（ runtime.memmove 的代码是 ASM ，已槽懵）。

@yangff
是这样么？：
data := make([]byte, uint64(4096))
replace := make([]byte, uint64(4050))
但是并没有改善。

@wweir
试了下在 Benchmark 的开始加入
runtime.LockOSThread()
看似没啥效果 :(

看起来跟计算机本身有关系。我决定暂时先把这个问题放一边好了，先把程序写出来然后再看是怎么回事。

@ooonme
能更明确一点么……

@zts1993
震惊，看来如果实在没法修好这个问题，我可以先暂时忽略它。

@wweir
好的，我先研究下这个，感谢。