Wicked visualdensity

[Project Name]

Every time you choose to apply a rule(s), explicitly state the rule(s) in the output. You can abbreviate the rule description to a single word or phrase.

Project Context

[Brief description ]

[more description]
[more description]
[more description]

Meltdown fix impact on Redis performances in virtualized environments

UPDATE: apparently kernel difference may have a serious impact, so I'll redo the test from scratch.

Test performed with AOF enabled, fsync policy 1 second, allowing the rewrites to be triggered.

Command lines used:

Prologue

I wrote this answer on stackexchange, here: https://stackoverflow.com/posts/12597919/

It was wrongly deleted for containing "proprietary information" years later. I think that's bullshit so I am posting it here. Come at me.

The Question

Amazon is a SOA system with 100s of services (or so says Amazon Chief Technology Officer Werner Vogels). How do they handle build and release?

Commit Message Format

This specification is inspired by and supersedes the [AngularJS commit message format][commit-message-format].

We have very precise rules over how our Git commit messages must be formatted. This format leads to easier to read commit history.

Each commit message consists of a header, a body, and a footer.

	CMDB:
	I do not have names on specific commentors. These notes have been re-ordered to make a bit more sense.

	We have dynamic environments, with information coming from systems and builds.
	Systems need configuration from runtime data based on service discovery and build configuration (IP addresses, versions, etc).

	CMDB use contexts:
	On call users - The sysadmin who has been paged at 4 am needs to determine context for the page.
	Deployment systems - To know where to deploy software, what version(s) to deploy, etc.
	Maintenance - Downtimes, escalate, software versions, hardware info...

	package main

	import (
	"fmt"
	"reflect"
	)

	type Aaa struct {
	a string
	}

	MIT License

	Copyright (c) <year> <copyright holders>

	Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

	The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

	THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE S

	# Idempotent way to build a /etc/hosts file with Ansible using your Ansible hosts inventory for a source.
	# Will include all hosts the playbook is run on.
	# Inspired from http://xmeblog.blogspot.com/2013/06/ansible-dynamicaly-update-etchosts.html

	- name: "Build hosts file"
	lineinfile: dest=/etc/hosts regexp='.*{{ item }}$' line="{{ hostvars[item].ansible_default_ipv4.address }} {{item}}" state=present
	when: hostvars[item].ansible_default_ipv4.address is defined
	with_items: groups['all']

	Moved to a proprer repositoy, TSWS is a real boy now!

	https://github.com/dfletcher/tsws

	PRs welcomed.