I came across this interesting problem of coming up with an algorithm that would compute, for each element of an array, the product of all other elements in that array, in linear time without using the division operator (or implementing a division algorithm.)

A solution is to traverse left to right computing the growing product, and then traverse right to left computing the growing product and multiplying it with the result from the previous traversal. I.e.,

Given,

P     Q    R    S

Compute,

1     P    PQ   PQR
x     x    x    x 
QRS   RS   S    1
-------------------
QRS   PRS  PQS  PQR  

Implemented in python,

def elProd( A ):
        result = []
        prod = 1

        # for i from 0 up to len(A) - 1
        for i in range( len( A ) ):
                result.append( prod )
                prod = prod * A[ i ]
        prod = 1
        
        # for i from len(A) - 1 down to 0
        for i in range( len( A ) - 1, -1, -1 ):
                result[ i ] = result[ i ] * prod
                prod = prod * A[ i ]

        return result

iv been searching the web for months tring to find a modified termsrv.dll in order to allow multiple concurrent remote desktop connections. after months of looking, i have found little parts of what we need to modify in XP along with replacing the original termsrv.dll file to make unlimited RDP work. i have put together an easy install pack to make patching for unimited RDP quick and simple.

i have personally tested this on a Windows XP Pro SP2 system with 5 RDP connections and they all work perfectly.

i have modified the original files to make this pack. although i do not know the authors of who created the termsrv.dll along with the other registry settings, i do give credit to them since they did the hard work. iv just bundled everything together to make this install quickly and work.

Download: Unlimited Remote Desktop Connections

if you have any questions or comments, feel free to post a comment and i should reply soon. Enjoy!

Oftentimes you have changes in your working copy that you'd like to preserve but not taint the trunk with it. Maybe you'd like to work on it later, or perhaps you'd just like to branch off features so that you don't interfere with a trunk moving to stable. The trouble is, you didn't decide beforehand that you have to create a branch. How do you solve this problem? Enter svn switch.

Here's how you do it:

svn copy url-to-trunk url-to-new-branch -m "Creating a new branch"
svn switch url-to-new-branch
svn commit -m "Commiting my changes to new branch."

You'd still be in the old working copy however, but one that points to the new svn url. That's confusing, so as soon as you commit your changes, rm -rf everything and check out your trunk and branches again.

I had reason to brush up on my C/C++ skills a bit and did something I've wanted to do for some time: implemented a nice encapsulated linked list. Read more for the source.

I just happened to watch a telecast on Discovery India on a topic called Speed with modern research and one of the ideas that predicted much result was Super Cavitation.

Supercavitation is the use of cavitation effects to create a large bubble of gas inside a liquid, allowing an object to travel at great speed through the liquid by being wholly enveloped by the bubble. The cavity (i.e., the bubble) reduces the drag on the object and precisely this makes supercavitation an attractive technology: drag is normally about 1,000 times greater in water than in air.
Read Full Article

The potential of this technology being relatively frictionless linear as well as radial motion in an environment of much high density and hence much high drag.

I have always dreamed of becoming an Inventor, have a lab of my own with all sorts of esoteric gadgets and all the time in the world to create whatever I want. At 46, Daniel Hillis is doing exactly that. An American inventor, he is living his dream - conjuring up whacky ideas and implementing them in his uber-cool lab. He is also an author, a scientist, and an engineer.

• W. Daniel Hillis at Wikipedia
• The Mind of an Inventor
• Applied Minds, Inc., Inside Applied Minds
• Clock of the Long Now at Wikipedia
• Babble - Privacy without walls.

Technology Research News (TRN) is featuring an article on the two schools of cryptography, based on the two basic methods of cryptography, namely, computational and probabilistic.

Two schools of cryptography (TRN How it works)

A paper by Hans Boehm demonstrates why vicarious multithreading, through library implementations (such as Pthreads), in languages like C and C++ can never be 100% correct.

• Threads Cannot be Implemented as a Library
• Lambda the Ultimate

I was reading though a threaded discussion over at Kerneltrap.org, under the post "Swap Pre-Fetching" and found this really neat explanation of how swapping relates to files and inodes. Especially enlightening as to how a file backed (mmap()) swapping system works if the underlying executable itself is upgraded when the executable is running.

Allow me to elaborate. UNIX filesystems have a concept of "inodes" that store the body of the file, its permissions and its ownership. The inodes get linked into directories via names--aka. directory entries. The same inode can be linked into the filesystem in multiple places. (Hence the concept of a "hard link.") The filesystem keeps track of how many links an inode has, and the kernel keeps track of how many processes have opened a given inode. This concept is important, and I will come back to it.

When an executable runs, the executable's file as well as the files for all the libraries it depends on get opened. The pages for these files get mmap()'d into the process' address space as file-backed virtual memory. The memory gets marked copy-on-write, so that any changes to the mmap()'d code result in a fault, and break the file backing. In any case, the file-backed portions are backed by the contents of the inodes themselves.

Under virtual memory pressure, the kernel will have to deallocate physical pages of memory from some processes in order to allocate them to others. There are two strategies available here: Write dirty pages to swap, and discard clean pages. Clean pages are pages which have either an explicit file backing (such as program executable pages), and pages that were previously swapped, brought back in, but still have an equivalent copy in the swap partition. (This is sometimes refered to as the "swap cache," though I don't know if that designation is accurate.)

So yes, under memory pressure, some pages of an executable might get discarded and will need to be brought in later from the original executable. The grandparent wonders how that works if a user upgrades a binary while the executable runs.

Recall that there's the separation between the file's contents (the inode) and the name given to it in the file system (hard link to the inode). File descriptors are bound to inodes, not directory entries. When you "rm" a file, you remove the link between the directory and the inode. When you replace a file, say with "cp," the existing inode gets unlinked and a new inode gets linked in its place. When you "mv" a file, it gets linked in its new location, and unlinked from its old location.

The filesystem code does not reclaim the space allocated to the inode until all references to the inode drop. This includes all filesystem links and open file descriptors. Thus, when you replace a program's executable while it executes, the currently running program continues to see the old executable, even if the inode doesn't have a visible link in the filesystem. The inode will remain allocated until all of its open file descriptors get closed. Then and only then will the filesystem reclaim the storage associated with the inode.

In fact, it is this property of UNIX derived filesystems that leads to all the orphaned inodes you find in "lost+found/" after a fsck if your system gets shut down abruptly. Any inodes that were open at the point of the crash, but which did not have a hard directory link end up here.

Xen is the new kid in the virtualization arena, receiving well deserved attention from the industry and the academia, with some really big players betting on it.

Xen is an open source virtual machine monitor, or hypervisor, developed by the University of Cambridge. It has a design goal of being able to run 100 full featured OS instances on a single typical computer. Xen provides secure isolation, resource control, quality of service guarantees, and live migration of virtual machines.

Linux Journal is featuring an introductory article on Xen and its design. A nice, moderately technical read: Introduction to the Xen Virtual Machine