Added new category - chrestomathies

[Schol-R-LEA]

One of the problems we keep running into is that there are a lot of things we really can't give a general example for in the wiki. A lot of the things we keep getting questions about over and over again are ones where an answer really depends on a lot of other details of the OS being developed.

As a result, most of the things in the wiki either don't have any example code, or have a skeletal example which couldn't really be used as they are, but which we've repeatedly seen newcomers trying to use unchanged despite warnings to the contrary.

I think we need to address this from more than one angle, but one which has occurred to me is to provide, not one skeleton example, but several working examples from other OSes, in a way that makes it clear that the readers are meant to compare the different approaches rather than just copy them.

This specifically came up while I was trying to figure out how to write different examples of how to use heap allocation for assembly-language data structures (especially things like linked lists and trees). Whereas I could have parallel examples for different architectures and assemblers without too much trouble, trying to have comparisons in three dimensions - CPU, assembler, and operating system - when the examples wouldn't even apply to the OSDevver's own systems, seemed to present a serious problem which called for a solution beyond just that one page.

To this end, I have created a new wiki category, Chrestomathy, where we could add actual code examples, as well as post links to others. In my idea, the chrestomathy pages would give a few different examples of the particular technique, especially ones from established systems (presumably open-source ones in the case system internals, though other examples would be of userland APIs and that different proprietary OSes expose - the one page I've already added, Application-level Memory Management Examples is an example of this), while others can add either more examples from their own OSes (or ones they know of which aren't already there) if they think that it is uniquely of interest to those designing new systems (e.g., it uses a method that is distinctly different from any of the examples already there), or links to same (if they want to show them but don't think they a significantly different from all the ones already there).

Does anyone have any opinions on this? My main concerns in this are that a) in-page examples might not be complete enough to illustrate the techniques; b) different topics will have uneven examples, with some have few if any and others having page after page of trivial ones; c) it might be too tempting of people to use it to promote interest in their OSes rather than focusing on useful examples; and d) the pages are likely to suffer from a lack of updates, which has been a problem for the wiki in general.

[alexfru]

One of the problems we keep running into is that there are a lot of things we really can't give a general example for in the wiki. A lot of the things we keep getting questions about over and over again are ones where an answer really depends on a lot of other details of the OS being developed.

;// It's probably also related to your wiki post.

We also keep getting asked the same questions over and over again because those asking have no systematic knowledge (and at times approach to building it) of the so many things involved in basic (and not so basic) things OS dev (tools, languages, HW/SW/algorithm concepts). Everyone has sets of what they know, what they don't know, what they think they know but don't, what they may have some ideas and doubts about. For everyone it's different sets with different knowledge gaps.

They often can't reuse prior questions and answers not only because they don't care to, but also because the circumstances are or perceived different and they either can't figure out important differences from unimportant ones or it's just an overkill for them to study and understand someone else's stuff (after all, they often can't understand or reason about their own, they wouldn't have asked if they could).

A complete, maintained, go-to reference system would be nice. But isn't MINIX just that? And there's even a good book about it. Anything wrong with it? Too big? Gotta buy or borrow the book?

What about one of those famous tutorials which has a bunch of known bugs that people keep stumbling over year after year? It's probably simpler. But is there a maintained version with those known bugs fixed?

Do we have a collection of good tutorials and online classes to cover the basics?

At any rate, I don't think you can possibly eliminate all confusion and questions in such complex matters as OS dev.

[Schol-R-LEA]

Was this meant to be in other thread I created? I know you are quoting this one, but it seems to be more about the other thread's topic, even if it is responding to what I said here.

No matter, it's a good point. I do think we need to do more to foster people to go out and develop more of that systematic knowledge elsewhere, and even help provide some framework for a few possible learning paths. We can't do a lot in that regard - it really isn't on topic, even if it is prerequisite to understanding OS dev, and frankly the people here simply don't have the time to do much about that even if it were simply because of time and focus constraints which already impinge on what we can do on the wiki - but I do think we should consider maybe giving more guidance on this, perhaps a page or two outlining the kinds of things people need to understand first in more detail.

We might want to go further on the topic pages in explaining the knowledge needed to tackle a given part of an OS or some specific topic, but again, time and space are factors.

Mind you, part of my idea for the category is to help drive the point home that there are no one-size-fit-all silver bullet solutions to a lot of these problems. In the back of my mind, part of the goal was to demonstrate that no, these really are different, and need to be different in order to mesh with the systems the belong to, as well as show that there are different approaches to the same problem and that the OS dev needs review more than one in order to understand how they might fit into their system and consider which one works best with their design and ideas - or even decide that they need a completely novel approach instead.