<?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"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: SimpleHelix won&#8217;t refund my money</title>
	<atom:link href="http://www.idiotz.nl/2010/07/28/simplehelix-wont-refund-my-money/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.idiotz.nl/2010/07/28/simplehelix-wont-refund-my-money/</link>
	<description>Just another idiot that wants to be heard...</description>
	<lastBuildDate>Wed, 18 Jan 2012 13:30:58 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: SimpleHelix, LLC.</title>
		<link>http://www.idiotz.nl/2010/07/28/simplehelix-wont-refund-my-money/comment-page-1/#comment-1378</link>
		<dc:creator>SimpleHelix, LLC.</dc:creator>
		<pubDate>Fri, 13 Aug 2010 15:43:53 +0000</pubDate>
		<guid isPermaLink="false">http://www.idiotz.nl/?p=144#comment-1378</guid>
		<description>Hello again,

The geographical location of a server is not necessarily advantageous. You have to account for the number of hops across backbones that are necessary to arrive at the destination. If one backbone has a slow hop, and that route is used, it can slow each subsequent hop which slows your response time from the server.

We understand that it may be more viable of a hosting solution for you to host outside the US, and wish you luck with your future hosting.</description>
		<content:encoded><![CDATA[<p>Hello again,</p>
<p>The geographical location of a server is not necessarily advantageous. You have to account for the number of hops across backbones that are necessary to arrive at the destination. If one backbone has a slow hop, and that route is used, it can slow each subsequent hop which slows your response time from the server.</p>
<p>We understand that it may be more viable of a hosting solution for you to host outside the US, and wish you luck with your future hosting.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Morriz</title>
		<link>http://www.idiotz.nl/2010/07/28/simplehelix-wont-refund-my-money/comment-page-1/#comment-1356</link>
		<dc:creator>Morriz</dc:creator>
		<pubDate>Tue, 03 Aug 2010 22:46:56 +0000</pubDate>
		<guid isPermaLink="false">http://www.idiotz.nl/?p=144#comment-1356</guid>
		<description>I understand your difficulties now with regards to my technical needs, and have assessed the option of upgrading to a full VPS (as I have now with my dutch host), but found it not only too costly, but was also not convinced it would bring down latency times (USA traffic to my current NL based host is faster than to your own US based servers?!). That is why I had no need for your services.
Anyway, I thank you for your thorough response, albeit a little late and only after I have tried numerous times to get a refund (by emailing with your sales department). What made you change your mind and grant me my refund after all? And why the strange policy to exclude paypal users their right to opt for a refund?</description>
		<content:encoded><![CDATA[<p>I understand your difficulties now with regards to my technical needs, and have assessed the option of upgrading to a full VPS (as I have now with my dutch host), but found it not only too costly, but was also not convinced it would bring down latency times (USA traffic to my current NL based host is faster than to your own US based servers?!). That is why I had no need for your services.<br />
Anyway, I thank you for your thorough response, albeit a little late and only after I have tried numerous times to get a refund (by emailing with your sales department). What made you change your mind and grant me my refund after all? And why the strange policy to exclude paypal users their right to opt for a refund?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: SimpleHelix, LLC.</title>
		<link>http://www.idiotz.nl/2010/07/28/simplehelix-wont-refund-my-money/comment-page-1/#comment-1355</link>
		<dc:creator>SimpleHelix, LLC.</dc:creator>
		<pubDate>Tue, 03 Aug 2010 21:43:31 +0000</pubDate>
		<guid isPermaLink="false">http://www.idiotz.nl/?p=144#comment-1355</guid>
		<description>Hi there,

I understand you have been experiencing some troubles in your webhosting endeavors with SimpleHelix. Please allow me to extend my apologies for this mishap. I would like to describe a  few things that caused limitation to your needs, as well as our PayPal  policy.

The requests that were made were vaguely related to creating a &#039;ram disk’ and caching commonly accessed files to memory. This is not dissimilar to allowing users to view your critical data out in the open. As documented here:

http://www.magentocommerce.com/boards/viewthread/73433/

Magento stores its cache with 777 permissions set, and in plain text, saves the database password. The unix users who also reside on the same server would be able to access said plaintext passwords, and this would raise SimpleHelix as liable.

This is why shared hosting is unusable for caching sensitive data. A dedicated virtual server or physical server on which no other user resides would be a great place to accomplish this style of caching because no one else is on the server to lift this data in the first place.

As for the PayPal situation, I absolutely sympathize with the issues you have experienced. On our website, it is displayed clearly in our terms of service:

&quot;If you paid using PayPal, you do not qualify for a refund.&quot;

This has always been our policy and upon registering for hosting. When you sign up for our hosting services, SimpleHelix and yourself enter a binding agreement. If either party were to break this agreement, the relationship would cease to function and we would be unable to render services. We apologize for any inconvenience, and we understand that a PayPal dispute may be necessary recourse for this situation. We do hope that this helps others to understand that is has always been our policy.</description>
		<content:encoded><![CDATA[<p>Hi there,</p>
<p>I understand you have been experiencing some troubles in your webhosting endeavors with SimpleHelix. Please allow me to extend my apologies for this mishap. I would like to describe a  few things that caused limitation to your needs, as well as our PayPal  policy.</p>
<p>The requests that were made were vaguely related to creating a &#8216;ram disk’ and caching commonly accessed files to memory. This is not dissimilar to allowing users to view your critical data out in the open. As documented here:</p>
<p><a href="http://www.magentocommerce.com/boards/viewthread/73433/" rel="nofollow">http://www.magentocommerce.com/boards/viewthread/73433/</a></p>
<p>Magento stores its cache with 777 permissions set, and in plain text, saves the database password. The unix users who also reside on the same server would be able to access said plaintext passwords, and this would raise SimpleHelix as liable.</p>
<p>This is why shared hosting is unusable for caching sensitive data. A dedicated virtual server or physical server on which no other user resides would be a great place to accomplish this style of caching because no one else is on the server to lift this data in the first place.</p>
<p>As for the PayPal situation, I absolutely sympathize with the issues you have experienced. On our website, it is displayed clearly in our terms of service:</p>
<p>&#8220;If you paid using PayPal, you do not qualify for a refund.&#8221;</p>
<p>This has always been our policy and upon registering for hosting. When you sign up for our hosting services, SimpleHelix and yourself enter a binding agreement. If either party were to break this agreement, the relationship would cease to function and we would be unable to render services. We apologize for any inconvenience, and we understand that a PayPal dispute may be necessary recourse for this situation. We do hope that this helps others to understand that is has always been our policy.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

