Shell's Home

为什么running不高但是load很高

Jun 3, 2014 - 1 minute read - Comments

很多初学者会混淆几个概念。CPU繁忙程度,load。两者的区别在于,一个秘书是真的忙着抄抄写写,另一个么,反正领导只检查桌子上堆的文件数。只要桌子上准备一堆文件,在文件里换来换去就好了,没必要真的很忙。当然,大多数时候桌子上堆着很多文件的理由还是因为秘书手不够了,不过少数时候也有例外。例如fork boom,CPU很空但是load奇高。 我们就遇到了一个例外的例外。 症状是这样的。系统经常出现偶发性的load过高。例如有那么几分钟,load会高到100-200,然后就快速下降。但是检查后发现,即使在load极高的时候,cpu占用率也并不高,大概在10-20左右。磁盘吞吐也一般。那么load为什么会这么高呢? 我的第一怀疑当然是超多数量的小线程,在那里搞切换调度。所以我第一反应就是看了/proc/loadavg的当前活跃线程数——结果居然只有1-5。为了确认,我特意的持续观察了数次,在我观测期间load的1分钟计数还升高了——这说明当前实际队列比1分钟平均还要高,而活跃线程却是3。 怎么可能?交通系统报警说北三环大赛车,平均堵塞长度500辆。去一辆警车到现场回报说只看到塞了两辆,再去一辆说算上我们自己三辆。去了十多次都如此。任何脑子清楚的人都会毫无疑问的喊出——黑箱政治,政府不作为,我们要占领国会——不好意思,我们好像没有这个东西。 OK,言归正转。为了解释这个疑惑,我特意的去看了一下内核源码——我擦,loadavg的平均值计算中,是把uninterruptible算在一起的。而活跃上下文中,只算了nr_running! ——你丫敢再精神分裂点么? 为了确认,我还特意man proc,结果发现里面确实有说,平均值是R和D两者去算的。但是在活跃上下文那里,只说了the number of currently runnable kernel scheduling entities——看看清楚,这里可从没有说有D。脑子清楚的仔细想想就知道,D是不可调度的。 ——问题是咱脑子不清不楚的就没想这差异,而且咱连man proc都没查。。。 另外顺便说一句,内核也告诉了我们一点东西——load计算的时候是连内核线程一起算的。 清楚这点差异后,问题的原因也很清楚了——肯定是哪里有很高的D。用ps -e Hl | grep -e R -e D扫了一下,再用wc -l做了一下统计。214个线程在D(或者R,或者只是不小心被grep到,但是实际上大部分都是D)。系统当前的loadavg正好长这样: 214.12 156.63 82.25 7/4629 10027 7个执行中线程®,207个uninterruptible。 ——所有的谜都解开了。

台北地铁砍人事件

May 25, 2014 - 1 minute read - Comments

