Talk:System software

From OLPC
Revision as of 08:29, 25 July 2006 by Memracom (talk | contribs) (Light-wight scripting language (Lua?))
Jump to: navigation, search

The following was removed from the main page since it seems more appropriate for the Discussion.

Operating System Selection

I would like to seriously question using Linux as the basis of the laptop. It's a path of constant tweaking and tuning. Linux is also further away from the "pure" microkernel architectures than the BSDs. In short Linux is like a F1 tuned for racing - but not as reliable. When working on a familiar hardware platform the BSDs become very robust and nice platform to work with. And more importantly without the horrible quality problems of the Linux kernel. FreeBSD kernel is also magnitudes more secure - it just is cleaner and better thought and developed with the focus first on stability and reliablity. Unlike Linux.. The bottom line is that the project has got the possibility to choose from others than just Linux as well. I'd go for Frisbee or mentioned reasons but there are others too.

  • (While I agree that *BSD might be a better option -- perhaps OpenBSD in particular for reasons of stability, et cetera -- I think the disparaging remarks about Linux-based operating systems were poorly conceived, exaggerated, and unnecessary as presented. - Chad Perrin)
  • Indeed: BSD is a good alternative. Another alternative may be an older Linux kernel. The 2.4 kernel line is pretty stable and good also. The current Linux kernel version is 2.6
  • (User-contributed) Yes, the older the Linux kernel is, the more stable it becomes. For example, the current 1.08 version of PuppyLinux is based on the 2.4 kernel, and can confidently deliver satisfactory GUI experience despite the resource constraints in the OLPC machine.
  • BSD is just as monolithic as Linux is, and the reverse - and their developers target reliability and security just as much as others, proved by millions of servers running it and some big companies wasting lot of engineering resources in making it even more stable (for example Linux distros are already shipping advanced security frameworks like SElinux, while FreeBSD (not openbsd) is still working on it)


