Archive for October, 2008
Only bugfixes, no new feature, will be added to the standard from now on.
Good. It is almost certain it will be called C++ 2009.
As I see, many new features will bring great convenience to programming. But… C++ will appear far more complicated and difficult and perhaps unreasonable to a newbie. It’s already complicated enough now…
Ten years ago C9x became C99, and now C++0x is becoming C++09. But there will be one certain difference: No major compiler completely implements C99 even today; however, every actively developed C++ compiler seems to be planning to add C++09 support as immediately as possible.
Combine “wildcard” and “ifeq“. For example,
ifneq “$(wildcard Makefile.inc)” “”
GNU Make is powerful!
Denyhosts is a small tool that frequently checks SSH daemon logs for incoming requests and put suspective IPs into /etc/hosts.deny.
For some reason, denyhosts was not running in recent days in my machine. (It should be automatically started at boot time, but was not.) Today I restarted it, and 7 IPs were immediately banned. They are from all around the world: 1 from US, 1 from Germany, 1 from Turkey, 1 from Armenia, and the rest 3 from China (respectively Xiamen University, Tianjin Netcom, and Qingdao Guangdian).
I then checked /var/log/messages, and found 5236 attacks in the last 5 days.
Yes, hackers all around the world are doing all kinds of brute-force attacks. Last summer, I found someone was using my anonymous proxy at port 3128, which had been open for just a few hours, to send hundreds of spams.
I wanted to find out if remote X creates a lot of network flows, so I logged into a remote computer with “ssh -Y“, started xclock, and then typed tcpdump. Then screen began scrolling up crazily like this:
13:21:00.694367 IP xxx.xxx.xx.xx.45762 > 192.168.1.3.ssh: . ack 60640 win 2003 <nop,nop,timestamp 191668683 75287130>
13:21:00.694430 IP 192.168.1.3.ssh > xxx.xxx.xx.xx.45762: P 70416:70464(48) ack 113 win 501 <nop,nop,timestamp 191668683 75287200>
Was X sending/receiving lots of data even if it seems to be idling? It shouldn’t be so silly.. And… Finally I realized what a big mistake I had made… It was like putting a microphone against a loudspeaker…
Just successfully started FCITX and typed Chinese in OpenOffice remotely..
X11 forwarding should be first enabled both at the server and client ends.
At the server end, put “X11Forwarding yes” in /etc/ssh/sshd_config, restart SSH daemon and it should be able to forward X11 requests.
At the client end, connect with “ssh -X
The last line is not needed if “ssh -X” works. In some circumstances only “ssh -Y” does, then ForwardX11Trusted is necessary.
ps1. If network is slow, “-C” (compress) may help.
ps2. X must be running with “-nolisten” argument, which (I guess) is the default in most distributions.
In my Core 2 running 64-bit Linux, it insists on compiling one of the Fortran sources with “gfortran -march=athlon64 -mfpmath=sse -msse2 -m3dnow …”, regardless of the FFLAGS environment variable. (Other Fortran files honor FFLAGS, nevertheless…)
It does not matter much if you insist on use “-march=athlon64”, but “-m3dnow” is really a problem since Intel never ever supported 3DNow!
FCITX (Free Chinese Input Toy for X) was one of the two major Chinese input methods in Linux. Yuking mentioned in his recent post that he had just learned to use SVN. It was amazing he had created such a successful tool without using any version control system… (The source files contain approximately 30k lines)
The codes were criticized to be “amateur” – mainly based on his use of Chinese configuration files and Chinese comments (both in GBK, not UTF-8). These criticism directly caused Yuking to stop development last year. But I still have no idea why it is not reasonable to use Chinese character in a Chinese input method…
Gentoo today stabilized openoffice 3.0. I then emerged it in two systems. OpenOffice 3 now supports parallel building, so there should be a speedup compared with 2.4 in an multi-core system.
x86 laptop: debugging is completely disabled. About 5 GiB.
amd64 desktop: CFLAGS=”… -ggdb”; FEATURES=”splitdebug“. More than 11GiB!
I have been using Compiz Fusion and VirtualBox for a while. They were both working well except I could not switch VirtualBox to fullscreen or seamless mode. I did not change any setting either in Compiz Fusion or VirtualBox, but these two days all black pixels have become transparent. What’s the problem?… (If I shut down Compiz Fusion, VirtualBox displays coreectly.)
Here is a simple C function:
long foo (unsigned a, unsigned b)
Compile it with an x86-64-targeted GCC with proper optimizations enabled (-O2 for example), you get the following instructions (in AT&T-style assembly):
movq %rsi, %rax
mov %edi, %edi
salq $32, %rax
orq %rdi, %rax
Pay attention to the red line. Literally it means assigning the value of register edi to register edi. Five years ago, anybody would agree this instruction does nothing like nops. But in an x86-64 system, this is not the case.
In x86-64 assembly, any instruction with a 32-bit register as its destination zeroes the higher 32 bits of the corresponding 64-bit register at the same time. Consequently, the function of ‘mov %edi, %edi’ is zeroing bits 32 to 63 of register rdi while leaving the lower 32 bits (i.e., register edi) unchanged.
One may want to rewrite it with a more intuitive and instruction:
andq $0xffffffff, %rdi
But this does NOT assemble! Because $0x00000000ffffffff is not representable in signed 32-bit format, but 64-bit immediates are currently allowed only in mov instructions whose destination is a general-purpose register (such a mov is usually explicitly written as movabsq). So if one must use and, one need something like this:
movl $0xffffffff, %eaxandq %rax, %rdi
Remember the zeroing rule for operations on 32-bit registers, so ‘movl $0xffffffff, %eax’ is equivalent to ‘movabsq $0xffffffff, %rax’…
X86-64 assembly really is too ugly, at least in this sense…
 Gentle Introduction to x86-64 Assembly