You can't even encrypt the SD card with a self-destructing key? Oh, right, no "x-tries-and-you-die" means no way for the key to self-destruct.
But at least you should be able to encrypt the damned card so removing it from the phone makes it useless.
And yet they encrypt the APPS? The one thing you CAN get from other sources and don't really represent secure data?
My jaw just dropped another inch. I may need surgery to reattach it now. There's room for an albatross to fly in.
Wow, if I was ever offered a choice of phones here at work, I was seriously considering Android. I'm going to have to re-evaluate that if and when the opportunity arises. Those are critical security failures for any phone that contains more than gramma's phone number and pictures of the kids.
True, but it's a matter of how hard it is. Nothing is completely uncrackable, but some nuts are harder to crack than others.
Looking for a smear pattern and tracing it is a lot easier than having 5 tries to unlock an encrypted phone that will instantly wipe the decryption keys on the 6th try. If you want to talk about physically bypassing security and reading memory directly, that's a whole other ball of wax.
Let's take my Blackberry.
1. You could "break" the password, but it's 8-character alphanumeric (minimum), and you get 10 tries. Good luck. So the easy way is unlikely. 2. You could crack it open and read the contents of memory, but they are encrypted with a passcode stored separately in memory. So you'll have to keep digging. 3. You could try to retrieve the encryption keys, but they are themselves encrypted by the passcode, not stored in cleartext on the phone. The passcode which, if you'll recall, is 8 character alpha, so you're going to spend a little time dealing with the number of possible passcodes. Mine has a hard keyboard, not a touchscreen, so you won't get much from the smudges on my screen, I'm afraid. Sorry.
So, while it's POSSIBLE to break the encryption on my phone and get access to the data, it's highly impractical.
I don't have to be absolutely secure. I realize that, given some good soldering skills and a crapload of computing power, someone could get the company memo about needing cover sheets for our TPS reports.
I just need to be more secure than the guy who left his Android on the bar with the word "BOOBS" smeared on the screen, or the guy who left his Apple with only one repeat smudgemark over the number "1".:)
You're right, an ATM with a touchscreen would be an instant ADA fail, since putting braille on a touchscreen would be somewhat difficult.
That aside...
An ATM would be a lot harder to crack, because lots of people use it so the keys are going to be somewhat more randomly-used (since everyone has a different PIN).
The only way of using this would be to put a shim on the ATM to read the magstripe, then some sort of substance on the keypad, and then go back and determine which keys were pressed between each use of the ATM. And, hell, if you're going to go to that much trouble just integrate a pinhole camera into the shim and capture the actual fingers pressing the actual keys along with the magstripe. No fancy guesswork required.
Except some of the mechanical push-button locks have been improved to mitigate this vulnerability.
For example, I've seen them where you can actually repeat the same button up to twice, so "1 - 5 - 2 - 1 - 2 - 5" would be a valid combination, so even though "1, 2, 5" are the only buttons pushed a lot, you have a lot of possible combinations.
They'd probably have used something a little more secure if they were protecting something more valuable than bandaids and gauze. You'd have to steal a whole lot of it to make it worth buying better than a cheap shitty lock. No one is going to put $5,000 into protecting $10 worth of supplies.
But the big difference between a mechanical lock and an electronic one is in the ability to limit the number of attempts (though for all I know really good mechanical keypress locks might have this feature by now).
Let's assume you are presented with an electronic lock and you know the numbers, but not the sequence. The designer of that lock wants to protect what's behind it, so they set a reasonable number of invalid attempts before your password is revoked entirely (meaning that a physical key would be required to reset or open it, or in the case of a cell phone the device wipes itself to protect the data contained on it from reaching the wrong hands).
A 2-digit numeric PIN with only one attempt allowed is 50% secure - you have a 50/50 chance of guessing the correct sequence. It's "1 - 2" or "2 - 1". Do, or do not. There is no "try".
A 3-digit numeric PIN with two attempts is secure two times out of three. You have six possible numbers to try, and two attempts.
A 4-digit numeric PIN with three attempts is even better. You have 24 possible combinations, and three attempts. So you have one chance in eight of guessing correctly. (a 4-digit numeric PIN where only three numbers are used makes things even more fun, because you don't know which one of the numbers has been repeated, and is probably the optimal PIN to use when it might be possible for someone to guess which numbers you used to make up your PIN).
A really good design could potentially detect obvious guessing and chop the number of attempts short. So if your PIN is "1 - 3 - 4 - 3" and you type "1 - 3 - 4 - 4" then "1 - 4 - 4 - 3", that could be a couple of typos and you might get another try or two, where if you type "1 - 1 - 3 - 4" then "1 - 1 - 4 - 3" you obviously are completely guessing and you might as well be cut off right there and then.
So in the case of my Blackberry, I have an 8-character alphanumeric password with ten attempts. After ten attempts, my phone wipes itself clean.
If someone started typing strings having utterly nothing to do with my password (no letters in common and no sequences that might indicate my thumbs are off by a character, for example), that might count as 4 attempts (of course, you don't tell the potential cracker that, you just keep the normal "9 attempts remaining" prompt). If they then do another pattern that has nothing to do with the first AND nothing to do with the real password, it tell them they have "8 attempts" when really the third try is their last. If they haven't proven they know at least part of the password by the third try, then there's not much point giving them the remaining seven, just nuke the sucker and call it a day.
Does the iPhone have a "swipe pattern to unlock" option? If not, then excluding Apple from this isn't FUD.
Any phone that includes a "draw a picture to unlock" option is very susceptible to being unlocked by someone other than the owner, and the Android is one of the models that has this feature.
Any phone that does not is not susceptible to this vulnerability.
If you have a phone that has a "draw picture to unlock" feature, stop using it now. If you don't, this doesn't apply.
Or change the swipe code frequently so the traces that are left are misleading.
But, yeah, a PIN or passcode is a far better security code, making sure it is nice and long and you have at least one or two repeats so the person who took your phone can't even figure out how long the passcode is.
And, of course, if your phone has some sort of limit on the number of tries, that's critical. My Blackberry will wipe itself clean and lose the encryption key for any secure data on my SD chip after ten consecutive unsuccessful password attempts. Someone gets to keep the handset, but that's not a big concern for my company as long as all the data has been thoroughly nuked - plus the handset gets reported as lost/stolen so if someone wants to try and reactivate the phone it might not go terribly well for them.
Yes, it is surprising on the surface that they didn't just put an install question "do you want to be counted as a Linux user?" and turn on package-survey.
But, of course, Canonical is looking for a track of Ubuntu installs, so turning on package-survey would be rather useless for their purposes, unless package-survey keeps track of installs by distro and the Debian community were willing to share their data with Ubuntu.
The guy described eyewitnesses in his forum post. That's enough for the cops to go find those eyewitnesses and get testimony. The guy's own comments, once corroborated by eyewitness testimony, should be enough to make a valid case. Or, in this case, a formal guilty plea.
His post mentions pedestrian eyewitnesses, one of which he almost ran down because the guy tried to slow him down so he could get a plate number. What, pray tell, do you think the investigation might have included? Perhaps a brief stop in the neighborhood looking for some old guys with pencils and paper trying to get plate numbers of speeders? A brief canvas of, say, the area around the corner the guy described nearly running down the old guy?
There would not have been a precedent of conviction based solely on Internet comments anyway. The comments were fair enough reason to investigate, and that's what the police did.
The comments cannot be treated as a sworn statement. However, they can be treated as evidence. The comments, plus corroborating evidence from eyewitnesses, was obviously enough to get Mr. Testosterone-head to 'fess up.
TFA just mentions they "investigated the case", but given that the guy bragged that he played chicken with and nearly ran down a pedestrian who was trying to slow him down enough to get his license plate number, and described where the old man was, I'm sure that old man's testimony came in real handy, or at least one of the people in the area.
They needed to confirm that the crime occurred. Once an eyewitnesses or two described a car identical to the car the guy owned going at the speeds he claimed in a neighborhood he claimed to speed through at about the time he claimed to do it, the cops had corroborating evidence that a traffic violation occurred. Then they can use his statement to demonstrate it was him.
He's also admitted to several other traffic violations on the same post, but it doesn't appear that there's enough information to follow up.
You might want to submit your findings to Wine's AppDB instead ( http://appdb.winehq.org/ ). They keep a pretty good database of what works and what doesn't.
If it's AT&T, they'd take option (b) until they got sick of issuing credits, followed shortly by a system-wide option (c).
"In order to avoid surprise charges, any phone you use on the AT&T network that is capable of sending or receiving SMS messages must include at least our $5 a month 100-message plan. For your convenience and peace of mind, this plan has been added to your monthly bill starting last month, and is a required component of your account and may not be canceled."
Laugh all you want. That's exactly what they did to a lot of smartphones and data plans last year. Why would SMS messages be any different?
Current "Congress" gets renamed to "Progress". They pass new bills.
New group starts up, called "Congress". They remove the worst of the stuff that "Progress" made.
"Congress" would be made up of the runners-up to every "Progressional" seat, so you'd know you had a candidate that had the support of a significantly large minority of the people, but one that represents a different viewpoint from the winner.
Plus, even the runners-up get to set policy, and we're not stuck in this violent swing left and right that the current majority-swap between the two parties in the current Congress causes every 2-4 years.
I don't own an Android, but I'm struggling with what a security app could do about something like this on a phone with a permissions-based architecture. I was under the impression that the Android security model was somewhat similar to the Blackberry one, but feel free to correct me if I'm wrong.
On the Blackberry, when you install software, each software package has "permissions" you can assign to it. Those permissions include things like "Address Book", "Email", "Corporate Network", "Calendar", "Internet", "GPS", "Bluetooth", "Telephony/SMS", and each one can have "Allow", "Deny", and (usually "Ask me").
My default permissions are "ask me" (or "deny" where "ask me" is not available). That way, every time a package starts up, it has to ask if it can access each resource it wants. If the request is reasonable, I check the "remember this" box and click "allow" and the app never bugs me again. If the app fails for lack of permission, I can always go into the app settings and turn specific permissions on for that app. This adds almost zero effort to installing and running applications. I get the occasional pop-up, but when Google Maps wants access to my GPS or the Internet, I figure it's pretty OK, and I never get asked again.
It sucks when something like Google Maps 4 demands "Allow" on every goddamned permission or it refuses to run at all, but a revert back to Google Maps 3 fixed that problem up just fine.
You can be pretty sure I'd notice if a media player asked for access to "Telephony/SMS" I'd be clicking the "FUCK NO" button (aka check "remember this" and click "deny"), followed immediately by a rapid trip to the uninstaller to obliterate it from my phone.
Surely the Android has similar tools, right? And, if it does, what is a security application going to do except watch for after-the-fact attacks from apps with specific signatures?
Seriously, good math, and this is exactly what Canonical is probably trying to figure out using less guesswork and more actual computers calling home and identifying themselves as Ubuntu machines.
Of course, I'd think they would get just as good (or better) numbers from simply asking "how many times was the latest security update loaded from our repository?" That would give them a pretty decent idea of actual consumer install base, since very few people run their own repos.
Canonical could have done a better disclosure job.
It hasn't happened yet, so it's tough to assess whether they "could have done" a better disclosure job until, you know, there is a need for disclosure.
They've put a package in the repos that you have to go out and install (if it's even on all the mirrors yet). If you go and install it yourself, then obviously it's been disclosed to you, and you want to stand up and be counted. If you don't want to be counted (or you are unaware that the package exists), you won't be installing it and you don't need to be informed of anything.
Once they start putting this on OEM installs, or in the default distro, then we can talk about how much disclosure was done, and whether they "should have done" more.
We aren't there yet. I don't know what Canonical intends for a communication before, or even if, they ever decide to make this a default install. Maybe it'll be an option on the installer or a first-run question on OEM installs. Maybe it'll be disabled by default and they'll mention it on the distro home page and ask you to enable it. Or maybe they'll sneak it in and turn it on and they'll then be subject to a valid and reasonable accusation of insufficient disclosure.
But that's all stuff that hasn't happened yet. Let's wait until it does, and keep an eye on Canonical and this package, so we're ready for our nerdragegasm when one is appropriate.
There may be a certain level of expectation of free software from the Linux folks, but it's not absolute. Linux users will hit the repositories first, but that doesn't mean we'll limit ourselves to ONLY the free repositories.
I've happily paid for several pieces of software for Linux, even (gasp!) closed-source ones, because the applications have filled a need I had that didn't have an acceptable solution in the repositories. MoneyDance, for example, runs circles around any of the (quite acceptable, but not good enough for me) money/finance management packages in the repositories. I happily cut the fine folks at that shop my check for $30 every couple of years or so to keep it up and running. TaxAct always gets $20 from me for the "deluxe" package, despite the fact that their Linux compatibility is poor and I have to run them in an XP VirtualBox, AND despite the fact that the free version is actually enough for me, because they do a fine job with my taxes and I want to pay them. If anyone came out with a good Linux-compiled tax package, I'd switch in a heartbeat, and gladly pay them instead.
I think you'll find that, once more commercial packages become available for Linux, the Linux users will become as willing to pay for quality Linux software as the Windows users are willing to pay for Windows software. Assuming, of course, you are writing something that isn't already available in an acceptable form for free.
Conversely, I think you'll find that the open source movement has raised the barriers somewhat on the Windows side. With things like OpenOffice, Gimp, Pidgin, Audacity, VLC, and hordes of other free packages hitting Windows, it's a lot easier to avoid paying money for a solution in Windows, too.
So all the software houses need to work on providing packages that can compete on quality, regardless of platform.
Make a game the best damned game out there, and people will pay to play, as long as you allow them to.
Certain games work better under WINE than they do in Windows, though few of them are current-market games.
I'm mostly referring to older adventure-type games that used things like Quicktime. My wife has an old favorite (Amber: Journeys Beyond) that we lost access to when we went to Windows XP, but I discovered recently that it is very well supported in Wine, and my wife was thrilled to have an old favorite back. We have a catalog of older games, many of which don't work in XP that I need to try out (Obsidian, Sanitarium, and a few other Myst-like games including the entire Myst series).
There could actually be a market for some of these older games in Linux where none can possibly exist in Windows without costly redevelopment of the game. The software houses could sell them in their original form (no redevelopment costs, only pressing the discs) with a one-page installation FAQ and milk a little more cash out of them with almost no effort.
Then that's as it should be. Game developers should develop for a profit, not to make everyone on every platform happy. If the numbers are, in fact, too low to justify a Linux port of a game, then they are too low. But at least the decision will be made by people who understand the numbers behind their decision.
On the other hand, game developers would have a semi-solid set of numbers to go by, so they can assess the size of their potential market. As it is, there really aren't good numbers on Linux adoption, because no one has to buy a license, everyone can freely copy it from each other, and people collect distro discs that never get used.
If you want gaming on Linux, download this app, join some of the "Linux users lists", and let the game companies know you are out there and willing to shell out some money for Linux games. If they see a market, they'll serve it. But they have to see the market first.
I have to say, maybe the Matrix is smaller than the Prius, but comparing the two as people and cargo carriers leads to a solution of "no contest".
I test-drove the Prius back in 2002 when I bought my Jetta Diesel, and my wife currently owns a Pontiac Vibe (Toyota Matrix with a badge change). The new Prius models look a tad roomier, but they don't look nearly as roomy as even my Jetta is today, 8 years later.
The Vibe is the only car in that weight/price I've ever seen that can handle three child seats across the back seat row without complaints about crowding, or carry 5 real-sized adults without problems. The roof continues straight back, so even my 6' 4" body can sit in the back seat of the Vibe for hours with no complaints.
The Prius and the Matrix might both be built on the Corolla frame, but don't discount the amount of space and weight the hybrid engine system and the shorter roofline uses up in terms of useful car space and capacity.
Sure, it only gets about 35MPG, but we got it brand new for $16,000. So the price differential is even bigger when you discover that you can't work out a deal on a Prius (sometimes you have to pay extra to get one), so you have to use its sticker price as a real-life price, but you can usually get a discount on just about anything else.
If you want to compare money saved on fuel versus the price differential, it's probably better to not compare the Prius against a Toyota model at all, but to pick a similarly-sized small sedan or an average of a few in its size/room class, and not artificially limit the comparison to Toyota models. Then take the real-world average price of the other car and compare it to the average real-world price of the Prius.
Unless gasoline gets very expensive, that comparison is going to get pretty ugly.
Of course, if your main goal is to save fuel at all dollar costs, these studies are meaningless - pick the hybrid, small gasser, or Diesel that is the smallest and most efficient that meets your needs, and go for it.
Slashdot Mirror
You can't even encrypt the SD card with a self-destructing key? Oh, right, no "x-tries-and-you-die" means no way for the key to self-destruct.
But at least you should be able to encrypt the damned card so removing it from the phone makes it useless.
And yet they encrypt the APPS? The one thing you CAN get from other sources and don't really represent secure data?
My jaw just dropped another inch. I may need surgery to reattach it now. There's room for an albatross to fly in.
Wow, if I was ever offered a choice of phones here at work, I was seriously considering Android. I'm going to have to re-evaluate that if and when the opportunity arises. Those are critical security failures for any phone that contains more than gramma's phone number and pictures of the kids.
True, but it's a matter of how hard it is. Nothing is completely uncrackable, but some nuts are harder to crack than others.
Looking for a smear pattern and tracing it is a lot easier than having 5 tries to unlock an encrypted phone that will instantly wipe the decryption keys on the 6th try. If you want to talk about physically bypassing security and reading memory directly, that's a whole other ball of wax.
Let's take my Blackberry.
1. You could "break" the password, but it's 8-character alphanumeric (minimum), and you get 10 tries. Good luck. So the easy way is unlikely.
2. You could crack it open and read the contents of memory, but they are encrypted with a passcode stored separately in memory. So you'll have to keep digging.
3. You could try to retrieve the encryption keys, but they are themselves encrypted by the passcode, not stored in cleartext on the phone. The passcode which, if you'll recall, is 8 character alpha, so you're going to spend a little time dealing with the number of possible passcodes. Mine has a hard keyboard, not a touchscreen, so you won't get much from the smudges on my screen, I'm afraid. Sorry.
So, while it's POSSIBLE to break the encryption on my phone and get access to the data, it's highly impractical.
I don't have to be absolutely secure. I realize that, given some good soldering skills and a crapload of computing power, someone could get the company memo about needing cover sheets for our TPS reports.
I just need to be more secure than the guy who left his Android on the bar with the word "BOOBS" smeared on the screen, or the guy who left his Apple with only one repeat smudgemark over the number "1". :)
You're right, an ATM with a touchscreen would be an instant ADA fail, since putting braille on a touchscreen would be somewhat difficult.
That aside...
An ATM would be a lot harder to crack, because lots of people use it so the keys are going to be somewhat more randomly-used (since everyone has a different PIN).
The only way of using this would be to put a shim on the ATM to read the magstripe, then some sort of substance on the keypad, and then go back and determine which keys were pressed between each use of the ATM. And, hell, if you're going to go to that much trouble just integrate a pinhole camera into the shim and capture the actual fingers pressing the actual keys along with the magstripe. No fancy guesswork required.
I just wish Android would have the ability to wipe itself after x amount of failed attempts.
The Android lacks this? Really? Seriously?
Wow.
Just... wow.
Better yet, just urinate on it. No one wants a broken phone that smells of urine.
Except some of the mechanical push-button locks have been improved to mitigate this vulnerability.
For example, I've seen them where you can actually repeat the same button up to twice, so "1 - 5 - 2 - 1 - 2 - 5" would be a valid combination, so even though "1, 2, 5" are the only buttons pushed a lot, you have a lot of possible combinations.
They'd probably have used something a little more secure if they were protecting something more valuable than bandaids and gauze. You'd have to steal a whole lot of it to make it worth buying better than a cheap shitty lock. No one is going to put $5,000 into protecting $10 worth of supplies.
But the big difference between a mechanical lock and an electronic one is in the ability to limit the number of attempts (though for all I know really good mechanical keypress locks might have this feature by now).
Let's assume you are presented with an electronic lock and you know the numbers, but not the sequence. The designer of that lock wants to protect what's behind it, so they set a reasonable number of invalid attempts before your password is revoked entirely (meaning that a physical key would be required to reset or open it, or in the case of a cell phone the device wipes itself to protect the data contained on it from reaching the wrong hands).
A 2-digit numeric PIN with only one attempt allowed is 50% secure - you have a 50/50 chance of guessing the correct sequence. It's "1 - 2" or "2 - 1". Do, or do not. There is no "try".
A 3-digit numeric PIN with two attempts is secure two times out of three. You have six possible numbers to try, and two attempts.
A 4-digit numeric PIN with three attempts is even better. You have 24 possible combinations, and three attempts. So you have one chance in eight of guessing correctly. (a 4-digit numeric PIN where only three numbers are used makes things even more fun, because you don't know which one of the numbers has been repeated, and is probably the optimal PIN to use when it might be possible for someone to guess which numbers you used to make up your PIN).
A really good design could potentially detect obvious guessing and chop the number of attempts short. So if your PIN is "1 - 3 - 4 - 3" and you type "1 - 3 - 4 - 4" then "1 - 4 - 4 - 3", that could be a couple of typos and you might get another try or two, where if you type "1 - 1 - 3 - 4" then "1 - 1 - 4 - 3" you obviously are completely guessing and you might as well be cut off right there and then.
So in the case of my Blackberry, I have an 8-character alphanumeric password with ten attempts. After ten attempts, my phone wipes itself clean.
If someone started typing strings having utterly nothing to do with my password (no letters in common and no sequences that might indicate my thumbs are off by a character, for example), that might count as 4 attempts (of course, you don't tell the potential cracker that, you just keep the normal "9 attempts remaining" prompt). If they then do another pattern that has nothing to do with the first AND nothing to do with the real password, it tell them they have "8 attempts" when really the third try is their last. If they haven't proven they know at least part of the password by the third try, then there's not much point giving them the remaining seven, just nuke the sucker and call it a day.
Does the iPhone have a "swipe pattern to unlock" option? If not, then excluding Apple from this isn't FUD.
Any phone that includes a "draw a picture to unlock" option is very susceptible to being unlocked by someone other than the owner, and the Android is one of the models that has this feature.
Any phone that does not is not susceptible to this vulnerability.
If you have a phone that has a "draw picture to unlock" feature, stop using it now. If you don't, this doesn't apply.
I guess then you just replace the protector
Or change the swipe code frequently so the traces that are left are misleading.
But, yeah, a PIN or passcode is a far better security code, making sure it is nice and long and you have at least one or two repeats so the person who took your phone can't even figure out how long the passcode is.
And, of course, if your phone has some sort of limit on the number of tries, that's critical. My Blackberry will wipe itself clean and lose the encryption key for any secure data on my SD chip after ten consecutive unsuccessful password attempts. Someone gets to keep the handset, but that's not a big concern for my company as long as all the data has been thoroughly nuked - plus the handset gets reported as lost/stolen so if someone wants to try and reactivate the phone it might not go terribly well for them.
I didn't name my cat "12345", you insensitive clod!
Yes, it is surprising on the surface that they didn't just put an install question "do you want to be counted as a Linux user?" and turn on package-survey.
But, of course, Canonical is looking for a track of Ubuntu installs, so turning on package-survey would be rather useless for their purposes, unless package-survey keeps track of installs by distro and the Debian community were willing to share their data with Ubuntu.
For things of this sort, I don't think police would normally pursue it even IRL unless there were more evidence (like the photos/video in this case)
http://forums.5series.net/topic/95495-going-140-kmh-on-a-40-zone
The guy described eyewitnesses in his forum post. That's enough for the cops to go find those eyewitnesses and get testimony. The guy's own comments, once corroborated by eyewitness testimony, should be enough to make a valid case. Or, in this case, a formal guilty plea.
His post mentions pedestrian eyewitnesses, one of which he almost ran down because the guy tried to slow him down so he could get a plate number. What, pray tell, do you think the investigation might have included? Perhaps a brief stop in the neighborhood looking for some old guys with pencils and paper trying to get plate numbers of speeders? A brief canvas of, say, the area around the corner the guy described nearly running down the old guy?
http://forums.5series.net/topic/95495-going-140-kmh-on-a-40-zone
There would not have been a precedent of conviction based solely on Internet comments anyway. The comments were fair enough reason to investigate, and that's what the police did.
The comments cannot be treated as a sworn statement. However, they can be treated as evidence. The comments, plus corroborating evidence from eyewitnesses, was obviously enough to get Mr. Testosterone-head to 'fess up.
TFA just mentions they "investigated the case", but given that the guy bragged that he played chicken with and nearly ran down a pedestrian who was trying to slow him down enough to get his license plate number, and described where the old man was, I'm sure that old man's testimony came in real handy, or at least one of the people in the area.
They needed to confirm that the crime occurred. Once an eyewitnesses or two described a car identical to the car the guy owned going at the speeds he claimed in a neighborhood he claimed to speed through at about the time he claimed to do it, the cops had corroborating evidence that a traffic violation occurred. Then they can use his statement to demonstrate it was him.
He's also admitted to several other traffic violations on the same post, but it doesn't appear that there's enough information to follow up.
Original post: http://forums.5series.net/topic/95495-going-140-kmh-on-a-40-zone
Then he pled guilty at trial.
[SLAM!] Case closed. Cops:1, Asshole:$1000 and 6 months.
He got off lightly - playing chicken with a pedestrian could have been a far more serious charge.
You might want to submit your findings to Wine's AppDB instead ( http://appdb.winehq.org/ ). They keep a pretty good database of what works and what doesn't.
If it's AT&T, they'd take option (b) until they got sick of issuing credits, followed shortly by a system-wide option (c).
"In order to avoid surprise charges, any phone you use on the AT&T network that is capable of sending or receiving SMS messages must include at least our $5 a month 100-message plan. For your convenience and peace of mind, this plan has been added to your monthly bill starting last month, and is a required component of your account and may not be canceled."
Laugh all you want. That's exactly what they did to a lot of smartphones and data plans last year. Why would SMS messages be any different?
I'm OK with a name swap.
Current "Congress" gets renamed to "Progress". They pass new bills.
New group starts up, called "Congress". They remove the worst of the stuff that "Progress" made.
"Congress" would be made up of the runners-up to every "Progressional" seat, so you'd know you had a candidate that had the support of a significantly large minority of the people, but one that represents a different viewpoint from the winner.
Plus, even the runners-up get to set policy, and we're not stuck in this violent swing left and right that the current majority-swap between the two parties in the current Congress causes every 2-4 years.
I don't own an Android, but I'm struggling with what a security app could do about something like this on a phone with a permissions-based architecture. I was under the impression that the Android security model was somewhat similar to the Blackberry one, but feel free to correct me if I'm wrong.
On the Blackberry, when you install software, each software package has "permissions" you can assign to it. Those permissions include things like "Address Book", "Email", "Corporate Network", "Calendar", "Internet", "GPS", "Bluetooth", "Telephony/SMS", and each one can have "Allow", "Deny", and (usually "Ask me").
My default permissions are "ask me" (or "deny" where "ask me" is not available). That way, every time a package starts up, it has to ask if it can access each resource it wants. If the request is reasonable, I check the "remember this" box and click "allow" and the app never bugs me again. If the app fails for lack of permission, I can always go into the app settings and turn specific permissions on for that app. This adds almost zero effort to installing and running applications. I get the occasional pop-up, but when Google Maps wants access to my GPS or the Internet, I figure it's pretty OK, and I never get asked again.
It sucks when something like Google Maps 4 demands "Allow" on every goddamned permission or it refuses to run at all, but a revert back to Google Maps 3 fixed that problem up just fine.
You can be pretty sure I'd notice if a media player asked for access to "Telephony/SMS" I'd be clicking the "FUCK NO" button (aka check "remember this" and click "deny"), followed immediately by a rapid trip to the uninstaller to obliterate it from my phone.
Surely the Android has similar tools, right? And, if it does, what is a security application going to do except watch for after-the-fact attacks from apps with specific signatures?
+5 ROTFLMAO! Well done!
Steve was actually figuring we'd all want to be like Al, struggling with imperfect implementations of high technology! He's a GENIUS!
Now we just need to have the iPhone4 make the little ticky-chirpy sounds when hit.
What we need is a body of the Legislature whose sole job is to eliminate obsolete, obscure, and unclear laws.
Since their job would be the opposite of that of Congress, I suggest a name that is equally opposite.
"Pro" is the opposite of "Con".
Therefore, I suggest we call the new body "Progress".
Some say,
All we know is, he's called "The Stig".
Seriously, good math, and this is exactly what Canonical is probably trying to figure out using less guesswork and more actual computers calling home and identifying themselves as Ubuntu machines.
Of course, I'd think they would get just as good (or better) numbers from simply asking "how many times was the latest security update loaded from our repository?" That would give them a pretty decent idea of actual consumer install base, since very few people run their own repos.
Canonical could have done a better disclosure job.
It hasn't happened yet, so it's tough to assess whether they "could have done" a better disclosure job until, you know, there is a need for disclosure.
They've put a package in the repos that you have to go out and install (if it's even on all the mirrors yet). If you go and install it yourself, then obviously it's been disclosed to you, and you want to stand up and be counted. If you don't want to be counted (or you are unaware that the package exists), you won't be installing it and you don't need to be informed of anything.
Once they start putting this on OEM installs, or in the default distro, then we can talk about how much disclosure was done, and whether they "should have done" more.
We aren't there yet. I don't know what Canonical intends for a communication before, or even if, they ever decide to make this a default install. Maybe it'll be an option on the installer or a first-run question on OEM installs. Maybe it'll be disabled by default and they'll mention it on the distro home page and ask you to enable it. Or maybe they'll sneak it in and turn it on and they'll then be subject to a valid and reasonable accusation of insufficient disclosure.
But that's all stuff that hasn't happened yet. Let's wait until it does, and keep an eye on Canonical and this package, so we're ready for our nerdragegasm when one is appropriate.
There may be a certain level of expectation of free software from the Linux folks, but it's not absolute. Linux users will hit the repositories first, but that doesn't mean we'll limit ourselves to ONLY the free repositories.
I've happily paid for several pieces of software for Linux, even (gasp!) closed-source ones, because the applications have filled a need I had that didn't have an acceptable solution in the repositories. MoneyDance, for example, runs circles around any of the (quite acceptable, but not good enough for me) money/finance management packages in the repositories. I happily cut the fine folks at that shop my check for $30 every couple of years or so to keep it up and running. TaxAct always gets $20 from me for the "deluxe" package, despite the fact that their Linux compatibility is poor and I have to run them in an XP VirtualBox, AND despite the fact that the free version is actually enough for me, because they do a fine job with my taxes and I want to pay them. If anyone came out with a good Linux-compiled tax package, I'd switch in a heartbeat, and gladly pay them instead.
I think you'll find that, once more commercial packages become available for Linux, the Linux users will become as willing to pay for quality Linux software as the Windows users are willing to pay for Windows software. Assuming, of course, you are writing something that isn't already available in an acceptable form for free.
Conversely, I think you'll find that the open source movement has raised the barriers somewhat on the Windows side. With things like OpenOffice, Gimp, Pidgin, Audacity, VLC, and hordes of other free packages hitting Windows, it's a lot easier to avoid paying money for a solution in Windows, too.
So all the software houses need to work on providing packages that can compete on quality, regardless of platform.
Make a game the best damned game out there, and people will pay to play, as long as you allow them to.
Certain games work better under WINE than they do in Windows, though few of them are current-market games.
I'm mostly referring to older adventure-type games that used things like Quicktime. My wife has an old favorite (Amber: Journeys Beyond) that we lost access to when we went to Windows XP, but I discovered recently that it is very well supported in Wine, and my wife was thrilled to have an old favorite back. We have a catalog of older games, many of which don't work in XP that I need to try out (Obsidian, Sanitarium, and a few other Myst-like games including the entire Myst series).
There could actually be a market for some of these older games in Linux where none can possibly exist in Windows without costly redevelopment of the game. The software houses could sell them in their original form (no redevelopment costs, only pressing the discs) with a one-page installation FAQ and milk a little more cash out of them with almost no effort.
Then that's as it should be. Game developers should develop for a profit, not to make everyone on every platform happy. If the numbers are, in fact, too low to justify a Linux port of a game, then they are too low. But at least the decision will be made by people who understand the numbers behind their decision.
On the other hand, game developers would have a semi-solid set of numbers to go by, so they can assess the size of their potential market. As it is, there really aren't good numbers on Linux adoption, because no one has to buy a license, everyone can freely copy it from each other, and people collect distro discs that never get used.
If you want gaming on Linux, download this app, join some of the "Linux users lists", and let the game companies know you are out there and willing to shell out some money for Linux games. If they see a market, they'll serve it. But they have to see the market first.
I have to say, maybe the Matrix is smaller than the Prius, but comparing the two as people and cargo carriers leads to a solution of "no contest".
I test-drove the Prius back in 2002 when I bought my Jetta Diesel, and my wife currently owns a Pontiac Vibe (Toyota Matrix with a badge change). The new Prius models look a tad roomier, but they don't look nearly as roomy as even my Jetta is today, 8 years later.
The Vibe is the only car in that weight/price I've ever seen that can handle three child seats across the back seat row without complaints about crowding, or carry 5 real-sized adults without problems. The roof continues straight back, so even my 6' 4" body can sit in the back seat of the Vibe for hours with no complaints.
The Prius and the Matrix might both be built on the Corolla frame, but don't discount the amount of space and weight the hybrid engine system and the shorter roofline uses up in terms of useful car space and capacity.
Sure, it only gets about 35MPG, but we got it brand new for $16,000. So the price differential is even bigger when you discover that you can't work out a deal on a Prius (sometimes you have to pay extra to get one), so you have to use its sticker price as a real-life price, but you can usually get a discount on just about anything else.
If you want to compare money saved on fuel versus the price differential, it's probably better to not compare the Prius against a Toyota model at all, but to pick a similarly-sized small sedan or an average of a few in its size/room class, and not artificially limit the comparison to Toyota models. Then take the real-world average price of the other car and compare it to the average real-world price of the Prius.
Unless gasoline gets very expensive, that comparison is going to get pretty ugly.
Of course, if your main goal is to save fuel at all dollar costs, these studies are meaningless - pick the hybrid, small gasser, or Diesel that is the smallest and most efficient that meets your needs, and go for it.