C++0x draft finished

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.

Reference
[1] September 2008 ISO C++ Standards Meeting: The Draft Has Landed, and a New Convener

Determine the existence of a file in Makefile

Combine "wildcard" and "ifeq". For example,

ifneq "$(wildcard Makefile.inc)" ""
include Makefile.inc
endif

GNU Make is powerful!

Always start denyhosts with sshd

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.

tcpdump

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...

SSH with X

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 " or "ssh -Y " (if ssh -X fails..). Alternatively, SSH client can be configured to turn on X11 forwarding automatically. Put in /etc/ssh/ssh_config the following lines:

Host *
  ForwardX11 yes
  ForwardX11Trusted yes

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.

Scilab

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!

Yuking resumes FCITX development

Wonderful!

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...

Disk size needed to compile OpenOffice

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!

Too Smart Router

I got a router between the WAN port and my computer. It seems it is just so "smart" that it, in the name of security, is preventing me from working properly...

If I don't use the router, I can easily connect to my computer using SSH and the connection still is active after being idle for an hour, which should be normal when you log in remotely.

With the router, I told it to redirect incoming requests to port 22 to my desktop, which works actually. HOWEVER, the router not only kills connections that has been idle for just a few minutes, but also rejects further requests from the same IP for a long time! So I now have a bash script:

 #! /bin/bash
until read -t10; do
    date
done

Once I finish something in SSH, I run this script. It sends several bytes every ten seconds so that the router won't consider the connection idle... I'm wondering what better workaround I can use (other than disconnecting frequently...)? I'm almost sure the router can't be configured so that it allows a connection to be idle for a long time..

[Update Oct 26: A better solution may be sending null bytes periodically, like what PuTTY does. This is usually called "anti-idle".]

A similar problem happened when I was transferring files from my laptop to my desktop (both connected to LAN ports of the router) with SCP. I issued SCP commands about ten times in several minutes, and further connections were rejected too. Is it possible to be again the router's fault? (SSH daemon had no reason to do so, I think.)

Why VirtualBox window is transparent...

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.)

mov %edi, %edi

Here is a simple C function:

long foo (unsigned a, unsigned b)
{
    return ((long)b<<32)|a;
}

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):

foo:
        movq    %rsi, %rax
        mov     %edi, %edi
        salq    $32, %rax
        orq     %rdi, %rax
        ret

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, %eax

andq %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...

Reference
[1] Gentle Introduction to x86-64 Assembly

Shrink an LVM partition

Gentoo’s Documentation says it is easier to increase the size of an LVM partition than to shrink it, so they recommend starting with smaller partitions and then increase them as needed.

Of course they are not saying shrinking is impossible, but only less easy. The most important thing is the FS must be reduced BEFORE the volume, or the FS will get damaged.

Example: Shrink partiton /dev/vg/home with ext3 filesystem from 30G to 12G:
e2fsck /dev/vg/home (resize2fs requires a check before resizing)
resize2fs /dev/vg/home 10G (resize FS to 10G)
lvreduce -L12G /dev/vg/home (reduce partition)
resize2fs /dev/vg/home (extend FS to the whole partition)

Someone (I’m not sure who..) recommended doing two resizes like this claiming it is safer.

Another VMware problem

Forgot about this when writing the previous post..

I had an error like this when trying to start VMware Workstation in a Linux host:

*** attempt to put segment in horiz list twice
/opt/vmware/workstation/lib/bin/vmware: symbol lookup error: /usr/lib/libglade-2.0.so.0: undefined symbol: g_return_if_fail_warning

The workaround is to export an environment variable before running vmware:

export VMWARE_USE_SHIPPED_GTK='yes'

The GTK libraries in my system is binary incompatible with the ones used by the VMware team, so VMware must use the library files shipped with it instead of those in my system. Similar compatibility problems are not rare when it comes to a closed-source application that is dynamically linked against an open-source library...

Reference
[1] HOWTO: Install vmware workstation 6.0.3 build 80004 (March 14) on Sabayon x86-3.5 Loop2-r2
[2] VMWARE_USE_SHIPPED_GTK=force vmware

Arrow keys not working in VMware

Arrow keys (and also Ctrl, Win, etc.) don't work in VMware if running in KDE. This should be an upstream bug.

Workaround: Add this line to ~/.vmware/config (create it if necessary) and restart VMware:

xkeymap.nokeycodeMap = true

VMware will display a warning about keyboard layout. Simply ignore it.

Reference
http://www.ultimalinux.com/wiki/VMware#Function.2Farrow_keys.2C_etc._not_working

SEEK_* Problem with MPICH2

This is a frequently encountered error when writing MPI programs in C++.

/usr/include/mpicxx.h:26:2: error: #error "SEEK_SET is #defined but must not be for the C++ binding of MPI"
/usr/include/mpicxx.h:30:2: error: #error "SEEK_CUR is #defined but must not be for the C++ binding of MPI"
/usr/include/mpicxx.h:35:2: error: #error "SEEK_END is #defined but must not be for the C++ binding of MPI"

I remember (not very sure) it was MPICH2 that introduced this problem. It was not present in MPICH1.

This happens if <mpi.h> is inlcuded AFTER some system headers like <stdio.h> and <iostream>. The workaround is simple: always include <mpi.h> first in any C/C++ source that uses MPI APIs. (Another workaround is to pass -DMPICH_IGNORE_CXX_SEEK to mpicxx, but it seems this has other drawbacks. Do this only if you are unable to modify the sources.)

This certainly should be considered a bug of MPICH2: SEEK_SET, SEEK_CUR, and SEEK_END are constant symbols required by the ANSI C standard, but MPICH2 has global variables with exactly the same names. MPICH2 has not changed this, though they apparently have realized this problem for long. (Otherwise they could not have introduced MPICH_IGNORE_CXX_SEEK. Probably they have binary compatibility concerns?)

Jumbled Characters after Catting a Binary File

When this happens, simply press Ctrl-V Ctrl-O Ctrl-M. Or alternatively, type "reset" and Return (Enter).

A terminal interpretes 0x0e byte as "activates the G1 character set", and 0x0f as "activates the G0 character set". The characters we read are in the G0 set. So, if there is no byte 0x0f after the last 0x0e in a binary file, everything will be shown in the unreadable G1 set, including the next shell prompt.

How does Ctrl-V Ctrl-O Ctrl-M work?
Ctrl-V is an 'escape character' - the next keystroke will always be interpreted as a literal character; Ctrl-O is 0x0f; Ctrl-M is carriage return. So the shell gets the command "\x0f" and outputs the error message "bash: \x0f: command not found". The byte 0x0f in this message turns the active character back to the readable G0.

G1 character set is not often used these days. Konsole chooses not to implement it at all, so we never have this problem in Konsole.