哪里都有疯子 其实并没有疯,只是不论理由,就是要杀人而已——就是所谓的反社会人格。理论上心理咨询是可以发现的。但是台湾的经验告诉我们——目前的心理咨询密度不足,敏感度不足。而要维持足够的敏感度,不仅费用成问题,而且还会有很多啼笑皆非的情况。 社会压力?北欧够没压力了吧。2011年挪威发生爆炸和枪击。 废除死刑? 我不赞成废除死刑。当然,这和捷运杀人案本身并没有什么关系。他杀人的时候就知道自己会被判死刑。人不畏死,奈何以死惧之,死刑对凶手是没什么阻止力的。所以废除死刑还是保留死刑,都不能阻止凶案的发生。 但是死刑还是能阻止一些东西的。例如本次事件,死者中有两位20出头的年轻人。如果没有死刑,他们的父母会不会试着杀了凶手呢?反正活着也没什么意思,而且很讽刺的——我们也不能判这些人死刑。更进一步的,每次杀人案,我们需要严密保护的想必不是受害人,而是加害人——因为加害人不能死。而我们的法律为了保护加害人而存在,受害人遗族如果心理难以平复,只有自己动手,同时把自己变成受法律保护的人——就是加害人——才行。这样的逻辑不荒谬么? 死刑这事原本就没什么意思——我们已经遭到了损失,却还要用杀人来扩大损失。从这个意义来说,如果真是很久都没有恶性事件了——例如2011年挪威枪击和爆炸事件那样。这样的情况下,要不要废除死刑还真的可以商量。只是真的如此,我们应当判处什么人的死刑呢?长着野百合的绞刑架大概会成为城市最美丽的徽章。 死刑的意义在于,在无法无天的地方,我们有一种廉价的方法,可以永远的不用看到这个人。 和太阳花连结 咳,要认真论关系,马总统和杀人犯的关系绝对比太阳花近——这人的衣食住行,哪个不是受到政府政策的影响?是为期一个月的太阳花运动,还是持续执政数年的政府,更有可能造就一个杀手?两者哪个和凶犯的联系更多?持太阳花论的人认真想过这个问题么? 还有。包围行政院的年轻人去哪了?大概正在被各种凶案发生时的警察逮捕吧——你不觉得换个说法”凶案发生时,警察去哪了?“,这个质疑也能成立么?而且大部分凶案发生时都看不到警察啊,明明总统府门口一大堆的说。 也不要以为持这种论点的人是傻瓜。你讨论了这个问题,哪怕是否定,也达到了他们的目地——没有关系也是一种关系啊。我们不断讨论,有没有关系,有没有关系。不断得出结论,没有关系,没有关系——届时只要轻轻反问一句,真没有关系为何要讨论这么久,有人讨论过西瓜和美国国旗的关系么?没人讨论,是因为真的真的,一点点关系都想不到啊。 从这个角度来说,这种问题居然还需要讨论本身就很反常,你我都是网里的一个飞虫而已。 玩游戏和杀人的关系 比”吃饭和杀人的关系“近,比”没有女朋友和杀人的关系“远。从这个意义上说——难道政府要强制所有人谈恋爱?

goproxy和msocks简介

May 8, 2014 - 1 minute read - Comments

