我也不太喜欢 systemd 。这个东西庞大、复杂，并且不是很用户友好。不同模块的加载时间，配置文件目录结构， unit 之间的依赖管理， service 重启的控制，日志采集，任务类型等等都和原来的系统会有差别。

不过复杂和不友好的程度还在可以接受的范围内。而且文档虽然不是最佳，起码是很全的，分散在很多个 man page 里面。

但是启动进程这个东西，最重要的是统一了就好。不要再出现 sysv init, upstart, systemd 的三国分立局面。过个几年用惯了，坑都踩过了，特性都熟悉了，就会开始喜欢了。

>> 即使没打猴子布丁也不能说没有了一点 gevent 的作用了吧，打上了，只是将 python 里的很多调用改成了携程方式而已……不知道我的理解对不对

@qwer1234asdf 这个程序主要的阻塞就是在 requests.get()，这里没有做 monkey patching 等同于整个程序是同步的。你可以把正确实现的版本，使用 monkey patching 和不使用，执行时间做一个对比。取决于你的网络状况和使用的 gevent 线程数，使用 monkey patching 的版本应该快好几倍。

在 gevent, tornado 这种基于 coroutine 的异步机制下，只要一个严重耗时的地方阻塞，其它地方不阻塞就失去意义了，因为所有代码都是在一个 OS 级别的 thread 来执行的。

>> 文档也声明猴子布丁是 evil 的 以及你的数据库问题

gevent 不是万能的。测试其它软件库和 gevent 的兼容性是软件作者的责任。如果同时使用 gevent 和数据库，就要用支持 gevent 的数据库连接资源池。这些在 gevent 文档或者示范代码里面有。

>> 最后，我以为，楼主这种方式，携程的粒度比较大

这个我就不回复了，如果要讨论颗粒度，你先把正确代码摆出来再讨论比较好。

>> 觉得 test 的 log 输出可读性不强（特指出现错误 case 的时候，不能一眼看过去就知道流程中哪个点出了问题）

@laoyur IDE 都是直接跳转到出错的那个 assert ，并且显示对应的 expect value 和 real value 。不知道你说的一眼看过去不容易看出哪个点是什么意思。实际做 TDD 的时候，通常都直接看错误的 assert 的代码行，不会去着重看测试名称的。

看到好几个问题：

1. 为什么要自己写 Queue ，不用 gevent.pool?
2. 为什么用了 reqeusts 但是没有做 monkey patching ？这样引入 gevent 的好处全没了。
3. spider() 的 while 循环，队列和 gevent thread 的使用，这里是一团糟。

如果只是为了功能，建议全部用 gevent.pool 重写。如果想自己学着用 blocking queue ，需要先继续学习，然后重写。可以多看看别人的代码。学习内容不需要局限在 python 和 gevent. 多线程的东西都是相通的。

流程性的东西，放到同一个 test case 里面做 setup 和 assert 。比如，如果我注册了一个用户，那么它应该可以正常登录。如果我发布了一条信息，那么应该能查询到这条信息。如果我删除了一条信息，那么应该无法查询到该信息。

不同的测试之间可以共享测试数据（比如用户名，测试消息什么的）和 setup 代码（比如创建一组用户和数据用于测试），但是不要让不同的测试场景和测试用例互相依赖。互相依赖的测试，一旦有错误，无法准确定位问题。牵一发而动全身。对开发和测试都不好。

@CuminLo 如果原来的软件自己没有带 .desktop 文件，可以在打包前自己写一个，然后放到系统级别的能识别的目录，比如 $DEST/usr/share/applications/smartgit.desktop 。.desktop 文件是文本格式的，格式也简单，一看就会。

>> 带有图标的怎么弄？ fpm 打包之后安装图标不能显示，有办法解决么

@CuminLo 什么程序的图标？ rpm/deb 都是默认图标的，应该不能自定义。
安装好之后 app 自己的桌面图标一般是写 .desktop 文件。 app 自己的图标，这是 GUI 框架里面写好的。

1 3 这些框架都可以满足要求。 2 不犯错需要经验，基本上没有框架是没有坑的，只是挖坑的地方不同而已。
小项目不用担心犯严重错误，大不了重写嘛。小项目，业务逻辑写好了，换框架不费事。

推荐 flask 或者 bottle.
原因：轻量级，项目在持续维护，结构简单，性能可靠。

django 由于重量级，以及这个项目不需要 SQL 类型的 ORM ，也不需要模板渲染和相关的辅助工具，系统复杂带来的学习成本，不做考虑。
web.py 自从原作者前些年不幸去世之后，项目维护和发展不及 flask 和 bottle. 所以从文档和性能调优方面来看，不推荐。

