Discipline

Mental discipline is much harder to adhere than physical discipline. However, it's the essential drive to a higher altitude in the cruise of life.

Setup isatap router on debian

The ifupdown package on Debian does not support isatap as a mode for v4tunnel. Therefore, one can not simply create a single entry in /etc/network/interfaces to make it work. Anyhow, following are the steps I took to set it up.

1. Install iproute and radvd
2. Add "net.ipv6.conf.all.forwarding=1" to /etc/sysctl.conf
3. Add /etc/radvd.conf containing:
   interface is0
   {
       AdvSendAdvert on;
       UnicastOnly on;
       AdvHomeAgentFlag off;
       prefix 2002:aaaa:bbbb:1::/64
       {
           AdvOnLink on;
           AdvAutonomous on;
           AdvRouterAddr off;
       };
   };
   (replace "2002:aaaa:bbbb:1" with the prefix of your ipv6 subnet)
4. Since I have my default address connected to a 6to4 tunnel on my eth0 already, I need to add an additional ip4 address to eth0. In /etc/network/interfaces I add the following post-up, and pre-down scripts to eth0:
   
   post-up ip tunnel add is0 mode isatap local 192.168.1.12 ttl 64
   post-up ip link set is0 up
   post-up ip addr add 2002:aaaa:bbbb:1::5efe:192.168.1.12/64 dev is0
   post-up ip addr add 192.168.1.12/32 dev eth0
   pre-down ip addr del 192.168.1.12/32 dev eth0
   pre-down ip link set is0 down
   pre-down ip tunnel del is0
   (again replace "2002:aaaa:bbbb:1")
5. Restart the computer or do the following:
   $ sysctl -p
   $ ifdown eth0
   $ ifup eth0
   $ invoke-rc.d radvd start
   

On the client side, I just installed isatapd, added

ISATAP_ROUTERS="192.168.1.12"

to /etc/default/isatapd, and restarted with "invoke-rc.d isatapd restart". Then, everything works!

Trap

Rudimentary are things that can get us stuck. If we can not have them scaled with ease, how are we going to navigate more intricate endeavor. Methodical is the approach...

Non-interactive ssh password auth

There are situations where only password authentication is allowed on a remote SSH server. And, it may be desirable to have non-interactive password entry even under interactive terminal sessions, e.g., running git, rsync, etc. through ssh. However, OpenSSH makes this difficult by requiring interactive keyboard entry whenever there is an associated tty to the process. While it is possible to bypass this with an expect script, the easiest solution is sshpass.

Tax for holding intellectual properties

There are a few parallelisms between intellectual properties and real estate properties: They last indefinitely. They exclude public access. They cost law enforcement.

However, real estate properties are localized and the effect of any single property on general public is limited. (There could be exceptions, for example, the property of the only water source within a large area of land.) However, intellectual properties are generally universal since new knowledge is build on old. The effect of their restriction can grow and propagate to all aspects of public lives. (Imagine patent on wheels, clocks, or electricity; Copyrights on all classical texts or musics; Or, trademarks on commonly used words.)

So, under a necessary condition that such an intellectual property is to be granted to a private holder, proper tax should be assessed to recover the cost to the public. This can include loss of free access, blockage of innovation, and cost of property right enforcement. It is easy to imagine the growth of such cost will generally speed up in time. Thus, the tax rate should increase with the time that such a right is held.

Alternatively, the creation of intellectual properties can be compensated and rewarded up front and their access should be made free to the public. The only difficulty is in determining the value of these properties. As naive this may sound, it has been practiced since the incipiency of science, where scientific knowledge gained is open to the public and scientists are rewarded by fame and status for the impact they made. Similar difficulty exists in judging the value of a research, but the current system based on consensus appears to be working.

Processing command-line arguments in C++

I just released arg as a standalone library under LGPL. It's a command-line parser for C++ programs. The aim is to keep the programming effort in adding command-line processing to C++ programs at a minimum. There are several considerations in this direction:

1. simple and intuitive syntax
2. requiring no redundancy
3. localized codes
4. extensibility
5. completeness

The simple example as given on the arg homepage,

#include <arg.hh>
#include <iostream>
int main(int argc, char ** argv)
{
        arg::Parser p;
        int n;
        p.add_opt('n').stow(n);
        p.parse(argc, argv);
        std::cout << n << '\n';
        return 0;
}

should be very close to the minimum as far as 1. goes.

Programming is for a programmer to describe what he wants the computer to do. Per point 2., he should not be asked to provide the same information multiple times. (Well, maybe except in situations where multiple confirmations are required: "Launch the missile. Please have the missile launched. Yes, I really want you to launch the missile! Launch the *&^%$ missile!!!"; Computer: "Aborted on Error: missile != *&^%$ missile".)

When working on an item, e.g., adding a new command-line option, the programmer won't be asked to go to multiple places in the codes if 3. is observed. While common and frequent usages should be supported and simplified in the library, new and novel applications will ask for 4. Finally, some rare, special, and/or tricky applications will demand 5. in the arsenal.

Push forward

As an organic matter, one requires constant exertion to maintain tension. The process ends when tension is out.