Slashdot Mirror

The Mac OS *kernel* comes from AT&T via DEC and others. Anyway, thirty years ago, AT&T sold the Unix name, and 25 years ago it was transferred to the Open Group, so it's been 30 years since Unix and and AT&T parted ways, 25 years since the Unix name went open. The reason I say "the Unix name" is because when the name was originally sold and locked down, there were several different Unix operating systems. At least three, which were all Unix, all derived from the same code. One group kept the name, the Open Group via AT&T and Novell.

In other words, it's kinda like asking "is Sierra actually Mac? I didn't know know Wozniak wrote it." Yes, new programmers can work on some software and it's still real. There have been 30 years of programmers between AT&T and modern Unix. It's still Unix.

There is a 3,700 page set of detailed specifications called the Single Unix Specification. A Unix system is defined as an operating system which is certified to meet all of those specs. The spec includes things like a Bourne-shell derived /bin/sh called the POSIX shell, ncurses, and 1,123 kernel and library functions.

Note the Unix spec describes (in detail) what a Unix *operating system* is, how it behaves and what it provides. Less than half of the spec deals with the *kernel*. The specs say the operating system must provide all of these different functions, which must work exactly as described. It does not specify *who* must write the functions. That's been true for 25 years. The pedigree of the kernel does not matter at all in terms of whether it's Unix. If you and I wrote an exact copy of Solaris Unix, so we ended up with the same operating system, that would be a Unix, if we got it certified showing we made a faithful copy - we met all specs correctly.

As far as the pedigree of the *kernel* goes, back in the AT&T days, AT&T licensed DEC, Microsoft, and others to create Unix systems. There were three major Unix systems. OSF/1 was one of those, BSD was another. OSF/1 (Open Software Foundation 1) used a modified version of a kernel built, for Unix systems, based on BSD Unix code, called mach. Years later, more code from BSD, mach, and other sources in the NeXTSTEP operating system. When Apple bought Next, they replaced much of the kernel code from NextSTEP with code from a different, more direct, descendant of OSF, which had been renamed OSFMFK, then modified it extensively to create XNU.

So yes there is some mach code in XNU. Mach was largely a reworking of kernel code from the Berkeley UNIX tapes. All of these kernels were designed for, and used in, Unix systems.

A list of Unix (tm) operating systems can be found here:

https://www.opengroup.org/open...

This is what I based on my opinion: http://pubs.opengroup.org/onlinepubs/9699919799/frontmatter/notice.html.

Linux dev tools running under macOS are a bit of a grab bag. You see, true UNIX type systems use the mantra that everything is a file.

macOS is a UNIX type system, officially: UNIX® Certified Products:
Apple Inc.: macOS version 10.14 Mojave on Intel-based Mac computers
Apple Inc.: macOS version 10.13 High Sierra on Intel-based Mac computers
https://www.opengroup.org/open...

This is something that absolutely is not true under macOS.

Nearly any *nix code that is somewhat cross platform builds and runs fine under macOS.

Worked flawlessly on Linux systems, but alas, the TA was using a mac, and mac will not let you simply do a 'echo "foo" > /dev/stty1'

You are confusing security settings with Unix compatibility.

Mac OS is already loosely based on Unix

To nitpick, if you mean UNIX, technically macOS is registered as UNIX 03.

https://www.opengroup.org/open...

I assume by "loosely based" you were probably referring to Linux, more appropriately the GNU tools and what not that it contains.

Sigh When the Open Group says they are, they are.

Yes, as you found out "0day" is not a valid username.

I tested Ubuntu, Debian, FreeBSD, and OpenSolaris, 0day is a perfectly valid username.

Oh it's more than just that, I checked the POSIX standard and this rule of his is entirely invented.

per the POSIX standard:

A string that is used to identify a user; see also User Database. To be portable across systems conforming to POSIX.1-2017, the value is composed of characters from the portable filename character set. The <hyphen-minus> character should not be used as the first character of a portable user name.

so what's the portable filename character set?

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 . _ -

