Data Matters

I have write a simple tools for tracing python function calls. The tools prints out the stack of call while execute the function. Use it as bellow: Consider several functions defined as below(in test.py), we make stack_trace the docorator of test(): import stack_trace def foo(): pass def bar(): foo() return 0 def error(): 1/0 def recur(i): if i == 0: return recur(i-1) @stack_trace.stack_trace(with_return=True, with_exception=True, max_depth=3) def test(): bar() recur(5) error() test() The result of executing test(): test [call] in test.py line:18 bar [call] in test.py line:6 foo [call] in test.py line:3 foo [return] None in test.py line:4 bar [return] 0 in test.py line:8 recur [call] in test.py line:13 recur [call] in test.py line:13 recur [call] in test.py line:13 recur [return] None in test.py line:16 recur [return] Non

The default settings for setup a pptp vpn on a linux server may be working with windows client. I have found two main issue: 1) the DNS issue The windows client may not use the DNS on vpn server. Need to edit the registry table entry "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage\Bind", move the line \Device\NdisWanIp to the first line of the value. 2)  The ms-chap v2/mppe issue With the issue, you shall found some website is not accessible but tcp connection is OK(like google talk), or some of website are working well but some not. You need to disable the encryption both on client/server setting. For pptp server, you need comment "require-mschap-v2" and "require-mppe-128" in /etc/ppp/pptpd-options. The issue may actually be caused by inconsistent mtu between the windows and linux server. You may check your windows mtu by "netsh interface ipv4 show subinterfaces". Or you may add a line in /etc/ppp/ip-up before the s

I have bridge the network of virtualbox vm with my wireless card, and it may not working, some router found it ip or mac addresses conflict. And I found the following in virtualbox manual: Bridging to a wireless interface is done differently from bridging to a wired interface, because most wireless adapters do not support promiscuous mode. All traffic has to use the MAC address of the host's wireless adapter, and therefore VirtualBox needs to replace the source MAC address in the Ethernet header of an outgoing packet to make sure the reply will be sent to the host interface. When VirtualBox sees an incoming packet with a destination IP address that belongs to one of the virtual machine adapters it replaces the destination MAC address in the Ethernet header with the VM adapter's MAC address and passes it on. VirtualBox examines ARP and DHCP packets in order to learn the IP addresses of virtual machines. So I switch back to wired network card, everything goes well

Basho discontinues the Luwak support since Riak 1.1 . If you need a version of Riak 1.1 with Luwak to support your legacy services, you may follow this article to build a Riak 1.1.2 with Luwak support(using Ubuntu). Fisrt, get erlang R14B03, devscripts, debhelper, gcc installed. Second, you need to checkout a version 1.1.2 riak source code from github: git clone git://github.com/basho/riak.git git checkout riak-1.1.2 Third, you may follow the installation guide in  https://github.com/basho/luwak  . Modify rebar.config, in deps , add {luwak, ".*", {git, "git://github.com/basho/luwak"}} and rel/reltool.config, add luwak, skerl, ... {app, skerl, [{incl_cond, include}]}, {app, luwak, [{incl_cond, include}]}, and optionally rel/files/app.config, add {luwak, [{enabled, true}]} Then build the riak with make rel You shall get the Luwak supported Riak 1.1.2. If need to build a deb package. You need modify the rebar.config, rel/reltool.config and re

rsync has an option to set about the compression level --compress-level=NUM. The document of rsync doesn't say anything about how to choose NUM. I found something at this post ., which refers a comment from zlib.h: The compression level must be Z_DEFAULT_COMPRESSION, or between 0 and 9: 1 gives best speed, 9 gives best compression, 0 gives no compression at all (the input data is simply copied a block at a time). Z_DEFAULT_COMPRESSION requests a default compromise between speed and compression (currently equivalent to level 6).