<?xml version="1.0" encoding="UTF-8"?><rss version="0.92">
<channel>
	<title>{ yeah : 必须哒 }</title>
	<link>http://www.bixuda.com</link>
	<description>No place to place should record our youth?</description>
	<lastBuildDate>Mon, 11 Jul 2011 08:47:07 +0000</lastBuildDate>
	<docs>http://backend.userland.com/rss092</docs>
	<language>en</language>
	<!-- generator="WordPress/3.2" -->

	<item>
		<title>centos下采用yum升级php5.2</title>
		<description><![CDATA[# rpm --import http://www.jasonlitka.com/media/RPM-GPG-KEY-jlitka # vi /etc/yum.repos.d/CentOS-Base.repo 增加下面信息 [utterramblings] name=Jason's Utter Ramblings Repo baseurl=http://www.jasonlitka.com/media/EL$releasever/$basearch/ enabled=1 gpgcheck=1 gpgkey=http://www.jasonlitka.com/media/RPM-GPG-KEY-jlitka 执行命令，自动升级。 yum update php -y yum install libmcrypt -y]]></description>
		<link>http://www.bixuda.com/2011/07/11/centos%e4%b8%8b%e9%87%87%e7%94%a8yum%e5%8d%87%e7%ba%a7php5-2/</link>
			</item>
	<item>
		<title>利用dns隧道免费上网</title>
		<description><![CDATA[大多数机场、酒店之类场所，当你输入一个网址比如www.google.com时，会弹出一个页面要你输入帐号密码才能上网。这个时候DNS能正确解析，但是上网要付费认证。 可以通过DNS隧道来实现免费上网。具体做法是： （1）找一个支持DNS解析的域名，现在这类免费域名很多，比如tk的、co.cc的。假设该域名是abc123.tk。 （2）在tk的注册机构里，设置abc123.tk的NS服务器为你自己的主机（最好是Linux VPS），例如： abc123.tk.     IN  NS  ns.abc123.tk. ns.abc123.tk.  IN  A   74.81.81.81 （3）在74.81.81.81上，以root身份运行一个Perl脚本（这个脚本来自Dan Kaminsky的OzymanDNS包）： ./nomde.pl -i 0.0.0.0 abc123.tk 上述脚本会侦听在UDP 53端口，接受DNS请求，并且只解析abc123.tk域。 （4）在客户机上（要求有ssh，最好是Linux系统），运行如下命令： ssh -ND 7070 -o ProxyCommand=”./droute.pl sshdns.abc123.tk” user@localhost 上述ssh命令，-ND 7070表示在本机打开7070的socks 5代理端口。droute.pl是DNS隧道的客户端工具，同样来自于OzymanDNS包。sshdns是固定的主机名，加在域名abc123.tk前面。user是你在74.81.81.81上的登录名字，@localhost是固定的，不需要改（因为隧道过去后，就是74.81.81.81本机）。 运行上述ssh命令后，会提示输入密码。输入正确密码后，就和远程主机建立了ssh连接，获取到一个SSH终端。并且，在本机打开了7070的socks 5代理端口。配置浏览器使用这个代理端口，开始享受免费冲浪吧！ 转自：http://www.nsbeta.info/archives/96]]></description>
		<link>http://www.bixuda.com/2011/06/29/%e5%88%a9%e7%94%a8dns%e9%9a%a7%e9%81%93%e5%85%8d%e8%b4%b9%e4%b8%8a%e7%bd%91/</link>
			</item>
	<item>
		<title>lsof 命令详解</title>
		<description><![CDATA[lsof全名list opened files，也就是列举系统中已经被打开的文件。我们都知道，linux环境中，任何事物都是文件，设备是文件，目录是文件，甚至sockets也是文件。所以，用好lsof命令，对日常的linux管理非常有帮助。以下的说明，大部分内容来自lsof的manual文档。我所做的只是在中文翻译的基础上，进行简单的分类说明，并列举最常用的参数。&#160; 一、输出说明 lsof是linux最常用的命令之一，通常的输出格式为： 引用 COMMAND     PID   USER   FD      TYPE     DEVICE     SIZE       NODE NAME 常见包括如下几个字段：更多的可见manual。 1、COMMAND 默认以9个字符长度显示的命令名称。可使用+c参数指定显示的宽度，若+c后跟的参数为零，则显示命令的全名 2、PID：进程的ID号 3、PPID 父进程的IP号，默认不显示，当使用-R参数可打开。 4、PGID 进程组的ID编号，默认也不会显示，当使用-g参数时可打开。 5、USER 命令的执行UID或系统中登陆的用户名称。默认显示为用户名，当使用-l参数时，可显示UID。 6、FD 是文件的File Descriptor number，或者如下的内容： （这里很难翻译对应的意思，保留英文） 引用 cwd  current working directory; Lnn  library references (AIX); jld  jail directory (FreeBSD); ltx  shared library text (code and data); Mxx  hex memory-mapped type number xx. m86  DOS [...]]]></description>
		<link>http://www.bixuda.com/2011/06/23/lsof-%e5%91%bd%e4%bb%a4%e8%af%a6%e8%a7%a3/</link>
			</item>
	<item>
		<title>BMP、JPG等六种常用图形文件的结构</title>
		<description><![CDATA[bmp文件 bmp（bitmap的缩写）文件格式是windows本身的位图文件格式，所谓本身是指windows内部存储位图即采用这种格式。一个.bmp格式的文件通常有.bmp的扩展名，但有一些是以.rle为扩展名的，rle的意思是行程长度编码（runlengthencoding）。这样的文件意味着其使用的数据压缩方法是.bmp格式文件支持的两种rle方法中的一种。 bmp文件可用每象素1、4、8、16或24位来编码颜色信息，这个位数称作图象的颜色深度，它决定了图象所含的最大颜色数。一幅1-bpp（位每象素，bitperpixel）的图象只能有两种颜色。而一幅24-bpp的图象可以有超过16兆种不同的颜色。 下一页的图说明了一个典型.bmp文件的结构。它是以256色也就是8-bpp为例的，文件被分成四个主要的部分：一个位图文件头，一个位图信息头，一个色表和位图数据本身。位图文件头包含关于这个文件的信息。如从哪里开始是位图数据的定位信息，位图信息头含有关于这幅图象的信息，例如以象素为单位的宽度和高度。色表中有图象颜色的rgb值。对显示卡来说，如果它不能一次显示超过256种颜色，读取和显示.bmp文件的程序能够把这些rgb值转换到显示卡的调色板来产生准确的颜色。 bmp文件的位图数据格式依赖于编码每个象素颜色所用的位数。对于一个256色的图象来说，每个象素占用文件中位图数据部分的一个字节。象素的值不是rgb颜色值，而是文件中色表的一个索引。所以在色表中如果第一个r/g/b值是255/0/0，那么象素值为0表示它是鲜红色，象素值按从左到右的顺序存储，通常从最后一行开始。所以在一个256色的文件中，位图数据中第一个字节就是图象左下角的象素的颜色索引，第二个就是它右边的那个象素的颜色索引。如果位图数据中每行的字节数是奇数，就要在每行都加一个附加的字节来调整位图数据边界为16位的整数倍。 并不是所有的bmp文件结构都象表中所列的那样，例如16和24-bpp，文件就没有色表，象素值直接表示rgb值，另外文件私有部分的内部存储格式也是可以变化的。例如，在16和256色.bmp文件中的位图数据采用rle算法来压缩，这种算法用颜色加象素个数来取代一串颜色相同的序列，而且，windows还支持os/2下的.bmp文件，尽管它使用了不同的位图信息头和色表格式。 pcx文件 .pcx是在pc上成为位图文件存储标准的第一种图象文件格式。它最早出现在zsoft公司的paintbrush软件包中，在80年代早期授权给微软与其产品捆绑发行，而后转变为microsoftpaintbrush，并成为windows的一部分。虽然使用这种格式的人在减少，但这种带有.pcx扩展名的文件在今天仍是十分常见的。 pcx文件分为三部分，依次为：pcx文件头，位图数据和一个可选的色表。文件头长达128个字节，分为几个域，包括图象的尺寸和每个象素颜色的编码位数。位图数据用一种简单的rle算法压缩，最后的可选色表有256个rgb值，pcx格式最初是为cga和ega来设计的，后来经过修改也支持vga和真彩色显示卡，现在pcx图象可以用1、4、8或24-bpp来对颜色数据进行编码。 tiff文件 pcx格式是所有位图文件格式中最简单的，而tiff(taggedimagefileformat)则是最难的一种。 tiff文件含有.tif的扩展名。它以8字节长的图象文件头开始(ifh)，这个文件头中最重要的成员是一个指向名为图象文件目录(ifd)的数据结构的指针。ifd是一个名为标记（tag）的用于区分一个或多个可变长度数据块的表，标记中含有关于图象的信息。tiff文件格式定义70多种不同类型的标记，有的用来存放以象素为单位的图象宽度和高度，有的用来存放色表(如果需要的话)，当然还必须有用来存放位图数据的标记，一个tiff格式文件完全为它的标记所决定，而且这种文件结构极易扩展，因为你要附加一些特征只须增加一些额外的标记。 究竟是什么使tiff文件如此复杂？一方面，要写一种能够识别所用不同标记的软件非常困难。大多数tiff的阅读程序只能识别一部分标记，所以会出现这种情况：有时一个应用程序创建的tiff文件，另一个应用程序却不能使用。创建tiff文件的程序还可能会在文件中加一些只有它自己认识的标记，虽然tiff的阅读程序可以跳过那些它们不认得的标记，但这样做总是有可能影响到图象的质量。 另一方面，一个tiff文件可以包含多个图象，每个图象都有自己的ifd和一系列标记。tiff文件中的位图数据可能会用好几种方法来压缩，所以一个完备的tiff阅读程序应该有rle解压缩程序，lzw解压缩程序和其他一些算法的解压缩程序。然而更糟的是使用lzw的解码必须得到unisys公司的同意，且通常是需要付版税的。所以即使是一些相当不错的tiff阅读程序在它们遇到lzw算法压缩的图象时也是无能为力的。 尽管tiff是那么的复杂，但仍是一种最好的跨平台格式。因为它非常灵活，无论在视觉上还是其他方面，都能把任何图象编码成二进制形式而不丢失任何属性。 gif文件 当许多图象方面的权威一想到lzw的时候，他们也会想到gif（graphicsinterchangeformat，读作jiff）这是一种常用的跨平台的位图文件格式，最初为compuserve公司所创。gif文件通常带有.gif的扩展名，而且在compuseve上大量存在。 gif文件的结构取决于它属于哪一个版本，目前的两种版本分别是gif87a和gif89a，前者较简单。无论是哪个版本，它都以一个长13字节的文件头开始，文件头中包含判定此文件是gif文件的标记、版本号和其他的一些信息。如果这个文件只有一幅图象，文件头后紧跟一个全局色表来定义图象中的颜色。如果含有多幅图象(gif和tiff格式一样，允许在一个文件里编码多个图象)，那么全局色表就被各个图象自带的局部色表所替代。 在gif87a文件中，文件头和全局色表之后是图象，它可能会是头尾相接的一串图象中的第一个，每个图象由三部分组成，一个10字节长的图象描述，一个可选的局部色表和位图数据。为有效利用空间，位图数据用lzw算法来压缩。 gif89a结构与此类似，但它还包括可选的扩展块来存放每个图象的附加信息。gif89a详细定义了四种扩展块：图象控制扩展块，它用来描述图象怎样被显示(例如，显示是应该象一个透明物去覆盖上一个图象，还是简单的替换它)；简单文本扩展块，它包含显示在图象中的文本；注释扩展块，它以ascii文本形式存放注释;应用扩展块，它存放生成该文件的应用程序的私有数据。这些扩展块可以出现在文件中全局色表的任何地方。 gif最显著的优点是它的广泛使用和它的紧密性。但它有两个弱点，一个是用gif格式存放的文件最多只能含有256种颜色。另一个可能更重要，就是那些使用了gif格式的软件开发者必须征得compuserve的同意，他们每卖出一个拷贝都要向compuserve付版税。这个政策是compuserve仿效unisys公司作出的，它抑制了那些程序员在他的图象应用程序中支持gif文件。 png文件 png(portablenetworkgraphic，发音做ping)文件格式是作为gif的替代品开发的，它能够避免使用gif文件所遇到的常见问题。它从gif那里继承了许多特征，而且支持真彩色图象。更重要的是，在压缩位图数据时它采用了一种颇受好评的lz77算法的一个变种，lz77则是lzw的前身，而且可以免费使用。由于篇幅所限，在这里就不花时间来具体讨论png格式了。 jpeg文件 jpeg(jointphotographicexpertsgroup，发音做jay-peg)文件格式最初由c-cubemicrosystems推出，是为了提供一种存储深度位象素的有效方法，例如对于照片扫描，颜色很多而且差别细微(有时也不细微)。jpeg和这里讨论的其他格式的最大区别是jpeg使用一种有损压缩算法，无损压缩算法能在解压后准确再现压缩前的图象，而有损压缩则牺牲了一部分的图象数据来达到较高的压缩率。但是这种损失很小以至于人们很难察觉。 jpeg图象压缩是一个复杂的过程，经常需要专门的硬件来帮助。首先图象以象素为单位分成8*8的块。然后，每个块分三个步骤被压缩。第一步使用dct(discretecosinetransform)离散余弦变换把8*8的象素矩阵变成8*8的频率（也就是颜色改变的速度）矩阵。第二步对频率矩阵中的值用量化矩阵进行量化，滤掉那些总体上对图象不重要的部分。第三步，也就是最后一步，对量化后的频率矩阵使用无损压缩。 因为被量化后的频率矩阵缺了许多高频信息，通常能被压缩到一半甚至更少。无损压缩一般根本不能压缩真正的照片图象，所以50%的压缩率已是相当不错了，但另一方面，无损压缩能把一些图象文件尺寸减少90%，这样的图象文件就不适合用jpeg来压缩。 jpeg的有损部分产生在第二步，量化矩阵的值越高，从图象中丢掉的信息就越多，从而压缩率就越高，可是同时图象的质量就越差。在jpeg压缩时可以选择一个量化因子，这个因子的值决定了量化矩阵中的数值。理想的量化因子要在压缩率和图象质量间达到平衡，所以对不同的图象要选择不同的量化因子，通常要经过若干次尝试后方可确定。]]></description>
		<link>http://www.bixuda.com/2011/06/14/bmp%e3%80%81jpg%e7%ad%89%e5%85%ad%e7%a7%8d%e5%b8%b8%e7%94%a8%e5%9b%be%e5%bd%a2%e6%96%87%e4%bb%b6%e7%9a%84%e7%bb%93%e6%9e%84/</link>
			</item>
	<item>
		<title>GIF文件格式说明</title>
		<description><![CDATA[1. 概述 GIF(Graphics Interchange Format，图形交换格式)文件是由 CompuServe公司开发的图形文件格式，版权所有，任何商业目的使用均须 CompuServe公司授权。 GIF图象是基于颜色列表的（存储的数据是该点的颜色对应于颜色列表的索引值），最多只支持8位（256色）。GIF文件内部分成许多存储块，用来存储多幅图象或者是决定图象表现行为的控制块，用以实现动画和交互式应用。GIF文件还通过LZW压缩算法压缩图象数据来减少图象尺寸（关于LZW算法和GIF数据压缩&#62;&#62;...）。 2. GIF文件存储结构 GIF文件内部是按块划分的，包括控制块（ Control Block ）和数据块（Data Sub-blocks）两种。控制块是控制数据块行为的，根据不同的控制块包含一些不同的控制参数；数据块只包含一些8-bit的字符流，由它前面的控制块来决定它的功能，每个数据块大小从0到255个字节，数据块的第一个字节指出这个数据块大小（字节数），计算数据块的大小时不包括这个字节，所以一个空的数据块有一个字节，那就是数据块的大小0x00。下表是一个数据块的结构： BYTE 7 6 5 4 3 2 1 0 BIT 0 块大小 Block Size - 块大小，不包括这个这个字节（不计算块大小自身） 1 Data Values - 块数据，8-bit的字符串 2 ... 254 255 一个GIF文件的结构可分为文件头(File Header)、GIF数据流(GIF Data Stream)和文件终结器(Trailer)三个部分。文件头包含GIF文件署名(Signature)和版本号(Version)；GIF数据流由控制标识符、图象块(Image Block)和其他的一些扩展块组成；文件终结器只有一个值为0x3B的字符（';'）表示文件结束。下表显示了一个GIF文件的组成结构： GIF署名 文件头 版本号 逻辑屏幕标识符 GIF数据流 全局颜色列表 ... 图象标识符 图象块 图象局部颜色列表图 [...]]]></description>
		<link>http://www.bixuda.com/2011/06/14/gif%e6%96%87%e4%bb%b6%e6%a0%bc%e5%bc%8f%e8%af%b4%e6%98%8e/</link>
			</item>
	<item>
		<title>LZW算法和GIF数据压缩</title>
		<description><![CDATA[可变长度编码的LZW压缩算法(Variable-Length_Code LZW Compression)，是从LZW(Lempel Ziv Compression)压缩算法演变过来的，通过压缩原始数据的重复部分来达到减少文件大小的目的。 标准的LZW压缩原理： 先来解释一下几个基本概念： LZW压缩有三个重要的对象：数据流(CharStream)、编码流(CodeStream)和编译表(String Table)。在编码时，数据流是输入对象（图象的光栅数据序列），编码流就是输出对象（经过压缩运算的编码数据）；在解码时，编码流则是输入对象，数据流是输出对象；而编译表是在编码和解码时都须要用借助的对象。 字符(Character)：最基础的数据元素，在文本文件中就是一个字节，在光栅数据中就是一个像素的颜色在指定的颜色列表中的索引值； 字符串(String)：由几个连续的字符组成； 前缀(Prefix)：也是一个字符串，不过通常用在另一个字符的前面，而且它的长度可以为0； 根(Root)：单个长度的字符串； 编码(Code)：一个数字，按照固定长度（编码长度）从编码流中取出，编译表的映射值； 图案：一个字符串，按不定长度从数据流中读出,映射到编译表条目. LZW压缩的原理：提取原始图象数据中的不同图案，基于这些图案创建一个编译表，然后用编译表中的图案索引来替代原始光栅数据中的相应图案，减少原始数据大小。看起来和调色板图象的实现原理差不多，但是应该注意到的是，我们这里的编译表不是事先创建好的，而是根据原始图象数据动态创建的，解码时还要从已编码的数据中还原出原来的编译表（GIF文件中是不携带编译表信息的），为了更好理解编解码原理，我们来看看具体的处理过程： 编码器(Compressor) 编码数据，第一步，初始化一个编译表，假设这个编译表的大小是12位的，也就是最多有4096个单位，另外假设我们有32个不同的字符（也可以认为图象的每个像素最多有32种颜色），表示为a，b，c，d，e...，初始化编译表：第0项为a，第1项为b，第2项为c...一直到第31项，我们把这32项就称为根。 开始编译，先定义一个前缀对象Current Prefix，记为[.c.]，现在它是空的，然后定义一个当前字符串Current String，标记为[.c.]k，[.c.]就为Current Prefix，k就为当前读取字符。现在来读取数据流的第一个字符，假如为p，那么Current String就等于[.c.]p（由于[.c.]为空，实际上值就等于p），现在在编译表中查找有没有Current String的值，由于p就是一个根字符，我们已经初始了32个根索引，当然可以找到，把p设为Current Prefix的值，不做任何事继续读取下一个字符，假设为q，Current String就等于[.c.]q（也就是pq），看看在编译表中有没有该值，当然。没有，这时我们要做下面的事情：将Current String的值（也就是pq）添加到编译表的第32项，把Current Prefix的值（也就是p）在编译表中的索引输出到编码流，修改Current Prefix为当前读取的字符（也就是q）。继续往下读，如果在编译表中可以查找到Current String的值([.c.]k)，则把Current String的值([.c.]k)赋予Current Prefix；如果查找不到，则添加Current String的值([.c.]k)到编译表，把Current Prefix的值([.c.])在编译表中所对应的索引输出到编码流，同时修改Current Prefix为k ，这样一直循环下去直到数据流结束。伪代码看起来就像下面这样： 编码器伪代码 Initialize String Table; [.c.] = Empty; [.c.]k = First Character in CharStream; while ([.c.]k != EOF ) { [...]]]></description>
		<link>http://www.bixuda.com/2011/06/14/lzw%e7%ae%97%e6%b3%95%e5%92%8cgif%e6%95%b0%e6%8d%ae%e5%8e%8b%e7%bc%a9/</link>
			</item>
	<item>
		<title>测试一下wiz</title>
		<description><![CDATA[测试一下wiz 通过 Wiz 发布]]></description>
		<link>http://www.bixuda.com/2011/05/17/%e6%9c%aa%e5%91%bd%e5%90%8d/</link>
			</item>
	<item>
		<title>Ubuntu笔记本内置鼠标（触摸板）的禁用</title>
		<description><![CDATA[以下是禁用触摸板的方法。 禁用触摸板用：sudo rmmod psmouse 或是 sudo modprobe -r psmouse 启用触摸板用：sudo modprobe psmouse 不过这种方法只适用于当前 关机后再开机就没用了 还得再次输入命令 一般情况下，是使用synaptics触摸板驱动。 最直接的方法，就是卸载synaptics驱动。 sudo apt-get autoremove synaptics 但是如果一旦需要使用触摸板，还要把驱动装上，太麻烦了。 还有一种比较简单的方法。 编辑xorg.conf文件： sudo vi /etc/X11/xorg.conf Section "InputDevice" Identifier "Synaptics Touchpad" Driver "synaptics" Option "SendCoreEvents" "true" Option "Device" "/dev/psaux" Option "Protocol" "auto-dev" Option "HorizEdgeScroll" "0" Option "SHMConfig" "on" EndSection 添加 Option "SHMConfig" "on" 这行内容 [...]]]></description>
		<link>http://www.bixuda.com/2011/05/03/ubuntu%e7%ac%94%e8%ae%b0%e6%9c%ac%e5%86%85%e7%bd%ae%e9%bc%a0%e6%a0%87%ef%bc%88%e8%a7%a6%e6%91%b8%e6%9d%bf%ef%bc%89%e7%9a%84%e7%a6%81%e7%94%a8/</link>
			</item>
	<item>
		<title>ImageMagick 的php扩展 imagick段错误解决</title>
		<description><![CDATA[imagick 是 PHP 下针对 ImageMagick 这个强大软件包的 API 接口，如果你在编译 ImageMagick 的时候将 IMAGEMAGICK_JPEG2000 编译进去了，你的 PHP 在启用 MagickWand 模块后会发生段错误，无法正常使用 PHP。 解决方法也就显而易见，在通过 源码安装的时候加上配置 --without-jp2，即： ./configure --without-jp2，安装即可。]]></description>
		<link>http://www.bixuda.com/2011/03/23/imagemagick-%e7%9a%84php%e6%89%a9%e5%b1%95-imagick%e6%ae%b5%e9%94%99%e8%af%af%e8%a7%a3%e5%86%b3/</link>
			</item>
	<item>
		<title>Support NginxWiki-20110303.chm to download</title>
		<description><![CDATA[Nginx more and more popular, but official wiki have too much time to chm[NginxWiki-20090731.chm], so I compiled the latest sync to the wiki into chm, available to the offline-read students who needed. Download: NginxWiki-20110303.chm.tar.gz]]></description>
		<link>http://www.bixuda.com/2011/03/03/support-nginxwiki-20110303-chm-to-download/</link>
			</item>
</channel>
</rss>