What's this mean? On POSIX your username can be "007", "4-8_" or "._-" if you want it to be.

Lennart is full of shit and cannot admit he didn't even consider the standard when designing systemd.

Yes, as you found out "0day" is not a valid username.

I tested Ubuntu, Debian, FreeBSD, and OpenSolaris, 0day is a perfectly valid username.

Oh it's more than just that, I checked the POSIX standard and this rule of his is entirely invented.

per the POSIX standard:

A string that is used to identify a user; see also User Database. To be portable across systems conforming to POSIX.1-2017, the value is composed of characters from the portable filename character set. The <hyphen-minus> character should not be used as the first character of a portable user name.

so what's the portable filename character set?

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 . _ -

What's this mean? On POSIX your username can be "007", "4-8_" or "._-" if you want it to be.

Lennart is full of shit and cannot admit he didn't even consider the standard when designing systemd.

Funny that every single version of OS X/macOS since 10.5 (Leopard) has been a Certified Unix (something NO Linux will EVER be).

It is funny that OSX / MacOS seems to be the only OS that wants to be certified as another one. This is quite a strange thing to be proud of as a mac fanboi.

Who says they are the only ones that WANT to be Certified?

https://www.opengroup.org/open...

Why LIE about something that is so easily proven?

I know. You're "Certifiable" yourself. Only it's a different kind of "Certification"...

Unix was founded on the ideas of lots os simple command line tools that do one job well and don't depend on system idiosyncracies.

People who say this don't have a particularly deep set of UNIX experiences.

Off the top of my head, I've worked with Linux (on PC, PowerPC, Itanium, S390, and mipsel), *BSD, MacOS, HPUX, AIX, IRIX, XENIX, DYNIX, SunOS, Solaris, and QNX. Most of these various flavours of UNIX have completely different network configuration tooling. Sometimes they are simple tools that don't depend on system idiosyncrasies, sometimes not. Often "ifconfig" and "netstat" aren't present, or if they are, are simply wrappers around other utilities (often provided only to provide better compatibility with shell scripts targeting Linux).

ifconfig and netstat are not even defined in POSIX.1-2017. Neither is /proc -- not all UNIX systems support procfs (although certainly many do).

Lastly, the tools discussed here in iproute2 originally made their way to Linux in 1999. They aren't new. And they are simple command line tools that do one job and do it well. They simply have more features, and provide better access to lower-level networking entities in Linux.

The history if UNIX has been a mishmash of all sorts of network (and other) configuration tools. Pretending otherwise is simply ignoring UNIX history by people who think Linux is UNIX.

Yaz

Unix is not a text editor.

A UNIX system includes the vi application, which is a screen-oriented text editor. The standard specifies its behavior.

No, this one:

http://opengroup.org/

Yeah! macOS forever!

... they will creat accountability algorithms.

You mean, they pay the Open Group to use the trademark? I have purchased a few of their license plates myself, so I guess I have a "real" UNIX, too.

Nothing that special, but Apple likes stuff like that.

