Older blog entries for async (starting at number 30)

Stuff to explore and Things you should know:

(Pseudo-)Random number generators are an art unto themselves; see Knuth's _The Art of Computer Programming_ for a good discussion of the matter. (I recommend spending a few years working the problem sets-- they are quite illuminating).

The most basic form is simply:
X_n = (a*X_(n-1) + c) mod m
This is called a linear congruential generator. It's quite nutty that it works as well as it does, though there are major issues with it. The first thing you have to tackle is figuring out what to make a,c and m. This is detailed very well in Knuth's work.

RC4 and you

RC4 encryption is a simple algorithm. It happens in two phases the setup and the cipher. The cipher is symmetric.

data consists of 256 bytes of state, up to 256 bytes of key, and 10 bytes of random data.

In the setup phase you should first init the state to contain 0 through 255. The key should contain the key itself followed by 10 bytes of random data. (If you are encrypting, the data is created by you and included in the output, if you are decrypting the data should come from the person who sent the ciphertext). Set i and j zero.

Secondly, you must mix the state. For each byte in the state do the following: set n to i mod the length of the key. then, add to j the i'th byte of state and the n'th byte of the key and take the mod 256. Then swap the i'th and j'th byte of state.

After this is done for each byte, set i and j to zero again.

For each byte to encrypt or decrypt do the following: increment i (again mod 256), and add to j the resulting i'th byte of the state (mod 256), then swap the j'th and i'th byte of state. n then is set to the i'th byte of state added to the j'th byte of state (mod 256). Finally, the n'th byte of state is exclusively or'ed with the byte to be cpihered.

As it stands, RC4 is subject to successful attacks. One modification to make it stronger is to perform the mix-state step multiple times (agreed to by the sender and receiver).

References:

Applied Cryptography, Second Edition, by Bruce Schneier,
John Wiley &
Sons, New York, 1996.  ISBN: 0471117099

 
 http://ciphersaber.gurus\.com/faq.html#getrc4
(Sep 15, 2001).

 
 _The Art of Computer Programming : Seminumerical Algorithms
(Vol 2, 3rd
Ed)_ by D.E. Knuth,  Addison-Wesley Pub Co, 1997.  ISBN:
0201896842

 
 

yay! mozilla 0.9.4

raph:

with regard to the antialiasing/hinting...

i think it's still going to be important to have decent fonts. 200DPI, high res screens will become ubiquitiuos for the desktop; however, many devices have smaller, lower resolution screens (like PDA's, wearable computers, and people who can't afford the new stuff) that are just getting to the point where they might benefit from having better fonts.

on the other hand there's alot of interesting stuff to be done besides (i think everyone here is familar with this).

the best solution may be to find someone (perhaps a motivated undergrad student, or young grad student) to recruit/mentor and oversee. they get the benefit of your knowledge, and they get to tackle an interesting problem. likewise, you are freed from dealing with the lower level details. also, you needn't feel to bad if the effort becomes less necessary in the long run.

it might be good to find a corporate sponser too, but i have no experience with this, and it sounds like a time consuming thing to do.

delegation is good, but sometimes it's hard to part with wanting to do it all yourself.

i'll email this response to you as well...hope you don't mind.

gilbertt:

Verbage mirwin: as members and users of this site, we all have a responsibility to keep our diary entries relatively terse, and not drone on for page after page after page. Please stop ignoring this responsibility. If you have nothing better to do that rehash the same stuff again and again in far more words than necessary, please create your own website for doing it. I'd just like to scroll down recentlog and not have to ignore the half of it that comes from you. It's annoying to me that just one of your entries makes 10 entries from people I actually care about scroll off the bottom of the page.

i have to disagree strongly with you here: they are diaries. the only problem it creates is making the recentlog page longer.

you have to look through the recentlog page to find the diaries you want to read only due to the inadequecies of the software that runs advogato (as raph tends to be very busy with other stuff).

