我绝对不会让 V2EX 的页面上出现一堆彩色的 icon。

他用的是 Fedora，如果有兴趣，可以尝试一下：

http://fedorasolved.org/Members/jmontleon/installing-fedora-16-on-macbooks-using-grub2-efi

AeroFS 也不错：

https://www.aerofs.com/

下单快一周了，现在还是显示 pending。

Player base is too small.

不算什么高端型号，属于那种用坏了丢了也不可惜的类型。

之前家里的 AirPort Express 坏了，于是就入了这个。用了一段时间觉得还可以，就把链接放上来了。

Safari 的问题，只能等。

目前确实不够明显。

希望这个你可以参考一下：

http://bjango.com/mac/istatmenus/

@adamwen 和主站放到一起的好处就是尽量复用代码，比如 data models 操作相关的那些。

如果单独为 rq/celery 写 tasks，那么很多 HTTP 环境里的上下文可能都没法用。

@yaotian 我是这样做的：

1. 通过 supervisord 管理启动的 instances，每个一个端口，比如 30000-30009 是前段端口，30010-30019 是后端端口。

2. 在 nginx 里把 30000-30009 做成前端的 upstream，30010-30019 是后端的 upstream。nginx 支持 least_conn 方式的负载均衡。

3. 然后通过 nginx 的 allow/deny 规则让后端 upstream 只能通过 127.0.0.1 访问。

4. 在 Tornado 里通过 rq 去 call 后端的那个域名。

@yaotian 这就是为什么要在两个端口启动 _至少_ 两个 instance 的原因。

我的某个项目中，Tornado 框架，12 个读 instance，12 个写 instance，通过 least connection 方式做 load balance。

启动至少两个 instance，在不同的端口。绑定 80 的那个用于所有读操作，另外一个用于这样的耗时操作。

通过 queue 去 call 另外一个。

PIL