Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Programming IT Technology

Architectures for Homebrew OSes? 5

WalterGR asks: "The recent article about Athena and discussion of other home-brew OSs has really gotten me interested in the subject. I'd like to try my hand at it, but I don't want to make just-another-[insert your favorite platform] clone. I'm not striving for compatibility, as I don't want to be hampered by legacy systems. Because compatibility won't be an issue, I'm at liberty to choose any architecture. Which one would be best for a brand new OS? The PC architecture seems to be a mess of backwards-compatibility baggage and afterthought. What is the best alternative, considering speed, availability of hardware, cost, availability of documentation, design, and so forth?"
This discussion has been archived. No new comments can be posted.

Architectures for Homebrew OSes?

Comments Filter:
  • by Bryan Ischo ( 893 ) on Saturday May 12, 2001 @06:14PM (#226661) Homepage
    The architecture you choose is entirely up to you, of course, but here are some suggestions to keep in mind which may help to make your OS more useful and interesting:

    1. Throw everything that you know about current OS's out the window. There is no point in building a new OS unless you can come up with some new ideas to make something truly unique. So don't base your ideas on what currently exists - you can use current technologies as guidance, but don't let them limit the way you think about the solutions to problems. Studying current technologies actually is useful because they have all come about to satisfy needs, and in studying them you can learn alot about the kinds of needs that users have, but the approaches to meeting these needs should not be encumbered by current technology.

    As an example, consider the file system. I myself have been trying to think about better ways to structure permanent storage than the current system. So far I have had no luck - it's a hard problem - but maybe you will come up with an idea which revolutionizes computers. Right now filesystems are throwbacks to the 1970's - hierarchical storage systems based upon string names. "Files" are organized in "directories", all of which have names, thus creating a hierarchically-named set of raw data files. But is there a better way? Is there a way to store data on a permanent medium such that storage and retrieval is much more natural? Perhaps by storing context information based upon the situation in which the data was created, so that retrieving that data at a later time is simply a matter of reproducing the context? Maybe this will make finding information much easier for the user. All I know is, poking around filesystems by opening folder after folder, drilling down to where you think the file might be, and then returning to the top level again for another look, because you can't find your data, seems like an awful waste of time, and one which the computer ought to be able to provide more assistance in than is currently done in modern OS's.

    2. Remember that an OS is nothing more than the program which allows the computer to run other programs, and provides the overall organization of the system such that programs (and users) needn't concern themselves with mundane tasks such as locating file data in the sectors of hard disks, or composing TCP/IP packets, etc. Don't overdesign your OS to do things that programs or users should do, but at the same time, don't underdesign it, so that programs and users have to come up with their own mechanisms for managing system resources. In the former case, you will stifle further development of your system by hardcoding in things which are better left to programs to handle in different ways which may suit different users better; in the latter case, different users and programs will fill in the gaps of your OS in different ways, resulting in fragmentation and incomatibility.

    3. Release your code under the GNU Public License. Don't make your own license, don't worry about licensing schemes which try to ensure that you can extract maximum revenue from your code should your OS become popular in the future. If you are very lucky, your code may gain a following. Releasing your code under a closed license or one which does not offer the full freedoms of the GPL will hinder your ability to gain support from developers in the free software community, and developer support is probably the most important factor in the success of such a project. And if your OS is popular, you will be paid back in myriads of ways, not all of them monetary.

    4. Keep in mind that you will probably want to offer the ability to run other open-source code on your OS in the future. You shouldn't cripple your system for the sake of compatibility for Linux/FreeBSD/etc. programs, but keep in mind that at some time in the future (maybe earlier rather than later), you will want to run such programs, so from the beginning keep the concept of a "POSIX compatibility layer" or somesuch in your mind, and design so that future implementation of such a thing is possible.

    5. Don't listen to people who will try to discourage you. Many people will say, "You're wasting your time - we already have so many OS's, we should focus our energy on expanding Linux rather than coming up with a new OS." Remember that your time and efforts are your own and no one else's, and only you have the right to decide what you should and shouldn't do with your time. If something interests and intruiges you, then do it. Don't worry about repeating someone else's work. If nothing else, the best way to learn is to do, and if your project fails, then at least you will have learned alot, and who knows, you may then be able to contribute to something like Linux much more effectively because of your experience, should you choose to do so. There is more than enough room in the world of software for new OS's, and new ideas, so go for it, and don't let naysayers discourage you.

    6. You might consider setting up a web site or mailing list for discussion of your ideas before you implement them; other people can provide valuable insight into your problems and maybe enhance your ideas so that when you do implement them, they are that much better.

    Best of luck, and keep us posted on your progress!

  • by Betcour ( 50623 ) on Saturday May 12, 2001 @11:39PM (#226662)
    The PC is not such a mess as you describe. ISA being dead - you end up with PCI which is very clean. Aside from that there's the x86 CPU which, while having some quirks from the old day, can work as well as any other RISC provided you use it properly (32 bit protected mode, MMX & SSE instructions, etc...)

    Frankly the idea that the PC is full of legagy shit is a real stereotype. Sure if you want to support every piece of ISA extension card that roamed the earth, you'll have to deal with lots of horrible legacy stuff. But if you drop ISA cards support everything is as clean as anywhere else (PPC Mac, Alpha, Sun, whatever as they all use PCI bus now too).
  • ... the Sega Dreamcast is the way to go.

    It has a 200Mhz Hitachi SH-4 processor, 16MB of system RAM, 8MB of video RAM, a seperate ARM7 core (with 2MB ram) for audio, ... the list goes on. You can find a lot more info here [mc.pp.se] and here [julesdcdev.com].

    You didn't really specify in your post how big or small of a system you're looking to target, but for a small net appliance and/or hobbyist 2D/3D gfx fun, nothing out there (in my opinion) tops the DC.

    In the US a base DC is now only $99, and the 10/100Mbit ethernet adapter ranges from $50-70, depending on where you find it (e.g. the cheapest would be eBay, but Sega also sells them). A keyboard and mouse will probably run you about $10-25 apiece.

    Current OSes scrambling for exposure in the DC arena include:

    Dan Potter's KallistiOS [allusion.net] (the first native DC OS),

    NetBSD/Dreamcast [netbsd.org],

    Our very own LinuxDC [linuxdc.org] Project, and

    There's even a port [m17n.org] of RedHat's eCos [redhat.com] underway!

    M. R.

  • by mini me ( 132455 ) on Saturday May 12, 2001 @08:24PM (#226664)
    Obviously the code where you have to directly access the hardware will not be portable but the rest should be portable across basically everything. In essence you have your hardware layer and the "everything else" layer(s). You can focus on one platform if you chose, but by just modifying the hardware layer you can get your OS to boot on any system (atleast in a perfect world)!

    As per which platform you want to initially work on, I would actually recommend working on embeded systems. Unless you are looking to build the next big server or desktop OS, the embeded market seems like a good place to start. Embeded systems are all the rage now-a-days since computers are going into almost everything. Maybe you would even create a niche for your operating system, oh I don't know, say in internet connected toasters? Maybe a toaster of that caliber doesn't really need a full-fleged multi-user OS such as Linux, but security is still a concern, I don't want people on the net burning my toast and that is where you could fit in!

    Again it all goes back to what you want your OS to do, if you want it to be something that will replace Windows then you aren't going to want it to run exclusivly on toasters, but if you are just interested in OS design and want to build one for the sake of just building it, I would go for the embeded market.
  • If you need any inspiration, you should try to read Tanenbaums book on Operating systems. It includes a cd with the OS and he included the sources in the book explaining some of the features in OS's with source code :) Makes it very good to understand. You should at least have a good understanding on how existing systems work and what their strengths and weaknesses are. Then come up with something better. Be sure to let us know how you progress

Stellar rays prove fibbing never pays. Embezzlement is another matter.

Working...