[linguae]

As a systems software researcher, I concur. I like Unix and I’m very greatful for its impact on computing, but Unix and its derivatives are not the final answers of systems software design. I feel that much of the software engineering and computer science world (even among OS researchers) is unfamiliar with non-Unix designs other than Windows. We can learn a lot from historical non-Unix operating systems such as the Genera OS for Symbolics LISP machines and the Oberon operating system.

[milquetoastaf]

BeOS is the silent master we can all learn from

[int_19h]

IIRC it still looked very Unix'ish once you dropped into the shell.

[pjmlp]

As much as Windows NT with POSIX personallity.

[electroly]

It ran bash, sure, but BeOS was not similar to Unix at all.

[waddlesplash]

It had the coreutils, glibc, it used UNIX filemodes and the fork() process model, "/dev", etc. So, how exactly was it not a UNIX?

[electroly]

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.

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

[waddlesplash]

> No mmap

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.