Why UNIX(like) at all?
Recently Negroponte stated that a "slimmer Linux" is needed for the $100 laptop. Like others here, I question why it has to be Linux. But I'll take that notion even further: Why does the OS even need to be Unix or a Unix work alike? Why is Negroponte so bent on Linux? There are other FOSS options that are much more focused on the desktop, yet still have Posix compliance.

  • Haiku-OS is an FOSS implementation of the BeOS tool kits with a FOSS kernel. It maintains binary and source level compatibility with BeOS R5, so all pre-existing free R5 software will work on it. (There is quite a bit)
  • Syllable OS Is a lot like BeOS. (But it's not BeOS) It's getting pretty mature.

Both these options are FOSS. If you really want the Unixy goodness, both also happen to have Posix compliant shells, so much of the Unix CLI stuff is portable. Both have fast native GUI systems and very modern design behind the internals. Both are extremely light weight compared to BSD or Linux + X + desktop env. And if one was really concerned with the stability of the kernel, it might be possible to run one of these alternative environments on top of a BSD or Linux kernel instead of their native kernels.

  • Why UNIX(like)?: What is the point of running a non-Unix kernel just to run Unix software using compatibility layers? A Unixy operative system will make things much easier (POSIX is native there and software is already running there and it's the main development platform) and will allow developers to concentrate on more serious issues like ram usage.

It might also be possible to buy out the BeOS R5 codebase from Palm Inc. or have them donate it to the project. They don't seem interested in doing anything with it. Then the OLPC project could release the the source under GPL and get help from the Haiku and Yellow Tab guys to whip it into shape for the $100 laptop. I really can't convey how great BeOS or Haiku would be project. It's a perfect match for a system with the $100 laptops specs.


The need for a distributed OS

The deployment environment is a school, not a business. So it needs cheap, easy system administration above all, as well as painless system integration. It would also be good if it distributed the file system so the spare storage on the laptops can be aggregated.

The logical choice is Plan 9. Plan 9 is open-sourced, designed for graphics, lightweight, network-centric, has a UNIX api (glued on the side, but it's there), and is designed to integrate and implement distributed file systems. It should be easy to aggregate the file systems of many laptops just by merging their name spaces.

  • Recent Linux kernels already support the 9P protocol and per-process namespaces to some degree. While Plan9 is a beautiful operative system, its sadly more of a research OS than the real alternative that OLPC needs - most of the *nix software have never been ported and it doesn't gets ported by just pressing a button.

Peer to Peer distribution of books

This was copied from the main page since it is discussion. It should really be sumamrized into the main page and the first comment really should join the rest here.

I believe one of the most useful purposes of the laptop will be to distribute electronic text (i.e. e-books). The distribution of any information without a persistent network connection will be difficult. I imagine a situation where 1 out of 100 or 1000 kids may have access to a network connection. The peer to peer network could be used to distribute e-books from that single network connection to 1000 kids. I'd like to propose the design of a peer-to-peer network client designed specifically for this purpose.

A simple, graphical language-localized client would be designed to present a catalog of e-books. The client would pull down a listing of books available in a certain age-range for a targeted language. The student would pick texts that he or she has interest in. This list of requests would consist of a very small packet of data, perhaps a unique identifier of the device and a unique identifier of the text. When the device sees another device, it would off load it's packet to the peer device and vice-versa. Each device would contain a listing of requests from all of the peers that it came in contact with. The next time a device connects to the Internet, it would pull as many texts as allowable by pre-defined memory limits (say 3-5 meg). As the device comes into contact with other devices, it would deliver the texts to the other devices. Hopefully, over time, the requestor would be delivered some of the texts originally requested. As each text is delivered, a delivery or cancellation notice would be sent back through the peer network.

The peer to peer network should gather performance intelligence over time. It should be able to guess which routes have better chances of making a request and returning a delivery.

If a proof of concept proves to work well, the peer to peer network would be extended to handle two-way communication for interaction such as email or the submission and grading of assignments.

--65.7.133.163 04:41, 27 January 2006 (EST) Jason Hoekstra - jason@solexinc.com


To continue on with what Jason and Volburger said, there is a fundamental conflict in OLPC. On one hand, you need to keep costs down and must therefore have small persistent storage. On the other hand, the purpose of the laptop is for learning, and learning requires the storage of information. What a child needs to learn with is really nothing more than an encyclopaedia and a simple way to navigate it, but it is probably not feasible to store an entire encyclopaedia in the available space, especially if you include multimedia, which you definitely should.

The approach suggested by Jason, which is not a bad one at all, is to retrieve information based on interest. I have some experience in mobile, ad hoc, sensor, and peer to peer networking, and what he's proposing is something similar to rumor routing and directed diffusion. There are a couple of problems with the suggestion, though. The first is that you will likely have a lot more requests for books than space to keep them. In a store and forward network with limited space and unpredicatable mobility, you are unlikely to hang onto enough books that you will be able to satisfy the requests. The second problem is that in all likelihood, some children will have far more Internet access than others, due to geographical location, being able to afford transport, or whatever the case may be. This may form a book distribution tree rooted at a few children with many children as leaves, which will cause significant distribution problems. Basically, a few children will need to store and forward books for a large number of children, and will quickly fill up their space without satisfying many requests. This depends on the particular country and situation of course, but in general, the branching factor and depth of the distribution tree can have serious repercussions on how many of the requests are satisfied.

I personally agree with Jason that a distributed, peer to peer filesystem is necessary. You may only have half a gigabyte of space, but there are a lot of half gigabytes running around, hopefully within a few hops of each other. So step one is that you need a routing protocol to form multihop ad hoc networks. There is a lot of literature on this; look at MobiHoc if you need a starting point. Step two is that you need a discovery protocol to learn what books are available and who has them, the aforementioned catalogue. Note that this catalogue needs to be updated as well, but the updates can be distributed using controlled flooding. And the reason I'm writing this whole thing is that I think you need a decent data (book) dissemination protocol. You are dealing with a sparsely connected network of resource starved nodes, with intermittent connectivity and esoteric mobility patterns. I believe you need some sort of centralised logic, such as a tracker in the Bittorrent protocol. If the computers belonging to the children that have Internet access can cooperate on which books to download and store, and if the computers themselves can try to form a rough topology of who is connected to who (in terms of the books they want), then you are in a much better position to allocate your resources to satisfy the most requests.

I hope this helps and I wish you the very best of luck in your endeavours.

Emerson Farrugia (emerson AolpcT runelands D0T net) - March 17th, 2006

Automated Language Localization of some Preset Sentences

I have for some time been interested in whether it would be of practical use (rather than just fun in researching what can and cannot be done) to have a collection of sentences and part sentences defined and translated into many languages, each sentence or part sentence having a code number, with the idea that an author may construct a message using one such code number or a sequence of such code numbers and then the code numbers could be used by a software system in the computer of a recipient of the message in conjunction with a small database of code numbers and the text of the sentences in a chosen language so as to produce a localized message displayed for the recipient.

For example, suppose that there were only two sentences from which to choose and that these have been encoded as sentences 21011 and 21012.

The English database would contain the following.

21011 It is raining.

21012 It is snowing.

The French database would contain the following.

21011 Il pleut.

21012 Il neige.

The database could be translated into as many languages as desired and possible.

So, if someone whose preferred language is English is authoring a message and wishes to send the message "It is raining." then he or she looks throgh the database using whatever search tools that are available at his or her location and encodes the message as 21011 and then sends it.

So, if someone whose preferred language is French receives the message then the text "Il pleut." can be displayed automatically.

So, if there were more sentences than that and also sentences with a parameter such as for "The temperature here is P1 degrees Celsius." where the value of parameter 1 is sent as a digit string (possibly including a decimal point) to accompany the 21852 code of the parameterized sentence, and that list of sentences were available in many languages, then, for example, weather information could be broadcast on a pan-European basis on an interactive television channel and localized automatically in interactive televisions in, for example, England, France, Italy, Finland and Latvia.

As to how to encode such a system, well there are various possibilities. I started off using a deliberately unusual yet valid sequence of regular Unicode characters to act as a key that would be most unlikely to occur in any other use context, namely a comet, a circumflex accent and an enclosing keycap design. I have also looked at using Unicode Private Use Area characters. It has been suggested to me that XML would be the best approach, though I have reservations as I would like a system where a short sequence could be added into a plain text file without having to restructure the whole document, however I am unsure of that so it is possible that XML would be the way to go.

I am wondering whether the technique, whether using the key or the Private Use Area codes, or using XML, or otherwise, could be useful for autolocalizing some part of the education process. For example, a sentence such as "Please tell your teacher that you have now completed the task." and such as "You have chosen the correct answer." and "Well done.".

I did a little with the idea theoretically some time ago.

http://www.users.globalnet.co.uk/~ngo/c_c00000.htm

I never got it beyond English!

A later development was to incorporate the LOCODE concept so as to specify names of places that were to be localized, such as the way Firenze is expressed as Florence in English and London is expressed as Londres in French.

http://www.unece.org/cefact/locode/service/main.htm

William Overington

17 March 2006

Light-wight scripting language (Lua?)

Instead of measuring Python memory usage, why not provide a lighter scripting language from day one? Lua would fit this kind of a machine perfectly; it's been tested and used in embedded, as well as games development for years. Lua 5.1 has a module system, which allows it to be used as a system (end application) programming platform just as Python and/or Ruby. Only, it weighs no more than 100kB in the binary (with basic modules, no bindings).

People interested in bringing full OLPC programming support for Lua, please contact me for future plans. I already have a project going for Cairo & Lua, OLPC could simply be its "physical" incarnation?  :)

This is not to say Python on the device is pointless, it is not. But both solutions can co-exist, and provide a term of healthy competition with each other, that's all. :)

Asko Kauppi 10:18, 18 Jul 2006 (EET)

I think use of Python for Sugar, etc is pretty set in stone, with C (for certain applications) being the only alternative anyone has spoken with any kind of seriousness. --SamatJain 11:30, 18 July 2006 (EDT)
That's what I'd like to challenge, or rather extend (Python may well have the top position, no problems with that). My current standing is to observe the project, and kick in a Lua API binding if/when I see the time is ripe. Can be done as a one-man work, I'm sure. :) --Asko Kauppi 23:30, 18 July 2006 (EET)