Another great article along these lines for those interested in assembly and execution environments and so on .. is of course the famous muppetlabs exploration to build the smallest linux executable:
A kind of love what this author has been doing for the past several months: taking personal deep dives into systems technology and then just enthusiastically writing up what they learned. I wish more people would write this way. I know I have a hard time doing it; I want to know that anything I write is novel, which is a crippling and stupid limitation I put on myself.
The reality is that one great way to get to novel value is to apply your own take on something that people have done before; you may find a way to teachably express a concept better than others have before you.
It probably has to do with heritage, but coming from a DOS/Windows background it feels like many things on *nix systems, including executable formats, are rather more complex than they really need to be; ELF is no exception to this, and the linker/compiler defaults tend to create far more sections than necessary.
But interestingly enough, the smallest (known) Win32 executable is actually still more than double the size of that Linux one:
http://www.phreedom.org/research/tinype/
...and both of them don't do much more than exit with a defined value. I think for simplicity, nothing beats the DOS COM format - pure code, up to 64k, loaded in a single segment at offset 100h, entry point is right at the beginning. A "Hello world" is on the order of 20 bytes. (Of which 7 bytes are actual code and the rest is the message.)
Too bad it's AT&T syntax, which is pretty incompatible with the majority of x86 reference material out there (including Intel's own manuals)... something like fasm/nasm would probably be much better in a *nix enviroment. This gives some of the reasons why: http://x86asm.net/articles/what-i-dislike-about-gas/
It's also an odd order for that book to defer binary/hex and data representation until far beyond other more complex/higher-level material. The fact that the code listings have a "compiler-generated" feel to it, complete with redundant instructions, suggests that this isn't a great way to learn Asm; see https://news.ycombinator.com/item?id=8248172 for a more detailed explanation.
The reality is that one great way to get to novel value is to apply your own take on something that people have done before; you may find a way to teachably express a concept better than others have before you.