Lazy Sunday: The Chronicles of Narnia Rap - Google Video

Very funny.

Just played Star Wars Risk today. Not bad, but I think I like Global Domination better.

Releasing send.pl and recv.pl soon.

Thinking about taking care of the website today.

The backup server is still really pissing me off.
Today, I will manually compile and run the very latest reiserfsck, which will hopefully find a problem (therfore meaning my suspicions were correct and more importantly that I found the problem, and may therefore fix it (either by using ext3, upgrading gentoo, or reinstalling)). Maybe I'll also see if the hashing tools are messed up, but I doubt it.


i'm productive

I learned perl. I wrote a client and server program in perl with an extremely lightwieght (fast but not especially secure or reliable). The protocol is very simple. It uses TCP/IP. It is simply data ended with an EOF. So what's the point? You can pipe anything into the client, and expect it to be piped out of the server (obviosly, you could just have them use keyboard & moniter, but then you'd just be sending messages to the other person; i suppose you could set up one of these in each direction and carry on a conversation. primitive IM!)
Anyway, what's the point? If I'm running tar or something like that, and I want to ultimately have the tarball on another computer, and the computer I'm running tar on doesn't have enough room for the file, I just pipe that info into the client, and then have the server running on the machine with the big hard drives and pipe its output to a file there. That's the main point of it, but it could also be used for sending files (but since you probably should be running in an SSH tunnel anyway, it would be much better to use scp).
The two biggest issues are data integrity and security. There are so far no known bugs that cause issues, but since this is over a network, there can always be a bit here or there messed up. Since it uses TCP, there probably won't be any lost data, but don't count on it. This is NOT AT ALL secure. DO NOT run the server on a port open to the public. DO NOT use the client to directly send any data that you wouldn't want others to see over a public network. While designed for use on a small LAN, it can be safely used over the Internet by using SSH tunnels. They MIGHT even solve the integrety issues (SSH might use checksums or something).
As for speed, the biggest changeable factors are the method, blocksize, and location of compression; the client blocksize; the server blocksize. Both the client and the server allow you to set blocksizes (in bytes). It will read that much and then write it all at once. The buffering features of perl are bypassed, because they seem to cause problems. It's probably best to have the client blocksize be a multiple of the payload size of a TCP packet (thereby getting the most out of every packet). If compression is being used on the client side, the blocksize should be a multiple of that. I'm not quite sure how one should pick the server blocksize, but I like to set it equal to the client's. Keep in mind that the memory usage of both the client and the server is more or less the blocksize (since it's effectively buffered). I think that if you have much memory to spare, you should probably use a big blocksize. It would make sense that bigger blocks use less CPU (since fewer loops, which include 1 read and 1 write).
Both programs take 3 arguments: host, port, and blocksize. The server takes a host so that it knows which to bind to, but if you want it binding to any IP, I think you can achieve that by modifying the script. STDIN on client and STDOUT on server are obvious. Vice-versa should not be used. STDERR contains the block counter (tells you how many FULL blocks have been sent/recieved so far (with small blocksizes, the one on the client&server should be very close, but with larger ones they might not be). Any errors thrown by the script or by perl itself should also go to STDERR. In most cases, it should die on any error. (although if you are running perl -w, which I have it as since it is alpha-quality, there will be other warnings thru STDERR that won't make it die).
I'll post these programs later under GPL.

My other big accomplishment is setting up a RAID 5 array using mdadm. Right now I have RieserFS 3.6.

Right now I am testing out both on the krisa compy. So far I have had one very strange data-integrity issue. I'm going to try partimaged. I'm really hoping it's just my stupid script's fault and not something else that someone else wrote that should work. Especially not the RAID.


insightful stuff

Little Red Book Draws Government Attention: "Once the
government is given power, it is human nature to abuse it. What I
don't understand is why people fall hook, line, and sinker, for the
same techniques throughout history over and over again.

1) Instill fear in the population somehow, by either orchestating or latching on to
a catastrophic event,
2) Tell the population that you will take care of it, blame enemies of the state,
3) Go to war, claim critics of the war are unpatriotic, out of touch, part of an 'elite'.

This is all classic power grab politics, and yet it happens again and again in

Why do people not learn from history? It is clear that those in power have a
vested interest in having a sheeple populace. A critical thinking, well informed
electorate, is the biggest enemy to would be dictators in a democratic society.

Start with the children. I guess fear really is the mind killer."

Slashdot | Little Red Book Draws Government Attention

Slashdot | Little Red Book Draws Government Attention



LXer: The RIAA - Hollywood - DRM - Linux Suicide Pact


Slashdot | BellSouth Wants to Rig the Internet: "Next up, well dressed men go door to door collecting their monthly 'protection money'. 'It sure would be tragic if your users started getting 1500ms ping times, wouldn't it mister dot com?'"
Slashdot | RIAA vs Linux and DVDs: "Or more likely- greed."
Slashdot | GMail Adds Virus Protection: "Google has rolled out virus protection for it's web based email service."

post of the month