FreeLists / openbeos / [openbeos] Re: Open BeOS

[Michael Phipps <mphipps1@xxxxxxxxxxxxxxxx>]

On 2003-10-19 at 17:38:08 [-0400], J. Grant wrote:
> Hello,
> 
> > GNU is basically a collection of utilities that were once part of
> > closed-source Unix. The GNU folks took those utilities and made their own
> > open-source versions.
> 
> Although SCO may agree with you on this one; I have to disagree.  Even
> the meaning of GNU clearly indicates that it is not Unix, or even based
> on any Unix code or philosophy.  Command names and typically arguments
> were used to name the GNU software they wrote (command compatibility is
> key, the same reason DOS used same commands as CPM), I am sure everyone
> knows that GNU is not "a collection of utilities that were once part of
> closed-source Unix".

His second sentence makes his intent pretty clear. He isn't saying that GNU 
took the code. I don't think that anyone is saying that (even SCO - they are 
talking about Linux kernel, not utilities).
 
> This is what I am interested in finding out,  how good is BeOS's
> implementation for process communication, and how the kernel
> architecture works.  Providing OBOS is virtually POSIX compliant I don't
> see anything that would stop anyone getting a GNU system with OBOS
> kernel off the ground within a few weeks.  (Famous last words perhaps).
>   Can anyone confirm if BeOS/OBOS is POSIX compliant?

BeOS R5 is mostly POSIX .1 compliant. Its non-compliancies are well documented 
elsewhere. The real question is "what is the point"? You talk about a "GNU 
system" - this is something that I think is pretty unclear. Are you talking 
about something like X Windows, bintools, gawk, etc, and Gnome/KDE? That is 
certainly possible. It would be a heck of a lot of work (including working 
around the networking and mmap incompatabilities) for little gain. While the 
BeOS kernel has definite advantages (and disadvantages), some of those are API 
specific. You would need, for example, to build your own threading conversion 
between whatever flavor is in use in Linux land this week and what the BeOS 
kernel uses. Not to mention all of the massive amounts of porting to make 
anything that uses device drivers work. All in all, you are talking about a 
heck of a lot of work that would need to be done by someone who is intimately 
familiar with both the BeOS kernel way of doing things and the Linux way of 
doing things. Kernels, despite POSIX, are not drag and drop. The BSD's won't do 
that with Linux kernels, nor will BeOS's kernel (which is further, yet, away 
from the Linux model). It sounds easy, but it is not even close. POSIX is a 
user land API. Anything kernel specific is not part of the standard.

> Included with BeOS5:  The entire compiler suite, fileutilities,
> gnu-utils, texutils many more packages are by GNU.  This is great,
> precisely what everyone should be doing in fact.  No point in
> reinventing the wheel, unless it is going to be replaced with a standard
> form of Concorde etc :)

We 100% agree. That is why some pieces are ports/recompiles and some are 
rewritten. We didn't see the need to write our own compiler. But we definately 
didn't want to be saddled with X Windows.