Max's Blog

今天用了win2003 sp2 r2（x64)的简体中文msdn标准版，怎么发现应用程序里面的字体小了，不知道哪里能改呢？比如QQ好友组的那些字体都好小，谁知道怎么搞啊？？？谢谢了

通过更改主题外观不能解决问题，这个我已经测试了。有其他办法么？

自己终于搞定了，希望对其他人有类似问题的有帮助
　　打开注册表编辑器找到这里
　　[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\GRE_Initialize]
　　把”GUIFont.Facename”字符串的值改为Tahoma
　　把”GUIFont.Height”DWORD值改为8
   
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes]
    把”MS Shell Dlg 2″和”MS Shell Dlg”字符串的值改为Tahoma
　　结果如下面所示：
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\GRE_Initialize]
　　”GUIFont.Facename”=”Tahoma”
　　”GUIFont.Height”=dword:00000008

　　[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes]
　　”MS Shell Dlg 2″=”Tahoma”
　　”MS Shell Dlg”=”Tahoma”

改完后重启就好了，呵呵。

新版伽利略eclipse会和flashget、360安全卫士等冲突，导致不能启动，

以下是解决方法

快捷方式加上参数 -vm “%JAVA_HOME%\jre\bin\javaw.exe”

指定使用javaw，以前eclipse默认是使用javaw的，不知道为啥现在改了，呵呵。

可能是问题原因：

The reason we need a contiguous memory region for the heap is that we have a bunch of side data structures that are indexed by (scaled) offsets from the start of the heap. For example, we track object reference updates with a “card mark array” that has one byte for each 512 bytes of heap. When we store a reference in the heap we have to mark the corresponding byte in the card mark array. We right shift the destination address of the store and use that to index the card mark array. Fun addressing arithmetic games you can’t do in Java that you get to (have to 🙂 play in C++.

Usually we don’t have trouble getting modest contiguous regions (up to about 1.5GB on Windohs, up to about 3.8GB on Solaris. YMMV.). On Windohs, the problem is mostly that there are some libraries that get loaded before the JVM starts up that break up the address space. Using the /3GB switch won’t rebase those libraries, so they are still a problem for us.

We know how to make chunked heaps, but there would be some overhead to using them. We have more requests for faster storage management than we do for larger heaps in the 32-bit JVM. If you really want large heaps, switch to the 64-bit JVM. We still need contiguous memory, but it’s much easier to get in a 64-bit address space.

永久解决方案：

用gbk建表，或者指定gbk字段，mysql 5.x支持某列单独定义字符集。

临时解决方案：

SELECT * FROM table ORDER BY CONVERT( chinese_field USING gbk ) ;

 

今天转换sql server 项目遇到的问题，记录一下，呵呵

今日升级了一下openssh，用了里面的自带chroot来实现SFTP的目录权限限制，详细如下：

首先升级openssh，目前版本是5.2p2，要使用ChrootDirectory需要4.8以上的版本

centos下：

./configure –prefix=/usr –sysconfdir=/etc/ssh –with-pam –with-kerberos5 –with-md5-passwords –with-tcp-wrapper

make

make install

 

编辑/etc/ssh/sshd_config

把

Subsystem      sftp    /usr/libexec/openssh/sftp-server

替换为

Subsystem sftp internal-sftp

开启内部sftp server支持

增加：

AuthorizedKeysFile /home/%u/.ssh/authorized_keys

Match group sftponly
  ChrootDirectory /home/%u
  X11Forwarding no
  AllowTcpForwarding no
  ForceCommand internal-sftp

 保存退出。

/etc/init.d/sshd restart

重启sshd 服务

假设user是ssmax

# chown root.root /home/ssmax
# usermod -d /sftp ssmax

# mkdir /home/ssmax/sftp

# chown ssmax.ssmax /home/ssmax/sftp

# groupadd sftponly
# adduser user sftponly

 

由于chroot必须目录是只有root可写，所以我们 ChrootDirectory /home/%u 之后，必须把  /home/%u 改为root权限。

而把用户根目录改成/sftp，其实就是在chroot以后自动进入/home/%u/sftp目录，该目录才是用户可写的

这里有个必须要注意的地方就是，用户Key验证的时候，读取的key文件是在还没有chroot之前就读取的，所以如果改变了用户根目录，默认ssh就回去/sftp/.ssh/authorized_keys 里面读取公钥，这个目录当然是不存在的，所以我们要改变默认的key读取方式：

AuthorizedKeysFile /home/%u/.ssh/authorized_keys

当然也有例外一种解决方法，就是在/home/%u下面，再建立 /home/%u/home/%u

这样key验证会在 /home/%u/.ssh/authorized_keys 下面进行

chroot登录后直接就进入 /home/%u/home/%u，但是这样的话，好像目录就太多层了，而且也很混乱，哈哈。

 

整个sftp的过程：

首先用key登录ssh：

查找AuthorizedKeysFile 指定的key文件，如果是相对路径，就查找当前登录用户根目录（/etc/passwd）下的.ssh/authorized_keys文件

登录ssh后chroot 到 ChrootDirectory 设置的目录，改目录必须是只有root可写。

chroot以后进入用户根目录，这个时候根目录还是读取（/etc/passwd）里面的设置，但是根是相对于ChrootDirectory 的存在了，比如ssmax的根目录是/home/ssmax，ChrootDirectory 也是/home/ssmax

这个时候用户的根目录就在 /home/ssmax/home/ssmax 里面了。

 

当然如果不用key的话就不用搞得这么复杂咯，哈哈。