goproxy是我个人写的,和shadowsocks同类的软件。当然,在设计之初我完全不知道shadowsocks的存在,goproxy的最初目标也不是成为shadowsocks的同类。只是我一直无法实现一个可靠的,能够达成目标的系统。最后想,那这样吧,我找一个跳一跳能够够到的苹果。大幅简化的结果就是goproxy——后来我才知道shadowsocks。 shadowsocks的基本原理 shadowsocks的基本概念,就是利用某种不同于SSL的协议,将本地的socks数据流转发到远程。这个协议,在默认版本中是一个凯撒变换,后来有了aes等加密算法。goproxy也采用了类似的做法,同样支持aes等加密算法。在每次连接时,客户端先用加密通道连接服务器端,然后完成整个连接通路。这样的设计鲁棒性相当好,但是作为代价的,也有不少缺陷。 首先,goproxy和shadowsocks不约而同的采用了自己的协议,而非将socks5透明的转发到远程的服务器端。为什么?因为socksv5协议中,握手过程是三次交互。客户发送握手包,服务器响应允许的握手验证方法。客户发送验证报文,服务器端返回是否成功,客户发送要连接的目标,服务器端返回是否成功。细节我记得不是很清楚,但是2-3次往返是必须的。 这种工作机制需要client -> proxy-client -> proxy-server -> server的一个链条,本身就比直连多了两次TCP握手。加上上述的往返过程,更加耗时。而且这个消耗在每次建立链接时都要来一次,而HTTP是一种短连接协议——这就更加无法容忍了。因此改用自有协议,一次交互完成握手,就会更加快速。 更根本的原因在于,这两个系统都需要越过IDS,而三次交互的报文大小是几乎固定的——就算加密也无法改变报文大小。不但大小一样,而且由于用户名密码相同,起始加密过程和IV一致,因此采用socks协议的话,每个链接开始都有相同的来返数据。 我不知道shadowsocks怎么处理的这个问题。qsocks协议(msocks)的前身规定,每次握手时客户端提供一组IV,然后发送一个头部变长的字符串(256字符以内),在远程丢弃同样长度的随机字符。经过这样的处理,每次链接时的报文长度和内容序列都不一样,增加了破译难度。至于多出来的几十个字节,和验证报文在一个报文内,开销相比一次RTO几乎可以忽略不计。 但是还是有一点无法避免的问题。如果你看到某个服务器上有一个端口,频繁的被一个或多个IP链接。每个链接都不长,每次都是客户端吐一堆数据,服务器返回一堆,然后关闭链接。尽管协议无法破解,但是基本可以肯定这就是shadowsocks。根据这个特性,可以有效的阻挡服务——这也是我最近碰到的问题。 而且每个链接都需要验证和TCP握手太慢了。 msocks的改进 所以,我参考SPDY协议,做了msocks。msocks的核心思路和qsocks很类似,主要修改是以下两点: 使用一个可靠链接(这里是经过加密的TCP),在这个链接里面封装多对传输。 每个链接只要一次验证。 这样做,首先减少了一次TCP握手和一次身份验证,工作速度更加快。其次多个传输叠加在一个流里面,流特征更加变化莫测。最后,无论是服务器端还是客户端的开销都小了很多。 当然,这也带来不少问题。例如TCP原本的拥塞控制窗口是为了一对传输序列设计的。当很多传输序列在一对TCP上传递的时候,丢报文造成的影响会作用作用在全体传输序列上。包括丢了一个报文重传的时候,所有序列都必须阻塞。还有基础的TCP被施加了丢包,导致全体序列共享5k带宽。当然,经过评估后,我觉得这些问题比频繁握手更加轻,所以就设计了msocks协议。 协议设计的时候,有几个细节问题。 多对复用 我采用了一个map,来记录某个id是否对应到了一个控制结构。这个映射只能被客户端更改,并且有个专门的函数负责查找空闲的id,每次生成的id都是递增的,如果碰到最大值则绕回。 id的大小是16位,足够容纳65536对同时链接。其实不修改内核的话,500对代理就会导致too many files。 实际上一般到id达到400后,单一的tcp就断线重连了。目前我还没见过上千的数字呢。 连接状态 连接一般情况下可以看到5种状态,连接请求发送,连接请求接收,连接建立,主动关闭连接中,被动关闭连接中。 当客户端请求代理连接一个远程服务器时,进入连接请求发送。代理远程端接受后在连接目标服务器的过程中,进入连接请求接收。当成功后,双方进入连接建立。 当关闭时,主动发起关闭一端进入主动关闭,另一端进入被动关闭。当被动关闭端调用close,或者主动关闭端收到对方关闭,整个链接就销毁。 由于tcp是可靠传输,因此三次握手和四次关闭都是不必须的。 简单吧。 拥塞控制 TCP原本是带有拥塞控制的——借助SSN双序列和窗口机制。但是在多路复用的时候,我们需要自行控制拥塞——而且不能采用会和机制。会和会导致后续已经到达的其他链接的报文被一个没人接收的报文阻挡。所以必须采用带拥塞控制的缓存队列机制。 不过幸好,TCP本身是可靠传输协议,所以我不用担心丢包重发之类的问题。我需要做的,就是把对方读取的字节数传递回来,减在控制器上,即可。 不过,我没有做对应于silly window syndrome的优化,在每次读取小数据量后,这个读取造成的window扩张都会被传回。当然,这么设计是有原因的。我默认采用了8K的buffer进行fd间拷贝,所以一般碰不到SWS。 为了解决tcp链接复用造成的单连接带宽问题,我强烈的建议你做以下的设定: net.ipv4.tcp_congestion_control = htcp net.core.rmem_default = 2621440 net.core.rmem_max = 16777216 net.core.wmem_default = 655360 net.core.wmem_max = 16777216 net.ipv4.tcp_rmem = 4096 2621440 16777216 net.ipv4.tcp_wmem = 4096 655360 16777216 ip选择算法和DNS 在goproxy中,我沿用了一个做法。通过DNS获得请求的目标IP,和中国IP范围核对。如果在国内则直接访问,否则透过代理。这个方法能够极快的加速访问,而且几乎不依赖于需要更新的列表(中国IP列表相对来说固定)。 问题是DNS解析过程。msocks内置了DNS能力,可以帮助做DNS。但是实践下来发现这样做效果并不很好。而原本是采用直接DNS,丢弃特定的报文。这样可以过滤防火墙污染。 原因很简单。原本的模式会让DNS服务器感知到查询者位于中国,于是给出中国可以访问的最快地址。而新的模式则会将DNS请求者搬到美国——这无故加重了代理的负担。例如www.qq.com,原本只需要请求得到一台深圳的服务器即可,现在则需要让DNS绕出去,再回来。如果不幸,QQ有一台位于美国的服务器,那么我的访问都会通过这台服务器——这可比深圳的服务器慢多了。

