华硕键盘FN故障，无法调节亮度。另类解决办法。

前天一边Dota一边喝功夫茶，不小心喂了本本几滴。曾经无数次地指导过菜鸟们如何处理键盘进水，没想到这次轮到我了。开始我居然还没发觉，直到Dota里面怎么都选不中英雄，才意识到进水了--囧。立马，电脑倒过来，关机、取出电池---dota可耻的秒了，可惜了我的虎妞呀。

While N 小时后,开机，测试一遍，F3,F4,F5挂掉了。。。。。。反正平常也没有用，偶尔用之也能唤出屏幕键盘。若干天后，开电影，用FN+F6把屏幕亮度调到了最亮....杯具出现了，因为F5挂掉，再也没办法把亮度调回来。熬到凌晨，尝试了N 多方法后，终于找到了华硕的另类解决方法。总结如下:

失败 1,  试图使用按键精灵修改键盘，发现无法实现FN的组合.....因为找不到FN对应的键值，google传说FN是通过跟某个数运算，结果如果返回是255，就产生fn对应的中断........不求甚解，盯着汽车大灯一样的屏幕，估计你也没有那个心情再去探究他对应的是哪个了吧。

失败 2，试图修改注册表，把F5映射到F6。相当简单.......可是按下FN之后产生的中断告诉了电脑，F6永远是F6.....F5永远是F5......至于台湾的F4太扯了---杯具
(华硕键盘的FN组合，估计是在BIOS级别实现了吧，因为只要加电这些组合键就有作用。证据 1 ,BIOS画面，可以使用组合键。2，在没有图形界面的linux里面同样能调节亮度。想到这里，估计这台本本是基本告别Linux了。)

失败 3，掰开键盘，擦擦？？？估计薄膜那层挂了，，，又一次杯具。而且身边没有酒精、没有镊子、仅有钥匙5把，以及大得可以切苹果的剪刀一把。

失败 4，BIOS里面竟然无亮度设置。

未尝试的计划 5，弄一个外置的usb键盘，带fn键的。。。。几十大元呀，不到万不得还是不花钱好。小弟每个月工资1500，不包吃不包住的喔。------原来我就是个杯具。

未尝试的计划 6，华硕售后。2010年的第一天，没有人工作滴。他们终于洗具了一把。
..............................................若干小时之后，终于，我的洗具出现了。

华硕的本本有一个Power4 Gear的电源管理工具，能够设置几个不同本本使用状态，控制cpu，屏幕亮度，待机时间等等。为了我的开机进程，一般都是一概不自己启动，禁止掉了。这次没想到成了我的救星。里面可以设置屏幕的亮度，不过得这样操作。
1，装上电池，2，拔掉外接电源（此时才能设置屏幕亮度）3，设置一个最低的亮度，4，直接退出Power4 Gear，亮度此时就不会变了，5，接回外接电源。再用fn+f6，调到自己合适的亮度。
The End Goto 洗具

失败 5，

posted @ 2010-01-01 12:22 Jarod.cn.LuLuLife 阅读(3533) | 评论 (0) | 编辑 收藏

linux file system

以下文章是我自己翻译的，后面有英文的原文。不当之处，敬请指教.
应该不是太新的文章，但是我我是2006-07-12的上午才看到的。哎........

2006-07-12 15:00 翻译完成
--------------------------------------------------------------------------------------------------------------
肠子都悔青了，昨天刚刚新加的硬盘上面的文件系统还是被我搞成了ext3。如果我能造一天注意到这篇文章的话........
----------------------------------------------------------------------------------------------------------------


Debian Administration
System Administration Tips and Resources

现在还可以得到的许多Linux filesystems 比较，但是他们中大多数是古老的，基于为人任务的或者在更老的情况下完成。 这篇基准测试文基于与老一代的适合一台文件服务器的11项硬件(奔腾II/III，EIDE硬盘)。

从最初编制到出版，文章已经产生许多变化，意见和建议改进。我目前正努力进行一些新的试验。(回答在原文范围的问题)。

结果将在大约在(2006年5月8日)可提供


汉斯

为什么要做基准测试？

我发现quantitative and reproductible benchmark基准使用2.6.x kernel。

Benoit在2003年在有512 MB RAM 的PIII 500服务器上使用大文件(1 + GB)实现12次试验。 这次试验信息十分丰富，但是结果对2.6.x kernel开始，主要适用于底座， 专门操作大的锉(例如，多媒体，科学，数据库)。

