@pubby 感谢，这个解释可能说明了一些问题。

按我理解，现在这种应用应当存在两种情况：

第一种：Python 程序打开 FIFO 读，有另外的程序打开 FIFO 写，并且没有写完，此时读取文件在默认（阻塞）条件下会阻塞。但是如果以非阻塞模式打开文件读会怎么样呢？（待实验，是否出现 EAGAIN/EWOULDBLOCK？）

第二种：Python 程序打开 FIFO 读，已经有程序打开过 FIFO 写并关闭了文件，此时一直读取文件一定会碰到 EOF，之后再以任何方式读取 FIFO 就像是读取普通文件遇到文件末尾后继续读返回空字符串那样返回了空字符串而非阻塞。是这样吗？如果以非阻塞方式打开文件读又会如何？（待实验）

@akira 使用非阻塞方式，是在 Python 程序中以非阻塞方式打开文件读吗？我觉得并不符合情景要求，因为任何情况下 read 都会立刻返回。

@pubby 不是很想通过轮询的方式判断有没有数据，占用 CPU 时间有点多

@yuelang85 实际上想实现的目的是读取到末尾管道中没有数据时，readline 函数因为没有输入又没有遇到 EOF 而阻塞，直到管道中又有数据输入，有换行符为止而使 readline 函数返回该行数据。就像是 shell 中

cat /tmp/myfifo

时阻塞住的情况，而不要在没数据时返回空字符串。

open() 放在循环外面是因为打开文件只需要一次，本来就不需要多次调用 open()。

LUG@USTC 的前来冒泡，简单说一下个人体会：

* 要保证新老更替，简单来说就是每年能招到新人，长江后浪推前浪
* 毕业学长一定要保持联系，可以为后人进行指导
* 和学校网络部门多联系，争取资源或者项目
* 自身学业或技术或能力至少一项要拿得出手
* 注册成为社团，构思各种活动吸引同学们甚至老师们参加

现在科大 LUG 处在良性循环中，活动十多年，建社团十几年，IT界学长积累不少，最近帝都聚餐就来了5、6个，都是宝贵的资源与友情积淀，甚至学校网络中心和教师也有当年LUG的人。可能走下来并不容易，但如果能坚持，前途一定是光明的。

感觉还是硬件不一样的问题，我这里 Ubuntu + KDE 装了两三年，怎么折腾都不会崩。同样 15.04。
另外，同时作为 Arch 用户和 Debian testing 用户，表示不是服务器的话就应该跟随主流最新版本。

今晚不睡，干活中

如果可以的话请不要使用"中科大 DNS"的表述方式，这个所谓的DNS与中科大网络信息中心没有直接关系，容易引起歧义。

把启动参数里面的 quiet splash $vt_handoff 之类的参数去掉（主要是前两个）再启动看看控制台输出

另外可以翻系统日志找原因

感谢大家的支持，我们还在努力修复中…

另外大家不要太看重这个 DNS 服务，毕竟不是学校的服务器，稳定性没有保证的，希望不要影响大家的正常工作

@datocp 绿色守护还是很有用的，停止后台进程，唤醒路径追踪与切断，合并唤醒，GCM 推送唤醒与通信唤醒，是对付各种全家流氓应用（某宝）和省电的利器

@Love4Taylor 看来你不熟悉 debian 环境啊，apt-mark 可解决问题

如果硬件支持好，Debian testing 和 Arch 都不错。如果有奇葩硬件，还是 Ubuntu

新版是需要发的，开源社区特性决定它不太可能像以前的巨硬那样几年憋一个大版本；如果一直不发新版，更有可能是项目死掉了。

另一个原因是技术迭代比较快，需要新版本跟上步伐。

其实还是和发行版选择有关。如果你选了 LTS，那么新版就应该和你无关。新版照样发，你照样用就是了。

Freenode:

#ubuntu-cn
#archlinuxcn
##Orz
#fcitx
#tuna

202.38.64.1
202.38.64.17
202.38.64.56
2001:da8:d800::1

其实不实用，因为Google做过特殊处理，而且对CDN得到的都是教育网IP

无意中翻到了这个节点，报个到

小透明喵服玩家冒泡