CVE-2014-0160(openssl)严重漏洞及其对应

Apr 8, 2014 - 1 minute read - Comments

描述 openssl 1.0.1系列中,1.0.1f以前的版本在实现上存在漏洞,未正确处理Heartbeat扩展,导致攻击者可以窃取服务器端敏感数据。 对应 请立刻升级openssl到1.0.1g版以上,并重启整个系统,以保证不会遗漏某些已经启动的进程。 如果有自行编译的程序使用了openssl。当这些程序静态链接或链接了自定义的openssl时,需要重新编译。 在有问题的设备上使用过的key,需要升级私钥。 openssh不受影响,openvpn受影响。 作为证明,请执行以下语句自行检查。 ldd /usr/sbin/sshd | grep ssl ldd /usr/sbin/openvpn | grep ssl ldd /usr/sbin/nginx | grep ssl for i in $(ps aux | awk '{print $2}'); do echo $i; ldd /proc/$i/exe | grep ssl; done 其他 根据昨晚看到的信息,这个漏洞会泄漏服务器端的通讯数据。因此请将所有session清空,在受影响期间使用过的用户名和密码请务必在3-5天后再修改一次(具体看服务商什么时候补掉漏洞)。 参考 nvd debian ubuntu openssl Is OpenSSH affected by this as well?

安全的几点快速说明

Mar 25, 2014 - 1 minute read - Comments

这篇文章谨献给某些特殊环境下奋斗的人士。其他人参考使用。 物理设备 物理设备上存储着相当多的个人资讯,所以所有的机密资讯要保密这是常识。 物理设备上可能拥有的机密资料: 各大站点的session token。借助这些,虽然不能抢走帐号,但是可以仿冒身份,发出假消息,或者诈骗。 浏览器启用了“保存密码”选项后,所有的密码都半明文存储在硬盘上。这些信息可以被用来抢走帐号。 个人的文档,照片,私密视频。万一笔电丢失就够倒霉了,再变陈老师岂不更痛苦? 浏览某些特别站点的记录。咳咳,大家懂。 之所以要设备加密,是因为有一种破解方法是将你的设备存储拆下来,接到独立的读写设备上,直接读取数据。无论系统密码设定多强,也无法防范。 如果是mac,有一个选项叫做全盘加密。ubuntu有home分区加密的选项。启用这两项可以有效加密你的电脑。windows也有个类似的功能叫做EFS,但是据说不少国家级单位有解密权限。 Windows Mac Linux android上有加密系统的选项。但是要注意,如果启用会消耗大量电力,而且必须擦除整个设备才能解除。iphone我没用过,据一位挺熟悉的朋友说,只要设定了pin码,整个手机就会被加密。 加密只是第一步。对于经常保持开机的系统,如果能够轻易的进入系统,那么磁盘加密也形同虚设。所以,请给你的系统加上一个足够强的登录密码。 最低强度: 磁盘加密8位以上,系统登录6位以上,包含小写和数字。 推荐强度: 磁盘加密10位以上,系统登录8位以上,包含大小写和数字。 网络安全 首先,请把系统的防火墙开到最大: Windows Linux Mac 基本原则是,只许出不许进。如果需要可以开放特定端口。 然后,如果在不安全的环境下使用网络,请使用vpn。这里请允许我广告一把朋友的网站云梯。一般是用来大陆翻墙的,不过要用来绕过不安全的环境也可以。 有时间有条件的朋友可以自行架设vpn服务器,这里给出linux下架设pptp vpn的方法。客户端使用方法可以参考云梯的说明。 How to Setup a VPN (PPTP) Server on Debian Linux PPTP Server linux pptp vpn服务器的架设 Debian系统快速搭建pptp VPN 注意加密一定要使用128位,不要使用56位。 网站访问 如果可以选择,尽量使用https。下面有一些插件,使你可以尽可能的使用https访问站点。当然,如果站点没有https则无效。 Chromium Firefox 在https访问的时候,如果跳出证书是伪造的之类的警告,请千万不要确定。这是有人在man-in-middle的信号。正确的做法是使用vpn,看看问题是否消失。如果消失,上报给工程师。如果没有消失,请找可信的工程师来排查。千万不要轻易认可未经鉴定的证书(实际上不建议自行接受任何证书——除非那是你自己配出来的)。 另外,请关注证书的签署者。在我这里看到的信息如下: google的证书签署者是GeoTrust facebook的签署者是VeriSign twitter的签署者是VeriSign 如果签署者有异,请上报工程师。这可能是有人获得了某个根证书机构的密钥来做的签署(例如CNNIC之类)。原则上这样的man-in-middle可以攻击任何网站。

