User talk:Felice/Our software: Difference between revisions
(New page: = What software will be used with the $100 laptop? = === FreeDOS === Any plans of a FreeDOS alternative or to drop GNU/Linux completely? FreeDOS is very effective and small. It is open s...) |
(→Tools) |
||
Line 22: | Line 22: | ||
:FreeDOS should run just fine in Bochs on the AMD Geode chips being used. It would make more sense to leave the base machine alone and just run FreeDOS from a USB key containing Bochs and a disk image. That way you make the machine more useful because you aren't subtracting any of the core package and capabilities. |
:FreeDOS should run just fine in Bochs on the AMD Geode chips being used. It would make more sense to leave the base machine alone and just run FreeDOS from a USB key containing Bochs and a disk image. That way you make the machine more useful because you aren't subtracting any of the core package and capabilities. |
||
=Tools= |
=Tools= |
||
=== Random generator entropy === |
|||
Hi, we came up with this issue at the 23c3 in a lecture about the /dev/(u)random generator in Linux. The algortihm gets most of its entropy from the harddisk. Because the OLPC lacks a hdd, this could be an issue, when you need a random number for cryptography at boot time. Of course the algorithm is still strong and sufficient enough for most applications (or at least i think so), but not as good as some people maybe think. (Other entropies: camera, microphone,...) (DustyDingo) |
|||
:Your question is confusing, as I'm not versed in random number generators based on hard disk... Isn't the built in Flashdrive good enough? It acts like a conventional hard drive, but it's all memory. --[[User:Jcfrench|Jeff]] |
|||
::No, the flash is not good at all. Hard drives have unpredictable timing, and thus the kernel uses them to supply /dev/random data. The DCON chip really should be modified to include a random number generator that works based on electrical noise such as the thermal stuff in a semiconductor junction. (note: NOT a pseudorandom number generator) [[User:24.110.145.57|24.110.145.57]] 19:40, 27 February 2007 (EST) |
|||
:::Hmm... Chaos Communication Congress... OK! So you are looking for a way to seed a random number generator from an on board OLPC component (mostly for cryptography a boot time). OLPC doesn't seem to prioritize encryption as a core value (it seems to go against the BitFrost mantra of transparency). That said, you've got a pair of WiFi like transmitters, a monitor, keyboard, touchpad, battery, etc. Does hard drive access time really provide an evenly distributed random number? I find that hard to believe. Also, is this topic really critical to the goals of OLPC as a project? --[[User:Jcfrench|Jeff]] |
|||
::::The very first thing an OLPC XO does is generate a long-term public/private key pair. All the over-the-air stuff is at least cryptographically signed. If a kid publishes a Sugar XO bundle, it gets signed with his key. Hard drives are decent; the fast-moving air inside the drive provides randomness. The WiFi may be a tolerable choice; it's both public and subject to lack of input though. The monitor is no good. The keyboard and touchpad are OK, though very slow. The battery is unlikely to help. The digital camera may be the best choice. The microphone is tolerable. Use of many of these devices will require lots of power and/or background daemons. It's just way easier to do as Intel did with their motherboard chipsets. VIA put a random number generator right in the CPU. [[User:AlbertCahalan|AlbertCahalan]] 22:14, 28 February 2007 (EST) |
|||
:::::This is a serious issue. There's a paper on the quality of the linux kernel RNG, and how it has relied on obscurity. When people wanted to find out how it works, they got no help from the developers; after analyzing it, they found serious weaknesses, and published. |
|||
:::::http://www.pinkas.net/PAPERS/gpr06.pdf |
|||
:::::In a nutshell: |
|||
:::::# Linux RNG is overly complicated, and could be made much simpler at no loss of quality if a random source is available. |
|||
:::::# Linux RNG is predictable with no random source |
|||
:::::# A "must" for diskless systems is to save the RNG state across shutdown/bootup. At the very least, each laptop should ship with a 512 byte file fetched from random.org (or similar) so that they can initialize to an unknown state on first boot. |
|||
:::::# Instead of using the linux RNG, perhaps consider a better one. Apple claims that its RNG -- "Yarrow" -- is better than Linux's, however it warns that a lack of random input will degrade it without warning (versus linux's estimate of entropy remaining in the main pool). |
|||
:::::I do **REALLY** hope that this is fixed before any "for end user" machines are shipped. --[[User:Keybounce|Keybounce]] 21:36, 31 March 2007 (EDT) |
|||
::::::It is a serious issue, but that stuff about Yarrow being better is wrong. People get recognition by publishing alarmist "research" about supposed defects in important software. The Linux developers have little time to help clueless people who won't study the history behind the Linux /dev/random and /dev/urandom devices. Yarrow has one feature of dubious value: it recovers quickly from an attacker who somehow exposes the content of the pool. If an attacker can do that, you have bigger issues to worry about because the attacker is reading your kernel memory! Yarrow does have two weaknesses. First, it assumes that there will not be a successful attack against the cryptographic operations it uses. The Linux /dev/random and /dev/urandom instead assume that such attacks will be somewhat successful, and thus does not depend greatly on the cryptographic operations being unbreakable forever. Second, Yarrow fails to track entropy. Even if no data goes into the pool, you can pull infinite data out. This makes Yarrow a pseudo-random number generator. Linux makes a conservative estimate of the amount of true randomness available in the pool and will cause /dev/random to block (stall) if there is not enough available. [[User:24.110.145.57|24.110.145.57]] 00:26, 1 April 2007 (EDT) |
|||
The AMD Geode LX processor includes a hardware random number generator. Linux's /dev/{u,}random uses it to seed the entropy pool. Also, keyboard and trackpad input are used to add to the entropy. There should be few issues with the quality of the random numbers. |
|||
::Look at the [[Measure]] activity - it reads unbiased voltage data from the audio in port. I don't know how sensitive the a/d on that is, but if it's sensitive enough to get some random noise when there's no mic attached, this would be an excellent, constant source of random data (I saw an article once arguing that a noisy a/d is either brownian motion - which has quantum input from molecular vibration modes - or direct quantum tunelling of electrons in the chip. Quantum random = gold standard.). I don't know if there are Bitfrost/Raibow issues with accessing this port - I think that's only for the physical mic, not the port. --[[User:Homunq|Homunq]] 11:06, 24 September 2007 (EDT) |
|||
=== OLPC on a disk? === |
=== OLPC on a disk? === |
Revision as of 18:29, 26 October 2007
What software will be used with the $100 laptop?
FreeDOS
Any plans of a FreeDOS alternative or to drop GNU/Linux completely? FreeDOS is very effective and small. It is open source. Greowsigbwoe
- No plans to drop GNU/Linux, although we expect that some children will want to experiment with other operating systems. --Walter 15:00, 23 September 2007 (EDT)
- So it will only be possible if they download them selves? And how will they be able to boot and install? The laptop have neither CD-ROM or floppy drives. Greowsigbwoe
- Is FreeDOS preinstalled not even an possible alternative to you? Greowsigbwoe
- They'll be able to boot from an SD card or USB. --Walter 15:33, 23 September 2007 (EDT)
- I have heard that LinuxBIOS can not boot DOS, but OK. You have not answered if the company might consider FreeDOS preinstalled. Greowsigbwoe
- We are not using LinuxBIOS. We are using Open Firmware as our bootloader. OFW does not emulate all the legacy PC hardware you'd need to run DOS, e.g., VESA (since the VESA emulation code in AMD's Geode VSA was the one part they could not open source due to not owning rights), and the PCI configuration emulation code (which gets in our way for fast resume). There are third parties working on a BIOS for the machine but there is a fair amount of driver work required, e.g., DCON. As far as whether or not we would consider FreeDOS preinstalled, if there is sufficient demand for it and it enables us to meet our epistemological goals, then yes. --Walter 15:52, 23 September 2007 (EDT)
- I have heard that LinuxBIOS can not boot DOS, but OK. You have not answered if the company might consider FreeDOS preinstalled. Greowsigbwoe
- I hope there will be someday. But i am not so sure, GNU/Linux is taking over almost everything. From big mainframes to these laptops. Thank you for your answers. Greowsigbwoe
- DOS knows nothing of PCI, so the emulation code is not needed. DOS programs generally don't care either. DOS also doesn't need VESA, but many DOS programs do need it. DOS certainly needs a pile of BIOS calls, but these could be built right into FreeDOS. (in other words, hack FreeDOS to boot from OpenFirmware and supply its own BIOS crud) DOS also needs a text mode video screen; this would be difficult but possible. AlbertCahalan 17:18, 23 September 2007 (EDT)
- One of the emulators is probably a better choice. It could even be wrapped up as a Sugar activity. If the emulators shipped with the OS itself, then one might be able to write DOS-based activities that are thin wrappers around DOS programs. Maybe there could be an easy way to share DOS disk images, much like TamTam projects can be shared. AlbertCahalan 17:18, 23 September 2007 (EDT)
- FreeDOS should run just fine in Bochs on the AMD Geode chips being used. It would make more sense to leave the base machine alone and just run FreeDOS from a USB key containing Bochs and a disk image. That way you make the machine more useful because you aren't subtracting any of the core package and capabilities.
Tools
Random generator entropy
Hi, we came up with this issue at the 23c3 in a lecture about the /dev/(u)random generator in Linux. The algortihm gets most of its entropy from the harddisk. Because the OLPC lacks a hdd, this could be an issue, when you need a random number for cryptography at boot time. Of course the algorithm is still strong and sufficient enough for most applications (or at least i think so), but not as good as some people maybe think. (Other entropies: camera, microphone,...) (DustyDingo)
- Your question is confusing, as I'm not versed in random number generators based on hard disk... Isn't the built in Flashdrive good enough? It acts like a conventional hard drive, but it's all memory. --Jeff
- No, the flash is not good at all. Hard drives have unpredictable timing, and thus the kernel uses them to supply /dev/random data. The DCON chip really should be modified to include a random number generator that works based on electrical noise such as the thermal stuff in a semiconductor junction. (note: NOT a pseudorandom number generator) 24.110.145.57 19:40, 27 February 2007 (EST)
- Hmm... Chaos Communication Congress... OK! So you are looking for a way to seed a random number generator from an on board OLPC component (mostly for cryptography a boot time). OLPC doesn't seem to prioritize encryption as a core value (it seems to go against the BitFrost mantra of transparency). That said, you've got a pair of WiFi like transmitters, a monitor, keyboard, touchpad, battery, etc. Does hard drive access time really provide an evenly distributed random number? I find that hard to believe. Also, is this topic really critical to the goals of OLPC as a project? --Jeff
- The very first thing an OLPC XO does is generate a long-term public/private key pair. All the over-the-air stuff is at least cryptographically signed. If a kid publishes a Sugar XO bundle, it gets signed with his key. Hard drives are decent; the fast-moving air inside the drive provides randomness. The WiFi may be a tolerable choice; it's both public and subject to lack of input though. The monitor is no good. The keyboard and touchpad are OK, though very slow. The battery is unlikely to help. The digital camera may be the best choice. The microphone is tolerable. Use of many of these devices will require lots of power and/or background daemons. It's just way easier to do as Intel did with their motherboard chipsets. VIA put a random number generator right in the CPU. AlbertCahalan 22:14, 28 February 2007 (EST)
- This is a serious issue. There's a paper on the quality of the linux kernel RNG, and how it has relied on obscurity. When people wanted to find out how it works, they got no help from the developers; after analyzing it, they found serious weaknesses, and published.
- In a nutshell:
- Linux RNG is overly complicated, and could be made much simpler at no loss of quality if a random source is available.
- Linux RNG is predictable with no random source
- A "must" for diskless systems is to save the RNG state across shutdown/bootup. At the very least, each laptop should ship with a 512 byte file fetched from random.org (or similar) so that they can initialize to an unknown state on first boot.
- Instead of using the linux RNG, perhaps consider a better one. Apple claims that its RNG -- "Yarrow" -- is better than Linux's, however it warns that a lack of random input will degrade it without warning (versus linux's estimate of entropy remaining in the main pool).
- In a nutshell:
- I do **REALLY** hope that this is fixed before any "for end user" machines are shipped. --Keybounce 21:36, 31 March 2007 (EDT)
- It is a serious issue, but that stuff about Yarrow being better is wrong. People get recognition by publishing alarmist "research" about supposed defects in important software. The Linux developers have little time to help clueless people who won't study the history behind the Linux /dev/random and /dev/urandom devices. Yarrow has one feature of dubious value: it recovers quickly from an attacker who somehow exposes the content of the pool. If an attacker can do that, you have bigger issues to worry about because the attacker is reading your kernel memory! Yarrow does have two weaknesses. First, it assumes that there will not be a successful attack against the cryptographic operations it uses. The Linux /dev/random and /dev/urandom instead assume that such attacks will be somewhat successful, and thus does not depend greatly on the cryptographic operations being unbreakable forever. Second, Yarrow fails to track entropy. Even if no data goes into the pool, you can pull infinite data out. This makes Yarrow a pseudo-random number generator. Linux makes a conservative estimate of the amount of true randomness available in the pool and will cause /dev/random to block (stall) if there is not enough available. 24.110.145.57 00:26, 1 April 2007 (EDT)
The AMD Geode LX processor includes a hardware random number generator. Linux's /dev/{u,}random uses it to seed the entropy pool. Also, keyboard and trackpad input are used to add to the entropy. There should be few issues with the quality of the random numbers.
- Look at the Measure activity - it reads unbiased voltage data from the audio in port. I don't know how sensitive the a/d on that is, but if it's sensitive enough to get some random noise when there's no mic attached, this would be an excellent, constant source of random data (I saw an article once arguing that a noisy a/d is either brownian motion - which has quantum input from molecular vibration modes - or direct quantum tunelling of electrons in the chip. Quantum random = gold standard.). I don't know if there are Bitfrost/Raibow issues with accessing this port - I think that's only for the physical mic, not the port. --Homunq 11:06, 24 September 2007 (EDT)
OLPC on a disk?
Just heard about the Give 1 Get 1 program, which sounds great, but i wonder if there aren't many in North America who would appreciate a kid-friendly computing environment for whom $400 is a bit much to spend, especially if they already have access to conventional hardware.
I haven't analyzed the pros and cons thoroughly but the following question occurs to me:
Would it be practical to create a knoppix-style live CD version of the OLPC environment (or a useful subset) that would run on generic hardware and use it as a fund raising device? an automated site could permit downloading disk images and assertively request a donation . (as it's open source you can't charge a licensing fee, but requesting a donation is probably OK.)
Donations could then be used to subsidize the cost of distributing the complete machines where they are needed.
Many folks already have kid-unfriendly PCs at home. others have access to hand-me down or refurbished hardware incapable of hosting contemporary grown-up computing environments but that would probably work OK with the OLPC software. making a $25-$50 donation and getting an OLPC-like environment on disk might be an easier sell in such cases than a $400 expenditure.
As a side benefit, such a project might permit experimenting with expanding the target audience for the software. there are folks other than young children who might benefit from a more approachable computer. (the elderly, adults with special needs, etc.) frankly, in some respects this may be a better general purpose computing environment than some of the fatter mainstream ones.
Also, getting the software in broader use in developed countries might preclude any stigma connected with the idea of a special product for the poor. it could change the OLPC hardware from an specialty computing system just for the poor to a specialty platform for hosting a software environment that is popular among the affluent.
(As the software is open source presumably it's already possible for somebody to do this independently and perhaps somebody will. this might be benefit the project by popularizing the software, but it wouldn't help the project raise funds. might be good to get there first.)
- Right, poverty is right here in the USA. $399 is no good for the kids of a West Virginia coal miner or truck stop waitress. These kids often have just one practical option for getting out of poverty: join the military. $100 might work, barely.
Content
Server
Security
Networking
access of offline content with browser
I am interested to see some of my html content on the OLPC before the content is uploaded. My content is on flash disk. I managed to mount the Flash Disk using the shell. Then I tried to use the browser in the sugar interface to access my index.html file from the Flash Disk. But, so far, all I got is error message. I need your guide.
- What is the error message? Crazybus 07:32, 28 July 2007 (EDT)
Page Load Error is the message. I am just trying to access an html file from my flash disk with out being connected to the internet. I used the path to my html file in place of URL.