The objective of this proposal is to standardize the usage of common data structures within the context of the C language. The existence of a common standard interface for lists, hash tables, flexible arrays, and other containers has several advantages:

User code remains portable across different projects. In C, we all use the FILE abstraction, for instance. This abstraction allows software to be compatible across a large spectrum of machines and operating systems. Imagine what would happen if each project had to develop a file stream abstraction again and again. This is the case when using lists, for instance. Today, we have in all significant projects written in C a list module, and probably other ones like hash tables, etc.
Avoid duplication of effort. Most of the list or hash tables modules can't be debugged completely and are the source of never ending problems.
Lack of standards makes the merging of two projects very difficult since in most cases the interfaces and data structures are slightly different. This leads to a complete rewrite of one of the modules, or to ädapter" software that will translate from one list implementation to the other, adding yet another layer of complexity to the merged project.
The language becomes more expressive since it becomes possible to reason within a high level environment. The lack of operations for handling advanced data structures conditions programmers to use low level solutions like making an array with a fixed maximum size instead of a list even if the programmer would agree that a list would be a more adequate solution to the problem. Confronted to the alternative of developing yet another list module or opting for a low level solution many time constrained programmers will opt for the second solution.
The portable specifications provide a common framework for library writers and compiler/system designers to build compatible yet strongly specialized implementations.
The language becomes easier to analyze mathematically. In their very interesting paper "Precise reasoning for programs using containers", Dillig, Dillig and Aiken 1 enumerate three main points that make program analysis easier using containers:
    Understanding the contents of a container doesn't require understanding the container's implementation
    Verifying container implementations requires different techniques and degrees of automation than verifying their clients. Hence, separating these two tasks allows us to choose the verification techniques best suited for each purpose.
    There are orders of magnitude more clients of a container than there are container implementations. This fact makes it possible to annotate a handful of library interfaces in order to analyze many programs using these containers.
It is possible to abstract from the nature of any container (using the iterator construct) what allows a series of algorithms to be written without having to bind them to a precise data structure. Containers present a uniform interface to the rest of the program.

echo $(printf %08X 256 | grep -o .. | tac | tr -d '\n')

This tool can be described as a Tiny Dirty Linux Only C command that looks for coreutils basic commands (cp, mv, dd, tar, gzip/gunzip, cat, ...) currently running on your system and displays the percentage of copied data.

The X Window System is a networked display system. A server component, the X server, is responsible for coordinating between all of the clients connected, taking input from the mouse and keyboard, and pushing pixels on the output. The most popular X server implementation is the Xorg X server, developed by the X.Org Foundation and community. There are other X server implementations: you might remember that Xorg was forked from XFree86 a decade ago, that Sun Microsystems has had several X server implementations, in both Xsun and XNeWS. Today, Xorg is the dominant X server implementation, getting most of the development. But back in the day, multiple competing implementations existed.

Short linux sysadmin screencasts containing tutorials, tips and tricks. Great for both novice and experienced Sysdmins.

The runtime symbol bindings can be displayed by setting LD_DEBUG=bindings:

the search paths of each symbol lookup can be displayed by setting LD_DEBUG=symbols. If this is combined with a bindings request, you can obtain a complete picture of the symbol relocation process.

Dynamically linked shared libraries are an important aspect of GNU/Linux®. They allow executables to dynamically access external functionality at run time and thereby reduce their overall memory footprint (by bringing functionality in when it's needed). This article investigates the process of creating and using dynamic libraries, provides details on the various tools for exploring them, and explores how these libraries work under the hood.

This article explores some of the Linux architectures that support real-time characteristics and discusses what it really means to be a real-time architecture. Several solutions endow Linux with real-time capabilities, and in this article I examine the thin-kernel (or micro-kernel) approach, the nano-kernel approach, and the resource-kernel approach. Finally, I describe the real-time capabilities in the standard 2.6 kernel and show you how to enable and use them.

A big doc about how asm instruction are decode

7 bytes

0000000: 6641 2521 2173 21 fA%!!s!

As 32 bit

00000000 6641 inc cx
00000002 2521217321 and eax,0x21732121

As 64 bit

00000000 6641252121 and ax,0x2121
00000005 7321 jnc 0x28

and clears the carry flag so the 64 bit version always jumps. For 64-bit the 6641 is the operand size override followed by rex.b so the operand size for the and comes out as 16 bit. On 32-bit the 6641 is a complete instruction so the and has no prefix and has a 32-bit operand size. This changes the number of immediate bytes consumed by the and giving two bytes of instructions that are only executed in 64-bit mode.

Colony graphs are a simple visualization of computer life forms. A process colony graph, or "ptree graph" for short, shows live processes and their parent and child relationships.

Interesting infographie of great mechanical mechanism