71–80 of 83 posts
Looks like someone gamed this poll. 36 of Linode's 93 votes came from newly created accounts. (For comparison, 1 of Amazon's 78 did.) I think in future I'll ignore votes of newly created accounts in polls. For now I'm going to manually subtract them.
Earlier quoted context omitted.
Being able to pay by the hour massively, massively reduces the capital expenditure required when launching a public site? You can launch on a relatively cheap $75-$150 a month and then if you get Slashdot/Digg your code can automatically scale and only pay for the extra capacity when you need ... that's kind of the point of the service. Check out Bezos at startup school last year talking about animoto : http://omnisi…
Some languages/frameworks etc scale better than others. Making that choice is very important. $75-$150/mo is quite a lot really unless you're getting lots of traffic. I can see the case for this sort of scalability if your traffic is wildly unpredictable - eg 1 visit one day, 100,000 visits the next - but I think that's rare.
Looks like someone gamed this poll. 36 of Linode's 93 votes came from newly created accounts. (For comparison, 1 of Amazon's 78 did.) I think in future I'll ignore votes of newly created accounts in polls. For now I'm going to manually subtract them.
This may have something to do with it. Did you manually subtract votes from all newly created accounts or just Linode's? http://is.gd/xuVf http://is.gd/xuUZ http://is.gd/xuVE
Earlier quoted context omitted.
64 bit binaries consume dramatically more memory, thus, unless you have more than 4GB of available RAM, running a 64 bit system is simply stupid.
There are cases where you need more than 4 GB of virtual address space even if you're not actively using 4 GB of physical memory. Our application, for instance, uses mmap heavily and pretty easily tears through 4 GB of address space while comfortably running on a machine with less RAM. One other nitpick I'd add there is that 64-bit runtimes consume drastically more memory -- mostly meaning interpreted languages, JVMs…
Perhaps there are special cases where it still makes sense, despite losing memory (though your example use case makes me feel funny, and not in a good way, but I don't know enough about such things to argue), but in the general web hosting case, it is stupid to have a 64 bit OS with less than 4GB of RAM. As you note, the difference is much more dramatic in dynamic languages (Ruby, Python, PHP, and Perl applications simply explode in size when run on 64 bit systems...like 50%-75% larger).
Looks like someone gamed this poll. 36 of Linode's 93 votes came from newly created accounts. (For comparison, 1 of Amazon's 78 did.) I think in future I'll ignore votes of newly created accounts in polls. For now I'm going to manually subtract them.
Earlier quoted context omitted.
There are cases where you need more than 4 GB of virtual address space even if you're not actively using 4 GB of physical memory. Our application, for instance, uses mmap heavily and pretty easily tears through 4 GB of address space while comfortably running on a machine with less RAM. One other nitpick I'd add there is that 64-bit runtimes consume drastically more memory -- mostly meaning interpreted languages, JVMs…
A 64-bit OS build consumes more memory, even if your app does not. Perhaps there are special cases where it still makes sense, despite losing memory (though your example use case makes me feel funny, and not in a good way, but I don't know enough about such things to argue), but in the general web hosting case, it is stupid to have a 64 bit OS with less than 4GB of RAM. As you note, the difference is much more dramat…
mmap is a way of treating files or parts of files as memory when interacting with them and is used pretty often in low-ish level stuff that does file wrangling as it's one of the more performant ways of doing random access on a file. Since those files are being accessed as memory they consume space from the 4 GB of address space on a 32-bit platform, but don't take up physical memory (except insofar as their contents is cached in disk buffers).
That's one thing that's often misunderstood with the 32-bit limitation -- address space is limited; modern "32-bit" CPUs have used 36-bit addressing internally for quite some time, meaning they can address 64 GB rather than 4 GB of RAM (http://en.wikipedia.org/wiki/Physical_Address_Extension).
Because of the address space limitations you also don't have a full 4 GB to work with inside of a process on 32-bit platforms -- if you try to allocate a 3.5 GB block of memory it will usually fail because there's no contiguous block of address space available, even if there's 3.5 GB of unused memory. Typically the Linux kernel reserves 1 GB of address space for itself, and user space reserves a block for memory mapped I/O devices as well.
There's a pretty good article explaining some of this here:
http://kerneltrap.org/node/2450
Now, all of that said, I'm not disagreeing with your advice -- just noting that there are some (mostly corner-) cases where you do need the address space, but may not need the physical memory.
Looks like someone gamed this poll. 36 of Linode's 93 votes came from newly created accounts. (For comparison, 1 of Amazon's 78 did.) I think in future I'll ignore votes of newly created accounts in polls. For now I'm going to manually subtract them.
I'm confused at the numbers then: 93 - 36 > 24 (current number of votes)