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.
> 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.
