易栈网-膘叔

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，基本上也只有这几种解决方案了。呵呵，全部列出来，希望有用

摘抄这一篇文章的内容，是因为这两天正好用到。
SSH连接上服务器后，人走开了，或者去忙其他事情了，结果回来一看，光标不动了。原来已经断却了连接。
看到这篇文章是24号，遇到问题是27号，因为对文章有印象，所以继续打开一看，原来我已经打上星标了。所以，摘抄下来。希望给其他使用UBUNTU的人也多一次GOOGLE搜索的命中率。

原文链接：SSH Client 会话空闲超时的解决办法

原文内容：

ClientAliveInterval 60
ClientAliveCountMax 1

这段时间最大的新闻莫过于SUN被收购了，收购人不是IBM而是oracle
新闻那是铺天盖地呀，去CNBETA看看就知道了，但对于我来说，关心的只有几点：

1、MYSQL会怎么个走法？
2、以后java会怎么继续
3、服务器价格会下降吗？

更多新闻请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 等更有用的技术吧!

来自dbanotes的文章，不多介绍了。我很多文章来自于dbanotes和sanotes网站

原文地址：http://www.dbanotes.net/arch/small_site_arch.html
原文如下：

到处都是什么大规模啊，高流量啊，高性能之类的网站架构设计，这类文章一是满足人们好奇心，但看过之后也就看过了，实际收益可能并不大；另外一个副作用是容易让人心潮澎湃，没学走先学跑，在很多条件仍不具备的情况下，过度设计、过度扩展(高德纳大爷也说过，"过早优化是万恶之源")，所以，这里反弹琵琶，讨论一下小规模、低性能、低流量的网站该如何搞法。

如果站点起步阶段可能就是一台机器(或是一台虚拟机，比如 JobsDigg.com )，这个时候，去关注什么数据拆分啊，负载均衡啊，都是没影子的事情。很多大站点的经验绝不能照搬，辩证的参考才是硬道理。

拥抱熟知的技术

动手构建站点的时候，不要到处去问别人该用什么，什么熟悉用什么，如果用自己不擅长的技术手段来写网站，等你写完，黄花菜可能都凉了。所以，有现成 的软件组件可用，就不要自己重新发明轮子。人家说 Python 牛，但自己只懂 PHP ，那就 PHP 好了，如果熟悉 .net ?，那也不错。用烂技术不是丢人的事情，把好技术用烂才丢人。

架构层次清晰化

起步的阶段应该清楚的确定下来架构的层次。如果都搅和在一起，业务一旦扩增开来，如果原有的一堆东西拆不开就是非常痛苦的事情。

Web Server <--> (AppServer)<-->Cache(eg. Memcached)<-->DB

层次清晰化的一个体现是(以 LAMP 架构为例)：即使只有一台机器，也应该起个 Memcached 的实例，效果的确非常好--一般人儿我不告诉他...不要把什么都压到 DB 上，DB 一旦 I/O 压力走到磁盘上，问题要暴露出来是很快的。没错，DB 本身也会利用自己的 Cache，但 DB 的Cache 和 Memcached 设计出发点毕竟不一样。

数据冗余? 有必要

很多人并不是数据库设计专家，如果应用要自己设计表结构什么的，基本都是临时抱佛脚，但三个范式很多人倒是记得牢，这是大多数小型 Web 站点遇到的一个头疼事儿，一个小小的应用搞了几十个表... 忘掉范式这个玩意儿! 记住，尽可能的冗余数据，你在数据层陷入的时间越多，你在产品上投入的就会越少。用户更关心的是产品的设计。

前端优化很重要

因为流量低，访客可能也不多，这时候值得注意的是页面不要太大，多数流量低的站点吃亏就在于一个页面动辄几兆(我前两天看到一个Startup的首页有4M之大,可谓惊人)，用户看个页面半分钟都打不开，你说咋发展? 先把基本的条件满足，再去研究前端优化。

功能增加要谨慎

不是有个 80/20 原则么? 把最重要的精力放在最能给你带来商业价值的地方。有些花里胡哨的功能带来很大的开销，反而收效甚微。记住，小站点，最有价值的是业务模式，而不是你的技术有多牛。技术是为业务服务的，不要炫技。

有些网站不停的添加功能，恰恰是把这些新功能变成了压死自己的稻草。

从开始考虑性能

这一点是可选的，但也重要。设计应用的时候在开始就应考虑 Profile 这件事情。一套应用能否在后期进行有效优化和扩展，很大的程度限制在是否有比较合适的 Profile 机制上。需要补充的是，对性能的考虑必然要把有关的历史数据考虑进来。另请参见网站运维之道的容量规划以及其它小帖子。

好架构不是设计出来的

这是最后要补充的一点。好的架构和最初的设计有关系，但最重要的是发展中的演化：

发展-->发现问题-->反馈-->解决问题(执行力)--> 改进->进化到下一阶段--新问题出现(循环)

有些站点到了某个阶段停足不前，可能卡在执行力这个地方，来自用户的反馈意见上来了之后，没有驱动力去做改进。最后也是死猪不怕开水烫了。

这篇文章有浓重的山寨风格，所以，你不要太认真。如果在用短平快的方式构建某些山寨网站的话，可参考其中对你有益的点，不赞同的地方可以直接忽视掉，就没必要费力留言进行争论了。

--EOF--