Talk:System software: Difference between revisions
PeasthopeOld (talk | contribs) m (→Operating System Selection: Revised the link for Inferno and restated the comment about the interface.) |
No edit summary |
||
(2 intermediate revisions by 2 users not shown) | |||
Line 57: | Line 57: | ||
> ... The logical choice is Plan 9 ... |
> ... The logical choice is Plan 9 ... |
||
:Yes; isn't [http://wiki.laptop.org/go/Inferno Inferno] the current incarnation? Better still, [http://en.wikipedia.org/wiki/Bluebottle_OS A2]. |
:Yes; isn't [http://wiki.laptop.org/go/Inferno Inferno] the current incarnation? Better still, [http://en.wikipedia.org/wiki/Bluebottle_OS A2]. ... [[User:Peasthope|Peasthope]] 15:24, 2 November 2011 (UTC) |
||
> ... designed for graphics of a decade or two ago. It's obsolete. |
> ... designed for graphics of a decade or two ago. It's obsolete. |
||
Line 66: | Line 66: | ||
Free, simple, small, effective. |
Free, simple, small, effective. |
||
<br> |
|||
You realise that FreeDOS is only for x86 based computers while the XO is ARM-based, right? --<tt>[[User:Alphaslucas|<span style="font-size:110%;letter-spacing:1px;text-shadow:1px -1px 1px Green;">Alphaslucas</span>]] <sup style="font-size:80%;">[[User_talk:Alphaslucas|talk]]</sup></tt> 08:49, 27 August 2015 (UTC) |
|||
:At the time the comment was written, the two XO laptop models used AMD and VIA processors and could run FreeDOS. It was only later that the next two models were ARM based. --[[User:Quozl|Quozl]] 09:09, 27 August 2015 (UTC) |
|||
== Peer to Peer distribution of books == |
== Peer to Peer distribution of books == |
Latest revision as of 09:09, 27 August 2015
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.
- Hah. FreeBSD recently got around to fixing a kernel bug that would let anyone become root via the LDT control interface. (you could zero memory... like the memory holding your UID) Either via stupidity or an attempt to hide the problem, the fix went into CVS with a commit message indicating that the bug was merely a way to crash the system. Nobody was told to upgrade. This is not a secure operating system.
- Ubuntu has proven very solid and user friendly for me. It recognized all hardware on my ibm thinkpad to include wireless device and the install was seemless. Upgrades are managed very efficiently, as well.
- (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)
- OpenBSD lacks any form of Mandatory Access Control, which is needed to implement Bitfrost. You can't protect a user from trojans on OpenBSD.
- 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
- The 2.4 kernel is slow, obsolete, and without many power-saving features.
- (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)
- BeOS??? Be serious. There very are few BeOS-only apps, especially open ones. There are many Linux-only apps, and many more POSIX-like apps that will need something a bit more full-featured than a buggy bare-bones POSIX.
- 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.
- I suppose an Apple-like environment on X is available via GNUstep, but that would need some serious work. The current GNUstep stuff is nasty-looking and woefully out of date. Fixing that could take forever.
- Why UNIX(cont'd). Availability of applications and the fact that they are likely to see this in the real world. More and more countries are using linux as their preferred OS for state agencies and we are likely to se linux continue to gain popularity within business community.
- 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.
- Yeah, but... BeOS sucks. It did a few things well. Linux does most things well.
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.
- Plan 9 is designed for graphics of a decade or two ago. It's obsolete.
- 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.
> ... The logical choice is Plan 9 ...
- Yes; isn't Inferno the current incarnation? Better still, A2. ... Peasthope 15:24, 2 November 2011 (UTC)
> ... designed for graphics of a decade or two ago. It's obsolete.
- Yes; for the OLPC program, the OLPC interface is needed, regardless of what other interfaces are available. ... Peasthope 15:24, 2 November 2011 (UTC)
I think FreeDOS is a good alternative.
Free, simple, small, effective.
You realise that FreeDOS is only for x86 based computers while the XO is ARM-based, right? --Alphaslucas talk 08:49, 27 August 2015 (UTC)
- At the time the comment was written, the two XO laptop models used AMD and VIA processors and could run FreeDOS. It was only later that the next two models were ARM based. --Quozl 09:09, 27 August 2015 (UTC)
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)
Why do We Assume there will Always be a School Server Nearby?
It will ultimately limit distribution if OLPC can only be used in areas with organized education. To plan for as broad a distribution as possible, expect isolated OLPC's, and plan on running successfully in meshes without a school hub, or even without any other mesh participants.
- I would assume that the first or initial drive/waves will try to benefit/reuse whatever infrastructure is already available—school's infrastructure & people mainly; so it seems a reasonable assumption.
- As the laptop deployment process pushes farther and farther, to where no laptop has gone before, setting the server (afaik, could be a laptop configured differently plus some extra hardware) within a town limits (ie: the elder's meeting place or the house of a local 'responsible' person—remember that you need the 'handler' for activation and other issues) should not pose too many differences... except that currently the national education bureaucracies know who the principal of a given school is, but ignore the social dynamics of a town they are not in contact with... --Xavi 06:40, 8 March 2007 (EST)
> It will ultimately limit distribution if OLPC can only be used in areas with organized education. ... expect isolated OLPC's, ...
- This could help. http://en.wikipedia.org/wiki/Team_OneBeep. Regards, ... Peasthope 14:49, 2 November 2011 (UTC)