Absolutely not.

POSIX hasn't bothered to scrutinize it, as stuff such as the init system are outside the scope of POSIX. (SUSv3-compliant systems include a system using launchd, a system using SMS, and some systems that, as far as I know, still use System V-style traditional inits.)

So that, for example, tasks within a job with SMT enabled could be scheduled with two tasks running on the same core as separate threads, rather than running on different cores?

(In the synchronicity department, the quote that popped up on /. when I went to your posting was "Your mode of life will be changed to EBCDIC.")

Actually, since System/360, each new IBM mainframe got a CPU that executed an instruction set that was a superset of the previous mainframe's instruction set, just as, for example, an 80486 executed an instruction set that was a superset of the 80386's. They did have to provide a mode bit for, say, 24-bit addressing vs. 31-bit addressing, but that's about it - there's also a difference between 64-bit mode and the 32-bit modes (24-bit addressing and 31-bit addressing), but that's true of just about every 64-bit processor out there except for Alpha (which was born 64-bit).

So there's no need, at the hardware layer, for emulation, other than the mode bits, to run older S/360 user-mode ("problem state") code, and certainly no need for a stack of emulators.

S/360 and earlier S/370's had options to emulate older non-S/3x0 processors, such as the IBM 14xx and 70xx systems; I don't know whether they still provide that with any level of hardware/firmware assist or if that's just done in software (which it can be, these days).

There's also backwards compatibility in the OS, but I doubt that involves multiple layers, just the continuing ability to support older APIs and ABIs on newer versions of the OS. That's not unique to IBM's operating systems, although they might be stricter about it than Microsoft or Sun^WOracle or... are.

Presumably by "support for SMT" you mean "understanding that you don't have n processor cores with their own CPU resources, you have n/T processor cores, each of which can run T streams of code at once sharing some of those resources", so that the scheduler might not treat all entities capable of running streams of code the same.

I don't know whether z13's SMT manifests itself as each core looking like two processors, but I have the impression that other chips that implement T-way SMT look mostly like chips with T times as many cores as they actually have, and could be treated by an SMP-capable OS in that fashion, but that doing so might not be the best way to treat them.

Perhaps they were referring to multithreading (which I think is new in the z13, although I read something about IBM having experimented decades ago with a 2-way-threaded variant of the System/360 Model 195) rather than to superscalarity. (Presumably they weren't referring to chip multiprocessing, either, as the z13 isn't the first multi-core z/Architecture chip.)

Sorry, I forgot that listicles usually use digits, so I guess that'd be "You won't believe these 5 new functions systemd performs!".

"You won't believe these five new functions systemd performs!"

Although I do note that

$ size -m /sbin/launchd

shows

Segment __TEXT: 159744
Section __text: 111946
Section __stubs: 1584
Section __stub_helper: 2656
Section __cstring: 26034
Section __const: 152
Section __osx_log_func: 21
Section __unwind_info: 868
Section __eh_frame: 12928
total 156189

on OS X 10.8 and

$ size -A /bin/systemd

shows

.text 545634 4231504

on Ubuntu 14.10, both x86-64, so there appears to be a bit more code in PID 1 on a systemd-equipped Linux distribution than in PID 1 of a launchd-equipped OS X release. (Both are dynamically linked with system libraries.)

What things other than that does the program whose executable code is stored in /bin/systemd, and that runs as the first userland process on the system, do (other than, say, restarting tasks)?

The features discussed by this article aren't implemented in a program that runs with a PID of 1.

I wish a different name had been chosen for the project that includes, as one of its components, an init daemon named "systemd"; it probably would have avoided some bad press and confusion.

Perhaps those other components were designed under the assumption that the daemon named "systemd" would start them, tying them to that daemon, so maybe that's the rationale for calling the project "systemd" (or "SystemD").

"VME" can refer either to the VME operating system or the VMEbus.

Presumably you're using hyperbole to say "they're old"; back in the late 1960s, a system based on modified System/360's was installed, and those were at least two generations of IBM computer away from vacuum tubes. Those have been replaced at least a couple of times since then.

Thank Doug Gwyn for that one - he pushed that in ANSI C so that it could handle leap seconds.

(And I pushed for leap-second-capable time in POSIX, but they didn't go for it.)

Yup, there's no guarantee that, if you calculate the number of seconds between "right now" and YYYY-MM-DD HH:MM:SS, whether that's local time or UTC, that will be the number of seconds in the future when YYYY-MM-DD HH:MM:SS will actually happen.

I wonder how many calendar programs cope with that.

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.

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

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.

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

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