5 ms·

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 answe

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 8y ago
BeOS is the silent master we can all learn from
- int_19h 8y ago
  IIRC it still looked very Unix'ish once you dropped into the shell.
  - pjmlp 8y ago
    As much as Windows NT with POSIX personallity.
  - electroly 8y ago
    It ran bash, sure, but BeOS was not similar to Unix at all.
    - waddlesplash 8y ago
      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 8y ago
        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/1558605320 https://www.amazon.com/BeOS-Applications-Martin-C-Brown/dp/1...
        waddlesplash 8y ago
        > 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.

milquetoastaf 8y ago

BeOS is the silent master we can all learn from

int_19h 8y ago
IIRC it still looked very Unix'ish once you dropped into the shell.
- pjmlp 8y ago
  As much as Windows NT with POSIX personallity.
- electroly 8y ago
  It ran bash, sure, but BeOS was not similar to Unix at all.
  - waddlesplash 8y ago
    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 8y ago
      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/1558605320 https://www.amazon.com/BeOS-Applications-Martin-C-Brown/dp/1...
      - waddlesplash 8y ago
        > 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.