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.
