Slashdot Mirror

Not long ago you asked Kurt Skauen about his AtheOS, a GPL'd OS with an integrated GUI and notable commonalities and differences from certain other GPL'd OSes. Kurt responded at length on everything from choice of programming languages to whether you'll see a version of AtheOS soon for the PPC. He also talks about dealing with interoperability (with Windows and with *NIX), why he chose the GPL, and what might drive him to change the AtheOS licensing.

Application framework & Development
by absurd_spork

Two questions, actually:

I think that not having X on board is a good idea, actually, because if you had X on AtheOS, everybody would start porting over X applications and then you'd have a lot of applications with an entirely different look & feel, which would spoil the integration that AtheOS currently offers. However, for the future, there's going to be need for a well-documented application framework in order to facilitate application development (for options such as component development and so on); since you already ported part of Qt to the native AtheOS system, what would you think about porting as much of KDE over to AtheOS as possible without including X, so that not too much of the native system's advantages would be lost, yet you could use the portability of KDE to ensure a broad supply of end-user applications?

I realize that you do very much of the actual development yourself, at the moment. What would you think of partially delegating development, such as putting up a list of "what is needed" to-dos, discussing the actual implementation with some developers, but letting them do more of the actual work? Because you've come really far with the OS, but I presume it's at a critical point at the moment where it needs to gain momentum. You could assume some sort of "benevolent dictatorship," we have at least one case in operating system development history where it worked out fine :-)

Kurt Skauen: Well the "Qt port" used by KHTML for AtheOS only supports exactly those features used by KHTML and nothing more, so I would not really call it a Qt port. It was just that I had to either rewrite the HTML/FORM code in KHTM to use the AtheOS widgets directly or wrap the AtheOS widgets with some "thin" classes that exported a Qt-like interface and used the native AtheOS widget internally. Each widget (like button, checkbox, listview, etc, etc) is implemented individually and the rest of the GUI infrastructure is not ported from Qt but is handled by the AtheOS toolkit itself. I had two main goals when making the port. First to make the browser behave like a true native AtheOS application, and secondly to make as few changes to KHTML as possible and still reach goal one to make it easier to update it when the KHTML team continue to do magic. This solution fulfills both goals pretty nicely.

Making a full Qt port would still be a lot of work. Besides, porting KDE over to AtheOS is not an option. That would just lead to another UNIX with a GUI on top. Not something that I'm very interested in. The AtheOS kernel, filesystem, and GUI have many features that are not found in UNIX and that will play very important roles in the desktop environment. Porting a desktop environment from UNIX would not make AtheOS a new desktop OS. If I wanted to run KDE I would probably have been better off installing FreeBSD/KDE than to write my own kernel/GUI, then wrap the GUI in a foreign toolkit stripping away any special features from the native GUI, and then port KDE to this.

Take a look at the "What are file attributes?" FAQ at www.atheos.cx for one of the reasons why porting KDE or any other UNIX desktops to AtheOS is not something I consider an option.

I don't see why AtheOS is at any critical point or why it needs to gain momentum now. Since the very beginning I have been working on AtheOS on my own, not telling anybody and still the project didn't die. The only change so far was when the TCP/IP stack was finished enough to make it possible to run a web-server on AtheOS. Just for the fun of it I put up a web-site running on AtheOS and suddenly /. found it and a lot of people got a peek at AtheOS.

To me AtheOS is just a hobby that I have been spending a lot of time on. I don't work on AtheOS to "take over the world," or to make Linux obsolete, but simply because I find it interesting to write an OS. Spending 90% of my spare time arguing about technical issues on some kind of discussion forum is just not my piece of cake. I find it much more interesting to implement something than to discuss how it could have been implemented. And I don't know what you mean when you say that this has worked out fine before. So far I have not seen any open-source OS that I personally would consider a successful desktop OS. Take a look at the other non "mainstream" alternate OSes that are developed by a committee or group of developers and compare their progress to AtheOS. Then you can decide whether talking about implementing or implementing is the most efficient way to develop something :)

I am of course greatly welcoming application and device driver developers who target AtheOS though. I clearly don't have the time/resources to concentrate on either device drivers nor applications of any reasonable size at the same time as trying to develop the OS. After all the by far most common kernel-hacking on Linux is on device drivers and not the actual kernel anyway.

How does AtheOS handle Binary Compatibility?
by MeowMeow Jones

