Domain: linas.org
Stories and comments across the archive that link to linas.org.
Comments · 68
-
Re:Will somebody please whack me with a clue-stickConsider yourself whacked:
Read the official web site Linux/390 and you will see that all the work is being done on VM and not on bare metal. Once you're on VM, bare-metal is easy but why would anyone want that?
-
Re:Intriguing! (Rumours)
I find it intriguing that the rumours always fail to mention the Linux/390 site where the actual work is going on: Bigfoot-- Linux on a Mainframe. Why do the news reporters carry this as a rumour? Doesn't anyone fact check? And why does it say "IBM is doing this"
... only a small fraction of the people involved in this project are employed by IBM, its seems weird that IBM gets all the credit. Whazzup with that? -
UCD not CMUYes, UCD seems to be staying on top of the evolving spec better than CMU is. And I see that RedHat now supplies UCD instead of CMU.
Here's some miscellaneous URLS's:
http://linas.org/linux/NMS.html
http://netman.cit.buffalo.edu/Archives.html
http://gxsnmp.scram.de/
http://www.cforc.com/cwk/net-manage.cgi
http://wwwsnmp.cs.utwente.nl/software/utwente.html
http://netman.cit.buffalo.edu/Papers.html -
Re:What would the purpose of this be?To put it bluntly: I'll believe it when I see it.
Then go and download a precompiled kernel and bootloader from http://www.linas.org/linux/i370.html. Note that this is a port that Linas Vepstas and others have been working on for some time now -- it's different to the rumoured "official" Linux port by IBM to which this story refers.
-
Great Satans never die ...Note that IBM manages to avoid mentioning or discussing the Open Source version of this port: http://linas.org/linux/i370.html.
Instead, we have classic FUD: press releases reporting rumours of what IBM may or may not be doing. Stuff designed to scare away contributors and supporters of the legit, above-ground, out-in-the-open development of the Linux Mainframe port.
Don't trust anyone over thirty [employees] !
-
Re:what the hell is the processor on these machine
They're mainframes. These are not normal computers.
Err, umm, once upon a time, mainframes were one of the few sorts of "normal computers" around. They don't look like PC's, but PC's are the only type of "normal" computers if you take "normal" literally, as in "average", as in "the average computer, by sheer numbers, is probably a PC" (I neglect embedded systems here, which I suspect may well outnumber even "IBM-compatible PC's").
They may not even have conventional CPUs at all.
The S/3x0 instruction set is pretty conventional - 32-bit, 16 general registers, register-register/register-memory/memory-memory instructions, most of which are boring old load, store, add, subtract, multiply, divide, etc., with various more exotic add-ons. Just because something's a mainframe, that doesn't mean its instruction set and CPU are immensely exotic.... (The Burroughs mainframes, and their Unisys A-series successors, have a fairly exotic instruction set, but IBM mainframes don't.) The ESA/390 Principles of Operation manual documents the S/390 instruction set.
That's why most mainframe programs are written for the VM which hides the actual hardware from the programmer.
If by "the VM" you mean "VM/390" or whatever it's called these days:
- it doesn't hide the underlying user-mode instruction set from the programmer, it just provides a simulated "bare hardware" machine letting you run various S/390 OSes at the same time on the same machine;
- I doubt that "most mainframe programs" are written for it - the programs that run atop VM are largely OSes, and the applications are presumably written for those OSes (OS/390, ESA/VM or whatever DOS/360 turned into, etc.).
Perhaps you're thinking of System/38 and AS/400, where the compilers used by application programmers don't generate native machine code, they generate code for a virtual machine, and the low-level OS code ("system licensed internal code") translates that code into the native machine code for the particular machine, if it hasn't already been done, in order to run it (that native machine code being a System/3x0-like instruction set on older machines, and an extended flavor of PowerPC on newer machines).
glibc
A port is in progress, according to the Linux on the IBM ESA/390 Mainframe Architecture page. ("A port of glibc has been started. System calls work. Signals don't.")
Xfree86: you're kidding, right?
Perhaps porting the X server code would make no sense (although there do exist graphical terminals for mainframes - I think they're still used for engineering and scientific work), but the X client code might be useful.
SMP: this is really an Intel thing
As far as I know, "SMP", meaning "symmetrical multi-processing", as in "multiple processors, without particular processors being devoted to particular tasks such as 'one processor runs OS kernel code and another runs user-mode code' or 'only one of the processors is allowed to ever run kernel code' (as opposed to, say, a single kernel lock allowing only one processor at a time to run kernel code), has, as a term, been around longer than have SMP systems with Intel processors. SMP systems, whatever they've been called, have definitely been around longer than have SMP systems with Intel processors....
-
Re:what the hell is the processor on these machine
The processor instruction set is a super-set of the ones found in PowerPC (I think).
Nope. It's a 16-general-register CISC instruction set (dating back to the early 1960's). The Linux on the IBM ESA/390 Mainframe Architecture page has a link to the the ESA/390 Principles of Operation manual, which describes the instruction set.
-
Old News/More Info
This is Old News, in computer terms.
LinuxToday ran a story on this back in mid-October. In it, they referenced an article in the Danish version of ComputerWorld. The feedback comments to LinuxToday are interesting, and several of them pointed out one project's home page. -
Linux on the IBM ESA/390
This has been done on the IBM ESA/390. See the Linux on the IBM ESA/390 Mainframe Architecture project. Unfortunatly it's still in devlopment. So no banks will be using it.
:-)
And there is a project looking at the possibility of a AS/400 port. It's not even in development though.
-
I've seen this somewhere before
Let's see...
Here it is: Linux on the IBM ESA/390 Mainframe Architecture -
Some other places to try
Project Management & Bug Tracking for Linux
Linux Center: Project & bug management
And then a short mention of something here TLUG Mailing List
-
Re:Dangers of "semi-open" sourceYou've got a point that IBM nearly dealt a death blow to VM by witholding its source. But then, IBM's been trying to kill VM for a long time. Too bad it's the only way to run MVS^WOS/390 second-level, huh?
Nevertheless, if I had to pick *one* large company right now that "gets" Open Source, and isn't attempting to cash in on it as a cynical ploy to get a lot of cannon fodder to throw at MS, it'd be IBM.
IBM is finally remembering that it is, and has always been, a service company, not a hardware, and not a software company. And, of course, there's the article over at Linux Today--I tipped
/. off to it, but they haven't deigned to acknowledge the same: that IBM has ported Linux to the S/390. I know that some really smart people have been doing the same on their own: Linas Vepstas and friends. IBM would gain a lot from bundling Linux with a VM distribution, of course: that would stanch some of the flow of people off mainframes onto Unix boxes. Further: what are mainframes good at? That's right, I/O. What do you need for a heavily trafficked web site? Hunh. Funny thing that. An S/390 running Apache would be something to see. And for those of us who much prefer VM to OS/390...well, it'd be pretty nice if Linux/390 sat on top of VM but not OS/390. Especially if it could also run on the bare iron, so those of us with Linux boxes plus Hercules could run it at home, just for the "hey, wow!" factor.I view Sun's latching on to Open Source as a self-evidently cynical ploy to get some attention. But as long as they are primarily software/hardware providers, they can't *really* get behind the penguin, because it's going to cut into their Solaris market. Watch: I give Star Office six months, and then they kill the standalone versions and only develop the Java client, which you can only use with the (Solaris-only, I bet) server piece, which will cost real money.
IBM, on the other hand, makes most of its money on service. Open Source is great for them, since it means they don't need to pay developers to write the stuff. They've got an army of people doing it for them, for free. And since their plan wasn't to make money selling the software in the first place, then it doesn't hurt them to give it away. They still sell you the service on it.
I don't trust Sun. They have every reason to turn around and screw us when the opportunity strikes. IBM, at least, has fewer such reasons.
Adam
-
Re:Reality check time folks...
As far as the OS/390, heh, Unix-like OS? As long has you don't mind submitting your "Unix" command, wait 2 days for it to reach the begining of the batch queue, then going to the datacenter to pick out the print job for your "ls" command.
OS/390 got its UNIX 95 certification before Solaris 2.6/SPARC got its UNIX 95 certification.
This may or may not actually mean anything more than "few people didn't think Solaris was UNIX, but people tended not to think of OS/3xx as UNIX, given that using its Time Sharing Option was, once upon a time, likened by one UNIXer to 'kicking a dead whale down the beach', so IBM had more incentive to get OS/390 through certification."
But, yes, it does have a UNIX-compatible environment, although it's not compatible at the character-set level (i.e., it uses EBCDIC, not ASCII...).
Of course, there are options being contemplated that would presumably use ASCII ("Well, the radio's exploded, what's on the mainframe then?" "Looks like a penguin...." The kernel "usually boots to the point of mounting the boot ramdisk, and trying to start
/bin/sh", but "bombs because umm, diferent reason every time"; a glibc port has also been started. I wonder what hardware they're using....). -
urls
Linux Network Address Translation is a really good explanation of what's available for Linux and how NAT works in general. (Or, at least, links to those things.)
I think the package offered at Linux IP NAT Forum is the one I tried to use. There's nothing wrong with it, but Linux's arp is inherently broken to my eye and it had become too great an irritation to make Linux do what I knew I could do in an hour in...
OpenBSD, using ipf and ipnat (the real and original way to do this, also available on Solaris, I believe). -
Re:Eh?
Well, the S70 AIX box is very similar to the largest AS/400 PowerAS. It uses the same CPU too. And it ought to be able to support Linux (don't think anyone has done that yet though), I don't know if the current AS/400 hardware is capable of running in 'tag-less' mode (neccesary for running any UNIX like system). On the VM front I've seen some work being done and I even tried to boot a kernel but it didn't work
:-/ (I'm no '390 guru) see Linux on the IBM ESA/390 Mainframe Architecture for some info..
Erik
Has it ever occurred to you that God might be a committee? -
Re:A Powerful Meme
Linux runs on everything from PalmPilot's and Itsy's to IBM System/390 mainframes.
I'd say that, at present, it "limps" rather than "runs" on IBM mainframes; the Web page for S/390 porting efforts says:
A port of the Linux kernel has been started. It compiles. Some things work, most things don't. System calls seem to work. Context switching works as long as you can avoid sneezing near it. It can mount a file system on a good day
...The Palm port (or, rather, the MMUless microcontroller port, which includes the Palm port) appears to be further along, but I don't know if it's something one could usefully run on a Palm yet or not.
-
linux + com ... is it about sales?
Hmm, "linux" and "com"mercial... I hope they host things like the Linux Business Solutions Project. I realize it looks like PHB fodder, but I've found that page useful in the past myself.
-
It's not a theory - it's factIt's very obvious you don't know how RAID 5 works.
Oh, save the condescending attitude. I work with RAID systems every day. Don't tell me I don't know my job.
You conveniently ignored what I said, so try to pay attention this time: to write a RAID 5 partition you must reread parity information from the disk, unless you are doing a Full-Stripe-Write; you need to write (ndisks -1 ) * stripe_size bytes of data in one operation to avoid the performance hit. Oh, and that data has to aligned on a stripe boundary, too.
Otherwise, you end up doing either a Read-Modify-Write or a Reconstruct-Write, and that's expensive.
For write-intensive filesystems, don't use RAID-5
My source for this?
- Linas Vepstas' RAID-HOWTO
- These Veritas course notes I have in front of me.
Now are you going to tell Veritas that they don't understand RAID either?
First, yes it's an XOR (at least you got that right). However, reading takes just over x+1/x amount the time of reading from a RAID 1 set. Just over being the time it takes to do an XOR and comparison.
You're wrong there, too, by the way. Reading a RAID-5 volume is just as quick as reading RAID-0. No XOR'ing needs to be done when you read. And you have the cheek to accuse me of not understanding RAID-5?