Slashdot Mirror
First OpenVMS Boot On IA64
vaxzilla writes "At 3:31pm EST on Friday, January 31st, 2003,
OpenVMS for the Intel IA64
architecture
successfully booted and ran a DIR command.
The Intel Itanium family of processors is the third architecture supported
by OpenVMS in its
25 year
history. Originally it ran on Digital Equipment Corporation VAX
systems; in the early 1990s, support was added for the DEC Alpha
processors. Following the acquisition of DEC by Compaq, and more recently
Compaq by HP, the Itanium and Itanium2 port of OpenVMS is now being
undertaken by HP. Congratulations on a job well done to the folks at
ZK03 in Nashua, NH!"
An itanium based platform can produce a listing of files!!!!
This is truly a breakthrough. Intel is waay ahead in computing than companies like Nike or Coca Cola.
Well...considering the heat which Intel processors tend to generate...you could probably just lay your bread in your case...and next thing you know...
TOAST!
I used OpenVMS a bit at my universty, and I have to say I never really got into it - getting my solaris account was a great day! I can understand people wanting to maintain legacy apps (big purchasing systems maybe?) but is OpenVMS really good for anything _new_ today? Does it have any real particular advantages that mean you would want to use it for reasons other that "we've already got a stack of Alphas this high on it and gonna keep using it until forever"?
4GB is still a lot by any standard, but the problem is that the kernel, for example, needs to have some of its structures appear in the process's address space. Shared libraries also need to be in each process's address space, even if it's in memory only once. Even better, you need to leave room for the heap to grow as well as for user-loaded entities (like dlopen()'ed shared objects). In practice, I understand the default restriction for Linux is somewhere in the neighborhood of 1.5GB per process, though you can increase that to 3GB with some libc tweaks. There are a few kernel patches to raise that limit further to 3.5GB, but that's the absolute ceiling (and you are sacrificing what may be important things, like SysV shared memory segments).
Even now, it's not uncommon to see gaming machines with 1GB RAM or more. Even small servers will often have 4GB RAM. In a few years, the number of "high-memory" systems is only going to increase as advances in technology continue to drive down the cost of RAM and drive up the requirements of software. This is especially the case as databases become more important and commonplace in the business world. Everyone uses them now, but we can expect to see them used more often, and in more diverse places, than in the past.
There is also a hope among many of us that Intel and AMD will use this opportunity to create good chips, not just cheap ones. They have the opportunity to fix a lot of the stupid design decisions Intel made 20 years ago and put together a modern, clean system. Unfortunately, it doesn't look like this is going to happen (I don't think anyone at AMD has had an original idea in their entire lives, and Itanium is being designed by committee), but this is the hope. In short, we may not see any immediate performance gains, but in the long term, the design of the chips would enable faster improvements than we're getting with IA32s right now.
THIS CHANGES EVERYTHING!!!
No, wait... what the hell does this matter? We're shutting the few remaining vaxes at work off soon...isn't everyone?
- A.P.
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
I must disagree with you.
64 bit does not mean a thing.
It means something important to anybody who ever has to receive a CAT scan or a nMRI scan... VMS/VAX systems run nMRI and CAT scanners... They use 64 bit architecture during Fourier analysis...
99.99999999999999% of software today does NOT run on it
probably because 99% of software today is used for text and graphics processing; not for mission critical apps. that's kind of like saying that 99% of all driving accidents happen within 25 miles of home... well, geeze, 99% of all driving period occurs within 25 miles of home...
performance difference in mhz between 32 bit and 64 bit processors (especially in the north bridge) makes any performance gained by using 64 bit architecture negligible
I disagree with you. The difference between being able to handle 2^32 and 2^64 is worlds apart in performance. I suggest that you compare 16 bit computers, which didn't support true-color, full motion multimedia, and compare to 32 bit computers. They both support text editing; however, one supports WYSIWYG better than the other...
FYI, my day job involves running MRI scans on a VMS/VAX Gyroscan Intera workstation... This 64 bit architecture is the hottest stuff around, for somebody who works with a VMS/VAX workstation... here's why: MRI scanners work just like any other printer/scanner device, in terms of device drivers, and general operation. The difficulty is, because MRI looks at differential angular momentum of hydrogen atoms to obtain it's pictures, it's got to calculate a Fourier wave analysis on each atom it vibrates. Being able to run an algorithm with 64 bits means less data manipulation, higher resolution, faster scan times, and increased diagnostic imaging power to the medical doctors.
Anyhow, for those interested, there currently seems to be a big migration from VMS/VAX/Alpha solutions to Windows/Intel compatibility (for obvious reasons). Philips has introduced an InteraNT product into their Intera Gyroscan line, which runs the MRI scanner on a Windows NT platform, instead of the traditional VMS/VAX platform which they've been using for some time...
As usual, great tool for the server companies, crap for everyone else in the world.
This is slashdot... they cover stuff which is great for server companies, hospital radiology departments, nuclear power facilities, astronautical engineering groups, etc. etc. That's why we love it...
automatic file versioning!
if you have foo.txt and you save another foo.txt in the same directory, you get foo.txt;2 !
damn, i wish Windows had that.
-c
I have discovered a truly remarkable proof which this margin is too small to contain.
Well, I just happened to have these links lying around, as I work on VMS/VAX systems at work (Gyroscan Intera system). These links are sort of the OpenVMS equivalent of gnu.org, gnome.org, redhat.com, and so forth...
n vms_roadmaps.htm
Core OpenVMS
http://www.openvms.compaq.com/
OpenVMS Future Release Contents, Schedules
http://www.openvms.compaq.com/openvms/roadmap/ope
OpenVMS and Core Layered Product Documentation
http://www.openvms.compaq.com/doc/
http://www.openvms.compaq.com:8000/
http://www.openvms.compaq.com/commercial/
Core OpenVMS Support Search Engine URLs, FTP Patch Area http://askq.compaq.com/
http://ftp.digital.com.au/pub/ecoinfo/
ftp://ftp.service.digital.com/public/vms/vax/...
ftp://ftp.service.digital.com/public/vms/axp/...
The OpenVMS Freeware
http://www.openvms.compaq.com/freeware/
Encompas
http://www.encompassus.org/
Tech Help OpenVMS
http://askq.compaq.com/
http://www.openvms.compaq.com/wizard/
ftp://ftp.service.digital.com/public/vms/vax/...
From the perspective of a user in a mis-managed VMS environment, I can understand your sentiment, but it was your sysadmins who were at fault, not VMS.
The fact that VMS HAS options which allow extremely fine-grained selection of user privs is a positive thing about the OS. VMS also had all kinds of login security years (break-in detection and evasion) before other systems, and was designated "trusted" quite early on.
VMS could be mismanaged so that it would crash, if ALL logging options were enabled. But that doesn't make it bad for it to have had so many different logging options.
Diskquotas weren't even enabled by default when I was using VMS. You *could* enable them (and obviously your silly sysadmins both enabled them and put very low limits on you), but you never had to.
VMS is a very flexible tool, and tools can be made to do lots of things, some good, some bad.
By the way, even now there aren't that many systems with the availability and redundancy VMS clusters had in 1985 (automatic failover from one machine to another, separate shared disk controllers, etc. etc.).
Finally VAX/VMS virtual memory worked better than any other such system I've seen. You could actually let things page and they didn't slow down much, since the paging was so intelligent.
*sigh* anyway, that was all a long time ago. I haven't used VMS professionally since 1992 or so...