膘叔

ssh连接时，发现屏幕上一堆乱码，恐怕这种事情谁都遇到过吧。（我是使用SSH secure shell登录的）
这种情况的发生大多是安装时，语言包选择为中文导致的。一般有以下几种解决方法

1、RH（估计centOS也行）
vim /etc/sysconfig/i18n
内容改为：
LANG="zh_CN.GB18030"
LANGUAGE="zh_CN.GB18030:zh_CN.GB2312:zh_CN"
SUPPORTED="zh_CN.GB18030:zh_CN:zh:en_US.UTF-8:en_US:en"
SYSFONT="lat0-sun16"

2、UBUNTU
中文版的ubuntu遇到这种问题，可以尝试使用putty，因为putty可以通过修改 font, character set 设置来解决。
设置：
Window -> Appearance -> Font settings 选择宋体或新宋体:
Window -> Translation -> Character set translation on received data 选择 UTF-8:
然后基本就没有问题了，

或者尝试使用secureCRT登录，这款软件也能够自动识别。

再或者尝试把语言换为英文？
修改Ubuntu的命令行语言环境的2个步骤：

1、修改／etc/default/locale
如不存在则新建一个
如下：
LANG='en_US' #中文可以用zh_CN
LANGUAGE='en_US:en' #中文可以用zh_CN:zh

2、reboot即可
locale命令可以列出当前系统所用的所有语言设置

即使你搜索google，基本上也只有这几种解决方案了。呵呵，全部列出来，希望有用

文章来自至顶网，两年前的内容，只是感觉好象不错，就复制了过来。
原文链接如下：
http://soft.zdnet.com.cn/software_zone/2007/1022/570485.shtml
http://soft.zdnet.com.cn/software_zone/2007/1020/568251.shtml

很难想象，2居然比1先出来。

Linux 能有多小呢 ? 每一个做 embedded 系统的人都把小看成第一要务，其实这是不对的。小当然不会比较坏，但不一定比较好。如果系统使用 4MB 和 5MB 没有价格或性能上的差别，那 4MB 和 5MB 是一样好的。

到底有多小

废话说了一堆，那到底 Linux 有多小呢? 好吧，各位这么有小牛顿的精神。我也只好想办法生一个答案出来了。

首先我必须声明，我的不一定最小。不要说我在欺骗世人，你的核心比我小。我无意比较，我的数据只是给大家一个参考而己。不过我欢迎大家提出自己的心得，告诉大家怎么样做出更小的核心。

我使用的是 Mandrake 内付的 2.2.15，我没有修改任何一行程序码，完全只靠修改组态档得到这些数据。

首先，使用 make xconfig 把所有可以拿掉的选项都拿得。

不要 floppy；

不要 SMP,MTRR；

不要 networking,SCSI；

把所有的 block device 移除，只留下 old IDE device；

把所有的 character device 移除；

把所有的 filesystem 移除，只留下 minix；

不要 sound 支援。

相信我，我己经把所有的选项都移除了。这样做之后，我得到了一个 188K 的核心。 还不够小吗? OK，再加上一招，请把下列二个档案中的 -O3,-O2 用 -Os 取代。

./Makefile 
./arch/i386/kernel/Makefile

这样一来，整个核心水小了 9K，成为 179K。不过这个核心恐怕很难发挥 Linux 的功能，因此我决定把网络加回去。把 General 中的 network support 加回去，重新编译，核心变成 189 K。10K 换个 TCP/IP stack，似乎是很上算的生意。不过有 stack 没有 driver 也是惘然，所以我把 embedded board 常用的 RTL8139 的 driver 加回去，195K。

如果你需要 DOS 档案系统，那大小成为 213K。如果 minix 用 ext2 换代，则大小成长至 222K。不过大家要注意，那里的大小指的是核心档的大小。那和所需要的随取记忆体是二回事。这个数字代表的意义是你需要多小的 ROM 来存放你的核心。

