My guess, based on what was commonly available at the anonymous author's facility in 1984, was that their machine was most likely a Dec Vax or PDP. The C compiler for Un*x on those machines allocated global variables out of bss which was initialized to zero by default.
I do know that Larry Bassel and I tested the entries on a Vax 780 running a BSD-flavored Un*x. The grand prize
winner of 1984 assumes you are running on a PDP or a Vax which had a PDP emulation mode.
We tested all of the 1984 entries on the same
system.
BTW: That entry by
Sjoerd Mullender and Robbert van Renesse
remains one of the my all-time favorites to this day.
Machine dependent entries are discouraged by the guidelines today, but not so in 1984.
It was probably that Grand Prize entry, more than anything, that encouraged Larry and I to hold a 2nd IOCCC back in 1985.
It was also the fact that the
grand prize authors were from Europe that the word "International" was added to the contest
name back in 1985.
FYI: I asked the anonymous
author a while back about Perl. They said:
"
Sometimes write
in Perl when the wind is right.:-)
(my smiley added) No seriously,
Perl does have its place.
I do use it for short scripting sometimes
although in those years
(back in 1984) it was sed, awk, grep and sh."
Very good explanation, BTW.
I was told that anonymous winner
used almost (but not quite) the reverse of your
explanation to construct the original entry.
Very well done post! It is nice to see someone who knows what they are talking about, responding
with reasonable accuracy and attitude
to a general question.
Piggy-backing on the parent post:
The UK National Lab
result represents a significant amount of
hard and careful work on behalf of a team
of very skilled people.
Congratulations to Gill and his team!
Strontium has been known for a while to have
a very narrow "linewidth".
Knowing this and being able to hold a laser
to that narrow frequency is another thing.
Still harder is to hold that frequency for
an extended period of time and count the
pulses reliably.
Even more difficult is producing a robust device
that can operate as
a reference standard for an extended period
of time.
There are lots and lots of devils in the details!
In theory, we should be able to
produce devices with a frequency that is stable
to about 1 part in 10^18.
The trick will be to build a robust device
that can take advantage of them.
And there are other elements with
hyperfine transitions that
might work even better than Strontium.
In will be interesting to see if such
frequency stability will be reached with
Strontium or another element altogether.
Whatever the element,
the pulses of such an ultra stable frequency
source would become the "ticker" of a
ultra accurate clock.
Work performed by
groups such as Dr. Gill's are "paving the
way" for the development of such a clock.
An ultra accurate clock is a thing of
beauty in and of itself.
Moreover, such a clock is an important
tool in fields such as Physics (such
as the detection
of "constant-drift"),
Astronomy (such as pulsar gravity wave
spin-down detection),
and navigation (on earth and
in deep space) will all benefit.
The Frequency/Time field is making
steady progress!:-)
I would like to comment on walking the campaign
trail from the perspective of an elected official
who did a lot of it:
When I ran for Sunnyvale City
Council I talked every predict in the city of ~125k people; knocking on some +30k doors of regular voters introducing myself and asking people to consider voting for me in November.
It was a very valuable experience.
I had plenty of experience listening to the voters
and answering their questions.
By the time it came to the televised debates I had a solid grasp of the concerns of the voting public.
I won with ~50% of the vote in a 3-way race.
Doing that much walking was hard work!
I walked 6 to 8 hours a day, 7 days a week for nearly 8 months.
Not only was to good exercise, it gave me some
key insights into important neighborhood issues
while I was in office.
Walking for another candidate is a fine thing
to do.
Even after I was selected I walked
a number precincts for a number of candidates
that I endorsed.
Still, there is no substitute for a voter
talking one-on-one with the actual candidate.
What all of that said:
About 1/2 of the my
time in a precinct was at the
door:
waiting for somebody to answer
leaving a note if nobody was home
attempting to discover
of they had a "No solicitors" sign (I would not
knock if they did)
finding the door bell
attempting to determine if the door bell
worked or if you had to knock
talking to the voter
The Segway will not help you with the door time.
Another ~1/6 of my time was spent going
from the street to the door.
This was the time that one had to remain
alert for:
dogs and other attack animals
trip and fall hazards
(hard to walk the city if you are on crutches)
finding the "main door"
(sometimes the main door was not the front
door but a side door)
avoiding plants / lawn
(some people really get upset if you tread
on their lawn, others expect you to walk
over it to reach their door)
not surprising people
(not good introduce yourself after you
have just startled them)
Using the Segway to go from the curb to the
door would be a bad idea... even if you
had room to navigate your way without
running over plants, pets, etc.:-)
The many stairs and steps would also be an issue
with the Segway.
The other ~1/3 of my time was spent going
to the next door.
Some of that is finding the next address of
a regular voter.
Some of that is attempting to
look up their name (I always
attempted to address them personally if
possible), etc.
The Segway would be able to help going
to the next door.
I mostly walked in the suburbs.
I am sure other types of areas have
different time ratios.
For my case: even if the Segway could cut my time
to the next door to zero, it would have
only saved me about 1/3 of my time.
Segways are fun, but I don't see
how they can 3x your
voter reach in the types of areas that I
was walking in.
This is not the 1st time that I have seen somebody
install a Microsoft critical update and receive
spyware.
No wonder Gates is not interested in building
anti-spyware into his products!
The Google billboard on US Highway 101 in CA
on
Google's Math Puzzle
·
· Score: 2, Interesting
The temperature of Hell is an old physics geek problem. The
calculation tale varies, but they state something
to the effect that:
The
temperature of hell is
> 388.36K and
< 717.87K because
under 1 atm pressure, molten Sulphur ("..
into the lake which burneth with fire and brimstone...") is liquid over that range.
So "TENFOLD HOTTER" would make "extreme
makeovers"
> 3883.6K and
< 7178.7K.
Note that surface of the Sun is
usually estimated to be about 5780K
which is similar to the midpoint of the
hell temperature
range (5531.15K).
Therefore one might conclude that these
"extreme makeovers" might
be brilliant...
thus the
need for sun glasses.:-)
AZ, CA, GA, ID, IN, IL, MD, MI, MO, OK, OR, PA, NC, SC, TX, VA
Nader cannot win 259 of the Electoral Votes.
There are 538 total Electoral Votes
and you need 270 to win the Presidency.
If the NECN (New England Cable News) report that Nader has been disqualified in MA is correct,
then Nader cannot win 271 votes.
This would mean that even
if Nader won every state in which
he was on the ballot,
Nader would still fail to
win the Presidency.
Obfuscate:
tr.v. -cated, -cating, -cates. 1. a. To render obscure.
b. To darken. 2. To confuse: his emotions obfuscated his judgment.
[LLat. obfuscare, to darken : ob(intensive) + Lat. fuscare,
to darken < fuscus, dark.] -obfuscation n. obfuscatory adj.
Goals:
To write the most Obscure/Obfuscated C program under the
content rules.
To show the importance of programming style, in an ironic way.
To stress C compilers with unusual code.
To illustrate some of the subtleties of the C language.
To provide a safe forum for poor C code.:-)
And here is one entry from the
IOCCC
FAQ that talks about
how the IOCCC got started:
One day (23 March 1984 to be exact), back Larry Bassel and I (
Landon
Curt Noll) were working for National Semiconductor's Genix porting group, we
were both in our offices trying to fix some very broken code.
Larry had
been trying to fix a bug in the classic Bourne shell (C code #defined
to death to sort of look like Algol) and I had been working on the
finger program from early BSD (a bug ridden finger implementation to be
sure).
We happened to both wander (at the same time) out to the hallway
in Building 7C to clear our heads.
We began to compare notes: ''You won't believe the code I am trying to
fix''.
And: ''Well you cannot imagine the brain damage level of the code
I'm trying to fix''.
As well as: ''It more than bad code, the author really
had to try to make it this bad!''.
After a few minutes we wandered back into my office where I posted a
flame
to net.lang.c
inviting people to try and out obfuscate the
UN*X source code we had just been working on.
BTW:
I (Landon Curt Noll)
had to post this
typo
correction.
Thus began the tradition of putting typos in the contest rules and
guidelines... to make them more obfuscated of course!:-)
BTW:
This posting was made back in the days when AT&T was the evil giant.
Now, Microsoft makes AT&T look mild and kind in comparison.:-( (IMHO) ).
BTW:
See the story about the ''
Bill
Gates'' award.:-)
OK, back to the story.
We (Larry and I) received a number of entries by EMail.
When we began to receive messages from outside of the US, Larry and I
decided to include International in the name.
The
1st IOCCC winners
were posted on 17 April 1984.
When we release the IOCCC winners, we are
going to need more mirrors.
If you want to mirror the IOCCC,
please send EMail to
Simon Cooper at:
mirror-request at ioccc dot org
Please include the following words in the subject of your EMail message:
IOCCC 2004
We will ask you a few questions and provide you with information on how we would prefer you
to mirror the site.
Please don't start mirroring until we have responded
and processed your mirror request.
Thanks in advance for your willingness to help.
Try webcams based on the
ov511
module.
The
LavaRnd
project uses the
D-LINK
DSB-C100 webcam
as one of its reference entropy sources because
it was "plug and play" for recent 2.4 and
all 2.6 kernels.
A search at
Bizrate
shows the DLink webcam going for about $20 US.
Another camera we tested that is
"plug and play" for recent 2.4 and all
all 2.6 kernels are camera based on the
se401 module.
In our next release of LavaRnd, we will
be adding support for
Kensington
VideoCAM PC Camera model 67014.
This camera is already supported as a normal
webcam... we are just getting around to making
it a reference LavaRnd entropy source because
someone donated one to the project.
These cameras seem to sell from $25 to $41 US.
Specs suggest that models 67015 thru 67017
should work as well as model 67014; although
we have only tested the 67014 model.
When properly "mis-tuned" and lens capped,
these webcams make good entropy sources.
And of course, they take reasonable pictures
when they are used as they were originally
intended to be used.:-)
Our list is by no means complete.
There are others we are sure.
If anyone has another other well supported
webcams, please chime in...
To whom / where does one say:
"I am willing to maintain the PWC open
source code"?
I've hacked kernels for years, even done
a bit inside Linux from time to time.
I've even pondered
writing a/dev/lavarnd kernel
module interface
(because of statistical DFT Spectral
flaws
in/dev/random),
but that is a different story.:-)
I'd be happy to yank the PWXC hooks and maintain
just the existing PWC interface.... unless somebody else wants to or is
doing it already.
Sorry, we do not have a system that runs windows.
Also PWC/PWCX only runs under Linux.:-)
Our Logitech QuickCam 3000 Pro CCD only
has a 160x120 pixel grid.
While this
closeup
image of the chip is a bit small
to count by, under higher magnification you can
see the individual sensors and count them.
They do not have 640x480 pixel array on
our chip.
We counted 160x120 instead.
One can do the math.
At 30 fps with 640x480 pixels, using
the YUV 4:2:0 Planar palette,
(encodes at 1.5 bytes per pixel) you have:
640*480*1.5 octets*30/sec = 13824000 octets/sec
You cannot shove data down a
USB1.1 pipe at that rate.
Something has to fill in the extra
data (between the 160x120 pixel grid and
the frame buffer of an application)
as it cannot be sent over a USB 1.1 wire
and keep up.
If you examine under high magnifaction
(where pixels are a few mm in size), you
can see the 4x4 chunking that PWCX performs.
Maybe windows has the Philips
decompressor builtin by default?
We know that the 640x480 bits are not real bits
from the hardware.
Perhaps the 640x480 rate is due to the CPU time
needed to fill in the in between pixels?
Try this experiment:
Take a 640x480 picture of a grid such as graph
paper... lines on a plain color background.
Enlarge the image until pixels are squares
that you an clearly see.
Notice the 4x4 pixel blocking.
Notice how each 4x4 pixel block looks like
a plane tilted in color space.
Now try the same for a 320x240 image.
And notice the 2x2 pixel blocking.
One ironic twist is that LavaRnd used only
the PWC (open source) module.
We did NOT use the PWCX (binary-only)
module.
Our hotplug script did an rmmod of the
pwcx module.
We discovered that the PWCX module reduced the
entropy that the webcams provided.
The PWCX module, when loaded, made webcams
a poorer entropy source.
LavaRnd used the entropy provided by the
actual hardware.
Our analysis showed that PWCX
was in effect "faking" the larger image sizes
by taking, say the true 160x120 pixel CCD output
and expanding it to something like 640x480.
The expansion was as if a 2D smoothing function
(such as a 2D spline?)
filled in the pixels in between.
Each of the original 160x120 hardware
pixels was turned
into a 4x4 pixel grid where the edges of
the grid were adjusted to fit better with
neighboring 4x4 pixel grids.
The PWCX appeared to support a higher frame rate
because the PWCX module "decompressed" the
true hardware pixels
and filled in the pseudo-pixels on the other
side of the USB wire.
We discovered the PWCX effect while taking
entropy measurements of webcam frames.
Using PWC alone in 160x120 mode,
the webcam produced slightly
more entropy than 640x480 PWCX mode.
The PWCX module was not adding real image
data to webcam frames, it was just smoothing
and filling in data that looked good enough
to a human.
However, PWCX could not fool the math...:-)
"
and I'm going to request (well, demand) that PWC will be removed from the kernel tree.''
The PWC maintainer's position appears to be
that if you cannot use PWCX, then PWC is
worthless.
From LavaRnd's point of view, PWCX (the binary
only module) adds no value and in some ways
reduces the Logitech QuickCam's value as
an entropy source.
We (LavaRnd) do not want to take sides in this
PWC/PWCX kernel dispute.
If this posting appears that way, then we
apologize.
The PWC folks have been mostly patient with
our unusual use of their webcam modules.
The Linux kernel folks have provided us with
a wonderful platform for LavaRnd.
As for ourselves, we put a lot of time into
helping
end users use the PWC module in older kernels.
Here is our advice request:
The LavaRnd project would like to see the
PWC (open source) module remain in the
Linux Kernel.
We would like the Linux kernel folk to
not honor the maintainer's request
to remove everything.
We want the support of PWC without PWCX
to continue in the Linux Kernel.
What is the best was to make
this position / request
known to the key Kernel people in the hopes
they will PWC as part of Linux?
And does every chunk of the Linux Kernel
need an active maintainer?
Could PWC remain in the Linux Kernel without
the original maintainer's support or would
someone such as ourselves need to step up
and offer to maintain it?
At SGI we did use Lava Lite(R) lamps to
generate unpredictable
seeds for pseudo-random number generators.
We purchased quite a few lamps over the life
of the project... so many that we had our
own account rep from the factory
and special discount price.
It was not hard for us to get approval to
buy the Lava Lite lamps.
Our bosses were very supportive in signing the
purchase orders to buy the lamps.
All it took was presenting a cool idea
(lavarand) to cool bosses (David Watson
and later Mel Pleasant).:-)
Some have asked about the relationship between
the classic SGI lavarand and the current
LavaRnd
project:
One of the members of the SGI
classic lavarand team
(me)
is also on the current LavaRnd team
As a nod to history, we do maintain a
pair
of lamps
in view of the live image our entropy source.
The difference between the old SGI classic
lavarand and the new LavaRnd
may
be viewed here
In the 08
Apr 2005
eclipse, the Umbra leaves the Earth
about 22:00 UT.
The
path
details
show that the totality path drops to 0 about
22:00 UT as well.
The Annular
Atlas shows that this 22:00 UT
point is well off the coast.
When it is this close to totality, one's thumb
(or other opaque object) may be used to
block out the solar disk and view the corona.
Using a ball on a stick and sighting the Sun
behind it will give one multiple seconds
of corona viewing.
I've used this technique to extend "totality
effects" as much as 15 second beyond the
official end of the eclipse.
I have been told that using a green filter
will further enhance the contrast of the
corona and allow you to extend the corona
viewing even longer.
Also when it is this close to total, you should
be able to view the shadow bands.
It is best to view then afterwards as the
excitement of what the sun/moon are doing will
occupy your attention.:-)
One cannot look for the shadow bands
and extend the corona viewing time.
Given the choice, I'd contentrate on the
zone around the solar disk.
Unlike long totality eclipses, short totality
and near total annular eclipses give one a
MUCH better view of photosphere / action near
the edge of the solar disk.
That alone would suggest skipping the shadow
bands this time.
I would try and go as far west as possible
so that the sun is as high above the horizon
as possible.
Of course one would want to be close to the
center line... which becomes critical on
short annular events like this one.
Of course, a ''the deep annular-like
conditions'' of the Venus transit do
not permit one to do this.:-)
> I went to Venezuela for the eclipse of 1998
> (did you see that one?)
1998 was a wonderful eclipse.
I do not see every Eclipse.
I'm trading the
08
Apr 2005 Solar Hybrid for the
8
June 2004 Venus
transit for example.
Since you live in Ecuador, I would
encourage/urge you to travel to the coast
and see the
Hybrid
eclipse (part Annular / part Total).
My calculations show that it will be very
close to total along the center line in
South America.
It is worth while to see the Sun
in annular mode once in a while.
long range plans for viewing transits & eclips
on
The Venus Transit 2004
·
· Score: 3, Interesting
I have made the viewing special astronomical
events a priority.
As a pre-condition of employment I ask my
prospective employer to ensure that I have
will get time off travel and view:
Total Solar Eclipses
Planetary Transits
Naked-eye visible Supernovas
Not only do I get to see amazing astronomical
events, while I am there I travel around
and see wonderful and interesting parts
of our own planet!
To pay for my vacations to these selected
events, I have established travel investment
funds (setup many years in advance) for:
I also keep an emergency fund that allows me
go anywhere in the world at a moments notice
to see a Supernova bright enough seen with the
naked eye.
I had such a fund in place which
allowed me to rush from California to
Australia some 21 hours after the
discovery of
1987A
(24 Feb 1987).
Maybe next naked eye supernova viewable in
my hemisphere.
But if not, I have another supernova fund
ready...
I have seen several postings related to the
"unbreakable Vernam / One-Time pad cipher".
The Vernam Cipher, or one-time pad is not a
the ''super-duper unbreakable solves all
your problems'' cipher that some people
think it is.
Yes, Quantum Cryptographic Communications
(QCC)
can
help with the requirement that the one-time pad
must be transmitted in private.
However the one-time pad cannot be reused
so your key must be the same size as your text.
Thus far, Quantum Cryptographic Communications
is not a speedy high bandwidth form of
communication.
It might be OK to transmit a small key but
to date it is not OK for sending,
in a reasonable
period of time, huge one-time pad keys
that are as big as your original message.
Another thing people sometimes gloss over
about Vernam one-time pads is that your
cipher is only as good as your random
number generator!
If you generate your one-time pad using
the v7 libc rand(3) function
your one-time pad is next to useless.
Another important aspect of Quantum Cryptography
(Quantum Cryptography is not simply limited
to communications) is random
number generation.
Quantum Cryptographic Random Number
Generation (QCRNG) is a useful tool
in generating keys (one-time pads, block
cypher keys, public/private key pairs, etc.).
The importance of QCRNG goes beyond Vernam
one-time pads.
You want a cryptographically strong RNG such
as a QCRNG when you generate your session
keys.
Sending predictable keys over a QCC protected
link is next to useless!
Now IF you have:
near perfect communication privacy
(such as with QCC)
near perfect one-time pad generation
(such as with QCRNG)
near perfect key management
(one-time use, no leakage,
destruction after use, etc.)
near perfect... etc.
then you will
begin to approach the ''unbreakable cypher
level'' that some people think you get
with Vernam One-Time Pad Ciphers.
Slashdot Mirror
I do know that Larry Bassel and I tested the entries on a Vax 780 running a BSD-flavored Un*x. The grand prize winner of 1984 assumes you are running on a PDP or a Vax which had a PDP emulation mode. We tested all of the 1984 entries on the same system.
BTW: That entry by Sjoerd Mullender and Robbert van Renesse remains one of the my all-time favorites to this day. Machine dependent entries are discouraged by the guidelines today, but not so in 1984. It was probably that Grand Prize entry, more than anything, that encouraged Larry and I to hold a 2nd IOCCC back in 1985. It was also the fact that the grand prize authors were from Europe that the word "International" was added to the contest name back in 1985.
Very good explanation, BTW. I was told that anonymous winner used almost (but not quite) the reverse of your explanation to construct the original entry.
Beyond the first two lines, how did you select those IP address ranges? Did you examine your logs or obtain these ranges from a list somewhere?
Very well done post! It is nice to see someone who knows what they are talking about, responding with reasonable accuracy and attitude to a general question.
Piggy-backing on the parent post:
The UK National Lab result represents a significant amount of hard and careful work on behalf of a team of very skilled people. Congratulations to Gill and his team!
Strontium has been known for a while to have a very narrow "linewidth". Knowing this and being able to hold a laser to that narrow frequency is another thing. Still harder is to hold that frequency for an extended period of time and count the pulses reliably. Even more difficult is producing a robust device that can operate as a reference standard for an extended period of time. There are lots and lots of devils in the details!
In theory, we should be able to produce devices with a frequency that is stable to about 1 part in 10^18. The trick will be to build a robust device that can take advantage of them. And there are other elements with hyperfine transitions that might work even better than Strontium. In will be interesting to see if such frequency stability will be reached with Strontium or another element altogether. Whatever the element, the pulses of such an ultra stable frequency source would become the "ticker" of a ultra accurate clock. Work performed by groups such as Dr. Gill's are "paving the way" for the development of such a clock.
An ultra accurate clock is a thing of beauty in and of itself. Moreover, such a clock is an important tool in fields such as Physics (such as the detection of "constant-drift"), Astronomy (such as pulsar gravity wave spin-down detection), and navigation (on earth and in deep space) will all benefit.
The Frequency/Time field is making steady progress! :-)
When I ran for Sunnyvale City Council I talked every predict in the city of ~125k people; knocking on some +30k doors of regular voters introducing myself and asking people to consider voting for me in November.
It was a very valuable experience. I had plenty of experience listening to the voters and answering their questions. By the time it came to the televised debates I had a solid grasp of the concerns of the voting public. I won with ~50% of the vote in a 3-way race.
Doing that much walking was hard work! I walked 6 to 8 hours a day, 7 days a week for nearly 8 months. Not only was to good exercise, it gave me some key insights into important neighborhood issues while I was in office.
Walking for another candidate is a fine thing to do. Even after I was selected I walked a number precincts for a number of candidates that I endorsed. Still, there is no substitute for a voter talking one-on-one with the actual candidate.
What all of that said: About 1/2 of the my time in a precinct was at the door:
The Segway will not help you with the door time.
Another ~1/6 of my time was spent going from the street to the door. This was the time that one had to remain alert for:
Using the Segway to go from the curb to the door would be a bad idea ... even if you
had room to navigate your way without
running over plants, pets, etc. :-)
The many stairs and steps would also be an issue
with the Segway.
The other ~1/3 of my time was spent going to the next door. Some of that is finding the next address of a regular voter. Some of that is attempting to look up their name (I always attempted to address them personally if possible), etc.
The Segway would be able to help going to the next door.
I mostly walked in the suburbs. I am sure other types of areas have different time ratios. For my case: even if the Segway could cut my time to the next door to zero, it would have only saved me about 1/3 of my time.
Segways are fun, but I don't see how they can 3x your voter reach in the types of areas that I was walking in.
> Gates: It's not a thing you build in.
This is because Microsoft allows spyware to be installed as part of its critical updates!
Last month I watched as a friend:
During the last update and spyware scan cycle, AdAware discovered a spyware issue in the registry!
FYI: The spyware entry came into by friends system as a result of one of these Microsoft critical updates:
AdAware discovered:
For more info on ALEXA spyware see:
This is not the 1st time that I have seen somebody install a Microsoft critical update and receive spyware. No wonder Gates is not interested in building anti-spyware into his products!
Typo or new term?
Note that surface of the Sun is usually estimated to be about 5780K which is similar to the midpoint of the hell temperature range (5531.15K).
Therefore one might conclude that these "extreme makeovers" might be brilliant ...
thus the
need for sun glasses. :-)
I'm sure other interpretations exist.
Nader cannot win 259 of the Electoral Votes.
There are 538 total Electoral Votes and you need 270 to win the Presidency.
If the NECN (New England Cable News) report that Nader has been disqualified in MA is correct, then Nader cannot win 271 votes. This would mean that even if Nader won every state in which he was on the ballot, Nader would still fail to win the Presidency.
Definition
Goals:
And here is one entry from the IOCCC FAQ that talks about how the IOCCC got started:
Please include the following words in the subject of your EMail message:
We will ask you a few questions and provide you with information on how we would prefer you to mirror the site. Please don't start mirroring until we have responded and processed your mirror request. Thanks in advance for your willingness to help.
Another camera we tested that is "plug and play" for recent 2.4 and all all 2.6 kernels are camera based on the se401 module. In our next release of LavaRnd, we will be adding support for Kensington VideoCAM PC Camera model 67014. This camera is already supported as a normal webcam ... we are just getting around to making
it a reference LavaRnd entropy source because
someone donated one to the project.
These cameras seem to sell from $25 to $41 US.
Specs suggest that models 67015 thru 67017
should work as well as model 67014; although
we have only tested the 67014 model.
When properly "mis-tuned" and lens capped, these webcams make good entropy sources. And of course, they take reasonable pictures when they are used as they were originally intended to be used. :-)
Our list is by no means complete. There are others we are sure. If anyone has another other well supported webcams, please chime in ...
I've hacked kernels for years, even done a bit inside Linux from time to time. I've even pondered writing a /dev/lavarnd kernel
module interface
(because of statistical DFT Spectral
flaws
in /dev/random),
but that is a different story. :-)
I'd be happy to yank the PWXC hooks and maintain just the existing PWC interface. ... unless somebody else wants to or is
doing it already.
Our Logitech QuickCam 3000 Pro CCD only has a 160x120 pixel grid. While this closeup image of the chip is a bit small to count by, under higher magnification you can see the individual sensors and count them. They do not have 640x480 pixel array on our chip. We counted 160x120 instead.
One can do the math. At 30 fps with 640x480 pixels, using the YUV 4:2:0 Planar palette, (encodes at 1.5 bytes per pixel) you have:
You cannot shove data down a USB1.1 pipe at that rate. Something has to fill in the extra data (between the 160x120 pixel grid and the frame buffer of an application) as it cannot be sent over a USB 1.1 wire and keep up.
If you examine under high magnifaction (where pixels are a few mm in size), you can see the 4x4 chunking that PWCX performs.
Maybe windows has the Philips decompressor builtin by default?
Try this experiment: Take a 640x480 picture of a grid such as graph paper ... lines on a plain color background.
Enlarge the image until pixels are squares
that you an clearly see.
Notice the 4x4 pixel blocking.
Notice how each 4x4 pixel block looks like
a plane tilted in color space.
Now try the same for a 320x240 image. And notice the 2x2 pixel blocking.
Now try the same for a 160x120 image.
One ironic twist is that LavaRnd used only the PWC (open source) module. We did NOT use the PWCX (binary-only) module. Our hotplug script did an rmmod of the pwcx module. We discovered that the PWCX module reduced the entropy that the webcams provided. The PWCX module, when loaded, made webcams a poorer entropy source.
LavaRnd used the entropy provided by the actual hardware. Our analysis showed that PWCX was in effect "faking" the larger image sizes by taking, say the true 160x120 pixel CCD output and expanding it to something like 640x480. The expansion was as if a 2D smoothing function (such as a 2D spline?) filled in the pixels in between. Each of the original 160x120 hardware pixels was turned into a 4x4 pixel grid where the edges of the grid were adjusted to fit better with neighboring 4x4 pixel grids. The PWCX appeared to support a higher frame rate because the PWCX module "decompressed" the true hardware pixels and filled in the pseudo-pixels on the other side of the USB wire.
We discovered the PWCX effect while taking entropy measurements of webcam frames. Using PWC alone in 160x120 mode, the webcam produced slightly more entropy than 640x480 PWCX mode. The PWCX module was not adding real image data to webcam frames, it was just smoothing and filling in data that looked good enough to a human. However, PWCX could not fool the math ... :-)
The PWC maintainer says on his web site:
The PWC maintainer's position appears to be that if you cannot use PWCX, then PWC is worthless. From LavaRnd's point of view, PWCX (the binary only module) adds no value and in some ways reduces the Logitech QuickCam's value as an entropy source.
We (LavaRnd) do not want to take sides in this PWC/PWCX kernel dispute. If this posting appears that way, then we apologize. The PWC folks have been mostly patient with our unusual use of their webcam modules. The Linux kernel folks have provided us with a wonderful platform for LavaRnd. As for ourselves, we put a lot of time into helping end users use the PWC module in older kernels.
Here is our advice request:
The LavaRnd project would like to see the PWC (open source) module remain in the Linux Kernel. We would like the Linux kernel folk to not honor the maintainer's request to remove everything. We want the support of PWC without PWCX to continue in the Linux Kernel. What is the best was to make this position / request known to the key Kernel people in the hopes they will PWC as part of Linux?
And does every chunk of the Linux Kernel need an active maintainer? Could PWC remain in the Linux Kernel without the original maintainer's support or would someone such as ourselves need to step up and offer to maintain it?
It was not hard for us to get approval to buy the Lava Lite lamps. Our bosses were very supportive in signing the purchase orders to buy the lamps. All it took was presenting a cool idea (lavarand) to cool bosses (David Watson and later Mel Pleasant). :-)
Some have asked about the relationship between the classic SGI lavarand and the current LavaRnd project:
All of our webcams, except one, are covered. :-)
I found the book: Coping with Difficult People by Robert M. Bramson very helpful in dealing with (as you say) an ''extremely unpleasant person''.
When it is this close to totality, one's thumb (or other opaque object) may be used to block out the solar disk and view the corona. Using a ball on a stick and sighting the Sun behind it will give one multiple seconds of corona viewing. I've used this technique to extend "totality effects" as much as 15 second beyond the official end of the eclipse. I have been told that using a green filter will further enhance the contrast of the corona and allow you to extend the corona viewing even longer.
Also when it is this close to total, you should be able to view the shadow bands. It is best to view then afterwards as the excitement of what the sun/moon are doing will occupy your attention. :-)
One cannot look for the shadow bands and extend the corona viewing time. Given the choice, I'd contentrate on the zone around the solar disk. Unlike long totality eclipses, short totality and near total annular eclipses give one a MUCH better view of photosphere / action near the edge of the solar disk. That alone would suggest skipping the shadow bands this time.
I would try and go as far west as possible so that the sun is as high above the horizon as possible. Of course one would want to be close to the center line ... which becomes critical on
short annular events like this one.
Of course, a ''the deep annular-like conditions'' of the Venus transit do not permit one to do this. :-)
> (did you see that one?)
1998 was a wonderful eclipse.
I do not see every Eclipse. I'm trading the 08 Apr 2005 Solar Hybrid for the 8 June 2004 Venus transit for example.
Since you live in Ecuador, I would encourage/urge you to travel to the coast and see the Hybrid eclipse (part Annular / part Total). My calculations show that it will be very close to total along the center line in South America. It is worth while to see the Sun in annular mode once in a while.
Not only do I get to see amazing astronomical events, while I am there I travel around and see wonderful and interesting parts of our own planet!
To pay for my vacations to these selected events, I have established travel investment funds (setup many years in advance) for:
I also keep an emergency fund that allows me go anywhere in the world at a moments notice to see a Supernova bright enough seen with the naked eye. I had such a fund in place which allowed me to rush from California to Australia some 21 hours after the discovery of 1987A (24 Feb 1987).
Maybe next naked eye supernova viewable in my hemisphere. But if not, I have another supernova fund ready ...
I first learned about the Transit of Venus, in the early summer of 1970, during a Morrison Planetarium program of the California Academy of Science. At the age of 9 I decided that I wanted to see next transit.
I have waiting patiently for 34 years to make my transit observations. It is now only a few dozen days away!!!
Yes, Quantum Cryptographic Communications (QCC) can help with the requirement that the one-time pad must be transmitted in private. However the one-time pad cannot be reused so your key must be the same size as your text. Thus far, Quantum Cryptographic Communications is not a speedy high bandwidth form of communication. It might be OK to transmit a small key but to date it is not OK for sending, in a reasonable period of time, huge one-time pad keys that are as big as your original message.
Another thing people sometimes gloss over about Vernam one-time pads is that your cipher is only as good as your random number generator! If you generate your one-time pad using the v7 libc rand(3) function your one-time pad is next to useless.
Another important aspect of Quantum Cryptography (Quantum Cryptography is not simply limited to communications) is random number generation. Quantum Cryptographic Random Number Generation (QCRNG) is a useful tool in generating keys (one-time pads, block cypher keys, public/private key pairs, etc.).
The importance of QCRNG goes beyond Vernam one-time pads. You want a cryptographically strong RNG such as a QCRNG when you generate your session keys. Sending predictable keys over a QCC protected link is next to useless!
Now IF you have:
then you will begin to approach the ''unbreakable cypher level'' that some people think you get with Vernam One-Time Pad Ciphers.