携程网信用卡泄密问题

Mar 23, 2014 - 1 minute read - Comments

事情经过 2014年3月22日晚上6点多,乌云平台报告了携程平台支付日志泄漏问题,然后信息快速传播。晚上八点左右我就得到消息。 从描述中大致来看,应当是支付过程的各种信息都被打到了日志里面,然后日志泄漏了。 第二天,携程发表声明。简单归纳就是几点: 漏洞系调试所致。 受影响的用户为21-22日的用户,统计仅93人。 因漏洞引起损失,携程将全额赔付。 个人认为,携程的声明基本就是在推卸责任。 过程还原 漏洞细节虽然没有暴露,但是从透露出来的信息仍然可以拼凑出部分过程。 某个时间开始,携程的某个内部人员打开了线上系统的日志,用来做调试。不幸的是,日志里面包含了信用卡所有刷卡信息,而且日志可以被穷举下载。这个人是谁,什么时间开始,不知道。 22日,漏洞发现者(猪猪侠)发现了这个问题,并报告在了乌云上。 携程收到信息后,立刻关闭了调试模式。并且把系统日志拉出来看看,发现里面有一些人。于是携程就发表声明。 问题分析 在整个过程中,暴露出几个问题: 携程未必是故意记录CVV信息。但是根据携程可以让用户仅提供卡号后四位就可以完成刷卡来看,携程一定是记录某些信息的,但是未受到本次漏洞影响。 交易过程所交流的数据属于机密,到底是什么人有权限打开调试日志,又没有经过严格的访问控制?是主管级以上?还是普通员工?无论哪个级别都是严重的问题。如果是普通员工,说明携程对员工的管理不到位,权限分割控制不合理。任何恶意员工可以打开日志得到数据而主管无法察觉。如果是主管以上级别则更加糟糕。说明主管根本不懂技术,也不知道如何保护客户的安全。 时间是否仅限于21-22日?如果是的话,意味着仅仅2天就被攻击者找到了漏洞。如果是偶然的话也太快了,如果是必然的话,则代表携程内部其实还有其他问题。 两天的交易仅仅是93人?没有更多?为什么只是部分用户受影响?携程并没有披露更多细节。要么是这里仍旧隐藏着漏洞,要么是携程的危机公关不到家。 评论 为什么说携程的声明是推卸责任? 首先,对于受到影响的用户,只要能证明是携程的责任,无论携程是否发布声明,都可以打官司获得赔偿。携程的声明仅仅是表达了他必然受到的法律后果。如同驾驶员发表声明:“我喝醉后所撞伤的所有人,我将全额赔付其医疗费”一样,没有任何意义。而如果无法证明是携程的责任,携程当然不会管你。 携程是否隐瞒了更久以前服务器调试开启的事实?这并不好说。个人倾向于善意的揣测携程不会隐瞒,但是在行动上不妨恶意的揣测其实调试信息打开时间更长,受影响的人更多。 为什么只有93人受到影响,携程并没有公布。携程的事后分析,应当都是基于这个漏洞的特性“下载日志”而定的。其赔偿基线也是根据“下载日志就会有日志”而产生。但是是否有可能被擦脚印?或者内部人员打开日志然后关闭而逃过被抓?这些携程并不能回答。从问题分析2来看,这种可能并不能排除。而携程的声明并没有表示对这些情况负责(当然就算想要负责也无能为力)。 由于携程信息的不透明,其声明“只有93人受到影响,其他用户安全不受影响”,换个说法就是,“不接受任何赔偿请求,除非你们有足够证据”。问题是用户怎么可能有证据?证据都在携程的服务器上和拿到信息者手里。当有用户的信用卡被盗刷,如何确认是自己的责任还是携程的责任? 基于上述几点,我认为携程的声明是在推卸责任。 建议 如果你是93人之一,当然,携程应该已经联系你换卡了。 如果你不是93人之一,根据上文分析,携程是不会理你的。基于携程并没有透露更多的信息,也没有第三方机构佐证其说法的事实。你需要自行考量信用卡信息泄漏的风险。因此,我对所有在三年以内在携程使用过信用卡的所有用户的建议是,立刻用各种方法冻结信用卡或额度,并尽快换卡。 我对所有人将来的建议是,远离携程直到其展现出对用户隐私和安全足够的尊重,或者关门。 PS,你可以用下面几种方法冻结信用卡: 打电话给发卡行,要求冻结。发卡行核对一些基本信息后就会帮你冻结。 使用网银将额度改为1元。根据网友反馈,建行的额度是千元为单位设定的,建议建行的用户们尽快弃卡。 信用卡的固有弱点 信用卡消费的几个要素是,卡号,CVV号,还有有效期。如果是线下消费,需要核对签名(理论上如此)。如果有设定密码,需要核对密码。 密码的问题是,如果设定了密码,一旦信用卡被盗刷,而密码一次正确,将被视为用户责任。而且很多发卡行的跨境消费是设定了密码但是没有密码也能成功的。因此信用卡的建议是不打开密码。 在网络使用中,这里有个很严重的不便——卡号,CVV,有效期,都是发行时即固定,不可更换。这导致一旦你将这些信息交给对方,你的安全就全由对方保护,发卡行无法帮你做任何事情。 正常来说,应当使用密码乃至在信用卡上附上电子token来加强安全性需求。这样的话,token信息无法保存,密码可以修改。当出现携程这类问题时(或者更普遍的,当碰到有恶意的商家时),可以通过修改密码来解决问题,不需要换卡。 一个小故事——我和携程打交到的经历,还有我为什么幸运的逃过一劫 我在某年,使用携程订机票的时候,对方业务员让我报出身份证号。我当时就一阵错愕——难道身份证号不是应当使用手机键盘输入么? 两者的区别在于,手机键盘输入,信息是直接输入到VI系统的电脑中,业务员只能看到尾号。而如果是业务员输入,那么他就有我的所有信息——从身份证号到信用卡号。也许我可以相信携程,但是我如何相信业务员?出了问题,我如何证明? 所以我就向携程的客户经理投诉了这个问题。具体经历在网络安全——你需要知道的东西里面已经描述了。这里面甚至我质疑了携程保存信用卡的安全性,几乎和今天的问题类似。 结果没多久,我打给携程的时候,丫的业务员和我说,如果你信不过我,咱们可以走这套系统。 我了个大去,这种系统还允许旁路绕过?那有个毛线的意义? 从此(12年年中吧)我再也没有用过携程的业务——用也是让公司同事帮我用。因此,当去年(13年某个时候)我的老卡到期,我就换用了新卡。新卡还没有在携程上用过。所以本次问题我一点事都没有。

