2006-06-27

4cm Fan @HK$8

DC 12V 0.25A
Purchased on 2006.06.26

2006-06-20

Ping from Windows XP to x86 Wireless Router

The x86 Wireless Router
$ uname -a
Linux dunno 2.6.17-gentoo #1 Tue Jun 20 00:40:37 CST 2006 i686 mobile AMD Athlon(tm) XP-M 2800+ GNU/Linux
$ lspci
00:0b.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)
        Subsystem: D-Link System Inc D-Link AirPlus DWL-G520 Wireless PCI Adapter(rev.B)
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 168 (2500ns min, 7000ns max), Cache Line Size: 256 bytes
        Interrupt: pin A routed to IRQ 209
        Region 0: Memory at cffe0000 (32-bit, non-prefetchable) [size=64K]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=2 PME-
$ iwconfig
ath0      IEEE 802.11g  ESSID:"XXXXXXXX"
          Mode:Master  Frequency:2.437 GHz  Access Point: XX:XX:XX:XX:XX:XX
          Bit Rate:0 kb/s   Tx-Power:18 dBm   Sensitivity=0/3
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX [2]   Security mode:open
          Power Management:off
          Link Quality=49/94  Signal level=-46 dBm  Noise level=-95 dBm
          Rx invalid nwid:13  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0
Windows XP on IBM Thinkpad X31
$ ping 192.168.52.149 -c 20
PING 192.168.52.149 (192.168.52.149) 56(84) bytes of data.
64 bytes from 192.168.52.149: icmp_seq=1 ttl=128 time=2.45 ms
64 bytes from 192.168.52.149: icmp_seq=2 ttl=128 time=1.93 ms
64 bytes from 192.168.52.149: icmp_seq=3 ttl=128 time=127 ms
64 bytes from 192.168.52.149: icmp_seq=4 ttl=128 time=1.04 ms
64 bytes from 192.168.52.149: icmp_seq=5 ttl=128 time=26.2 ms
64 bytes from 192.168.52.149: icmp_seq=6 ttl=128 time=50.5 ms
64 bytes from 192.168.52.149: icmp_seq=7 ttl=128 time=75.0 ms
64 bytes from 192.168.52.149: icmp_seq=8 ttl=128 time=98.2 ms
64 bytes from 192.168.52.149: icmp_seq=9 ttl=128 time=20.1 ms
64 bytes from 192.168.52.149: icmp_seq=10 ttl=128 time=44.0 ms
64 bytes from 192.168.52.149: icmp_seq=11 ttl=128 time=68.4 ms
64 bytes from 192.168.52.149: icmp_seq=12 ttl=128 time=2.42 ms
64 bytes from 192.168.52.149: icmp_seq=13 ttl=128 time=1.01 ms
64 bytes from 192.168.52.149: icmp_seq=14 ttl=128 time=38.1 ms
64 bytes from 192.168.52.149: icmp_seq=15 ttl=128 time=63.5 ms
64 bytes from 192.168.52.149: icmp_seq=16 ttl=128 time=1.02 ms
64 bytes from 192.168.52.149: icmp_seq=17 ttl=128 time=1.01 ms
64 bytes from 192.168.52.149: icmp_seq=18 ttl=128 time=31.8 ms
64 bytes from 192.168.52.149: icmp_seq=19 ttl=128 time=56.1 ms
64 bytes from 192.168.52.149: icmp_seq=20 ttl=128 time=80.4 ms

--- 192.168.52.149 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19005ms
rtt min/avg/max/mdev = 1.013/39.568/127.513/36.517 ms

2006-06-12

Microsoft Shared Computer Toolkit for Windows XP

Introducing powerful new software tools for shared computers in schools, libraries, Internet cafes, and other public places. The Shared Computer Toolkit helps make it easy to set up, safeguard, and manage reliable shared computers running genuine Windows XP.
Microsoft

2006-05-19

[笑話轉貼] 放A片的資料夾該叫什麼好呢?

前天和同學們在咖啡館喝咖啡聊是非,討論到家中弟妹都資源共享,但是某些隱私性的資料該怎麼處理呢?

在唸中X大學碩士班的天才同學"小仁",推了推他的千度眼鏡很老沉的說 "A片就A片,假什麼?"

大家都不爽他的傲慢態度,便問"要不你怎麼不被發現電腦裡的A片?"

只見他拿出他半年前買的NB(筆記型電腦),開起電源,點取他的D 槽,裡面是論文報告夾、MUSIC夾、LETTER夾、DATA夾、哩哩扣扣一大堆資料夾。

靠!偽裝這招也太遜了吧?小仁一臉不屑的說"我有需要那種偽裝的地步嗎?"

看著他點了滑鼠兩下"趴"一聲:

一本道之XXXX、無碼之草X牛奶等,一大推A片檔名歷歷在目。
回頭再看他的資料夾,小仁放A片的資料夾名稱是取啥?

.....

....

...

..

.


“搖桿驅動程式”

當場把香草拿鐵噴到他的 14.1 吋螢幕上……。




後續-----

「搖桿驅動程式」再點進去還有兩個資料夾~~

一個叫「騎兵」~

一個叫「步兵」~

啥意思??




騎兵 = 有馬(碼)

步兵 = 無馬(碼)

2006-04-11

Dual Display with IBM Thinkpad X31 and external LCD

