Slashdot stories can be listened to in audio form via an RSS feed, as read by our own robotic overlord.

 



Forgot your password?
typodupeerror

Comment: Re:Ctrl-f POSIX; not found (Score 1) 551

by Guy Harris (#48833465) Attached to: Systemd's Lennart Poettering: 'We Do Listen To Users'

Simply put, systemd DOES NOT hold up to POSIX scrutiny.

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

Comment: Re:Mainframe vs PaaS and SaaS (Score 1) 164

by Guy Harris (#48826787) Attached to: The Mainframe Is Dead! Long Live the Mainframe!

The link in the post above yours provides a good discussion. What you say is correct, it appears as 2 processors. However it does not provide the performance of 2 processors, but has about a 40% increase over 1 processor. This means that neither thread is running at full speed. Much mainframe workload depends on fast uniprocessing, so slowing down a thread by using SMT is not desirable in those situations. Therefore, zOS would have to specifically allow certain jobs to use SMT.

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

Comment: Re:2.5 billion transactions a day (Score 1) 164

by Guy Harris (#48826465) Attached to: The Mainframe Is Dead! Long Live the Mainframe!

Mainframes do have one cool thing going for them that is not respected on smaller machines - portability. There's code that's been in use for several decades on mainframes running in a stack of emulators. Each new mainframe gets an emulator to make it possible to act just like an an old mainframe.

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.

Comment: Re:Mainframe vs PaaS and SaaS (Score 1) 164

by Guy Harris (#48826383) Attached to: The Mainframe Is Dead! Long Live the Mainframe!

The reason that this is the first mainframe with SMT is simple. Prior to the previous generation (z12), most mainframe workload was z/OS, and z/OS has no support for SMT.

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.

Comment: Re:Mainframe vs PaaS and SaaS (Score 1) 164

by Guy Harris (#48826325) Attached to: The Mainframe Is Dead! Long Live the Mainframe!

This is the first IBM mainframe that has had the ability to run multiple instructions at once on a single core the way Intel chips have done for many years now.

Eh... No. The Z196 processor (2010) implements superscalarity (5 wide, 3 decode) and out of order execution at 5.2GHz. The Z12 processor (2012) have 7 wide execution and runs at 5.5GHz. They are top of the line products.

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

Comment: Re:Installed systemd--What happened next was amazi (Score 1) 553

by Guy Harris (#48816169) Attached to: SystemD Gains New Networking Features

That's the kind of clickbait subjects/headlines Slashdot needs to start using in addition to clickbait topics...

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

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

Comment: Re:Fuck Me (Score 1) 553

by Guy Harris (#48815775) Attached to: SystemD Gains New Networking Features

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

Comment: Re:Fuck Me (Score 1) 553

by Guy Harris (#48815707) Attached to: SystemD Gains New Networking Features

I try to stay out of the systemd fray... but it goes against the core of UNIX... which is the KISS principle.

Init should start tasks, possibly stick them into jails or containers, and set resource limitations. Having something do everything including the kitchen sink is just asking to get hacked down the road unless millions of dollars are spent on source code audits.

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

Comment: Re:Fuck Me (Score 4, Informative) 553

by Guy Harris (#48815675) Attached to: SystemD Gains New Networking Features

Apparently, you're the idiot, because the fact that systemD integrates itself so closely with my GNU^H^H^HSystemD/Linux as PID 1

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

Comment: Re:Modern Technology (Score 1) 189

the air traffic control systems until very recently ran on vacuum tube computers,

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.

Comment: Re:Fix NTP (Score 2) 289

by Guy Harris (#48750247) Attached to: Extra Leap Second To Be Added To Clocks On June 30

Yes you are right, I had forgotten just how broken POSIX time is. Completely unfixable.

Which is stupid, because struct tm actually supports leap seconds and even (despite them not being possible) double leap seconds.

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

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

This bit you already have to handle due to daylight savings and time zone changes. If the user inputs a local date and time for a particular event, it is NOT valid to convert and store that as seconds after the epoch. That conversion can change anytime.

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.

Comment: Re:Fix NTP (Score 2) 289

by Guy Harris (#48749825) Attached to: Extra Leap Second To Be Added To Clocks On June 30

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.

I'd rather be led to hell than managed to heavan.

Working...