Slashdot Mirror

Eugenia writes: "Over a month ago it was reported that a developer had forked the Athe(na) operating system and ported its GUI on top of Linux, without the use of XFree86. This combined OS, called Cosmoe, would support Linux, AtheOS, BeOS and even Macintosh's Carbon APIs (without the use of GNUStep - his port of Carbon is wrapped around the Be API). OSNews today features an interview with the architect of the combined OS, Bill Hayden, where a lot of things are explained about his plans for Cosmoe."

MAIC-32 writes: "OSNews features a very informative and detailed review of AtheOS, the promising 32-bit GPL Operating System. The article describes the installation process, the GUI (screenshots included), usage, internal design, developement and much more."

OSBlue writes: "After Palm announced the buyout of Be, Inc.'s intellectual property & Technology and after some consequent indications from several key people that Palm has no interest at Be's products and especially in BeOS, a number of the BeOS believers tried to find a new home. Some found comfort in AtheOS, others joined BeUnited's effort to license the BeOS source code, while some developers formed efforts like BlueOS and OpenBeOS. OpenBeOS consists from a number of BeOS developers who are trying to recreate the BeOS Kits in a form of a new, complete and open source Operating System that has source and if possible binary compatibility with BeOS 5. One of the most important people in this effort, Michael Phipps, is interviewed by OSNews.

Jarito writes: "Seems Kurt has found time to release another version of AtheOS. Changes include a slew of bug/speed fixes for ABrowse, optimization of the TCP/IP stack, a new system for handling POSIX packages, mouse-wheel support, a regular expression searching class and many more. Stop on by www.atheos.cx and check it out." Here's the changelog since 0.3.6 -- AtheOS remains astoundingly slick-looking for a (mostly) one-man project, if you missed our interview with Kurt Skauen, it's worth reading if AtheOS interests you.

Jarito writes: "Seems Kurt has found time to release another version of AtheOS. Changes include a slew of bug/speed fixes for ABrowse, optimization of the TCP/IP stack, a new system for handling POSIX packages, mouse-wheel support, a regular expression searching class and many more. Stop on by www.atheos.cx and check it out." Here's the changelog since 0.3.6 -- AtheOS remains astoundingly slick-looking for a (mostly) one-man project, if you missed our interview with Kurt Skauen, it's worth reading if AtheOS interests you.

Eugenia writes: "So, you think that BeOS or AtheOS are niche Operating Systems? Well, you haven't seen anything yet. OSNews provides a list and short description of the most active and most promising Operating Systems written by individuals or small teams just for the fun of it or because they have a dream of how the perfect OS should be (is there such a thing though?). Some of them, like SkyOS for example, are even quite far down the line in terms of usability and advancements."

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.

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.

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.

Developer Kurt Skauen, programming for fun, ended up answering the frequent cries to write a graphical Free OS not tied to the X Window system by doing just that. His AtheOS has been mentioned here a few times before -- it's a Free (as in GPL) Operating System for Intel-and-compatible CPUs with an integrated GUI, a tendency toward POSIX, and more than a hint of BeOS. There are quite a few sites with more information about AtheOS, but you may have trouble just getting past the beautiful screenshots and nearly as beautiful AtheOS FAQ. (There are also ASCII parrots.) Ask Kurt about the past, present, and future of AtheOS here (ask as many questions as you'd like, but please only one per post) and we'll forward the best ones to Kurt for his answers.

Developer Kurt Skauen, programming for fun, ended up answering the frequent cries to write a graphical Free OS not tied to the X Window system by doing just that. His AtheOS has been mentioned here a few times before -- it's a Free (as in GPL) Operating System for Intel-and-compatible CPUs with an integrated GUI, a tendency toward POSIX, and more than a hint of BeOS. There are quite a few sites with more information about AtheOS, but you may have trouble just getting past the beautiful screenshots and nearly as beautiful AtheOS FAQ. (There are also ASCII parrots.) Ask Kurt about the past, present, and future of AtheOS here (ask as many questions as you'd like, but please only one per post) and we'll forward the best ones to Kurt for his answers.

Developer Kurt Skauen, programming for fun, ended up answering the frequent cries to write a graphical Free OS not tied to the X Window system by doing just that. His AtheOS has been mentioned here a few times before -- it's a Free (as in GPL) Operating System for Intel-and-compatible CPUs with an integrated GUI, a tendency toward POSIX, and more than a hint of BeOS. There are quite a few sites with more information about AtheOS, but you may have trouble just getting past the beautiful screenshots and nearly as beautiful AtheOS FAQ. (There are also ASCII parrots.) Ask Kurt about the past, present, and future of AtheOS here (ask as many questions as you'd like, but please only one per post) and we'll forward the best ones to Kurt for his answers.

Developer Kurt Skauen, programming for fun, ended up answering the frequent cries to write a graphical Free OS not tied to the X Window system by doing just that. His AtheOS has been mentioned here a few times before -- it's a Free (as in GPL) Operating System for Intel-and-compatible CPUs with an integrated GUI, a tendency toward POSIX, and more than a hint of BeOS. There are quite a few sites with more information about AtheOS, but you may have trouble just getting past the beautiful screenshots and nearly as beautiful AtheOS FAQ. (There are also ASCII parrots.) Ask Kurt about the past, present, and future of AtheOS here (ask as many questions as you'd like, but please only one per post) and we'll forward the best ones to Kurt for his answers.

Developer Kurt Skauen, programming for fun, ended up answering the frequent cries to write a graphical Free OS not tied to the X Window system by doing just that. His AtheOS has been mentioned here a few times before -- it's a Free (as in GPL) Operating System for Intel-and-compatible CPUs with an integrated GUI, a tendency toward POSIX, and more than a hint of BeOS. There are quite a few sites with more information about AtheOS, but you may have trouble just getting past the beautiful screenshots and nearly as beautiful AtheOS FAQ. (There are also ASCII parrots.) Ask Kurt about the past, present, and future of AtheOS here (ask as many questions as you'd like, but please only one per post) and we'll forward the best ones to Kurt for his answers.

JigSaw writes: "SDL, the open source answer to DirectX, is a well-known cross-platform multimedia library designed to provide fast access to the graphics framebuffer and audio device. Sam Lantiga, the maintainer and SDL project leader, announced today on the SDL mailing list, that he ported the library to Playstation2 and it will allow to write and run SDL games (open source or commercial, as SDL is LGPL) on the Linux port for the PS2. Great to see Linux to become the source for a whole bunch of free SDL games (some of them with commercial-level quality), easily recompiled for the PS2 and run them without having to spend $49 USD for each game. This release will be even more significant in the near future, as SONY is planning to release the broadband adapter add-on, which will enable small developers (and even companies) to release free or shareware games, downloadable in binary or source format (most SDL games are known to have small sizes) from the web, and hop, to your TV!"

JigSaw writes "AtheOS 0.3.5 has just been released. Lots of changes to the core of the OS, but the most important upgrade is the port of the Konqueror web browser (the author had to wrap around X/KDE/QT calls in order to port it). AtheOS is a modern OS, written from scratch using OOP and C++, it features a 64-bit journaled/attributed filesystem and (surprise) it doesn't use X, but rather its native GUI system (screenshots). Changelog is here, while you can download it here (only around 23 MB for the basic installation). There is already a number of posix software ports and third party native software available."

JigSaw writes "AtheOS 0.3.5 has just been released. Lots of changes to the core of the OS, but the most important upgrade is the port of the Konqueror web browser (the author had to wrap around X/KDE/QT calls in order to port it). AtheOS is a modern OS, written from scratch using OOP and C++, it features a 64-bit journaled/attributed filesystem and (surprise) it doesn't use X, but rather its native GUI system (screenshots). Changelog is here, while you can download it here (only around 23 MB for the basic installation). There is already a number of posix software ports and third party native software available."

JigSaw writes "AtheOS 0.3.5 has just been released. Lots of changes to the core of the OS, but the most important upgrade is the port of the Konqueror web browser (the author had to wrap around X/KDE/QT calls in order to port it). AtheOS is a modern OS, written from scratch using OOP and C++, it features a 64-bit journaled/attributed filesystem and (surprise) it doesn't use X, but rather its native GUI system (screenshots). Changelog is here, while you can download it here (only around 23 MB for the basic installation). There is already a number of posix software ports and third party native software available."

JigSaw writes "AtheOS 0.3.5 has just been released. Lots of changes to the core of the OS, but the most important upgrade is the port of the Konqueror web browser (the author had to wrap around X/KDE/QT calls in order to port it). AtheOS is a modern OS, written from scratch using OOP and C++, it features a 64-bit journaled/attributed filesystem and (surprise) it doesn't use X, but rather its native GUI system (screenshots). Changelog is here, while you can download it here (only around 23 MB for the basic installation). There is already a number of posix software ports and third party native software available."

JigSaw writes "AtheOS 0.3.5 has just been released. Lots of changes to the core of the OS, but the most important upgrade is the port of the Konqueror web browser (the author had to wrap around X/KDE/QT calls in order to port it). AtheOS is a modern OS, written from scratch using OOP and C++, it features a 64-bit journaled/attributed filesystem and (surprise) it doesn't use X, but rather its native GUI system (screenshots). Changelog is here, while you can download it here (only around 23 MB for the basic installation). There is already a number of posix software ports and third party native software available."

JigSaw writes "AtheOS 0.3.5 has just been released. Lots of changes to the core of the OS, but the most important upgrade is the port of the Konqueror web browser (the author had to wrap around X/KDE/QT calls in order to port it). AtheOS is a modern OS, written from scratch using OOP and C++, it features a 64-bit journaled/attributed filesystem and (surprise) it doesn't use X, but rather its native GUI system (screenshots). Changelog is here, while you can download it here (only around 23 MB for the basic installation). There is already a number of posix software ports and third party native software available."

JigSaw writes: "BeNews has a very interesting interview with Kurt Skauen, the AtheOS creator and almost its sole developer. In the interview, Kurt is discussing the design of his OS which features a (nearly) micro-kernel, memory protection, 'true' multitasking, real C++ OOP design from the ground-up and all the rest of these buzzwords. AtheOS uses its own GUI, it does not rely on X or KDE libs, so porting Konqueror to his OS was a bit of a challenge."

garethwi writes "A new OS has been released, called AtheOS. It has been designed from the ground up for Intel architecture, and already has a lot of software for it. The screenshots aren't too bad either. " Quite a lot of people have been submitting this over the last few days - what does everyone think about it?

garethwi writes "A new OS has been released, called AtheOS. It has been designed from the ground up for Intel architecture, and already has a lot of software for it. The screenshots aren't too bad either. " Quite a lot of people have been submitting this over the last few days - what does everyone think about it?

garethwi writes "A new OS has been released, called AtheOS. It has been designed from the ground up for Intel architecture, and already has a lot of software for it. The screenshots aren't too bad either. " Quite a lot of people have been submitting this over the last few days - what does everyone think about it?