台湾反服贸占领立法院中,网络干了点什么

Mar 21, 2014 - 1 minute read - Comments

短文,直接说吧。今天在facebook上看到,有帮台湾朋友组装了两台大功率的基台,把信号直接打到立法院里面。我在图片上看到了一堆天线,不少Cisco的设备,还有基台车。好像还有朋友拿着易拉罐和炒菜锅不知道是帮忙还是帮倒忙。 简单点说,基本架构就是外面架一个基台(推测使用5G频率),用定向天线和里面的client连通,出口用4G和基台车连接。然后里面的client走有线网和多个AP连接起来,每个AP分散部署,分享基台到client之间的链路。 目前看到的效果,信号已经打到立法院里面了。连警察人墙都可以用网——只是他们没有密码而已。 ——结果今天早上发现立法院内其实有网,而且网速快过4G。所以又反过来架设——内部多个AP分享出去后,向外面打信号,外面又架设多个AP把信号分享给会场的上万人群。 上万?想想都要疯啊。 03-21T14:42: 根据看到的最新消息。3G和WiMax都爆满,而且整个立法院内信号密度过高。因此退回最原始的方案——拉一根超长网线解决。啊啊,这不是白折腾了么? 03-23T12:00: 在会场架网络的朋友,在google plus上分享了细节。细节在这里: https://plus.google.com/+DAVIDLIFUHUANG/posts/WKP2qTDJypA 摘抄如下: 我來解釋一下我在立法院內部遇到的網路問題, 同時也說明這是我看到的問題, 或許 rex 有不一樣的見解, 那就再請 rex 另外闢文說明, 我剛開始進去的時候, 我原來以為 g0v 裡面有人, 不過實際上應該是我搞錯意思, 所以我就傻傻的進去了, 不過我個人是覺得, 我們應該要維持裡外訊息的暢通跟正確性, 所以我應該要做一點事情, 畢竟我只會弄網路, 所以我就真的去想辦法弄網路了 XD 人很多, 3G 全部癱瘓, 所以早就該換 LTE 了, 對吧 XD 3G 全部癱瘓, 所以大家都用 WIMAX, 這次 WIMAX 的表現還不錯, 讓我覺得以後來台北參加活動還是應該花點小錢租 WIMAX, 畢竟正確的訊息傳遞可以避免很多不必要的麻煩發生, 同時沒有人用的服務遇到人多的時候就是好服務, 因為它沒有人用, 但是目前沒有 5G 無線網路的 WIMAX 攜帶型無線網路熱點, 這是一個很嚴重的問題 XD WIMAX 多, 大家都開無線網路熱點來分享 WIMAX 的服務, 所以造成了無線網路封包的的碎片化 立法院本來就有無線網路系統, 在一個會議室裡面有一堆一樣的 ESSID, 同時又分散在不同的頻道上, 然後這些頻道上面又有很多一樣的 ESSID 但是分散在不同的 AP 上面, 這樣會發生什麼事情呢?

