OSDev.org

If all the members in this forum start writing together a brand new OS as a team work, can we write a better OS than Windows and Linux?


(This is just a thought. Dont think otherwise.)

Probably not at first. Throwing more developers onto a problem does not always equal a faster or better solution. Instead, it's more likely that if one project gets mature enough and then other people jump on board, then that'd be our best chances. But something like Linux took so many man-years to make, and although we wouldn't have to reduplicate *all* of the effort, it'd still be rather like reinventing a whole lot of the wheel first.

No, and the goal of most people on this forum is probably not to write an OS that is better than Windows or Linux in a general sense.
As it says on the Wiki, OS development is a huge and difficult task and it can take years just to get meager results.

The main point of OS development for me is to learn more how computers and OSes work on a fundamental level, rather than just writing code that calls the operating system without knowing what is going on behind the scenes. I do not intend to ever release something a lot of people would want of use, nor do I intend to make any money on it.

Other people writes operating systems because they have a certain idea they want to see implemented. For example, Linux is a monolithic kernel and Windows has evolved from a monolithic one to a hybrid one over time. So many people want to implement a microkernel, or something even smaller. Their goal isn't usually to compete with Windows' or Linux's market share, but merely to see their idea come to fruition.

Probably not, because people would keep arguing about the design (and most importantly, coding style!) rather than actually developing the OS.

Any individual working alone can potentially create the best OS for a particular purpose, but if we all tried to build a single joint OS there would be no end of conflict and it would by unlikely to get anywhere at all. More likely is that groups of people with similar ideas could work together to create the kind of OS which collectively appeals to all of the members of that group, but that can happen already if people simply pick an existing OS that they like the look of and join the team developing it. Some people don't want their OS contaminated by any code written by compilers, while others want to do everything with compilers so that their OS is easy to port to other platforms. Some want monolithic kernals while others want microkernals or modular ones, and while a lot of people would probably be prepared to compromise on that and build something that's a mixture of all three, you mustn't forget that people actually want to build their own OS, so the idea of abandoning that just to write a new Linux doesn't have a lot of appeal.

