A critic of Guido's blog on Python's lambda

[Paul Rubin]

"Martin P. Hellwig" <mhellwig at xs4all.nl> writes:
> and clients make it quite scalable. For example, I'm creating a
> xmlrpcserver that returns a randomized cardlist, but I because of
> fail-over I needed some form of scalability , my solution was to first
> randomize the deck then marshal it and dump the file on a ZFS
> partition, giving back the client a ticket number, the client can then
> connect with the ticket number to receive the cardlist (read the file
> - unmarshal it).

This is a weird approach.  Why not let the "ticket" by the (maybe
encrypted) PRNG seed that generates the permutation?

> While this is overkill for 1 server, I needed multiple because of
> fail-over and load-balancing, in this case I have 3 'crypto' boxes
> (with hardware crypto engines using OpenBSD) doing only the
> randomizing and 4 solaris machines doing the zfs and distribution of
> the list.

I don't know what good that hardware crypto is doing you, if you're
then writing out the shuffled deck to disk in the clear.