Elect the designing team!

[M52]

I think we can all agree that progress is crawling to a hold. The best way to save the project is to really start organizing it.

Scrap everything we have and know and thought of, just, scrap it and push it out of your mind..

Ready? Good.

I would like to propose that we "elect" 2 or 3 people who will design the Kernel from the ground up. They will need to cover everything and document it very thoroughly and clearly.

For example, they could begin developing how the filesystem works, once they have an idea they propose it here in an issue.

In that issue the rest of us. with the design team, discuss the design and make modifications if needed.

Once we have reached agreement the document is practically set in stone (unless something else down the road requires a few changes). We do not begin to code, yet...

We wait until we have all parts documented (The first document we'd need would actually be one that describes WHAT parts we need). If we have we can then assign people to different tasks and work from there.

Sounds like a plan?

[dilbertfan]

Guys, trying to dcoumnet everything with 2 or 3 people will NOT work, and what I want is a finished kernel as soon as possible, so re-doing everything is not an option. Haven't we made progress on the multitasker? is that not fast enough?

On Sat, Oct 27, 2012 at 7:48 AM, M52 notifications@github.com wrote:

I think we can all agree that progress is crawling to a hold. The best way to save the project is to really start organizing it.

Scrap everything we have and know and thought of, just, scrap it and push it out of your mind..

Ready? Good.

I would like to propose that we "elect" 2 or 3 people who will design the Kernel from the ground up. They will need to cover everything and document it very thoroughly and clearly.

For example, they could begin developing how the filesystem works, once they have an idea they propose it here in an issue.

In that issue the rest of us. with the design team, discuss the design and make modifications if needed.

Once we have reached agreement the document is practically set in stone (unless something else down the road requires a few changes). We do not begin to code, yet...

We wait until we have all parts documented (The first document we'd need would actually be one that describes WHAT parts we need). If we have we can then assign people to different tasks and work from there.

Sounds like a plan?

— Reply to this email directly or view it on GitHubhttps://github.com/trillek/entropy/issues/20.

[dilbertfan]

I'm ok with docs, but I say we have a 1 month period MAX for documenting- there are plenty of ChaOS coders whop are pissed at the slow, constant redoing of the kernel.

[M52]

I can agree with the timeframe and I could also agree on designing the documents in larger or smaller teams. The key is, we need a direction. Currently everything is just sort of fiddled together with bits and piece of ducttape sticking out...well sort of...

The whole thing is: documents first, then code.

Now we could design the documents all together by using issues as proposals for certain parts.

First document: What parts does the kernel consist of?

[dilbertfan]

Task switcher, VERY BASIC libs, hardware drivers, some sort of process communication, MAYBE networking- also, come to the science meeting in 4 hrs at HA- this will be talked abbout

On Sat, Oct 27, 2012 at 8:09 AM, M52 notifications@github.com wrote:

I can agree with the timeframe and I could also agree on designing the documents in larger or smaller teams. The key is, we need a direction. Currently everything is just sort of fiddled together with bits and piece of ducttape sticking out...well sort of...

The whole thing is: documents first, then code.

Now we could design the documents all together by using issues as proposals for certain parts.

First document: What parts does the kernel consist of?

— Reply to this email directly or view it on GitHubhttps://github.com/trillek/entropy/issues/20#issuecomment-9834929.

[Lucus16]

If we decide to execute M52s plan, we could still reuse all the code we have easily, most of the time it will need only a few modifications to work as intended. As for making the documentation, I'd say we shouldn't wait with coding until the documentation is done because you run into problems pretty often while implementing the functions. At that point, the documentation would have to be changed, so it's better to try making the code immediately and see if it could work.

I also think that if we decide to do this, we should make a google document to make the documentation. Google documents also log all changes, so we can always revert something, but it is a lot easier to use and express ideas in than github issues. It also allows us to put everything in one document without it becoming messy.

EDIT: I must admit that I have a lot of ideas about how the kernel should work that I'm finding hard to find a place to express them right now.

[dilbertfan]

Use issues D:

[viccuad]

I do think that everyone should be involved in the design. people don't like to develop things that they have not thought about, or understand why is it done that way. in fact, is counterproductive: they even would fail doing it so, because they don't understand why should be done that way.

I have to say that looking to the people here, noone seems to have proper background in computer science. building a kernel is not an easy task. is one of the hardest of computer science, maybe with the task of building a compiler. there is a lot of science and prior understanding of LOT of things.

because of that, I do think that we should design the lesser we can. there is a lot of already done books, and someone has already really thought about problems that maybe a lot of people here don't even know that exist.

Once I said to make an Unix like system, back in the 0x10c forums. and Herobrine said that there wasn't any neccessity for "hipter whatevers", and posted a photo of something funny. unix is not hipster. it's proven, it's working.

I would really vote for implementing a simplified linux kernel. if you read this and you can't picture how an linux-like kernel works, then, maybe you shouldn't think about coding a kernel. or at least you should be inclined to just go to your uni's library(or your nearest computer science faculty) and grab some literature. making this project is just a wonderful way to learn everything you should know about OS! but trying to make one without not knowin even from where to start is going to be impossible.

making a linux-like kernel is easy, you take a book about linux kernels (i.e. A.Tanebaum's Operating Systems: design and implementation), and start to read it and simplify it to the level of the dcpu16. its even simpler than coding a kernel on your own.

have you ever wondered why they aren't any preemtive kernels for dcpu16 on github? it's not an easy task.

[M52]

^ I am heading towards the library!

No but seriously, I think you are absolutely right. Books, here I come!

[Lucus16]

That is exactly the book I have used so far for reference: http://www.minix3.org/documentation/index.html Minix 3 is a very simple linux kernel built specifically for helping people understand kernels. Even so it's still far more advanced than what we will be making. I believe I understand how our kernel should end up working pretty well though.

While we could just make a lot of issues to discuss the different aspects of the kernel, I feel it is useful to centralize all those discussions and specifications in one place, which is why I believe a Google Document would be helpful. This is also because it makes editing much easier, while in issues, we can pretty much only follow a linear discussion.

[dilbertfan]

"Once I said to make an Unix like system, back in the 0x10c forums. and Herobrine said that there wasn't any neccessity for "hipter whatevers", and posted a photo of something funny. unix is not hipster. it's proven, it's working."... on computers with VASTLY more memory, speed and opcodes

[Liraal]

I am against either Linux or Unix kernels. They have no place on the DCPU and should never be considered. Every good kernel and subsequently OS written in DASM-16 has to be purpose-built and designed specifically for the DCPU. Mind that I'm not banning you from doing it your way, I just won't support it. No. Just no.

[viccuad]

I really think that you just don't see the difference between what a unix-like kernel is, or a microkernel or a monolithic kernel is.

a kernel can be UNIX or POSIX compliant without being bloated.

for example:

• Minix. micro-kernel. unix-like. minix 1.0 is from 1987. created to work on IBM PC AT (model 5170): CPU Intel 80286, Memory 256 KB ~ 16 MB. not bloated.
• LynxOS. used in motorola 68010, or 80386. real time OS. used for avionics and etc. unix-like. not bloated. written in 1986.
• Apolo os. APOLO OS: Domain/OS (https://en.wikipedia.org/wiki/Domain/OS). done in 1981. running in the apolo computer: CPU 2 x 68000, 8Mghz, 1k memory page size. (https://en.wikipedia.org/wiki/Apollo_Computer). UNIX COMPLIANT.
• the first initial UNIX system by Bell labs: unics, in 1969 (later renamed unixTTS in 1971). Good computers in that years, uh? plenty of RAM, and so on, uh?. oh wait. wasn't ram invented on 1970?

The above OSes (and their kernels, therefore) were created for embedded systems, on purpose. just like this kernel and the DCPU-16. (well, maybe not the unics one).

I do really think that you even don't know what are you talking about. And I think pretending to build a complete kernel without never ever have studied how OSes work and how OSes are is quite naive: specially when you are not eager to inform yourself.

but ok, whatever. I have tried :)

the trick about building an Unix-like system is that a lot of old and wisdom people have already thought about the bad things we would need to think about, in this 50 years of computer history.

In fact, even without you noticing it, you're trying to build a unix-like system: unix introduced many concepts (https://en.wikipedia.org/wiki/Multics#Novel_ideas)

[Callum6677]

we don't have 256kb or 16mb. We have 64kw (note the w) and 1.4mb.

If anything I think your the one that has no idea what he/she is talking about.

[viccuad]

the PDP-7, which was the computer for which unics was made, had 4kw (note the w), upgradeable to 64k words (144 KB, not 1.4mbs). (http://www.linfo.org/pdp-7.html) And hey, the PDP-7 didn't have the awesome instructions we have with the DCPU. And it's ram was made by magnetic tape in those years. and our ram is just instantaneus.

I'm not talking about porting anything to the DCPU(like the lastest unix). just take unix ideas.

but, whatever :)

[jrcrittenden]

Ok, So i've just been reading through issues and the code base for a couple days. It seems to me that the very basic requirements of the kernel haven't been figured out yet.

So far, from the discussion, it appears that we want a kernel that will handle:

Software Requirements:

1. Memory Management
2. Interrupts
3. Process handling + scheduling
4. stdio and a couple other std libs
5. Hardware communication (HD + Monitor + ?) 5.5 Simple filesystem based on FAT16
6. Networking (I haven't seen any hint of a specification that would allow us to do networking on these. So it sounds like the most we could do here is psuedocode and a specification)
7. All of this must be extremely small, and as fast as humanely possible. (Humanely is used purposefully here, it will always be possible to get the code a little faster, but at a certain point more optimizations won't be worth the amount of time and/or torment).

Quality and Speed Requirements: It has to be done SOON. It can't change much after it is done. And we can't spend much time documenting.

Organizational Structure:

1. The code will be organized by whoever wants to do whatever, whenever they have time. OR 2. We will appoint two/three people to organize all of the things.

To be quite honest, this seems insane. If I saw this in any commercial development team, I would run as far away as possible.

The latest argument seems to be on whether it should be Unix/POSIX-like or designed from the ground-up. Honestly, I don't care. My background is definitely in the unix-similar systems, because that's what the CS program at my uni focused on. Maybe we could look at FreeDOS or something else, but honestly, not looking at anything else while doing this is going to introduce massive issues (See: race conditions, locking issues, and memory access).

Minix is perhaps the best documented micro-kernel around, and I fully support everyone reading up on it, even if the rest of the group vehemently opposes using any of its implementation, the ideas are the same for any OS and are pretty much required reading for OS-Design courses.

This argument might be valuable, but it seems that we haven't figured out the very basics yet.

[viccuad]

So, essentially we want a lot of stuff done, in the lesser time, and without making any errors (we cannot afford to cicle again).

And we have two ways of doing it, don't we? One is to made it up from the ground. have a lot of bright ideas and don't fail even in one, and do it with people that have never made a kernel before and don't have any idea of what they are doing. The other one is to look at an already proven system, and mimic it in the dcpu-16. Oh, and even if we don't want to do this, we need to do it just to learn what we need for building it up from the ground on our own. That leads us to unix-like or BSD-like, well documented. (or windows-like, if someone is brave enough..)

jrcrittenden, maybe if you can convince them that making it whatever-like (i.e. unix-like) is not going to end in a bloated system, and has nothing to do with it, we could solve the whole design part in a breeze. And as jrcrittenden has already said:

but honestly, not looking at anything else while doing this is going to introduce massive issues (See: race conditions, locking issues, and memory access).

edit: hilarious presentation by A. Tannenbaum about minix: https://www.youtube.com/watch?v=bx3KuE7UjGA a quote: "Those who don't understand Unix are condemned to reinvent it, poorly." – Henry Spencer (https://en.wikipedia.org/wiki/Unix_philosophy)

[M52]

"I'm ok with docs, but I say we have a 1 month period MAX for documenting- there are plenty of ChaOS coders whop are pissed at the slow, constant redoing of the kernel."

It is going slow because we consistantly fail to agree on aspects, the project is disorganized, not on a code-wise level but on an organisation level.

I have no idea whatsoever what I should be doing and I think many people feel the same. I support viccuad's idea of basing ourselves on an existing architecture, that way we have a standard that we can all look back into. Designing one ourself might either prove too complex or, as you state, take too long.

EDIT: Oh and, what SirCmpwn says in issue #21, we need leadership. Preferably the brighest, most knowledgeable of us all and let him/her hand out the tasks to everyone.