Linux 所需的记忆体大约在 600~800 K 之间。1MB 可能可以开机了，但可能不太有用。因为可能连载入 C 程序库都有困难。2MB 应该就可以做点事了，但可能要到 4MB 以上才可以执行一个比较完整的系统。

到底谁占了这些空间

看到这里，是不是觉得 Linux 真的有点大。好吧! 那我们就来看看谁占用了这些空间，下面这个列表是从 222K 这个核心做出来的。

# wc  
arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o  
ipc/ipc.o  
fs/filesystems.a  
net/network.a  
drivers/block/block.a  
drivers/char/char.a  
drivers/misc/misc.a  
drivers/net/net.a drivers/pnp/pnp.a  
/usr/src/smalllinux/arch/i386/lib/lib.a  
/usr/src/smalllinux/lib/lib.a  
/usr/src/smalllinux/arch/i386/lib/lib.a

结果如下 :

243 2250 81946 arch/i386/kernel/kernel.o 
42 316 10569 arch/i386/mm/mm.o 
173 1541 74660 kernel/kernel.o 
266 2307 68053 mm/mm.o 
222 3139 123193 fs/fs.o 
49 602 21600 ipc/ipc.o 
263 2940 106504 fs/filesystems.a 
137 1510 65512 net/network.a 
92 719 39178 drivers/block/block.a 
230 2308 87556 drivers/char/char.a 
1 1 8 drivers/misc/misc.a 
83 721 25680 drivers/net/net.a 
1 1 8 drivers/pnp/pnp.a 
20 187 9526 /usr/src/smalllinux/arch/i386/lib/lib.a 
23 150 7714 /usr/src/smalllinux/lib/lib.a 
20 187 9526 /usr/src/smalllinux/arch/i386/lib/lib.a 
1865 18879 731233 total

先说明一下，这里的大小和最终的大小有点差别，但大致还是可以做个参考。这边显示 730K 实际上大约在 600K 左右。

很显然的，filesystem 相当的大。大约在 230K 左右，占了 1/3 的体积。记忆体管理占了 80K，和核心其它部份的总合差不多。TCP/IP stack 占了 65K，驱动程序占了 120K。SysV IPC 占了 21K，必要的话可以拿掉，核心档应该可以再小个 10K 左右。

所以如果要减核心大小，应该动那里呢? 答案应该很明显，当然是档案系统。Linux 的 VFS 减化了档案系统的设计，buffer cache, directory cache 增加了系统的效率。但这些对整个系统都在 flash 上的 embedded 系统而言根本就用处不大。如果可以把它们对拿掉，核心可以马上缩小 20K 左右。如果跳过整个 VFS，直接将档案系统写成一个 driver 的型式，应该可以将 230K 缩减至 50K左右。整个核心缩到 100K 左右。

从上面的数据来看，ucLinux 所减小的 mm 部份反到省的不多，主要是 mm 除了 virtual memory 之外，也要处理 memory allocation 的部份，这部份是省不得的。如果二者齐做，则 100K 以下的 Linux 核心不是不可能的事。

结语

如果有人有闲的话，不妨拿 2.0 或 1.0 的核心来试试。看能做出多小的核心。看完本文后，143K 的核心不再是技术上的挑战了，是吗? 也许明天就有人宣称做了 120K 的核心了。不过，所为何来，省那几十K。不如好好想想 compressed filesystem 等更有用的技术吧!

虽然在用LINUX，但其实对于它的安全，并不是很了解，所以，看到有这样的文章时，还是会记录一下。
原文：http://item.feedsky.com/~feedsky/phpv/~1232318/202448855/1235221/1/item.html
来自：PHP5研究室

俗称“脚本小鬼”的家伙是属于那种很糟糕的黑客，因为基本上他们中的许多和大多数人都是如此的没有技巧。可以这样说，如果你安装了所有正确的补丁，拥有经 过测试的防火墙，并且在多个级别都激活了先进的入侵检测系统，那么只有在一种情况下你才会被黑，那就是，你太懒了以至没去做该做的事情，例如，安装 BIND的最新补丁。

