It's more of a capability thing. If you're running, say, Piston cloud you're using ceph over ethernet to back your disks, so you can easily decouple disk usage and ram usage. If you're stuck using local disks (ie. rackspace/joyent/linode/amazon to a point/etc.), then it's a lot harder to provide that sort of product.
That being said there are providers out there that sell it, and have been for years.
This makes sense when you keep in mind how the older clouds work (essentially VPS providers 101).
You have a server with some disks, some ram and some cpus. You aggregate the disks together, then split them to form the individual disks for the virtual machines. You then use kvm/xen to provide isolation as well as to split the ram/cpu between the virtual machines.
So to answer your question: Storage/ram/cpu is sold in lock step because otherwise there would be resources sitting on servers that are unable to be sold. Bandwidth isn't constrained like that because bandwidth isn't a thing tied to a machine.
There are some providers out there that don't lock ram/disk together. This is mostly because they use a distributed storage pool rather than local disks. This is significantly more complex and is a 'fairly' new addition to the scene (~2010?).
This is also why certain providers still charge you for ram even when your machine is turned off, and why backups/migra
tions/plan upgrades can be a bit of a pain in the neck at times.
Key value stores are useful, and they are especially useful in this form factor. On the other hand, you now have a very large black box that you have to somehow navigate in order to create a workable system. Given that this is likely an arm core running linux on the inside, I would have considered a slightly more open approach to be 'Here's a working KV store using backing db X and here's how to reflash it if it doesn't quite work for you'.
Using external kernels isn't in any way fundamental to the way Xen works. Most standard setups (even PV) have the kernel inside the VM, which allows for standard upgrades, etc.
I saw that, but it doesn't seem to implement any of the indexes you'd need in order to run a bloom query efficiently.
That being said, if you stored your bitvector as an array of powers of two, then it would work. But that would be horribly inefficient in terms of space usage.
Cloud done right. Hardware that is approximately indistinguishable from tin sitting on your datacenter floor, pay by the second.
To elaborate slightly. I mean hardware that you can run anything on, complete with full BMC, fast persistent disk storage (1K IOPS+), and any number of full layer 2 cross connectable networks. All pay by the second.
Already a major company in Australia with enterprise and government clients. Coming to the US soon.
An an improvement though, you only need two independent hash functions to run your bloom filter[1]. Strangely enough, this isn't well known and as such isn't implemented anywhere near as often as it should be (ie. it's not implemented here).
Anyways, the major problem is that shares and options are taxed like income at the time of issue, with no easy way to defer the tax bill. This makes it essentially untenable to hand out equity to employees. This then makes it a lot harder to employ people as a bootstrapped startup.
It wouldn't surprise me if it has something like GCJ creating something like a .so that it loads on the fly. That is just a thought though, i haven't inspected it particularly closely.
ssltrip requires a valid root ca, or an ssl library that doesn't check the signing chain. After using it though, the parameters are unencrypted and so can simply be sniffed.
Are you attempting to reencrypt the parameters with another key? If so then why run that through https?
1) You know the hash function beforehand
2) You know that they are salting in exactly this way
3) You know how they are doing their salting (HMAC vs., vs.)
4) You have enough time to create this new rainbow table
5) You have only just enough access to the system to dump the hashes (ie. the easier routes are blocked off from you)
That would in fact, with some probability (based upon the complexity of your rainbow table and the complexity of the users password), give you the passwords for a particular set of users.
I did say that it was more secure then it seems, not that it was perfectly secure :)
Having a password salted with the username fairly easily balloons out the complexity of building and searching a rainbow table by a factor of the number of usernames you want to be useful for. This factor is larger then you'd expect, given the sheer quantity and variety of usernames in various systems.
For a targeted attack it really doesn't matter as the time complexity to produce the rainbow table is equivalent to that of simply brute forcing the hash, ie, you can't say 'well assume the rainbow table contains only some small number of usernames"...
It also is entirely unlike the WPA2 rainbow tables in that you don't have millions of users all sharing the same username (ie. factory default SSIDs).
Overall it's more secure then it seems at first glance but you still have to ask yourself why you'd use that over a random salt.
DNS doesn't play particularly nice when you try and load balance it. You end up, essentially with issues with end users caching particular ip addresses and either failing when they shouldn't or causing load imbalances on particular servers that you can't seem to fix.
You probably want to have an external dns host returning two ip addresses for a haproxy or LVS cluster, which you then route into your actual web tier.
You can in fact bond for 2gbps if you are on two different switches, in two completely different ways.
One way involves the use of cisco stacking switches, allowing you to use 802.3ad between two independent 'stacked' switches. You can also use the external PSU to provide redundant power to each switch (giving each switch redundant PSU's and having each switch redundant).
The second involves the use of the linux bonding driver in balance-rr configuration. This has a slight bug with the bridge driver in that it sometimes won't forward ARP packets, but if you're just using it as a web head or whatever, you don't really care about those.
The 'big boys' do use ibgp/etc. internally, but that's for a different reason: At large scale you can't buy a switch with a large enough MAC table (they run out of CAM), so you have routers at the top of your rack that then interlink. You can still connect your routers with redundant switches easily enough with vlans and such (think router on a stick).
That being said there are providers out there that sell it, and have been for years.