Re: [Trion-kernel-dev] Is the project still active?

[Daniel R. <cos...@gm...>]

> Christopher Bertels wrote:
> So my question is: is trion still being developed and if yes, could i  
> help out
> in programming? i will continue reading my book on os design and i'd  
> like to
> help out wherever i can, even if it's the more easy stuff.

Stephen is right when he says that the project does not always develop as  
fast as it could. Nevertheless we also made some considerable progess  
lately, and I still haven't lost my hope that Trion really will take off  
one fine day. Operating system development is a difficult task, maybe it  
just takes some time until you can see the results.

> Stephen M. Webb wrote:
> Heh, yeah, the project is sort of dozing off and on.  Most of thecurrent  
> work on v0.2 was done by Daniel Raffler in a brief flurry ofwork a few  
> months ago.

The reason for my rather errratic coding cycles is that I really have some  
problems stuffing all the theory in my mind into a concrete  
implementation. The nankernel design leads to an extremly "dense" nucleus  
as a lot of decisions with potentially high impact have to be made at an  
early stage. Almost all of the the code I contributed during the first 4-5  
month of the year was hardare related and merely built an abstraction  
layer for the upper components of the nucleus. When I finished with this  
stage I had to return to pencil and paper sketches in order to design the  
rest of the implementation. By now I've finished most of the planning, so  
that I'm really confident that I can continue coding and documenting  
anytime soon.

> Stephen M. Webb wrote:
> I think the next major task in the kernel is to work the scheduler and  
> dispatcher.

Before we can tackle that some more work on the kernel memory manager will  
be needed. I've already finished most of the paper-work for the kernel  
memory system, so that it shouldn't take too long until I can present some  
more details.

> Stephen M. Webb wrote:
> I still think in the coming era of multicore hardware a new OS will rise  
> up.

With the first quadcore getting released just next month, there's probably  
no denying anymore that multi-cores system will be the future. What impact  
this will have on operating system designs is however hard to say. The  
most obvious changes should be in scheduling, but I could also imagine  
that many other areas will be affected indirectly. It's also possible that  
our nanokernel architecture turns out to have some more advantages on such  
machines as it makes the system more reentrant and modular. This should  
allow a more parallel processing of system task, which is the key to high  
performance on multicore systems.

Nevertheless it's in the end always the user applications that make the  
difference: A game that doesn't support multiprocessing on Windows, won't  
perform much better on trion, even if we had the superior multicore  
support. If we're going to lean towards MP systems as our target, we must  
design the whole platform (kernel, drivers, servers, api, libraries,  
programming techniques) with parallel processing on our minds.

> Sergey Kuznetsov wrote:
> I feel that in the future we will have big computer clusters who
> will do the main work, and we will have lots of embedded
> thin clients with plenty of bandwidth and cheap not powerful CPUs (
> probably as a part of powerful GPU) so all calculations will be
> offloaded to that CPU clusters, and pre-cooked data will flow as
> compined video-sound stream to the thin clients.

It's not that I've never thought about this idea. Even today such a  
computing farm could pay off for most average users that hardly ever use  
their computer for anthing more expensive that browsing the internet or  
writing some word documents. They could pay their service per volume or as  
a flatrate and the cluster centre would provide them with the necessary  
computing power. As such users don't need a whole computer of their own,  
the computing centre wouldn't have to buy that much hardware (200  
computers for 1000 clients) and could thus sell its services at a  
relativly cheap rate. For the more expensive applications (gaming, video  
editing, etc) it wouldn't pay off as each client would have to be given  
it's own node in the cluster. As our need for computing time grows at  
least as fast as technological progress increases our resources I actually  
doubt that this will ever change.

In a few decades average users might indeed use such services, while power  
users will in my opinion always rely on their own hardware. After all most  
of use still use their own car rather than public transport and owners of  
big farms don't borrow their machines from the community.

As a goal for trion I thus don't know if cluster computing is really such  
a good idea. It's not only that we would be writing software for a harware  
that's still far away, but also that I frankly don't know in what respects  
an operating system for such a platform would have to be different. My  
impression always was that clusters can be handled just fine on the user  
level. A server receives all request and then distributes them among its  
nodes. Both server and client applications are quite simple programs that  
shouldn't require any support by the kernel.

> Sergey Kuznetsov wrote:
> I like the idea and it would be nice to implement some ideas I
> shared here two years ago (universal byte-code and so on)

What's the point of having a universal byte-code if the sole remaining  
mainstream architecure is x86-64 ? The only areas where other platforms  
might be used are science, video consoles and possibly IA-64 servers.  
Apart from these most exotic architecures seem to be quite dead nowadays.  
Also note that I'm not sure to what extend the operating system really has  
to support cross platform compatibility. From what I can tell both Java  
and CLI seem to work just fine without additional kernel support.

> Sergey Kuznetsov wrote:
> What if we will make some brain storm here ( I love brainstorming ) what
> do we need on the web-site, and later make the voting on the topics and
> will assign priorities on each feature.

In my opinion the main purpose of the site right now is to present the  
project and to recruit developers. For that we don't need a fancy polling  
system, but a simple site that gives a concise (yet complete) description  
of the project providing the visitor with all the information he might  
need.

a) Providing a couple of screen-shots might catch the visitors' attention.  
If screens are available the user at least gets the impression that the  
project is alive and has a code-base that has already reached a certain  
maturity.
b) The site should describe the goals of the kernel in much greater  
detail. Right now there're only a couple of rather generic sentences about  
our design on the page. Developers however want to know much more about a  
project before they might consider to join: Why should I join Trion and  
not some other sourceforge  project ?
c) A project history and a roadmap for the next 6-12 months should give  
the visitors an impression of the current state of the project. It can  
also help us to keep track of the development as we plan in the long term.  
This section should get updated regularly as the development proceeds. It  
could even be an alternative to the not-so-exiting news sections that most  
other projects have.
d) The "What Can I Do?" section should in my opinion be more specific. We  
don't need somebody to do anything, but a developer that know language X  
and has experience with Y to write module Z. The more specific the given  
information, the easier it is for a potential developer to imagine his  
tasks. Visitores interested in the project would no longer have to  
register to the mailing list in order to find out what exactly they could  
contribute.
e) A member page with some private information about the regulars might  
give the project a personal touch. After having leart a bit about the  
other team-members, one might be less hesitant to get into contact with  
the team.

> Stephen M. Webb wrote:
> The best place to start is to build the kernel from source, create  
> yourself a
> floppy or CD and boot your own computer, just to get the hang of it.   
> You can
> also boot the kernel using bochs or, I hear, vmware.  Use the v0.2  
> branch in CVS.

If he's really new to OS develpment chances are that he doesn't know about  
the toolchain or has no experience with installing bochs. It would  
probably also be a good idea to add a number of such beginner tutorials to  
the wiki.

> I'm not a big fan of forums:  I would prefer using the mailinglist for  
> support but I'm open on that count.

I second using the mailing list for development purposes. It has the big  
advantage that every member is reached when something new gets posted,  
while a topic in the forum might not be read by everybody for days or even  
weeks.

> Jeff wrote a long time ago:
> It would be nice if we could use a localized toolchain. Obviously I
> can add in the directories into the path, but does GCC make any
> assumptions about where to find files?

Just in case that this is still an issue: Including the cross-compiler  
directory in your PATH does the job. I've been using this method myself  
and gcc never had any problems finding its files.

regards,
Daniel