a site like livejournal.com has many more features which make using it easier. (i believe it's open source too). but it's not quite what advogato aims to be.

the fix could be any of the following:
_raph should let a few other people help out with admin'ing and upgrading the site (the changes being made to the code base by others have not been folded in though raph plans to do this).
_the site should transition to a different code base and add in the trustmetric. this would eliminate possibly redundent efforts into making a good community site, and allow raph to focus on the trust metric end of things.

i favor the first option, because i like advogato as it is. that said, a few more features would make using it faster and easier.

been building and crashing some micro rc airplanes. fun stuff. now i'm looking for another plane to scratch build.

there sure is alot of fun stuff to be done.

must do some now.

hooray

High Level Language Constructs 1.

A closure is a piece of code and its environment which can be referred to and executed. The environment consists of the variable bindings which are available to the closure when it was first declared/executed. [2]

Pseudocode:

void *
create_foo ( void ) 
{
       double c = sqrt(5)/2;
       int call_count = 0; 
       void inner_foo (double x) { 
       	   printf("%i, %f\n", call_count c*x);
	   call_count++;
       }
       return inner_foo;
}

 foop = create_foo();   // foop is a function pointer to
inner_foo
foop(11); 
>> 0 12.29837387624884333020
foop(11); 
>> 1 12.29837387624884333020

a closure 'closes' the free variables. in the above example the free variable (with respect to inner_foo) are call_count and c. being a free variable means that they are not locally defined. (note that if this were like C, the variables c, and call_count would be allocated on the stack and would go away when the call returns. but since this is a psuedolanguage...they stay around. in lisp and scheme, they would

be allocated on the heap and a garbage collector would take care of them).

notice that we can do similar things with object oriented programming:

Class Foo { 
      double c;
      int call_count;
      Foo(void) { 
         c = sqrt(5)/2;
	 call_count = 0;
      }

       void inner_foo(double x) { 
       	   printf("%i, %f\n", call_count c*x);
	   call_count++;
      }	   
}

this would accomplish the same capturing of the variables only explicitly, requiring a call to

foo->inner_foo(11)

instead of the above.

In real life, closures are most useful for implementing callbacks. In C using Gtk+ for example you can specify a function that is called when an event occurs (like a button press).

you do this with a function like this [4]

signal_connect(object_signal_comes_from, 
	       signal_name, 
               function_to_call,
               gpointer data)

the signature of the function_to_call is usually something like

void function_to_call(object_signal_comes_from, gpointer data); 

the data is a void pointer that can be used to pass along pointers to structures which should be operated on when the event occurs.

One weakness of this system, however, is that if more than one piece of data needs to be used by the callback function, you either have to package them into another struct whose address you can then pass in the data, or you have to use global variables.

A closure on the other hand can be used to give the effect of referring to a global variable (the closed free variables) without having to structure your code as such. In C for instance, this would prevent having copious 'extern' declarations to share instances of data across files. And since the variables aren't actually global, you can use them to pass along different values to the same callback (by making more than one closure of that callback function).

In this case, a closure isn't strictly necessary, but having it available, allows you to get the job done a bit faster since you don't have to define the struct to aggregate all the necessary values which should be passed to the callback, and allocate and free that struct. This is one of the reasons that lisp, scheme, and python users say that you can get more done faster with fewer lines of code in these languages than in languages like C or pascal.

(It is intresting to note that many higher level language constructs are built on the idea of computation-as-data.[1])

references:

1.http://www.cb1.com/John/thesis/chapters/closure-building.html (07/17/2001)
2.http://www.cs.utexas.edu/users/wilson/schintro/schintro_122.html#SEC152 (7/17/2001)
3.http://www.norvig.com/python-lisp.html (7/17/2001)
4.http://developer.gnome.org/doc/API/gtk/gtk-signals.html#GTK-SIGNAL-CONNECT (7/17/2001)
5. Brian W. Kernighan, Dennis M. Ritchie, _The C Programming Language_ 2nd ed.

grrrrrrrrrrrrr.
annoying issues with the gnu assembler.
the people on bug-binutils@gnu are helpful.
it was almost haiku.

I AM WEARING MY PANTS ON MY FACE

helpful hint: if you are using libaudiofile, and the version isn't recent (say 0.2.1), do yourself a nice favor and upgrade. 0.1.9 (or so) took about 30 seconds to read a certain file, and 0.2.1 took about 1 second on the same file. i wonder how michael managed that one (and i don't mean the amazing optimizations :D).

debian

dbootstrap (the debian installer program) has to be one of the most hideous programs in existence. it's this huge mess of C. the menusystem is hardcoded. good grief.

so consequently i had to make a new install program. used python. was fun. now i need to clean it up a bit. and make a decent scripting/menu interface.

overall a fun way to waste a nite and early morning, and a few hundred megs of diskspace.

pepper: cygnus managed to carve out a pretty good niche for themselves. this is mainly the reason why redhat bought them: they sold products and had cashflow.

i dunno what your definition of good money is though.

most people/companies doing well with freesoftware seem to be those that get paid to create some specific program or do maintainence or improve or port software. fundementally, it is selling the time of the programmer to do the work, not the program itself.