Piszcz 在2006年实现21项任务(有768 MB RAM 和一个400GBEIDE-133硬盘在PIII-500 模拟多种文件操作)。到目前为止，这测试看起来是在2.6.x kernel上的最全面的工作。 但是， 很多任务是人造的(例如， 复制和删除10，000个空目录，新建10，000个文件，递归分割文件)，把这些结论应用到现实世界可能是无意义的。

因此， 这里测试的基准的目标是验证一些Piszcz(2006)的结论， 通过专门应用于现实世界在小型企业文件服务器(看见任务描述)里找到。

测试基础

    * Hardware Processor : Intel Celeron 533
    * RAM : 512MB RAM PC100
    * Motherboard : ASUS P2B
    * Hard drive : WD Caviar SE 160GB (EIDE 100, 7200 RPM, 8MB Cache)
    * Controller : ATA/133 PCI (Silicon Image)

    * OS Debian Etch (kernel 2.6.15), distribution upgraded on April 18, 2006
    * All optional daemons killed (cron,ssh,saMBa,etc.)

    * Filesystems Ext3 (e2fsprogs 1.38)
    * ReiserFS (reiserfsprogs 1.3.6.19)
    * JFS (jfsutils 1.1.8)
    * XFS (xfsprogs 2.7.14)

选择的测试任务描述

*在一个大文件(ISO 镜像文件，700 MB)的从第2个磁盘复制到这个试验磁盘
*再从在另一个位置再复制这个 ISO 一次
*删除这个ISO 的两个副本

*操作一文件树(有7500 文件，900 目录，1.9GB)，从第2 磁盘复制到这个试验磁盘
*再从在另一个位置再复制这个文件树 一次
*删除这个文件树的两个副本

*用递归的方法遍历文件树目录和文件树的全部内容，复制到这个试验磁盘
*匹配通配符，在文件树查找具体的文件

*用(mkfs) 建立filesystem(全部FS都使用默认值)
*mount  filesystem
*Umount filesystem

上述11项任务(从建立filesystem到umounting filesystem)的顺序，编写为Bash script运行完成3 次(报告平均成绩)。 每个顺序花费大约7分种，完成任务的时间用秒计算，  GNU time utility (version 1.7) 记录任务时的CPU 的利用百分比。

结果

分区能力

(在filesystem 创造之后)初始化分区并重新划分block的过程里，Ext3有最差的初始利用率(92.77%)， 其它的filesystem 几乎可是使用全部的容量(ReiserFS = 99.83%，JFS = 99.82%，XFS = 99.95%)。
结论： 为了使用你的分区的的最大容量，选择ReiserFS，JFS或者XFS。

建立文件系统，mount和unmounting

在20GB的分区创造filesystem测试，划分为Ext3带14.7秒， 与为相比其他filesystem多2秒或更少。(ReiserFS = 2.2，JFS = 1.3，XFS = 0.7)。

不过，挂载ReiserFS 要比其他的FS多花费5-15倍时间(2.3秒)(Ext3 = 0.2, JFS = 0.2, XFS = 0.5)，umount以及要比其他的FS多花费2 倍时间(0.4秒)。

所有的FS都花费差不多CPU占用来创建FS(59%（ReiserFS） -74%（JFS）)，挂载FS(在6和9%之间)。 不过，Ext3 和XFS多用2倍的CPU占用 给umount(37% 和45%)， ReiserFS和JFS(14% 和27%)。
结论： 对创建FS性能和mounting/unmounting来说，选择JFS或者XFS。

大文件操作性能(ISO image，700 MB)

    把大文件复制到Ext3(38.2秒)和ReiserFS(41.8)， 要比JFS和XFS(35.1和34.8)需要更多时间。使用XFS有助于提高在相同的磁盘上复制相同的文件(XFS=33.1,Ext3 = 37.3，JFS = 39.4，ReiserFS = 43.9)相比。 在JFS和XFS上删除那些ISO 大约要快100 倍(0.02秒)，（ReiserFS1.5秒，Ext32.5秒）！所有FS复制时的CPU利用(在46和51%之间)，再复制时(在38%到50%之间)。当其他FS使用大约10%时，ReiserFS使用49%的CPU。 比他FS大约少5到10%)，JFS使用较少的CPU。
结论： 对大文件操作性能来说，最好选择JFS或者XFS。 如果你需要使CPU利用减到最小，更推荐JFS。


