如果你也想把自己的网站变灰，那么可以参考以下的方法。
搜索结果 分类目录: 技术
2010年08月15日
2010年07月24日
各版本Linux下sshd服务启动方法（持续更新…）
slax-6.1.2:
# sh /etc/rc.d/rc.sshd start
ubuntu-10.04:
# sudo /etc/init.d/ssh start
2010年05月30日
[转]游戏UI解决方案汇总
1.CEGUI
CEGUI是老牌的开源界面库了，最新版本是0.7.1，完全免费，也是Ogre官方推荐使用的界面库，Ogre1.6及以前的版本，都是内置支持的。使用它的商业游戏也非常多，比如天龙八部，火炬之光，仙剑四等。这也就证明CEGUI确实强大，可以完全达到商业应用级别，而且相关资料非常丰富，至少不用担心某个功能无法实现，因为你能碰到的问题，网上基本都有解决方案，经过这些大作的证明，就不要怀疑了：）。
但是功能强大是有代价的，就是它太庞大、复杂了，上手很困难。这些大作没有一个不修改CEGUI的，也就是说要真正用起来，或者说要用的好，还是要做点事的。那需要做多少事呢？不清楚。
2. Ogre SDKTray
从Ogre1.7开始就不再内置支持CEGUI了，转而使用Ogre自己的SDKTray，“tray”是在ogre的overlay和material的基础上实现的，使用很容易理解和使用，但目前它还只是个半成品，无法应用到商业游戏中。
3.QuickGUI
最新版本10.1，专为Ogre写的UI库，支持Ogre1.7，比起CEGUI来说，小巧了很多。
但是很遗憾，至今还有没有编辑器（作者的Blog上说正在开发，但是还没有发布），要靠手动编写xml文件，囧啊～～Ogre社区里从来没有人推荐使用这个。我只是简单看了下，感觉像是作者练手的项目（个人观点）。
4.Hikari
Hikari可以让你使用Flash制作界面，最新版本0.3，完全免费，大家知道Flash动画是非常流行的，如果将Flash应用到游戏中，一定很拉风！Hikari就实现了这个功能，通过Flash.ocx将swf渲染成Ogre的Texture，然后你就可以任意操作这个Texture了，正是因为如此，Hikari支持Flash的所有版本，不存在兼容性问题。因为Flash本身就支持多国语言，所以中文显示也没有问题。可以把界面开发的大部分内容放到Flash那边，从而使客户端简洁很多（简单就是美啊）。
但是Hikari最致命的问题的效率太低，它使用的是Flash的ocx，先将动画内容渲染到DC上，然后拷到Texture中，所以很慢，而且慢的是第二步，使得Flash优秀的脏矩形优势无法发挥，根本无法应用到商业游戏中。我做了个动画，30张图片随机飘动，1023×768的窗口，使Flash占满，Release版只能跑到15帧（集成显卡），这还没有显示任何文字呢：（
5.Scaleform
Scaleform跟Hikari的作用是一样的，都是用Flash来做游戏界面，不同的是Scaleform非常牛X，它的效率很高，可以说是最强游戏界面解决方案了！而且对亚洲语言显示和输入都完美支持。目前最新版本是3.2，据说4.0将支持Actionscript 3.0, 并全方位支持3D UI。超过600款游戏使用Scaleform做界面，比如超大作StarCraft II，Crysis，Fable II，Civilization IV，Halo Wars，Princes of Persia，Mess Effect 2，Prototype，Resistance 2，Splinter Cell等。
心动了吧，可惜Scaleform是收费的，而且授权费相当的高，3.X版的目标售价是15万美金。如果你不在乎钱的话，这绝对是不二之选，在乎钱的话，这是二B之选。PS：有不少商业引擎已经将Scaleform集成进去了，比如Gamebryo，Unreal3等，如果你不用Ogre，买了商业引擎也爽了～～
6.ogreSwf/vektrix
Hikari效率太低，Scaleform太贵，ogreSwf/vektrix就是出来解决这个矛盾的。ogreSwf跟Scaleform一样都由开源的gameSwf发展起来，Scaleform开始商业化，ogreswf继续开源，后来ogreswf项目停掉了。2010年ogreSwf的作者重起了该项目，在原来的基础上改进并改名为vektrix，2010年4月发布了新的demo，可能是SourceForge的原因，我下的demo文件无法解压，又觉得vektrix目前还无法达到Scaleform的高度，所以后来就没有再试了。
7.Awesomium
Awesomium的功能有点类似Hikari，只不过它是将网页渲染成Texture，而且效率方面也做的比较好。Awesomium 采用了目前业界速度最快的浏览器内核webkit和v8，其实是把Chrome内核嵌入到了里面，同时还很好地支持flash，可以通过javascript使游戏和网页交互。该项目最初也是开源的，后来商业化了，但是不太贵，最便宜的版本只要400多美金。
Awesomium的效率之所以高，估计也是脏矩形方面做的好，我把上面那个动画嵌到网页中，用Awesomium打开，帧数马上就下来了，所以还是不能做UI，但是游戏中的帮助页面则可以考虑用这个。Awesomium也不方便根据网页内的内容做半透明效果，也就是网页中部分半透明很难实现，全透明，也就是镂空效果则可以通过模板实现。
8.MYGUI
MyGUI最新版本3.0.1，是俄罗斯人写的，要么没有注释，要么注释是俄文的，而且相关的资料实在是太缺乏了，虽然小修改一下可以支持中文显示，但是效果太差了，根本不能用，更别说多种文字，多种效果了，目前也没有什么商业游戏是用这个库做的。
但我最终选择了这个UI库。
就像MYGUI的介绍一样“MyGUI – fast, simple and flexible GUI.”这确实是一个，高效，轻便，灵活的库。首先它的设计很好，所以即使没有注释，也不难理解。换肤的设计避免了CEGUI里的很多中间层，使用要简单很多，资源文件的管理也要清爽（清楚+爽）一些。没有使用ogre的overlay，用底层直接画了，效率比CEGUI要高。LayoutEdit，ImageSetEdit等比CEGUI的要好用的多，CEGUI的工具经常当掉- -。中文显示可以模仿CEGUI去做，我已经完全实现，效率并不低，完全可以接受。
载入layout文件后返回一个窗口的vector，你可以自己写一个类似BaseLayout的类去管理，然后像MYGUI一样大量用C++委托做回调函数，就可以把各个Dialog分开去写，就像写MFC的Dialog一样，这一点做的实在太好了。如果再学一点CEGUI，把Lua脚本集成进去，载入layout文件时把窗口注册到lua中，这样就可以在脚本里写逻辑了，客户端-UI-脚本，很清晰。
为什么没有商业游戏使用MYGUI呢？MYGUI比较稳定的版本2.2.3是09年10月份发布的，是少要1年才能有游戏出来，火炬之光是09年11月上市的，在开发的时候MYGUI还很不完善，以后一定会有不少游戏使用MYGUI：）
2010年04月29日
链接静态MFC库时要注意
今天需要给公司同事做个办公用的小软件，由于项目简单，根据经验做就行，也就没做太多规划，窗口系统就用MFC来做了。不想在发行时附带VC内部的几个DLL，就把项目设置为use MFC in a static library，结果出现了一些错误，在网上搜索得到以下解决办法：
链接错误
nafxcw.lib(afxmem.obj) :error LNK2005: “void * __cdecl operator new(unsigned int)”(??2@YAPAXI@Z) already defined in LIBCMT.lib(new.obj)
这是因为VC的编译器在编译程序时有两个习惯：
a、在从头开始编译时，将源文件名按字母排序后，依次处理。
b、一边编译一边决定需要哪些缺省库。
C运行时库（CRT）和Microsoft基础类库（MFC）的链接顺序有误。CRT库对new、delete、DllMain函数使用弱外部链接，MFC库包含new、delete、DllMain函数，这些函数要求先链接MFC库，然后再链接CRT库。
强制链接器按照正确的顺序链接库。
Project ->setting ->Link : category ->Input
Ignore libraries： nafxcw.lib ; libcmt.lib
Object/library modules：nafxcw.lib ; libcmt.lib
注意顺序，前者为MFC静态链接库，后者为C运行时库。
使用MFC库时，务必先链接它们，然后再链接CRT库。这可以通过确保项目中的每个文件都首先包含 Msdev\Mfc\Include\Afx.h 来完成。直接包含（#include <Afx.h>）或间接包含（#include <Stdafx.h>）都可以。Afx.h包含文件会通过使用#pragma comment (lib,”<libname>”)指令来强制采用库的正确顺序。
连接时警告
warning LNK4089: all references to “SHELL32.dll” discarded by /OPT:REF
链接器工具警告 LNK4089/OPT:REF 已丢弃所有对“动态链接库”的引用，链接器放弃了引用 dynamic-link library 中的导出的所有封装函数。
如果代码中未使用的函数引用链接器已放弃的DLL导出，也会出现此警告。用#pragma comment(linker，”/ignore:4089)可以取消警告。
在project->settings->linking->projects options中加上/OPT:NOREF 也可以。
2009年11月24日
传说中的libmysqlclient.so诞生啦
在cygwin下成功编译mysql-5.1倒没有遇到太大问题，执行：
./configure --without-readline --without-libedit
make
时间较长，但没有出错，只是编译完成后我要的libmysqlclient.so(dll)没有生成。
下面提供解决办法：
定位到源码目录下的libmysql子目录，执行：
gcc -shared -o libmysqlclient.dll -Wl,--out-implib=libmysqlclient.dll.a -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--whole-archive .libs/libmysqlclient.a -Wl,--no-whole-archive -lcrypt -lz
即可:-)
2009年11月8日
修复SVN仓库
> I’m running SUSE 10.2 with svn from the SUSE Subversion repo.
>
> LC_ALL=C
> svn –version
> svn, version 1.5.0 (dev build)
> compiled Jun 5 2008, 16:16:44
>
Not even a Release Candidate, just head of the branch. :(
> After the last update on the 5th I get this error when committing:
> svn: Can’t open file ‘/srv/svn/repos/oneiros/db/txn-current’: No such
> file or directory
>
Hmm. ’svnadmin verify’ doesn’t complain if txn-current is missing, and
’svnadmin recover’ doesn’t recreate it either. However, ’svnadmin dump’
doesn’t complain either! So, a dump|load might work for you:
% svn –version -q
1.5.0-final
% svnlook youngest repos1
1
% rm -f repos1/db/txn-current
% svnadmin create repos2
% svnadmin -q dump repos1 | svnadmin -q load repos2
% svnlook youngest repos2
1
% cat repos2/db/txn-current
1
# swap the repositories, relocate the wc, and commit. Works.
Daniel
> And surely, /srv/svn/repos/oneiros/db/txn-current doesn’t exist.
>
> Here’s an ls of /srv/svn/repos/oneiros/db/:
> current format fs-type indexes.sqlite revprops revs transactions
> txn-current-lock uuid write-lock
> transactions is empty, txn-current’s size is 0.
> svnadmin lstxns /srv/svn/repos/oneiros/ shows no transactions.
>
> Creating an empty /srv/svn/repos/oneiros/db/txn-current only changes
2009年11月1日
在linux下产生并调试core文件
$ uname -a
$ vi foo.c
$ gcc -Wall -g foo.c
$ ./a.out
$ ls -l core.*
$ ulimit -c 1024
$ ulimit -a
$ ./a.out
$ ls -l core.*
$ gdb –core=core.9128
(gdb) file ./a.out
(gdb) l
先看看我用的是个什么机器：
$ uname -a
Linux dev 2.4.21-9.30AXsmp #1 SMP Wed May 26 23:37:09 EDT 2004 i686 i686 i386 GNU/Linux
再看看默认的一些参数，注意core file size是个0，程序出错时不会产生core文件了。
$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) 4
max memory size (kbytes, -m) unlimited
open files (-n) 2048
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 7168
virtual memory (kbytes, -v) unlimited
写个简单的程序，看看core文件是不是会被产生。
$ more foo.c
#include
static void sub(void);
int main(void)
{
sub();
return 0;
}
static void sub(void)
{
int *p = NULL;
/* derefernce a null pointer, expect core dump. */
printf(“%d”, *p);
}
$ gcc -Wall -g foo.c
$ ./a.out
Segmentation fault
$ ls -l core.*
ls: core.*: No such file or directory
没有找到core文件，我们改改ulimit的设置，让它产生。1024是随便取的，要是core文件大于1024个块，就产生不出来了。
$ ulimit -c 1024
$ ulimit -a
core file size (blocks, -c) 1024
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) 4
max memory size (kbytes, -m) unlimited
open files (-n) 2048
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 7168
virtual memory (kbytes, -v) unlimited
$ ./a.out
Segmentation fault (core dumped)
$ ls -l core.*
-rw——- 1 uniware uniware 53248 Jun 30 17:10 core.9128
注意看上述的输出信息，多了个(core dumped)。确实产生了一个core文件，9128是该进程的PID。我们用GDB来看看这个core。
$ gdb –core=core.9128
GNU gdb Asianux (6.0post-0.20040223.17.1AX)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type “show copying” to see the conditions.
There is absolutely no warranty for GDB. Type “show warranty” for details.
This GDB was configured as “i386-asianux-linux-gnu”.
Core was generated by `./a.out’.
Program terminated with signal 11, Segmentation fault.
#0 0×08048373 in ?? ()
(gdb) bt
#0 0×08048373 in ?? ()
#1 0xbfffd8f8 in ?? ()
#2 0×0804839e in ?? ()
#3 0xb74cc6b3 in ?? ()
#4 0×00000000 in ?? ()
此时用bt看不到backtrace，也就是调用堆栈，原来GDB还不知道符号信息在哪里。我们告诉它一下：
(gdb) file ./a.out
Reading symbols from ./a.out…done.
Using host libthread_db library “/lib/tls/libthread_db.so.1″.
(gdb) bt
#0 0×08048373 in sub () at foo.c:17
#1 0×08048359 in main () at foo.c:8
此时backtrace出来了。
(gdb) l
8 sub();
9 return 0;
10 }
11
12 static void sub(void)
13 {
14 int *p = NULL;
15
16 /* derefernce a null pointer, expect core dump. */
17 printf(“%d”, *p);
(gdb)
Ubuntu升级命令
如果针对版本升级命令：
sudo apt-get update
sudo update-manager -c -d然后选选择upgrade
如果是普通升级的命令：
sudo apt-get update
sudo apt-get upgrade
如果针对单一软件升级的命令：
sudo apt-get update
sudo apt-get upgrade package_name_your_want_to_upgrade
如果你要全部升级的话：
sudo apt-get dist-upgrade
2009年09月6日
关于CPU的省电模式
在G0工作状态下，ACPI定义系统处理器的电源状态，要么为活跃状态(正在执行)，要么为睡眠状态(未执行)。处理器电源状态被设计为C0,C1,C2,C3。。。Cn。C0电源状态是活跃状态，即CPU执行指令。C1到Cn都是处理器睡眠状态，即和C0状态相比，处理器处理器消耗更少的能源并且释放更少的热量。当进入睡眠状态，处理器不执行任何指令。每个睡眠状态都有一个和省电多少对应的延迟。一般来说，进入和退出的延迟越长，这个状态越省电。为了保持能量，OSPM在空闲时将处理器置于其中一个支持的睡眠状态中。在C0状态下，ACPI允许处理器的性能通过一个定义的节制过程发生改变，通过改变进入多种性能状态(P-states)。
ACPI定义这样的逻辑在每个CPU的偏置上，即OSPM通过转换来切换不同的处理器电源状态。这个逻辑是可选的，在FADT表和处理器对象中有描述。FADT表中的这些字段和标志描述了硬件的对称性，以及处理器对象对特别的CPU时钟逻辑包含的位置(在P_BLK寄存器块和_CST对象中有描述)。
P_LVL2和P_LVL3寄存器提供可选的支持，将系统处理器置于C2或者C3状态。P_LVL2寄存器将排好序的处理器置于C2状态，P_LVL3讲排好序的处理器置于C3状态。C3状态的额外支持通过总线主状态和仲裁禁止位被提供(PM!1_STS寄存器中的BM_STS位和PM2_CNT寄存器中的ARB_DIS位)。系统软件通过读取P_LVL2或者P_LVL3寄存器数据来进入C2或者C3状态。硬件必须精确的将处理器放在恰当的时钟状态，通过对相应的P_LVLx寄存器的读操作。平台必须定义可选的接口来允许OSPM使用_CST对象进入C-state。
处理器的电源状态支持是对称的，通过FADT表和P_BLK接口；OSPM假设同一系统里的所有的处理器都在相同的电源状态下。如果处理器有不对称的电源状态支持，BIOS将通过FADT表选择和使用所有处理器最低的相同的电源状态。例如，如果CPU0支持所有的电源状态乃至C3，但是CPU1仅支持C1，那么OSPM将仅将空闲的处理器置于C1(CPU0将不会被置于C2和C3状态)。注意C1必须被支持，C2和C3是可选的。
处理器电源状态C1
所有的处理器必须支持这种状态。这种状态的支持是通过一个本地的处理器指令(HLT或者mwait)，并且认为不需要芯片组的硬件支持。这种状态的硬件延迟必须足够的低，使得OSPM在决定是否使用该状态时不需要考虑延迟方面的问题。除了将处理器置于一种电源状态，这个状态没有其他的软件可见的效果。在C1状态下，处理器可以保持系统cache里面的内容。
硬件可以以任何理由退出该状态，但必须是在有中断到达处理器的情况下。
处理器电源状态C2
这种电源状态不是必需的。如果存在，该状态能够更好的省电，它通过使用P_LVL2命令寄存器或者由_CST提供的另一种机制来使处理器进入该状态。这个状态的最坏情况下的硬件延迟在FADT的表里面有声明，OSPM可以根据这个信息来决定什么时候C1状态应该被C2状态代替。除了将处理器置于一种电源状态，该状态没有其他的软件可见效果。OSPM假设C2比C1更省电，但是退出的延迟比C1要高。
C2电源状态是一种可选的ACPI时钟状态，需要芯片组的硬件支持。时钟逻辑由一个接口组成，可以用来被操纵使处理器精确的进入C2电源状态。在C2电源状态下，处理器被认为能够保持其cache的一致性；例如，总线控制器和多处理器的活动可以发生而不破坏cache里面的内容。
C2状态将处理器置于一种低功耗的状态，围绕多处理器和总线控制器系统做优化。当存在总线控制器或者多处理器活动时(这一条件将阻止处理器进入C3状态)，OSPM将使一个空闲状态下的处理器群体进入C2状态。处理器簇能够在C2状态下监视总线控制器或者多核CPU访问内存的行为。
硬件可以以任何理由退出该状态，但必须是在有中断到达处理器的情况下。
处理器电源状态C3
系统对C3处理器电源状态的支持也是可选的。 如果存在，这种状态比C1和C2状态更加节省功耗。 使用P_LVL3命令寄存器或者_CST机制可以进入C3状态。 这种状态的最坏的硬件延迟在FADT表中声明了，OSPM可以通过这一信息来决定什么时候需要进入C3状态而不是C1或者C2状态。 当在C3状态中，处理器的cache保持着状态但是处理器没有窥视总线控制器，或者多核CPU进行访存。
硬件可以以任何理由退出这种状态，但必须是因为一个中断投递到了该处理器，或者当BM_RLD被设置时，一个总线控制器企图访存。
OSPM负责保证cache的一致性。在单处理器环境下，这可以通过使用PM2_CNT。ARB_DIS总线控制器仲裁寄存器来保证总线控制器的活动不会发生在C3状态下。 在多处理器环境下，处理器的cache可以通过flush和invalidate来保持一致性。
有两种机制支持C3电源状态：
1.在进入C3状态之前，让OSPM flush和invalidate cache
2.提供一种硬件机制，阻止控制器写内存(只支持UP)
在第一种情况下，OSPM将在进入C3之前flush系统的cache。 由于flush系统的cache通常有很大的延迟，OSPM只对多核平台的空闲处理器支持这种情况。 flush cache通过ACPI定义的一种机制来完成。
单处理器平台提供一种硬件功能，OSPM将尝试将平台置于一种模式，当处理器处于C3模式，这种模式组织系统总线控制器来写内存。一旦总线控制器请求一个访问，CPU将从C3中被唤醒，并且重新使能总线控制器访问。
OSPM使用BM_STS位来决定要进入的电源状态是C2还是C3。BM_STS是一个可选的bit位，表示总线控制器是活跃的。 OSPM使用这一位来决定在C2和C3之间的策略。 频繁的总线控制器活动将CPU的电源状态降到C2，没有总线控制器活动将CPU的电源状态提升到C3。 OSPM保持BM_STS的一个变化历史来决定CPU电源状态的策略。
用在C3里的最后一个硬件特性是BM_RLD位。 这一位决定总线控制器的访问是否导致Cx电源状态的退出。 如果这一位被设置，一旦有总线控制器访问，Cx将退出。 如果该位被复位为零，总线控制器的访问将不会导致电源状态的退出。 在C3状态中，总线控制器的申请需要CPU转换回C0状态，但是在C2状态中，这样的转换将不是必须的。在C3状态下，OSPM可以设置这一位，在C1或C2状态下，可以清除该位。