问你的业务逻辑，不要问性能
业务逻辑等价的话，用后者（如果语言支持的话， switch case 更佳）
不等价的话，你这个问题还有提问的必要吗

linux 的 samba 不是文件服务器吗，帐号系统一般来自于 AD 。你是指 samba 内置的 ldb 吧，还是说 openldap? 那东西不太适合生产使用吧

理论的最优解的话当然是 Long.toString(id, 62 或 52)，要求数字可以超过 64bit 的话可以用 bigdecimal

@donghui #17 去掉最后一个 --ignore-date 和 rebase -i 上选择了 pick, squash, squash, squash 是完全等价的

能说一下具体细节吗？以及为什么 Google 登录不受影响？

看了上层发现原来 V2EX 对新浪图床的识别支持是精确到主机名的，测试一下

http://ww2.sinaimg.cn/large/9542bb84ly1fd8mchk6kij20go0m8djy.jpg

说错，是 node -p 不是 -r

应该很简单吧，直接用 shell workflow 执行 node -r <输入的剩余内容> 把结果回显到菜单区域，麻烦的是如果要考虑多行显示的话怎么优化的问题

a1 a2 a3 a4

git reset --soft a1^
git commit -m "a1 ～ a4"

或者
git reset --soft a1
git commit --amend -m "a1 ～ a4" --ignore-date

/go/all4all

标题背锅侠

@haochih #15 这个描述无论是在 BIO NIO 还是 APR 下应该都是正确的， BIO 并不是不能处理高并发， BIO 只是无法处理 keepalive (socket accept 也是专用线程来的不会占用 worker 线程) 以及无法支持 sendfile 而已

@esolve 既然大家不住一个频道上，那就按你想象中的来吧，不再回复了

@esolve 脱离谈响应时间谈并发就是耍流氓，难道你用 nodejs 单线程服务就能解决问题了？好好想想这句话是什么意思。多线程不是让问题更加恶劣，而是缓解问题，如果不存在阻塞（典型的是 IO 阻塞），最简单的多线程模型显然是最优解，所有异步框架都是为了解决阻塞问题的。

@esolve #7 这个结论明显不正确，还是先读一下资料吧，至少先搞懂 BIO / NIO / AJP 几种不同的 io 模型，还有 sendfile 。

对于 BIO 而言，也许是正确的，因为 socket 成了最大的瓶颈。所有其它 IO 模型都是异步模型，超过处理能力的请求只会排队， poller 线程（连接及 header 处理）是独立的； sendfile （比如静态文件）还完全不会占用 worker 线程

这有点难买，而且价格感人，官方的一套也就 4 个键

curl http://www.gsxt.gov.cn/corp-query-custom-geetest-image.gif

[102,117,110,99,116,105,111,110,32,99,104,101,99,107,95,98,114,111,119,115,101,114,40,100,97,116,97,41,123,32,10,32,32,32,32,32,108,111,99,97,116,105,111,110,95,105,110,102,111,32,61,32,100,97,116,97,46,118,97,108,117,101,32,94,32,53,51,54,56,55,48,57,49,49,10,125,32,10,108,111,99,97,116,105,111,110,95,105,110,102,111,32,61,32,52,57,48,57,52,50,49,48,56,52,59]

curl http://www.gsxt.gov.cn/corp-query-custom-geetest-image.gif | node -p 'JSON.parse(fs.readFileSync(0, "utf8")).map(x=>String.fromCharCode(x)).join("”)'

function check_browser(data){
location_info = data.value ^ 536870911
}
location_info = 4909421084;

现在政府网站也玩这无聊的一手？

想把这两个文件存到 github 上，怎么办？在线等，急！

你晚上想起报社的时候吃掉不行吗