一不留神而被黑确实让人感到为难，更严重的是某些脚本小鬼还会下载一些众所周知的“root kits”或者流行的刺探工具，这些都占用了你的CPU，存储器，数据和带宽。这些坏人是从那里开始着手的呢?这就要从root kit开始说起。

一个root kit其实就是一个软件包，黑客利用它来提供给自己对你的机器具有root级别的访问权限。一旦这个黑客能够以root的身份访问你的机器，一切都完了。 唯一可以做就是用最快的效率备份你的数据，清理硬盘，然后重新安装操作系统。无论如何，一旦你的机器被某人接管了要想恢复并不是一件轻而易举的事情。

你能信任你的ps命令吗?

找出root kit的首个窍门是运行ps命令。有可能对你来说一切都看来很正常。图示是一个ps命令输出的例子。真正的问题是，“真的一切都正常吗?”黑客常用的一个 诡计就是把ps命令替换掉，而这个替换上的ps将不会显示那些正在你的机器上运行的非法程序。为了测试个，应该检查你的ps文件的大小，它通常位于 /bin/ps。在我们的Linux机器里它大概有60kB。我最近遇到一个被root kit替换的ps程序，这个东西只有大约12kB的大小。

另一个明显的骗局是把root的命令历史记录文件链接到/dev/null。这个命令历史记录文件是用来跟踪和记录一个用户在登录上一台Linux机器 后所用过的命令的。黑客们把你的历史纪录文件重定向到/dev/null的目的在于使你不能看到他们曾经输入过的命令。

你可以通过在 shell提示符下敲入history来访问你的历史记录文件。假如你发现自己正在使用history命令，而它并没有出现在之前使用过的命令列表里，你 要看一看你的~/.bash_history 文件。假如这个文件是空的，就执行一个ls -l ~/.bash_history命令。在你执行了上述的命令后你将看到类似以下的输出：

-rw------- 1 jd jd 13829 Oct 10 17:06 /home/jd/.bash_history

又或者，你可能会看到类似以下的输出：

lrwxrwxrwx 1 jd jd 9 Oct 10 19:40 /home/jd/.bash_history -> /dev/null

假如你看到的是第二种，就表明这个 .bash_history 文件已经被重定向到/dev/null。这是一个致命的信息，现在就立即把你的机器从Internet上断掉，尽可能备份你的数据，并且开始重新安装系统。

寻找未知的用户账号

在你打算对你的Linux机器做一次检测的时候，首先检查是否有未知的用户账号无疑是明智的。在下一次你登录到你的Linux机器时，敲入以下的命令：

grep :x:0: /etc/passwd

只有一行，我再强调一遍，在一个标准的Linux安装里，grep命令应该只返回一行，类似以下：

root:x:0:0:root:/root:/bin/bash

假如在敲入之前的grep命令后你的系统返回的结果不止一行，那可能就有问题了。应该只有一个用户的UID为0，而如果grep命令的返回结果超过一行，那就表示不止一个用户。

认真来说，虽然对于发现黑客行为，以上都是一些很好的基本方法。但这些技巧本身并不能构成足够的安全性，而且其深度和广度和在文章头提到的入侵检测系统比起来也差得远。

以下内容来自于两个博客的内容合并。
首先是来自于冰山上的博客的关于atime、mtime与ctime的介绍（我估计作者也是COPY来的，因为最后两段明显单词断行了，没有修改）：

原文：http://xinsync.xju.edu.cn/index.php/archives/4683

atime 访问时间(access time)：访问时间是文件最后一次被读取的时间。因此阅读一个文件会更新它的访问时间，而它的改变时间并没有变化(有关文件状态的信息没有被改变)，它的修改时间也同样没有变化(文件内容本身没有被改变)；

mtime 修改时间(modification time)：文件内容最后被修改的时间。如 echo “Hello” >myfile ，则myfile的mtime被改变，同时ctime和atime也被改变；

ctime 改变时间(change time)：文件状态（status）最后被改变的时间。如 chmod a+w myfile ，则myfile的ctime被改变，atime和mtime都不变；