I was going to reply saying that macOS hadn't been certified since 10.6, because Apple said that they'd no longer bother after that, but apparently I was wrong and 10.12 is certified (though apparently only UNIX03, which is a bit surprising because I've not found anything from UNIX08 missing and many of the UNIX08 additions were originally in macOS). The most interesting one on the list is Huawei EulerOS 2.0 - as far as I know this is the first Linux distribution to be certified UNIX.

Troll troll troll your boat....

Hardly.

The Gnome desktop has become a steaming pile of bloat.

systemd is a shitty, shitty, shitty solution in search of a problem, from the very same sphincter that excreted PulseAudio - one of the same Linux turds that the GP post complained about.

And yeah, Linux has become less stable than Windows. And that's not surprising, given the attitude many in the free software community display towards standards. Hey, if you can't get fork() to be async-signal-safe as the POSIX standard requires, try to get the standards committee to lower the standard so you can meet it.

Because "We don't meet that standard, so would you please lower it even though everyone else does meet the standard?" is not an attitude that leads to stable, robust systems.

Yes, z/OS.

It does now. Include <stdint.h> and you have it.

There are several non-Intel-based OSes which are Certified UNIX products with HW still in production https://www.opengroup.org/openbrand/register/xy.htm

I'm afraid that I've encountered a few engineers who refuse to acknowledge the distinction between UNIX operating systems, which follow certain detailed standards documented in the "Single UNIX Standard" at https://www2.opengroup.org/ogs... and other operating systems whose kernels, and whose core libraries, have critical distinctions. MacOS, for example, is. Linux is not, as documented at https://www.iso.org/standard/3... . Solaris was, and SCO OpenServer was, as was AT&T SysV.

Following a standard in every detail can be difficult, confusing, and expensive to verify. This is partly why genuine UNIX operating systems have fallen out of favor in many environments.

The people that count say it is. All that other stuff is just junk thrown on top.

You'd be better off criticizing how crappy their implementation of some of the commands is in terms of performance, because it is. I just opened up top totally vanilla and it was consuming 3.8% of a core. On Solaris it would be something like 1%, even with much slower cores. (Apple used to use 10% on top and this was a better example.)

OS X has been certified UNIX 03 since 2007.

and i guess you don't know that Shell is a UNIX standard.

That's actually funny.

Whilst paths could theoretically be any length on UFS, there was (actually still is) a #define called PATH_MAX which practically every programmer used to allocate buffers to hold paths. According to Posix, the absolute largest this define can be is 256 (fortunately, Linux ignores this and goes for 4096).

I bet there is a lot of Unix code out there that breaks, possibly in subtle ways when paths exceed PATH_MAX characters.

The standard says "If the process is a controlling process, the SIGHUP signal shall be sent to each process in the foreground process group of the controlling terminal belonging to the calling process." No action required by that controlling process, or even discretion about it.

No, it is *not* self-evident that cgroups are an improvement for login sessions. For virtualization, sure, they make sense -- but I am unconvinced that the same kind of resource quotas make sense for login sessions.

This header file defines float_t as double precision, although by default math.h defines float_t as single precision.

Sorry. Technically float_t is a type, and defined as single precision. double_t is the correct type for double float

Regardless, redefining the float_t to being double is the problem, when it is already defined as something else. Sending back for a fix would solve the problem, rather than redefining what float_t means. Of course, you can remain pendantic and not get the point I was making. It is solvable, by sending the code back for revision, to remove the problematic re-defining of the type. In this case, using double_t instead of redefining float_t .

http://pubs.opengroup.org/onli...

float_t
        A real-floating type at least as wide as float.
double_t
        A real-floating type at least as wide as double, and at least as wide as float_t.

The world is won by "good enough". Someone who's an obvious fan of a platform that fancies itself a Unix should understand that.

Jealous much?

Unlike Linux, OS X, all the way back to 10.5 Leopard up through the just-released 10.11 El Capitan, OS X is a Certified Unix. Something that no Linux will ever be.

Let's clarify real quick. Overall I agree with your point, but:

1. 1) OS X is not Linux. It's also not "Unixy". Linux is a Unix clone, and OS X is UNIX. Full stop.

My full apologies here folks, This is slashdot, and I probably insulted some of the linux folks with my asinine comparison.

...but the distinction should be maintained.

Why? How "unixy" Linux or MacOS is is a really rather tired argument by now, isn't? Having cut my unix teeth on Solaris, AIX, and HP-UX, seems like I should be able to tell how "unixy" something is. I have MacOS because of my work, but I hate it. It doesn't really fee like unix to me at all, and I have a hard time understanding how "unixy" it really is since the kernel is a heavily modified mach clone. But whatever, just saying your reasoning on how "unixy" Mac is seems a bit strained to me, even with a big web page with small characters explaining how "unixy" it is.

The point of my post was more to correct the semantics in the discussion than to debate how unixy either OS is. Mac, Linux, *BSD, and Solaris are all sufficiently unixy for me. But I'm not a real neckbeard--I never used AIX or HP-UX.

