OSNews

Sounds like a LOT of fun, and great for cultivating the interest in operating systems needed to sustain more serious free software kernel development efforts such as Linux. I've said this many times, but you don't need an advanced computer science degree to hack free software. The whole premise is to keep the complexity down and to limit the expertise needed to contribute. Educational kernel projects such as this one are a great extension of this principle, particularly as this one tries to be a simpler Linux rather than an academic demonstration of OS design such as MINIX.

Like Almafeta (not something I say everyday), I also hope this project breaks with the Linux tradition and goes public domain. As an AIX developer, I can't look at a GPL kernel without forms filed in triplicate and two lawyers looking over my shoulders, and I'd like to take a look at this if only to satisfy my curiosity.

Edited 2007-05-02 23:55

Perhaps someone could provide other resources for those interested in learning operating systems?

Linux Kernel Development, second edition, by Robert Love, is highly recommended if your focus is on Linux. Otherwise, Operating System Design and Implementation, by Andrew Tanenbaum, is the classic textbook on OS design based on MINIX. An indispensable reference for any *nix programmer is The C Programming Language, by Kernighan and Ritche. These are by far the most useful dead tree resources I own.

Edited 2007-05-03 00:13

"An indispensable reference for any *nix programmer is The C Programming Language, by Kernighan and Ritche."

Followed by complains such as "But C is not object oriented" or "C is not a safe language", or at least "C is not Java!" :-)

"These are by far the most useful dead tree resources I own."

Dead tree resources... :-) Let's see how much of these resources are occupied by the OS in the resource monitor. :-)

By the way, if nothing else works, you'll be happy about printed material (e. g. system reference manual, troubleshooting and maintenance section).

Here's some of the pages I use the most.

This site's resources page:

* http://www.osnews.com/resources.php

The OSDev Wiki (currently in a rebuilding process as they try to combine two unrelated wikis from two unrelated software into a third set of software, but still has Good Stuff):

* http://www.osdev.org/wiki/Main_Page

Linux's kernel (they can't stop you from just reading the thing):

* http://www.kernel.org/

Minix 3's kernel (as a single HUGE file):

* http://www.minix3.org/doc/AppendixB.html

Some alt.os.development (usenet ftw!) archives:

* http://my.execpc.com/~geezer/osd/

Some questions to ask yourself before you write a single line of code:

* http://www.openbg.net/sto/os/
* http://chuos.genezys.net/wiki/Questions%20for%20an%20OS... (almost identical, but not quite the same)

