爬虫？

3天就能撸出来。。给力的

@buddha

貌似是不能直接以 mtr 显示 xx% lost 作为直接的丢包判定

root@localhost:~# mtr --report www.google.com
HOST: example Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 50.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1
5. 72.14.233.56 0.0% 10 7.2 8.3 7.1 16.4 2.9
6. 209.85.254.247 0.0% 10 39.1 39.4 39.1 39.7 0.2
7. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.3
8. gw-in-f147.1e100.net 0.0% 10 39.6 40.5 39.5 46.7 2.2

比如这个 report，其实是第2个节点限制了 icmp 协议包，并没有丢包

这篇文章说的很详细
https://www.linode.com/docs/networking/diagnostics/diagnosing-network-issues-with-mtr

However, it is common practice among some service providers to rate limit the ICMP traffic that MTR uses. This can give the illusion of packet loss when there is in fact no loss. To determine if the loss you’re seeing is real or due to rate limiting, take a look at the subsequent hop. If that hop shows a loss of 0.0%, then you can be pretty sure that you’re seeing ICMP rate limiting and not actual loss.

真正丢包的模式是类似这样的
root@localhost:~# mtr --report www.google.com
HOST: localhost Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 60.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 60.0% 10 6.7 6.8 6.7 6.9 0.1
5. 72.14.233.56 50.0% 10 7.2 8.3 7.1 16.4 2.9
6. 209.85.254.247 40.0% 10 39.1 39.4 39.1 39.7 0.2
7. 64.233.174.46 40.0% 10 39.6 40.4 39.4 46.9 2.3
8. gw-in-f147.1e100.net 40.0% 10 39.6 40.5 39.5 46.7 2.2

In this case, you see 60% loss between hops 2 and 3 as well as between hops 3 and 4. You can assume that the third and fourth hop is likely losing some amount of traffic because no subsequent host reports zero loss. However, some of the loss is due to rate limiting as several of the final hops are only experiencing 40% loss. When different amounts of loss are reported, always trust the reports from later hops.

那些密码要就拿去好了。。

@dbfox

就这个需求来说，个人觉得确实是web这边做比较合适的，理由就一个，灵活

如果下回产品说改个排序规则什么的，在客户端做的话就要重新发布客户端
在web这边实现只要改下输出逻辑就行了

在显示的时候做，谁显示谁负责~

XSS 过滤逻辑可能没 cover 到所有 case（或者后来可能会出现一些新的case）
这时候如果在存储之前做过滤，后来发现有些 case 没过滤掉咋办？回去数据库找没 cover 到的数据改掉？

如果在显示的时候做，只要改下显示逻辑即可，相对改数据库来说，简单很多吧

个人更倾向于 DB commit 后 更新/清空 cache 对应的 key 的做法

设置一个很短的过期时间，多短的时间算是“很短”呢？
长了数据不一致问题会比较明显，短了 cache hit rate 降低，cache 就没啥意义了

@vivisidea
尝试了下似乎不是很靠谱，会 remove 掉一堆相关的东西，试试 --reinstall 看是不是想要的效果。。

xxx:$ sudo apt-get --reinstall install python

Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
gir1.2-ubuntuoneui-3.0 gir1.2-unique-3.0 gambas3-gb-form-stock libubuntuoneui-3.0-1 libkms1 pastebinit
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 154 not upgraded.
Need to get 168 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://mirrors.sohu.com/ubuntu/ precise-updates/main python amd64 2.7.3-0ubuntu2.2 [168 kB]
Fetched 168 kB in 0s (335 kB/s)
(Reading database ... 255759 files and directories currently installed.)
Preparing to replace python 2.7.3-0ubuntu2.2 (using .../python_2.7.3-0ubuntu2.2_amd64.deb) ...
Unpacking replacement python ...
Processing triggers for doc-base ...
Processing 1 changed doc-base file...
Registering documents with scrollkeeper...
Processing triggers for man-db ...
Setting up python (2.7.3-0ubuntu2.2) ..

重装 python 试试。。好像没有直接能 reset 的

apt-get remove xx
apt-get install xx

居然还活着！

ubuntu 申请过光盘

@caixiexin +1

曾经有一次下班赶着要走，又想着“把一个清理数据的脚本写好再走吧”，于是慌乱中把线上数据给错删了

对线上环境要有敬畏之心~之前从一位前辈听来的，一直深以为然。

当然能收的权限是要收掉的，DROP 之类的
DELETE 我的经验是，
1. 先 SELECT 出来确认结果，然后 DELETE 一定要带 LIMIT（哪怕只有一条），防止长时间锁表
2. 来路不明的 SQL 语句一定不直接贴到 MySQL 终端，至少要把 TAB 之类的整理干净
3. 最好在测试环境先演练好

对于老家离工作地方 1000+km 的来说，回家就像是一次旅行

@zhaoace 收藏。。