(As I'm sure you know) one of the problems with C++ is that modifying a class changes the binary structure of an object. This then breaks any programs that were dynamically linked against this. This problem has been addressed in several ways (CORBA, COM, statically linking in the code, or keeping 800 copies of MFC40.dll on your machine, etc, etc)

This seems (to me, at least) the biggest problem with writing an OS in C++. How does AtheOS deal with this problem?

KS: The fragile-base-class problem will of course always be a PITA when putting C++ code into DLLs but there are ways around it.

There are two problems with the static nature of C++ objects. One is that adding a new data member to a class moves all subsequent members in both the modified class and all classes inheriting from it. Since C++ resolves member offsets at compile time and not run time, this breaks all code that believes it knows where to find a member. The other problem is adding virtual members. Adding a virtual member expands the vtable and moves successive table entries down. Also the vtable offsets are resolved at compile time so this will again break all code that believe it knows where in the vtable to find one of the virtual functions.

The first problem is easy to solve. You just move all data members into a separate private class/structure and only keep a pointer to an instance of this in the API-visible class. Now it is possible to add as many new data members to this private class as needed without changing the layout of the class. This technique makes it impossible to have public data members but that has never been considered good design anyway.

The other problem is a bit more tricky. I know of no absolute solution to this but there is a workaround that give some extra head-room. By adding a few extra (unused) virtual members to each class it is possible to reserve some spare entries in the vtable for leaner times. If it later become necessary to add a new virtual member you just replace one of the unused members with a "real" member. Old applications will still have a reference to the old virtual member so when replacing the dummy I must also add an assembly function labeled with the mangled C++ name of the dummy member that simply returns immediately to avoid undefined references in old applications.

This is of course not a full solution since it is impossible to guess beforehand how many virtual members a class will eventually going to need and sooner or later all the extra-slots are gone and you are left high and dry.

When this happen the only solution (short of declaring the project as finished) is to give the library a new version number. The version number is encoded into the name of the DLL so all old applications will continue to use the old library while new applications will use the new version.

So far I have achieved most of the backward compatibility by making the protocol between the GUI server and the GUI toolkit library backward compatible and then renamed the toolkit library whenever I have had to break backward compatibility in the library. In V0.3.5 however I started to reserve extra virtual members like described above and V0.3.7 will be the first version that achieves backward compatibility by stealing a reserved virtual. The View class in 0.3.7 has an extra virtual callback for mouse-wheel support and this was added without breaking the library.

There are compatibility issues with renaming the DLLs as well, like old applications won't take advantage of bugfixes unless the fixes are backported to the old libs, applications with plugins often can't load plugins linked against a different version of the system libs, and breaking the protocol between the GUI server and the GUI toolkit library will either require a protocol update for the old libraries or the old libraries and the apps that depend on them will become obsolete. Still the techniques described here should be able to give a reasonable degree of backward compatibility and a good overlap allowing people to recompile/redistribute old applications.

It might be worth mentioning that even the latest version of AtheOS is mostly backward compatible with the first released version. I recently unpacked the V0.1.1 archive and tried to run some of the GUI apps and most of them still worked. The most interesting detail here is that between 0.1.4 and 0.2.0 I rewrote the GUI to use floating point instead of integers to describe coordinates. To keep it backward compatible the toolkit library that V0.1.1 - V0.1.4 binaries are linked to are converting all coordinates to floating point before sending them to the GUI server and back to integers when receiving them again. So AtheOS has been backward compatible even across quite dramatic architectural changes.

Embedded devices?
by proxima

Have you ever considered promoting AtheOS as an OS for GUI-based embedded devices? The competition in that arena now is Windows CE, Palm OS, and Linux - but an OO based GUI built into the OS may be beneficial in terms of performance.

With Linux, a device developer has to get the core Linux kernel working and then build a GUI on top of it (XFree86 or a smaller X server). Palm OS doesn't have multitasking and isn't very scalable to powerful devices. Windows CE requires a royalty. AtheOS could provide a powerful operating system for embedded devices for free.

KS: I have no such plans. So far I have no problems filling my todo list with tasks for the desktop version :)

Design an OS with C++
by JWhitlock

According to Bjarne Stroustrup, the core application domain for C++ is systems programming. Having created an OS in C++, what would you say are C++ strengths and weaknesses for your needs? Has the OS evolved along with the evolving standard (the STL, templates, the new type casts, etc.), or have you stuck with the C++ that was around when you started? What features do you depend on, and which do you avoid like the plague? And, of course, if you did it today, would you use another language or make different language choices?

