No, he's definitely right. Work/life balance is definitely a factor in retention. If you can't check into your home security cam to see if your dog is chewing on the sofa, that may be worth a couple hundred in salary to you, and tens of those little things add up.

...but balefully less well documented, and full of feature sets that managers want to turn on that make it less reliable than the old gear/ware.

Really, if equipment and software providers would spend even 10% of what they do on sales on good documentation written by technical writers with priority access to engineers, IT would be 5 times simpler, and the presence of the documentation would more than make up for the lack of a few powerpoint slides and SE visits. Almost ALL my time is wasted trying to either figure out product behavior on my own or rub elbows with enough people until I find someone who can offer proper technical answers.

I have to agree with GP. SAN and virtual infrastructure isn't cheap, but neither are competent rack monkeys or business quality switchports. As long as you can avoid some of byzantinisms of managing the VMs it's better to have a sysadmin that does VM management part time than waste your network guy's time doubling as a rack monkey when he needs to be plumbing new features on the equipment. You end up with more talent at your disposal.

Yeah pretty much it goes like this:

1) Outsource existing application, burn out your IT staff on the migration effort, lose some IT staff
2) Try to get new application customized to a new need.
3) Remaining IT staff tied up in meetings and phone calls delineating the new need to the service provider.
4) Refresh all progress made in 3) again when your point of contact at the provider moves on to another company.
5) Eventually end up with consultants from the provider working as many FTEs on premisis as your IT staff did.

No, but they will surely raise holy hell when there's a BGP problem that kills access to the DNS server for their cloud service app and they can;t get any work done for a day while the ISPs bang it out.

Also some idiot will eventually drop PCI data on the cloud service, even if the service has no place to put it. They will find a way tp let their idiot light shine through.

I.... am glad I don't have your problems. Really the user base has gotten too lethargic. An occasional day-long outage due to an arp spoofing attack that the cheap-ass prosumer equipment cannot block can do wonders for an IT budget. Of course that's a lot of firing/hiring musical chairs because they won't remember that you told them the crap stuff wouldn't cut it.

Have fun with that "backplane" capacity :-)

(BTW these days you'd be looking at a 6800 not a 6500 unless buying used, and the Nexus only if you've got some majorly complex things going on in the server room. Also we gave up on paying the cisco premium on the edge a while back, and have never looked back. While Cisco has been fiddling with SLA, other folks have made much cheaper alternate edge switches with fully adequate feature sets.)

#like

A VM runs its own kernel.
Containers share a kernel, but have their own namespace so e.g. they see only their own process table
chroot jails just really control permissions and environment/libs

On the one hand all of them have some pretty compelling use cases like ease of moving machines to new/backup hardware. On the other hand they all lend themselves to horrible abuses and serve to keep crummy, buggy, code in service way past when it should be flushed down the toilet with extreme prejudice, and attract a swarm of people with awful instincts to create heinously bad UIs to administer them. And as someone noted above, often require network contortions after the fact when folks realize that yes, they needed some IPC between containers.

You think that's bad, you should see what goes on on the network side these days. All the layers of encapsulation can very often be larger than the innermost payload.

These days for heavy remote X use you use stuff like Xpra, also over SSH, as it can leverage hardware encoders which the X protocol didn't have at its disposal back when it was designed.

If your crypto is vulnerable in this way, it is not technically executed correctly.

I think it's possible to make the valid point that just hiding your communications, even if done perfectly, is not enough, and pursuing social change in addition to that is also needed, without casting baseless aspersions on cryptography in general. TFA strays too far towards the latter IMO.

That only a fraction of a percent of humanity is currently capable/willing to ensure that their crypto ducks are in a row is a more valid point, and how to get the general population to choose the right platforms/apps/providers when there is no way to establish trust relationships that is not vulnerable to everyone ending up trusting a prick -- that is also a valid point.

Eventually, however, social prohibitions against snooping will become impossible to enforce at the individual level, forget at the institutional level, just like it has become rather impossible these days to stop a determined individual from eavesdropping on face-to-face conversations, nor even prosecute them were a listening device discovered, if they were careful enough. There's a window past which the technical execution of strong crypto will be the only recourse left.

Yeah, I would say to the OP that it matters what information you touch or privileges you have in that job position, e.g. if you are running around to network racks with a "god key" having theft as a conviction would not be a good match.

I would say that, but the truth is that in a lot of places whether they even check is arbitrary, and then what they do with the information is also arbitrary. HR and hiring committees in general tend to be a quite slapdash.

Shoot a randomly speckled light pattern through a splitter. Put one copy of the pattern into a multipixel camera, then multiply what the multpixel camera saw with what the single pixel receiver saw after the second copy of the pattern bounced off or through the target. Rinse repeat, sum that array of pixels over lots of iterations. Basically that tweaked with additional statistics and physics for efficiency/accuracy. Perhaps eliminate the multipixel camera if you can find some other way to know the speckle patterns you emit.

Still not clear on how they get the duplicate of the post-scattering image when using a chicken breast as a scatterer, myself, though. Maybe they are acattering before the chicken breast and just have found additional math to compensate for the scattering in the chicken.

You're thinking too small. Used on lottery scratch tickets it would provide resources to then buy boobies and a beer to boot.