aras-p

// Just before switching jobs:
// Add one of these.
// Preferably into the same commit where you do a large merge.
//
// This started as a tweet with a joke of "C++ pro-tip: #define private public",
// and then it quickly escalated into more and more evil suggestions.
// I've tried to capture interesting suggestions here.
//
// Contributors: @r2d2rigo, @joeldevahl, @msinilo, @_Humus_,
// @YuriyODonnell, @rygorous, @cmuratori, @mike_acton, @grumpygiant,

plentz

# to generate your dhparam.pem file, run in the terminal
openssl dhparam -out /etc/nginx/ssl/dhparam.pem 2048

amitsaha

How does ls work?

I wanted to be really able to explain to a fair amount of detail how does the program ls actually work right from the moment you type the command name and hit ENTER. What goes on in user space and and in kernel space? This is my attempt and what I have learned so far on Linux (Fedora 19, 3.x kernel).

How does the shell find the location of 'ls' ?

pascalpoitras

Mouse

---

enable

---

mattiaslundberg

# 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

zsup

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.

xem

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)

jashkenas

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

ABOUT

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.

yunga

_________ _____ _______________       _____
\_   ___ \\    \\___________   \____ / ____\     ~/.bash/cliref.md
/    \  \/|    | |   ||       _/ __ \  __\    copy/paste from whatisdb
\     \___|__  |_|_  ||    |   \  __/|_ |   http://pastebin.com/yGmGiDQX
 \________  /_____ \_||____|_  /____  /_|     yunga.palatino@gmail.com
 20160515 \/ 1527 \/         \/     \/

---

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