> and that Haiku picked it up because the networking situation without BONE is dire
Haiku is vastly more POSIX compatible than BeOS ever was (we have mmap, pthreads, posix_spawn, madvise, etc. etc. etc.) It is indeed compatible with both BONE and Net-API BeOS applications, but properly speaking our network stack is neither; under the hood it looks nothing like the BeOS network stack did (only NIC drivers are source-compatible for the most part.)
> I don't get the feeling that you're arguing in good faith here. If you know about BONE, you know that I'm not whistling dixie about the lack of sockets on BeOS being a problem.
Nowhere did I say it was not a problem. What I did say that a lack of them does not make BeOS "not a UNIX".
> and everything else is different, is that really similar?
What does this mean? Do you think that if there is no "/dev/sda", it's "not UNIX"? There was "/dev/zero", "/dev/null", "/dev/random", etc. What exactly are you asking for here?
> when they're just supplying whatever hardcoded information they need in order to make their POSIX facade work.
The point is that the facade is at least there; I think they were planning to add multiuser in a later release. (Haiku is still single-user on the facade, but under the hood you can useradd, chown, SSH in to other users, etc.)
> BeOS is so deeply multithreaded their marketing called it "pervasive". Linux is not at all; fork is the standard model for multiprocessing and most processes can happily be forked without issue.
Yes, obviously using fork() in an application that used the GUI would not make sense on BeOS. It doesn't make sense on Linux either; it's just that most "BeOS native" applications had GUIs. So what is the difference here?
> Almost nothing on BeOS forks because almost everything needs to use a thread at some point. You know this too; I really think you're playing dumb here in order to make your point seem more convincing.
My point is, again, not that "nothing used it", but rather that "this is how the process model works." I am not playing dumb here...
I didn't look at the details, but my understanding is that the Be-native API calls (e.g. BRoster::Launch) invoked fork/exec under the hood. So, again, simply "it's not that useful when you are using threads" is not the case here.
> The chapter treats signals as sort of a Venn diagram between BeOS and POSIX, where there is some common functionality in the middle
I haven't read the book; what's in the diagram? Is it just signal names e.g. SIGKILL, SIGTERM, etc.?
Only having some signals and not others does not mean it's "not a UNIX". If it talks like a duck, quacks like a duck, looks like a duck, but it's missing a leg and half its feathers ... it's still a duck.
> BeOS's glibc is forked and heavily modified.
Not really? They released the modified source due to GPL of course, and they mostly just removed stuff like mmap() or the like.
Haiku is vastly more POSIX compatible than BeOS ever was (we have mmap, pthreads, posix_spawn, madvise, etc. etc. etc.) It is indeed compatible with both BONE and Net-API BeOS applications, but properly speaking our network stack is neither; under the hood it looks nothing like the BeOS network stack did (only NIC drivers are source-compatible for the most part.)
> I don't get the feeling that you're arguing in good faith here. If you know about BONE, you know that I'm not whistling dixie about the lack of sockets on BeOS being a problem.
Nowhere did I say it was not a problem. What I did say that a lack of them does not make BeOS "not a UNIX".
> and everything else is different, is that really similar?
What does this mean? Do you think that if there is no "/dev/sda", it's "not UNIX"? There was "/dev/zero", "/dev/null", "/dev/random", etc. What exactly are you asking for here?
> when they're just supplying whatever hardcoded information they need in order to make their POSIX facade work.
The point is that the facade is at least there; I think they were planning to add multiuser in a later release. (Haiku is still single-user on the facade, but under the hood you can useradd, chown, SSH in to other users, etc.)
> BeOS is so deeply multithreaded their marketing called it "pervasive". Linux is not at all; fork is the standard model for multiprocessing and most processes can happily be forked without issue.
Yes, obviously using fork() in an application that used the GUI would not make sense on BeOS. It doesn't make sense on Linux either; it's just that most "BeOS native" applications had GUIs. So what is the difference here?
> Almost nothing on BeOS forks because almost everything needs to use a thread at some point. You know this too; I really think you're playing dumb here in order to make your point seem more convincing.
My point is, again, not that "nothing used it", but rather that "this is how the process model works." I am not playing dumb here...
I didn't look at the details, but my understanding is that the Be-native API calls (e.g. BRoster::Launch) invoked fork/exec under the hood. So, again, simply "it's not that useful when you are using threads" is not the case here.
> The chapter treats signals as sort of a Venn diagram between BeOS and POSIX, where there is some common functionality in the middle
I haven't read the book; what's in the diagram? Is it just signal names e.g. SIGKILL, SIGTERM, etc.?
Only having some signals and not others does not mean it's "not a UNIX". If it talks like a duck, quacks like a duck, looks like a duck, but it's missing a leg and half its feathers ... it's still a duck.
> BeOS's glibc is forked and heavily modified.
Not really? They released the modified source due to GPL of course, and they mostly just removed stuff like mmap() or the like.