Patent lawyer: "Why yes! Of course you should pay me $10,000! Otherwise the boogeyman will get you!"
The $10,000 cost referred to is the cost of filing the final, non-provisional application, not the cost of legal fees. Since the cost is to the company, if the company has in-house counsel, talking to them should be far less expensive, and would be the kind of thing that would be pretty irresponsible not to do (and if special talent that is outside of the company is needed, that's something in-house counsel should be able to determine, and should be able to assist in locating someone who isn't going to blatantly violate legal ethics by acting in their own interest rather than their clients, and, failing that, should be able to get the ball rolling on the legal malpractice action against the outside counsel if such a violation does occur.)
Also, what kind of document would I need to make official the public-domaining of the app?
If you have the source code, just drop it on SourceForge or make it available for download on your site with a copy of the GPL as a license file [gnu.org].
No, the GPL will not "make official the public-domaining of the app". The GPL is a copyright license that imposes all kinds of terms on those making derivative works, while something being in the public domain means there are no copyright-based restrictions on those making derivative works. A BSD-style license would be more like releasing it into the public domain, but still quite distinct.
Strictly speaking, there is, AFAIK, no way in the US to release a copyrightable work to the public domain officially. When you say that a work that you control the copyright is in the public domain, you've mostly just issued a gratuitous public license for other people do with it what they want, that is as revocable as any other gratuitous license, but may be enforceable to the benefit of the licensee (e.g., anyone who acted under the purported release into the public domain) under the principle of promissory estoppel.
Anyhow, asking Slashdot for this kind of business/legal advice is like asking a forum of MBAs or lawyers for programming advice.
Re:Markup language != programming language
on
FBML Essentials
·
· Score: 1
The ML are just responsible for the View part in the MVC architecture. To make a complete application, you need also the Model and the Controller.
Not all applications use MVC architecture, and markup languages can certainly be used outside of the MVC architecture, and can certainly be used for a lot more than views. Example: XML is a fairly well-known markup language. It can be used for things that are certainly view-oriented (XHTML, XSL-FO). It can also be used for things that are not exclusively view-oriented (WS-BPEL, XPDL, XSLT).
I have never understood why Microsoft does this. Well, beyond the "make more money" aspect but that's because they're a company in the business of making money. The thing is, I just don't understand _how_ this leads to them making more money. In my mind, having one-and-only-one version of your operating system seems so much more efficient and cost-effective.
The "evil" reason it works is market segmentation. Packaging the features demanded by different subsets of the market into different SKUs offered at different prices, enables Microsoft to charge the maximum price in each market segment.
The less "evil" reason it works is it gives each segment the experience they want out of the box; note that Ubuntu also does lots of different editions (Ubuntu Desktop, Ubuntu Server, Ubuntu Studio, Kubuntu, Xubuntu, Edubuntu) targeted at different markets, too (though, of course, they are all both free and Free, and once you have one you can get all the features of all of them without any difficulty, by design) simply to give users the out-of-the-box experience they want.
Digital goods -- from music and video to Wikipedia -- can be produced and distributed at virtually no marginal cost, and so, by the laws of economics, price has gone the same way, to $0.00.
If this was the whole explanation, it would not make sense "by the laws of economics". "Virtually no" is not the same thing as "no"; there is a marginal cost and it needs to be paid. Plus, there are fixed costs, and even if the marginal costs per unit were $0, producers who can't recoup their fixed costs would be losing money. If many people are getting something at no cost, someone else is paying those costs. Usually, what is free is either charity of one form of another (where the producer--or at least the people funding the producer--derives subjective utility from other people getting the benefit of the good, and thus is willing to eat the cost), or promotion of one form or another (where the producer gives the good away for free to build exposure and future profitability for that good, or to build demand for another good, that the producer can then profit from.) Sun doesn't give the JRE and JDK away for free (and Microsoft doesn't give away the free versions of Visual Studio) because of an irrational expectation that $0/copy times a really large number of copies will somehow make back their costs associated with those products, they do it because they expect it will increase demands for the goods and services that they charge money for enough to warrant the costs.
Now, the low marginal costs of digital goods delivered online make both of these kinds of free goods a lot more practical, so there is a lot more free.
Now if there were an easy way to say that for program X:/lib/liblib.so ==/lib/liblib.so.4 and for program Y:/lib/liblib.so ==/lib/liblib.so.5
What if properly packaged applications didn't use system-wide shared library directories as the first resort, but looked first in application-specific ones that were managed by the package management system and contained symlinks to the appropriate libraries identified as dependencies, and only looked in the system-wide shared library directory (which the package management system would populate with the most current [or possibly user-designated default, even if not most current] version of libs loaded through the package management system using the basic name of the lib, while alternative versions were stored using something like the name + version format you suggest (though I think I've seen "foo.so.n" used for other purposes, so maybe not that exact system), and used as targets of the symlinks for apps installed through the package management system?
Re:I am afraid, there is lack of direction for Rub
on
Ruby 1.9.1 Released
·
· Score: 1
But now you are comparing RoR (language + framework) to PHP (language). Bad comparison. Thats like comparing a submarine to a volkswagon. I was strictly comparing languages based upon benchmarks of the languages and NOT the frameworks.
PHP is a language a templating system designed very much for building web applications.
Ruby is a general purpose programming language, that is largely popular due to a particular web app framework.
Comparing bare Ruby with no non-standard libraries to PHP for web apps hosted behind another server is at least as bad of a comparison, and arguably far worse, than comparing RoR to PHP.
I'm willing to take a second look at Ruby but to date it has always come second as a web language for speed, scalability.
I've yet to hear a coherent argument for how Ruby fails at scalability compared to any other language, whether PHP or anything else.
The thing Ruby DOES provide that enable you to develop faster (like obfuscating looping and stuff like that) unfortunately is also it's achilles heel and causes extra processing to occur causing it to be slower than other languages doing the same tasks.
Ruby doesn't obfuscate looping. I have no idea what you mean by "stuff like that" other than "other stuff that isn't true, either".
What you describe is a build system, not a package manager.
No, its a package manager that includes a build system.
One of the many mis-features of RPM is that it pretends to know how to build packages from source.
If building from source is a desired feature, the misfeature is that it fails to do so well (presuming it does; I have very little experience using RPM.)
What you're really asking is that all distributions come with the same versions of the same libraries, applications and utilities, all compiled with the same options for the same processor architecture.
Uh, he seemed to me to be asking for a unified package manager, not at all what you describe.
If you have a unified packaging architecture, you don't need the rest (especially if the package manager can handle building and installing source packages), since what the OS is distributed with doesn't matter, what matters is what dependencies can be satisfied on it, and with a unified packaging system that can handle source packages, it is conceptually simple to minimize the differences in terms of what dependencies can be satisfied.
Now, admittedly, getting a good enough packaging system to do this well enough to be the "standard Linux packaging system" (or perhaps an even broader standard that could be used for Linux and for other Free *n*xen) is a big task. But progress toward it has a potentially big payoff even before it becomes a standard.
But packaging follows directly with the distro issue.
No, it doesn't. Sure, there a couple of base distributions now that also have unique packaging systems, but that doesn't mean that a packaging system has any inherent reason to be tied to a particular distro. You don't need to solve the diversity of distros problems to get a packaging system that solves the packaging problems, and once you have that, you don't need to get rid of multiple competing distros to get that widely implemented.
Now, admittedly, any unification is the same type of problem as the distro issue, in that you need to convince people working on multiple things to work on the same thing, but unlike OS distros, there really shouldn't need to be multiple packaging systems to serve different niches.
Re:I am afraid, there is lack of direction for Rub
on
Ruby 1.9.1 Released
·
· Score: 1
Scaling isn't a language issue normally but in the case of Ruby, it seems to have an inherent flaw with it's threads which causes it to 'top out' in comparison to other languages
Ruby 1.8.x uses green threads in a single process per interpreter instance, JRuby uses Java threads (which are native threads on most or all platforms, IIRC), Ruby 1.9.0/1.9.1 use native threads with a GIL, exactly, AFAIK, like Python up through and including 3.0. Each of these Ruby implementations will have different threading performance. Of course, none of that matters for Rails, which is probably where the issue you are talking about arouse rather than Ruby itself, since Rails is still, AFAIK, single-threaded throughout, with experimental threading support.
For example, as PHP determines a need for more processes, it scales up to handle more concurrent requests.
Every Ruby implementation contains support for spawning additional processes, though deciding whether and when to do this isn't a language function, its an application (or framework, or even application server) function.
I think the important question to ask is this: if everyone's using the same packaging system (which they fucking well should, it's a no-brainer), then why not take that next step to basing all relevant distros off the same core distro?
If we address the packaging issues, that might well be a logical next step. But if we address the packaging issues, whether the distros are based on the same base distro or not won't matter very much (indeed, if the packaging issues are handled well enough, whether they are using Linux or *BSD might not be a particularly big deal.)
I need a feature that is present in a new version of an application. There is no package available for that version in my distro's repositories.
This is a different problem. Again, though, a common package management system doesn't mean you are restricted to a single set of repositories.
An application has been abandoned by developers, but I still use it. A new feature of a package it depends on breaks backward compatibility. Therefore, to keep my app working, a dependency can no longer be updated. Now I have another application that needs the NEW version of the dependency. I can't have both.
This is usually (I am inclined to say always) a package management or packaging problem; there is no reason, generally, why you shouldn't be able to have multiple versions of a library, application, or pretty much any other dependency side by side. You may, in some cases, need not just technical improvement but improvements in "best practices" to make this work, but its not at all an intractable problem, and its a pretty important one even within existing distros, much less as part of a Linux Packaging Grand Unification.
My choices tend to be hacking it together until it works, or waiting indefinitely in hopes that someone will assemble an appropriate package. The former tends to weaken my system's continuity. The latter tends to not let me run software.
With an agreed common, and well-designed, package management system, the incentive would be high for those building software to provide packages. One reason why you won't find software packaged for your distro now is that there are competing packaging systems (and sometimes, even with the same package management system, you can't seemlessly use packages for one distro on another), so any packages that are provided will be useful to only a limited slice of the audience. Improvements in that direction will naturally reduce the "the thing I want doesn't have packages for my distro" problem.
So? I personally don't care where the problem is. It's still an unresolved problem.
Where the problem is is kind of intimately related to how the problem can be addressed.
And it's not going to get fixed anytime soon.
The problem of packaging things to allow seemless side-by-side installs of different versions of components so that components that depend on them can operate without conflicts (both on the side of package management system issues and packaging issues) is a lot easier to solve than the supposed problem of "too many Linux distributions", and a lot more amenable to solution.
Yes, and that works great, in theory. However, once you want to install an app that the repository doesn't have (or doesn't have the version you need), things begin to break down.
A common package management system does not require one shared repository. (Though of course that, or at least a shared repository discovery system, would be nice as a convenience.)
In Linux, two different applications that depend on two different versions of a common system can ruin continuity.
Unless the "common system" is the kernel, this is a problem in design of either the package management system or the particular packages.
And let's face it... KDE is modern but broken in many ways
KDE 4.1.4 doesn't seem any more broken than any major commercial desktop environment I've used, and is more pleasant than the XP or Vista desktops (its been a long time since I've used a Mac, so I won't comment there); I'll admit that it was a bad idea for Kubuntu to bundle KDE 4.1 in 8.10 when it was really unready, and the 4.1.4 is only in the pre-released updates repo, so for casual or cautious users of what is probably the biggest KDE-centered distro, KDE seems pretty broken. I hope the Kubuntu maintainers aren't being as overoptimistic in including 4.2 as the default in 9.04.
The only thing that, it seems to me, is really broken about KDE, at least in the 4.x line, is premature releases that take several point releases before they are really ready for daily use.
You don't NEED to use CLI for apt because of Synatpic -- wonderful graphical interface for managing apt.
If the base install is minimal and leaves the user to install "options" like X and a window manager, then, yeah, you need to use a CLI for apt before you can even get to a position where you can use Synaptic.
Of course, you could have multiple distributions all based on the same distro, many of which come with GUIs included. But then the debate is over which streamlined base distro and package management system to keep and how to convince everyone working on other distros to move over to it.
Fine. Everyone should stop working on your favorite distro now, and work on my favorite distro instead, okay? That'll get us "a little less fragmentation".
Calls for "less fragmentation" are vacuous without a call to unite behind something specific; then we can debate the pros and cons of what would be gained and what would be lost. Of course, the people you really have to convince are the people working on whatever would be axed, since its an open source community and the only way to make that happen is to convince those people to stop working on what they've been working on and start working on something else.
We do need different distros for different needs, the problem is there's also a lot of distros filling the same needs and some do a pretty poor job of it such that the resources would be better spent on a competing distro.
I suspect that most people agree with that.
Where they disagree is on which distros are doing the right thing and which are wasting their time. Its pretty obvious that they disagree on that, because if they didn't, everyone would be working on the same distros now, and there would be no issue.
Also, its not like the developers that are scratching their own itch working on "distro x" would necessarily be as interested in working on "distro y". The Linux Community isn't a corporation with fixed resources and a central command that can redistribute them wherever it wants. If people aren't working on what they want to be working on, those resources don't go somewhere else, they just go out of the community entirely.
Windows is dominant partially because if someone writes an application for Windows, everyone with Windows (in most cases) can run it without significant installation and configuration and version incompatibility problems.
Insofar as that's true, you don't really need a common distribution to address that, a common package management system that can handle building and installing source-base packages would be sufficient.
We need a main, reliable, one size fits all DESKTOP distro. that's what we need.
The problem is one size doesn't fit all; Windows is dominant despite that because MS was in the right place at the right time to become so ubiquitous that instead of fitting people's needs, peopel would fit their needs to MS's products because they were the only option, and it has a lot of leverage from that that its been milking ever since.
Re:I am afraid, there is lack of direction for Rub
on
Ruby 1.9.1 Released
·
· Score: 1
but do you really think a project gets developed faster because a language has blocks and closures?
Yes.
I've experienced quite the opposite...if you start using a language that is particularly good in one thing, every problem gets resolved by using this one thing. Especially in ruby, where you have to use blocks which are quite unreadable for everything or you're a noob
Since Ruby blocks are structurally pretty much identical to Ruby method definitions, which are themselves pretty similar to function/method definitions in most vaguely C-like (or Algol-derived, if you prefer) languages, I find describing them as "quite unreadable" to be rather odd. If you have a lot of programming experience but none of it in other languages where passing around anonymous functions as arguments is commonplace, it probably seems unusual at first and takes a little bit of time to get over that feeling, but I wouldn't think it would be too big of a barrier for most people.
Re:I am afraid, there is lack of direction for Rub
on
Ruby 1.9.1 Released
·
· Score: 1
Twitter.
Rails wasn't Twitter's problem, though there was some initial finger pointing in that direction. The problem was that Twitter initially had a simple synchronous architecture (which, sure, is the easiest thing to do with Rails, as with most frameworks) when it needed an asynchronous messaging architecture, and that they didn't do database optimizations that are out of scope for the web application framework. See, among other things, this article.
It's not bogus at all. My point is that the statement "creates 120,000 jobs" is completely dishonest.
The argument that moving money from one use to another cannot create jobs is bogus. Determining whether the statement "creates 120,000 jobs" is accurate relies on information not presented in this discussion, it may or may not be.
Unless that money is sitting in a room in the form of gold bars, then, a movement of investment from one place to another will have a net change in jobs.
Again, this is completely bogus. Not all uses of money (even excluding "sitting in a room in the form of gold bars") have equal effects on jobs. Different uses involve different direct applications of labor, giving them a different direct impact on jobs, and money applied in different uses also has different velocity, giving it a different less-direct impact on jobs.
You might have more jobs for less money in one situation, versus, less jobs for more money in another
Which means moving money from the latter use to the former use will, in fact, create more jobs, rendering your preceding claim bogus.
One only has to look at countries like Sweden which have lower population densities than the US but still have very high speed synchronous connections for less than we pay for a fraction of the service level here.
I agree with your overall point, but I think you mean symmetric rather than synchronous here.
Slashdot Mirror
The $10,000 cost referred to is the cost of filing the final, non-provisional application, not the cost of legal fees. Since the cost is to the company, if the company has in-house counsel, talking to them should be far less expensive, and would be the kind of thing that would be pretty irresponsible not to do (and if special talent that is outside of the company is needed, that's something in-house counsel should be able to determine, and should be able to assist in locating someone who isn't going to blatantly violate legal ethics by acting in their own interest rather than their clients, and, failing that, should be able to get the ball rolling on the legal malpractice action against the outside counsel if such a violation does occur.)
No, the GPL will not "make official the public-domaining of the app". The GPL is a copyright license that imposes all kinds of terms on those making derivative works, while something being in the public domain means there are no copyright-based restrictions on those making derivative works. A BSD-style license would be more like releasing it into the public domain, but still quite distinct.
Strictly speaking, there is, AFAIK, no way in the US to release a copyrightable work to the public domain officially. When you say that a work that you control the copyright is in the public domain, you've mostly just issued a gratuitous public license for other people do with it what they want, that is as revocable as any other gratuitous license, but may be enforceable to the benefit of the licensee (e.g., anyone who acted under the purported release into the public domain) under the principle of promissory estoppel.
Anyhow, asking Slashdot for this kind of business/legal advice is like asking a forum of MBAs or lawyers for programming advice.
Not all applications use MVC architecture, and markup languages can certainly be used outside of the MVC architecture, and can certainly be used for a lot more than views. Example: XML is a fairly well-known markup language. It can be used for things that are certainly view-oriented (XHTML, XSL-FO). It can also be used for things that are not exclusively view-oriented (WS-BPEL, XPDL, XSLT).
The "evil" reason it works is market segmentation. Packaging the features demanded by different subsets of the market into different SKUs offered at different prices, enables Microsoft to charge the maximum price in each market segment.
The less "evil" reason it works is it gives each segment the experience they want out of the box; note that Ubuntu also does lots of different editions (Ubuntu Desktop, Ubuntu Server, Ubuntu Studio, Kubuntu, Xubuntu, Edubuntu) targeted at different markets, too (though, of course, they are all both free and Free, and once you have one you can get all the features of all of them without any difficulty, by design) simply to give users the out-of-the-box experience they want.
If this was the whole explanation, it would not make sense "by the laws of economics". "Virtually no" is not the same thing as "no"; there is a marginal cost and it needs to be paid. Plus, there are fixed costs, and even if the marginal costs per unit were $0, producers who can't recoup their fixed costs would be losing money. If many people are getting something at no cost, someone else is paying those costs. Usually, what is free is either charity of one form of another (where the producer--or at least the people funding the producer--derives subjective utility from other people getting the benefit of the good, and thus is willing to eat the cost), or promotion of one form or another (where the producer gives the good away for free to build exposure and future profitability for that good, or to build demand for another good, that the producer can then profit from.) Sun doesn't give the JRE and JDK away for free (and Microsoft doesn't give away the free versions of Visual Studio) because of an irrational expectation that $0/copy times a really large number of copies will somehow make back their costs associated with those products, they do it because they expect it will increase demands for the goods and services that they charge money for enough to warrant the costs.
Now, the low marginal costs of digital goods delivered online make both of these kinds of free goods a lot more practical, so there is a lot more free.
What if properly packaged applications didn't use system-wide shared library directories as the first resort, but looked first in application-specific ones that were managed by the package management system and contained symlinks to the appropriate libraries identified as dependencies, and only looked in the system-wide shared library directory (which the package management system would populate with the most current [or possibly user-designated default, even if not most current] version of libs loaded through the package management system using the basic name of the lib, while alternative versions were stored using something like the name + version format you suggest (though I think I've seen "foo.so.n" used for other purposes, so maybe not that exact system), and used as targets of the symlinks for apps installed through the package management system?
PHP is a language a templating system designed very much for building web applications.
Ruby is a general purpose programming language, that is largely popular due to a particular web app framework.
Comparing bare Ruby with no non-standard libraries to PHP for web apps hosted behind another server is at least as bad of a comparison, and arguably far worse, than comparing RoR to PHP.
I've yet to hear a coherent argument for how Ruby fails at scalability compared to any other language, whether PHP or anything else.
Ruby doesn't obfuscate looping. I have no idea what you mean by "stuff like that" other than "other stuff that isn't true, either".
No, its a package manager that includes a build system.
If building from source is a desired feature, the misfeature is that it fails to do so well (presuming it does; I have very little experience using RPM.)
Uh, he seemed to me to be asking for a unified package manager, not at all what you describe.
If you have a unified packaging architecture, you don't need the rest (especially if the package manager can handle building and installing source packages), since what the OS is distributed with doesn't matter, what matters is what dependencies can be satisfied on it, and with a unified packaging system that can handle source packages, it is conceptually simple to minimize the differences in terms of what dependencies can be satisfied.
Now, admittedly, getting a good enough packaging system to do this well enough to be the "standard Linux packaging system" (or perhaps an even broader standard that could be used for Linux and for other Free *n*xen) is a big task. But progress toward it has a potentially big payoff even before it becomes a standard.
No, it doesn't. Sure, there a couple of base distributions now that also have unique packaging systems, but that doesn't mean that a packaging system has any inherent reason to be tied to a particular distro. You don't need to solve the diversity of distros problems to get a packaging system that solves the packaging problems, and once you have that, you don't need to get rid of multiple competing distros to get that widely implemented.
Now, admittedly, any unification is the same type of problem as the distro issue, in that you need to convince people working on multiple things to work on the same thing, but unlike OS distros, there really shouldn't need to be multiple packaging systems to serve different niches.
Ruby 1.8.x uses green threads in a single process per interpreter instance, JRuby uses Java threads (which are native threads on most or all platforms, IIRC), Ruby 1.9.0/1.9.1 use native threads with a GIL, exactly, AFAIK, like Python up through and including 3.0. Each of these Ruby implementations will have different threading performance.
Of course, none of that matters for Rails, which is probably where the issue you are talking about arouse rather than Ruby itself, since Rails is still, AFAIK, single-threaded throughout, with experimental threading support.
Every Ruby implementation contains support for spawning additional processes, though deciding whether and when to do this isn't a language function, its an application (or framework, or even application server) function.
If we address the packaging issues, that might well be a logical next step. But if we address the packaging issues, whether the distros are based on the same base distro or not won't matter very much (indeed, if the packaging issues are handled well enough, whether they are using Linux or *BSD might not be a particularly big deal.)
My point is that the key problem is packaging.
This is a different problem. Again, though, a common package management system doesn't mean you are restricted to a single set of repositories.
This is usually (I am inclined to say always) a package management or packaging problem; there is no reason, generally, why you shouldn't be able to have multiple versions of a library, application, or pretty much any other dependency side by side. You may, in some cases, need not just technical improvement but improvements in "best practices" to make this work, but its not at all an intractable problem, and its a pretty important one even within existing distros, much less as part of a Linux Packaging Grand Unification.
With an agreed common, and well-designed, package management system, the incentive would be high for those building software to provide packages. One reason why you won't find software packaged for your distro now is that there are competing packaging systems (and sometimes, even with the same package management system, you can't seemlessly use packages for one distro on another), so any packages that are provided will be useful to only a limited slice of the audience. Improvements in that direction will naturally reduce the "the thing I want doesn't have packages for my distro" problem.
Where the problem is is kind of intimately related to how the problem can be addressed.
The problem of packaging things to allow seemless side-by-side installs of different versions of components so that components that depend on them can operate without conflicts (both on the side of package management system issues and packaging issues) is a lot easier to solve than the supposed problem of "too many Linux distributions", and a lot more amenable to solution.
A common package management system does not require one shared repository. (Though of course that, or at least a shared repository discovery system, would be nice as a convenience.)
Unless the "common system" is the kernel, this is a problem in design of either the package management system or the particular packages.
KDE 4.1.4 doesn't seem any more broken than any major commercial desktop environment I've used, and is more pleasant than the XP or Vista desktops (its been a long time since I've used a Mac, so I won't comment there); I'll admit that it was a bad idea for Kubuntu to bundle KDE 4.1 in 8.10 when it was really unready, and the 4.1.4 is only in the pre-released updates repo, so for casual or cautious users of what is probably the biggest KDE-centered distro, KDE seems pretty broken. I hope the Kubuntu maintainers aren't being as overoptimistic in including 4.2 as the default in 9.04.
The only thing that, it seems to me, is really broken about KDE, at least in the 4.x line, is premature releases that take several point releases before they are really ready for daily use.
If the base install is minimal and leaves the user to install "options" like X and a window manager, then, yeah, you need to use a CLI for apt before you can even get to a position where you can use Synaptic.
Of course, you could have multiple distributions all based on the same distro, many of which come with GUIs included. But then the debate is over which streamlined base distro and package management system to keep and how to convince everyone working on other distros to move over to it.
Fine. Everyone should stop working on your favorite distro now, and work on my favorite distro instead, okay? That'll get us "a little less fragmentation".
Calls for "less fragmentation" are vacuous without a call to unite behind something specific; then we can debate the pros and cons of what would be gained and what would be lost. Of course, the people you really have to convince are the people working on whatever would be axed, since its an open source community and the only way to make that happen is to convince those people to stop working on what they've been working on and start working on something else.
I suspect that most people agree with that.
Where they disagree is on which distros are doing the right thing and which are wasting their time. Its pretty obvious that they disagree on that, because if they didn't, everyone would be working on the same distros now, and there would be no issue.
Also, its not like the developers that are scratching their own itch working on "distro x" would necessarily be as interested in working on "distro y". The Linux Community isn't a corporation with fixed resources and a central command that can redistribute them wherever it wants. If people aren't working on what they want to be working on, those resources don't go somewhere else, they just go out of the community entirely.
Insofar as that's true, you don't really need a common distribution to address that, a common package management system that can handle building and installing source-base packages would be sufficient.
The problem is one size doesn't fit all; Windows is dominant despite that because MS was in the right place at the right time to become so ubiquitous that instead of fitting people's needs, peopel would fit their needs to MS's products because they were the only option, and it has a lot of leverage from that that its been milking ever since.
Yes.
Since Ruby blocks are structurally pretty much identical to Ruby method definitions, which are themselves pretty similar to function/method definitions in most vaguely C-like (or Algol-derived, if you prefer) languages, I find describing them as "quite unreadable" to be rather odd. If you have a lot of programming experience but none of it in other languages where passing around anonymous functions as arguments is commonplace, it probably seems unusual at first and takes a little bit of time to get over that feeling, but I wouldn't think it would be too big of a barrier for most people.
Rails wasn't Twitter's problem, though there was some initial finger pointing in that direction. The problem was that Twitter initially had a simple synchronous architecture (which, sure, is the easiest thing to do with Rails, as with most frameworks) when it needed an asynchronous messaging architecture, and that they didn't do database optimizations that are out of scope for the web application framework. See, among other things, this article.
The argument that moving money from one use to another cannot create jobs is bogus. Determining whether the statement "creates 120,000 jobs" is accurate relies on information not presented in this discussion, it may or may not be.
Again, this is completely bogus. Not all uses of money (even excluding "sitting in a room in the form of gold bars") have equal effects on jobs. Different uses involve different direct applications of labor, giving them a different direct impact on jobs, and money applied in different uses also has different velocity, giving it a different less-direct impact on jobs.
Which means moving money from the latter use to the former use will, in fact, create more jobs, rendering your preceding claim bogus.
I agree with your overall point, but I think you mean symmetric rather than synchronous here.