目录树(7500个文件，900份目录，1.9GB)的操作

    最初复制目录树时，Ext3(158.3秒)和XFS(166.1秒)更迅速， ReiserFS和JFS(172.1和180.1)。在第二次复制的时候有相似的结果。（Ext3=120秒，XFS = 135.2，ReiserFS = 136.9 和JFS = 151)。但是， 移动目录树时Ext3(22秒)相比ReiserFS(8.2秒， XFS(10.5秒)和JFS(12.5秒))大约多2倍时间！所有FS在复制和再复制目录树时都使用较多的CPU (复制在27和36%之间)，(再复制在29%-JFS和45%-ReiserFS之间)。

    令人吃惊，ReiserFS 和XFS使用更多的CPU 删除目录树(86% 和65%)， 而其他FS只使用大约15%的(Ext3和JFS)。再次，与任何其他FS相比较，JFS的明显使用较少CPU。 当有较多的数量较小页面时适合ReiserFS。这个差别在目录树的再复制和移动里的ReiserFS将有更高的速度。
    结论：对在大容量的目录树操作来说，选择Ext3或者XFS。 来自其他作者的基准测试已经证明如果使用ReiserFS，对大量的小文件更为合适。但是，目前包括各种各样尺寸(10KB在5 MB)数千文件的目录树操作上，建议使用Ext3或者XFS可能获得更好的性能。如果JFS的CPU占用减到最小，这种FS带着相当高的性能。

目录列表和文件查找

     递归显示目录的目录列表，ReiserFS(1.4秒)和XFS更迅速的1.8)， Ext3和JFS(2.5和3.1)。文件查找有着相同的结果。在文件查找项目， ReiserFS(0.8秒)相比XFS(2.8)和Ext3(4.6秒)和JFS(5秒)更迅速。 Ext3和JFS有更好CPU占用：目录列表(35%)，文件查找(6%)。 XFS目录列表(70%)使用更多的CPU，文件查找(10%)。 ReiserFS 看起来是占用CPU最多的FS，目录列表71%，文件查找36% 。
结论： 结果表明那， 对于这些CPU占用任务来说，(ext3和JFS)filesystems 能更少的使用CPU的。 XFS作为好备选，带有相对适中的性能和CPU的占用。

总的结论

这些结果从Piszcz(2006)关于分解的Ext3，ReiserFS的磁盘能力报告一样。 这两篇文章两篇已经显示JFS是最低的CPU利用的FS。 最后，这份报告看起来没有显示出ReiserFS的high page faults activity 

由于一个分区只能有一个filesystem，认识每种filesystem的优缺点很重要。如果，以这篇文章的全部测试为基准， XFS看起来是家庭或者小型企业最适合的应用于文件服务器的filesystem：

*它使用你的服务器硬盘(s)的拥有最大的容量
*创建FS，mount和unmount很迅速
*操作大文件最迅速的FS(>500 MB)
*这FS得第二名地方给经营关于许多在适度尺寸文件和目录小
*在CPU占用和目录列表或者文件搜寻性能之间比较平衡，
*没有最小CPU要求，老一代硬件也可十分接受

Piszcz(2006)当时没有明确推荐XFS，他只是说："就个人来说，我仍然愿意选择同时具备性能和可伸缩性的XFS"。 现在我只能支持这个结论。

参考

贝努瓦，M.(2003)。 Linux 文件系统基准。

Piszcz，J.(2006)。 基准问题测试Filesystems第二部分。 Linux Gazette, 122 (January 2006)。


以下是原文
-----------------------------------------------------------------------