By "the distinction should be maintained" I meant the distinction between OS and GUI. Why not? GUIs are interchangeable and optional. I do the vast majority of my work in terminal, my cross-platform text editor, and a browser. I care a lot more about how the OS handles path resolution, variables, ssh, port forwarding over ssh, symlinks, shell expansion, regex, etc. than crap like launchctl or X. Is there even a POSIX standard or anything similar regarding windowing systems?

I'd agree that Mac doesn't "feel" Unixy. But in my experience, it implements the standard reliably enough. I'm curious where it falls short for you (aside from personal dislike, which I totally get).

If you haven't read the standards, you might want to glance at IEEE Std 1003.1, 2013.

Let's clarify real quick. Overall I agree with your point, but:

1. 1) OS X is not Linux. It's also not "Unixy". Linux is a Unix clone, and OS X is UNIX. Full stop.
2. 2) "You're in at the deep end of the pool now, so it better be good" and "If you like, I can give you his contact info so you can tell him how wrong he is." come across as very petty and childish. Along the lines of "my dad can beat you up!".
3. 3) The "main attraction" of Linux is not that the GUI is configurable. The main attraction is that it's stable, free, and easy to manage at scale on servers. The main attraction of LInux on the desktop is... bragging rights? Desktop usage is what, 1% of Linux usage?
4. 4) sunderland's post equates the GUI with the OS. I am sure he understands the distinction, but the distinction should be maintained. OS X's OS is UNIX. It has a ton of room for customization, replacement with a lot of GNU binaries, etc. It's extremely powerful and compatible with other *nix systems, and absolutely a good base for learning *nix methodology and utilities.

5. However, the windowing system is not highly customizable. I'd argue it's far better than Windows, and provides a better user experience for the majority of users than GNOME, KDE, etc... but no, you're not going to be editing the source and recompiling with new features.

Personally, I am happiest with Mac on my desk and Linux in my server room (or cloud). The MacBook Pro isn't that much more expensive. It's a great computer with a good (paid) warranty that gives me full support and compatibility with all the tools I need, and I'll never have to waste time fucking with drivers or the latest GNOME stupidity.

...There's a three-page article explaining this, ...

Not really. That three page article does not explain the benefit to POSIX if the merger would occur.

.
For example, what is the approval process for changes to Object Store? What is the approval process for changes to POSIX? What will the resulting approval process look like after the two are merged? How will POSIX benefit from the new approval process?

There is nothing in the article that addresses that topic. And that is but one of many unaddressed topics.

The article is typical technical magazine article. Lots of interesting technical stuff, but nothing about process.

There, I fixed your question for you.

Not really. All you did was show that you've not a clue about what POSIX is and how new features are added to POSIX.

fwiw, I'm not saying that POSIX wouldn't benefit from having something like Object Store added to it, I'm just saying that the process to do such a thing needs to be understood and followed. You might want to start by researching how to make an addition to the POSIX standard. Here's a link to that starting place: http://pubs.opengroup.org/onli...

Some folks were asking how this works, so here goes:

