Terms of Service Updates

Hi all,

I wanted to make a quick post mentioning some changes to our Terms of Service. These additions were made to improve overall performance on the shared servers.

In section 2, we've added the following to examples of unacceptable material for shared servers: ... image, filedump, or banner-ad services (similar to rapidshare, photobucket, or commercial banner ad rotation). [...] topsites, commercial audio streaming (more than one or two streams), locally hosted chat scripts [... and the] sale of any controlled substance without prior proof of appropriate permit(s).

In section 7, we've added: 7c) Run any type of web spider or indexer (including Google Cash / AdSpy) on shared servers.

sale of any controlled substance without prior proof of appropriate permit(s): We really had one type of site in mind (viagra/cialis and illegitimate sale of prescription drugs) when we added that clause, but we left it slightly broad for safety's sake.

locally hosted chat scripts: This is not really about the chat scripts themselves, but rather simply because, if your chat room is decent, you'll have lots of very long-running php (or other) processes as everyone chats away all night. This is obviously bad in a shared environment, and is similar to a daemonized process (which is not permitted).

commercial audio streaming: In all honesty, this clause is aimed at the few clients who have chosen to (a) stream audio to hundreds of listeners from a shared server, (b) setup a commercial radio station on a shared baby croc account, or (c) uploaded mp3s to their space and shared the link with a few thousand of their closest friends. It's simply not appropriate.

Run any type of web spider or indexer (including Google Cash / AdSpy) on shared servers: Both Google Cash and AdSpy Pro consume a HUGE amount of processor when loaded up with a decent dataset. Additionally, many users were running the crawlers every 5 minutes. On both fronts, it caused performance to suffer.

The rest of the additions: The reasoning behind these additions is simple: In almost all cases, these activities seriously impact the CPU on a shared machine. To protect the performance of the shared servers, it was necessary to make these additions.

As most of you know, bandwidth is generally not a problem - it's easy to get, and all it takes is a phone call if we need more. CPU, on the other hand, is exponentially more expensive when it's time to expand (compare 4-way motherboard pricing with 8-way boards, for example). CPU, generally, is finite. The activities listed above, by their very nature, require massive amounts of hits to become profitable/worthwhile. We overlook short spikes in CPU, but these activites have proven to have more of a long-term running effect on a server, and consume a disproportionate amount of CPU.

Some hosts would rather say publicly "You can do absolutely anything at all on our shared servers" and then privately cancel/suspend accounts when they consume an excessive amount of resources, but I prefer to lay it out on the table. We want to prohibit as little as possible on our network so that everyone has a good time; in cases like these, it is necessary.

I hope that those of you that may be impacted by these changes understand, and perhaps sales can work something out with you regarding an upgrade. Thanks, and enjoy the rest of your 4th of July!

[gwyneth]

It was nice to be alerted about any changes, even if they may not apply, and very nice to have an explanation of the thinking behind them.

Thanks!

[riostyles]

I have already an indexer installed since ever and on a monthly basis index some internal sites and on a six month basis a handfull of externals sites. As now, I had no complaint. It is Zac's FDSE engine with a multisite license. I never observed the load growing when he is running.
Do this hurt the TOS?

[kmaw]

Maybe yes... but as we've noticed in the past, HG often only enforces the TOS when you get nabbed for high CPU usage (like with the inodes limit)... so you could probably take your chances... are you a gambling person? lol

[Serra]

Yes, people can skirt the TOS for months before getting caught. They seem to complain that something they've been doing for months is suddenly a problem. Really, its always been a problem, they just didn't get caught.

[smp]

Originally Posted by kmaw

so you could probably take your chances... are you a gambling person? lol

lol well i'm a gamling person (lost $30 in the last 3 days) but I wouldn't gamble with HG's TOS.

Riostyles, if I was you i'd submit a ticket and get a quick definate answer rather than waiting for a gator to respond on here.

Regards, Steve Xx

[Break the Silence]

Originally Posted by GatorJamyn

The reasoning behind these additions is simple: In almost all cases, these activities seriously impact the CPU on a shared machine. To protect the performance of the shared servers, it was necessary to make these additions.

A lot of it strikes me as plain old common sense...

A.K.A. If you're going to be running CPU intensive applications, then don't try to do it on the cheap through the backdoor.

On behalf of all the little guys, thanks for taking the time to stay on top of this.

[riostyles]

For to be clear, I am a quiet HG user and (I hope) never use much CPU, nor my customer, I watch them closely and on aregular basis.
My fact is that when I moved in, about 15 months ago, I had this indexer. I tested it against the cpu like I did with other heavy scripts.

Today a new TOS comes-up so I was just naively wondering about my search engine working smooth now since 5 years and glean some opinion before, eventually asking HG.
I am not a gambler in this matter nor run "Intensive CPU applications", I do not skirt the TOS it is the TOS skirting me, maybe.

Regards.

[bliss]

How do you find out how much your shared hosting is using of the cpu? Is there a way?

[riostyles]

Originally Posted by bliss

How do you find out how much your shared hosting is using of the cpu? Is there a way?

They are some ways with shell, eventually over php exec. They are not direct but doing tests on a regular basis you can estimate the load per script per deduction. You can establish also some correlation with the BW use for the scripts serving trough Apache.
Until a few months ago we had acces to our processes load and memory use but this disspear and was not safe.

[Sam]

Originally Posted by bliss

How do you find out how much your shared hosting is using of the cpu? Is there a way?

You can ask support