I thought OLPC was about using technology to help kids to learn technology so that they can do any number of things that technology can potentially offer them.
the mission is to get the technology in the hands of as many children as possible.
It used to be that Negroponte was always saying that the focus of the project was education, that the laptop itself, the software, the content were all means to that end, and getting laptops, or "technology" more generally, to people wasn't the goal, but a means to the goal.
Now, the OLPC mission is, apparently, exactly what Negroponte used to deny it was: its a technology project, not an education project. When it was an education project, openness mattered. As a technology project, it loses all of its value (except to technology vendors), but using closed-sourced commercial software pushed by vendors whose interest is creating lock-in for the national governments that buy in to the project no longer conflicts with the mission that remains.
If I built a house out of cheese with a hammer made from cheese and the house began to crumble, would you say it's because of the hammer made from cheese or because cheese isn't a stable building material?
Well, I'd say it was the cheese because I know from information outside of the hypothetical that cheese generally isn't a stable building material.
OTOH, I've also known lots of structures made of wood, concrete, steel, etc., to collapse, not because of deficiencies of those as a building material, but because of the particular design features of the structures involved. Would you say that because some buildings made with those have collapsed, they are categorically poor building materials? Or would you recognize that the use of the building materials makes a difference?
Similarly, if -- and again, no actual concrete evidence has been presented to support this assertion -- Rails is incapable of scaling, that in and of itself proves nothing about Ruby. Now, if you can show both that it can't scale and that the reason it can't is an intrinsic feature of Ruby, then you have something to say against Ruby. But if it can't scale but you can't show that the reason is something intrinsic to Ruby, you've got nothing.
More concretely, its worth noting that one frequently-pointed-to limitation of Rails that is claimed to be implicated in scaling problems (that it isn't threadsafe and thus relies on multiple, expensive Ruby processes to handle multiple requests) is not true of several other Ruby web-app frameworks (Merb and Waves, for instance.)
When you've got something specific you can point to that shows (1) the inability of Rails to scale, and (2) the source of that inability within the Ruby language, perhaps you'll have an argument. As it is, all you've got is a highly emotional rant and a series of baseless insults.
Well for starters, active record and the notion that everything always should go to the database. In the rails world, caching refers to page generation where in like the ASP and J2EE worlds, there is also data caching from the database.
Using memcached to cache, among other things, ActiveRecord objects instead of always hitting the database has been a common practice for people using Rails (and lots of other frameworks, Ruby and otherwise) for years. So, AFAICT, you're just plain wrong here. Now, it may be a valid complaint that database caching isn't integrated into Rails, but its certainly not something foreign to the Rails world as you suggest.
No threading or service module notion. Everything is tied to servicing a web page. Long lived jobs mean long lived web page renders.
Assuming you write the long-lived jobs in Rails, which is just the wrong way to do it. You are right that everything written in Rails is centered around servicing web requests; if you need to trigger off long-running processes from that that are themselves only indirectly bound to the request-response cycle, you do that outside of Rails entirely. I would guess the easiest way to do that would be to use the database as the communications vehicle between Rails and whatever system you build to handle the long-running processes using ActiveRecord on the Rails side (and, if you are using Ruby "off the Rails" for the other end, possibly on that end as well), though there are other options.
Rails isn't even conceptually aimed at being a general alternative to the kind of technologies you hold it up against (J2EE in particular).
Both Waves and Merb are thread-safe; when (and they might already, I'm not sure) they can run on JRuby or Ruby 1.9 they'll be able to use native threads. (Without a GIL on JRuby, with one on Ruby 1.9, for now.)
Correct. Ruby is not the same thing as Rails. Rails is one of many web application frameworks written in Ruby, and it has many differences relevant to performance (and development) to any of the other ones. In fact, the motivation to develop many of the ones that are newer than Rails has been to address things that people found problematic in Rails. Rails having a problem doesn't mean that Ruby has that problem, any more than the fact that a particular piece of C code doesn't work right means that C is broken.
So if Ruby with Rails (Ruby) does not scale, I doubt another framework is going to do any better.
Ruby on Rails is not the same thing as Ruby, again. Its a framework. Its design is not the only framework design possible on Ruby, and if it really doesn't scale (something which many people argue without any concrete demonstration or apparent factual basis other than "someone else reportedly said it didn't"), those design choices and not the underlying language may be involved. Rails not scaling (if it doesn't) does not say anything about Ruby, and putting Ruby in parentheses after the name to imply that it is valid to generalize about Ruby from Rails doesn't change that.
It's funny though that other languages like Java and PHP have frameworks programmed in their native languages that scale just fine and Ruby doesn't...
Its far from established that Ruby doesn't in any sense that those other languages do; first, because its not established that Rails doesn't scale, and second because Rails isn't the whole universe of Ruby-based web application frameworks; what is true of Rails is likely not true of Merb (whose main motivation was addressing performance issues), or Waves or Nitro or Camping or...
My tests confirm it is 20 times slower than python in simple loops./blockquote
Since in many simple tests, JRuby and Ruby 1.9 are 10+ times faster than Ruby 1.8, I wouldn't be really impressed that on some simple tests Python is 20x faster than Ruby 1.8. Not that any of the speed tests in the tables on the linked page show a 20:1 ratio in either direction between Python 2.4 and Ruby 1.8; and the only one that is over 10:1 in favor of Python doesn't use similar methodology in the Python and Ruby tests.
They are debating on whether the language can scale. That's why they are thinking of using JAVA or PHP instead. If they thought the language could scale on it's own and they already had fully trained staff of RUBY developers, it wouldn't be a debate now would it?
Even granting, arguendo, that the rumors TechCrunch is reporting should be treated as fact, that doesn't follow. If there concern is not with the languages scalability, but the framework, then they would evaluate other frameworks, including possibly those based in other languages, especially if they've decided that they really don't want to right their own framework from scratch, regardless of what the language could support if used right. Having Rails experience may be a plus in favor of another Ruby framework (especially one that was similar), but its doesn't limit the search space for replacements to other Ruby frameworks if you have a problem with Rails, its just a factor you weigh in considering replacements.
BTW, neither Java nor Ruby are initialisms, and they shouldn't be presented in all caps.
And for all those Ruby people in denial to the fact that people have been saying this for years, here is your proof yet again.
Since when is an unconfirmed second-hand report "proof" of anything. And, anyway, even if the reports were true, they don't prove that Ruby can't scale since one of the things they are reportedly considering dumping Rails for is Ruby without using the Rails framework.
Rumor is not the same thing as proof, and, even if it was, a particular user finding a system doesn't scale well for them doesn't prove that that system can't scale, and, even if it did, Ruby is not the same thing as Rails.
That's generally the goal of the left-wing not the right-wing.
Yeah, the right-wing is definitely not the side that wants to limit government except for law enforcement and military while increasing the scope of power, authority, and prerogatives of those two sectors of government.
The summary asserts that Canonical is a "traditional for-profit company," but the Wikipedia entry you point to paints a picture of a company that is not traditional.
Its a perfectly traditional for-profit, privately held company, so long as you keep in mind that all "for-profit" means is that it isn't specially government recognized "not-for-profit" (it doesn't mean that profit is its only or central purpose, particularly), and that a traditional "for-profit" company exists to serve the common interests of its owners (financial returns are often one of those, either directly or as essential to serving any other shared interests, but they aren't the sole unifying interests in many companies [they are pretty much that in many broadly held and pretty much all publicly-traded firms, because there the investors often are at arms length from each other and only invest based on perceived financial returns].)
What on earth are you talking about...editing Wikipedia with a biased viewpoint is a crime?
No, but if you have either specifically personally or as a member of a group had authorization to edit Wikipedia revoked, and you, knowing this, use technical circumventions or other means to continue to access and edit Wikipedia, that may be unlawful and even criminal.
If it was a NASA rocket motor there would be congressional investigations, news people camped out waiting for news of the investigation at NASA headquarters etc.
Only once a manned spacecraft blew up. The actual history of actual problems and treatment of reports of problems at NASA I think demonstrates this rather clearly.
While rigged, insecure, or simply inaccurate voting machines might also lead to deaths (and even far more of them), the connection isn't as immediate, obvious, visible and dramatic.
value can start as an int/double/float your choice.
in the end newValue does not alwasy equal value.. even though it should.. i understand floating point errors but i first saw this cause a problem with value being a double 8.12
Yeah, so? Floating point errors on values that aren't positive or negative powers of two are rampant in any system using approximate binary floating point math, rather than exact math. That's the default for non-integer math for most programming languages (Java, C, C++, Javascript, Ruby, Python, and many more.) There are some languages that do exact arbitrary-precision decimal math by default unless a value used which has no exact representation (Scheme comes to mind), but they are rather the exception rather than the rule. And, if you need exact math, most major languages have exact math libraries available (for Java, look into BigDecimal.)
oddly it isn't consitant from one CPU to the next but all the cpu's i have tested will have error's at and all have been with less than 1k amounts..
Floating point errors are a result of conversion to and from binary representation, and have no connection to the size of the number.
it is odd as hell but it is the one reason i don't use java.. if i can't trust it to do basic math then i can't trust it at all
BigDecimal is in the standard library; otherwise, Java's floating point math behaves just like binary floating point in most languages, with the same kind of problems.
I boggled at that too, but I simply thought I misunderstood the article (English isn't my native language.) I keep hearing that Ruby's interpreter is rubbish, but I had no idea it could be beaten by a JavaScript implementation running a Ruby interpreter.
The JavaScript implementation isn't running a Ruby interpreter, its running a (not full featured, as I understand) Ruby 1.9 bytecode interpreter. Comparing Ruby 1.8.x, which isn't bytecode compiled vs. an JavaScript interpreter for Ruby 1.9 bytecodes operating on precompiled bytecodes generated by the stock Ruby 1.9 bytecode compiler, and mostly what you are learning is mostly that (1) Ruby 1.9 is much better on the tested task than Ruby 1.8.x, and (2) much of the speedup comes from using a bytecode approach.
(I've seen tests on narrow tasks where Ruby 1.9 was something like 20x as fast as Ruby 1.8.x, so I'm not at all surprised that you get examples of things for which this approach is 5x as fast as Ruby 1.8.x.)
As a specific concept, maybe. But it absolutely does fit -- more generally, it is about explicitness vs implicitness. 99% of the time, if something's indented, I want it scoped that way -- I wouldn't mind typing explicit begin/end blocks or brackets for the other 1% of the time.
Of course, if that's your preference, you can always use Python; there are, IMO, boundaries to the utility of implicit-over-explicit (Rails, itself, sometimes seems to cross over some of them; Python's indentation-based-scoping is far over the line, IMO. [note: I like Python, generally, aside from the handling of indentation.])
"Convention over configuration" is mostly, IMO, a good idea in the range where Rails applies it; OTOH, like most short maxims, if you generalize it further and make it a quasi-religious precept, it does more harm than good.
Even in Rails, a lot of the applications of DRY are, again, about explicitness vs implicitness -- for example, one place Rails is not entirely DRY is validations, many of which could be inferred from the schema. By providing both a column constraint (NOT NULL, say) and an ActiveRecord constraint (validates_uniqueness_of), Rails is forcing you to repeat yourself. (Unless you're using, say, the schema_validations plugin.)
Saying something explicitly twice vs. saying it explicitly only once is not really "explicitness vs. implicitness". Its repeating vs. not repeating, as the name DRY suggests.
More generally, when asked why he chose Ruby, DHH said that it was the language in which he could write "the most beautiful code". End statements are not beautiful to me. Yes, it's subjective.
To me, the programming constructs that create large cascades of end statements are generally not beautiful (they are, sometimes, the expeditious way to acheive a particular task; some tasks don't have elegant expression), whether or not you have explicit end statements. The problem, to me, isn't with the language (or, rather, not with the use of explicit scope in the language; its often with the range of substantive constructs available.)
One more thing: I haven't done a lot of Python code, but I have done a lot of haml and sass lately. It's interesting that the same people who love haml never breathe a word about Ruby's end statements -- even when said end statements are actually abstracted away by haml!
Yeah, most people aren't fanatical extremists; they see that some things can be useful in one area and counterproductive in another.
Well, there are all sorts of government agencies that (sometimes) wear uniforms, carry guns, and even operate overseas.
Yes, but there are only two departments that control "Armed Forces" and four that control "uniformed services", as defined in Subtitle A ("General Military Law") of Title 10 of the United States Code.
There's five branches in the U.S. military. Four in the Department of Defense, and one in the Department of Homeland Security.
There are five branches of the U.S. Armed Forces (defined in 10 USC 101(a)(4)) and seven branches of the U.S. uniformed services (defined in 10 USC 101(a)(5)) (the two not included in the Armed Forces being in the Department of Health and Human Services and the Department of Commerce). The uniformed services that are not part of the armed forces were specifically created as uniformed services because of their military role, (in the case of the one now part of the Department of Commerce, most specifically to assure that members would be treated as combatants rather than spies if captured in wartime while performing their duties on the battlefied.)
I think that the projects success demands free software and cheap hardware. I believe we agree on this.
I don't think we do; I think that the economics of education are such that the only thing necessary for the project to succeed, ultimately, is adequate quality Free (as in libre) software and content. If it works on any existing hardware platform, and the software and content are compelling, the hardware will be cheap enough in reasonably short order.
We differ in this: you see the non-support of non-free software as a necessary condition for having free software.
Um, no, we don't. For one thing, I don't see "the non-support of non-free software as a necessary condition for having free software". OTOH, I do see expenditure of resources developing software for a non-Free platform as a choice that reduces the available resources for improving the quality of the software stack on the Free platform.
But that's not the point on which we disagreed in your previous post and my response; that disagreement is this: you see it as a fixed fact that the major cost of the systems will be the hardware cost, whereas I see that as being true if and only if the software and content is Free. Even free (gratis) software and content from a commercial vendor is likely to become a major cost down the road in maintenance and upgrades, and licensing restrictions will prevent even a large user community from becoming effectively self-supporting, and with major non-Free components, the costs of those components will likely be a major long-term cost, even if they are initially free. With Free (libre) software and content, while there will be some maintenance and upgrade costs, particularly if the upstream supplier doesn't keep providing free support, the user community can become self-supporting in a way which can control the costs to any user, without any vendor lock-in providing a virtual support "tax" to a monopolistic vendor who can take advantage of the need for continuity and the ability to exclude others from modifying its code to charge monopoly rents on those services.
While I agree with most of your post, I have to disagree with this:
It is true that there are a lot of companies that dual-license and don't really run a convincing community development at all, they are abusing the process.
Offering software under the GPL -- either exclusively or in a dual-licensing arrangement -- doesn't obligate (even morally) the licensor to run a community development process ("convincing" or otherwise). Its not "abusing" the process not to run a community development process, or not to run one that is "convincing".
The GPL gives you the right to develop your own derivatives of the software, it doesn't give you a legitimate basis for expecting that the person who gave you licensed the software to you under the GPL will run a development process you can participate in.
This is the crucial argument, isn't it? But it's a pragmatic question. I don't think the usefulness of Linux to users is at issue, it's the usefulness of Sugar. If the project takes resources to make sure Sugar runs OK on XP, it doesn't threaten the utility of Linux, but the utility of Sugar.
Right. Which threatens the utility of the project, insofar as the content/software end of the project relies on Sugar.
Except the real costs of this program, if expanded to its envisioned potential, are going to be hardware.
The only way the real costs are going to be hardware is if the software and content remains Free.
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.
Untrue. Its quite possible to build a business around OSS and make money; you don't make the money by selling software licenses, of course, but that doesn't stop you from making money from your understanding of the code (either as the initial developer or just someone who has made good use of the availability of the code) and your own business acumen, writing skills, ability to provide support for the software, etc.
The comparison of proprietary software (at least software with a strong network effect like MS Windows and MS Office) to addictive drugs is actually pretty accurate. People who use proprietary software think it's necessary, refuse to admit they have a problem, and try to push the stuff on other people.
Well, for many of us, it actually is necessary (network effects are like that), and we readily admit that it is, though sometimes necessary, a problem. Its hardly as if the computer users of the world are divided into two non-overlapping camps of "people who use Free software" and "people use use proprietary software".
Slashdot Mirror
OLPC was about that.
OLPC is about something else now.
It used to be that Negroponte was always saying that the focus of the project was education, that the laptop itself, the software, the content were all means to that end, and getting laptops, or "technology" more generally, to people wasn't the goal, but a means to the goal.
Now, the OLPC mission is, apparently, exactly what Negroponte used to deny it was: its a technology project, not an education project. When it was an education project, openness mattered. As a technology project, it loses all of its value (except to technology vendors), but using closed-sourced commercial software pushed by vendors whose interest is creating lock-in for the national governments that buy in to the project no longer conflicts with the mission that remains.
Well, I'd say it was the cheese because I know from information outside of the hypothetical that cheese generally isn't a stable building material.
OTOH, I've also known lots of structures made of wood, concrete, steel, etc., to collapse, not because of deficiencies of those as a building material, but because of the particular design features of the structures involved. Would you say that because some buildings made with those have collapsed, they are categorically poor building materials? Or would you recognize that the use of the building materials makes a difference?
Similarly, if -- and again, no actual concrete evidence has been presented to support this assertion -- Rails is incapable of scaling, that in and of itself proves nothing about Ruby. Now, if you can show both that it can't scale and that the reason it can't is an intrinsic feature of Ruby, then you have something to say against Ruby. But if it can't scale but you can't show that the reason is something intrinsic to Ruby, you've got nothing.
More concretely, its worth noting that one frequently-pointed-to limitation of Rails that is claimed to be implicated in scaling problems (that it isn't threadsafe and thus relies on multiple, expensive Ruby processes to handle multiple requests) is not true of several other Ruby web-app frameworks (Merb and Waves, for instance.)
When you've got something specific you can point to that shows (1) the inability of Rails to scale, and (2) the source of that inability within the Ruby language, perhaps you'll have an argument. As it is, all you've got is a highly emotional rant and a series of baseless insults.
Using memcached to cache, among other things, ActiveRecord objects instead of always hitting the database has been a common practice for people using Rails (and lots of other frameworks, Ruby and otherwise) for years. So, AFAICT, you're just plain wrong here. Now, it may be a valid complaint that database caching isn't integrated into Rails, but its certainly not something foreign to the Rails world as you suggest.
Assuming you write the long-lived jobs in Rails, which is just the wrong way to do it. You are right that everything written in Rails is centered around servicing web requests; if you need to trigger off long-running processes from that that are themselves only indirectly bound to the request-response cycle, you do that outside of Rails entirely. I would guess the easiest way to do that would be to use the database as the communications vehicle between Rails and whatever system you build to handle the long-running processes using ActiveRecord on the Rails side (and, if you are using Ruby "off the Rails" for the other end, possibly on that end as well), though there are other options.
Rails isn't even conceptually aimed at being a general alternative to the kind of technologies you hold it up against (J2EE in particular).
Both Waves and Merb are thread-safe; when (and they might already, I'm not sure) they can run on JRuby or Ruby 1.9 they'll be able to use native threads. (Without a GIL on JRuby, with one on Ruby 1.9, for now.)
Correct. Ruby is not the same thing as Rails. Rails is one of many web application frameworks written in Ruby, and it has many differences relevant to performance (and development) to any of the other ones. In fact, the motivation to develop many of the ones that are newer than Rails has been to address things that people found problematic in Rails. Rails having a problem doesn't mean that Ruby has that problem, any more than the fact that a particular piece of C code doesn't work right means that C is broken.
So if Ruby with Rails (Ruby) does not scale, I doubt another framework is going to do any better.
Ruby on Rails is not the same thing as Ruby, again. Its a framework. Its design is not the only framework design possible on Ruby, and if it really doesn't scale (something which many people argue without any concrete demonstration or apparent factual basis other than "someone else reportedly said it didn't"), those design choices and not the underlying language may be involved. Rails not scaling (if it doesn't) does not say anything about Ruby, and putting Ruby in parentheses after the name to imply that it is valid to generalize about Ruby from Rails doesn't change that.
Its far from established that Ruby doesn't in any sense that those other languages do; first, because its not established that Rails doesn't scale, and second because Rails isn't the whole universe of Ruby-based web application frameworks; what is true of Rails is likely not true of Merb (whose main motivation was addressing performance issues), or Waves or Nitro or Camping or
Even granting, arguendo, that the rumors TechCrunch is reporting should be treated as fact, that doesn't follow. If there concern is not with the languages scalability, but the framework, then they would evaluate other frameworks, including possibly those based in other languages, especially if they've decided that they really don't want to right their own framework from scratch, regardless of what the language could support if used right. Having Rails experience may be a plus in favor of another Ruby framework (especially one that was similar), but its doesn't limit the search space for replacements to other Ruby frameworks if you have a problem with Rails, its just a factor you weigh in considering replacements.
BTW, neither Java nor Ruby are initialisms, and they shouldn't be presented in all caps.
Define small-scale sites and explain how that definition applies to yellowpages.com.
Since when is an unconfirmed second-hand report "proof" of anything. And, anyway, even if the reports were true, they don't prove that Ruby can't scale since one of the things they are reportedly considering dumping Rails for is Ruby without using the Rails framework.
Rumor is not the same thing as proof, and, even if it was, a particular user finding a system doesn't scale well for them doesn't prove that that system can't scale, and, even if it did, Ruby is not the same thing as Rails.
Nice try, though.
Yeah, the right-wing is definitely not the side that wants to limit government except for law enforcement and military while increasing the scope of power, authority, and prerogatives of those two sectors of government.
Well, except in the real world.
Its a perfectly traditional for-profit, privately held company, so long as you keep in mind that all "for-profit" means is that it isn't specially government recognized "not-for-profit" (it doesn't mean that profit is its only or central purpose, particularly), and that a traditional "for-profit" company exists to serve the common interests of its owners (financial returns are often one of those, either directly or as essential to serving any other shared interests, but they aren't the sole unifying interests in many companies [they are pretty much that in many broadly held and pretty much all publicly-traded firms, because there the investors often are at arms length from each other and only invest based on perceived financial returns].)
No, but if you have either specifically personally or as a member of a group had authorization to edit Wikipedia revoked, and you, knowing this, use technical circumventions or other means to continue to access and edit Wikipedia, that may be unlawful and even criminal.
Only once a manned spacecraft blew up. The actual history of actual problems and treatment of reports of problems at NASA I think demonstrates this rather clearly.
While rigged, insecure, or simply inaccurate voting machines might also lead to deaths (and even far more of them), the connection isn't as immediate, obvious, visible and dramatic.
Yeah, so? Floating point errors on values that aren't positive or negative powers of two are rampant in any system using approximate binary floating point math, rather than exact math. That's the default for non-integer math for most programming languages (Java, C, C++, Javascript, Ruby, Python, and many more.) There are some languages that do exact arbitrary-precision decimal math by default unless a value used which has no exact representation (Scheme comes to mind), but they are rather the exception rather than the rule. And, if you need exact math, most major languages have exact math libraries available (for Java, look into BigDecimal.)
Floating point errors are a result of conversion to and from binary representation, and have no connection to the size of the number.
BigDecimal is in the standard library; otherwise, Java's floating point math behaves just like binary floating point in most languages, with the same kind of problems.
The JavaScript implementation isn't running a Ruby interpreter, its running a (not full featured, as I understand) Ruby 1.9 bytecode interpreter. Comparing Ruby 1.8.x, which isn't bytecode compiled vs. an JavaScript interpreter for Ruby 1.9 bytecodes operating on precompiled bytecodes generated by the stock Ruby 1.9 bytecode compiler, and mostly what you are learning is mostly that (1) Ruby 1.9 is much better on the tested task than Ruby 1.8.x, and (2) much of the speedup comes from using a bytecode approach.
(I've seen tests on narrow tasks where Ruby 1.9 was something like 20x as fast as Ruby 1.8.x, so I'm not at all surprised that you get examples of things for which this approach is 5x as fast as Ruby 1.8.x.)
Of course, if that's your preference, you can always use Python; there are, IMO, boundaries to the utility of implicit-over-explicit (Rails, itself, sometimes seems to cross over some of them; Python's indentation-based-scoping is far over the line, IMO. [note: I like Python, generally, aside from the handling of indentation.])
"Convention over configuration" is mostly, IMO, a good idea in the range where Rails applies it; OTOH, like most short maxims, if you generalize it further and make it a quasi-religious precept, it does more harm than good.
Saying something explicitly twice vs. saying it explicitly only once is not really "explicitness vs. implicitness". Its repeating vs. not repeating, as the name DRY suggests.
To me, the programming constructs that create large cascades of end statements are generally not beautiful (they are, sometimes, the expeditious way to acheive a particular task; some tasks don't have elegant expression), whether or not you have explicit end statements. The problem, to me, isn't with the language (or, rather, not with the use of explicit scope in the language; its often with the range of substantive constructs available.)
Yeah, most people aren't fanatical extremists; they see that some things can be useful in one area and counterproductive in another.
Yes, but there are only two departments that control "Armed Forces" and four that control "uniformed services", as defined in Subtitle A ("General Military Law") of Title 10 of the United States Code.
There are five branches of the U.S. Armed Forces (defined in 10 USC 101(a)(4)) and seven branches of the U.S. uniformed services (defined in 10 USC 101(a)(5)) (the two not included in the Armed Forces being in the Department of Health and Human Services and the Department of Commerce). The uniformed services that are not part of the armed forces were specifically created as uniformed services because of their military role, (in the case of the one now part of the Department of Commerce, most specifically to assure that members would be treated as combatants rather than spies if captured in wartime while performing their duties on the battlefied.)
I don't think we do; I think that the economics of education are such that the only thing necessary for the project to succeed, ultimately, is adequate quality Free (as in libre) software and content. If it works on any existing hardware platform, and the software and content are compelling, the hardware will be cheap enough in reasonably short order.
Um, no, we don't. For one thing, I don't see "the non-support of non-free software as a necessary condition for having free software". OTOH, I do see expenditure of resources developing software for a non-Free platform as a choice that reduces the available resources for improving the quality of the software stack on the Free platform.
But that's not the point on which we disagreed in your previous post and my response; that disagreement is this: you see it as a fixed fact that the major cost of the systems will be the hardware cost, whereas I see that as being true if and only if the software and content is Free. Even free (gratis) software and content from a commercial vendor is likely to become a major cost down the road in maintenance and upgrades, and licensing restrictions will prevent even a large user community from becoming effectively self-supporting, and with major non-Free components, the costs of those components will likely be a major long-term cost, even if they are initially free. With Free (libre) software and content, while there will be some maintenance and upgrade costs, particularly if the upstream supplier doesn't keep providing free support, the user community can become self-supporting in a way which can control the costs to any user, without any vendor lock-in providing a virtual support "tax" to a monopolistic vendor who can take advantage of the need for continuity and the ability to exclude others from modifying its code to charge monopoly rents on those services.
Offering software under the GPL -- either exclusively or in a dual-licensing arrangement -- doesn't obligate (even morally) the licensor to run a community development process ("convincing" or otherwise). Its not "abusing" the process not to run a community development process, or not to run one that is "convincing".
The GPL gives you the right to develop your own derivatives of the software, it doesn't give you a legitimate basis for expecting that the person who gave you licensed the software to you under the GPL will run a development process you can participate in.
Yes, making lots of money is extremely difficult. That's why most people aren't rich.
Right. Which threatens the utility of the project, insofar as the content/software end of the project relies on Sugar.
The only way the real costs are going to be hardware is if the software and content remains Free.
Untrue. Its quite possible to build a business around OSS and make money; you don't make the money by selling software licenses, of course, but that doesn't stop you from making money from your understanding of the code (either as the initial developer or just someone who has made good use of the availability of the code) and your own business acumen, writing skills, ability to provide support for the software, etc.
Well, for many of us, it actually is necessary (network effects are like that), and we readily admit that it is, though sometimes necessary, a problem. Its hardly as if the computer users of the world are divided into two non-overlapping camps of "people who use Free software" and "people use use proprietary software".