BitcoinAverage is probably the best place for "the" price of bitcoin. It mains a weighted average of all the exchanges, based on volume. They also document which exchanges have been excluded from their list, and why. In the case of Mt Gox, it hasn't been included in the weighted average for a while, as withdrawals have been dead / dying for a very long time.
Mercurial is actually making some strides in that direction... the hg-git mercurial plugin lets you push/pull from git repositories, and it transparently integrates itself into the mercurial command line, not as a separate tool.
If it was good enough that the market was choosing it as an alternative to Oracle (to the tune of $1billion), I think that's pretty good proof of quality right there (at least as far as the end users' TCO was concerned).
Don't forget the open-source MySQL, which was of such good quality Oracle purchased it for a HUGE amount of money, despite already having a database product (as their primary product no less!).
Yeah, "votes of no confidence" and various fail-safe dissolution rules are two things which I really feel the US government would benefit from. It'd a great way to hold their feet to the fire. That and some other voting system like Instant Runoff. It's weird, because the US Constitution has got pretty much everything else and the kitchen sink thrown in there.
Bitcoin is a rather complex protocol (which I'm not 100% on), so the following is a bit of simplification...
Bitcoin operates as a gigantic transaction ledger (maintained by majority concensus), which tracks the movement of bitcoins between arbitrary psuedonoymous "addresses". To create an address, you generate a ECDSA public/private key pair. The public key is the address, anyone can transfer bitcoins to it. The private key is the control, only someone who has that can move money *out* of that address. The wallet file is essentially just a list of those pairs. If you started using a backup wallet file, you'd have control over all the addresses it has private keys for. If you've emptied any of the them since that backup was made, you'll still have control over the address, there just won't be any money there:)
There's a second (wonderfully useful) wrinkle, though. Due to the nature of ECDSA, you can derive additional public/private pairs from the initial pair, in a deterministic fashion. This allows you to have one master "seed" (e.g. a nice long passphrase) which can be used to generate unlimited public/private keys, without it being obvious that they are even connected to each other. And all you need to take control of any of them is the initial seed value. This means many bitcoin "wallets" are in fact just the seed passphrase... so if you keep it in your head and nowhere else, you have complete control over an unlimited number of addresses, without having to make *any* backups.
I'm sorry, but the entire premise that there is one "best" open source license is completely wrong. Where did this obsession arise to see one license crowned victor over all others, in all situations?
BSD (and MIT and variants) -- I've found they work best for providing backend and reference libraries, which by their nature are trying to provide a standard implementation of something, or at least a standard API. Open and closed sourced projects alike can use and modify it to suit their needs. This means such a library gets the widest adoption over the alternatives (all other factors being equal). This is especially great for server-side programs which want to promote multiple third-party clients - just release a BSD reference client.
LGPL -- A step down, for when you want the adoption level of a BSD license, but your project is complex and high maintenance enough that it needs to keep all the developers focused on a single api and codebase in order to thrive. Graphics libraries like GTK, audio processing libraries like LAME, are a great example of this.
GPL -- Finally, for the same reasons as LGPL, your want everyone contributing back to a single codebase, whether it's because you don't want to give the codebase away to closed source products that then profit from it, prevent brand confusion, or just maximize developer contributions. Mind you, closed source projects *will* choose an LGPL/BSD alternative over this or closed source, so it doesn't make much sense for libraries, etc. Primarily, this is useful for applications, which are vying for user (not developer) eyeballs.
So given they all have different uses that fit better for different project types and target markets, who in their right minds thinks only one of these licenses is correct?
What they need to start doing is sell electric cars with a small, removable, high-efficiency, gas turbine generator for charging.
Build an easy-attach mounting point inside the trunk, with hooks for intake, exhaust, and connection to the battery.
You could leave the thing sitting in your garage 3/4 of the year... and plop in it there when you need to go on a trip. Then you've got the best of both worlds (outside of losing some trunk space).
I suspect (IANA engineer) that you'd have a bunch of weight savings from an engine dedicated to charging the car rather than having the power to push the car directly. Also, the engine could be optimized to always run at it's most efficient RPM, rather than going all over the place during stop-n-go traffic.
I find it kind of odd that all of the analyses linked to in this article go on about SHA512-Crypt, BCrypt, SCrypt, etc, and the slideshow even talks about "Key Derivation Functions"... yet there doesn't seem to be any mention or comparision of PBKDF2-HMAC-SHA512 as a valid password-hashing key derivation function, despite it's widespread use, and that it's one of the core architectural components used in the design of SCrypt.
it's kinda funny, but webOS comes/came pretty close to what you're describing. Root was accessible by enabling "dev" mode through a special but officially documented code (the konami code for some versions), no cracking needed; the underlying linux os had a number of gnu tools already, and you can use the ipkg framework to install more; then there's Preware, a still thriving open source community / app catalog tool full of free unsigned apps and OS patches which palm and hp both officially sanctioned. The main limitation was that some of the hardware wasn't that well documented.
sigh. My only hope now is that android one day becomes as easy to mod, so getting python and an ssh/http server on my next phone is just as simple.
Relating to webOS phones... I regularly have 8+ browser pages open on my Palm Pre, and I can switch between them quickly with barely a glance and a couple of idly placed swipes with my thumb. I can't think of another ui that would make that work... even on a tablet, the "tabbed browser" interface is clunky. If they'd make a version of Android with 1) that interface, 2) webos's lack of jailbreaking, 3) something akin to Preware and it's offerings... I'd be a lot happier about switching to an Android phone when my Pre breaks.
Actually, the fact that OSX uses SHA512 makes it easy to crack the password (compared to the alternatives).
OSX uses SHA512(salt+password) to generate it's hashes. SHA2 was specifically designed to be highly parallelizable and fast on modern processors, which means brute force attacks are going to proceed very quickly. And as time goes on, and average processor speed increases, that amount of time per cpu (and per $) keeps dropping.
There are four modern password hashing schemes worthy of note: SHA512-Crypt (this is NOT simply SHA512), BCrypt, PBKDF2, and SCrypt. All of these schemes use a variable number of rounds of their underlying cryptographic operation. This allows the algorithm to stay the same, but the cpu-cost to be increased per hash as computers get faster, or if a user is particularly paranoid and wants to make it take longer to crack.
Many of them (such as PBKDF2) even have properties that make them resistant to preimage attacks on the underlying hash function.
Finally, SCrypt has the unique property of being "memory hard"... it's rounds don't just require a certain amount of time, but a certain amount of memory*time. This makes parallelizing the attack much more costly, as each CPU has to get it's own dedicated amount of memory for the attack.
All of the above are so much tougher to brute force, that the cost of OSX's hash scheme is barely worth notice by comparison. I'm not sure why OSX is using what it is... Linux uses SHA512-Crypt, BSD uses BCrypt, WPA2 and many other things use PBKDF2... all would have been better choices.
I think SCHeckler's point was that $150 - $200 was the right price to sell it at, given what the TouchPad provided. The fact that it cost HP $318 to make something which only had $200 of value to the customer... just shows why selling it at an even higher cost wasn't going to fix anything. They chose the other obvious option, and stopped selling it.
I'd agree that lack of apps was a problem, but only at the $500 price point. Look at how crazily it sold at $99 (and still successfully reselling on ebay for $200)... all of that is happening with the near *promise* of no new apps, and the vaguest homebrew mutterings of "I wonder if we can port Android". I'd argue the lack of apps becomes an increasing concern only when the price starts making the customer think "what else am I getting, besides a ereader / browser?". Which seems to happen around $300.
Not that it's impossible to move tablets without a major app ecosystem. HP had two other choices besides give up: make a cheaper tablet (as you pointed out, that probably wouldn't have worked); or follow the XBox strategy: sell drastically under cost to flood the market, then ramp up the price on the next gen TouchPad2. The gamble is that the initial glut would grow the marketplace to the point that people looking to pay $500 decide the TouchPad2 has enough apps to make it worth it.
For some reason, they tried to start *out* at that point, selling the premium, without any carrot to pull people in. They should have worked their way up to it; but seemed too risk averse to invest the money needed to carve out the mindshare. Not that there's anything wrong with being risk averse, but why did they even try the half-assed way, when the figures should have blatantly showed it was an all or nothing situation?
While I'd like to it not be the case, I'd have to agree with you about the general not-quite-there-yet state of dynamic frameworks. That said, Django's custom ORM leaves much to be desired. Next time you decide to give a python framework a try, pick one which uses SQLAlchemy as it's ORM layer. You'll find it to be a much more sophisticated library (similar to Java's Hibernate). In particular, it has all the features you just mentioned. Not integrating SQLAlchemy is one of the main things that keeps me from using Django... any other ORM layer in Python seems doomed to play catch-up.
Actually, I'd be relatively ok with us fighting in space, if it meant we were trying to get into space to begin with.
Consider a hypothetical moon colony -
* War requires developing countermeasures for missles and kinetic weapons - these are already needed to protect the colony from asteroids.
* War requires radiation-hardening the colony against EM weapons - this is already needed to protect against solar flares and the like.
* War requires developing more agile, efficient drives in order to out-maneuver the enemy? This just helps us colonize further.
Much as a I'd like space to be nice and peaceful, that doesn't seem to be in our natures right now - and just shifting the theater of conflict to space would put the well-funded military R&D pipelines on track to developing numerous technologies that we were going to need anyways - but they'd do it faster than if the goal was peaceful colonization, since it's now a matter of "national pride".
Even better, valet parking -
Valet gives you a ticket, and you discover it's possible to pencil in another number, and get a different car. Then you discover they let you make 20,000 photocopies, and present 20,000 different tickets, and valet *never gets suspicious*.
Regarding Google - actually, yes, there is implied consent. robots.txt and nofollow links can easily be added to any website, to tell Googlebot and others to go away. And they will - or then they probably would be wandering into (c) infringing - or at least some form of illegal use of resources (for trawling the site).
I think his underlying point was that many of us users do (or will) miss the old choices.
I used to prefer KDE 3. Then KDE4 came along and replaced it; and the new design just made too many fixed assumptions about things I wanted to configure, and constantly threw in my face things I didn't want to *have* to configure. I never really cared about the stability / completness issue of the early 4.x series - I respect it took a while to refactor all that code. Still, with the fundamental interface changes they made, even today, I just don't want to use KDE4.
So I migrated to Gnome 2. I liked it ok. It's not as configurable, but I could get it close enough to how I like to do things. But instead of polishing it, and fleshing out the details, Gnome seems obsessed with removing features unless 80% of the users are using it (and everyone has some feature that's in that 20% category, so it slowly annoys the whole userbase). But it's at least currently usuable for me.
Now Gnome3 comes along. I appreciate everyone's trying to improve the desktop metaphor. But personally, I'm a spacial person - I remember where my virtual desktops are relative to eachother, what windows I put where, it maps nicely to an actual desktop you just can see only a part of. Gnome3's workspaces break that spacial mapping for me, and make it much harder to use.
And then there's XFCE. I like XFCE, it's been hanging on for a long time. But I'd like a little more integration and polish than it offers (I respect the fact that they're trying to be minimal. They've done a great job, given their goals).
But all that comes down to the fact that, for me and others: linux may be choice, but I feel like my choices are being taken away, as when Gnome2 goes away to bitrot, there won't be a desktop that I consider usuable. And forking and picking up the codebase of one of these environments is just way too big a task for individual coders - the only way it'll happen is if one of the projects has a schism, and they all seem way too in agreement for that to happen.
It feels like we're heading towards 15 years ago, when all the desktop environments were either incomplete, or different for different's sake.
The article contends that a strategy to maximize profits in developed countries has two effects: maximizes profits globally, and fosters piracy in undeveloped countries. You seem to have focused on the first effect, and are wondered at how that could be bad thing for business... but you missed the second effect.
Their idea is that If the strategy fosters a thriving pirate market, then in the long run that market will grow large enough to hurt the legitimate market (even in developed countries)... which in the long run will cause the strategy to actual undermine profits, both locally and globally. So even though it will seem like a "success" during the short run, it will have to be abandoned at some point.
If the study is correct, I'd say the optimal path would in fact be a hybrid - start out targeting the developed market, but watch the pirate market, and do drastic price drops in that market before it gets established. That way, the company maximizes short-term profit in developed countries, but retains control of the world-wide market in the long run. And long-term market control is definitely more important, else competitors and piracy will drive your price below a sustainable level.
It seems to me that our general body of knowledge is growing so large, and economic competition is so fierce, that people are being forced to specialize on particular areas, to the point that they lack even introductory knowledge about other fields of study. Case in point: this paper, where a doctor basically rediscovered calculus.
I wouldn't say it's the only one worth using. Palm's (now HP's) WebOS is also linux-based, supports js, java, c++ based apps, and they are actively supporting the open-source community, even to the point of actively documenting how to (officially) gain root access. Not to mention much better multi-tasking support.
So don't feel like Android is the only remaining underdog to compete w/ Apple... Android itself is a rather closed environment compared to the alternatives that are also out there.
Indeed! Just to clarify things for the AC above...
This is an issue of the authors of some code demanding "adhere to our license or get rid of our code". Which I think everyone can understand the need to honor, if just as a matter of "do unto others, or else".
DeCSS is a completely different case. The code was written by a Norwegian named Jon Johansen, who not only did the cryptographic research to invent the algorithm in the first place, but wrote the code and then released it to the world. Copyright-wise, the code is legally open-source. And for all countries except the US, the code is legal for use. So for anyone outside the US, there aren't any legal problems with the code. And VLC isn't a US-developed piece of software (though to help Americans, DeCSS is distributed as a separate library under many linux distributions).
The only thing which taints the algorithm in the US is the "DCMA" law, which outlawed the use of any algorithms which circumvent a "copy protection scheme". The law is so broad that almost *anything* which alters the encoding of data (ROT13, etc) is a copy protection scheme; despite the fact that encrypting a DVD in no way prevents you from making copies of it (copies of encrypted bits play just like the original). So the DVD "CSS" encryption scheme doesn't even stop copying, yet it's able to wrap itself in the legal mantle the DCMA provides. What CSS *does* do is prevent you from playing a DVD unless the software author has paid a license fee to the people who created CSS (NOTE: not the people who creating the video codec it uses, that's just MPEG2). So all it does is stop you from making use of your fair use rights under US copyright law. It's your DVD, you have a right to play it, sell it, etc.
Now, you might argue that the DCMA, while unjust, is still the law, and Americans should abide by it. And that's a whole can of worms to which Slashdot has devoted many pages of discussion over the last decade. But initially, the effects of the DMCA were broader: worldwide, there were *no* open source DVD players. Period. Because the CSS algorithm wasn't even available in source form anywhere. DVD player authors worldwide had to pay a license just to link in a binary-only library. That is, until Jon Johansen (and cohorts) successfully reverse engineered the algorithm in a completely-legal-for-Norway manner (he was tried in court and found innocent of any wrongdoing). Thus allowing the rest of the world to watch dvds without having to pay money under a racket created by a US-only law.
And *thats* where DeCSS came from, and why it's nothing like this situation, which (while foot-and-bullet stupid) is perfectly within all internationally recognized rights of the authors.
Slashdot Mirror
BitcoinAverage is probably the best place for "the" price of bitcoin. It mains a weighted average of all the exchanges, based on volume. They also document which exchanges have been excluded from their list, and why. In the case of Mt Gox, it hasn't been included in the weighted average for a while, as withdrawals have been dead / dying for a very long time.
Mercurial is actually making some strides in that direction... the hg-git mercurial plugin lets you push/pull from git repositories, and it transparently integrates itself into the mercurial command line, not as a separate tool.
Looks like exactly what PostgreSQL's PGStrom project is trying to acheive.
If it was good enough that the market was choosing it as an alternative to Oracle (to the tune of $1billion), I think that's pretty good proof of quality right there (at least as far as the end users' TCO was concerned).
Don't forget the open-source MySQL, which was of such good quality Oracle purchased it for a HUGE amount of money, despite already having a database product (as their primary product no less!).
Yeah, "votes of no confidence" and various fail-safe dissolution rules are two things which I really feel the US government would benefit from. It'd a great way to hold their feet to the fire. That and some other voting system like Instant Runoff. It's weird, because the US Constitution has got pretty much everything else and the kitchen sink thrown in there.
Bitcoin is a rather complex protocol (which I'm not 100% on), so the following is a bit of simplification...
Bitcoin operates as a gigantic transaction ledger (maintained by majority concensus), which tracks the movement of bitcoins between arbitrary psuedonoymous "addresses". To create an address, you generate a ECDSA public/private key pair. The public key is the address, anyone can transfer bitcoins to it. The private key is the control, only someone who has that can move money *out* of that address. The wallet file is essentially just a list of those pairs. If you started using a backup wallet file, you'd have control over all the addresses it has private keys for. If you've emptied any of the them since that backup was made, you'll still have control over the address, there just won't be any money there :)
There's a second (wonderfully useful) wrinkle, though. Due to the nature of ECDSA, you can derive additional public/private pairs from the initial pair, in a deterministic fashion. This allows you to have one master "seed" (e.g. a nice long passphrase) which can be used to generate unlimited public/private keys, without it being obvious that they are even connected to each other. And all you need to take control of any of them is the initial seed value. This means many bitcoin "wallets" are in fact just the seed passphrase... so if you keep it in your head and nowhere else, you have complete control over an unlimited number of addresses, without having to make *any* backups.
I'm sorry, but the entire premise that there is one "best" open source license is completely wrong. Where did this obsession arise to see one license crowned victor over all others, in all situations?
BSD (and MIT and variants) -- I've found they work best for providing backend and reference libraries, which by their nature are trying to provide a standard implementation of something, or at least a standard API. Open and closed sourced projects alike can use and modify it to suit their needs. This means such a library gets the widest adoption over the alternatives (all other factors being equal). This is especially great for server-side programs which want to promote multiple third-party clients - just release a BSD reference client.
LGPL -- A step down, for when you want the adoption level of a BSD license, but your project is complex and high maintenance enough that it needs to keep all the developers focused on a single api and codebase in order to thrive. Graphics libraries like GTK, audio processing libraries like LAME, are a great example of this.
GPL -- Finally, for the same reasons as LGPL, your want everyone contributing back to a single codebase, whether it's because you don't want to give the codebase away to closed source products that then profit from it, prevent brand confusion, or just maximize developer contributions. Mind you, closed source projects *will* choose an LGPL/BSD alternative over this or closed source, so it doesn't make much sense for libraries, etc. Primarily, this is useful for applications, which are vying for user (not developer) eyeballs.
So given they all have different uses that fit better for different project types and target markets, who in their right minds thinks only one of these licenses is correct?
What they need to start doing is sell electric cars with a small, removable, high-efficiency, gas turbine generator for charging.
Build an easy-attach mounting point inside the trunk, with hooks for intake, exhaust, and connection to the battery.
You could leave the thing sitting in your garage 3/4 of the year... and plop in it there when you need to go on a trip. Then you've got the best of both worlds (outside of losing some trunk space).
I suspect (IANA engineer) that you'd have a bunch of weight savings from an engine dedicated to charging the car rather than having the power to push the car directly. Also, the engine could be optimized to always run at it's most efficient RPM, rather than going all over the place during stop-n-go traffic.
I find it kind of odd that all of the analyses linked to in this article go on about SHA512-Crypt, BCrypt, SCrypt, etc, and the slideshow even talks about "Key Derivation Functions"... yet there doesn't seem to be any mention or comparision of PBKDF2-HMAC-SHA512 as a valid password-hashing key derivation function, despite it's widespread use, and that it's one of the core architectural components used in the design of SCrypt.
A developer enters a market and wonders aloud "There are 12 conflict libraries, which one should I target?"
His friend replies: "You know, we should write a single library to abstract away all those differences, so everyone can just target 1 library!"
"That's a great idea!" the developer exclaims.
Now there are 13 conflicting libraries.
it's kinda funny, but webOS comes/came pretty close to what you're describing. Root was accessible by enabling "dev" mode through a special but officially documented code (the konami code for some versions), no cracking needed; the underlying linux os had a number of gnu tools already, and you can use the ipkg framework to install more; then there's Preware, a still thriving open source community / app catalog tool full of free unsigned apps and OS patches which palm and hp both officially sanctioned. The main limitation was that some of the hardware wasn't that well documented.
sigh. My only hope now is that android one day becomes as easy to mod, so getting python and an ssh/http server on my next phone is just as simple.
Relating to webOS phones... I regularly have 8+ browser pages open on my Palm Pre, and I can switch between them quickly with barely a glance and a couple of idly placed swipes with my thumb. I can't think of another ui that would make that work... even on a tablet, the "tabbed browser" interface is clunky. If they'd make a version of Android with 1) that interface, 2) webos's lack of jailbreaking, 3) something akin to Preware and it's offerings... I'd be a lot happier about switching to an Android phone when my Pre breaks.
Actually, the fact that OSX uses SHA512 makes it easy to crack the password (compared to the alternatives).
OSX uses SHA512(salt+password) to generate it's hashes. SHA2 was specifically designed to be highly parallelizable and fast on modern processors, which means brute force attacks are going to proceed very quickly. And as time goes on, and average processor speed increases, that amount of time per cpu (and per $) keeps dropping.
There are four modern password hashing schemes worthy of note: SHA512-Crypt (this is NOT simply SHA512), BCrypt, PBKDF2, and SCrypt.
All of these schemes use a variable number of rounds of their underlying cryptographic operation. This allows the algorithm to stay the same, but the cpu-cost to be increased per hash as computers get faster, or if a user is particularly paranoid and wants to make it take longer to crack.
Many of them (such as PBKDF2) even have properties that make them resistant to preimage attacks on the underlying hash function.
Finally, SCrypt has the unique property of being "memory hard"... it's rounds don't just require a certain amount of time, but a certain amount of memory*time. This makes parallelizing the attack much more costly, as each CPU has to get it's own dedicated amount of memory for the attack.
All of the above are so much tougher to brute force, that the cost of OSX's hash scheme is barely worth notice by comparison. I'm not sure why OSX is using what it is... Linux uses SHA512-Crypt, BSD uses BCrypt, WPA2 and many other things use PBKDF2... all would have been better choices.
Just to provide some links to the "alternative approach" mentioned in the summary:
* The Perspectives Project spearheaded the concept of independant notary servers instead of a chain-of-trust.
* Convergence is another spin on the same concept, by Moxie Marlinspike in fact. (Not sure if it's compatible w/ Perspectives, but I think it is)
I think SCHeckler's point was that $150 - $200 was the right price to sell it at, given what the TouchPad provided. The fact that it cost HP $318 to make something which only had $200 of value to the customer... just shows why selling it at an even higher cost wasn't going to fix anything. They chose the other obvious option, and stopped selling it.
I'd agree that lack of apps was a problem, but only at the $500 price point. Look at how crazily it sold at $99 (and still successfully reselling on ebay for $200)... all of that is happening with the near *promise* of no new apps, and the vaguest homebrew mutterings of "I wonder if we can port Android". I'd argue the lack of apps becomes an increasing concern only when the price starts making the customer think "what else am I getting, besides a ereader / browser?". Which seems to happen around $300.
Not that it's impossible to move tablets without a major app ecosystem. HP had two other choices besides give up: make a cheaper tablet (as you pointed out, that probably wouldn't have worked); or follow the XBox strategy: sell drastically under cost to flood the market, then ramp up the price on the next gen TouchPad2. The gamble is that the initial glut would grow the marketplace to the point that people looking to pay $500 decide the TouchPad2 has enough apps to make it worth it.
For some reason, they tried to start *out* at that point, selling the premium, without any carrot to pull people in. They should have worked their way up to it; but seemed too risk averse to invest the money needed to carve out the mindshare. Not that there's anything wrong with being risk averse, but why did they even try the half-assed way, when the figures should have blatantly showed it was an all or nothing situation?
While I'd like to it not be the case, I'd have to agree with you about the general not-quite-there-yet state of dynamic frameworks. That said, Django's custom ORM leaves much to be desired. Next time you decide to give a python framework a try, pick one which uses SQLAlchemy as it's ORM layer. You'll find it to be a much more sophisticated library (similar to Java's Hibernate). In particular, it has all the features you just mentioned. Not integrating SQLAlchemy is one of the main things that keeps me from using Django... any other ORM layer in Python seems doomed to play catch-up.
Consider a hypothetical moon colony -
Much as a I'd like space to be nice and peaceful, that doesn't seem to be in our natures right now - and just shifting the theater of conflict to space would put the well-funded military R&D pipelines on track to developing numerous technologies that we were going to need anyways - but they'd do it faster than if the goal was peaceful colonization, since it's now a matter of "national pride".
Even better, valet parking - Valet gives you a ticket, and you discover it's possible to pencil in another number, and get a different car. Then you discover they let you make 20,000 photocopies, and present 20,000 different tickets, and valet *never gets suspicious*.
Regarding Google - actually, yes, there is implied consent. robots.txt and nofollow links can easily be added to any website, to tell Googlebot and others to go away. And they will - or then they probably would be wandering into (c) infringing - or at least some form of illegal use of resources (for trawling the site).
I think his underlying point was that many of us users do (or will) miss the old choices.
I used to prefer KDE 3. Then KDE4 came along and replaced it; and the new design just made too many fixed assumptions about things I wanted to configure, and constantly threw in my face things I didn't want to *have* to configure. I never really cared about the stability / completness issue of the early 4.x series - I respect it took a while to refactor all that code. Still, with the fundamental interface changes they made, even today, I just don't want to use KDE4.
So I migrated to Gnome 2. I liked it ok. It's not as configurable, but I could get it close enough to how I like to do things. But instead of polishing it, and fleshing out the details, Gnome seems obsessed with removing features unless 80% of the users are using it (and everyone has some feature that's in that 20% category, so it slowly annoys the whole userbase). But it's at least currently usuable for me.
Now Gnome3 comes along. I appreciate everyone's trying to improve the desktop metaphor. But personally, I'm a spacial person - I remember where my virtual desktops are relative to eachother, what windows I put where, it maps nicely to an actual desktop you just can see only a part of. Gnome3's workspaces break that spacial mapping for me, and make it much harder to use.
And then there's XFCE. I like XFCE, it's been hanging on for a long time. But I'd like a little more integration and polish than it offers (I respect the fact that they're trying to be minimal. They've done a great job, given their goals).
But all that comes down to the fact that, for me and others: linux may be choice, but I feel like my choices are being taken away, as when Gnome2 goes away to bitrot, there won't be a desktop that I consider usuable. And forking and picking up the codebase of one of these environments is just way too big a task for individual coders - the only way it'll happen is if one of the projects has a schism, and they all seem way too in agreement for that to happen.
It feels like we're heading towards 15 years ago, when all the desktop environments were either incomplete, or different for different's sake.
That's what they said, and they are serious.
The article contends that a strategy to maximize profits in developed countries has two effects: maximizes profits globally, and fosters piracy in undeveloped countries. You seem to have focused on the first effect, and are wondered at how that could be bad thing for business... but you missed the second effect.
Their idea is that If the strategy fosters a thriving pirate market, then in the long run that market will grow large enough to hurt the legitimate market (even in developed countries)... which in the long run will cause the strategy to actual undermine profits, both locally and globally. So even though it will seem like a "success" during the short run, it will have to be abandoned at some point.
If the study is correct, I'd say the optimal path would in fact be a hybrid - start out targeting the developed market, but watch the pirate market, and do drastic price drops in that market before it gets established. That way, the company maximizes short-term profit in developed countries, but retains control of the world-wide market in the long run. And long-term market control is definitely more important, else competitors and piracy will drive your price below a sustainable level.
It seems to me that our general body of knowledge is growing so large, and economic competition is so fierce, that people are being forced to specialize on particular areas, to the point that they lack even introductory knowledge about other fields of study. Case in point: this paper, where a doctor basically rediscovered calculus.
I wouldn't say it's the only one worth using. Palm's (now HP's) WebOS is also linux-based, supports js, java, c++ based apps, and they are actively supporting the open-source community, even to the point of actively documenting how to (officially) gain root access. Not to mention much better multi-tasking support.
So don't feel like Android is the only remaining underdog to compete w/ Apple... Android itself is a rather closed environment compared to the alternatives that are also out there.
Indeed! Just to clarify things for the AC above...
This is an issue of the authors of some code demanding "adhere to our license or get rid of our code". Which I think everyone can understand the need to honor, if just as a matter of "do unto others, or else".
DeCSS is a completely different case. The code was written by a Norwegian named Jon Johansen, who not only did the cryptographic research to invent the algorithm in the first place, but wrote the code and then released it to the world. Copyright-wise, the code is legally open-source. And for all countries except the US, the code is legal for use. So for anyone outside the US, there aren't any legal problems with the code. And VLC isn't a US-developed piece of software (though to help Americans, DeCSS is distributed as a separate library under many linux distributions).
The only thing which taints the algorithm in the US is the "DCMA" law, which outlawed the use of any algorithms which circumvent a "copy protection scheme". The law is so broad that almost *anything* which alters the encoding of data (ROT13, etc) is a copy protection scheme; despite the fact that encrypting a DVD in no way prevents you from making copies of it (copies of encrypted bits play just like the original). So the DVD "CSS" encryption scheme doesn't even stop copying, yet it's able to wrap itself in the legal mantle the DCMA provides. What CSS *does* do is prevent you from playing a DVD unless the software author has paid a license fee to the people who created CSS (NOTE: not the people who creating the video codec it uses, that's just MPEG2). So all it does is stop you from making use of your fair use rights under US copyright law. It's your DVD, you have a right to play it, sell it, etc.
Now, you might argue that the DCMA, while unjust, is still the law, and Americans should abide by it. And that's a whole can of worms to which Slashdot has devoted many pages of discussion over the last decade. But initially, the effects of the DMCA were broader: worldwide, there were *no* open source DVD players. Period. Because the CSS algorithm wasn't even available in source form anywhere. DVD player authors worldwide had to pay a license just to link in a binary-only library. That is, until Jon Johansen (and cohorts) successfully reverse engineered the algorithm in a completely-legal-for-Norway manner (he was tried in court and found innocent of any wrongdoing). Thus allowing the rest of the world to watch dvds without having to pay money under a racket created by a US-only law.
And *thats* where DeCSS came from, and why it's nothing like this situation, which (while foot-and-bullet stupid) is perfectly within all internationally recognized rights of the authors.