Linked by Emmanuel Marty on Mon 5th Aug 2002 05:58 UTC
I've always been curious about how things work. When I was little, I annoyed my parents with millions of
questions. Why is the sky blue? How does water come out of the tap when you open it? Maybe I was born without the
mental switch that lets you be happy with using something, without trying to figure out how it works.
Permalink for comment
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Recent Original Stories
Recent Comments
Headlines
Random Comments
Random Stories
Random OS Link
To all,
Thanks a lot for your comments. Positive or negative, peer review is always great.
This editorial piece is about sharing my experience, if it helps take out some of the frustration. Make it more fun to develop your OS and see it work in the end.
It does not even try to cover the commercial success of an operating system. That's another problem entirely. It's a conflict of interest with having fun developing something according to your own dream, anyway. It's fair to say that Linux had technical success as well as being adopted because it filled a need. It's true AtheOS was successful technically but not for adoption. Both of them do fit in the pattern the editorial piece describes.
About the integration-validation part, it's true that if you have only one guy, like on AtheOS, his window of time is fixed, and you can either do one thing well and deeply, or many things superficially; what Vanders calls "skin-deep". What you probably want to do is: design and code the basics by yourself. Later, switch to a position where people send you patches, and you OK them and commit them. Once you've grown a team, trust one or two more people to commit as well, then you can go back to a little bit of coding.
Using wiki to avoid losing patches and speeding up their handling is a good idea, Vanders.
Overcoming the 'kernel fright' (people stuck in bootloader land) is an interesting topic too. Using GRUB on PC-AT is a better starting point, certainly, if you want to develop your kernel without being dismayed by fitting assembler in 512 bytes and switching to protected mode. As someone said, that will not prevent you from having to know assembler and the IA32 in-depth; but it can get you up and running quicker.
The OSKit is quite targetted at the people who want to advance the state of the art, in a particular domain. They want to implement the VM techniques they describe in their PhD. They want to implement a new scheduler. People who want to learn how it all works will want to start from scratch.
The "top-bottom" approach prevents having to write the whole kernel before you can print "hello world". You can design and implement a lot of it as an application on top of another OS. Provided there is a good and clean design, moving it to native afterwards can and has been done.
Emmanuel