由于太长时间没有动了,所以我决定还是把blog程序从2.6升级到最新的2.7.1版本

由于后台管理升级挺大的,请各位管理员熟悉一下使用的感觉,如果有什么问题的话可以联系我

另外由于spam太多,我将我的Akismet key的使用在这个博客上了,希望各位admin不要把这个key再次使用,毕竟这是我的private key,不希望被Akismet给封杀的说

　　2009年3月3日晚，武汉大学的momodi同学通知我说，1017题交以前通过的代码结果是WA，开始怀疑是SPJ的问题，后来发现%JUDGE_HOME%目录的权限居然是750，并且所有者是root，也许是这个原因导致了切换JUDGE用户的时候无法写入文件，马上修复这个错误之后，提交了一个1000的C++代码，依然是WA，问题还没解决。
　　把1000的代码拿下来，手动编译运行，执行g++ xxx.cc -o xxx的时候，系统报找不到命令，原来问题出在这里，G++不知道何时搞丢了，马上apt装了一个，重新提交代码，返回结果AC！看来问题差不多解决了，不过，受这个问题影响的提交可能还不少，马上REJUDGE最近的一些提交，直接到命令行下执行SQL语句，很不幸的是，不知道怎么搞的，我明明设置了solution_id>19000的，但是却发现3000多号的提交，状态居然被改成了compiling了，这还了得，翻了好多页之后，发现这种情况不少，没办法啦……全部REJUDGE吧，否则实在搞不定，于是乎，一个SQL　REJUDGE了所有20000多个提交，然后就丢在那里让它跑了。
　　3月4日早上起来，发现已经REJUDGE到18xxx了，9点左右，基本REJUDGE完毕，看了看Ranklist，却发现原来排名第一的Rocket323已经从第一名的位置上掉下来很多了，而且，很多提交都变成了Compile Error，我ssh到服务器上检查，准备upgrade一下系统，一个apt-get dist-upgrade之后，发现有400多个MB的文件需要下载……我的天哪……这种情况对于Debian来说，根本是不可能的，我查看了一个sources.list，发现涉及版本的地方，都写的是stable，而之前的stable一直是etch(Debian4.0)，而最近lenny(Debian5.0)刚刚成为stable，etch(Debian4.0)成为了oldstable，检查g++，发现版本成了4.3.2，而且Rocket323同学大部分无法通过编译的代码基本上是用了memset函数而没包含memory.h或者string.h头文件，将代码弄到其他4.1或者3.4版本的g++下面，编译通过。
　　马上%s/stable/etch/g，然后重新dist-upgrade，删掉g++/gcc-4.3版本的，重新安装了4.1.2版的g++，然后把所有CE掉的6000多个提交重新REJUDGE，终于在19:00的时候，全部Rejudge结束，Rocket323同学重回榜首!
　　事故总结完毕，这个事故还是蛮严重的，以后要注意几点。
　　1. 生产机不是测试机，最重要的是稳定，除非对性能提高非常大，或者修复了很严重的BUG，否则最好不要随便乱升级。
　　2. 某些同学，写代码的时候最好要标准，用到的头文件，不要以为有的编译器会自动给带上就不包含了，一旦编译器换掉，马上就会Compile Error！