Linus has no experience with c++, and until he does get some experience, he will maintained the c++ ban. Remember, Linus also banned version control for many years. Finally, he got it, and became a great proponent.
I expect that the Go compiler written in Go compiles slower than the Go compiler written in C, however the Go-in-Go compiler is undoubtedly more loved by the devs, which counts for a lot. Over time, it is probable that the optimizer will develop faster in the Go-in-Go version, which if true, means that the Go-in-Go version will ultimately be superior.
Compared to C++, C is a clumsy anachronism. Speaking as a C expert and someone who still writes a lot of it. C is bad news for maintainability and abstraction. Those who insist on denying that end up with sprawling haphazard embarrassments like GTK and Enlightenment.
In any case, the limitations of C are not the issue. The issue is, if a systems language is inappropriate for implementing a compiler for itself, then does it deserve to be taken seriously? It is a matter of proving the worth, power and efficiency of the language. Another advantage for implementing a compiler in its own language is the simple but powerful regression test: can the compiler compile itself so that the result can also compile itself?
As far as C compiling itself goes, GCC won't be doing that any more, it is moving to C++.
When a site seems brokens because it requires flash to render, I rarely "click". Instead, I go somewhere else.
I see that very rarely these days. Used to be, companies like banks would build their sites with flash, probably because the only metric they have for judging is now pretty it is, and they consider lots of annoying animations an asset. Somewhere along the line that changed, not sure what happened, but it's been years since I landed on a website I actually need that has flash menus.
Removing flash is far from refusing to let my kid explore. It's more like "you're not a pig so don't wallow in that shit". Installing humble bundle games is fine.
Cold turkey works. One day I just removed flash from my tween kid's computer, which means no more flash games, causing much weeping and wailing for a few days. The flash games are social networks you see, which is why the kids keep going to those site, not the crappy retro 2D games.
Fringe benefits: the fan on the laptop isn't going all the time now. Ads are less obnoxious and consume less bandwidth. Hours of mind-numbing wastage on useless grinding-type games becomes available for, you know, education. After a few days of complaints, life goes on, and from where I stand, it's a better life without flash.
Time to repeat your test on a high end Broadwell. Also, check that each infiniband card is bound to a dedicated core and that your memory regions are properly NUMA-bound to the respective core. With proper configuration I expect you will be able to run multiple Infiniband cards at full speed (personally, I doubt Infiniband has a future with the industry piling on to RDMAoE, but that's another story).
In any case, there is no fundamental difference in the engineering problem to be solved or the designs used to solve it. Just different tradeoffs for power efficiency and transistor budget, with commodity server CPUs looking more like mainframe processors all the time. Intel goes where the data center mass market is, and because the mass market is galloping in the direction of high IO, Intel will continue to lather on more IO with each generation. AMD likewise of course, to the extent that their monopoly-abused finances permit it. Massive amounts of PCI-connected flash is driving this, for one thing.
I suspect you will find that Broadwell has already closed the IO gap to a small sliver.
...the BIG thing with mainframe I/O is that unlike the PC hardware, there's no single system bus that gets split between devices, instead you have a crap-ton of channels that can all communicate concurrently...
You mean, unlike old PC hardware. Modern AMD hardware has hypertransport and Intel followed with QPI, both point to point serial architectures. The traditional shared bus is now just an emulation.
and the available features for data integrity, encryption etc, which includes checksumming of transfers between devices or between device and RAM etc.
PCI devices (now actually serial-connected) are unrestricted in what they can do. Network hardware has because a lot smarter and does a lot more offload. Disk hardware, not so much, but it's heading in that direction. So basically the same thing, which should be no surprise. Updated and subject to stronger evolutionary selection.
These days, mainframe peripherals are much like any other... high end EMC or HDS gear or the like, 10G or 40G ethernet and possibly fiberchannel (dinosaur still walking the earth). Interconnect on the mainframe would be better in general than high end rack mount servers, a modest advantage but not enough to justify the cost. Availability is the trump card.
...of all the things that Linux isn't designed for, is a mainframe OS, because either the mainframe hardware will have to be changed to support Linux's "view" of the world, or Linux has to get a ton of drivers.
Now I'm stumped by your comment. Linux has no problem with "a ton of drivers", but the fact is, only a few drivers are actually needed.
I understand IBM's mainframe division is trying to stay relevant, but they need to focus on getting people to use a mainframe, not trying to make a mainframe act as a PC.
What makes you think Linux makes a mainframe act as a PC? Linux runs on many disparate architectures, some of which look very little like a PC. Sure, Linux forces every architecture to present a page table abstraction derived historically from intel's model, but is that is mainly because that simple model makes sense, and not particularly inefficient for architectures with a different approach to emulate it. Other than that, life in mainframe land is much like any other architecture, especially now that with virualization rampant, everything looks a lot more like a mainframe inside today.
Things like lockstep CPUs and such, leave that to the hypervisor, and let Linux view it as one CPU in/proc unless there are critical exceptions that need to be passed to the client OS.
Why would you think it works any differently than that?
However, what really needs to be done is sell what a mainframe does best, and that is reliability.
How do you imagine IBM sells mainframes? There was a time when customers had a lot of idle capacity siting around that could be recycled as Linux servers, but now IBM's only compelling argument is reliability. But that argument is a cruncher for some customers.
What IBM needs to do is have a case for having the hardware be expensive and reduce the number of man-hours needed to be put in to code a solution.
The mainframe proposition is not about maintenance cost, it is about the business cost of even temporary interruption or failure.
Yeah, I'm sort of failing to see the point here as well - running your classic z/OS backend stuff and then having a few zIFLs talking to the backend over HiperSockets (IIRC) made sense, but just a big zSeries box with no way to run legacy apps?
It seems apparent that there now exists a significant market segment that only cares about Linux serving and not legacy mainframe apps.
Linux on a Mainframe is a neat party trick, but it doesn't really make a lot of sense.
That "party trick" is generally credited for reviving IBM's mainframe business.
Modern Z Series hardware is heavily derived from Power. Why not just run Power Linux? Mainframe I/O design is intentionally about as un-PDP-like as possible, so it's a bad match for Unix, Linux, or even Windows for that matter (NT ran on MIPS, so it theoretically could be ported to S/390).
Not sure what you're concerned about. Linux sees the mainframe hardware through drivers like any other architecture. Who cares if the DASD driver using a channel is organized differently from a memory mapped driver for some other arch? It just looks like a block driver to the rest of the kernel.
Mainframes get their performance by pushing computation into the channel controllers, and while you could do something like that in Linux, are any of your applications ready to treat your database like a device driver?
Even more puzzled by this comment. S390 applications never need to bother with channel controllers or know they exist.
Because that's what you'll have to do.
I doubt it.
And, incidentally, it's why every attempt from AIX/370 to Linux on Z Series has required virtualization and a ton of independent kernels to get anything resembling decent performance.
Citation needed.
And that's where Dell will come in and put thousands of cores in a 42U rack for you... No, IBM's own P Series is a better idea, and their former x86 division (now Lenovo) looks even better.
IBM covers the whole spectrum of form factors. For some customers, fewer individual boxes looks like a great idea.
If you are not just a blathering asshole (which I doubt) then please explain to me the process by which the application goes from "corrupted" to "terminated". (The fact that you believe the difference between "corrupt" and "terminated" to be "obtuse" already says everything we need to know about you.)
I have never seen an application terminated on Linux due to a suspend cycle.
I have, XFCE for example and also in situations where a large amount of GPU and system memory is being used where it doesn't seem to save the entire system state in RAM so the application state is corrupted on resume.
He said "find out half your apps got forcefully terminated because they couldn't fit in swap space", so I will call you an anonymous asshole because your post has little to do with the original (bogus sounding) claims. Application state corrupted is not the same application terminated, even if either claim is based on real experience, which is doubtful.
Don't bother reading if you expect to see any technical insight. The article summary is "oh gosh gee whiz it's so gosh darn fast" followed by a dump about all kinds of amazing things a really fast data link might enable.
Suspend and hibernate work great for me on Windows... Linux on the other hand requires all sorts of kernel and bootloader changes, plus god forbid you use a lot of memory to start with, and find out half your apps got forcefully terminated because they couldn't fit in swap space.
You're talking out of your ass. I have never seen an application terminated on Linux due to a suspend cycle. Suspend does not require bootloader changes. I strongly suspect that you pulled the "all sorts of kernel" thing out of your ass, and that you have zero experience with suspend on Linux, and quite possibly zero experience with Linux at all (except perhaps on the half dozen embedded devices in your home that run it and you don't even know). Obvious scumsucking troll regurgitating a bag of buzzwords.
My wife and I both have Lumia 635s now, neither of us were coerced into buying them. They're refreshingly 'clean' compared to Android phones, and were only $70...
Case in point. Take the same hardware, load Android, stick an LG label on it, and sell it for $150. See, Microsoft can't sell phones, they can only give them away.
Slashdot Mirror
Linus has no experience with c++, and until he does get some experience, he will maintained the c++ ban. Remember, Linus also banned version control for many years. Finally, he got it, and became a great proponent.
If you think that decent memory management is the only reason to use c++ then you certainly do not get it.
Greek town switched to LibreOffice
Methinks Microsoft has observed significant penetration by open course office suites and is ramping up for a PR war.
I expect that the Go compiler written in Go compiles slower than the Go compiler written in C, however the Go-in-Go compiler is undoubtedly more loved by the devs, which counts for a lot. Over time, it is probable that the optimizer will develop faster in the Go-in-Go version, which if true, means that the Go-in-Go version will ultimately be superior.
No, BASH. If you're going to go ugly, go all the way.
Compared to C++, C is a clumsy anachronism. Speaking as a C expert and someone who still writes a lot of it. C is bad news for maintainability and abstraction. Those who insist on denying that end up with sprawling haphazard embarrassments like GTK and Enlightenment.
In any case, the limitations of C are not the issue. The issue is, if a systems language is inappropriate for implementing a compiler for itself, then does it deserve to be taken seriously? It is a matter of proving the worth, power and efficiency of the language. Another advantage for implementing a compiler in its own language is the simple but powerful regression test: can the compiler compile itself so that the result can also compile itself?
As far as C compiling itself goes, GCC won't be doing that any more, it is moving to C++.
Recent versions of Firefox and Chrome show you which tabs are playing media.
When a site seems brokens because it requires flash to render, I rarely "click". Instead, I go somewhere else.
I see that very rarely these days. Used to be, companies like banks would build their sites with flash, probably because the only metric they have for judging is now pretty it is, and they consider lots of annoying animations an asset. Somewhere along the line that changed, not sure what happened, but it's been years since I landed on a website I actually need that has flash menus.
Removing flash is far from refusing to let my kid explore. It's more like "you're not a pig so don't wallow in that shit". Installing humble bundle games is fine.
Cold turkey works. One day I just removed flash from my tween kid's computer, which means no more flash games, causing much weeping and wailing for a few days. The flash games are social networks you see, which is why the kids keep going to those site, not the crappy retro 2D games.
Fringe benefits: the fan on the laptop isn't going all the time now. Ads are less obnoxious and consume less bandwidth. Hours of mind-numbing wastage on useless grinding-type games becomes available for, you know, education. After a few days of complaints, life goes on, and from where I stand, it's a better life without flash.
Time to repeat your test on a high end Broadwell. Also, check that each infiniband card is bound to a dedicated core and that your memory regions are properly NUMA-bound to the respective core. With proper configuration I expect you will be able to run multiple Infiniband cards at full speed (personally, I doubt Infiniband has a future with the industry piling on to RDMAoE, but that's another story).
In any case, there is no fundamental difference in the engineering problem to be solved or the designs used to solve it. Just different tradeoffs for power efficiency and transistor budget, with commodity server CPUs looking more like mainframe processors all the time. Intel goes where the data center mass market is, and because the mass market is galloping in the direction of high IO, Intel will continue to lather on more IO with each generation. AMD likewise of course, to the extent that their monopoly-abused finances permit it. Massive amounts of PCI-connected flash is driving this, for one thing.
I suspect you will find that Broadwell has already closed the IO gap to a small sliver.
You have it right. In particular, cpus may be connected to to other cpus by hypertransport, implementing SMP
...the BIG thing with mainframe I/O is that unlike the PC hardware, there's no single system bus that gets split between devices, instead you have a crap-ton of channels that can all communicate concurrently...
You mean, unlike old PC hardware. Modern AMD hardware has hypertransport and Intel followed with QPI, both point to point serial architectures. The traditional shared bus is now just an emulation.
and the available features for data integrity, encryption etc, which includes checksumming of transfers between devices or between device and RAM etc.
PCI devices (now actually serial-connected) are unrestricted in what they can do. Network hardware has because a lot smarter and does a lot more offload. Disk hardware, not so much, but it's heading in that direction. So basically the same thing, which should be no surprise. Updated and subject to stronger evolutionary selection.
These days, mainframe peripherals are much like any other... high end EMC or HDS gear or the like, 10G or 40G ethernet and possibly fiberchannel (dinosaur still walking the earth). Interconnect on the mainframe would be better in general than high end rack mount servers, a modest advantage but not enough to justify the cost. Availability is the trump card.
Reliability.
...of all the things that Linux isn't designed for, is a mainframe OS, because either the mainframe hardware will have to be changed to support Linux's "view" of the world, or Linux has to get a ton of drivers.
Now I'm stumped by your comment. Linux has no problem with "a ton of drivers", but the fact is, only a few drivers are actually needed.
I understand IBM's mainframe division is trying to stay relevant, but they need to focus on getting people to use a mainframe, not trying to make a mainframe act as a PC.
What makes you think Linux makes a mainframe act as a PC? Linux runs on many disparate architectures, some of which look very little like a PC. Sure, Linux forces every architecture to present a page table abstraction derived historically from intel's model, but is that is mainly because that simple model makes sense, and not particularly inefficient for architectures with a different approach to emulate it. Other than that, life in mainframe land is much like any other architecture, especially now that with virualization rampant, everything looks a lot more like a mainframe inside today.
Things like lockstep CPUs and such, leave that to the hypervisor, and let Linux view it as one CPU in /proc unless there are critical exceptions that need to be passed to the client OS.
Why would you think it works any differently than that?
However, what really needs to be done is sell what a mainframe does best, and that is reliability.
How do you imagine IBM sells mainframes? There was a time when customers had a lot of idle capacity siting around that could be recycled as Linux servers, but now IBM's only compelling argument is reliability. But that argument is a cruncher for some customers.
What IBM needs to do is have a case for having the hardware be expensive and reduce the number of man-hours needed to be put in to code a solution.
The mainframe proposition is not about maintenance cost, it is about the business cost of even temporary interruption or failure.
Yeah, I'm sort of failing to see the point here as well - running your classic z/OS backend stuff and then having a few zIFLs talking to the backend over HiperSockets (IIRC) made sense, but just a big zSeries box with no way to run legacy apps?
It seems apparent that there now exists a significant market segment that only cares about Linux serving and not legacy mainframe apps.
Linux on a Mainframe is a neat party trick, but it doesn't really make a lot of sense.
That "party trick" is generally credited for reviving IBM's mainframe business.
Modern Z Series hardware is heavily derived from Power. Why not just run Power Linux? Mainframe I/O design is intentionally about as un-PDP-like as possible, so it's a bad match for Unix, Linux, or even Windows for that matter (NT ran on MIPS, so it theoretically could be ported to S/390).
Not sure what you're concerned about. Linux sees the mainframe hardware through drivers like any other architecture. Who cares if the DASD driver using a channel is organized differently from a memory mapped driver for some other arch? It just looks like a block driver to the rest of the kernel.
Mainframes get their performance by pushing computation into the channel controllers, and while you could do something like that in Linux, are any of your applications ready to treat your database like a device driver?
Even more puzzled by this comment. S390 applications never need to bother with channel controllers or know they exist.
Because that's what you'll have to do.
I doubt it.
And, incidentally, it's why every attempt from AIX/370 to Linux on Z Series has required virtualization and a ton of independent kernels to get anything resembling decent performance.
Citation needed.
And that's where Dell will come in and put thousands of cores in a 42U rack for you... No, IBM's own P Series is a better idea, and their former x86 division (now Lenovo) looks even better.
IBM covers the whole spectrum of form factors. For some customers, fewer individual boxes looks like a great idea.
If you are not just a blathering asshole (which I doubt) then please explain to me the process by which the application goes from "corrupted" to "terminated". (The fact that you believe the difference between "corrupt" and "terminated" to be "obtuse" already says everything we need to know about you.)
What inability to understand how suspend works, asshole?
I have never seen an application terminated on Linux due to a suspend cycle.
I have, XFCE for example and also in situations where a large amount of GPU and system memory is being used where it doesn't seem to save the entire system state in RAM so the application state is corrupted on resume.
He said "find out half your apps got forcefully terminated because they couldn't fit in swap space", so I will call you an anonymous asshole because your post has little to do with the original (bogus sounding) claims. Application state corrupted is not the same application terminated, even if either claim is based on real experience, which is doubtful.
Don't bother reading if you expect to see any technical insight. The article summary is "oh gosh gee whiz it's so gosh darn fast" followed by a dump about all kinds of amazing things a really fast data link might enable.
Suspend and hibernate work great for me on Windows... Linux on the other hand requires all sorts of kernel and bootloader changes, plus god forbid you use a lot of memory to start with, and find out half your apps got forcefully terminated because they couldn't fit in swap space.
You're talking out of your ass. I have never seen an application terminated on Linux due to a suspend cycle. Suspend does not require bootloader changes. I strongly suspect that you pulled the "all sorts of kernel" thing out of your ass, and that you have zero experience with suspend on Linux, and quite possibly zero experience with Linux at all (except perhaps on the half dozen embedded devices in your home that run it and you don't even know). Obvious scumsucking troll regurgitating a bag of buzzwords.
If you want politeness, make all public bug reports go through company representatives.
I reject your implied proposition that engineers are incapable of being polite.
My wife and I both have Lumia 635s now, neither of us were coerced into buying them. They're refreshingly 'clean' compared to Android phones, and were only $70...
Case in point. Take the same hardware, load Android, stick an LG label on it, and sell it for $150. See, Microsoft can't sell phones, they can only give them away.