The OP is somewhat mistaken about entropy sources within a modern system. A modern OS implementation keeps a record of the number of shannons of entropy available in the/dev/random pool and only allows that amount to be taken out. The/dev/urandom pool simply allows the user to continue removing bits of data when there are no shannons of entropy left in the pool. The only way to acquire more shannons of entropy to fill the/dev/random pool (and hence provide a way for/dev/urandom pool to also acquire more) is to have a physical source of truly random nature. Such sources can include the timing information of key presses which introduce fractions of a shannon of entropy but network activity of any type is disturbingly periodic, hence such sources have largely been removed. If you want a true random number generator you need something like an Entropy key which uses physical quantum phenomena to generate many shannons of entropy continuously.
Hi all, it appears someone has slashdotted my bookshelf. Hope you got something useful from it:-)
A quick note that the original idea behind this was to assist some of our customers in the embedded arena by showing what books we used. Yes there are a number of "classics" missing (they were mostly on the shelf below;-) but the idea was for a representative "sample" not a definitive booklist. If I were to create such a list it would include at least
The Pragmatic Programmer by hunt
Code Complete by McConnell
Engineering mathmatics by K A Stroud
and the non programming books
A history of modern computing by Ceruzzi
The code book by Simon Singh (actually almost anything by Singh)
The victorian Internet by Tom Standage
Some people have noted they dont use their knuth much, personally I would often be lost without it, although there are many other good books on practical algorithms out there now (I am and old fart and years ago knuth was *it*;-)
Another reason ARM dont have too many people complaining about them is their designs go into some really inexpensive system on chip (SOC) devices.
So anyone wanting to play with the technology can have a development system really cheap like these (check out the tiny OKI modules) or even open source hardware like this
Historicaly when Acorn first created the ARM CPU even X86 had the 387, however as time went on and Acorn split off ARM they did develop a floating point co-processor (early ARMS had the co-processor bus exposed) the FPA10 and FPA11. Unfortunately these were not very popular and the emulated maths routines (done with unknown instruction aborts) were an adequate solution for most users. The only SOC device that *ever* had Floating point hardware was the 7500FE (99ukp dev board available from http://www.simtec.co.uk/products/EB7500ATX) this device can, even now, outstrip a 600Mhz XScale performing FPU operations. It would seem that the reason ARM CPUs do not usualy have a FPU is purely because of cost, emulating FP operations seems to be fast enough that most of the time the extra cost of the FPU simply is not justified.
Slashdot Mirror
The OP is somewhat mistaken about entropy sources within a modern system. /dev/random pool and only allows that amount to be taken out. /dev/urandom pool simply allows the user to continue removing bits of data when there are no shannons of entropy left in the pool. /dev/random pool (and hence provide a way for /dev/urandom pool to also acquire more) is to have a physical source of truly random nature.
A modern OS implementation keeps a record of the number of shannons of entropy available in the
The
The only way to acquire more shannons of entropy to fill the
Such sources can include the timing information of key presses which introduce fractions of a shannon of entropy but network activity of any type is disturbingly periodic, hence such sources have largely been removed.
If you want a true random number generator you need something like an Entropy key which uses physical quantum phenomena to generate many shannons of entropy continuously.
Hi all, it appears someone has slashdotted my bookshelf. Hope you got something useful from it :-)
A quick note that the original idea behind this was to assist some of our customers in the embedded arena by showing what books we used. Yes there are a number of "classics" missing (they were mostly on the shelf below ;-) but the idea was for a representative "sample" not a definitive booklist. If I were to create such a list it would include at least
- The Pragmatic Programmer by hunt
- Code Complete by McConnell
- Engineering mathmatics by K A Stroud
and the non programming booksSome people have noted they dont use their knuth much, personally I would often be lost without it, although there are many other good books on practical algorithms out there now (I am and old fart and years ago knuth was *it* ;-)
ARM Linux has had something similar in Kautobuild for some time.
Although the testing and building is limited to the ARM platform.
The site also has a whos who thats worh looking at ;-)
Another reason ARM dont have too many people complaining about them is their designs go into some really inexpensive system on chip (SOC) devices.
So anyone wanting to play with the technology can have a development system really cheap like these (check out the tiny OKI modules) or even open source hardware like this
I have had some good experience with Simtecs OKI module. I have only used this in the gold config but it seems to do its job.
Historicaly when Acorn first created the ARM CPU even X86 had the 387, however as time went on and Acorn split off ARM they did develop a floating point co-processor (early ARMS had the co-processor bus exposed) the FPA10 and FPA11. Unfortunately these were not very popular and the emulated maths routines (done with unknown instruction aborts) were an adequate solution for most users.
The only SOC device that *ever* had Floating point hardware was the 7500FE (99ukp dev board available from http://www.simtec.co.uk/products/EB7500ATX) this device can, even now, outstrip a 600Mhz XScale performing FPU operations.
It would seem that the reason ARM CPUs do not usualy have a FPU is purely because of cost, emulating FP operations seems to be fast enough that most of the time the extra cost of the FPU simply is not justified.
The Remote Imaging Group is the place to go for information on all aspects of this hobby.