Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kinds of Content #2

Open
Evrey opened this issue Mar 3, 2021 · 15 comments
Open

Kinds of Content #2

Evrey opened this issue Mar 3, 2021 · 15 comments

Comments

@Evrey
Copy link

Evrey commented Mar 3, 2021

So, in the spirit of figuring out what this Wiki will be about and what'll set it apart, these are some categories i can think of that articles may be written for:

  • Hardware Techniques — Like the OSDev Wiki, bits and pieces on how some hardware works, how to poke it with code, links to ref docs, common pitfalls, etc.
  • Software Techniques — Algorithms and other how to shit in OS dev, like »how to scheduler«, »how to vmem alloc«, or even »how to flexbox layout my desktop UI«.
  • Research OSs — Which ones exist, what do they do, what did the researchers find out, which lessons to learn. Links to papers, summaries, key takeaways, etc.
  • Novel Ideas Without Research — Things we or others came up with that sound really interesting and beneficial, but are not backed by science yet.
  • The Status Quo — Out of the traditional OSs that exist, what works, what doesn't, what's their design like.
  • Cook Books — Analogous to https://os.phil-opp.com/, a more general guide on how to get started and grow things from there. Probably with lots of links to the more detailed articles for the deep dives.
  • OSdev Roadmap — Timeline of usual big OSdev milestones with relevant articles or cook books per milestone linked.
@Stupremee
Copy link

We can probably add a short, but helpful and good tutorial section.

This shouldn't be a tutorial where the user basically copies the code.
Instead, we provide some sort of roadmap, where each section contains a small introduction, or some longer explanation if needed, then link some resources that may help to implement/understand this section, and then tells the user what he needs to do, in order to "complete" this stage.

@MaxBondABE
Copy link
Member

@Stupremee Like this?
https://os.phil-opp.com/

@Evrey
Copy link
Author

Evrey commented Mar 3, 2021

@MaxBondABE That's what i envision while reading @Stupremee 's comment. Would be useful indeed. Kinda an OSdev cookbook.

@Stupremee
Copy link

Stupremee commented Mar 3, 2021

Something similar. My initial idea was more of a roadmap that doesn't really explain every part in detail, since most parts are often explained very well somewhere else (e.g. in Phil's blog post, or in this wiki itself), and instead leads the user into a direction on "What should I do next", and where can I find stuff about this part. Then the user has to think by himself and implement it using his own design.

The idea also makes it much easier to write this tutorial, since you don't need to explain everything in detail, and thus we can probably even provide multiple tutorials each with different Architectures, Kernel Designs, etc.

But I'm also open for other suggestions

@Evrey
Copy link
Author

Evrey commented Mar 3, 2021

Oh yeah, a roadmap like that would be quite useful. Also as a meta article, like:

  1. How to boot into your OS loader.
    • Boot process by board:
      • Link to RasPi boot process article.
    • General boot loaders and firmware:
      • UEFI article
      • GRUB2 article
      • QEMU stuff
  2. Loading the OS
    • Executable formats.

So like bookmarks to go through in development order? @Stupremee

@Stupremee
Copy link

Yeah that is exactly what I imagined.

@AbleTheAbove
Copy link
Member

Another content type might be design review
I, E evaluating unix design
We could start with the main 3 and then spiral down into hobby os's

@AltriusRS
Copy link

Another content type might be design review
I, E evaluating unix design
We could start with the main 3 and then spiral down into hobby os's

I really like this idea, it is very similar to how I was first imagining the content we produce, where we start off with a "what we like and dislike about " and then as things get further onwards, we move towards looking into hobby OSs.

Maybe if we could come up with some way of splitting the project into to components:
1 - Design Review
2 - How to X

we could get the best things out of both worlds, whilst still providing content which meets up with what we all want to do the most?

@Evrey
Copy link
Author

Evrey commented Mar 4, 2021

Very neat idea. We may even have multiple reviews for the same OS, and then a meta review article that tl;drs all our opinions in a neat pros/cons/interestings table.

@AbleTheAbove
Copy link
Member

AbleTheAbove commented Mar 4, 2021

# Windows Review / Able edition 
It’s bad

@AltriusRS
Copy link

Very neat idea. We may even have multiple reviews for the same OS, and then a meta review article that tl;drs all our opinions in a neat pros/cons/interestings table.

This does make a lot of sense, or we produce two articles on each OS, one which is worked on as a group, where we provide our longer-form opinions and feedback, and the one which tl;drs all of our opinions?

I am open to anything at this time though

@Evrey
Copy link
Author

Evrey commented Mar 5, 2021

I think multiple individual articles get shit done quicker. =) Less coördination required except for the tl;dr tables.

@AltriusRS
Copy link

True, that would make more sense. Ignore my prior suggestion haha.

@AbleTheAbove
Copy link
Member

That being said, the tl;dr table should include a bias section(I.E. Used windows for 7 years || worked on the Linux kernel || etc etc)

@Evrey
Copy link
Author

Evrey commented Mar 5, 2021

@AbleTheAbove Absolutely definitely true.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants