[openbeos] Re: Hi from the PetrOS camp.
- From: Peter Tattam <peter@xxxxxxxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Fri, 9 Nov 2001 12:09:34 +1100 (EST)
On Thu, 8 Nov 2001, Ithamar R. Adema wrote:
>
>
> >I'm no kernel jockey, but I think you might be onto something. Would
> there
> >possibly be a way that to somehow work together on this one=3F We *are*
> open-
> >source, after all. Perhaps I just don't understand the situation. My
> $0.02.
> >
> >--DarkWyrm
> >
>
> My sentiments exactly. Could you elaborate on what you think would be
> your idea exactly=3F I mean, our code is for the grabs anyway, so there
> must be something you would like in return for investing time in
> creating a "BeOS-kernel-compatibility" layer into your OS. I guess you
> would like our support, i.e. help with creating that, and bugfixes if
> any problems arise in the "generic" layers of OpenBeOS=3F I can't see the
> hurt in that....
>
> Would the code for the network stack be open-sourced=3F I think that
> should be required for OpenBeOS..... We want all the code to be open-
> source for OpenBeOS, otherwise our whole =5Freason=5F for starting this is
> doomed....
>
> Please elaborate what it is you =5Fprecisely=5F are thinking/talking
> about.....
>
> Regards,
>
> Ithamar.
>
> PS: My opionion is basicly this: If it doesn't take away too much time
> of developing our OpenBeOS project, and gets us a really good network
> stack for free, why not=3F
>
Ok. I'll be clear from the start so there's no arguments later.
I'm prepared to open source the BeOS kernel driver and any userland stuff
related to BeOS only. The rest of our OS including the network stack would be
closed source. I'm uncertain about the ELF loader. If we developed it
exclusively and it was required for other closed source sections to our OS, I'd
keep the ELF loader closed.
As the networking in BeOS appears to be only a sockets layer (correct me if I'm
wrong) I see no need to redo that as a BeOS module, and in actual practice, it
would be better not to for system wide integration.
I feel a reasonable solution is to use as much of the native OS features as
possible, and networking is a native feature.
Also, you can be assured that because we are a Pascal camp, it's unproductive
for us to borrow C/C++ sources and rip them off. We're not in the business of
ripping off other people's code.
I am getting concerned about the whole closed/open source delineation. If
there is not enough consensus about it then maybe its best we wait on the
sidelines till your full project is done. The alternative for us is if we
believe that beos emulation is of such value commercially is that we do an
independent implementation privately as a closed source. I don't however
believe the market is sufficiently strong to sustain such investment. That's
why I'm looking at an open source solution that could blend with our current
closed source.
As far as licensing is concerned, we normally license the OS at a retail price
of US$50 (available online). However we could produce a reduced kernel
component for BeOS users at a lower cost than that. (i.e. you would ge the
kernel, drivers necessary to run BeOS, but none of the other apps or Win32
layer).
Also, perhaps the openbeos project need to be realistic about things. What is
the goal? To totally recreate a BeOS system down the last nut & bolt, or get a
working BeOS environment up as rapidly as possible? The two are not the same.
If you want the formaer, it will take a long time and if you want the latter,
you will need to make important decisions that will facilitate that end in the
best way. From the application perspective, all they need to see is a userland
layer that emulates the BeOS API. How it's done underneath is immaterial.
If you can make a clear delineation betweeen the userland stuff and the
kernelland stuff, with a well defined user/kernel ABI, it would make the
project much more suitable for cross OS implementation. You are unlikely to
lose anything because your native OS (NewOS) can support this ABI directly
also. It would be a win-win situation.
We are also developing our own GUI for Win32 and have done a fair amount of
work on it so far. The BeOS layer could either link into components we have
done already, or be an independent GUI implementation that only uses our
virtual flat frame buffer interface which is exported directly from the kernel.
We could stand to gain from having an alternative GUI implmentation from our
own. Doing a GUI is a major effort, and we've been encouraged time & again to
seek open source solutions if possible. This is one such exploration.
Peter
--
Peter R. Tattam peter@xxxxxxxxxxx
Managing Director, Trumpet Software International Pty Ltd
Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210
Other related posts:
