asharp

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.

Also look at https://github.com/Seagate/Kinetic-Preview

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'.

Bitrot? Error recovery? SMART data? ...?

That doesn't seem to agree with http://www.fujitsu.com/downloads/MICRO/fma/pdf/LCD_Backgroun... .

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 think you should take a quick look at oracle's exadata machines. Mostly because they are both distributed and ACID compliant.

Does this method have a name/are there any reasonable papers out there describing it?

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.

I believe that you can index the bloom column, to some extent, with some hacks.

A major problem is a lack of indexes in array elements, which then forces you to build an otherwise unneeded table.

That being said, it's definitely doable, to some extent.

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.

Cool speed hacks.

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).

[1] www.eecs.harvard.edu/~kirsch/pubs/bbbf/rsa.pdf

Mmmm. Strange.

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.

Would you mind elaborating?

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?

Sure you can, assuming:

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).

From what i've read, the problem is that an attacker can add commits with forced Author information into a central repository to frame somebody else.

Wouldn't the signing of all commits as they are committed solve this problem? (ie. rather then trusting Author information from the commit, trust the signed-by information to give author information?)

From my understanding, I think they meant that mosh would deal with the more congested conditions better then ssh, thus providing a better experience. Just a hunch though.

That being said, mosh is rather cool ^_^

Be careful with that on rackspace. If I recall correctly, they use a credit scheduler with burst capacity. You need to be sure that you're not just getting a bunch of burst capacity and factoring that in with your cost calcs.

Is that their dNAS product or something else?

As I remember rackspace is a cloud in the same sense that Linode is a cloud, but not in the same sense that Amazon is a cloud, ie. they've taken an existing vps product (Slicehost) and resold it under the 'cloud' brand rather then developing something new from the ground up as a cloud.

Here's to hoping that its cloudfiles implementation no longer uses a file replicated sqlite db for indexing. (iirc it did earlier on. Scared me stupid when I found out).

I'd say that the major reason is cost.

Inside Australia you have the major peering fabrics which are on the order of a dollarish a mbit (cap). Compare that to $50-200/mbit for international transit and you'll see the problem. Quickly compare the cost of a gigE link.

About the only "international" player that doesn't (really) have this problem is NZ. Transit to NZ is ca $5/mbit last time i looked at it.

For the non network admins amongst us: http://lists.ausnog.net/pipermail/ausnog/2012-February/01222...

Keep in mind that EC2 is simply one very specific case, and you can sum up a good portion of its problems with "It's designed to be cheap to build".

You are correct in that you need performance parity for two items to be comparable.

You are incorrect in saying that you take an order of magnitude performance hit when Virtualization, especially for CPU bound tasks [1].

In terms of disk you are slightly more correct, you can lose substantial performance, however it's still not an order of magnitude.

[1] http://blog.xen.org/index.php/2011/11/29/baremetal-vs-xen-vs... (A series of benchmarks showing a disparity of ~1% off bare metal on CPU bound tasks.)