台湾服贸协议问题

Mar 19, 2014 - 1 minute read - Comments

这篇东西是简单介绍台湾服贸问题的前世今生的文。其实我早就在关注这个问题,只是作为一个大陆人,这个问题很不合适。毕竟服贸这东西让台湾人很不爽。换言之,某种程度上我是获利一方。作为获利方还指手画脚说三道四未免有点“得了便宜还买乖”的嫌疑。不过近日,服贸问题已经从一个单纯的贸易协商变为政治问题。这里面很多东西非常值得我们学习。 什么是服贸协议 简单来说,就是大陆和台湾的贸易协定。从这个角度来说,这个东西不但没问题,而且必须。出问题的是内容和通过内容的方法。 台湾政府宣称服贸可以提振台湾经济,但是民众始终有疑虑: 大陆人工(薪酬)比台湾便宜,加大开放是否会影响就业 开放不对等,台湾太多领域对大陆开放,而大陆很多领域不对台开放,其中甚至包括影响国家安全的重要领域(例如通讯和传媒) 大陆食品安全问题,台湾的检验检疫是否能保持独立性 老实说,从大陆人眼光看,很多问题颇有点——不知道怎么说的味道。台湾食品安全问题也不轻,而且从就业工资来看,台湾平均起薪大概和上海持平。随着工作年限上涨,反而是上海这里工资更高(至少在IT业)。如果每一条都照着对台湾有利的方向改,对服贸不爽的就是我了。基本一点,协议是双方的东西,即使我们看起来这个协议再合理,对对方再有好处,如果对方本身不同意,就不应当且也无法签署。协议本身,必然是双方讨论,我这里退让一点换取你哪里退让一点,最终得到双方认可——的这么个过程。 参考可以看以下几条: 看过来 看过来 看过来 问题在哪里 问题在于通过的流程。 台湾服贸对不同人群造成的影响不同。对于老板阶级来说,员工工资降低,市场扩大,自然是好到不能再好的好事。对于高阶白领来说,能到大陆打工也不坏。但是对于中低层员工而言,就要面对工资降低,服务品质变差等等问题。因此不同人群对服贸的支持和反对是不一致的。而台湾不是大陆,通过这种东西理论上是要通过内部讨论,人民授权的。问题是服贸这么一大包,这条这帮人不同意,那条那帮人不同意。每个人一个说法,但是总之就是反对你。这样服贸就始终无法通过,政府非常头大。 因此要通过服贸,比较容易的办法就是逐步协议,每次只谈一部分,对少部分人产生不利影响而对多数产生好处。逐步通过逐步调整,减少影响范围,降低抗议人群比例。但是台湾政府不但拿着一大包协议来签,而且想大手笔的一笔就签下去,完全没管民众的反应,也不管是否合规。等民众抗议了,再强行闯关。 呃,是不是来大陆考察多了,一不小心以为自己还在过组织生活呢? 最近怎么回事 本来去年服贸都要签了,结果被人踢爆,叫停回去重新逐条审查,而且要开公听会(听证会)。大陆的同志们想也知道,听证会么,涨价就对了。所以党国官员干脆一周开八场,我讲你听就好,乖乖不要多问。结果引起不满,后面被人排成了两周一场——依然是我讲你听(非常熟悉吧)。党国官员还很不爽,指责这是拖延时间。 然后拖到最后一场,干脆一合本子。好了,三个月已到,审查视为通过。 咳咳,要这么容易,不知道能不能拜托他通过一下大陆人获得“台湾”国籍的法规。只要迁一成大陆人的户籍过去,公投回归大陆就没疑虑了。 参考可以看这里。 所以呢 所以这帮不爽的人就跑去把立法院给“占领”了。 啊然后呢 我也不知道。不过搞成这样,已经完全不是服贸的问题了。服贸本身没什么太大问题,逐条审议逐步通过也可以,阻力大也不会比现在更糟吧。现在已经是手法本身激起的不满比服贸本身还大了,作为政治(尤其是还算民主的地区的政治),这么搞是很不明智的。 从我关注的台湾各大事件的结果来看,往往是雷声大雨点小。运动的时候声势沸反,但是最终结果下来往往是差强人意。但是好在运动是经常的。民众往往是这里一点,那里一点,能够挡住一些太过荒唐的事情。其实这也是民主社会协商的必然结果,指望一次运动就能把所有的问题一并解决的想法,和一次通过整包服贸一样不靠谱。