Debian Administration
System Administration Tips and Resources
[ About | Archive | FAQ | Hall of Fame | Search | Tagged Articles |
Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch


There are a lot of Linux filesystems comparisons available but most of them are anecdotal, based on artificial tasks or completed under older kernels. This benchmark essay is based on 11 real-world tasks appropriate for a file server with older generation hardware (Pentium II/III, EIDE hard-drive).

Since its initial publication, this article has generated
a lot of questions, comments and suggestions to improve it.
Consequently, I'm currently working hard on a new batch of tests
to answer as many questions as possible (within the original scope
of the article).

Results will be available in about two weeks (May 8, 2006)

Many thanks for your interest and keep in touch with
Debian-Administration.org!

Hans

Why another benchmark test?

I found two quantitative and reproductible benchmark testing studies using the 2.6.x kernel (see References). Benoit (2003) implemented 12 tests using large files (1+ GB) on a Pentium II 500 server with 512MB RAM. This test was quite informative but results are beginning to aged (kernel 2.6.0) and mostly applied to settings which manipulate exclusively large files (e.g., multimedia, scientific, databases).

Piszcz (2006) implemented 21 tasks simulating a variety of file operations on a PIII-500 with 768MB RAM and a 400GB EIDE-133 hard disk. To date, this testing appears to be the most comprehensive work on the 2.6 kernel. However, since many tasks were "artificial" (e.g., copying and removing 10 000 empty directories, touching 10 000 files, splitting files recursively), it may be difficult to transfer some conclusions to real-world settings.

Thus, the objective of the present benchmark testing is to complete some Piszcz (2006) conclusions, by focusing exclusively on real-world operations found in small-business file servers (see Tasks description).

Test settings

    * Hardware Processor : Intel Celeron 533
    * RAM : 512MB RAM PC100
    * Motherboard : ASUS P2B
    * Hard drive : WD Caviar SE 160GB (EIDE 100, 7200 RPM, 8MB Cache)
    * Controller : ATA/133 PCI (Silicon Image)

    * OS Debian Etch (kernel 2.6.15), distribution upgraded on April 18, 2006
    * All optional daemons killed (cron,ssh,saMBa,etc.)

    * Filesystems Ext3 (e2fsprogs 1.38)
    * ReiserFS (reiserfsprogs 1.3.6.19)
    * JFS (jfsutils 1.1.8)
    * XFS (xfsprogs 2.7.14)

Description of selected tasks

    * Operations on a large file (ISO image, 700MB) Copy ISO from a second disk to the test disk
    * Recopy ISO in another location on the test disk
    * Remove both copies of ISO

    * Operations on a file tree (7500 files, 900 directories, 1.9GB) Copy file tree from a second disk to the test disk
    * Recopy file tree in another location on the test disk
    * Remove both copies of file tree

    * Operations into the file tree List recursively all contents of the file tree and save it on the test disk
    * Find files matching a specific wildcard into the file tree

    * Operations on the file system Creation of the filesystem (mkfs) (all FS were created with default values)
    * Mount filesystem
    * Umount filesystem

The sequence of 11 tasks (from creation of FS to umounting FS) was run as a Bash script which was completed three times (the average is reported). Each sequence takes about 7 min. Time to complete task (in secs), percentage of CPU dedicated to task and number of major/minor page faults during task were computed by the GNU time utility (version 1.7).

RESULTS

Partition capacity

Initial (after filesystem creation) and residual (after removal of all files) partition capacity was computed as the ratio of number of available blocks by number of blocks on the partition. Ext3 has the worst inital capacity (92.77%), while others FS preserve almost full partition capacity (ReiserFS = 99.83%, JFS = 99.82%, XFS = 99.95%). Interestingly, the residual capacity of Ext3 and ReiserFS was identical to the initial, while JFS and XFS lost about 0.02% of their partition capacity, suggesting that these FS can dynamically grow but do not completely return to their inital state (and size) after file removal.
Conclusion : To use the maximum of your partition capacity, choose ReiserFS, JFS or XFS.

File system creation, mounting and unmounting

The creation of FS on the 20GB test partition took 14.7 secs for Ext3, compared to 2 secs or less for other FS (ReiserFS = 2.2, JFS = 1.3, XFS = 0.7). However, the ReiserFS took 5 to 15 times longer to mount the FS (2.3 secs) when compared to other FS (Ext3 = 0.2, JFS = 0.2, XFS = 0.5), and also 2 times longer to umount the FS (0.4 sec). All FS took comparable amounts of CPU to create FS (between 59% - ReiserFS and 74% - JFS) and to mount FS (between 6 and 9%). However, Ex3 and XFS took about 2 times more CPU to umount (37% and 45%), compared to ReiserFS and JFS (14% and 27%).
Conclusion : For quick FS creation and mounting/unmounting, choose JFS or XFS.

Operations on a large file (ISO image, 700MB)

The initial copy of the large file took longer on Ext3 (38.2 secs) and ReiserFS (41.8) when compared to JFS and XFS (35.1 and 34.8). The recopy on the same disk advantaged the XFS (33.1 secs), when compared to other FS (Ext3 = 37.3, JFS = 39.4, ReiserFS = 43.9). The ISO removal was about 100 times faster on JFS and XFS (0.02 sec for both), compared to 1.5 sec for ReiserFS and 2.5 sec for Ext3! All FS took comparable amounts of CPU to copy (between 46 and 51%) and to recopy ISO (between 38% to 50%). The ReiserFS used 49% of CPU to remove ISO, when other FS used about 10%. There was a clear trend of JFS to use less CPU than any other FS (about 5 to 10% less). The number of minor page faults was quite similar between FS (ranging from 600 - XFS to 661 - ReiserFS).
Conclusion : For quick operations on large files, choose JFS or XFS. If you need to minimize CPU usage, prefer JFS.

Operations on a file tree (7500 files, 900 directories, 1.9GB)

The initial copy of the tree was quicker for Ext3 (158.3 secs) and XFS (166.1) when compared to ReiserFS and JFS (172.1 and 180.1). Similar results were observed during the recopy on the same disk, which advantaged the Ext3 (120 secs) compared to other FS (XFS = 135.2, ReiserFS = 136.9 and JFS = 151). However, the tree removal was about 2 times longer for Ext3 (22 secs) when compared to ReiserFS (8.2 secs), XFS (10.5 secs) and JFS (12.5 secs)! All FS took comparable amounts of CPU to copy (between 27 and 36%) and to recopy the file tree (between 29% - JFS and 45% - ReiserFS). Surprisingly, the ReiserFS and the XFS used significantly more CPU to remove file tree (86% and 65%) when other FS used about 15% (Ext3 and JFS). Again, there was a clear trend of JFS to use less CPU than any other FS. The number of minor page faults was significantly higher for ReiserFS (total = 5843) when compared to other FS (1400 to 1490). This difference appears to come from a higher rate (5 to 20 times) of page faults for ReiserFS in recopy and removal of file tree.
Conclusion : For quick operations on large file tree, choose Ext3 or XFS. Benchmarks from other authors have supported the use of ReiserFS for operations on large number of small files. However, the present results on a tree comprising thousands of files of various size (10KB to 5MB) suggest than Ext3 or XFS may be more appropriate for real-world file server operations. Even if JFS minimize CPU usage, it should be noted that this FS comes with significantly higher latency for large file tree operations.

Directory listing and file search into the previous file tree

The complete (recursive) directory listing of the tree was quicker for ReiserFS (1.4 secs) and XFS (1.8) when compared to Ext3 and JFS (2.5 and 3.1). Similar results were observed during the file search, where ReiserFS (0.8 sec) and XFS (2.8) yielded quicker results compared to Ext3 (4.6 secs) and JFS (5 secs). Ext3 and JFS took comparable amounts of CPU for directory listing (35%) and file search (6%). XFS took more CPU for directory listing (70%) but comparable amount for file search (10%). ReiserFS appears to be the most CPU-intensive FS, with 71% for directory listing and 36% for file search. Again, the number of minor page faults was 3 times higher for ReiserFS (total = 1991) when compared to other FS (704 to 712).
Conclusion : Results suggest that, for these tasks, filesystems can be regrouped as (a) quick and more CPU-intensive (ReiserFS and XFS) or (b) slower but less CPU-intensive (ext3 and JFS). XFS appears as a good compromise, with relatively quick results, moderate usage of CPU and acceptable rate of page faults.

OVERALL CONCLUSION

These results replicate previous observations from Piszcz (2006) about reduced disk capacity of Ext3, longer mount time of ReiserFS and longer FS creation of Ext3. Moreover, like this report, both reviews have observed that JFS is the lowest CPU-usage FS. Finally, this report appeared to be the first to show the high page faults activity of ReiserFS on most usual file operations.

While recognizing the relative merits of each filesystem, only one filesystem can be install for each partition/disk. Based on all testing done for this benchmark essay, XFS appears to be the most appropriate filesystem to install on a file server for home or small-business needs :

    * It uses the maximum capacity of your server hard disk(s)
    * It is the quickest FS to create, mount and unmount
    * It is the quickest FS for operations on large files (>500MB)
    * This FS gets a good second place for operations on a large number of small to moderate-size files and directories
    * It constitutes a good CPU vs time compromise for large directory listing or file search
    * It is not the least CPU demanding FS but its use of system ressources is quite acceptable for older generation hardware

While Piszcz (2006) did not explicitly recommand XFS, he concludes that "Personally, I still choose XFS for filesystem performance and scalability". I can only support this conclusion.

References

Benoit, M. (2003). Linux File System Benchmarks.

Piszcz, J. (2006). Benchmarking Filesystems Part II. Linux Gazette, 122 (January 2006).

posted @ 2008-10-05 16:49 Jarod.cn.LuLuLife 阅读(342) | 评论 (0) | 编辑 收藏

Discuz论坛的OpenID革命？

OpenID对国内用户也许还是一个非常陌生的字眼，但是它在国外已经成熟应用了很多年了。就在不久前goolge、yahoo、微软、ibm纷纷都开始支持openid协议了。

openid到底是什么？openid将带来新的互联网革命吗？

OpenID解决了一个帐户登录不同网站的难题，用户不用再记住不同的帐户密码，只需要一个openid帐号就能随意登录openid支持的网站。
它本质上能够成为整个互联网的通行证。而与以前的通行证不同之处在于，它是一个不属于任何组织的。它不属于任何人，没人有能够垄断openid。当然能够优秀服务的提供商可能成为大家首选的注册点。但是在openid协议中，用户的openid使用绝对不会受制于任何一家openid帐号提供商。(更多资料能“google之”)
有理由相信，openid的推广将带来的不仅仅是革命了。

目前openidoor.com已经完成了Discuz论坛的OpenID登录插件开发。

OpenID在论坛使用意味着OpenID在中国国内的推广又有了新的进展。而这次全系列的支持(4.0--6.1)意味着大中型论坛都有可能应用。大型论坛跟国际接轨，进一步巩固自己的地位。而小论坛则使用用户登录更为友好，突然拥有了上千万、上亿的openid用户不得不说人人都将获得新的机会。因为人们能够更加随意地自由地登录你的论坛，体验你的论坛的特色服务。

目前已经更新到了1.2的版本，测试也在陆续进行中。有兴趣赶快去试试吧~~

discuz官网的论坛中的发布地址：

http://www.discuz.net/thread-994518-1-1.html

在他们自己的网站也能下载到：

http://www.openidoor.com/remository.html

另外作者还提供了一个演示地址，可以让大家体验一下openid的使用。
http://www.openidoor.com/discuz_6.0

更多资料可以goolge、百度关键字：“Openid”
或者参看他们的网站介绍
http://www.openidoor.com

posted @ 2008-07-23 15:51 Jarod.cn.LuLuLife 阅读(628) | 评论 (0) | 编辑 收藏

windows+PHP+apache+netbeans6.5安装配置xdebug~~~

下载相应版本：http://pecl4win.php.net/ext.php/php_xdebug.dll

放在某个目录下，例如下面的：
c:/xdebug/php_xdebug-2.0.2-5.2.5.dll

然后在php的配置文件php.ini的末尾加入下面两行
（注意斜杠的方向啦）
(如果开启了zend，要关掉之)

zend_extension_ts="c:/xdebug/php_xdebug-2.0.2-5.2.5.dll"
xdebug.remote_enable=1

posted @ 2008-07-21 18:49 Jarod.cn.LuLuLife 阅读(1290) | 评论 (2) | 编辑 收藏

对我来说OpenID是什么？（白菜flash，第二篇）

上次简单介绍了OpenID，估计很多人还是弄不明白，下面做了一个flash，依次演示了注册、使用。

以下flash来自：http://www.openidoor.com

注册中使用的是著名的OpenID提供商myopenid的网站。

后面的使用演示，一个是登陆网站、一个是在google的blog留言~~

posted @ 2008-07-10 08:53 Jarod.cn.LuLuLife 阅读(239) | 评论 (0) | 编辑 收藏

国内的OpenID推广、服务商。

• 热衷于搜集各个提供商和支持站点的链接，整理发布OpenID公共资源，推广OpenID。

• 测试提供商和支持站点的兼容性，帮助各站点实现严格的OpenID协议，保证用户在各站点顺利使用OpenID登录。

• 旨在向客户提供专业、成熟的OpenID升级、部署服务，使客户的站点支持OpenID登录，让客户站点更便捷，更吸引用户

posted @ 2008-07-08 20:56 Jarod.cn.LuLuLife 阅读(570) | 评论 (0) | 编辑 收藏

对我来说OpenID是什么?(小白篇)

对我来说OpenID是什么？

(本文假设这是你第一次看到”OpenID”这个“单词”)

    Google Blogger网站的注册用户数量在1000万到5000万之间，他们都是OpenID用户,他们都能使用OpenID功能。差不多同时，Yahoo也推出了OpenID的站点，并宣布在1月30日开始提供Yahoo的OpenID帐号服务。可以认为yahoo,google用户都拥有了OpenID帐户，他们可以随时使用！

OpenID是啥？能吃吗？

一句话，就是一个“用户名”而已啦。当然，还有一个对应的密码。这个“用户名”的最神奇之处在于，它不需要注册就能登陆所有支持使用OpenID登录的站点。简单的例子就是你可以使用在Yahoo注册的openid用户名登陆Goolge Blogger、flickr、Zoomr、Plaxo。

这样做有什么好处？

试想，你的照片放在flickr，你的日记写在Goolge Blogger，同时你还使用着Zoomr,Wikispaces，Plaxo的各种各样千奇百怪的服务。你需要记住多少个用户名和密码？要知道，很多网站你的用户名很可能已经被抢注了。（比如我的:Jarod，在这里无限同情一下John,Eric……）

有了OpenID则一切都不同了，我只需要记住OpenID这一个用户名，他的形式是一个网址的URl,例如我在www.myopenid.com注册的 :  jarod.myopenid.com，我可以用它登录上面提到的所有网站。Goolge,微软，yahoo都成为了提供商，你可以选择已经拥有的ID作为自己的OpenID了。

我在中国，我不了解国外那一大堆千奇百怪的网站，我还是不明白什么是OpenID？

在中国，设想一下腾讯如果支持openid了~~~

它意味着，你的QQ帐户可以登陆Mop,天涯，优酷，土豆，豆瓣，搜狐博客……

OpenID安全吗？

这个问题可以类比，银行卡安全吗？

不夸张地说，其实OpenID比银行卡更安全。当然这是需要一些进阶技巧和条件的啦。例如你得拥有一个个人网站。

我听说Google web side向所有人提供啦!

~~~请关注OpenID进阶篇~~~

posted @ 2008-05-31 02:16 Jarod.cn.LuLuLife 阅读(2247) | 评论 (1) | 编辑 收藏

六度理论，到达wiki的中心

据说“2007”这篇文章就是wiki的中心，以这篇文章为起点，平均只需要3.45次点击，就可以到达维基百科中其余的2111479篇文章。

互联网的中心在哪？

goolge？yahoo?
它们只是目录吧

posted @ 2008-05-29 11:44 Jarod.cn.LuLuLife 阅读(234) | 评论 (0) | 编辑 收藏

Eclipse里面方法提示的背景，前景设置！~

莫名其妙换了一个xp主题之后，居然看不清楚Eclipse里面按下"."之后选择的方法了。前景跟背景一个色。

弄了半天，极度郁闷地发现
windows- >preferences- >java- >editor- >completion proposal background 这个是背景的颜色

                                                                   completion proposal foreground 这个是文字（方法名）的颜色

posted @ 2008-05-28 17:36 Jarod.cn.LuLuLife 阅读(778) | 评论 (0) | 编辑 收藏

Unix-Center,快去体验NB的服务器unix环境，关键是免费的。

非常棒的一个“组织”，哈哈。
可以免费体验Unix-Linux环境，远程登陆之后就可以如同使用自己电脑一样。而且登陆手段极为方便，他们的说明写得也是非常通俗易懂、详尽之极，就算小小小小小白都能看得懂。
关键是，如此强大的环境下已经完全支持了Java环境（100M哇卡卡）。非常棒，非常棒。而且最近还加入了Mysql支持。
这样好的东西，当然要大家都知道哦。

posted @ 2008-05-10 15:05 Jarod.cn.LuLuLife 阅读(1177) | 评论 (1) | 编辑 收藏

java.lang.Math.Random()与java.util.Random生成随机数的区别

一个是方法一个是对象之类的废话就不说了。关键在与两个生成随机数的不同特征。
因为在做图像特征提取，对整个像素空间的逐个提取、识别显然不太聪明，于是乎想起概率论上的一堆东东。
取得一个可以反应整个向量空间的随机数集合，不失为明智的选择。

《Think in Java》里面经常用那个对象弄，自然我首先想到了这个。同学则喜欢Math.Random，他认为生成的是一个在区间均匀分布的符合要求的随机数。以前从来没想过“随机”这个问题，到底是一个任意的数（各个概率一样，就像古典概型里面，硬币的正反一样），还是一个在空间有均匀分布特征的呢？

在网上搜罗了一大堆东西，发现说什么的都有，越来越迷糊。最后想起该看看权威的JDK API说明乎：

random（注:java.lang.Math）
public static double random()
返回带正号的 double 值，该值大于等于 0.0 且小于 1.0。返回值是一个伪随机选择的数，在该范围内（近似）均匀分布。 
第一次调用该方法时，它将创建一个新的伪随机数生成器，与以下表达式完全相同 

new java.util.Random
之后，新的伪随机数生成器可用于此方法的所有调用，但不能用于其他地方。 
此方法是完全同步的，可允许多个线程使用而不出现错误。但是，如果许多线程需要以极高的速率生成伪随机数，那么这可能会减少每个线程对拥有自己伪随机数生成器的争用。 


返回： 
大于等于 0.0 且小于 1.0 的伪随机 double 值。 

下面是java.util里面的

java.util 
类 Random
java.lang.Object
  java.util.Random
所有已实现的接口： 
Serializable 
直接已知子类： 
SecureRandom 

--------------------------------------------------------------------------------

public class Randomextends Objectimplements Serializable此类的实例用于生成伪随机数流。此类使用 48 位的种子，使用线性同余公式 (linear congruential form) 对其进行了修改（请参阅 Donald Knuth 的The Art of Computer Programming, Volume 3，第 3.2.1 节）。 

如果用相同的种子创建两个 Random 实例，则对每个实例进行相同的方法调用序列，它们将生成并返回相同的数字序列。为了保证此属性的实现，为类 Random 指定了特定的算法。为了 Java 代码的完全可移植性，Java 实现必须让类 Random 使用此处所示的所有算法。但是允许 Random 类的子类使用其他算法，只要其符合所有方法的常规协定即可。 

Random 类实现的算法使用一个 protected 实用工具方法，每次调用它最多可提供 32 个伪随机生成的位。 

很多应用程序会发现 Math.random() 方法更易于使用。 

看看下面的就更加显而易见啦

next
protected int next(int bits)生成下一个伪随机数。当被所有其他方法使用时，子类应该重写此方法。 
next 的常规协定是，返回一个 int 值，如果参数 bits 位处于 1 和 32（包括）之间，那么返回值的多数低位都将（大致）是单独选择的位值，每个位值是 0 或 1 的机会（大致）相等。通过将种子自动更新为 

(seed * 0x5DEECE66DL + 0xBL) & ((1L << 48) - 1)并返回 
(int)(seed >>> (48 - bits))，Random 类可实现 next 方法。这是一个线性同余伪随机数生成器，由 D. H. Lehmer 定义，Donald E. Knuth 在 The Art of Computer Programming, Volume 3: Seminumerical Algorithms 的第 3.2.1 节中进行了描述。 

参数：
bits - 随机位。 
返回：
随机数生成器序列的下一个伪随机值。

于是我的结论如下：
1：java.lang.Math.Random()这个静态方法得到的是一个空间中有均匀分布特征的随机数。
2：java.util.Random，通过这个对象得到的则是“几何分布”
3：我的图像特征应该选择第一个方法比较适当。

问题：我的似乎应该说是一个抽样问题更为恰当。呼呼，先写到这里


啦啦啦，请高人指教。

posted @ 2008-05-01 17:15 Jarod.cn.LuLuLife 阅读(26707) | 评论 (3) | 编辑 收藏

终于可以运行了，发帖小庆祝一下。过段时间整理一下心得发出来。

posted @ 2008-05-01 04:54 Jarod.cn.LuLuLife 阅读(125) | 评论 (0) | 编辑 收藏

JSF路上，又是小树枝牵绊着我.

盯着屏幕10个小时了，还是举步维艰。

搜到几只Punk还有Rock的MP3,心情跟以前完全不一样了唉。
不过我的激荡还是属于这里的。

睡觉前发现两处好地方，明天继续加油。
(一个IBM，另一个sun的就不用说了)
https://javaserverfaces.dev.java.net/users.html
http://forum.java.sun.com/thread.jspa?threadID=703986&tstart=0
http://www-128.ibm.com/developerworks/library/j-jsf2/#resources

神哪，给我几个优秀的架构学习学习吧。国内几个例子，其中包括不少老厚老厚的清华出版社弄出来的，实在不敢恭维。
(音量调大大大大大,最好大到溢出)

posted @ 2008-04-27 23:08 Jarod.cn.LuLuLife 阅读(129) | 评论 (0) | 编辑 收藏

毕业设计,我的图像搜索引擎哦

终于完成了比较烂的图像内容识别部分。
本来定好了是用JSF开发的，唉哦，从来没用过的东西哦。没准备充分，现在又卡住了。

“冬眠”我的数据库实在是太方便了哦，哈哈哈哈哈哈哈。少写了无数行代码。

继续搜索文章中

posted @ 2008-04-27 16:05 Jarod.cn.LuLuLife 阅读(456) | 评论 (1) | 编辑 收藏

Sun 要完全开源了。非常想看看他的图形库技术啊。

posted @ 2008-04-24 23:58 Jarod.cn.LuLuLife 阅读(219) | 评论 (0) | 编辑 收藏

庆祝Blog开通了哦.

庆祝我的blog开始啦，终于弄好了封面。
是我白痴了，从来没弄过blog。

幸亏Blogjava的API(就是FaQ啦)，写得通俗易懂，而且还是中文的。

posted @ 2008-04-24 16:00 Jarod.cn.LuLuLife 阅读(95) | 评论 (0) | 编辑 收藏