Single UNIX Standard (free registration required) -- A standard that competes with (but in reality is almost identical) to the POSIX standard. You don't have to implement it if working like Unix isn't among your goals(although it's one of the few things used by pretty much every extant OS out there), but even if you don't implement it, it gives you a good idea of how modern OSs are structured:

* http://www.unix.org/version3/

Most of my other links I'm using go things specific to my OS, or to deficiencies in my skills that I'm amending, or references for specific hardware, so I doubt they'd be useful.

Hope all this helps!

*nodnods*

If we (using a very very generic 'we' here) ever want to have a really competitive market develop, then we need to build the sorts of resources that will help make many more people able to understand and (hopefully) turn to OS development. Not just developers who like the GPL license, not just developers who like the BSD license, not just developers who want to work at Microsoft, but anyone who will at least try.

The only problem I can see with that there are a very few countries who don't let people who are alive put their works into the public domain. One way I have of solving that: if ever SkunkyOS (see my profile) gets to a 'distributable' stage, I'm probably going to use this license: "© [whenever] Shanya Almafeta. Permission is granted to use the code of SkunkyOS for any use. [Standard disclaimer here.]" This 'one-clause BSD' license grants a maximum of flexibility to me (able to change license in future if needed, able to keep control of SkunkyOS's name as a trademark to prevent abuse) while not restricting users in any way (not even asking for credit or for the end-user to find an unobtrusive place to put the license).

Anywho, sorry for the tangent.

I agree. The more tools we have to learn how an OS works, the better. This is especially true when the code is simplified to better allow students to understand the fundamentals of good OS design.

I feel that I must point out that even if code is simplified, it by no means lends it to an understanding of good OS design. This is because simple, easy to read code is not guaranteed to make good design.

Bad design can just as easily be made to be simple and easy to read.

This is because simple, easy to read code is not guaranteed to make good design.

Strictly speaking, you're correct. However, good design correlates extremely well with simple and clear code.

Does this mean NetBSD is an educational OS too?

Yes, but well-planned, well-documented, and well-written bad design is that much easier to make into good design. :>

"I feel that I must point out that even if code is simplified, it by no means lends it to an understanding of good OS design. This is because simple, easy to read code is not guaranteed to make good design.

Bad design can just as easily be made to be simple and easy to read."

That's true, but I think the original poster meant that, assuming the design is good, it can be better understood if the code is clean and well documented. Hence the didactic value of this initiative.

The inclusion of the word "GNU" in the OS name means that the OS is indeed using GNU software (in the user space) and hence its complete name GNU/Fiwix, but does not mean nothing about the license of the other name "Fiwix".

« License
The Fiwix kernel will be publicly available under an open license when it reach the 1.0 version. »

mmmm. I would like to see the code now, since it *is* small !

"Unless this OS have some new concept in creating a new OS that others educational OS like Minix cannot emulate. There is no point in creating this OS."

Sure, you can read other peoples' code and learn from it - but I, and probably a large majority of other CS students - learn by tinkering and tweaking. Writing one's own code is the perfection of this.

For example (C++-specific, since that's what I was taught), when we first learn about linked lists, do we immediately start using the STL std::list class? No: we write our own dinky class for it. Do we start with std::stack or std::queue when learning about stack and queue operations, respectively? No! We write our own dinky classes for them that do the basic insert/remove/etc. functions needed. Do we use std::map when learning about key-value pair management? NO! We Write Our Own(tm). Is it becoming clearer to you now?

"Sure, you can read other peoples' code and learn from it - but I, and probably a large majority of other CS students - learn by tinkering and tweaking."

Remember, kids, trial & error is not a programming concept. :-)

"Writing one's own code is the perfection of this."

Learning by doing seems to be the way most developers achieved their knowledge and abilities.

"For example (C++-specific, since that's what I was taught), when we first learn about linked lists, do we immediately start using the STL std::list class? No: we write our own dinky class for it. Do we start with std::stack or std::queue when learning about stack and queue operations, respectively? No! We write our own dinky classes for them that do the basic insert/remove/etc. functions needed. Do we use std::map when learning about key-value pair management? NO! We Write Our Own(tm). Is it becoming clearer to you now? "

Same here. :-) This "archaic slime" is what makes programmers know what they're doing. Using std:queue is easy, but knowing how it works will help you in some situation that might be not that easy. Therefore, atomic types (int, char, void *, even FILE *) are important to know about. They don't need to be used everywhere (especially when functional libraries exist). It even teaches structure (the one you can see when you're looking at source code) - if the teacher is smart enough.

If you know one programming language, you know them all. :-)

Why should it matter to you if somebody is reinventing the wheel again - simply ignore it. It is very useful to others as an educational tool and exciting to work on.

I think this one is monolithic OS written in C because both Windows and Linux are monolithic kernels primarially written in C, and C is the language that the most students will be familiar with.

(I know, I know, Windows includes some sections in Pascal, but the majority is in C.)

It is my impression that C is still the best language for implementing an operating system. For one, we created HelenOS in C and a bit of assembly. However, one of our developers is now working on a research project in which he implements parts of HelenOS in Objective C. His research area is componentization of the operating system. The object oriented language can be also used to implement some operating system constructs more straightforwardly (e.g. virtual methods) than it would be possible in plain C. As for performance loss, according to Martin's experimentation and measurements, it is almost negligible. With ObjC, you need to supply the kernel with a small ObjC runtime code. In case of C++, this runtime would be a bit bigger.

But again, there is nothing you couldn't achieve in C which you could in other languages. So I think using a different language can make your code more expressive and straightforward but will not bring more research into your OS.

Sadly and no offence here, I also feel that the idea of writing an operating system in a non-C language, especially in an object oriented language, has become sort of a cliche.

First, this is not simply an experimental OS. It is at least partially intended to serve as an easy introduction to OS development for those interested in hacking the Linux kernel. So it wouldn't make sense to code it in anything other than C and native assembler.

While C is the undisputed king of system programming languages and the ideological underpinning of UNIX, I find it hard to imagine that C will remain the dominant systems programming language indefinitely. Although I don't see any OS project on the horizon to unseat C-based systems within the next 15 years, I would be surprised to find C retaining its ubiquity when I'm old and gray in 50 years. Certain technologies are incredibly resilient in the face of progress, and C is one of them. But they all fade away eventually, pushed aside by new technologies whose fundamental ideas are irreconcilable with the giants of yesterday.

While D is a promising evolution of the C heritage, one on which I would like to see an OS based, it is not at odds with C in a fundamental way. Therefore I don't see it ever rising to dominance. The technology that makes C irrelevant will most likely involve a revolutionary hardware architecture that demands a more dynamic and adaptive language than anything we have today.

I wonder if Mr. Tanenbaum and Mr. Sanfeliu will ever go at it.