系统内存有富裕但是syslog中持续报告内存耗尽

Mar 17, 2014 - 11 minute read - Comments

现象 ubuntu12.04,3.5.0-23的内核。在syslog里面持续看到内存耗尽,用free去查看却是内存还有80G左右。检查系统没有cgroup或者ulimit限制。log如下: Mar 11 14:45:34 nb81 kernel: [7352493.081026] swapper/0: page allocation failure: order:4, mode:0x4020 Mar 11 14:45:34 nb81 kernel: [7352493.081035] Pid: 0, comm: swapper/0 Tainted: G W 3.5.0-23-generic #35~precise1-Ubuntu Mar 11 14:45:34 nb81 kernel: [7352493.081038] Call Trace: Mar 11 14:45:34 nb81 kernel: [7352493.081040] <IRQ> [<ffffffff8112d1b6>] warn_alloc_failed+0xf6/0x150 Mar 11 14:45:34 nb81 kernel: [7352493.081065] [<ffffffff81139a51>] ? wakeup_kswapd+0x101/0x160 Mar 11 14:45:34 nb81 kernel: [7352493.081071] [<ffffffff81130ffb>] __alloc_pages_nodemask+0x6db/0x930 Mar 11 14:45:34 nb81 kernel: [7352493.081079] [<ffffffff815c80df>] ?

换了一个服务器

Mar 7, 2014 - 1 minute read - Comments

上一家服务器的质量太差了。价钱贵,响应慢,还经常服务不可用。忍无可忍,换了东哥的虚拟主机。反正我只支持一个blog。 大家可以用新地址访问我的blog: http://shell909090.org/blog 希望没什么别的问题。如果有的话,可以发我email,或者通过twitter联系我。我现在已经不怎么上微薄了,切切。 PS: 不知为何,我这里发出去的同步到twitter没有经过短链接缩短服务,导致twitter上和facebook上的新文章通知都有问题。