Latest revision as of 18:59, 8 December 2007

Voyager Frequently Asked Questions

Assembled by:

Adrian Gschwend, aka ktk
Cinc

Motivation

OS/2: Everything is an object [tm]
MacOS X: Not everything is an object
Gnome: We once tried objects
KDE: We claim there are objects
Windows: There is no object

General

What is Voyager?

Voyager is the codename for the idea of having a replacement OS/2, or rather of the OS/2 Workplace Shell (WPS) on top of modern technology. This idea is the result of thinking a lot about what we can do in the future as current OS/2 and eComStation users. As many information in the Internet, this FAQ does not resemble the most recent status of the project for various reasons described later. But we still try to give you an impression of what we try to do with this project.

Before you continue you should probably consult:

The Voyager page in this Wiki and...
The Voyager mailinglist at gmane.org

Note that our path is firmly set and long past the point of discussion. As a potential contributor, know from the onset, that acceptance of this path is a must. Take it or leave it, it's our choice and we have our reasons.

How is this related to OS/2 and eCS?

A lot and not much ;) Voyager is basically a re-implementation of a lot of ideas already implemented in the WPS, the Workplace Shell of OS/2, the multimedia subsystem (like IO procedures) and other areas which make OS/2 unique. The WPS has still unique concepts that are not implemented in any of the free and well-known desktops like Gnome or KDE. Our goal is to get the "WPS and OS/2 feeling" on top of new, (and existing), open source technologies, in a way that's more or less independent of the kernel used.

One of the main concerns of current OS/2 and eCS users is good backward compatibility. This is addressed below.

How is this related to MacOS X?

While explaining the idea of Voyager to people we often get the feedback, that this sounds a lot like MacOS X. Indeed there are concepts that are used in MacOS X as well.

The MacOS X Desktop does have a lot in common with the WPS. We're going to limit our talk to some of the ideas and concepts here. The reasons for the similarity are quite simple: Apple, IBM and HP had a company called Taligent in the 90s which worked on an object oriented OS. The project was canceled in 1995, but some of the conceptual ideas survived. Some of these made it into the MacOS X which has also been influenced by NeXT which also has some ideas in common with OS/2s WPS.
MacOS X provides a powerful 2D engine called Quartz Extreme, we think this is the way to go today and Voyager has planned something like this utilizing Cairo as the 2D engine.

Unfortunately Apple didn't push the object orientation far enough in MacOS X. Not everything is an object as with the WPS, thus things that should (in our opinion) simply work, do not. As an example try to drag & drop an Address Book entry to the trash can. The entry itself is not a normal desktop object and thus can't be dropped to the trashcan. Also Objective C used by Apple does have some nice features but the object model of OS/2 (SOM) is still much further in terms of binary compatibility for example.

Is Voyager yet another Linux distribution?

No! Voyager is more than just repackaged Linux stuff with a pretty desktop (in fact it is more likely BSD stuff...). We will kill some sacred cows of the *nix camp like X as the graphics foundation or so called choice. You won't have ten editors for your config files, you won't have several window managers but one, you won't have a dozen file systems to choose from but only one or two. You get the picture... Since there's no decision for the kernel yet the rumors Voyager would use the Linux kernel are just - rumors. Voyager won't require you do recompile your kernel every few weeks or hunt down package dependency when installing new apps by providing a standard set of base libs.

I heard Voyager uses the Linux kernel

Read the answer to the previous question! For your convenience I highlighted the sentence which may interest you.

I type this very slowly so every OS/2 zealot going berserk may understand it: There is no decision about which kernel to use, yet. There's no decision about using the Linux kernel, there's not even a discussion about using the Linux kernel. Whenever somebody is telling you Voyager is using the Linux kernel just ignore that.

Will netlabs.org stop providing software for OS/2 and eCS now?

Definitely not! We will continue to provide essential software for OS/2 the next years. Voyager is in our opinion a great option for the future but we know very well that it will take some time until you can use that as full replacement for what you use now.

The best choice you can do at the moment is to work with eComStation, version 2 of eCS will provide some essential enhancements, many of the ideas are planned for Voyager as well. So one could say that Voyager could become something like eComStation 3.0 once.

How can I support Voyager?

There are several possibilities:

