It depends on where the "brains" are. Facebook (IIRC) has the redundancy on the backend app layer where coupled with NoSQL, if something drops... there is some redundancy built in somewhere to pick it off, or drop a couple tuples, but the tables still have their integrity. Whole servers can drop off the map, and Facebook will keep going. Isn't pretty, but their model really can handle stuff getting tossed here and there.
Apple, on the other hand, uses Teradata systems with NetApp appliances on the backend, so one large cloud provider does go with the more traditional storage stack model found in the enterprise. However, unlike losing a FB post or two, a user losing chunks of their data would not be a good thing, so Apple's model tends to be more rigidly ACID compliant.
Encryption schemes are important, but whenever someone mentions "let's encrypt it", I cringe.
Encryption isn't some magic switch that you turn on and all your data is 100% secure from bad guys. What happens is that it makes a smaller chunk of data (i.e. the key or keys) the valuable part.
Key management isn't a cookie-cutter thing. Error on security, and your data can't be recovered. Error on accessibility, and the bad guys now have your keys and can get your data.
A small company can get by with burning an archival CD-ROM, as well as printing out all keys (passwords especially, but.asc files of private keys as well [1]) A bigger company would have recovery info be split up among corporate officers in a "x out of y" structure (where 3 out of 5 officers are needed to regenerate the master key.) Even larger companies would have regional managers, and far more exotic key management layouts with multiple recovery paths.
If Yahoo decides to just "encrypt it", they need to put in a good key management structure in place... and of course, that will be the prime target for bad guys [2], so it has to be worth the security payoff of keeping the eggs in one basket.
[1]: Yes, it will be hell and a half to retype in, but it will be there. Having archival media on a CD helps with that, but if bit rot nails the CD, there is always the paper copy.
Oh, and don't try utilities which print bitmaps to paper like Paperbak. I've had great look in printing them out... but scanning them in and recovering any data... absolutely zero luck whatsoever, so don't bother with those utilities as of now.
[2]: The NSA is hyped, but one major threat are blackhats who would love access to Yahoo's assets for blackmail, DDoS, extortion, or to find other people to attack.
For a lot of things, the threat of having the device bricked is overblown.
The only time that I've ever been worried about bricking was on the Motorola Atrix 2 when initially, there was no FXZ or other way to reflash back to a stock ROM. Eventually this was remedied, but for a whole, the modding community for that device was walking a tightrope without a safety net.
This doesn't say that one can't brick a device, as it is doable, especially if one misses some directions or skips steps, but it isn't as common as people think.
I can spend $10 and get a T-Mobile SIM plus some prepaid minutes.
In fact, if I'm doing Craigslist transactions, I use a burner phone, and when done, destroy the SIM card [1] and get a new one. That way, after I buy/sell something, I'm not dealing with all the fraudsters who have sons on oil rigs or are willing to send me $50,000 cashiers checks.
I avoid CDMA providers, because if one wants a new number, the whole phone has to be destroyed or recycled. However, once done with the phone, handing it to the nearest street corner hobo pretty much does the same thing (and here in Austin, we envy Santa Cruz for their lack of aggressive homeless population, which says something.)
[1]: Takes only a few times to lock out the PIN, around 20 to fry the PUK, then the card hits a fine-grained shredder.
Google is to be respected there. In the past, I've encountered many businesses that, at best, provide lip service, at worst, have nothing whatsoever.
Almost every business should have some form of key management solution in place, even if it is a printed out piece of paper with all the BitLocker recovery codes stashed in a couple safe deposit boxes. Of course, if some antagonist is big enough, a safe deposit box can be frozen or seized, so for some organizations, that isn't a wise idea.
I just wish USB cryptographic tokens were more widespread. There were some out of Germany that would work with gpg, but they are sold out, and no clue when they might start production again. For example, having tokens in the hands of corporate officers (including the CIO and CTO) then having a tarball of all the other critical keys stored with the corporate data would be an idea. If one of the tokens is still usable, the rest of the key infrastructure would be recoverable, although if one of the tokens gets lost or stolen, the damage would be enormous. One can go with share split systems (e.g. 3 out of 5 keys needed) to help mitigate that.
Encrypting is useful, but then comes the very nasty thing that comes with it: Key management.
Key management is something people fail to think about after the "Encrypt it, encrypt it now!" statement is implemented. How are keys stored, who has access to them. You have to sail your way between the Scylla of having keys obtainable by the bad guys, versus the Charybdis of a disaster causing all data to be forever inaccessible.
Of course, there are plenty of guys who will sell you an encryption appliance that supposedly will handle all this for you. But upon asking, the only way to back up the appliance is to install another appliance... and the only way to back that up. Yep, you guessed it, yet another appliance for replication.
Take backup media for instance. You can buy exotic tools to lock it down many ways. Or, you can set a password via Diceware, have it in a physical notebook with multiple copies (tape safe, offsite), and every year or two, change to a new one while keeping the old one for new tapes. It may not be as snazzy as encrypting each piece of media with its own key, but it provides virtually the same security.
Or another item are LUNs from a SAN. Yes, you can encrypt them, but what happens if/when the host machine goes down... where are the backup keys so the machine can be rebuilt?
Oh, the CA keys. Are they stashed in an armored HSM, or just generated/signed/used on some machine that can be compromised by just walking to it?
In Brazil, I wonder if generator and small engine makers make their products so they can handle E100.
The reason why that would be nice to have is that one could get a fuel distiller's permit, then build a still to ferment by-products from a farm to use for fuel.
If it is useful there, the same technology would be useful here in the US, and ethanol is a lot poisonous than gasoline. Nobody would deliberately drink gasoline, but pure ethanol in various dilute concentrations? Very common. Just look around any university area.
I should do objective performance and MPG tests on E85 because my current vehicle can use the stuff [1]. There is a small horsepower increase, but the loss of MPG (which I would guesstimate around 20 percent) makes it not worth it unless I'm towing something. If E85 were about 15%-20% cheaper, then it might be worth it, especially on a "plain old" normally aspirated engine that has the ECM tuning to handle the booze in the lines.
[1]: I have thought it is strangely amusing when people fight over the "cheap gas" pump at one of the gas stations with E85, and neither of their vehicles are Flex-Fuel rated.
If I want E0 gas here in Texas, I have to pay for a fuel company to set up an above ground tank on property and pay in increments of hundreds of gallons.
I would love E0 gas. E10 doesn't help generator or small engine life in any way whatsoever. It also kills gasoline life because the ethanol sucks water from the air, which causes gas to get bad quicker. Preservatives like Sta-Bil help, but even with that, one really can't store E10 past 6 months without risking fouling up carbs.
What Android needs a permissions model similar to BlackberryOS or iOS 6/7. First time a device requests something, a dialog pops up. That way, if an app asks for the world with permissions, one can do more than allow or deny.
There used to be an app pre-4.2 that would help with this, LBE Privacy Guard. It could be configured so if an app asksed for contacts, it would receive them... made up garbage. Same with locations and texts. That way, an app can have a lot of permissions, but wouldn't be able to do much damage. However, the successor of this app is Chinese only, so unless one tries for a translation from xda-developers, they are out of luck.
Android's permission model is a good one. If one rejects the fleshlight app asking for everything including superuser access, it works well. However, the Apple model of having a brutal gatekeeper on the App Store has fared a lot better. Perhaps Google should split their store into two tiers. One tier is similar to Amazon's store where anything residing is actively checked, and restrictions put on. The second tier is the Play Store as it is now. Then, by default, phones only access stuff on the first tier, but after a warning about permissions, can get to apps on the free-for-all level.
I can see this selling to rednecks. Even they are going solar as opposed to having to deal with the grid.
A Tesla truck has a lot of nice advantages that would be useful, especially for rednecks:
1: Max torque at 0 RPM. This can be extremely handy.
2: No fuel needed, which is a good thing as there is a growing off-grid mentality. Even if the truck trickle charges on a 120VAC, 20A connection via a set of solar panels, it still will be useful. With a larger solar or wind array, a 440VAC charger can be used. Of course, with a redneck, they just sling a generator in the back if worried about range.
3: There is also a very useful feature of an electric pickup truck. Stick an inverter on the batteries, and you have a very large battery for running electric equipment and no obnoxious generator noise.
4: There are times when one idles a pickup truck due to needing heat or A/C. Idling an electric car takes up 0 fuel other than what is used for accessories.
I should have been clearer with my wording. Any firearm will rupture or fail if too high power a load is put in. It might not explode with pieces going everywhere, but it will render the firearm into modern art sculpture, even though the user would be unharmed because of the good engineering.
I'm sure someone will mention that a device that just has one shot in an airplane can mean more than an AR-15 on the ground.
Then there is the fact that some gangster may not really care about accuracy. For most things, pulling out any type of firearm on a victim will get the criminal the car, wallet, bag o' meth, or even a hostage.
Of course, this gives me a fear that the other shoe will fall -- DRM on 3D printers. I can see this implemented very easily:
1: No printer will function unless the pieces are signed by a third party that vets them for "non-gun" use. So, if someone has an object they want to make, the WRL file has to be uploaded, scanned, then downloaded with an authorized signature for it to be printed.
2: Printers would be registered and tags added to objects, similar to the yellow dots on color printers.
Put too hot a round into almost any firearm, be it plastic, metal, or whatever, and it will explode.
I think this is really a non-issue. The Liberator was a proof of concept more than anything else. Of course, the technology will get better, but the only way one would use a 3D printed plastic pistol is if they had no other recourse.
The real tests I'm curious about, would be the Solid Concept's 1911. I wonder how well sintered metal will take a high round count. Since the 1911 was made back when metal technology was fairly primitive, it might just be that the metal stereolithography (what 3D printing was called before it was called 3D printing) process is good enough. Plus, shooting a.45 round puts a lot more pressure on components than a.22 or.25.
A few years back, I remember a startup which had a card that was programmable with any magstripe ID, but instead of Bluetooth, it had a few small wires between the main handheld apparatus and the card itself.
It went over like a lead balloon, and I don't even remember the name of the contraption maker.
Intead, I'd much rather see the smartphone itself be the payment device using Bluetooth between it and the register [1]. The register sends a signed transaction, the device validates the signature and asks if you want to pay it, you tap a fingerprint or PIN code on your device, payment is confirmed, and one is on their merry way. Of course, there are still security loopholes (someone copies the app with the card repository, etc.) However, it isn't that much worse than an average piece of plastic with an easily forged magstrip.
[1]: Of course, the weakness would be the same as any CA based system... compromise the head CA, and all hell breaks loose, but it does get rid of skimmers as a potential attack, and those are far cheaper to make than hacking a SSL private key.
Me being cynical is some successor for Blu-Ray for movies. What it would have is a requirement for DRM timestamps to play them. Want to play a movie made in 2015? You need a TV made that year or newer. Buy movies from 2016? Time to hit the big box store for next year's set. Of course, TV set makers will promise that their 2014 model will be upgradable to 2015 year DRM... but will never happen.
We have encountered exactly this situation with TOR. TOR is quite cool to use, but there is a big difference between using it versus running an exit node.
It would be the same with a P2P program. If a couple nodes are brutally made examples of with criminal/civil actions due to other people's stuff coming out, said program will end up completely disused.
Most buildings have a core water chiller. It wouldn't be that hard to have a heat exchanger going to the fluid circulation system, then liquid cool every rack and item inside.
The big problem is engineering the valves and connectors. It would be nice for a leak or an improper connection to be detected, and a valve shutting off coolant until it is fixed. Having quick-connect connectors which will shut off coolant flow when disconnected is also imperative. The goal would be for an almost immediate disconnection if someone cut a hose, ideally both active valves that shut off if there is a leak, as well as check valves so coolant cannot move backwards, so as little coolant as possible gets lost if something gets punctured.
Linus has had to evolve. I remember the days where the Linux kernel project was more of an academic creation than anything else. Then money was thrown at it because it was used and proved itself on servers (especially Web servers early on), and what once was a kernel for a userland for college students and hobbyists became something that runs everything from mainframes to embedded processors.
I worry about what happens when Linus is not at the helm. Of all the things that we don't need large forks of is the kernel. Distros have enough incompatibilities as is, and forking the kernel would mean an application has to not just be tested and written for not just RedHat variants, Debian variants, etc... but kernel designs that differ as well.
What would be a good organization that could maintain the Linux kernel? Tough call.
I've wondered about that myself, however there would be grave ramifications of any decision coming out of planning. For example, should the kernel be a true microkernel with everything in a module, even security, location of drivers, who owns what, and so on.
Just planning a new kernel would take man-years because there are just so many issues. Just security threats alone are too great for any one person. It would probably take the NSA, GCHQ, China's MSS, FSB, ISI, and any other country's intel division's knowledge pooled together in order to hammer out something that is resistant to threats from the ground up.
Of course, then comes the userland. Too strange an environment, and people won't adopt it. Linux had the advantage of being able to get stuff ported to it from SVR4 based boxes as well as BSD stuff.
It would be nice to just throw everything out the window and go with a Harvard architecture, or perhaps one with well demarcated security domains. However, the hard part would be getting people to bother writing apps for it.
Wouldn't be impossible, but it would be an uphill battle.
I would agree some utilities have a point where they will be "complete"./bin/cat perhaps, or/bin/yes.
However, the one thing that keeps the Linux kernel from being "done" is the security race. The kernel will never be "complete" because of today's and tomorrow's security risks. Right now, Web browser (and add-ons) are compromises. It could be in the future that physical compromise and armed robbery of data centers would be a major threat, so the kernel would have to be modified to keep as much data as possible in memory encrypted (perhaps using a key stored in a protected register on a future chip), only decrypting what is needed.
If the Linux kernel were a true microkernel with the security stuff separate, then it might be the kernel could be considered "done". However, because of its structure, any security issues will always mean updates.
Security is a race you never win, only tie or lose. With this in mind, if the Linux kernel has development that gets stopped, it would mean that people would be moving to other platforms that would still keep abreast of the latest threats.
Second to security are drivers and new hardware, and things that came up not considered before. For example, ten years ago, few would think a USB flash drive would register as a HID and try to type commands when plugged in. Similar with IEEE1394 and possibly Thunderbolt and DMA RAM dumping. A kernel might be secure, but along comes a device used in a new and brutal way, and an update will need to be done to keep things secure.
Finally, architectures change. We might end up having cores that are purely FPGAs in the near future, so security sensitive code is executed on a Harvard architecture, then the FPGA changes back to the single data/code path. With architecture changes come kernel changes.
So, of all the things in computing, a modern OS kernel is the last thing that will ever be considered "complete" unless it is completely wrapped in another layer, similar to a hypervisor.
There are a lot of cloud providers, but what would be nice is a standard on client-side encryption and key management [1], regardless of what cloud provider destination. That way, if I'm sending files to Dropbox, S3, Glacier, RH's cloud, Azure, or another provider, all I have to do is change out the name and authentication info, not have to use a completely different API. This would also allow me to have redundant cloud storage for vital documents, automatically retrieving a document even if one of the providers is offline.
[1]: Key management is just as important as encryption, but it is something that gets forgotten about until a disaster, and one has a nice pile of tapes... but no way to decrypt them.
I wonder how useful it would be for security sensitive applications. For example, even though it sounds goofy to run a Web browser in a Linux kernel running in a window, the difficulity for malware to get out of rings of context (including multiple instruction sets) would be enormous. Not impossible, but highly unlikely.
Something like this would provide a decent defense against browser-based (or browser add-ons) attacks (which is a significant vector for malware these days.)
I copy/paste bookmarks to a different file, so that really isn't an issue. Cached sessions are not a worry either. In fact, being able to dump all state, no matter how much identifying info is left behind is a win for privacy.
Slashdot Mirror
It depends on where the "brains" are. Facebook (IIRC) has the redundancy on the backend app layer where coupled with NoSQL, if something drops... there is some redundancy built in somewhere to pick it off, or drop a couple tuples, but the tables still have their integrity. Whole servers can drop off the map, and Facebook will keep going. Isn't pretty, but their model really can handle stuff getting tossed here and there.
Apple, on the other hand, uses Teradata systems with NetApp appliances on the backend, so one large cloud provider does go with the more traditional storage stack model found in the enterprise. However, unlike losing a FB post or two, a user losing chunks of their data would not be a good thing, so Apple's model tends to be more rigidly ACID compliant.
Encryption schemes are important, but whenever someone mentions "let's encrypt it", I cringe.
Encryption isn't some magic switch that you turn on and all your data is 100% secure from bad guys. What happens is that it makes a smaller chunk of data (i.e. the key or keys) the valuable part.
Key management isn't a cookie-cutter thing. Error on security, and your data can't be recovered. Error on accessibility, and the bad guys now have your keys and can get your data.
A small company can get by with burning an archival CD-ROM, as well as printing out all keys (passwords especially, but .asc files of private keys as well [1]) A bigger company would have recovery info be split up among corporate officers in a "x out of y" structure (where 3 out of 5 officers are needed to regenerate the master key.) Even larger companies would have regional managers, and far more exotic key management layouts with multiple recovery paths.
If Yahoo decides to just "encrypt it", they need to put in a good key management structure in place... and of course, that will be the prime target for bad guys [2], so it has to be worth the security payoff of keeping the eggs in one basket.
[1]: Yes, it will be hell and a half to retype in, but it will be there. Having archival media on a CD helps with that, but if bit rot nails the CD, there is always the paper copy.
Oh, and don't try utilities which print bitmaps to paper like Paperbak. I've had great look in printing them out... but scanning them in and recovering any data... absolutely zero luck whatsoever, so don't bother with those utilities as of now.
[2]: The NSA is hyped, but one major threat are blackhats who would love access to Yahoo's assets for blackmail, DDoS, extortion, or to find other people to attack.
Only difference is that we have no Retief...
For a lot of things, the threat of having the device bricked is overblown.
The only time that I've ever been worried about bricking was on the Motorola Atrix 2 when initially, there was no FXZ or other way to reflash back to a stock ROM. Eventually this was remedied, but for a whole, the modding community for that device was walking a tightrope without a safety net.
This doesn't say that one can't brick a device, as it is doable, especially if one misses some directions or skips steps, but it isn't as common as people think.
I can spend $10 and get a T-Mobile SIM plus some prepaid minutes.
In fact, if I'm doing Craigslist transactions, I use a burner phone, and when done, destroy the SIM card [1] and get a new one. That way, after I buy/sell something, I'm not dealing with all the fraudsters who have sons on oil rigs or are willing to send me $50,000 cashiers checks.
I avoid CDMA providers, because if one wants a new number, the whole phone has to be destroyed or recycled. However, once done with the phone, handing it to the nearest street corner hobo pretty much does the same thing (and here in Austin, we envy Santa Cruz for their lack of aggressive homeless population, which says something.)
[1]: Takes only a few times to lock out the PIN, around 20 to fry the PUK, then the card hits a fine-grained shredder.
Google is to be respected there. In the past, I've encountered many businesses that, at best, provide lip service, at worst, have nothing whatsoever.
Almost every business should have some form of key management solution in place, even if it is a printed out piece of paper with all the BitLocker recovery codes stashed in a couple safe deposit boxes. Of course, if some antagonist is big enough, a safe deposit box can be frozen or seized, so for some organizations, that isn't a wise idea.
I just wish USB cryptographic tokens were more widespread. There were some out of Germany that would work with gpg, but they are sold out, and no clue when they might start production again. For example, having tokens in the hands of corporate officers (including the CIO and CTO) then having a tarball of all the other critical keys stored with the corporate data would be an idea. If one of the tokens is still usable, the rest of the key infrastructure would be recoverable, although if one of the tokens gets lost or stolen, the damage would be enormous. One can go with share split systems (e.g. 3 out of 5 keys needed) to help mitigate that.
Encrypting is useful, but then comes the very nasty thing that comes with it: Key management.
Key management is something people fail to think about after the "Encrypt it, encrypt it now!" statement is implemented. How are keys stored, who has access to them. You have to sail your way between the Scylla of having keys obtainable by the bad guys, versus the Charybdis of a disaster causing all data to be forever inaccessible.
Of course, there are plenty of guys who will sell you an encryption appliance that supposedly will handle all this for you. But upon asking, the only way to back up the appliance is to install another appliance... and the only way to back that up. Yep, you guessed it, yet another appliance for replication.
Take backup media for instance. You can buy exotic tools to lock it down many ways. Or, you can set a password via Diceware, have it in a physical notebook with multiple copies (tape safe, offsite), and every year or two, change to a new one while keeping the old one for new tapes. It may not be as snazzy as encrypting each piece of media with its own key, but it provides virtually the same security.
Or another item are LUNs from a SAN. Yes, you can encrypt them, but what happens if/when the host machine goes down... where are the backup keys so the machine can be rebuilt?
Oh, the CA keys. Are they stashed in an armored HSM, or just generated/signed/used on some machine that can be compromised by just walking to it?
All important things to consider.
In Brazil, I wonder if generator and small engine makers make their products so they can handle E100.
The reason why that would be nice to have is that one could get a fuel distiller's permit, then build a still to ferment by-products from a farm to use for fuel.
If it is useful there, the same technology would be useful here in the US, and ethanol is a lot poisonous than gasoline. Nobody would deliberately drink gasoline, but pure ethanol in various dilute concentrations? Very common. Just look around any university area.
I should do objective performance and MPG tests on E85 because my current vehicle can use the stuff [1]. There is a small horsepower increase, but the loss of MPG (which I would guesstimate around 20 percent) makes it not worth it unless I'm towing something. If E85 were about 15%-20% cheaper, then it might be worth it, especially on a "plain old" normally aspirated engine that has the ECM tuning to handle the booze in the lines.
[1]: I have thought it is strangely amusing when people fight over the "cheap gas" pump at one of the gas stations with E85, and neither of their vehicles are Flex-Fuel rated.
If I want E0 gas here in Texas, I have to pay for a fuel company to set up an above ground tank on property and pay in increments of hundreds of gallons.
I would love E0 gas. E10 doesn't help generator or small engine life in any way whatsoever. It also kills gasoline life because the ethanol sucks water from the air, which causes gas to get bad quicker. Preservatives like Sta-Bil help, but even with that, one really can't store E10 past 6 months without risking fouling up carbs.
What Android needs a permissions model similar to BlackberryOS or iOS 6/7. First time a device requests something, a dialog pops up. That way, if an app asks for the world with permissions, one can do more than allow or deny.
There used to be an app pre-4.2 that would help with this, LBE Privacy Guard. It could be configured so if an app asksed for contacts, it would receive them... made up garbage. Same with locations and texts. That way, an app can have a lot of permissions, but wouldn't be able to do much damage. However, the successor of this app is Chinese only, so unless one tries for a translation from xda-developers, they are out of luck.
Android's permission model is a good one. If one rejects the fleshlight app asking for everything including superuser access, it works well. However, the Apple model of having a brutal gatekeeper on the App Store has fared a lot better. Perhaps Google should split their store into two tiers. One tier is similar to Amazon's store where anything residing is actively checked, and restrictions put on. The second tier is the Play Store as it is now. Then, by default, phones only access stuff on the first tier, but after a warning about permissions, can get to apps on the free-for-all level.
I can see this selling to rednecks. Even they are going solar as opposed to having to deal with the grid.
A Tesla truck has a lot of nice advantages that would be useful, especially for rednecks:
1: Max torque at 0 RPM. This can be extremely handy.
2: No fuel needed, which is a good thing as there is a growing off-grid mentality. Even if the truck trickle charges on a 120VAC, 20A connection via a set of solar panels, it still will be useful. With a larger solar or wind array, a 440VAC charger can be used. Of course, with a redneck, they just sling a generator in the back if worried about range.
3: There is also a very useful feature of an electric pickup truck. Stick an inverter on the batteries, and you have a very large battery for running electric equipment and no obnoxious generator noise.
4: There are times when one idles a pickup truck due to needing heat or A/C. Idling an electric car takes up 0 fuel other than what is used for accessories.
5: Less noise and smell... easier on animals.
I should have been clearer with my wording. Any firearm will rupture or fail if too high power a load is put in. It might not explode with pieces going everywhere, but it will render the firearm into modern art sculpture, even though the user would be unharmed because of the good engineering.
I'm sure someone will mention that a device that just has one shot in an airplane can mean more than an AR-15 on the ground.
Then there is the fact that some gangster may not really care about accuracy. For most things, pulling out any type of firearm on a victim will get the criminal the car, wallet, bag o' meth, or even a hostage.
Of course, this gives me a fear that the other shoe will fall -- DRM on 3D printers. I can see this implemented very easily:
1: No printer will function unless the pieces are signed by a third party that vets them for "non-gun" use. So, if someone has an object they want to make, the WRL file has to be uploaded, scanned, then downloaded with an authorized signature for it to be printed.
2: Printers would be registered and tags added to objects, similar to the yellow dots on color printers.
Put too hot a round into almost any firearm, be it plastic, metal, or whatever, and it will explode.
I think this is really a non-issue. The Liberator was a proof of concept more than anything else. Of course, the technology will get better, but the only way one would use a 3D printed plastic pistol is if they had no other recourse.
The real tests I'm curious about, would be the Solid Concept's 1911. I wonder how well sintered metal will take a high round count. Since the 1911 was made back when metal technology was fairly primitive, it might just be that the metal stereolithography (what 3D printing was called before it was called 3D printing) process is good enough. Plus, shooting a .45 round puts a lot more pressure on components than a .22 or .25.
A few years back, I remember a startup which had a card that was programmable with any magstripe ID, but instead of Bluetooth, it had a few small wires between the main handheld apparatus and the card itself.
It went over like a lead balloon, and I don't even remember the name of the contraption maker.
Intead, I'd much rather see the smartphone itself be the payment device using Bluetooth between it and the register [1]. The register sends a signed transaction, the device validates the signature and asks if you want to pay it, you tap a fingerprint or PIN code on your device, payment is confirmed, and one is on their merry way. Of course, there are still security loopholes (someone copies the app with the card repository, etc.) However, it isn't that much worse than an average piece of plastic with an easily forged magstrip.
[1]: Of course, the weakness would be the same as any CA based system... compromise the head CA, and all hell breaks loose, but it does get rid of skimmers as a potential attack, and those are far cheaper to make than hacking a SSL private key.
Me being cynical is some successor for Blu-Ray for movies. What it would have is a requirement for DRM timestamps to play them. Want to play a movie made in 2015? You need a TV made that year or newer. Buy movies from 2016? Time to hit the big box store for next year's set. Of course, TV set makers will promise that their 2014 model will be upgradable to 2015 year DRM... but will never happen.
We have encountered exactly this situation with TOR. TOR is quite cool to use, but there is a big difference between using it versus running an exit node.
It would be the same with a P2P program. If a couple nodes are brutally made examples of with criminal/civil actions due to other people's stuff coming out, said program will end up completely disused.
Most buildings have a core water chiller. It wouldn't be that hard to have a heat exchanger going to the fluid circulation system, then liquid cool every rack and item inside.
The big problem is engineering the valves and connectors. It would be nice for a leak or an improper connection to be detected, and a valve shutting off coolant until it is fixed. Having quick-connect connectors which will shut off coolant flow when disconnected is also imperative. The goal would be for an almost immediate disconnection if someone cut a hose, ideally both active valves that shut off if there is a leak, as well as check valves so coolant cannot move backwards, so as little coolant as possible gets lost if something gets punctured.
Linus has had to evolve. I remember the days where the Linux kernel project was more of an academic creation than anything else. Then money was thrown at it because it was used and proved itself on servers (especially Web servers early on), and what once was a kernel for a userland for college students and hobbyists became something that runs everything from mainframes to embedded processors.
I worry about what happens when Linus is not at the helm. Of all the things that we don't need large forks of is the kernel. Distros have enough incompatibilities as is, and forking the kernel would mean an application has to not just be tested and written for not just RedHat variants, Debian variants, etc... but kernel designs that differ as well.
What would be a good organization that could maintain the Linux kernel? Tough call.
I've wondered about that myself, however there would be grave ramifications of any decision coming out of planning. For example, should the kernel be a true microkernel with everything in a module, even security, location of drivers, who owns what, and so on.
Just planning a new kernel would take man-years because there are just so many issues. Just security threats alone are too great for any one person. It would probably take the NSA, GCHQ, China's MSS, FSB, ISI, and any other country's intel division's knowledge pooled together in order to hammer out something that is resistant to threats from the ground up.
Of course, then comes the userland. Too strange an environment, and people won't adopt it. Linux had the advantage of being able to get stuff ported to it from SVR4 based boxes as well as BSD stuff.
It would be nice to just throw everything out the window and go with a Harvard architecture, or perhaps one with well demarcated security domains. However, the hard part would be getting people to bother writing apps for it.
Wouldn't be impossible, but it would be an uphill battle.
I would agree some utilities have a point where they will be "complete". /bin/cat perhaps, or /bin/yes.
However, the one thing that keeps the Linux kernel from being "done" is the security race. The kernel will never be "complete" because of today's and tomorrow's security risks. Right now, Web browser (and add-ons) are compromises. It could be in the future that physical compromise and armed robbery of data centers would be a major threat, so the kernel would have to be modified to keep as much data as possible in memory encrypted (perhaps using a key stored in a protected register on a future chip), only decrypting what is needed.
If the Linux kernel were a true microkernel with the security stuff separate, then it might be the kernel could be considered "done". However, because of its structure, any security issues will always mean updates.
Security is a race you never win, only tie or lose. With this in mind, if the Linux kernel has development that gets stopped, it would mean that people would be moving to other platforms that would still keep abreast of the latest threats.
Second to security are drivers and new hardware, and things that came up not considered before. For example, ten years ago, few would think a USB flash drive would register as a HID and try to type commands when plugged in. Similar with IEEE1394 and possibly Thunderbolt and DMA RAM dumping. A kernel might be secure, but along comes a device used in a new and brutal way, and an update will need to be done to keep things secure.
Finally, architectures change. We might end up having cores that are purely FPGAs in the near future, so security sensitive code is executed on a Harvard architecture, then the FPGA changes back to the single data/code path. With architecture changes come kernel changes.
So, of all the things in computing, a modern OS kernel is the last thing that will ever be considered "complete" unless it is completely wrapped in another layer, similar to a hypervisor.
There are a lot of cloud providers, but what would be nice is a standard on client-side encryption and key management [1], regardless of what cloud provider destination. That way, if I'm sending files to Dropbox, S3, Glacier, RH's cloud, Azure, or another provider, all I have to do is change out the name and authentication info, not have to use a completely different API. This would also allow me to have redundant cloud storage for vital documents, automatically retrieving a document even if one of the providers is offline.
[1]: Key management is just as important as encryption, but it is something that gets forgotten about until a disaster, and one has a nice pile of tapes... but no way to decrypt them.
I wonder how useful it would be for security sensitive applications. For example, even though it sounds goofy to run a Web browser in a Linux kernel running in a window, the difficulity for malware to get out of rings of context (including multiple instruction sets) would be enormous. Not impossible, but highly unlikely.
Something like this would provide a decent defense against browser-based (or browser add-ons) attacks (which is a significant vector for malware these days.)
I copy/paste bookmarks to a different file, so that really isn't an issue. Cached sessions are not a worry either. In fact, being able to dump all state, no matter how much identifying info is left behind is a win for privacy.