Slashdot Mirror
Main Linux Distros Port To IBM's S/390
SuSE has announced that they are going to release a beta SuSE Linux for IBM's S/390. A beta version will be out in late June. TurboLinux has signed an agreement to port their Linux distribution to S/390 as well. The only major distributor that is missing here is Redhat. What do you think about Linux distributions and the S/390??
Aside from the target market, ISPs, not many folks will have a financial or work-related interest. I certainly won't. I've only worked at one company that even had a mainframe, and I was a user, not an admin at all. I'm still not an admin, and it's just not that likely I'll ever work with an S/390 or its successors.
However, I still care. This is really neat stuff. It tells me stuff about Linux, Linux kernel hackers, and IBM that are all good to hear. Just knowing that people are using Linux in this way, and that it works, is something I care about.
There are plenty of things which I care about that have little or no practical use to me. I'm probably never going to go to Mars, or other planetary systems. I still care about the research being done on them. I may never visit South Africa, or buy anything made there, or know anyone who lives there. But I'm still glad that the ANC won without a bloodbath. Only someone with no empathy or imagination would think that only those directly affected can care about something.
Many of the newer IBM mainframe machines are air cooled (no water chiller needed) and could probably be run in a normal house with a decent air conditioning system.
While I'd agree that Linux on S390 doesn't need CICS to be useful, CICS isn't strictly a mainframe thing. IBM has versions of CICS for AIX and OS/2. There are 3rd party software developers who do products like UniKix which is a CICS emulator for many of the commercial UNIXes. There isn't any reason why one of those couldn't be ported to Linux on S390.
The reliability of a mainframe comes not from the software (though that is a factor) but from the hardware.
Wrong. It comes from redundancy built into both the hardware and software. The hardware is only as reliable as the software running on it and vice versa.
Finkployd
I work on a fairly small mainframe (oxymoron) running OS/390, programming COBOL on loan systems on a small co-op bank--I've got a PII/450 running W98 on my desk that only gets used as a 3270 emulator (and Web browser when the boss isn't looking). There's nothing new, sexy, or "hip" about S/390 mainframes, but they are dead solid reliable. They just don't break.
So of course our CIO is hellbent on scrapping our ugly but functional COBOL-based systems for the Brave New World of client/server, VB 6, SQL Server 7, Microsoft everything, distributed processing, blah blah blah. Forget what works, it isn't New! and Improved! so we dump it and go for eye candy. This is why I like seeing stuff like this--keep that super-reliable raised-floor gear but bring it forward into the 21st century, or at least the mid-90s.
This sure seems like the best of both worlds--mainframe reliability and *nix flexibility. Now, when the heavy iron operations people meet the Linux geeks, that is gonna be fun...
"Settle down, Beavis. We've got an experiment to do."
While the availability of our familiar distributions is nice, it's not that important in the scheme of things. Of more significance, by far, is that fact that IBM is now officially supporting the S/390 port. It had previously been available for free download, but that's not going to convince an IT manager to install it as a mission critical system. The fact that it is now supported by IGS (IBM Global Services), however, is likely to make them sit and and take notice. IBM offering the same consulting and implementation services that they offer for other S/390 OSes is a major boost. It make Linux/S390 into a mainstream platform. The importance of that shouldn't be underestimated.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
I think you can get S/390 cards for your PC. You won't get the mainframe reliability - which is the whole point of having a mainframe - but you will get a good chunk of the speed.
Even an S/390 emulator might run Linux at reasonable speeds, if you run the emulator on a modern PC or workstation.
-- Ed Avis ed@membled.com
Actually the point of the articles and press releases is that Linux will now run natively on an S/390 and not just inside a virtual machine on OS/390. That is pretty damn cool :)
:-) and crazy I/O channels.
:-)
Yeah, that is pretty damn cool, but not terribly useful. I think it would be much more useful running under a virtual machine. Linux just can't possibly take full advantage of that hardware, what with all the billions of CPUs (err... maybe not billions
I'd love to see some performance specs on Linux vs OS/390!
I'm sure it would get creamed. Except for Intel chips (maybe others too, but I know not Alpha or PPC), Linux is generally not as fast on the hardware as operating systems which were designed specifically for that hardware.
On a related off-topic topic (?), does anybody know if Compaq is still doing that free Tru64 for personal use thing? I'd love to give that a test drive on my Alpha (or, if nothing else, just steal the math libs and compiler to run under Linux with the Tru64 emulation libs
--
Heh, just call me picky today... :-)
It surprises me how most people don't remember that VMS was born on the VAX architecture. Not too different from the folks who think that PCs started with Pentiums. I'll concede that it was more of an oversight or omission than an error.
Methinks you're referring to an older version of VMS. It's had a journaled filesystem (the Spiralog file system) since v7.0 or maybe the later v6.x releases (if memory serves). Don't ask me about it though; we never used at the last VMS site I worked at though I know some people swear by it (while others swear at it). It's not IBM's jfs, DEC's advfs, or whatever Veritas's is called but it's not really FAT-like either or so I understand. Now Files-11 is/was sort of FATty but I've never actually had a corrupted file on a File-11 disk while I've had, and seen countless other people have too, plenty of experience losing files on FAT-based filesystems (via the infamous cross-linked cluster problem). I suspect, though, that most of those losses were due to essentially being root on the PC when using DOS/Windows and its propensity to crashing. If I ran around on VMS systems with BYPASS privilege turned on all the time, I would expect more problems.
As for the drive letters: I never found the drive naming to be a problem. It was tons better than PCs had at the time. I suppose it depends on whet you used first. Personally, I'd find it somewhat annoying to go back to drive letters nowadays. In fact, I currently find it annoying as hell that Linux still uses sequentially assigned drive letters in the SCSI subsystem when other, more transparent, naming conventions exist (especially, since I was using a PC UNIX in the early '90s that didn't have this limitation). One wonders why the kernel developers seem to hate the way System V handles SCSI devices. Oh, well.
Just what are the complaints about Compaq's hardware? I've never heard anyone complain about the VAX and Alpha hardware before other than about the price. Now Compaq's PC hardware? That's another story and I do know of techs who will say it ``bites''.
Not sure what you're driving at with this comment. What kind of ``cluster'' is this, I wonder. It sounds like you mean hardware fault tolerance. Buy a Tandem or a Stratus. They're hard to beat FT-wise. Of course, you gotta have some pretty deep pockets to consider those hardware platforms.
rtscts? Gee, I'm still getting by with xonxoff.
--
CUR ALLOC 20195.....5804M
Anyone who receieved a Linux Journal in the last few days will notice there is a HUGE article about the S/390 and the linux port done by both IBM and hte Open Source community.
:)
It also goes to mention that in the IBM port, there are a couple of core level modules (i'm not much with a S/390 so not sure what they are) that are object code only, IOW, not open source.
I have no problem with this other than the fact that Debian, which is mentioned as having a port in the works (the writer of the article is a core debian maintainer), prides itself in being a "Free Software Only" distribution. I'd really like to hear some comments on why that is or should be any different for this case.
The big advantage from what I can tell is not even runnign linux as the core OS, but running it under the very powerful VM mechanisms in the S/390 (the article explains how the VM is actually tied into the HARDWARE, which just plain rules) allowed the writer of the full free software kernel port (which is not finished, IBM did a private port and announced it this month) to START OVER *41,000* COPIES OF LINUX + THE APACHE WEBSERVER! Good LORD!
So don't kid yourself, with native power like that, no one is going to even bother running linux standalone on one of these things, not to mention there is much cheaper, adequate hardware that will run linux by itself - a S/390 is a very high end machine and chances are it's going to be a cold day in hell before the suits let you throw your "Free OS" directly on the machine.
But that doesn't matter, from the article I gathered it's going to be much more popular in a VM.
-Erik-
If you give me a free S/390 I'll do a review for you...
--
Have Exchange users? Want to run Linux? Can't afford OpenMail?
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
You are right, Mhz isn't everything. For the 390, it is fairly telling. I don't recall any superscaler implmentations. I don't beleve it has a fused FP multiply and add. For FP it just isn't all that fast, nor even for 32 bit integer math. On the other hand it's BCD math can be quite fast (single instruction for most ops, something like 40 or 60ish digets supported in hardware, more possable with OS assist). Translate table instructions.
If it's I/O you need fast a 390 can do it. If it is something else you need fast, there is almost certonally another computer that will do it better. Frequently even made by IBM :-)
For FP Fortran code, I would guess a Alpha would really run much faster (in absolute terms, or per dollar) then a 390, unless you have quite a bit of I/O going on. Even then maybe. I'm sure Compaq has a F90 compiler.
Of corse the 390 is very very very good at making sure that the answer you get is right. It's somewhat fault tolerent, but more importantly for many applications it actaully notices many kinds of breakage and will let you know about them rather then blondering on with the wrong answers.
At this point there are 76148 machines registered; one of these could increase this number by 50%!
I heard that they were going to phase out totally in favor of Linux.
I wonder what the banks will think of that?
I guess my stupid questions is Why? What advantages are there to running Linux on a mainframe?
If you aren't part of the solution, there is good money to be made prolonging the problem
Now I have to clean out my basement. There's nowhere else in the house big enough for an S/390 and the disk farm that I'm going to want attached to it. And I'm definitely going to need something faster than a single cable modem. My heating problems are solved!
The net will not be what we demand, but what we make it. Build it well.
You are lost in a twisty maze of little standards, all different.
Linix has software reliability - and can be hardened even more. But the platforms it runs on die when the bits get dropped.
On mainframes, no bits drop. (Actually, they do. But the mainframe fixes it and keeps on going. So as far as the software is concerned the computer is perfect.)
Now suppose you want to do a reliable web server for an enterprise:
- You could do a farm of PCs running Linux and Apache. But when a processor failes you lose the transactions in progress there.
- You could port Apache to (or write a web server for) an ordinary mainframe OS.
- You could port Apache to a mainframe Unix. (Has been done for UTS - Amdahl's mainframe SVR4. But while that will run on IBM mainframes it isn't from IBM.)
- You could port Linux to a mainframe. Apache and EVERYTHING ELSE UNIX/LINUX comes along for free.
Lots of other uses for Linux on a mainframe, of course. Mainframe reliability, capacity, and speed, combined with Linux reliability and functionality, is a powerful combination. But I bet enterprise-reliable web servers are the first "Killer App".
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
I think the whole point is, you'd have one machine doing nearly everything. Have one LPAR running /DB\/?2/ maybe running some legacy cics/cobol apps, have another one running linux as a webserver / samba server. It can talk to the db2 server with a ridiculously high-bandwidth connection. need another server for something, or want a test environment? Just fire off another one.
MVS, while unpleasant at best, from a user's perspctive, has power roughly equivalent to an aircraft carrier. If you want to abuse that metaphor a little (and I do), maybe linux is the fleet of planes based off that carrier?
Anyway, we have some big iron here where I (for the next week at least) work, and there are aspects of it that rock nads. It's uber-reliable, and relatively low cost, in some respects. For companies that already use mainframes, this is simply beyond cool. We all know how well linux integrates with disparate systems. MVS is about as poor at that as linux is good, so this could be a piece which ties everything together.
One more drink, and I'll move on. --Dave Matthews Band
The only problem with porting Linux to a mainframe is that Linux is probably too slow. I work with an S/390 at Northern Illinois University, and have experienced firsthand just how slow mainframes run. Contrary to popular belief, mainframes are not fast machines - the average Sun server can run circles around a mainframe in terms of instructions executed per second. However, mainframes make up for slow processor speed with massive IO capabilities - and given that most data processing tasks are IO bound, this is good design. However, Linux wasn't designed to be run on systems where every single processor cycle counts, and MVS was. Granted, MVS is a piece of junk from the user's perspective, and I would rather run Linux any day. But I don't think that Linux will make successful inroads into the mainframe community simply because it is a processor-cycle intensive operating system; this isn't a problem on PC's which have processor cycles to waste, but on a mainframe, where every clock cycle counts, Linux would probably be more of a drag on the system than anything else. Think about it - if you have to process 250 million records, you don't need the OS taking away any more clock cycles than absolutely necessary, and a kernel written in C with portability in mind can't possibly be as efficient as one written specifically for the hardware (and probably in assembler).
The society for a thought-free internet welcomes you.
Depends on the "they" to which you're referring, and on what "quite large" means. According to the S/390 Multiprise 3000 Reference Guide, the "Base (CPC) Frame" for said machine is 520mm wide, 1110mm deep, and 819mm high, or 20" wide, 43" deep, 31.5" high for us Yanks, and, according to this page from the S/390 Integrated Server Technical Application Brief, that box is about the same size (533mm wide, 1038mm deep, 819mm high).
No, of course not.
The same applies to Linux/x86, of course; let's pick the one distribution that should be the only one on x86. :-)
As far as I know, the "port", in the sense of "kernel, glibc, compiler, binutils (and perhaps gdb)" (i.e., the part of a Linux distribution that contains the most platform-dependent code - other than perhaps the X server) has already been done, just as it's been done for x86, Alpha, etc.; I presume what TurboLinux, SuSE, etc. will be doing will be combining that with their distributions to make S/390 versions, to go along with versions for whatever other processors the distributors in question support.
1. We've been able to run Linux on S/390's for a long time, in virtual machine mode. This is pretty neat but has limited practical usage. 2.IBM has had Linux available for the S/390 since January! 3.A mainframe is VERY expensive to purchase and maintain (or lease). Who's going to make that kind of investment to run an operating system that wastes a good percentage of those expensive MIPS when OS/390:MVS does a much better job? 4. Mainframes are used for mission critical, enterprise level proccessing. Who's going to tell the 25,000 users who depend on the mainframe to do thier jobs, that we're going to switch operating systems and then rewrite or recompile the 18,000 jobs and associated programs that execute every night? Not me. I like my job. *--> "Go away or I shall taunt you a second time!" *-->
I knew nothing at mainframes until I worked at a shop where one was used. Coming from a Windoze/UNIX background I was really really surprised to learn that there is this whole other mainframe universe in which there are many people working, coding, and living as if Windoze and UNIX didn't even exist. (Well, of course they're all aware of Microsoft.)
I got to learn a little bit about OS/390 (the operating system which runs on those mainframes) and it's a nightmare (in this UNIX bigot's opinion). lrecl, fb or vb, PDSes, GDGs, ftp commands like 'put BFDG.XD.DIWDOS(+1)', ISPF, fortythousand acronyms, gawd. From what I understand, IBM didn't even consider supporting TCP/IP until about ten years ago or so -- for a very Microsoft reason: they don't want to support any protocols they can't control (see also Direct3D vs. OpenGL and kerberos). There are several thousand supported instructions on IBM's assembler for OS/390. This is because there was such a huge number of assembler programmers for OS/390 IBM kept adding instructions to make programming easier. If I understand correctly, I think there is even a "print" instruction in OS/390 assembler.
90% of IBM's products =~ m|\w\w?/\d{1,4}|;
But the IBM of today is, what appears to me, a very different company. The prospect of running Linux on IBM is, in my mind, revolutionary for IBM. The prospects of Linux on IBM look really cool -- kind of like compacting hundreds of linux boxen into one big, black, airstreamed box with a big, red, candylike power switch that screams "Flip me!" So I think this is great. The more Linux, the better.
I don't make the rules. I just make fun of them.
Sorry, but most fortune 500 shops rely upon IBM mainframes to crunch through the data in their core business applications.
;)
Although Linux is an elegant OS with a bright future, at the moment it suffers from youth and the deficiencies of its original platform: the PC.
1. Raw I/O throughput. The strength of a mainframe resides primarily in its enormous capacity to move data through I/O channels. Separate I/O controllers handle most devices (like the I20 architecture), so the main CPUs are free to focus on computing tasks. The PC is not even in the same league--yet.
2. Advanced enterprise features, such as hierarchical storage management. Although Linux is moving towards LVM (Linux Volume Manager) to handle disk space, the mainframe data management facilities go one further: the OS will automatically migrate unused data from "small," fast hard drives to slower, larger hard drives, and finally to removable tape storage. This means that, unlike Linux where we manage mount points and disk partitions, the OS takes care of moving data around on all of its volumes to ensure best access. To the user (and an administrator), the sum total of all available hard disks and all cataloged tapes represents the complete collection of available data: terabytes upon terabytes of storage!
3. Another advanced feature: machine partitioning. Although incorporation of the User Mode Kernel is a step in the right direction, OS/390 (and high-end UNIX platforms, such as SUN, as well) allow an adminstrator to _partition_ a machine into completely isolated units, or partitions. Not to be confused with the Virtual Machine capability much discussed with Linux on S/390, but a partition is simply a fixed allocation of CPUs, memory, and I/O devices to an instance of a running OS/390 system.
What that means is 1 box may be split into multiple partitions, and each partition may have completely separate disk drives, memory, CPUs, etc. Basically, each partition becomes it's own machine, which can be useful for segregating activities onto different sets of resources (e.g., a test or development partition and a production partition). S/390 can do this because of hardware support, but unfortunately, efforts such as the User Mode Kernel do not achieve quite the same results: the "partitions" or "user mode kernels" still share the same underlying kernel data structures. If one UMK craps out, it could potentially bring down the whole machine.
Of course, give the Linux/Open Source community another 6 months, and it will solve all of these in spades.
Meaning a native port of some flavor of UNIX, or S/390 Open Edition? If the latter, then you may already have given the reason:
meaning it may be easier to put Linux on an S/390 (or in a virtual machine or logical partition on an S/390) than to put some New Economy Dot Com applications on Open Edition.
General-register-based architecture, 16 general-purpose registers, 4 (or is it 8 or more, now?) floating-point registers, memory-to-register and register-to-register arithmetic instructions - not all that different from VAXes, 68Ks, x86's; it's just another general-register-based CISC box. (Yeah, it has specialized instructions, but so do the other CISCs for which GCC generates code; you don't necessarily have to use them.)
The relatively short offsets in instructions may be the biggest problem.
Linux has already been ported; presumably SuSE and TurboLinux will be integrating the kernel, glibc, GCC, binutils, GDB, etc. changes into their distributions.
There's been S/370 support in GCC for a while,a s I remember; the S/3x0 config directory of the EGCS source includes notes and checkins that suggest support (e.g, the 1.3 version of the README file says that it currently "supports three different styles of assembly", including MVS using the HLASM assembler, S/390 Open Edition, and "ELF/Linux for use with the binutils/gas GNU assembler".
There's also, in the GAS CVS tree, tc-i370.c and tc-i370.h files (which are for S/360 and S/390 as well as S/370, according to the comment).
I suppose that building a mainframe distribution is very costly. (I suppose they need at least one expensive actual mainframe to do the testing, don't they?)
And then, since it is mainly GPL software, you could buy just one copy (disc? tape?) of a distro and install it in all the virtual machines of all the mainframes in the company. So you have a maximum number of sales as big as the number of Data Processing departments that run S/390s. I expect this number to be small, at least, compared to the number of individual-owned PCs.
So I think that the number of sales of these distributions has to be very low (comparing to PC distros). And media sales is the main revenue of distribution makers.
Am I wrong?
__
__
Men with no respect for life must never be allowed to control the ultimate instruments of death.
GW Bu
This would undoubtedly be a neat hack, and nice to have, but first, I'm guessing this is going to impact roughly 0.02% of slashdot, and second, they shouldn't be doing it for business reasons, since there already is UNIX on os/390.
At my job I spend a lot of time working with IBM's Open Edition, which is a UNIX that IBM implemented on top of os/390. It is very, very strange as UNIX goes. A lot of common things you associate with unix aren't there like a password file, and other common facilities. Things are put in very strange places on the filesystem, and the way the backend works, (i.e. how it interfaces with MVS) is far weirder than weird. That said, it's a very interesting system that seems pretty stable.
Unfortunately, none of the architecture dependant GNU utilities will compile on this beast, since the hardware isn't even similar to anything unix boxes are used to running on. If suse is going to port linux, they may encounter the hardest part in porting things like gas and gcc, since AFAIK they don't know how to spit out binary for this CPU as of now.
(FYI for people who aren't familiar with OS/390 - it's IBM's mainframe OS. These types of boxes generally start in the $60,000 range for one that probably isn't worth using, and range in price up to the multi-million dollar range. On the one I work on, each individual CPU costs $200K.)
That's why I say probably most slashdot readers won't care. For the vast majority of people, they never work with a mainframe because the only people who can afford to have mainframes are large organizations. (The federal reserve has some bitchin huge mainframes)
-- Truth goes out the door when rumor comes innuendo. -- Groucho Marx
Molog
So Linus, what are we doing tonight?
So Linus, what are we going to do tonight?
The same thing we do every night Tux. Try to take over the world!
Fair enough: you are correct. That's the point of "user mode kernel:" if it's in user-space, it can crap out just like any other user-space app, so the rest of the system is safe.
However, valuable as UMK is for some applications, it's (yet) not in the same league as mainframe partitioning.
1. The OS and system software on mainframe partitions may be upgraded separately without affecting other active partitions. UMKs, too, can be upgraded, but if the real kernel has to be upgraded, the whole machine goes down.
2. How well does the UMK protect the underlying real kernel (and thus other user-space apps) for excessive resource consumption? For example, what if an errant application running in an active UMK (or just buggy code in the kernel used by the UMK) starts spawning threads like crazy, will the UMK protect the rest of the real machine from adverse effects?
3. The UMK kernel, valuable as it is, is still limited in it's ability to differ from the true underlying kernel. For example, can a kernel within a UMK provide a different thread-scheduling policy that the underlying real kernel?
BTW: don't get me wrong, I love UMK and what it can become. It's quite an accomplishment to put such a thing together. Further, I may be incorrect about the completeness of it's operation. However, my whole point is to emphasize how in IBM's mainframe environment complete isolation of distinct partitions is very easy, and it's a feature that the Linux commmunity may wish to emulate as it moves further into enterprise computing territory.
They arn't so much faster and more reliable then the latest cluster systems so much as actually being the latest cluster systems. Oh, and being far more reliable (lots of check logic, ECC on the cache, and register files, not just main memory). Not so much the faster part though. The CPUs only run a few hundrad Mhz (last year 300Mhz to 400Mhz was extreamly fast for them). Of corse they have dedicated IO processors, and small tens of CPUs is a common size.
Most of the innovations in clustering in the micro world is re-inventing what mainframes have allready been doing. Then again so was having caches, and out-of-order execution. That's not to say micros didn't invent something, or that finding the right time to re-use what had gone before isn't hard in and of itself.
Your basic S/390 can run 200-300 Linux server images under VM. Taking the usual uptime and hardware failure figures into consideration, these 200 Linux "servers" will be VASTLY more reliable than the equivalent "real" Linux servers. In any large hosting environment, you've got machines crashing hard every week -- the MTBF really comes back to bite you when you're dealing with hundreds of physical units.
IBM doesn't think anybody in the world will go replace MVS with Linux. They're trying to grab the hosting market. Don't forget, when we talk about running 200 Linux servers, they're not talking about 200 hosting accounts -- they're talking about the equivalent of 200 actual servers, each of which would have bunches of hosting accounts on it.
Nobody is going to switch their bank transaction stuff over to Linux. IBM's just aiming for Sun. Besides which, I'm sure they're thinking about eventual transitions, etc.
. . . of course I could be wrong.
I have no
Unless they get sponsorship from some huge company. Not that they couldn't do it, just that mainframes are so hugely expensive, that I really doubt they could afford one, or that they own even a small one already. Possibly if some huge company "donated" an LPAR for a period of time it'd be possible, but otherwise I don't know how they'd actually get a hold of the platform to do it.
(I hope I'm wrong about that. Debian kicks ass)
-- Truth goes out the door when rumor comes innuendo. -- Groucho Marx
Why not just download the compilers and math libs that have been ported from Tru64 to Linux?
Hmmm.... well, that's an idea. Although I'd still like to try Tru64.
--
Let's celebrate!!!
--
Here's my mirror
Instead, they want an ISP to buy a 390 and pop a couple hundred Linux "servers" on it, each with their own wad of hosting accounts.
This might actually make sense, as if you're running a truly gigantic hosting farm then you're probably getting bit by MTBF on a regular basis. Using the 390 would significantly reduce your exposure to outages etc.
Now, since each Linux image would be a "real" server, even if it didn't exist in the physical world, the ISP could use their normal admins etc. -- they'd just need to hire somebody to run VM for them.
This way they can run monster hosting farms on reliable hardware, probably save a fortune in power requirements (one 390 vs. 300 PC-level boxen), and they don't have to all start learning VM or MVS.
It's obviously not for everyone, but I really do think it might be useful for lots of companies that wouldn't otherwise even think about mainframes.
I have no
The S/390 is a big mainframe, correct? If so, then Linux on that thing is phat. Not as the main operating system, of course - but as another operating system running on the same machine. That's what so cool about these things - you can run several operating systems at the same time on the hardware. So you could have the main OS serving up huge databases or whatever and then have Linux with Apache serving up web pages, Samba serving up shares, etc. I want one.
--
The only major distributor that is missing here is Redhat.
;)
Does Debian have a proposed port? I'd love to load up Linux on my S/390 here at home... *dreaming*
eraseme
The only major distributor that is missing here is Redhat.
And Debian is not a major distribution? I think you should be a bit more impartial in your comments. "The only" is a quite strong expression.
I'm only playing Devil's advocate, but this sort of logic is only a small step away from that of people who think RedHat==Linux.
> Apart from a few academics running dinosaur equipment, who cares?
Actually, mainframes are quite rare in academia, unless you want to count the registrar and business office. They are found most commonly in business environments: banks, corporate payroll systems, etc.
--
Sheesh, evil *and* a jerk. -- Jade
Apart from a few academics running dinosaur equipment, who cares?
I'll bet you think large companies do all their computing on PC's huh?
You'd be shocked to find that these machines are still being made, keeping up with the latest technology, and faster and more reliable than the best cluster systems.
Finkployd
It wasn't perfect - getting backspace-echo to work well on that sort of I/O controller just wasn't going to happen - but it was pretty close, and you could at least use vi. I was taking a compiler course at the time, doing a lot of compilation, and the choice of timesharing a Vax with ~40 people or using the Amdahl with ~2 people was pretty obvious
Why would you port Unix to Big Iron? Well, not only could you use the blazingly fast 10+ MIPS of CPU (when Vaxen were the canonical 1 MIPS), but more importantly, the distributed I/O architecture lets you do immense quantities of disk I/O to run databases. Not only is this Entertaining Research, but it was valuable for phone company billing and equipment-configuration-management applications, allowing more flexible Unix development environments, and it was a much better development environment that Vax-sized machines for the 5ESS phone switch development folks, who needed to compile and build programs that were huge then and large even today.
On the other hand, fsck took a *long* time to run, since the machines had a lot of disks, and this was back when Unix file systems really did need to be checked every time you booted
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
> efforts such as the User Mode Kernel do not
> achieve quite the same results: the "partitions"
> or "user mode kernels" still share the same
> underlying kernel data structures. If one UMK
> craps out, it could potentially bring down the
> whole machine.
Wrong. If one umk craps out, it affects nothing else. Every umk has its own data structures, completely separate from every other kernel on the system.
Jeff
"Mainframes are known for being very powerful (in IO speed, not necessarily CPU speed)"
This used to be true, with I/O devices directly connected running at channel speeds. However with the advent of cross-bar technology and SANS (12.6GB/s on a Starfire and 100MB/s full duplex disc access using fibre) it is true no longer. A big UNIX box can beat the pants off a mainframe in terms of CPU, I/O and cost.
Where UNIX doesn't come anywhere near the mainframe is in handling a complex workmix and availability. These are the major reasons why you find enterprises running online transaction processing on the mainframe and datawarehousing on a cheaper, more powerful box.
Cluster are catching up in speed, but have light years to go before hitting the reliability and stability of a big iron.
Finkployd
IBM's always seems to have had things like this. Anyone else remember the 370 emulator for the XT that even let you run a version of the VM/CMS operating system on your desktop. (We were a big CMS shop back in those days and I lobbied to get a couple of these cards but they were much too pricy for us.)
--
CUR ALLOC 20195.....5804M
From a purely functional viewpoint the monopoly nukement trials seem to do chock piles of goodness. Look at IBM: it's grown to a very clever player from the ultimate bully. I think every sufficiently big power concentration (governmental/corporational/religious/whatever) should be limited like that; what do our liberalists think? The worst problem is that there should always be a bigger power establishing the limits :P
/. way ago), but large production deployment is only possible with official support.
Running Linux on IBM mainframes in their virtual-machine "userland" is nothing new in itself (was noticed on
I think, therefore thoughts exist. Ego is just an impression.
At Linux PR you can read a bit about the e-commerce apps coming out for that environment.
--
Sheesh, evil *and* a jerk. -- Jade
Following the recent announcements that SuSE and TurboLinux will be releaseing Linux for the IBM S/390 and RedHat's release for the Itanium, Slackware have announced a release for the Commodore 64.
"It just seemed logical to go for a machine with a huge userbase." Said a spokesman with a funny last name who was probably called Rob or something. "Linux scales remarkable well to small machines. In fact much better than it does large servers."
Critics of the company are sceptical about whether the system will be reliable since it comes on tape.
"I just used the CD record feature on my stereo" said Rob. "It works for music so why not data?"
When asked whether a spectrumversion would be available, Rob said "It all depends on the success of this version. We're hoping to port it to all Z80 based machines, and possibly even pre-electronic machines".
Charles Babbage was not available for comment
> However, valuable as UMK is for some
> applications, it's (yet) not in the same league
> as mainframe partitioning.
True enough. I never claimed I was creating the next VM.
> UMKs, too, can be upgraded, but if the real
> kernel has to be upgraded, the whole
> machine goes down.
Yup. But if you ever have a setup where essentially everything is inside a UMK, and the hosting kernel is stripped down to the point that it's just providing processes, device drivers, and a filesystem, then you can run that forever, and just upgrade the UMKs.
> How well does the UMK protect the underlying
> real kernel (and thus other user-space apps)
> for excessive resource consumption? For
> example, what if an errant application running
> in an active UMK (or just buggy code in the
> kernel used by the UMK) starts spawning threads
> like crazy, will the UMK protect the rest of
> the real machine from adverse effects?
The UMK, just like a native kernel, runs in a constant amount of memory. You configure it with 64M, that's all it will ever use. You configure it with 4 processors, it will never have more than four processes running at once. So, you can protect the native kernel from excessive resource consumption by sticking things inside a virtual machine.
> The UMK kernel, valuable as it is, is still
> limited in it's ability to differ from the true
> underlying kernel.
No it's not.
> For example, can a kernel within a UMK provide a
> different thread-scheduling policy that the
> underlying real kernel?
You seem to think that the UMK is somehow not a full kernel. It is. The underlying kernel is just a provider of resources. If a new version of the kernel provided a funky new scheduling policy, UMK would support it, regardless of what is supported by the underlying kernel.
> However, my whole point is to emphasize how in
> IBM's mainframe environment complete isolation
> of distinct partitions is very easy
Yeah. Nothing comes close. Not even Linux plus UMK. Maybe this is a small step in that direction and maybe some people will find that useful, but there is a long way to go.
Jeff