|
[openbeos]
||
[Date Prev]
[10-2003 Date Index]
[Date Next]
||
[Thread Prev]
[10-2003 Thread Index]
[Thread Next]
[openbeos] Re: Open BeOS
- From: "J. Grant" <jg-lists@xxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Mon, 20 Oct 2003 20:07:50 +0100
Hello,
on the 20/10/03 04:18, Michael Phipps wrote:
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).
SCO would say my Grandma stole their ancient source if it would get
their stock price up.
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.
What I consider to be a "GNU system" is an OS, made mostly from GNU
software, with other Free Software components. This seems broadly
inline with what the FSF consider the "GNU system".
I expect device problems would be limited if I were using OBOS for the
kernel. All GNU software would be used for in this case is userland
code. And depending on how POSIX OBOS is, this could be feasible.
In this thread I am really just trying to gain an understanding of the
way BeOS/OBOS works, in comparison to other OS's I use and understand.
Now I am just considering options; if something has good performance and
interesting features it is worth the effort. I understand there would
be a lot of work to get things running, but I'm a hacker, and that is
the challenge. I'll see how it goes with OBOS development, perhaps
returning to the list when there is a test distro.
Thank you for answering my queries.
Kind regards
JG
|
|
