Looks good.How about "Unix"?
Looks good.How about "Unix"?
Citation needed.Microsoft has certified a certain NT kernel with Services For Unix userland with The Open Group
You could argue the same about System III, which replaced the `/etc/rc` framework with runlevels. This leads you to a place where you end up with actual UNIX™ from AT&T not being "Unix," but the derived BSD systems not from AT&T are "Unix."Rest assured, BSDs are far more Unix than UNIX(TM) EulerOS although it's not far being a Linux. Linux that has systemd, wayland and every second thing that goes breaking the old Unix philosophy. The "Linux people" pushing for these developments do not want ties to Unix, they see that as needless backward compatibility. Systemd leader has been vocal about this.
cat filename --squeeze-blank
is "non-Unix" in at least three different ways.)Citation needed.
You could argue the same about System III, which replaced the `/etc/rc` framework with runlevels. This leads you to a place where you end up with actual UNIX™ from AT&T not being "Unix," but the derived BSD systems not from AT&T are "Unix."
Possibly an even stronger argument is that systems using the Gnu userland are not "Unix," since the Gnu tools unquestionably go against the Unix philosophy of being small and simple. (cat filename --squeeze-blank
is "non-Unix" in at least three different ways.)
Looks good.
Well, we'll have to agree to disagree on init conforming to Unix style. But my opinion is derived from not only experience using both for well over three decades now, but also as the designer and author of much of the NetBSD /etc/rc.d system. As well, I was around during the "rc vs. init wars," and a lot of people had similar feelings about init as many later had about systemd.The thing is both sysinit and rc conform to main points of Unix dogma. Systemd to none.
There's no need. "UNIX" is the correct rendering of their trademarked term, but under the usual laws and conventions of trademark usage, someone using "Unix" for almost anything computer-related is clearly infringing on the "UNIX" trademark.Btw, if Open Group could trademark "Unix" too, they would've done it. It's not like it's intentionally there to describe something that practically conforms but wasn't certified.
You may feel it's perverse, but that's actually an excellent description of the situation when using "UNIX" or "Unix" in a manner that invites a trademark lawsuit.Then only legal option would be to call FreeBSD "unix-like" and EulerOS or WindowsNT+SFU as UNIX or Unix. Which is totally perverse.
Thank you for that wikipedia link, but I am well versed in the POSIX runtime of the old Windows NT. I am asking for citation as to confirm your assertion that Microsoft had that NT POSIX runtime certified as UNIX by The Open Group. That is totally news to me, so please provide proof, otherwise it smells like a totally fake assertion.Microsoft has certified a certain NT kernel with Services For Unix userland with The Open Group
Citation needed.
Microsoft POSIX subsystem - Wikipedia
en.wikipedia.org
Well, we'll have to agree to disagree on init conforming to Unix style. But my opinion is derived from not only experience using both for well over three decades now, but also as the designer and author of much of the NetBSD /etc/rc.d system. As well, I was around during the "rc vs. init wars," and a lot of people had similar feelings about init as many later had about systemd.
As for systemd, I'm a big fan (and that includes journald). I think that a lot of the people arguing against it just haven't really had to deal with the problems that it solves, such as the nightmares of trying to deal with service management via a complex set of interdependent shell scripts that all share a global variable space or parsing and managing ASCII log files (especially when you're moving them over networks—go run a site with even just a few dozen servers to be managed and see where you get with crap like logrotate.)
One of the big ironies of the whole systemd brouhaha was that a very similar thing happened with the replacement of netconf with NetworkManager (with about the same relationship between them as /etc/rc and systemd), and almost nobody complained about that. Perhaps the reason was that even individual users often have the problems with netconf thrust right in their faces, and so they better understand the problems that the "Unix philosophy" can bring. (To be clear, I'm not saying I'm not a fan of the Unix philosophy, I'm just saying that there are situations where it causes more pain than its simplicity helps.)
There's no need. "UNIX" is the correct rendering of their trademarked term, but under the usual laws and conventions of trademark usage, someone using "Unix" for almost anything computer-related is clearly infringing on the "UNIX" trademark.
You may feel it's perverse, but that's actually an excellent description of the situation when using "UNIX" or "Unix" in a manner that invites a trademark lawsuit.
Thank you for that wikipedia link, but I am well versed in the POSIX runtime of the old Windows NT. I am asking for citation as to confirm your assertion that Microsoft had that NT POSIX runtime certified as UNIX by The Open Group. That is totally news to me, so please provide proof, otherwise it smells like a totally fake assertion.
From my quick look at the list of USL systems certified as Unix, NT ain't there.So it remains under a question whether USL certified it or someone else did.....
Yeah, I dunno that I"m buying that as a real thing. POSIX filesystem semantics are so different from Windows NT filesystem semantics that I don't see how a system can support both except to say, "we have these semantics for one mount, and those semantics for a different one." In which case, what's the point? Do you refuse access to files on a mounted NTFS to any program that runs in POSIX mode, and vice versa?Still a version of NT achieves full POSIX compliance while being the farthest thing from Unix, lineage and philosophy wise, of all major OSes on the market then.
That link does not document what USL may have certified or vetted as UNIX prior to the constitution of The Open Group. That link is the "Registry" which The Open Group maintains for certified UNIX which *also* are current with their payment to be listed on such "Registry". Notice the absence of Sun/Oracle Solaris from that list... Oracle has lapsed in its payment to The Open Group. Solaris is still a certified UNIX by The Open Group, but has temporarily been de-listed from the UNIX Registry which The Open Group maintains (same case as EULER Linux, by the way).From my quick look at the list of USL systems certified as Unix, NT ain't there.
From my quick look at the list of USL systems certified as Unix, NT ain't there.
Yeah, I dunno that I"m buying that as a real thing. POSIX filesystem semantics are so different from Windows NT filesystem semantics that I don't see how a system can support both except to say, "we have these semantics for one mount, and those semantics for a different one." In which case, what's the point? Do you refuse access to files on a mounted NTFS to any program that runs in POSIX mode, and vice versa?
I'm thinking that question really needs a separate thread; that straying even quite a bit further than this one already has. But if there's a place here appropriate for such a discussion, post about it and send me a PM and I'll reply.What parts of the sysinit workflow and design do you see as Unix-incompatible?
I"m not sure what that means. I guess perhaps I was always just looking at it from a technical perspective?I don't disagree with systemd but I heavily disagreed with politics around it.
No problem. BSD is a separate thing in many ways and, while systemd is great, rc.conf can do a reasonably good job, too. But probably more importantly, systemd (I think probably properly) takes advantage of Linux-specific stuff in the kernel. So complaining about it not working on BSD is like complaining about Docker not working on BSD: it's unfortunate, but it would require some serious shaving of functionality to make it portable to other Unices. (Actually, as I'm reminded by the real topic of this thread, it's like complaining about the lack of POSIX filesystem semantics on Windows.)I also wonder what's your opinion about them not taking into account BSD world at all.
Ha! Go completely remove NetworkManager from your laptop and report back on your experience! I guarantee you will not be happy. (And if you drop netconf as well, let us know how fun you find it to have no networking at all without manually running ipconfig or ip.netconf and NetworkManager are not essential system packages tho, networking works without them.
Oh, right! This thread had a different topic originally!Do keep in mind the thread here. OP asked for a Linux distro, I came in with FreeBSD idea but said it's not a Linux, then someone else followed up saying BSD is Unix. It went from there.
Oh, clearly NetBSD. I think we're in agreement that it's easiest to use "Unix" for the thing that, well, we know what it is. And "UNIX™" when we're talking about the trademark. But obviously such usage conventions can be confusing.I did write in my previous threads that I separate the legal Open Group stuff with the spirit. There's a link for POSIX-certified Windows. If we aren't talking legal terms, what's more of an Unix, NetBSD or that system?
Open Group, of course, since USL is long gone. And, well, those are the systems currently certified to be called "UNIX." I don't know much more than that about it. I agree that it has a tenuous relationship to what any Unix user or sysadmin thinks of as "Unix."Are those USL or Open Group certifications?
The list misses Solaris and IRIX among others. I think that's the current list, only by Open Group (96-)
But POSIX does specify the filesystem semantics, does it not? (Which are sort of internals.) Semantics that are simply not compatible with systems like Windows NT or others that cannot separate inodes and filenames.Exactly my point. POSIX does not specify the internals of the system. That's why I'm against on putting "Unix" tag to everything certified for POSIX by whomever, just like that.
But POSIX does specify the filesystem semantics, does it not? (Which are sort of internals.) Semantics that are simply not compatible with systems like Windows NT or others that cannot separate inodes and filenames.
Ha! Go completely remove NetworkManager from your laptop and report back on your experience! I guarantee you will not be happy. (And if you drop netconf as well, let us know how fun you find it to have no networking at all without manually running ipconfig or ip.
Can you give me a link to the standard you're looking at? I was pretty sure that POSIX specified semantics such as, "you can open a new file, unlink() it, and continue to use that file handle (making changes to the file all that time), then linkat() that file descriptor to a new name and the "new file" will appear with all your contents." (You can read that as, "inode is separate from filename") I am still reasonably sure that Windows will not let you do anything like that.The standard has no mention of inode. Kernel internals are not in the scope.
Well, fair enough, I suppose, but you must admit that the vast majority of users need to change their IP address on a regular basis, and do like this to happen automatically.Hah I'll always prefer hitting a cli command or two than have a daemon hang around for the same purpose - but I use fixed networking, not wireless and certainly not roaming stuff.
It's right there in 5.5.1.2, the description of the unlink() call:No mentions of that sort of stuff that I can find.
The major structure you use to implement that functionality and hard links need not be called an "inode," of course, but whatever you call it it's going to be effectively the same thing: file information separate from the file name so you can support files that have zero, one, two or more names.When the file’s link count becomes zero and no process has the file open, the space occupied by the file shall be freed and the file shall no longer be accessible.If one or more processes have the file open when the last link is removed, the link shall be removed before unlink() returns, but the removal of the file contents shall be postponed until all references to the file have been closed.
Well, that makes my point. Even you use NetworkManager.On another work machine, current Rocky Linux, NM is running because I'm moving between fixed and multiple wireless access points.