Ever try to port a POSIX utility to BeOS? I did. No mmap and no BSD sockets killed any chance of easily porting any network utility to BeOS. It had a directory called /dev, yes, but it was absolutely nothing like /dev on any Unix system; it's all home grown. 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. It supported fork but it's incompatible with threads, and everything on BeOS is threaded. Some signals are implemented, but the C API is home grown instead of the standard POSIX calls. Etc. They built a Unix facade but the system is very un-Unix like.
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: sockets. We both know BONE was never officially released because Be went out of business before Dano came out, that it was written to solve exactly the problem I described, and that Haiku picked it up because the networking situation without BONE is dire. Come on. 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.
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.