Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Comment: Re:Big Data (Score 1) 439

by Guy Harris (#49057769) Attached to: Will Submarines Soon Become As Obsolete As the Battleship?

How much credibility does this article lose once you put "Big Data" in there?

Would suggesting the use of Big Data gathered from cloud-based mobile social apps help its credibility?

Or am I just proactively leveraging my synergies here?

(Sounds like some detection technology is in play here....)

Comment: Re:Felony o' Clock? (Score 2) 50

by Guy Harris (#49022011) Attached to: Rich Olson Embodies the Spirit of the Maker Movement (Video)

An alarm clock that shreds money? I'm pretty sure that destruction of legal tender is a somewhat serious crime.

Cutting US currency is a crime, but not all that serious a crime - a fine or imprisonment of not more than six months isn't exactly hard time.

Your mileage will vary with other nations' currency (vary from "shred all the Canadian bills you want" to "it's OK to shred some Euro notes privately" to "we're not sure whether it's OK to shred Brazilian real notes" to "no, you may not shred {Australian dollars, New Zealand dollars}".

Whether the Long Arm Of The Law will bother reaching out and touching you if your alarm clock shreds a few bills is another matter.

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

To be a kind of moral Unix, he touched the hem of Nature's shift. -- Shelley

Working...