The version 1.1 of Linux is fine, but it doesn't have the latest security patches, and a malformed ping packet will cause it to give up the ghost.
A 2 TB operating system won't be a nice thing to upgrade, but it will be something forced in order to keep up with the latest security issues. Security never stands still, so one has to either keep on the upgrade treadmill to stay protected, add third party software to make up for the outdated OS protections, or put the machines behind an air gap.
All I see is the same problems we have now, except with stuff running in terabytes where in the past it took gigabytes or even megabytes.
Once we start seeing expanded RAM sizes, I'm sure we will see OO based development tools more than ready to fill up that RAM with object frameworks vastly larger than now. End result: Still needing to buy and upgrade RAM, applications performing essentially the same, except taking up a lot more space.
Where I'd like to see memristor technology be used are dumbphones and embedded devices such as cash registers and POS (point of sale, not the other POS) units. Places where having the ability to boot near instantly is critical. For POS units, downtime is money lost every second.
Memristor based crossbar switches will be extremely useful for two uses:
Shuffling data between VMs in a secure manner on a host such as an IBM 795 or a zSeries that has a large number of VMs in use for different tasks. This way a bunch of VMs that talk amongst themselves frequently (a DB server to an app server) will end up being able to do high I/O without that slamming the CPU.
Another use is tiered memory, where one has a machine with fast RAM and slow RAM, with slow RAM being exponentially faster than going to SSD or magnetic platters. If memristors become able to be printed on a large scale, perhaps we will see machines with 16-32 GB of DRAM, then 256-512 GB of memristive RAM that is used as both swap space, but also a persistant cache for the OS to boot from an image with, never touching the storage media until the OS is fully loaded and the user wants to load documents, or the OS is doing a backup.
The lawyers are not trying to get 5000 trials. They are trying to do one trial with 5000 defendants. And so far, they just might be successful at this.
I still think it is cool that cameras made 20-30 years ago from Hasselblad can get digital imaging backs put on with 39 megapixels worth of resolution.
There is something about seeing an "Intel Inside" and a "Designed for Windows XP" sticker affixed to an IBM z-Series mainframe rack which is both funny and sacrilegious at the same time.
Don't forget the cost of the hardware is just a part of the job:
If someone knows what they are doing and are building a gaming rig, then obviously, Macs are not a good choice for this. A 12 core Mac Pro will be a good game machine, but I'm sure equal performance can be gotten elsewhere for much, much less.
If someone is buying a PC as a desktop machine and knows what he or she are doing (imaging the original stuff off, erasing the HDD, putting on a new OS), then a Mac may not be what they need, because they know what they are doing, usually have some type of backup facility (even if it is just the OS imaging stuff), and have basic protection against malware (Adblock, Privoxy, etc.)
If someone is using Linux, a BSD, or another OS on generic x86 hardware, a Mac may not be the best choice either, because EFI is less compatible for booting than plain old BIOS.
However, Macs are good if one factors in total costs of ownership for a non technical user (the Joe Sixpacks, Jane Artist, and Aunt Tillie):
Take a $1500 iMac. One can build similar with a monitor in the PC environment for less. However, the average user will usually end up having to reinstall the Windows box due to an infection once or twice, and because most sub-1000 PCs (except for Dells) have no restore CDs, that is an additional $100+ expense. A "delousing" of a machine can take a good chunk of change if the user is in a place where he/she doesn't have any Windows-savvy friends. So, for the average non-technical user, not having to pony up for periodic service would sway things a lot better in the Mac's direction.
In an extreme case, buying a Mac might shield a person from identity theft, bank account fraud, and other online crimes which Windows has had problems with, because it is the focus of so many blackhats. These items could cost a user thousands to remedy, so having a platform that isn't the target of criminals across the globe may make the TCO swing a lot better in Apple's direction.
The key is knowing what the end user wants, and their skill level.
The reason companies do the buying is that R&D is so heavily penalized in the US, due to tax breaks, liability, and other things. If a small company puts out a product, it is better to wait to see if they face lawsuits, then buy them if nothing happens as opposed to creating a product for a new market.
Plus, American companies are shackled to the fact that they have to make a profit quarter per quarter, or shareholders can sue the company in the ground. Buying a company is a lot easier to explain to the accountants and board members as opposed to charging off some chunk of change for a R&D facility for new products that won't have an ROI for 5-10 years.
How about a Skype application that does end to end encryption from the VoIP server to the cellphone? This would definitely be the killer app. This way, management can talk plans to a sales guy making a deal in Latveria without the Elbonians listening in.
On the Mac, iTunes works well. Mash play/pause/FF/rewind, it does so when in the background. However, on Windows, the media keys don't work unless iTunes is present in the foreground. Even the Zune player is good in this regard.
My second issue is that iTunes is so critical to the operation of iOS devices. If iTunes becomes unusable, you can't restore your iPhone, iPad, or iPod Touch if that dies. Other iPods can be used with third party utilities, or even manually dumped in disk mode.
What I'd like to see Apple do with iTunes on both Mac and Windows is have a method of repairing the program, as well as more thorough diagnostics. Not just checking file placement and Registry/NetInfo entries, but running checks on the installed drivers, checking to see if the daemons/services start up and stay up, looking for known conflicts (say the iPod driver conflicts with another utility), and then a standalone program to temporarily disable all USB drivers, allow an iDevice to be plugged in, and check to see if that works on a low level basis.
Another thing I'd like to see is a pure image dump, similar to nandroid. This way, the iDevice can be backed up and restored without having to restore the app plists, then resync everything back. Even if this backup was locked to the device with an encryption key for the whole blob, it would be extremely nice to have. iOS devices are doing a more and more things, they really need an advanced backup system, so one can restore the device with an image if something happens. Even better would be a synthetic full method of backups, where incrementals can be taken of the device, and a full image generated from the first full + the incrementals after that. This would allow a nice point in time system.
Finally, I wish iOS devices would get a filesystem that supported snapshotting. Why? This would allow syncs over the air and allowing the user to keep using the device while it is syncing, assuming the user wasn't using an application whose files were getting a change pushed to them from the remote side of course.
One can compare it to SANs. If someone wants a lot of disk capacity, they can build a bunch of BackBlaze pods. However, one reason people buy SANs is for additional features, such as being able to have multiple computers access a LUN (the main machine and a backup box), deduplication, replication across a WAN, snapshot filesystems, snapshot backups (snapshots run in constant time so popping a snapshot is the fastest way to back up a LUN on a machine with a very small backup window, then the backup snapshot can be dumped to tape for long term archiving), etc.
Same with mainframes. One can make a Beowulf cluster of anything and end up with something faster than IBM's iron. However, is the MTBF the same? The more machines, the more things that can go wrong, so the more redundancy is needed.
This isn't to say PCs are bad, but there are always trade-offs. A SAN and a couple boxes in a cluster can give 99% uptime, but if someone is needing 5 nine reliability, they go mainframe, no questions asked, and they will pay dearly for those five nines.
RISC machines in general have a lot more registers to mess around with. Take the Itanium for example:
128 integer regs, 128 Floating point spaces, etc.
With amd64 assembly, you have rax, rbx, rcx, and rdx. If you need to juggle more than that, you go to memory. With the Itanium, you can just keep playing with numbers and do some serious calculations without leaving the CPU's die. More registers also help cryptography operations where you have to keep shifting rows of data up/down/left/right for AES, or doing large multiply operations as per RSA.
I'm sure an IBM rep would be more than happy to show you numbers of a 4.25 Ghz POWER7 compared to the equal x86/amd64 performance stats. Even if the POWER7 cores are running in TurboCore mode where half of them are shut off, and due to that, the ones which are active take the caches of the powered down cores and can run a little bit faster with clock speed.
Same thing I said. The 2G Shuffle had a lot going for it. It was reasonably priced, had the buttons on the device so I could use cheap earbuds or something for the gym, had a decent battery life, and was all around well designed. The third gen looked cooler, but one either had to buy an adapter for the buttons or use special headphones. Don't forget the multiple tapping needed to skip back and forward songs.
"Perfection is achieved not when there is nothing left to add, but when there is nothing left to take away" seems to sum it up best about the latest Shuffle. For the form factor and what the device does, it is extremely hard to improve on the 2G design. The 4G did so by having one switch (on/play sequence/play shuffle), as opposed to two (on/off and sequence/shuffle), as well as having voiceover, and being able to use the buttons from the third gen Shuffle.
Apple's battery technology has improved significantly since the 2G Shuffle, so I'm hoping that addresses the parent poster's issue with the previous 2G.
From a QA perspective, having eight devices to have to test on (four iPhones, iPad, iPad 3G, two iPod Touch models) is a lot easier than checking to see if your device works with different displays, resolutions keyboards, trackballs (physical and virtual), status lights, cameras, and so on.
One mistake on your Android app, and your app's review status starts going deep in a hole with tons of "Force closes on the Blarf, refunded." on the Marketplace review sheet.
The "mistake" that non-Windows platforms make is the fact that developers on that platform actually value what they are developing on. There isn't any of that on Windows, and Windows devs feel free to crap where they sleep.
Platform loyalty is important. Not many programmers on Windows would go out of their way to deal with the latest worm or Trojan (unless it fattened their wallets, of course), but on other platforms, almost everyone would ensure that it would be stopped. Mac devs don't like viruses (especially older ones which dealt with that crud in the pre OS X days), so would actively find a way to stop it until Apple put out an official patch. Linux distros would have patches out in minutes to hours.
There is one thing I forgot to add which should help things:
Change your outgoing IP often if you don't have servers running. That, or use a proxy server so more than just you are coming from that address. An additional benefit of an encrypted proxy server is that if one is using a dodgy AP, someone sniffing traffic wouldn't be able to discern what is being done over the wire for the most part.
I tell people to don't bother citing the Wikipedia article, but go to the sources listed in the article, read those and the citations those articles have, then go from there, or even check those articles and their references out as well. At least with 1-2 layers of articles gleaned from citations, that might be enough for most references.
Caveat: A lot of papers require peer reviewed academic journal citations, so this does not replace going to the library and digging through for relevant academic items.
One of the cooler implementations of an app level VM system was Thinstall, now EMC ThinApp. With this, one could have on executable that would store all files and Registry entries changed in a subdirectory in the user's AppData/Thinstall directory. Thinstall could also be configured to wipe the directory when the app is closed.
The only disadvantage to this setup is if malware or a Web browser plugin could break out and run as the user's context not hemmed in by the encapsulation Thinstall had.
What would be cool is to combine redirected writes on the OS level with Thinstall's functionality. This way, the OS shunts any write requests it gets to the directory the app has in the user's home directory, both file changes and Registry entries. So the app can think it fat, dumb, and happy installing junk all across the system, when in reality there are only de-duplicated changes in its directory marking its work.
1: Eventually everyone will be moving to a MicroSIM. Losing the couple millimeters may not sound like much, but with the ever shrinking form factors of devices, it allows for more leeway in positioning the card in a device, as well as a smaller size. The Apple 30 pin connector is Apple specific, but it does have three advantages over every other connector. The first is that it has a much higher insertion cycle rating than most USB plugs. The second is that the connector can be used as a dock so the iPod/iPhone can stand up and be supported physically by the connector. The third is that the connector is so common. Stereos have it, some car stereos have a place for the iPhone, some TVs have it so one can run movies from the device, and so on.
2 and 2a: Maybe this is a good thing, due to the dancing bunny problem. Without Apple watching the store, there would be a high chance of developers writing malicious software and putting it on the store. When one app gets found out and killed, the developer just buys another ID and keeps cranking out the bad apps -- the returns from grabbing contact info and other nefarious acts would more than be worth it. Then there is the fact that Joe Sixpack would download an app and scoop it onto the phone without thinking about it, then when he gets a gigantic phone bill, he will blame Apple for having a device with such poor security.
The absolute best thing would be an obstacle big enough to keep Joe in the walled garden while letting people with a clue be able to dispense with it and use the phone as a decent UNIX machine. I like how the Nexus One did it.
Cookie Monster is nice, but any ad place worth a clue is using Flash Shared Objects and not browser cookies, and Cookie Monster does nothing to remedy that.
Best way to fix? The BetterPrivacy add-on in Firefox. Set it to run every 2-3 minutes to clean out the Flash crap, and go from there. However, this is just playing cat and mouse, because other add-ons tend to save state too.
Ultimately, this is where the government will have to get involved. Our only other option is everyone running their Web browser in a virtual machine that rolls back all changes when closed. I'm sure more add-ons will be needed to browse content in the future, and each of those add-ons will have the ability to allow persistent storage of data.
What is killing Sony is the fact that they are in a dinosaur mentality. Yes, it took half a decade for the PS3 to get breached, and they have top of the line security. They had this mentality since the Network Walkman days. People would look at their devices (which had an excellent form factor), hear about the annoying DRM restrictions that were in your face (can't copy songs to the device, had to check them out, and that was only if the device was authorized to do so, no ability to back up stored music in a library, etc.) Yes, their security is superb, but what happens is that they end up a bit player because of it.
While Sony was with SDMI working on demanding everyone has DRM standards (such as not allowing music to be copied from a device to a computer), Apple put out a device with zero restrictions at first, then a DRM system which not just didn't bother most of Apple's users, but if someone was desperate to listen to iTunes downloads on a non-Apple device, they could burn a playlist to CD and re-rip.
Sony hasn't seemed to learn their lesson. If they not just permitted a homebrew community, but actually encouraged it, they wouldn't just sell consoles, they would be ahead of the pack, just because cool and innovative titles would be appearing on the console. If the consoles could be better used with alternative operating systems, Sony would make money hand-over-fist because people would buy the consoles and use them as NAS heads, firewalls (with USB adapters), dedicated appliances, and other items. If Sony actually built in home server functionality into the console (a la Time Capsule or a Windows Home Server), the PS3 would wind up a central fixture in a lot of homes, putting the competition six feet under.
It is ironic that the PS3, with a -ZERO- piracy rate until a week ago is doing so poorly compared to the competition. This is definitely a counter-argument to blaming lagging sales on IP infringement which the industry always does.
Downloading is becoming harder and harder. ISPs here in the US are not upgrading jack except for fees and bandwidth surcharges. Combine that with the fact that in general, connections are more saturated making reliably downloading something more problematic, and one finds that a download-only format isn't going to work just yet.
What I see happening is that future games on consoles will require two things. A cartridge or CD/DVD/BD-ROM which is bundled with a CD key, and a required download to activate the game and bind it to a console. The download will be a signed flash image to update the DRM stack on the console if it isn't at the latest level, as well as a way to communicate the decryption key via a secure mechanism from the game company's servers to the console. What will then happen is that used *media* will end up at the used game stores, but to purchase a usable CD key (just like Windows), it will cost the retail price of the game, perhaps a little bit less.
Slashdot Mirror
The version 1.1 of Linux is fine, but it doesn't have the latest security patches, and a malformed ping packet will cause it to give up the ghost.
A 2 TB operating system won't be a nice thing to upgrade, but it will be something forced in order to keep up with the latest security issues. Security never stands still, so one has to either keep on the upgrade treadmill to stay protected, add third party software to make up for the outdated OS protections, or put the machines behind an air gap.
All I see is the same problems we have now, except with stuff running in terabytes where in the past it took gigabytes or even megabytes.
Once we start seeing expanded RAM sizes, I'm sure we will see OO based development tools more than ready to fill up that RAM with object frameworks vastly larger than now. End result: Still needing to buy and upgrade RAM, applications performing essentially the same, except taking up a lot more space.
Where I'd like to see memristor technology be used are dumbphones and embedded devices such as cash registers and POS (point of sale, not the other POS) units. Places where having the ability to boot near instantly is critical. For POS units, downtime is money lost every second.
Memristor based crossbar switches will be extremely useful for two uses:
Shuffling data between VMs in a secure manner on a host such as an IBM 795 or a zSeries that has a large number of VMs in use for different tasks. This way a bunch of VMs that talk amongst themselves frequently (a DB server to an app server) will end up being able to do high I/O without that slamming the CPU.
Another use is tiered memory, where one has a machine with fast RAM and slow RAM, with slow RAM being exponentially faster than going to SSD or magnetic platters. If memristors become able to be printed on a large scale, perhaps we will see machines with 16-32 GB of DRAM, then 256-512 GB of memristive RAM that is used as both swap space, but also a persistant cache for the OS to boot from an image with, never touching the storage media until the OS is fully loaded and the user wants to load documents, or the OS is doing a backup.
The lawyers are not trying to get 5000 trials. They are trying to do one trial with 5000 defendants. And so far, they just might be successful at this.
I still think it is cool that cameras made 20-30 years ago from Hasselblad can get digital imaging backs put on with 39 megapixels worth of resolution.
There is something about seeing an "Intel Inside" and a "Designed for Windows XP" sticker affixed to an IBM z-Series mainframe rack which is both funny and sacrilegious at the same time.
Don't forget the cost of the hardware is just a part of the job:
If someone knows what they are doing and are building a gaming rig, then obviously, Macs are not a good choice for this. A 12 core Mac Pro will be a good game machine, but I'm sure equal performance can be gotten elsewhere for much, much less.
If someone is buying a PC as a desktop machine and knows what he or she are doing (imaging the original stuff off, erasing the HDD, putting on a new OS), then a Mac may not be what they need, because they know what they are doing, usually have some type of backup facility (even if it is just the OS imaging stuff), and have basic protection against malware (Adblock, Privoxy, etc.)
If someone is using Linux, a BSD, or another OS on generic x86 hardware, a Mac may not be the best choice either, because EFI is less compatible for booting than plain old BIOS.
However, Macs are good if one factors in total costs of ownership for a non technical user (the Joe Sixpacks, Jane Artist, and Aunt Tillie):
Take a $1500 iMac. One can build similar with a monitor in the PC environment for less. However, the average user will usually end up having to reinstall the Windows box due to an infection once or twice, and because most sub-1000 PCs (except for Dells) have no restore CDs, that is an additional $100+ expense. A "delousing" of a machine can take a good chunk of change if the user is in a place where he/she doesn't have any Windows-savvy friends. So, for the average non-technical user, not having to pony up for periodic service would sway things a lot better in the Mac's direction.
In an extreme case, buying a Mac might shield a person from identity theft, bank account fraud, and other online crimes which Windows has had problems with, because it is the focus of so many blackhats. These items could cost a user thousands to remedy, so having a platform that isn't the target of criminals across the globe may make the TCO swing a lot better in Apple's direction.
The key is knowing what the end user wants, and their skill level.
The reason companies do the buying is that R&D is so heavily penalized in the US, due to tax breaks, liability, and other things. If a small company puts out a product, it is better to wait to see if they face lawsuits, then buy them if nothing happens as opposed to creating a product for a new market.
Plus, American companies are shackled to the fact that they have to make a profit quarter per quarter, or shareholders can sue the company in the ground. Buying a company is a lot easier to explain to the accountants and board members as opposed to charging off some chunk of change for a R&D facility for new products that won't have an ROI for 5-10 years.
How about a Skype application that does end to end encryption from the VoIP server to the cellphone? This would definitely be the killer app. This way, management can talk plans to a sales guy making a deal in Latveria without the Elbonians listening in.
My issue with iTunes are two things:
On the Mac, iTunes works well. Mash play/pause/FF/rewind, it does so when in the background. However, on Windows, the media keys don't work unless iTunes is present in the foreground. Even the Zune player is good in this regard.
My second issue is that iTunes is so critical to the operation of iOS devices. If iTunes becomes unusable, you can't restore your iPhone, iPad, or iPod Touch if that dies. Other iPods can be used with third party utilities, or even manually dumped in disk mode.
What I'd like to see Apple do with iTunes on both Mac and Windows is have a method of repairing the program, as well as more thorough diagnostics. Not just checking file placement and Registry/NetInfo entries, but running checks on the installed drivers, checking to see if the daemons/services start up and stay up, looking for known conflicts (say the iPod driver conflicts with another utility), and then a standalone program to temporarily disable all USB drivers, allow an iDevice to be plugged in, and check to see if that works on a low level basis.
Another thing I'd like to see is a pure image dump, similar to nandroid. This way, the iDevice can be backed up and restored without having to restore the app plists, then resync everything back. Even if this backup was locked to the device with an encryption key for the whole blob, it would be extremely nice to have. iOS devices are doing a more and more things, they really need an advanced backup system, so one can restore the device with an image if something happens. Even better would be a synthetic full method of backups, where incrementals can be taken of the device, and a full image generated from the first full + the incrementals after that. This would allow a nice point in time system.
Finally, I wish iOS devices would get a filesystem that supported snapshotting. Why? This would allow syncs over the air and allowing the user to keep using the device while it is syncing, assuming the user wasn't using an application whose files were getting a change pushed to them from the remote side of course.
One can compare it to SANs. If someone wants a lot of disk capacity, they can build a bunch of BackBlaze pods. However, one reason people buy SANs is for additional features, such as being able to have multiple computers access a LUN (the main machine and a backup box), deduplication, replication across a WAN, snapshot filesystems, snapshot backups (snapshots run in constant time so popping a snapshot is the fastest way to back up a LUN on a machine with a very small backup window, then the backup snapshot can be dumped to tape for long term archiving), etc.
Same with mainframes. One can make a Beowulf cluster of anything and end up with something faster than IBM's iron. However, is the MTBF the same? The more machines, the more things that can go wrong, so the more redundancy is needed.
This isn't to say PCs are bad, but there are always trade-offs. A SAN and a couple boxes in a cluster can give 99% uptime, but if someone is needing 5 nine reliability, they go mainframe, no questions asked, and they will pay dearly for those five nines.
RISC machines in general have a lot more registers to mess around with. Take the Itanium for example:
128 integer regs, 128 Floating point spaces, etc.
With amd64 assembly, you have rax, rbx, rcx, and rdx. If you need to juggle more than that, you go to memory. With the Itanium, you can just keep playing with numbers and do some serious calculations without leaving the CPU's die. More registers also help cryptography operations where you have to keep shifting rows of data up/down/left/right for AES, or doing large multiply operations as per RSA.
I'm sure an IBM rep would be more than happy to show you numbers of a 4.25 Ghz POWER7 compared to the equal x86/amd64 performance stats. Even if the POWER7 cores are running in TurboCore mode where half of them are shut off, and due to that, the ones which are active take the caches of the powered down cores and can run a little bit faster with clock speed.
IBM CPUs are not slow by any means.
Same thing I said. The 2G Shuffle had a lot going for it. It was reasonably priced, had the buttons on the device so I could use cheap earbuds or something for the gym, had a decent battery life, and was all around well designed. The third gen looked cooler, but one either had to buy an adapter for the buttons or use special headphones. Don't forget the multiple tapping needed to skip back and forward songs.
"Perfection is achieved not when there is nothing left to add, but when there is nothing left to take away" seems to sum it up best about the latest Shuffle. For the form factor and what the device does, it is extremely hard to improve on the 2G design. The 4G did so by having one switch (on/play sequence/play shuffle), as opposed to two (on/off and sequence/shuffle), as well as having voiceover, and being able to use the buttons from the third gen Shuffle.
Apple's battery technology has improved significantly since the 2G Shuffle, so I'm hoping that addresses the parent poster's issue with the previous 2G.
Devil's (or more exactly Apple's) advocate here:
From a QA perspective, having eight devices to have to test on (four iPhones, iPad, iPad 3G, two iPod Touch models) is a lot easier than checking to see if your device works with different displays, resolutions keyboards, trackballs (physical and virtual), status lights, cameras, and so on.
One mistake on your Android app, and your app's review status starts going deep in a hole with tons of "Force closes on the Blarf, refunded." on the Marketplace review sheet.
The "mistake" that non-Windows platforms make is the fact that developers on that platform actually value what they are developing on. There isn't any of that on Windows, and Windows devs feel free to crap where they sleep.
Platform loyalty is important. Not many programmers on Windows would go out of their way to deal with the latest worm or Trojan (unless it fattened their wallets, of course), but on other platforms, almost everyone would ensure that it would be stopped. Mac devs don't like viruses (especially older ones which dealt with that crud in the pre OS X days), so would actively find a way to stop it until Apple put out an official patch. Linux distros would have patches out in minutes to hours.
Most likely Google will throw the kill switch and the offending app gets purged from devices.
Assuming the malware didn't get root access, of course. If the user does allow it through su, all bets are off.
Latest move to prod is sort of stopped -- I thought it was a dev VM, but powered off the wrong box from the command line.
Sorry about that.
There is one thing I forgot to add which should help things:
Change your outgoing IP often if you don't have servers running. That, or use a proxy server so more than just you are coming from that address. An additional benefit of an encrypted proxy server is that if one is using a dodgy AP, someone sniffing traffic wouldn't be able to discern what is being done over the wire for the most part.
I tell people to don't bother citing the Wikipedia article, but go to the sources listed in the article, read those and the citations those articles have, then go from there, or even check those articles and their references out as well. At least with 1-2 layers of articles gleaned from citations, that might be enough for most references.
Caveat: A lot of papers require peer reviewed academic journal citations, so this does not replace going to the library and digging through for relevant academic items.
One of the cooler implementations of an app level VM system was Thinstall, now EMC ThinApp. With this, one could have on executable that would store all files and Registry entries changed in a subdirectory in the user's AppData/Thinstall directory. Thinstall could also be configured to wipe the directory when the app is closed.
The only disadvantage to this setup is if malware or a Web browser plugin could break out and run as the user's context not hemmed in by the encapsulation Thinstall had.
What would be cool is to combine redirected writes on the OS level with Thinstall's functionality. This way, the OS shunts any write requests it gets to the directory the app has in the user's home directory, both file changes and Registry entries. So the app can think it fat, dumb, and happy installing junk all across the system, when in reality there are only de-duplicated changes in its directory marking its work.
Time for me to do devil's advocate mode here:
1: Eventually everyone will be moving to a MicroSIM. Losing the couple millimeters may not sound like much, but with the ever shrinking form factors of devices, it allows for more leeway in positioning the card in a device, as well as a smaller size. The Apple 30 pin connector is Apple specific, but it does have three advantages over every other connector. The first is that it has a much higher insertion cycle rating than most USB plugs. The second is that the connector can be used as a dock so the iPod/iPhone can stand up and be supported physically by the connector. The third is that the connector is so common. Stereos have it, some car stereos have a place for the iPhone, some TVs have it so one can run movies from the device, and so on.
2 and 2a: Maybe this is a good thing, due to the dancing bunny problem. Without Apple watching the store, there would be a high chance of developers writing malicious software and putting it on the store. When one app gets found out and killed, the developer just buys another ID and keeps cranking out the bad apps -- the returns from grabbing contact info and other nefarious acts would more than be worth it. Then there is the fact that Joe Sixpack would download an app and scoop it onto the phone without thinking about it, then when he gets a gigantic phone bill, he will blame Apple for having a device with such poor security.
The absolute best thing would be an obstacle big enough to keep Joe in the walled garden while letting people with a clue be able to dispense with it and use the phone as a decent UNIX machine. I like how the Nexus One did it.
Cookie Monster is nice, but any ad place worth a clue is using Flash Shared Objects and not browser cookies, and Cookie Monster does nothing to remedy that.
Best way to fix? The BetterPrivacy add-on in Firefox. Set it to run every 2-3 minutes to clean out the Flash crap, and go from there. However, this is just playing cat and mouse, because other add-ons tend to save state too.
Ultimately, this is where the government will have to get involved. Our only other option is everyone running their Web browser in a virtual machine that rolls back all changes when closed. I'm sure more add-ons will be needed to browse content in the future, and each of those add-ons will have the ability to allow persistent storage of data.
What is killing Sony is the fact that they are in a dinosaur mentality. Yes, it took half a decade for the PS3 to get breached, and they have top of the line security. They had this mentality since the Network Walkman days. People would look at their devices (which had an excellent form factor), hear about the annoying DRM restrictions that were in your face (can't copy songs to the device, had to check them out, and that was only if the device was authorized to do so, no ability to back up stored music in a library, etc.) Yes, their security is superb, but what happens is that they end up a bit player because of it.
While Sony was with SDMI working on demanding everyone has DRM standards (such as not allowing music to be copied from a device to a computer), Apple put out a device with zero restrictions at first, then a DRM system which not just didn't bother most of Apple's users, but if someone was desperate to listen to iTunes downloads on a non-Apple device, they could burn a playlist to CD and re-rip.
Sony hasn't seemed to learn their lesson. If they not just permitted a homebrew community, but actually encouraged it, they wouldn't just sell consoles, they would be ahead of the pack, just because cool and innovative titles would be appearing on the console. If the consoles could be better used with alternative operating systems, Sony would make money hand-over-fist because people would buy the consoles and use them as NAS heads, firewalls (with USB adapters), dedicated appliances, and other items. If Sony actually built in home server functionality into the console (a la Time Capsule or a Windows Home Server), the PS3 would wind up a central fixture in a lot of homes, putting the competition six feet under.
It is ironic that the PS3, with a -ZERO- piracy rate until a week ago is doing so poorly compared to the competition. This is definitely a counter-argument to blaming lagging sales on IP infringement which the industry always does.
Downloading is becoming harder and harder. ISPs here in the US are not upgrading jack except for fees and bandwidth surcharges. Combine that with the fact that in general, connections are more saturated making reliably downloading something more problematic, and one finds that a download-only format isn't going to work just yet.
What I see happening is that future games on consoles will require two things. A cartridge or CD/DVD/BD-ROM which is bundled with a CD key, and a required download to activate the game and bind it to a console. The download will be a signed flash image to update the DRM stack on the console if it isn't at the latest level, as well as a way to communicate the decryption key via a secure mechanism from the game company's servers to the console. What will then happen is that used *media* will end up at the used game stores, but to purchase a usable CD key (just like Windows), it will cost the retail price of the game, perhaps a little bit less.