ssh -X

Warning: No xauth data; using fake authentication data for X11 forwarding.
不存在xauth命令

Warning: untrusted X11 forwarding setup failed: xauth key data not generated
xauth命令出错
X server 没有启动

UNIX系统的命令很多，但是巧妙使用命令的方法更多。随着经验的积累和观察学习其他用户的实践，我们也可学会解决特殊问题的方法。这里谈谈自己使用UNIX系统中stty命令的一些体会，希望能与你共享。

1．stty(set tty，设置tty)命令用于检查和修改当前注册的终端的通信参数。UNIX系统为键盘的输入和终端的输出提供了重要的控制手段，可以通过stty命令对特定终端或通信线路设置选项。
可以在stty命令中使用-a查看当前注册终端的设置情况。
$ stty -a
Speed 9600 baud; line =0;intr= DEL;quit = ^;erase = ^h;kill =^U; eof = ^d;start=^q;stop=^s
-parenb -parodd cs8 -cstopb -hupcl cread -clocal -loblk
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl -iuclc
ixon ixany -ixoff
isig icanon -xcase echo echoe echok -echonl -noflsh
opost -olcuc onlcr -ocrnl -onocr onlret ofill ofdel tab3
需要时，这里显示的各种选择都可以重新配置。每种终端选项都有自己的名字（如ixon），其中大多数要么被设置要么被清除。在stty中相应选项前冠以负号（-），该选项被清除（禁止）；如果无负号，该选项被设置。
当希望修改各选择的值时，应在stty命令中正确书写相应选项。如命令
$ stty -ixon
将流控制设置为OFF，而命令
$ stty ixon
则将其置为ON。在stty命令中可以同时设置多个选项：
$ stty ixon 1200
该命令将终端设置为1200波特，并将流控制置为ON。
当选项的列表较长时，应当小心所做的修改造成会话的混乱。典型的情况下，终端在设置不正确时完全不能工作。经常出现的现象是列输出显示或用户的击键不能被shell正确接受。有时NEWLINE可能只显示或走一行但不回行，即用户输入的NEWLINE符不能被shell正确读取。建立新注册标识的过程通常建立了正确的stty选项，在日常使用中很少需要修改。但如果变量TERM的设置不正确或用户希望使用新的终端或通信渠道（如局域网），则需要修改stty的选项。
如果你在某个机器中注册后终端操作正常，但后来因故发生了混乱，那么最佳的解决方法是先注销然后再向系统注册。因为注册时系统会重新设置相应选项。还有一种不太严格的解决办法是：
$ stty sane
命令sane最常出现在大多数终端的stty选项的集合中。它并不改变通信信道的速率，但当终端发生混乱时，通常能够产生有益的效果。命令sane可能使全屏幕应用程序(如vi)不能正确工作，而且在设置了选项sane之后，如果不能解决任何问题，就应立即注销，然后再注册。如果终端在注册后依然不能正确工作，用户的注册可能是不成功的。
如果终端已经混乱，NEWLINE键不能结束命令行，可以用CTRL-J代替NEWLINE直到用户执行stty sane。此时，再用CTRL-J终止stty sane，使系统恢复正常。
stty命令的几项主要选项功能为：
选项parenb使终端进行奇偶校验，-parenb则是禁止校验；
选项cs5、cs6、cs7和cs8分别将字符大小设为5、6、7和8比特；
选项300、600、1200、2400、4800、9600和19200设置波特率；
cstopb和-cstopb分别设置两个或一个停止位；
tabs使系统使用制表符而不是空格序列，因此减少了输出量，选项-tabs仅使用空格，当终端不能正确处理制表符（tab）时应使用该项。
　

2． stty还可用于控制一些具有特殊控制功能的键。系统可能已经使用CTRL-D作为文件结束符，但你可能喜欢使用CTRL-C。因此可以使用stty命令改变之：
$ stty eof c
其中c可以是你喜欢的其它特殊控制字符。
可以直接输入控制字符，在其前面冠以反斜线和脱字符（ ^）。命令
$ stty eof ^c
将CTRL-C设置为文件结束符。这种语法形式还可以用于修改删除符（通常为退格键BackSpace）和中断符（通常为DEL键）。若希望将删除符改为BACKSPACE，可以使用下列命令：
$ stty erase ^h
可以设置一个会话期，使得当自己键入一个退格键时，系统用退格、删除和退格序列响应。此时可以看到用退格键覆盖的字符从显示中消失了，这样更符合计算机的惯例。使用命令
$ stty echoe
可使这一特性设置为ON。
终端方式及其管理是UNIX系统中比较困难的内容之一，系统的用户手册中有stty选项的全部清单。在进行尝试之前，应当查阅手册，仔细分析，以免给你的工作带来麻烦。

Getting in

start a new screen session: screen
.. with session name: screen -S
attach to a running session: screen -r
.. to session with name: screen -r
the “ultimate attach”: screen -dRR (Attaches to a screen session. If the session is attached elsewhere, detaches that other display. If no session exists, creates one. If multiple sessions exist, uses the first one.)

Escape key

