|
> Is there such a thing as a Unix “design and architecture” though? I think so, absolutely yes. Internals of kernel are largely irrelevant, I would submit. That's not visible to the user. Minix 3, Darwin atop XNU, HURD, doesn't matter: boot it in single-user mode and they all look much alike. Cryptic little terse commands, all in lower-case, with single-letter switches after `-` and these days often full-word ones after `--`. Lots of cryptic little plain-text config files, both in a global directory (usually in `/etc`) and in the user's home directory (usually under `/home`). No drive letters or indicators, one global filesystem, directories separated by `/`. Then look at the things that are only pretending to be a Unix, from NT to OpenVMS to z/OS, and there's a totally different shell or set of shells, there are drive indentifiers and maybe directories, maybe not, with who-knows-what as the delimiter. NT has "real" internal identifiers mapped to Windows-like ones and to Unix like ones, these days via at least 3 entirely separate subsystems: the original POSIX subsystem, much enhanced; and WSL 1, with code from the Windows Android runtime emulating a Linux kernel; and WSL 2, using Hyper-V to run a real kernel in a special porous VM. (Talk about baroque!) I think it's very clear which of these are UNIX-like designs, with a Unix-like filesystem and a Unix-like shell and so on, and other ones, where but it's a (maybe option) extra, it's not the real underlying OS and you can quite possibly ignore it and never see it, or even remove it, and you can't use the Unix-like personality to run and administer your machine. Yes, I think it's a real and important distinction. QNX, say, is Unix-like. VMS, say, is not. Even if one has better compatibility with the notional "real thing" than the other. |
Okay, but AIX quite notably deviates from that, in that it stores a lot of its system configuration in binary format, in a database, the Object Data Manager (ODM). In some ways, AIX's philosophy about storing system configuration is closer to the Windows Registry than to traditional Unix systems. Does that therefore mean that AIX deviates from "Unix design and architecture", and hence isn't a "real Unix"?
> Then look at the things that are only pretending to be a Unix, from NT to OpenVMS to z/OS, and there's a totally different shell or set of shells, there are drive indentifiers and maybe directories, maybe not, with who-knows-what as the delimiter.
So one of your arguments here seems to be, that if a system supports a non-POSIX path name syntax, it cannot be a "real Unix"? Or if its native path name syntax isn't POSIX path name syntax, it can't be a "real Unix"?
But, isn't it true that z/OS natively supports POSIX path name syntax? I mean, when you give z/OS a Unix path, if it is a path to a Unix file it never translates it to an MVS dataset name, because Unix files aren't datasets and don't directly belong to the MVS VTOC filesystem. Now, it is true that the Unix file is contained in a Unix filesystem (HFS or zFS), and that Unix filesystem is contained in a VSAM LDS dataset in the VTOC filesystem. But, if you compare that to z/Linux – a file is contained in a Unix filesystem (ext4 or whatever), and the Linux kernel supports storing that filesystem as a non-VSAM dataset in the VTOC filesystem – so z/OS and z/Linux actually behave pretty similarly here, at least when you use the Linux kernel's IBM VTOC support, the only actual difference is whether the filesystem dataset is VSAM LDS (DSORG=VS) or non-VSAM (DSORG=DA). Also, z/Linux can actually read (non-VSAM/PDSE) datasets in VTOC filesystems (using zdsfs from s390-tools), and for both z/OS and z/Linux, access to MVS datasets in VTOC filesystems is done using a hybrid between Unix and MVS naming syntax (although the details are somewhat different in each case). z/OS supports write too, but I don't see why that's a fundamental issue, given that other components of s390-tools (such as fdasd) have some degree of write support. z/OS and z/Linux are more alike than you seem to think.