大多数人很容易将CSS属性display和visibility混淆，它们看似没有什么不同，其实它们的差别却是很大的。

    一些操作系统的最新版本已经更新了 /proc/cpuinfo 文件，以支持多路平台。如果您的系统中的 /proc/cpuinfo 文件能够正确地反映出处理器信息，那么就不需要执行上述步骤。反之，可采用本文中的信息进行解释。

    /proc/cpuinfo 文件包含系统上每个处理器的数据段落。/proc/cpuinfo 描述中有 6 个条目适用于多内核和超线程（HT）技术检查：processor, vendor id, physical id, siblings, core id 和 cpu cores。

    目前服务器上配置的CPU是越来越多，并且，单个物理CPU中也包括了更多的核心。以Intel E5504为例，一个CPU就拥有4个核心，并发的速度得到明显的提高。其中，部分CPU还同时拥有超线程技术，这样，系统中识别出来的核心数量会更多。要让系统正确的识别出所有可用的CPU核心，系统使用Linux kernel是个关键，例如使用smp或largesmp，打开kernel编译时的支持等。当然，kernel越新，兼容性通常会更好。
    但我接下来要举出的案例，确与kernel关系不大，因此该kernel（红旗 DC Server 5.0 SP3）已经被确认可支持多大64个物理core，而且支持双核、四核、六核等架构。该问题的解决过程，由zhengyiyun#redflag-linux.com提供，我觉得相当值得借鉴。

    最近在看《藏地密码》，其中多次提到“反万字”符号，特从互动百科上查询了一下，摘录如下：

反万字-概述    
     区别但类似于万字符号“卍”的一个符号，曾被用作纳粹党标志。
    最早于摩亨佐达罗废墟中出土的印章上就有“卐”符号，后来“卐”又被亚利安人所接受，在佛教出现前的印度这个符号就曾广为使用。古印度的“卐”包括佛教中的“卍”其实并没有固定的旋转方向，写成“卐”“卍”皆可，在印度以及我国内陆的早期佛教造像任意旋转方向的“卐”中看出。印度教则认为“卐”“卍”是同一符号，只不过因为被刻画神像的性别不同而旋转方向有所不同。

    由于共享磁盘大多很昂贵，所以搭建系统的成本也就随之增加。不使用共享磁盘，在各服务器之间对各服务器上的磁盘进行镜像，通过该方法用低廉的价格实现相同功能的集群系统称为镜像磁盘型。使用Red Flag HA Cluster 6.0新增的磁盘镜像功能，不需要购买昂贵的磁盘柜就能享受到高可用性及高可靠性；配合HA Cluster 6.0独有的FastSync选件，能得到几乎和使用磁盘柜同样的性能，大幅度缩减投资预算。

    插入式验证模块（Pluggable Authentication Module，PAM）API 将公开一组功能，应用程序程序员可以使用这些功能来实现与安全性相关的功能，例如用户验证、数据加密、LDAP 等。

    经常遇到的问题是，使用了BOM编码后，PHP脚本执行错误，或使用fileStream读取并转换为XML会报错"The markup in the document following the root element must be well-formed."。

    由于学习的需要，我希望在Windows XP平台上搭建一个AMP（Apache+Mysql+Php/Perl）的环境。但我可不想慢慢的去安装、配置Windows下的东西，XAMPP正是一个不错的快捷方式。

    Linux原生的ext4文件系统目前已经在一些最新的Linux发布版本中包含了，我也使用了一段时间，和ext3相比，有所改善但是不是那种非常显著的干劲，更详细的情况可以参考这篇文章(ext4文件系统：介绍及性能测试)。
    不过我一直向往Solaris上的ZFS，觉得那才是真正的企业级文件系统，COW,CDP等功能让人着迷，虽然目前linux上已经有基于fuse的ZFS实现，但是性能上就大打折扣了，直到btrfs文件系统的出现，让我看到了未来：Btrfs （通常唸成Butter FS）。
    承若将赋予这个文件系统许多类似ZFS的企业级特征，甚至在性能和亮点上要超过ZFS。事实上，很多Linux专家认为btrfs应该是Linux未来的一个关键点。不过目前btrfs目前还没有完全发布，不过相信很快大家就能用到了，在正式使用之前，我们不妨对它做一些了解，甚至可以对其进行一些性能上的测试。

    最早接触Satisfy，是这样一个情况，一个目录启用了密码保护，想单独开放它的一个子目录，让这个子目录无须密码即可访问，那么需要这样设置：

    经过前面的讲解，相信大家对Subversion的使用也基本了解。但之前讲述的svn://协议和http://采用的都是明文方式，这可能会带来安全问题。我们可以采用svn+ssh或Apache+SSL的方式增强安全性。

    在前面的日志中，讲述了如何使用Subversion提供的svnserve服务，通过svn://协议访问远端的仓库数据。实际上，Subversion的设计包括了一个抽象的网络层，这意味着版本库是可以通过各种服务器进程访问的。理论上来会说，Subversion可以使用无限数量的网络协议来实现，甚至可以直接用perl利用相关的接口来编写自定义协议。但日常中，用得最多的就是svn://协议，和用mod_dav_svn模块通过Apache服务进行访问。
    通过HTTP协议访问版本库是Subversion的亮点之一，这种方式具备许多svnserve服务器所没有的特性，使用上更加灵活。