I think you've got it backwards. People can, and will, pay for new features, and for making software talk together in previously untried ways
My original message was pointing out that the business model based on bug fixes creates a pathologic economic incentive. You're talking here about a variation on this theme, which is adding new features. I'll point out first that individuals can't pay a dev team to develop new features, and the vast majority of individuals won't pay for free software, so by "people" you probably mean "companies". Sure, some of them will pay for new features, when did I ever say they won't? But your variation still creates a twisted economic incentive, which is to provide software with minimum features (and get paid to write them later).
I doubt however that you can make serious money on either version of the support above; every company will want some specific features, so what you're writing is custom software, and you'll get paid standard wages. Selling support contracts, (basically software "insurance") would be difficult too, because a company willing to pay for a support contract, will probably go with the solution provider, like IBM, Sun, Microsoft or Oracle. The interesting business model is however one where you can sell your product to multiple customers, thus spreading your development costs over many units. This model is difficult to support with FOSS, because FOSS doesn't scale well. See how even SourceForge Inc (nee VA Linux), the company owning slashdot, had to take their flagship product to a proprietary licence, before selling it altogether, and now seems to be out of the software development business altogether.
All software has bugs. If your customer finds a bug in the software they can report it upstream and wait around for the bug to get fixed or they can report it to you and pay you to fix it now. That's support.
And this creates a powerful economic incentive to provide buggy software: if your software is perfect out of the box, the customer will not pay you. As an open source software writer, you depend on the *bugs* in your software for your income. That creates a paradox, and makes your life difficult: your product must be innovative enough, or good enough, to get customers to use it. However, the better your software is, the less money you make! You can write high quality code for art's sake (nice if you don't have a mortgage and/or kids), but if you want to make your living on software you need to look for another business model.
Note that the economic incentive works precisely the other way around for makers of proprietary software: the margin on most software sales is not very large, and one support call will wipe out your revenue for that sale. So the software maker needs to make his software as stable as possible, to avoid the extra costs of supporting it.
RSA and other similar algorithms can only 'encrypt' things which are quite a lot shorter than the key length (and they use some kind of padding scheme). So you would have to define some kind of encoding scheme which splits the source into blocks to 'encrypt' them (and with some kind of chaining scheme so that the bad guys could not take blocks from different messages and rearrange them). As far as I know, there is no standard for this with widespread support.
Well, not quite. The block size for RSA is equal to the size of the key modulus (basically the key size). If you encrypt plaintexts shorter than the block size, you'll need to pad them, of course (and there are well defined standards for the padding too, see here ). For plaintexts of arbitrary size, you use one of the (well known and standardized) modes of operation - for example ECB (Electronic Code Book), CBC (Cipher Block Chaining) or various feedback modes. The modes of operation are defined in the ANSI X3.106 standard for DES or in ISO92b (for cyphers with arbitrary block sizes). FWIW, it's not recommended to simply split the plaintext in MODULUS_SIZE blocks, but instead pad every block - see OAEP (Optimal Asymmetric Encryption Padding).
And how do you think PGP signs something? It takes a checksum of it (hopefully avoiding md5) and passes that through the signature algorithm (RSA or something similar). So you can't avoid the checksum (hash function) by using PGP.
PGP may do that, but note that a hash is a convenience, used because it's much smaller than the original document, so encrypting/decrypting the signature uses fewer computational resources. A "real" hash is not however required to sign a document: just provide the original document and the same document encrypted with your private key. The encrypted version is your signature. Users can verify you're the one that signed the document by decrypting the encrypted version with your public key and comparing it against the plaintext one.
I'm no astronomer or physicist but isn't the fact that there is so much dark sky, even with powerful telescopes, suggestive of the presence of dark matter?
No, but the existence of dark sky *is* interesting.
Look up Olbers' paradox. Any matter that respects the laws of thermodinamics (be it dust, interstellar gas or the newly defined "dark matter") should heat up to the temperature of its ambient medium and start radiating, so absorbtion can't be an explanation for the dark sky. There are however other theories that could explain it (see the Wikipedia article for some of them).
Re:I really want a copy of this...
on
Clean Code
·
· Score: 2, Insightful
So the title seems a little misleading. It seems to me that Anna Pyayt is the primary inventor, not the Microsoft engineers.
Not to rain on your anti-MS parade, but during a research collaboration it is often difficult to assign ideas clearly to one or another of the team members. And I'll note that one of the "Microsoft engineers" you mention, one of the authors of the article, is Gary Starkweather. This is the guy who invented both the laser printer and color management, so I think he has the capability to come up with new ideas by himself.
IBM does LOADS of research in materials, chip, silicon, quantum, math...and etcetera. They actually live off some real patents and some trolish stupid patents.
HP does less than IBM, but its sort-of in the same league: they do, for a big part, live of real patents
Microsoft has only patented really stupid ideas (not that the other two havent, but MS practically ONLY has patents for trolling or to "prevent" trolling).
People who actually work in the field disagree with you.
See here for more information. MS, IBM and HP have led the patent quality scorecard for years, and last year MS actually took the title from IBM. A better example of patent troll would be Samsung, who leads in number of patents, but lags the world average in patent quality.
1. Microsoft didn't even target "regular Joe" computers. They aimed to capture the enterprise market, and succeeded. Their software was extremely boring to the "regular Joe", but they managed to estabilish themselves as a de facto standard, and then creeped into the home desktop.
That's a very ignorant statement. On the contrary, Microsoft was always interested in home machines, since the beginning; they wrote code for the hobbyist Altair systems before the PC was even a gleam in IBM's eye. In the eighties, Microsoft defined the MSX standard specifically for home computers. Microsoft was one of the first companies to release games on the PC, with the first version of Flight Simulator available in '82.
2. Microsoft was at the right place in the right time, and their monopoly was essentially sponsored by IBM - any other company would have done the job as well.
3. The first "regular Joe" computers - ZX Spectrum, Atari, Commodore, Amiga - had nothing to do with Microsoft.
Shows what you know. The Commodore and the Amiga all shipped with BASIC written by and licensed from Microsoft. The Atari also licensed the language from MS, and sold it as a separate product. Microsoft also released a lot of software for Apple - guess who wrote the most popular BASIC for the Apple II? That's right, Microsoft. And Word for the Apple Macintosh was available in 1985, very soon after the Macintosh release in 1984.
4. The real reason why the price of computing dived were related to the price of hardware falling dramatically over a short period
So, you're saying the price of computers went down because the price of computers went down. BZZT! The price went down because of the commoditization of computing, because of the huge economies of scale mass production allows. And mass production become possible because people suddenly wanted computers, and bought them in droves. And, except for a technically savvy minority, people didn't want computers for the processor they had inside. They wanted them for the software running on them, for games, word processing, desktop publishing (which was quite a buzzword at a time).
Technically you could say that Microsoft doesn't do anything profitably except OS and Office software.
You could indeed say that, but you'd be wrong by billions of dollars. The SQL Server group is highly profitable as well, making almost a billion in profit in the first quarter of 2008, and over 3 billion over the 9 months ending March 31. See the numbers here, in note 9 (SQL Server is under Server and Tools). Note that even the Entertainment division (makers of the XBox) made a profit that quarter, and also in the 9 month ending March 31. The only division in the red is the Online division (no surprise there).
If I am going to write a cross platform app, why choose a toolkit with so many platform-specific -isms, like win32-isms (WM_ messages, HWND, WndProc etc) and not choose one that makes more sense, like GTK#?
Because the "cross-platform" requirement often doesn't exist, at least not during the design of V1.0 of an application. The application is intended to work on a certain platform. A design requirement for "cross-platform compatibility" will have a major impact on resources and budget (think for example of all the extra effort required for testing and stabilizing the app on multiple platforms). Yes, there are toolkits or frameworks that promise cross-platform compatibility, but the truth is that for serious apps you'll have to either sacrifice performance on your real target platform, or tweak the code individually for all platforms. Big effort, if you're talking about a big application. There must be a strong justification for the extra expense, and in many cases it doesn't make sense.
Sometimes, after a number of years/versions, requirements change, and you need to migrate the app to something else. That's where something like Mono helps. And note, this two-step process may well be the correct way to go for a company, especially for a start-up. The money and resources for the porting work will come from a different year's budget; if your app was successful, your company may now have enough cash to handle it.
That said, there is a clumsy set of constructs around threading still. Most modern languages do not have the atomic test-and-flip operation around an object as you wish. For example, in the C# realm, I see this routinely:
[snip]
...I'd much more appreciate the OS supporting a thread-level operation that allowed for
With the Whitehouse blaming MS Exchange for the loss of emails (at least in part so no need for flames as that is how joe sixpack will hear the news),
I will note though that joe sixpack doesn't even know what a data center is, much less needs one, designs one or does comparisons of various vendor solutions. So your argument doesn't really apply. If the designer of a data center is ignorant enough to miss the technical issues with the above-mentioned White House press release, and incompetent enough to use that as a factor in his decision, any kind of data center he puts together will probably be a major failure. And then he'll blame the vendor, of course:)
My understanding of hawking radiation is that a particle/anti-particle pair is created near the event horizon. One particle falls in and the other falls out. It's the ones that fall out that are called hawking radiation, and the particles falling in contribute to the black hole's demise.
The question that arises in my mind is this. Presumably there is a 50/50 chance that it's the particle that's being emitted, and the anti-particle falling into the hole. The other 50% of the time it's the antiparticle that escapes, and the particle falls in. So, if half of what falls in are particles, and half are anti-particles, wouldn't the net effect on the black hole be zero?
IANAPhysicist, so I son't know anything about the state of matter inside a black hole, but even if the particles and antiparticles annihilate, the resulting energy doesn't dissapear or leave the black hole. So this basically makes no difference: the net mass still increases.
who would you say the most influential practitioner within the field is?
I had the pleasure of hearing Adi Shamir give a number of talks about his recent work at the Weizmann Institute. I think he's definitely a more influential figure than Schneier (albeit less well-known by the public). I don't think I'm informed enough to say he's "the most" influential though.
For example, most people don't use the SSE stuff or even know about it. You can, for example, make a vector with 4 numbers in it and multiply it with another vector with 4 numbers in it. The result is that the four multiplications are done simulatanously
But that isn't part of the C++ language, is it? It's just the compiler being clever. Is there anything specific to the language that would stop the C# or Java compilers from using a similar optimization?
Good way to collect active and not spam-trapped e-mail addresses, and maybe link them to phone numbers as well. As a company, I may not send mail or call the phone numbers Mr. Geist is so nicely forwarding to me, but what stops me from selling them to spammers? I don't have a direct relationship with the customer, so, AFAICT there is no legal issue.
it's because the spec requires things that are contradictory or that don't really work in the real world for one reason or another [...]
The requirement for waiting until we have 2 complete implementations is so that we know, when we say the spec is done, that it really can be implemented and that such implementations really can be interoperable.
Interesting; I had no idea that the W3C design process for the specs is actually trial and error. Thanks for the info! I'd say that explains a lot:).
Something I found interesting is that they will not consider the spec complete until there are two fully working implementations (FTFA).
Which sounds rather self-defeating to me; why would a group or company put in a lot of effort implementing the most difficult parts of the recommendation, if W3C explicitely reserves the right to change the spec under them any time before you're done?
Do they _really_ need to learn Windows, or just basic computing concepts?
I'm not sure what you mean, but the discussion started with the "show source" requirement, so I'll assume you don't include everyday computer usage as a computer concept, even basic.
Here, on Slashdot, we tend to exaggerate the importance of computer knowledge. Basic computing concepts (such as the capability to read/write a program or a script) are needed for engineers, system administrators, certainly for programmers, and a few others. But there are *many* more jobs where familiarity with Windows and Office is useful or even essential, while knowledge of computing theory and programming (even at a basic level) is not. Familiarity with Excel may for example make the difference between being hired for a secretarial position or not. So yes, pragmatically speaking, learning how to *use* (not program) Windows could be more useful for a poor 3rd world kid than getting source code access.
The only requirement is that it displays graphics and text on the screen, so there's absolutly no reason I can see why they couldn't learn all those things with a non-Windows OS
Agreed - but that's a different issue. My argument was not OS related; I was saying that the usefulness of the OLPC is not given by the capability to see the source code.
But the entire point of the OLPC is education. A computer that shows you its code, so you can learn and create with it.
That's a very Slashdotesque point of view and a good example of missing the forest because of one tree. You need to see the source only if you want the kid to become a programmer or maybe a sysadmin. The third world countries targeted by the OLPC have much higher and more urgent priorities. They need educated people in many other areas, not only programming. They need better, more knowledgeable farmers, workers, manufacturers, engineers, teachers, physicians, accountants, even managers and lawyers. Very, very few of the kids playing and learning now in those countries need bash or python. They do need however to learn how not to dig the outhouse near the well, how to avoid malaria, how to get more wheat out of their crops, how to start a business, how to sell their product in an increasingly globalized world. They need to learn how to access expertise already existing elsewhere, and they need to be able to do so easily. I'd argue that they even need to learn Windows, and thus get access to a whole variety of jobs where they use computers (non-programming positions, of course).
The source code is irrelevant for all those scenarios, which I believe are the core ones for the OLPC project.
Slashdot Mirror
Perl could be a first class citizen on Windows if MS bundled a C compiler and library like any decent OS does.
Or, you could go and download them, geeze! Why bloat installations with bundled stuff that the vast majority of users won't ever need?
I think you've got it backwards. People can, and will, pay for new features, and for making software talk together in previously untried ways
My original message was pointing out that the business model based on bug fixes creates a pathologic economic incentive. You're talking here about a variation on this theme, which is adding new features. I'll point out first that individuals can't pay a dev team to develop new features, and the vast majority of individuals won't pay for free software, so by "people" you probably mean "companies". Sure, some of them will pay for new features, when did I ever say they won't? But your variation still creates a twisted economic incentive, which is to provide software with minimum features (and get paid to write them later).
I doubt however that you can make serious money on either version of the support above; every company will want some specific features, so what you're writing is custom software, and you'll get paid standard wages. Selling support contracts, (basically software "insurance") would be difficult too, because a company willing to pay for a support contract, will probably go with the solution provider, like IBM, Sun, Microsoft or Oracle. The interesting business model is however one where you can sell your product to multiple customers, thus spreading your development costs over many units. This model is difficult to support with FOSS, because FOSS doesn't scale well. See how even SourceForge Inc (nee VA Linux), the company owning slashdot, had to take their flagship product to a proprietary licence, before selling it altogether, and now seems to be out of the software development business altogether.
All software has bugs. If your customer finds a bug in the software they can report it upstream and wait around for the bug to get fixed or they can report it to you and pay you to fix it now. That's support.
And this creates a powerful economic incentive to provide buggy software: if your software is perfect out of the box, the customer will not pay you. As an open source software writer, you depend on the *bugs* in your software for your income. That creates a paradox, and makes your life difficult: your product must be innovative enough, or good enough, to get customers to use it. However, the better your software is, the less money you make! You can write high quality code for art's sake (nice if you don't have a mortgage and/or kids), but if you want to make your living on software you need to look for another business model.
Note that the economic incentive works precisely the other way around for makers of proprietary software: the margin on most software sales is not very large, and one support call will wipe out your revenue for that sale. So the software maker needs to make his software as stable as possible, to avoid the extra costs of supporting it.
RSA and other similar algorithms can only 'encrypt' things which are quite a lot shorter than the key length (and they use some kind of padding scheme). So you would have to define some kind of encoding scheme which splits the source into blocks to 'encrypt' them (and with some kind of chaining scheme so that the bad guys could not take blocks from different messages and rearrange them). As far as I know, there is no standard for this with widespread support.
Well, not quite. The block size for RSA is equal to the size of the key modulus (basically the key size). If you encrypt plaintexts shorter than the block size, you'll need to pad them, of course (and there are well defined standards for the padding too, see here ). For plaintexts of arbitrary size, you use one of the (well known and standardized) modes of operation - for example ECB (Electronic Code Book), CBC (Cipher Block Chaining) or various feedback modes. The modes of operation are defined in the ANSI X3.106 standard for DES or in ISO92b (for cyphers with arbitrary block sizes). FWIW, it's not recommended to simply split the plaintext in MODULUS_SIZE blocks, but instead pad every block - see OAEP (Optimal Asymmetric Encryption Padding).
And how do you think PGP signs something? It takes a checksum of it (hopefully avoiding md5) and passes that through the signature algorithm (RSA or something similar). So you can't avoid the checksum (hash function) by using PGP.
PGP may do that, but note that a hash is a convenience, used because it's much smaller than the original document, so encrypting/decrypting the signature uses fewer computational resources. A "real" hash is not however required to sign a document: just provide the original document and the same document encrypted with your private key. The encrypted version is your signature. Users can verify you're the one that signed the document by decrypting the encrypted version with your public key and comparing it against the plaintext one.
I'm no astronomer or physicist but isn't the fact that there is so much dark sky, even with powerful telescopes, suggestive of the presence of dark matter?
No, but the existence of dark sky *is* interesting.
Look up Olbers' paradox. Any matter that respects the laws of thermodinamics (be it dust, interstellar gas or the newly defined "dark matter") should heat up to the temperature of its ambient medium and start radiating, so absorbtion can't be an explanation for the dark sky. There are however other theories that could explain it (see the Wikipedia article for some of them).
Ouch... Your function fails miserably if n is negative. Check if n greater than 0, not !0
So the title seems a little misleading. It seems to me that Anna Pyayt is the primary inventor, not the Microsoft engineers.
Not to rain on your anti-MS parade, but during a research collaboration it is often difficult to assign ideas clearly to one or another of the team members. And I'll note that one of the "Microsoft engineers" you mention, one of the authors of the article, is Gary Starkweather. This is the guy who invented both the laser printer and color management, so I think he has the capability to come up with new ideas by himself.
IBM does LOADS of research in materials, chip, silicon, quantum, math...and etcetera. They actually live off some real patents and some trolish stupid patents.
HP does less than IBM, but its sort-of in the same league: they do, for a big part, live of real patents
Microsoft has only patented really stupid ideas (not that the other two havent, but MS practically ONLY has patents for trolling or to "prevent" trolling).
People who actually work in the field disagree with you.
See here for more information. MS, IBM and HP have led the patent quality scorecard for years, and last year MS actually took the title from IBM. A better example of patent troll would be Samsung, who leads in number of patents, but lags the world average in patent quality.
I call bullshit on this.
I call bullshit on your bullshit.
1. Microsoft didn't even target "regular Joe" computers. They aimed to capture the enterprise market, and succeeded. Their software was extremely boring to the "regular Joe", but they managed to estabilish themselves as a de facto standard, and then creeped into the home desktop.
That's a very ignorant statement. On the contrary, Microsoft was always interested in home machines, since the beginning; they wrote code for the hobbyist Altair systems before the PC was even a gleam in IBM's eye. In the eighties, Microsoft defined the MSX standard specifically for home computers. Microsoft was one of the first companies to release games on the PC, with the first version of Flight Simulator available in '82.
2. Microsoft was at the right place in the right time, and their monopoly was essentially sponsored by IBM - any other company would have done the job as well.
3. The first "regular Joe" computers - ZX Spectrum, Atari, Commodore, Amiga - had nothing to do with Microsoft.
Shows what you know. The Commodore and the Amiga all shipped with BASIC written by and licensed from Microsoft. The Atari also licensed the language from MS, and sold it as a separate product. Microsoft also released a lot of software for Apple - guess who wrote the most popular BASIC for the Apple II? That's right, Microsoft. And Word for the Apple Macintosh was available in 1985, very soon after the Macintosh release in 1984.
4. The real reason why the price of computing dived were related to the price of hardware falling dramatically over a short period
So, you're saying the price of computers went down because the price of computers went down. BZZT! The price went down because of the commoditization of computing, because of the huge economies of scale mass production allows. And mass production become possible because people suddenly wanted computers, and bought them in droves. And, except for a technically savvy minority, people didn't want computers for the processor they had inside. They wanted them for the software running on them, for games, word processing, desktop publishing (which was quite a buzzword at a time).
Look at the Microsoft org chart to see where they place SQL Server in and then come back and tell me how right I am.
SQL Server is made by the Server and Tools division, and the Office suite by the Business division, so it looks like you're not right at all.
Technically you could say that Microsoft doesn't do anything profitably except OS and Office software.
You could indeed say that, but you'd be wrong by billions of dollars. The SQL Server group is highly profitable as well, making almost a billion in profit in the first quarter of 2008, and over 3 billion over the 9 months ending March 31. See the numbers here, in note 9 (SQL Server is under Server and Tools). Note that even the Entertainment division (makers of the XBox) made a profit that quarter, and also in the 9 month ending March 31. The only division in the red is the Online division (no surprise there).
"The Silverlight plugin does not work on pre-Intel Macs. Sorry."
embrace, extend, extinguish.
You're absolutely right - especially when you contrast with the way Apple supports their own pre-Intel computers.
If I am going to write a cross platform app, why choose a toolkit with so many platform-specific -isms, like win32-isms (WM_ messages, HWND, WndProc etc) and not choose one that makes more sense, like GTK#?
Because the "cross-platform" requirement often doesn't exist, at least not during the design of V1.0 of an application. The application is intended to work on a certain platform. A design requirement for "cross-platform compatibility" will have a major impact on resources and budget (think for example of all the extra effort required for testing and stabilizing the app on multiple platforms). Yes, there are toolkits or frameworks that promise cross-platform compatibility, but the truth is that for serious apps you'll have to either sacrifice performance on your real target platform, or tweak the code individually for all platforms. Big effort, if you're talking about a big application. There must be a strong justification for the extra expense, and in many cases it doesn't make sense.
Sometimes, after a number of years/versions, requirements change, and you need to migrate the app to something else. That's where something like Mono helps. And note, this two-step process may well be the correct way to go for a company, especially for a start-up. The money and resources for the porting work will come from a different year's budget; if your app was successful, your company may now have enough cash to handle it.
[snip]
So what's wrong with the Interlocked class? It seems to do exactly what you want:
You can see more details and a locking example using that technique here
With the Whitehouse blaming MS Exchange for the loss of emails (at least in part so no need for flames as that is how joe sixpack will hear the news),
:)
I will note though that joe sixpack doesn't even know what a data center is, much less needs one, designs one or does comparisons of various vendor solutions. So your argument doesn't really apply. If the designer of a data center is ignorant enough to miss the technical issues with the above-mentioned White House press release, and incompetent enough to use that as a factor in his decision, any kind of data center he puts together will probably be a major failure. And then he'll blame the vendor, of course
Who is we?
We have met the enemy and he is us
My understanding of hawking radiation is that a particle/anti-particle pair is created near the event horizon. One particle falls in and the other falls out. It's the ones that fall out that are called hawking radiation, and the particles falling in contribute to the black hole's demise.
The question that arises in my mind is this. Presumably there is a 50/50 chance that it's the particle that's being emitted, and the anti-particle falling into the hole. The other 50% of the time it's the antiparticle that escapes, and the particle falls in. So, if half of what falls in are particles, and half are anti-particles, wouldn't the net effect on the black hole be zero?
IANAPhysicist, so I son't know anything about the state of matter inside a black hole, but even if the particles and antiparticles annihilate, the resulting energy doesn't dissapear or leave the black hole. So this basically makes no difference: the net mass still increases.
who would you say the most influential practitioner within the field is?
I had the pleasure of hearing Adi Shamir give a number of talks about his recent work at the Weizmann Institute. I think he's definitely a more influential figure than Schneier (albeit less well-known by the public). I don't think I'm informed enough to say he's "the most" influential though.
For example, most people don't use the SSE stuff or even know about it. You can, for example, make a vector with 4 numbers in it and multiply it with another vector with 4 numbers in it. The result is that the four multiplications are done simulatanously
But that isn't part of the C++ language, is it? It's just the compiler being clever. Is there anything specific to the language that would stop the C# or Java compilers from using a similar optimization?
Good way to collect active and not spam-trapped e-mail addresses, and maybe link them to phone numbers as well. As a company, I may not send mail or call the phone numbers Mr. Geist is so nicely forwarding to me, but what stops me from selling them to spammers? I don't have a direct relationship with the customer, so, AFAICT there is no legal issue.
it's because the spec requires things that are contradictory or that don't really work in the real world for one reason or another [...]
:).
The requirement for waiting until we have 2 complete implementations is so that we know, when we say the spec is done, that it really can be implemented and that such implementations really can be interoperable.
Interesting; I had no idea that the W3C design process for the specs is actually trial and error. Thanks for the info! I'd say that explains a lot
Something I found interesting is that they will not consider the spec complete until there are two fully working implementations (FTFA).
Which sounds rather self-defeating to me; why would a group or company put in a lot of effort implementing the most difficult parts of the recommendation, if W3C explicitely reserves the right to change the spec under them any time before you're done?
Do they _really_ need to learn Windows, or just basic computing concepts?
I'm not sure what you mean, but the discussion started with the "show source" requirement, so I'll assume you don't include everyday computer usage as a computer concept, even basic.
Here, on Slashdot, we tend to exaggerate the importance of computer knowledge. Basic computing concepts (such as the capability to read/write a program or a script) are needed for engineers, system administrators, certainly for programmers, and a few others. But there are *many* more jobs where familiarity with Windows and Office is useful or even essential, while knowledge of computing theory and programming (even at a basic level) is not. Familiarity with Excel may for example make the difference between being hired for a secretarial position or not. So yes, pragmatically speaking, learning how to *use* (not program) Windows could be more useful for a poor 3rd world kid than getting source code access.
The only requirement is that it displays graphics and text on the screen, so there's absolutly no reason I can see why they couldn't learn all those things with a non-Windows OS
Agreed - but that's a different issue. My argument was not OS related; I was saying that the usefulness of the OLPC is not given by the capability to see the source code.
But the entire point of the OLPC is education. A computer that shows you its code, so you can learn and create with it.
That's a very Slashdotesque point of view and a good example of missing the forest because of one tree. You need to see the source only if you want the kid to become a programmer or maybe a sysadmin. The third world countries targeted by the OLPC have much higher and more urgent priorities. They need educated people in many other areas, not only programming. They need better, more knowledgeable farmers, workers, manufacturers, engineers, teachers, physicians, accountants, even managers and lawyers. Very, very few of the kids playing and learning now in those countries need bash or python. They do need however to learn how not to dig the outhouse near the well, how to avoid malaria, how to get more wheat out of their crops, how to start a business, how to sell their product in an increasingly globalized world. They need to learn how to access expertise already existing elsewhere, and they need to be able to do so easily. I'd argue that they even need to learn Windows, and thus get access to a whole variety of jobs where they use computers (non-programming positions, of course).
The source code is irrelevant for all those scenarios, which I believe are the core ones for the OLPC project.