Stan Dard: Difference between revisions
Jump to navigation
Jump to search
| [unchecked revision] | [unchecked revision] |
Content deleted Content added
No edit summary |
|||
| Line 3: | Line 3: | ||
== Description == |
== Description == |
||
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 of |
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. |
||
there is always a price of compatibility that must be paid. |
|||
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. |
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. |
||
| Line 11: | Line 13: | ||
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. |
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 |
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. |
||
Stan also understands why a standard is like it is. |
|||
== Pro's & Con's == |
== Pro's & Con's == |
||