What do you mean run Ubuntu in a Chrome tab? Is this a full virtual machine?

He is probably using Crouton : https://github.com/dnschneid/crouton

A lot of their speed comes from special tricks like bypassing the kernel and going direct to hardware (DPDK).

Intel's DPDK doesn't support Mac OS X.

You should probably develop in a VM anyways, or at least with a platform + hardware that supports these features so you can better match what production deployments will be like.

I always cringe a little, for backend systems software, when people develop in an environment completely divorced from their production environment. It just creates headaches.

This is actually the most stressful part of dinner. Along with splitting a bill fairly.

Of course I can do it, but when I'm talking with people I'd rather do it much faster with less likelihood of a mistake.

Move the decimal point to the left. Boom, %10.

Move the decimal point to the left, then double. Boom, %20.

Problem with Snebu: it only does file-level deduplication I think which means storing something like virtual machine snapshots or images will not deduplicate well.

You need block-level deduplication to work well with things like VM images.

That is correct -- at this time it is only doing file level dedup, due to overhead and complexity of block level (or better yet, variable block level) deduplication. The file level dedup is done by computing the sha1 checksum of the file, and using that as the name to store the file contents under.

I've got a solution in the works specifically for KVM images, that hopefully I'll be able to finish up the next time I get a week off of work. The way I'm planning on handling that (at least for LibVirt based VMs) is to use libguestfs to create an equivalent to the `find` command (with all the -printf options that it supports), and to generate tar file output of selected files from the VM. (Snebu is designed around only requiring find/tar on the client side -- so anything that can produce this output will work). Although I don't like that libguestfs actually fires up a VM in order to work with the image files -- I may work on an approach to read the qcow2 file images directly. Again, looking forward to a vacation this spring so I can pound out that module.

My experience with attic (seems to be a trend with all of your dedup reviewed systems) is that it also takes a very long time to restore large amounts of data _however_ you have the option of restoring individual files via a FUSE file system which is _immensely_ useful.

An example was that a restore of ~200 GiB of VM snapshots took over a day from a NAS to the server in question.

Usually, the backups take about an hour to write out, so reading data from attic does take significantly longer.

This is probably because dedup is non-trivial to restore from (it can involve lots of random reads/disk seeks).

As some commenters mentioned, a meta-backup system that can manage multiple different ingest methods would be Deltaic:

https://github.com/cmusatyalab/deltaic

So a metatool that is flexible in terms of backup ingest? Almost like backup plugins?

Check out Deltaic, designed precisely for this:

https://github.com/cmusatyalab/deltaic

This tool certainly looks interesting and does support several sources for the backup.

I was describing a meta tool that would act like an experienced backup admin and setup the whole process / environment. E.g. this tool would configure network shares or a webserver with authentication to access the data, that deltaic restored.

However, such a tool does not exist, so I will study deltaic when there is some more time to waste with backup research. :)

I see what you're saying...kind of like an AI or an "automation" tool/framework for backup.

I was focusing on the lower-level building blocks.

With TCP_REPAIR, presumably they could...but both ends need to implement the REPAIR option I think, so maybe not in practice yet.

Or if the SDN of your cloud is good enough, even TCP_REPAIR might not be needed!

It's a custom SDN layer we wrote.

Precisely. Also perhaps why Telegram didn't respond.

This is an OS-/device-level attack---not an app exploit/attack.

Yeah...it doesn't feel like a true vulnerability...feels like just padding the "vulnerability" counter :p