Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

One of the website providers I use (Pair) for 20+ years used to be exclusively FreeBSD. I believe they use a lot of Linux now. Not sure why.


Ah, pair. Reminds me of this gem:

http://www.archub.org/ycoutage.txt


Seems reasonable to me:

... This site and this directory were driving up server load averages, which causes instability for all users on this server. Our block on this site appears to have blocked over 150,000 connections in about half an hour. This is simply more than is appropriate for a shared server.

You may want to review your domain's traffic logs to see what kind of traffic this site is getting. The logs for today will be distributed at midnight EST tonight. If the traffic to this site is legitimate, you should look into a dedicated or a virtual private server. If the traffic is not legitimate, you should block it. I can provide assistance with that if you need it.

This domain and this directory will need to be disabled until traffic dies down, traffic is blocked, or your account is upgraded from shared hosting. If you need access to the directory so that you can make any necessary changes, please let me know.


Sure, it's reasonable, if your desired outcome is to lose a customer by

a) demonstrating a lack of burst or headroom capacity and/or graceful degradation/priority scheduling capability, and

b) being a dick about it.

Alternatively one may intervene with a positive approach and framing viz. "we have temporarily [provisioned additional capacity / relocated your storage to another spindle / mirrored your content to a less congested host / etc] in order to handle your traffic, can we call you tomorrow to move you to a service plan that can handle your growth". Even just throttling the account in some appropriate fashion would've been better than the blunt "we dropped you like a hot potato" that was actually communicated. This was in 2010, by which time any ISP that wasn't operating as amateur hour had the tools for all these things.


> This was in 2010, by which time any ISP that wasn't operating as amateur hour had the tools for all these things.

Agreed. Also consider that shared hosting packages are very much providers scraping the bottom of the barrel for some marginal extra revenue. Shared hosting customers are not the highest priority of customers, unless your entire business is based around shared hosting (in which case, you are likely operating as amateur hour anyway)


depends on what product/service plan they had. a 5$ per month is not worth jumping through the hoops, because usually an individual solution is needed, but this doesn't scale. if the site is important to the owner, they need a more fitting service plan with higher headroom. that being said, a good provider at least tries to filter out what could be a (d)dos


In 2010, those tools were not easily available outside massive Enterprise solutions like Akamai. Cloudflare just launched in 2009 and on-premise hardware was generally cost prohibitive.


I was building ISPs from the 1990s. The idea that after decades of innovation and field experience, tools for managing bursty/high-growth customers were somehow "not easily available", or that hardware be some kind of unicorn resource, just smells to me like rank incompetence. In this case coupled to an equally questionable customer retention failure.


In many industries it's standard practice to cause pain to one customer to avoid causing pain to all of them. If you've ever had work done on your house, a small guy who overruns will often bail out on your job ( and reschedule) rather than slip all the other customers he had lined up. so I can see why this guy decided to disable a directory rather than all the other customers in the server have slow service

The issue is that the economics are different: a roofer doesn't earn more by doing one big job than 4 small ones in the same time. But a big user is a better economic prospect to a service provider than the small ones. That's why this was clearly a dumb move


That's not even remotely reasonable.

They should have been monitoring load and notified the customer before it got to the point that they were worried about stability.

Shutting down a customer's site without warning when you could have notified them of a problem in the near future... well, that's a great way to lose a customer. I really hope YC promptly moved to another provider after that incident.


If this was their first and only mail on that yeah it's not the best way to handle. But then my sites don't generate anywhere near the traffic as YC even YC of 2010


I used them for shared personal website hosting until the Obama era when they were mostly/all FreeBSD. I moved off around the time AWS came about.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: