记得几个星期前,有网友在“知乎”上问了个问题:如何优雅地使用Windows系统?结果被轰:去用Mac。但实际上,我认为“优雅”的使用Windows确实是有可能的,但是你必须严格控制这台机器的用途——比如,只限于开发,并且小心地挑选你的软件才行。
Continue reading
记得几个星期前,有网友在“知乎”上问了个问题:如何优雅地使用Windows系统?结果被轰:去用Mac。但实际上,我认为“优雅”的使用Windows确实是有可能的,但是你必须严格控制这台机器的用途——比如,只限于开发,并且小心地挑选你的软件才行。
Continue reading
很早以前,记得我是坚定的IE用户 Continue reading
Nvidia不支持KMS已经令人诟病很长时间了,可不支持就是不支持。我们只能通过各种方式,来获得一个在没有KMS情况下完美/半完美的分辨率。有些幸运的人,在通过添加内核参数vga=791/792,就成功让自己的1024×768显示器配合VESA使用最佳分辨率了。而有些Nvidia的显卡BIOS还不太一样,有的在最差的状态下只支持800×600。这样的80×24终端除了复古,没人想要吧。
Continue reading
Gentoo的Gnome3使用久了,你的“应用程序”集合就会出现各色的图标:失效的、无用的、重复的、图标烂/图标丢失的,还有Wine创建的大量快捷方式,严重影响了Gnome3的使用体验. 比如比尔盖子的桌面上有好多分辨率很低的三明治——好多版本的PyShell.
Continue reading
在之前的文章中已经提到了,Gentoo的mdadm在Intel的FakeRAID存在bug,会将一个三块正常硬盘组成的RAID5阵列少识别一块硬盘,但由于RAID5在2块硬盘也能正常运行。而重新启动计算机后,mdadm又能识别出三块硬盘,并开始重建RAID阵列。再次重启后,又回到最初的情况。
Continue reading
话说比尔盖子转换完文件系统之后,发现开机的时候有一些Warning。具体内容如下:
Use of the opts variable is deprecated and will
be removed in the future. Please use extra_commands or extra_started_commands.
也就是说,只要把init启动脚本中的”opts=”改成”extra_commands=”就OK了。但是,这项工作也太繁琐了。最终在Gentoo论坛上找到了解决方法,翻译过来,比尔盖子再修改一下,大致是:
注意,这个方法很快捷,同时也很脏。容易出现问题!
用root执行:
cd /etc/init.d mkdir /root/init.d_backups cp * /root/init.d_backups sed -e 's:opts=:extra_commands=:g' -e 's:${opts}:${extra_commands}:g' -e 's:$opts:$extra_commands:g' /etc/init.d/* -i重启。如果系统没挂,而且启动之后的Warning都消失了,就继续用root执行:
rm -r /root/init.d_backups如果系统挂了,很简单,用LiveCD启动系统,chroot之后(方法你应该懂得),root执行:
rm -r /etc/init.d cp /root/init.d_backups /etc/init.d重启,进入系统吧,有Warning就有吧。反正不影响正常使用。最好别再试验了。
反正比尔盖子是一次成功了,重启之后,Warning都消失了!如果你有兴趣,不妨看看原帖:http://forums.gentoo.org/viewtopic-t-465367-start-175.html。
比尔盖子的蜗牛笔记本在装上Gentoo后,终于变成蜈蚣了,速度快多了。
但是刚才突然想起,比尔盖子的/boot分区当时装机为了避免麻烦,没有使用ext4文件系统。虽然这几乎不会损失什么性能,但是比尔盖子还是想把它转换成ext4。
注意:请务必阅读“修复引导”部分,否则,到时候系统挂了比尔盖子就只能帮你了……如果你没有LiveCD,那么比尔盖子也帮不了你了。
怎么转换呢?首先,要先把它转换成ext3,这两条命令盖子都已经背熟了:
#先卸载,后日志,再强检。完事以后挂载。ext2就变ext3!
umount /dev/hda1
tune2fs -j /dev/hda1
fsck -f /dev/hda1
mount /dev/hda1
然后再转换成ext4,去网上查了查命令:
#先卸载,变结构,再强检。完事以后挂载。ext3就变ext4!
umount /dev/hda1
tune2fs -O extents,uninit_bg,dir_index /dev/hda1
fsck -f /dev/hda1
mount /dev/hda1
虽然转换完了,但是由于这样转换,虽然文件系统是ext4了,但是数据结构还是ext3。只有新的数据才是ext4格式。这不是瞎折腾吗?
这可通过整理磁盘碎片解决,但是由于ext4从来没有什么真正的“碎片”,因此磁盘碎片整理程序几年过去了还是没有稳定下来。但是,比尔盖子发现BFS调度器的作者:大名鼎鼎的澳大利亚黑客——CK,居然还写了一个能基本上无视文件系统,从抽象层就可以(我不知道我理解的是否正确,因此使用了删除符号,注意,这段内容仍然有效,只是我怕误导大家)整理磁盘碎片的bash脚本!
可以从这里获得:http://ck.kolivas.org/apps/defrag/defrag-0.08/defrag
把这个脚本放到你要整理的文件系统上,比如我要整理的是新的ext4分区:/boot。就把它放到/boot的根目录上,然后用root执行:
bash defrag
umount /dev/hda1
fsck -f /dev/hda1
mount /dev/hda1
在这里,为了防止这个脚本在整理磁盘碎片时胡乱破坏文件系统,因此再强制检查一次。稍等片刻,整理就完成了。现在可以删除这个脚本了。
需要注意的是,这时候如果你重新启动系统,那么你可能就再也进不去了!你只能看到永远的黑屏,没错,连内核信息都没有!
因为,文件系统转换以后,再加上用CK大神的脚本整理了磁盘碎片,因此我的/boot的GRUB已经有99%可能性已经被破坏了,因此,需要重装GRUB。
如果你转换/整理的文件系统不是引导分区,那么可以省略这步!
用root执行:
#因为比尔盖子的/boto分区是独立的,因此需要这样:
grub-install --root-directory=/boot /dev/hda1
如果提示没有错误,那么就说明GRUB已经修好了。
这一步是必需的,否则下一次将无法挂载修改后的文件系统。只能卡在内核提示的Kernel Panic的灾难信息上。
用root权限执行你喜欢的编辑器,比如Vim、Emacs,把里面的ext2改成ext4。
注意,如果你并没有转换某个ext2分区,请不要把它后面的ext2改成ext4。程序猿,Linuxer,你们懂得。
今天输入mail,发现root收到16000多封邮件,都是Cron发给我的。
我一看:
451 gmail.com: Name server timeout
天啊,这年头DNS也抽风?后来经过查阅资料,再加上一些回忆,终于想到了原因:
原来比尔盖子的VPS机房是支持IPv6的,可自从搬到日本去IPv6就没有了。但是Sendmail依赖IPv6,因此没有了它DNS也就查询不成功了。
解决这个问题的方法倒是挺简单:
cd /etc/mail
yum install sendmail-cf
#刚学会超级转义符号:单引号,用单引号引用的内容永远不会具有特殊含义,比双引号厉害。
#正好就用到了!
#下面这句话的意思是:在sendmail.mc的最后一行加上"dnl define(`confBIND_OPTS’, `WorkAroundBrokenAAAA’)dnl" 来屏蔽IPv6!
echo 'dnl define(`confBIND_OPTS’, `WorkAroundBrokenAAAA’)dnl' >> sendmail.mc
m4 sendmail.mc >sendmail.cf
make
service sendmail restart
然后,Sendmail终于把邮件发出去了!
昨天升级完Fedora 16后又闲着没事干,想起来以前看过一篇文章,可以安装一个插件让Linux实现歌词同步显示。于是尝试了许多Rtythmbox的插件,结果发现这些插件安装上去以后,都没有在Rtythmbox的插件列表中显示出来……
最后,发现了Osd-Lyrics。于是决定下载源码编译安装,结果发现编译失败。于是我去提交了一个Bug(Issue 244: Fedora 16 编译失败),结果10个小时就解决了!
现在编译安装的过程如下:
git clone git://github.com/tigersoldier/osd-lyrics.git
cd osd-lyrics
git checkout --track origin/develop
aclocal
autoheader
autoconf
automake --add-missing
./configure
make -j3
su -c "make install"
然后在Gnome3“应用程序”的“影音”中找到“Osd Lyrics”,打开,然后拿Rtythmbox放一首歌,歌词出来了!
随着即将结束的2011年,比尔盖子也对服务器进行了一些检查。但是比尔盖子网站的可用率未能达到100%,在此表示道歉。
故障分许:在2011年第三季度时出现了15小时的当机时间,这是由于网站搬迁机房造成的;而在2011年第四季度,由于比尔盖子所使用的Linux内核版本存在Bug,因此导致了多次的系统崩溃,总计崩溃时间达到了10小时。
年 | 季度 | 月 |
2011年
99.52%
1天14小时46分钟
|
第4季度
98.95%
10小时26分钟
|
11月
100%
|
10月
98.60%
10小时26分钟
|
||
第3季度
99.35%
15小时9分钟
|
09月
98.48%
10小时57分钟
|
|
08月
99.93%
33分钟
|
||
07月
99.51%
3小时39分钟
|
||
第2季度
99.51%
4小时50分钟
|
06月
99.90%
44分钟
|
|
05月
99.77%
1小时43分钟
|
||
04月
99.67%
2小时22分钟
|
||
第1季度
99.54%
8小时19分钟
|
03月
99.73%
2小时2分钟
|
|
02月
99.34%
4小时26分钟
|
||
01月
99.75%
1小时50分钟
|
||
2010年
99.32%
24小时8分钟
|
第4季度
99.12%
14小时34分钟
|
12月
99.75%
1小时50分钟
|
11月
99.60%
2小时54分钟
|
||
10月
98.68%
9小时48分钟
|
||
第3季度
99.42%
9小时34分钟
|
09月
98.75%
8小时58分钟
|
|
08月
99.81%
36分钟
|
监控项目 | 开始时间 | 恢复时间 | 故障持续时间 | 故障原因 | 故障分类 | ||
2011-10-20 | |||||||
![]() |
比尔盖子技术交流站 | 15:30:50 | 15:34:07 | 3分钟 | 无法连接服务器 | 网络故障 | |
2011-10-12 | |||||||
![]() |
比尔盖子技术交流站 | 01:59:57 | 02:00:59 | 1分钟 | 数据包全部丢弃 | 网络故障 | |
![]() |
比尔盖子技术交流站 | 01:21:41 | 01:22:41 | 1分钟 | 无法连接服务器 | 网络故障 | |
2011-10-08 | |||||||
![]() |
比尔盖子技术交流站 | 19:26:02 | 19:27:02 | 1分钟 | 数据包全部丢弃 | 网络故障 | |
2011-10-07 | |||||||
![]() |
比尔盖子技术交流站 | 15:30:33 | 16:02:34 | 32分钟 | 请求超时 | 软件故障 | |
2011-10-05 | |||||||
![]() |
比尔盖子技术交流站 | 01:11:35 | 08:13:48 | 7小时2分钟 | 请求超时 | 软件故障 | |
2011-10-04 | |||||||
![]() |
比尔盖子技术交流站 | 15:39:22 | 18:26:25 | 2小时47分钟 | 请求超时 | 软件故障 | |
2011-10-02 | |||||||
![]() |
比尔盖子技术交流站 | 09:36:47 | 09:37:48 | 1分钟 | 服务器无返回数据 | 网络故障 | |
2011-09-30 | |||||||
![]() |
比尔盖子技术交流站 | 09:48:41 | 18:20:58 | 8小时32分钟 | 无法连接服务器 | 软件故障 | |
![]() |
比尔盖子技术交流站 | 09:48:32 | 18:20:53 | 8小时32分钟 | 数据包全部丢弃 | 软件故障 | |
2011-09-10 | |||||||
![]() |
比尔盖子技术交流站 | 15:26:00 | 17:46:26 | 2小时20分钟 | 无法连接服务器 | 软件故障 | |
![]() |
比尔盖子技术交流站 | 15:21:45 | 17:27:16 | 2小时5分钟 | 数据包全部丢弃 | 软件故障 | |
![]() |
比尔盖子技术交流站 | 14:51:43 | 14:56:00 | 4分钟 | 无法连接服务器 | 网络故障 | |
2011-08-27 | |||||||
![]() |
比尔盖子技术交流站 | 07:03:50 | 07:35:56 | 32分钟 | 无法连接服务器 | 网络故障 | |
2011-08-21 | |||||||
![]() |
比尔盖子技术交流站 | 01:58:40 | 01:59:41 | 1分钟 | 无法连接服务器 | 网络故障 | |
2011-07-29 | |||||||
![]() |
比尔盖子技术交流站 | 16:11:48 | 16:28:50 | 17分钟 | 请求超时 | 网络故障 |
Copyright © 2023 比尔盖子 博客
Theme by Anders Noren — Up ↑