@jdhao 就算他不赚钱也是不道德的，那叫损人不利己，蠢。你换位思考下就明白了，如果你是优酷，别人搞个软件拦你广告，而你的视频要投入，网络流量要投入，你乐意吗？

就算是个人用户讲道理也不应该主动去拦，你嫌广告多可以不看呀，也可以去其他平台看。又要白票，又要用户体验，不如服务你来提供？

@A388 其实这件事有什么好吵的呢？换位思考一下不就完了嘛：假如你是优酷，你乐意一个软件屏蔽你的广告让在视频、流量上的投入打水漂？所谓己所不欲，勿施于人的道理都不需要讨论。

@barrysn 我可没这么说：如果说个人用户拦截广告的行为也定性为不道德，那之前视频网站做的超前点播、给购买会员的用户加广告 就道德了？

只要还是要看服务条款吧：

如果人家承诺无广告还给你加，那就不是道德问题了，按我理解应该算违约。可以到工商局投诉，上法院诉讼？当然了，投告无门也是有可能的。不过，那是另一个问题……我支持你采取任何法律不禁止的行为，你把人家网站黑了我都不反对

如果人家没有承诺，但你还是买了他的会员，按我理解就是你的问题。

事情可能要分开看吧，就像之前别人讨论的：很多人把 v 站的广告给屏蔽了，广告主一看效果不行不再投放了，v 站做不下去了，我们不是失去一个很好的平台吗……

其实我觉得，别说是独立开发者做广告拦截软件了，就算是个人用户，使用工具拦截人家的广告也是不道德行为。

觉得人家广告多可以选择不看嘛，或者也可以换个平台看嘛。就像市面上大量的盗版书一样，觉得贵可以不买嘛，或者买便宜的嘛。总想白嫖算怎么回事呢？有本事自己也做一个产品让别人白嫖？说到底，人是一种自私自利的动物……

因此，我觉得 X 的作者没啥好喊冤的，将自己包装成弱势群体博同情而已……谁说弱势群体就可以违法侵犯别人利益了？不能因为警惕强者垄断就走另一个极端……

其实我觉得，别说是独立开发者做广告拦截软件了，就算是个人用户，使用工具拦截人家的广告也是不道德行为。

觉得人家广告多可以选择不看嘛，或者也可以换个平台看嘛。就像市面上大量的盗版书一样，觉得贵可以不买嘛，或者买便宜的嘛。总想白嫖算怎么回事呢？有本事自己也做一个产品让别人白嫖？说到底，人是一种自私自利的动物……

因此，我觉得 X 的作者没啥好喊冤的，将自己包装成弱势群体博同情而已……谁说弱势群体就可以违法侵犯别人利益了？

@laike9m 异常处理目前还没有涉及，我回头看看

不嫌弃的话，可以看看我写的专栏《 Python 3 源码剖析》： https://www.imooc.com/read/76
专栏以 Python3.7 源码为准，分为 7 大模块展开：

- 对象模型
- 内建对象
- 虚拟机
- 函数机制
- 类机制
- 生成器与协程
- 内存管理机制

考虑到 C 源码太过隐晦，我绘制了大量的底层结构示意图，应该更易读一点。我公众号上有几个样章，可以试读：

为什么要钻研 Python 源码： https://mp.weixin.qq.com/s/3T59Li0W116T-xDRHwjeFg
小菜成长之路，警惕沦为 API 调用侠： https://mp.weixin.qq.com/s/S_daJB8ZDUp4lSVVhlS0Dw
Python 对象模型概述： https://mp.weixin.qq.com/s/jFYMprMoD0fLQ9qLxd2SyQ
揭开 Python 对象的神秘面纱： https://mp.weixin.qq.com/s/yIhVXKM2TbY2zKRtFtURyw
str 对象，统一的 Unicode 字符串： https://mp.weixin.qq.com/s/E7z2yN8V9ac2pUTfgqDg9Q
GIL，束缚 Python 的紧箍圈： https://mp.weixin.qq.com/s/lIkcTuCX5htQcteklCFaZw
手把手教你设计协程库： https://mp.weixin.qq.com/s/MaLMf3HZCYfmzxOY1QfPnw
内存池技术如何优化分配效率： https://mp.weixin.qq.com/s/SRd6r1URibR3ZSulT1GDug