参考：

st_atime
Time when file data was last accessed. Changed by  the following   functions:   creat(),   mknod(),   pipe(), utime(2), and read(2).

st_mtime
Time when data was last modified. Changed by the  fol-lowing  functions:  creat(), mknod(), pipe(), utime(),and write(2).

st_ctime
Time when file status was last changed. Changed by the following   functions:   chmod(),   chown(),  creat(),link(2),  mknod(),  pipe(),  unlink(2),  utime(),  and write().

然后下面的内容又来自于知道分子的博客：http://hutuworm.blogspot.com/2009/03/blog-post_31.html

Linus 大神最近将一项名为 relatime 的特性设定为内核默认行为。（参阅：Matthew Garrett，Reducing disk use）

UNIX 文件系统中的 ctime、mtime、atime 属性分别记录了文件的创建时戳、修改时戳和访问时戳。每当有进程创建、修改、访问某个文件时，文件系统就会保存相应的时戳。对于一般用户而言，文件系统自 动记录这些时戳所花费的时间根本不值一提，完全可以忽略不计。但对于某些特定用途的生产服务器，比如存储大量小图片文件的服务器（写少读多），若每次读取 一个文件都要修改该文件的 atime——想像中的单纯读取操作，实际上却是一读一写——如果这些服务器访问量还挺大，那么这个过程中的消耗则无疑值得斤斤计较、细细考究了。

以 往我们为了节省不必要的 atime 改写，常常采用的方法，是通过 mount 选项 noatime 挂载文件系统，完全摈弃该属性。但随之而来的问题是，某些依赖于 atime 属性的系统程序无法正常工作。而 relatime 补丁的改进之处在于，仅当 atime 比 ctime 或 mtime 更早，或者早于当前时间 24 小时以上，系统才会去修改 atime，由此就大幅度减少了 atime 改写操作，提升了文件系统性能。该项功能已在 Fedora 和 Ubuntu 去年的新版本中发布。

其 实，可以节省的地方还有很多。上周小算了一笔账，某个页面引用的 js 和 css 文件 Expire 时间为 900 秒，一部分图片的 Expire 时间为 12 小时，另一部分图片的 Expire 时间为 4 天——假设该页面内容不变、访问量不变，那么一年的相关静态文件总下载量为数万 GB；如果把这些静态文件的 Expire 时间统一调整为一个月，那么总下载量可以下降一个数量级，降到几千 GB；如果胆子大一点、步子快一点，统一调整为一年，那么总下载量还可以再降一个数量级，降到几百 GB。阿米豆腐，这样的估算结果真是令人咋舌。

这两天又看了三篇跟性能优化相关的报道。一篇报道是 Linux Magazine 采访 Theodore Ts'o，其中提到 Google 的工程师向 Ext4 文件系统开发者提交了一个取消日志补丁，以获得更高的性能，可以看出，这个功能对于 Google 非常重要。一篇报道是 Red Hat 官方新闻，说 RHEL 5.3 开始支持 Intel 的 QuickPath 内存技术，运行内存密集型的应用可以获得两倍性能提升——显然这得归功于 Nehalem CPU 的崭新架构和超强性能。另一篇报道是 Linux Kernel 2.6.24 到 2.6.29 横向测试，OpenSSL 在 2.6.29 内核上测得性能比前几个版本高出一倍：


无论如何，关注这些信息，稍微算一算，我们就知道随便从其中找一项出来优化，可以提升多少性能、节省多少资源。虽说咱不差钱，但能省干嘛不省呢？

网上的资料，都是用svn update命令在post-commit里面进行同步，这里面很多人都忽略了讲最重要的一点，那就是在svn update之前，该目录必须要先用svn checkout一下，否则。update目录会直接忽略该目录。
这，几乎所有的教程里都没讲，我是试了半天啊。。。
后来，也找到了一篇类似教程。希望看到的人少走点弯路。

原文：http://www.unix-center.net/bbs/viewthread.php?tid=11607