<?xml version="1.0" encoding="iso-8859-1"?><!-- generator="b2evolution/2.4.5" -->
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:admin="http://webns.net/mvcb/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/">
	<channel>
		<title>Josh Saddler - Latest comments on Hardware hackery</title>
		<link>http://blogs.gentoo.org/nightmorph?disp=comments</link>
		<description></description>
		<language>en-US</language>
		<docs>http://backend.userland.com/rss</docs>
		<admin:generatorAgent rdf:resource="http://b2evolution.net/?v=2.4.5"/>
		<ttl>60</ttl>
				<item>
			<title>In response to: Hardware hackery</title>
			<pubDate>Tue, 16 Jun 2009 09:21:09 +0000</pubDate>
			<dc:creator>Josh Saddler [Member]</dc:creator>
			<guid isPermaLink="false">c21497@http://blogs.gentoo.org/</guid>
			<description>@&lt;strong&gt;Gordon&lt;/strong&gt;:&lt;br /&gt;
&lt;br /&gt;
I've read the TechReport articles, and their conclusions are extremely suspect, as numerous comments and forum threads at TR have discussed. Their methodology is rather lacking; they're even still using HDTach, which has been soundly debunked as an SSD benchmarking tool. (http://benchmarkreviews.com/index.php?option=com_content&amp;amp;task=view&amp;amp;id=270&amp;amp;Itemid=38 et al).&lt;br /&gt;
&lt;br /&gt;
AnandTech had smarter benchmarks and more thorough investigation of the Indilinx controllers a couple of months ago.&lt;br /&gt;
&lt;br /&gt;
Every other site on the 'net that put the Indilinx-based drives through synthetic and real-world benchmarks, including on Linux systems, found them to be spectacular performers, behind only Intel and a few Samsung-based SSDs. I'd be quite comfortable buying one or two, especially as I wouldn't be running them in a severely degraded, artificially heavily-worn condition as they are in the TechReport setups.&lt;br /&gt;
&lt;br /&gt;
Actually, what I'd really like to do is put my main system on an Indilinx drive, and move the heavily-written directories (/var, /usr/portage) to their own cheap, small SSD, to get some nice read speed improvements. I've outlined my plans here:&lt;br /&gt;
http://www.techreport.com/forums/viewtopic.php?f=5&amp;amp;t=66642&lt;br /&gt;
&lt;br /&gt;
Thing is . . . I can't seem to find a non-JMicron SSD for under a hundred bucks. Don't get me wrong, the Indilinx-based drives are a good value for their size, but they're also expensive considering I don't need more than 8GB for my intended usage.&lt;br /&gt;
&lt;br /&gt;
* * * &lt;br /&gt;
&lt;br /&gt;
Anyway, as far as reinstalling goes . . . while the base hardware (CPU, mobo) remains the same, thus negating any real kernel changes (except for choosing the NOOP scheduler and a new filesystem like NILFS/ext4/btrfs). moving from a RAID array to a single disk isn't something I really look forward to. If I have to do all kinds of interesting partition/block alignment tricks, filesystem tweaks, and whatnot to the drive to get it ready, I may as well install Gentoo from scratch while I'm at it. I haven't really looked into simple data migration like making a tarball of the entire root FS and copying it, or anything like that.&lt;br /&gt;
&lt;br /&gt;
However, the tips are appreciated. Still, for anything as convoluted as moving down a chain of Athlon XP/AMD64/Core2, I'd rather take the easy way out and make an offline backup of /home, and just perform a new install. It's also good practice. Let's me &lt;em&gt;really&lt;/em&gt; create a lean, mean system, having learned some things about optimization and bloat prevention over time. Oh, and reinstalling lets me verify that the handbooks I write are still accurate. :)</description>
			<content:encoded><![CDATA[@<strong>Gordon</strong>:<br />
<br />
I've read the TechReport articles, and their conclusions are extremely suspect, as numerous comments and forum threads at TR have discussed. Their methodology is rather lacking; they're even still using HDTach, which has been soundly debunked as an SSD benchmarking tool. (http://benchmarkreviews.com/index.php?option=com_content&amp;task=view&amp;id=270&amp;Itemid=38 et al).<br />
<br />
AnandTech had smarter benchmarks and more thorough investigation of the Indilinx controllers a couple of months ago.<br />
<br />
Every other site on the 'net that put the Indilinx-based drives through synthetic and real-world benchmarks, including on Linux systems, found them to be spectacular performers, behind only Intel and a few Samsung-based SSDs. I'd be quite comfortable buying one or two, especially as I wouldn't be running them in a severely degraded, artificially heavily-worn condition as they are in the TechReport setups.<br />
<br />
Actually, what I'd really like to do is put my main system on an Indilinx drive, and move the heavily-written directories (/var, /usr/portage) to their own cheap, small SSD, to get some nice read speed improvements. I've outlined my plans here:<br />
http://www.techreport.com/forums/viewtopic.php?f=5&amp;t=66642<br />
<br />
Thing is . . . I can't seem to find a non-JMicron SSD for under a hundred bucks. Don't get me wrong, the Indilinx-based drives are a good value for their size, but they're also expensive considering I don't need more than 8GB for my intended usage.<br />
<br />
* * * <br />
<br />
Anyway, as far as reinstalling goes . . . while the base hardware (CPU, mobo) remains the same, thus negating any real kernel changes (except for choosing the NOOP scheduler and a new filesystem like NILFS/ext4/btrfs). moving from a RAID array to a single disk isn't something I really look forward to. If I have to do all kinds of interesting partition/block alignment tricks, filesystem tweaks, and whatnot to the drive to get it ready, I may as well install Gentoo from scratch while I'm at it. I haven't really looked into simple data migration like making a tarball of the entire root FS and copying it, or anything like that.<br />
<br />
However, the tips are appreciated. Still, for anything as convoluted as moving down a chain of Athlon XP/AMD64/Core2, I'd rather take the easy way out and make an offline backup of /home, and just perform a new install. It's also good practice. Let's me <em>really</em> create a lean, mean system, having learned some things about optimization and bloat prevention over time. Oh, and reinstalling lets me verify that the handbooks I write are still accurate. :)]]></content:encoded>
			<link>http://blogs.gentoo.org/nightmorph/2009/06/07/hardware-hackery#c21497</link>
		</item>
				<item>
			<title>In response to: Hardware hackery</title>
			<pubDate>Tue, 16 Jun 2009 07:43:51 +0000</pubDate>
			<dc:creator>Gordon Malm (gengor) [Visitor]</dc:creator>
			<guid isPermaLink="false">c21494@http://blogs.gentoo.org/</guid>
			<description>Hey Josh,&lt;br /&gt;
&lt;br /&gt;
Might want to avoid the OCZ Vertex, it has its own issues:&lt;br /&gt;
&lt;br /&gt;
http://www.techreport.com/articles.x/16848&lt;br /&gt;
http://www.techreport.com/articles.x/16979&lt;br /&gt;
&lt;br /&gt;
The Samsung and Corsair (Samsung rebadge) SSDs are the closest to Intel without breaking the bank.&lt;br /&gt;
&lt;br /&gt;
Also, no need to re-install (if you don't want to) most of the time.  I personally hate re-installing and pretty much never do.  A few Gentoo installs I still have running go back to '03 and started out on oldish P2 hardware (now Athlon X2s, Core2s, etc. with intermediate steps along the way).  All of them have seen between 2-4 different MB/CPU/GFX combos over the last 6 1/2 years.  It's a little different depending on each boxen's role, but for the most part its just prep a 2nd kernel for your new hardware, remove your persistent net/cd rules, remove any HW-specific services (sensors, hdparm, mdadm or whatever) and move the disk(s).  Once booted on the new hardware w/ new kernel just add services back to runlevels, change CFLAGS and a few other things.  Migrating disks/RAIDs is about the same difficulty (not), just a different process.&lt;br /&gt;
&lt;br /&gt;
If GCC auto-vectorization is used (gcc4.2-3ish @ -O3) you may need to recompile with the lowest common denominator beforehand (or mtune instead of march) depending on CPU compat.&lt;br /&gt;
&lt;br /&gt;
It can be a wee challenge the first time moving hardware around but you'll be able to do it in your sleep in no time.  Another cool thing about that is you'll gain valuable skills to recover a dead box using entirely different hardware quickly (as long as ARCH remains the same of course).&lt;br /&gt;
&lt;br /&gt;
The next time a non-redundant box dies @ work that needs to be back up asap and you don't have identical spares (happens) you'll have all the skills necessary to recover quickly with the hardware immediately available.&lt;br /&gt;
&lt;br /&gt;
The next step after that is moving installs from physical hardware to virtual machines (+vise-versa) and between entirely different VM solutions.  Usually this is only slightly more challenging.  I know there are some tools out there that claim the ability to do at least the phys-&gt;virt part for you.  But IME most of them work poorly at best and hide everything they are doing behind the scenes (which I also dislike).</description>
			<content:encoded><![CDATA[Hey Josh,<br />
<br />
Might want to avoid the OCZ Vertex, it has its own issues:<br />
<br />
http://www.techreport.com/articles.x/16848<br />
http://www.techreport.com/articles.x/16979<br />
<br />
The Samsung and Corsair (Samsung rebadge) SSDs are the closest to Intel without breaking the bank.<br />
<br />
Also, no need to re-install (if you don't want to) most of the time.  I personally hate re-installing and pretty much never do.  A few Gentoo installs I still have running go back to '03 and started out on oldish P2 hardware (now Athlon X2s, Core2s, etc. with intermediate steps along the way).  All of them have seen between 2-4 different MB/CPU/GFX combos over the last 6 1/2 years.  It's a little different depending on each boxen's role, but for the most part its just prep a 2nd kernel for your new hardware, remove your persistent net/cd rules, remove any HW-specific services (sensors, hdparm, mdadm or whatever) and move the disk(s).  Once booted on the new hardware w/ new kernel just add services back to runlevels, change CFLAGS and a few other things.  Migrating disks/RAIDs is about the same difficulty (not), just a different process.<br />
<br />
If GCC auto-vectorization is used (gcc4.2-3ish @ -O3) you may need to recompile with the lowest common denominator beforehand (or mtune instead of march) depending on CPU compat.<br />
<br />
It can be a wee challenge the first time moving hardware around but you'll be able to do it in your sleep in no time.  Another cool thing about that is you'll gain valuable skills to recover a dead box using entirely different hardware quickly (as long as ARCH remains the same of course).<br />
<br />
The next time a non-redundant box dies @ work that needs to be back up asap and you don't have identical spares (happens) you'll have all the skills necessary to recover quickly with the hardware immediately available.<br />
<br />
The next step after that is moving installs from physical hardware to virtual machines (+vise-versa) and between entirely different VM solutions.  Usually this is only slightly more challenging.  I know there are some tools out there that claim the ability to do at least the phys->virt part for you.  But IME most of them work poorly at best and hide everything they are doing behind the scenes (which I also dislike).]]></content:encoded>
			<link>http://blogs.gentoo.org/nightmorph/2009/06/07/hardware-hackery#c21494</link>
		</item>
				<item>
			<title>In response to: Hardware hackery</title>
			<pubDate>Sun, 07 Jun 2009 16:39:12 +0000</pubDate>
			<dc:creator>Josh Saddler [Member]</dc:creator>
			<guid isPermaLink="false">c21449@http://blogs.gentoo.org/</guid>
			<description>You must have missed all the links I posted to my threads in the SPCR forums . . . I'm well aware of the site. :)</description>
			<content:encoded><![CDATA[You must have missed all the links I posted to my threads in the SPCR forums . . . I'm well aware of the site. :)]]></content:encoded>
			<link>http://blogs.gentoo.org/nightmorph/2009/06/07/hardware-hackery#c21449</link>
		</item>
				<item>
			<title>In response to: Hardware hackery</title>
			<pubDate>Sun, 07 Jun 2009 12:44:45 +0000</pubDate>
			<dc:creator>Maffin [Visitor]</dc:creator>
			<guid isPermaLink="false">c21446@http://blogs.gentoo.org/</guid>
			<description>If you didn't know it yet http://www.silentpcreview.com is imo a great ressource on hardware with focus on silence and (as a side effect) low power consumption.</description>
			<content:encoded><![CDATA[If you didn't know it yet http://www.silentpcreview.com is imo a great ressource on hardware with focus on silence and (as a side effect) low power consumption.]]></content:encoded>
			<link>http://blogs.gentoo.org/nightmorph/2009/06/07/hardware-hackery#c21446</link>
		</item>
				<item>
			<title>In response to: Hardware hackery</title>
			<pubDate>Sun, 07 Jun 2009 07:24:18 +0000</pubDate>
			<dc:creator>Josh Saddler [Member]</dc:creator>
			<guid isPermaLink="false">c21443@http://blogs.gentoo.org/</guid>
			<description>&lt;strong&gt;Nirbheek&lt;/strong&gt;:&lt;br /&gt;
&lt;br /&gt;
Running a &lt;em&gt;git&lt;/em&gt; graphics stack? That's not bleeding-edge, that's off-the-edge-and-plummeting-to-your-doom crazy! :D&lt;br /&gt;
&lt;br /&gt;
But I may give it a shot. I do know that I'll need the DRM bits from a specific git branch of the upstream code just for working 2D, as until the filesystem stuff in 2.6.30-rcX is sorted out, I can't use the DRM in there. If I was willing to run a .30 kernel, it would greatly simplify things; I'd just need ~arch xf86-video-radeon and assorted packages. Nothing that isn't already in Portage.&lt;br /&gt;
&lt;br /&gt;
Thanks for the tip though; I'll keep in it mind!</description>
			<content:encoded><![CDATA[<strong>Nirbheek</strong>:<br />
<br />
Running a <em>git</em> graphics stack? That's not bleeding-edge, that's off-the-edge-and-plummeting-to-your-doom crazy! :D<br />
<br />
But I may give it a shot. I do know that I'll need the DRM bits from a specific git branch of the upstream code just for working 2D, as until the filesystem stuff in 2.6.30-rcX is sorted out, I can't use the DRM in there. If I was willing to run a .30 kernel, it would greatly simplify things; I'd just need ~arch xf86-video-radeon and assorted packages. Nothing that isn't already in Portage.<br />
<br />
Thanks for the tip though; I'll keep in it mind!]]></content:encoded>
			<link>http://blogs.gentoo.org/nightmorph/2009/06/07/hardware-hackery#c21443</link>
		</item>
				<item>
			<title>In response to: Hardware hackery</title>
			<pubDate>Sun, 07 Jun 2009 07:19:37 +0000</pubDate>
			<dc:creator>Nirbheek Chauhan [Visitor]</dc:creator>
			<guid isPermaLink="false">c21440@http://blogs.gentoo.org/</guid>
			<description>If you want to try out KMS, you might want to apply this to the x11 overlay and then use the resultant ebuilds:&lt;br /&gt;
&lt;br /&gt;
http://dpaste.com/52404/&lt;br /&gt;
&lt;br /&gt;
This should make it to the overlay soon as well.</description>
			<content:encoded><![CDATA[If you want to try out KMS, you might want to apply this to the x11 overlay and then use the resultant ebuilds:<br />
<br />
http://dpaste.com/52404/<br />
<br />
This should make it to the overlay soon as well.]]></content:encoded>
			<link>http://blogs.gentoo.org/nightmorph/2009/06/07/hardware-hackery#c21440</link>
		</item>
			</channel>
</rss>
