Gentoo神秘而又气死人的RAID bug

昨天更新完Gentoo,重新启动机器后发现,Gentoo不认RAID了。又重启一下,这回不但依然不认,英特尔的芯片还告诉我:RAID已损坏,进入系统后将Rebuild⋯⋯我发现我的Fedora还能认阵列,马上进去Rebuild。Rebuild好了,发现每次进入Fedora没有任何问题,进入Gentoo就会这样。

后来进入Gentoo仔细研究,发现Gentoo把三块硬盘组成的RAID 5认成了两个阵列。Rebuild完之后,倒是能正确的认出来,但是由于之前造成数据不同步,导致Rebuild。经过搜索,发现这个Bug已经有所报告,是由于关机时没有正确停止RAID造成的,之前也遇到过,并自己解决。但是,我这样不认+阵列坏的问题,倒是离奇。

只能使用重装系统之大法了。

遭遇最坑爹的在线订餐——必胜宅急送

今天打算在http://www.4008123123.com(必胜宅急送)上订餐,结果发现Web页面加载不全,点确定就提示“请选择订餐时间”,可根本就没有这个选项。看来是浏览器兼容问题了,用IE、IE(兼容模式)、Chrome、Firefox狂试,最后用Linux Firefox浏览器,选项终于出现了……而奇怪的是Windows下的Firefox居然不行?上去之后选择要订的食物,点击提交的时候要么没有反应,要么就无限的“正在加载”。

看到网络用的是JSP——甲骨文的Java到底考不靠谱?试了10来次都是这样。最后发现网络页面加载残缺不全——会不会只是线路问题。打开SSH连接到比尔盖子位于日本东京的服务器,然后用端口转发做代理,居然成功了。原因看来就是线路问题,不过有两种可能:第一种情况是:比尔盖子使用双WAN路由器,很可能是负载均衡导致有两个IP发出请求导致服务器端判断错误——不过在HTTP上看少见到这种情况——只能说是判断策略不成熟;第二种情况就是联通线路问题了。

因此,双WAN路由器出现这种情况不妨先禁用负载均衡,如果太麻烦就每次有这种交易的时候打开代理或者VPN就可以了。

关于Vim&Emacs的中文分词相关讨论

在Vim中,基于单词的文本编辑命令是相当有用的。比如使用命令3dw即可删除三个单词。但是在中文中,由于存在相当烦人的分词问题,因此,也就无法实现这样的功能。

但情况远远比这更糟,vi设计之初就遵从的是KISS原则。标点符号和空格分词等,是写死的C代码中的,而Vim也是如此。反观Emacs,则是全部可以使用配置文件进行配置的。正是因为Emacs这种行事风格,也才导致了软件功能膨胀,不过确实提供了神一般的可定制性。

而关于中文分词,我的建议很简单:在Vim读入文件后使用外部工具进行分词,然后反馈给Vim插件,Vim插件检测用户光标的位置,并把cw、dw这样的键映射给插件。如果用户使用dw,那么就根据词语使用d3l来代替dw。

不过这样有一些需要讨论的地方:

