Except that the version numbers do matter when it comes to plugins and the maxVersion string.
Plugins should test against new versions when before they are released to GA, and should issue updates which address compatibility issues (and update the supported Firefox versions if there aren't compatibility issues or once those issues are addressed.)
But that's not Firefox maintainers' responsibility, its the plugin maintainers' responsibility.
HTML is versionless now as HTML5 is the last version to be released.
That's probably not true; the same reasons that motivate the HTML5 snapshot of the current state of HTML is quite likely to motivate future snapshots, as well.
If you don't plan to give any support, call that a development version!
They are providing support, including security updates. The security updates just happen to be the subsequent major version, which is provided at no charge.
I would not be surprised if their new release cycle causes their marketshare to start shrinking in a significant fashion.
According to most measures I've seen, Firefox marketshare peaked in late 2009; since then its been, overall, falling, though not as fast as IE.
The browser that's been taking the share that IE and Firefox have been losing is Chrome, which already uses a release approach similar to the one that Firefox just adopted.
I don't see any extensions that use the proxy API so that you can keep proxy settings separate from the OS. Can you recommend one?
I can't recommend one since I have no use for one, but it seems like that sample extension for the proxy api allows that.
I use KeePass myself, and don't really want my browser keeping passwords for me; however, I know people that do. For non-technical users, downloading and installing yet another application to keep passwords for them -- passwords they'll only use on web sites while in their web browser -- can be a non-trivial challenge and annoyance.
Using an application to keep passwords secure is a fundamentally broken approach to papering around an insecure OS; Google supports common existing applications bundled with certain desktop environments for this purpose, but its browser doesn't attempt to do it, and I think that's exactly the right approach. Its much better to use an OS that does its job (and securing access to local data to only authorized users is the OS's job) or, failing that, to use a single sign-on solution that uses two-factor authentication.
As for lacking a master password, it is almost laughable you consider the fact that Chrome stores passwords in plain text on Linux an acceptable solution
I didn't actually say that, but, insofar as there is a problem with that, its with Linux (or the way the particular Linux system is configured and managed), not Chrome, and it affects far more than passwords stored by Chrome: it affects the security of every bit of data on the local system.
in addition, I do find it laughable you consider kwallet and gnome keyring a reasonable solution for typical users.
I am not really interested in what you find laughable when you aren't going to justify your subjective impression, and, again, I didn't say that, either; but I certainly don't see any reason why simple and user-friendly password management tools bundled with two popular Linux desktop environments aren't reasonable solutions for typical Linux users.
You did do a good job, however, giving me a hearty laugh, and I congratulate you on reinforcing the kinds of stereotypes normal people have about chest-thumping uber-geeks.
Your the one that is positing that your personal preferences (which you admit aren't even based on your own need but your own assumptions about less-technical users) for which you don't bother to even attempt to an offer a justification are superior to the judgements of people who are actually succeeding rather than merely snarking on the internet. If you are really looking to find someone "reinforcing the kinds of stereotypes normal people have about chest-thumping uber-geeks", you don't really need to go looking all that far.
It makes me question their decisions and the future of the browser, and I'm sorry to say this to you, if you don't like me questioning their decisions, well, you're just going to have to suffer.
I hate to bust your overinflated sense of your own importance, but just because I respond to a post on Slashdot to point out that you are both factually wrong about Chrome's actual features and, in my opinion, also wrong about the features it ought to have to be considered a good browser choice, that doesn't even begin to imply that those points of disagreement cause me to "suffer".
And, really, I have no problem with you questioning anyone's decisions. But, when you do, try to have some substance behind it -- like try getting a fact right every now and then, and try having an argument to offer when someone challenges your claims that software is designed wrong rather than just a bunch of ad hominems, abuse, and "I find it laughable" with no support.
Or, you know, don't. Its not like I have an interest in anyone taking you seriously, though Slashdot would be a nicer place with more substantive discussion.
I don't think you do, I think you are just focusing on a different time window.
Insurance would simply cease to exist, because it would no longer be profitable. If premiums escalated as you say, it would no longer be worthwhile for people to buy insurance, so the whole business model simply disappears.
Well, yeah, that would be the ultimate effect, I was just looking at the immediate response on the insurance company's side, not what the ultimate (and fairly rapid) effect would be.
If you are a game developer (a demographic that is conceivably part of Slashdot's "...for nerds" focus), you care about this kind of feature of the gaming market (ignoring, for a moment, whether this market analysis is convincing) because it reveals an opportunity for you to make more money if you take it into consideration.
If you are anyone else, you might well not care about analysis of underserved audiences in the gaming market.
Also, if you don't care, there is no reason for you to click into the thread and post a reply.
Shorter: You're so vain, you probably think this thread is about you.
I don't understand why a game developer would want to tailor games to a single sex, male of female. The broader the appeal the larger the audience.
This intuition is quite often incorrect in the market. The broader the appeal, the more people might be willing to play your game if nothing else was competing for their time and money, but the more intensely the game appeals to some demographic -- and this is easier to achieve narrowly than broadly -- the more likely it is to be at the top of someone's shopping list rather than somewhere way down the list that they never get to because they spend the time and money they have on things more intensely appealing.
The reason that you have well-developed genres of games that are almost formulaic isn't (just) because designers are lazy, its because there is a proven intense interest in certain market segments for certain styles of games, and, commercially, its much better to appeal intensely to a clear and proven interest than to try to be modestly satisfying to everyone.
You can't be found guilty of a crime you were coerced into performing.
True but irrelevant here; as a criminal defense that provides exculpation (rather than a circumstance that might mitigate sentence upon conviction), coercion requires (among other things) an imminent threat of death or serious bodily harm. Unless the company execs were on an orbiting space station and the hacker was threatening to shut off their life support system with a clear capacity to carry out the threat, or some equally extreme scenario, you aren't going to find "coercion" of the type necessary to excuse a crime in a hacker-ransom scenario.
On the contrary: ideally, that is just exactly what you would do.
If it was possible for you to know that (and, thus, do it), it wouldn't be possible to sell insurance at a profit (unless the insurance companies had access to the same knowledge, in which case, it would no longer be an ideal tactic, because the premiums would escalate along with the certainty of a qualifying claim.)
I don't think it's likely to burst -- cloud-based data is just too useful (assuming, of course, that you have an internet connection and sufficient bandwidth, which can be pretty big assumptions). John Gruber, of all people, makes some pretty good points on the upcoming client-in-a-web-browser (Google) and client-as-a-native-app (Apple) wars
Which are pretty much po-TAY-to vs. po-TAH-to wars.
There are plenty of tools being built to allow HTML/Javascript "native" apps, and Chrome includes NaCl (and soon, PNaCl) which allow the browser to run native code delivered over the web.
I know Google has this whole web-based vision where everything is accessed through the browser, but I'd rather see this as a stand-alone app.
Its not an app at all, its a set of Web APIs exposing existing infrastructure that has to be supported by the host OS for it to work at all.
So, if you are developing for an OS that already supports this type of thing outside of the browser (most do, though the APIs may or may not be as nice), and you don't mind tying yourself to that OS, and you don't want to integrate with the Web, then you don't need this.
OTOH, if you do want to integrate with the Web, you need something that has browser integration, and you probably want it to work across different OS's.
Heck, Windows 8 will be written in HTML/Javascript
No, it won't.
Windows 8 will include and support apps that are written in HTML/Javascript, but that's not the same thing.
so I don't expect to have to wait too long for a native app.
Since its not an app at all, but APIs and supporting infrastructure on which apps can be built, which requires existing non-web APIs and infrastructure to already exist in the underlying OS and hardware, a kind of native equivalent already exists anywhere this can be deployed.
I just can't wait for the cloud bubble to burst so we can go back to having traditional software again.
I'm pretty sure native realtime communication software is fairly common already.
Google won't add basic features like proxy settings that aren't shared with the operating system
Chrome does support this via an extension API (chrome.proxy).
and a master password for your saved passwords,
A while back, Google added integration with kwallet and gnome keyring, which, does this without requiring a separate master password for the browser; OTOH, simply using saved passwords and having appropriate security on your OS user account would seem to be an adequate approach for dealing with this concern.
I really don't understand why they're making the kinds of decisions they're making. It seems so random, like they stuff in whatever shiny they like, and then come up with weak justifications for skipping the rest.
Have you considered that, aside from your errors regarding what features they have supposedly skipped, their perceptions of what is important in a browser may differ from yours, and that their success in rapidly building browser market share based on what they have done with Chrome might be an indication that they aren't completely in the dark about what matters?
Like many I embraced Chrome because it seemed that Firefox had become big, bloated, and cumbersome. Chrome seemed to resist the urge to stuff extra doo-dads into the browser, and I like that.
This impression of yours has been misguided from the start. Chrome has been, almost from the beginning, all about adding extra doodads to support rich internet applications based in the browser. It's true that compared to contemporary versions of Firefox, Chrome had less doodads, but that's because Chrome was focussing on what Google thought was important for rich internet apps (initially, JavaScript performance was the main focus), and because, like many lean/agile projects, it was a start-small-and-build-rapidly effort.
You wouldn't build Gmail into the browser, so why build in phone service?
Google hasn't built phone service into the browser, they've built lower-level realtime communications functions that can be used to implement phone service as well as lots of other apps.
They've also built a lot of stuff into the browser to provide low-level support for Gmail and other existing Google Apps (that can be, and are, used for lots of other things.) Desktop notifications come to mind. And the SPDY protocol. So, really, they haven't treated phone service any different from Gmail here.
The 'BSD-like' license [google.com] Google chose is not right in my opinion. Companies like Microsoft could easily do an 'Embrace-->Extend-->Extinguish' game on the technology.
EEE doesn't work on BSD-licensed (or public domain) software as long as as there is an active developer community around the open source version (and especially not if there is at least one big corporate user that sponsors the open source version to get people to work for them for free), it only works if there is little concern in the community for the product for open licensing, or if the product is essentially dead. Sure, you get use in closed products that may or may not contribute back, but so what? Lots of closed products use SQLite code, yet SQLite is still alive as an active public domain project, with lots of big corporate backers, presumably because those corporations realize that SQLite is important for their business, but not what they are in the business of selling, so its more important to them that it is maintained than that they exclusively control it. PostgreSQL, with a BSD-style license, comes to mind, as well.
The bigger danger with EEE is against standards like the communication interface, and the license you choose for the software, no matter how restrictive, is unlikely to effectively restrain EEE on against the communication interface, except by inhibiting adoption in the first place, which is counterproductive. OTOH, as long as there are enough big users of the original interface (something which Google has some power to make happen), its very difficult for an EEE effort to displace the original interface in the open source software with an incompatible interface only provided by their own proprietary software.
What is wrong with LGPL ver. 3?
GPL-style licenses (including the LGPL, though not as much so as the GPL itself) are really good if you favor Free Software for ideological reasons but don't actually believe that it offers value for developers as well as end users. If you believe that it brings pragmatic benefit to developers, rather than just ideological satisfaction, to release source under open-source license rather than keeping it proprietary, the additional restrictions in GPL-style licenses become counterproductive for developers (including the first developer) and unnecessary (as the pragmatic value providers downstream developers a built-in incentive to release their own work under a similar license.)
But in truth, I'd be more concerned about unbrided capitalism and monopolistic practices,
I guess I don't understand why capitalism is a dirty word around here.
It's not. The "dirtiness" comes with the modifier "unbridled". And the other term "monopolistic practices". If you read all of what someone writes, instead of just one word, your understanding may be improved.
Isn't it a good thing that businesses are not run by the state?
Overall, probably, which is one reason you won't find many here arguing in support of an extreme form of socialism in which all industry is directly operated by the State.
Does competition not spur innovation?
Certainly, which is one problem with unbridled capitalism (which often tends to monopoly) and monopolistic practices, which the GP was complaining about in the excerpt you responded to. See how that works? "Competitiong = good" --> "No competition = not good"
Which economic system would you have in capitalism's place?
Personally, I'd prefer a modern mixed economy with regulation well-aimed to address the well-known problems of unregulated markets, particularly the tendency to form accrete market power narrowly which leads to barriers to entry which stifle competition, and the poor efficiency of unregulated markets when dealing with externalities and with goods and services that are not well approximated by the kind of Econ 101 assumptions that underlie the premise that unregulated markets are efficient (e.g., that economic exchanges are undertaken by actors with perfect knowledge of the utilities they would experience from all possible courses of action.)
Of course, wanting regulation well-aimed toward any goal takes a lot of public vigiliance, but then, so does having any government at all that doesn't turn into an absolute dictatorship over time, and its pretty much the same type of vigilance, so that's not really an additional cost.
Google, Apple, Netflix will team together and repel any net neutrality rule.
Which is why Google has been lobbying so hard for net neutrality rules.
After all they can pay for the bandwidth their user will use and they are very interested to keep datacap for competitors.
Google doesn't, in practice, seem to be very interested in erecting or preserving barriers to entry, whether or not they have a position which makes it seem rational to expect they might be.
Of course having to invest some of your income into updating the infrastructure eats into profits, but somehow, the telecomms in most of the world still manage to stay profitable. Perhaps you Americans are simply bad at business?
No, American businesses have just found that it is more efficient (in terms of short term RoI), given the prevailing market conditions to spend a little bit lobbying regulators than to pay for infrastructure upgrades.
That's not being bad at business, quite the opposite.
C++ didn't exist as a standardized language till 13 years ago. It was in development before then.
The first sentence is true. It does not imply the second, however.. C++ was widely used in production before it became an ISO standard, so in one sense it was "out of development" before being standardized; on the other hand,it remains actively under development today (which is why we are talking about a new version of the standard), so no matter which side you look at it from, the first ISO standard isn't a good dividing line between the language "being in development" and it being in some other state. The first ISO standard for C++ wasn't the first iteration of the language in any meaningful sense, it was just the first ISO standard.
If you outsource something, you are FAR MORE LIKELY to be told NO. You can no longer abuse people who are your own employees.
If you outsource, IME, you will rarely be told "no", you will be told "yes, and here's what it will cost"; occasionally, you will also be given a reason you ought not to do what you asked (and sometimes it will be valid, and sometimes it will be an attempt to steer you in a direction which serves interests of the vendor.)
OTOH, an internal IT department is far more likely to flat out say no to an internal business unit's request. (They won't say no to a directive from common authority over the business unit and the IT department, but glancing at any org chart and finding where that common authority exists will tell you why that doesn't necessarily mean that much to most business units in even a modestly large organization in practice.)
Offerings of particular service providers may or may not be closed, but "the cloud", itself, is not (in fact, "the cloud" is something that you can run yourself with open source software; Ubuntu Server even includes infrastructure for it in the form of Ubuntu Enterprise Cloud.)
Well why not make the ubuntu installer ask whether you'd like kde or gnome or xfce instead of managing 8 *buntus...? Seems so terribly redundant.
Possibly because putting all the desktop environments on one CD would take up too much space. The WUBI installer (that installs Ubuntu with its boot partition in a file on an NTFS partition that can be installed and removed from Windows with Add/Remove programs [note, its still a dual boot, not a "runs under Windows" system like, e.g., Portable Ubuntu]), which grabs packages from the internet to install, does ask what desktop environment you want, while the normal CD-based installers don't.
"Free software guru Richard Stallman claims consumers should reject eBooks until they "respect our freedoms". He highlights the DRM embedded in eBooks sold by Amazon as an example of such restrictions, citing the infamous case of Amazon wiping copies of George Orwell's 1984 from users' Kindles without permission.
Yes, DRM-laden ebooks are bad.
There are plenty of vendors of DRM-free ebooks. Since most of them don't adhere to the ideals of the FSF with regard to content freedom, they probably are also objectionable to RMS, but they provide the same (or more) practical freedom than one enjoys with a physical book. DRM-free seems to be very common with creators/publishers that directly sell their own e-books, while DRM-laden products seem to dominate when large third-party distributors that aren't the contents developer are selling ebooks (B&N and Amazon particularly, and Google to a lesser extent.)
His suggested remedy? Distributing tax funds to authors based on their popularity, or "designing players so users can send authors anonymous voluntary payments"."
I have a better remedy: people who are concerned about DRM and related freedom issues only purchase e-books that conform to their preferences, and don't purchase other ebooks. Most current e-book readers (both dedicated and software) will support DRM-free ebooks, so this requires neither changes to existing devices, changes to existing software, or changes to existing laws. It just requires people to act based on their preferences.
Since there are profitable companies producing DRM-free ebooks, I think that the idea that there is a "problem" with revenue that needs to be solved by either technical change or imposing taxes that are distributed by the government to content creators if DRM is to be avoided is unfounded, and I think RMS does a gross disservice to the cause of content freedom by validating the position of the pro-DRM camp by implicitly endorsing the existence of a problem of that kind with the "solutions" he proposes.
Slashdot Mirror
Plugins should test against new versions when before they are released to GA, and should issue updates which address compatibility issues (and update the supported Firefox versions if there aren't compatibility issues or once those issues are addressed.)
But that's not Firefox maintainers' responsibility, its the plugin maintainers' responsibility.
That's probably not true; the same reasons that motivate the HTML5 snapshot of the current state of HTML is quite likely to motivate future snapshots, as well.
They are providing support, including security updates. The security updates just happen to be the subsequent major version, which is provided at no charge.
According to most measures I've seen, Firefox marketshare peaked in late 2009; since then its been, overall, falling, though not as fast as IE.
The browser that's been taking the share that IE and Firefox have been losing is Chrome, which already uses a release approach similar to the one that Firefox just adopted.
I can't recommend one since I have no use for one, but it seems like that sample extension for the proxy api allows that.
Using an application to keep passwords secure is a fundamentally broken approach to papering around an insecure OS; Google supports common existing applications bundled with certain desktop environments for this purpose, but its browser doesn't attempt to do it, and I think that's exactly the right approach. Its much better to use an OS that does its job (and securing access to local data to only authorized users is the OS's job) or, failing that, to use a single sign-on solution that uses two-factor authentication.
I didn't actually say that, but, insofar as there is a problem with that, its with Linux (or the way the particular Linux system is configured and managed), not Chrome, and it affects far more than passwords stored by Chrome: it affects the security of every bit of data on the local system.
I am not really interested in what you find laughable when you aren't going to justify your subjective impression, and, again, I didn't say that, either; but I certainly don't see any reason why simple and user-friendly password management tools bundled with two popular Linux desktop environments aren't reasonable solutions for typical Linux users.
Your the one that is positing that your personal preferences (which you admit aren't even based on your own need but your own assumptions about less-technical users) for which you don't bother to even attempt to an offer a justification are superior to the judgements of people who are actually succeeding rather than merely snarking on the internet. If you are really looking to find someone "reinforcing the kinds of stereotypes normal people have about chest-thumping uber-geeks", you don't really need to go looking all that far.
I hate to bust your overinflated sense of your own importance, but just because I respond to a post on Slashdot to point out that you are both factually wrong about Chrome's actual features and, in my opinion, also wrong about the features it ought to have to be considered a good browser choice, that doesn't even begin to imply that those points of disagreement cause me to "suffer".
And, really, I have no problem with you questioning anyone's decisions. But, when you do, try to have some substance behind it -- like try getting a fact right every now and then, and try having an argument to offer when someone challenges your claims that software is designed wrong rather than just a bunch of ad hominems, abuse, and "I find it laughable" with no support.
Or, you know, don't. Its not like I have an interest in anyone taking you seriously, though Slashdot would be a nicer place with more substantive discussion.
I don't think you do, I think you are just focusing on a different time window.
Well, yeah, that would be the ultimate effect, I was just looking at the immediate response on the insurance company's side, not what the ultimate (and fairly rapid) effect would be.
If you are a game developer (a demographic that is conceivably part of Slashdot's "...for nerds" focus), you care about this kind of feature of the gaming market (ignoring, for a moment, whether this market analysis is convincing) because it reveals an opportunity for you to make more money if you take it into consideration.
If you are anyone else, you might well not care about analysis of underserved audiences in the gaming market.
Also, if you don't care, there is no reason for you to click into the thread and post a reply.
Shorter: You're so vain, you probably think this thread is about you.
This intuition is quite often incorrect in the market. The broader the appeal, the more people might be willing to play your game if nothing else was competing for their time and money, but the more intensely the game appeals to some demographic -- and this is easier to achieve narrowly than broadly -- the more likely it is to be at the top of someone's shopping list rather than somewhere way down the list that they never get to because they spend the time and money they have on things more intensely appealing.
The reason that you have well-developed genres of games that are almost formulaic isn't (just) because designers are lazy, its because there is a proven intense interest in certain market segments for certain styles of games, and, commercially, its much better to appeal intensely to a clear and proven interest than to try to be modestly satisfying to everyone.
True but irrelevant here; as a criminal defense that provides exculpation (rather than a circumstance that might mitigate sentence upon conviction), coercion requires (among other things) an imminent threat of death or serious bodily harm. Unless the company execs were on an orbiting space station and the hacker was threatening to shut off their life support system with a clear capacity to carry out the threat, or some equally extreme scenario, you aren't going to find "coercion" of the type necessary to excuse a crime in a hacker-ransom scenario.
When it is a legal defense at all, "coercion" usually requires much more than was in play here (like imminent threat of death).
If it was possible for you to know that (and, thus, do it), it wouldn't be possible to sell insurance at a profit (unless the insurance companies had access to the same knowledge, in which case, it would no longer be an ideal tactic, because the premiums would escalate along with the certainty of a qualifying claim.)
"Normal" AJAX is restricted by the same origin policy, though there are workarounds (e.g., JSONP).
Which are pretty much po-TAY-to vs. po-TAH-to wars.
There are plenty of tools being built to allow HTML/Javascript "native" apps, and Chrome includes NaCl (and soon, PNaCl) which allow the browser to run native code delivered over the web.
Its not an app at all, its a set of Web APIs exposing existing infrastructure that has to be supported by the host OS for it to work at all.
So, if you are developing for an OS that already supports this type of thing outside of the browser (most do, though the APIs may or may not be as nice), and you don't mind tying yourself to that OS, and you don't want to integrate with the Web, then you don't need this.
OTOH, if you do want to integrate with the Web, you need something that has browser integration, and you probably want it to work across different OS's.
No, it won't.
Windows 8 will include and support apps that are written in HTML/Javascript, but that's not the same thing.
Since its not an app at all, but APIs and supporting infrastructure on which apps can be built, which requires existing non-web APIs and infrastructure to already exist in the underlying OS and hardware, a kind of native equivalent already exists anywhere this can be deployed.
I'm pretty sure native realtime communication software is fairly common already.
Chrome does support this via an extension API (chrome.proxy).
A while back, Google added integration with kwallet and gnome keyring, which, does this without requiring a separate master password for the browser; OTOH, simply using saved passwords and having appropriate security on your OS user account would seem to be an adequate approach for dealing with this concern.
Have you considered that, aside from your errors regarding what features they have supposedly skipped, their perceptions of what is important in a browser may differ from yours, and that their success in rapidly building browser market share based on what they have done with Chrome might be an indication that they aren't completely in the dark about what matters?
This impression of yours has been misguided from the start. Chrome has been, almost from the beginning, all about adding extra doodads to support rich internet applications based in the browser. It's true that compared to contemporary versions of Firefox, Chrome had less doodads, but that's because Chrome was focussing on what Google thought was important for rich internet apps (initially, JavaScript performance was the main focus), and because, like many lean/agile projects, it was a start-small-and-build-rapidly effort.
Google hasn't built phone service into the browser, they've built lower-level realtime communications functions that can be used to implement phone service as well as lots of other apps.
They've also built a lot of stuff into the browser to provide low-level support for Gmail and other existing Google Apps (that can be, and are, used for lots of other things.) Desktop notifications come to mind. And the SPDY protocol. So, really, they haven't treated phone service any different from Gmail here.
EEE doesn't work on BSD-licensed (or public domain) software as long as as there is an active developer community around the open source version (and especially not if there is at least one big corporate user that sponsors the open source version to get people to work for them for free), it only works if there is little concern in the community for the product for open licensing, or if the product is essentially dead. Sure, you get use in closed products that may or may not contribute back, but so what? Lots of closed products use SQLite code, yet SQLite is still alive as an active public domain project, with lots of big corporate backers, presumably because those corporations realize that SQLite is important for their business, but not what they are in the business of selling, so its more important to them that it is maintained than that they exclusively control it. PostgreSQL, with a BSD-style license, comes to mind, as well.
The bigger danger with EEE is against standards like the communication interface, and the license you choose for the software, no matter how restrictive, is unlikely to effectively restrain EEE on against the communication interface, except by inhibiting adoption in the first place, which is counterproductive. OTOH, as long as there are enough big users of the original interface (something which Google has some power to make happen), its very difficult for an EEE effort to displace the original interface in the open source software with an incompatible interface only provided by their own proprietary software.
GPL-style licenses (including the LGPL, though not as much so as the GPL itself) are really good if you favor Free Software for ideological reasons but don't actually believe that it offers value for developers as well as end users. If you believe that it brings pragmatic benefit to developers, rather than just ideological satisfaction, to release source under open-source license rather than keeping it proprietary, the additional restrictions in GPL-style licenses become counterproductive for developers (including the first developer) and unnecessary (as the pragmatic value providers downstream developers a built-in incentive to release their own work under a similar license.)
It's not. The "dirtiness" comes with the modifier "unbridled". And the other term "monopolistic practices". If you read all of what someone writes, instead of just one word, your understanding may be improved.
Overall, probably, which is one reason you won't find many here arguing in support of an extreme form of socialism in which all industry is directly operated by the State.
Certainly, which is one problem with unbridled capitalism (which often tends to monopoly) and monopolistic practices, which the GP was complaining about in the excerpt you responded to. See how that works? "Competitiong = good" --> "No competition = not good"
Personally, I'd prefer a modern mixed economy with regulation well-aimed to address the well-known problems of unregulated markets, particularly the tendency to form accrete market power narrowly which leads to barriers to entry which stifle competition, and the poor efficiency of unregulated markets when dealing with externalities and with goods and services that are not well approximated by the kind of Econ 101 assumptions that underlie the premise that unregulated markets are efficient (e.g., that economic exchanges are undertaken by actors with perfect knowledge of the utilities they would experience from all possible courses of action.)
Of course, wanting regulation well-aimed toward any goal takes a lot of public vigiliance, but then, so does having any government at all that doesn't turn into an absolute dictatorship over time, and its pretty much the same type of vigilance, so that's not really an additional cost.
Which is why Google has been lobbying so hard for net neutrality rules.
Google doesn't, in practice, seem to be very interested in erecting or preserving barriers to entry, whether or not they have a position which makes it seem rational to expect they might be.
No, American businesses have just found that it is more efficient (in terms of short term RoI), given the prevailing market conditions to spend a little bit lobbying regulators than to pay for infrastructure upgrades.
That's not being bad at business, quite the opposite.
The first sentence is true. It does not imply the second, however.. C++ was widely used in production before it became an ISO standard, so in one sense it was "out of development" before being standardized; on the other hand,it remains actively under development today (which is why we are talking about a new version of the standard), so no matter which side you look at it from, the first ISO standard isn't a good dividing line between the language "being in development" and it being in some other state. The first ISO standard for C++ wasn't the first iteration of the language in any meaningful sense, it was just the first ISO standard.
If you outsource, IME, you will rarely be told "no", you will be told "yes, and here's what it will cost"; occasionally, you will also be given a reason you ought not to do what you asked (and sometimes it will be valid, and sometimes it will be an attempt to steer you in a direction which serves interests of the vendor.)
OTOH, an internal IT department is far more likely to flat out say no to an internal business unit's request. (They won't say no to a directive from common authority over the business unit and the IT department, but glancing at any org chart and finding where that common authority exists will tell you why that doesn't necessarily mean that much to most business units in even a modestly large organization in practice.)
No, its not.
Offerings of particular service providers may or may not be closed, but "the cloud", itself, is not (in fact, "the cloud" is something that you can run yourself with open source software; Ubuntu Server even includes infrastructure for it in the form of Ubuntu Enterprise Cloud.)
Possibly because putting all the desktop environments on one CD would take up too much space. The WUBI installer (that installs Ubuntu with its boot partition in a file on an NTFS partition that can be installed and removed from Windows with Add/Remove programs [note, its still a dual boot, not a "runs under Windows" system like, e.g., Portable Ubuntu]), which grabs packages from the internet to install, does ask what desktop environment you want, while the normal CD-based installers don't.
Yes, DRM-laden ebooks are bad.
There are plenty of vendors of DRM-free ebooks. Since most of them don't adhere to the ideals of the FSF with regard to content freedom, they probably are also objectionable to RMS, but they provide the same (or more) practical freedom than one enjoys with a physical book. DRM-free seems to be very common with creators/publishers that directly sell their own e-books, while DRM-laden products seem to dominate when large third-party distributors that aren't the contents developer are selling ebooks (B&N and Amazon particularly, and Google to a lesser extent.)
I have a better remedy: people who are concerned about DRM and related freedom issues only purchase e-books that conform to their preferences, and don't purchase other ebooks. Most current e-book readers (both dedicated and software) will support DRM-free ebooks, so this requires neither changes to existing devices, changes to existing software, or changes to existing laws. It just requires people to act based on their preferences.
Since there are profitable companies producing DRM-free ebooks, I think that the idea that there is a "problem" with revenue that needs to be solved by either technical change or imposing taxes that are distributed by the government to content creators if DRM is to be avoided is unfounded, and I think RMS does a gross disservice to the cause of content freedom by validating the position of the pro-DRM camp by implicitly endorsing the existence of a problem of that kind with the "solutions" he proposes.