We definitely need skilled developers. We have a wide range of tasks available, please consult the Voyager page to get an impression and join the mailing list if you can contribute in some form.
Motivate skilled coders to help on the project. We think that the idea is very tempting and unique and we already successfully motivated developers outside of the OS/2 and eCS community. This is essential for this project.
Buy eComStation. netlabs.org is working closely with SSI and Mensys to provide new software on eCS. Supporting eCS is thus an exellent way to also fund development of Voyager indirectly.
Buy netlabs.org sponsoring units in the Mensys shop, we get 100% of the amount you donate there!
Present Voyager at your local user group. We need to spread the word to motivate people to contribute in any form.
Help out with the documentation of Voyager

Technology

Will Voyager support my OS/2 and eCS applications?

That's a question we can't answer that easy at the moment. For sure it would be nice if we reach that state one day but that depends on quite a lot of things. There are several options:

use a virtual machine like VirtualBox to run OS/2 or eCS in there. Will definitely work but is not a soft migration
implement the OS/2 base API on an existing Kernel to provide API compatibility. This could even be extended to binary compatibility if we work hard on it.
- osFree has something in mind, see here as well.
- There is a project at Sourceforge which provides a base OS/2 API already on Linux, written by an IBM employee. This library is not complete yet but provides a base to work on
implement at least parts of GPI and PM on top of an existing 2D engine like Cairo for PM compatibility. This is a very big task and we are not sure if it is worth doing that but if a group of people volunteers to write that, get in contact with us on the Voyager mailing list. Note that such a project should definitely integrate well with our idea, otherwise it will not help at all.

Another possiblity might come up with the design of Voyager, at the moment the most likely Glitz backend will be Xorg OpenGL drivers, so we would get drivers from the HW-vendors. This opens a new interesting approach for backward compatibility, that would involve the following steps:

compile Xorg on OS/2 with Innotek LIBC
get the binary only drivers to work (should work somehow in theory)
compile Glitz using Xorg backend
recompile GTK2 & all libraries used with Innotek LIBC
write a GRADD driver that renders using OpenGL, which means it would render into the OpenGL driver of Xorg. Like this it should even be possible to have a windowed PM in Glitz.

The benefit would be that we would also get HW acceleration in the current OS/2 or eCS.

In short one can say that binary compatibility is technically possible up to a certain point at least. One can debate about if this is useful or not.

Why something new? There is Gnome, KDE...

If you think KDE, GNOME... fit your needs , that's fine, just move on because you have found a solution for your personal computing needs. The people involved with Voyager so far don't think desktops other than the WPS which are available today fit their needs. Different people, different preferences.

Or to quote Larry Wall: "There's More Than One Way to Do It".

Why not X?

Short answer

Voyager is a desktop OS. We don't see any need for opening a window on a machine located somewhere in China when your monitor is only 50cm away from you.

And, we don't like X. Period. And finally we are not the only ones realizing that.

Long answer

We talk about X in terms of Xlib here, a library which was designed about 20 years ago when networks were slow, terminals common and processors did all the GFX (rendering) work. Now we have fast networks, fast computers, some graphic cards cost more than the CPU and remote access can be done with modern protocols like RDP or NX.

Since Apple started introducing eye candies in MacOS X everyone wants fancy 3D effects on his desktop too, no matter how useless they actually are. So one needs to get direct access to the hardware in X too, a concept that got introduced in form of the Direct Rendering Interface (DRI) mainly for 3D games. New desktop extensions like Xgl or Aiglx are using such techniques as well to get direct access to the hardware, without messing around with Xlib.

The two most popular toolkits GTK and Qt started moving their rendering to new engines as well like Cairo or Arthur. Depending on the backend of those rendering engines they also bypass Xlib and thus don't need it anymore except for things like window and input handling. Our point of view is that it would make more sense to replace those parts (window & input handling and other missing stuff) by a window manager on top of those rendering engines like Cairo instead. There was a prototype of this idea presented at Developers Workshop 2006, the project is called Neptune. Note that we don't necessarily will do it like this, if something better comes up, we will save us the work for sure.

There are people working on alternatives for Xlib as we know it right now. One of them is XCB, a project at freedesktop.org. This project can solve some of the problems we have with Xlib nowadays but it doesn't kill it completely.

