Yeah, OLPC (and the XO) have been making steady progress for the past few years. There are "grown up" versions of the XO with more standard keyboards, and the XO-1.5 have more memory and processor than before, etc.
That's the XO-2 design, which was discontinued. The XO-3 design is a single screen -- look for more details on this soonish. (The renderings on the olpc website are not up to date.)
Yes, the design of the laptop is intended to make it clear that it is a children's machine.
The hand-crank was always a creation of the confused media coverage. You *can* power the XO-1/1.5/1.75 with a hand crank -- you just wouldn't want to. Your arms are not the strongest part of your body, and the cranking motion is inefficient. OLPC invested in multiple different power technologies for different parts of the world -- step-powered generators, cow-powered generators, small and large solar panels, car battery multi-chargers, etc. Large-scale solar power is the only thing which deployment countries have been eager to adopt in large numbers. We respond to our deployments.
Incidentally, the lower power consumption of the XO-1.75 unsurprisingly makes it work better on solar power as well.
And this language, in particular, combines all the worst features of C, Perl, and Python. I can't find a single example in the tutorial that doesn't make my eyes bleed.
Interesting link -- but CS does provide mechanisms for creating "trust worthy" bundles securities, in the form of one-way functions. If the seller says, "I distributed the asset types among these securities using a random number generator built on a cryptographically secure one-way function with the following seed", it is possible to have a high degree of confidence that the distribution really is random. The seller can rejigger the seed but the one-way function (statistically) prevents more than a certain amount of tampering. (Of course, you can still try to tamper with the ordering or identity of the input securities -- discuss!)
RC4? Really?! Dude, that's totally broken -- see http://en.wikipedia.org/wiki/RC4#Security and especially http://en.wikipedia.org/wiki/Fluhrer,_Mantin,_and_Shamir_attack . Ron Rivest makes lots of good stuff, but all of "Ron's Codes" have been broken. (Except maybe RC6, but the AES committee determined that Rijndael was better than it.)
Classic example of amateur cryptography actually resulting in a system that is *weaker* than the alternative. Le sigh.
It's not running GNOME. It's running a custom shell based on X11/Clutter, with a few GTK widgets to avoid having to reimplement a textbox for the 1337th time.
Actually, I think you've got cause and effect backwards. Other GNOME guys have been hearing about big-shell's use of JavaScript informally from Havoc, and decided to adopt it for gnome-shell since it's worked so well for litl. If you look at the commit history of gjs you'll see it's about evenly divided between litl people and gnome-shell people now.
Because the moon's gravity well is 17% the size of the earth's. If you've climbed out of the earth's gravity well, why would you want to slide back down almost a fifth of the way, only to find yourself in an inhospitable environment with no cheap resources? Just go direct. It's easier.
For hard numbers, look at the delta-V budget to reach Mars from the moon, an accurate metric for launch costs.
Delta-V from Earth to Mars: 20.2 km/s.
Delta-V from Earth to Moon: 15.7 km/s.
Delta-V from Moon to Mars: 9.3 km/s.
So your total cost has gone up by 5km/s (a quarter) by stopping off at the Moon first.
Compare:
Delta-V from Earth to LEO: 10 km/s
Delta-V from LEO to Mars: 10.2 km/2.
So, if you build your stop-over point in low-earth orbit, then (a) it's 33% easier to get to, and (b) it makes the Mars trip 25% cheaper. And that 33% is nothing to sneeze at; expect you'd probably have an order of magnitude more people staying at your "moon base" or "space base" than you will send on to the ultimate destination, Mars.
Please review the technical assessment of porting Sugar to Windows which offers a number of reasons why porting the XO software to Windows is difficult, in excruciating details.
Yes, I wrote that assessment, and yes, I work at OLPC. I know what I'm talking about. You don't.
Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3.
Rationale: The whole idea behind indentation is to clearly define where a block of control starts and ends. Especially when you've been looking at your screen for 20 straight hours, you'll find it a lot easier to see how the indentation works if you have large indentations.
Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.
In short, 8-char indents make things easier to read, and have the added benefit of warning you when you're nesting your functions too deep. Heed that warning.
Don't put multiple statements on a single line unless you have something to hide:
if (condition) do_this;
do_something_everytime;
Don't put multiple assignments on a single line either. Kernel coding style is super simple. Avoid tricky expressions.
Outside of comments, documentation and except in Kconfig, spaces are never used for indentation, and the above example is deliberately broken.
Get a decent editor and don't leave whitespace at the end of lines.
Chapter 2: Breaking long lines and strings
Coding style is all about readability and maintainability using commonly available tools.
The limit on the length of lines is 80 columns and this is a hard limit.
Statements longer than 80 columns will be broken into sensible chunks. Descendants are always substantially shorter than the parent and are placed substantially to the right. The same applies to function headers with a long argument list. Long strings are as well broken into shorter strings.
[...]
Chapter 4: Naming
C is a Spartan language, and so should your naming be. Unlike Modula-2 and Pascal programmers, C programmers do not use cute names like ThisVariableIsATemporaryCounter. A C programmer would call that variable "tmp", which is much easier to write, and not the least more difficult to understand.
HOWEVER, while mixed-case names are frowned upon, descriptive names for global variables are a must. To call a global function "foo" is a shooting offense.
GLOBAL variables (to be used only if you _really_ need them) need to have descriptive names, as do global functions. If you have a function that counts the number of active users, you should call that "count_active_users()" or similar, you should _not_ call it "cntusr()".
Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged - the compiler knows the types anyway and can check those, and it only confuses the programmer. No wonder MicroSoft makes buggy programs.
LOCAL variable names should be short, and to the point. If you have some random integer loop counter, it should probably be called "i". Calling it "loop_counter" is non-productive, if there is no chance of it being mis-understood. Similarly, "tmp" can be just about any type of variable that is used to hold a temporary value.
If you are afraid t
Re:Things like this are easy to fix.
on
Google's Evil NDA
·
· Score: 1
The article does in fact mention this: among the confidential information is the terms of my offer (should I get one). So unless that becomes public (through no action or inaction of my own) the agreement never expires.
As a contestant, I'll contend that the teams weren't all "pretty dumb", but I agree the challenges were fairly straightforward. I got the idea that the show was trying to teach very basic science knowledge -- on my episode, we had to recreate that standard "lemon battery" experiment from primary school at one point. We certainly weren't doing particle physics. But we did get to build a hydroelectric dam and a cable car on the same episode. Not research science, but fun.
I think the show was never really certain what it's target audience was. It seemed to going after primary/middle school kids, but then it aired at 10pm.
"Escape from Experiment Island" was another Discovery Channel show with a concept similar to the one you describe. The science was rather more basic, however, and it aired in 2003, not "6 months ago". It lasted for a single season before being canned.
Unfortunately for martian surfers, the atmosphere on Mars is very low pressure -- so the winds, although "fierce" in mph terms, can't really move stuff more massive than than dust.
Re:did yall check the whois for groklaw?
on
SCO Vs. Groklaw
·
· Score: 1
Hmm. I haven't seen Paul Jones either, and I haven't seen Pamela Jones. But I *have* seen Eric S. Raymond. If all three of these are the same person, we're in a heap of trouble. Yargh!
At various times there have been poster campaigns to educate people about reuse. It sounds like you might be motivated to start another one. Ask around on the reuse related lists; I'd be surprised if there weren't poster pdfs already stashed away somewhere.
Um, he-LLO? MIT is the king of recycling. It's the home of the "reuse" list, where you can find someone to take almost *anything*. We've got student groups dedicated to rescuing ancient macs, dozens of dorm rooms filled with obsolete lab equipment, etc, etc. At MIT you really only have to put your unwanted stuff outside your door with a "reuse" sign on it and it will be snatched up. If you do this and post to the reuse mailing list, then it'll be gone within minutes. And not just electronic stuff: people regularly post food, event tickets, etc, etc, to reuse. It's magic, and a big part of MIT culture.
I have to assume that you are new here (and your advisor, too). Learn a bit about MIT culture (especially undergraduate culture) before you are so quick to judge.
And, when you've tinkered enough and want to learn how things like transistors *really work* (instead of just plugging together building blocks you've found elsewhere:
Horowitz and Hill's "The Art of Electronics" is the canonical guide/desk reference. It's pretty enjoyable reading if you like this sort of thing.
Slashdot Mirror
--scott (Director, New Technology, OLPC)
Yeah, OLPC (and the XO) have been making steady progress for the past few years. There are "grown up" versions of the XO with more standard keyboards, and the XO-1.5 have more memory and processor than before, etc.
That's the XO-2 design, which was discontinued. The XO-3 design is a single screen -- look for more details on this soonish. (The renderings on the olpc website are not up to date.)
The hand-crank was always a creation of the confused media coverage. You *can* power the XO-1/1.5/1.75 with a hand crank -- you just wouldn't want to. Your arms are not the strongest part of your body, and the cranking motion is inefficient. OLPC invested in multiple different power technologies for different parts of the world -- step-powered generators, cow-powered generators, small and large solar panels, car battery multi-chargers, etc. Large-scale solar power is the only thing which deployment countries have been eager to adopt in large numbers. We respond to our deployments.
Incidentally, the lower power consumption of the XO-1.75 unsurprisingly makes it work better on solar power as well.
The original G1G1 program also had large support and marketing costs.
Take a look at javascript, especially ES5.
And this language, in particular, combines all the worst features of C, Perl, and Python. I can't find a single example in the tutorial that doesn't make my eyes bleed.
Interesting link -- but CS does provide mechanisms for creating "trust worthy" bundles securities, in the form of one-way functions. If the seller says, "I distributed the asset types among these securities using a random number generator built on a cryptographically secure one-way function with the following seed", it is possible to have a high degree of confidence that the distribution really is random. The seller can rejigger the seed but the one-way function (statistically) prevents more than a certain amount of tampering. (Of course, you can still try to tamper with the ordering or identity of the input securities -- discuss!)
RC4? Really?! Dude, that's totally broken -- see http://en.wikipedia.org/wiki/RC4#Security and especially http://en.wikipedia.org/wiki/Fluhrer,_Mantin,_and_Shamir_attack . Ron Rivest makes lots of good stuff, but all of "Ron's Codes" have been broken. (Except maybe RC6, but the AES committee determined that Rijndael was better than it.) Classic example of amateur cryptography actually resulting in a system that is *weaker* than the alternative. Le sigh.
The litl uses low-travel scissor-action keys, like the Apple keyboards, not rubber keys like the old 'chiclet' keyboards and the OLPC XO-1. The keyboard is pretty pleasant to type on. See http://en.wikipedia.org/wiki/Chiclet_keyboard#Recent_developments
The support videos at http://litl.com/support/ give a good idea of how the UI works -- and they also feature Annie, litl's friendly customer care rep!
It's not running GNOME. It's running a custom shell based on X11/Clutter, with a few GTK widgets to avoid having to reimplement a textbox for the 1337th time.
The WSJ article was not linked, but it's at http://blogs.wsj.com/digits/2009/11/04/litl-introduces-its-web-based-netbook/
Actually, I think you've got cause and effect backwards. Other GNOME guys have been hearing about big-shell's use of JavaScript informally from Havoc, and decided to adopt it for gnome-shell since it's worked so well for litl. If you look at the commit history of gjs you'll see it's about evenly divided between litl people and gnome-shell people now.
Because the moon's gravity well is 17% the size of the earth's. If you've climbed out of the earth's gravity well, why would you want to slide back down almost a fifth of the way, only to find yourself in an inhospitable environment with no cheap resources? Just go direct. It's easier.
For hard numbers, look at the delta-V budget to reach Mars from the moon, an accurate metric for launch costs.
So your total cost has gone up by 5km/s (a quarter) by stopping off at the Moon first.
Compare:
So, if you build your stop-over point in low-earth orbit, then (a) it's 33% easier to get to, and (b) it makes the Mars trip 25% cheaper. And that 33% is nothing to sneeze at; expect you'd probably have an order of magnitude more people staying at your "moon base" or "space base" than you will send on to the ultimate destination, Mars.
Please review the technical assessment of porting Sugar to Windows which offers a number of reasons why porting the XO software to Windows is difficult, in excruciating details. Yes, I wrote that assessment, and yes, I work at OLPC. I know what I'm talking about. You don't.
This is Linus' canonical justication for 80-column lines. Full version (worth reading!) at: /linux-2.6.git;a=blob;f=Documentation/CodingStyle; hb=HEAD
http://git.kernel.org/?p=linux/kernel/git/torvalds
-------
Linux kernel coding style
[...]
Chapter 1: Indentation
Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3.
Rationale: The whole idea behind indentation is to clearly define where a block of control starts and ends. Especially when you've been looking at your screen for 20 straight hours, you'll find it a lot easier to see how the indentation works if you have large indentations.
Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.
In short, 8-char indents make things easier to read, and have the added benefit of warning you when you're nesting your functions too deep. Heed that warning.
Don't put multiple statements on a single line unless you have something to hide:
if (condition) do_this;
do_something_everytime;
Don't put multiple assignments on a single line either. Kernel coding style is super simple. Avoid tricky expressions.
Outside of comments, documentation and except in Kconfig, spaces are never used for indentation, and the above example is deliberately broken.
Get a decent editor and don't leave whitespace at the end of lines.
Chapter 2: Breaking long lines and strings
Coding style is all about readability and maintainability using commonly available tools.
The limit on the length of lines is 80 columns and this is a hard limit.
Statements longer than 80 columns will be broken into sensible chunks. Descendants are always substantially shorter than the parent and are placed substantially to the right. The same applies to function headers with a long argument list. Long strings are as well broken into shorter strings.
[...]
Chapter 4: Naming
C is a Spartan language, and so should your naming be. Unlike Modula-2 and Pascal programmers, C programmers do not use cute names like ThisVariableIsATemporaryCounter. A C programmer would call that variable "tmp", which is much easier to write, and not the least more difficult to understand.
HOWEVER, while mixed-case names are frowned upon, descriptive names for global variables are a must. To call a global function "foo" is a shooting offense.
GLOBAL variables (to be used only if you _really_ need them) need to have descriptive names, as do global functions. If you have a function that counts the number of active users, you should call that "count_active_users()" or similar, you should _not_ call it "cntusr()".
Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged - the compiler knows the types anyway and can check those, and it only confuses the programmer. No wonder MicroSoft
makes buggy programs.
LOCAL variable names should be short, and to the point. If you have some random integer loop counter, it should probably be called "i". Calling it "loop_counter" is non-productive, if there is no chance of it
being mis-understood. Similarly, "tmp" can be just about any type of variable that is used to hold a temporary value.
If you are afraid t
The article does in fact mention this: among the confidential information is the terms of my offer (should I get one). So unless that becomes public (through no action or inaction of my own) the agreement never expires.
I think that this agreement is terribly worded.
As a contestant, I'll contend that the teams weren't all "pretty dumb", but I agree the challenges were fairly straightforward. I got the idea that the show was trying to teach very basic science knowledge -- on my episode, we had to recreate that standard "lemon battery" experiment from primary school at one point. We certainly weren't doing particle physics. But we did get to build a hydroelectric dam and a cable car on the same episode. Not research science, but fun.
I think the show was never really certain what it's target audience was. It seemed to going after primary/middle school kids, but then it aired at 10pm.
"Escape from Experiment Island" was another Discovery Channel show with a concept similar to the one you describe. The science was rather more basic, however, and it aired in 2003, not "6 months ago". It lasted for a single season before being canned.
Unfortunately for martian surfers, the atmosphere on Mars is very low pressure -- so the winds, although "fierce" in mph terms, can't really move stuff more massive than than dust.
Hmm. I haven't seen Paul Jones either, and I haven't seen Pamela Jones. But I *have* seen Eric S. Raymond. If all three of these are the same person, we're in a heap of trouble. Yargh!
At various times there have been poster campaigns to educate people about reuse. It sounds like you might be motivated to start another one. Ask around on the reuse related lists; I'd be surprised if there weren't poster pdfs already stashed away somewhere.
Um, he-LLO? MIT is the king of recycling. It's the home of the "reuse" list, where you can find someone to take almost *anything*. We've got student groups dedicated to rescuing ancient macs, dozens of dorm rooms filled with obsolete lab equipment, etc, etc. At MIT you really only have to put your unwanted stuff outside your door with a "reuse" sign on it and it will be snatched up. If you do this and post to the reuse mailing list, then it'll be gone within minutes. And not just electronic stuff: people regularly post food, event tickets, etc, etc, to reuse. It's magic, and a big part of MIT culture. I have to assume that you are new here (and your advisor, too). Learn a bit about MIT culture (especially undergraduate culture) before you are so quick to judge.
And, when you've tinkered enough and want to learn how things like transistors *really work* (instead of just plugging together building blocks you've found elsewhere: Horowitz and Hill's "The Art of Electronics" is the canonical guide/desk reference. It's pretty enjoyable reading if you like this sort of thing.