What of those who are contractually bound to carriers that don't offer unlimited data? You completely missed that part of my post, apparently. For anyone acquiring service today who needs their phone to work while traveling, the majority of carriers do not offer unlimited data (grandfathered unlimited plans mean fuck-all to someone who is new to the service) and, of the two major players in the US who do offer unlimited, one is dropping the option soon and the other doesn't work for a lot of people (e.g. they simply don't have coverage). I'm lucky in that T-Mobile covers my area fairly well. That does not apply to everyone.
That is literally the dumbest thing I have read today.
And yet, you found it worthwhile enough to respond to.
Yes, your mobile phone usage is a random number selected from a hat each month by your wireless company and arbitrarily inserted into your bill for kicks, with no involvement from you.
Maybe read the rest of the sentence and realize that's not what I'm saying at all? Oh, look, you quoted the appropriate context even, so you clearly did read it.
I'm not sure who your phone company is, but most wireless networks I know of assign dynamic non-routable IP addresses behind carrier grade NAT to their customers' mobile devices. So, you know, good luck with your DDoS there.
Not only did you quote it, you replied to it as though you actually understood what I was saying; so, why did you still post the obvious misinterpretation of my words? Poorly constructed strawman, much? I do have to say, though, that you are absolutely correct about this, most carriers to use carrier grade NAT on their tethering APNs. Where you are mistaken is with regard to their mobile data APNs. I've run public servers from my phone on both AT&T and T-Mobile; you can't do that behind NAT unless you set up forwarding rules, which you can only do if you have access to the NAT configuration, not an option with most carriers. In short, yes, most phones actually have publicly routable IP addresses.
Yes, wireless companies are just dying to have people flood their networks with junk packets so they have an excuse to overbill people. They certainly don't do anything already to prevent just that kind of thing.
You haven't been paying much attention lately. First of all, the contracts are worded such that they allow billing for any and all received data, requested or otherwise, so there would be no overbilling as per the agreed-upon terms. Second, doing something to prevent it costs the carrier money, while letting it happen (as the contract has their asses covered) makes them money. Which do you think the shareholders would opt for? There hasn't been a class action yet because the attack that opens everyone's eyes to the vulnerabilities that exist (within these contracts) hasn't happened yet. Just wait and see.
You uncovered the conspiracy!
Technically, yes. Shareholders want profits, spending money to prevent the attacks these networks are vulnerable to reduces profits, especially when the networks are not currently being exploited, so the shareholders and carriers are conspiring to leave the networks vulnerable for now. I hadn't really looked at it that way before. In reality, it's just the classic "there is no security problem until it gets exploited" mindset most businesses have adopted, but I guess there is a technical conspiracy angle to it, as well.
You should probably just go out and spend the money right now that you are planning to win from your class action lawsuit.
You appear to lack reading comprehension skills. Having unlimited data, I wouldn't be a class member.
I hear tinfoil hats are on sale,
Maybe you should switch, you seem to be exhibiting signs of aluminum poisoning.
but you may not wish to prop up the widely known corrupt practices of Big Tinfoil.
While this is an obvious troll, I'll bite. Big Tinfoil doesn't shill like the carriers. Clearly, you're more comfortable attacking them than the industry that pays you to spread misinformation.
You're right, i shouldnt be mad about something I have complete control over. Like, you know, the number and power rewuirements of devices I allow to be connected to my home's electrical wiring and when those devices are allowed access to power. An that's why I dont bitch about my electric company having implemented metered billing; in short, I am in full control of my usage, right up to the point of an equipment failure on my end, which is clearly my responsibility. To further my point, utility meters are regulated while there is no regulation or legally required metering mehodology for data, which only compounds the fact that someone else can just start firing unrequested packets in my direction and I'll get billed for them.
Well, I won't because I have unlimited data, but many dont even have it as an option from the carrier they're contractually bound to. For them, having a variable cost they literally have no control over (even if they dont request more data than their plan allows, nothing stops it from being sent - thimk DDoS) is a huge issue worth complaining about. And no, it is not negated by the fact that they agreed to it; as you have clearly demonstrated, not everyone realizes they won't be in control of the data they are paying for.
I'm just waiting for the first (desktop and/or server) malware that sends a steady stream of packets to random AT&T and Verizon mobile IPs. Think class-action, because you KNOW neither providers will block that traffic when they could bill for it instead.
Does the Nexus 6 I've had practically since it was released count? It's had hardware encryption since support for the 805's coprocessor was added in 5.1.
Aldi is supportive of unions, their cashiers are union and very well paid, and all employees have access to benefits (and they did pre-Obamacare, as well). I don't know about the rest of their staff but my understanding is that everyone working there must be trained as a cashier, which I imagine would make them all cashiers as far as payroll is concerned (that is to say they're not going to get a promotion and a pay cut).
If I can get cheaper prices and the compromise is that I'm getting off brands and there isn't a million dollars of marketing being thrown in my face every time I enter the store, but the workers are paid well and treated fairly, I think I can live with that, thank you. Sadly, there aren't any Aldi stores where I currently live.
You do have a point with this. With verified boot, you'll have to compile with the same compiler, compiler version, and compiler flags, which will wield identical binaries and the signature will remain valid after you replace the binaries with your self-compiled versions. After all of that, you've accomplished nothing, but hey, at least you know the binaries belong to the code, right?
In case anyone is confused about my position on open source: Yes, it has benefits in that you can review the code if you care to do so, and you can compile from source if so inclined. However, it has drawbacks in the form of the circlejerk that is the open source community at large. "Oh, it's open source? It's automatically better." No, sorry, it's not, remove your hand from the penis of the man to your right and remove your penis from the hand of the man to your left and realize that there are many facets to good software. Honestly, most open source projects lack most of the qualities of good software, namely usability and stability, and that's ignoring the security aspect; most projects follow a development pattern along the lines of "we're a small team of nerds who need a specific tool that works a specific way, we know what we need and how it should work so we don't need documentation, any automation we can bring to this task is an improvement over the current state of things so we don't care if it's stable; it'll be modeled after our current process which probably won't make sense to most people but it'll be usable for us and that's what matters. Oh, and being an internal tool used by this small group of trusted individuals, it will be secure by default... in our environment, at least". Does a project like that work? Perhaps, if you're a member of the development team and actually don't need documentation, if you're familiar with the workflow the program was written to follow and that workflow makes sense for your use case, if you're willing to accept software that crashes if you don't feed it exactly the input it expects, and especially if you don't care about security. Or if you have time to review the source and fix these issues.
But really, software is a tool. Find the tool that works for you, the one that does the best job with the least effort, and if security is a concern (and it should be), you should already be using a layered approach that negates the absolute need to review the source code and compile your own binaries (not that anyone honestly does this anyway). Is it nice to be able to do that? Sure, but if you think it is necessary, you are taking the wrong approach to security.
So yes, I use (and support) open source where open source actually works, and I pay for software where open source does not. I pay for a lot of software. Android works better for me than iOS on my phone (which I use differently than a tablet), but iOS works better for me on a tablet; for some reason this blows peoples' minds, but that's the reality of the current market, for me. Oh, and I quite enjoy stirring the pot with regard to choice of platform, especially given that I use all of the major platforms at least once in the course of any given workday.
Welcome to English. I can't even argue with you at this point; anyone who calls English a language is lying to themselves; it's a set of languages, all loosely related by a general set of rules, but with their own specifics. Some would say those are simply different dialects of the language, but the fact is we've got "Queen's" English, "American" English, "Queens" English (note the missing apostrophe, I'm referring to the Brooklyn accent here), and now the Millenials have their own made-up rules and I'm, like, not sure, you know, like, what to like, call it or whatever. (Yes, that was an example of that "dialect")
You could almost compare it to Perl, but at least you can run Perl code through a debugger to make sense of what it's trying to do most of the time.
Comments like that are akin to saying female lions can't hunt because the male lions are bigger and stronger.
Well, sure, if you ignore half of what was said. It's more akin to saying the average female and well-below-average male lion can't hunt because they're not big and strong enough, while the above average female lion and average male lion can because they are. I know that's too many words for a simple mind like yours, so I understand why you oversimplify the way you do.
Females also tend to have an advantage in situational awareness
Tell that to my wife. Now tell her again. One more time. Nope, she's still not aware you're talking to her. Try calling her name first to get her attention. Okay, now tell her. Nope, she still didn't hear you, try again.
If you're counting node licenses you're doing it wrong. If you're at the point of needing performance beyond what FOSS can provide, you're at the point where hiring a team to build a solution tailored to your data will cost less in the long-term than buying a solution that was built for someone else's. You'll get better performance that way, as well.
But if you'd rather pay perpetual licensing to third parties for the rest of your natural life (as implied at the end of your post), you're right, I guess having a large amount of local storage doesn't make sense.
And yes, I do realize I didn't answer any of the questions implied by your comment. Just because you don't have a use case (and nether do I or I'd tell you what that use case is) does not mean one does not exist; clearly Samsung sees a use case for this or they'd not have spent the money to develop it.
Keep in mind that a 12G SAS connection is as good as a 24G SATA Connection since it's bidirectional unlike SATA that's unidirectional
You're assuming an equal flow of read/write traffic and control commands in both directions. If you've got a workload that involves a lot of writes followed by a lot of reads, rather than an interleave of reads and writes, SATA will win.
I'm sure, for your common workload, you are correct, but please try to avoid such sweeping generalizations as they really make you look like you have no idea what you're talking about.
The million IOPS isn't for getting data off the host, it's for data crunching done on the host; often times a host only sends out a fraction of what it reads from disk. In most cases, simple gigE or 10gigE will be sufficient to get data off of such a system, but more IOPS will mean the data gets processed faster and is ready to be retrieved sooner. For datasets under a couple hundred GB, there's still nothing that beats a RAMdisk, but for larger sets this is where it's at.
Here's a solution for virtualized environments (e.g. the cloud):
Think LVM + software RAID + PCIe disk + SAS. When attaching an volume from a SAS array, first allocate a matching partition on the PCIe SSD, then build a RAID 1 with the SAS volume and the local partition. It's on you to figure out how to prioritize the local disk over the SAS for IO, so all reads come from the SSD and all writes hit the SSD first for consistency, but there you go. The caveat is that, once the SAS volume is used in the software RAID, it can only be used as a member of a RAID array going forward, so taking an instance offline and spinning it back up from the same volume will require rebuilding the RAID. There are issues as well with using two different "disks" for the RAID array, but those are mitigated by prioritizing the local disk; the SAS volume can be used during the rebuild, so the instance can still boot and be used (albeit with degraded performance) while the RAID rebuilds.
This is just my 2-minute-engineering solution to the problem. I wouldn't be surprised if a better solution already exists for this; in fact I'm 99% certain one does. I don't live in a datacenter, though, so I'm not aware of one.
It's different in that what the warranty oh so graciously offers to cover is often vastly different from what the product is claimed to be capable of in advertising. My understanding is that SoGA entitles you to a full refund if the item does not live up to its advertising and not just the portion the manufacturer states in the warranty. Additionally, as explained by the poster before me, the ability to take the product back to the store rather than having to deal with the manufacturer, regardless of the store's return policy.
Ahh, fun stuff. I had this happen with a gen 4 classic and a gen 1 nano. On the classic it was the result of an interrupted sync (accidentally yanked the cable), on the nano it was a case of manual sync getting confused. It was fixed on the classic by telling it to shut down, then turning it back on; the gray songs (which hadn't succesfully synched) were gone and plugging it back in caused it to sync successfully. I had to reset the nano, though, and sync it from a fresh (empty) state. Apparently, the iPod will report manually synched tracks as being present if there is a database entry on the device, even if the file is missing or damaged. Because the device says the file is there, iTunes doesnt sync it; and because the file actually isn't there, the device obviously can't play it.
If restarting and resetting don't work (or if you're talking about gray tracks in iTunes rather than on the iPod itself), drop me a line via email so we don't end up spamming/. with details about your buddy's iPod.
Thank you for making this point more concisely than I've done in the past. I never actually looked as far back as the iPhone 4, so I'll remember that data point for future reference.
Well if it's my bank account you're after, you'd be better off cutting off one of my kid's fingers every hour until I hand over the account numbers and/or contents rendering my phone's encryption irrelevant either way. However, if you're a nonviolent offender, by far the most common class of criminal, that encryption certainly stops you dead in your tracks.
Slashdot Mirror
What of those who are contractually bound to carriers that don't offer unlimited data? You completely missed that part of my post, apparently. For anyone acquiring service today who needs their phone to work while traveling, the majority of carriers do not offer unlimited data (grandfathered unlimited plans mean fuck-all to someone who is new to the service) and, of the two major players in the US who do offer unlimited, one is dropping the option soon and the other doesn't work for a lot of people (e.g. they simply don't have coverage). I'm lucky in that T-Mobile covers my area fairly well. That does not apply to everyone.
That is literally the dumbest thing I have read today.
And yet, you found it worthwhile enough to respond to.
Yes, your mobile phone usage is a random number selected from a hat each month by your wireless company and arbitrarily inserted into your bill for kicks, with no involvement from you.
Maybe read the rest of the sentence and realize that's not what I'm saying at all? Oh, look, you quoted the appropriate context even, so you clearly did read it.
I'm not sure who your phone company is, but most wireless networks I know of assign dynamic non-routable IP addresses behind carrier grade NAT to their customers' mobile devices. So, you know, good luck with your DDoS there.
Not only did you quote it, you replied to it as though you actually understood what I was saying; so, why did you still post the obvious misinterpretation of my words? Poorly constructed strawman, much? I do have to say, though, that you are absolutely correct about this, most carriers to use carrier grade NAT on their tethering APNs. Where you are mistaken is with regard to their mobile data APNs. I've run public servers from my phone on both AT&T and T-Mobile; you can't do that behind NAT unless you set up forwarding rules, which you can only do if you have access to the NAT configuration, not an option with most carriers. In short, yes, most phones actually have publicly routable IP addresses.
Yes, wireless companies are just dying to have people flood their networks with junk packets so they have an excuse to overbill people. They certainly don't do anything already to prevent just that kind of thing.
You haven't been paying much attention lately. First of all, the contracts are worded such that they allow billing for any and all received data, requested or otherwise, so there would be no overbilling as per the agreed-upon terms. Second, doing something to prevent it costs the carrier money, while letting it happen (as the contract has their asses covered) makes them money. Which do you think the shareholders would opt for? There hasn't been a class action yet because the attack that opens everyone's eyes to the vulnerabilities that exist (within these contracts) hasn't happened yet. Just wait and see.
You uncovered the conspiracy!
Technically, yes. Shareholders want profits, spending money to prevent the attacks these networks are vulnerable to reduces profits, especially when the networks are not currently being exploited, so the shareholders and carriers are conspiring to leave the networks vulnerable for now. I hadn't really looked at it that way before. In reality, it's just the classic "there is no security problem until it gets exploited" mindset most businesses have adopted, but I guess there is a technical conspiracy angle to it, as well.
You should probably just go out and spend the money right now that you are planning to win from your class action lawsuit.
You appear to lack reading comprehension skills. Having unlimited data, I wouldn't be a class member.
I hear tinfoil hats are on sale,
Maybe you should switch, you seem to be exhibiting signs of aluminum poisoning.
but you may not wish to prop up the widely known corrupt practices of Big Tinfoil.
While this is an obvious troll, I'll bite. Big Tinfoil doesn't shill like the carriers. Clearly, you're more comfortable attacking them than the industry that pays you to spread misinformation.
You're right, i shouldnt be mad about something I have complete control over. Like, you know, the number and power rewuirements of devices I allow to be connected to my home's electrical wiring and when those devices are allowed access to power. An that's why I dont bitch about my electric company having implemented metered billing; in short, I am in full control of my usage, right up to the point of an equipment failure on my end, which is clearly my responsibility. To further my point, utility meters are regulated while there is no regulation or legally required metering mehodology for data, which only compounds the fact that someone else can just start firing unrequested packets in my direction and I'll get billed for them.
Well, I won't because I have unlimited data, but many dont even have it as an option from the carrier they're contractually bound to. For them, having a variable cost they literally have no control over (even if they dont request more data than their plan allows, nothing stops it from being sent - thimk DDoS) is a huge issue worth complaining about. And no, it is not negated by the fact that they agreed to it; as you have clearly demonstrated, not everyone realizes they won't be in control of the data they are paying for.
I'm just waiting for the first (desktop and/or server) malware that sends a steady stream of packets to random AT&T and Verizon mobile IPs. Think class-action, because you KNOW neither providers will block that traffic when they could bill for it instead.
promoted to entry level computer hardware mover
If it's up to me, the new title will be "exit-level developer".
the non-standard MS symbols, which still hunt me sometimes
This sounds like a case for gun-emoji control.
Does the Nexus 6 I've had practically since it was released count? It's had hardware encryption since support for the 805's coprocessor was added in 5.1.
Aldi is supportive of unions, their cashiers are union and very well paid, and all employees have access to benefits (and they did pre-Obamacare, as well). I don't know about the rest of their staff but my understanding is that everyone working there must be trained as a cashier, which I imagine would make them all cashiers as far as payroll is concerned (that is to say they're not going to get a promotion and a pay cut).
If I can get cheaper prices and the compromise is that I'm getting off brands and there isn't a million dollars of marketing being thrown in my face every time I enter the store, but the workers are paid well and treated fairly, I think I can live with that, thank you. Sadly, there aren't any Aldi stores where I currently live.
And if not?
You do have a point with this. With verified boot, you'll have to compile with the same compiler, compiler version, and compiler flags, which will wield identical binaries and the signature will remain valid after you replace the binaries with your self-compiled versions. After all of that, you've accomplished nothing, but hey, at least you know the binaries belong to the code, right?
In case anyone is confused about my position on open source: Yes, it has benefits in that you can review the code if you care to do so, and you can compile from source if so inclined. However, it has drawbacks in the form of the circlejerk that is the open source community at large. "Oh, it's open source? It's automatically better." No, sorry, it's not, remove your hand from the penis of the man to your right and remove your penis from the hand of the man to your left and realize that there are many facets to good software. Honestly, most open source projects lack most of the qualities of good software, namely usability and stability, and that's ignoring the security aspect; most projects follow a development pattern along the lines of "we're a small team of nerds who need a specific tool that works a specific way, we know what we need and how it should work so we don't need documentation, any automation we can bring to this task is an improvement over the current state of things so we don't care if it's stable; it'll be modeled after our current process which probably won't make sense to most people but it'll be usable for us and that's what matters. Oh, and being an internal tool used by this small group of trusted individuals, it will be secure by default... in our environment, at least". Does a project like that work? Perhaps, if you're a member of the development team and actually don't need documentation, if you're familiar with the workflow the program was written to follow and that workflow makes sense for your use case, if you're willing to accept software that crashes if you don't feed it exactly the input it expects, and especially if you don't care about security. Or if you have time to review the source and fix these issues.
But really, software is a tool. Find the tool that works for you, the one that does the best job with the least effort, and if security is a concern (and it should be), you should already be using a layered approach that negates the absolute need to review the source code and compile your own binaries (not that anyone honestly does this anyway). Is it nice to be able to do that? Sure, but if you think it is necessary, you are taking the wrong approach to security.
So yes, I use (and support) open source where open source actually works, and I pay for software where open source does not. I pay for a lot of software. Android works better for me than iOS on my phone (which I use differently than a tablet), but iOS works better for me on a tablet; for some reason this blows peoples' minds, but that's the reality of the current market, for me. Oh, and I quite enjoy stirring the pot with regard to choice of platform, especially given that I use all of the major platforms at least once in the course of any given workday.
Welcome to English. I can't even argue with you at this point; anyone who calls English a language is lying to themselves; it's a set of languages, all loosely related by a general set of rules, but with their own specifics. Some would say those are simply different dialects of the language, but the fact is we've got "Queen's" English, "American" English, "Queens" English (note the missing apostrophe, I'm referring to the Brooklyn accent here), and now the Millenials have their own made-up rules and I'm, like, not sure, you know, like, what to like, call it or whatever. (Yes, that was an example of that "dialect")
You could almost compare it to Perl, but at least you can run Perl code through a debugger to make sense of what it's trying to do most of the time.
basically going into the SAN business and re-inventing the wheel
Local caches are useless?
She didn't think it was quite so funny. She then admitted it was, at least, accurate.
Comments like that are akin to saying female lions can't hunt because the male lions are bigger and stronger.
Well, sure, if you ignore half of what was said. It's more akin to saying the average female and well-below-average male lion can't hunt because they're not big and strong enough, while the above average female lion and average male lion can because they are. I know that's too many words for a simple mind like yours, so I understand why you oversimplify the way you do.
Females also tend to have an advantage in situational awareness
Tell that to my wife. Now tell her again. One more time. Nope, she's still not aware you're talking to her. Try calling her name first to get her attention. Okay, now tell her. Nope, she still didn't hear you, try again.
Know what else makes it east to know you need to reload? *click*
If you're counting node licenses you're doing it wrong. If you're at the point of needing performance beyond what FOSS can provide, you're at the point where hiring a team to build a solution tailored to your data will cost less in the long-term than buying a solution that was built for someone else's. You'll get better performance that way, as well.
But if you'd rather pay perpetual licensing to third parties for the rest of your natural life (as implied at the end of your post), you're right, I guess having a large amount of local storage doesn't make sense.
And yes, I do realize I didn't answer any of the questions implied by your comment. Just because you don't have a use case (and nether do I or I'd tell you what that use case is) does not mean one does not exist; clearly Samsung sees a use case for this or they'd not have spent the money to develop it.
Keep in mind that a 12G SAS connection is as good as a 24G SATA Connection since it's bidirectional unlike SATA that's unidirectional
You're assuming an equal flow of read/write traffic and control commands in both directions. If you've got a workload that involves a lot of writes followed by a lot of reads, rather than an interleave of reads and writes, SATA will win.
I'm sure, for your common workload, you are correct, but please try to avoid such sweeping generalizations as they really make you look like you have no idea what you're talking about.
The million IOPS isn't for getting data off the host, it's for data crunching done on the host; often times a host only sends out a fraction of what it reads from disk. In most cases, simple gigE or 10gigE will be sufficient to get data off of such a system, but more IOPS will mean the data gets processed faster and is ready to be retrieved sooner. For datasets under a couple hundred GB, there's still nothing that beats a RAMdisk, but for larger sets this is where it's at.
Here's a solution for virtualized environments (e.g. the cloud):
Think LVM + software RAID + PCIe disk + SAS. When attaching an volume from a SAS array, first allocate a matching partition on the PCIe SSD, then build a RAID 1 with the SAS volume and the local partition. It's on you to figure out how to prioritize the local disk over the SAS for IO, so all reads come from the SSD and all writes hit the SSD first for consistency, but there you go. The caveat is that, once the SAS volume is used in the software RAID, it can only be used as a member of a RAID array going forward, so taking an instance offline and spinning it back up from the same volume will require rebuilding the RAID. There are issues as well with using two different "disks" for the RAID array, but those are mitigated by prioritizing the local disk; the SAS volume can be used during the rebuild, so the instance can still boot and be used (albeit with degraded performance) while the RAID rebuilds.
This is just my 2-minute-engineering solution to the problem. I wouldn't be surprised if a better solution already exists for this; in fact I'm 99% certain one does. I don't live in a datacenter, though, so I'm not aware of one.
It's different in that what the warranty oh so graciously offers to cover is often vastly different from what the product is claimed to be capable of in advertising. My understanding is that SoGA entitles you to a full refund if the item does not live up to its advertising and not just the portion the manufacturer states in the warranty. Additionally, as explained by the poster before me, the ability to take the product back to the store rather than having to deal with the manufacturer, regardless of the store's return policy.
Ahh, fun stuff. I had this happen with a gen 4 classic and a gen 1 nano. On the classic it was the result of an interrupted sync (accidentally yanked the cable), on the nano it was a case of manual sync getting confused. It was fixed on the classic by telling it to shut down, then turning it back on; the gray songs (which hadn't succesfully synched) were gone and plugging it back in caused it to sync successfully. I had to reset the nano, though, and sync it from a fresh (empty) state. Apparently, the iPod will report manually synched tracks as being present if there is a database entry on the device, even if the file is missing or damaged. Because the device says the file is there, iTunes doesnt sync it; and because the file actually isn't there, the device obviously can't play it.
/. with details about your buddy's iPod.
If restarting and resetting don't work (or if you're talking about gray tracks in iTunes rather than on the iPod itself), drop me a line via email so we don't end up spamming
You weren't hard enough on that AC. And I mean that sincerely.
The Snapdragon 805 in the Nexus 6 has hardware encryption support and it has been supported since Android 5.1.
Thank you for making this point more concisely than I've done in the past. I never actually looked as far back as the iPhone 4, so I'll remember that data point for future reference.
Well if it's my bank account you're after, you'd be better off cutting off one of my kid's fingers every hour until I hand over the account numbers and/or contents rendering my phone's encryption irrelevant either way. However, if you're a nonviolent offender, by far the most common class of criminal, that encryption certainly stops you dead in your tracks.