<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Flash memory the future for laptops?</title>
	<atom:link href="http://gizbuzz.co.uk/2007/flash-memory-the-future-for-laptops/feed/" rel="self" type="application/rss+xml" />
	<link>http://gizbuzz.co.uk/2007/flash-memory-the-future-for-laptops/</link>
	<description>Technology, Computers, Web 2.0, Google, Microsoft, and just about anything else</description>
	<pubDate>Thu, 20 Nov 2008 11:02:19 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6</generator>
		<item>
		<title>By: Lee</title>
		<link>http://gizbuzz.co.uk/2007/flash-memory-the-future-for-laptops/#comment-19606</link>
		<dc:creator>Lee</dc:creator>
		<pubDate>Sat, 10 Mar 2007 16:17:45 +0000</pubDate>
		<guid isPermaLink="false">http://gizbuzz.co.uk/2007/flash-memory-the-future-for-laptops/#comment-19606</guid>
		<description>In theory this is an excellent idea, although the read/write cycle's is a serious issue, last time I checked it was about 100,000. Although it is great that the battery life could seriously be increased, without needing to continue to develop them too much. But it all comes back to the cycles, the drives would probably be dead in a few months for most people, and Virtual Memory would be an absolute no-no.

Although this could work if the OS was built around the limitations of flash memory, so If it booted like a read-only Live Linux disc that would use no (or little) write cycle's, then  you would need lot's of ram to erradicate the need for Virtual Memory, and store any files that needed to be written for permanent storage in the ram until the computer is shut down, that way the number of cycles required would significantly be reduced, although shut-down time would be increased, and after extended period's of time with no reboots the system would become slow.

It is certainly an idea for the future, but I personally don't want to be having to by new flash drives for my computer every few months.</description>
		<content:encoded><![CDATA[<p>In theory this is an excellent idea, although the read/write cycle&#8217;s is a serious issue, last time I checked it was about 100,000. Although it is great that the battery life could seriously be increased, without needing to continue to develop them too much. But it all comes back to the cycles, the drives would probably be dead in a few months for most people, and Virtual Memory would be an absolute no-no.</p>
<p>Although this could work if the OS was built around the limitations of flash memory, so If it booted like a read-only Live Linux disc that would use no (or little) write cycle&#8217;s, then  you would need lot&#8217;s of ram to erradicate the need for Virtual Memory, and store any files that needed to be written for permanent storage in the ram until the computer is shut down, that way the number of cycles required would significantly be reduced, although shut-down time would be increased, and after extended period&#8217;s of time with no reboots the system would become slow.</p>
<p>It is certainly an idea for the future, but I personally don&#8217;t want to be having to by new flash drives for my computer every few months.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Adam</title>
		<link>http://gizbuzz.co.uk/2007/flash-memory-the-future-for-laptops/#comment-19586</link>
		<dc:creator>Adam</dc:creator>
		<pubDate>Sat, 10 Mar 2007 09:51:15 +0000</pubDate>
		<guid isPermaLink="false">http://gizbuzz.co.uk/2007/flash-memory-the-future-for-laptops/#comment-19586</guid>
		<description>I can see the advantage in terms of portability. But yes - I cant see any practicality because of the read/write issue.</description>
		<content:encoded><![CDATA[<p>I can see the advantage in terms of portability. But yes - I cant see any practicality because of the read/write issue.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.394 seconds -->