如果追求性能 bottle + gevent 或者 bottle + uwsgi 挺靠谱的。
如果喜欢各种集成， flask 对周边东西的集成比 bottle 多一些。用 bottle 需要你自己比较懂 web ， flask 即使不懂也可以开始用别人写好的一些东西。

>> 嗯，晚上回家尝试用 PE 修复下，启动软件放在 U 盘里，然后从 U 盘启动，检测修复硬盘对吧？


@Arrowing 不是把启动软件放 U 盘。是把可以启动的磁盘镜像（一般是 iso 或者 img 格式）写到 U 盘，都是用专用工具来制作的。在资源管理器复制是不行的。

如果用 PE 启动，启动之后直接在资源管理器就能看到本地所有磁盘。如果看不到，就直接关机吧。不要自己尝试任何修复软件，基本都不靠谱。对于不熟悉的人，如果操作失误，很容易造成数据丢失。

两块硬盘同时坏的几率还是很小的。如果只是启动不了，这个很好办。先用光盘或者 U 盘启动，看看硬盘挂载是否正常。硬盘上的数据是否正常。 Windows PE 和很多 live linux 都可以做这件事。

如果文件安好，只要修复引导器，或者操作系统，或者系统的其它硬件（ SATA 接口，供电, BIOS 设置等等）就行。

====

如果判断到硬盘已经出现复杂的逻辑故障或者物理故障，还是拿给更专业的人去看吧。自己分析和修复的过程中已经可能造成二次损坏。至于是否能修复，要花多少钱，只有分析后才能判断。

如果里面数据值很多钱，可以考虑花钱修复。如果不是，还是吸取经验教训，从今天开始就对重要数据做备份吧。

数据修复领域，便宜不止是没好货，而且如果乱修把你的数据弄坏了你也不会知道。

@nifury 修改后有没有 kill 掉已经启动的 dhclient 进程？不 kill 应该不生效的。

PHP 不会过时，太亲民了。草根王者。只是没有最热的时候(差不多是 2000 年左右？)那么风光罢了。

像 blog, CMS (content management system), 论坛，基本上都是 PHP 写的最多，用户数最多，相关插件最多。但是具体说每个产品品质怎么样，就仁者见仁、智者见智了。

现在 web 开发的选择实在太多了。这些主流的 php/java/ruby/python/node 选谁都没有错。还有小众一些的 erlang/elixir/C++ 也完全没有问题。

另外一个参考
http://superuser.com/questions/725935/default-route-in-debian-with-two-interfaces

/etc/dhcp/dhclient.conf 添加

interface eth0 {
supersede routers ""
}

表示忽略来自 eth0 的 DHCP 里面的 gateway 信息。

如果确认删除了会自动回来， eth0 设置 static ，手动配置 IP 和 netmask 吧，不写 gateway 就行了。

eth0 只连了内网，不需要这个默认路由啊。删掉这个试试：

ip r del default via 172.17.128.2 dev eth0

如果是浏览器客户端，前端必须支持编译到 JavaScript 才能在浏览器执行, 所以能够做到的语言不多。我知道的能在生产环境用的只有 JavaScript 和非常相关的替代比如 coffee script 和 typescript ，以及 clojurescript.

如果前端是 app 或者桌面应用，可以前后端用同一种语言开发。这样就可以用共享库 /模块的方式 share 代码。只要把校验这部分代码分割出来成为独立模块就好。

问问题的时候还是多给些上下文比较好。核心思路都是在前端和后端用同一种语言。当初 node.js 兴起的时候，这个是一大卖点。

代码格式乱掉了，基本没法看。重新排版一下吧。

一般输出两次是配置问题，在子 logger 配置中，如果不希望上游的 logger 继续收到并处理该日志，需要设置 propagate=0.

根 logger 是空字符串"", 子 logger 就是 "a.b.c"这种。一般第三方库都会用子 logger 。但是你没有点名，所以不能确定。如果真的是用的 root logger ，那除非是配置了两个 console 类型的 handler ，才会输出两次。

@skydiver 就是就是。除非你还有很多个这样的文件，或者你是闲得慌的 DBA ，不然秒级别的导入根本不需要优化。

同意上面多线程可能更慢的说法。

另外性能调优不要看感觉。 CPU ，内存， IO 这些都有工具可以测量他们的实际负载情况 (top, vmstat, iostat)。

@CarlWangCn 官方新版已经支持了。官方没支持之前也有第三方发布的支持 python 3 的库。 bytes 和 str 分离对 protocol buffer 是更有利了，这个库本身支持 python 3 本来也不难。

https://github.com/google/protobuf/issues/7
https://pypi.python.org/pypi/protobuf/3.0.0b2