Slashdot Mirror
The Pros and Cons of Mainframe Linux
magellan writes "There is a good article on LinuxWorld.com that goes over some of the pros and cons of Linux on the mainframe. The author, Paul Murphy is an old mainframer and current UNIX user, as well as a frequent contributor to LinuxWorld.com, so he has some good insights.
"
Linux the utility OS, runs anywhere. I have it on Intel & Alpha at home. What hardware do you want to make sing today :-)
What OS do you want to abuse today?
I work in a large datacenter with some very powerful machines, and I just don't see Linux having much of a future on mainframes, at least not without some serious kernel improvements. It is an excellent OS, and would be a good choice for a workstation or a low-end server, but would be a very poor choice for a high-end mainframe machine. The linux kernel is highly configurable and it would certainly be possible to get a Linux kernel running on a massively parallel machine, but this was not what Linux was designed for, and performance would not be on par with other more robust Unices. Linux' inferior TCP/IP stack as well as its inferior handling of multi-threading on a large scale is its major weakness in this area. Until these weaknesses are addressed, I would prefer Solaris, Irix, or HP/UX instead, as they were designed from the ground up with mainframe usage in mind.
-atrowe: Card-carrying Mensa member. I have no toleranse for stupidity.
It's open source, if you don't like it fix it.
I don't get it, why would you want to run Linux on a mainframe? There are serious issues that leave Linux with limited scalability, even if you're running a few dozen virtual machines. It just seems like a waste with all the effort that's already been put into a truly fantastic machine and OS.
It's still Linux, whether you run it on a Celeron or a mainframe.
You've got the right hardware, but the software still isn't 'mainframe' level.
I was about to spend 5 million dollars on a new zSeries setup, but after reading the article I thought "maybe my laptop is good enough for now".
-... ---
(see this report of a test on a 733-MHz Linux system for details on mstone) run on the mainframe.
Yes, it's a word document. You'd think anyone writing an article for a Linux targetted site would at least check or convert the document to something everyone can read...
Code, Hardware, stuff like that.
Besides pricing, the more high end the server goes... the more I will lean toward solaris.
I am linux-biased folks are going to / me for this.... but I am speaking from experience.
Um, Solaris, Irix, and HP/UX (shudder) are *NOT* mainframe operating systems.
MVS and OS/390 are mainframe operating systems.
You are talking out of your nether regions, especially when you call linux's TCP/IP stack inferior to HP/UX. I have adminned every operating system mentioned above except Irix, and you sir are grossly incorrect.
noooooo.....nu-uh....you can't use NT on a mainframe.
You would think that.
It's open source, if you don't like it fix it.
Is it an obligation? Or can I just use something else?
GNU stands for "Gnu's not Unix."
Funnily enough I just came across this article on ZDNet that talks about how Linux isn't a very good long term server solution. Its here at http://zdnet.com.com/2100-1104-909084.html
Linux was never ported to the 486 and Pentium. As they support the same instruction set as the 386, no porting was necessary. Sure, over time enhancements were made to take advantage of specific features of various x86 features, but that's not porting.
And GNU has nothing to do with porting of Linux to any platform.
And your corporate mainframe doesn't run NT. Or if it does, you're using a definition of "mainframe" with which I was not previously familiar.
And preemptive multithreading and protected process management is not new to 2.4.5. That's something that has been in every Unix since, oh, about 1970. It's also something that has been in every enterprise-class system in the past twenty years. I would hardly call it a boon to admins.
AFAIK, there are no mainframes that run NT. And I've never seen one with a USB port, either. Your post makes absolutely no sense from a mainframe perspective. What are you talking about with "dual boot"? Mainframes can run multiple simultaneous LPARs, which are virtual machines sort of like VMware provides, but nobody ever boots a mainframe if they can avoid it. And mainframers don't use the word "boot" anyway, since individual components of the mainframe can be individual restarted. Mainframers IPL from the HMC, which is the analogous operation to rebooting. Mainframes run VM, MVS, OS/390, and similar. They don't run NT or OpenBSD (though OpenBSD could probably be ported). There is no graphics console device on a mainframe, so how the hell could you run NT?
It is a frickin' mainframe!
Still, the article (if it is the same as the one linked to by ZDNet UK) does point out some things that need to be fixed in future Linux mainframe systems. Solidity.
I believe that the future is bright for Linux on mainframes. The article assumes that Mainframes will be deprecated in the future by commodity x86 hardware, whereas they will equally get more powerful and require an OS to handle that power well, and IBM recognise the value of Linux in this respect.
Much server work looks like this: request comes in from network, appropriate program gets loaded, maybe talks to a database, runs for less than a second, returns results to network, exits. Typically, a large fraction of the resources used go into the "appropriate program gets loaded" step, doing the same startup ritual over and over.
There are two UNIX/Linux solutions to that startup overhead problem. One is to build the transaction program into the network application (as in Apache/mod_perl/php). Note that this uses an interpreter to protect the network application from bugs in transaction programs, which is a major performance hit.
The other approach is to use the regular UNIX/Linux program launch facilities to run a separate program for each transaction (as in CGI programs.) This is safer and easier to maintain, because the CGI programs each run in their own processes, but the cost of program loading (which might include initializing a Perl or Java environment) often dwarfs the cost of doing the useful work.
A mainframe transaction processor basically maintains process images which are ready to run a transaction, with all loading complete. When a process is needed to run a transaction, it's made by copying one of those process images (with read-only or copy-on-write sharing of pages) and launching it to do the job. The new process runs for a short period and exits. This is a facility that Linux/UNIX lack, because they were intended for interactive use, not server-side transactions.
Because Linux has copy-on-write semantics for fork(II), it's should be possible to do a high performance transaction facility under Linux. A transaction program initializes itself by loading everything it needs, but without any per-transaction data available. It then goes into a loop waiting for work, and on each request, forks off a copy of itself to do the job. Each copy does one transaction and exits. If it crashes or gets corrupted, only one transaction is affected. Note that there are no expensive exec(II) calls involved in starting a new transaction.
Has this been done? It's obvious enough that somebody has probably tried it.
That ain't big iron! The only system that runs both of those is the Alpha. And the Alpha ain't a mainframe.
Best Slashdot Co
First of all, way to go Slashdot, this article has been out for quite some time. It's received a lot of attention on the Linux 390 mailing list as a Sun FUD campaign as it places a fully loaded z900 on par with 80 Dell servers and the zSeries in general on par with mid-range Sun equipment (and others).
;) so it is my job to know about what a z800 can do for us.
First, I'm fairly qualified to talk about what the zServer can do. For those of you who don't remember, I'm one of the guys that helped win a z800 for Clarkson University that will be used in our Open Source Institute. I'm also the technical lead for COSI (whatever that means
Some history, Clarkson University has always had a very good relationship with IBM: they employ a large amount of Clarkson students and graduates (including me, in the Extreme Blue program. So if you think that biases my opinion, well too bad as I've talked with the guys making sure that Linux runs and is fully integrated on the Linux platform and one of the original Linux S390 authors Boas Betzler.
All of these people have real experience with what the zSeries can do, as do I since I've seen it in action. A zServer is unique in the sense that you can (with the right model) run Linux S390, VM, zOS and other guest operating systems in Logical Partitions. These all act independantly of one another just as if they were seperate machines on a network. This is great if you have DB2 with maybe a web frontend because both of those machines can talk at memory speed via HiperSockets and the only outside link is the network connection to the web server, which is at Gigabit speed (did I mention that you can do full speed gigabit with one of these things on multiple interfaces?).
This article basically says that you can take a midrange Sun server and do everything that a z800 can do but much better. I don't know of any Sun Server that can run N Linux clients in a VM at full speed.
They aren't the solution to every problem, but a zServer certainly is a better solution that what is presented in the article. I really don't have the time to go in to detail with everything as it's a lengthy article but suffice it to say that this is no where near 100% accurate.
At least this site will inform the user that story content has changed...
-Justin
That's enough posting for now lads, there're trolls afoot.
No it wasn't. GNU is a license, and licenses are notoriously bad for writing code (or doing anything except sit on a disk or shelf). Linus wrote Linux for the 386, but there was nothing stopping you running it on the 486 even on day 1. In fact, even today, you can run 386 code on a Pentium IV. The only disadvantage is that you'll not get the best optimizations. The GNU license was applied for version 0.12 in Jan 1992, before it was really a practical OS, and in March 1992, it became 0.95, and was really a usable OS.
He doesn't say what mainframe he was using, but IIRC, there exists for RS/6000 and AS/400's (yeah, I know the RS/6000 isn't really a mainframe) "co-processor" boards that are essentially funky PC motherboards that run the PC-based OS (in this case, NT), and have drivers to use the mainframes resources (drives, ports, etc) and translate them into the PC equivalents.
Most of the time, these boards have their own memory - some even have thier own hard drives (I would imagine there are some which are simply a TN5250 hack for comm with the mainframe, and only draw power from the backplane - all memory, ports, and drives mounted to the module).
In other words, NT doesn't actually run on the mainframe, or VM - but rather on a dedicated processor board. I know these solutions exist for IBM hardware - I wouldn't doubt that there are similar solutions for other mainframe manufacturers as well (either by the manufacturer or licensed third parties).
Reason is the Path to God - Anon
darn, I had hoped to get "+1 funny", but I got "-1 not funny you star trek goof" instead. oh well.
The Kruger Dunning explains most post on
I think that.
I guess I'll stick with my old P-200 for the moment....
You forgot:
:-)
3) Bitch about it on Slashdot because you apparently are not working now!
I'll grant the point of the paragraph - that UNIX process/destruction occurs more often that MVS address space creation or even task creation. And I'll buy that some "UNIX CPUs" can handle multiple instruction streams. But have any really implemented a single-cycle context switch?
I checked, and yes, the IBM site did say "31-bit" mode. Won't this break a lot of Linux apps?
Mainframes - designed for the benefit of the machine.
PCs - designed for the benefit of the user.
Unix - designed for the benefit of hunt-and-peck administrators and obscure language designers.
To respond to you both:
The GPL is the licence you're thinking of.
GNU is the name of the operating system project started by Richard Stallman. It is not a "group" that "ported Linux to the 486" or a "licence". The first functional implementation of GNU was created by Linus Torvalds when he ported GNU to run over his Linux kernel. The fact that this combination is largely GNU software yet is called "Linux" is the bone of some contention from Stallman and others who worked on GNU, but that's another thread.
Have I been trolled?
KMSMA (WWBD?)
Would that be the BeOS zealots?
This article was in linux journal about two years ago, but most of the discussion is still fairly interesting to read. He brings up a lot of very good points and has some interesting numbers to back him up.
There is another article on ZDNET link that roasts Linux on the mainframe. I think people were too harsh toward sun when they published their report, but the reality is that Linux is not ready for the mainframe YET.
mainframe Linux is that most mainframes don't have USB ports or good drivers. This sux cause then I can't plug in my Canon Powershot digital camera and use the pictures to make christmas cards for my grandmother. Also, Printshop Deluxe doesn't run on my S/390. SUX
I work for a large shop and here are my experiences running Linux on the Mainframe.
First, I'm a mainframe person. I like the mainframe. I've used Linux at home for about 6 years so I was chosen to be on a "proof of concept" with running Linux under VM. I've been doing OS/390 & z/OS support for about 4 years. I'm in the "30 & under" crowd and I've seen both the Unix & mainframe side of support.
We've played with TurboLinux, SuSE, & the RedHat beta for the zSeries. We're running zVM 4.2.
First, lots of things work really well. It was strange seeing the normal Linux boot messages appearing in zVM. We've been primarily using the 2.4 series kernel, but we have tested things with the 2.2 series. We've played with Oracle, WebSphere, DB2 Connect, Samba, Apache, IBM HTTPD server. The only technical problem we really had was Samba caused kernel crashes. Some patches from the IBM z/Linux site fixed it.
The biggest problems we have had are philosophical and percepteion based. Here are some of the difficulties:
We had to force our customers to a shared outage window. Even VM needs to be IPLed every year or so. If they can't tolerate a 6 hour window every quarter or 6 months, we won't support them on the zSeries. A second box could make it a true zero downtime machine, but we are initially targeting the low usage, non critical machines.
Lots of people have the delusion that the zSeries processor is hundreds of times faster than other processors. It isn't. It's fast, but not several magnitudes faster than the other processors out there. It's also not designed for heavy computational applications. Don't try, you'll hate the results. It can be done on a limited basis, but don't try and compute PI. It works better on I/O related applications which are traditional mainframe strengths.
A lot of the code on the zSeries for Linux is the first generation to be released there. A lot of the performance perks for that platform are not there yet. If there is enough adoption, ISVs will make the performance better, but right now a lot of them are testing the water.
Some people have the illusion that if you take a piece of crap application on Solaris or NT and run it on Linux, it will run better. The OS typically doesn't make your piece of crap any better.
When people buy an Intel or Solaris server, they typically get the most memory & disk space they can afford. This is the worst thing to do under VM. We had a lot of people want 2GB of RAM and 100GB of disk space. Later analysis showed they could survive with much less memory (some as little as 128M) and used almost none of the disk. The reason for this is simple. Whey you buy a Sun or Intel server, upgrading them is a pain, so you do the pain up front. Under VM you can change the amount of memory & allocate more disk very easily. This was a big learning curve for people, and not just the Unix people. The major difference we found in the memory is because Linux uses it as disk cache. On the zSeries the hardware has lots of it's cache on on it.
People needed to understand they were sharing CPU & memory. Performance tuning has a very big impact. On Intel or Sun who cares if your application is looping endlessly. On VM everyone cares. Lots of our Unix sysadmins really hated this fact and the customers couldn't fathom it. You want to put applications with LOW USAGE on this platform. The idea behind sharing is that nobody needs all of the CPU all of the time. If you run at 100% on a 4-way Pentium CPU, you won't like sharing CPU with dozens of other virtual servers and they won't like sharing with you. This was probably the most difficult thing to stress to the users.
This isn't emulating Intel. It took a while to get people to understand that VM wasn't emulating an Intel machine and that the nice pre-compiled intel binaries don't work. Lots of people went out looking for software from ISVs and the ISVs said "Sure we support Linux". What they didn't say is "We support Linux/390". There is a very big difference. Linux is not just Linux on Intel and it took some education to get this through to the users.
Once we convinced people that it isn't running Intel, they tried to recompile their favorite programs and found out that for some applications a "simple" recompile wasn't enough. I would imagine that the power-pc folks had similar problems, but some programs take a little investigation.
There were some really nice aspects of running on a zSeries.
Disaster Recovery is easier. Mainframe DR has been established for decades and it isn't terribly different with Linux on the mainframe. Much more simple than having dozens of individual machines to recover.
The hardware never fails. It may be expensive, but CPUs have a 30 year mean time to failure, the disk is all raid, multiple IO chanels help ensure there is not single point of failure. Hardware can typically be swapped out without taking an outage. CPUs can by dynamically added.
If you want to copy an existing virtual server and make a test copy, that can be done in minutes. That makes it really nice for developers who want to do the "what if I do this" tests.
VM's programmable operator facility makes for some nice system automation. You can also create Rexx scripts for your operations so they never even need to logon to Linux to do certain work.
Creating a new server is easy. No more running through the install screens. Once you have one customized, just use it as a template for new servers.
We were able to have certain drives shared as read-only across all images. This makes support a little easier. We made one Linux have the drive read-write. When we changed it there, we just unmounted & remounted it on the other images (a Rexx script made that painless) and it was magically everywhere. We can even take down the read-write linux to be sure something isn't accidentally changed. We've been experimenting with sharing lots of Linux mount points this way. We estimate we can concentrate about 100GB down to 2 GB which cuts down the overall cost. The majority of code on all Linux images are the same and will tolerate being shared, so as long as your environment is stable and you do some planning, you can dramatically cut down on disk usage. The amount of disk you save is directly related to the number of images your machine can handle.
The virtual-linux to virtual-linux IP traffic happends at memory-to-memory speed. It's also very nice not to worry about network issues when trying to debug a problem because there is no physical network.
Recovery is easier if an image won't boot. Just attach the drive to another, running image and fix the problem. No need to physically go to the machine.
Sorry to ramble, but this is what we have found. Linux on the zSeries has it's place and does work, but it's not a solution to every problem. Few things are.
I believe many of the scalability problems are also
due to no asych I/O , at least for db apps. I believe they are implementing it in linux 2.6, though
it is relative to enerprise OS's not pieces of shit like windows
soory but BeoS is not a good server OS. youre beef is with KDE and GNOME
What's wrong with it? It has worked very well for me and many other people I know. Very low latency, low overhead, good bandwidth, support for most of the new TCP and IP options.
Are talking about things like VLAN support, massive numbers of device aliases, or strange hardware like token ring -- or what?
Isn't that the old processor that HP used to make?
sorry bud, but mainframes run 70% of corporate data still.
o ri alsID=59
check out
http://www.esj.com/departments/article.asp?Edit
Let's take a reasonable guess: the average Slashdot user has no experience whatsoerver with mainframes or corporate data centers. Better stick to stories about ATTACK OF THE CLONES and so on. At least those topics offer something within the life experience of the average /. reader.
"I think the best that's been done is called the 'tacky' bit (chmod +t) on an executable. Traditionally, that left the executable loaded 'in swap', presumably for faster startup."
To get this effect cheaply and repeatably in Linux, copy the relevant binaries under a tmpfs mounted directory.
Market research company Meta Group takes a swing at Linux, saying that Linux mainframes will soon be irrelevant and that the OS isn't mature enough to handle critical business applications.
Your the one that not MATURE!
Not to be a GNU pundit, but...
> And GNU has nothing to do with porting of Linux to any platform.
... is demonstratably false. Whether or not the individual people who port the Linux kernel to a new architecture are or are not GNU affiliates is, simply put, irrelevant. The first step to getting Linux (or BSD, or whatever) on a new system is porting GCC to its architecture. While this is sometimes done by the people responsible for the Linux porting effort, most of the time this is done by members of the GCC team -- getting a new port to work without breaking all the others requires a great deal of cooperation and support.
Not to mention a working linker. Assembler. The list goes on. Who wrote those?
Lately I've heard a lot of Linux weenies dissing GNU and RMS as out-dated hippies who are prone to overestimating their importance. Unfortunately for these people, GNU is the only reason Linux exists. It's not like Linus wrote his kernel and there just happened to be a binutils chain, compiler, libc, etc just sitting there, ripe for the taking without someone doing a HECK of a lot of work. Probably more work than goes into developing the Linux kernel itself.
Unlike some morons, I'm not here trying to say that Linux/Linus don't deserve a lot of credit; they do. But people who disagree with RMS and his policies often decide that that makes it okay to write revisionist history and downplay his importance to the OSS movement. Without him, there is no movement. Like him or not, don't forget it.
I've noticed that whenever Meta group report on Linux they always denigrate it. There have been articles on ZDNET and similar places where positive things have been said by Gartner, IDC etc., but then at the end there are some words of doom from Meta Group: "it may not be ready", "there might be problems", "you can't yet run Linux on 1000 processor machines...".
For example, look at this article about Linux in investment banks. Positive news all the way through until:
But Meta Group programme director Ashim Pal says the cost of the platform is not the only consideration. 'The operating system is a relatively small part of the total cost of ownership. Purely focusing on the cost of the platform is deluded,' he said.
If you go their web-site and look for recent documents featuring Linux in the title you will find:
- Linux on the Mainframe: Nice Place to Visit, But... ... Linux Management: More Hype than Substance
- No Advantage From Linux PDAs
- Choose Palm or Pocket PC - Linux Only for Custom Apps
- Linux PDAs Offer Alternative for Low-End and Specialized Markets
- Companies Should Consider Limited Server-Based Linux Implementations
- Microsoft Criticizes Linux as Operating System Issues Move to Web Services Level
-
- Linux Dreams of Management Promotion.,
- Linux: Application Server Tiers or Tears?
I guess you can make your own minds up. BTW, Meta Group have been having a few problems themselves recently.
I'd have to say the Civil Rights movement completed many of the objectives of the New Deal, and not so much of reconstruction. For more info, read a GODDAMN HISTORY BOOK!
First I must say that my story is a long time ago (like the author of the article). I was an operator on an IBM 3083 17 years ago and left a few months after they had installed VM. We had the mainframe connected to the comanies bottlings plants across the whole country (running system 36 minis) and during the day, especially later in the afternoon most of the various plant's accounts/processing data would come in. The night shift would then start the accounting and processing jobs around 7PM and run them through the night and a few hours before the morning shift came in the Storage backup system would run (HSM) and then during the day the coders would do their thing etc.
The whole point of VM (and the mainframe) was that it is optimised for business systems, AFAIK, and unlike heavy scientific computing loads, there is seldom a need for incredible processing power in the CPU, but there is a need for distributed processes and extremely good I/O since most business tasks are often thrashing around on the disk getting and updating customer/financial info etc.
I don't think the zSeries would be doing as well as it is (eBay, Swedish and Japanese telcos etc) if there wasn't some advantage to this system. Probably, what sways a lot of these deals is that if your machine has any problems IBM will have a technician there pronto and their staff (at least in those days) were very professional and well trained.
I didn't get the part of the article about swapping to a RAM disk. That doesn't really make a lot of sense.
But, for what its worth, I have used Linux on an S/390 for software development. I found it performed just fine as an interactive environment and no different than any other multi-user system.
Sure, sometimes you notice a slowdown under heavy load, but it was very rare and short-lived.
As for application portability it seemed to have no problem with ANSI C code and POSIX functionality. It's Linux, as long as your code doesn't do nutty things that are not guaranteed by ANSI, Linux/390 functions just like a large Sun or HP machine with lots of people compiling and editing.
hm. the article on lw.com states that sendmail can handle about 2 million boxes on an IBM Mainframe. Well, according to this article at ibm.com, a Mainframe of the same architecture can handle 250+ Million of Users (IMAP, POP3 and SMTP). Guess Linux can step back in this specific case against the not really well known TPF Operating System (currently used at the IT Farms of Airlines and large Banks).
Linux just doesn't work as well as FreeBSD. IBM would be better off supporting FreeBSD.
FreeBSD scales way better and is more stable than *linux. Spread the word. We need to let people know there's something better out there.
That was quite a few keywords there. Definitely a varied combination. If they'd been assembled a bit better, your post might have made sense! Next time, link each word to E2 for added mod points.
Keywords:
Linux, GNU, mainframe, NT, OpenBSD, USB, multithreading, kernel
There were others, but you get the idea. Now, which ones don't belong?
At least NT, OpenBSD, and USB. Of course, those are the majority of your argument (and the rest of your post was simply unrelated fluff).
Yours was definitely a Slashdot post for the ages.
Hell. Yes.
FreeBSD also has COW and is more stable and faster than Linux. IBM should switch to FreeBSD because FreeBSD is truly free.
Please do not do that! FreeBSD is already available to run on your PC and it is truly free source, with even the installer included, which most proprietary *linux distros will not give you source code for. FreeBSD is more stable and faster than linux and more advanced too. It embodies decades of Unix(tm) research that Linux keeps reinventing due to NIH. Please put a stop to this madness and start spreading the word about FreeBSD.
Alpha was a 64-bit chip in 1992. DEC sued Intel over the contents of the Alpha, and Intel paid them a large sum of money in settlement. Then, DEC sold itself (what was left) to Compaq. HP is planning on dropping Tru64, don't know if it's planning on dropping the Alpha. Hope not -- it's a beautiful design and only gotten better over the years. It's a shame IBM didn't buy the Alpha. Also a shame that DEC never knew how to sell.
Mainframe UNIX is an oxymoron.
Linux and s390 isnt a swiss arm knife, if you want raw cpu process go to RISC.
IBM line.
Xseries, INTEL.
PSeries, RS/6000 P=PERFORMANCE
ISeries, AS/400 I=Integration
ZSeries, S390/Zseries Zero Stop.
The Mainframe advantage is handle large amount of data, impressive IO access and uncomparable stability.
"Thank you for your interest. We are performing system maintenance at this time. LinuxWorld will return shortly."
I've pushed hard to have Linux put on my client's mainframe. The mainframe has superior storage management and security so it's the best place to keep massive amounts of data(massive to the PC mindset). My client has a need to have certain reports available forever and the reports in question are about 40 gig in size for the first year. This has been expected to grow quite a bit in the next few years to something like 100 to 200 Gig a year. Since the reports for the most part will not be accessed often, it makes no sense to build an NT box just to serve up these reports when they're requested(a Linux box on a server machine is out of the question in this shop--politics).
The users will request their report on the Linux ghost box and the Linux system will request the file from MVS which likely will reside on cart, I mean tape. The tape subsystems are extremely fast and the hardware is already budgeted and in use. The NT folks wanted all sorts of money for a new server, OS, etc.. it just wasn't worth it.
The hardest part is selling the idea, I mentioned it to the manager I report to and he said, "What's Linux?" I'm not kidding. This IT manager had never even heard of Linux. I found that the best way to make sure it happened was to go ahead and just make a prototype. Systems programming on the mainframe side were enthusiastic about loading it and got it going in short order(they want to screw the NT people anyway). It not only works but retrieval from archive is seamless and quick. Security is easy to handle because the users are already defined in RACF with certain rights, we just need to add those datasets to their IDs. After we're done there should be no more manual intervention(which supposedly was needed with the NT solution)
Other groups at the client site are now aware of what we are doing and would like to publish their own reports on the intranet from the mainframe without having to go through the hassle of dealing with the NT groups. Since departments in this company are not charged for their mainframe usage but are charged for any NT servers they need, it's a no brainer for management-- once you show them it works. You often have to lead these people by the hand. You also need to engage systems programming. Those guys have all sorts of neat soultions to problem but they are terrible when it comes to marketing their solutions.
Of course Linux TCP/IP is multithreaded.
This is why the 2.4.0 kernel took so
long to release.
Of course Linux TCP/IP can pass multiple
packets at the same time. This has been
the case from day one, before the 1.0.x
kernel was even released.
Linux beats Slowaris up to at least 8 CPUs,
and completely roasts Slowaris on 1 CPU.
The earlier poster made the mistake of confusing NT itself with applications on NT. NT itself was a native compile for the Alpha (as it had been earlier for PowerPC until that CPU also was deemed to be unusable/unsellable for NT). Of course, this created a problem, because almost nobody created native Alpha binary versions of their applications. So DEC had a OS "smart" emulator that worked as was described (e.g., more you used it the better the speed). But this emulator was used for i86 binaries running on Alpha, not for native code.
One of the avantages of NT Alpha was it was a cheaper box than Unix Alpha (or at least it was when I still worked for DEC). Still, it was always more expensive than the comparable x86 32-bit boxes. Still, if Microsoft had produced NT 5 in 1998 as planned in both 32- and 64-bit versions, then the Alpha would have been the only platform besides IA-64 that would have been available, but 4 years later this is all just old news (and getting more useless every day, except for the "learn by example" of what not to do if you want your Tech company to continue living).
Regarding the suit between DEC and Intel, my money was on Intel having "borrowed" IP from the Alpha team, especially the wetware they hired away from DEC to learn how to build high-speed silicon. At any rate, I don't believe Intel paid for the suit, but for the Alpha FAB in Hudson Ma., which would still have been worth some $$$ prior DEC to getting sold to Compaq. This freed DEC of some debt, as well as having the cloud of the underlying lawsuit eliminated prior to the buyout.
Given "The Register" comments a few weeks back about even 2nd Gen IPF CPU's merely being almost equal to current RISC CPU's because the complier engineers are still trying to figure out how to build EPIC-savvy compilers, I'd say we still have a ways to go before we see the IPF CPU's killing off the other CPUs. Remember, Compaq declared Alpha "Dead" just before the HP merger announcement, just like DEC sold off the Alpha FAB just before the Compaq merger announcement. Lots of this just seems to be business, not technical.
Intel has the megabucks needed to continue building FABs; neither HP or Compaq do, and certainly not now after the merger. Both went "fabless" just like SUN, and for the same reason. This ties them to the IA-64 EPIC architecture in a "bet-the-company" fashion, so it is also no surprise that Compaq sent some of its best Alpha Compiler people over to Intel as part of the Alpha death announcment; Intel needs good 64-bit Compiler designers, and the Alpha team was some of the best around.
And for all those reading this and thinking - "Why should I care about the Alpha?" just remember. Alpha CPUs used to win benchmarks by wide margins once upon a time, especially floating point ones. And this was at a time when all the other CPUs were still 32-bit (1993-1994 - except MIPS), so they had an advantage over Alpha - no extra overhead from doing everything in 64-bit mode. So the Alpha's won even though they were "handicapped" by the 64-bit overhead, at least until DEC sold the fab, and Compaq took over. Just go back and look up the benchmark results - Alphas stayed at the top or at least competitive until their speed stopped rising, because of lack of investment.
So all you SUN lovers out there - keep your eye on the "Solaris on IA-64" story; if HP/Q get the IPF CPUs competitive (with appropriate compilers of course), they will have a significant price advantage over SPARC. IBM of course owns its own fabs, and had "built-in" market share for the z-Series (Mainframe) and i-Series (AS/400) boxen, so it can still make high-end RISC CPUs. I just wonder how SUN will be able to continue with SPARC past this next generation coming.
Of course, your mileage may vary ...
**AC**
Well yes, the alpha put up good benchmark numbers, but it also ran about 5X the speed of the competition. I think that the numbers have sess to do with compilers and more to do with fabs.
Yea apple jelly is better than grape jelly, but there is no need to spread the word; there is not enough difference.
If you still have the article somewhere can you please post a link to it?
Thank you