OSDev in decline

[Korona]

I had an idea while heading home from work today. If you're looking to spark up interest, howabout introducing a weekly/biweekly/monthly thread where people talk about what they've recently accomplished, or their short (current month at most) term and concrete plans? Sort of like a book group except not.

I think this is a very good idea. I would however recommend it isn't bound to some time range (just like you can post in the Screenshots thread any time). I would also suppose something like this would attract plans that include some questions. (Should that be allowed? I'd say yes.)

Now, who is willing to begin this thread? Probably not me, as I don't have an established OS currently, just some plans for its building/hosting prerequisites. Still debating with myself whether I can find some time currently and whether I should use files or a database for the VCS that will be used to host the OS.

I second that this sounds like a nice idea. There is the screenshot thread to "brag" about your UI accomplishments but I feel that the things that interest me the most in OSdev are not graphical at all -- I care much more about technical features and good design. Would moderation support such a thread? Would it also be stickied if it turns out to be successful?

[pat]

Hi,

I had an idea while heading home from work today. If you're looking to spark up interest, howabout introducing a weekly/biweekly/monthly thread where people talk about what they've recently accomplished, or their short (current month at most) term and concrete plans? Sort of like a book group except not.

I think this is a very good idea. I would however recommend it isn't bound to some time range (just like you can post in the Screenshots thread any time). I would also suppose something like this would attract plans that include some questions. (Should that be allowed? I'd say yes.)

Now, who is willing to begin this thread? Probably not me, as I don't have an established OS currently, just some plans for its building/hosting prerequisites. Still debating with myself whether I can find some time currently and whether I should use files or a database for the VCS that will be used to host the OS.


Regards,
glauxosdever

I'd be happy to manage that thread. I had some ideas on how to structure it t. By the time range, what I meant was you could post any time, but your specific OS's focus would be limited to once a $period. So say I posted on any random day about Saturn, I could respond and discuss but not bring up another Saturn finished feature until some time elapsed.

This is so that there would be several days inbetween OSs to focus the topic of conversation on their thing. It wouldnt be rigidly enforced but its just to help the flow of posts in a linear forum like this as opposed to a reddit style. Its also to prevent kind of spam of tiny features that wouldnt foster discussion.

[Korona]

I don't know if we need a strict rule -- some rule of thumb should be sufficient. The screenshot thread is not spammed either.

I'd suggest some recommendation on the length of posts. I think posts should give some context but not be too long. After all, neither "I implemented an IDT." nor full page posts with technical details would be desirable. I think we should encourage posts to state some context like "This weekend, I implemented an IDT. I encountered problems X and Y. It took me a while to figure out that Z in my code was wrong but the qemu debugger helped me to find this issue. Thanks to the IDT support, I also implemented a keyboard driver; I can now use the arrow keys move my ASCII art unicorn around the screen."

[glauxosdever]

Hi,

By the time range, what I meant was you could post any time, but your specific OS's focus would be limited to once a $period. So say I posted on any random day about Saturn, I could respond and discuss but not bring up another Saturn finished feature until some time elapsed.

Ok, I get now what you mean.

Look, while it's probably a good idea to limit the frequency of posts about each project, I don't think there would be a problem if there were 5 posts about the same project in a single week. Sometimes, you have lots of free time (e.g. summer, break from work, etc) and sometimes you are busy (exams, overtime, etc). It's perfectly normal to do and announce more stuff when having free time. Of course, if these "5 posts about the same project in a single week" are a recurring pattern for 3 or more consecutive weeks, maybe some moderation could be enforced then. A good rule of thumb would probably be that you can post per week at most max(5 posts, 20% of all posts during that week).

What do you think?


Regards,
glauxosdever

[pat]

Hi,

By the time range, what I meant was you could post any time, but your specific OS's focus would be limited to once a $period. So say I posted on any random day about Saturn, I could respond and discuss but not bring up another Saturn finished feature until some time elapsed.

Ok, I get now what you mean.

Look, while it's probably a good idea to limit the frequency of posts about each project, I don't think there would be a problem if there were 5 posts about the same project in a single week. Sometimes, you have lots of free time (e.g. summer, break from work, etc) and sometimes you are busy (exams, overtime, etc). It's perfectly normal to do and announce more stuff when having free time. Of course, if these "5 posts about the same project in a single week" are a recurring pattern for 3 or more consecutive weeks, maybe some moderation could be enforced then. A good rule of thumb would probably be that you can post per week at most max(5 posts, 20% of all posts during that week).

What do you think?

Regards,
glauxosdever

Sounds good to me.

[pat]

I don't know if we need a strict rule -- some rule of thumb should be sufficient. The screenshot thread is not spammed either.

I'd suggest some recommendation on the length of posts. I think posts should give some context but not be too long. After all, neither "I implemented an IDT." nor full page posts with technical details would be desirable. I think we should encourage posts to state some context like "This weekend, I implemented an IDT. I encountered problems X and Y. It took me a while to figure out that Z in my code was wrong but the qemu debugger helped me to find this issue. Thanks to the IDT support, I also implemented a keyboard driver; I can now use the arrow keys move my ASCII art unicorn around the screen."

I like the context and problems encountered. I was thinking it should be focused on one meaty feature, examples include (follow up questions in brackets)

- modified scheduler to facilitate priorities (why did you go with X over Y, I had problems while implementing Z how did you overcome that)
- the idt example and really getting into how you debugged it
- got the first piece of SMP support in place (how are you planning on managing Z down the road)

Then go into these were my problems, fun/interesting things I learned in the process, things I'd like to revisit or do differently.

Note that this isnt a hard format, but the examples are just there to show how its one thing that could bring up a few posts. Not so much a blogpost of here's everything I did last week. But that's just my thoughts, I'm open to ideas.

[Thomas]

Sadly, this is quite true. OSDev is in a decline as a research problem these days, but not as a practical problem, there are ton of bugs everywhere which needs to be resolved. See this article as early as 2000.
http://doc.cat-v.org/bell_labs/utah2000/

--Thomas

[~]

Even if everything was fully explained, OS development would never decline, but would become increasingly important like any other tool.

Computers are an extension to any living being, so it will always be very important.

If you mean that practical topics containing full source code are more and more rare, then we will do better to talk on topics that deal with problems we will be implementing on our own right away to then post our answers with full source along with the ones from others.