[openbeos] Re: my thoughts
- From: Erik Jakowatz <erik@xxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Wed, 22 Aug 2001 09:08:31 -0700
I think some of what you talk about here can be addressed by answering
your last question: the development environment for OpenBeOS is BeOS
R5.x. Combined with the determination that NewOS will be our kernel
foundation, it doesn't make a lot of sense to spend time and resources
on writing a wrapper for Linux. The server/kit teams will use and write
to the R5.x kernel until the NewOS-based kernel is ready; then we'll
drop it in. Doing a Linux wrapper (while possibly quite interesting,
technically) would just end up being a detour from our intended goal.
While the Berlin project is pretty dang cool in its own right, I'm not
convinced it really fits in architecturally with BeOS as it stands
(which *is* our target), and could require prohibitive amounts of
refactoring to do the job. I'm sure there are some great ideas we could
crib from them, though, so if you have some insights about how their
system works that can be applied, I'm certain everybody would love to
hear them.
e
John Kenneth Milli Grytten wrote:
>
> On 0, Zenja Solaja <solaja@xxxxxxxxxx> wrote:
> > Linux parts" framework and already adopted a course of action outlined in
> > Correct me if I'm wrong, but I believe we've already moved past the "grab
> > the resolution (someone post it on a web page, please). I'd hate to see us
>
> Ok, I will try to "correct" with two ideas:
>
> First, would it be possible to "define" the kernel functions, create a wrapper
> around the linux kernel and develop app_server on top of that, while those
> interested in kernel work could work on that?
> Of course, noone will agree on everything. But it's a real challenge
> to let everyone participate.. maybe defining the API's and protocols (as
> much as possible) could be a good start? I don't have any idea how difficult
> it would be to define the expected behaviour from the kernel (and the other
> "kits" for that sake), it just seems to me that having the header files isn't
> enough. I'm not rambling about creating a perfect object-oriented OS, but
> such a "BeOS kernel" wrapper could serve as a specification and be used for
> prototyping the rest of the OS (and sometimes effectively implemention some
> parts, just needing a recompile).
>
> Second, I got the impression that Be needed to rewrite the app_server anyway.
> There is a project http://www.berlin-consortium.org/
> who aims to create a powerful new windowing system... it would be great to
> have one windowing system supporting GUI programming through various languages
> (and not depending on complicated wrappers around C). Why limit the "BeOS
> Research OS" to just the app_server? The threading capabilities of BeOS (if
> not much else) interest many people. Of course people will decide on their
> own what they want to write. We should not give up working together, having
> something
> in common ought to be better than having nothing :-)
>
> Another thing, what would be the preferred development environment?
>
> -jk, running GNU/Debian and vmware, plex86 etc.. (hint hint)
>
> --
>
> John Kenneth
> 42
Other related posts:
