Certainly.

Or perhaps you were looking for something entirely different.

VirtualBox isn't representative of the majority of the use cases under discussion here. I work with large KVM and VMware ESX deployments every day, and every single file and database server I use in enterprise environments is virtualized. Performance is not a problem, even for heavy workloads. Latency is not an issue, either. I won't beat a dead horse in this thread, but I will offer my advice via email if you'd like a few additional ideas regarding your stated use case.

Things happen. Sometimes very nasty things happen. Attempts at suppression of information related to nasty things will inevitably fail, and such attempts will only serve to cast those advocating for suppression in a nasty light themselves. "Authorities" might find their time better spent pursuing criminals instead of engaging in an odd attempt to force the populace to bury its head in the sand on threat of imprisonment. The information itself isn't the problem; direct harm caused against human beings is.

TLDR: Scotland Yard can go fuck itself, and I think this is a great time to make a personal project of facilitating the spread of this information as widely as possible. Thank goodness I've got a great deal of resources available to assist in that endeavor. Cheers, mates.

I like how you didn't bother to directly respond to any of the points listed. Your apparent inability to properly tune a virtualization host and its guests is your problem, and not reflective of the current abilities offered by modern virtualization systems. To address your point regarding GPU losses, if you're really that concerned about such issues on server systems, you're welcome to give host passthrough a shot with one of your guests; a lot of nice work has been done in that area lately. That said, these are indeed server systems we're talking about, and for the majority of use cases the only displays involved are the odd VNC/RDP session. What was your point, again?

Modern virtualization doesn't have the overhead the GP cited; the 20% RAM loss and 30% CPU capacity loss numbers cited by the AC you responded to are absurd fabrications. I use KVM on Debian hosts to power a large number of VMs running a variety of operating systems, and the loss of CPU bandwidth and throughput with guests is negligible due to hardware virt extensions in modern CPUs (where "modern" in fact means "most 64-bit AMD and Intel CPUs from the last few years, plus a small number of 32-bit CPUs"). Using the "host" CPU setting in guests can also directly expose all host CPU facilities, resulting in virtually no losses in capabilities for mathematically-intensive guest operations. As far as memory is concerned, far from resulting in a 20% loss of available RAM, I gain a significant amount of efficiency in overall memory utilization using KSM (again, used with KVM). On a host running many similar guests, extremely large gains in memory deduplication may be seen. Running without KSM doesn't result in significant memory consumption overhead either, as KVM itself hardly uses any RAM.

The only significant area of loss seen with modern virtualization is disk IO performance, but this may be largely mitigated through use of correctly tuned guest VM settings and updated VirtIO drivers. The poster you replied to is ignorant at best, and trolling at worst.

Please see propagation delay.

I want to know who the hell shoots a rifle from the hip at all.

Given a reasonable toolbox, that's arguably a reasonable proposition these days, at least for many devices in your immediate vicinity. Yes, things really are that bad.

Perhaps you should look into multiple accepted meanings for a word before you further embarrass yourself with ill-informed commentary.

You seem to be making the implication that it's not okay for Linus to loudly complain about a compiler that produces a broken Linux kernel. Why is that?

Quoting http://en.wikipedia.org/wiki/A...

Please describe all the platforms you presently use which do not support ASCII, and please provide statistics on the market presence for such platforms.

Whoosh.

I'm curious why you capitalized "black man" as you would a proper noun, but failed to properly capitalize Perl.

How shall we define importance? In terms of scope, are we talking about kernel space, userland code that humans directly interact with, systems/infrastructure code, data processing systems, or something else entirely?

Does your shop have a relatively narrow development scope? Over the course of my career, I've found that single language shops are either fairly tightly tied to a small set of problem domains, or they're full of people who see every problem as a nail so to speak. The latter condition is an unfortunate state of inflexibility that tends to extend into other areas, including higher level systems work and network architecture. I'm not saying your organization suffers from that affliction, but I would like to understand a bit more about the sort of development your team does. For the record, I'm a big fan of mature systems in general, and for most of my work various combinations of Perl, Bash, C, and Python gets the job done (usually in that order).