I'm aware of Thompson's essay on the subject, and also the ramifications of it, which is to say that you actually can't trust any code, ever, as to do so would mean compiling it with a compiler that you wrote, and compiling that with a compiler you wrote, and compiling that with... (ad nauseum). And that's not even to mention the whole issue of trusting the hardware itself (which you likely didn't build).
However, insofar as source code can be trusted, which is to say that it can at least be partially trusted, or at least more trusted than a binary with no available source code, then at least the source to (some of) Android is available. And that fact, combined with the noticeable difference in battery usage, suggests that the system can be at least somewhat trusted to actually turn off the GPS when it claims that it has done so.
There are no guarantees in this world, but of all the things that can keep me up at night worrying, whether or not my phone actually does turn off its GPS when it tells me it has is not high on my worry list.
If only producing things at the production quality people expect in music they pay money for were just as "you + computer, viola" as Slashdot believes...
Who said anything about needing a viola?;)
But seriously, you obviously need talent, and it definitely helps to surround yourself with other people who have talent (other musicians, audio engineers, etc). The thing is, there are lots of amateurs with talent in those areas. The Internet provides a means to connect with them, modern technology provides the ability for those without too much money to create content, and the WWW provides the ability to distribute. It's not a perfect system, but honestly, a decently talented amateur musician nowadays has a much better chance of becoming known online, at least enough to subsidize their efforts, maybe even make an honest living out of it, than they ever had before when their only hope was to get "discovered" by some elusive record company exec who'll promise them zillions of dollars and all the girls they can screw, only to turn around and screw them from the get-go.
I'm an amateur musician as well, and I used to be a professional musician (independent, mind you), and I'm quite enjoying watching the music industry crumble. I do think that society has shifted to a mindset that really doesn't value content highly (monetarily speaking), but I'm not convinced that's entirely a bad thing. On the other hand, I'm also not convinced that that in any way prevents artists from being able to make a living. It might spell the end of the mega-rich superstar, but that's not something I'll mourn the loss of.
Its also possible to recover data from a drive after writing zeros to it just one time. Its going to cost enough to be cost prohibitive in most cases, but its not impossible to pull off, of course its also not very reliable to get useful data out of it either.
At one time, with older technology, it was theoretically possible to do this. Nobody to my knowledge has ever actually managed to do it in the real world.
With today's technology, it's not even theoretically possible. A good explanation can be found here.
Actually, you're wrong, but you can be excused for it, because you relied on the article. The problem is that the article is wrong.
If you actually look at the text of the law itself, it explicitly says that passwords, either plaintext or hashed, must be retained only if they are currently stored. The law doesn't tell you what you have to store, just how long you have to store it for, and requires you to give it up to the police when asked.
Interestingly, I had to put little watermarks on about 400 images a year ago. It took about 5 minutes of scripting with ImageMagick to do it.
If I'd done that with Photoshop or GIMP, I'd still be at it!
You're comparing ImageMagick to Photoshop/GIMP, not CLI to GUI.
There is no reason a GUI application couldn't provide the ability for you to define how a watermark is applied, then select a directory containing 400 images and apply that watermark to those images with a click of the "Apply" button. If they didn't provide that functionality, then that's a design decision, not a limitation of the GUI concept in general.
Of course, some dumbass developer could be concatenating a SQL command using the raw input data without scrubbing it and running the command against the DB.
This happens all the time. Developers need to be aware of SQL Injection and how to prevent it. You cannot just implement something like parameterized queries and assume that you're defended against the ignorance of other developers on your team. You have to train them.
This would be extremely useful in increasing the quality of search results if people could '+1' search results anonymously. Instead, Google's using this EXACTLY like the "Like" button on Facebook, which relies on having friends on Google already to be useful.
If it were implemented in a public way, it would be useless, and nothing but another avenue for gaming search results. It's useful precisely because it is influenced primarily by people who are most likely to have interests similar to your own.
Why can't Google understand that I simply do not want to broadcast my searches to the world? I have been trusting Google with that information. If they want to use my click-throughs as part of their search algorithms, that's fine. But why do they want me to attach my name to it? Google keeps trying to go social and that goes against all the trust we put in Google's privacy policies.
Actually, they do get it. That's why you have to go out of your way to opt in to this by creating a public profile, and then clicking the "+1" button where applicable. The rest of us, who have no interest in it, can continue to use Search the way we always have.
If you say more people found it easier to use than the Zune, you're on the right track.
Really? You think the Zune lost because it's difficult to use? Have you tried a Zune? Most people haven't. Most people have never even held one in their hands. I don't know anyone who hasn't tried an iPod. You'd have to be a complete moron to find the iPod "easier to use" than the Zune. Not that the iPod is difficult to use (although I didn't get the stupid wheel thing the first time I saw it), but neither is the Zune. Most people simply never tried it. The Zune lost for many reasons, but not because it's difficult to use.
More features usually means less well developed features which means worse.
You're discussing generalities. I'm discussing a specific product comparison. I have an iPod, and my wife has a Zune, and although I like my iPod and don't regret the purchase, I find the Zune to be the superior device.
The problem is that you defined the market so narrow as to guarantee a win for the Zune.
But that's what I was talking about: the Zune. Not the Zune line of products, or the market it was in, but the basic Zune itself. Not Zune HD. Not Zune XP2020 or whatever else they might come out with. Just the Zune. A product, not a market. All I said is that it's better than the iPod, but people who were looking for that type of product, meaning an audio/video player with large storage capacity, chose the iPod over the Zune for other reasons, such as the perceived "coolness" of the iPod.
As for the market in general, you're absolutely right. Microsoft has always been playing catch-up, and they're not very good at it.
The Zune was better than the iPod Classic. The problem for MS was it was not better than the iPod Touch which Apple released after the Zune.
But the basic Zune was a competitor to the iPod Classic, not the iPod Touch. For people just looking for something to carry around all their music on, the choice is between the Zune and the iPod Classic, and the Zune is the better choice, in my opinion.
The iPod Touch is really just a wannabe smartphone. I don't see its value at all anymore. But there is still value for a basic audio player— at least until smartphones start matching the storage capacity.
No, but neither does more features == worse. The Zune did everything the iPod Classic did, plus more. If the "more" amounted to "nothing useful", then the worst you could say is that the Zune was "as good, but no better than" the iPod Classic. However, I find some of those features useful, making it better.
Apple learned that lesson. MS still hasn't.
More accurately, I think, Apple has learned to put in just enough features to make the product successful, while still holding back some features to cash in on the next generation.
The Zune wasn't really bad (it wasn't that good either)
It was better than its primary competitor, the iPod, which didn't come with an FM receiver, wireless synch, or a simple drag-and-drop interface for adding/removing songs, and had a smaller screen and less intuitive interface.
but the early defining feature seemed to be the fecal color
Which was only one of three available colours at the time, the other two being black and white. But people clung to the ugly brown because, let's face it, they wanted to hate it, because Microsoft is just not cool in consumers' minds.
It's unfortunate. Microsoft does make some crap products, but they also make some good ones. The Zune was a good product that simply failed in people's minds.
Dedicated eBook Readers serve a purpose that no other device can match, due to their e-ink screens (way easier on the eyes, especially in poor light, and uses hardly any battery power). Unless tablet makers figure out how to have a regular tablet screen that can also become an e-ink screen when needed, I don't see tablets wiping out eBook Readers anytime.
Tablets, on the other hand, well, I haven't quite figured out yet what purpose they serve. I've seen them used in certain business settings (hospitals, for example), and I see the value there. But as a consumer, I just don't see the value. I have a laptop, a smartphone, a digital audio player, and an eBook Reader. These meet all my electronic needs, and while there is some overlap, each device provides something that the others cannot.
From 4:56 to 5:02 is six minutes. This guy thinks that someone visited his site at 4:56 pm and had time to read the page, decide to write an article, write the article, proofread it, send it to the editor, and post it, all in 6 minutes.
They should have simply provided a link to his site as one of their sources which his web logs prove they went to his site before publishing the article.
You missed the key point here: the web logs proved somebody went to his site 6 minutes before the article was published.
Generally speaking, newspaper articles don't get written, edited, and approved for publishing in 6 minutes. This guy is just full of himself. He did the simplest research that anyone could've done, and now he thinks that anyone else who did the same research must have stolen it from him.
That article is dated in early 2002. Most developers I know were quite unsure of C# and.NET in general in 2002. The consulting company I work for planned to launch an internal C# project in late 2002. We use internal projects as a training opportunity, so technology is chosen based on what skills would be most beneficial for our consultants to have experience with. Just before the project started, management decided to switch to Java because it was perceived to be a more valuable skill. In the years that have passed since then,.NET has caught up, so today we do about as much.NET work as Java work. But back then, it was still the new kid on the block, and most weren't sure what to think of it.
"Are you sure" dialogs are generally just an annoyance caused by lazy developers. They'd rather ask for verification (one line of code) than write functionality to allow the user to "undo" what they did if it turns out that they did it incorrectly. Of course, sometimes you're dealing with something that simply can't reasonably be "undone", and that's where there should always be an extra step, whether it's an extra step after the fact, such as a confirmation dialog, or an extra step before the fact, such as the "unlock" button or some other "safety cover" type of concept, as you described. For emergency systems, what you describe makes sense. For systems in general, any sort of extra step to validate intent is the right approach. If developers used confirmation dialogs appropriately (i.e. extremely sparingly), they would be quite effective and not nearly as hated as they are.
My favourite case of unnecessary and outrageously annoying confirmation dialogs: I was working with an internally built application (I didn't build it), and launched a screen that shows a simple listing of records, and allowed me to add/edit/delete these records. I wanted to delete all of the existing records. The only way to delete a record was to right-click on it and select "delete" from the context menu that appeared, which resulted in an "are you sure" dialog. There were about 70 records I needed to delete, and it did not allow multi-select. The context menu did not allow selection of items using the keyboard, so there was no convenient "right-click, D", it had to be "right-click, navigate down to Delete, click, navigate back up to the next record", plus, of course, clicking "Yes" on the confirmation dialog. Then, just to add insult to injury, when I had finally gotten through all of that, I clicked the "OK" button to close the window, which prompted me with "are you sure you want to save the changes to the database?" So, all those deletions weren't even committed to the database yet, despite forcing me to confirm every single one of them. I wanted to beat the developer with a crowbar.
Anyone who does usability studies can assure you that people won't read confirmations, they'll just blindly click OK.
This is true if you're discussing confirmations that come up for frequent actions. However, if your normal action (save) just happens without any confirmation, and your non-normal action (submit— how often do they actually need to use this system?) pops up a confirmation, it tends to catch you off guard and make you take notice that something unexpected is happening. This would be precisely the correct use of a confirmation dialog.
Slashdot Mirror
I'm aware of Thompson's essay on the subject, and also the ramifications of it, which is to say that you actually can't trust any code, ever, as to do so would mean compiling it with a compiler that you wrote, and compiling that with a compiler you wrote, and compiling that with... (ad nauseum). And that's not even to mention the whole issue of trusting the hardware itself (which you likely didn't build).
However, insofar as source code can be trusted, which is to say that it can at least be partially trusted, or at least more trusted than a binary with no available source code, then at least the source to (some of) Android is available. And that fact, combined with the noticeable difference in battery usage, suggests that the system can be at least somewhat trusted to actually turn off the GPS when it claims that it has done so.
There are no guarantees in this world, but of all the things that can keep me up at night worrying, whether or not my phone actually does turn off its GPS when it tells me it has is not high on my worry list.
On any of these devices (iphone / nexus / etc) what makes you think the "disable GPS" actually disables the GPS?
How about the significant difference in battery usage between "GPS on" and "GPS off"? In the case of Android, there's also the source code itself.
If only producing things at the production quality people expect in music they pay money for were just as "you + computer, viola" as Slashdot believes...
Who said anything about needing a viola? ;)
But seriously, you obviously need talent, and it definitely helps to surround yourself with other people who have talent (other musicians, audio engineers, etc). The thing is, there are lots of amateurs with talent in those areas. The Internet provides a means to connect with them, modern technology provides the ability for those without too much money to create content, and the WWW provides the ability to distribute. It's not a perfect system, but honestly, a decently talented amateur musician nowadays has a much better chance of becoming known online, at least enough to subsidize their efforts, maybe even make an honest living out of it, than they ever had before when their only hope was to get "discovered" by some elusive record company exec who'll promise them zillions of dollars and all the girls they can screw, only to turn around and screw them from the get-go.
I'm an amateur musician as well, and I used to be a professional musician (independent, mind you), and I'm quite enjoying watching the music industry crumble. I do think that society has shifted to a mindset that really doesn't value content highly (monetarily speaking), but I'm not convinced that's entirely a bad thing. On the other hand, I'm also not convinced that that in any way prevents artists from being able to make a living. It might spell the end of the mega-rich superstar, but that's not something I'll mourn the loss of.
Its also possible to recover data from a drive after writing zeros to it just one time. Its going to cost enough to be cost prohibitive in most cases, but its not impossible to pull off, of course its also not very reliable to get useful data out of it either.
At one time, with older technology, it was theoretically possible to do this. Nobody to my knowledge has ever actually managed to do it in the real world.
With today's technology, it's not even theoretically possible. A good explanation can be found here.
Actually, you're wrong, but you can be excused for it, because you relied on the article. The problem is that the article is wrong.
If you actually look at the text of the law itself, it explicitly says that passwords, either plaintext or hashed, must be retained only if they are currently stored. The law doesn't tell you what you have to store, just how long you have to store it for, and requires you to give it up to the police when asked.
Here is the Babel Fish translation of the law itself: http://66.163.168.225/babelfish/translate_url_content?.intl=us&lp=fr_en&trurl=http%3A%2F%2Fwww.legifrance.gouv.fr%2FaffichTexte.do%3Bjsessionid%3D%3FcidTexte%3DJORFTEXT000023646013%26dateTexte%3D%26oldAction%3DrechJO%26categorieLien%3Did
The key point in that link is the comment that says that passwords "should be preserved only insofar as the people usually collect them."
Interestingly, I had to put little watermarks on about 400 images a year ago. It took about 5 minutes of scripting with ImageMagick to do it.
If I'd done that with Photoshop or GIMP, I'd still be at it!
You're comparing ImageMagick to Photoshop/GIMP, not CLI to GUI.
There is no reason a GUI application couldn't provide the ability for you to define how a watermark is applied, then select a directory containing 400 images and apply that watermark to those images with a click of the "Apply" button. If they didn't provide that functionality, then that's a design decision, not a limitation of the GUI concept in general.
The ones I know of cost about $10,000. Are there cheaper ones that you're aware of?
Google already logs web searches. Without logging into a profile, this button provides them with no more information than they already had.
Of course, some dumbass developer could be concatenating a SQL command using the raw input data without scrubbing it and running the command against the DB.
This happens all the time. Developers need to be aware of SQL Injection and how to prevent it. You cannot just implement something like parameterized queries and assume that you're defended against the ignorance of other developers on your team. You have to train them.
This would be extremely useful in increasing the quality of search results if people could '+1' search results anonymously. Instead, Google's using this EXACTLY like the "Like" button on Facebook, which relies on having friends on Google already to be useful.
If it were implemented in a public way, it would be useless, and nothing but another avenue for gaming search results. It's useful precisely because it is influenced primarily by people who are most likely to have interests similar to your own.
Why can't Google understand that I simply do not want to broadcast my searches to the world? I have been trusting Google with that information. If they want to use my click-throughs as part of their search algorithms, that's fine. But why do they want me to attach my name to it? Google keeps trying to go social and that goes against all the trust we put in Google's privacy policies.
Actually, they do get it. That's why you have to go out of your way to opt in to this by creating a public profile, and then clicking the "+1" button where applicable. The rest of us, who have no interest in it, can continue to use Search the way we always have.
If you say more people found it easier to use than the Zune, you're on the right track.
Really? You think the Zune lost because it's difficult to use? Have you tried a Zune? Most people haven't. Most people have never even held one in their hands. I don't know anyone who hasn't tried an iPod. You'd have to be a complete moron to find the iPod "easier to use" than the Zune. Not that the iPod is difficult to use (although I didn't get the stupid wheel thing the first time I saw it), but neither is the Zune. Most people simply never tried it. The Zune lost for many reasons, but not because it's difficult to use.
More features usually means less well developed features which means worse.
You're discussing generalities. I'm discussing a specific product comparison. I have an iPod, and my wife has a Zune, and although I like my iPod and don't regret the purchase, I find the Zune to be the superior device.
The problem is that you defined the market so narrow as to guarantee a win for the Zune.
But that's what I was talking about: the Zune. Not the Zune line of products, or the market it was in, but the basic Zune itself. Not Zune HD. Not Zune XP2020 or whatever else they might come out with. Just the Zune. A product, not a market. All I said is that it's better than the iPod, but people who were looking for that type of product, meaning an audio/video player with large storage capacity, chose the iPod over the Zune for other reasons, such as the perceived "coolness" of the iPod.
As for the market in general, you're absolutely right. Microsoft has always been playing catch-up, and they're not very good at it.
The Zune was better than the iPod Classic. The problem for MS was it was not better than the iPod Touch which Apple released after the Zune.
But the basic Zune was a competitor to the iPod Classic, not the iPod Touch. For people just looking for something to carry around all their music on, the choice is between the Zune and the iPod Classic, and the Zune is the better choice, in my opinion.
The iPod Touch is really just a wannabe smartphone. I don't see its value at all anymore. But there is still value for a basic audio player— at least until smartphones start matching the storage capacity.
More features != better.
No, but neither does more features == worse. The Zune did everything the iPod Classic did, plus more. If the "more" amounted to "nothing useful", then the worst you could say is that the Zune was "as good, but no better than" the iPod Classic. However, I find some of those features useful, making it better.
Apple learned that lesson. MS still hasn't.
More accurately, I think, Apple has learned to put in just enough features to make the product successful, while still holding back some features to cash in on the next generation.
The Zune wasn't really bad (it wasn't that good either)
It was better than its primary competitor, the iPod, which didn't come with an FM receiver, wireless synch, or a simple drag-and-drop interface for adding/removing songs, and had a smaller screen and less intuitive interface.
but the early defining feature seemed to be the fecal color
Which was only one of three available colours at the time, the other two being black and white. But people clung to the ugly brown because, let's face it, they wanted to hate it, because Microsoft is just not cool in consumers' minds.
It's unfortunate. Microsoft does make some crap products, but they also make some good ones. The Zune was a good product that simply failed in people's minds.
Dedicated eBook Readers serve a purpose that no other device can match, due to their e-ink screens (way easier on the eyes, especially in poor light, and uses hardly any battery power). Unless tablet makers figure out how to have a regular tablet screen that can also become an e-ink screen when needed, I don't see tablets wiping out eBook Readers anytime.
Tablets, on the other hand, well, I haven't quite figured out yet what purpose they serve. I've seen them used in certain business settings (hospitals, for example), and I see the value there. But as a consumer, I just don't see the value. I have a laptop, a smartphone, a digital audio player, and an eBook Reader. These meet all my electronic needs, and while there is some overlap, each device provides something that the others cannot.
From 4:56 to 5:02 is six minutes. This guy thinks that someone visited his site at 4:56 pm and had time to read the page, decide to write an article, write the article, proofread it, send it to the editor, and post it, all in 6 minutes.
He's a looney.
They should have simply provided a link to his site as one of their sources which his web logs prove they went to his site before publishing the article.
You missed the key point here: the web logs proved somebody went to his site 6 minutes before the article was published.
Generally speaking, newspaper articles don't get written, edited, and approved for publishing in 6 minutes. This guy is just full of himself. He did the simplest research that anyone could've done, and now he thinks that anyone else who did the same research must have stolen it from him.
And slashdot
I admit, I can't find anything wrong with that.
Then you haven't seen the new layout. ;)
That article is dated in early 2002. Most developers I know were quite unsure of C# and .NET in general in 2002. The consulting company I work for planned to launch an internal C# project in late 2002. We use internal projects as a training opportunity, so technology is chosen based on what skills would be most beneficial for our consultants to have experience with. Just before the project started, management decided to switch to Java because it was perceived to be a more valuable skill. In the years that have passed since then, .NET has caught up, so today we do about as much .NET work as Java work. But back then, it was still the new kid on the block, and most weren't sure what to think of it.
The video in the linked site, which has been around since at least 2009, is entirely animated. It's a neat idea, but show me a physical device.
"Are you sure" dialogs are generally just an annoyance caused by lazy developers. They'd rather ask for verification (one line of code) than write functionality to allow the user to "undo" what they did if it turns out that they did it incorrectly. Of course, sometimes you're dealing with something that simply can't reasonably be "undone", and that's where there should always be an extra step, whether it's an extra step after the fact, such as a confirmation dialog, or an extra step before the fact, such as the "unlock" button or some other "safety cover" type of concept, as you described. For emergency systems, what you describe makes sense. For systems in general, any sort of extra step to validate intent is the right approach. If developers used confirmation dialogs appropriately (i.e. extremely sparingly), they would be quite effective and not nearly as hated as they are.
My favourite case of unnecessary and outrageously annoying confirmation dialogs: I was working with an internally built application (I didn't build it), and launched a screen that shows a simple listing of records, and allowed me to add/edit/delete these records. I wanted to delete all of the existing records. The only way to delete a record was to right-click on it and select "delete" from the context menu that appeared, which resulted in an "are you sure" dialog. There were about 70 records I needed to delete, and it did not allow multi-select. The context menu did not allow selection of items using the keyboard, so there was no convenient "right-click, D", it had to be "right-click, navigate down to Delete, click, navigate back up to the next record", plus, of course, clicking "Yes" on the confirmation dialog. Then, just to add insult to injury, when I had finally gotten through all of that, I clicked the "OK" button to close the window, which prompted me with "are you sure you want to save the changes to the database?" So, all those deletions weren't even committed to the database yet, despite forcing me to confirm every single one of them. I wanted to beat the developer with a crowbar.
Anyone who does usability studies can assure you that people won't read confirmations, they'll just blindly click OK.
This is true if you're discussing confirmations that come up for frequent actions. However, if your normal action (save) just happens without any confirmation, and your non-normal action (submit— how often do they actually need to use this system?) pops up a confirmation, it tends to catch you off guard and make you take notice that something unexpected is happening. This would be precisely the correct use of a confirmation dialog.