1.分词的准确性问题
中文分词一直是一个难题,除了大规模数学统计的方法可以获得较准确的结果外,只能指望今后的人工智能了:( 如果是这样,Vim的分词将不会给用户带来方便,而是烦恼——一些莫名奇妙的词语发生了改变,而不是想要的结果。

2.“大词”和“小词”
拿一个常见的词语来举个例子:发展中国家。这个词语在分词不准确的情况下会分成:发展/中国/家,而在分词准确的情况下则能正确将“中”分出来。但问题是,“发展中国家”单独也成一词。用户在一些情况下可能会希望对“发展中国家”为单位进行操作,但有时仅仅希望删去“发展”一词。如何权衡就是一个很大的问题了。

3.“分词线”
为了避免不可预测的分词结果带来反而难以操作的后果,“分词线”是一个需要实现的功能。即,在每一个分成的汉语词中添加下划线或是斜杠等符号来将词语隔开。但是要在Vim中实现“所见即所得”式的排版效果来显示出“删除线”,恐怕是无法解决的一大问题了,而Emacs可能还好一些。

另外,我对汉语分词技术的一点幻想是“定义词”。假如文章中有这么一句话:“我把它叫做一个‘集合’”,那么分词程序可以根据语义,实时的定义新词。先显然,基本无法实现。另外,我对Vim中中文的折行、不停切换输入法,和不支持中文引号匹配导致前后引号混用的问题也有些意见。显然,Emacs里自带输入法模块,没有此问题。据说VimIM可以解决汉语和vi命令冲突的问题?

欢迎大家对以上问题进行交流。

比尔盖子

用Hash算法来判断文件是否修改

这篇文章我写了数百字,但因为Firefox的Bug导致提交了空白内容。

Fedora Linux下GVim无菜单、乱码的解决方法

有时,Linux系统安装完GVim后,你会发现它在UTF8中文环境下,无菜单和乱码。原来,GVim是根据系统LANG变量来检测语言并使用相应语言文件的。但是,对于中文,GVim只能识别zh_CN.utf-8,而不能识别不带“-”的zh_CN.utf8(晕)!

解决的方法很简单,到GVim的文件目录的lang目录下,比如/usr/share/vim/vim73/lang,然后做一个软链接(符号链接):

ln -s menu_zh_cn.utf-8.vim menu_zh_cn.utf8.vim

再打开GVim,你就会发现菜单正常了!

我的~vimrc

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
set nocompatible
source $VIMRUNTIME/vimrc_example.vim
source $VIMRUNTIME/mswin.vim
behave mswin
 
set diffexpr=MyDiff()
function MyDiff()
  let opt = '-a --binary '
  if &diffopt =~ 'icase' | let opt = opt . '-i ' | endif
  if &diffopt =~ 'iwhite' | let opt = opt . '-b ' | endif
  let arg1 = v:fname_in
  if arg1 =~ ' ' | let arg1 = '"' . arg1 . '"' | endif
  let arg2 = v:fname_new
  if arg2 =~ ' ' | let arg2 = '"' . arg2 . '"' | endif
  let arg3 = v:fname_out
  if arg3 =~ ' ' | let arg3 = '"' . arg3 . '"' | endif
  let eq = ''
  if $VIMRUNTIME =~ ' '
    if &sh =~ '\<cmd'
      let cmd = '""' . $VIMRUNTIME . '\diff"'
      let eq = '"'
    else
      let cmd = substitute($VIMRUNTIME, ' ', '" ', '') . '\diff"'
    endif
  else
    let cmd = $VIMRUNTIME . '\diff'
  endif
  silent execute '!' . cmd . ' ' . opt . arg1 . ' ' . arg2 . ' > ' . arg3 . eq
endfunction
 
"" exec "!e: && cd  E:\\PortableApps\\flake8-1.3 && C:\\Python27\\python.exe E:\\PortableApps\\flake8-1.3\\setup.py build"
"" exec "!e: && cd  E:\\PortableApps\\flake8-1.3 && C:\\Python27\\python.exe E:\\PortableApps\\flake8-1.3\\setup.py install"
set autoindent " same level indent
set smartindent " next level indent
set expandtab
set tabstop=4
set shiftwidth=4
set softtabstop=4
set tags=tags;
set autochdir 
 
call pathogen#infect()
filetype plugin on
filetype plugin indent on
autocmd FileType python setlocal et sta sw=4 sts=4
let Tlist_Ctags_Cmd = 'E:\PortableApps\ctags58\ctags'
let g:pydiction_location = 'E:\PortableApps\gVimPortable\App\vim\vim73\ftplugin\pydiction\complete-dict'
set encoding=utf-8
set langmenu=zh_CN.UTF-8
language message zh_CN.UTF-8
 
let Tlist_Inc_Winwidth=0
let Tlist_Use_Right_Window=1
let Tlist_File_Fold_Auto_Close=1
 
func! Run()
        exec "w! temp.py"
        if &filetype == "python"
			exec '!C:\Python27\Python E:\PortableApps\stu\temp.py'
        endif
endfunc
 
map <F6> :call Run()<CR>
 
set mouse=a
set nu
 
func! Run16en()
        exec "%!xxd"
endfunc
 
func! Run16de()
        exec "%!xxd -r"
endfunc
 
map <F9> :call Run16en()<CR>
map <F10> :call Run16de()<CR>
 
set guifont=Courier_new:h11
"解决菜单乱码
source $VIMRUNTIME/delmenu.vim
source $VIMRUNTIME/menu.vim
"解决consle输出乱码
language messages zh_CN.utf-8

VB6.0中“取消 Pentium(tm) FDIV 安全性检查”是什么意思

最近比尔盖子在用VB6.0编写一个小型程序。在高级编译优化选项中,有一项:“取消 Pentium(tm) FDIV 安全性检查”,这是什么意思呢?在查阅了资料以后,终于明白了,我们就来了解一下吧。

1994年10月,美国弗吉尼亚州Lynchburg College数学系教授Thomas Nicely发现用电脑处理长除法时一直出错。他用一个数字去除以824,633,702,441时,答案一直是错误的。事后才知道,这位教授使用的60-100MHz P5版本奔腾处理器在浮点运算单元有一个问题,原因是英特尔为了加速运算,将整个乘法表烧录在处理器上面,但是2048个乘法数字中,有5个输入错误。在极少数情况下,会导致除法运算的精确度降低甚至出错。这就是后来臭名昭著的Pentium FDIV bug。

因此,为了避免由于处理器bug导致的运算错误,很多编译器都增加了一个编译选项,可以让程序通过间接运算的方法绕过这个FDIV bug,避免在有 FDIV bug的奔腾处理器上运算错误。但是,由于如今几乎已经不可能有人使用这种老奔腾处理器了,因此可以在VB6.0或其它的编译器中(如果有的话),安全的“取消 Pentium(tm) FDIV 安全性检查”,可以轻微提高性能,同时不会导致任何异常。

最后送上十几年前的那个笑话:英特尔有新格言了

United We Stand, Divided We Fall.

注:这句话原出自《伊索寓言》,翻译过来即是

合即立,分即跨。

但是Divided在这里是“除法”的意思。于是就有了翻译过来大概是

加法我们对了,除法我们错了。

“mysql-bin.000001″占用超大空间

最近几个月服务器总是频繁当机,导致比尔盖子的可用性得不到保证。但说也奇怪,当机的时候,服务器可以正常连接,Nginx也看似正常,但就是PHP-FPM失去响应。后来无意中df -h一下,发现:

rootfs 7.7G 7.7G 0 100% /

根目录满了!便认为是日志太多,清理了下日志。但基本每个一个星期日志就会满。弄得比尔盖子不得安宁。后来就把/var独立分区了,但依然不奏效,有多少占多少。也清理过/var/tmp和/var/cache,但效果依然有限。

今天,耐着性子du -ah,发现/var/lib/mysql占用空间异常,cd到这里ls -lh后发现:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
 -rw-rw---- 1 mysql mysql 5242880 Feb 27 14:49 ib_logfile0
 -rw-rw---- 1 mysql mysql 5242880 Dec 27 17:55 ib_logfile1
 -rw-rw---- 1 mysql mysql 588M Mar 12 02:03 maria_log.00000003
 -rw-rw---- 1 mysql mysql 52 Mar 12 01:54 maria_log_control
 drwx------ 2 mysql root 4.0K Jan 15 14:28 mysql
 -rw-rw---- 1 mysql mysql 20K Dec 27 17:54 mysqld-bin.000001
 -rw-rw---- 1 mysql mysql 715K Dec 27 17:54 mysqld-bin.000002
 -rw-rw---- 1 mysql mysql 625 Dec 28 11:46 mysqld-bin.000003
 -rw-rw---- 1 mysql mysql 125 Dec 27 18:20 mysqld-bin.000004
 -rw-rw---- 1 mysql mysql 125 Dec 27 18:20 mysqld-bin.000005
 -rw-rw---- 1 mysql mysql 125 Dec 27 18:21 mysqld-bin.000006
 -rw-rw---- 1 mysql mysql 125 Dec 27 18:21 mysqld-bin.000007
 -rw-rw---- 1 mysql mysql 125 Dec 27 18:22 mysqld-bin.000008
 -rw-rw---- 1 mysql mysql 125 Dec 27 18:22 mysqld-bin.000009
 -rw-rw---- 1 mysql mysql 20K Dec 27 18:22 mysqld-bin.000010
 -rw-rw---- 1 mysql mysql 715K Dec 27 18:22 mysqld-bin.000011
 -rw-rw---- 1 mysql mysql 125 Dec 27 18:24 mysqld-bin.000012
 -rw-rw---- 1 mysql mysql 125 Dec 27 18:25 mysqld-bin.000013
 -rw-rw---- 1 mysql mysql 125 Dec 27 18:27 mysqld-bin.000014
 -rw-rw---- 1 mysql mysql 125 Dec 28 09:55 mysqld-bin.000015
 -rw-rw---- 1 mysql mysql 125 Dec 28 11:41 mysqld-bin.000016
 -rw-rw---- 1 mysql mysql 125 Dec 28 11:42 mysqld-bin.000017
 -rw-rw---- 1 mysql mysql 125 Dec 28 12:07 mysqld-bin.000018
 -rw-rw---- 1 mysql mysql 1.4K Dec 28 12:49 mysqld-bin.000019
 -rw-rw---- 1 mysql mysql 125 Dec 28 16:31 mysqld-bin.000020
 -rw-rw---- 1 mysql mysql 107M Dec 28 18:30 mysqld-bin.000021
 -rw-rw---- 1 mysql mysql 1.2M Dec 30 09:22 mysqld-bin.000022
 -rw-rw---- 1 mysql mysql 125 Dec 30 09:26 mysqld-bin.000023
 -rw-rw---- 1 mysql mysql 3.8K Dec 30 12:29 mysqld-bin.000024
 -rw-rw---- 1 mysql mysql 59M Jan 11 21:34 mysqld-bin.000025
 -rw-rw---- 1 mysql mysql 10M Jan 14 15:16 mysqld-bin.000026
 -rw-rw---- 1 mysql mysql 186K Jan 15 05:16 mysqld-bin.000027
 -rw-rw---- 1 mysql mysql 21K Jan 15 14:46 mysqld-bin.000028
 -rw-rw---- 1 mysql mysql 13K Jan 15 15:12 mysqld-bin.000029
 -rw-rw---- 1 mysql mysql 62M Jan 17 16:36 mysqld-bin.000030
 -rw-rw---- 1 mysql mysql 63M Jan 18 17:10 mysqld-bin.000031
 -rw-rw---- 1 mysql mysql 125 Jan 18 17:16 mysqld-bin.000032
 -rw-rw---- 1 mysql mysql 21K Jan 18 17:23 mysqld-bin.000033
 -rw-rw---- 1 mysql mysql 118M Jan 22 12:41 mysqld-bin.000034
 -rw-rw---- 1 mysql mysql 209K Jan 22 12:59 mysqld-bin.000035
 -rw-rw---- 1 mysql mysql 117M Jan 28 11:59 mysqld-bin.000036
 -rw-rw---- 1 mysql mysql 125 Jan 28 13:46 mysqld-bin.000037
 -rw-rw---- 1 mysql mysql 24M Jan 28 16:01 mysqld-bin.000038
 -rw-rw---- 1 mysql mysql 460K Jan 28 16:10 mysqld-bin.000039
 -rw-rw---- 1 mysql mysql 7.0M Jan 28 16:52 mysqld-bin.000040
 -rw-rw---- 1 mysql mysql 2.3M Jan 28 17:12 mysqld-bin.000041
 -rw-rw---- 1 mysql mysql 2.1M Jan 28 17:27 mysqld-bin.000042
 -rw-rw---- 1 mysql mysql 173K Jan 28 17:37 mysqld-bin.000043
 -rw-rw---- 1 mysql mysql 378K Jan 28 17:44 mysqld-bin.000044
 -rw-rw---- 1 mysql mysql 79K Jan 28 17:50 mysqld-bin.000045
 -rw-rw---- 1 mysql mysql 272K Jan 28 18:12 mysqld-bin.000046
 -rw-rw---- 1 mysql mysql 156K Jan 28 18:15 mysqld-bin.000047
 -rw-rw---- 1 mysql mysql 962K Jan 28 18:33 mysqld-bin.000048
 -rw-rw---- 1 mysql mysql 43K Jan 28 18:40 mysqld-bin.000049
 -rw-rw---- 1 mysql mysql 28M Jan 29 11:43 mysqld-bin.000050
 -rw-rw---- 1 mysql mysql 125 Jan 29 11:46 mysqld-bin.000051
 -rw-rw---- 1 mysql mysql 139K Jan 29 12:37 mysqld-bin.000052
 -rw-rw---- 1 mysql mysql 135K Jan 29 12:44 mysqld-bin.000053
 -rw-rw---- 1 mysql mysql 409M Feb 9 23:18 mysqld-bin.000054
 -rw-rw---- 1 mysql mysql 482M Feb 17 09:37 mysqld-bin.000055
 -rw-rw---- 1 mysql mysql 542M Feb 27 12:30 mysqld-bin.000056
 -rw-rw---- 1 mysql mysql 125 Feb 27 12:31 mysqld-bin.000057
 -rw-rw---- 1 mysql mysql 125 Feb 27 14:48 mysqld-bin.000058
 -rw-rw---- 1 mysql mysql 854M Mar 13 12:08 mysqld-bin.000059
 -rw-rw---- 1 mysql mysql 1.1K Feb 27 14:49 mysqld-bin.index

上帝老天爷,这些log和bin都是什么玩意儿?!最后找到资料:

mysql-bin.000001、mysql-bin.000002等文件是数据库的操作日志,例如UPDATE一个表,或者DELETE一些数据,即使该语句没有匹配的数据,这个命令也会存储到日志文件中,还包括每个语句执行的时间,也会记录进去的。这主要是用于操作审查和多数据库同步的。ib_logfile则是用来记录InnoDB的表一致性的,只有在当机后才能发挥作用。maria_log.00000003则是比尔盖子使用的MariaDB特有的文件,作用也差不多。

但是对比尔盖子来说,没有主从数据库,也不用审查操作,这些文件完全没有任何用处!因此,首先清理一下这些文件。然后编辑mysql配置文件,组织其再记录这些日志,铲草除根。Gentoo的MySQL日志在/etc/mysql/my.cnf。把里面的log-bin这一行注释掉。

然后重启MySQL服务器,问题搞定!可用空间瞬间增加数GB!

一个不好的冒泡排序算法实现

最近在研究在研究Python,先是做了一个凯撒加密,现在则实现了冒泡排序算法。在实现这个算法时,坚决没有看现成的例子,完全是冒泡排序的文字叙述实现的。

因此,这个算法实现有很多没用的循环和判断,只是练习,在产品中使用肯定是不行的。另外代码中还包括性能统计swapwhiletime,分别计算的是数字的交换次数和循环的进入次数,通过此统计可以看出这个实现多么低效。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
#!/usr/bin/python3
times=0
times2=0
swap=0
whiletime=0
list=[858282,4252,5825725,8752,-2825245,8725,-82257465]
 
while times2 < len(list) -1:
        whiletime+=1
        while times < len(list)-1:
                whiletime+=1
                times+=1
                if list[times-1] > list[times]:
                        swap+=1
                        a=list[times-1]
                        b=list[times]
                        list[times-1]=b
                        list[times]=a
        times2+=1
        times=0
 
print(list)
print('Swap times:',swap)
print('While times:',whiletime)

Python实现移位密码(凯撒密码)加密

实现移位密码,就是将字母从字母表中向左移动或向右移动。比尔盖子首先想到了ANSI码,但由于不知道怎么处理出界,因此又用列表解决问题。等修改完列表,突然又想到ANSI的解决方案。因此,才写了两个版本。大家根据需求用吧。如果有bug务必提出!

这里有两段代码可以实现,一个是用ANSI码实现;另一个是用列表实现。
但是这些代码一点都不“美”,还需修改。

更新1:列表版的代码不但不美,而且还有bug,比尔盖子已经做了修改!
更新2:ANSI版的代码虽然实现简单,但是没有注释,而且有两个严重bug,比尔盖子也已经修改!
更新3:使用取余数来代替while循环减去26,在明文、密钥超长的情况下提速至少100倍;化简了ANSI版出界对折的公式。

注:无论代码里是否有声明, 这里的声明将覆盖掉其中的声明。
代码使用GPL v3或更高版本发布。

ANSI版:

这里的代码已经修改了,有了详细注释,而且修正了bug。
很抱歉,代码太多了,因此请去我的Github:https://github.com/biergaizi/caesar-encrypt/tree/查看各个版本,ANSI版的文件名叫”ansi.py”。

列表版:

这里的代码已经修改了,更加美,而且修正了bug。

新版

很抱歉,代码太多了,因此请去我的Github:https://github.com/biergaizi/caesar-encrypt/tree/查看各个版本,列表版的文件名叫”list.py”。