KS: First I might mention that not everything in AtheOS is written in C++. When I first started working on AtheOS C++ was just a post increment to me. Both the kernel and the GUI was written in C. A GUI is pretty much object oriented by definition and almost all GUI toolkits are object oriented in some way. And so was the first AtheOS GUI. It had an object model with objects, inheritance, and virtual members. Writing object oriented code in a function oriented language is of course like shooting yourself in the foot but I didn't know any other way. When I later learned C++ I realized this and rewrote the GUI in C++ and was finally able to 'concentrate on the functionality rather than on how to twist an object oriented design into a function oriented language. The kernel however is much more function oriented so I have not seen any reason to rewrite it in C++. I have often considered to compile it with a C++ compiler to be able to take advantage of some of the "advanced C" features in C++ but so far I have not taken that step. C++ is a bit too implicit to make it comfortable to use in the kernel.

I like C++ for several reasons. It is well supported, integrates easily with C and has a nice balance between highlevelness and efficiency. I sometimes miss the more dynamic structure of higher-level languages but I'm not sure if I would be willing to pay the performance price required to get those into C++.

As for following the evolution of C++ I think AtheOS is doing pretty well. There is nothing in the architecture that prevents me from using any of the C++ features. AtheOS make heavy use of STL. It also uses most other features, like exception handling, RTTI, multiple inheritance (and thus also the new type-casts), operator overloading, templates, etc etc. In short I use all the C++ features I need to get the job done. I would not have chosen another language today. The first choice (C) was a very bad one (for the highlevel stuff) but I'm quite pleased with the current one.

Are you happy?
by An Anonymous Coward

... about not having some bearded weirdo running after you, crying: 'It's GNU/AtheOS, it's GNU/AtheOS!'?

KS: Well, I'm not sure if that is what makes me happy but I believe having some bearded weirdo running after me crying 'It's GNU/AtheOS, it's GNU/AtheOS!' would make me sad :)

CD-Rom support
by timothy

Kurt:

I much prefer to install software (at least anything over several megs) with a CD than over the net, and there are a lot of old documents that I have converted to CD for storage. I wouldn't want to buy a machine without a CD-ROM drive :)

Is bootable (or other) CD-ROM support planned? Perhaps many people would be able to sample AtheOS easier if they could (for instance) order a CD from Cheapbytes and install it locally, pass to a friend etc. Considering the progress on the other aspects of the system, how important do you think this is, or are there technical difficulties (other than time) in getting CD-ROM support to work?

KS: There are some technical issues with a bootable AtheOS CD but nothing that would be a real show stopper. The issue I had in mind is the fact that the AtheOS filesystem have much better support for user defined metadata than traditional filesystems and while the current version of AtheOS don't make any use of this it will be very crucial in a not-too-distant future. This should not be a real problem though. It only means that the boot-CD must contain a native-AtheOS file system rather than a ISO filesystem.

The real problem is lack of drivers that can support a CD-ROM. Personally I don't miss the CD-ROM very much so the driver is not very high on my personal priority list.

I know several developers have been poking around on a IDE driver that Jesper Hansen originally wrote to add support for ATAPI. So far I have not seen any results but I assume that sooner or later someone will come up with at least an IDE driver that can handle a CD-ROM.

AFAIK there is nothing in the kernel that would prevent adding support for any kind of CD-ROM with a regular loadable device driver.

Limiting the scope of AtheOS
by brennan73

It seems to me that it'll be extremely difficult for AtheOS (or any new OS, really) to do everything well; even Linux, which is pretty widely used, isn't a be-all, end-all solution yet (and maybe never will be, or never should be). So have you considered limiting the scope of AtheOS (possibly severely), and aiming at doing a relatively few things exceptionally well? Here I'm thinking of BeOS, which was usually promoted as a "multimedia OS." It seems to me that this might be a way for alternative OSes now and in the future to stake out some territory: do a few things very very effectively rather than trying to be all things to all people.

Of course, if you're doing this as a fun/interesting thing, you may not care as much about a niche or widespread acceptance. But, still.

KS: What few things can be done so exceptionally well that you don't need anything else to make a useful desktop OS? First I might mention that the main motivation behind AtheOS is my interest in OS programming. I have no "strategic plan" on how to lure people to AtheOS. To me the most important thing when it comes to AtheOS is that I work with things that interest me. I'm very interested in making a user-friendly, consistent desktop OS that is easy to configure and where the command-line is only something you use if you are familiar with UNIX and like to do certain things there. Not something you must deal with in your everyday use of the OS to maintain cryptic text-file based configurations. To achieve this I believe it is necesarry to have a quite broad feature set.

PPC?
by mcc

Some minor questions:

Do you consider it likely that at some point in the near future AtheOS will develop a PPC port?

