I have an old AMD K6/2 350 overclocked to 400 and I find Perfoect Office fo rLinux quite usable It is not appreciably (did I spell that right?) slower an the MS Office bloatware I have to have for work on the NT partiton on the same box. I really do not care, personally, whether the port is native or not, at least not in an absolute sense. I am happy to have quality apps running on my Linux desktop, however they got there. Wine is fine, at least for me. That said, I certainly understand your feelings. I had the same feeling about apps for OS/2 for years. I, like Nick Petrelli, loved OS/2 and the Workplace Shell. However, no apps, no OS. I still have a Warp 4 partition on this box but I only boot to it for nestalgia these days. I personally prefer to have viable apps. The lack of them killed OS/2, the lack of them could kill Linux too.
Look I have read books and this was more than just one book. Basically if you paraphrase them they say that mainframes were used then. Now we use a client server way of doing things effectively killing most mainframes. Those that are left are the leftovers from the olden days and are falling stars even now. Take that as you will.
I have read many of the same books, or at least I have read books making similar points. However, they may be wrong.
Client/server architectures have some important weaknesses as well as important strengths. One of the big problems is the maintenance of processing logic on multiple client machines turns out to be rather more complex and time consuming than maintaining it on a single central box. The current move to web-based applications is motivated, at least in part, by the desire to reduce maintenance headaches by centralizing the storage of business logic. Secondly, executing business logic on the client makes the most sense when the data reside there. When the data reside in a central database, for example when there are several GB of data in an RDBMS, moving the data to the client to apply the business logic does not make sense. (On the other hand, entering the individual records that make up the contents of the database may well be best implemented by moving the business logic to the client so that the data can be validated before it leaves the client.)
Cleint/server architectures are contrained by network data transfer rates and usage. The more the data and the more the users, the poorer the performance will be at any given level of network bandwidth.
As to the value of mainframes in today's world. A couple of words have been bandied about in this conversation, "reliability" and "throughput" among others. Linux is approaching mainframe reliability and will, I expect, actually get that good in the not too distant future. After all, Linux is maintained and enhanced by a large group of folks who take bugs personally (if MS dealt with bugs that way, NT would be so good that Linux would still be the personal toy of Linus and a few interested hobbyists.)
Throughput is a different issue. IBM mainframes handle enormous volume because the system is architected for it from the ground up. Mainframes have multiple separate processors in them that are designed to handle a single function or closely related functions very well. These individual processors take their cues from the CPU but even the CPU is a different animal on a mainframe than on a PC.
An unfortunate consequence of common terms is that when a mainframe person uses the term "CPU" they mean something slightly different than a PC person means. While both devices execute "machine code" instructions, the common range of instructions is different in important ways. A PC CPU is a general purpose device that handles I/O, computations, branching, sound, DSP, etc. A mainframe CPU can do all that but usually does not. Rather a mainframe CPU acts more like a compute server and a traffic cop inside a network. The mains mainframes use to process massive I/O volume is for the CPU to direct a peripheral device to "handle it" and to let the CPU know when it is done. (PCs implementing DMA go part way down that path and performance improves if done right.)
This traffic cop behavior, supported by off CPU devices is what make a mainframe MIP profoundly different than a PC MIP. The PC instruction to move a bunch of data is actually a tight loop executed over and over in the CPU to move data a byte or a word at a time. On a mainframe it is a single instruction that supplies the peripheral processor the target location, the size of the data block and the target destination. The CPU has no other involvement with the process. So, while a PC CPU is performing the I/O, the mainframe CPU is moved on to other tasks.
Couple this with data paths that are much wider than that on a PC, and masive volume can be handled on a "single" machine.
Thoughtful readers will point out that I have described a network and I will agree. However, the network is all within a very short physical distance and has been designed as an integrated whole from the start. High performance is a natural consequence of the design.
Slashdot Mirror
I have an old AMD K6/2 350 overclocked to 400 and I find Perfoect Office fo rLinux quite usable It is not appreciably (did I spell that right?) slower an the MS Office bloatware I have to have for work on the NT partiton on the same box. I really do not care, personally, whether the port is native or not, at least not in an absolute sense. I am happy to have quality apps running on my Linux desktop, however they got there. Wine is fine, at least for me. That said, I certainly understand your feelings. I had the same feeling about apps for OS/2 for years. I, like Nick Petrelli, loved OS/2 and the Workplace Shell. However, no apps, no OS. I still have a Warp 4 partition on this box but I only boot to it for nestalgia these days. I personally prefer to have viable apps. The lack of them killed OS/2, the lack of them could kill Linux too.
I have read many of the same books, or at least I have read books making similar points. However, they may be wrong.
Client/server architectures have some important weaknesses as well as important strengths. One of the big problems is the maintenance of processing logic on multiple client machines turns out to be rather more complex and time consuming than maintaining it on a single central box. The current move to web-based applications is motivated, at least in part, by the desire to reduce maintenance headaches by centralizing the storage of business logic. Secondly, executing business logic on the client makes the most sense when the data reside there. When the data reside in a central database, for example when there are several GB of data in an RDBMS, moving the data to the client to apply the business logic does not make sense. (On the other hand, entering the individual records that make up the contents of the database may well be best implemented by moving the business logic to the client so that the data can be validated before it leaves the client.)
Cleint/server architectures are contrained by network data transfer rates and usage. The more the data and the more the users, the poorer the performance will be at any given level of network bandwidth.
As to the value of mainframes in today's world. A couple of words have been bandied about in this conversation, "reliability" and "throughput" among others. Linux is approaching mainframe reliability and will, I expect, actually get that good in the not too distant future. After all, Linux is maintained and enhanced by a large group of folks who take bugs personally (if MS dealt with bugs that way, NT would be so good that Linux would still be the personal toy of Linus and a few interested hobbyists.)
Throughput is a different issue. IBM mainframes handle enormous volume because the system is architected for it from the ground up. Mainframes have multiple separate processors in them that are designed to handle a single function or closely related functions very well. These individual processors take their cues from the CPU but even the CPU is a different animal on a mainframe than on a PC.
An unfortunate consequence of common terms is that when a mainframe person uses the term "CPU" they mean something slightly different than a PC person means. While both devices execute "machine code" instructions, the common range of instructions is different in important ways. A PC CPU is a general purpose device that handles I/O, computations, branching, sound, DSP, etc. A mainframe CPU can do all that but usually does not. Rather a mainframe CPU acts more like a compute server and a traffic cop inside a network. The mains mainframes use to process massive I/O volume is for the CPU to direct a peripheral device to "handle it" and to let the CPU know when it is done. (PCs implementing DMA go part way down that path and performance improves if done right.)
This traffic cop behavior, supported by off CPU devices is what make a mainframe MIP profoundly different than a PC MIP. The PC instruction to move a bunch of data is actually a tight loop executed over and over in the CPU to move data a byte or a word at a time. On a mainframe it is a single instruction that supplies the peripheral processor the target location, the size of the data block and the target destination. The CPU has no other involvement with the process. So, while a PC CPU is performing the I/O, the mainframe CPU is moved on to other tasks.
Couple this with data paths that are much wider than that on a PC, and masive volume can be handled on a "single" machine.
Thoughtful readers will point out that I have described a network and I will agree. However, the network is all within a very short physical distance and has been designed as an integrated whole from the start. High performance is a natural consequence of the design.