newgrp is a UNIX utility that executes a shell with a new group ID (UNIX specification page: http://pubs.opengroup.org/onli...). This requires root permission since it can change the group ID to one outside the current shell's group list (e.g. to any group in the uid's group list). Therefore, newgrp is a setuid root application which launches a shell.

DYLD_PRINT_TO_FILE is a dyld (OS X dynamic linker) environment variable that tells dyld where to print debugging information. Ordinarily, dyld supports a large number of debugging options to facilitate debugging shared libraries and to allow neat tricks like DYLD_INSERT_LIBRARIES (equivalent to LD_PRELOAD on Linux). When dyld sees this environment variable, it opens a new file descriptor connected to the specified file. Since fds 0,1,2 are already connected to stdin, stdout and stderr, the file is opened as fd 3.

Notably, since newgrp starts as root, the file is opened using root's permissions, even though newgrp later drops privileges to spawn the shell.

Because DYLD_ environment variables can modify a program's behaviour in unexpected ways, they are usually deleted or sanitized prior to running setuid programs (because otherwise an unprivileged attacker could cause a setuid program to misbehave, exactly as in this exploit). Apple clearly forgot to sanitize the new DYLD_PRINT_TO_FILE when shipping Yosemite, opening this particular flaw up.

Finally, the (outer) echo command tells the subshell spawned by newgrp to execute the (inner) echo command, which outputs the string "$(whoami) ALL=(ALL) NOPASSWD:ALL" into fd 3, which (due to the DYLD_PRINT_TO_FILE variable) is /etc/sudoers. This line tells sudo that *any* account is allowed sudo access, and that no password is required to use sudo.

The subshell then exits (no more commands to run), and the final command "sudo -s" executes. Since sudo no longer requires a password, and all accounts can use sudo, "sudo -s" just immediately opens a root shell without prompting.

Because there's no such thing as an assignment operator in bash. Everything is a string token at first (even numbers aren't number unless you're in arithmetic evaluation context), and then tokens get interpreted in various ways once split by whitespace. x = 3 happens to be three tokens, the first one being the command 'x', the other two being parameters '=' and '3' to command 'x'. x=3 is one token and it doesn't mean assignment unless it's in the command preface where assignments take place.

Tomatoe Tomato.

Actually I also do $(($x+1)) as per example in http://pubs.opengroup.org/onli.... (Arithmetic section)

But I think I will have to revise that behaviour as it could allow circular problems or "arithmetic injection". Thanks for making me aware of this.

Why did Apple ever bother with Unix certification then?

It already does unless you've forcibly removed OSX.

While we're in a thread called "Pedantic, but..." I feel safe with posting that OS X actually _is_ a UNIX, with SUS03 compliance. They did that after being sued by The Open Group for claiming to OS X be a UNIX when they weren't in compliance.

Unix again does it wrong by keeping system time in UTC rather than TAI.

Actually, that's not what POSIX does, for any definition of "keeping system time in UTC" corresponding to the ITU-R specification, as the POSIX definition of "seconds since the Epoch" and its mapping to a struct tm doesn't allow the seconds value to be 60, which it will be during a positive leap second.

I.e., it's even more wrong - a POSIX-compliant time_t isn't something that corresponds to TAI (as it doesn't tick forward by 1 every second of elapsed time) and you can't generate valid UTC labels (YYYY-MM-DD HH:MM:SS) from it.

UTC is useful for humans

...but I suspect few clocks used by humans give a local time corresponding to UTC - most of the digital ones won't show "60" in the seconds section one second after June 30, 2015 at 23:59:59 UTC, and I don't know what the right thing to do for the second hand on an analog clock would be (for an analog clock without a second hand, presumably the minute hand should move two seconds after June 30, 2015 23:59:59 UTC).

but difficult for machines, it should be handled by the human interface libraries, just like time zones. Kernel time should be TAI of course.

I.e., "seconds since the Epoch" should actually be a count of the number of seconds that have elapsed since the Epoch, rather than being, well, what it is.

When leap seconds are inserted, systems must be updated,

...and whatever data structures are used to keep tract of future scheduled events might have to be updated to reflect that, for example, July 1, 2015, 00:00:00 UTC is going to be one more second later than was expected at the time an event was scheduled for that date and time.

However, having system time tick ahead one second every second means that events scheduled to occur N seconds from now, rather than scheduled to occur at YYYY-MM-DD HH:MM:SS UTC, won't have their time messed up by leap seconds; it's not as if the POSIX solution doesn't screw up anything.

but that is not particularly harder than keeping the time zone files up-to-date is already.

Especially given that leap seconds are part of the Olson^WIANA time zone source files.

How about instead of setting the time to 23:59:60, the value 23:59:59 happens twice.

Because that would be extremely broken as 00:00:00 - 23:59:59 is _one_ second, not two.

Broken, but POSIX-compliant.

The long term plan is to run iOS on laptops and desktops, or have you not been paying attention? This is why Apple has stopped caring about POSIX, and has put all of its efforts into the iOS runtime environment--UI, toolchain, etc. OS X is a second-class citizen.

http://www.opengroup.org/openbrand/register/brand3607.htm

Hey, now that the systemd nutters have broken Linux we can go back to calling Unix Unix instead of *nix.

At least one trademarked Unix uses a launch-on-demand-based init daemon, so it's not clear that the use of systemd-the-daemon is sufficient to make Linux not be a Un*x. Maybe systemd-the-software-bundle is sufficient.

It changes the user space sufficiently that the historical text configuration files for logging and other facilities no longer function compatibly with the VSC test suite. If those were changed back, or the test suite was somehow made independent of configuration variances for the purposes of testing, I might agree with you, but as it is, there is no way a systemd based system would pass VSC, and would also likely fail VSX, and the parts of the VSTH and VSRT testing, based on the posix_spawn implementation and XPG/4 compliance.

Hey, now that the systemd nutters have broken Linux we can go back to calling Unix Unix instead of *nix.

At least one trademarked Unix uses a launch-on-demand-based init daemon, so it's not clear that the use of systemd-the-daemon is sufficient to make Linux not be a Un*x. Maybe systemd-the-software-bundle is sufficient.

OS X is Unix. FreeBSD, Linux and every other crappy "work-alike" you idiots are talking about, by contrast, aren't.

$() is POSIX. Backticks are, too, but usually discouraged, for they don't nest.
Sibling's claim that this was bash- or zsh specific is wrong.

http://www.opengroup.org/openb...

iOS is based on OS X, which is a proper UNIX.

As I stated elsewhere on this page, no, iOS is based on BSD. OS X is also based on BSD, but that doesn't mean iOS is based on OS X.

There are many similarities, but for obvious reasons, they had to strip a lot out in iOS to make it practical for mobile hardware.

And no, BSD isn't UNIX, nor is OS X. They are posix-compliant operating systems, like Linux, AUX, and HP UX. None of them are actually UNIX anymore. All split from actual UNIX long ago. But they are all "unix-like" operating systems.

Well since we're all nitpicking, UNIX(R) is a trademark, just like POSIX(R) and you can call your butt either one if it's certified.

_If_ the above systems are actually certified to be POSIX compliant to some degree, they could also be a test away from being UNIX certified, to some degree.

IF we're just calling all the above "[POSIX|UNIX]-like", they all qualify... to some degree.

I enjoyed that article, but it's worth noting that vi actually is standard.

I'm talking data de-duplication searching tools,

Son, are you kidding me?

multi-monitor window managers,

What?

downloading / p2p tools,

Excuse me?

media players,

You fail it

media encoders

Wrong

etc.

Are you even trying?


In unrelated news, slashdot doesn't let me post this reply as-is, because it consists of too short lines, on average. Wtf. Fooooooooooooooooooooooooooooooooooooooooooooooo

I'm talking data de-duplication searching tools,

Son, are you kidding me?

multi-monitor window managers,

What?

downloading / p2p tools,

Excuse me?

media players,

You fail it

media encoders

Wrong

etc.

Are you even trying?


In unrelated news, slashdot doesn't let me post this reply as-is, because it consists of too short lines, on average. Wtf. Fooooooooooooooooooooooooooooooooooooooooooooooo

I'm talking data de-duplication searching tools,

Son, are you kidding me?

multi-monitor window managers,

What?

downloading / p2p tools,

Excuse me?

media players,

You fail it

media encoders

Wrong

etc.

Are you even trying?


In unrelated news, slashdot doesn't let me post this reply as-is, because it consists of too short lines, on average. Wtf. Fooooooooooooooooooooooooooooooooooooooooooooooo

I'm talking data de-duplication searching tools,

Son, are you kidding me?

multi-monitor window managers,

What?

downloading / p2p tools,

Excuse me?

media players,

You fail it

media encoders

Wrong

etc.

Are you even trying?


In unrelated news, slashdot doesn't let me post this reply as-is, because it consists of too short lines, on average. Wtf. Fooooooooooooooooooooooooooooooooooooooooooooooo