Are they going to try to port RETAIN from MVS to Linux?
This makes no sense. This is about changing the clients IBMers use. RETAIN users switching from WinXP to Linux will just need a 3270 emulator. There are GUI clients, but they are java based, so will just need a JVM on the Linux client.
IBM makes lots of money on software. If software is a stack, with OSes at the bottom, what you should understand is that trying to make money out of OSes is like, so 80s, and IBM will never play in that game again. These days, the money is in middleware like app servers, business integration software (and areas like DB2 which are resounding business sucess stories). In the future you can bet that OSS will canablaize some of that too, but IBM will have moved on by then.
There aren't many low MIPS machines out there, certainly not ones that will be targetted by large corporations to deploy J2EE apps. The last 10 years have seen a progressive consolidation of the mainframe market, with the low end and more stable sites moving to other platforms. We're talking recent 10 or 12 way boxes with >10GB of real storage, which is more than adequate to get lots of trans/s. Plus you can run lots of other workload at the same time. Plus the TCP/IP stacks are slick (multiple stacks on Linux anyone ?) and perform well. Plus builtin crypto hardware to speed up those SSL sessions. I could go on. These types of organizations don't deploy scripting languages in general. I dunno (and no offence) but I just think lack of contact with this mainframe world makes people think they know more about it than they do:-)
I think that's a bit patronising. It assumes that Linux is "cutting edge", when it's clearly just a good implementation of what is now well understood OS technology. Don't forget that these "boring" systems contain a lot of advanced OS technolgies e.g. sophisticated workload scheduling (setting Goals for the OS in business terms), coupling technologies that allow multiple systems to be managed as one system. One of the proofs of their resliance and adaptibility is the fact that you can deploy J2EE apps in these enviroments -- you might just find that your "cutting edge" OS doesn't cut the mustard and that your PHBs prefer to deploy these modern apps on old iron.
A lot of MS defects are reported to them by one organization and patched pretty quickly. The problem is updating all those existing clients and servers out there. With a massive OS population it's inevitable that there will still be vulnerable machines by the time the (now publically documented) defect is exploited. Like I say, I see this being an equal problem for OSS if the future turns out to be Linux dominated.
...but in a linux desktop future you think the worm, trojan and virus writers are going to give up and go home with their tails between their legs ? I don't think so dude. And it's not a great leap to imagine a spoofed email from RedHat arriving in your inbox.
I'm not defending MS monopolistic position, and I look forward to a day when Linux desktops are the standard. I just think we should be a little humble about the difficulties involved.
So how is this different to MS having multiple attempts to resolve their security bugs ? I don't see a difference. Doesn't this prove that closed or OSS, security code is a difficult software engineering challange ? Maybe slashdotters should cut MS some slack in this area.
Damn, you beat me to it:-) And APARed several times folks...
Re:Can someone explain "The Java allure" to me?
on
Even Sun Can't Use Java
·
· Score: 2, Interesting
On the server side it's because companies like the idea of component based development, where they can employ programmers to concentrate on building good reusable application level components, but get the benefit of transactional support that the J2EE containers provide. The thing is, CORBA is tricky for remote objects, whereas J2EE has provided a whole eco system in short timeescale to do this stuff - right from IDEs through to the J2EE servers themselves. And the best bit for the real world is that there is a high degree of OS and Architecture independance. Not total I'd agree, but enough to make people who were once locked into SNA networking etc. a lot happier about the future.
Not that there is anything wrong with using a garbage collector, but my experience with customer applications based on java application servers is that you are really exchanging one set of C/C++ memory errors for another type (object leaks where you still maintain references to a portion of the object graph, preventing the objects from being collected, through application errors) and in a lot of production type environment the tools for figuring out object leaks either don't exist or are not as mature as those for figuring out "traditional" storage leaks.
I think the reality is closer than this article or the discussion here makes clear. See http://www.gridforum.org/ for example. The company I work for certainly has this tagged as a 'next big thing'.
Slashdot Mirror
Are they going to try to port RETAIN from MVS to Linux?
This makes no sense. This is about changing the clients IBMers use. RETAIN users switching from WinXP to Linux will just need a 3270 emulator. There are GUI clients, but they are java based, so will just need a JVM on the Linux client.
IBM makes lots of money on software. If software is a stack, with OSes at the bottom, what you should understand is that trying to make money out of OSes is like, so 80s, and IBM will never play in that game again. These days, the money is in middleware like app servers, business integration software (and areas like DB2 which are resounding business sucess stories). In the future you can bet that OSS will canablaize some of that too, but IBM will have moved on by then.
There aren't many low MIPS machines out there, certainly not ones that will be targetted by large corporations to deploy J2EE apps. The last 10 years have seen a progressive consolidation of the mainframe market, with the low end and more stable sites moving to other platforms. We're talking recent 10 or 12 way boxes with >10GB of real storage, which is more than adequate to get lots of trans/s. Plus you can run lots of other workload at the same time. Plus the TCP/IP stacks are slick (multiple stacks on Linux anyone ?) and perform well. :-)
Plus builtin crypto hardware to speed up those SSL sessions. I could go on. These types of organizations don't deploy scripting languages in general. I dunno (and no offence) but I just think lack of contact with this mainframe world makes people think they know more about it than they do
I think that's a bit patronising. It assumes that Linux is "cutting edge", when it's clearly just a good implementation of what is now well understood OS technology. Don't forget that these "boring" systems contain a lot of advanced OS technolgies e.g. sophisticated workload scheduling (setting Goals for the OS in business terms), coupling technologies that allow multiple systems to be managed as one system. One of the proofs of their resliance and adaptibility is the fact that you can deploy J2EE apps in these enviroments -- you might just find that your "cutting edge" OS doesn't cut the mustard and that your PHBs prefer to deploy these modern apps on old iron.
It was reported by a third party "Microsoft thanks The Last Stage of Delirium Research Group"
A lot of MS defects are reported to them by one organization and patched pretty quickly. The problem is updating all those existing clients and servers out there. With a massive OS population it's inevitable that there will still be vulnerable machines by the time the (now publically documented) defect is exploited. Like I say, I see this being an equal problem for OSS if the future turns out to be Linux dominated.
...but in a linux desktop future you think the worm, trojan and virus writers are going to give up and go home with their tails between their legs ? I don't think so dude. And it's not a great leap to imagine a spoofed email from RedHat arriving in your inbox.
I'm not defending MS monopolistic position, and I look forward to a day when Linux desktops are the standard. I just think we should be a little humble about the difficulties involved.
So how is this different to MS having multiple attempts to resolve their security bugs ? I don't see a difference. Doesn't this prove that closed or OSS, security code is a difficult software engineering challange ? Maybe slashdotters should cut MS some slack in this area.
But Eclipse is written in Java and is a useful app with a good UI. With SWT you wouldn't need to know it's Java based at all.
CICS can run EJBs in its latest versions.
..the idea of storing away a "UI continuation" as an object, which can be used to restart an operation from some pending point.
Integration of email and IM is already available in commercial products like WebSphere Portal Server.
me too. Still think of those model 30s.
Damn, you beat me to it :-) And APARed several times folks...
On the server side it's because companies like the idea of component based development, where they can employ programmers to concentrate on building good reusable application level components, but get the benefit of transactional support that the J2EE containers provide.
The thing is, CORBA is tricky for remote objects, whereas J2EE has provided a whole eco system in short timeescale to do this stuff - right from IDEs through to the J2EE servers themselves. And the best bit for the real world is that there is a high degree of OS and Architecture independance. Not total I'd agree, but enough to make people who were once locked into SNA networking etc. a lot happier about the future.
...and that would be good, because we already have a lot of marketing folks who market "Vaperware"...
Nah. Server side Java is the thing these days. With a good JIT Compiler, your steady state performance is going to be very good.
Not that there is anything wrong with using a garbage collector, but my experience with customer applications based on java application servers is that you are really exchanging one set of C/C++ memory errors for another type (object leaks where you still maintain references to a portion of the object graph, preventing the objects from being collected, through application errors) and in a lot of production type environment the tools for figuring out object leaks either don't exist or are not as mature as those for figuring out "traditional" storage leaks.
I think the reality is closer than this article or the discussion here makes clear. See http://www.gridforum.org/ for example. The company I work for certainly has this tagged as a 'next big thing'.