专栏是付费的，请试读觉得合适再买哈，不要冲动消费，哈哈~
因能力有限，我不敢说写得多好，用心而已。
有什么建议或者感兴趣的话题，也可以向我提哈，我后续会抽空完善。

@GetMoney 付费阅读也不能幸免……

我去年在慕课网写了一个 Python 源码剖析专栏： https://www.imooc.com/read/76
刚发表不久就发现被某些公众号抄了，只字未改……
好在，微信公众平台上可以投诉，官方处理也快，不然真拿这些孙子没办法……

create_task 的时候，协程被创建，但还没被调度执行；
await gather 的时候，程序执行权被转移到 asyncio 内部的事件循环；
这时，先前创建的协程如果达到执行条件，将被事件循环调度执行；
直到 gather 等待的协程，也就是 producer 执行完毕，程序执行权回到当前代码；
await q.join 的时候，程序执行权又被转移到事件循环，comsumer 继续执行；
直到队列 q 为空，这时 consumer 肯定已经完成所有数据消费；

可以自己动手写一个极简的协程库加深对协程运行原理的理解，只需 100 来行代码，即可一举拿下协程、事件循环、IO 多路复用等核心概念：

https://www.imooc.com/read/76/article/1935

我只看 asyncio 文档时，总有一种似懂非懂的感觉；自己折腾过一遍后就清晰了，各种概念对号入座。

@zhoudaiyu 应该都是 flags 设置 O_TRUNC 标志的 open 系统调用，多看看操作系统底层，别被眼前的表象给骗了😁

也许可以尝试分多次 truncate，每次只截短一点，最终截到 0

@whisky221 不同的经历，有不同的认知；不同的认知，有不同的命运。富不过三代古人几千年前就总结出来了

之前是 1s 一条，也惨不忍睹呀~~~

应该是差不多的，我才 sync 命令执行时就是调 sync()系统调用。你可以执行以下 strace sync 跟踪一下系统调用，就知道 sync 命令到底干了什么了：

