Oh, in case it wasn't clear in my ranting elsewhere about AES-NI: it generally improves crypto filesystem throughput by 4x to 10x while simultaneously reducing the CPU utilization by 80%.
Therefore, I would expect the E-350 successor to be able to handle 100+ MB/sec of simple, lowest-grade AES-CBC disk crypto while only having a 20% CPU utilization compared to the E-350's ~30 MB/sec at 100% CPU utilization for the same configuration. Furthermore, AES-NI doesn't adversely affect power budget because "all it does" is to provide silicon support for a few opcodes to conduct certain low-level AES operations in a single instruction vs. the multiple instructions/memory accesses required to do it in software. Meta-operations, if you will.
So, if you are using even basic/simplistic crypto then having AES-NI support contributes far more to performance than even a simple, non-AES-NI CPU upgrade would deliver. This would leave the "camera solution" in this thread's subject more capable of handling camera image capture/processing/higher resolution/whatever while meeting the same basic security goals.
I believe we are on the same page about desired features: simple, basic security, low power, able to be powered via something like an M3-ATX-HV in a vehicle, capable of handling video capture, and low cost. I think the E-350 would run hot for this (due to CPU overhead for basic crypto), but its successor likely would not. For example, I am deliberately running my E-350 NAS in passive/fanless mode, and sustained ~30 MB/sec basic crypto fs throughput will push its CPU up to about 70 C... I think an automotive application would ideally be passive/fanless with no moving parts, and would be operating in a wider-temperature environment than my home NAS.
Actually if you read the title of the post, "Ask Slashdot: Encrypted Digital Camera/Recording Devices?" and from TFS: "But given the level of overreach law enforcement has shown, I'd only consider one if I could be assured that the data was secure from prying eyes (e.g., a camera that writes to encrypted SD memory)." it is clear that this is about preventing the data from being accessed by unauthorized cops.
Nowhere in the topic does it refer to ensuring that cops can't destroy the data. That is a separate consideration and is orthogonal to the point at hand. FFS, man, you seem to be voluntarily choosing to be deliberately obtuse—this topic is about encrypting data storage.
What I am proposing is the simplest possible method. It just doesn't get any simpler than "install existing, well-documented crypto filesystem software, set it on the lowest supported grade of encryption, and then use the encrypted datastore like any normal filesystem". This takes approximately two minutes to get up and running, and that's what I am saying has limited performance on an E-350. I am not complaining that "NSA-proof" crypto is slow on an E-350; rather, that the simplest possible crypto filesystem configuration is slow. Perhaps the performance is sufficient for the purposes at hand, but this is absolutely a salient consideration. You seem to be taking it personally that the E-350 is likely marginal for this topic's task. As I noted in another comment, the E-350's Jaguar-based successor should resolve this issue by supporting AES-NI on die.
Your droll attempt to be clever with the XKCD reference really missed the mark. You are the one overthinking this by implicitly suggesting that users use something more complicated to setup & operate than a crypto filesystem.
Hell, even the cell crypto PCIe board is a spurious consideration, because a $300 increased budget would be better spent on a motherboard and a low-power CPU with AES-NI support on die... and that wouldn't blow the power budget, either. Even tendering this as an option suggests that you are operating in a "golden hammer" type fixation on using the E-350. For example, a 17 watt TDP dual-core Ivy Bridge Xeon E3-1220LV2 with AES-NI support runs about $200 at retail, and a cheap socket 1155 micro-ATX MSI motherboard that supports that processor costs about $55 at retail. Hell, that's just one possibility among many.
I am frustrated attempting to communicate with you, and I consider this regrettable because I have being paying attention to your comments ever since you related your saga of IP travails in your stymied attempt to create your abandonware USB stick product.
Yes, it has a PCIe slot, and I explored that option. The problem is crypto framework support for the hardware. For example, the FreeBSD systems support a handful of VPN accelerator cards for this purpose, but the available/supported devices are nearly a decade old. From what I have read they are about the same speed as the E-350 CPU in terms of crypto, and the options are an either/or decision for whether to use the hardware crypto card or the software-based CPU implementation... meaning that you can't double performance that way.
Really, the way forward is the AES-NI instructions, which are well supported by just about every framework. From what I understand, the E-350 successor is to be based on Jaguar cores and thus should have AES-NI included.
An aspect of the file change log capability already exists in ZFS ("zfs diff"), which displays the file/dir changes between two snapshots or a snapshot/filesystem. It would be nice to determine what has changed on the filesystem since an arbitrary point, like btrfs can do. However, this isn't a capability that is intrinsically precluded from ZFS—the filesystem uses transaction IDs—it's more like no one has extended the zfs diff functionality yet.
As for the extents, that term seems to be overloaded in btrfs: extent block groups, extent trees, btree extent backrefs, etc. Were you referring to the extent block group administrative control, the allocation strategy, or something else?
Does btrfs allow you to add cache or log accelerator devices to a storage pool? I couldn't find any equivalent of that feature, based on my googling. Hm, "How ZFS continues to be better than btrfs" seems to indicate that log acceleration isn't available.
Oh, and who could forget RAID-Z[2,3]?
Having more choice is better, and perhaps a bit of competition from btrfs will prompt the ZFS devs to add additional features (eg. like the file change search capability).
Furthermore, ZFS has been around since 2005-ish and is stable for use in production enterprise systems.
Ultimately it is not to Oracle's advantage that Z-OS, I-OS (the IBM one) and AIX are the OSes for very large storage. That's how they could lose to DB2 / Netezza.
So, you're saying that it therefore makes more sense for Oracle to back the multi-year development of a completely new filesystem that is attempting to mimic a subset of the features of ZFS, rather than to... merely dual-license ZFS, which would allow ZFS to be included in Linux tomorrow?
Those are some flaming hoops of reasoning you just leaped through there.
The reason ZFS on Linux isn't getting much traction is that the community doesn't want to encourage this kind of "can't ship as a binary/have to personally compile" fragmentation of Linux. I mean, what a nightmare for enterprise providers like RedHat... "Sure, we support your custom-compiled kernel! What could possibly go wrong?"
It just took a long time, as no one sane would run ZFS on USB hardware to start with.
Are you attempting to troll? ZFS on FreeBSD has performed superbly on my home NAS using USB hardware. But why take my word for it...
OpenSolaris Home Server: ZFS and USB Disks: "Together, USB disks and ZFS make a great team. Not enterprise class, but certainly an interesting option for a home server."
Yes, but that solves the inverse of the stated problem. While it is useful to ensure that one retains a copy of the data, the topic is about denying other people a copy.
This is about making the data unintelligible for the cops if they were to yank the computer.
I run mine completely fanless and passively cooled by its (rather massive) heatsink. It gets hot under load, though not enough to trip the thermal protection scaler. Furthermore, it's silent except for capacitor whine.
As I noted above, the platform is marginal with regard to crypto filesystem throughput even on the lowest possible settings that various crypto frameworks offer. One crucial factor that gives it an edge over an Atom-platform unit is that the system supports up to 8 GB of RAM vs. Atom's 4 GB.
I would be completely satisfied with my E-350 if it supported AES-NI, which would bump the crypto throughput into the 100+ megabyte per second range.
You know, perhaps you should actually research setting up crypto on one of these machines before you pontificate. Based on your comment, it seems you are unaware that AES doesn't offer a keysize smaller than 128 bit. Furthermore, there are no GPU-accelerated crypto filesystems, despite your erroneous belief to the contrary.
For Windows/Mac/Linux, TrueCrypt offers AES-256/XTS as its "simplest" option; that's significantly slower than what I suggested. DM-Crypt/LUKS offers AES-128-ECB-null on Linux, which should have similar performance to FreeBSD's geli AES-128-CBC—that's about as fast as it gets: ~30 megabytes per second on an E-350.
Or, if you don't care at all about using existing crypto filesystems and want to put yourself through the pain of developing your own solution, then why not just apply a constant XOR value to every byte of your files? That should be fast, symmetrical, and should confuse your "beat cop" while not really offering anything cryptographically secure. Hell, why not just delete the first, "header metadata" bytes of each video file... that should confuse your beat cop's video player.
Oh please, you're being overly dramatic. Yes, it's a bubble with an impending crash; however, 90 cents is only enough to, say, drive your car six miles or so.
I would bet 90 cents you don't wring your hands over the monetary cost of even a 10 mile detour while driving.
It's been 100 years since the Fed started systematically eroding the value of our money.
Yeah but to be fair we ARE talking about just keeping the average police force out of them, not like we are talking about the FBI or CIA. You could probably get by with half of that and would stump the shit out of your average police force no problem, and let us not forget you also have a GP-GPU that can be used for other things...like say Crypto.
Perhaps I missed your point, but what I'm saying is that AES 128 bit/CBC (4K sectors) is probably the minimum tolerable security threshold at the moment. I ended up choosing this over something potentially more secure like AES 256 bit/XTS (512 byte sectors) because the performance on the E-350 was abysmal. So, you can consider the ~30 MBps throughput @ 100% CPU utilization (both cores) to be an upper bound for these.
Also, I have never encountered an AES crypto filesystem that could use GPU acceleration; that means your CPU resources have to be used for the crypto and anything else currently executing will have an effect on your encrypted disk throughput.
Do you have countervailing experience? If so, please let me know because I could certainly use more throughput...
Not only is it an easy job but it'll do 1080p and most will hold 8GB of DDR 3 while using even less power than my Sempron, its really a sweet little unit.
Just an FYI: the maximum throughput of an E-350 to an SSD encrypted with AES-128 CBC (4K sectors) is on the order of 30 megabytes/sec... and that's with full CPU use for the crypto (i.e. the system is doing nothing else).
These really suffer from their lack of AES-NI support; it's their one major downfall.
Perhaps the next gen systems will be better (read: AES-NI). At least these support 2x the RAM that Atoms do.
It's one thing to superimpose an interactive Flash game for the driver via a HUD.
It's another thing entirely to have an optional FLIR overlay to increase the driver's perception of the path ahead, or to display the vehicle's current speed in the upper-left area of the windshield, etc. Capabilities like this are likely to improve safety rather than diminish it. Admittedly, these would work best via an actual HUD in the vehicle rather than via a personal Glass device, but the point remains.
Hell, I have idly considered rigging a FLIR HUD prototype in my next vehicle. It shouldn't be too hard (just expensive).
Do you realize that any entity that controls over 50% of the hashrate of the Bitcoin network controls the entire thing?
Have you seen the hashrate of the new, high-end ASIC rigs? How much would it cost to buy 100% equivalent of the current network hashrate in brand new ASIC rigs? A few million dollars? 10 million dollars?
Do you think that's a significant amount to "suits"?
People needed to use CPU cycles to "mine" them, thus they feel like they've accomplished something. They feel like they've contributed. They have earned something of value. It's a very nice, exciting, warm and fuzzy feeling.
I think that was due to the waste heat exhaust from cooling their CPU's.
The problem with that approach is that you lose an important idiom that doesn't have a good substitute.
The idiom has already been lost, if only because communication is fundamentally about conveying concepts among those involved in discourse. The term "begs the question" at best is ambiguous now, but truly the original definition has been supplanted in common usage. Thus, using the idiom increases confusion in discourse (which is considered harmful).
Besides, "begs the question" (original idiom) doesn't mesh with the common usage of the word "beg" anymore, unlike how the "begs the question" (modern idiom) does. I argue that it was a poor choice of term in the first place.
Better to start promulgating the Latin term "petitio principii" for the fallacy, which should remain unambiguous forever. Or try "presumes the argument" or "presumes the point" instead, both of which are self-explanatory and are unlikely to become obsolete. Hell, the latter form has the same syllable count as "begs the question".
Well, I grant your point that all of these accounts I reference were "free" in terms of not having a periodic fee for the account. Americans rather expect that the institution to which we're offering to let temporarily have access to our money wouldn't charge us for the simple privilege of "allowing" us to let them take our money. If that makes sense. Yeah, if I'm giving my money to a bank to store then they damn well better not charge me for that.
Also, interest rates (even on high yield, "online-only" savings accounts) are probably abysmal almost everywhere in the world right now. Far less than 1%. As for regular, brick and mortar banks, those have always had shitty interest rates; I believe one such of my accounts is currently paying 0.025% APY. No, that's not a typo. I actually called the bank and asked them to stop paying "interest" (if that's the correct term for 0.025%) on that account because it just annoyed me and gave me headaches with my accounting software. They first were confused why I would want to do that, but eventually refused to comply with my wishes, so I am forced to earn a handful of cents per year. And then they spend 15x the interest amount on postage to send me a tax document telling me they reported my 3 cents of interest income (or whatever) to the IRS.
I don't know about your banks, but with mine I can open an account with an overdraft limit of 0.00. In other words, if there's no money on it, they get their attempt to withdraw rejected.
Yes, but they *love* their overdraft fees, so they usually make the overdraft program operate similarly to Facebook privacy controls. "We've changed something about our overdraft program and so we've opted you back into what you explicitly told us you didn't want! Contact us if, for some bizarre reason, you don't want this amazing service!"
Besides, have you actually used this approach in practice? What *really* happens is that even if you have the account setup to not overdraft if something comes in that would bounce then they refuse to pay *and* they charge you some absurd NSF fee.
...and even credit unions do that.
For example, once I was hit with an NSF by a credit union after the fucking FDIC yanked money out of my account because the bank from which I had transferred the money failed. So, the FDIC "helped" by absconding with thousands of dollars of my money which was at a completely different institution than the one that failed and then sent me a paper check later. Fuckers.
Basically, the best way to be able to prevent overcharging by other entities with whom you transact is to use a controlled payment number like BoA ShopSafe. The only failing with this approach is that it is limited to entities that accept credit card payments.
Despite periodic "corrections", the price is still continuing to rise precipitously. The volatility is insane, but how viable is it that the price on 1 Jan 2013 was 1 BTC/~$15, and now it's trading for ~$70? The value has more than quadrupled in the 81 days so far in 2013. If the present bubble is extrapolated that represents roughly a 103,000% APY; clearly, that growth is unsustainable.
Yes, these laws/bans would almost be amusing (in a surreal way) if they didn't carry the threat of 10 years in federal prison.
Here's an example. The ATF has decided that on the AR-15 platform the lower receiver is considered the registered firearm. It is this part (less the pistol grip).
That means that all other components of an AR-15 are freely available: you only have to get a background check to buy the lower receiver from the FFL dealer. When you buy it, the lower receiver is legally designated on the form with its type (regular rifle, short-barreled rifle, pistol, AOW, etc).
The upper receiver on AR-15's (the rest of the firearm, less the stock) simply plugs into the lower receiver and is held in place with push pins.
Let's say you legally own this regular rifle and also owned this pistol (both normal, non-NFA firearms). Furthermore, let's say you decided to clean them both at the same time, and when you were done you accidentally plugged the pistol upper into the rifle lower.
Congratulations, you've just committed felony construction of a short-barreled rifle.
I can understand the ban on machine guns
Since the NFA became law in 1934 there have been approximately two (2) homicides that have been committed using a legally-owned machine gun. One of those was a police officer murdering his informant. There's no reason for the current ban on new machine gun production for civilians.
Still, though, why do we have these restrictions? Why is an 11-inch barrel legal in one instance and illegal in another?
You should stop looking for a legitimate rationale or intellectual honesty within the NFA: it's almost entirely arbitrary and enforcement is capricious. Essentially, the only valid functional classification within the NFA is that of a machine gun (ie. a firearm that fires two or more shots with a single pull of a trigger); however, even that led to the ATF issuing a machine gun classification to a shoelace.
Furthermore, do you know that suppressors (aka "silencers") are classified as Title II firearms according to the NFA? Suppressors aren't "Hollywood quiet" in real life. As a matter of fact, I believe we should propose gun safety legislation to allow "firearm mufflers" ownership to be unrestricted, just like in Finland, Norway, Poland, Italy, etc. Gun safety for hearing protection, of course.
Essentially, the NFA was the 1930's equivalent of the "assault weapons" ban: a ban on "scary looking things" and machine guns. However, at that time the intellectual dishonesty of the Wickard v. Filburn decision had yet to come to pass. Therefore, the gun control proponents felt constrained by the Constitution: they had no power to ban these weapons but they had the power to tax. Therefore, they set a fixed $200 tax on these "evil weapons" that was many times the value of the regulated items.
Now they don't bother with workarounds that. According to the Supreme Court in Gonzales v. Raich, even producing something and giving it away for free within a single state qualifies as "interstate commerce", which implies that Congress can regulate, restrict, or ban it.
So, you asked the correct question, but ultimately there is no valid rationale for the law for you to find. Your question also applies to the 1994 Assault Weapons Ban (and Feinstein's current proposed law): what valid reason exists to ban things simply due to cosmetics? Why are pistol grips on rifles "evil", but are okay on pistols? Why are adjustable rifle stocks evil?
It's farcical.
What possible public interest is served by making rifles legal, pistols legal, "short-barreled rifles" legal, but a Frankengun that's a rifle with a barrel less than 16 inches illegal?
Actually, all of those are legal provided you comply with the NFA.
Title I firearms (eg. rifes, pistols, shotguns) are the "regular" kind of firearms found in everyday stores and require no NFA tax stamps. Title II firearms are things like short-barreled rifles, short-barreled shotguns, suppressors, machine guns, and "Any Other Weapons" (AOW); these require the tax stamp, approval from the federal government to own, etc.
The "Frankengun" you describe would be classified as an NFA short-barreled rifle (cf. this rifle) needing a stamp + federal approval, unless it lacked a stock, whereupon it would be classified as a regular handgun (cf. this pistol) with no restrictions, unless it had a vertical forward grip, whereupon it would be an AOW and need a stamp + federal approval.
BTW, you have to choose the firearm's classification *before* you make/obtain the firearm (see first link in my post).
What does Voyager's impending power failure have to do with any of this? Unfortunately, your reply did nothing to elucidate your original statement.
I mean, even if you were alleging some sort of thermal radiation pressure acceleration due to the RTG, that's really esoteric and is a complete non-sequitur to your comment about the 10 to 15 year remaining lifespan of the power supply. Not to mention I imagine you would have explained that if if this were what you were claiming.
Running out of power will have no effect on Voyager's velocity.
Slashdot Mirror
Oh, in case it wasn't clear in my ranting elsewhere about AES-NI: it generally improves crypto filesystem throughput by 4x to 10x while simultaneously reducing the CPU utilization by 80%.
Therefore, I would expect the E-350 successor to be able to handle 100+ MB/sec of simple, lowest-grade AES-CBC disk crypto while only having a 20% CPU utilization compared to the E-350's ~30 MB/sec at 100% CPU utilization for the same configuration. Furthermore, AES-NI doesn't adversely affect power budget because "all it does" is to provide silicon support for a few opcodes to conduct certain low-level AES operations in a single instruction vs. the multiple instructions/memory accesses required to do it in software. Meta-operations, if you will.
So, if you are using even basic/simplistic crypto then having AES-NI support contributes far more to performance than even a simple, non-AES-NI CPU upgrade would deliver. This would leave the "camera solution" in this thread's subject more capable of handling camera image capture/processing/higher resolution/whatever while meeting the same basic security goals.
I believe we are on the same page about desired features: simple, basic security, low power, able to be powered via something like an M3-ATX-HV in a vehicle, capable of handling video capture, and low cost. I think the E-350 would run hot for this (due to CPU overhead for basic crypto), but its successor likely would not. For example, I am deliberately running my E-350 NAS in passive/fanless mode, and sustained ~30 MB/sec basic crypto fs throughput will push its CPU up to about 70 C... I think an automotive application would ideally be passive/fanless with no moving parts, and would be operating in a wider-temperature environment than my home NAS.
Actually if you read the title of the post, "Ask Slashdot: Encrypted Digital Camera/Recording Devices?" and from TFS: "But given the level of overreach law enforcement has shown, I'd only consider one if I could be assured that the data was secure from prying eyes (e.g., a camera that writes to encrypted SD memory)." it is clear that this is about preventing the data from being accessed by unauthorized cops.
Nowhere in the topic does it refer to ensuring that cops can't destroy the data. That is a separate consideration and is orthogonal to the point at hand. FFS, man, you seem to be voluntarily choosing to be deliberately obtuse—this topic is about encrypting data storage.
What I am proposing is the simplest possible method. It just doesn't get any simpler than "install existing, well-documented crypto filesystem software, set it on the lowest supported grade of encryption, and then use the encrypted datastore like any normal filesystem". This takes approximately two minutes to get up and running, and that's what I am saying has limited performance on an E-350. I am not complaining that "NSA-proof" crypto is slow on an E-350; rather, that the simplest possible crypto filesystem configuration is slow. Perhaps the performance is sufficient for the purposes at hand, but this is absolutely a salient consideration. You seem to be taking it personally that the E-350 is likely marginal for this topic's task. As I noted in another comment, the E-350's Jaguar-based successor should resolve this issue by supporting AES-NI on die.
Your droll attempt to be clever with the XKCD reference really missed the mark. You are the one overthinking this by implicitly suggesting that users use something more complicated to setup & operate than a crypto filesystem.
Hell, even the cell crypto PCIe board is a spurious consideration, because a $300 increased budget would be better spent on a motherboard and a low-power CPU with AES-NI support on die... and that wouldn't blow the power budget, either. Even tendering this as an option suggests that you are operating in a "golden hammer" type fixation on using the E-350. For example, a 17 watt TDP dual-core Ivy Bridge Xeon E3-1220LV2 with AES-NI support runs about $200 at retail, and a cheap socket 1155 micro-ATX MSI motherboard that supports that processor costs about $55 at retail. Hell, that's just one possibility among many.
I am frustrated attempting to communicate with you, and I consider this regrettable because I have being paying attention to your comments ever since you related your saga of IP travails in your stymied attempt to create your abandonware USB stick product.
Yes, it has a PCIe slot, and I explored that option. The problem is crypto framework support for the hardware. For example, the FreeBSD systems support a handful of VPN accelerator cards for this purpose, but the available/supported devices are nearly a decade old. From what I have read they are about the same speed as the E-350 CPU in terms of crypto, and the options are an either/or decision for whether to use the hardware crypto card or the software-based CPU implementation... meaning that you can't double performance that way.
Really, the way forward is the AES-NI instructions, which are well supported by just about every framework. From what I understand, the E-350 successor is to be based on Jaguar cores and thus should have AES-NI included.
Interesting, thanks for that info.
An aspect of the file change log capability already exists in ZFS ("zfs diff"), which displays the file/dir changes between two snapshots or a snapshot/filesystem. It would be nice to determine what has changed on the filesystem since an arbitrary point, like btrfs can do. However, this isn't a capability that is intrinsically precluded from ZFS—the filesystem uses transaction IDs—it's more like no one has extended the zfs diff functionality yet.
As for the extents, that term seems to be overloaded in btrfs: extent block groups, extent trees, btree extent backrefs, etc. Were you referring to the extent block group administrative control, the allocation strategy, or something else?
Does btrfs allow you to add cache or log accelerator devices to a storage pool? I couldn't find any equivalent of that feature, based on my googling. Hm, "How ZFS continues to be better than btrfs" seems to indicate that log acceleration isn't available.
Oh, and who could forget RAID-Z[2,3]?
Having more choice is better, and perhaps a bit of competition from btrfs will prompt the ZFS devs to add additional features (eg. like the file change search capability).
AFAIK BTRFS is [...] more feature rich.
[citations desperately needed]
Furthermore, ZFS has been around since 2005-ish and is stable for use in production enterprise systems.
Ultimately it is not to Oracle's advantage that Z-OS, I-OS (the IBM one) and AIX are the OSes for very large storage. That's how they could lose to DB2 / Netezza.
So, you're saying that it therefore makes more sense for Oracle to back the multi-year development of a completely new filesystem that is attempting to mimic a subset of the features of ZFS, rather than to... merely dual-license ZFS, which would allow ZFS to be included in Linux tomorrow?
Those are some flaming hoops of reasoning you just leaped through there.
The reason ZFS on Linux isn't getting much traction is that the community doesn't want to encourage this kind of "can't ship as a binary/have to personally compile" fragmentation of Linux. I mean, what a nightmare for enterprise providers like RedHat... "Sure, we support your custom-compiled kernel! What could possibly go wrong?"
It just took a long time, as no one sane would run ZFS on USB hardware to start with.
Are you attempting to troll? ZFS on FreeBSD has performed superbly on my home NAS using USB hardware. But why take my word for it...
OpenSolaris Home Server: ZFS and USB Disks:
"Together, USB disks and ZFS make a great team. Not enterprise class, but certainly an interesting option for a home server."
Yes, but that solves the inverse of the stated problem. While it is useful to ensure that one retains a copy of the data, the topic is about denying other people a copy.
This is about making the data unintelligible for the cops if they were to yank the computer.
Looks like you are in the ballpark:
Intel Core2 Duo T5500 @ 1.66GHz - score 882
AMD E-350 APU - score 881
I run mine completely fanless and passively cooled by its (rather massive) heatsink. It gets hot under load, though not enough to trip the thermal protection scaler. Furthermore, it's silent except for capacitor whine.
As I noted above, the platform is marginal with regard to crypto filesystem throughput even on the lowest possible settings that various crypto frameworks offer. One crucial factor that gives it an edge over an Atom-platform unit is that the system supports up to 8 GB of RAM vs. Atom's 4 GB.
I would be completely satisfied with my E-350 if it supported AES-NI, which would bump the crypto throughput into the 100+ megabyte per second range.
You know, perhaps you should actually research setting up crypto on one of these machines before you pontificate. Based on your comment, it seems you are unaware that AES doesn't offer a keysize smaller than 128 bit. Furthermore, there are no GPU-accelerated crypto filesystems, despite your erroneous belief to the contrary.
For Windows/Mac/Linux, TrueCrypt offers AES-256/XTS as its "simplest" option; that's significantly slower than what I suggested. DM-Crypt/LUKS offers AES-128-ECB-null on Linux, which should have similar performance to FreeBSD's geli AES-128-CBC—that's about as fast as it gets: ~30 megabytes per second on an E-350.
Or, if you don't care at all about using existing crypto filesystems and want to put yourself through the pain of developing your own solution, then why not just apply a constant XOR value to every byte of your files? That should be fast, symmetrical, and should confuse your "beat cop" while not really offering anything cryptographically secure. Hell, why not just delete the first, "header metadata" bytes of each video file... that should confuse your beat cop's video player.
I wouldn't invest 90 cents in bitcoin.
Oh please, you're being overly dramatic. Yes, it's a bubble with an impending crash; however, 90 cents is only enough to, say, drive your car six miles or so.
I would bet 90 cents you don't wring your hands over the monetary cost of even a 10 mile detour while driving.
It's been 100 years since the Fed started systematically eroding the value of our money.
Yeah but to be fair we ARE talking about just keeping the average police force out of them, not like we are talking about the FBI or CIA. You could probably get by with half of that and would stump the shit out of your average police force no problem, and let us not forget you also have a GP-GPU that can be used for other things...like say Crypto.
Perhaps I missed your point, but what I'm saying is that AES 128 bit/CBC (4K sectors) is probably the minimum tolerable security threshold at the moment. I ended up choosing this over something potentially more secure like AES 256 bit/XTS (512 byte sectors) because the performance on the E-350 was abysmal. So, you can consider the ~30 MBps throughput @ 100% CPU utilization (both cores) to be an upper bound for these.
Also, I have never encountered an AES crypto filesystem that could use GPU acceleration; that means your CPU resources have to be used for the crypto and anything else currently executing will have an effect on your encrypted disk throughput.
Do you have countervailing experience? If so, please let me know because I could certainly use more throughput...
Not only is it an easy job but it'll do 1080p and most will hold 8GB of DDR 3 while using even less power than my Sempron, its really a sweet little unit.
Just an FYI: the maximum throughput of an E-350 to an SSD encrypted with AES-128 CBC (4K sectors) is on the order of 30 megabytes/sec... and that's with full CPU use for the crypto (i.e. the system is doing nothing else).
These really suffer from their lack of AES-NI support; it's their one major downfall.
Perhaps the next gen systems will be better (read: AES-NI). At least these support 2x the RAM that Atoms do.
...that's from the same source as Tuscan Whole Milk, 1 gal, 128 fl. oz., right?
ZOMG! Nork rush!!!!1!!!eleven!!!
It's all about context and type of data.
It's one thing to superimpose an interactive Flash game for the driver via a HUD.
It's another thing entirely to have an optional FLIR overlay to increase the driver's perception of the path ahead, or to display the vehicle's current speed in the upper-left area of the windshield, etc. Capabilities like this are likely to improve safety rather than diminish it. Admittedly, these would work best via an actual HUD in the vehicle rather than via a personal Glass device, but the point remains.
Hell, I have idly considered rigging a FLIR HUD prototype in my next vehicle. It shouldn't be too hard (just expensive).
Do you realize that any entity that controls over 50% of the hashrate of the Bitcoin network controls the entire thing?
Have you seen the hashrate of the new, high-end ASIC rigs? How much would it cost to buy 100% equivalent of the current network hashrate in brand new ASIC rigs? A few million dollars? 10 million dollars?
Do you think that's a significant amount to "suits"?
People needed to use CPU cycles to "mine" them, thus they feel like they've accomplished something. They feel like they've contributed. They have earned something of value. It's a very nice, exciting, warm and fuzzy feeling.
I think that was due to the waste heat exhaust from cooling their CPU's.
The problem with that approach is that you lose an important idiom that doesn't have a good substitute.
The idiom has already been lost, if only because communication is fundamentally about conveying concepts among those involved in discourse. The term "begs the question" at best is ambiguous now, but truly the original definition has been supplanted in common usage. Thus, using the idiom increases confusion in discourse (which is considered harmful).
Besides, "begs the question" (original idiom) doesn't mesh with the common usage of the word "beg" anymore, unlike how the "begs the question" (modern idiom) does. I argue that it was a poor choice of term in the first place.
Better to start promulgating the Latin term "petitio principii" for the fallacy, which should remain unambiguous forever. Or try "presumes the argument" or "presumes the point" instead, both of which are self-explanatory and are unlikely to become obsolete. Hell, the latter form has the same syllable count as "begs the question".
Well, I grant your point that all of these accounts I reference were "free" in terms of not having a periodic fee for the account. Americans rather expect that the institution to which we're offering to let temporarily have access to our money wouldn't charge us for the simple privilege of "allowing" us to let them take our money. If that makes sense. Yeah, if I'm giving my money to a bank to store then they damn well better not charge me for that.
Also, interest rates (even on high yield, "online-only" savings accounts) are probably abysmal almost everywhere in the world right now. Far less than 1%. As for regular, brick and mortar banks, those have always had shitty interest rates; I believe one such of my accounts is currently paying 0.025% APY. No, that's not a typo. I actually called the bank and asked them to stop paying "interest" (if that's the correct term for 0.025%) on that account because it just annoyed me and gave me headaches with my accounting software. They first were confused why I would want to do that, but eventually refused to comply with my wishes, so I am forced to earn a handful of cents per year. And then they spend 15x the interest amount on postage to send me a tax document telling me they reported my 3 cents of interest income (or whatever) to the IRS.
I don't know about your banks, but with mine I can open an account with an overdraft limit of 0.00. In other words, if there's no money on it, they get their attempt to withdraw rejected.
Yes, but they *love* their overdraft fees, so they usually make the overdraft program operate similarly to Facebook privacy controls. "We've changed something about our overdraft program and so we've opted you back into what you explicitly told us you didn't want! Contact us if, for some bizarre reason, you don't want this amazing service!"
Besides, have you actually used this approach in practice? What *really* happens is that even if you have the account setup to not overdraft if something comes in that would bounce then they refuse to pay *and* they charge you some absurd NSF fee.
For example, once I was hit with an NSF by a credit union after the fucking FDIC yanked money out of my account because the bank from which I had transferred the money failed. So, the FDIC "helped" by absconding with thousands of dollars of my money which was at a completely different institution than the one that failed and then sent me a paper check later. Fuckers.
Basically, the best way to be able to prevent overcharging by other entities with whom you transact is to use a controlled payment number like BoA ShopSafe. The only failing with this approach is that it is limited to entities that accept credit card payments.
That place is like the Fight Club of Bitcoin.
The bubble is obvious: look at the 2013 BTC/USD chart.
Despite periodic "corrections", the price is still continuing to rise precipitously. The volatility is insane, but how viable is it that the price on 1 Jan 2013 was 1 BTC/~$15, and now it's trading for ~$70? The value has more than quadrupled in the 81 days so far in 2013. If the present bubble is extrapolated that represents roughly a 103,000% APY; clearly, that growth is unsustainable.
So... is anyone selling put options on BTC?
Seems like purchasing a few puts on BTC will pay off handsomely.
Yes, these laws/bans would almost be amusing (in a surreal way) if they didn't carry the threat of 10 years in federal prison.
Here's an example. The ATF has decided that on the AR-15 platform the lower receiver is considered the registered firearm. It is this part (less the pistol grip).
That means that all other components of an AR-15 are freely available: you only have to get a background check to buy the lower receiver from the FFL dealer. When you buy it, the lower receiver is legally designated on the form with its type (regular rifle, short-barreled rifle, pistol, AOW, etc).
The upper receiver on AR-15's (the rest of the firearm, less the stock) simply plugs into the lower receiver and is held in place with push pins.
Let's say you legally own this regular rifle and also owned this pistol (both normal, non-NFA firearms). Furthermore, let's say you decided to clean them both at the same time, and when you were done you accidentally plugged the pistol upper into the rifle lower.
Congratulations, you've just committed felony construction of a short-barreled rifle.
I can understand the ban on machine guns
Since the NFA became law in 1934 there have been approximately two (2) homicides that have been committed using a legally-owned machine gun. One of those was a police officer murdering his informant. There's no reason for the current ban on new machine gun production for civilians.
Still, though, why do we have these restrictions? Why is an 11-inch barrel legal in one instance and illegal in another?
You should stop looking for a legitimate rationale or intellectual honesty within the NFA: it's almost entirely arbitrary and enforcement is capricious. Essentially, the only valid functional classification within the NFA is that of a machine gun (ie. a firearm that fires two or more shots with a single pull of a trigger); however, even that led to the ATF issuing a machine gun classification to a shoelace.
Furthermore, do you know that suppressors (aka "silencers") are classified as Title II firearms according to the NFA? Suppressors aren't "Hollywood quiet" in real life. As a matter of fact, I believe we should propose gun safety legislation to allow "firearm mufflers" ownership to be unrestricted, just like in Finland, Norway, Poland, Italy, etc. Gun safety for hearing protection, of course.
Essentially, the NFA was the 1930's equivalent of the "assault weapons" ban: a ban on "scary looking things" and machine guns. However, at that time the intellectual dishonesty of the Wickard v. Filburn decision had yet to come to pass. Therefore, the gun control proponents felt constrained by the Constitution: they had no power to ban these weapons but they had the power to tax. Therefore, they set a fixed $200 tax on these "evil weapons" that was many times the value of the regulated items.
Now they don't bother with workarounds that. According to the Supreme Court in Gonzales v. Raich, even producing something and giving it away for free within a single state qualifies as "interstate commerce", which implies that Congress can regulate, restrict, or ban it.
So, you asked the correct question, but ultimately there is no valid rationale for the law for you to find. Your question also applies to the 1994 Assault Weapons Ban (and Feinstein's current proposed law): what valid reason exists to ban things simply due to cosmetics? Why are pistol grips on rifles "evil", but are okay on pistols? Why are adjustable rifle stocks evil?
It's farcical.
What possible public interest is served by making rifles legal, pistols legal, "short-barreled rifles" legal, but a Frankengun that's a rifle with a barrel less than 16 inches illegal?
Actually, all of those are legal provided you comply with the NFA.
Title I firearms (eg. rifes, pistols, shotguns) are the "regular" kind of firearms found in everyday stores and require no NFA tax stamps. Title II firearms are things like short-barreled rifles, short-barreled shotguns, suppressors, machine guns, and "Any Other Weapons" (AOW); these require the tax stamp, approval from the federal government to own, etc.
The "Frankengun" you describe would be classified as an NFA short-barreled rifle (cf. this rifle) needing a stamp + federal approval, unless it lacked a stock, whereupon it would be classified as a regular handgun (cf. this pistol) with no restrictions, unless it had a vertical forward grip, whereupon it would be an AOW and need a stamp + federal approval.
BTW, you have to choose the firearm's classification *before* you make/obtain the firearm (see first link in my post).
What does Voyager's impending power failure have to do with any of this? Unfortunately, your reply did nothing to elucidate your original statement.
I mean, even if you were alleging some sort of thermal radiation pressure acceleration due to the RTG, that's really esoteric and is a complete non-sequitur to your comment about the 10 to 15 year remaining lifespan of the power supply. Not to mention I imagine you would have explained that if if this were what you were claiming.
Running out of power will have no effect on Voyager's velocity.