All screen commands are prefixed by an escape key, by default C-a (that's Control-a, sometimes written ^A). To send a literal C-a to the programs in screen, use C-a a.

Getting out

detach: C-a d
detach and logout (quick exit): C-a D D
exit screen: exit all of the programs in screen.
force-exit screen: C-a C-\ (not recommended)

Help

See help: C-a ? (lists keybindings)

Window Management

create new window: C-a c
change to last-visited active window: C-a C-a (commonly used to flip-flop between two windows)
change to window by number: C-a (only for windows 0 to 9)
change to window by number or name: C-a '
change to next window in list: C-a n or C-a
change to previous window in list: C-a p
see window list: C-a ” (allows you to select a window to change to)
show window bar C-a w (if you don't have window bar)
close current window: Close all applications in the current window (including shell)
kill current window: C-a k (not recommended)
rename current window: C-a A

Split screen

split display: C-a S
jump to next display region: C-a tab
remove current region: C-a X
remove all regions but the current one: C-a Q

Misc

redraw window: C-a C-l
enter copy mode: C-a [ (also used for viewing scrollback buffer)
paste: C-a ]
monitor window for activity: C-a M
monitor window for silence: C-a _
enter digraph: C-a C-v
lock (password protect) display: C-a x
enter screen command: C-a :

最近看到 yungyuc 和 letoh 都貼出各自的 screenrc 。過去我看到 psilotum 的 screen 設定，深覺羨慕，卻抽不出空來修改。今天突然興起，做了一些設定。這個設定的特點是，讓 xterm 和 rxvt 的 title 能隨著 screen 的切換而改變。另外 screen 也能自動偵測 shell 所執行的程式，將 title 換成正在執行的程式。

#termcapinfo xterm 'hs:ts=\E]2;:fs=\007:ds=\E]2;screen\007'
termcapinfo xterm 'hs:ts=\E]0;:fs=\007:ds=\E]0;bash\007'
caption always "%{= bk} %{= wk} %-Lw%{by}%n+%f %t%{wk}%{wk}%+Lw %=%{kw}%{= R}%{-}"
shelltitle '$ |bash'
defhstatus "\005t"
hardstatus on

補充

另外需要設定 shell 的 prompt

PS1="\033k\033\\\\\\W\\$ "; export PS1

這是 screen 偵測執行中程式，所使用的提示字串。 screen 靠這個字串，判斷 shell 正在接受使用者的 command 。

Reference

http://www.faqs.org/docs/Linux-mini/Xterm-Title.html#ss3.1

快下班时，爱问问题的小朋友Nico又问了一个问题：
"sqlserver里面有char和nchar，那个n据说是指unicode的数据，这个是什么意思。"
并不是所有简单的问题都很容易回答，就像这个问题一样。于是我答应专门写一篇BLOG来从头讲讲编码的故事。那么就让我们找个草堆坐下，先抽口烟，看看夜晚天空上的银河，然后想一想要从哪里开始讲起。嗯，也许这样开始比较好……

很久很久以前，有一群人，他们决定用8个可以开合的晶体管来组合成不同的状态，以表示世界上的万物。他们看到8个开关状态是好的，于是他们把这称为"字节"。
再后来，他们又做了一些可以处理这些字节的机器，机器开动了，可以用字节来组合出很多状态，状态开始变来变去。他们看到这样是好的，于是它们就这机器称为"计算机"。

开始计算机只在美国用。八位的字节一共可以组合出256(2的8次方)种不同的状态。
他们把其中的编号从0开始的32种状态分别规定了特殊的用途，一但终端、打印机遇上约定好的这些字节被传过来时，就要做一些约定的动作。遇上00x10, 终端就换行，遇上0x07, 终端就向人们嘟嘟叫，例如遇上0x1b, 打印机就打印反白的字，或者终端就用彩色显示字母。他们看到这样很好，于是就把这些0x20以下的字节状态称为"控制码"。
他们又把所有的空格、标点符号、数字、大小写字母分别用连续的字节状态表示，一直编到了第127号，这样计算机就可以用不同字节来存储英语的文字了。大家看到这样，都感觉很好，于是大家都把这个方案叫做 ANSI 的"Ascii"编码（American Standard Code for Information Interchange，美国信息互换标准代码）。当时世界上所有的计算机都用同样的ASCII方案来保存英文文字。
后来，就像建造巴比伦塔一样，世界各地的都开始使用计算机，但是很多国家用的不是英文，他们的字母里有许多是ASCII里没有的，为了可以在计算机保存他们的文字，他们决定采用127号之后的空位来表示这些新的字母、符号，还加入了很多画表格时需要用下到的横线、竖线、交叉等形状，一直把序号编到了最后一个状态255。从128到255这一页的字符集被称"扩展字符集"。从此之后，贪婪的人类再没有新的状态可以用了，美帝国主义可能没有想到还有第三世界国家的人们也希望可以用到计算机吧！
等中国人们得到计算机时，已经没有可以利用的字节状态来表示汉字，况且有6000多个常用汉字需要保存呢。但是这难不倒智慧的中国人民，我们不客气地把那些127号之后的奇异符号们直接取消掉, 规定：一个小于127的字符的意义与原来相同，但两个大于127的字符连在一起时，就表示一个汉字，前面的一个字节（他称之为高字节）从0xA1用到 0xF7，后面一个字节（低字节）从0xA1到0xFE，这样我们就可以组合出大约7000多个简体汉字了。在这些编码里，我们还把数学符号、罗马希腊的字母、日文的假名们都编进去了，连在 ASCII 里本来就有的数字、标点、字母都统统重新编了两个字节长的编码，这就是常说的"全角"字符，而原来在127号以下的那些就叫"半角"字符了。
中国人民看到这样很不错，于是就把这种汉字方案叫做 "GB2312"。GB2312 是对 ASCII 的中文扩展。
但是中国的汉字太多了，我们很快就就发现有许多人的人名没有办法在这里打出来，特别是某些很会麻烦别人的国家领导人。于是我们不得不继续把 GB2312 没有用到的码位找出来老实不客气地用上。
后来还是不够用，于是干脆不再要求低字节一定是127号之后的内码，只要第一个字节是大于127就固定表示这是一个汉字的开始，不管后面跟的是不是扩展字符集里的内容。结果扩展之后的编码方案被称为 GBK 标准，GBK 包括了 GB2312 的所有内容，同时又增加了近20000个新的汉字（包括繁体字）和符号。
后来少数民族也要用电脑了，于是我们再扩展，又加了几千个新的少数民族的字，GBK 扩成了 GB18030。从此之后，中华民族的文化就可以在计算机时代中传承了。
中国的程序员们看到这一系列汉字编码的标准是好的，于是通称他们叫做 "DBCS"（Double Byte Charecter Set 双字节字符集）。在DBCS系列标准里，最大的特点是两字节长的汉字字符和一字节长的英文字符并存于同一套编码方案里，因此他们写的程序为了支持中文处理，必须要注意字串里的每一个字节的值，如果这个值是大于127的，那么就认为一个双字节字符集里的字符出现了。那时候凡是受过加持，会编程的计算机僧侣们都要每天念下面这个咒语数百遍：
"一个汉字算两个英文字符！一个汉字算两个英文字符……"

因为当时各个国家都像中国这样搞出一套自己的编码标准，结果互相之间谁也不懂谁的编码，谁也不支持别人的编码，连大陆和台湾这样只相隔了150海里，使用着同一种语言的兄弟地区，也分别采用了不同的 DBCS 编码方案——当时的中国人想让电脑显示汉字，就必须装上一个"汉字系统"，专门用来处理汉字的显示、输入的问题，但是那个台湾的愚昧封建人士写的算命程序就必须加装另一套支持 BIG5 编码的什么"倚天汉字系统"才可以用，装错了字符系统，显示就会乱了套！这怎么办？而且世界民族之林中还有那些一时用不上电脑的穷苦人民，他们的文字又怎么办？
真是计算机的巴比伦塔命题啊！
正在这时，大天使加百列及时出现了——一个叫 ISO （国际标谁化组织）的国际组织决定着手解决这个问题。他们采用的方法很简单：废了所有的地区性编码方案，重新搞一个包括了地球上所有文化、所有字母和符号的编码！他们打算叫它"Universal Multiple-Octet Coded Character Set"，简称 UCS, 俗称 "UNICODE"。
UNICODE 开始制订时，计算机的存储器容量极大地发展了，空间再也不成为问题了。于是 ISO 就直接规定必须用两个字节，也就是16位来统一表示所有的字符，对于ascii里的那些“半角”字符，UNICODE 包持其原编码不变，只是将其长度由原来的8位扩展为16位，而其他文化和语言的字符则全部重新统一编码。由于"半角"英文符号只需要用到低８位，所以其高 8位永远是０，因此这种大气的方案在保存英文文本时会多浪费一倍的空间。
这时候，从旧社会里走过来的程序员开始发现一个奇怪的现象：他们的strlen函数靠不住了，一个汉字不再是相当于两个字符了，而是一个！是的，从 UNICODE 开始，无论是半角的英文字母，还是全角的汉字，它们都是统一的"一个字符"！同时，也都是统一的"两个字节"，请注意"字符"和"字节"两个术语的不同，“字节”是一个8位的物理存贮单元，而“字符”则是一个文化相关的符号。在UNICODE 中，一个字符就是两个字节。一个汉字算两个英文字符的时代已经快过去了。
从前多种字符集存在时，那些做多语言软件的公司遇上过很大麻烦，他们为了在不同的国家销售同一套软件，就不得不在区域化软件时也加持那个双字节字符集咒语，不仅要处处小心不要搞错，还要把软件中的文字在不同的字符集中转来转去。UNICODE 对于他们来说是一个很好的一揽子解决方案，于是从 Windows NT 开始，MS 趁机把它们的操作系统改了一遍，把所有的核心代码都改成了用 UNICODE 方式工作的版本，从这时开始，WINDOWS 系统终于无需要加装各种本土语言系统，就可以显示全世界上所有文化的字符了。
但是，UNICODE 在制订时没有考虑与任何一种现有的编码方案保持兼容，这使得 GBK 与UNICODE 在汉字的内码编排上完全是不一样的，没有一种简单的算术方法可以把文本内容从UNICODE编码和另一种编码进行转换，这种转换必须通过查表来进行。
如前所述，UNICODE 是用两个字节来表示为一个字符，这就总共可以组合出65535不同的字符，这大概已经可以覆盖世界上所有文化的符号。如果还不够也没有关系，ISO已经准备了UCS-4方案，说简单了就是四个字节来表示一个字符，这样我们就可以组合出21亿个不同的字符出来（最高位有其他用途），这大概可以用到银河联邦成立那一天吧！

UNICODE 来到时，一起到来的还有计算机网络的兴起，UNICODE 如何在网络上传输也是一个必须考虑的问题，于是面向传输的众多 UTF（UCS Transfer Format）标准出现了，顾名思义，UTF8就是每次8个位传输数据，而UTF16就是每次16个位，只不过为了传输时的可靠性，从UNICODE到 UTF时并不是直接的对应，而是要过一些算法和规则来转换。

从网上引来一段从UNICODE到UTF8的转换规则：

Unicode
UTF-8

0000 - 007F
0xxxxxxx

0080 - 07FF
110xxxxx 10xxxxxx

0800 - FFFF
1110xxxx 10xxxxxx 10xxxxxx

例如"汉"字的Unicode编码是6C49。6C49在0800-FFFF之间，所以要用3字节模板：1110xxxx 10xxxxxx 10xxxxxx。将6C49写成二进制是：0110 1100 0100 1001，将这个比特流按三字节模板的分段方法分为0110 110001 001001，依次代替模板中的x，得到：1110-0110 10-110001 10-001001，即E6 B1 89，这就是其UTF8的编码。

讲到这里，我们再顺便说说一个很著名的奇怪现象：当你在 windows 的记事本里新建一个文件，输入"联通"两个字之后，保存，关闭，然后再次打开，你会发现这两个字已经消失了，代之的是几个乱码！呵呵，有人说这就是联通之所以拼不过移动的原因。
其实这是因为GB2312编码与UTF8编码产生了编码冲撞的原因。
而当你新建一个文本文件时，记事本的编码默认是ANSI, 如果你在ANSI的编码输入汉字，那么他实际就是GB系列的编码方式，在这种编码下，"联通"的内码是：
c1 1100 0001
aa 1010 1010
cd 1100 1101
a8 1010 1000
注意到了吗？第一二个字节、第三四个字节的起始部分的都是"110"和"10"，正好与UTF8规则里的两字节模板是一致的，于是再次打开记事本时，记事本就误认为这是一个UTF8编码的文件，让我们把第一个字节的110和第二个字节的10去掉，我们就得到了"00001 101010"，再把各位对齐，补上前导的0，就得到了"0000 0000 0110 1010"，不好意思，这是UNICODE的006A，也就是小写的字母"j"，而之后的两字节用UTF8解码之后是0368，这个字符什么也不是。这就是只有"联通"两个字的文件没有办法在记事本里正常显示的原因。

而如果你在"联通"之后多输入几个字，其他的字的编码不见得又恰好是110和10开始的字节，这样再次打开时，记事本就不会坚持这是一个utf8编码的文件，而会用ANSI的方式解读之，这时乱码又不出现了。

受到过网络编程加持的计算机僧侣们都知道，在网络里传递信息时有一个很重要的问题，就是对于数据高低位的解读方式，一些计算机是采用低位先发送的方法，例如我们PC机采用的 INTEL 架构，这就叫little endian, 而另一些是采用高位先发送的方式, 这就叫big endian. 在网络中交换数据时，为了核对双方对于高低位的认识是否是一致的，采用了一种很简便的方法，就是在文本流的开始时向对方发送一个标志符——如果之后的文本是高位在位，那就发送"FEFF"，反之，则发送"FFFE"。不信你可以用二进制方式打开一个UTF-X格式的文件，看看开头两个字节是不是这两个字节？

顺便提一下little endian和big endian这两个网络术语的来历: 在<<格列佛游记>>中, 小人国中由于争论吃鸡蛋应该从大头敲还是从小头敲而分成了不同派系, 还发生了战争, 连皇帝都被干掉了. 在计算机技术发展中, 不同体系的硬件之间的通信也因为大头在前还是小头在前产生了同样严重的问题, 因此技术专家里比较幽默的那部分人----那一绝大部分人----就采用了"endian"这个有强烈政治隐喻的术语.

好了，终于可以回答NICO的问题了，在数据库里，有n前缀的字串类型就是UNICODE类型，这种类型中，固定用两个字节来表示一个字符，无论这个字符是汉字还是英文字母，或是别的什么。

下面的例子应该可以说明unicode型和ansi型的字段的区别:
我们在任意类型的数据库中建一个表, 含有如下的字段.
nc nchar(10)
c char(10)
然后, 我们再试着向其中加入下面的记录:
"1234567890", "1234567890"
"一二三四五六七八九十","一二三四五六七八九十"
对于第一条记录, 两个字段都可以插入10个字符, 同时也都一个字符也多存不了.
但对于第二条记录, nc字段可以把从"一"到"十"的数据都保存进去, 而c字段只能保存到"五", 再多就会出错.
为什么? 因为在nchar字段里, 一个汉字一个字符, 10字符宽的字段就可以保存10个汉字. 而char字段里, 一个汉字算两个字符, 10字符宽的字段就只能保存5个汉字了.

The format tags follow this prototype:

%[flags][width][.precision][length]specifier

Where specifier is the most significant one and defines the type and the interpretation of the value of the coresponding argument:

specifier	Output	Example
c	Character	a
d or i	Signed decimal integer	392
e	Scientific notation (mantise/exponent) using e character	3.9265e+2
E	Scientific notation (mantise/exponent) using E character	3.9265E+2
f	Decimal floating point	392.65
g	Use the shorter of %e or %f	392.65
G	Use the shorter of %E or %f	392.65
o	Signed octal	610
s	String of characters	sample
u	Unsigned decimal integer	7235
x	Unsigned hexadecimal integer	7fa
X	Unsigned hexadecimal integer (capital letters)	7FA
p	Pointer address	B800:0000
n	Nothing printed. The argument must be a pointer to a signed int, where the number of characters written so far is stored.
%	A % followed by another % character will write % to the string.

The tag can also contain flags, width, .precision and modifiers sub-specifiers, which are optional and follow these specifications:

flags	description
-	Left-justify within the given field width; Right justification is the default (see width sub-specifier).
+	Forces to preceed the result with a plus or minus sign (+ or -) even for positive numbers. By default, only negative numbers are preceded with a - sign.
(space)	If no sign is going to be written, a blank space is inserted before the value.
#	Used with o, x or X specifiers the value is preceeded with 0, 0x or 0X respectively for values different than zero. Used with e, E and f, it forces the written output to contain a decimal point even if no digits would follow. By default, if no digits follow, no decimal point is written. Used with g or G the result is the same as with e or E but trailing zeros are not removed.
0	Left-pads the number with zeroes (0) instead of spaces, where padding is specified (see width sub-specifier).

width	description
(number)	Minimum number of characters to be printed. If the value to be printed is shorter than this number, the result is padded with blank spaces. The value is not truncated even if the result is larger.
*	The width is not specified in the format string, but as an additional integer value argument preceding the argument that has to be formatted.

.precision	description
.number	For integer specifiers (d, i, o, u, x, X): precision specifies the minimum number of digits to be written. If the value to be written is shorter than this number, the result is padded with leading zeros. The value is not truncated even if the result is longer. A precision of 0 means that no character is written for the value 0. For e, E and f specifiers: this is the number of digits to be printed after the decimal point. For g and G specifiers: This is the maximum number of significant digits to be printed. For s: this is the maximum number of characters to be printed. By default all characters are printed until the ending null character is encountered. For c type: it has no effect. When no precision is specified, the default is 1. If the period is specified without an explicit value for precision, 0 is assumed.
.*	The precision is not specified in the format string, but as an additional integer value argument preceding the argument that has to be formatted.

.precision

description

.number

For integer specifiers (d, i, o, u, x, X): precision
specifies the minimum number of digits to be written. If the value to
be written is shorter than this number, the result is padded with
leading zeros. The value is not truncated even if the result is longer.
A precision of 0 means that no character is written for the value 0.
For e, E and f specifiers: this is the number of digits to be printed after the decimal point.
For g and G specifiers: This is the maximum number of significant digits to be printed.
For s:
this is the maximum number of characters to be printed. By default all
characters are printed until the ending null character is encountered.
For c type: it has no effect.
When no precision is specified, the default is 1. If the period is specified without an explicit value for precision, 0 is assumed.

The precision is not specified in the format string, but as an additional integer value argument preceding the argument that has to be formatted.

length	description
h	The argument is interpreted as a short int or unsigned short int (only applies to integer specifiers: i, d, o, u, x and X).
l	The argument is interpreted as a long int or unsigned long int for integer specifiers (i, d, o, u, x and X), and as a wide character or wide character string for specifiers c and s.
L	The argument is interpreted as a long double (only applies to floating point specifiers: e, E, f, g and G).

直接阅读源代码特别是比较大的程序应该遵循一定的步骤进行
第一了解程序的功能框架
第二使用源代码阅读器source insight 按照程序执行流程，入口点，实参，形参逐次阅读、
linux内核的源码结构：
arch ---
不同的处理器类型
arm
boot
linux/arch/arm/boot/compressed/head.S
head.s 自引导的代码解压内核
kernel head.s Kernel startup code
lib
match-不同的板子针对不同类型的板子进行的初始化代码
match-3sc2410
gpio.c
irq.c clock.c cpu.c devs.c
block
crypto
documents 文档
drivers 驱动代码
fs 文件系统
include 内核头文件
init main.c 内核初始化包含start-kernel(),restinit(),init()等初始化函数

ipc 进程通信的程序
kernle 内核
lib 库函数
mm 关于内存处理
net 关于网络
scripts 脚本用来编译内核的
security 安全
sound 声音
usr 用户

这样可以按照从arch/arm/boot head.s -> arch/arm/kernle/head.s -> init/main.c startkernel() 这样的顺寻读
第三可以从功能模块读起，单独的模块很多驱动模块，文件模块，网络模块。
最好先阅读一些中文的资料对内核的工作有所了解以后再读内核，比如要阅读驱动模块，最好是先把驱动的有关知识学一下，linux内核是怎么管理设备的，怎么写驱动，怎么注册设备，有了大概的了解以后，找一个简单驱动程序入手。

一，相关变量介绍

我们知道大部分Linux系统是无所谓中文版和英文版的，以FC4　Linux为例,系统发行的时候全世界都一样，系统是中文的还是英文的完全取决于你选择的语言包。不同国家的人在安装使用的时候选择属于自己国家的语言包，应用程序中的语言也不是写死的，它根据系统的设置来调用相关的语言，所以，一个应用程序写出来不经过修改，全世界不同国家的用户都可以以母语界面使用它，这就事所谓的internationalization（国际化），简称 i18n。这也是未来软件的发展趋势。

那么，如果我在系统中安装了不同的语言包和不同的字体，系统是如何判断我所要的语言界面并调用相关的字体的呢？系统中那些文件和变量在控制这些呢？

在redHat和FC系列Linux系统下，记录系统默认使用语言的文件是/etc/sysconfig/i18n,如果默认安装的是中文的系统，i18n的内容如下：
代码:

LANG="zh_CN.UTF-8" SYSFONT="latarcyrheb-sun16" SUPPORTED="zh_CN.UTF-8:zh_CN:zh"

其中LANG变量是language的简称，稍微有英语基础的用户一看就看出来这个变量是决定系统的默认语言的，即系统的菜单、程序的工具栏语言、输入法默认语言等。SYSFONT是system font的简称，决定系统默认用哪一种字体。SUPPORTED变量决定系统支持的语言，即系统能够显示的语言。需要说明的是，由于计算机起源于英语国家，因此，不管你把这些变量设置成什么，英语总是默认支持的，而且不管用什么字体，英文字体总包含在其中。

这些变量中LANG变量是在字符模式和图形界面下都用到的，在你登录系统后就被读取并生效，相信很多人在字符界面下输入Linux命令的时候经常会遇到显示出来的出错信息是乱码的情况，必需安装zhcon或者cce等字符模式下的中文软件才能正常显示中文的出错信息。如果我不要他显示中文乱码，我也不要为了看个很简单的出错信息而特意起用zhcon那我该怎么办呢？一个简单的零时解决的办法就是设置一下LANG变量：
代码:

[root@gucuiwen ~]# LANG="en_US.UTF-8"

即把系统的语言临时设置成英文，或者更简单一点，可以直接这样：
代码:

[root@gucuiwen ~]# LANG=""

即把LANG变量清空，由于英语是无论什么情况都支持的，LANG变量被清空后，系统就默认用英语。这样设置后，在字符模式下输出的出错信息等就是全英文的了。但这种设置是临时的，只是临时改变了LANG这个bash变量而已。当退出重新登录或者切换到其他字符终端后就无效了。到现在，读者应该想到了，只要把i18n文件中的LANG变量设置成英文的”en_US.UTF-8”，就可以永久解决这个问题了。修改后的文件如下：
代码:

#LANG="zh_CN.UTF-8" LANG="en_US.UTF-8" SYSFONT="latarcyrheb-sun16" SUPPORTED="zh_CN.UTF-8:zh_CN:zh"

请不要把LANG变量简单的清空，因为这个变量不仅在字符模式下用到，在图形界面下也用到，简单清空在字符模式下确实不会有问题，但在图形界面下，却会造成中文无法正常显示的情况，在过去Re d ha t 系列的版本中i18n文件中还有一个叫LANGUAGE的变量，专门控制图形界面下的语言设置，现在的FC系列中已经把这两个变量整合成一个变量了。

经过修改这个变量，重新起动图形界面后，就可以看到界面一经完全是英文的了。但是按ctrl+空格却不能调出中文输入法，输入法菜单中也不能添加中文输入法。我们只简单的修改了LANG变量改变了系统语言设置，当然这一步也可以用图形界面下的工具修改，而不用亲自修改配置文件。

二，关于运行等级

这个问题似乎和这篇文章的的主题无关，但是介于现在越来越多的linux新手遇到linux图形界面的问题，而且在中文输入法设置过程中也牵涉到这些问题，因此想顺便提一下。

现在的linux安装完成后，默认就运行在第5个系统运行级别。在SYSTEM V 风格的UNIX系统中，系统被分为不同的运行级别，这和BSD分支的UNIX有所不同，常用的为0~6七个级别:

0　关机
1　单用户
2　不带网络的多用户
3　带网络的多用户
4　保留，用户可以自给定义
5　图形界面的多用户
6　重起系统

由于现在的Linux系统安装完后就运行在第5个级别，即系统启动后直接进入图形界面，而不用在字符模式下登录后用startx或者xinit 来起动图形界面。这样看起来很方便。但是有什么坏处呢？　一旦你改变了某些设置，显示出问题的时候，系统不断在图形和字符间派徊，新手又不知道如何应对，十分麻烦，而且对于学习研究Linux的人来说，这样不利于了解和学习Linux底层的一些东西。很早就用Linux的老用户都知道，过去的Linux如 redhat6.0，都是默认运行接别为3，即使后来的RedHat9.0也可以在安装时候选默认字符登录还是图形登录。但现在的FC系列和其他大多数版本都不管三七二十一直接帮用户选择了直接图形界面登录。虽然对于大多数菜鸟来说，Linux确实越来越简单了，但是很多乐趣，那些新手也体验不到了。

也许你不相信，直接图形登录到系统确实会有很多问题，因此，作为一个有6年Linux使用经验的Linux和Solaris 系统管理员，我强烈建议在系统安装完成后把系统的默认运行等级设置在第3级，在字符终端登录后，再手工输入startx 命令起动图形界面。可以用如下的方法修改：
用文本编辑器修改　/etc/inittab文件，把
代码:

id:5:initdefault:

这一行，修改成
代码:

id:3:initdefault:

保存后就重起，系统就默认起动到字符界面。不同运行级别之间的差别的在于系统默认起动的服务的不同，如运行级别3默认不启动X图形界面服务，而运行级别5 却默认起动。本质上是没有区别的，更无所谓不同级别间功能强弱的问题。用户完全可自给定义不同级别的默认服务。在任何运行级别，用户都可用init 命令来切换到其他运行级别。

三，调出中文输入法：

我之所以要在上面费那么多笔墨来讲系统运行级别，是因为对系统的认识是从底部向上开始的。
先把默认运行级别修改成3级别，当然，如果你实在不想修改，就临时用init 3命令切换到第3级。

这样你就可以用startx起动图形界面，然后用ctrl+alt+backspace退出图形界面。请注意我说的是“退出”图形界面，而不是按ctrl+alt＋F2切到一个字符终端。

好了，一切由startx开始。当你需要在Linux系统中设置某个东西，或者配置某个服务的时候，最关键的是要知道，这一切是怎么开始的。知其然必需知其所以然。如果你有空把/etc/rc.d目录下的系统起动时运行的脚本通读一遍，就完全知道了/etc下的各种配置文件是用来干什么的、如何修改、修改后有什么效果等等。玩起系统来也能随心所欲想怎么改就怎么改。这就是我一直强调的,知其然一定要知其所以然。一定要深入系统，读脚本，学会用命令和手工修改系统配置文件。这样对系统才会有透彻的了解，整天用图形界面的工具是不能帮助你对系统有教为透彻深入的了解的，不同的linux系统提供的图形界面配置程序会不同，但命令和配置文件都是相同的，越是底层的东西越具有通用性。所以，应当先学会手动配置和修改系统配置文件，等熟悉了以后，再用图形界面的工具修改，以便减少工作量。

上面提了一下我解决问题的思路。我是顺着这个思路开始的：

中文输入法是在图形界面下使用的，是图形界面下运行的一个程序。而图形界面中的一切，都是由startx程序开启运行的。这就是问题的根源。

找出startx的位置：
代码:

[root@gucuiwen ~]# which startx /usr/X11R6/bin/startx

看startx是一个脚本还是二进制文件：
代码:

[root@gucuiwen ~]# file /usr/X11R6/bin/startx /usr/X11R6/bin/startx: Bourne shell script text executable

发现startx是一个shell 脚本，于是我打开它分析并阅读，看看能不能找到一些关于输入法起动过程和相关变量的线索：
代码:

[root@gucuiwen ~]# vi /usr/X11R6/bin/startx

我找到了该脚本在运行过程中调用的其他脚本和配置文件的信息：
代码:

userclientrc=$HOME/.xinitrc userserverrc=$HOME/.xserverrc sysclientrc=/etc/X11/xinit/xinitrc sysserverrc=/etc/X11/xinit/xserverrc

并且知道，startx的目的是寻找系统中可用的桌面系统X服务器系统、以及用户自定义的参数，最终调用xinit来初始化X图形界面。我没有在 startx脚本中找到直接和起动输入法相关的代码，于是就可以肯定，输入法相关的代码在startx调用的脚本中。于是我来到
/etc/X11/xinit/ 目录下，阅读并分析该目录下的脚本，这些脚本有些是startx直接调用的，有些是被startx调用的脚本再调用的，存在着多级嵌套的关系，没有一点耐心还真是搞不清楚。最终我在/etc/X11/xinit/xinitrc.d目录中的xinput.sh脚本中找到了和输入法相关的代码：
代码:

lang_region=$(echo $tmplang | sed -e 's/"..*//') lang_region="zh_CN"　 #这一行是修改后加上去的 for f in $HOME/.xinput.d/${lang_region} " $HOME/.xinput.d/default " /etc/X11/xinit/xinput.d/${lang_region} " /etc/X11/xinit/xinput.d/default ; do [ -r $f ] && source $f && break done

通过分析脚本，我知道，图形界面启动的时候脚本是根据LANG变量来决定是否启用输入法，以及启用哪种语言的输入法等。问题在于：我们还没有把LANG变量改成英语之前，系统得到的LANG变量是中文的，因此，它知道需要在图形界面启动过程中启用中文输入法，但把LANG变量改成英文后，系统根据LANG 变量知道系统是英文的，它便不再启动中文输入法，也不再设置和导出相关的变量，导致中文输入法不可用。因此，只要在这个脚本中，“骗”过系统，让输入法脚本“以为”系统是中文的，它不就运行中文输入法，并导出相关变量了吗？　于是，通过分析脚本，我在xinput.sh中的：
代码:

lang_region=$(echo $tmplang | sed -e 's/"..*//') 后面又添加了 lang_region="zh_CN"

直接把lang_region=$(echo $tmplang | sed -e 's/"..*//')　修改成　lang_region="zh_CN"　也可以
多添加一行是为了以后改过来方便，直接删除添加的一行就可以了。

当然，把for循环中的/etc/X11/xinit/xinput.d/${lang_region}该成
/etc/X11/xinit/xinput.d/zh _CN也可以。

当然还有其他的改法，前提是你要懂得shell 脚本的语法，看得懂脚本的意思。这样修改后，即便系统是英文的，xinput.sh脚本也会去读取/etc/X11/xinit/xinput.d/zh _CN　文件并导出其中的内容、设置好XMODIFERS等输入法变量，并运行iiimx输入法程序。

那么为什么不在图形界面启动后直接运行iiimx输入法程序呢？实验一下就知道，这根本不行。因为输入法程序是须要和被输入的应用程序配合运行的软件，在运行过程中需要导出很多变量。直接运行iiimx只运行了主程序，而没相关变量，没办法和应用程序配合完成输入工作。

完成修改工作后，保存脚本文件。输入startx命令启动图形界面，就可以用全英文的系统界面和中文输入法了。但需要注意的是：由于系统是全英文的，默认输入法也是英文，通过GNOME或者KDE菜单起动的应用程序第一次输入中文的时候不能按ctrl+空格来切换到中文，需要用鼠标在任务栏上点击输入法图标切换，第一次切换后以后就可以用ctrl+空格快捷键来切换中英文输入法了。

四，一些后续问题

某些软件，比如Open Office，通过GNOME或者KDE菜单启动的话，即使切换到中文输入法也输不进中文，这是因为整个桌面系统的环境是英文的，软件“继承”了英文环境的相关变量，这些软件就“认死理”，就是不让输入中文，这时候可以打开一个gnome终端，把LANG变量临时设置成zh_CN.UTF-8　：

[root@gucuiwen ~]# LANG="zh_CN.UTF-8"

然后在这个gnome终端中，用命令打开open office:

[root@gucuiwen ~]# oowriter &

这样Open Office就“继承”了gnome终端的LANG变量，起动后，工具栏和菜单等都是中文的，而且能输入中文。推而广之，任何软件都可以用这种方法，根据需要，打开中文界面的软件和英文界面的软件。要以英文界面运行软件时，只要从GNOME或者KDE菜单打开，要用中文界面运行软件时，在终端中修该 LANG变量，从修改过LANG变量的终端中通过命令运行即可。当然，如果你还安装了其他语言的字体，你还可以以其他语言的界面来运行程序。如日语：

[root@gucuiwen ~]# LANG="ja_JP.UTF-8"
[root@gucuiwen ~]# gedit &

我用上面的两条命令打开的gedit 编辑器就是全日语界面的，但是能输入中文和英文，并显示日文。从而达到，一个系统，多种语言和文字共存的目的。

当然，前提是要安装了日语字体和日语locale，否则所有有文字的地方会全部显示成一连串问号。总之，要先懂得原理，之后想怎么玩就怎么玩，随心所欲，完全不受限制，充分享受用Linux的乐趣。

五,　快速设置步骤：

1.修改/etc/sysconf/i18n文件，把
LANG="zh_CN.UTF-8"
修改成：
LANG="en_US.UTF-8"

2.修改/etc/X11/xinit/xinitrc.d/xinput.sh文件，把其中一行：

lang_region=$(echo $tmplang | sed -e 's/"..*//')

修改成：

lang_region=”zh_CN”

3,重新启动图形界面，就可以用英文的界面并且正确显示中文和输入中文。

VMware Workstation VMware Server 功能对比

很多人都弄不清楚VMware Workstation和VMware Server之间到底有什么功能差别。从名字上看，Server似乎应该比Workstation功能更强，可是Server居然是免费的，Workstation反倒要花钱。两者之间到底有什么区别呢？

其实，首先从用途上分，正如VMware网站上所说的，Workstation是用来搭建测试、临时环境的，也就是说Workstation上面的 Guest OS通常是为了测试、评估某个软件，或者是为了临时运行某个与当前系统不兼容的应用程序，通常不作为正式的系统、特别是服务器系统使用。而VMware Server则可以看成是VMware公司的旗舰产品——GSX的一个免费入门版，其上面通常会同时运行多个Guest OS，并且是作为稳定的服务器系统运行的，换句话说，一台服务器上安装了VMware Server之后，就可以作为几台虚拟服务器使用。从某种角度讲，如果在VMware Server上只运行一台VM，也就没有什么意义了。

那么，从技术角度上看两者有什么不同呢？VIRTUALIZATION.INFO在5月10日的一篇文章中，比较了两者的最新版本：VMware Workstation 6.0.0 (5月9日发布)和 VMware Server 1.0.3 (4月26日发布)。由于两者面向的市场不同，这个比较可能没有什么实际意义，但是由于在新版本的Workstation中包含了很多server- like的特性，在一些模棱两可的环境中还是值得参考的。

此外，VMware Server还不支持WinXP Home/Pro、Win2000 Pro等不是服务器版本的OS作为Host OS。

The Photos application is one of Facebook’s most popular features. Up to date, users have uploaded over 15 billion photos which makes Facebook the biggest photo sharing website. For each uploaded photo, Facebook generates and stores four images of different sizes, which translates to a total of 60 billion images and 1.5PB of storage. The current growth rate is 220 million new photos per week, which translates to 25TB of additional storage consumed weekly. At the peak there are 550,000 images served per second. These numbers pose a significant challenge for the Facebook photo storage infrastructure.

NFS photo infrastructure

The old photo infrastructure consisted of several tiers:

* Upload tier receives users’ photo uploads, scales the original images and saves them on the NFS storage tier.
* Photo serving tier receives HTTP requests for photo images and serves them from the NFS storage tier.
* NFS storage tier built on top of commercial storage appliances.

Since each image is stored in its own file, there is an enormous amount of metadata generated on the storage tier due to the namespace directories and file inodes. The amount of metadata far exceeds the caching abilities of the NFS storage tier, resulting in multiple I/O operations per photo upload or read request. The whole photo serving infrastructure is bottlenecked on the high metadata overhead of the NFS storage tier, which is one of the reasons why Facebook relies heavily on CDNs to serve photos. Two additional optimizations were deployed in order to mitigate this problem to some degree:

* Cachr: a caching server tier caching smaller Facebook "profile" images.
* NFS file handle cache - deployed on the photo serving tier eliminates some of the NFS storage tier metadata overhead

Haystack Photo Infrastructure

The new photo infrastructure merges the photo serving tier and storage tier into one physical tier. It implements a HTTP based photo server which stores photos in a generic object store called Haystack. The main requirement for the new tier was to eliminate any unnecessary metadata overhead for photo read operations, so that each read I/O operation was only reading actual photo data (instead of filesystem metadata). Haystack can be broken down into these functional layers -

* HTTP server
* Photo Store
* Haystack Object Store
* Filesystem
* Storage

In the following sections we look closely at each of the functional layers from the bottom up.

Storage

Haystack is deployed on top of commodity storage blades. The typical hardware configuration of a 2U storage blade is –

* 2 x quad-core CPUs
* 16GB – 32GB memory
* hardware raid controller with 256MB – 512MB of NVRAM cache
* 12+ 1TB SATA drives

Each storage blade provides around 10TB of usable space, configured as a RAID-6 partition managed by the hardware RAID controller. RAID-6 provides adequate redundancy and excellent read performance while keeping the storage cost down. The poor write performance is partially mitigated by the RAID controller NVRAM write-back cache. Since the reads are mostly random, the NVRAM cache is fully reserved for writes. The disk caches are disabled in order to guarantee data consistency in the event of a crash or a power loss.

Filesystem

Haystack object stores are implemented on top of files stored in a single filesystem created on top of the 10TB volume.

Photo read requests result in read() system calls at known offsets in these files, but in order to execute the reads, the filesystem must first locate the data on the actual physical volume. Each file in the filesystem is represented by a structure called an inode which contains a block map that maps the logical file offset to the physical block offset on the physical volume. For large files, the block map can be quite large depending on the type of the filesystem in use.

Block based filesystems maintain mappings for each logical block, and for large files, this information will not typically fit into the cached inode and is stored in indirect address blocks instead, which must be traversed in order to read the data for a file. There can be several layers of indirection, so a single read could result in several I/Os depending on whether or not the indirect address blocks are cached.

Extent based filesystems maintain mappings only for contiguous ranges of blocks (extents). A block map for a contiguous large file could consist of only one extent which would fit in the inode itself. However, if the file is severely fragmented and its blocks are not contiguous on the underlying volume, its block map can grow large as well. With extent based filesystems, fragmentation can be mitigated by aggressively allocating a large chunk of space whenever growing the physical file.

Currently, the filesystem of choice is XFS, an extent based filesystem providing efficient file preallocation.

Haystack Object Store

Haystack is a simple log structured (append-only) object store containing needles representing the stored objects. A Haystack consists of two files – the actual haystack store file containing the needles, plus an index file. The following figure shows the layout of the haystack store file:

The first 8KB of the haystack store is occupied by the superblock. Immediately following the superblock are needles, with each needle consisting of a header, the data, and a footer:

A needle is uniquely identified by its tuple, where the offset is the needle offset in the haystack store. Haystack doesn’t put any restriction on the values of the keys, and there can be needles with duplicate keys. Following figure shows the layout of the index file -

There is a corresponding index record for each needle in the haystack store file, and the order of the needle index records must match the order of the associated needles in the haystack store file. The index file provides the minimal metadata required to locate a particular needle in the haystack store file. Loading and organizing index records into a data structure for efficient lookup is the responsibility of the Haystack application (Photo Store in our case). The index file is not critical, as it can be rebuilt from the haystack store file if required. The main purpose of the index is to allow quick loading of the needle metadata into memory without traversing the larger Haystack store file, since the index is usually less than 1% the size of the store file.

Haystack Write Operation

A Haystack write operation synchronously appends new needles to the haystack store file. After the needles are committed to the larger Haystack store file, the corresponding index records are then written to the index file. Since the index file is not critical, the index records are written asynchronously for faster performance.

The index file is also periodically flushed to the underlying storage to limit the extent of the recovery operations caused by hardware failures. In the case of a crash or a sudden power loss, the haystack recovery process discards any partial needles in the store and truncates the haystack store file to the last valid needle. Next, it writes missing index records for any trailing orphan needles at the end of the haystack store file.

Haystack doesn’t allow overwrite of an existing needle offset, so if a needle’s data needs to be modified, a new version of it must be written using the same tuple. Applications can then assume that among the needles with duplicate keys, the one with the largest offset is the most recent one.

Haystack Read Operation

The parameters passed to the haystack read operation include the needle offset, key, alternate key, cookie and the data size. Haystack then adds the header and footer lengths to the data size and reads the whole needle from the file. The read operation succeeds only if the key, alternate key and cookie match the ones passed as arguments, if the data passes checksum validation, and if the needle has not been previously deleted (see below).

Haystack Delete Operation

The delete operation is simple – it marks the needle in the haystack store as deleted by setting a “deleted” bit in the flags field of the needle. However, the associated index record is not modified in any way so an application could end up referencing a deleted needle. A read operation for such a needle will see the “deleted” flag and fail the operation with an appropriate error. The space of a deleted needle is not reclaimed in any way. The only way to reclaim space from deleted needles is to compact the haystack (see below).

Photo Store Server.

Photo Store Server is responsible for accepting HTTP requests and translating them to the corresponding Haystack store operations. In order to minimize the number of I/Os required to retrieve photos, the server keeps an in-memory index of all photo offsets in the haystack store file. At startup, the server reads the haystack index file and populates the in-memory index. With hundreds of millions of photos per node (and the number will only grow with larger capacity drives), we need to make sure that the index will fit into the available memory. This is achieved by keeping a minimal amount of metadata in memory, just the information required to locate the images.

When a user uploads a photo, it is assigned a unique 64-bit id. The photo is then scaled down to 4 different sizes. Each scaled image has the same random cookie and 64-bit key, and the logical image size (large, medium, small, thumbnail) is stored in the alternate key. The upload server then calls the photo store server to store all four images in the Haystack.

The in-memory index keeps the following information for each photo:

Haystack uses the open source Google sparse hash data structure to keep the in-memory index small, since it only has 2 bits of overhead per entry.

Photo Store Write/Modify Operation

A write operation writes photos to the haystack and updates the in-memory index with the new entries. If the index already contains records with the same keys then this is a modification of existing photos and only the index records offsets are modified to reflect the location of the new images in the haystack store file. Photo store always assumes that if there are duplicate images (images with the same key) it is the one stored at a larger offset which is valid.

Photo Store Read Operation

The parameters passed to a read operation include haystack id and a photo key, size and cookie. The server performs a lookup in the in-memory index based on the photo key and retrieves the offset of the needle containing the requested image. If found it calls the haystack read operation to get the image. As noted above haystack delete operation doesn’t update the haystack index file record. Therefore a freshly populated in-memory index can contain stale entries for the previously deleted photos. Read of a previously deleted photo will fail and the in-memory index is updated to reflect that by setting the offset of the particular image to zero.

Photo Store Delete Operation

After calling the haystack delete operation the in-memory index is updated by setting the image offset to zero signifying that the particular image has been deleted.

Compaction

Compaction is an online operation which reclaims the space used by the deleted and duplicate needles (needles with the same key). It creates a new haystack by copying needles while skipping any duplicate or deleted entries. Once done it swaps the files and in-memory structures.

HTTP Server

The HTTP framework we use is the simple evhttp server provided with the open source libevent library. We use multiple threads, with each thread being able to serve a single HTTP request at a time. Because our workload is mostly I/O bound, the performance of the HTTP server is not critical.

Summary

Haystack presents a generic HTTP-based object store containing needles that map to stored opaque objects. Storing photos as needles in the haystack eliminates the metadata overhead by aggregating hundreds of thousands of images in a single haystack store file. This keeps the metadata overhead very small and allows us to store each needle’s location in the store file in an in-memory index. This allows retrieval of an image’s data in a minimal number of I/O operations, eliminating all unnecessary metadata overhead.

︶ㄣ無名氏

xauth

stty

screen Quick Reference

Getting in

Escape key

Getting out

Help

Window Management

Split screen

Misc

screenrc

補充

字符集和编码

printf sprintf fprintf format

linux内核源代码阅读的步骤

英文的界面显示中文和输入中文