Submitted by The proposed design for Voyager, which aims to become an OS/2 replacement, is now available. “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 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.” Read the Voyager FAQ to understand what it actually is and aims to become.
Revive the WPS
!
We’ll see in two or three years whether this project has produced enough code. That’s all there is to say about this. BTW: It’s ok to say that everything else is rubbish because it’s the reason why I try to do something new. Perfectly ok
I like this one best:
“Why not X?
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. ”
I still haven’t quite understood it – hey, I have: We’re going to invent everything for the 2nd time.
I think he made it perfectly clear: “And, we don’t like X. Period.”
My guess would be that they don’t like it. But I don’t know…there might be something hidden in that statement.
Somewhere else in the FAQ, there’s something about preferences – you know, like it’s okay for people to prefer different things. Whoa, prefer seems like a root word for preference.
…however, let’s look at this objectively: This is not the first time that people have ‘reinvented x’. There have been other projects that have taken this stance: Berlin/Fresco. Maybe not to the same breadth or depth, but they certainly aren’t the first. Even X itself is now a split: Xfree86 and X.org. Of course this paragraph may not have been the proper aim at addressing your ‘invent everything for the 2nd time’ statement.
But the statement is rather cliche these days, especially here on OSNews. Looking at what you said the wrong way could easily spawn the argument that “why are there so many OS projects when there is Linux, FreeBSD, MacOS – they’re all reinventing everything for the nth time.”
If they don’t like and they want to do something else, than by all means. I mean after all, that’s gotta be the 50,000th sometime someone said they’re reinventing something.
But, I digress.
“…however, let’s look at this objectively: This is not the first time that people have ‘reinvented x’.”
They are not going for a reinvention of X, they’re going for a free reimplementation of WPS/PMShell, using existing technologies like Cairo.
X and WPS/PMShell are two very different animals.
Not everyone like X and that’s understandable. The core X protocol is hard to understand (too hard for what it is does). Xlib too. And this thing doesn’t even provide basic widgets that would probably make things faster. Anyway, Xlib is out of the race now with XCB. But the problem is that XCB is barely documented. I had to reread alot about core X protocol and Xlib to understand it. And finally, there’re all the extensions…making things even more annoying.
X is outdated. And unless you want to keep compatibility with X applications, you better leave it alone. Anyway, for what it does it’s pretty useless. Just use their video card drivers from the DRI project and start your own thing. Or use DirectFB. Or maybe OpenGL directly…
But there’s still a way to to take advantage of X. It’s not all that bad. One could make a GUI on top of X with only the root window. It would use it X for drawing operations and user input only. Everything else would be handled by such system…like the windowing logic, etc. The great thing about that is that you could run X applications…making the transition easier…
My $0,02 =)
XCB doesn’t really need to be documented. It’s just a t hin wrapper over the X protocol, which is itself quite well documented.
As for being outdated — I don’t see what’s so outdated about the X protocol. It creates graphics contexts, windows, handles input, etc. There is just not a lot of new things to do in these areas. I mean, no matter how fancy your OpenGL-based windowing system is, you’re still going to need to create windows, graphics contexts, handle mouse events, and is there a huge incentive to do these things in a fundementally different way?
There are legitimate reasons to avoid X, however. It’s a big piece of code, and if you don’t want to use the core X or RENDER to do drawing (you don’t), then you’re going to have to do some surgery, which won’t be easy. Of course, using DRI independently of X will be a lot of work too, so you’re probably not saving much.
X is one of the greatest things ever. The arguments that I hear everythime there is an X flame are the same.
1) X has no standard widget kit. That is pretty normal as it is not the point of the project. There are NO graphical systems (including the MacOS one and the Windows one) that also provide widget sets. They are another issue. Actually, you never work with the graphical system, but with the widget set when you program. The separation is normal, and it allows GTK apps (for example), to run on Windows natively (without the need for X11).
2) Extensions are anoying? Modularity is something that makes any software great. I doubt that you need desktop compozitioning on a Cell phone, or changing the resolution on a POS. Having extensions makes the X11 framework modular, and it helps aplications when they need to query the capabilities of the host.
The following paragraphs 2 are the ones that surprised me the most. Use only the Root Window? One of the advantages of X is the fact that you can pipe different individual applications through a network connection. What would be the difference between X and Remote Desktop if I could only have the whole desktop on a remote computer, when I need only one small app.
A few weeks ago I visited a monitoring station for the national power grid. They had a huge display (roughly 30ft wide, 5 ft tall) that would show in different windows the logical map of the system, graphs of the frequency and other stuff. It was because of X11 that they could have all those applications that rand on different UNIX servers, on a central display.
I, as an administrator, have on my desktop different monitoring applications that show the status of a few, but important servers. The applications are actually running on those servers and only the display is found on my workstation.
Not everybody is dependant, nor want the capabilities to export a display.
OS/2 is not capable at this, at this minute – which means there’s no culture that demands it.
So what…is this going to be OS/3 or OS/2 v.5 or something???
Maybe… OSX?
While I applaud the effort, why not do something sooner?
IBM has EOLed OS/2 a while ago, and we all knew there was no commercial development for a while. So, you’re trying to recreate OS/2 (you already have a 10 year handicap), and then factor in the additional years since the EOL annoucement…it will take them a while to get up to speed and produce something that is extensible and ready for the future…
Maybe they’ve looked at the ReactOS project and/or the resurrection of Atheos (through Syllable) and only now thought “Hey! We could do that!”
VMS is older than OS/2, and there’s a few opensource versions of VMS out there in use, so I don’t see a problem of adding OS/2 to the mix. From what I understand, it seems that they’re taking the MacOSX on BSD and Win32 on Linux (aka WINE) approach to getting OS/2 to run on Linux, so it should take a lot faster time to operate since they won’t have to redo the low level and they won’t have to create special Voyager device drivers or Voyager Graphics drivers (since it’ll be built on X.org’s low level device framework).
I don’t know if it’ll pan out, but if it does, it’ll provide a smoother migration path for OS/2 Warp users to move to Linux (a good thing), Linux compatibility through exposing low level functions and through adding an optional web server a la MacOSX (also a good thing), and move some of OS/2’s advanced ideas that have faded from memory into the forefront (also a good thing), and provide Windows users another open source alternative to Windows that’s closer to Windows in feel that KDE or GNOME can be (also a good thing).
So even though I’ll likely never use Voyager, I’d welcome it.
Edited 2006-10-15 20:21
Very interesting….
If there are any Voyager devs reading this, you may want to check out osfree (http://www.osfree.org).
That’s an existing project to do an open-source OS/2 clone. However, they’re making very slow progress, so I was thinking – maybe the devs there might be interested in helping you? Maybe, maybe not – anyway, just thought I’d mention that ….
Good luck and very best wishes to the Voyager devs!
should help osFree. Its idea for L4 uKernel is interesting and they need more hands. Otherwise they will be delayed until they become irrelevant.
As the author of the current The Design of Voyager document I would like to comment a few things.
First, we do not want to rewrite OS/2. Everyone that would at least read the first few chapters in the book would get that, so before you post BS please read more than just a few FAQ entries.
Second, we do not want to replace Xorg. We plan to get rid of Xlib in mid-term but we also clearly write that this is not the plan right now because we have another focus first. I hope that we get there one day but we can release Voyager based on a X11 server as well. Note that we will most probably use the Xorg OpenGL backend in any case so we will not invent yet another backend (like Fresco).
Third, there is no plan to rewrite the OS/2 kernel or invent yet another new kernel. I hope to find some time soon to write some more details about the kernel in the according chapter. Voyager will work on about every POSIX compatible kernel and maybe one day we will ship some kind of a distribution with our favourite kernel. But that’s far away…