posted by Eugenia Loli on Mon 27th Aug 2001 05:22 UTC
IconAtheOS is a modern, free (GPLed) Operating System written from scratch in C++. A big chunk of the OS is POSIX compliant, supports multiprocessing and it is GUI-oriented (fully OOP). Today we are hosting an interesting interview with the AtheOS creator, Kurt Skauen. Kurt is talking about his views on binary compatibility in future versions, multithreading and the future of his OS in general.

1. Especially after the release of 0.3.5, AtheOS received an even bigger popularity. It is amazing to see new software on Kamidake appearing almost everyday. How do you feel about this? Can you handle the "load" and responsibility that this generates?

Kurt Skauen: It's nice to see that people are interrested in the project but I don't feel responsible to deliver anything in particular. If giving away something automatically meant you where responsible to fullfill all demmands from everybody who accepted the gift I don't think there would be many free software projects out there. If people like AtheOS that's great but if they don't there is a lot of other OS's out thereto save their day. If none of them fit they can always write their own.

2. AtheOS is surely still young. If, for example, you would have to break binary compatibility for the general good of the OS (ie. a switch to gcc 3.01), would you do it?

Kurt Skauen: Indeed. I expect to break binary compatibility every now and then. At this stage I will break all compatibility from one release to another if it is needed to get some new features or changes implemented. I hope to be able to keep a good overlap in the future though so that people get time to recompile/update their applications.

As a side-note I can mention that even the latest versions of AtheOS is mostly backward compatible with binaries built for the first released version of AtheOS. Just for the fun of it I unpacked the ATerm terminal emulator from AtheOS V0.1.1 and tried to launch it and it started and run happily on the current "development version" of AtheOS.

3. I see a whole lot of BeOS refugees in your developer's mailing list. Most of them developers. How do you feel about this? Do you welcome the opportunity of lots of BeOS software may even be ported soon?

Kurt Skauen: Yes there seems to be a lot of BeOS developers on the mailing list. I have no problem with this as long as they don't spam the list with requests for turning AtheOS into a BeOS clone. That have not been a problem so far. I believe most of them know where I stand and have accepted that. If some of them decide to port some of their software to AtheOS that would sure be nice. AtheOS lacks a lot of important applications so that would indeed be welcomed.

Click for a larger version

4. What I am going to say is not widely known among the BeOS people, but it is true among the Be engineers: BeOS has a real problem when it comes to multithreading. While multithreading is great on paper, it makes it extremely hard to program larger projects, especially if your project has more than 1 window to manage. Large projects and (especially) ports were doomed to failure and to non-existance under BeOS just because of (the good and bad at the same time) multithreading (most of the programmers out there have no clue how to manage multithreading correctly in their code). Now, my understanding is that AtheOS is based on the same principles regarding multithreading. How will you be able to overcome this problem for your developers, especially without a debugger/profiler in place?

Kurt Skauen: I can see that the multithreaded nature of both AtheOS and BeOS can be a problem for porting large applications from a single threaded environment (ie. just about anything else). Converting any piece ofsoftware larger than hello-world from singlethreading to multithreading will always be very hard.

I don't see any big problems for large projects that is designed from scratch to be multithreaded though. All the required syncronization primitives are there and the threads that are "forced" on you have quite specific tasks. Then again I dont have any experience with writing large applications for either of the OS's so there is probably unforseen issues. I will just have to deal with them as they come.

AtheOS already have ways to chicken-out of the multithreading though.

I do have first-hand experience with porting large projects to AtheOS and I do know that making a foregin application taking advantage of the multithreading is very hard.

The by far largest GUI based project I have ported to AtheOS is KHTML. The HTML renderer used in Konqueror and ABrowse (the native AtheOS web-browser). KHTML is not multithreaded and rewriting it to do efficient multithreading would indeed be very hard.

By default all "active" objects like Windows use their one mutex to protect the object whenever any user-code is run. It is however possible to tell the window (or any other objects running in their own thread) to use a user suplied mutex instead. In ABrowse I just create one global mutex that is passed to all browser windows thus forching all the windows to be 100% syncronized. This will give the impression of a single thread of execution and made it possible to run most of the KHTML code unchanged under AtheOS.

5. AtheOS has come a long way even if it is still conceived as "young". And most of the work, is all yours, which I find quite amazing to come this far all by yourself. Please allow me to say that the only part of AtheOS that "standards" are not there yet is a Media Kit implementation. Any plans for a Media Kit?

Kurt Skauen: No, I don't have much plans for this yet. It is still a bit into the future. I have not spent much time thinking about things like sound and live video yet. This sure are important things but there is many other things above them on my todo list yet.

6. A lot of people seem to have a bit of trouble dealing with GRUB. Is there an easier setup procedure in the works?

Kurt Skauen: Yes. I started to work on a graphical installer a long time ago that will automate the installation process. I would really like to get some more work done on the installer both because it would make it much easier to install AtheOS and because I personally find it a very interresting project. Unfortunatly it continue to be pushed down the list by other "must-have" things. Like the web-browser :)

7. Any plans to jump off to gcc 3.x? (which reportedly generates much better code?)

Kurt Skauen: Absolutely. I have not had the time to look at it yet but it will be included in AtheOS and the whole OS will be compiled with it as soon as I manage to get it to build under AtheOS.

8. I am sure that there are parts of AtheOS (as with any project) that were written a long time ago and you would like to replace. If this is the case, which these parts are?

Kurt Skauen: AtheOS have been totally rewritten several times already but now things seems to have stabilized quite a bit. I'm quite pleased with the current foundation.

The TCP/IP stack need a large overhaul but I don't expect a full rewrite. There also is a lot of things that need to be cleaned up and fixed inside the kernel but there is no large modules that I would like to replace at the moment.

9. What are the cool things are you working for AtheOS 0.3.7 and for the future in general?

Kurt Skauen: The next release will be almost as boring as the previous. Mostly bugfixes and optimizations and very few new features. I have spendt a lot of time fixing bugs in and optimizing the TCP/IP stack. It now performs a lot better on connections with high latency. This used toscrew up the timing and kill the troughput in older versions.

The most interresting new feature is support for scroll wheel in the GUI. Catalin Climov sendt me a patch to the PS2 mouse driver that added support for IntelliMouse mouse wheels some time ago and I have now added support for mouse wheels throughout the GUI toolkit. Many of the standard GUI components (like list-views, multiline text views, scroll-bars, spinner controls) take advantage of the it without any extra support from the application and I have also added support for the mouse wheel to the terminal emulator and the web browser.

For the future in general the most imidiate project of some size is the desktop manager. I have a lot of plans for it and I'm looking forward to start working on it.

e p (0)    53 Comment(s)

Technology White Papers

See More