** Upgraded from Proview 15" to BenQ FP92W 19" widescreen
MergeFB:
Merged Framebuffer mode allows you to use 3D acceleration on both heads of a dualheaded Radeon card. This is accomplished by creating a single large framebuffer with two viewports (CRTCs) looking into it. The current Radeon dualhead code creates two separate screens with separate framebuffers. they can be combined into a single logical screen using xinerama or used separately as separate X servers (host:0.0 and host:0.1). Merged Framebuffer mode can only be used to create a single logical screen. This is because a single framebuffer is shared between the two CRTCs. This is also the reason that HW accelerated 3D works on both heads. (freedesktop wiki)

also:
MergedFB mode is a special kind of Xinerama mode; it practically works like Xinerama, ie the two heads form a large screen which is transparent for applications. But this mode goes beyond Xinerama by even faking one screen to the X server itself. This provides the main advantage, namely that it is faster than Xinerama.-- www.winischhofer.net

also:
MergeFB is an XFree86 driver feature for video cards that have multiple heads. It is similar to Xinerama in that it also creates one big virtual desktop out of multiple screens.

The difference is in the implementation: Xinerama creates multiple screens with multiple framebuffers and MergedFB, like the name says, creates one big framebuffer with multiple 'viewports'. The main advantage of this method, is that it supports hardware 3D acceleration on all heads and it's generally faster. This is similar to 'TwinView' used in the nVidia drivers and the 'Big Desktop' in the ATI drivers.

Currently, this isn't supported in the drivers that come with the latest stable XFree86 release. Only in the MGA drivers from Matrox[1] and the experimental open source drivers for the SiS[2] and ATI Radeon[3] cards.

Framebuffer:
A framebuffer is a block of memory that holds one frame (one whole display or picture) of pixel data.

In the Linux kernel, there is a framebuffer device available. This device provides a hardware independent API for graphics devices. Applications see a framebuffer and can manipulate it though this API. It is accessed through a special device, normally /dev/fb* (e.g. /dev/fb0). It behaves much like other memory devices in linux, in that you can also read and write it with normal tools. For example copying the framebuffer to a file (effectively making a raw screenshot) can be done with:

cat /dev/fb0 > somefile

The main application of this in the Linux kernel is allowing the Tux logo at boot and a high resolution text console (a "Framebuffer console" -- the module for this is called fbcon). It's also for use on platforms which don't support a standard text mode. Other applications can also use it to get graphics without X or some other library, this is especially interesting for embedded devices.

Some screenshots:

2006-02-09

IMS 6Mbps download speed is near 445K/s

$ wget http://ftp.cuhk.edu.hk/pub/windows/nero/oem/Lite-On/{Nero-6.6.0.13,NVE-3.1.0.7,NMP-1.4.0.29,InCD-4.3.14.1,InCD4Reader}.exe
--01:41:48--
http://ftp.cuhk.edu.hk/pub/windows/nero/oem/Lite-On/Nero-6.6.0.13.exe
          => `Nero-6.6.0.13.exe'
Resolving ftp.cuhk.edu.hk... 137.189.4.14
Connecting to ftp.cuhk.edu.hk|137.189.4.14|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 33,831,292 (32M) [application/octet-stream]

100%[============================================>] 33,831,292 
445.53K/s    ETA 00:00

--01:43:34--
http://ftp.cuhk.edu.hk/pub/windows/nero/oem/Lite-On/NVE-3.1.0.7.exe
          => `NVE-3.1.0.7.exe'
Reusing existing connection to ftp.cuhk.edu.hk:80.
HTTP request sent, awaiting response... 200 OK
Length: 37,263,436 (36M) [application/octet-stream]

100%[============================================>] 37,263,436 
444.56K/s    ETA 00:00

01:44:58 (433.73 KB/s) - `NVE-3.1.0.7.exe' saved [37263436/37263436]

--01:44:58--
http://ftp.cuhk.edu.hk/pub/windows/nero/oem/Lite-On/NMP-1.4.0.29.exe
          => `NMP-1.4.0.29.exe'
Reusing existing connection to ftp.cuhk.edu.hk:80.
HTTP request sent, awaiting response... 200 OK
Length: 8,179,212 (7.8M) [application/octet-stream]

100%[============================================>] 8,179,212  
445.93K/s    ETA 00:00

01:45:16 (441.43 KB/s) - `NMP-1.4.0.29.exe' saved [8179212/8179212]

--01:46:02--
http://ftp.cuhk.edu.hk/pub/windows/nero/oem/Lite-On/InCD-4.3.14.1.exe
          => `InCD-4.3.14.1.exe'
Reusing existing connection to ftp.cuhk.edu.hk:80.
HTTP request sent, awaiting response... 200 OK
Length: 9,972,045 (9.5M) [application/octet-stream]
100%[============================================>] 9,972,045  
445.37K/s    ETA 00:00

01:46:25 (439.16 KB/s) - `InCD-4.3.14.1.exe' saved [9972045/9972045]

--01:46:25--
http://ftp.cuhk.edu.hk/pub/windows/nero/oem/Lite-On/InCD4Reader.exe
          => `InCD4Reader.exe'
Reusing existing connection to ftp.cuhk.edu.hk:80.
HTTP request sent, awaiting response... 200 OK
Length: 3,149,140 (3.0M) [application/octet-stream]

100%[============================================>] 3,149,140  
441.26K/s    ETA 00:00

01:46:32 (440.36 KB/s) - `InCD4Reader.exe' saved [3149140/3149140]