Upgrade wifi from 11m to 54m
用u8c也有一段时间了，虽然是几年前的产品，但不少细节的设计甚至可以让今天的umpc汗颜。当然，没有完美的东西，要说u8c的不足或者遗憾，也尽可以洋洋洒洒的写很多，有空再说吧
原来用n410c上的万通宝wifi，本身就是802.11b规范，所以配合的ap也一直是11m的，现在u8c可是直接支持g的，今天抽空换了一个，效果明显啊。不过就规范而言，都远没有达到理论上限，b大概可以到理论值的60-65%，g大概是55%左右，不过这个似乎是司空见怪的事情，想想usb2.0的480m，好像也差得很远呢。
保持同一环境的测了一下对比，图片如下下面，嗯，还是相当明显的，2.5MB/s的速度，大部分情况下，就算是大文件的拷贝，我也懒得再切到有线了。
不过g的高速度跟信号的关系相当明显，开始我把ap放在比较隐蔽的机房，中间略有阻隔，居然测试出来的速度只有400KB/s左右，以至于我怀疑到底有没有工作在g，放到开阔的地方就好多了。不过netgear民用ap样子虽然好看（有mac的风格）的信号确实偏弱了点，家用的话还可以（前提条件不是豪宅，而且墙也不能太厚），以后如果面积比较大的话，我打算尝试一下工业级的产品了，不然一个ap只能覆盖那么点地方，没办法铺开啊。
——
·本文由 iamcj 原创，采用
“CC创作共用”方式共享
Solved two small problems
从AppServ转到APMServ之后，出现了两个问题，依靠在newsmth的提问和个google，全部搞定，记录流水帐如下：
Blog顶部出现了很奇怪的Warning: Cannot modify header information - headers already sent by (output started at D:\APMServ\www\htdocs\www.iamcj.net\blog\wp-blog-header.php:1) in D:\APMServ\www\htdocs\www.iamcj.net\blog\wp-content\plugins\ImageCounter\ImageCounter.php on line 47。
看着提示，到ImageCounter.php的47行一看，没有什么特别的，是一行设置cookie的内容。
再看wp-blog-header.php的第一行，还是没有思路，看错误信息好像是重复发送了header，怎么会呢。
放狗搜，同样的问题别人早碰到过了，同时在这儿有更详细的理论阐述（拜yskinJ）是因为wp-blog-header.php在保存的时候，加了一个unicode的签名，一般这是因为用了Windows自带的记事本编辑导致的，解决的办法是用EmEditor或者UE之类的工具，保存的时候去掉下面这个类似的选项，就OK了；
WordPress的重定向功能失效，具体表现就是blog首页打开完全正常，点击任何文章、分类、评论都出错，但是后台也可以进去，看起来也没有错误。偶然发现在”设置——永久链接——自定义永久链接结构——常规设置”里面选择默认方式就好了，也就是/?p=123的形式，但是这样一来以前全部的链接就都失效，这个代价也太大了些，继续找办法……
有人把这个问题归纳为rewrite重写功能没有打开并提出的解决办法，但是我phpinfo看到的信息rewrite分明是enable的，在newsmth上问，没有结果，有朋友说有时候就是有这样的问题，没办法，不死心。
不过经过前面的迷茫，已经把目光集中到rewrite功能上了，集中精力找APMServ和这个的关系（因为是切换服务器之后出现的），终于找到症结所在，APMServ环境下里面，影响这个功能的有三个地方：
- 全局的httpd.conf，影响整个服务器，位于/Apache/conf，检查rewrite_module模块前面有没有被#注释掉；
- 局部的vhost.conf，影响当前虚拟主机，位于/Apache/conf /apmserv，对应的虚拟主机的AllowOverride后面如果是None（默认值），就不能复写，得修改成Options FileInfo；
- 目录下的.htaccess文件，影响当前目录，RewriteEngine必须是On，这个一般没问题，是具体程序（如WordPress设置的）。
我前面忽略的就是第二点，修改，重启apache，搞定。
——
·本文由 iamcj 原创，采用
“CC创作共用”方式共享
Change from AppServ to APMServe
用了很长一段时间的AppServ，就是包含了apache+php+mysql+phpmyadmin的服务器集成环境，应该说比起全部自己手工架，还是有相当的优势的，不会出错，不会冲突，速度快，性能稳定，嗯，这些就足够了。
最近接触了APMServe，另外一个类似的集成环境。试用之后，我感受到的优势是：
- 集成度更高：除了AppServ的那些组件之外，还有MiniPerl（Perl脚本解释器）、4.x和5.x的双版本mysql支持、SQLite、SQLiteManager、ZendOptimizer，OpenSSL，虽然不一定用得到，但是在默认关闭的情况下，并不影响使用，如果需要的话就是莫大的优点了，比如以前帮别人调shopex的时候就需要Zend，那时候不得不去找AppServ的Zend Add-on，现在就不需要了，启用即可；
- 方便的管理界面：众所周知，apache的配置最多接触的就是虚拟主机和虚拟目录的管理，原来也已经习惯了编辑httpd.conf，但是APMServ提供了图形化的配置界面，用起来还是相当方便的；
- 纯绿色：直接解压缩就可以用，虽然还是会写系统服务（为了启动），但是这个过程是清晰可控的；
- 居然还支持ASP：虽然没测试过，但是既然放出来了，至少是基本可用的，估计搞个简单的动网还是没问题的（不然也别说支持了）；
看起来APMServ是作者在大学的时候开发的作品，毕业之后似乎进入了sina，估计也无暇顾及了，不然的话，很多方面的细节都可以优化，一些小错误也可以改正，包括界面上的一些功能，原来应该在下一个版本中就可以实现的，现在遥遥无期了。
就算这样，APMServ还是个相当不错的集成环境，对于开发调试和一般规模的应用，都没有问题。
不过今天在迁移原来AppServ的过程中，还是有点意外的，本来想合在一起写的，但是似乎不太相关，还是分离吧。
补充一下，与此二者同类型的还有xampp，评价也相当不错，是apache friends的成员，还是跨平台的开源系统，特色是大量的插件，可以支持Perl和Tomcat(!)，有兴趣的可以自己试试看，我这边测试有点启动方面的小问题。
——
·本文由 iamcj 原创，采用
“CC创作共用”方式共享