This project is too big, you will fail

Maybe. But honestly without trying you won't know...

Development

Under what license is Voyager released?

The source is dual licensed. It is covered by the CDDL and the LGPL.

Where can I download sourcecode?

The source can be found in a subversion tree on netlabs.org. Trac provides a web interface for browsing. Currently you find the following.

Documentation. (Seriously out of date because we changed quite a lot from the design point of view, sorry)
Netlabs Object Model.
Desktop.
Multimedia subsystem.

Information how to download the source will follow. Note that some repositories are not available to the public right now because we want to design the prototypes on our own.

Should I still work on OS/2 and eCS applications?

Sure! OS/2 and eCS will be around for a very long time and Voyager will need quite some time to be mature enough to be usable. But if you intend to support the Voyager approach any time you should try to code in a portable way. Instead of using the OS/2-API use a portable runtime instead e.g. GLib, NPL or APL. Consider using a cross platform toolkit for the UI like DynamicWindows, GTK, XUL. Use only standard WPS methods without PM-specific tricks.

If you don't like the Voyager approach anyway, why do you ask in the first place ;)?

Whats next with Voyager - where are we?

Ask the oracle :-)

We definitely can't give any assumptions about when we will be ready for a public release. One lesson we definitely learned in the past years with netlabs.org and other software projects is that release plans never work as announced :)

@@ Line 15: / Line 15: @@
 ==General==
 ===What is Voyager?===
