Catalyst_9.12出来了，9.11也很久了，可DELL的就只给M92，还是几个月前的。
今天，实在郁闷了，调教之。
先G，发现“笔记本ATI显卡安装最新驱动及最新CCC的方法”，找到Mobility Modder.net，然后找软件官网，找到“DH Mobility Modder.net v1.2.0.0 Final”。
后来的就简单了，照说明做。
Win7下不用禁止UAC，我是直接把那程序以管理员身份运行了。然后处理9-12_vista64_win7_64_dd_ccc_wdm_enu和Catalyt_9.12_Hotfix_Win7_Vista_8.682.2RC1_Dec15。安装成功，连重启都不需要。
（我这装完后面那个，动态桌布就黑掉了，只好重启。可能是新装了HydraVision的关系。）
阅读全文…
ll -rt ./_log/*.o* |awk '{if($5==84){print $9}}' | perl -ne '/(GP.*Chr.*\.sh)/;print "$1\n";' | while read a; do find . -name "$a" ;done | while read ss; do qsub -l vf=280M -cwd $ss;done
……
原因嘛，有些计算节点默认的SHELL不是bash，如果没shell-bang就出错到STDOUT：
Warning: no access to tty (Bad file descriptor). Thus no job control in this shell.
也有可能是其他原因，反正就这了……
后记，这样还是不行。也不知道计算节点的配置到底是出啥问题了。
后后记：结果嘛，# -S /bin/bash
http://hi.baidu.com/wrxzzj/blog/item/59b303b10ca1045108230240.html
HP P2015 在CUPS上的配置
2008年05月09日 星期五 13:54
公司的打印机，全称是HP LaserJet P2015 Series PCL 5e，由于不是window共享的打印机，所以也不能用samba的那一套方法了。而是采用JetDirect的连接方式，JetDirect是一套网络打印机规范，端口为9100。首先下载cups-1.4 源码包，编译配置如下：
./configure –prefix=/usr –sysconfdir=/etc –enable-raw-printing –with-cups-user=root –with-cups-group=lp –localstatedir=/var
编译安装后，你就可以用cups来打印文件了。
注意：在安装CUPS之前，最好先把foomatic 一套包都安装上去。
然后，你在http://localhost:631的web 配置界面里，直接可以用Find Printer 让CUPS自己发现网络上P2015 打印机。先选择HP 打印机生产商，然后在产品里选择HP LaserJet 1320 series Postscript。因为HP P2015就是1320这个型号的，在它的产品列表里，你发现根本就没有P2150这个系列的。
阅读全文…
chownat, pronounced "chone nat", allows two peers behind
two separate NATs with NO port forwarding and NO DMZ setup
on their routers to directly communicate with each other.
There is NO middle man, NO proxy, NO 3rd party, and the
application runs as an unprivileged user on both ends.
More importantly, it opens up a tunnel between the two
machines so one peer can access a service, such as a web
server, on the other machine which is also behind a NAT.
The next big version update will be a true client/server model,
where the server does not need to know any client IP addresses to
allow them to connect. The client will only need to know the server.
Example of a client behind a NAT talking to a machine NOT behind a NAT:
Machine A -> NAT A -> net -> quake server
Machine A sends a UDP packet to quake server, opening a "session".
NAT A sees this and says:
"If any UDP packets come back soon with the same host and port info,
I'm routing it to machine A."
Quake server sends UDP packets back, hits NAT A, and NAT A seeing the right
hosts and ports, sends it to machine A. Machine A and quake server are now
able to communicate without any problem.
Now here is how chownat works. Goal is:
Machine A (ssh client) -> NAT A -> net -> NAT B -> Machine B (ssh server)
When you start up the chownat server on machine B, it slowly fires off
UDP packets to machine A. Of course, NAT A is not expecting these so it
drops every one of them. Machine B does not stop.
Once you begin the chownat client on machine A, it begins sending UDP
packets to machine B. Note: chownat defaults source and destination
ports to 2222. Any unprivileged user can set UDP source and dest ports.
Normally the UDP packets that machine A is sending to NAT B would get dropped.
However, since machine B is sending similar packets OUT, NAT B assumes
these are responses and lets them back in. Once machine B sees these packets,
it sends handshake packets back to machine A. These packets will not get
dropped by NAT A because of the same reason: NAT A sees packets going out, and
the packets coming back to the NAT look like responses to the ones going out.
Finally, both sides are fully communicating over UDP, allowing protocols that
run over TCP to tunnel through.
Note: There is a keep-alive process on the chownat server and client that
always keeps the UDP "session" active. The packets it sends have a 0 byte
payload and are only sent when the client is not sending data out. Otherwise,
the fastest it will possibly send the keep-alive packets is one packet every 5
seconds. If any other type of data is traveling through the tunnel, no
keep-alive packets will be transmitted.
The next big version update will be a true client/server model,
where the server does not need to know any client IP addresses to
allow them to connect. The client will only need to know the server.
I am not telling how it will work, just yet 
Two machines exist across the Internet.
Machine nat1 is behind a NAT.
Machine nat2 is behind another NAT.
Machine nat1 is running a web server on port 80,
however it cannot be accessed because it is behind a NAT.
Machine nat1 wants to let nat2 connect to its web server.
In this case, nat1 runs:
./chownat.pl -d -s 80 nat2.com
And nat2 runs:
./chownat.pl -d -c 8000 nat1.com
nat2 connects to http://localhost:8000 in their local browser
and will access the http server nat1 has running on port 80
Similar scenario with ssh:
ssh server side:
./chownat.pl -d -s 22 nat2.com
client side:
./chownat.pl -d -c 1234 nat1.com
ssh -p 1234 user@localhost
chownat-v008b
Hardware
The pixel pitch is just the distance from one pixel to the next. The math doesn’t work out quite right, which makes me think there’s some funny business going on:
Width = 0.264 mm/pixel * 1280 pixels == 337.92 mm / 25.4 mm/inch == 13.30394 inches
Height = 0.264 mm/pixels * 1024 pixels == 270.336 mm / 25.4 mm/inch == 10.643 inches
Diagonal = SQRT(13.3^2 + 10.6^2) == 17.03735 inches.
Maybe the math is off because the pixels aren’t perfectly square.Then again, the manufacturer’s website says they’re square (http://www.minmaw.com/lcd%20-%20FP988D.htm). For other 19-inch monitors, the pitch is 0.294 mm/pixels, and the math works out almost perfectly:
Width = 0.294 mm/pixel * 1280 pixels == 376.32mm / 25.4mm/inch == 14.81575 inches
Height = 0.294 mm/pixels * 1024 pixels == 301.056 / 25.4 mm/inch == 11.8526 inche
Diagonal = SQRT(14.815^2 + 11.8526^2) == 18.97342 inches, which is a gnat’s hair less than nineteen inches.
There’s some funny business going on with that Min Wa monitor.
http://www.raydreams.com/prog/dpi.aspx
DPI 86.3
Pixels 1,310,720
Dimensions 14.8 x 11.9 inches
Dimensions 376.7 x 301.4 mm
Aspect Ratio 1.25
Linux各种文件系统(ext3,ReiserFS,jfs,xfs)的性能
http://hi.baidu.com/xuzhi1977/blog/item/c5869758dfafbade9d82040a.html
2006-07-28 08:55
以下文章是我自己翻译的，后面有英文的原文。不当之处，敬请指教.
应该不是太新的文章，但是我我是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).
Comment on this article
http://www.matrix67.com/blog/archives/276
好像目前还没有这方面题目的总结。这几天连续看到四个问这类题目的人，今天在这里简单写一下。这里我们不介绍其它有关矩阵的知识，只介绍矩阵乘法和相关性质。
不要以为数学中的矩阵也是黑色屏幕上不断变化的绿色字符。在数学中，一个矩阵说穿了就是一个二维数组。一个n行m列的矩阵可以乘以一个m行p列的矩阵，得到的结果是一个n行p列的矩阵，其中的第i行第j列位置上的数等于前一个矩阵第i行上的m个数与后一个矩阵第j列上的m个数对应相乘后所有m个乘积的和。比如，下面的算式表示一个2行2列的矩阵乘以2行3列的矩阵，其结果是一个2行3列的矩阵。其中，结果的那个4等于2*2+0*1：
下面的算式则是一个1 x 3的矩阵乘以3 x 2的矩阵，得到一个1 x 2的矩阵：
矩阵乘法的两个重要性质：一，矩阵乘法不满足交换律；二，矩阵乘法满足结合律。为什么矩阵乘法不满足交换律呢？废话，交换过来后两个矩阵有可能根本不能相乘。为什么它又满足结合律呢？仔细想想你会发现这也是废话。假设你有三个矩阵A、B、C，那么(AB)C和A(BC)的结果的第i行第j列上的数都等于所有A(ik)*B(kl)*C(lj)的和（枚举所有的k和l）。
经典题目1 给定n个点，m个操作，构造O(m+n)的算法输出m个操作后各点的位置。操作有平移、缩放、翻转和旋转
这里的操作是对所有点同时进行的。其中翻转是以坐标轴为对称轴进行翻转（两种情况），旋转则以原点为中心。如果对每个点分别进行模拟，那么m个操作总共耗时O(mn)。利用矩阵乘法可以在O(m)的时间里把所有操作合并为一个矩阵，然后每个点与该矩阵相乘即可直接得出最终该点的位置，总共耗时O(m+n)。假设初始时某个点的坐标为x和y，下面5个矩阵可以分别对其进行平移、旋转、翻转和旋转操作。预先把所有m个操作所对应的矩阵全部乘起来，再乘以(x,y,1)，即可一步得出最终点的位置。
经典题目2 给定矩阵A，请快速计算出A^n（n个A相乘）的结果，输出的每个数都mod p。
由于矩阵乘法具有结合律，因此A^4 = A * A * A * A = (A*A) * (A*A) = A^2 * A^2。我们可以得到这样的结论：当n为偶数时，A^n = A^(n/2) * A^(n/2)；当n为奇数时，A^n = A^(n/2) * A^(n/2) * A （其中n/2取整）。这就告诉我们，计算A^n也可以使用二分快速求幂的方法。例如，为了算出A^25的值，我们只需要递归地计算出A^12、A^6、A^3的值即可。根据这里的一些结果，我们可以在计算过程中不断取模，避免高精度运算。
经典题目3 POJ3233 (感谢rmq)
题目大意：给定矩阵A，求A + A^2 + A^3 + … + A^k的结果（两个矩阵相加就是对应位置分别相加）。输出的数据mod m。k<=10^9。
这道题两次二分，相当经典。首先我们知道，A^i可以二分求出。然后我们需要对整个题目的数据规模k进行二分。比如，当k=6时，有：
A + A^2 + A^3 + A^4 + A^5 + A^6 =(A + A^2 + A^3) + A^3*(A + A^2 + A^3)
应用这个式子后，规模k减小了一半。我们二分求出A^3后再递归地计算A + A^2 + A^3，即可得到原问题的答案。
经典题目4 VOJ1049
题目大意：顺次给出m个置换，反复使用这m个置换对初始序列进行操作，问k次置换后的序列。m<=10, k<2^31。
首先将这m个置换“合并”起来（算出这m个置换的乘积），然后接下来我们需要执行这个置换k/m次（取整，若有余数则剩下几步模拟即可）。注意任意一个置换都可以表示成矩阵的形式。例如，将1 2 3 4置换为3 1 2 4，相当于下面的矩阵乘法：
置换k/m次就相当于在前面乘以k/m个这样的矩阵。我们可以二分计算出该矩阵的k/m次方，再乘以初始序列即可。做出来了别忙着高兴，得意之时就是你灭亡之日，别忘了最后可能还有几个置换需要模拟。
经典题目5 《算法艺术与信息学竞赛》207页（2.1代数方法和模型，[例题5]细菌，版次不同可能页码有偏差）
大家自己去看看吧，书上讲得很详细。解题方法和上一题类似，都是用矩阵来表示操作，然后二分求最终状态。
经典题目6 给定n和p，求第n个Fibonacci数mod p的值，n不超过2^31
根据前面的一些思路，现在我们需要构造一个2 x 2的矩阵，使得它乘以(a,b)得到的结果是(b,a+b)。每多乘一次这个矩阵，这两个数就会多迭代一次。那么，我们把这个2 x 2的矩阵自乘n次，再乘以(0,1)就可以得到第n个Fibonacci数了。不用多想，这个2 x 2的矩阵很容易构造出来：
经典题目7 VOJ1067
我们可以用上面的方法二分求出任何一个线性递推式的第n项，其对应矩阵的构造方法为：在右上角的(n-1)*(n-1)的小矩阵中的主对角线上填1，矩阵第n行填对应的系数，其它地方都填0。例如，我们可以用下面的矩阵乘法来二分计算f(n) = 4f(n-1) – 3f(n-2) + 2f(n-4)的第k项：
利用矩阵乘法求解线性递推关系的题目我能编出一卡车来。这里给出的例题是系数全为1的情况。
经典题目8 给定一个有向图，问从A点恰好走k步（允许重复经过边）到达B点的方案数mod p的值
把给定的图转为邻接矩阵，即A(i,j)=1当且仅当存在一条边i->j。令C=A*A，那么C(i,j)=ΣA(i,k)*A(k,j)，实际上就等于从点i到点j恰好经过2条边的路径数（枚举k为中转点）。类似地，C*A的第i行第j列就表示从i到j经过3条边的路径数。同理，如果要求经过k步的路径数，我们只需要二分求出A^k即可。
经典题目9 用1 x 2的多米诺骨牌填满M x N的矩形有多少种方案，M<=5，N<2^31，输出答案mod p的结果
我们以M=3为例进行讲解。假设我们把这个矩形横着放在电脑屏幕上，从右往左一列一列地进行填充。其中前n-2列已经填满了，第n-1列参差不齐。现在我们要做的事情是把第n-1列也填满，将状态转移到第n列上去。由于第n-1列的状态不一样（有8种不同的状态），因此我们需要分情况进行讨论。在图中，我把转移前8种不同的状态放在左边，转移后8种不同的状态放在右边，左边的某种状态可以转移到右边的某种状态就在它们之间连一根线。注意为了保证方案不重复，状态转移时我们不允许在第n-1列竖着放一个多米诺骨牌（例如左边第2种状态不能转移到右边第4种状态），否则这将与另一种转移前的状态重复。把这8种状态的转移关系画成一个有向图，那么问题就变成了这样：从状态111出发，恰好经过n步回到这个状态有多少种方案。比如，n=2时有3种方案，111->011->111、111->110->111和111->000->111，这与用多米诺骨牌覆盖3×2矩形的方案一一对应。这样这个题目就转化为了我们前面的例题8。
后面我写了一份此题的源代码。你可以再次看到位运算的相关应用。
经典题目10 POJ2778
题目大意是，检测所有可能的n位DNA串有多少个DNA串中不含有指定的病毒片段。合法的DNA只能由ACTG四个字符构成。题目将给出10个以内的病毒片段，每个片段长度不超过10。数据规模n<=2 000 000 000。
下面的讲解中我们以ATC,AAA,GGC,CT这四个病毒片段为例，说明怎样像上面的题一样通过构图将问题转化为例题8。我们找出所有病毒片段的前缀，把n位DNA分为以下7类：以AT结尾、以AA结尾、以GG结尾、以?A结尾、以?G结尾、以?C结尾和以??结尾。其中问号表示“其它情况”，它可以是任一字母，只要这个字母不会让它所在的串成为某个病毒的前缀。显然，这些分类是全集的一个划分（交集为空，并集为全集）。现在，假如我们已经知道了长度为n-1的各类DNA中符合要求的DNA个数，我们需要求出长度为n时各类DNA的个数。我们可以根据各类型间的转移构造一个边上带权的有向图。例如，从AT不能转移到AA，从AT转移到??有4种方法（后面加任一字母），从?A转移到AA有1种方案（后面加个A），从?A转移到??有2种方案（后面加G或C），从GG到??有2种方案（后面加C将构成病毒片段，不合法，只能加A和T）等等。这个图的构造过程类似于用有限状态自动机做串匹配。然后，我们就把这个图转化成矩阵，让这个矩阵自乘n次即可。最后输出的是从??状态到所有其它状态的路径数总和。
题目中的数据规模保证前缀数不超过100，一次矩阵乘法是三方的，一共要乘log(n)次。因此这题总的复杂度是100^3 * log(n)，AC了。
最后给出第9题的代码供大家参考（今天写的，熟悉了一下C++的类和运算符重载）。为了避免大家看代码看着看着就忘了，我把这句话放在前面来说：
Matrix67原创，转贴请注明出处。
#include <cstdio> #define SIZE (1<<m) #define MAX_SIZE 32 using namespace std; class CMatrix { public: long element[MAX_SIZE][MAX_SIZE]; void setSize(int); void setModulo(int); CMatrix operator* (CMatrix); CMatrix power(int); private: int size; long modulo; }; void CMatrix::setSize(int a) { for (int i=0; i<a; i++) for (int j=0; j<a; j++) element[i][j]=0; size = a; } void CMatrix::setModulo(int a) { modulo = a; } CMatrix CMatrix::operator* (CMatrix param) { CMatrix product; product.setSize(size); product.setModulo(modulo); for (int i=0; i<size; i++) for (int j=0; j<size; j++) for (int k=0; k<size; k++) { product.element[i][j]+=element[i][k]*param.element[k][j]; product.element[i][j]%=modulo; } return product; } CMatrix CMatrix::power(int exp) { CMatrix tmp = (*this) * (*this); if (exp==1) return *this; else if (exp & 1) return tmp.power(exp/2) * (*this); else return tmp.power(exp/2); } int main() { const int validSet[]={0,3,6,12,15,24,27,30}; long n, m, p; CMatrix unit; scanf("%d%d%d", &n, &m, &p); unit.setSize(SIZE); for(int i=0; i<SIZE; i++) for(int j=0; j<SIZE; j++) if( ((~i)&j) == ((~i)&(SIZE-1)) ) { bool isValid=false; for (int k=0; k<8; k++)isValid=isValid||(i&j)==validSet[k]; unit.element[i][j]=isValid; } unit.setModulo(p); printf("%d", unit.power(n).element[SIZE-1][SIZE-1] ); return 0; }
http://stat3.blog.sohu.com/81746595.html
GLIDE-蛋白质的预处理(protein preparation)
1.Maestro鼠标基本操作
右键拖放–平动分子
按住滑轮拖放–旋转分子
左键–选择键
右键+滑轮拖放–分子视图放大与缩小
2.一步一步对要对接的蛋白进行处理
1). 输入一个蛋白/配体分子复合物的结构，一般是PDB格式的。这一步需要的是一个蛋白/配体分子的复合物（DOCK6.1中也需要一个参考小分子的）。
2). 保留一些必要的水分子，去掉一些不必要的水分子。一般情况下是把所有的水分子都给去掉的，但是有些水分子对配体与受体蛋白之间的连接有一个桥梁作用，还是要留下来的，这些保留下来的水分子能正确定向也是很重要的。蛋白预处理的过程中，氧原子会自动给加上氢的。
3). 对多聚复合体的简化。如果这个蛋白/配体复合物是二聚体或者多聚体，一般会有一些重复的结合活性位点，当然还有多余的重复蛋白链也是多余的。所以对这些重复的以及多余的要删掉。
4).调整蛋白，金属离子，辅因子。对于蛋白最常见的错误就是残基不完整，要是这些错误出现在离活性位点较远的地方，一般影响不大。要是出现在活性位点附近，还是要修正一下的。对于金属和蛋白之间的键一般要去掉的，并加上有效电荷。如果有需要要将辅因子的键级和有效电荷加以调整。
5). 如果有俩配体存在俩活性区域，那么这俩配体的键级都要进行修正。
6). 运行蛋白的预处理。打开”Protein Preparation”面板，鼠标选取配体，选择合适的设置，点击”Start”. “Protein Preparation Start”对话框打开。在”Name”文本框里敲入一个文件名(自己设置)。
7). 重新检查处理的结果。
由于D版的Surflex出现问题，所以无法体验比较可惜，只好用一下GLIDE，不过感觉挺好的，速度很快。
Program | Number of results
| High- Medium- Inaccurate
| accuracy accuracy
—————————————
Glide | 39 24 5
GOLD | 47 13 8
LigandFit| 24 35 10
FlexX | 26 18 25
DOCK | 4 19 45
Maestro7.5的安装：
Install the suite, for example in /home/username/schrodinger
(so for the rest of the instructions,
Copy ‘license’, ‘flexlmstart.sh’ and ‘flexlmstop.sh’ to
Copy ‘SHROD’ to
Edit your startup shell script (here for example it’s .cshrc) and add the following environment variables (the format might be different depending on the shell; .bashrc, .cshrc, .login, .shrc, .tcshrc, .zshrc, etc.):
setenv SCHRODINGER
set path = ($path
Close/Restart the shell, or source .cshrc
Verify that the variables are properly set by typing the following commands:
echo $SCHRODINGER
echo $path
Run flexlmstart.sh
Start the main application with: maestro
Note: maestro will not run if it’s launched from
Enjoy!
P.S. We included flexlmstart.sh to simplify the FLEXlm License Server startup. You only need to run it once after a computer reboot.
Run flexlmstop.sh if you wish to shutdown the server.
To run the license server manually, type: licadmin SERVERUP
To shutdown the license server manually, type: licadmin SERVERDOWN -q -vendor SCHROD
安装及使用方法：
1.将下载好的[医药软件].TLF-SOFT-Schrodinger.Suite.2007.iso.TBE.bin文件载入虚拟光驱。如无法载入虚拟光驱，建议使用UltralISO将其转换成iso格式文件，再载入虚拟光驱。把schroedinger-suite 2007安装到任意盘的根目录下
2.将软件包中crack目录下的license_server.dat 复制到软件安装目录下的\mmshare-v16109\bin\WIN32-x86\下，再在该目录下将license_server.dat复制一份命名为license.dat，然后在该目录下新建文件cmd.txt，输入cmd.exe /k lmgrd -z -c license.dat后保存文件，把文件名改为cmd.bat，发送快捷方式到桌面上
3.打开控制面板的系统项，在高级选项卡里点开环境变量，新建系统变量SCHROD_LICENSE_FILE值为@localhost
4.复制软件包中crack目录下的schroedinger_2007_patcher.exe到软件的安装目录并执行
安装过程完成，运行时先双击执行发送到桌面上的cmd.bat（可改成其它名称）不要关闭它，然后运行桌面上的Maestro-v8.0，OK!
有问题欢迎联系
以上是2007版在windows下的安装，在这种情况下装Xfree86， 原来机子里必须是没有装过cygwin的，否则xfree可能会出现问题！！！
13 | Unique Visitors |
MoeFan (萌番)
最近评论