cwoac

Odd, the default according to the docs is now flannel. Note that that is the default choice _if you ask for network in your configuration_, otherwise it doesn't do any (this caught me out).

Rook is doing OK for me so far, but be warned, the api is seemingly quite volatile at the moment

For ingress on bare metal (I assume that is what you are using), either nginx-ingress (for rest protocols) or metallb for arbitrary ones.

True, but they also validated it against generic facebook images; and compared the accuracy of humans on the (dating website) images to the established benchmark of human capability (which came out comparable). If there was something telling sexuality-wise from the dating pictures, then you would probably expect humans to be able to pick up on it as well.

(see author notes on this: https://docs.google.com/document/d/11oGZ1Ke3wK9E3BtOFfGfUQuu...)

From the author's notes: "When presented with a pair of participants, one gay and one straight, the algorithm could correctly distinguish between them 91% of the time for men and 83% of the time for women." So yes, 50-50.

There is a slightly disingenuity here. "a large portion of massive security holes in recent history have been due to archaic libraries that have security holes a-plenty".

The fact they are also C libraries is because that was the only real option of the time when they were written; rather like saying most car accidents were caused by black ones when the only option was a model T.

Chocolatey is fairly well established as wrapper around nuget that grabs windows binaries - indeed it's currently the only source type that microsoft's own package manager (oneget) supports (although they intend to provide others see http://blogs.technet.com/b/windowsserver/archive/2014/04/03/...)

Unfortunately, the reason it worked was (as someone who uses both svn and git professionally) it was entirely plausible that the subversion devs would want to use git.

Whether real or not, it does raise a question I've been wondering about for a while now - what about a f2p game that did state upfront that while playing, you are mining; so the more you play, the more it costs you. No IAP, no upfront costs, etc.

Obviously it would not be suitable for some game types (anything 3d heavy, basically), and has obvious battery/temperature implications on mobile, but it does seem to provide a plausible additional option for monetization.

For those of us still wedded to mutt (or other cli clients), there is notmuch - http://notmuchmail.org/ - a clone/reimplementation of the search side of sup as a standalone thing.

Frankly, I think it is more interesting that the various official writer's guilds have a higher bar for entry for self-published "because it is easier to make money by going indie."

Even then, IDE on one monitor; web for reference material on the other.

Okay, what form and key size of encryption is in use? What implementation is it? Does it do PFS? is it salted? Where/for how long/how are messages stored? Who has access to the encrypted form of the messages? What block mode is being used here? How are you handling the iv initialisation? Per message? per person? per conversation? What are you using to determine the IV value?

Given way the password is distributed, I doubt the encryption is salted.

Note that that is for containers (i.e. guests). For the host side, only ubuntu is officially supported; many people are using arch quite well, and a few have got it running under fedora and suse that I know of (I'm going to assume gentoo have it as well, knowing them). both require custom kernels however.

With the correct versioning, you can sort the guarantees out - there is some discussion on the docker forum at the moment on signing / hashing or otherwise verifying the images.

For slotted services, I suggest looking at nix and nixos, a package manager (and a distribution) which pinches some ideas from containers.

As for the main point of your comment:

Yes, native package management is lighter-weight than containers (which is lighter than vms, which is lighter than seperate physical machines). Perhaps unsurprisingly, that weight brings additional features. The main one that containers (upwards) adds is segregation. apt (lovely as it is) can only ensure packages don't conflict on the files that they install - you are on your own for ensuring there are no runtime conflicts. Yes, with proper user creation + management you can restrict their ability to tread on each other's toes (hope there are no setuid programs in there), but that is all more effort than the 'their filesystems are seperate' that the heavier options give you.

There is also the question of tidying up / migrating. Let's say I install number of packages for some thing I'm deploying on a box. After a while I realise the load is too high and decide to migrate one/some of the apps to another machine. apt, etc can tell me what files a package has installed. It can't tell me what files a package has created while running. I'll have to go around and figure out the data (config, user config, log, etc) file locations and probably miss a couple and end up just duplicating the original machine. Or I copy the container file and the half a dozen images that make it up.

It's true that docker (and to a lesser extent vagrant et al) are perhaps suffering from over-use as the are 'the new hotness', but that's because we have a new tool and haven't yet fully figured out how to use it - it's somewhat inevitable behaviour. And yes, for some applications package management is fine and containers is unneeded overhead. But for others it isn't.

Basically, yes. Used in this manner it's a lower friction version of slapping vmdk's on a web server (or 'how we used to do it')

Actually the provisions of the OSA cover you even if you haven't signed it. Signing it is generally just a reminder thing, hence the fact that if you have to sign it once, you will probably end up signing it several times (when you join, when you leave, when you change roles, etc).

The OSA primarily covers how you handle secret information that you legitimately have access to. He was talking about stuff outside the scope of the OSA - i.e. when you acquire material that you shouldn't have to start with.

A nice approach, I will look at implementing it on my setup at home; Probably worth noting that if you are taking these steps then running it all out of an encrypted filesystem is probably a sensible addition. Although if you are looking at doing this you probably have an encrypted filesystem already.

She. I remain surprised by how often this mistake is made, given her name is on every page and the whole thing a few years back where someone accused her of being a fiction made up by IBM.

Also, I wonder what the other contributors she had given post privileges to think of this (I thought she had stepped down/away from some of the cases groklaw was covering).