If it were really Unix, they probably would not have needed to write a whole book on porting Unix applications: https://www.amazon.com/BeOS-Applications-Martin-C-Brown/dp/1...
mmap could be emulated very easily via create_area(), and I think most people did this indeed.
> and no BSD sockets
BONE (an official R5 patch) had BSD sockets. There were also libraries for this also.
> it was absolutely nothing like /dev on any Unix system
What does this mean? Devices were in "/dev" could be opened, stat'ed, "dd"'ed to, etc. It had a different naming convention, but so does macOS and the like.
> No permissions; it's a single-user system. It stores file owners and modes, yes, but they don't actually mean anything; you don't need the +x bit to execute a file, you don't need the +x bit to list a directory, everything is owned by "baron", etc.
"baron" was just UID 0. I haven't looked in a while, but I'm pretty sure you needed +x to actually execute files? At least we mandate this on Haiku and it hasn't broken BeOS compatibility at all, as far as I'm aware of.
> It supported fork but it's incompatible with threads, and everything on BeOS is threaded
What does this mean? Its fork behaved the same way fork does on any other UNIX-like OS, i.e. only one thread carries over. The same is true in Linux...
> Some signals are implemented, but the C API is home grown instead of the standard POSIX calls.
Again, I don't know what you mean here. "glibc" was there, and so of course was malloc(), string.h, etc. etc.
Further, "UNIXy" does not mean "POSIX compatible." IMO the fork-based process model and "/dev" are the large hallmarks of the "UNIX philosophy". POSIX was a larger set of API calls that plenty of 90s-era UNIXy OSes did not ever implement.
Re: /dev. If the only thing similar to Unix is that it contains file-like objects (i.e. "can be opened, stat'd, dd'd to"), and everything else is different, is that really similar?
Re: +x to execute. I'm pretty certain BeOS didn't obey the +x bit, because I remember being surprised by it later when I migrated to a Linux system, but I'm too lazy to fire up real BeOS and not Haiku to check. I only have Haiku set up. Let's assume you're right.
Re: baron. He wasn't "just" UID 0. He was the only user -- you couldn't create others. I tried to create a multiuser addon for BeOS and gave up; you can't do much more than swapping home directories. I feel like you're seeing a facade they built and assuming an entire multiuser infrastructure is present, when they're just supplying whatever hardcoded information they need in order to make their POSIX facade work.
Re: fork. 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. 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. We both know that BeOS does not primarily use forking as its process model, and that fork's use is very rare.
Re: signals. BeOS doesn't have the same internal signal infrastructure as a POSIX system. The "Porting UNIX Applications" book has a whole chapter on how signals in BeOS are different from POSIX systems. The chapter treats signals as sort of a Venn diagram between BeOS and POSIX, where there is some common functionality in the middle, and then some BeOS-only stuff (SIGKILLTHR), some POSIX-only stuff (lots of signals not implemented in BeOS). BeOS's glibc is forked and heavily modified.
Indeed, I am very aware that POSIX and Unix are different. BeOS aimed for some level of POSIX compatibility via a facade, and it's not really very similar to Unix systems.
