kgriffs

# Configuration file for runtime kernel parameters.
# See sysctl.conf(5) for more information.

# See also http://www.nateware.com/linux-network-tuning-for-2013.html for
# an explanation about some of these parameters, and instructions for
# a few other tweaks outside this file.
#
# See also: https://gist.github.com/kgriffs/4027835
#
# Assumes a beefy machine with lots of network bandwidth

Chaser324

Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, it's quite easy to make mistakes or not know what you should do when you're initially learning the process. I know that I certainly had considerable initial trouble with it, and I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.

In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.

Creating a Fork

Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite git client to clone your repo or j

brendangregg

struct task_struct {
	volatile long int          state;                /*     0     8 */
	void *                     stack;                /*     8     8 */
	atomic_t                   usage;                /*    16     4 */
	unsigned int               flags;                /*    20     4 */
	unsigned int               ptrace;               /*    24     4 */

	/* XXX 4 bytes hole, try to pack */

	struct llist_node          wake_entry;           /*    32     8 */

reborg

Rich Already Answered That!

A list of commonly asked questions, design decisions, reasons why Clojure is the way it is as they were answered directly by Rich (even when from many years ago, those answers are pretty much valid today!). Feel free to point friends and colleagues here next time they ask (again). Answers are pasted verbatim (I've made small adjustments for readibility, but never changed a sentence) from mailing lists, articles, chats.

How to use:

• The link in the table of content jumps at the copy of the answer on this page.
• The link on the answer itself points back at the original post.

Table of Content

htfy96

In this article we compared different behavior of static, inline and static inline free functions in compiled binary. All the following test was done under g++ 7.1.1 on Linux amd64, ELF64.

Test sources

header.hpp

#pragma once

inline int only_inline() { return 42; }
static int only_static() { return 42; }

timvisee

Falsehoods programmers believe about time

This is a compiled list of falsehoods programmers tend to believe about working with time.

Don't re-invent a date time library yourself. If you think you understand everything about time, you're probably doing it wrong.

Falsehoods

• There are always 24 hours in a day.
• February is always 28 days long.
• Any 24-hour period will always begin and end in the same day (or week, or month).

shafik

What is the Strict Aliasing Rule and Why do we care?

(OR Type Punning, Undefined Behavior and Alignment, Oh My!)

What is strict aliasing? First we will describe what is aliasing and then we can learn what being strict about it means.

In C and C++ aliasing has to do with what expression types we are allowed to access stored values through. In both C and C++ the standard specifies which expression types are allowed to alias which types. The compiler and optimizer are allowed to assume we follow the aliasing rules strictly, hence the term strict aliasing rule. If we attempt to access a value using a type not allowed it is classified as undefined behavior(UB). Once we have undefined behavior all bets are off, the results of our program are no longer reliable.

Unfortunately with strict aliasing violations, we will often obtain the results we expect, leaving the possibility the a future version of a compiler with a new optimization will break code we th

melvic-ybanez

What I Didn't Know about Functional Programming until 2020

1. Programming using a series of transformations and aggregations, something I've been doing for years, is known as programming in the map/reduce style.
2. The more abstract the type is, the greater its cardinality, and the smaller the set of operations it supports. So make use of universal quantifiers, particularly by implementing fully parametric functions. They guide you on how to implement their term-level definitions by narrowing down the number of possible implementations. In other words, the type system of Scala (or Haskell, for that matter) is not only great for capturing compile-time errors, but is also capable of leading you to the correct solution.
3. You can encode union types by combining different Scala features such as type constructors, subtyping and implicits, and by taking advantage of the Curry-Howard Isomorphism and De Morgan's Laws for neg