很多人在說 LG G3 螢幕解析度很高很吃記憶體, 都只是隨便嘴巴講講沒什麼真實證據。
http://stackoverflow.com/questions/3154632/android-vram-check
如果照這裡的方法來看的話
root@g3:/ # dd if=/dev/graphics/fb0 of=/dev/null bs=4096
7200+0 records in
7200+0 records out
29491200 bytes transferred in 0.695 secs (42433381 bytes/sec)
>>> 29491200 / 1440./ 2560. /4.
2.0
看起來數字是對的。
29491200 bytes ~ 30M 笑了 是真的有差很多嗎？
Nexus 4 是11796480 bytes ~ 12M
另外 dmesg 裡面沒有看到VRAM相關訊息
2015年6月6日 星期六
2015年6月5日 星期五
找出所有Google Public DNS的主機
Google Public DNS 是用 Anycast 的方式提供服務的, 而且主機設定成不管什麼回應(DNS, icmp ...)都會顯示來源是 8.8.8.8 。
所以沒辦法知道真實主機是誰 hosting 的。
在看DNS DDoS 的時候發現 http://openresolverproject.org/ 他會去DNS Query internet 上的所有主機, 然後記錄下來, 如果你的主機是有對外提供服務的, 就有可能被利用來當DNS Amplification attack。
輸入 8.8.8.8 去查詢的話, 可以查到 33186 個 IP 會回應來源是 8.8.8.8, 8.8.4.4 的話是有 1766 個。
也有可能裡面有假的, 不過假的就要從 routing 去hacking 才有可能讓別人 query 到。
OpenDNS 208.67.222.222 1565台, 208.67.220.220 1320台。
Hinet 168.95.192.1 5台, 168.95.1.1 107台 (大吃一驚)
Seednet 139.175.1.1 沒有開放非 seednet 用戶 query
ns1.he.net 跟 ns1.afraid.org 拒絕recursive query。其實我比較好奇he.net 到底有哪些機器。
f.ns.buddyns.com 會 timed out 沒有回應, 不過他網站上面有寫主機位置, 應該沒有 anycast。
看來, 要 DDoS 攻擊的話 168.95.1.1 也許是個好選擇
所以沒辦法知道真實主機是誰 hosting 的。
在看DNS DDoS 的時候發現 http://openresolverproject.org/ 他會去DNS Query internet 上的所有主機, 然後記錄下來, 如果你的主機是有對外提供服務的, 就有可能被利用來當DNS Amplification attack。
輸入 8.8.8.8 去查詢的話, 可以查到 33186 個 IP 會回應來源是 8.8.8.8, 8.8.4.4 的話是有 1766 個。
也有可能裡面有假的, 不過假的就要從 routing 去hacking 才有可能讓別人 query 到。
OpenDNS 208.67.222.222 1565台, 208.67.220.220 1320台。
Hinet 168.95.192.1 5台, 168.95.1.1 107台 (大吃一驚)
Seednet 139.175.1.1 沒有開放非 seednet 用戶 query
ns1.he.net 跟 ns1.afraid.org 拒絕recursive query。其實我比較好奇he.net 到底有哪些機器。
f.ns.buddyns.com 會 timed out 沒有回應, 不過他網站上面有寫主機位置, 應該沒有 anycast。
看來, 要 DDoS 攻擊的話 168.95.1.1 也許是個好選擇
2010年10月19日 星期二
Get OpenBSD/NetBSD Latest Install ISO/sets via Rsync
The performance, maybe not a good way to get iso.
OpenBSD
One big install iso
install48.iso
240121856 100% 206.91kB/s 0:18:53 (xfer#1, to-check=0/1)
Number of files: 1
Number of files transferred: 1
Total file size: 240121856 bytes
Total transferred file size: 240121856 bytes
Literal data: 139474432 bytes
Matched data: 100647424 bytes
File list size: 47
File list generation time: 2.846 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 108569
Total bytes received: 139521735
sent 108569 bytes received 139521735 bytes 115159.01 bytes/sec
total size is 240121856 speedup is 1.72
NetBSD
boot iso and install sets
Number of files: 20
Number of files transferred: 5
Total file size: 223682054 bytes
Total transferred file size: 69074290 bytes
Literal data: 67497874 bytes
Matched data: 1576416 bytes
File list size: 730
File list generation time: 30.022 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 96373
Total bytes received: 67522725
sent 96373 bytes received 67522725 bytes 162741.51 bytes/sec
total size is 223682054 speedup is 3.31
The performance is not so good if you want to keep in sync often.
Possible reason see http://svana.org/kleptog/rgzip.html
http://samba.anu.edu.au/rsync/rsync-and-debian/rsync-and-debian.html
OpenBSD
One big install iso
| rsync -avz --progress rsync://ftp.estpak.ee/openbsd/snapshots/amd64/install48.iso . |
240121856 100% 206.91kB/s 0:18:53 (xfer#1, to-check=0/1)
Number of files: 1
Number of files transferred: 1
Total file size: 240121856 bytes
Total transferred file size: 240121856 bytes
Literal data: 139474432 bytes
Matched data: 100647424 bytes
File list size: 47
File list generation time: 2.846 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 108569
Total bytes received: 139521735
sent 108569 bytes received 139521735 bytes 115159.01 bytes/sec
total size is 240121856 speedup is 1.72
NetBSD
boot iso and install sets
| VER=`rsync rsync://nyftp.netbsd.org/NetBSD-daily/HEAD/|tail -n1|cut -d ‘:’ -f 3|cut -d ‘ ‘ -f 2` rsync -avz --progress rsync://nyftp.netbsd.org/NetBSD-daily/HEAD/$VER/amd64/binary/sets/ ./sets/ rsync -avz --progress rsync://nyftp.netbsd.org/NetBSD-daily/HEAD/$VER/amd64/installation/cdrom/boot.iso . |
Number of files transferred: 5
Total file size: 223682054 bytes
Total transferred file size: 69074290 bytes
Literal data: 67497874 bytes
Matched data: 1576416 bytes
File list size: 730
File list generation time: 30.022 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 96373
Total bytes received: 67522725
sent 96373 bytes received 67522725 bytes 162741.51 bytes/sec
total size is 223682054 speedup is 3.31
The performance is not so good if you want to keep in sync often.
Possible reason see http://svana.org/kleptog/rgzip.html
http://samba.anu.edu.au/rsync/rsync-and-debian/rsync-and-debian.html
2010年10月15日 星期五
Android ACTION_MEDIA_* events
Not working in 2.2 froyo if the activity is accessing sdcard.
http://code.google.com/p/android/issues/detail?id=11740
http://code.google.com/p/android/issues/detail?id=11679
Not working before 2.2 if registered statically.
http://code.google.com/p/android/issues/detail?id=7322
http://code.google.com/p/android/issues/detail?id=11740
http://code.google.com/p/android/issues/detail?id=11679
Not working before 2.2 if registered statically.
http://code.google.com/p/android/issues/detail?id=7322
2010年10月10日 星期日
Synology NFS Server
Synology CS407e
Samba is too slow, AFP does not reconnect after network error.
Using NFS, tcp or udp, while playing HD contents on the server, and try to access the nfs volume, it blocks for a while.
Solution, create more nfsd daemon.
/usr/syno/etc/rc.d/S83nfsd.sh
#To create 16 nfs servers
/usr/sbin/nfsd 16
To see server loading
/proc/net/rpc/nfsd
th 16 261 2.256 2.056 3.144 1.404 3.564 3.820 1.556 2.408 1.696 14.924
16 threads, used the last thread 261 times.
2.256 seconds uses 10% of the 16 threads
2.056 seconds uses 20% of the 16 threads
...
Samba is too slow, AFP does not reconnect after network error.
Using NFS, tcp or udp, while playing HD contents on the server, and try to access the nfs volume, it blocks for a while.
Solution, create more nfsd daemon.
/usr/syno/etc/rc.d/S83nfsd.sh
#To create 16 nfs servers
/usr/sbin/nfsd 16
To see server loading
/proc/net/rpc/nfsd
th 16 261 2.256 2.056 3.144 1.404 3.564 3.820 1.556 2.408 1.696 14.924
16 threads, used the last thread 261 times.
2.256 seconds uses 10% of the 16 threads
2.056 seconds uses 20% of the 16 threads
...
2010年10月8日 星期五
Yahoo 斷章取義 API
原文
哥哥安唷 我叫小樂 目前讀大二
民國78年次 身高165cm 47kg 34c
最近家里經濟不好 出來做兼職
希望好心ㄉ哥哥可以援助
見面滿意約 ,ㄅ滿意可以ㄅ約* 愛愛 伴游 聊天 逛街 鐘點情人
ㄞㄞ 3000 2h全套服務 現金交易 ㄅ轉賬刷卡
ㄞㄞㄉ時候要帶套套ㄛ 單純交易.各取所需
有需要ㄉ哥哥加我MSN: @hotmail.com
我ㄉ相簿http://www.wretch.cc/album/
可以在我相簿留電話給我, 我會第一時間聯絡妳ㄉ
期待哥哥約
關鍵字擷取
鐘點##人 203.61894582528
哥哥 124.68604562448
滿意 98.457096577591
聊天 96.000808858899
小樂 94.645411353588
兼職 87.775598642351
希望 86.83604180972
援助 86.090431693226
愛愛 81.748683909361
單純 72.878584750222
鐘點情人的情不知道為什麼變成##,其他都還蠻準的。
另外有一個問題是,如果整篇文章只是把上面關鍵字擷取出來的再傳回去,一樣會傳回這些關鍵字。
希望 185.71838296432
聊天 170.81425651791
小樂 169.63149462119
兼職 162.70161315737
援助 161.0193089944
滿意 148.33799007289
單純 147.81485462203
哥哥 124.63040966573
鐘點 118.08395440453
愛愛 81.748683909361
有些順序變了,但是沒有變的像是”愛愛”分數還是一樣,鐘點情人因為##不見了。
所以說,只要有這些零散的字,就算沒有意圖也一樣會被判斷是怪怪的文章。
再另外,yahoo會刪掉符號,☎之類的,應該是跟標點符號一起一開始被處理掉的,但是,如果在關鍵字裡面加入中文,例如援乂交。☎兼☎職這樣符號太多的也不會被抓出來,阿...就插入一堆電話就可以通過了。
需要python範例程式請留言。
sourceforge上面有java api可以用,提供中研院斷詞跟yahoo斷詞,但是沒有關鍵字這一項。
哥哥安唷 我叫小樂 目前讀大二
民國78年次 身高165cm 47kg 34c
最近家里經濟不好 出來做兼職
希望好心ㄉ哥哥可以援助
見面滿意約 ,ㄅ滿意可以ㄅ約* 愛愛 伴游 聊天 逛街 鐘點情人
ㄞㄞ 3000 2h全套服務 現金交易 ㄅ轉賬刷卡
ㄞㄞㄉ時候要帶套套ㄛ 單純交易.各取所需
有需要ㄉ哥哥加我MSN: @hotmail.com
我ㄉ相簿http://www.wretch.cc/album/
可以在我相簿留電話給我, 我會第一時間聯絡妳ㄉ
期待哥哥約
關鍵字擷取
鐘點##人 203.61894582528
哥哥 124.68604562448
滿意 98.457096577591
聊天 96.000808858899
小樂 94.645411353588
兼職 87.775598642351
希望 86.83604180972
援助 86.090431693226
愛愛 81.748683909361
單純 72.878584750222
鐘點情人的情不知道為什麼變成##,其他都還蠻準的。
另外有一個問題是,如果整篇文章只是把上面關鍵字擷取出來的再傳回去,一樣會傳回這些關鍵字。
希望 185.71838296432
聊天 170.81425651791
小樂 169.63149462119
兼職 162.70161315737
援助 161.0193089944
滿意 148.33799007289
單純 147.81485462203
哥哥 124.63040966573
鐘點 118.08395440453
愛愛 81.748683909361
有些順序變了,但是沒有變的像是”愛愛”分數還是一樣,鐘點情人因為##不見了。
所以說,只要有這些零散的字,就算沒有意圖也一樣會被判斷是怪怪的文章。
再另外,yahoo會刪掉符號,☎之類的,應該是跟標點符號一起一開始被處理掉的,但是,如果在關鍵字裡面加入中文,例如援乂交。☎兼☎職這樣符號太多的也不會被抓出來,阿...就插入一堆電話就可以通過了。
需要python範例程式請留言。
sourceforge上面有java api可以用,提供中研院斷詞跟yahoo斷詞,但是沒有關鍵字這一項。
2010年9月14日 星期二
NetBSD 新的防火牆NPF
http://mail-index.netbsd.org/netbsd-announce/2010/09/13/msg000110.html
The NetBSD Foundation is pleased to announce NPF, a new packet filter
by Mindaugas Rasiukevicius. NPF is designed for high performance on
multiprocessor machines, and for easy extensibility.
Highlights of NPF features include
* MP-safety and locklessness for scalable MP performance: no longer is
the packet filter the bottleneck in your multicore router
* Fast hash-table and red-black tree lookups
* Stateful packet filtering, Network Address Port Translation (NAPT),
and Application-Level Gateways (ALGs) for, e.g., traceroute
* The N-Code processor, a packet-inspection engine inspired by BPF:
the N-Code processor is programmed to match packets using generic,
RISC-like instructions and a few CISC-like instructions for common
patterns such as IPv4 addresses
* Familiar configuration syntax and utilities
* Modularity and extensibility: users extend NPF by loading a kernel
module. NPF provides developers with an extensions API. NPF rules
can embed a hook that invokes an extension
By the end of January, NPF should have all of the capabilities that
NetBSD users have come to expect by using the other filters in the
kernel:
* IPv4 reassembly support
* Bi-directional NAT and port forwarding (re-direction)
* FTP proxy support
* IP header flags cleansing
* ICMP packets and TCP RST packet blocking
* Save/restore state
* Packet logging, configurable using filter rules
Rasiukevicius will also write documentation and configuration examples.
Beyond that, NPF needs code for IPv6 support. Rasiukevicius agrees to
provide technical support to developers who will add IPv6 support to
NPF. An outline of the steps to IPv6 support will be forthcoming.
NPF is the third packet filter in NetBSD, after IP Filter and PF. NPF
is unique for using a bytecode interpreter in its packet-inspection
engine, and for answering the question, "What does a packet filter
designed from the bottom up for multiprocessor systems look like?"
NPF development is sponsored by the NetBSD Foundation.
The NetBSD Foundation is pleased to announce NPF, a new packet filter
by Mindaugas Rasiukevicius. NPF is designed for high performance on
multiprocessor machines, and for easy extensibility.
Highlights of NPF features include
* MP-safety and locklessness for scalable MP performance: no longer is
the packet filter the bottleneck in your multicore router
* Fast hash-table and red-black tree lookups
* Stateful packet filtering, Network Address Port Translation (NAPT),
and Application-Level Gateways (ALGs) for, e.g., traceroute
* The N-Code processor, a packet-inspection engine inspired by BPF:
the N-Code processor is programmed to match packets using generic,
RISC-like instructions and a few CISC-like instructions for common
patterns such as IPv4 addresses
* Familiar configuration syntax and utilities
* Modularity and extensibility: users extend NPF by loading a kernel
module. NPF provides developers with an extensions API. NPF rules
can embed a hook that invokes an extension
By the end of January, NPF should have all of the capabilities that
NetBSD users have come to expect by using the other filters in the
kernel:
* IPv4 reassembly support
* Bi-directional NAT and port forwarding (re-direction)
* FTP proxy support
* IP header flags cleansing
* ICMP packets and TCP RST packet blocking
* Save/restore state
* Packet logging, configurable using filter rules
Rasiukevicius will also write documentation and configuration examples.
Beyond that, NPF needs code for IPv6 support. Rasiukevicius agrees to
provide technical support to developers who will add IPv6 support to
NPF. An outline of the steps to IPv6 support will be forthcoming.
NPF is the third packet filter in NetBSD, after IP Filter and PF. NPF
is unique for using a bytecode interpreter in its packet-inspection
engine, and for answering the question, "What does a packet filter
designed from the bottom up for multiprocessor systems look like?"
NPF development is sponsored by the NetBSD Foundation.
訂閱：
文章 (Atom)