Ben Mezger benmezger

State of emergency in France

Sources

Loi n°55-385 from 1955
Wikipedia / Etat d'urgence en France (general structure)

Process

Linux Backup Solutions

I've been looking for the best Linux backup system, and also reading lots of HN comments.

Instead of putting pros and cons of every backup system I'll just list some deal-breakers which would disqualify them.

Also I would like that you, the HN community, would add more deal breakers for these or other backup systems if you know some more and at the same time, if you have data to disprove some of the deal-breakers listed here (benchmarks, info about something being true for older releases but is fixed on newer releases), please share it so that I can edit this list accordingly.

Bacula (from the Why section on Burp)

Too complex to configure
Stores catalog separate from backups, need to backup catalog

_________ _____ _______________       _____
\_   ___ \\    \\___________   \____ / ____\     ~/.bash/cliref.md
/    \  \/|    | |   ||       _/ __ \  __\    copy/paste from whatisdb
\     \___|__  |_|_  ||    |   \  __/|_ |   http://pastebin.com/yGmGiDQX
 \________  /_____ \_||____|_  /____  /_|     [email protected]
 20160515 \/ 1527 \/         \/     \/

alias CLIRef.txt='curl -s "http://pastebin.com/raw/yGmGiDQX" | less -i'

Spurred by recent events (https://news.ycombinator.com/item?id=8244700), this is a quick set of jotted-down thoughts about the state of "Semantic" Versioning, and why we should be fighting the good fight against it.

For a long time in the history of software, version numbers indicated the relative progress and change in a given piece of software. A major release (1.x.x) was major, a minor release (x.1.x) was minor, and a patch release was just a small patch. You could evaluate a given piece of software by name + version, and get a feeling for how far away version 2.0.1 was from version 2.8.0.

But Semantic Versioning (henceforth, SemVer), as specified at http://semver.org/, changes this to prioritize a mechanistic understanding of a codebase over a human one. Any "breaking" change to the software must be accompanied with a new major version number. It's alright for robots, but bad for us.

SemVer tries to compress a huge amount of information — the nature of the change, the percentage of users that wil

codegolf JS

Mini projects by Maxime Euzière (xem), subzey, Martin Kleppe (aemkei), Mathieu Henri (p01), Litterallylara, Tommy Hodgins (innovati), Veu(beke), Anders Kaare, Keith Clark, Addy Osmani, bburky, rlauck, cmoreau, maettig, thiemowmde, ilesinge, adlq, solinca, xen_the,...

(For more info and other projects, visit http://xem.github.io)

(Official Slack room: http://jsgolf.club / join us on http://register.jsgolf.club)

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
Once documentation has been written, development should commence, and test-driven development is preferred.
Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
When a feature is being modified, it should be modified documentation-first.
When documentation is modified, so should be the tests.

This configuration is not maintained anymore. You should think twice before using it, Breaking change and security issue will likely eventually happens as any abandonned project.

	/*
	* Demonstrates that an RSA signature does not uniquely identify a public key.
	* Given a signature, s, and a message m, it's possible to construct a new RSA key
	* pair such that s is a valid signature for m under the new key pair.
	*
	* Requires Go version >= 1.5. Go <= 1.4 doesn't work due to a bug in the bignum
	* package: https://github.com/golang/go/issues/9826
	*
	* Written in 2015 by Andrew Ayer <agwa@andrewayer.name>
	*

	The Goals of this Gist are to:
	[1] Increase the GnuPG key size limit beyond 4096 bits.
	[2] Provide configuration files that maximize security and anonymity.

	For now, the ideal configuration files have been provided.
	The Debian_Linux_GnuPG_Compiler.bash script works to build GnuPG with the 4096 bit key size limit raised.

	Please provide input. Feedback and changes welcome.

	# Install ARCH Linux with encrypted file-system and UEFI
	# The official installation guide (https://wiki.archlinux.org/index.php/Installation_Guide) contains a more verbose description.

	# Download the archiso image from https://www.archlinux.org/
	# Copy to a usb-drive
	dd if=archlinux.img of=/dev/sdX bs=16M && sync # on linux

	# Boot from the usb. If the usb fails to boot, make sure that secure boot is disabled in the BIOS configuration.

	# Set swedish keymap