Uhh, I never once said Linux was easy to use. Nor did I claim it was ready for the desktop. Frankly, I don't give a shit if Linux is ready for the desktop or not. Hell, I'm on record stating that the idea of Linux world domination, itself, is stupid and misguided. Linux works for me. If it doesn't work for you, and you're still obsessed with switching away from Windows, get a Mac. Because *I don't care*.
The first item in the list is give them independence - but what OLPC creates is dependence on a technological infrastructure whose sole source in the whim of OLPC and their national government.
How so? The entire platform is open. Literally, all the source, the specs for the hardware, *everything*. If OLPC vanished today, right now, people could still get along just fine. Can you say the same if MS vanished and left XP behind?
Additionally, I've always found the "they can modify it" argument a but specious
To you. Millions of kids growing up with computers with BASIC on them would tend to disagree.
The last point I would like to make is that the GPL license does not, and will not, empower people in India, Brazil, or any other developing nation.
You're absolutely right. If some kid decides he wants to take some code from the OLPC, commercialize it, and make a mint, he won't be able to do it. OTOH, *who cares*?
Why USB? Just buy a standard 3Com PCI adapter and pop it in. Otherwise, hit Google. You should have little trouble finding a brand of adapter that will work.
Or get supported hardware made by vendors who are actually willing to cooperate with the Linux developers, numbnuts. Are you gonna complain that Ubuntu doesn't support your winmodem, too?
Except that KDE4 is, like I say, the entire frickin' desktop environment. And, having just been released in January, hardly has much in the way of legs on it just yet. Hence, it's understandable why Kubuntu decided to forego KDE4 for this LTS release.
I never said it tied them to x86. I said choosing something non-x86 would've added an additional technical complication that's entirely unnecessary, unless ARM offered some obvious, tangible benefit.
And the fact that most of the OLPC application stack is python doesn't change the fact that the environment, itself, is x86-based, and it's useful to be able to run the full stack, soup to nuts, on a development machine or within a VM.
Try it and decide for yourself (that's what the LiveCD is for). There are a million perfectly good reasons to switch to Ubuntu, and a million more to stick with Windows. It comes down to personal preference and needs.
Personally, I find Linux to be, overall, faster, more stable, more secure, and more open (ie, far easier to hack and customize). Of course, the price is right, too. And the vast universe of software freely available, right at my fingertips, means I spend more time using my computer, and less time hunting around for software to do what I need to do.
Incidentally, WoW is a platinum certified application for Wine, so you should be able to get it working quite nicely on the Linux side.
Strange, I'm running a T61 with an nvs140m in it, with the beta nvidia drivers no less (though I ran the stable drivers for a long time), and it's solid as a rock. 2D performance is excellent (well, assuming you stick with the 171 driver), and 3D is top notch as well.
Meanwhile, ATI has a history of creating incredibly shoddy drivers (there's a reason MythTV devs tell you to avoid them like the plague). Oh well, there's a reason the acronym YMMV came to being.
Yeah, sure, porting is doable. But it must be done. And if I, for example, don't have an OLPC on hand, my life is suddenly made a lot more difficult if I want to contribute to the project. Basically, non-x86 adds hassle and headaches that, without good reason otherwise, are best avoided.
Meanwhile, you haven't demonstrated any reason why ARM is, in reality, better than the platform they've chosen. Arguments involving actual numbers, as opposed to religion and gutfeel, are preferred.
The x86 platform they're running on is an excellent low-power system. Meanwhile, being x86, developers can work on and run Sugar, and developer applications, all on their regular ol' laptop, and then deploy them on an OLPC, all very easily.
So, tell me again, if they've already got a nice, low-power x86 platform, how does ARM do anything but make life *more* complicated for them, rather than less?
Or maybe it's just because Python (or Ruby or ) doesn't come close to having the level of corporate or community backing and support that Java does.
Like it or not, companies *like* the idea of a big corporation being the face behind something like Java. It means stability, predictability, support, long-term viability. It means someone you can bitch to if things go wrong. I means, in short, a sort of corporate legitimacy that's craved by upper-management types. And you can't that by simply being technically better (not that Python is better). Otherwise, we'd all be running around hacking code in Lisp and Smalltalk.
Right, so it's baseless speculation with a little MS bashing thrown in for flavour.
Honestly, the guy makes one reference to MS-like management structure, and all of a sudden it's an MS conspiracy?
Sorry, no, it's far easier to just assume the most simple, obvious answer: OLPC is growing, and they've discovered they need to change the way they manage the project in order to succeed. I know, shocking. And what better model to use for managing a large project than that used by one of the *largest computer companies in the world*?
So you're saying there's something wrong with MS's management structure? Or are you just throwing out baseless speculation for kicks, with a little MS bashing for flavour?
Absolutely agreed. As far as portability goes, I think widescreen wins, hands down. Not only is the dimension more amenable to backpacks, etc, it's also more stable (wider and less tall), and it also means it'll fit better in cramped spaces (eg, airplanes).
Given that, at the time, none of them knew of the theory of evolution, I think it's safe to give them a pass.
On the other hand, if Pasteur were alive today, working in biology, and claimed that creationism was the source of all diversity on earth, then damn right he should be fired. And the same goes for the rest of them.
I only meant that the underlying problem comes from the coders, not the languages they use.
I disagree. "Safe" languages are safer because they make the default case safe. In C, the default case is unsafe (and this is true for much of the language and standard library). The former makes it easier for the programmer to do the right thing. The latter makes it easier for the programmer to do the wrong thing. And every programmer can benefit from a language that makes safe programming easier... after all, no one is perfect.
Or, you can actually handle the error, which IMO should always happen, even if you can't recover from the error.
Absolutely not! By doing this, you do one thing: introduce additional code that's exceedingly hard to test, for no good reason. It reduces the coverage of your tests, and just increases the odds you'll introduce a bug.
It's a simple rule: If you can't handle the error, and your language gives you a mechanism for passing the issue on up the stack, you should *use it*. 99 times out of 100, you can't do anything about it, anyway, and anything you do attempt will probably be wrong.
When a program throws an exception rather than popping up a nice human-targetted message telling me what went wrong, that tells me that the programmer simply didn't expect the error in question to happen.
No, what it tells you is that something exceptional happened. Something that the program couldn't handle, and so it threw up it's hands and said "I don't know what happened, but you should probably look into it". That's a *good* thing. The last thing we need is more code hiding errors, or doing the *wrong* thing when it should just be aborting and alerting the user that something strange is going on.
But to be clear, I'm not saying programmers should ignore *all* errors. If you can recover from an error, you should do it as soon as possible. But if you can't, don't even try! The problem is, unsafe languages like C don't make that easy. Of course it *can* be done (Java is written in C, after all, so it must be possible), but it sure ain't easy or pretty or standardized.
Great, you've handled one case. Now what about realloc(), calloc(), free(), open(), read(), write(), etc, etc, etc?
Now suppose you want to allow the error to trickle up to some top-level code, where you can clean up after yourself and maybe generate a nice log message. How would you do that? Now how would you do it for code in a reuseable library? Now imagine you have code using the library, and it realizes it *can* handle the error, and would like to retry. How would you accomodate that without going in and modifying the library?
See, while you *can* do things in C, they're almost always horribly inconvenient, hackish, error prone, quite often unsafe, and everyone ends up rolling their own, which means yet more untested code with no miles on it. *Or*, you could use a language that provides facilities to make these things easier (and exceptions are just the tip of the iceberg). Why do you think so many people have worked so hard to replace C? Because, except for a few niche areas, it's *not* the best tool for the job anymore.
That's called "[catching] the error and handling it". Just because the error handling code is "exit()", doesn't change the fact that it's explicit error handling code that must be included in order for the program to work correctly. But in an exception-based language, you don't have to do *anything* to get safe behaviour.
Slashdot Mirror
Uhh, I never once said Linux was easy to use. Nor did I claim it was ready for the desktop. Frankly, I don't give a shit if Linux is ready for the desktop or not. Hell, I'm on record stating that the idea of Linux world domination, itself, is stupid and misguided. Linux works for me. If it doesn't work for you, and you're still obsessed with switching away from Windows, get a Mac. Because *I don't care*.
The first item in the list is give them independence - but what OLPC creates is dependence on a technological infrastructure whose sole source in the whim of OLPC and their national government.
How so? The entire platform is open. Literally, all the source, the specs for the hardware, *everything*. If OLPC vanished today, right now, people could still get along just fine. Can you say the same if MS vanished and left XP behind?
Additionally, I've always found the "they can modify it" argument a but specious
To you. Millions of kids growing up with computers with BASIC on them would tend to disagree.
The last point I would like to make is that the GPL license does not, and will not, empower people in India, Brazil, or any other developing nation.
You're absolutely right. If some kid decides he wants to take some code from the OLPC, commercialize it, and make a mint, he won't be able to do it. OTOH, *who cares*?
Ah, nm, you didn't want to open your case. Well, like I say, hit Google. I'm not sure why you expect someone on Slashdot to do all the work for you.
BTW, I'd give the Ubuntu Live CD a try before doing anything else. You never know, your card may have driver support, now.
Why USB? Just buy a standard 3Com PCI adapter and pop it in. Otherwise, hit Google. You should have little trouble finding a brand of adapter that will work.
Or get supported hardware made by vendors who are actually willing to cooperate with the Linux developers, numbnuts. Are you gonna complain that Ubuntu doesn't support your winmodem, too?
Except that KDE4 is, like I say, the entire frickin' desktop environment. And, having just been released in January, hardly has much in the way of legs on it just yet. Hence, it's understandable why Kubuntu decided to forego KDE4 for this LTS release.
I never said it tied them to x86. I said choosing something non-x86 would've added an additional technical complication that's entirely unnecessary, unless ARM offered some obvious, tangible benefit.
And the fact that most of the OLPC application stack is python doesn't change the fact that the environment, itself, is x86-based, and it's useful to be able to run the full stack, soup to nuts, on a development machine or within a VM.
So, what you're saying is kernel hot patching would be exactly the kind of they they'd be interested in (well, assuming banks ran Linux)? :)
And, clearly, you know better how to run a bank's systems than they do, despite having run them this way for, what, 30 years? 40?
As opposed to slipping a rootkit into the kernel image on-disk, and then waiting for/forcing a reboot?
Try it and decide for yourself (that's what the LiveCD is for). There are a million perfectly good reasons to switch to Ubuntu, and a million more to stick with Windows. It comes down to personal preference and needs.
Personally, I find Linux to be, overall, faster, more stable, more secure, and more open (ie, far easier to hack and customize). Of course, the price is right, too. And the vast universe of software freely available, right at my fingertips, means I spend more time using my computer, and less time hunting around for software to do what I need to do.
Incidentally, WoW is a platinum certified application for Wine, so you should be able to get it working quite nicely on the Linux side.
Strange, I'm running a T61 with an nvs140m in it, with the beta nvidia drivers no less (though I ran the stable drivers for a long time), and it's solid as a rock. 2D performance is excellent (well, assuming you stick with the 171 driver), and 3D is top notch as well.
Meanwhile, ATI has a history of creating incredibly shoddy drivers (there's a reason MythTV devs tell you to avoid them like the plague). Oh well, there's a reason the acronym YMMV came to being.
Yes. Because upgrading the entire frickin' desktop environment is exactly the same as shipping a late beta of Firefox.
Yeah, sure, porting is doable. But it must be done. And if I, for example, don't have an OLPC on hand, my life is suddenly made a lot more difficult if I want to contribute to the project. Basically, non-x86 adds hassle and headaches that, without good reason otherwise, are best avoided.
Meanwhile, you haven't demonstrated any reason why ARM is, in reality, better than the platform they've chosen. Arguments involving actual numbers, as opposed to religion and gutfeel, are preferred.
The x86 platform they're running on is an excellent low-power system. Meanwhile, being x86, developers can work on and run Sugar, and developer applications, all on their regular ol' laptop, and then deploy them on an OLPC, all very easily.
So, tell me again, if they've already got a nice, low-power x86 platform, how does ARM do anything but make life *more* complicated for them, rather than less?
Or maybe it's just because Python (or Ruby or ) doesn't come close to having the level of corporate or community backing and support that Java does.
Like it or not, companies *like* the idea of a big corporation being the face behind something like Java. It means stability, predictability, support, long-term viability. It means someone you can bitch to if things go wrong. I means, in short, a sort of corporate legitimacy that's craved by upper-management types. And you can't that by simply being technically better (not that Python is better). Otherwise, we'd all be running around hacking code in Lisp and Smalltalk.
BTW, I should say "software companies", but since they don't just manufacture software, that isn't quite right either. Technology companies? *shrug*
Right, so it's baseless speculation with a little MS bashing thrown in for flavour.
Honestly, the guy makes one reference to MS-like management structure, and all of a sudden it's an MS conspiracy?
Sorry, no, it's far easier to just assume the most simple, obvious answer: OLPC is growing, and they've discovered they need to change the way they manage the project in order to succeed. I know, shocking. And what better model to use for managing a large project than that used by one of the *largest computer companies in the world*?
So you're saying there's something wrong with MS's management structure? Or are you just throwing out baseless speculation for kicks, with a little MS bashing for flavour?
Oh, right, this is Slashdot...
Absolutely agreed. As far as portability goes, I think widescreen wins, hands down. Not only is the dimension more amenable to backpacks, etc, it's also more stable (wider and less tall), and it also means it'll fit better in cramped spaces (eg, airplanes).
Given that, at the time, none of them knew of the theory of evolution, I think it's safe to give them a pass.
On the other hand, if Pasteur were alive today, working in biology, and claimed that creationism was the source of all diversity on earth, then damn right he should be fired. And the same goes for the rest of them.
I only meant that the underlying problem comes from the coders, not the languages they use.
I disagree. "Safe" languages are safer because they make the default case safe. In C, the default case is unsafe (and this is true for much of the language and standard library). The former makes it easier for the programmer to do the right thing. The latter makes it easier for the programmer to do the wrong thing. And every programmer can benefit from a language that makes safe programming easier... after all, no one is perfect.
Or, you can actually handle the error, which IMO should always happen, even if you can't recover from the error.
Absolutely not! By doing this, you do one thing: introduce additional code that's exceedingly hard to test, for no good reason. It reduces the coverage of your tests, and just increases the odds you'll introduce a bug.
It's a simple rule: If you can't handle the error, and your language gives you a mechanism for passing the issue on up the stack, you should *use it*. 99 times out of 100, you can't do anything about it, anyway, and anything you do attempt will probably be wrong.
When a program throws an exception rather than popping up a nice human-targetted message telling me what went wrong, that tells me that the programmer simply didn't expect the error in question to happen.
No, what it tells you is that something exceptional happened. Something that the program couldn't handle, and so it threw up it's hands and said "I don't know what happened, but you should probably look into it". That's a *good* thing. The last thing we need is more code hiding errors, or doing the *wrong* thing when it should just be aborting and alerting the user that something strange is going on.
But to be clear, I'm not saying programmers should ignore *all* errors. If you can recover from an error, you should do it as soon as possible. But if you can't, don't even try! The problem is, unsafe languages like C don't make that easy. Of course it *can* be done (Java is written in C, after all, so it must be possible), but it sure ain't easy or pretty or standardized.
Great, you've handled one case. Now what about realloc(), calloc(), free(), open(), read(), write(), etc, etc, etc?
Now suppose you want to allow the error to trickle up to some top-level code, where you can clean up after yourself and maybe generate a nice log message. How would you do that? Now how would you do it for code in a reuseable library? Now imagine you have code using the library, and it realizes it *can* handle the error, and would like to retry. How would you accomodate that without going in and modifying the library?
See, while you *can* do things in C, they're almost always horribly inconvenient, hackish, error prone, quite often unsafe, and everyone ends up rolling their own, which means yet more untested code with no miles on it. *Or*, you could use a language that provides facilities to make these things easier (and exceptions are just the tip of the iceberg). Why do you think so many people have worked so hard to replace C? Because, except for a few niche areas, it's *not* the best tool for the job anymore.
That's called "[catching] the error and handling it". Just because the error handling code is "exit()", doesn't change the fact that it's explicit error handling code that must be included in order for the program to work correctly. But in an exception-based language, you don't have to do *anything* to get safe behaviour.