You are not the only one. I much rather have buttons on a bookreader, especially for page turning, and not have to worry about fingerprints. The Kindle is a decent form factor for holding like a novel.
The Kindle is a bookreader. Having Web browser functionality is nice, because sometimes clicking on a link in text to do something may prove fruitful.
However, if the Kindle turns into a touch screen tablet, it will just be a face in a herd, and lose the usefulness that made it a sellout item in the first place. We have a ton of touch screen tablets.
What Amazon should do instead is get the Kindle to work with the epub format, add a SD card slot, so if someone wants 32 GB, they can have it. Since Amazon also has a decent cloud store, why not offer to stream/download from that as well? This doesn't need anything fancy on the screen, although AT&T may not like Whispernet being used for this.
Amazon should not lose what makes the Kindle great, and that is the ease of reading books with it, regardless of light. If they make the Kindle into another tablet, they will lose their market because they will be just another generic iPad competitor.
Make it out of beryllium then. Problem solved. If it wasn't for that toxic property, beryllium would be a great lightweight metal to use in a lot of things.
That depends, on what people mean by 4G. This can be very blurry due to the marketing hype spewed by the cellular companies.
My HTC Inspire 4G has HSPA+. Doesn't mean it is faster than 3G, but supposedly it will be when HSPA+ gets out there to the towers.
Technically, if one defines 4G as a medium that sends everything via the data stream, as opposed to voice/data, only newer Verizon and Sprint phones may be truly 4G. However, one can get similar speeds from HSPA+ depending on area.
That is what the OS is for. Of course, the dancing bunnies problem affects all platforms regardless of being Harvard, Von Neumann, or otherwise, but moving to this means that stack smashing attacks become a thing of the past.
We can't stop anything and everything, but if we start from the basics and limit the attack vector of stack smashing attacks, as well as the dancing bunny problem, it will mean that the attack surface of a machine is quite diminished.
To keep people from allowing stuff mindlessly, that is what repositories are for. If we can train users that a program that isn't installing via a repository is a very bad thing outside a developer environment, and combine that with techniques to harden web browsers and the add-ons, 99% of our job is pretty much done. Of course, there will be new threats (perhaps bugs in the IPv6 stack, CPU bugs, etc.), but stomping out the biggest problems would mean that blackhats would actually have to actively work to gain access.
It uses hard linking as the secret sauce. Backups with one file that stays static just drop a link. If the file is changed, you will find the actual file in the directory.
All and all, a pretty clever system. Only downside is having to make sure you strip the Locked bit if you manually restore data.
I prefer having a dedicated backup server pull data from machines as opposed to having machines save to a NAS, just because if a box gets infected, it can easily scrozzle the NAS, while its damage to a backup server would be minimal.
Perhaps Symantec should have a NetBackup appliance for home users?
It is a pipe dream, but it would be nice if a Senate committee decided to address the issues and actually do something relevant to national security.
Just having an organization similar to the FDIC which would step in and deal with the data from a defunct cloud provider would go a long ways for national security.
Cloud providers, especially Apple's iCloud, are big, fat, juicy targets for blackhats just because of the sheer amount of actionable intelligence gained. Most people may not care if Johnny's school is going to a soccer game, but it might be something that a local gang may love to know, so they know who is away from their houses and when.
A committee means one thing -- more laws. We all know about the bad laws that can be passed (more DRM, tossing some guy who logs on as his ex on FB in prison for 50 years, etc.) However, maybe some good can come out of it:
1: Money spent to have on staff more blackhats/whitehats. Perhaps we need another branch of the Armed Services just dedicated to intrusion prevention and hardening?
2: Certifications for cloud providers. This would include the government stepping in and either erasing or physically destroying all the cloud storage media if the provider got shut down, went bankrupt, got sold to a foreign company, etc. This way, even if the company tanked, all client data would be destroyed, so unlike now, the client data can't just be handed to the next owner of the servers for them to do what they want. The certifications would also include physical inspection, network inspection, host inspection, process inspection, tiger team testing, etc. We do this with hardware and software (FIPS, Common Criteria, EAL), why not cloud computing?
3: Funding for US fab technology for sensitive components like TPMs, firewalls, and other items. This way, there is solid knowledge that an Elbonian backdoor isn't waiting for just the right time to shut down a router or allow intruders in.
4: Funding for a B2B backbone infrastructure where it is preplanned what machines communicate to each other. This way, a bank's computer can send info to a credit card processor, but can't send anything to a baseball card shop unless they have a prior relationship. Preferably have this on separate fiber than the regular Internet. This way, critical business items can be isolated from Internet escapades. Think NIPRNet or SIPRNet, but for businesses.
5: Funding to work on a standard like VNC/Citrix/MS Terminal Server, so that people traveling do not require physical access to data, just access to a terminal server. This way, a blackhat has to compromise a locked down terminal server before they can get to the juicy stuff like Exchange or the like.
6: Grants to universities for better OS and hardware security models. Some computers used to have two addresses for RAM, one just for data, one instructions, and never did they meet. Things like that would be transparent to the user, but would greatly increase security. Same with operating systems that could hand Web browsers privileges by window/tab, so that a compromised tab couldn't get to the tab right by it that the user is doing banking with. Designing machines from the ground up to treat all Web content as hostile would greatly reduce the amount of malware floating around, just like firewalls have reduced incoming attacks.
7: A hardened device for storing passwords similar to a HSM for public keys. This would be extremely useful in LDAP setups as well as websites that have user accounts. A hacked server does not mean wholesale user compromise.
8: A standard TPM that can be added to all computers, but may or not be present. This would allow computers to have a TPM card dropped in if someone wanted it, but it wouldn't present, so the DRM writers couldn't force gamers to use it for additional lockdown.
9: Funding to design a standardized filesystem/LVM similar to ZFS, except that it is not patent encumbered, and can be used by all and sundry, either with all features, or a subset. The only filesystem across platforms these days is either FAT/FAT32, or the CD-ROM format. The reason this would increase security is that tools that can be used on many platforms can identify issues and fix them, especially at the LUN level (pop a snapshot of a LUN, have the SAN scan for viruses to find rootkits that the infected machines can't detect.)
These may be expensive, but at least some of the stuff would at least help things in a substantial manner. Passing more laws with longer prison terms will do jack squat for security overall, except make the private prison owners richer. You have to fight technical battles with technology.
Scalability: Depends. Some things may scale like putting files for download with Akamai. Other things, not so much. The cloud is a tool in the architect's toolbox.
Admin payroll: Someone is going to need to architect things, so you will still have an IT department, if only to maintain your internal network links, and make sure the desktop PCs don't become botnet clients. Don't forget networking. You will need to have those fat pipes to access the cloud provider, so you will still need a space for those Cisco Nexus 7000 boxes with the clear covers.
Guarenteed SLAs: Read the contract... the SLA may not be as good as people think it might be.
Oh, and if the cloud provider goes bankrupt, the data on their servers is free for the taking by anyone who so desires. Even though it is SOP for auctions to wipe the drives, this gets forgotten or "forgotten". Promises mean nothing when some competitor in Elbonia now has your payroll (sold your employees' info to ID thieves), your client list (and is offering the same services for 50% less), your source code (with a version of your product that is exactly the same except in name), your suppliers (which are then harassed to make better deals elsewhere), and others.
No recorded breach with a cloud provider... time will tell on this one. Nothing is 100% secure. Gmail has had people report incidents, Dropbox has had the security tokens that people talked about, and so on.
No server room? I'm sorry, but even with "economies of scale", you are either paying for a data center in house, or you will be paying for one somewhere else. Don't forget regulations about physical security of data.
DB/OS versions? Sure. However, if something breaks your app's code due to an update done without notice, there is no way to roll back. ITIL 101 here.
Exchange versions? See above.
Don't assume the cloud provider has backups automatically. If someone logs on as an admin with a cloud provider and blows all your storage away, it may not be recoverable, while the old LTO-5 tape library will be able to restore data. When push comes to shove, and in some industries, you better retain data for a while (up to 50 years if dealing with the FAA), you need to pack your own parachute. I trust tape, and moving archived data to the latest archival version every couple years far more than a cloud provider's promise. However, I'm one of those "IT guys" that the parent apparently dislike, so if someone wants to be fast and loose with their data, they can store it on the cloud and assume that their storage has all the snapshot features of the EMC SAN they want to chuck.
Cloud computing is a useful tool. It won't replace server rooms anytime soon. Maybe I'm a fossil, but I rather trust a VTL, replicated SAN, or even good old fashioned tape far more than I would trust just an assurance that a cloud provider has my data backed up.
I wish phonebookFS was still being worked on. It would be great for just exactly this.
I used to use it with a FUSE driver to use Gmail as a filesystem. This way, I could grab out documents for college, personal files, files related to consulting, each of which being separate from each other. The gmail side only saw a bunch of files, some of which could be just chaff and not decrypt-able in any way.
This has been discussed on the TrueCrypt forums at length.
Any forensic person who can understand the difference between a dead body and an iPad will be whipping out the hardware write blocker, making a VMWare image, and working on that. If they fail to do that, it is SOP that any evidence gleaned from the machine can be tossed out the window in most US courts. A password that causes a self-destruction action is nullified with just a rollback from a snapshot, and might add either charges like destruction of evidence.
With the Sony Network Walkman players, it was the same thing. The first generation which used a Magic Gate Memory Stick required transcoding. The second generation wrapped the MP3 format with encryption.
Even more annoying was the fact that you couldn't copy music to it; you checked it out. If you formatted the player and didn't check the music back in, there was a high chance that you would have to re-scan/re-buy the tracks, as some Network Walkman players would check back in erased tracks, others wouldn't.
Because of the in-your-face and annoying DRM, Sony in effect ceded the MP3 player market to Apple, which in later iPod releases had FairPlay DRM, but it would not be as annoying constantly as the old OpenMG software.
A.secure domain on the same physical net is one thing. However, what we really need are separate backbones designed from the ground up to carry traffic.
The US has NIPRNet and SIPRNet. Ideally, it would be nice to see banks and credit card processing places have a "BIPRNet" just so that machines from bank "A" can contact bank "B" via a secure link, preferably a separate physical wire than what the traffic from the outside runs on. This way, a blackhat would have to find a machine that sits on both networks, and go from there. If the network backbone is set up to allow communications only between machines that have a business need to see/connect to each other, it would make that backbone quite secure. Add an IDS/IPS system will make compromise even more difficult.
Same with SCADA stuff. It needs its own backbone, then hardened computers that relay the diagnostic info from the embedded controllers to where it needs to be. I've even used two machines that were connected to each other via a one way serial port (slow link, but it worked getting the small datasets across, and one tx/rx pair was disabled so data could only move from the inner network to the outer) to ensure that the inner embedded network would require physical access to be compromised.
Good internet security is not a matter of "can't". It is a matter of "won't".
FB architected themselves around cheap. Lots of cheap x86 boxes and have the backend application deal with failing servers.
In reality, FB should have considered moving to "big boy" hardware. Since they use MySQL, why not go with full blown Oracle clusters on SPARC M-Series with a decent EMC SAN? Backups are fairly easily done with replication and snapshots, with a tape library to store archives of the build tree. User data can happily remain on a deduped filesystem while business critical stuff like tax records can sit on disk, as well as get saved to tape.
Moving to Oracle also gives the benefit of being able to have the best RDBMS tool selection out there from a mom and pop shop all the way to multi-terabyte databases sitting on SSDs used at banks for 24/7/365 transaction processing.
IBM is another possibility. Upper end POWER7 boxes only need a few CPU and I/O drawers and have the I/O buses that can handle the load FB has. They can use Oracle on this platform, or use DB/2's new oracle compatibility mode and move to that. IBM has a decent AIX/POWER7/DB2 compatibility stack which can load-balance quite effectively.
Or, if FB was willing to reorganize, a couple IBM zSeries and a decent backend storage device (DS8000, EMC's Symmetrix or Celerra series) could sit in a fairly small data center, doing all the work that the tons of x86 boxes do for far less energy used and cooling.
I wonder how much money FB would save had they built their redundancy lower in the hardware/software stack as opposed to having their backend app do all the work? Of course, there is the understandable fear of being locked into a platform... but isn't this the issue with MySQL now? Better to be married to a platform that can scale than one that has been shown to require gymnastics to get it working on the level that FB needs.
Austin has a few roundabouts. However, I dread them highly. One is places on a two way street with no third intersection (Riverside drive). Normally this wouldn't be an issue, but when I go that route, I encounter:
1: People staying in the roundabout and gunning it in order to cause a wreck with merging traffic.
2: People going the wrong way on the roundabout. Yes, I know this sounds crazy, but it isn't that uncommon for someone to be trying to go the wrong way and cause a head on wreck.
3: People who just stay in the roundabout driving around and around like National Lampoon's European Vacation and prevent others from merging on. This is extremely common in the smaller traffic circles where two vehicles do this just to deny access until the drivers get bored or dizzy.
Roundabouts work if drivers have some IQ. That isn't the US, so it is safer to just have a red light which turns to flashing red at the off hours.
Take a scenario where some drunk decides hit a semi, causing it to crash into a median, which is all too common on I-35. Even when the wreck is cleared, it will take 30-45 minutes to traverse it. Add the fact that the car is likely around 1/2 or 2/3 charge from coming home, and there is a good chance of the vehicle running out of juice, even though it barely moves at idle.
These things are not road-worthy. It means that we will have more stalled cars that have to wait for the tow trucks, and this could be fatal during an evacuation.
We don't need gimmicks. Want to know what the US really needs on the roads? Turbo diesels. They have an obscene MPG, are tried and true, and have a standard range of fuel. MSRP? $26,065 will get you a TDI with a decent navigation system. MPG? Easily in the 30s, even with driving it like you stole it.
Want hybrids? Sure. Stick a battery pack in a turbo diesel, or even just a beefed up starter motor that can move the vehicle short distances so the car's main engine can be off in low speed traffic, saving at least 10% of fuel costs, far more on fleet vehicles that idle.
Car makers need to start making what consumers need and are useful. Yes, an all electric car is cute, but we do not have the infrastructure for it, and we likely will not for 20-50 years. Most places where people might park may not have electricity available, much less to charge cars. (With a lot of employers, just receiving a paycheck is likely the most one can expect from them, much less amenities like parking or a juice hookup.) Electric cars are not practical now. This doesn't mean hybrid electric cars are not (like the Volt), but pure electric just doesn't have much use for most people, especially if they need to make that unplanned trip.
It is sad, but there are a lot of cases where this is the truth:
DVDs -- disabling the PUO crap, so one doesn't have to sit through 45 minutes of previews for movies that flopped.
Games -- playing games that will not activate because the activation servers have been taken offline, or continuing to play a game after a video card was changed out, and the game will not activate.
Applications -- being able to continue use of a program even after hardware has been changed (RAM upgrade).
The best DRM for games is the simplest -- have a serial number to access multiplayer servers. This worked for almost a decade for NWN1. It keeps the freeloaders at bay, while ensuring that legit users have as good a gaming experience as possible.
Not really... Farmers have to compete with large agribusinesses that have access to patented crops that grow with fewer resources spent. Larger businesses have economies of scale on their side.
Trying the "organic" route might work, but there are only so many farmer's markets, so trying to compete against large businesses who can flood the market with dirt cheap crops is becoming more and more difficult.
Farmers are becoming an endangered species. Especially due to the fact that land is becoming more and more valuable, even if the farm is just passed from speculator to speculator.
The second part is that USENET was initially populated by professionals. Either college students, college professors, or people who worked at a "serious" job.
Also, reputation came into play. Relatively few people had anonymous handles, so if someone was jacking around, their name was on what they did.
I am showing my age, but I do miss the days before Eternal September.
The key is if the TPM gets "sealed" before or after the infection. After, you are screwed. Before, the modified MBR will be detected, because the PC in its pre-boot process will scan the MBR, make a MD5 hash of it, and pass it to the TPM. Even the most clever malware can't get past that, barring an infected BIOS flash or a compromised TPM.
We have the technology to deal with this -- the controversial TPM chip, which is around on a lot of hardware.
On Linux, an implementation to prevent MBR-based rootkits could be having at the minimum / encrypted, optimally every filesystem. Use a passphrase for recovery, so if the TPM fails, it isn't hard to just boot without it. This way, if malware does infect the MBR, it will get booted as far as the initial ramdisk and get stuck when the boot process asks for the key to the root volume and the TPM reports that there was tampering.
"Trusted" computing is controversial, but using a TPM in this context will significantly add to security.
Communism works on a small scale. When people are known and reputations matter, communism works.
However, the system will completely break down when people start realizing that they can take more than they give and not suffer consequences for their action.
The history of the Internet shows this -- before the C&S USENET spam, people tended to behave because all it took was a call to their sysadmin and they would be tossed off the net. After C&S, where it was shown that people could get away with breaking traditions and mores to score some cash, it was only a matter of time before the system of "put a server up to help out, and other people do similar" went the way of the dodo, eclipsed by doing what it takes to earn cash.
This is one reason why a TPM chip is a useful tool. It is present, but disabled in most servers.
Enable BitLocker, make sure to save the recovery key somewhere safe (preferably printing it out as well), have it use the MBR, and call it done.
If malware nails the MBR after BitLocker gets turned on, the machine will not boot. One can use Windows PE, mount the system volume with the recovery key, and squash the malicious software that way.
The main concern is that a USB flash drive can also register than more than just a mass storage device:
1: It can register as a keyboard and start typing in text. Ad services use this so when someone jams their device in, it autoruns and pops up a web browser. Malicious ones tend to do worse things.
2: It can register as other devices. The problem is with the USB protocol, when in the past it just used to be a . It would be nice to have a "dumb" protocol that doesn't allow devices to read from host memory (which is why serious forensics people use a FireWire device for dumping RAM) and that is just made for mass storage devices. SCSI was nice for this... perhaps the best storage protocol for drives that might have unknown data would be FC or FCoE [1]. Optical would be ideal, as a drive couldn't overvoltage and fry the connection.
[1]: I really wish computer makers would add CNA ability to network adapters on motherboards. FCoE is an ideal protocol for a home NAS.
You might be surprised. There are some thin insulation types that one can use in cars, RVs, and other places that do an excellent job. Aerogels used as insulation are extremely useful (Thermoblok is one brand with 10.3 per inch of insulation for the R-value). combine that with reflective Mylar, and it becomes an ideal insulator for RVs and such.
The key is getting this technology into combat theaters.
Slashdot Mirror
You are not the only one. I much rather have buttons on a bookreader, especially for page turning, and not have to worry about fingerprints. The Kindle is a decent form factor for holding like a novel.
The Kindle is a bookreader. Having Web browser functionality is nice, because sometimes clicking on a link in text to do something may prove fruitful.
However, if the Kindle turns into a touch screen tablet, it will just be a face in a herd, and lose the usefulness that made it a sellout item in the first place. We have a ton of touch screen tablets.
What Amazon should do instead is get the Kindle to work with the epub format, add a SD card slot, so if someone wants 32 GB, they can have it. Since Amazon also has a decent cloud store, why not offer to stream/download from that as well? This doesn't need anything fancy on the screen, although AT&T may not like Whispernet being used for this.
Amazon should not lose what makes the Kindle great, and that is the ease of reading books with it, regardless of light. If they make the Kindle into another tablet, they will lose their market because they will be just another generic iPad competitor.
Make it out of beryllium then. Problem solved. If it wasn't for that toxic property, beryllium would be a great lightweight metal to use in a lot of things.
That depends, on what people mean by 4G. This can be very blurry due to the marketing hype spewed by the cellular companies.
My HTC Inspire 4G has HSPA+. Doesn't mean it is faster than 3G, but supposedly it will be when HSPA+ gets out there to the towers.
Technically, if one defines 4G as a medium that sends everything via the data stream, as opposed to voice/data, only newer Verizon and Sprint phones may be truly 4G. However, one can get similar speeds from HSPA+ depending on area.
That is what the OS is for. Of course, the dancing bunnies problem affects all platforms regardless of being Harvard, Von Neumann, or otherwise, but moving to this means that stack smashing attacks become a thing of the past.
We can't stop anything and everything, but if we start from the basics and limit the attack vector of stack smashing attacks, as well as the dancing bunny problem, it will mean that the attack surface of a machine is quite diminished.
To keep people from allowing stuff mindlessly, that is what repositories are for. If we can train users that a program that isn't installing via a repository is a very bad thing outside a developer environment, and combine that with techniques to harden web browsers and the add-ons, 99% of our job is pretty much done. Of course, there will be new threats (perhaps bugs in the IPv6 stack, CPU bugs, etc.), but stomping out the biggest problems would mean that blackhats would actually have to actively work to gain access.
It uses hard linking as the secret sauce. Backups with one file that stays static just drop a link. If the file is changed, you will find the actual file in the directory.
All and all, a pretty clever system. Only downside is having to make sure you strip the Locked bit if you manually restore data.
I prefer having a dedicated backup server pull data from machines as opposed to having machines save to a NAS, just because if a box gets infected, it can easily scrozzle the NAS, while its damage to a backup server would be minimal.
Perhaps Symantec should have a NetBackup appliance for home users?
It is a pipe dream, but it would be nice if a Senate committee decided to address the issues and actually do something relevant to national security.
Just having an organization similar to the FDIC which would step in and deal with the data from a defunct cloud provider would go a long ways for national security.
Cloud providers, especially Apple's iCloud, are big, fat, juicy targets for blackhats just because of the sheer amount of actionable intelligence gained. Most people may not care if Johnny's school is going to a soccer game, but it might be something that a local gang may love to know, so they know who is away from their houses and when.
A committee means one thing -- more laws. We all know about the bad laws that can be passed (more DRM, tossing some guy who logs on as his ex on FB in prison for 50 years, etc.) However, maybe some good can come out of it:
1: Money spent to have on staff more blackhats/whitehats. Perhaps we need another branch of the Armed Services just dedicated to intrusion prevention and hardening?
2: Certifications for cloud providers. This would include the government stepping in and either erasing or physically destroying all the cloud storage media if the provider got shut down, went bankrupt, got sold to a foreign company, etc. This way, even if the company tanked, all client data would be destroyed, so unlike now, the client data can't just be handed to the next owner of the servers for them to do what they want. The certifications would also include physical inspection, network inspection, host inspection, process inspection, tiger team testing, etc. We do this with hardware and software (FIPS, Common Criteria, EAL), why not cloud computing?
3: Funding for US fab technology for sensitive components like TPMs, firewalls, and other items. This way, there is solid knowledge that an Elbonian backdoor isn't waiting for just the right time to shut down a router or allow intruders in.
4: Funding for a B2B backbone infrastructure where it is preplanned what machines communicate to each other. This way, a bank's computer can send info to a credit card processor, but can't send anything to a baseball card shop unless they have a prior relationship. Preferably have this on separate fiber than the regular Internet. This way, critical business items can be isolated from Internet escapades. Think NIPRNet or SIPRNet, but for businesses.
5: Funding to work on a standard like VNC/Citrix/MS Terminal Server, so that people traveling do not require physical access to data, just access to a terminal server. This way, a blackhat has to compromise a locked down terminal server before they can get to the juicy stuff like Exchange or the like.
6: Grants to universities for better OS and hardware security models. Some computers used to have two addresses for RAM, one just for data, one instructions, and never did they meet. Things like that would be transparent to the user, but would greatly increase security. Same with operating systems that could hand Web browsers privileges by window/tab, so that a compromised tab couldn't get to the tab right by it that the user is doing banking with. Designing machines from the ground up to treat all Web content as hostile would greatly reduce the amount of malware floating around, just like firewalls have reduced incoming attacks.
7: A hardened device for storing passwords similar to a HSM for public keys. This would be extremely useful in LDAP setups as well as websites that have user accounts. A hacked server does not mean wholesale user compromise.
8: A standard TPM that can be added to all computers, but may or not be present. This would allow computers to have a TPM card dropped in if someone wanted it, but it wouldn't present, so the DRM writers couldn't force gamers to use it for additional lockdown.
9: Funding to design a standardized filesystem/LVM similar to ZFS, except that it is not patent encumbered, and can be used by all and sundry, either with all features, or a subset. The only filesystem across platforms these days is either FAT/FAT32, or the CD-ROM format. The reason this would increase security is that tools that can be used on many platforms can identify issues and fix them, especially at the LUN level (pop a snapshot of a LUN, have the SAN scan for viruses to find rootkits that the infected machines can't detect.)
These may be expensive, but at least some of the stuff would at least help things in a substantial manner. Passing more laws with longer prison terms will do jack squat for security overall, except make the private prison owners richer. You have to fight technical battles with technology.
I'll bite.
Scalability: Depends. Some things may scale like putting files for download with Akamai. Other things, not so much. The cloud is a tool in the architect's toolbox.
Admin payroll: Someone is going to need to architect things, so you will still have an IT department, if only to maintain your internal network links, and make sure the desktop PCs don't become botnet clients. Don't forget networking. You will need to have those fat pipes to access the cloud provider, so you will still need a space for those Cisco Nexus 7000 boxes with the clear covers.
Guarenteed SLAs: Read the contract... the SLA may not be as good as people think it might be.
Oh, and if the cloud provider goes bankrupt, the data on their servers is free for the taking by anyone who so desires. Even though it is SOP for auctions to wipe the drives, this gets forgotten or "forgotten". Promises mean nothing when some competitor in Elbonia now has your payroll (sold your employees' info to ID thieves), your client list (and is offering the same services for 50% less), your source code (with a version of your product that is exactly the same except in name), your suppliers (which are then harassed to make better deals elsewhere), and others.
No recorded breach with a cloud provider... time will tell on this one. Nothing is 100% secure. Gmail has had people report incidents, Dropbox has had the security tokens that people talked about, and so on.
No server room? I'm sorry, but even with "economies of scale", you are either paying for a data center in house, or you will be paying for one somewhere else. Don't forget regulations about physical security of data.
DB/OS versions? Sure. However, if something breaks your app's code due to an update done without notice, there is no way to roll back. ITIL 101 here.
Exchange versions? See above.
Don't assume the cloud provider has backups automatically. If someone logs on as an admin with a cloud provider and blows all your storage away, it may not be recoverable, while the old LTO-5 tape library will be able to restore data. When push comes to shove, and in some industries, you better retain data for a while (up to 50 years if dealing with the FAA), you need to pack your own parachute. I trust tape, and moving archived data to the latest archival version every couple years far more than a cloud provider's promise. However, I'm one of those "IT guys" that the parent apparently dislike, so if someone wants to be fast and loose with their data, they can store it on the cloud and assume that their storage has all the snapshot features of the EMC SAN they want to chuck.
Cloud computing is a useful tool. It won't replace server rooms anytime soon. Maybe I'm a fossil, but I rather trust a VTL, replicated SAN, or even good old fashioned tape far more than I would trust just an assurance that a cloud provider has my data backed up.
I wish phonebookFS was still being worked on. It would be great for just exactly this.
I used to use it with a FUSE driver to use Gmail as a filesystem. This way, I could grab out documents for college, personal files, files related to consulting, each of which being separate from each other. The gmail side only saw a bunch of files, some of which could be just chaff and not decrypt-able in any way.
This has been discussed on the TrueCrypt forums at length.
Any forensic person who can understand the difference between a dead body and an iPad will be whipping out the hardware write blocker, making a VMWare image, and working on that. If they fail to do that, it is SOP that any evidence gleaned from the machine can be tossed out the window in most US courts. A password that causes a self-destruction action is nullified with just a rollback from a snapshot, and might add either charges like destruction of evidence.
With the Sony Network Walkman players, it was the same thing. The first generation which used a Magic Gate Memory Stick required transcoding. The second generation wrapped the MP3 format with encryption.
Even more annoying was the fact that you couldn't copy music to it; you checked it out. If you formatted the player and didn't check the music back in, there was a high chance that you would have to re-scan/re-buy the tracks, as some Network Walkman players would check back in erased tracks, others wouldn't.
Because of the in-your-face and annoying DRM, Sony in effect ceded the MP3 player market to Apple, which in later iPod releases had FairPlay DRM, but it would not be as annoying constantly as the old OpenMG software.
A .secure domain on the same physical net is one thing. However, what we really need are separate backbones designed from the ground up to carry traffic.
The US has NIPRNet and SIPRNet. Ideally, it would be nice to see banks and credit card processing places have a "BIPRNet" just so that machines from bank "A" can contact bank "B" via a secure link, preferably a separate physical wire than what the traffic from the outside runs on. This way, a blackhat would have to find a machine that sits on both networks, and go from there. If the network backbone is set up to allow communications only between machines that have a business need to see/connect to each other, it would make that backbone quite secure. Add an IDS/IPS system will make compromise even more difficult.
Same with SCADA stuff. It needs its own backbone, then hardened computers that relay the diagnostic info from the embedded controllers to where it needs to be. I've even used two machines that were connected to each other via a one way serial port (slow link, but it worked getting the small datasets across, and one tx/rx pair was disabled so data could only move from the inner network to the outer) to ensure that the inner embedded network would require physical access to be compromised.
Good internet security is not a matter of "can't". It is a matter of "won't".
FB architected themselves around cheap. Lots of cheap x86 boxes and have the backend application deal with failing servers.
In reality, FB should have considered moving to "big boy" hardware. Since they use MySQL, why not go with full blown Oracle clusters on SPARC M-Series with a decent EMC SAN? Backups are fairly easily done with replication and snapshots, with a tape library to store archives of the build tree. User data can happily remain on a deduped filesystem while business critical stuff like tax records can sit on disk, as well as get saved to tape.
Moving to Oracle also gives the benefit of being able to have the best RDBMS tool selection out there from a mom and pop shop all the way to multi-terabyte databases sitting on SSDs used at banks for 24/7/365 transaction processing.
IBM is another possibility. Upper end POWER7 boxes only need a few CPU and I/O drawers and have the I/O buses that can handle the load FB has. They can use Oracle on this platform, or use DB/2's new oracle compatibility mode and move to that. IBM has a decent AIX/POWER7/DB2 compatibility stack which can load-balance quite effectively.
Or, if FB was willing to reorganize, a couple IBM zSeries and a decent backend storage device (DS8000, EMC's Symmetrix or Celerra series) could sit in a fairly small data center, doing all the work that the tons of x86 boxes do for far less energy used and cooling.
I wonder how much money FB would save had they built their redundancy lower in the hardware/software stack as opposed to having their backend app do all the work? Of course, there is the understandable fear of being locked into a platform... but isn't this the issue with MySQL now? Better to be married to a platform that can scale than one that has been shown to require gymnastics to get it working on the level that FB needs.
Austin has a few roundabouts. However, I dread them highly. One is places on a two way street with no third intersection (Riverside drive). Normally this wouldn't be an issue, but when I go that route, I encounter:
1: People staying in the roundabout and gunning it in order to cause a wreck with merging traffic.
2: People going the wrong way on the roundabout. Yes, I know this sounds crazy, but it isn't that uncommon for someone to be trying to go the wrong way and cause a head on wreck.
3: People who just stay in the roundabout driving around and around like National Lampoon's European Vacation and prevent others from merging on. This is extremely common in the smaller traffic circles where two vehicles do this just to deny access until the drivers get bored or dizzy.
Roundabouts work if drivers have some IQ. That isn't the US, so it is safer to just have a red light which turns to flashing red at the off hours.
You hit the nail on the head.
Take a scenario where some drunk decides hit a semi, causing it to crash into a median, which is all too common on I-35. Even when the wreck is cleared, it will take 30-45 minutes to traverse it. Add the fact that the car is likely around 1/2 or 2/3 charge from coming home, and there is a good chance of the vehicle running out of juice, even though it barely moves at idle.
These things are not road-worthy. It means that we will have more stalled cars that have to wait for the tow trucks, and this could be fatal during an evacuation.
We don't need gimmicks. Want to know what the US really needs on the roads? Turbo diesels. They have an obscene MPG, are tried and true, and have a standard range of fuel. MSRP? $26,065 will get you a TDI with a decent navigation system. MPG? Easily in the 30s, even with driving it like you stole it.
Want hybrids? Sure. Stick a battery pack in a turbo diesel, or even just a beefed up starter motor that can move the vehicle short distances so the car's main engine can be off in low speed traffic, saving at least 10% of fuel costs, far more on fleet vehicles that idle.
Car makers need to start making what consumers need and are useful. Yes, an all electric car is cute, but we do not have the infrastructure for it, and we likely will not for 20-50 years. Most places where people might park may not have electricity available, much less to charge cars. (With a lot of employers, just receiving a paycheck is likely the most one can expect from them, much less amenities like parking or a juice hookup.) Electric cars are not practical now. This doesn't mean hybrid electric cars are not (like the Volt), but pure electric just doesn't have much use for most people, especially if they need to make that unplanned trip.
It is sad, but there are a lot of cases where this is the truth:
DVDs -- disabling the PUO crap, so one doesn't have to sit through 45 minutes of previews for movies that flopped.
Games -- playing games that will not activate because the activation servers have been taken offline, or continuing to play a game after a video card was changed out, and the game will not activate.
Applications -- being able to continue use of a program even after hardware has been changed (RAM upgrade).
The best DRM for games is the simplest -- have a serial number to access multiplayer servers. This worked for almost a decade for NWN1. It keeps the freeloaders at bay, while ensuring that legit users have as good a gaming experience as possible.
I've seen drives with two arms before, configured multiple ways:
One drive had one arm just for reading, one for writing.
One was made so if one arm failed, the other could continue. In the mean time, one arm did the work, while the other one just stayed idle.
One was similar to the previous, except both arms did reading/writing at the same time.
I think it didn't catch on because of cost, but could be wrong.
Not really... Farmers have to compete with large agribusinesses that have access to patented crops that grow with fewer resources spent. Larger businesses have economies of scale on their side.
Trying the "organic" route might work, but there are only so many farmer's markets, so trying to compete against large businesses who can flood the market with dirt cheap crops is becoming more and more difficult.
Farmers are becoming an endangered species. Especially due to the fact that land is becoming more and more valuable, even if the farm is just passed from speculator to speculator.
Fear was one part of the equation.
The second part is that USENET was initially populated by professionals. Either college students, college professors, or people who worked at a "serious" job.
Also, reputation came into play. Relatively few people had anonymous handles, so if someone was jacking around, their name was on what they did.
I am showing my age, but I do miss the days before Eternal September.
The key is if the TPM gets "sealed" before or after the infection. After, you are screwed. Before, the modified MBR will be detected, because the PC in its pre-boot process will scan the MBR, make a MD5 hash of it, and pass it to the TPM. Even the most clever malware can't get past that, barring an infected BIOS flash or a compromised TPM.
We have the technology to deal with this -- the controversial TPM chip, which is around on a lot of hardware.
On Linux, an implementation to prevent MBR-based rootkits could be having at the minimum / encrypted, optimally every filesystem. Use a passphrase for recovery, so if the TPM fails, it isn't hard to just boot without it. This way, if malware does infect the MBR, it will get booted as far as the initial ramdisk and get stuck when the boot process asks for the key to the root volume and the TPM reports that there was tampering.
"Trusted" computing is controversial, but using a TPM in this context will significantly add to security.
I will give this:
Communism works on a small scale. When people are known and reputations matter, communism works.
However, the system will completely break down when people start realizing that they can take more than they give and not suffer consequences for their action.
The history of the Internet shows this -- before the C&S USENET spam, people tended to behave because all it took was a call to their sysadmin and they would be tossed off the net. After C&S, where it was shown that people could get away with breaking traditions and mores to score some cash, it was only a matter of time before the system of "put a server up to help out, and other people do similar" went the way of the dodo, eclipsed by doing what it takes to earn cash.
This is one reason why a TPM chip is a useful tool. It is present, but disabled in most servers.
Enable BitLocker, make sure to save the recovery key somewhere safe (preferably printing it out as well), have it use the MBR, and call it done.
If malware nails the MBR after BitLocker gets turned on, the machine will not boot. One can use Windows PE, mount the system volume with the recovery key, and squash the malicious software that way.
The main concern is that a USB flash drive can also register than more than just a mass storage device:
1: It can register as a keyboard and start typing in text. Ad services use this so when someone jams their device in, it autoruns and pops up a web browser. Malicious ones tend to do worse things.
2: It can register as other devices.
The problem is with the USB protocol, when in the past it just used to be a . It would be nice to have a "dumb" protocol that doesn't allow devices to read from host memory (which is why serious forensics people use a FireWire device for dumping RAM) and that is just made for mass storage devices. SCSI was nice for this... perhaps the best storage protocol for drives that might have unknown data would be FC or FCoE [1]. Optical would be ideal, as a drive couldn't overvoltage and fry the connection.
[1]: I really wish computer makers would add CNA ability to network adapters on motherboards. FCoE is an ideal protocol for a home NAS.
You might be surprised. There are some thin insulation types that one can use in cars, RVs, and other places that do an excellent job. Aerogels used as insulation are extremely useful (Thermoblok is one brand with 10.3 per inch of insulation for the R-value). combine that with reflective Mylar, and it becomes an ideal insulator for RVs and such.
The key is getting this technology into combat theaters.