http://ycombinator.com/newsnews.html#15jan09

Is that quest over, or is upgrading the server fair game? :)

Note the collorary: with a sufficient business model you can earn arbitrarily large amounts of money relative to hardware costs.

Which always makes me wonder why the clooooooooooooud gets so much press for cost reduction. If your application doesn't value data by weight (or worse, values data at 0), your hosting costs are going to be rounding error. Reducing the rounding error to half-sized doesn't strike me as the number one best use of time for the majority of businesses.

Elastic scalability is a major advantages in some cases, allowing you to rapidly scale up (and back down) while minimizing waste. "The cloud" absorbs the fluctuations.

Easy deployment and thus reduced administrative costs might be another. With EC2, etc that's might not be the case, since you still have to set up the OS images and other infrastructure yourself, but things like Heroku might help.

There's now enough memory that we can fit all the links and comments in memory at once again. We should be good for another year or so.

http://en.wikipedia.org/wiki/Robert_Tappan_Morris

* MIT Prof

* creator of first internet worm

* cofounder of viaweb and ycombinator

That's rtm's father, not rtm.

  pg: Robert, do you have anything to add?
  rtm: No.

It could solve the growth problem, perhaps?

New: 3.0 GHz Core whatever, 12 GB RAM, 64-bit FreeBSD 7.1.

And by "FreeBSD 7.1" you mean 7.1-RELEASE-p3, right? :-)

We've got a simple functional language here - being very unscientific, and looking at the key data structures, for my current workload, straight pointers are about 5-10% of the allocation. In practice I do see a 10-25% memory usage increase going from 32bit to 64bit (Linux).

(Anecdotally -- I've read 20% is a rough rule of thumb for 64bit anyway).

There is also an increase in data structure size due to data alignment, but this is going to vary quite a bit -- depends on the structure, the compiler -- and if you're doing dynamic memory allocation you may even find it makes no difference at all -- as malloc may have been delivering an oversize allocation anyway.

So, it's certainly not a trivial increase... Especially as we're currently running on a 256mb slice (I sort of wish they had a supported 32bit option)... but it's not massive.

However, for us, 64 bit still has a lot of advantages. For example, you can do more expansive memory mapping and the like.

Not sure if that helps.

arc runs in MzScheme 352 (http://download.plt-scheme.org/mzscheme/v352.html)

the freeBSD binaries on this page are i386, if thats what the new server is using then it won't make a difference. The source is available as well, if pg compiled the source in 64 bit mode it would increase memory usage.

But using a 64 bit OS doesn't necessitate using a 64 bit address space.

If your compiler is unfriendly, your structure size can change significantly -- afaik, GCC is pretty clever about structure packing, but I'd imagine it varies a lot depending on the architecture.

Could you explain why to me? I just can't remember. I think I might be suffering from mnesia.

Until now I only knew that erlang can span multiple hosts - but only when you wrote your application that way?

What has really helped us in terms of machine migration (but at the cost of additional overhead) is running stuff inside Xen and OpenVZ virtual machines. Those can really be migrated seamlessly - often without a noticable downtime.