Sending that info to the "mothership"" (sic), without my knowledge or permission, is bad because they have no reason to need that data; other than to sell it or use it for marketing.
What are you talking about? When you installed the software you clearly indicated that you had read and understood the terms and conditions, which clearly stated that your camera software would be sending information stored in each image the camera records back to the camera company.
That little check box is legally binding. Some specific parts of some ridiculous EULAs are not legally binding, but on the whole they are legitimate. You gave them permission to do this, I don't see why you are upset about it.
If you actually care about your privacy, you should actually read the Terms and Conditions, in which they actually tell you what they are actually going to do with your private data. If there is something in there you don't agree with, don't check the box, and don't install the software. Either find some other way to use the device, or simply return the device.
It annoys me to no end when people complain about the evil things companies are doing with their private information, yet are too lazy to read what a company is specifically telling you what they want to do with your private data, and is asking for your permission to do so.
I personally don't like what companies do with my private information, but I don't care about it enough to not use the software. This is clearly also true of 99% (or more) of the people here. If you really care about this shit, when a company asks for your permission, simply tell them "no thank you".
I can't see how you can call it traitorware when they told you up front exactly what they were going to do with your data. Traitors don't tell you before hand that they are going to betray you. It's frankly not the software company's fault* that you don't seem to care what they plan to do with your data.
*Note that the Sony rootkit was illegal. That shit should never fly. Most anything short of that is fair game, though, if you are stupid enough to agree to it.
I imagine Joel thought you would be smart enough to apply the guidelines to your own situation. You've done that to a degree, but you're making the list needlessly inflexible.
- Do you use source control?
If your source control does not actually control the source effectively, it isn't source control. It's just a thing you put your source code into to make your life a living hell.
-Can you make a build in one step?/Do you make daily builds?
This one you have a small point on, but the obvious purpose here is to automate the process of publishing the latest version of the software to the team in order to avoid mistakes in the build/deployment process. Server side scripting, for example, isn't compiled or "built", but all the pieces do need to be in place and everyone needs access to the most current version. "Building" in this case would mean deploying the new code to the internal test server so all the developers know what the most current version of the web site is and can actually use it to verify that everything is working. This prevents you from making changes that are so large they are difficult to trace (if you have source control and nightly builds, you know exactly who screwed up and when). There should be an automated process to ensure all of the needed components are, in fact, there. It's just as critical for things that don't build as it is for things that do, it just looks different so you may not realize it.
"make this a 'deploy package' in one step" I hope you mean deploy to the test server in one step, and not publishing it out to the world. If not you totally missed the point of nightly builds (it's to catch major bugs before the code needing debugging becomes too large).
I could accept Garcia's "Do you have automated build or deployment procedures?" as a replacement for "Can you make a build in one step". The point is automation to avoid procedural mistakes, not compiling/deployment itself.
-Do you fix bugs before writing new code?
"Use unit testing here" - There is no need to be so specific. Unit testing is an effective modern tool, but it will not catch all bugs, particularly systemic bugs. The point is that you need to fix the major, money sucking bugs before you add new features.
-Do you have a spec?
"overrated" ??? The specification is the thing that describes what you are trying to do! How the hell can you write anything but hodgepodge software, especially with more than one developer, if you don't have overall design goals written down somewhere where they can be referenced? You can change the specification if your goals or needs change, but you should always have one! I suspect this is an especially serious flaw for open source projects that don't have strong leadership, given the distributed nature of open source.
-Do programmers have a quiet working conditions?
"ditch the phones" ?? What if your programmer works from home, how are you supposed to effectively communicate? Email isn't good enough for all situations, IM is better but still doesn't quite cut it, and frankly it encourages people to interrupt you more often. Quiet working conditions are what you need, not a simple lack of phones. I think if you were to expand this you should add "free from distractions" to the end of that. These days, it can be very quiet in your office yet still be extremely distracting with emails and IM notifications popping up all over the place.
Seriously, most of his "updates" are just re-statements of the old questions in a less flexible manner, so that they apply to fewer software companies or coding environments. The old questions already include his if you assume such things as bug databases and source control need to be effective in order to meet the requirement. A bug database that doesn't contain the information you need to fix bugs is useless, and would count against the company. Source control that doesn't effectively control the source code would be the same. No need to force distributed source control on one guy in an office just because "it's 2010 and we do web shit now".
And why fix bugs before implementing new features? How is that better, or really any different than fixing bugs before writing new code? Joel talks about prioritizing bug fixes elsewhere, if you need help understanding that. The idea is not that every bug is fixed before a new line of code is written, it's that you are constantly fixing bugs, and you don't put major bug fixes on the back burner to add new features. Which is what writing new code is about, is it not? I still don't understand why he changed that.
Plus some of his ideas (like his take on the bug database) are just stupid.
You've never waded through a laundry list of bugs before, have you?
Re:Old system is fine.
on
Joel Test Updated
·
· Score: 4, Insightful
His "updates" just sound like re-statements of the original questions for a particular situation (i.e. less applicable to all modern software companies than the original).
Joel Spolsky assumed you would be intelligent enough to adapt the list to your specific situation.
For example, what good is "source control" if it doesn't effectively control the source code? There is no need to specifically mention distributed source control; if your source control is doing its job then you have good source control. If it isn't doing its job because you've got developers all over the country, then you need a distributed source control. It's built in to the question.
Customers directly reporting to a bug database, as others have mentioned, can be disasterous. However, Joel's flagship software is bug tracking software, and from what I've heard it's very, very good. His bug tracking uses a combination of silent reports from the software, direct customer input, and support service input. Specifically stating bug tracking must be entered directly by the customer is stupid and inflexible, and does not apply to all situations. The point of the software test is to apply to all situations.
It goes on, most of them are similar, but this one is egregious:
Do you have automated build or deployment procedures?
What the hell does he think "Can you make a build in one step?" means?! That's automated build and/or deployment!
Also:
Do you fix bugs before implementing new features?
Uh... frankly, that sounds worse than "Do you fix bugs before writing new code?"
Do you have a roadmap, and you don't make important changes to the short term priorities?
A) That's not the programmers job nor responsibility, and B) "Do you have an up-to-date schedule?" Hello?
Seriously, what does this guy think all these words mean? Just because they were written 10 years ago doesn't mean the meanings of the words changed. Apply them to your situation, they fit just fine.
Last but not least:
Do your team work in good conditions (quiet environment, flexible schedule, freedom to choose development software, fair paycheck...)
That's a dream of every office worker in America, and if you refuse to work at companies that don't have an office culture like that, well, you won't be working much unless you are seriously hot shit.
Huh, so you're saying Radiohead's latest album wasn't a success in spite of the millions of dollars in profit? Profit which they would likely never have seen a dime of if it had been sold in the traditional manner, mind you (the music industry is nasty to artists - it's incredible).
Obviously this isn't going to work for everything, but it works for a lot more than older or smaller items. In fact it works extremely well on popular items as well. In a brick and mortar store Radiohead's album would have sold for almost $20 dollars, yet they made a killing averaging $3 per sale, if memory serves. Not a small item, not old, very profitable.
Nine Inch Nails did something similar, though they used a tiered system instead of pay as you want - X number of tracks HQ free download, all tracks HQ download for $5, CD shipped for $10, delux with hardcover something-or-other for $75, and an uber-delux for $300.
...but you'll have a hard time selling music on line in a pay-what-you-want model.
Seemed to work very well for Nine Inch Nails and Radiohead, they each made several million on their experimental attempts online sales. NIN used a tiered model (starting at free), while Radiohead was pay-as-you-want, but the concept is the same and the results are undeniable.
Musicians typically don't make much, if anything, on album sales. By cutting out the labels entirely both of these bands received 100% of the profit. Even if overall sales were a fraction of what the label could have done, the musicians still came out far ahead.
You're failing basic supply and demand principles here.
For computer games, supply is effectively infinite, so we can ignore that side of the equation, and we need only look at demand.
The question is, is $20 the optimal price point?
Taking your example, only 100 people will pay $20 for the game. At $30, say the number drops to 50. Sales just went from $2000 to $1500 by raising the price. However, if the $30 price point only has 10 fewer purchases, well now your sales went up to $2700. In this case, the $20 price point is clearly too low.
On the other hand, if $20 is too high then things will go something like this: the price is dropped from $20 to $5, and 900 more people are willing to buy the game at the drastically reduced price. That's $5000 for selling 1000 copies at $5 vs $2000 for selling 100 copies. The $5 price point is the clear winner here. To continue, dropping the game to $1 may only increase sales by another 3000 copies, sounds like a lot, but that only gets you $4000 total - a loss from the $5 price point. On the other hand, dropping down to $1 may actually boost sales to 10,000 copies, a clear win.
Each product has an ideal price point, where the demand for the unit and the price needed to match that demand produce the greatest possible profit.
This is why stores have sales. Think for a moment about Black Friday - the most profitable shopping day of the year. It is called Black Friday because it is the day when most retail stores go from being "in the red" - i.e. no profit for the year - to being "in the black" - profitable. How can this be, when it is the day when retail items are at the lowest price they will be all year?
The answer is demand. You will always increase demand for a product by reducing the price. For almost all products this also means an increase in profit. The question is not whether reducing the price will bring in more money, the question is at what point will reducing the price stop bringing in money. With retail sales there are hard limits - things cost a certain amount to make, so the price cannot be reduced below that and still make money (on that item - you can sell for a loss to boost sales of other items, for an overall profit gain - see Xbox 360 vs Wii for a good comparison of the two strategies). With digital sales the limit is simply a number that needs to be met (the cost to make the first copy), the hard limit (bandwidth & server costs) is so minimal as to be insignificant.
This also illustrates the genius of retail sales. At retail, an item initially sells for its highest price. Once most of the people who are willing to pay the high price have purchased the item it goes on sale, bringing in a whole new set of customers who were not willing to buy at the higher price but are perfectly willing to buy at the new, lower price. Depending on the nature of the item, the new price could become the permanent price, or it could go back to the old price. Either way, once sales level off, there is another sale, and a whole new slew of customers come in to buy the product.
This allows the retail stores to extract the full profit at each stage. For my example, it would combine the $30 profits, $20 profits, and $5 profits. You would end up with $1500 for the 50 who would buy at $30 or less, another $1000 for the remaining 50 who would buy at $20 or less ($2500 for the first 100 sales), and $4500 from the remaining 900 who would buy at $5 or less. Once the money train has dried up, you can then even drop to $1 to catch the remaining 3000 people, for another $3000. This brings the total profit to $10000, and eliminates the risk of dropping the price too low.
As you can see, in my example the last two bumps were the most significant, but for other products that could easily happen at other price points. For example, a polarizing game with a core of fanatical fans but not many others who would be willing to purchase the game no matter the price. You might only get 100 people to buy,
Meh, conciseness is an important part of tech writing. If you are wordy you should be punished for it: state at the top to please be concise, and toss any applications that are too long.
Harsh, but too many people are applying to college these days anyway. Gotta thin the herd any way you can.
More like a correction of Engadget's hysteria and a lamentation at the lack of openness.
The gist of it is that Engadget claims Android's security is shit since you can root it so easily.
The Android devs respond by saying you shouldn't call it "rooting" since the Nexus S was intended to allow users to install their own OS. To do that, you need to be able gain root access. In fact, they tell you how in the blog: fastboot oem unlock. That's it.
Rooting a phone implies root access was not intended, and you must exploit a security flaw to gain access. If root access was intended from the beginning, how can running the command to do so possibly be considered exploiting a security flaw?
To put it another way, is sudo a security flaw in Linux? That's basically what Engadget is saying, and the Android devs are saying that's stupid, and oh yeah phones should be open so rooting goes the way of the do-do bird.
The housing market is greatly hampered by various levels of government. Look at Fannie Mae / Freddie Mac. Look at building codes. Look at zoning regulations.
In the US, pretty much nobody goes without food unless they have mental problems, in which case their problem is mental, not foodal.
So clearly the conclusion we must draw is that capitalism has utterly failed.
What does large-scale fraud have to do with deregulation?
Regulation does not prevent fraud, and deregulation does not encourage fraud. The only thing that changes is exactly what kinds of fraud are committed.
Fraud in all its forms should be aggressively prosecuted.
Depending upon exactly which metric you are looking at (some react faster than others), $1 in 1980 would be worth between $2.60 and $5 today. Average looks to be right around $3, which also coincides with the most relevant metric: consumer prices. 300% inflation was the original AC's claim, he was just confused about what that actually meant for prices today vs prices 30 years ago. In uber simple terms that even AC should be able to understand, inflation means there are more dollars out there, but each one is worth 1/3 what it used to be.
If $1 in 1980 is worth $3 today, then $1000 in 1980 would be worth $3000 today. That is a fact, there is no question that this is so. You can check for yourself here if you don't believe me. They have a handy dandy calculator so you can figure out the value for a particular span of years. For what its worth, it was pretty stead inflation until 2008, after which some metrics deflated while others (like consumer goods) have quite rapidly inflated.
The second portion of this discussion has been anecdotal. The claim that a cross-country trip cost $1000 30 years ago which now costs $450. I personally can't comment regarding flying that far back, but it does fit with my experience over the last 20 years or so.
Compare that $1000 ticket, which in today's inflated dollars would be $3000, to the $450 ticket of today, and there is an extremely obvious and massive decline in price between then and now.
What the fuck kind of ass-backwards retarded "free" market is that?
"Here's our Free Market over here, and this 8 foot tall 600 pound gentleman over here is Tiny, he rules the Free Market with an iron fist."
Next you'll be saying we need to set up a Ministry of Peace to start wars (so we can have peace, of course) and a Ministry of Truth to sanitize all speech and print (to only the truth is heard, of course).
Slashdot Mirror
With hunt-and-peck no less!
Don't you think that Betrayalware would be a better term?
What exactly do you think a traitor is?
I'll help you out with the actual definition:
# someone who betrays his country by committing treason
# double-crosser: a person who says one thing and does another
Sending that info to the "mothership"" (sic), without my knowledge or permission, is bad because they have no reason to need that data; other than to sell it or use it for marketing.
What are you talking about? When you installed the software you clearly indicated that you had read and understood the terms and conditions, which clearly stated that your camera software would be sending information stored in each image the camera records back to the camera company.
That little check box is legally binding. Some specific parts of some ridiculous EULAs are not legally binding, but on the whole they are legitimate. You gave them permission to do this, I don't see why you are upset about it.
If you actually care about your privacy, you should actually read the Terms and Conditions, in which they actually tell you what they are actually going to do with your private data. If there is something in there you don't agree with, don't check the box, and don't install the software. Either find some other way to use the device, or simply return the device.
It annoys me to no end when people complain about the evil things companies are doing with their private information, yet are too lazy to read what a company is specifically telling you what they want to do with your private data, and is asking for your permission to do so.
I personally don't like what companies do with my private information, but I don't care about it enough to not use the software. This is clearly also true of 99% (or more) of the people here. If you really care about this shit, when a company asks for your permission, simply tell them "no thank you".
I can't see how you can call it traitorware when they told you up front exactly what they were going to do with your data. Traitors don't tell you before hand that they are going to betray you. It's frankly not the software company's fault* that you don't seem to care what they plan to do with your data.
*Note that the Sony rootkit was illegal. That shit should never fly. Most anything short of that is fair game, though, if you are stupid enough to agree to it.
I imagine Joel thought you would be smart enough to apply the guidelines to your own situation. You've done that to a degree, but you're making the list needlessly inflexible.
- Do you use source control?
If your source control does not actually control the source effectively, it isn't source control. It's just a thing you put your source code into to make your life a living hell.
-Can you make a build in one step?/Do you make daily builds?
This one you have a small point on, but the obvious purpose here is to automate the process of publishing the latest version of the software to the team in order to avoid mistakes in the build/deployment process. Server side scripting, for example, isn't compiled or "built", but all the pieces do need to be in place and everyone needs access to the most current version. "Building" in this case would mean deploying the new code to the internal test server so all the developers know what the most current version of the web site is and can actually use it to verify that everything is working. This prevents you from making changes that are so large they are difficult to trace (if you have source control and nightly builds, you know exactly who screwed up and when). There should be an automated process to ensure all of the needed components are, in fact, there. It's just as critical for things that don't build as it is for things that do, it just looks different so you may not realize it.
"make this a 'deploy package' in one step" I hope you mean deploy to the test server in one step, and not publishing it out to the world. If not you totally missed the point of nightly builds (it's to catch major bugs before the code needing debugging becomes too large).
I could accept Garcia's "Do you have automated build or deployment procedures?" as a replacement for "Can you make a build in one step". The point is automation to avoid procedural mistakes, not compiling/deployment itself.
-Do you fix bugs before writing new code?
"Use unit testing here" - There is no need to be so specific. Unit testing is an effective modern tool, but it will not catch all bugs, particularly systemic bugs. The point is that you need to fix the major, money sucking bugs before you add new features.
-Do you have a spec?
"overrated" ??? The specification is the thing that describes what you are trying to do! How the hell can you write anything but hodgepodge software, especially with more than one developer, if you don't have overall design goals written down somewhere where they can be referenced? You can change the specification if your goals or needs change, but you should always have one! I suspect this is an especially serious flaw for open source projects that don't have strong leadership, given the distributed nature of open source.
-Do programmers have a quiet working conditions?
"ditch the phones" ?? What if your programmer works from home, how are you supposed to effectively communicate? Email isn't good enough for all situations, IM is better but still doesn't quite cut it, and frankly it encourages people to interrupt you more often. Quiet working conditions are what you need, not a simple lack of phones. I think if you were to expand this you should add "free from distractions" to the end of that. These days, it can be very quiet in your office yet still be extremely distracting with emails and IM notifications popping up all over the place.
Because Garcia said so!
Seriously, most of his "updates" are just re-statements of the old questions in a less flexible manner, so that they apply to fewer software companies or coding environments. The old questions already include his if you assume such things as bug databases and source control need to be effective in order to meet the requirement. A bug database that doesn't contain the information you need to fix bugs is useless, and would count against the company. Source control that doesn't effectively control the source code would be the same. No need to force distributed source control on one guy in an office just because "it's 2010 and we do web shit now".
And why fix bugs before implementing new features? How is that better, or really any different than fixing bugs before writing new code? Joel talks about prioritizing bug fixes elsewhere, if you need help understanding that. The idea is not that every bug is fixed before a new line of code is written, it's that you are constantly fixing bugs, and you don't put major bug fixes on the back burner to add new features. Which is what writing new code is about, is it not? I still don't understand why he changed that.
Plus some of his ideas (like his take on the bug database) are just stupid.
You've never waded through a laundry list of bugs before, have you?
His "updates" just sound like re-statements of the original questions for a particular situation (i.e. less applicable to all modern software companies than the original).
Joel Spolsky assumed you would be intelligent enough to adapt the list to your specific situation.
For example, what good is "source control" if it doesn't effectively control the source code? There is no need to specifically mention distributed source control; if your source control is doing its job then you have good source control. If it isn't doing its job because you've got developers all over the country, then you need a distributed source control. It's built in to the question.
Customers directly reporting to a bug database, as others have mentioned, can be disasterous. However, Joel's flagship software is bug tracking software, and from what I've heard it's very, very good. His bug tracking uses a combination of silent reports from the software, direct customer input, and support service input. Specifically stating bug tracking must be entered directly by the customer is stupid and inflexible, and does not apply to all situations. The point of the software test is to apply to all situations.
It goes on, most of them are similar, but this one is egregious:
Do you have automated build or deployment procedures?
What the hell does he think "Can you make a build in one step?" means?! That's automated build and/or deployment!
Also:
Do you fix bugs before implementing new features?
Uh... frankly, that sounds worse than "Do you fix bugs before writing new code?"
Do you have a roadmap, and you don't make important changes to the short term priorities?
A) That's not the programmers job nor responsibility, and B) "Do you have an up-to-date schedule?" Hello?
Seriously, what does this guy think all these words mean? Just because they were written 10 years ago doesn't mean the meanings of the words changed. Apply them to your situation, they fit just fine.
Last but not least:
Do your team work in good conditions (quiet environment, flexible schedule, freedom to choose development software, fair paycheck...)
That's a dream of every office worker in America, and if you refuse to work at companies that don't have an office culture like that, well, you won't be working much unless you are seriously hot shit.
The "sentence" is total fail.
I find the irony of that statement absolutely hilarious.
In other words, it's good for everything digital.
Which is what the summary was talking about.
...and only for older/"smaller" items.
Huh, so you're saying Radiohead's latest album wasn't a success in spite of the millions of dollars in profit? Profit which they would likely never have seen a dime of if it had been sold in the traditional manner, mind you (the music industry is nasty to artists - it's incredible).
Obviously this isn't going to work for everything, but it works for a lot more than older or smaller items. In fact it works extremely well on popular items as well. In a brick and mortar store Radiohead's album would have sold for almost $20 dollars, yet they made a killing averaging $3 per sale, if memory serves. Not a small item, not old, very profitable.
Nine Inch Nails did something similar, though they used a tiered system instead of pay as you want - X number of tracks HQ free download, all tracks HQ download for $5, CD shipped for $10, delux with hardcover something-or-other for $75, and an uber-delux for $300.
...but you'll have a hard time selling music on line in a pay-what-you-want model.
Seemed to work very well for Nine Inch Nails and Radiohead, they each made several million on their experimental attempts online sales. NIN used a tiered model (starting at free), while Radiohead was pay-as-you-want, but the concept is the same and the results are undeniable.
Musicians typically don't make much, if anything, on album sales. By cutting out the labels entirely both of these bands received 100% of the profit. Even if overall sales were a fraction of what the label could have done, the musicians still came out far ahead.
Well, the musician will likely never become a billionaire thanks to people buying his CD, but the author and actor might.
Seriously, the music industry is fucked in the head, the vast majority of mainstream artists can't make a buck without touring 350 days a year.
You're failing basic supply and demand principles here.
For computer games, supply is effectively infinite, so we can ignore that side of the equation, and we need only look at demand.
The question is, is $20 the optimal price point?
Taking your example, only 100 people will pay $20 for the game. At $30, say the number drops to 50. Sales just went from $2000 to $1500 by raising the price. However, if the $30 price point only has 10 fewer purchases, well now your sales went up to $2700. In this case, the $20 price point is clearly too low.
On the other hand, if $20 is too high then things will go something like this: the price is dropped from $20 to $5, and 900 more people are willing to buy the game at the drastically reduced price. That's $5000 for selling 1000 copies at $5 vs $2000 for selling 100 copies. The $5 price point is the clear winner here. To continue, dropping the game to $1 may only increase sales by another 3000 copies, sounds like a lot, but that only gets you $4000 total - a loss from the $5 price point. On the other hand, dropping down to $1 may actually boost sales to 10,000 copies, a clear win.
Each product has an ideal price point, where the demand for the unit and the price needed to match that demand produce the greatest possible profit.
This is why stores have sales. Think for a moment about Black Friday - the most profitable shopping day of the year. It is called Black Friday because it is the day when most retail stores go from being "in the red" - i.e. no profit for the year - to being "in the black" - profitable. How can this be, when it is the day when retail items are at the lowest price they will be all year?
The answer is demand. You will always increase demand for a product by reducing the price. For almost all products this also means an increase in profit. The question is not whether reducing the price will bring in more money, the question is at what point will reducing the price stop bringing in money. With retail sales there are hard limits - things cost a certain amount to make, so the price cannot be reduced below that and still make money (on that item - you can sell for a loss to boost sales of other items, for an overall profit gain - see Xbox 360 vs Wii for a good comparison of the two strategies). With digital sales the limit is simply a number that needs to be met (the cost to make the first copy), the hard limit (bandwidth & server costs) is so minimal as to be insignificant.
This also illustrates the genius of retail sales. At retail, an item initially sells for its highest price. Once most of the people who are willing to pay the high price have purchased the item it goes on sale, bringing in a whole new set of customers who were not willing to buy at the higher price but are perfectly willing to buy at the new, lower price. Depending on the nature of the item, the new price could become the permanent price, or it could go back to the old price. Either way, once sales level off, there is another sale, and a whole new slew of customers come in to buy the product.
This allows the retail stores to extract the full profit at each stage. For my example, it would combine the $30 profits, $20 profits, and $5 profits. You would end up with $1500 for the 50 who would buy at $30 or less, another $1000 for the remaining 50 who would buy at $20 or less ($2500 for the first 100 sales), and $4500 from the remaining 900 who would buy at $5 or less. Once the money train has dried up, you can then even drop to $1 to catch the remaining 3000 people, for another $3000. This brings the total profit to $10000, and eliminates the risk of dropping the price too low.
As you can see, in my example the last two bumps were the most significant, but for other products that could easily happen at other price points. For example, a polarizing game with a core of fanatical fans but not many others who would be willing to purchase the game no matter the price. You might only get 100 people to buy,
It's wordy, unclear, and redundant, but the only actual mistake there is using "to" instead of "too".
He almost certainly meant "forms" as well, given the context, but one cannot say for certain.
Are you an asshole, or do you just hate life?
Meh, conciseness is an important part of tech writing. If you are wordy you should be punished for it: state at the top to please be concise, and toss any applications that are too long.
Harsh, but too many people are applying to college these days anyway. Gotta thin the herd any way you can.
More like a correction of Engadget's hysteria and a lamentation at the lack of openness.
The gist of it is that Engadget claims Android's security is shit since you can root it so easily.
The Android devs respond by saying you shouldn't call it "rooting" since the Nexus S was intended to allow users to install their own OS. To do that, you need to be able gain root access. In fact, they tell you how in the blog: fastboot oem unlock. That's it.
Rooting a phone implies root access was not intended, and you must exploit a security flaw to gain access. If root access was intended from the beginning, how can running the command to do so possibly be considered exploiting a security flaw?
To put it another way, is sudo a security flaw in Linux? That's basically what Engadget is saying, and the Android devs are saying that's stupid, and oh yeah phones should be open so rooting goes the way of the do-do bird.
The housing market is greatly hampered by various levels of government. Look at Fannie Mae / Freddie Mac. Look at building codes. Look at zoning regulations.
In the US, pretty much nobody goes without food unless they have mental problems, in which case their problem is mental, not foodal.
So clearly the conclusion we must draw is that capitalism has utterly failed.
What does large-scale fraud have to do with deregulation?
Regulation does not prevent fraud, and deregulation does not encourage fraud. The only thing that changes is exactly what kinds of fraud are committed.
Fraud in all its forms should be aggressively prosecuted.
Do you understand how inflation works?
Depending upon exactly which metric you are looking at (some react faster than others), $1 in 1980 would be worth between $2.60 and $5 today. Average looks to be right around $3, which also coincides with the most relevant metric: consumer prices. 300% inflation was the original AC's claim, he was just confused about what that actually meant for prices today vs prices 30 years ago. In uber simple terms that even AC should be able to understand, inflation means there are more dollars out there, but each one is worth 1/3 what it used to be.
If $1 in 1980 is worth $3 today, then $1000 in 1980 would be worth $3000 today. That is a fact, there is no question that this is so. You can check for yourself here if you don't believe me. They have a handy dandy calculator so you can figure out the value for a particular span of years. For what its worth, it was pretty stead inflation until 2008, after which some metrics deflated while others (like consumer goods) have quite rapidly inflated.
The second portion of this discussion has been anecdotal. The claim that a cross-country trip cost $1000 30 years ago which now costs $450. I personally can't comment regarding flying that far back, but it does fit with my experience over the last 20 years or so.
Compare that $1000 ticket, which in today's inflated dollars would be $3000, to the $450 ticket of today, and there is an extremely obvious and massive decline in price between then and now.
How did that dollar sign get there?? 0.o
Wait what?
If 2010 dollars are 1/3 that of 1980 dollars, then the adjusted price for the 1980 $1,000 ticket is $3,000.
That makes the $2010 ticket a whopping 1/6 the price of the 1980 ticket.
You suck at math dude.
Dumb politicians only mess everything up.
You had some superfluous words in there, so I tidied it up for you.
What the fuck kind of ass-backwards retarded "free" market is that?
"Here's our Free Market over here, and this 8 foot tall 600 pound gentleman over here is Tiny, he rules the Free Market with an iron fist."
Next you'll be saying we need to set up a Ministry of Peace to start wars (so we can have peace, of course) and a Ministry of Truth to sanitize all speech and print (to only the truth is heard, of course).
If you need the other 40%, you can probably afford the $4k.
Also, expect AutoCad to release cheaper, hobby versions of their software if this takes off.
Bingo.
It's certainly possible to copy other equipment, but unless it is ridiculously overpriced it will not be economical to do so.
If the item is ridiculously overpriced, then the price needs to come down anyway.