I realize that the AtheOS developers are very busy with the hard work they are doing and that there is no good reason for them to expend effort on a PPC port. However i was wondering if you think that there is enough interest among extant developers familiar with the ppc/chrp/macintosh platform that someone might feel like cobbling together a port.

That being said, I was checking and trying to figure out: does AtheOS have some kind of flexible arbitrary-server auto-upgrade "package"-style system along the lines of the debian apt-get? if not, are there plans to implement one, or perhaps port apt-get and dselect to AtheOS?

KS: I have no interest in such a port at this stage. There is still a lot to do even without trying to support multiple platforms so I don't feel like using any energy on getting AtheOS to run on non-x86 machines anytime soon. Almost everything in AtheOS is written in portable C/C++ and there is nothing in the design that binds AtheOS to the x86, so there is a fair chance that you will see AtheOS on other platforms some time in the future but don't hold your breath. The babes won't like your new face color. This is covered a bit in the FAQ BTW.

AtheOS doesn't have a package manager. Some kind of application installer would be nice but I'm not sure if a regular package manager from Linux would be appropriate. In UNIX all the files from all the packages are blended together in one totally unmaintainable (by humans) soup of files. AtheOS is a desktop OS not UNIX so there is no reason why things should be handled this way under AtheOS. I have built all the CLI packages so each goes into a separate directories to make them a bit more manageable. Native applications will mostly be handled by the desktop manager and there is/will be features in AtheOS that can aid applications in locating their own directory (based on location of the executable) so it will not matter where on the HD an application is installed as long as the desktop manager knows where the executable is.

AtheOS and GPL?
by Midnight Ryder

Greetings ... Another poster mentioned the idea that you were considering moving AtheOS to a different license. Is that the case?

Secondly, if you are considering putting it under a different license, why? And, why did you select GPL licensing for AtheOS as opposed to a number of different licensing choices out there? (Regardless of if you are or aren't moving AtheOS from a GPL license.)

KS: I will probably change the license of the kernel and possibly the application server to LGPL to make sure the AtheOS license don't "leak" into third-party device drivers. I don't want the OS to dictate what license people might choose for their software.

The reason I chose GPL in the first place is more of a coincidence than anything else. I'm no lawyer and the GPL seemed like a decent choice. I must admit that I have grown very tired of all the fanatic GPL advocates screaming loud whenever they see something non-GPL though and if I ever go away from GPL altogether (to for example the BSD license) it would most likely be in protest against the attitude of the GPL advocates.

Now what?
by baptiste

My question: Sure you did this for fun and it is a beautiful OS. But as it gains attention and user interest, do you have a target audience in mind? Who do you think should use AtheOS -- who will derive the most benefit?

KS: The next step is to tie most of the kernel/GUI functionality into a desktop environment that takes better advantage of things like file attributes, mime-types, node-monitoring, the AtheOS messaging system, drag-and-drop, etc etc. Right now AtheOS looks more like a regular UNIX than anything else since few of the AtheOS specific features are really used. This will be a important step to define AtheOS as a desktop OS and not just a UNIX with a GUI.

Still for the forseeable future I guess the target audience will be application and device-driver developers. It doesn't make much sense for anybody else to install the OS before a decent application and HW support base are in place.

Windows apps?
by JohnTheFisherman

I know a lot of people hate Windows here, but it certainly has the lion's share of apps. Can/will/do you plan to add a windows emulation layer, or some fairly painless way of running Windows apps? Same for X/GTK/etc.

KS: I have no plans for a "windows compatibility layer" of any kind. The sheer amount of work this would require is enough to put it down. Beside I work on AtheOS for the fun and trying to emulate something as gross as Win32 and then trying to keep up with newer versions is not really something I consider fun.

As for X11, things are a bit different. It would be nice to have a X11 server for AtheOS that integrated X11 apps as nicely into the native desktop as possible to be able to run remote X11 applications from UNIX machines. This works quite nicely with several X11 server under Windows and I don't see why it shouldn't work for AtheOS. I stress that I consider this a good idea because it would make it possible to run remote UNIX apps on the AtheOS desktop. Not because I want to port GTK or any other toolkits to AtheOS. Having multiple toolkits will just cause the same compatibility and interoperability problems you find on Linux.

Another take on Windows apps
by n3m6

Why not include a DirectX emulation? It would be easier on his OS since its not tied to X and input devices are not a separately controlled ... if he could do that could this be the next gaming platform? Now that would be serious competition ...

KS: There isn't much point in DirectX emulation without the rest of the Windows API's since none of the games would run anyway.

I believe it would be much better to go for an open standard like OpenGL than to try to reverse-engineer a closed standard like DirectX in order to emulate it.