Slashdot Mirror

Because he failed to give any links...

http://www.lavarnd.org/ - Was the site linked in story below, but is now dead

Sourceforge: http://sourceforge.net/project...

http://slashdot.org/story/03/0...

I think it is past time for CPUs to provide hardware random numbers. Via CPUs have done this for years, but Via CPUs are just too slow for most uses. (I used to run my mail server on a Via C3... I am a lot happier now that my server runs on an AMD low-power dual-core.)

Recent Intel chips do have some sort of random number generator (RdRand).

Hardware RNG accessories are available but expensive.

There is the LavaRnd project, which I think is really darn cool. However, I downloaded the source code, and it hasn't been updated since 2003... a decade later, GCC won't even compile the code. (GCC now issues warnings about some of the code and they set the "treat warnings as errors" flag. I didn't experiment with disabling that flag and trying the code out.) Also, the supported hardware list is a short list of decade-old webcams.

(Note: this would be a good project for a high school student or college student who knows C: update LavaRnd so it builds with GCC or Clang, get it working with at least one currently-available webcam, and write a report about it.)

The Raspberry Pi has a hardware RNG as part of the system-on-a-chip, and Linux on the Pi supports it. You could set one up as a randomness server to your VMs, and that would be quite inexpensive. At least the VMs could reseed their PRNGs with random values pulled from the Pi.

http://vk5tu.livejournal.com/43059.html

If you have a sound device, Audio Entropy Daemon may work.

http://www.vanheusden.com/aed/

P.S. Haveged looks interesting... I just discovered it and I don't know how well it actually works.

https://www.digitalocean.com/community/articles/how-to-setup-additional-entropy-for-cloud-servers-using-haveged

I linked to LavaRnd in a reply to an earlier post, but at the risk of being redundant, I'll mention it again.

For real security you need specialized hardware devices.

Yep. I think it's about time to hook up the ol' lava lamp.

It's an unreasonable idea. First, it requires a reliable Internet connection. Second, the NSA could monitor the traffic, plant back doors in the server, or otherwise compromise an in-the-cloud solution.

Much better would be a hardware source of randomness, connected to your server, and under your direct control.

Why not get a cheap webcam and set up your own LavaRnd? There, true random data available to your computer even at boot time.

http://www.lavarnd.org/what/how-good.html

LavaRnd has Linux kernel drivers, and it will drop right in and Just Work.

I'll donate $1000 towards costs if the idea is viable.

You could buy a lot of cheap webcams for $1000.

'Every minute a new impossible thing is uploaded to the internet and that improbable event becomes just one of hundreds of extraordinary events that we'll see or hear about today,'

The principle of generating small amounts of finite improbability by simply hooking the logic circuits of a Arduinopentamillenuova-5007 Sub-Microcontroller to a Markov chain generator driven by a strong RNG (say, a nice lava lamp and a photodetector) were of course well understood - and such generators were often used to acquire a first round of venture funding by photoshopping all the pixels in the hostess's undergarments simultaneously one foot to the left, in accordance to the theory of Rule 34.

Many respectable developers said that they weren't going to stand for this, partly because Web 2.0 was a debasement of technology, but mostly because they didn't get hired by those sorts of startups.

Another thing they couldn't stand was the perpetual failure they encountered while trying to construct a machine which could generate the infinite improbability field needed to propagate a meme across the bandwidth-draining distances between the farthest minds, and at the end of the day they grumpily announced that such a machine was virtually impossible.

Then, one day, an intern who had been left to sweep up after a particularly unsuccessful startup found himself reasoning in this way: If, he thought to himself, such a machine is a virtual impossibility, it must have finite improbability. So all I have to do in order to virtualize one is to work out how exactly improbable it is, feed that figure into the finite improbability generator, give it a fresh round of really hot funding... and turn it on!

He did this and was rather startled when he managed to create the long-sought-after golden Infinite Improbability generator. He was even more startled when just after he was awarded the Y Combinator 2013 Prize for Extreme Agility, he was lynched by a rampaging mob of respectable developers who had realized that one thing they couldn't stand was a smart-ass.

Well, he is using MacOS. If he were using a real operating system, he might have access to more authentic random numbers from /dev/random.

But what an incredibly ugly hack. If it's so damned important to you, just buy a $20 USB-FM receiver, tune into the cosmic microwave background, and record and hash the audio stream from that. Or point your webcam at a bubbles generated from a fish-tank bubbler and hash the video stream. There are so many easy ways to get moderately random numbers, that would certainly be much more random and easier to program than parsing the not-so-random stuff from tcpdump.

He probably never even bothered to query Google for natural sources of randomness, or he may have run accross LavaRnd.

Please, everyone, don't even think about taking TFA seriously.

Method that doesn't involve cat poo

The Eiffel tower hasn't changed that much in the past 110 years... The MIT (IIRC) used to have a random data feed generated from a webcam and a lava lamp. I guess each datacenter ought to invest in a lavalamp...

Correction : after a quick Google, it seems that it was SGI, and that they actually patented the thing (which may or may not mean something depending on your jurisdiction). The site was (and still is apparently) lavarnd.org.

Actually, it does. I was just reading about this from another link in a comment hereabouts.

heh, I actually linked to the wrong lava lamp random number generator, but after clicking around the site, I decided that this one was better, though no actual lava lamps were harmed in the creation of this rng.
so again: http://www.lavarnd.org/

I like the lava lamp rng
http://www.lavarnd.org/

His point was that that's what his excuse would be for the presence of "too-random" data on his computer. I'm not convinced it would be all that successful though, because /dev/urandom isn't a real file: when you "read" from it the kernel just generates [pseudo-]random bits on-the-fly.

Sometimes I want to build myself a lava lamp random number generator just to have a plausible excuse for storing big "random" files.

It is not at all hard to get true pure randomness into your computer.

Despite the fact calculating all of the ranges you claim would make it 'easy' would in fact take computers a few million *ORDERS OF MAGNITUDE* more powerful than what exists today to even finish before you die, but there are simple cheap easy ways (Or if you prefer, expensive) to generate true randomness.

http://inventgeek.com/Projects/alpharad/overview.aspx
^- Based on alpha particle decay using materials found in a home smoke detector and a ccd camera

http://www.uelectronics.info/true-random-number-generator
^- Based off using white noise in an area from a specific angle

http://home.comcast.net/~orb/details.html
^- A built it yourself on a PIC version that uses the outside tolerance levels of capacitor charging.

http://www.lavarnd.org/
^- Uses a lava lamp and snapshots to essentially capture the current state of a highly complex chaotic system that would need to be duplicated down to the molecular level to 'run' and get anywhere near the same output (aka, not possible until star trek is no longer fiction)

Do you mean to say you still aren't using a true hardware random number generator at home?!

-- Dissy

I see that one of the chips in question is for a random number generator. Despite providing documentation/specs on how this chip runs, to make it possible to write free drivers, it's not the same as having the actual source code for the chip. With any other type of chip this would be well and good, but with random number generators, you can't really test them, and will need to rely on examination of the source code to prove that it works. Even then, it would not be that easy --see the Underhanded C Contest of 2007 in which people write encryption programs, and they work, and the source is open to inspection --and they STILL provide a back door to allow the encryption to be broken. (Man, that Underhanded C Contest is pretty scary.)

I hope the kernel developers and other programmers give us a choice whether to use random numbers from the Padlock chip or from some other source. Me, I'll just plug in my blinded webcam into my USB port and multiply it into any random stream for good measure.

If they really want something random, they should invest in some funky lighting for their server room...

How is the key generated? Even "random" is typically not truly random.

It's extremely easy, actually. In fact, I think some Intel chips include a RNG based on thermal noise (Johnson noise). In the absence of that, there's always the Lava Lamp.

Seriously though, there are plenty of physical processes which are completely random, and which are very easy to use to generate true randomness. The spin of incoherent photons is random, and measurable. The time between decays of radioactive nuclides is random and measurable. The instantaneous power spectrum of the white noise of waves breaking on the beach is random and measurable.

lavarand

A similar LGPL implementation: LavaRnd

Atmospheric noise
Lava lamps
Radioactive decay
Entropy

In the late 90's I was part of a team that was hacking Lava Lite (R) lamps. We built a system that converted SGI Indycam (digital camera) images of Lava Lites into cryptographic seeds of a pseudo-random number generator. And while classic lavarand has been replaced by LavaRnd (directly generating random numbers using lens capped webcams), it remains one of my favorite hacks / creations.

Let's not forget that microprocessors aren't capable of generating true randomness. An external source of entropy is required, such as a Lava Lamp, decaying Cesium-137 atoms, or something else..

Now, I gotta say it would be pretty cool if these iPods use a vibration-sensing mechanism to gather enough entropy to seed the PRNG!

--Weasel

They used this tool to write the article: http://www.lavarnd.org/cgi-bin/corpspeak.cgi

        To: All slashdotters
        From: Your Boss
        Date: Sat Aug 26 07:07:03 2006
        Subject: Important Announcement

                  Surely, we can conclude that the drop dead dates indicate that the resource will knock your socks off. Allowing widely-distributed multiple-sourcing. So, a quality-oriented merger restores. Our company must balance killer apps in a number of areas in a way that maximizes technological a technological culture change.

                  During this period of company transition, the killer apps provide an indication of the execution. If we can foresee the benefits of the multimedia culture changes, then the ISP will assure us the super-scalar products. The diverse strategic and tactical actions foster multimedia supercorridor, which was outlined recently on our internal Web site.

                  Surely, we can conclude that the market realignment indicate that a Windows-compliant alliance takes the initiative. The professional tangent coordinates market-driven scalable shared memory multiprocessor. We will boldly take over the high-impact market for visual computing.

                  The staffing e-mail achieves a new leadership skills. We absolutely have to develop the compatible information superhighway as well. The seven-habits-conforming standards outsource multimedia supercorridor, on a going-forward basis.

                  We have been looking into the UI. If we can foresee the benefits of 3-D, then multimedia will assure us super-scalar neophytes. We are pleased to announce that massively parallel methods of empowerment interface with the growth years.

                  Now that the merger is complete, time frames are not going to customize. Due to the based missions and the product lines, what has changed is the pace of change. We will long-term kick this idea around.

                  In order to obtain annotation, we took a close look at the win-win parameters to understand what they mean. I think that the next step has possibilities for future technical advances. We are ahead of the sponsorships curve.

This has actually been done, using the fluctuations of lava lamps as a photon seed. http://www.lavarnd.org/

This project seems to work well... http://www.lavarnd.org/

This was a cipher called Solitaire, which was created by Bruce Schneier. It has been horribly broken.

What they need to do is fire up a dubbie and get one of these.

One that doesn't require a telescope: http://www.lavarnd.org/

The coolest random number generator ever.

http://www.lavarnd.org/

As rjh also pointed out, the ANSI-X9.17 pseudo-random number generator (a 3-DES based PRNG) is a high quality PRNG. So if you lack a good hardware random source, or if your hardware random source cannot deliver quality values fast enough for your purposes, then the ANSI-X9.17 might be your next best choice.

As rjh also pointed out, the ANSI-X9.17 pseudo-random number generator (a 3-DES based PRNG) is a high quality PRNG. So if you lack a good hardware random source, or if your hardware random source cannot deliver quality values fast enough for your purposes, then the ANSI-X9.17 might be your next best choice.

As rjh also pointed out, the ANSI-X9.17 pseudo-random number generator (a 3-DES based PRNG) is a high quality PRNG. So if you lack a good hardware random source, or if your hardware random source cannot deliver quality values fast enough for your purposes, then the ANSI-X9.17 might be your next best choice.

As rjh also pointed out, the ANSI-X9.17 pseudo-random number generator (a 3-DES based PRNG) is a high quality PRNG. So if you lack a good hardware random source, or if your hardware random source cannot deliver quality values fast enough for your purposes, then the ANSI-X9.17 might be your next best choice.

As rjh also pointed out, the ANSI-X9.17 pseudo-random number generator (a 3-DES based PRNG) is a high quality PRNG. So if you lack a good hardware random source, or if your hardware random source cannot deliver quality values fast enough for your purposes, then the ANSI-X9.17 might be your next best choice.

As rjh also pointed out, the ANSI-X9.17 pseudo-random number generator (a 3-DES based PRNG) is a high quality PRNG. So if you lack a good hardware random source, or if your hardware random source cannot deliver quality values fast enough for your purposes, then the ANSI-X9.17 might be your next best choice.

I always enjoyed the SGI's use of lava lights. There's an open source implementation available, that was mentioned previously.

If you need entropy on the cheap check out LavaRnd. LavaRnd uses a low cost off the shelf "webcam" with it's lens cap in place as a random number generator.

http://www.lavarnd.org/news/lavadiff.html

Lava Lamps:
http://www.lavarnd.org/what/index.html

So has anyone linked their iPod with a lava lamp random number generator (e.g. LavaRnd.org) to see if it picks better random songs?

There are some quality random number generators on the Internet like Random.org, HotBits, and Lavarnd. But to be technical, their numbers come from background radio noise, radioactive decay, and lava lamps (er, "Lava Lite lamps"), meaning they don't truly generate it on the chip.

I don't know what is in the boxes they are using, but the http://lavarnd.org/ project is a high quality randon number generator you can easily build.

"Random Number Generator". That is a very dubious statement. You see, computers can never be truly random. Whenever a computer generates anything random, it isn't truly random but pseudorandom. When a computer generates a sequence of random numbers, it is based on a random seed, which goes through several math processes. Eventually, this sequence will repeat itself. Even the most advanced so-called random number generators repeat themselves after millions of digits. Computer randomness is never true randomness, and that's why chaotic systems and quantum randomness is so applealing to computer security: Because these things are much more "truly" random. Example: LavaRnd (http://www.lavarnd.org/what/index.html) Considering that the article says that the machine 's chip is "no more complex than the ones found in modern pocket calculators", I find it hard to beleive that this machine is actually random, so even if you don't consider all the other evidence for why this is a hoax, you see that there is a fundemental flaw with this whole theory in the first place.

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 ...

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:

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?

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:

" 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?

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:

" 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?

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:

" 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?

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:

" 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?

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