Tor is back - config tor bridge without vidalia

Tor used to be blocked by China's GFW, but now it is back! Here is how
to manually config tor to use bridge without the vidalia GUI, useful for
FreeBSD and GNU/Linux users, especially for those who live in China.

It has been so long a time, since August 2009, that I can not visit
blogger, youtube, twitter, vimeo, picasa, or anything else that is
contributed and enjoyed by other Internet users, even with Tor, which
greatly helped me before in using the Internet free and securely.

It's all because of GFW, on which I don't want to comment too much. What
I support is Chinese government to censor the Internet and to guide
masses, for I am a somewhat patriotic guy not interested in dog-eat-dog
politics, and CCP did change and improve the life standard of my family
in the last few decades.

However, would you PLEASE *distinct* those so-called anti-government
content from other normal information? Would you please give us some
restricted freedom under your great and wisdom control?

All I want and need is something interesting and new, like a funny cat
picture, a comedy video, or some latest news from my friends. Give me
access to these good things, and block/remove/delete/whatever the other
fucking damn FLG, CNN, or Tibeter. Who cares!?

Okay. Let's come to the config file for using tor with bridge.

FILES

/etc/tor/torrc

OPTIONS

Bridge IP:ORPort [fingerprint]

When set along with UseBridges, instructs Tor to use the relay at
"IP:ORPort" as a "bridge" relaying into the Tor network. If
"fingerprint" is provided (using the same format as for
DirServer), we will verify that the relay running at that
location has the right fingerprint. We also use fingerprint to
look up the bridge descriptor at the bridge authority, if it's
provided and if UpdateBridgesFromAuthority is set too.

UseBridges 0|1

When set, Tor will fetch descriptors for each bridge listed in
the "Bridge" config lines, and use these relays as both entry
guards and directory guards. (Default: 0)

UpdateBridgesFromAuthority 0|1

When set (along with UseBridges), Tor will try to fetch bridge
descriptors from the configured bridge authorities when
feasible. It will fall back to a direct request if the authority
responds with a 404. (Default: 0)

EXAMPLES

# This example is copied and pasted from a vidalia generated torrc.
# The IP and port of bridges have been modified. ^&^
# For real tor bridges, try Google.

Bridge 8.98.151.48:80
Bridge 81.59.250.53:43
Bridge 108.125.18.153:91
UpdateBridgesFromAuthority 1
UseBridges 1

You can also get these help from

$man tor

And, finally, once again, I'd like to say it is the government's right
and responsibility to censor and to guide masses. I support the
government's position and shall defeat the FLG, CNN, and Tibeter. I
support China!!

Google Wave and "Gmail is temporarily unable to access your Contacts"

At this time(Thu Sep 24 23:43:42 CST 2009), hundreds of thousands of
gmail users are experiencing the problem of "Gmail is temporarily unable
to access your Contacts. You may experience issues while this
persists". And, there are already many posts about this topic, saying
it's once again an outage, google's fault or mistake.

But to my view, it's obviously not an exception, but an necessary
procedure toward the extent of Google's recently most exciting and
powerful product: Google Wave! Goole Wave will be out of the sandbox,
and be extended to every now Gmail users within this week, that's the
real cause for this "temporarily unable" thing.

Why?

Did you notice that google contact has been working so well despite the
intentionally highlighted err notice on Gmail, which has been there for
over hours. Have you ever experienced such funny FAULT or OUTAGE that
google will allow to PERSIST for so long a time?

It's no exception, it's Google Wave's coming! Let's wait to see!!

----------------------------------------
All these words are just my personal assumption based on very few proof,
so it has nothing to do with Google Mail or Google Wave. All I want to
do is to make an prediction.

[drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0

This is about how to solve a frame buffer problem I encountered after
upgrading to the 2.6.28-15-generic kernel. Last week I enabled the frame buffer
in my grub menu.lst to use the very fast fbterm(a Chinese console
environment, better than zhcon), with the following options:

vga=791 video=vesafb:ywrap,mtrr:3

At that time, everything worked well, and I really enjoyed the many
features of fbterm: display ttf font, Chinese and any other double width
characters, as well as the scrollback history.

However, after I upgraded to the latest kernel 2.6.28.15-generic in
through Ubuntu's apt, I found the console couldn't work any
longer. After the GRUB menu, everything disappeared and nothing showed
until the very late stage, when X desktop stared. If I get out to
the console with Ctrl+Alt+F1, it is still blank, and I found the
following message in dmesg every time I tried to invoke the console:

[drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for
disabled pipe 0

A quick google gave no answer to my question, and a test of booting with
the previous 2.6.28-14 kernel didn't help either. So it's not a problem
with the upgrade, and there must be something wrong with my
configuration, but I am sure I didn't change any of the system files.

...

The resolution of this problem finally came when I was checking the vga
opinions, and thought of the vesafb module. Was it loaded?

lsmod | grep fb

told me the answer, and after I load vesafb with the command:

modprobe vesafb

MY CONSOLE IS BACK!

I think the kernel should load it automatically as the options given is
clear, but it didn't. No matter how, I add the it in /etc/modules, and
hope it will solve this problem.

--------------------
UPDATE:

Found the source of the problem, in

/etc/modprobe.d/blacklist-framebuffer.conf

to solve the problem, just comment out the line of vesafb.

--------------------
UPDATE2:

It's not the blacklist, change it won't help. it's the mtrr option,
it should be:

vga=791 video=vesafb:ywrap,mtrr:1

iptables forward local port 80 to 8080

This is about how to forward local port 80 to 8080, or any other port,
which is useful when you are runing some test server with no root
privilege, while the client can still connect to the standard www port.

iptables -t nat -A OUTPUT -d 127.0.0.1 -p tcp --dport 80 -j REDIRECT --to-port 8080

cmd create a .lnk(shortcut)

We don't use any extra command tool that you have to download somewhere
else and worry about its security, but the winxp built-in cscript(or
wscript, if you prefer) to excute a little Jscript creat-a-lnk.js(source
followed), and create your shortcut on the desktop(or anywhere you want
to), quick and safe!

--------------------create-a-lnk.js--------------------
Shell = new ActiveXObject("WScript.Shell");
DesktopPath = Shell.SpecialFolders("Desktop");
link = Shell.CreateShortcut(DesktopPath + "\\shortcut-name.lnk");
// If you want:
// link = Shell.CreateShortcut("D:\\path\\to\\your\\shortcut-name.lnk");
link.Description = "a lnk created from cmd";
link.HotKey = "CTRL+ALT+SHIFT+l";
//link.IconLocation = ".exe,1";
link.TargetPath = Shell.CurrentDirectory + "\\lnk-to-this.txt";
// If you want:
// link.TargetPath = "E:\\path\\to\\your\\target.exe";
link.WindowStyle = 3;
link.Save();
--------------------create-a-lnk.js--------------------

Personally, I feel this is much better than running some unkown
XcreateLnk.exe as you can see the source, learn the process, and
guarante the security of your system.

linux zip/unzip err encoding 压缩解压中文文件 乱码

在linux下压缩和解压(zip,unzip)时,如果文件名中含有中文,就会由于文件名编码
(encoding)不同而出现平台(GNU/linux与win)之间制作的压缩包不能互相兼容的问
题,就是所谓的乱码.这里说一种最简单的解觉方法(2009)

首先,出现这种情况时不需要紧张,因为这只是文件名称的混乱,文件本身的内容还是正常
的.

然后,来看解觉的方法^_^:
前提:您身处2005以后的时代~
安装了zip,unzip ->以ubuntu为例 (~$ sudo apt-get install zip unzip)

1.制作可以在win下打开的zip压缩包
# sorry.暂缺

2.解压在win下制作的zip压缩包
~$ unzip -O cp936 /path/to/file.zip

-O 参数指定原压缩包的编码方式.
简体中文(GBK/GB2312) 为 cp936
繁体中文(BIG5) 为 cp950

结束语.
遇到问题,先尝试 -h --help,然后man,再然后才轮到Google.

小记:因为要从压缩包里取一个文件名含中文的文件夹出来,记得以前在linux下做的
压缩包在win下会打不开,反过来win下压缩的也会解压成乱码,就试验了一下.果然,
跟以前一样还是行不通的,并没有因为时间过渡到了2009,版本升到了9.04就有所改
变.乱码依旧,直接google,结果除了台湾一个贴子看起来比较有趣外,英文的搜索没
有结果,中文搜索 linux 压缩 解压 乱码得到的全部都是关于rar,7z代替的方案,
再不然就是一篇转了无数次的更改zip源代码的沉旧文章.可是我原先的zip都做好
了,并切也(还)没有养成动辙就源代码编译的好习惯(尤其是在ubuntu下),所以就准
备reboot回我们的D版winxp...

就在^D退出Terminal的这当口,想到了-h, --help.

于是就有了本篇的故事.为什么ubuntu里面带的zip不是Info-ZIP的呢?那样也许就
可以在制做压缩包的时候也指定编码格式了.

# 台湾的站
http://mrtg2.tnc.edu.tw/xoops/html/modules/weblog/details.php?blog_id=181

google code svnsync Error setting property

When I tried to sync a local repository to google code project host, I
got the Error setting property.
yang@acer:~$ svnsync init https://yangs.googlecode.com/svn file:///home/yang/code.google/
yang@acer:~$ svnsync sync https://yangs.googlecode.com/svn
.......
Committed revision 7.
Copied properties for revision 7.
Transmitting file data ................
Committed revision 8.
svnsync: Error setting property 'log'
svnsync: At least one property change failed;
repository is unchanged
svn: Error setting property 'log'
Could not execute PROPPATCH
After somewhat hours of googling, I didn't find any direct solution for
my problem, although it did help me get an general understanding of
several keyword in the err log:
PROPPATCH is an http method used in WebDav, just like GET, POST, and
PUT.
property is some technology SVN used to store additonal
information about the files in a repository.
Okay, let's go back to my problem, and its solution. In fact, it's easy,
and all included in the svn help. I didn't realize this until I went
back to the svnbook after long time unsuccessful attempts to google the
solution.
The Err message tells you that something wrong happened while setting a
property 'log'. Exactly speaking, it's the 'log' property of revision 8,
as the err happened right after revision 7's commit job was done. So, to
solve the problem, you need to check and repair the 'log' property of
r8, with the folling command:
svn propedit --revprop svn:log file:///home/yang/code.google/ -r8
In my case, it's some unknown blank new lines at the end of the 'log'
property. After remove them, and the command svnsync went through
without any problem.
Hope this will help those who encounter the same/similar questions, and
the lesson I learned from this experience, again: read the manual~