Time and time again I come across a business model based on Pay as you go (PAYG), which I don’t like.
I can see it being useful in some industries like mobile, with its low buy in cost and cost visibility. Though that usually comes at a cost. For example mobile calls on PAYG are more expensive than being on a contract plan. However PAYG is really convenient as you don’t have to go through credit checks, direct debits etc. to setup an account. Perfect if you are a teenager.
Admittedly there are some other good features of PAYG in the mobile industry, like showing roughly how much a mobile phone device actually costs. With mobile contracts in the UK the phone is often bundled into the contract. So “cost visibility”, knowing how much you are paying for the mobile device and the calls can be really difficult to know.
Anyway, last week I was chatting to a someone who was offering a PAYG hosting service framework. For example, he claims with his system is cost just 60-something pence yesterday to run his Website.
Ok, that might get some managers wet, but I do not want to pay extra if I out gun typical limits.
The fact is I am a power user. I smash typical bandwidth limits for breakfast. I upload, I serve, I create. 
PAYG plans punish me for doing something out the ordinary. Imagine Google on a PAYG Internet plan?
Hence I love Dreamhost. As with a typical cheap account I can tranfer huge amounts as typical users don’t use their accounts as heavily as mine. All for less than 10USD a month.
With T-online’s Web&Walk and Three’s unlimited internet plans, this is the trend. People did not want to pay per byte, hence these recent “ground breaking” developments of flat rate (contract) plans. So that’s why I say no to this type of PAYG.
Using my preferred email environment lately has been really painful.
- Losing connection to my courier IMAP server at dreamhost (perhaps blame the wireless) and having to restart mutt
- vim hanging after a save (see the screenshot)
Does this affect other people? Any tips? My configs can be found in my $HOME
Otherwise I have to use freakin’ gmail and cope with its problems.
No one is perfect.
Web services go down or go awry. Though what I really loathe is when administrators don’t share that information. Two services I use often are on that shitlist. Flickr and Google. Let me share my experience with Google:
- I notice something does not work like it was before
- Go through their help system
- Perhaps try a search and fail to find what I need
- Look at forums
- Ponder about posting to the forum, decide against it
- Send a mail/feedback (which can be really hard to find)
- Get an impersonal blanket response
- Later, get a email from Google whether the response was helpful or not… grrr
- End up just waiting and retrying again later at some random time
Kudos to Flickr in sense I’ve actually got to speak to a human in this regard. Though all that person did was say sorry and try again later. What Google and Flickr both need sorely is a public status page reporting outages.
Dreamhost do it right with DreamHost status.
Except when Dreamhost posts about machines that I don’t use. It could be a lot better, though if I was using some powerful RSS aggregator I could perhaps filter it.
I know it might look bad to maintain “public availability status” and it could reflect badly on your stock price in the short term. I urge you to think long term and build trust with your customers. Dreamhost went through a rough patch recently and I stuck with them because they seemingly tried their best to make their problems they were experiencing public.
Sometime this afternoon, KT one of the leading Korean ISPs change my IP address from
222.106.128.78 to 222.106.128.198.
CRAP
I’ve asked for a fixed address, but they said they couldn’t give me one.
So this has prompted me to move my repository and projects once again (previously hosted with Jamie in the UK) from Seoul to Dreamhost in California.
In the next day most of my other hosted projects won’t work and this site will look a little funny. In the next few days almost everything will be working except Trac.
I’ve not been able to get Trac working without unacceptable crufty URLs in Dreamhost.
Update: Everything up again, including http://trac.natalian.org/
One of the major problems I see in Korea is the complete lack of remotely decent hosting.
Admittedly finding a host in the UK or US is hard, but here it’s impossible. Really.
The leading Korean registrar inames offers a “complete solution” where it doesn’t even offer advanced DNS management. So I can’t add an A name record for a subdomain. It’s just completely featureless. You’re lucky if PHP works on your FTP space.
Thank god (for want of another expression, as I don’t believe god exists) for Dreamhost. I’m now hosting more and more of the company services on my own account!
Whoever is remotely interested in Web stuff in Korea has some serious stumbling blocks to contend with.
I subscribe to mailing lists on hendry@dabase.com, but I send from different shells where the return path isn’t the same.
So time and time again I can’t contribute to free software mailing lists. Mailman typically gives me a:
Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list
Whilst the human moderator usually never moderates (blame spam) or moderates far too late. Thank you Debian list managers for getting your policy right…
The fix for Linux users is simple. A mutt configuration like:
set envelope_from=no
set sendmail='/usr/lib/sendmail -oem -oi -f yourremail@example.com'
Will normalise your return path, no matter which shell you use.
Dreamhost are great and everything, but it can be quite difficult to make full use of one’s host.
For example. I have more diskspace, so I was thinking of hosting a copy of wikipedia and abusing my near unlimited bandwidth. Not so fast:
pico$ bunzip2 pages_articles.xml.bz2 Killed Connection to dabase.com closed by remote host. Connection to dabase.com closed.
Hmph. Next things I’ve been playing with is Ruby on Rails.
Though I read the Wiki page I am experiencing Application error (Rails) whilst using Fast CGI. It’s a bit odd and somethings work. I know without Fast CGI, development iterations are extremely slow. You’re basically going nowhere without something like Fast CGI.
Then I had a look at web.py. It seems to require mod_python and again DreamHost doesn’t seem to support this module. Oh crap.
Django seems to be able to utilise Fast CGI and I tried a very basic sanity test for Fast CGI via Python and that doesn’t work either.
So where are we? Back at square one. This blog about The sysadmin view on PHP is actually quite right. It is so easy to deploy a PHP application in comparison to Rails and Python.
I almost forgot I work with Java, tomcat, JBoss and other hopeless Enterprise technologies. They need the server to come down to deploy. That’s Web 0.0.
Update: Dreamhost support spotted an error in my database.yml. It’s working! WOOT!
Update: With the help of Aaron Swartz I managed to get a web.py “hello world” working with fastcgi on dreamhost.
Update: Django on DreamHost does work. I missed the part about fcgi.py. Oops.
I had trouble reading my mail and you might as well had trouble accessing this site. Evidently Dreamhost was dealing with a distributed denial of service attack.
I liked the way they updated their status page humourously. Some other admins would have been hopping mad.
I don’t run anything too critical on Dreamhost. Though I often suggest companies outsource their mail to them. So if I was using Dreamhost for managing a company’s IT needs, the company’s email et al would have been out of action for half the day.
mod_rewrite is a pain to work with. In order to debug you need RewriteLog and if you’re on a shared host you’re probably stuck with evil .htaccess where Rewritelog is:
.htaccess: RewriteLog not allowed here
So what does one do?
While preparing alpha Debian packages for WP 1.6 I looked at the htaccess Wordpress generates. It’s just:
RewriteRule . /index.php
I didn’t know you could do this. This makes it so much easier to de-crufy URLs. I started an interesting thread on Wordpress hackers which details this sane URL rewriting technique.
Here is the code that implements Wordpress URL rewriting in PHP.
Why didn’t I heed my own advice?
I tried to get Subversion working at Dreamhost.
Honestly, I tried.
So that makes Subversion close to useless in large computing environments which generally always run NFS to provide mounts. 
It’s a miracle I am still using Subversion knowing what I’ve been through. Omg the Berkley stuff still gives me nightmares…
So I moved back my repository to Jamie’s ADSL hosted unstable box.
At least now you can see what I’ve been up to.