-Voyager is the codename for the idea of having a replacement OS/2 on top of modern technology. This idea is the result of around 1.5 years of thinking a '''lot''' about what we can do in the future as current OS/2 and [http://www.ecomstation.com/ eComStation] users.
+Voyager is the codename for the idea of having a replacement OS/2, or rather of the OS/2 Workplace Shell (WPS) on top of modern technology. This idea is the result of thinking a '''lot''' about what we can do in the future as current OS/2 and [http://www.ecomstation.com/ eComStation] users.
-Note that it's absolutely impossible to convey what we plan to do in a few sentences. I made a speech on it at Warpstock Europe 2005 that, by itself, took 1.5 hours so you get the point :)
+As many information in the Internet, this FAQ does not resemble the most recent status of the project for various reasons described later. But we still try to give you an impression of what we try to do with this project.
 Before you continue you should probably consult:
-* My presentation at [http://warpstock.net/wse2005/presentations/presentations/ Warpstock Europe 2005]. Get the ALL06 PDF.
-* My presentation as DivX ([ftp://ftp.netlabs.org/pub/voyager/wse05_all06-1.avi part 1, current situation (360 MB)],[ftp://ftp.netlabs.org/pub/voyager/wse05_all06-2.avi part 2, outlook & Voyager (366 MB)])  or MP3 (available soon). Use WarpVision or VLC 0.8.4a to play (VLC 0.8.2 won't work).
 * The [[Voyager]] page in this Wiki and...
 * The [http://dir.gmane.org/gmane.org.netlabs.voyager.devel Voyager mailinglist] at gmane.org
@@ Line 27: / Line 25: @@
 Note that our path is firmly set and long past the point of discussion. As a potential contributor, know from the onset, that acceptance of this path is a must.  Take it or leave it, it's our choice and we have our reasons.
-===How is this releated to OS/2 and eCS?===
+===How is this related to OS/2 and eCS?===
-A lot and not much ;) Voyager is basically a re-implementation of a lot of ideas already implemented in the [http://en.wikipedia.org/wiki/Workplace_Shell WPS], the Workplace Shell of OS/2, the multimedia subsystem (like IO procedures) and other areas which make OS/2 unique. As mentioned in the ALL06 PDF, the WPS has still unique concepts that are not implemented in any of the free and well-known desktops like [http://www.gnome.org Gnome] or [http://www.kde.org KDE].
+A lot and not much ;) Voyager is basically a re-implementation of a lot of ideas already implemented in the [http://en.wikipedia.org/wiki/Workplace_Shell WPS], the Workplace Shell of OS/2, the multimedia subsystem (like IO procedures) and other areas which make OS/2 unique. The WPS has still unique concepts that are not implemented in any of the free and well-known desktops like [http://www.gnome.org Gnome] or [http://www.kde.org KDE].
 Our goal is to get the "WPS and OS/2 feeling" on top of new, (and existing), open source technologies, in a way that's more or less independent of the kernel used.
-One of the main concerns of current OS/2 and eCS users is good backward compatiblity. This is addressed [[Voyager_FAQ#Will_Voyager_support_my_OS.2F2_and_eCS_applications.3F | below]].
+One of the main concerns of current OS/2 and eCS users is good backward compatibility. This is addressed [[Voyager_FAQ#Will_Voyager_support_my_OS.2F2_and_eCS_applications.3F | below]].
 ===How is this related to MacOS X?===
-I talk a lot about the MacOS X in my presentation for various reasons:
+While explaining the idea of Voyager to people we often get the feedback, that this sounds a lot like MacOS X. Indeed there are concepts that are used in MacOS X as well.
-* The MacOS X Desktop does have a lot in common with the WPS. We're going to limit our talk to some of the ideas and concepts here. The reasons for the similarity are quite simple: Apple, IBM and HP had a company called [http://en.wikipedia.org/wiki/Taligent Taligent] in the 90s which worked on an object oriented OS. The project was cancelled in 1995, but some of the conceptual ideas survived. Some of these made it into the MacOS X which has also been influenced by [http://en.wikipedia.org/wiki/NeXT_Computer NeXT] which also has some ideas in common with OS/2s WPS.
+* The MacOS X Desktop does have a lot in common with the WPS. We're going to limit our talk to some of the ideas and concepts here. The reasons for the similarity are quite simple: Apple, IBM and HP had a company called [http://en.wikipedia.org/wiki/Taligent Taligent] in the 90s which worked on an object oriented OS. The project was canceled in 1995, but some of the conceptual ideas survived. Some of these made it into the MacOS X which has also been influenced by [http://en.wikipedia.org/wiki/NeXT_Computer NeXT] which also has some ideas in common with OS/2s WPS.
 * MacOS X provides a powerful 2D engine called [http://www.apple.com/macosx/features/quartzextreme/ Quartz Extreme], we think this is the way to go today and Voyager has planned something like this utilizing [http://www.cairographics.org Cairo] as the 2D engine.
-* MacOS X provides an X implementation for compatiblity with Unix applications. Netlabs.org will provide something similar with [http://everblue.netlabs.org/ Everblue].
+Unfortunately Apple didn't push the object orientation far enough in MacOS X. Not everything is an object as with the WPS, thus things that should (in our opinion) simply work, do not. As an example try to drag & drop an ''Address Book'' entry to the trash can. The entry itself is not a normal desktop object and thus can't be dropped to the trashcan. Also Objective C used by Apple does have some nice features but the object model of OS/2 (SOM) is still much further in terms of binary compatibility for example.
-* Apple has already solved quite a few problems that we have now with OS/2 and eCS, (no real multiuser system, no real security concept etc). If you want to know more about our plans to deal with this read the [http://developer.apple.com/documentation/Darwin/Kernel-date.html Kernel Programming Guide] at apple.com. It is always a good idea to learn from others as there's no point in re-inventing the wheel.
 ===Is Voyager yet another Linux distribution?===
-No! Voyager is more than just repackaged linux stuff with a pretty desktop (in fact it is more likely BSD stuff...). We will kill some sacred cows of the *nix camp like X as the graphics foundation or so called choice. You won't have ten editors for your config files, you won't have several window managers but one, you won't have a dozen file systems to choose from but only one or two. You get the picture... '''Since there's no decision for the kernel yet the rumours Voyager would use the linux kernel are just - rumours.'''
+No! Voyager is more than just repackaged Linux stuff with a pretty desktop (in fact it is more likely BSD stuff...). We will kill some sacred cows of the *nix camp like X as the graphics foundation or so called choice. You won't have ten editors for your config files, you won't have several window managers but one, you won't have a dozen file systems to choose from but only one or two. You get the picture... '''Since there's no decision for the kernel yet the rumors Voyager would use the Linux kernel are just - rumors.'''
 Voyager won't require you do recompile your kernel every few weeks or hunt down package dependency when installing new apps by providing a standard set of base libs.
@@ Line 47: / Line 44: @@
 Read the answer to the previous question! For your convenience I highlighted the sentence which may interest you.
-I type this very slowly so every OS/2 zealot going berzerk may understand it: There is no decision about which kernel to use, yet. There's no decision about using the Linux kernel, there's not even a discussion about using the Linux kernel. Whenever somebody is telling you Voyager is using the Linux kernel just ignore that.
+I type this very slowly so every OS/2 zealot going berserk may understand it: There is no decision about which kernel to use, yet. There's no decision about using the Linux kernel, there's not even a discussion about using the Linux kernel. Whenever somebody is telling you Voyager is using the Linux kernel just ignore that.
 ===Will netlabs.org stop providing software for OS/2 and eCS now?===
@@ Line 55: / Line 52: @@
 ===How can I support Voyager?===
 There are several possibilities:
-* We definitely need skilled developers. We have a wide range of tasks available, please consult the [[Voyager]] page to get an impression and join the [http://dir.gmane.org/gmane.org.netlabs.voyager.devel mailinglist] if you can contribute in some form.
+* We definitely need skilled developers. We have a wide range of tasks available, please consult the [[Voyager]] page to get an impression and join the [http://dir.gmane.org/gmane.org.netlabs.voyager.devel mailing list] if you can contribute in some form.
 * Motivate skilled coders to help on the project. We think that the idea is very tempting and unique and we already successfully motivated developers outside of the OS/2 and eCS community. This is essential for this project.
 * Buy [http://www.ecomstation.com eComStation]. netlabs.org is working closely with SSI and Mensys to provide new software on eCS. Supporting eCS is thus an exellent way to also fund development of Voyager indirectly.
 * Buy netlabs.org sponsoring units in the [http://shop.mensys.nl/catalogue/mns_NETLABS.html Mensys] shop, we get 100% of the amount you donate there!
-* Present Voyager at your local usergroup. We need to spread the word to motivate people to contribute in any form. For sure you are welcome to show the DivX of the presentation as well.
+* Present Voyager at your local user group. We need to spread the word to motivate people to contribute in any form.
 * Help out with the [[Voyager_Support | documentation]] of Voyager
@@ Line 65: / Line 62: @@
 ===Will Voyager support my OS/2 and eCS applications?===
 That's a question we can't answer that easy at the moment. For sure it would be nice if we reach that state one day but that depends on quite a lot of things. There are several options:
-* use a virtual machine like [http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ XEN] to run OS/2 or eCS in there. Will definitely work but is not a soft migration
+* use a virtual machine like [http://www.virtualbox.org/ VirtualBox] to run OS/2 or eCS in there. Will definitely work but is not a soft migration
 * implement the OS/2 base API on an existing Kernel to provide API compatibility. This could even be extended to binary compatibility if we work hard on it.
 ** [http://www.osfree.org osFree] has something in mind, see [http://www.falvotech.com/projects/os3.php here] as well.
 ** There is a project at [http://os2linux.sourceforge.net/  Sourceforge] which provides a base OS/2 API already on Linux, written by an IBM employee. This library is not complete yet but provides a base to work on
-* implement at least parts of GPI and PM on top of an existing 2D engine like Cairo for PM compatibility. This is a very big task and we are not sure if it is worth doing that but if a group of people volunteers to write that, get in contact with us on the Voyager mailinglist. Note that such a project should definitely integrate well with our idea, otherwise it will not help at all.
+* implement at least parts of GPI and PM on top of an existing 2D engine like Cairo for PM compatibility. This is a very big task and we are not sure if it is worth doing that but if a group of people volunteers to write that, get in contact with us on the Voyager mailing list. Note that such a project should definitely integrate well with our idea, otherwise it will not help at all.
-Another possiblity might come up with the design of Voyager, at the moment the most likely Glitz backend will be xorg OpenGL drivers, so we would get drivers from the HW-vendors. This opens a new interesting approach for backward compatibility, that would involve the following steps:
+Another possiblity might come up with the design of Voyager, at the moment the most likely Glitz backend will be Xorg OpenGL drivers, so we would get drivers from the HW-vendors. This opens a new interesting approach for backward compatibility, that would involve the following steps:
 * compile Xorg on OS/2 with Innotek LIBC
 * get the binary only drivers to work (should work somehow in theory)
-* compile Glitz using xorg backend
+* compile Glitz using Xorg backend
 * recompile GTK2 & all libraries used with Innotek LIBC
 * write a GRADD driver that renders using OpenGL, which means it would render into the OpenGL driver of Xorg. Like this it should even be possible to have a windowed PM in Glitz.
@@ Line 93: / Line 90: @@
 Voyager is a desktop OS. We don't see any need for opening a window on a machine located somewhere in China when your monitor is only 50cm away from you.
-And, we don't like X. Period.
+And, we don't like X. Period. And finally we are not the only ones [http://blog.netlabs.org/?p=35 realizing that].
 ====Long answer====
@@ Line 100: / Line 97: @@
 Since Apple started introducing eye candies in MacOS X everyone wants fancy 3D effects on his desktop too, no matter how useless they actually are. So one needs to get direct access to the hardware in X too, a concept that got introduced in form of the [http://en.wikipedia.org/wiki/Direct_Rendering_Infrastructure Direct Rendering Interface (DRI)] mainly for 3D games. New desktop extensions like [http://en.wikipedia.org/wiki/Xgl Xgl] or [http://en.wikipedia.org/wiki/Aiglx Aiglx] are using such techniques as well to get direct access to the hardware, without messing around with Xlib.
-The two most popular toolkits GTK and Qt started moving their rendering to new engines as well like [http://en.wikipedia.org/wiki/Cairo_%28graphics%29 Cairo] or [http://doc.trolltech.com/4.0/qt4-arthur.html Arthur]. Depending on the backend of those rendering engines they also bypass Xlib and thus don't need it anymore except for things like window and input handling. Our point of view is that it would make more sense to replace those parts (window & input handling and other missing stuff) by a window manager on top of those rendering engines like Cairo instead. There was a prototype of this idea presented at Developers Workshop 2006, the project is called [ftp://ftp.netlabs.org/pub/events/DWS2006/presentations/AWMBasedOnCairo-dws06.pdf Neptune].
+The two most popular toolkits GTK and Qt started moving their rendering to new engines as well like [http://en.wikipedia.org/wiki/Cairo_%28graphics%29 Cairo] or [http://doc.trolltech.com/4.0/qt4-arthur.html Arthur]. Depending on the backend of those rendering engines they also bypass Xlib and thus don't need it anymore except for things like window and input handling. Our point of view is that it would make more sense to replace those parts (window & input handling and other missing stuff) by a window manager on top of those rendering engines like Cairo instead. There was a prototype of this idea presented at Developers Workshop 2006, the project is called [ftp://ftp.netlabs.org/pub/events/DWS2006/presentations/AWMBasedOnCairo-dws06.pdf Neptune]. Note that we don't necessarily will do it like this, if something better comes up, we will save us the work for sure.
 There are people working on alternatives for Xlib as we know it right now. One of them is [http://en.wikipedia.org/wiki/XCB XCB], a project at freedesktop.org. This project can solve some of the problems we have with Xlib nowadays but it doesn't kill it completely.
@@ Line 116: / Line 113: @@
 a web interface for browsing. Currently you find the following.
-* [http://svn.netlabs.org/v_doc Documentation].
+* [http://svn.netlabs.org/v_doc Documentation]. (Seriously out of date because we changed quite a lot from the design point of view, sorry)
 * [http://svn.netlabs.org/v_nom Netlabs Object Model].
 * [http://svn.netlabs.org/v_desktop Desktop].
 * [http://svn.netlabs.org/v_triton Multimedia subsystem].
-Information how to download the source will follow.
+Information how to download the source will follow. Note that some repositories are not available to the public right now because we want to design the prototypes on our own.
 ===Should I still work on OS/2 and eCS applications?===
@@ Line 134: / Line 131: @@
 We definitely can't give any assumptions about when we will be ready for a public release. One lesson we definitely learned in the past years with netlabs.org and other software projects is that release plans never work as announced :)
-There are some very rough plans at the moment:
-* we would like to present some first prototypes of various components at Developer Workshop 2006 in Biel/Bienne. Those components are more or less technology studies for interested developers.
-* till Warpstock Europe 2006 we hope to present a basic development setup which makes it easy for other developers to join the project on various platforms. This means you should be able to contribute on OS/2 & eCS, Linux, BSD and probably even MacOS X.