What you want to happen probably is happening as much as it ever can, but maybe you've asked the wrong question. Could we all create OSes on a par with Windows and Linux if we made greater efforts to create components that can easily be used by others with little or no modification such that it becomes child's play to add dazzling capabilities to your OS? Instead of throwing all our effort into a single OS (or two or three of different types), it would be better for us to think about how to get all our OSes up to the point where they are able to offer all the services that applications would be likely to ask of them (and ideally have some kind of common API so that applications can run on all of them without modification, though not necessarily as the only means for applications to interact with the OS - there's no reason not to have two APIs in every OS, the alternative one being provided for applications which want to take advantage of the specific, innovative design of a particular OS).

We should try to make all the components of our OSes easy for other people to copy or borrow from so that they can take shortcuts and focus on making their OS the best OS for what they want to do with it instead of having to reinvent every single wheel along the way, so the trick is to write how-to guides at the same time as you write your OS to make it easy for others to learn from your work, and you can also read the how-to guides written by others in order to take shortcuts in areas where you don't want to get bogged down for years in doing something dull which isn't going to make your OS distinct from any other OS anyway. I aim to turn my entire OS into a how-to guide so that people can take the whole thing and replace any parts of it with their own code if they don't like the way I've done something, thereby evolving it into their own OS which may eventually contain no code of mine at all. At the moment it's too much of a mess to be a useful guide for anyone, but I'm working day and night at the moment to eliminate all the glaring design faults. Even so, it won't appeal to everyone as it's based on doing all the programming directly in machine code, but other people can do the same kind of thing with their OS, appealing to people who program in assembler, C, or whatever programming language they prefer.

What sorts of things could be provided as standard components? Here are a few examples:-

(1) Code to load and save the OS and any files generated by it and using all the different kinds of storage devices. You may want to write substantial parts of this yourself, but why not start with something that already works and then modify it, replacing parts with your own code wherever you have ideas about doing things differently?

(2) Code to handle memory and allocate it. Lots of different ways of doing it could be made available, so you'd pick the one closest to what you want to do and then modify it as necessary to fit your exact needs.

(3) Code to get the computer into a decent screen mode and to enable you to use the screen easily and efficiently. This is really dull stuff which none of us should be wasting time developing independently.

(4) Code to display jpg pictures - how many of us could ever do that for ourselves? I don't know if we're even allowed to.

(5) Code to play video files - the same applies. You might think this is more of application than part of the OS, but you may want to be able to get video in from a pair of webcams to use them as an input device for controlling the machine, and you aren't going to be able to develop that kind of system if you can't even display the video.

(6) Code to handle all the ACPI stuff for you.

(7) Etc. (add your own ideas to the list).

In short, we could collectively write a whole stack of OSes which may share many parts and which could realistically get up to the level of Windows or Linux in terms of functionality, even if you have a more restricted choice of gadgets to use with them (in terms of different brands and models). The most important thing would be to have a common API so that the rewards of writing an OS that uses it are maximised, and many more people might then come on board to write their own OS, knowing from the start that they will end up with something that will be fully functional and useful not only when it's finished, but long before it's finished - they can start off by putting together all the components that fit in best with the kind of OS they are trying to create so that it will be fully functional from early on. They will then be able to modify parts of it which don't work the way they want them to in order to turn it little by little into an OS of their own design. Then the thing might become part of the school curriculum and millions of people may get involved in making their own OS, and at that point the serious application developers would begin to take an interest in what is from their point of view a single platform with millions of users, even though the code running beneath the surface may be radically different from one OS to the next.

If you do what you're saying, you basically get UDI/CDI, and you're back where you started.

Remember, it still takes nine months to make a baby no matter how many women you recruit for the project.

There are OSes that were spawned by multiple members of this board.

Pedigree, for example.

Chandra wrote:If all the members in this forum start writing together a brand new OS as a team work, can we write a better OS than Windows and Linux?

What does better mean?
What ever the anwser is...no we cannot. Programmers tend to be very mean and egoistic and soon you would have a burst od "brilliant" different ideas and each one thinks that his or hers should be implemented. Also when you divide the project, there will always be people who will slow things down by being lazy, unproductive, strong on ideas and poor on implementing them, etc.

Why Linux worked? Simple because it was programmed to be _usable_ system by only _one_ programmer and after he made code available to others it was only the question on how to perfect it. And even then....I don't think that anyone expected to grow so big.
Other then that...we are already too late...20 years to be precise. 80s and early 90s were arena of operating systems. Well, today thanks to the mobile devices they are somewhat back to mainstream, but still no newcomers.

But if you still want to see osdev.org collaberation, I suggest a very small team of expirienced programmers like Brendan, Solar, Bewing...

NickJohnson wrote:If you do what you're saying, you basically get UDI/CDI, and you're back where you started.

Or you create a new API and adapt/rewrite UDI, CDI or other drivers to work with it. The important point is that anyone creating a driver for use in the system would be making something that can be used by a great many OSes, and it wouldn't even need to replace the normal UDI or CDI interface, so you can retain that in an OS that already uses it. Int 3 is probably available for an experimental standard additional API on most OSes, and it shouldn't be hard for anyone to add that to their OS and convert all the calls to tie in with their existing API.

Do drivers need to be rigidly tied to UDI or CDI anyway? The aim in writing a driver should be to make it as easy as possible to adapt it to run under any API - by doing that, it doesn't matter which API wins out in the end because any driver written will be used extensively in some form or other anyway. As soon as you tie it to a particular API and make it hard for other people to modify it for other APIs, you doom it to probable extinction by narrowing its appeal to well below the critical mass required for success. We need to be creating drivers which are designed to be easy to adapt to fit into any OS regardless of the API(s) used there. It may actually be that the existing UDI and CDI drivers are so well documented that they are easy to adapt anyway, so using them doesn't necessarily mean that you have to commit yourself to the UDI API or the CDI API. I would suggest that a new API which doesn't get in the way of UDI or CDI would be the best approach, initially keeping it really simple and restricting it to the most essential services, but always ensuring that it can be upgraded to be more capable without making the old stuff incompatible, and that could be achieved by putting a version number in a register on each call alongside the register which specifies which service it's requesting. The new applications may become incompatible with the old versions of API calls, but each new version of the device driver would come with sufficient documentation to enable any OS writer to adapt it to fit into their OS so that they can keep up with all developments, and of course, anyone making a new OS would just go straight for the latest versions of everything make sure that it's all tied in properly to all the old version numbers of calls.

All of it should be done on the basis that if it ends up in an OS which is actually sold for money, the writers of the device drivers get their fair cut of the money - it may seem unlikely that this will ever happen, but who would be happy to give their code away freely and then to see other people charging for an OS containing it and giving them nothing? It's not beyond possibility that your device drivers could end up in an OS which runs a killer application that makes it popular. If we target our OSes at use in education, there's no reason why they shouldn't be licensed for use in schools and generate a modest income, and bear in mind that schools often pay out six-figure sums to use really uninspiring software of a trivial nature even in a single region of a small country. I don't mind individuals using my software for free, but business usage is another thing entirely, and schools are a business: everyone else is paid in one way or another for their work when it's used in schools, so we should not make ourselves an exception.

CelestialMechanic wrote:Remember, it still takes nine months to make a baby no matter how many women you recruit for the project.

That doesn't really fit as an analogy because you can speed up the development of a number of OSes substantially by sharing components, but it's often the case that the more people are involved in a project, the slower the progress becomes. That's where having different people work on different components as a free-for-all is a better approach, so long as they're all focused on maximising compatibility of the thing they're creating: everyone's working for themselves, but everything they create can be used by all, and anything that's used in a system that generates revenues will pay out a fair share to all the people whose work went into it.

The aim in writing a driver should be to make it as easy as possible to adapt it to run under any API

Looks and sounds nice in print, terrible in practice. Driver APIs are too dissimilar: there's not always a 1:1 adaption for a driver and the API functions it was written for.

That's where having different people work on different components as a free-for-all is a better approach, so long as they're all focused on maximising compatibility of the thing they're creating

I would have agreed with this in January last year, but I don't agree anymore. I tried this and ended up running into so many inter-dependent components that it became impossible to work on "different" components without some work shared. This means you do need to have agreement on how to do something from all members of a project, and the design process needs to be flexible and efficient. The key word is "flexibility" - that's how you avoid significant issues in a hobby-based team project.

Knowing which components are inter-dependent helps too, but that really comes from experience .

and bear in mind that schools often pay out six-figure sums to use really uninspiring software of a trivial nature even in a single region of a small country

I don't know which country you are from, but in every school I've seen (private and public, excluding the extremely high-quality grammar schools) six figure sums give both IT administrators and their bosses heart attacks .

Schools here aren't made of money, and as someone working in one I would find it extremely difficult to justify a six-figure sum for a piece of "inspiring" software, let alone "uninspiring". Three or four figures on the other hand...

Crazy! Firstly all OSes are meant for different targets and therefore will be different. Also people follow different coding styles, even if we wrote a coding style guideline we would all use different algorythms and styles to do the same thing, as aresult you get a big 20000000000000000TB piece of junk. (Personally I feel the linux kernel is starting to get bloated.

pcmattman wrote:

The aim in writing a driver should be to make it as easy as possible to adapt it to run under any API

Looks and sounds nice in print, terrible in practice. Driver APIs are too dissimilar: there's not always a 1:1 adaption for a driver and the API functions it was written for.

The most time-consuming part of writing any driver is reading through all the technical stuff about it and sorting it out into something you can get your head round and translate into a form that you can actually work with. You then have to work hard to determine which bits of information are actually needed for a minimal implementation which you can build on later to add more capability. Every time it's a bit like trying to solve Rubik's cube, and yet if one person has done that work already, that understanding can then be shared, thereby slashing the amount of work that other people have to do. The resulting drivers written by different people to communicate with the same device may end up being radically different in numerous ways, but apart from the first one, all the rest should be straightforward to write because the groundwork's been done, and it may also be possible to copy and paste whole chunks of code as well. Much more important than the actual code is the how-to guide that can be created along the way to make it easy for others to follow in the same tracks. The alternative to this is for everyone to crawl along for years reinventing the wheel over and over again while creating OSes which will never achieve the full functionality they want for it. Waste of life.

There are a great many talented people reinventing wheels here who could, if they were able to get through the early stages of OS development much more quickly, be breaking new ground instead by helping to write device drivers and how-to guides which will help everyone else who follows - the sooner they get to the front line, the quicker all the OSes here will advance, including the most advanced ones. Clearly the people who are furthest behind have the most to gain from this, but there are gains available for all.

and bear in mind that schools often pay out six-figure sums to use really uninspiring software of a trivial nature even in a single region of a small country

I don't know which country you are from, but in every school I've seen (private and public, excluding the extremely high-quality grammar schools) six figure sums give both IT administrators and their bosses heart attacks .

Schools here aren't made of money, and as someone working in one I would find it extremely difficult to justify a six-figure sum for a piece of "inspiring" software, let alone "uninspiring". Three or four figures on the other hand...

Not single schools - I'm talking about government education departments which buy stuff for all the schools in their region collectively, so your three-to-four figure sums can often be multiplied by a hundred. I'm basing this on someone I've read about who has become a millionaire just through selling dismal crap to a single region in Scotland. He wouldn't get away with that if he had to sell to individual schools, but if the software you're trying to get into schools is of high quality and genuinely useful, all those three to four figure sums can begin to add up and you could get the same end result. Then again, you could easily run into an endless wall of visionless morons and get nowhere, but my point was that it could potentially happen and that you wouldn't want your code to be included in the package if you weren't going to be paid for your contribution while someone else gets fat from it.

There are a great many talented people reinventing wheels here

Isn't that the point of hobby OS development?

Not single schools - I'm talking about government education departments

Ah, fair enough. I see where you're coming from now.

pcmattman wrote:

There are a great many talented people reinventing wheels here

Isn't that the point of hobby OS development?

Partly, but not for the sake of itself. I think it's more about learning how things work. Once you've written one or two network drivers and you know that the ten other drivers that you could use are similar in principle, writing them is just boring work. So at this point I'm more than happy to take your code for the next driver. And this is exactly what I did - and you did the same with my code because you didn't feel like reinventing the wheel for this particular driver.