My point is that I'm not sure what the heck "Maybe the linux crowd will catch on someday." has to do with ROOT, given that their Web site indicates that it's supported on at least one RHEL6-based distribution and is available in source form that, apparently, can be built and installed on Linux. What is it that "the linux crowd" is being urged to "catch on" to? ROOT? Most of the Linux crowd and the OS X crowd and the Solaris crowd and the Windows crowd probably don't know about it, so I'm not sure why it's specifically the Linux crowd that needs to "catch on".
I like Macs but I would be concerned about they're being so ``closed''. Need more onboard disk space? You need to buy another Mac. (I'm talking about the ``Airs''; not sure about the bigger, more expensive models.)
They're (almost) all SSD now, but OWC has upgrades, including for the Air. I don't know what the upgrade would do for your warranty, however, but suspect "void it" might be the answer.
Use what the big boys/girls use: ROOT https://root.cern.ch/ , includes a C++ interpreter. Most excellent, even for non-physics. Maybe the linux crowd will catch on someday.
However, we don't use them in a Mac-like fashion, but rather install XQuartz and use them as unix-like boxes.
Presumably either because the apps you need for your physics work are written for some X11 toolkit, rather than having separate GUI code for Macs and the rest of the UN*X world or using some cross-platform toolkit with native Mac support, or because you're using it as an X terminal for those apps and running the apps on some other machine such as a big compute server.
(Or perhaps you prefer xterm/Konsole/gnome-terminal/fill-in-your-favorite-X11-toolkit-based-terminal-emulator to Terminal.)
Laws of that sort should include, under "income", investment income, not just paycheck income; rich, old, retired people are probably paying their bills with interest income, dividend income, and realized capital gain income.
So if all income is included, the only way to "get away with it" would be to live relatively cheaply, invest heavily in non-dividend-paying stocks, and avoid breaking traffic laws in years where you realize those capital gains you've been accumulating during the years when you've been driving like a bat out of hell.
(Or, if only reported income is included, arrange to make most of your money in the shadow economy.)
I thought Qualcomm only made chips for CDMA digital voice. I didn't know that Qualcomm made data chips for 4G LTE as well.
They make chips for CDMA2000 EV-DO, the "DO" indicating that they're most definitely for data, not just voice. Realizing that cdmaONE/CDMA2000 has no future, they're also making W-CDMA/HSPA and LTE chips.
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.
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.)
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.")
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.
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.
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.)
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.)
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)?
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").
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.
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.
Slashdot Mirror
Because finnish teachers are not unionized at all, right?
As you presumably suspected - or already knew - was the case, they most definitely are unionized.
Sorry, I don't get your point.
My point is that I'm not sure what the heck "Maybe the linux crowd will catch on someday." has to do with ROOT, given that their Web site indicates that it's supported on at least one RHEL6-based distribution and is available in source form that, apparently, can be built and installed on Linux. What is it that "the linux crowd" is being urged to "catch on" to? ROOT? Most of the Linux crowd and the OS X crowd and the Solaris crowd and the Windows crowd probably don't know about it, so I'm not sure why it's specifically the Linux crowd that needs to "catch on".
I like Macs but I would be concerned about they're being so ``closed''. Need more onboard disk space? You need to buy another Mac. (I'm talking about the ``Airs''; not sure about the bigger, more expensive models.)
They're (almost) all SSD now, but OWC has upgrades, including for the Air. I don't know what the upgrade would do for your warranty, however, but suspect "void it" might be the answer.
Use what the big boys/girls use: ROOT https://root.cern.ch/ , includes a C++ interpreter. Most excellent, even for non-physics. Maybe the linux crowd will catch on someday.
"Catch on" as in "use it on something other than the RHEL6-based SLC6, for which they offer a binary download", in case you don't want to install from source?
However, we don't use them in a Mac-like fashion, but rather install XQuartz and use them as unix-like boxes.
Presumably either because the apps you need for your physics work are written for some X11 toolkit, rather than having separate GUI code for Macs and the rest of the UN*X world or using some cross-platform toolkit with native Mac support, or because you're using it as an X terminal for those apps and running the apps on some other machine such as a big compute server.
(Or perhaps you prefer xterm/Konsole/gnome-terminal/fill-in-your-favorite-X11-toolkit-based-terminal-emulator to Terminal.)
After all, rich, old, retired people speed, too.
Laws of that sort should include, under "income", investment income, not just paycheck income; rich, old, retired people are probably paying their bills with interest income, dividend income, and realized capital gain income.
So if all income is included, the only way to "get away with it" would be to live relatively cheaply, invest heavily in non-dividend-paying stocks, and avoid breaking traffic laws in years where you realize those capital gains you've been accumulating during the years when you've been driving like a bat out of hell.
(Or, if only reported income is included, arrange to make most of your money in the shadow economy.)
I thought Qualcomm only made chips for CDMA digital voice. I didn't know that Qualcomm made data chips for 4G LTE as well.
They make chips for CDMA2000 EV-DO, the "DO" indicating that they're most definitely for data, not just voice. Realizing that cdmaONE/CDMA2000 has no future, they're also making W-CDMA/HSPA and LTE chips.
If you're travelling at the speed of light in a vacuum, then the speed at which you're travelling through time is slowed infinitely.
But wave-particle duality also applies to particles traveling slower than c, so it has nothing to do with traveling at light speed.
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....)
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.
I think its outrageous that we honor them by implementing this wonton censorship.
So when has the French government started suppressing Chinese dumplings?
I heard Mickey Mouse is a corporate stooge.
Absolutely not.
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.)
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.")
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.
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.
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.)
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!".
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!"
Although I do note that
shows
on OS X 10.8 and
shows
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.)
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)?
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").
It is a bus and connector specification.
"VME" can refer either to the VME operating system or the VMEbus.
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.
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.