fasion@ubuntu:~$ strace sync
execve("/usr/bin/sync", ["sync"], 0x7ffe44037610 /* 30 vars */) = 0
brk(NULL) = 0x55d3c942f000
arch_prctl(0x3001 /* ARCH_??? */, 0x7fff9667d0b0) = -1 EINVAL (Invalid argument)
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=26487, ...}) = 0
mmap(NULL, 26487, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ff948082000
close(3) = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360q\2\0\0\0\0\0"..., 832) = 832
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784
pread64(3, "\4\0\0\0\20\0\0\0\5\0\0\0GNU\0\2\0\0\300\4\0\0\0\3\0\0\0\0\0\0\0", 32, 848) = 32
pread64(3, "\4\0\0\0\24\0\0\0\3\0\0\0GNU\0cBR\340\305\370\2609W\242\345)q\235A\1"..., 68, 880) = 68
fstat(3, {st_mode=S_IFREG|0755, st_size=2029224, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff948080000
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784
pread64(3, "\4\0\0\0\20\0\0\0\5\0\0\0GNU\0\2\0\0\300\4\0\0\0\3\0\0\0\0\0\0\0", 32, 848) = 32
pread64(3, "\4\0\0\0\24\0\0\0\3\0\0\0GNU\0cBR\340\305\370\2609W\242\345)q\235A\1"..., 68, 880) = 68
mmap(NULL, 2036952, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7ff947e8e000
mprotect(0x7ff947eb3000, 1847296, PROT_NONE) = 0
mmap(0x7ff947eb3000, 1540096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x25000) = 0x7ff947eb3000
mmap(0x7ff94802b000, 303104, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19d000) = 0x7ff94802b000
mmap(0x7ff948076000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e7000) = 0x7ff948076000
mmap(0x7ff94807c000, 13528, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7ff94807c000
close(3) = 0
arch_prctl(ARCH_SET_FS, 0x7ff948081580) = 0
mprotect(0x7ff948076000, 12288, PROT_READ) = 0
mprotect(0x55d3c7e1e000, 4096, PROT_READ) = 0
mprotect(0x7ff9480b6000, 4096, PROT_READ) = 0
munmap(0x7ff948082000, 26487) = 0
brk(NULL) = 0x55d3c942f000
brk(0x55d3c9450000) = 0x55d3c9450000
openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=3035952, ...}) = 0
mmap(NULL, 3035952, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ff947ba8000
close(3) = 0
sync() = 0
close(1) = 0
close(2) = 0
exit_group(0) = ?

我在我的虚拟机上跑了一下，发现 sync 命令确实是调用 sync()系统调用来实现的，见倒数第四行。

语雀，最近开始在上面写网络协议教程： https://www.yuque.com/coding-fan/network

我也在写编程话题文章，我的公众号是『小菜学编程』。投入了不少精力，但没什么成效，大概是姿势不对，有经验的老铁来指导下~~~

这是我最近发的文章，自认为写得还算用心：

- 图解内存池，看它如何避免内存碎片化： https://mp.weixin.qq.com/s/SRd6r1URibR3ZSulT1GDug
- 动手设计协程库，彻底掌握协程原理： https://mp.weixin.qq.com/s/MaLMf3HZCYfmzxOY1QfPnw
- GIL 全局锁，束缚 Python 的紧箍圈： https://mp.weixin.qq.com/s/lIkcTuCX5htQcteklCFaZw

但阅读量很少很少，如何提升呢？

对了，还可以观察字节码，看看不同的写法有什么差别。下面是一个可以编译成常量的 tuple 对象的例子：

```
>>> dis.dis(compile('a = ("a", "b", "c")', '', 'exec'))
1 0 LOAD_CONST 0 (('a', 'b', 'c'))
2 STORE_NAME 0 (a)
4 LOAD_CONST 1 (None)
6 RETURN_VALUE
```

而同样的 list 对象则不能，只能即时创建(BUILD_LIST 字节码)：

```
>>> dis.dis(compile('a = ["a", "b", "c"]', '', 'exec'))
1 0 LOAD_CONST 0 ('a')
2 LOAD_CONST 1 ('b')
4 LOAD_CONST 2 ('c')
6 BUILD_LIST 3
8 STORE_NAME 0 (a)
10 LOAD_CONST 3 (None)
12 RETURN_VALUE
```

关于 Python 代码编译过程与字节码，我上面贴的链接里面同样有介绍。

其实两者一样慢，都是 O(n)操作；而且你写的是字面量，n 本来就很小，所以差别更是微乎其微。有些 tuple 字面量可以编译成常量，这样就不用每次都创建 tuple 对象，有一丁点性能优势。另外，考虑 list 和 tuple 对象的内部结构，tuple 也有些优势。具体可以参考 Python 虚拟机内部原理，特别是内建对象部分：

https://www.imooc.com/read/76

这个例子不如这样理解：在什么场景，就用什么数据结构。如果你需要一个不需要变化的列表，那就用 tuple 对象，而不是 list 对象。这样既避免意外修改，也获得一丁点性能优势。单从性能考虑，则有些牵强。

说说我最近的尝试——写了一个关于 Python 虚拟机源码的专栏，目前发表在慕课网上，有免费样章：

https://www.imooc.com/read/76

成果如何呢？截止到目前的情况，只能说非常一般。这个话题从大约一年前就开始约稿，然后花了大量时间列提纲、阅读源码、画各种数据结构示意图、讲解算法、整理面试题等等。然后呢，大约今年年中的时候，才发布上线。

上线时只写好一半的章节，另一半按照每周两小节的速度更新。讲真，每周写两个小节，5 千左右，都压力山大。特别是遇到一些自己先前没有研究积累的领域，比如 Python 生成器和协程的运行原理等等。

收益如何呢？实话说，聊胜于无。前前后后忙活了一年，花了几十个的周末，收入跟用几个周末接外包差不多。血亏。不过呢，也有意外的收获。例如，因为写这个专栏，我把 Python 协程运行原理的来龙去脉都搞清楚了，还自制了一个简单的协程库。另外，也彻底研究了 Python 内部内存池实现以及垃圾回收机制，也算是一种进步。这大概就是这一年的最大意义。

先前尝试过接外包，辅导在海外留学的计算机专业学生。收入还算不错，一个月 4 个周末大概能来万把块钱。但后来觉得这些都是一锤子买卖，做一个算一个，但我们的时间都是有限的，遂放弃。

后来换了个思路，准备写一本或者做一门课程，或许能有长尾效应。Python 源码这个专栏算是一个开始，虽然卖得不咋滴，但我应该还会继续，最近正在筹备一个讲解网络协议的入门级教程，打算做成免费的，看能否攒点人气：

https://www.yuque.com/coding-fan/network

至于技术创作的路好不好走，等我尝试后再来跟各位老哥报告一下~