Hmm. It doesn't look to me like you've changed the coding and maintenance game rules. It just looks to me like you've implemented a domain-specific language, where the application code is written in XML which gets translated to Java. That's a tried and true approach, and it works very well within the domain of the domain-specific language. But outside of the specific domain, you're right back at square one.
(Disclaimer: I work for Google, and part of my work is related to Wallet, but I have carefully restricted my comments to exactly what I would have said based on the knowledge I had before joining Google.)
Partitioning your knowledge like this is an interesting and valuable skill. Did they teach you this before or after teaching you the secret of levitation?
It's not that hard. I just thought about what I would have said if presented with this same story a year ago. Since I was actively thinking and discussing such things at that time, it wasn't difficult.
Stupid story and I read somewhere that even some stupid phone provider in the US (Verizon maybe?) has delayed the sale of the Nexus because of this.
I think what you're referring to is that Verizon has refused to allow Google Wallet on the new Galaxy Nexus, and has used this as part of their justification. However, it seems more likely that their real concern with Google Wallet is that they're part of a consortium (ISIS) which is developing a competitor to Google Wallet. Verizon wants to be able to rent space on the secure elements in the phones on their network. They figure credit card issuers and others will pay for the right to get their stuff installed in phones. I suspect they also have visions of someday cutting the card companies out of the loop and taking the transaction fees for themselves. Google offering the same service for free is not something they want to support, hence the FUD campaign.
"Hey man, could I borrow your phone for a sec to call home? Mine ran out of battery."
More like "Hey man, could I borrow your phone for an hour, hook it up to my computer, use an exploit to root it without wiping it and then go rummaging around in the contained SQLite databases?"
Okay, the attacker obviously wouldn't ask that. But this requires far more than borrowing a phone "for a sec" to make a phone call.
I think the point was that it makes it easier to pull off the "social engineering" if you have access to information only privileged parties should have. They should still be encrypting the locally stored data, and it's just lazy not to.
Encrypt it with what key?
This attack already requires a rooted phone. If the attacker has your phone, and has rooted it, then he has access to any key stored on the phone.
The key could be derived from your PIN, but that's four digits. How long does it take to brute force search 10^4 possibilities? Milliseconds. This would be a ciphertext-only attack, so the the attacker would need to be able to recognize the correct plaintext. If all of the potentially-sensitive data were encrypted, picking the correct plaintext would be trivial. If only the most-sensitive info -- last four and expiration -- were encrypted, it would be harder, but not much, given that valid months must be in the 1-12 range and valid years must be within current + 2-3. In fact, all but ~3% * ~12% = ~0.36% of plaintext candidates could be excluded out of hand.
Perhaps a custom compression function could be used to compress all of the available entropy into as few bits as possible before encryption to make it harder to discard plaintext candidates -- but keep in mind that there may be multiple cards stored in the app, so the compression function would have to be flexible enough to handle an arbitrary number of cards, without getting weaker. It would also be good if it could include the user's name, etc. I suspect it could be done, but it's well beyond just "non-laziness". In fact it's a mini research project.
The real solution would involve putting the data in the SE, but that would require modifying the payment app. I spent over a decade working in that space (smart card payment) and I think even Google would shy away from modifying the MasterCard PayPass app. The certification costs for any change are staggering. Not that Google couldn't do it, or afford the certification, but it would be a tremendous cost, to protect data that is (a) on every plastic card out there (compare losing your Google Wallet phone with losing your regular wallet) and (b) pretty widely available even without the plastic card.
(Disclaimer: I work for Google, and part of my work is related to Wallet, but I have carefully restricted my comments to exactly what I would have said based on the knowledge I had before joining Google.)
Oh, so this is on a users phone? (Yea I didn't read FTA).
If so, this is right up there with the previous scandal about Android keeping passwords in plaintext. In that case you had to be root to gain access them, meaning whether or not they were stored as plaintext would be a moot point. If you're root, then surely you can do anything including invoke any methods used for decryption. Same goes for this.
Root access is also required for this attack. Without root, a person with your phone can't get the unencrypted data. Rooting the phone via normal means (i.e. not exploiting some other security defect) will wipe the data.
The federal government is also bound by the US constitution. The federal government cannot change the constitution on its own. Does that mean it is not sovereign? According to the US Supreme Court, the federal government and the state governments are all sovereign.
The states within the USA are not sovereign by pretty much any definition of a sovereign state.
Nonsense. The normal definition of sovereign is that a political entity is sovereign if it has authority to make and enforce laws that does not derive from any other legal authority. The US states do not derive their lawmaking power from the federal government. In fact it's really the reverse; the Constitution passes specific, enumerated powers to the federal government but outside of those defined areas all else is of the states. This is different from the authority that counties and municipalities have to pass ordinances: That authority is specifically granted to them by state law, and the state has complete freedom to expand or limit that authority in any way it sees fit. One implication of this is that double jeopardy does not attach when an accused person is tried both by a state and the federal government for the same crime, because the state and the federal government are "separate sovereigns".
If you want to argue that states aren't sovereign because of the enumerated powers given to the federal government, then you'd also have to argue that the federal government isn't sovereign because of the powers that are not given to it by the Constitution. Those include both the powers reserved to the states, and the powers that are taken from both states and federal government by the Constitution and its amendments: What we usually call "civil liberties". The US is far from unique in that respect. It's not even the first. The Magna Carta preceded the US Constitution by five centuries, for example.
We don't typically think of states as sovereign, and arguably the federal government has stretched certain portions of the Constitution to the breaking point and beyond in order to reduce state sovereignty, but that doesn't mean it's not real.
Take lines of code, for example. Some people hate it because you can bloat the numbers by adding comments, neglecting to consider how useful those comments are for future maintenance, and thereby a useful application of a developer's time.
The real problem with measuring lines of code is the erroneous idea that more lines == more productivity. What you really want is less code, not more, and that includes comments. Every line of code is a maintenance burden. It's something that has to be read and understood later so that new functionality can be added or bugs can be fixed. If God were a software developer, He would add functionality by deleting code, not writing it, and the result would be clearer and easier to understand than before.
Comments are actually worse than code in this respect. First, because they're rarely correct. They're usually mostly correct, but imprecision in expression almost invariably means that they can be misinterpreted in some way, and they often subtly disagree with the code they purport to document. That can actively mislead maintainers and increase maintenance cost. In addition, having comments means the comments have to be maintained, too! And they often aren't, which means that over time they become misleading.
The best developers write code that is so straightforward and understandable that no comments are necessary, and indeed they'd merely be a distraction and clutter if they were present. I don't always succeed at that lofty goal, but I do hesitate every time I feel the need to write a comment, and look for a way I can make that comment unnecessary. Perhaps a better variable or function name will express the intent of the code more clearly. In some cases I like to introduce an "unnecessary" temporary variable just for the information I can convey through its name, or factor out a section of a function into a subroutine, just so I can name the subroutine in an informative way.
I should mention that comments that document an interface are valuable, particularly the ones that are extracted to generate documentation (Javadoc, doxygen, docstring, etc.). Even those should not bother repeating information already contained in function and parameter names, though. In fact, names should be chosen that completely explain the purpose of the function (or class, etc.), and the focus of the documentation comment should be on spelling out the things that users of the function should watch out for -- defining handling of edge cases, warning about any potential surprises and explaining any non-obvious characteristics. Example usage is also excellent. Of course, if there is a lot of that sort of stuff that needs to be explained, it's a good sign that the interface design isn't very good and a refactoring is in order to make it less surprising. Whatever is documented must also be unit tested to ensure that maintainers notice if the documentation ever becomes wrong.
One other exception is some code that implements a highly-sophisticated algorithm, or a highly-optimized mathematical computation. Those can be opaque regardless of how cleanly the code is structured and how well the variables are named. In that case, though, the very best comment is one that just contains a hyperlink to the relevant research paper (plus usage information as described above). If the paper doesn't exist, write it and either host it at a persistent URL or add it to the source repository.
Bottom line: The goal is to make the code functional, flexible and clear. Comments in code are a quick 'n dirty hack to paper over ugly code, and like any other quick 'n dirty hack, they're expensive in the long run.
If I were to try to define some good metrics for developers, they would be based on functionality implemented per unit of time -- but only after the code had passed a rigorous review process to keep technical debt from accumulating. I'd also measure functionality implemented per line of code, and give a bump to dev
> The difference between the US and the EU is the powers delegated to the States
Well - yes - as far as it goes - but obviously there are all sorts of powers held by countries in the EU that are NOT delegated to them by the EU.
To be precise, the powers held by the US states are not delegated to them by the federal government, either. It's the other way around. The states have authorized the federal government certain, specific and enumerated powers as laid out in the Constitution. The 10th amendment clarifies that everything else belongs to the states, but that amendment was technically unnecessary given the structure of the main document.
That said, we long ago started ignoring inconvenient aspects of the Constitution, and allocation of powers is an area in which practice differs tremendously from what's written.
Under the Constitution the states are still sovereign. This is why, for example, you can be tried and convicted by both the federal government and the state government for the same crime, and it's not considered double jeopardy.
Umm, if your normal judgment and attitude is so bad that you have to impair your reactions in order to calm yourself to a reasonable level... you should seriously consider giving up driving.
That's why I said "those who have full-time employment".
I do have to wonder a bit about the amount of unemployment angst here. From where I sit the job market for software developers, at least, is very healthy. It's a little tougher for people with little experience, and a little tougher at the more senior end (salary > $120K), but the midrange is almost a seller's market -- and the ends aren't too bad.
But I suppose it's not the same everywhere, and a lot of slashdotters are more "IT guys", rather than developers, and I don't really know anything about that market.
Hehe. The funny thing is that most 4channers and Slashdotters will probably be in the top 5% or so when you take the world population into account..
The US median household income is about $48K. According to http://www.globalrichlist.com/, someone making $48K annually is in the top 0.99% worldwide. So half of Americans are "one-percenters". I think the average well-established (10+ years experience, good track record) software engineer makes over $100K, which puts them in the top 0.66% worldwide.
To make the top 1% in the US (in terms of household income, which isn't the same as wealth), you have to have an annual income in excess of $300K, which puts you on the top 0.001% worldwide.
To be in the top 5% worldwide you need an annual household income of $33,700 or higher. I suspect that very, very few slashdotters who have full-time employment fall below that level.
A tiny bit of pot before a trip prevents me from becoming a dangerous, road raging speed fiend. I'm sure there's some impairment, but it's negligible compared to the alternative.
If that's true, I think you should seriously consider giving up driving.
Because plenty of reputable guys on Wall Street are selling Abilify for $700 for 60mg. I don't think ACTUAL illegal drugs are that much per gram to make to feel good.
Why would anyone want to abuse Abilify? That stuff has a massive list of severe and nasty side effects and doesn't do anything to make you feel good; it pretty much just steamrollers your emotions flat -- unless you hit some of the emotional side effects which pretty much just make you want to kill yourself.
My daughter is on Abilify and it actually does seem to help her, but she has a serious mood disorder. Even though it helps stabilize her moods, her psychiatrist is taking her off of it because of the nasty physical side effects. We're hoping to be able to find something else which will help more and harm less.
Huh, I thought it was because IBM has become pretty worthless on the hardware and invention front since they became primarily a consultancy.
IBM still spends more on R&D than any other tech company, and still receives more patents than anyone else -- and IBM's patents by and large tend to be pretty meaningful ones. While it's true that about half of IBM is focused on consulting these days, that still leaves over 200,000 employees doing other stuff. I haven't checked the numbers recently, but as of a couple of years ago, IBM was still the second-largest software company on the planet, as well as being the largest maker of server hardware, and the world's largest technology consultant.
IBM is huge.
(Power CPU's and stuff notwithstanding, I am kidding a little. But scalpel? REALLY? Anyone that can say that IBM wields proprietary aspects of their computer technology like a frickin' scalpel needs to reexamine the first 70 or 80 years of IBM's history).
First, the subject was how IBM uses its patent portfolio, not the much broader topic of "proprietary aspects of their computer technology". Second, IBM's a radically different company today than it was for the first 70 or 80 years of its history. Heck, it's a very different company than it was 10 years ago (I know, I was working there and watched it changing), and it's hugely different than it was in the 60s and 70s, prior to the anti-trust suits and the massive bloodletting of the 80s, and the layoffs of the 90s.
I'm not saying IBM doesn't do some underhanded crap. They do. And they exploit the hell out of their employees; I'm very glad I left. But I am saying that what they did 30 years ago really has no bearing on today, and what they did 20 years ago has little bearing.
And I do think they use their patent portfolio very responsibly. So far.
With the discovery of this tunnel and the seizure of 2000 pounds of blow, the War on Drugs is clearly all but over.
Re:Anyone seen the new Google Calendar / Gmail?
on
The Condescending UI
·
· Score: 1
A lot of your comments on the new calendar look are just wrong.
I just opened up two calendars, side by side, one with the new look (including the removal of the black bar on top) and one with the "classic" look (which is still an option if you prefer it... just look under "Settings"). Things I noted:
The new look makes better use of vertical whitespace. Even with a slightly larger font I can see an additional hour of my schedule every day.
The extra lines and shadings separating UI elements, which you seem to like so much, make absolutely no difference for me. They don't make it any easier to find what I'm interested in. They're just clutter.
The darker bars on the top of each appointment don't accomplish anything useful. The layout of the text within the appointments is identical, except that in some cases the lack of the header bar allows more reflowing of text so that you can see more of the information.
In fairness, your screenshot was from a "mid-change" version. The full new look eliminates the black bar across the top, merging all of its functionality into the bar below it, which more than resolves your one real complaint. Note that you may still not have gotten the update that eliminates the bar. If not, it'll come in the next few days.
I also have to say that I think there is one big problem with the new look, and it has to do with the elimination of that black bar and the mechanism used to replace it. Now you cursor over the Google logo and a menu pops up that allows you to navigate between mail, calendar, contacts, and all of the other Google services. That wouldn't be too terrible, but the layout of the options in that popup is pretty weird. I have to go to "More" to get to calendar, even though the calendar is something I use a dozen times a day. But YouTube and News are on the first page of options, even though I rarely use those, except when they come up in search results.
IMO, the menu order ought to be personalizable, and perhaps be personalized automatically. Even better, for power users we should just have keyboard shortcuts that allow us to quickly hop from any Google service to any other. I do have confidence that this issue will get sorted out.
THUS, it wouldn't matter WHERE THE ERRORS COME FROM, they cause hassles for END USERS... period!
The subject of the discussion was whether or not sandboxes work. Programming errors in code running in the sandbox are irrelevant to that topic; what matters is whether or not malicious software can break out of the sandbox.
This is as "real" as it gets (though I prefer posting real-world practice findings as I did above & in my initial post you replied to) -> http://secunia.com/advisories/product/12878/ [secunia.com]
Wow a total of four vulnerabilities discovered in 2011. Thank you for making my point.
Slashdot Mirror
Hmm. It doesn't look to me like you've changed the coding and maintenance game rules. It just looks to me like you've implemented a domain-specific language, where the application code is written in XML which gets translated to Java. That's a tried and true approach, and it works very well within the domain of the domain-specific language. But outside of the specific domain, you're right back at square one.
(Disclaimer: I work for Google, and part of my work is related to Wallet, but I have carefully restricted my comments to exactly what I would have said based on the knowledge I had before joining Google.)
Partitioning your knowledge like this is an interesting and valuable skill. Did they teach you this before or after teaching you the secret of levitation?
It's not that hard. I just thought about what I would have said if presented with this same story a year ago. Since I was actively thinking and discussing such things at that time, it wasn't difficult.
Stupid story and I read somewhere that even some stupid phone provider in the US (Verizon maybe?) has delayed the sale of the Nexus because of this.
I think what you're referring to is that Verizon has refused to allow Google Wallet on the new Galaxy Nexus, and has used this as part of their justification. However, it seems more likely that their real concern with Google Wallet is that they're part of a consortium (ISIS) which is developing a competitor to Google Wallet. Verizon wants to be able to rent space on the secure elements in the phones on their network. They figure credit card issuers and others will pay for the right to get their stuff installed in phones. I suspect they also have visions of someday cutting the card companies out of the loop and taking the transaction fees for themselves. Google offering the same service for free is not something they want to support, hence the FUD campaign.
"Hey man, could I borrow your phone for a sec to call home? Mine ran out of battery."
More like "Hey man, could I borrow your phone for an hour, hook it up to my computer, use an exploit to root it without wiping it and then go rummaging around in the contained SQLite databases?"
Okay, the attacker obviously wouldn't ask that. But this requires far more than borrowing a phone "for a sec" to make a phone call.
I think the point was that it makes it easier to pull off the "social engineering" if you have access to information only privileged parties should have. They should still be encrypting the locally stored data, and it's just lazy not to.
Encrypt it with what key?
This attack already requires a rooted phone. If the attacker has your phone, and has rooted it, then he has access to any key stored on the phone.
The key could be derived from your PIN, but that's four digits. How long does it take to brute force search 10^4 possibilities? Milliseconds. This would be a ciphertext-only attack, so the the attacker would need to be able to recognize the correct plaintext. If all of the potentially-sensitive data were encrypted, picking the correct plaintext would be trivial. If only the most-sensitive info -- last four and expiration -- were encrypted, it would be harder, but not much, given that valid months must be in the 1-12 range and valid years must be within current + 2-3. In fact, all but ~3% * ~12% = ~0.36% of plaintext candidates could be excluded out of hand.
Perhaps a custom compression function could be used to compress all of the available entropy into as few bits as possible before encryption to make it harder to discard plaintext candidates -- but keep in mind that there may be multiple cards stored in the app, so the compression function would have to be flexible enough to handle an arbitrary number of cards, without getting weaker. It would also be good if it could include the user's name, etc. I suspect it could be done, but it's well beyond just "non-laziness". In fact it's a mini research project.
The real solution would involve putting the data in the SE, but that would require modifying the payment app. I spent over a decade working in that space (smart card payment) and I think even Google would shy away from modifying the MasterCard PayPass app. The certification costs for any change are staggering. Not that Google couldn't do it, or afford the certification, but it would be a tremendous cost, to protect data that is (a) on every plastic card out there (compare losing your Google Wallet phone with losing your regular wallet) and (b) pretty widely available even without the plastic card.
(Disclaimer: I work for Google, and part of my work is related to Wallet, but I have carefully restricted my comments to exactly what I would have said based on the knowledge I had before joining Google.)
Oh, so this is on a users phone? (Yea I didn't read FTA).
If so, this is right up there with the previous scandal about Android keeping passwords in plaintext. In that case you had to be root to gain access them, meaning whether or not they were stored as plaintext would be a moot point. If you're root, then surely you can do anything including invoke any methods used for decryption. Same goes for this.
Root access is also required for this attack. Without root, a person with your phone can't get the unencrypted data. Rooting the phone via normal means (i.e. not exploiting some other security defect) will wipe the data.
The federal government is also bound by the US constitution. The federal government cannot change the constitution on its own. Does that mean it is not sovereign? According to the US Supreme Court, the federal government and the state governments are all sovereign.
The states within the USA are not sovereign by pretty much any definition of a sovereign state.
Nonsense. The normal definition of sovereign is that a political entity is sovereign if it has authority to make and enforce laws that does not derive from any other legal authority. The US states do not derive their lawmaking power from the federal government. In fact it's really the reverse; the Constitution passes specific, enumerated powers to the federal government but outside of those defined areas all else is of the states. This is different from the authority that counties and municipalities have to pass ordinances: That authority is specifically granted to them by state law, and the state has complete freedom to expand or limit that authority in any way it sees fit. One implication of this is that double jeopardy does not attach when an accused person is tried both by a state and the federal government for the same crime, because the state and the federal government are "separate sovereigns".
If you want to argue that states aren't sovereign because of the enumerated powers given to the federal government, then you'd also have to argue that the federal government isn't sovereign because of the powers that are not given to it by the Constitution. Those include both the powers reserved to the states, and the powers that are taken from both states and federal government by the Constitution and its amendments: What we usually call "civil liberties". The US is far from unique in that respect. It's not even the first. The Magna Carta preceded the US Constitution by five centuries, for example.
We don't typically think of states as sovereign, and arguably the federal government has stretched certain portions of the Constitution to the breaking point and beyond in order to reduce state sovereignty, but that doesn't mean it's not real.
Yeah, I sure they are...
They are according to the US Supreme Court. That's why it's not double jeopardy if you're tried by the state and the feds for the same crime.
Take lines of code, for example. Some people hate it because you can bloat the numbers by adding comments, neglecting to consider how useful those comments are for future maintenance, and thereby a useful application of a developer's time.
The real problem with measuring lines of code is the erroneous idea that more lines == more productivity. What you really want is less code, not more, and that includes comments. Every line of code is a maintenance burden. It's something that has to be read and understood later so that new functionality can be added or bugs can be fixed. If God were a software developer, He would add functionality by deleting code, not writing it, and the result would be clearer and easier to understand than before.
Comments are actually worse than code in this respect. First, because they're rarely correct. They're usually mostly correct, but imprecision in expression almost invariably means that they can be misinterpreted in some way, and they often subtly disagree with the code they purport to document. That can actively mislead maintainers and increase maintenance cost. In addition, having comments means the comments have to be maintained, too! And they often aren't, which means that over time they become misleading.
The best developers write code that is so straightforward and understandable that no comments are necessary, and indeed they'd merely be a distraction and clutter if they were present. I don't always succeed at that lofty goal, but I do hesitate every time I feel the need to write a comment, and look for a way I can make that comment unnecessary. Perhaps a better variable or function name will express the intent of the code more clearly. In some cases I like to introduce an "unnecessary" temporary variable just for the information I can convey through its name, or factor out a section of a function into a subroutine, just so I can name the subroutine in an informative way.
I should mention that comments that document an interface are valuable, particularly the ones that are extracted to generate documentation (Javadoc, doxygen, docstring, etc.). Even those should not bother repeating information already contained in function and parameter names, though. In fact, names should be chosen that completely explain the purpose of the function (or class, etc.), and the focus of the documentation comment should be on spelling out the things that users of the function should watch out for -- defining handling of edge cases, warning about any potential surprises and explaining any non-obvious characteristics. Example usage is also excellent. Of course, if there is a lot of that sort of stuff that needs to be explained, it's a good sign that the interface design isn't very good and a refactoring is in order to make it less surprising. Whatever is documented must also be unit tested to ensure that maintainers notice if the documentation ever becomes wrong.
One other exception is some code that implements a highly-sophisticated algorithm, or a highly-optimized mathematical computation. Those can be opaque regardless of how cleanly the code is structured and how well the variables are named. In that case, though, the very best comment is one that just contains a hyperlink to the relevant research paper (plus usage information as described above). If the paper doesn't exist, write it and either host it at a persistent URL or add it to the source repository.
Bottom line: The goal is to make the code functional, flexible and clear. Comments in code are a quick 'n dirty hack to paper over ugly code, and like any other quick 'n dirty hack, they're expensive in the long run.
If I were to try to define some good metrics for developers, they would be based on functionality implemented per unit of time -- but only after the code had passed a rigorous review process to keep technical debt from accumulating. I'd also measure functionality implemented per line of code, and give a bump to dev
> The difference between the US and the EU is the powers delegated to the States
Well - yes - as far as it goes - but obviously there are all sorts of powers held by countries in the EU that are NOT delegated to them by the EU.
To be precise, the powers held by the US states are not delegated to them by the federal government, either. It's the other way around. The states have authorized the federal government certain, specific and enumerated powers as laid out in the Constitution. The 10th amendment clarifies that everything else belongs to the states, but that amendment was technically unnecessary given the structure of the main document.
That said, we long ago started ignoring inconvenient aspects of the Constitution, and allocation of powers is an area in which practice differs tremendously from what's written.
I think you are simply incorrect that the a "state" is ANY politically distinct entity.
I think the true distinction is that the entity must be sovereign to be a state.
In fact, the USA as a whole is a state
And the states in the USA are sovereign political entities, and hence are truly states as well.
Under the Constitution the states are still sovereign. This is why, for example, you can be tried and convicted by both the federal government and the state government for the same crime, and it's not considered double jeopardy.
CarrierIQ sends your text messages
Completely false. It might be accidentally logging received messages, but even those aren't human readable.
Except to teenagers.
But then, I think a good argument can be made that teenagers aren't human, so I guess you're right.
Umm, if your normal judgment and attitude is so bad that you have to impair your reactions in order to calm yourself to a reasonable level... you should seriously consider giving up driving.
Those that have jobs, at least :/
That's why I said "those who have full-time employment".
I do have to wonder a bit about the amount of unemployment angst here. From where I sit the job market for software developers, at least, is very healthy. It's a little tougher for people with little experience, and a little tougher at the more senior end (salary > $120K), but the midrange is almost a seller's market -- and the ends aren't too bad.
But I suppose it's not the same everywhere, and a lot of slashdotters are more "IT guys", rather than developers, and I don't really know anything about that market.
Hehe. The funny thing is that most 4channers and Slashdotters will probably be in the top 5% or so when you take the world population into account..
The US median household income is about $48K. According to http://www.globalrichlist.com/, someone making $48K annually is in the top 0.99% worldwide. So half of Americans are "one-percenters". I think the average well-established (10+ years experience, good track record) software engineer makes over $100K, which puts them in the top 0.66% worldwide.
To make the top 1% in the US (in terms of household income, which isn't the same as wealth), you have to have an annual income in excess of $300K, which puts you on the top 0.001% worldwide.
To be in the top 5% worldwide you need an annual household income of $33,700 or higher. I suspect that very, very few slashdotters who have full-time employment fall below that level.
A tiny bit of pot before a trip prevents me from becoming a dangerous, road raging speed fiend. I'm sure there's some impairment, but it's negligible compared to the alternative.
If that's true, I think you should seriously consider giving up driving.
Because plenty of reputable guys on Wall Street are selling Abilify for $700 for 60mg. I don't think ACTUAL illegal drugs are that much per gram to make to feel good.
Why would anyone want to abuse Abilify? That stuff has a massive list of severe and nasty side effects and doesn't do anything to make you feel good; it pretty much just steamrollers your emotions flat -- unless you hit some of the emotional side effects which pretty much just make you want to kill yourself.
My daughter is on Abilify and it actually does seem to help her, but she has a serious mood disorder. Even though it helps stabilize her moods, her psychiatrist is taking her off of it because of the nasty physical side effects. We're hoping to be able to find something else which will help more and harm less.
Huh, I thought it was because IBM has become pretty worthless on the hardware and invention front since they became primarily a consultancy.
IBM still spends more on R&D than any other tech company, and still receives more patents than anyone else -- and IBM's patents by and large tend to be pretty meaningful ones. While it's true that about half of IBM is focused on consulting these days, that still leaves over 200,000 employees doing other stuff. I haven't checked the numbers recently, but as of a couple of years ago, IBM was still the second-largest software company on the planet, as well as being the largest maker of server hardware, and the world's largest technology consultant.
IBM is huge.
(Power CPU's and stuff notwithstanding, I am kidding a little. But scalpel? REALLY? Anyone that can say that IBM wields proprietary aspects of their computer technology like a frickin' scalpel needs to reexamine the first 70 or 80 years of IBM's history).
First, the subject was how IBM uses its patent portfolio, not the much broader topic of "proprietary aspects of their computer technology". Second, IBM's a radically different company today than it was for the first 70 or 80 years of its history. Heck, it's a very different company than it was 10 years ago (I know, I was working there and watched it changing), and it's hugely different than it was in the 60s and 70s, prior to the anti-trust suits and the massive bloodletting of the 80s, and the layoffs of the 90s.
I'm not saying IBM doesn't do some underhanded crap. They do. And they exploit the hell out of their employees; I'm very glad I left. But I am saying that what they did 30 years ago really has no bearing on today, and what they did 20 years ago has little bearing.
And I do think they use their patent portfolio very responsibly. So far.
With the discovery of this tunnel and the seizure of 2000 pounds of blow, the War on Drugs is clearly all but over.
A lot of your comments on the new calendar look are just wrong.
I just opened up two calendars, side by side, one with the new look (including the removal of the black bar on top) and one with the "classic" look (which is still an option if you prefer it... just look under "Settings"). Things I noted:
In fairness, your screenshot was from a "mid-change" version. The full new look eliminates the black bar across the top, merging all of its functionality into the bar below it, which more than resolves your one real complaint. Note that you may still not have gotten the update that eliminates the bar. If not, it'll come in the next few days.
I also have to say that I think there is one big problem with the new look, and it has to do with the elimination of that black bar and the mechanism used to replace it. Now you cursor over the Google logo and a menu pops up that allows you to navigate between mail, calendar, contacts, and all of the other Google services. That wouldn't be too terrible, but the layout of the options in that popup is pretty weird. I have to go to "More" to get to calendar, even though the calendar is something I use a dozen times a day. But YouTube and News are on the first page of options, even though I rarely use those, except when they come up in search results.
IMO, the menu order ought to be personalizable, and perhaps be personalized automatically. Even better, for power users we should just have keyboard shortcuts that allow us to quickly hop from any Google service to any other. I do have confidence that this issue will get sorted out.
And on ISPs. Cox and Time Warner (Road Runner) started running consumer IPv6 pilots this year, and I wouldn't be surprised if other ISPs also started.
http://www.comcast6.net
THUS, it wouldn't matter WHERE THE ERRORS COME FROM, they cause hassles for END USERS... period!
The subject of the discussion was whether or not sandboxes work. Programming errors in code running in the sandbox are irrelevant to that topic; what matters is whether or not malicious software can break out of the sandbox.
This is as "real" as it gets (though I prefer posting real-world practice findings as I did above & in my initial post you replied to) -> http://secunia.com/advisories/product/12878/ [secunia.com]
Wow a total of four vulnerabilities discovered in 2011. Thank you for making my point.