I think it would be pretty hard to use Hercules as a hot-backup. It can't even drive the real IO (DASD).
Not true at all. While an Intel Server, even a high-powered one might not be able to drive the same throughput as a late-model mainframe (no, that's not an oxymoron), there are plenty of older mainframes out there (I have an acquaintance that as of just a couple of years ago was still running an IBM 4300 series mainframe) that might even see an increase in performance. And if Hercules is to be used as a DR solution, then performance is less critical as many businesses only need DR for their core business systems, not the entire application portfolio.
You are incorrect in your differentiating hardware from software here. IBM mainframe processors (going all the way back to S/370 at least) are micro-coded processors. (I actually still have a box containing a microfiche copy of the microcode for a 370/148). This means that while there is definitely some proprietary hardware executing, the instruction set is 100% implemented in software which runs on the special purpose hardware. In a very real way, the very same instruction set that Hercules emulates, is in reality implemented as an emulator on IBM's hardware.
In any case, I do find IBM's tack here a bit ridiculous. I mean c'mon, what micro-percentage of potential sales are possibly being lost the the Hercules emulator? I've been a user of Hercules going way back (and A370 before that!). I don't use it for any real work - but I like to occasionally go back and refresh my old skill set (I was an MVS SysProg years ago). Today I spend 98% of my time doing S/D in Java and C# on Unix and Windows, but every once in a while I get called in to do something on a mainframe (and no, it doesn't pay any better than my Java/C# work). Hercules is by far the most complete S/390 emulator out there and I'm grateful for folks like Jay and Roger (Fish, Volker and the rest of the regulars) who give freely of their efforts and time to allow old farts like me to experience the thrill of bringing up an MVS or VM/370 system on our very own system (something you young whippersnappers probably just can't understand).
What you are missing (as are most of the posters so far) is that there is considerable overhead involved in the actual management of the memory in terms of keeping track of what memory is free or allocated. This is outside the issue of maintaining locks. Moving this management overhead to a separate thread allows the otherwise single threaded app to take advantage of additional cores without any code changes. This does not appear all that novel however as modern garbage collectors do this today.
Guess if he would have laid down his pipe, maybe he would have found the Grand Unified Theory. GMAFB Smoking is bad, no doubt - but there are too many examples of geniuses that smoked for me to buy this. Sounds like propaganda to me - but if it stops X percent of people from starting smoking, the I guess there's no harm done.
Wow, I've seen some arrogant and pompous posts on./ but this one strikes such a tone of condescension that it demanded at least as much scrutiny as apparently you applied to the parent.
Most of the benefits offered by Java are those bestowed upon an application by virtue of running in the Java Runtime Environment (JRE), including automatic memory management (garbage collection), strong exception handling
Umm, no. While the JRE provides the aforementioned facilities, I hardly think they are "bestowed upon an application by virtue of running in the Java Runtime Environment (JRE)". Garbage collection has been available for years in add on libraries for C++ - guess what? - No JRE!
Strong exception handling? - C++ has had that for years - again with no JRE!
Granted, the (sandboxed code execution) could only be provided through a JRE of some sort, but security controls ?. What the hell is that? If you are referring to bytecode verification, then why not say so.
And what about dynamic class generation? This is a language feature. While most languages that support introspection or dynamic binding (which is what I believe you are referring to here - again you weren't clear) are implemented on top of a runtime of some sort, it's certainly possible to implement this without a runtime environment (ever heard of SOM?).
I'm a long time Java advocate and I almost have to hold my nose when I have to develop in other languages (although I find C# close enough to be somewhat tolerable), so my intent is not to argue what I believe was the main point of your post, but personally attacking those that are misinformed does nothing to further the case for Java; rather it make Java advocates come across as rude and arrogant.
Why would you need to have an internet connection to the grid? Do you really need the ability to shut off the power to a city or or country? I think not. You're local power utility, which controls the power going to your house (called a distribution organization) is who you need to interact with. The grid is within the realm of a different organization a (called a transmission organization). These organizations deal with the transmission of large amounts of power between cities, states, counties and such. You local power company buys it's power from them. In other words, they manage the trading of power between companies. I see no need for an individual to have any access to their infrastructure at all.
I have a great way to protect the power grid against cyber-attacks: Don't connect it to the internet!
Nothing on the grid is, or will be connected to the Internet. Yes, you may find it amazing, but the IT folks in the energy sector have already figured this out, even without your advice! Duh..
However, if you think that's all it takes to secure the grid you're even more naive than you sound.
All of the transmission organizations I've worked with have their grid networks completely isolated from their "business" networks that may have some external connectivity. Most won't even allow a simple serial (as in RS-232) wire connection between these systems to transfer data (it's a royal pain when we need to get data from one network to the other and usually involves some form of sneaker-net).
The problem is that even that level of isolation does not guarantee that these systems can't get hacked into. Some of the equipment on the grid is ancient and the cost to upgrade to something modern is cost prohibitive. Contrary to what most people think, power companies are tightly regulated by public utility commissions. They can't raise rates willy-nilly, so expensive upgrades usually don't get approved. Local politicians don't want their constituents pissed off because they approved a rate increase to enhance the infrastructure.
This is going to be a tough nut to crack and I for one am glad to see that this threat is finally being taken seriously.
Whether anything comes of it will remain to be seen.
Perhaps you should study up a little on OS design. Task switching absolutely does occur in a threaded model. When the OS scheduler interrupts a "task" (whether it be a thread or a process - and this includes Grand Central tasks) because it's time-slice has expired or for any other number of reasons, the OS (assisted by microcode in the CPU) saves the state of the processor (PSW, registers, etc.), restores the state of the next task to be dispatched and begins processing the new task. This all happens many times per second and gives the appearance of multiple threads running in parallel. The only difference between the way this works on a single core or multi-core processor is that the scheduler "may" dispatch the task (or task, or process - whichever term you prefer) on a different core than the one it was interrupted from. Grand Central is no different. The ONLY real difference from an OS perspective is that GC "tasks" are lighter weight than threads, as threads are lighter weight than processes. By lighter weight, I'm referring to the amount of information that must be saved and restored during task switching operations. Before you start climbing on your soapbox impuning other's knowledge you should gain a little knowledge yourself.
If all it was doing was task switching, it wouldn't be able to make use of parallel cores.
Need I say more? I think I will.
Sure. If you manually make use of the threading tools.... you do not have to do that on a Mac
I'm sorry, but I'm not buying. Applications have to be structured to take advantage of parallelism and no simple tweaks to a language (any language) will turn a single threaded application into a parallel processing application. It just doesn't work that way. I worked with ADA 20 years ago and it had extensive support for concurrency, but unless you structured your application to run in parallel this feature was useless. One final point. OS X is a derivative of FreeBSD and NetBSD. These are Unix OS's and all support the same basic multi-tasking model, and Windows is functionally the same as well. An argument can be made as to which system has the best scheduler, dispatcher, etc., but all in all they pretty much do the same thing. All Apple is really doing here is layering another API on top of the regular threading model and adding some syntactic sugar to C++ and Obj-C (thereby making applications non-portable). I'm glad you are so enthralled with GCD and I hope you enjoy your Mac world. I prefer to work in less proprietary worlds (yes, even Windows is far more open than OS X - as amazing that seems).
This sounds like the same argument I had with my boss 30 years ago. He wouldn't believe that microprocessors would one day obsolete the mainframes. He reasoned that no matter how powerful microprocessors got, mainframes would always stay well ahead of them. To my thinking, when it comes to electronics (both in speed and capacity), the distance between circuits begins to matter a lot when your working at the speed of light on a nanometer scale. There is abosolutely no way, in the long run, mechanical devices of any type will be able to stay ahead of purely electronic devices. Actually I'm surprised it's taken this long to get to this point. Costs will come down (I can pick up an 8GB thumbdrive for about $20 as opposed to the 8GB harddrive I paid $150 for about 10 years ago). Spinning drives still have a few years left, but the writing is on the wall.
Software is different. I still hear stories of folks running autocoder programs! Hardware will most definitely eventually die, and when it does, it will get replaced by the most cost effective hardware available.
one has ever given me an answer as to why my money has to go to pay the medical bills of my neighbor who smokes half a pack a day, or my neighbor on the other side who thinks it's funny to drink a case of beer each weekend by themselves.
For the same reason I have to pay for Oil companies to protect their interests in Iraq, or the same reason I have to pay for public schools when I send my kids to private schools. I tend to be libertarian in my views, but if I had to start a list of basic services that my government should provide, I would think health care would be at the top of the list, certainly above funding for bank bailouts (thank you GWB). And when it comes to something as basic as the ability to see a doc when you get sick (people who don't drink or smoke get sick too!), a system that is set up to maximize profit at the expense of human suffering (which we have now) is completely immoral and even contrary to the founding father's intent (isn't Life the first of our unalienable rights as stated in the declaration of independence? - We hold these truths to be self-evident, that all men are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness.)
But as more cores come around it will eventually be the only practical way to go.
Great! I didn't realize that one of the greatest challenges of software engineering has been solved, by Apple no less! Maybe Apple can now turn to solving the issues in quantum computing! GMAFB! Grand Central is at best an elegant solution for a narrow class of (simple, somewhat parallel processing) problems. All it really does is abstract the concept of threads away into "tasks" which are managed by the OS rather than the programmer. This will not complete solve the problem any more than garbage collection completely solves memory management problems. The CPU still has to switch contexts between these tasks although the overhead of tasks is less than that of true threads, it's simple a (possibly) more efficient implementation of the same old concept of task switching that's been around for decades (although I'm sure Apple will try and patent it as if it's something totally new). Similar reimplementation of threading are available or being worked on in other environments as well (Java - JSR 166,.Net - TPL, OpenMP and others). However, none of these approaches are going to yield efficient use of massively parallel systems when they become commonplace. There will have to be a major paradigm shift in the way applications are developed in order to take advantage of these systems for general purpose computing.
I believe the Jaguar - Cray XT5-HE has about 225,000 cores... IBM's BlueGene nearly 300,000 cores. Yea, give each app it's own CPU - then what do we do with the other 299,990 cores?
You can try porting the entire system over to a virtual machine, using dd to copy the entire system, then booting it up in qemu...
Here's a link to someone who's had success with this approach...
http://virtuallyfun.blogspot.com/2007/05/running-xenix-on-qemu.html
Good luck!
Seriously... I hope they all eat each other alive so that open-source is the only reasonable way to produce software. I've seen too much greed and infighting over "Master of the Universe" status for too long.
if NetBeans or Eclipse were taken up to the quality and usefulness of Visual Studio then that'd be awesome.
Huh? You're kidding right?
I use Eclipse and VS all day long every day. IMHO, Eclipse is far and away the better IDE any way you slice it. It also talks to everything and it doesn't cost thousands of dollars (yea, I know there's an Express edition, but if you intend to do Enterprise development you better be ready to take out a loan).
Eclipse gets slammed a lot for it's supposed "diabolical" UI, but I just don't get that. It feels perfectly natural to me and organized just the way I would expect it to be. I can grab a new plugin as needed for additional language support and everything works the same as other language support. I don't need to spend days scratching my head or reading books to know how to use a new feature, it just works as I expect it to. To each their own I guess.
Slashdot Mirror
I think it would be pretty hard to use Hercules as a hot-backup. It can't even drive the real IO (DASD).
Not true at all. While an Intel Server, even a high-powered one might not be able to drive the same throughput as a late-model mainframe (no, that's not an oxymoron), there are plenty of older mainframes out there (I have an acquaintance that as of just a couple of years ago was still running an IBM 4300 series mainframe) that might even see an increase in performance.
And if Hercules is to be used as a DR solution, then performance is less critical as many businesses only need DR for their core business systems, not the entire application portfolio.
You are incorrect in your differentiating hardware from software here.
.
IBM mainframe processors (going all the way back to S/370 at least) are micro-coded processors. (I actually still have a box containing a microfiche copy of the microcode for a 370/148). This means that while there is definitely some proprietary hardware executing, the instruction set is 100% implemented in software which runs on the special purpose hardware. In a very real way, the very same instruction set that Hercules emulates, is in reality implemented as an emulator on IBM's hardware.
In any case, I do find IBM's tack here a bit ridiculous. I mean c'mon, what micro-percentage of potential sales are possibly being lost the the Hercules emulator?
I've been a user of Hercules going way back (and A370 before that!). I don't use it for any real work - but I like to occasionally go back and refresh my old skill set (I was an MVS SysProg years ago). Today I spend 98% of my time doing S/D in Java and C# on Unix and Windows, but every once in a while I get called in to do something on a mainframe (and no, it doesn't pay any better than my Java/C# work).
Hercules is by far the most complete S/390 emulator out there and I'm grateful for folks like Jay and Roger (Fish, Volker and the rest of the regulars) who give freely of their efforts and time to allow old farts like me to experience the thrill of bringing up an MVS or VM/370 system on our very own system (something you young whippersnappers probably just can't understand)
Having said that - now get off my lawn!
the age old technique of screen-scraping, only probably a lot more error prone (if that's possible).
What you are missing (as are most of the posters so far) is that there is considerable overhead involved in the actual management of the memory in terms of keeping track of what memory is free or allocated. This is outside the issue of maintaining locks. Moving this management overhead to a separate thread allows the otherwise single threaded app to take advantage of additional cores without any code changes. This does not appear all that novel however as modern garbage collectors do this today.
I have a graph in my head that pops up every time I see someone smoking.
Sounds like someone has some issues of their own :)
Guess if he would have laid down his pipe, maybe he would have found the Grand Unified Theory.
GMAFB
Smoking is bad, no doubt - but there are too many examples of geniuses that smoked for me to buy this.
Sounds like propaganda to me - but if it stops X percent of people from starting smoking, the I guess there's no harm done.
Most of the benefits offered by Java are those bestowed upon an application by virtue of running in the Java Runtime Environment (JRE), including automatic memory management (garbage collection), strong exception handling
Umm, no. While the JRE provides the aforementioned facilities, I hardly think they are "bestowed upon an application by virtue of running in the Java Runtime Environment (JRE)". Garbage collection has been available for years in add on libraries for C++ - guess what? - No JRE!
Strong exception handling? - C++ has had that for years - again with no JRE!
Granted, the (sandboxed code execution) could only be provided through a JRE of some sort, but security controls ?. What the hell is that? If you are referring to bytecode verification, then why not say so.
And what about dynamic class generation? This is a language feature. While most languages that support introspection or dynamic binding (which is what I believe you are referring to here - again you weren't clear) are implemented on top of a runtime of some sort, it's certainly possible to implement this without a runtime environment (ever heard of SOM?).
I'm a long time Java advocate and I almost have to hold my nose when I have to develop in other languages (although I find C# close enough to be somewhat tolerable), so my intent is not to argue what I believe was the main point of your post, but personally attacking those that are misinformed does nothing to further the case for Java; rather it make Java advocates come across as rude and arrogant.
Why would you need to have an internet connection to the grid? Do you really need the ability to shut off the power to a city or or country? I think not. You're local power utility, which controls the power going to your house (called a distribution organization) is who you need to interact with. The grid is within the realm of a different organization a (called a transmission organization). These organizations deal with the transmission of large amounts of power between cities, states, counties and such. You local power company buys it's power from them. In other words, they manage the trading of power between companies. I see no need for an individual to have any access to their infrastructure at all.
I have a great way to protect the power grid against cyber-attacks: Don't connect it to the internet!
Nothing on the grid is, or will be connected to the Internet. Yes, you may find it amazing, but the IT folks in the energy sector have already figured this out, even without your advice! Duh..
However, if you think that's all it takes to secure the grid you're even more naive than you sound.
All of the transmission organizations I've worked with have their grid networks completely isolated from their "business" networks that may have some external connectivity. Most won't even allow a simple serial (as in RS-232) wire connection between these systems to transfer data (it's a royal pain when we need to get data from one network to the other and usually involves some form of sneaker-net).
The problem is that even that level of isolation does not guarantee that these systems can't get hacked into. Some of the equipment on the grid is ancient and the cost to upgrade to something modern is cost prohibitive. Contrary to what most people think, power companies are tightly regulated by public utility commissions. They can't raise rates willy-nilly, so expensive upgrades usually don't get approved. Local politicians don't want their constituents pissed off because they approved a rate increase to enhance the infrastructure.
This is going to be a tough nut to crack and I for one am glad to see that this threat is finally being taken seriously.
Whether anything comes of it will remain to be seen.
I can't believe you left out the late great Tiny Tim!
Tiptoeing beneath the tulips now I suppose.
Before you start climbing on your soapbox impuning other's knowledge you should gain a little knowledge yourself.
If all it was doing was task switching, it wouldn't be able to make use of parallel cores.
Need I say more?
I think I will.
Sure. If you manually make use of the threading tools. ... you do not have to do that on a Mac
I'm sorry, but I'm not buying. Applications have to be structured to take advantage of parallelism and no simple tweaks to a language (any language) will turn a single threaded application into a parallel processing application. It just doesn't work that way.
I worked with ADA 20 years ago and it had extensive support for concurrency, but unless you structured your application to run in parallel this feature was useless.
One final point. OS X is a derivative of FreeBSD and NetBSD. These are Unix OS's and all support the same basic multi-tasking model, and Windows is functionally the same as well. An argument can be made as to which system has the best scheduler, dispatcher, etc., but all in all they pretty much do the same thing. All Apple is really doing here is layering another API on top of the regular threading model and adding some syntactic sugar to C++ and Obj-C (thereby making applications non-portable). I'm glad you are so enthralled with GCD and I hope you enjoy your Mac world.
I prefer to work in less proprietary worlds (yes, even Windows is far more open than OS X - as amazing that seems).
Shows how much thinking "out of the box" goes on in top engineering circles today...
This sounds like the same argument I had with my boss 30 years ago. He wouldn't believe that microprocessors would one day obsolete the mainframes. He reasoned that no matter how powerful microprocessors got, mainframes would always stay well ahead of them. To my thinking, when it comes to electronics (both in speed and capacity), the distance between circuits begins to matter a lot when your working at the speed of light on a nanometer scale. There is abosolutely no way, in the long run, mechanical devices of any type will be able to stay ahead of purely electronic devices. Actually I'm surprised it's taken this long to get to this point. Costs will come down (I can pick up an 8GB thumbdrive for about $20 as opposed to the 8GB harddrive I paid $150 for about 10 years ago).
Spinning drives still have a few years left, but the writing is on the wall.
Software is different. I still hear stories of folks running autocoder programs!
Hardware will most definitely eventually die, and when it does, it will get replaced by the most cost effective hardware available.
Yea sure, tell that to the pile of drives in the corner of my office that gave up the ghost in 1 to 2 years.....
spam selling me down-loadable "male enhancements" for your 3d printer.... Thanks for giving them the idea...
one has ever given me an answer as to why my money has to go to pay the medical bills of my neighbor who smokes half a pack a day, or my neighbor on the other side who thinks it's funny to drink a case of beer each weekend by themselves.
For the same reason I have to pay for Oil companies to protect their interests in Iraq, or the same reason I have to pay for public schools when I send my kids to private schools.
I tend to be libertarian in my views, but if I had to start a list of basic services that my government should provide, I would think health care would be at the top of the list, certainly above funding for bank bailouts (thank you GWB). And when it comes to something as basic as the ability to see a doc when you get sick (people who don't drink or smoke get sick too!), a system that is set up to maximize profit at the expense of human suffering (which we have now) is completely immoral and even contrary to the founding father's intent (isn't Life the first of our unalienable rights as stated in the declaration of independence? - We hold these truths to be self-evident, that all men are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness.)
But as more cores come around it will eventually be the only practical way to go.
Great! I didn't realize that one of the greatest challenges of software engineering has been solved, by Apple no less! .Net - TPL, OpenMP and others).
Maybe Apple can now turn to solving the issues in quantum computing!
GMAFB!
Grand Central is at best an elegant solution for a narrow class of (simple, somewhat parallel processing) problems. All it really does is abstract the concept of threads away into "tasks" which are managed by the OS rather than the programmer. This will not complete solve the problem any more than garbage collection completely solves memory management problems. The CPU still has to switch contexts between these tasks although the overhead of tasks is less than that of true threads, it's simple a (possibly) more efficient implementation of the same old concept of task switching that's been around for decades (although I'm sure Apple will try and patent it as if it's something totally new).
Similar reimplementation of threading are available or being worked on in other environments as well (Java - JSR 166,
However, none of these approaches are going to yield efficient use of massively parallel systems when they become commonplace. There will have to be a major paradigm shift in the way applications are developed in order to take advantage of these systems for general purpose computing.
Oh yea? When I started out, our machine only had one byte - and our entire programming staff had to share it - now get off my lawn!
I believe the Jaguar - Cray XT5-HE has about 225,000 cores... IBM's BlueGene nearly 300,000 cores. Yea, give each app it's own CPU - then what do we do with the other 299,990 cores?
You can try porting the entire system over to a virtual machine, using dd to copy the entire system, then booting it up in qemu... Here's a link to someone who's had success with this approach... http://virtuallyfun.blogspot.com/2007/05/running-xenix-on-qemu.html Good luck!
Guess he didn't want to go swimming with concrete shoes on...
Java's open-source now.. it's ok for Sun to sink in the west now.
Seriously... I hope they all eat each other alive so that open-source is the only reasonable way to produce software. I've seen too much greed and infighting over "Master of the Universe" status for too long.
if NetBeans or Eclipse were taken up to the quality and usefulness of Visual Studio then that'd be awesome.
Huh? You're kidding right?
I use Eclipse and VS all day long every day. IMHO, Eclipse is far and away the better IDE any way you slice it. It also talks to everything and it doesn't cost thousands of dollars (yea, I know there's an Express edition, but if you intend to do Enterprise development you better be ready to take out a loan).
Eclipse gets slammed a lot for it's supposed "diabolical" UI, but I just don't get that. It feels perfectly natural to me and organized just the way I would expect it to be. I can grab a new plugin as needed for additional language support and everything works the same as other language support. I don't need to spend days scratching my head or reading books to know how to use a new feature, it just works as I expect it to. To each their own I guess.