Stan knows how things should be. It's all nicely written down in standards. He sees how they fit together to form a beautiful system, well, if you disregard all the parts where the standard is stupid. He has a reasonably complete implementation of the areas he knows about and not-terribly-impressive code for the areas he is unskilled in. He spends much time rewriting code written by younger-and-unskilled instances of himself to satisfy his insatiable and ever-changing perfectionism. He is always ready to be helpfully unhelpful to newcomers by pointing out they should stop doing things their way and do it his way instead.
Stan suffers from an acute case of Not-Invented-Here. When he looks at the computing world today with all its horribleness and complexity, he wants to do better. Of course, he doesn't have the effort to rewrite everything (but perhaps he wants to, perhaps he ought to). He compromises by honoring standards as long as they are reasonable and goes with his gut otherwise. He understands how sometimes diverging from standards is the best thing to do, but there is always a price to pay for every divergence. He knows about the history of standards and why the standards are like they are.
If you give Stan sufficient time, he probably ends up with a mostly-complete implementation of POSIX (IEEE Std 1003.1, 2013 Edition). Of course, he started out inexperienced and naively made a bunch of bad design decisions that he now regrets. Much time is spent fixing the code made by younger instances of himself - he really should have been more ambitious than "I'm just having fun" and done things properly. As he gradually cleans up his act and learns the standards, his code gets cleaner and simpler, but he still isn't satisfied. On the other hand, he feels proud when he looks at the complexity of contemporary systems and likes how his solution is simpler even if currently suboptimal. He can usually split his code into two categories, the code that he is reasonably proud of, and the code that is scheduled for a rewrite. As such, more time is spent improving the operating system base than actually getting new features done.
That's certainly not all bad. His standard library is powerful, robustly made, and compatible with much third party software. His operating system has dozens of ports. Often his work is more like a Linux distribution preparing packages than a low-level hacker writing drivers. He ported a graphical user-interface toolkit, but has no functional display server (and no mouse driver). He has a port of git, but no networking. Somehow he even managed to port Python and Mono, though like most ports they're not really useful as he isn't actually using his operating system. He ported enough programs that his operating system is self-building, but not actually self-hosting as he still hasn't written that crucial harddisk driver.
Stan generally manages to do well in areas that he knows about and manages to neglect good work in areas outside his expertise. He strives to improve the way he does things, and stuck with a legacy codebase written by incompetent versions of himself, he often makes new recommendations that his code certainly doesn't follow.
Building his operating system is a fun experience involving getting yourself a modern Linux that implements the modern features his custom cross-tools expect, a version of the core shell utilities that supports the obscure long options he needs, building the highly customized binutils and gcc he maintains, bootstrapping his custom Make (as GNU Make is obviously not good enough), setting up his ports collection (highly patched to cross-compile properly), and so on. He deeply understands why this is the One True Way to cross-compile and his friendly documentation of the process scares established osdev community members.
Pros & Cons
For Stan it's easy to port third party software, but it is sometimes hard, to be conformant to all the standards.
Stan generally has no bookshelf as the relevant standards can be accesses electronically, or can be accessed through his university library:
- The Intel and AMD CPU manuals
- The System V ABI
- The C standard (2011 revision)
- Advanced Programming in the UNIX Environment
- Modern Operating Systems
- Practical Filesystem Design (with the Be File System)
- The usual RFC documents
- The Man Pages for his favorite Unix